MXPA00001931A - Metodo para utilizarse en un servidor de paquetes. - Google Patents

Abstract

Se define un nuevo par de valores de atributo (AVP) para utilizarse en mensajes de control de protocolo de tunelizacion de 2 capas (L2TP) para soportar la negociacion de tuneles que tienen diferentes requerimientos de calidad de servicio (QoS). Ademas, se describen procedimientos de control de admision ilustrativos para aceptar o rechazar llamadas entrantes/salientes con diferentes requerimientos de calidad de servicio utilizando los tuneles negociados.

Description

MÉTODO PARA UTILIZARSE EN UN SERVIDOR DE PAQUETES Campo de la invención Esta invención se relaciona de manera general con comunicaciones y, de manera más particular, con sistemas de comunicaciones por paquetes. Antecedentes de la invención En el pasado, todo el tráfico de datos que usa la Internet era tratado igualmente y transportado utilizando un mecanismo del "mejor esfuerzo". Sin embargo, con el tiempo, la necesidad de soportar aplicaciones en tiempo real sobre la Internet (por ejemplo, herramientas para conferencias de audio/video, aplicaciones de juegos, etc.) necesitó alguna forma de ofrecer servicios diferenciados. Por lo tanto, los expertos en la técnica están definiendo nuevos protocolos para proporcionar calidad de servicio (QoS) a los usuarios de la Internet. Por ejemplo, el artículo "Una Arquitectura para Servicios Diferenciados", RFC2475, Diciembre de 1998 por S. Blake, et al., define seis bits dentro del Tipo de bit de Servicio (TOS) en el encabezado del protocolo de Internet (IP) para transportar un punto de código que representa una cierta QoS. De manera similar, el artículo "Un PHB de Envío Expedito", draft-ietf-diffserv-phb-ef-01.txt, Noviembre de REF.: 32813 1998, por V. Jacobson, et al., describe un punto de código específico que permite a los usuarios suscribirse a diferentes velocidades configuradas tales co o el servicio de Velocidad de Bits Constante (CBR) en ATM. Y, el artículo "Grupo de PHB de Envío Asegurado", draft-ietf-diffserv-af- 03.txt, Diciembre de 1998, por J. Heinanen, et al., describe otros tipos de servicios que son similares a los Servicios de Velocidad de bits Variable (VBR) en Tiempo Real/Tiempo no Real un ATM. Un uso de la Internet como un vehículo de comunicaciones es como un esqueleto de datos mejorado para acoplar grupos de trabajo juntos para proporcionar lo que se conoce como "red privada virtual" (VPN) . Una aplicación de la VPN es un ambiente corporativo tal como el de los empleados, por ejemplo, en casa, se puede tener acceso de manera remota, vía la Internet, a redes de datos corporativas. Una VPN proporciona seguridad, y autentificación, para que un usuario remoto se una a un grupo de usuarios cercano sin importar el uso de instalaciones públicas. En efecto, el uso de una VPN proporciona un vehículo similar a la WAN" a la compañía o corporación y sus empleados. (Aunque la red corporativa podría proporcionar también acceso remoto directo, por ejemplo, cuando un usuario marca directamente a la red corporativa, existen ventajas económicas para el uso de una VPN) .

