MXPA98005407A - Servicio de datos conmutado por relevador de cuadro - Google Patents

Abstract

La presente invención se refiere a un nuevo tipo de servicio para el transporte de datos, el cual utiliza un identificador de conexión del enlace de datos, de la capa 2, de relevador de cuadros, (DLCI) para seleccionar entre varios tipos de servicios, grupos de características y/o grupos cerrados de usuarios (CUGs). Puede extraerse una dirección de la capa 3 a partir de un cuadro de la capa 2, y la información de dirección de la capa 3 puede ser utilizada para encaminar paquetes de datos sobre una red de conmutación de paquetes de acuerdo con las clases de servicios, los grupos de características, y/o CUGs seleccionados. En el destino, el paquete de datos de la capa 3 puede ser encerrado, otra vez, en un cuadro de la capa 2 con un DLCI que indique las clases de servicios, los grupos de características, y/o los CUGs. Debido a que no es necesario el uso de circuitos virtuales, permanentes, convencionales (PVCs), en los aspectos de la invención, se presentan nuevos métodos para la medición y la administración del tráfico de la red.

Description

SERVICIO DE DATOS CONMUTADO POR RELEVADOR DE CUADRO ANTECEDENTES DE LA INVENCIÓN 1. Campo de la invención. La presente invención se dirige a sistemas y métodos para implementar arquitecturas mejoradas de redes, y más específicamente para sistemas y métodos para encaminar paquetes de protocolo interredes (IP) utilizando protocolos de relevador de cuadro modificado. 2. Descripción de la técnica relacionada. Recientemente, se ha incrementado la popularidad de las grandes redes de "malla". Sin embargo, las redes de gran escala altamente reticuladas pueden ser difíciles de implementar, dar mantenimiento y manejar utilizando las tecnologías convencionales de red. Un ejemplo de una configuración convencional de malla se muestra en la Figura 1. Una red de gran amplitud (WAN -wide-area network), 900, incluye una pluralidad de encaminadores RA, RB, e, RD, (equipo en el establecimiento del cliente (CPE)) colocados respectivamente en una pluralidad de ubicaciones del usuario final, A, B, C, y D, y que están interconectados con una red del proveedor de servicios (SPN), 901, via interconexiones respectivas usuario-red (UNÍ) 920-1, -2, ..., -n. Las interconexiones usuario-red, 920, pueden estar configuradas de varias maneras para ser, por REF.: 27459 ejemplo, un conmutador de modo de transferencia asincrono (ATM) , que tiene una interconexión de relevador de cuadro con el CPE. Conectando los sitios entre si se encuentran trayectorias lógicas llamadas, por ejemplo, circuitos virtuales permanentes (PVCs), PA-c/ PA-D» PB-D, PA-B, PC-B, que se caracterizan por sus extremos finales en las UNIs, 920-1, 920-2, ..., 920-n, y un ancho de banda garantizado llamado la tasa de la información comprometida (CIR) . La Figura 2 proporciona una vista detallada del flujo de datos a través de la WAN 900. Existe una pluralidad de capas de protocolo sobre las cuales pueden presentarse las comunicaciones. Por ejemplo las capas bien conocidas del Modelo de Interconexión de Sistemas Abiertos de la Organización de Estándares Internacionales (ISO), que tiene capas a partir de una capa física (capa 1), una capa para el enlace de datos (capa 2), una capa de red (capa 4), hasta, e incluyendo, una capa de aplicación (capa 7) . Bajo este modelo, los datos del usuario 902, se generan por una aplicación del usuario que corre en la capa de aplicación, 903. En la capa de transporte, (capa 4), 904, una dirección del puerto de origen y de destino, 906 (como parte del iniciador TCP (capa 4)), puede ser adicionado a los datos del usuario, 902. En la capa de la red (capa 3), 905, puede adicionarse un iniciador adicional (i.e., un iniciador IP (capa 3)) que contiene las direcciones IP de origen y de destino, 908. Por consiguiente, el campo de datos del usuario, de la capa 3, incluye los datos del usuario de la capa 4, 902, más el iniciador de la capa 4, 906. La unidad de datos del protocolo de la capa 3 (PDU), 902, 906, 908, que forma, por ejemplo, un paquete IP, 950, se hace pasar entonces hacia la capa 2, 909, en el CPE (encaminadores RA, B RC, RD) ue se interconecta con el SPN 901. En el encaminador, una tabla mapea una o más direcciones IP (capa 3), 908, hacia un PVC o PVCs adecuado (s) (PA-c, PA-D/ PB-D, PA-B, PC-B) - La tabla del encaminador es mantenida por el cliente. Una vez que se localiza el PVC correcto en la tabla de encaminamiento, el identificador de conexión del enlace de datos correspondiente (DLCI) (capa 2), 912, es codificado en el iniciador del cuadro del relevador de cuadro, 914 (paquete) . Posteriormente se incluye el resto del cuadro del relevador de cuadro y se calcula una suma de verificación del cuadro (FCS) . Entonces el cuadro se hace pasar hacia abajo, hacia la capa física, y es transmitido hacia el SPN 901. En el UNÍ 920, se verifica la validez del cuadro para determinar si existe un PVC predefinido, asociado con el DLCI 912. Si este es el caso, el cuadro 914 se hace avanzar entonces sobre ese PVC, a través de la red, a lo largo del mismo recorrido y en el mismo orden que otros cuadros con ese DLCI, como se muestra en la Figura 2. La información del cuadro de la capa 2 permanece a medida que el paquete atraviesa la red del relevador de cuadro, ya sea que esta red sea implementada realmente como una red de relevador de cuadro u otro tipo de red, como una red ATM. El cuadro es llevado hacia su destino sin realizar decisiones adicionales de asignación de ruta en la red. El FCS es verificado en el UNÍ que emerge, y si el cuadro no se encuentra corrompido, entonces es enviado hacia la UNÍ asociada con el usuario final. Es bien sabido en la técnica, Figuras 1-3, proporcionar diagramas ejemplares de cómo son ensamblados los paquetes de datos del relevador de cuadro en las diversas capas ISO utilizando el ejemplo del transporte del protocolo TCP/IP sobre una capa de enlace de datos del relevador de cuadro. El ejemplo muestra cómo son "envueltos" los datos del usuario en la capa de aplicación, en cubiertas sucesivas, formando las PDUs, a medida que pasa hacia la pila de protocolos. Específicamente, la composición del campo de Iniciador se muestra expandida para observar sus detalles y se muestra en la Figura 5. El campo del identificador de conexión del enlace de datos (DLCI) comprende 10 bits distribuidos sobre el primero y segundo octetos, y permite 1023 posibles direcciones, de las cuales algunas están reservadas para usos específicos por los estándares. Como se muestra en la Figura 3, el DLCI es adicionado al iniciador del relevador de cuadro de acuerdo con la dirección IP de destino que se especifique en el paquete de IP. La decisión sobre qué DLCI es elegido es realizada por el CPE, generalmente un encaminador, basado en información sobre la configuración proporcionada por el usuario que proporciona un mapeo de las direcciones IP en los PVCs que conectan la ubicación real con otros a través de la WAN 900. En el relevador de cuadro convencional, un cuadro Q.922, de la capa 2, lleva el paquete de datos del usuario, de la capa 3, a través de la red, en un circuito virtual permanente (PVC) que es identificado por medio de un identificador de conexión del enlace de datos (DLCI) . Por consiguiente, los DLCIs son utilizados por el usuario como direcciones que seleccionan el PVC adecuado para llevar los datos hacia el destino deseado. El paquete de datos del usuario es llevado a través de la red de manera transparente y su contenido nunca es examinado por la red . La red reticulada con relevador de cuadro, convencional, discutida anteriormente tiene ciertas limitaciones. Por ejemplo,' cada vez que se adiciona una nueva ubicación de usuario final a la red reticulada, se requiere que se adicione una nueva conexión a cada ubicación del usuario final. Como consecuencia, todas las tablas de encaminamiento deben ser actualizadas en cada ubicación de usuario final. Por consiguiente, un efecto de "rizo" se propaga a través de toda la red siempre que existe un cambio en la topología de la red. Para las redes grandes, con miles de ubicaciones de usuario final, este efecto de rizo crea una gran carga tanto en el proveedor de la red, para proporcionar suficientes circuitos virtuales permanentes (PVCs), y en los usuarios de la red al actualizar todas sus tablas de encaminamiento. Además, la mayor parte de los encaminadores están limitados a emparejarse con un máximo de 10 encaminadores más, lo cual hace que la topología de la red sea difícil de implementar. A medida que las redes crecen en tamaño, el número de PVCs que los usuarios necesitan manejar y mapear en los DLCIs incrementa. Además, complicando el problema se encuentra una tendencia hacia el incremento de la "reticularidad" ( "meshedness " ) de las redes, lo cual significa que más sitios se encuentran directamente conectados entre sí. El resultado es un incremento en el número y reticulación de los PVCs en las redes, que no se escala bien con las tecnologías actuales de redes. Una posible solución para manejar redes altamente reticuladas es utilizar una red privada virtual (VPN) que interconecta las ubicaciones de usuario final usando tráfico codificado via "la formación de túneles" ("tunneling") en la interred (internet). Sin embargo, los VPNs no están ampliamente soportados por los proveedores del servicio de la interred (ISPs), tienen velocidades de información erráticas y presentan diversos aspectos de seguridad. Otra posible solución es el uso de circuitos virtuales conmutados (SVCs), a base de relevador de cuadro. Mientras que los PVCs (discutidos anteriormente) se definen generalmente en base a una suscripción y son análogos a las líneas arrendadas, los SVCs son temporales, definidos en una base según las necesidades, y son análogos a las llamadas telefónicas. Sin embargo, los SVCs requieren de comunicaciones continuas entre todos los encaminadores en el sistema, para coordinar los SVCs. Además, debido a que las tablas que mapean las direcciones IP hacia las direcciones SVC son mantenidas típicamente de manera manual, los SVCs a menudo son imprácticos para las grandes redes altamente reticuladas. La seguridad es un aspecto importante para las redes SVC donde las tablas son manejadas de manera errónea o la red es violada. Además, los SVCs de cuadro son difíciles de entrelazar con un modo de transferencia asincrona (ATM) SVCs . Ninguna de las soluciones anteriores ataca adecuadamente la creciente demanda de redes altamente reticuladas. Por consiguiente, existe la necesidad de arquitecturas de red que permitan la implementación de redes altamente reticuladas que tengan seguridad, bajos costos de mantenimiento, operaciones eficientes y que puedan escalarse.

