ES2588739T3 - Método, equipo y sistema para mapear una instancia de servicio - Google Patents

Abstract

Un método para mapear una instancia de servicio para el protocolo de Interconexión Transparente de Múltiples enlaces, TRILL, que comprende: correlacionar (101) una instancia de servicio de capa 2 con un puerto de acceso al servicio de la instancia de servicio, y determinar la correspondencia entre el puerto de acceso al servicio y un identificador de la instancia de servicio; y asociar (102) el identificador de la instancia de servicio a una etiqueta de servicio de un paquete de apilamiento de red de área local virtual, VLAN, de dos capas, en donde un paquete de capa 2 de un usuario que ha sido recibido por parte del puerto de acceso al servicio se encapsula en el paquete de apilamiento de la VLAN de dos capas utilizando una cabecera TRILL; y reenviar el paquete de apilamiento de la VLAN de dos capas; caracterizado por que la etiqueta de servicio es de 24 bits, la etiqueta de servicio está constituida por un campo de red de área local virtual de una primera etiqueta externa y un campo de red de área local virtual de una etiqueta interna en el paquete de apilamiento de la VLAN de dos capas, los 12 bits del campo VLAN de la etiqueta externa almacenan los 12 bits más significativos de la etiqueta de servicio, y los 12 bits del campo VLAN de la etiqueta interna almacenan los 12 bits menos significativos de la etiqueta de servicio.

Description

5

10

15

20

25

30

35

40

45

50

55

DESCRIPCION

Metodo, equipo y sistema para mapear una instancia de servicio Campo tecnico

Los modos de realizacion de la presente invencion estan relacionados con el campo de las tecnologfas de las comunicaciones y, en particular, con un metodo, un equipo y un sistema para mapear una instancia de servicio.

Antecedentes

Con el respaldo de las tecnologfas de virtualizacion, la computacion en la nube puede proporcionar un fondo comun escalable de recursos de servicios de computacion, almacenamiento y aplicaciones. Una tendencia de desarrollo fundamental de la computacion en la nube es la construccion de una arquitectura de red que disponga de un centro de datos no bloqueante de alta capacidad, y sobre esta base se pueden ofrecer varios tipos de aplicaciones de servicio. Un dispositivo de red debe permitir una agrupacion (cluster) de servidores de mayor tamano, migrar una maquina virtual a un rango mas amplio cuando se solicita la maquina virtual, y garantizar la continuidad del servicio en un proceso de migracion. Por consiguiente, la computacion en la nube debera cumplir los siguientes tres requisitos de red:

1. Arquitectura de red no bloqueante y balanceo del trafico multiruta.

Las caractensticas de trafico de un centro de datos (Data Center, DC para abreviar) son: el trafico horizontal interno (trafico entre los servidores internos) es mayor que el trafico vertical (trafico entre un servidor interno y un cliente externo), y el trafico horizontal interno es en gran medida intermitente y no se puede planificar de antemano. En una arquitectura de red, en un centro de datos con la tecnologfa existente, para construir una interconexion interna no convergente se tiende a adoptar una forma de fat tree (arbol grueso). En una arquitectura de red fat tree, para satisfacer el requisito de conmutacion no bloqueante es necesario que la capa de control haga un buen uso de multiples rutas de igual coste entre los nodos de la red, con el fin de resolver el problema del aumento de conflictos del trafico horizontal en el centro de datos.

2. Utilizar una red L2 (esto es, la capa de enlace de datos, tambien denominada capa 2) grande para soportar una mayor agrupacion (cluster) de servidores y la migracion de maquinas virtuales.

Una tecnologfa L2 tradicional no es capaz de soportar multiples rutas de red, la tasa de utilizacion de una ruta valida de toda una red por parte de la red despues de haber eliminado los bucles mediante la utilizacion de una tecnologfa relacionada con el Spanning Tree Protocol (protocolo del arbol de expansion, STP para abreviar) es muy baja y una mayor agrupacion de servidores y un rango mas amplio de migracion de maquinas virtuales requieren una red L2 mayor. Una red L2 grande puede mejorar el rango de migracion de una maquina virtual asf como implementar una comparticion de servidores de amplio rango.

3. Una nube publica requiere una red que disponga de la capacidad de identificar a multiples arrendatarios, con el fin de mantener el control de los mismos.

En la construccion de una nube publica, para poder identificar los multiples arrendatarios se requiere un gran numero de instancias de servicio, y la forma de soportar en un dispositivo de red mas servicios de arrendatario representa tambien un problema. Por ejemplo, un centro de datos que incluye 500K maquinas virtuales necesita una capacidad para soportar mas de 10K instancias de servicio.

En la actualidad, las tecnologfas estandar de una red L2 grande en un centro de datos incluyen: la tecnologfa Transparent Interconnection of Lots of Links (Interconexion Transparente de Multiples Enlaces, TRILL para abreviar) del Internet Engineering Task Force (Grupo de Trabajo de Ingeniena de Internet, IETF para abreviar), y una tecnologfa 802.1aq del Institute of Electrical and Electronics Engineers (Instituto de Ingenieros Electricos y Electronicos, IEEE para abreviar). El principio basico de las dos es: calcular el Shortest Path First (Ruta Mas Corta Primero, SPF para abreviar) de un enlace de capa 2 en la capa 2, en funcion del estado de conexion de los puertos y enlaces utilizando el protocolo Intermediate System to Intermediate System (Sistema Intermedio a Sistema Intermedio, ISIS para abreviar), con el fin de obtener una ruta mas corta entre los dispositivos. En el plano de datos, las dos tecnologfas utilizan diferentes formatos de encapsulacion. La tecnologfa TRILL define una cabecera TRILL, y un paquete de capa-2 de un usuario se encapsula en la cabecera TRILL y se envfa salto a salto. El 802.1aq, esto es, el Shortest Path Bridging (puente de ruta mas corta, SPB para abreviar), utiliza un formato de encapsulacion mac- en-mac (MacInMac) definido por el 802.1ah, y define de forma espedfica una extension de la cabecera de difusion de acuerdo con un requisito del protocolo, en donde un MAC interna de una cabecera MacInMac es un paquete de capa-2 de un usuario. Las dos difieren en cierta medida en el plano de control del protocolo: el plano de control del protocolo TRILL implica menos calculo que el SPB, y a la vez, se puede equilibrar la utilizacion de los anchos de banda de la red mediante multiples rutas con igual coste (Equal Cost Multi-Path, ECMP para abreviar) salto a salto; sin embargo, una instancia de servicio actual del protocolo TRILL es un identificador de una red de area local virtual 802.1q (Virtual Local Area Network, VLAN para abreviar) en un paquete, en donde el identificador tiene un tamano de 12 bits (bits) en total, lo que permite hasta 4094 instancias de servicio como maximo, lo cual limita el numero de

5

10

15

20

25

30

35

40

45

50

55

arrendatarios que puede soportar una nube publica. El protocolo SPB utiliza principalmente la entrada de un servicio para realizar la comparticion de carga para multiples rutas, puede planificar el trafico del servicio a nivel global y puede soportar instancias de servicio de 16M bits (bits). El plano de control del protocolo SPB implica mas calculo que el TRILL. En el protocolo TRILL, un paquete de capa-2 de un usuario se encapsula mediante la utilizacion de la cabecera TRILL. La cabecera TRILL incluye un VLAN ID de un nodo de transmision de la red (VLAN externa). El calculo del enrutamiento ISIS se realiza en funcion del VLAN ID y en combinacion con un enlace interconectado. Un nodo intermedio en una ruta de reenvfo realiza un aprendizaje selectivo en funcion de si el nodo intermedio tiene la instancia de servicio (con una VLAN interna encapsulada en un paquete correspondiente), y se realiza el reenvfo a un puerto de usuario en un nodo de destino. El protocolo TRILL es un proceso de enrutamiento mediante rutas de igual coste para trafico disperso salto a salto sobre una ruta de reenvfo. En el SPB, un paquete de capa-2 de un usuario se encapsula mediante la utilizacion de encapsulacion MacInMac, y para transportar y enviar el paquete de usuario entre dispositivos de red se utilizan BMAC+BVLAN externos, y un identificador de servicio de usuario se identifica mediante un ISID (24 bits) en una I-TAG espedfica en la cabecera MacInMac. El SPB realiza el aprendizaje de reenvfo de acuerdo con el MAC+ISID. Un paquete de usuario puede adoptar multiples formas, incluyendo UN-TAG, TAG unica y TAG dual. En el plano de reenvfo del SPB, diferentes BVLAN forman multiples planos de reenvfo de igual coste; y a la vez, en la parte de acceso de usuario se puede especificar de forma flexible una regla de asociacion para asociar el paquete de usuario a un plano de reenvfo correspondiente.

Una vez que se ha especificado una relacion de asociacion en la entrada, el paquete de usuario llega a su dispositivo del nodo de destino a traves de una ruta fija extremo a extremo determinada mediante el calculo. La mayor diferencia entre los comportamientos de reenvfo del protocolo SPB y el protocolo TRILL consiste en que una ruta de reenvfo del protocolo SPB se determina extremo a extremo, su comparticion de la carga multiruta esta sujeta a la asignacion de trafico en la entrada, y el trafico se asocia a diferentes planos de reenvfo para su comparticion; mientras que el protocolo TRILL es un proceso de enrutamiento de rutas de igual coste para el trafico disperso salto a salto sobre una ruta de reenvfo.

Aunque el protocolo SPB puede proporcionar mas instancias de servicio (con un ISID de 24 bits) para satisfacer las necesidades de servicio, un modelo de trafico de reparto de carga del protocolo SPB consiste en realizar un enrutamiento fijo en la entrada. En comparacion con el protocolo TRILL, la modalidad de enrutamiento fijo del protocolo SPB no puede garantizar el equilibrio de la carga maxima de trafico, el propio centro de datos experimenta mucho trafico intermitente inestable, y es diffcil planificar la asociacion de forma apropiada de antemano sin un modelo claro del trafico. Por consiguiente, el protocolo SPB es mas vulnerable a la congestion en un punto de acceso. Por otro lado, en el caso de expansion de la red para un centro de datos con una arquitectura fat tree, el enrutamiento fijo del protocolo SPB da lugar facilmente a mas ECMP, y la utilizacion de una ruta valida en la red es baja cuando la ruta se planifica extremo a extremo; por su parte, el protocolo TRILL puede utilizar mejor una ruta valida en la red debido a la distribucion de la ruta mas corta salto a salto. En una arquitectura de red fat tree, las ECMP interconectadas de los nodos internos aumentan continuamente a medida que aumenta la escala de la red (suponiendo que la capacidad de los dispositivos es constante), y puede resultar cada vez mas diffcil utilizar completamente los anchos de banda de la red mediante la utilizacion del protocolo SPB para calcular el numero fijo de rutas extremo a extremo; la forma de equilibrar las ECMP salto a salto del protocolo TRILL es obviamente mejor.

