MX2007008112A - Metodo para ejecutar una red sin conexion como una red de conexion orientada. - Google Patents

Metodo para ejecutar una red sin conexion como una red de conexion orientada.

Info

Publication number
MX2007008112A
MX2007008112A MX2007008112A MX2007008112A MX2007008112A MX 2007008112 A MX2007008112 A MX 2007008112A MX 2007008112 A MX2007008112 A MX 2007008112A MX 2007008112 A MX2007008112 A MX 2007008112A MX 2007008112 A MX2007008112 A MX 2007008112A
Authority
MX
Mexico
Prior art keywords
switching apparatus
traffic
switching
ethernet
control plane
Prior art date
Application number
MX2007008112A
Other languages
English (en)
Inventor
Alan Mcguire
Andrew Bryson Dick Reid
Original Assignee
British Telecomm
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from GB0428541A external-priority patent/GB0428541D0/en
Priority claimed from GB0428542A external-priority patent/GB0428542D0/en
Priority claimed from GB0502036A external-priority patent/GB0502036D0/en
Priority claimed from GB0502038A external-priority patent/GB0502038D0/en
Priority claimed from GB0502039A external-priority patent/GB0502039D0/en
Priority claimed from GB0518450A external-priority patent/GB0518450D0/en
Priority claimed from GB0518850A external-priority patent/GB0518850D0/en
Application filed by British Telecomm filed Critical British Telecomm
Publication of MX2007008112A publication Critical patent/MX2007008112A/es

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/64Hybrid switching systems
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/64Hybrid switching systems
    • H04L12/6418Hybrid transport
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46Interconnection of networks
    • H04L12/4641Virtual LANs, VLANs, e.g. virtual private networks [VPN]
    • H04L12/4645Details on frame tagging
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/34Signalling channels for network management communication
    • H04L41/344Out-of-band transfers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40Network security protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/64Hybrid switching systems
    • H04L12/6418Hybrid transport
    • H04L2012/6486Signalling Protocols

Landscapes

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

Abstract

Se describe un esquema de comunicaciones para configurar una red que comprende una pluralidad de aparatos de conmutacion conectados, cada aparato de comunicacion tiene la funcionalidad para implementar el envio sin conexion del trafico de comunicaciones recibido para proporcionar selectivamente un servicio de conexion orientada para el trafico de comunicaciones recibido, el esquema comprende: determinar en el plano de control de valores del campo de cabecera de indice para identificar el trafico sin conexion recibido en el aparato de conmutacion para que se establezca una conexion entre un nodo de fuente y un nodo de destino; proporcionar cada aparato de conmutacion necesario para implementar la conexion con la informacion del plano de control, la informacion permite que las tablas de envio de datos de conmutacion sea llenadas con los valores del campo de cabecera de indice en asociacion con los puertos de salida del aparato de conmutacion; y deshabilitar el resto de la funcionalidad en el aparato de conmutacion capaz de llenar las tablas de envio de datos con la informacion de indice asociada a los puertos de salida del aparato de conmutacion necesarios para establecer la conexion.

Description

