Protocolo de transmisión de control de flujo

Protocolo de red informática

Conjunto de protocolos de internet
Capa de aplicación
BGP DHCP (v6) DNS FTP HTTP HTTPS IMAP LDAP MGCP MQTT NNTP NTP MÚSICA POP PTP ONC / RPC RTP RTSP ROTURA sorbo SMTP SNMP SSH Telnet TLS / SSL XMPP más...
Capa de transporte
TCP UDP DCCP SCTP RSVP más...
Capa de internet
IP IPv4 IPv6 ICMP (v6) ECN IGMP IPsec más...
Capa de enlace
ARP NDP OSPF Túneles L2TP PPP MAC Ethernet Wifi DSL RDSI FDDI más...
v t mi

El protocolo de transmisión de control de tren ( SCTP ) es una red de la computadora protocolo de comunicaciones en la capa de transporte de la protocolos de Internet . Originalmente diseñado para el transporte de mensajes del Sistema de señalización 7 (SS7) en telecomunicaciones, el protocolo proporciona la función orientada a mensajes del Protocolo de datagramas de usuario (UDP), al tiempo que garantiza un transporte de mensajes confiable y en secuencia con control de congestión como el Protocolo de control de transmisión ( TCP). A diferencia de UDP y TCP, el protocolo proporciona rutas redundantes y de alojamiento múltiple para aumentar la resiliencia y la confiabilidad. SCTP está estandarizado por elGrupo de trabajo de ingeniería de Internet (IETF) en RFC  4960 . La implementación de referencia SCTP fue lanzada como parte de la versión 7 de FreeBSD y desde entonces ha sido ampliamente portada a otras plataformas.

Supervisión formal

El grupo de trabajo de transporte de señalización del IETF ( SIGTRAN ) definió el protocolo (número 132 ^[1] ) en octubre de 2000, ^[2] y el grupo de trabajo del área de transporte del IETF (TSVWG) lo mantiene. RFC 4960 define el protocolo. RFC 3286 proporciona una introducción.  

Transmisión múltiple basada en mensajes

Las aplicaciones SCTP envían datos para su transmisión en mensajes (grupos de bytes) a la capa de transporte SCTP. SCTP coloca los mensajes y la información de control en fragmentos separados ( fragmentos de datos y fragmentos de control), cada uno identificado por un encabezado de fragmento . El protocolo puede fragmentar un mensaje en varios fragmentos de datos, pero cada fragmento de datos contiene datos de un solo mensaje de usuario. SCTP agrupa los fragmentos en paquetes SCTP. El paquete SCTP, que se envía al Protocolo de Internet , consta de un encabezado de paquete, fragmentos de control SCTP (cuando es necesario), seguidos de fragmentos de datos SCTP (cuando están disponibles).

SCTP puede caracterizarse como orientado a mensajes, lo que significa que transporta una secuencia de mensajes (cada uno es un grupo de bytes), en lugar de transportar un flujo de bytes ininterrumpido como en TCP. Al igual que en UDP, en SCTP un remitente envía un mensaje en una operación, y ese mensaje exacto se pasa al proceso de aplicación receptor en una operación. En contraste, TCP es un protocolo orientado a flujos , que transporta flujos de bytes de manera confiable y en orden. Sin embargo, TCP no permite que el receptor sepa cuántas veces la aplicación del remitente llamó al transporte TCP y le pasó grupos de bytes que se enviarán. En el remitente, TCP simplemente agrega más bytes a una cola de bytes en espera de salir a través de la red, en lugar de tener que mantener una cola de mensajes salientes individuales separados que deben conservarse como tales.

El término transmisión múltiple se refiere a la capacidad de SCTP para transmitir varios flujos independientes de fragmentos en paralelo, por ejemplo, transmitiendo imágenes de páginas web simultáneamente con el texto de la página web. En esencia, implica agrupar varias conexiones en una sola asociación SCTP, que opera en mensajes (o fragmentos) en lugar de bytes.

TCP conserva el orden de los bytes en la secuencia al incluir un número de secuencia de bytes con cada segmento . SCTP, por otro lado, asigna un número de secuencia o una identificación de mensaje ^{[nota 1]} a cada mensaje enviado en una secuencia. Esto permite la ordenación independiente de mensajes en diferentes flujos. Sin embargo, el orden de los mensajes es opcional en SCTP; una aplicación receptora puede optar por procesar los mensajes en el orden de recepción en lugar de en el orden de envío.