En resumen, la forma de equilibrar las ECMP salto a salto del protocolo TRILL es obviamente mejor, aunque el numero de instancias de servicio es pequeno y no puede hacer frente a mas de 4K instancias de servicio. Por ejemplo, puede no ser capaz de satisfacer el requisito de multiples arrendatarios de una nube publica.

El documento de Radia Perlman Intel Labs Donald Eastlake 3rd Stellar Switches Dinesh G. Dutt Silvano Gai Cisco Systems Anoop Ghanwani Brocade "RBridges: Base Protocol Specification (RBridges: Especificacion del

Protocolo Base); draft-ietf-trill-rbridge-protocol-16" proporciona el protocolo TRILL general.

El documento EP 2 226 973 A1 proporciona metodos, equipos y productos para el enrutamiento de tramas en una red TRILL utilizando identificadores de VLAN de servicio.

El documento de Donald Eastlake 3rd: "Future TRILL Work 2 (Trabajo 2 sobre el TRILL Futuro)" proporciona soluciones para etiquetado de grano fino en TRILL. Se divulga la utilizacion de una etiqueta mac-en-mac como etiqueta. La etiqueta mac-en-mac no se divide en dos partes.

El documento de Emmanuel Hocdet "[rbridge] Break 4096 VLAN limit ([rbridge] Romper el lfmite de 4096 VLAN)" divulga la utilizacion de VLAN extendidas internas para romper el lfmite de VLAN en TRILL. Sin embargo, no divulga que la etiqueta se divide en dos partes, una superior y otra inferior.

Resumen

La presente invencion proporciona un metodo, un equipo y un sistema para mapear instancias de servicio, que se utilizan para superar un defecto de la tecnologfa actual consistente en que el protocolo TRILL soporta un numero pequeno de instancias de servicio, y para implementar el soporte de mas instancias de servicio.

La presente invencion se define en las reivindicaciones adjuntas.

5

10

15

20

25

30

35

40

45

50

En el metodo, el equipo y el sistema para mapear instancias de servicio de la presente invencion, despues de que se haya correlacionado una instancia de servicio de capa 2 con un puerto de acceso al servicio de la instancia de servicio se puede asociar un identificador de la instancia de servicio correspondiente al puerto de acceso al servicio a una etiqueta de servicio de un paquete. Como la etiqueta de servicio se utiliza para transportar el identificador de la instancia de servicio, se puede proporcionar una mayor capacidad de soporte de etiquetas de servicio, se pueden soportar mas instancias de servicio, y se puede satisfacer el requisito de multiples arrendatarios en un entorno de nube publica a gran escala; el soporte del protocolo de control se amplfa y la extension del protocolo TRILL puede ofrecer una mayor capacidad de desarrollo de servicios.

Breve descripcion de los dibujos

Con el fin de describir con mas claridad las soluciones tecnicas de los modos de realizacion de la presente invencion o de la tecnica anterior, a continuacion de introducen brevemente los dibujos adjuntos necesarios para describir los modos de realizacion o la tecnica anterior. Evidentemente, los dibujos que se adjuntan en la siguiente descripcion ilustran unicamente algunos modos de realizacion de la presente invencion, y a partir de dichos dibujos adjuntos las personas con un conocimiento normal de la tecnica todavfa pueden idear otros dibujos sin esfuerzos creativos.

La FIG. 1a es un diagrama de flujo de un metodo para mapear una instancia de servicio de acuerdo con el Modo de realizacion 1 de la presente invencion;

la FIG. 1b es un diagrama esquematico de un formato de encapsulacion 802.1q utilizado en un paquete TRILL en el metodo para mapear una instancia de servicio de acuerdo con el Modo de realizacion 1 de la presente invencion;

la FIG. 1c es un diagrama esquematico de un formato de encapsulacion de un paquete QinQ en el metodo para mapear una instancia de servicio de acuerdo con el Modo de realizacion 1 de la presente invencion;

la FIG. 1d es otro diagrama esquematico de un formato de encapsulacion 802.1q utilizado en un paquete TRILL en el metodo para mapear una instancia de servicio de acuerdo con el Modo de realizacion 1 de la presente invencion;

la FIG. 1e es un diagrama esquematico de una maquina de estados creada por un vecino de una P2P extendida en el metodo para mapear una instancia de servicio de acuerdo con el Modo de realizacion 1 de la presente invencion;

la FIG. 2a es un diagrama esquematico de un escenario de aplicacion de un metodo para mapear una instancia de servicio de acuerdo con el Modo de realizacion 2 de la presente invencion;

la FIG. 2b es un diagrama esquematico de otro escenario de aplicacion del metodo para mapear una instancia de servicio de acuerdo con el Modo de realizacion 2 de la presente invencion;

la FIG. 3 es un diagrama esquematico de la estructura de un equipo para mapear una instancia de servicio de acuerdo con el Modo de realizacion 3 de la presente invencion; y

la FIG. 4 es un diagrama esquematico de la estructura de un equipo para mapear una instancia de servicio de acuerdo con el Modo de realizacion 4 de la presente invencion.

Descripcion de los modos de realizacion

Con el fin de hacer mas comprensibles los objetivos, las soluciones tecnicas y las ventajas de los modos de realizacion de la presente invencion, a continuacion se describen de forma clara y completa las soluciones tecnicas de los modos de realizacion de la presente invencion haciendo referencia a los dibujos adjuntos en los modos de realizacion de la presente invencion. Evidentemente, los modos de realizacion que se van a describir son tan solo una parte, en lugar de todos los modos de realizacion de la presente invencion. Cualesquiera otros modos de realizacion obtenidos por personas con un conocimiento normal de la tecnica sin esfuerzos creativos a partir de los modos de realizacion de la presente invencion se consideraran dentro del alcance de proteccion de la presente invencion.

Modo de realizacion 1

La FIG. 1a es un diagrama de flujo de un metodo para mapear una instancia de servicio de acuerdo con el Modo de realizacion 1 de la presente invencion. Tal como se ilustra en la FIG. 1a, el metodo para mapear una instancia de servicio puede incluir espedficamente:

Paso 101: Correlacionar una instancia de servicio de capa 2 con un puerto de acceso al servicio de la instancia de servicio, y determinar la correspondencia entre el puerto de acceso al servicio y un identificador de la instancia de servicio.

La instancia de servicio en el modo de realizacion de la presente invencion es un servicio de red de capa 2 (capa de enlace de datos). En una red se afslan las diferentes instancias de servicio mediante aislamiento de capa-2, y la correlacion entre el puerto de acceso al servicio de la instancia de servicio y la instancia de servicio se puede especificar mediante una forma de configuracion basada en comandos. Por ejemplo:

[RB1] service instance 100 name "S1" // crear una instancia de servicio S1;

[PE2] interface vlanif 10

[PE1-Vlanif10] L2 binding service instance S1 // correlacionar la instancia de servicio S1 con la interfaz del puerto de acceso al servicio de VLAN vlanif 10.

5 Ademas, en una red determinada, cada instancia de servicio se corresponde con un identificador de instancia de servicio unico global, en donde el identificador de la instancia de servicio esta formado por un valor numerico, un alias alfanumerico, etc. Cuando la instancia de servicio se correlaciona con el puerto de acceso al servicio, a la instancia de servicio se le puede asignar un identificador de instancia de servicio correspondiente; o se puede configurar antes de la correlacion un identificador de la instancia de servicio correspondiente a la instancia de

10 servicio. El identificador de la instancia de servicio se puede asociar a una etiqueta de servicio en un paquete de datos, y transmitir entre los dispositivos. Ademas, en un escenario de multiples arrendatarios, un identificador de arrendatario es un identificador de uno de los arrendatarios. Un arrendatario puede contratar multiples instancias de servicio de capa 2 para satisfacer una necesidad de aplicacion de servicio del arrendatario, esto es, un identificador de arrendatario de un arrendatario puede corresponder a multiples identificadores de instancias de servicio.

15 Paso 102: Asociar el identificador de la instancia de servicio a una etiqueta de servicio de un paquete.

En particular, como el comportamiento de reenvfo definido por un protocolo TRILL puede hacer un mejor uso de la mejor ruta posible en la red e implementar una dispersion espacial optima del trafico, en el modo de realizacion de la presente invencion se consigue una mejora tomando a modo de ejemplo el protocolo de control TRILL. Un formato de un paquete TRILL es tal como se muestra en la siguiente Tabla 1.

20 Tabla 1 Formato de un paquete TRILL

Nombre del campo

OuterDMAC OuterSMAC OuterVlanTag TRILL Head User Pkt FCS

Numero de bytes

6 Bytes 6 Bytes 4 Bytes 4 Bytes

En la Tabla 1, el paquete TRILL incluye, de izquierda a derecha: una direccion MAC externa de destino (OuterDMAC) de 6 bytes (Bytes), una direccion MAC externa de origen (OuterSMAC) de 6 bytes, una etiqueta VLAN externa (OuterVlanTAG) de 4 bytes, una cabecera TRILL (TRILL Head) de 4 bytes, un paquete de datos de usuario (User Pkt), que es un paquete 802.1q de un usuario, y un control de trama y secuencia de control de trama (Frame 25 Check Sequence, FCS para abreviar) de 4 bytes al final. Las MAC externas son MAC puente de dispositivos. Si el paquete es un paquete de unidifusion, las MAC externas son MAC puente de dos dispositivos adyacentes; si el paquete es un paquete de difusion amplia, la MAC de origen es una MAC puente de un nodo de entrada, y la MAC de destino es una MAC de difusion amplia espedfica. En la cabecera TRILL se define el ID de un dispositivo que sirve como base para el enrutamiento del reenvfo de los paquetes. El formato de la cabecera TRILL es tal como se 30 muestra en la siguiente Tabla 2:

Tabla 2 Formato de una cabecera TRILL

TRILL Eth-type

V R M Op-Length Hop Count

Egress RBridge Nickname

Ingress Rbridge Nickname

Los campos de informacion importantes en la Tabla 2 son los siguientes: "TRILL Eth-type" es un tipo de TRILL Ethernet; "V" representa la version de TRILL, y es "0" antes de la extension, un paquete puede ser descartado directamente cuando se comprueba que "V" no es "0", y "V" se puede cambiar a "1" despues de la extension; "M" es 35 un indicador que indica si un paquete es un paquete de difusion amplia, en donde "0" representa unidifusion y "1" representa difusion amplia; "Op-Length" es la longitud de una opcion de extension de la cabecera TRILL, y utiliza 4 bytes como unidad, como maximo se puede soportar la definicion de una opcion de 124 bytes, y el primer byte de cada opcion en un area de opcion responde a un formato como el de la siguiente Tabla 3:

