Redes Denidas por Software: uma abordagem sist emica para

o desenvolvimento das pesquisas em Redes de Computadores

Dorgival Guedes
1,2
, Luiz Filipe Menezes Vieira
1
, Marcos Menezes Vieira
1
,
Henrique Rodrigues
3
, Rog erio Vinhal Nunes
1
1
Departamento de Ci encia da Computac ao Universidade Federal de Minas Gerais
2
International Computer Science Institute, Berkeley
3
HP Laboratories, Palo Alto
{dorgival,lfvieira,mmvieira,rogervn}@dcc.ufmg.br,
henriquesilvar@gmail.com
Resumo. Redes Denidas por Software (Software Dened Networks, ou SDN)
constituem um novo paradigma para o desenvolvimento de pesquisas em redes
de computadores que vem ganhando a atenc ao de grande parte da comuni-
dade acad emica e da ind ustria da area. Muita da atenc ao at e o momento tem
sido voltada para o padr ao OpenFlow, um dos elementos que tornaram possvel
esse enfoque. Entretanto, Redes Denidas por Software v ao al em de OpenFlow,
abrindo novas perspectivas em termos de abstrac oes, ambientes de controle e
aplicac oes de rede que podem ser desenvolvidas de forma simples e livre das
limitac oes das tecnologias de rede atuais. Este minicurso adota uma aborda-
gem sist emica da area, com aspectos de teoria e pr atica. Na parte te orica,
discutimos os diversos componentes de um sistema de rede denido por soft-
ware, incluindo soluc oes para virtualizac ao dos elementos de rede, sistemas
operacionais de rede e novas aplicac oes, bem como os desaos de pesquisa
que esse paradigma ainda precisa enfrentar e os diversos esforcos de pesquisa
em andamento no Brasil e no mundo. Para ilustrar as novas possibilidades de
desenvolvimento que o paradigma oferece, a parte pr atica foca no sistema ope-
racional de redes POX, desenvolvido especicamente para ns de pesquisa e
ensino.
Abstract. Software Dened Networks (SDN) are a new paradigm for the deve-
lopment of research in computer networks, which has been getting the attention
of the academic community and the network industry. A lot of the attention so
far has focused on the OpenFlow standard, one of the elements which make
this approach possible. However, Software Dened Networks go way beyond
OpenFlow, creating new perspectives in terms of abstractions, control environ-
ments and network applications which can be developed easily and without the
limitations of the current network technologies. This short course take a syste-
mic approach to the topic, with theoretical and practival aspects. Considering
the theory, we discuss the various components of a software-dened network
system, including issues such as network element virtualization, the structure
of the network operating system and its applications, as well as the challenges
this new approach still has to face, and the ongoing research efforts in Brazil
and around the world. To illustrate the new development possibilities offered by
the new paradigm, the practical part of the course focuses on the POX network
operating system, created with research and teaching in mind.
1. Introduc ao
A comunidade de redes se encontra hoje em uma situac ao complexa: o sucesso da area
pode ser considerado estrondoso, j a que hoje a tecnologia de redes de computadores per-
meia todos os nveis da sociedade. A maioria das atividades da sociedade hoje de al-
guma forma atravessa uma ou mais redes de computadores. A tecnologia est a nos lares,
na forma de redes domiciliares, nas rotinas de implementac ao de polticas p ublicas, na
forma do governo eletr onico, na educac ao, onde a Web se tornou uma das fontes essenci-
ais de informac ao para os estudantes nos diversos nveis. A Internet se tornou um artefato
conhecido e acessado por uma frac ao signicativa da populac ao e iniciativas de inclus ao
digital s ao desenvolvidas em diversas esferas com o objetivo de expandir seu alcance,
idealmente a toda a populac ao mundial.
Tamanho sucesso, entretanto, traz consigo um problema para a comunidade de
pesquisa. Como grande parte da sociedade depende hoje da Internet em suas atividades
do dia-a-dia e tecnologias de acesso ` a rede se tornaram commodities de f acil acesso, es-
tabilidade se tornou uma caracterstica essencial da Internet. Isso signica que pesquisas
com novos protocolos e tecnologias n ao s ao mais possveis na Internet em geral, devido
ao risco de interrupc ao das atividades para as quais ela j a se tornou ferramenta essencial.
N ao s o isso, mas tamb em a economia de escala possvel pelo crescimento da rede e a
larga adoc ao das tecnologias j a desenvolvidas inviabiliza a inserc ao de novas tecnologias
que dependam de alterac oes do hardware a ser utilizado.
Mesmo pesquisadores trabalhando em iniciativas como backbones de pesquisa
b asica, como a Internet2, se v em frente a um problema complexo para justicar a adoc ao
em larga escala das tecnologias desenvolvidas nesses ambientes. O potencial de ruptura
de tais avancos se torna um forte argumento contra sua adoc ao.
Esses problemas levaram diversos pesquisadores a armar que a arquitetura de
redes de computadores em geral e a rede mundial (a Internet) atingiram um nvel de
amadurecimento que as tornaram pouco exveis. A express ao usada em muitos casos e
que a Internet est a calcicada (ossied, em ingl es), referindo-se ao processo que substitui
cartilagens (mais el asticas) por ossos ao longo do envelhecimento dos seres vivos.
Para tentar contornar esse problema, a comunidade de pesquisa em Redes de
Computadores tem investido em iniciativas que levem ` a implantac ao de redes com
maiores recursos de programac ao, de forma que novas tecnologias possam ser inse-
ridas na rede de forma gradual. Exemplos de iniciativas desse tipo s ao as propostas
de redes ativas (active networks) [Tennenhouse and Wetherall 2007], de testbeds como
o PlanetLab [Peterson and Roscoe 2006] e, mais recentemente, do GENI [Turner 2006,
Elliott and Falk 2009]. Redes ativas, apesar do seu potencial, tiveram pouca aceitac ao
pela necessidade de alterac ao dos elementos de rede para permitir que se tornassem pro-
gram aveis. Iniciativas mais recentes, como PlanetLab e GENI, apostam na adoc ao de
recursos de virtualizac ao para facilitar a transic ao para novas tecnologias. Apesar de se-
rem consideradas de grande potencial no longo prazo, tais iniciativas ainda enfrentam
desaos em quest oes como garantir o desempenho exigido pelas aplicac oes largamente
utilizadas hoje utilizando-se tais elementos de rede virtualizados.
Uma outra forma de abordar o problema, a m de oferecer um caminho de
menor impacto e que possa ser implementado em prazos mais curtos e com bom de-
sempenho, consiste em estender o hardware de encaminhamento de pacotes de forma
mais restrita. Considerando-se que a operac ao que precisa de alto desempenho nos
elementos de comutac ao atual e o encaminhamento de pacotes, algumas iniciativa
prop oem manter essa operac ao pouco alterada, para manter a viabilidade de desen-
volvimento de hardware de alto desempenho, mas com uma possibilidade de maior
controle por parte do administrador da rede. Essa proposta se inspira em uma tec-
nologia j a largamente adotada atualmente, o chaveamento (encaminhamento) base-
ado em r otulos program aveis, popularizado pelo MPLS (Multi-protocol Label Swit-
ching) [Davie and Farrel 2008, Kempf et al. 2011].
Com MPLS, o controle no sobre o tr afego de rede se torna possvel ao se atribuir
a cada pacote um r otulo (label) que determina como o mesmo ser a tratado pelos elemen-
tos de rede. Explorando esse recurso, administradores de rede podem exercer controle
diferenciado sobre cada tipo de tr afego de rede, assumindo que os mesmos possam ser
identicados para receberem r otulos apropriados. Com base nessa observac ao, uma ideia
trabalhada por diversos pesquisadores e a manutenc ao de um hardware de encaminha-
mento de alto desempenho, com a possibilidade de permitir que o administrador de rede
(ou o desenvolvedor de aplicac oes para a rede) determine como uxos sejam rotulados e
encaminhados.
1.1. Origens
A iniciativa mais bem sucedida nesse sentido foi, sem d uvida, a denic ao da interface e
do protocolo OpenFlow [McKeown et al. 2008]. Com OpenFlow, os elementos de enca-
minhamento oferecem uma interface de programac ao simples que lhes permite estender o
acesso e controle da tabela de consulta utilizada pelo hardware para determinar o pr oximo
passo de cada pacote recebido. Dessa forma, o encaminhamento continua sendo eciente,
pois a consulta ` a tabela de encaminhamento continua sendo tarefa do hardware, mas a de-
cis ao sobre como cada pacote deve ser processado pode ser transferida para um nvel
superior, onde diferentes funcionalidades podem ser implementadas. Essa estrutura per-
mite que a rede seja controlada de forma estensvel atrav es de aplicac oes, expressas em
software. A esse novo paradigma, deu-se o nome de Redes Denidas por Software, ou
Software Dened Networks (SDN).
Do ponto de vista hist orico, SDNs t em sua origem na denic ao da arquite-
tura de redes Ethane, que denia uma forma de se implementar polticas de con-
trole de acesso de forma distribuda, a partir de um mecanismo de supervis ao centrali-
zado [Casado et al. 2009]. Naquela arquitetura, cada elemento de rede deveria consultar
o elemento supervisor ao identicar um novo uxo. O supervisor consultaria um grupo
de polticas globais para decidir, com base nas caractersticas de cada uxo, como o ele-
mento de encaminhamento deveria trat a-lo. Essa decis ao seria comunicada ao comutador
na forma da programac ao de uma entrada em sua tabela de encaminhamento com uma
regra adequada para o novo uxo (que poderia, inclusive, ser seu descarte). Esse modelo
foi posteriormente formalizado por alguns dos autores na forma da arquitetura OpenFlow.
1.2. Motivac ao
Desde seu surgimento, diversos pesquisadores da area de Redes de Computadores e em-
presas voltadas para o desenvolvimento de equipamentos e sistemas de ger encia de redes
t em voltado sua atenc ao para o paradigma de Redes Denidas por Software (SDN). O
Open Networking Summit, um encontro de pesquisadores e prossionais da ind ustria, or-
ganizado recentemente pela Universidade de Stanford e a empresa Nicira, teve umn umero
de participantes muito acima do esperado pelos organizadores, resultando em 250 inscri-
tos e uma lista de espera de mais de 250 nomes. Outro indicador desse interesse e o
n umero de publicac oes em confer encias da area que abordam algum elemento de Redes
Denidas por Software. No SBRC 2011, por exemplo, mais de 10 trabalhos forcaram
aspectos da area.
Esse interesse se deve ` as diversas possibilidades de aplicac ao do paradigma, que se
apresenta como uma forma potencial de implantac ao do que se convencionou denominar
Internet do Futuro. Com a proposta de uma interface de programac ao para os elementos
de comutac ao da rede, como o padr ao OpenFlow, fabricantes e pesquisadores abracaram a
ideia de uma estrutura de redes onde a comutac ao de pacotes n ao precisa mais ser denida
pelo princpio de roteamento de redes Ethernet ou IP, mas que pode ser controlado por
aplicac oes (software) desenvolvido independentemente do hardware de rede. Al em de um
modelo de refer encia de um comutador OpenFlow implementado como um processo de
usu ario e de uma implementac ao de um comutador no espaco do kernel para ambientes
virtualizados, o Open vSwitch, diversos fabricantes j a oferecem no mercado produtos que
implementa a interface OpenFlow.
Um aspecto importante e que Redes de Denidas por Software constituem um
universo muito maior que aquele denido pelo padr ao OpenFlow. OpenFlow oferece,
por exemplo, uma soluc ao simples para a criac ao de diversas redes virtuais sobre uma
infraestrutura fsica, onde cada rede virtual e composta por switches nvel 2, roteadores
e gateways de aplicac ao tradicionais. Mas o paradigma de Redes Denidas por Soft-
ware tamb em abre a possibilidade de se desenvolver novas aplicac oes que controlem os
elementos de comutac ao de uma rede fsica de formas impensadas no passado.
Para se desenvolver essas novas aplicac oes, e importante se compreender a funcio-
nalidade de controladores de rede (tamb em denominados Sistemas Operacionais de Rede
ou Network Hypervisors). Esses elementos oferecem um ambiente de programac ao onde
o desenvolvedor pode ter acesso aos eventos gerados por uma interface de rede que siga
um padr ao como OpenFlow e pode tamb em gerar comandos para controlar a infraestru-
tura de chaveamento. Com esse ambiente, torna-se mais simples implementar polticas
de seguranca baseadas em nveis de abstrac ao maiores que enderecos Ethernet ou IP, que
cubram todos os pontos de rede, por exemplo. Da mesma forma, com SDNs e possvel
implementar controladores de rede que implementem l ogicas de monitorac ao e acompa-
nhamento de tr afego mais sosticadas, ou soluc oes que oferecam novas abstrac oes para
os usu arios da rede, como cada usu ario de um datacenter ter a vis ao de que todas as suas
m aquinas est ao ligadas a um switch unico e privado, independente dos demais.
Este minicurso foi concebido tendo essas possibilidades em mente, com o ob-
jetivo de oferecer aos alunos, pesquisadores e prossionais da area uma introduc ao ao
paradigma e ` as oportunidades que ele oferece. Para isso apresentar o POX, um controla-
dor desenvolvido especicamente para o ambiente de pesquisa e ensino, com a proposta
de ser facilmente extensvel e de f acil entendimento.
1.3. Organizac ao do texto
Com a motivac ao apresentada na sec ao anterior em mente, este material est a organizado
nas seguintes sec oes:
1. Introduc ao esta sec ao, cujo objetivo foi introduzir o tema de forma abstrada;
2. Componentes de um sistema baseado em SDNs apresenta uma denic ao mais
renada do conceito de SDN, abordando os elementos normalmente identica-
dos com o paradigma de forma a dar ao leitor uma vis ao geral do papel de cada
componente e das relac oes entre eles;
3. Programac ao dos elementos de rede discute os requisitos mnimos da interface
de programac ao, com foco principal na denic ao do modelo OpenFlow;
4. Particionamento de recursos (virtualizac ao) detalha o conceito de slicing da
rede e seu uso para permitir a implementac ao de redes virtuais;
5. Controladores de rede aborda os principais projetos de controladores dis-
ponveis para a implementac ao de SDNs;
6. Aplicac oes discute como o conceito de SDN pode ser aplicado a diferentes
contextos e lista iniciativas de pesquisa relacionadas no Brasil e no mundo;
7. Desenvolvimento de sistemas utilizando POX apresenta os detalhes da arquite-
tura do controlador POX e os elementos principais para a programac ao do mesmo;
8. Desaos de pesquisa discute desaos para a arquitetura SDN que devem ser
abordados para viabilizar sua aplicac ao nos diversos contextos;
9. Considerac oes nais oferece um fechamento da discuss ao, amarrando os di-
versos conceitos e pontos de vista apresentados.
Ao nal deste trabalho, esperamos que os participantes tenham uma vis ao das possibili-
dades da area e um entendimento de como um controlador como POX pode ser utilizado
para colocar em pr atica diferentes ideias.
2. Componentes de um sistema baseado em SDNs
Com base na discuss ao anterior, de forma abstrata, podemos dizer que uma Rede Denida
por Software (SDN) e caracterizada pela exist encia de um sistema de controle (software)
que pode controlar o mecanismo de encaminhamento dos elementos de comutac ao da rede
por uma interface de programac ao bem denida. De forma mais especca, os elementos
de comutac ao exportam uma interface de programac ao que permite ao software inspeci-
onar, denir e alterar entradas da tabela de roteamento do comutador como ocorre, por
exemplo, com comutadores OpenFlow. O software envolvido, apesar de potencialmente
poder ser uma aplicac ao monoltica especialmente desenvolvida, na pr atica tende a ser or-
ganizado com base em um controlador de aplicac ao geral, em torno do qual se contr oem
aplicac oes especcas para o m de cada rede.

E possvel, ainda, utilizar-se um divisor de
vis oes para permitir que as aplicac oes sejam divididas entre diferentes controladores. A
gura 1 ilustra essa organizac ao, para uma rede com elementos com e sem o.
2.1. Elementos de comutac ao program aveis
Obviamente, o princpio b asico de redes denidas por software e possibilidade
de programac ao dos elementos de rede. Como mencionado anteriormente, essa
programac ao, ao contr ario de propostas anteriores, como Redes Ativas, se restringe a
uma manipulac ao simples de pacotes baseado no conceito de uxos, ou seja, sequ encias
D
i
v
i
s
o
r
Figura 1. Estrutura geral de uma SDN
de pacotes que compartilham atributos com valores bem denidos. A denic ao exata
do que constitui um uxo e func ao exatamente dos recursos oferecidos pela interface de
programac ao.
A operac ao de encaminhamento dos elementos de comutac ao em redes baseadas
em pacotes segue um princpio simples: cada pacote recebido em uma das interfaces do
comutador e inspecionado e gera uma consulta ` a tabela de encaminhamento do comu-
tador. No caso de switches Ethernet, essa consulta e baseada no endereco de hardware
(MAC) de destino do pacote; em roteadores IP, em um prexo do endereco IP de destino;
em redes ATM, nos valores dos campos VCI/VPI da c elula ATM, etc. Caso a consulta
n ao tenha sucesso, o pacote e descartado. Usualmente, h a ainda a possibilidade de se de-
nir um comportamento padr ao (default) nos casos de insucesso. Uma vez identicado o
destino do pacote, o mesmo atravessa as interconex oes internas do comutador para atingir
a porta de destino, onde ela e enleirada para transmiss ao.
Ao longo da evoluc ao das redes de computadores, esse processo de consulta (loo-
kup) e chaveamento (switching) j a foi amplamente estudado, resultando hoje em soluc oes
baseadas usualmente em hardware com desempenho suciente para acompanhar as taxas
de transmiss ao do meio (wire speed switching).
2.2. Divisores de recursos/vis oes
A possibilidade de se associar todo um processamento complexo, denido por software, a
pacotes que se encaixem em um determinado padr ao abriu a possibilidade de se associar
diversos comportamentos em uma mesma rede. Tornou-se vi avel, por exemplo, manter
um comportamento tradicional para uxos denominados de operac ao e dar tratamento
diferente para uxos de pesquisa. Uma nova possibilidade, imediatamente identicada
por pesquisadores, e a de estender essa divis ao para permitir que diferentes tipos de pes-
quisa sejam colocados em operac ao em paralelo, na mesma rede fsica. Para isso, seria
necess ario estender o modelo com a noc ao de vis oes diferentes da rede, dividindo os
recursos entre diferentes controladores.
Estendendo o modelo de comportamento dos elementos de chaveamento, basea-
dos em consultas usando campos do pacote, o processo de divis ao de recursos se baseia
exatamente em denir partic oes do espaco de consulta disponvel. Isso pode ser visto
como uma extens ao do princpio de particionamento baseado em padr oes parciais: alguns
dos bits usados no processo de consulta s ao utilizados para denir espacos que devem
ser tratados de forma isolada. Essa pr atica e basicamente uma extens ao do princpio de
particionamento do tr afego Internet baseado em n umero de porto, por exemplo.
2.3. Controlador
Uma vez denida uma interface de programac ao para os elementos de chaveamento, seria
possvel desenvolver uma aplicac ao que utilizasse diretamente as chamadas dessa inter-
face para controlar cada switch separadamente. Entretanto, esse enfoque traz limitac oes
semelhantes ` aquelas associadas ao desenvolvimento de software diretamente ligado a um
elemento de hardware: o desenvolvimento exige que o programador lide com tarefas de
baixo nvel na interface com o dispositivo e o sofware resultante e normalmente muito
dependente do hardware adotado. Novos desenvolvimentos exigem que todas as funcio-
nalidades de baixo nvel sejam reimplementadas.
Essas limitac oes levaram ` a identicac ao da necessidade de um novo nvel na
arquitetura, que concentre as tarefas de manipulac ao direta dos dispositivos de rede e
ofereca uma abstrac ao de mais alto nvel para o desenvolvedor. Esse elemento, talvez
mais que a arquitetura OpenFlow, dene a natureza de uma rede denida por software.
Em uma analogia direta das funcionalidades de um sistema operacional, esse elemento
age como um sistema operacional para a rede: provendo o controle direto dos dispositi-
vos de rede, oferecendo uma interface mais eciente para os desenvolvedores, isolando
os detalhes de cada componente.
O controlador de rede, ou sistema operacional de rede, ou, ainda, hypervisor da
rede (em alus ao ao conceito derivado da area de sistemas virtualizados) pode, dessa
forma, concentrar a comunicac ao com todos os elementos program aveis que comp oem
a rede e oferecer uma vis ao unicada do estado da rede [Casado et al. 2010b]. Sobre
essa vis ao, comandos podem ser executados e outros programas podem ser desenvolvidos
que implementem novas funcionalidades. Um dos pontos fortes de SDNs e exatamente a
formac ao dessa vis ao centralizada das condic oes da rede, sobre a qual e possvel desen-
volver an alises detalhadas e chegar a decis oes operacionais sobre como o sistema como
um todo deve operar. A exist encia dessa vis ao global simplica a representac ao dos pro-
blemas e a tomada de decis ao, bem como a express ao das ac oes a serem tomadas.