Funciones

Las características de SCTP incluyen:

• Transmisión confiable de flujos de datos ordenados y no ordenados.
• Soporte de alojamiento múltiple en el que uno o ambos extremos de una conexión pueden constar de más de una dirección IP, lo que permite una conmutación por error transparente entre rutas de red redundantes.
• La entrega de fragmentos dentro de flujos independientes elimina el bloqueo innecesario de cabecera de línea , a diferencia de la entrega de flujo de bytes TCP.
• Fiabilidad parcial explícita.
• Selección y monitoreo de ruta para seleccionar una ruta de transmisión de datos primaria y probar la conectividad de la ruta de transmisión.
• Los mecanismos de validación y reconocimiento protegen contra ataques de inundación y brindan notificación de fragmentos de datos duplicados o faltantes.
• Detección de errores mejorada adecuada para tramas gigantes de Ethernet .

Los diseñadores de SCTP lo pensaron originalmente para el transporte de telefonía ( Sistema de señalización 7 ) sobre Protocolo de Internet, con el objetivo de duplicar algunos de los atributos de confiabilidad de la red de señalización SS7 en IP. Este esfuerzo de IETF se conoce como SIGTRAN . Mientras tanto, se han propuesto otros usos, por ejemplo, el protocolo Diameter ^[3] y Reliable Server Pooling (RSerPool). ^[4]

Motivación y adopción

TCP ha proporcionado el medio principal para transferir datos de manera confiable a través de Internet. Sin embargo, TCP ha impuesto limitaciones a varias aplicaciones. Desde RFC 4960 : 

• TCP proporciona tanto una transferencia de datos confiable como una entrega de datos por orden estricto de transmisión. Algunas aplicaciones necesitan una transferencia confiable sin mantenimiento de secuencia, mientras que otras se conformarían con un orden parcial de los datos. En ambos casos, la propiedad de bloqueo de cabecera de línea de TCP provoca retrasos innecesarios.
• Para las aplicaciones que intercambian registros o mensajes distintos, la naturaleza orientada a la transmisión de TCP requiere la adición de marcadores explícitos u otra codificación para delinear los registros individuales.
• Para evitar enviar muchos paquetes IP pequeños donde un solo paquete más grande hubiera sido suficiente, la implementación de TCP puede retrasar la transmisión de datos mientras espera que la aplicación ponga más datos en la cola ( algoritmo de Nagle ). Si y cuando un retraso tan pequeño no es deseable, la aplicación debe solicitar explícitamente la transmisión sin demora caso por caso utilizando la función de inserción (es decir, estableciendo la bandera PSH en el encabezado del paquete TCP). SCTP, por otro lado, permite configurar la transmisión sin demora como predeterminada para una asociación, eliminando cualquier demora no deseada, pero a costa de una mayor sobrecarga de transferencia. ^[5]
• El alcance limitado ^{[ vago ]} de los sockets TCP complica la tarea de proporcionar una capacidad de transferencia de datos de alta disponibilidad utilizando hosts de múltiples hosts.
• TCP es relativamente vulnerable a los ataques de denegación de servicio, como los ataques SYN .

La adopción se ha ralentizado por la falta de conciencia, la falta de implementaciones (particularmente en Microsoft Windows), la falta de soporte de aplicaciones y la falta de soporte de red. ^[6]

Multi homing

SCTP proporciona rutas redundantes para aumentar la confiabilidad.

SCTP Multihoming

Cada punto final SCTP debe verificar la accesibilidad de las direcciones primaria y redundante del punto final remoto mediante un latido . Cada punto final SCTP debe reconocer los latidos que recibe del punto final remoto.

Cuando SCTP envía un mensaje a una dirección remota, la interfaz de origen solo será decidida por la tabla de enrutamiento del host (y no por SCTP).

Multi homing asimétrico

En el multi-homing asimétrico, uno de los dos puntos finales no admite el multi-homing.

Homing múltiple local: homing único remoto

En Local multi-homing y Remote single homing, si la dirección primaria remota no es accesible, la asociación SCTP falla incluso si es posible una ruta alternativa.