Tabla 3 Primer byte de una opcion

CHbH

CItE

Reservado

40 En la Tabla 3, si el bit CHbH es "1", ello indica que la opcion es salto a salto; mientras que si el CItE es "1", indica que la opcion es extremo a extremo.

Por otro lado, el ID de un dispositivo en una entrada (Ingress) de un paquete y el ID de un dispositivo en una salida (Egress) del paquete corresponden al alias de 16 bits de un puente de enrutamiento (RBridge Nickname) respectivamente. Para un paquete de unidifusion, el indicador "M" es "0", e "Ingress Rbridge Nickname " y "Egress

5

10

15

20

25

30

35

40

45

50

55

Rbridge Nickname " son alias de los dispositivos de red correspondientes a la entrada y a la salida, respectivamente; para un paquete de difusion amplia, el indicador "M" es "1", "Ingress Rbridge Nickname " es el alias de un dispositivo de entrada, y "Egress Rbridge Nickname " es el alias de un dispositivo de un nodo rafz del arbol de difusion utilizado.

En el protocolo TRILL se soporta una forma de encapsulacion de paquetes 802.1q en la parte de usuario, esto es, un paquete transportado actualmente en el campo "User Pkt" es un paquete 802.1q, que incluye una etiqueta VLAN (Vlan TAG). La etiqueta VLAN es una etiqueta de servicio y es valida globalmente en toda una red TRILL. La etiqueta VLAN puede ser la misma que la etiqueta VLAN de un usuario de acceso, o puede ser una etiqueta VLAN

nueva obtenida mediante conversion de VLAN. La FIG. 1b es un diagrama esquematico de un formato de

encapsulacion 802.1q utilizado en un paquete TRILL en el metodo para mapear una instancia de servicio de acuerdo con el Modo de realizacion 1 de la presente invencion. Tal como se ilustra en la FIG. 1b, la etiqueta VLAN (VLAN TAG) esta constituida por un identificador de protocolo de etiquetas (Tag Protocol Identifier, TPID para abreviar) de 2 bytes e informacion de control de etiqueta (Tag Control Information, TCI para abreviar) de 2 bytes, en donde el TPID es 8100 (hexadecimal), y la TCI incluye una informacion de prioridad (Priority Information, PRI para abreviar) de 3 bits que indica la prioridad, y una informacion de factor de congestion (Congestion Factor Information, CFI para abreviar) de 1 bit que indica si se ha experimentado congestion. Un ultimo campo VLAN (esto es, campo VLAN interna del paquete TRILL) puede almacenar un VLAN ID de 12 bits. En la red TRILL, teniendo en cuenta que se calculan multiples rutas desde cada nodo a los otros nodos en funcion de la topologfa de red y la sobrecarga de los enlaces, para un paquete de difusion amplia se puede realizar una poda de rutas de acuerdo con las instancias de

servicio (VLAN internas) de un nodo del flujo descendente. En consecuencia, en la red TRILL, el VLAN ID

almacenado del campo VLAN interna puede servir tanto como identificador de la instancia de servicio del usuario como etiqueta de poda de la ruta del paquete de difusion amplia. En la red TRILL, si el VLAN ID que se almacena del campo VLAN interna y sirve como identificador de la instancia de servicio y la etiqueta de poda de la ruta del paquete de difusion tiene 12 bits, se pueden soportar hasta 4094 VLAN internas. Como tanto el identificador de la instancia de servicio como la etiqueta de poda de la ruta de reenvfo en el protocolo TRILL son el VLAN ID almacenado del campo VLAN interna, se puede conseguir una capacidad espacial para soportar mas instancias de servicio mediante una forma de definir una etiqueta de servicio extendida del campo VLAN interna.

Por ejemplo, la etiqueta de servicio extendida puede tener 20 bits, y utilizando los 20 bits se pueden soportar 1M de instancias de servicio. De esta forma, el diseno del protocolo ISIS permite mantener el numero de nodos de la red por debajo de 1K en la medida de lo posible, con el fin de controlar las interfaces y la capacidad de conmutacion que los dispositivos de red pueden proporcionar realmente. 1M instancias de servicio pueden satisfacer el requisito de aplicacion de servicio de 1K nodos de la red, y tienen una gran potencialidad de permitir la expansion futura de la red. Una etiqueta de servicio obtenida mediante extension podra responder a los dos ejemplos siguientes:

Ejemplo 1: El formato de encapsulacion del paquete 802.1q se combina con una opcion de extension de la cabecera TRILL, de modo que mediante dicha extension se puede obtener una capacidad para soportar una etiqueta de servicio de 20 bits.

En el protocolo TRILL un paquete de usuario se encapsula en un formato de paquete 802.1q, se utiliza un campo VLAN (esto es, un campo VLAn interna del TRILL) en un campo TCI del paquete 802.1q para almacenar los 12 bits menos significativos de la etiqueta de servicio, y se extiende una opcion de la cabecera TRILL para albergar los otros 8 bits mas significativos de la etiqueta de servicio. Por supuesto, los 12 bits del campo VLAN interna del TRILL se pueden utilizar como los 12 bits mas significativos, y la opcion de la cabecera TRILL se puede extender para albergar los 8 bits menos significativos, o se pueden utilizar otras formas de combinacion disponibles. La opcion se puede extender a traves de un valor longitud del tipo (Type Length Value, TLV para abreviar) y ocupa 4 bytes. El formato de una opcion de extension puede ser tal como se muestra en la siguiente Tabla 4:

Tabla 4

CHbH

CItE Reserved Type Length Lable High8

Primer byte

Segundo byte Tercer byte Cuarto byte

Un primer byte de la opcion de extension de la cabecera TRILL puede ajustarse a la definicion del formato de cabecera estipulado en el protocolo TRILL. En el primer byte, CHbH es un bit indicador de salto a salto, y CItE es un bit indicador de extremo a extremo, que definen una forma de transportar la opcion respectivamente. Como el identificador unico de instancia de servicio se utiliza dentro de un unico campo TRILL, CHbH puede ser "0", CItE puede ser "1", y los restantes 6 bits reservados (Reserved) son "0". Un segundo byte puede ser la informacion de tipo (Type), y su valor se puede definir provisionalmente como "1". Un tercer byte puede ser la longitud del campo de informacion (Length) medida en bytes y se utiliza para definir la longitud de la opcion posterior, y su valor puede ser "1". Un cuarto byte pueden ser los 8 bits mas significativos de la etiqueta de servicio (Lable High8). La Tabla 4 muestra solo un ejemplo de un formato de opcion de extension, y la opcion de extension tambien puede ajustarse a otros formatos de definicion posibles.

Ejemplo 2: Para soportar una etiqueta de servicio de 20 bits o 24 bits se utiliza una forma de encapsulacion de

5

10

15

20

25

30

35

40

45

50

55

apilamiento dual de VLAN (802.1q en 802.1q, QinQ para abreviar) en un campo de un paquete de usuario.

La FIG. 1c es un diagrama esquematico de un formato de encapsulacion de paquetes QinQ en el metodo para mapear una instancia de servicio de acuerdo con el Modo de realizacion 1 de la presente invencion. Tal como se ilustra en la FIG. 1c, un paquete QinQ incluye una etiqueta (TAG) de VLAN interna y una etiqueta VLAN externa. Cada TAG de VLAN esta constituida por un TPID de 2 bytes y una TCI de 2 bytes. El TPID de la etiqueta externa (Outer TAG) es 88A8 (hexadecimal), y el TPID de la etiqueta interna (Inner tAg) es 8100 (hexadecimal). La TCI incluye una PRI de 3 bits que indica una prioridad, una CFI de 1 bit que indica si se ha experimentado congestion, y un campo VLAN de 12 bits al final.

Cuando se adopta un formato de encapsulacion QinQ, el campo VLAN de la etiqueta interna se puede utilizar para almacenar los 12 bits menos significativos de una etiqueta de servicio, los 8 bits menos significativos (que tambien pueden ser los 8 bits mas significativos, u 8 bits seleccionados de otra forma) de los 12 bits del campo VLAN de la etiqueta externa se pueden utilizar para almacenar los 8 bits mas significativos de la etiqueta de servicio, y los 4 bits mas significativos restantes pueden ser un campo reservado. Por supuesto, el campo VLAN de la etiqueta interna se puede utilizar para almacenar los 12 bits mas significativos de la etiqueta de servicio, y los 8 bits menos significativos (que tambien pueden ser los 8 bits mas significativos, u 8 bits seleccionados de otra forma) de los 12 bits del campo VLAN de la etiqueta externa se pueden utilizar para almacenar los 8 bits menos significativos de la etiqueta de servicio. Mediante la utilizacion del formato de encapsulacion QinQ, se puede conseguir la capacidad para soportar una etiqueta de servicio de 20 bits mediante extension.

Ademas, los 12 bits del campo VLAN de la etiqueta interna y los 12 bits del campo VLAN de la etiqueta externa se pueden utilizar conjuntamente para almacenar la etiqueta de servicio. Por ejemplo, los 12 bits del campo VLAN de la etiqueta interna pueden almacenar los 12 bits mas significativos de la etiqueta de servicio, y los 12 bits del campo VLAN de la etiqueta externa pueden almacenar los 12 bits menos significativos de la etiqueta de servicio; o los 12 bits del campo VLAN de la etiqueta interna pueden almacenar los 12 bits menos significativos de la etiqueta de servicio, y los 12 bits del campo VLAN de la etiqueta externa pueden almacenar los 12 bits mas significativos de la etiqueta de servicio. Mediante la utilizacion del formato de encapsulacion QinQ se puede conseguir la capacidad para soportar una etiqueta de servicio de hasta 24 bits mediante extension.

Las formas anteriores de extender la etiqueta de servicio son solo algunos ejemplos. Las capacidades de la etiqueta de servicio no se limitan a las dos capacidades que soportan 20 bits y 24 bits, y tambien puede haber otras capacidades que soporten mas de 12 bits. La extension se puede aplicar espedficamente en funcion de las necesidades de un escenario de aplicacion.