Para proporcionar una VPN, se utilizan protocolos de tunelización tales como "Protocolo de Tunelización Punto a Punto" .(PPTP) y el protocolo de "Envío de 2 Capas" (L2F) . Hablando de manera general, un protocolo de túnel permite la creación de un flujo de datos privado vía una red pública colocando un paquete al lado de otro. En el contexto de una VPN, se coloca un paquete de IP a un lado de otro paquete de IP. En un intento por desarrollar un estándar en la industria, la Fuerza de Trabajo de Ingeniería de la Internet (IETF) se encuentra desarrollando el "Protocolo de Tunelización de 2 Capas" (L2PT) , el cual es un híbrido de los protocolos PPTP y L2F (por ejemplo, véase K. Hamzeh, T. Kolar, M. Littlewood, G. Singh Pall, J. Taarud, A. J. Valencia, W. Verthein; Protocol o de Tunelización de 2 Capas "L2TP"; redactado en la Internet, Marzo, 1998) . Para un usuario remoto, una forma típica de tener acceso a una VPN es vía una conexión "servicio telefónico del plan viejo" (POTS) a un "proveedor de servicios de Internet" (ISP) que proporcione el servicio VPN. Por ejemplo, un usuario incorpora un modera analógico a una computadora personal, o equivalente, y tiene una cuenta personal con un ISP particular, al que se hace referencia aquí como el ISP "local". (También se asumió que la computadora personal del usuario está configurada apropiadamente para soportar uno de los protocolos de tunelización mencionados anteriormente) . El usuario tiene acceso a la VPN simplemente haciendo una llamada de datos al ISP local, por ejemplo, marcando un número telefónico asociado con el ISP "local" y a continuación "registrándose con" la VPN. Como se hizo notar anteriormente, en el L2TP, se establece un túnel entre dos proveedores del servicio VPN para transportar un número de llamadas. Desafortunadamente, el protocolo L2TP anteriormente mencionado no resuelve los aspectos de "Calidad de Servicio" (QoS) (también conocidos como Servicios Diferenciales) . Por lo tanto, algunos usuarios pueden mostrarse reacios a adoptar el L2TP sin asegurar la QoS de modo que se garantice un ancho de banda mínimo para una llamada. En consecuencia, los expertos en la técnica han sugerido modificar el L2TP de modo que después de que se establezca el túnel, puedan negociarse una QoS por llamada utilizando únicamente un sólo valor de punto de código (por ejemplo, véase "Extensión de los Servicios Diferenciales de IP del Protocolo de Tunelización de 2 Capas" "L2TP", Julio 1998, draft-ietf-pppext-12tp-ds-02.txt@http: //www. ietf.org) Breve Descripción de la Invención Desafortunadamente, proporcionar una QoS por llamada utilizando un solo valor de punto de código no es una solución completa al problema. En particular, tener tal QoS por llamada requiere el uso de una velocidad de datos fija predeterminada para efectuar el control de admisión de la llamada. Además, si la QoS no puede ser acomodada por un L2TP, la llamada es negada. Por lo tanto, de acuerdo con los principios de la invención, se proporciona un método y un aparato para negociar primero túneles de L2TP que tienen diferentes requerimientos de QoS. En una modalidad de la invención, se definen los nuevos Pares de Valores de Atributo (AVP) para utilizarse en los mensajes de control L2TP (como se define en el L2TP, los AVP son utilizados para especificar mejor la señalización de control) . Esos nuevos AVP soportan la negociación de túneles dados los diferentes requerimientos de QoS. De manera ilustrativa, se proporciona un servicio de marcación virtual vía un Proveedor de Servicios de Internet (ISP) . Un ISP de servicio negocia un túnel para un servidor de red, el cual proporciona acceso a, por ejemplo, una intranet privada. Como resultado, se proporciona un servicio de red privada virtual (VPN) que permite acceso remoto, vía un túnel - que soporta una QoS particular - a una red privada. Los nuevos AVP incluyen parámetros de tráfico que permiten que los túneles tengan diferentes retrasos, pérdida de paquetes, y garanticen que se establezcan anchos de banda entre dos semejantes. Por lo tanto, esos AVP soportan sesiones de datos con diferentes requerimientos de retraso, etc. Además, se definen bits adicionales, tales como bits promovibles/reducibles, que permiten un punto final para incrementar o hacer disminuir la QoS de un túnel bajo ciertas condiciones. Por lo tanto, si la QoS inicial no puede ser acomodada por un L2TP semejante, ese semejante puede ser capaz de acomodar una QoS menor o mayor sin tener que rechazar la llamada. De acuerdo con una característica de la invención, se describen los procedimientos de control de admisión ilustrativos para aceptar o rechazar llamadas entrantes/salientes con diferentes requerimientos de calidad de servicio utilizando los túneles negociados.

Breve Descripción de los Dibujos La FIGURA 1 muestra un sistema de comunicación de acuerdo con los principios de la invención; Las FIGURAS 2-3 muestran diagramas de flujo de métodos ilustrativos para utilizarse en el sistema de comunicaciones de la FIGURA 1; La FIGURA 4 ilustra una transacción de mensajes de control para negociar un túnel de acuerdo con los principios de la invención; Las FIGURAS 5-6 ilustran nuevos mensajes L2TP del Par de Valores de Atributo para utilizarse de acuerdo con los principios de la invención; La FIGURA 7 ilustra un nuevo mensaje de control de L2TP para utilizarse de acuerdo con los principios de la invención; Las FIGURAS 8-9 ilustran otras transacciones de mensajes de control en comunicaciones semejantes de L2TP de acuerdo con los principios de la invención; La FIGURA 10 muestra un diagrama de flujo de un método ilustrativo para utilizarse para efectuar el control de admisión de llamadas; La FIGURA 11 muestra un diagrama de bloques de alto nivel, ilustrativo, de un Servidor de Acceso de Red; y La FIGURA 12 muestra otro sistema de comunicaciones de acuerdo con los principios de la invención.

Descripción Detallada La siguiente descripción se divide de manera general en dos partes . La primera parte describe la negociación de un túnel con una QoS particular. La segunda parte describe el control de admisión de llamadas para un conjunto de túneles negociados.

Negociación del Túnel La FIGURA 1 muestra un sistema de comunicaciones ilustrativo 100 de acuerdo con los principios de la invención. Además del concepto de la invención, los elementos son bien conocidos y no serán descritos en detalle. Por ejemplo, la computadora personal (PC) 110 incluye equipo de comunicación de datos (no mostrado) para el acceso por marcación a través de la red conmutada pública (PSTN) 110 al ISP A para establecer una conexión de Internet. De igual modo, las líneas sólidas entre los elementos del sistema de comunicaciones 100 son representativas de las instalaciones de comunicación bien conocidas entre los puntos finales respectivos, por ejemplo, la conexión entre la PC 110 y la PSTN 110 es representativa de una conexión de circuito local, la conexión entre el ISP A y la Internet 130 es soportada por el modo de transferencia asincrónica (ATM) sobre una red óptica sincrónica (SONET) , etc. Además, se asume que el lector está familiarizado con el protocolo L2TP anteriormente mencionado, el Servicio de Envío Expedito y el Servicio de Envío Asegurado. En este punto, se asumen las siguientes definiciones : mL2TP - el protocolo L2TP como se define en K. Hamzeh, T. Kolar, M. Littlewood, G. Singh Pall, J. Taarud, A. J. Valencia, W. Verthein; Protocolo de Tunelización de Dos Capas "L2TP"; redactado en la Internet; Marzo, 1998; más modificaciones como se describe alli . LAC - Control de Acceso mL2TP, es decir, un Servidor de Acceso a la Red (ÑAS) que soporta mL2TP; y LNS un Servidor de Red (NS) que soporta mL2TP; (Esas definiciones se utilizaron para simplificar una descripción ilustrativa del concepto de la invención. Por lo tanto, y co o aquellos expertos en la técnica comprenderán, el concepto de la invención no está limitado de este modo y puede aplicarse a cualquier protocolo de tunelización y equipo de procesamiento asociado) . Como puede observarse de la FIGURA 1, el sistema de comunicaciones 100 comprende el ISP A, de acuerdo a lo representado por la Red ISP A. El último comprende el LAC 155 (al que también se hace referencia como un "LAC de servicio") , el cual incluye un encaminador de punto de presencia (POP) (no mostrado) como es sabido en la técnica, una red local 160, y un encaminador 165. Se asume que el ISP A proporciona un servicio de VPN para empleados localizados remotamente para tener acceso a una Red Corporativa ilustrativa vía el LNS 135, el cual proporciona, entre otras funciones, una capacidad de encaminamiento y pared de fuego. (Se asume que la red Corporativa es por ejemplo, una colección de redes de área local (no mostradas) protegidas de manera adecuada detrás del LNS 135) . De acuerdo con el concepto de la invención, y como se describe mejor más adelante, se negocia un túnel entre la Red ISP A y el LNS 135 para proporcionar un QoS dado.

Ahora se hará referencia a la FIGURA 2, la cual muestra un diagrama de flujo de alto nivel ilustrativo de un método de acuerdo con los principios de la invención para proporcionar un servicio de VPN a un usuario remoto localizado en la PC 110. (Se presume que el LAC 115 y los otros servidores respectivos están programados adecuadamente para llevar a cabo los métodos descritos más adelante utilizando técnicas de programación convencionales, las cuales, como tales, no serán descritas aquí) . En el paso 205, el usuario remoto inicia una conexión de PPP (Protocolo Punto a Punto) al ISP A vía la PSTN 110. En el paso 210, el LAC 155 autentifica parcialmente al usuario (por ejemplo, utilizando un "nombre de usuario" y "contraseña" predefinidos) y acepta la conexión (representada por la línea punteada 1 de la FIGURA 1) . (De manera alternativa, podría ser utilizada la identificación DNIS (servicio de identificación del número marcado) , CLID (identificación de la línea que llama) , u otras formas equivalentes) . Obviamente, si el LAC 155 no puede autentificar al usuario, la conexión no es aceptada (este paso no se muestra) . (Como antecedente, y como es sabido en la técnica, cuando un usuario remoto desea establecer una nueva sesión PPP, la PC 110 inicia una Petición de Configuración de LCP (Protocolo de Control de Enlace) de PPP al LAC de Servicio. El LAC de Servicio completa las fases PPP LCP y PPP PAP/CHAP, como es sabido en la técnica, con el equipo del usuario antes de iniciar cualquier comunicación con un servidor de LNS de acuerdo con el concepto de la invención. (Para Conductos seguros, el IETF ha definido dos protocolos para asegurar conexiones sobre PPP - el Protocolo de Autentificación de Contraseña (PAP) y el Protocolo de Autentificación de Saludo Desafiante (CHAP) (por ejemplo, véase la Petición IETF para Comentarios (RFC) 1334, "Protocolos de Autentificación PPP") ) . En el paso 215, el LAC 155 determina si el usuario remoto desea utilizar un servicio de VPN. Esta señalización podría, por ejemplo, ser asociada directamente con "nombres de usuario" particulares y/o ser asociada con una petición separada del usuario, por ejemplo, vía una forma de "Protocolo, de Transporte de Hipertexto" (http) rápido proporcionado por el LAC 155) . Si el -usuario remoto no solicita un servicio de marcación virtual, el LAC 155 proporciona acceso a la Internet estándar en el paso 220. Sin embargo, si el usuario remoto desea utilizar una VPN, entonces el LAC 155 identifica un LNS asociado en el paso 225 (descrito más adelante) . El LAC 155 almacena una tabla de VPN que asocia a priori, por ejemplo, una identificación de usuario con un LNS particular. Una porción de tal tabla se muestra a continuación en la Tabla Uno. En este ejemplo, el usuario remoto asociado con la PC 110 está asociado con el LNS 135, que tiene una dirección de Protocolo de Internet (IP) representada de manera ilustrativa por la nomenclatura "g.h.i.j .".

Identificación del Usuario LN Nombre del Usuario g.h.i.j Tab] .a Uno (De manera alternativa, deberá notarse que podrán ser utilizadas estructuras, u operaciones, equivalentes. Por ejemplo, el LAC de Servicio también puede efectuar esta función vía los mensajes de Petición/Respuesta de Acceso de Radio con un Servidor de Radio Local)-. En el paso 230, el LAC 155 verifica para ver si existe un túnel entre sí mismo y el LNS 135. Por lo tanto, el LAC 155 mantiene una tabla, como se ilustra en la Tabla Dos, más adelante, de los túneles actuales, representados por un valor de identificación de túnel (Tid) , identificadores de llamadas (Cid) asociados de las llamadas que actualmente están utilizando ese túnel, y las direcciones de IP de LNS asociadas.