Homing múltiple asimétrico: homing múltiple local - homing único remoto

Homing único local: homing múltiple remoto

Homing múltiple asimétrico: Homing único local - Homing múltiple remoto

Estructura del paquete

Artículo principal: estructura de paquetes SCTP

Bits 0–7 8-15 16-23 24–31 +0 Puerto de origen Puerto de destino 32 Etiqueta de verificación 64 Suma de comprobación 96 Tipo de fragmento 1 Banderas de fragmento 1 Longitud del trozo 1 128 Fragmento 1 de datos ... ... ... Tipo de fragmento N Banderas Chunk N Longitud del trozo N ... Chunk N datos

Un paquete SCTP consta de dos secciones básicas:

1. El encabezado común , que ocupa los primeros 12 bytes y está resaltado en azul, y
2. Los fragmentos de datos , que ocupan la parte restante del paquete. El primer fragmento se resalta en verde y el último de N fragmentos (Chunk N) se resalta en rojo.

Cada fragmento comienza con un identificador de tipo de un byte, con 15 tipos de fragmentos definidos por RFC 4960 y al menos 5 más definidos por RFC adicionales. ^{[nota 2]} Ocho bits de bandera, un campo de dos bytes de longitud y los datos componen el resto del fragmento. Si el fragmento no forma un múltiplo de 4 bytes (es decir, la longitud no es un múltiplo de 4), se rellena con ceros que no se incluyen en la longitud del fragmento. El campo de longitud de dos bytes limita cada fragmento a una longitud de 65.535 bytes (incluidos los campos de tipo, indicadores y longitud). 

Seguridad

Aunque el cifrado no formaba parte del diseño SCTP original, SCTP se diseñó con funciones para mejorar la seguridad, como el protocolo de enlace de 4 vías (en comparación con el protocolo de enlace de 3 vías de TCP ) para proteger contra ataques de inundación SYN y "cookies" grandes para la verificación de la asociación. y autenticidad.

La confiabilidad también fue una parte clave del diseño de seguridad de SCTP. Multihoming permite que una asociación permanezca abierta incluso cuando algunas rutas e interfaces están inactivas. Esto es de particular importancia para SIGTRAN, ya que transporta SS7 a través de una red IP utilizando SCTP y requiere una gran capacidad de recuperación durante las interrupciones del enlace para mantener el servicio de telecomunicaciones incluso cuando se soportan anomalías en la red.

SCTP es a veces un buen candidato para la toma de huellas dactilares . Algunos sistemas operativos se envían con el soporte SCTP habilitado y, como no es tan conocido como TCP o UDP, a veces se pasa por alto en las configuraciones de firewall y detección de intrusiones, lo que a menudo permite el tráfico de sondeo.

Implementaciones

La implementación de referencia SCTP se ejecuta en FreeBSD, Mac OS X, Microsoft Windows y Linux. ^[7]

Los siguientes sistemas operativos implementan SCTP:

• AIX versión 5 y posteriores
• NetBSD ^[8] desde 8.0 ^[9]
• Cisco IOS 12
• DragonFly BSD desde la versión 1.4, sin embargo, el soporte está en desuso en la versión 4.2 ^[10]
• FreeBSD , versión 7 y superior, contiene la implementación SCTP de referencia ^[11]
• HP-UX , 11i v2 y superior ^[12]
• Linux 2.4 y posterior basado en kernel
• Tru64 con el paquete complementario SCTP de Compaq
• QNX Neutrino Realtime OS, ^[13] 6.3.0 a 6.3.2, obsoleto desde 6.4.0 ^[14]
• Sun Solaris 10 y superior ^[15]
• VxWorks versiones 6.2.xa 6.4.xy 6.7 y posteriores
• Ilumina

Controladores de terceros:

• Microsoft Windows :
  • El controlador del kernel SctpDrv es un puerto de la pila BSD SCTP a Windows ^[16]
• MacOS :
  • Extensión de kernel de red SCTP para Mac OS X ^[17]

Biblioteca del espacio de usuario :

• Pila de espacio de usuario SCTP portátil ^[18]
• La biblioteca SCTP ^[19]
  • Puerto de Windows XP ^[20]
• Oracle Java SE 7
• Erlang / OTP

