ALTO (protocolo)

La optimización del transporte en la capa de aplicación ( ALTO ) es un protocolo que permite a los clientes de Internet obtener información que compara las propiedades de red de las rutas a otros puntos finales. Normalmente, esto se usaría para identificar la ubicación de menor coste para acceder a una copia de algún tipo de contenido. ^{[ 1 ]}

El protocolo base ALTO se especifica en RFC 7285. ^{[ 2 ]} Requiere que se implementen "servidores ALTO" en la red con conocimiento de las propiedades de la red, a menudo simplemente el costo de enrutamiento a varios puntos finales. ^{[ 3 ]} Un "cliente ALTO", generalmente vinculado a un agente de usuario que intenta obtener un recurso, consulta al servidor ALTO a través de HTTP para obtener la ubicación óptima desde la cual recuperar el recurso.

A partir de 2005, el uso generalizado de aplicaciones peer-to-peer como BitTorrent se convirtió en una seria preocupación para muchos operadores de red, ya que el enorme volumen de tráfico generado por estas aplicaciones tuvo un impacto significativo en la ingeniería de tráfico y los ingresos. Algunos operadores de red intentaron limitar este tráfico. ^{[ 4 ]}

En mayo de 2008, en un taller del IETF sobre infraestructura peer-to-peer, se identificaron varias áreas de trabajo: ^{[ 5 ]}

1. Una interfaz estandarizada para el intercambio de información entre la red IP subyacente y una red superpuesta , como una red peer-to-peer . La idea básica es que, si la red superpuesta conociera la topología y el coste de envío de tráfico a través de la red IP subyacente , podría optimizar las decisiones relativas a la topología de la red superpuesta (por ejemplo, la selección de pares ) y el enrutamiento del tráfico a través de ella. El resultado sería un mejor rendimiento o una mejor experiencia de usuario en la aplicación, a la vez que se reduce la utilización de la infraestructura de red subyacente. Este proyecto dio lugar a la creación del grupo de trabajo ALTO de la IETF.
2. Cachés de contenido en la red. Esto se ha estudiado en el grupo de trabajo DECADE de la IETF. Sin embargo, no se ha desarrollado ni estandarizado ningún protocolo nuevo. ^{[ 6 ]}
3. Un nuevo mecanismo de control de congestión en la capa de transporte para el tráfico de fondo, que "cede" al TCP estándar . Esto se desarrolló en el grupo de trabajo LEDBAT de la IETF y se estandarizó en la RFC 6817. ^{[ 7 ]}
4. Se ha estandarizado en RFC 8622 un nuevo punto de código DiffServ para marcar los paquetes IP con una prioridad menor que la categoría predeterminada de " mejor esfuerzo ". ^{[ 8 ]}

El grupo de trabajo IETF ALTO se estableció en noviembre de 2008. ^{[ 9 ]} Los primeros entregables fueron el planteamiento del problema, ^{[ 1 ]} el documento de requisitos, ^{[ 3 ]} la especificación del protocolo ALTO central ^{[ 2 ]} y un mecanismo de descubrimiento de servidores ALTO. ^{[ 10 ]} Desde entonces, se han especificado varias extensiones (véase más abajo) o todavía están en desarrollo (véase IETF ALTO Datatracker ^{[ 11 ]} ).

Diseñado originalmente para facilitar el intercambio de archivos entre pares , el concepto es ampliamente aplicable a muchos problemas de red. ^{[ 12 ]} Sin embargo, hasta 2021 no se había generalizado su uso en internet. No obstante, se han realizado experimentos en redes de proveedores de servicios de internet (ISP) y se ha implementado para facilitar grandes transferencias de datos en el Gran Colisionador de Hadrones del CERN . ^{[ 13 ]}

Los servidores ALTO suelen operar dentro de un proveedor de servicios de Internet (ISP) y recopilan información sobre la topología de su red. Los métodos para recopilar esta información quedan fuera del alcance del diseño de ALTO, pero normalmente implican participar en el intercambio de información del protocolo de enrutamiento, aceptar políticas de entrada de la administración de la red y datos de diversos sistemas de monitorización de la red.

El servidor ALTO utiliza esta información para proporcionar servicios al cliente.

