ES2410654B1 - Sistema y método para gestionar la infraestructura de un servicio de red de distribución de contenido en una red isp - Google Patents

Abstract

Sistema y método para gestionar la infraestructura de un servicio de red de distribución de contenido en una red ISP.#El sistema comprende un gestor CDN de una red de distribución de contenido que aloja interfaces de programación API para administrar regiones en una unidad de negocio u OB, añadiendo y/o borrando dichas regiones de dicho OB usando dichas API, en donde dichas API de un proveedor de servicios CDN están seleccionadas de: una API de gestión de contenido, una API DNS que permite la configuración de servidores DNS en regiones nuevas, y una API de topología de red que permite al proveedor de servicios CDN definir su visión de topología de red.#El método comprende usar un gestor CDN para administrar una o más regiones en una unidad de negocio para implementar al sistema.

Description

SISTEMA Y METODO PARA GESTIONAR LA INFRAESTRUCTURA DE UN SERVICIO DE RED DE DISTRIBUCiÓN DE CONTENIDO EN UNA RED ISP

Campo de la técnica

La presente invención se refiere en general, en un primer aspecto, a un sistema para gestionar la infraestructura de un servicio de red de distribución de contenido en una red ISP, y más particularmente a un sistema que comprende un gestor CON que aloja inteñaces de programación de aplicaciones API para administrar una o más regiones en una unidad de negocio.

Un segundo aspecto de la invención se refiere a un método que usa dicho gestor CDN para implementar el sistema del primer aspecto.

Estado de la técnica anterior

Las redes de entrega de contenido (CDN) son una red de ordenadores que contienen copias de datos, situadas en diversos puntos en la red para acelerar el acceso a datos para los clientes por toda la red (1]. La idea clave en este caso es garantizar que los usuarios finales no van todos al servidor central para acceder a los datos. Más bien, el usuario final accede a una copia de los datos cercana para evitar que se provoquen atascos de computación y de ancho de banda de red en el servidor central.

A medida que crece la demanda de contenido multimedia en Internet, también lo hace la necesidad de mantener los costes de ancho de banda bajos y reducir los ciclos de mejora de los enlaces de red principal. Las CDN han despegado en gran medida en los últimos años. Las CON pueden distribuir dinámicamente contenido a diferentes puntos de la red de borde y gestionar la carga de red y optimizar la capacidad por cliente. Las CON pueden ofrecer disponibilidad de contenido ante cortes de potencia, de red y de hardware.

Las redes de entrega de contenido existen desde hace más de una década. Existen diversas arquitecturas para construir y operar tales redes. Akamai por ejemplo, tiene varias decenas de miles de servidores distribuidos por muchos PoP remotos. Akamai usa una jerarquía de servidores DNS para identificar los servidores de contenido que pueden proporcionar de la mejor manera el contenido solicitado.

También se usan memorias caché web para almacenar el contenido más popular en servidores que tienen el mayor número de peticiones de cliente. Las memorias caché web reducen la carga del servidor y mejoran el tiempo de respuesta del usuario final para el contenido que está almacenado en la memoria caché.

Con Amazon Cloudfront, el cliente en primer lugar crea un contenedor 83 que servirá como servidor original para el contenido. El cliente pone entonces el contenido en el contenedor 83 y convierte el contenido en públicamente legible. Como siguiente etapa, el cliente CON crea una distribución cloudfront y la infraestructura genera un ID de distribución único y un nombre de dominio cfoudfront. El cliente CON puede incrustar entonces los URL en su sitio web de modo que cuando un usuario final solicita contenido, cloudfront recibirá el URL apropiado que se usará para proporcionar el contenido.

Cloudfront ofrece HTIP para proporcionar archivos básicos y transmisión en flujo continuo RTMP de archivos de medios. Cloudfront también permite a un cliente CDN usar sus nombres de dominio personalizados y usar los servidores originales ubicados en las instalaciones del cliente.

Lime/ight usa un número pequeño de grandes centros de datos conectados mediante una red óptica de alta velocidad, de alta capacidad. Estos centros de datos están ubicados estratégicamente para conectarse con redes de acceso en múltiples ubicaciones por todo el mundo. Limelight usa un mecanismo de redirección DNS que correlaciona peticiones con un nodo de extremo en uno de sus centros de datos. Por ejemplo, una consulta al ONS de 'MVW.shrek3.com se resuelve en primer lugar para dar drmwrks.vo.llnwd.net mediante la infraestructura de DNS pública [2]. Esto se resuelve entonces para dar una dirección IP de nodo de extremo específica en un centro de datos mediante la infraestructura de ONS privada de Lime/ight.

Lime/ight también permite a los clientes usar directamente nombres de anfitrión de Limelight en sus sitios web. Por ejemplo, los clientes que están descargándose películas de Amazon Unbox pueden encontrar que su petición se contesta por Amazon-xxx.vo.llnwd.net (donde xxx es un número entero) [2).

Limelight y Amazon Cloudfront tienen un número pequeño de grandes centros de datos que se conectan a través de una red global. La arquitectura de Highwinds Network tiene muchos pequeños centros de datos distribuidos globalmente conectados a través de una red global. En todos estos casos, se identifica el servidor en el centro de datos (de la red CON de alojamiento) más cercano al cliente solicitante para entregar el contenido. Sin embargo, la construcción de centros de datos tan grandes y sobrecargados implica un gasto de capital significativo y aun así, no utilizan completamente la flexibilidad ofrecida por la infraestructura de red existe.

Existen varios problemas con las soluciones existentes.

(1)

El ONS y el equilibrado de la carga se acoplan. Esto hace difícil distinguir entre un servidor de contenido sobrecargado y un servidor DNS sobrecargado.

(2)

Varias de las soluciones de centros de datos anteriores son caras y requieren un gasto de capital significativo para su construcción y despliegue.

(3)

Algunas de estas soluciones requieren hardware especializado en forma de equilibradores de carga, servidores de tecnología avanzada para entregar contenido.

(4)

Algunas de las soluciones se basan puramente en P2P. En este caso, cada usuario final se trata como un igual para distribuir contenido. Se requieren recursos del usuario final para distribuir contenido. Esto implica requisitos adicionales de seguridad y autenticación cuando se distribuye contenido.

(5)

Las soluciones basadas en P2P usan un ancho de banda no fiable en usuarios finales, que tienen diferentes limitaciones de recursos dependiendo de la aplicación que ejecutan en sus maquinas para intentar entregar contenido de manera fiable. Una entrega de contenido fiable es imposible a gran escala en un escenario de este tipo.

(6)

Sólo los protocolos de tipo BitTorrent usan la información de topología mas reciente cuando se encuentran enlaces de red que estan lo menos cargados para distribuir contenido, pero éstos se basan puramente en P2P.

(7)

No es posible desplegar mucho las soluciones tratadas anteriormente en una topología de ISP. De las anteriores, sólo la solución de Akamai puede desplegarse mucho en un ISP. Sin embargo, esto requeriría que el ISP expusiera detalles significativos sobre su topología.

Descripción de la invención

Es necesario ofrecer una alternativa para el estado de la técnica que cubra las lagunas encontradas en la misma, en particular las relacionadas con la falta de propuestas que ofrecen soluciones que pueden desplegarse en una red ISP tanto como sea necesario y sin exponer los detalles de la topología de red ISP.

Para ese fin, la presente invención proporciona, en un primer aspecto, un sistema para gestionar la infraestructura de un servicio de red de distribución de contenido en una red ISP, que, a diferencia de las propuestas conocidas, comprende un gestor CON de una red de distribución de contenido que aloja una o mas interfaces de programación de aplicaciones API para administrar una o mas regiones en una unidad de negocio u OB, al menos añadiendo y/o borrando dichas regiones de dicho 08 usando dichas API , en donde dichas API de un proveedor de servicios CDN están seleccionadas de al menos un grupo que comprende:

-

una API de gestión de contenido que permite a dicho proveedor de servicios CON proporcionar a los propietarios de contenido las herramientas para gestionar su contenido, -una API DNS que permite la configuración de servidores DNS en regiones nuevas, y nombres de componentes CON ambos en la misma región que dicho servidor DNS y a 5 nivel de OB, y

-

una API de topología de red que permite al proveedor de servicios CON definir su visión de topología de red, o bien en detalle o como una abstracción de alto nivel de la red subyacente.

Otras realizaciones del sistema del primer aspecto de la invención, se describen 10 según las reivindicaciones 2 a 5 adjuntas, y en una sección posterior relacionada con la descripción detallada de varias realizaciones.

Un segundo aspecto de la invención se refiere a un método para gestionar la infraestructura de un servicio de red de distribución de contenido en una red API , en donde de una manera característica y a diferencia de las propuestas conocidas comprende utilizar