Las siguientes aplicaciones implementan SCTP:

• WebRTC

Túnel sobre UDP

En ausencia de soporte SCTP nativo en los sistemas operativos, es posible tunelizar SCTP sobre UDP, ^[21] así como mapear llamadas API de TCP a llamadas SCTP para que las aplicaciones existentes puedan usar SCTP sin modificaciones. ^[22]

Historial de RFC

• RFC  7829 SCTP-PF: un algoritmo de conmutación por error rápido para el protocolo de transmisión de control de flujo
• RFC  7765 TCP y el protocolo de transmisión de control de flujo (SCTP) Reinicio de RTO
• RFC  7496 Políticas adicionales para la extensión del protocolo de transmisión de control de transmisión parcialmente confiable
• RFC  7053 SACK-INMEDIATELY Extensión para el Protocolo de transmisión de control de flujo (actualiza RFC 4960)
• RFC  6951 UDP Encapsulación de paquetes de protocolo de transmisión de control de flujo (SCTP) para comunicación de host final a host final
• RFC  6525 Protocolo de transmisión de control de flujo (SCTP) Reconfiguración de flujo
• RFC  6458 Extensiones de API de sockets para el Protocolo de transmisión de control de flujo (SCTP)
• RFC  6096 Protocolo de transmisión de control de flujo (SCTP) Registro de indicadores de fragmentos (actualiza RFC 4960)
• RFC  5062 Ataques de seguridad encontrados contra el Protocolo de transmisión de control de flujo (SCTP) y contramedidas actuales
• RFC  5061 Reconfiguración de dirección dinámica del Protocolo de transmisión de control de flujo (SCTP)
• RFC  5043 Adaptación de colocación directa de datos (DDP) del protocolo de transmisión de control de flujo (SCTP)
•  Protocolo de transmisión de control de flujo RFC 4960
• RFC  4895 Trozos autenticados para el Protocolo de transmisión de control de flujo (SCTP)
• RFC  4820 Padding Chunk y parámetro para el protocolo de transmisión de control de flujo (SCTP)
•  Erratas y problemas de especificación del Protocolo de transmisión de control de flujo (SCTP) RFC 4460
• RFC  3873 Base de información de administración (MIB) del Protocolo de transmisión de control de flujo (SCTP )
• RFC  3758 Extensión de confiabilidad parcial del Protocolo de transmisión de control de flujo (SCTP)
• RFC  3554 sobre el uso del protocolo de transmisión de control de flujo (SCTP) con IPsec
• RFC  3436 Seguridad de la capa de transporte sobre el protocolo de transmisión de control de flujo
•  Cambio de suma de comprobación del protocolo de transmisión de control de flujo (SCTP) RFC 3309 (obsoleto por RFC 4960)
• RFC  3286 Introducción al protocolo de transmisión de control de flujo
•  Declaración de aplicabilidad del protocolo de transmisión de control de flujo RFC 3257
•  Protocolo de transmisión de control de flujo RFC 2960 (actualizado por RFC 3309 y obsoleto por RFC 4960)

Ver también

• Capa de transporte § Comparación de los protocolos de la capa de transporte
• Protocolo de inicio de sesión (SIP), que puede iniciar múltiples transmisiones a través de SCTP, TCP o UDP
• Multipath TCP : permite que una conexión TCP utilice varias rutas para maximizar el uso de recursos y aumentar la redundancia.
• Happy Eyeballs : originalmente diseñado para una selección eficiente de IPv4 o IPv6 para una conexión; ^[23] también podría adaptarse para seleccionar entre diferentes protocolos de transporte, por ejemplo: TCP y SCTP ^[24]

Notas

1. El fragmento DATA usa un número de secuencia para mensajes ordenados, el fragmento I-DATA , que resuelve algunos problemas con el fragmento DATA original, usa un ID de mensaje para todos los mensajes
2. Consulte la estructura del paquete SCTP para obtener más detalles

Referencias

