ES2647665B2 - Procedimiento cooperativo, entre puentes y controlador, de reparación de caminos en fallo y puente de red - Google Patents

Procedimiento cooperativo, entre puentes y controlador, de reparación de caminos en fallo y puente de red Download PDF

Info

Publication number
ES2647665B2
ES2647665B2 ES201600530A ES201600530A ES2647665B2 ES 2647665 B2 ES2647665 B2 ES 2647665B2 ES 201600530 A ES201600530 A ES 201600530A ES 201600530 A ES201600530 A ES 201600530A ES 2647665 B2 ES2647665 B2 ES 2647665B2
Authority
ES
Spain
Prior art keywords
frame
bridge
repair
destination
address
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES201600530A
Other languages
English (en)
Other versions
ES2647665A1 (es
Inventor
Guillermo IBÁÑEZ FERNÁNDEZ
Joaquín ÁLVAREZ HORCAJO
José Manuel ARCO RODRIGUEZ
José Manuel GIMÉNEZ GUZMÁN
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Universidad de Alcala de Henares UAH
Original Assignee
Universidad de Alcala de Henares UAH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Universidad de Alcala de Henares UAH filed Critical Universidad de Alcala de Henares UAH
Priority to ES201600530A priority Critical patent/ES2647665B2/es
Priority to PCT/ES2017/070443 priority patent/WO2017220834A1/es
Publication of ES2647665A1 publication Critical patent/ES2647665A1/es
Application granted granted Critical
Publication of ES2647665B2 publication Critical patent/ES2647665B2/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/28—Routing or path finding of packets in data switching networks using route fault recovery
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40—Support for services or applications

Landscapes

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

Abstract

La presente invención describe mecanismos para, en una red de puentes transparentes dotados de funcionalidad de aprendizaje de caminos de tipo ARP-Path, en cooperación con el controlador SDN, reparar todos los caminos en uso que pasan por un determinado enlace cuando éste falla. El puente con el enlace en fallo informa al controlador enviando un paquete OpenFlow de tipo Packetln conteniendo la dirección de destino a reparar. El controlador consulta en una tabla el puente frontera al que está conectado cada terminal y envía un paquete OpenFlow PacketOut al puente frontera conectado al terminal destino. Este paquete contiene una trama de reparación de multidifusión que el puente desencapsula y envía a través de todos sus enlaces, inundando la red hasta alcanzar el puente que detectó el fallo del enlace, estableciendo esta trama a su paso por la red un árbol de confluencia hacia el puente del terminal destino.

Description

DESCRIPCIÓN
Procedimiento cooperativo, entre puentes y controlador, de reparación de caminos en fallo y puente de red.
5
Sector de la técnica
La presente invención se encuadra dentro del sector de las comunicaciones y de los dispositivos electrónicos y/o aplicaciones informáticas que establecen las comunicaciones entre puentes transparentes. 10
Estado de la técnica
Nota.- En esta descripción la función denominada como "terminal" normalmente identifica a un sistema final pero puede estar implementada en un sistema intermedio (puente o 15 encaminador).
Son conocidos protocolos de establecimiento de caminos denominados Fast-Path y ARP-Path [MacCrane_10] [Tanaka_10] [NISHIMURA] [Mickenberg_11] [lbáñez_09] [Rojas_15] que establecen caminos mediante la exploración simultánea de toda la red mediante una 20 trama de difusión como el ARP Request, una trama unidestino ARP Reply y el aprendizaje en los puentes atravesados de las direcciones MAC origen y su asociación al puerto por donde se recibe primero la trama difundida.
Estos protocolos presentan el inconveniente de que cuando falla un enlace se envía una 25 trama de difusión Path Request por toda la red para estar seguro de alcanzar el puente frontera destino, dicho puente genera después una trama Path Reply de difusión que establece caminos en árbol hacia dicho terminal destino, las tramas dirigidas a dicho terminal que se encuentren en la red seguirán la rama hacia el destino que alcance el puente que estén atravesando (el puente con el enlace en fallo). Este procedimiento de 30 reparación totalmente distribuida tiene el inconveniente de que implica un procesamiento en todos los puentes de la red de la trama Path Request hasta que se alcanza el puente destino.
Asimismo es conocido el uso de uno o varios controladores de red en las Redes 35 Definidas por Software (Software Defined Networks, SDN) [OpenFlow-1.3.2] conectados a cada uno de los puentes de la red mediante una red paralela de control.
Los puentes SDN pueden ser de tipo híbrido [OpenFlow-1.3.2] combinando de diversas formas las funciones (distribuidas) de reenvío tradicionales de los puentes y 40 encaminadores con las funciones (centralizadas) de reenvío gestionadas por el controlador. En estos puentes parte del tráfico entrante se procesa mediante la funcionalidad distribuida implementada en el puente o bien según el tratamiento especificado explícitamente por el controlador al puente para cada flujo de tráfico.
45
Estas redes SDN realizan la reparación de caminos en fallo de forma totalmente centralizada, comunicando el puente al controlador el fallo de uno de sus enlaces. El controlador calcula rutas alternativas para los terminales destino afectados por el fallo de dicho enlace y configura mediante su interfaz de control (por ejemplo OpenFlow) un nuevo camino hacia el terminal destino en cada uno de los puentes atravesados por el 50 nuevo camino. Este procedimiento tiene un retardo de procesamiento significativo para calcular y configurar los cambios en las tablas de procesado en los puentes para los flujos de tramas afectados por el fallo. Asimismo, requiere que la topología activa de la
red esté libre de enlaces redundantes para que los reenvíos de tramas en difusión no generen tormentas de tramas.
La invención descrita en esta patente mitiga los inconvenientes de la reparación distribuida y evita los de la reparación centralizada, mediante un procedimiento de 5 reparación cooperativa entre los puentes de la red y el controlador. El controlador prepara la trama de reparación y la envía al puente frontera destino, el cual solamente la desencapsula y reenvía en multidifusión a través de la red, restableciéndose así el camino hacia el terminal destino al aprenderse en los puentes la dirección origen del terminal destino. 10
Explicación de la invención
Los protocolos de encaminamiento de tramas basados en exploración de caminos como ARP-Path, encuentran los caminos por inundación de la red mediante tramas de difusión. 15 Los puentes que los utilizan solamente aprenden las direcciones MAC origen de las tramas ARP Request, ARP Reply y de otras tramas de control que reciben, bloqueando el aprendizaje de dichas direcciones en otros puertos del puente durante un tiempo suficiente y descartando las tramas de igual origen recibidas durante ese periodo de bloqueo en otros puertos del puente. Estos puentes pueden Implementarse como 20 puentes con capacidad SDN dotados de una interfaz OpenFlow, combinando así la funcionalidad de un puente OpenFlow con la de un puente ARP-Path en un único puente. Esta funcionalidad combinada presenta por un lado la ventaja de poder evitar al controlador el control detallado de todos los flujos de datos de la red y en particular posibilita la reparación cooperativa de caminos entre la red y el controlador. 25
La presente Invención describe mecanismos que permiten, en una red de puentes transparentes con Interfaz OpenFlow y dotados de funcionalidad de aprendizaje de caminos con bloqueo temporal del reaprendizaje tipo ARP-Path, implementar la reparación, en cooperación con el controlador SDN, de todos los caminos en uso que 30 pasan por un determinado enlace cuando este falla. De esta forma, cuando por fallo de un enlace u otra causa hay que reparar un camino hacia un terminal en un puente, este informa al controlador enviando un paquete OpenFlow de tipo Packetln conteniendo la dirección de destino a reparar. El controlador consulta en una tabla el puente frontera al que está conectado cada terminal y envía un paquete OpenFlow PacketOut al puente 35 frontera conectado al terminal destino. Este paquete contiene una trama de reparación de multidifusión que el puente desencapsula y envía a través de todos sus enlaces, inundándola hasta alcanzar el puente que detecto el fallo del enlace, estableciendo esta trama a su paso por la red un árbol de confluencia por donde alcanzar al puente del terminal destino, cuyas ramas, una o varias, serán utilizadas por las tramas en tránsito 40 hacia el destino.
Estos mecanismos pueden ser implementados en dispositivos hardware especializados o bien parcial o totalmente como programas software ejecutados en dispositivos hardware tanto especializados como genéricos. 45
Breve descripción de los dibujos
Para complementar esta descripción, y con objeto de ayudar a una mejor comprensión de las características de la invención, se acampana, como parte integrante de dicha 50 descripción, un juego de dibujos en donde, con carácter ilustrativo y no limitativo, se ha representado lo siguiente:
La figura 1 muestra los cuatros tipos de procesamiento que puede tener una trama en un puente híbrido: recuperación cooperativa, recuperación ARP-Path, tratamiento OpenFlow y tratamiento ARP-Path.
La figura 2 muestra el último caso de procesamiento de la trama que se puede dar, 5 cuando la trama es tratada con el protocolo ARP-Path.
La figura 3 muestra el procesamiento de la trama en la parte del controlador.
La figura 4 muestra el procesamiento de la trama cuando se realiza una reparación 10 cooperativa con trama Path Recovery.
En la figura 5 se muestra un ejemplo de red con un controlador SDN donde la red de control (controlador-puentes) se implementa con una red separada (fuera de banda).
15
La figura 6 muestra un camino establecido entre los terminales A y B, mediante las direcciones aprendidas asociadas a puertos en los diferentes puentes que intervienen en el camino.
La figura 7 muestra un fallo del enlace que une los puentes s3 y s5, por lo que la trama 20 que el terminal A envía al B al llegar a s3 no puede ser reenviada.
La figura 8 muestra cómo el puente s3 notifica el problema al controlador con una trama Packetln.
25
La figura 9 muestra como el controlador envía una trama PacketOut al puente s5 destino del terminal B.
La figura 10 muestra como el puente s5 destino de B envía una trama Path Recovery a toda la red para aprender de nuevo por donde se encuentra B. 30
La figura 11 muestra el formato de la trama de recuperación Path Recovery.
La figura 12 muestra cómo se hace el envío de tramas desde el terminal A al B por el nuevo camino. 35
La figura 13 muestra cómo al cabo de un tiempo las direcciones aprendidas y no usadas no son refrescadas y se borran, como ocurre en el puente s3.
La figura 14 muestra un ejemplo de red con controlador SDN en el que no existe una red 40 de control separada (señalización dentro de banda) y donde falla el envío de tramas de control al puente destino del terminal B.
La figura 15 muestra la secuencia de paquetes y tramas intercambiados entre los elementos de la red, desde el fallo del enlace que une los puentes s3 y s5 hasta que el 45 camino hacia s5 esta reparado.
Realización preferente de la invención
Todos los puentes de la red son puentes con funcionalidad OpenFlow y ARP-Path. En la 50 figura 1 se muestra el funcionamiento genérico del puente OpenFlow cuando se recibe una trama, seleccionando diferentes acciones según el tipo de trama recibida.
Estas acciones son: procesar la trama según lo especificado en las tablas OpenFlow, procesar el paquete OpenFlow PacketOut recibido del controlador, ejecutar recuperación cooperativa de caminos, recuperación convencional ARP-Path o reenviar trama según protocolo ARP-Path, mostrado en la figura 2.
5
Si no hay reglas SDN configuradas en el puente ni rutas ARP-Path para enrutar la trama, según el organigrama de la figura 2, se comprobaría la conectividad con el controlador y si no existe conectividad se iniciaría la recuperación distribuida ARP-Path. Si no existe regia configurada, se verifica si la trama recibida es una trama Path Recovery para en ese caso participar en el proceso de recuperación cooperativa de la figura 4, donde en 10 cada puente se aprende o actualiza la dirección del terminal destino.
Si la trama no está relacionada con la reparación se trata como una trama normal ARP-Path con arreglo a la figura 2.
15
En el caso de que el puente genere un Packetln el controlador realizará lo establecido en la figura 3.
La figura 5 muestra una red en la que se recoge una realización de la invención, implementada en una red con un controlador central SDN conectado a los puentes con 20 interfaz OpenFlow mediante una red separada.
Los terminales A y B están conectados respectivamente a los puentes frontera 1 y 5. Estos puentes tienen establecidos caminos entre los terminales A y b, tal y como se muestra en la figura 6, mediante el aprendizaje de la dirección origen de las tramas ARP 25 Request y ARP Reply emitidas por dichos terminales al comenzar a comunicarse. Se indica, junto a cada puente, con un círculo rodeando una letra, el puerto al que está asociada la dirección de dicho terminal (dirección aprendida)
De acuerdo con ello, y de manera similar a otros puentes Ethernet transparentes, para 30 una trama unidestino con destino 8 que sale de A, al llegar al puente 1, se consulta en una memoria de dicho puente el contenido de la tabla de reenvío para dicha dirección destino, leyendo de la misma el puerto de salida por el que debe ser reenviada, el puerto de s1 que tiene un circulo B en la figura 6; al llegar la trama al puente 3 es igualmente reenviada hacia el puente 5 tras consultar la tabla de reenvío del puente y en el puente 5 35 es reenviada por el puerto asociado al terminal B. En todos los puentes atravesados se produce la renovación o refresco del temporizador de caducidad de la dirección MAC destino, lo cual permite mantener activado el camino hacia el destino.
Se supone que hay establecido un camino entre los terminales A y B, tal como se 40 muestra en la figura 6, con las direcciones aprendidas en los diferentes puertos y llega una trama al puente s3 y debe ser reenviada por el enlace s3-s5 que ha fallado, según se ilustra en la figura 7. El puente s3 no tiene una ruta valida en sus tablas para alcanzar el terminal destino B o el puerto de reenvío está deshabilitado, por lo que informa del problema al controlador con un paquete OpenFlow Packetln, dentro del cual va la 45 dirección 8 del terminal de destino desconocido, según se muestra en la figura 8.
El controlador tiene registrados en una tabla las direcciones de los terminales y los puentes frontera a los que están conectados, consulta el puente correspondiente al terminal 8, en este caso el puente s5, prepara una trama especial Path Recovery de 50 reparación de camino con la dirección origen del terminal 8 y la envía encapsulada dentro de una trama PacketOut, según se muestra en la figura 9.
El puente frontera destino comienza el proceso de recuperación, figura 10, sin generar tráfico hacia el terminal B. La recuperación se hace reenviando la trama Path Recovery, cuyo formato es mostrado en la figura 11, con dirección destino la dirección MAC de grupo asignada a todos los puentes AllPath y en el campo Ethertype el identificador del protocolo ARP-Path (o los campos SSAP/DSAP Source Service Access Point, Punto de 5 Acceso al Servicio Fuente / Destination Service Access Point, Punto de Acceso al Servicio Destino) utilizados con el mismo fin si el encapsulado es LLC (Logical Link Control, Control de Enlace Lógico) y con dirección origen B.
Esta trama Path Recovery se retransmite, tal y como se muestra en la figura 10, por 10 todos los puertos excepto el que la recibió primero, descartándose las tramas duplicadas que se reciben más tarde de la misma forma que en el protocolo ARP-Path, por ser recibidas por un puerto distinto al asociado a su dirección MAC origen. Para ello, durante esa propagación, según el organigrama de la recuperación cooperativa de la figura 4, se aprende la dirección de B en la tabla de aprendizaje (Learning Table, LT) creándose así 15 un árbol de confluencia con raíz en el puente 5, el cual persistirá durante el tiempo de activación del temporizador de aprendizaje.
En la figura 11 se muestra el formato de trama de recuperación con el tipo de trama Path Recovery. En la figura 12 se muestra cómo el puente 1 tras aprender el nuevo puerto 20 para llegar a 8, envía la trama unidestino para B.
Algunas entradas de la tabla quedan obsoletas al no ser usadas y se eliminan por vencimiento de su temporizador, como muestra la figura 13.
25
La dirección MAC origen del terminal puede ser aprendida durante la reparación en unos puertos que finalmente no cursen tráfico hacia B, por lo que, pasado un periodo asociado a las entradas de la tabla LT, figura 2, la dirección expira y es borrada. En la figura 13, el puente s3 borra la dirección de 8 y queda la red con la dirección B aprendida en los puertos por los que es usada por el tráfico con destino B. 30
Esta reparación de camino es unidireccional para alcanzar el terminal destino B. Para el tráfico en dirección opuesta se realiza una reparación similar.
Si la red de datos es utilizada también para la comunicación entre el controlador y los 35 puentes, la reparación cooperativa puede verse afectada por el fallo del enlace, pudiendo darse varios casos y acciones en cada caso:
a) Fallo del enlace Puente-Controlador. Si el puente no puede enviar el paquete Packetln al controlador, el puente puede utilizar alguno de los métodos ARP-Path de 40 reparación distribuida descritos en el estado de la técnica, según se muestra en la figura 2.
b) Fallo del enlace Controlador-Puente destino, en este caso el PacketOut se envía al puente frontera origen y este puente puede utilizar alguno de los métodos ARP-Path 45 de reparación distribuida, por ejemplo mediante el envío de una trama de difusión Path Request para el destino B. respondiendo el puente frontera destino con una trama Path Reply. En la figura 14 se muestra un ejemplo de este caso en una red compartida para datos y control (inband) en la que el fallo del enlace entre s3 y s5 afecta a la comunicación entre el controlador y el puente frontera destino, por lo que 50 no llega el PacketOut y es necesaria la reparación distribuida desde el puente origen.
Referencias
[MacCrane_10] Mack-Crane et al. Media access control bridging in a mesh network. Patent Application Publication. US 2010/0272108 A1
5
[Tanaka_10] Tanaka et al. First arrival port learning method, relay apparatus, and computer product. Patente USA: US 7760667 B2
[NISHIMURA] Nishimura K.WO/2008/111173. Communication Path Control Method, Communication Apparatus and Communication System. Publication date: 18.09.2008 10
[Mickenberg_11]. Minkenberg et al. US2011/0032825A1 Multipath discovery in switched Ethernet networks. Patent application. Publ. date Feb.10, 2011
[lbáñez_09] Ibáñez et al. P200900508. Procedimiento de encaminamiento de tramas de 15 datos y puente de red.
[Rojas 15] E. Rojas, G. Ibanez, J. M. Jiménez-Guzman, J. A. Carral, A. Garcia-Martinez, l. Martinez-Yelmo, J. M. Arco, All-path bridging: Path exploration protocols for data center and cam-pus networks, Computer Networks 79 (0) (2015) 120 - 132. 20 doi:http://dx.doi.org/10.1016/j.comnet.2015.01.002. URL http://www.sciencedírect.com/ science/article/pii/ S1389128615000055
[OpenFlow-1.3.2] OpenFlow Switch Specification v1.3.2, https://www. opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow/ 25 openflow-spec-v1.3 2. pdf.