15 un gestor CON de una red de distribución de contenido que aloja una o más interfaces de programación de aplicaciones API destinadas a administrar una o más regiones en una unidad de negocio u 08, al menos añadiendo y/o borrando dichas regiones en dicho 08 usando dichas API por un proveedor de servicios CON

Otras realizaciones del método del segundo aspecto de la invención, se describen 20 según las reivindicaciones 7 a 23 adjuntas, y en una sección posterior relacionada con la descripción detallada de varias realizaciones.

A continuación se facilitan algunas definiciones que son útiles para comprender la terminología usada tanto para las divulgaciones de la técnica anterior como para la presente 25 invención.

Punto de presencia (PoP): Un punto de presencia es una demarcación artificial o punto de interfaz entre dos entidades de comunicación. Es un punto de acceso a Internet que aloja servidores, conmutadores, encaminadores y agregadores de llamadas. Los ISP normalmente tienen múltiples PoP.

30 Sistema de resolución de ONS de ISP: Los usuarios residenciales se conectan a un ISP. Cualquier petición para resolver una dirección se envía a un sistema de resolución de ONS mantenido por el ISP. El sistema de resolución de ONS de ISP enviará la petición de ONS a uno o más servidores ONS dentro del dominio administrativo delISP. Contenedor: Un contenedor es un compartimento lógico para un cliente. Un

35 contenedor o bien establece un enlace entre el URL del servidor original y la URL de la CON

o puede contener el propio contenido (que se transmite mediante ftp al contenedor en el punto de entrada). Un nodo de extremo replicará archivos desde el servidor original a archivos en el contenedor. Cada archivo en un contenedor puede correlacionarse exactamente con un archivo en el servidor original. Un contenedor tiene varios atributos 5 asociados con el mismo. Estos atribulos son de dos clases (i) basados en sistemas de archivos (casi como los atributos de un archivo en Unix) y (ii) para distribución de contenido, por ejemplo la duración durante la que es válida un contenido, geobloqueo de contenido, elc. También se utilizan mecanismos para garantizar que se transmitan automáticamente nuevas versiones del contenido en el servidor original al contenedor en los nodos de

10 extremo y se eliminen versiones antiguas.

Un cliente puede crear tantos contenedores como desee. Un compartimiento es en realidad un directorio que contiene archivos de medios. Un contenedor puede contener subdirectorios y archivos dentro de esos subdirectorios.

Geolocalización: Es la identificación de ubicaciones geográficas reales de un

15 dispositivo conectado a Internet. El dispositivo puede ser un ordenador, dispositivo móvil o un aparato que permita la conexión a Internet para un usuario final. Los datos de geolocalización de la dirección IP pueden incluir información tal como país, región, ciudad, código postal, latitud/longitud de un usuario

Aplicación de función hash (hashing) consistente: Este método proporciona la

20 funcionalidad de una tabla hash de modo que la adición o eliminación de una ranura no altera significativamente la correlación de llaves con ranuras. La aplicación de función hash consistente es un modo de distribuir peticiones entre una población grande y cambiante de servidores web. La adición o eliminación de un servidor web no altera significativamente la carga en los otros servidores.

25 MD5: En criptografía, MD5 es una función criptográfica usada ampliamente con un valor de hash de 128 bits. MD5 se usa ampliamente para probar la integridad de los archivos. MD5 se expresa normalmente como un número hexadecimal. 08 (Unidad de negocio): Un 08 es un área geográfica arbitraria en la que está instalada la CDN de un TID. Un 08 puede operar en más de una región. Una región es un

30 área geográfica arbitraria y puede representar un país, o parte de un país o incluso un conjunto de países . Un 08 puede estar compuesto por más de una región. Un 08 puede estar compuesto por uno o más ISP. Un 08 tiene exactamente una instancia de DNS y servidor de topología.

PIO (ID de partición): Esto es meramente una correlación de prefijos IP a nivel de AS con números enteros. Se trata de una correlación uno a uno. Esto es una partición muy basta de prefijos IP.

ONS (Servicio de nombres de dominio): DNS es un servicio que traduce nombres de dominio en direcciones ¡P. La resolución de DNS es jerárquica. Si un servidor DNS no sabe cómo traducir un nombre de dominio, pregunta a otros servidores DNS comenzando con el servidor DNS raíz hasta que encuentra el servidor DNS que puede resolver el nombre de dominio.

CON (Red de distribución de contenido): Esto se refiere a un sistema de nodos (u ordenadores) que contienen copias de contenido de cliente que está almacenado y situado en diversos puntos en una red (o Internet pública). Cuando se replica contenido en diversos puntos en la red, el ancho de banda se utiliza mejor a lo largo de la red y los usuarios tienen tiempos de acceso más rápidos al contenido. De este modo, el servidor original que contiene la copia original del contenido no experimenta atascos.

URL: El localizador uniforme de recursos (URL) es la dirección de una página web en la world wide web. No hay dos URL idénticos. Si son idénticos, apuntan al mismo recurso. Redirección URL (o de HTTP): El redirección URL también se conoce como reenvío de URL. Una página puede necesitar redirección (1) si su nombre de dominio ha cambiado,

(2) si se crean alias significativo para URL largos o que cambian frecuentemente (3) si el usuario deletrea mal un nombre de dominio al teclearlo (4) si se manipula a los visitantes, etc. Para este propósito, un servicio de redirección típico es uno que redirecciona usuarios al contenido deseado. Un enlace de redirección puede usarse como dirección permanente para contenido que cambia frecuentemente de anfitrión (host) (casi como de DNS).

Vídeo bajo demanda (VoD): Éstos son sistemas que permiten a los usuarios seleccionar y ver flujos continuos de vídeo. Estos sistemas pueden transmitir en flujo continuo contenido mediante un módulo decodificador, un ordenador (que permite visualizar el contenido en tiempo real) o permiten descargar el archivo antes de visualizarlo.

Protocolo de transferencia de hipertexto (HTTP): HTIP es un protocolo peticiónrespuesta diseñado para la comunicación cliente-servidor en la web. Un navegador web, que actúa como cliente remite peticiones HTIP a un sitio web que actúa como servidor.

Proveedor de servicios de Internet (ISP): Un proveedor de servicios de Internet (ISP) proporciona a sus clientes acceso a Internet. El ISP puede usar interconexiones de alta velocidad, módem de cable, DSL o conmutación para esto.

Menos recientemente usado (LRU): Es un ejemplo de un algoritmo de sustitución o una política de sustitución. LRU descarta en primer lugar los elementos menos

recientemente usados. Usado a menudo para situar previamente memorias caché, en esta invención, se usa para sustituir archivos en un disco.

Interfaz de programación de aplicaciones (API): Una interfaz de programación de aplicaciones (API) es un conjunto de reglas y especificaciones que el programa de software puede seguir para acceder y hacer uso de los servicios y recursos proporcionados por otro programa de software que implementa la API. En este documento, se hace referencia a API como una API web (o servicio web) basada en una comunicación de tipo REST.

Registros de NS y de A: Un registro de A es una dirección IPv4 de 32 bits. Se usa para correlacionar nombres de anfitrión con una dirección IP del anfitrión. Un registro de NS (servidor de nombres) delega una región para usar un servidor de nombres autorizado dado.

Breve descripción de los dibujos

Las ventajas y características anteriores y otras se entenderán de manera más completa a partir de la siguiente descripción detallada de realizaciones, con referencia a los dibujos adjuntos, que deben considerarse de una manera ilustrativa y no limitativa, en los que:

La figura 1 muestra una configuración de 08 típica con todos los componentes de la infraestructura CDN del segundo aspecto de la invención. Obsérvese que la infraestructura de monitorización CDN y procesamiento de registro temporal puede operarse en una red separada.

La figura 2 muestra un despliegue de la CON del proveedor de servicios. Cada unidad de negocio (08) utiliza una CON que se conecta con la red principal de Internet, según una realización de la invención.

La figura 3 muestra la interacción entre un cliente CON y la infraestructura CDN del proveedor de servicios al cargar el contenido, según el método del primer aspecto de la invención.

La figura 4 ilustra un ejemplo que muestra todas las interacciones en una infraestructura CON del proveedor de servicios. Más exactamente, esta figura muestra todas las interacciones de un cliente CON , usuarios finales y las interacciones entre los componentes de la infraestructura CON , según una realización del método y la infraestructura de la invención.

La figura 5 muestra una resolución de ONS en una infraestructura CON del proveedor de servicios según una realización del primer aspecto de la invención. En total, la resolución de ONS implica dos consultas al ONS y un redirección HTIP.

Descripción detallada de varias realizaciones

