ES2433073T3 - Aplicación de políticas para gestionar un flujo de servicio - Google Patents

Aplicación de políticas para gestionar un flujo de servicio Download PDF

Info

Publication number
ES2433073T3
ES2433073T3 ES08719530T ES08719530T ES2433073T3 ES 2433073 T3 ES2433073 T3 ES 2433073T3 ES 08719530 T ES08719530 T ES 08719530T ES 08719530 T ES08719530 T ES 08719530T ES 2433073 T3 ES2433073 T3 ES 2433073T3
Authority
ES
Spain
Prior art keywords
service
address
user
server
flow management
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES08719530T
Other languages
English (en)
Inventor
Sylvain Monette
Martin Julien
Benoit Tremblay
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Application granted granted Critical
Publication of ES2433073T3 publication Critical patent/ES2433073T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/20—Traffic policing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2408—Traffic characterised by specific attributes, e.g. priority or QoS for supporting different services, e.g. a differentiated services [DiffServ] type of service
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Un método de aplicación de políticas de tráfico a un tipo de servicio proporcionado por un servidor a un dominiode usuario, el método que comprende los pasos de: proporcionar (210) una plantilla de servicio (300) que comprende una dirección del servidor, un identificador deprotocolo, y una o más políticas de tráfico; producir (220) un conjunto de gestión de flujo de servicio (400) añadiendo una dirección del dominio de usuario (460)a la plantilla de servicio; recibir (230) un paquete que comprende una dirección de origen, una dirección de destino, un tipo de protocolo, ydatos en relación con el tipo de servicio; identificar (240) el conjunto de gestión de flujo de servicio haciendo coincidir la dirección de origen, la dirección dedestino, y el tipo de protocolo con el conjunto de gestión de flujo de servicio; e intercambiar los datos entre el dominio de usuario y el servidor usando (250) la una o más políticas de tráfico.

Description