BREVE DESCRIPCIÓN DE LA INVENCIÓN Aspectos de la presente invención resuelven uno o más de los problemas establecidos anteriormente y/o proporcionan sistemas y métodos mejorados para implementar una arquitectura de red. Un nuevo tipo de servicio de transporte de datos toma ventaja de la base existente del equipo en el establecimiento del cliente (CPE) de relevador de cuadro y de los clientes, mientras que ofrece un nuevo mecanismo para proporcionar características del servicio que pueden extenderse a aquellos clientes. En el nuevo servicio, los identificadores de conexión del enlace de datos (DLCIs) pueden ser utilizados por el CPE para seleccionar entre los tipos de servicio, grupos de configuración y grupos cerrados de usuarios (CUGs). El DLCI es utilizado en el cuadro de la capa 2 que transporta los datos del usuario hacia la red. El paquete de datos del usuario, de la capa 3, es extraído del cuadro de la capa 2 y la información de dirección de la capa 3, para el protocolo (al que puede asignarse una ruta), es utilizada para encaminar el paquete de datos del usuario sobre una red conmutada de paquetes de alto rendimiento, de acuerdo con la clase de servicio/grupo de configuración seleccionado por el DLCI. En el punto de destino, el paquete de datos de la capa 3 es encerrado otra vez en un cuadro de la capa 2, con un DLCI que indica a qué grupo de servicio pertenece. El cuadro es entonces enviado hacia el CPE. El uso de esta técnica permitirá que el CPE de relevador de cuadro existente soporte, sobre la misma interconexión física, un servicio convencional de relevador de cuadro con un rango de DLCIs que se encuentra unido a las trayectorias lógicas como el circuito virtual permanente (PVCs), asi como un rango de DLCIs que se encuentran unidos a los grupos de servicio y/o de configuración. Esto permitirá un método robusto para la extensión de nuevos servicios hacia la base instalada del relevador de cuadro, con un minimo impacto al equipo existente del cliente. En algunos aspectos de la invención se utilizan DLCIs de relevador de cuadro para seleccionar entre varias "categorías de servicio". Esto difiere significativamente del relevador de cuadro convencional, el cual utiliza DLCIs solamente para seleccionar los PVCs y/o los circuitos virtuales conmutados (SVCs). Las categorías del servicio pueden incluir, aunque no se limitan a, comunicación via la interred pública, comunicación vía una intrared local, comunicación dentro de un grupo cerrado de usuarios (CUG), comunicación con una red externa (extranet) (e.g., una red de proveedores confiables o socios corporativos), transmisión de audio/video en vivo, transmisión múltiple, telefonía sobre el protocolo de la interred (IP), o cualquier combinación de las mismas. Por consiguiente, el concepto de una PVC de relevador de cuadro se ve significativamente expandido por los aspectos de la presente invención. Por ejemplo, la ubicación de un destinatario final programado, de la red, no es determinada necesariamente por un DLCI en un punto final de envió de la red. El DLCI puede representar una categoría de servicio, donde el destinatario programado se encuentra indicado por una dirección IP dentro del paquete de relevador de cuadro. Esto resulta en un beneficio importante para los usuarios de la red debido a que, a diferencia del relevador de cuadro convencional, los usuarios ya no necesitan actualizar sus tablas locales DLCI cada vez que un cliente de la red, con el cual desean comunicarse, es adicionado o eliminado de la red. Por consiguiente, se reduce sustancialmente la carga del cliente para la administración de la red. En aspectos secundarios de la invención, algunos DLCIs pueden utilizarse para seleccionar entre las categorías del servicio ("DLCIs de la categoría del servicio"), mientras que en la misma red pueden utilizarse otros DLCIs para seleccionar PVCs y/o SVCs convencionales ("DLCIs convencionales"). En otras palabras, el relevador de cuadro convencional puede estar mezclado con aspectos de la presente invención dentro de la misma red, permitiendo que los aspectos de la presente invención se implementen de manera creciente en las redes de relevador de cuadro convencionales, existentes. En aspectos adicionales de la invención, el direccionamiento contenido en múltiples capas (e.g., como se define por el modelo de Interconexión de Sistema Abierto) es comparado entre si en una red, para determinar los errores de encaminamiento. Si el direccionamiento en las capas es consistente entre sí, entonces los datos asociados son encaminados sin interrupción. Por otro lado, si el direccionamiento en las capas es inconsistente entre si, los datos asociados pueden ser manejados de manera especial. Por ejemplo, los datos pueden ser desechados, enviados hacia una dirección predeterminada, y/o ser retornados al remitente. Esta comparación de dirección puede ser aplicada a la dirección remitente y/o a la dirección del destinatario. Una ventaja de esta comparación de direcciones en capas múltiples es que se incrementa la seguridad de la red. Por ejemplo, los problemas tales como "violación", que es la práctica de proporcionar a propósito una dirección incorrecta del protocolo (IP) de envío de la interred, son mejor controlados por este método.