Preferiblemente, despues de adoptar la etiqueta de servicio extendida, la informacion del numero de version "V" en la cabecera TRILL se puede actualizar de "0" a "1", lo que impide que un dispositivo que no soporte la etiqueta de servicio extendida pueda llevar a cabo una determinacion de analisis incorrecta. Por supuesto, tambien es posible no realizar la actualizacion, sino que se obtenga un TLV correspondiente a traves de un plano de control, y se asegure directamente una relacion de conexion correcta en el proceso de creacion de una relacion de vecindad mediante un paquete HELLO (Hola) de sistema intermedio a sistema intermedio (IS-IS HELLO, IIH para abreviar).

Ademas, de acuerdo con los ejemplos anteriores de una definicion de etiqueta de servicio, el paso 102 puede adoptar espedficamente una cualquiera de las siguientes formas:

Forma 1: De acuerdo con el ejemplo 1 anterior, el identificador de instancia de servicio se puede asociar a un campo de red de area local virtual de una primera etiqueta de red de area local virtual de un paquete de Interconexion Transparente de Multiples Enlaces, y a una opcion de extension de la cabecera de un paquete de Interconexion Transparente de Multiples Enlaces, en donde el campo de red de area local virtual de la primera etiqueta de red de area local virtual del paquete de Interconexion Transparente de Multiples Enlaces y la opcion de extension de la cabecera de un paquete de Interconexion Transparente de Multiples Enlaces forman la etiqueta de servicio;

por ejemplo, los 12 bits menos significativos del identificador de la instancia de servicio se asocian al campo de red de area local virtual de la primera etiqueta de red de area local virtual del paquete de Interconexion Transparente de Multiples Enlaces, y los 8 bits mas significativos del identificador de la instancia de servicio se asocian a la opcion de extension de la cabecera del paquete de Interconexion Transparente de Multiples Enlaces; o

los 12 bits mas significativos del identificador de la instancia de servicio se asocian al campo de red de area local virtual de la primera etiqueta de red de area local virtual del paquete de Interconexion Transparente de Multiples Enlaces, y los 8 bits menos significativos del identificador de la instancia de servicio se asocian a la opcion de extension de la cabecera del paquete de Interconexion Transparente de Multiples Enlaces.

Forma 2: De acuerdo con el ejemplo 2 anterior, el identificador de la instancia de servicio se asocia a un campo de red de area local virtual de una primera etiqueta externa y a un campo de red de area local virtual de una primera etiqueta interna en un paquete de apilamiento de red de area local virtual de dos capas, en donde el campo de red de area local virtual de la primera etiqueta externa y el campo de red de area local virtual de la primera etiqueta interna en el paquete de apilamiento de red de area local virtual de dos capas forman la etiqueta de servicio. Por ejemplo:

5

10

15

20

25

30

35

40

45

50

55

los 8 bits mas significativos del identificador de la instancia de servicio se asocian al campo de red de area local virtual de la primera etiqueta externa en el paquete de apilamiento de red de area local virtual de dos capas, y los 8 bits menos significativos del identificador de la instancia de servicio se asocian al campo de red de area local virtual de la primera etiqueta interna en el paquete de apilamiento de red de area local virtual de dos capas; o

los 8 bits menos significativos del identificador de la instancia de servicio se asocian al campo de red de area local

virtual de la primera etiqueta externa en el paquete de apilamiento de red de area local virtual de dos capas, y los 8 bits mas significativos del identificador de la instancia de servicio se asocian al campo de red de area local virtual de la primera etiqueta interna en el paquete de apilamiento de red de area local virtual de dos capas; o

los 12 bits mas significativos del identificador de la instancia de servicio se asocian al campo de red de area local virtual de la primera etiqueta externa en el paquete de apilamiento de red de area local virtual de dos capas, y los 12 bits menos significativos del identificador de la instancia de servicio se asocian al campo de red de area local virtual de la primera etiqueta interna en el paquete de apilamiento de red de area local virtual de dos capas; o

los 12 bits menos significativos del identificador de la instancia de servicio se asocian al campo de red de area local

virtual de la primera etiqueta externa en el paquete de apilamiento de red de area local virtual de dos capas, y los 12 bits mas significativos del identificador de la instancia de servicio se asocian al campo de red de area local virtual de la primera etiqueta interna en el paquete de apilamiento de red de area local virtual de dos capas.

Ademas, en el metodo para mapear una instancia de servicio se puede seguir conservando un identificador de red de area local virtual original, y el identificador de red de area local virtual se puede asociar a un campo de red de area local virtual original, lo cual tambien puede incluir espedficamente los siguientes ejemplos:

Ejemplo 1: el identificador de red de area local virtual de la instancia de servicio se asocia a un campo de red de area local virtual de una segunda etiqueta de red de area local virtual en el paquete de Interconexion Transparente de Multiples Enlaces.

La FIG. 1d es otro diagrama esquematico de un formato de encapsulacion 802.1q utilizado en un paquete TRILL en el metodo para mapear una instancia de servicio de acuerdo con el Modo de realizacion 1 de la presente invencion. Tal como se ilustra en la FIG. 1d, la primera etiqueta de red de area local virtual en el paquete de Interconexion Transparente de Multiples Enlaces (TRILL) mencionado en el ejemplo anterior puede ser una VLANTAG (tambien se puede hacer referencia a la Fig. 1b), y la segunda etiqueta de red de area local virtual en el paquete TRILL puede ser una VLANTAG' recien creada; por supuesto, tambien es factible que la primera etiqueta de red de area local virtual sea una VLANTAG' y la segunda etiqueta de red de area local virtual sea una VLANTAG. De esta forma, el paquete TRILL no solo puede transportar el identificador de la instancia de servicio en la primera etiqueta de red de area local virtual, sino que tambien puede transportar el identificador de VLAN original de la instancia de servicio en la segunda etiqueta de red de area local virtual, con el fin de mantener la compatibilidad con el protocolo TRILL original.

Ejemplo 2: El identificador de red de area local virtual de la instancia de servicio se asocia a un campo de red de area local virtual de una segunda etiqueta externa y/o un campo de red de area local virtual de una segunda etiqueta interna en un paquete de apilamiento de red de area local virtual de dos capas.

Al igual que en el ejemplo 1, a partir de la FIG. 1c, se pueden agregar una OuterTAG' y una InnerTAG' nuevas. Si la primera etiqueta externa del paquete de apilamiento de red de area local virtual de dos capas (QinQ) es una OuterTAG, la segunda etiqueta externa es una OuterTAG'; si la primera etiqueta interna es una InnerTAG, la segunda etiqueta interna es una InnerTAG', y viceversa. El identificador de VLAN original de la instancia de servicio es transportado en la segunda etiqueta externa y/o la segunda etiqueta interna. Con el fin de mantener la compatibilidad con el protocolo TRILL original se pueden transportar tanto la etiqueta de servicio como el identificador de VLAN.

En una red TRILL, una instancia de servicio de capa 2 se identifica mediante la utilizacion de una etiqueta de servicio extendida, y para satisfacer las necesidades de acceso por parte de un usuario del centro de datos se requiere un modo mas flexible de asociar servicios. Un puerto de acceso en la parte del usuario puede incluir una forma de encapsulacion de VLAN simple y una forma de encapsulacion QinQ. Ambas formas de encapsulacion se pueden asociar de forma flexible a una etiqueta de servicio extendida y convertirse en una instancia de servicio. Una VLAN en la parte de acceso, independientemente de si se basa en la forma de encapsulacion de VLAN simple o en QinQ, puede utilizar una VLAN local de un nodo local, y no es necesaria la coherencia global. A traves de algunas modificaciones realizadas sobre la base del protocolo TRILL original se puede disponer de una solucion de etiquetas de servicio de mayor capacidad.

En el protocolo TRILL original, un identificador de VLAN de una instancia de servicio se almacena directamente en un campo VLAN en un campo TCI de un paquete que utiliza un formato de encapsulacion 802.1q. Despues de haber extendido la etiqueta de servicio se pueden extender los 2 bytes del campo VLAN original a 4 bytes capaces de almacenar la etiqueta de servicio extendida. En los 4 bytes, los 24 bits menos significativos alojan la etiqueta de servicio extendida, y 1 byte esta reservado. Ademas, para transmitir la capacidad de soporte de etiquetas de servicio del nodo, a un paquete Hello se le puede agregar un TLV extendido, por ejemplo un TLV de capacidad de soporte

de etiquetas de servicio (Service label Capability). La forma de seleccion de una etiqueta de servicio definitiva del sistema se determina mediante negociacion. Haciendo referencia a la Tabla 5, la Tabla 5 muestra los TLV relevantes de capa 2 de un protocolo TRILL modificado.

Tabla 5 Forma de extension del protocolo TRILL

Etapa de Aplicacion

Tipo de TLV Subtipo de TLV Esquema de Modificacion

LSP

TLV de Accesibilidad MAC Modificar RSV+VLAN (2 bytes) a Reservado (1 byte)+ServiceLable (3 bytes) [4 bytes en total]

IIH

TLV de Capacidad de Puertos que permiten Multiples Topologfas sub-TLV de VLAN Especiales e Indicadores Mantener el contenido y el formato inalterados; sin embargo, teniendo en cuenta que una forma de mapeo de una etiqueta de servicio extendida sobrepasa la funcion de mapeo de VLAN (VLANMapping) definida en el TRILL original, es factible suprimir en ella un campo OuterVLAN, y configurar y almacenar informacion de asociacion y un indicador a traves de un nodo local en lugar de transmitir la informacion de asociacion y el indicador

IIH

sub-TLV de VLAN Habilitadas Extender un VLAN para una etiqueta de servicio, modificar un VLAN ID Inicial de 2 bytes a una etiqueta de servicio ServiceLable (3 bytes) + reservado (1 byte), y modificar un mapa de bits (bitmap) de VLAN a un mapa de bits de etiquetas de servicio (ServiceLable bitmap)

IIH

sub-TLV de Reemisores Designados Sin modificacion

LSP

sub-TLV de Version de TRILL Mantener el formato inalterado. Permitir que una version del TRILL sea 1 unidad mayor que la version actual del TRILL. Por ejemplo, el numero de version es "1"

LSP

sub-TLV de Alias Sin modificacion

LSP

sub-TLV de Arboles Sin modificacion

LSP

TLV de sub-TLV de Identificadores de Arbol Sin modificacion

LSP

Capacidad del Router sub-TLV de Identificadores Utilizados de Arbol Sin modificacion

LSP

sub-TLV de VLAN Interesadas y Rafces de Arbol de Expansion Sin modificacion; el escenario de aplicacion puede estar limitado a acceso de VLAN simple, y el QinQ puede no estar soportado

LSP

sub-TLV del Grupo de VLAN Sin modificacion; el sub-TLV puede no ser utilizado; la nueva ServiceLable es independiente de una VLAN; y el aprendizaje compartido puede no ser distinguible del aprendizaje independiente

LSP