Aplicación de políticas para gestionar un flujo de servicio
Antecedentes de la invención
Campo técnico
La presente invención se refiere a un método y un nodo para identificar un tipo de servicio ofrecido por un servidor a un dominio de usuario y para aplicar políticas de tráfico al mismo.
Descripción de la técnica relacionada
Es bien conocido en la técnica que las redes de acceso permiten a los clientes tener acceso a contenidos de servidores. El método usado más frecuentemente para proporcionar contenido de los servidores a los clientes es mediante el uso de las denominadas conexiones de “mejor esfuerzo”. “Mejor esfuerzo” implica que la red de acceso no proporciona ninguna garantía de que un contenido deseado se entregará realmente, o que el contenido se entregará según una Calidad de Servicio (QoS) especificada, dentro de un retardo mínimo, o con una prioridad fijada. En una red de mejor esfuerzo cada cliente obtiene un servicio de mejor esfuerzo, lo que significa que obtiene una tasa de bit variable y un tiempo de entrega no especificados, dependiendo de la carga de tráfico actual.
La Figura 1 muestra una representación de la técnica anterior de una red de acceso 100 simple usada para proporcionar servicios desde un servidor 110 de un proveedor de servicios a un dominio de usuario 120. El dominio de usuario 120 puede constar de un único nodo, o puede comprender una pluralidad de dispositivos de usuario 22a, 22b, que constan por ejemplo de varios dispositivos de usuario 22a, 22b, en un mismo hogar. Todos los dispositivos de usuario 22a, 22b dentro del dominio de usuario 120 comparten una misma suscripción a la red de acceso 100 y a los proveedores de servicio. Dentro de la red de acceso 100, uno o más nodos de dominio de acceso 130, por ejemplo encaminadores de acceso, proporcionan una conexión de Protocolo de Internet (IP) directa a los dispositivos de usuario 22a, 22b. Los nodos de dominio de acceso 130 reenvían los datos de tráfico IP, así como las peticiones de servicio y las respuestas de servicio, entre el dominio de usuario 120 y el servidor 110. La Figura 1 está muy simplificada; aquellos expertos en la técnica reconocen fácilmente que una red de acceso 100 típica comprendería normalmente decenas o centenas de nodos de dominio de acceso 130 que sirven miles de dominios de usuario 120, y que proporcionan acceso a millones de servidores 110 en Internet.
Un usuario del dominio de usuario 120 puede solicitar un servicio según cualquiera de muchos tipos de servicios. Mientras que servicios tales como el Protocolo de Transferencia de Ficheros (FTP), o descargar de una página web mediante el uso del Protocolo de Transferencia de Hiper Texto (HTTP), se pueden servir favorablemente dentro de un simple tipo de mejor esfuerzo de red de acceso 100, otros servicios que requieren alto ancho de banda o baja latencia, tales como difusión en forma continua de vídeo y Voz sobre Protocolo de Internet (VoIP), son más demandantes en términos de Calidad de Servicio (QoS).
Actualmente, la versión 4 del Protocolo de Internet (IPv4), como se especifica en la Petición de Comentarios (RFC) 791 del Grupo de Trabajo de Ingeniería de Internet (IETF), transporta un parámetro de Tipo de Servicio (TOS) dentro de una cabecera de cada paquete IPv4. La RFC 2474 “Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers” además define posibles valores para el parámetro TOS. Es posible usar el parámetro TOS para indicar que un paquete de IPv4 se debería entregar con prioridad más alta, o con un retardo más bajo, que en una simple conexión de mejor esfuerzo. Todavía, los valores de TOS posibles están muy limitados en gama y no proporcionan unos medios para especificar a los encaminadores en una red, con un nivel alto de granularidad, los parámetros de QoS de demanda requeridos para algunos servicios de hoy en día.
La US 6.449.650 B1 se refiere a métodos y aparatos para configurar una red de comunicación usando plantillas de servicio que permiten aplicar reglas de tráfico para uso en una pluralidad de dispositivos de procesamiento de paquetes.
No hay actualmente medios eficientes para que un servidor 110 proporcione una definición única de servicios, permitiendo un uso de información avanzada acerca de los parámetros de QoS requeridos que pueden necesitar ser ejecutados tras la puesta en marcha de sesiones con dominios de usuario 120.
Compendio de la invención
Habría claras ventajas de tener un método y nodos para identificar servicios de una manera que aseguren que los parámetros de QoS de demanda se pueden imponer dentro de una red, a fin de proporcionar servicios mejorados entre servidores y dispositivos de usuario.
Es por lo tanto un objeto extenso de esta invención proporcionar un método y un nodo para identificar un servicio ofrecido por un proveedor de servicios, y para especificar parámetros de políticas de tráfico extremo a extremo relacionados.
Un primer aspecto de la presente invención se dirige a un método de aplicación de políticas a un tipo identificado de servicio proporcionado por un servidor a un dominio de usuario. Se prepara primero una plantilla de servicio, que comprende una dirección de un servidor, un identificador de protocolo, y una o más políticas de tráfico para uso en el manejo del tipo de servicio identificado. Entonces, se proporciona un conjunto de gestión de flujo de servicio completando la plantilla de servicio mediante la adición de una dirección de dominio de usuario. Según se recibe un paquete, que comprende una dirección de origen, una dirección de destino, y un tipo de protocolo, el paquete también que comprende datos en relación con el tipo de servicio identificado, se identifica el conjunto de gestión de flujo de servicio haciendo coincidir estas direcciones de origen y de destino, así como el tipo de protocolo, con las direcciones y el identificador de protocolo en el conjunto de gestión de flujo de servicio. Los datos se intercambian en un flujo de servicio entre el dominio de usuario y el servidor mediante el uso de la una o más políticas de tráfico.
Un segundo aspecto de la invención se dirige a una variante del método anteriormente en la presente memoria. Un nodo proveedor de servicios prepara una pluralidad de plantillas de servicio para una pluralidad de tipos de servicio. La producción del conjunto de gestión de flujo de servicio tiene lugar en respuesta a recibir una petición de servicio desde el dominio de usuario, la petición de servicio que significa un tipo servicio dado. Donde se reciben una pluralidad de peticiones de servicio desde el dominio de usuario, se producen distintos conjuntos de gestión de flujo de servicio, según los tipos de servicio identificados en la pluralidad de peticiones de servicio.
Un tercer aspecto de la presente invención se dirige a otra variante del método anteriormente en la presente memoria. Un nodo proveedor de servicios prepara dos o más plantillas de servicio para dos o más aspectos de una misma oferta de servicio. La producción de dos o más conjuntos de gestión de flujo de servicio tiene lugar en respuesta a recibir una petición de servicio desde el dominio de usuario, la petición de servicio que identifica la oferta de servicio.
Un cuarto aspecto de la presente invención se dirige a un nodo de dominio de acceso para aplicar políticas de tráfico a un flujo de servicio entre un dominio de usuario y un servidor. El nodo de dominio de acceso comprende una memoria para almacenar una plantilla de servicio. La plantilla de servicio comprende una dirección del servidor, un identificador de protocolo, y una o más políticas de tráfico. El nodo de dominio de acceso también tiene una lógica de control adaptada a producir un conjunto de gestión de flujo de servicio añadiendo una dirección del dominio de usuario a la plantilla de servicio. Dos dispositivos de entrada-salida, uno en un lado del servidor y uno en un lado del dominio de usuario, están adaptados para recibir paquetes de datos, cada paquete que comprende una dirección de origen, una dirección de destino, un tipo de protocolo, y datos. Un procesador de políticas identifica el conjunto de gestión de flujo de servicio haciendo coincidir la dirección de origen, la dirección de destino, y el tipo de protocolo con el conjunto de gestión de flujo de servicio, y aplica la una o más políticas de tráfico a los datos. Los paquetes entonces se reenvían hacia su destino mediante los dispositivos de entrada-salida.
En una realización la dirección del servidor, la dirección del dominio de usuario, la dirección de origen y la dirección de destino son direcciones del Protocolo de Internet (IP).
En una realización adicional, la dirección de origen es igual a la dirección del dominio de usuario, la dirección de destino es igual a la dirección del servidor, y el tipo de protocolo es igual al protocolo.
En una realización adicional, la dirección de destino es igual a la dirección del dominio de usuario, la dirección de origen es igual a la dirección del servidor, y el tipo de protocolo es igual al identificador de protocolo.
En una realización, el tráfico de datos se intercambia entre el dominio de usuario y el servidor mediante el uso de políticas comprendidas en dos o más conjuntos de gestión de flujo de servicio; y los dos o más conjuntos de gestión de flujo de servicio se basan en dos o más plantillas de servicio distintas, en donde los dos o más conjuntos de gestión de flujo de servicio están asociados con dos o más aspectos complementarios de una oferta de servicio, en donde la oferta de servicio puede ser un servicio de televisión, uno de los dos o más aspectos complementarios puede ser un flujo de audio, y otro de los dos o más aspectos complementarios puede ser un flujo de vídeo.
En una realización, la preparación de la plantilla de servicio se realiza en un nodo proveedor de servicios que envía la plantilla de servicio a un nodo de dominio de acceso; y la producción del conjunto de gestión de flujo de servicio se hace en el nodo de dominio de acceso, en donde la plantilla de servicio puede comprender además una identidad de un proveedor de servicios; y el nodo de dominio de acceso puede usar la identidad del proveedor de servicios para reenviar tráfico entre el proveedor de servicios y el dominio de usuario.
En una realización, un nodo proveedor de servicios prepara una pluralidad de plantillas de servicio para una pluralidad de tipos de servicio, en donde la producción del conjunto de gestión de flujo de servicio se puede hacer en respuesta a recibir una petición de servicio desde el dominio de usuario, el dominio de usuario puede suscribirse a uno o más de la pluralidad de tipos de servicio, la petición de servicio puede comprender una indicación de un tipo de servicio deseado, y la producción del conjunto de gestión de flujo de servicio puede estar condicionada al dominio de usuario que está suscrito al tipo de servicio deseado.
Además, se pueden recibir una pluralidad de peticiones de servicio desde el dominio de usuario, y se pueden producir distintos conjuntos de gestión de flujo de servicio para cada una de la pluralidad de peticiones de servicio.
Además, el dominio de usuario puede suscribirse a uno o más de la pluralidad de tipos de servicio, el dominio de usuario puede comprender una pluralidad de dispositivos de usuario, se puede recibir una pluralidad de peticiones de servicio de uno o más de la pluralidad de dispositivos de usuario, cada petición de servicio que comprende una indicación de un tipo de servicio deseado, el uno o más de la pluralidad de dispositivos de usuario se puede seleccionar según los tipos de servicio deseados, para cada una de la pluralidad de peticiones de servicio; y se pueden producir condicionalmente distintos conjuntos de gestión de flujo de servicio para cada una de la pluralidad de peticiones de servicio, en donde la producción de cada conjunto de gestión de flujo de servicio puede estar condicionada al dominio de usuario que está suscrito a los tipos de servicio deseados.
Breve descripción de los dibujos
Para una comprensión más detallada de la invención, para objetos y ventajas adicionales de la misma, se puede hacer ahora referencia a la siguiente descripción, tomada en conjunto con los dibujos anexos, en los que:
La Figura 1 es una representación de la técnica anterior de una red de acceso simple;
La Figura 2 muestra una representación de un método para definir y usar conjuntos de gestión de flujo de servicio;
La Figura 3 muestra una plantilla de servicio ejemplar según un aspecto de la presente invención;
La Figura 4 muestra un conjunto de gestión de flujo de servicio ejemplar según un aspecto de la presente invención;
La Figura 5 muestra un diagrama de señalización ejemplar según un aspecto de la presente invención; y
La Figura 6 muestra un nodo de dominio de acceso ejemplar construido según la presente invención.
Descripción detallada
Las enseñanzas innovadoras de la presente invención se describirán con referencia particular a diversos usos y aspectos ejemplares de la realización preferida. No obstante, se debería entender que esta realización proporciona solamente unos pocos ejemplos de los muchos usos ventajosos de las enseñanzas innovadoras de la invención. En general, las declaraciones hechas en la especificación de la presente solicitud no limitan necesariamente ninguno de los diversos aspectos reivindicados de la presente invención. Además, algunas declaraciones pueden aplicar a algunos rasgos inventivos pero no a otros. En la descripción de las figuras, números iguales representan elementos iguales de la invención.
La presente invención proporciona un método y un nodo para identificar tipos de servicio y para aplicar de manera eficiente políticas para gestionar servicios ofrecidos por proveedores de servicios a dominios de usuario. Los tipos de servicio ofrecidos por un servidor se usan para preparar plantillas de servicio. Cada plantilla de servicio comprende parámetros de políticas, tales como por ejemplo parámetros de Calidad de Servicio (QoS), información útil en el direccionamiento del servidor, que incluyen una dirección del servidor que entrega realmente el servicio, un identificador de protocolo, y además comprende un campo de datos vacío previsto para ser rellenado mediante la adición de información útil en el direccionamiento de un dominio de usuario. Dependiendo del identificador de protocolo, la plantilla también puede comprender un puerto de servidor, que puede ser un puerto bien conocido tal como, por ejemplo, el puerto 25 para el Protocolo de Transferencia de Correo Simple (SMTP), y también puede comprender otro campo de datos vacío previsto para ser rellenado mediante la adición de un puerto de dominio de usuario. Las plantillas de servicio se preparan preferiblemente por los servidores de los proveedores de servicios, y preferiblemente se envían a nodos de dominio de acceso que proporcionan acceso de red a los dominios de usuario. Tales nodos de dominio de acceso, a los que se puede acceder por ejemplo mediante encaminadores de Proveedores de Servicios de Internet (ISP), preferiblemente almacenan las plantillas de servicio tras la recepción.
Cuando un usuario desea obtener un servicio de un tipo específico desde un proveedor de servicios, un dominio de usuario envía una petición hacia un servidor del proveedor de servicios. La petición comprende una dirección de usuario y puede comprender además un puerto de usuario. Si el servidor acepta las peticiones de servicio, reenvía la dirección de usuario, y el puerto si se incluye en la petición, al nodo de dominio de acceso. En el nodo de dominio de acceso, se ejecuta un conjunto de gestión de flujo de servicio copiando un contenido de una plantilla de servicio para el tipo de servicio específico, rellenando los campos vacíos de la plantilla con la dirección de usuario, y con el puerto de usuario si está disponible. A partir de entonces, se produce un flujo de servicio por el cual los paquetes de datos de tráfico se intercambian entre el dominio de usuario y el servidor, a través del nodo de dominio de acceso. Cada paquete transporta una dirección de origen, una dirección de destino y un tipo de protocolo, en donde el origen y el destino designan respectivamente o bien el dominio de usuario o bien el servidor, dependiendo de una dirección de los datos de tráfico. El nodo de dominio de acceso hace coincidir, para cada paquete, las direcciones de origen y de destino y el tipo de protocolo con la dirección del servidor, la dirección del usuario, y el identificador de protocolo, a fin de relacionar el paquete con el flujo de servicio apropiado. El nodo de dominio de acceso aplica los parámetros de políticas del conjunto de gestión de flujo de servicio apropiado para reenviar el flujo de datos de tráfico hacia su
destino, o bien transparentemente, o bien modificando, retrasando, descartando, o sustituyendo los paquetes de datos.
En el contexto de la presente invención, un proveedor de servicios puede comprender uno o más servidores. El proveedor de servicios puede tener un servidor por cada tipo de servicio que ofrece. Alternativamente, un servidor dado puede ser capaz de soportar varios tipos de servicio. Se pueden usar varios servidores dentro de un mismo dominio de proveedor de servicios para compartición de carga, redundancia, o se pueden seleccionar según una distancia geográfica desde un dominio de usuario solicitante. Un servidor puede autorizar simplemente el acceso a un servicio mientras que uno o más de otros servidores del mismo proveedor de servicios pueden entregar realmente contenido a los usuarios. De manera general, la descripción de la presente invención se puede leer teniendo en cuenta la equivalencia de los términos “servidor” y “proveedor de servicios”.
Un proveedor de servicios típicamente sirve a un número muy grande de dominios de usuario. Un dominio de usuario puede comprender uno o más dispositivos de usuario tales como ordenadores, receptores multimedia digitales de televisión, asistentes digitales personales y similares, encontrados generalmente en un único hogar o dentro de una única oficina. El dominio usuario puede constar de un dispositivo móvil, en cuyo caso la ubicación del dominio usuario o dispositivo usuario puede cambiar con el tiempo y, por ello, el dominio de usuario puede acceder a cualquiera de una multiplicidad de nodos de dominio de acceso. El dominio de usuario puede tener un servicio de una variedad de distintos proveedores de acceso tales como unos ISP. Un dominio de usuario puede actuar como un servidor para otro dominio de usuario; como resultado, la presente invención puede implicar dos dominios de usuario distintos, en donde cada dominio de usuario actúa como un servidor hacia el otro dominio usuario.
El nodo de dominio de acceso puede ser un encaminador, un encaminador de Red de Área Local Inalámbrica (WLAN), y similares. Típicamente, el nodo de dominio de acceso sirve a un número grande de dominios de usuario. En lugar de ser implementados en un único nodo, los rasgos del nodo de dominio de acceso se pueden compartir entre varios nodos. Por ejemplo, un gestor de recursos puede almacenar una lista de plantillas de servicio y proporcionar la plantilla de servicio relevante a un encaminador cuando se requiera la ejecución de un conjunto de gestión de flujo de servicio. También, dos encaminadores distintos presentes en un camino entre el dominio de usuario y el servidor pueden tener copias de la información del conjunto de gestión de flujo de servicio y cada uno puede aplicar algunos o todos los parámetros de políticas al flujo de servicio. Un encaminador situado próximo al dominio de usuario puede aplicar preferiblemente políticas que se refieren al tráfico de enlace ascendente, mientras que otro encaminador situado próximo al servidor aplicaría preferiblemente políticas que se refieren al tráfico de enlace descendente.
Las direcciones usadas por el dominio de usuario y por el servidor pueden tomar la forma de direcciones del Protocolo de Internet (IP). Alternativamente, se pueden usar otros tipos de direcciones. Por ejemplo direcciones de Control de Acceso al Medio (MAC) Ethernet obtenidas a partir de la traducción de direcciones IP mediante el uso de identificadores de sesión de un Protocolo de Resolución de Dirección (ARP), o Protocolo Punto a Punto sobre Ethernet (PPPoE). También, se pueden usar etiquetas de Conmutación de Etiquetas Multiprotocolo (MPLS) en lugar de direcciones IP.
En lugar de tener una dirección específica para designar el servidor o el dominio de usuario, se puede usar ventajosamente una gama de direcciones. Por ejemplo, se pueden alcanzar varios servidores de un mismo proveedor de servicios dentro de una gama de direcciones IP identificada por una dirección de red. Una dirección de red ejemplar para un servidor podría tomar la forma de “192.168.4.x”. Aplicar cualquier valor dentro de una gama [1255] al campo “x” produciría una dirección IP versión 4 (IPv4) estándar dentro de la gama de la dirección de red. La terminología usada en la presente memoria, que se refiere a direcciones, tiene que ser entendida como que abarca direcciones específicas, por ejemplo direcciones IP, etiquetas MPLS, o direcciones MAC, así como gamas de direcciones tales como direcciones de red, y similares.
En la presente invención, el término “flujo de servicio” describe una sucesión de paquetes de datos intercambiados entre un origen y un destino, por ejemplo entre un proveedor de servicios y un dominio de usuario, o más específicamente entre un servidor del proveedor de servicios y un dispositivo de usuario del dominio de usuario. El tráfico de datos puede fluir en cualquiera de las dos direcciones entre el servidor y el dominio de usuario. Los paquetes dentro de un flujo de servicio, o flujo de datos de servicio, pueden formar un flujo continuo o uno discontinuo, en el sentido que algunos servicios proporcionarán un flujo de paquetes de datos de una forma más consistente, mientras que algunos otros servicios proporcionarán paquetes de datos sobre una base según se necesite, con retardos posibles largos entre paquetes o entre grupos de paquetes. Todos los paquetes dentro del flujo se refieren generalmente a un tipo de servicio, o a un componente particular de una oferta de servicio.
Ahora se hace referencia a los Dibujos, en los cuales la Figura 2 muestra una representación de un método para definir y usar conjuntos de gestión de flujo de servicio. Un conjunto de gestión de flujo de servicio se prepara y usa, como se muestra en el método de la Figura 2, a fin de asegurar que se entrega un tipo de servicio ofrecido a un dominio de usuario en cumplimiento con las políticas seleccionadas por un proveedor de servicios. El proceso comienza en el paso 210 donde se proporciona una plantilla de servicio, que comprende parámetros que definen un tipo de servicio. La plantilla de servicio se puede preparar en un primer nodo, por ejemplo en un servidor y reenviar para usar más tarde en un segundo nodo, por ejemplo en un encaminador. Alternativamente, la plantilla de servicio
se puede usar en el mismo nodo donde se ha preparado originalmente. Los parámetros de la plantilla de servicio se describen en la Figura 3, la cual muestra una plantilla de servicio 300 ejemplar según un aspecto de la presente invención.
Como se muestra la Figura 3, la plantilla de servicio 300 comprende una dirección 310 de un servidor que proporciona realmente el tipo de servicio definido por la plantilla de servicio 300. La dirección 310 puede ser por ejemplo una dirección IP. También se incluye un identificador de protocolo 330 que se encuentra en una cabecera IP, por ejemplo un Protocolo de Control de Transmisión (TCP), un Protocolo de Datagrama de Usuario (UDP), un Protocolo de Transmisión de Control de Flujo (SCTP), o un Protocolo de Mensaje de Control de Internet (ICMP). Un puerto 320 del servidor se puede incluir opcionalmente, donde sea aplicable dependiendo de un valor del identificador de protocolo 330. Preferiblemente, la dirección del servidor 310, el identificador de protocolo 330, y el puerto 320 si se incluye, forman una única combinación para un tipo de servicio dado. La plantilla de servicio 300 comprende dos campos vacíos: Un primer campo vacío 360 está preparado para recibir eventualmente una dirección de un usuario del servicio definido por la plantilla de servicio 300. Un segundo campo vacío 370 se prepara para recibir opcionalmente un número de puerto de usuario. Una lista 340 comprende una o más políticas para controlar un flujo de servicio, parte de la plantilla de servicio 300, las políticas que se seleccionan tras la configuración de una oferta de servicio por el proveedor de servicios según las necesidades del tipo de servicio. Dentro de la lista 340 se pueden encontrar parámetros de QoS ejemplares y otros tipos de parámetros, tales como un ancho de banda en la dirección del enlace ascendente y/o enlace descendente 341, un retardo de enlace ascendente y/o enlace descendente máximo 342, un indicador 343 de que la retransmisión en la dirección del enlace ascendente/enlace descendente se permite o no, unos parámetros de conformación de tráfico 344 para atenuar los picos de tráfico en la dirección del enlace ascendente y/o del enlace descendente, unas condiciones de filtrado de paquetes en las direcciones del enlace ascendente y/o del enlace descendente 345, una prioridad de paquete en las direcciones del enlace ascendente y/o del enlace descendente 346, y similares. Se debería entender que la lista de parámetros 341-346 es solamente ejemplar y que otros tipos de parámetros de QoS, prioridad, o parámetros de conformación de tráfico podrían formar el contenido de la lista 340 sin apartarse del espíritu de la presente invención. La plantilla de servicio 300 además puede comprender una identidad de proveedor de servicios 350. En algunas redes tales como en redes IP versión 6 (IPv6), es posible asegurar la unicidad de la dirección del servidor
310. No obstante, en redes IPv4, una misma dirección IP se puede asignar a más de un nodo. Incluso en el caso de redes IPv6, que aseguran la unicidad de las direcciones 310 se requiere un manejo complejo, que no siempre se implementa. En tales casos, la identidad del proveedor de servicios 350 se puede añadir ventajosamente a la plantilla de servicio 300 a fin de identificar de manera única el servidor. La plantilla de servicio 300 se puede preparar y almacenar dentro de un nodo, o se puede preparar dentro de un primer nodo y almacenar para usar más tarde en un nodo separado.
Volviendo la Figura 2, se produce un conjunto de gestión de flujo de servicio en el paso 220. El conjunto de gestión de flujo de servicio 400 se puede producir en el nodo donde se preparó en primer lugar la plantilla de servicio 300, o en un nodo separado donde la plantilla de servicio 300 fue almacenada. El conjunto de gestión de flujo de servicio se produce cuando se requiera para un usuario específico del servicio identificado por la plantilla de servicio. Esto puede ser en respuesta a la recepción de una señal o mensaje que requiere la puesta en marcha de una sesión desde el dominio de usuario, la señal o mensaje que comprende una indicación de una dirección de usuario y, opcionalmente, de un puerto de usuario. La dirección de usuario y el puerto de usuario opcional se pueden obtener alternativamente por otros medios, por ejemplo mediante configuración manual de la información relacionada con un dominio de usuario seleccionado permitido para obtener un servicio desde una red segura. La producción del conjunto de gestión de flujo de servicio 400 se hace copiando el contenido de la plantilla de servicio 300, sobre escribiendo los campos vacíos 360 y 370 con la dirección de dominio de usuario y, opcionalmente, con el número de puerto de dominio usuario. La Figura 4 muestra un conjunto de gestión de flujo de servicio 400 ejemplar según un aspecto de la presente invención. El conjunto de gestión de flujo de servicio 400 comprende toda la información de la plantilla de servicio 300, a la que se añaden una dirección de usuario 460, y un puerto de usuario 470 opcional, los cuales en efecto rellenan los campos vacíos 360 y 370, respectivamente, de la plantilla de servicio 300. A fin de identificar de manera única un tipo de servicio dado ofrecido a un dominio de usuario, la dirección de servidor 310, el identificador de protocolo 330, y la dirección de usuario 460, junto con el puerto de servidor 320 y el puerto de usuario 470 si se incluye, deben formar una combinación única dentro de una misma red, y aparecer en un único conjunto de gestión de flujo de servicio 400.
En muchos casos, cuando el tipo de servicio definido por la plantilla de servicio 300 es de una categoría unidifusión, la dirección de usuario 460 puede ser una dirección IP asignada a un dispositivo de usuario dentro del dominio de usuario. En esos casos, el puerto de usuario 470 puede ser un número de puerto del mismo dispositivo de usuario, seleccionado según una implementación interna del dispositivo de usuario. Alternativamente, cuando el tipo de servicio definido por la plantilla de servicio 300 es de una categoría multidifusión, la dirección de usuario no está relacionada con ningún dispositivo de usuario específico, sino más bien puede ser una dirección IP multidifusión que se relaciona con un grupo multidifusión, es decir, un grupo de dispositivos de usuario que tiene un interés en el mismo servicio multidifusión. En el caso de servicio multidifusión, el puerto de usuario 470 es un número de puerto que usan todos los dispositivos en el grupo multidifusión para acceder al servicio multidifusión.
Todavía en la Figura 2, se intercambia tráfico de datos en un flujo de servicio establecido entre el servidor y el dominio de usuario según los parámetros en la lista de políticas 340 del conjunto de gestión de flujo de servicio 400.
En el paso 230, se recibe un paquete de datos, que comprende una dirección de origen, una dirección de destino, un tipo de protocolo y, opcionalmente, un puerto de origen y un puerto de destino. Dependiendo de una dirección del tráfico de datos, la de origen puede ser el servidor y la de destino puede ser el dominio de usuario, en cuyo caso la dirección del tráfico es de enlace descendente. En una dirección de enlace ascendente, la de origen es el dominio de usuario y la de destino es el servidor. En el paso 240, las direcciones de origen y de destino, el tipo de protocolo, y los puertos si se incluyen, se hacen coincidir con la dirección del servidor 310, la dirección del usuario 460, el identificador de protocolo 330 y, opcionalmente, con el puerto de servidor 320 y el puerto de usuario 470, identificando por ello el conjunto de gestión de flujo de servicio 400 adecuado. En el paso 250, el paquete de datos se maneja según parámetros en la lista de políticas 340 del conjunto de gestión de flujo de servicio 400 apropiado. Los datos, que se relacionan con el tipo de servicio identificado de manera única por el conjunto de gestión de flujo de servicio 400, están contenidos en el paquete de datos. Se verifica el cumplimiento de los datos con los parámetros en la lista de políticas 340. Los datos se pueden reenviar, retardar, descartar, filtrar, o modificar de otro modo en base a la lista de políticas 340. A modo de ejemplo, la prioridad 346 en la lista de políticas 340 puede indicar que los datos tienen una prioridad baja. En caso de sobrecarga de tráfico, el paquete de datos se puede retardar, si el retardo máximo 342 indica que está permitido retardar el paquete. Alternativamente, el paquete de datos se puede borrar y no reenviar, si el retardo máximo 342 indica que el paquete no se puede retardar en absoluto.
Habiendo ahora descrito anteriormente en la presente memoria un método de definición y uso de plantillas de servicio 300 y conjuntos de gestión de flujo de servicio 400, ahora se describirán aspectos de la realización preferida de la presente invención en referencia a la Figura 5, la cual muestra un diagrama de señalización ejemplar según un aspecto de la presente invención. La Figura 5 muestra la interacción entre un servidor 500, un dominio usuario 120, y un nodo de dominio de acceso 600. Se debería entender que una red de acceso típica comprendería normalmente un gran número de nodos de dominio de acceso 600, y un incluso mayor número de dominios de usuario 120. Varios tipos de nodos de dominio de acceso 600 podrían comprender por ejemplo encaminadores de acceso que proporcionan acceso directo a los dominios de usuario 120, y los concentradores. En un único dominio de usuario 120 podrían residir uno o más dispositivos de usuario (no se muestran, pero se representan en la Figura 1). La red de acceso proporcionaría acceso a una multiplicidad de dominios de proveedor de servicios, cada uno de los cuales que comprende uno o más servidores 500. Dentro de un dominio de proveedor de servicios, uno podría encontrar varios nodos especializados tales como nodos de función de aplicaciones (no se muestran) además de varios tipos de servidores 500. La siguiente descripción de señalización entre el servidor 500, el nodo de dominio de acceso 600, y el dominio de usuario 120 es ilustrativa y está simplificada.
En el paso 210, el servidor 500 prepara una o más plantillas de servicio 300, para uno o más tipos de servicio correspondientes. El paso 210 es el mismo que se describió en relación con la Figura 2. En el paso 502, el servidor 500 envía hacia el nodo de dominio de acceso 600 un mensaje que comprende un contenido de cada una de las plantillas de servicio 300. El mensaje del paso 502 identifica de manera única cada plantilla de servicio 300, o bien mediante una combinación única de la dirección del servidor 310, el puerto de servidor opcional 320, y el identificador de protocolo 330, o bien mediante el uso de un identificador de plantilla de servicio separado. El nodo de dominio de acceso 600 almacena la una o más plantillas de servicio 300 en memoria en el paso 504. El paso 210 se puede ejecutar en el servidor 500 cuando se modifican los tipos de servicio existentes, o cuando se introducen nuevos tipos de servicio. Los pasos 502 y 504 se ejecutan consecutivos al paso 210, o cuando el servidor 500 adquiere una nueva relación con un nuevo nodo de dominio de acceso 600. Los pasos 502 y 504 se podrían ejecutar también en otros momentos, por ejemplo tras recuperar de la memoria una pérdida en el nodo de dominio de acceso 600.
En el paso 506, un usuario del dominio de usuario 120 inicia una petición para suscribirse a uno o más servicios seleccionados. Se envía un mensaje hacia el servidor 500, posiblemente transmitido a través del nodo de dominio de acceso 600. El mensaje comprende una identidad del usuario, correspondiente a una identidad del dominio de usuario 120, y la lista de servicios seleccionados. Ejemplos de servicios pueden comprender Vídeo Bajo Demanda (VOD), o Voz sobre IP (VoIP). En el paso 508, el servidor 500 almacena información de suscripción para el dominio de usuario 120 y los servicios seleccionados. Para algunos tipos de servicios ofrecidos por el servidor 500, puede no ser requerida suscripción y los pasos 506-508 se pueden omitir.
En el paso 510, el usuario inicia una petición para poner en marcha una sesión de servicio. Esto se puede hacer por ejemplo encendiendo un dispositivo de usuario comprendido dentro del dominio usuario 120, por ejemplo un receptor multimedia digital de televisión. El dominio de usuario 120 envía una petición de servicio hacia el servidor 500, que comprende una indicación del tipo de servicio requerido, con una dirección y un número de puerto opcional del dispositivo de usuario, si el tipo de servicio requerido es unidifusión. Para un servicio IP multidifusión, la dirección y el número de puerto opcional sería, respectivamente, una dirección IP multidifusión y un número de puerto común a todos los dispositivos de usuario en un grupo multidifusión. Por simplicidad y sin pérdida de generalidad, la siguiente descripción supone que se requiere un servicio unidifusión. La petición de servicio se puede transmitir a través del nodo de dominio de acceso 600. Si es aplicable al tipo de servicio, el servidor 500 verifica en el paso 512 que el dominio de usuario 120 está suscrito al servicio requerido. El servidor 500 puede al mismo tiempo iniciar un proceso de contabilización para tarificar al usuario. El servidor 500 envía un mensaje hacia el dominio de acceso, en el paso 514, requiriéndole producir un conjunto de gestión de flujo de servicio 400. El mensaje identifica positivamente una plantilla de servicio 300 relevante, para la producción del conjunto de gestión de flujo de servicio
400, mediante el uso de la combinación de la dirección de servidor 310, el identificador de protocolo 330, y el puerto de servidor opcional 320, o mediante el uso del identificador de plantilla de servicio. El mensaje comprende la dirección de dispositivo de usuario y puede comprender el número de puerto opcional. En el paso 220, que es el mismo que se describió en relación a la Figura 2, el nodo de dominio de acceso produce el conjunto de gestión de flujo de servicio 400 añadiendo la dirección del dispositivo de usuario y el número de puerto opcional, como la dirección de usuario 460 y el puerto de usuario opcional 470, al contenido de la plantilla de servicio 300.
Un nodo de dominio de acceso 600 único puede proporcionar concurrentemente acceso a un mismo tipo de servicio unidifusión desde el mismo servidor 500 a varios dominios de usuario 120. Dentro de ese nodo de dominio de acceso 600, la plantilla de servicios 300 para el tipo de servicios del servidor 500 se ejecuta solamente una vez, pero el conjunto de gestión de flujo de servicio 400 se ejecuta tantas veces como dominios de usuario 120 haya accediendo concurrentemente al servicio. Para un tipo de servicio multidifusión desde un servidor 500, que se sirve a través del nodo de dominio de acceso 600, el conjunto de gestión de flujo de servicio 400 se ejecuta por el nodo de dominio de acceso 600 solamente una vez para un grupo multidifusión, sin importar el número de dominios de usuario 120 dentro del grupo multidifusión.
Preferiblemente, el servidor 500 informa al dominio de usuario 120 que se acepta la petición en el paso 516.
A partir de entonces, el tráfico de datos en forma de paquetes se intercambia en un flujo de servicio establecido entre el servidor 500 y el dominio de usuario 120, a través del nodo de dominio de acceso 600. El tráfico puede fluir en una dirección de enlace descendente, desde el servidor 500 hacia el dominio de usuario 120, en una dirección de enlace ascendente, desde el dominio de usuario 120 hacia el servidor 500, o en ambas direcciones. Si el tipo de servicio es VOD, virtualmente todo el tráfico está en la dirección del enlace descendente, aparte de alguna cantidad menor de señalización de control enviada por el dominio de usuario 120. En el caso de un servicio de telefonía de VoIP, el tráfico fluye en ambas direcciones.
Los paquetes de datos transitan a través del nodo de dominio de acceso 600, el cual aplica políticas a partir del conjunto de gestión de flujo de servicio 400. Por ejemplo, un paquete de datos de enlace ascendente enviado desde el dominio de usuario 120 en el paso 518 llega al nodo de dominio de acceso 600, que contiene una dirección de origen de usuario, una dirección de destino de servidor 500, un tipo de protocolo y, opcionalmente, un puerto de origen de usuario y un puerto de destino de servidor 500. El nodo de dominio de acceso 600 identifica el conjunto de gestión de flujo de servicio 400 adecuado haciendo coincidir el identificador de protocolo 330 y las direcciones de usuario y de servidor y los puertos opcionales contenidos en el mismo con las direcciones de origen y de destino recibidas, el tipo de protocolo y los puertos opcionales. Cualquier paquete de datos que tiene direcciones de origen y de destino, o tipo de protocolo, o puertos opcionalmente, que no hace coincidir ningún conjunto de gestión de flujo de servicio 400 del nodo de acceso 600 se manejaría según las maneras conocidas en la técnica anterior, por ejemplo trasferido a través del nodo de acceso 600 en un modo de mejor esfuerzo. En el paso 520, el nodo de dominio de acceso 600 verifica que el paquete de datos se puede reenviar como está, modificado, o eliminado, según las políticas. A modo de ejemplo, los datos contenidos en un paquete de VoIP único enviado por el dispositivo de usuario, que representan una fracción de un segundo de habla, se pueden eliminar según una política del conjunto de gestión de flujo de servicio 400, si se excede un umbral que indica que está siendo transmitido demasiado tráfico hacia el servidor 500. Las políticas del conjunto de gestión de flujo de servicio 400 no permitirían retardar ese paquete de VoIP, considerando que retardar un paquete degradaría la calidad del habla incluso más que simplemente descartando el mismo paquete. El paquete, si no se elimina, se reenvía hacia el servidor en el paso 522. En otro ejemplo, un paquete que contiene datos de VOD se envía desde el servidor 500, en la dirección del enlace descendente, en el paso 524. En el paso 526, el nodo de dominio de acceso aplica políticas a partir de un conjunto de gestión de flujo de servicio 400 que hace coincidir direcciones, tipo de protocolo y puertos opcionales contenidos en el paquete de datos de VOD, y que comprende políticas para un servicio de VOD. En caso de sobrecarga de tráfico, una política dada puede indicar que no se permite descartar datos de VOD, sino que se permite retardar paquetes de vídeo en un mecanismo de conformación de tráfico. En el paso 528, se reenvían paquetes de datos, posiblemente en forma modificada, hacia el dominio de usuario 120. En el paso 530, el usuario puede requerir cesar la sesión de servicio. El servidor 500 puede detener la contabilización y entonces informa al nodo de dominio de acceso en el paso 532 para eliminar el conjunto de gestión de flujo de servicio 400.
El servidor 500 puede determinar que una oferta de servicio particular se sirve mejor por dos o más flujos distintos, para lo cual se definen dos o más plantillas de servicio 300 y dos o más conjuntos de gestión de flujo de servicio 400 correspondientes. Por ejemplo un servicio de televisión podría comprender dos flujos de servicio para flujos de audio y video, los dos flujos que tienen diferentes características gestionadas por distintas listas de políticas 340 debido a los diferentes requerimientos para las señales de audio y video de alta calidad. Las dos plantillas de servicio 300 distintas para los flujos de audio y de vídeo ya habrían sido enviadas desde el servidor 500 al nodo de dominio de acceso 600 en el paso 502, y almacenadas en el paso 504. En el paso 514, el servidor 500 puede indicar favorablemente al nodo de dominio de acceso 600 que se requiere una producción de dos conjuntos de gestión de flujo de servicio 400, en respuesta a una petición de servicio única en el paso 510, si la petición es para la oferta de servicio de televisión. Al menos uno de la dirección de servidor 310, el puerto de servidor 320, la dirección de usuario 460, el puerto de usuario 470, o el identificador de protocolo 330, debe ser diferente en los dos conjuntos de gestión de flujo de servicio 400, a fin de hacerlos distinguibles. El tráfico de datos entonces se maneja independientemente en ambos flujos de servicio, en los pasos 518-528. De igual modo, si la petición de servicio
recibida en el paso 510 identifica dos servicios independientes que tienen diferentes características, se pueden producir dos conjuntos de gestión de flujo de servicios 400 separados en el paso 220 para proporcionar independientemente los dos servicios desde el mismo servidor 500 al mismo dominio de usuario 120.
La solicitud de patente de EE.UU. número US 2006/0182123, publicada el 17 de agosto de 2006, titulada “Method for aggregating data traffic over an access domain and nodes therefor”, y concedida al beneficiario de la presente solicitud, describe una red de servicio de datos en donde un proveedor de servicios ofrece un servicio a un dominio de usuario a través de una red de acceso que comprende unos Nodos de Acceso (AN) y unos Nodos de Borde de Acceso (AEN). Un enlace de servicio se crea y almacena en el AEN cuando el dominio de usuario pide poner en marcha una sesión de servicio con un proveedor de servicios. El contenido de vinculación de servicio se reenvía a, y almacena en, el AN que proporciona acceso al dominio de usuario. La vinculación de servicio comprende o se refiere a una identidad del servidor, un tipo de servicio, un número de puerto de servidor, una dirección de Control de Acceso al Medio (MAC), un número de puerto del AN para conectar el dispositivo de usuario, parámetros de QoS, y alguna otra información. El tráfico de datos enviado en la dirección del enlace descendente desde el proveedor de servicios pasa a través del AEN y luego a través del AN anterior a llegar al dominio de usuario. Los parámetros de QoS contenidos en la vinculación de servicio se usan por el AEN y por el AN para gestionar el manejo del tráfico de datos. La vinculación de servicio que se describe en la US 2006/0182123 identifica una relación entre un dominio de usuario y un servidor, pero no puede identificar de manera única un tipo de servicio específico. La vinculación de servicio funciona a un nivel de dirección MAC, y de esta manera no soporta un manejo específico de paquetes de datos en base a una combinación específica de direcciones de usuario y de servidor, tipos de protocolo, o números de puerto. Además, una vinculación de servicio existente puesta en marcha para una sesión en curso, según la US 2006/0182123, no proporciona la capacidad para el usuario de seleccionar nuevos servicios, para lo cual se podrían especificar parámetros de QoS específicos desde el mismo proveedor de servicios. En la US 2006/0182123, una vinculación de servicio solamente se puede relacionar con un conjunto de parámetros de QoS, lo cual puede no ser adecuado para distintos tipos de servicio. Por lo tanto, la US 2006/0182123 no proporciona la capacidad de soportar eficientemente más de un servicio, o más de un flujo de datos para un mismo servicio, desde el mismo proveedor de servicios a un dominio de usuario.
En algunas realizaciones de la presente invención, el AEN descrito en la US 2006/0182123 se puede complementar con rasgos similares a aquéllos del nodo de dominio de acceso 600 descritos anteriormente en la presente memoria. Una pluralidad de plantillas de servicio 300 se pueden almacenar en el AEN y uno o más conjuntos de gestión de flujo de servicio 400 también se pueden ejecutar en el AEN, para un dominio de usuario dado, los conjuntos de gestión de flujo de servicio 400 que llegan a ser parte del enlace de servicio para ese dominio de usuario. Según el AEN reenvía información del enlace de servicio al AN que sirve el dominio de usuario, puede añadir alguna información a partir de los conjuntos de gestión de flujo de servicio 400. El AEN y el AN pueden aplicar ambos las políticas comprendidas en los conjuntos de gestión de flujo de servicio 400 a la sesión de servicio. En algunos casos, el AEN y el AN aplican igualmente todas las políticas. Alternativamente, el AEN y el AN pueden aplicar cada uno algunas de las políticas. Por ejemplo, cuando un dispositivo de usuario envía muchos paquetes grandes previstos para el servidor, el AN que es el primer nodo que recibe esos paquetes grandes puede aplicar una política de filtrado y retardo o descartar algunos de los paquetes, impidiendo por ello la sobrecarga del AEN y el servidor. El AN puede aplicar favorablemente políticas de enlace ascendente mientras que el AEN aplica políticas de enlace descendente.
Una construcción ejemplar de un nodo de dominio de acceso 600 como se usa en las figuras precedentes se describirá ahora en referencia a la Figura 6, la cual muestra un nodo de dominio de acceso según la presente invención. El nodo de dominio acceso 600 aplica políticas de tráfico a un flujo de servicio entre un dominio de usuario 120 y un servidor 500. El nodo de dominio de acceso 600 comprende un dispositivo de entrada-salida del lado del servidor 610, un dispositivo de entrada-salida del lado del dominio de usuario 620, una memoria 630, una lógica de control 640 y un procesador de políticas 650. La memoria 630 además comprende una tabla de plantillas de servicio 632 y una tabla de flujos de servicio 634. Las plantillas de servicio 300 en la tabla de plantillas de servicio 632 son las mismas que se describieron en relación con la Figura 3. De igual modo, los conjuntos de gestión de flujo de servicio 400 de la Figura 4 describen contenidos de la tabla de flujos de servicio 634.
Cuando se crean un tipo de servicio y una plantilla de servicio 300 correspondiente en un servidor 500, el servidor 500 envía información que comprende la plantilla de servicio 300 hacia el nodo de dominio de acceso 600. La información llega al dispositivo de entrada-salida del lado del servidor 610. El dispositivo de entrada-salida del lado del servidor 610 reenvía la plantilla de servicio 300 a la lógica de control 640, la cual a su vez escribe la plantilla de servicio 300 en una entrada de la tabla de plantillas de servicio 632. La tabla de plantillas de servicio 632 puede almacenar plantillas de servicio 300 para un número grande de tipos de servicio disponibles, desde muchos servidores 500.
Cuando el servidor 500 acepta una petición para un servicio desde un dominio de usuario 120, envía hacia el nodo de dominio de acceso 600 una petición para añadir un conjunto de gestión de flujo de servicio 400 para el dominio de usuario 120. La petición comprende una dirección de usuario y, opcionalmente, un puerto de usuario. La petición se recibe en el dispositivo de entrada-salida del lado del servidor 610 y reenvía a la lógica de control 640. La lógica de control 640 lee la plantilla de servicio 300 apropiada de la tabla de plantillas de servicio 632, combina su contenido con la dirección de usuario recibida, y con el puerto de usuario si se incluye, para producir un conjunto de
gestión de flujo de servicio 400, y almacena el conjunto de gestión de flujo de servicio 400 en la tabla de flujos de servicio 634. La tabla de flujos de servicio 634 puede comprender un gran número de conjuntos de gestión de flujo de servicio 400, para una multiplicidad de nodos de dominio de acceso 120.
El tráfico dentro del flujo de servicio puede pasar a través del nodo de dominio de acceso 600 en una dirección de enlace ascendente, desde el dominio de usuario 120 hacia el servidor 500, o en una dirección de enlace descendente, inversa. Tanto el dispositivo de entrada-salida del lado del dominio de usuario 620 como el dispositivo de entrada-salida del lado del servidor 610 pueden recibir entonces el flujo de tráfico en forma de paquetes de datos. Cada paquete de datos comprende una dirección de origen de enlace ascendente o enlace descendente, una dirección de destino de enlace ascendente o enlace descendente, un tipo de protocolo, y además puede comprender un puerto de origen de enlace ascendente o enlace descendente, y un puerto de destino de enlace ascendente o enlace descendente. Por ejemplo, se envía un paquete de datos recibido en el dispositivo de entrada-salida del lado del servidor 610 por el servidor 500 en la dirección del enlace descendente; ese paquete por lo tanto comprende una dirección de origen de enlace descendente y una dirección de destino de enlace descendente. Esas direcciones, tipo de protocolo y puertos opcionales se usan por el procesador de políticas 650 para identificar un conjunto de gestión de flujo de servicio 400 correspondiente dentro de la tabla de flujos de servicio 634, encontrando una coincidencia con el identificador de protocolo 330 y con las direcciones y puertos opcionales del servidor y usuario. Una vez que se encuentra una coincidencia, las políticas contenidas en el conjunto de gestión de flujo de servicio 400 se leen por el procesador de políticas 650. El procesador de políticas 650 usa las políticas, que comprenden por ejemplo el ancho de banda de enlace ascendente y/o enlace descendente 341, el retardo máximo de enlace ascendente y/o enlace descendente 342, el indicador de retrasmisión de enlace ascendente y/o enlace descendente 343, la conformación de tráfico 344, las condiciones de filtrado de paquetes de enlace ascendente y/o enlace descendente 345, o la prioridad de enlace ascendente y/o enlace descendente 346, o cualquier combinación adecuada de los mismos, para determinar cómo se manejan los paquetes de datos. Dependiendo de la dirección del paquete de datos, el procesador de políticas hace preferiblemente una selección, entre las políticas del conjunto de gestión de flujo de servicio 400, de políticas que aplican solamente al enlace ascendente, al enlace descendente, o a ambas direcciones de tráfico. Dependiendo de las políticas seleccionadas, el procesador de políticas 650 puede dejar paquetes sin modificar, o alternativamente descartar, filtrar, retardar o hacer cualquier modificación basada en políticas adecuadas a los paquetes, anterior a reenviarlos a través del dispositivo de entrada-salida del lado del dominio de usuario 620 o el dispositivo de entrada-salida del lado del servidor 610. Por ejemplo, si una cantidad y tamaño de los paquetes de datos recibidos desde un dominio de usuario 120 dado en el dispositivo de entradasalida del lado del dominio de usuario 620 excede un límite fijado por el ancho de banda de enlace ascendente 341, el tráfico se considera no compatible con el ancho de banda de enlace ascendente 341 y algunos de los paquetes de datos se retardan o descartan por el procesador de políticas 650.
Si el servidor 500 determina que una petición para el servicio requiere poner en marcha dos conjuntos de gestión de flujo de servicio 400 separados para el dominio de usuario 120, se reciben dos peticiones para añadir conjuntos de gestión de flujo de servicio 400 desde el servidor 500 en el dispositivo de entrada-salida del lado del servidor 610, o bien separadamente o bien en un mensaje combinado. La lógica de control 640 lee dos plantillas de servicio 300 distintas de la tabla de plantillas de servicio 632 y almacena dos conjuntos de gestión de flujo de servicio 400 distintos en la tabla de flujos de servicio 634. En tal caso, las dos plantillas de servicio 300 distintas pueden tener diferentes contenidos en sus listas de políticas 340. Preferiblemente, las dos plantillas de servicio 300 distintas se distinguen teniendo direcciones de servidor 310 distintas, o puertos de servidor 320 distintos, o identificadores de protocolo 330 distintos, o cualquier combinación diferente. Alternativamente, se pueden distinguir dos conjuntos de gestión de flujo de servicio 400 distintos asignados a un mismo dominio de usuario 120 mediante el uso de direcciones de usuario 460 distintas o puertos de usuario 470 distintos.
En un caso donde se asignan dos o más conjuntos de gestión de flujo de servicio 400 a un dominio de usuario 120, por ejemplo un primer conjunto de gestión de flujo de servicio 400 para un servicio de VoIP y un segundo conjunto de gestión de flujo de servicio 400 para otro servicio de datos, los paquetes de datos para estas dos o más aplicaciones comprenden diferentes conjuntos de direcciones de origen y de destino, tipos de protocolo, o puertos distintos. El procesador de políticas 650 de esta manera es capaz de distinguir entre los dos o más conjuntos de gestión de flujo de servicio 400 del dominio de usuario 120 mediante el uso de esos conjuntos diferentes.
Aunque se han ilustrado diversos aspectos de la realización preferida del método y del nodo de dominio de acceso de la presente invención en los Dibujos anexos y descrito en la Descripción Detallada antes mencionada, se entenderá que la invención no está limitada a la realización descrita, sino que cubre numerosas reordenaciones, modificaciones y sustituciones.