El primer paso para recuperar información de ALTO es localizar el servidor ALTO. Si el cliente ALTO se encuentra en el host que también es el punto final de las transmisiones de datos que se van a optimizar, se puede utilizar el procedimiento de descubrimiento del servidor ALTO especificado en RFC 7286 ^{[ 10 ]} . En cambio, cuando el cliente ALTO se encuentra en un host diferente (por ejemplo, cuando un rastreador BitTorrent con un cliente ALTO integrado quiere optimizar la selección de pares en nombre de un par que podría estar en un dominio de red diferente), se debe utilizar el procedimiento de descubrimiento de servidores entre dominios especificado en RFC 8686 ^{[ 14 ]} . Un cliente puede tener el nombre de dominio de descubrimiento de servicio configurado directamente, pero normalmente lo obtendrá mediante DHCP al unirse a una red. A continuación, compone una consulta DDDS a ese host de descubrimiento de servicio para la etiqueta de servicio de aplicación "ALTO:https" o "ALTO:http", que a su vez devuelve la URL de cualquier directorio de recursos de información del servidor ALTO (IRD) disponible.

Posteriormente, el cliente recuperaría el IRD de uno de los servidores ALTO, que enumera los detalles de los servicios disponibles, los parámetros admitidos y la ubicación de dichos servicios.

En el protocolo base existen cuatro tipos de servicio:

El servicio de mapas proporciona un archivo que enumera todos los puntos finales o PID que el servidor rastrea. Un "mapa de red" funciona como un "índice" que el cliente puede usar para construir consultas más específicas. Estos puntos finales se identifican mediante direcciones IPv4 o IPv6 y se agrupan con otros puntos finales de propiedades similares en identificadores definidos por el proveedor (PID) para reducir el tamaño de las consultas y respuestas futuras. Un "mapa de costos" enumera el costo de enrutamiento para cada par de PID.

El servicio de filtrado de mapas proporciona un subconjunto del mapa de red o del mapa de costes en función de los parámetros proporcionados por el cliente.

El servicio de propiedades de punto final permite al cliente consultar propiedades, como el tipo de conectividad o el PID de encapsulación, de un punto final específico.

El servicio de cálculo de costes de los puntos finales proporciona a los clientes el coste de enrutamiento a puntos finales específicos, que puede expresarse como una métrica de coste absoluto o como una clasificación del coste relativo de cada uno.

Las especificaciones posteriores especifican servicios adicionales:

El Servicio de Flujo de Actualización , especificado en RFC 8895, ^{[ 15 ]} mantiene la conexión abierta para que el servidor proporcione un flujo de mensajes de actualización a medida que cambia la información. El mismo RFC también especifica el Servicio de Control de Flujo , que permite al cliente cambiar su solicitud de mensajes de actualización.

Todos los mensajes del cliente ALTO son solicitudes HTTP REST que obtienen respuestas HTTP del servidor ALTO. Las cargas útiles de estas solicitudes y respuestas consisten en texto JSON que contiene pares clave-valor jerárquicos.

Los clientes obtienen el IRD mediante el mensaje HTTP GET. El siguiente ejemplo de la RFC 7285 muestra una solicitud del IRD. El destino solicitado (/directory) proviene del proceso de descubrimiento de servicios DDDS descrito anteriormente. Este IRD proporciona destinos para los servicios disponibles en este servidor, así como los parámetros aceptables.

GET /directory HTTP / 1.1 Host : alto.example.com Accept : application/alto-directory+json,application/alto-error+json