Claims (8)

  1. REIVINDICACIONES
    1. Procedimiento cooperativo para la reparación de caminos de tramas de datos que comprende:
    5
    - recibir, a través de un puerto de un puente de red donde dicho puerto tiene una identidad de puerto asignada, una trama que comprende una dirección MAC origen y una dirección MAC destino;
    - asociar, en una unidad de registro, la dirección MAC origen de la trama recibida a la 10 identidad del puerto del puente que primero recibía la trama, a un indicador de caducidad de la trama y al instante de llegada de la trama:
    - borrar, en la unidad de registro, las asociaciones que tenga un puerto de un puente cuando detecte la caída de un enlace en dicho puerto o expire el temporizador de validez 15 de la dirección;
    caracterizado por que cuando llega una trama a un puente con una dirección MAC de destino desconocida comprende:
    20
    - enviar una trama especial de petición de reparación al controlador, encapsulada en un paquete OpenFlow Packetln, conteniendo la dirección MAC de destino desconocida;
    - consultar el controlador la identidad del puente frontera al que está conectado dicho 25 terminal destino;
    - construir una trama de reparación con dirección MAC origen la del terminal destino y destino la dirección de multidifusión del protocolo ARP-Path;
    30
    - encapsular dicha trama en un paquete OpenFlow PacketOut y enviarla al puente conectado al terminal destino;
    - extraer el puente frontera destino la trama de reparación contenida en el paquete OpenFlow Packetln y reenviarla por todos los puertos del puente frontera conectados 35 a otros puentes.
  2. 2. Procedimiento cooperativo de reparación de caminos de tramas de datos según la reivindicación 1, caracterizado por, en los puentes donde se recibe la trama especial de reparación Path Recovery: 40
    - aprender el nuevo camino asociando la dirección origen de la trama recibida con el puerto por donde primero se recibe el Path Recovery.
  3. 3. Procedimiento cooperativo de reparación de caminos de tramas de datos, según 45 cualquiera de las reivindicaciones anteriores, caracterizado por que las tramas de reparación de camino se seleccionan entre:
    - tramas estándar ARP Request y ARP Reply generadas por el terminal correspondiente o por un puente intermedio; 50
    - tramas especiales de reparación: Path Recovery;
    - combinaciones de las anteriores.
  4. 4. Procedimiento cooperativo de reparación de caminos de tramas de datos, según cualquiera de las reivindicaciones anteriores, caracterizado por que el registro de direcciones en proceso de reparación comprende las direcciones MAC destino y un temporizador de reparación con valor inicial superior al tiempo necesario para que las tramas de reparación recorran la red y sean respondidas. 5
  5. 5. Puente de red que comprende unos medios de procesamiento configurados para:
    - enviar una trama especial de petición de reparación al controlador, encapsulada en un paquete OpenFlow Packetln, conteniendo la dirección MAC de destino desconocida; 10
    - asociar, en una unidad de registro, la dirección MAC origen de la trama recibida a la identidad del puerto del puente que primero recibió la trama, a un indicador de caducidad de la trama y al instante de llegada de la trama;
    15
    - renovar el temporizador de caducidad de direcciones de la dirección MAC destino por un nuevo periodo a fin de mantener el camino unidireccional a destino activado;
    - borrar, en la unidad de registro, las asociaciones que tengan un puerto de un puente cuando detecte la caída de un enlace en dicho puerto o expire el temporizador de validez 20 de la dirección;
    caracterizado por que cuando llega una trama a un puente con un destino unidirección MAC desconocido el procedimiento comprende:
    25
    - enviar una trama especial de petición de reparación al controlador, encapsulada en un paquete Packetln, conteniendo la dirección MAC de destino desconocida;
    - consultar el controlador la identidad del puente frontera conectado a dicho terminal destino; 30
    - construir una trama especial de reparación Path Recovery con dirección MAC origen la del terminal destino y destino la dirección de multidifusión del protocolo ARP-Path;
    - encapsular dicha trama en un paquete PacketOut y enviarlo al puente conectado al 35 terminal destino:
    - extraer en el puente frontera destino la trama de reparación y reenviarla por todos los puertos del puente frontera conectados a otros puentes.
    40
  6. 6. Puente de red, según la reivindicación 5, caracterizado por, en los puentes donde se recibe la trama especial de reparación Path Recovery enviada por el puente frontera:
    - aprender el nuevo camino asociando la dirección origen de la trama recibida con el puerto por donde primero se recibe la trama Path Recovery. 45
  7. 7. Puente de red, según la reivindicación 6, caracterizado por que las tramas de reparación de camino se seleccionan entre:
    - tramas estándar ARP Request y ARP Reply generadas por el terminal 50 correspondiente o por un puente intermedio;
    - tramas especiales de reparación: Path Recovery;
    - combinaciones de las anteriores.
  8. 8. Red de telecomunicaciones conmutada caracterizada por que comprende al menos un puente de red definido según alguna de las reivindicaciones 5 a 7.
    5