Claims (29)

  1. REIVINDICACIONES
    1. Un método de aplicación de políticas de tráfico a un tipo de servicio proporcionado por un servidor a un dominio de usuario, el método que comprende los pasos de:
    proporcionar (210) una plantilla de servicio (300) que comprende una dirección del servidor, un identificador de protocolo, y una o más políticas de tráfico;
    producir (220) un conjunto de gestión de flujo de servicio (400) añadiendo una dirección del dominio de usuario (460) a la plantilla de servicio;
    recibir (230) un paquete que comprende una dirección de origen, una dirección de destino, un tipo de protocolo, y datos en relación con el tipo de servicio;
    identificar (240) el conjunto de gestión de flujo de servicio haciendo coincidir la dirección de origen, la dirección de destino, y el tipo de protocolo con el conjunto de gestión de flujo de servicio; e
    intercambiar los datos entre el dominio de usuario y el servidor usando (250) la una o más políticas de tráfico.
  2. 2.
    El método de la reivindicación 1, en donde:
    la dirección del servidor (310), la dirección del dominio de usuario (460), la dirección de origen y la dirección de destino son direcciones del Protocolo de Internet (IP).
  3. 3.
    El método de la reivindicación 1, en donde: la dirección de origen es igual a la dirección del dominio de usuario; la dirección de destino es igual a la dirección del servidor; y el tipo de protocolo es igual al protocolo.
  4. 4.
    El método de la reivindicación 1, en donde: la dirección de destino es igual a la dirección del dominio de usuario; la dirección de origen es igual a la dirección del servidor; y el tipo de protocolo es igual al identificador del protocolo.
  5. 5.
    El método de la reivindicación 1, en donde:
    el tráfico de datos se intercambia entre el dominio de usuario y el servidor mediante el uso de políticas (340) comprendidas en dos o más conjuntos de gestión de flujo de servicio (400); y
    los dos o más conjuntos de gestión de flujo de servicio están basados en dos o más plantillas de servicio (300) distintas;
    en donde los dos o más conjuntos de gestión de flujo de servicio están asociados con dos o más aspectos complementarios de una oferta de servicio.
  6. 6.
    El método de la reivindicación 5, en donde: la oferta de servicio es un servicio de televisión; uno de los dos o más aspectos complementarios es un flujo de audio; y otro de los dos o más aspectos complementarios es un flujo de vídeo.
  7. 7.
    El método de la reivindicación 1, en donde: el paso de preparar la plantilla de servicio se realiza en un nodo proveedor de servicios (500); el nodo proveedor de servicios envía la plantilla de servicio a un nodo de dominio de acceso (600); y el paso de producir el conjunto de gestión de flujo de servicio se hace en el nodo de dominio de acceso (600).
  8. 8.
    El método de la reivindicación 7, en donde: la plantilla de servicio además comprende una identidad de un proveedor de servicios; y el nodo de dominio de acceso (600) usa la identidad del proveedor de servicios para reenviar tráfico entre el
    proveedor de servicios (500) y el dominio de usuario (120).
  9. 9.
    El método de la reivindicación 1, en donde:
    un nodo proveedor de servicios prepara una pluralidad de plantillas de servicio (210) para una pluralidad de tipos de servicio.
  10. 10.
    El método de la reivindicación 9, en donde:
    el paso de producir el conjunto de gestión de flujo de servicio (400) se hace en respuesta a recibir una petición de servicio (510) desde el dominio de usuario.
  11. 11.
    El método de la reivindicación 10, en donde: el dominio de usuario se suscribe (506) a uno o más de la pluralidad de tipos de servicio; la petición de servicio (510) comprende una indicación de un tipo de servicio deseado; y la producción (220) del conjunto de gestión de flujo de servicio (400) está condicionada al dominio de usuario que
    está suscrito al tipo de servicio deseado.
  12. 12.
    El método de la reivindicación 10, en donde: la pluralidad de peticiones de servicio (510) se reciben desde el dominio de usuario (120); y distintos conjuntos de gestión de flujo de servicio (400) se producen para cada una de la pluralidad de peticiones de
    servicio.
  13. 13.
    El método de la reivindicación 9, en donde: el dominio de usuario (120) se suscribe a uno o más de la pluralidad de tipos de servicio; el dominio de usuario (120) comprende una pluralidad de dispositivos de usuario; una pluralidad de peticiones de servicio (510) se reciben desde uno o más de la pluralidad de dispositivos de
    usuario, cada petición de servicio que comprende una indicación de un tipo de servicio deseado;
    el uno o más de la pluralidad de dispositivos de usuario se seleccionan según los tipos de servicio deseados, para cada una de la pluralidad de peticiones de servicio; y distintos conjuntos de gestión de flujo de servicio (400) se producen condicionalmente para cada una de la pluralidad
    de peticiones de servicio, en donde la producción de cada conjunto de gestión de flujo de servicio está condicionada al dominio de usuario que está suscrito a los tipos de servicio deseados.
  14. 14.
    El método de la reivindicación 1, en donde: la una o más políticas de tráfico (340) comprenden condiciones de filtrado de paquetes (345).
  15. 15.
    El método de la reivindicación 1, en donde: la una o más políticas de tráfico (340) comprenden parámetros de conformación de tráfico (344).
  16. 16.
    El método de la reivindicación 1, en donde: la una o más políticas de tráfico (340) comprenden parámetros de calidad de servicio.
  17. 17.
    El método de la reivindicación 1, en donde: la plantilla de servicio se define para un servicio unidifusión; y la dirección de usuario es una dirección IP de un dispositivo de usuario comprendido en el dominio de usuario.
  18. 18.
    El método de la reivindicación 1, en donde: la plantilla de servicio se define para un servicio multidifusión; y la dirección de usuario es una dirección IP multidifusión usada por una pluralidad de dispositivos de usuario
    comprendidos en una pluralidad de dominios de usuario.
  19. 19.
    El método de la reivindicación 1, en donde: la plantilla de servicio (300) además comprende un puerto del servidor (320);
    producir el conjunto de gestión de flujo de servicio (400) además comprende añadir un puerto al dominio de usuario
    (470) a la plantilla; el paquete además comprende un puerto de origen y un puerto de destino; y el paso de identificar el conjunto de gestión de flujo de servicio (400) además comprende hacer coincidir el puerto de
    origen y el puerto de destino con el conjunto de gestión de flujo de servicio.
  20. 20.
    El método de la reivindicación 1, en donde: al menos una o más de las políticas de tráfico aplica en una dirección de enlace descendente (526).
  21. 21.
    El método de la reivindicación 1, en donde: al menos una de la una o más políticas de tráfico aplica en una dirección de enlace ascendente (520).
  22. 22.
    El método de la reivindicación 1, en donde:
    al menos una de la una o más políticas de tráfico aplica tanto en una dirección de enlace ascendente como en una dirección de enlace descendente.
  23. 23.
    El método de la reivindicación 1, en donde: la dirección del servidor es una dirección de red.
  24. 24.
    El método de la reivindicación 1, en donde: la dirección del dominio de usuario es una dirección de red.
  25. 25.
    Un nodo de dominio de acceso (130) para aplicar políticas de tráfico a un flujo de servicio entre un dominio de usuario (120) y un servidor (110), que comprende:
    una memoria (600) adaptada para almacenar una plantilla de servicio (300) que comprende una dirección del servidor (310), un identificador de protocolo (380), y una o más políticas de tráfico (340);
    una lógica de control (640) adaptada para producir un conjunto de gestión de flujo de servicio (400) añadiendo una dirección del dominio de usuario (460) a la plantilla de servicio;
    un primer dispositivo de entrada-salida (620) adaptado para recibir un paquete que comprende una dirección de origen, una dirección de destino, un tipo de protocolo, y datos;
    un procesador de políticas (650) adaptado para identificar el conjunto de flujo de servicio haciendo coincidir la dirección de origen, la dirección de destino, y el tipo de protocolo con el conjunto de gestión de flujo de servicio, y aplicar la una o más políticas de tráfico a los datos; y
    un segundo dispositivo de entrada-salida adaptado para reenviar el paquete (610).
  26. 26.
    El nodo de dominio de acceso de la reivindicación 25, en donde: la una o más políticas de tráfico (340) comprenden parámetros de calidad de servicio.
  27. 27.
    El nodo de dominio de acceso de la reivindicación 25, en donde: la plantilla de servicio (300) además comprende un puerto de servidor (320); el conjunto de gestión de flujo de servicio (400) además comprende el puerto de servidor y un puerto de dominio de
    usuario (470); el paquete además comprende un puerto de origen y un puerto de destino; y el procesador de políticas (650) además identifica el conjunto de gestión de flujo de servicio haciendo coincidir el
    puerto de origen y el puerto de destino con el conjunto de gestión de flujo de servicio.
  28. 28. El nodo de dominio de acceso de la reivindicación 25, en donde:
    el flujo de servicio comprende una dirección de enlace ascendente y una dirección de enlace descendente; y
    el procesador de políticas (650) aplica (520) una selección de la una o más políticas de tráfico a los datos comprendidos en la dirección de enlace ascendente y otra selección (526) de la una o más políticas de tráfico a datos comprendidos en la dirección de enlace descendente.
  29. 29. El nodo de dominio de acceso de la reivindicación 25, en donde:
    el procesador de políticas (650) hace coincidir la dirección de origen, la dirección de destino, y el tipo de protocolo con la dirección del dominio de usuario, la dirección del servidor, y el identificador de protocolo.