La infraestructura CDN del proveedor de selVicios del segundo aspecto de la invención comprende varias realizaciones. Una realización incluye un gestor CDN que aloja una o más API para implementar el método del primer aspecto de la invención. Otros elementos de la infraestructura CDN son: punto de entrada (o punto de publicación), nodo de extremo, rastreador, servidor original, servidor de topología, divisor en tiempo real, servidor DNS y servidor de registro temporal. En la presente invención, las expresiones servidores de contenido y nodos de extremo se usarán sin distinción. Además, las expresiones punto de entrada y punto de publicación o servidor de publicación se usarán sin distinción.

Para una realización, los elementos de un servicio CON según el método y el escenario de despliegue de la infraestructura CON de la invención puede estar muy dentro en una red ISP. Esto permite allSP alojar servidores de contenido (o nodos de extremo) en el borde y tan cerca como sea posible de los usuarios finales como sea necesario. Por ejemplo, los nodos de extremo pueden estar alojados en la misma ubicación que los OSLAM. El objetivo de una CON es mover contenido desde servidores originales hasta nodos de extremo que están cerca de los usuarios finales solicitantes. Por tanto, el contenido puede proporcionarse con el menor retardo a los usuarios finales solicitantes.

El método del primer aspecto de la invención comprende además diferentes elementos CON que interaccionan entre sí según las diversas realizaciones de la invención para el despliegue de una infraestructura CON.

Para una realización de la invención, la infraestructura CON del segundo aspecto y también descrita en el método del primer aspecto comprende elementos CON que son parte de un escenario de despliegue de 08 típico. Otras realizaciones de la invención son: el despliegue de elementos CON en una región , un escenario de despliegue de 08 múltiple para entidades de un servicio CDN.

Otra realización del método de la invención comprende usar el servidor de topología para describir la topología a un nivel de 08 para crear una abstracción de la topología en una región y/o una abstracción para conectar dos regiones dentro del mismo 08.

Para otra realización, el método comprende prever etapas para la interacción entre diferentes tipos de elementos CDN , el cliente CON (propietario o proveedor de contenido) y usuarios finales (que solicitan contenido).

En primer lugar se describe la función de cada uno de los elementos CDN. A continuación, se describe el diseño CON. También se detalla un escenario de despliegue de un 08 y como puede extenderse el despliegue a múltiples 08. La descripción incluye detallar las acciones que resultan de un cliente CDN que carga contenido en la CDN del proveedor de servicios y las acciones que resultan de un usuario final que solicita contenido alojado por la CON del proveedor de servicios.

5 Descripción de elementos CDN individuales En este caso, se describe la función de cada uno de los elementos CON.

Punto de entrada (punto de publicación): Cualquier proveedor de servicios de un cliente de la CON puede interaccionar con la infraestructura CDN únicamente a través del

10 punto de entrada. El punto de entrada ejecuta una interfaz de servicios web para crear/actualizar sus cuentas CON y para crear/borrar y actualizar contenedores para su cuenta.

Cada contenedor tiene asociado con el mismo metadatos de dos clases, meta datos de sistema de archivos de tipo Unix y metadatos de distribución de contenido. El cliente

15 puede definir los metadatos a nivel de contenedor cuando crea un contenedor. Al crear un contenedor (una carpeta que contiene archivos de contenido), un cliente CON puede cargar un archivo de contenido junto con meta datos a nivel de archivo.

Un cliente puede crear dos clases de contenedores: VoO para contenido de vídeo bajo demanda y en tiempo real para transmitir en flujo continuo contenido en tiempo real. 20 Para el contenido de VoO, un cliente CON tiene dos opciones para cargar datos. El cliente puede o bien cargar archivos en el contenedor o bien proporcionar URL a los archivos que indican el sitio web del cliente CON . Los datos se descargan entonces para su procesamiento por el punto de publicación CON. Posteriormente, el archivo descargado se mueve a otro directorio para su posprocesamiento. Para distribuir contenido en tiempo real,

25 el cliente CON simplemente proporciona el URL del flujo continuo en tiempo real como un parámetro de metadatos al contenedor en tiempo real. La infraestructura CON se encarga de obtener el flujo continuo de contenido original y distribuirlo a los usuarios finales CON .

Gestor CON: El gestor CON aloja la API de gestor de contenidos, la API ONS y la API de topología de red (todas las API están en este servidor). Hay una instancia del gestor 30 CON para toda la CON . El gestor CON puede residir en uno de los puntos de publicación o

en un servidor separado. El gestor CON puede residir en aBO o uno cualquiera de los 08.

Nodo de extremo: Un nodo de extremo es la entidad que gestiona la comunicación entre los usuarios finales solicitantes y la infraestructura CON. Esencialmente es un servidor HTIP personalizado.

Los nodos de extremo mantienen una lista de contenedores/archivos que están disponibles con otros nodos de extremo en el mismo centro de datos. Esto permite que los nodos de extremo en el mismo centro de datos obtengan contenido los unos de los otros cuando sea posible y que vayan al servidor original para el contenido solicitado cuando sea necesario. Los nodos de extremo también tienen una lisia de todos los archivos y contenedores en el 08. Por tanto, también se encargan de geobloquear las peticiones a la infraestructura CDN, descartar las peticiones de contenido frívolas, realizar la autenticación en contenido solicitado si se considera necesario por los propietarios de contenido. Los nodos de extremo también desempeñan un papel central en la resolución de DNS ya que tienen tanto el anillo de función hash consistente como la base de datos de regiones para identificar la región de la petición que se origina y emitir un redirección HTIP respecto a la petición a la región apropiada si es necesario.

Rastreador: El rastreador es la entidad clave que permite la inteligencia y coordinación de la infraestructura CDN. Con el fin de hacer esto, un rastreador mantiene (1) información sobre el contenido en cada nodo de extremo mediante la aplicación de función hash consistente y (2) recopila las estadísticas de uso de recursos periódicamente de cada nodo de extremo. Como parte de esto, el rastreador mantiene información tal como el número de bytes salientes, número de bytes entrantes, número de conexiones activas para cada contenedor, el tamaño del contenido que está proporcionándose, etc.

El rastreador ayuda en la comunicación entre nodos de extremo identificando entornos de nodos de extremo que les permiten compartir datos entre sí en vez de ir al servidor original para recuperar datos cada vez. El rastreador también ayuda a los nodos de extremo a sincronizarse con otras entidades de la infraestructura CDN: el cambio en los metadatos de contenedor y geodb con el gestor CDN , la base de datos de regiones intermedia con el servidor DNS TLD, pidlocdb y la matriz de costes con el servidor de topología.

Servidor original: Éste es el elemento de la infraestructura CDN del proveedor de servicios que contiene la copia maestra de los datos. Cualquier nodo de extremo que no tenga una copia de los datos puede solicitarla del servidor original. Un cliente CDN no tiene acceso al servidor original. La infraestructura CDN del proveedor de servicios mueve los datos desde el servidor de publicación al servidor original tras realizar comprobaciones de seguridad en los datos descargados (MD5 de datos, etc.). El servidor original también mantiene una integridad de nivel de bloque de los datos descargados.

El servidor original es la propiedad de los contenedores en la CDN del proveedor de servicios. Cada archivo en un contenedor tiene asociado con el mismo un URL de servidor

original. Los archivos del cliente CDN se cargan en primer lugar en el punto de publicación y después en el servidor original tras su posprocesamiento.

Servidor de topología: El servidor de topología proporciona un servicio adaptado a la topología que tiene información sobre la topología del 08 en el que opera. Cada 08 puede especificar sus políticas de encaminamiento entre prefijos IP en el servidor de topología. El servidor de topolog ía mantiene información sobre las redes de tránsito y también el coste de atravesar enlaces.

El selVidor de topología ayuda al rastreador a seleccionar la trayectoria de menor coste (tal como se define mediante la política de OS) en el caso de que haya múltiples trayectorias entre una fuente de contenido y un usuario final solicitante.

Divisor en tiempo real: Cuando el cliente crea un contenedor para un canal "en tiempo rear (o evento), se pasa al divisor en tiempo real. El divisor en tiempo real sirve como servidor original para un flujo continuo en tiempo real. El divisor en tiempo real se encarga de obtener un flujo continuo en tiempo real, dividir un flujo continuo en tiempo real y usar un segmentador para crear una lista de reproducción. La lista de reproducción generada se envía a nodos de extremo que pueden proporcionar contenido en tiempo real. El divisor en tiempo real sólo está limitado por el ancho de banda disponible.

SeNidor DNS: El servidor DNS proporciona la resolución de nombres dentro de la infraestructura CON. El ONS raíz reen vía una consulta para t-cdn.net al servidor ONS que está autorizado para el dominio de nivel superior (TLO). Una consulta posterior al servidor ONS TLD resuelve las consultas al servidor DNS autorizado para el dominio de segundo nivel. Estos servidores, autorizados para el dominio de segundo nivel, están dentro de cada OB.