E importante observar que essa noc ao de vis ao unica e centralizada da rede como
expressa pelo sistema operacional da rede e uma vis ao l ogica. N ao necessariamente exige
que o controlador opere como um elemento concentrador, sicamente localizado em um
ponto unico do sistema. A abstrac ao de vis ao global pode muito bem ser implementada de
forma distribuda, seja pela divis ao dos elementos da vis ao entre domnios diferentes, seja
pela implementac ao de um controlador realmente distribudo, que se valha de algoritmos
de consenso, por exemplo, para manter a vis ao consistente entre suas partes.
Diferentes tipos de controladores de rede j a foram desenvolvidos dentro do con-
texto de redes denidas por software. Muitos deles se apresentam como ambientes
de tempo de execuc ao (run-time systems) que oferecem uma interface imperativa para
programac ao da rede. A linguagem utilizada, nesse caso, determina em grande parte o
estilo de desenvolvimento e as funcionalidades oferecidas. Outros controladores, entre-
tanto, ultrapassam a noc ao de uma interface de programac ao imperativa e oferecem novas
abstrac oes, como um ambiente de programac ao funcional ou declarativa. Nesses casos,
os recursos da linguagem utilizada se prestam ` a implementac ao de novas funcionalidades,
como detecc ao de conitos ou depurac ao automatizada da rede.
Muitos controladores j a implementados, desenvolvidos sem a preocupac ao b asica
de escalabilidade frente a grandes demandas, optam pela estrutura centralizada por sim-
plicidade. Por outro lado, alguns dos esforcos de desenvolvimento voltados para a
implantac ao em grandes sistemas, como os datacenters de grandes corporac oes, utili-
zam diferentes formas de distribuic ao para garantir a escalabilidade e disponibilidade do
sistema.
2.4. Aplicac oes de rede
Nesse contexto, considerando os controladores de SDN como o sistema operacional da
rede, o software desenvolvido para criar novas funcionalidades pode ser visto com a
aplicac ao que executa sobre a rede fsica. Valendo-se da vis ao unicada dos recursos
de rede que o controlador oferece, pode-se, por exemplo, implementar soluc oes de rotea-
mento especialmente desenhadas para um ambiente particular, controlar a interac ao entre
os diversos comutadores, oferecendo para os computadores a eles ligados a impress ao de
estarem ligados a um unico switch, ou a um unico roteador IP.
3. Programac ao dos elementos de rede
O princpio por tr as de Redes Denidas por Software e a capacidade de se controlar o
plano de encaminhamento de pacotes atrav es de uma interface bem denida. Sem d uvida,
a interface associada ao paradigma desde seu incio (de fato, um dos elementos motivado-
res da sua criac ao) e OpenFlow, apesar de n ao ser a unica forma de se implementar uma
SDN.
3.1. O padr ao OpenFlow
O OpenFlow e um padr ao aberto para Redes Denidas por Software que tem como prin-
cipal objetivo permitir que que se utilize equipamentos de rede comerciais para pesquisa
e experimentac ao de novos protocolos de rede, em paralelo com a operac ao normal das
redes. Isso e conseguido com a denic ao de uma interface de programac ao que permite
ao desenvolvedor controlar diretamente os elementos de encaminhamento de pacotes pre-
sentes no dispositivo. Com OpenFlow, pesquisadores podem utilizar equipamentos de
rede comerciais, que normalmente possuem maior poder de processamento que os comu-
tadores utilizados em laborat orios de pesquisa, para realizar experimentos em redes de
produc ao. Isso facilita a transfer encia dos resultados de pesquisa para a ind ustria.
Uma caracterstica b asica do modelo OpenFLow e uma separac ao clara entre os
planos de dados e controle em elementos de chaveamento. O plano de dados cuida do
encaminhamento de pacotes com base em regras simples (chamadas de ac oes na termino-
logia OpenFlow) associadas a cada entrada da tabela de encaminhamento do comutador
de pacotes (um switch ou roteador). Essas regras, denidas pelo padr ao, incluem (i)
encaminhar o pacote para uma porta especica do dispositivo, (ii) alterar parte de seus
cabecalhos, (iii) descart a-lo, ou (iv) encaminh a-lo para inspec ao por um controlador da
rede. Em dispositivos dedicados, o plano de dados pode ser implementado em hardware
utilizando os elementos comuns a roteadores e switches atuais. J a o m odulo de controle
permite ao controlador da rede programar as entradas dessa tabela de encaminhamento
com padr oes que identiquem uxos de interesse e as regras associadas a eles. O ele-
mento controlador pode ser um m odulo de software implementado de forma independente
em algum ponto da rede.
3.1.1. Estrutura e Possibilidades
Um grande trunfo da arquitetura OpenFlow e a exibilidade que ela oferece para se pro-
gramar de forma independente o tratamento de cada uxo observado, do ponto de vista de
como o mesmo deve (ou n ao) ser encaminhado pela rede. Basicamente, o padr ao Open-
Flow determina como um uxo pode ser denido, as ac oes que podem ser realizadas
para cada pacote pertencente a um uxo e o protocolo de comunicac ao entre comutador
e controlador, utilizado para realizar alterac oes dessas denic oes e ac oes. A uni ao de
uma denic ao de uxo e um conjunto de ac oes forma uma entrada da tabela de uxos
OpenFlow [McKeown et al. 2008].
Em um switch OpenFlow, cada entrada na tabela de uxos pode ser implemen-
tada como um padr ao de bits representado em uma mem oria TCAM (Ternary Content-
Addressable Memory). Nesse tipo de mem oria, bits podem ser representados como zero,
um ou n ao importa (dont care), indicando que ambos os valores s ao aceit aveis naquela
posic ao. Como o padr ao e programado a partir do plano de controle, uxos podem ser
denidos da forma escolhida pelo controlador (p.ex., todos os pacotes enviados a partir do
endereco fsico A para o endereco fsico B, ou todos os pacotes TCP enviados da m aquina
com endereco IP X para o porto 80 da m aquina com endereco IP Y). A gura 2 apresenta
uma vis ao geral de uma entrada da tabela OpenFlow. Cada pacote que chega a um co-
mutador OpenFlow e comparado com cada entrada dessa tabela; caso um casamento seja
encontrado, considera-se que o pacote pertence ` aquele uxo e aplica-se as ac oes relacio-
nadas ` a esse uxo. Caso um casamento n ao seja encontrado, o pacote e encaminhado para
o controlador para ser processado o que pode resultar na criac ao de uma nova entrada
para aquele uxo. Al em das ac oes, a arquitetura prev e a manutenc ao de tr es contadores
por uxo: pacotes, bytes trafegados e durac ao do uxo.
Figura 2. Exemplo de uma entrada na tabela de uxos OpenFlow.
Esse pequeno conjunto de regras cria diversas possibilidades, pois muitas das fun-
cionalidades que s ao implementadas separadamente podem ser agrupadas em um unico
controlador OpenFlow, utilizando um pequeno conjunto de regras. Alguns exemplos das
possibilidades s ao apresentadas na gura 3. As entradas representam o uso do switch
OpenFlow para realizar encaminhamento de pacotes na camada de enlace, implemen-
tar um rewall e realizar encaminhamento de pacotes na camada de enlace utilizando
VLANs, respectivamente.
Figura 3. Exemplos de uso de um Switch OpenFlow.
Apesar de possuir um conjunto pequeno de ac oes simples, alguns descrevem o
OpenFlow com uma analogia ao conjunto de instruc oes de um microprocessador x86
que, apesar de pequeno e simples, prov e uma vasta gama de possibilidades para o desen-
volvimento de aplicac oes. O OpenFlow cria possibilidades semelhantes para o desenvol-
vimento de aplicac oes no contexto de redes de computadores.
3.1.2. Limitac oes e futuras vers oes
A vers ao atual do OpenFlow e a 1.1, que ainda possui algumas limitac oes em termos do
uso do padr ao em circuitos opticos e uma denic ao de uxos que englobe protocolos que
n ao fazem parte do modelo TCP/IP. No entanto, a vers ao 2.0 est a sendo formulada e um
dos objetivos e eliminar algumas dessas limitac oes.
Alguns switches comerciais j a suportam o padr ao OpenFlow, como e o caso do HP
Procurve 5400zl, do NEC IP880 e do Pronto 3240 e 3290. Espera-se que ` a medida que a
especicac ao OpenFlow evolua, mais fabricantes de equipamentos de rede incorporem o
padr ao ` as suas soluc oes comerciais.
3.2. Implementac oes em software
A implementac ao de refer encia do modelo OpenFlow e um comutador em software, exe-
cutando no espaco de usu ario em uma m aquina Linux. Esse modelo tem sido utilizado
como base em diversos experimentos, mas carece de um melhor desempenho. Desen-
volvido para suprir essa lacuna, o Open vSwitch (OvS) e um switch virtual que segue a
arquitetura OpenFlow, implementado em software, com o plano de dados dentro do kernel
do sistema operacional Linux, enquanto o plano de controle e acessado a partir do espaco
de usu ario [Pfaff et al. 2009]. Em particular, essa implementac ao foi desenvolvida espe-
cicamente para controlar o tr afego de rede da camada de virtualizac ao em ambientes
virtualizados [Pettit et al. 2010].
Em sua implementac ao atual (gura 4), o Open vSwitch e composto por dois com-
ponentes principais: um m odulo presente no n ucleo do sistema operacional, denominado
Fast Path, e um componente no nvel de usu ario, o Slow Path. O fast path interage
ativamente com o tr afego de rede, pois e respons avel por procurar rotas na tabela de u-
xos e encaminhar pacotes de rede. J a o slow path e o componente do Open vSwitch onde
s ao implementadas as demais funcionalidades associadas ao plano de controle, como as
interfaces de congurac ao do switch, a l ogica de uma ponte com aprendizado (learning
bridge) e as funcionalidades de ger encia remota, etc. A interac ao entre os dois m odulos
se d a prioritariamente atrav es da manipulac ao da tabela de uxos.
Figura 4. Arquitetura do Open vSwitch.
Aimplementac ao do fast path e simples e seu c odigo e composto por poucas linhas
(em torno de 3000 um n umero de linhas bem pequeno quando comparado ` as 30.000 do
slow path). Existem dois motivos para essa decis ao de projeto, sendo que o primeiro deles
e o desempenho. O fast path e a parte crtica do sistema quando consideramos o tempo
de processamento e, portanto, quanto menor o processamento realizado para cada pacote,
maior a capacidade de processamento desse componente. Essa caracterstica torna indis-
pens avel a sua implementac ao como uma parte do sistema operacional, posicionando-o
mais pr oximo ` as NICs. Al em disso, como a l ogica implementada pelo fast path e de-
pendente das APIs do sistema operacional, manter a sua complexidade pequena facilita
a tarefa de portar o Open vSwitch a um outro sistema operacional. O segundo motivo e
o esforco reduzido em adaptar as funcionalidades do fast path ` a acelerac ao de hardware
(hardware acceleration/offoading), que eventualmente pode ser oferecida pela m aquina
fsica.
Al em de oferecer as funcionalidades da arquitetura OpenFlow, o OvS, na sua
congurac ao padr ao, opera como um switch Ethernet normal. Para simplicar a sua
integrac ao com o kernel Linux, o OvS emula as interfaces de rede daquele sistema e uti-
liza partes do c odigo fonte de seu m odulo bridge, que implementa o switch de rede padr ao
do Linux. Como resultado dessas decis oes de projeto, o Open vSwitch pode ser utilizado
como um substituto imediato para os switches virtuais adotados pelos VMMs baseadas
em Linux mais utilizados atualmente, como Xen, XenServer e KVM e vem sendo ado-
tado como o switch padr ao em diversas distribuic oes, mesmo quando as funcionalidades
da arquitetura OpenFlow n ao s ao utilizadas.
3.3. Outras propostas
Apesar do foco principal dos ambientes de Redes Denidas por Software hoje ser o mo-
delo/protocolo OpenFlow e a forma como ele exp oe os recursos do switch, h a outras
possibilidades de implementac ao de uma interface de programac ao que atenda os obje-
tivos do paradigma. O paradigma SDN n ao se limita ao OpenFlow, nem o exige como
elemento essencial.
A forma como comutadores MPLS podem ser programados para tratar cada uxo
combase no r otulo a ele associado mostramque essa tecnologia pode ser facilmente esten-
dida para a implantac ao de uma SDN [Davie and Farrel 2008]. Uma primeira iniciativa
nesse sentido utiliza o princpio da interface denida por OpenFlow sobre o comporta-
mento usual de roteadores MPLS [Kempf et al. 2011]. Nesse caso, os autores estendem
o modelo da tabela de encaminhamento do plano de dados de OpenFlow para incluir a
noc ao de porto virtual. Esse tipo de porto virtual armazena internamente as noc oes de
encapsulamento desencapsulament necess arios ao processamento de pacotes com MPLS.
Uma segunda proposta e o conceito de interface de rede sNICh [Ram et al. 2010].
Originalmente, sNICh foi apresentado como uma proposta para uma nova arquitetura de
rede para ambientes virtualizados, onde a divis ao do plano de dados e feita de forma a
dividir as tarefas de encaminhamento entre o host e a interface de rede. Essa divis ao visa
garantir a eci encia do encaminhamento entre m aquinas virtuais no mesmo hospedeiro e a
rede. Por se apresentar como uma opc ao para o uso de switches de software como o Open
vSwitch, mantendo uma estrutura program avel, e possvel se imaginar que a interface
denida para essa arquitetura tamb em possa ser usada para o controle de roteamento a
partir de um m odulo de software como um controlador SDN.
Finalmente, h a tamb em propostas para novas implementac oes que alteram a di-
vis ao de tarefas entre controlador e os switches, como no caso da arquitetura Devo-
Flow [Mogul et al. 2010]. O argumento dos autores e que no padr ao OpenFlow tradicio-
nal, a necessidade de que todos os uxos sejam acessveis para o controlador SDN imp oe
demandas sobre o hardware e limitac oes de desempenho que podem n ao ser aceit aveis em
alguns casos, em particular para uxos de alto desempenho e que podem ser denidos por
regras simples. Dessa forma, DevoFlow reduz o n umero de casos em que o controlador
precisa ser acionado, aumentando a eci encia. Muitas das soluc oes propostas para essa
arquitetura, inclusive, podem ser aplicadas diretamente em implementac oes OpenFlow
tradicionais. Um exemplo disso e a adoc ao de regras especcas (sem o uso de coringas,
como todos os elementos de identicac ao do uxo instanciados para o uxo particular a
ser tratado) para cada uxo que seja identicado pelo controlador.
4. Particionamento de recursos (virtualizac ao)
Redes denidas por software, ao denirem uma forma exvel de se alterar a funcionali-
dade da rede, abriram espaco para que pesquisadores e desenvolvedores usassem a rede
como ambiente de testes. Entretanto, ao se conectar os elementos de comutac ao de uma
rede a um controlador unico, a capacidade de se desenvolver e instalar novas aplicac oes
na rede ca restrita ao respons avel por aquele controlador. Mesmo que o acesso a esse
elemento seja compartilhado entre diversos pesquisadores, ainda h a a quest ao da garantia
de n ao-interfer encia entre as diversas aplicac oes e a restric ao de que todos devem utilizar
a mesma interface, sem opc oes.
Para se resolver esse problema, surgiu a demanda pela capacidade de se poder
dividir a rede em fatias (slices) e atribuir cada fatia a um controlador diferente. Uma
forma de se fazer esse tipo de divis ao de recursos de rede em contextos usuais e atrav es
do uso de VLANs (redes locais virtuais), onde um cabecalho especial e usado para denir
que cada pacote pertenca a uma rede virtual particular. O uso de VLANs, entretanto, tem
suas pr oprias limitac oes e est a amarrado em sua denic ao ` a tecnologia Ethernet (ou IEEE
802.x). Essa amarrac ao torna complexo sua aplicac ao em contextos onde as fatias devem
se estender por mais de uma tecnologia de rede.
Considerando a analogia de que o controlador de SDN se assemelha a um sis-
tema operacional da rede, uma forma de se implementar fatias na rede seria lancando
m ao do princpio de virtualizac ao. Dessa forma, os recursos da rede seriam virtuali-
zados e apresentados de forma isolada para cada desenvolvedor que desejasse ter seu
pr oprio controlador sobre a rede. Como no caso da virtualizac ao de m aquinas fsicas, a
virtualizac ao tamb em pode ser implementada sobre a rede fsica em diversos nveis, por
exemplo, abaixo do controlador ou acima do mesmo, como nos casos de virtualizac ao do
hardware ou virtualizac ao do sistema operacional.
A primeira soluc ao a ganhar larga aplicac ao em SDNs foi a divis ao di-
reta dos recursos OpenFlow da rede fsica (virtualizac ao do hardware), atrav es do
FlowVisor [Sherwood et al. 2009, Sherwood et al. 2010]. Nessa soluc ao, o FlowVisor
opera como um controlador de rede respons avel apenas pela divis ao do espaco de
enderecamento disponvel na rede OpenFlow. Fatias da rede s ao denidas pela uni ao,
intersec ao e/ou diferenca de valores dos diversos campos disponveis para identicac ao
de uxos OpenFlow, conforme ilustrado na gura 5. A denic ao dessas fatias contituem
regras, as quais denem as polticas de processamento.
Figure 2: We present a monitoring program that graphically displays ows in real time in their respective network slice. Slices are
dened by union, intersection, and difference of 10 packet eldsthree of which are shown here.
aspects orthogonal. This allows each technology to evolve
independently, avoiding new forms of ossication.
We believe that our demonstration highlights these architectural
features.
3. DEMONSTRATION
To visualize our four experiments, we display a custom slice
monitoring tool running on a large screen (Figure 2). The tool
dynamically shows in real time the test-bed topology and color-
coded ows from each experiment . The monitoring tool displays
a simultaneous view of the entire physical network topology (Fig-
ure 2,bottom layer) and the virtual topology corresponding to each
slice.
We further demonstrate that FlowVisor has exible and ne-
grained network slices control. These slices can be recursively
delegated (Figure 1). In our demonstration, Bob delegates a net-
work slice to Alice, who in turn re-delegates it to the Bicast ex-
periment. Further, FlowVisor allows slices to be dened along
any combination of ten packet header elds (Figure 2), includ-
ing physical layer (switch ports), link layer (src/dst mac addresses,
ether type), network layer (src/dst IP address, IP protocol), and
transport layer (src/dst UDP/TCP ports). Additionally, FlowVisor
slices can be dened with negation (all packets but TCP packets
with dst port 80), unions (ethertype is ARP or IP dst address is
255.255.255.255), or intersections (netblock 192.168/16 and IP
protocol is TCP). We believe that such ne-grained slicing will be
a useful tool for network researchers and administrators alike.
The four slices (two wired and two wireless) are chosen to show
the diversity of experiments that FlowVisor supports, and will each
be running an isolated slice specically carved for its needs.
Learning Switch A controller that performs the standard MAC-
address learning switch algorithm. The learning switchs net-
work slice is dened as the default, that is, any ow that does
not belong to any other experiment is part of this slice. We
include the learning switch to demonstrate how research and
non-research trafc can safely co-exist.
Mobile VMs In this experiment, a virtual machine (VM) running a
latency-sensitive video game is migrated live between servers
while maintaining the same IP address. The server and video
game software remain unchanged; an OpenFlow controller
performs dynamic re-writing of the trafc so that connectiv-
ity is maintained. This experiments slice is dened as all
game trafc on a specic UDP port. This experiment won
the SIGCOMM 2008 Best Demo award [1].
Hard Handover mobility agent This OpenFlow controller man-
ages a pair of mobile laptops running at Stanford. We demon-
strate that with OpenFlow, it is possible to re-route ows dy-
namically and seamlessly hand-off between an 802.11 access
point and a WiMAX base station. Hard handovers network
slice is dened as the packets destined to the MAC addresses
of the mobile laptops. To visualize the effect of the handover,
we display a video streamed to the laptops.
Bicasting mobility agent Setup similarly to hard handover, this
controller manages the trafc for a second pair of mobile
laptops. In this experiment, we demonstrate the effect of
bi-casting, i.e., duplicating packets along two independent
links. To visualize the effects of bicasting, we display a video
streaming to the laptops.
4. REFERENCES
[1] D. Erickson et al. A demonstration of virtual machine
mobility in an OpenFlow network. In Proceedings of ACM
SIGCOMM (Demo), page 513, Seattle, WA, Aug. 2008.
[2] K. Greene. Special reports 10 emerging technologies 2009.
MIT Technology Review, 2009. http:
//www.technologyreview.com/biotech/22120/.
[3] N. Gude, T. Koponen, J. Pettit, B. Pfaff, M. Casado,
N. McKeown, and S. Shenker. NOX: Towards and operating
system for networks. In ACM SIGCOMM Computer
Communication Review, July 2008.
[4] N. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar,
L. Peterson, J. Rexford, S. Shenker, and J. Turner. OpenFlow:
enabling innovation in campus networks. ACM SIGCOMM
Computer Communication Review, 38(2):6974, April 2008.
Figura 5. FlowVisor: denic ao de fatias com base em tr es atributos de uxos. Na -
gura, o domnio bicasting handover corresponde a um conjunto denido por uma faixa
de enderec os MAC e uma faixa de enderec os IP; mobile VMs engloba todos os pacotes
com uma certa faixa de n umeros de porto, exceto se contidos na faixa de bicasting han-
dover; nalmente, hard handover engloba dois conjuntos com enderec os IP e MAC em
faixas, exceto nos casos em que os portos correspondem ` a faixa de moble VMs.
Uma inst ancia de FlowVisor se coloca entre os diversos controladores e os dis-
positivos fsicos. Comandos dos controladores s ao observados para se certicar que as
regras por eles geradas n ao excedam a denic ao do domnio daquele controlador na rede.
Se necess ario, elas s ao re-escritas para estender os padr oes utilizados com a denic ao do
domnio. Por outro lado, mensagens enviadas pelos switches OpenFlow s ao inspeciona-
das e direcionadas para o controlador OpenFlow apropriado em func ao do seu domnio
de origem. A gura 6 ilustra esse processo. Como um controlador, e possvel inclusive a
construc ao de hierarquias de FlowVisors, cada um dividindo uma sec ao de um domnio
denido por uma inst ancia de um nvel anterior.
Aplicao
A.1
Aplicao
C.1
Aplicao
B.1
Aplicao
A.2
Controlador A Controlador C Controlador B
Regras para o
domnio A
Regras para o
domnio C
Regras para o
domnio B
Polticas
de
diviso
Traduo
Demultiplexao
!"#$%&'#(
Switches OpenFlow
nsero
de regra
Packet n
Figura 6. FlowVisor: organizac ao do sistema e uxo de comandos. Um comando de
inserc ao de regra originado em uma aplicac ao do domnio A passa pelo FlowVisor, que
traduz a regra para garantir que ela se aplique apenas ao domnio de A. Um pacote enca-
minhado por um switch OpenFlow para o controlador e processado pelo demultiplexador
para identicar qual o controlador do nvel acima que e repons avel por aquela faixa dos
atributos de entrada.
Flowvisor, entretanto, e apenas uma das formas possveis de se dividir os recurso
fsicos de uma SDN. Tamb em e possvel dotar o controlador de recurso de particiona-
mento de recursos, apesar dessa soluc ao ser menos adotada at e o momento. Al em disso,
o conceito de virtualizac ao tamb em pode ser aplicado aos elementos de rede visveis para
as aplicac oes. Por exemplo, um controlador pode organizar certas portas de um con-
junto de portas espalhadas por diversos comutadores da rede fsica subjacente e oferecer
a vis ao para a aplicac ao SDN de um unico switch, onde as diversas portas estejam di-
retamente interligadas. Esse tipo de abstrac ao pode ser util, por exemplo, para oferecer
domnios de isolamento de tr afego (apenas as portas pertencentes a tal switch virtual es-
tariam no mesmo domnio de broadcast Ethernet, por exemplo. Esse tipo de aplicac ao de
virtualizac ao e previsto, por exemplo, para o controlador POX, apesar de ainda n ao estar
completamente implementado.
5. Controladores de rede
Nesta sec ao s ao descritos os principais controladores SDN que existem atualmente. Apre-
sentamos uma breve motivac ao por tr as de cada um deles, suas caractersticas principais
e, em alguns casos, exemplos simples de programac ao ou uma descric ao dos elementos
principais da API.
5.1. NOX
NOX e o controlador original OpenFlow e tem como principal func ao hoje o desenvolvi-
mento de controladores ecientes em C++. Ele opera sobre o conceito de uxos de dados.
Ele checa o primeiro pacote de cada uxo e procura na tabela de uxos para determinar
a poltica a ser aplicada. O controlador gerencia o conjunto de regras instaladas nos swit-
ches da rede reagindo a eventos de rede. Atualmente a maioria dos projetos de pesquisa na
area s ao baseados no NOX, que e um sistema operacional simples para redes e que prov e
primitivas para o gerenciamento de eventos bem como as func oes para a comunicac ao
com os switches [Gude et al. 2008].
NOX dene uma s erie de eventos:
packet in(switch; port; packet), acionado quando o switch envia um pacote rece-
bido por uma porta fsica para o controlador.
stats in(switch; xid; pattern; packets; bytes) acionado quando o switch retorna
os contadores de pacotes e bytes em resposta a um pedido pelas estatsticas as-
sociadas ` as regras contidas no padr ao pattern. O par ametro xid representa um
identicador para o pedido.
ow removed(switch; pattern; packets; bytes) acionado quando uma regra com
padr ao pattern supera o seu tempo limite e e removido da tabela de uxo do
switch. Os par ametros packets e bytes cont em os valores dos contadores para a
regra.
switch join(switch) acionado quando o switch entra na rede.
switch exit(switch) acionado quando o switch sai da rede.
port change(switch; port; up), acionado quando o enlace ligado a uma dada porta
fsica e ligado ou desligado. O par ametro up representa o novo status do enlace.
NOX tamb em prov e funcionalidades para enviar mensagens aos switches:
install (switch; pattern; priority; timeout; actions) insere uma regra com o dado
padr ao, prioridade, tempo limite e ac oes na tabela de uxos do switch.
uninstall (switch; pattern) remove a regra contida em padr ao da tabela de uxos
do switch.
send(switch; packet; action) envia o dado pacote para o switch e aplica a ac ao l a.
query stats(switch; pattern) gera umpedido para estatsticas de uma regra contida
no padr ao no switch e retorna um identicador de requisic ao xid que pode ser
usado para mapear uma resposta assncrona do swtich.
Figura 7. Topologia simples
O programa em execuc ao no controlador dene um manipulador para cada um
dos eventos construdos dentro do NOX, mas pode ser estruturado como um programa
arbitr ario. Exemplo: para ilustrar o uso de OpenFlow, considere um programa controlador
escrito em Python que implementa um hub repetidor simples. Suponha que a rede tem
um unico switch ligado a um conjunto de hosts internos no porto 1 e uma rede ampla no
porto 2, como mostrado na gura 7. O manipulador switch join abaixo invoca o repetidor
quando o switch se junta ` a rede. Afunc ao repetidor instala regras no switch que o instruem
a enviar pacotes da porta 1 para a porta 2 e vice-versa.
def switch_join(switch):
repeater(switch)
def repeater(switch):
pat1 = {in_port:1}
pat2 = {in_port:2}
install(switch,pat1,DEFAULT,None,[output(2)])
install(switch,pat2,DEFAULT,None,[output(1)])
Note que as duas chamadas para install usam o nvel de prioridade DEFAULT e
None como o tempo limite, indicando que as regras s ao permanentes.
NOX obteve uma grande aceitac ao entre os pesquisadores da area de SDN. A
exist encia de duas interfaces, C++ e Python, permite que o mesmo ambiente seja utilizado
em situac oes que exigem alto desempenho e em casos onde a capacidade de express ao
de Python agilizam o desenvolvimento e simplicam o c odigo resultante. Como ser a
discutido mais tarde, POX foi desenvolvido com base no modelo de NOX, mas com a
premissa de ser completamente escrito em Python, resultando em uma interface mais
elegante e simples dentro daquela linguagem. Os desenvolvedores de POX acreditam que
este seja adequado para substituir NOX nos casos em que Python e utilizado, enquanto
NOX ainda permanece como um ambiente adequado para implementac oes que tenham
demandas mais elevadas em termos de desempenho.
5.2. Trema
Trema [tre 2012] e uma implementac ao OpenFlow para desenvolvimento de controla-
dores usando as linguagens de programac ao Ruby e C. O escopo de Trema e ajudar os
desenvolvedores a criar facilmente seus pr oprios controladores OpenFlow. N ao tem com
o objetivo fornecer uma implementac ao especca de um controlador OpenFlow.
Controladores Trema OpenFlow s ao simples scripts escritos em Ruby.

E possvel
escrever seu pr oprio controlador adicionando manipuladores de mensagempara sua classe
controller. Com um arquivo de congurac ao e possvel descrever a topologia da rede na
qual o controlador e executado e pass a-lo para execuc ao pelo trema.
class MyController < Controller
# packet_in handler
def packet_in dpid, msg
send_flow_mod_add(
dpid,
:match => ExactMatch.from(msg),
:buffer_id => msg.buffer_id,
:actions => ActionOutput.new(msg.in_port+1)
)
end
end
Trema tem um emulador de rede OpenFlow integrado. N ao e preciso preparar
switches OpenFlowe hosts para testar aplicac oes de controlador. Oc odigo a seguir mostra
um exemplo de arquivo de congurac ao de rede que cria dois switches virtuais.
# network.conf
vswitch { dpid 0xabc }
vhost host1
vhost host2
link 0xabc, host1
link 0xabc, host2
A execuc ao e feita com a seguinte linha de comando:
./trema run mycontroller.rb -c network.conf
5.3. Maestro
Maestro e uma plataforma escal avel de controladores para switches OpenFlow em
Java [Cai et al. 2010].
Maestro e um sistema operacional de rede desenvolvido para orquestrar aplicac oes
de controle no modelo SDN. O sistema fornece interfaces para implementac ao modula-
res de aplicac oes de controladores de rede para acessar e modicar o estado da rede e
coordenar suas interac oes. O modelo de programac ao do Maestro fornece interfaces para:
Introduc ao de novas func oes de controle personalizadas, adicionando componen-
tes de controle modular.
Manutenc ao do estado da rede em nome dos componentes de controle.
Composic ao de componentes de controle, especicando a sequ encia de execuc ao
e o estado dos componentes da rede compartilhada.
Emparticular, Maestro j a inclui m odulos de descoberta de recursos fsicos da rede,
utilizado para contruir sua vis ao global da estrutura da rede, e m odulos para implementar
protocolos de roteamento usuais sobre essa estrutura.
Al em disso, Maestro tenta explorar o paralelismo dentro de uma unica m aquina
para melhorar o desempenho do sistema de transfer encia. A caracterstica fundamental
de uma rede OpenFlow e que o controlador e respons avel pela criac ao inicial de cada
uxo entrando em contato com switches relacionados. O desempenho do controlador
pode ser o gargalo. No projeto do Maestro tentou-se exigir o menor esforco possvel dos
programadores para conseguir gerenciar a paralelizac ao. Maestro lida com a maior parte
do trabalho tedioso e complicado de gerir distribuic ao de carga de trabalho e agendamento
de threads.
No Maestro, os programadores podem alterar a funcionalidade do plano de con-
trole escrevendo programas single-threaded. Maestro incorpora um conjunto de mode-
los e t ecnicas que abordam a especicac ao de requisitos do OpenFlow e explora parale-
lismo em nome dos programadores. Para maximizar o rendimento do sistema, a carga
de trabalho tem de ser uniformemente distribuda entre as threads em Maestro, de modo
que nenhum n ucleo do processamento que ocioso, enquanto h a trabalho a fazer. Isto e
alcancado fazendo com que todas as threads compartilhem a la de tarefas de pacotes. O
projeto
5.4. Beacon
Beacon e outro controlador baseado em Java que suporta tanto a operac ao baseada em
eventos quanto em threads [bea 2012].
O projeto vem sendo desenvolvido j a h a um ano e meio, sendo considerado
est avel. Seu registro de operac ao inclui a ger encia de uma rede com 100 switches virtuais,
20 switches fsicos em um datacenter experimental. O sistema tem uma estrutura modular
que permite que o controlador seja atualizadom em tempo de execuc ao sem interromper
outras atividades de encaminhamento de pacotes. O pacote opcionalmente incorpora o
servidor web Jetty e um arcabouco extensvel para o desenvolvimento de interfaces de
usu ario personalizadas.
5.5. FML
A linguagem FML (Flow Management Language) e uma linguagem declarativa de alto
nvel que permite especicar polticas de ger encia e seguranca em redes OpenFlow. FML
foi desenvolvida para substituir os mecanismos tradicionais de congurac ao de redes para
reforcar as polticas dentro das redes de empresas [Hinrichs et al. 2009]. A linguagem e
simples e pode ser usada para expressar muitas congurac oes comuns usadas em redes
atualmente. FML foi projetado para admitir uma implementac ao eciente, adequada para
grandes redes corporativas.
FML opera sobre uxos unidirecionais. Isso signica que a poltica resultante a
aplicada igualmente em todos os pacotes dentro do mesmo uxo, e polticas podem ser
construdas que tratam cada uxo diferentemente.
O sistema resultante permite a especicac ao de alto nvel de v arias tarefas de
gerenciamento de forma resumida e estruturada, liberando os administradores de rede
do trabalho penoso de congurar regras de controle de acesso em roteadores, rewalls,
servidores de NAT e VLANs para alcancar polticas de uso de rede simples. A natureza
declarativa da FML permite que os administradores se concentrem sobre a poltica de
decis oes, em vez de detalhes de implementac ao.
Uma poltica FML e um conjunto de regras n ao-recursivas. Por exemplo, as tr es
armac oes seguintes dizem que Todd e Michelle s ao superusu arios e um superusu ario n ao
tem restric oes de comunicac ao.
allow(Us;Hs;As;Ut;Ht;At;Prot;Req) <= superuser(Us)
superuser(Todd)
superuser(Michelle)
Os argumentos para allow s ao smbolos que correspondem a oito campos de um
uxo dentro do sistema. S ao eles: usu ario, host e ponto de acesso fonte (U
s
; H
s
; A
s
),
usu ario, host e ponto de acesso alvo (U
t
; H
t
; A
t
;), protocolo (Prot) e se o uxo e uma
requisic ao (Req).
Al em de allow , h a outras palavras chaves para o controle de acesso, como deny,
waypoint, avoid e ratelimit.
Para qualidade de servicos, FML possui tr es palavras chaves latency, jitter, band
que podem ser usadas para congurar diferentes requisitos para diferentes uxos.
FML tamb em permite a inclus ao de refer encia a fontes externas, como consultas
SQL em uma base de dados ou procedimentos remotos .
5.6. Frenetic
Frenetic e um sistema baseado em linguagem funcional desenvolvido para programar re-
des OpenFlow [Foster et al. 2010]. Frenetic permite que o operador da rede, ao inv es de
manualmente congurar cada equipamento da rede, programe a rede como um todo. Fre-
netic e implementado sobre NOX, em Python, e foi projetada para resolver problemas de
programac ao com o OpenFlow/NOX. Frenetic introduz abstrac oes funcionais para permi-
tir programas modulares e a composic ao desses programas.
Frenetic e composto de duas sublinguagens integradas: uma linguagem declara-
tiva de consultas para classicar e agregar tr afego da rede e uma biblioteca reativa funci-
onal para descrever polticas de envio de pacotes em alto nvel.
Figura 8. Sintaxe de Consulta do Frenetic
A gura 8 mostra a sintaxe das consultas em Frenetic. Cada cl ausula e opcional,
exceto Select, no qual identica qual o tipo de evento retornado pela consulta: evento
contendo pacotes, contador de bytes ou contador de pacotes. O operador e usado para
combinar cl ausulas.
A cl ausula Select(a) agrega os resultados retornados pela consulta a. A cl ausula
where(fp) ltra os resultados, mantendo apenas aqueles pacotes que satisfazem o l-
tro de padr ao fp. Os padr oes de consultam podem usar os campo de cabecalho como
porta (inport), endereco MAC de origem (srcmac), endereco MAC de destino (dstmac),
entre outros. Filtro de padr oes mais complicados podem ser construdos usando ope-
radores de conjunto como intersec ao (and fp), uni ao (or fp),diferenca (diff fp) e com-
plemento(not fp). Cl ausulas GroupBy([qh1,...,qhn]) subdividem o conjunto de paco-
tes consultados em subconjuntos baseado nos campos de cabecalhos qh. Cl ausulas
Every(n)particionam os pacotes por tempo, agrupando pacotes que estejam na mesma
janela de tempo. Finalmente, cl ausulas Limit(n) limintam o n umero de pacotes em cada
subconjunto.
Abaixo temos um exemplo de consulta utilizando Frenetic:
def web_query():
return \
(Select(sizes)
*
Where(inport_fp(2) & srcport_fp(80)))
*
Every(30))
A consulta seleciona os pacotes que chegam na porta fsica 2 e da porta de origem
TCP 80. Ela soma o tamanho de todos esses pacotes a cada 30 segundos e retorna um
evento com o resultado.
5.7. Onix
Onix e um controlador desenvolvido em parceria pela Nicira, Google e NEC,
com o objetivo de permitir o controle de redes de grandes dimens oes de forma
con avel [Koponen et al. 2010]. Para garantir a escalabilidade e conabilidade do sis-
tema, Onix prov e abstrac oes para particionar e distribuir o estado da rede em m ultiplos
controladores distribudos, enderecando as quest oes de escalabilidade e toler ancia a falha
que surgem quando um controlador centralizado e utilizado.
A vis ao global da rede e mantida atrav es de uma estrutura de dados denominada
NIB (Network Information Base), que representa um grafo com todas as entidades presen-
tes na rede fsica. A NIB e o centro do sistema e a base para o modelo de distribuic ao de
Onix. Aplicac oes de controle da rede s ao implementadas atrav es de operac oes de leitura
e atualizac ao do estado da NIB; escalabilidade resili encia s ao obtidos particionando-se e
replicando-se a NIB entre os servidores do sistema. A consist encia das atualizac oes sobre
a base distribuda e controlada pela aplicac ao e utiliza dois reposit orios com compro-
missos diferentes entre os as garantias de resili encia e desempenho (uma base de dados
transacional replicada e uma DHT baseada em mem oria). Para garantir a escalabilidade,
Onix prev e a organizac ao da NIB em estruturas hier arquicas, com concentradores e dife-
rentes nveis de detalhes para os recursos do sistema.
Os resultados apresentados atestam o bom desempenho do sistema e o artigo dis-
cute em algum detalhe os compromissos adotados com relac ao ` a escalabilidade e re-
sili encia do sistema. O sistema resultante, conforme descrito, sugere um grande cui-
dado com a funcionalidade e uma estrutura complexa que atende aos requisitos de projeto
apresentados. Entretanto, Onix e, pelo menos at e o momento, um produto fechado, pro-
priet ario.
5.8. Click
O roteador modular Click [Kohler et al. 2000] e um projeto que expressou o objetivo
de permitir que equipamentos de rede fossem program aveis bem antes do advento de
redes denidas por software. Sendo considerado um dos projetos que inuenciaram a
denic ao de OpenFlow. O roteador Click enfatiza a modularidade, permitindo que pes-
quisadores criem m odulos de processamento de pacotes customizados. Entretanto, Click
foca exclusivamente em switches de software (implementado como m odulo do kernel
do Linux). J a existe uma interface do OpenFlow para o Click, o elemento OpenFlow-
Click [Mundada et al. 2009]. Esse elemento permite o contralador instalar regras para
fazer pacotes atravessarem diferentes elementos. O OpenFlowClick permite um contro-
lador central controlar v arios roteadores Click ao mesmo tempo. Esta interface tem o
potencial para novas possibilidades de aplicac oes de processamento de tr afego, como eli-
minar pacotes duplicados ou detecc ao de anomalias via inspec ao peri odica de pacotes.
5.9. Floodlight
Floodlight [o 2012] e um controlador OpenFlow para redes corporativas baseado total-
mente na linguagemJava e distribudo segundo a licenca Apache. Oprojeto se originou do
controlador Beacon e agora e apoiado por uma comunidade de desenvolvedores e tamb em
pela Big Switch Networks, start-up que produz controladores comerciais que suportam o
Floodlight. O n ucleo e m odulos principais s ao escritos em Java. Recentemente adicio-
naram Jython, o que permite desenvolvimento na linguagem Python. Em sua arquitetura,
todos os elementos s ao m odulos e m odulos exportam servicos. Toda a comunicac ao en-
tre m odulos e feita atrav es de servicos. A interface ItopologyService permite descobrir a
topologia da rede automaticamente. Permite integrar com redes n ao openow e e com-
patvel com a ferramenta de simulac ao Mininet [Lantz et al. 2010].
5.10. SNAC
Simple Network Access Control(SNAC) [sna 2012] e um controlador OpenFlow no qual
se utiliza uma interface web para monitorar a rede. Ele incorpora uma linguagem de
denic ao de polticas exvel que permite realizar buscas utilizando padr oes de alto nvel
para especicar polticas de controle de acesso. SNAC tamb em prov e uma ferramenta
de monitamento gr aco, mas n ao e um ambiente de programac ao gen erica, como outros
controladores discutidos aqui.
5.11. NEC Programmable Flow
Na parte de produtos comerciais, temos a famlia de produtos do NEC Programmable
Flow [nec 2012]. A famlia prov e tanto componentes de software como tamb em de hard-
ware. Em software, temos o ProgrammableFlow Management Console, que e uma ferra-
menta para monitoramento que prov e um ponto de controle centralizado. Em hardware,
temos o controlador ProgrammableFlowController que permite virtualizac ao em nvel de
rede e e util, por exemplo, para data center pois permite monitorar e controlar redes com
v arios nveis de ger encia. Dentre os switches, podemos citar o PF5420 e o PF5820 que
s ao compatveis com OpenFlow e reduzem o custo de operac ao da rede j a que n ao preci-
samexecutar algoritmos dsitribudos tradicionais como arvor e geradora, j a que funcionam
com um controlador centralizado.
5.12. Mininet
Apesar de n ao se tratar de um controlador propriamente dito, na parte de emuladores
e simuladores, e importante mencionar o Mininet [Lantz et al. 2010], uma ferramenta
de simulac ao de Redes Denidas por Software.

E um sistema que permite a r apida
prototipac ao de grandes redes utilizando apenas um computador. Mininet cria Redes
Denidas por Software escal aveis utilizando primitivas de virtualizac ao do Sistema Ope-
racional, como processos e namespaces de rede. Com essa primitivas, ele permite rapida-
mente criar, interagir e customizar prot otipos de Redes Denidas por Software.
6. Aplicac oes
Pela exibilidade que Redes Denidas por Software oferecem para a estruturac ao de sis-
temas em rede, o princpio estruturador oferecido por esse paradigma pode ser util em
praticamente todas as areas de aplicac ao de Redes de Computadores. A estruturac ao da
rede com comutadores program aveis e uma vis ao (l ogica) centralizada da rede podem ser
de grande valia no desenvolvimento de novas funcionalidades em um grande n umero de
ambientes. Nesta sec ao, discutimos primeiramente os principais contextos j a identica-
dos que podem se beneciar da aplicac ao de SDN. Em seguida, identicamos alguns dos
principais projetos de pesquisa em andamento que se valem do paradigma para avancar a
fronteira do conhecimento em suas areas, no Brasil e no mundo.
6.1. Contextos de aplicac ao
Se considerarmos que SDN dene uma nova forma de estrutura um sistema em rede,
podemos considerar que ela seja aplic avel a qualquer tipo de aplicac oa de Redes de Com-
putadores que possa se benecar de um maior grau de organizac ao das funcionalidades
oferecidas em torno de uma vis ao completa da rede. Entretanto, alguns domnios de
aplicac ao j a foram identicados e v em sendo tratados por diferentes projetos de pesquisa.
Controle de acesso
Pela natureza da interface de programac ao de OpenFlow, onde o tratamento e denido
pelos padr oes que identicam uxos, a sua aplicac ao ao problema de controle de acesso e
bastante direta. A vis ao global da rede oferecida pelo controlador SDN permite que regras
de acesso sejam desenvolvidas com base em informac oes abrangentes e n ao apenas o que
seria possvel com o uso de um rewall em um enlace especco da rede. De fato, como
mencionado anteriormente, um dos projetos precursores de OpenFlow foi exatamente
Ethane, um sistema de controle de acesso distribudo, baseado no conceito de uma vis ao
global das polticas de controle e do estado da rede [Casado et al. 2009].
O poder de express ao disponvel ao se adotar uma vis ao global permite a
implementac ao de regras que levem em conta n ao apenas tipos de protocolo e pontos
de origem/destino, mas a relac ao entre estes e a identidade do usu ario de forma simples.
Al em disso, a facilidade de se denir qual rota adotar para cada uxo viabiliza inclusive a
utilizac ao de ltros especiais de tr afego (middle-boxes), como dispositivos de inspec ao de
pacotes (DPI) e proxies. Um exemplo do que pode ser feito nesse caso e o sistema SpSb,
um honeypot de alta interatividade que est a sendo desenvolvido no DCC/UFMG para
o estudo do comportamento de bots, especialmente aqueles usados para a distribuic ao
de spam [Silva et al. 2011]. Uma m aquina e interposta entre o computador infectado e
o restante da Internet com um comutador Open vSwitch e um controlador POX. Cada
uxo iniciado pela m aquina infectada e inspecionado pelo controlador, que pode decidir
entre bloque a-lo, permitir sua passagem para o restante da rede ou redirecion a-lo para
um conjunto se servidores desenvolvidos para emular servicos importantes que permi-
tam ao sistema controlar o comportamento do bot. Por exemplo, um servidor de DNS
especialmente congurado pode ser programado para registrar as consultas efetuadas e
redirecionar acessos quando necess ario. Um tipo de acesso que seria sempre redirecio-
nado seria qualquer tentativa de contato a um servidor de correio eletr onico por SMTP,
que seria enviado para um servidor especialmente congurado para emular qualquer ser-
vidor de correio e armazenar as mensagens recebidas, sem entretanto repass a-las para o
restante da rede.
Ger encia de Redes
Um dos argumentos sempre utilizados com relac ao a SDNs e qe a vis ao global da rede
simplica as ac oes de congurac ao e ger encia de rede, enquanto os contadores associados
aos uxos permitem uma monitorac ao clara dos uxos de interesse. Entretanto, ainda n ao
est a claro como essas funcionalidades podem ser melhor integradas a pr aticas de ger encia
habituais. Uma forma de integrac ao interessante e certamente a integrac ao direta de swit-
ches OpenFlow a sistemas de ger encia tradicionais, como os que utilizam o protocolos
SNMP [Farias et al. 2011].
Outros projetos, como OMNI [Mattos et al. 2011], oferecem opc oes para simpli-
car o processo de administrac ao de redes OpenFlow pela inclus ao de uma interface de
controle baseada em uma arquitetura orientada servicos. Al em disso, OMNI inclui uma
plataforma orientada a agentes para simlicar a express ao de comportamentos que devem
ser monitorados e sobre os quais o sistema deve atuar.
Tamb em utilizando uma arquitetura multi-agentes, pesquisadores da UFAM t em
estudado a integrac ao de t ecnicas de Intelig encia Articial a redes denidas por soft-
ware. A vis ao global da rede provida pelos controladores oferece um ponto focal so-
bre o qual t ecnicas de detecc ao de anomalias ou padr oes frequentes podem ser apli-
cadas para se detectar diversos tipos de comportamento, como ataque de negac ao de
servico [Braga et al. 2010].
Redes domiciliares
Redes dom esticas t em sido apontadas como um dos grandes desaos para a ind ustria de
redes, especialmente no que se refere a dotar o usu ario dessas redes de recursos ecientes
para sua ger encia e congurac ao [Dixon et al. 2010]. Vencer esse desao exigir a tanto o
investimento emsoluc oes para os problemas de interac ao dos usu arios comos dispositivos
de rede, quanto em novas soluc oes para automac ao de congurac ao e implementac ao de
polticas de seguranca para o lar.
Uma forma de aplicar os princpios de SDN nesse contexto e utilizar um roteador
dom estico com recursos OpenFlow e transferir para o provedor de acesso a responsabi-
lidade de controlar a rede atrav es de um controlador SDN. Dessa forma, esse sistema
operacinal de rede seria capaz de programar cada roteador dom estico com as regras de
acesso apropriadas para cada usu ario e ter uma vis ao global de todo o tr afego que atra-
vessa o enlace de acesso a cada resid encia, construindo dessa forma uma vis ao agregada
do que pode ser considerado tr afego lcito e quais padr oes de tr afego podem indicar a
ac ao de atacantes ou c odigo malicioso. Esse enfoque tem sido adotado por pesquisadores
da Georgia Tech [Feamster 2010, Calvert et al. 2011].
Por outro lado, outra soluc ao interessante pode ser a implementac ao de um contro-
lador de rede interno ` a rede dom estica. Essa soluc ao se torna atraente especialmente frente
ao aumento da complexidade dessas redes, que contam hoje com um n umero crescente
de dispositivos ativos, como smartphones e consoles de jogos, al em dos computadores
usuais, al em de poderem contar hoje com mais de um elemento de comutac ao, tanto para
enlaces cabeados quanto para enlaces sem o. Um controlador dom estico poderia acom-
panhar todo o tr afego interno da rede, potencialmente tornando mais simples a detecc ao
de m aquinas comprometidas por malware (cujo tr afego de disseminac ao seria mais facil-
mente identicdo contra o padr ao usual do tr afego do lar) e a congurac ao de servicos da
rede, como impressoras e novos dispositivos de acesso.
Ger encia de energia
O interesse em soluc oes que conservem energia em sistemas de computac ao vem cres-
cendo. Em ambientes corporativos e grandes datacenters, onde os recursos de rede as-
sumem dimens oes signicativas, reduzir o consumo de energia consumida pelo meio de
comunicac ao se torna uma possibilidade interessante. Ac oes como a reduc ao da taxa de
transmiss ao de enlaces sub-utilizados ou seu desligamento completo (e de dispositivos de
rede, da mesma forma) se tornam vi aveis a partir do momento em que uma rede denida
por software oferece uma vis ao global do estado da rede, que simplica a identicac ao
desses elementos ociosos e mesmo a redenic ao de rotas a m de desviar tr afego de
elementos passveis de desligamento. Al em disso, o controle das rotas e decis oes de en-
caminhamento permite a implantac ao de pontos de controle (proxies) que interceptem
tr afego ruidoso na rede, evitando que pacotes de menor import ancia atinjam m aquinas
que podem operar em um modelo de wake-on-lan, evitando que as mesmas sejam ativadas
desnecessariamente.
Comutador virtual distribudo
Ambientes virtualizados, comuns hoje em redes corporativas e grandes datacenters, usu-
almente implicam no uso de switches implementadas por software no hypervisor insta-
lado em cada m aquina fsica a m de prover a conectividade exigida por cada m aquina
virtual (VM). Um exemplo de tal switch e o Open vSwitch, discutido anteriormente. A
facilidade de se mover as m aquinas virtuais entre os hospedeiros fsicos, um recurso bas-
tante valorizado nesses ambiente, torna o processo de congurac ao e monitorac ao dessas
m aquinas um desao que complica a ger encia dos switches virtuais. Uma forma de re-
duzir essa complexidade seria oferecer a vis ao de um switch unico, virtual, ao qual todas
as VMs estariam conectadas. Dessa forma, migrac oes de VMs teriam impacto mnimo
nas congurac oes da rede virtual, uma vez que elas continuariam ligadas a uma porta
do unico switch visvel para a rede. Essa abstrac ao pode ser facilmente implementada
atrav es de um controlador de rede, j a que ele pode inserir automaticamente as regras de
encaminhamento de tr afego entre as portas dos diversos switches de software para criar
o efeito desejado. Com o uso de switches fsicos que tamb em implementem o protocolo
OpenFlow, mesmo m aquinas fsicas n ao virtualizadas podem fazer parte dessa rede.
Roteador expansvel de alta capacidade
Grandes datacenters e as bordas das redes de acesso de grandes provedores, bem como
das suas redes de longa dist ancia, possuem demandas de conectividade elevadas. Nesses
casos, usualmente um roteador de grande porte e usualmente a unica soluc ao vi avel, a um
custo bastante elevado. Utilizando-se uma rede denida por software, pode ser possvel
substituir esse roteador de grande porte por um banco de switches de porte m edio, como
as utilizadas internamente em um cluster, desde que dotadas de interfaces OpenFlow. De
forma semelhante ao que ocorre no caso do comutador virtual distribudo, um controla-
dor SDN pode preencher as tabelas de roteamento de cada switch com as rotas necess arias
para interligar o tr afego entre duas portas de switches diferentes que sejam vistas como
fazendo parte do mesmo roteador. Uma malha de interconex ao do tipo fat-tree garantiria
uma banda de interconex ao suciente entre os comutadores, de forma que o controlador
n ao teria que lidar com gargalos inesperados entre portas do roteador. As informac oes de
roteamento seriam distribudas entre os switches em func ao das demandas identicadas
pelo controlador. Os algoritmos de roteamento necess arios ao funcionamento do roteador
poderiam ser executados tamb em pelo controlador, que se encarregaria de manter a inter-
face com os demais roteadores com os quais o roteador virtual tenha que se comunicar.
Datacenters multi-usu arios
Em ambientes onde aplicac os de v arios usu arios necessitem coexistir, como em data-
centers p ublicos (multi-tenant), uma demanda sempre presente e o isolamento de tr afego
entre os diversos usu arios. Uma forma de se obter esse isolamento com dispositivos atuais
e atrav es da congurac ao de VLANs individuais para cada cliente. Assim, tr afego de cada
usu ario e transportado apenas dentro da sua VLAN, garantindo o isolamento necess ario
para ns de seguranca e privacidade. Entretanto, o recurso de VLANs e limitado pelo
tamanho dos campos usados para identic a-las, tornando invi avel sua utilizac ao quando
o n umero de usu arios da rede cresce. Al em disso, as interfaces de congurac ao desse tipo
de soluc ao tendem a ser limitadas, tornando a ger encia de congurac ao desse tipo de rede
uma tarefa bastante complexa. A soluc ao para esse problema pode ser construda dire-
tamente sobre a abstrac ao do comutador virtual distribudo mencionado anteriormente: a
cada usu ario e fornecido um switch virtual que interliga suas m aquinas, independente da
localizac ao das mesmas na rede fsica. O controlador de rede e respons avel por denir as
rotas entre as portas dos diversos comutadores que comp oem o comutador virtual e por
garantir a alocac ao de recursos sucientes em cada caso. Como cada cliente e conectado
a um switch diferente, o isolamento de tr afego e obtido diretamente pela implementac ao.
Al em de garantir o isolamento de tr afego de forma ecaz, essa soluc ao tem a van-
tagem de permitir que se ofereca a cada usu ario o controle direto de sua rede. Quaisquer
congurac oes que estejam disponveis para o switch virtual podem ser controladas pelo
usu ario que controla a rede, uma vez que a mesma est a isolada das demais. Soluc oes como
balanceamento de carga, estabelecimento de nveis de qualidade de servico e redund ancia
de rotas podem ser colocadas sob o controle do usu ario, desde que o controlador de rede
garanta sua implementac ao no nvel do switch virtual distribudo.
6.2. Alguns projetos de pesquisa
Pela caracterstica recente do tema, diversos projetos de pesquisa ainda focam o desenvol-
vimento de controladores de rede que preencham as caractersticas de um sistema opera-
cional de rede, na denic ao de SDN. Esses projetos j a foram discutidos na sec ao 5. Aqui
discutimos projetos principalmente focados em aplicac oes do paradigma em alguns dos
contextos mencionados anteriormente. Diversos s ao os que abordam problemas que afe-
tam um ou mais domnios mencionados anteriormente. A lista a seguir n ao tem a intenc ao
de ser exaustiva, dado o n umero de iniciativas, mas pretende ilustrar alguns desses proje-
tos.
Ripcord
O datacenter foi identicado rapidamente como um dos principais contextos onde SDN
poderia ser aplicado com sucesso. Isso pode ser observado na identicac ao de aplicac oes
como o comutador virtual distribudo e o ambiente multi-usu ario. Um ponto importante
dos datacenters hoje e a demanda por novas topologias de rede que permitama construc ao
de infraestruturas de comunicac ao eciente e robustas. Nesse contexto, Ripcord foi con-
cebido como um sistema que aplicaria os conceitos de SDN na construc ao de um sistema
de rede que pudesse ser congurado para diferentes topologias e diferentes soluc oes de ro-
teamento, a m de permitir a escolha da soluc ao mais adequada para diferentes condic oes
de contorno [Heller et al. 2010a, Casado et al. 2010a].
Al em das caractersticas de modularidade, escalabilidade e operac ao com
m ultiplos usu arios, Ripcord tamb em tinha como metas denir um mecanismo de
migrac ao de VMs de forma transparente e com recursos de balanceamento de carga para o
tr afego de rede. O prot otipo desenvolvido foi implementado sobre o NOX, com diferentes
m odulos para implementar cada func ao identicada como essencial ` a sua operac ao. Entre
os m odulos (engines) principais, destaca-se o de topologia, que mant em a vis ao da rede
fsica, o de aplicac ao, que controla a vis ao de cada usu ario (tenant) sobre a rede, e o de
roteamento, que implementa o mecanismo de roteamento com balanceamento de carga
escolhida. O sistema foi testado com tr es polticas de roteamento com diferentes graus de
complexidade e apresentou bom desempenho.
RouteFlow
No contexto de redes de longa dist ancia, a implementac ao de protocolos de roteamento
e uma preocupac ao frequente. Uma rede denida por software que pretenda operar de
maneira eciente com outras redes a seu redor deve implementar polticas de roteamento
bem denidas e, mais que isso, deve ser capaz de trocar informac oes sobre suas rotas
com elementos vizinhos. RouteFlow oferece uma soluc ao distribuda para que se possa
aplicar protocolos de roteamento bem denidos sobre uma rede denida por software,
permitindo a implantac ao imediata de protocolos de roteamento j a denidos e ofere-
cendo um arcabouco extensvel sobre o qual novos protocolos podem ser implementa-
dos [Nascimento et al. 2011].
RouteFlow executa como uma aplicac ao sobre NOX que controla a comunicac ao
com os comutadores OpenFlow da rede e o servidor RouteFlow, que mant em a vis ao
das rotas na rede. Os protocolos de roteamento propriamente ditos s ao executados por
m aquinas virtuais que executam vers oes do(s) protocolo(s) de roteamento escolhido(s)
em um ambiente virtualizado. Essas vers oes dos protocolos s ao obtidos normalmente
do Quagga routing engine. Cada roteador denido na vis ao de rede denida executa
como uma m aquina virtual, trocando mensagens dentro do ambiente virtualizado com os
demais roteadores da rede, de acordo com o protocolo escolhido. Se a especicac ao da
rede prev e a exist encia de roteadores adicionais que n ao fazem parte da rede denida por
software, as mensagens dos protocolos de roteamento que devem ser trocadas entre os
roteadores virtualizados e esse roteadores reais s ao injetadas e retiradas da rede atrav es
dos comutadores OpenFlow.
Elastic Tree
Com foco na quest ao de ger encia (e economia) de energia, o objetivo de Elastic Tree
e controlar a topologia da rede fsica de um datacenter para reduzir o consumo devido
a canais sub-utilizados [Heller et al. 2010b]. O princpio de operac ao nesse caso e que,
em situac oes de carga reduzida, o nvel de replicac ao de recursos encontrado em uma
rede de datacenter bem provisionada pode levar a um consumo de energia desnecess ario.
Em uma topologia fat-tree, por exemplo, h a diversos nveis de switches interligando os
servidores da rede; o n umero de enlaces e switches a cada nvel e denido de forma
que haja diversas rotas entre cada par de servidores, a m de evitar gargalos na rede.
Em condic oes de carga baixa, entretanto, muitos desses caminhos redundantes se tornam
desnecess arios e poderiam ser removidos para reduzir o consumo de energia.
Elastic Tree monitora continuamente o tr afego da rede e decide, com base nos
objetivos de economia de energia e disponibilidade expressos pelo administrador, quais
enlaces e switches precisam permanecer ativos e quais podem ser desligados. A vis ao
global do tr afego e da topologia s ao providos pelo controlador SDN adotado (NOX, no
prot otipo implementado). Diversos algoritmos de otimizac ao foram implementados para
oferecer diferents polticas de controle, reetindo diferentes compromissos entre econo-
mia e disponibilidade. Em casos onde o padr ao de tr afego se limitava em sua maioria
a servidores pr oximos na topologia, a energia consumida chegava a ser apenas 40% da
energia consumida com a topologia original, sem controle. Os ganhos se reduzem caso o
padr ao de tr afego exija a comunicac ao entre servidores distantes na topologia (exigindo
maior conectividade nos nveis superiores da hiearquia de switches), mas s ao ainda signi-
cativos para uma ampla gama de valores.
Gatekeeper-ng
Ainda no contexto de redes para datacenters, um outro aspecto que tem recebido grande
atenc ao e a quest ao de se estabelecer garantias de alocac ao de tr afego para diferents
usu arios com suas aplicac oes. Gatekeeper e uma soluc ao proposta para esse m que
se baseia em uma vis ao abstrata onde cada usu ario receberia garantias equivalentes ` as
providas caso sua aplicac ao executasse em um conjunto de m aquinas conectadas por
um switch privativo, sem compartilhamento com outras aplicac oes. As garantias de de-
sempenho seriam determinadas pela banda alocada para o enlace de conex ao de cada
m aquina, que poderia ser escolhida pelo usu ario em um modelo com custos associa-
dos [Rodrigues et al. 2011, Rodrigues et al. 2011].
A abstrac ao oferecida por Gatekeeper se encaixa precisamente ao modelo de co-
mutador virtual distribudo discutido anteriormente. Considerando-se que o ambiente
alvo do sistema s ao datacenters virtualizados, onde a conex ao de cada m aquina virtual ` a
rede se d a atrav es de switches de software (Open vSwitch), a extens ao do modelo para uti-
lizar uma rede denida por software que realmente implemente a abstrac ao de um switch
virtual distribudo pode ser feita de forma simples [Pettit et al. 2010]. Al em disso, ao se
integrar esse modelo ao ambiente Open Stack, que tamb em se baseia na noc ao de uma
rede privada assinalada para cada usu ario [ope 2012], o processo de congurac ao, disparo
de m aquinas virtuais e recongurac ao no caso de migrac ao de VMs pode ser totalmente
integrado, dando origem ao ambiente Gatekeeper-ng, atualmente em desenvolvimento.
POX at Home
Esse projeto aborda o desenvolvimento de uma aplicac ao SDN para ger encia de redes
dom esticas. Inicialmente denominado NOX at home, foi recentemente adaptado para
utilizar o controlador POX. O princpio por tr as do projeto e que, dadas as velocidades de
acesso disponveis para usu arios residenciais, a capacidade de processamento disponvel
em roteadores dom esticos e suciente para inspecionar cada uxo que atravessa o enlace
de acesso.
A aplicac ao POX nesse caso implementa um analisador de protocolos que acom-
panha cada novo uxo observado na rede local e reconstr oi o uxo de aplicac ao para
protocolos identicados como relevantes, como SMTP, HTTP e DNS. Essa reconstruc ao
continua at e que o controlador tenha informac ao suciente para se avaliar a conformi-
dade do tr afego em relac ao a um conjunto de regras de acesso e aplicar um algoritmo de
detecc ao de anomalias para determinar a natureza do tr afego [Mehdi et al. 2011]. Nesse
momento, uma regra e emitida para incluir uma rota direta para o restante do uxo, ou
para descart a-lo, caso seja julgado inadequado. H a tamb em a possibilidade de se con-
gurar a travessia de um middle-box caso algum tipo de p os-processamento do uxo seja
necess ario
7. Desenvolvimento de sistemas utilizando POX
POX vem sendo desenvolvido como um sucessor natural de NOX para iniciativas de pes-
quisa e ensido. O objetivo dos desenvolvedores e que ele venha a substituir NOX nos
casos onde desempenho n ao seja um requisito crtico essencialmente, nos casos onde a
interface Python e utilizada. Nesse aspecto, POX traz uma interface mais moderna e uma
pilha SDN mais elegante, al em de oferecer melhor desempenho que NOX com Python,
como pode ser visto na gura 9.
Figura 9. Comparac ao de desempenho entre POX e NOX, com suas duas in-
terfaces (C++ e Python). Figura publicada por Murphy McCauley no site
http://www.noxrepo.org/2012/03/introducing-pox/.
NOX e outros controladores de primeira gerac ao s ao construdos ao redor do con-
ceito de mensagens OpenFlow como primitivas b asicas. Assim sendo, as aplicac oes ser
organizam ao redor de ciclos de recebimento/tratamento/gerac ao de mensagens. POX est a
sendo organizado ao redor da noc ao de vis ao global da rede: aplicac oes n ao necessitar ao
necessariamente receber e enviar mensagens diretamente, mas poder ao consultar a vis ao
corrente da rede e atuar diretamente sobre ela para obter seus objetivos (os recursos para
esse m ainda est ao em desenvolvimento). Outros elementos que fazem parte do contexto
de projeto de POX incluem a previs ao de recursos para a distribuic ao dessa vis ao global
e para a depurac ao de aplicac oes desenvolvidas sobre essa vis ao.
7.1. Instalac ao e execuc ao
POX
1
exige Python 2.7 (ou superior) para executar. Ele deve ser compatvel com Python
3.x, mas nenhuma vericac ao cuidadosa foi feita a esse respeito. N ao h a registro de
elementos que sejam especcos de uma plataforma particular e ele pode ser executado
no Linux, Mac OS ou Windows. Para um melhor desempenho, recomenda-se o uso da
implementac ao no ambiente PyPy
2
.
Obtenc ao do c odigo
Originalmente, POX era distribudo o controle de vers ao Mercurial (hg), mas no momento
da escrita deste material ele estava sendo movido para o controlador Git e deve ser em
breve disponibilizado no GitHub
3
.
Incio da execuc ao e o mecanismo launch()
POX e iniciado ao se executar o m odulo pox.py. Ele recebe como argumentos a lista
de nomes de m odulos que devem ser instanciados durante a execuc ao. Cada m odulo
identicado e localizado e a func ao lauch() de cada m odulo e executada, se existir.
Em seguida, POX abra a interface de comandos de Python para uso interativo. M odulos
s ao procurados na hierarquia de diret orios usual de Python e nos diret orios pox e ext do
pacote. Assim sendo, para se disparar o m odulo que implementa switches Ethernet com
aprendizado, utiliza-se o comando
./pox.py dumb l2 switch
Cada m odulo pode receber argmentos atrav es de opc oes de execuc ao indicadas
ap os o nome do m odulo. Essas opc oes s ao passadas como par ametros para a func ao
launch() do m odulo.
Em particular, as opc oes de congurac ao de OpenFlow s ao uteis ao se iniciar a
execuc ao de POX associada a um ambiente de rede criado com o arcabouco Mininet.
Como mencionado anteriormente, Mininet cria uma rede virtual de comutadores Open-
Flow executando em uma m aquina virtual disparada na m aquina local. Os comutadores
e hosts na rede virtual podem ser congurados para se comunicar com uma inst ancia
de POX executando no computador hospedeiro. Para isso, POX deve ser iniciado da
seguinte forma:
./pox.py openflow.of 01 --address=10.1.1.1 --port=6634
1
O conte udo dessa sec ao e diretamente derivado de notas de utilizac ao disponveis no site http://www.
noxathome.org/wiki/POXConcepts.
2
http://pypy.org/
3
https://github.com/
Em seguida, no terminal Mininet, dispara-se a rede virtual com o comando:
sudo mn --controller=remote --ip=10.1.1.1 --port=6634
Para que isso seja possvel, a classe of 01 foi denida com o m etodo launch()
na forma:
def launch (port=6633, address = 0.0.0.0):
Operacoes a serem executadas ao se iniciar o modulo
O mesmo recurso pode se utilizado por qualquer m odulo desenvolvido no sistema.
Al em disso, pox.py reconhece algumas opc oes pr oprias, que devem ser listadas
primeiro:
--verbose exibe stack traces para excecoes durante a inicializacao
--no-cli nao inicia a interface interativa de comandos
--no-openflow nao inicia o modulo openflow automaticamente
Testes e depurac ao
No momento, n ao h a ainda uma rotina de testes completamente denida, mas h a um
primeiro esboco de como se construir um arcabouco para testes de unidade e integrac ao
no sub-diret orio test/.
Um dos objetivos maiores de POX e dotar o ambiente SDN de mecanismos de
depurac ao sosticados que integrem as diversas camadas de uma rede denida por soft-
ware. Em sua vers ao atual, entretanto, h a apenas um sistema de depurac ao que aumenta
os nveis de avisos e de gerac ao de logs, habilita a detecc ao de deadlocks e outras me-
didas uteis. Esse sistema e iniciado ao se executar ./pox.debu.py ao inv es do co-
mando original. Al em disso, pode ser util se incluir nos m odulos desenvolvidos recursos
de execuc ao passo-a-passo, o que pode ser feito ao se executar a linha import pdb;
pdb.set trace(), que iniciar a a execuc ao passo-a-passo.
Registro no pox.core
Ao executar, o objeto pox.core e criado e oferece a funcionalidade de se registrar obje-
tos arbitr arios, que passama ser acessveis para os m odulos do sistema. Por exemplo, voc e
pode escrever o c odigo de um tipo de comutador de rede, que pode ent ao ser registrado
como pox.core.switch em tempo de execuc ao. Uma vantagem disso e que outros
podem posteriormente implementar um comutador totalmente diferente que implemente a
mesma interface de programac ao e registr a-lo como pox.core.switch, por sua vez.
Outras aplicac oes que utilizem a interface do comutador podem continuar a funcionar,
sem modicac oes. Uma vantagem desse mecanismo e que ele depende menos do uso de
comandos import do Python, reduzindo o c odigo de inicializac ao. Como exemplo, o
c odigo a seguir, do m odulo of 01, cria um objeto respons avel pelas tarefas de controle
do protocolo OpenFlow e registra-o para que o mesmo seja facilmente referenciado por
outros objetos:
def launch (port = 6633, address = 0.0.0.0):
if core.hasComponent(of_01):
return None
l = OpenFlow_01_Task(port = int(port), address = address)
core.register(of_01, l)
return l
Orientac ao a eventos
POX usa eventos frequentemente. O systema de controle de eventos e implementado na
biblioteca revent. O princpio principal da implementac ao e que objetos se tornam
eventos, n ao apenas uma colec ao de campos e m etodos. Um objeto pode disparar eventos
e outros podem esperar por eventos gerados por aquele objeto registrando um tratador
(handler) com ele. Tratadores de eventos executam de forma n ao preemptiva, at e o seu
m.
Um objeto se torna uma fonte potencial de eventos ao herdar de EventMixin
(apesar dessa classe ter sido projetada com o objetivo de ser adequada para a combinac ao
em tempo de execuc ao de classes e objetos, n ao h a suporte a isso no momento e a unica
forma de uso apoiada no momento e herdando-se dela). Tal objeto normalmente espe-
cicar a quais tipos de eventos ele pode disparar, apesar disso n ao ser obrigat orio. Os
eventos propriamente ditos s ao normalmente classes que estendem Event e passam a
possuir certas caractersticas, mas na pr atica podem ser qualquer coisa. Qualquer objeto
interessado em um evento pode registrar um tratador para ele.

E possvel tamb em registrar o interesse em todos os eventos disparados por

um objeto de forma implcita com m etodos como EventMixin.listenTo().
Nesse caso, se Foo e Bar herdam ambos de EventMixin e Bar dispara even-
tos timeout, newMsg e linkFailure e Foo dene m etodos handle timeout,
handle newMsg e handle linkFailure, Foo pode associar todos esses trata-
dores diretamente aos eventos apropriados de Bar simplesmente executando o m etodo
self.listenTo(someBarObject). Essa forma e usualmente mais simples que
registrar cada tratador para um n umero de eventos.
7.2. Modelo de threads
Na maioria das vezes o modelo de eventos n ao levanta a necessidade da preocupac ao
do uso de threads, por em, caso um componente precise utilizar alguma forma de con-
corr encia pode ser interessante entender o modelo de threads usado no POX.
O modelo de threads do POX e programado como a biblioteca de nome recoco
para poder criar um modelo de threads cooperativas. Um modelo de threads cooperativas
consiste em um modelo no qual as pr oprias threads delegam o processamento entre si, ao
contr ario do modelo preemptivo no qual o sistema operacional ativamente interrompe o
processamento e o delega a quaisquer outra thread.
As threads cooperativas precisam ser criadas criando uma classe que estenda re-
coco.Task e implemente um m etodo run. Ap os a criac ao a thread precisa ser escalonada e
quando for escolhida para executar, ela pode considerar que executar a atomicamente at e
terminar ou at e entregar o processamento (atrav es de func oes como o Sleep, por exemplo).
Portanto e importante car atento que qualquer operac ao blocante ir a bloquear o
funcionamento do sistema por completo.
Nada impede que sejam escritos componentes que usam o modelo preemptivo
padr ao do python, por em e importante atentar que o modelo preemptivo ir a funcionar em
paralelo com o modelo cooperativo, o que pode causar problemas no desenho de alguns
componentes e dados inconsistentes.
Alguns dos problemas causados por esse tipo de interac ao podem ser corrigidos
com as seguintes ac oes:
1. Se somente e desejado que uma thread normal se comunique com uma task coo-
perativa do recoco, isso pode ser feito utilizando locks normais e estruturas thre-
adsafe como o dequeue do Python. (com cuidado para que os locks inseridos n ao
travem o processamento das outras tasks por muito tempo)
2. Se uma thread s o precisa se comunicar com eventos usando a biblioteca revent, ela
pode usar a func ao POX.deferedRaise() no lugar de self.raiseEvent(). A primeira
func ao ir a levantar um evento de dentro de uma task, fazendo isso de modo seguro.
3. Uma thread normal pode executar c odigo dentro de um bloco com re-
coco.scheduler.synchronized():. Ao executar dentro de um bloco com essa
marcac ao, a thread nativa ir a esperar por uma oportunidade de parar as threads
cooperativas. E assim, executar a o c odigo dentro do bloco antes de permitir que
as outras threads cooperativas executem novamente.
Outra funcionalidade que a biblioteca recoco implementa e um Timer simples
para funcionar com esse modelo de threads cooperativas. Ele funciona de forma similar
ao Timer comum do Python, como no exemplo a seguir:
from pox.lib.recoco import Timer
self._timer = Timer(30.0, self._timerHandler, recurring=True)
Esse trecho de c odigo chama o timer a cada 30 segundos para executar a func ao
timerHandler denida no pr oprio m odulo de forma recorrente. Os demais par ametros
denidos para o construtor da classe Timer s ao os seguintes:
timeToWake tempo a esperar antes de chamar o callback (segundos)
callback funcao a ser chamada quando o timer expirar
absoluteTime uma hora especifica para executar (usa time.time())
recurring chama o timer repetidamente ou somente uma vez
args, kw argumentos para a funcao de callback
scheduler escalonador recoco a usar (None escolhe o escalonador padrao)
started se for False, precisa chamar .start() para iniciar o timer
selfStoppable se for True, o callback pode retornar False para parar o timer
def __init__ (self, timeToWake, callback, absoluteTime = False,
recurring = False, args = (), kw = {}, scheduler = None,
started = True, selfStoppable = True):
7.3. Organizac ao do c odigo
Em sua vers ao atual, o c odigo fonte do POX est a dividido em um conjunto de diret orios
que compreende tanto m odulos essenciais para seu funcionamento b asico quanto compo-
nentes adicionais que oferecem funcionalidades adicionais uteis.
7.4. Componentes
Componente no POX e o nome dado ` as aplicac oes que s ao programadas para executar
sobre ele, utilizando a sua interface para realizar uma determinada tarefa sobre a rede
controlada. Essas aplicac oes podem ser includas pelo desenvolvedor para aproveitar as
funcionalidades j a implementadas.
Os seguintes diret orios cont em um ou mais componentes com suas determinadas
func oes:
gui backend: Tem a nalidade de oferecer informac oes para o plugin de interface
gr aca do POX. Ele monitora as informac oes que passam pelo controlador para
reunir dados necess arios para a interface gr aca.
host tracker: Mant em informac oes sobre as m aquinas conectadas ` a rede, em ter-
mos de em qual porta de qual switch OpenFlow elas est ao conectadas e como est ao
conguradas (endereco MAC e IP, quando dispoonvel). Essa informac ao pode ser
usada, por exemplo, para implementar um servico de ARP diretamente no n ucleo
da rede. Futuramente essa informac ao pode ser integrada com os componentes de
topologia.
messenger: Este componente possibilita a comunicac ao entre o POX e aplicac oes
externas atrav es de mensagens codicadas em JSON. Dessa forma e possvel reu-
nir informac oes no controlador e se comunicar com o mundo exterior de diversas
formas independentes do protocolo de comunicac ao.
misc: Componentes diversos. No momento possui dois componentes, dnsspy e
recocospy, que apresentam apenas informac oes para depurac ao do protocolo DNS
e da biblioteca de threads adotada.
samples: Pacote de componentes simples que servem como exemplo de
programac ao do POX. No momento possui 4 exemplos simples de diferentes ti-
pos de componentes que utilizam diferentes partes do sistema a m de servir como
base para a construc ao de componentes mais complexos.
topology: Reune informac oes da topologia da rede populada por demais compo-
nentes.
web: Pacote de componentes que permitem a criac ao de um servidor web para in-
teragir com o mundo exterior. No momento possui um componente de framework
web e uma interface para exibir mensagens do componente messenger em um
servidor web.
forwarding: Conjunto de componentes que trata do encaminhamento de paco-
tes. Possui diversas implementac oes que simulam switches (nveis 2 e 3) com
comportamento diferenciado para o ambiente openow.
7.5. M odulos de funcionamento
Os m odulos de funcionamento incluem o n ucleo do POX e bibliotecas auxiliares.
log: Controla o nvel e a formatac ao dos logs do POX.
lib: Bibliotecas auxiliares, como implementac oes de polticas de threads,
manipulac ao de enderecos, eventos, pacotes e outras bibliotecas que s ao utilizadas
pelos componentes.
openow: Implementac ao do protocolo Openow. Possui n ao s o uma interface
para a criac ao e tratamento de pacotes OpenFlow como alguns componentes de
exemplo que utilizam essa interface.
core.py: N ucleo do POX, possui func oes base para criac ao de componentes, como
func oes de registrar componentes, eventos, etc.
init .py: Construtor do POX.
license.py: Listagem da licenca GPL.
De interesse particular, s ao o m odulo openow, o m odulo packet, e a biblioteca
revent, que e a respons avel por gerar os eventos do POX, j a discutidos anteriormente.
Biblioteca openflow
A biblioteca openflow implementa facilidades para a comunicac ao com comutadores
OpenFlow e para a recepc ao e gerac ao de pacotes do protocolo OpenFlow. Cada vez que
um comutador OpenFlow se torna ativo no sistema, ele estabelece uma conex ao com o
controlador. Essa conex ao e representada por um objeto no sistema que e tamb em um
evento e pode ser observado por elementos que se interessem pelo surgimento de novos
comutadores, como o m odulo que mant em a vis ao da topologia da rede.
Por exemplo, pacotes oriundos dos comutadores OpenFlow s ao recebidos pelo
m odulo openow e geram um evento PacketIn, que pode ser observado por qualquer
objeto que esteja interessado na chegada de um pacote. Esse evento pode ser observado
ao se registrar um tratador com o controlador propriamente dito, ou pode ser observado
diretamente no objeto representando a conex ao de um comutador em particular.
Para criar uma ac ao de output, existe a func ao ofp action output que ao receber
uma porta do switch j a cria uma estrutura de dados de ac ao para ser concatenada a uma
mensagem criada com a func ao ofp packet out atrav es da func ao append presente no
objeto actions e depois ser enviada para o switch. Todo esse processo pode ser ilustrado
pelos seguintes comandos:
msg = of.ofp_packet_out()
msg.actions.append(of.ofp_action_output(port = of.OFPP_FLOOD))
self.connection.send(msg)
subsubsection*Biblioteca packet
A biblioteca packet possibilita que se acesse detalhes do pacote sendo manipu-
lado. Por exemplo, um pacote recebido por um evento PacketIn, ap os ser traduzido com a
func ao parse possui os campos src e dst que correspondem aos enderecos Ethernet do pa-
cote identicado. Tamb em e interessante considerar o campo next que possui informac oes
sobre o pr oximo cabecalho do pacote, como qual protocolo ele segue (IP, ARP, etc). Por
exemplo, um pacote IP possui informac oes do IP de origem e destino atrav es dos campos
next.protosrc e next.protodst. A utilizac ao desses campos car a mais clara no exemplo de
componente que ser a comentado posteriormente.
Mais detalhes sobre as func oes presentes duas bibliotecas podem ser encon-
trados nos links http://www.noxathome.org/doc/pox/pox.openflow.libopenflow_
01.html e http://www.noxathome.org/doc/pox/pox.lib.revent.revent.html.
7.6. Exemplo de programac ao de um componente POX
Um componente no POX e uma implementac ao de uma aplicac ao que usa o Framework
para escutar e levantar eventos. No POX e bem simples criar e levantar um componente.
Primeiro ser a tratada a parte de criac ao de um componente e depois como execut a-lo e
test a-lo.
7.7. Criac ao de um componente mnimo
O POX facilita muito a criac ao de componentes. Primeiro e necess ario criar um diret orio
dentro do diret orio pox ou ext, que s ao os diret orios comuns para a pesquisa de compo-
nentes. Por exemplo, ser a criado o diret orio ext/foo.
Dentro deste diret orio ser a criado o construtor init .py e o m odulo do compo-
nente foo.py. O construtor e necess ario somente se o componente for chamado pelo nome
do diret orio, caso contr ario o componente pode ser chamado pelo nome do diret orio se-
guido por um ponto seguido pelo nome do arquivo (por exemplo, foo.foo). Caso seja
interessante chamar o componente pelo nome do diret orio, o m etodo launch deve estar
listado no construtor, caso contr ario no arquivo que ser a chamado (no nosso exemplo, o
foo.py).
O m etodo launch e executado assim que o POX chama o componente. Ele tem
como nalidade registrar um m odulo como componente no n ucleo do POX. Em nosso
exemplo o m etodo launch localizado no construtor que chama a classe classe Foo no
arquivo foo.py seria o seguinte:
def launch (number, food = "spam"):
from foo import Foo
from pox.core import core
core.registerNew(foo.Foo)
Note que dois argumentos s ao necess arios, number e food, sendo que food e au-
tomaticamente colocado com o valor spam caso nenhum argumento seja passado. A
chamada do POX para esse novo componente criado com os par ametros utilizados deve
ser da seguinte forma:
./pox.py foo --food=eggs --number=42
No arquivo foo.py e necess ario que a classe Foo herde a classe EventMixIn para
que seja possibilitada de levantar eventos e que utilize a func ao herdada listenTo para
poder escutar os eventos levantados. Por exemplo:
class Foo (EventMixin):
def __init__ (self):
self.listenTo(core.openflow)
Agora o componente Foo j a escuta a eventos, mas tamb em e necess ario criar
func oes para tratar certos eventos. Para tratar o evento ConnectionUp, levantado toda vez
que o POX detecta uma nova conex ao, e necess ario que a classe Foo possua um m etodo
handle ConnectionUp (em outros eventos bastaria mudar o nome de ConnectionUp para
o evento desejado). Esse m etodo recebe como par ametro o pr oprio evento e pode realizar
qualquer computac ao com ele.
def _handle_ConnectionUp (self, event):
log.debug("Connection %s" % (event.connection,))
...
7.8. Um componente mais realista: Switch L2
Para exemplicar melhor o funcionamento de um componente, vamos usar o exemplo de
um componente que simula um switch L2 com aprendizado a partir de um comutador
OpenFlow. O comportamento desse switch e simplicado e segue o padr ao a seguir:
Para cada novo fluxo PacketIn:
1) Use o endereco de origem e a porta para atualizar a tabela endereco/porta
2) O tipo do pacote Ethernet e LLDP?
Sim:
2a) Descarte o pacote -- LLDP nunca e encaminhado
FIM
3) O destino e multicast?
Sim:
3a) Envie o pacote por todas as portas
FIM
4) O endereco de destino esta na tabela endereco/porta?
Nao:
4a) Envie o pacote por todas as portes
FIM
5) A porta de sada e a mesma de entrada?
Sim:
5a) Descarte o pacote e seus similares por um tempo
6) Instale uma entrada na tabela de fluxos do switch para que este fluxo
siga para a porta apropriada
6a) Envia os dados do pacote para a porta apropriada
FIM
Os passos do processamento descrito devem ser facilmente entendidos em face do
comportamento usual de switches Ethernet com aprendizado. O passo 2, entretanto, trata
um aspecto particular de funcionamento de redes OpenFlow. Cada comutador OpenFlow
pode executar o protocolo de descoberta de enlaces, LLDP. Esse protocolo permite, por
exemplo, que cada comutador identique seus vizinhos; dessa forma, ele poderia ser
utilizado para a construc ao de um mecanismo de composic ao da vis ao global da rede
mencionada anteriormente. Neste exemplo, esses pacotes s ao apenas descartados.
O c odigo completo e apresentado na gura 10. Elementos importantes do c odigo
s ao discutidos a seguir, com a repetic ao dos trechos de c odigo mais relevantes. Comando
de log s ao utilizados de forma simplicada para reduzir o tamanho do c odigo. Posterior-
mente discute-se o uso de mensagens mais elaboradas.
As linhas de 1 a 42 denem a classe LearningSwitch, que herda de
EventMixin para ser capaz de tratar eventos e implementa o switch propriamente dito.
Antes de analisarmos esse c odigo, devemos observar que as linhas de 44 a 53 denem ou-
tra classe derivada de EventMixin, l2 learning. Essa classe age como um constru-
tor de switches: seu construtor (linhas 4849) se registra com o componente openflow
do core, de forma que o tratador de eventos para novas conex oes (novos comutadores)
e instalado (linhas 5153). Ao detectar uma conex ao de um novo comutador um objeto
da classe LearningSwitc e criado e associado ` a conex ao. As linhas 5556 denem a
func ao launch() para esse m odulo: ela registra um objeto da classe construtora junto
ao core do POX.
Objetos da classe LearningSwitch comecam (construtor, linhas 25) identicando
a conex ao de controle do comutador OpenFlow, criando um dicion ario para registrar
1 c l a s s Le a r ni ngSwi t c h ( Event Mi xi n ) :
2 def i n i t ( s e l f , c onne c t i on ) :
3 s e l f . c onne c t i on = c onne c t i on # Swi t ch que e s t a r e mos c o n t r o l a n d o
4 s e l f . macToPort = {} # Tabel a i n t e r n a
5 s e l f . l i s t e n To ( c onne c t i on ) # Ne c e s s a r i o pa r a ouvi r e ve nt os Pa c ke t I n
6
7 def h a n d l e Pa c k e t I n ( s e l f , e ve nt ) :
8
9 Tr a t a os p a c o t e s das mensagens do s wi t c h pa r a i mpl ement ar o a l g o r i t mo
10 Met odos a u x i l i a r e s f l ood ( ) e dr op ( ) s er i am d e f i n i d a s a s e g u i r .
11
12 pa c ke t = e ve nt . pa r s e ( )
13 s e l f . macToPort [ pa c ke t . s r c ] = e ve nt . p o r t # 1
14
15 i f pa c ke t . t ype == pa c ke t . LLDP TYPE: # 2
16 dr op ( )
17 ret urn
18
19 i f pa c ke t . d s t . i s Mu l t i c a s t ( ) : # 3
20 f l ood ( ) # 3a
21 ret urn
22
23 i f pa c ke t . d s t not i n s e l f . macToPort : # 4
24 l og . debug ( Por t f o r %s unknown f l o o d i n g % ( pa c ke t . ds t , ) )
25 f l ood ( ) # 4a
26 ret urn
27
28 p o r t = s e l f . macToPort [ pa c ke t . d s t ]
29 i f p o r t == e ve nt . p o r t : # 5
30 l og . war ni ng ( Same p o r t . Drop . )
31 dr op ( 10) # 5a
32 ret urn
33
34 l og . debug ( i n s t a l l i n g f l ow )
35 msg = of . of p f l ow mod ( ) # 6
36 msg . mat ch = of . of p mat ch . f r om pa c ke t ( pa c ke t )
37 msg . i d l e t i me o u t = 10
38 msg . h a r d t i me o u t = 30
39 msg . a c t i o n s . append ( of . o f p a c t i o n o u t p u t ( p o r t = p o r t ) )
40 msg . b u f f e r i d = e ve nt . of p . b u f f e r i d # 6a
41 s e l f . c onne c t i on . send ( msg )
42
43 c l a s s l 2 l e a r n i n g ( Event Mi xi n ) :
44
45 Es per a por conexoes de s wi t c he s OpenFlow e os t r a n s f o r ma em s wi t c h e s L2 .
46
47 def i n i t ( s e l f ) :
48 s e l f . l i s t e n To ( c or e . openf l ow )
49
50 def handl e Connect i onUp ( s e l f , e ve nt ) :
51 l og . debug ( Connect i on %s % ( e ve nt . c onne c t i on , ) )
52 Le a r ni ngSwi t c h ( e ve nt . c onne c t i on )
53
54 def l a unch ( ) :
55 c or e . r e gi s t e r Ne w ( l 2 l e a r n i n g )
Figura 10. C odigo para implementac ao de um switch L2 com aprendizado no POX
os enderecos MAC conhecidos e registrando-se para receber eventos gerados pelo co-
mutador nesse caso, eventos de PacketIn. O restante do c odigo corresponde ` a
implementac ao do algoritmo discutido anteriormente, onde os passos s ao identicados
pela numerac ao apresentada nos coment arios. As func oes drop() e flood() foram
ocultadas assim como as importac oes de pacotes para simplicar o c odigo.
Alguns detalhes de implementac ao que merecemdestaque s ao o processamento do
pacote para identicac ao dos cabecalhos dos diversos protocolos que o comp oem (linha
13), o preenchimento da tabela de enderecos (linha 14) e o acesso a diversas informac oes
derivadas do processamento do pacote (linhas 16, 20, 24), o uso de func oes de log para
registrar a evoluc ao do c odigo. Finalmente, as linhas de 36 a 42 comp oem a mensagem
OpenFlow usada para registrar o uxo no comutador, com a regra para encaminhar o
pacote para a porta de sada identicada pela tabela de enderecos MAC.
7.9. Exemplo de levantamento de evento: componente de topologia
Al em de poder escutar e reagir a eventos, pode ser interessante levantar um evento para
ser tratado por outros componentes. Esse tipo de interface simplica a amarrac ao entre
diferentes m odulos.
Primeiro, e necess ario identicar o tipo de eventos que o componente pode levan-
tar. No componente de topologia isso e feito da seguinte forma:
class Topology (EventMixin):
_eventMixin_events = [
SwitchJoin,
SwitchLeave,
HostJoin,
HostLeave,
EntityJoin,
EntityLeave,
Update
]
Al emde herdar a classe EventMixin para poder levantar eventos, como descrito an-
teriormente, a lista eventMixin events e alimentada com a lista dos eventos que o m odulo
pode levantar. Cada um desses eventos e uma classe denida anteriormente que herda
alguma classe de eventos e pode ser levantado utilizando a func ao raiseEvent da classe
EventMixin. No caso do componente de topologia, essa func ao e reescrita para adicionar
umtratamento especial ao evento de Update, mas logo emseguida a func ao da superclasse
e chamada normalmente:
def raiseEvent (self, event,
*
args,
**
kw):
"""
Sempre que um evento for levantado, um evento de Update tambem
sera levantado, por isso reescrevemos o metodo do EventMixin
"""
rv = EventMixin.raiseEvent(self, event,
*
args,
**
kw)
if type(event) is not Update:
EventMixin.raiseEvent(self, Update(event))
return rv
No caso, a func ao da superclasse recebe, al em do objeto do pr oprio componente,
um objeto do tipo do evento a ser levantado, como e mostrado com o evento Update.
Ap os essa ac ao de levantamento de eventos, todos os componentes que possurem uma
func ao de tratamento para esses eventos (como por exemplo, handle HostJoin) poder ao
trat a-los normalmente como qualquer outro evento do POX.
7.10. Utilizac ao do componente de log
O POX tem uma funcionalidade de logging facilmente utilizada e congur avel em diver-
sos nveis. Para ter acesso a essa ferramenta, basta utilizar a func ao getLogger da bi-
blioteca core, passando o nome do componente registrado que voc e deseja acessar (caso
nenhum nome seja passado, o log retornado utilizar a o nome do componente corrente).
Portanto, basta recuperar o log do componente corrente com a linha:
log = core.getLogger()
Essa operac ao foi ocultada no c odigo da gura 10 por quest oes de espaco.
A classe de log do POX utiliza o logging padr ao do python, portanto utiliza o
mesmo formato de m etodos e string para poder exibir as mensagens, como os seguintes
m etodos:
Logger.info(msg,
*
args,
**
kwargs)
Logger.warning(msg,
*
args,
**
kwargs)
Logger.error(msg,
*
args,
**
kwargs)
Logger.critical(msg,
*
args,
**
kwargs)
Logger.log(lvl, msg,
*
args,
**
kwargs)
Logger.exception(msg,
*
args)
Gracas aos recursos de manipulac ao de strings de Python, e possvel construir-se
mensagens bastante informativas sem que as func oes de logging precisem manipular um
grande n umero de argumentos. Por exemplo, uma mensagem de registro mais completa
para registrar a instalac ao de um novo uxo no comutador (linha 35) na gura 10 poderia
ser re-escrita como:
log.debug("installing flow for %s.%i -> %s.%i" %
(packet.src, event.port, packet.dst, port))
Mais detalhes sobre a classe logging do python podem ser encontrados em http:
//docs.python.org/library/logging.html.
Al em disso, o POX permite que sejam declarados diferentes nveis para o log de
cada componente durante a inicializac ao atrav es de par ametros para o launch do compo-
nente de log. Por exemplo, para carregar o componente web.webcore com um nvel de
log somente de INFO enquanto os outros componentes mant em o nvel de log padr ao, o
POX dever a ser chamado da seguinte forma:
./pox.py web.webcore log.level --web.webcore=INFO
Esse comando chama o componente web.webcore e o componente log.level, pas-
sando para o ultimo o par ametro web.webcore=INFO, o que denir a o nvel de INFO para
o log do componente web.webcore.
7.11. Testando seu componente com o Mininet
O Mininet e um simulador de rede OpenFlow que consiste em criar um conjunto de
m aquinas virtuais conectadas por switches OpenFlow utilizando uma interface simples
para congurar, monitorar e modicar esta rede. Com o Mininet e possvel simular uma
rede com v arios n os para testar um componente em um ambiente mais simplicado e de
f acil manipulac ao.
No momento o Mininet oferece uma imagem de m aquina virtual j a instalada e
congurada com a aplicac ao compilada e funcional. Para utiliz a-la basta utilizar um
monitor de m aquinas virtuais (a imagem disponibilizada e do VirtualBox em http:
//www.openflow.org/downloads/OpenFlowTutorial-101311.zip ).
Ao levantar a imagem disponibilizada em um monitor de m aquinas virtuais, basta
logar na m aquina (usu ario: openow senha: openow) e congurar o Mininet para usar o
POX como controlador.
Por exemplo, em uma m aquina que o IP da m aquina executando o POX seja
10.1.1.1 e e interessante que ele seja levantado no porto 6634 (o padr ao e 6633), na
m aquina controladora deve ser levantado o POX:
./pox.py <componente> --address=10.1.1.1 --port=6634
J a na m aquina virtual do Mininet e necess ario apontar para o controlador levan-
tado:
sudo mn --controller=remote --ip=10.1.1.1 --port=6634
Mais informac oes sobre como congurar e utilizar o Mininet podem ser en-
contradas nos links http://yuba.stanford.edu/foswiki/bin/view/OpenFlow/
MininetGettingStarted, http://yuba.stanford.edu/foswiki/bin/view/
OpenFlow/MininetVMSetupNotes e http://yuba.stanford.edu/foswiki/bin/
view/OpenFlow/MininetWalkthrough .
8. Desaos de pesquisa
O paradigma de Redes Denidas por Software abre uma grande gama de novas possibili-
dades para a pesquisa em Redes de Computadores. A sec ao 6 discutiu diversos contextos
de aplicac ao em que a aplicac ao de SDN pode oferecer novas possibilidades de evoluc ao
e novos enfoques. Al em deles, certamente outras formas de aplicac ao do paradigma ainda
est ao por ser identicados e desenvolvidos em modelos de pesquisa consolidados.
Um ponto importante a considerar e que o conceito de Redes Denidas por Soft-
ware em si ainda e algo novo e muito h a para se fazer no sentido de consolidar o para-
digma. Nesse sentido, diversos desaos de pesquisa ainda se apresentam para aqueles
que desejem avaliar os princpios norteadores dessa nova area. Quest oes como qual a
abstrac ao de programac ao mais adequada, como implementar mecanismos de depurac ao,
como lidar com quest oes como distribuic ao do controlador para lidar com aspectos de
desempenho e conabilidade, se apresentam como areas abertas para a pesquisa.
Vis ao da rede
Um dos elementos chave do conceito de SDN e a noc ao da vis ao geral da rede dis-
ponvel atrav es do controlador da rede. Os controladores atuais ainda n ao apresentam
essa vis ao como um elemento estrutural b asico, apesar dela poder ser construda com
base nas informac oes derivadas das mensagens recebidas. H a uma expectativa de que
POX ofereca essa vis ao como um elemento arquitet onico b asico, atrav es da noc ao do
Modelo de Objetos da Rede, o Network Object Model (NOM). Essa abstrac ao permi-
tir a ao desenvolvedor de aplicac oes SDN exprimir suas demandas e as ac oes esperadas em
func ao do grafo de rede e n ao mais como c odigo reativo organizado ao redor dos eventos
de chegada de mensagens OpenFlow.
Em um primeiro nvel, o NOM deve reetir uma vis ao bastante clara da infra-
estrutura que constitui a rede fsica e principais elementos de software relacionados, como
switches Open vSwitch. Os objetos dessa representac ao devem exportar interfaces que
permitam ao desenvolvedor representar ac oes como a chamada de m etodos implementa-
dos por esses objetos. Esses m etodos, por sua vez, se responsabilizariam pela emiss ao
de mensagens OpenFlow ou de qualquer padr ao de controle dos elementos de rede que
esteja disponvel.
Sobre essa vis ao da rede fsica, pode-se construir novas vis oes que representem
a vis ao do usu ario/desenvolvedor para uma aplicac ao especca. Essa vis ao pode n ao
conter todos os n os da rede fsica, incluir enlaces que n ao existem na rede subjacente,
mas que podem ser implementados como t uneis sobre a mesma, ou ainda elementos de
rede virtualizados, como comutadores virtuais distribudos.
Sistema operacional da rede
Em diversos pontos deste curso nos referimos ` a noc ao de Sistema Operacional da Rede,
como o ambiente de execuc ao que estabelece a ligac ao entre as aplicac oes SDN e o subs-
trato da rede fsica. O Professor Scott Shenker, em suas palestras, tem chamado a atenc ao
para o fato de que esse conceito pode abrir o caminho para uma nova forma de se ver
e pensar Redes de Computadores, n ao mais em termos de artefatos tecnol ogicos mas de
princpios organizacionais abstratos, como ocorre com a area de Sistemas Operacionais
propriamente dita: pesquisadores podem utilizar noc oes com escalonamento de proces-
sos, algoritmos de sincronizac ao e estruturas de dados para mem oria virtual para pen-
sar sobre os princpios b asicos da area. Com esse enfoque, um desao importante e a
identicac ao de quais seriam os blocos arquitet onicos essenciais para a area de Redes de
Computadores que seriam adicionados ao ambiente de tempo de execuc ao de um con-
trolador SDN, para compor soluc oes como as possveis em outras areas da Ci encia da
Computac ao, como Sistemas Operacionais ou Bancos de Dados, que j a se organizaram
em torno desses conceitos b asicos?
Virtualizac ao de rede
Continuando a aplicac ao da noc ao de Sistema Operacional de Rede, chega-se rapidamente
ao princpio de virtualizac ao de redes. Esse conceito, bastante em voga recentemente em
projetos como o GENI, prop oe uma nova forma de se organizar as redes fsicas, de forma
a permitir a coexist encia de diferentes aplicac oes, redes l ogicas e mesmo arquiteturas de
rede. Em sua origem, a partir da rede PlanetLab, a id eia de se utilizar m aquinas virtuais
para representar roteadores virtuais tem sido bastante discutida. Entretanto, esse tipo de
virtualizac ao enfrenta o desao de vencer a barreira entre essas m aquinas virtuais e uma
implementac ao eciente do plano de dados nesse roteadores, uma vez que nas redes atuais
a otimizac ao do hardware de encaminhamento de pacotes atingiu patamares signicativos
que s ao difceis de se equiparar em software.
O fato de Redes Denidas por Software darem acesso ` as tabelas de encaminha-
mento de forma program avel oferece uma nova forma de se virtualizar a rede: n ao mais
com m aquinas virtuais independentes para cada elemento da rede virtual, mas com o
particionamento dos espacos de enderecamento dessas tabelas. Assim, vis oes abstratas
da rede, como grafos virtuais, podem ser oferecidos a cada pesquisador/desenvolvedor
que deseje implantar um novo servico/arquitetura sobre a rede fsica. Como discutido
na sec ao 4, FlowVisor oferece exatamente essa funcionalidade. Entretanto, continuando
o paralelo com a area de Sistemas Operacionais, essa seria apenas uma das dimens oes
possveis sobre a qual se organizar uma camada de virtualizac ao. Assim como monito-
res de m aquinas virtuais podem se organizar diretamente sobre o hardware, ou sobre a
interface do Sistema Operacional, ou ainda como uma m aquina virtual Java, tamb em no
contexto de SDN podem haver diferentes formas de se expressar a noc ao de redes virtuais,
com diferentes compromissos em termos de desempenho, poder de express ao e facilidade
de uso. A extens ao do NOM em POX para incluir elementos virtualizados sobre a vis ao
direta da rede fsica e um caminho possvel, mas que ainda precisa ser melhor compreen-
dido e melhor denido. Outros podem existir; por exemplo, o que seria o equivalente do
recurso de para-virtualizac ao no contexto de Sistemas Operacionais de Rede?
Abstrac oes de encaminhamento
Apesar de OpenFlow ter ganhado larga aceitac ao como a interface primordial de acesso
aos mecanismos de encaminhamento de cada comutador da rede, a area de SDN n ao
deveria se restringir a ela. Como mencioando anteriormente, outras soluc oes s ao possveis
e um controlador SDN deveria oferecer acesso a elas. N ao s o isso, mas uma soluc ao
para Redes Denidas por Software deveria oferecer uma interface de encaminhamento
pela malha da rede, independente da interface particular de cada elemento de rede. Dessa
forma, aplicac oes poderiam se concentrar em suas caractersticas especcas, fazendo uso
de primitivas de encaminhamento m-a-m na malha.
Uma possibilidade, considerada em diferentes cen arios, e que uma funcionalidade
de programac ao como OpenFlow esteja disponvel apenas nas bordas da rede, enquanto a
estrutura interna da mesma n ao seja diretamente visvel para o desenvolvedor. Isso daria
espaco para os desenvolvedores de dispositivos de rede incluirem outras funcionalidades
que n ao se casem facilmente com o modelo OpenFlow. Um exemplo de funcionalidade
desse tipo seriam soluc oes para recuperac ao r apida de falhas de roteamento, difceis de
serem implementadas de forma eciente no contexto de SDN.
Especicac ao de aplicac oes
Controladores de rede como Frenetic e FML j a demonstram que aplicac oes para Redes
Denidas por Software n ao necessariamente ser ao desenvolvidas utilizando-se lingua-
gens imperativas. Sistemas como OMNI utilizam arcaboucos de sistemas multi-agentes
para organizar suas aplicac oes e expressar as regras de controle que devem ser implemen-
tadas sobre a rede. Um dos desaos da area e certamente identicar quais paradigmas
de programac ao e quais conjuntos de abstrac oes (bibliotecas) se prestam melhor aos
objetivos de diferentes cen arios.
A integrac ao de controladores SDN a outros ambientes, como sistemas orientados
para problemas de intelig encia articial ou minerac ao de dados pode levar a novas for-
mas de se descrever a interac ao entre os componentes de rede. Nesse sentido, o tipo de
aplicac ao alvo e seu contexto de denic ao podem guiar o desenvolvimento das abstrac oes
de programac ao da rede em direc oes at e agora n ao imaginadas.
Depurac ao
A inclus ao de diversos nveis de abstrac ao entre a aplicac ao de rede e a infra-estrutura
fsica cria a necessidade de regras de traduc ao entre o que e expressado na linguage/in-
terface da aplicac ao e como os conceitos associados s ao colocados em pr atica na na rede
fsica. Nesse processo, existe a possibilidade de que a congurac ao da rede fsica n ao re-
presente exatamente o que era desejado no nvel superior. Determinar quando isso acon-
tece e, se possvel, identicar as causas dessas inconsist encias exige que sejam denidas
t ecnicas de depurac ao (debugging) adequadas.
Como no caso do item anterior, as abstrac oes adotadas pelo controlador SDN,
pela linguagem de programac ao associada determinar ao o tipo de recursos de depurac ao
que podem ser oferecidos. Qualquer soluc ao adotada, entretanto, deve se pautar pelo
acompanhamento das regras de transformac ao ao longo dos nveis de abstrac ao, de forma
a permitir que se estabelecam paralelos entre cada abstrac ao de alto nvel e as regras de
controle por ela geradas na rede fsica. Por exemplo, Frenetic se vale de sua natureza
funcional para facilitar a depurac ao das regras de controle [Reitblatt et al. 2011].
Distribuic ao

E sempre importante relembrar que a noc ao da vis ao global da rede como algo cen-
tralizado em SDN e uma vis ao l ogica. N ao h a nenhuma exig encia no paradigma
que determine que essa vis ao deve ser obrigatoriamente implementada de forma cen-
tralizada. Requisitos de desempenho ou de toler ancia a falhas podem levar a uma
decis ao de distribuic ao dessa vis ao global. As decis oes de projeto que levaram ao
modelo do sistema Onix, por exemplo, mostram um caminho onde a distribuic ao
em algum nvel foi considerada essencial para a soluc ao nal. Outros sistemas,
como Hyperow [Tootoonchian and Ganjali 2010] apresentam outros caminhos para essa
distribuic ao. Certamente, emfunc ao das diferentes abstrac oes de programac ao que podem
vir a surgir em controladores SDN e das diferentes linguagens/interfaces de programac ao
possveis, muitas linhas de ac ao podem ser exploradas nesse contexto.
9. Considerac oes nais
O potencial do paradigma de Redes Denidas por Software apenas comeca a ser explo-
rado, mas j a e grande o interesse pela area entre pesquisadores e empresas da area. O
fato de j a estarem no mercado os primeiros dispositivos comerciais baseados no padr ao
OpenFlow conrmam o momento positivo dessa iniciativa. Al em disso, e claro interesse
de diversas grandes empresas da area de dispositivos de rede e o surgimento de diversas
novas empresas de tecnologia (start-ups) ao redor desses conceitos.
Nesse cen ario, neste trabalho buscamos apresentar uma vis ao dos aspectos
te oricos e pr aticos envolvidos no desenvolvimento de pesquisas em SDN. Em particu-
lar, apresentamos os elementos que devem ser considerados ao se iniciar um trabalho na
area, com enfase no controlador de rede. Esse elemento tem papel essencial em qualquer
iniciativa sobre SDN, uma vez que o software que dene esses sistemas deve ser desen-
volvido com base nos recursos de express ao oferencidos pelo controlador. As diversas
opc oes de controladores disponveis foram descritas e os aspectos pr aticos de desenvol-
vimento de aplicac oes SDN foram discutidos ` a luz do controlador POX, recentemente
lancado e especialmente desenvolvido para o ambiente de pesquisa e ensino.
Considerando-se o sucesso do paradigma e os desaos identicados neste texto,
consideramos que existe um campo amplo para o desenvolvimento de novos projetos de
pesquisa enfocando Redes Denidas por Software, seja como ferramenta para o desenvol-
vimento de novos servicos e aplicac oes de redes, seja como alvo de estudos sobre novas
abstrac oes e soluc oes de implementac ao. Certamente, os trabalhos mais interessantes na
area ainda est ao por vir.
Al em das refer encias apresentadas a seguir, alguns stios concentram
grande parte das discuss oes sobre os conceitos aqui apresentados. Os in-
teressados na area devem acompanhar as atividades dos desenvolvedores em
stios como noxathome.org, noxrepo.org, openflow.org, openwrt.org,
openvswitch.org, opennetworking.org, opennetsummit.org, entre ou-
tros.
Agradecimentos
Este trabalho foi parcialmente nanciado pelo Instituto Nacional de Ci encia e Tecnolo-
gia para a Web (InWeb), pelo CNPq, FAPEMIG, HP Brasil, pelo programa UOL Bolsa
Pesquisa (www.uol.com.br) e pelo Programa de Visitas Brasil-ICSI do Movimento Brasil
Colaborativo/ABDI. Murphy McCauley e o desenvolvedor principal do POX e colaborou
com diversas informac oes utilizadas aqui. Muitos dos elementos apresentados sobre de-
saos de pesquisa na area de controladores SDN foram derivados de discuss oes com o
Prof. Scott Shenker.
Refer encias
(2012). The beacon controller. https://openow.stanford.edu/display/Beacon/Home.
(2012). Floodlight. http://oodlight.openowhub.org/.
(2012). Nec programmable ow. http://www.necam.com/pow/.
(2012). Openstack:open source software for building private and public clouds.
http://openstack.org/.
(2012). Simple network access control. http://www.openow.org/wp/snac/.
(2012). Trema: Full-stack openow framework for ruby and c.
http://trema.github.com/trema/.
Braga, R. B., Mota, E. M., and Passito, A. P. (2010). Lightweight ddos ooding attack
detection using nox/openow. In Proceedings of the Annual IEEE Conference on Lo-
cal Computer Networks, pages 408415, Los Alamitos, CA, USA. IEEE Computer
Society.
Cai, Z., Cox, A. L., and Ng, T. S. E. (2010). Maestro: A system for scalable openow
control. Technical Report TR10-08, Rice University.
Calvert, K. L., Edwards, W. K., Feamster, N., Grinter, R. E., Deng, Y., and Zhou, X.
(2011). Instrumenting home networks. SIGCOMM Comput. Commun. Rev., 41(1):84
89.
Casado, M., Erickson, D., Ganichev, I. A., Grifth, R., Heller, B., Mckeown, N., Moon,
D., Koponen, T., Shenker, S., and Zaris, K. (2010a). Ripcord: A modular platform
for data center networking. EECS Department Technical Report UCB/EECS-2010-93,
University of California, Berkeley.
Casado, M., Freedman, M. J., Pettit, J., Luo, J., Gude, N., McKeown, N., and Shenker, S.
(2009). Rethinking enterprise network control. IEEE/ACM Transactions on Networ-
king, 17(4):12701283.
Casado, M., Koponen, T., Ramanathan, R., and Shenker, S. (2010b). Virtualizing the
network forwarding plane. In Proceedings of the Workshop on Programmable Routers
for Extensible Services of Tomorrow, PRESTO 10, pages 8:18:6, New York, NY.
Davie, B. S. and Farrel, A. (2008). MPLS: Next Steps: Next Steps. Morgan Kaufmann
Publishers Inc., San Francisco, CA, USA.
Dixon, C., Mahajan, R., Agarwal, S., Brush, A. J., Lee, B., Saroiu, S., and Bahl, V. (2010).
The home needs an operating system (and an app store). In Proceedings of the Ninth
ACM SIGCOMM Workshop on Hot Topics in Networks, Hotnets 10, pages 18:118:6,
New York, NY, USA. ACM.
Elliott, C. and Falk, A. (2009). An update on the geni project. SIGCOMM Comput.
Commun. Rev., 39(3):2834.
Farias, F. N. N., Salvatti, J. J., Dias, J. M., Toda, H. S., Cerqueira, E., and Abel em, A.
J. G. (2011). Implementac ao de um novo datapath openow em ambientes de switches
legados. In Anais do II Workshop de Pesquisa Experimental em Internet do Futuro,
pages 1518. SBC.
Feamster, N. (2010). Outsourcing home network security. In Proceedings of the 2010
ACM SIGCOMM workshop on Home networks, HomeNets 10, pages 3742, New
York, NY, USA. ACM.
Foster, N., Freedman, M. J., Harrison, R., Rexford, J., Meola, M. L., and Walker, D.
(2010). Frenetic: a high-level language for openow networks. In Proceedings of the
Workshop on Programmable Routers for Extensible Services of Tomorrow, PRESTO
10, pages 6:16:6, New York, NY.
Gude, N., Koponen, T., Pettit, J., Pfaff, B., Casado, M., McKeown, N., and Shenker,
S. (2008). Nox: towards an operating system for networks. SIGCOMM Comput.
Commun. Rev., 38:105110.
Heller, B., Erickson, D., McKeown, N., Grifth, R., Ganichev, I., Whyte, S., Zaris, K.,
Moon, D., Shenker, S., and Stuart, S. (2010a). Ripcord: a modular platform for data
center networking. SIGCOMM Comput. Commun. Rev., 40:457458.
Heller, B., Seetharaman, S., Mahadevan, P., Yiakoumis, Y., Sharma, P., Banerjee, S., and
Mckeown, N. (2010b). Elastictree: Saving energy in data center networks. In Procee-
dings of the 7th Usenix Symposium on Networked Systems Design and Implementation
(NSDI).
Hinrichs, T. L., Gude, N. S., Casado, M., Mitchell, J. C., and Shenker, S. (2009). Prac-
tical declarative network management. In Proceedings of the 1st ACM workshop on
Research on enterprise networking, WREN 09, pages 110, New York, NY.
Kempf, J., Whyte, S., Ellithorpe, J., Kazemian, P., Haitjema, M., Beheshti, N., Stuart, S.,
and Green, H. (2011). Openow mpls and the open source label switched router. In
Proceedings of the 23rd International Teletrafc Congress, ITC 11, pages 814. ITCP.
Kohler, E., Morris, R., Chen, B., Jannotti, J., and Kaashoek, M. F. (2000). The click
modular router. ACM Trans. Comput. Syst., 18(3):263297.
Koponen, T., Casado, M., Gude, N., Stribling, J., Poutievski, L., Zhu, M., Ramanathan,
R., Iwata, Y., Inoue, H., Hama, T., and Shenker, S. (2010). Onix: a distributed con-
trol platform for large-scale production networks. In Proceedings of the 9th USENIX
conference on Operating systems design and implementation, OSDI10, pages 16,
Berkeley, CA. USENIX Association.
Lantz, B., Heller, B., and McKeown, N. (2010). A network in a laptop: rapid prototyping
for software-dened networks. In Proceedings of the Ninth ACMSIGCOMMWorkshop
on Hot Topics in Networks, Hotnets 10, pages 19:119:6, New York, NY, USA. ACM.
Mattos, D. M. F., Fernandes, N. C., da Costa, V. T., Cardoso, L. P., Campista, M. E. M.,
Costa, L. H. M. K., and Duarte, O. C. M. B. (2011). Omni: Openow management
infrastructure. In Proceedings of the 2nd IFIP International Conference Network of
the Future - NoF2011, pages 15. IFIP.
McKeown, N., Anderson, T., Balakrishnan, H., Parulkar, G., Peterson, L., Rexford, J.,
Shenker, S., and Turner, J. (2008). Openow: enabling innovation in campus networks.
SIGCOMM Comput. Commun. Rev., 38:6974.
Mehdi, S. A., Khalid, J., and Khayam, S. A. (2011). Revisiting trafc anomaly detection
using software dened networking. In Proceedings of the 14th International Sympo-
sium on Recent Advances in Intrusion Detection (RAID), pages 161180.
Mogul, J. C., Tourrilhes, J., Yalagandula, P., Sharma, P., Curtis, A. R., and Banerjee, S.
(2010). Devoow: cost-effective ow management for high performance enterprise
networks. In Proceedings of the Ninth ACM SIGCOMM Workshop on Hot Topics in
Networks, Hotnets 10, pages 1:11:6, New York, NY, USA. ACM.
Mundada, Y., Sherwood, R., and Feamster, N. (2009). An openow switch element for
click. In Proceedinds on the Symposium on Click Modular Router.
Nascimento, M. R., Rothenberg, C. E., Salvador, M. R., Corr ea, C. N. A., De Lucena,
S. C., and Magalh aes, M. F. (2011). Virtual routers as a service: The routeow ap-
proach leveraging software-dened networks. In Proceedings of the 6th International
Conference on Future Internet Technologies (CFI), pages 03.
Peterson, L. and Roscoe, T. (2006). The design principles of planetlab. SIGOPS Oper.
Syst. Rev., 40(1):1116.
Pettit, J., Gross, J., Pfaff, B., Casado, M., and Crosby, S. (2010). Virtual switching
in an era of advanced edges. In Proceedings of the 2nd Workshop on Data Center
- Converged and Virtual Ethernet Switching (DC CAVES), DC CAVES, pages 17,
Amsterdam, The Netherlands. ITC.
Pfaff, B., Pettit, J., Amidon, K., Casado, M., Koponen, T., and Shenker, S. (2009). Ex-
tending networking into the virtualization layer. In Proceedings of the Eighth ACM
Workshop on Hot Topics in Networks (HotNets-VIII).
Ram, K. K., Mudigonda, J., Cox, A. L., Rixner, S., Ranganathan, P., and Santos, J. R.
(2010). snich: efcient last hop networking in the data center. In Proceedings of
the 6th ACM/IEEE Symposium on Architectures for Networking and Communications
Systems, ANCS 10, pages 26:126:12, New York, NY, USA. ACM.
Reitblatt, M., Foster, N., Rexford, J., and Walker, D. (2011). Consistent updates for
software-dened networks: Change you can believe in. In Proceedings of ACM SIG-
COMM Workshop on Hot Topics in Networks (HotNets), pages 16.
Rodrigues, H., Santos, J. R., Turner, Y., Soares, P., and Guedes, D. (2011). Gatekeeper:
Supporting bandwidth guarantees for multi-tenant datacenter networks. In Proceedings
of the 3rd Usenix Workshop on I/O Virtualization (WIOV 11), Portland, OR. Usenix.
Sherwood, R. et al. (2010). Carving research slices out of your production networks with
openow. SIGCOMM Comput. Commun. Rev., 40:129130.
Sherwood, R., Gibb, G., Yap, K.-K., Apenzeller, G., Casado, M., McKeown, N.,
and Parulkar, G. (2009). Flowvisor: A network virtualization layer. Tech. Rep.
OPENFLOWTR-2009-1, OpenFlowSwitch.org.
Silva, G., Arantes, A., Steding-Jessen, K., Hoepers, C., Chaves, M., Jr., W. M., and Gue-
des, D. (2011). SpSb: um ambiente seguro para o estudo de spambots. In Anais do
Simp osio Brasileiro de Seguranca, pages 15, Braslia, DF. SBC.
Tennenhouse, D. L. and Wetherall, D. J. (2007). Towards an active network architecture.
SIGCOMM Comput. Commun. Rev., 37(5):8194.
Tootoonchian, A. and Ganjali, Y. (2010). Hyperow: a distributed control plane for
openow. In Proceedings of the 2010 internet network management conference on Re-
search on enterprise networking, INM/WREN10, pages 33, Berkeley, CA. USENIX
Association.
Turner, J. S. (2006). A proposed architecture for the geni backbone platform. In Procee-
dings of the 2006 ACM/IEEE symposium on Architecture for networking and commu-
nications systems, ANCS 06, pages 110, New York, NY, USA. ACM.