HTTP / 1.1 200 OK Content-Length : 2333 Content-Type : application/alto-directory+json{ "meta" : { "cost-types" : { "num-routing" : { "cost-mode" : "numerical" , "cost-metric" : "routingcost" , "description" : "My default" }, "num-hop" : { "cost-mode" : "numerical" , "cost-metric" : "hopcount" }, "ord-routing" : { "cost-mode" : "ordinal" , "cost-metric" : "routingcost" }, "ord-hop" : { "cost-mode" : "ordinal" , "cost-metric" : "hopcount" } }, "default-alto-network-map" : "my-default-network-map" }, "resources" : { "my-default-network-map" : { "uri" : "http://alto.example.com/networkmap" , "media-type" : "application/alto-networkmap+json" }, "numerical-routing-cost-map" : { "uri" : "http://alto.example.com/costmap/num/routingcost" , "media-type" : "application/alto-costmap+json" , "capabilities" : { "cost-type-names" : [ "num-routing" ] }, "uses" : [ "my-default-network-map" ] }, "numerical-hopcount-cost-map" : { "uri" : "http://alto.example.com/costmap/num/hopcount" , "media-type" : "application/alto-costmap+json" , "capabilities" : { "cost-type-names" : [ "num-hop" ] }, "uses" : [ "my-default-network-map" ] },"custom-maps-resources" : { "uri" : "http://custom.alto.example.com/maps" , "media-type" : "application/alto-directory+json" }, "endpoint-property" : { "uri" : "http://alto.example.com/endpointprop/lookup" ,"media-type" : "application/alto-endpointprop+json" , "accepts" : "application/alto-endpointpropparams+json" , "capabilities" : { "prop-types" : [ "my-default-network-map.pid" , "priv:ietf-example-prop" ] }, }, "endpoint-cost" : { "uri" : "http://alto.example.com/endpointcost/lookup" , "media-type" : "application/alto-endpointcost+json" , "accepts" : "application/alto-endpointcostparams+json" , "capabilities" : { "cost-constraints" : true , "cost-type-names" : [ "num-routing" , "num-hop" , "ord-routing" , "ord-hop" ] } } } }

Los clientes obtienen el servicio de mapas mediante el mensaje HTTP GET. El siguiente ejemplo de la RFC 7285 muestra una solicitud de un mapa de red y una respuesta que agrupa cinco puntos finales en 3 PID:

GET /networkmap HTTP / 1.1 Host : alto.example.com Accept : application/alto-networkmap+json,application/alto-error+json

HTTP / 1.1 200 OK Content-Length : 449 Content-Type : application/alto-networkmap+json{ "meta" : { "vtag" : { "resource-id" : "my-default-network-map" , "tag" : "da65eca2eb7a10ce8b059740b0b2e3f8eb1d4785" } }, "network-map" : { "PID1" : { "ipv4" : [ "192.0.2.0/24" , "198.51.100.0/25" ] }, "PID2" : { "ipv4" : [ "198.51.100.128/25" ] }, "PID3" : { "ipv4" : [ "0.0.0.0/0" ], "ipv6" : [ "::/0" ] } } }

Los otros tres servicios dependen de información adicional que el cliente proporciona en la solicitud. Dado que HTTP GET no requiere una solicitud, los clientes acceden a estos servicios mediante el método HTTP POST. El siguiente ejemplo de RFC 7285 muestra una solicitud de costo desde una fuente a tres posibles destinos, junto con la respuesta.

POST /endpointcost/lookup HTTP / 1.1 Host : alto.example.com Content-Length : 248 Content-Type : application/alto-endpointcostparams+json Accept : application/alto-endpointcost+json,application/alto-error+json{ "cost-type" : { "cost-mode" : "ordinal" , "cost-metric" : "routingcost" }, "endpoints" : { "srcs" : [ "ipv4:192.0.2.2" ], "dsts" : [ "ipv4:192.0.2.89" , "ipv4:198.51.100.34" , "ipv4:203.0.113.45" ] } }

HTTP / 1.1 200 OK Content-Length : 274 Content-Type : application/alto-endpointcost+json { "meta" : { "cost-type" : { "cost-mode" : "ordinal" , "cost-metric" : "routingcost" } }, "endpoint-cost-map" : { "ipv4:192.0.2.2" : { "ipv4:192.0.2.89" : 1 , "ipv4:198.51.100.34" : 2 , "ipv4:203.0.113.45" : 3 } } }

Numerosos estándares adicionales han ampliado la usabilidad y el conjunto de funciones del protocolo.

• RFC 8189 ^{[ 16 ]} permite a los clientes solicitar varios tipos de costos (por ejemplo, costo de enrutamiento y número de saltos) en una sola solicitud.
• RFC 8896 ^{[ 17 ]} introduce el concepto de "calendario de costos", donde el servidor puede expresar cómo evoluciona el costo para llegar a un punto final a lo largo del tiempo.
• El IETF Datatracker para el grupo de trabajo ALTO ^{[ 11 ]} muestra documentos que aún están en proceso de elaboración.