SeNidor de registro temporal: Archivos de registro temporal HTIP de todos los nodos de extremo se envían a este servidor. Estos archivos de registro temporal se procesan entonces por la infraestructura de procesamiento en el servidor de registro temporal para una presentación en tiempo real y contabilidad para los clientes CON.

A continuación , se describen las entidades que son parte del despliegue CON. En primer lugar, se identifican los elementos que son parte de un despliegue de un único OB típico. A continuación, se detalla un ejemplo con múltiples OB. También se identifican y detallan las entidades globales en la CON.

Despliegue de un único OB:

La figura 1 muestra un despliegue típico de un OB, según una realización de la invención. Este despliegue asume una región en el OB. El despliegue consiste en un rastreador, un servidor DNS que está autorizado para un OB, un punto de publicación (que comprende tanto el gestor CON como el publicador de contenido), un divisor en tiempo real para manejar el contenido en tiempo real, un servidor de topología, un servidor original para contener el contendido cargado por los clientes CON, un servidor de registro temporal para

5 contener registros temporales de todos los nodos de extremo y un número de nodos de extremo que proporcionan contenido a los usuarios finales solicitantes. El servidor de registro temporal alimenta a la infraestructura de notificación del OB. El procesamiento/la notificación de registros temporales puede producirse en una red separada y es parte del despliegue de un 08. Además, el TLO para la CON también puede residir dentro de un 08.

10 Los requisitos para el despliegue de un OB se resumen tal como sigue:

(1)

Las subredes de ONS TLO son independientes. No se consideran parte de la topología del OB y nunca se someten a geobloqueo.

(2)

Un OB debe tener exactamente un servidor de topOlogía.

(3) Un OB puede desplegar la CDN en más de una región (dentro del mismo 15 08).

(4)

Una región debe tener exactamente un rastreador y servidor DNS autorizado para esa región .

(5)

Dos 08 pueden tener el mismo ID de región El administrador CON en un OB

asigna ID de región dentro de cada OB (un 08 puede tener varias regiones). 20 Los ID de región no son globalmente únicos.

(6)

Una región puede contener más de una subred.

(7)

Una subred pertenece a exactamente una región.

(8) Si un administrador define dos sub redes y una subred incluye todas las demás (una subred no puede estar incluida sólo parcialmente; o bien está 25 incluida completamente o bien son inconexas), entonces ambas subredes pueden pertenecer a diferentes regiones y OB. La subred más pequeña tiene prioridad a la hora de determinar a qué subregión pertenece. Es decir, si la subred A contiene la subred B, y A Y 8 pertenecen a las regiones RA y Re, entonces cualquier IP de la subred B pertenecerá sólo a la región B, y no a la

30 región A.

(9) Se define una región O por defecto para cada OB. Se asigna a la región O una dirección IP que no está en ninguna subred IP del OB. El servidor DNS TLO se encarga de reenviar las peticiones de los usuarios finales al servidor ONS del OB apropiado.

Por tanto, tal como se explicó anteriormente, un 08 puede tener tantos rastreadores y servidores DNS como número de regiones en un OB. Los servidores DNS de un 08 están autorizados sólo en la región en la que operan (un servidor DNS por región).

5 Despliegue a través de múltiples 08:

La figura 2 muestra un despliegue de la CDN con tres OB. Cada despliegue funciona como una CON independiente. Los enlaces marcados con O son enlaces de red principal que conectan los 08 con grandes encaminadores de núcleo en Internet. Las etiquetas en 081 se explican tal como sigue: la etiqueta 1 es el punto de publicación (también

10 denominado servidor de publicación). Aquí es donde el cliente CDN crea contenedores, carga contenido. El contenido se mueve al servidor original (etiqueta 1a) tras el posprocesamiento y las comprobaciones de seguridad. Cuando un usuario final solicita contenido, el servidor DNS (tras un redirección HTTP) reenvía la petición al rastreador en el OB (etiqueta 1 b). Tras ejecutar una función hash consistente en la petición, el rastreador

15 reenvía la petición al nodo de extremo (etiqueta 1c) que puede atender de la mejor manera la petición. Cuando la petición de contenido llega directamente desde el usuario final, si el nodo de extremo tiene el contenido, proporcionará el contenido. Si no, el nodo de extremo buscará el contenido en el servidor original (etiqueta 1d) antes de atender la petición.

La infraestructura CON también contiene un elemento global, el servidor DNS TLD. O

20 bien puede ser independiente o bien puede residir dentro de uno de los OB. El gestor CON reside con el servidor de publicación en uno de los OB (ya que hay una instancia del gestor CDN para la CDN).

Descripción de la región cero (entidades globales)

25 Cada OB debe fijar una región O por defecto. Un administrador de OB se encarga de definir el rango de IP bajo la administración de cada una de sus regiones. Dado que ningún OB definirá el rango completo de IP, los prefijos IP restantes se asignan a la región O (región cero). La región cero es una región global por defecto. Tiene un rastreador para coordinar

30 todos los nodos de extremo desplegados en esta región. Cualquier petición de una IP que no sea parte de ninguna de las regiones se atenderá mediante un nodo de extremo de la región por defecto. Esta región global es una entidad separada en su totalidad . Esta región global está dimensionada de modo que puede manejar peticiones y tiene una capacidad suficiente para atender peticiones de contenido de todas las partes del mundo cuando las

35 regiones no están definidas apropiadamente.

Definiciones de API

Tal como se indicó anteriormente, el método y el escenario de despliegue de la infraestructura CON de la invención prevé el uso de un gestor CON que aloja todas las API para la CON. Esto permite a un proveedor de servicios CON para un 08 usar las API para la gestión de contenido, servicio DNS cuando se define una región y topología de red cuando se define la red subyacente. El gestor CON proporciona API web (o servicio web) basándose en una comunicación de tipo REST con mensajes de petición y respuesta definidos. Dichas API se describen a continuación para algunas realizaciones.

API de gestión de contenido

Esta API proporciona todos los métodos necesarios para gestionar el contenido que entregara la CON. La entrega se basa en el concepto de un contenedor inteligente, un compartimento lógico con metadatos apropiados. Los metadatos para un contenedor se componen de dos partes: metadatos a nivel de sistema de archivos (como en un sistema de archivos Unix) y meta datos de distribución de contenido. Se definen dos clases de contenedores: (1) un contenedor VoO para la transmisión en flujo continuo de vídeo o una entrega de archivos estática y (2) un contenedor en tiempo real para la transmisión en flujo continuo en tiempo real.

El contenedor VoO define metadatos para el tipo de autenticación, la tasa de transmisión de bits de distribución, el geobloqueo, la colocación previa del contenido, la lista blanca/lista negra, etc.

El flujo continuo en tiempo real, por otro lado, define metadatos para el URL fuente del flujo continuo en tiempo real, el divisor en tiempo real, el geobloqueo, la lista blanca/lista negra, etc.

La API define métodos para crear, borrar, recuperar y actualizar metadatos de contenedor.

Además, la API de gestión de contenido define actualizaciones de metadatos a nivel de archivo para cada archivo en un contenedor. Los metadatos a nivel de archivo anulan los metadatos a nivel de contenedor. La API define métodos para enumerar archivos en un contenedor, añadir archivos a y borrar archivos de un contenedor. Algunos de los parámetros de metadatos que pueden sobrescribirse son: enabled, startdate (válido desde), enddate (válido hasta), bandwidth (tasa de entrega), geoloc (para geobloqueo), etc.

API DNS

El punto de entrada de DNS es parte del gestor CDN en la forma de un gestor de DNS. El gestor de DNS proporciona una API DNS para la comunicación entre un administrador CON/OS y la infraestructura CDN. Hay un espacio de nombre para la CON: tedn.net. El espacio de nombre se divide en OB. Un 08 puede tener múltiples regiones. A cada una de las regiones se le asigna un ID de región (un número entero). Una vez que un administrador de 08 o regiones añade un componente CDN en una región existente o añade un servidor DNS en una nueva región a través de llamadas de API DNS, la actualización de DNS se envía al servidor DNS autorizado de la región. La API DNS se usa para asignar nombres y regiones, realizar geolocalización y para traducir nombres en el espacio de nombre.

El servidor DNS TLD se encarga de la geolocalización, traduciendo nombres en el espacio de nombre CDN: (a) los nombres de contenedor se geolocalizarán siempre usando la base de datos de regiones. Por ejemplo, b10.t-cdn.net pasará a ser b10.111.t-cdn.net para un usuario en la región 111. (b) Los anfitriones nombrados (es decir, webcache1), se geolocalizarán si están presentes en la base de datos de nombres. Si el nombre del anfitrión no está presente en la base de datos de nombres, el nombre se resolverá como alias para la región O.

