Protocolo de control de congestión de datagramas

format_list_bulleted Contenido keyboard_arrow_down
ImprimirCitar

En redes de computadoras, el Protocolo de control de congestión de datagramas (DCCP) es un protocolo de capa de transporte orientado a mensajes. DCCP implementa una configuración confiable de conexión, desmontaje, notificación explícita de congestión (ECN), control de congestión y negociación de funciones. El IETF publicó DCCP como RFC 4340, un estándar propuesto, en marzo de 2006. El RFC 4336 proporciona una introducción.

Operación

DCCP proporciona una manera de obtener acceso a mecanismos de control de congestión sin tener que implementarlos en la capa de aplicación. Permite una semántica basada en flujo como en el Protocolo de control de transmisión (TCP), pero no proporciona una entrega en orden confiable. La entrega secuenciada dentro de múltiples transmisiones como en el Protocolo de transmisión de control de transmisión (SCTP) no está disponible en DCCP. Una conexión DCCP contiene tráfico de confirmación y tráfico de datos. Los acuses de recibo informan al remitente si sus paquetes han llegado y si fueron marcados por Notificación de congestión explícita (ECN). Los acuses de recibo se transmiten de manera tan confiable como lo requiera el mecanismo de control de congestión en uso, posiblemente de manera completamente confiable.

DCCP tiene la opción de números de secuencia muy largos (48 bits) correspondientes a un ID de paquete, en lugar de un ID de byte como en TCP. La gran longitud de los números de secuencia tiene como objetivo proteger contra "algunos ataques ciegos, como la inyección de DCCP-Resets en la conexión".

Aplicaciones

DCCP es útil para aplicaciones con limitaciones de tiempo en la entrega de datos. Dichas aplicaciones incluyen transmisión de medios, juegos en línea multijugador y telefonía por Internet. En dichas aplicaciones, los mensajes antiguos rápidamente se vuelven inútiles, por lo que es preferible recibir mensajes nuevos que reenviar mensajes perdidos. A partir de 2017, estas aplicaciones a menudo se conformaron con TCP o utilizaron el Protocolo de datagramas de usuario (UDP) e implementaron sus propios mecanismos de control de congestión, o no tienen ningún control de congestión. Si bien es útil para estas aplicaciones, DCCP también puede servir como mecanismo general de control de congestión para aplicaciones basadas en UDP, agregando, según sea necesario, mecanismos para una entrega confiable o en orden además de UDP/DCCP. En este contexto, DCCP permite el uso de mecanismos de control de congestión diferentes, pero generalmente compatibles con TCP.

Implementaciones

Los siguientes sistemas operativos implementan DCCP:

  • FreeBSD, versión 5.1 como parche
  • Linux desde la versión 2.6.14, pero marcada deprecatada desde la versión 6.4 debido a la falta de mantenimiento y programado para la eliminación en 2025.

Biblioteca de espacio de usuario:

  • DCCP-TP Archivado 2008-07-23 en la implementación de Wayback Machine está optimizada para portabilidad, pero no ha tenido cambios desde junio de 2008.
  • El objetivo de esta aplicación es proporcionar un marco normalizado y portátil para las comunicaciones entre homólogos con control flexible de la congestión, dependiendo de la aplicación.

Estructura del paquete

El encabezado genérico DCCP adopta diferentes formas dependiendo del valor de X, el bit de números de secuencia extendidos. Si X es uno, el campo Número de secuencia tiene una longitud de 48 bits y el encabezado genérico ocupa 16 bytes, como se muestra a continuación.

DCCP header genérico
OffsetsOctet 0 1
Octet Bit0123456789101112131415
0 0 Puerto de origen
2 16 Puerto de destino
4 32 Data OffsetCCValCsCov
6 48 Checksum
8 64 ResTipoX=1Reservado
10 80 Número de secuencia (pechos altos)
12 96 Número de secuencias
14 112 Número de secuencia (bits bajos)

Si X es cero, sólo se transmiten los 24 bits bajos del número de secuencia y el encabezado genérico tiene 12 bytes de longitud.

OffsetsOctet 0 1
Octet Bit0123456789101112131415
0 0 Puerto de origen
2 16 Puerto de destino
4 32 Data OffsetCCValCsCov
6 48 Checksum
8 64 ResTipoX=0Número de secuencia (alto)
10 80 Número de secuencia (bits bajos)
Puerto fuente (16 bits)
Identifica el puerto que envía
Puerto de destino (16 bits)
Identifica el puerto receptor
Data Offset
(8 bits): El offset desde el inicio del encabezado DCCP del paquete hasta el inicio de su área de datos de aplicaciones, en palabras de 32 bits.
CCVal (4 bits)
Utilizado por el CCID HC-Sender
Cobertura de cheques (CsCov) (4 bits)
Checksum La cobertura determina las partes del paquete que están cubiertas por el campo Checksum.
Checksum (16 bits)
La comprobación de Internet de la cabecera DCCP del paquete (incluyendo opciones), un pseudoheader de cadena, y, dependiendo de la cobertura de checksum, todos, algunos o ninguno de los datos de la aplicación
Reservado (Res) (3 bits)
Los remitentes DEBE fijar este campo a todos los ceros en paquetes generados, y los receptores DEBE ignorar su valor
Tipo (4 bits)
El campo Tipo especifica el tipo del paquete
Números de secuencia extendida (X) (1 bit)
Se establece a uno para indicar el uso de un encabezado genérico extendido con números de secuencia y reconocimiento de 48 bits
Número de secuencia (48 o 24 bits)
Identifica el paquete únicamente en la secuencia de todos los paquetes la fuente enviada en esta conexión

Desarrollo actual

De manera similar a la extensión del protocolo TCP mediante capacidad de rutas múltiples (MPTCP), también para DCCP la característica de rutas múltiples está bajo discusión en el IETF, denominada correspondientemente MP-DCCP. Las primeras implementaciones ya se han desarrollado, probado y presentado en un enfoque colaborativo entre operadores y académicos y están disponibles como una solución de código abierto.

Más resultados...
Tamaño del texto:
undoredo
format_boldformat_italicformat_underlinedstrikethrough_ssuperscriptsubscriptlink
save