Todavía, en aspectos adicionales de la invención, las tablas de consulta de encaminamiento, dentro de la red, se encuentran separadas, de modo que, por ejemplo, cada cliente, grupo cerrado de usuarios (CUG), extrared y/o interred, puedan tener su propia partición privada y/o tabla separada. Esto puede proporcionar mayor velocidad a la red debido a que un encaminador no necesita explorar el espacio total disponible de direcciones para todos los usuarios de la red al mismo tiempo. Además,, la seguridad de los datos se ve mejorada debido a que se reduce el riesgo de enviar datos hacia un destinatario equivocado. Todavía, en otros aspectos más de la invención, la información de dirección de la capa 3 y/o de la capa 4, es utilizada para encaminar los paquetes rápidos a través de la red . En aspectos adicionales de la invención, se definen nuevas técnicas y mediciones para la administración del tráfico de la red. Por ejemplo, en algunos aspectos de la administración del tráfico, de la invención, pueden asignarse tasas de entrega comprometidas (CDRs) a una o más UNIs. Una CDR es la mínima tasa de datos promedio que se garantiza será entregada a una UNÍ cuando se envia suficiente tráfico hacia la UNÍ. En aspectos adicionales de la administración del tráfico, de la invención, se asigna un compartimiento de tasa de destino (DRS) a una o más UNIs. El DRS puede ser utilizado para determinar el compartimiento de tráfico que una UNÍ dada puede enviar a través de la red. Si varias UNIs ofrecen al mismo tiempo enviar tráfico a la misma UNÍ de destino, entonces, el compartimiento de cada UNÍ remitente, de la red, puede determinarse por su propia DRS y las DRSs de las otras UNIs remitentes. Estas y otras características de la invención se hará aparentes luego de la consideración de la siguiente descripción detallada de las modalidades preferidas. Aunque la invención ha sido definida utilizando las reivindicaciones anexadas, estas reivindicaciones son ejemplares en el sentido en que la invención está programada para incluir los elementos y las etapas que se describen aqui en cualquier combinación o subcombinaci ón . Por consiguiente, existen diversas combinaciones alternativas para definir la invención, que incorpora uno o más elementos de la especificación, incluyendo la descripción, las reivindicaciones y las figuras, en diversas combinaciones y subcombinaciones. Será aparente para aquellos entrenados en la teoría y diseño de redes, a la luz de la presente especificación, que pueden utilizarse combinaciones alternativas de la presente invención, ya sea solas o en combinación con uno o más elementos o etapas definidos aqui, como modificaciones o alteraciones de la invención o como parte de la invención. Se pretende que la descripción escrita de la invención contenida aqui cubra todas estas modificaciones y alteraciones.

BREVE DESCRIPCIÓN DE LAS FIGURAS El resumen anterior de la invención, así como la siguiente descripción detallada de las modalidades preferidas se comprenden mejor cuando se leen en conjunto con las figuras que la acompañan. Para propósitos ilustrativos, las modalidades que muestran uno o más aspectos de la invención son mostradas en las figuras. Estas modalidades ejemplares, sin embargo, no pretenden limitar la invención solamente a las mismas. La Figura 1 ilustra una red de gran amplitud (WAN) que tiene encaminadores como CPEs y PVCs entre las ubicaciones de los clientes. La Figura 2 muestra los datos que fluyen a través de la WAN que se muestra en la Figura 1. Las Figuras 3-5 muestran la construcción y el flujo de los paquetes de datos a través de la red. La Figura 6 muestra un diagrama de bloques de una arquitectura de red, de acuerdo con los aspectos de la presente invención. La Figura 7 muestra un diagrama de bloques detallado de la red ilustrada en la Figura 6.

Las Figuras 8A-8B muestran el recorrido de migración para incorporar los aspectos de la invención en las arquitecturas convencionales de red. La Figura 9 muestra los datos que fluyen a través de la arquitectura de la red de la Figura 6. La Figura 10 muestra la asignación de prioridades, basada en la aplicación, a través de la arquitectura de la red de la Figura 6. La Figura 11 ilustra una modalidad ejemplar de accesorios para proporcionar servicios a través de la red de la Figura 6. Las Figuras 12-14 ilustran los datos que fluyen a través de las WANs ejemplares 1.

DESCRIPCIÓN DETALLADA DE LAS MODALIDADES PREFERIDAS Las modalidades ejemplares de la presente invención permiten que la gran base instalada del equipo en las instalaciones del cliente (CPE), de relevador de cuadro, sean mantenidas utilizando la misma interconexión de una forma diferente, para entregar nuevos grupos de servicios y accesorios al cliente. Por ejemplo, el identificador de conexión del enlace de datos (DLCI), conocido del protocolo de relevador de cuadro, puede ser utilizado para seleccionar entre diversas redes virtuales privadas con diferentes espacios de dirección, grupos de características y/o circuitos virtuales, permanentes, convencionales (PVCs) . Refiriéndose a la Figura 7, se muestra un diagrama de bloques de una red de gran amplitud (WAN) 1 que incorpora aspectos de la presente invención. La WAN 1 incluye una pluralidad de sistemas del equipo en las instalaciones del cliente (CPE), por ejemplo, encaminadores localizados en cada una de las ubicaciones del usuario final e interconectados vía uno o más proveedores del servicio de las redes (SPNs) 500. El SPN 500 se encuentra conectado típicamente con una pluralidad de encaminadores de extremo final, 919, via una pluralidad de interconexiones de la red, del usuario, correspondientes (UNIs), 402, y uno o más conmutadores del protocolo de la interred (IP), 502. Los interruptores IP, 502, las UNIs 402, y/o los encaminadores /conmutadores , 501, pueden estar interconectados de modo que formen una red reticulada (e.g., una red parcial o totalmente reticulada) . Adicionalmente, la red de gran amplitud (WAN) 1 puede contener cualquier número de conmutadores IP 502 localizados dentro de la WAN 1, de tal forma que no se conecta directamente con cualesquiera encaminadores de extremo final, 919, y/o uno o más conmutadores IP, 502, pueden estar localizados en una interconexión entre el SPN 500 y un encaminador de extremo final, 919. En modalidades adicionales de la invención, pueden existir múltiples encaminadores de extremo final, 919, asociados con una UNÍ 402 /conmutador IP 502 y/o múltiples UNIs 402 / conmutadores IP 502, asociados con un 'encaminador de extremo final, 919. La arquitectura de red de la WAN 1 permite que se incremente el número de conmutadores IP a medida que los clientes son trasladados al nuevo servicio. Por ejemplo, como se muestra en la Figura 8A, inicialmente puede existir sólo un pequeño número (e.g., uno, dos, tres, etc.) de conmutadores IP instalados en el sistema. Donde se incluyen solamente -un pequeño número de conmutadores IP en la red, el tráfico que se origina de UNIs, 402, no habilitadas con IP (e.g., UNÍ A) puede ser encaminado hacia un conmutador IP, 502, en cualquier lugar de la red. Aunque esto origina algunas ine fi ciencias despreciables en la "búsqueda de retroceso", sin embargo permite un recorrido de migración hacia la nueva arquitectura de red sin reemplazar al mismo tiempo todos los encaminadores 501. Sin embargo, a medida que más y más usuarios son trasladados a la nueva arquitectura de red de la WAN 1, pueden adicionarse más y más conmutadores IP (Figura 8B) para acomodar la mayor carga. En muchas modalidades, puede ser deseable convertir eventualmente cada UNÍ 402 en un conmutador IP, 502, de modo que el encaminamiento por IP pueda efectuarse en el borde de la red. En algunas modalidades, la WAN 1 puede incluir una combinación de conmutadores y/o encaminadores, 501, convencionales de red, además de los conmutadores IP 502. Por otro lado, cada conmutador en el SPN 500 puede ser un conmutador IP 502. Alternati amente, la WAN 1 puede contener solamente un conmutador IP simple, 502. Los conmutadores IP 502 pueden configurarse de diversas maneras para incluir un conmutador de encaminamiento multicapas, como un Conmutador Tag de Cisco. También pueden utilizarse los conmutadores de encaminamiento en multicapas de vendedores como ípsilon, Toshiba, IBM, y/o Telecom. Los conmutadores IP se están desarrollando actualmente para reemplazar los encaminadores de extremo final de modo que el equipo en las instalaciones del cliente (e.g., equipo de red del área local (LAN) Ethernet) puede conectarse directamente con una red de modo de transferencia asincrono (ATM) . Aspectos de la presente invención proponen el uso de conmutadores IP de manera diferente para mantener la enorme base instalada del equipo en las instalaciones del cliente, mientras que evita las limitaciones de los sistemas anteriores. Por consiguiente, los conmutadores IP, de acuerdo con las modalidades de la invención, se colocan dentro del SPN 500 y se modifican para proporcionar un encaminamiento y funciones de interconexión adecuadas. En algunas modalidades de la invención, un conmutador IP 502 actúa como un conmutador multicapas. Por ejemplo, un conmutador IP 502 puede recibir celdas ATM, la conmutación de todas o de algunas de las celdas ATM que se basan en el contenido de los paquetes IP encapsulados dentro de las celdas ATM. Por consiguiente, el direccionamiento IP puede ser utilizado por un conmutador IP 502 para determinar un recorrido virtual ATM, para enviar las celdas ATM hacia una UNÍ de destino, 402. En modalidades adicionales de la invención, el direccionamiento de las capas superiores (e.g., los puertos lógicos en la capa 4 del programa de control de la transmisión (TCP)) también puede ser utilizado por un conmutador IP 502 como la base para conmutar las celdas ATM para proporcionar un recorrido a través del SPN 500. Todavía, en una modalidad adicional de la invención, un conmutador IP 502 utiliza las direcciones IP y/o los puertos lógicos TCP para realizar decisiones de la calidad de servicio (QOS). En modalidades adicionales de la invención, un encaminador de punto final, 919, pueden encapsular uno o más paquetes IP en el cuadro del relevador de cuadro, 914. En este caso, los cuadros del relevador de cuadro pueden ser transmitidos entre un encaminador de extremo final, 919, y una UNÍ correspondiente, 402, y/o un conmutador IP 502. El encaminador de extremo final, 919, encapsula los paquetes IP 950 con los cuadros del relevador de cuadro, 914. Además, el encaminador de extremo final, 919, puede ajustar el DLCI de cada cuadro del relevador de cuadro, 914, de acuerdo con una categoría particular de servicio (si se utiliza una categoría de servicio DLCI) que el usuario ha seleccionado. Por ejemplo, las diversas categorías de servicio pueden incluir la interred pública, la comunicación via una intrared local, comunicación dentro de un grupo cerrado de usuarios (CUG), la comunicación con una red externa (e.g., una red de proveedores confiables o socios corporativos), transmisión en vivo de audio/video, transmisión múltiple, telefonía sobre el protocolo internet (IP), o cualquier combinación de los mismos. Por consiguiente, el concepto de un relevador de cuadro PVC se expande significativamente por los aspectos de la presente invención. Por ejemplo, la ubicación de un destinatario final programado no es determinada necesariamente por un DLCI en los encaminadores de extremo final, 919. En modalidades adicionales de la invención, una UNÍ 402 puede recibir los cuadros del relevador de cuadro, 914, desde un encaminador de extremo final, 919, y divide y encapsula los cuadros del relevador de cuadro en, por ejemplo, celdas ATM menores, de longitud fija. La UNÍ 402 puede además traducir el DLCI del re-levador de cuadro en una dirección ATM (e.g., identificador del recorrido virtual/identif icador del canal virtual (VPI/VCI). Existen diversos métodos que pueden utilizarse para traducir DLCIs en VPI/VCIs. Por ejemplo, puede utilizarse el Estándar de Interreacción de la Red, tal como se define en el Acuerdo de Implementación #5 del Foro del Relevador de Cuadro, y/o el Estándar de Interreacción de Servicio, tal como se define en el Acuerdo de Implementación #8 del Foro del Relevador de Cuadro. Una dirección ATM asociada con una categoría de servicio de DLCIs define un recorrido virtual ATM, vía encaminadores de la red, hacia un conmutador IP, 502. Por consiguiente, los datos ATM asociados con un DLCI de categoría del servicio es enviado, por último, hacia un conmutador IP 502. Sin embargo, los datos ATM asociados con un DLCI convencional pueden, o no, ser enviados hacia un conmutador IP 502 y pueden ser encaminados a través de la red sin pasar por un conmutador IP 502. Por consiguiente, tanto los datos IP traducidos, como los datos PVC convencionales, pueden estar presentes en el SPN 500 y/o en la WAN 1. En modalidades adicionales de la invención, una UNÍ 402 y/o un encaminador de la red, 501, pueden enviar datos hacia un conmutador IP predeterminado, 502.

