ES2785562T3 - Arquitectura SDN, procedimiento de reenvío de mensajes basado en arquitectura SDN - Google Patents

Arquitectura SDN, procedimiento de reenvío de mensajes basado en arquitectura SDN Download PDF

Info

Publication number
ES2785562T3
ES2785562T3 ES15841768T ES15841768T ES2785562T3 ES 2785562 T3 ES2785562 T3 ES 2785562T3 ES 15841768 T ES15841768 T ES 15841768T ES 15841768 T ES15841768 T ES 15841768T ES 2785562 T3 ES2785562 T3 ES 2785562T3
Authority
ES
Spain
Prior art keywords
controller
control plane
multiple controllers
forwarding device
flow table
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
ES15841768T
Other languages
English (en)
Inventor
Feicai Jin
Ran Chen
Yanjie Zhao
Xinwen Jiao
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.)
ZTE Corp
Original Assignee
ZTE Corp
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 ZTE Corp filed Critical ZTE Corp
Application granted granted Critical
Publication of ES2785562T3 publication Critical patent/ES2785562T3/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/02—Topology update or discovery
    • 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/42—Centralised routing
    • 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/02—Topology update or discovery
    • H04L45/036—Updating the topology between route computation elements, e.g. between OpenFlow controllers
    • 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/22—Alternate routing
    • 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/38—Flow based routing
    • 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/64—Routing or path finding of packets in data switching networks using an overlay routing layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/565—Conversion or adaptation of application format or content
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/567—Integrating service provisioning from a plurality of service providers

Landscapes

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

Abstract

Una arquitectura de red definida por software, SDN, que comprende múltiples controladores (500) y un dispositivo de reenvío (504), comprendiendo además la arquitectura SDN: un controlador de supervisión (502), conectado entre los múltiples controladores y el dispositivo de reenvío y configurado para recibir o supervisar (S202) mensajes del plano de control de los múltiples controladores, y caracterizado porque el controlador de supervisión está configurado para: determinar (S204) una tabla de flujo que se enviará al dispositivo de reenvío según una estrategia local y los mensajes del plano de control de los múltiples controladores; donde el controlador de supervisión está configurado para seleccionar una tabla de flujo transportada en un mensaje del plano de control de un controlador de los múltiples controladores de las tablas de flujo transportadas en los mensajes del plano de control de los múltiples controladores, y determinar la tabla de flujo seleccionada como la tabla de flujo que se enviará al dispositivo de reenvío.

Description