TLV de Direccion del Grupo sub-TLV de Direccion MAC del Grupo Extender un VLAN para una etiqueta de servicio, y modificar un RESV + VLAN ID original de 2 bytes a una ServiceLable (3 bytes) + reservado (1 byte)

IIH

TLV de Capacidad de Etiquetas de Servicio Transportar el TLV en el paquete Hello

5 De acuerdo con la Tabla 5, el metodo para mapear una instancia de servicio puede incluir, ademas, uno cualquiera de los siguientes pasos:

enviar un mensaje de acceso inicial (IIH) que incluye un TLV de Capacidad de Puertos que soportan Multiples Topologfas (Multi Topology aware Port Capability TLV), en donde un sub-TLV de VLAN habilitadas (Enabled-VLANs sub-TLV) de la capacidad de puertos que soportan multiples topologfas incluye un campo de informacion de etiqueta 10 de servicio (ServiceLable) extendida;

5

10

15

20

25

30

35

40

45

enviar un mensaje de provision de servicio por capas (LSP) que incluye un TLV de Accesibilidad del MAC (MAC Reachability TLV), en donde la accesibilidad del control de acceso al medio incluye un campo de informacion de etiqueta de servicio (ServiceLable) extendida; y

enviar un mensaje de provision de servicio por capas que incluye un TLV de Direccion de Grupo (Group Address TLV), en donde una Direccion MAC de Grupo (Group MAC Address sub-TLV) de la direccion del grupo incluye un campo de informacion de etiqueta de servicio extendida.

Ademas, en la Tabla 5, hay un TLV de Capacidad de Etiquetas de Servicio, que es un nuevo TLV extendido, para cuyo formato, se puede hacer referencia a la siguiente Tabla 6:

Tabla 6

Campo

Numero de Bytes

Tipo = Srv-Cap

1 byte

Longitud

1 byte

Resv Anuncio de Capacidad de etiquetas de Servicio | T3 | T2 | T1

1 byte

Resv Negociacion de etiqueta de Servicio | T3 | T2 | T1

1 byte

En la Tabla 6, "Tipo" se refiere a un tipo de TLV, y, por ejemplo, puede tener un valor "146"; "Longitud" se refiere a la longitud de la informacion TLV, y, por ejemplo, puede tener un valor "2"; "Anuncio de Capacidad de etiquetas de Servicio" se refiere al anuncio de la forma de una etiqueta de servicio del nodo, en donde "T1" se refiere al transporte de una etiqueta de 20 bits en una forma de QinQ, "T2" se refiere al soporte de una etiqueta de 20 bits en una forma de extension de una opcion de cabecera TRILL, y "T3" se refiere al transporte de una etiqueta de 24 bits en una forma de QinQ. "Negociacion de etiqueta de Servicio" se refiere a la negociacion entre nodos para determinar finalmente una forma de transportar la etiqueta entre los nodos, en donde "T1, T2, y T3" tienen las mismas definiciones que las descritas anteriormente. En el proceso de negociacion se aplica una forma de negociacion en tres etapas (three-way handshake), y, cuando se crea una relacion de vecindad, se selecciona una forma de utilizacion y se negocia sobre como utilizar una etiqueta de servicio. Posteriormente, el proceso de negociacion de la capacidad de interaccion de la etiqueta se puede anadir en una etapa IIH. En particular, la forma de negociacion en tres etapas se utiliza en la etapa IIH para agregar un nuevo TLV de Capacidad de etiquetas de Servicio extendidas a un paquete inicial. Un nodo local difunde su capacidad de etiquetas de servicio en el paquete inicial. Al recibir el anuncio, un vecino de un nodo equivalente devuelve un TLV de Capacidad de etiquetas de Servicio de acuerdo con su propia condicion de adaptacion de capacidad, y, a la vez, envfa un TLV de adyacencia punto a punto en tres etapas (Point-to-Point Three-Way Adjacency) para devolver el resultado de su propio procesamiento. Si la capacidad de soporte de etiquetas de servicio del nodo local coincide con la capacidad de soporte de etiquetas de servicio del nodo equivalente, se puede crear una relacion de vecindad. En consecuencia, el metodo para mapear una instancia de servicio puede incluir, ademas, una etapa de negociacion, por parte de los dispositivos adyacentes, de la capacidad de soporte de etiquetas de servicio en el proceso de establecimiento inicial de una conexion mediante una negociacion, que incluye espedficamente:

recibir un mensaje de acceso inicial que incluye la capacidad de soporte de etiquetas de servicio de un nodo equivalente y un estado de negociacion en tres etapas que indica el estado no conectado;

negociar de acuerdo con una capacidad de soporte de etiquetas de servicio del nodo local y la capacidad de soporte de etiquetas de servicio del nodo equivalente con el fin de determinar una capacidad de soporte de etiquetas de servicio para establecer una conexion; y

enviarle al nodo equivalente una notificacion que incluye la capacidad de soporte de etiquetas de servicio para establecer una conexion, e indica que el estado de la negociacion en tres etapas ha cambiado a un estado de conexion establecida.

La negociacion de acuerdo con una capacidad de soporte de etiquetas de servicio del nodo local y la capacidad de soporte de etiquetas de servicio del nodo equivalente con el fin de determinar una capacidad de soporte de etiquetas de servicio para el establecimiento de una conexion puede incluir, espedficamente:

si la capacidad de soporte de etiquetas de servicio del nodo local coincide con la capacidad de soporte de etiquetas de servicio del nodo equivalente, cambiar el estado de la negociacion en tres etapas al estado de conexion establecida y determinar como capacidad de soporte de etiquetas de servicio para establecer una conexion la capacidad coincidente de soporte de etiquetas de servicio; o

si la capacidad de soporte de etiquetas de servicio del nodo local no coincide con la capacidad de soporte de etiquetas de servicio del nodo equivalente, determinar como capacidad de soporte de etiquetas de servicio para

establecer una conexion la menor capacidad de soporte de etiquetas de servicio entre la capacidad de soporte de etiquetas de servicio del nodo local y la capacidad de soporte de etiquetas de servicio del nodo equivalente.

En particular, en el modo de realizacion de la presente invencion se modifica una maquina de estados creada por un vecino punto a punto (P2P). El proceso de creacion de una maquina de estados por un vecino P2P original es tal 5 como se muestra en la siguiente Tabla 7:

Tabla 7 maquina de estados creada por un vecino P2P original

Estado de Adyacencia de Tres etapas Recibido

No conectado (Abajo)

Inicializando (Inicializando) Conexion establecida (Arriba)

Estado de Adyacencia de Tres etapas

Abajo Inicializar Arriba Abajo

Inicializando

Inicializar Arriba Arriba

Arriba

Inicializar Aceptar Aceptar

La FIG. 1e es un diagrama esquematico de una maquina de estados creada por un vecino de una P2P extendida en el metodo para mapear una instancia de servicio de acuerdo con el Modo de realizacion 1 de la presente invencion. Tal como se ilustra en la FIG. 1e, cuando se recibe un mensaje de IIH que contiene una etiqueta de servicio y el 10 estado de la negociacion en tres etapas es no conectado (Abajo), el nodo local tiene que determinar, de acuerdo con la capacidad de soporte de etiquetas de servicio del nodo local, si es posible crear una relacion de vecindad con el nodo equivalente. Si las capacidades de soporte de etiquetas de servicio no coinciden, el nodo local le notifica al nodo equivalente el estado Abajo mediante un TLV de estado de la negociacion en tres etapas e incluye su propia capacidad de soporte de etiquetas de servicio. Si las capacidades de soporte de etiquetas de servicio de ambos 15 lados coinciden, el nodo local puede cambiar el estado al estado de conexion establecida (Arriba), le asigna al TLV de estado de la negociacion en tres etapas el estado ARRIBA, y se lo notifica al nodo equivalente junto con su propia capacidad de soporte de etiquetas de servicio. Despues de agregar la verificacion de la capacidad de soporte de etiquetas de servicio, la creacion del vecino P2P puede ser tal como se muestra en la Tabla 8.

Tabla 8 Maquina de estados creada por un nuevo vecino P2P

Estado de Adyacencia de Tres etapas Recibido

No conectado (Abajo)

Inicializando (Inicializando) Conexion establecida (Arriba)

Estado de Adyacencia de Tres etapas

Abajo Inicializar (Inicializar/Abajo) Arriba/Abajo Abajo

Inicializando

Inicializar Arriba Arriba

Arriba

Inicializar Aceptar Aceptar

20 En la Tabla 8, si el estado del nodo local es Abajo, cuando el mensaje IIH recibido desde el nodo equivalente incluye la capacidad de soporte de etiquetas de servicio y el estado del nodo equivalente es Abajo, se comprueba si la capacidad de soporte de etiquetas de servicio del nodo local coincide con la capacidad de soporte de etiquetas de servicio del nodo equivalente. Si ambas coinciden, el estado del nodo local se puede modificar a Inicializar; si ambas no coinciden, el estado del nodo local permanece como Abajo. Si el estado del nodo local es Inicializando, cuando el 25 mensaje IIH recibido desde el nodo equivalente incluye la capacidad de soporte de etiquetas de servicio y el estado del nodo equivalente es Abajo, se comprueba si la capacidad de soporte de etiquetas de servicio del nodo local coincide con la capacidad de soporte de etiquetas de servicio del nodo equivalente. Si ambas coinciden, el estado del nodo local se modifica a Arriba; en caso contrario, el estado del nodo local se mantiene como Abajo.

Ademas, si un nodo capaz de identificar una etiqueta de servicio crea una relacion de vecindad con un nodo incapaz 30 de identificar una etiqueta de servicio, o si un nodo con una capacidad de soporte de etiquetas de servicio elevada no crea ninguna relacion de vecindad con otro nodo de alta capacidad, la capacidad de soporte de etiquetas de servicio se puede reducir, de tal modo que se crea una relacion de vecindad con un nodo de baja capacidad mediante la utilizacion de una capacidad de soporte de etiquetas de servicio mas baja, tal como una version antigua de TLV. De este modo, despues de que un nodo de alta capacidad haya creado una relacion de vecindad con un 35 nodo de baja capacidad, el nodo de alta capacidad pasa a comportarse como un nodo de baja capacidad, asegurando de esta forma la conexion efectiva de la red.

En los modos de realizacion, despues de que se haya correlacionado una instancia de servicio de capa 2 con un puerto de acceso al servicio de la instancia de servicio, se puede asociar un identificador de la instancia de servicio correspondiente al puerto de acceso al servicio a una etiqueta de servicio de un paquete. Como se utiliza la etiqueta 40 de servicio para transportar el identificador de la instancia de servicio, se puede proporcionar una mayor capacidad