Todavía, en modalidades adicionales de la invención, una UNÍ 402 y/o un encaminador de red, 501, selecciona a qué conmutador IP 502 se envían los datos, basándose en un algoritmo (e.g., basados en los flujos de tráfico de la red, la relativa distancia/ubicación de un conmutador IP 502, el tipo de datos que se envían, y/o la categoría del servicio seleccionada) . Todavía, en modalidades adicionales de la invención, una UNÍ 402, un encaminador de red 501, y/o el conmutador IP 502, pueden enviar los mismos datos a más de una UNÍ 402, encaminador de red 501, y/o conmutador IP 502, dependiendo de, por ejemplo, una categoría o categorías del servicio. En modalidades adicionales de la invención, una UNÍ 402, un conmutador IP 502, y/o un encaminador de red 501, compara una dirección ATM VPI/VCI, 303-305, con una dirección IP para los mismos datos. Si las dos direcciones son inconsistentes, entonces la celda ATM puede ser descartada, enviarse hacia una dirección predeterminada, y/o regresarse hacia la ubicación remitente. En modalidades todavía adicionales de la invención, las capas por arriba de la capa IP, de la capa 3, pueden ser utilizadas para una generación/discriminación de dirección y/o de la clase de servicio. Por ejemplo, puede utilizarse la capa 4 del esquema de direccionamiento ISO y/u otros datos del nivel de aplicación para determinar las clases particulares del servicio. Refiriéndose especificamente a la Figura 9, se muestra el recorrido de los datos del usuario que fluyen a través de una WAN 1 ejemplar. Como en el caso del relevador de cuadro, los datos del usuario en la capa de aplicación y en la capa 4, requieren la adición de un iniciador de dirección de la red, de la capa 3. En el CPE se decide, en base a la información en las capas 3 y 4, hacia qué red privada virtual (VPN), clase de servicio, o PVC convencional, debe encaminarse el paquete. Por consiguiente, un paquete con la información de la capa 4, que indica que es una aplicación telnet (interactiva) y con la información de la capa 3 que indica que es una dirección de compañía interna, puede ir hacia la VPN A, para una clase de servicio de intrared de poca demora. Otro paquete que sea parte de una transferencia de archivos, del protocolo de transferencia de archivos (FTP), puede ir hacia la VPN B, con una clase de servicio inferior, y un tercer paquete que vaya entre dos aplicaciones altamente utilizadas puede ir hacia una PVC D, dedicada. Estas decisiones son codificadas como diferentes valores DLCI, se insertan en el cuadro de la capa 2, y se envían hacia la UNÍ. En la UNÍ 402 se efectúa la conmutación basada en el DLCI. El paquete puede ser encaminado hacia el conmutador IP 502, en el centro del SPN 500. El cuadro de la capa 2 del primer paquete es separado a medida que es enviado hacia el VPN A, la dirección de la capa 3 ahora es utilizada para realizar decisiones de encaminamiento que envían el paquete hacia su UNÍ de destino. Por consiguiente, no es necesario establecer ningún PVC adelantado en el tiempo para ese recorrido, y pueden utilizarse métodos y protocolos de encaminamiento convencionales, así como técnicas de encaminamiento de "cortocircuito", recientes. Esto permite que el VPN A proporcione un elevado grado de "reticulación", como un gran número de PVCs. El paquete enviado hacia el VPN B es tratado de manera similar, excepto porque el VPN está implementado con una clase inferior de servicio (e.g., mayor retardo) . Finalmente, el paquete enviado hacia el PVC D mantiene intacto su cuadro de la capa 2 y pasa a través de la red como un cuadro de relevador de cuadro convencional. Esto permite que los clientes mantengan su conectividad actual de los PVCs para sus recorridos de tráfico con alto grado de uso, pero todavía tienen un alto grado de reticulación de conectividad a través de diversos VPNs . Por consiguiente, en diversos aspectos de la invención, la WAN 1 y/o el SPN 500 pueden ser cualquier red de paquete rápido que recibe paquetes de datos del relevador de cuadro, que tiene datos del usuario en un campo de datos del usuario. La WAN 1 y/o el SPN 500 entonces conmuta los paquetes utilizando uno o más conmutadores IP 502, en respuesta a los datos del usuario. Los datos del usuario pueden ser utilizados para discriminar entre una pluralidad de diferentes categorías de servicio, basados en los datos del usuario. La asignación de ruta por la WAN 1 y/o el SPN 500 puede ser en respuesta a al menos una de las diferentes categorías de servicio incluyendo la discriminación basados en los datos de transmisión múltiple. Adicionalmente, la WAN puede generar un campo de dirección de paquete rápido en respuesta a los datos del paquete IP y encaminar el paquete IP a través de la red de paquetes rápidos en respuesta al primer campo de dirección del paquete rápido. Además, la información de la capa 4 puede ser utilizada para determinar la calidad del servicio. La calidad del servicio puede incluir, por ejemplo, uno o más de lo siguiente: una velocidad de información, información de la prioridad, retardo, pérdida, disponibilidad, etc. Pueden implementarse características de seguridad en el conmutador IP, de modo que las tablas de encaminamiento para cada uno de los usuarios se encuentren separadas, basados en una o más categorías del servicio y/o uno o más usuarios. De este modo, el sistema se hace más seguro. Todavía más, el sistema puede recibir una pluralidad de paquetes del relevador de cuadros sobre un circuito virtual permanente (PVC) en un primer nodo, en un modo de transferencia asincrono (ATM), generar una dirección ATM basados en un campo de datos diferente a un identificador de conexión del enlace de datos (DLCI) dentro de los paquetes del relevador de cuadro, y luego encaminar los paquetes a través de la red ATM basados en la dirección ATM. El encaminamiento de los paquetes puede ser en respuesta a una de una pluralidad de categorías de servicio. El sistema puede proporcionar tablas separadas de encaminamiento dentro de un conmutador ATM para cada una de una pluralidad de diferentes categorías del servicio. Las diferentes categorías de servicio pueden determinarse utilizando los datos del protocolo de la interred (IP) dentro de un campo de datos de un paquete que pasó por el conmutador ATM. En una red rápida de paquetes, un interruptor de paquetes rápidos puede comparar la dirección de un paquete rápido con una dirección del protocolo de interred (IP), de la capa 3, contenido dentro del paquete rápido, y determinar si la dirección del paquete rápido es consistente con la dirección IP de la capa 3. Además, para seguridad, pueden proporcionarse circuitos de hardware y/o software para el examen de una dirección remitente o una dirección de destinatario. Además, los paquetes pueden desecharse en respuesta a la detección de alguna inconsistencia. La WAN 1 puede incluir el equipo en las instalaciones del cliente (CPE) y un conmutador en modo de transferencia asincrono (ATM) acoplado con, y recibiendo desde, los paquetes de datos del relevador de cuadro del CPE, y que incluye circuitos para la traducción de la dirección para traducir los identificadores de conexión del enlace de datos, de los paquetes de datos del relevador de cuadro, en direcciones ATM que representan una pluralidad de redes virtuales privadas, basadas en una categoría del servicio predeterminada, asociada con una DLCI particular; o la WAN 1 puede incluir equipo en las instalaciones del cliente (CPE) y un conmutador de paquetes rápidos acoplado con el CPE vía uno o más circuitos virtuales permanentes y paquetes de datos del relevador de cuadro, receptores, donde el conmutador del paquete rápido incluye circuitos para la traducción de la dirección, para traducir los datos del usuario dentro de los paquetes de datos del relevador de cuadro en direcciones de paquetes rápidos. En las modalidades de la presente invención, la seguridad de los datos se ve reforzada en el sentido en que los datos pueden ser verificados de manera sencilla y precisa, buscando inconsistencias en el punto de destino. Esto se debe a que estas modalidades operan utilizando tanto la información de di eccionamiento de la capa 2 como de la capa 3. Por ejemplo, suponga que un cuadro del relevador de cuadro, que tiene un DLCI que indica que el VPN 1 (e.g., la intrared corporativa) llega en un conmutador/encaminador de red con una dirección IP de un sistema de contabilidad corporativo particular. Sin embargo, debido a que el procesador VPN tiene disponible el DLCI del paquete (y por consiguiente la información acerca de la fuente del paquete), el procesador del VPN puede realizar una verificación cruzada del DLCI con la dirección IP de la fuente, en el paquete, para ver si la dirección IP de la fuente se encuentra en el rango conocido desde el sitio de origen. Por consiguiente, el problema asociado con la violación de las direcciones fuente IP puede reducirse de manera significativa. En modalidades todavía adicionales de la invención, una UNÍ 402, un conmutador IP 502, y/o un encaminador de red 501, tienen tablas de consulta de encaminamiento separadas y/o divididas. Las tablas de encaminamiento pueden ser separadas basados en la categoría del servicio, el cliente o el usuario, y/o la UNÍ 402. Por consiguiente, en algunas modalidades, dentro de una VPN, un cliente o usuario puede tener una tabla individual de encaminamiento que contenga la información de dirección de la red IP del cliente. En algunas modalidades, debido a que el DLCI identifica la fuente de un cuadro, el DLCI puede ser utilizado como un índice por un conmutador IP, un encaminador de la red, y/o una UNÍ, para determinar que tabla de encaminamiento utilizar. Esto permite que los clientes tengan el tamaño y la velocidad de su tabla de encaminamiento gobernados por su espacio individual de dirección, acelerando considerablemente el proceso de encaminamiento. El uso de tablas de encaminamiento separadas también proporciona una medida más de seguridad, puesto que los paquetes no pueden ser encaminados de modo erróneo debido a errores o actualizaciones en la información de encaminamiento relacionada con otros clientes. En algunas modalidades, un encaminador tiene imágenes múltiples del espacio de datos apareadas con una sola imagen del espacio de una sola instrucción, del software de encaminamiento. Por consiguiente, por ejemplo, a medida que los paquetes llegan desde el Cliente A, el software de encaminamiento utiliza la imagen de los datos para una tabla de encaminamiento asociada con el Cliente A para hacer una decisión de encaminamiento. En modalidades adicionales, una sola imagen del software es utilizada, pero se anexan Índices adicionales correspondientes a las tablas de encaminamiento. Todavía, en modalidades adicionales, la ejecución de las instrucciones y el manejo de datos se procesan de manera separada. Esto puede efectuarse mediante el uso de procesadores separados, uno para ejecutar las instrucciones y otro para el manejo de datos . La Figura 12 ilustra una WAN 1 ejemplar que tienen tanto encaminadores convencionales y conmutadores IP que incorporan los aspectos de la invención. En esta WAN 1 ejemplar, un elemento de encaminamiento, 1004, y el interruptor 1003 se encuentran conectados con el Sitio del Cliente A, via el conmutador de relevador de cuadro 1001. El elemento de encaminamiento 1007 y el conmutador 1006 se encuentran conectados con el Sitio del Cliente B via el conmutador de relevador de cuadro, 1009. El elemento encaminador 1012 y el conmutador 1014 se encuentran conectados con el Sitio del Cliente C via el conmutador de relevador de cuadro 1016. El elemento encaminador 1013 y el conmutador 1015 se encuentran conectados con el Sitio del Cliente D vía el conmutador de relevador de cuadro 1017. En esta WAN 1 ejemplar, los cuadros que llegan, 1000, desde el Sitio del Cliente A, pueden ser codificados con un DLCI de la capa 2, especificando la VPN #1 como el destino de la capa 2 y una dirección de la capa 3 apuntando hacia el Sitio del Cliente B. En este caso, el conmutador de relevador de cuadro 1001, conmuta los cuadros sobre un tronco del relevador de cuadro, 1002, hacia el conmutador 1003, que tiene el elemento de encaminamiento del la capa 3, 1004, asociado con el mismo. Después de que el cuadro es recibido por el conmutador 1003, el cuadro es enviado hacia el encaminador 1004, el cual implementa el encaminamiento de cortocircuito, tal como se describió anteriormente. En encaminador/conmutador 1003, 1004, utiliza la información de la capa 2 para discriminar entre los diferentes clientes fuente. La información de la capa 2 puede entonces descartarse. Enseguida, la información de la capa 3, en combinación con una tabla de encaminamiento, es utilizada para realizar una decisión de encaminamiento. En este caso, la decisión de encaminamiento podria resultar en una PDU, 1011, de la capa 3, que está siendo enviada hacia el encaminador /conmutador 1006, 1007. El PDU de la capa 3, 1011, es encapsulado entonces con un cuadro de la capa 2, donde el cuadro, en este caso, está siendo direccionado hacia el Sitio del Cliente B. El conmutador 1006 entonces envia el cuadro cía un tronco 1008 hacia el conmutador de relevador de cuadro, 1009. En el puerto de salida del conmutador de relevador de cuadro, 1009, el DLCI del cuadro del relevador de cuadro, 1010, es reemplazado con un valor que indique que el cuadro se originó desde, en este caso, la VPN #1. El cuadro del relevador de cuadro, 1010, es entregado entonces al encaminador del Cliente B. A medida que el servicio crece, la funcionalidad para realizar decisiones de encaminamiento VPN puede trasladarse a un sitio más cerca del cliente y puede presentarse, eventualmente, en cada nodo de conmutación, como se muestra en la Figura 3. Esto puede reducir el retroceso previamente necesario para llegar hasta los nodos de procesamiento del encaminador/ conmutador y permitir el encaminamiento óptimo utilizando todos los nodos en la WAN 1 y/o en la SPN 500. En la modalidad ejemplar de la Figura 13, el VPN #1 se encuentra conectado con los Sitios de los Clientes 'A, B, C y D. Aquí, cada nodo de conmutación incluye un conmutador 1501 y un elemento de encaminamiento 1502. Los cuadros del relevador de cuadro 1500, que tienen un DLCI dirigido hacia el Sitio del Cliente B, pueden ser enviados desde el Sitio del Cliente A. En este caso, los cuadros 1503 serian enviados a través de la VPN #1, via los nodos de conmutación 1501, 1502, y los cuadros 1504 serían recibidos en el Sitio del Cliente B. En algunas modalidades, puede utilizarse una red de núcleo ATM para el transporte de datos y pueden utilizarse interconexiones del relevador de cuadro para interconectarse con el cliente. En la Figura 14 se muestra una modalidad ejemplar utilizando una red de núcleo ATM. En esta modalidad, el conmutador 2003 y el encaminador 2004 se encuentran conectados con el Sitio del Cliente A, via el conmutador 2000 y una unidad de conversión relevador de cuadro/ATM, 2001. El conmutador 2019 y el encaminador 2018 se conectan con el Sitio del Cliente B, via el conmutador 2005 y la unidad de conversión relevador de cuadro/ATM, 2006. El conmutador 2012 y el encaminador 2010 se conectan con el Sitio del Cliente C vía el interruptor 2015 y la unidad de conversión relevador de cuadro/ATM 2014. El conmutador 2013 y el encaminador 2011 se conectan con el Sitio del Cliente D vía el conmutador 2016 y la unidad de conversión relevador de cuadro/ATM 2017. Suponiendo que el Sitio del Cliente A se encuentra enviando los cuadros 2020 destinados para el Sitio del Cliente B, los cuadros de la capa 2 que están llegando pueden ser encapsulados para su transporte en celdas ATM, en el conmutador 2000, de acuerdo a, por ejemplo, el Estándar de Interconexión de Redes. Esta encapsulación puede, por ejemplo, ocurrir en la unidad de conversión 2001, externa al conmutador ATM 2000. Las celdas ATM, 2002, pueden ser enviadas hacia un PVC de ATM, designado para el procesamiento de VPN #1. Las celdas ATM 2002 pueden entonces ser enviadas hacia el conmutador 2003 y el encaminador / conmutador 2004 (el cual puede estar unido al conmutador 2003), donde las celdas ATM pueden ser reensambl adas para obtener la información del paquete de la capa 3, para el encaminamiento dentro del VPN #1. Una vez que la información de la dirección ha sido extraida del paquete de la capa 3, el paquete puede ser segmentado otra vez en celdas ATM, 2009, que pueden ser transferidas a través de la red. Después de ser enviadas a través del encaminador /conmutador 2018, 2019, las celdas ATM 2008 pueden ser convertidas de celdas a cuadros en la unidad externa de conversión, 2006, y el conmutador 2005. El Sitio del Cliente B recibiría entonces los cuadros, 2021, del relevador de cuadro. Por consiguiente, puede requerirse de un ciclo extra de segmentación y reensamble (SAR) cuando se utiliza una estructura ATM con un núcleo de encaminador / conmutadores . Sin embargo, si el procesamiento VPN es empujado hacia afuera de los conmutadores del borde, el ciclo SAR extra puede ser eliminado debido a que la conversión de los cuadros del relevador de cuadro en celdas ATM puede efectuarse en la misma unidad donde se toman las decisiones VPN. La administración del tráfico puede configurarse de diferentes formas en la WAN 1 y/o el SPN 500. Por ejemplo, desde el punto de vista de un cliente, la WAN 1 y/o el SPN 500 pueden asegurar ciertas velocidades de tráfico para el cliente. En una red, los datos del tráfico pueden ser enviados desde múltiples fuentes hacia un sólo destino (mult i -puntos a punto) . Una "fuente" se define como el usuario que transmite desde un extremo de, por ejemplo, una UNÍ (i.e., el cliente del extremo de una UNÍ que puede ser externo a una WAN y/o a una VPN) , un conmutador, un conmutador IP, y/o un encaminador en, o cerca de, el borde de una red. El tráfico que se ofrece para su transmisión por una fuente hacia la WAN 1 y/o el SPN 500 es definido como el "tráfico ofrecido". Además, una "fuente VPN" y un "destino VPN" son la fuente y el destino, respectivamente, que pertenecen a una VPN dada. Una UNÍ dada, si se encuentra enviando y recibiendo al mismo tiempo, puede, simultáneamente, ser una fuente y un destino. Además, una fuente dada puede ofrecer tráfico de datos hacia múltiples destinos y un destino dado puede recibir tráfico de múltiples fuentes. En algunas modalidades de la invención, una velocidad de entrega comprometida (CDR) puede ser asignada a cada destino. La CDR se define como el número promedio de bits por segundo que la WAN 1 y/o el SPN 500 se comprometen a entregar a un destino dado, donde el promedio puede calcularse sobre una ventana de tiempo fija o variable. Aunque la palabra "promedio" será utilizada en toda la descripción, puede utilizarse cualquier otro algoritmo similar, tal como la media, la suma, o cualquier otra medida y/o cálculo estadístico útil. Si la velocidad promedio del tráfico ofrecido agregado (i.e., el tráfico total ofrecido) de una o más fuentes hacia un destino dado es mayor o igual a un CDR asignado a un destino dado, entonces, la WAN 1 y/o el SPN 500 puede garantizar entregar el tráfico direccionado al destino a una velocidad promedio igual o mayor al CDR. Si la velocidad promedio del tráfico ofrecido agregado es menor al CDR, entonces la WAN 1 y/o el SPN 500 puede entregar el tráfico ofrecido al destino a la velocidad de tráfico ofrecido agregado (100% del tráfico ofrecido).