DESCRIPCIÓN
Arquitectura SDN, procedimiento de reenvío de mensajes basado en arquitectura SDN
Campo técnico
La presente descripción se refiere al campo de las comunicaciones, y más particularmente a una arquitectura SDN y un procedimiento para reenviar mensajes basado en la arquitectura SDN.
Antecedentes
Junto con la propuesta de un concepto SDN y el desarrollo de aplicaciones del mismo, actualmente se encuentra en una fase de desarrollo rápido una tecnología OpenFlow, como tecnología SDN central. En la actualidad, las redes OpenFlow construidas en virtud de la tecnología OpenFlow se han aplicado cada vez más a la producción práctica y la vida. La red OpenFlow adopta una arquitectura en la que el plano de control y el plano de reenvío (que también se denomina el plano de datos o el plano de usuario) están separados entre sí. La Fig. 1 es un diagrama de arquitectura de una red OpenFlow según una tecnología relacionada. Como se muestra en la Fig. 1, el plano de control de la red OpenFlow se implementa mediante un controlador OpenFlow. El controlador OpenFlow es un dispositivo con una alta capacidad de computación. Específicamente, puede ser un ordenador personal, un servidor, un grupo de servidores o similares. El plano de reenvío de la red OpenFlow se implementa mediante un conmutador OpenFlow. El conmutador OpenFlow es un dispositivo con una alta capacidad de conmutación, y puede ser un elemento de red que está provisto de múltiples puertos de red y realiza el procesamiento y el reenvío de mensajes basándose en tablas de flujo. La interfaz entre el controlador Open-Flow y el conmutador OpenFlow sigue un protocolo OpenFlow, por lo que la interfaz también se denomina un canal OpenFlow.
El protocolo OpenFlow está regulado y modificado por la Open Networking Foundation (ONF), una organización de estándares internacionales. El protocolo OpenFlow actual especifica que: en una red OpenFlow, todas las funciones de control se acreditan a los controladores OpenFlow, y los controladores OpenFlow controlan los comportamientos de reenvío del conmutador OpenFlow a través de canales OpenFlow, y cada controlador está conectado con el conmutador OpenFlow a través de los canales OpenFlow. El conmutador OpenFlow puede comunicarse con un controlador independiente, y también puede comunicarse con múltiples controladores al mismo tiempo para mejorar la fiabilidad, y durante la comunicación con los múltiples controladores, se requiere comunicación y sincronización de estado entre cada controlador.
En la actualidad, no hay ningún estándar de comunicación entre controladores, existen problemas acerca de la comunicación entre controladores de diferentes fabricantes y, además, los controladores de diferentes fabricantes tienen diferentes decisiones sobre el dispositivo de reenvío, lo que puede causar un trastorno de los comportamientos de reenvío y también es desfavorable para la asignación de recursos del dispositivo de reenvío.
El documento relacionado ("FlowVisor: A network virtualization layer", Rob Sherwood et al.) un informe técnico de OpenFlow describe una capa intermedia de supervisión y control que implementa virtualización de conmutador y segmentación de red.
Resumen
Para el problema técnico del trastorno del comportamiento de reenvío de mensajes causado por la falta de un estándar de comunicación entre controladores en la tecnología relacionada, las realizaciones de la presente descripción proporcionan una arquitectura SDN según la reivindicación 1, un procedimiento para un controlador de supervisión según la reivindicación 10 y un procedimiento para un dispositivo de reenvío según la reivindicación 13, para al menos resolver el problema anterior.
Según una realización de la presente descripción, se proporciona una arquitectura SDN, que puede incluir controladores y dispositivo de reenvío, y la arquitectura SDN incluye además: un controlador de supervisión, conectado entre los múltiples controladores y el dispositivo de reenvío y configurado para recibir o supervisar mensajes del plano de control de los múltiples controladores y determinar una tabla de flujo que se enviará al dispositivo de reenvío según una estrategia local y los mensajes del plano de control de los múltiples controladores.
En la realización, un extremo del controlador de supervisión puede estar conectado lógicamente con los múltiples controladores, y el otro extremo puede estar conectado lógicamente con el dispositivo de reenvío; los múltiples controladores pueden estar conectados lógicamente con el dispositivo de reenvío a través del controlador de supervisión; y el controlador de supervisión puede estar configurado para recibir primeros mensajes del plano de control de los múltiples controladores, procesar los primeros mensajes del plano de control para obtener segundos mensajes del plano de control según la estrategia local y enviar los segundos mensajes del plano de control al dispositivo de reenvío.
En la realización, el controlador de supervisión puede estar configurado para generar una tabla de flujo según la estrategia local y los mensajes del plano de control de los múltiples controladores, y determinar la tabla de flujo generada como la tabla de flujo que se enviará al dispositivo de reenvío.
En la realización, los canales de conexión lógica entre el controlador de supervisión y los múltiples controladores pueden incluir: primeros canales de conexión principal y primeros canales de conexión auxiliar, donde puede haber cero, uno o múltiples primeros canales de conexión auxiliar.
En la realización, los canales de conexión lógica entre el controlador de supervisión y el dispositivo de reenvío pueden incluir: un segundo canal de conexión principal y un segundo canal de conexión auxiliar, donde puede haber cero, uno o múltiples segundos canales de conexión auxiliar.
En la realización, el controlador de supervisión puede estar configurado además para recibir un tercer mensaje del plano de control desde el dispositivo de reenvío, procesar el tercer mensaje del plano de control para obtener un cuarto mensaje del plano de control según la estrategia local, y enviar el cuarto mensaje del plano de control a los múltiples controladores.
En la realización, los múltiples controladores pueden estar conectados directamente con el dispositivo de reenvío lógicamente, y los múltiples controladores pueden estar conectados con el dispositivo de reenvío a través del controlador de supervisión físicamente, donde el controlador de supervisión puede estar configurado para supervisar los mensajes del plano de control de los múltiples controladores.
En la realización, los canales de conexión lógica entre los múltiples controladores y el dispositivo de reenvío pueden incluir: terceros canales de conexión principal y uno o más terceros canales de conexión auxiliar; y el controlador de supervisión puede estar configurado para transmitir de manera transparente los mensajes del plano de control de los múltiples controladores en los terceros canales de conexión principal, y descartar o reenviar selectivamente los mensajes del plano de control de los múltiples controladores en los terceros canales de conexión auxiliar.
En la realización, el controlador de supervisión puede estar configurado para seleccionar una tabla de flujo de entre las tablas de flujo transportadas en los mensajes del plano de control de los múltiples controladores, y determinar la tabla de flujo seleccionada como la tabla de flujo que se enviará al dispositivo de reenvío.
En la realización, el controlador de supervisión puede estar configurado además para transmitir de manera transparente el mensaje del plano de control desde el dispositivo de reenvío a los múltiples controladores.
En la realización, cada controlador puede tener el mismo derecho de toma de decisiones para el dispositivo de reenvío.
Según otra realización de la presente descripción, se proporciona un procedimiento de procesamiento de reenvío de mensajes basado en arquitectura SDN, que puede incluir que: un controlador de supervisión reciba o supervise mensajes del plano de control de múltiples controladores en una arquitectura SDN; el controlador de supervisión determina una tabla de flujo según una estrategia local y los mensajes del plano de control de los múltiples controladores; y el controlador de supervisión envía la tabla de flujo determinada al dispositivo de reenvío configurado para reenvío de mensajes.
En la realización, un extremo del controlador de supervisión puede estar conectado lógicamente con los múltiples controladores, y el otro extremo puede estar conectado lógicamente con el dispositivo de reenvío; los múltiples controladores pueden estar conectados lógicamente con el dispositivo de reenvío a través del controlador de supervisión; y la etapa de que el controlador de supervisión reciba los mensajes del plano de control de los múltiples controladores en la arquitectura SDN puede incluir que: el controlador de supervisión reciba los mensajes del plano de control a través de canales de conexión lógica entre el controlador de supervisión y los múltiples controladores.
En la realización, la etapa de que el controlador de supervisión determina la tabla de flujo según la estrategia local y los mensajes del plano de control de los múltiples controladores pueden incluir que: el controlador de supervisión genere una tabla de flujo según la estrategia local y los mensajes del plano de control de los múltiples controladores, y determine la tabla de flujo generada como la tabla de flujo que se enviará al dispositivo de reenvío.
En la realización, los múltiples controladores pueden estar conectados directamente con el dispositivo de reenvío lógicamente, y los múltiples controladores pueden estar conectados con el dispositivo de reenvío a través del controlador de supervisión físicamente; y la etapa de que el controlador de supervisión supervise los mensajes del plano de control de los múltiples controladores en la arquitectura SDN puede incluir que: el controlador de supervisión supervise los mensajes del plano de control, enviados en canales de conexión lógica entre los múltiples controladores y el dispositivo de reenvío, de los múltiples controladores.
En la realización, la etapa de que el controlador de supervisión determina la tabla de flujo según la estrategia local y los mensajes del plano de control de los múltiples controladores pueden incluir que: el controlador de supervisión selecciona una tabla de flujo de las tablas de flujo transportadas en los mensajes del plano de control de los múltiples controladores, y determina la tabla de flujo seleccionada como la tabla de flujo que se enviará al dispositivo de reenvío.
Según otra realización de la presente descripción, se proporciona un procedimiento para reenviar mensajes basado en una arquitectura SDN, que puede incluir que: el dispositivo de reenvío en una arquitectura SDN reciba una tabla de flujo reenviada por un controlador de supervisión, donde la tabla de flujo puede ser una tabla de flujo determinada por el controlador de supervisión según una estrategia local y mensajes del plano de control de múltiples controladores; y el dispositivo de reenvío realice el reenvío de mensajes según la tabla de flujo reenviada por el controlador de supervisión.
Según las realizaciones de la presente descripción, en virtud del controlador de supervisión conectado entre los múltiples controladores y el dispositivo de reenvío, la tabla de flujo que se enviará al dispositivo de reenvío se determina según los mensajes del plano de control recibidos o supervisados de los múltiples controladores y la estrategia local, de modo que se resuelve el problema técnico del trastorno del comportamiento de reenvío de mensajes, que está causado por la falta de un estándar de comunicación entre los múltiples controladores y la incapacidad en la coordinación unificada de las decisiones de los múltiples controladores para el dispositivo de reenvío, en la tecnología relacionada, y se mejora aún más la fiabilidad de una red y la precisión de reenvío de mensajes.
Breve descripción de los dibujos
Los dibujos aquí descritos se adoptan para proporcionar una comprensión adicional de la presente descripción, y forman parte de la presente descripción. Las realizaciones esquemáticas de la presente descripción y las descripciones de las mismas se adoptan para explicar la presente descripción y no pretenden formar límites inadecuados a la presente descripción. En los dibujos:
La Fig. 1 es un diagrama de arquitectura de una red OpenFlow según la tecnología relacionada;
la Fig. 2 es un diagrama de flujo de un procedimiento de procesamiento de reenvío de mensajes basado en arquitectura SDN según una realización de la presente descripción;
la Fig. 3 es un diagrama de bloques estructurales de un dispositivo de procesamiento de reenvío de mensajes basado en arquitectura SDN según una realización de la presente descripción;
la Fig. 4 es un diagrama de flujo de un procedimiento para reenviar mensajes basado en una arquitectura SDN según una realización de la presente descripción;
la Fig. 5a es un diagrama bloques estructurales de un procedimiento para reenviar mensajes basado en una arquitectura SDN según una realización de la presente descripción;
la Fig. 5b es un diagrama de bloques estructurales de un procedimiento para reenviar mensajes basado en una arquitectura SDN según una realización de la presente descripción;
la Fig. 6 es un diagrama estructural de un sistema de reenvío de mensajes basado en arquitectura SDN según la realización 1 de la presente descripción;
la Fig. 7 es un diagrama estructural de un sistema de reenvío de mensajes basado en arquitectura SDN según la realización 2 de la presente descripción; y la Fig. 8 es un diagrama de flujo de un procedimiento para reenviar mensajes basado en una arquitectura SDN según la realización 3 de la presente descripción.
Descripción detallada de las realizaciones
La presente descripción se describirá a continuación con referencia a los dibujos y las realizaciones en detalle. Es importante observar que las realizaciones en la presente descripción y las características en las realizaciones pueden combinarse bajo la condición de que no haya conflictos.
Para los problemas técnicos del trastorno del comportamiento de reenvío de mensajes causado por la falta de un estándar de comunicación entre los múltiples controladores y la incapacidad en la coordinación unificada de decisiones de los múltiples controladores para el dispositivo de reenvío y similares en la tecnología relacionada, las realizaciones de la presente descripción proporcionan soluciones correspondientes, que se describirán en detalle.
La Fig. 2 es un diagrama de flujo de un procedimiento de procesamiento de reenvío de mensajes basado en arquitectura SDN según una realización de la presente descripción. Como se muestra en la Fig. 2, el procedimiento incluye:
etapa S202: un controlador de supervisión recibe o supervisa mensajes del plano de control de múltiples controladores en una arquitectura s DN;
etapa S204: el controlador de supervisión determina una tabla de flujo según una estrategia local y los mensajes del plano de control de los múltiples controladores; y etapa S206: el controlador de supervisión envía la tabla de flujo determinada al dispositivo de reenvío configurado para reenvío de mensajes.
Por cada una de las etapas de procesamiento, la tabla de flujo puede determinarse y enviarse al dispositivo de reenvío en virtud del controlador de supervisión según la estrategia local y los mensajes del plano de control de los múltiples controladores, de modo que una serie de problemas causados por la falta de un estándar de comunicación correspondiente para comunicación entre los múltiples controladores y, en particular, pueden evitarse radialmente los problemas del trastorno del comportamiento de reenvío de mensajes como resultado de ello y similares. Basándose en las etapas de procesamiento, las decisiones de los múltiples controladores para el dispositivo de reenvío pueden coordinarse de manera unificada, de modo que se mejora la fiabilidad de una red y la precisión de reenvío de mensajes.
En una realización preferida, el controlador de supervisión está conectado entre los múltiples controladores y el dispositivo de reenvío, es decir, los múltiples controladores forman la conexión de comunicación con el dispositivo de reenvío a través del controlador de supervisión, donde hay dos condiciones de conexión.
(1) Un extremo del controlador de supervisión está conectado lógicamente con los múltiples controladores, y el otro extremo está conectado lógicamente con el dispositivo de reenvío; los múltiples controladores están conectados lógicamente con el dispositivo de reenvío a través del controlador de supervisión; y en este momento, la operación de que el controlador de supervisión recibe los mensajes del plano de control de los múltiples controladores en la arquitectura SDN en la Etapa S202 puede representarse de, pero no limitarse a, la siguiente forma: el controlador de supervisión recibe los mensajes del plano de control a través de canales de conexión lógica entre el controlador de supervisión y los múltiples controladores.
En una realización preferida de las realizaciones, la Etapa S204 puede implementarse de, pero no limitarse a, la siguiente manera: el controlador de supervisión genera una tabla de flujo según la estrategia local y los mensajes del plano de control de los múltiples controladores, y determina la tabla de flujo generada como la tabla de flujo que se enviará al dispositivo de reenvío.
(2) Los múltiples controladores están conectados directamente con el dispositivo de reenvío lógicamente, y los múltiples controladores están conectados con el dispositivo de reenvío a través del controlador de supervisión físicamente; y en este momento, la operación de que el controlador de supervisión supervise los mensajes del plano de control de los múltiples controladores en la arquitectura SDN en la Etapa S202 puede representarse de, pero no limitarse a, la siguiente forma de implementación: el controlador de supervisión supervise los mensajes del plano de control, enviados en canales de conexión lógica entre los múltiples controladores y el dispositivo de reenvío, de los múltiples controladores.
En una realización preferida de las realizaciones, la etapa de que el controlador de supervisión determina la tabla de flujo según la estrategia local y los mensajes del plano de control de los múltiples controladores puede implementarse de, pero no limitarse a, la siguiente manera: el controlador de supervisión selecciona una tabla de flujo de las tablas de flujo transportadas en los mensajes del plano de control de los múltiples controladores, y determina la tabla de flujo seleccionada como la tabla de flujo que se enviará al dispositivo de reenvío.
El procedimiento de procesamiento de reenvío de mensajes basado en arquitectura SDN proporcionado por las realizaciones puede ser aplicable a las siguientes condiciones: cada controlador en los múltiples controladores tiene el mismo derecho de toma de decisiones para el dispositivo de reenvío.
En un procedimiento de implementación preferido, la estrategia local incluye, pero no se limita a uno de que: una tabla de flujo con la mayoría de las mismas estrategias de reenvío en las tablas de flujo de los múltiples controladores se toma como referencia (es decir, un principio de minoría que obedece a la mayoría); y se toma como referencia la tabla de flujo de un controlador especificado en los múltiples controladores.
En las realizaciones, se proporciona además un dispositivo de procesamiento de reenvío de mensajes basado en arquitectura SDN. El dispositivo está configurado para implementar el procedimiento, y también puede aplicarse a un controlador de supervisión. Como se muestra en la Fig. 3, el dispositivo incluye:
un módulo de agente 30, configurado para recibir o supervisar mensajes del plano de control de múltiples controladores en una arquitectura SDN;
un módulo de selección de estrategia, conectado al módulo de agente 30, conectado a un módulo transceptor 34 y configurado para determinar una tabla de flujo según una estrategia local y los mensajes del plano de control de los múltiples controladores; y
el módulo transceptor 34, conectado al módulo de selección de estrategia 32 y configurado para enviar la tabla de flujo determinada al dispositivo de reenvío configurado para reenvío de mensajes.
En un procedimiento de implementación preferido, el módulo de agente 30 está configurado para recibir tablas de flujo, que cumplan el siguiente requisito, de los múltiples controladores: cada controlador de los múltiples controladores tiene el mismo derecho de toma de decisiones para el dispositivo de reenvío.
Es importante observar que cada módulo puede implementarse a través de software o hardware, y este último puede implementarse de, pero no limitarse a, la siguiente manera: el módulo de agente 30, el módulo de selección de estrategia 32 y el módulo transceptor 34 están todos ubicados en el mismo procesador; o, el módulo de agente 30, el módulo de selección de estrategia 32 y el módulo transceptor 34 están ubicados en un primer procesador, un segundo procesador y un tercer procesador respectivamente.
En las realizaciones, se proporciona además un procedimiento para reenvío de mensajes basado en una arquitectura SDN. Como se muestra en la Fig. 4, el procedimiento incluye las siguientes etapas de procesamiento:
etapa S402: el dispositivo de reenvío en una arquitectura SDN recibe una tabla de flujo reenviada por un controlador de supervisión, donde la tabla de flujo es una tabla de flujo determinada por el controlador de supervisión según una estrategia local y mensajes de plano de control de múltiples controladores; y
etapa S404: el dispositivo de reenvío realiza el reenvío de mensajes según la tabla de flujo reenviada por el controlador de supervisión.
En una realización preferida del procedimiento de reenvío de mensajes basado en arquitectura SDN, cada controlador de los múltiples controladores tiene el mismo derecho de toma de decisiones para el dispositivo de reenvío.
Las realizaciones de la presente descripción proporcionan además un dispositivo de reenvío de mensajes basado en arquitectura SDN. El dispositivo está configurado para implementar el procedimiento mostrado en la Fig. 4, y el dispositivo puede aplicarse al dispositivo de reenvío en una arquitectura SDN. Como se muestra en la Fig. 5a, el dispositivo incluye:
un módulo de recepción 50, configurado para recibir una tabla de flujo reenviada por un controlador de supervisión, donde la tabla de flujo es una tabla de flujo determinada por el controlador de supervisión según una estrategia local y mensajes de plano de control de múltiples controladores; y
un módulo de envío 52, conectado al módulo de recepción 50 y configurado para realizar el reenvío de mensajes según la tabla de flujo reenviada por el controlador de supervisión.
Es importante observar que cada módulo puede implementarse a través de software o hardware, y este último puede implementarse de, pero no limitarse a, la siguiente manera: el módulo de recepción 50 y el módulo de envío 52 están ambos ubicados en el mismo procesador; o, el módulo de recepción 50 y el módulo de envío 52 están ubicados en un primer procesador y un segundo procesador respectivamente.
Las realizaciones de la presente descripción proporcionan además un sistema de reenvío de mensajes basado en arquitectura SDN, como se muestra en la figura 5b, el sistema incluye: controladores 500, un controlador de supervisión 502 y dispositivo de reenvío 504, donde el controlador de supervisión 502 está conectado entre los múltiples controladores 500 y el dispositivo de reenvío 504, y está configurado para recibir o supervisar mensajes del plano de control de los múltiples controladores 500, y determinar una tabla de flujo que se enviará al dispositivo de reenvío 504 según una estrategia local y los mensajes del plano de control de los múltiples controladores 500. Una arquitectura específica puede referirse a la Fig. 6 y la Fig. 7. En un procedimiento de implementación preferido, cada controlador tiene el mismo derecho de toma de decisiones para el dispositivo de reenvío.
Una arquitectura SDN proporcionada por las realizaciones puede representarse por dos formas.
(1) Un extremo del controlador de supervisión está conectado lógicamente con los múltiples controladores, y el otro extremo está conectado lógicamente con el dispositivo de reenvío; los múltiples controladores están conectados lógicamente con el dispositivo de reenvío a través del controlador de supervisión; y el controlador de supervisión está configurado para recibir primeros mensajes del plano de control de los múltiples controladores, procesar los primeros mensajes del plano de control para obtener segundos mensajes del plano de control según la estrategia local y enviar los segundos mensajes del segundo plano de control al dispositivo de reenvío. En este momento, el controlador de supervisión está configurado para generar una tabla de flujo según la estrategia local y los mensajes del plano de control de los múltiples controladores, y determinar la tabla de flujo generada como la tabla de flujo que se enviará al dispositivo de reenvío.
En un procedimiento de implementación preferido, los canales de conexión lógica entre el controlador de supervisión y los múltiples controladores incluyen: primeros canales de conexión principal y primeros canales de conexión auxiliar, donde hay cero, uno o múltiples primeros canales de conexión auxiliar.
En otro procedimiento de implementación preferido, los canales de conexión lógica entre el controlador de supervisión y el dispositivo de reenvío incluyen: un segundo canal de conexión principal y un segundo canal de conexión auxiliar, donde hay cero, uno o múltiples segundos canales de conexión auxiliar.
(2) Los múltiples controladores están conectados directamente con el dispositivo de reenvío lógicamente, y los múltiples controladores están conectados con el dispositivo de reenvío a través del controlador de supervisión físicamente, donde el controlador de supervisión está configurado para supervisar los mensajes del plano de control de los múltiples controladores.
En una realización preferida, los canales de conexión lógica entre los múltiples controladores y el dispositivo de reenvío incluyen: terceros canales de conexión principal y uno o más terceros canales de conexión auxiliar; y el controlador de supervisión está configurado para transmitir de manera transparente los mensajes del plano de control de los múltiples controladores en los terceros canales de conexión principal, y/o está configurado para descartar o reenviar selectivamente los mensajes del plano de control de los múltiples controladores en los terceros canales de conexión auxiliar.
En este momento, el controlador de supervisión puede estar configurado para seleccionar una tabla de flujo de entre las tablas de flujo transportadas en los mensajes del plano de control de los múltiples controladores, y determinar la tabla de flujo seleccionada como la tabla de flujo que se enviará al dispositivo de reenvío.
Además, el controlador de supervisión está configurado además para transmitir de manera transparente el mensaje del plano de control desde el dispositivo de reenvío a los múltiples controladores.
En las realizaciones, cada controlador tiene el mismo derecho de toma de decisiones para el dispositivo de reenvío.
Para comprender mejor las realizaciones, a continuación, se harán descripciones detalladas con referencia a realizaciones preferidas.
Realización 1
La Fig. 6 es un diagrama estructural de un sistema de reenvío de mensajes basado en arquitectura SDN según la realización 1 de la presente descripción. La realización también es aplicable a un sistema basado en la Arquitectura de Computación Avanzada de Telecomunicaciones (ATCA) e incluye los siguientes contenidos.
1: Hay múltiples controladores SDN en una arquitectura SDN, donde cada controlador ejecuta un modo EQUAL. Como se muestra en la Fig. 6, hay múltiples controladores SDN en la arquitectura SDN, es decir, un controlador 1, un controlador 2 y un controlador 3. Los tres controladores ejecutan el modo EQUAL. El modo EQUAL se refiere a que: cada controlador tiene el mismo derecho de toma de decisiones para el dispositivo de reenvío SDN.
2: Cada controlador establece canales de conexión (equivalentes a los primeros canales de conexión) con un controlador de supervisión y se comunica a través de los canales de conexión. Además, cada controlador establece los canales de conexión con un módulo de agente del controlador de supervisión.
Alternativamente, cada controlador puede establecer selectivamente múltiples canales de conexión auxiliar, además de un canal de conexión principal, con el controlador de supervisión.
Como se muestra en la Fig. 6, se establecen conexiones entre el controlador 1 y el controlador de supervisión, entre el controlador 2 y el controlador de supervisión y entre el controlador 3 y el módulo de agente del controlador de supervisión. Cada controlador reenvía un mensaje del plano de control generado al controlador de supervisión.
3: El controlador de supervisión establece canales de conexión (equivalentes a los segundos canales de conexión) con el dispositivo de reenvío SDN y se comunica a través de los canales de conexión.
Como se muestra en la Fig. 6, el controlador de supervisión establece los canales de conexión con el dispositivo de reenvío SDN.
Alternativamente, el controlador de supervisión puede establecer selectivamente múltiples canales de conexión auxiliar, además de una conexión principal, con el dispositivo de reenvío SDN.
Un módulo de control del controlador de supervisión selecciona una tabla de flujo apropiada para transmisión al dispositivo de reenvío SDN según la propia estrategia local. El dispositivo de reenvío SDN reenvía los mensajes según la tabla de flujo.
Realización 2
En la realización:
1: Hay múltiples controladores SDN en una arquitectura SDN, donde cada controlador SDN ejecuta un modo EQUAL.
La Fig. 7 es un diagrama estructural de un sistema de reenvío de mensajes basado en arquitectura SDN según la realización 2 de la presente descripción. Como se muestra en la Fig. 7, hay múltiples controladores SDN en la arquitectura SDN, es decir, un controlador 1, un controlador 2 y un controlador 3. Los tres controladores ejecutan el modo EQUAL. El modo EQUAL se refiere a que: cada controlador tiene el mismo derecho de toma de decisiones para el dispositivo de reenvío SDN.
2: Cada controlador establece conexiones principales y auxiliares con el dispositivo de reenvío SDN. Los canales internos de los múltiples controladores se ven obligados a transferirse a un controlador de supervisión. Es decir, cada controlador establece canales de conexión principal y auxiliar con el dispositivo de reenvío SDN a través del controlador de supervisión.
Alternativamente, cada controlador puede establecer múltiples canales de conexión con el dispositivo de reenvío SDN, es decir, un canal de conexión principal y múltiples conexiones auxiliares.
El controlador de supervisión transmite de manera transparente mensajes en las conexiones principales, parte de los mensajes en las conexiones auxiliares, como mensajes de eco, pueden transmitirse de manera transparente, y mensajes como tablas de grupo y tablas de flujo relacionadas con el reenvío de servicios pueden transmitirse al dispositivo de reenvío SDN solo después de que se tomen decisiones según la propia estrategia local.
Las conexiones principales son necesarias para adoptar el Protocolo de control de transferencia (TCP) o las conexiones del Protocolo de seguridad de la capa de transporte (TLS), y las conexiones solo pueden supervisarse y no pueden modificarse. Las conexiones auxiliares adoptan un Protocolo de datagramas de usuario (UDP) para el establecimiento de enlaces, y pueden supervisar y controlar la transmisión de todas las entradas de la tabla de reenvío y los mensajes de protocolo.
Realización 3
La realización puede basarse en, pero no se limita a, un sistema de reenvío de mensajes mostrado en la Fig. 7. la Fig. 8 es un diagrama de flujo de un procedimiento para reenviar mensajes basado en una arquitectura SDN según la realización 3 de la presente descripción. Como se muestra en la Fig. 8, el procedimiento incluye las siguientes etapas.
Etapa S802: El dispositivo de reenvío SDN envía un mensaje del plano de control a los controladores a través de un controlador de supervisión según una configuración de una tabla de flujo después de recibir el mensaje.
Por supuesto, el dispositivo de reenvío SDN también puede seleccionar descartar directamente el mensaje según la configuración de la tabla de flujo.
Etapa S804: el controlador de supervisión transmite de manera transparente el mensaje de protocolo a cada controlador a través de canales del plano de control.
Como se muestra en la Fig. 7, el controlador de supervisión transmite de manera transparente el mensaje de protocolo recibido a un controlador 1, un controlador 2 y un controlador 3.
Etapa S806: los múltiples controladores generan tablas de flujo según sus propias decisiones y las transmiten al dispositivo de reenvío SDN a través de conexiones auxiliares y el controlador de supervisión.
Como se muestra en la Fig. 7, una interfaz de salida de una tabla de flujo generada por el controlador 1 es un puerto 1, una interfaz de salida de una tabla de flujo generada por el controlador 2 es un puerto 2, y una interfaz de salida de una tabla de flujo generada por el controlador 3 es el puerto 1. Puede existir un error de computación del controlador 2 y la interfaz de salida generada es el puerto 2. Por supuesto, también existe un escenario en el que un determinado controlador falla y puede no generar ninguna tabla de flujo y transmitir la tabla de flujo. Cada controlador envía la propia tabla de flujo generada al dispositivo de reenvío SDN a través del controlador de supervisión.
Etapa S808: del controlador de supervisión selecciona una tabla de flujo apropiada para transmisión al dispositivo de reenvío SDN según la propia estrategia local.
Como se muestra en la Fig. 7, el controlador de supervisión recoge las 3 tablas de flujo transmitidas por los 3 controladores, y selecciona transmitir la tabla de flujo generada por el controlador 1 al dispositivo de reenvío SDN según la propia decisión local del controlador de supervisión, por ejemplo, según un principio de la minoría que obedece a la mayoría.
Etapa S810: el dispositivo de reenvío SDN genera una tabla de flujo y reenvía mensajes según la tabla de flujo.
Los expertos en la materia deberían saber que la realización de la presente descripción puede proporcionarse como un procedimiento, un sistema o un producto de programa informático. Por lo tanto, la presente descripción puede adoptar una forma de realización de hardware, realización de software o realización de software y hardware. Además, la presente descripción puede adoptar una forma de producto de programa informático implementado en uno o más medios de almacenamiento disponibles en un ordenador (incluyendo, pero no limitados a una memoria de disco, una memoria óptica y similares) que incluyen códigos de programa disponibles en un ordenador.
La presente descripción se describe con referencia a diagramas de flujo y/o diagramas de bloques del procedimiento, dispositivo (sistema) y producto de programa informático según la realización de la presente descripción. Debería entenderse que cada flujo y/o bloque en los diagramas de flujo y/o los diagramas de bloques y combinaciones de los flujos y/o bloques en los diagramas de flujo y/o los diagramas de bloques pueden implementarse mediante instrucciones de programas de ordenador. Estas instrucciones de programa de ordenador pueden proporcionarse para un ordenador universal, un ordenador dedicado, un procesador incorporado o un procesador de otro dispositivo de procesamiento de datos programable para generar una máquina, de modo que un dispositivo para realizar una función especificada en un flujo o más flujos en los diagramas de flujo y/o un bloque o más bloques en los diagramas de bloques se genera mediante las instrucciones ejecutadas a través del ordenador o el procesador del otro dispositivo de procesamiento de datos programable.
Estas instrucciones de programa de ordenador también pueden almacenarse en una memoria legible por ordenador capaz de guiar al ordenador o al otro dispositivo de procesamiento de datos programable para que funcione de una manera específica, de modo que un producto que incluya un dispositivo de instrucciones pueda generarse mediante las instrucciones almacenadas en la memoria legible por ordenador, realizando el dispositivo la función especificada en un flujo o muchos flujos en los diagramas de flujo y/o un bloque o muchos bloques en los diagramas de bloques.
Estas instrucciones de programa de ordenador pueden cargarse además en el ordenador u otro dispositivo de procesamiento de datos programare, de modo que una serie de etapas operativas se ejecuten en el ordenador o el otro dispositivo de procesamiento de datos programable para generar el procesamiento implementado por el ordenador, y las etapas para realizar la función especificada en un flujo o muchos flujos en los diagramas de flujo y/o un bloque o muchos bloques en los diagramas de bloques son proporcionadas por las instrucciones ejecutadas en el ordenador o el otro dispositivo de procesamiento de datos programable.
Basándose en los contenidos anteriores, en otra realización, se proporciona software, que está configurado para ejecutar las soluciones técnicas descritas en las realizaciones mencionadas anteriormente y los modos de implementación preferidos.
En otra realización, se proporciona además un medio de almacenamiento, en el que se almacena el software mencionado anteriormente, incluyendo el medio de almacenamiento, pero no limitado a: un disco óptico, un disquete, un disco duro, una memoria borrable y similares.
Obviamente, los expertos en la materia deberían saber que cada módulo o cada etapa de la presente descripción puede implementarse mediante un dispositivo informático universal, y los módulos o etapas pueden concentrarse en un único dispositivo informático o distribuirse en una red formada por una pluralidad de dispositivos informáticos, y opcionalmente puede implementarse mediante códigos de programa ejecutables para los dispositivos informáticos, de modo que los módulos o etapas puedan almacenarse en un dispositivo de almacenamiento para ejecución con los dispositivos informáticos, las etapas mostradas o descritas pueden ejecutarse en secuencias diferentes de las aquí descritas en algunas circunstancias, o pueden formar cada módulo de circuito integrado respectivamente, o múltiples módulos o etapas en los mismos pueden formar un único módulo de circuito integrado para la implementación. Como consecuencia, la presente descripción no se limita a ninguna combinación específica de hardware y software.
Lo anterior es solo la realización preferida de la presente descripción y no pretende limitar la presente descripción. Para los expertos en la materia, la presente descripción puede tener diversas modificaciones y variaciones.
Aplicación industrial
Basándose en las soluciones técnicas proporcionadas por las realizaciones de la presente descripción, los medios técnicos de determinación de la tabla de flujo que se enviará al dispositivo de reenvío en virtud del controlador de supervisión conectado entre los múltiples controladores y el dispositivo de reenvío según los mensajes del plano de control recibidos o supervisados de los múltiples controladores y se adopta la estrategia local, de modo que se resuelven los problemas técnicos del trastorno del comportamiento de reenvío de mensajes causado por la falta de un estándar de comunicación entre los múltiples controladores y la incapacidad en la coordinación unificada de las decisiones de los múltiples controladores para el dispositivo de reenvío y similares en la tecnología relacionada, y se mejora aún más la fiabilidad de una red y la precisión de reenvío de mensajes.

