ES A2 ESPAÑA 11. Número de publicación: Número de solicitud: H04L 12/00 ( )

Transcripción

1 19 OFICINA ESPAÑOLA DE PATENTES Y MARCAS ESPAÑA Número de publicación: Número de solicitud: Int. CI.: H04L 12/00 (06.01) 12 SOLICITUD DE PATENTE A2 22 Fecha de presentación: Fecha de publicación de la solicitud: Solicitantes: TELEFÓNICA, S.A. (0.0%) C/ GRAN VÍA, MADRID ES 72 Inventor/es: ASTIZ LEZAUN, Eguzki; BARTHEL, Mattias; CHHABRA, Parminder; GARCIA MENDOZA, Armando Antonio; LAOUTARIS, Nikolaos; PANDO CAO, Arcadio; RODRIGUEZ RODRIGUEZ, Pablo; SAURIN PARRA, Alvaro y YANG, Xiaoyuan 74 Agente/Representante: ARIZTI ACHA, Monica 4 Título: SISTEMA Y MÉTODO PARA GESTIONAR LA INFRAESTRUCTURA DE UN SERVICIO DE RED DE DISTRIBUCIÓN DE CONTENIDO EN UNA RED ISP ES A2 7 Resumen: 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.

2 SISTEMA Y MÉTODO 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 CDN que aloja interfaces 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. 1 2 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 CDN 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 CDN 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é. 2

3 1 2 3 Con Amazon Cloudfront, el cliente en primer lugar crea un contenedor S3 que servirá como servidor original para el contenido. El cliente pone entonces el contenido en el contenedor S3 y convierte el contenido en públicamente legible. Como siguiente etapa, el cliente CDN crea una distribución cloudfront y la infraestructura genera un ID de distribución único y un nombre de dominio cloudfront. El cliente CDN 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 HTTP 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. Limelight 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 DNS de 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 DNS privada de Limelight. Limelight 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 CDN 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 DNS y el equilibrado de la carga se acoplan. Esto hace difícil distinguir entre un servidor de contenido sobrecargado y un servidor DNS sobrecargado. 3

