Sem resumo de edição |
Sem resumo de edição |
||
| (14 revisões intermediárias por 3 usuários não estão sendo mostradas) | |||
| Linha 5: | Linha 5: | ||
<br> | <br> | ||
Resumo - | == Resumo == | ||
In recent years it is remarkable evolution of the Internet. By contrast, the TCP / IP not gone through the same evolution. Nowadays the network devices are still black boxes, which are software locked, not allowing the user a freedom to control the network. Consequently the Internet becomes unchanging, inflexible, slow and costly developments. Recent developments point to research and development for controllers implemented externally to overcome specific shortcomings and deficiencies, in which an example would be the OpenFlow. The RouteFlow also works in this line, which is an SDN architecture, ie it follows the principle of network be set by software. The network control should be centralized to have a programmable approach, gathering status information. Furthermore, this architecture should separate the routing logic of hardware settings. | |||
Basically this new structure will be composed of a OpenFlow, application controller, and a RouteFlow, server which will control a virtual network, managing virtual IPs interconnect. A reproduction of the physical infrastructure and hardware resources can be achieved by means of routing protocols that can refer to a virtual network itself. Besides the protocols can also be referred to their own physical devices. | |||
By means of routing mechanisms is obtained routing information base (FIB - Forwarding Information Base) according to the protocol. In the specific case of IP, the tables are collected and translated into OpenFlow standard, which makes it possible to associate devices datapath. | |||
Consequently, the main objective is to provide services of RouteFlow IP routing and centralized remote, promoting greater flexibility for the services offered. It also will allow for customization and addition of new protocols that the user wishes. The work is based on the routing mechanism of Linux, being an evolution of the earlier work. | |||
The RouteFlow uses a virtual network, consisting of VMs (virtual environments) running logical control of OpenFlow switches, in which each VM simulates a routing tool. These VMs are dynamically interconnected in a logical manner to create an infrastructure similar to a physical. In external servers is where the virtual network, in which communication is done via an API OpenFlow controller, receiving servers RouteFlow decisions made through routing protocols. The flow have rules that are stored in a database to identify how traffic should be treated. While this control is centralized, it retains logically distributed, so no modifications are needed, it is possible to integrate an existing infrastructure, since the routing protocol messages are either received as sent to the control panel. Then there is the possibility of a flexible, high-performance and high-cost benefit model to provide IP routing switches based on programmable low-cost technologies commodites x86 and open source routing protocols. | |||
<br> | |||
== Tópicos == | |||
Introdução - Alex | |||
<br> | <br> | ||
* A grande evolução de Internet é notável nos últimos anos, sendo que por trás disso temos os protocolos TCP/IP, os quais não passaram pela mesma evolução. | * A grande evolução de Internet é notável nos últimos anos, sendo que por trás disso temos os protocolos TCP/IP, os quais não passaram pela mesma evolução. | ||
| Linha 21: | Linha 37: | ||
O Projeto RouteFlow - Caio | O Projeto RouteFlow - Caio | ||
* RouteFlow utiliza uma rede virtual, composta por VMs, para executar o controle lógico dos switches OpenFlow, sendo que cada uma destas VMs simula uma ferramente de roteamento. | |||
* Estas VMs estão dinamicamente interconectadas de forma lógica, criando uma estrutura semelhante a infraestrutura física. | |||
* A rede virtual se encontra em servidores externos, e a comunicação é feita através da uma API do controlador OpenFlow, o qual recebe dos servidores RouteFlow as decisões feitas pelos protocolos de roteamento. | |||
* As regras de fluxo são guardadas no plano de dados para identificar como o trafego deve ser tratado. | |||
* Enquanto o controle for centralizado, ele se manterá logicamente distribuído. Desta forma, não se faz necessária modificações. É possível ainda que integrar com a infraestrutura atual, já que as mensagens do protocolo de roteamento podem ser tanto recebidas quanto enviadas para o painel de controle. | |||
* Isso possibilita um flexível, de alto desempenho e com aceitável custo-beneficio modelo para disponibilizar roteamento IP baseado em: switches programáveis de baixo custo; protocolos opensource de roteamento e tecnologias commodites x86 | |||
Modos de Operação - Gabriel | Modos de Operação - Gabriel | ||
* Separando o plano de controle do encaminhamento estratégico permite um mapeamento e uma operação entre os elementos virtuais e os equivalentes físicos. | |||
* Existem três modos principais de operação que o RouteFlow visa apoiar: | |||
** Divisão Lógica: mapeamento entre hardware switches e os roteadores virtualmente motorizados basicamente reflete o substrato físico para o plano de controle virtual. | |||
** Multiplexando: mapeamento físico ao substrato virtual o que representa a abordagem comum para o roteador de virtualização onde múltiplos controles de avião ocorrem simultaneamente e instalam os seus FIBs no mesmo hardware. Multi-tentativas de redes virtuais pode ser definido por deixar o controle de fluxo de mensagens através do plano virtual e emenda o plano de dados de acordo com a conformidade. | |||
** Agregação: este mapeamento de recursos de hardware para instâncias virtuais permite simplificar a engenharia do protocola da rede através do agrupamento de um grupo de comutadores, de tal modo que os dispositivos vizinhos ou domínios podem tratar o agregado como se fosse um único elemento. Desta forma o intra-domínio roteia podendo ser independente, enquanto o legado inter-domínio ou inter-zona de roteamento podem ser consolidado em uma simples unidade de controle por sinal escaldo ou simplificado, centralizando a gestão. | |||
* As duas primeiras depender do protocolo de roteamento das mensagens, sendo enviados fisicamente ou armazenadas no plano virtual. Já a última permite separar e otimizar os problemas físicos de topologia descobrindo e fazendo a manutenção, além do problema de roteamento distribuído pelo estado. | |||
Detalhes Arquiteturais - Luiz Cláudio | Detalhes Arquiteturais - Luiz Cláudio | ||
<br> | |||
Implementação do protótipo - Alex | Implementação do protótipo - Alex | ||
<br> | |||
* O RouteFlow é baseado em softwares open-source e componentes recém desenvolvidos: | |||
* RF-Server e RF-Controller: | |||
- RF-Controler é uma aplicação feita em C++, que roda no topo do NOX.<br> | |||
- RF-Server é uma aplicação stand-alone responsável por eventos lógicos do sistema, como processamento, mapeamento das máquinas virtuais, gerenciamento de recursos.<br> | |||
- A associação dos dois é definida por mensagens do RF-Protocol.<br> | |||
* RF-Slave e coleta FIB: | |||
- RF-Slave é uma aplicação em C++ que atualiza a coleta da base de informações de encaminhamento(FIB), através de uma API do Linux(Netlink), enviando os dados do evento através do RF-Protocol.<br> | |||
- Esta aplicação também executa um recurso técnico de descoberta para a máquina virtual e uma identificação da troca de portas.<br> | |||
* Ambiente da rede virtual: | |||
- OpenVSwitch (OVS) é um switch programado para conectar todas as máquinas virtuais em uma topologia de acordo com o objetivo determinado pelo modo de operação.<br> | |||
- São usados os protocolos do OpenFlow para controlar dinamicamente a conexão entre as máquinas virtuais e selecionar os pacotes que serão enviados ao plano de encaminhamento.<br> | |||
- As OVSs distribuem o ambiente da rede virtual para múltiplas instâncias dela mesma, interconectadas por portas.<br> | |||
* Avaliação: | |||
- Experimentos com a implementação de um protótipo em uma testbed baseada em NetFPGA, provaram uma total compatibilidade com os equipamentos atuais além de um tempo de convergência menor, o qual justifica-se por não sofrer o problema de utilizar caminhos mais longos até o plano de controle. <br> | |||
- O RouteFlow só apresenta grande latência nos pacotes que necessitam de tratamento em um caminho mais longo, resultado de faltas de entrada na FIB e do próprio processamento da rede nas pilhas de roteamento.<br> | |||
<br> | |||
Agenda de P&D do RouteFlow - Caio | Agenda de P&D do RouteFlow - Caio | ||
* O objetivo é tornar o RouteFlow um framework opensource desenvolvido pela comunidade, o qual será usado nos serviços de roteamento do IP virtual nas redes OpenFlow | |||
* A combinação de hardware de redes de boa performance com a flexibilidade de stacks opensource de roteamento organizados às modernas praticas de cloud computing devem propiciar um novo modelo de negócios. | |||
* Para realmente conciliarmos esse projeto, reconhecemos algumas áreas que necessitam pesquisa e desenvolvimento a serem feitos: | |||
** Aplicar PaaS(Plataform as Service) a rede: | |||
** Optimização de protocolo | |||
** Resiliencia e Escalabilidade | |||
** Adesão dos trabalhos relacionados e contrução de uma comunidade. | |||
Conclusões - Gabriel | Conclusões - Gabriel | ||
* RouteFlow é um exemplo da força de uma inovação resultante da mistura das interfaces abertas ao hardware comercial e de fonte aberta no desenvolvimento de software. | |||
* A arquitetura RouteFlow permite uma associação de recursos gerados entre os protocolos de roteamento IP e um programável substrato físico, o que abre portas para vários casos de uso em torno de virtualizar os serviços de roteamento IP. | |||
* Espere-se migrar as implementações tradicionais de redes IP para softwares controladores dos drivers open-source framework. | |||
Edição atual tal como às 21h34min de 29 de agosto de 2012
Arquivo:RouteFlow-Virtual Routers.pdf
- Virtual Routers as a Service: The RouteFlow Approach Leveraging Software-Defined Networks
- Marcelo R. Nascimento, Carlos N. A. Corrêa, Maurício F. Magalhães, Sidney C. de Lucena, Christian E. Rothenberg,Marcos R. Salvador
Resumo
In recent years it is remarkable evolution of the Internet. By contrast, the TCP / IP not gone through the same evolution. Nowadays the network devices are still black boxes, which are software locked, not allowing the user a freedom to control the network. Consequently the Internet becomes unchanging, inflexible, slow and costly developments. Recent developments point to research and development for controllers implemented externally to overcome specific shortcomings and deficiencies, in which an example would be the OpenFlow. The RouteFlow also works in this line, which is an SDN architecture, ie it follows the principle of network be set by software. The network control should be centralized to have a programmable approach, gathering status information. Furthermore, this architecture should separate the routing logic of hardware settings.
Basically this new structure will be composed of a OpenFlow, application controller, and a RouteFlow, server which will control a virtual network, managing virtual IPs interconnect. A reproduction of the physical infrastructure and hardware resources can be achieved by means of routing protocols that can refer to a virtual network itself. Besides the protocols can also be referred to their own physical devices.
By means of routing mechanisms is obtained routing information base (FIB - Forwarding Information Base) according to the protocol. In the specific case of IP, the tables are collected and translated into OpenFlow standard, which makes it possible to associate devices datapath.
Consequently, the main objective is to provide services of RouteFlow IP routing and centralized remote, promoting greater flexibility for the services offered. It also will allow for customization and addition of new protocols that the user wishes. The work is based on the routing mechanism of Linux, being an evolution of the earlier work.
The RouteFlow uses a virtual network, consisting of VMs (virtual environments) running logical control of OpenFlow switches, in which each VM simulates a routing tool. These VMs are dynamically interconnected in a logical manner to create an infrastructure similar to a physical. In external servers is where the virtual network, in which communication is done via an API OpenFlow controller, receiving servers RouteFlow decisions made through routing protocols. The flow have rules that are stored in a database to identify how traffic should be treated. While this control is centralized, it retains logically distributed, so no modifications are needed, it is possible to integrate an existing infrastructure, since the routing protocol messages are either received as sent to the control panel. Then there is the possibility of a flexible, high-performance and high-cost benefit model to provide IP routing switches based on programmable low-cost technologies commodites x86 and open source routing protocols.
Tópicos
Introdução - Alex
- A grande evolução de Internet é notável nos últimos anos, sendo que por trás disso temos os protocolos TCP/IP, os quais não passaram pela mesma evolução.
- Atualmente os dispositivos da rede são caixas pretas no que se diz a sua implementação, são softwares fechados. Esta situação é reconhecida como ossificação da Internet, tornando-a mais lenta e dispendiosa na sua evolução.
- Recentes desenvolvimentos encaminham esta evolução para controladores externos implementados, para suprir certas deficiências, um exemplo é o próprio OpenFlow.
- O RouteFlow trabalha nesta linha, é uma arquitetura que segue o princípio da rede definida por software(SDN).
- É baseado numa abordagem programável para o centralizar o controle da rede, unificar informações de estado e também separar o encaminhamento lógico das configurações do hardware.
- É composto por um controlador da aplicação (OpenFlow) e um servidor (RouteFlow) que controla uma rede virtual, interconectando IPs virtuais.
- Protocolos de roteamento podem ser encaminhados para os próprios dispositivos físicos ou para a própria rede virtual que pode ser uma reprodução da infraestrutura física e dos recursos de hardware.
- Através dos mecanismos de roteamento é gerada uma base de informações de encaminhamento (FIB - Forwarding Information Base) de acordo com o protocolo. No caso do IP, tabelas são coletadas e traduzidas para o padrão do OpenFlow, sendo assim associadas aos dispositivos de datapath.
- O grande objetivo do RouteFlow é disponibilizar serviços de roteamento de IP remotos e centralizados, o que provê uma grande flexibilidade para os serviços oferecidos, além de possibilitar customização e adição de novos protocolos. É uma evolução dos trabalhos anteriores, e trabalha baseado no mecanismo de roteamento do Linux.
O Projeto RouteFlow - Caio
- RouteFlow utiliza uma rede virtual, composta por VMs, para executar o controle lógico dos switches OpenFlow, sendo que cada uma destas VMs simula uma ferramente de roteamento.
- Estas VMs estão dinamicamente interconectadas de forma lógica, criando uma estrutura semelhante a infraestrutura física.
- A rede virtual se encontra em servidores externos, e a comunicação é feita através da uma API do controlador OpenFlow, o qual recebe dos servidores RouteFlow as decisões feitas pelos protocolos de roteamento.
- As regras de fluxo são guardadas no plano de dados para identificar como o trafego deve ser tratado.
- Enquanto o controle for centralizado, ele se manterá logicamente distribuído. Desta forma, não se faz necessária modificações. É possível ainda que integrar com a infraestrutura atual, já que as mensagens do protocolo de roteamento podem ser tanto recebidas quanto enviadas para o painel de controle.
- Isso possibilita um flexível, de alto desempenho e com aceitável custo-beneficio modelo para disponibilizar roteamento IP baseado em: switches programáveis de baixo custo; protocolos opensource de roteamento e tecnologias commodites x86
Modos de Operação - Gabriel
- Separando o plano de controle do encaminhamento estratégico permite um mapeamento e uma operação entre os elementos virtuais e os equivalentes físicos.
- Existem três modos principais de operação que o RouteFlow visa apoiar:
- Divisão Lógica: mapeamento entre hardware switches e os roteadores virtualmente motorizados basicamente reflete o substrato físico para o plano de controle virtual.
- Multiplexando: mapeamento físico ao substrato virtual o que representa a abordagem comum para o roteador de virtualização onde múltiplos controles de avião ocorrem simultaneamente e instalam os seus FIBs no mesmo hardware. Multi-tentativas de redes virtuais pode ser definido por deixar o controle de fluxo de mensagens através do plano virtual e emenda o plano de dados de acordo com a conformidade.
- Agregação: este mapeamento de recursos de hardware para instâncias virtuais permite simplificar a engenharia do protocola da rede através do agrupamento de um grupo de comutadores, de tal modo que os dispositivos vizinhos ou domínios podem tratar o agregado como se fosse um único elemento. Desta forma o intra-domínio roteia podendo ser independente, enquanto o legado inter-domínio ou inter-zona de roteamento podem ser consolidado em uma simples unidade de controle por sinal escaldo ou simplificado, centralizando a gestão.
- As duas primeiras depender do protocolo de roteamento das mensagens, sendo enviados fisicamente ou armazenadas no plano virtual. Já a última permite separar e otimizar os problemas físicos de topologia descobrindo e fazendo a manutenção, além do problema de roteamento distribuído pelo estado.
Detalhes Arquiteturais - Luiz Cláudio
Implementação do protótipo - Alex
- O RouteFlow é baseado em softwares open-source e componentes recém desenvolvidos:
- RF-Server e RF-Controller:
- RF-Controler é uma aplicação feita em C++, que roda no topo do NOX.
- RF-Server é uma aplicação stand-alone responsável por eventos lógicos do sistema, como processamento, mapeamento das máquinas virtuais, gerenciamento de recursos.
- A associação dos dois é definida por mensagens do RF-Protocol.
- RF-Slave e coleta FIB:
- RF-Slave é uma aplicação em C++ que atualiza a coleta da base de informações de encaminhamento(FIB), através de uma API do Linux(Netlink), enviando os dados do evento através do RF-Protocol.
- Esta aplicação também executa um recurso técnico de descoberta para a máquina virtual e uma identificação da troca de portas.
- Ambiente da rede virtual:
- OpenVSwitch (OVS) é um switch programado para conectar todas as máquinas virtuais em uma topologia de acordo com o objetivo determinado pelo modo de operação.
- São usados os protocolos do OpenFlow para controlar dinamicamente a conexão entre as máquinas virtuais e selecionar os pacotes que serão enviados ao plano de encaminhamento.
- As OVSs distribuem o ambiente da rede virtual para múltiplas instâncias dela mesma, interconectadas por portas.
- Avaliação:
- Experimentos com a implementação de um protótipo em uma testbed baseada em NetFPGA, provaram uma total compatibilidade com os equipamentos atuais além de um tempo de convergência menor, o qual justifica-se por não sofrer o problema de utilizar caminhos mais longos até o plano de controle.
- O RouteFlow só apresenta grande latência nos pacotes que necessitam de tratamento em um caminho mais longo, resultado de faltas de entrada na FIB e do próprio processamento da rede nas pilhas de roteamento.
Agenda de P&D do RouteFlow - Caio
- O objetivo é tornar o RouteFlow um framework opensource desenvolvido pela comunidade, o qual será usado nos serviços de roteamento do IP virtual nas redes OpenFlow
- A combinação de hardware de redes de boa performance com a flexibilidade de stacks opensource de roteamento organizados às modernas praticas de cloud computing devem propiciar um novo modelo de negócios.
- Para realmente conciliarmos esse projeto, reconhecemos algumas áreas que necessitam pesquisa e desenvolvimento a serem feitos:
- Aplicar PaaS(Plataform as Service) a rede:
- Optimização de protocolo
- Resiliencia e Escalabilidade
- Adesão dos trabalhos relacionados e contrução de uma comunidade.
Conclusões - Gabriel
- RouteFlow é um exemplo da força de uma inovação resultante da mistura das interfaces abertas ao hardware comercial e de fonte aberta no desenvolvimento de software.
- A arquitetura RouteFlow permite uma associação de recursos gerados entre os protocolos de roteamento IP e um programável substrato físico, o que abre portas para vários casos de uso em torno de virtualizar os serviços de roteamento IP.
- Espere-se migrar as implementações tradicionais de redes IP para softwares controladores dos drivers open-source framework.