Claims (13)

REIVINDICACIONES
1. Una arquitectura de red definida por software, SDN, que comprende múltiples controladores (500) y un dispositivo de reenvío (504), comprendiendo además la arquitectura SDN:
un controlador de supervisión (502), conectado entre los múltiples controladores y el dispositivo de reenvío y configurado para recibir o supervisar (S202) mensajes del plano de control de los múltiples controladores, y caracterizado porque el controlador de supervisión está configurado para: determinar (S204) una tabla de flujo que se enviará al dispositivo de reenvío según una estrategia local y los mensajes del plano de control de los múltiples controladores; donde el controlador de supervisión está configurado para seleccionar una tabla de flujo transportada en un mensaje del plano de control de un controlador de los múltiples controladores de las tablas de flujo transportadas en los mensajes del plano de control de los múltiples controladores, y determinar la tabla de flujo seleccionada como la tabla de flujo que se enviará al dispositivo de reenvío.
2. La arquitectura SDN según la reivindicación 1, donde un extremo del controlador de supervisión está conectado lógicamente con los múltiples controladores, y el otro extremo está conectado lógicamente con el dispositivo de reenvío; los múltiples controladores están conectados lógicamente con el dispositivo de reenvío a través del controlador de supervisión; y el controlador de supervisión está configurado para recibir primeros mensajes del plano de control de los múltiples controladores, procesar los primeros mensajes del plano de control para obtener segundos mensajes del plano de control según la estrategia local y enviar los segundos mensajes del plano de control al dispositivo de reenvío.
3. La arquitectura SDN según la reivindicación 2, donde los canales de conexión lógica entre el controlador de supervisión y cada controlador de los múltiples controladores comprenden: primeros canales de conexión principal y primeros canales de conexión auxiliar, donde hay uno o múltiples primeros canales de conexión auxiliar.
4. La arquitectura SDN según la reivindicación 2, donde los canales de conexión lógica entre el controlador de supervisión y el dispositivo de reenvío comprenden: un segundo canal de conexión principal y un segundo canal de conexión auxiliar, donde hay uno o múltiples segundos canales de conexión auxiliar.
5. La arquitectura SDN según la reivindicación 2, donde el controlador de supervisión está configurado además para recibir un tercer mensaje del plano de control desde el dispositivo de reenvío, procesar el tercer mensaje del plano de control para obtener un cuarto mensaje del plano de control según la estrategia local y enviar el cuarto mensaje del plano de control a los múltiples controladores.
6. La arquitectura SDN según la reivindicación 1, donde los múltiples controladores están conectados directamente con el dispositivo de reenvío lógicamente, y los múltiples controladores están conectados con el dispositivo de reenvío a través del controlador de supervisión físicamente, donde el controlador de supervisión está configurado para supervisar los mensajes del plano de control de los múltiples controladores.
7. La arquitectura SDN según la reivindicación 6, donde los canales de conexión lógica entre los múltiples controladores y el dispositivo de reenvío comprenden: terceros canales de conexión principal y uno o más terceros canales de conexión auxiliar; y
el controlador de supervisión está configurado para transmitir de manera transparente los mensajes del plano de control de los múltiples controladores en los terceros canales de conexión principal, y descartar o reenviar selectivamente los mensajes del plano de control de los múltiples controladores en los terceros canales de conexión auxiliar.
8. La arquitectura SDN según la reivindicación 6, donde el controlador de supervisión está configurado además para transmitir de manera transparente un mensaje del plano de control desde el dispositivo de reenvío a los múltiples controladores.
9. La arquitectura SDN según cualquiera de las reivindicaciones 1-8, donde cada controlador tiene el mismo derecho de toma de decisiones para el dispositivo de reenvío.
10. Un procedimiento para reenviar mensajes basado en la arquitectura de red definida por software SDN, que comprende:
recibir o supervisar (S202), mediante un controlador de supervisión (502), mensajes del plano de control de múltiples controladores (500) en la arquitectura SDN; y caracterizado porque el procedimiento comprende además determinar (S204), mediante el controlador de supervisión, una tabla de flujo según una estrategia local y los mensajes del plano de control de los múltiples controladores; y
enviar (S206), mediante el controlador de supervisión, la tabla de flujo determinada a un dispositivo de reenvío (504) para reenvío de mensajes; donde determinar, mediante el controlador de supervisión, la tabla de flujo según la estrategia local y los mensajes del plano de control de los múltiples controladores comprende: seleccionar, mediante el controlador de supervisión, una tabla de flujo transportada en un mensaje del plano de control de un controlador de los múltiples controladores de las tablas de flujo transportadas en los mensajes del plano de control de los múltiples controladores, y determinar la tabla de flujo seleccionada como la tabla de flujo que se enviará al dispositivo de reenvío.
11. El procedimiento según la reivindicación 10, donde un extremo del controlador de supervisión está conectado lógicamente con los múltiples controladores, y el otro extremo está conectado lógicamente con el dispositivo de reenvío; los múltiples controladores están conectados lógicamente con el dispositivo de reenvío a través del controlador de supervisión; y recibir, mediante el controlador de supervisión, los mensajes del plano de control de los múltiples controladores en la arquitectura SDN comprende:
recibir, mediante el controlador de supervisión, los mensajes del plano de control a través de canales de conexión lógica entre el controlador de supervisión y los múltiples controladores.
12. El procedimiento según la reivindicación 10, donde los múltiples controladores están conectados directamente con el dispositivo de reenvío lógicamente, y los múltiples controladores están conectados con el dispositivo de reenvío a través del controlador de supervisión físicamente; y supervisar, mediante el controlador de supervisión, los mensajes del plano de control de los múltiples controladores en la arquitectura SDN comprende:
supervisar, mediante el controlador de supervisión, los mensajes del plano de control, enviados en canales de conexión lógica entre los múltiples controladores y el dispositivo de reenvío, de los múltiples controladores.
13. Un procedimiento para reenviar mensajes basado en la arquitectura de red definida por software SDN, que comprende:
determinar (S204), mediante un controlador de supervisión (502), una tabla de flujo según una estrategia local y mensajes del plano de control de múltiples controladores (500);
recibir (S402), mediante un dispositivo de reenvío (504) en la arquitectura SDN, la tabla de flujo reenviada por el controlador de supervisión; y
realizar (S404), mediante el controlador de reenvío, el reenvío de mensajes según la tabla de flujo reenviada por el controlador de supervisión; donde determinar (S204), mediante el controlador de supervisión, la tabla de flujo según la estrategia local y los mensajes del plano de control de los múltiples controladores comprende: seleccionar, mediante el controlador de supervisión, una tabla de flujo transportada en un mensaje del plano de control de un controlador de los múltiples controladores de las tablas de flujo transportadas en los mensajes del plano de control de los múltiples controladores, y determinar la tabla de flujo seleccionada como la tabla de flujo que se enviará al dispositivo de reenvío.
ES15841768T 2014-09-15 2015-05-12 Arquitectura SDN, procedimiento de reenvío de mensajes basado en arquitectura SDN Active ES2785562T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201410469598.9A CN105490960B (zh) 2014-09-15 2014-09-15 基于sdn架构的报文转发方法及系统
PCT/CN2015/078804 WO2016041367A1 (zh) 2014-09-15 2015-05-12 Sdn架构、基于sdn架构的报文转发方法