ES201600530A 2016-06-24 2016-06-24 Procedimiento cooperativo, entre puentes y controlador, de reparación de caminos en fallo y puente de red Active ES2647665B2 (es)

Priority Applications (2)

Application Number Priority Date Filing Date Title
ES201600530A ES2647665B2 (es) 2016-06-24 2016-06-24 Procedimiento cooperativo, entre puentes y controlador, de reparación de caminos en fallo y puente de red
PCT/ES2017/070443 WO2017220834A1 (es) 2016-06-24 2017-06-19 Procedimiento cooperativo, entre puentes y controlador, de reparación de caminos en fallo y puente de red

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
ES201600530A ES2647665B2 (es) 2016-06-24 2016-06-24 Procedimiento cooperativo, entre puentes y controlador, de reparación de caminos en fallo y puente de red

Publications (2)

Publication Number Publication Date
ES2647665A1 ES2647665A1 (es) 2017-12-26
ES2647665B2 true ES2647665B2 (es) 2018-04-24

Family

ID=60687340

Family Applications (1)

Application Number Title Priority Date Filing Date
ES201600530A Active ES2647665B2 (es) 2016-06-24 2016-06-24 Procedimiento cooperativo, entre puentes y controlador, de reparación de caminos en fallo y puente de red

Country Status (2)