El DNS TLO está en la región O por defecto. El espacio de dirección IP que no pertenece a ninguna región en ningún OB se asigna por defecto a la región O. El ONS TLD se encarga de reenviar las peticiones realizadas por usuarios finales a los servidores DNS de 08 apropiados.

La API define un método para crear entidades en un OB o una región en un OB, un GET respecto al método de nombres para enumerar todas las entidades en un OB. La API también define métodos que usan un código de regiones para recuperar, actualizar y borrar información sobre un elemento de red (rastreador, servidor ONS, servidor de topología, etc.).

La API es útil para crear una región, recuperar la lista de regiones actuales, recuperar información sobre la región, actualizar la información de región (por ejemplo subredes que pertenecen a una región) y borrar una región.

La API también define métodos para recuperar la base de datos de regiones (todos los prefijos IP en una región de un servidor DNS regional) y la base de datos completa de regiones (todos los prefijos IP en todas las regiones) del servidor ONS TLD. El rastreador ejecuta las dos últimas llamadas API.

API de topología de red

La API de topología de red permite la especificación de un gráfico de topología de red lógica desde el punto de vista de un operador de red, actuando como interfaz con el servidor de topología. La API permite a los operadores abstraer conexiones físicas en particiones lógicas que contienen sub redes. Las particiones se enlazan entre sí con bordes

5 que tienen pesos asociados con los mismos. Estos pesos indican el coste de transferir datos sobre el enlace entre las dos particiones.

Subredes: Un objeto de subred tiene los siguientes atributos: subred y máscara. La API define métodos para crear una nueva subred, borrar una subred existente y recuperar un conjunto de subredes. La API también define métodos para añadir subredes a un ID de

10 partición (PID), borrar subredes de un PID, y recuperar todas las subredes que pertenecen a un PID. También se define un método para recuperar toda la lista de pares de particiónsubred .

Particiones: la API define métodos para crear un objeto de partición que devuelve un PID, devolver un conjunto de particiones, recuperar información sobre (subredes en) un PID, 15 actualizar/crear un PID y borrar un PID.

Bordes: Un borde de red define el coste de transportar una unidad de datos entre dos PIO (o simplemente, el peso de un borde). la API define métodos para obtener la costmatrix (una matriz que define el coste entre cada par de partición), crear, actualizar y recuperar el coste entre dos PID. Por defecto, el coste entre dos PIO se fija en un valor grande. la API

20 también define métodos para recuperar todos los bordes con un PID de origen dado, recuperar todos los bordes respecto a un PID de destino.

la topología descrita en un servidor de topología puede extenderse mucho más allá de sus límites de 08. Sólo se describe el punto de vista de 08 de la topología de red. Como ejemplo, un 08 en España crea una partición que define todas las subredes en los EE.UU.

25 mientras que otro 08 en Argentina crea particiones que definen todas las subredes de los EE.UU.

Método para añadir/borrar una región en un 08: Para la siguiente realización descrita, las API descritas anteriormente alojadas en el 30 gestor CDN se usan para añadir y borrar regiones en un 08.

El gestor CDN también aloja el gestor de DNS que es el punto de entrada al servidor DNS TlD. Esto permite al gestor de DNS gestionar de manera remota la base de datos Sal en el servidor DNS TlD.

Un administrador de 08 asigna un ID de región para una nueva región en un 08. 35 Una vez configurados todos los elementos de una región dentro de un 08, se invoca la API DNS. Esta llamada a la API DNS asocia la nueva región con el servidor DNS TLD. Esto permite al servidor DNS TLD resolver de manera recursiva una petición destinada a una región en un OB.

Cuando se borra una región dentro de un 08, se invoca la API DNS. Esto tiene el

5 efecto de (i) borrar la región del servidor DNS TLD, (ii) borrar todos los registros de NS y registros de A de la región recién eliminada y (jii ) borrar todos los rangos de direcciones IP que pertenecen a la región borrada.

Descripción de la interacción con la CON del proveedor de servicios:

10 A continuación , se describen las interacciones para la CDN del proveedor de servicios. Las interacciones consisten en tres partes: (a) una interacción del cliente CDN con la CDN del proveedor de servicios cuando se añade contenido, (b) una interacción entre todos los componentes de la infraestructura CON y (c) cómo proporciona una CON contenido cuando un usuario final hace una petición de contenido alojado en la CON.

15 -Interacción del cliente con una infraestructura CON del proveedor de servicios: A continuación se describen las interacciones del cliente CON con la CON del

proveedor de servicios. La figura 3 muestra el diagrama secuencial de las interacciones entre el cliente CON y la infraestructura CON y entre diversos elementos de la

20 infraestructura CON al cargar contenido. El punto de entrada es el único punto de comunicación para un cliente CON con una infraestructura CON del proveedor de servicios. Un cliente CON puede usar su cuenta para crear, eliminar y editar contenedores (un directorio o carpeta que contiene los archivos de contenido del cliente CON).

25 Un cliente CON debe crear en primer lugar un contenedor de contenido dentro de la infraestructura CON. El contenedor tiene un id globalmente único que ayuda al proveedor de servicios CON a identificar a un cliente CON . El gestor CON tal como se muestra en la figura 3 proporciona este id de contenedor único. Cuando los clientes crean un contenedor, asocian metadatos apropiados al contenedor y cargan contenido en el contenedor, se crea

30 un archivo requests.xml. Este archivo (requests.xml) contiene una lista de archivos que es necesario colocar en un contenedor así como metadatos asociados con cada archivo. Un cliente CON puede añadir contenido mediante uno cualquiera de dos métodos: cargar contenido o proporcionar la dirección IP del servidor original del cliente CON desde la que la infraestructura CON puede descargar el contenido. El contenido se descarga en el

35 punto de publicación. Antes de que el contenido se transfiera al servidor original, se comprueba la integridad del contenido. El cliente puede o bien cargar los propios archivos en el servidor de publicación o bien indicar que los archivos están en un servidor en el sitio del cliente. En este caso, la infraestructura CDN extraerá el contenido del servidor del cliente

CDN . Dado que el XML también contiene metadatos para cada archivo en el contenedor y lo fija el cliente, garantiza que el cliente tenga un control completo sobre el contenido.

Si el contenido se carga en el servidor de publicación, el cliente CON también puede asignar algunos metadatos a nivel de archivo y/o anular algunos de los metadatos de contenedor. Esto tiene el efecto de crear un archivo requests.xml. El archivo requests.xml define metadatos del/de los archivo(s) cargado(s) en el contenedor. En el punto de publicación, un proceso de monitorización busca la existencia del archivo requests.xml. Una vez que detecta que todos los archivos a los que hace referencia el xml están presentes (y tienen el tamaño correcto), se mueven los archivos a otro directorio para su posprocesamiento. En este momento, se invoca el publicador de contenido.

El publicador de contenido comprueba los archivos cargados en cuanto a la integridad del contenido. Una vez comprobada la integridad del contenido respecto a los metadatos definidos por un cliente CON, se crea una suma de comprobación a nivel de bloque para cada archivo cargado. Esto garantiza que la copia maestra de lo que reside en el servidor original de la CON sea siempre válida.

Una vez detectado el archivo request.xml en el punto de publicación, se lee, y si se cargan los archivos de medios, se mueven al servidor original tras comprobar su integridad. Por otro lado, si el URL de los archivos de medios indica un servidor en las instalaciones del cliente, estos archivos se descargan en el punto de publicación y luego en el servidor original de la infraestructura CON del proveedor de servicios . Todos los archivos están ahora bajo el control de la infraestructura CON aunque todo el control de metadatos sobre contenedores y archivos individuales es con el cliente CON. Esto garantiza que el cliente CON tenga un control completo sobre la duración durante la que el contenido es válido y también la ubicación geográfica en la que puede mostrarse el contenido. Los meta datos permiten a un cliente CON añadir, eliminar y actualizar archivo(s) de contenido.

Tras procesar los archivos, el proceso de monitorización genera un archivo responses.xml en el mismo directorio. Esto notifica al cliente CON si el contenido cargado en el punto de publicación se introdujo satisfactoriamente. Además, el cliente CON obtiene el/los URL de la CDN del contenido cargado.

A continuación , el publicador de contenido mueve los archivos cargados junto con la comprobación de integridad a nivel de bloque al servidor original. Cualquier nodo de extremo que solicite contenido realizará la petición al servidor original. Lo mismo se aplica si el

