ES2602818T3 - Procedimiento para la gestion de asignacion de direccion de protocolo de red con un controlador - Google Patents

Procedimiento para la gestion de asignacion de direccion de protocolo de red con un controlador Download PDF

Info

Publication number
ES2602818T3
ES2602818T3 ES12775587.4T ES12775587T ES2602818T3 ES 2602818 T3 ES2602818 T3 ES 2602818T3 ES 12775587 T ES12775587 T ES 12775587T ES 2602818 T3 ES2602818 T3 ES 2602818T3
Authority
ES
Spain
Prior art keywords
controller
server
dhcp
network
packet
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
ES12775587.4T
Other languages
English (en)
Inventor
Kanzhe Jiang
Shudong Zhou
Robert Edward ADAMS
Mandeep Singh DIIAMI
Alexander Stafford David REIMERS
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.)
Big Switch Networks LLC
Original Assignee
Big Switch Networks LLC
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 Big Switch Networks LLC filed Critical Big Switch Networks LLC
Application granted granted Critical
Publication of ES2602818T3 publication Critical patent/ES2602818T3/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
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/25—Mapping addresses of the same type
    • H04L61/2503—Translation of Internet protocol [IP] addresses
    • H04L61/2521—Translation architectures other than single NAT servers
    • H04L61/2528—Translation at a proxy
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/50—Address allocation
    • H04L61/5007—Internet protocol [IP] addresses
    • H04L61/5014—Internet protocol [IP] addresses using dynamic host configuration protocol [DHCP] or bootstrap protocol [BOOTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/50—Address allocation
    • H04L61/5061—Pools of addresses
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/50—Address allocation
    • H04L61/5076—Update or notification mechanisms, e.g. DynDNS

Abstract

Procedimiento de utilización de un controlador (18) para controlar conmutadores en una red, comprendiendo el procedimiento: controlar con el controlador (18), los conmutadores de la red proporcionando reglas de reenvío de paquetes a los conmutadores; identificar (202) con el controlador (18), si un paquete de red que se ha enviado desde una estación final está solicitando la asignación de una dirección de protocolo para la estación final; en respuesta a identificar que el paquete de red solicita la asignación de una dirección de protocolo para la estación final, procesar el paquete de red con el controlador (18); y controlar con el controlador (18), los conmutadores proporcionando al menos a uno de los conmutadores el paquete de red que ha sido procesado por el controlador, en el que el procesamiento del paquete de red con el controlador comprende: identificar (206) con el controlador, un servidor que tiene capacidades de asignación de direcciones de protocolo; y reenviar (208) con el controlador (18), el paquete de red al servidor, estando el procedimiento caracterizado porque el reenvío del paquete de red al servidor comprende proporcionar reglas de reenvío de paquetes a los conmutadores que ordenan los conmutadores a reenviar el paquete de red de la estación final al servidor.

Description

5
10
15
20
25
30
35
40
45
50
55
60
65
DESCRIPCION
Procedimiento para la gestion de asignacion de direccion de protocolo de red con un controlador Antecedentes
Este documento se refiere a las redes de comunicacion y, mas concretamente, a la utilization de un controlador para controlar el trafico de la red asociado con la asignacion de direccion de red en una red.
Las redes basadas en paquetes tales como internet y las redes de datos locales que estan conectadas a internet incluyen conmutadores de red. Se utilizan conmutadores de red en el envio de paquetes desde los origenes de los paquetes a los destinos de los paquetes. Los paquetes se pueden denominar, en ocasiones, tramas (frames, en ingles).
Puede ser dificil o imposible controlar los conmutadores de un proveedor utilizando el equipo de otro proveedor. Esto se debe a que el equipo de commutation de un proveedor puede utilizar un sistema operativo y un conjunto de procedimientos de control diferentes de los del equipo de conmutacion de otro proveedor. Para abordar los problemas asociados con el control de diferentes tipos de plataformas de conmutacion, se han desarrollado protocolos de plataforma cruzada. Estos protocolos permiten el control centralizado de conmutadores que de otro modo son incompatibles.
Los clientes del controlador de plataforma cruzada pueden estar incluidos en los conmutadores de una red. Los clientes del controlador son capaces de comunicarse con un servidor del controlador correspondiente a traves de rutas de red. Debido a que los clientes del controlador pueden ser implementados con diferente hardware de conmutador, es posible que un solo controlador controle el equipo de conmutacion que de otro modo podria ser incompatible.
Las estaciones finales en la red se pueden comunicar enviando paquetes de red a traves de los conmutadores. Cada uno de los paquetes de red tiene campos de cabecera de paquete que incluyen information de la direccion del Protocolo de Internet (IP) de origen y/o informacion de la direccion de otro protocolo. La informacion de la direccion IP de origen de un paquete de red dado identifica que estacion final envio dicho paquete de red. Para comunicarse con otras estaciones finales, cada estacion final debe obtener primero una direccion IP correspondiente de la red. La red puede incluir uno o varios servidores que distribuyen direcciones IP a estaciones finales en la red. Los servidores pueden distribuir direcciones IP utilizando el Protocolo de configuration dinamica de estacion (DHCP, Dynamic Host Configuration Protocol). Para obtener una direccion IP, una estacion final inunda la red con paquetes de petition de obtencion de DHCP que pueden llegar a cada una de las otras estaciones finales en la red. Los servidores de DHCP que reciben la peticion de obtencion pueden responder con un paquete de oferta de DHCP que informa a la estacion final de una direccion IP disponible para que la utilice. La estacion final puede aceptar una direccion IP disponible de entre los paquetes de oferta de DHCP, inundando la red con un paquete de peticion de oferta de DHCP que informa a los servidores de DHCP de cual de las direcciones IP ofrecidas fue aceptada por la estacion final.
Inundar una red para enviar peticiones de DHCP puede cargar la red de manera no deseada con un trafico de red innecesario, debido a que las peticiones de DHCP pueden ser enviadas a estaciones finales que no son servidores de DHCP. El envio de peticiones de DHCP innecesarias puede afectar al rendimiento de los conmutadores de la red. Seria, por lo tanto, deseable, poder proporcionar mejoras para realizar la asignacion de direccion a las estaciones finales en una red.
El documento EP 1 615 405 A2 da a conocer el ahorro de energia en redes inalambricas basadas en paquetes mediante un filtrado selectivo de la difusion. El documento EP 1 613 023 A2 da a conocer un dispositivo de puentes de red y un procedimiento para el dispositivo de puentes de red. El documento DE 10 2005 006889 A1 da a conocer un procedimiento para el establecimiento de un enlace de comunicaciones, al menos, en una red de comunicaciones.
Caracteristicas de la invention
La presente invencion proporciona un procedimiento tal como el definido en la revindication 1 independiente. Se puede utilizar un controlador tal como un servidor de controlador, para controlar los conmutadores en una red. El controlador puede ayudar a reducir el trafico de red que esta asociado con la difusion general de peticiones del Protocolo de configuracion dinamica de estaciones (DHCP) (por ejemplo, u otras peticiones que solicitan la asignacion de una direccion de protocolo a una estacion final) identificando los paquetes de red que estan asociados con el protocolo DHCP, y procesando los paquetes de red identificados. El controlador puede identificar cuales de los paquetes de red son paquetes de peticion de DHCP, recuperando la informacion de los campos de cabecera de paquete de los paquetes de red.
En respuesta a la identification de que un paquete de red recibido de una estacion final es un paquete de peticion de DHCP, el controlador puede procesar el paquete de peticion de DHCP identificando un servidor apropiado (por
5
10
15
20
25
30
35
40
45
50
55
60
65
ejemplo, un servidor DHCP o un agente de retransmision de DHCP) que es capaz de asignar una direccion de protocolo a la estacion final, y remitir el paquete de peticion de DHCP al servidor. El servidor puede ser identificado seleccionando el servidor de una base de datos de servidores. La base de datos se puede actualizar en base a los paquetes de respuesta de DHCP que son recibidos por el controlador de los servidores en la red. Por ejemplo, el controlador puede almacenar informacion de direccion tal como direcciones de hardware y direcciones de protocolo de los servidores que son recuperadas de los campos de cabecera de paquete de los paquetes de respuesta de DHCP. La informacion de direccion almacenada se puede utilizar para identificar servidores para cumplimentar paquetes de peticion de DHCP futuros.
El controlador puede modificar el paquete de peticion de DHCP para convertir el paquete de peticion de DHCP de un paquete de difusion general en un paquete de unidifusion que esta destinado al servidor. Para convertir el paquete de peticion de DHCP en un paquete de unidifusion, el controlador puede modificar los campos de la cabecera de direccion del paquete, tales como direcciones de Ethernet y direcciones de Protocolo de Internet (IP). Por ejemplo, el controlador puede almacenar una direccion de hardware del servidor en un campo de direccion de destino del paquete. El controlador puede determinar si modifica las direcciones de Ethernet o las direcciones IP del paquete en base a la informacion de la topologla de red. Por ejemplo, el controlador puede modificar un campo de direccion de destino de Ethernet del paquete, en respuesta a la determinacion de que la estacion final y el servidor esten situados en la misma subred. Como ejemplo adicional, el controlador puede modificar un campo de direccion de destino de IP del paquete en respuesta a la determinacion de que la estacion final y el servidor esten situados en diferentes subredes. El controlador puede remitir el paquete de peticion de DHCP modificado al servidor, proporcionando reglas de reenvio de paquetes, tales como entradas de tablas de flujo a los conmutadores, o mediante la remision del paquete de peticion de DHCP modificado a traves del controlador a un conmutador que esta acoplado al servidor.
Otras caracteristicas de la presente invencion, su naturaleza y diversas ventajas, resultaran mas evidentes a partir de los dibujos que se acompanan y de la siguiente descripcion detallada.
Breve description de los dibujos
La figura 1 es un diagrama que muestra una red que incluye un controlador y un sistema de reenvio de paquetes, segun una realization de la presente invencion.
La figura 2 es un diagrama que muestra como se puede implementar un sistema de reenvio de paquetes utilizando un equipo basado en microprocesadores que ejecuta un motor de procesamiento de paquetes, segun una realizacion de la presente invencion.
La figura 3 es un diagrama de un sistema de reenvio de paquetes y el controlador asociado, en el que el sistema de reenvio de paquetes incluye una unidad de control y circuitos integrados de commutation asociados, segun una realizacion de la presente invencion.
La figura 4 es un diagrama de una red, en la que un sistema de reenvio de paquetes tiene controladores maestro y subordinado, y en la que un servidor del controlador puede ser implementado en un equipo informatico remoto o en una tarjeta de linea en el sistema de reenvio de paquetes, segun una realizacion de la presente invencion.
La figura 5 es un diagrama de un servidor del controlador y de un cliente del controlador que se pueden comunicar a traves de una conexion de red, segun una realizacion de la presente invencion.
La figura 6A es un diagrama que muestra una tabla de flujo del tipo que puede ser utilizado por un sistema de procesamiento de paquetes, segun una realizacion de la presente invencion.
La figura 6B es un diagrama que muestra una tabla de flujo del tipo que puede ser utilizado por un sistema de procesamiento de paquetes que muestra tres tipos de reenvio de paquetes que pueden ser realizados en base a las entradas de la tabla de flujo, segun una realizacion de la presente invencion.
La figura 6C es un diagrama que muestra una tabla de flujo en la que se reenvian paquetes con una direccion concreta al tercer puerto fisico en un conmutador, segun una realizacion de la presente invencion.
La figura 6D es un diagrama que muestra una tabla de flujo en la que se reenvian paquetes con una direccion concreta al quinto puerto fisico en un conmutador, segun una realizacion de la presente invencion.
La figura 7 es un diagrama de flujo que muestra las etapas implicadas en el procesamiento de paquetes en un sistema de procesamiento de paquetes, segun una realizacion de la presente invencion.
La figura 8 es un diagrama que muestra una red en la que una estacion final puede solicitar una direccion de Protocolo de Internet (IP) de los servidores de Protocolo de configuration dinamica de estaciones (DHCP), segun una realizacion de la presente invencion.
5
10
15
20
25
30
35
40
45
50
55
60
65
La figura 9A muestra un paquete de peticion de obtencion de DHCP que puede ser enviado por una estacion final para solicitar una direccion IP de los servidores de DHCP, segun una realizacion de la presente invencion.
La figura 9B muestra un paquete de peticion de obtencion de DHCP modificado mediante un controlador, que puede ser reenviado directamente a un servidor DHCP, segun una realizacion de la presente invencion.
La figura 9C muestra un paquete de respuesta a la oferta del servidor DHCP que puede ser enviado por un servidor DHCP para ofrecer una direccion IP a una estacion final, con una realizacion de la presente invencion.
La figura 9D muestra un paquete de peticion de oferta de DHCP que puede ser enviado por una estacion final en respuesta a la oferta del servidor DHCP, segun una realizacion de la presente invencion.
La figura 9E muestra un paquete de peticion de oferta de DHCP modificado mediante un controlador, que puede ser reenviado directamente a un servidor DHCP, segun una realizacion de la presente invencion.
La figura 9F muestra un paquete de respuesta de acuse de recibo de DHCP que puede ser enviado por un servidor DHCP para confirmar la asignacion de una direccion IP a una estacion final, segun una realizacion de la presente invencion.
La figura 10 es un diagrama que muestra etapas que pueden ser realizadas utilizando un controlador para reenviar una peticion de DHCP de una estacion final a un servidor DHCP conocido, segun una realizacion de la presente invencion.
La figura 11 es un diagrama que muestra una red, en la que una estacion final ubicada en una primera subred puede solicitar una direccion IP desde un servidor DHCP que esta situado en una segunda subred, segun una realizacion de la presente invencion.
La figura 12 muestra un paquete de peticion de obtencion de DHCP modificado mediante un controlador que puede estar creado por un servidor del controlador y enviado a un agente de retransmision.
La figura 13 muestra un paquete de peticion de obtencion de DHCP modificado mediante un controlador, que puede estar creado por un controlador que tiene una funcionalidad incorporada de agente de retransmision, segun una realizacion de la presente invencion.
La figura 14 muestra un diagrama que muestra etapas implicadas con la cumplimentacion de peticiones de DHCP con un servidor del controlador que tiene una funcionalidad incorporada de agente de retransmision, segun una realizacion de la presente invencion.
La figura 15 muestra un diagrama de flujo de etapas que pueden ser realizadas mediante un controlador para controlar el flujo de paquetes de DHCP entre estaciones finales y servidores de DHCP, segun una realizacion de la presente invencion.
La figura 16 muestra un diagrama de flujo de etapas que pueden ser realizadas por un controlador para crear un paquete de peticion de DHCP modificado mediante el controlador en base a information de la topologia de red, segun una realizacion de la presente invencion.
La figura 17 es un diagrama que muestra una red, en la que un controlador puede estar distribuido en conmutadores en la red, segun una realizacion de la presente invencion.
Description detallada
Redes tales como internet y las redes locales y regionales que estan acopladas a internet se basan en conmutadores basados en paquetes. Estos conmutadores, que se denominan en ocasiones en esta memoria conmutadores de red, sistemas de procesamiento de paquetes o sistemas de reenvio de paquetes, pueden reenviar paquetes en base a informacion de la direccion. De esta manera, los paquetes de datos que son transmitidos por el origen de los paquetes pueden ser entregados a un destino de paquetes. En terminos de red, los origenes y los destinos de paquetes se denominan en ocasiones estaciones finales. Ejemplos de estaciones finales son ordenadores personales, servidores y otros equipos informaticos.
Los conmutadores de red varian, en capacidad desde conmutadores Ethernet relativamente pequenos y puntos de acceso inalambricos hasta grandes sistemas basados en “rack”, que incluyen varias tarjetas de linea, fuentes de alimentation duplicadas y capacidades de supervision. No es infrecuente que las redes incluyan equipos de varios proveedores. Los conmutadores de red de diferentes proveedores pueden estar interconectados para crear una red de reenvio de paquetes, pero puede resultar dificil de gestionar de una manera centralizada, debido a incompatibilidades entre sus sistemas operativos y sus protocolos de control.
5
10
15
20
25
30
35
40
45
50
55
60
65
Estas potenciales incompatibilidades se pueden superar mediante la incorporacion de un modulo comun de control de plataforma cruzada (denominado en ocasiones en esta memoria cliente del controlador) en cada conmutador de red. Un servidor del controlador de plataforma cruzada centralizado puede interactuar con cada uno de los clientes de control a traves de los respectivos enlaces de red. La utilizacion de un servidor del controlador de plataforma cruzada y de los correspondientes clientes del controlador permiten potencialmente gestionar de manera centralizada diversos equipos de conmutacion de red.
A modo de configuracion ilustrativa, que se describe en ocasiones en esta memoria como ejemplo, se preve un control centralizado mediante uno o varios servidores del controlador tales como el servidor -18- del controlador de la figura 1. El servidor -18- de control puede ser implementado en un ordenador independiente, en un grupo de ordenadores, en un conjunto de ordenadores distribuidos entre varias ubicaciones, en hardware incorporado en un conmutador de red, o en otro equipo informatico -12- adecuado. El servidor -18- del controlador se puede ejecutar como un solo proceso en un unico ordenador, o puede estar distribuido en varias estaciones por duplicidad. La utilizacion de una disposicion distribuida puede ayudar a proporcionar a la red -10- cierta resistencia frente a particiones inesperadas de la red (por ejemplo, una situation en la que un enlace de red entre dos campus se interrumpe).
En disposiciones distribuidas del controlador, los nodos del controlador pueden intercambiar informacion utilizando un protocolo interno de los controladores. Por ejemplo, si una estacion final nueva esta conectada a un hardware de red (por ejemplo, un conmutador) que solo esta conectado a un primer nodo controlador, dicho primer nodo controlador puede utilizar el protocolo interno de los controladores para informar a otros nodos controladores de la presencia de la nueva estacion final. Si se desea, un conmutador u otro componente de red puede conectarse a varios nodos controladores. En esta memoria, en ocasiones, se describen a modo de ejemplo disposiciones en las que se utiliza un solo servidor de controlador para controlar una red de conmutadores asociados.
El servidor -18- del controlador de la figura 1 puede reunir information acerca de la topologla de la red -10-. Por ejemplo, el servidor -18- del controlador puede enviar los paquetes de prueba del Protocolo de obtencion de capa de enlace (LLDP) a traves de la red para obtener la topologla de la red -10-. El servidor -18- del controlador puede utilizar informacion acerca de la topologla de red e informacion sobre las capacidades de equipo de red para decidir rutas apropiadas para los paquetes que circulan por la red. Una vez que se han identificado las rutas apropiadas, el servidor -18- del controlador puede enviar los datos de configuracion correspondientes al hardware de la red -10- para asegurar que los paquetes circulan por la red segun se desea. Los procedimientos de configuracion de la red como estos pueden ser realizados durante los procedimientos de configuracion del sistema, de manera continua en segundo plano, o en respuesta a la aparicion de paquetes de datos recien transmitidos (es decir, paquetes para los que no se ha establecido una ruta preexistente).
El servidor -18- del controlador puede ser utilizado para implementar reglas -20- de configuracion de red. Las reglas -20- pueden especificar que servicios estan disponibles para varias entidades de red. Por ejemplo, las reglas -20- pueden especificar que usuarios (o tipo de usuarios) de la red -10- pueden acceder a un servidor concreto. Las reglas -20- pueden, por ejemplo, estar guardadas en una base de datos en el equipo informatico -12-.
El servidor -18- del controlador y los clientes -30- del controlador en los respectivos conmutadores -14- de red pueden utilizar pilas de protocolo de red para comunicarse a traves de los enlaces -16- de red.
Cada conmutador -14- (sistema de reenvio de paquetes) puede tener puertos -34- de entrada-salida. Se pueden utilizar cables para conectar partes del equipo a los puertos -34-. Por ejemplo, las estaciones finales tales como ordenadores personales, servidores web y otros equipos informaticos pueden ser conectados en los puertos -34-. Asimismo, se pueden utilizar los puertos -34- para conectar uno de los conmutadores -14- a otros conmutadores -14-.
Se pueden utilizar circuitos -32- de procesamiento de paquetes en el reenvio de paquetes desde uno de los puertos -34- a otro de los puertos -34-, y pueden ser utilizados para realizar otras acciones adecuadas en paquetes entrantes. Se puede implementar el circuito -32- de procesamiento de paquetes utilizando uno o varios circuitos integrados tales como circuitos de conmutacion de alta velocidad dedicados, y puede servir como ruta de datos de hardware. Si se desea, se puede utilizar software -26- de procesamiento de paquetes que se ejecuta en la unidad -24- de control, en la implementacion de una ruta de datos de software.
La unidad de control -24- puede incluir circuitos de procesamiento y de memoria (por ejemplo, uno o varios microprocesadores, chips de memoria y otros circuitos de control) para almacenar y ejecutar software de control. Por ejemplo, la unidad de control -24- puede almacenar y ejecutar software tal como el software -26- de procesamiento de paquetes, puede almacenar la tabla -28- de flujo y puede ser utilizada para dar soporte al procedimiento de los clientes -30- del controlador.
Los clientes -30- del controlador y el servidor -18- del controlador pueden ser compatibles con un protocolo de conmutacion de red tal como el protocolo “OpenFlow” (vease, por ejemplo, la version 1.0.0 de la Especificacion de
5
10
15
20
25
30
35
40
45
50
55
60
65
conmutacion de OpenFlow). Uno o varios clientes de entre los clientes -30- del controlador pueden ser compatibles asimismo con otros protocolos (por ejemplo, el Protocolo simple de administracion de la red del ingles “Simple Network Management Protocol). Utilizando el protocolo OpenFlow u otros protocolos adecuados, el servidor -18- del controlador puede proporcionar a los clientes -30- del controlador datos que determinan como va a procesar el conmutador -14- los paquetes entrantes de los puertos -34- de entrada-salida.
Con una disposicion adecuada, se pueden almacenar los datos de la tabla de flujo del servidor -18- del controlador en una tabla de flujo tal como la tabla -28- de flujo. Las entradas de la tabla -28- de flujo se pueden utilizar en la configuracion del conmutador -14- (por ejemplo, las funciones de los circuitos -32- de procesamiento de paquetes y/o el software -26- de procesamiento de paquetes). En un escenario normal, la tabla -28- de flujo sirve como memoria cache para las entradas de la tabla de flujo, y una version correspondiente de estas entradas de la tabla de flujo se incluye en la configuracion guardada por la circuiterla de los circuitos -32- de procesamiento de paquetes. Sin embargo, esto es meramente ilustrativo. La tabla -28- de flujo puede servir como almacenamiento exclusivo para las entradas de la tabla de flujo en el conmutador -14-, o puede ser suprimida en favor de los recursos de almacenamiento de la tabla de flujo dentro de los circuitos -32- de procesamiento de paquetes. En general, las entradas de la tabla de flujo se pueden almacenar utilizando cualquier estructura de datos adecuada (por ejemplo, una o varias tablas, listas, etc.). Para mayor claridad, los datos de la tabla -28- de flujo (ya sea si estan guardados en la base de datos en la unidad -24- de control o si estan incluidos en la configuracion de los circuitos -32- de procesamiento de paquetes) se denominan en esta memoria, como entradas de la tabla de flujo de formacion (por ejemplo, filas en la tabla -28- de flujo).
El ejemplo de las tablas -28- de flujo que almacenan datos que determina como va a procesar el conmutador -14- los paquetes entrantes, es meramente ilustrativo. Se puede utilizar cualquier motor de decision de reenvio de paquetes para ayudar al sistema -14- de reenvio de paquetes a tomar decisiones acerca de como reenviar paquetes de red. Por ejemplo, los motores -28- de decision de reenvio de paquetes pueden ordenar al sistema -14- de reenvio de paquetes que reenvie paquetes de red a puertos predeterminados, en base a las caracteristicas de los paquetes de red (por ejemplo, en base a las cabeceras del protocolo de red).
Si se desea, el conmutador -14- puede ser implementado utilizando una plataforma de procesamiento de uso general que ejecuta software de control y que suprime los circuitos -32- de procesamiento de paquetes de la figura 2. Este tipo de configuracion se muestra en la figura 2. Tal como se muestra en la disposicion ilustrativa de la figura 2, el servidor -18- del controlador en el equipo informatico -12- puede comunicarse con los clientes -30- del controlador en el conmutador (sistema de reenvio de paquetes) -14- a traves del enlace -16- de red. El servidor -18- del controlador puede, por ejemplo, enviar entradas de la tabla de flujo a los clientes -30- del controlador que estan guardadas en la tabla -28- de flujo. El software -40- de procesamiento de paquetes puede utilizar la interfaz -38- de red para reenviar y procesar paquetes de otro modo (por ejemplo, paquetes transmitidos y recibidos utilizando los puertos -34-). La interfaz -38- de red se puede implementar utilizando una o varias tarjetas de interfaz de red que estan conectadas en una placa del sistema en el conmutador -14- (a modo de ejemplo).
Los conmutadores de red tales como el conmutador -14- de red de la figura 1 se pueden implementar utilizando circuitos de control que estan acoplados a uno o varios circuitos integrados de conmutacion de alta velocidad (“CI del conmutador"). Este tipo de configuracion se muestra en la figura 3. Tal como se muestra en la figura 3, el servidor -18- del controlador en el equipo informatico -12- se puede comunicar con el conmutador -14- de red a traves de la ruta -16-. El conmutador -14- puede incluir los circuitos -24- de procesamiento y uno o varios CI -32- de conmutador asociados, tales como el CI -32-1- de conmutador... CI -32-N- de conmutador. Los circuitos -24- de control pueden estar basados, por ejemplo, en un microprocesador y una memoria. Los CI -32-1-... -32-N- de conmutador pueden ser circuitos de conmutacion dedicados capaces de manejar tareas de procesamiento de paquetes a altas velocidades. Como ejemplo, los circuitos -24- de control pueden estar basados en un microprocesador de 500 MHz y los CI -32-1- ... -32-N- del conmutador pueden ser capaces de manejar datos de 48 de los puertos -34- de entrada-salida, cada uno de los cuales tiene una velocidad de datos asociada de 1-10 Gbps (a modo de ejemplo).
En la figura 4, se muestra otra arquitectura de conmutador ilustrativa, que puede ser utilizada en la implementacion del conmutador -14- de red de la figura 1. En el ejemplo de la figura 4, el conmutador -14- (sistema de reenvio de paquetes) puede incluir un procesador maestro, tal como el procesador -24-1-, y uno o varios procesadores subordinados asociados, tal como el procesador subordinado -24-2-. Los CI -32- del conmutador y los procesadores subordinados tal como el procesador -24-2- se pueden implementar en tarjetas de linea tales como la tarjeta -48- de linea. Una o varias tarjetas de linea, tales como la tarjeta -50- de linea, puede o pueden contener circuitos de procesamiento (por ejemplo, un microprocesador y una memoria). Las tarjetas -48- y -50- de linea se pueden interconectar utilizando el panel -52- trasero.
Con una disposicion del tipo mostrada en la figura 4, el servidor del controlador se puede implementar utilizando los recursos de procesamiento de la tarjeta de linea. Por ejemplo, el servidor del controlador se puede implementar en la tarjeta -50- de linea, tal como muestra el servidor -18-B- del controlador de la figura 4. Si se desea, el servidor del controlador se puede implementar en el equipo informatico -12- (por ejemplo, tal como el servidor -18-A- del controlador de la figura 4). El servidor -18-A- del controlador o el servidor -18-B- del controlador se puede comunicar
5
10
15
20
25
30
35
40
45
50
55
60
65
con los clientes -30- del controlador que estan implementados utilizando procesadores tales como el procesador -24-1- y/o -24-2-. Las comunicaciones entre el servidor -18-A- del controlador y los clientes del controlador pueden tener lugar a traves de la conexion -16- de red. Las comunicaciones entre el servidor -18-B- del controlador y los clientes del controlador pueden tener lugar en el panel -52- trasero (por ejemplo, a traves de una conexion de red que utiliza un protocolo tal como el TCP/IP).
Tal como se muestra en la figura 5, el servidor -18- del controlador y el cliente -30- del controlador se pueden comunicar a traves de la ruta -66- de red utilizando pilas del protocolo de red tales como la pila -58- de protocolo de red y la pila -60- de protocolo de red. Las pilas -58- y -60- pueden ser, por ejemplo, las pilas TCP/IP de Linux o la pila TCP/IP en el sistema operativo VxWorks (a modo de ejemplos). La ruta -66- puede ser, por ejemplo, una ruta que soporta una conexion de red entre el conmutador -14- y un equipo externo (por ejemplo, la ruta -16- de red de la figura 1), o puede ser una ruta que soporta una conexion de red en el panel -52- trasero en el conmutador -14-, tal como se muestra en la figura 4. En esta memoria, se describen en ocasiones, a modo de ejemplo, disposiciones en las que la ruta -66- es una ruta de red tal como la ruta -16-.
La pila -56- del protocolo de control sirve de interfaz entre la pila -58- del protocolo de red y el software -54- de control. La pila -62- del protocolo de control sirve de interfaz entre la pila -60- del protocolo de red y el software -64- de control. Durante el funcionamiento, cuando el servidor -18- del controlador se esta comunicando con el cliente -30- del controlador, las pilas -56- del protocolo de control generan y analizan los mensajes de control (por ejemplo, los mensajes de control para activar un puerto o para instalar una entrada concreta de la tabla de flujo en la tabla -28- de flujo). Utilizando las disposiciones del tipo mostrado en la figura 5, se crea una conexion de red en el enlace entre el servidor -18- del controlador y el cliente -30- del controlador. El servidor -18- del controlador y el cliente -30- del controlador se pueden comunicar utilizando el Protocolo de control de transmision (TCP) o el Protocolo de datagramas de usuario (UDP) a traves de la conexion de red del Protocolo de Internet (IP). Ejemplos de protocolos de control que se pueden utilizar cuando existe comunicacion entre el servidor -18- del controlador y los clientes -30- del controlador a traves de la conexion de red, incluyen SNMP y la version 1.0.0 de la pila de protocolo OpenFlow de (a modo de ejemplos).
La tabla -28- de flujo contiene entradas de la tabla de flujo (por ejemplo, filas en la tabla) que tienen varios campos (en ocasiones denominados campos de cabecera). Los campos en un paquete que ha sido recibido por el conmutador -14- se pueden comparar con los campos de la tabla de flujo. Cada entrada de la tabla de flujo puede tener acciones asociadas. Cuando existe una coincidencia entre los campos en un paquete y los campos en una entrada de la tabla de flujo, se puede realizar la accion correspondiente para esa entrada de la tabla de flujo.
Una tabla de flujo ilustrativa se muestra en la figura 6. Tal como se muestra en la figura 6A, la tabla -28- puede tener entradas -68- (filas) de tabla de flujo. Cada entrada de la tabla de flujo puede estar asociada con la cabecera -70-, la accion -72- y las estadisticas -74-. Las cabeceras -70- pueden incluir, cada una, campos -76- de cabecera. La accion en cada entrada de la tabla de flujo indica que accion va a realizar el conmutador -14- en el paquete cuando se detecta una coincidencia entre los campos en el paquete y los campos correspondientes en la cabecera de dicha entrada de la tabla de flujo. El conmutador -14- puede guardar los datos estadisticos (valores de contador) en la porcion estadistica de la tabla -28- de flujo que puede ser interrogada por el servidor -18- del controlador cuando se desea obtener informacion acerca del funcionamiento del conmutador -14-.
Los campos de cabecera en la cabecera -70- (y los correspondientes campos en cada paquete entrante) pueden incluir los siguientes campos: puerto de entrada (es decir, la identidad del puerto fisico en el conmutador -14- a traves del cual se esta recibiendo el paquete), la direccion de origen Ethernet, la direccion de destino Ethernet, el tipo de Ethernet, la identificacion de la red de area local virtual (VLAN), la prioridad de la VLAN, la direccion IP origen, la direccion IP destino, el protocolo IP, los bits de “ToS" (tipo de servicio) de IP, el puerto de origen de transporte / Tipo de protocolo de mensajes de control de Internet (ICMP) (en ocasiones denominado puerto TCP origen), y el puerto de destino de transporte/codigo ICMP (en ocasiones denominado puerto TCP destino). Si se desea, se pueden utilizar otros campos. Por ejemplo, se puede utilizar un campo de protocolo de red y un campo de puerto de protocolo.
Cada entrada de la tabla de flujo (entrada de flujo) esta asociada a cero o mas acciones que deciden como maneja el conmutador los paquetes coincidentes. Si no existen acciones de reenvio, el paquete preferiblemente se descarta. Las acciones que el conmutador -14- puede tomar cuando se detecta una coincidencia entre los campos de un paquete y los campos de la cabecera en una entrada de la tabla de flujo pueden incluir las siguientes acciones: reenvio (por ejemplo, TODOS para enviar el paquete en todas las interfaces, no incluyendo la interfaz de entrada, CONTROLADOR para encapsular y enviar el paquete al servidor del controlador, LOCAL para enviar el paquete a la pila de red local del conmutador, TABLA para realizar acciones en la tabla -28- de flujo, PUERTO_ENTRADA para sacar el paquete del puerto de entrada, NORMAL para procesar el paquete con una ruta de reenvio por defecto que esta soportada por el conmutador, utilizando, por ejemplo, el nivel 2 tradicional, la VLAN y el procesamiento de nivel 3, INUNDACION para inundar el paquete a lo largo del arbol de expansion minima, no incluyendo la interfaz de entrada). Las acciones adicionales que el conmutador -14- puede realizar incluyen: una accion de puesta en cola para reenviar un paquete a traves de una cola unida a un puerto, y una accion de descartar (por ejemplo, descartar un paquete que coincide con una entrada de la tabla de flujo sin ninguna accion especifica). Las acciones de
5
10
15
20
25
30
35
40
45
50
55
60
65
modification de campo pueden ser asimismo soportadas por el conmutador -14-. Ejemplos de acciones de modification de campo que se pueden realizar incluyen: Establecer la identification de la VLAN, Establecer prioridad de la VLAN, Separar la cabecera de la VLAN, Modificar la direction MAC (Control de acceso a medios) de origen Ethernet, Modificar la direccion MAC de destino Ethernet, Modificar direccion de origen IPv4, Modificar bits de ToS de IPv4, Modificar el puerto de destino de transporte.
La figura 6B es una tabla de flujo ilustrativa que tiene tres entradas en la tabla de flujo. Las entradas incluyen campos con asteriscos (por ejemplo, simbolos “*”). Cuando existe un asterisco en un campo particular, se considerara que todos los paquetes entrantes crean una “coincidencia" con respecto al campo, independientemente del valor concreto del campo en el paquete entrante.
La entrada de la primera fila de la tabla de la figura 6B indica el conmutador en el que la entrada de la tabla de flujo esta operando para realizar una commutation de Ethernet. En concreto, los paquetes entrantes con direcciones con destino Ethernet coincidentes son reenviados al puerto 3.
La entrada de la segunda fila de la tabla de la figura 6B muestra como se puede configurar un conmutador para realizar el encaminamiento de internet (es decir, los paquetes son reenviados en base a su direccion IP de destino).
La tercera fila de la tabla de la figura 6B contiene una entrada que muestra como se puede configurar un conmutador para realizar la funcion de cortafuegos. Cuando se recibe un paquete que tiene un valor del puerto IP de destino de 80, ese paquete se descarta (es decir, el conmutador se configura para actuar como un cortafuegos que bloquea el trafico del puerto 80).
Las entradas de la tabla de flujo del tipo mostrado en la figura 6B pueden ser cargadas en un conmutador -14- por el servidor -18- del controlador durante las operaciones de ajuste del sistema, o pueden ser proporcionadas a un conmutador -14- desde el servidor -18- del controlador en tiempo real, en respuesta a la reception y el procesamiento de paquetes en el servidor -18- del controlador del conmutador -14-. En una red con numerosos conmutadores -14-, cada conmutador puede ser provisto de entradas apropiadas de la tabla de flujo para crear una ruta a traves de la red.
Se considera, a modo de ejemplo, una red que contiene un primer y un segundo conmutador conectados en serie entre las estaciones finales respectivas. Cuando se envia trafico desde la primera de las estaciones finales a la segunda de las estaciones finales, puede ser deseable encaminar el trafico a traves del primer y segundo conmutador. Si el segundo conmutador esta conectado al puerto 3 del primer conmutador, si la segunda estacion final esta conectada al puerto 5 del segundo conmutador, y si la direccion IP destino de la segunda estacion final es 172.12.3.4, el servidor -18- del controlador puede proporcionar al primer conmutador la entrada de la tabla de flujo de la figura 6C, y puede proporcionar al segundo conmutador la entrada de la tabla de flujo de la figura 6D. Cuando los paquetes con direccion IP destino 172.12.3.4 son recibidos en el primer conmutador, estos son reenviados al segundo conmutador de acuerdo con la action “reenviar al puerto 3" en la tabla de la figura 6C. Cuando estos paquetes son recibidos en el segundo conmutador, son reenviados a la segunda estacion final que esta conectada al puerto 5 del segundo conmutador de acuerdo con la accion “reenviar al puerto 5" en la figura 6D.
En la figura 7 se muestran etapas ilustrativas que el conmutador -14- puede realizar en el procesamiento de paquetes que se reciben en los puertos -34- de entrada-salida. En la etapa -78-, el conmutador -14- recibe un paquete en uno de sus puertos (por ejemplo, uno de los puertos -34- de entrada-salida de la figura 1).
En la etapa -80-, el conmutador -14- compara los campos del paquete recibido con los campos de las entradas de la tabla de flujo en la tabla -28- de flujo de dicho conmutador para determinar si existe una coincidencia. Algunos campos en una entrada de la tabla de flujo pueden contener valores completos (es decir, direcciones completas). Otros campos pueden contener asteriscos (es decir, campos marcados con el caracter de “no considerar" representado por el asterisco “*"). Otros campos adicionales pueden tener entradas parcialmente completas (es decir, una direccion parcial que tiene un asterisco parcial). Algunos campos pueden utilizar rangos (por ejemplo, restringiendo un numero de puerto TCP a un valor entre 1 y 4096) y, en efecto, utilizar el rango para implementar un tipo de asterisco parcial. Realizando comparaciones campo a campo entre el paquete recibido y las entradas de la tabla de flujo, el conmutador -14- puede tener en cuenta si cada campo en la entrada de la tabla de flujo contiene o no un valor completo sin ningun asterisco, un valor parcial con asterisco, o un caracter con asterisco (es decir, un campo completamente con asterisco).
Si durante las operaciones de la etapa -80- se determina que no existe ninguna coincidencia entre los campos del paquete y los correspondientes campos de las entradas de la tabla de flujo, el conmutador -14- puede enviar el paquete al servidor -18- del controlador a traves del enlace -16- (etapa -84-).
Si durante las operaciones de la etapa -80- se determina que existe una coincidencia entre el paquete y una entrada de la tabla de flujo, el conmutador -14- puede realizar la accion que esta asociada con dicha entrada de la tabla de flujo, y puede actualizar el valor del contador en el campo de estadisticas de dicha entrada de la tabla de flujo (etapa
5
10
15
20
25
30
35
40
45
50
55
60
65
-82-). El procedimiento puede, a continuacion, volver atras a la etapa -78-, de tal manera que el conmutador -14- puede procesar otro paquete, tal como se indica mediante la linea -86-.
Un controlador (por ejemplo, un servidor del controlador u otros controladores implementados en un equipo informatico) que controla una red de conmutadores puede reunir o monitorizar informacion de red, tal como la topologia de red o informacion asociada con estaciones finales. El controlador puede incluir uno o varios servidores del controlador o puede estar distribuido en uno o varios conmutadores (por ejemplo, partes del controlador pueden estar implementadas en los circuitos de almacenamiento y de procesamiento de varios conmutadores). El controlador puede monitorizar las ubicaciones de red de las estaciones finales o monitorizar las conexiones entre los conmutadores en la red. El controlador puede reducir la carga de trafico de red en la red mediante la utilizacion de informacion de red para controlar el flujo del trafico de red entre las estaciones finales. La figura 8 muestra un escenario ilustrativo en el que el servidor -18- del controlador puede utilizar informacion de red para reducir el trafico innecesario de red, en la red -100-.
Tal como se muestra en la figura 8, la red -100- puede incluir estaciones finales -102- que estan conectadas a conmutadores en la red -100-. Los conmutadores pueden tener puertos a los que estan conectadas las estaciones finales u otros conmutadores. El conmutador -SW1- puede tener puertos A y B conectados a la estacion final -EH1- y al puerto E del conmutador -SW3-, respectivamente. El conmutador -SW2- puede tener puertos C y D conectados al puerto F del conmutador -SW3- y al servidor S1 DHCP, respectivamente. El ejemplo de los conmutadores -SW1- y -SW2- conectados a un unico conmutador -SW3- es meramente ilustrativo. Si se desea, el conmutador -SW1- puede estar conectado al conmutador -SW2- a traves de cualquier numero de conmutadores intermedios (por ejemplo, decenas, cientos, miles o mas) que crean la parte -104- de red.
Las estaciones finales -102- pueden incluir servidores DHCP tales como el servidor S1 DHCP y el servidor S2 DHCP que proporcionan direcciones de Protocolo de Internet (IP) a otras estaciones finales en la red -100-. Al servidor S1 DHCP y al servidor S2 DHCP se les puede asignar una parte respectiva de las direcciones IP disponibles (por ejemplo, un administrador de red puede asignar direcciones IP a cada servidor DHCP de un grupo de direcciones IP posibles). Por ejemplo, al servidor S1 DHCP se le pueden asignar direcciones IP entre 192.168.1.0 a 192.168.1.255. En este escenario, el servidor S1 DHCP puede proporcionar a la estacion final -EH1- la direccion IP 192.168.1.1. La estacion final -EH1- puede comunicarse, entonces, con otras estaciones finales de la red -100- utilizando la direccion IP 192.168.1.1. Por ejemplo, los paquetes de red enviados desde la estacion final -EH1- pueden incluir campos de cabecera indicando que los paquetes de red fueron enviados desde la direccion IP 192.168.1.1. Otras estaciones finales en la red -100- pueden enviar paquetes de red a la estacion final -EH1- enviando los paquetes de red a la direccion IP 192.168.1.1.
Para obtener una direccion IP, la estacion final -EH1- se puede comunicar con servidores DHCP utilizando el Protocolo de configuracion dinamica de estaciones (DHCP). Las figuras 9A, 9B, 9C, 9D, 9E y 9F muestran paquetes de red DHCP ilustrativos que se pueden utilizar para asignar una direccion IP a la estacion final -EH1-.
Cuando la estacion final -EH1- se conecta inicialmente a la red -100-, la estacion final -EH1- puede tener ya una direccion de hardware correspondiente (por ejemplo, una direccion MAC u otra direccion de Ethernet). Para comunicarse con otras estaciones finales, la estacion final -EH1- puede necesitar obtener una direccion IP de un servidor DHCP.
La figura 9A muestra un paquete de peticion de obtencion de DHCP -112A- que la estacion final -EH1- puede utilizar para solicitar una direccion IP de los servidores DHCP en la red -100-. Tal como se muestra en la figura 9A, la peticion -112A- de obtencion DHCP puede incluir una direccion origen de Ethernet, una direccion destino de Ethernet, una direccion de hardware de cliente y, opcionalmente, una direccion IP preferente u otras opciones deseadas. La direccion origen de Ethernet y la direccion de hardware de cliente pueden ser la direccion de hardware (por ejemplo, direccion MAC) de la estacion final -EH1-. La direccion destino de Ethernet puede ser una direccion de difusion general (por ejemplo, indicando que la peticion -112A- de obtencion de DHCP debe inundar toda la red -100-). El paquete de peticion -112A- de obtencion DHCP se puede denominar paquete de difusion general, debido a que el paquete esta dirigido a todas las estaciones finales de la red -100-.
La estacion final -EH1- puede indicar una direccion IP preferente 192.168.1.1 en la peticion -112A- de obtencion DHCP. Este ejemplo es meramente ilustrativo. Si se desea, la estacion final -EH1- puede incluir cualquier direccion IP preferente (por ejemplo, 192.168.1.99, 192.168.1.30, etc.) y puede, opcionalmente, incluir otra informacion, tal como informacion relativa a un tipo de hardware o firmware de la estacion final -EH1-.La estacion final -EH1- puede enviar la peticion -112A- de obtencion de DHCP a un conmutador del cliente conectado a la estacion final -EH1- (por ejemplo, el conmutador -SW1- del cliente). En respuesta a la recepcion de la peticion -112A- de obtencion de DHCP, el conmutador -SW1- del cliente puede reenviar la peticion -112A- de obtencion de DHCP al servidor -18- del controlador. En respuesta a la recepcion de la peticion -112A- de obtencion de DHCP, el servidor -18- del controlador puede identificar si un servidor DHCP adecuado es conocido para el servidor 18- del controlador -.
El servidor -18- del controlador puede identificar un servidor DHCP adecuado recuperando la informacion del servidor DHCP de una base de datos. Por ejemplo, el servidor -18- del controlador puede recuperar informacion de
5
10
15
20
25
30
35
40
45
50
55
60
65
direccion (por ejemplo, una direccion de red y una direccion de hardware) del servidor S1 DHCP de una base de datos almacenada en un almacenamiento -170-. La base de datos puede incluir informacion relativa a los servidores DHCP identificados previamente.
En respuesta a la identificacion de un servidor DHCP adecuado para cumplimentar la peticion -112A- de obtencion de DHCP, un servidor -18- del controlador puede crear la peticion -112B- de obtencion de DHCP modificada por el controlador de la figura 9B. La peticion -112B- de obtencion de DHCP modificada por el controlador se puede crear sustituyendo la direccion destino de Ethernet de difusion general de la peticion -112A- de obtencion de DHCP por una direccion de hardware del servidor DHCP identificado (por ejemplo, una direccion de hardware recuperada de la base de datos). El servidor -18- del controlador puede utilizar la direccion de hardware y otra informacion de direccion recuperada para generar una ruta de reenvio de paquetes desde la estacion final -EH1- al servidor S1 DHCP. El servidor -18- del controlador puede generar la ruta de reenvio de paquetes entre la estacion final -EH1- y el servidor S1 DHCP a traves de los conmutadores del cliente -SW1-, -SW3- y -SW2- (por ejemplo, proporcionando entradas apropiadas de la tabla de flujo u otras reglas de reenvio de paquetes que ordenan a los conmutadores del cliente reenviar paquetes de red entre la estacion final -EH1- y el servidor S1 DHCP). El servidor -18- del controlador puede, a continuacion, ordenar al conmutador -SW1- de cliente que reenvie la peticion -112B- de obtencion de DHCP modificada por el controlador al servidor S1 DHCP a lo largo de la ruta generada de reenvio de paquetes. Mediante la creacion de una ruta de reenvio de paquetes que encamina directamente la peticion -112B- de obtencion de DHCP modificada por el controlador hacia el servidor S1 DHCP, el servidor -18- del controlador puede ayudar a evitar un trafico innecesario en la red asociado con la difusion general de la peticion -112A- de obtencion de DHCP.
La peticion -112B- de obtencion de DHCP modificada por el controlador se puede denominar paquete de unidifusion, debido a que el paquete esta dirigido a una sola estacion final (por ejemplo, el servidor S1 DHCP).
En respuesta a la recepcion de la peticion -112B- de obtencion de DHCP modificada por el controlador, el servidor S1 DHCP puede asignar una direccion IP disponible a la estacion final -EH1- (por ejemplo, una direccion IP que no este actualmente asignada a otra estacion final o a un dispositivo de red), y responder a la peticion enviando el paquete de respuesta -114- a la oferta del servidor DHCP de la figura 9C.
La respuesta -114- a la oferta del servidor DHCP puede incluir una direccion origen Ethernet, una direccion destino Ethernet, una direccion IP origen, una direccion IP ofrecida, una direccion de hardware de cliente, duracion opcional de concesion y otras opciones relativas al ofrecimiento de una direccion IP a la estacion final -EH1-. La direccion origen Ethernet puede ser la direccion de hardware (por ejemplo, la direccion Ethernet) del servidor S1 DHCP, la direccion destino Ethernet y la direccion de hardware de cliente pueden ser la direccion de hardware de cliente recuperada de una peticion -112- de obtencion de DHCP correspondiente, la direccion IP origen puede ser la direccion IP del servidor S1 DHCP y la direccion IP ofrecida puede ser la direccion IP que ha sido asignada por el servidor S1 DHCP a la estacion final -EH1-. La duracion opcional de concesion puede identificar una duracion condicional asociada con la oferta (por ejemplo, la duracion condicional que debe ser aceptada por la estacion final -EH1- antes de que la direccion IP ofrecida sea asignada a la estacion final -EH1-). Por ejemplo, la duracion opcional de concesion puede incluir un periodo del tiempo durante el cual la direccion IP sera asignada a la estacion final -EH1- (por ejemplo, un dia). En este escenario, la asignacion de la direccion IP 192.168.1.1 a la estacion final -EH1- expira al cabo de un dia.
El servidor S1 DHCP puede enviar la respuesta -114- a la oferta del servidor DHCP al conmutador -SW2- del cliente. Si no existe una ruta de reenvio de paquetes para la respuesta -114- a la oferta del servidor DHCP, el conmutador -SW2- del cliente puede reenviar la respuesta -114 a la oferta del servidor DHCP - al servidor -18- del controlador. Si ya se ha generado una ruta de reenvio de paquetes (por ejemplo, en respuesta a la peticion -112- de obtencion de DHCP), el conmutador -SW2- del cliente puede reenviar la respuesta -114- a la oferta del servidor DHCP a la estacion final -EH1- a lo largo de la ruta de reenvio de paquetes generada previamente.
En respuesta a la recepcion de la respuesta -114- a la oferta de servidor DHCP, el servidor -18- del controlador puede generar una ruta de reenvio de paquetes entre el servidor S1 DHCP y la estacion final -EH1- y ordenar al conmutador -SW2- del cliente que reenvie la respuesta -114- a la oferta del servidor DHCP directamente a la estacion final -EH1- a lo largo de la ruta de reenvio de paquetes.
El servidor -18- del controlador puede utilizar informacion recuperada de los paquetes de DHCP tal como la respuesta -114- a la oferta del servidor DHCP para almacenar informacion del servidor DHCP (por ejemplo, en una base de datos en un almacenamiento -170-). Por ejemplo, el servidor -18- del controlador puede recuperar informacion del servidor DHCP tal como direcciones de red y una direccion de hardware del servidor DHCP a partir de la respuesta -114- a la oferta del servidor DHCP, y almacenar la informacion del servidor DHCP recuperada. El servidor -18- del controlador puede utilizar la informacion del servidor DHCP almacenada para responder a futuros paquetes de peticiones de DHCP. Por ejemplo, en respuesta a la recepcion de la respuesta -114- a la oferta del servidor DHCP desde el servidor S1 DHCP, el servidor -18- del controlador puede almacenar la direccion IP y la direccion MAC del servidor S1 DHCP (es decir, 192.168.1.100 y 10, respectivamente). En este escenario, el servidor -18- del controlador puede responder a futuras peticiones de obtencion de DHCP mediante el reenvio de las futuras
5
10
15
20
25
30
35
40
45
50
55
60
65
peticiones de obtencion de DHCP al servidor S1 DHCP (por ejemplo, debido a que el servidor S1 DHCP es conocido).
En respuesta a la recepcion de la respuesta -114- a la oferta del servidor DHCP desde el servidor S1 DHCP, la estacion final -EH1- puede responder con la peticion -116A- de oferta de DHCP de la figura 9D. La peticion -116A- de oferta de DHCP puede indicar que la estacion final -EH1- acepta la direccion IP que el servidor S1 DHCP le ofrecio a traves de la respuesta -114- a la oferta del servidor DHCP.
Tal como se muestra en la figura 9D, la peticion -116A- de oferta de DHCP puede incluir una direccion origen Ethernet (por ejemplo, la direccion MAC de la estacion final -EH1-), una direccion destino Ethernet, una direccion IP del servidor DHCP y una direccion IP de la estacion final. La direccion destino Ethernet puede ser una direccion de difusion general. La direccion IP del servidor DHCP puede ser la direccion IP del servidor DHCP que envio la respuesta -114- a la oferta del servidor DHCP. La estacion final -EH1- puede recuperar la direccion IP del servidor DHCP del campo de direccion IP origen de la respuesta 114- a la oferta del servidor DHCP -. La direccion IP de la estacion final puede ser la direccion IP ofrecida que esta siendo aceptada (por ejemplo, la direccion IP de la estacion final puede ser recuperada del campo de direccion IP ofrecida de la respuesta -114- a la oferta del servidor DHCP). La estacion final -EH1- puede enviar la peticion -116A- de oferta de DHCP al conmutador -SW1- del cliente y el conmutador -SW1- del cliente puede reenviar la peticion -116A- de oferta de DHCP al servidor -18- del controlador.
En respuesta a la recepcion de la peticion -116A- de oferta de DHCP, el servidor -18- del controlador puede crear el paquete de peticion -116B- de obtencion de DHCP modificado por el controlador de la figura 9E sustituyendo la direccion de difusion general por la direccion Ethernet del servidor S1 DHCP. El servidor -18- del controlador puede reenviar la peticion -116B- de obtencion de DHCP modificada por el controlador al servidor S1 DHCP en lugar del paquete de peticion -116A- de oferta de DHCP (por ejemplo, proporcionando entradas apropiadas de la tabla de flujo a los conmutadores del cliente).
En respuesta a la recepcion de la peticion -116B- de oferta de DHCP, el servidor S1 DHCP puede responder con la respuesta -118- de acuse de recibo de DHCP de la figura 9F. Tal como se muestra en la figura 9F, la respuesta -118- de acuse de recibo de DHCP puede incluir la misma direccion origen Ethernet que la establecida para la direccion de hardware del servidor S1 DHCP, y la misma direccion destino Ethernet que la establecida para la direccion de hardware de la estacion final -EH1-. La respuesta -118- de acuse de recibo de DHCP puede confirmar la asignacion de la direccion IP asignada a la estacion final -EH1- mediante un campo de tipo mensaje (por ejemplo, el tipo de mensaje puede ser “confirmar” o “acuse de recibo"). Si ya se ha generado una ruta de reenvio de paquetes, el conmutador -SW2- del cliente puede reenviar la respuesta -118- de acuse de recibo de DHCP a la estacion final -EH1-. Si no se ha generado ninguna ruta de reenvio de paquetes, el servidor -18- del controlador puede recibir una respuesta -118- de acuse de recibo de DHCP (por ejemplo, a traves del conmutador -SW2- del cliente) y reenviar la respuesta -118- de acuse de recibo de DHCP directamente a la estacion final -EH2-.
Los campos de paquete mostrados en las figuras 9A-9F son meramente ilustrativos. Si se desea, se pueden incluir otros campos de paquete tales como los campos de datos DHCP, los campos de cabecera IP, los campos de cabecera Ethernet, etc, en los paquetes DHCP tales como las peticiones de DHCP y las respuestas de DHCP. Por ejemplo, se pueden enviar paquetes DHCP utilizando el Protocolo de datagramas de usuario (UDP). En este escenario, los paquetes DHCP pueden incluir campos de cabecera UDP tales como las direcciones IP origen y destino. Los paquetes de peticion de DHCP de las estaciones finales a las que aun no se les ha asignado una direccion IP pueden incluir direcciones IP origen no validas, tales como 0.0.0.0. Los paquetes de respuesta de DHCP a las estaciones finales a las que aun no se les ha asignado una direccion IP pueden incluir direcciones IP de destino de difusion general tales como 255.255.255.255 o direcciones IP ofrecidas de estacion final.
La figura 10 muestra un diagrama ilustrativo de como puede el servidor -18- del controlador reenviar una peticion de DHCP (por ejemplo, la peticion -112- de obtencion de DHCP de la figura 9A o la peticion -116- de oferta de DHCP de la figura 9C) directamente desde la estacion final -EH1- al servidor S1 DHCP.
En la etapa -122-, la estacion final -EH1- puede enviar la peticion de DHCP al puerto A del conmutador -SW1- del cliente. La estacion final -EH1- puede indicar que la peticion de DHCP debe ser enviada por difusion general a traves de la red -100- (por ejemplo, proporcionando una direccion de difusion general en un campo de direccion destino Ethernet de la peticion de DHCP).
En la etapa -124-, el conmutador del cliente puede recibir la peticion de DHCP de la estacion final -EH1- y examinar una tabla de flujo correspondiente para determinar como procesar la peticion de DHCP. En respuesta a la determinacion de que no existe ninguna entrada de la tabla de flujo para la peticion de DHCP o que las entradas de la tabla de flujo ordenan al conmutador -SW1- del cliente que reenvie la peticion de DHCP al servidor -18- del controlador, el servidor -SW1- del cliente puede reenviar la peticion de DHCP al servidor -18- del controlador.
En la etapa -126-, el servidor -18- del controlador puede identificar un servidor DHCP apropiado. El servidor -18- del controlador puede identificar un servidor DHCP apropiado recuperando la information del servidor DHCP (por ejemplo, la direccion de red, la direccion de hardware, etc.) de una base de datos. El servidor -18- del controlador
5
10
15
20
25
30
35
40
45
50
55
60
65
puede crear una peticion modificada por el controlador (por ejemplo, la peticion -112B- de obtencion de DHCP modificada por el controlador de la figura 9B) utilizando la informacion recuperada del servidor DHCP.
En la etapa -128-, el servidor -18- del controlador puede crear una ruta de reenvio de paquetes proporcionando entradas de la tabla de flujo a los conmutadores del cliente que ordenan a los conmutadores de cliente reenviar la peticion de DHCP modificada por el controlador al servidor DHCP identificado. El servidor -18- del controlador puede proporcionar entradas de la tabla de flujo a los conmutadores -SW1-, -SW2- y -SW3- de cliente que ordenen al conmutador -SW1- de cliente reenviar la peticion de DHCP modificada por el controlador, del puerto A al puerto B, que ordenen al conmutador -SW3- del cliente a reenviar la peticion de DHCP modificada por el controlador desde el conmutador -SW1- de cliente al conmutador -SW2- de cliente, y que ordenen al conmutador -SW2- de cliente reenviar la peticion de DHCP modificada por el controlador, del puerto C al puerto D.
En la etapa -130-, la peticion de DHCP modificada por el controlador puede ser reenviada desde la estacion final -EH1- al servidor S1 DHCP a lo largo de la ruta de reenvio de paquetes a traves de los conmutadores. Por ejemplo, el servidor -18- del controlador puede proporcionar la peticion de DHCP modificada por el controlador al conmutador -SW1- de cliente y dar instrucciones al conmutador -SW1- de cliente para reenviar la peticion de DHCP modificada por el controlador a lo largo de la ruta de reenvio de paquetes.
Mediante la creacion de una ruta de reenvio de paquetes que reenvia paquetes directamente entre la estacion final -EH1- y el servidor S1 DHCP, el servidor -18- del controlador puede evitar la difusion general innecesaria de paquetes DHCP. Por ejemplo, el servidor -18- del controlador puede evitar que las peticiones de DHCP sean reenviadas por los conmutadores al servidor S2 DHCP, incluso aunque las peticiones puedan estar creadas por estaciones finales con direcciones destino Ethernet de difusion general.
El ejemplo de la figura 10 en el que el servidor -18- del controlador crea una ruta de reenvio de paquetes a traves de los conmutadores es meramente ilustrativo. Si se desea, el servidor -18- del controlador puede reenviar peticiones y/o respuestas de DHCP a traves del servidor -18- del controlador. Por ejemplo, el servidor -18- del controlador puede recibir la peticion -112- de obtencion de DHCP desde la estacion final -EH1-, enviar la peticion -112- de obtencion de DHCP al conmutador -SW2- del cliente (por ejemplo, a traves de las rutas -66- de red de la figura 8), y ordenar al conmutador -SW2- del cliente a reenviar la peticion 112- de obtencion de DHCP - al servidor S1 DHCP a traves del puerto D.
Las peticiones de DHCP tales como la peticion -112A- de obtencion de DHCP pueden ser enviadas por estaciones finales a servidores DHCP especificos. Por ejemplo, si una estacion final desea renovar una concesion (por ejemplo, debido a la expiracion de una duracion de una concesion), la estacion final puede enviar una peticion de obtencion de DHCP que esta destinada para un servidor DHCP determinado (por ejemplo, una peticion de obtencion de DHCP con una direccion IP destino especifica, en lugar de una direccion IP de difusion general). Si se desea, el servidor -18- del controlador puede ser configurado por un administrador de red para permitir que las peticiones de DHCP lleguen a servidores DHCP autorizados, y para impedir que peticiones de DHCP lleguen a servidores DHCP no autorizados. Los servidores DHCP autorizados pueden ser proporcionados por el administrador de red al servidor -18- del controlador como una lista de servidores DHCP autorizados. La lista de servidores DHCP autorizados puede ser almacenada en el almacenamiento -170- del servidor -18- del controlador. El servidor -18- del controlador puede estar configurado por el administrador de red en un modo estatico, en el que el servidor -18- del controlador permite peticiones basadas en la lista de servidores DHCP autorizados, y en un modo normal, en el que el servidor -18- del controlador permite todas las peticiones de DHCP con direcciones IP destino especificas.
Una red puede, en ocasiones, estar dividida en subredes (en ocasiones, denominadas subredes). Cada subred puede incluir un encaminador (por ejemplo, un sistema de reenvio de paquetes que reenvia paquetes en base a los campos de cabecera IP de los paquetes). Los encaminadores pueden, en ocasiones, denominarse conmutadores de tres capas. La figura 11 muestra una red -140- ilustrativa con subredes -142A- y -142B- que estan asociadas con los respectivos encaminadores -R1- y -R2-. La red -140- puede incluir conmutadores de cliente tales como -SW4- y -SW5- que estan controlados por el servidor -18- del controlador a traves de las rutas -66- de la red.
Cada subred puede estar asociada con un rango de direcciones IP. A los dispositivos de red en una subred determinada se les pueden asignar direcciones IP en el rango de direcciones IP correspondiente a dicha subred. La subred -142A- puede estar asociada con direcciones IP entre 192.168.1.0 y 192.168.1.255, mientras que la subred -142B- puede estar asociada con direcciones IP entre 192.168.2.0 y 192.168.2.255. A la estacion final -EH2- y al encaminador -R1-, que estan asociados con la subred -142A-, se les pueden asignar direcciones IP de 192.168.1.10 y 192.168.1.1 (por ejemplo, direcciones IP que estan dentro del rango correspondiente a la subred -142A-). Al servidor S3 DHCP y al encaminador -R2- que estan asociados con la subred -142B- se les pueden asignar direcciones IP de 192.168.2.100 y 192.168.2.1. Las direcciones IP de los encaminadores y los servidores DHCP pueden preconfigurarse (por ejemplo, por un administrador de red).
Cada encaminador puede reenviar paquetes entre una subred correspondiente y otras subredes. Los paquetes de red pueden ser reenviados por los encaminadores en base a los campos de cabecera IP tales como las direcciones IP destino. Por ejemplo, los paquetes de red enviados desde una estacion final en la subred -142A- con una
5
10
15
20
25
30
35
40
45
50
55
60
65
direccion IP destino asociada con la subred -142B- pueden ser reenviados desde el encaminador -R1- al encaminador -R2-.
Un servidor DHCP puede estar configurado para asignar direcciones IP a estaciones finales de varias subredes. No obstante, cada encaminador impide que los paquetes de red que tienen direcciones destino de difusion general alcancen subredes que no estan asociadas con el encaminador. Por ejemplo, el encaminador -R1- puede bloquear los paquetes de red Ethernet de difusion general que son enviados por la estacion final -EH1- para que no alcancen la subred -142B-. En algunos escenarios, los encaminadores pueden impedir que los paquetes de difusion general DHCP alcancen el servidor DHCP.
Por ejemplo, un paquete de una peticion de obtencion de DHCP que es difundido a nivel general por la estacion final -EH2- puede ser bloqueado por el encaminador -R1- antes de que alcance el servidor S3 DHCP (por ejemplo, debido a que todos los paquetes de red de la subred -142A- deben pasar a traves del encaminador -R1- para alcanzar la subred -142B-). En este escenario, el encaminador -R1- puede estar configurado con un agente de retransmision -144A- que convierte el paquete de peticion de obtencion de DHCP difundido a nivel general en un paquete de peticion de obtencion DHCP dirigido (por ejemplo, creando un paquete de red dirigido con una direccion IP origen que es la direccion IP del encaminador -R1- y con una direccion IP destino que es la direccion IP del servidor S3 DHCP). El paquete de obtencion de DHCP dirigido se puede denominar en ocasiones paquete IP de unidifusion, porque el paquete de obtencion de DHCP dirigido puede estar dirigido hacia una sola direccion IP destino.
El servidor -18- del controlador puede estar provisto de information relativa a los agentes de transmision en la red -140- (por ejemplo, un administrador de red puede proporcionar informacion relativa al agente de retransmision -144A- al servidor -18- del controlador). Para ayudar a reducir la carga de red debida a la difusion general de paquetes de DHCP (por ejemplo, debido a los conmutadores que difunden los paquetes de DHCP a traves de una subred correspondiente), el servidor -18- del controlador puede interceptar los paquetes de peticion de DHCP y convertir los paquetes de peticion de DHCP en paquetes de peticion de DHCP modificados que estan destinados a agentes de retransmision DHCP apropiados.
Se debe tener en cuenta el escenario en el que la estacion final -EH2- envia un paquete de peticion de obtencion de DHCP que solicita la asignacion de una direccion IP a la estacion final -EH2-. El conmutador -SW4- de cliente puede recibir el paquete de peticion de obtencion de DHCP y reenviar el paquete de peticion de obtencion de DHCP al servidor -18- del controlador. En respuesta a la reception del paquete de peticion de obtencion de DHCP, el servidor -18- del controlador puede crear una peticion -112C- de obtencion de DHCP modificada por el controlador mostrada en la figura 12.
Tal como se muestra en la figura 12, la peticion -112C- de obtencion de DHCP modificada por el controlador puede incluir una direccion origen Ethernet, una direccion destino Ethernet y una direccion de hardware de cliente. La direccion origen Ethernet y la direccion de hardware de cliente puede ser la direccion de hardware de la estacion final -EH2- (por ejemplo, la direccion MAC de la estacion final -EH2-). La direccion destino Ethernet puede ser la direccion de hardware del encaminador -R1- (por ejemplo, el encaminador asociado con el agente de retransmision -144A- que esta dentro de la misma subred que la estacion final -EH2-). El servidor -18- del controlador puede determinar la direccion Ethernet del agente de retransmision -144A- a partir de una base de datos proporcionada por un administrador del sistema.
Si se desea, el servidor -18- del controlador puede ser creado con un agente retransmision -144B- que proporciona al servidor -18- del controlador la capacidad de crear paquetes de peticion de DHCP modificados por el controlador que pueden ser reenviados entre las subredes. El agente de retransmision -144B- puede estar asociado con una direccion IP reservada (por ejemplo, 192.168.1.20) y una direccion MAC (por ejemplo, 10). Si se desea, el agente de retransmision -144B- puede estar creado en lugar del agente de retransmision -144A-, porque las funciones realizadas por el agente de retransmision -144A- pueden ser realizadas por un servidor del controlador con el agente de retransmision -144B-. La figura 13 muestra una peticion -112D- de obtencion de DHCP modificada por el controlador que puede ser creada por el servidor -18- del controlador que tiene un agente de retransmision -144B- en respuesta a un paquete de peticion de obtencion de DHCP enviado por la estacion final -EH2-.
Tal como se muestra en la figura 13, la peticion -112D- de obtencion de DHCP modificada por el controlador puede incluir direcciones Ethernet origen y destino, direcciones IP origen y destino, una direccion IP de puerta de enlace y una direccion de hardware de cliente. Las direcciones origen Ethernet e IP pueden ser la direccion MAC y la direccion IP del agente de retransmision -144B-. La direccion destino Ethernet puede ser la direccion Ethernet del encaminador -R1-. La direccion IP destino puede ser la direccion IP del servidor S3 DHCP. La direccion IP de puerta de enlace puede ser la direccion IP del agente de retransmision -144B-. La direccion de hardware de cliente puede ser la direccion de hardware de cliente de la estacion final -EH2-.
La figura 14 muestra etapas ilustrativas implicadas en la utilization del servidor -18- del controlador que tiene un agente de retransmision -144B- correspondiente para generar paquetes de peticion de DHCP modificados por el
5
10
15
20
25
30
35
40
45
50
55
60
65
controlador, tales como el paquete de peticion -112D- modificado por el controlador que puede ser reenviado entre subredes.
En la etapa -152-, la estacion final -EH2- puede enviar un paquete de peticion de DHCP que solicita la asignacion de una direccion IP a la estacion final -EH2- (por ejemplo, un paquete de peticion -112A- de obtencion de DHCP con una direccion origen Ethernet de 2). En la etapa -154-, el conmutador -SW4- puede reenviar el paquete de peticion de DHCP al servidor -18- del controlador.
En la etapa -156-, el servidor -18- del controlador puede recibir el paquete de peticion de DHCP y crear un paquete de peticion modificado por el controlador utilizando informacion tal como informacion de direccion IP del agente de retransmision -144B-. Por ejemplo, el servidor -18- del controlador puede crear el paquete de peticion modificado por el controlador de la figura 12 con campos de cabecera de paquete adicionales que identifican una direccion IP origen correspondiente al agente de retransmision -144B- (por ejemplo, 192.168.1.20) y una direccion IP destino que corresponde al servidor S3 DHCP (por ejemplo, 192.168.2.100). Al crear el paquete de peticion de DHCP modificado por el controlador con informacion del agente de retransmision apropiada e informacion de direccion IP, el servidor -18- del controlador puede proporcionar informacion de encaminamiento apropiada a los encaminadores -R1- y -R2- (por ejemplo, porque los encaminadores -R1- y -R2- reenvian paquetes de red en base a la informacion de direccion IP).
En la etapa -158-, el servidor -18- del controlador puede enviar el paquete de peticion de DHCP modificado por el controlador y entradas apropiadas de la tabla de flujo al conmutador -SW4-. El conmutador -SW4 puede reenviar el paquete de peticion de DHCP modificado por el controlador a lo largo de una ruta de reenvio de paquetes apropiada (por ejemplo, utilizando las entradas de la tabla de flujo).
En la etapa -160- el paquete de peticion de DHCP modificado por el controlador puede ser reenviado a traves de la ruta de reenvio de paquetes (por ejemplo, a traves de los encaminadores -R1- y -R2- y el conmutador -SW5-) al servidor S3 DHCP. El servidor S3 DHCP puede recuperar la direccion de hardware de la estacion final -EH2- y la direccion IP del agente de retransmision -144B- (por ejemplo, del campo de direccion de hardware de cliente y del campo de direccion IP de puerta de enlace) y asignar una direccion IP apropiada a la estacion final -EH2- en base a la informacion recuperada.
La figura 15 muestra un diagrama de flujo de etapas ilustrativas que pueden ser realizadas por el servidor -18- del controlador para gestionar peticiones para las asignaciones de direcciones de red en una red.
En la etapa -202-, el servidor -18- del controlador puede recibir un nuevo paquete de una estacion final. Por ejemplo, el nuevo paquete puede ser reenviado por un conmutador de cliente de una estacion final al servidor -18- del controlador. El servidor -18- del controlador puede identificar un tipo de paquete (por ejemplo, si el paquete es o no una peticion de DHCP, una respuesta de DHCP u otros tipos de paquetes). Para identificar el tipo del paquete, el servidor -18- del controlador puede recuperar la informacion de paquete de los campos de cabecera del paquete (por ejemplo, campos de cabecera de Ethernet, campos de cabecera IP, etc.).
En respuesta a la identificacion de que el paquete no esta asociado con el DHCP (por ejemplo, que el paquete es un paquete no DHCP), el servidor -18- del controlador puede realizar las operaciones de la etapa -204-. En respuesta a la identificacion de que el paquete es un paquete de peticion de DHCP, el servidor -18- del controlador puede realizar las operaciones de la etapa -206-. En respuesta a la identificacion de que el paquete es un paquete de respuesta de DHCP, el servidor -18- del controlador puede realizar las operaciones de la etapa -210-.
En la etapa -204-, el servidor -18- del controlador puede procesar el paquete con normalidad. Por ejemplo, el servidor -18- del controlador puede crear una ruta de reenvio de paquetes para el paquete para reenviarlo entre origenes de paquete y destinos de paquete (por ejemplo, si el paquete tiene una direccion IP destino especifica). Como ejemplo adicional, el servidor -18- del controlador puede ordenar a los conmutadores de cliente a difundir a nivel general el paquete (por ejemplo, si el paquete tiene una direccion IP destino de difusion general).
En la etapa -206-, el servidor -18- del controlador puede identificar un servidor DHCP apropiado para cumplimentar el paquete de peticion de DHCP. El servidor -18- del controlador puede identificar el servidor DHCP apropiado recuperando la informacion del servidor DHCP de una base de datos o de otras formas de almacenamiento. Por ejemplo, el servidor -18- del controlador puede utilizar direcciones de hardware y de red almacenadas en una base de datos para identificar un servidor DHCP apropiado. Si el servidor -18- del controlador no puede identificar un servidor DHCP apropiado, se pueden realizar las operaciones de la etapa -204- para difundir a nivel general la peticion de DHCP en toda la red. Si el servidor del controlador puede identificar un servidor DHCP apropiado, se pueden realizar las operaciones de la etapa -208-.
En la etapa -208-, el servidor -18- del controlador puede crear un paquete de DHCP modificado por el controlador a partir de la peticion de DHCP utilizando informacion recuperada para el servidor DHCP identificado. Por ejemplo, el servidor -18- del controlador puede crear la peticion -116B- de oferta de DHCP modificada por el controlador a partir
5
10
15
20
25
30
35
40
45
50
55
60
65
de la peticion -116A- de oferta de DHCP reemplazando la direccion destino Ethernet de difusion general de la peticion -116A- de oferta de DHCP con la direccion de hardware del servidor DHCP identificado.
El servidor -18- del controlador puede reenviar el paquete de DHCP modificado por el controlador directamente al servidor DHCP identificado. Por ejemplo, el servidor -18- del controlador puede proporcionar entradas de la tabla de flujo a los conmutadores del cliente para crear una ruta de reenvio de paquetes entre la estacion final y el servidor DHCP identificado. Como ejemplo adicional, el servidor -18- del controlador puede reenviar el paquete de peticion de DHCP a traves del servidor -18- del controlador a un conmutador de cliente conectado al servidor DHCP, y dar instrucciones al conmutador de cliente para reenviar el paquete de peticion de DHCP al servidor DHCP identificado. El proceso puede, entonces, opcionalmente, volver a la etapa -202- a traves de la ruta -220- para procesar nuevos paquetes de estaciones finales.
En la etapa -210- el servidor -18- del controlador puede identificar un modo de funcionamiento. Los modos de funcionamientos pueden incluir un modo estatico y un modo normal. En otras palabras, el servidor -18- del controlador puede determinar si el servidor del controlador esta configurado en un modo estatico o en un modo normal. El modo normal puede en ocasiones denominarse modo de inundacion o de reenvio. El modo de funcionamiento puede configurarse por un administrador de red. En respuesta a la determinacion de que el servidor -18- del controlador esta configurado en un modo normal, se pueden realizar las operaciones de la etapa -202-. En respuesta a la determinacion de que el servidor -18- del controlador esta configurado en un modo estatico, se pueden realizar las operaciones de la etapa -216-.
En la etapa -212-, el servidor -18- del controlador puede almacenar informacion del servidor DHCP que envio el paquete de respuesta de DHCP. La informacion almacenada puede incluir informacion de direcciones de red y hardware asociadas con el servidor DHCP (por ejemplo, informacion de direccion IP, informacion de direccion Ethernet, etc.). La informacion almacenada puede, por ejemplo, almacenarse en una base de datos en el servidor -18- del controlador y puede ser recuperada en la etapa -206- para identificar servidores DHCP apropiados para cumplimentar peticiones de DHCP futuras.
En la etapa -214-, el servidor -18- del controlador puede reenviar el paquete de respuesta de DHCP directamente a una estacion final destino. El servidor -18- del controlador puede recuperar la informacion de la estacion final de destino de los campos de cabecera del paquete de respuesta de DHCP. Por ejemplo, el servidor -18- del controlador puede identificar la estacion final de destino de una direccion de hardware recuperada de un campo de direccion destino Ethernet del paquete de respuesta de DHCP. El servidor -18- del controlador puede reenviar el paquete de respuesta de DHCP proporcionando entradas adecuadas de la tabla de flujo a los conmutadores del cliente para encaminar el paquete del servidor DHCP que envio el paquete de respuesta a la estacion final de destino. Si se desea, el paquete de respuesta de DHCP puede ser reenviado a traves del servidor del controlador (por ejemplo, reenviado por el servidor del controlador directamente a un conmutador del cliente conectado a la estacion final de destino). El proceso puede volver, a continuacion, a la etapa -202- a traves de la ruta -220- para procesar nuevos paquetes de estaciones finales.
En la etapa -216-, el servidor -18- del controlador puede identificar si el servidor DHCP que envio el paquete de respuesta de DHCP esta autorizado a enviar respuestas de DHCP. Por ejemplo, el servidor -18- del controlador puede haber sido configurado por un administrador de red con una lista de servidores DHCP autorizados. En este escenario, el servidor -18- del controlador puede comparar atributos (por ejemplo, direcciones IP, direcciones de hardware, etc.) del servidor DHCP con entradas en la lista de servidores DHCP autorizados. Si se encuentra una coincidencia, el servidor -18- del controlador puede determinar que el servidor DHCP esta autorizado a enviar respuestas de DHCP y se pueden realizar las operaciones de la etapa -212-. Si no se encuentra ninguna coincidencia, el servidor -18- del controlador puede determinar que el servidor DHCP no esta autorizado a enviar respuestas de DHCP y se pueden realizar las operaciones de la etapa -218-.
En la etapa -218-, el servidor -18- del controlador puede descartar el paquete de respuesta de DHCP (por ejemplo, de tal manera que el paquete de respuesta de DHCP no se reenvia a una estacion final destino). El proceso, a continuacion, puede volver a la etapa -202- a traves de la ruta -220- para procesar nuevos paquetes de estaciones finales.
La utilizacion de uno o mas controladores centralizados, tales como el servidor -18- del controlador, para controlar conmutadores de red es meramente ilustrativa. Si se desea, se puede utilizar cualquier tipo de controlador (por ejemplo, un controlador implementado en un equipo informatico) que controle una red de sistemas de reenvio de paquetes, para procesar paquetes de red tales como peticiones de DHCP (por ejemplo, para realizar las etapas del diagrama de flujo de la figura 15).
Las operaciones de la etapa -208- se pueden llevar a cabo en base a la informacion de la topologia de red. Por ejemplo, el servidor -18- del controlador puede reunir informacion de la topologia de red relativa a la particion de la red en subredes y sus respectivos rangos de direcciones IP. Como ejemplo adicional, un administrador de la red puede proporcionar al servidor -18- del controlador informacion de la topologia de red. La figura 16 muestra un diagrama de flujo de etapas ilustrativas que pueden ser llevadas a cabo por el servidor -18- del controlador utilizando
5
10
15
20
25
30
35
40
45
50
55
60
65
la informacion de la topologla de red para crear un paquete de peticion de obtencion de DHCP modificado por el controlador y reenviar el paquete de peticion de obtencion de DHCP modificado por el controlador a un servidor DHCP identificado. Las etapas ilustrativas de la figura 16 pueden ser llevadas a cabo como parte de la etapa -208- de la figura 15.
En la etapa -232-, el servidor -18- del controlador puede determinar si un servidor DHCP identificado o un agente de retransmision de DHCP (por ejemplo, un servidor DHCP identificado en la etapa -206- de la figura 15) esta en la misma subred que la estacion final que envio la peticion de DHCP. Por ejemplo, el servidor -18- del controlador puede utilizar informacion de la topologia de red recuperada del almacenamiento tal como el almacenamiento -170- del servidor -18- del controlador para identificar si la estacion final esta en la misma subred que el servidor DHCP. Si el servidor -18- del controlador determina que la estacion final esta asociada con una subred diferente a la del servidor DHCP, el procedimiento puede realizar las operaciones de la etapa -234-. Si el servidor -18- del controlador determina que la estacion final esta asociada con la misma subred que el servidor DHCP, el procedimiento puede realizar las operaciones de la etapa -236-.
En la etapa -234-, el servidor -18- del controlador puede crear un paquete de peticion de DHCP modificado por el controlador con campos de direccion IP de puerta de entrada y con campos de cabecera IP apropiados (por ejemplo, para convertir el paquete de peticion de DHCP en un paquete IP unidifusion). Para determinar la direccion IP de la puerta de enlace apropiada, el servidor -18- del controlador puede utilizar informacion de la topologia de red e informacion del agente de retransmision. Por ejemplo, el servidor -18- del controlador puede configurarse con un agente de retransmision que tiene unas direcciones IP y MAC correspondientes. En este escenario, el servidor -18- del controlador puede crear el paquete modificado mediante un controlador con la informacion de direccion del agente de retransmision. Si se desea, el servidor -18- del controlador puede recuperar la informacion de direccion de hardware del agente de retransmision de la base de datos y crear el paquete modificado por el controlador con la informacion de direccion recuperada.
Los campos de la cabecera IP pueden ser proporcionados por el servidor -18- del controlador, de tal manera que los encaminadores que reciben el paquete de peticion de DHCP modificado por el controlador encaminan correctamente el paquete al servidor DHCP (por ejemplo, debido a que el campo de direccion IP destino puede ser ajustado a la direccion IP del servidor DHCP).
En la etapa -236-, el servidor -18- del controlador puede crear un paquete de peticion de DHCP modificado por el controlador sin una direccion IP de puerta de enlace (por ejemplo, proporcionando una direccion IP de puerta de enlace de 0.0.0.0). Como ejemplo, el servidor -18- del controlador puede crear la peticion -112B- de obtencion de DHCP modificada por el controlador de la figura 9A.
En la etapa -238-, el servidor -18- del controlador puede reenviar el paquete de peticion de DHCP modificado por el controlador creado en cualquiera de las etapas -234- o -236- al servidor DHCP o al agente de retransmision de DHCP (por ejemplo, proporcionando a los conmutadores de cliente en la red reglas apropiadas de reenvio de paquetes, o reenviando el paquete de peticion de DHCP modificado por el controlador). El procedimiento puede entonces volver a la etapa -202- de la figura 15, para procesar nuevos paquetes recibidos de las estaciones finales.
La figura 17 muestra un ejemplo ilustrativo en el que los controladores -302- pueden estar distribuidos en los conmutadores -14- a lo largo de la red -300-. Los controladores -302- pueden estar distribuidos en algunos o en todos los conmutadores -14- de la red. Los clientes de controlador tales como el cliente -30- del controlador se pueden comunicar con uno o varios de los controladores -302- a traves de los enlaces de comunicaciones de red (por ejemplo, los controladores -302- pueden enviar instrucciones al cliente -30- del controlador a traves de los enlaces de comunicaciones). Los controladores -302- se pueden comunicar entre si para controlar conjuntamente los conmutadores -14- o pueden controlar individualmente los conmutadores -14-.
Como ejemplo, los controladores -302- pueden controlar conjuntamente la red -300- comunicandose entre si. Los controladores -302- pueden compartir informacion relativa a la topologia de red, al trafico de red, a las estaciones finales conectadas a los conmutadores -14-, etc. Al compartir la informacion de la red, los conmutadores -302- pueden reunir la informacion del servidor DHCP y utilizar la informacion del servidor DHCP para procesar paquetes de DHCP.
De acuerdo con una realizacion, un procedimiento para la utilizacion de un controlador para controlar el trafico de red a traves de conmutadores de red, el procedimiento esta previsto de modo que incluye identificar con el controlador si un paquete de red enviado desde una estacion final es un paquete de difusion general del Protocolo de configuracion dinamica de estaciones; y, en respuesta a la identification de que el paquete de red es un paquete de difusion general del Protocolo de configuracion dinamica de estaciones, modificar el paquete de red con el controlador.
Segun otra realizacion, la modification del paquete de red incluye modificar un campo de direccion destino del paquete de red.
5
10
15
20
25
30
Segun otra realizacion, el procedimiento incluye recuperar informacion de direccion de un servidor del Protocolo de configuracion dinamica de estaciones de una base de datos, modificando el campo de direccion de destino del paquete de red, lo que incluye almacenar informacion de la direccion del servidor del Protocolo de configuracion dinamica de estaciones en el campo de direccion de destino.
Segun una realizacion, un procedimiento para controlar el trafico en una red de conmutadores, el procedimiento esta previsto que incluya, recibir un paquete de peticion del Protocolo de configuracion dinamica de estaciones con el controlador, que es enviado desde una estacion final; y en base a la informacion de topologla de red asociada con la red de conmutadores, modificar el paquete de peticion del Protocolo de configuracion dinamica de estaciones con el controlador.
Segun otra realizacion, la red esta dividida en subredes asociadas con respectivos rangos de direccion y en la que la estacion final esta asociada con una subred determinada, el procedimiento incluye ademas identificar con el controlador un servidor para cumplimentar el paquete de peticion del Protocolo de configuracion dinamica de estaciones, identificar con el controlador si el servidor esta asociado con la subred determinada en base a la informacion de topologia de red; en respuesta a la identificacion de que el servidor esta asociado con la subred dada, modificar un campo de direccion Ethernet del paquete de peticion del Protocolo de configuracion dinamica de estaciones; y, en respuesta a la identificacion de que el servidor no esta asociado con la subred determinada, modificar un campo de direccion del Protocolo de Internet del paquete de peticion del Protocolo de configuracion dinamica de estaciones.
Segun otra realizacion, identificar si el servidor esta asociado con la subred incluye comparar una direccion del Protocolo de Internet del servidor con un rango de direcciones de la subred determinada.
Segun otra realizacion, modificar el campo de direccion del Protocolo de Internet del paquete de peticion del Protocolo de configuracion dinamica de estaciones incluye modificar un campo de direccion del Protocolo de Internet de la puerta de enlace del paquete de peticion del Protocolo de configuracion dinamica de estaciones.
Lo anterior es meramente ilustrativo del espiritu de esta invencion, y los expertos en la materia pueden realizar varias modificaciones sin apartarse del alcance de la invencion.

Claims (7)

  1. 5
    10
    15
    20
    25
    30
    35
    40
    45
    50
    REIVINDICACIONES
    1. Procedimiento de utilizacion de un controlador (18) para controlar conmutadores en una red, comprendiendo el procedimiento:
    controlar con el controlador (18), los conmutadores de la red proporcionando reglas de reenvio de paquetes a los conmutadores;
    identificar (202) con el controlador (18), si un paquete de red que se ha enviado desde una estacion final esta solicitando la asignacion de una direccion de protocolo para la estacion final;
    en respuesta a identificar que el paquete de red solicita la asignacion de una direccion de protocolo para la estacion final, procesar el paquete de red con el controlador (18); y
    controlar con el controlador (18), los conmutadores proporcionando al menos a uno de los conmutadores el paquete de red que ha sido procesado por el controlador, en el que el procesamiento del paquete de red con el controlador comprende:
    identificar (206) con el controlador, un servidor que tiene capacidades de asignacion de direcciones de protocolo; y
    reenviar (208) con el controlador (18), el paquete de red al servidor, estando el procedimiento caracterizado porque el reenvio del paquete de red al servidor comprende proporcionar reglas de reenvio de paquetes a los conmutadores que ordenan los conmutadores a reenviar el paquete de red de la estacion final al servidor.
  2. 2. Procedimiento, segun la reivindicacion 1, en el que la identificacion (202) de que el paquete de red esta solicitando la asignacion de una direccion de protocolo a la estacion final comprende:
    recuperar la information de los campos de cabecera de paquete del paquete de red.
  3. 3. Procedimiento, segun la reivindicacion1, en el que la identificacion (202) de que el paquete de red esta solicitando la asignacion de una direccion de protocolo a la estacion final comprende:
    identificar que el paquete de red es una petition del Protocolo de configuration dinamica de estaciones.
  4. 4. Procedimiento, segun la reivindicacion 1, en el que la identificacion (206) de que el servidor tiene capacidades de asignacion de direcciones de protocolo comprende:
    seleccionar un servidor del Protocolo de configuracion dinamica de estaciones de una base de datos.
  5. 5. Procedimiento, segun la reivindicacion 1, en el que el reenvio (208) del paquete de red al servidor comprende reenviar el paquete de red a traves del controlador (18) a un conmutador conectado al servidor.
  6. 6. Procedimiento, segun la reivindicacion 1, en el que el procesamiento del paquete de red con el controlador (18) comprende, ademas:
    crear un paquete modificado, modificando al menos un campo de cabecera del paquete de red, en el que el reenvio del paquete de red al servidor comprende reenviar el paquete modificado al servidor.
  7. 7. Procedimiento, segun la reivindicacion 6, en el que la modification de al menos un campo de cabecera del paquete de red comprende:
    modificar al menos un campo de direccion Ethernet del paquete de red.
ES12775587.4T 2011-10-14 2012-10-04 Procedimiento para la gestion de asignacion de direccion de protocolo de red con un controlador Active ES2602818T3 (es)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US13/274,157 US8856384B2 (en) 2011-10-14 2011-10-14 System and methods for managing network protocol address assignment with a controller
US201113274157 2011-10-14
PCT/US2012/058601 WO2013055555A1 (en) 2011-10-14 2012-10-04 System and methods for managing network protocol address assignment with a controller

Publications (1)

Publication Number Publication Date
ES2602818T3 true ES2602818T3 (es) 2017-02-22

Family

ID=47049373

Family Applications (1)

Application Number Title Priority Date Filing Date
ES12775587.4T Active ES2602818T3 (es) 2011-10-14 2012-10-04 Procedimiento para la gestion de asignacion de direccion de protocolo de red con un controlador

Country Status (5)

Country Link
US (1) US8856384B2 (es)
EP (1) EP2749011B1 (es)
JP (1) JP5813885B2 (es)
ES (1) ES2602818T3 (es)
WO (1) WO2013055555A1 (es)

Families Citing this family (49)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8856384B2 (en) * 2011-10-14 2014-10-07 Big Switch Networks, Inc. System and methods for managing network protocol address assignment with a controller
US8644149B2 (en) * 2011-11-22 2014-02-04 Telefonaktiebolaget L M Ericsson (Publ) Mechanism for packet forwarding using switch pools in flow-based, split-architecture networks
KR20130093734A (ko) * 2011-12-26 2013-08-23 한국전자통신연구원 로드 밸런싱 장치 및 그것의 로드 밸런싱 방법
US9426067B2 (en) * 2012-06-12 2016-08-23 International Business Machines Corporation Integrated switch for dynamic orchestration of traffic
US9049114B2 (en) 2012-08-31 2015-06-02 Cisco Technology, Inc. Network access device and method for automatically establishing connection to a wide area network
CN103973828B (zh) * 2013-02-01 2017-07-14 华为技术有限公司 一种dhcp客户端获取ip地址的方法及装置
US9008080B1 (en) * 2013-02-25 2015-04-14 Big Switch Networks, Inc. Systems and methods for controlling switches to monitor network traffic
FR3009162B1 (fr) * 2013-07-24 2016-11-04 Bull Sas Procede et dispositif de controle de la transmission de trames par remplacement de l'adresse point a multipoints par une adresse point a point
US9742639B1 (en) * 2013-08-20 2017-08-22 Cavirin Systems, Inc. Intelligent network resource discovery and monitoring
WO2015061706A1 (en) * 2013-10-24 2015-04-30 University Of Houston System Location-based network routing
US9825857B2 (en) 2013-11-05 2017-11-21 Cisco Technology, Inc. Method for increasing Layer-3 longest prefix match scale
US9876711B2 (en) 2013-11-05 2018-01-23 Cisco Technology, Inc. Source address translation in overlay networks
US9655232B2 (en) 2013-11-05 2017-05-16 Cisco Technology, Inc. Spanning tree protocol (STP) optimization techniques
US9397946B1 (en) 2013-11-05 2016-07-19 Cisco Technology, Inc. Forwarding to clusters of service nodes
US10778584B2 (en) 2013-11-05 2020-09-15 Cisco Technology, Inc. System and method for multi-path load balancing in network fabrics
US10951522B2 (en) 2013-11-05 2021-03-16 Cisco Technology, Inc. IP-based forwarding of bridged and routed IP packets and unicast ARP
US9674086B2 (en) 2013-11-05 2017-06-06 Cisco Technology, Inc. Work conserving schedular based on ranking
US9374294B1 (en) 2013-11-05 2016-06-21 Cisco Technology, Inc. On-demand learning in overlay networks
US9502111B2 (en) 2013-11-05 2016-11-22 Cisco Technology, Inc. Weighted equal cost multipath routing
US9769078B2 (en) 2013-11-05 2017-09-19 Cisco Technology, Inc. Dynamic flowlet prioritization
US9509092B2 (en) 2013-11-06 2016-11-29 Cisco Technology, Inc. System and apparatus for network device heat management
JP6228822B2 (ja) * 2013-11-21 2017-11-08 株式会社日立製作所 ネットワーク管理制御装置、ネットワーク管理制御システム、及びネットワーク管理制御方法
US9600263B2 (en) * 2014-07-21 2017-03-21 Big Switch Networks, Inc. Systems and methods for performing uninterrupted network upgrades with controllers
US9853938B2 (en) * 2014-09-08 2017-12-26 Quanta Computer Inc. Automatic generation of server network topology
EP3202099A1 (en) * 2014-09-30 2017-08-09 Sercel Method for dynamically configuring a network comprising a plurality of subnets
US9544270B2 (en) * 2014-10-01 2017-01-10 The Boeing Company Universal DHCP helpers
US10116493B2 (en) 2014-11-21 2018-10-30 Cisco Technology, Inc. Recovering from virtual port channel peer failure
US20180007075A1 (en) * 2015-02-12 2018-01-04 Hewlett Packard Enterprise Development Lp Monitoring dynamic device configuration protocol offers to determine anomaly
CN104980302B (zh) * 2015-05-12 2018-06-19 上海斐讯数据通信技术有限公司 一种在sdn框架下基于stp消除冗余链路的方法
US10142163B2 (en) 2016-03-07 2018-11-27 Cisco Technology, Inc BFD over VxLAN on vPC uplinks
CN107295113B (zh) * 2016-03-31 2020-08-25 华为技术有限公司 一种网络配置的方法、交换机和服务器
US10333828B2 (en) 2016-05-31 2019-06-25 Cisco Technology, Inc. Bidirectional multicasting over virtual port channel
US11509501B2 (en) 2016-07-20 2022-11-22 Cisco Technology, Inc. Automatic port verification and policy application for rogue devices
US10193750B2 (en) 2016-09-07 2019-01-29 Cisco Technology, Inc. Managing virtual port channel switch peers from software-defined network controller
US10432578B2 (en) 2016-09-27 2019-10-01 Cisco Technology, Inc. Client address based forwarding of dynamic host configuration protocol response packets
US10313259B2 (en) 2016-12-09 2019-06-04 Vmware, Inc. Suppressing broadcasts in cloud environments
US10547509B2 (en) 2017-06-19 2020-01-28 Cisco Technology, Inc. Validation of a virtual port channel (VPC) endpoint in the network fabric
US10454882B2 (en) 2017-06-30 2019-10-22 Cisco Technology, Inc. DHCP in layer-3 overlay with anycast address support and network address transparency
US10797959B2 (en) * 2017-08-11 2020-10-06 Quanta Computer Inc. LLDP based rack management controller
EP3461081A1 (de) * 2017-09-22 2019-03-27 Siemens Aktiengesellschaft Verfahren zum betrieb eines mehrere kommunikationsgeräte umfassenden kommunikationsnetzes eines industriellen automatisierungssystems, steuerungseinheit und kommunikationsgerät
WO2019113728A1 (zh) 2017-12-11 2019-06-20 华为技术有限公司 一种网络及网络管理方法
US11888899B2 (en) * 2018-01-24 2024-01-30 Nicira, Inc. Flow-based forwarding element configuration
JP7073841B2 (ja) * 2018-03-28 2022-05-24 株式会社リコー 情報処理装置、パケット中継方法
US10819679B2 (en) * 2018-05-02 2020-10-27 Ciena Corporation Zero touch provisioning of a network element through a network address translation gateway
US11102074B2 (en) * 2019-01-11 2021-08-24 Cisco Technology, Inc. Software defined access fabric without subnet restriction to a virtual network
US20210400015A1 (en) * 2019-01-17 2021-12-23 Hewlett Packard Enterprise Development Lp Short-term lease allocation for network address conflict reduction in dhcp failover deployments
JP7218613B2 (ja) * 2019-02-27 2023-02-07 沖電気工業株式会社 通信装置および通信方法
US11356330B2 (en) * 2019-02-27 2022-06-07 Oki Electric Industry Co., Ltd. Communication device and communication method
CN113132505A (zh) * 2020-01-10 2021-07-16 华为技术有限公司 发送应答报文的方法、装置、计算设备和存储介质

Family Cites Families (38)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3654554B2 (ja) 1997-11-21 2005-06-02 株式会社小松製作所 ネットワークシステム及びｄｈｃｐサーバ選択方法
US6640251B1 (en) 1999-03-12 2003-10-28 Nortel Networks Limited Multicast-enabled address resolution protocol (ME-ARP)
US7318089B1 (en) 1999-09-30 2008-01-08 Intel Corporation Method and apparatus for performing network-based control functions on an alert-enabled managed client
US7231660B1 (en) 1999-11-25 2007-06-12 International Business Machines Corporation Method and system for preventing unauthorized server interference in an internet protocol network
WO2002061599A1 (en) 2001-01-25 2002-08-08 Crescent Networks, Inc. Extension of address resolution protocol (arp) for internet protocol (ip) virtual networks
JP4001820B2 (ja) * 2001-03-08 2007-10-31 ブリティッシュ・テレコミュニケーションズ・パブリック・リミテッド・カンパニー アドレス変換器
US7072354B1 (en) 2001-10-03 2006-07-04 Cisco Technology, Inc. Token registration of managed devices
WO2003037009A1 (en) 2001-10-23 2003-05-01 Meshnetworks, Inc. System and method for providing a congestion optimized address resolution protocol for wireless ad-hoc networks
US7213065B2 (en) * 2001-11-08 2007-05-01 Racemi, Inc. System and method for dynamic server allocation and provisioning
US7337224B1 (en) 2002-10-24 2008-02-26 Cisco Technology, Inc. Method and apparatus providing policy-based determination of network addresses
US7386629B2 (en) * 2003-06-30 2008-06-10 Intel Corporation System and method for synchronous configuration of DHCP server and router interfaces
JP3838437B2 (ja) * 2003-09-26 2006-10-25 日本電気株式会社 ネットワークスイッチ及びその動作方法、並びにブレードサーバ
JP2006020085A (ja) 2004-07-01 2006-01-19 Fujitsu Ltd ネットワークシステム、ネットワークブリッジ装置、ネットワーク管理装置およびネットワークアドレス解決方法
US7920577B2 (en) * 2004-07-08 2011-04-05 Avaya Communication Israel Ltd. Power saving in wireless packet based networks
US7729284B2 (en) * 2005-01-19 2010-06-01 Emulex Design & Manufacturing Corporation Discovery and configuration of devices across an Ethernet interface
DE102005006889B4 (de) * 2005-02-15 2007-01-11 Siemens Ag Verfahren, Kommunikationsanordnung und Kommunikationsvorrichtung zum Einrichten einer Kommunikationsbeziehung in zumindest einem Kommunikationsnetz
US7756976B2 (en) 2005-03-18 2010-07-13 Hewlett-Packard Development Company, L.P. Systems and methods for denying rogue DHCP services
US7937494B2 (en) 2005-09-01 2011-05-03 Cisco Technology, Inc. Methods and apparatus for processing a DHCP request using rule-based classification
EP1780943A1 (en) 2005-10-31 2007-05-02 Hewlett-Packard Development Company, L.P. Discovery of ISO Layer-2 Topology
US8966018B2 (en) * 2006-05-19 2015-02-24 Trapeze Networks, Inc. Automated network device configuration and network deployment
US20070286209A1 (en) 2006-06-12 2007-12-13 Research In Motion Limited System and method for handling address resolution protocol requests
JP4882555B2 (ja) 2006-07-07 2012-02-22 双葉電子工業株式会社 無線ブリッジ通信機
JP2008028914A (ja) * 2006-07-25 2008-02-07 Nec Corp 通信負荷低減装置、通信負荷低減方法、及びプログラム
US20080063002A1 (en) * 2006-09-11 2008-03-13 3Dsp Corporation Multi-gateway system and methods for same
US20080101381A1 (en) 2006-10-25 2008-05-01 Mediatek Inc. Address resolution protocol (arp) cache management methods and devices
US20080189769A1 (en) 2007-02-01 2008-08-07 Martin Casado Secure network switching infrastructure
US9419867B2 (en) 2007-03-30 2016-08-16 Blue Coat Systems, Inc. Data and control plane architecture for network application traffic management device
EP2193630B1 (en) * 2007-09-26 2015-08-26 Nicira, Inc. Network operating system for managing and securing networks
US8099764B2 (en) * 2007-12-17 2012-01-17 Microsoft Corporation Secure push and status communication between client and server
WO2009140625A1 (en) 2008-05-15 2009-11-19 Harris Stratex Networks Operating Corporation Systems and methods for distributed data routing in a wireless network
US8238315B2 (en) * 2008-09-16 2012-08-07 Marvell World Trade Ltd. Rapid local address assignment for wireless communication networks
KR101352852B1 (ko) 2008-09-30 2014-01-20 삼성전자주식회사 Ｄｈｃｐ를 이용한 화상형성장치의 ｉｐ 주소 할당 방법, 그 화상형성장치, 및 ｄｈｃｐ를 이용한 ｉｐ주소 할당 시스템
US8588082B2 (en) 2009-09-23 2013-11-19 Ixia Network testing using control plane and data plane convergence
US20130268801A1 (en) * 2010-12-10 2013-10-10 Nec Corporation Server management apparatus, server management method, and program
US20130024553A1 (en) * 2011-07-18 2013-01-24 Cisco Technology, Inc. Location independent dynamic IP address assignment
US8971334B2 (en) 2011-08-02 2015-03-03 Telefonaktiebolaget L M Ericsson (Publ) Packet broadcast mechanism in a split architecture network
US9250941B2 (en) * 2011-09-30 2016-02-02 Telefonaktiebolaget L M Ericsson (Publ) Apparatus and method for segregating tenant specific data when using MPLS in openflow-enabled cloud computing
US8856384B2 (en) * 2011-10-14 2014-10-07 Big Switch Networks, Inc. System and methods for managing network protocol address assignment with a controller

Also Published As

Publication number Publication date
EP2749011B1 (en) 2016-08-10
JP5813885B2 (ja) 2015-11-17
WO2013055555A1 (en) 2013-04-18
US20130097335A1 (en) 2013-04-18
EP2749011A1 (en) 2014-07-02
JP2014532373A (ja) 2014-12-04
US8856384B2 (en) 2014-10-07

Similar Documents

Publication Publication Date Title
ES2602818T3 (es) Procedimiento para la gestion de asignacion de direccion de protocolo de red con un controlador
US8923296B2 (en) System and methods for managing network packet forwarding with a controller
EP3058681B1 (en) Method for testing networks with a controller
EP3172875B1 (en) Method for performing logical network forwarding using a controller
US8208463B2 (en) Subnet scoped multicast / broadcast packet distribution mechanism over a routed network
US9185056B2 (en) System and methods for controlling network traffic through virtual switches
EP2748992B1 (en) Method for managing network hardware address requests with a controller
EP2974133B1 (en) Method and system for controlling an underlying physical network by a software defined network
US9036636B1 (en) System and methods for managing network packet broadcasting
WO2015100329A1 (en) Systems and methods for performing network service insertion
WO2016014338A1 (en) Systems and methods for handling link aggregation failover with a controller
US8891536B2 (en) Layer-3 services for united router farm
US9548900B1 (en) Systems and methods for forwarding network packets in a network using network domain topology information
EP2314026A1 (en) A method of controlling data propagation within a network
US11463356B2 (en) Systems and methods for forming on-premise virtual private cloud resources
US9264295B1 (en) Systems and methods for forwarding broadcast network packets with a controller
US9356838B1 (en) Systems and methods for determining network forwarding paths with a controller
Cisco Apollo Domain Commands
Kim et al. Building Scalable Self-configuring Networks with SEIZE