Country Link
ES (1) ES2647665B2 (es)
WO (1) WO2017220834A1 (es)

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3028401A1 (en) * 2013-08-01 2016-06-08 Hewlett-Packard Development Company, L.P. Address resolution rewriting

Also Published As

Publication number Publication date
ES2647665A1 (es) 2017-12-26
WO2017220834A1 (es) 2017-12-28

Similar Documents

Publication Publication Date Title
US9628285B2 (en) Increasing failure coverage of MoFRR with dataplane notifications
ES2361545B1 (es) Procedimiento de encaminamiento de tramas de datos y puente de red.
ES2614614T3 (es) Igualación de carga en dominios de capa-2
EP2839614B1 (en) Selecting between equal cost shortest paths in a 802.1aq network using split tiebreakers
KR101406922B1 (ko) 공급자 링크 상태 브리징
ES2383827T3 (es) Sistema de control, método de transmisión de mensaje de datos y dispositivo de red Ethernet
US10439880B2 (en) Loop-free convergence in communication networks
US7719958B1 (en) Method and apparatus for enabling multicast over split multilink trunking
ES2527834T3 (es) Método y sistema de comunicaciones de empresa de servicios
US8811168B2 (en) Transient loop prevention in a hybrid layer-2 network
ES2540595B2 (es) Procedimiento de establecimiento y borrado de caminos y de reenvio de tramas para conexiones de transporte y puente de red
CN105900406B (zh) 针对网络服务可用性的技术
ES2731352T3 (es) Método y dispositivo de detección de fallos
KR20140027455A (ko) 이더넷 패킷을 인터넷 프로토콜 네트워크를 통해 라우팅하는 집중 시스템
US20140328163A1 (en) Midspan re-optimization of traffic engineered label switched paths
US20090129383A1 (en) Hub and spoke multicast model
US20110080854A1 (en) Method And System For Controlled Tree Management
WO2014132967A1 (ja) 通信システム、スイッチ、制御装置、制御用チャネルの構築方法及びプログラム
EP3694158A1 (en) Active-active access to transparent interconnection of lots of links (trill) edges
ES2647665B2 (es) Procedimiento cooperativo, entre puentes y controlador, de reparación de caminos en fallo y puente de red
WO2005015855A1 (es) Procedimiento de conmutación de paquetes en un medio de transmisión con múltiples estaciones conectadas mediante distintos enlaces
KR20130079596A (ko) 네트워크 구성 방법, 링 네트워크 시스템, 노드
ES2638292B2 (es) Procedimiento de establecimiento y borrado de caminos múltiples disjuntos, de reenvío de tramas y puente de red
JP2013005143A (ja) リング型ネットワークシステム、ネットワーク管理装置及びｌ２スイッチ
Sharma et al. Meshed tree protocol for faster convergence in switched networks

Legal Events

Date Code Title Description
FG2A Definitive protection

Ref document number: 2647665

Country of ref document: ES

Kind code of ref document: B2

Effective date: 20180424