Tabla Dos Si actualmente no existe conexión de túnel entre el LAC 155 y el LNS 135, entonces se negocia un túnel en el paso 235 de acuerdo con el concepto de la invención (descrito más adelante) . Una vez que existe un túnel entre el LAC 155 y el LNS 135, el LAC 155 en el paso 240, el LAC 155 efectúa el control de admisión de la llamada (descrito más adelante) y, si la llamada es aceptada, le asigna un nuevo Cid, actualiza la Tabla Dos, e inicia una sesión con el LNS 135 enviando una petición de VPN al LNS 135 vía la red local 160, el encaminador 165, y la Internet 130. En esta petición, el LAC 155 lleva la información de identificación del usuario al LNS 135. (Si la llamada no es aceptada, se desconecta la llamada entrante) . Pasando ahora a la FIGURA 3, el LNS 135 recibe la petición en el paso 305. En el paso 310, el LNS 135 acepta la conexión PPP (al menos por un momento) . En el paso 315, el LNS 135 efectúa la autentificación del usuario remoto (por ejemplo, utilizando un "nombre de usuario" y "contraseña") predefinida como se hizo notar anteriormente. (De manera alternativa, al igual que el LAC, DNIS, CLID, podrían se utilizadas otras formas de identificación equivalentes) . Si el LNS 135 no puede autentificar al usuario, la conexión no es aceptada y el LNS 135 niega la petición en el paso 320. (En este caso, el LAC 155 debe llevar de manera similar un mensaje de error de regreso al usuario remoto (no mostrado) ) . Por el contrario, si el LNS 135 autentifica al usuario, el LNS 135 acepta la conexión (representada por la línea punteada 2 de la FIGURA 1) y establece la sección VPN en el paso 330. A diferencia del concepto de la invención, la sesión VPN con el LNS 135 se establece como en la técnica anterior. De manera ilustrativa, se asume que el LAC de Servicio mantiene la siguiente tabla de conexión por cada dirección de comunicación por cada sesión VPN establecida con un usuario remoto: Tabla Tres Esta tabla lista, por número de conexión, la Dirección de IP de LAC de Servicio, la Dirección de IP del LNS asociado (con los valores de la ID del túnel y la ID de la Llamada asociados para ese salto asociado) , y al usuario se le asigna la dirección de IP para esta llamada. Como tal, al establecer una nueva sesión VPN el LAC 155 asigna un nuevo Cid y actualiza la Tabla Tres (por ejemplo, agrega una nueva conexión) . En este punto, la conectividad es una sesión PPP punto a punto cuyos puntos finales son la aplicación de conexión a la red del usuario remoto en un extremo (de acuerdo a lo representado por la PC 110) y la terminación de esta conectividad en el soporte PPP de la LNS 135 en el otro. (Deberá notarse que puede efectuarse la contabilidad, si es necesario, en el LAC de Servicio, así como en el LNS, es decir, que cada elemento puede contar paquetes, octetos y los tiempos de inicio y fin de la conexión) . En el soporte del servicio de marcación virtual descrito anteriormente, y de acuerdo con el concepto de la invención, se utiliza una forma del protocolo L2TP (mL2TP) y se describe más adelante. Como en el L2TP, existen dos componentes paralelos del mL2TP que operan sobre un túnel dado: mensajes de control entre cada par de LAC-LNS, y un paquete de pago entre el mismo par LAC-LNS. Los últimos son utilizados para transportar paquetes PPP encapsulados por el L2TP para sesiones de usuario entre el par LAC-LNS. Como en el L2TP, los campos Nr (Siguiente Recibido) y Ns (Siguiente Enviado) están siempre presentes en los mensajes de control y opcionalmente están presentes en los paquetes de pago. Los mensajes de control y los mensajes de pago utilizan diferentes estados del número de secuencia. Para el escenario del par LAC/LNS mencionado anteriormente, no existen cambios en la definición del protocolo redactado L2TP puesto que está implicado el mantenimiento y uso de (Nr, Ns) . Como se hizo notar anteriormente, y de acuerdo con el concepto de la invención, antes de que pueda ocurrir la tunelización PPP entre el LAC de Servicio y el LNS, se negocia un túnel como se muestra en el paso 235 de la FIGURA 2 para proporcionar una QoS particular. Durante esta negociación, se intercambian mensajes de control mL2TP entre el LAC de Servicio y el LNS. Por lo tanto, se definen nuevos Pares de Valor de Atributo (AVP) (descritos más adelante) para utilizarse en los mensajes de control del L2TP (convirtiéndose en consecuencia en mensajes de control del mL2TP) para permitir que dos mL2TP similares establezcan, o negocien, túneles con diferentes requerimientos de calidad de servicio. Por lo tanto, deberá comprenderse que - además de la negociación del QoS adicional para establecer un túnel -los procedimientos de establecimiento de un túnel de L2TP no cambian. Una transacción de mensajes de control ilustrativa para efectuar la negociación del túnel se muestra en la FIGURA 4 entre dos mL2TP similares (aquí representados por un LAC y un LNS) . (Nuevamente, además de la inclusión de los nuevos AVP, esas transacciones de mensajes de control se especifican en el L2TP) . Como puede observarse de la FIGURA 4, el LAC (en este contexto, también referido aquí como el "iniciador del túnel") transmite un mensaje de Iniciar Conexión de Control (SCCRQ) que ahora incluye un Solicitar AVP_QoS (descrito más adelante) al LNS (en este contexto, también referido aquí como el "terminador del túnel") . En respuesta, el LNS envía un mensaje de Respuesta de Inicio de Control de Conexión (SCCRP) que ahora incluye un Otorgar AVP_QoS (descrito más adelante) al LAC. El LAC confirma con un mensaje de Conectar Conexión de Inicio de Control (SCCCN) al LNS. Pasando ahora a la FIGURA 5, se muestra un formato ilustrativo de un Solicitar AVP_QoS . Los primeros dos bits de este AVP " tienen un patrón de bits predefinido de "10" (como se define en el L2TP) , las porciones de bits, 2 hasta 5, contienen valores para los nuevos parámetros P, M, D y L, donde P es representativo de un bit promovible, M es representativo de un bit reducible, D es representativo de un bit de clase de retraso, y L es representativo de una clase de Pérdida. El bit D es el usado si el túnel solicitado soportará clases de retraso únicamente. En otras palabras, si el bit D es colocado en un mensaje SSCRQ, únicamente son tomados en consideración los bits de retraso del valor del punto de código diferenciado (descrito más adelante) . De manera similar, el bit L es utilizado si el túnel solicitado li soportará clases de pérdida únicamente, es decir, si el bit L es colocado en un mensaje de establecimiento de túnel (SSCRQ) , únicamente los bits de pérdida del punto de código son tomados en consideración. Los bits P y M son utilizados sobre una base por llamada e ignorados durante la negociación del túnel. Cuando los bits P y M representan un valor de cero, el rt?L2TP semejante indica que únicamente el valor del punto de código diferenciado elegido va a ser utilizado sobre paquetes IP dentro del canal de datos de la sesión. Cuando se fija el bit P, esto significa que el mL2TP similar puede recomendar un valor de punto de código de servicio diferenciado con un nivel de servicio mayor si el solicitado no está disponible para una llamada. Cuando se fija el bit M, significa que el mL2TP puede recomendar un valor de punto de código de servicio diferenciado co un nivel de servicio inferior si el solicitado no está disponible para una llamada. Como tal, los servicios diferenciados pueden ser ofrecidos por los ISP. Por ejemplo, un usuario puede comprar un servicio donde pague y dólares por la clase de prioridad de retraso 1 y x dólares por la clases de prioridad de retraso 2 ($y > $x) . Cada vez que el usuario haga una llamada, el mL2TP similar determina si hay suficientes recursos dentro del túnel que proporcionen la clase de prioridad de retraso 2 para admitir la petición del usuario. Si existen suficientes recursos, el mL2TP similar puede promover el punto de código al siguiente nivel superior (es decir tratar de ver si existen suficientes recursos para colocar la petición del usuario en otro túnel que proporciones la clase de prioridad de retraso 1) . Después de los bits P, M, D y L se encuentra un campo de 10 bits de longitud, el valor para el cual es el tamaño de este AVP. Después del campo largo, existe una ID específica del Vendedor de dos bytes (aquí mostrada de manera ilustrativa como aquélla que contiene los datos representativos de un identificador de Lucent (Lucentid) y que denota que éste es un mensaje de QoS de túnel) . (De manera alternativa, esta podría ser reemplazada por un código AVP de mL2TP predefinido que significa que éste es un mensaje de QoS de túnel) . La ID específica del Vendedor es seguida por un campo del tipo de atributo de L2TP de dos bytes, aquí fijado como 1. Después del campo del tipo de atributo, existe un valor de punto de código de servicios diferenciado (de dos bytes de longitud) , el cual es utilizado por el mL2TP semejante (aquí el LNS) para indicar que desea establecer un túnel que soporte una clase particular de servicio diferenciado. Los valores de los valores del punto de código de servicio diferenciado se definen en una forma similar a la definición de los puntos de código en el Servicio de Envío Asegurado (AF) anteriormente mencionado. En particular, los dos mL2TP semejantes pueden establecer clases de túneles A j, donde i representa un tipo de clase de retraso y j representa un tipo de clase de pérdida. Para propósitos de ejemplo únicamente, i = 1 , 2, 3, 4; y j = 1 , 2, 3. Por lo tanto, existen cuatro clases de túneles cada uno de los cuales soporta una clase de prioridad de retraso diferente, es decir, con puntos de código de servicio diferenciados Aix, I = 1 , 2, 3, 4, como se muestra en la tabla, a continuación.

