ES2664075T3 - Priorización de paquetes en una red definida por software que implementa OpenFlow - Google Patents

Priorización de paquetes en una red definida por software que implementa OpenFlow Download PDF

Info

Publication number
ES2664075T3
ES2664075T3 ES13857704.4T ES13857704T ES2664075T3 ES 2664075 T3 ES2664075 T3 ES 2664075T3 ES 13857704 T ES13857704 T ES 13857704T ES 2664075 T3 ES2664075 T3 ES 2664075T3
Authority
ES
Spain
Prior art keywords
correspondence
flow
flow table
service
fields
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
ES13857704.4T
Other languages
English (en)
Inventor
Jiao Wang
Min Luo
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.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
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 Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Application granted granted Critical
Publication of ES2664075T3 publication Critical patent/ES2664075T3/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
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2425—Traffic characterised by specific attributes, e.g. priority or QoS for supporting services specification, e.g. SLA
    • H04L47/2433—Allocation of priorities to traffic types
    • 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/54—Organization of routing tables
    • 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
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/74—Address processing for routing
    • H04L45/745—Address table lookup; Address filtering

Abstract

Un aparato (200), que comprende: un receptor configurado para recibir instrucciones; un sistema de memoria (260) acoplado al receptor y configurado para almacenar las instrucciones; caracterizado por que el aparato comprende además: un procesador (230) acoplado al sistema de memoria y configurado para ejecutar las instrucciones con el fin de provocar que el aparato: implemente un conducto de flujo (300), en el que el conducto de flujo comprende una serie de tablas de flujo, en el que las tablas de flujo comprenden campos de correspondencia, en el que los campos de correspondencia se ordenan en base a una priorización de servicios de red y a dependencias compartidas de campos de correspondencia, en el que las dependencias compartidas presentadas de correspondencia son requisitos requeridos por algunos de los campos de correspondencia para utilizar otro campo de correspondencia, y encamine un paquete utilizando el conducto de flujo.

Description