4 1 (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. () 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 máquinas 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 más reciente cuando se encuentran enlaces de red que están 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. 2 3 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 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 OB usando dichas API, en donde dichas API de un proveedor de servicios CDN están seleccionadas de al menos un grupo que comprende: 4

5 1 - 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 nuevas, y nombres de componentes CDN ambos en la misma región que dicho servidor DNS y a nivel de OB, 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. Otras realizaciones del sistema del primer aspecto de la invención, se describen según las reivindicaciones 2 a 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 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 negocio u OB, al menos añadiendo y/o borrando dichas regiones en dicho OB usando dichas API por un proveedor de servicios CDN. Otras realizaciones del método del segundo aspecto de la invención, se describen según las reivindicaciones 7 a 23 adjuntas, y en una sección posterior relacionada con la descripción detallada de varias realizaciones. 2 3 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 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. Sistema de resolución de DNS 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 DNS mantenido por el ISP. El sistema de resolución de DNS de ISP enviará la petición de DNS a uno o más servidores DNS dentro del dominio administrativo del ISP. Contenedor: Un contenedor es un compartimento lógico para un cliente. Un contenedor o bien establece un enlace entre el URL del servidor original y la URL de la CDN

6 1 2 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 asociados con el mismo. Estos atributos 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, etc. 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 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 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 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. MD: En criptografía, MD es una función criptográfica usada ampliamente con un valor de hash de 128 bits. MD se usa ampliamente para probar la integridad de los archivos. MD se expresa normalmente como un número hexadecimal. OB (Unidad de negocio): Un OB es un área geográfica arbitraria en la que está instalada la CDN de un TID. Un OB puede operar en más de una región. Una región es un área geográfica arbitraria y puede representar un país, o parte de un país o incluso un conjunto de países. Un OB puede estar compuesto por más de una región. Un OB puede estar compuesto por uno o más ISP. Un OB tiene exactamente una instancia de DNS y servidor de topología. 6

7 1 2 3 PID (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. DNS (Servicio de nombres de dominio): DNS es un servicio que traduce nombres de dominio en direcciones IP. 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. CDN (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): HTTP 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 HTTP 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 7

8 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 OB 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 CDN del proveedor de servicios. Cada unidad de negocio (OB) utiliza una CDN 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 CDN 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 CDN del proveedor de servicios. Más exactamente, esta figura muestra todas las interacciones de un cliente CDN, usuarios finales y las interacciones entre los componentes de la infraestructura CDN, según una realización del método y la infraestructura de la invención. La figura muestra una resolución de DNS en una infraestructura CDN del proveedor de servicios según una realización del primer aspecto de la invención. En total, la resolución de DNS implica dos consultas al DNS y un redirección HTTP. 8

9 1 2 3 Descripción detallada de varias realizaciones La infraestructura CDN del proveedor de servicios 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 CDN según el método y el escenario de despliegue de la infraestructura CDN de la invención puede estar muy dentro en una red ISP. Esto permite al ISP 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 DSLAM. El objetivo de una CDN 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 CDN que interaccionan entre sí según las diversas realizaciones de la invención para el despliegue de una infraestructura CDN. Para una realización de la invención, la infraestructura CDN del segundo aspecto y también descrita en el método del primer aspecto comprende elementos CDN que son parte de un escenario de despliegue de OB típico. Otras realizaciones de la invención son: el despliegue de elementos CDN en una región, un escenario de despliegue de OB 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 OB 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 OB. Para otra realización, el método comprende prever etapas para la interacción entre diferentes tipos de elementos CDN, el cliente CDN (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 CDN. También se detalla un escenario de despliegue de un OB y como puede extenderse el despliegue a múltiples OB. La descripción incluye 9

10 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 CDN del proveedor de servicios. Descripción de elementos CDN individuales En este caso, se describe la función de cada uno de los elementos CDN. 1 2 Punto de entrada (punto de publicación): Cualquier proveedor de servicios de un cliente de la CDN puede interaccionar con la infraestructura CDN únicamente a través del punto de entrada. El punto de entrada ejecuta una interfaz de servicios web para crear/actualizar sus cuentas CDN y para crear/borrar y actualizar contenedores para su cuenta. Cada contenedor tiene asociado con el mismo metadatos de dos clases, metadatos de sistema de archivos de tipo Unix y metadatos de distribución de contenido. El cliente 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 CDN puede cargar un archivo de contenido junto con metadatos a nivel de archivo. Un cliente puede crear dos clases de contenedores: VoD para contenido de vídeo bajo demanda y en tiempo real para transmitir en flujo continuo contenido en tiempo real. Para el contenido de VoD, un cliente CDN 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 CDN. Los datos se descargan entonces para su procesamiento por el punto de publicación CDN. Posteriormente, el archivo descargado se mueve a otro directorio para su posprocesamiento. Para distribuir contenido en tiempo real, el cliente CDN simplemente proporciona el URL del flujo continuo en tiempo real como un parámetro de metadatos al contenedor en tiempo real. La infraestructura CDN se encarga de obtener el flujo continuo de contenido original y distribuirlo a los usuarios finales CDN. Gestor CDN: El gestor CDN aloja la API de gestor de contenidos, la API DNS y la API de topología de red (todas las API están en este servidor). Hay una instancia del gestor CDN para toda la CDN. El gestor CDN puede residir en uno de los puntos de publicación o en un servidor separado. El gestor CDN puede residir en OB0 o uno cualquiera de los OB. Nodo de extremo: Un nodo de extremo es la entidad que gestiona la comunicación entre los usuarios finales solicitantes y la infraestructura CDN. Esencialmente es un servidor HTTP personalizado.

11 1 2 3 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 lista de todos los archivos y contenedores en el OB. 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 HTTP 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 (MD 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 11

12 1 2 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 OB en el que opera. Cada OB 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 servidor de topología ayuda al rastreador a seleccionar la trayectoria de menor coste (tal como se define mediante la política de OB) 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 real (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. Servidor DNS: El servidor DNS proporciona la resolución de nombres dentro de la infraestructura CDN. El DNS raíz reenvía una consulta para t-cdn.net al servidor DNS que está autorizado para el dominio de nivel superior (TLD). Una consulta posterior al servidor DNS 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. Servidor de registro temporal: Archivos de registro temporal HTTP 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 CDN. A continuación, se describen las entidades que son parte del despliegue CDN. 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 CDN. 3 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 12

13 1 2 rastreador, un servidor DNS que está autorizado para un OB, un punto de publicación (que comprende tanto el gestor CDN 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 CDN, un servidor de registro temporal para 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 OB. Además, el TLD para la CDN también puede residir dentro de un OB. Los requisitos para el despliegue de un OB se resumen tal como sigue: (1) Las subredes de DNS TLD 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 OB). (4) Una región debe tener exactamente un rastreador y servidor DNS autorizado para esa región. () Dos OB pueden tener el mismo ID de región. El administrador CDN en un OB asigna ID de región dentro de cada OB (un OB puede tener varias regiones). 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 subredes y una subred incluye todas las demás (una subred no puede estar incluida sólo parcialmente; o bien está 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 B pertenecen a las regiones R A y R B, entonces cualquier IP de la subred B pertenecerá sólo a la región B, y no a la región A. (9) Se define una región 0 por defecto para cada OB. Se asigna a la región 0 una dirección IP que no está en ninguna subred IP del OB. El servidor DNS TLD se encarga de reenviar las peticiones de los usuarios finales al servidor DNS del OB apropiado. 13

14 Por tanto, tal como se explicó anteriormente, un OB puede tener tantos rastreadores y servidores DNS como número de regiones en un OB. Los servidores DNS de un OB están autorizados sólo en la región en la que operan (un servidor DNS por región). 1 Despliegue a través de múltiples OB: La figura 2 muestra un despliegue de la CDN con tres OB. Cada despliegue funciona como una CDN independiente. Los enlaces marcados con 0 son enlaces de red principal que conectan los OB con grandes encaminadores de núcleo en Internet. Las etiquetas en OB1 se explican tal como sigue: la etiqueta 1 es el punto de publicación (también 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 1b). Tras ejecutar una función hash consistente en la petición, el rastreador 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 CDN también contiene un elemento global, el servidor DNS TLD. O bien puede ser independiente o bien puede residir dentro de uno de los OB. El gestor CDN reside con el servidor de publicación en uno de los OB (ya que hay una instancia del gestor CDN para la CDN). 2 3 Descripción de la región cero (entidades globales) Cada OB debe fijar una región 0 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 0 (región cero). La región cero es una región global por defecto. Tiene un rastreador para coordinar 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 regiones no están definidas apropiadamente. 14

15 1 2 Definiciones de API Tal como se indicó anteriormente, el método y el escenario de despliegue de la infraestructura CDN de la invención prevé el uso de un gestor CDN que aloja todas las API para la CDN. Esto permite a un proveedor de servicios CDN para un OB 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 CDN 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 entregará la CDN. 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 metadatos de distribución de contenido. Se definen dos clases de contenedores: (1) un contenedor VoD 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 VoD 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. 3 API DNS 1

16 1 2 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 CDN/OB y la infraestructura CDN. Hay un espacio de nombre para la CDN: t- cdn.net. El espacio de nombre se divide en OB. Un OB 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 OB 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, b.t-cdn.net pasará a ser b.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 0. El DNS TLD está en la región 0 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 0. El DNS TLD se encarga de reenviar las peticiones realizadas por usuarios finales a los servidores DNS de OB 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 DNS, 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 DNS TLD. El rastreador ejecuta las dos últimas llamadas API. API de topología de red 16

17 1 2 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 subredes. Las particiones se enlazan entre sí con bordes 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 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ón subred. 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, actualizar/crear un PID y borrar un PID. Bordes: Un borde de red define el coste de transportar una unidad de datos entre dos PID (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 PID se fija en un valor grande. La API 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 OB. Sólo se describe el punto de vista de OB de la topología de red. Como ejemplo, un OB en España crea una partición que define todas las subredes en los EE.UU. mientras que otro OB en Argentina crea particiones que definen todas las subredes de los EE.UU. 3 Método para añadir/borrar una región en un OB: Para la siguiente realización descrita, las API descritas anteriormente alojadas en el gestor CDN se usan para añadir y borrar regiones en un OB. 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 SQL en el servidor DNS TLD. Un administrador de OB asigna un ID de región para una nueva región en un OB. Una vez configurados todos los elementos de una región dentro de un OB, se invoca la API 17

18 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 OB, se invoca la API DNS. Esto tiene el 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 (iii) borrar todos los rangos de direcciones IP que pertenecen a la región borrada Descripción de la interacción con la CDN del proveedor de servicios: 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 CDN y (c) cómo proporciona una CDN contenido cuando un usuario final hace una petición de contenido alojado en la CDN. - Interacción del cliente con una infraestructura CDN del proveedor de servicios: A continuación se describen las interacciones del cliente CDN con la CDN del proveedor de servicios. La figura 3 muestra el diagrama secuencial de las interacciones entre el cliente CDN y la infraestructura CDN y entre diversos elementos de la infraestructura CDN al cargar contenido. El punto de entrada es el único punto de comunicación para un cliente CDN con una infraestructura CDN del proveedor de servicios. Un cliente CDN puede usar su cuenta para crear, eliminar y editar contenedores (un directorio o carpeta que contiene los archivos de contenido del cliente CDN). Un cliente CDN debe crear en primer lugar un contenedor de contenido dentro de la infraestructura CDN. El contenedor tiene un id globalmente único que ayuda al proveedor de servicios CDN a identificar a un cliente CDN. El gestor CDN 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 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 CDN puede añadir contenido mediante uno cualquiera de dos métodos: cargar contenido o proporcionar la dirección IP del servidor original del cliente CDN desde la que la infraestructura CDN puede descargar el contenido. El contenido se descarga en el punto de publicación. Antes de que el contenido se transfiera al servidor original, se 18

19 1 2 3 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 CDN 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 CDN, 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 CDN 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 CDN del proveedor de servicios. Todos los archivos están ahora bajo el control de la infraestructura CDN aunque todo el control de metadatos sobre contenedores y archivos individuales es con el cliente CDN. Esto garantiza que el cliente CDN 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 metadatos permiten a un cliente CDN 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 CDN si el contenido cargado en el punto de publicación se introdujo satisfactoriamente. Además, el cliente CDN 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 19

20 contenido se descarga desde el servidor original mediante cualquiera de los nodos de extremo CDN 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 al/a los usuario(s) final(es) solicitante(s) Interacción CDN entre sus componentes de núcleo: La infraestructura CDN 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 CDN puede interaccionar con la infraestructura CDN del proveedor de servicios sólo en el servidor de publicación. La comunicación entre cada una de las entidades CDN 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 HTTP 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 metadatos de un contenedor (o el archivo en un contenedor) por un cliente CDN se refleja en el gestor CDN inmediatamente. Dado que el rastreador sincroniza los contenedores con el gestor CDN 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