Ciases de Prioridad de Retraso La "X" representa una condición de "sin cuidado", es decir, que el valor puede ser un cero binario o un uno binario. El guión entre los dos bytes es para mejorar la legibilidad únicamente. Las sesiones individuales con puntos de código de servicio diferenciados Aij son trazadas a un túnel que soporta el punto de código de servicio diferenciado Aix. De manera similar, el mL2TP semejante puede establecer tres clases de túneles cada uno soportando una clase de prioridad de pérdida diferente, es decir, con puntos de código de servicio diferenciados Aix, j = 1 , 2, 3. Las sesiones individuales con punto de código de servicio diferenciado Aij se trazan a un túnel que soporta el punto de código de servicio diferenciado Axj, como se muestra en la tabla, a continuación.

Clases de Prioridad de Pérdida (De manera alternativa, los dos L2TP semejantes pueden establecer un túnel específicamente para el punto de código de servicio diferenciado Ai y admitir únicamente sesiones individuales que soliciten el punto de código de servicio diferenciado Aij) .

De este modo, para servicios AF, los valores del punto de código de servicio diferenciado tales como OOlxxx o xxxOl O son aceptables para los túneles. Para el diseño de tráfico apropiado, se requiere que los dos mL2TP semejantes especifiquen una velocidad por cada túnel que soporte servicios AF. Con tal especificación, los L2TP semejantes pueden decidir cuando admitir/rechazar sesiones de datos. Ellos también pueden decidir como compartir los recursos disponibles (ancho de banda y memorias intermedias) entre los diferentes túneles establecidos. De manera similar, para el servicio de Envío Expedito (EF) mencionado inicialmente, el Solicitar AVP_QoS incluye el Punto de Código EF (es decir, el valor del punto de código de servicio diferenciado) , y la velocidad promedio solicitada. El campo de velocidad promedio, el campo del tamaño de ráfaga tolerable, el campo de tamaño de ráfaga en exceso, el campo de velocidad pico y el campo de requerimientos de pérdida/retraso representan los parámetros de tráfico que son utilizados para proporcionar túneles con garantías de retraso/pérdida cuantitativas así como para mejorar la probabilidad de admisión de llamadas (incrementar la multiplexión del ancho de banda) . En particular, el valor del campo de velocidad promedio representa los bits por segundo promedio solicitados para el túnel. La petición del valor de campo de tamaño de ráfaga tolerable representa qué tantos paguetes puede transmitir un transmisor a la velocidad pico. La petición de valor de campo de tamaño de ráfaga en exceso (opcional) representa qué tanto puede el transmisor exceder el tamaño de ráfaga tolerable. La petición de valor de campo pico representa la velocidad pico solicitada, por ejemplo, en bits por segundo. La petición de valor de campo de reguerimiento de pérdida/retraso representa la clase de pérdida (se fija el campo de L bits anteriormente mencionado) o retraso (se fija el campo de D bits anteriormente mencionado) de paquetes. Para la pérdida de paquetes, este valor representa el porcentaje de pérdida de paquetes tolerable, por ejemplo, 1%, 5%, etc. Para la clase de retraso, este valor representa el retraso tolerable, por ejemplo, en milisegundos. Los parámetros de tráfico adicionales anteriores son importantes. Por ejemplo, si el tamaño de ráfaga tolerable no es tomado en cuenta, entonces se restringe el manejo del ancho de banda. Como una ilustración adicional, considérese lo siguiente. Si existe un canal que soporte una clase AF Aij con un ancho de banda R y actualmente está soportando una sesión de datos con un ancho de banda Rl, una petición de una nueva sesión de datos que también esté solicitando la clase AF Aij con un ancho de banda requerido de R2 da como resultado la reducción del ancho de banda disponible restante (Re) a Re = R - (R1+R2) . Sin embargo, si se consideran las dos sesiones juntas, entonces puede ser necesario reservar únicamente Rg, donde Rg < (Rl + R2) y Rg > ri + r2, donde ri y r2 son las velocidades promedio para las sesiones de datos uno y dos, respectivamente. La FIGURA 6 muestra un formato ilustrativo para un Otorgar AVP_QoS enviado por un terminador de túnel (por ejemplo, LNS 135 de la FIGURA 1) en el mensaje SCCRP. Los campos del Otorgar AVP_QoS son complementarios a aquéllos de Solicitar AVP_QoS (descritos anteriormente) . En este caso, no existen bits PMDL, el servidor que responde indica la "Velocidad Otorgada" y el valor de Pérdida/Retraso Garantizado. La velocidad otorgada puede ser menor que la velocidad solicitada. Deberá notarse que el terminador del túnel puede incluir en el SCCRP otro Solicitar AVP_QoS para invertir el tráfico si existe tal necesidad. La respuesta del iniciador del túnel está contenida en el Otorgar AVP_QoS dentro de un mensaje SCCCN. Cuando se admiten más sesiones de datos, puede ser necesario sintonizar los parámetros de tráfico para los túneles existentes. El proceso de renegociar los parámetros de tráfico para los túneles existentes se conoce aquí como el proceso de sintonización del túnel. Además, para gozar mejor la ganancia de la multiplexión del ancho de banda, puede ser necesario que algunos túneles preconfigurados sean interrumpidos y las sesiones de datos existentes (soportadas por tales túneles) sean movidas a otro túnel. Este proceso se conoce aquí como reasignación de túnel. Nótese gue idealmente, esos dos procesos se ocurrirían sólo raramente. Por lo tanto, y de acuerdo con el concepto de la invención, están disponibles nuevos mensajes de L2TP para la renegociación, o sintonización de un túnel existente. Esos nuevos mensajes de L2TP son "actualizar el túnel" y "confirmar actualización". Por ejemplo, un mensaje de "actualizar túnel" es utilizado por un mL2TP semejante para informar a otro mL2TP semejante de los nuevos parámetros de tráfico solicitados para un túnel existente. El otro mL2TP semejante responde utilizando el mensaje de "confirmar actualización". Los mensajes de "actualizar túnel" y "confirmar actualización" utilizan el mismo formato que los AVP de Solicitar QoS y otorgar QoS, respectivamente, y, por lo tanto, no se muestran aquí. Un formato ilustrativo para un nuevo mensaje de reasignación de túnel se muestra en la FIGURA 7. Al igual que el mensaje de "actualizar túnel", un mensaje de reasignación de túnel se utiliza únicamente si se elige soportar el mecanismo de sintonización/renegociación del túnel. Este mensaje es utilizado por un mL2TP semejante para informar a otro mL2TP semejante que una sesión de datos particular ha sido movida a otro túnel. Este mensaje de mL2TP incluye la ID del túnel (vieja o existente), la ID de la llamada (vieja o existente) , la nueva ID del túnel, y la nueva ID de la llamada. Las posiciones de los bits T y L son como se definieron para el L2TP. Una vez que se establece un túnel que tiene una QoS particular, entonces necesita ser considerada la QoS sobre una base por llamada (o sesión individual) . Para una sesión individual, el LAC o LNS recibe la petición de establecer una llamada entrante para un usuario o saliente de un usuario. El LAC o LNS determina los parámetros de tráfico relevantes y la QoS (puntos de código) sobre la base del perfil definido a priori por el usuario. El LAC o LNS se comunica con un servidor de Autorización de Autentificación y Contabilidad (AAA) , como es sabido en la técnica, para obtener tales parámetros sobre la base del nombre del registro del usuario. Por ejemplo, un usuario puede comprar un servicio de línea de arrendamiento virtual (con un punto de código EF) de una velocidad particular. Por lo tanto, los parámetros de tráfico especificados por cada sesión individual, por ejemplo, velocidad promedio, tamaños de ráfaga tolerable/en exceso, velocidades pico, etc., son utilizados para propósitos de control de admisión. Tal información permite que diferentes mL2TP semejantes mantengan el seguimiento de los recursos disponibles para un túnel que soporta una clase de servicio particular. De este modo, existe un Solicitar AVP_QoS en los mensajes de Petición de Llamada Entrante (ICRQ) o Petición de Llamada Saliente (OCRQ) . Se presenta entonces un Otorgar AVP_QoS en el mensaje de Respuesta de Llamada Entrante (ICRP) y Respuesta de Llamada Saliente (OCRP) correspondiente. Esas transacciones de mensaje de control son ilustradas en las FIGURAS 8 y 9. Nótese además, que si se desea tener diferentes parámetros de tráfico en las direcciones corriente arriba o corriente abajo, entonces también puede estar presente un Solicitar AVP_QoS para la dirección inversa en los mensajes ICRP y OCRP en los mensajes ICRP y OCRP. Si está presente un Solicitar AVP_QoS en los mensajes ICRP y OCRP, entonces está presente un Otorgar AVP_QoS en los mensajes de Salida Entrante Conectada (ICCN) y Salida Saliente Conectada (OCCN) . La presencia de un Solicitar AVP_QoS en el ICRQ u OCRQ indica que un mL2TP semejante desea utilizar un punto de código de servicio diferenciado para todos los paquetes de datos de una sesión de datos particular. Si el rt?L2TP semejante no puede aceptar ese punto de código debido a un recorte de recursos, ese mL2TP no puede recomendar un punto de código alternativo si se fijan los bits Pro ovibles/Recortables anteriormente mencionados. De otro modo, el mL2TP rechaza la petición de llamada. De este modo, el valor encontrado en el Otorgar AVP_QoS indica el valor que el mL2TP semejante está dispuesto a aceptar.