5
10
15
20
25
30
35
40
45
50
55
DESCRIPCION
Priorización de paquetes en una red definida por software que implementa OpenFlow DECLARACIÓN SOBRE INVESTIGACIÓN O DESARROLLO SUBVENCIONADOS FEDERALMENTE
No aplicable
REFERENCIA A UN APÉNDICE DE MICROFICHAS
No aplicable
ANTECEDENTES
Las redes modernas de comunicaciones comprenden nodos, tales como encaminadores, conmutadores, puentes y otros dispositivos, que transportan datos a través de las redes. Con el paso de los años, las redes se han ido haciendo cada vez más complejas, conduciendo a mallas entrelazadas de nodos de red. Como resultado, los proveedores de nodos se han esforzado para personalizar, optimizar y mejorar el rendimiento de los nodos. El trabajo en red definido por software (SDN, software-defined networking) es una tecnología de red emergente que trata dichas personalización, optimización y mejora. SDN simplifica las redes al desacoplar la funcionalidad de envío de datos (es decir, el plano de datos) respecto de la funcionalidad de encaminamiento, recursos y otra funcionalidad de gestión (es decir, el plano de control). Como resultado, mientras que los nodos de red tradicionales pueden proporcionar tanto la funcionalidad del plano de datos como la funcionalidad del plano de control, un nodo SDN puede proporcionar la funcionalidad del plano de datos y un controlador SDN puede proporcionar la funcionalidad del plano de control. Los servicios de interfaz de programación de aplicaciones (API, application programming interface) abierta, tales como OpenFlow, pueden estandarizar las interacciones entre el plano de datos y el plano de control, y pueden permitir la implementación de nodos y controladores que no son específicos de ningún proveedor. Como resultado, SDN conjuntamente con un servicio de API abierta tal como OpenFlow pueden proporcionar beneficios, tales como personalización, optimización y rendimiento mejorados.
El documento WO 2012/032684 A1 da conocer un mecanismo para conseguir la extensión del número de entradas de una tabla de flujo abierto utilizando tablas en un conmutador como recursos existentes, en el que cuando el puerto de entrada es el puerto válido de OpenFlow, el conmutador transfiere el paquete desde puerto de entrada a la sección de función de OpenFlow. La sección de función de OpenFlow ejecuta un proceso de búsqueda sobre el paquete transferido, en la sección de gestión de tablas de OpenFlow que contiene una serie de tablas del conmutador. A continuación, la sección de funciones de OpenFlow determina una acción del paquete en base al resultado de la búsqueda y una prioridad de cada tabla en el elemento de resolución de acciones OpenFlow, denominándose la prioridad un nivel de prioridad.
RESUMEN
En una realización, la invención incluye un aparato OpenFlow de trabajo en red definido por software (SDN), que comprende un procesador, y un sistema de memoria acoplado al procesador y que comprende un conducto de flujo, en el que el conducto de flujo comprende una serie de tablas de flujo, en el que cada una de las tablas de flujo comprende por lo menos un campo de correspondencia, en el que los campos de correspondencia corresponden a una serie de servicios de red, en el que los campos de correspondencia están ordenados en base a una priorización de los servicios de red, a cuáles de los campos de correspondencia son compartidos entre los servicios de red, a una dependencia compartida de los campos de correspondencia y a la velocidad de procesamiento, y en el que la priorización está basada en qué servicios de red son los más importantes y en qué servicios de red se utilizan más frecuentemente.
En otra realización, la invención incluye un aparato OpenFlow de trabajo en red definido por software (SDN) que comprende un procesador, y un sistema de memoria acoplado al procesador y que comprende un conducto de flujo, en el que el conducto de flujo comprende una serie de tablas de flujo numeradas de 0 a 11, en el que la tabla de flujo 0 y la tabla de flujo 1 están configuradas para implementar un servicio de lista de control de acceso (ACL, access control list), en el que la tabla de flujo 2 está configurada para implementar un servicio de localización de servicios, en el que la tabla de flujo 3 está configurada para implementar un servicio de envío de la capa dos, en el que la tabla de flujo 2, la tabla de flujo 3 y la tabla de flujo 4 están configuradas para implementar un servicio de red de área local virtual (VLAN, virtual local area network), en el que la tabla de flujo 2 y la tabla de flujo 5 están configuradas para implementar un servicio de conmutación por etiquetas multiprotocolo (MPLS, multiprotocol label switching), en el que la tabla de flujo 2, la tabla de flujo 6, la tabla de flujo 7 y la tabla de flujo 8 están configuradas para implementar un servicio de versión 4 de protocolo de internet (IPv4), en el que la tabla de flujo 2, la tabla de flujo 6, la tabla de flujo 9 y la tabla de flujo 10 están configuradas para implementar un servicio de protocolo de internet versión 6 (IPv6) y en el que la tabla de flujo 11 está configurada para implementar por lo menos un servicio adicional.
En otra realización más, la invención incluye un procedimiento relacionado con OpenFlow de trabajo en red definido por software (SDN), comprendiendo el procedimiento seleccionar una serie de servicios de red, priorizar los servicios de red en base a qué servicios de red son los más importantes y a qué servicios de red son los más frecuentemente
5
10
15
20
25
30
35
40
45
utilizados, determinar un campo de correspondencia correspondiente a cada uno de los servicios de red, y diseñar un conducto de flujo con una serie de tablas de flujo, en el que cada una de las tablas de flujo comprende por lo menos uno de los campos de correspondencia, y en el que los campos de correspondencia están ordenados en base a la priorización, a cuáles de los campos de correspondencia son compartidos entre los servicios de red, a la dependencia compartida de los campos de correspondencia y a la velocidad de procesamiento.
Estas y otras características se comprenderán más claramente a partir de la siguiente descripción detallada, tomada junto con los dibujos adjuntos y las reivindicaciones.
BREVE DESCRIPCIÓN DE LOS DIBUJOS
Para una comprensión más completa de esta invención, se hace referencia a continuación a la siguiente breve descripción, tomada en relación con los dibujos adjuntos y la descripción detallada, donde los numerales de referencia similares representan partes similares.
La figura 1 es un diagrama esquemático de una red definida por software, de acuerdo con una realización de la invención.
La figura 2 es un diagrama esquemático de un dispositivo de red, según una realización de la invención.
La figura 3 es un diagrama esquemático de un conducto de flujo generalizado.
La figura 4 es un diagrama esquemático de una realización de un conducto de flujo para implementar calidad de servicio (QoS, quality of service).
La figura 5 es un diagrama esquemático de una realización de un conducto de flujo para implementar QoS.
La figura 6 es un diagrama esquemático de una realización de un conducto de flujo para implementar encaminamiento y envío virtuales (VRF, routing and forwarding).
La figura 7 es un diagrama esquemático de una realización de un conducto de flujo para implementar un cortafuegos.
La figura 8 es un diagrama esquemático de una realización de un conducto de flujo para implementar conmutación por etiquetas multiprotocolo (MPLS).
La figura 9 es un diagrama de dependencias compartidas de campos de correspondencia.
La figura 10 es un diagrama esquemático de un conducto de flujo, según una realización de la invención.
La figura 11 es un diagrama esquemático que muestra conmutación y envío de la capa dos en el conducto de flujo de la figura 10.
La figura 12 es un diagrama esquemático que muestra conmutación y envío de la capa tres en el conducto de flujo de la figura 10.
La figura 13 es un diagrama esquemático de un conducto de flujo, según otra realización de la invención.
La figura 14 es un diagrama de flujo que muestra un procedimiento, según una realización de la invención. DESCRIPCIÓN DETALLADA
Para empezar se debe entender que, aunque a continuación se da a conocer una implementación ilustrativa de una o varias realizaciones, los sistemas y/o procedimientos dados a conocer se pueden implementar utilizando cualquier número de técnicas, ya sean actualmente conocidas o existentes. La invención no se deberá limitar en modo alguno a las implementaciones, dibujos y técnicas ilustrativas mostradas a continuación, incluyendo los diseños e implementaciones a modo de ejemplo mostrados y descritos en la presente memoria, sino que se puede modificar dentro del alcance de las reivindicaciones adjuntas junto con toda la gama de sus equivalentes.
Las redes pueden tener nodos con tablas de encaminamiento. Una tabla de encaminamiento puede comprender instrucciones de encaminamiento que instruyen a un nodo cómo encaminar datos a destinos de red. Los nodos de red basados en protocolo de internet (IP, Internet Protocol) tradicionales pueden tener tablas de encaminamiento relativamente grandes que comprenden muchas, posiblemente millones de instrucciones de encaminamiento. Cada una de las instrucciones de encaminamiento puede tener, por ejemplo, cinco atributos. Por lo tanto, la velocidad de entrega de los datos de dichos nodos puede ser relativamente más lenta debido a que la velocidad entrega de los datos puede depender estrechamente de la velocidad de búsqueda a través de las grandes tablas de encaminamiento. Además, dichas tablas de encaminamiento pueden estar implementadas en memoria ternaria de contenido direccionable (TCAM, ternary content-addressable memory), y la TCAM puede consumir relativamente más potencia, coste y espacio en comparación con otros tipos de memoria.
5
10
15
20
25
30
35
40
45
50
55
60
La especificación de conmutador OpenFlow, versión 1.0.0 (OpenFlow 1.0.0) adoptó una única tabla de encaminamiento, o de flujo, y por lo tanto heredó los problemas descritos anteriormente. Una tabla de flujo se puede definir como una tabla de encaminamiento utilizada para realizar un flujo de paquetes de datos. El flujo de paquetes puede comprender búsqueda, envío y modificación de paquetes. Un paquete se puede definir como una estructura de datos de Ethernet, IP u otra, que comprende una cabecera y una carga útil. Además, OpenFlow 1.0.0 proporciona entradas de flujo de 12 tuplas o 12 elementos. Las entradas de flujo pueden comprender datos para comparar con un paquete con estos, así como instrucciones para procesar el paquete en base al resultado de la comparación. Por lo tanto, la implementación puede requerir la duplicación de muchos atributos a través de las entradas de cinco- tuplas, agotando de ese modo el espacio de las tablas de flujo y los recursos de hardware. Además, OpenFlow 1.0.0 puede requerir la implementación de una capa de abstracción del hardware (HAL, hardware abstraction layer) compleja. Una HAL se puede definir como una capa de abstracción, lo que significa que permite al software funcionar perfectamente con diferentes tipos de hardware. Por consiguiente, aunque los controladores de OpenFlow 1.0.0 pueden proporcionar instrucciones de encaminamiento para nodos de manera centralizada, estas instrucciones de encaminamiento pueden seguir siendo ineficientes. Finalmente, OpenFlow 1.0.0 puede no aprovechar la capacidad de reconocer tipos de aplicación o de flujo, ni aprovechar otro potencial en una red SDN-OpenFlow.
En lugar de nodos que tienen una única tabla de flujo, la especificación de conmutador OpenFlow, versión 1.1.0 (OpenFlow 1.1.0), que se incorpora como referencia como si se reprodujera en su totalidad, introduce nodos que tienen conductos de flujo con múltiples tablas de flujo. Cada tabla de flujo comprende entradas de flujo, que comprenden campos de correspondencia. Un conducto de flujo se puede definir como un conjunto de tablas de flujo conectadas. Un campo de correspondencia se puede definir como un campo con el que se pone en correspondencia un paquete. Sin embargo, la introducción de conductos de flujo puede hacer más complejos el diseño y la implementación de los nodos. Por ejemplo, puede ser difícil separar servicios de red tales como QoS y encaminamiento. Asimismo, existe un desafío en diseñar conductos de flujo que utilicen de manera efectiva los recursos, tales como la memoria de acceso aleatorio (RAM, random access memory) y la TCAM, y que sean flexibles, fáciles de implementar y capaces de buscar rápidamente correspondencias. Para facilitar la adopción de OpenFlow para grandes redes, existe asimismo la necesidad de extender la abstracción de las tablas del núcleo y establecer conductos de flujo flexibles, pero optimizados, con múltiples tablas de flujo que proporcionen de manera efectiva lo siguiente: (1) encaminamiento de internet del núcleo con políticas QoS; (2) encaminamiento conducido por tipos de aplicación o características de flujo; (3) encaminamiento utilizando el hardware actual pero tablas TCAM relativamente menores; y (4) capacidades de conmutación de la capa dos y la capa tres. La capa dos se puede referir a la capa de enlace de datos en el modelo de interconexión de sistemas abiertos (OSI, Open Systems Interconnection). La capa tres se puede referir a la capa de red en el modelo OSI. A partir de OpenFlow 1.1.0, se han implementado las subsiguientes especificaciones de OpenFlow. La especificación de conmutador OpenFlow, versión 1.3.1 (OpenFlow 1.3.1), que se incorpora como referencia como si se reprodujera en su totalidad, es la especificación de OpenFlow más reciente. Se debe entender que aunque OpenFlow 1.3.1 es la especificación de OpenFlow más reciente, la técnica dada conocer no se limita a OpenFlow 1.3.1.
En la presente memoria se dan a conocer sistemas y procedimientos para un diseño mejorado de conducto de flujo en conmutadores basados en OpenFlow SDN y dispositivos similares. En general, la técnica dada a conocer se puede centrar en servicios de red clave, priorizar dichos servicios de red clave y seleccionar para las tablas de flujo una secuencia de campos de correspondencia que puede ser necesaria para proporcionar dichos servicios de red clave. Más específicamente, la técnica dada a conocer se puede centrar en optimizar el tiempo de procesamiento (búsqueda y puesta en correspondencia para campos de correspondencia) para servicios importantes y utilizados frecuentemente, tales como lista de control de acceso (ACL), envío de la capa dos, red de área local virtual (VLAN), MPLS y red de envío de la capa tres. Además, la técnica dada a conocer puede proporcionar campos de correspondencia adicionales para localizar diferentes tipos de servicio con el fin de acelerar el envío. Se puede utilizar una tabla de flujo final para incluir campos de correspondencia relacionados con otros servicios más. Por lo tanto, la técnica dada a conocer puede proporcionar encaminamiento basado en OpenFlow SDN con políticas QoS; encaminamiento conducido por tipos de aplicación o características de flujo; encaminamiento utilizando el hardware actual, pero con tablas TCAM relativamente más pequeñas; y capacidades de conmutación de la capa dos y la capa tres.
La figura 1 es un diagrama esquemático de una red definida por software 100, según una realización de la invención. La red 100 puede comprender un controlador 110, un canal 130, un nodo 140 y una serie de puntos extremos 160.
El controlador 110 puede ser cualquier dispositivo o proceso de comunicación capaz de comunicar con el nodo 140. Por ejemplo, el controlador 110 puede ser un servidor informático que pueda recibir instrucciones de un usuario por medio de una interfaz de usuario 120 y transmitir dichas instrucciones al nodo 140. El controlador 110 puede gestionar el nodo 140 por medio de OpenFlow.
El canal 130 puede ser cualquier canal que pueda proporcionar un trayecto de comunicación entre el controlador 110 y el nodo 140. Por ejemplo, el canal 130 puede ser un medio físico o una conexión lógica. El canal 130 puede ser un canal seguro y puede utilizar OpenFlow para facilitar la comunicación entre el controlador 110 y el nodo 140.
El nodo 140 puede ser cualquier dispositivo de comunicación capaz de comunicar con el controlador 110 y entre los puntos extremos 160. Por ejemplo, el nodo 640 puede ser un encaminador, un conmutador, un puente u otro
5
10
15
20
25
30
35
40
45
50
55
dispositivo similar. El nodo 140 puede recibir paquetes desde un punto extremo 160 y encaminar dichos paquetes a otro punto extremo 160 en base a instrucciones recibidas desde el controlador 110 e implementadas en un módulo de conducto de flujo (FPM, flow pipeline module) 150, que se describirá en mayor detalle a continuación.
Los puntos extremos 160 pueden ser cualesquiera dispositivos de comunicación capaces de comunicar con el nodo 140 y entre sí. Por ejemplo, los puntos extremos 160 pueden ser un teléfono móvil, un ordenador de tableta, un ordenador de sobremesa, un ordenador portátil u otro dispositivo similar.
La figura 2 es un diagrama esquemático de un dispositivo de red 200, según una realización de la invención. El dispositivo de red 200 puede comprender una serie de puertos de entrada 210 y/o unidades de receptor (Rx) 220 para datos, un procesador o unidad lógica 230 para procesar señales, una serie de puertos de salida 240 y/o unidades de transmisor (Tx) 250 para transmitir datos a otros componentes, y una memoria 260. El dispositivo de red 200 puede ser adecuado para implementar las características, procedimientos y dispositivos descritos en la presente memoria, incluyendo el nodo 140. Por ejemplo, si el dispositivo de red 200 está implementando el nodo 140, entonces los puertos de entrada 210 y los puertos de salida 240 pueden estar acoplados al canal 130 y a los puntos extremos 160. Además, el procesador 230 y/o la memoria 260 pueden comprender el FPM 150.
El procesador 230, que se puede denominar una unidad central de proceso (CPU, central processing unit), puede estar en comunicación con los puertos de entrada 210, las unidades de receptor 220, los puertos de salida 240, las unidades de transmisor 250 y la memoria 260. El procesador 230 puede estar implementado como uno o varios chips de CPU, núcleos (por ejemplo, un procesador multi-núcleo), matrices de puertas programables in situ (FPGA, field-programmable gate arrays), circuitos integrados de aplicación específica (ASIC, application specific integrated circuits) y/o procesadores de señal digital (DSP, digital signal processors) y/o puede formar parte de uno o varios ASIC.
La memoria 260 se puede componer de uno o varios discos, unidades de cinta o unidades de estado sólido; puede ser utilizada para almacenamiento no volátil de datos y como un dispositivo de almacenamiento de datos en desbordamiento; puede ser utilizada para almacenar programas cuando dichos programas son seleccionados para ejecución; y puede ser utilizada para almacenar instrucciones y quizás datos que se lean durante la ejecución del programa. La memoria 260 puede ser volátil y/o no volátil y puede ser memoria de sólo lectura (ROM, read only memory), RAM, TCAM, memoria estática de acceso aleatorio (SRAM, static random-access memory) o cualquier combinación de las mismas. La memoria 260 puede estar situada en un chip con los otros componentes del dispositivo de red 200 o situada en un chip independiente.
La figura 3 es un diagrama esquemático de un conducto de flujo generalizado 300. El conducto de flujo 300 es de OpenFlow 1.3.1. El conducto de flujo 300 puede ser implementado en el nodo 140 y, en particular, en el FPM 150. El conducto de flujo 300 puede comprender tablas de flujo numeradas de 0 a n, donde n es un entero igual o mayor que uno. Cada tabla puede comprender cualquier número de entradas de flujo. El controlador 110 puede añadir, actualizar y eliminar dichas entradas de flujo en cualquier momento. Las entradas de flujo pueden comprender seis atributos: campos de correspondencia, una prioridad, contadores, instrucciones, límites de tiempo y una cookie. Los campos de correspondencia se han definido anteriormente. La prioridad puede definir una precedencia de correspondencia de una entrada de flujo. Los contadores se pueden actualizar cuando se ponen en correspondencia paquetes. Las instrucciones informan al conducto de flujo 300 de cómo procesar un paquete si se produce una correspondencia. Los límites de tiempo se pueden referir a la cantidad máxima de tiempo que un paquete se puede encaminar a través del conducto de flujo 300 antes de expirar. Una cookie puede no utilizarse para paquetes de proceso, pero puede utilizarse para filtrar estadísticas de flujo y para modificación y eliminación. La técnica dada a conocer se puede centrar en campos de correspondencia de entradas de flujo, contadores e instrucciones.
Un paquete puede entrar en el conducto de flujo 300 por medio de un puerto de entrada. El puerto de entrada y cualesquiera puertos subsiguientes pueden ser puertos físicos o lógicos. El flujo de paquetes puede ser unidireccional, de tal modo que un paquete progresa secuencialmente de la tabla 0 a la tabla n. El paquete puede comenzar siempre en la tabla 0. En la tabla 0, el FPM 150 puede extraer del paquete una cabecera del paquete y comparar un valor de la cabecera con cada campo de correspondencia en cada entrada de flujo en la tabla 0. La comparación puede tener uno de tres resultados: el valor se corresponde con un campo de correspondencia, el valor se corresponde con más de un campo de correspondencia o el valor no se corresponde con ningún campo de correspondencia. Si el valor se corresponde con un campo de correspondencia, entonces el FPM 150 puede actualizar un contador de dicho campo de correspondencia, ejecutar instrucciones asociadas con dicho campo de correspondencia y enviar el paquete según dichas instrucciones. Por ejemplo, el FPM 150 puede enviar el paquete a la tabla 1. Si el valor se corresponde con más de un campo de correspondencia, el FPM 150 puede determinar qué campo de correspondencia tiene la máxima prioridad para la tabla 0, actualizar un contador del campo de correspondencia de máxima prioridad, ejecutar instrucciones asociadas con dicho campo de correspondencia y enviar el paquete según dichas instrucciones. Por ejemplo, el FPM 150 puede enviar el paquete a la tabla 1. Si el valor no se corresponde con ningún campo de correspondencia, el FPM 150 puede entonces enviar el paquete al controlador 110, desechar el paquete o enviar el paquete según una instrucción de inexistente en la tabla ("table- miss").
5
10
15
20
25
30
35
Las instrucciones pueden ordenar cambios en el paquete, un conjunto de acciones asociadas con el paquete, metadatos asociados con el paquete o cualquier combinación de los mismos. Los cambios en el paquete lo pueden ser en los datos incluidos en el propio paquete. El conjunto de acciones se puede definir como el conjunto de acciones de procesamiento aplicadas a un paquete cuando éste sale del conducto de flujo 300. Los metadatos se pueden definir como valores de registro que se pueden enmascarar, utilizados para llevar información de una tabla a la siguiente tabla. Para conseguir una correspondencia, el valor extraído de la cabecera tiene que ser exactamente igual que el campo de correspondencia. Alternativamente, una entrada de flujo puede comprender un campo de correspondencia comodín, que significa que el valor extraído de la cabecera se puede corresponder con el campo de correspondencia si el valor de la cabecera es cualquier valor. Además de buscar correspondencias en cabeceras de paquete, el FPM 150 puede buscar correspondencias en puertos de entrada, puertos de salida y campos de metadatos. El proceso de búsqueda de correspondencia se puede repetir en cada tabla hasta que el paquete sale de la tabla n y se ejecuta el conjunto de acción finalizada o hasta que el paquete se desecha o se envía al controlador 110 debido a una falta de correspondencia.
Las figuras 4 y 5 son diagramas esquemáticos de realizaciones de conductos de flujo para implementar QoS. Las figuras 6 a 8 son diagramas esquemáticos de realizaciones de conductos de flujo para implementar VRF, un cortafuegos y MPLS, respectivamente. Los conductos de flujo de las figuras 4 a 8 se han diseñado con múltiples tablas de flujo, pero dichos conductos de flujo están diseñados para servicios de red únicos.
Tal como se ha explicado anteriormente, un conducto de flujo se puede diseñar para proporcionar múltiples servicios de red seleccionando primero los servicios de red clave que se utilizan más frecuentemente. Dichos servicios de red pueden incluir ACL, envío de la capa dos, VLAN, MPLS y envío de la capa tres. En segundo lugar, se seleccionan los campos de correspondencia clave correspondientes a dichos servicios. Dichos campos de correspondencia pueden ser tal como se muestra en la tabla 1.
ACL
Envío de la capa dos
ETH TYPE
ETH SRC
IP SRC
ETH DST
IP DST
Metadatos
IP PROTO
DST PORT
VLAN ETH DST VLAN VID VLAN PCP Metadatos
IP PROTO Metadatos
MPLS
MPLSLABEL
MPLSTC
Metadatos
Envío de la capa tres IP SRC IP DST ETH TYPE IP TOS
Tabla 1: campos de correspondencia clave
Además, los campos de correspondencia ETH TYPE e IN PORT se pueden utilizar para localizar diferentes tipos de servicio con el fin de acelerar el envío de paquetes. En tercer lugar, algunos campos de correspondencia pueden requerir que se utilice asimismo otro campo de correspondencia. Dichos requisitos se pueden denominar dependencias compartidas y se muestran en la figura 9, que es un diagrama de dependencias compartidas de campos de correspondencia. A modo de ejemplo, tal como se muestra en la tabla 1, ACL tiene un campo de correspondencia IP PROTO. Tal como se muestra en la figura 9, para poner en correspondencia IP PROTo es necesario asimismo poner en correspondencia ETH TYPE. Volviendo a la tabla 1, ETH TYPE es otro campo de correspondencia para ACL, de tal modo que se satisface la dependencia de los campos de correspondencia en la tabla 1. En cuarto lugar, en base a la priorización de los servicios de red, a una determinación de qué campos de correspondencia tienen en común los servicios de red, y a las dependencias compartidas de los campos de correspondencia, se puede diseñar un conducto de flujo optimizado.
La priorización puede estar basada en qué servicios de red se utilizan más frecuentemente. Un controlador tal como el controlador 110, un nodo de red tal como el nodo 140, un administrador tal como administrador asociado con el
5
10
15
20
25
30
35
40
45
50
55
60
nodo 110 u otra entidad adecuada pueden llevar a cabo la priorización. El controlador, el nodo de red u otra entidad adecuada pueden analizar tráfico de datos, determinar qué servicios de red se utilizan más frecuentemente y priorizar en consecuencia los servicios de red. Por ejemplo, si hay 10 servicios de red disponibles, el controlador, el nodo de red u otra entidad adecuada pueden analizar el tráfico de datos, determinar los cinco primeros servicios de red disponibles en términos de frecuencia de utilización, y seleccionar dichos cinco primeros servicios de red disponibles. El controlador, el nodo de red u otra entidad adecuada pueden a continuación priorizar los cinco servicios de red disponibles por frecuencia de utilización.
Alternativamente, el administrador puede seleccionar y priorizar servicios de red arbitrariamente, en base a su conocimiento, o en base a por lo menos un criterio que le es conocido.
En la tabla 1, el campo de correspondencia ETH TYPE puede describir un tipo de trama Ethernet. El campo de correspondencia IP SRC puede corresponder al campo de correspondencia IPV4 SRC, que puede describir una dirección de origen IPv4, o bien al campo de correspondencia IPV6 SRC, que puede describir una dirección de origen IPv6. El campo de correspondencia IP DST puede corresponder al campo de correspondencia IPV4 DST, que puede describir una dirección de destino IPv4, o bien al campo de correspondencia IPV6 DST, que puede describir una dirección de destino IPv6. El campo de correspondencia IP PROTO puede describir un número de protocolo IPv4 o IPv6. El campo de correspondencia DST PORt puede corresponder al campo de correspondencia TCP DST, que puede describir el puerto de destino del protocolo de control de transmisión (TCP, transmission control protocol), o bien al campo de correspondencia UDP DST, que puede describir el puerto de destino del protocolo de datagramas de usuario (UDP, user datagram protocol). El campo de correspondencia ETH SRC puede describir una dirección de origen de Ethernet. El campo de correspondencia ETH DST puede describir una dirección de destino de Ethernet. El campo de correspondencia de metadatos puede describir metadatos, que se han definido anteriormente. El campo de correspondencia VLAN VID puede describir la identificación (ID) VLAN. El campo de correspondencia VLAN PCP puede describir una prioridad VLAN. El campo de correspondencia MPLS LABEL puede describir una etiqueta MPLS. El campo de correspondencia MPLS TC puede describir una clase de tráfico (TC, traffic class) MPLS. El campo de correspondencia IP TOS puede corresponder al campo de correspondencia IP DSCP, que puede describir un tipo de servicio (TOS, type of service) IP en seis bits, o bien al campo de correspondencia IP ECN, que puede describir un IP TOS en dos bits. Finalmente, el campo de correspondencia IN PORT puede describir un puerto de entrada de conmutación.
Es importante señalar que, aunque no se muestran, los campos de correspondencia dados a conocer pueden comprender prefijos y otras notaciones, tales como las mostradas en la página 49 de OpenFlow 1.3.1. Por ejemplo, el campo de correspondencia ETH TYPE se puede describir en OpenFlow 1.3.1 como OFPXMT_OFB_ETH TYPE. Aunque las denominaciones de campo de correspondencia pueden cambiar a través de diferentes versiones de OpenFlow, los propósitos de los campos de correspondencia se mantienen idénticos en general.
La figura 10 es un diagrama esquemático de un conducto de flujo 1000, según una realización de la invención. El conducto de flujo 1000 puede estar diseñado en base a la técnica anterior, y puede estar implementado en el nodo 640, y en particular, el FPM 650. Las tablas 0/1 pueden implementar ACL; la tabla 2 puede implementar localización de servicios; la tabla 3 puede implementar envío de la capa dos; las tablas 2 a 4 pueden implementar VLAN; las tablas 2 y 5 pueden implementar MPLS; las tablas 2, 6 y 7/8 pueden implementar envío IPv4 ((capa tres); las tablas 2, 6 y 9/10 pueden implementar envío IPv6 (capa tres); y la tabla 11 puede incluir todos los campos de correspondencia restantes para implementar cualesquiera servicios restantes. La denotación de las tablas 0/1 puede indicar que la tabla 0 y la tabla 1 comprenden los mismos campos de correspondencia; sin embargo, la tabla 0 puede ser una tabla de correspondencia exacta mientras que la tabla 1 puede ser una tabla de correspondencia comodín. Las denotaciones de las tablas 7/8 y las tablas 9/10 pueden indicar la misma relación de correspondencia exacta y correspondencia comodín. Cada tabla de correspondencia exacta puede estar almacenada y ser consultada en SRAM mientras que cada tabla de correspondencia comodín puede estar almacenada y ser consultada en TCAM. Esta relación puede reducir la utilización de TCAM, que de lo contrario sería necesaria para implementar el conducto de flujo 1000. Además de tener un bit 0 y un bit 1 para poner o no en correspondencia un campo, TCAM puede tener un tercer bit prescindible ("do-not-care") que puede ser adecuado para correspondencia comodín. La correspondencia exacta y la correspondencia comodín se pueden producir secuencial o simultáneamente. Por ejemplo, la tabla 0 puede en primer lugar realizar una búsqueda de correspondencia y puede estar seguida por la tabla 1, o las tablas 0 y 1 pueden llevar a cabo búsqueda de correspondencia al mismo tiempo. Si existe una correspondencia exacta y una correspondencia comodín, la correspondencia exacta puede tener prioridad. El conducto de flujo 1000 puede soportar servicios de red clave, así como conmutación y envío rápidos. Por ejemplo, algunos servicios pueden no requerir poner en correspondencia cada tabla, sino que pueden saltarse tablas en el conducto de flujo 1000. Las siguientes figuras proporcionan ejemplos de este tipo. Además, puede haber tablas de grupos asociadas. Las tablas de grupos pueden comprender conjuntos de acciones para desbordamiento, pueden permitir un envío más complejo y pueden permitir enviar múltiples entradas de flujo a un único identificador. Finalmente, el conducto de flujo 1000 se puede extender dinámicamente a otros campos de correspondencia utilizados con menor frecuencia y proporcionar soporte para futuras entradas de flujo utilizando la tabla 11.
La figura 11 es un diagrama esquemático que muestra conmutación y envío de la capa dos en el conducto de flujo 1000 de la figura 10. Un paquete puede comenzar en las tablas 0/1 para correspondencia de ACL. Si el paquete se corresponde, se puede entonces ordenar que el paquete salte a la tabla 2. Si el paquete no se corresponde, el
paquete puede entonces ser enviado al controlador 610, desechado o enviado según una instrucción de inexistente en la tabla. En la tabla 2, si el paquete se corresponde, puede entonces ordenarse que el paquete salte a la tabla 3. Si el paquete no se corresponde, el paquete puede entonces enviarse a la tabla 3, según una instrucción de inexistente en la tabla. En la tabla 3, si el paquete se corresponde, se puede entonces ordenar que el paquete salte 5 al puerto correspondiente del nodo 640 y puede comenzar el proceso de envío de datos. Si el paquete no se corresponde, el paquete puede entonces enviarse al controlador 610 o desecharse.
La figura 12 es un diagrama esquemático que muestra la conmutación y envío de la capa 3, en el conducto de flujo 1000 de la figura 10. Un paquete puede comenzar en las tablas 0/1 para correspondencia ACL. Si el paquete se corresponde, se puede entonces ordenar que el paquete salte a la tabla 2. Si el paquete no se corresponde, el 10 paquete puede entonces ser enviado al controlador 610, desechado o enviado según una instrucción de inexistente en la tabla. En la tabla 2, si el paquete se corresponde, puede entonces ordenarse que el paquete salte a la tabla 6. Por ejemplo, si el paquete tiene ETH TYPE = 0x0806 e IN PORT = 10, entonces se puede ordenar que el paquete salte a la tabla 6. Si el paquete no se corresponde, el paquete puede entonces ser enviado al controlador 610, desechado o enviado según una instrucción de inexistente en la tabla. En la tabla 6, se determina qué tipo de envío 15 de la capa tres puede ser apropiado. Si el paquete se corresponde con IPv4, se puede ordenar entonces que el paquete salte a las tablas 7/8. Si el paquete se corresponde con IPv6, se puede ordenar entonces que el paquete salte a las tablas 9/10. Si el paquete no se corresponde, el paquete puede entonces enviarse al controlador 610 o desecharse. En la tabla 9/10, si el paquete se corresponde, se puede entonces ordenar que el paquete salte al puerto correspondiente del nodo 640 y puede comenzar el proceso de envío de datos. Si el paquete no se 20 corresponde, el paquete puede entonces enviarse al controlador 610 o desecharse.
En base a la definición de las múltiples tablas de flujo, las tablas 0 y 1 se pueden extender de acuerdo con algunos requisitos específicos. Una extensión de este tipo que se centra en envío de la capa tres puede comprender los campos de correspondencia mostrados en la tabla 2 e implementados en la figura 13.
Tabla 0:
Tabla 1: Tabla 2:
ETHTYPE
IPV4 SRC IPV4 SRC
IP PROTO
IPV4 DST IPV4 DST
(Correspondencia exacta)
TCP SRC TCP SRC
TCP DST TCP DST
(Correspondencia exacta) (Correspondencia comodín)
Tabla 3:
Tabla 4: Tabla 5:
IPV4 SRC
IPV4 SRC
IPV6 SRC
IPV4 DST
IPV4 DST
IPV6 DST
UDP SRC
UDP SRC
TCP SRC
UDP DST
UDP DST
TCP DST
(Correspondencia exacta)
(Correspondencia comodín)
(Correspondencia exacta)
Tabla 6:
Tabla 7: Tabla 8:
IPV6 SRC
IPV6 SRC
IPV6 SRC
IPV6 DST
IPV6 DST
IPV6 DST
TCP SRC
UDP SRC UDP SRC
TCP DST
UDP DST UDP DST
(Correspondencia comodín)
(Correspondencia exacta)
(Correspondencia comodín)
Tabla 2: diseño de tablas de flujo extendidas
5
10
15
20
25
30
Igual que para las figuras 10 a 12, la denotación en la figura 13 de las tablas 1/2, 3/4, 5/6 y 7/8 puede indicar que las tablas 1, 3, 5 y 7 pueden ser tablas de correspondencia exacta mientras que las tablas 2, 4, 6 y 8 pueden ser tablas de correspondencia comodín.
En la tabla 2 pueden seguir aplicando las descripciones de campos de correspondencia para la tabla 1. Además, el campo de correspondencia TCP SRC puede describir el puerto de origen TCP. El campo de correspondencia UDP SRC puede describir el puerto de origen UDP.
La figura 14 es un diagrama de flujo que muestra un procedimiento 1400, según una realización de la invención. El procedimiento 1400 se puede implementar en el nodo 140, por ejemplo, en el FPM 150. En la etapa 1410, se pueden seleccionar una serie de servicios de red. En la etapa 1420, los servicios de red se pueden priorizar en base a qué servicios de red son los más importantes y a qué servicios de red son los utilizados más frecuentemente. En la etapa 1430, se puede determinar un campo de correspondencia correspondiente a cada uno de los servicios de red. En la etapa 1440, se puede diseñar un conducto de flujo con una serie de tablas de flujo. Cada una de las tablas de flujo puede comprender por lo menos uno de los campos de correspondencia, y los campos de correspondencia pueden estar ordenados en base a la priorización, a cuáles de los campos de correspondencia son compartidos entre los servicios de red, a una dependencia compartida de los campos de correspondencia y a la velocidad de procesamiento.
Aunque en la presente invención se han dado conocer varias realizaciones, se debe entender que los sistemas y procedimientos se pueden realizar de muchas otras formas específicas sin apartarse del alcance de la presente invención. Los presentes ejemplos se deben considerar como ilustrativos y no limitativos, y no se pretende limitarse a los detalles proporcionados en la presente memoria. Por ejemplo, los diversos elementos o componentes se pueden combinar o integrar en otro sistema, o determinadas características pueden ser omitidas, o no implementarse.
Además, las técnicas, sistemas, subsistemas y procedimientos descritos y mostrados en las diversas realizaciones como separados o independientes, se pueden combinar o integrar con otros sistemas, módulos, técnicas u procedimientos sin apartarse del alcance de la presente invención. Otros elementos mostrados o descritos como acoplados, o acoplados directamente o comunicando entre sí, pueden estar acoplados indirectamente o comunicando a través de alguna interfaz, dispositivo o componente intermedio ya sea eléctrica, mecánicamente o de otro modo. Los expertos en la materia pueden ser capaces de determinar otros ejemplos de cambios, sustituciones y modificaciones, y estos se pueden realizar sin apartarse del alcance dado a conocer en la presente memoria.

Claims (22)

  1. 5
    10
    15
    20
    25
    30
    35
    40
    45
    50
    55
    REIVINDICACIONES
    1. Un aparato (200), que comprende:
    un receptor configurado para recibir instrucciones;
    un sistema de memoria (260) acoplado al receptor y configurado para almacenar las instrucciones; caracterizado por que el aparato comprende además:
    un procesador (230) acoplado al sistema de memoria y configurado para ejecutar las instrucciones con el fin de provocar que el aparato:
    implemente un conducto de flujo (300), en el que el conducto de flujo comprende una serie de tablas de flujo, en el que las tablas de flujo comprenden campos de correspondencia, en el que los campos de correspondencia se ordenan en base a una priorización de servicios de red y a dependencias compartidas de campos de correspondencia, en el que las dependencias compartidas presentadas de correspondencia son requisitos requeridos por algunos de los campos de correspondencia para utilizar otro campo de correspondencia, y
    encamine un paquete utilizando el conducto de flujo.
  2. 2. El aparato según la reivindicación 1, en el que los servicios de red comprenden un servicio de lista de control de acceso, ACL, un servicio de envío de la capa dos, un servicio de red de área local virtual, VLAN, un servicio de conmutación por etiquetas multiprotocolo, MPLS, un servicio de envío de la capa tres y un servicio de localización de servicios.
  3. 3. El aparato según la reivindicación 2, en el que el servicio de envío de la capa tres comprende un servicio de protocolo de internet versión 4, IPv4, y un servicio de protocolo de internet versión 6, IPv6.
  4. 4. El aparato según la reivindicación 3, en el que las tablas de flujo están numeradas de 0 a 11, en el que la tabla de flujo 0 y la tabla de flujo 1 hacen que el procesador implemente el servicio ACL, en el que la tabla de flujo 2 hace que el procesador implemente el servicio de localización de servicios, en el que la tabla de flujo 3 hace que el procesador implemente el servicio de envío de la capa dos, en el que la tabla de flujo 2, la tabla de flujo 3 y la tabla de flujo 4 hacen que el procesador implemente el servicio VLAN, en el que la tabla de flujo 2 y la tabla de flujo 5 hacen que el procesador implemente el servicio MPLS, en el que la tabla de flujo 2, la tabla de flujo 6, la tabla de flujo 7 y la tabla de flujo 8 hacen que el procesador implemente el servicio IPv4, en el que la tabla de flujo 2, la tabla de flujo 6, la tabla de flujo 9 y la tabla de flujo 10 hacen que el procesador implemente el servicio IPv6 y en el que la tabla de flujo 11 hace que el procesador implemente por lo menos un servicio adicional.
  5. 5. El aparato según la reivindicación 4, en el que la tabla 0, la tabla 7 y la tabla 9 son tablas de correspondencia exacta, y en el que la tabla 1, la tabla 8 y la tabla 10 son tablas de correspondencia comodín.
  6. 6. El aparato según la reivindicación 4, en el que la tabla de flujo 0 y la tabla de flujo 1 comprenden cada una campos de correspondencia ETH TYPE, IP SRC, IP DST, IP PROTO y DST PORT, en el que la tabla de flujo 2 comprende campos de correspondencia ETH TYPE e IN PORT, en el que la tabla de flujo 3 comprende campos de correspondencia ETH SRC, ETH DST y de metadatos, en el que la tabla de flujo 4 comprende campos de correspondencia VLAN VID, VLAN PCP y de metadatos, en el que la tabla de flujo 5 comprende campos de correspondencia MPLS LABEL, MPLS TC y de metadatos, en el que la tabla de flujo 6 comprende campos de correspondencia IP TOS, IP PROTO y de metadatos, en el que la tabla de flujo 7 y la tabla de flujo 8 comprenden cada una campos de correspondencia IPV4 SRC, IPV4 DST y de metadatos, en el que la tabla de flujo 9 y la tabla de flujo 10 comprenden cada una campos de correspondencia IPV6 SRC, IPV6 DST y de metadatos, en el que la tabla de flujo 11 comprende campos de correspondencia adicionales y en el que el campo de correspondencia ETH TYPE describe un tipo de trama de Ethernet, el campo de correspondencia IP SRC describe una dirección de origen de protocolo de internet, IP, el campo de correspondencia IP DST describe una dirección de destino IP, el campo de correspondencia IP PROTO describe un número de protocolo IPv4 o IPv6, el campo de correspondencia DST PORT describe un puerto de destino, el campo de correspondencia IN PORT describe un puerto de entrada de conmutación, el campo de correspondencia ETH SRC describe una dirección de origen de Ethernet, el campo de correspondencia ETH DST describe una dirección de destino de Ethernet, el campo de correspondencia de metadatos describe metadatos, el campo de correspondencia VLAN VID describe una identificación, ID, de VLAN, el campo de correspondencia VLAN PCP describe una prioridad VLAN, el campo de correspondencia MPLS LABEL describe una etiqueta MPLS, el campo de correspondencia MPLS TC describe una clase de tráfico, TC, MPLS, el campo de correspondencia IP TOS describe un tipo de servicio, TOS, IP, el campo de correspondencia IPV4 SRC describe una dirección de origen IPv4, el campo de correspondencia IPV4 DST describe una dirección de destino IPv4, el campo de correspondencia IPV6 SRC describe una dirección de origen IPv6 y el campo de correspondencia IPV6 DST describe una dirección de destino IPV6.
  7. 7. El aparato según la reivindicación 6, en el que los campos de correspondencia adicionales comprenden todos los campos de correspondencia restantes.
    5
    10
    15
    20
    25
    30
    35
    40
    45
    50
  8. 8. El aparato según la reivindicación 1, en el que el sistema de memoria comprende memoria estática de acceso aleatorio, SRAM, para implementar una correspondencia exacta de los campos de correspondencia, y memoria ternaria de contenido direccionable, TCAM, para implementar correspondencia comodín de los campos de correspondencia.
  9. 9. El aparato según la reivindicación 1, en el que las tablas de flujo están numeradas de 0 a 8, en el que la tabla de flujo 0 comprende campos de correspondencia ETH TYPE e IP PROTO, en el que la tabla de flujo 1 y la tabla de flujo 2 comprenden cada una campos de correspondencia IPV4 SRC, IPV4 DST, TCP SRC y TCP DST, en el que la tabla de flujo 3 y la tabla de flujo 4 comprenden cada una campos de correspondencia IPV4 SRC, IPV4 DST, UDP SRC y UDP DST, en el que la tabla de flujo 5 y la tabla de flujo 6 comprenden cada una campos de correspondencia IPV6 SRC, IPV6 DST, TCP SRC y TCP DsT, en el que la tabla de flujo 7 y la tabla de flujo 8 comprenden cada una campos de correspondencia IPV6 SRC, IPV6 DST, UDP SRC y UDP DST y en el que el campo de correspondencia ETH TYPE describe un tipo de trama de Ethernet, el campo de correspondencia IP PROTO describe un número de protocolo IPv4 o IPv6, el campo de correspondencia IPV4 SRC describe una dirección de origen IPv4, el campo de correspondencia IPV4 DST describe una dirección de destino IPv4, el campo de correspondencia TCP SRC describe un puerto de origen del protocolo de control de transmisión, TCP, el campo de correspondencia DST TCP PORT describe un puerto de destino TCP, el UDP SRC describe un puerto de origen del protocolo de datagramas de usuario, UDP, el UDP DST describe un puerto de destino UDP, el campo de correspondencia IPV6 SRC describe una dirección de origen IPv6, y el campo de correspondencia IPV6 DST describe una dirección de destino IPv6.
  10. 10. El aparato según la reivindicación 9, en el que la tabla de flujo 0, la tabla de flujo 1, la tabla de flujo 3, la tabla de flujo 5 y la tabla de flujo 7 son tablas de flujo de correspondencia exacta, y en el que la tabla de flujo 2, la tabla de flujo 4, la tabla de flujo 6 y la tabla de flujo 8 son tablas de flujo de correspondencia comodín.
  11. 11. Un procedimiento relacionado con OpenFlow de trabajo en red definido por software, SDN, comprendiendo el procedimiento:
    seleccionar 1410 servicios de red; priorizar 1420 los servicios de red;
    determinar 1430 campos de correspondencia correspondientes a los servicios de red; y
    diseñar 1440 un conducto de flujo con una serie de tablas de flujo, en el que cada una de las tablas de flujo comprende por lo menos uno de los campos de correspondencia, y en el que los campos de correspondencia se ordenan en base a la priorización y a las dependencias compartidas de campos de correspondencia, en el que las dependencias compartidas presentadas de correspondencia son requisitos requeridos por algunos de los campos de correspondencia para utilizar otro campo de correspondencia.
  12. 12. El procedimiento según la reivindicación 11, que comprende además enviar instrucciones para implementar el conducto de flujo y para encaminar paquetes utilizando el conducto de flujo.
  13. 13. El procedimiento según la reivindicación 11, en el que la priorización se basa en cuáles son los servicios de red utilizados con mayor frecuencia.
  14. 14. El procedimiento según la reivindicación 11, en el que las tablas de flujo están numeradas de 0 a 11, en el que la tabla de flujo 0 y la tabla de flujo 1 implementan un servicio de lista de control de acceso, ACL, en el que la tabla de flujo 2 implementa un servicio de localización de servicios, en el que la tabla de flujo 3 implementa un servicio de envío de la capa dos y en el que la tabla de flujo 2, la tabla de flujo 3 y la tabla de flujo 4 implementan un servicio de red de área local virtual, VLAN, en el que la tabla de flujo 2 y la tabla de flujo 5 implementan un servicio de conmutación por etiquetas multiprotocolo, MPLS, en el que la tabla de flujo 2, la tabla de flujo 6, la tabla de flujo 7 y la tabla de flujo 8 implementan un servicio de protocolo de internet versión 4, IPv4, en el que la tabla de flujo 2, la tabla de flujo 6, la tabla de flujo 9 y la tabla de flujo 10 implementan un servicio de protocolo de internet versión 6, IPv6, y en el que la tabla de flujo 11 implementa por lo menos un servicio adicional.
  15. 15. El procedimiento según la reivindicación 11, en el que seleccionar servicios de red comprende seleccionar los servicios de red clave que se utilizan más frecuentemente.
  16. 16. El procedimiento según la reivindicación 15, en el que una tabla de flujo final de la serie de tablas de flujo incluye campos de correspondencia relacionados con otros servicios que no son los servicios de red clave.
  17. 17. El procedimiento según la reivindicación 11, en el que cada una de las tablas de flujo comprende cualquier número de entradas de flujo, cada una de las entradas de flujo comprende los campos de correspondencia, una prioridad, contadores, instrucciones y una cookie.
  18. 18. El procedimiento según la reivindicación 17, que comprende además añadir, actualizar o eliminar las entradas de flujo.
  19. 19. Un aparato (110), que comprende:
    un primer procesador configurado para crear instrucciones con el fin de implementar un conducto de flujo (300), en el que el conducto de flujo comprende una serie de tablas de flujo, en el que las tablas de flujo comprenden campos de correspondencia, en el que los campos de correspondencia se ordenan en base a una priorización de servicios de red y a dependencias compartidas de campos de correspondencia, en el que las dependencias compartidas 5 presentadas de correspondencia son requisitos requeridos por algunos campos de correspondencia para utilizar otro campo de correspondencia;
    una memoria acoplada al primer procesador y configurada para almacenar las instrucciones; y un transmisor acoplado a la memoria y configurado para transmitir las instrucciones.
  20. 20. El aparato según la reivindicación 19, en el que la priorización está basada en qué servicios de red son los 10 utilizados más frecuentemente.
  21. 21. El aparato según la reivindicación 19, en el que los servicios de red comprenden un servicio de lista de control de acceso, ACL, un servicio de envío de la capa dos, un servicio de red de área local virtual, VLAN, un servicio de conmutación por etiquetas multiprotocolo, MPLS, un servicio de envío de la capa tres y un servicio de localización de servicios.
    15 22. El aparato según la reivindicación 21, en el que para algunos de los servicios de red no se requiere se
    correspondan con cada una de las tablas de flujo en el conducto de flujo.
  22. 23. El aparato según la reivindicación 19, el primer procesador está configurado además para seleccionar un servicio de red, priorizar el servicio de red y determinar los campos de correspondencia correspondientes a los servicios de red, y diseñar el conducto de flujo con la serie de tablas de flujo que comprenden el campo de correspondencia.
    20
ES13857704.4T 2012-11-29 2013-11-29 Priorización de paquetes en una red definida por software que implementa OpenFlow Active ES2664075T3 (es)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201261731389P 2012-11-29 2012-11-29
US201261731389P 2012-11-29
US201314089295 2013-11-25
US14/089,295 US9923831B2 (en) 2012-11-29 2013-11-25 Packet prioritization in a software-defined network implementing OpenFlow
PCT/CN2013/088108 WO2014082590A1 (en) 2012-11-29 2013-11-29 Packet prioritization in a software-defined network implementing openflow

Publications (1)

Publication Number Publication Date
ES2664075T3 true ES2664075T3 (es) 2018-04-18

Family

ID=50773206

Family Applications (2)

Application Number Title Priority Date Filing Date
ES13857704.4T Active ES2664075T3 (es) 2012-11-29 2013-11-29 Priorización de paquetes en una red definida por software que implementa OpenFlow
ES17196071T Active ES2757916T3 (es) 2012-11-29 2013-11-29 Priorización de paquetes en una red definida por software que implementa OpenFlow

Family Applications After (1)

Application Number Title Priority Date Filing Date
ES17196071T Active ES2757916T3 (es) 2012-11-29 2013-11-29 Priorización de paquetes en una red definida por software que implementa OpenFlow

Country Status (5)

Country Link
US (1) US9923831B2 (es)
EP (2) EP2926513B1 (es)
CN (2) CN104823416B (es)
ES (2) ES2664075T3 (es)
WO (1) WO2014082590A1 (es)

Families Citing this family (42)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8982727B2 (en) * 2012-10-22 2015-03-17 Futurewei Technologies, Inc. System and apparatus of generalized network controller for a software defined network (SDN)
US9906445B2 (en) 2013-02-01 2018-02-27 Texas Instruments Incorporated Packet processing match and action pipeline structure with dependency calculation removing false dependencies
US9172604B1 (en) * 2013-02-25 2015-10-27 Google Inc. Target mapping and implementation of abstract device model
US9166912B2 (en) 2013-02-25 2015-10-20 Google Inc. Translating network forwarding plane models into target implementation using sub models and hints
US9515872B2 (en) * 2013-03-12 2016-12-06 Dell Products L.P. Systems and methods for tunnel-free fast rerouting in internet protocol networks
US9755963B2 (en) 2013-07-09 2017-09-05 Nicira, Inc. Using headerspace analysis to identify flow entry reachability
US9426060B2 (en) * 2013-08-07 2016-08-23 International Business Machines Corporation Software defined network (SDN) switch clusters having layer-3 distributed router functionality
US9577924B2 (en) * 2013-11-14 2017-02-21 Electronics And Telecommunications Research Institute SDN-based network device with extended function and method of processing packet in the same device
US10257091B2 (en) * 2014-04-08 2019-04-09 Hewlett Packard Enterprise Development Lp Pipeline table identification
EP3148129A4 (en) 2014-06-26 2017-08-16 Huawei Technologies Co., Ltd. Method and device for controlling quality of service of software defined network
CN104104561B (zh) * 2014-08-11 2017-09-22 武汉大学 一种基于OpenFlow协议的SDN防火墙状态检测方法及系统
CN105556916B (zh) * 2014-08-25 2019-03-08 华为技术有限公司 网络流的信息统计方法和装置
WO2016032552A1 (en) * 2014-08-28 2016-03-03 Hewlett Packard Enterprise Development Lp Network compatibility determination based on flow requirements of an application and stored flow capabilities of a software-defined network
US9917769B2 (en) * 2014-11-17 2018-03-13 Telefonaktiebolaget Lm Ericsson (Publ) Method and system for virtualizing flow tables in a software-defined networking (SDN) system
CN105827425B (zh) * 2015-01-08 2020-07-24 华为技术有限公司 一种网络控制的方法及装置
US9667440B2 (en) 2015-02-10 2017-05-30 Alcatel Lucent Method and system for identifying an incoming interface using openflow protocol
US9660904B2 (en) * 2015-02-10 2017-05-23 Alcatel Lucent Method and system for inserting an openflow flow entry into a flow table using openflow protocol
US9686137B2 (en) 2015-02-10 2017-06-20 Alcatel Lucent Method and system for identifying an outgoing interface using openflow protocol
US9660903B2 (en) 2015-02-10 2017-05-23 Alcatel Lucent Method and system for inserting an openflow flow entry into a flow table using openflow protocol
WO2016153478A1 (en) * 2015-03-23 2016-09-29 Hewlett Packard Enterprise Development Lp Implementing policy instructions in multiple tables
US10044676B2 (en) 2015-04-03 2018-08-07 Nicira, Inc. Using headerspace analysis to identify unneeded distributed firewall rules
WO2016175768A1 (en) 2015-04-28 2016-11-03 Hewlett Packard Enterprise Development Lp Map tables for hardware tables
US9674081B1 (en) * 2015-05-06 2017-06-06 Xilinx, Inc. Efficient mapping of table pipelines for software-defined networking (SDN) data plane
US10554694B2 (en) 2015-07-20 2020-02-04 At&T Intellectual Property I, L.P. System and method for using software defined networking in internet protocol multimedia subsystems
WO2017018989A1 (en) * 2015-07-24 2017-02-02 Hewlett Packard Enterprise Development Lp Simultaneous processing of flow tables
CN106385365B (zh) * 2015-08-07 2019-09-06 新华三技术有限公司 基于开放流Openflow表实现云平台安全的方法和装置
CN106559338A (zh) * 2015-09-29 2017-04-05 中国电信股份有限公司 Sdn网络中的租户划分方法、装置及sdn网络系统
WO2017124330A1 (en) * 2016-01-20 2017-07-27 Telefonaktiebolaget Lm Ericsson (Publ) Advertising network resource sharing status in sdn
US20170359259A1 (en) * 2016-06-09 2017-12-14 Hewlett Packard Enterprise Development Lp Packet field matching in openflow
US10805238B1 (en) 2016-09-23 2020-10-13 Amazon Technologies, Inc. Management of alternative resources
US10666569B1 (en) * 2016-09-23 2020-05-26 Amazon Technologies, Inc. Journal service with named clients
US10911317B2 (en) * 2016-10-21 2021-02-02 Forward Networks, Inc. Systems and methods for scalable network modeling
CN106301970A (zh) * 2016-10-27 2017-01-04 盛科网络（苏州）有限公司 一种使用转发表收敛以减少tcam表项消耗的芯片实现方法
CN108011823B (zh) * 2016-11-01 2021-11-19 中兴通讯股份有限公司 多域流表的多级化方法及装置、多级流表查找方法及装置
CN106453138B (zh) * 2016-11-25 2020-03-06 新华三技术有限公司 一种报文处理方法和装置
TWI626837B (zh) 2016-12-01 2018-06-11 財團法人工業技術研究院 封包傳遞方法、封包傳遞裝置及非暫態電腦可讀取媒體
CN107070693B (zh) * 2017-01-12 2019-10-11 烽火通信科技股份有限公司 基于OpenFlow流表的快速配置POTN业务的方法及装置
US10587479B2 (en) 2017-04-02 2020-03-10 Nicira, Inc. GUI for analysis of logical network modifications
WO2018220638A1 (en) * 2017-06-01 2018-12-06 Telefonaktiebolaget Lm Ericsson (Publ) Optimizing service node monitoring in sdn
WO2019061521A1 (zh) * 2017-09-30 2019-04-04 深圳前海达闼云端智能科技有限公司 一种代理转发方法和装置、代理服务器和多级代理网络
CN109600318B (zh) * 2018-11-29 2022-07-12 新华三技术有限公司合肥分公司 一种监控sdn中应用程序的方法及sdn控制器
US11252096B2 (en) 2019-06-20 2022-02-15 Microsoft Technology Licensing, Llc Network flow state management for connectionless protocol(s)

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7649879B2 (en) * 2004-03-30 2010-01-19 Extreme Networks, Inc. Pipelined packet processor
US20060041668A1 (en) * 2004-08-19 2006-02-23 International Business Machines Corporation Method and system to automatically define resources forming an it service
CN101175025B (zh) * 2006-10-30 2011-08-03 华为技术有限公司 支持混合转发报文的系统、交换机及方法
US8542588B2 (en) * 2008-06-25 2013-09-24 Qualcomm Incorporated Invoking different wireless link rate selection operations for different traffic classes
JP5408243B2 (ja) * 2009-03-09 2014-02-05 日本電気株式会社 ＯｐｅｎＦｌｏｗ通信システムおよびＯｐｅｎＦｌｏｗ通信方法
CN101789995A (zh) 2009-12-31 2010-07-28 优视科技有限公司 一种移动通讯设备的网页浏览器的书签管理系统
ES2523038T3 (es) * 2010-01-05 2014-11-20 Nec Corporation Sistema de red y método de redundancia de red
JP5534437B2 (ja) * 2010-07-28 2014-07-02 信越ポリマー株式会社 入力装置
EP2615781B1 (en) 2010-09-08 2017-06-14 Nec Corporation Switching system, switching control method, and memory medium
US9001827B2 (en) * 2010-12-17 2015-04-07 Big Switch Networks, Inc. Methods for configuring network switches
CN102685006A (zh) 2012-05-03 2012-09-19 中兴通讯股份有限公司 一种转发数据报文的方法及装置
GB201215279D0 (en) * 2012-08-28 2012-10-10 Microsoft Corp Downloading content

Also Published As

Publication number Publication date
EP3300320A1 (en) 2018-03-28
EP2926513A1 (en) 2015-10-07
US9923831B2 (en) 2018-03-20
EP2926513B1 (en) 2018-01-10
CN104823416A (zh) 2015-08-05
CN108809830B (zh) 2021-09-14
US20140146674A1 (en) 2014-05-29
ES2757916T3 (es) 2020-04-30
CN104823416B (zh) 2018-07-13
WO2014082590A1 (en) 2014-06-05
EP2926513A4 (en) 2015-11-11
EP3300320B1 (en) 2019-09-04
CN108809830A (zh) 2018-11-13

Similar Documents

Publication Publication Date Title
ES2664075T3 (es) Priorización de paquetes en una red definida por software que implementa OpenFlow
US10778612B2 (en) Variable TCAM actions
CN109861926B (zh) 报文的发送、处理方法、装置、节点、处理系统和介质
US10326830B1 (en) Multipath tunneling to a service offered at several datacenters
US11374858B2 (en) Methods and systems for directing traffic flows based on traffic flow classifications
US10778721B1 (en) Hash-based ACL lookup offload
US10530692B2 (en) Software FIB ARP FEC encoding
US10708272B1 (en) Optimized hash-based ACL lookup offload
US10333853B1 (en) Unified quality of service (QoS) for label switching traffic
WO2019030552A1 (en) ADVANCED NETWORK PATH TRACING
Kundel et al. OpenBNG: Central office network functions on programmable data plane hardware
US11818022B2 (en) Methods and systems for classifying traffic flows based on packet processing metadata
US11876696B2 (en) Methods and systems for network flow tracing within a packet processing pipeline
Kundel et al. P4-bng: Central office network functions on programmable packet pipelines
WO2018150223A1 (en) A method and system for identification of traffic flows causing network congestion in centralized control plane networks
US11563698B2 (en) Packet value based packet processing
US20230064845A1 (en) Methods and systems for orchestrating network flow tracing within packet processing pipelines across multiple network appliances
US20120106555A1 (en) Low latency carrier class switch-router
US11637775B2 (en) Methods and systems for location identifier based forwarding
Kasabai et al. Priority-based scheduling policy for OpenFlow control plane
Kushwaha et al. Bitstream: A flexible SDN protocol for service provider networks
US11863467B2 (en) Methods and systems for line rate packet classifiers for presorting network packets onto ingress queues
Koerner et al. An approach for qos constraint networks in cloud environments
CN115865802B (zh) 虚拟实例的流量镜像方法、装置、虚拟机平台及存储介质
Al Shaikhli Using Software-Defined Networking and OpenFlow Switching to Reroute Network Traffic Dynamically Based on Traffic Volume Measurements