Para aclarar, sea N el número de fuentes activas que envían tráfico hacia un destino particular. Como se describirá con mayor detalle más adelante, una fuente puede ser considerada "activa" durante una ventana de tiempo dada si la fuente ofrece al menos una cantidad umbral de tráfico hacia la WAN 1 y/o el SPN 500 dentro de la ventana de tiempo dada. Sea Si la velocidad promedio del tráfico ofrecido, o "velocidad de oferta", desde cada fuente i hacia un solo destino dado, donde i=[l, ...., N] . Además, sea R la velocidad total a la cual la WAN 1 y/o el SPN 500 realmente entrega el tráfico al destino. Entonces, la WAN 1 y/o el SPN 500 proporcionarán que: R = ?ÍSÍ, de lo contrario.

Si la velocidad del tráfico ofrecido agregado, ?S L , no excede el CDR, entonces el 100% del tráfico ofrecido de cada fuente i puede ser entregado a través de la WAN 1 y/o el SPN 500 hacia el destino. Sin embargo, cuando el tráfico ofrecido agregado, SSi, excede el CDR, la WAN 1 y/o el SPN 500 pueden tener la precaución de moderar o reducir la velocidad de entrega del tráfico ofrecido desde alguna o todas las fuentes activas. La entrega puede reducirse en una cantidad tal que la velocidad total de la entrega del tráfico R hacia un destino es al menos igual al CDR asignado al destino. En la situación donde R se reduce por la red, puede ser deseable reforzar lo "razonable" para cada fuente. En otras palabras, puede ser deseable asegurar que no se permita que una sola fuente llegue a saturarse obteniendo una cantidad desproporcionada del ancho de banda de la red a expensas de otras fuentes . Para proporcionar un acceso aceptable hacia la WAN 1 y/o el SPN 500, en algunas modalidades a cada fuente se le asigna al menos un compartimiento de la velocidad de destino (DRS) . Una DRS es una velocidad, medida en unidades de datos por unidad de tiempo (e.g., bits por segundo) . Una DRS separada y/o grupo de DRSs puede ser asignada a cada fuente y/o grupo de fuentes. Además, la DRS o DRSs para una fuente dada puede depender del destino o grupo de destinos hacia los que la fuente puede enviar tráfico. En otras palabras, se puede asignar al menos un DRSi a cada fuente i, que corresponde con el DRS asignado entre una fuente i y un destino dado (o grupo de destinos). Por consiguiente, en algunas modalidades, el DRS puede ser diferente para una fuente dada, dependiendo del destino al que se esté mandando tráfico. En modalidades adicionales, el DRS para una fuente dada puede ser constante, independiente del destino.