Admisión de la Llamada En esta sección, se propone un algoritmo de control de admisión de llamadas genérico para ser utilizado por mL2TP semejantes en el manejo de las conexiones de túnel existentes (negociadas o no) . Este algoritmo de control de admisión de llamadas genérico se describe en contexto de dos ejemplos: túneles con diferentes requerimientos de retraso (a los que se hace referencia aquí como "túneles basados en el retraso") y túneles con diferentes requerimientos de pérdida (a los que se hace referencia aquí como "túneles basados en la pérdida") . Con respecto a los túneles basados en el retraso, se asumió que el retraso que un túnel garantiza satisface la siguiente ecuación: d = (b + C) /R + D, (1) donde d es el retraso solicitado por una nueva llamada (o sesión) , b es el tamaño de la ráfaga, R es el ancho de banda reservado para el túnel, y C y D son parámetros definidos como sigue. El retraso fluido de un flujo que obedece a una descripción de tráfico (r, d) , donde r es la velocidad promedio y b es el tamaño de la ráfaga) y que está siendo servido por una línea con un ancho de banda R es determinado por b/R en tanto R no sea menor que r. Dado el hecho de que estos son los paquetes que están siendo modelados, se definen dos términos de corrección de errores adicionales: C y D, los cuales describen la desviación máxima del modelo fluido. Por ejemplo, si el tamaño de la unidad de transferencia máxima (MTU) es de 512 bytes, y el valor de b es de 1500 bytes, entonces C es igual a: 3 x 512 o 1500 bytes puesto que debe ser procesado un número entero de paquetes. De manera similar, si una imple entación tiene vacíos ocasionales en el servicio (debido al procesamiento de otros mensajes), D necesita ser suficientemente grande para considerar el tiempo que puede perder una gramática de datos durante el vacío y el servicio (por ejemplo, D se expresa en milisegundos) . Para los propósitos de este primer ejemplo, se asumió que los túneles están ordenados en orden creciente del retraso que pueden garantizar (por ejemplo, en una tabla tal como la que se muestra en la Tabla Dos, más arriba) y que cada túnel está configurado con parámetros (bt Rt , Ct , Dt) donde bt es el tamaño de ráfaga tolerable, Rt es el ancho de banda reservado total para el túnel, Ct y Dt son ajustes debidos a la naturaleza del paquete y el superíndice T es la id del túnel . Dados N túneles, cada uno con una garantía de retraso de dxt , y una nueva sesión de datos con la petición (b, r , p, d) , donde r es la velocidad promedio, p es la velocidad pico, y d es el retraso solicitado por una nueva sesión de datos, se utiliza el siguiente algoritmo para admitir o rechazar una nueva sesión de datos así co o para determinar el túnel apropiado para transportar el tráfico de la nueva sesión de datos: Se utilizaron las siguientes definiciones: BUri = la suma de los tamaños de ráfagas tolerables de todas las sesiones admitidas para ese túnel; RUti = la velocidad que se requiere para soportar un retraso de d¿t, para todas las sesiones (o llamadas) admitidas, Ro,i - la suma de la velocidad promedio de todas las sesiones admitidas para ese túnel, es decir, Rofl = ^ '_ rk , donde n es el número de sesiones de datos admitidas en ese túnel; (b, r, p, d) = el vector de solicitud de llamada de pérdida de retraso que comprende: b - el tamaño de ráfaga tolerable, r - velocidad promedio, p - velocidad pico y d - requerimiento de retraso de esa sesión de datos; (b, r, p, pl ) = el vector de petición de llamada de probabilidad de pérdida que comprende: b - tamaño de ráfaga tolerable, r - velocidad promedio, p - velocidad pico y pl - requerimiento de probabilidad de pérdida de esa sesión de datos; (Rt, Bt, dt) vector de uso del túnel de pérdida de retraso que comprende: R - ancho de banda reservado total para el túnel, B tamaño de ráfaga tolerable total para el túnel, y dr - requerimiento de retraso para el túnel; y (Rt, Bt, PLT) = vector de uso del túnel de probabilidad de pérdida que comprende: Rt - ancho de banda reservado total para el túnel, Br - tamaño de ráfaga tolerable total para el túnel, y PL requerimiento de probabilidad de pérdida de esa sesión del túnel. También deberá hacerse referencia a la Figura 10 la cual, muestra un diagrama de flujo genérico de como el algoritmo controla la admisión de llamadas. Para los propósitos de esta descripción se asumió que el LNS 155 de la Figura 1 efectúa este algoritmo de control de admisión de llamadas. (Sin embargo, cualquier LAC o LNS puede hacerlo) . El paso 705 de la Figura 10 representa el inicio del proceso. Tras una determinación en el paso 705 de que necesita ser admitido una nueva llamada, el LNS 155 ejecuta el paso 710. Como se hizo notar anteriormente, se asumió que el LNS 155 mantiene una tabla de túneles (los cuales son candidatos para la llamada entrante) arreglados en orden creciente de retraso. Por cada túnel, i, con df menor que d, el LNS 155 calcula en el paso 710: "nuevo, i — Í5U x + D, (2) R-nuevo, i — (J- uevo, i ' ) / Q.-JJ) (3) O H-nuevo, i " ^u, i (4) donde Bnuev? i es el nuevo canal de ráfaga requerido por el túnel i, si la nueva llamada es admitida, RnUevo, i es el ancho de banda que se requiere para soportar todas las sesiones si esta nueva sesión de datos fuera admitida, y d es la diferencia entre los anchos de banda nuevo y viejo. En el paso 715, el LNS 155 verifica si el nuevo ancho de banda, Rnuevo, i es menor que la suma de la velocidad promedio para todos los túneles, RQ, x, y r. Si es así, entonces el LNS 155 fija d=r en el paso 720. Si no, el LNS 155 procede directamente al paso 725. En el paso 725, el LNS 155 efectúa los siguientes cálculos: ?nue o, 2 -' HÍ, i "^ Re *; - Rnu y ( 6 ¡ Be — Bt - BnueV0f -_ ' ( 7 ) donde Re es el ancho de banda restante disponible para el túnel y Be es el tamaño de ráfaga restante disponible para el túnel (por ejemplo, este puede ser trazado como una función del espacio en la memoria intermedia restante) .

En el paso 730, el LNC 155 selecciona un conjunto de "túneles factibles". Es decir, aquellos túneles para los cuales Re > 0, Bnuevo < Bf , y df < d. En el paso 740, el LNC 155 elige aquel túnel del conjunto de túneles factibles que de el Re mínimo. Si existen más de uno de tales túneles, el LNC 155 elige el túnel que también da Be menor. Este método proporciona un "empaque máximo" de llamadas en el túnel. De manera alterativa, el LNC 155 puede "empaque mínimo" de llamadas, en un túnel. En este caso, en el paso 740, el LNC 155 elige aquel túnel del conjunto de túneles factibles que de el Re máximo. Si existe más de uno de tales túneles, el LNC 155 elige el túnel que también da el Be más grande. De manera similar el LNC 155 puede admitir llamadas en un túnel de acuerdo con un método de "ancho de banda mínimo". En este caso, en el paso 740, el LNC elige aquel túnel del conjunto de túneles factibles que den la d menor. Si existe más de uno de tales túneles, el LNC 155 elige el túnel que también da el Re más pequeño. Como se hizo notar anteriormente, también se presentó una técnica de control de admisión de llamadas similar para túneles basados en las pérdidas. Esta técnica es similar a la técnica de control de admisión de llamadas mencionada anteriormente para túneles basados en el retraso y utiliza el algoritmo de control de admisión de llamadas genérico mostrado en la Figura 10. Para los propósitos de esta descripción se asumió que el LNS 155 de la Figura 1 efectúa ese algoritmo de control de admisión de llamadas. Nuevamente, se asumió que los túneles están ordenados en orden creciente de la probabilidad de pérdida que pueden garantizar (por ejemplo, en una tabla tal como la que se muestra en la Tabla Dos, anteriormente) y que cada túnel está configurado con los parámetros (bt, Rt, PLT) , donde bt es el tamaño de ráfaga tolerable, Rt es el ancho de banda reservado promedio para el túnel, y PLT es la probabilidad de pérdida que el túnel puede garantizar. Se definió la siguiente función: R = f (b, r, p, pl ) , (8) donde f es una función que da el ancho de banda que necesita ser reservado para asegurar una probabilidad de pérdida de pl dado un tráfico con una velocidad pico p, velocidad de promedio r, y tamaño de ráfaga b. Una función ilustrativa puede encontrarse en el artículo "Evaluación de Capacidad de un Sistema Inalámbrico de Acceso a la Internet", por M.C. Chuah, W. Matragi, y S. Dravida, Proceedings of NetlnterOp 98. Nuevamente, el paso 705 de la Figura 11 representa el inicio del proceso. Tras una determinación en el paso 705 de que necesita ser admitida una nueva llamada, el LNS 155 ejecuta el paso 710. Como se hizo notar anteriormente, si se asume que el LNS 155 mantiene una tabla de túneles (los cuales son candidatos para la llamada entrante) arreglados en orden creciente de la probabilidad de pérdida que pueden garantizar. Por cada túnel, i, y Pf menor que p, el LNS 155 calcula en el paso 710: B. nuevo, i ^ , ± *~ -O , (9) Rnuevo, j. = (Bnuevo, i + C) / (d~D) f y (10) (11) donde Bnuev?/ ± es el nuevo canal de ráfaga requerido por el túnel i, si la nueva llamada es admitida, Rnue o, _. es el ancho de banda que se requiere para soportar todas las sesiones si esta nueva sesión de datos fuera admitida, y d es la diferencia entre los anchos de banda nuevo y viejo. En el paso 715, el LNS 155 verifica si el nuevo ancho de banda, Rnuevo - es menor que la suma de la velocidad promedio para todos los túneles, Ro, ±, y r. Si es así, entonces el LNS 155 fija d=r en el paso 720. Si no, el LNS 155 procede directamente al paso 725. En el paso 725, el LNS 155 efectúa los siguientes cálculos: Rnuevo, i ^- , i """ , : i2 ) Be = Pf - Bnu ( 14 ) donde Pe es el ancho de banda restante disponible para el túnel y Be es el tamaño de ráfaga restante disponible para el túnel (por ejemplo, éste puede ser trazado como una función del espacio en la memoria intermedia restante) . En el paso 730, el LNC 155 selecciona un conjunto de "túneles factibles". Es decir, aquéllos túneles para los cuales Pe > 0, Bnuevo < Btt , y df = d. En el paso 740, el LNC 155 elige aquel túnel del conjunto de túneles factibles que de el Pe mínimo. Si existen más de uno de tales túneles, el LNC 155 elige el túnel que también da Be menor. Este método proporciona un "empaque máximo" de llamadas en el túnel. De manera similar, el LNC 155, puede admitir llamadas en un túnel de acuerdo con un método de "ancho de banda mínimo". En este caso, en el paso 740, el LNC 155 elige el túnel del conjunto de túneles factibles que den d menor.

Si existen más de uno de tales túneles, el LNC 155 elige el túnel que también de el Pe más pequeño. Como puede observarse de lo anterior, ha sido descrita una extensión de la calidad de servicio flexible para L2TP. Este método permite a los L2TP semejantes proporcionar garantías de retraso/pérdida cuantitativas a los usuarios finales en una arquitectura de servicio diferencial.

Además, se describieron algoritmos de control de admisión de llamadas nuevos para ser utilizados por L2TP semejantes.

Pasando brevemente a la Figura 11, en ella se muestra un diagrama de bloques de alto nivel de un ÑAS representativo (L2TP) semejante) de acuerdo con los principios de la invención. Un ÑAS es una arquitectura de procesador basada en el control del programa almacenado e incluye el procesador 650, la memoria 660 (para almacenar instrucciones de programa y datos, por ejemplo, para comunicar los mensajes AVP mencionados anteriormente relacionados con la QoS, etc.) y las interfaces de comunicaciones 665 para acoplarse a uno o más dispositivos de comunicación como los representados por la trayectoria 666. Lo anterior únicamente ilustra los principios de la invención y de este odo se apreciará que aquéllos expertos en la técnica serán capaces de idear numerosos arreglos alternativos los cuales, aunque no descritos explícitamente aquí, incorporan los principios de la presente invención y están dentro de su espíritu y alcance. Por ejemplo, aunque el concepto de la invención fue descrito en el contexto de una tunelización de LAC de Servicio a un LNS, el concepto de la invención es aplicado a túneles de saltos múltiples, como por ejemplo, tal como se describe en la solicitud de Patente Estadounidense o también comúnmente asignada de Chuah et al., titulada "Protocolo Punta a Punto de Saltos Múltiples", No. de Serie 09/074745, presentado en Mayo 5, 1998. Además, aunque el concepto de la invención puede ser descrito en términos del L2TP, deberá notarse que tales negociaciones de QoS para un túnel (y la subsecuente admisión de la llamada) pueden ser efectuados de manera equivalente por servidores de Autorización de Autentificación y Contabilidad (AAA) como se muestra en la Figura 12. El sistema de comunicaciones de la Figura 12 es similar a la de la Figura 1 excepto que el ÑAS y el NS se comunican cada uno con un servidor AAA. Los servidores AAA correspondientes negocian entonces la QoS del túnel utilizando los AVP modificados de manera adecuada, descritos anteriormente. Se hace constar que con relación a esta fecha, el mejor método conocido por la solicitante para llevar a la práctica la citada invención, es el que resulta claro de la presente descripción de la invención.

Claims (21)

1. REIVINDICACIONES
2. . Habiéndose descrito la invención como antecede, se reclama como propiedad lo contenido en las siguientes reivindicaciones . 1. Un método para utilizarse en un servidor de paquetes, el método se caracteriza porque comprende los pasos de: determinar que necesita establecerse un túnel de paquetes con otro servidor de paquetes; y establecer el túnel de paquetes de modo que se negocie una Calidad de Servicio (Qos) particular para el túnel de paquetes entre los servidores de paquetes utilizando un protocolo basado en el Protocolo de Tunelización de Dos
3. Capas (L2TP) . 2. El método de conformidad con la reivindicación 1, caracterizado porque el paso de establecimiento incluye el paso de enviar, al otro servidor de paquetes, un mensaje de petición de QoS que comprende parámetros de QoS que representan una QoS solicitada por el túnel de paquete. 3. El método de conformidad con la reivindicación 1, caracterizado porque comprende además el paso de admitir una llamada al túnel de paquetes establecido, de modo que la admisión de la llamada incluye el paso de enviar, al otro servidor de paquetes, un mensaje de petición de QoS que comprende parámetros de QoS que representan una QoS solicitada para la llamada donde los parámetros de la QoS incluyen un bit promovible que permite que el otro servidor de paquetes recomiende una QoS mayor para la llamada diferente a la QoS solicitada.
4. 4. El método de conformidad con la reivindicación 1, caracterizado porque comprende además el paso de admitir una llamada al túnel de paquetes establecido, de modo que la admisión de la llamada incluye el paso de enviar, al otro servidor de paquetes, un mensaje de petición de QoS que comprende parámetros de QoS que representan una QoS solicitada por la llamada, donde los parámetros de la QoS incluyen un bit reducible que permite que el otro servidor de paquetes recomiende una QoS menor para la llamada que la QoS solicitada.
5. 5. El método de conformidad con la reivindicación 2, caracterizado porque los parámetros de la QoS incluyen un bit de clase de retraso que especifica el túnel de paquetes que soportará clases de retraso únicamente.
6. 6. El método de conformidad con la reivindicación 2, caracterizado porque los parámetros de la QoS incluyen una probabilidad de bits de pérdida que especifica el túnel de paquetes que soportará clases de pérdida únicamente.
7. 7. El método de conformidad con la reivindicación 2, caracterizado porque los parámetros de la QoS incluyen un campo de velocidad solicitada, un campo de tamaño de ráfaga tolerable, un campo de tamaño de ráfaga en exceso, y un campo de velocidad pico.
8. 8. El método de conformidad con la reivindicación 2, caracterizado porque los parámetros de la QoS incluyen un campo de pérdida/retraso que representa una cantidad de pérdida de paquetes o una cantidad de retraso de paquetes para el túnel de paquetes .
9. 9. El método de conformidad con la reivindicación 2, caracterizado porque el mensaje de petición del QoS es parte de un mensaje de Petición de Conexión de Inicio de Control (SCCRQ) del Protocolo de Tunelización de Dos Capas (L2TP) .
10. 10. El método de conformidad con la reivindicación 2, caracterizado porque el paso de establecimiento incluye el paso de recibir, del otro servidor de paquetes, un mensaje que otorga la QoS que incluye los parámetros de la QoS otorgada que representan una QoS otorgada para el túnel de paquetes .
11. 11. El método de conformidad con la reivindicación 10, caracterizado porque los parámetros de la QoS incluyen un campo de velocidad otorgada, una campo de tamaño de ráfaga tolerable, un campo de tamaño de ráfaga en exceso, y un campo de velocidad pico.
12. 12. El método de conformidad con la reivindicación 10, caracterizado porque los parámetros de la QoS incluyen un campo de pérdida/retraso garantizado que representa una cantidad de pérdida de paquetes o una cantidad de retraso de paquetes para el túnel de paquetes.
13. 13. El método de conformidad con la reivindicación 10, caracterizado porque el mensaje de otorgamiento del QoS es parte del mensaje de Respuesta de Conexión de Inicio de Control (SCCRP) del Protocolo de Tunelización de Dos Capas (L2TP) .
14. 14. El método de conformidad con la reivindicación 1, caracterizado porgue comprende además el paso de sintonizar un túnel establecido intercambiando mensajes de actualización del túnel y de confirmación de la actualización, donde el paso de sintonización cambia un parámetro de la QoS del túnel negociado previamente para el túnel establecido.
15. 15. El método de conformidad con la reivindicación 1, caracterizado porque comprende además el paso de reasignar un túnel establecido, de modo que al menos una llamada soportada por el túnel establecido se mueva a un túnel diferente.
16. 16. El método de conformidad con la reivindicación 1, caracterizado porque comprende además el paso de admitir una llamada para utilizar el túnel de paquetes establecido negociando primero una QoS para la llamada con el otro servidor de paquetes.
17. 17. El método de conformidad con la reivindicación 1, caracterizado porque comprende además un método de admisión de control de llamadas para utilizarse para admitir una nueva llamada al túnel de paquetes establecido, el método se caracteriza porque comprende los pasos de: determinar por cada túnel de paquetes establecido un vector de uso del túnel que representa el uso de cada túnel de paquetes establecido, respectivo; determinar para la nueva llamada un vector de petición de llamada; determinar un nuevo ancho de banda como función de al menos los vectores de uso del túnel y el vector de petición de llamada; sí el nuevo ancho de banda es menor que la suma de una velocidad promedio para todos los túneles de paquetes establecidos y la velocidad para la nueva llamada, seleccionar entonces un conjunto de túneles factibles para soportar la nueva llamada; y seleccionar un túnel de paquetes establecido, para soportar la nueva llamada, del conjunto de túneles factibles como función de un criterio de selección de túnel.
18. 18. El método de conformidad con la reivindicación 17, caracterizado porque el criterio de selección del túnel empaca un número máximo de llamadas en túnel.
19. 19. El método de conformidad con la reivindicación 17, caracterizado porque el criterio de selección del túnel empaca un número mínimo de llamadas en túnel.
20. 20. El método de conformidad con la reivindicación 17, caracterizado porque el criterio de selección del túnel es de acuerdo con un método de ancho de banda mínimo .
21. 21. El método de conformidad con la reivindicación 1, caracterizado porque el servidor de paquetes comunica paquetes del Protocolo de Internet (IP) , y el método comprende además el paso de proporcionar acceso, utilizando el túnel establecido, a un servicio de red privada virtual para ser utilizado por los usuarios que establecen conexiones del protocolo punto a punto con el servidor de paquetes. ** MÉTODO PARA UTILIZARSE EN UN SERVIDOR DE PAQUETES RESUMEN DE LA INVENCIÓN Se define un Nuevo Par de Valores de Atributo (AVP) para utilizarse en mensajes de control del Protocolo de Tunelizacíón de 2 Capas (L2TP) para soportar la negociación de túneles que tienen diferentes requerimientos de calidad de servicio (QoS) . Además, se describen procedimientos de control de admisión ilustrativos para aceptar o rechazar llamadas entrantes/salientes con diferentes requerimientos de 10 calidad de servicio utilizando los túneles negociados. 15 20 25