ES08719530T 2007-03-12 2008-03-01 Aplicación de políticas para gestionar un flujo de servicio Active ES2433073T3 (es)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US684881 1984-12-21
US11/684,881 US7765312B2 (en) 2007-03-12 2007-03-12 Applying policies for managing a service flow
PCT/IB2008/050754 WO2008110955A2 (en) 2007-03-12 2008-03-01 Applying policies for managing a service flow

Publications (1)

Publication Number Publication Date
ES2433073T3 true ES2433073T3 (es) 2013-12-09

Family

ID=39760171

Family Applications (1)

Application Number Title Priority Date Filing Date
ES08719530T Active ES2433073T3 (es) 2007-03-12 2008-03-01 Aplicación de políticas para gestionar un flujo de servicio

Country Status (7)

Country Link
US (1) US7765312B2 (es)
EP (1) EP2130332B1 (es)
JP (1) JP4801204B2 (es)
CN (1) CN101641912B (es)
ES (1) ES2433073T3 (es)
PL (1) PL2130332T3 (es)
WO (1) WO2008110955A2 (es)

Families Citing this family (57)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8910241B2 (en) * 2002-04-25 2014-12-09 Citrix Systems, Inc. Computer security system
JP4256897B2 (ja) * 2006-06-16 2009-04-22 インターナショナル・ビジネス・マシーンズ・コーポレーション マッチング・サービスを提供するための装置、方法及びプログラム
US8156233B2 (en) * 2007-04-06 2012-04-10 Cisco Technology, Inc. Streaming of templates and data records in individual streams using a multistream protocol
JP4789864B2 (ja) * 2007-05-31 2011-10-12 株式会社日立製作所 ルータ装置
US20090006618A1 (en) * 2007-06-28 2009-01-01 Richard Hayton Methods and systems for access routing and resource mapping using filters
US9240945B2 (en) 2008-03-19 2016-01-19 Citrix Systems, Inc. Access, priority and bandwidth management based on application identity
GB2459291A (en) * 2008-04-17 2009-10-21 Zeus Technology Ltd Supplying web pages
US8346225B2 (en) * 2009-01-28 2013-01-01 Headwater Partners I, Llc Quality of service for device assisted services
US8495245B2 (en) * 2009-01-08 2013-07-23 Alcatel Lucent Connectivity, adjacencies and adaptation functions
US8276010B2 (en) * 2009-02-12 2012-09-25 Cisco Technology, Inc. Network based system to control and monitor power consumption of networked elements
US9535762B2 (en) * 2010-05-28 2017-01-03 At&T Intellectual Property I, L.P. Methods to improve overload protection for a home subscriber server (HSS)
US9319433B2 (en) 2010-06-29 2016-04-19 At&T Intellectual Property I, L.P. Prioritization of protocol messages at a server
US9336029B2 (en) 2010-08-04 2016-05-10 International Business Machines Corporation Determination via an indexed structure of one or more partitionable endpoints affected by an I/O message
US8495271B2 (en) * 2010-08-04 2013-07-23 International Business Machines Corporation Injection of I/O messages
US8549202B2 (en) 2010-08-04 2013-10-01 International Business Machines Corporation Interrupt source controller with scalable state structures
US9270472B2 (en) * 2011-03-29 2016-02-23 Time Warner Cable Enterprises Llc System and method for assigning a service flow classifier to a device
US9450836B2 (en) 2011-12-27 2016-09-20 Cisco Technology, Inc. System and method for management of network-based services
US9185025B2 (en) 2012-06-22 2015-11-10 Telefonaktiebolaget L M Ericsson (Publ) Internetworking and failure recovery in unified MPLS and IP networks
US8988985B2 (en) * 2012-06-22 2015-03-24 Telefonaktiebolaget L M Ericsson (Publ) Internetworking and IP address management in unified MPLS and IP networks
WO2014006692A1 (ja) 2012-07-03 2014-01-09 富士通株式会社 制御対象フロー特定プログラム、制御対象フロー特定方法および制御対象フロー特定装置
US8958294B2 (en) 2012-08-09 2015-02-17 Lenovo Enterprise Solutions (Singapore) Pte. Ltd. Assigning identifiers to mobile devices according to their data service requirements
EP2892190A4 (en) * 2012-09-06 2015-09-02 Huawei Tech Co Ltd METHOD FOR CONTROLLING NETWORK TRANSMISSION DELAY, SERVICE GOOD CONTROL UNIT AND COMMUNICATION DEVICE
CN103052172B (zh) * 2012-12-28 2015-10-28 上海寰创通信科技股份有限公司 一种WLAN子网端的PPPoE实现方法
US8954535B2 (en) * 2012-12-31 2015-02-10 Juniper Networks, Inc. Dynamic network device processing using external components
US10135732B2 (en) * 2012-12-31 2018-11-20 Juniper Networks, Inc. Remotely updating routing tables
US20140294006A1 (en) * 2013-03-29 2014-10-02 Alcaltel-Lucent Canada Inc. Direct service mapping for nat and pnat
CN104144156B (zh) * 2013-05-10 2018-09-21 华为技术有限公司 报文处理方法和装置
JP6108968B2 (ja) * 2013-06-06 2017-04-05 株式会社ソニー・インタラクティブエンタテインメント 通信処理装置および通信処理方法
US9319307B2 (en) 2013-09-06 2016-04-19 At&T Intellectual Property I, L.P. Providing differentiated service to traffic flows obscured by content distribution systems
DE112013007696T5 (de) * 2013-12-19 2016-09-22 Intel Corporation Dienstvorlagenerzeugung und -einsatz basierend auf Erfordernissen der Vereinbarung über die Verbindungsgüte
CN104202206A (zh) * 2014-07-25 2014-12-10 汉柏科技有限公司 报文处理装置及方法
CN104202249A (zh) * 2014-07-25 2014-12-10 汉柏科技有限公司 报文处理方法及装置
CN112906077A (zh) * 2014-11-14 2021-06-04 Nicira股份有限公司 无状态集群边缘上的有状态服务
US11533255B2 (en) 2014-11-14 2022-12-20 Nicira, Inc. Stateful services on stateless clustered edge
US10021221B2 (en) * 2015-02-24 2018-07-10 Citrix Systems, Inc. Methods and systems for detection and classification of multimedia content in secured transactions using pattern matching
US10432511B2 (en) * 2015-03-12 2019-10-01 Nec Corporation Method for forwarding data in a network, forwarding element for forwarding data, and a network for forwarding data
US10749808B1 (en) 2015-06-10 2020-08-18 Amazon Technologies, Inc. Network flow management for isolated virtual networks
US9998955B1 (en) * 2015-06-10 2018-06-12 Amazon Technologies, Inc. Multi-tier stateful network flow management architecture
US20170012751A1 (en) * 2015-07-07 2017-01-12 Huawei Technologies Co., Ltd. Multipoint Radio Link Control (RLC) Coordinator for Loosely Coordinated Multipoint Communications
JP6941102B2 (ja) * 2015-12-10 2021-09-29 マイクロソフト テクノロジー ライセンシング，エルエルシー 電気通信アプリケーションのデータ駆動型自動プロビジョニング
US10469381B2 (en) * 2016-07-27 2019-11-05 Cisco Technology, Inc. Localization of group based policies in a demand based overlay network
US10951584B2 (en) 2017-07-31 2021-03-16 Nicira, Inc. Methods for active-active stateful network service cluster
US11570092B2 (en) 2017-07-31 2023-01-31 Nicira, Inc. Methods for active-active stateful network service cluster
US11296984B2 (en) 2017-07-31 2022-04-05 Nicira, Inc. Use of hypervisor for active-active stateful network service cluster
CN109787801B (zh) * 2017-11-15 2022-01-21 华为技术有限公司 一种网络服务管理方法、装置和系统
US11153122B2 (en) 2018-02-19 2021-10-19 Nicira, Inc. Providing stateful services deployed in redundant gateways connected to asymmetric network
US11140020B1 (en) 2018-03-01 2021-10-05 Amazon Technologies, Inc. Availability-enhancing gateways for network traffic in virtualized computing environments
US11082338B1 (en) 2018-04-17 2021-08-03 Amazon Technologies, Inc. Distributed connection state tracking for large-volume network flows
US11108687B1 (en) 2018-09-12 2021-08-31 Amazon Technologies, Inc. Scalable network function virtualization service
US10834044B2 (en) 2018-09-19 2020-11-10 Amazon Technologies, Inc. Domain name system operations implemented using scalable virtual traffic hub
US11108686B1 (en) 2019-06-28 2021-08-31 Amazon Technologies, Inc. Port allocation at distributed network address translators
CN111009966A (zh) * 2019-11-22 2020-04-14 贵州电网有限责任公司 一种变电站设备的数据交互系统、方法、装置及存储介质
CN111314286B (zh) * 2019-12-20 2022-11-01 杭州迪普科技股份有限公司 安全访问控制策略的配置方法及装置
EP4107908A1 (en) * 2020-02-19 2022-12-28 Telefonaktiebolaget LM ERICSSON (PUBL) Data traffic control
CN113486100A (zh) * 2021-06-30 2021-10-08 中国民航信息网络股份有限公司 服务治理方法、装置、服务器及计算机存储介质
US11799761B2 (en) 2022-01-07 2023-10-24 Vmware, Inc. Scaling edge services with minimal disruption
US11962564B2 (en) 2022-02-15 2024-04-16 VMware LLC Anycast address for network address translation at edge

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6449650B1 (en) 1999-02-01 2002-09-10 Redback Networks Inc. Methods and apparatus for deploying quality of service policies on a data communication network
US7346677B1 (en) * 1999-07-02 2008-03-18 Cisco Technology, Inc. Method and apparatus for creating policies for policy-based management of quality of service treatments of network data traffic flows
WO2001013579A1 (fr) * 1999-08-18 2001-02-22 Fujitsu Limited Systeme et procede de repartition de charge dans un reseau, et support d'enregistrement destine au programme de ce systeme
GB9930428D0 (en) 1999-12-22 2000-02-16 Nortel Networks Corp A method of provisioning a route in a connectionless communications network such that a guaranteed quality of service is provided
AU2001238429A1 (en) 2000-02-18 2001-08-27 Cedere Corporation Method of automatically baselining business bandwidth
WO2002033428A1 (en) 2000-09-11 2002-04-25 Sitara Networks, Inc. Central policy manager
US7082102B1 (en) * 2000-10-19 2006-07-25 Bellsouth Intellectual Property Corp. Systems and methods for policy-enabled communications networks
US7102996B1 (en) * 2001-05-24 2006-09-05 F5 Networks, Inc. Method and system for scaling network traffic managers
US7760730B2 (en) * 2004-06-15 2010-07-20 Oracle America, Inc. Rule set verification
US7505463B2 (en) * 2004-06-15 2009-03-17 Sun Microsystems, Inc. Rule set conflict resolution
US8353003B2 (en) * 2004-10-01 2013-01-08 Exelis Inc. System and method for controlling a flow of data a network interface controller to a host processor
US20060075093A1 (en) * 2004-10-05 2006-04-06 Enterasys Networks, Inc. Using flow metric events to control network operation
US8077619B2 (en) 2005-02-14 2011-12-13 Telefonaktiebolaget L M Ericsson (Publ) Method for aggregating data traffic over an access domain and nodes therefor
US20070078955A1 (en) * 2005-09-15 2007-04-05 Xelor Software Pty Ltd Service quality management in packet networks