contenido se descarga desde el servidor original mediante cualquiera de los nodos de extremo CON que proporcionan el contenido a un cliente CDN solicitante.

Los nodos de extremo tienen una lista de contenedores y archivos junto con información de suma de comprobación a nivel de bloque del gestor CDN (a través del rastreador). Cuando los usuarios finales solicitan un archivo de contenido, el nodo de extremo entra en contacto con el servidor original. El servidor original (u otros nodos de extremo en el mismo centro de datos) proporcionan el contenido solicitado. El nodo de extremo receptor verifica la integridad a nivel de bloque del archivo descargado. Una vez verificada, el nodo de extremo proporciona el contenido alla los usuario(s) final(es) solicitante(s).

-

Interacción CON entre sus componentes de núcleo:

La infraestructura CON consiste en una diversidad de componentes: rastreador, servidor de topología, nodos de extremo, servidor de publicación, servidor original y punto de entrada. Un cliente CON puede interaccionar con la infraestructura CON del proveedor de servicios sólo en el servidor de publicación.

La comunicación entre cada una de las entidades CON se produce a través de RPC. Los RPC pueden adoptar cualquiera de los de los siguientes formatos: XML, binario, json, llamada API REST, etc. con HTIP como mecanismo de transporte.

En esta sección, se describe la interacción entre las entidades de la infraestructura CDN.

Interacción entre el gestor CDN y el rastreador: Cualquier cambio en los meta datos de un contenedor (o el archivo en un contenedor) por un cliente CON se refleja en el gestor CON inmediatamente. Dado que el rastreador sincroniza los contenedores con el gestor CON periódicamente, cualquier cambio en los metadatos de contenedor se refleja en el rastreador en cuestión de segundos. El rastreador también se sincroniza con los nodos de extremo con frecuencia. Así, cualquier cambio en los metadatos del contenedor (o cualquier archivo en un contenedor) en el gestor de contenido se propaga a los nodos de extremo en un tiempo muy corto (décimas de segundo).

La base de datos de geolocalización, geodb (y cualquier cambio en la geodb) se propagan al rastreador periódicamente. La información de geodb se envía a los nodos de extremo para realizar geobloqueo.

Interacción entre rastreador y servidor de topología: Los rastreadores mantienen una conexión abierta con el servidor de topología. El rastreador busca información sobre (1) las particiones (o subredes), denominadas pidlocdb y (2) la matriz de costes (denominada costmatrix) entre particiones (o sub redes). El servidor de topología tiene una visión global por rastreadores distribuidos geográficamente en un OB. Los ISP pueden definir sus políticas de encaminamiento a través del servidor de topología. El servidor de topología puede recomendar determinadas rutas al rastreador sobre otras dependiendo del coste de

5 enviar datos a través de las redes de tránsito, políticas de BGP o IGP y la carga actual sobre los enlaces. Esta información está contenida en la matriz de costes entre particiones.

Interacción entre los nodos de extremo CON y el servidor de registro temporal: Periódicamente, todos los registros temporales de acceso a contenido en cada nodo de extremo de un 08 se reenvían al servidor de registro temporal. Estos archivos de registro

10 temporal se procesan para mantener la contabilidad para los clientes CON y para monitorizar el tráfico de nodo de extremo en la CON.

Interacción entre rastreador y servidor DNS TLD: El rastreador recibe un archivo que contiene información sobre regiones (denominado regionsdb) desde el servidor ONS TLO. Esta información de regiones se pasa al nodo de extremo periódicamente o cuando se

15 actualiza. Esta información es útil para un nodo de extremo para (1 ) realizar geobloqueo y

(2) determinar la región de una petición que se origina.

Si la región de la petición que se origina no es la misma que la del nodo de extremo, el nodo de extremo devuelve un HTTP 302 mientras codifica la región como parte del URL (usando la regionsdb obtenida del servidor ONS TLO).

20 Interacción entre rastreador y nodos de extremo: El rastreador se sincroniza con los nodos de extremo regularmente. El rastreador actualiza los nodos de extremo con la siguiente información regularmente: (1) lista de todos los metadatos de contenedores, (2) pidlocdb, una tabla de PIO, (3) regionsdb, información sobre regiones en la CON, (4) geodb, la base de datos de geolocalización, (5) costmatrix, el coste de transferir datos entre dos PIO

25 y (6) lista de IP de entorno. Cualquier cambio en los metadatos de contenedor de un cliente se propaga al rastreador. El cambio en los metadatos de contenedor también se propaga a los nodos de extremo en cuestión de segundos. Esto garantiza que cualquier cambio que realice un cliente CON en sus archivos en un contenedor de contenido tenga un efecto casi inmediato sobre su distribución.

30 Todos los nodos de extremo mantienen una conexión abierta con el rastreador. El rastreador recopila estadísticas de uso (cpu, disco, cuenta de conexión) y archivo (bytes transferidos entrantes/salientes) detalladas en cada nodo de extremo. Usa esta información para equilibrar en carga conexiones a través de nodos de extremo tras determinar los nodos de extremo que tienen el contenido solicitado al ejecutar una función hash consistente sobre

35 el archivo solicitado.

El rastreador también ayuda al nodo de extremo a mantener una lisia actualizada de todos sus vecinos. Un nodo de extremo puede solicitar al rastreador que actualice su lista de vecinos. En respuesta, el rastreador envía una lista de direcciones IP de entorno y sus estadísticas de archivo. Esto permite a un nodo de extremo determinar cuál de los nodos de extremo en su entorno está mejor colocado para enviar el contenido solicitado (en vez de acudir al servidor original para recuperar el contenido) por un usuario final.

Interacción entre nodos de extremo en el mismo centro de datos: Los nodos de extremo en el mismo centro de datos informan a sus vecinos de la disponibilidad de contenido descargado recientemente. Por tanto, otros nodos de extremo descargan el contenido (en caso necesario) de (un) punto(s) de extremo en el mismo centro de datos que tiene(n) el contenido reduciendo así la carga en el servidor original. Esto se denomina comunicación de igual a igual (dado que están implicados los nodos de extremo en el mismo centro de datos).

En la figura 4, la etiqueta 1 corresponde a la interacción del cliente CON con la infraestructura CON del proveedor de servicios. Las etiquetas 1 a y 1 b corresponden a datos que están descargándose en el servidor original de la infraestructura CON.

-

Interacción del usuario final con la infraestructura CDN del proveedor de servicios:

A continuación, se describe cómo funciona el servicio de nombres de dominio (ONS) para una CON del proveedor de servicios. Ésta es la primera etapa para una CON en la identificación del nodo de extremo mejor colocado para proporcionar el contenido solicitado a un usuario final. Una vez identificado el nodo de extremo, obtiene el contenido solicitado de o bien el servidor original o bien otro nodo de extremo en el mismo centro de datos. A continuación se describe con más detalle todo el proceso:

Los usuarios finales en una casa no se comunican directamente con un sistema de resolución de ONS. En su lugar, la resolución de ONS se produce de manera transparente independientemente del programa de aplicación que ejecuta un usuario. La resolución de ONS se produce en las siguientes etapas: (1) el programa solicitante envía una petición de resolución de dirección al sistema de resolución de ONS en el sistema operativo local. Si la memoria caché local contiene la respuesta, el sistema de resolución devuelve el valor en la memoria caché al programa solicitante. (2) Si la memoria caché no contiene la respuesta, el sistema de resolución enviará la petición al servidor ONS designado de la organización. Para la mayoría de los usuarios domésticos, el ISP al que se conecta la máquina provee al servidor ONS (o sistema de resolución). (3) El sistema de resolución de ONS del ISP intentará resolver la dirección IP en primer lugar en su memoria caché local o realizar una

petición al servidor DNS raíz. Así, la dirección IP recibida por cualquiera de los TLD no es la dirección IP del cliente, sino la del sistema de resolución de DNS delISP. Cualquier sistema de resolución de DNS está configurado con direcciones conocidas de servidores raíz. Una consulta a uno de los servidores raíz devolverá el servidor

5 autorizado para el dominio de nivel superior (TLD). En el caso de la invención propuesta, el servidor DNS raíz devolverá el servidor autorizado para el dominio .nel. Como etapa siguiente, se consulta al servidor DNS TLD respecto al servidor autorizado para el dominio de segundo nivel (en el caso de la invención, es el dominio t-cdn.net). A continuación se explica la interacción etiquetada posterior de la figura 5:

10 (O) El usuario realiza una petición para un vídeo bucket id.tcdn.neVbucket_id/video01.flv. Para simplificar la explicación, fíjese bucket_id = 87. La petición tendrá ahora el aspecto 87.tcdn.neV87/video01.flv.

(1) El sistema de resolución de DNS de ISP consulta al servidor DNS TLD el 15 dominio .net para resolver el dominio t-cdn.net.

