Open Flow

OpenFlow e redes definidas por software: um
novo paradigma de controle e inovao em

redes de pacotes
Christian Esteve Rothenberg
*
, Marcelo Ribeiro Nascimento, Marcos Rogrio Salvador, Maurcio
Ferreira Magalhes**

H algum tempo observa-se o surgimento da necessidade de maior abertura e flexibilidade dos
equipamentos de rede, especialmente com o propsito de pesquisa e inovao. Os roteadores atuais
implementam uma arquitetura composta por uma camada de software fechada, que executada em um
hardware proprietrio. Esse modelo resulta em solues de alto custo, dificulta a insero de novas
funcionalidades e inviabiliza a experimentao de novas ideias. Com o avano da padronizao do
protocolo OpenFlow para programar o plano de encaminhamento dos equipamentos de redes de
pacotes, o conceito de redes programadas por software traz um novo paradigma de inovao cujo
potencial disruptivo assemelha-se ao da introduo de sistemas operacionais em computadores e, mais
recentemente, em dispositivos mveis. Este artigo introduz os princpios da tecnologia OpenFlow e
apresenta a arquitetura RouteFlow como exemplo de inovao para a funo de roteamento em um
ambiente aberto (open source), executado sobre hardware comercial (commodity).
Palavras-chave: Redes de pacotes. Roteamento. Encaminhamento. Software livre. Virtualizao.
Introduo
A infraestrutura das redes de pacotes
composta, atualmente, por equipamentos
proprietrios, fechados e de alto custo, cujas
arquiteturas bsicas so concebidas a partir da
combinao de circuitos dedicados,
responsveis por garantir alto desempenho
(Application Specific Integrated Circuit ASIC),
ao processamento de pacotes. A infraestrutura
complementada por uma camada de software de
controle, responsvel pelo suporte a uma
extensa pilha formada por um nmero elevado
de protocolos. No entanto, torna-se evidente a
necessidade de especializao da lgica de
controle de acordo com cada tipo e objetivo de
rede. Porm, qualquer mudana de configurao
avanada do equipamento ou especializao da
lgica de controle e tratamento dos pacotes ou,
ainda, insero de novas funcionalidades esto
sujeitas a ciclos de desenvolvimento e de testes
restritos ao fabricante do equipamento,
resultando em um processo demorado e custoso
(HAMILTON, 2009). No mbito da pesquisa,
essas exigncias so ainda maiores pois
requerem experimentaes de novos protocolos
e funcionalidades da rede em condies reais,
idealmente em ambientes espalhados da rede
em operao (SHERWOOD et al., 2010).
A ausncia de exibilidade no controle do
funcionamento interno dos equipamentos assim
como o alto custo da infraestrutura vigente so
barreiras para a evoluo das arquiteturas e para
a inovao decorrente da oferta de novos
servios e aplicaes de rede (ANWER et al.,
2010).
Este artigo faz um levantamento do estado da
arte da tecnologia OpenFlow como quebra de
paradigma de controle em software (remoto) dos
equipamentos de rede, habilitando o conceito de
redes definidas por software. Como exemplo de
utilizao, apresenta-se um trabalho em
desenvolvimento, voltado para uma arquitetura
de roteamento denominada RouteFlow
(NASCIMENTO et al., 2011), cujo controle
realizado remotamente via software. Essa
arquitetura implementvel em produtos
comerciais e utiliza ambientes de software de
domnio pblico para implementao das funes
de controle.
1 Redes definidas por software
Apesar da evoluo formidvel da Internet, em
termos de penetrao e de aplicaes, sua
tecnologia, representada pela arquitetura em
camadas e pelos protocolos do modelo TCP/IP,
no evoluiu suficientemente nos ltimos vinte
anos. A Internet tornou-se comercial e os
equipamentos de rede tornaram-se caixas
pretas, ou seja, implementaes integradas
verticalmente baseadas em software fechado
sobre hardware proprietrio. O resultado desse
modelo o j reconhecido engessamento da
Internet (CHOWDHURY; BOUTABA, 2009).
Em contraste com o desenho da arquitetura da
Internet, caracterizada por um plano de controle
(PC) distribudo, os avanos na padronizao de
APIs (Application Programming Interface)
independentes do fabricante do equipamento
*Autor a quem a correspondncia deve ser dirigida: esteve@cpqd.com.br.
** Faculdade de Engenharia Eltrica e de Computao Unicamp.
Cad. CPqD Tecnologia, Campinas, v. 7, n.1, p. 65-76, jul. 2010/jun. 2011
OpenFlow e redes definidas por software: um novo paradigma de controle e inovao em redes de pacotes
(OPENFLOW, 2010; IETF, 2011) permitem
mover grande parte da lgica de tomada de
deciso dos dispositivos de rede para
controladores externos, que podem ser
implementados com o uso da tecnologia de
servidores comerciais (PCs), um recurso
abundante, escalvel e barato. Essa lobotomia
da inteligncia do equipamento da rede para
controladores logicamente centralizados
possibilita a definio do comportamento da rede
em software no apenas pelos fabricantes do
equipamento, mas tambm por fornecedores ou
pelos prprios usurios, como, por exemplo,
operadores de rede.
1.1 Arquiteturas de roteamento
Uma anlise da arquitetura atual dos roteadores
(Figura 1) permite observar que se trata de um
modelo formado basicamente por duas camadas
bem distintas: o software de controle e o
hardware dedicado ao encaminhamento de
pacotes (JUNIPER NETWORKS, 2010). O
primeiro, encarregado de tomar as decises de
roteamento, transfere essas decises para o
plano de encaminhamento atravs de uma API
proprietria. A nica interao da gerncia com o
dispositivo ocorre atravs de interfaces de
configurao (Web, SNMP, CLI, por exemplo),
limitando o uso dos dispositivos s
funcionalidades programadas pelo fabricante.
coerente pensar que se a arquitetura ,
atualmente, composta por duas camadas
autocontidas, elas no precisam estar fechadas
em um mesmo equipamento. Para isso, basta
que exista uma forma padro de se programar o
dispositivo de rede remotamente, permitindo que
a camada de controle possa ser movida para um
servidor dedicado e com alta capacidade de
processamento. Desse modo, mantm-se o alto
desempenho no encaminhamento de pacotes em
hardware aliado flexibilidade de se inserir,
remover e especializar aplicaes em software
por meio de um protocolo aberto para
programao da lgica do equipamento
(Figura 1). Com esse propsito, nasceu o
consrcio OpenFlow (MCKEOWN et al., 2008),
dando origem ao conceito de software-defined
networking as redes definidas por software
(GREENE, 2009).
Figura 1 Arquiteturas de roteadores: modelo atual
mainframe e modelo programvel OpenFlow
1.2 OpenFlow
O OpenFlow foi proposto pela Universidade de
Stanford para atender demanda de validao
de novas propostas de arquiteturas e protocolos
de rede (incluindo as abordagens clean slate)
sobre equipamentos comerciais. OpenFlow
define um protocolo-padro para determinar as
aes de encaminhamento de pacotes em
dispositivos de rede, como, por exemplo,
comutadores, roteadores e pontos de acesso
sem fio. As regras e aes instaladas no
hardware de rede so responsabilidade de um
elemento externo, denominado controlador, que
pode ser implementado em um servidor comum,
conforme Figura 2.
Figura 2 Exemplo de uma rede com OpenFlow
habilitado
A principal abstrao utilizada na especificao
OpenFlow o conceito de fluxo. Um fluxo
constitudo pela combinao de campos do
cabealho do pacote a ser processado pelo
dispositivo, conforme Figura 3. As tuplas podem
ser formadas por campos das camadas de
enlace, de rede ou de transporte, segundo o
modelo TCP/IP. Deve-se enfatizar que a
abstrao da tabela de fluxos ainda est sujeita a
refinamentos, com o objetivo de oferecer uma
melhor exposio dos recursos do hardware e,
nesse caso, permitir a concatenao de vrias
tabelas j disponveis, como, por exemplo,
tabelas IP/Ethernet/MPLS. Nesse sentido, a
contribuio mais importante do paradigma do
OpenFlow a generalizao do plano de dados
qualquer modelo de encaminhamento de dados
baseado na tomada de deciso fundamentada
em algum valor, ou combinao de valores, dos
campos de cabealho dos pacotes pode ser
suportado.
De forma pragmtica, a especificao OpenFlow
(OPENFLOW, 2010) procura reutilizar as
funcionalidades do hardware existente (por
66 Cad. CPqD Tecnologia, Campinas, v. 7, n.1, p. 65-76, jul. 2010/jun. 2011
Figura 3 Cabealhos disponveis no OpenFlow
para a especificao de fluxos
exemplo, Access Control List ACL em switches
e roteadores para implementar servios como
NAT, rewall e VLANs) atravs da definio de
um conjunto simples de regras e das aes
associadas: encaminhar, descartar, enviar para o
controlador, reescrever campos do cabealho,
etc.
1.2.1 Componentes
Basicamente, uma rede programvel com
OpenFlow consiste em equipamentos de rede
habilitados para que o estado das tabelas de
fluxos possa ser instalado atravs de um canal
seguro, conforme as decises de um controlador
em software:
1.2.1.1 Tabela de fluxos
Cada entrada na tabela de uxos do hardware de
rede consiste em regra, aes e contadores.
A regra formada com base na definio do
valor de um ou mais campos do cabealho do
pacote. Associa-se a ela um conjunto de aes
que denem o modo como os pacotes devem ser
processados e para onde devem ser
encaminhados. Os contadores so utilizados
para manter estatsticas de utilizao e para
remover uxos inativos. As entradas da tabela de
uxos podem ser interpretadas como decises
em cache (hardware) do plano de controle
(software), sendo, portanto, a mnima unidade de
informao no plano de dados da rede.
1.2.1.2 Canal seguro
Para que a rede no sofra ataques de elementos
mal-intencionados, o canal seguro garante
conabilidade na troca de informaes entre o
switch e o controlador. A interface de acesso
recomendada o protocolo SSL (Secure Socket
Layer). Interfaces alternativas (passivas ou
ativas) incluem TCP e pcap (packet capture), e
so especialmente teis em ambientes virtuais e
experimentais pela simplicidade de utilizao,
pois no necessitam de chaves criptogrcas.
1.2.1.3 Protocolo OpenFlow
Protocolo aberto para comunicao que usa uma
interface externa, definida pelo OpenFlow para a
troca de mensagens entre os equipamentos de
rede e os controladores. Essas mensagens
podem ser simtricas (hello, echo vendor),
assncronas (packet in, flow removed, port
status, error) ou, ainda, iniciadas pelo controlador
(features, configuration, modify state, send
packet, barrier).
1.2.1.4 Controlador
o software responsvel por tomar decises e
adicionar e remover as entradas na tabela de
fluxos, de acordo com o objetivo desejado.
O controlador exerce a funo de uma camada
de abstrao da infraestrutura fsica, facilitando a
criao de aplicaes e servios que gerenciem
as entradas de fluxos na rede. Esse modelo
assemelha-se a outros sistemas de software que
proveem abstrao do hardware e funcionalidade
reutilizvel. Dessa forma, o controlador
OpenFlow atua como um sistema operacional
(SO) para gerenciamento e controle das redes, e
oferece uma plataforma com base na reutilizao
de componentes e na definio de nveis de
abstrao (comandos da API). Contudo, novas
aplicaes de rede podem ser desenvolvidas
rapidamente (GUDE et al., 2008).
A programabilidade do controlador permite a
evoluo em paralelo das tecnologias nos planos
de dados e as inovaes na lgica das
aplicaes de controle. A Figura 4 mostra uma
abstrao de uma rede com OpenFlow e o
controlador NOX executando inmeras
aplicaes que necessitam de uma viso do
estado da rede (network view). Essa viso pode
ser armazenada, por exemplo, em um simples
banco de dados executado localmente ou em um
servidor remoto.
Figura 4 Elementos de uma rede OpenFlow
1.2.2 OpenFlow em ao
Quando um pacote chega a um equipamento
com OpenFlow habilitado, os cabealhos do
pacote so comparados s regras das entradas
das tabelas de fluxos, os contadores so
atualizados e as aes correspondentes so
realizadas. Se no houver correspondncia entre
o pacote e alguma entrada da tabela de fluxos, o
pacote encaminhado, por completo, ao
controlador. Alternativamente, apenas o
cabealho encaminhado ao controlador
mantendo o pacote armazenado no buffer do
hardware.
Normalmente, os pacotes que chegam ao
controlador correspondem ao primeiro pacote de
um novo fluxo ou, em funo do tipo de pacote e
da aplicao, o controlador pode optar por
instalar uma regra no switch para que todos os
pacotes de determinado fluxo sejam enviados
para o controlador para serem tratados
individualmente. Esse ltimo caso corresponde,
em geral, a pacotes de controle (ICMP, DNS,
DHCP) ou de protocolos de roteamento (OSPF,
BGP).
Como exemplo de fluxo, tm-se todos os pacotes
Cad. CPqD Tecnologia, Campinas, v. 7, n.1, p. 65-76, jul. 2010/jun. 2011 67
em uma faixa de endereos IP ( roteamento IP
tradicional), uma conexo TCP em uma porta
especfica ou, ainda, todos os pacotes
pertencentes a uma mesma VLAN. As aes
associadas aos fluxos incluem:
a) encaminhar o fluxo de pacotes para
determinada porta (ou portas);
b) modificar os campos do cabealho;
c) encapsular e transmitir o pacote para o
controlador;
d) descartar os dados, como medida de
segurana, com a implementao de
firewalls, ou ainda para inibir ataques de
negao de servio;
e) encaminhar o pacote para o
processamento normal do equipamento
nas camadas 2 ou 3.
O ltimo item garante que o trfego experimental
no interfira no processamento-padro do trfego
de produo. Conforme ilustrado na Figura 5,
outra forma de garantir isso definir um conjunto
de VLANs para fins experimentais. Essa
segmentao do trfego permite ter
equipamentos hbridos que processem trfego
legado conforme os protocolos e as
funcionalidades embarcadas no equipamento e,
ao mesmo tempo e de forma isolada, obter
trfego baseado na programabilidade do
OpenFlow.
Figura 5 Modelo de operao hbrido com VLANs
isolando trfego legado e OpenFlow
Na verso 1.1 do protocolo OpenFlow (ainda sob
especificao), est sendo considerado o suporte
a mltiplas tabelas de fluxos concatenadas
(Figura 6) mediante um novo conjunto de
instrues (Go-to-Table, Write-Metadata), bem
como novas aes (copy/decrement TTL,
push/pop tag, QoS) e campos de cabealho
(VLAN priority, MPLS label/traffic class, SCTP
port) para uma definio ainda mais completa
dos fluxos e do conjunto de aes associadas.
Figura 6 Diagrama detalhando o tratamento de um
pacote no pipeline de um switch OpenFlow
1.2.3 Fatores crticos de sucesso
Existem quatro razes fundamentais que
contribuem para a aceitao da tecnologia
OpenFlow:
a) o OpenFlow pode ser incorporado em
equipamentos de rede (roteadores,
switches, pontos de acesso Wi-Fi)
comerciais, atualmente, em operao, sem
modificao do hardware e mediante uma
atualizao do firmware, garantindo o
desempenho de tecnologias consolidadas
no encaminhamento de pacotes
IP/Ethernet, como, por exemplo, ASICs,
FPGAs, etc.;
b) o protocolo OpenFlow separa o plano de
controle do plano de dados, permitindo a
utilizao de controladores remotos
baseados em servidores com sistemas
operacionais e linguagens de programao
comuns na indstria de TI. O software do
controlador responsvel por definir o
modo como os fluxos de pacotes so
encaminhados e processados na rede.
Isso permite que o controle sobre o plano
de dados seja "terceirizado" a
pesquisadores, sistemas de gerncia,
desenvolvedores, operadores de rede,
plataformas de servios e, at mesmo, s
prprias aplicaes finais, como, por
exemplo, servidores de contedo ou
servios em nuvem. Dessa forma, o
controle da rede deixa de estar embarcado
nos equipamentos e limitado por
implementaes e padres com mais de
15 anos de existncia;
c) o OpenFlow no dependente da forma
como o software controla a rede, e oferece
um simples servio de encaminhamento
multicamada (L1-L4) orientado a fluxos
definidos por qualquer combinao de
mais de 20 cabealhos-padro. Uma rede
OpenFlow permite a definio de fatias de
rede (slices ou flow-spaces), com garantia
de isolamento entre os diferentes
controladores que operam sobre a rede,
permitindo que o trfego operacional
(conforme os protocolos tradicionais) e o
trfego experimental (conforme definido
pelo usurio/operador da rede) operem em
paralelo;
d) o OpenFlow compatvel com a Internet
atual, cujo trfego pode continuar em
operao em uma ou mais fatias da rede
OpenFlow.
Todos os argumentos citados, anteriormente,
apontam o OpenFlow como uma tecnologia
inovadora que abre uma srie de oportunidades
de desenvolvimento tecnolgico na rea das
redes de pacotes. Com a consolidao das
tecnologias de equipamentos programveis em
software no padro OpenFlow, ou tecnologias
similares, o conceito de redes definidas por
software envolve novos paradigmas de gerncia
integrada, inovao em protocolos e servios
baseados em recursos de redes virtualizados,
como, por exemplo, Network as a Service
(CHOWDHURY; BOUTABA, 2009; KELLER;
REXFORD, 2010).
1.3 Mercado e cenrios de aplicao
Os fatores apontados anteriormente e o potencial
disruptivo da tecnologia OpenFlow tm atrado a
ateno da indstria, o que tem se traduzido:
a) no desenvolvimento dos primeiros prottipos
com suporte ao OpenFlow (HP, NEC,
Extreme, Arista, Ciena, Juniper, Cisco);
b) no suporte dos fornecedores de
processadores em silcio (Broadcom,
Marven);
c) na criao de novas empresas (Nicira, Big
Switch Networks); e
d) no interesse de operadoras, como Deutsche
Telekom e Docomo, e provedores de
servios em nuvem, como Google,
Facebook e Amazon).
Entre os vrios cenrios de rede em que a
adoo da tecnologia OpenFlow traz aspectos
promissores, vale destacar:
a) redes corporativas: novos mecanismos de
controle de acesso e segurana, gerncia
integrada de rede cabeada e sem fio,
configurao de VLANs, suporte
mobilidade, etc. (CASADO et al., 2007);
b) backbone: convergncia de redes de
pacotes e circuitos, (Figura 7), como, por
exemplo, agregao e gerncia dinmica e
flexvel do trfego, novos mecanismos de
roteamento e engenharia de trfego e
recuperao de falhas; balanceamento do
trfego Web; mobilidade de mquinas
virtuais; etc. (GUDLA et al., 2010);
c) redes celulares: uso transparente de
diversas redes de acesso
(Wi-Fi/3G/WiMAX), separao do provedor
de infraestrutura do provedor de servios
(por exemplo, virtual network operators),
etc. (YAP et al., 2010);
d) data center: tcnicas de conservao de
energia, engenharia de trfego, roteamento
plano e multicaminho, suporte
virtualizao de hosts e software switches
(KOPONEN et al., 2010);
e) redes domsticas: terceirizao
(outsourcing) da gerncia de rede,
compartilhamento da rede com vrios
provedores de servios e usurios, como,
por exemplo, Open Wi-Fi, e gerncia de
energia com medidores inteligentes, como
smart grid;
f) redes de ensino e pesquisa: infraestrutura
de experimentao de novas arquiteturas de
rede e paradigmas de encaminhamento de
pacotes, compartilhamento de uma
infraestrutura experimental multicamada,
multidomnio e multitecnologia, validao
sobre hardware comercial, etc.
Fonte: GUDLA et al., 2010
Figura 7 Rede hbrida com switches TDM, WDM e
roteadores IP controlados por OpenFlow (NOX),
que implementa as funcionalidades em software
2 Arquitetura RouteFlow
O RouteFlow uma proposta de oferta de
servios de roteamento IP remoto de forma
centralizada, e que visa um desacoplamento
efetivo entre o plano de encaminhamento e o
plano de controle (ROUTEFLOW, 2011). O
objetivo tornar as redes IP mais flexveis pela
facilidade de adio, remoo e especializao
de protocolos e algoritmos. O RouteFlow
armazena a lgica de controle dos switches
OpenFlow na infraestrutura de rede, atravs de
uma rede virtual composta por mquinas virtuais
(MV), cada uma executando um cdigo (engine)
de roteamento de domnio pblico (open source).
Essas MVs podem ser interconectadas de
maneira a formar uma topologia lgica,
espelhando a topologia de uma rede fsica
correspondente ou uma topologia virtual
simplificada. O ambiente virtual armazenado
em um servidor externo, ou um conjunto deles,
que se comunicam com os equipamentos do
plano de dados atravs de um controlador
OpenFlow, que transporta para o plano de
encaminhamento as decises tomadas pelos
protocolos de roteamento no plano de controle
(OSPF, BGP, RIP). A Figura 8 ilustra uma
sub-rede com switches programveis, em que a
lgica de roteamento implementada no servidor
RouteFlow.
O resultado consiste numa soluo flexvel de
alto desempenho e comercialmente competitiva,
a partir da combinao de recursos disponveis,
como, por exemplo:
a) switches programveis de baixo custo e
software embarcado reduzido (OpenFlow);
b) pilhas de protocolos de roteamento open
source (QUAGGA, 2009; XORP, 2011); e
c) servidor de prateleira de alto poder de
processamento e, tambm, de baixo custo.
Cabe ressaltar que, apesar de o controle estar
fisicamente centralizado, ele continua distribudo
logicamente. Dessa forma, no necessria
qualquer alterao dos protocolos de roteamento
existentes. Alm disso, a soluo pode tornar-se
mais escalvel no futuro, com o uso de vrios
servidores de alto desempenho.
2.1 Blocos funcionais
Uma viso global dos principais componentes do
RouteFlow pode ser observada na Figura 9. A
seguir, apresenta-se a descrio de cada um dos
componentes da arquitetura proposta.
Figura 9 Componentes da soluo RouteFlow
2.1.1 RouteFlow-Slave (RF-S)
Cada MV do plano de controle executa um
processo (daemon) responsvel pelas seguintes
funes:
a) registrar a MV no controlador como recurso
da topologia virtual, sendo que a MV se
torna um recurso disponvel para ser
utilizado na representao de um roteador;
b) gerenciar as interfaces de rede do sistema
(portas do roteador);
c) detectar as atualizaes das tabelas
Address Resolution Protocol (ARP) e de
roteamento do sistema; e
d) converter rotas em fluxos a serem
instalados no plano de dados por meio da
API do OpenFlow.
Pacotes de protocolos e outros, cujos destinos
sejam o prprio roteador so encaminhados e
recebidos pela MV para processamento (ARP,
ICMP, Telnet, SSH, OSPF, RIP, etc.). Pacotes
ARP e ICMP, por exemplo, so tratados pela
pilha TCP/IP do Linux, enquanto pacotes de
protocolos so utilizados pela engine de
roteamento para clculo de rotas. O
processamento no caminho inverso ocorre do
mesmo modo. Concomitantemente ao
processamento de pacotes da MV, um
mecanismo de polling executa a tarefa de
verificar as tabelas ARP e ROUTE do sistema
em busca de atualizaes que devem ser
reproduzidas no plano de dados. Quando
atualizaes so detectadas, as modificaes
correspondentes so convertidas na instalao
ou remoo de fluxos da tabela do elemento de
encaminhamento atribudo MV.
2.1.2 RouteFlow-Controller (RF-C)
o componente central da arquitetura proposta.
Como o prprio nome sugere, trata-se de uma
funo de controle que conecta todos os
elementos do plano de dados e as MVs do plano
de controle. As principais funes do RF-C so:
a) registrar-se no controlador de rede para
eventos de recebimento de pacotes,
conexo e desconexo de switches;
b) registrar os recursos (MVs) disponveis na
topologia virtual;
c) fazer a configurao do software switch
para montar a topologia lgica da rede;
d) gerenciar o mapeamento entre switches
OpenFlow e MVs;
e) instalar/remover fluxos OpenFlow dos
switches do plano de dados.
A vinculao das mquinas virtuais aos switches
do plano de dados pode ser feita estaticamente
atravs de um arquivo de configurao, que
permite configurar uma topologia virtual
independentemente da topologia fsica.
Alternativamente, a configurao pode ser
dinmica, com base em um mecanismo de
descoberta de topologia governado pelo
controlador de rede. Nesse ltimo caso, a rede
virtual ser uma rplica da topologia fsica. Outra
possibilidade consiste em agregar um conjunto
de ns fsicos, como, por exemplo, switch
stacking/trunking, em uma nica MV no plano
virtual, ou ter vrias engines de roteamento
atuando sobre um mesmo elemento fsico o
que remete ao conceito de roteadores virtuais,
em que mltiplos planos de controle com
objetivos diferentes compartilham o mesmo
substrato hardware de rede (CHOWDHURY;
BOUTABA, 2009).
Figura 8 Viso geral do RouteFlow
2.1.3 RouteFlow-Protocol (RF-P)
Protocolo desenvolvido na arquitetura proposta
para a comunicao entre os componentes do
RouteFlow. Nele, esto definidas as mensagens
e os comandos bsicos para conexo e
configurao das MVs e, tambm,
gerenciamento das entradas de roteamento em
hardware. Entre os campos da mensagem-
padro esto: identificao do controlador,
identificao da MV, tipo da mensagem,
comprimento e dados.
3 Avaliao do prottipo RouteFlow
O RF-Controller foi implementado em C++ como
uma aplicao do controlador open source NOX
(2011). Como engine de roteamento, foi utilizado
o Quagga (2009), uma conhecida soluo de
roteamento open source com suporte aos
principais protocolos de roteamento (RIP, OSPF,
BGP). Como plataforma para programao
remota dos equipamentos de rede, utilizou-se a
verso 1.0 da tecnologia OpenFlow, cuja
vantagem sua abordagem multifornecedor.
Isso significa que ele no depende do fabricante
e do modelo do equipamento que compe a
rede. Desde que haja suporte ao protocolo
OpenFlow, no so necessrias mudanas no
controlador nem nas aplicaes de rede que
executam sobre ele. A infraestrutura do plano de
dados do prottipo formada por NetFPGAs,
que so hardware programveis com quatro
interfaces de rede Gigabit e com mdulo
OpenFlow. A escolha da plataforma NetFPGA se
deu pela flexibilidade de programao do plano
de encaminhamento e pela taxa de
processamento de pacotes em Gigabits.
Tambm foi usado o switch L2/L3 CPqD
Enterprise, baseado em um ASIC da Broadcom
com 24 portas de 1 Gbit/s e 2 de 10 Gbit/s.
Devido ao nmero de equipamentos disponveis
com suporte ao OpenFlow, por se tratar de um
ambiente real e no simulado, as redes testadas
apresentam um nmero limitado de ns.
Entretanto, a quantidade de ns suficiente para
uma avaliao de viabilidade da proposta,
atravs da anlise detalhada das trocas de
mensagens e dos tempos relacionados
convergncia da rede em caso de falha, como,
por exemplo, o tempo de processamento das
mensagens RouteFlow e OpenFlow. Essas
mensagens no existem em uma arquitetura
clssica de roteador com pilha de protocolos
embarcada.
3.1 Tempo de convergncia com trfego line
rate
Para os testes de convergncia, foi utilizado um
gerador e um analisador de trfego configurados
para transmisso de pacotes IP de 1500 bytes
em ambos os sentidos (full duplex), a uma taxa
de 1 Gbit/s. Dessa forma, garante-se que essa
soluo de roteamento remota sobre uma rede
programvel capaz de operar com trfego na
taxa de transmisso da interface (line rate), uma
vez que os pacotes so processados em
hardware (ARGYRAKI et al., 2008).
A Figura 10 apresenta um grfico que mostra o
tempo total de convergncia da rede aps falha
de um enlace, utilizando o protocolo OSPFv3
configurado com o parmetro hello time em
1 segundo. Esse o principal parmetro do
protocolo diretamente relacionado ao tempo de
deteco de falhas. O hello time foi configurado
para 1, 5 e 10 segundos, correspondendo aos
valores tpicos da indstria, que apresentam
default de 10 segundos em enlaces Ethernet. O
dead interval utilizado foi o recomendado
correspondendo a quatro vezes o hello time.
Figura 10 Tempo total de convergncia (OSPF
hello interval = 1 s)
Figura 11 Fragmentao do tempo de
convergncia (OSPF hello interval = 1 s)
Com o intuito de estudar os componentes que
contribuem com o tempo total de convergncia,
foram realizadas anlises das mensagens
enviadas e recebidas pelo hardware OpenFlow
para o controlador NOX. Nos resultados, est
incluso o tempo gasto pelas mensagens para
transitar entre o dispositivo de encaminhamento,
o controlador e a MV. T1 pode ser obtido a partir
do intervalo entre o instante em que ocorre a
interrupo do trfego e a primeira mensagem de
LS-Update gerada pelo RouteFlow ao detectar a
falha. Em seguida, leva-se T2 + T3 para que o
RF-Slave inicie o envio da primeira mensagem
de alterao de fluxo e, por ltimo, T4 finaliza o
processo com o restabelecimento do trfego.
Tabela 1 Tempos de convergncia aps falha
Hello
Time
T1 [s] T2 + T3 [s] T4 [s] Ttotal [s]
OSPF Tmed. T90% Tmed. T90% Tmed. T90% Tmed. T90%
1 s 3,25 3,92 0,36 0,40 0,07 0,12 3,70 4,37
5 s 16,7 18,9 0,32 0,39 0,06 0,10 17,1 19,3
10 s 36,4 37,8 0,36 0,49 0,04 0,11 36,8 38,3
Na Figura 11 e na Tabela 1, apresentam-se os
tempos conforme a fragmentao proposta
anteriormente, em que cada um deles possui o
valor de tempo abaixo do qual se encontram
metade dos testes e o valor de tempo abaixo do
qual se encontram 90% dos testes, num total de
20 repeties para cada uma das configuraes.
Conforme os dados apresentados, o tempo total
de convergncia bem prximo de T1 (tempo de
deteco da falha). Portanto, o tempo restante,
gasto com o clculo de rotas, deteco de
modificaes da tabela de roteamento pelo
RF-Slave e instalao do fluxo tem pouco
impacto no tempo de convergncia. Apesar de
T2 e T3 no terem sido analisados
separadamente, sabe-se que o tempo de polling
para verificar atualizaes da tabela de
roteamento e ARP do Linux fixo em 100 ms, ou
seja, da soma T2 + T3, T3 representa at
100 milissegundos, no pior caso. Vale ressaltar
que foi utilizada a estratgia de polling por
simplificao; no entanto, podem ser feitas
otimizaes para reduzir substancialmente T3.
Uma opo seria fazer com que a aplicao se
registrasse no Zebra (mdulo central do Quagga)
para receber notificaes sobre a RIB. Dessa
forma, a informao chegaria ao RF-Slave de
forma muito mais rpida e eficiente.
Dada a baixa representatividade dos tempos T3
e T4 sobre o tempo total, razovel afirmar a
viabilidade da soluo RouteFlow no contexto
proposto.
3.2 Encaminhamento em slow path e fast
path
Outra forma de se avaliar o impacto de uma pilha
de protocolos de roteamento remota comparar
os tempos para os modos de encaminhamento
de pacotes: slow path e fast path. A primeira
forma de encaminhamento ocorre quando o
roteador precisa se comunicar com um n de
uma rede diretamente conectada a ele, mas
antes do aprendizado do endereo MAC do
destino, necessrio para o encaminhamento em
hardware. O slow path normalmente ocorre com
os ns que entraram na rede ou que ficaram sem
comunicao por um longo perodo. Por essa
razo, essa operao nos roteadores, apesar de
necessria, considerada de baixa relevncia.
O fast path refere-se ao encaminhamento em
hardware que ocorre aps o aprendizado dos
endereos dos ns e o preenchimento das
tabelas em hardware. Portanto, em uma
transmisso de dados, o slow path ocorre,
quando necessrio, apenas para o primeiro
pacote, a partir do qual ser realizado o
aprendizado, sendo que o restante dos pacotes
sero processados em line rate.
Atravs desse teste, possvel avaliar a
diferena de desempenho entre um
encaminhamento por software e por hardware,
de um roteador tradicional com protocolos
embarcados, e do RouteFlow, com o plano de
controle remoto. Foram realizados testes de
PING (Internet Control Message Protocol
ICMP) entre dois hosts diretamente conectados a
portas distintas, de um mesmo roteador, e
configuradas em redes diferentes. No incio, os
hosts no tm conhecimento do endereo MAC
dos gateways, e o roteador tambm no
contempla ambos os hosts em suas tabelas.
Aps o aprendizado dos endereos, so obtidos
os valores de fast path. Foram utilizados os
seguintes switches layer 3: CISCO 3560-e
Catalyst, Extreme x450-e, CPqD Enterprise
(prottipo) e RouteFlow. Os resultados dos testes
esto apresentados na Tabela 2.
Foi observado nos testes com o RouteFlow que
alm do primeiro pacote ICMP request, o reply
tambm encaminhado no slow path em
software. O motivo desse comportamento est
relacionado principalmente aos 100 ms de polling
para que as atualizaes nas tabelas do Linux
sejam detectadas. No momento da resposta
ICMP, os fluxos ainda no esto instalados e o
pacote precisa novamente ser direcionado ao
controlador para ser, ento, encaminhado por
software. Portanto, vlido pensar em um tempo
consideravelmente menor para esse teste, com
uma otimizao da forma com que o RF-Slave
passa a ter conhecimento das atualizaes,
como exemplificado anteriormente.
Outro ponto a ser destacado sobre o resultado de
slow path, consideravelmente superior quando
comparado aos dispositivos com software
embarcado, o desempenho do controlador
OpenFlow (NOX) utilizado nos testes, cuja
proposta a de prover uma plataforma simples
de desenvolvimento de aplicaes de rede sem o
compromisso de manter o foco em desempenho.
Nesse sentido, j foram identificadas possveis
otimizaes que devem trazer ganhos
significativos no tempo de processamento das
mensagens no controlador, como, por exemplo,
tornar o controlador multitarefa, de forma a
realizar o processamento paralelo das
mensagens e, tambm, a implementao de
mensagens que agreguem mais informao,
resultando em um menor chaveamento de
contexto da aplicao para processar cada
pacote recebido.
Em contrapartida, pode-se observar o melhor
desempenho de fast path do RouteFlow, que a
forma de encaminhamento mais relevante.
Nesse modo, a tabela de fluxos encaminhada
mais rapidamente, se comparado ao modo
longest prefix match, que utilizado nas tabelas
de encaminhamento IP.
Tabela 2 Tempo de resposta ICMP
Equipamento
Slow path [ms] Fast path [ms]
Tmed. T90% Tmed. T90%
CISCO 3560-e C. 5,46 7,75 0,100 0,130
Extreme x450-e 11,30 14,00 0,106 0,141
CPqD Enterprise 14,20 17,30 0,101 0,147
RouteFlow 116,00 138,00 0,082 0,119
3.3 Discusso dos resultados e trabalhos
futuros
Os resultados alcanados na avaliao do
prottipo sugerem o grande potencial do
RouteFlow como soluo de roteamento para
redes de campus/corporativas, mediante o ganho
de flexibilidade e o poder de inovao
proporcionados. As questes pertinentes ao
desempenho no inviabilizam a proposta, uma
vez que j foram identificadas otimizaes e
outras melhorias decorrentes da maturidade do
protocolo OpenFlow.
Como em qualquer abordagem baseada em
controladores centralizados, tornam-se desafios
os aspectos de escalabilidade, resilincia a
falhas e segurana. Vale a pena notar que a
centralizao do modelo OpenFlow somente
lgica. No existe nenhuma restrio a uma
implementao distribuda dos elementos
controladores para atender aos requisitos de
escala, desempenho e confiabilidade da rede.
Esforos atuais no aprimoramento da arquitetura
nesses aspectos incluem a distribuio do plano
de controle virtual em mltiplos servidores, a
adoo de tcnicas avanadas de virtualizao
para o balanceamento e migrao das MVs, e
outras melhores prticas da programao de
sistemas em nuvem (cloud computing) para
tornar a plataforma escalvel e tolerante a falhas
(ex.: BD distribuda do tipo NoSQL, replicao do
estado em controladores backup) (KOPONEN
et al., 2010).
Outros aspectos da proposta, que merecem
consideraes adicionais e so objeto de estudo,
incluem o isolamento entre as MVs
(FERNANDES et al., 2010) e a materializao do
conceito de roteamento como servio (KELLER;
REXFORD, 2010). Dessa forma, pode-se obter
topologias lgicas independentes sobre uma
mesma rede, que executem protocolos distintos,
resultando em uma abordagem de virtualizao
com um melhor aproveitamento dos recursos da
infraestrutura, que, agora, pode ser
compartilhada com diferentes propsitos
(CASADO et al., 2010).
Outra questo pertinente o gargalo observado
nas implementaes disponveis do OpenFlow
quanto ao tamanho da tabela de fluxos (entre 2 e
4 mil) e capacidade de instalao de novas
entradas por segundo (valor em torno de
100 fluxos por segundo). Essas limitaes so
transitrias e sero contornadas com o avano
das especificaes. Por exemplo, a partir da
verso 1.1 do protocolo OpenFlow possivel
expor e controlar as tabelas L2/L3 do hardware.
Outras tcnicas para reduzir o consumo das
entradas em hardware incluem algoritmos que
escolhem aquelas entradas mais utilizadas
(SARRAR et al., 2010). Essas e outras questes
encontram-se atualizadas na agenda de P&D do
projeto (ROUTEFLOW, 2011).
Concluso
O conceito de redes definidas por software
decorrente da disponibilidade de um protocolo
aberto, como o OpenFlow promete um modelo
disruptivo de inovao tecnolgica de potencial
impacto nos cenrios de convergncia ampla
(consolidao de planos de controle de redes
heterogneas) e de computao em nuvem
(integrao da rede com recursos de TI).
Equipamentos de rede programveis podero
servir de base para o incio de um ciclo de
inovao aberta e rpida, envolvendo
pesquisadores, engenheiros e desenvolvedores
de software da academia, dos institutos de
cincia e tecnologia, dos fabricantes de
equipamentos, das operadoras de
telecomunicaes e dos provedores de servios
de Internet. Essas inovaes se daro tanto no
mbito dos controladores como das aplicaes
que so executadas nesses controladores. Por
aplicaes entenda-se algoritmos, protocolos,
servios e aplicaes de controle e gerncia de
redes e servios. Alm disso, o movimento de
inovao aberta, decorrente do modelo
OpenFlow, poder alavancar e induzir um grande
desenvolvimento na rea de redes e tecnologias
da informao e computao de uma forma
considervel, como ocorreu com os
computadores pessoais com o advento dos
sistemas operacionais DOS, do Windows, do
Linux e da consolidao destes por meio de
tcnicas de virtualizao que dominam,
atualmente, o mundo das tecnologias da
informao.
Em resumo, os principais benefcios e impactos
do advento da tecnologia OpenFlow incluem:
1. Capacidade de inovao (possivelmente
aberta) em solues de redes e servios
para os proprietrios de infraestrutura, os
provedores de servios e a comunidade
de pesquisa.
2. Oportunidade para que novas empresas
possam competir e inovar na rea de
aplicaes avanadas para gerenciamento
e controle de redes de pacotes.
3. Novos modelos de negcio que
promovem reduo de CAPEX e OPEX
por meio de novos servios atravs da
alocao dinmica de fatias/recursos da
rede, por exemplo e de
reaproveitamento de ativos
virtualizao/consolidao.
4. Reduo do custo de manuteno dos
equipamentos, atravs, por exemplo, da
incorporao de novos protocolos, da
atualizao do hardware do equipamento,
etc.
5. Reduo do tempo de implementao de
novas funcionalidades nos equipamentos
e de integrao de solues de redes
especializadas s demandas do cliente
final.
6. Simplificao e barateamento dos
equipamentos de rede pela diminuio
dos requisitos mnimos do software
embarcado e das pilhas de protocolos
proprietrias.
7. Consolidao dos planos de controle e da
gerncia de infraestruturas de rede,
facilitando a migrao para novos
protocolos-padro e tecnologias de rede
de transporte.
Como exemplo de inovao sobre redes
programveis com OpenFlow, foi apresentada a
proposta do RouteFlow, que representa uma
abordagem expansvel (scale-out) para
arquiteturas de redes de pacotes. Com o plano
de controle externo ao dispositivo de rede, passa
a existir maior independncia entre esse plano e
o de encaminhamento, de forma que ambos
escalem e evoluam separadamente. Nesse
sentido, o RouteFlow possibilita o surgimento de
redes mais baratas e flexveis, mantendo
compatibilidade com redes legadas e apoiando
uma evoluo das redes em que a conectividade
IP possa se tornar um produto (commodity)
ofertado em um modelo de plataforma como
servio (KELLER; REXFORD, 2010) e a
diferenciao dos servios dos operadores possa
se dar pelas potenciais inovaes do paradigma
de redes definidas por software.
Agradecimentos
Os autores agradecem o apoio dado a este
trabalho, desenvolvido no mbito do projeto
Arquitetura de Redes para Comunicaes
Mveis IP que contou com recursos do Fundo
para o Desenvolvimento Tecnolgico das
Telecomunicaes FUNTTEL, do Ministrio
das Comunicaes, atravs do Convnio
n 002/2007 com o Ministrio das Comunicaes.
Referncias
ANWER, M. B. et al. Switchblade: a platform for
rapid deployment of network protocols on
programmable hardware. In: SIGCOMM 10.
Proceedings... New York, USA: ACM, 2010.
p.183-194.
ARGYRAKI, K. et al. Can software routers scale?
In: PRESTO 08. Proceedings... New York, USA:
ACM, 2008. p. 21-26.
CASADO, M. et al. Ethane: Taking Control of the
Enterprise. In: SIGCOMM '07. Proceedings...
New York, USA: ACM, 2007.
______. Virtualizing the network forwarding
plane. In: PRESTO 10. Proceedings...
Philadelphia, USA, 2010.
CHOWDHURY, M.; BOUTABA, R. Network
Virtualization: State of the Art and Research
Challenges. IEEE Communications Magazine,
v. 47, n. 7, p. 20-26, 2009.
FERNANDES, N. et al. Virtual networks: isolation,
performance, and trends. Annals of
Telecommunications, p. 1-17. 2010.
GREENE, K. TR10: Software-Defined
Networking. MIT Technology Review. 2009.
Disponvel em:
<http://www.technologyreview.com/communicatio
ns/22120/>. Acesso em: 31 jan. 2011.
GUDE, N. et al. NOX: towards an operating
system for networks. SIGCOMM Computer
Communication Review, 38(3), p.105-110,
2008.
GUDLA, V. et al. Experimental Demonstration of
OpenFlow Control of Packet and Circuit
Switches. In: OPTICAL FIBER CONFERENCE
(OFC/NFOEC'10). Proceedings... San Diego,
USA, 2010.
HAMILTON, J. Networking: The last bastion of
mainframe computing. 2009. Disponvel em:
<http://perspectives.mvdirona.com/2009/12/19/N
etworkingTheLastBastionOf-
MainframeComputing.aspx>. Acesso em: 31 jan.
2011.
INTERNET ENGINEERING TASK FORCE
(IETF). Forwarding and Control Element
Separation (ForCES), WG, 2011. Disponvel em:
<http://datatracker.ietf.org/wg/forces/charter/>.
Acesso em: 31 jan. 2011.
JUNIPER NETWORKS. Network Operating
System Evolution. White paper, Oct. 2010.
KELLER, E.; REXFORD, J. The 'Platform as a
Service' model for networking. In: INM/WREN.
Proceedings... San Jose, USA, 2010.
KOPONEN, T. et al. Onix: A distributed control
platform for large-scale production networks. In:
OSDI10. Proceedings... Vancouver, Canada,
Oct. 2010.
MCKEOWN, N. et al. OpenFlow: enabling
innovation in campus networks. SIGCOMM
Computer Communication Review, 38,
p.69-74, 2008.
NASCIMENTO, M. R. et al. RouteFlow:
Roteamento Commodity Sobre Redes
Programveis. In: XXIX SIMPSIO BRASILEIRO
DE REDES DE COMPUTADORES - SBRC'2011,
Campo Grande, MS, Brasil, 2011.
Proceedings...
NOX. An open-source OpenFlow controller.
2011. Disponvel em: <http://noxrepo.org>.
Acesso em: 31 jan. 2011.
SARRAR, N. et al. FIBIUM towards hardware
accelerated software routers. In: EUROVIEW
2010 (poster session).
SHERWOOD, R. et al. Can the production
network be the testbed? In: OSDI10.
Proceedings... USENIX Association, Vancouver,
Canada, 2010.
The OPENFLOW Specification. 2010. Disponvel
em:
<http://www.openflowswitch.org/documents/openf
low-wp-latest.pdf>. Acesso em: 31 jan. 2011.
The QUAGGA Project. 2009. Disponvel em:
<http://www.quagga.net>. Acesso em: 31 jan.
2011.
The XORP Project. Extensible open router
platform. 2011. Disponvel em:
<http://www.xorp.org>. Acesso em: 31 jan. 2011.
The ROUTEFLOW Project. 2011. Disponvel em:
<https://sites.google.com/site/routeflow/>. Acesso
em: 31 mai. 2011.
YAP, K. K. et al. Blueprint for Introducing
Innovation into Wireless Mobile Networks. In:
VISA'10, New Delhi, India, 2010. Proceedings...
New York: ACM, 2010.
Abstract
For some time we have seen the need for greater openness and flexibility of networking equipment, not
only for research purposes, but also in search of in-house innovation. Todays networking gear follows the
model of computer mainframes, with closed software running on proprietary hardware. This approach
results in expensive solutions and prevents equipment owners to put new ideas into practice. Advances in
the standardization of OpenFlow as a hardware-independent, open protocol to control the networking gear
of packet networks introduces the notion of software-defined networks, a new paradigm for innovation
with a disruptive potential comparable to the emergence of operating systems in the computer and mobile
device industries. This paper introduces the principles of OpenFlow and presents the RouteFlow as an
example of innovative ongoing work on open-source routing services over commodity hardware.
Key words: Packet networks. Routing. Switching. Free Software. Virtualization.

Open Flow

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Open Flow

Transféré par

Droits d'auteur :

Formats disponibles

OpenFlow e redes definidas por software: um

novo paradigma de controle e inovao em

Vous aimerez peut-être aussi