5

10

15

20

25

30

35

40

45

50

de soporte de etiquetas de servicio, se pueden soportar mas instancias de servicio, y se puede satisfacer el requisito de multiples arrendatarios en un entorno de nube publica a gran escala, lo que constituye una solucion L2 general; el soporte del protocolo de control se amplfa, la extension del protocolo TRILL puede proporcionar una mayor capacidad de desarrollo de servicios, y se pueden soportar multiples escenarios de servicio mediante formas flexibles para mapear servicios.

Modo de realizacion 2

La FIG. 2a es un diagrama esquematico de un escenario de aplicacion de un metodo para mapear una instancia de servicio de acuerdo con el Modo de realizacion 2 de la presente invencion. Tal como se ilustra en la FIG. 2a, la arquitectura ffsica basica de una red de datos de un centro de datos incluye: un dispositivo 21 de acceso, un dispositivo 23 de convergencia, un dispositivo troncal 25, y un router 27 de salida. Dichos dispositivos conforman una red para conectar un servidor ffsico 20 del centro de datos a una red externa 30. En una red real, las formas de los dispositivos ffsicos son como sigue: el dispositivo de acceso y el dispositivo de convergencia pueden ser un conmutador de tipo bastidor o de tipo caja, el dispositivo troncal puede ser un conmutador de tipo bastidor, y el dispositivo de convergencia y el dispositivo troncal pueden estar integrados en uno con el fin de simplificar la jerarqma de la red.

La FIG. 2b es un diagrama esquematico de otro escenario de aplicacion del metodo para mapear una instancia de servicio de acuerdo con el Modo de realizacion 2 de la presente invencion. Tal como se ilustra en la FIG. 2b, como un servidor puede soportar la virtualizacion, en un servidor ffsico 20 se pueden crear multiples maquinas virtuales (Virtual Machine, VM para abreviar) mediante virtualizacion utilizando un software, y se pueden conectar al dispositivo 21 de acceso a traves de un conmutador virtual de software (Virtual Switch, VSW para abreviar) que se crea mediante virtualizacion utilizando un software del servidor ffsico 20.

El metodo para mapear una instancia de servicio en el modo de realizacion de la presente invencion se puede implementar en el dispositivo 21 de acceso, el dispositivo 23 de convergencia, y el dispositivo troncal 25. El dispositivo de acceso implementa fundamentalmente el acceso al servicio en la parte de usuario. El dispositivo de acceso solo puede realizar el etiquetado de VLAN, y un dispositivo de convergencia de nivel superior correlaciona un puerto de acceso al servicio con una instancia de servicio para implementar la asociacion entre un identificador de instancia de servicio y un paquete; o el dispositivo de acceso puede correlacionar el puerto de acceso al servicio con la instancia de servicio despues de haber realizado el etiquetado VLAN, y a continuacion, asociar directamente el identificador de la instancia de servicio a una etiqueta de servicio del paquete. El dispositivo 23 de convergencia y el dispositivo troncal 25 pueden actuar como nodos de acceso de la instancia de servicio, nodos intermedios para el reenvfo de la instancia de servicio, o nodos frontera para la conversion de la instancia de servicio. Cuando el dispositivo de convergencia y el dispositivo troncal actuan como nodos de acceso de la instancia de servicio, un nodo de acceso correspondiente unicamente implementa el etiquetado VLAN simple o el etiquetado QinQ de un servicio de usuario, y el dispositivo 23 de convergencia o el dispositivo troncal 25 correlacionan el puerto de acceso al servicio con la instancia de servicio con el fin de llevar a cabo la asociacion del identificador de la instancia de servicio con el paquete. Si el dispositivo 23 de convergencia o el dispositivo troncal 25 actuan como nodos intermedios, el dispositivo 21 de acceso puede llevar a cabo la asociacion de una interfaz de acceso al servicio del usuario con la instancia de servicio, y el dispositivo 23 de convergencia o dispositivo troncal 25 llevan a cabo la interconexion de la instancia de servicio entre diferentes nodos de acceso.

Adicionalmente, el servidor ffsico puede acceder al dispositivo de acceso sin una etiqueta (UNTAG) o utilizando una tarjeta de red para vincular una etiqueta de servicio. El VSW se puede interconectar con el dispositivo de acceso de tres formas: como puente virtual frontera (Virtual edge bridge, VEB para abreviar), como agregador de puertos virtual frontera (Virtual edge port aggregator, VEPA para abreviar), y como multicanal (Multi-Channel). El VEB puede realizar la conmutacion del puerto interno, enviar trafico externo, y encapsular un paquete de usuario en forma de VLAN simple; el VEPA no realiza la conmutacion del nodo local, sino que envfa todo el trafico a un dispositivo de acceso externo para su conmutacion y encapsula un paquete de usuario en forma de VLAN simple; y el modo Multicanal corresponde a multiples vEb y VEPA, y accede a un conmutador de acceso vinculando una VLAN externa.

En resumen, las formas de asociacion y despliegue de las etiquetas de servicio en un centro de datos incluyen varias combinaciones, que son espedficamente tal como se muestra en la siguiente Tabla 9:

Tabla 9 Formas de combinar la asociacion y despliegue de etiquetas de servicio

Forma de Combinacion

Servidor Ffsico VSW Dispositivo de Acceso Dispositivo de Convergencia y Dispositivo troncal

1

Acceso UNTAG Agrega una VLAN de acuerdo con un puerto de acceso de usuario para obtener un puerto de acceso al servicio, correlaciona el puerto de acceso al servicio con una instancia de servicio y asocia un identificador de la Actuan como dispositivos intermedios

instancia a una etiqueta de servicio de un paquete

2

Acceso UNTAG Agrega una VLAN de acuerdo con un puerto de acceso de usuario para obtener un puerto de acceso al servicio Correlacionan el puerto de acceso al servicio del dispositivo de acceso con una instancia de servicio y asocian un identificador de la instancia de servicio a una etiqueta de servicio de un paquete

3

Acceso utilizando una tarjeta de red para vincular una VLAN Reasigna una VLAN de acuerdo con un puerto de acceso de usuario para obtener un puerto de acceso al servicio, y asocia el puerto de acceso al servicio a la etiqueta de servicio de un paquete; se puede optar por aceptar una etiqueta de prioridad en una VLAN de usuario o realizar una reasignacion para modificar la etiqueta de prioridad Actuan como dispositivos intermedios

4

Acceso utilizando una tarjeta de red para vincular una VLAN Reasigna un encapsulado VLAN o QinQ de acuerdo con un puerto de acceso de usuario para obtener un puerto de acceso al servicio; se puede optar por aceptar una etiqueta de prioridad en una VLAN de usuario o realizar una reasignacion para modificar la etiqueta de prioridad La asocian a una etiqueta de servicio de un paquete de acuerdo con el puerto de acceso al servicio del dispositivo de acceso

5

Modo VEB Modo VEPA Asocia un puerto de acceso VSW+VLAN (puerto de acceso al servicio) a la etiqueta de servicio de un paquete; se puede optar por aceptar una etiqueta de prioridad en una VLAN de un paquete de acceso o realizar una reasignacion para modificar la etiqueta de prioridad Actuan como dispositivos intermedios

6

Modo VEB Modo VEPA Reasigna un encapsulado VLAN o QinQ de acuerdo con un puerto de acceso VSW para obtener un puerto de acceso al servicio; se puede optar por aceptar una etiqueta de prioridad en una VLAn de un paquete de acceso o realizar una reasignacion para modificar la etiqueta de prioridad La asocian a una etiqueta de servicio de un paquete de acuerdo con el puerto de acceso al servicio del dispositivo de acceso

7

Modo Multi canal Combina una SVLAN externa de un encapsulado QinQ Multicanal con una CVLAN interna para obtener un puerto de acceso al servicio, que se asocian conjuntamente a una etiqueta de servicio de un paquete; se puede optar por aceptar una etiqueta de prioridad en una VLAN de un paquete de acceso o realizar una reasignacion para modificar la etiqueta de prioridad Actuan como dispositivos intermedios

8

Modo Multi canal Combina una SVLAN externa de un encapsulado QinQ Multicanal con una CVLAN interna y las asocia conjuntamente al encapsulado QinQ para obtener un puerto de acceso al servicio; se puede optar por aceptar una etiqueta de prioridad en una VLAN de un paquete de acceso o realizar una reasignacion para modificar la etiqueta de prioridad La asocian a una etiqueta de servicio de un paquete de acuerdo con el puerto de acceso al servicio del dispositivo de acceso

El puerto de acceso al servicio en la Tabla 9 adopta correspondientemente la forma de "puerto de acceso de usuario+VLAN", "puerto de acceso de usuario+QinQ", "puerto de acceso VSW+VLAN", "puerto de acceso VSW+QinQ", o "SVLAN+CVLAN".

En este modo de realizacion, para almacenar un identificador de VLAN se utiliza una etiqueta de servicio extendida

5

10

15

20

25

30

35

40

45

50

55

en un protocolo TRILL, y se puede proporcionar una capacidad para soportar una etiqueta de servicio de 20/24 bits, lo que permite hacer un uso completo de un ruta de igual coste en una red, soportar mas instancias de servicio en combinacion con una aplicacion de ruta mas corta, y se puede satisfacer el requisito de aislamiento de una red L2 de multiples arrendatarios en un entorno de nube publica a gran escala, lo que constituye una solucion L2 general; el soporte del protocolo de control se amplfa, la extension del protocolo TRILL puede proporcionar una mayor capacidad de desarrollo de servicios, y se pueden soportar multiples escenarios de servicio mediante formas flexibles para mapear los servicios. La forma de despliegue es flexible, y se puede hacer un uso completo de los dispositivos existentes. Por ejemplo, como dispositivo de acceso se puede utilizar un dispositivo de conmutacion de gama baja, a la vez que en el dispositivo de convergencia se dispone un equipo para mapear instancias de servicio con el fin de implementar la mejora. En consecuencia, la construccion del sistema resulta rentable en conjunto. Ademas, como la mejora se realiza basandose en el protocolo TRILL, un dispositivo de red solo requiere una pequena modificacion y resulta completamente compatible con el protocolo TRILL existente, y la extension se puede llevar a cabo facilmente.

Las personas con un conocimiento normal de la tecnica deben entender que la totalidad o parte de los pasos de los modos de realizacion del metodo anterior se pueden implementar mediante un programa que controle un hardware apropiado. El programa se puede almacenar en un medio de almacenamiento legible por ordenador. Cuando se activa el programa se ejecutan los pasos de los modos de realizacion del metodo anterior. El medio de almacenamiento incluye cualquier medio capaz de almacenar codigos de programa, como por ejemplo una ROM, una RAM, un disco magnetico, o un disco optico, o similares.