MÉTODO PARA EJECUTAR UNA RED SIN CONEXIÓN COMO UNA RED DE CONEXIÓN ORIENTADA Campo de la Invención La presente invención se refiere a un esquema de comunicaciones de conexión orientada proyecta para la conmutación de tráfico sin conexión a través de una red de comunicaciones. En particular, pero no exclusivamente, la invención se relaciona a un aparato de conmutación configurado para implementar el esquema de comunicaciones de conexión orientada para el tráfico sin conexión en la red de comunicaciones, y los aspectos relacionados tales como métodos de proporcionar la información de señalización apropiada y información de control de OAM para soportar el esquema de comunicaciones. Antecedentes de la Invención Las redes de telecomunicaciones se han desarrollado de manera significativa durante las últimas décadas a partir de sistemas de circuito conmutado, de conexión orientada usando las conexiones punto a punto del pasado para las redes de comunicaciones digitales sin conexión disponibles virtualmente a todos los negocios y consumidores. Así, hoy en día, existe una mezcla de sistemas de comunicación, cada uno con sus propias características especificas que recurren a diferentes clases de uso.
La forma más antigua de redes de telecomunicaciones se puede referir como redes de circuito conmutado de conexión orientada (CO-CS) y ejemplos de tales redes incluyen la red de teléfono conmutada pública (PSTN) y redes ópticas. Las redes ópticas y las redes de cable coaxial tienen un ancho de banda más alto que, por ejemplo, las redes que abarcan pares de alambres de cobre y tendrán canales múltiplex de división de tiempo (TDM) para poder transmitir las comunicaciones múltiples en un solo cable o una sola fibra óptica. Las redes de TDM a veces también son referidas como redes Plesiochronous Digital Hierarchy (PDH) y Synchronous Digital Hierarchy (SDH), dependiendo de la estructura y organización de las redes que son utilizadas. Las redes conmutadas de paquete de conexión orientada (CO-PS) se utilizan para permitir la transferencia del ancho de banda alto o de datos de alta velocidad entre las terminales y ejemplos ¡ncluyen redes de relevo de cuadro, redes Asynchronous Transfer Mode (ATM) y redes X.25. Las redes sin conexión (CNLS) generalmente no tienen una ruta preestablecida entre las terminales de usuario final que se comunican en las mismas pero se soportan en cada terminal que tiene una dirección dedicada y enrutadores que intentan transferir la información por cualquier ruta disponible. El mejor ejemplo conocido de CNLS es la así llamada Internet que soporta la World Wide Web (WWW o W3) pero otras redes tales como redes de Ethernet utilizan el mismo principio de transmisión de datos vía "cualquier ruta disponible" en un paquete mediante la base del paquete a su punto terminal. Descripción Detalla de la Invención El aparato de conmutación (por ejemplo, nudos, enrutadores, puentes y/o conmutadores), requiere dirigir de forma correcta la información que se llevará por las unidades de datos de protocolo relevantes (PDUs) para determinar en que interfaz se debe remitir la PDU recibida hacia su dirección de destino. Los datos que deben comunicarse entre los nodos situados en la misma red de área local se pueden proporcionar con la información de dirección de destino que se basa solamente en un esquema de dirección de 2 capas OSI (Open Systems Interconnection). Los datos que deben comunicarse entre los nodos localizados en diversas redes de área local y comunicados sobre una red interna, que contienen los enrutadores, no obstante deben proporcionarse con la información de dirección del destino que es única en el nivel de red, es decir, que se basa en un esquema de dirección de 3 capas OSI (la capa de red). Los ejemplos de los esquemas de dirección de 2 capas OSI incluyen esquemas de dirección de Media Access Control (MAC), y ejemplos de esquemas de dirección de 3 capas OSI incluyen los esquemas de dirección de Internet Protocol (IP) (por ejemplo, IETF IPv4 o IPv6). El proceso de PDÚs recibidos para extraer la información de dirección apropiada genera retraso. El proceso de búsqueda para determinar en que puerto debe progresar un paquete recibido vía la tela de conmutador para alcanzar su destino, necesita ser puesto en ejecución lo más rápido posible, y esto impone límites ante la complejidad de la información de dirección que puede ser procesada. Además, si el aparato de conmutación se implementa para requerir un comportamiento de difusión si un paquete se recibe con una dirección de destino desconocida (también referida adjunto "difusión en-desconocida" tipo funcionalidad), después el tamaño de cualquier dominio de difusión puede afectar el funcionamiento de la red. Los expertos en la materia estarán por enterados que las difusiones tienen el potencial de saturar los recursos de la red y que lógicamente la restricción de los dominios de difusión pueden mitigar esto a cierto grado. Un medio de imponer una restricción lógica es implementar Redes de Área Local Virtual (VLANs). Proporcionando la información adicional en la cabecera de PDU, la VLAN a la cual se ha asignado la PDU se puede identificar por el aparato de conmutación que recibe la PDU, y el tráfico se conmuta internamente a la VLAN, es decir, solamente entre otros nodos en la VLAN. Para implementar una VLAN, un aparato de conmutación que recibe una PDU indicada como perteneciendo a una VLAN particular, debe asociar interfaces a la VLAN particular (es decir, asignar la VLAN a un puerto "nativo"). De esta manera, cuando el aparato de conmutación recibe el tráfico asociado a uns VLAN-ID particular, el tráfico será remitido exclusivamente a los puertos nativos apropiados asociados con la VLAN a la cual la PDU recibida pertenece. Si una PDU contiene una dirección de destino de 2 capas OSI que no se asocie ya con un puerto saliente particular del aparato de conmutación, los aparatos de conmutación necesitan difundir solamente sobre las interfaces asociadas con la VLAN-ID de PDU y no sobre todos los puertos del aparato de conmutación. Debido a que los expertos en la materia estarán por enterados, las tramas de Ethernet (OSI-capa 2 PDUs) pueden incorporar información adicional que comprende una VLAN-ID como parte de una etiqueta de VLAN en sus campos de cabecera. Desafortunadamente, la solución ofrecida por esquemas de identificación de VLAN simples no es escalable fácilmente, y se limita a 4096 casos separados de VLAN en una red, pues la VLAN ID es única en el contexto de una red de área local. Para proporcionar una escalabilidad adicional, VLANs jerárquicas o apiladas puedan utilizarse. PDUs que tienen la misma fuente y dirección de destino que son remitidas sobre una base sin conexión por el aparato de conmutación, son rutas asignadas en una base por paquete, tal que cada PDU es remitida independientemente desde la trayectoria tomada por las PDUs previamente recibidas que tienen la misma fuente y direcciones de destino. Para asegurar que una obtrucción no ocurra en las redes de Ethernet, el protocolo de árbol extendido configura lógicamente la topología de la red de Ethernet, que también evita que las trayectorias múltiples sean establecidas a la misma dirección de destino. El tráfico para una dirección de MAC es primero difundido y una vez que se determine la localización las tablas remitadas se llenan tal que el tráfico es remitido a lo largo de la misma ruta (a menos que el árbol extendido determina una ruta alternativa como puede ocurrir como resultado de una falla en topología). En cualquier red de comunicaciones donde los datos tienden a ser ráfagas, es decir, donde los bloques significativos de datos se transmiten desde una fuente a un receptor o aceptor de una manera desigual, hay la posibilidad de que una ruta seleccionada particular llega seriamente a sobrecargarse, retrasando la transferencia de datos, mientras que otras rutas de manera significativa serán utilizadas. Esto es porque un primer mensaje que tiene una cabecera nueva de fuente-receptor puede llegar a un conmutador, ser difundido y recibir un primer ACK a través de una ruta mientras que una combinación anterior de fuente-receptor es relativamente reservada. Los tiempos de transmisión a lo largo de una ruta se degradan generalmente cuando otras fuentes asignadas a la misma ruta comienzan a transmitir cargas más altas de tráfico. Si la degradación es bastante severa, puede hacer la ruta inutilizable para el servicio requerido. Las rutas múltiples entre una fuente y una destino para balancear la carga de tráfico no se permiten en la Ethernet legada porque el protocolo de árbol extendido (STP) determina una topología libre de bucles, si es posible, con solamente una ruta entre una fuente y un destino. Si una calidad garantizada de servicio (QOS) se requiere para los servicios con una capacidad agregada mayor que la del vínculo, se requiere una manera alternativa de asignar el ancho de banda requerido para tener más de un vínculo. Los conmutadores de Ethernet son intrínsecamente vulnerables cuando la información de control en-banda se proporciona como mensajes de control y la funcionalidad de conmutador se puede atacar por los computófilos. El uso de procesos de árbol extendido en una red de Ethernet puede ser perjudicial a la red, particularmente cuando hay bucles de puente cuando un puerto debe bloquearse en lugar del tráfico de envío. Es importante que ninguna interacción ocurra entre los procesos de árbol extendido usados en redes de área local y la red central. Simplemente conmutar un algoritmo del árbol extendido no es a menudo posible pues daría lugar simplemente a la difusión de "tormentas" y bucles. El aparato de conmutación de capa 2 y de capa 3 de OSI puede extraer la información que distingue como las PDUs recibidas son remitidas, por ejemplo, la información referente al tipo de servicio que recibe la PDU, y/o la información de prioridad que puede ser extraída. Diversos tipos de PDUs se pueden procesar por el aparato de conmutación de manera diferente (por ejemplo el tráfico por Operations Administration and Management (OAM) puede procesarse de manera diferente de PDUs que llevan los datos del usuario final). Aunque los protocolos sin conexión han proporcionado históricamente la ayuda adecuada para las aplicaciones elásticas, que son convenientes para las comunicaciones con retraso variante, secuenciación errónea potencial y con ninguna calidad de servicio verdadera (QoS), muchas aplicaciones son inelásticas y requieren el servicio de conexión orientada junto con el ancho de banda garantizado, elasticidad, y QoS. Por consiguiente es una demanda proporcionar los servicios de conexión orientada seguros para aplicaciones tales como aplicaciones de video interactivo por ejemplo, tal como la video conferencia, así como aplicaciones de medios fluidos. Substituir el equipo ya instalado para soportar los protocolos de comunicaciones sin conexión con el equipo de conexión orientada para cumplir con esta demanda es costoso y problemático. Una solución propuesta es la implementación de sistemas de conmutación de etiqueta del protocolo Multi (MPLS) tales como los proporcionados por Cisco™. Los sistemas de MPLS proporcionan una red de enrutadores que utilizan una etiqueta para enrutar paquetes entre los nodos de red definidos usando los mismos protocolos de enrutamiento que el enrutamiento sin conexión pero con un protocolo de señalamiento tal como LDP (protocolo de distribución de etiqueta). De esta manera, las rutas a través de la red pueden aparecer como conexión orientada desde un punto de vista de señalamiento en tales sistemas de MPLS. MPLS proporciona una solución parcial a la provisión de los arreglos de conmutación de conexión orientada y es una solución relativamente costosa comparada al uso de sistemas de conmutación de Ethernet debido a la complejidad de los sistemas de MPLS. Ethernet es una solución más extensa para proporcionar redes de área local (LANs) y redes de área amplia (WANs). Los conmutadores de Ethernet son así más fácilmente disponibles y menos costosos que los enrutadores permitidos de MPLS. Los enrutadores del Internet Protocol (IP) también se despliegan extensamente, sin embargo, el IP es un ejemplo de otro protocolo que soporta comunicaciones sin conexión. La Solicitud de Patente Internacional WO2005/008971 titulada "Arrangements for Connection-Oriented Transport in a Packet Switched Communications Network" publicada el 27 de enero de 2005 se relaciona a un sistema de control y sistema de comunicaciones que permiten el transporte del tráfico en un modo de conexión orientada usando la infraestructura de la red y el hardware de una red tradicionalmente sin conexión. WO'8971 reparte el espacio de dirección de un campo de dirección en un cuadro tradicionalmente sin conexión en un subconjunto de direcciones que se asocian a un modo de conexión orientada, y un subconjunto de direcciones que están asociadas a un modo sin conexión. El contenido de WO2005/008971 es incorporado por este medio en la descripción por referencia. La Solicitud de Patente Internacional WO2003027807 titulada " Method for Supporting Ethernet MAC Circuits" describe una subcapa de Ethernet MAC para soportar los circuitos de Ethernet MAC en una red de Ethernet en la cual la subcapa de MAC procesa e instala circuitos. La subcapa de MAC soporta un nivel más alto de señalamiento y aplicaciones de enrutamiento para implementar la funcionalidad del circuito de MAC y proporcionar interrupciones para el aprendizaje de WAN e instalación del circuito. La subcapa de MAC también proporciona la extensión de entrada de la tabla de dirección para permitir el uso de vínculos múltiples entre los nodos. La aplicación de enrutamiento se utiliza para manejar la información de enrutamiento, para mantener MAC en la base de datos de trazado del puerto, y manejar los recursos portuarios. La aplicación de señalamiento se utiliza para instalar y manejar circuitos. El contenido de WO2003027807 es incorporado por este medio en la descripción por referencia. En la técnica anterior ya señalada, cualquier interrupción se debe proporcionar para permitir al aparato de conmutación que se ha pre-configurado, proporcionar un servicio sin conexión y/o servicio sin conexión legado retenido. Por ejemplo, en WO2003027807, una dirección en un subconjunto de conexión orientada se utiliza como etiqueta de trayectoria para una conexión establecida por un plano de conexión orientada de control. Sin embargo, la reservación de un subconjunto del espacio de dirección para identificar una trayectoria conmutada de etiqueta de conexión orientada requiere, además de las funciones de conmutación legadas, un administrador de dirección y planos múltiples de control (el plano de control dedicado a soportar el modo de conexión orientada se debe complementar por un plano sin conexión de control para soportar el modo sin conexión). Por otra parte, para soportar el modo sin conexión, las funcionalidades de árbol extendido no se pueden conmutar para el subconjunto apropiado, y el plano de conexión orientada de control debe tener una vista completa de la red antes de que las trayectorias de conexión orientada puedan utilizar los vínculos inhabilitados por el protocolo de árbol extendido. Los expertos en la materia estarán por enterados del Institute for Electrical and Electronic Engineering's Standard IEEE 802.1Q™ titulado "Local and metropolitan área networks, Virtual Bridged Local Área Networks" que describe una arquitectura para Virtual Bridged LANs, para los servicios proporcionados en Virtual Bridged LANs, y los protocolos y algoritmos implicados en la provisión de esos servicios. Este estándar describe cómo el aparato de conmutación de Ethernet se debe configurar para soportar el estándar, por ejemplo, cómo el algoritmo del árbol extendido debe implementarse y cómo los procedimientos de filtrado de datos y envío de datos deben implementarse por el aparato de conmutación. El contenido de IEEE 802.1Q™ es incorporado por este medio por referencia en la descripción. La Sección 8.10. de IEEE 802.1Q describe cómo la base de datos de filtración soporta el proceso de envío determinando cómo, en la base de la dirección del control de acceso al medio (MAC) y del identificador de LAN (VLAN) virtual (VID), las tramas recibidos de Ethernet deben ser remitidos a través de una interfaz dada (es decir, a través de un puerto potencial de transmisión). El estándar de IEEE 802.1Q™ describe cómo la base de datos de filtración abarca las entradas que son estáticas (es decir, la entrada de la base de datos es configurada explícitamente por una acción del administrador) o dinámicas (es decir, la entrada de filtración es incorporada automáticamente en la base de datos de filtración por la operación normal del aparato de conmutación de Ethernet y de los protocolos que soporta). La información de filtración estática de IEEE 802.1Q™ para el individuo y para las direcciones de MAC del grupo incluye la información para permitir el control de administración sobre cómo un cuadro con una dirección destino particular se remite y la información para permitir el control de administración sobre cómo las tramas con VLAN-IDs particulares se remiten, y cómo las entradas de etiqueta de VLAN son agregadas a/extraídas de las tramas remitidos. Debajo de IEEE 802.1Q™, la información de filtración estática tal como la información de la dirección de MAC, un VID, y el mapa portuario (que tiene un elemento de control para que cada puerto especifique la filtración para la dirección de MAC y de VID) se agrega a, se modifica, y retira de la base de datos de filtración bajo el control explícito del administrador. Por ejemplo, usando la capacidad del administrador puente remoto bajo los recursos de IEEE 802.1Q™ se puede identificar, inicializar, re-establecer/apagar, las relaciones del recurso determinado y los parámetros operacionales suministrados. Sin embargo, mientras que IEEE 802.1Q describe el uso del administrador de puente remoto para llenar las bases de datos de filtración con las entradas estáticas, esto es siempre en el contexto de complementar la información de filtración dinámica que se genera automáticamente. Por otra parte, IEEE 802.1Q™ requiere siempre el árbol extendido y otros protocolos para funcionar y asegurar que bucles no ocurran, es decir, es necesario que cada puente opere un protocolo de árbol extendido para calcular, una o más topologías activas conectadas completamente libres de bucles por configurar ciertos puertos para quitar lógicamente cualquier conexión físicamente con bucles con otros puentes. La US 2005/0220096 describe un método de ingeniería de tráfico en redes basadas en tramas tales como redes de Ethernet en las cuales las conexiones son establecidas configurando, en varios nodos, trazos para las tramas de datos de envío (tales como tramas de Ethernet). Los trazos asocian una combinación de a) la dirección de destino que corresponde a un nodo de destino de la conexión y de un identificador tal como una etiqueta de VLAN con un puerto de salida seleccionado del arreglo de conmutador. En la US 2055/0220096 los trazos utilizan una combinación de la dirección de destino y del identificador para permitir las tramas de datos que pertenecen a diversas conexiones que se remitirán de manera diferente en un nodo a pesar de tener el mismo nodo de destino. En la US 2005/0220096 un medio de tratar los problemas generados al configurar las tablas de envío en conmutadores de Ethernet, es alterar el comportamiento de los conmutadores de Ethernet que forman la red del portador de modo que en vez de difundir el tráfico desconocido, los conmutadores de Ethernet desechan los paquetes y posiblemente expiden una alarma, registran o cuentan los paquetes desechados. Sin embargo, mientras que es posible fijar el nivel del volumen de difusión a cero en algunos conmutadores de Cisco™, ninguna motivación para fijar el volumen de difusión así bajo ha existido hasta ahora pues esto daría lugar generalmente a un número inaceptable de paquetes desechados (debido a que su dirección de envío es desconocida). En la U.S 2005/022096 en vez de usar auto-aprendizaje para configurar las tablas de envío en conmutadores de Ethernet, se configuran las tablas de envío dirigidas usando un plano de control de Ethernet nuevo. En la US 2005/022096, el plano de control abarca un número de controladores de conexión que corresponden a cada conmutador de Ethernet. Cada controlador de conexión controla la conmutación de su conmutador respectivo usando la interfaz de control de conexión que señala cuál se utiliza para configurar directamente las tablas de envío usadas por los conmutadores de Ethernet de la red portador. En la US2005/022096, el control de flujo es implementado distinguiendo los flujos a la misma dirección de destino basado en el ¡dentificador virtual de la red de área local de cada trama recibida del tráfico (es decir, basado en la VLAN-ID). En la US 2005/022096 los controladores de conexión pueden comunicarse entre sí mismos usando la Interfaz de Red a Red (NNI), e intercambiando típicamente la información con respecto a su estado operacional y al estado de sus vínculos de comunicaciones usando el señalamiento de NNI. Otras funciones del plano de control tal como las descritas en Y.17ethOAM, también se describen. El contenido de US 2005/022096 y de su Solicitud de Patente subsecuente PCT, son incorporados por este medio por referencia en la descripción. En el IETF Draft Recommendation draft-kawakami-mpls-lsp-vlan-00.txt con fecha del 29 de marzo de 2004, por Kawakami y colaboradores, un método se propone para instalar un túnel de capa 2 sobre las redes basado en la tecnología de Ethernet. Kawakami y colaboradores, describe la configuración de puertos de un conmutador de Ethernet para remitir los paquetes etiqueta- etiquetados VLAN entrantes de cierto puerto a otro puerto inequívoco usando la información de la etiqueta de VLAN. Los conmutadores de Ethernet son una parte de los enrutadores de conmutación de etiqueta (LSRs), que distribuyen las etiquetas de VLAN usando el Protocolo de Distribución de Etiqueta (LDP).
Para permitir que un LDP cumpla esta función, se propone una extensión de LDP. Kawakami y colaboradores, propone la creación de LSP sobre Ethernet usando la conmutación de etiqueta de VLAN en donde la información se transporta en el plano de envío y el plano de control. El plano de envío utiliza el componente de envío de una VLAN-LSR mientras que el plano de control controla la distribución de etiqueta de LSP y proporciona el administrador para el LSP. Kawakami también describe una entidad de administración de la red que calcula las trayectorias (la información de VLAN-LSP) y control la carga de la red. El contenido de IETF Draft Recommendation draft-kawakami-mpls-lsp-vlan-00.txt con fecha de 29 de marzo de 2004, por Kawakami y colaboradores es incorporado por este medio por referencia en la descripción. La técnica anterior citada arriba se relaciona con cualquier repartición de dirección-espacio para proporcionar un servicio sin conexión o de conexión orientada o requiera la reservación de un intervalo de direcciones, etc., en la fuente de tráfico tal que cierto tráfico se pueda identificar por el aparato de conmutación y enrutado en una manera de conexión orientada, aunque el formato de tráfico se conforma de otra manera al formato de tráfico que se enruta generalmente de una manera sin conexión. La presente invención intenta mitigar y/o evitar ciertos problemas asociados con el uso del aparato de conmutación preconfigurado para soportar los protocolos de comunicación sin conexión (designados adjunto como el equipo de conmutación legado) para proporcionar un servicio de conexión orientada de extremo-a-extremo. Los aspectos de la invención son según lo precisado en las reivindicaciones independientes anexas, y las modalidades preferidas de la invención se precisan en las reivindicaciones dependientes de las mismas. Así, un aspecto de la invención intenta proporcionar un método de usar un aparato de conmutación legado para proporcionar un servicio de conexión orientada, en el cual la información requerida para establecer una conexión extremo a extremo ha sido proporcionada por un procesador del plano de control. Esto elimina cualquier necesidad de proporcionar interrupciones y/o de utilizar cualquier función de evitar el aprendizaje y/o bucle de la dirección. En cambio, cada aparato de conmutación se proporciona con datos del plano de control. La información de la ruta proporcionada del plano de control se relaciona a rutas que se preconfiguran para asegurar que el aparato de conmutación proporcione un servicio de conexión orientada. En algunas modalidades de la invención, el aparato de conmutación convencional dispuesto para soportar modos sin conexión de transporte, puede requerir la modificación para permitir a su interfaz de línea de comando proporcionar la información para llenar las tablas de envío del aparato de conmutación para proporcionar un modo de conexión orientada extremo a extremo de transporte. En algunas modalidades de la invención, sin embargo, tal modificación se limita a usar un software para reconfigurar la interfaz. De esta manera, la interfaz de línea de comando permite la información que se origina desde el plano de control para llenar las tablas de envío del aparato de conmutación (mientras que convencionalmente, se llenan las tablas de envío de datos usando la información del plano de datos en una manera bien conocida a los expertos en la técnica). Así en un aspecto, la invención intenta utilizar el plano de control para configurar el aparato de conmutación legado para proporcionar un servicio de conexión orientada extremo a extremo a través de una red de comunicaciones y/o de una red interna.
Implementar la invención para proporcionar un servicio de conexión orientada sobre una red interna de comunicaciones que conecta una pluralidad de redes de área local (LANs), requiere la provisión de la información de enrutamiento constante para llenar las tablas de envío de cada aparato de conmutación dentro de la red interna. Esto se puede proporcionar por un plano centralizado de control asociado con todo el aparato de conmutación dentro de la red interna o por un plano distribuido de control, que requiere que la información sea comunicada entre el plano de control de los procesadores distribuidos. Un aspecto de la invención es proporcionar un esquema por el cual la información de administrador y la información de señalamiento sean comunicadas con seguridad al aparato de conmutación conservando cierta funcionalidad en el puerto de específicos del aparato de conmutación tal que una función de difusión pueda conservarse. El esquema retira toda funcionalidad preexistente que soporta protocolos preconfigurados en otros puertos que deban proporcionar modos de conexión orientada de transporte. Ciertas modalidades de la ¡nvención proporcionan un plano de control dispuesto para controlar dinámicamente la funcionalidad de uno o más puertos de una pluralidad de aparatos de conmutación desplegados en una red de comunicaciones para establecer una conexión para el tráfico que se conforma de otra manera a un protocolo sin conexión desde un nodo de borde fuente de la red de comunicaciones a un nodo de borde destino de la red de comunicaciones. Los nodos de borde pueden proporcionar el acceso a y desde una o más redes de área local. De esta manera, el aparato de conmutación es capaz de cambiar el modo de operación de los puertos para el enrutamiento del tráfico desde una conexión orientada a sin conexión selectivamente restaurando la funcionalidad asociada a un modo sin conexión de transporte (por ejemplo, conservando árbol extendido y los protocolos de aprendizaje de la dirección de MAC) y dejando de proporcionar la información de enrutamiento del plano de control. De esta manera, en algunas modalidades, el modo de conexión orientada puede controlar remotamente y/o dinámicamente usando el plano de control a la funcionalidad sin conexión de desactivar/eliminar/desinstalar en puertos específicos del aparato de conmutación y en lugar de proporcionar la información de enrutamiento desde el plano de control. Los datos proporcionados por el procesador del plano de control se arreglan para controlar por lo menos la función de envío de datos que el aparato de conmutación realiza en los paquetes recibidos. Los paquetes recibidos se conforman a un protocolo sin conexión. Los datos recibidos por el aparato de conmutación desde el plano de control permiten al aparato de conmutación operar para proporcionar un modo de conexión orientada de transporte para los paquetes recibidos a través de una red de comunicaciones. La información de cabecera de los paquetes conserva el formato del protocolo sin conexión mientras que es transportada de una manera de conexión orientada a través de la red. Coordinando cómo las tablas de envío de los aparatos de conmutación a través de la red de comunicaciones, se llenan desde el plano de control, el aparato de conmutación (que puede abarcar un puente, enrutador, conmutador o nudos o cualquier aparato capaz de realizar un envío conveniente de datos y/o de filtrar y/o función de conmutación) se arregla para proporcionar un ambiente de conexión orientada, es decir, es posible cambiar el modo en el cual el envío de datos es proporcionado por el aparato de conmutación (sin conexión o de conexión orientada) usando el plano de control. Así para Ethernet, los procesos sin conexión tales como el árbol extendido y los procesos de aprendizaje puente no son más requeridos en los puertos del aparato de conmutación usado para establecer una conexión a través de la red de comunicaciones debido a que el señalamiento del plano de control se proporciona y el señalamiento del plano de control se puede utilizar para determinar si una trayectoria ya ha sido transitada, lo que permite evitar los bucles. En algunas modalidades de la invención, si se recibe un paquete para el cual no se ha preconfigurado ninguna trayectoria, se cae el paquete, y toda la información requerida para establecer el servicio de conexión orientada debe llenar las tablas de dirección antes de la recepción de cualquier paquete para evitar la pérdida del paquete. Así en estas modalidades el aparato de conmutación se configura para tener una función de desecho predeterminada para los paquetes que se reciben y para cuáles no se ha proporcionado ninguna información en las tablas de dirección y de envío. El plano de control puede estar en-banda pero está preferiblemente fuera de banda que en banda ya que es más vulnerable al ataque. Ventajosamente, no hay necesidad de reservar un subconjunto del espacio de dirección disponible para funcionar como una etiqueta para implementar el servicio de conexión orientada. Debido a que el plano de control ahora está llenando por lo menos parte de las tablas de envío del aparato de conmutación en la red de comunicaciones, el plano de control puede ajustar en formato selectivamente los campos de índice sobre los cuales el aparato de conmutación realiza la operación de búsqueda para proporcionar mayor versatilidad y flexibilidad. Esto se puede hacer incluyendo campos de índice adicionales, substituyendo los campos de índice, o teniendo un número de campos de índice diferentes, que pueden ser arreglados tal que el envío se ejecute sobre una base jerárquica. En algunas modalidades, la provisión de una pluralidad de tipos diferentes de campos de índice permite que el control de flujo se realice en el caso de una congestión de un puerto saliente del conmutador automáticamente. Los expertos en la técnica apreciarán que los aspectos según lo precisado en las reivindicaciones independientes se puedan combinar con cualquiera de las características dependientes de acuerdo a lo precisado en las reivindicaciones dependientes de cualquier manera apropiada evidente a los expertos en la técnica. La invención proporciona ventajas similares a las proporcionadas por Multi-Protocol Label Switching (MPLS) sin las implicaciones de costo asociadas, el proceso de MPLS implica la hibridación de la conmutación de paquete sin conexión y de conexión orientada. Las modalidades de la invención ahora serán descritas con referencia a los dibujos anexos que están a modo de ejemplo solamente y en donde: La figura 1A muestra un plano de control de acuerdo a la invención que llena las tablas de dirección de MAC de los aparatos de conmutación de Ethernet; La figura 1B muestra esquemáticamente una modalidad alternativa de una tabla de envío llena por un plano de control de acuerdo con una modalidad de la invención; La figura 2 muestra una red de comunicaciones de Ethernet de acuerdo con una modalidad de la invención. La figura 3 muestra cómo el plano de control se interconecta con el plano de datos de una red de comunicaciones de acuerdo con una modalidad de la invención; La figura 4 muestra una modalidad de la interfaz del plano de control de la figura 3; La figura 5 muestra más detalladamente el plano de control distribuido de la figura 4; Las figuras 6A, 6B y 6C muestran ejemplos de una trama estándar de Ethernet de acuerdo con lo conocido a los expertos en la técnica; La figura 7 muestra más detalladamente cómo una etiqueta de VLAN se transporta en una trama estándar de Ethernet; La figura 8 muestra cómo Q-en-Q se transporta en una trama de Ethernet; La figura 9 muestra cómo MAC-en-MAC se transporta en una trama de Ethernet; La figura 10A muestra una modalidad de la invención en la cual se proporciona Ethernet de conexión orientada; La figura 10B muestra cómo las conexiones múltiples entre los conmutadores de Ethernet se pueden proporcionar en la Ethernet de conexión orientada de la figura 10A; La figura 10C muestra cómo puede la trama de portador encapsula la información de trama del cliente en una modalidad de la invención. La figura 11 muestra un plano de control centralizado de acuerdo con una modalidad de la invención; La figura 12 muestra una jerarquía de los procesadores del plano de control de acuerdo con otra modalidad de la invención; La figura 13 muestra el señalamiento entre los procesadores del plano de control de acuerdo con una modalidad de la invención; La figura 14 muestra el señalamiento entre los procesadores del plano de control de acuerdo con otra modalidad de la invención; La figura 15 muestra cómo el plano de control se interconecta con el plano de datos de una red de comunicaciones IP de acuerdo con una modalidad de la invención; La figura 16 muestra el formato de una cabecera de trama de IPv4; La figura 17 muestra el formato de una cabecera de trama de IPv4; La figura 18 muestra el formato de las cabeceras de trama de IP-en-IP que se conforman a RFC 1853; La figura 19 muestra cómo puede una trama de portador de IP encapsular la información de trama de IP del cliente en una modalidad de la invención; Las figuras 20 y 21 muestran cómo el señalamiento se puede proporcionar entre los procesadores del plano de control en dos modalidades de la ¡nvención; La figura 22A muestra cómo el plano de control llena una tabla de envío de acuerdo con una modalidad de la invención; La figura 22B muestra cómo el plano de control llena una tabla de envío de acuerdo con otra modalidad de la invención; y La figura 23 muestra cómo las tramas de tráfico del cliente se pueden encapsular dentro de las tramas de un proveedor de acuerdo con una modalidad de la ¡nvención. Las modalidades de la invención, incluyendo el mejor modo de la invención contemplado actualmente por los inventores, ahora serán descritas con referencia a los dibujos anexos En la descripción siguiente, para propósitos de explicación, numerosos detalles específicos se disponen para proporcionar una comprensión cuidadosa de la presente invención Será evidente, sin embargo, a un experto en la técnica, que la presente invención se puede practicar sin estos detalles específicos En otros casos, estructuras y dispositivos bien conocidos se muestran en forma esquemática simplificada para facilitar la explicación y el detalle adicional conocido a un experto en la técnica se ha omitido por claridad Donde es evidente a los expertos en la técnica, un componente alternativo posible con funcionalidad equivalente, la descripción se desea que incluya de forma implícita tales equivalentes funcionales a menos que se excluya explícitamente Un esquema de enumeración constante se utiliza para todos los componentes en los dibujos que tienen funcionalidad equivalente a menos que se indique de otra manera Por simplicidad, a menos que haya una necesidad de distinguir entre los componentes diferentes, las características serán referidas como el aparato de conmutación 20 y red 18, en lugar del aparato de conmutación 20a, b, c, d, e, f y red 18a, b, c, d, e, etc Refiriéndose ahora a los dibujos anexos, las figuras 1A y 1B muestran esquemáticamente cómo un plano de control de acuerdo con la invención llena las tablas de dirección de MAC de los aparatos de conmutación de Ethernet La figura 1A muestra esquemáticamente cómo un plano de control 12 se puede utilizar para llenar las tablas de envío de dirección 1a, 1b y las tablas de filtración de dirección 3 del aparato de conmutación de Ethernet 20. En lugar del aparato de conmutación de Ethernet 20 que llena las tablas de envío de la manera convencional, por ejemplo, enseñando qué puertos se asocian con que direcciones de MAC, el plano de control se utiliza para configurar directamente las tablas de dirección de MAC para asociar identificadores portuarios específicos a las tramas recibidas de MAC de Ethernet). El término "puerto" es equivalente a la "interfaz" en el contexto evidente a los expertos en la técnica. Similarmente, donde se ha hecho referencia a una forma particular de PDU, por ejemplo, un paquete, el término "paquete" se debe leer como sinónimo para cualquier PDU equivalente, por ejemplo, la trama para la cual la invención puede implementarse. Debido a que las tablas de envío del aparato de conmutación se proporcionan directamente con la información de dirección asociada a los puertos salientes del aparato de conmutación, no hay necesidad de implementar un proceso de "aprendizaje la dirección" para permitir al aparato de conmutación asociar el tráfico recibido cuya dirección de destino es desconocida con un puerto saliente del aparato de conmutación. En cambio, si no se conoce ninguna asociación de dirección y puerto saliente, entonces el aparato de conmutación desecha el paquete recibido. Aunque en IEEE 802.1q, una interfaz para el plano de control se utiliza para proporcionar la información estática de dirección, en IEEE 802.1q, los protocolos existentes tales como el árbol extendido y los protocolos de aprendizaje de la dirección de MAC, siguen estando activos. En contraste, la invención configura de nuevo el aparato de conmutación de modo que la información proporcionada por el plano de control a las tablas de dirección de envío del aparato de conmutación no sea capaz de sobreescribirse de manera autónoma por los protocolos preexistentes asociados al plano de control sin conexión ahora inusitado. Una dirección de MAC se asume generalmente que es un valor único asociado al adaptador de la red de un nodo e identifica únicamente el adaptador en una Red de Área Local (LAN). Un ejemplo de la dirección de MAC es un número hexadecimal de 12-dígitos (48 bits en longitud) (por ejemplo, tal como es mostrado en la tabla 1a por MM:MM:MM:SS:SS:SS en la figura 1A). La primera mitad del campo de dirección es el número ID del fabricante del adaptador. La segunda mitad del campo de dirección es el número de serie asignado al adaptador por el fabricante. El aparato de conmutación de Ethernet 20 puede funcionar en modo de mital-dúplex o dúplex completo, y es capaz de soportar un servicio de protocolo OSI-capa-2 dúplex completo, punto a punto en un modo de menos colisión completamente. El aparato de conmutación de Ethernet 20 recibe tramas de Ethernet desde la LAN A y enruta las tramas a LAN B usando las tablas de dirección 1a, 1b asociadas a cada uno de sus puertos y tabla de filtro 3. La tabla de filtro 3 limita el tráfico a ciertas asociaciones portuarias lógicas, tal como se utiliza, por ejemplo, para configurar Redes de Área Local Virtuales. La figura 1B muestra una versión alternativa de una tabla de envío, en la cual el plano de control 12 llena las entradas en la tabla de envío con por lo menos otro campo de cabecera de Ethernet además del campo de dirección de destino. En la figura 1B, el plano de control asocia además una VLAN con un puerto saliente, o de salida del conmutador. Este VLAN-ld se utiliza para distinguir entre trayectorias múltiples a través de una red de comunicaciones que comprende una pluralidad de aparatos de conmutación de Ethernet conectados. Sin embargo, de acuerdo con lo mencionado más adelante en detalle adjunto posteriormente, un número de otros campos alternativos de cabecera de Ethernet se pueden proporcionar para llenar la tabla de envío del aparato de conmutación. De acuerdo con la invención, no hay necesidad de asignar subconjuntos del espacio de dirección o de cualquier otro campo de cabecera para señalar un paquete particular para recibir el envío de conexión orientada. En cambio, una conexión a través de la red de comunicaciones es establecida por el plano de control proporcionando la información apropiada de envío en el aparato de conmutación para el espacio de dirección asignado al tráfico para el cual la conexión debe preporcionarse. El tráfico se puede identificar por el plano de control usando cualquier campo de cabecera o combinación apropiada de los campos de cabecera, y el tráfico diferente se puede proporcionar con diversas combinaciones del campo. El operador de la red o el proveedor de servicio para la red central puede proporcionar selectivamente un servicio de conexión orientada para el tráfico del protocolo sin conexión a través de la red central. Esto, puede ser de acuerdo con las condiciones en la red central generalmente, o si el tráfico a una dirección de destino particular está desequilibrando la red, etc. La decisión para proporcionar un servicio de conexión orientada para el tráfico se puede también realizar automáticamente. Alternativamente, una petición de conexión se puede implementar de la manera bien conocida a los expertos en la técnica. Una vez que se haya determinado que una conexión se debe establecer a través de la red central a una dirección de destino particular, el plano de control se utiliza para configurar el aparato de conmutación a través de la red de comunicaciones y establecer la conexión para el tráfico basado en asociar una entrada de índice a un puerto saliente o interfaz del aparato de conmutación. Los ejemplos de las entradas de índice ¡ncluyen: dirección de destino, o una combinación de la dirección de destino y una o más de otra información del campo de cabecera, tal como VLAN-ID, o Ethertype, o si una etiqueta de prioridad está presente en la cabecera, o la etiqueta de flujo de IP o tipo de servicio. Las Figuras 1C y 1D muestran modalidades alternativas de las tablas de envío para las cuales el plano de control se puede configurar para proporcionar la información de envío de acuerdo con las modalidades de la invención. En la figura 1C, el plano de control ha llenado el campo(s) de índice con una combinación de diversos tipos de índice. El aparato de conmutación se puede configurar en este caso para buscar diversos campos que se igualarán, o continuar buscando sus entradas en el caso de que el puerto de salida particular primero igualado se congestione. Esto también permitirá que diversas trayectorias se puedan establecer para el tráfico. Así en la figura 1C, a modo de ejemplo, si un paquete fue recibido con la VLAN-ID tipo #1 para una dirección de destino particular asociada con el port-ID #1 del aparato de conmutación, el aparato de conmutación puede comprobar la Ethertype del paquete recibido, y si iguala la entrada siguiente del campo de índice, enruta el puerto vía el port-ID#2, o si este puerto estuviera congestionado o si no se encontró ninguna igualación para Ethertype, comprueba la prioridad del paquete, etc. Alternativamente (o adicionalmente), los paquetes que no tienen ningún campo de VLAN-ID se pueden remitir en la base de Ethertype o a cierto otro campo de cabecera, etc. El tipo de información en el cual una búsquea puede ser realizada es limitado solamente por el tipo de información que el aparato de conmutación puede extraer del campo de cabecera, y la capacidad del plano de control (y de cualquier parte requerida del software) de llenar la tabla de envío con una entrada de índice en una forma conveniente. La figura 1D muestra una forma alternativa de tabla de envío en la cual el plano de control proporciona un tipo fila de identificador de índice para cada puerto, en este caso la dirección de destino, y un primer y segundo identificador de índice. Por ejemplo, cada puerto se puede asociar a un DA, VLAN-ID, y a otro identificador de índice, por ejemplo, la Ethertype. Refiriéndose ahora a las figuras 2 y 3 de los dibujos anexos, la funcionalidad de la red de comunicaciones de Ethernet es proporcionada por un plano administrador 10, un plano de control 12 y un plano 14 de datos/envío (véase la figura 3). El plano 10 administrador proporciona las interfaces apropiadas para configurar, controlar y manejar la red de Ethernet. El plano de control 12 proporciona las interfaces lógicas y físicas para instalar y controlar las actividades del plano 14 de datos/envío (véase la figura 3) vía la interfaz de línea de comando o por cualquier otra manera especificada en cualquiera de los estándares de IEEE, por ejemplo, IEEE 802.1. El plano 12 administrador y/o de control puede realizar las funciones de control de llamadas y de control de conexión, y usar el señalamiento para instalar y suministrar las conexiones y restaurar las conexiones en el caso de falla, por ejemplo estableciendo conexiones permanentes suaves. El plano 14 de envío de datos proporciona la funcionalidad de filtración y de envío usada para transportar los datos de la red. La invención permite los paquetes que se conforman a los protocolos sin conexión que se transportarán a través de una red de comunicaciones en un modo de conexión orientada proporcionando la información de enrutamiento al aparato de conmutación legado e inhabilitando las funciones del aparato de conmutación que pueden sobreescribir o si no proporcionar otra información de enrutamiento. La información de enrutamiento proporcionada permite al aparato de conmutación proporcionar un servicio de conexión orientada conforme toda la funcionalidad del aparato de conmutación que daria lugar a un servicio sin conexión, es inhabilitada. Tal aparato de conmutación es fácilmente disponible y es relativamente económico, mientras que el aparato de conmutación construido para soportar un protocolo de conexión orientada tal como MPLS, es relativamente costoso. Una ventaja potencial de la invención es que permite al equipo legado configurado para soportar los protocolos de comunicación sin conexión, crecer para soportar modos de conexión orientada de comunicación. Ventajosamente, la invención también permite servicios que se distinguen en términos de calidad del servicio, prioridad, ancho de banda, etc. De acuerdo con la invención, el plano de control proporciona la información de enrutamiento, por ejemplo, el equipo que genera la información de control para el aparato de conmutación se utiliza para proveer al aparato de conmutación con la información de enrutamiento y señalamiento. Esta información de control incluye la información que se puede utilizar para llenar las tablas de enrutamiento de búsqueda del aparato de conmutación. El aparato de conmutación diseñado e instalado originalmente en una red de comunicaciones para soportar protocolos de comunicación sin conexión, puede así proporcionar un servicio de conexión orientada a los paquetes recibidos. El término "paquete" se utiliza de forma sinónima para implicar un paquete o una celda (por ejemplo un paquete de longitud fija), o en algunas modalidades de la invención una trama ya que los expertos en la materia la encontrarán evidente. Los datos para la transmisión a través de una red están montados en paquetes cada uno de los cuales lleva una cabecera y una carga útil, la cabecera que indica fuente y las direcciones del receptor y la carga útil que lleva los datos que se suministrarán. Los paquetes también llevarán otros campos de datos que se relacionen con la validez del paquete total que es transmitido. Los paquetes no necesitan modificar su información de cabecera para poder beneficiarse del servicio de conexión orientada proporcionado por el aparato de conmutación. Ejemplos de protocolos sin conexión para los cuales un servicio de conexión orientada puede ser proporcionado por el aparato de conmutación que se conforma a la invención incluyen los protocolos de Ethernet estándar y los protocolos de Internet estándar (por ejemplo IPv4 e IPv6). De acuerdo con la invención, el aparato de conmutación se proporciona con los medios para recibir la información de control, y el plano de control (un término utilizado adjunto para referir a cualquier arreglo conveniente de aparato capaz de proporcionar tal información de control al aparato de conmutación) dirige señales de datos del canal a través de la sección de conmutación para efectuar la transmisión de datos desde una "fuente" a un "receptor". La fuente puede ser una PC o un servidor tal como puede ser el receptor, la fuente refiere a la unidad de transmisión y al aceptor del receptor. Será apreciado que en la mayoría de las comunicaciones las fuentes y receptores están presentes en ambos extremos del vínculo, es decir, están co-localizados, y pueden simplemente ser un transmisor/receptor de una computadora o de un circuito transmisor-receptor de un instrumento de teléfono. Todos los términos usados adjunto conservan las definiciones dadas en la International Telecommunication Union (ITU)'s ITU-T Recommendation G.805 "Generic functional architecture of transport networks", cuyo contenido es incorporado adjunto por referencia, a menos que esté indicado explícitamente con un diverso significado que sea contrario con el significado dado en G.805.
Cuando una trama llega al aparato de conmutación de Ethernet, se procesa la cabecera, y la información se extrae para permitir que la combinación fuente-receptor para el paquete sea determinada. En una modalidad de la invención, esto es determinado por comunicar la información extraída de una pluralidad de campos de cabecera al plano de control. El plano de control entonces determina si esto es un mensaje para una combinación fuente-receptor conocida. En modalidades alternativas, el plano de control ya ha comunicado la información suficiente para permitir que la combinación fuente-receptor sea determinada en el aparato de conmutación. Si se conoce la combinación fuente-receptor, por lo que se entiende si la información extraída de la cabecera iguala la información ya retenida en un almacén de datos accesible por el aparato de conmutación, una sola ruta previamente establecida se utiliza para transferir el mensaje a través de la sección de conmutación de datos. Refiriéndose ahora a la figura 2, una modalidad de la invención se muestra en la cual una red de comunicaciones 16 (por ejemplo, una red de área amplia (WAN)) que comprende una primera red 18a de hospedadores locales, por ejemplo una LAN del cliente, está conectada a una segunda red 18b de hospedadores locales, por ejemplo otra LAN del cliente, vía una pluralidad de aparatos de conmutación interconectados 20 de Ethernet. Por claridad, cuatro aparatos 20 de conmutación de Ethernet se muestran en la figura 2, que se etiquetan A, B, C, y D. En la figura 2, la red 18a proporciona una fuente 22 de tráfico que se transmite vía un dispositivo conveniente de borde 24 (por ejemplo, una concentración de tráfico significa el abastecimiento de cierta funcionalidad de multiplexación) al conmutador de Ethernet A. La red 18d de acuerdo con lo mostrado en la figura 2 funciona como el receptor 26 de tráfico de Ethernet, y recibe el tráfico de Ethernet desde el conmutador D de Ethernet vía un dispositivo de borde apropiado 28 (por ejemplo, medios de desconcentración del tráfico que proporcionan una función de des-multiplexación). Una red local puede, sin embargo, en práctica funcionar como una fuente y un receptor del tráfico de Ethernet, al igual bien conocido por los expertos en la técnica. En la figura 2, la información de enrutamiento para las tablas de enrutamiento del aparato de conmutación de Ethernet A es ingresada por un administrador de la red 30 usando una interfaz de línea de comando apropiada (CLI) 32a. La información de enrutamiento se proporciona similarmente vía CLIs 32b, c, d para llenar las tablas de envío de cada uno de los aparatos de conmutación de Ethernet 20 B, C, D. Otra funcionalidad se puede implementar en un aparato de conmutación de Ethernet, por ejemplo, tal como un rastreador de paquetes 34 en el aparato de conmutación de Ethernet D. De acuerdo con lo mencionado anteriormente, para funcionar correctamente como un aparato de conexión orientada de conmutación de Ethernet, debido a que el aparato de conmutación fue preconfigurado para soportar protocolos de comunicaciones sin conexión, los protocolos preconfigurados (por ejemplo los protocolos de árbol extendido y de aprendizaje puente, y cualquier protocolo de control de VLAN específico no requeridos por la invención) se deben desactivar para todos los puertos en los aparatos de conmutación de Ethernet que proporcionan el servicio de conexión orientada. En el mejor modo de la invención, toda la funcionalidad que soporta los protocolos preconfigurados en todos los puertos del aparato de conmutación, es inhabilitada. En otras modalidades de la invención, la funcionalidad específica se conserva en los puertos especificados del aparato de conmutación. Esto permite el uso de redes de área local virtuales (VLANs) para los propósitos de manejo. Por ejemplo, se permite que un medio de difusión alcance el autodescubrimiento de nuevos vínculos y nuevos nodos, pero confinado solamente al administrador de VLAN. Las entradas de la tabla de enrutamiento asociadas a todos los puertos que proporcionan un servicio de conexión orientada se llenan usando la información proporcionada por el plano de control vía una interfaz de línea de comando (CLI) o por cualquier otra manera especificada en un estándar de IEEE, por ejemplo, IEEE 802.1. Proporcionando la información de enrutamiento para llenar la tabla de enrutamiento usando la interfaz que se utiliza para transportar la información de control estándar al aparato de conmutación, cualquier aparato de conmutación que se conforme con los requisitos estándares prevalecientes para soportar protocolos de comunicaciones sin conexión, se puede reconfigurar para soportar los modos de conexión orientada de comunicación. Así, para el aparato de conmutación de Ethernet, para proporcionar una conexión extremo a extremo, cada conmutador A, B, C, D se llena con las entradas de la tabla de envío apropiadas para la conexión extremo a extremo, ya que la información de cabecera de enrutamiento de Ethernet es igual en cada conmutador. Una conexión extremo a extremo se puede especificar del plano de control explotando la unicidad global ya inherente en el esquema de direccionamiento de Ethernet MAC. Si las direcciones de MAC no son únicas por cierta razón, se proporcionan algunos otros medios de conferir una identidad única a la fuente de tráfico, por ejemplo usando una cabecera de VLAN, descrita en detallade más adelante en la presente. La figura 3 muestra esquemáticamente una modalidad de la ¡nvención en la cual una red 12 del plano de control se arregla para proporcionar la información de enrutamiento al plano 14 de datos. En la figura 3, se muestra una pluralidad del aparato de conmutación de Ethernet interconectado 20, etiquetado A, B, C, D, E, y F. Las redes de Ethernet se muestran interconectadas completamente en las figuras 3, 4, y 11, pero para beneficiarse de la invención, es suficiente que una pluralidad de trayectorias exista entre los aparatos de conmutación de Ethernet. En la figura 3, cada aparato de conmutación de Ethernet 20 está conectado a una red de área local 18 (LAN), y está conectado adicionalmente a uno o más aparatos 20 de conmutación de Ethernet para proporcionar una red de comunicaciones más grande 16, por ejemplo, una red de área amplia (WAN). Donde una LAN particular se asocia con una LAN virtual particular (VLAN), el tráfico será marcado para identificarlo como perteneciente a la VLAN (véase las figuras 6, 7) y el tráfico de VLAN tendrá acceso a la red de Ethernet 16 solamente vía el puerto nativo en el aparato de conmutación de Ethernet 20 asociado con la VLAN. En la figura 3, la funcionalidad de filtración y de envío de datos de Ethernet de todos los puertos en cada aparato de conmutación de Ethernet 20 proporcionado en el plano 14 de datos, es controlada de la red del plano de control 12 vía la interfaz de línea de comando 32a, b, c, d, e, f asociada a cada aparato de conmutación de Ethernet 20. La red del plano de control 12 abarca la red de comunicaciones del plano de control extremo a extremo que desactiva y configura las funcionalidades de envío/filtración de datos del árbol extendido y de aprendizaje de todos los puertos de cada aparato de conmutación de Ethernet 20 en la red de comunicaciones que ofrece un servicio de conexión orientada y finaliza en todas las unidades de datos de protocolo asociadas puente (BDPUs) en los puertos. La red del plano de control 12 se puede implementar de una manera centralizada o en una forma distribuida, dependiendo del número de los procesadores del plano de control (CPPs) 36 (no mostrado en la figura 3), cómo se despliegan en la red y su relación a cada aparato de conmutación de Ethernet 20. Una vez que las funcionalidades del árbol extendido y de aprendizaje de la dirección de MAC se hayan inhabilitado (por ejemplo por el plano de control 12 o manualmente inhabilitándolas en el conmutador), el plano de control 12 crea y proporciona la información de enrutamiento necesaria para llenar las tablas de dirección de MAC y de VLAN-ID y cualquier otra entrada de las tablas del campo de cabecera. El aparato de conmutación de Ethernet entonces utiliza esta información para establecer las conexiones de vínculo de Ethernet apropiadas 42 entre los mismos aparatos de conmutación de Ethernet. Es posible que el aparato de conmutación de Ethernet soporte conexiones de vínculo unidireccionales y/o bidireccionales (y proporcionar así un servicio dúplex completo, al igual bien conocido por los expertos en la técnica). Cada aparato de conmutación de Ethernet 20 ¡mplementa el envío de datos basado en la cabecera de VLAN más baja de cada trama del tráfico de Ethernet recibida al realizar una operación de búsqueda en el identificador para la VLAN (VLAN-ID) en su tabla de envío. Debido a que la tabla de VLAN-ID ahora está llena por la información derivada del plano de control del aparato de conmutación, los datos serán remitidos de tal manera que proporcionen un servicio de conexión orientada. Si no hay cabecera de VLAN, entonces el aparato de conmutación remite la trama recibida de Ethernet usando por lo menos la dirección de MAC de destino. Se proporciona el proceso de envío después de que las cabeceras de VLAN se asociaran a las capas de red que finalizan en un aparato de conmutación de Ethernet 20 particular se hayan retirado del protocolo de VLAN apilado en este aparato de conmutación. Además, una o más cabeceras de VLAN nuevas se pueden agregar a la pila de protocolo de VLAN en los puertos de salida del aparato de conmutación de Ethernet 20. En la práctica, la operación de búsqueda para proporcionar un servicio de conexión orientada se puede realizar para un número de campos de la cabecera de Ethernet, y como tal, permite servicios diferentes a proporcionarse por diversos flujos de VLANs/tráfico, por ejemplo, los servicios que difieren en la calidad de servicio, prioridad, ancho de banda, etc. El control del aparato de conmutación proporcionado por el plano de control 12 implementa las funciones de control (o un subconjunto apropiado) identificadas y descritas en la "International Telecommunication Union ITU-T Recommendation G.8080, titulada Architecture of the automatically switched optical network (ASON), cuyo contenido es incorporado por este medio por referencia. Las modalidades preferidas de la invención implementan un plano de control de una manera constante con G.8080 que permite el concepto de una conexión y de una llamada, la separación del plano de control y de usuario, y la separación del control de llamada y del control de conexión. Alternativamente, GMPLS, MPLS, o un plano de control de PSTN legado, o un sistema de dirección de la red puede utilizarse. El plano de control 12 tiene visibilidad sobre la red de Ethernet y así está por enterado que recursos están libres. Una vez que una trayectoria de A a D se ha señalado, el plano de control 12 necesita saber en D qué recursos están disponibles para establecer la conexión, es decir, para determinar qué recursos están libres. Por ejemplo, si VLAN-ID 50 está libre, el plano de control 12 informa a todos los aparatos 20 de conmutación vía los procesadores del plano de control (CPPs) 36 (no mostrados explícitamente en la figura 3) que utilicen VLAN 50. Cuando una petición de conexión es recibida por un CPP 36, el CPP 36 procesa la petición de determinar cómo hablar con el CPP 36 en el extremo lejano del plano de control 12 (es decir, el CPP 36 para el aparato de conmutación de Ethernet 20 en el cual el tráfico sale de la red central de Ethernet) y con todos los CPPs intermedios 36. La petición puede proporcionar una ruta específica o identificar límites, y puede solicitar que el CPP 36 encuentre una ruta. En las modalidades donde una solicitud para la conexión es recibida por un procesador del plano de control (CPP) 36 vía un aparato de conmutación de Ethernet 20 para el cual el CPP 20 controla la funcionalidad del envío de datos y de filtración, el aparato de conmutación de Ethernet 20 funciona de forma silenciosa cuando se envía la solicitud por la conexión al CPP 36 (es decir, el CPP 36 no controla cómo el aparato de conmutación de Ethernet 20 transmite las peticiones de conexión recibidas al plano de control 12). Refiriéndose ahora a la figura 4 de los dibujos anexos, el plano de control 12 se muestra esquemáticamente comprendiendo una pluralidad de procesadores del plano de control interconectados adjuntos (CPP) 36a, b, c, d, e, f. El término "adjunto" se utiliza en la presente para indicar que el procesador no está "en-conmutador", es decir, que no es parte del conmutador preconfigurado original. Cada aparato de conmutación de Ethernet 20 está conectado a una red 18 local que comprende los hospedadores locales interconectados (por ejemplo, una LAN del cliente). Cada red 18 asociada a una VLAN ID se proporciona con un puerto predeterminado (o nativo) en el aparato de conmutación de Ethernet 20, y las tablas de VLAN ahora se llenan con la información proporcionada por el plano de control 12. El plano de control 12 conserva la información de enrutamiento, que se utiliza para llenar las tablas de envío de datos (es decir, las tablas de dirección de MAC 1a, b y/o las tablas de filtración 3 mostradas en la figura 1C) proporcionadas en el plano de envío de datos con la información de envío de datos. En la figura 4, la información de enrutamiento se proporciona para cada aparato de conmutación de Ethernet 20 vía su respectiva interfaz de línea de comando (CLI) 32 (mostrada como una barra en la línea discontinua que conecta cada procesador del plano de control 36 y su aparato asociado de conmutación de Ethernet 20 en la figura 4). En la figura 4, cada CPP 36 se arregla en correspondencia uno por uno con el aparato de conmutación de Ethernet que los controla. La información se intercambia entre los CPPs 36 por medio de una red de señalamiento apropiada (véase figura 5 por ejemplo). La figura 5 muestra cómo una red de señalamiento entre una pluralidad de CPPs 36 se puede configurar en el plano de control 12 para facilitar la instalación de la conexión. Uno de la pluralidad de CPPs 36 recibe la petición de conexión y comunica esto al plano administrador o a otro medio de enrutamiento que determina una ruta apropiada (o rutas si se sigue una pluralidad de trayectorias) para que el tráfico siga desde el nodo de fuente al nodo destino a través del plano 14 de datos. La red de señalamiento se puede implementar en la forma de una VLAN que interconecta una pluralidad o todos los aparatos de conmutación dentro del plano de datos tal que la información de señalamiento es enrutada por separado desde el tráfico sin-señalamiento. De esta manera, es posible configurar el aparato de conmutación para conservar algunos puertos configurados para la función en un modo de operación sin conexión y/o para conservar los protocolos de enrutamiento tales como el árbol extendido, etc., para la información de señalamiento, aunque el árbol extendido y cualquier otro protocolo sin conexión de enrutamiento serán inhabilitados en los otros puertos del aparato de conmutación, es decir, de modo que el tráfico normal se conmutado de una manera de conexión orientada. Volviendo ahora a la figura 4, cada CPP 36 abarca un procesador adjunto que genera la información que controla cómo la tabla de envío de datos del aparato de conmutación de Ethernet 20 se actualiza. Cada CPP 36 también previene el daños a las tramas con las direcciones de MAC o cabeceras de VLAN que no son reconocidos por la información de señalamiento proporcionada al pasar a través del aparato de conmutación vía los puertos que ofrecen el servicio de conexión orientada. Por ejemplo, las tramas que no reconocen las direcciones de MAC o de VLAN-IDs pueden desecharse. Aparte de ser capaz ahora de ofrecer un servicio de conexión orientada, la funcionalidad restante del aparato de conmutación de Ethernet 20 está sin cambios, pues el cambio en el comportamiento del aparato de conmutación necesario para proporcionar el servicio de conexión orientada es simplemente un resultado de cambiar las entradas de la tabla de envío para proporcionar tal servicio. Conforme el plano de control 12 está llenándose, las tablas de envío y ahora el algoritmo del árbol extendido es inhabilitado, el algoritmo del árbol extendido ya no evita que las rutas múltiples sean establecidas y las trayectorias múltiples entre la fuente de Ethernet y el receptor que usan los troncos 42 de Ethernet a través de la red, son posibles. Esto permite la funcionalidad tal como balancear la carga que se pondrá en ejecución a través de la red. La figura 4 muestra dos trayectorias a-i, a2 entre los aparatos de conmutación de Ethernet A y D. La trayectoria a-¡ es vía el aparato de conmutación de Ethernet B y C, y a2 es vía el aparato de conmutación de Ethernet F y E. Las conexiones múltiples se pueden ahora proporcionar usando el aparato de conmutación de Ethernet 20 que ofrece un servicio de conexión orientada. Como un ejemplo, el tráfico se puede conmutar a una trayectoria nueva dinámicamente si su trayectoria actual sufre un nivel inaceptable de degradación conforme el plano de control se puede utilizar para reconfigurar dinámicamente el flujo de tráfico A a D. Por ejemplo, un operador de red 30 puede reconfigurar el flujo de tráfico en caso que el rastreador de paquete 34 detecte la congestión en el aparato de conmutación de Ethernet 20d como se muestra en la figura 2. Esto permite una fuente de banda ancha alta del tráfico de Ethernet para mantener su calidad de servicio a su receptor incluso cuando el otro tráfico se genera posteriormente que afecta la trayectoria original a^ sobre la red. El tráfico se puede también enviar simultáneamente a lo largo de dos trayectorias (por ejemplo a,, a2) o más trayectorias simultáneamente si se requiere la banda ancha, y se apropia de secuenciar, etc., las operaciones se pueden realizar en el aparato de conmutación de Ethernet destino 20 D. En una modalidad adicional de la invención, las entradas de la tabla de envío de datos de todos los aparatos de conmutación de Ethernet asociados con ambas rutas a,, a2 se pre-llenan, de modo que si a, falla, uno necesita solamente re-llenar la tabla de envío del aparato de conmutación de Ethernet fuente 20A para efectuar el cambio sobre la ruta ai a la ruta a2. Los procesadores del plano de control CPP 36 proporcionan la funcionalidad del control de conexión de llamada además de proporcionar la información de enrutamiento. En la figura 4, el CPP 36a que controla el aparato de conmutación A se muestra recibiendo una petición de conexión. El CPP 36a entonces determina una ruta apropiada para el tráfico que se origina de la red 18a del cliente fuente a la red del cliente receptor 18d. El CPP 36a también asegura que el señalamiento apropiado se envíe al otro aparato de conmutación de Ethernet 20 en la ruta que CPP 36a ha determinado (por ejemplo, para la trayectoria a-i, el aparato de conmutación de Ethernet B, C y D) de modo que sus tablas de envío sean apropiadamente actualizadas. Si están las etiquetas de VLAN presentes en las cabeceras del paquete de Ethernet, en una modalidad de la invención, los flujos de tráfico se separan usando etiquetas de VLAN. Esto permite implementar la administración apropiada del tráfico (por ejemplo, permitir el balance de la carga de red). Las etiquetas de VLAN no necesitan ser interconmutadas, y si no se intercambian pueden ser utilizadas como parte de un identificador global si se combinan con una dirección de VLAN. De esta manera, una solución completamente escalable para manejar una red escalable se puede proporcionar por ejemplo, por el tráfico de envío basado en una combinación de la dirección de destino y de la etiqueta de VLAN, o apilando las etiquetas de VLAN (tal como ocurre al implementar Q-en-Q de la manera conocida a los expertos en la técnica). Si las etiquetas de VLAN son interconmutadas por el aparato de conmutación de Ethernet, una VLAN-ID permanecerá solamente por importancia local. Una conexión extremo a extremo entre el aparato de conmutación de Ethernet fuente A y el aparato de conmutación de Ethernet receptor D es proporcionada así llenando cada una de las entradas de la tabla de envío para la tabla de aprendizaje de dirección de MAC y la tabla de VLAN-ID para cada aparato de conmutación de Ethernet 20 a lo largo de una trayectoria (por ejemplo a-, y/o a2) con las entradas apropiadas de la tabla de envío. El envío es implementado por la tabla de envío que iguala la información de cabecera relevante del paquete de Ethernet a un puerto saliente del aparato de conmutación de Ethernet.
Las figuras 6A, 6B, y 6C, colectivamente muestran esquemáticamente las versiones estándares de la trama de Ethernet conocidas actualmente por los expertos en la técnica, y la figura 7 muestra esquemáticamente cómo una trama de Ethernet de formato estándar se marca con un ¡dentificador de red de área local virtual (VLAN ID) y también la estructura de la etiqueta de VLAN ID. La figura 6A muestra el formato de trama de Ethernet V2.0, la figura 6B muestra el formato de trama de la Institute of Electrical & Electronic Engineers Standard Recommendation IEEE 802.3 con una cabecera de la Institute of Electrical & Electronic Engineers standard recommendation IEEE 802.2 LLC, y la trama de Ethernet mostrada en la figura 6C se conforma con la Institute of Electrical & Electronic Engineers standard recommendation 802.3 con variantes de LLC/SNAP. Sin embargo, el término "trama de Ethernet" referido adjunto no se limita a estas modalidades dadas pero refiere a cualquier tipo de formato de trama de Ethernet capaz de implementar la invención. En una red de Ethernet convencional, una trama de Ethernet básica sin activar tal como una de las mostradas en las figuras 6 A, B, C, consiste esencialmente en una dirección (SA) del control de acceso medio fuente (MAC) y una dirección (DA) de MAC destino, un campo tipo y datos que forman la carga útil del paquete de Ethernet. Una cabecera de etiqueta de VLAN estándar, por ejemplo, una cabecera de etiqueta de VLAN conforme a IEEE 802.1Q, se inserta entre el dirección de MAC fuente y el campo tipo como se muestra en la figura 7. El formato de tramas de Ethernet estándares es bien conocido a los expertos en la técnica, y una explicación completa de todos los campos y funcionalidad asociada, se omite aquí por claridad. Donde el tráfico se marca con una VLAN-ID, el aparato de conmutación de Ethernet 20 se configura al aparato de conmutación de cada paquete para así comunicarlo solamente a los puertos asociados con la misma VLAN en cada aparato de conmutación de Ethernet 20 en la red de comunicaciones 16. Para los aparatos de conmutación trafiquen entre diferentes VLANs, se proporciona la funcionalidad adicional (por ejemplo, la funcionalidad de envío de la dirección del Protocolo de Internet o cierta otra forma de funcionalidad del envío de la capa 3 de OSI) en el encendido o apagado del aparato de conmutación de Ethernet 20. Cualquiera de los campos relevantes en la cabecera de la trama de Ethernet, o individualmente o en combinación, por ejemplo, pueden utilizarse DA, SA, Ethertype, prioridad, VLAN-ID de la cabecera de VLAN. En una modalidad de la ¡nvención, el plano de control solamente busca en las direcciones de MAC e instala las redes virtuales múltiples basado en el Ethertype para ofrecer QoS múltiples. Esto da lugar a dos casos de un plano de control que existe lógicamente, es decir, se proporcionan dos redes virtuales, y el dominio del control puede diferenciar cada red virtual de acuerdo a algunas modalidades de la invención. De esta manera, un cliente de una red del portador que proporciona el servicio de Ethernet sobre la red central 16 puede proporcionarse con acceso a una de las redes virtuales para permitirle tener un grado de control dentro de la red central. El campo de VLAN-ID de 12-bits impone una limitación en donde solamente los clientes de 4096 VLAN son posibles en cualquier momento. La VLAN múltiple marca al mismo paquete de Ethernet para crear un apilado de VLAN ID que permite diferentes entidades para implementar la capa dos que se conmuta en diferentes niveles del apilado de VLAN-ID - esto es referido como Q-en-Q - y permite el marcado de VLAN jerárquico dentro de un paquete de Ethernet. La Figura 8 muestra esquemáticamente cómo Q-en-Q se implementa en una trama de Ethernet estándar, y la Figura 9 muestra esquemáticamente cómo MAC-en-MAC se ¡mplementa en una trama de Ethernet estándar como se conoce por los expertos en la técnica. El formato de trama que implementa estos esquemas ya se conoce por los expertos en la técnica, y así una descripción completa de todos los campos mostrados en las Figuras 8 y 9 y su funcionalidad asociada se omite en la presente por brevedad. Encapsulando la información del cliente, y proporcionando los esquemas de dirección jerárquicos tal como Q-en-Q y MAC-en-MAC (ver Figuras 8 y 9, que se describen antes), el plano de control es aislado del cliente en algunas modalidades de la invención. Puesto que el plano de control opera su propio esquema de dirección proporcionando una cabecera externa a la información de cabecera convencional en el aparato de conmutación de Ethernet fuente 20a, se mejora la seguridad a través de la red. Una modalidad de la invención implementa Q-en-Q en donde una etiqueta adicional se inserta en las tramas de Ethernet del cliente de manera bien conocida por los expertos en la técnica. En esta una modalidad, el aparato de conmutación de Ethernet 20 procesa cada trama de Ethernet recibida para reenviar datos a través de la red de Ethernet 16 basada solamente en la cabecera de VLAN externa de manera que la cabecera de VLAN interna (mostrada en la mitad superior de la Figura 8) se ignora. Alternativamente, el aparato de conmutación de Ethernet 20 puede examinar las cabeceras de VLAN externa e interna y tomar las decisiones de envío que se basan en las entradas del plano de control que se han proporcionado para ambas VLAN-IDs en la tabla de envío de VLAN-ID de cada aparato de conmutación de Ethernet 20. En una modalidad de la invención, un esquema de encapsulación de MAC-en-MAC es controlado por el plano de control 12. En esta modalidad, la fuente del cliente y direcciones de MAC destino se encapsulan dentro de los campos de dirección de MAC en el aparato de conmutación de Ethernet 20 del borde de red. Cuando se implementa la encapsulación de MAC-en-MAC, la trama del cliente se encapsula y no interactúa con el plano de control, en cambio el plano de control actúa en las cabeceras de MAC encapsuladas proporcionadas por el aparato de conmutación de Ethernet, permitiendo a las direcciones de MAC del cliente permanecer efectivamente invisibles sobre la red central de Ethernet 16. En la Figura 9 la trama del proveedor (P) se muestra adyacente a la trama del cliente. La trama del proveedor incluye campos tal como un campo de VLAN o MAC que son completamente independientes de la trama del cliente (que no podrán contener, por ejemplo, ninguna etiqueta de VLAN, o una VLAN-etiqueta o Q-en-Q). De este modo, la seguridad mejorada puede proporcionarse dentro del centro de la red de las direcciones MAC usadas son las proporcionadas por el portador cuyo esquema de dirección de MAC se utiliza, con la dirección de MAC del cliente solamente que se des-encapsula en el aparato de conmutación del borde de la red, si es requerido. La Figura 10A de los dibujos anexos muestra una modalidad de la invención en la cual se proporciona la Ethernet de conexión orientada. La figura 10A muestra un plano de control extremo a extremo 12, tal como puede proporcionarse, por ejemplo, utilizando la red óptica conmutada automática (ASON) para controlar una pluralidad del aparato de conmutación interconectado 20.
El plano de control instala las conexiones, llenando las tablas de transición en el aparato de conmutación de la manera descrita en la presente antes, puesto que los aparatos de conmutación de Ethernet tienen su aprendizaje de MAC desactivado, y así se desactiva el protocolo de árbol extendido, y así ningún BPDUs se proporciona. Se separan los flujos usando uno o más campos en la trama de Ethernet de acuerdo a la capacidad del aparato de conmutación, por ejemplo, etiquetas de VLAN, que permiten implementar el control del tráfico apropiado (por ejemplo, permitiendo balancear la carga de red). Las etiquetas de VLAN no se intercambian, y tienen solamente un significado local, que no asegura en práctica limitar la extensibilidad de la red. Esto permite que las conexiones múltiples se proporcionen entre el aparato de conmutación de Ethernet, tal como la figura 10B muestra. En la figura 10B, una primera trayectoria se muestra entre el aparato de conmutación A, B, C y E, y una segunda trayectoria se muestra entre el aparato de conmutación A, D y E. En el nodo A, el plano de control ha configurado los puertos salientes para reenviar el tráfico que se asocia con la VLAN ID 100 a lo largo de la primera trayectoria, y el tráfico que tiene la VLAN ID 120 se envía a lo largo de la segunda trayectoria. La modalidad de la ¡nvención mostrada en la Figura 10C proporciona una tecnología multiplexada multi-servicio. Esta modalidad permite una red del portador para implementar un multiplexado multi-servicio de Ethernet y otros servicios en el borde de la red utilizando tecnologías de conversión tal como GFP y ATM-Layer-Adaptation. El aparato de conmutación A recibe una trama de Ethernet del cliente, que se encapsula en el aparato de conmutación A (o en algún otro dispositivo de borde no mostrado en la Figura 10A) en una trama del proveedor de servicio. En algunas modalidades de la invención, la dirección asociada con el proveedor de servicio se agregó al cabecera de encapsulado. En otras modalidades, la información de dirección de la cabecera encapsulada continúa utilizándose para reenviar la trama encapsulada a través del aparato de conmutación 20. La figura 10C muestra una modalidad particular de la invención en la cual se muestra un servicio de paquete-en-ethernet para la red central, sin embargo, los expertos en la técnica apreciarán que los principios de cubrir una trama del cliente dentro de la trama de Ethernet de un portador pueden aplicarse para solicitar otras tecnologías. Mientras que la trama del cliente está sin tocar, se proporciona la transparencia. El portador está libre para utilizar su propio esquema de dirección (que proporciona el escalamiento, seguridad, aislamiento y detección de avería). En esta modalidad de la invención el portador OAM (especialmente gestión) el tráfico es distinguido del tráfico del cliente como las tramas OAM tienen solamente una sola cabecera (por ejemplo Y.17ethoam). En una modalidad, solamente el aparato de conmutación de Ethernet de borde entiende el espacio de dirección del cliente. Esto no es necesario sin embargo, si se proporciona el servicio punto-a-punto, en tal caso el aparato de conmutación de Ethernet 20 necesita solamente entender el espacio de dirección del proveedor. Como se muestra en las Figuras 10A a 10C, la red de Ethernet 16 proporcionada por la invención utiliza la dirección de fuente (SA) de Media Access Control (MAC) y la dirección de destino (DA) para proveer un servicio de paquete-ed de conexión orientada (CO-PS) de usuario final (en la red de capa de Ethernet alta), con campos de cabecera de VLAN se utilizan para definir las capas del servidor debajo que transporta la capa de CO-PS alta. Esto permite a un operador proveedor/red de servicio ofrecer un tipo de "línea dedicada" de servicio donde la capa de MAC del cliente y cualquier capa de VLAN alta se transportan transparente (ver, por ejemplo, la Figura 10C de los dibujos anexos). En una modalidad de la invención, el operador del proveedor/red de servicio puede agregar otra capa servidor del propietario para los servicios propietarios de implementación tal como ingeniería de tráfico etc. Los expertos en la técnica estarán enterados que G.8080 describe una arquitectura para el plano de control de una red de conexión orientada, y está implementa la funcionalidad de la conexión orientada del plano de control G.8080 donde un servicio de conexión orientada puede proporcionarse en el ambiente de red Ethernet sin conexión. El plano de control de conexión orientada G.8080 se utiliza para controlar la tecnología de Ethernet sin conexión y así convertir el comportamiento del aparato de conmutación de Ethernet. En una modalidad de la invención, un interfaz apropiada se proporciona conformada con G.8080 para separar los procesadores del plano de control de llamada/conexión (CPP) 36 y el aparato de conmutación de Ethernet 20, por ejemplo, cada aparato de conmutación de Ethernet 20 puede controlarse vía su interfaz en línea de comando del propietario existente (CLI) 32.
Sin mostrarse en estos dibujos está el fragmento o mediador que esta modalidad requiere cuyos comandos se traducen a través del CLI (es decir, que maneja los cambios a la interfaz de línea de comandos o al plano de control y se traducen entre el "lenguaje" usado de cualquier lado de la interfaz). La arquitectura G.8080 también permitida para el plano de control se integra en la plataforma del aparato de conmutación. Mientras que esto puede requerir modificaciones a la plataforma del aparato de conmutación agregando funcionalidad plana de control no hay necesidad de cambiar el hardware que proporciona la funcionalidad de envío de datos. En otra modalidad de la invención, una interfaz estandardizada entre el aparato de conmutación y el plano de control tal como el Generalised Switching apparatus Management Protocol (GSMP) se utiliza para implementar la funcionalidad del plano de control. Por ejemplo, GMPLS y protocolos de gestión de red o control similar o protocolos del plano de gestión pueden utilizarse para implementar la funcionalidad necesaria, por ejemplo, la eXtensible Mark-up Language (XML) o International Telecomunications Union (ITU) Telecomunications (ITU-T) Recomendation M.3100. OPERACIONES, ADMINISTRACIÓN Y MANTENIMIENTO Las operaciones, administración y mantenimiento u OAM es una parte fundamental de cualquier red del Service Providers. Esto es debido a que reduce el costo de servicios a través de permitir la supervisión remota y reparación del equipo y configuración a través de la detección y notificación de alarma. Asi las fallas se localizan rápidamente y resuelven rápido, conduciendo a una satisfacción de cliente incrementada. Una modalidad de la invención implementa la funcionalidad de OAM en una plataforma de software que es el interruptor apagado (es decir, en una plataforma diferente que proporciona el hardware separado para el tráfico de OAM al aparato de conmutación de Ethernet que procesa el hardware para el tráfico sin OAM). Esto permite la funcionalidad de OAM requerida por la invención para proporcionarse sin cualquier modificación directa de las modalidades de los aparatos de conmutación de Ethernet de acuerdo a la invención. Por otra parte, como los estándares que se proporcionan en este campo desarrollado, implementando el interruptor apagado del servicio OAM, por ejemplo, en una plataforma de software, es fácil adaptar las funciones OAM proporcionadas para conformarse con los protocolos estándares apropiados Actualmente, no existe ninguna OAM de Ethernet estándar y solamente existen las soluciones propietarias del vendedor Tres cuerpos estándares - IEEE, ITU-T y el Metro Ethernet Forum son estándares actualmente desarrollados para introducir OAM en segmentos Ethernet en el sentido de Ethernet que proporciona un servicio sin conexión Se desea que estos estándares se alineen con los disponibles para Frame-Relay y ATM e incluyen funcionalidad tal como el descubrimiento, chequeo continuo, realimentación, rastro de trayectoria, gestión de funcionamiento y supresión de alarmar Sin embargo, aunque Ethernet OAM en un ambiente de Ethernet sin conexión mejorará la capacidad del aislamiento de fallas de Ethernet, no proporciona el mismo nivel de información proporcionado en una red de conexión orientada como SDH y ATM Una modalidad de la invención implementa las funciones de OAM constantes con los requerimientos especificados en la International Telecommunications Union (ITU-T) Recommendation Y 1710, titulada "Requirements for Operation & Mamtenance functionality for MPLS networks" implementando una versión ligeramente modificada de la solución propuesta de la operación y mecanismo de mantenimiento en ITU-T Recommendation Y 1711 titulada "Operation & Maintenance mechanism for MPLS networks" Las modalidades de la invención que implementan Y.1710-co o OAM, implementan un sistema OAM en el cual la entidad más genérica en la arquitectura funcional de plano del usuario es una fuente (y/o fuente dividida subsiguiente a la fuente en el dominio de flujo) que difunde/multidifunde, y un receptor, (y/o fuente dividida antes del receptor en el dominio de flujo) que se filtran. El etiquetado en su sentido más genérico es esencial para esta entidad como la fuente y etiquetado de destino permiten que el receptor filtre una comunicación de fuente/destino única. Una subred y un dominio de flujo son ejemplos de esta entidad. Sin embargo, un vínculo es también un caso especial de esta entidad. En un vínculo, el etiquetado de destino explícito no se necesita pues hay solamente un destino. El etiquetado de fuente se requiere en orden para que el receptor sea desmultiple?ado. Además, un vínculo no une el tráfico, por definición. Como tal la fuente está en un control completo del multiplexado de un vínculo. Basado en esta entidad, la distinción entre nivelar y dividir es más sutil. Para implementar una subred o dominio de flujo es necesario crear un "servidor" asignado de etiquetas usando funciones de adaptación de una manera exactamente paralela a la de una capa de servidor que soportaba un vínculo. El dominio de difusión etiquetado con receptores de filtración es el fondo verdadero del apilado. En ITU-T Recommendation G 805 existen dos tipos posibles de flujo de OAM, el flujo de OAM de cola extremo a extremo y la conexión tándem intermedia que supervisa el flujo de OAM. En una unidad de datos del protocolo Ethernet (PDU), existen dos niveles de etiquetas (o capas) - la Ethernet de MAC Source Address (SA)/Destination Address (DA) y las capas de cabecera de VLAN (que pueden subdividirse adicionalmente si hay más subcapas) y así cuatro tipos de flujos de OAM se necesitan: Flujo de OAM de capa Trail MAC SA/DA (permite llamar este flujo de OAM tipo A); - Flujo de OAM de capa Tándem Connection Monitoring MAC SA/DA (flujo de OAM tipo B); Flujo de OAM de capa Trail VLAN (flujo de OAM tipo C); Flujo de OAM de capa TCM VLAN (OAM flujo D). En el flujo de OAM tipo A, la SA y DA en cada paquete son globalmente únicas y para que ninguna identificación del punto de acceso sea necesaria. Además cada trama tiene una FCS que puede utilizarse para la supervisión de funcionamiento. Los paquetes OAM explícitos pueden diseñarse, posiblemente usando una Ethertype ID, sin embargo, alternativamente, pueden utilizarse la IP y un número de puertos User Datagram Protocol (UDP). Todos los otros tres flujos tienen esencialmente la misma implementación básica. Las tramas de Ethernet son inyectadas por el procesador adjunto (CPP 36, 38) para el aparato de conmutación de borde de Ethernet relevante 20 (o central) y esto puede unirse al control de señalización que instala la conexión. En el extremo lejano, las tramas de OAM se separan del tráfico de plano del usuario y se conmutan en el procesador adjunto (CPP 36, 38) para procesamiento. Así para implementar los flujos de OAM anteriores, en primer lugar, el flujo de OAM debe tener los mismos valores en los campos de etiqueta como la conexión de plano del usuario de manera que cualquier aparato de conmutación intermedio de Ethernet conmute las tramas de OAM como si fueran tramas del usuario. Alternativamente, más de un valor de etiqueta por conexión puede proporcionarse pero esto no prueba necesariamente la exactitud e integridad de las tablas de señalización y envío de la misma manera. En segundo lugar, las tramas de OAM necesitan ser extraídas del plano de usuario y conmutarse en el aparato de conmutación de Ethernet de acuerdo a la funcionalidad estándar de un aparato de conmutación de Ethernet. Existen varias maneras de alcanzar estos dos requerimientos, sin embargo, la dirección de MAC de la interfaz del procesador adjunto (CPP 36, 38) originaria del flujo de OAM en el campo SA de la trama de OAM se utiliza en una modalidad preferida de la invención. FDI y AIS Como en cualquier red de CO-PS, el etiquetado del tributario no está cableado y así la inserción de las señales de indicación de alarmar (AIS) y/o detección e identificación de Falla (FDI) requiere del proceso de OAM buscando la tabla de etiqueta para encontrar cuales etiquetas son actuales y válidas. En esta modalidad de la invención, el proceso de OAM es realizado por un procesador adjunto (CPP 36, 38) localizado en el plano de control y no en el mismo hardware que el plano de usuario. La AIS y/o FDI ahora son indicadores adicionales para los flujos de extremo a extremo. Generalmente, la AIS y FDI se accionan de una falla detectada en la adaptación de una capa del servidor. No sustituyen el flujo de OAM extremo a extremo en la capa del cliente como el flujo y solamente este flujo puede supervisar la integridad de la conexión del cliente. La pérdida de la conexión del cliente se deduce cuando existe una pérdida correspondiente del flujo de OAM asociado. Si las señales de AIS y/o FDI se reciben además de la pérdida del flujo de OAM principal, entonces el receptor puede deducir que la falla no es local al receptor. Puesto que la AIS y/o FDI ahora son la información adicional de la información no esencial, la pérdida o corrupción de su inserción no es fatal y no se abre a la interpretación. La orientación de conexión significa que la "dirección y etiquetado" pueden desacoplarse entre sí, con el sistema de señalización utilizado para asociarlo. La invención trata la dirección de MAC como una "Etiqueta" que es solamente visible en el plano de control. En principio, cualquier esquema de direccionamiento podrá utilizarse como direccionamiento si solamente es visible al procesador adyacente del aparato de conmutación de Ethernet, es decir, solamente visible en el plano de control. Sin embargo, para dar compatibilidad con las redes sin conexión, el Protocolo de Internet versión 4 (IPv4) de direccionamiento podrá utilizarse o alternativamente, el Protocolo de Internet versión 6 (IPv6). Dado el uso extenso de la dirección privada, una dirección globalmente única se ha creado implícitamente en una de dos formas. La primera forma es la dirección de VPNid/IPv4 de la dirección global implícita usada en las redes privadas virtuales (VPNs) de Protocolo de Internet (IP). La segunda forma de una dirección global única es una dirección Network Address Transport (NAT). Esta dirección única global es implícitamente formada como el encadenamiento de la dirección de IPv4 pública de la entrada seguido por la dirección IPv4 privada. Las alternativas tal como la dirección Network Service Access Point NSAP, la dirección E.164 o cualquier formato de dirección única globalmente aplicable podrán también utilizarse en las modalidades alternativas de la invención. Es posible utilizar formas humanas de dirección tal como las basadas en la ubicación geográfica y/o física de la interfaz del aparato de conmutación, así como es bien conocido por los expertos en la técnica para implementar operaciones de red. SEÑALIZACIÓN La señalización enviada por el plano de control 12 al plano de datos 14 se conforma con uno de los protocolos de señalización estándares actuales de acuerdo a una modalidad de la invención. Por ejemplo, los protocolos tal como la interfaz del nodo de red privado (PNNI) como se define por el foro de ATM, un Resource Reservation Protocol (RSVP) u otro protocolo que proporciona un mecanismo de señalización para aplicaciones para solicitar y recibir un servicio preferencial a través de la red, por ejemplo, (RSVP-TE), el protocolo Generalised Multi-Protocol Label Switching (GMPLS) tal como se define por RFC 3473, el protocolo Multi-Protocol Label Switching (MPLS) como se define por RFC 3209, el protocolo de distribución de etiqueta que dirige la restricción basada (CR-LDP) tal como se define en ITU-T G.7713.3, o un protocolo ITU-Q-serie SS7 o cualquier protocolo que tiene la funcionalidad necesaria podrá utilizarse con las extensiones simples que permiten los parámetros específicos al transporte Ethernet. En otras modalidades de la invención, otro tipo de arquitectura del plano de control se implementa el cual proporciona funcionalidad similar a la de G.8080 (completamente o como un subconjunto o variantes especializadas). Por ejemplo, el protocolo de GMPLS como se define de RFC 3945 recomendación estándar por la Internet Engineering Task Forcé (IETF) puede utilizarse en modo cubierto. En aún otra modalidad de la invención, los protocolos de gestión de red se utilizan para proporcionar información de enrutamiento para el plano de control e indicaciones que definen los retrocesos para OAM entre el plano de control 12 y el aparato de conmutación de Ethernet 20. En esta modalidad, los mensajes de señalización se envían en una red separada a la red de comunicaciones Ethernet 16. Por ejemplo, en modalidades en donde los componentes del plano de control 36 están separados del aparato de conmutación de Ethernet 20, una red de comunicaciones de datos de gestión separada puede utilizarse para proporcionar la señalización. Alternativamente, la señalización del plano de control puede proporcionarse con el tráfico de Ethernet en el sentido de compartir el mismo vínculo físico pero se proporciona en una red fuera de banda. El objetivo de una red fuera de banda (OOB) es para efectivamente proporcionar una red segura para la información de control tal que la información de control es aislada lógicamente de la trayectoria del tráfico con el cual la información de control se relaciona. Así la información de control para conmutar el tráfico de la red de área local sobre la red Ethernet central se lleva usando una red OOB (es decir, una red lógicamente diferente) sobre la red central tal que solamente un portador (es decir, operador de red para la red central) puede tener acceso al plano de control y, si se requiere, interrumpe la operación del plano de control. El cliente de la red de área local (es decir, la red del cliente) no tiene ningún control sobre el plano de control. En esta modalidad, es posible asociar la información de señalización a una VLAN, así dentro de la VLAN un canal de señalización se asocia con todos los aparatos de conmutación de Ethernet. Esto puede también utilizarse (u otra VLAN para el tráfico de OAM de dirección de retroceso, particularmente para el tráfico unidireccional). Los protocolos de enrutamiento a menudo se asocian con cualquiera o el protocolo de señalización o el esquema de direccionamiento. No hay necesidad a priori de un protocolo de enrutamiento ya que es posible con un servicio de conexión orientada-enrutamiento estático. El enrutamiento puede basarse en esquemas basados paso por paso, jerárquicos de domino o fuente. La información de enrutamiento proporcionada por el plano de control puede distribuirse usando protocolos basados en IP tal como el protocolo Open Shortest Path First Traffic Engineering (OSPF-TE), o de una manera constante con la arquitectura de ASON. En una modalidad de la invención, se proporciona la información de enrutamiento estático. En las modalidades alternativas de la invención, sin embargo, el enrutamiento dinámico se implementa usando un protocolo de enrutamiento dinámico apropiado tal como se conoce por los expertos en la técnica. En una modalidad de la invención un administrador de red manualmente configura las rutas de red. Si se utiliza el enrutamiento dinámico, se utilizan algoritmos de enrutamiento para llenar automáticamente las tablas de enrutamiento en el plano de control y el protocolo de señalización lee las entradas de la tabla de enrutamiento y llena las entradas de la tabla de envío del aparato de conmutación de Ethernet. Todavía es posible para algunas trayectorias ser configuradas explícitamente vía el plano de control en un ambiente de enrutamiento dinámico). El enrutamiento estático y dinámico puede ¡mplementarse usando cualquiera plano de control distribuido (ver Figura 4) o el plano de control centralizado (ver Figura 11) de las modalidades de la invención. En una modalidad de la invención, un administrador de red (u operador) manualmente incorpora la información de enrutamiento de la conexión orientada en el plano de control que es exportada por el sistema de señalización vía la interfaz de línea de comandos para llenar la tabla de datos reenviados proporcionada en el aparato de conmutación de Ethernet. La información es mediada por un fragmento apropiado (no mostrado) que traduce la información proporcionada en la forma apropiada para actualizar las entradas de la tabla de envío del aparato de conmutación de Ethernet. Como un ejemplo, ahora se considera brevemente la modalidad de la ¡nvención mostrada en las Figuras 3 y 4. En esta modalidad, la información de enrutamiento es proporcionada por un plano de control ¡mplementado como una pluralidad de procesadores, cada procesador del plano de control 34 proporciona la entrada a un solo aparato de conmutación de Ethernet, que puede ser vía una interfaz de línea de comandos 32 (mostrada en la Figura 3). Esta información puede proporcionarse usando o en un protocolo de control del aparato de conmutación apropiado o explícitamente vía la interfaz de línea de comandos proporcionada para cada aparato de conmutación de Ethernet 20 en la red de comunicaciones 16. En una modalidad de la invención, la OAM puede combinarse con el enrutamiento para que el plano de control pueda automáticamente descubrir la interconectividad del aparato de conmutación de Ethernet y utilizar esta información para construir y mantener la información de enrutamiento dentro del plano de control. Estos mensajes 'hola', como son llamados por los expertos en la técnica efectivamente reúnen la OAM con el enrutamiento para que el plano de control tenga la mayor imagen de datos de la red. COMUNICACIONES DEL PLANO DE CONTROL EXTREMO A EXTREMO La Figura 11 muestra una arquitectura del plano de control la cual se ordena para que una funcionalidad del plano de control centralizado (mostrada esquemáticamente por CPP 38 y espera CPP 40 (que son redundantes pero proporcionan resistencia en caso de que falle la CPP 38) proporcione una red de comunicaciones del plano de control extremo a extremo. En esta modalidad de la invención, cada componente 38, 40 del plano de control proporciona la funcionalidad del plano de control para más de un aparato de conmutación de Ethernet 20.
La Figura 11 muestra un plano de control que comprende un procesador del plano de control de señal 38 que se ordena para funcionar como un regulador de llamada y conexión para todos los aparatos de conmutación de Ethernet 20 del plano de datos 14. En práctica, el índice de llamada y reguladores de conexión 38 a los aparatos de conmutación de Ethernet 20 pueden seleccionarse por ser cualquier relación apropiada (así como se conoce por los expertos en la técnica). Así el procesador CPP (M) para la relación del aparato de conmutación de Ethernet (N) es M: N donde M < N varía de acuerdo a cómo se centralizó o distribuyó la funcionalidad del plano de control según se requiera. La implementación de un plano de control centralizado para proporcionar una red de comunicaciones extremo a extremo en esta modalidad funciona de una manera equivalente a las modalidades de la invención mostrada en las Figuras 3 y 4, aparte de la funcionalidad de los procesadores del plano de control ahora se centralizan a un grado mayor o menor. Las características descritas en la presente antes con referencia a las modalidades del plano de control distribuido también se considera para describirse en el contexto de un plano de control centralizado cuya funcionalidad es ¡mplementada por uno o más componentes del plano de control, cada uno de los cuales se asocia con más de un aparato de conmutación de Ethernet del plano de datos - en otras palabras, la relación del plano de control que procesa los componentes al aparato de conmutación de Ethernet puede variar, como la fuerza del nivel de la redundancia construida en el plano de control. Por ejemplo, en la modalidad de la invención mostrada en la Figura 11, solamente un procesador del plano de control CPP 40 se ordena para proporcionar un servicio del plano de control de espera para incrementar la resistencia del plano de control en caso de que ocurra una falla de señalización (por ejemplo, entre cualquiera de los aparatos de conmutación de Ethernet 20 y el procesador del plano de control central 38 mostrados en la Figura 11), pero en las modalidades alternativas más de un procesador del plano de control en espera 40 puede proporcionarse en el plano de control.
Describiendo la Figura 11 ahora más detalladamente, en la red central de Ethernet 16', el CPP centralizado 38 funciona como un procesador adjunto para cada uno de los aparatos de conmutación de Ethernet 20 A, B, C, D, E, y F mostrados en la red 14 del plano de datos. Una sola lista de espera de CPP 40 también se proporciona para todos los aparatos de conmutación 20 en la red de comunicaciones del plano de datos 14. En la modalidad mostrada en la Figura 11, CCP 38 determina la ruta de cada petición de conexión y envía los mensajes de señalización apropiados para llenar las entradas de la tabla de envío de datos de cada uno de los aparatos de conmutación de Ethernet 20 (por ejemplo, usando un CLI). CPP 38 contiene un modelo apropiado de red, por ejemplo, una base de datos de los recursos de la red tales como aparatos de conmutación, vínculos, topología y conexiones, que CPP 38 utiliza para activar las peticiones por servicio. El plano de control se puede implementar usando CPPs que tienen cualquier relación apropiada tal como una jerarquía global o una pluralidad de jerarquías locales, interconectada en los niveles específicos para formar grupos de procesadores del plano de control. La figura 12 muestra una modalidad de la invención en la cual CPPs "0", "A", "B", y "C" se ordenan para interactuar de forma jerárquica con el CPP "0" que proporciona un control igual sobre cada uno de los dominios localizados de CPPs "A, B, C" de responsabilidad. Cualquier red de comunicaciones conveniente se puede utilizar por el CPPs que forma el plano de control para transportar mensajes apropiados de control a cada aparato de conmutación de Ethernet en la red de aparatos de conmutación de Ethernet para llenar sus tablas de envío de datos apropiadamente, aunque en un cierto punto la información de control de enrutamiento (que se conserva en el plano de control) se convierte en una forma conveniente para llenar las entradas de la tabla de envío de datos del aparato de conmutación de Ethernet. Como se ha discutido antes en el contexto de las modalidades del plano de control distribuido, cualquier protocolo conveniente capaz de transportar la información de control al aparato de conmutación de Ethernet puede utilizarse, por ejemplo, un protocolo del manejo o del plano de control de redes podría utilizarse. El protocolo del plano de control puede ser propietario, basado en los protocolos de manejo o basado alternativamente en protocolos de control estándares tales como GMPLS, ASON- RSUP-TE, CR-LDP, PNNI, SS7, etc., como se describe en la presente antes, al proporcionarlos se adaptan como sea evidente a cualquier experto en la técnica para los parámetros específicos de Ethernet requeridos por la invención. Los expertos en la técnica estarán por enterados que si un cambio se realiza a la interfaz de línea de comando (CLI) de un aparato de conmutación de Ethernet, las partes del software del aparato de conmutación entre el plano de control y el CLI necesitarán actualizarse. Esto requiere que el software se actualice y una red de comunicaciones separada se requiere para el plano de control se comunique con el aparato de conmutación. En una modalidad de la invención, hacer frente a los cambios de CLI y proporcionar una red de comunicaciones apropiada para que el plano de control 12 se comunique con el aparato de conmutación de Ethernet 20, el CLI 32 se sustituye por una interfaz basada en los estándares para el plano de control 12 (por ejemplo, GSMP - el protocolo del manejo general del aparato de conmutación se puede utilizar). GSMP proporciona un protocolo amo-esclavo en el cual el aparato de conmutación 20 funciona como un esclavo para un amo que comprende cualquier plataforma apropiada, por ejemplo, una computadora tal como una computadora personal. GSMP permite al amo instalar y desmontar las conexiones de Ethernet a través del aparato de conmutación 20, para realizar las tareas del manejo, solicitar información o permitir que el aparato de conmutación informe al amo de cualquier problema. En una modalidad de la invención, el amo se configura para controlar el plano de control 12 por sí mismo y cómo el GSMP opera para permitir el manejo y adyacencia de la conexión. Sin importar si CLI o GSMP (o su equivalente funcional) es utilizado, en una modalidad de la invención, algo o todo el tráfico del plano de control sigue al tráfico del transporte comúnmente en la misma infraestructura. En algunas modalidades de la invención, se muestra una VLAN en la cual el plano de control se crea entre los aparatos de conmutación 20. El plano de control de VLAN, se aisla lógicamente del tráfico de transporte y lleva el tráfico del plano de control entre los aparatos de conmutación de Ethernet 20. Cada CPP 36 en una red del plano de control distribuido 16 puede comunicarse con el otro CPPs 36 en la red usando la Ethernet como la red de comunicaciones para la información de señalización del plano de control. Esta información es pasada a la VLAN relevante por un puerto apropiadamente configurado del aparato de conmutación de Ethernet relevante 20. En la figura 13, tres aparatos de conmutación de Ethernet A, B, y C, se muestran, cada uno con un CPP asociado. La Figura 13 muestra cómo en una modalidad de la invención, cada CPP está conectado al aparato de conmutación de Ethernet vía una interfaz de línea de comando apropiada (CLI) (mostrada por "x" en la figura 13). En este ejemplo, no hay cambio en el aparato de conmutación de Ethernet. También se muestra en la figura 13 otra interfaz "y", que comprende una interfaz de GSMP en una modalidad de la invención (en modalidades alternativas un protocolo similar se puede utilizar para controlar remotamente el aparato de conmutación). Sin embargo, si un interfaz del protocolo de manejo del aparato de conmutación se utiliza para controlar remotamente el aparato de conmutación, entonces el software del aparato de conmutación necesitará ser modificado para comunicarse con el CPP, por ejemplo, una parte u otro mediador puede requerirse. La trama 14 muestra una modalidad alternativa de la invención, en la cual los CPPs están conectados en una topología diferente. En esta modalidad, es posible que diferentes CPPs se comuniquen con diferentes redes de comunicaciones. En este caso, la VLAN(s) usada para transportar los mensajes de control entre los CPPs y el aparato de conmutación de Ethernet, es instalada por el operador de la red de manera que sea posible distinguir cada VLANs de control. Por ejemplo, algunas modalidades de la invención tienen diferentes funciones del plano de control implementadas en diferentes VLANS. De este modo es posible proporcionar el control de Ethernet lógicamente fuera de banda. Los expertos en la técnica también apreciarán que una VLAN se pueda también utilizar para otros propósitos, por ejemplo, transportar operaciones y paquetes de mantenimiento (OAM). La figura 14 muestra al caso donde los aparatos de conmutación de Ethernet y CPP tienen una topología común, en cuyo caso la funcionalidad del plano de control se puede integrar en cada aparato de conmutación de Ethernet. APARATO DE CONMUTACIÓN DE ETHERNET DE MODO DUAL En otra modalidad de la invención, un aparato híbrido de conmutación de Ethernet se configura para proporcionar un servicio sin conexión y un servicio de conexión orientada. El aparato híbrido de conmutación de Ethernet proporciona cierta funcionalidad sin conexión y la funcionalidad de conexión orientada es proporcionada por el plano de control 12 que proporciona la información de enrutamiento que llena la tabla de envío de datos solamente para los puertos en los aparatos híbridos de conmutación de Ethernet que deben proporcionar un servicio de conexión orientada. En esta modalidad, el plano de datos de envío/filtración conservará su funcionalidad sin conexión para los puertos señalados porque proporcionan un servicio sin conexión. Las entradas de las tablas de envío de datos se actualizan con la información derivada del plano de control solamente para los puertos asociados con un servicio de conexión orientada y los puertos restantes continúan proporcionando un servicio sin conexión de Ethernet. Un algoritmo apropiado del árbol extendido asegura que existan trayectorias no redundantes al eliminar las trayectorias redundantes en las entradas de la tabla de enrutamiento asociadas a los puertos de cada aparato de conmutación de Ethernet colocado para proporcionar un servicio sin conexión de Ethernet. Mientras que es posible implementar un aparato híbrido de conmutación que ofrece Ethernet sin conexión y con conexión orientada, el uso del protocolo del árbol extendido es susceptible a la mala-operación inadvertida o ataque deliberado. Esto significa que el uso de un STP representa un punto operacional de vulnerabilidad en una red de comunicaciones. Encapsulando la funcionalidad del árbol extendido del cliente usando el MAC en MAC, y eliminando toda la funcionalidad de STP de la red central de Ethernet, la vulnerabilidad de la red central a la mala-operación de STP o al ataque, es reducida de manera significativa. El uso de MAC-en-MAC sobre la red central de Ethernet no evita que una red de área local implemente un STP dentro de ese dominio. Así modalidades de la invención que utilizan la encapsulación sobre la red central aumentan la seguridad del tráfico en el dominio. RECONFIGURACION DEL APARATO DE CONMUTACIÓN DE CAPA 3 Refiriéndose ahora a las figuras 15 a 21 de los dibujos anexos, el aparato de conmutación de la invención abarca el aparato de conmutación previsto originalmente para ser capaz de soportar el enrutamiento sin conexión de capa 3 de la Open Systems Interconnection (OSI). La capa 3 de la Open Systems Interconnection (OSI) (también conocida como la capa de red), es la primera capa que maneja el tráfico extremo a extremo y tiene trato con la significación extremo a extremo. Los ejemplos de protocolos de capa 3 incluyen el Protocolo de Internet (IP, por sus siglas en inglés), y el Internet Packet Exchange (IPX). En general, sin embargo, la capa 3 describe las funciones de dirección, enrutamiento, y filtración requeridas para asegurar la conectividad entre los sistemas finales (computadoras), así como definir el formato de los paquetes que hacen uso de las tramas proporcionadas por la capa 2. El término "IP" se utiliza en la presente para referir a la versión 4 de IP y a la versión 6 de IP. En los ejemplos siguientes, por lo tanto el aparato de conmutación de acuerdo a la invención incluye enrutadores de IP colocados originalmente para soportar el enrutamiento sin conexión del tráfico de la versión 4 o de la versión 6 del Protocolo de Internet. La invención permite a tales enrutadores poder proporcionar un servicio de conexión orientada en lugar de, o además de, un servicio sin conexión y el servicio de conexión orientada puede en algunas modalidades proporcionar un enrutamiento multidireccional. En general, por lo tanto, el aparato de conmutación del término se define para abarcar todo aparato de enrutamiento capaz de funcionar como un aparato del envío y capaz de resolver las direcciones de OSI-capa 3 (capa de red), por ejemplo, un Enrutador de IP capaz de resolver las direcciones de IP de OSI-capa 3 (capa de red). Todos los términos usados en la presente conservan las definiciones dadas en la International Telecommunication Union (ITU)1S ITU-T Recommendation G.805 "Generic functional architecture of transport networks", cuyo contenido es incorporado en la presente por referencia, a menos que se indique explícitamente con un significado diferente que sea contrario con el significado dado en G.805. APARATO DE CONMUTACIÓN DEL PROTOCOLO DE INTERNET Una modalidad de la invención suministra un servicio conmutado de paquete de conexión orientada que utiliza un enrutador estándar de IP como su hardware nodal. Toda señalización y OAM necesitados para la conmutación de paquete de conexión orientada se implementa en una plataforma de procesamiento separada (por ejemplo, una plataforma del servidor de UNIX). Idealmente, el enrutador de IP por sí mismo está sin modificar, y como tal estará disponible "a la mano" de cualquier proveedor estándar. El tipo de servicio proporcionado por la invención es una conmutación de paquete de conexión orientada (CO-PS) en el sentido que proporciona un transporte transparente a través de la red central de IP, y es capaz de proporcionar un servicio punto a punto o punto-a-múltiples puntos. Esto no imposibilita el uso de apremios de múltiples puntos-a-punto y de múltiples puntos-a-múltiples puntos como parte de la entrega de un servicio transparente extremo a extremo. Como tal, un servicio punto a punto puede a su vez ser un servicio unidireccional de punto-a-punto o de punto-a-múltiples puntos o un servicio bidireccional.
Para ser conmutable en el enrutador de IP, la unidad de datos de protocolo (PDU) debe ser constante con el formato del paquete de IP, es decir, sea una PDU estándar de IP La figura 15 muestra una red de comunicaciones de capa-3 50 que comprende una pluralidad de aparatos 62 de conmutación de capa-3 establecidos para soportar los modos sin conexión de comunicación. En la red de comunicaciones 50, la funcionalidad de red es proporcionada por un plano administrador 52, un plano de control 54 y un plano de datos/envío 56 de una manera equivalente para el tráfico de capa 3 de OSI tal como se describe anteriormente para el tráfico de comunicaciones del tipo de capa-2 OSI. Los conceptos asociados con el plano de control llenan las tablas de enrutamiento del aparato de conmutación y asocian las consideraciones de VLAN y OAM de las modalidades descritas en la presente anteriormente en el contexto de que el equipo de comunicaciones sin conexión de Ethernet sea adaptable en lugar de soportar la provisión de un servicio de conexión orientada usando el equipo de comunicaciones de IP (incluyendo el equipo de comunicaciones de IP preestablecido en la red para propósitos de proporcionar un servicio sin conexión). En la figura 15, el plano administrador 52 proporciona las interfaces apropiadas para configurar, controlar y administrar una red 50 de IP. El plano de control 54 proporciona las interfaces lógicas y físicas para instalar y controlar las actividades del plano de datos/envío 56 de IP vía la interfaz de línea de comando o por cualquier otra manera apropiada conocida por los expertos en la técnica, por ejemplo, de acuerdo a lo especificado en uno de los estándares de IETF, por ejemplo, GMPLS. El plano de control 54 realiza las funciones de control de llamada y de control de conexión, y utiliza la señalización para instalar y suministrar las conexiones y restaurar las conexiones en el caso de falla. El plano de envío de datos 56 proporciona la funcionalidad de filtración y envío usada para transportar el tráfico de datos de la red. En la figura 15, una red de comunicaciones 50 abarca una primera red 60a de hospedadores locales, por ejemplo una LAN del cliente, que es capaz de conectarse a una segunda red 60d de hospedadores locales, por ejemplo otra LAN del cliente, vía una pluralidad de enrutadores interconectadas 62 de IP. Un número ejemplar (por claridad, solamente cuatro) de enrutadores 20 de IP se muestra en la figura 15 (etiquetados A, B, C, y D). En la figura 15, la red de área local 60a proporciona una fuente 64 del tráfico (por ejemplo tráfico de IP) que se transmite vía un dispositivo de borde conveniente 66 (por ejemplo, un enrutador que proporciona cierta funcionalidad de multiplexación) al enrutador A. Alternativamente, el dispositivo de borde 66 puede encapsular un diferente tipo de protocolo de tráfico en el tráfico de IP conveniente para enrutar sobre la red central vía el plano de datos 56. La red 60d de acuerdo a lo mostrado en la figura 2 funciona como el receptor del tráfico de IP 68, y recibe el tráfico de IP desde el enrutador D de IP vía un dispositivo apropiado 70 (por ejemplo, un enrutador que proporciona una función de des-multiplexación). Una vez más, el dispositivo de borde 708 puede des-encapsular el tráfico si es requerido. Por otra parte, una red local puede, funcionar sin embargo, en la práctica como una fuente y un receptor del tráfico de IP, al igual que bien conocido por los expertos en la técnica. Para que los enrutadores de IP 62 funcionen correctamente como un enrutador de conexión orientada de IP, los protocolos de enrutamiento pre-configurados se deben desactivar o configurar tal que todas las entradas de la tabla de envío llenas por los protocolos de enrutamiento sean de una prioridad más baja a las del servicio de conexión orientada. En cambio, se llenan las entradas de la tabla de envío asociadas a todo el servicio de conexión orientada usando la información proporcionada por el plano de control vía un CLI o por cualquier otro medio conocido por los expertos en la técnica. Para proporcionar una conexión de extremo a extremo, cada enrutador (o aparato de conmutación equivalente) A, B, C, D es llenado con las entradas de la tabla de envío apropiadas para la conexión extremo a extremo por el plano de control. Esto es posible ya que la información de cabecera de enrutamiento de IP es la misma en cada enrutador 62 de IP. En la figura 15, la funcionalidad de envío de datos de IP para el tráfico de conexión orientada en cada aparato 62 de conmutación de IP proporcionado en el plano de datos 56, es controlada desde el plano de control 54 usando la interfaz de línea de comando 74a, b, c, d asociada con cada enrutador 62 de IP. En la modalidad de la invención mostrada en la figura 15, la información de enrutamiento para las tablas de envío del aparato A de conmutación de IP, se genera en el plano administrador 52 y se comunica con el enrutador 62 vía el plano de control 54. Como ejemplo, la información de enrutamiento se puede generar por un administrador de red 72 y por la señalización al aparato de conmutación usando una interfaz de línea de comando apropiada (CLI) 74a. La información de enrutamiento se proporciona similarmente vía CLIs 74 b, c, d para llenar las tablas de envío de cada uno de los enrutadores 62 de IP B, C, y D. Otra funcionalidad se puede implementar en los enrutadores de IP, por ejemplo, tal como un rastreador de paquete 34 en los aparatos de conmutación de IP D. La red de comunicaciones del plano de control extremo a extremo desactiva y configura las funcionalidades de la tabla de enrutamiento de cada enrutador de IP 20 en la red que ofrece un servicio de conexión orientada (por desactivar las funcionalidades o por bajar su prioridad a un nivel apropiado, por ejemplo asegurar que no se implementen en práctica). En la modalidad preferida de la invención, el enrutador de IP 62 ofrece solamente un servicio de conexión orientada y el enrutamiento sin conexión es completamente desactivado, pero alternativamente, un aparato de conmutación híbrido puede proporcionarse (ver a continuación). Una vez que los protocolos de enrutamiento se hayan desactivado de acuerdo a lo descrito anteriormente, por ejemplo, por el plano de control, el plano de control crea y proporciona la información de enrutamiento necesaria para llenar las tablas de envío de IP basado en la dirección de IP y puerto y cualquier otra entrada de la tabla del campo de cabecera. El enrutador de IP entonces utiliza esta información para establecer las conexiones apropiadas del vínculo de IP (mostradas por las flechas negras gruesas en la figura 15) entre los mismos enrutadores de IP 62a, b, c, d. Es posible que los enrutadores de IP soporten las conexiones de vínculo unidireccionales y/o bidireccionales (y proporcionar así un servicio dúplex completo, al igual bien conocido a los expertos en la técnica). Cada enrutador de IP 62 implementa el envío de datos basado en la cabecera exterior de IP en cada paquete del tráfico de IP recibido al realizar una operación de búsqueda en la dirección de IP en su tabla de envío. Debido a que la tabla de envío ahora es llenada por la información derivada desde el plano de control del aparato de conmutación, los datos serán remitidos de tal manera que se proporciona un servicio de conexión orientada. Cuando el esquema de dirección usado para el servicio orientado de conexión es igual que el usado por la red IP, entonces el plano de control puede utilizar esta dirección directamente, usando las tablas de ruta de los planos de control para que trabaje el puerto saliente en cada enrutador IP. Éste entonces se configura en el enrutador IP como una entrada estática en la tabla de envío del enrutador IP según lo entendido por los expertos en la técnica. Cuando el esquema de dirección usado para el servicio orientado de conexión es diferente al usado por la red IP, entonces el control debe primero realizar una búsqueda de traducción del directorio para encontrar la dirección IP correcta para el punto final de la conexión. El plano de control entonces puede utilizar ésta dirección IP junto con éstas tablas de ruta para hacer las entradas estáticas en las tablas de envío de los enrutadores IP. En la modalidad preferida de la invención donde el tráfico de conexión orientado es el único tráfico soportado por el enrutador IP, entonces las entradas estáticas en las tablas de envío de los enrutadores IP son las únicas entradas que son válidas para el tráfico del usuario final. Esto proporciona un alto grado de seguridad ya que el único tráfico del usuario final en el tráfico, es el tráfico que se ha admitido explícitamente para la red. En una modalidad alternativa de la invención donde el tráfico de conexión orientada se mezcla con el tráfico sin conexión en el mismo enrutador IP. En esta modalidad el tráfico de conexión orientada se puede distinguir del tráfico sin conexión haciendo que las entradas estáticas en la tabla de envío tengan una prioridad superior más alta que las entradas para el tráfico sin conexión. Se pueden hacer otras distinciones entre el tráfico para soportar la calidad de las propiedades de servicio del servicio de conexión orientada, por ejemplo, haciendo que los paquetes orientados a la conexión tengan una prioridad más alta en los búfers de cola. Más allá de la simple organización por prioridad, muchas de las técnicas desarrolladas para la gestión del tráfico IP y conocidas por los expertos en la técnica, están disponibles para distinguir el tráfico de conexión orientada del tráfico sin conexión y para ofrecer una QoS de. conexión orientada normal para el tráfico de conexión orientada. El control de aparato de conmutación proporcionado por el plano de control 54, implementa las funciones de control (o un subconjunto apropiado) identificadas y descritas en la Telecommunication Union ITU-T Recommendation G.8080, con el título Architecture of the automatically switched optical network (ASON), cuyo contenido se incorpora en la presente por referencia. Las modalidades preferidas de la invención implementan un plano de control de una manera constante con G.8080 que permite el concepto de una conexión y una llamada, la separación de control y el plano del usuario, y la separación del control de llamada y del control de conexión. Alternativamente, se podrían utilizar GMPLS, MPLS, o un plano de control PSTN de legado, o un sistema de gestión de red. El plano de control tiene una visibilidad en la red IP, reconoce qué los recursos están libres. Una vez que se ha señalado una trayectoria de A á D, el plano de control necesita conocer en D qué recursos están disponibles para establecer la conexión, es decir, para determinar qué recursos están libres, por ejemplo, si en la versión IP 6 está libre un identificador de flujo, el plano de control informa a todos los aparatos de conmutación vía los CPPs el uso del identificador de flujo libre. Cuando una petición es recibida por un CPP, el CPP procesa la petición para determinar de que manera hablar al CPP en el extremo remoto del plano de control (es decir, el CPP para el aparato de conmutación IP en el cual el tráfico deja la red central IP), y a todos los CPPs intermedios. La petición puede proporcionar una ruta específica o identifica los puntos finales, y puede requerir que el CPP encuentre una ruta. Los expertos en la técnica reconocen que una petición para la conexión se puede recibir mediante un procesador del plano de control vía un enrutador IP, para lo cual el CPP controla la funcionalidad de envío de datos, sin embargo, el enrutador IP funcionara sin procesamiento cuando reenvíe la petición de conexión al CPP (es decir, el CPP no controla la manera en la cual el enrutador IP reenvía las peticiones de conexión recibidas al plano de control). Refiriéndose ahora brevemente a la figura 21, el plano de control puede comprender una pluralidad de procesadores del plano de control adjuntos interconectados (CPP) 78 o se puede implementar de una manera centralizada (en cuyo caso la correlación entre los procesadores del plano de control y el aparato de conmutación puede diferir de 1:1 y donde se proporciona una pluralidad de procesadores del plano de control, son posibles las relaciones del proceso de control jerárquicas complejas). Similarmente, la redundancia se puede proporcionar al tener uno o más CPP de reserva cuyos recursos se utilizan solamente en el caso de que otro CPP falle. Para la simplicidad, a menos que haya una necesidad de distinguir entre los componentes diferentes, las características serán referidas como el enrutador 62, red de área local 60, en lugar del enrutador 62a, b, c, d, etc. y red 60a, b, etc. Cada enrutador IP 62 en la red de comunicaciones 50 se conecta a dos o más redes locales 60 que comprenden anfitriones locales interconectados (por ejemplo, una LAN del cliente), aunque solamente se muestran en la figura 15 las LANs 60a y 60b. El plano de control 54 conserva la información de enrutamiento, que se utiliza para llenar las tablas de envío de datos proporcionadas en el plano de envío de datos con la información de envío de datos. La información de enrutamiento se proporciona para cada enrutador IP 62 vía su interfaz en línea de comando (CLI) respectiva 74 (mostrada en la figura 15 como una barra en la línea discontinua que conecta el plano de control y el aparato de conmutación IP asociado 62). No se muestra en la figura 15 la configuración del plano de control, que se puede distribuir o centralizar dependiendo de la relación de los procesadores del plano de control 78 con los enrutadores IP 62. En un plano de control completamente distribuido (tal como se muestra por ejemplo en las figuras 20 y 21), se controla cada CPP 78 configurado en la correspondencia uno a uno con el enrutador IP 62. La información se intercambia entre los CPPs 78 por medio de una red de señalización apropiada (ver por ejemplo las figuras 20, 21). Estos procesadores adjuntos 78 generan la información que controla de que manera se actualiza la tabla de envío de datos de las enrutadores IP 62, y también previene que se dañen las tramas de las direcciones IP, o en el caso de la versión IP 6 previene el flujo de los ¡dentificadores que no son reconocidos por la información de señalización proporcionada del paso a través del aparato de conmutación vía los puertos que ofrecen el servicio de conexión orientada. Aparte de que ahora es capaz de ofrecer un servicio de conexión orientada, la funcionalidad restante de los enrutadores IP 62 está sin cambios, puesto que el cambio en el comportamiento del aparato de conmutación necesario para proporcionar el servicio de conexión orientada es simplemente un resultado de cambiar las entradas de la tabla de envío para proporcionar tal servicio. Las multi-trayectorias para las modalidades de la invención en las cuales se proporciona un modo de transporte IP de conexión orientada, se pueden establecer de una manera análoga a la mostrada esquemáticamente en la figura 4 para Ethernet. Así en la figura 15, dos trayectorias se pueden establecer entre los enrutadores A y D, una vía los aparatos de conmutación de los enrutadores B y C, y la otra solo vía el enrutador IP B (la trayectoria ABD se muestra como una flecha discontinua entre B y D en la figura 15). Las conexiones múltiples ahora se pueden proporcionar usando los enrutadores IP 62 que ofrecen un servicio de conexión orientada. El tráfico se puede conmutar para una nueva trayectoria dinámica si su trayectoria actual sufre de un nivel inaceptable de degradación, mientras que el plano de control se puede utilizar para reconfigurar dinámicamente el flujo de tráfico de A á D en cualquier punto a lo largo de la trayectoria. Esto permite que una fuente mayor de banda ancha del tráfico IP mantenga su calidad de servicio para su receptor incluso cuando el otro tráfico se generado posteriormente, el cual afecta la trayectoria original (1 en la red. El tráfico también se puede enviar simultáneamente a lo largo de dos o más trayectorias simultáneamente si se requiere la banda ancha, y proporcionar la secuenicacion apropiada, etc , las operaciones se pueden realizar en el enrutador IP de destino 62D En una modalidad adicional de la invención, las entradas de la tabla de envío de datos de todos los enrutadores IP 62 asociadas a ambas rutas pre-llenas, de modo que si la primera falla, la única tabla de envío que el plano de control necesita para rellenar es la tabla de envío del enrutador IP de la fuente 62A para efectuar el cambio de la 1ra ruta a la 2 a ruta En algunas modalidades, los procesadores del plano de control CPP 78 proporcionan la funcionalidad del control de conexión de llamada además de proporcionar la información de enrutamiento Por ejemplo, si el CPP 78a que controla el enrutador IP A recibe una petición de conexión entonces determina una ruta apropiada para el trafico que se origina de LAN de la fuente 60a a LAN de receptor 60d CPP 78a también asegura que la señalización apropiada se envíe al otro aparato de conmutación de Ethernet 62 en la ruta, CPP 78a se ha determinado (por ejemplo, para ia primera trayectoria mostrada en la figura 15, estos serán los enrutadores IP A, B, C y D) a modo que sus tablas de envío se actualicen apropiadamente Cuando las etiquetas de flujo estan presentes, al igual que el caso con la versión IP 6 en las cabeceras del paquete IP, en una modalidad de la invención, los flujos de tráfico se separan usando las etiquetas de flujo Esto permite que la gestión apropiada del tráfico se implemente (por ejemplo, para permitir que la carga de la red se balancee). Las etiquetas de flujo no necesitan intercambiarse, y si no se intercambian se pueden utilizar como parte de un identificador global si se combinan con una dirección IP. De esta manera se puede proporcionar una solución completamente escalable para la gestión de una red escalable, por ejemplo, reenviando el tráfico basado en una combinación de la dirección de destino y de la etiqueta de flujo. Si las etiquetas de flujo se intercambian por el aparato de conmutación IP, seguirá permaneciendo una etiqueta de flujo solamente de importancia local. Así se proporciona una conexión extremo-a-extremo entre el enrutador IP de fuente A y el enrutador IP del receptor D llenando cada una de las entradas de la tabla de envío para cada enrutador IP 20 a lo largo de una trayectoria (por ejemplo la primera y/o segunda trayectoria) con las entradas apropiadas de la tabla de envío. El envío es implementado por la tabla de envío que iguala la información de la cabecera relevante del IP a un puerto saliente del enrutador IP. Flujo de control IPv4. En la descripción anterior usando el aparato de conmutación de Ethernet, las marcas VLAN se utilizaron de una manera idéntica a la manera a la usada en las etiquetas de flujo IPv6 en la presente para lograr las trayectorias múltiples. También hay un número de maneras de implementar esta etiqueta de flujo multi-trayectoria en IPv4. Una opción utilizaría una dirección de la sub-red como la dirección y direcciones de destino con la sub-red para identificar cada trayectoria. El plano de control entonces puede establecer apropiadamente la máscara de la sub-red en la tabla de envío de cada enrutador IP para controlar el enrutamiento de cada trayectoria. Una segunda opción utilizaría el enrutamiento de la fuente IP, enrutamiento de fuente libre o enrutamiento de fuente limitada. Una tercera opción utilizaría un IP en UDP en la conversión IP y utilizaría el envío del puerto TCP/UDP en el enrutador IP para distinguir la trayectoria final. Otras opciones podrían utilizar otro de los campos opcionales en la cabecera IPv4. Las figuras 16 y 17 muestran esquemáticamente las versiones estándares relevantes del IP actualmente conocidas por los expertos en la técnica, respectivamente, la figura 16 muestra el formato de la versión IP 4, la figura 7 muestra el formato de cabecera básica de la versión IP 6. Las figuras 16 y 17 se incluyen para que ilustren estas cabeceras del protocolo, las cuales son bien conocidas por los expertos en la técnica y no serán descritas de forma adicional más detalladamente en la presente. Los expertos en la técnica encontrarán evidente que el término paquete IP no se debe limitar a las modalidades específicas descritas en la presente pero se refiere a cualquier tipo de formato de paquete funcionalmente equivalente cuyas características son capaces de implementar la invención. Las limitaciones impuestas por la longitud de los campos de la dirección IP se pueden disminuir apilando los campos de la dirección para encapsular la información de la cabecera IP. Esto se muestra esquemáticamente en la figura 18. Para más detalle con respecto a los esquemas de las encapsulaciones para el IP, el lector se refiere a Request for Comments starndars document RFC 1853 disponible de Internet Engineering Task Fource (IETF), o la documentación estándar equivalente disponible de European Telecommunications Standar Institute (ETSI) o de International Telecommunications Union (ITU), que son conocidos por los expertos en la técnica. Existe un número de otros esquemas de encapsulación (aparte de IP-en-IP), que también permiten que un paquete IP sea llevado en otro paquete IP y se usan para una variedad de aplicaciones (y más se pueden definir en el futuro). Por ejemplo, existen las encapsulaciones de IP-en-UDP que se pueden utilizar para soportar la característica multi-trayectoria descrita en la presente anteriormente. En esta descripción, IP-en-IP incluye cualquiera de estas encapsulaciones según sea apropiado, y no solo la encapsulación IP-en-IP descrita en el documento RFC1853. En las modalidades de la invención, en las cuales la información de cabecera IP visible del cliente se encapsula dentro de la información de cabecera IP proporcionada por ejemplo por un portador, y en las cuales se implementa un esquema de dirección jerárquico, el plano de control se aisla con seguridad del cliente. Esta cabecera externa que encapsula a los clientes, se puede proporcionar mediante el plano de control que opera su propio esquema de dirección proporcionando una cabecera externa para la información de cabecera convencional en el enrutador IP de fuente 62a. En esta modalidad de la invención, el esquema de encapsulación IP-en-IP es controlado por el plano de control 12. Las direcciones IP de fuente del cliente y de destino se encapsulan dentro de los campos de dirección IP en los enrutadores IP 62 del borde de la red. Cuando el IP en la encapsulación IP se implementa, el paquete del cliente se encapsula y no interactúa con el plano de control, en su lugar el plano de control actúa en las cabeceras IP de encapsulamiento proporcionadas por el aparato de conmutación IP, permitiendo que las direcciones IP del cliente permanezcan efectivamente invisibles en la red central IP. En la figura 19, se muestra un servicio IP-en-IP para la red IP central, pero los principios para envolver un paquete IP del cliente dentro del paquete IP de un portador se pueden aplicar para otras tecnologías. Mientras que el paquete del cliente esté sin tocar, se proporciona la transparencia. El portador está entonces libre de utilizar su propio esquema de dirección (proporcionando escalamiento, seguridad, aislamiento y detección de fallas). La figura 19 muestra la manera en la cual un paquete IP del proveedor (P) puede incluir otros campos que son completamente independientes de la cabecera del cliente. De este modo, se puede proporcionar la seguridad mejorada mientras que dentro del centro de la red, las direcciones IP usadas son las proporcionadas por el portador, cuyo esquema de dirección IP está siendo usado, si se requiere con las direcciones IP del cliente que solamente están desencapsuladas en el aparato de conmutación del borde de la red. El esquema de numeración usado en los dibujos anteriores se conserva para los elementos de la figura 19 que tienen la misma o equivalente funcionalidad. En la figura 19, el paquete IP del cliente (indicado como el paquete c-IP en el dibujo) se muestra conservado dentro del paquete IP del portador mientras que el tráfico fluye a través de la red. En una modalidad, solamente los enrutadores IP del borde 62 entienden el espacio de dirección del cliente. Esto no es necesario, sin embargo, si se proporciona un servicio punto-a-punto. Los enrutadores IP centrales 62 necesitan solamente entender el espacio de dirección del proveedor. La red IP proporcionada por la invención usa la dirección de fuente IP (SA) y la dirección de destino (DA) para proporcionar un servicio de conmutación de paquete de conexión orientada (CO-PS) del usuario final (usando la cabecera externa IP). Esto permite que un proveedor de servicio/operador de red ofrezca un tipo de "línea dedcada" del servicio donde el paquete IP del cliente se transporta transparentemente (ver, por ejemplo, la figura 19 de los dibujos anexos). La cabecera interna IP se procesa usando los protocolos convencionales de los enrutadores IP y de enrutamiento IP y opera como IP sin conexión convencional. En una modalidad de la ¡nvención, el proveedor de servicio/operador de red es capaz de agregar otra capa del servidor para implementar los servicios de propietario tal como el diseño del tráfico, etc. En otra modalidad de la invención las cabeceras internas y externas pueden ser diferentes versiones del IP. Las cabeceras internas y externas se separan lógicamente y son posibles muchas modalidades de la invención.
Anteriormente, se ha descrito la modalidad donde la cabecera externa es Ethernet (MAC) y en este caso, hay muchas otras modalidades constitutivas cada una con diferentes cabeceras internas. Los ejemplos incluyen IPv4 en MAC, IPv6 en MAC, IPX en MAC, y MAC en MAC. En la modalidad descrita en la presente, la cabecera externa es IP (por ejemplo IPv4 o IPv6) y hay también muchas modalidades constitutivas. Similarmente, los ejemplos incluyen IPv4 en IP, IPv6 en IP, IPX en IP, y MAC en IP.
Los expertos en la técnica estarán concientes que G.8080 describe una diseño para el plano de control de una red de conexión orientada, y es implementando la funcionalidad de conexión orientada del plano de control de G.8080 que un servicio de conexión orientada puede proporcionar en el ambiente de la red IP sin conexión. El plano de control de conexión orientada de G.8080 se utiliza para controlar la tecnología IP sin conexión y para así convertir el comportamiento de los enrutadores JP. En una modalidad de la invención, una interfaz apropiada es proporcionada conforme a G.8080 para separar los procesadores del plano de control (CPP) de la llamada/conexión 36 y los enrutadores IP 62, por ejemplo, cada enrutador IP 62 puede controlarse vía su interfaz en línea de comando (CLI) de propietario existente 32 (ver la figura 20). No se muestra en estos dibujos el fragmento o mediador que esta modalidad requiere que traduzca los comandos a través de la CLI (es decir, que maneje los cambios de la interfaz en línea de comando o del plano de control y los traduzca entre el "leguaje" usado en cualquier lado de la interfaz). El diseño de G.8080 también permite que el plano de control sea integrado en la plataforma del aparato de conmutación. Mientras que esto puede requerir modificaciones a la plataforma del aparato de conmutación para agregar la funcionalidad deí plano de control, no hay necesidad de cambiar el hardware que proporciona la funcionalidad de envío de datos. En otra modalidad de la ¡nvención, una ¡nterfaz estandardizada entre el aparato de conmutación y el plano de control tal como el Generalised Switching apparatus Management Protocol (GSMP) se utiliza para implementar la funcionalidad del plano de control. Por ejemplo, los GMPLS y los protocolos de gestión de red o los protocolos similares del plano de gestión o control se pueden utilizar para implementar la funcionalidad necesaria, por ejemplo, la eXtensible Mark-up Language (XML) o International Telecomnunication Union (ITU) Telecommunications(ITU-T) Recomendation M.3100. La orientación de conexión significa que la "dirección y etiquetado" se pueden desacoplar entre sí, con el sistema de señalización usado para asociarlos. La invención trata la dirección IP como una "etiqueta" que es solamente visible en el plano de control. En principio, cualquier esquema de dirección se puede utilizar mientras que la dirección es solamente visible para el procesador adjunto del aparato de conmutación IP, es decir, solamente visible en el plano de control. Sin embargo, para dar compatibilidad con las redes sin conexión, la dirección de la versión Internet Protocol 4 (IPv4) se podría utilizar o alternativamente, la versión Internet Protocol 6(IPv6). Dado el uso extenso de la dirección privada, una dirección única globalmente se ha creado implícitamente de una de dos formas. La primera forma es la dirección VPNid/IPv4 de la dirección global implícita usada en las redes privadas virtuales (VPNs) del protocolo de Internet (IP). La segunda forma de una dirección única globalmente es una dirección Network Address Transport (NAT). Esta dirección única globalmente se forma implícitamente mientras que la combinación de la dirección pública IPv4 de la puerta fue seguida por la dirección privada IPv4. Las alternativas tal como la dirección Network Service Access Point NSAP, la dirección E.164 o cualquier formato aplicable de la dirección única globalmente también se podrían utilizar en las modalidades alternativas de la ¡nvención. Es posible utilizar las formas humanas de dirección tal como las basadas en la ubicación geográfica y/o física de interfaz del aparato de conmutación, al igual conocidas por los expertos en la técnica de ¡mplementar las operaciones de red. El envío de señalización mediante el plano de control 54 al plano de datos 56 conforma a uno de los protocolos de señalización estándares actuales de acuerdo a una modalidad de la invención según lo descrito más detalladamente anteriormente en el contexto del tráfico de Ethernet pero aquí tiene la funcionalidad necesaria para tener extensiones simples que permiten a los parámetros específicos para el transporte IP. La funcionalidad del enrutamiento se puede implementar de una manera similar a la descrita en el contexto de las modalidades dirigidas hacia el aparato de conmutación de Ethernet. Una modalidad particular del enrutamiento dinámico puede utilizar los protocolos de enrutamiento dentro del enrutador. En esta modalidad, la enrutador puede ejecutar sus protocolos de enrutamiento normales para calcular una tabla de ruta, no obstante el envío del tráfico del usuario final no se basa directamente en esta tabla de ruta ya que estaría en el enrutamiento sin conexión normal. En su lugar, el plano de control utiliza esta tabla de enrutamiento en el enrutador como su tabla de enrutamiento para calcular las entradas de envío en la tabla de envío. En esta modalidad, el enrutador se configura de modo que se deshabilite el copiado normal de la tabla de la ruta en las tabla de envío, con la excepción de que las direcciones de los enrutadores sean requeridas para la operación correcta del protocolo de enrutamiento. La manera en la cual el enrutador deshabilita éste copiado puede variar dependiendo de la implementación exacta y de la capacidad de la CLI del enrutador. Una técnica particular que se podría utilizar para asistir a esto, sería asignar a las direcciones IP de los enrutadores un espacio diferente de las direcciones IP de los puntos finales del servicio de conexión orientada. Si es soportado por el enrutador IP, un filtro entonces se podría instalar para permitir el envío sin conexión de solamente la dirección IP de los enrutadores. Tal modalidad implementa automáticamente el auto-descubrimiento y la vinculación y detección de la falla del nodo. Así, en la modalidad de la invención mostrada en la figura 15, la información de enrutamiento es proporcionada por un plano de control implementado como una pluralidad de procesadores, cada procesador del plano de control 78 proporciona una entrada para un solo enrutador IP 62, que puede ser vía una línea de comando 74. Esta información se puede proporcionar usando un enrutador apropiado o un protocolo de control del aparato de conmutación o explícitamente vía la interfaz en línea de comando proporcionada para cada enrutador IP 62 en la red de comunicaciones. Si se configura el diseño del plano de control de modo que una funcionalidad del plano de control distribuida proporcione una red de comunicaciones del plano de control extremo-a-extremo, cada componente del plano de control proporciona la funcionalidad del plano de control para más de un aparato de conmutación, y de este modo el plano de control para los enrutadores IP 62 se puede ¡mplementar de una manera equivalente a la descrita en la presente anteriormente para el aparato de conmutación de Ethernet para el aparato de conmutación IP. Como se ha discutido anteriormente en el contexto de otras modalidades, se puede utilizar cualquier protocolo adecuado capaz de transportar la información de control al enrutador IP, por ejemplo, se podría usar las redes del protocolo del panel de control o gestión. El protocolo del plano de control puede ser propietario, basado en los protocolos de gestión o basado alternativamente en los protocolos de control estándares tal como GMPLS, ASON-RSVP-TE, CR-LDP, PNNI, SS7, etc, según lo descrito en la presente anteriormente, proporcionando que se adapten como es evidente para cualquier experto en la técnica a los parámetros específicos IP requeridos por la invención. Los expertos en la técnica estarán concientes que si un cambio se realiza a la ¡nterfaz en línea de comando (CLI) de un aparato de conmutación IP, los segmentos del software del aparato de conmutación entre el plano de control y CLI necesitarán actualizarse. Esto requiere que el software se actualice y que una red de comunicaciones separada sea requerida para el plano de control a modo de hablar al aparato de conmutación. En la figura 20, se muestran tres enrutadores IP 62 A, B, y C, cada uno tiene un CPP 78 asociado. Cada CPP 78 se conecta al enrutador IP 62 vía una interfaz apropiada, por la interfaz en línea de comando (CLI) denotada por x y/o por la interfaz y, que comprende una interfaz GSMP.
Alternativamente, se podría utilizar cualquier otro protocolo conocido capaz de controlar remotamente los enrutadores IP 62 del plano de control. Sin embargo, si se usa una interfaz del protocolo de gestión del aparato de conmutación para controlar remotamente el aparato de conmutación, entonces el software del aparato de conmutación necesitará modificarse para comunicarse con el CPP, por ejemplo, se puede requerir el segmento u otro mediador. La figura 21 muestra una modalidad alternativa de la invención, en la cual los CPPs 78 están conectados en una topología diferente que permite que diferentes CPPs 78 se comuniquen con diferentes redes de comunicaciones. Por ejemplo, los CPPs 78 podrían utilizar el identificador de flujo en los paquetes IPv6 para identificar las redes privadas virtuales que se pueden utilizar para transportar los mensajes del control entre los CPPs 78 y los enrutadores IP 62 Las redes privadas virtuales son instaladas por el operador de red de modo que sea posible distinguir cada una de la VPNs de control De esta manera es posible por ejemplo tener diferentes funciones del plano de control implementadas en diferentes VPNs De este modo es posible proporcionar el control lógicamente fuera de banda para un modo de transporte IP de conexión orientada Por otra parte, los expertos en la técnica apreciarán, una VPN también se puede utilizar para otros propósitos, por ejemplo, para transportar las operaciones y el mantenimiento de paquetes (OAM) Aparato de Conmutación de IP/Modo Dual En otra modalidad de la invención, un enrutador IP se configura para proporcionar un servicio sin conexión y un servicio de conexión orientada El enrutador IP proporciona una cierta funcionalidad sin conexión directa En esta modalidad, el plano de envío de datos conservará su funcionalidad sin conexión del servicio sin conexión Las entradas de las tablas de envío de datos se actualizan con la información derivada del plano de control solamente para el servicio de conexión orientada Los expertos en la técnica encontrarán evidentes numerosos equivalentes y modificaciones a las características descritas anteriormente en la descripción detallada de las modalidades de la invención El alcance de la invención por lo tanto se debe interpretar por las reivindicaciones anexas, en lugar de por las modalidades especificas descritas anteriormente A menos que por el contrario el contexto lo requiera, a través de la descripción y de las reivindicaciones, las palabras "comprende", "que comprende" y similares se deben interpretar en un sentido inclusivo en comparación a un sentido exclusivo o exhaustivo, es decir, en el sentido de "incluye, pero no se limita a" La descripción anterior indica claramente que el tráfico IP encapsulado se puede reenviar usando todas las herramientas, técnicas y protocolos existentes disponibles para las redes IP convencionales, mientras que el trafico IP encapsulado puede utilizar su propio plano de control y espacio de dirección Sin embargo, el trafico encapsulado y un parte o todo de su tráfico de control no necesitan reenviarse de manera similar Para las soluciones del plano de control que transportan su tráfico en combinación con el trafico del usuario (es decir utiliza los mismos vínculos que el trafico entre los enrutadores) uno podría simplemente de forma manual pre-proporcionar las conexiones dedicadas al control y gestión del tráfico (en la capa que proporciona la encapsulacion) para que el tráfico de control se pueda enviar alrededor de la red Este es un prerrequisito para crear las conexiones para el trafico del usuario Sin embargo, otros esquemas se pueden considerar Solo mientras que diferentes comportamientos de envío se puedan aplicar al trafico IP encapsulado y de encapsulamiento en el sentido que se esté aplicando en diferentes capas (IP en IP se puede considerar como la encapsulacion completa del cliente/servidor en el sentido de la ITU Recommendation G 809 donde el trafico encapsulado se asocia a la capa del cliente y el trafico de encapsulamiento está asociado a la capa del servidor) también se puede aplicar hopzontalmente En lugar de la pre-provision de las conexiones para el tráfico de gestión y control, el trafico de control se puede enviar de una manera sin conexión mientras que el tráfico del usuario se envía a lo largo de conexiones (en la capa de encapsulamiento) Como tal, la capa que está proporcionando la encapsulación, se puede dividir tal que el trafico de control se reenvié de acuerdo a las técnicas de envío IP convencionales mientras que el trafico de tipo conexión se reenvía usando el nuevo plano de control La ventaja de dividir el comportamiento de envío es que el trafico del plano de control puede utilizar todas las herramientas y protocolos disponibles en las redes IP convencionales Como tal, los protocolos tal como Internet Control Message Protocol (ICMP) y sus atributos (tal como registro de ruta y Ping) se pueden desplegar para el tráfico del plano de control y el plano de control también pueden utilizar la los protocolos de enrutamiento IP para llenar las tablas de enrutamiento para asistir el trafico de control de envío Los protocolos de ^nrutamiento para el trafico de control se pueden utilizar para llenar las tablas de enrutamiento solamente para el tráfico del plano de control, simplemente filtrando las direcciones IP que no se asocian al tráfico de control. También se debe observar que las herramientas tal como ICMP también se pueden utilizar dentro de las conexiones. En este caso se limitan al contexto de la conexión, no obstante las herramientas y técnicas de diagnóstico IP convencionales ahora se pueden ejecutar "en conexión" para proporcionar las instalaciones de OAM para monitorear la conexión. Además estas herramientas se pueden utilizar en conexiones unidireccionales. Aquí la trayectoria de regreso no necesita seguir la conexión y se pueden enviar los mensajes de regreso en el plano de control. Alternativamente para dos conexiones unidireccionales que se asocian para formar una conexión bidireccional, la trayectoria de regreso puede seguir la conexión en la otra dirección. Si el tráfico de control entre los procesadores de control se ejecuta en una red separada de la del tráfico del usuario (es decir vínculos separados y distintos), el envío del tráfico del plano de control está en cualquier caso totalmente separado del caso del tráfico del usuario. El espacio de dirección de este tráfico también está separado y no necesita de hecho incluso ser del mismo tipo (es decir IPv4 en un espacio IPv6, en el otro). Las modalidades anteriores de la invención indican claramente que es posible proporcionar un servicio de conexión orientada usando el aparato de conmutación diseñado originalmente para los modos del transporte sin conexión. Ahora se puede utilizar para proporcionar un servicio de conexión orientada cualquier equipo de comunicaciones de dos capas diseñado originalmente para soportar los modos de transporte sin conexión de 2 capas o 3 capas OSI que confía en las tablas de enrutamiento que son capaces de estar llenos remotamente del plano de control. Los esquemas de dirección sin conexión originales se pueden conservar pero uno o más campos que contienen la información de dirección en cada cabecera de la trama se utilizaran mediante el plano de control para actualizar las tablas de enrutamiento a través de una interfaz apropiada para el aparato de conmutación. Mediante la información de dirección de encapsulamiento en el aparato de conmutación en el borde de la red central (por ejemplo el portador), la información de dirección del cliente se puede encapsular dentro del portador, se proporciona la información de dirección y así se transporta con más seguridad a través de la red. Las figuras 22A y 22B muestran de que manera la tabla de envío 80 de un enrutador IP se puede llenar mediante el plano de control 54. En el IP una tabla de envío es referida como una tabla de enrutamiento y contiene lista organizada por prioridad de las rutas (efectiva para agregar las direcciones) asociadas a un puerto saliente particular del enrutador IP. De acuerdo a la invención, el plano de control 54 llena la tabla de envío IP 80 con las rutas organizadas por prioridad de tal manera se asegura que el enrutador por defecto esté sin conexión, si se proporciona una ruta por defecto. El motor de envío del enrutador IP simplemente busca en las entradas de ruta en la tabla de envío 80 mostrada en la figura 22A, mientras que selecciona una ruta asociada a un puerto saliente particular del enrutador para un paquete IP recibido. En el ejemplo mostrado en la figura 22A, la ruta 82a es la ruta de prioridad más alta, mientras que la ruta 82b tiene una prioridad más baja. La ruta 84 es la ruta por defecto, que en esta modalidad de la invención está sin conexión. Para implementar el enrutamiento mult-trayectoria en la modalidad mostrada en la figura 22A, es posible asignar una sub-red del espacio de dirección IP a la dirección de destino, y entonces cada una de las direcciones individuales en el espacio de dirección de la sub-red IP se pueden utilizar para distinguir cuales trayectorias son diferentes. De esta manera, las trayectorias múltiples se pueden instalar de una manera de conexión orientada para el tráfico que está conforme a los protocolos IP estándares. Por ejemplo, en el esquema de dirección IP que es bien conocido por los expertos en la técnica, la sub-red clase C se puede utilizar como la dirección de destino, y hasta 256 trayectorias se pueden designar usando las direcciones individuales clase C. La figura 22B muestra una modalidad alternativa de una tabla de envío/enrutamiento para un enrutador IP de acuerdo a la invención, en la cual el plano de control 54 llena la tabla de envío con la información de ruta que comprende una serie de rutas IP estándares de la dirección y del espacio de dirección enmascarado de la manera mostrada en la figura 22A, y además proporciona el identificador de puerto TCP/UDP para permitir que las trayectorias múltiples se instalan entre una fuente y una dirección de destino IP particular. Todas las modalidades anteriores muestran que la invención proporciona medios de permitir que un aparatos de conmutación de 2 ó 3 capas OSI se configure para soportar los modos de tráfico sin conexión para soportar los modos de tráfico de conexión orientada como el modo de transmisión por defecto, con los modos de tráfico sin conexión que están reducidos o permitidos solamente si se identifican como tal, por algunos medios, por ejemplo, usando una entrada particular de la tabla de enrutamiento con la marca VLAN o por defecto. Así esta invención permite la reutilización del equipo sin conexión existente para el servicio de conexión orientada, que incluye todas las características de multi-trayectoria y las características de restauración de trayectoria asociadas normalmente al servicio de conexión orientada, sin ningún cambio al equipo existente o a cualquiera de los estándares asociados al equipo. Para implementar las características de la multitrayectoria y la restauración de trayectoria, un identificador multitrayectoria es necesario, al cual no se puede llegar por una dirección de destino simple o por un par de direcciones de fuente y destino. Otro campo es necesario para esto, tal como la identificación VLAN, identificación de flujo IPv6, o un número de posibilidades para IPv6 descritas en la presente posteriormente, el cual está ausente en la técnica anterior. El control del tráfico de conexión orientada se desacopla completamente por cualquiera de los protocolos de control sin conexión existentes, por ejemplo el protocolo de aprendizaje de transición de Ethernet y de árbol extendido o protocolos de enrutamiento IP, así se da la seguridad asociada normalmente al servicio de conexión orientada. Así, deshabilitando los protocolos del plano de control convencionales, la invención hace posible configurar de nuevo el hardware para operar de un modo de conexión orientada. Sin importar si la forma de orientación a la conexión es conmutación de circuitos (por ejemplo TDM, o longitudes de onda) o conmutación de paquetes (por ejemplo ATM), hay un conjunto de propiedades que muchos consideran que definen la orientación a la conexión. Incluyen los recursos de petición y asignación antes de transferir la información. En el plano de datos se asume que el envío está basado en un identificador de conexión que tiene una importancia local del vínculo. Los ejemplos incluyen el lapso de tiempo en las redes TDM, longitudes de onda en las redes ópticas, campos VCI y VPI en ATM, campo DLCI en la retransmisión de trama y la etiqueta en la redes MPLS basadas en RSVP-TE. Este identificador de conexión también es conocido por los expertos en la técnica como "etiqueta" y se asocia a cada unidad de tráfico que se transporta a través de la red. Se conoce en la técnica para reenviar las unidades de tráfico usando etiquetas, por ejemplo, en el intercambio de etiqueta de las redes de conmutación de paquetes de conexión orientada (CO-PS) se puede alcanzar la escalabilidad. La etiqueta puede ser explícita o implícita (por ejemplo un lapso de tiempo). El IEEE está desarrollando actualmente la encapsulación de MAC-en-MAC que permite: que el espacio de dirección del proveedor se desacople del espacio del cliente, que las tramas del cliente se desmarquen o marquen, que los clientes usen sus propios protocolos de control tal como el protocolo de expansión de árbol, y el uso de la jerarquía para proporcionar seguridad encapsulando las tramas del cliente en el borde de la red. El uso de la jerarquía también permite la separación del control durante la gestión, por ejemplo, a modo que el control de gestión en una capa de jerarquía sea independiente del control implementado en otras capas. Es posible en algunas modalidades de la ¡nvención que la capa del cliente esté sin conexión y que la funcionalidad de envío y transición sea según lo definido por IEEE en la capa del cliente.
Esto se aplica a las marcó sin marcar y marcadas. No hay necesidad de recurrir a las construcciones de conexión orientada para describir las VLANs (pues una VLAN no es una conexión) y desde la perspectiva del cliente la red en ésta capa parece ser cualquier otra red Ethernet. Sin embargo, en tales modalidades, en la capa del servidor, el formato normal de las tramas Ethernet, se mantiene pero la funcionalidad de transición se conmuta, por ejemplo aprendizaje MAC y Broadcast on Unknown. El árbol de expansión también se deshabilita. Así el concepto propuesto en la presente se puede aplicar a parte o todo el intervalo VLAN. Mientras que las especificaciones IEEE permiten que las tablas de envío se llenen por medio de la configuración estática con el objeto de implementar el enrutamiento sin conexión, la invención utiliza este mecanismo para llenar las tablas de envío para implementar el enrutamiento de conexión orientada entre una fuente y un receptor del tráfico de Ethernet o IP. Esto permite que el envío de conexión orientada use el hardware existente. Si una Protocol Data Unit (por ejemplo una trama o paquete) está presente sin ninguna entrada en una tabla de envío, PDU simplemente se disminuye. De esta manera, no se permite que el tráfico esté en la red a menos que se asocie a una conexión. Refiriéndose ahora a la figura 23 de los dibujos anexos, se muestra una modalidad de la invención, la cual implementa el enrutamiento muti-trayectoria entre el aparato de conmutación en la red central para el tráfico en el nivel 2 OSI (por ejemplo el tráfico tiene la información de dirección Ethernet). Las modalidades equivalentes se pueden proporcionar para el tráfico del nivel 3 OSI, por ejemplo, el tráfico tiene la información de la dirección IP.
En la figura 23, una primera trayectoria se muestra entre el aparato de conmutación A, B, C, y E, y una segunda trayectoria se muestra entre el aparato de conmutación A, D, y E. En la figura 23, se muestra una modalidad de la invención en la cual el tráfico del cliente comprende el tráfico de Ethernet. Las tramas de tráfico de Ethernet del cliente se encapsulan usando un esquema de encapsulación apropiado en las tramas Ethernet que tienen la información de la dirección del proveedor entre el aparato de conmutación de Ethernet 20 de la red central. Los esquemas de encapsulación similares se pueden implementar para el tráfico IP. Así en la modalidad mostrada en la figura 23, en el nodo A, el plano de gestión 10 (y/o el plano de control 12) ha configurado los puertos salientes para reenviar el tráfico que se asocia a la VLAN ID 100 a lo largo de la primera trayectoria, y el tráfico que tiene la VLAN ID 120 se reenvía a lo largo de la segunda trayectoria. En la figura 23, los elementos de la red A y E corresponden a los dispositivos del borde de red, por ejemplo los dispositivos adaptables 802.1ah, que ofrecen los puertos frontales del cliente donde el tráfico del cliente se encapsula sobre las trayectorias conmutadas Ethernet configuradas en A y extraídas en E. La primera trayectoria se ha computado en el plano de abastecimiento y gestión para el tráfico que asignó VLAN-ID 120. Así las tablas de envío configuradas en los conmutadores P de intervención para aplicar VID = 120/MAC = E a los puertos de salida apropiados de cada dispositivo para definir una trayectoria contigua. Para la segunda trayectoria, el mismo proceso dio lugar a una trayectoria configurada en los conmutadores usando VID = 100/MAC = E. Un proceso similar también se utiliza para configurar las trayectorias de regreso simétricas de E a A. En el ejemplo las trayectorias deliberadamente se asocian/desasocian en el nodo D para ilustrar que es la combinación de VID y MAC que proporciona la entrada de envío. Es la combinación de los dos, la cual determina la trayectoria de envío. Las colisiones en cualquier espacio, tal como VID 100 ó 120 se utilizaron en combinación con otra dirección de MAC o como en el ejemplo anterior donde las trayectorias 120/E y 100/E transversales todavía se determinan únicamente a un solo puerto de salida. La VLAN ID ahora se utiliza para identificar una de un número de trayectorias paralelas para una dirección de destino. El campo VLAN ID no es globalmente más significativo cuando se utiliza de esta manera y cada valor de VLAN ID se puede reutilizar para una dirección de destino diferente. Sin embargo, no hay impacto sobre el envío en cada aparato de conmutación. De acuerdo a la invención, se puede utilizar cualquier valor del identificador de campo de cabecera del índice o combinación de los valores que se pueda incorporar medíante el plano de control en la tabla de envío, aunque en el ejemplo anterior es la combinación de una dirección de MAC y VLAN ID en donde se ha basado el envío. Esto permite la "asociación" en el nivel de la marca VLAN mientras que usa la combinación de los campos para asegurar la unicidad global. Esto proporciona un comportamiento de escalamiento atractivo, mientras que se evita la pérdida de visibilidad de la fuente que ocurre en las tecnologías de conexión orientada que utilizan solamente una etiqueta al asociarse. No requiere la introducción de ninguna nueva forma de mecanismo de envío, en contraste al intercambio de VLAN. Explotando la dirección de MAC existente más otro identificador de cabecera tal como la etiqueta de VLAN y utilizando los mismos valores para la dirección de MAC y VLAN ID en cada salto entre el aparato de conmutación a través de la red, es simplificado considerablemente OAM para la conexión a través de la red de comunicaciones. Por ejemplo, es inmediata la auto-identificación de los errores de envío tal como la configuración incorrecta. En particular, la cabecera adicional más la dirección de destino MAC permite que las capacidades del diseño del tráfico sean agregadas a Ethernet. Esto representa un beneficio considerable sobre las soluciones existentes de Ethernet. Las capacidades de la orientación a la conexión tal como la gestión de la banda ancha y el control de la admisión a la conexión proporcionan la gestión del recurso. En contraste a las tecnologías de conexión orientada existentes, el envío no se hace por medio de una sola etiqueta implícita o explícita, pero si por medio de una combinación de una dirección de destino y una etiqueta del identificador de cabecera que ahora actúa como un distinguidor de ruta, por ejemplo, el tráfico de una prioridad más alta puede asignar un modo de transporte de conexión orientada, mientras que el tráfico que tiene una prioridad más baja puede continuar siendo enrutado a través de la red en un modo sin conexión. Claramente mientras que una etiqueta es suficiente para el envío de conexión orientada, la funcionalidad adicional se puede obtener si también se utiliza una dirección. Para la mayoría de las tecnologías de conexión orientada esto no son posibles, pero con Ethernet (o IP) esto es posible como un resultado del formato de trama/paquete. La combinación de una dirección y una etiqueta también significa que no es requerido el intercambio. Así el envío solo no determina el comportamiento de conexión orientada o sin conexión y cualquier forma de comportamiento se pueden obtener usando el mismo formato de trama y el mismo hardware. El aparato de conmutación de 2 y 3 capas OSI configurado para implementar el enrutamiento sin conexión sobre una base ad-hoc y que tiene medios para la interfaz con un plano de control se puede adaptar de acuerdo a la invención para implementar el enrutamiento de conexión orientada, proporcionando que se deshabilite la funcionalidad de aprendizaje de enrutamiento/dirección sin conexión en todos los o un subconjunto de puertos del aparato de conmutación en el cual el servicio de conexión orientada se implementara. Esto permite que el enrutamiento de conexión orientada sea implementado en todos o una sola gama de puertos (o VLAN-IDs u otros identificadores de campo capaces de examinarse mediante el aparato de conmutación) donde se usa el plano de gestión o control para llenar directamente las tablas de envío del aparato de conmutación. La operación del aparato de conmutación en algunas modalidades es selectiva bajo el control del plano de control, más bien es determinado estáticamente. Proporcionando una pluralidad de aparatos de conmutación de Ethernet cuyas tablas de envío se han llenado directamente de esta manera en una red de comunicaciones, el aparato de conmutación opera efectivamente en el modo CO-PS para todo el tráfico cuyos valores del identificador de campo de cabecera igualan los valores, el plano de control ha configurado el conmutador para proporcionar un servicio de conexión orientada. Mientras que éste se puede hacer para algunas entradas en la base de VLAN-ID, otras entradas pueden comprender otros identificadores de cabecera, por ejemplo, Ethertype, o prioridad, o una combinación de los mismos, de hecho, cualquier información que se pueda proporcionar mediante el plano de control y que se pueda formatear de una manera apropiada a modo que pueda ocupar las tablas de envío usadas por el aparato de conmutación, y que se pueda igualar a la información extraída por el aparato de conmutación de los campos de cabecera de tráfico. Así es posible configurar el aparato de conmutación para que tenga tablas que tienen algunas entradas en las cuales un puerto de salida se asocia a VLAN-ID y DA, y otras entradas en la misma tabla que se asocian a un puerto de salida con Ethertype y DA o con la prioridad y DA, etc. La diversidad de las entradas puede dar lugar a una pluralidad de trayectorias para el tráfico (por ejemplo, si el puerto de salida se asocia a VLAN-ID particular y DA se congestiona, es posible que el tráfico sea enrutado a lo largo de una trayectoria alternativa basada en DA y Ethertype o prioridad, si éstos se asocian a un puerto de la salida diferente). El plano de control configurará las tablas de envío de todos los aparatos de conmutación relevantes para establecer una conexión a través de la red de comunicaciones (es decir, cada serie contigua de aparatos de conmutación llenará efectivamente sus tablas de envío tal que cada entrada instale una conexión uni-direccional (o bi-direccional si también se aplica a la dirección contraria. Es decir, SA a DA es unidireccional pero las entradas SA-DA y DA-SA proporcionan una conexión bidireccional). El identificador en una tabla de envío puede ser parte de una serie o una gama de identificadores, por ejemplo, una serie o una gama de VLAN-IDs que son únicos para MAC DAs específicos. Si es así pueden identificar el número de las terminaciones de potenciales de conexión en cualquier DA dado. Mientras que la tabla de envío responde normalmente a las direcciones desconocidas por inundación, esta funcionalidad se debe deshabilitar para asegurar que se evite la inundación, y la tabla de envío se llena directamente con la información del plano de gestión (o equivalentemente, del plano de control). Esto se aplica en particular a cualquier tráfico de emisión o multi-emisión cuyas necesidades ser filtraran (o reducirán) antes de la transmisión mediante el aparato de conmutación. El enrutamiento explícito de las conexiones a través de la red cuando se combina con el control y cola de admisión de llamada, por ejemplo, cola basada en la clase basada en 802.1Q, permite el QoS por conexión. Sin embargo, una cierta información de topología la cual es obtenible de la red (por ejemplo, usando la tecnología estándar ITU-802.1ab) es necesaria para proporcionar un servicio CO-PS. Es también necesario para proporcionar la señalización de las conexiones requeridas, por ejemplo, las conexiones se pueden señalar del plano de gestión usando el tráfico OAM (por ejemplo, usando ITU-802.1ag). La invención se relaciona así al uso de un plano de control para configurar el aparato de conmutación tal que la decisión de si el tráfico recibido se enrutara de una manera de conexión orientada o sin conexión a través de una red central, independientemente del modo de transporte utilizado en las redes de acceso. Equivalentemente, el plano de gestión se puede utilizar para configurar apropiadamente el plano de control, y es capaz de determinar cuando un servicio de conexión orientada se implementara. El proveedor o cliente del servicio de red de área local no necesita asignar valores específicos de gama de campo de cabecera (aunque lo puede hacer) para que el tráfico se enrute de una manera de conexión orientada a través de la red central. Algunas modalidades de la invención permiten que un proveedor de servicio controle la operación del aparato de conmutación vía el plano de control para proporcionar selectivamente un servicio de conexión orientada o sin conexión para el tráfico a través de la red central. De esta manera, por ejemplo, es posible ofrecer selectivamente un modo de conexión orientada del transporte de acuerdo a la hora y carga del tráfico en la red central (o cantidad de tráfico a una dirección de destino específica), más bien de acuerdo a la información específica en el campo de cabecera de los paquetes/tramas recibidos. El modo del tráfico de envío se determina simplemente si los protocolos sin conexión (por ejemplo los protocolos de árbol extendido y de aprendizaje de dirección o cualquier protocolo que tenga una funcionalidad equivalente para el tráfico no Ethernet) se operan en las interfaces específicas del aparato de conmutación o si han sido deshabilitado/retirado tal que el plano de control se pueda proporcionar la información de enrutamiento equivalente para establecer una conexión para cierto tráfico recibido a través de la red central. Esto permite que al aparato de conmutación opere al tráfico de envío a la misma dirección de destino de una manera sin conexión y/o de conexión orientada, al mismo tiempo (es decir, en un modo híbrido) o selectivamente en diferentes momentos según lo determinado por el plano de control. El tráfico no necesita asignar identificadores específicos en sus campos de cabecera en su fuente, mientras que el modo de operación del aparato de conmutación se controle solamente cerca si o no una conexión es establecida por el plano de control. El plano de control puede configurar el aparato de conmutación para eliminar todo el tráfico desconocido o el aparato de conmutación puede transferir el tráfico desconocido a un puerto de salida en el cual se ha conservado un protocolo de dirección adecuado, por ejemplo, intercambiando la VLAN-ID de un paquete/trama recibido a una VLAN-ID asociada a un puerto de salida para el cual la difusión en la funcionalidad desconocida no se ha deshabilitado/retirado. Donde la funcionalidad del árbol extendido y del aprendizaje de dirección es remotamente configurable, el plano de control se puede utilizar para activar/desactivar remotamente esta funcionalidad. De esta manera, es posible que el aparato de conmutación modifique dinámicamente su comportamiento de acuerdo a la información que recibe desde el plano de control para proporcionar el enrutamiento de conexión orientada extremo-a-extremo o sin conexión para el tráfico recibido activando o desactivando la funcionalidad de una o más interfaces del aparato de conmutación que permite que cada una o más interfaces operen de una manera sin conexión. Los expertos en la técnica estarán concientes que hay muchos aspectos del aparato de conmutación convencional no descritos de forma detallada anteriormente, tal como por ejemplo, los medios de almacenamiento de datos del aparato de conmutación, los cuales pueden ser, por ejemplo, una base de datos configurada para proporcionar la funcionalidad de "búsqueda" de dirección. Se asume que tales medios de base de datos están asociados al aparato de conmutación y/o integrados al aparato de conmutación tal que el plano de control sea capaz de proporcionar la información apropiada para llenar la base de datos (se asume que la información del plano de control se formatea/configura/traduce apropiadamente mediante un segmento apropiado de cualquier manera evidente para los expertos en la técnica en una forma adecuada para la inclusión en la base de datos). De esta manera, se pueden llenar mediante el plano de control los registros de la base de datos que asocian las interfaces salientes (o puertos de salida) del aparato de conmutación con la información asociada a uno o más campos de cabecera predeterminados del tráfico recibido.
Convencionalmente, el aparato de conmutación se proporciona con las tablas de envío que contienen por lo menos la dirección de destino asociada a un puerto de salida. Por ejemplo, el aparato de conmutación de Ethernet contiene generalmente la información de envío que comprende la VLAN-ID y la información de la dirección de destino y el puerto de salida asociado del aparato de conmutación. Sin embargo, puesto que plano de control ahora está llenando la base de datos, es posible remplazar o sustituir la información de VLAN-ID con la información de otro campo de la información de cabecera, por ejemplo, los campos de cabecera Ethertype o de prioridad, totalmente o en parte en la base de datos. Esto es debido a que cualquier información que es simplemente proporcionada necesita igualarse con la información de cabecera apropiada en la base de datos para que un paquete recibido se asocie a un puerto de salida del aparato de conmutación. Por ejemplo, si el plano de control ha llenado la entrada en la tabla de transición en el aparato de conmutación a modo que el puerto de salida del aparato de conmutación de Ethernet tenga deshabilitada su funcionalidad de aprendizaje MAC y desactivado el protocolo de árbol extendido (y así no se proporciona ningún BPDU), entonces el paquete procede en una base de conexión orientada. Si sin embargo, el plano de control no ha proporcionado selectivamente la información de conexión orientada para el puerto de salida, entonces el protocolo de árbol extendido, etc. seguirá siendo funcional para el puerto, y el paquete procede de una manera sin conexión. En algunas modalidades donde el plano de control se utiliza para activar y/o desactivar remotamente el protocolo de árbol extendido, es posible que los mismos puertos de salida de los aparatos de conmutación en la red de comunicaciones cambien dinámicamente su función de una manera sin conexión u de conexión orientada. De esta manera, una red de comunicaciones puede comprender una pluralidad de redes de acceso (por ejemplo redes de área local) que soportan los protocolos de comunicaciones sin conexión y una red central cuya funcionalidad puede estar sin conexión u de conexión orientada de acuerdo a los requisitos de proveedor del servicio que controla el aparato de conmutación en la red central. Por ejemplo, el tráfico de una fuente se puede enrutarse por el proveedor de servicio a una dirección de destino en un modo sin conexión y el tráfico de la misma fuente pero enviado en un momento diferente se puede enviar en un modo de conexión orientada. Como otro ejemplo, el tráfico de una fuente se puede enviar de una manera sin conexión a una dirección de destino pero el tráfico enviado al mismo tiempo de otra fuente a la misma dirección de destino se puede enviar de una manera de conexión orientada. No hay necesidad de proporcionar un intervalo de valores del campo de cabecera o configurar las cabeceras de tráfico con la información de cabecera predeterminada para recibir un servicio de conexión orientada, más bien, se determina la decisión de enlutar el tráfico de una manera de conexión orientada mediante el plano de control de acuerdo al criterio tal como una o más condiciones determinadas en la red central.
Así en algunas modalidades es posible que el tráfico cambie su modo de transporte dinámicamente del aparato de conmutación a otro aparato de conmutación antes de alcanzar su dirección de destino. Como un ejemplo, del conmutador A al conmutador C en la figura 23, es posible que el tráfico de un cierto tipo se enrute de una manera sin conexión, pero del conmutador C al conmutador E de una manera de conexión orientada. Al mismo tiempo, el tráfico de un diferente tipo se pude enlutar de una manera de conexión orientada del conmutador A á C y de una manera sin conexión del conmutador C al conmutador E. sin embargo, en el mejor modo de la invención, el modo de transporte es determinado en una manera extremo-a-extremo por el plano de control llenando directamente las tablas de envío de datos del aparato de conmutación vía cuya conexión se ha establecido con la información de enrutamiento apropiada. Para que un proveedor de servicio ¡mplemente un servicio de conexión orientada extremo-a-extremo para el tráfico del protocolo sin conexión, el plano de control configura el aparato de conmutación de la red central para establecer una conexión apropiada entre el nodo del borde de fuente y el nodo del borde de destino. Esto es logrado asociando ciertos campos de información de cabecera a los puertos de salida predeterminados del aparato de conmutación, tal que el tráfico recibido que contiene la misma información en sus campos de cabecera es enrutado de una manera de conexión orientada. Así en la base de uno o una combinación de los campos de cabecera, por ejemplo, uno o más campos de dirección de destino y/o uno o más campos de la dirección de fuente y/o uno o más campos de la dirección de ruta de fuente y/o uno o más campo Ethertype y/o uno o más campos de prioridad y/o uno o más campos del tipo de servicio y/o uno o más campos del identificador de flujo y/o unos o más campos capaces de identificar una red privada virtual y/o uno o más campos de protocolo y/o uno o más campos del identificador de puerto de destino TCP/UDP y/o uno o más campos del identificador de puerto de fuente TCP/UDP, es posible determinar si el tráfico recibido se debe reenviar de un modo sin conexión u de conexión orientada, y sí después, a lo largo de una o más trayectorias a la dirección de destino. Así, por ejemplo, configurando el plano de control, un proveedor de servicio de red central puede proporcionar o no selectivamente un servicio de conexión orientada para cierto tráfico, de acuerdo a un número de criterios potenciales y se puede configurar para que el plano de control configure el aparato de conmutación de la red central adecuadamente. Esto significa que los proveedores de servicio de acceso pueden solicitar simplemente el servicio de conexión orientada para cierto tráfico sin necesidad de asegurar que los identificadores predeterminados específicos se incluyan en la información de cabecera para asegurar que un servicio de conexión orientada sea recibido. Esto permite que el servicio de conexión orientada sea implementado por el control de una manera virtualmente sin impacto entre una dirección de fuente y destino. Como un ejemplo, si la congestión de red para el tráfico sin conexión excede ciertos niveles, puede ser ventajoso que el tráfico sin conexión cambie a un modo de conexión orientada del transporte en una manera relativamente sin impacto, por ejemplo reconfigurando dinámicamente el aparato de conmutación tal que enrute el tráfico recibido de un modo de conexión orientada. La descripción de las modalidades preferidas no tiene el propósito de limitar el alcance de las reivindicaciones anexas a la misma. Las modificaciones a las características anteriores de la invención y a las características que tienen efecto equivalente a las características evidentes para el experto en la técnica están incluidas implícitamente en la descripción. El alcance de la invención se debe por lo tanto interpretar mediante las reivindicaciones anexas, en lugar de por las modalidades específicas descritas anteriormente. Las características descritas en el contexto de una modalidad que se incorporan fácilmente en otras modalidades o que son evidentes para un experto en la técnica son funcionalmente equivalentes o capaces de remplazar las características en otras modalidades que están pensadas implícitamente para incorporarse en la descripción de otras modalidades. Aunque las modalidades principales de la ¡nvención han discutido la proporción de los protocolos sin conexión tal como Ethernet e IP, los expertos en la técnica apreciarán que la invención no esté limitada a estos dos protocolos de transporte o versiones de estos protocolos, pero por el contrario se establecen mediante las reivindicaciones anexas. Los expertos en la técnica apreciarán que haya muchas modificaciones y variaciones posibles a las características de las modalidades de la invención descritas en la presente, y que las características descritas en el contexto de una modalidad, las cuales se pueden adaptar convenientemente, se puedan incorporar en otras modalidades. A menos que por el contrario el contexto claramente lo requiera, a través de la descripción y reivindicaciones, las palabras "comprende", "que comprende" y similares se interpretaran en un sentido inclusivo en comparación a un sentido exclusivo o exhaustivo; es decir, en el sentido de "incluye, pero no se limita a".

Claims (113)

REIVINDICACIONES
1. Un aparato de conmutación en una red de comunicaciones, que comprende: una pluralidad de puertos de ingreso configurados para recibir el tráfico en forma de unidades de datos de protocolo que conforman un protocolo de comunicaciones sin conexión; una pluralidad de puertos de salida para reenviar el tráfico recibido en; medios de interfaz configurados para recibir la información de un procesador del plano de control; y medios de almacenamiento de datos, mediante los cuales la información proporcionada por el plano de control se almacena y configura para asociar un puerto de salida del aparato de conmutación a un campo de índice, en donde la información recibida por el aparato de conmutación del plano de control permite que el aparato de conmutación opere para proporcionar un modo de conexión orientada de transporte para el tráfico recibido para establecer una conexión entre un nodo de fuente y un nodo final en ia red de comunicaciones vía una pluralidad de otros aparatos de conmutación configurados por el plano de control, en donde el aparato de conmutación no tiene ninguna otra funcionalidad capaz de controlar la función de envío de datos para las interfaces de los aparatos de conmutación configurados por el plano de control para proporcionar un modo de conexión orientada de transporte para el tráfico recibido, en donde el modo del transporte para el tráfico recibido entre la fuente y el destino es determinado por el plano de control para la pluralidad de aparatos de conmutación en la red de comunicaciones.
2. Un aparato de conmutación de conformidad con la reivindicación 1, en donde el modo de transporte es determinado por el plano de control que llena los medios de almacenamiento de datos con una pluralidad de identificadores de campo de índice, por lo menos un identificador de campo de índice comprende una dirección de destino de la conexión que se establecerá para el tráfico recibido. '
3. Un aparato de conmutación de conformidad con la reivindicación 1 ó 2, en donde el modo de transporte es determinado por el plano de control que llena los medios de almacenamiento de datos con una pluralidad de diferentes identificadores de campo de índice, por lo menos un identificador de campo de índice comprende una dirección de destino de la conexión que se establecerá para el tráfico recibido.
4. Un aparato de conmutación de conformidad con la reivindicación 2 ó 3, en donde la pluralidad de identificadores de campo de índice se configura en un orden jerárquico, y los identificadores de campo de índice a diferentes niveles de la jerarquía se asocian a diferentes puertos de salida de la configuración del conmutador.
5. Un aparato de conmutación de conformidad con cualquiera de las reivindicaciones 1 a 4, en donde la información recibida del procesador del plano de control adicionalmente controla la función de filtración de datos que el aparato de conmutación realiza en el tráfico recibido, y en donde el aparato de conmutación no tiene ninguna otra funcionalidad capaz de controlar la función de filtración de datos para las interfaces del aparato de conmutación para el cual el plano de control ha proporcionado la información para controlar la función de filtración de datos.
6. Un aparato de conmutación de conformidad con cualquiera de las reivindicaciones 1 a 5, en donde las funciones de envío y/o filtración realizadas por el aparato de conmutación son controladas por el plano de control que llena las tablas de envío usadas por el aparato de conmutación para causar que el tráfico recibido siga unas o más trayectorias predeterminadas a través de la red de comunicaciones.
7. Un aparato de conmutación de conformidad con la reivindicación 6, en donde la tabla de envío tiene entradas que causan que el tráfico recibido sea reenviado usando un modo de conexión orientada que tiene origen en las entradas para el tráfico sin conexión.
8. Un aparato de conmutación de conformidad con cualquiera de las reivindicaciones anteriores 1 a 7, en donde el tráfico recibido comprende tramas Ethernet o paquetes IP.
9. Un aparato de conmutación de conformidad con cualquiera de las reivindicaciones 3 a 8, en donde para uno o más puertos de salida del aparato de conmutación, la información proporcionada por el plano de control llena la tabla de envío de los datos con la información de dirección agregada que comprende una combinación de los valores de campo de cabecera asociados a un puerto de salida del aparato de conmutación.
10. Un aparato de conmutación de conformidad con la reivindicación 9, en donde la información de dirección agregada comprende por lo menos una dirección localmente única y por lo menos una dirección globalmente única, y en donde el plano de control proporciona la información para enrutar el tráfico recibido a una dirección globalmente única a lo largo de una trayectoria dependiente de una o más direcciones localmente únicas.
11. Un aparato de conmutación de conformidad con cualquiera de las reivindicaciones 9 a 10, en donde la información de dirección agregada comprende la información extraída de uno o más campos en un cabecera de un paquete recibido por el aparato de conmutación que está asociado a un puerto de salida del aparato de conmutación mediante el plano de control, mediante el cual el aparato de conmutación está configurado para reenviar la trama recibida a un puerto de salida del aparato de conmutación en base a uno o más de los siguientes campos del paquete recibido de acuerdo al protocolo de comunicaciones sin conexión: uno o más campos de dirección de destino; uno o más campos de dirección de fuente; uno o más campos de dirección de ruta de fuente; uno o más campos Ethertype; uno o más campos de prioridad; uno o más campos de tipo de servicio; uno o más campos del identificador de flujo; y uno o más campos capaces de identificar una red privada virtual; uno o más campos de protocolo; uno o más campos del identificador de puerto de destino TCP/UDP; uno o más campos del identificador de puerto de fuente de TCP/UDP.
12. Un aparato de conmutación de conformidad con la reivindicación 9, en donde el tráfico comprende los paquetes IP y la dirección agregada comprende un conjunto de direcciones IP e información de enmascaramiento de dirección apropiada asociada a un puerto de salida del aparato de conmutación, y en donde para cada dirección agregada, una sub-red IP proporciona una dirección de destino y la dirección dentro de cada sub-red identifica únicamente una trayectoria a través de la red de comunicaciones.
13. Un aparato de conmutación de conformidad con la reivindicación 9, en donde la dirección globalmente significativa es proporcionada por una combinación de datos almacenados en los campos de cabecera del tráfico recibido, y en donde la información de dirección agregada localmente significativa comprende una dirección de hardware.
14. Un aparato de conmutación de conformidad con la reivindicación 9, en donde el plano de control proporciona además del agregado de dirección, un identificador de trayectoria único que comprende un identificador de puerto TCP/UDP asociado a un dirección IP, el identificador de puerto TCP/UDP está asociado por el plano de control a un puerto de salida del aparato de conmutación.
15. Un aparato de conmutación de conformidad con la reivindicación 9, en donde el plano de control proporciona la tabla de envío con una ruta IPv6 asociada a un puerto de salida del aparato de conmutación, y el identificador de trayectoria única comprende el identificador de flujo de una dirección IPv6.
16. Un aparato de conmutación de conformidad con cualquiera de las reivindicaciones 1 a 11, en donde el protocolo sin conexión comprende Ethernet.
17. Un aparato de conmutación de conformidad con la reivindicación 16, en donde la información de dirección localmente única comprende uno o más campos de cabecera de MAC.
18. Un aparato de conmutación de conformidad con cualquiera de las reivindicaciones anteriores, en donde el aparato de conmutación está configurado para que sea capaz de reactivar el modo de operación sin conexión de los puertos de salida activando la funcionalidad que es capaz de configurar las tablas de envío de datos del aparato de conmutación para operar en un modo sin conexión al recibir la señalización apropiada del plano de control.
19. Un aparato de conmutación de conformidad con cualquiera de las reivindicaciones 1 a 18, que adicionalmente comprende: medios para extraer la información de cabecera de la cabecera de cada paquete recibido; medios para realizar una operación de búsqueda para determinar si la información de cabecera extraída iguala la información de envío almacenada, la información de envío está configurada para proporcionar una función de envío de datos para cada paquete recibido dependiente de la información de cabecera extraída; en donde la información recibida de la fuente del plano de control es procesada por el aparato de conmutación para llenar el medio de almacenamiento de datos para almacenar la información de envío para permitir que la fuente del plano de control controle la funcionalidad de envío de datos de conexión orientada, cuyo aparato de conmutación funciona en cada paquete recibido.
20. Un aparato de conmutación de conformidad con cualquiera de las reivindicaciones 1 a 19, en donde el aparato de conmutación opera en una red de comunicaciones, y proporciona previamente solamente un servicio sin conexión en la red de comunicaciones.
21. Un aparato de conmutación de conformidad con cualquiera de las reivindicaciones 1 a 19, en donde proporciona un servicio de punto-a-multi-punto transparente en la red de comunicaciones.
22. Un aparato de conmutación de conformidad con cualquiera de las reivindicaciones 1 a 19, en donde proporciona un servicio de punto-a-multi-punto transparente en la red de comunicaciones.
23. Un aparato de conmutación de conformidad con cualquiera de las reivindicaciones 18 a 22, en donde un campo en una cabecera de un paquete recibido por el aparato de conmutación se asocia a un puerto de salida del aparato de conmutación, y el aparato de conmutación reenvía la trama recibida a un puerto de salida del aparato de conmutación en base a uno o más de los siguientes campos del paquete recibido de acuerdo a un protocolo de comunicaciones sin conexión: uno o más campos de dirección de destino; uno o más campos de dirección de fuente; uno o más campos de dirección de ruta de fuente; uno o más campos Ethertype; uno o más campos de prioridad; uno o más campos de tipo de servicio; uno o más campos del identificador de flujo; y uno o más campos capaces de identificar una red privada virtual; uno o más campos de protocolo; uno o más campos del identificador de puerto de destino TCP/UDP; uno o más campos del identificador de puerto de fuente de TCP/UDP.
24. Un aparato de conmutación de conformidad con la reivindicación 23, en donde recibió encapsulada la cabecera de un paquete recibido dentro de una o más de otras cabeceras.
25. Un aparato de conmutación de conformidad con la reivindicación 24, en donde el paquete recibido comprende un paquete IP que tiene un cabecera de paquete IP que incluye la primera información de dirección IP encapsulada en una segunda cabecera de paquete IP que comprende la segunda información de dirección IP.
26. Un aparato de conmutación de conformidad con cualquiera de las reivindicaciones anteriores, en donde la información relacionada a una conexión proporcionada por el aparato de conmutación en la red de comunicaciones se proporciona solamente dentro del plano de control de la red de comunicaciones.
27. Un método para modificar el aparato de conmutación operado en una red de comunicaciones para proporcionar un servicio sin conexión en la red de comunicaciones, en donde el método comprende la etapa de deshabilitar la funcionalidad de envío de datos del aparato de conmutación para usar la información calculada de los protocolos de enrutamiento sin conexión a modo de implementar el enrutamiento sin conexión, y en donde la información que llena la tabla de envío es proporcionada por el plano de control del aparato de conmutación, en donde la información proporcionada permite que el aparato de conmutación implemente su funcionalidad de envío de datos para recibir los paquetes.
28. Un método para modificar el aparato de conmutación de conformidad con la reivindicación 27, en donde en la etapa de deshabilitar la funcionalidad de envío de datos, las direcciones IP del aparato de conmutación se conservan en cada tabla de envío en un modo sin conexión normal, y en donde el protocolo de transporte y enrutamiento del plano de control que incluye el auto-descubrimiento se implementa en un modo sin conexión.
29. Un método para modificar el aparato de conmutación operado en una red de comunicaciones para proporcionar un servicio sin conexión en la red de comunicaciones, en donde el método comprende la etapa de envío de datos de prevención en un modo sin conexión llenando la tabla de envió con las entradas de conexión orientada que se originan en las entradas de envío sin conexión, y en donde la información que llena la tabla de envío es proporcionada por el plano de control del aparato de conmutación, en donde la información proporcionada permite que el apa rato de conmutación impl emente su fu ncionalidad de envío de datos para recibir los paq uetes .
30. U n método para con muta r los paquetes en u na red de comunicaciones q ue comprend e u na plu ralidad de apa ratos de conmutación interconectados, e l método comprende: la recepción de paquetes en un aparato de conmutación conectado a la red de comunicaciones, el envío de los paq uetes en u n aparato de con mutación llenando u n almacenamiento de datos configu rado para asociar la información proporcionada en por lo menos un campo de la cabecera de un paquete reci bido a un puerto de salida del aparato de conmutación usando la información proporcionada por uno o más de los procesadores del plano de control asociados al aparato de conmutación , uno o más procesadores del plano de control comprenden el plano de control de la red de comunicaciones, mediante los cuales la fu ncionalidad de envío de datos y/o de filtración de ruta del aparato de conmutación el controlada por el plano de control de la red de comunicaciones.
31 . U na red de comu nicaciones que comprende una pluralidad de aparatos de conmutación interconectados para proporcionar el transporte de datos conmutables entre las fuentes de datos y receptores de datos , en donde las funciones de envío de datos y filtración de datos que cada aparato conmutador realiza en los paquetes recibidos, son controladas por un plano de control q ue comprende uno o más procesadores del plano de control, el plano de control que proporciona cada aparato conmutador con datos de control que permiten que el aparato de conmutación implemente su funcionalidad de envío de datos y filtración de datos en los paquetes recibidos, los paquetes recibidos incluyen la información de cabecera que tiene información de dirección de acuerdo a un protocolo sin conexión, los datos de control permiten que los aparatos conmutadores proporcionen un servicio de conexión orientada para los paquetes recibidos.
32. Un procesador del plano de control configurado para proporcionar el aparato de conmutación de conformidad con cualquiera de las reivindicaciones 1 a 26 con los datos de control, los datos de control permite que el aparato de conmutación implemente su funcionalidad envío de datos y de filtración de datos en los paquetes recibidos.
33. Una red de comunicaciones que comprende una pluralidad de aparatos de conmutación interconectados de conformidad con cualquiera de las reivindicaciones 1 a 26.
34. Una red de conformidad con la reivindicación 33, en donde los datos de control generados por el plano de control se transmiten fuera de la banda a cada aparato de conmutación.
35. Una red de conformidad con cualquiera de las reivindicaciones 33 a 34, en donde el plano de control de la red de comunicaciones establece una pluralidad de trayectorias para un flujo de tráfico de por lo menos una fuente de datos a por lo menos un receptor de datos a través de la red.
36. Un método para proporcionar el servicio de diferenciación en una red de comunicaciones reconfigurando un aparato de conmutación capaz de proporcionar un servicio sin conexión para proporcionar un servicio de conexión orientada, el método comprende las etapas de: deshabilitar toda la funcionalidad de envío de datos preconfigurada y de filtración de datos preconfigurada del aparato de conmutación; proporcionar toda la información de enrutamiento requerida para el envío de un paquete recibido desde una fuente de datos localizada sin conmutar vía una interfaz de control para el aparato de conmutación, en donde la información de enrutamiento remplaza la información proporcionada previamente por los protocolos sin conexión soportados por el aparato de conmutación, en donde la ruta determinada para cada flujo de tráfico es dependiente de una característica de flujo de tráfico.
37. Un método de conformidad con la reivindicación 36, en donde cada ruta es dependiente de una característica que comprende la calidad de servicio solicitada para el flujo de tráfico.
38. Un método de conformidad con la reivindicación 36, en donde la característica es la prioridad del flujo de tráfico.
39. Un método de conformidad con la reivindicación 37, en donde la característica es la banda ancha requerida para el flujo de tráfico.
40. Un método de conformidad con la reivindicación 37, en donde la característica es Ethertype del flujo de tráfico.
41. Un método de conformidad con la reivindicación 37, en donde la característica es la cabecera de control del vínculo lógico (LLC) para el flujo de tráfico.
42. Un método para seleccionar una trayectoria en una red de comunicaciones para balancear la carga de tráfico en la red, el método comprende las etapas de: identificar un flujo de tráfico que llega al aparato de conmutación, en donde el aparato de conmutación se ha reconfigurado para proporcionar un servicio de conexión orientada a través de una red de comunicaciones en lugar de un servicio sin conexión, asociar el flujo de tráfico a un identificador de conexión individual; asociar el identificador de conexión individual a la información del campo de cabecera adicional para proporcionar un identificador global para la flujo de tráfico; determinar usando el plano de control a una trayectoria para identificar globalmente el flujo, y proporcionar la información a una pluralidad de aparatos de conmutación reconfigurado dentro de la red de comunicaciones para permitir que una pluralidad de trayectorias se determine para cada flujo de tráfico, en donde una o más de la pluralidad de trayectorias es seleccionada por el procesador del plano de control.
43. Un método de conformidad con la reivindicación 42, en donde el tráfico es el tráfico de Ethernet y el identificador de conexión individual comprende un identificador de red de área local virtual.
44. Un método de conformidad con la reivindicación 42, en donde el tráfico es el tráfico IP.
45. Un método para generar una conexión extremo-a-extremo en una red de comunicaciones que comprende una pluralidad de aparatos de conmutación preconfigurados para soportar los protocolos de comunicaciones sin conexión, el método comprende las etapas de: reconfigurar el aparato de conmutación mediante: deshabilitar cualquier funcionalidad que soporte el envío de un flujo de tráfico de comunicaciones recibido usando el protocolo de comunicaciones sin conexión; permitir la funcionalidad que soporte le envío de un flujo de tráfico de comunicaciones recibido usando un protocolo de comunicaciones de conexión orientada; determinar una trayectoria para la conexión extremo-a- extremo de una fuente a un receptor para el flujo de tráfico; comunicar la trayectoria vía una interfaz de control para proporcionar la información de enrutamiento para la flujo de tráfico recibido, mediante la cual la funcionalidad de permiso reenvía el flujo de tráfico recibido hacia el receptor a través de la red de comunicaciones.
46. Un método de conformidad con la reivindicación 41, en donde la etapa de permitir que la funcionalidad soporte un protocolo de comunicaciones de conexión orientada se proporcione vía una interfaz de control al aparato de conmutación.
47. En una red de comunicaciones que comprende una pluralidad de redes de área local interconectadas por una red de área amplia, un método para proporcionar los modos de envío diferenciados para empaquetar los datos recibidos de la primera de una pluralidad de LANs a una segunda de la pluralidad de LANs, el método comprende: en un primer aparato configurado para proporcionar los datos de la primera LAN con acceso a la WAN, realizando una operación de búsqueda en una pluralidad de campos de cabecera para los datos; determinar si cada uno de la pluralidad de campos de cabecera, se asocia a la información de enrutamiento almacenada en un almacenamiento de datos llenado por el plano de control del primer aparato; enrutar los datos a través de la red de área amplia a un segundo aparato configurado para proporcionar el acceso a los datos de la WAN a la segunda LAN de acuerdo con la información de enrutamiento proporcionada por el plano de control.
48. Un método de conformidad con la reivindicación 47, en donde los datos empaquetados comprenden una pluralidad de tramas Ethernet, y la pluralidad de campos de cabecera comprende por lo menos una tupia VLAN-ID/DA MAC, y en donde el primero y segundo aparatos de conmutación comprenden el primero y segundo conmutadores Ethernet de aprendizaje de VLAN independientes, respectivamente.
49. Un método de conformidad con la reivindicación 48, en donde el primero y segundo aparatos de conmutación de Ethernet de aprendizaje de VLAN independientes están interconectados por una secuencia contigua del aparato de conmutación de Ethernet de aprendizaje de VLAN independiente configurado para reenviar las tramas Ethernet recibidas en las VLAN-IDs localmente significativas para formar una conexión unidireccional.
50. Un método de conformidad con la reivindicación 49, en donde la información de enrutamiento proporcionada por el plano de control adicionalmente proporciona una trayectoria inversa entre el segundo conmutador Ethernet y el primer conmutador Ethernet para proporcionar la conectividad bidireccional entre el primer y segundo aparatos de conmutación de Ethernet.
51. Un aparato de conmutación de Ethernet configurado para recibir los datos recibidos de un procesador del plano de control para controlar las funciones de envío de datos y de filtración de datos que el aparato de conmutación realiza en el tráfico de Ethernet recibido.
52. Un aparato de conmutación de Ethernet de conformidad con la reivindicación 51, en donde el plano de control instala las conexiones y llena una o más tablas de transición en el aparato de conmutación a modo que el aparato de conmutación de Ethernet tenga su funcionalidad de aprendizaje de dirección del Media Access Control deshabilitada y para que el protocolo del árbol extendido esté desactivado y así no se proporciona ninguna unidades de datos de protocolo de transición.
53. Un aparato de conmutación de Ethernet de conformidad con la reivindicación 51 ó 52, en donde el plano de control comprende un plano de control de conexión orientada configurado para controlar la tecnología del aparato de conmutación de Ethernet que se asume estará sin conexión y para convertir el comportamiento de la tecnología del aparato de conmutación de Ethernet.
54. Un procesador del plano de control configurado para proporcionar un aparato de conmutación de Ethernet con datos de control, los datos de control permiten que el aparato de conmutación de Ethernet implemente su funcionalidad de envío de datos y filtración de datos en el tráfico de Ethernet recibido.
55. Una red de comunicaciones que comprende una multiplicidad de aparatos de conmutación de Ethernet interconectados para proporcionar el transporte de datos conmutables entre las fuentes de datos y receptores de datos, en donde las funciones de envío de datos y filtración de datos que cada aparato de conmutación de Ethernet realiza en el tráfico de Ethernet recibido son controladas por un procesador del plano de control que proporciona cada aparato de conmutación de Ethernet con datos de control permitiendo que el aparato de conmutación de Ethernet implemente su funcionalidad de envío de datos y filtración de datos en el tráfico de Ethernet recibido.
56. Una red de comunicaciones que comprende una multiplicidad de aparatos de conmutación de Ethernet interconectados para proporcionar el transporte de datos conmutables entre las fuentes de datos y los receptores de datos, en donde las funciones de envío de datos y filtración de datos que todos los aparatos de conmutación de Ethernet realiza en el tráfico de Ethernet recibido en la red, son controladas colectivamente por un procesador del plano de control configurado para proporcionar los datos de control a todos los aparatos de conmutación de Ethernet para permitir que cada aparato de conmutación implemente su funcionalidad de envío de datos y filtración de datos en el tráfico de Ethernet recibido.
57. Una red de conformidad con la reivindicación 55 ó 56, en donde los datos de control generados por cada procesador del plano de control se transmiten fuera de la banda a cada aparato de conmutación de Ethernet.
58. Una red de conformidad con la reivindicación 57, en donde una VLAN se establece entre el aparato de conmutación de Ethernet para transmitir los datos de control.
59. Una red de conformidad con cualquiera de las reivindicaciones 55 a 58, en donde el plano de control establece una pluralidad de trayectorias para un flujo de tráfico de por lo menos una fuente de datos a por lo menos un receptor de datos.
60. Un aparato de conmutación de Ethernet de conformidad con cualquiera de las reivindicaciones 51 a 53, en donde la información proporcionada por el plano de control comprende por lo menos un tipo de identificador de índice para asociar el identificador a un puerto de salida del aparato de conmutación, el tipo del identificador que es un identificador de campo de cabecera del tráfico cuyo aparato de conmutación se configura para la recepción.
61. Un aparato de conmutación de Ethernet de conformidad con la reivindicación 60, en donde la información de envío proporcionada por el plano de control para una pluralidad de puertos de salida, comprende tipos de diferenciación de los identificadores de índice.
62. Un aparato de conmutación de Ethernet de conformidad con cualquiera de las reivindicaciones 60 ó 61, en donde el plano de control asigna un tipo de identificador de índice para implementar un esquema de balance de carga.
63. Un método para implementar un flujo de OAM a lo largo de una conexión de comunicaciones entre una fuente y un destino en una red de comunicaciones, el método comprende las etapas de: inyectar un flujo de tráfico empaquetado de un procesador adjunto a un primer aparato de conmutación, el flujo de tráfico empaquetado comprende el tráfico de OAM, en donde el tráfico de OAM tiene los tipos de valor de campo de etiqueta que son los mismos tipos de valor de campo de etiqueta que el flujo de tráfico del plano del usuario que fluye a lo largo de la conexión de comunicaciones; conmutar los paquetes de OAM para permitir que aparato de conmutación intermedio entre la fuente y el destino reenvié los paquetes de OAM como si fueran los paquetes del plano de usuario; recibir del flujo de tráfico empaquetado del plano del usuario y OAM en un segundo aparato de conmutación; separar los paquetes de OAM de los paquetes del plano de usuario; conmutar los paquetes de OAM en un procesador adjunto al aparato de conmutación final para procesarse mediante el aparato de conmutación de acuerdo a su funcionalidad estándar.
64. Un método de conformidad con la reivindicación 63, en donde el flujo de OAM se proporciona para el tráfico del plano de usuario de acuerdo a un protocolo de comunicaciones sin conexión y en donde el primer aparato de conmutación es configurado por el procesador adjunto para establecer una conexión al segundo aparato de conmutación en el extremo de la conexión para el tráfico del plano de usuario.
65. Un método de conformidad con la reivindicación 63 ó 64, en donde la etapa de separación de los paquetes de OAM de los paquetes del plano de usuario es realizada procesando la información de campo de cabecera en el segundo aparato de conmutación en el extremo de la conexión para determinar uno o más identificadores en la información de cabecera que indica que los paquetes recibidos son paquetes de OAM.
66. Un método de conformidad con la reivindicación 63 ó 64, en donde los paquetes de OAM contienen la información de cabecera que indica que su dirección de destino es el procesador adjunto asociado al segundo aparato de conmutación en el extremo de lá conexión por el que en el aparato de conmutación extremo, la etapa de separación de los paquetes de OAM de los paquetes del plano de usuario comprende el envío adicional de los paquetes de OAM al procesador del plano de control adjunto.
67. Un método de conformidad con cualquiera de las reivindicaciones 63 a 66, en donde es el flujo de tráfico empaquetado comprende un flujo de paquetes de 2 capas OSI.
68. Un método de conformidad con la reivindicación 67, en donde los paquetes de 2 capas OSI comprenden las tramas Ethernet.
69. Un método de conformidad con cualquiera de las reivindicaciones 63 a 66, en donde el flujo de tráfico empaquetado comprende un flujo de los paquetes de 3 capas OSI.
70. Un método de conformidad con la reivindicación 69, en donde los paquetes 3 capa OSI comprenden los paquetes Internet Protocol.
71. Un método de conformidad con cualquiera de las reivindicaciones 63 a 70, en donde un procesador del plano de control inyecta el OAM empaquetado a los aparatos de conmutación.
72. Un método de conformidad con cualquiera de las reivindicaciones 63 a 71, en donde el flujo de OAM se implementa según lo deseado.
73. Un método de conformidad con la reivindicación 72, en donde el flujo de OAM se implementa según se desee cuando una conexión se establezca mediante el plano de control para el tráfico recibido en el primer aparato de conmutación.
74. Un método para implementar un flujo de OAM en una red de comunicaciones, que comprende: inyectar las tramas Ethernet de un procesador adjunto a un conmutador Ethernet, las tramas Ethernet comprenden un flujo de OAM y el tráfico del plano de usuario, en donde el flujo de OAM tiene los valores del campo de etiqueta que son los mismos valores del campo de etiqueta que la conexión del plano de usuario para permitir que el aparato de conmutación de Ethernet intermedio conmute las tramas de OAM como si fueran las tramas de usuario; en el extremo de la conexión, la separación de las tramas de OAM de los tramas del plano de usuario; y la conmutación de las tramas de OAM en un procesador adjunto para procesarse mediante un conmutador Ethernet de acuerdo a su funcionalidad estándar.
75. Un aparato de conmutación de Ethernet capaz de proporcionar un servicio sin conexión en una red de comunicaciones, en donde la funcionalidad del aparato de conmutación de Ethernet es modificada por su plano de control para proporcionar un servicio de conexión orientada para por lo menos alguno de sus puertos, en donde un protocolo operacional, de administración, y de gestión (OAM) que soporta la funcionalidad de conexión orientada del aparato de conmutación de Ethernet se implementa usando un procesador que es diferente del procesador configurado para implementar el servicio de conexión orientada proporcionado por al menos alguno de los puertos del conmutador Ethernet para el tráfico distinto a OAM.
76. Un aparato de conmutación de Ethernet de conformidad con la reivindicación 75, en donde el hardware de procesamiento separado es soportado por una plataforma diferente de la plataforma que soporta la funcionalidad de conmutación del conmutador Ethernet para el tráfico distinto a OAM.
77. Un aparato de conmutación de Ethernet de conformidad con la reivindicación 75 ó 76, en donde el servicio de conexión orientada proporcionado por el conmutador Ethernet comprende un servicio punto-a-punto transparente.
78. Un aparato de conmutación de Ethernet de conformidad con la reivindicación 75 ó 76, en donde el servicio de conexión orientada proporcionado por el aparato de conmutación de Ethernet comprende un transparente servicio de punto-a-multi-puntos.
79. Un aparato de conmutación de Ethernet de conformidad con la reivindicación 77 ó 78, en donde el protocolo OAM se aplica al flujo agregado asociado a un flujo agregado asociado al servicio transparente ofrecido por el conmutador Ethernet.
80. Un sistema para implementar los protocolos operacionales, de administración, y de gestión (OAM) para el aparato de conmutación de Ethernet, el sistema comprende: una plataforma configurada para soportar el software configurado para proporcionar una operación de tipo OAM para el aparato de conmutación de Ethernet, en donde el aparato de conmutación de Ethernet se configura para proporcionar un servicio de punto-a-punto transparente.
81. Un sistema para implementar los protocolos operacionales, de administración, y gestión (OAM) para el aparato de conmutación de Ethernet, el sistema comprende: una plataforma configurada para soportar el software configurado para proporcionar una operación de tipo OAM para el aparato de conmutación de Ethernet, en donde el aparato de conmutación de Ethernet se configura para proporcionar un servicio punto-a-multi-puntos transparente.
82. Un sistema de conformidad con la reivindicación 80 ó 81, configurado para proporcionar un protocolo OAM para un flujo agregado asociado al servicio transparente proporcionado por el aparato de conmutación de Ethernet.
83. Un procesador configurado para proporcionar un protocolo operacional, de administración, y de gestión (OAM) para el aparato de conmutación en una red de comunicaciones, en donde una funcionalidad de envío de datos del aparato de conmutación es controlada por un plano de control para permitir que el aparato de conmutación reenvíe el tráfico de Ethernet recibido en una pluralidad de trayectorias a una destino en la red de comunicaciones, en donde el procesador OAM no proporciona la funcionalidad de envío de datos para el tráfico distinto a OAM recibido por el aparato de conmutación.
84. Un sistema de control de conmutador fuera-de-banda para un aparato de conmutación en una red de comunicaciones que comprende una pluralidad de aparatos de conmutación interconectados para proporcionar el transporte de datos conmutable las fuentes de datos y los receptores de datos, en donde la funcionalidad de envío de datos que cada aparato de conmutación realiza en el tráfico recibido es controlado fuera-de- banda por un procesador del plano de control que proporciona cada aparato de conmutación con datos de control se separados lógicamente de los datos enviados entre las fuentes de datos y los receptores de datos.
85. Un sistema de control de conmutador fuera-de-banda del de conformidad con la reivindicación 84, en donde el aparato de conmutación comprende el aparato de conmutación de Ethernet, y el tráfico comprende las tramas Ethernet.
86. Un sistema de control de conmutación fuera-de-banda de conformidad con la reivindicación 84, en donde el aparato de conmutación comprende un enrutador IP, y el tráfico comprende los paquetes IP.
87. Un esquema del control de conmutador fuera-de-banda de conformidad con cualquiera de las reivindicaciones 84 ó 85, en donde los datos de control se comunican a cada aparato de conmutación usando una red de área local virtual.
88. Un esquema de control de conmutador fuera-de-banda de conformidad con cualquiera de las reivindicaciones 84 a 87, en donde unas o más redes virtuales proporcionadas en la red de comunicaciones se utilizan para transportar la información de control al aparato de conmutación que forma la red de comunicaciones.
89. Un esquema de control de conmutador fuera-de-banda de conformidad con cualquiera de las reivindicaciones 84 a 87, en donde un procesador del plano de control en la red de comunicaciones proporciona los datos de control a una pluralidad de aparatos de conmutación.
90. Un aparato de conmutación configurado para recibir los datos de control del conmutador fuera-de-banda de un procesador del plano de control de acuerdo a un esquema de control de conmutador fuera-de-banda de conformidad con cualquiera de las reivindicaciones 84 a 89, en donde los datos de control recibidos permiten que el conmutador implemente su funcionalidad de envío de datos en el tráfico recibido.
91. Un aparato de conmutación configurado para recibir los datos de control de conmutador fuera-de-banda de un procesador del plano de control de acuerdo a un esquema de control de conmutador fuera-de-banda de conformidad con cualquiera de las reivindicaciones 84 a 89, en donde el aparato de conmutación comprende los datos de control recibidos por el aparato de conmutación de Ethernet permitiendo que el conmutador implemente su funcionalidad de envío de datos y filtración de datos en el tráfico de Ethernet recibido.
92. Un aparato de conmutación de conformidad con la reivindicación 91, en donde el aparato de conmutación de Ethernet comprende: un almacenamiento de datos configurado para reenviar el tráfico de Ethernet recibido en la red de comunicaciones a los puertos de salida del aparato de conmutación, el almacenamiento de datos comprende una pluralidad de registros de datos, cada registro de datos que asocia una trama Ethernet recibida a un puerto de salida del aparato de conmutación se basa en la información extraída de la cabecera de la trama Ethernet recibida; medios para llenar los registros del almacenamiento de datos con la información proporcionada por un procesador del plano de control del aparato de conmutación, mediante el cual la funcionalidad de envío de datos del aparato de conmutación de Ethernet es controlada por el plano de control de la red de comunicaciones.
93. Un aparato de conmutación de conformidad con la reivindicación 92, en donde la información proporcionada por el plano de control comprende por lo menos un identificador de índice asociado a un puerto de salida, el tipo de identificador de índice es el tipo de ¡dentificador del aparato de conmutación que es capaz de extraer de la cabecera de una trama Ethernet recibida.
94. Aparato de conmutación de conformidad con cualquiera de las reivindicaciones 91 a 93, en donde el aparato de conmutación comprende el aparato de conmutación de Ethernet operado en una red de comunicaciones, en donde el aparato de conmutación de Ethernet proporcionó previamente solo un servicio Ethernet sin conexión en la red de comunicaciones.
95. Un aparato de conmutación configurado para recibir los datos de control de conmutador fuera-de-banda de un procesador del plano de control de acuerdo a un esquema de control de conmutador fuera-de-banda de conformidad con cualquiera de las reivindicaciones 84 a 89, en donde el aparato de conmutación comprende los datos de control recibidos por el aparato de conmutación Internet Protocol (IP) perdiendo que el conmutador implemente su funcionalidad de envío de datos y filtración de datos en el tráfico recibido Internet Protocol (IP).
96. Un aparato de conmutación de conformidad con la reivindicación 95, en donde el aparato de conmutación Internet Protocol (IP) comprende: un almacenamiento de datos configurado para reenviar el tráfico del Internet Protocol (IP) recibido en la red de comunicaciones a los puertos de salida del aparato de conmutación, el almacenamiento de datos comprende una pluralidad de registros de datos, cada registro de datos que asocia un paquete Internet Protocol (IP) recibido a un puerto de salida del aparato de conmutación se basa en la información extraída de la cabecera del paquetelnternet Protocol (IP) recibido; y los medios para llenar los registros del almacenamiento de datos con la información proporcionada por un procesador del plano de control del aparato de conmutación, por el cual la funcionalidad de envío de datos del aparato de conmutación Internet Protocol (IP) es controlada por el plano de control de la red de comunicaciones.
97. Aparato de conmutación de conformidad con cualquiera de las reivindicaciones 95 a 96, en donde el aparato de conmutación comprende el aparato de conmutación Internet Protocol (IP) operado en una red de comunicaciones, en donde el aparato de conmutación Internet Protocol (IP) proporcionó previamente solo un servicio Internet Protocol (IP) sin conexión en la red de comunicaciones.
98. Aparato de conmutación de conformidad con cualquiera de las reivindicaciones 90 a 97, en donde el aparato de conmutación proporciona un servicio punto-a-punto transparente en la red de comunicaciones.
99. Aparato de conmutación de conformidad con cualquiera de las reivindicaciones 90 a 97, en donde el aparato de conmutación proporciona un servicio de punto-a-mutli-punto transparente en la red de comunicaciones.
100. El aparato de conmutación de conformidad con cualquiera de las reivindicaciones 90 a 97, en donde un campo en un cabecera de una trama o paquete de tráfico recibido por el aparato de conmutación se asocia a un puerto de salida del aparato de conmutación, y el aparato de conmutación reenvía la trama o paquete recibida a un puerto de salida del aparato de' conmutación en base a uno o más de los siguientes campos: uno o más campos de dirección de destino globalmente únicos; uno o más campos de dirección de fuente globalmente únicos; uno o más campos de dirección de destino localmente únicos; uno o más campos de dirección de fuente localmente únicos; uno o más campos Ethertype; uno o más campos de identificador de flujo IPV6; uno o más campos de prioridad; y uno o más campos VLAN-ID.
101. El aparato de conmutación de conformidad con la reivindicación 100, en donde la trama o paquete recibido encapsula la trama o paquete localmente único a la red de área local de fuente para la trama o paquete recibido.
102. Aparato de conmutación de conformidad con cualquiera de las reivindicaciones 90 a 101, en donde el aparato de conmutación se configura para reenviar un trama o paquete recibido vía un puerto de salida del aparato de conmutación configurado para proporcionar un servicio sin conexión o vía un puerto de salida configurado para proporcionar un servicio de conexión orientada, en dependencia de la información contenida dentro de la cabecera de la trama o paquete recibido.
103. Un procesador del plano de control configurado para proporcionar el aparato de conmutación de conformidad con cualquiera de las reivindicaciones 90 a 102 con los datos de control de conmutador fuera-de-banda de acuerdo a un esquema de control de conmutador fuera-de-banda de conformidad con cualquiera de las reivindicaciones 1 a 6, los datos de control recibidos permiten que el conmutador implemente su funcionalidad de envío y filtración de datos en las tramas o paquetes de tráfico recibido.
104. Una red de comunicaciones que comprende una pluralidad de aparatos de conmutación de conformidad con cualquiera de las reivindicaciones 90 a 102, el aparato de conmutación está interconectado para proporcionar el transporte de datos conmutables entre las fuentes de datos y receptores de datos, la red de comunicaciones proporciona un sistema de control fuera-de-banda para cada una de la multiplicidad de pluralidad de conmutadores Ethernet.
105. Un método para generar una red de área local virtual para llevar el tráfico del plano de control entre una pluralidad de aparatos de conmutación en una red de comunicaciones, el método comprende: configurar en cada uno de la pluralidad de aparatos de conmutación por lo menos un puerto que se asociará VLAN que lleva el tráfico del plano de control; recibir en el plano de control de conmutador la señalización de un procesador del plano de control se asoció al aparato de conmutación; reenviar en el puerto asociado a VLAN el tráfico de señalización del plano de control a cada uno de la pluralidad de aparatos de conmutación que tiene un puerto configurado para el tráfico VLAN, mediante lo cual cuando la señalización del plano de control es un destino de uno de la pluralidad de aparatos de conmutación, el aparato de conmutación se configura para que sea capaz de comunicar la señalización del plano de control con un procesador del plano de control dentro del cual se asocia el aparato de conmutación.
106. Un método para permitir que un plano de control descubra automáticamente la interconectividad de una pluralidad de aparatos de conmutación en una red de comunicaciones, el aparato de conmutación de conmutación está reconfigurado para proporcionar el soporte para los modos orientados a la conexión de la comunicación haciendo que tengan toda la funcionalidad para soportar los modos sin conexión de comunicación deshabilitados, el método comprende las etapas de: rehabilitar un modo sin conexión en una división de por lo menos uno de los aparatos de conmutación exclusivos para la gestión y control de la información; emitir los mensajes del plano de control difundiéndolos a través de la división de la gestión; recibir por lo menos uno de los mensajes en un aparato de conmutación existente al final de un nuevo vínculo y/o en un nuevo aparato de conmutación de la red de comunicaciones; responder a por lo menos un mensaje recibió en el aparato de conmutación existente o nuevo comunicándose con el plano de control, la comunicación permite que el descubrimiento de la interconectividad del aparato de conmutación nuevo y/o del nuevo vínculo.
107. Un método para establecer una conexión de gestión en una red de comunicaciones, que comprende las etapas de: generar en primer lugar una red de área local virtual para llevar el tráfico de gestión de conformidad con la reivindicación 105; y descubrir en segundo lugar la conectividad entre el aparato de conmutación usando el método de conformidad con la reivindicación 106.
108. Un método para configurar el aparato de conmutación para recibir la información de gestión y/o señalización que comprende las etapas de: retener una funcionalidad de difusión en uno o más puertos específicos del aparato de conmutación, deshabilitar toda la funcionalidad preexistente que soporta los protocolos sin conexión preconfigurados de otros puertos del aparato de conmutación, los otros puertos están reconfigurados por la información derivada de la información de gestión y señalización recibida en uno o más puertos específicos para proporcionar uno o más modos orientados a la conexión de transporte para el tráfico recibido en otros puertos, el tráfico fue recibido en otros puertos de acuerdo un protocolo de comunicaciones sin conexión, mediante el cual, uno o más puertos específicos del aparato de conmutación se configuran para aislar lógicamente la información recibida de gestión y/o señalización del otro tráfico recibido por el aparato de conmutación.
109. Un método para configurar el aparato de conmutación de conformidad con la reivindicación 108, en donde la funcionalidad de difusión conservada permite que el aparato de conmutación reenvié el tráfico recibido de gestión y señalización de una manera sin conexión.
110. Un método para configurar el aparato de conmutación de conformidad con la reivindicación 108 ó 109, en donde el aparato de conmutación aisla lógicamente la información recibida de gestión y/o señalización asociando un identificador extraído de la cabecera de un paquete o trama que lleva la información con uno o más puertos específicos del aparato de conmutación.
111. Un esquema de comunicaciones para configurar una red que comprende una pluralidad de aparatos de conmutación conectados, cada aparato de conmutación tiene la funcionalidad para implementar el envío sin conexión del tráfico de comunicaciones recibido para proporcionar selectivamente un servicio de conexión orientada para el tráfico de comunicaciones recibido, el esquema compre: determinar los valores del campo de cabecera de índice para identificar el tráfico recibido en el aparato de conmutación para que una conexión se establezca entre un nodo de fuente y un nodo de destino; proporcionar cada aparato de conmutación necesario para ¡mplementar la conexión con la información que permite que sus tablas de envío de datos sean llenadas con los valores del campo de cabecera de índice en asociación con los puertos de salida del aparato de conmutación; y deshabilitar el resto de la funcionalidad en el aparato de conmutación capaz de llenar las tablas de envío de datos con la información de índice asociada a los puertos de la salida del aparato de conmutación necesario para establecer la conexión.
112. Un esquema de comunicaciones de conformidad con la reivindicación 111, en donde una pluralidad de los tipos de diferenciación de los valores del campo de cabecera de índice se proporciona mediante el plano de control.
113. Un esquema de comunicaciones de conformidad con la reivindicación 112, en donde los tipos de diferenciación de los valores del campo de cabecera de índice se configuran jerárquicamente, y los niveles diferentes de la jerarquía se asocian a diferentes puertos de salida del aparato de conmutación.
MX2007008112A 2004-12-31 2005-12-30 Metodo para ejecutar una red sin conexion como una red de conexion orientada. MX2007008112A (es)

Applications Claiming Priority (9)

Application Number Priority Date Filing Date Title
GB0428541A GB0428541D0 (en) 2004-12-31 2004-12-31 Out-of-band switch control
GB0428542A GB0428542D0 (en) 2004-12-31 2004-12-31 Communications network
GB0502036A GB0502036D0 (en) 2005-02-01 2005-02-01 Communications network
GB0502038A GB0502038D0 (en) 2005-02-01 2005-02-01 Out-of band switch control
GB0502039A GB0502039D0 (en) 2005-02-01 2005-02-01 Oam in a communications network
EP05252276 2005-04-12
GB0518450A GB0518450D0 (en) 2005-09-09 2005-09-09 Communications network
GB0518850A GB0518850D0 (en) 2005-09-15 2005-09-15 Communications network
PCT/GB2005/005100 WO2006070197A2 (en) 2004-12-31 2005-12-30 Method to run a connectionless network as a connection oriented network

Publications (1)

Publication Number Publication Date
MX2007008112A true MX2007008112A (es) 2007-10-19

Family

ID=36000807

Family Applications (1)

Application Number Title Priority Date Filing Date
MX2007008112A MX2007008112A (es) 2004-12-31 2005-12-30 Metodo para ejecutar una red sin conexion como una red de conexion orientada.

Country Status (9)

Country Link
US (1) US20080049621A1 (es)
EP (1) EP1832068A2 (es)
JP (1) JP2008527772A (es)
KR (1) KR20070095374A (es)
AU (1) AU2005321093A1 (es)
BR (1) BRPI0519612A2 (es)
CA (1) CA2590669A1 (es)
MX (1) MX2007008112A (es)
WO (1) WO2006070197A2 (es)

Families Citing this family (313)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050220096A1 (en) 2004-04-06 2005-10-06 Robert Friskney Traffic engineering in frame-based carrier networks
US8923292B2 (en) 2004-04-06 2014-12-30 Rockstar Consortium Us Lp Differential forwarding in address-based carrier networks
US8085662B2 (en) 2008-05-14 2011-12-27 Hewlett-Packard Company Open network connections
US20070189273A1 (en) * 2006-02-10 2007-08-16 3Com Corporation Bi-planar network architecture
EP1891538A4 (en) * 2005-05-11 2009-01-21 Bigfoot Networks Inc SYSTEM AND METHOD FOR DISTRIBUTED PROCESSING
US8498297B2 (en) * 2005-08-26 2013-07-30 Rockstar Consortium Us Lp Forwarding table minimisation in ethernet switches
US20070060373A1 (en) * 2005-09-12 2007-03-15 Bigfoot Networks, Inc. Data communication system and methods
US9455844B2 (en) * 2005-09-30 2016-09-27 Qualcomm Incorporated Distributed processing system and method
US8873555B1 (en) * 2006-02-02 2014-10-28 Marvell Israel (M.I.S.L.) Ltd. Privilege-based access admission table
US8892706B1 (en) 2010-06-21 2014-11-18 Vmware, Inc. Private ethernet overlay networks over a shared ethernet in a virtual environment
US8924524B2 (en) 2009-07-27 2014-12-30 Vmware, Inc. Automated network configuration of virtual machines in a virtual lab data environment
US8619771B2 (en) 2009-09-30 2013-12-31 Vmware, Inc. Private allocated networks over shared communications infrastructure
US9294477B1 (en) * 2006-05-04 2016-03-22 Sprint Communications Company L.P. Media access control address security
US7783686B2 (en) * 2006-06-16 2010-08-24 Microsoft Corporation Application program interface to manage media files
US7603387B2 (en) * 2006-06-16 2009-10-13 Microsoft Corporation Techniques to manage media files
CN101507194B (zh) * 2006-06-27 2012-08-15 艾利森电话股份有限公司 桥接的以太网中的强制介质访问控制(mac)学习
US8379644B1 (en) * 2006-06-30 2013-02-19 Marvell International Ltd. System and method of processing management frames
US8874780B2 (en) * 2006-07-17 2014-10-28 Qualcomm Incorporated Data buffering and notification system and methods thereof
US8683045B2 (en) * 2006-07-17 2014-03-25 Qualcomm Incorporated Intermediate network device for host-client communication
KR100754649B1 (ko) * 2006-07-24 2007-09-05 삼성전자주식회사 브리지 기반 무선 기지국 기간망 시스템 및 그 신호 처리방법
DE102006036565A1 (de) * 2006-08-04 2008-02-07 Siemens Ag Verfahren zur paketvermittelten Datenübertragung in einem Kommunikationsnetz
CN101127696B (zh) * 2006-08-15 2012-06-27 华为技术有限公司 二层网络中的数据转发方法和网络及节点设备
IL177974A (en) * 2006-09-10 2011-06-30 Tejas Israel Ltd Method and system for relaying frames through an ethernet network and bridge therefor
US7653057B1 (en) * 2006-11-30 2010-01-26 World Wide Packets, Inc. Preventing forwarding of a packet to a control plane
US7961737B2 (en) * 2006-12-21 2011-06-14 Alcatel Lucent Ethernet/TMPLS hybrid network operation administration and maintenance frame creation method
EP1947803B1 (en) * 2007-01-22 2017-07-19 Nokia Solutions and Networks GmbH & Co. KG Operation of network entities in a communications system
US8787170B2 (en) * 2007-01-24 2014-07-22 Ciena Corporation Methods and systems for existential provisioning of flexible line modules using distributed control
KR101443939B1 (ko) * 2007-01-26 2014-09-23 퀄컴 인코포레이티드 통신 소켓 상태 모니터링 시스템 및 방법들
EP2140350B1 (en) 2007-03-23 2017-04-05 Qualcomm Incorporated Distributed processing method and computer program product
KR20100015846A (ko) 2007-03-26 2010-02-12 빅풋 네트웍스, 인크. 노드들 간의 통신을 위한 방법 및 시스템
EP1976195B1 (en) * 2007-03-30 2014-05-07 Alcatel-Lucent Method and apparatus for Mac address learning
US7969888B2 (en) * 2007-04-27 2011-06-28 Futurewei Technologies, Inc. Data communications network for the management of an ethernet transport network
US8140654B2 (en) * 2007-04-27 2012-03-20 Futurewei Technologies, Inc. Verifying management virtual local area network identifier provisioning consistency
US20080267080A1 (en) * 2007-04-27 2008-10-30 Futurewei Technologies, Inc. Fault Verification for an Unpaired Unidirectional Switched-Path
US7724673B2 (en) 2007-05-30 2010-05-25 Alcatel Lucent Apparatus and methods of determining configurations for handling communication path management traffic
EP2181393A4 (en) * 2007-07-20 2013-08-21 Qualcomm Inc DEVICE AND METHOD FOR CLIENT AUTHENTICATION
WO2009014951A1 (en) * 2007-07-20 2009-01-29 Bigfoot Networks, Inc. Remote access diagnostic device and methods thereof
US8166205B2 (en) * 2007-07-31 2012-04-24 Cisco Technology, Inc. Overlay transport virtualization
WO2009036804A1 (en) * 2007-09-20 2009-03-26 Telefonaktiebolaget L M Ericsson (Publ) Policy routing in a communications network
EP2193630B1 (en) * 2007-09-26 2015-08-26 Nicira, Inc. Network operating system for managing and securing networks
US7817547B2 (en) * 2007-10-02 2010-10-19 Microsoft Corporation Uncovering the differences in backbone networks
US8339965B2 (en) * 2007-10-02 2012-12-25 Microsoft Corporation Uncovering the differences in backbone networks
US20090086754A1 (en) * 2007-10-02 2009-04-02 Futurewei Technologies, Inc. Content Aware Connection Transport
CN100531101C (zh) * 2007-10-22 2009-08-19 华为技术有限公司 一种实现端到端的QinQ业务标签自动分配的方法和装置
US8279871B1 (en) * 2007-10-29 2012-10-02 Marvell Israel (M.I.S.L.) Ltd. Methods and apparatus for processing multi-headed packets
WO2009070713A1 (en) 2007-11-29 2009-06-04 Bigfoot Networks, Inc. Remote message routing device and methods thereof
JP5018457B2 (ja) * 2007-12-21 2012-09-05 富士通株式会社 データ送受信装置、保守管理データ挿入抽出装置、保守管理データ挿入抽出プログラムおよび保守管理データ挿入抽出方法
US9432213B2 (en) 2007-12-31 2016-08-30 Rpx Clearinghouse Llc IP forwarding across a link state protocol controlled ethernet network
US8923285B2 (en) * 2008-04-30 2014-12-30 Qualcomm Incorporated Apparatus and methods for transmitting data over a wireless mesh network
US8290367B2 (en) * 2008-04-14 2012-10-16 Telcordia Technologies, Inc. OSS support for control plane technology
US8195774B2 (en) 2008-05-23 2012-06-05 Vmware, Inc. Distributed virtual switch for virtualized computer systems
US8503305B2 (en) * 2008-06-03 2013-08-06 Tejas Israel Ltd Automatic signaling method and device for telecommunication services
US20090304010A1 (en) * 2008-06-06 2009-12-10 Nec Corpoation Of America Network element providing an interworking function between plural networks, and system and method including the network element
EA201170293A1 (ru) 2008-07-31 2011-08-30 Джама Текнолоджи Корп. Способ публикации и подписки для мониторинга событий в режиме реального времени в системе для управления множеством различных сетей
JP5239618B2 (ja) * 2008-08-19 2013-07-17 沖電気工業株式会社 アドレス変換装置、方法及びプログラム、並びにノード
CN101741678B (zh) * 2008-11-26 2012-02-29 华为技术有限公司 一种建立虚拟局域网连接的方法、设备与***
KR101525623B1 (ko) * 2008-12-18 2015-06-03 삼성전자주식회사 네트워크 트래픽 필터링 방법 및 장치
US20100235515A1 (en) * 2009-03-16 2010-09-16 Posco Ict Company Ltd. Method and apparatus for managing connection
US8750286B2 (en) 2009-03-19 2014-06-10 Nec Corporation Network communication system, communication device, network linkage method and program thereof
US8966035B2 (en) 2009-04-01 2015-02-24 Nicira, Inc. Method and apparatus for implementing and managing distributed virtual switches in several hosts and physical forwarding elements
EP2242215B1 (en) 2009-04-16 2017-01-11 Alcatel Lucent Method for client data transmission through a packet switched provider network
US8170038B2 (en) * 2009-05-27 2012-05-01 International Business Machines Corporation Two-layer switch apparatus to avoid first layer inter-switch link data traffic in steering packets through bump-in-the-wire service applications
US8289977B2 (en) 2009-06-10 2012-10-16 International Business Machines Corporation Two-layer switch apparatus avoiding first layer inter-switch traffic in steering packets through the apparatus
US8289961B2 (en) 2009-08-20 2012-10-16 Telefonaktiebolaget L M Ericsson (Publ) Link state identifier collision handling
US8509249B2 (en) * 2009-09-04 2013-08-13 Equinix, Inc. Process and system for an integrated carrier ethernet exchange
JP5717164B2 (ja) 2009-10-07 2015-05-13 日本電気株式会社 コンピュータシステム、及びコンピュータシステムのメンテナンス方法
EP2309680B1 (en) * 2009-10-08 2017-07-19 Solarflare Communications Inc Switching API
EP2489154A1 (en) * 2009-10-12 2012-08-22 Nokia Siemens Networks OY Method and device for processing data in a network domain
US9082091B2 (en) 2009-12-10 2015-07-14 Equinix, Inc. Unified user login for co-location facilities
US8767742B2 (en) * 2010-04-22 2014-07-01 International Business Machines Corporation Network data congestion management system
CN102934400B (zh) 2010-06-09 2016-08-24 日本电气株式会社 通信***、逻辑信道控制设备、控制设备、通信方法以及程序
US8660132B2 (en) * 2010-06-28 2014-02-25 Avaya Inc. Control plane packet processing and latency control
JP5516142B2 (ja) * 2010-06-30 2014-06-11 富士通株式会社 伝送システム、伝送装置、宛先管理装置、制御ユニット、伝送制御プログラム及び同プログラムを記録したコンピュータ読み取り可能な記録媒体
US10103939B2 (en) 2010-07-06 2018-10-16 Nicira, Inc. Network control apparatus and method for populating logical datapath sets
US8817621B2 (en) 2010-07-06 2014-08-26 Nicira, Inc. Network virtualization apparatus
US8964528B2 (en) 2010-07-06 2015-02-24 Nicira, Inc. Method and apparatus for robust packet distribution among hierarchical managed switching elements
US9525647B2 (en) 2010-07-06 2016-12-20 Nicira, Inc. Network control apparatus and method for creating and modifying logical switching elements
US9680750B2 (en) 2010-07-06 2017-06-13 Nicira, Inc. Use of tunnels to hide network addresses
JP5485821B2 (ja) * 2010-07-08 2014-05-07 富士通テレコムネットワークス株式会社 通信フレームの中継装置および中継方法
CN101917492B (zh) * 2010-08-06 2013-06-05 北京乾唐视联网络科技有限公司 一种新型网的通信方法及***
EP2608462B1 (en) * 2010-08-20 2019-02-06 Nec Corporation Communication system, control apparatus, communication method and program
US8627137B1 (en) * 2010-09-16 2014-01-07 Cisco Technology, Inc. Graceful handling of critical traffic blackholing faults
US8559432B2 (en) * 2010-09-23 2013-10-15 Telefonaktiebolaget Lm Ericsson (Publ) Pseudo-wire providing an in-band control channel using an offset
JP5674107B2 (ja) 2010-10-19 2015-02-25 日本電気株式会社 通信システム、制御装置、処理規則の設定方法およびプログラム
US8417111B2 (en) * 2010-10-28 2013-04-09 Ciena Corporation Optical network in-band control plane signaling, virtualized channels, and tandem connection monitoring systems and methods
WO2012063106A1 (en) * 2010-11-12 2012-05-18 Telefonaktiebolaget L M Ericsson (Publ) Installation and enforcement of dynamic and static pcc rules in tunneling scenarios
CN102014061B (zh) * 2010-11-25 2012-11-21 福建星网锐捷网络有限公司 内网核心交换机的上行流量控制方法及装置
EP2652918B1 (en) * 2010-12-15 2016-03-09 Telefonaktiebolaget LM Ericsson (publ) Segment recovery in connection-oriented network
US20120155461A1 (en) * 2010-12-16 2012-06-21 Electronics And Telecommunications Research Institute Apparatus for managing virtual network
JP5534036B2 (ja) * 2010-12-28 2014-06-25 日本電気株式会社 情報システム、制御装置、通信方法およびプログラム
CN102055673A (zh) * 2010-12-30 2011-05-11 上海顶竹通讯技术有限公司 多路由网络以及路由切换方法
HUE024948T2 (en) * 2011-02-19 2016-01-28 Deutsche Telekom Ag Looping MPLS-UTAK to MPLS Networks with no connection level
US20120224579A1 (en) * 2011-03-01 2012-09-06 Futurewei Technologies, Inc. Multiprotocol Label Switching (MPLS) Virtual Private Network (VPN) Over Routed Ethernet Backbone
US8520534B2 (en) * 2011-03-03 2013-08-27 Alcatel Lucent In-service throughput testing in distributed router/switch architectures
CN102118316B (zh) * 2011-03-07 2013-09-25 杭州华三通信技术有限公司 学习mac地址的方法和设备
EP2685675A4 (en) * 2011-03-09 2014-12-10 Nec Corp COMPUTER SYSTEM, SERVER, OPENFLOW CONTROL DEVICE, AND COMMUNICATION METHOD
JPWO2012133060A1 (ja) * 2011-03-29 2014-07-28 日本電気株式会社 ネットワークシステム、及びvlanタグ情報取得方法
US9065723B2 (en) 2011-04-04 2015-06-23 Jds Uniphase Corporation Unaddressed device communication from within an MPLS network
US8825900B1 (en) 2011-04-05 2014-09-02 Nicira, Inc. Method and apparatus for stateless transport layer tunneling
US8897173B2 (en) * 2011-04-29 2014-11-25 T-Mobile Usa, Inc. Microwave backhaul arrangements
US9043452B2 (en) 2011-05-04 2015-05-26 Nicira, Inc. Network control apparatus and method for port isolation
WO2012154542A1 (en) 2011-05-06 2012-11-15 Interdigital Patent Holdings, Inc. Methods and apparatus for using control plane to transmit and receive data
CN102209363B (zh) * 2011-05-18 2015-05-20 中兴通讯股份有限公司 一种在操作维护中心配置到基站路由的实现方法及***
EP2721785B1 (en) * 2011-06-15 2016-05-18 BAE Systems PLC Data transfer
EP2536070A1 (en) * 2011-06-15 2012-12-19 BAE Systems Plc Data transfer
WO2012177213A2 (en) * 2011-06-20 2012-12-27 Telefonaktiebolaget L M Ericsson (Publ) Methods and devices for monitoring a data path
US9185027B2 (en) * 2011-07-29 2015-11-10 Telefonaktiebolaget L M Ericsson (Publ) Method and apparatus for resilient routing of control traffic in a split-architecture system
US10091028B2 (en) 2011-08-17 2018-10-02 Nicira, Inc. Hierarchical controller clusters for interconnecting two or more logical datapath sets
US9369426B2 (en) 2011-08-17 2016-06-14 Nicira, Inc. Distributed logical L3 routing
EP2756635B1 (en) 2011-09-16 2018-11-07 Cisco Technology, Inc. Downstream device architecture and control
US8811212B2 (en) 2012-02-22 2014-08-19 Telefonaktiebolaget L M Ericsson (Publ) Controller placement for fast failover in the split architecture
US9288104B2 (en) 2011-10-25 2016-03-15 Nicira, Inc. Chassis controllers for converting universal flows
US9137107B2 (en) 2011-10-25 2015-09-15 Nicira, Inc. Physical controllers for converting universal flows
US9203701B2 (en) 2011-10-25 2015-12-01 Nicira, Inc. Network virtualization apparatus and method with scheduling capabilities
US9154433B2 (en) 2011-10-25 2015-10-06 Nicira, Inc. Physical controller
US10089127B2 (en) 2011-11-15 2018-10-02 Nicira, Inc. Control plane interface for logical middlebox services
CN103178983A (zh) * 2011-12-26 2013-06-26 中兴通讯股份有限公司 最短路径优先协议接口区域标识的配置方法及装置
KR20140116176A (ko) * 2011-12-29 2014-10-01 노키아 솔루션스 앤드 네트웍스 오와이 통신 네트워크 시스템에서 트래픽 운반
KR101393189B1 (ko) * 2012-01-31 2014-05-08 최현욱 검색어 제시를 위한 데이터베이스 관리방법과 이 방법을 위한 컴퓨터로 읽을 수 있는 매체 및 컴퓨터 장치
JP5771832B2 (ja) * 2012-02-14 2015-09-02 株式会社日立製作所 伝送システム、管理計算機、及び論理パス構築方法
US9020888B1 (en) 2012-04-04 2015-04-28 Nectar Services Corp. Data replicating systems and data replication methods
WO2013158918A1 (en) 2012-04-18 2013-10-24 Nicira, Inc. Using transactions to minimize churn in a distributed network control system
US9112728B2 (en) * 2012-05-31 2015-08-18 Broadcom Corporation Implementing control planes for hybrid networks
US9178801B1 (en) * 2012-06-27 2015-11-03 Juniper Networks, Inc. Automated service discovery in computer networks
US9231892B2 (en) 2012-07-09 2016-01-05 Vmware, Inc. Distributed virtual switch configuration and state management
US9167318B1 (en) * 2012-08-07 2015-10-20 Ciena Corporation Bandwidth advertisement systems and methods for optical transport network
US9225671B2 (en) 2012-08-17 2015-12-29 Cisco Technology, Inc. Auto management of a virtual device context enabled network infrastructure
US20140064150A1 (en) * 2012-08-31 2014-03-06 Cisco Technology, Inc. Mst extensions for flexible and scalable vn-segment loop prevention
US9236936B2 (en) * 2012-08-31 2016-01-12 Hughes Network Systems, Llc System and method for low-complexity, high-speed preprocessing of encapsulated packets in a broadband communications network
CN103780449B (zh) * 2012-10-23 2018-05-01 百度在线网络技术(北京)有限公司 一种基于cache存储的流量复用方法和装置
CN102970621B (zh) * 2012-11-23 2015-09-16 中兴通讯股份有限公司 一种网元内传输资源管理装置及方法
US20140153443A1 (en) * 2012-11-30 2014-06-05 International Business Machines Corporation Per-Address Spanning Tree Networks
US9198118B2 (en) * 2012-12-07 2015-11-24 At&T Intellectual Property I, L.P. Rogue wireless access point detection
US9246847B2 (en) * 2012-12-17 2016-01-26 Telefonaktiebolaget L M Ericsson (Publ) Extending the reach and effectiveness of header compression in access networks using SDN
CN104871529B (zh) * 2012-12-17 2018-09-18 马维尔国际贸易有限公司 网络发现装置
US9391959B2 (en) * 2013-01-15 2016-07-12 Cisco Technology, Inc. Automated control plane for limited user destruction
US9306873B2 (en) 2013-02-21 2016-04-05 Beers Enterprises, Llc Customer controlled video network
US20140269531A1 (en) * 2013-03-14 2014-09-18 Aliphcom Intelligent connection management in wireless devices
US9270368B2 (en) 2013-03-14 2016-02-23 Hubbell Incorporated Methods and apparatuses for improved Ethernet path selection using optical levels
US9294393B1 (en) * 2013-04-30 2016-03-22 Cisco Technology, Inc. Interconnecting virtual private networks
US9479433B1 (en) 2013-04-30 2016-10-25 Cisco Technology, Inc. Interconnecting virtual private networks
US9246799B2 (en) * 2013-05-10 2016-01-26 Cisco Technology, Inc. Data plane learning of bi-directional service chains
US9432215B2 (en) 2013-05-21 2016-08-30 Nicira, Inc. Hierarchical network managers
US9178812B2 (en) 2013-06-05 2015-11-03 Cisco Technology, Inc. Stacking metadata contexts for service chains
US9444675B2 (en) 2013-06-07 2016-09-13 Cisco Technology, Inc. Determining the operations performed along a service path/service chain
US9438665B1 (en) * 2013-06-18 2016-09-06 Amazon Technologies, Inc. Scheduling and tracking control plane operations for distributed storage systems
US9407561B2 (en) 2013-06-19 2016-08-02 Huawei Technologies Co., Ld. Systems and methods for traffic engineering in software defined networks
US10218564B2 (en) 2013-07-08 2019-02-26 Nicira, Inc. Unified replication mechanism for fault-tolerance of state
US9571386B2 (en) 2013-07-08 2017-02-14 Nicira, Inc. Hybrid packet processing
US9602312B2 (en) 2013-07-08 2017-03-21 Nicira, Inc. Storing network state at a network controller
US10454714B2 (en) 2013-07-10 2019-10-22 Nicira, Inc. Method and system of overlay flow control
US10749711B2 (en) 2013-07-10 2020-08-18 Nicira, Inc. Network-link method useful for a last-mile connectivity in an edge-gateway multipath system
US9282019B2 (en) 2013-07-12 2016-03-08 Nicira, Inc. Tracing logical network packets through physical network
US9407580B2 (en) 2013-07-12 2016-08-02 Nicira, Inc. Maintaining data stored with a packet
US9197529B2 (en) 2013-07-12 2015-11-24 Nicira, Inc. Tracing network packets through logical and physical networks
US9952885B2 (en) 2013-08-14 2018-04-24 Nicira, Inc. Generation of configuration files for a DHCP module executing within a virtualized container
US9887960B2 (en) 2013-08-14 2018-02-06 Nicira, Inc. Providing services for logical networks
US9973382B2 (en) 2013-08-15 2018-05-15 Nicira, Inc. Hitless upgrade for network control applications
WO2015026809A1 (en) 2013-08-19 2015-02-26 Centurylink Intellectual Property Llc Network management layer - configuration management
US9374308B2 (en) * 2013-08-30 2016-06-21 Lenovo Enterprise Solutions (Singapore) Pte. Ltd. Openflow switch mode transition processing
US9577845B2 (en) 2013-09-04 2017-02-21 Nicira, Inc. Multiple active L3 gateways for logical networks
US9503371B2 (en) 2013-09-04 2016-11-22 Nicira, Inc. High availability L3 gateways for logical networks
US10270719B2 (en) * 2013-09-10 2019-04-23 Illinois Tool Works Inc. Methods for handling data packets in a digital network of a welding system
US9602398B2 (en) 2013-09-15 2017-03-21 Nicira, Inc. Dynamically generating flows with wildcard fields
US9674087B2 (en) 2013-09-15 2017-06-06 Nicira, Inc. Performing a multi-stage lookup to classify packets
US10148484B2 (en) 2013-10-10 2018-12-04 Nicira, Inc. Host side method of using a controller assignment list
US10063458B2 (en) 2013-10-13 2018-08-28 Nicira, Inc. Asymmetric connection with external networks
US9785455B2 (en) 2013-10-13 2017-10-10 Nicira, Inc. Logical router
WO2015070892A1 (en) * 2013-11-12 2015-05-21 Telefonaktiebolaget L M Ericsson (Publ) Method and a device for provisioning control plane in multi-technology network
US20150134851A1 (en) * 2013-11-14 2015-05-14 Broadcom Corporation Geotagged communications in network systems and components
US10158538B2 (en) 2013-12-09 2018-12-18 Nicira, Inc. Reporting elephant flows to a network controller
US9967199B2 (en) 2013-12-09 2018-05-08 Nicira, Inc. Inspecting operations of a machine to detect elephant flows
US9996467B2 (en) 2013-12-13 2018-06-12 Nicira, Inc. Dynamically adjusting the number of flows allowed in a flow table cache
US9569368B2 (en) 2013-12-13 2017-02-14 Nicira, Inc. Installing and managing flows in a flow table cache
US9629018B2 (en) 2014-02-05 2017-04-18 Ibasis, Inc. Method and apparatus for triggering management of communication flow in an inter-network system
US10263903B2 (en) * 2014-02-05 2019-04-16 Ibasis, Inc. Method and apparatus for managing communication flow in an inter-network system
US9590901B2 (en) 2014-03-14 2017-03-07 Nicira, Inc. Route advertisement by managed gateways
US9313129B2 (en) 2014-03-14 2016-04-12 Nicira, Inc. Logical router processing by network controller
US9225597B2 (en) 2014-03-14 2015-12-29 Nicira, Inc. Managed gateways peering with external router to attract ingress packets
US9419855B2 (en) 2014-03-14 2016-08-16 Nicira, Inc. Static routes for logical routers
US9503321B2 (en) 2014-03-21 2016-11-22 Nicira, Inc. Dynamic routing for logical routers
US9647883B2 (en) 2014-03-21 2017-05-09 Nicria, Inc. Multiple levels of logical routers
US9736053B2 (en) * 2014-03-25 2017-08-15 Nec Corporation Layer 2 path tracing through context encoding in software defined networking
US9413644B2 (en) 2014-03-27 2016-08-09 Nicira, Inc. Ingress ECMP in virtual distributed routing environment
US9893988B2 (en) 2014-03-27 2018-02-13 Nicira, Inc. Address resolution using multiple designated instances of a logical router
US9385954B2 (en) 2014-03-31 2016-07-05 Nicira, Inc. Hashing techniques for use in a network environment
GB2524749B (en) * 2014-03-31 2018-12-19 Metaswitch Networks Ltd Spanning tree protocol
US10193806B2 (en) 2014-03-31 2019-01-29 Nicira, Inc. Performing a finishing operation to improve the quality of a resulting hash
US9985896B2 (en) 2014-03-31 2018-05-29 Nicira, Inc. Caching of service decisions
US9602422B2 (en) 2014-05-05 2017-03-21 Nicira, Inc. Implementing fixed points in network state updates using generation numbers
US9742881B2 (en) 2014-06-30 2017-08-22 Nicira, Inc. Network virtualization using just-in-time distributed capability for classification encoding
US10481933B2 (en) 2014-08-22 2019-11-19 Nicira, Inc. Enabling virtual machines access to switches configured by different management entities
US9819573B2 (en) * 2014-09-11 2017-11-14 Microsoft Technology Licensing, Llc Method for scalable computer network partitioning
US9544225B2 (en) 2014-09-16 2017-01-10 Microsoft Technology Licensing, Llc Method for end point identification in computer networks
US10020960B2 (en) 2014-09-30 2018-07-10 Nicira, Inc. Virtual distributed bridging
US9838337B1 (en) * 2014-09-30 2017-12-05 Juniper Networks, Inc. Automatic virtual local area network (VLAN) provisioning in data center switches
US11178051B2 (en) 2014-09-30 2021-11-16 Vmware, Inc. Packet key parser for flow-based forwarding elements
US10511458B2 (en) 2014-09-30 2019-12-17 Nicira, Inc. Virtual distributed bridging
US9768980B2 (en) 2014-09-30 2017-09-19 Nicira, Inc. Virtual distributed bridging
US10250443B2 (en) 2014-09-30 2019-04-02 Nicira, Inc. Using physical location to modify behavior of a distributed virtual network element
US10469342B2 (en) 2014-10-10 2019-11-05 Nicira, Inc. Logical network traffic analysis
CN105591767A (zh) * 2014-10-21 2016-05-18 中兴通讯股份有限公司 Svlan分配方法及装置、以太网业务建立方法及***
US10057330B2 (en) * 2014-11-04 2018-08-21 Intel Corporation Apparatus and method for deferring asynchronous events notifications
US9774458B2 (en) * 2015-01-14 2017-09-26 Alcatel-Lucent Usa Inc. Method for transporting Ethernet and non-Ethernet traffic over the same medium
US10313151B2 (en) * 2015-01-14 2019-06-04 Fujitsu Limited Enhanced loop-breaking protocol to support connectionless and connection-oriented ethernet
US9787605B2 (en) 2015-01-30 2017-10-10 Nicira, Inc. Logical router with multiple routing components
US10038628B2 (en) 2015-04-04 2018-07-31 Nicira, Inc. Route server mode for dynamic routing between logical and physical networks
US9923760B2 (en) 2015-04-06 2018-03-20 Nicira, Inc. Reduction of churn in a network control system
US10498652B2 (en) 2015-04-13 2019-12-03 Nicira, Inc. Method and system of application-aware routing with crowdsourcing
US10425382B2 (en) * 2015-04-13 2019-09-24 Nicira, Inc. Method and system of a cloud-based multipath routing protocol
US10135789B2 (en) * 2015-04-13 2018-11-20 Nicira, Inc. Method and system of establishing a virtual private network in a cloud service for branch networking
US10225184B2 (en) 2015-06-30 2019-03-05 Nicira, Inc. Redirecting traffic in a virtual distributed router environment
US10230629B2 (en) 2015-08-11 2019-03-12 Nicira, Inc. Static route configuration for logical router
US10057157B2 (en) 2015-08-31 2018-08-21 Nicira, Inc. Automatically advertising NAT routes between logical routers
EP3145269A1 (en) * 2015-09-16 2017-03-22 Alcatel Lucent Method, devices and system for a hybrid bearer service
US10204122B2 (en) 2015-09-30 2019-02-12 Nicira, Inc. Implementing an interface between tuple and message-driven control entities
US10095535B2 (en) 2015-10-31 2018-10-09 Nicira, Inc. Static route types for logical routers
US20170195218A1 (en) * 2015-12-30 2017-07-06 Qualcomm Incorporated Routing in a hybrid network
US10333849B2 (en) 2016-04-28 2019-06-25 Nicira, Inc. Automatic configuration of logical routers on edge nodes
US11019167B2 (en) 2016-04-29 2021-05-25 Nicira, Inc. Management of update queues for network controller
US10484515B2 (en) 2016-04-29 2019-11-19 Nicira, Inc. Implementing logical metadata proxy servers in logical networks
US10841273B2 (en) 2016-04-29 2020-11-17 Nicira, Inc. Implementing logical DHCP servers in logical networks
US10091161B2 (en) 2016-04-30 2018-10-02 Nicira, Inc. Assignment of router ID for logical routers
US10153973B2 (en) 2016-06-29 2018-12-11 Nicira, Inc. Installation of routing tables for logical router in route server mode
US10560320B2 (en) 2016-06-29 2020-02-11 Nicira, Inc. Ranking of gateways in cluster
TWI651950B (zh) 2016-07-07 2019-02-21 財團法人工業技術研究院 無線接取網路之服務區分方法、無線網路系統及無線接取網路存取點
US10298491B2 (en) * 2016-08-25 2019-05-21 Cisco Technology, Inc. Efficient path detection and validation between endpoints in large datacenters
US10454758B2 (en) 2016-08-31 2019-10-22 Nicira, Inc. Edge node cluster network redundancy and fast convergence using an underlay anycast VTEP IP
US10979890B2 (en) 2016-09-09 2021-04-13 Ibasis, Inc. Policy control framework
US10341236B2 (en) 2016-09-30 2019-07-02 Nicira, Inc. Anycast edge service gateways
US10742746B2 (en) 2016-12-21 2020-08-11 Nicira, Inc. Bypassing a load balancer in a return path of network traffic
US10237123B2 (en) 2016-12-21 2019-03-19 Nicira, Inc. Dynamic recovery from a split-brain failure in edge nodes
US10212071B2 (en) 2016-12-21 2019-02-19 Nicira, Inc. Bypassing a load balancer in a return path of network traffic
US10616045B2 (en) 2016-12-22 2020-04-07 Nicira, Inc. Migration of centralized routing components of logical router
US10554494B1 (en) 2017-01-04 2020-02-04 Juniper Networks, Inc. Automatic ICCP provisioning and VLAN provisioning on an inter-chassis link in a MC-LAG
US11121962B2 (en) 2017-01-31 2021-09-14 Vmware, Inc. High performance software-defined core network
US10992568B2 (en) 2017-01-31 2021-04-27 Vmware, Inc. High performance software-defined core network
US11252079B2 (en) 2017-01-31 2022-02-15 Vmware, Inc. High performance software-defined core network
US11706127B2 (en) 2017-01-31 2023-07-18 Vmware, Inc. High performance software-defined core network
US10992558B1 (en) 2017-11-06 2021-04-27 Vmware, Inc. Method and apparatus for distributed data network traffic optimization
US20180219765A1 (en) 2017-01-31 2018-08-02 Waltz Networks Method and Apparatus for Network Traffic Control Optimization
US20200036624A1 (en) 2017-01-31 2020-01-30 The Mode Group High performance software-defined core network
US10574528B2 (en) 2017-02-11 2020-02-25 Nicira, Inc. Network multi-source inbound quality of service methods and systems
US10778528B2 (en) 2017-02-11 2020-09-15 Nicira, Inc. Method and system of connecting to a multipath hub in a cluster
US10200306B2 (en) 2017-03-07 2019-02-05 Nicira, Inc. Visualization of packet tracing operation results
CN110036656B (zh) 2017-03-30 2022-10-11 伊巴西斯公司 无需sms的esim简档切换
US10523539B2 (en) 2017-06-22 2019-12-31 Nicira, Inc. Method and system of resiliency in cloud-delivered SD-WAN
US10524116B2 (en) 2017-06-27 2019-12-31 Ibasis, Inc. Internet of things services architecture
US10681000B2 (en) 2017-06-30 2020-06-09 Nicira, Inc. Assignment of unique physical network addresses for logical network addresses
US10637800B2 (en) 2017-06-30 2020-04-28 Nicira, Inc Replacement of logical network addresses with physical network addresses
US11516049B2 (en) 2017-10-02 2022-11-29 Vmware, Inc. Overlay network encapsulation to forward data message flows through multiple public cloud datacenters
US11089111B2 (en) 2017-10-02 2021-08-10 Vmware, Inc. Layer four optimization for a virtual network defined over public cloud
US10959098B2 (en) 2017-10-02 2021-03-23 Vmware, Inc. Dynamically specifying multiple public cloud edge nodes to connect to an external multi-computer node
US11115480B2 (en) 2017-10-02 2021-09-07 Vmware, Inc. Layer four optimization for a virtual network defined over public cloud
US10999165B2 (en) 2017-10-02 2021-05-04 Vmware, Inc. Three tiers of SaaS providers for deploying compute and network infrastructure in the public cloud
US10999100B2 (en) 2017-10-02 2021-05-04 Vmware, Inc. Identifying multiple nodes in a virtual network defined over a set of public clouds to connect to an external SAAS provider
US10608887B2 (en) 2017-10-06 2020-03-31 Nicira, Inc. Using packet tracing tool to automatically execute packet capture operations
US11223514B2 (en) 2017-11-09 2022-01-11 Nicira, Inc. Method and system of a dynamic high-availability mode based on current wide area network connectivity
US10374827B2 (en) 2017-11-14 2019-08-06 Nicira, Inc. Identifier that maps to different networks at different datacenters
US10511459B2 (en) 2017-11-14 2019-12-17 Nicira, Inc. Selection of managed forwarding element for bridge spanning multiple datacenters
US11025537B2 (en) * 2017-12-04 2021-06-01 Is5 Communications, Inc. Multiple RSTP domain separation
US10993171B2 (en) * 2018-01-02 2021-04-27 Qualcomm Incorporated Advertisement of communication schedules for multiple basic service sets
JP7136893B2 (ja) * 2018-06-14 2022-09-13 日立Astemo株式会社 ゲートウェイ装置
US10999220B2 (en) 2018-07-05 2021-05-04 Vmware, Inc. Context aware middlebox services at datacenter edge
US11184327B2 (en) 2018-07-05 2021-11-23 Vmware, Inc. Context aware middlebox services at datacenter edges
CN112866004B (zh) * 2018-08-23 2024-04-12 华为技术有限公司 控制面设备的切换方法、装置及转控分离***
CN109462558A (zh) * 2018-10-23 2019-03-12 北京华环电子股份有限公司 一种对mpls报文进行gre封装处理的装置
SE1851342A1 (en) * 2018-10-29 2020-04-30 Telia Co Ab A method and an apparatus for routing data packets in a network topology
US10931560B2 (en) 2018-11-23 2021-02-23 Vmware, Inc. Using route type to determine routing protocol behavior
US10735541B2 (en) 2018-11-30 2020-08-04 Vmware, Inc. Distributed inline proxy
US10797998B2 (en) 2018-12-05 2020-10-06 Vmware, Inc. Route server for distributed routers using hierarchical routing protocol
US10938788B2 (en) 2018-12-12 2021-03-02 Vmware, Inc. Static routes for policy-based VPN
US10841209B2 (en) 2018-12-21 2020-11-17 Cisco Technology, Inc. Method, node, and medium for establishing connection between a source and endpoint via one or more border nodes
US11018995B2 (en) 2019-08-27 2021-05-25 Vmware, Inc. Alleviating congestion in a virtual network deployed over public clouds for an entity
US11159343B2 (en) 2019-08-30 2021-10-26 Vmware, Inc. Configuring traffic optimization using distributed edge services
US11044190B2 (en) 2019-10-28 2021-06-22 Vmware, Inc. Managing forwarding elements at edge nodes connected to a virtual network
US11489783B2 (en) 2019-12-12 2022-11-01 Vmware, Inc. Performing deep packet inspection in a software defined wide area network
US11394640B2 (en) 2019-12-12 2022-07-19 Vmware, Inc. Collecting and analyzing data regarding flows associated with DPI parameters
US11641305B2 (en) 2019-12-16 2023-05-02 Vmware, Inc. Network diagnosis in software-defined networking (SDN) environments
US11283699B2 (en) 2020-01-17 2022-03-22 Vmware, Inc. Practical overlay network latency measurement in datacenter
CN113163276A (zh) * 2020-01-22 2021-07-23 华为技术有限公司 路由信息的发布方法、装置及***
US20210234804A1 (en) 2020-01-24 2021-07-29 Vmware, Inc. Accurate traffic steering between links through sub-path path quality metrics
US20230155918A1 (en) * 2020-03-17 2023-05-18 Nec Corporation Logical network construction system, gateway device, controller, and logicalnetwork construction method
US11245641B2 (en) 2020-07-02 2022-02-08 Vmware, Inc. Methods and apparatus for application aware hub clustering techniques for a hyper scale SD-WAN
US11606294B2 (en) 2020-07-16 2023-03-14 Vmware, Inc. Host computer configured to facilitate distributed SNAT service
US11616755B2 (en) 2020-07-16 2023-03-28 Vmware, Inc. Facilitating distributed SNAT service
US11303505B2 (en) * 2020-07-22 2022-04-12 Arista Networks, Inc. Aggregated control-plane tables
US11611613B2 (en) 2020-07-24 2023-03-21 Vmware, Inc. Policy-based forwarding to a load balancer of a load balancing cluster
US11902050B2 (en) 2020-07-28 2024-02-13 VMware LLC Method for providing distributed gateway service at host computer
US11451413B2 (en) 2020-07-28 2022-09-20 Vmware, Inc. Method for advertising availability of distributed gateway service and machines at host computer
US11570090B2 (en) 2020-07-29 2023-01-31 Vmware, Inc. Flow tracing operation in container cluster
US11196628B1 (en) 2020-07-29 2021-12-07 Vmware, Inc. Monitoring container clusters
US11558426B2 (en) 2020-07-29 2023-01-17 Vmware, Inc. Connection tracking for container cluster
US11363124B2 (en) 2020-07-30 2022-06-14 Vmware, Inc. Zero copy socket splicing
US11575591B2 (en) 2020-11-17 2023-02-07 Vmware, Inc. Autonomous distributed forwarding plane traceability based anomaly detection in application traffic for hyper-scale SD-WAN
US11575600B2 (en) 2020-11-24 2023-02-07 Vmware, Inc. Tunnel-less SD-WAN
US11929903B2 (en) 2020-12-29 2024-03-12 VMware LLC Emulating packet flows to assess network links for SD-WAN
US11736436B2 (en) 2020-12-31 2023-08-22 Vmware, Inc. Identifying routes with indirect addressing in a datacenter
US11336533B1 (en) 2021-01-08 2022-05-17 Vmware, Inc. Network visualization of correlations between logical elements and associated physical elements
US11792127B2 (en) 2021-01-18 2023-10-17 Vmware, Inc. Network-aware load balancing
US11979325B2 (en) 2021-01-28 2024-05-07 VMware LLC Dynamic SD-WAN hub cluster scaling with machine learning
US11509571B1 (en) 2021-05-03 2022-11-22 Vmware, Inc. Cost-based routing mesh for facilitating routing through an SD-WAN
US11729065B2 (en) 2021-05-06 2023-08-15 Vmware, Inc. Methods for application defined virtual network service among multiple transport in SD-WAN
US11489720B1 (en) 2021-06-18 2022-11-01 Vmware, Inc. Method and apparatus to evaluate resource elements and public clouds for deploying tenant deployable elements based on harvested performance metrics
US11687210B2 (en) 2021-07-05 2023-06-27 Vmware, Inc. Criteria-based expansion of group nodes in a network topology visualization
US11375005B1 (en) 2021-07-24 2022-06-28 Vmware, Inc. High availability solutions for a secure access service edge application
US11711278B2 (en) 2021-07-24 2023-07-25 Vmware, Inc. Visualization of flow trace operation across multiple sites
US11706109B2 (en) 2021-09-17 2023-07-18 Vmware, Inc. Performance of traffic monitoring actions
US11943146B2 (en) 2021-10-01 2024-03-26 VMware LLC Traffic prioritization in SD-WAN
KR102539612B1 (ko) * 2021-12-24 2023-06-02 엘에스일렉트릭(주) IP 기반 RAPIEnet을 지원하는 통신 디바이스 및 이를 포함하는 네트워크 시스템
CN114301691B (zh) * 2021-12-29 2022-10-25 威创集团股份有限公司 分布式信号单向传输隔离方法、装置、设备及存储介质
US11909815B2 (en) 2022-06-06 2024-02-20 VMware LLC Routing based on geolocation costs
US20240146649A1 (en) * 2022-10-26 2024-05-02 Schweitzer Engineering Laboratories, Inc. Communication system configuration using substation configuration language file

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0738596A (ja) * 1993-07-16 1995-02-07 Toshiba Corp ネットワーク間接続装置
US20030120822A1 (en) * 2001-04-19 2003-06-26 Langrind Nicholas A. Isolated control plane addressing
KR100451721B1 (ko) * 2000-12-30 2004-10-08 엘지전자 주식회사 이동통신 시스템에서의 프로세서간 정합 방법
US7212495B2 (en) * 2001-02-21 2007-05-01 Polytechnic University Signaling for reserving a communications path
US7130303B2 (en) * 2001-03-15 2006-10-31 Lucent Technologies Inc. Ethernet packet encapsulation for metropolitan area ethernet networks
US20030025959A1 (en) * 2001-07-31 2003-02-06 Ramesh Nagarajan Connection setup strategies in optical transport networks
WO2003027807A2 (en) * 2001-09-24 2003-04-03 Rumi Sheryar Gonda Method for supporting ethernet mac circuits
US20030128668A1 (en) * 2002-01-04 2003-07-10 Yavatkar Rajendra S. Distributed implementation of control protocols in routers and switches
JP3914087B2 (ja) * 2002-04-19 2007-05-16 富士通株式会社 シグナリング制御方法及びシグナリング対応通信装置及びネットワーク管理システム
US7301949B2 (en) * 2003-07-15 2007-11-27 Telefonaktiebolaget Lm Ericsson (Publ) Arrangements for connection-oriented transport in a packet switched communications network
JP3760167B2 (ja) * 2004-02-25 2006-03-29 株式会社日立製作所 通信制御装置、通信ネットワークおよびパケット転送制御情報の更新方法
US7860096B2 (en) * 2004-06-08 2010-12-28 Oracle America, Inc. Switching method and apparatus for use in a communications network

Also Published As

Publication number Publication date
BRPI0519612A2 (pt) 2009-02-25
JP2008527772A (ja) 2008-07-24
AU2005321093A1 (en) 2006-07-06
EP1832068A2 (en) 2007-09-12
KR20070095374A (ko) 2007-09-28
CA2590669A1 (en) 2006-07-06
WO2006070197A3 (en) 2006-12-21
WO2006070197A2 (en) 2006-07-06
US20080049621A1 (en) 2008-02-28

Similar Documents

Publication Publication Date Title
MX2007008112A (es) Metodo para ejecutar una red sin conexion como una red de conexion orientada.
KR101503629B1 (ko) 주소 기반 캐리어 네트워크의 구별 전달
US8194668B2 (en) Differential forwarding in address-based carrier networks
US7619966B2 (en) Hybrid virtual private LAN extensions
US20080037559A1 (en) Arrangements for connection-oriented transport in a packet switched communications network
CN101107824A (zh) 针对无连接通信流量的面向连接的通信方案
US8111613B2 (en) In-layer ethernet p-cycle protection scheme
EP1782587A2 (en) Method and system for communicating and isolating packetized data through a plurality of last-mile carriers to form a multi-node intranet
WO2012093295A1 (en) Architecture for routing data of a customer network over provider&#39;s network in provider backbone bridges
Iwata et al. Global open Ethernet architecture for a cost-effective scalable VPN solution
US20060088033A1 (en) Packet switch network link
GB2438767A (en) Identifying packets for forwarding through connections

Legal Events

Date Code Title Description
FA Abandonment or withdrawal