Cuando una fuente i ofrece tráfico a una velocidad promedio Si, excediendo el CDR de un destino particular, puede lograrse lo justo asegurando que a cada fuente se le permita transmitir al menos su compartimiento razonable de la CDR. El "compartimiento justo" de una fuente de la CDR de destino se define como el DRS de la fuente dividido por el DRS agregado de las fuentes activas que transmiten hacia un destino dado. Por consiguiente, el compartimiento justo de cada fuente activa, rL, de la CDR puede definirse como se indica enseguida : DRSi r. = CDR ?iDRSi La velocidad real de transmisión de la red, Tx, que la WAN 1 y/o el SPN 500 escoge como la que conforma al tráfico que se garantiza será entregado de cada fuente hacia un destino dado puede satisfacer lo siguiente: cuando ?ÍSÍ > CDR, Por consiguiente, en estas modalidades, la WAN 1 y/o el SPN 500 pueden reforzar lo justo reduciendo la velocidad real de transmisión de la red, Tx, de una o más fuentes, a lo más de S? a r i f asegurando que cada fuente obtenga su compartimiento justo de la CDR. En algunas modalidades, para lograr una velocidad de la menos la CDR, la WAN 1 y/o el SPN 500 pueden, a su discreción, transmitir tráfico desde una fuente, o fuentes, activa(s) dada(s) a una velocidad mayor a rí . De hecho, la WAN 1 y/o el SPN 500 puede, a su discreción, transmitir datos desde una fuente i a cualquier velocidad entre e incluyendo la velocidad justa de compartimiento, ri, y la velocidad total ofrecida, S^ Si S,. es mayor que Ti, una fuente puede ser considerada por la WAN 1 y el SPN 500 como una "fuente no conformante". La conformancia de una fuente puede calcularse utilizando el algoritmo estándar de la cubeta con fugas, con una tasa variable de drenado. Por consiguiente, la "profundidad" de conformancia de una "cubeta" sería DRSdW. En otras palabras, el número máximo de bits que serán enviados a la red dentro de una ventana dada de tiempo, de longitud W, es igual a DRSdW. Durante una ventana de tiempo dada, de longitud W, la "velocidad de drenado" de la "cubeta" es igual a Ti que se calcula durante las ventanas de tiempo previas. Por consiguiente, lo paquetes de datos insertados "por arriba" de la profundidad de conformancia de la cubeta pueden ser marcados como "no conformantes". En otras palabras, para una ventana de tiempo dada, los paquetes de datos con exceso del número total bits, DRSdW, pueden ser marcados como paquetes de datos no conformantes. En esta situación, algunos o todos los paquetes de datos de la fuente iguales a la diferencia entre Si y Ti pueden ser marcados como paquetes de datos no conformantes, y algunos o todos los paquetes de datos no conformantes pueden ser eliminados. Esto no significa que los datos no pueden ser de naturaleza explosiva o con velocidad variable. Aunque se han descrito modalidades ejemplares que operan utilizando velocidades promedio, las velocidades de tiempo real pueden variar dentro de una ventana de tiempo dada, de longitud W. Por consiguiente, se permite una cierta cantidad de carácter explosivo de los datos. Este tamaño máximo de carácter explosivo es el número máximo de bits que la WAN 1 y/o el SPN 500 garantizan transferir durante una ventana de tiempo W. En modalidades adicionales de la invención, la WAN 1 y/o el SPN 500 pueden proporcionar una notificación posterior de congestión hacia un destino. Por ejemplo, la WAN 1 y/o el SPN 500 pueden proporcionar una indicación binaria en la capa 2 que el CDR está siendo excedido utilizando el bit y/o el mensaje de la capa 3 de notificación de congestión, explícita, posterior (FECN), que indica una fuente no conformante y que contiene opcionalmente información de la velocidad para esa fuente (e.g., la velocidad real transmitida TL y/o la velocidad de exceso Sx - Tx) . Además, en algunas modalidades, pueden catalogarse múltiples fuentes no conformantes, aún dentro de un solo mensaje. En estas modalidades de notificación posterior de la congestión, la conformancia puede medirse en el lado de la red de un destino. En algunas modalidades, puede proporcionarse una notificación posterior de congestión hacia un destino dado cuando la velocidad de oferta, S de una fuente activa que se ofrece a enviar tráfico hacia el destino, excede la velocidad real de transmisión de la red, Tx, para la fuente. Los paquetes no conformantes que no pueden ser transmitidos a su salida de una fuente, pueden ser eliminados con o sin indicación a la fuente o al destino. Para medir la conformancia de una fuente, debe determinarse la cantidad del ancho de banda en exceso disponible para las fuentes, para transmisión hacia el destino. Para calcular el exceso de ancho de banda, sea W-, la ventana de tiempo jés?ma. £1 exceso de ancho de banda por arriba del ancho de banda de compartimiento justo puede ser calculado como: E = CDR - ?i min(r Si) - MB , donde M se define como el número de posibles fuentes desde las cuales un destino puede recibir tráfico, y donde B se define como una velocidad predeterminada de referencia. La introducción de la velocidad de referencia B efectivamente reserva el ancho de banda de la red para una fuente inactiva, asegurando, por consiguiente, que una fuente previamente inactiva que se vuelva activa, pueda enviar al menos algo de tráfico a través de la red durante el periodo de tiempo j . Específicamente, la WAN 1 y/o el SPN 500 pueden asegurar que se garantice que cada Tj. de la fuente sea al menos una velocidad de referencia B. En esta situación, una fuente es considerada activa durante Wj si se reciben más de B*Wj unidades de datos (e.g., bits) durante j . Es deseable definir que B sea relativamente pequeña, comparada con Sj., de modo que retenga el mayor exceso de ancho de banda posible, aunque todavía suficientemente grande para asegurara la disponibilidad de la red para una fuente no activa (una fuente que no envía con respecto a un destino dado) que puede volverse activa posteriormente, con respecto a un destino dado. En algunas modalidades, B puede ser una velocidad predeterminada. En modalidades adicionales, B puede variar con el tiempo, con el número de fuentes inactivas, con el número de fuentes activas, y/o con el número total de fuentes. En modalidades todavía adicionales, B, para una fuente, puede depender de una clasificación de prioridad asignada a la fuente. En modalidades todavía adicionales, cuando una fuente previamente inactiva se vuelve activa, la prioridad asignada a la fuente puede depender del contenido de datos (e.g., carga útil de datos, DLCI, y/o dirección) que se ofrece serán enviados. Por consiguiente, B puede no ser la misma para cada fuente. Una vez que se determina el exceso del ancho de banda, pueden calcularse las velocidades máximas de transmisión de la red, Ti, reales, conformantes. Para lograr esto, Tx para cada fuente puede ajustarse primero por omisión a min(ri, Si). Luego, el exceso del ancho de banda, E, puede ser distribuido entre algunas o todas las fuentes que se encuentran transmitiendo de manera activa hacia el destino dado, ajustando o incrementando, entonces, Ti para estas fuentes. En algunas modalidades, el exceso del ancho de banda puede ser distribuido entre estas fuentes de acuerdo a la prioridad de la fuente, la prioridad de los datos, y/o el DLCI. En modalidades adicionales, la WAN 1 y/o SPN 500 pueden proporcionar una notificación de congestión de retroceso hacia una fuente no conformante. Esta notificación puede ser en forma de un mensaje en la capa 2 o en la capa 3 que indique un destino (s) para el (los) cual (es) la fuente no conformante excede Tt y/o la velocidad de información para la fuente no conformante (e.g., la velocidad real transmitida Tx y/o la velocidad de exceso Si - Ti) . Sin embargo, una notificación de la capa 2 por sí misma, puede no ser preferible, debido a que una fuente que recibe solamente una notificación de la capa 2 puede no ser capaz de distinguir entre los destinos hacia los cuales la fuente es conformante y aquellos para los cuales no es conformante. En algunas modalidades, puede proporcionarse una notificación de congestión de retroceso, hacia una fuente activa dada cuando la velocidad de ofrecimiento, Sif de la fuente, excede la velocidad real de transmisión de la red, Ti para la fuente. En modalidades adicionales, un usuario en una fuente no conformante puede ser notificado con información de congestión, el CDR, DRS, DRSi, rt y/o Tif asignados. Todavía, en modalidades adicionales, puede depender de un usuario decidir cómo actuar luego de una notificación de congestión. En modalidades adicionales, una fuente puede reducir su velocidad de oferta Si en respuesta a la recepción de una notificación de congestión de retroceso. En estas modalidades de notificación de congestión de retroceso, la conformidad puede ser implementada en el lado de la red de la fuente UNÍ. En estas modalidades, la retroalimentación que concierne a la velocidad de entrega del destino puede ser requerida desde el sitio de destino. La retroalimentación también puede contener información respecto al compartimiento de velocidad de las fuentes activas en el destino y/o el CDR dividido por la velocidad agregada. Mientras se muestran sistemas y métodos ejemplares que aplican la presente invención, se comprenderá, por supuesto, que la invención no se limita a estas modalidades. Pueden realizarse modificaciones por aquellos entrenados en la técnica, particularmente a la luz de las enseñanzas anteriores. Por ejemplo, cada uno de los elementos de las modalidades mencionadas anteriormente puede ser utilizada sola o en combinación con los elementos de otras modalidades. Adicionalmente, aunque se muestra una red reticulada en los ejemplos, las invenciones definidas por las reivindicaciones anexadas no se limitan necesariamente de este modo. Además, el conmutador IP puede convertir desde cualquier protocolo IP similar de cualquier nivel superior hacia cualquier protocolo similar de paquete rápido y no se limita necesariamente al ejemplo ATM/IP proporcionado anteriormente. Además, se describen ejemplos de las etapas que pueden efectuarse en la implementación de los diversos aspectos de la invención, en conjunción con el ejemplo de una modalidad física, como se ilustra en la Figura 5. Sin embargo, las etapas para la implementación del método de la invención no se limitan a la misma. Adicionalmente, aunque los ejemplos han sido derivados mediante el uso del protocolo IP para la capa tres, será aparente para aquellos entrenados en la técnica, que puede utilizarse cualquier versión de IP o IPX como el protocolo de la capa tres que puede encaminarse. Además, se comprenderá que mientras algunos ejemplos de implementaciones se discuten anteriormente con respecto a los protocolos IP y ATM, la invención no pretende limitarse solamente a los mismos, y también pueden utilizarse otros protocolos que son compatibles con aspectos de la invención. 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 convencional para la manufactura de los objetos a que la misma se refiere.