Publications (1)

Publication Number Publication Date
ES2785562T3 true ES2785562T3 (es) 2020-10-07

Family

ID=55532523

Family Applications (1)

Application Number Title Priority Date Filing Date
ES15841768T Active ES2785562T3 (es) 2014-09-15 2015-05-12 Arquitectura SDN, procedimiento de reenvío de mensajes basado en arquitectura SDN

Country Status (5)

Country Link
US (1) US10432501B2 (es)
EP (1) EP3197109B1 (es)
CN (1) CN105490960B (es)
ES (1) ES2785562T3 (es)
WO (1) WO2016041367A1 (es)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018165866A1 (zh) * 2017-03-14 2018-09-20 华为技术有限公司 一种sdn及其报文转发的方法和装置
CN109039948B (zh) * 2017-06-12 2022-10-28 刘昱 一种控制面信息生成方法、装置及计算机可读存储介质
KR102454398B1 (ko) 2018-02-19 2022-10-14 한국전자통신연구원 분산형 소프트웨어 정의 네트워킹 방법 및 장치
US11054875B2 (en) 2018-09-02 2021-07-06 Arista Networks, Inc. Centralized adaptive power management
CN115277424B (zh) * 2022-06-23 2023-10-03 中国联合网络通信集团有限公司 软件定义网络中的决策下发方法、装置及存储介质

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8711860B2 (en) * 2011-12-22 2014-04-29 Telefonaktiebolaget L M Ericsson (Publ) Controller for flexible and extensible flow processing in software-defined networks
US9450817B1 (en) * 2013-03-15 2016-09-20 Juniper Networks, Inc. Software defined network controller
US9160650B2 (en) * 2013-06-17 2015-10-13 Futurewei Technologies, Inc. Enhanced flow entry table cache replacement in a software-defined networking switch
CN104283756B (zh) * 2013-07-02 2017-12-15 新华三技术有限公司 一种实现分布式多租户虚拟网络的方法和装置
CN104348727B (zh) * 2013-08-05 2018-05-15 新华三技术有限公司 OpenFlow网络中的流表表项处理方法及设备
US20160197831A1 (en) * 2013-08-16 2016-07-07 Interdigital Patent Holdings, Inc. Method and apparatus for name resolution in software defined networking
CN103647658B (zh) * 2013-11-27 2016-12-07 华为技术有限公司 一种软件定义网络系统中网络设备的管理方法和控制器
CN103685250A (zh) 2013-12-04 2014-03-26 蓝盾信息安全技术股份有限公司 一种基于sdn的虚拟机安全策略迁移的系统及方法
CN104702502B (zh) * 2013-12-09 2019-11-26 中兴通讯股份有限公司 网络路径计算方法及装置
CN103905523A (zh) * 2013-12-23 2014-07-02 浪潮(北京)电子信息产业有限公司 一种基于sdn的云计算网络虚拟化实现方法及系统
WO2015152436A1 (ko) * 2014-03-31 2015-10-08 쿨클라우드㈜ Sdn 기반의 서비스 체이닝 시스템
US9407541B2 (en) * 2014-04-24 2016-08-02 International Business Machines Corporation Propagating a flow policy by control packet in a software defined network (SDN) based network
WO2015184610A1 (zh) * 2014-06-05 2015-12-10 华为技术有限公司 一种发送报文的方法及装置
WO2015187946A1 (en) * 2014-06-05 2015-12-10 KEMP Technologies Inc. Adaptive load balancer and methods for intelligent data traffic steering
CN104009871A (zh) 2014-06-06 2014-08-27 中国科学院声学研究所 Sdn控制器实现方法及sdn控制器
US9602308B2 (en) * 2014-06-23 2017-03-21 International Business Machines Corporation Servicing packets in a virtual network and a software-defined network (SDN)