Modo de realizacion 3

La FIG. 3 es un diagrama esquematico de la estructura de un equipo para mapear una instancia de servicio de acuerdo con el Modo de realizacion 3 de la presente invencion. Tal como se ilustra en la FIG. 3, el equipo para mapear una instancia de servicio incluye:

un modulo 31 de correlacion, configurado para correlacionar una instancia de servicio de capa 2 con un puerto de acceso al servicio de la instancia de servicio, y determinar la correspondencia entre el puerto de acceso al servicio y un identificador de la instancia de servicio; y

un modulo 33 de asociacion, configurado para asociar el identificador de la instancia de servicio a una etiqueta de servicio de un paquete.

En particular, la instancia de servicio en el modo de realizacion de la presente invencion es un servicio de red de capa 2 (capa de enlace de datos). Las diferentes instancias de servicio se afslan en una red mediante aislamiento de la capa 2, y la correlacion entre el puerto de acceso al servicio de la instancia de servicio y la propia instancia de servicio se puede especificar en una forma de configuracion mediante comandos. En una red concreta, cada instancia de servicio se corresponde con un identificador de instancia de servicio unico global, en donde el identificador de la instancia de servicio esta constituido por un valor numerico, un alias alfanumerico, etc. Al

correlacionar la instancia de servicio con el puerto de acceso al servicio, a la instancia de servicio se le puede

asignar un identificador de instancia de servicio correspondiente; o se puede configurar con antelacion un identificador de la instancia de servicio correspondiente a la instancia de servicio antes de la correlacion. El

identificador de la instancia de servicio se puede asociar a una etiqueta de servicio en un paquete de datos, y

transmitirse entre los dispositivos. En relacion con un metodo para asociar el identificador de la instancia de servicio a la etiqueta de servicio del paquete por parte del modulo de asociacion, se puede realizar una mejora a partir de un protocolo TRILL. Para mas detalles, se puede hacer referencia a la correspondiente descripcion en el Modo de realizacion 1 y el Modo de realizacion 2 de la presente invencion.

En este modo de realizacion, despues de que el modulo de correlacion haya correlacionado una instancia de servicio de capa 2 con un puerto de acceso al servicio de la instancia de servicio, el modulo de asociacion puede asociar un identificador de la instancia de servicio correspondiente al puerto de acceso al servicio con una etiqueta de servicio de un paquete. Como se utiliza la etiqueta de servicio para transportar el identificador de la instancia de servicio, se puede proporcionar una mayor capacidad de soporte de etiquetas de servicio, se pueden soportar mas instancias de servicio, y se puede satisfacer el requisito de multiples arrendatarios en un entorno de nube publica a gran escala, lo que constituye una solucion L2 general; el soporte del protocolo de control se amplfa, la extension del protocolo TRILL puede proporcionar una mayor capacidad de desarrollo de servicios, y se pueden soportar multiples escenarios de servicio mediante formas flexibles para mapear servicios.

Modo de realizacion 4

La FIG. 4 es un diagrama esquematico de la estructura de un equipo para mapear una instancia de servicio de acuerdo con el Modo de realizacion 4 de la presente invencion. Tal como se ilustra en la FIG. 4, basandose en el Modo de realizacion 3, el modulo 33 de asociacion del equipo para mapear una instancia de servicio puede incluir:

un submodulo 331 de red de area local virtual simple, configurado para asignarle el identificador de la instancia de servicio a un campo de red de area local virtual de una primera etiqueta de red de area local virtual de un paquete de Interconexion Transparente de Multiples Enlaces y a una opcion de extension de la cabecera del paquete de

5

10

15

20

25

30

35

40

45

50

55

Interconexion Transparente de Multiples Enlaces, en donde el campo de red de area local virtual de la primera etiqueta de red de area local virtual del paquete de Interconexion Transparente de Multiples Enlaces y la opcion de extension de la cabecera de Interconexion Transparente de Multiples Enlaces conforman la etiqueta de servicio; o

un submodulo 333 de apilamiento de red de area local virtual de dos capas, configurado para asociar el identificador de la instancia de servicio a un campo de red de area local virtual de una primera etiqueta externa y a un campo de red de area local virtual de una primera etiqueta interna en un paquete de apilamiento de red de area local virtual de dos capas, en donde el campo de red de area local virtual de la primera etiqueta externa y el campo de red de area local virtual de la primera etiqueta interna en el paquete de apilamiento de red de area local virtual de dos capas conforman la etiqueta de servicio.

Por otro lado, el submodulo 331 de red de area local virtual simple esta configurado, ademas, para asociar un identificador de red de area local virtual de la instancia de servicio a un campo de red de area local virtual de una segunda etiqueta de red de area local virtual en el paquete de Interconexion Transparente de Multiples Enlaces; o

el submodulo 333 de apilamiento de red de area local virtual de dos capas esta configurado, ademas, para asociar el identificador de una red de area local virtual de una instancia de servicio a un campo de red de area local virtual de una segunda etiqueta externa y/o a un campo de red de area local virtual de una segunda etiqueta interna en el paquete de apilamiento de red de area local virtual de dos capas.

Adicionalmente, el equipo para mapear una instancia de servicio puede incluir, ademas, uno o mas de los siguientes modulos:

un modulo 35 de negociacion en tres etapas, configurado para: recibir un mensaje de acceso inicial que incluye la capacidad de soporte de etiquetas de servicio de un nodo equivalente y un estado de negociacion en tres etapas no conectado; negociar de acuerdo con la capacidad de soporte de etiquetas de servicio del nodo local y la capacidad de soporte de etiquetas de servicio del nodo equivalente con el fin de determinar una capacidad de soporte de etiquetas de servicio para establecer una conexion; y enviarle al nodo equivalente una notificacion que incluye la capacidad de soporte de etiquetas de servicio para establecer una conexion e indica que el estado de la negociacion en tres etapas ha cambiado a un estado de conexion establecida;

un modulo 36 que soporta multiples topologfas, configurado para enviar un mensaje de acceso inicial que contiene la capacidad de puertos que soportan multiples topologfas, en donde una red de area local virtual habilitada con la capacidad de puertos que soportan multiples topologfas incluye un campo de informacion de la etiqueta de servicio extendida;

un modulo 37 de control de acceso al medio, configurado para enviar un mensaje de provision de servicios por capas que incluye la accesibilidad del control de acceso al medio, en donde la accesibilidad del control de acceso al medio incluye un campo de informacion de la etiqueta de servicio extendida; y

un modulo 38 de direccion de grupo, configurado para enviar un mensaje de provision de servicios por capas que incluye una direccion de grupo, en donde la direccion de control de acceso al medio de grupo de la direccion de grupo incluye un campo de informacion de la etiqueta de servicio extendida.

El modulo 35 de negociacion en tres etapas puede incluir:

un primer submodulo 351 de negociacion, configurado para: si la capacidad de soporte de etiquetas de servicio del nodo local coincide con la capacidad de soporte de etiquetas de servicio del nodo equivalente, cambiar el estado de la negociacion en tres etapas al estado de conexion establecida y determinar como capacidad de soporte de etiquetas de servicio para establecer una conexion la capacidad coincidente de soporte de etiquetas de servicio; y

un segundo submodulo 353 de negociacion, configurado para: si la capacidad de soporte de etiquetas de servicio del nodo local no coincide con la capacidad de soporte de etiquetas de servicio del nodo equivalente, determinar como capacidad de soporte de etiquetas de servicio para establecer una conexion la menor capacidad de soporte de etiquetas de servicio entre la capacidad de soporte de etiquetas de servicio del nodo local y la capacidad de soporte de etiquetas de servicio del nodo equivalente.

En relacion con los procesos funcionales y los principios operativos de los modulos y submodulos en los modos de realizacion, se puede hacer referencia a la descripcion de los modos de realizacion del metodo anteriores, por lo que los detalles no se describen de nuevo aqrn.

Ademas, en el modo de realizacion de la presente invencion, un dispositivo que soporte el metodo para mapear una instancia de servicio, concretamente el equipo para mapear una instancia de servicio, tambien se puede aplicar a una red MEN de telecomunicaciones. Por ejemplo, un DSLAM accede a Internet utilizando un conmutador de convergencia, y una red PTN lleva a cabo la funcion de red de retorno para las estaciones moviles. Este tipo de redes pertenecen al acceso de capa 2 (L2), y disponen de algunos tipos de bucle para garantizar la conmutacion. Mediante la adopcion del metodo para mapear una instancia de servicio en el modo de realizacion de la presente invencion se pueden proporcionar y considerar ventajas tales como una configuracion flexible y un enrutamiento

5

10

15

20

25

30

35

40

automatico, y al mismo tiempo, se dispone de etiquetas de servicio de alta capacidad, lo cual puede satisfacer los requisitos de aplicacion del servicio.

En este modo de realizacion, despues de que el modulo de correlacion haya correlacionado una instancia de servicio de capa 2 con un puerto de acceso al servicio de la instancia de servicio, cada uno de los submodulos del modulo de asociacion puede asociar un identificador de instancia de servicio correspondiente al puerto de acceso al servicio con una etiqueta de servicio de un paquete. Como se utiliza la etiqueta de servicio para transportar el identificador de la instancia de servicio, se puede proporcionar una mayor capacidad de soporte de etiquetas de servicio, se pueden soportar mas instancias de servicio, y se puede satisfacer el requisito de multiples arrendatarios en un entorno de nube publica a gran escala, lo que constituye una solucion L2 general; el soporte del protocolo de control se ampffa, la extension del protocolo TRILL puede proporcionar una mayor capacidad de desarrollo de servicios, y se pueden soportar multiples escenarios de servicio mediante formas flexibles para mapear servicios.

Modo de realizacion 5

El Modo de realizacion 5 de la presente invencion proporciona un sistema para mapear instancias de servicio. El sistema para mapear instancias de servicio incluye al menos un centro de datos.

En el centro de datos se puede utilizar un equipo para mapear instancias de servicio con una cualquiera de las estructuras descritas en los modos de realizacion de la presente invencion.

En particular, la estructura del centro de datos puede incluir dispositivos tales como un servidor ffsico, un dispositivo de acceso, un dispositivo de convergencia, un dispositivo troncal, y un router de salida, en referencia a la FIG. 2a y su descripcion correspondiente en el Modo de realizacion 2; en el servidor ffsico del centro de datos se pueden crear multiples maquinas virtuales o conmutadores virtuales mediante virtualizacion utilizando un software, en referencia a la Fig. 2b y su descripcion correspondiente en el Modo de realizacion 2. El equipo para mapear una instancia de servicio se puede disponer en un conmutador virtual del dispositivo ffsico, un dispositivo de acceso, un dispositivo de convergencia, un dispositivo troncal, o un router de salida.