(2)

El servidor de nombres .net responde con la dirección IP del servidor autorizado para el dominio t-cdn.net.

(3)

El servidor DNS autorizado para el dominio de segundo nivel, t-cdn.net

deduce en primer lugar que 87.t-cdn.net es un alias para 87.g.t-cdn.net. Así, 20 se realizará una consulta para el dominio g.t-cdn.net.

(4

) Para resolver la subzona, usa su geobase de datos de IP.

(5)

El servidor DNS autorizado para el dominio t-cdn.net resuelve la subzona del sistema de resolución de DNS de ISP. En el ejemplo de esta invención, el servidor DNS autorizado para el dominio de segundo nivel responde con

25 la subzona del cliente como "es" (para España). El servidor DNS resuelve que la dirección IP en la subzona es eS.t-cdn.net.

(6) El servidor DNS eS.t-cdn.net es el servidor DNS autorizado para la subzona "es". El sistema de resolución de DNS de ISP intentará entonces resolver 87.es.t-cdn.net consultando al servidor DNS autorizado en la subzona.

30 (7) El servidor DNS autorizado en la subzona tiene una lista de todos los nodos de extremo. Reenvía la petición a uno cualquiera de los nodos de extremo usando o bien un esquema round-robin o bien un esquema de geolocalización de mejor esfuerzo que intenta hacer coincidir la petición con el nodo de extremo más cercano de {nodo de extremo 1, nodo de extremo

35 2, nodo de extremo 3, .. , nodo de extremo N}

(8)

El nodo de extremo 2 recibe la petición. El nodo de extremo realiza una geolocalización de grano fino sobre la dirección IP solicitada e identifica la ubicación como SeN. Esto implica que un nodo de extremo en el centro de datos de SeN puede ser el más adecuado para proporcionar contenido al usuario final solicitante.

(9)

El nodo de extremo 2 realiza una función hash consistente sobre el URL solicitado (en este caso, "87/video01.f1v"). A continuación, el nodo de extremo 2 devuelve HTIP 302, Moved Location (ubicación movida) abI8.bcn.es.t-cdn.net donde abl8 = sub-string(MD5(URL)). La respuesta de HTTP se devuelve al usuario final.

(10)

El usuario final envía una petición de resolución de dirección para abf8.bcn.es.t-cdn.net.

(11)

El sistema de resolución de DNS de ISP reenvía la petición de resolución de dirección desde el cliente al sistema de resolución de DNS en la subzona "es".

(12)

Se identifica el centro de datos/PoP (en SeN). Ahora se envía la petición de resolución de dirección al rastreador.

(13)

El rastreador realiza una función hash consistente sobre abf8 para obtener {nodo de extremo 3, nodo de extremo 2 y nodo de extremo N} como nodos de extremo que pueden atender de la mejor manera la petición.

(14)

El rastreador tiene en cuenta la carga actual en los nodos de extremo e identifica el nodo de extremo 3 como el más adecuado para proporcionar contenido. La respuesta del rastreador que identifica el nodo de extremo 3 se devuelve al sistema de resolución de DNS autorizado en la subzona "es".

(15)

El sistema de resolución de DNS de subzona "es" reenvía la respuesta al sistema de resolución de DNS de ISP.

(16)

El sistema de resolución de DNS de ISP devuelve la respuesta al usuario final.

(17)

El usuario final intentará ahora conectar directamente con el nodo de extremo 3.

Si el nodo de extremo 3 no tiene el contenido solicitado, intentará obtener el contenido de uno cualquiera de los demás nodos de extremo de entorno en el mismo centro de datos (si ya existe el contenido en uno de los nodos de extremo). Alternativamente, el nodo de extremo 3 volverá al servidor original para obtener el contenido solicitado y dar servicio al usuario final. Antes de proporcionar el contenido, el nodo de extremo también

puede comunicarse con un servidor de autenticación en el propietario de contenido si se especifica en los metadatos del contenedor. En resumen, todo el proceso de resolución implica dos consultas: una consulta al servidor DNS en el dominio de segundo nivel t-cdn.net para identificar el centro de datos

5 más cercano al cliente solicitante. Esta etapa implica un mensaje de redirección HTTP y reescritura de URL desde uno de los nodos de extremo en la infraestructura CDN que se elige para tratar la consulta. En la segunda etapa, se realiza una consulta al DNS para identificar el nodo de extremo en el centro de datos más cercano al cliente que puede proporcionar el contenido de la mejor manera. Como parte de este procedimiento, la petición

10 de ONS se reenvía al rastreador que usa una función hash consistente para identificar el contenido y a continuación usa el conocimiento estadístico de los nodos de extremo para devolver un conjunto de nodos de extremo (en orden, con el primer nodo de extremo mejor colocado, etc.) para proporcionar de la mejor manera el contenido al usuario final solicitante. Obsérvese que el servidor ONS autorizado para el dominio t-cdn.net también puede

15 estar autorizado para la subzona "es". En tal caso, el servidor ONS detecta que e intentará enviar la consulta al ONS a uno de los nodos de extremo para resolver en primer lugar el centro de datos más cercano que puede atender de la mejor manera la petición.

Ventajas de la invención: 20 Esta invención proporciona las siguientes características:

•

La solución está diseñada para funcionar en un hardware común. Además, la solución obvia la necesidad de equilibradores de carga caros y cualquier elemento de red de tecnología avanzada.

•

La resolución de ONS y el equilibrado de carga para distribución de contenido

25 está desacoplada. Esto facilita distinguir entre un servidor de contenido sobrecargado y un servidor ONS sobrecargado.

• La invención permite al proveedor de servicios CON añadir rastreadores y nodos de extremo según sea necesario, haciendo que la infraestructura CON de la invención pueda ajustarse muy bien a escala.

30 • La invención muestra cómo la infraestructura CON puede añadir fácilmente 08 adicionales.

•

La arquitectura CON tiene un número pequeño de entidades globales. Se despliegan varias otras entidades segun el 08.

•

La entidad global, el gestor CON se encarga de lo siguiente:

8. Asignar un id de contenedor globalmente único. Un cliente CON puede tener tantos contenedores como se desee.

b. Asignar id de 08 globalmente únicos. Por tanto, se invoca el gestor CON cuando se crea un nuevo OB.

5 • La CON incorpora el coste de red mas reciente en la identificación de nodos de extremo que son los mejor ubicados para proporcionar contenido a los usuarios finales solicitantes basándose en el menor coste de red.

• La infraestructura CON de esta invención no requiere centros de datos muy grandes para el alojamiento. Los nodos de extremo pueden añadirse en centros

10 de datos pequeños según sea necesario. Dependiendo de en qué medida en su red el ISP quiere alojar los nodos de extremo, el centro de datos puede estar a un nivel de bloque o nivel de ciudad o al nivel de región. A diferencia de las CON tradicionales, la CON de esta invención está diseñada para ISP.

• Los nodos de extremo pueden colocarse en la misma ubicación que los

15 OSLAM. La ubicación física de los OSLAM facilita ubicar el contenido cerca de los usuarios finales.

• El rastreador se comporta como un equilibrador de carga a nivel de archivo para los puntos de entrada que obvia la necesidad de que otro hardware se comporte como un equilibrador de carga.

20 Un experto en la técnica puede introducir cambios y modificaciones en las realizaciones descritas sin apartarse del alcance de la invención tal como se define en las reivindicaciones adjuntas.

SIGLAS

AOSL

5

CON

ONS

TLO ONS

PoP

MD5

10

08

PIO

TLO

URL

HTTP

15

VoO

ISP

FTP

TTL

MD5

20

LRU

API

Asymmetric Digital Subscriber Line; Línea de abonado digital asimétrica Content Distribution Network; Red de distribución de contenido Domain Name Service; Servicio de nombres de dominio Top Level Domain DNS; DNS de dominio de nivel superior Point of Presence; Punto de presencia Message-Digest algorithm 5; Algoritmo de resumen del mensaje 5 Qperating Business; Unidad de negocio Partition ID; ID de partición Top LeveJ Domain; Dominio de nivel superior Universal Record Locator; Localizador universal de registro HyperText Transporf Protocol; Protocolo de transporte de hipertexto Video on Demand; Vídeo bajo demanda Internet Service Provider; Proveedor de servicios de Internet Fije Transfer Protocol; Protocolo de transferencia de archivos Time To Uve; Tiempo de vida Message Digest algorithm 5; Algoritmo de resumen del mensaje 5 Least Recently Used; Menos recientemente usado Application Programming Interface; Interfaz de programación de aplicaciones

BIBLIOGRAFíA

[1] Red de distribución de contenido. En http://en.wikipedia.org/wiki/Content deliverv network