Also Published As

Publication number Publication date
US10432501B2 (en) 2019-10-01
CN105490960B (zh) 2019-10-18
EP3197109A4 (en) 2017-09-27
CN105490960A (zh) 2016-04-13
EP3197109B1 (en) 2020-01-29
EP3197109A1 (en) 2017-07-26
US20170257305A1 (en) 2017-09-07
WO2016041367A1 (zh) 2016-03-24

Similar Documents

Publication Publication Date Title
ES2785562T3 (es) Arquitectura SDN, procedimiento de reenvío de mensajes basado en arquitectura SDN
US11696242B2 (en) Link auto-negotiation between a radio equipment controller (REC) and radio equipment (RE) in an ethernet-based fronthaul network
US11012261B2 (en) Associating VXLANs with tunnels
US20150003464A1 (en) LACP Negotiation Processing Method, Relay Node, and System
EP3014826B1 (en) Link aggregation
CN105656645B (zh) 堆叠系统的故障处理的决策方法和装置
CN105871743B (zh) 聚合端口状态协商方法以及装置
US10868754B2 (en) High availability input/output management nodes
US10530636B2 (en) Link management method, device and system in virtual machine environment
US20160344633A1 (en) Load balancing method, device, system and computer storage medium
CN104125088A (zh) Drni中同一端内系统之间交互信息的方法和系统
US10296407B2 (en) Method to detect and to handle failures in the communication in a computer network
WO2021083208A1 (zh) 网络拓扑发现方法及节点设备
Ochoa-Aday et al. Self-healing and SDN: bridging the gap
WO2016116050A1 (zh) 环保护链路故障保护方法、设备及系统
US9166868B2 (en) Distributed control plane for link aggregation
US9984028B2 (en) Redundancy for port extender chains
Görkemli et al. Dynamic management of control plane performance in software-defined networks
CN114303349A (zh) 虚拟网络接口控制器中的双向转发检测(bfd)卸载
WO2015172745A1 (en) Bidirectional forwarding detection
CN103220189A (zh) 一种mad检测备份方法和设备
EP4133706A1 (en) Dead peer detection across split control plane nodes and data plane nodes of a tunneled communication session
CN108604996A (zh) 一种nfv系统中的策略传输方法和装置
US20160308787A1 (en) Method for processing event between controller and network device
US9749223B2 (en) Linear path protection in a centralized controller environment