1. "Números de protocolo" . iana.org . IANA . Consultado el 9 de septiembre de 2014 .
2. Protocolo de transmisión de Stream Control . IETF . Octubre de 2000. doi : 10.17487 / RFC2960 . RFC 2960 .
3. "Transporte" . Protocolo de base de diámetro . IETF . segundo. 2.1. doi : 10.17487 / RFC3588 . RFC 3588 . Consultado el 18 de mayo de 2012 .
4. "Escenario de ejemplo con servicios de sesión RSerPool" . Una descripción general de los protocolos de agrupación de servidores confiables . IETF . pag. 10. seg. 4.2. doi : 10.17487 / RFC5351 . RFC 5351 .
5. RFC 4960, sección 1.5.5
6. Hogg, Scott. "¿Qué pasa con el Protocolo de transmisión de control de flujo (SCTP)?" . Mundo de la red . Consultado el 4 de octubre de 2017 .
7. "Implementación de referencia para SCTP - RFC4960" . Consultado el 14 de octubre de 2013 . Esta es la implementación de referencia para SCTP. Es portátil y se ejecuta en FreeBSD / MAC-OS / Windows y en el espacio de usuario (incluido Linux).
8. "sys / netinet / sctp.h" . Referencia cruzada BSD . NetBSD . 2017-06-27 . Consultado el 21 de enero de 2019 .
9. "man4 / sctp.4" . Referencia cruzada BSD . NetBSD . 2018-07-31 . Consultado el 21 de enero de 2019 .
10. "DragonFly elimina SCTP" . Lists.dragonflybsd.org . Consultado el 28 de abril de 2016 .
11. "Acerca de los avances tecnológicos de FreeBSD" . El Proyecto FreeBSD. 2008-03-09 . Consultado el 13 de septiembre de 2008 . SCTP: FreeBSD 7.0 es la implementación de referencia para el nuevo protocolo IETF Stream Control Transmission Protocol (SCTP), destinado a admitir VoIP, telecomunicaciones y otras aplicaciones con alta confiabilidad y transmisión de calidad variable a través de características como entrega de múltiples rutas, conmutación por error. y transmisión múltiple.
12. "Protocolo de transmisión de control de flujo (SCTP)" . Compañía de desarrollo de Hewlett-Packard. Archivado desde el original el 3 de enero de 2013.
13. "Redes TCP / IP" . Soporte para desarrolladores de QNX . Sistemas de software QNX . Consultado el 13 de septiembre de 2008 ."Novedades de esta referencia" . Referencia de la biblioteca de QNX . Sistemas de software QNX . Consultado el 18 de diciembre de 2012 .
14. "Plataforma de desarrollo de software QNX 6.4.0" .
15. "Redes del sistema operativo Solaris 10 - Rendimiento de red extremo" . Sun Microsystems . Consultado el 13 de septiembre de 2008 .
16. "SctpDrv: un controlador SCTP para Microsoft Windows" . Archivado desde el original el 8 de enero de 2011 . Consultado el 4 de febrero de 2011 .
17. "Extensión de kernel de red SCTP para Mac OS X" .
18. https://github.com/sctplab/usrsctp
19. "Página de descarga de SCTP" . 2006-05-29 . Consultado el 4 de febrero de 2011 .
20. "Instalador de la biblioteca SCTP de Windows" . Consultado el 4 de febrero de 2011 .
21. Tuexen, Michael; Stewart, Randall R. (mayo de 2013). Encapsulación UDP de paquetes de protocolo de transmisión de control de flujo (SCTP) para comunicación de host final a host final . IETF . doi : 10.17487 / RFC6951 . RFC 6951 .
22. Bickhart, Ryan; Paul D. Amer; Randall R. Stewart (2007). "Capa de compensación de traducción de TCP a SCTP transparente" (PDF) . Consultado el 13 de septiembre de 2008 .
23. D. Ala; A. Yourtchenko (abril de 2012). "Globos oculares felices: éxito con hosts de doble pila" . tools.ietf.org . IETF .
24. Khademi, Naeem; Brunstrom, Anna; Hurtig, Per; Grinnemo, Karl-Johan (21 de julio de 2016). "Globos oculares felices para la selección de transporte" . tools.ietf.org . IETF . Consultado el 9 de enero de 2017 .

Enlaces externos

• sigtran (archivado)
• Ietf.org
• Ietf.org
• Openss7.org
• Grupo de trabajo SCTP para Linux
• Página SCTP de Michael Tüxen
• Página SCTP de Lode Coene
• Página del proyecto SCTP de Thomas Dreibholz