[2] C. Huang, J. Li, Angela Wang y KW. Ross, Understanding Hybrid CDN-P2P: Why

Limelight Needs its Own Red Swoosh , NOSSDAV, Braunschweig, Alemania, 2008

Claims (21)

1. REIVINDICACIONES

   1. Sistema para gestionar la infraestructura de un servicio de red de distribución de contenido en una red ISP, caracterizado porque comprende:

   5 -un gestor CDN de una red de distribución de contenido que aloja una o más interfaces de programación de aplicaciones API para administrar una o más regiones en una unidad de negocio u OB, al menos añadiendo y/o borrando dichas regiones de dicho 08 usando dichas API , en donde dichas API de un proveedor de servicios CON están seleccionadas de al

   10 menos un grupo que comprende:

   -

   una API de gestión de contenido que permite a dicho proveedor de servicios CDN proporcionar a los propietarios de contenido las herramientas para gestionar su contenido,

   -

   una API DNS que permite la configuración de servidores DNS en regiones 15 nuevas, y nombres de componentes CDN ambos en la misma región que dicho servidor DNS ya nivel de 08, y

   -

   una API de topología de red que permite al proveedor de servicios CDN definir su visión de topología de red , o bien en detalle o como una abstracción de alto nivel de la red subyacente.

2. 2. Sistema según la reivindicación 1, caracterizado por que dichas API son API web basadas en una comunicación de tipo REST con mensajes de petición y respuesta definidos.

   25 3. Sistema según la reivindicación 1, caracterizado por que dicha API DNS se proporciona por un gestor de DNS alojado en el gestor CDN , siendo dicho gestor de DNS el punto de entrada de un servidor DNS TLD y servidores DNS de región.
3. 4. Sistema según la reivindicación 3, caracterizado por que dicho servidor DNS TLD y

   30 servidores DNS de región están configurados por medio de dicho gestor de DNS, mediante al menos la adición de nombres y regiones.
4. 5. Sistema según la reivindicación 1 ó 3, caracterizado por que comprende un administrador de 08 o administrador de región que llama a dicha API DNS para añadir

   35 un componente CDN en una región existente o añadir un servidor DNS en una nueva región .
5. 6. Método para gestionar la infraestructura de un servicio de red de distribución de contenido en una red ISP, caracterizado porque comprende utilizar un gestor CDN de una red de distribución de contenido que aloja una o más interfaces de programación de aplicaciones API destinadas a administrar una o más regiones en una unidad de

   5 negocio u OB, al menos añadiendo y/o borrando dichas regiones en dicho 08 usando dichas API por un proveedor de servicios CDN.

6. 7.

   Método según la reivindicación 6, caracterizado por que comprende gestionar negocios operativos distribuidos geográficamente usando dicho gestor CON.

7. 8.

   Método según la reivindicación 6, caracterizado por que una API de gestión de contenido proporciona todos los procedimientos necesarios para gestionar el contenido que va a entregarse a través de la CON en forma de contenedores con metadatos asociados, incluyendo procedimientos para crear, borrar, recuperar y

   15 actualizar dichos metadatos de contenedor y/o procedimientos para enumerar archivos en un contenedor, añadir archivos a y borrar archivos de un contenedor y procedimientos para definir y actualizar metadatos para distribución de contenido.
8. 9. Método según la reivindicación 6, caracterizado por que comprende asignar un ID

   20 de región para una nueva región en un 08 por medio de un administrador de OB y, llamar a una API ONS, una vez configurados todos los elementos de una región dentro de un OB, para asociar la nueva región con un servidor DNS TLO para permitir a este último resolver una petición destinada a una región en un 08.

   25 10. Método según la reivindicación 9, caracterizado por que comprende, cuando se

   borra una región llamando a la API ONS, que el gestor de ONS:

   -

   borre la región en el servidor ONS TLO,

   -

   elimine todos los registros de NS y A de la región recién eliminada,

   -

   borre todos los rangos de dirección IP que pertenecen a la región borrada; y 30 -borre todos los nombres en una región en el servidor ONS de regiones.

9. 11 . Método según la reivindicación 9, caracterizado por que comprende crear, modificar o borrar nombres y regiones en una CON del proveedor de servicios usando dicha API DNS.
10. 12. Método según la reivindicación 9, caracterizado por que comprende usar dicha API ONS para realizar al menos uno de:

    -crear entidades en un 08 o una región en un 08; -un GET sobre el procedimiento de nombres para enumerar todas las entidades en un 08; -procedimientos que usan un ID de regiones para recuperar, actualizar y borrar

    5 información sobre una entidad de red ; -crear una región, recuperar la lista de regiones actuales, recuperar información sobre la región, actualizar la información de región y borrar una región; y -procedimientos para recuperar la base de datos de regiones, incluyendo todos

    10 los rangos de IP en una región a partir de un servidor DNS regional, y toda la base de datos de regiones, incluyendo todos los prefijos IP en todas las regiones a partir del servidor DNS TLD.
11. 13. Método según cualquiera de las reivindicaciones 6 a 12, caracterizado por que

    15 comprende especificar un gráfico de topología de red lógica desde el punto de vista de un operador de red, abstrayendo conexiones físicas en particiones lógicas que contienen subredes usando una APl de topología de red .
12. 14. Método según la reivindicación 13, caracterizado por que dichas particiones están

    20 enlazadas entre sí con bordes que tienen pesos asociados con los mismos, indicando dichos pesos el coste de transferir datos sobre el enlace que conecta las dos particiones.
13. 15. Método según la reivindicación 13 ó 14, caracterizado por que comprende crear

    25 una nueva subred, borrar una subred existente y recuperar un conjunto de subredes usando dicha API de topología de red .
14. 16. Método según la reivindicación 13, 14 ó 15, caracterizado por que comprende usar dicha API de topología de red para al menos uno de:

    30 -crear un objeto de partición que devuelve un ID de partición, o PIO que tiene asociado con el mismo, una descripción y un nombre o etiqueta, -añadir 5ubredes a un PID, -borrar subredes de un PIO, -recuperar todas las subredes que pertenecen a un PIO,

    35 -recuperar toda la lista de pares de partición-subred , -devolver un conjunto de particiones, -actualizar un PIO, y -borrar un PID.
15. 17. Método según la reivindicación 14, caracterizado por que comprende usar dicha

    API de topología de red para al menos uno de: -obtener toda la matriz de costes que define el coste entre cada par de partición que está conectado mediante un enlace, -crear, actualizar y recuperar el coste entre dos PID; -recuperar todos los bordes con un PID de origen dado, y -recuperar todos los bordes respecto a un PIO de destino.

16. 18.

    Método según cualquiera de las reivindicaciones anteriores 6 a 17, caracterizado por que comprende proporcionar un ID único a un contenedor de cliente CDN cuando se crea un contenedor de contenido por el cliente CON usando dicho gestor CON.

17. 19.

    Método según cualquiera de las reivindicaciones anteriores 6 a 18, caracterizado por que comprende usar dicho gestor CON para interaccionar con un rastreador CDN para sincronizar periódicamente contenedores de modo que cualquier cambio en los metadatos de un contenedor o un archivo en un contenedor se refleje en el rastreador en segundos, y viceversa.

18. 20.

    Método según cualquiera de las reivindicaciones 13 a 17, caracterizado por que comprende que dicho gestor CON use dicha API de topología de red como una interfaz con un servidor de topología de dicho 08 para definir o bien una región y/o bien una visión a nivel de 08 de topología de red, o bien en detalle o bien como una abstracción de la red subyacente.

19. 21.

    Método según la reivindicación 20, caracterizado por que comprende usar dicho servidor de topología a través de dicha API de topología de red en el gestor CON, para describir la topología a un nivel de 08 y/o crear una abstracción para la topología en una región y/o crear una abstracción para conectar dos regiones dentro del mismo 08 y/o crear una abstracción de la topología que conecta múltiples 08.

20. 22.

    Método según la reivindicación 20 ó 21 , caracterizado por que dicho servidor de topología proporciona un servicio adaptado a la topología que tiene información sobre la topología de red visto desde el 08 en el que opera y/o información sobre políticas de encaminamiento de 08 entre prefijos IP y/o mantiene información sobre las redes de tránsito y el coste de atravesar enlaces.

21. 23.

    Método según cualquiera de las reivindicaciones 20 a 22, caracterizado por que comprende usar dicho servidor de topología, a través de dicha API de topología de red de gestor CDN, para ayudar a un rastreador CDN a seleccionar la trayectoria de menor coste, según se define por una de dichas políticas de encaminamiento de OB, en caso de que haya múltiples trayectorias entre una fuente de contenido y un usuario final solicitante.