Also Published As

Publication number Publication date
WO2008110955A3 (en) 2009-09-03
US7765312B2 (en) 2010-07-27
CN101641912A (zh) 2010-02-03
CN101641912B (zh) 2013-09-11
WO2008110955A2 (en) 2008-09-18
JP4801204B2 (ja) 2011-10-26
PL2130332T3 (pl) 2014-01-31
EP2130332B1 (en) 2013-09-04
US20080228932A1 (en) 2008-09-18
EP2130332A2 (en) 2009-12-09
JP2010521857A (ja) 2010-06-24

Similar Documents

Publication Publication Date Title
ES2433073T3 (es) Aplicación de políticas para gestionar un flujo de servicio
US11575611B2 (en) Quality of service in packet networks
US10021034B2 (en) Application aware multihoming for data traffic acceleration in data communications networks
US9426078B2 (en) Systems and methods for dynamic quality of service
US9729663B2 (en) Dynamic/shared PMTU cache
WO2006085233A2 (en) Method for aggregating data traffic over an access domain and nodes therefor
US20170289225A1 (en) Optimizing media bitrate with explicit network feedback on one client only
Hauge et al. Multi-topology routing for qos support in the consis convoy manet
WO2011035582A1 (zh) WiMAX系统中多接口数据流负荷分担的方法及装置
Hoque et al. Barriers in seamless QoS for mobile applications
Loyall et al. A concept for publish-subscribe information dissemination and networking
Logota et al. A cross-layer resource over-provisioning architecture for P2P networks
Matsumoto et al. Source address selection policy distribution for multihoming
Lim Understanding the Impact of Congestion Control Algorithms on Emerging Networks and Applications
Sun IP networking and future evolution
Shah Performance Evaluation of MPLS in a Virtualized Service Provider Core (with/without Class of Service)
Brose et al. Multi-topology routing-QoS functionality and results from CoNSIS field experiment
Brennan Exploring Alternative Routes Using Multipath TCP
Vidal et al. Reducing the reservation establishment time in IP tunnels by using staged refresh timers
Pfeifer IPv6 Fragment Header Deprecated draft-bonica-6man-frag-deprecate-02