En el centro de datos del modo de realizacion, despues de que se haya correlacionado una instancia de servicio de capa 2 con un puerto de acceso al servicio de la instancia de servicio se puede asociar un identificador de la instancia de servicio que corresponde al puerto de acceso al servicio con una etiqueta de servicio de un paquete. Como se utiliza la etiqueta de servicio para transportar el identificador de la instancia de servicio, se puede proporcionar una mayor capacidad de soporte de etiquetas de servicio, se pueden soportar mas instancias de servicio, y se puede satisfacer el requisito de multiples arrendatarios en un entorno de nube publica a gran escala, lo que constituye una solucion L2 general; el soporte del protocolo de control se ampffa, la extension del protocolo TRILL puede proporcionar una mayor capacidad de desarrollo de servicios, y se pueden soportar multiples escenarios de servicio mediante formas flexibles para mapear servicios.

Por ultimo, se debe observar que los modos de realizacion anteriores unicamente pretenden describir las soluciones tecnicas de la presente invencion mas que limitar la presente invencion. Aunque la presente invencion se describe en detalle haciendo referencia a los modos de realizacion anteriores, las personas con un conocimiento normal de la tecnica deben entender que aun pueden hacer modificaciones a las soluciones tecnicas descritas en los modos de realizacion anteriores, o realizar sustituciones equivalentes a algunas de las caractensticas tecnicas de la soluciones tecnicas, a condicion de que dichas modificaciones o sustituciones no den lugar a que la esencia de las soluciones tecnicas correspondientes se aparten del alcance de las soluciones tecnicas de los modos de realizacion de la presente invencion.

Claims (8)

1. 5

   10

   15

   20

   25

   30

   35

   40

   45

   50

   REIVINDICACIONES

   1. Un metodo para mapear una instancia de servicio para el protocolo de Interconexion Transparente de Multiples enlaces, TRILL, que comprende:

   correlacionar (101) una instancia de servicio de capa 2 con un puerto de acceso al servicio de la instancia de servicio, y determinar la correspondencia entre el puerto de acceso al servicio y un identificador de la instancia de servicio; y

   asociar (102) el identificador de la instancia de servicio a una etiqueta de servicio de un paquete de apilamiento de red de area local virtual, VLAN, de dos capas, en donde un paquete de capa 2 de un usuario que ha sido recibido por parte del puerto de acceso al servicio se encapsula en el paquete de apilamiento de la VLAN de dos capas utilizando una cabecera TRILL; y

   reenviar el paquete de apilamiento de la VLAN de dos capas;

   caracterizado por que

   la etiqueta de servicio es de 24 bits, la etiqueta de servicio esta constituida por un campo de red de area local virtual de una primera etiqueta externa y un campo de red de area local virtual de una etiqueta interna en el paquete de apilamiento de la VLAN de dos capas, los 12 bits del campo VLAN de la etiqueta externa almacenan los 12 bits mas significativos de la etiqueta de servicio, y los 12 bits del campo VLAN de la etiqueta interna almacenan los 12 bits menos significativos de la etiqueta de servicio.
2. 2. El metodo para mapear una instancia de servicio de acuerdo con la reivindicacion 1, que comprende, ademas, un paso de negociacion, por parte de nodos adyacentes, de una capacidad de soporte de etiquetas de servicio en un proceso de establecimiento inicial de una conexion mediante una negociacion en tres etapas, en donde el paso comprende, espedficamente:

   recibir un mensaje de acceso inicial que incluye una capacidad de soporte de etiquetas de servicio de un nodo equivalente y un estado de negociacion en tres etapas, siendo este un estado no conectado;

   negociar de acuerdo con la capacidad de soporte de etiquetas de servicio de un nodo local y la capacidad de soporte de etiquetas de servicio del nodo equivalente con el fin de determinar una capacidad de soporte de etiquetas de servicio para establecer una conexion; y

   enviarle al nodo equivalente una notificacion que incluye la capacidad de soporte de etiquetas de servicio para establecer una conexion e indica que el estado de la negociacion en tres etapas ha cambiado al estado conexion establecida.
3. 3. El metodo para mapear una instancia de servicio de acuerdo con la reivindicacion 2, en el que la negociacion de acuerdo con la capacidad de soporte de etiquetas de servicio de un nodo local y la capacidad de soporte de etiquetas de servicio del nodo equivalente con el fin de determinar una capacidad de soporte de etiquetas de servicio para establecer una conexion comprende:

   si la capacidad de soporte de etiquetas de servicio del nodo local coincide con la capacidad de soporte de etiquetas de servicio del nodo equivalente, cambiar el estado de la negociacion en tres etapas al estado de conexion establecida y determinar como capacidad de soporte de etiquetas de servicio para establecer una conexion la capacidad coincidente de soporte de etiquetas de servicio; o

   si la capacidad de soporte de etiquetas de servicio del nodo local no coincide con la capacidad de soporte de etiquetas de servicio del nodo equivalente, determinar como capacidad de soporte de etiquetas de servicio para establecer una conexion la menor capacidad de soporte de etiquetas de servicio entre la capacidad de soporte de etiquetas de servicio del nodo local y la capacidad de soporte de etiquetas de servicio del nodo equivalente.
4. 4. El metodo para mapear una instancia de servicio de acuerdo con la reivindicacion 1, que comprende, ademas, uno cualquiera de los siguientes pasos:

   enviar un mensaje de acceso inicial que incluye una capacidad de puertos que soportan multiples topologfas, en donde una red de area local virtual habilitada con la capacidad de puertos que soportan multiples topologfas comprende un campo de informacion de la etiqueta de servicio extendida;

   enviar un mensaje de provision de servicios por capa que incluye la accesibilidad del control de acceso al medio, en donde la accesibilidad del control de acceso al medio comprende un campo de informacion de la etiqueta de servicio extendida; y

   enviar un mensaje de provision de servicios por capas que incluye una direccion de grupo, en donde una direccion de control de acceso al medio de grupo de la direccion de grupo incluye un campo de informacion de la etiqueta de servicio extendida.

   5

   10

   15

   20

   25

   30

   35

   40

   45

   50
5. 5. Un equipo para mapear una instancia de servicio para el protocolo de Interconexion Transparente de Multiples enlaces, TRILL, que comprende:

   un modulo (31) de correlacion, configurado para correlacionar una instancia de servicio de capa 2 con un puerto de acceso al servicio de la instancia de servicio, y determinar la correspondencia entre el puerto de acceso al servicio y un identificador de la instancia de servicio; y,

   un modulo (33) de asociacion, configurado para asociar el identificador de la instancia de servicio a una etiqueta de servicio de un paquete de apilamiento de red de area local virtual, VLAN, de dos capas que ha sido recibido en el puerto de acceso al servicio, en donde el paquete de capa 2 de un usuario que ha sido recibido por parte del puerto de acceso al servicio se encapsula en el paquete de apilamiento de la VLAN de dos capas utilizando una cabecera TRILL; y

   medios para reenviar el paquete de apilamiento de la VLAN de dos capas;

   caracterizado por que

   la etiqueta de servicio es de 24 bits, la etiqueta de servicio esta constituida por un campo de red de area local virtual de una primera etiqueta externa y un campo de red de area local virtual de una etiqueta interna en el paquete de apilamiento de la VLAN de dos capas, los 12 bits del campo VLAN de la etiqueta externa almacenan los l2 bits mas significativos de la etiqueta de servicio, y los 12 bits del campo VLAN de la etiqueta interna almacenan los 12 bits menos significativos de la etiqueta de servicio.
6. 6. El equipo para mapear una instancia de servicio de acuerdo con la reivindicacion 5, que comprende, uno cualquiera o mas de uno de los siguientes modulos:

   un modulo (35) de negociacion en tres etapas, configurado para: recibir un mensaje de acceso inicial que incluye la capacidad de soporte de etiquetas de servicio de un nodo equivalente y un estado de la negociacion en tres etapas, siendo dicho estado no conectado; negociar de acuerdo con la capacidad de soporte de etiquetas de servicio de un nodo local y la capacidad de soporte de etiquetas de servicio del nodo equivalente con el fin de determinar una capacidad de soporte de etiquetas de servicio para establecer una conexion; y enviarle al nodo equivalente una notificacion que incluye la capacidad de soporte de etiquetas de servicio para establecer una conexion e indica que el estado de la negociacion en tres etapas ha cambiado a un estado de conexion establecida;

   un modulo (36) que soporta multiples topologfas, configurado para enviar un mensaje de acceso inicial que incluye una capacidad de puertos que soportan multiples topologfas, en donde una red de area local virtual habilitada con la capacidad de puertos que soportan multiples topologfas comprende un campo de informacion de la etiqueta de servicio extendida;

   un modulo (37) de control de acceso al medio, configurado para enviar un mensaje de provision de servicios por capas que incluye la accesibilidad del control de acceso al medio, en donde la accesibilidad del control de acceso al medio comprende un campo de informacion de la etiqueta de servicio extendida; y

   un modulo (38) de direccion de grupo, configurado para enviar un mensaje de provision de servicios por capas que incluye una direccion de grupo, en donde una direccion de control de acceso al medio de grupo de la direccion de grupo incluye un campo de informacion de la etiqueta de servicio extendida.
7. 7. El equipo para mapear una instancia de servicio de acuerdo con la reivindicacion 6, en el que el modulo de negociacion en tres etapas comprende:

   un primer submodulo (351) de negociacion, configurado para: si la capacidad de soporte de etiquetas de servicio del nodo local coincide con la capacidad de soporte de etiquetas de servicio del nodo equivalente, cambiar el estado de la negociacion en tres etapas al estado de conexion establecida y determinar como capacidad de soporte de etiquetas de servicio para establecer una conexion la capacidad coincidente de soporte de etiquetas de servicio; o

   un segundo submodulo (353) de negociacion, configurado para: si la capacidad de soporte de etiquetas de servicio del nodo local no coincide con la capacidad de soporte de etiquetas de servicio del nodo equivalente, determinar como capacidad de soporte de etiquetas de servicio para establecer una conexion la menor capacidad de soporte de etiquetas de servicio entre la capacidad de soporte de etiquetas de servicio del nodo local y la capacidad de soporte de etiquetas de servicio del nodo equivalente.
8. 8. Un sistema para mapear instancias de servicio, que comprende al menos un centro de datos, en donde:

   el centro de datos comprende el equipo para mapear una instancia de servicio de acuerdo con una cualquiera de las reivindicaciones 5 a 7.