Habiéndose descrito la invención como antecede, se reclama como propiedad lo contenido en las siguientes.

Claims (16)

1. REIVINDICACIONES 1. Un método caracterizado porque comprende las etapas de: recibir en una red de paquetes rápidos, paquetes de datos de relevador de cuadro, donde los paquetes de datos del relevador tienen datos del usuario en un campo de datos del usuario; y conmutar los paquetes del relevador de cuadro dentro de la red de paquetes rápidos en respuesta a los datos del usuario.
2. 2. El método, de conformidad con la reivindicación 1, caracterizado porque los datos del usuario comprenden datos de la categoría del servicio, y donde el método además incluye la etapa de discriminar entre una pluralidad de categorías del servicio basados en los datos del usuario.
3. 3. El método, de conformidad con la reivindicación 2, caracterizado porque además incluye la etapa de encaminar sobre la interred en respuesta a al menos una de las categorías del servicio.
4. 4. El método, de conformidad con la reivindicación 2, caracterizado porque la etapa de discriminación incluye el reconocimiento de datos de voz.
5. 5. El método, de conformidad con la reivindicación 2, caracterizado porque la etapa de discriminación incluye el reconocimiento de datos de video.
6. 6. Un método caracterizado porque comprende: recibir una pluralidad de paquetes de relevador de cuadro sobre un circuito virtual permanente, en un primer nodo, en una red en modo de transferencia asincrono; generar una dirección en modo de transferencia asincrono basados en un campo de datos, diferentes a un identificador de conexión del enlace de datos, dentro de los paquetes del relevador de cuadro; y encaminar los paquetes a través de la red en modo de transferencia asincrono, basados en la dirección en modo de t ansferencia asincrono.
7. 7. El método, de conformidad con la reivindicación 6, caracterizado porque la etapa de encaminamiento incluye el encaminamiento de los paquetes en respuesta a una pluralidad de categorías de servicio.
8. 8. Un método caracterizado porque comprende la etapa 6 donde se utilizan tablas de encaminamiento separadas, dentro del conmutador en modo de transferencia asincrono para cada una de la pluralidad de categorías del servi ció.
9. 9. El método, de conformidad con la reivindicación 8, caracterizado porque las categorías del servicio son determinadas utilizando los datos del protocolo de la interred dentro de un campo de datos de un paquete que se hace pasar por el conmutador en modo de transferencia asincrono .
10. 10. Un método, caracterizado porque comprende las etapas de : utilizar un conmutador de paquetes rápidos para dar servicio a una pluralidad de clientes; y particionar las tablas de encaminamiento dentro del conmutador de paquetes rápidos, por medio del usuario.
11. 11. Una red, caracterizada porque comprende: equipo en las instalaciones del cliente; un conmutador de paquetes rápidos acoplado con el equipo en las instalaciones del cliente, con al menos un circuito virtual permanente y que recibe una pluralidad de paquetes de datos del relevador de cuadros, donde el conmutador de paquetes rápidos incluye circuitos para la traducción de la dirección, para traducir los datos del usuario dentro de al menos uno de los paquetes de datos del relevador de cuadros, en una dirección de paquetes rápidos .
12. 12. La red, de conformidad con la reivindicación 1, ca acterizada porque los circuitos de traducción responden a una pluralidad de diferentes categorías del servicio.
13. 13. La red, de conformidad con la reivindicación 12, caracterizada porque los circuitos de traducción responden a datos del protocolo de la interred dentro de los paquetes de datos del relevador de cuadros.
14. 14. La red, de conformidad con la reivindicación 13, caracterizada porque los circuitos de traducción responden a los datos del protocolo de la interred de la capa 3.
15. 15. La red, de conformidad con la reivindicación 12, caracterizada porque los circuitos de traducción están configurados para determinar la calidad del servicio en respuesta a los datos de la capa 4.
16. 16. La red, de conformidad con la reivindicación 11, caracterizada porque el conmutador de paquetes rápidos es un conmutador basado en el protocolo de modo de transfe encia asincrono.