Livrodeminicursos PDF

XXX Simpsio Brasileiro de Redes de Computadores e
Sistemas Distribudos
30 de Abril a 4 de Maio de 2012
Ouro Preto, MG
Minicursos
Livro Texto
Editora
Sociedade Brasileira de Computao (SBC)
Organizadores
Antnio Jorge Gomes Abelm (UFPA)
Jussara Marques de Almeida (UFMG)
Dorgival Olavo Guedes Neto (UFMG)
Realizao
Departamento de Cincia da Computao
Universidade Federal de Minas Gerais (UFMG)
Promoo
Laboratrio Nacional de Redes de Computadores (LARC)
ii Minicursos Livro Texto
Copyright c 2012 da Sociedade Brasileira de Computao
Todos os direitos reservados
Capa: Centro de Comunicaes (Cedecom) da UFMG
Produo Editorial: Antnio Jorge Gomes Abelm,
Jussara Marques de Almeida,
Dorgival Olavo Guedes Neto
Cpias Adicionais:
Av. Bento Gonalves, 9500 Setor 4 Prdio 43.412 Sala 219
Bairro Agronomia CEP 91.509-900 Porto Alegre RS
Fone: (51) 3308-6835
E-mail: sbc@sbc.org.br
Dados Internacionais de Catalogao na Publicao (CIP)
Simpsio Brasileiro de Redes de Computadores e Sistemas Distribudos (30.: 2012 :
Ouro Preto, MG).
Minicursos / XXX Simpsio Brasileiro de Redes de Computadores e Sistemas
Distribudos ; organizadores Antnio Jorge Gomes Abelm, Dorgival Olavo Guedes Neto,
Jussara Marques de Almeida. Porto Alegre : SBC, c2012.
264 p.
ISSN 3277-4978
1. Redes de computadores. 2. Sistemas distribudos. I. Abelm, Antnio Jorge Gomes.
II. de Almeida, Jussara Marques. III. Guedes Neto, Dorgival Olavo. IV Ttulo.
XXX Simpsio Brasileiro de Redes de Computadores e Sistemas Distribudos - SBRC 2012 iii
Promoo
Diretoria
Presidente
Paulo Roberto Freire Cunha (UFPE)
Vice-Presidente
Lisandro Zambenedetti Granville (UFRGS)
Diretor Administrativo
Luciano Paschoal Gaspary (UFRGS)
Diretor de Finanas
Luci Pirmez (UFRJ)
Diretor de Eventos e Comisses Especiais
Altigran Soares da Silva (UFAM)
Diretora de Educao
Mirella Moura Moro (UFMG)
Diretora de Publicaes
Karin Koogan Breitman (PUC-Rio)
Diretora de Planejamento e Programas Especiais
Ana Carolina Brando Salgado (UFPE)
Diretora de Secretarias Regionais
Thais Vasconcelos Batista (UFRN)
Diretor de Divulgao e Marketing
Edson Norberto Cceres (UFMS)
Diretor de Relaes Prossionais
Roberto da Silva Bigonha (UFMG)
Diretor de Competies Cientcas
Ricardo de Oliveira Anido (UNICAMP)
Diretor de Cooperao com Sociedades Cientcas
Raimundo Jos de Arajo Macdo (UFBA)
iv Minicursos Livro Texto
Promoo
Conselho
Mandato 20011-2015
Ariadne Carvalho (UNICAMP)
Carlos Eduardo Ferreira (IME - USP)
Jos Carlos Maldonado (ICMC - USP)
Luiz Fernando Gomes Soares (PUC-Rio)
Marcelo Walter (UFRGS)
Mandato 2009-2013
Flvio Rech Wagner (UFRGS)
Itana Maria de Souza Gimenes (UEM)
Jacques Wainer (UNICAMP)
Silvio Romero de Lemos Meira (UFPE)
Virglio Almeida (UFMG)
Suplentes 20011-2013
Csar A. F. De Rose (PUCRS)
Maria Izabel Cavalcanti Cabral (UFCG)
Renata Mendes de Arajo (UNIRIO)
Ricardo Augusto da Luz Reis (UFRGS)
Laboratrio Nacional de Redes de Computadores (LARC)
Diretoria
Diretor do Conselho Tcnico-Cientco
Diretor Executivo
Clio Vinicius Neves de Albuquerque (UFF)
Vice-Diretora do Conselho Tcnico-Cientco
Artur Ziviani (LNCC)
Vice-Diretor Executivo
Elias P. Duarte Jr. (UFPR)
Membros Institucionais
CEFET-CE, CEFET-PR, IME, INPE/MCT, LNCC, PUCPR, PUC-RIO, SESU/MEC,
UECEM UERJ, UFAM, UFBA, UFC, UFCG, UFES, UFF, UFMG, UFMS,UFPA,
UFPB, UFPE, UFPR, UFRGS, UFRJ, UFRN, UFSC, UFSCAR, UNICAMP,
UNIFACS, USP
XXX Simpsio Brasileiro de Redes de Computadores e Sistemas Distribudos - SBRC 2012 v
Realizao
Comit de Organizao
Coordenadores Gerais
Jussara Marques de Almeida (UFMG)
Dorgival Olavo Guedes Neto (UFMG)
Coordenao do Comit de Programa
Elias P. Duarte Jr. (UFPR)
Jos F. de Rezende (UFRJ)
Coordenao de Palestras e Tutoriais
Edmundo Madeira (UNICAMP)
Coordenao de Painis e Debates
Francisco V. Brasileiro (UFCG)
Coordenao de Minicursos
Coordenao de Workshops
Aldri Luiz dos Santos (UFPR)
Coordenadores do Salo de Ferramentas
Humberto Torres Marques Neto (PUC-Minas)
Ricardo Augusto Rabelo Oliveira (UFOP)
Comit Consultivo
Artur Ziviani (LNCC)
Bruno Schulze (LNCC)
Clio Albuquerque (UFF)
Luci Pirmez (UFRJ)
Marinho Pilla Barcellos (UFRGS)
Ronaldo Alves Ferreira (UFMS)
Thais Vasconcelos Batista (UFRN)
vi Minicursos Livro Texto
Realizao
Organizao Local
Antonio Alfredo F. Loureiro (UFMG)
Carlos Frederico Marcelo da Cunha Cavalcanti (UFOP)
Cristina Duarte Murta (CEFET- MG)
Daniel Fernandes Macedo (UFMG)
Dorgival Guedes Neto (UFMG)
Fabrcio Benevenuto (UFOP)
Flvia Otoni (UFMG)
Humberto Torres Marques Neto (PUC-Minas)
talo Cunha (UFMG)
Jos Marcos Nogueira (UFMG)
Jussara M. Almeida (UFMG)
Luis Filipe M. Vieira (UFMG)
Marcos Vieira (UFMG)
Murilo Silva Monteiro (UFMG)
Olga Goussevskaia (UFMG)
Raquel Mini (PUC-Minas)
Ricardo A. Rabelo (UFOP)
XXX Simpsio Brasileiro de Redes de Computadores e Sistemas Distribudos - SBRC 2012 vii
Mensagem dos Coordenadores Gerais
Sejam bem vindos ao XXX Simpsio Brasileiro de Redes de Computadores e Sistemas
Distribudos (SBRC 2012) na bela e histrica cidade de Ouro Preto, MG! Promovido an-
ualmente pela Sociedade Brasileira de Computao (SBC) e pelo Laboratrio Nacional de
Redes de Computadores (LARC), o SBRC 2012, em sua trigsima edio, busca manter
a sua posio como o mais importante evento cientco nacional em Redes de Computa-
dores e Sistemas Distribudos e um dos maiores da rea de Informtica no pas. Ele busca
tambm, como sua tradio, estimular a troca de ideias e experincias, a discusso de
temas de pesquisa desaadores, assim como a aproximao entre estudantes, professores,
pesquisadores e prossionais.
Para tal, o SBRC 2012 est com uma programao bastante rica, variada e com alta qual-
idade tcnica. So 19 sesses tcnicas com a apresentao de artigos completos cobrindo
uma ampla lista de tpicos bastante relevantes e atuais nas reas de Redes de Computa-
dores e Sistemas Distribudos; 3 sesses tcnicas com apresentaes de ferramentas; 5
minicursos, com quatro horas de durao cada, sobre temas atuais normalmente no abor-
dados nas grades curriculares; 5 palestras e 1 tutorial proferidos por pesquisadores de alto
renome internacional; 3 palestras de prossionais de empresas de reconhecida excelncia
e liderana no mercado e 3 painis versando sobre temas atuais e polmicos. Alm dessas
atividades, 8 workshops ocorrero em paralelo com o evento: XVII Workshop de Gern-
cia e Operao de Redes e Servios (WGRS), XIII Workshop da Rede Nacional de Ensino
e Pesquisa (WRNP), XIII Workshop de Testes e Tolerncia a Falhas (WTF), X Workshop
de Computao em Grade e Aplicaes (WCGA), VIII Workshop de Redes Dinmicas
e Sistemas P2P (WP2P), III Workshop de Pesquisa Experimental na Internet do Futuro
(WPEIF), II Workshop on Autonomic Distributed Systems (WoSiDA) e II Workshop de
Redes de Acesso em Banda Larga (WRA).
Em particular, em comemorao s suas 30 edies, o SBRC 2012 traz algumas novi-
dades. A programao tcnica conta com uma sesso de artigos convidados, escritos por
expoentes da comunidade. Estes artigos vm relembrar a histria do evento e da sua co-
munidade cientca, fomentando uma reexo sobre a sua evoluo ao longo dessas 30
edies e sobre novos rumos para essa comunidade. A programao tambm conta com
um painel que visa fazer uma retrospectiva crtica dos 30 anos de pesquisa em Redes no
Brasil, contrastando-a com a evoluo da rea globalmente. Por m, para homenagear
aqueles que contriburam signicativamente para o desenvolvimento da pesquisa e o for-
talecimento da comunidade cientca nas reas de Redes de Computadores e Sistemas
Distribudos no Brasil, o SBRC 2012 cria o Prmio Destaque SBRC, que passar a ser
concedido anualmente. Nesta primeira edio do prmio, o homenageado o Professor
Edmundo Albuquerque de Souza e Silva, da Universidade Federal do Rio de Janeiro, em
reconhecimento s suas contribuies cientcas e aos servios prestados em benefcio do
SBRC e de sua comunidade.
viii Minicursos Livro Texto
A organizao de um evento do porte e da importncia do SBRC s pode ser realizada
se contar com a ajuda de uma equipe capacitada e coesa. Gostaramos de agradecer aos
membros dos Comits de Organizao Geral e Local pelo trabalho voluntrio de excelente
qualidade e pelo apoio incansvel durante as vrias etapas da organizao deste evento.
Somos muito gratos tambm ao apoio prestado pela SBC, particularmente aos membros
da Comisso Especial de Redes de Computadores e Sistemas Distribudos, pela prontido
e ateno que nos foram dedicadas. Gostaramos de agradecer ainda ao Comit Gestor
da Internet no Brasil (CGI.br), s agncias governamentais de fomento CNPq, CAPES
e FAPEMIG, ao Instituto Nacional de Cincia e Tecnologia para a Web (INWeb) e aos
patrocinadores por reconhecerem e valorizarem a importncia do SBRC como frum de
divulgao de pesquisa e inovao. Por m, nossos agradecimentos ao Departamento de
Cincia da Computao da UFMG, por viabilizar a realizao deste evento, assim como
ao Departmento de Computao da UFOP, pelo apoio a essa realizao.
Em nome do comit organizador do SBRC 2012, desejamos a todos uma semana bastante
produtiva e agradvel. Esperamos que a tradicional hospitalidade mineira e que a fabu-
losa e setecentista Ouro Preto deixem lembranas inesquecveis desta trigsima edio do
SBRC.
Jussara Marques de Almeida
Dorgival Olavo Guedes Neto
Coordenadores Gerais do SBRC 2012
XXX Simpsio Brasileiro de Redes de Computadores e Sistemas Distribudos - SBRC 2012 ix
Mensagem do Coordenador de Minicursos
com grande satisfao que apresento os minicursos que sero ministrados na 30a.
edio do Simpsio Brasileiro de Redes de Computadores e Sistemas Distribudos (SBRC
2012). Ao longo dos anos, a abrangncia de qualidade do trabalho da comunidade acad-
mica brasileira vem se reetindo na quantidade de submisses enviadas. Recebemos vinte
e oito (28) propostas de minicursos de excelente nvel tcnico, entre as quais foram sele-
cionadas cinco (5) para serem apresentadas durante o evento, representando uma taxa de
aceitao de aproximadamente 18%. Cada proposta recebeu pelo menos trs (3) avali-
aes, feitas por um criterioso Comit de Avaliao composto de vinte e cinco (25)
pesquisadores especialistas nas diversas reas de redes de computadores e sistemas dis-
tribudos.
Os minicursos selecionados apresentam temtica bastante atual e reetem o cuidado do
Comit de Avaliao em escolher assuntos novos, no comumente tratados em cursos
regulares, mas que ao mesmo tempo despertem o interesse dos participantes. Em sua
maioria abordam questes relativas infraestrutura e servios para a Internet do futuro.
A investigao sobre o futuro da Internet tornou-se uma prioridade estratgica em todo o
mundo, com importantes iniciativas nos EUA, Europa, Japo, Coria e China. Os desen-
volvimentos tecnolgicos esperados da Internet do Futuro e as tendncias para infraestru-
turas inteligentes (em energia, sade, mobilidade de trabalho, meio ambiente, etc) repre-
sentam uma excelente oportunidade para apresentar solues sustentveis e que possam
ser absorvidas pela sociedade. Novos paradigmas de armazenamento, busca e distribuio
de contedo, alm de solues inovadoras para o desenvolvimento e congurao de re-
des sero necessrios. Esses requisitos, dentre outros, formam o objeto de estudo dos
captulos a seguir.
O Captulo 1 apresenta os desaos e as novas tcnicas para tratar com grandes massas
de dados na nuvem. So discutidos os problemas relacionados s aplicaes de grandes
massas de dados; as questes relativas aos protocolos de comunicao, nos ambientes
inter e intra-datacenter; as propostas e solues tecnolgicas, e principais iniciativas de
pesquisa na rea. So identicados, tambm, os componentes chave para o suporte de
grandes massas de dados na Internet, incluindo novas estratgias nas reas de bancos de
dados, minerao de dados, computao paralela e visualizao de dados, assim como
novos protocolos de comunicao e tcnicas de virtualizao.
O Captulo 2 aborda os fundamentos, as tecnologias e as tendncias sobre segurana
de redes virtuais. So apresentados os principais desaos relacionados a esse tipo de
ambiente, algumas das principais ameaas, bem como solues propostas na literatura
para prover diferentes aspectos de segurana. As preocupaes relacionadas segurana
de dispositivos de roteamento e de canais de comunicao compartilhados so debatidas
emconjunto comas solues de proteo s infraestruturas de redes virtuais emambientes
reais e em larga escala.
x Minicursos Livro Texto
O estado da arte de sistemas de controle e monitoramento de infraestruturas para exper-
imentao de redes de comunicao o tema do Captulo 3. Os arcabouos de controle
e monitoramento, chamados CMFs (Control and Management Frameworks), permitem,
entre outras coisas, registrar os recursos, controlar o acesso aos servios da infraestrutura
para experimentao, gerenciar o ciclo de experimentos, monitorar e armazenar os resul-
tados. So descritos os requisitos, as implementaes, as implantaes e os esforos de
federalizao desses sistemas de controle e monitoramento. Exemplos e estudos de caso
sobre o uso de alguns dos principais CMFs atualmente utilizados so apresentados, com
o intuito de incentivar os pesquisadores em redes de comunicao e sistemas distribudos
a realizar experimentos com esses arcabouos.
O Captulo 4 explora uma abordagem sistmica sobre redes denidas por software, com
aspectos de teoria e prtica. Primeiro discute os diversos componentes de um sistema de
rede denido por software, incluindo solues para virtualizao dos elementos de rede,
sistemas operacionais de rede e novas aplicaes, bem como os desaos de pesquisa que
esse paradigma ainda precisa enfrentar e os diversos esforos em andamento no Brasil
e no mundo. Para ilustrar as novas possibilidades de desenvolvimento que o paradigma
oferece, os autores apresentam exemplos de aplicaes que podem ser desenvolvidas com
o sistema operacional de redes POX, desenvolvido especicamente para ns de pesquisa
e ensino.
No Captulo 5 so discutidos os desaos das Redes Orientadas a Contedo (ROCs). As-
pectos de roteamento, nomeao de contedos e uso de caches de contedo nos elementos
do ncleo da rede para aumentar a ecincia da localizao e da entrega e a disponibil-
idade de contedos so algumas das questes debatidas pelos autores. So apresentados
aspectos prticos para implantao das ROCs, incluindo como a mobilidade e a segurana
dos contedos podem ser melhoradas com esse novo paradigma.
Gostaria de agradecer Jussara Marques de Almeida e ao Dorgival Olavo Guedes Neto da
UFMG, coordenadores do SBRC 2012, pela conana e pelo apoio recebido ao longo das
nossas interaes. Meu agradecimento tambm a todos os membros do Comit de Avali-
ao pelo comprometimento, pela reatividade e pelas boas discusses que contriburam
para termos uma seleo criteriosa e construtiva. Gostaria, por m, de agradecer de forma
especial aos autores que, mais uma vez, prestigiaram a trilha de minicursos do SBRC, en-
caminhando propostas qualicadas e muito bem estruturadas.
Antnio Jorge Gomes Abelm
Coordenador de Minicursos do SBRC 2012
XXX Simpsio Brasileiro de Redes de Computadores e Sistemas Distribudos - SBRC 2012 xi
Comit de Avaliao de Minicursos
Alexandre Sztajnberg (UERJ)
Alfredo Goldman (IME-USP)
Alysson Bessani (Universidade de Lisboa)
Antnio Tadeu Gomes (LNCC)
Carlos Kamienski (UFABC)
Carlos Montez (UFSC)
Dbora Muchaluat-Saade (UFF)
Edmundo Madeira (UNICAMP)
Eduardo Cerqueira (UFPA)
Eduardo Nakamura (UFAM)
Fabola Greve (UFBA)
Fatima Duarte-Figueiredo (PUC Minas)
Genaro Costa (UFBA)
Hana Rubinsztejn (UFMS)
Jussara Almeida (UFMG)
Kleber Cardoso (UFG)
Lisandro Granville (UFRGS)
Lucia Drummond (UFF)
Luciano Gaspary (UFRGS)
Luis Carlos De Bona (UFPR)
Marcelo de Amorim (UPMC)
Marinho Barcellos (UFRGS)
Nabor Mendonca (UNIFOR)
Paulo Andr Gonalves (UFPE)
Regina Araujo (UFSCAR)
xii Minicursos Livro Texto
Sumrio
1 GRANDES MASSAS DE DADOS NA NUVEM: DESAFIOS E TC-
NICAS PARA INOVAO 1
1.1 Introduo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Grandes Massas de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.1 Aplicaes e valores tpicos de grandes massas de dados . . . . . . . . 5
1.2.2 Ciclo de vida dos dados . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3 Arquiteturas em Aglomerao . . . . . . . . . . . . . . . . . . . . . . . 10
1.4 Modelos de Programao para Arquiteturas em Aglomerao . . . . . . . 14
1.5 Modelos de Interconexo para Arquiteturas em Aglomerao . . . . . . . 18
1.5.1 Fat-tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.5.2 BCube . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.5.3 Camada Virtual 2 (VL2) . . . . . . . . . . . . . . . . . . . . . . . 24
1.5.4 Jellysh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.6 A Internet e a Migrao de Grandes Massas de Dados . . . . . . . . . . . 27
1.6.1 Cenrios de sistema de comunicao interno a um centro de dados . . . 27
1.6.2 Cenrios de sistema de comunicao entre centros de dados . . . . . . 28
1.7 Solues para a Migrao dentro de um Centro de Dados . . . . . . . . . 29
1.7.1 Enlaces multi-gigabit para aumentar a capacidade de centros de dados . 29
1.7.2 Deadline-Driven Delivery control protocol (D
3
) . . . . . . . . . . . . 31
1.7.3 Centros de dados preditivos . . . . . . . . . . . . . . . . . . . . . . 33
1.7.4 Orchestra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
1.7.5 NetLord . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
1.7.6 Eliminao de trfego redundante . . . . . . . . . . . . . . . . . . . 38
1.7.7 Roteamento por mltiplos caminhos . . . . . . . . . . . . . . . . . . 39
1.7.8 Interconexo do centro de dados com pontes . . . . . . . . . . . . . . 42
1.7.9 Transparent Interconnection of Lots of Links (TRILL) . . . . . . . . . 44
1.7.10 Distributed Overlay Virtual Ethernet (DOVE) . . . . . . . . . . . . . 45
1.7.11 OpenFlow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
1.8 Solues para a Migrao entre Diferentes Centros de Dados . . . . . . . 49
1.8.1 NetStitcher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
1.8.2 Descarregamento de trfego . . . . . . . . . . . . . . . . . . . . . . 52
1.9 Concluso e Perspectivas Futuras . . . . . . . . . . . . . . . . . . . . . . 52
2 SEGURANA DE REDES VIRTUAIS: FUNDAMENTOS, TEC-
NOLOGIAS E TENDNCIAS 59
2.1 Introduo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
2.2 Busca Literria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
2.3 Virtualizao de Redes . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
2.3.1 Abordagens Baseadas em Protocolos . . . . . . . . . . . . . . . . . 63
2.3.2 Abordagens Baseadas em Virtualizao de Mquinas . . . . . . . . . . 64
2.3.3 Redes Programveis . . . . . . . . . . . . . . . . . . . . . . . . . 65
2.4 Taxonomia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
2.4.1 Ameaas de Segurana . . . . . . . . . . . . . . . . . . . . . . . . 65
XXX Simpsio Brasileiro de Redes de Computadores e Sistemas Distribudos - SBRC 2012 xiii
2.4.2 Servios de Segurana . . . . . . . . . . . . . . . . . . . . . . . . 67
2.5 Ameaas de Segurana . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
2.5.1 Divulgao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
2.5.2 Fraude . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
2.5.3 Disrupo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
2.5.4 Usurpao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
2.6 Servios de Segurana . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
2.6.1 Controle de Acesso . . . . . . . . . . . . . . . . . . . . . . . . . . 73
2.6.2 Autenticao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
2.6.3 Condencialidade . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
2.6.4 Integridade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
2.6.5 No-repdio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
2.6.6 Disponibilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
2.7 Anlise do Estado da Arte e Tendncias . . . . . . . . . . . . . . . . . . 88
2.7.1 Anlise do Estado da Arte . . . . . . . . . . . . . . . . . . . . . . . 88
2.7.2 Projetos e Tendncias . . . . . . . . . . . . . . . . . . . . . . . . . 89
2.8 Concluso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
3 ESTADO DA ARTE DE SISTEMAS DE CONTROLE E MONITO-
RAMENTO DE INFRAESTRUTURAS PARA EXPERIMENTAO
DE REDES DE COMUNICAO 101
3.1 Introduo a Infraestruturas para Experimentao em Internet do Futuro . 102
3.2 Requisitos Gerais das Infraestruturas do Ponto de Vista do Experimentador 103
3.2.1 Planejamento de Experimentos . . . . . . . . . . . . . . . . . . . . 103
3.2.2 Implantao dos Experimentos . . . . . . . . . . . . . . . . . . . . 105
3.2.3 Execuo dos Experimentos . . . . . . . . . . . . . . . . . . . . . . 106
3.3 Descrio das Principais Funcionalidades da Parte de Controle dos CMFs 107
3.3.1 Requisitos de Controle de Acesso e Credenciais . . . . . . . . . . . . 108
3.3.2 Requisitos de Agregados e Componentes . . . . . . . . . . . . . . . 109
3.3.3 Requisitos de Fatias . . . . . . . . . . . . . . . . . . . . . . . . . . 109
3.4 Monitoramento dos CMFs Requisitos e Funcionalidades . . . . . . . . 109
3.4.1 Requisitos de Monitorao . . . . . . . . . . . . . . . . . . . . . . 110
3.4.2 Grupos de Usurios e Casos de Uso . . . . . . . . . . . . . . . . . . 110
3.4.3 Servios de Instrumentao e Monitorao (I&M) para o GENI . . . . 114
3.4.4 Cenrios de Uso dos Servios . . . . . . . . . . . . . . . . . . . . . 114
3.4.5 Tipos de Servios . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
3.4.6 Ferramentas de I&M Relacionadas . . . . . . . . . . . . . . . . . . 115
3.5 Exemplos de Testbeds e respectivos CMFs . . . . . . . . . . . . . . . . . 117
3.5.1 Planetlab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
3.5.2 ProtoGENI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
3.5.3 PrimoGENI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
3.5.4 ORCABEN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
3.5.5 OFELIA-CF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
3.5.6 OMF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
3.5.7 Panlab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
xiv Minicursos Livro Texto
3.6 Federao de Testbeds: Criando Valor para Experimentadores (SFA 1.0 e
2.0) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
3.6.1 Introduo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
3.6.2 SFA 1.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
3.6.3 SFA 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
3.7 Estudo de Caso de Implantao do CMF OFELIA em uma Testbed Open-
Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
3.7.1 Requisitos e infraestrutura . . . . . . . . . . . . . . . . . . . . . . . 138
3.7.2 Instalando e Congurando o OFELIA CF . . . . . . . . . . . . . . . 138
3.7.3 Congurando e administrando o OFELIA CF . . . . . . . . . . . . . 143
3.7.4 Executando um experimento no OFELIA CF . . . . . . . . . . . . . 145
3.8 Estudo de Caso de Implantao de OMF em uma Testbed Sem Fio . . . . 147
3.8.1 Requisitos e infraestrutura . . . . . . . . . . . . . . . . . . . . . . . 147
3.8.2 Congurao da Rede . . . . . . . . . . . . . . . . . . . . . . . . . 148
3.8.3 Servios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
3.8.4 Testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
3.9 Concluses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
4 REDES DEFINIDAS POR SOFTWARE: UMA ABORDAGEM SIS-
TMICA PARA O DESENVOLVIMENTO DE PESQUISAS EM RE-
DES DE COMPUTADORES 161
4.1 Introduo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
4.1.1 Origens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
4.1.2 Motivao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
4.1.3 Organizao do texto . . . . . . . . . . . . . . . . . . . . . . . . . 165
4.2 Componentes de um sistema baseado em SDNs . . . . . . . . . . . . . . 166
4.2.1 Elementos de comutao programveis . . . . . . . . . . . . . . . . 166
4.2.2 Divisores de recursos/vises . . . . . . . . . . . . . . . . . . . . . . 167
4.2.3 Controlador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
4.2.4 Aplicaes de rede . . . . . . . . . . . . . . . . . . . . . . . . . . 168
4.3 Programao dos elementos de rede . . . . . . . . . . . . . . . . . . . . 168
4.3.1 O padro OpenFlow . . . . . . . . . . . . . . . . . . . . . . . . . 169
4.3.2 Implementaes em software . . . . . . . . . . . . . . . . . . . . . 171
4.3.3 Outras propostas . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
4.4 Particionamento de recursos (virtualizao) . . . . . . . . . . . . . . . . 173
4.5 Controladores de rede . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
4.5.1 NOX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
4.5.2 Trema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
4.5.3 Maestro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
4.5.4 Beacon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
4.5.5 FML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
4.5.6 Frenetic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
4.5.7 Onix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
4.5.8 Click . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
4.5.9 Floodlight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
4.5.10 SNAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
XXX Simpsio Brasileiro de Redes de Computadores e Sistemas Distribudos - SBRC 2012 xv
4.5.11 NEC Programmable Flow . . . . . . . . . . . . . . . . . . . . . . . 182
4.5.12 Mininet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
4.6 Aplicaes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
4.6.1 Contextos de aplicao . . . . . . . . . . . . . . . . . . . . . . . . 183
4.6.2 Alguns projetos de pesquisa . . . . . . . . . . . . . . . . . . . . . . 187
4.7 Desenvolvimento de sistemas utilizando POX . . . . . . . . . . . . . . . 190
4.7.1 Instalao e execuo . . . . . . . . . . . . . . . . . . . . . . . . . 190
4.7.2 Modelo de threads . . . . . . . . . . . . . . . . . . . . . . . . . . 193
4.7.3 Organizao do cdigo . . . . . . . . . . . . . . . . . . . . . . . . 194
4.7.4 Componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
4.7.5 Mdulos de funcionamento . . . . . . . . . . . . . . . . . . . . . . 195
4.7.6 Exemplo de programao de um componente POX . . . . . . . . . . . 197
4.7.7 Criao de um componente mnimo . . . . . . . . . . . . . . . . . . 197
4.7.8 Um componente mais realista: Switch L2 . . . . . . . . . . . . . . . 198
4.7.9 Exemplo de levantamento de evento: componente de topologia . . . . . 200
4.7.10 Utilizao do componente de log . . . . . . . . . . . . . . . . . . . 201
4.7.11 Testando seu componente com o Mininet . . . . . . . . . . . . . . . 202
4.8 Desaos de pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
4.9 Consideraes nais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
5 REDES ORIENTADAS A CONTEDO: UM NOVO PARADIGMA
PARA A INTERNET 213
5.1 Introduo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
5.2 A Distribuio de Contedo na Internet . . . . . . . . . . . . . . . . . . 215
5.2.1 A Arquitetura Centrada em Sistemas Finais e suas Limitaes . . . . . 216
5.2.2 Comunicao Multidestinatria . . . . . . . . . . . . . . . . . . . . 217
5.2.3 Redes Par-a-Par . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
5.2.4 Redes de Distribuio de Contedo . . . . . . . . . . . . . . . . . . 218
5.2.5 Sistemas Publish/Subscribe . . . . . . . . . . . . . . . . . . . . . . 220
5.3 Redes Orientadas a Contedo . . . . . . . . . . . . . . . . . . . . . . . . 222
5.3.1 Nomeao de Contedos . . . . . . . . . . . . . . . . . . . . . . . 222
5.3.2 Roteamento de Contedos . . . . . . . . . . . . . . . . . . . . . . . 225
5.3.3 Armazenamento de Contedos (Caching) . . . . . . . . . . . . . . . 228
5.3.4 Arquiteturas e Projetos em Desenvolvimento . . . . . . . . . . . . . . 229
5.4 Desaos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
5.4.1 Nomeao de Contedos . . . . . . . . . . . . . . . . . . . . . . . 239
5.4.2 Roteamento de Contedos . . . . . . . . . . . . . . . . . . . . . . . 242
5.4.3 Armazenamento na Rede (caching) . . . . . . . . . . . . . . . . . . 246
5.4.4 Segurana . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
5.4.5 Aspectos Prticos . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
5.5 Consideraes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
Captulo
1
Grandes Massas de Dados na Nuvem:
Desaos e T ecnicas para Inovac ao
Lus Henrique M. K. Costa
1
, Marcelo D. de Amorim
2
,
Miguel Elias M. Campista
1
, Marcelo G. Rubinstein
3
,
Patricia Florissi
4
e Otto Carlos M. B. Duarte
1
1
GTA/PEE-COPPE/DEL-Poli - Universidade Federal do Rio de Janeiro - RJ, Brasil
2
LIP6/CNRS - Universit e Pierre et Marie Curie - Paris, Franca
3
PEL/DETEL/FEN - Universidade do Estado do Rio de Janeiro - RJ, Brasil
4
EMC Nova Iorque, Estados Unidos
Resumo
A era das grandes massas de dados j a iniciou. Usu arios s ao agora fontes de dados; em-
presas armazenam incont aveis informac oes de clientes; milh oes de sensores monitoram
o mundo real, criando e trocando dados na Internet das coisas. As arquiteturas em nu-
vem obrigam indivduos e organizac oes a lidarem com um verdadeiro dil uvio de dados
que exp oem as limitac oes das soluc oes tradicionais de armazenamento, gerenciamento,
an alise e transfer encia. Este minicurso foca o impacto das grandes massas de dados nas
redes de computadores em centros de dados e na Internet. S ao identicadas as raz oes das
transfer encias das grandes massas de dados serem um desao e quais as deci encias das
atuais tecnologias empregadas. S ao apresentadas as principais propostas e iniciativas
da area.
Abstract
We are living today the dawn of big data era. Users have become data sources; com-
panies store uncountable information from clients; millions of sensors monitor the real
world; create and exchange data in the Internet of things. Cloud architectures enable
individuals and organizations to cope with a true deluge of data, which expose the limits
of traditional solutions for storage, management, analysis, and transference. This short
Este trabalho utilizou recursos da CAPES, CNPq, FAPERJ, FUJB, FUNTTEL, FINEP e CNRS.
2 Minicursos Livro Texto
course focuses on the impact of big data on computer networks in datacenters and also
on the Internet. We identify the reasons why big data is an issue and what the weaknesses
of the legacy Internet are and we visit the main proposals and initiatives in this area.
1.1. Introduc ao
A quantidade de dados produzidos e armazenados no mundo tem aumentado de ma-
neira vertiginosa e j a n ao se mede mais em giga ou terabytes, mas em peta, exa e at e
zetabytes
1
. Um recente estudo da International Data Corporation (IDC) junto com a
EMC em junho de 2011 indica que a quantidade de dados na Internet j a ultrapassou
a marca de 2 zettabytes em 2010 e a previs ao e que esse valor chegue a 8 zettabytes
em 2015 [Gantz e Reinsel, 2010, Gantz e Reinsel, 2011]. Esse n umeros representam um
aumento de mais de 300% em apenas cinco anos (Figura 1.1). Como consequ encia,
estima-se que soluc oes existentes envolvendo manipulac ao de dados como armazena-
mento, visualizac ao e transmiss ao n ao tenham propriedades sucientemente resistentes
para suportar t ao fortes requisitos de escalabilidade.
V arias s ao as raz oes que justicam tal crescimento na quantidade de dados mani-
pulados no mundo. Usu arios est ao permanentemente interconectados ` a Internet, criando
bilh oes de conex oes e se transformando em fontes de dados; empresas armazenam um
sem n umero de informac oes de seus clientes, de seus fornecedores e de suas operac oes co-
merciais; milh oes de sensores monitoram o mundo real; celulares, medidores eletr onicos
de energia, dispositivos port ateis, e autom oveis sensoriam, criam e trocam dados remo-
tamente na Internet das coisas. A inovac ao, a competic ao e a produtividade em todos os
setores da economia dependem agora da captura, da transfer encia, da agregac ao, da arma-
zenagem e da an alise de grandes massas de dados (big data). Os servidores do Facebook,
por exemplo, estocam aproximadamente 40 bilh oes de fotos dos seus usu arios, o que j a
signicaria petabytes de volume de dados armazenados assumindo-se fotos de apenas al-
gumas dezenas de kbytes [The Economist, 2010]. Experimentos de fsica de partculas
realizados no CERN (Centre Europ een de Recherche Nucl eaire) podem gerar at e 40 te-
rabytes de dados a cada segundo. Valores quase t ao grandes s ao tamb em encontrados
em aplicac oes comerciais, como no caso da rede Walmart, onde milhares de usu arios s ao
tratados a cada hora, gerando cerca de 2,5 petabytes de dados a serem inseridos nos cen-
tros de dados (datacenters) da empresa [The Economist, 2010]. V arios outros exemplos
podem ser citados.
Uma observac ao importante e com relac ao ` a velocidade na qual os dados po-
dem ser processados, em oposic ao ` a velocidade de gerac ao de dados. Por exemplo, a
decodicac ao do genoma humano exigiu cerca de dez anos de c alculos antes dos pri-
meiros resultados divulgados em 2003; a mesma operac ao exige aproximadamente uma
semana com as possibilidades atuais. Os dados gerados, por outro lado, ainda ultrapassam
signicativamente as capacidades de armazenamento das estruturas de base envolvidas no
procedimento. Desta forma, se torna imprescindvel a concepc ao de novos procedimentos
para o tratamento desses dados. Inclusive, n ao e descartada a possibilidade de que novas
1
Zetta (smbolo Z), peta (smbolo P) e exa (smbolo E) s ao prexos que denotam os fatores 10
21
, 10
18
e
10
15
, respectivamente. Esses prexos v em do Latim e signicam sete (1000
7
), seis (1000
6
) e cinco (1000
5
),
respectivamente.
XXX Simp osio Brasileiro de Redes de Computadores e Sistemas Distribudos - SBRC 2012 3
observac oes sejam feitas com relac ao aos mesmos dados, procedimentos anteriormente
considerados invi aveis por causa de limitac oes na infraestrutura.
Uma das principais caractersticas dos sistemas que lidam diretamente com gran-
des massas de dados e o fato de se basearem sobre arquiteturas do tipo nuvem compu-
tacional (cloud computing). Atributos das arquiteturas em nuvem como escalabilidade,
baixo custo, agilidade e elasticidade permitem de fato n ao somente a criac ao de enormes
massas de dados como o tratamento desses dados. Um ciclo e formado, pois quanto mais
dados s ao introduzidos na nuvem, novos desaos surgem e soluc oes inovadoras s ao ne-
cess arias. Cada vez mais grandes massas de dados (big data) e nuvem computacional
(cloud) se associam atr as de um mesmo conceito. Alguns analistas prev eem que por volta
de 2020 a maior parte dos dados digitais no mundo ser ao manuseados, monitorados e/ou
armazenados em nuvens se n ao durante todo o ciclo de vida, pelo menos em parte.
A implementac ao de nuvens e intimamente relacionada ` a noc ao de centros de
dados, que podem ser denidos como aglomerac oes de computadores interconectados
que prov eem, de maneira eciente, hospedagem e manipulac ao de dados. Aplicac oes de
enorme sucesso da Internet (como o Yahoo, Amazon e Facebook) utilizam centros de
dados distribudos onde dados s ao replicados de forma a diminuir o tempo de resposta
e melhorar a satisfac ao do usu ario. Esse cen ario ser a ainda mais importante em um fu-
turo pr oximo, visto que as principais empresas consumidoras de recursos j a anunciaram
seus planos de expans ao para seus centros de dados. A Figura 1.2 ilustra a previs ao do
crescimento dos dados armazenados para os pr oximos anos.
Al em da preocupac ao com os servicos de armazenamento e de manipulac ao de
dados, outro desao de grande import ancia e relativo ` a transmiss ao das informac oes en-
tre pontos distantes na Internet. O desempenho dos protocolos de comunicac ao con-
vencionais nem sempre e satisfat orio para muitas aplicac oes tpicas de centros de da-
dos (por exemplo, a computac ao paralela). Adicionalmente, a manipulac ao de massas
de dados envolve um custo energ etico e nanceiro crescente. Onde armazenar, quando
transmitir, como movimentar os dados, tornam-se quest oes primordiais tanto do ponto
de vista ecol ogico quanto econ omico. Novos protocolos de comunicac ao e t ecnicas de
virtualizac ao [Fernandes et al., 2011] s ao pecas-chave para o suporte de grandes massas
de dados na Internet, al em de novas estrat egias nas areas de economia de energia, bancos
de dados, minerac ao de dados, computac ao paralela e visualizac ao de dados.
Um recente estudo levando em conta 106 operadores de centros de dados revelou
que 77% deles replicam seus dados em tr es ou mais c opias [Forrester Research, 2010].
Al em disso, mais de 50% deles anunciaram que a quantidade de dados armazenadas
nos seus centros de dados ultrapassa a marca de um petabyte e que a banda passante
necess aria para interconectar esses centros de dados de maneira satisfat oria dobrar a ou
triplicar a nos pr oximos quatro anos [Forrester Research, 2010]. De uma maneira mais
geral, sabendo-se que o tr afego IP dever a alcancar mais de um zetabyte antes do m de
2015 [Cisco, 2011], soluc oes ecientes para a transfer encia de grandes quantidades de
dados em modo bulk ser ao mais do que necess arias.
Neste minicurso, s ao estudadas as principais aplicac oes que geramgrandes massas
de dados, e quais as implicac oes dessas massas.

E dado foco ao problema da migrac ao
dos dados j a que envolvem redes de comunicac ao. Em especial, s ao apresentados de-
2005 2010 2015
0
2000
4000
6000
8000
A
r
m
a
z
e
n
a
m
e
n
t
o
(
e
m
e
x
a
b
y
t
e
s
)
Fonte: IDCs Digital Universe Study, patrocinado pela EMC, Junho de 2011
Figura 1.1. Aumento dos dados armazenados estimados pela IDC [Gantz e Reinsel, 2011].
Microsoft
Dublin, Irlanda
$500 milhoes
19 acres
Google
Dublin, Irlanda
$101 milhoes
11 acres
Microsoft
Virginia, EUA
$150 milhoes
Microsoft
Iowa, EUA
$200 milhoes
Google
Oklahoma, EUA
$600 milhoes
130,000 pes
2
IBM
Langfang, China
620,000 pes
2
Facebook
NC, EUA
$450 milhoes
300,000 pes
2
Google
Singapura
Google
Hong
Kong
Google
Taiwan
Fonte: OnlineTech, Outubro de 2011
Figura 1.2. Planos de expans ao de centros de dados em 2012 [(Online Tech), 2011].
saos de interconex ao de milhares de computadores em centros de dados e desaos de
interconex ao de centros de dados, que demonstram as diferencas do ambiente interno a
um centro de dados (intra datacenter) com a Internet e os desaos de se migrar massas
de dados entre centros de dados (inter datacenters). Em cada um desses ambientes, di-
ferentes tecnologias podem ser utilizadas para aumentar o desempenho como o uso da
virtualizac ao de redes combinada a novas tecnologias de denic ao de redes por software
(Software Dened Networking SDN) [Lantz et al., 2010]. Todas essas quest oes justi-
cam a import ancia que vem sendo dada a essa area de pesquisa no meio industrial e
acad emico.
1.2. Grandes Massas de Dados
Inicialmente, esta sec ao busca denir o qu ao grande devem ser os dados para serem de-
nominados grandes massas de dados (big data) e quais s ao as suas fontes de gerac ao.
A melhor denic ao para grandes massas de dados n ao indica, intencionalmente, um ta-
manho exato.

E prefervel a denic ao relativa como um volume de dados que excede
a capacidade de gerenciamento das ferramentas usadas para lidar com tamanhos tpicos
de uma determinada aplicac ao ou area. Essa denic ao e mais adequada porque as tec-
nologias utilizadas para gerenciar as grandes massas de dados evoluem e o valor limite
aumenta ano a ano. Al em disso, a denic ao pode depender dos softwares frequente-
mente utilizados e dos tamanhos tpicos dos dados usados em uma determinada area de
produc ao. Portanto, vislumbra-se que tal denic ao exata n ao possa ser concluda de ma-
neira denitiva em curto-prazo e que ela n ao surja enquanto a escalabilidade n ao for uma
caracterstica permanente da maioria dos sistemas computacionais.
Como mencionado, a denic ao do que seriam as grandes massas de dados de-
pende do setor de produc ao relacionado. Nesse sentido, nota-se que as fontes de dados
s ao in umeras e est ao ligadas aos diferentes segmentos da sociedade. Um dos principais
motores do aumento da quantidade de dados e a digitalizac ao dos sistemas que impul-
siona ainda mais a gerac ao dessas massas. Com a crescente quantidade de dados gerados,
manipulados, transferidos e armazenados, novos problemas surgem envolvendo muitas
areas interdisciplinares como banco de dados, minerac ao de dados, arquitetura de compu-
tadores, sistemas digitais, provis ao de energia e tecnologias de baixo consumo energ etico
(tecnologias verdes), recuperac ao da informac ao e redes de computadores.
1.2.1. Aplicac oes e valores tpicos de grandes massas de dados
O tamanho das massas de dados para que sejam consideradas realmente grandes n ao e
facilmente denido. Apesar de sua complexidade, o termo vem sendo utilizado mesmo
que leve a ambiguidades. Um conceito equivocado, entretanto, e que as grandes massas
de dados referem-se somente ao tamanho absoluto desses dados. Apesar de o tamanho ser
certamente um elemento a ser considerado na denic ao, h a outros aspectos ou proprieda-
des das grandes massas de dados, n ao diretamente associados ao tamanho, que devem ser
tamb em levados em considerac ao. A velocidade na qual as grandes massas de dados s ao
geradas, assim como o n umero e a variedade de fontes que geram dados simultaneamente
devem ser considerados. Observando em detalhes cada uma das fontes, verica-se como
a classicac ao e dependente do prop osito dos dados e do setor de produc ao no qual eles
est ao inseridos. Dessa forma, uma apresentac ao de 40 megabytes, uma imagem m edica
de 1 terabyte ou um lme de 1 petabyte podem ser igualmente considerados grandes mas-
sas de dados mesmo tendo tamanhos t ao diferentes. Para isso, basta vericar que cada um
desses arquivos extrapola os limites disponveis das tecnologias comumente utilizadas por
cada uma deles. Os argumentos abaixo reforcam esse conceito:
uma apresentac ao de 40 megabytes representa uma grande massa de dados se n ao
for possvel envi a-la por correio eletr onico a um colega ou cliente;
uma imagem m edica de 1 terabyte representa uma grande massa de dados se n ao
for possvel exibi-la de forma simples e acurada em uma tela remota em tempo real
durante uma consulta m edica com um paciente;
um lme de 1 petabyte representa uma grande massa de dados se n ao for possvel
edit a-lo dentro dos limites plausveis de tempo estabelecidos pelo neg ocio corrente.
Logo, conclui-se que o tamanho n ao e a unica propriedade que deve ser considerada ao
classicar o qu ao grande s ao as massas de dados. Uma denic ao mais abrangente para
classicar as grandes massas de dados deve considerar tamb em se os limites m aximos
disponveis para o uso desses dados foram alcancados ou n ao.
Os argumentos apresentados t em como objetivo negar o conceito comum no qual
se dene as grandes massas de dados tendo somente o tamanho como base. Tal denic ao
deve englobar outros atributos que atingem os limites da capacidade do sistema utilizado.
Outros atributos que aumentam a abrang encia da denic ao s ao a velocidade na qual os
dados s ao gerados e o n umero e a variedade de fontes geradoras. Ambos contribuem
para uma denic ao mais ampla do que seriam as grandes massas de dados. Tal denic ao
e, ent ao, baseada em volume, j a que e possvel imaginar que as massas de dados s ao
geradas a partir do produto entre n umero de fontes e quantidade de bytes. Mesmo quando
criado em pequenos fragmentos, o composto agregado pode se tornar uma grande massa
de dados correlacionados. Esse composto dene, ent ao, um grande volume de dados.
Por exemplo, tais volumes podem ser vistos no contexto de medidores inteligentes de
energia que s ao empregados em resid encias ao redor do mundo. Esses medidores podem
enviar ` as companhias el etricas a energia gerada e consumida em uma casa a cada 10 ou
15 minutos. O produto da quantidade de dados gerados individualmente pelo n umero de
resid encias em um vilarejo ou em uma pequena cidade gera um volume de dados enorme.
Tais dados devem ser analisados dentro de um dado intervalo de tempo ou dentro de uma
determinada fronteira geogr aca.
Outro aspecto a ser ressaltado das grandes massas de dados e que elas se dife-
renciam tamb em sob o ponto de vista estrutural. Algumas massas de dados t em o seu
formato bem denido, como requisic oes a um banco de dados, nas quais cada entrada
pode ser dividida em campos, cada um armazenando dados de um tipo pr e-estabelecido
e j a bem denido. Por outro lado, algumas grandes massas de dados podem ser somente
uma colec ao de entradas de blogs que contenham texto, tabelas, imagens, voz e vdeo
armazenados em um mesmo reposit orio de dados. As caractersticas desses dados le-
vam a outros aspectos das grandes massas de dados que s ao a diversidade de gerac ao e a
correlac ao entre os dados. Apesar do tamanho, velocidade ou fonte dos dados serem di-
ferentes, as grandes massas de dados impulsionam a necessidade de se extrair sentido do
aparente caos. Para tal, e necess ario encontrar signicado dos dados que est ao em cons-
tante evoluc ao, al em de encontrar as relac oes entre eles. A compreens ao dessa correlac ao
e da possibilidade de obter informac oes preciosas, muitas vezes escondidas nas grandes
massas de dados, ajuda a revelar o valor do esforco. Assim sendo, coletar, analisar e
compreender as grandes massas de dados (Sec ao 1.2.2) est a se tornando atualmente uma
estrat egia diferenciada e vislumbra-se que ela ainda se tornar a fundamental em um futuro
pr oximo. O local onde a an alise precisa ser executada, seja em um unico centro de dados
(datacenter) ou em um centro de dados distribudo geogracamente, sem perder a con-
cis ao, acur acia e relev ancia dos resultados e um dos desaos abordados neste minicurso.
geracao
analise
agregacao apagamento
Figura 1.3. Ciclo de vida dos dados e os seus respectivos est agios.
1.2.2. Ciclo de vida dos dados
Semelhantemente ao ciclo de vida biol ogico, os dados tamb em passam por est agios desde
a sua gerac ao at e o nal da sua utilidade. De maneira geral, um ciclo de vida pode ser
classicado em quatro est agios: nascimento, crescimento, reproduc ao e morte. Por ana-
logia, como ilustrado na Figura 1.3, pode-se pensar em um ciclo de vida similar para os
dados, no qual a gerac ao dos dados substitui o nascimento; a agregac ao dos dados substi-
tui o crescimento; a an alise dos dados substitui a reproduc ao; e, nalmente, o apagamento
dos dados substitui a morte. Percebe-se que durante o est agio de agregac ao, mais dados
com sem antica semelhante, ou mesmo dados que sejam de alguma forma correlaciona-
dos, s ao adicionados aos dados originais. Em ambos os casos, a agregac ao enriquece o
valor dos dados, ampliando a sua import ancia.
Durante o est agio de an alise, a combinac ao dos dados obtidos resulta em novos
dados com melhor e mais acurado signicado. Uma observac ao importante sobre os
dados, que tamb em poderia ser associada ` a vida biol ogica, e que durante o est agio de
crescimento, os dados podem ser migrados para outros locais. Portanto, os dados podem
ser movidos de um local para outro em busca de melhores condic oes de an alise. Uma
diferenca, nesse caso, entre os ciclos de vida dos dados e o biol ogico, e que o primeiro
pode ser tanto movido quanto replicado. J a no segundo caso, no ciclo de vida biol ogico,
n ao h a a possibilidade de replicac ao.
O primeiro est agio, a gerac ao dos dados, pode produzir arquivos com diferentes
tamanhos dependendo da aplicac ao geradora e do prop osito do dado. Enquanto aplicac oes
web tipicamente lidam com arquivos de tamanhos da ordem de kilo at e megabytes, ima-
gens 3D de alta denic ao podem atingir tamanhos de at e tera ou petabytes. Indepen-
dentemente dos seus tamanhos individuais, a quantidade agregada pode compor grandes
volumes de dados, que n ao podem nem ser salvos em sistemas de armazenamento co-
muns nem ser transferidos atrav es das redes de acesso atuais. Logo, em termos de escala,
o resultado nal e o mesmo que haveria se eles fossem uma unica massa de dados.
Outra quest ao importante e o tipo ou o formato que os dados s ao gerados. Eles
podem ter ou n ao uma correlac ao clara se eles seguirem uma estrutura pr e-denida.
Nesse sentido, os dados podem ser classicados em quatro tipos: estruturados, quasi-
estruturados, semi-estruturados e desestruturados. Entradas em bancos de dados relaci-
Figura 1.4. Tipos de dados caracterizados de acordo com as suas principais
caractersticas de gerac ao.
onais s ao ditos estruturados j a que seguem um formato xo; dados que incluem auto-
descric oes conforme um esquema pr evio s ao considerados quasi-estruturados, por exem-
plo, dados descritos em uma estrutura XML; dados com algumas inconsist encias em seus
valores ou formatos s ao considerados semi-estruturados; enquanto imagens, vdeos e tex-
tos s ao considerados desestruturados. O processo de extrac ao de valor dos dados pode ser
classicado em uma ordem crescente de complexidade, na qual os dados desestruturados
s ao os que oferecem maiores diculdades para a extrac ao de valor.
A partir do n umero de fontes, volume e estrutura pode-se visualizar tr es carac-
tersticas ortogonais. A Figura 1.4 mostra a posic ao no espaco de dados conhecidos
conforme suas caractersticas principais. Registros e dados sensoriais comp oem gran-
des volumes a partir da agregac ao de dados de diferentes fontes. Transac oes comerciais
s ao feitas cada vez mais e seguem tipicamente uma estrutura rgida para n ao gerarem da-
dos err oneos. Os backups comumente resultam em arquivos grandes, enquanto imagens
e vdeos podem variar entre pequenos e grandes arquivos.
O segundo est agio, a agregac ao dos dados, est a relacionado ao modo como os da-
dos com sem antica semelhante ou de alguma forma correlacion aveis s ao continuamente
coletados e armazenados. Em geral, esses dados devem ter um signicado claro para ter
utilidade e podem ser armazenados de forma centralizada ou distribuda. Encontrar tal
signicado, entretanto, n ao e sempre obvio. Dada a diversidade das fontes e a diferenca
entre as estruturas dos dados, a correlac ao entre eles e a extrac ao de valor e um desao
que vai al em do armazenamento das grandes massas. Nesse est agio, apesar dos clientes
reconhecerem as possveis informac oes escondidas, eles preferem perder os dados a enve-
redar em uma busca incessante por correlac ao e, posteriormente, valor. Ao fazer isso, os
clientes sabem que podem perder informac oes de interesse como problemas operacionais,
comportamento de usu arios e possibilidades de falhas de seguranca que poderiam levar
a ganhos substanciais de desempenho. Al em da correlac ao dos dados gerados, e ainda
desej avel agregar esses dados com os sistemas legados que est ao mais adaptados ao setor
de produc ao especco dos clientes.
Em seguida, h a o est agio da an alise dos dados que e crucial e com frequ encia re-
quer soluc oes especcas para os diferentes dados. Durante a an alise, e necess ario lidar
com duas direc oes opostas: o volume e a complexidade dos tipos emergentes de dados,
que vem continuamente aumentando; e o tempo de processamento necess ario para trans-
formar as grandes massas de dados eminformac ao util emtempo real. Emoutras palavras,
o desao durante a an alise e transformar as grandes massas de dados em informac ao util
em um tempo sucientemente pequeno para que os usu arios sejam capazes de reagir a
possveis mudancas dos seus setores de interesse. Entretanto, mesmo considerando da-
dos estruturados, frequentemente os usu arios n ao sabem nem como lidar com os dados e
nem o que pode ser extrado deles. Tipicamente, os usu arios est ao habituados com da-
dos que j a possuem caractersticas conhecidas e cujos valores a serem extrados assim
como a probabilidade desses valores serem encontrados j a s ao previamente conhecidos.
A obtenc ao de informac oes das grandes massas de dados e diferente e essa nova oportuni-
dade e desaadora. Dessa forma, novas ferramentas que revelem diferentes signicados
s ao necess arias. A total falta de percepc ao sobre a exibilidade deste novo ambiente,
que possivelmente poderia levar a direc oes de interesse, assim como a falta de conheci-
mento pr evio sobre essa nova area de grandes massas de dados s ao atualmente os grandes
obst aculos.
As grandes massas de dados s ao tamb em atualizadas em altas taxas de forma inte-
rativa e incremental. As mudancas constantes nos dados gerados os tornam mais acurados
e mais precisos ao longo do tempo. Al em disso, sobre os dados atuais, mais dados s ao
criados, calculados e inferidos. Os novos dados criados s ao derivados dos originais de-
pois de requisic oes, resumos ou infer encias estatsticas. Adicionalmente, an alises podem
ser tamb em efetuadas atrav es do uso de t ecnicas de visualizac ao, especialmente impor-
tantes em casos nos quais a representac ao espacial pode contribuir na compreens ao e
manipulac ao dos dados. Um problema que surge como consequ encia do aumento nunca
visto antes da quantidade de dados e foco de novas t ecnicas de visualizac ao.
Aexecuc ao de an alises emmaiores detalhes, mantendo resultados concisos, acura-
dos e relevantes em um dado contexto de interesse leva a ac oes mais precisas e, como con-
sequ encia, maiores ganhos nanceiros. Por exemplo, provedores de energia e olica anali-
sam dados clim aticos para auxiliar no posicionamento dos seus equipamentos em campo.
Essa possibilidade permite encontrar os pontos otimos em que os captadores de vento de-
vem ser instalados para que, por conseguinte, a produc ao de energia aumente. Empresas
do ramo de mdias digitais podemtamb emse interessar em an alises de conte udo de vdeos
para detectar pirataria ou exibic ao n ao autorizada de seus vdeos em p aginas de redes so-
ciais. Ainda, o setor comercial de uma empresa pode se interessar em melhorar a an alise
de correios eletr onicos para observar o relacionamento entre os usu arios e, assim, apoiar
atividades que eles possam desempenhar em suas corporac oes. Por m, seria de interesse
dos setores t ecnicos de empresas a an alise de registros dos seus sistemas em execuc ao
para que seja possvel a realizac ao de manutenc ao preventiva. Descobrir problemas nos
equipamentos antes mesmo que eles ocorram permite melhorar o servico prestado aos
clientes ao planejar com anteced encia as intervenc oes de manutenc ao.
A extrac ao de valor dos dados tamb em tem que lidar com o aspecto de tempo util.
Enquanto v alidas as grandes massas de dados podemse encaixar emdiferentes prop ositos.
Entretanto, depois de certo tempo, o valor contido desaparece e toda a informac ao desses
dados se torna in util ou totalmente absorvida por dados mais recentes. Durante o ciclo de
vida, os dados n ao s ao necessariamente armazenados em discos rgidos j a que eles podem
ser exibidos por mdias em difus ao. Entretanto, quando armazenados, o desao e saber
por quanto tempo. Essa quest ao surge como um compromisso entre a disponibilidade da
informac ao e a acessibilidade dela. Frequentemente, dados em potencial s ao deixados de
lado ou mesmo descartados devido ` a falta de infraestrutura para an alise e armazenamento.
Por um lado, apesar de frustrados, os clientes descartam os dados que eles sabem que s ao
fontes empotencial de informac ao representativa para n ao saturar a sua infraestrutura. Por
outro lado, identicar o exato momento para descartar os dados, ou seja, o nal do seu
ciclo de vida, e complexo e pode levar ao armazenamento in util de quantidades macicas
de dados.
Durante o ciclo de vida, uma importante quest ao a ser considerada e como e por
qual motivo os dados devem ser movidos. Consequentemente, onde armazen a-los deve
ser cuidadosamente escolhido. A movimentac ao incessante dos dados ou a replicac ao
deles entre pontos geogracamente distantes e um desao abordado neste minicurso.
Essa tarefa pode envolver muitas t ecnicas de otimizac ao, como a localizac ao do lugar
mais apropriado para o armazenamento dos dados, que pode ser atrav es de t ecnicas de
agregac ao em um unico centro de dados (datacenter) con avel ou atrav es da manutenc ao
distribuda desses dados na vizinhanca dos seus consumidores.

E de suma import ancia
que a soluc ao adotada faca o melhor uso dos recursos disponveis para evitar impactos
negativos sobre o sistema de comunicac oes, sobre o meio ambiente ou ainda sobre a qua-
lidade de servico oferecida aos clientes. Uma soluc ao trivial e manter os dados no mesmo
ambiente de armazenamento e distribu-los sob demanda considerando propriedades de
localizac ao. Entretanto, essa estrat egia nem sempre e possvel j a que as grandes massas
de dados s ao transferidas muitas vezes usando a Internet ou outras redes de comunicac ao
que possuem limitac oes. Logo, os dados s ao distribudos entre m ultiplos centros de dados
mesmo fora da infraestrutura do seu propriet ario. Esses centros de dados externos podem
ser acessveis atrav es da pr opria Internet e podem estar disponveis publicamente.
1.3. Arquiteturas em Aglomerac ao
Como mencionado na sec ao anterior, o est agio de an alise e de suma import ancia. Uma
soluc ao para agilizar e viabilizar a an alise das grandes massas de dados e a partir das
arquiteturas em aglomerac ao (cluster), que est ao se tornando cada vez mais utilizadas
com esse objetivo. As principais raz oes para isso s ao o alto desempenho que as arquitetu-
ras em aglomerac ao apresentam e as vantagens j a mencionadas obtidas do paradigma de
computac ao em nuvem tais como a escalabilidade, a agilidade e a elasticidade dos recur-
sos. Essas caractersticas s ao pr e-requisitos muito importantes para a an alise das grandes
massas de dados. Uma quest ao chave, entretanto, e como as arquiteturas em aglomerac ao
podem atingir todas essas caractersticas e como elas podem ser comparadas ` as arqui-
teturas tradicionais utilizadas nas empresas. Primeiramente, e crucial compreender as
diferencas fundamentais oriundas dos princpios entre as arquiteturas tradicionais usadas
nas empresas e a arquitetura em aglomerac ao. O projeto das arquiteturas tradicionais
e baseado na premissa da exist encia de tr es tipos principais de recursos de hardware a
serem gerenciados:
servidores de custo elevado contendo alto potencial de processamento e de armaze-
namento que n ao devem car ociosos em nenhum momento;
matrizes de armazenamento (storage arrays) contendo mdias com diferentes tipos
de desempenho, capacidade e custo por GB, variando desde mdias de estado s olido
(Solid State Drives - SSD) at e discos rgidos SATAs;
redes de armazenamento (Storage Area Networks - SAN) conectando conjuntos de
servidores aos conjuntos de matrizes de armazenamento.
Uma das principais peculiaridades das arquiteturas tradicionais e a separac ao en-
tre os servidores e as matrizes de armazenamento, que podem expandir, podem ser atu-
alizadas ou removidas do uso, independente umas das outras. A SAN, por outro lado,
permite que aplicac oes sendo executadas em qualquer servidor tenham acesso aos dados
armazenados em qualquer elemento da matriz, se tiverem credenciais que as atribuam
esse direito. Em uma congurac ao empresarial, todos os componentes da arquitetura s ao
construdos para serem robustos e com modos de operac ao com toler ancia a falhas para
assegurar disponibilidade, muito embora n ao se espere que os componentes falhem com
frequ encia. Caso isso ocorra, eles s ao substitudos rapidamente. Essas propriedades de
robustez e alta disponibilidade, entretanto, conduzem a um maior valor agregado e, por
conseguinte, maiores custos.
A arquitetura tradicional foi projetada para aplicac oes de computac ao intensiva
que tipicamente requerem muitos ciclos de processamento, mas apenas em um subcon-
junto dos dados da aplicac ao, que ent ao s ao transferidos atrav es da SAN dos locais de
armazenamento at e os servidores para o processamento. Da mesma forma, os resultados
s ao transferidos de volta dos servidores at e os locais de armazenamento. Por exemplo,
considere as estatsticas e as an alises realizadas no nal do dia sobre o consumo di ario de
um determinado produto em todo o Brasil de uma empresa como a Americanas.com. Da-
das as in umeras opc oes de produtos disponveis nas Americanas.com, esse determinado
produto em especial representa um pequeno subconjunto do total de dados disponvel.
Considere ainda que seja necess ario ordenar uma grande massa de dados, e que atrav es da
ordenac ao, os dados s ao organizados conforme um dado crit erio, como ordem alfab etica,
num erica ou outra relacionada com o tempo, como o caso ocorrido com a Google em
2008 [Dean e Ghemawat, 2008a]. Para se ordenar dados, o conjunto inteiro pode precisar
ser examinado e isso e uma operac ao computacional altamente intensiva, especialmente se
as massas de dados forem da ordem de petabytes todo o dia. Essa tarefa fundamental em
computac ao e realmente muito importante porque, uma vez que os dados sejam ordena-
dos, todas as operac oes sobre esses dados podem ser executadas em ordens de magnitude
mais r apidas, como a busca e a combinac ao dos dados. De fato, acredita-se que cerca de
25% de todos os ciclos de CPU sejam gastos atualmente com operac oes de ordenac ao.
Portanto, considerando a quantidade de dados gerados por mdias sociais e outras fontes
com alterac oes di arias e considerando que todos esses dados s ao provavelmente ordena-
dos antes de serem analisados, deve-se denitivamente compreender como as diferentes
arquiteturas s ao utilizadas hoje para essas tarefas intensivas. Isso e o que leva as arquite-
turas em aglomerac ao (cluster) a serem mais ecientes, mesmo sendo projetadas a partir
de alguns princpios b asicos como:
baixo custo com o uso de hardware de prateleira, no qual os n ucleos de processa-
mento e os discos rgidos est ao mais em conta com a comunicac ao em nuvem.
Uma comprovac ao do baixo custo e o PennySort, que e um benchmark usado
como m etrica para medir a quantidade de dados que podem ser ordenados em um
tempo de processamento equivalente ao que se compraria com um centavo de d olar
(penny). De acordo com a Sortbenchmark, em 2011, a Universidade de Padova na
It alia registrou o recorde do PennySort com 334 GB. Os precos de equipamentos de
prateleira permitiram tamb em que empresas desenvolvessem arquiteturas altamente
escal aveis. Considerando, por exemplo, que a Google possua milh oes de n ucleos
de processadores em todos os seus centros de dados, apesar desses componentes
falharem com frequ encia, componentes redundantes fazem com que essas falhas
sejam imperceptveis aos usu arios;
viabilizac ao de aplicac oes com uso intensivo de dados em larga escala, nos quais
a computac ao seja feita frequentemente sobre o conjunto inteiro de dados e n ao
somente sobre um subconjunto deles. Considere, por exemplo, os estudos sobre
o genoma humano que analisa milhares de indivduos em busca de diferencas ou
mutac oes que possam ser a causa de uma doenca em particular. Uma vez que o ge-
noma consiste de uma sequ encia de 3,2 bilh oes de caracteres, a comparac ao deles
requer o uso intensivo de grandes dados. Outra m etrica poderia ser o MinuteSort,
que e umbenchmark usado para medir a quantidade de dados que pode ser ordenado
em exatamente 60 segundos. De acordo com o Sortbenchmark, em 2011, a Univer-
sidade da Calif ornia, em S ao Diego, estabeleceu um novo recorde do MinuteSort
com 1.353 GB;
atendimento dos requisitos das grandes massas de dados que requerem uma alta
vaz ao de leitura e cujo volume pode facilmente tornar a SAN um gargalo. Para
avaliar esse requisito, a m etrica GraySort pode ser usada. O GraySort mede a taxa
de ordenac ao, em termos de terabytes por minuto, que pode ser atingida durante
a ordenac ao de uma grande quantidade de dados. Novamente, de acordo com o
Sortbenchmark, em 2011, a Universidade da Calif ornia, em S ao Diego, estabeleceu
o novo recorde do GraySort com 0,938 TB/min, ou seja, quase 1 TB/min.
O conhecimento dos requisitos para an alise das grandes massas de dados permite
compreender o projeto da arquitetura. Uma arquitetura em aglomerac oes (clusters) e ba-
seada em um conjunto b asico de componentes que podem estar disponveis aos milhares
ou centenas de milhares e que podem ser facilmente montados em conjunto. Tudo e
iniciado a partir de um n o, que consiste de um conjunto de n ucleos de processamento
e mem orias principais de equipamentos de prateleira anexadas a um conjunto de dis-
cos rgidos tamb em de prateleira; uma pilha de n os formam um bastidor (rack); e um
grupo de bastidores formam um aglomerado (cluster). Todos os componentes s ao co-
nectados atrav es de uma rede de alta velocidade para troca r apida de informac oes. A
Figura 1.5 ilustra a arquitetura em aglomerac ao, assim como os seus principais compo-
nentes.

E importante destacar alguns princpios fundamentais e benefcios da arquitetura
em aglomerac ao. Primeiro, a arquitetura e altamente modular e escal avel. A capacidade
de execuc ao de suas tarefas se mant em crescente se novos n os e bastidores forem adicio-
nados. Segundo, as arquiteturas em aglomerac ao usam o conceito de localidade de dados,
no qual os dados podem ser processados pelos n ucleos computacionais localizados no
Figura 1.5. Arquitetura em aglomerac ao e seus principais componentes: n o,
bastidor e interconex ao em alta velocidade.
mesmo n o ou pelo menos no mesmo bastidor, onde est ao os discos com os dados, elimi-
nando ou minimizando qualquer transfer encia de dados pela rede. Como consequ encia, a
rede n ao deve se constituir em um potencial gargalo.
Adicionalmente, a arquitetura induz ` a paralelizac ao das atividades, tornando-se ideal para
o Processamento Paralelo Macico (Massive Parallel Processing - MPP). Portanto, retor-
nando ` a quest ao da ordenac ao dos dados, cada n o em um aglomerado pode ordenar o
fragmento da grande massa de dados que esteja localizado no mesmo n o. Isso leva ` a
transfer encia de dados somente de um disco local para a mem oria principal. De acordo
com a Universidade da Calif ornia em S ao Diego, o recorde do MinuteSort foi alcancado
com um cluster consistindo de 52 n os, cada um com dois processadores quad-core, 24
gigabytes (GB) de mem oria e discos de 16.500 GB, todos interconectados por um comu-
tador Cisco Nexus 5020. Por m, a paralelizac ao das leituras dos discos atrav es dos n os
pode aumentar o n umero de operac oes de entrada e sada por segundo (Input/Output Ope-
rations Per Second - IOPS) mesmo mantendo os mesmos custos com unidades de discos
rgidos.
Um exemplo simples comparativo entre o custo de armazenamento por IOPS entre
as arquiteturas tradicionais das empresas e da arquitetura em aglomerac ao permite enten-
der como esta ultima pode ser economicamente mais interessante. Nos c alculos apresenta-
dos, s ao usados dados publicados em um relat orio do Cr edit Suisse [Winslow et al., 2011]
em marco de 2011.

E importante observar que, nos c alculos, a proporc ao relativa entre os
n umeros e mais importante que os seus valores absolutos, j a que os valores continuam a
diminuir. Em uma arquitetura empresarial tradicional, as unidades de discos rgidos em
uma matriz de armazenamento variam em desempenho, capacidade, e custo por GB. As
unidades de discos de estado s olido (Solid State Drive - SSD), de acordo com o relat orio,
s ao capazes de executar 5.000 operac oes de escrita por segundo e 30.000 operac oes de
leitura por segundo com um custo por GB na faixa de 1,20 d olares. O SATA, por outro
lado, e capaz de executar apenas 250 IOPS, mas a um custo por GB na faixa de 0,04
d olares. Supondo um aglomerado com 120 n os, cada um capaz de realizar 250 IOPS, j a
que 120250 = 30.000, os 120 n os lendo dados em paralelo alcancam 30.000 IOPS, que
e o mesmo desempenho do SSD, mas a um custo por GB igual ao SATA. Portanto, o em-
prego da arquitetura em aglomerac ao se torna nanceiramente muito interessante. O com-
promisso, entretanto, e que essa arquitetura e baseada em hardware de prateleira e possui
componentes que podem falhar com frequ encia. Portanto, o software de gerenciamento
da arquitetura e as aplicac oes executadas nessa arquitetura devem detectar e responder
a falhas de forma automatizada e eciente. Isso traz um grande nvel de complexidade
j a que e necess ario considerar o compromisso. Para evitar perda de dados, tipicamente,
os dados s ao replicados em muitos n os, o que eleva a uma dada quantidade de recursos
de armazenamento necess aria para guardar os dados em um aglomerado. Se forem ne-
cess arias tr es r eplicas de 1 petabyte de dados, por exemplo, s ao necess arios 4 petabytes de
armazenamento. Finalmente, para atingir o m aximo proveito em termos de desempenho e
relac ao custo-benefcio, os dados precisam ser igualmente distribudos atrav es dos n os do
aglomerado. Logo, a aplicac ao precisa ser projetada tendo como meta o processamento
paralelo macico (MPP) de dados e o gerenciamento empregado precisa ser cuidadoso na
troca de resultados, nais ou intermedi arios, entre os n os do aglomerado. Por isso, os
princpios do Hadoop s ao apresentados na pr oxima sec ao para que seja possvel compre-
ender como e possvel utilizar as arquiteturas em aglomerac ao de forma eciente.
1.4. Modelos de Programac ao para Arquiteturas em Aglomerac ao
Para se utilizar a arquitetura em aglomerac ao e necess ario uma infraestrutura de software
de sistema distribudo. Essa infraestutura pode ser vista como o sistema operacional da
arquitetura em aglomerac ao usada em centros de dados. A infratestrutura e composta
por sistemas de arquivos distribudos, escalonadores, chamadas a procedimentos remo-
tos e modelos de programac ao para simplicar o uso dos recursos na escala dos centros
de dados, tais como: Hadoop [Apache, 2012], MapReduce [Dean e Ghemawat, 2008b],
Dryad [Isard et al., 2007], Dynamo [DeCandia et al., 2007] etc. Esta sec ao descreve o Ha-
doop que foi desenvolvido para um ambiente tpico de provedores de servico de nuvens
e que, al em disso, ele foi projetado para uma arquitetura em aglomerac ao construda a
partir de hardware de prateleira. Portanto, uma aglomerac ao e composta de componentes
simples, disponveis aos milhares e que podem ser combinados. Os n os s ao compostos
de tais componentes, uma pilha de n os forma um bastidor (rack) e um grupo de bas-
tidores forma um aglomerado (cluster). Todos conectados atrav es de uma rede de alta
velocidade para troca r apida de informac oes. Assim, o Hadoop e um software de c odigo
aberto para computac ao distribuda de modo con avel e escal avel. O Hadoop permite
o processamento distribudo de grandes conjuntos de dados atrav es de um aglomerado
de computadores usando um modelo simples de programac ao. O Hodoop e projetado
com o objetivo de escalar de um unico servidor at e milhares de m aquinas, cada uma com
processamento e mem oria local. A alta disponibilidade do sistema e obtida por software
projetado para detectar e tratar falhas, evitando assim maiores custos de hardware.
O Hadoop foi desenvolvido para aproveitar os recursos e a estrutura disponvel
em uma arquitetura em aglomerac ao. O objetivo e possibilitar que as aplicac oes utilizem
todo o potencial de um aglomerado ao levar em considerac ao dois pontos chave: (i) a
distribuic ao dos dados pelo aglomerado, assegurando que os dados estejam distribudo
igualmente e (ii) o desenvolvimento de aplicac oes que se beneciem da localizac ao dos
dados. Esses dois pontos fundamentais levam o projeto do Hadoop a empregar dois me-
canismos:
o Sistema de Arquivos Distribudo (Hadoop Distributed File System - HDFS) que
e um sistema de arquivos para dividir, espalhar, replicar e gerenciar dados ao longo
dos n os em um aglomerado;
o MapReduce que e um mecanismo computacional para executar aplicac oes em
paralelo. As aplicac oes s ao executadas atrav es da divis ao emtarefas que manipulam
apenas uma parcela dos dados, coletando e redistribuindo resultados intermedi arios
e gerenciando falhas atrav es de todos os n os do aglomerado.
Inicialmente, o sistema de arquivos distribudo do Hadoop e abordado para, em
seguida, ser apresentado o MapReduce. O sistema de arquivos distribudo do Hadoop se
baseia em conceitos simples e princpios de uniformidade em seu projeto. Um arquivo
consiste de blocos com tamanhos iguais e m ultiplos dos tamanhos dos blocos de arma-
zenamento. No Apache Hadoop Community Edition, por exemplo, os blocos de arquivo
s ao de 64 MB, enquanto os blocos de armazenamento s ao de 512 kB. O Hadoop usa o
bloco de arquivos como a unidade a ser empregada para distribuir partes de arquivo entre
os discos rgidos dos n os. Como n ucleos de processadores e discos em um n o e tamb em
n os em um bastidor (rack) podem falhar, o mesmo bloco de arquivo pode ser armazenado
em m ultiplos n os por todo o aglomerado. O n umero de c opias pode ser congurado, mas
por padr ao, e tipicamente igual a tr es.
O sistema de arquivos do Hadoop e classicado como distribudo porque ele
gerencia o armazenamento por todas as m aquinas da rede e os arquivos s ao distribudos
por entre diversos n os, no mesmo ou em diferentes bastidores ou aglomerados (clusters).
OHadoop trata todos os n os como n os de dados, o que signica que eles podemarmazenar
dados. Entretanto, ele elege ao menos um n o para ser o Name Node. Esse Name Node
decide, para cada arquivo do Hadoop, em qual disco rgido cada uma das c opias de cada
um dos blocos de arquivo e armazenada. Al em disso, o Name Node mant em todas as
informac oes em tabelas armazenadas localmente em seus discos. Quando um n o falha, o
Name Node identica todos os blocos de arquivo que foram afetados; recupera as c opias
desses blocos de arquivo de n os operacionais; encontra novos n os para armazenar outras
c opias dos dados afetados; armazena essas c opias no n o escolhido e atualiza a informac ao
em sua tabela. Quando uma aplicac ao precisa ler um arquivo, ele primeiro se conecta ao
Name Node para obter o endereco dos blocos do disco onde os blocos do arquivo est ao
armazenados. Assim, emseguida, a aplicac ao pode ler esses blocos diretamente semoutra
intervenc ao do Name Node.
Um dos maiores problemas apontados do sistema de arquivos distribudos do Ha-
doop e o fato do Name Node poder se tornar um ponto unico de falha. Se o n o que falhar
for o mesmo onde o Name Node est a, todas as informac oes de mapeamento entre nomes
de arquivos e enderecos de seus respectivos blocos de arquivo podem ser perdidos. Ent ao,
um novo n o precisa ser designado como o Name Node com o mesmo endereco IP do an-
terior que falhou. Para abordar tal quest ao, o Hadoop salva c opias das tabelas criadas
pelo Name Node em outros n os do cluster. Adicionalmente, algumas vers oes do Hadoop,
especialmente as edic oes empresariais, t em outros n os desempenhando o papel de Name
Node de backup.
O segundo mecanismo fundamental do Hadoop e o MapReduce. Como o pr oprio
nome sugere, o MapReduce enxerga uma tarefa computacional como consistindo de duas
fases, a fase de mapeamento (Map) e a fase de reduc ao (Reduce), que s ao executadas
nessa mesma sequ encia. Durante a fase de mapeamento, todos os n os desempenham a
mesma tarefa computacional a partir de um subconjunto dos dados que est a localizado no
pr oprio n o ou pr oximo dele. Em outras palavras, o MapReduce usa o princpio da locali-
dade dos dados para aumentar o seu desempenho e para minimizar a movimentac ao dos
dados pela rede.

E importante notar que devido a todos os blocos de arquivos no sistema
de arquivos distribudos do Hadoop terem o mesmo tamanho, a computac ao na fase de
mapeamento pode ser igualmente dividida entre os n os. Se os blocos de arquivo n ao tives-
sem o mesmo tamanho, o tempo de processamento seria predominantemente ditado pelo
tempo necess ario para processar o bloco de arquivo mais longo, enquanto os outros n os
permaneceriam ociosos. Se considerado, por exemplo, um arquivo utilizado para agregar
entradas de blogs relacionadas a grandes massas de dados postadas nas ultimas 24 horas,
este arquivo seria armazenado de forma dividida no sistema de arquivos distribudos do
Hadoop. Esse arquivo poderia ter o nome de BigData.txt e poderia ser dividido
em blocos de arquivos, cada um gerando pelo menos tr es c opias, armazenadas nos 50 n os
de um aglomerado. A partir desse exemplo, pretende-se iniciar uma an alise dessa grande
massa de dados atrav es, primeiramente, da contagem do n umero de vezes que as palavras
Computador, Rede e Dados s ao mencionadas. Assume-se que a func ao de mape-
amento recebe como entrada o endereco de um bloco de arquivo e oferece como sada o
n umero de vezes que cada uma dessas palavras apareceu. Para tal, cada n o participante
da fase de mapeamento recebe um ponteiro para a func ao de mapeamento e o endereco
do bloco de arquivos localizado no n o. No exemplo, assume-se ainda que a rede seja
composta por tr es n os, sendo eles o N o 1, o N o 2 e o N o 3.
O MapReduce possui outro princpio simples no que se refere a sua estrutura de
sada da fase de mapeamento e entrada e sada da fase de reduc ao, j a que ela consiste de
uma lista de pares <chave, valor>. Esse conceito e t ao importante no MapReduce
que tamb em e apresentado no contexto do exemplo dado a seguir. Ap os a execuc ao da
func ao de mapeamento, cada n o produz uma lista de pares chave-valor, na qual cada
chave e o nome da palavra e o valor e um n umero que indica o n umero de vezes que o
nome aparece no texto. Pode-se, ent ao, utilizar a fase de reduc ao para somar os resultados
obtidos por cada n o para reduzir a sada das func oes de mapeamento a uma unica lista
de pares chave-valor.
No MapReduce, um n o e selecionado para executar a func ao de reduc ao. Todos
os outros n os precisam enviar a lista <chave, valor> criada pela pr opria func ao de
mapeamento ao n o designado. Assumindo que o N o 2 seja cumpra esse papel durante
a execuc ao da func ao de reduc ao, ent ao os N os 1 e 3 t em que os seus resultados para
o N o 2. Tipicamente, durante a fase de reduc ao, as entradas s ao ordenadas e combina-
das antes da reduc ao propriamente dita ocorrer. No exemplo ilustrado na Figura 1.6,
a entrada da fase de reduc ao e <Computador, 7>, <Rede, 5>, <Dados, 4>,
<Computador, 9>, <Rede, 8>, <Dados, 6>, <Computador, 3>, <Rede,
4>, <Dados, 9> que e a sada da fase de mapeamento referente a execuc ao dos N os 1,
2 e 3, respectivamente. O primeiro procedimento executado agrupa os pares <chave,
valor> com a mesma chave de forma ordenada. Em seguida, o procedimento execu-
tado e o procedimento de combinac ao que agrupa os pares <chave, valor> com a
mesma chave em uma unica entrada. O agrupamento e realizado de forma que cada en-
trada seja composta de uma chave e uma lista com todos os valores relacionadas a mesma
chave no procedimento anterior. Finalmente, o procedimento de reduc ao soma os valores
associados a cada chave existente do par <chave, valor>.
Figura 1.6. Fase de reduc ao do MapReduce.
No arcabouco MapReduce, ambas operac oes de mapeamento e reduc ao s ao con-
sideradas rotinas, que combinadas formam uma tarefa. O arcabouco MapReduce requer
que exista:
um JobTracker para coordenar todas as tarefas executadas no sistema atrav es da
divis ao da tarefa em rotinas e para agendar cada uma dessas tarefas para serem
executadas em um n o. O JobTracker tamb em mant em informac oes de todos os n os
participantes da computac ao, monitora os status individuais, orquestra o uxo de
dados e se encarrega de contornar as falhas dos n os;
um n umero de TaskTrackers que executem tarefas e enviem relat orios de progresso
ao JobTracker. Caso a tarefa falhe, o JobTracker pode reagend a-la emumTaskTrac-
ker diferente. O TaskTracker mant em informac oes de todas as tarefas em execuc ao
em seus n os, seja uma tarefa de mapeamento ou reduc ao.
Semelhantemente ao sistema de arquivos distribudos do Hadoop, no qual um n o
assume o papel de um Name Node, no MapReduce, um n o assume o papel de JobTracker.
Antes de executar uma tarefa, um programador de Hadoop deve prover ao MapReduce as
seguintes informac oes: (i) a localizac ao dos dados a serem processados, que consiste em
uma lista de blocos de arquivo e enderecos de todas as c opias oferecidas pelo sistema
de arquivos distribudos do Hadoop, (ii) a func ao de mapeamento a ser executada du-
rante a fase de mapeamento e (iii) a func ao de reduc ao a ser executada durante a fase de
reduc ao. O programador obt em como resultado, uma lista de pares <chave, valor>
consolidada.
De certa forma, a computac ao com o Hadoop em uma arquitetura em aglomerado
prov e uma extens ao de computac oes tpicas realizadas em congurac oes empresariais,
possibilitando que eles desempenhem an alises intensivas em grandes massas de dados.
De acordo com previs oes realizadas pelo Yahoo, at e a segunda metade desta d ecada, 50%
dos dados empresariais estar ao sendo processados e armazenados usando o Hadoop.
Apesar do alto potencial de aprimoramento do desempenho das an alises em gran-
des massas de dados que aproveitam propriedades de localizac ao dos dados, nem sempre
e possvel contar com tal possibilidade. Em centros de dados, os dados podem ser movi-
dos de uma m aquina para outra ou entre diferentes bastidores. Al em disso, os centros de
dados podem estar espalhados por diferentes cidades ou at e mesmo pases. Essa ultima
possibilidade e frequente j a que muitas empresas est ao criando infraestrutura de arma-
zenamento de provedores de servico em nuvem. Para acessar seus dados armazenados
externamente ou at e mesmo para migrar seus dados entre centros de dados geograca-
mente distantes, as empresas podem se servir de redes p ublicas como a Internet. Este
minicurso investiga essa movimentac ao dentro de um unico centro de dados e entre dois
ou mais datacenters chamando esse tipo de comunicac ao de, respectivamente, migrac ao
intra e inter-datacenter.
1.5. Modelos de Interconex ao para Arquiteturas em Aglomerac ao
Um dos principais fatores a serem levados em considerac ao na implantac ao de cen-
tros de dados e o custo. Por quest oes de compatibilidade e de custo, a maioria dos
sistemas de comunicac ao para aglomerados utiliza comutadores Ethernet e roteadores
para interconectar as m aquinas dos aglomerados [Al-Fares et al., 2008]. A agilidade
2
e
uma outra propriedade que deve ser provida por esses sistemas em aglomerados. Nesta
subsec ao, s ao apresentadas as arquiteturas tpicas e propostas de novas arquiteturas de
centros de dados, incluindo suas principais caractersticas, tais como topologias, esque-
mas de enderecamento e mecanismos de roteamento e de encaminhamento.
As arquiteturas tpicas de centros de dados consistem em arvores hier arquicas de
dispositivos de roteamento e de comutac ao com equipamentos cada vez mais especiali-
zados e caros conforme se sobe na hierarquia.

E comum se ter arvores de dois ou tr es
nveis de comutadores e de roteadores [Al-Fares et al., 2008]. Na topologia de tr es nveis,
servidores s ao conectados a comutadores topos de bastidores (Top-of-Racks - ToRs), co-
mutadores de agregac ao conectam comutadores ToRs e s ao conectados a roteadores de
2
Agilidade signica capacidade de associar qualquer hospedeiro a qualquer servico em uma topologia
em aglomerado [Greenberg et al., 2009].
n ucleo, como apresentado na Figura 1.7. A topologia de dois nveis somente possui as
camadas n ucleo e ToR. Comutadores nas folhas de uma arvore possuem tipicamente de
48 a 288 portas Gigabit Ethernet que conectam servidores e algumas portas a 10 Gb/s de
subida (uplink). Os comutadores de nveis mais altos somente possuem portas a 10 Gb/s
(tipicamente de 32 a 128 portas).
Figura 1.7. Arquitetura em camadas tpica de centros de dados.
Considerando essas arquiteturas tpicas de centros de dados, um dos principais ar-
tifcios utilizados para diminuir o custo e a velocidade do enlace para um nvel mais alto
n ao corresponder ` a soma de todos os enlaces de nvel mais baixo, artifcio denominado
sobreinscric ao (oversubscription). Por exemplo, uma sobreinscric ao 1:4 signica que os
dispositivos da camada de agregac ao ou de n ucleo possuem capacidade menor do que a
capacidade total dos dispositivos do nvel mais baixo, na proporc ao de 1 para 4, ou seja,
para cada 4 Gb/s de banda passante dos servidores, corresponde somente 1 Gb/s no nvel
superior (uplinking). Por outro lado, uma sobreinscric ao 1:1 signica que todos os servi-
dores podemse comunicar comoutros servidores usando a taxa m axima de suas interfaces
de rede, alcancando o que se denomina m axima banda passante agregada (full bisection
bandwidth). A sobreinscric ao 1:1 na verdade corresponde ` a aus encia de sobreinscric ao.
A capacidade de comunicac ao utilizando a banda total entre quaisquer pares de
servidores e um requisito que as novas arquiteturas de centros de dados procuram atender.
No caso em que um unico roteador de n ucleo e utilizado, h a uma restric ao quanto ao
n umero m aximo de servidores da rede. Por exemplo, considere um dispositivo comercial
tpico de grande porte que possui 128 portas de 10 Gb/s sendo utilizado na camada de
n ucleo. A cada porta de 10 Gb/s conecta-se o enlace de subida de um comutador de
menor porte ao qual podem ser conectados em suas portas de 1 Gb/s at e 10 servidores,
para que seja garantida a banda total de 10 Gb/s sem sobreinscric ao. Assim, considerando
uma sobreinscric ao 1:1 e a banda disponvel nesse unico dispositivo do n ucleo, o n umero
m aximo de servidores na rede do centro de dados seria limitado a 1.280.
Este exemplo mostra a diculdade de se interconectar um grande n umero de ser-
vidores em um aglomerado sem sobreinscric ao usando a topologia em arvore. Uma
forma de se contornar a restric ao de n ao se conseguir equipamentos de baixo custo com
enlaces de subida de taxas muito altas e a utilizac ao de m ultiplos enlaces de subida
ou topologias diferentes da mencionada acima. Em func ao disso, utilizam-se arvores
com m ultiplas razes e t ecnicas de m ultiplos caminhos, tais como o algoritmo Equal-
Cost Multi-Path (ECMP) [Hopps, 2000]. O ECMP realiza um balanceamento est atico
de carga se caminhos de um mesmo custo estiverem disponveis. Contudo, o n umero de
m ultiplos caminhos e baixo e o n umero de entradas nas tabelas de roteamento cresce
bastante com o n umero de caminhos, aumentando o custo e lat encia de busca na ta-
bela [Al-Fares et al., 2008].
1.5.1. Fat-tree
Uma das arquiteturas cujo principal objetivo e reduzir o custo mantendo a capacidade de
comunicac ao utilizando a banda total entre quaisquer pares de servidores e denominada
Fat-tree [Al-Fares et al., 2008], ou arvore gorda. Diferentemente da arvore comum, a
arvore gorda e mais parecida com uma arvore real, pois esta ca cada vez mais grossa
partindo-se das folhas. Na arvore gorda, quanto mais se sobe na hierarquia, maior e o
n umero de enlaces utilizados conectando um n o lho ao seu pai; consequentemente a
banda passante aumenta [Leiserson, 1985].
Essas redes cont em m ultiplos est agios construdos como uma matriz de peque-
nos elementos de conex ao. Na topologia Fat-tree, comutadores Ethernet de prateleira
3
s ao utilizados, de forma a reduzir o custo da arquitetura. Por exemplo, comutadores de
48 portas de 1 Gb/s poderiam ser usados em uma Fat-tree.
A regra de formac ao de uma Fat-tree e apresentada a seguir. Uma k- esima Fat-
tree e composta por k pods e (k/2)
2
comutadores de n ucleo com k portas. Um pod possui
duas camadas (borda e agregac ao) de k/2 comutadores cada e tamb em inclui k servidores.
Cada comutador com k portas na camada de borda e conectado a k/2 servidores. As ou-
tras k/2 portas de um comutador de borda s ao conectadas a k/2 de k portas na camada de
agregac ao. Cada comutador de n ucleo possui uma porta conectada a cada um dos k pods.
Nesta arquitetura, no total podem ser conectados k
3
/4 servidores. Todos os servidores co-
nectados ao mesmo comutador de borda pertencem a uma mesma sub-rede, enquanto que
a comunicac ao entre servidores de diferentes sub-redes envolve roteamento. A Figura 1.8
mostra um exemplo de uma topologia Fat-tree com k = 4. Nessa topologia caso sejam
utilizados comutadores de 48 portas de 1 Gb/s haveria 48 pods, com 24 comutadores em
cada uma das camadas de borda e de agregac ao e 24 servidores ligados a um pod, em um
total de 27.648 servidores.
Para atingir a capacidade m axima de comunicac ao utilizando a banda total entre
quaisquer pares de servidores e necess ario distribuir de forma mais uniforme possvel o
tr afego de sada de um dado pod entre os comutadores de n ucleo. H a ent ao a neces-
sidade de se utilizar um m etodo de distribuic ao que seja simples e que tire vantagem
da estrutura da topologia. Dessa forma, os autores prop oem o uso de tabelas de rotea-
mento de dois nveis para espalhar o tr afego baseando-se nos bits menos signicativos
do endereco IP de destino. A seguir o esquema de enderecamento e descrito e posterior-
mente as tabelas de roteamento ser ao apresentadas. De forma a simplicar as tabelas de
roteamento, um esquema especial de enderecamento e utilizado. Enderecos IP s ao aloca-
dos a partir de um bloco 10.0.0.0/8. Comutadores de um pod utilizam enderecos da forma
10.pod.comutador.1, onde pod se refere ao n umero do pod, de 0 a k1, da esquerda para
direita, enquanto comutador signica a posic ao daquele comutador no pod, de 0 a k 1,
3
Em [Al-Fares et al., 2008], os autores usam o termo comutador se referindo a dispositivos que realizam
comutac ao no nvel 2 e roteamento no nvel 3. A mesma notac ao ser a utilizada nesta subsec ao.
Figura 1.8. Exemplo de topologia Fat-tree com k=4.
da esquerda para direita, de baixo para cima. Os enderecos dos comutadores de n ucleo
seguem o padr ao 10.k. j.i, onde j e i est ao relacionados ` a coordenada do comutador na
grade de (k/2)
2
comutadores, cada um de 1 a k/2, comecando em cima e ` a esquerda.
Os servidores utilizam enderecos da forma 10.pod.comutador.id, onde id e a posic ao do
servidor naquela sub-rede, de 2 a k/2+1, da esquerda para direita. A Figura 1.8 tamb em
inclui um exemplo do esquema de enderecamento.
Fares et al. assumem que existe uma entidade central com conhecimento da topo-
logia do aglomerado que gera e carrega todas as tabelas de roteamento nos comutadores
durante a fase de estabelecimento da rede. Algoritmos especcos para gerar as tabelas
de roteamento dos comutadores de agregac ao e de n ucleo e para distribuir essas tabe-
las s ao apresentados em [Al-Fares et al., 2008]. Al em disso, duas t ecnicas opcionais de
roteamento din amico s ao tamb em apresentadas.
A arquitetura Fat-tree tamb em inclui extens oes ao encaminhamento IP de forma a
atingir o uso efetivo da capacidade da topologia. Essas extens oes envolvem modicac oes
nos comutadores. De uma maneira geral, uma vez que o pacote chega a um comutador
de n ucleo, existe um enlace para o seu pod de destino. Ap os o pacote chegar ao seu pod
de destino, ele e enviado ao seu comutador de sub-rede de destino e depois e nalmente
enviado ao servidor de destino. Tabelas de roteamento de dois nveis s ao utilizadas para
espalhar o tr afego baseando-se nos bits menos signicativos do endereco IP de destino.
Cada entrada da tabela (pre f ixo, porta) possui um ponteiro adicional para uma tabela se-
cund aria com entradas do tipo (suf ixo, porta). Uma tabela secund aria pode ser apontada
por mais de um prexo de primeiro nvel. Se a busca pelo prexo mais longo coinci-
dente obt em como resultado um prexo que cont em um suxo de segundo nvel, o suxo
mais longo coincidente na tabela secund aria e utilizado. Para comunicac oes inter-pods,
os comutadores de um pod possuem um prexo padr ao /0 com a tabela secund aria coin-
cidindo com os identicadores dos hospedeiros (byte menos signicativo do endereco IP
de destino). Por exemplo, na Figura 1.9 e apresentada a tabela do comutador 10.2.2.1
(Figura 1.8). Um pacote com endereco de destino 10.2.1.2 e encaminhado na porta 1,
enquanto que um pacote para 10.3.0.3 e enviado na porta 3. Na Figura 1.8, dados do
servidor 10.0.1.2 para o 10.2.0.3 seguem o caminho indicado em tracejado.
As tabelas de roteamento de dois nveis podem ser implementadas em hardware
usando mem orias CAM (Content-Addressable Memory). Mais especicamente, um tipo
especial de mem oria CAMdenominado TCAM(Ternary CAM) e utilizado. Uma mem oria
TCAM permite buscas mais exveis por utilizar Xs (dont cares) al em dos 0s e 1s. As-
sim, a TCAM pode por exemplo armazenar o valor 0x0C.3F.XX.XX, onde alguns bits
n ao s ao denidos. Assim, em vez de apenas enderecos IP completamente denidos de
32 bits, a TCAM permite armazenar prexos e suxos de enderecos. Estes indexam uma
mem oria RAM que armazena o endereco IP do pr oximo salto e a porta de sada.
Figura 1.9. Tabela de roteamento de dois nveis no comutador 10.2.2.1 da Figura 1.8.
1.5.2. BCube
O BCube [Guo et al., 2009] tamb em procura resolver os problemas de custo e de desem-
penho relacionados ` a necessidade de enlaces de subida de alta taxa de transmiss ao para
diminuic ao da sobreinscric ao, por em utilizando uma abordagem diferente da Fat-tree. O
BCube foi especicamente projetado para centros de dados modulares (Modular Data
Centers - MDCs) montados em cont eineres, que s ao estruturas mais ecientes em relac ao
` a refrigerac ao dos equipamentos. Como os cont eineres s ao selados e depois colocados em
operac ao, torna-se bastante difcil a manutenc ao de seus componentes [Guo et al., 2009].
Assim, a infraestrutura de rede nos MDCs necessita alta toler ancia a falhas. O BCube
foi projetado para possuir uma queda de desempenho lenta quando submetido a falhas
em seus comutadores ou servidores. Outra caracterstica importante que e atendida por
essa arquitetura corresponde ao suporte aos diferentes padr oes de comunicac ao: um-para-
um, um-para-muitos, um-para-todos e todos-para-todos. Essa medida visa atender v arias
aplicac oes que demandam grande banda passante, tais como sistemas de arquivos dis-
tribudos (um-para-muitos) e MapReduce (muitos-para-muitos).
No BCube, os servidores s ao conectados a m ultiplas camadas de pequenos comu-
tadores. O BCube corresponde a uma estrutura denida de forma recursiva. Um BCube
de nvel 0, denominado BCube
0
, consiste de n servidores conectados a um comutador de
n portas. J a um BCube
1
e composto por n BCube
0
s e por n comutadores de n portas. De
uma maneira geral, um BCube
k
(k 1) e formado por n BCube
k1
s e n
k
comutadores de
n portas. Os n BCube
k1
s s ao numerados de 0 a n1 e os servidores em cada BCube
k1
s ao numerados de 0 a n
k
1. A porta do nvel k do i- esimo servidor localizado no j- esimo
BCube
k1
e conectada ` a j- esima porta do i- esimo comutador de nvel k. A Figura 1.10
apresenta um BCube
1
com n = 4.

E importante ressaltar que o BCube mostrado na Fi-
gura 1.10, ao contr ario da Fat-tree mostrada na Figura 1.8, requer mais de uma interface
Ethernet no servidor.
Existe um mapeamento de um-para-um entre um endereco IP e um endereco
Figura 1.10. Um exemplo de BCube
1
com n=4.
BCube. O BCube tamb em utiliza enderecos de 32 bits. O BCube armazena um ndice
de pr oximo salto (Next Hop Index - NHI) e o caminho completo (array de NHIs) no
cabecalho de cada pacote. Um vers ao de 8 bits do NHI, chamada NHA, pode ser usada
para reduzir o tamanho do cabecalho. Um NHA e dividido em duas partes: DP e DV.
O DP indica qual dgito do pr oximo salto e diferente do atual servidor de retransmiss ao
enquanto que o DV corresponde ao valor daquele dgito.
O BCube prov e m ultiplos caminhos paralelos e curtos para permitir comunicac oes
servidor-para-servidor. Al em de prover uma grande banda passante na comunicac ao um-
para-um, esses caminhos tamb em aumentam a toler ancia a falhas e melhoram o balan-
ceamento de carga. Um protocolo de roteamento pela fonte denominado BSR (BCube
Source Routing) e utilizado por tr es motivos. Primeiro, a fonte pode controlar o cami-
nho sem coordenac ao com os servidores intermedi arios. Segundo, esses servidores inter-
medi arios n ao se envolvem no roteamento e somente encaminham pacotes, simplicando
suas operac oes. Por ultimo, ao sondar a rede de modo reativo, pode-se evitar a difus ao
de estados de enlaces, que possui um problema de escalabilidade quando milhares de ser-
vidores est ao em operac ao. Ao tirar proveito dos m ultiplos caminhos e por ativamente
sondar a rede, o BSR prov e balanceamento de tr afego e lida com falhas sem necessitar
distribuir os estados dos enlaces. Com o BSR, a capacidade do BCube diminui de modo
n ao abrupto quando as falhas dos servidores/comutadores aumentam.
O funcionamento do BSR e apresentado a seguir. Quando um uxo deve ser
transmitido, a fonte envia sondas em m ultiplos caminhos. Os servidores intermedi arios
incluem informac oes nesses pacotes que ser ao utilizadas para selecionar um dos m ultiplos
caminhos, por exemplo, mnima banda passante disponvel. Quando uma sonda chega
ao destino, o destino envia uma resposta para a fonte. Ao receber as respostas, a fonte
seleciona o melhor caminho baseado em alguma m etrica, por exemplo, a m axima banda
passante disponvel. O algoritmo usado para calcular os k +1 caminhos paralelos entre
dois servidores e apresentado em [Guo et al., 2009].
O procedimento de encaminhamento utiliza uma tabela de status de vizinhos,
mantida por um protocolo de manutenc ao de vizinhos. Cada entrada na tabela corres-
ponde a umvizinho e possui tr es campos: NeighborMAC, OutPort e StatusFlag. ONeigh-
borMAC e o endereco MAC do vizinho, o qual e obtido do protocolo de manutenc ao de
Figura 1.11. Exemplo da topologia Camada Virtual 2 (VL2).
vizinhos, OutPort indica a porta de conex ao com o vizinho e o StatusFlag indica se o
vizinho est a disponvel. Cada entrada e indexada pelo valor de NHA do vizinho. Quando
um hospedeiro intermedi ario recebe um pacote, ele obt em o NHA do pr oximo salto do
cabecalho do pacote. Ent ao ele extrai o status e o endereco MACdo pr oximo salto, usando
o NHA como ndice. Se o pr oximo salto est a funcional, ele atualiza os enderecos MAC,
o NHA e a soma de vericac ao (checksum) do cabecalho do BCube e encaminha o pacote
pela porta de sada.
1.5.3. Camada Virtual 2 (VL2)
A proposta Camada Virtual 2 (Virtual Layer 2 - VL2) [Greenberg et al., 2009] utiliza co-
mutadores de baixo custo
4
em uma topologia Clos para lidar com o problema de custo e
tamb em com a quest ao da agilidade. O VL2 prov e a ilus ao de que os servidores est ao co-
nectados a um grande comutador n ao interferente de Camada 2 que abrange um centro
de dados. Essa caracterstica do comutador equivale ` a propriedade de n ao-bloqueio em
redes de comutac ao de circuitos, enquanto as taxas de distribuic ao de tr afego forem uni-
formes e os padr oes de tr afego oferecido n ao violarem restric oes da borda (por exemplo,
velocidade da placa).
Os enlaces entre os comutadores de n ucleo e de agregac ao formam um grafo com-
pleto bipartido, facilitando assim o balanceamento de carga entre os diversos comutadores
de n ucleo. Os comutadores ToR s ao conectados a dois comutadores de agregac ao. Cada
servidor e conectado a um comutador ToR. Um exemplo de uma rede VL2 e apresentado
na Figura 1.11.
OVL2 utiliza dois tipos de enderecos IP. Todos os comutadores usamenderecos IP
especcos de localizac ao (Location-specic IP Addresses - LAs), enquanto os servidores
e os comutadores ToR usam enderecos IP especcos de aplicac ao (Application-specic
IP Addresses - AAs). Um AA n ao e modicado mesmo se a localizac ao do servidor
mudar por migrac ao ou reprovisionamento. Cada servidor e associado com um LA, o
identicador do comutador ToR ao qual o servidor est a conectado. Existe um sistema
de diret orios que mapeia AAs em LAs. Os enderecos LAs de comutadores de n ucleo
4
Em [Greenberg et al., 2009], os autores utilizam o termo comutador se referindo a dispositivos que
realizam roteamento no Nvel 3. A mesma notac ao ser a utilizada nesta subsec ao.
Figura 1.12. Exemplo de enderec amento da Camada Virtual 2 (VL2). O H(ft) cor-
responde ao hash da tupla de cinco valores.
s ao um s o, pois essa opc ao simplica o procedimento de balanceamento de carga (a ser
apresentado a seguir). Al em disso, como alguns comutadores baratos n ao proveem su-
porte a tuplas com cinco elementos (por exemplo, para o TCP: protocolo, endereco fonte,
porta fonte, endereco de destino e porta de destino) quando um pacote e encapsulado
com m ultiplos cabecalhos IP, um agente na fonte calcula um hash dos cinco valores e
escreve esse hash no campo endereco IP da fonte, usado pelos comutadores nas tomadas
de decis ao de encaminhamento utilizando o ECMP, como descrito a seguir.
Os comutadores executam o protocolo OSPF disseminando somente enderecos
LAs. Al em disso, dois mecanismos de balanceamento de carga s ao usados: o VLB e o
ECMP. O objetivo dos dois mecanismos e similar: o VLB distribui tr afego atrav es de n os
intermedi arios enquanto que o ECMP o faz atrav es de caminhos de mesmo custo.
O VLB (Valiant Load Balancing) distribui tr afego pelos comutadores de n ucleo
sem uma coordenac ao centralizada ou usar engenharia de tr afego. Usando o VLB, cada
servidor independentemente seleciona um caminho aleat orio para cada um dos uxos que
envia para outros hospedeiros. O VLB usa uxos como unidade b asica de espalhamento
para evitar a entrega fora de ordem de pacotes. J a o ECMP lida com a entrega de pacotes
encapsulados com o endereco anycast a qualquer um dos comutadores de n ucleo. O uso
de enderecos anycast simplica o sistema de diret orios. No caso de falha de comutadores
ou de enlaces, o ECMP ir a reagir, eliminando a necessidade de noticar os agentes e
assegurando a escalabilidade.
A Figura 1.12 mostra um exemplo do encaminhamento junto com os mecanismos
VLB e ECMP. Para encaminhar tr afego entre os hospedeiros 20.0.0.55 e 20.0.0.56, um
agente VL2 no hospedeiro captura o pacote e o encapsula com o endereco LA do co-
mutador ToR de destino (10.0.0.6 na Figura 1.12). Al em disso, o pacote e encapsulado
com o endereco anycast 10.1.1.1. Depois de passar pelo comutador ToR, o pacote ent ao
e entregue a um dos comutadores de n ucleo, desencapsulado pelo comutador, entregue
ao comutador ToR utilizando o endereco LA, desencapsulado de novo e ent ao enviado ao
destino.
1.5.4. Jellysh
O Jellysh [Singla et al., 2011] aborda a quest ao da expans ao incremental dos datacen-
ters. Esse problema e comumente deixando de lado por outras propostas da literatura,
principalmente aquelas que prop oem o uso de topologias rgidas. Tipicamente, o n umero
de servidores em topologias conhecidas e determinado pelo n umero de portas dos comuta-
dores disponveis. Como visto, em uma topologia do tipo Fat-Tree [Al-Fares et al., 2008],
o n umero m aximo de servidores e func ao do n umero de portas dos seus comutadores. Se-
melhantemente, no BCube [Guo et al., 2009], o n umero m aximo de servidores depende
no n umero de portas por comutador e tamb em do n umero de nveis da sua estrutura mo-
dular. O n umero m aximo de servidores, nesse caso, e func ao do n umero de portas por
comutador e do n umero de nveis do modelo de interconex ao.
Tanto no Fat-Tree [Al-Fares et al., 2008] quanto no BCube [Guo et al., 2009], o
aumento do n umero de servidores pode desbalancear a estrutura se for feita de maneira
a n ao levar em conta a rigidez da topologia. A consequ encia e a possibilidade de perda
de duas propriedades principais dos centros de dados (datacenters) que s ao a vaz ao de
bissec ao e a toler ancia a falhas. Logo, se mais servidores forem necess arios, todos os
comutadores devem ser substitudos para manter as propriedades desejadas. Essa carac-
terstica n ao e interessante j a que as demandas dos clientes por armazenamento e pro-
cessamento de dados est ao crescendo a passos largos. O Jellysh permite que as co-
nex oes sejam realizadas de forma aleat oria no nvel dos comutadores, resultando em uma
distribuic ao uniforme que n ao compromete as propriedades de interesse dos centros de
dados. O modelo de interconex ao de um centro de dados que utilize o Jellysh e formado
por comutadores e servidores. Assumindo que cada comutador i tenha k
i
portas, c
i
delas
s ao conectadas a outros comutadores, enquanto as portas restantes, k
i
c
i
, s ao conectadas
a servidores. Para simplicar, se existirem n comutadores na rede e se todos eles tiverem
o mesmo n umero de portas (k =k
i
) e comutadores conectados (c =c
i
), ent ao o n umero de
servidores suportados e n(k c). Ao amostrar o espaco de possibilidades, a topologia
resultante se mostra aleat oria e uniformemente distribuda.
A construc ao segue um algoritmo que empiricamente oferece as propriedades de-
sejadas atrav es da interconex ao dos comutadores e dos comutadores com os servidores.
O algoritmo usado no Jellysh inicia escolhendo e, posteriormente, conectando um par
aleat orio de portas entre as disponveis no centro de dados. Esse procedimento e recur-
sivamente repetido at e que n ao sobrem mais portas disponveis ou um unico comutador
permaneca com duas ou mais portas desconectadas. Caso o ultimo caso ocorra, um dos
enlaces existentes e aleatoriamente escolhido e removido. A remoc ao aumenta o n umero
de portas disponveis na topologia para que as portas que haviam sobrado possam ser
conectadas.
A Figura 1.13 mostra comutadores de quatro portas (k
i
=k =4), os quais cada um
est a conectado a dois servidores e dois comutadores (c
i
= c = 2). Logo, ao nal, todos os
comutadores devem ter suas c portas conectadas a outros comutadores e k c portas co-
nectadas a servidores. Na topologia ilustrada, o n umero m aximo de servidores e, portanto,
n (k c) = 5 (4 2) = 10. No exemplo, a execuc ao do algoritmo de interconex ao
da rede termina com um comutador (Comutador S) com duas portas disponveis. Quando
isso ocorre, enlaces existentes devem ser removidos at e que as portas que tenham sobrado
sejam conectadas. Cada enlace e removido por vez, at e que o n umero de portas disponi-
bilizadas seja suciente. A Figura 1.13(b) mostra a mesma topologia depois da remoc ao
dos enlaces A e da posterior conex ao das portas que haviam sobrado no Comutador S ` a
topologia.

E importante mencionar que outra vantagem do Jellysh e de n ao exigir que os
equipamentos sejam iguais e, portanto, comutadores com um n umero diferentes de portas
podem ser usados.
(a) Topologia incompleta. (b) Topologia completa.
Figura 1.13. A topologia Jellysh com conex ao aleat oria.
1.6. A Internet e a Migrac ao de Grandes Massas de Dados
A arquitetura atual da Internet imp oe diferentes desaos para a migrac ao de grandes mas-
sas de dados. A movimentac ao de grandes quantidades de dados, seja em uma unica
localidade, como uma rede interna de um centro de dados, ou entre localidades geo-
gracamente distantes apresentam limitac oes devido ` a arquitetura e protocolos atuais da
Internet. Em um sistema de comunicac ao interno a um centro de dados, o TCP apre-
senta diferentes obst aculos a grandes transmiss oes de dados. No cen ario distribudo,
muito frequentemente diferentes parceiros precisam reunir massas de dados que est ao
globalmente distribudas. Por exemplo, colaboradores em uma nuvem computacional
com m ultiplos centros de dados podem precisar mover dados da ordem de alguns Teraby-
tes para um unico centro de dados [Cho e Gupta, 2011], com as mais diversas nalidades
como por exemplo consolidac ao de dados cientcos. Assim, podem-se dividir o escopo
das limitac oes da Internet para a migrac ao de grandes massas de dados em cen arios inter-
nos a um centro de dados (intra-datacenter) e cen arios de comunicac ao entre centros de
dados (inter-datacenters).
1.6.1. Cen arios de sistema de comunicac ao interno a um centro de dados
O processamento e armazenamento de grandes quantidades de dados de forma escal avel
requer um processamento distribudo em um aglomerado (cluster) ou uma rede de centro
de dados. Ap os o processamento pelos servidores, os resultados s ao enviados para um
unico servidor agregador atrav es de m ultiplas conex oes TCP. Essas conex oes comparti-
lham o mesmo buffer do comutador de topo de bastidor (Top of Rack) no qual o agregador
est a conectado.
`
A medida que o n umero de servidores cresce, a capacidade do buffer
se esgotar a e o comutador comecar a a descartar pacotes. Em algumas aplicac oes, como
o Map Reduce, o n o remetente n ao poder a enviar um novo bloco de dados at e que os
blocos de todos outros servidores tenham sido transmitidos com sucesso. Como no TCP
um remetente precisa esperar uma temporizac ao ou tr es ACKs duplicados para reenviar
os pacotes perdidos, todos os outros remetentes estar ao bloqueados e n ao poder ao enviar
novos blocos, degradando o desempenho geral da aplicac ao. Muito esforco e atualmente
empregado para contornar essas limitac oes do TCP [Zhang et al., 2011]. Uma soluc ao e
evitar temporizac oes no TCP. O TCP possui um valor mnimo de temporizac ao (RTO
min
)
de 200ms, mas a lat encia emenlaces de centros de dados pode ser da ordemde centenas de
microssegundos. Assim, a espera de temporizac ao pode provocar uma reduc ao de desem-
penho severa. Para evitar temporizac oes Phanishayee et al. [Phanishayee et al., 2008]
prop oem a reduc ao do limiar de ACKs duplicados de 3 para 1. Al em disso, a fase de
partida lenta (slow-start) do TCP e desativada. Uma outra soluc ao, proposta por Vasude-
van et al., e a reduc ao da granularidade do RTO
min
de milissegundos para microssegun-
dos. Outros trabalhos prop oem a mudanca no esquema de controle de congestionamento.
Alizadeh et al. [Alizadeh et al., 2010] emprega noticac ao de congestionamento explcita
(ECN - Explicit Congestion Notication) na qual os comutadores da rede marcam pacotes
quando detectam congestionamento. Nesse trabalho e proposto um esquema de controle
no qual os remetentes reagem ` as marcas ECN pela reduc ao da janela de congestionamento
de acordo com a frac ao de marcas recebidas. Wu et al. [Wu et al., 2010] prop oem um con-
trole de congestionamento executado pelo receptor, ao inv es de deixar essa func ao para os
remetentes como feito pelo TCP padr ao. Para isso, nesse trabalho e utilizado o controle
de taxa padr ao do TCP, no qual o receptor pode ajustar a m axima janela de congestiona-
mento permitida para o remetente. Assim, o receptor ajusta a janela de congestionamento
de todos os remetentes baseado na informac ao da banda disponvel.
Outro desao relacionado ao TCP em redes locais de centro de dados diz respeito
` a lat encia. O TCP foi projetado para fornecer o envio ordenado de dados, conabili-
dade dos dados e controle de congestionamento. Todas as conex oes TCP que dividem
um enlace de gargalo da rede reagem ao congestionamento de forma que cada uma das
conex oes obtenha uma parcela justa da banda passante disponvel naquele enlace. Por
outro lado, muitas aplicac oes de centros de dados tem na lat encia o principal requisito de
desempenho, uma vez que nestas aplicac oes o usu ario espera respostas do sistema quase
em tempo real. Aplicac oes de redes sociais como o Facebook pertencem a esta categoria.
Para estas aplicac oes de tempo quase real, se um uxo enviado na rede n ao completar
antes de um prazo m aximo, todo o uxo de rede foi desperdicado, porque a resposta ao
usu ario n ao chegou a tempo. O TCP n ao foi projetado para transportar estes uxos com
prazo m aximo, e propostas como o D
3
, descrito na Sec ao 1.7.2, tentam preencher esta
lacuna.
1.6.2. Cen arios de sistema de comunicac ao entre centros de dados
No contexto de aplicac oes distribudas que lidam com grandes massas de dados, a arqui-
tetura atual da Internet apresenta diferentes desaos para a movimentac ao de dados. A
Internet e composta por em torno de 60.000 sistemas aut onomos [BGP Reports, 2012], in-
terconectados em uma topologia de livre-escala [Barabasi e Bonabeau, 2003]. Enlaces de
longa dist ancia s ao frequentemente os mais caros nanceiramente e, como consequ encia,
a banda passante e normalmente mais escassa considerando este tipo de enlace que nas re-
des locais. Outra caracterstica inevit avel dos enlaces de longa dist ancia e, naturalmente,
maior lat encia.
Propostas como o Netsticher, descrita mais ` a frente na Sec ao 1.8.1, tentam orga-
nizar as grandes transfer encias de dados no eixo do tempo. A observac ao motivadora e
que, como uma consequ encia dos hor arios de trabalho das pessoas, os enlaces de longa
dist ancia apresentam utilizac ao da banda passante que e heterog enea ao longo do dia. Es-
tes enlaces podem apresentar nada passante inutilizada, por exemplo, de 2:00 ` as 06:30
da manh a. Essas oportunidades de transmiss ao podem ser usadas para transferir grandes
massas de dados. Por exemplo, o procedimento de backup de um grande banco de dados
pode ser realizado atrav es da divis ao dos dados em pedacos e sua transmiss ao de acordo
com as oportunidades de transmiss ao que ocorram. Al em disso, os pedacos dos dados
podem ser armazenados em n os intermedi arios para aguardar a pr oxima oportunidade de
transmiss ao. O Netstitcher e um sistema que realiza o agendamento das transmiss oes para
aproveitar a banda passante de sobra.
Outros tipos de soluc oes propostas na literatura levam em considerac ao o custo
nanceiro para decidir que m etodos de transmiss ao de informac ao ser ao utilizados para
transmitir as massas de dados. Um exemplo e o sistema Pandora (People and Networks
Moving Data Around) [Cho e Gupta, 2011], em uma traduc ao livre, pessoas e redes mo-
vimentando dados. O Pandora considera como meios de transmiss ao de dados a Internet
e o envio de discos rgidos por empresas de entrega expressa. O custo de envio mnimo
e a m etrica de desempenho utilizada como objetivo. J a os dados de entrada s ao os cus-
tos de transmiss ao de dados pela Internet, que dependem do tipo de conex ao, enlaces de
longa dist ancia, etc., os custos de envio utilizando diferentes servicos de empresas como
os correios. Al em disso o tempo de envio tamb em e contabilizado. Este depende do tipo
de servico escolhido no caso de envio de discos pelo correio, ou das taxas de transmiss ao
no caso de envio pela Internet.
1.7. Soluc oes para a Migrac ao dentro de um Centro de Dados
Um grande n umero de estrat egias foram propostas na literatura para enfrentar os desa-
os que surgem como consequ encia das grandes massas de dados e, de maneira mais
geral, quando o cen ario de rede envolve centros de dados. Nesta sec ao, s ao apresenta-
das soluc oes de sistemas de comunicac ao que tratam diferentes problemas deste tipo de
cen ario, focando o problema de qualidade de servico intra centro de dados (intra datacen-
ter). Para cada uma das soluc oes, primeiro e apresentado o problema tratado e em seguida
seu funcionamento. Embora o objetivo neste trabalho n ao seja reunir todas as soluc oes
em um mesmo arcabouco, estas soluc oes ilustram os diferentes problemas que podem ser
encontrados em redes de centros de dados.
1.7.1. Enlaces multi-gigabit para aumentar a capacidade de centros de dados
Halperin et al. [Halperin et al., 2011] prop oem uma arquitetura hbrida misturando enla-
ces cabeados e sem o para melhorar o desempenho da rede. A adic ao de alguns poucos
enlaces sem o denominados yways pode aliviar pontos com alta carga (hotspots) e
aumentar o desempenho das aplicac oes. Nessa arquitetura hbrida, a rede cabeada pode
ser uma arquitetura tpica de centros de dados ou uma das novas arquiteturas que eli-
minam o problema de sobreinscric ao, tais como [Al-Fares et al., 2008, Guo et al., 2009,
Greenberg et al., 2009]. Al em disso, esta rede cabeada pode ser provisionada para uma
carga m edia. Na parte sem o, cada comutador topo de bastidor (ToR) e equipado com um
ou mais dispositivos que trabalham a 60 GHz, com antenas direcionadas eletronicamente.
(a) Sem yway. (b) Com um yway de C para B (enlace ponti-
lhado).
Figura 1.14. Exemplo de yway.
Atrav es do uso de antenas direcionais, os enlaces de 60 GHz podem prover suporte a taxas
de v arios Gb/s a dist ancias de v arios metros.
O objetivo dessa arquitetura e congurar os enlaces yways e o roteamento para
melhorar o tempo necess ario para satisfazer demandas de tr afego. A arquitetura possui
tr es tarefas principais: medir e estimar demandas de tr afego, decidir quais yways ins-
tanciar e realizar mudancas no roteamento para enviar tr afego atrav es dos yways. Um
controlador central monitora padr oes de tr afegos de centros de dados e comuta os fei-
xes dos dispositivos sem o para estabelecer yways entre comutadores topo de bastidor
que proveem banda passante adicional quando necess ario. Um mecanismo de tr afego
de tr ansito indireto e utilizado para aumentar o desempenho. O algoritmo proposto pe-
los autores para selecionar os yways a serem instanciados escolhe o que desvia a maior
quantidade de tr afego de um enlace de gargalo. Isso resulta em utilizar yways entre
n os que estejam pr oximos e que tenham alta capacidade. Ao permitir tr afego em tr ansito,
garante-se que qualquer yway que possa descarregar tr afego de umenlace de gargalo ser a
util, mesmo que esse enlace n ao seja entre o par straggler, isto e, o par ToR que envia
a maior quantidade de tr afego no enlace de gargalo e termina a comunicac ao por ultimo.
Mais informac oes sobre o algoritmo podem ser obtidas em [Halperin et al., 2011]. A Fi-
gura 1.14 ilustra um exemplo de uso de yways. S ao mostrados seis comutadores topo
de bastidor, A, C, D, E, F e G, que possuem tr afego para o comutador topo de bastidor
B. O comutador A possui 100 unidades de tr afego para enviar enquanto os comutadores
de C a G possuem 80 unidades cada, em um total de 500 unidades a serem enviadas para
B. A capacidade de entrada e de sada dos enlaces cabeados dos comutadores topo de
bastidor e de 10 unidades/s. O enlace de descida (downlink) para B e o gargalo, pois
por ele devem passar as 500 unidades e s ao necess arios 50 s para que B receba todas as
unidades (Figura 1.14(a)). Se um yway est a habilitado de C para B (enlace pontilhado
na Figura 1.14(b)) com capacidade de 6 unidades/s, as unidades de C s ao enviadas dire-
tamente a B, deixando de ocupar o enlace de gargalo. Essa comunicac ao duraria 13,3 s,
por em as outras 420 unidades ainda seriam enviadas pelo enlace de gargalo, com durac ao
da comunicac ao de 42 s. Ao permitir o tr afego de tr ansito, unidades de outras fontes al em
de C podem usar o yway. Neste caso, aplicando-se o algoritmo dos autores, o tempo para
completar as comunicac oes seria reduzido a 312/10 = 188/6 = 31, 2 s, correspondendo
aos envios de 312 unidades no enlace cabeado para B e de 188 unidades no yway.
Um mecanismo simples roteia tr afego atrav es de potenciais m ultiplos caminhos
que s ao realiz aveis com yways. Os yways s ao tratados como enlaces ponto-a-ponto.
Cada caminho no yway transita por exatamente um enlace, logo o tudo que roteamento
precisa fazer e encapsular os pacotes para o endereco da interface apropriada. Por exem-
plo, na Figura 1.14(b), para enviar tr afego atrav es de A-Agregac ao-C-B, os hospedeiros
ligados a A encapsulam pacotes com o endereco da interface yway de C para B. Um
controlador de yways calcula a frac ao do tr afego que deve passar em cada caminho e
retransmite essas decis oes aos hospedeiros. Ao mudar o estabelecimento de um yway, o
encapsulamento e desabilitado e as rotas anteriormente adicionadas s ao removidas.
1.7.2. Deadline-Driven Delivery control protocol (D
3
)
Wilson et al. [Wilson et al., 2011] prop oem o protocolo de controle de envio orientado
a prazo m aximo (Deadline-Driven Delivery control protocol D
3
), um protocolo de ca-
mada de transporte projetado especialmente para redes de comunicac ao internas de cen-
tros de dados. A motivac ao principal do D
3
se deve ao fato de muitas das aplicac oes
de centros de dados requerem um prazo m aximo para a transfer encia de um uxo e a
transfer encia n ao ser necess aria se o prazo n ao for atendido. Por outro lado, protocolos
de transporte tradicionais da Internet n ao levam a vari avel tempo em considerac ao, em
outras palavras, n ao prov eem garantias de tempo m aximo para que um uxo seja enviado.
O protocolo TCP se preocupa, por outro lado, com a transfer encia con avel dos dados e
com o compartilhamento justo da banda passante disponvel nos enlaces de gargalo entre
os uxos TCP dividindo este enlace.
Muitas das aplicac oes atuais de centros de dados pertencem ` a categoria chamada
de aplicac oes de interac ao direta com o usu ario (user-facing applications), ou aplicac oes
de tempo quase-real: os usu arios esperam que a resposta do sistema chegue dentro de
um limite de tempo razo avel, se a resposta do sistema chegar tarde demais, ela e in util
e os recursos da rede e de processamento utilizados para transmitir esta resposta foram
desperdicados. Exemplos destas aplicac oes interativas incluem mecanismos de busca na
web, redes sociais e sistemas de recomendac ao, apenas para citar alguns. Muitas destas
aplicac oes de centros de dados tornam-se escal aveis atrav es do particionamento da tarefa
de responder ` a requisic ao do usu ario entre m ultiplos servidores. Os servidores s ao in-
terconectados atrav es de m aquinas agregadoras, hierarquicamente organizadas, que s ao
respons aveis por combinar os resultados das subtarefas realizadas pelos servidores em
uma resposta a ser enviada ao usu ario. Como consequ encia, para chegar a um tempo de
resposta m aximo visto pelo usu ario, podem ser denidos tempos m aximos para as subta-
refas realizadas pelos servidores, pelos agregadores, e para a transmiss ao da informac ao
entre eles. Outra hip otese importante feita no projeto do D
3
e que uma rede de centro de
dados pertence a uma unica organizac ao, o que signica que o compartilhamento justo da
banda passante, assim como quest oes de seguranca, s ao de menor prioridade, alargando o
espectro de soluc oes possveis para o controle de uxo na camada de transporte.
A ideia b asica do D
3
e transportar tantos uxos de rede quantos forem possveis,
ao mesmo tempo em que o prazo m aximo de cada um deles e garantido. Para garantir
que o prazo m aximo de um uxo seja respeitado, e preciso conhecer o prazo m aximo
do uxo (d) e o tamanho dos uxos (s), por exemplo em bytes. Assim, uma primeira
aproximac ao para garantir o prazo m aximo d e reservar uma taxa de transmiss ao r =
s/d em todos os roteadores ao longo do caminho entre a fonte e o destino. No entanto,
reservar banda passante por uxo nos roteadores possui a desvantagem da quantidade de
estado armazenado na mem oria dos roteadores, o que n ao e escal avel. Os autores do D
3
evitam reservas explcitas observando que uxos de redes de centros de dados possuem
prazos m aximos para completar, mas n ao precisam de uma taxa constante de envio de bits
durante toda sua durac ao. Assim, o D
3
se baseia nos emissores do uxo requisitando e
armazenando as taxas de transmiss ao reservadas com sucesso nos roteadores, em vez de
os roteadores armazenarem esta informac ao. Os roteadores apenas precisam armazenar a
quantidade de uxos com prazo m aximo e a quantidade total de banda passante reservada.
Para acomodar a din amica gerada uma vez que os uxos de rede podem comecar em
instantes diferentes de tempo, as reservas s ao v alidas apenas durante uma janela de tempo,
que no caso da implementac ao do D
3
e igual a um tempo de ida e volta (RTT - round-trip
time).
O algoritmo de controle de taxa do D
3
funciona da seguinte forma. Ao iniciar
um uxo com prazo m aximo, as aplicac oes informam o tamanho e o prazo m aximo do
uxo ao D
3
. A estac ao fonte usa essa informac ao para requisitar inicialmente uma taxa de
envio r = s/d. Esta taxa inicial desejada e encaminhada pelos roteadores na direc ao da
estac ao de destino. Cada roteador ao longo do caminho informa a taxa alocada com su-
cesso de volta para a estac ao fonte, usando o caminho reverso. Assim, a fonte obt em uma
lista das taxas que podem ser alocadas por cada um dos roteadores ao longo do caminho
para o destino, e assim pode concluir qual taxa de envio pode ser utilizada durante aquela
janela de tempo (igual a um RTT). Logicamente, a taxa de envio possvel e a menor das
taxas de envio possveis em todos os roteadores. Como consequ encia, durante o pr oximo
RTT a fonte envia dados a esta taxa e aproveita um dos pacotes de dados para enviar junto
o pedido de taxa de transmiss ao para a pr oxima rodada. A cada RTT, a fonte continua
requisitando taxas de envio aos roteadores, at e que todo o uxo de prazo m aximo tenha
sido transmitido.
Os roteadores tentam alocar, no mnimo, a taxa de transmiss ao requisitada pela
fonte emcada rodada, de forma que os uxos completemo mais r apido possvel. Por outro
lado, se h a banda passante de sobra, o roteador aloca uma taxa para o uxo igual a a =
r+ f s para o uxo de prazo m aximo, onde r e a taxa de transmiss ao atualmente requisitada
e f s e a uma parcela da banda passante de sobra, igual ` a banda passante de sobra dividida
pelo n umero de uxos passando pelo roteador, ou seja, a parcela justa da banda passante
disponvel. Por outro lado, se o roteador n ao tem capacidade disponvel sequer para
satisfazer as demandas de todos os uxos de prazo m aximo, o algoritmo guloso tenta
satisfazer tantos uxos quanto for possvel. Fluxos com prazo m aximo e uxos regulares
que n ao poder ao ser satisfeitos t em, no entanto, atribuda a eles uma taxa de transmiss ao
b asica que permite que eles enviem um pacote de dados a cada RTT, dando-lhes uma
chance de conseguir alocar uma taxa de transmiss ao ao longo do caminho, na pr oxima
rodada. Assim, diminui-se a probabilidade de que estes uxos terminem por inanic ao.
A principal inovac ao do protocolo de transporte D
3
e o algoritmo de alocac ao de
taxas de transmiss ao projetado para garantir que o prazo m aximo dos uxos de rede seja
respeitado. No entanto, o D
3
tamb em fornece o envio de dados con avel e em ordem,
baseando-se em n umeros de sequ encia, reconhecimentos, retransmiss oes baseadas em
temporizadores e algoritmos de controle de uxo, de forma similar ao TCP.
1.7.3. Centros de dados preditivos
Uma das consequ encias diretas do manuseio de grandes massas de dados e o aumento da
complexidade nas operac oes de gerenciamento de redes, tanto no caso de comunicac oes
internas a um centro de dados como entre centros de dados. A n ao ser que o cliente
aceite pagar valores extremamente altos para terem servicos de comunicac ao dedica-
dos [Amazon, 2011], normalmente a soluc ao adotada pelos operadores de centros de
dados consiste em implementar, na pr atica, a t ecnica de sobreinscric ao conforme apresen-
tado na Sec ao 1.5. Nessa t ecnica, os operadores aceitam mais clientes do que o m aximo
nominal do sistema, esperando que os picos de utilizac ao individuais n ao acontecam ao
mesmo tempo. Operadores utilizam c alculos estatsticos de forma a prover o servico pro-
metido aos usu arios e melhorar a utilizac ao dos recursos da rede.
A grande diculdade dos operadores e o balanceamento entre eci encia e sobre-
inscric ao. O gerenciamento do espaco reservado aos clientes se torna uma tarefa com-
plexa quando o n umero de clientes aumenta de forma signicativa. Dois aspectos inuen-
ciam a qualidade do servico oferecido aos clientes. Em primeiro lugar, como os clientes
dividem o mesmo substrato fsico, os tr afegos de dados gerados pelos diferentes clientes
interferem entre eles, principalmente durante momentos em que esses tr afegos atingem
seus valores m aximos. Em segundo lugar, os clientes n ao t em controle sobre o posicio-
namento de suas m aquinas virtuais respectivas. Como resultado, nem os clientes, nem os
operadores s ao totalmente satisfeitos.
A principal ideia dos centros de dados preditivos e de aprimorar a interface entre
os clientes e os provedores de forma a facilitar o gerenciamento dos recursos disponveis
levando-se em conta os desejos de ambas as partes [Ballani et al., 2011]. Na pr atica, os
clientes n ao t em a oportunidade de informar o provedor sobre suas exig encias em termos
de recursos de rede. Essa falta de interac ao e uma das principais causas da variabilidade
da qualidade de servico. Ora, se essa exig encia for explicitamente exposta ao provedor,
este ultimo pode mais facilmente e ecientemente atender seus clientes. Os autores desse
trabalho prop oem o uso de redes virtuais como soluc ao de base e que os clientes espe-
ciquem o n umero e o tipo de m aquinas virtuais, al em de explicitamente denirem a
topologia da rede. Para tal, dois tipos de abstrac oes de topologia de rede s ao propostos,
adotadas em func ao do padr ao de tr afego gerado pelo cliente:
Clusters virtuais. Esta abstrac ao pretende simular redes do tipo usadas em empre-
sas, nas quais os n os s ao conectados por interm edio de uma rede do tipo estrela
(com comutadores Ethernet). A Figura 1.15 ilustra esse tipo de abstrac ao.
Clusters virtuais sobreinscritos. Muitas aplicac oes do tipo em nuvem n ao preci-
sam de uma rede estrita e aceitam uma certa forma de exibilidade com relac ao
a qualidade do servico fornecido. A segunda abstrac ao proposta visa esse tipo de
situac ao, como ilustrado na Figura 1.16.
Os autores prop oem um sistema, chamado Oktopus, que implementa as abstrac oes
acima explicitadas. Neste sistema, os clientes denem os par ametros desejados caso quei-
ram adotar uma das abstrac oes; caso contr ario, n ao precisam denir nada e recebem um
servico do tipo melhor esforco (best effort). Oktopus se baseia em dois componentes que
comutador virtual
maquina
virtual
1
maquina
virtual
2

maquina
virtual
N
Figura 1.15. Abstrac ao do tipo cluster virtual representando uma rede de em-
presa. Neste caso, o cliente pede < N, >, onde N e o n umero de m aquinas
virtuais e e a banda passante entre cada m aquina virtual e o comutador.
s ao o plano de gerenciamento e o plano de dados. Enquanto o plano de gerenciamento e
respons avel principalmente pela implementac ao dos algortmos de alocac ao de recursos,
o plano de dados controla a utilizac ao dos recursos por parte dos clientes.
Atrav es de simulac oes e avaliac oes em ambientes reais, os autores mostram que
as abstrac oes propostas s ao sucientes para representar a maioria dos padr oes de uso em
situac oes reais al em de facilitarem outras funcionalidades como a tarifac ao individual dos
clientes.
1.7.4. Orchestra
Como muitas aplicac oes de aglomerados transferem grandes quantidades de dados en-
tre seus est agios de computac ao, essas transfer encias podem ter um impacto signicativo
no desempenho dos jobs. Chowdhury et al. [Chowdhury et al., 2011] argumentam que
para maximizar o desempenho dos jobs, e necess ario otimizar o desempenho ao nvel
de transfer encias, ao inv es de ao nvel de uxos individuais. Para atacar esse problema,
eles prop oem uma arquitetura de gerenciamento global e um conjunto de algoritmos de-
nominados Orchestra para otimizar o desempenho das transfer encias de dados. Eles
denem uma transfer encia como um conjunto de todos os uxos que transportam dados
entre dois est agios de um job. A Orchestra diminui o tempo de transfer encia de padr oes
de comunicac ao comuns, tais como a difus ao (um-para-muitos) e o padr ao muitos-para-
muitos (shufe), e permite o uso de polticas de escalonamento ao nvel de transfer encias,
tais como o estabelecimento de prioridades para transfer encias.
A Orchestra gerencia transfer encias concorrentes que pertencem a um ou mais
jobs usando um controlador inter-transfer encias (Inter-Transfer Controller - ITC). O ITC
pode reduzir o tempo m edio de transfer encia em um workload de m ultiplas transfer encias,
comparado comquando uxos de transfer encias arbitrariamente compartilhama rede. Por
exemplo, o ITC pode priorizar transfer encias de consultas ad hoc ao inv es de jobs em ba-
telada. O ITC gerencia m ultiplos controladores de transfer encias (Transfers Controllers
- TCs), um para cada transfer encia no aglomerado. Os TCs selecionam o mecanismo a
comutador virtual raiz
maquina
virtual
1
maquina
virtual
2

maquina
virtual
S
maquina
virtual
1
maquina
virtual
2

maquina
virtual
S
maquina
virtual
1
maquina
virtual
2

maquina
virtual
S
S
O
grupo 1 grupo 2 grupo
N
S
comutador virtual
de grupo comutador virtual
de grupo
comutador virtual
de grupo
S
O
S
O
Figura 1.16. Abstrac ao do tipo cluster virtual sobreinscrito usada no caso de
reservas de recursos de redes com sobreinscric ao. Clientes pedem <N, , S, O>,
onde N e o n umero de m aquinas virtuais e e a banda passante entra cada
m aquina virtual e o grupo de comutadores virtuais, S e o n umero de grupos e O
e o fator de sobreinscric ao.
ser usado para as suas transfer encias baseados no tamanho dos dados, no n umero de n os
da transfer encia, nas suas localizac oes e em outros fatores. Eles tamb em ativamente mo-
nitoram e controlam os n os que participam de uma transfer encia. Os TCs gerenciam a
transfer encia na granularidade dos uxos, atrav es da escolha de quantos uxos concor-
rentes devem ser abertos para cada n o, quais destinos devem receber os uxos e quando
deve-se mover cada pedaco de dados. O ITC usa um compartilhamento justo ponderado
(weighted fair sharing) como poltica de escalonamento. A cada transfer encia e associ-
ado um peso e cada enlace congestionado na rede e compartilhado proporcionalmente ao
peso das transfer encias que passam por aquele enlace. Quando uma aplicac ao quer reali-
zar uma transfer encia, ela invoca uma API que lanca um TC para aquela transfer encia. O
TC se registra no ITC para obter sua parte no compartilhamento da rede. O ITC periodica-
mente consulta uma poltica de escalonamento para associar fatias no compartilhamento
` as transfer encias ativas e envia essas fatias aos TCs. Cada TC pode dividir sua parte en-
tre seus pares fonte-destino como quiser. O ITC tamb em atualiza o compartilhamento
de transfer encias periodicamente em func ao de mudancas no conjunto de transfer encias
ativas. Finalmente, cada TC solicita a eliminac ao do registro quando a sua transfer encia
acaba.
Adifus ao corresponde ao padr ao de comunicac ao um-para-muitos entre sequ encias
de est agios de processamento. Para transfer encias em difus ao, os autores prop oem um TC
que implementa um protocolo otimizado parecido com o BitTorrent denominado Cornet.
Esse protocolo inclui um algoritmo de agrupamento adaptativo de forma a tirar vanta-
gem da alta velocidade e da baixa lat encia nas tpicas topologias de centros de dados, da
aus encia de pares egostas e do fato de n ao haver n os maliciosos que podem modicar os
dados. Diferentemente do BitTorrent, n ao existe subdivis ao em blocos e grandes blocos
(4 MB por padr ao) s ao utilizados, cada n o usa sua capacidade total durante todo o tempo
da transfer encia e e realizada uma unica vericac ao da integridade sobre os dados.
Para as transfer encias do padr ao muitos-para-muitos, os autores prop oem um
algoritmo otimo denominado WSS (Weighted Shufe Scheduling). Considerando uma
comunicac ao muitos-para-muitos na qual um receptor r
i
precisa obter d
i j
unidades de da-
dos do transmissor s
j
, o WSS aloca taxas para cada uxo usando o compartilhamento
justo ponderado, de forma que o peso do uxo entre r
i
e s
j
seja proporcional a d
i j
.
A Orchestra pode ser implementada em nvel de aplicac ao e sobreposta acima
de diversas topologias de roteamento, esquemas de controle de acesso e camadas de
virtualizac ao. Essa abordagem permite ` a Orchestra ser utilizada em aglomerados j a exis-
tentes sem a necessidade de modicac oes em roteadores e comutadores.
1.7.5. NetLord
O principal objetivo do NetLord [Mudigonda et al., 2011] e reduzir a carga de gerenci-
amento em centros de dados de pequenas e m edias empresas. O NetLord simplica as
tarefas de gerenciamento atrav es do uso da infraestrutura em nuvem ao inv es do uso de
uma infraestrutura local em uma empresa. Como consequ encia, e possvel evitar despe-
sas de gerenciamento relacionadas a grandes tarefas computacionais ou relacionadas ` a
manutenc ao de grande estrutura de equipamentos e de funcion arios de rede. Ao trans-
ferir os servicos do centro de dados para a nuvem, as despesas s ao reduzidas porque os
provedores do servico podem otimizar o uso dos pr oprios recursos atrav es dos m ultiplos
clientes. Essa otimizac ao e atingida com a virtualizac ao do substrato fsico usando hi-
pervisores como o Xen [Egi et al., 2007]. Assim, o uso de m ultiplas m aquinas virtuais
leva ao compartilhamento do substrato fsico, o que evita a subutilizac ao dos recursos.
O benefcio da reduc ao dos custos se torna mais evidente caso haja um grande n umero
de clientes compartilhando a mesma infraestrutura fsica. Entretanto, o gerenciamento
da nuvem e complexo e ferramentas automatizadas para congurac ao e operac ao devem
ser propostas. O maior desao torna-se gerenciar o compartilhamento dos recursos e,
ao mesmo tempo, garantir qualidade de servico em grandes escalas. Nessa direc ao, o
NetLord tem por objetivo aprimorar os servicos em nuvem focando em tr es pilares prin-
cipais: reduc ao dos custos com a escala, aprimoramento do suporte a multiusu arios e
simplicac ao das tarefas administrativas da rede. A principal raz ao para a escolha desses
tr es pilares vem da observac ao sobre o desempenho dos centros de dados. O argumento
usado e que muito da eci encia dos centros de dados e desperdicada com congurac oes
manuais e com sobrecarga operacional desnecess aria inserida por soluc oes mal adaptadas.
A ideia chave do NetLord e utilizar o encapsulamento em quadros da camada
de enlace (Camada 2) para transfer encia de pacotes atrav es do uso de comutadores es-
cal aveis. Para isso, o NetLord usa uma combinac ao de encapsulamento em Camada 2
e 3, ou seja, ele usa respectivamente o Ethernet e o IP para combinar os benefcios de
ambas as camadas. Cada cliente deve, ent ao, ter m aquinas virtuais conguradas com
enderecos MAC, atribudos a partir de um espaco de enderecamento privado, e enderecos
IP, que n ao possuem restric oes. O encapsulamento permite a utilizac ao de um unico
endereco MAC nas m aquinas virtuais do cliente e um endereco MAC univocamente re-
lacionado na rede entre os clientes. Tal abordagem e semelhante ` a utilizada pelo LISP
(Loc/ID Split Protocol), cuja diferenca e usar enderecos de rede ao inv es de enderecos
MAC [Saucez et al., 2009].
O encapsulamento permite que todos os enderecos de m aquinas virtuais sejam
escondidos dentro de uma rede local atrav es do uso externo do endereco do comutador
de borda da rede. Esse procedimento e similar ao tunelamento, comumente utilizado
na Internet. Observe que a execuc ao de m ultiplas m aquinas virtuais levaria a tamanhos
maiores de tabelas de encaminhamento (Forwarding Information Base - FIB) porque ha-
veria um n umero maior de enderecos MAC inseridos pelas m ultiplas m aquinas virtuais.
O encapsulamento, entretanto, permite a reduc ao dos tamanhos das FIBs, que e um re-
quisito importante de escalabilidade. Um efeito indireto do encapsulamento e a reduc ao
da sobrecarga de gerenciamento da rede que diminui a complexidade de manutenc ao e
operac ao. O encapsulamento tamb em atribui benefcios ` a camada de rede atrav es do uso
de um identicador de cliente. Esse identicador e inserido no cabecalho externo da ca-
mada de rede que pode ser visto na rede entre as redes dos clientes. Esse identicador
pode ser usado para prover servicos personalizados.
Um desao acarretado pelo encapsulamento e a garantia de conectividade m-a-
m entre as m aquinas virtuais (Virtual Machines - VMs). O NetLord prop oe o uso do
Agente NetLord (NetLord Agent - NLA), em execuc ao no hipervisor da m aquina virtua-
lizada para realizar o encapsulamento e assegurar a correta entrega dos pacotes. A ac ao
do NLA durante o encaminhamento depende se o destino est a sendo executado na mesma
m aquina fsica ou n ao. Como todo cliente anuncia ao NetLord os conjuntos de enderecos
IP que possui e os enderecos MAC correspondentes, o NLA pode identicar se o destino
est a executando na mesma m aquina. Sempre que uma m aquina virtual (VM) envia um pa-
cote, o seu NLA local intercepta o pacote e extrai dele o cabecalho IP e MAC para checar
se os enderecos pertencem a algum dos seus clientes. Caso pertenca, o NLA encapsula
o pacote e o envia ao destino nal. Caso contr ario, se a busca n ao for bem sucedida e o
destino n ao estiver sendo executado na mesma m aquina fsica, o NLA deve encapsular o
pacote contendo toda a informac ao necess aria para que o NLA do destino possa identi-
car de forma unvoca a interface de rede virtual do destino. Essa informac ao e obtida a
partir de uma tupla contendo o endereco MAC do destino, o identicador do cliente do
destino e o identicador do espaco de enderecos MAC (MAC Address Space ID - MAC
AS ID) atribudo tamb em ao destino. Esses dados s ao inseridos no cabecalho do pacote,
respectivamente, no lugar do endereco MAC de destino original no cabecalho Ethernet,
no campo do endereco IP do destino e no campo do endereco IP da origem.
A Figura 1.17 ilustra o cabecalho Ethernet externo usando como os seus enderecos
MAC de origem e destino, os enderecos MAC de origem e destino dos comutadores de
borda da rede, ou seja, do comutador de borda (Edge Switch - ES) da origem e do comu-
tador de borda (Edge Switch - ES) do destino. Na mesma gura, e tamb em apresentado o
campo VLAN (Virtual Local Area Network), usado para sinalizar opc oes adicionais como
o uso de encaminhamento por m ultiplos caminhos. Ao receber o pacote, o comutador de
borda do destino desencapsula o cabecalho Ethernet externo e procura o endereco IP de
destino na sua tabela de encaminhamento para vericar se possui uma entrada correspon-
dente. Caso a encontre, as informac oes do NLA do pr oximo salto s ao obtidas e outro
cabecalho Ethernet e adicionado para garantir o encaminhamento correto do pacote at e o
NLA do destino. O NLA do destino identica o cliente baseado no cabecalho IP e pode
ainda identicar a m aquina virtual de destino ap os desencapsular completamente o pacote
recebido. Finalmente, o pacote e entregue para a interface virtual do destino.
Figura 1.17. Procedimentos de encapsulamento e desencapsulamento utilizados
pelo NetLord durante o encaminhamento de pacotes.
O NLA da fonte requer informac oes sobre o endereco MAC do comutador de
borda remoto e o n umero da porta para encapsular o pacote a ser enviado. Al em disso,
ele precisa mapear a interface da m aquina virtual do destino ao comutador de borda do
destino. Para realizar essa tarefa, um protocolo semelhante ao ARP (NetLord-Address
Resolution Protocol - NL-ARP) e usado para manter uma tabela em cada hipervisor, que
e consequentemente, acessvel aos NLAs. Sempre que uma m aquina virtual desejar enviar
um pacote, a informac ao sobre o comutador de borda do destino pode estar armazenada
em uma tabela local. Caso a informac ao n ao esteja disponvel, uma requisic ao NL-ARP
e realizada. Para evitar requisic oes sucessivas, o mapeamento entre as interfaces das
m aquinas virtuais e os comutadores de borda e mantido permanentemente ao acesso de
todos os NLAs atrav es do uso de uma estrat egia pr o-ativa. Sempre que um mapeamento
e alterado, essa informac ao e enviada para todos os NLAs da rede.
1.7.6. Eliminac ao de tr afego redundante
Outra forma de reduzir o custo da banda passante e atrav es da aplicac ao de t ecnicas de
eliminac ao de tr afego redundante (Trafc Redundancy Elimination - TRE). Aredund ancia
no tr afego surge dos comportamentos dos usu arios da nuvem, tais como repetidamente
baixar e distribuir o mesmo conte udo ou conte udo similar (por exemplo, texto, imagem,
vdeo etc.). Zohar et al. [Zohar et al., 2011] prop oem um novo sistema de TRE deno-
minado PACK (Predictive ACK). Diferentemente de outras soluc oes de TRE, o PACK
e baseado em uma abordagem orientada ao receptor. Com isso o transmissor n ao ne-
cessita manter de forma contnua os status dos receptores. O PACK permite ao receptor
utilizar os rec em recebidos pedacos da dados para identicar correntes de pedacos previa-
mente recebidos, as quais podem ser usadas como preditores con aveis de pedacos ainda
a serem transmitidos. Atrav es da utilizac ao de informac ao de meta-dados mantida local-
mente, o receptor envia ao transmissor as predic oes que incluem assinaturas de pedacos e
informac oes f aceis de serem vericadas dos dados a serem transmitidos. No caso de uma
correspond encia das informac oes, o transmissor dispara a operac ao de TRE.
Essa abordagem e detalhada a seguir. Quando chegam novos dados, o receptor
calcula a assinatura de cada pedaco e procura uma correspond encia com os dados arma-
zenados localmente. Se uma correspondente assinatura de pedaco e encontrada, o recep-
tor determina se ela e parte de uma sequ encia anteriormente recebida de pedacos sub-
sequentes, denominada uma corrente, atrav es da vericac ao dos meta-dados do pedaco
que incluem a assinatura do pedaco e um ponteiro para o pedaco sucessivo na ultima cor-
rente recebida que cont em aquele pedaco. Usando a corrente construda, o receptor envia
a predic ao ao transmissor relativa aos dados subsequentes. Parte de cada predic ao de
pedaco, denominado um palpite (hint), e uma func ao f acil de ser calculada com um valor
pequeno o suciente de falsos positivos, tal como uma soma de vericac ao (checksum)
dos dados usando um ou-exclusivo byte-a-byte. A predic ao enviada ao transmissor inclui
o intervalo dos dados preditos, o palpite e a assinatura daquele pedaco. O transmissor
identica o intervalo predito em seu buffer de dados e verica o palpite para aquele in-
tervalo. Se o resultado corresponde ao palpite recebido, o transmissor realiza a operac ao
SHA-1 ((Secure Hash Algorithm) mais intensiva computacionalmente e a compara ` a as-
sinatura recebida na predic ao. Se h a uma correspond encia das assinaturas, o transmissor
envia uma mensagem de conrmac ao ao receptor, permitindo a ele copiar os dados cor-
respondentes de seu armazenamento local.
Al em da operac ao orientada a receptor, os autores tamb em prop oem o uso de
uma abordagem orientada a transmissor em alguns casos. Usando a abordagem baseada
no receptor, quando os dados s ao espalhados, as sequ encias de predic oes s ao frequen-
temente interrompidas at e que uma nova correspond encia seja encontrada no receptor e
comunicada ao transmissor. Esse tipo de dados torna o modo de TRE menos eciente.
Permitindo ao PACK reconhecer uma sequ encia de mudancas dispersas, ele pode esco-
lher acionar uma abordagem baseada no transmissor. Al em disso, quando um dispositivo
m ovel alimentado por bateria e usado, o PACK pode deslocar a sobrecarga de computac ao
do TRE de volta para a nuvem (transmissores) atrav es do acionamento do TRE baseado
no transmissor.
1.7.7. Roteamento por m ultiplos caminhos
A tecnologia de rede tipicamente utilizada em centros de dados e o Ethernet. Suas prin-
cipais vantagens s ao o poder de auto-congurac ao, as t ecnicas para comutac ao r apida
que permitem operar em dezenas de Gb/s e o baixo custo da infraestrutura e equipe de
administrac ao da rede. Entretanto, muitas redes Ethernet operam baseadas em topologias
do tipo arvores de espalhamento (spanning tree) que concentram o tr afego nos enlaces
e comutadores selecionados. Por conseguinte, essa concentrac ao pode impactar a esca-
labilidade da rede. Uma soluc ao para melhorar o desempenho e a divis ao da rede em
sub-redes conectadas atrav es de roteadores. Essa alternativa melhora o desempenho ao
aliviar o tr afego dos possveis enlaces congestionados, especialmente se considerado que
os centros de dados podem ter milhares de m aquinas. Apesar de realmente aumentar
a escalabilidade, o uso de roteadores requer equipamentos adicionais, o que pode levar
a custos mais elevados. Outra possibilidade surge com as t ecnicas de virtualizac ao que
possivelmente precisariam de exibilidade suciente para alterar a topologia da rede sob
demanda, ou seja, atrav es da migrac ao de m aquinas virtuais de uma sub-rede para outra.
A migrac ao de m aquinas virtuais entre diferentes redes e um problema conhecido, se a
manutenc ao da topologia original for um pr e-requisito [Wang et al., 2008].
Uma abordagem para aprimorar o desempenho da Ethernet, atendendo a todos
os requisitos acima citados, e o encaminhamento por m ultiplos caminhos. Uma con-
sequ encia comum desse tipo de encaminhamento e, entretanto, a substituic ao de todos os
equipamentos de prateleira por equipamentos especiais com funcionalidades adicionais.
Essa contrapartida n ao e desej avel e deve ser contornada pelo uso de t ecnicas de rede que
possibilitem o uso dos m ultiplos caminhos em centros de dados [Mudigonda et al., 2010]
sem a necessidade de aquisic ao de novos equipamentos. O SPAIN (Smart Path Assign-
ment In Networks) [Mudigonda et al., 2010] prop oe o uso de um controlador central de
rede para calcular ofine todos os m ultiplos caminhos disponveis, e assim, melhorar a
redund ancia da rede. O objetivo e aumentar tanto a vaz ao de bissec ao quanto a toler ancia
a falhas em centros de dados. Todos os caminhos calculados s ao combinados em um con-
junto de arvores que s ao mapeadas individualmente em uma VLAN (Virtual Local Area
Networks). Como a maioria dos comutadores de prateleira prov e suporte a VLANs, esse
requisito n ao afetaria os custos da rede. O controlador central do SPAIN deve aprender
a topologia atual e congurar individualmente as VLANS calculadas em seus respectivos
comutadores. O conhecimento da topologia e obtido utilizando o protocolo LLDP (Link-
Layer Discovery Protocol) enquanto a congurac ao dos comutadores e obtida atrav es do
controlador central que programa as VLANs em cada comutador.
Figura 1.18. M ultiplas arvores calculadas pelo SPAIN. Cada uma das arvores e
mapeada em uma VLAN, entre as quais a VLAN
1
cobre todos os n os.
Todas as VLANs s ao conguradas nos comutadores da rede com o objetivo de
maximizar a utilizac ao dos enlaces fsicos. Portanto, todos os servidores podem usar
as diferentes VLANs para diferentes uxos. A Figura 1.18 ilustra uma topologia sim-
ples composta de duas arvores alternativas, chamadas de VLAN
1
e VLAN
2
. No SPAIN,
pelo menos uma VLAN deve conectar todos os n os por quest oes de conabilidade e, por
padr ao, usa-se a VLAN
1
para isso. Considerando que todas as VLANs j a estejam progra-
madas no exemplo, os Servidores A e B e os Servidores C e D j a poderiam se comunicar
usando caminhos com enlaces disjuntos, o que n ao seria possvel usando a abordagem
tpica que envolve as arvores de espalhamento. O SPAIN, portanto, evita particionamen-
tos da rede em m ultiplas sub-redes IP e n ao requer nenhuma topologia em especial como
a Fat-Tree ou um Hipercubo.
Deve-se mencionar que os centros de dados virtualizados j a prov eem suporte
ao encaminhamento por m ultiplos caminhos (ex. o NetLord [Mudigonda et al., 2011]).
Logo, explorar os m ultiplos caminhos fsicos deve ser considerado nas camadas superio-
res. Esse e uma conclus ao importante especialmente ao utilizar o TCP e seu conhecido
problema de reordenac ao de pacotes. Apesar do SPAIN j a considerar essa quest ao, h a ou-
tros trabalhos mais focados na operac ao do TCP em centros de dados que empreguem en-
caminhamento por m ultiplos caminhos. O MPTCP (MultiPath TCP) [Raiciu et al., 2010,
Raiciu et al., 2011] e um exemplo que divide um unico uxo em m ultiplos subuxos en-
tre o par origem-destino da comunicac ao. Ele se baseia na possibilidade dos m ultiplos
caminhos existirem e serem descobertos pelo protocolo de roteamento da camada infe-
rior. O desao que surge e o mecanismo de controle de congestionamento, originalmente
projetado para a operac ao do TCP com apenas um uxo. O MPTCP, portanto, acopla
o mecanismo de controle de congestionamento aos m ultiplos caminhos, concentrando
tr afego nos subuxos que atravessam os caminhos menos congestionados. Globalmente,
o tr afego da rede se torna mais balanceado, o que leva ao aumento do desempenho geral.
O uso do MPTCP e denido durante o estabelecimento de conex ao, quando o
servidor anuncia ao cliente se possui ou n ao mais enderecos IP. Os m ultiplos subuxos
s ao iniciados usando diferentes enderecos IP ou, no pior caso, usando o mesmo par de
enderecos IP, mas diferentes portas. Ap os o estabelecimento dos diferentes subuxos,
o n o de origem divide os dados entre eles e utiliza opc oes adicionais do TCP para que
os dados sejam reordenados na recepc ao. Uma vez divididos em m ultiplos subbuxos,
cada um mantem o seu pr oprio espaco de n umeros de sequ encia e a sua pr opria janela de
contenc ao. Cada subuxo pode, ent ao, se adaptar individualmente ` as condic oes do ca-
minho percorrido. Assim, um subuxo que encontre congestionamentos pode ajustar os
seus pr oprios par ametros para reduzir a inserc ao de tr afego, enquanto os subuxos atra-
vessando caminhos menos congestionados podem aumentar as suas taxas de transmiss ao.
A rede, como consequ encia, melhora balanceamento de carga de forma natural.
(a) TCP original. (b) MPTCP.
Figura 1.19. Diferenc a entre o TCP que usa um unico caminho e o MPTCP com
m ultiplos caminhos. O TCP concentra carga no enlace A, enquanto o MPTCP
realiza um melhor balanceamento de carga entre os diferentes enlaces da rede.
O uso do TCP para m ultiplos caminhos pode aumentar a vaz ao agregada da rede
em centros de dados sem o comprometimento das topologias fsicas, como e necess ario
com o Fat-Tree [Al-Fares et al., 2008] ou BCube [Guo et al., 2009]. Essa caracterstica e
relevante para poupar os administradores de redes do uso de topologias xas.
1.7.8. Interconex ao do centro de dados com pontes
Duas tecnologias s ao proeminentes na interconex ao dos servidores em centros de dados, o
Ethernet e a Fibre Channel. A Ethernet e a tecnologia mais usada e continua com desem-
penho crescente de 10, para 100 e 1000 Mb/s e agora para 10, 40 e 100 Gb/s. Por outro
lado, a Fibre Channel est a em 16 Gb/s e com maiores diculdades para escalar. Assim, a
Ethernet vem se tornando cada vez mais comum e foi desenvolvido o Fibre Channel over
Ethernet (FCoE) para encapsular os quadros do Fibre Channel em quadros Ethernet. No
entanto, a tecnologia Ethernet segue o modelo de melhor esforco e e menos con avel que
a tecnologia Fibre Channel, podendo perder pacotes quando os dispositivos receptores
est ao ocupados e n ao conseguem receber na taxa que lhe e transmitida. Quando o Ether-
net e usado, de uma maneira geral, a recuperac ao de quadros perdidos e deixada para os
protocolos das camadas superiores, na Internet, por exemplo, as perdas s ao recuperadas
pelo TCP. No entanto, nos centros de dados, deixar a recuperac ao dos quadros perdidos
para o TCP n ao e conveniente, por causa do seu baixo desempenho devido ` a complexi-
dade e ao grande custo operacional. Pode-se dizer que e mais r apido e melhor reagir a
congestionamentos e recuperar perdas de pacotes na camada de enlace do que esperar
para faz e-lo na camada de transporte pelo TCP. No caso de centro de dados, isso se torna
crucial por causa das altas taxas.
Em decorr encia das deci encias do uso do Ethernet em centros de dados, uma
s erie de normas relativas ` a interconex ao de Centro de Dados com Pontes (Data Center
Bridging - DCB) est ao em desenvolvimento para evitar congestionamentos e eliminar as
perdas de quadros em ambiente de centros de dados. Quatro tecnologias procuram melho-
rar as propriedades da rede Ethernet: Controle de Fluxo baseado em Prioridade (Priority-
based Flow Control - PFC) [Hugh Barras et al., 2008], Selec ao Aperfeicoada de Trans-
miss ao (Enhanced Transmission Selection) [Manoj Wadekar et al., 2008b], Troca DCB
(DCB Exchange) [Manoj Wadekar et al., 2008a] e Noticac ao de Congestionamento (Con-
gestion Notication) [CN, 2009]. O Controle de Fluxo baseado em Prioridade (Priority-
based Flow Control - PFC), tamb em conhecido como PAUSA por prioridade, denido na
norma IEEE 802.1Qbb [Hugh Barras et al., 2008], e um mecanismo usado quando uma
estac ao deseja que um dado uxo de quadros recebido seja interrompido temporaria-
mente. O mecanismo PCF indica um tempo de pausa em quanta para cada uma das
oito classes de prioridade separadamente, diferente do quadro de PAUSA convencional
que inibia a transmiss ao de todos os quadros de forma indiscriminada. O PCF acrescenta
campos que permitem identicar cada classe de prioridade e, assim, selecionar qual ou
quais delas devem ser inibidas. Para tal, um quadro de pausa PCF cont em um vetor com
oito campos que inclui dois octetos de campo de habilitac ao do vetor de prioridade (pri-
ority enable vector Field) e dois octetos de campo do vetor de tempo (octet time vector
eld). O valor do tempo e medido em unidade de pause quanta que e igual a 512 vezes o
tempo do bit de uma camada fsica particular.
O mecanismo Selec ao Aperfeicoada de Transmiss ao (Enhanced Transmission Se-
lection - ETS), denido pela norma IEEE 802.1Qaz [Manoj Wadekar et al., 2008b], prove
um modelo operacional para processamento de prioridade e alocac ao de banda, em termos
de percentagem da banda total, em enlaces convergentes de comutadores e estac oes. O
mecanismo ETS introduz um novo campo de 4 bits chamado Priority Group ID (PGID).
Assim, tem-se 16 valores de PGID sendo que o valor PGID=15 e especial e signica
Figura 1.20. Operac ao da troca DCB (DCB Exchange) com priorizac ao de tr afego
e reserva de banda.
sem nenhum limite de banda passante e os valores 8-14 s ao reservados. Cada PGID
e alocado como um percentual da banda disponvel no enlace, onde banda disponvel se
refere ao valor m aximo percentual disponvel depois das prioridades com PGID=15 se-
rem alocadas. Portanto, usando processamento com prioridade e alocac ao de banda e
possvel a congurac ao de diferentes classes de tr afego, tais como: LAN, SAN, IPC e
gerenciamento, para prover caractersticas de transmiss ao com baixa lat encia. Para que
esses objetivos sejam atendidos os dispositivos devem suportar (i) a atribuic ao de priori-
dades em grupos de prioridades (Priority Groups), como por exemplo 40% LAN, 40%
SAN e 20% IPC de alocac ao de banda passante para cada grupo de tal forma que a prio-
ridade atenda a demanda por um certo comportamento; (ii) o escalonamento da ocupac ao
de um enlace para minimizar o impacto da converg encia em um unico enlace ao mesmo
tempo; (iii) a coexist encia de tr afego de baixa lat encia com tipos de tr afegos que deman-
dam alta banda passante e s ao sensveis a perda e (iv) uma plataforma de gerenciamento
para congurac ao via objetos MIB.
Na Figura 1.20, tr es classes de tr afego s ao agrupados em dois grupos distintos,
um grupo de alta prioridade e um de baixa prioridade. O tr afego IPC, de alta prioridade e
totalmente atendido, enquanto os dois tr afegos de baixa prioridade, LAN e SAN, dividem
igualmente a banda passante restante.
A Troca DCB (Data Center Bridging eXchange - DCBX), denido na norma
IEEE 802.1Qaz [Manoj Wadekar et al., 2008a], e um protocolo de descoberta de capaci-
dades que e usado para adequar capacidades e congurac oes entre n os diretamente conec-
tados por enlaces, de forma a garantir congurac oes consistentes atrav es da rede. O DCB
usa o protocolo de descoberta de enlaces (Link Layer Discovery Protocol - LLDP) para
troca par ametros. A noticac ao de congestionamento (Congestion Notication - CN),
denida na norma 802.1Qau [CN, 2009], e um mecanismo para transmitir informac ao
de congestionamento m-a-m por uxo. A nvel de enlace, um quadro de pausa traz
como consequ encia uma propagac ao de congestionamento do uxo que e pausado, pro-
vocando gargalos secund arios. Logo, um algoritmo de controle de congestionamento na
Camada 2 permite que um gargalo prim ario reduza diretamente a taxa das fontes gera-
doras do tr afego evitando gargalos secund arios. A noticac ao de congestionamento e
dividida em dois algoritmos: Congestion Point Dynamics (CP) e Reaction Point Dyna-
mics (RP).
Todos os protocolos apresentados se destinam a tornar a tecnologia Ethernet mais
con avel e praticamente sem perdas de pacotes, atendendo a exig encia de interconex ao
de centros de dados.
1.7.9. Transparent Interconnection of Lots of Links (TRILL)
O Ethernet foi originalmente projetado para ser usado em um barramento e depois em
uma topologia em estrela, com estac oes conectadas atrav es de um unico enlace restrito a
um alcance m aximo de alguns poucos quil ometros em barramento e a em estrela poucas
centenas de metros. Com o intuito de permitir a criac ao de redes maiores, tanto em al-
cance quanto no n umero de estac oes, foram criadas as pontesque encaminham quadros
Ethernet entre diferentes enlaces. No entanto, os mecanismos criados para encaminhar
quadros Ethernet atrav es de pontes, na camada de enlace, n ao t em todas as caractersticas
necess arias para o encaminhamento como ocorre no roteamento efetuado na camada di-
retamente superior, pelo protocolo IP . Os principais desaos do encaminhamento na
camada de enlace s ao a aus encia de um campo de contagem de saltos no cabecalho Ether-
net; a forma plana de enderecamento do protocolo Ethernet que, por isso, n ao reete a
localizac ao dos n os e n ao permite a agregac ao de enderecos; e a aus encia de protocolos
de descoberta de novos n os e de protocolos de roteamento em camada de enlace. Logo,
foi adotada uma maneira simples de encaminhar os quadros na camada de enlace cha-
mada comutac ao transparente. Os n os encaminhadores aprendem por qual porta uma
determinada estac ao nal e acessvel e passam a utilizar essa porta para encaminharem
tr afego para essa estac ao. No entanto, esse m etodo funciona somente quando h a apenas
um caminho entre quaisquer pares de n os nais. Assim, para permitir o funcionamento do
encaminhamento em camada de enlace para topologias arbitr arias, foi criado o algoritmo
de arvore de cobertura (spanning tree) [Touch e Perlman, 2009]. O algoritmo de arvore
de cobertura garante a formac ao de caminhos na rede sem lacos ao custo de desativar
enlaces da rede fsica, fazendo com que todo o tr afego da rede que restrito a um unico
caminho. Outra limitac ao desse algoritmo e a sua instabilidade. A perda de conectivi-
dade em um enlace pertencente ` a arvore de cobertura pode signicar o rec alculo de toda
a arvore e consequentes mudancas em toda a sua organizac ao [Touch e Perlman, 2009].
Dessa forma, o algoritmo de arvore de cobertura apresenta comportamento inst avel em
redes extensas interligadas por comutadores.
Uma proposta para realizar o encaminhamento de pacotes na camada de enlace,
com suporte a m ultiplos caminhos e sem a necessidade de se denir uma arvore de cober-
tura, e o TRILL (Transparent Interconnection of Lots of Links), um protocolo padronizado
pelo IETF (Internet Engineering Task Force) que aplica t ecnicas de roteamento da camada
de rede para criar a interconex ao de redes, na camada de enlace [Touch e Perlman, 2009,
Perlman et al., 2011]. A interconex ao dos enlaces e feita de forma transparente para o
protocolo IP. Os enlaces interconectados pelo TRILL s ao vistos pela camada de rede
como uma unica sub-rede IP. O TRILL encapsula, com um cabecalho pr oprio, os qua-
dros Ethernet a serem encaminhados. Como o quadro Ethernet e mantido inalterado, o
TRILL garante as funcionalidades da camada de enlace, como VLAN (Virtual Local Area
Network), e permite o uso de multicast e broadcast.
O TRILL permite a autocongurac ao da camada de enlace, assim como o Ether-
net, mas tamb em permite o uso de t ecnicas de roteamento como as da camada de rede.
Os equipamentos de rede que implementam o TRILL s ao chamados de Routing Bridges
ou RBridges. A ideia central de uma RBridge e agir como um comutador Ethernet para as
estac oes nais, mas que no n ucleo da rede e capaz de rotear os pacotes encapsulados pelo
TRILL como se fosse o roteamento da camada de rede. As RBriges podem coexistir com
os comutadores Ethernet. Quanto maior o n umero de RBridges em relac ao ao n umero
de comutadores Ethernet, menores s ao as arvores de cobertura denidas entre os comu-
tadores. Consequentemente, menos enlaces s ao desativados, melhorando o uso da banda
passante disponvel na rede.
O funcionamento do TRILL ocorre da seguinte forma [Perlman et al., 2011]. Ao
iniciar uma rede TRILL, as RBridges escolhem identicadores aleat orios e os divulgam.
Se um identicador escolhido j a estiver em uso por outra RBridge, um novo identica-
dor e escolhido. As RBridges executam um protocolo de roteamento de estado do enlace
que permite ` as RBridges conhecerem a topologia da rede e calcularem o caminho mais
curto entre duas RBriges. O encaminhamento dos quadros entre os n os TRILL e baseado
no cabecalho de encapsulamento que apresenta tr es campos principais. O primeiro e o
ingress RBridge que cont em o identicador da RBridge de entrada na rede TRILL. O se-
gundo e o egress RBridge que cont emo identicador da RBridge de destino do pacote. Por
m, o campo hop count guarda a contagem de saltos do pacote na rede TRILL para evitar
o encaminhamento dos pacotes em lacos. H a ainda uma marcac ao no cabecalho que iden-
tica se o pacote tem m ultiplas destinac oes ou e um pacote com destinac ao unica. Cada
RBridge est a conectada a um conjunto de estac oes nais, como se fosse um comutador
Ethernet. Quando uma estac ao nal envia um quadro Ethernet para a RBridge, esta ve-
rica a destinac ao do quadro. Caso o destino do quadro esteja associado a uma RBridge
conhecida, a RBridge que recebeu o quadro, o encapsula com o cabecalho TRILL e o
envia na rede. Caso o quadro que chega ` a RBridge tenha como destino uma estac ao as-
sociada a uma RBridge desconhecida, ou caso seja um quadro de broadcast/multicast,
marca-se o quadro com m ultiplas destinac oes e o quadro e inundado na rede. Ao chegar
na RBridge de destino, o quadro e desencapsulado, resgata-se o quadro Ethernet original
e este e entregue ` a estac ao nal de destino, de maneira transparente para as estac oes.
O protocolo de estado de enlace que executa entre as RBridges e o IS-IS (Interme-
diate System - Intermediate System). Esse protocolo e o mais adequado para o cen ario do
TRILL, pois executa diretamente na camada de enlace, ao contr ario do OSPF que executa
sobre o IP, e permite a criac ao de novos campos na divulgac ao das informac oes do enlace.
1.7.10. Distributed Overlay Virtual Ethernet (DOVE)
A tend encia atual para a organizac ao de sistemas de comunicac ao de centros de dados e
tratar os servidores virtuais como estac oes nais da rede fsica. Dessa forma, o n umero
de estac oes nais conectadas na rede do centro de dados cresce substancialmente, em
relac ao ` a interconex ao de somente servidores fsicos, aumentando a complexidade da
rede. Assim, as redes dos centros de dados necessitam de mais investimentos, aumen-
tando a quantidade de comutadores disponveis ou aumentando a capacidade dos existen-
tes, seja em termos de mem oria disponvel, seja em termos de aprendizagem de novos
enderecos MAC. Por outro lado, as cargas de trabalho dos centros de dados podem variar
dependendo de fatores externos e dos requisitos de aplicac ao que executam no centro de
dados. Hoje, a infraestrutura de rede dos centros de dados permanece est atica mesmo
com as mudancas de carga de trabalho. Portanto, da mesma forma como a virtualizac ao
de computadores permitiu o melhor compartilhamento dos recursos computacionais oci-
osos, uma proposta para melhor compartilhar a rede de centros de dados e atrav es da
virtualizac ao. O uso da virtualizac ao de redes permite criar redes virtuais independentes
das caractersticas da infraestrutura fsica, isolando umas das outras, de forma din amica,
congur avel e gerenci avel.
O Distributed Overlay Virtual Ethernet (DOVE) [Barabash et al., 2011] e uma
proposta de arquitetura de virtualizac ao de protocolos para centro de dados que prov e
isolamento entre redes virtuais, capacidade de recongurac ao din amica da rede e de ge-
renciamento da rede virtual, independentemente da infraestrutura fsica preexistente no
centro de dados. A arquitetura DOVE permite a criac ao de redes virtuais com espacos de
enderecamentos isolados e din amicas sobre uma infraestrutura fsica comum. Ofunciona-
mento do DOVE baseia-se no encapsulamento de pacotes e na criac ao de uma rede de so-
brecamada para permitir a separac ao entre a rede virtual e a rede fsica subjacente. Assim
que s ao enviados por uma m aquina virtual, os quadros Ethernet s ao tratados pelo servidor
fsico que hospeda tal m aquina virtual. O servidor fsico, ent ao, encapsula os quadros
Ethernet que deixam uma m aquina virtual em um pacote UDP, que tamb em possui um
cabecalho DOVE. Os pacotes encapsulados possuem um campo para a marcac ao de qual
rede virtual tal pacote pertence. Os pacotes encapsulados, por sua vez, s ao enderecados
ao IP do servidor fsico que hospeda a m aquina virtual de destino. No caso de pacotes de
difus ao (broadcast ou de multicast), o pacote encapsulado e enviado a todos os servidores
fsicos que hospedam m aquinas virtuais de rede virtual a que o pacote encapsulado se
destina. No servidor fsico ao qual o pacote encapsulado se destina, o quadro Ethernet
original e recuperado ap os o desencapsulamento do pacote. O encaminhamento baseado
nos cabecalhos IP e UDP mais externos garante a compatibilidade do pacote encapsulado
com a infraestrutura de rede. O encaminhamento e o roteamento dos pacotes encapsu-
lados ocorrem na infraestrutura fsica da rede, logo, as propriedades de conectividade e
seguranca da rede de sobrecamada s ao as mesmas da infraestrutura fsica.
As duas principais vantagens do DOVE s ao a separac ao dos espacos de enderecos
e a migrac ao facilitada de m aquinas virtuais. A separac ao dos espacos de enderecos
refere-se ao fato de que o tr afego de cada rede virtual s o e visvel para as estac oes nais
que pertencam ` aquela rede virtual. A separac ao das redes virtuais permite que cada uma
possa ser gerenciada individualmente. Outra vantagem e a migrac ao de m aquinas virtuais.
Como a participac ao de uma m aquina virtual a uma rede virtual depende somente da
congurac ao do sistema fsico que a hospeda, uma m aquina virtual pode ser migrada para
qualquer servidor fsico do centro de dados e mesmo assim manter a sua conectividade ` a
rede virtual bastando recongurar o servidor fsico.
1.7.11. OpenFlow
O OpenFlow [McKeown et al., 2008, Mattos et al., 2011b] permite que a infraestrutura
fsica de redes seja compartilhada pela rede de produc ao e por redes experimentais. A
ideia chave do OpenFlow e centralizar o controle da rede e simplicar a congurac ao
dos elementos de rede. O OpenFlow promove a criac ao de redes denidas por software
(Software Dened Networks - SDN), usando elementos comuns de rede, tais como comu-
tadores, roteadores, pontos de acesso ou, at e mesmo, computadores pessoais. Assim, o
OpenFlow e uma plataforma que permite congurar o encaminhamento dos pacotes com
base em denic oes de uxos nos elementos de rede. Esta enorme exibilidade oferecida
pelo OpenFlow e vantajosa para centros de dados, pois os uxos podem ser recongura-
dos de acordo com a demanda dos servidores. Um uxo e denido como um conjunto
de doze caractersticas da comunicac ao entre dois n os na rede, obtidas nos cabecalhos
das camadas de enlace, de rede e de transporte de cada pacote [McKeown et al., 2008].
Como em um comutador padr ao, o comutador OpenFlow tamb em possui uma tabela de
encaminhamento, que e chamada de tabela de uxo. As entradas nessa tabela relacio-
nam um uxo com um conjunto de ac oes denidas pelo controlador sobre cada pacote.
Quando um pacote chega ao comutador OpenFlow, o comutador verica se o pacote se
adequa a algum uxo j a existente. Em caso positivo, as ac oes denidas para aquele uxo
s ao aplicadas ao pacote. Em caso negativo, o primeiro pacote do uxo e enviado ao con-
trolador, que dene um novo uxo e determina as ac oes a serem tomadas. A Figura 1.21
mostra a organizac ao de uma rede OpenFlow e a comunicac ao dos elementos de rede com
o controlador centralizado.
Figura 1.21. Arquitetura de uma rede OpenFlow. Os comutadores OpenFlow
comunicam-se com o controlador atrav es do protocolo OpenFlow em um canal
seguro. O controlador executa as aplicac oes de controle de cada rede virtual.
O controlador e um elemento centralizado que executa aplicac oes de controle so-
bre a rede OpenFlow, congurando as tabelas de uxo dos elementos encaminhadores. O
controlador implementa o protocolo OpenFlow para se comunicar com os elementos de
rede e, atrav es desse protocolo, congura os elementos da rede. Um dos controladores
OpenFlow mais usados e o Nox [Gude et al., 2008]. O Nox age como um sistema ope-
racional de rede, provendo as func oes b asicas de congurac ao e monitoramento da rede
para as aplicac oes que controlam a rede. Dessa forma, o controlador age somente como
uma interface entre a rede e as aplicac oes. O plano de controle e exercido pelas aplicac oes
que executam sobre o Nox. Sendo assim, uma rede virtual no OpenFlow e representada
pelo seu conjunto de uxos, plano de dados, e pelas suas aplicac oes de controle, plano de
controle.
A virtualizac ao do plano de controle em redes OpenFlow e feita pelo FlowVi-
sor [Sherwood et al., 2009]. O FlowVisor e um controlador especial do OpenFlow, que
funciona de forma transparente entre os dispositivos em uma rede OpenFlow e os outros
controladores, como por exemplo o Nox. O FlowVisor permite que mais de um controla-
dor controle a rede OpenFlow, para tanto, o FlowVisor introduz o conceito de fatia. Cada
fatia de rede e controlada por um controlador e e denida por polticas no FlowVisor.
As mensagens de controle trocadas entre os dispositivos e os controladores s ao interme-
diadas pelo FlowVisor, que verica para cada mensagem, quais polticas s ao aplic aveis.
Al em disso, verica se um determinado controlador pode controlar um dado uxo em um
dispositivo.
Figura 1.22. Arquitetura do FlowVisor, um controlador especial do OpenFlow,
que permite a denic ao de redes virtuais.
O FlowVisor, como mostrado na Figura 1.22, executa a virtualizac ao do plano
de controle da rede, isolando o controle, mas compartilhando o plano de dados dos co-
mutadores da rede OpenFlow. O fatiamento da rede realizado pelo FlowVisor e focado
no compartilhamento de cinco recursos primitivos da rede [Sherwood et al., 2009]: isola-
mento de banda, descoberta de topologia, engenharia de tr afego, monitoramento de CPU
e controle das tabelas de encaminhamento. O FlowVisor executa apenas a virtualizac ao
do plano de controle, permitindo que mais de um controlador troque mensagens de con-
trole com um dispositivo OpenFlow. No entanto, cada controlador exerce o controle em
uma fatia da rede e, nessa fatia, s o um controlador exerce o controle. Dessa forma, o
FlowVisor cria ilhas de controle em uma rede OpenFlow, de forma que o controle global
da rede ca distribudo, enquanto o controle de cada fatia de rede ca centralizado em um
controlador por fatia.
O XenFlow [Mattos et al., 2011a] e uma plataforma de virtualizac ao hbrida, na
qual m aquinas virtuais Xen [Moraes et al., 2011] agem como o plano de controle de ro-
teadores e o encaminhamento e baseado no OpenFlow. O XenFlow tem como vantagem
tornar o plano de dados do Xen program avel e com isto fazer a migrac ao de enlaces de
forma mais simples, sem a necessidade de criac ao de t uneis e com perda zero de pacotes.
1.8. Soluc oes para a Migrac ao entre Diferentes Centros de Dados
Apesar da maioria das soluc oes se concentrarem nos cen arios internos aos centros de
dados, transmitir os dados atrav es de centros de dados distribudos distantes geograca-
mente e um desao ainda maior. Envolver a Internet signica herdar todas as limitac oes
dessa rede para esse tipo de aplicac ao. Esta sec ao descreve soluc oes que se dedicam
principalmente ao caso de comunicac oes entre centros de dados.
1.8.1. NetStitcher
A ideia b asica da soluc ao Netsticher [Laoutaris et al., 2011] e explorar banda passante
(periodicamente) n ao utilizada para movimentar grandes massas de dados entre cen-
tros de dados distribudos. A estrat egia do Netstitcher e combinar a transmiss ao utili-
zando m ultiplos caminhos e a t ecnica de armazenamento e encaminhamento (store-and-
forward) para mover os dados na direc ao do destino, de acordo com as oportunidades
de transmiss ao que acontecam. O Netstitcher se baseia em uma rede sobreposta, seme-
lhante ` a implementada por sistemas baseados em armazenamento e encaminhamento bem
conhecidos, como o Bit Torrent. No entanto, diferentemente destes sistemas, o Netstit-
cher leva em considerac ao a durac ao, o instante de tempo e a localizac ao das janelas de
transmiss ao.
A principal observac ao que motivou os autores a proporem o Netstitcher e que os
enlaces de longa dist ancia da rede que interconecta os centros de dados apresentam banda
passante n ao utilizada durante alguns perodos do dia, por exemplo como consequ encia
dos hor arios de jornada de trabalho das pessoas. Por outro lado, estas oportunidades de
transmiss ao podem ocorrer em diferentes instantes de tempo para os diferentes stios de
um centro de dados distribudo, como consequ encia da diferenca de fuso hor ario entre
localidades distantes. Assim, para transmitir um grande arquivo de backup da costa leste
para a costa oeste dos Estados Unidos, e possvel agendar as transfer encias de dados
para ocorrerem durante os perodos onde os enlaces de transmiss ao est ao sub-utilizados.
Utilizando a capacidade de armazenamento dos n os intermedi arios, e possvel esperar pela
pr oxima oportunidade de transmiss ao. Por outro lado, caso m ultiplos caminhos existam
e possuam banda passante disponvel, o arquivo pode ser dividido pelo Netstitcher em
pedacos e cada um transmitido utilizando um caminho diferente.
A Figura 1.23 ilustra um backup realizado entre um centro de dados localizado
em Nova Iorque (NYC) e outro localizado em Palo Alto (PAL), explorando o fato de que,
como consequ encia das jornadas de trabalho, h a banda passante de sobra nos enlaces de
longa dist ancia e, como consequ encia, oportunidades de transmiss ao. O ret angulo da Fi-
gura 1.23 representa o perodo durante o qual cada um dos centros de dados pode executar
o backup porque h a banda passante de sobra. Por exemplo, em Nova Iorque o backup e
possvel das 3:00 ` as 6:00 horas da manh a, no fuso hor ario EST (Eastern Standard Time)
enquanto que em Denver o backup pode ser realizado tamb em das 3:00 ` as 6:00 da manh a,
por em no fuso hor ario local, MST (Mountain Standard Time). Assim, gracas aos dife-
rentes fusos hor arios, as oportunidades de transmiss ao de durac ao de 3 horas podem se
sobrepor total ou parcialmente. O diagrama mostra a operac ao de uma soluc ao baseada na
t ecnica de armazenamento e encaminhamento onde foi utilizado o armazenamento tem-
por ario em cinco localidades diferentes, Boston (BOS), Chicago (CHI), Phoenix (PHO),
Figura 1.23. Exemplo do diagrama de tempo de uma transfer encia de
grande massa de dados usando oportunidades de transmiss ao (adaptado
de [Laoutaris et al., 2011]).
Denver (DEN) e Seattle (SEA). Utilizando a banda passante de sobra do enlace de sada
de Nova Iorque (NYC), tr es blocos de dados s ao transmitidos e ent ao temporariamente
armazenados em Boston (1), Chicago (2) e Denver (3). O bloco de dados armazenado em
Boston (BOS) e mais tarde transmitido para Phoenix (4), entre 5:00 e 6:00 da manh a no
hor ario local de Boston (entre 3:00 e 4:00 da manh a no fuso hor ario de Phoenix). Este
bloco de dados e depois transmitido de Phoenix para Seattle (7) e ent ao de Seattle para
Palo Alto (8). Os outros dois blocos de dados resultantes do particionamento inicial em
Nova Iorque s ao transmitidos utilizando oportunidades de transmiss ao e caminhos dife-
rentes, como ilustrado na gura.
O Netstitcher foi implementado baseado em uma rede sobreposta e um sistema
composto de quatro m odulos. O m odulo de gerenciamento da rede sobreposta e res-
pons avel pela manutenc ao da conectividade na rede sobreposta. O m odulo de predic ao
de volume e respons avel pela medic ao e/ou estimac ao da banda passante disponvel nos
enlaces e espaco de armazenamento disponvel nos n os. O m odulo de escalonamento e
respons avel por executar um algoritmo para decidir quando as transfer encias devem ocor-
rer e por quanto tempo os blocos de dados devem ser armazenados nos n os intermedi arios,
de maneira que o tempo de transfer encia do volume total de dos seja minimizado. Final-
mente, o m odulo de gerenciamento de transmiss ao e respons avel pela execuc ao propria-
mente dita das transfer encias de dados decididas pelo m odulo de escalonamento.
O m odulo de escalonamento e o principal do Netstitcher. O escalonamento e mo-
delado como umproblema de mnimo tempo de transfer encia (MTT), onde umn o v deseja
enviar um arquivo de tamanho F para um n o de destino u [Laoutaris et al., 2011]. O n o
Figura 1.24. Exemplo de um grafo tradicional obtido a partir de um grafo evolucion ario.
v pode usar qualquer banda passante n ao utilizada e n os da rede sobreposta como arma-
zenamento tempor ario. O modelo divide o tempo sem slots. Tanto os recursos de banda
passante quanto os de armazenamento s ao denidos em termos da quantidade de dados
(por exemplo, em bytes) que podem ser transmitidos (respectivamente, armazenados) du-
rante um slot de tempo t. A rede e modelada atrav es de um grafo evolucion ario. Assim,
considerando um n o v, v(1) e v(2) representam o n o v durante os slots de tempo 1 e 2, res-
pectivamente. N
vw(1)
representa o gargalo de rede, ou a banda passante disponvel, entre
os n os v e w durante o slot de tempo 1. S
w(1)
representa a capacidade de armazenamento
do n o w durante o slot de tempo 1. Expandindo o n o v em T
max
n os (v(1), . . . , v(T
max
)),
onde T
max
e o n umero m aximo de slots de tempo, o grafo evolucion ario pode ser trans-
formado em um grafo tradicional, onde N
vw(t)
representa os gargalos da rede e S
w
(t) a
capacidade de armazenamento do n o w durante o slot de tempo t. Assim, enlaces conec-
tando n os no mesmo slot de tempo (cada slot corresponde a uma linha horizontal no grafo)
representam a capacidade da rede, enquanto enlaces conectando n os localizados em slots
de tempo diferentes (enlaces verticais) representam a capacidade de armazenamento dos
n os, como mostrado na Figura 1.24.
Considerando o grafo expandido da topologia, a ideia b asica do Netstitcher e re-
solver um problema de uxo m aximo (max-ow), ou seja, encontrar uma combinac ao de
caminhos na rede e capacidades dos uxos a transmitir em cada caminho tal que a quanti-
dade de dados transmitido da fonte v(1) para o destino z(T
max
) seja m axima. O algoritmo
de Ford-Fulkerson e usado para resolver o problema de uxo m aximo. Existe, no entanto,
um problema com esta soluc ao, uma vez que o Netstitcher tem como objetivo minimizar
o tempo de transmiss ao, e n ao maximizar o uxo entre fonte e destino. Na denic ao do
problema de uxo m aximo, o tempo de transmiss ao m aximo e um dado de entrada, no
caso, igual a T
max
multiplicado pelo tamanho do slot de tempo. A soluc ao utilizada pelo
Netstitcher e executar o algoritmo de Ford-Fulkerson T
max
vezes em vez de apenas uma
vez, a cada vez, utilizando a cada vez uma topologia diferente. Cada topologia utilizada e
um sub-grafo da topologia geral, com 1, 2, . . . T
max
1 slots. Em seguida, e realizada uma
busca bin aria entre as soluc oes encontradas nas diferentes execuc oes do algoritmo para
escolher, entre as que obtiveramo uxo m aximo, a que utilizou a subtopologia commenos
slots de tempo, minimizando o tempo de transmiss ao como era o objetivo do Netstitcher.
1.8.2. Descarregamento de tr afego
Uma caracterstica comum ` as soluc oes apresentadas at e agora e que todas visam melho-
rias na utilizac ao dos recursos da Internet, mas ao mesmo tempo dependem da infraes-
trutura Internet para a transfer encia de dados. Recentemente, uma soluc ao alternativa
tem sido explorada: o descarregamento de tr afego (trafc ofoading). A id eia de des-
carregar o tr afego de uma rede sobre uma outra rede de forma a aliviar a primeira tem
sido proposta em v arios contextos, principalmente em relac ao ` a infrastrutura 3G que tem
sofrido com o aumento do tr afego gerados pelos smatphones. De fato, de acordo com
a Cisco, dados relacionados ` as redes m oveis aumentou cerca de 26 vezes no perodo
2010-2015 [Cisco, 2011]. Entretando, o descarregamento de tr afego pode ser aplicado
em in umeras outras situac oes.
No contexto desse minicurso, o exemplo mais interessante e o de centros de dados
m oveis (data-centers-to-go), os quais se baseiam em arquiteturas do tipo modulares (ver
exemplo do BCube na Sec ao 1.5.2) no qual cont eineres carregados de computadores e uni-
dades de armazenamento religam pontos geogracamente distribudos [Waldrop, 2007].
Apesar da lat encia, a quantidade de dados transferidas durante esse tipo de operac ao e bem
superior ` aquela oferecida se a Internet fosse usada. V arias soluc oes de centros de dados
m oveis t em sido propostas por empresas do ramo. Por exemplo, a empresa APC deno-
minou seu produto InfraStruXure Express On-demand Mobile Data Center, utilizando
caminh oes como o ilustrado na Figura 1.25 [APC, 2012]. Esse cont einer e constitudo
um gerador de energia, um sistema de resfriamento e um centro de operac oes, cujo custo
total e da ordem de 1,5 milh oes de d olares. Outras soluc oes similares ` a da APC s ao a
Blackbox da Sun (Oracle), Portable Modular Datacenter da IBM, ICE Cube da Rackable
e Portable Optimized Datacenter da HP [Waldrop, 2007].
1.9. Conclus ao e Perspectivas Futuras
Este minicurso apresentou a import ancia do crescimento das massas de dados, impulsi-
onado pelo uso das comunicac oes em nuvens. Ainda, foi detalhada uma denic ao mais
precisa que a comumente utilizada que relaciona as grandes massas de dados apenas a
sua quantidade de bytes. Normalmente, outros aspectos relevantes s ao deixados de lado
como o n umero de fontes, a variabilidade dos dados e a velocidade com que os dados
s ao gerados. Todos eles contribuem com a denic ao mais abrangente que relaciona uma
grande massa de dados a um grande volume de dados.
Os grandes volumes de dados escondem informac oes frequentemente n ao apro-
veitadas por falta de recursos de infraestrutura para armazenamento e an alise. Novas
t ecnicas para agilizar a extrac ao de valor v em sendo propostas. Um dos principais pon-
tos de otimizac ao e evitar que os dados sejam movidos entre os centros de dados onde
Figura 1.25. Um caminh ao APC oferecendo InfraStruXure Express On-demand
Mobile Data Center.
est ao armazenados. Para tal, s ao considerados fatores como localidade na organizac ao
dos dados. Entretanto, encontrar a melhor localizac ao nem sempre e possvel ou trivial
j a que fatores como a proximidade dos clientes aos dados diminuem o tempo de resposta
a requisic oes. Dessa maneira, grandes massas de dados precisam ser movidas dentro
dos centros de dados ou at e mesmo entre diferentes centros de dados afastados geogra-
camente. Essa movimentac ao pode utilizar redes p ublicas tradicionais, em especial a
Internet, revelando as limitac oes dessas redes.
As limitac oes da Internet s ao muitas j a que a rede foi inicialmente projetada para
transfer encia con avel de dados com poucos kilobytes. Mover uma enorme massa de
dados, da ordem de petabytes oferece problemas que v ao desde a organizac ao dos centros
de dados at e a reformulac ao de protocolos conhecidos como o TCP. Neste minicurso,
foram abordados propostas que atacam tal gama de problemas desde as comunicac oes
internas ao centros de dados (intra-datacenters) at e as comunicac oes entre centros de
dados (inter-datacenters) ou na nuvem. Vale ressaltar que o tema e bastante complexo
e muitas soluc oes v em sendo propostas na literatura, principalmente as intra-centros de
dados. Nota-se que as soluc oes que envolvem movimentac ao entre centros de dados ainda
n ao s ao t ao exploradas como decorr encia da adic ao das redes de comunicac ao, que tornam
a soluc ao ainda mais complexa.
As grandes massas de dados ainda possuem outras quest oes n ao abordadas neste
minicurso devido ` a impossibilidade de se realizar uma pesquisa exaustiva. Dentre as
quest oes n ao abordadas est ao a seguranca dos dados, especialmente durante a trans-
fer encia; o consumo excessivo de energia; e os impactos sociais. A seguranca dos dados e
bastante controversa, j a que muitas vezes os dados dos usu arios s ao mantidos em centros
de dados de provedores de servico em nuvem, cujo controle de acesso e frequentemente
posto em xeque. J a a segunda quest ao citada e consequ encia das enormes quantidades
de energia gastas para manter refrigerados todos os servidores de um centro de dados.
E sabido que empresas de grande porte chegam a migrar os seus centros de dados para
regi oes mais frias do globo para economizar energia em resfriamento. A quest ao social e
consequ encia das novas oportunidades que surgem com a an alise dos dados, que revelam
tend encias a serem exploradas e, consequente, retorno econ omico.
Observa-se que o tema e bastante amplo e ainda h a muita pesquisa e desenvol-
vimento em potencial. Este minicurso ressalta o problema iminente resultante do surgi-
mento das grandes massas de dados, principalmente na area de comunicac ao em redes.
Entretanto, um vasto caminho ainda est a em aberto nas mais diferentes areas.
Refer encias
[CN, 2009] (2009). IEEE 802.1Qau/D1.4. draft standard for local and metropolitan area
networks - virtual bridged area networks - Amendment 7: congestion notication.
[Al-Fares et al., 2008] Al-Fares, M., Loukissas, A. e Vahdat, A. (2008). A scalable, com-
modity data center network architecture. Em ACM Sigcomm, p. 6374.
[Alizadeh et al., 2010] Alizadeh, M., Greenberg, A., Maltz, D., Padhye, J., Patel, P.,
Prabhakar, B., Sengupta, S. e Sridharan, M. (2010). Data center TCP (DCTCP). Em
Proceedings of the ACM SIGCOMM 2010, p. 6374. ACM.
[Amazon, 2011] Amazon (2011). Amazon cluster compute. Acessado em http://
aws.amazon.com/ec2/hpc-applications.
[Apache, 2012] Apache (2012). The Hadoop Project. Acessado emhttp://hadoop.
apache.org.
[APC, 2012] APC (2012). InfraStruXure express on-demand mobile data cen-
ter. Acessado em http://www.apc.com/solutions/display.cfm?id=
AFE229A7-5056-9170-D39270DF%E3F5E617&ISOCountryCode=us.
[Ballani et al., 2011] Ballani, H., Costa, P., Karagiannis, T. e Rowstron, A. (2011).
Towards predictable datacenter networks. Em ACM Sigcomm, p. 242253.
[Barabash et al., 2011] Barabash, K., Cohen, R., Hadas, D., Jain, V., Recio, R. e Ro-
chwerger, B. (2011). A case for overlays in dcn virtualization. Em Proceedings of the
3rd Workshop on Data Center-Converged and Virtual Ethernet Switching, p. 3037.
ITCP.
[Barabasi e Bonabeau, 2003] Barabasi, A. L. e Bonabeau, E. (2003). Scale-free
networks. Scientic American, 288(5):5059.
[BGP Reports, 2012] BGP Reports (2012). BGP routing table analysis reports. Acessado
em http://www.potaroo.net/tools/asn32.
[Cho e Gupta, 2011] Cho, B. e Gupta, I. (2011). Budget-constrained bulk data transfer
via internet and shipping networks. Em 8th ACM International Conference on Auto-
nomic Computing, p. 7180.
[Chowdhury et al., 2011] Chowdhury, M., Zaharia, M., Ma, J., Jordan, M. I. e Stoica,
I. (2011). Managing data transfers in computer clusters with Orchestra. Em ACM
Sigcomm, p. 98109.
[Cisco, 2011] Cisco (2011). Cisco visual networking index: Forecast and methodology,
2010-2015. Acessado em http://www.cisco.com/en/US/solutions/
collateral/ns341/ns525/ns537/ns705%/ns827/white_paper_
c11-481360_ns827_Networking_Solutions_White_Paper.html.
[Dean e Ghemawat, 2008a] Dean, J. e Ghemawat, S. (2008a). MapReduce: simplied
data processing on large clusters. Communications of the ACM, 51:107113.
[Dean e Ghemawat, 2008b] Dean, J. e Ghemawat, S. (2008b). MapReduce: simplied
data processing on large clusters. Communications of the ACM, 51(1):107113.
[DeCandia et al., 2007] DeCandia, G., Hastorun, D., Jampani, M., Kakulapati, G.,
Lakshman, A., Pilchin, A., Sivasubramanian, S., Vosshall, P. e Vogels, W. (2007).
Dynamo: Amazons highly available key-value store. Em ACM SIGOPS Symposium
on Operating Systems Principles, p. 205220.
[Egi et al., 2007] Egi, N., Greenhalgh, A., Handley, M., Hoerdt, M., Mathy, L. e Schoo-
ley, T. (2007). Evaluating Xen for router virtualization. Em International Conference
on Computer Communications and Networks (ICCCN), p. 12561261.
[Fernandes et al., 2011] Fernandes, N. C., Moreira, M. D. D., Moraes, I. M., Ferraz, L.
H. G., Couto, R. S., Carvalho, H. E. T., Campista, M. E. M., Costa, L. H. M. K. e
Duarte, O. C. M. B. (2011). Virtual networks: Isolation, performance, and trends.
Annals of Telecommunications, 66(56):339355.
[Forrester Research, 2010] Forrester Research (2010). The future of data center
wide-area networking. Acessado em http://www.infineta.com/sites/
default/files/pdf/Special_Forrester_Repor%t_Skyrocketing_
WAN_Traffic.pdf.
[Gantz e Reinsel, 2010] Gantz, J. e Reinsel, D. (2010). The digital universe de-
cade - are you ready? Acessado em http://www.emc.com/collateral/
analyst-reports/idc-digital-universe-are-%you-ready.pdf.
[Gantz e Reinsel, 2011] Gantz, J. e Reinsel, D. (2011). Extracting value from chaos.
Acessado em http://www.emc.com/collateral/analyst-reports/
idc-extracting-value-from%-chaos-ar.pdf.
[Greenberg et al., 2009] Greenberg, A., Hamilton, J. R., Jain, N., Kandula, S., Kim, C.,
Lahiri, P., Maltz, D. A., Patel, P. e Sengupta, S. (2009). VL2: a scalable and exible
data center network. Em ACM Sigcomm, p. 5162.
[Gude et al., 2008] Gude, N., Koponen, T., Pettit, J., Pfaff, B., Casado, M., McKeown,
N. e Shenker, S. (2008). Nox: towards an operating system for networks. SIGCOMM
Comput. Commun. Rev., 38(3):105110.
[Guo et al., 2009] Guo, C., Lu, G., Li, D., Wu, H., Zhang, X., Shi, Y., Tian, C., Zhang, Y.
e Lu, S. (2009). BCube: A high performance, server-centric network architecture for
modular data centers. Em ACM Sigcomm, p. 6374.
[Halperin et al., 2011] Halperin, D., Kandula, S., Padhye, J., Bahl, P. e Wetherall, D.
(2011). Augmenting data center networks with multi-gigabit wireless links. Em ACM
Sigcomm, p. 3849.
[Hopps, 2000] Hopps, C. (2000). Analysis of an equal-cost multi-path algorithm. RFC
2992.
[Hugh Barras et al., 2008] Hugh Barras et al. (2008). IEEE 802.1Qbb/D1.0.
draft standard for local and metropolitan area networks - virtual bridged lo-
cal area networks - Amendment XX: Priority-based ow control. Aces-
sado em http://www.ieee802.org/1/files/public/docs2008/
bb-pelissier-pfc-proposa%l-0508.pdf.
[Isard et al., 2007] Isard, M., Budiu, M., Yu, Y., Birrell, A. e Fetterly, D. (2007). Dryad:
distributed data-parallel programs from sequential building blocks. Em ACM SI-
GOPS/EuroSys European Conference on Computer Systems, p. 5972.
[Lantz et al., 2010] Lantz, B., Heller, B. e McKeown, N. (2010). A network in a laptop:
rapid prototyping for software-dened networks. Em ACM HotNets, p. 19:119:6,
Monterey, EUA.
[Laoutaris et al., 2011] Laoutaris, N., Sirivianos, M., Yang, X. e Rodriguez, P. (2011).
Inter-datacenter bulk transfers with NetStitcher. Em ACM Sigcomm, p. 7485.
[Leiserson, 1985] Leiserson, C. E. (1985). Fat-trees: Universal networks for hardware-
efcient supercomputing. IEEE Transactions on Computers, 34(10):892901.
[Manoj Wadekar et al., 2008a] Manoj Wadekar et al. (2008a). DCB ca-
pability exchange protocol base specication Rev 1.01. Acessado em
http://www.ieee802.org/1/les/public/docs2008/az-wadekar-dcbx-capability-
exchange-discovery-protocol-1108-v1.01.pdf.
[Manoj Wadekar et al., 2008b] Manoj Wadekar et al. (2008b). IEEE 802.1Qaz/D0.2.
draft standard for local and metropolitan area networks - virtual bridged local area
networks - Amendment XX: Enhanced transmission selection for bandwidth sharing
between trafc classes. Acessado em http://www.ieee802.org/1/files/
public/docs2008/az-wadekar-ets-proposal-%0608-v1.01.pdf.
[Mattos et al., 2011a] Mattos, D., Fernandes, N. C. e Duarte, O. C. M. B. (2011a). Xen-
ow: Um sistema de processamento de uxos robusto e eciente para migrac ao em
redes virtuais. Em XXIX Simp osio Brasileiro de Redes de Computadores e Sistemas
Distribudos - SBRC2011, p. 309322.
[Mattos et al., 2011b] Mattos, D. M. F., Fernandes, N. C., Cardoso, L. P., da Costa, V. T.,
Mauricio, L. H., Barretto, F. P. B. M., Portella, A. Y., Moraes, I. M., Campista, M.
E. M., Costa, L. H. M. K., e Duarte, O. C. M. B. (2011b). Omni: Uma ferramenta
para gerenciamento aut onomo de redes openow. Em Sal ao de Ferramentas do XXIX
Simp osio Brasileiro de Redes de Computadores e Sistemas Distribudos - SBRC2011,
p. 957964.
[McKeown et al., 2008] McKeown, N., Anderson, T., Balakrishnan, H., Parulkar, G., Pe-
terson, L., Rexford, J., Shenker, S. e Turner, J. (2008). Openow: enabling innovation
in campus networks. SIGCOMM Comput. Commun. Rev., 38(2):6974.
[Moraes et al., 2011] Moraes, I. M., Pisa, P. S., Carvalho, H. E. T., Alves, R. S., Ferraz,
L. H. G., Ferreira, T. N., Couto, R. S., da Silva Neto, D. J., da Costa, V. P., Lage, R. A.,
dos Santos, L. V., Fernandes, N. C., Campista, M. E. M., Costa, L. H. M. K. e Duarte,
O. C. M. B. (2011). Vnext: Uma ferramenta de controle e gerenciamento para redes
virtuais baseadas em xen. Em Sal ao de Ferramentas do XXIX Simp osio Brasileiro de
Redes de Computadores e Sistemas Distribudos - SBRC2011, p. 981988.
[Mudigonda et al., 2010] Mudigonda, J., Yalagandula, P., Al-Fares, M. e Mogul, J. C.
(2010). SPAIN: COTS data-center Ethernet for multipathing over arbitrary topologies.
Em USENIX Symposium on Networked Systems Design and Implementation (NSDI),
p. 265280.
[Mudigonda et al., 2011] Mudigonda, J., Yalagandula, P., Mogul, J., Stiekes, B. e Pouf-
fary, Y. (2011). Netlord: A scalable multi-tenant network architecture for virtualized
datacenters. Em ACM Sigcomm, p. 6273.
[(Online Tech), 2011] (Online Tech), T. P. (2011). Cloud computing prompts 2012 data
center expansion plans. http://resource.onlinetech.com/cloud-computing-prompts-
2012-data-center-expansion-plans/.
[Perlman et al., 2011] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S. e Ghanwani, A.
(2011). Routing Bridges (RBridges): Base Protocol Specication. RFC 6325.
[Phanishayee et al., 2008] Phanishayee, A., Krevat, E., Vasudevan, V., Andersen, D.,
Ganger, G., Gibson, G. e Seshan, S. (2008). Measurement and analysis of TCP th-
roughput collapse in cluster-based storage systems. Em Proceedings of the 6th USE-
NIX Conference on File and Storage Technologies, p. 12. USENIX Association.
[Raiciu et al., 2011] Raiciu, C., Barre, S., Pluntke, C., Greenhalgh, A., Wischik, D. e
Handley, M. (2011). Improving datacenter performance and robustness with multipath
TCP. Em ACM Sigcomm, p. 266277.
[Raiciu et al., 2010] Raiciu, C., Pluntke, C., Barre, S., Greenhalgh, A., Wischik, D. e
Handley, M. (2010). Data center networking with multipath TCP. Em ACM HotNets,
p. 10:110:6, Monterey, EUA.
[Saucez et al., 2009] Saucez, D., Iannone, L. e Bonaventure, O. (2009). OpenLISP: An
open source implementation of the locator/ID separation protocol. Em ACM SIG-
COMM Demos Session, p. 12.
[Sherwood et al., 2009] Sherwood, R., Gibb, G., Yap, K., Appenzeller, G., Casado, M.,
McKeown, N. e Parulkar, G. (2009). Flowvisor: A network virtualization layer. Open-
Flow Switch Consortium, Tech. Rep.
[Singla et al., 2011] Singla, A., Hong, C.-Y., Popa, L. e Godfrey, P. B. (2011). Jellysh:
Networking data centers, randomly. Em Usenix HotCloud.
[The Economist, 2010] The Economist (2010). Data, data everywhere. Aces-
sado em http://www.emc.com/collateral/analyst-reports/
ar-the-economist-data-dat%a-everywhere.pdf.
[Touch e Perlman, 2009] Touch, J. e Perlman, R. (2009). Transparent Interconnection of
Lots of Links (TRILL): Problem and Applicability Statement. RFC 5556.
[Waldrop, 2007] Waldrop, M. (2007). Data center in a box: A shipping container stuffed
with servers could usher in the era of cloud computing. Scientic American, 297(2):90
93.
[Wang et al., 2008] Wang, Y., Keller, E., Biskeborn, B., van der Merwe, J. e Rexford, J.
(2008). Virtual routers on the move: live router migration as a network-management
primitive. Em ACM SIGCOMM, p. 231242.
[Wilson et al., 2011] Wilson, C., Ballani, H., Karagiannis, T. e Rowstron, A. (2011). Bet-
ter never than late: Meeting deadlines in datacenter networks. Em ACM Sigcomm, p.
5061.
[Winslow et al., 2011] Winslow, P., Simson, D. e Panigrahi, S. (2011). The need for
speed. Relat orio t ecnico, Credit Suisse.
[Wu et al., 2010] Wu, H., Feng, Z., Guo, C. e Zhang, Y. (2010). ICTCP: Incast conges-
tion control for TCP in data center networks. Em Proceedings of the 6th International
Conference, p. 13. ACM.
[Zhang et al., 2011] Zhang, J., Ren, F. e Lin, C. (2011). Modeling and understanding
TCP incast in data center networks. Em Proceedings of the IEEE INFOCOM 2011, p.
13771385. IEEE.
[Zohar et al., 2011] Zohar, E., Cidon, I. e Mokryn, O. (2011). The power of prediction:
Cloud bandwidth and cost reduction. Em ACM Sigcomm, p. 8697.
Captulo
2
Segurana de Redes Virtuais:
Fundamentos, Tecnologias e Tendncias
Leonardo Richter Bays
1
, Rodrigo Ruas Oliveira
1
,
Luciano Paschoal Gaspary
1
, Marinho Pilla Barcellos
1
,
Edmundo Roberto Mauro Madeira
2
, Nelson Luis Saldanha da Fonseca
2
1
Instituto de Informtica Universidade Federal do Rio Grande do Sul (UFRGS)
2
Instituto de Computao Universidade Estadual de Campinas (UNICAMP)
Abstract
Network virtualization is the technique that allows the creation of multiple instances of
virtual networks over a single physical substrate. This technique has attracted a great
amount of interest from the academic community, in particular due to its applicability
in creating favorable conditions for the evaluation of new architectures for the Future
Internet. There is also noticeable interest from major companies within the segment of
computer networks, which are starting to manufacture devices supporting virtualization,
as well as offering virtual network provisioning services. However, the shared use of rou-
ting devices and communication channels brings a series of security related concerns. It
is necessary to provide protection to virtual network infrastructures in order to enable
their use in real environments and on a large scale. In this tutorial, we present a review
of the state-of-the-art concerning virtual network security. We discuss the main challen-
ges related to this kind of environment, some of the major threats, as well as solutions
proposed in the literature which aim to deal with varying security aspects.
Resumo
Virtualizao de redes a tcnica que permite a criao de mltiplas instncias de redes
virtuais sobre um mesmo substrato fsico. Tal tcnica tem, por um lado, atrado grande
interesse por parte da comunidade acadmica, devido a sua aplicabilidade na criao
de condies favorveis de avaliao de novas arquiteturas para a Internet do Futuro.
Por outro, tambm possvel perceber o interesse de empresas importantes do segmento
de redes, que passam tanto a fabricar dispositivos com suporte virtualizao quanto a
oferecer servios de aprovisionamento de instncias virtualizadas de redes. No entanto,
o uso compartilhado de dispositivos de roteamento e de canais de comunicao traz con-
sigo uma srie de preocupaes relacionadas segurana. necessrio prover proteo
s infraestruturas de redes virtuais, de forma a viabiliz-las em ambientes reais e em
larga escala. Nesse minicurso, apresentamos uma reviso do estado da arte no que se re-
fere segurana de redes virtuais. So apresentados os principais desaos relacionados
a esse tipo de ambiente, algumas das principais ameaas, bem como solues propostas
na literatura para prover diferentes aspectos de segurana.
2.1. Introduo
Virtualizao um conceito bem estabelecido, com aplicaes que cobrem diver-
sas reas da computao. Tal tcnica permite a criao de mltiplas plataformas virtuais
sobre uma nica infraestrutura fsica. O uso de virtualizao traz vantagens como e-
xibilidade, permitindo que arquiteturas heterogneas sejam instanciadas sobre o mesmo
hardware. Seu uso tambm proporciona uma melhor utilizao de substratos fsicos,
permitindo a incluso e remoo de ns virtuais de forma dinmica, de acordo com a
demanda.
No contexto de servios de rede, a virtualizao tem sido comumente usada em
servidores, proporcionando vantagens como exibilidade e adaptao dinmica, previ-
amente mencionadas. Provedores de servios so capazes de adaptar dinamicamente a
quantidade de recursos alocados a diferentes aplicaes para suprir maiores ou menores
demandas. Alm disso, essa maior exibilidade pode permitir a proviso de um nmero
maior de aplicaes. A virtualizao tambm pode ser usada para elevar a disponibilidade
atravs do uso de ns virtuais redundantes.
Motivado por servios cada vez mais especcos e dinmicos, e dado o sucesso
da utilizao da virtualizao na hospedagem de sistemas computacionais, passou-se a
explorar o uso desse conceito tambm em infraestruturas de rede. Virtualizao de re-
des permite a criao de mltiplas instncias independentes de redes virtuais sobre um
mesmo substrato fsico. Isso se d atravs da instanciao de um ou mais roteadores vir-
tuais sobre roteadores fsicos, bem como do estabelecimento de enlaces virtuais entre tais
roteadores, independente da topologia usada na rede fsica. Tal tcnica pode ser usada
tanto para trazer as vantagens da virtualizao a substratos de rede quanto para permitir a
implantao de novas aplicaes que tm sido idealizadas.
O uso de virtualizao de redes permite acomodar mltiplas pilhas de protoco-
los simultaneamente no mesmo substrato fsico. Isso propicia a criao de infraestrutu-
ras de rede especicamente adaptadas s necessidades de diferentes aplicaes de rede
[Fernandes et al. 2010]. Adicionalmente, a virtualizao de redes possibilita a execuo
de experimentos de novas arquiteturas e protocolos sem interferir no trfego de produo.
Infraestruturas virtuais podem ser usadas para realizar tais experimentos em escala e com
um alto grau de similaridade com infraestruturas reais. Um estudo aprofundado sobre o
uso da virtualizao nesse contexto pode ser encontrado em [Farias et al. 2011].
Outras propostas de utilizao de virtualizao de redes esto relacionadas ao de-
senvolvimento da Futura Internet. Recentemente, tem havido vrios esforos da comu-
XXX Simpsio Brasileiro de Redes de Computadores e Sistemas Distribudos - SBRC 2012 61
nidade cientca para repensar a arquitetura da Internet, visando solucionar suas atuais
limitaes e dar suporte a novos requisitos [Campista et al. 2010]. Para tornar isso poss-
vel, alguns autores defendem uma abordagem clean slate, em que uma arquitetura com-
pletamente nova criada [Feldmann 2007]. Essa considerada uma abordagem atraente,
j que uma nova arquitetura no seria restrita pelas limitaes tcnicas que existem na
Internet atual. No entanto, tal abordagem no compatvel com a evoluo gradual utili-
zada tradicionalmente na Internet. Atualmente, melhorias incrementais so implementa-
das sobre a arquitetura existente, provendo retrocompatibilidade. Com a criao de uma
arquitetura completamente nova, uma transio gradual no seria possvel. Alm disso,
dada a escala em que a Internet utilizada atualmente, no seria possvel ter uma tran-
sio em que uma rede completamente desativada para que outra possa ser instanciada
em seu lugar. Para permitir tal transio, foi proposta a utilizao de redes virtualizadas,
o que permitiria a implantao de uma nova rede de forma paralela, sem interromper a
rede atual [Stuckmann and Zimmermann 2009].
No outro extremo, fora do escopo de explorao acadmica, a virtualizao de
redes vem tambm ganhando espao no mercado. Empresas importantes do segmento de
redes de computadores passam a fabricar dispositivos com suporte virtualizao. Alm
disso, provedores de infraestruturas passam a oferecer novos servios, tirando proveito de
tais funcionalidades. O apoio de grandes empresas a esse tipo de iniciativa pode ser obser-
vado, por exemplo, na lista de membros da organizao Open Networking Foundation
1
,
que promove o desenvolvimento e uso de redes denidas por software (Software-Dened
Networking). Tal organizao conta com o apoio de empresas como Cisco, Google e
Microsoft, entre diversas outras.
Em contraste com os benefcios oferecidos pela virtualizao, o uso comparti-
lhado de dispositivos de roteamento e canais de comunicao traz consigo uma srie de
preocupaes relacionadas segurana. Sem proteo adequada, usurios de uma rede
virtual podem ser capazes de acessar ou at mesmo interferir com trfego pertencente a
outras redes virtuais. Essas aes violariam propriedades de segurana tais como con-
dencialidade e integridade. Adicionalmente, a infraestrutura pode ser alvo de ataques de
negao de servio (DoS), causando problemas de disponibilidade para as redes virtuais
hospedadas na mesma. Portanto, de grande importncia que arquiteturas de virtuali-
zao de redes ofeream proteo contra esses e outros tipos de ameaas que possam
comprometer sua segurana.
Nesse minicurso, ser caracterizado o atual estado da arte no que se refere se-
gurana em virtualizao de redes, identicando as principais vulnerabilidades presentes
nessa rea, bem como o que j foi realizado buscando tornar essa tecnologia mais segura.
Para efetuar esse estudo, foi realizada uma extensiva busca literria. Tendo como base
conferncias e peridicos de qualidade, foram selecionadas publicaes e agrupadas de
acordo com classicaes bem conhecidas da rea de segurana de redes, bem como sub-
categorias criadas pelos autores. Tal organizao permitir uma anlise e discusso de
mltiplos aspectos de segurana em virtualizao de redes durante o decorrer do captulo.
O restante deste captulo est organizado da seguinte forma. A Seo 2.2 descreve
a sistemtica empregada na busca literria. A Seo 2.3 apresenta uma contextualizao
1
http://www.opennetworking.org/membership
da rea de virtualizao de redes. A Seo 2.4 dene a taxonomia usada para classicar
as publicaes selecionadas. A Seo 2.5 expe as ameaas de segurana encontradas na
literatura, enquanto a Seo 2.6 apresenta os servios de segurana providos por solues
encontradas em propostas anteriores. Por m, a Seo 2.7 discute os resultados desse
estudo e as principais tendncias para o futuro, e a Seo 2.8 conclui este captulo.
2.2. Busca Literria
Para formar a base literria desse estudo, pesquisas extensivas foram realizadas
nas bibliotecas digitais da ACM
2
e do IEEE
3
. O processo de busca literria foi realizado,
basicamente, em trs passos.
Inicialmente, buscas baseadas em palavras-chave foram empregadas em ambas as
bases de publicaes. Foramselecionadas palavras-chave associadas comvirtualizao de
redes, e combinadas com palavras-chave referentes segurana. Esse segundo conjunto
inclui, por exemplo, palavras relacionadas a componentes de segurana (isolamento, in-
tegridade, disponibilidade, etc.), bem como palavras associadas a tcnicas ou ameaas de
segurana (intruso, autenticao, criptograa, etc.).
Em um segundo passo, publicaes duplicadas ou inadequadas foram removidas.
Um nmero signicativo de publicaes, apesar de corresponder s palavras-chave se-
lecionadas, no estava diretamente relacionado segurana em virtualizao de redes,
e portanto, as mesmas foram descartadas. O restante das publicaes foi agrupado em
categorias bsicas de acordo com preocupaes relacionadas a segurana e abordagens
apresentadas por seus respectivos autores.
Por ltimo, as conferncias e peridicos em que tais artigos foram publicados
foram classicados e ordenados pela mdia da relao entre nmero de citaes e nmero
de publicaes. Todos os artigos acima de uma razo 2 foram considerados relevantes e
portanto selecionados. Os demais artigos foram analisados e, em geral, descartados.
O resultado desse processo uma compilao categorizada de artigos publicados
que so relevantes a essa pesquisa e apresentam um alto nvel de qualidade. Seguindo
essa busca literria, uma taxonomia foi criada para auxiliar na organizao e na discusso
das publicaes selecionadas. A denio dessa taxonomia apresentada na Seo 2.4.
2.3. Virtualizao de Redes
A virtualizao de redes consiste no compartilhamento dos dispositivos de uma
rede fsica (roteadores, comutadores, etc.) entre diferentes redes virtuais. Ela permite a
coexistncia de mltiplas redes, possivelmente heterogneas, sobre uma mesma infraes-
trutura fsica. Os elementos bsicos de um ambiente de rede virtualizada so ilustrados
na Figura 2.1. Ao nvel da rede fsica, diversos sistemas autnomos so representados por
substratos de rede interconectados (por exemplo, substratos A, B e C). Os dispositivos da
rede fsica so representados por ns com suporte a alguma tecnologia de virtualizao.
As redes virtuais (por exemplo, redes virtuais 1 e 2), por sua vez, tm suas topologias
2
http://portal.acm.org/
3
http://ieeexplore.ieee.org/
mapeadas no substrato (ou conjunto de substratos) correspondente(s). Essas topologias
de rede so formadas por roteadores virtuais, os quais utilizam uma parcela dos recursos
dos roteadores fsicos, e enlaces virtuais, os quais so caminhos na rede fsica compostos
por um ou mais enlaces fsicos e seus respectivos roteadores intermedirios.
Os roteadores e enlaces virtuais so, do ponto de vista da rede virtual, como equi-
pamentos fsicos dedicados. No entanto, em termos prticos, os mesmos compartilham os
recursos fsicos com roteadores e enlaces de outras redes virtuais. Dessa forma, a tcnica
utilizada para virtualizao de redes deve propiciar o nvel adequado de isolamento para
que seja possvel a implantao desse paradigma em um ambiente real e de larga escala.
Substrato A Substrato B Substrato C
Rede Virtual 1
Rede Virtual 2
Rede Fsica
Figura 2.1. Modelo de virtualizao de redes, exibindo um cenrio com mltiplos
substratos fsicos e redes virtuais.
Ao longo dos anos, diferentes mtodos para criao de redes virtuais tm sido usa-
dos. Abordagens tpicas incluem VLANs (Virtual Local Area Networks) e VPNs (Virtual
Private Networks). Mais recentemente, Monitores de Mquinas Virtuais e dispositivos de
rede programveis so empregados para criar roteadores e enlaces virtuais sobre disposi-
tivos e canais de comunicao fsicos. Tais abordagens so explicadas em mais detalhes
nas subsees seguintes.
2.3.1. Abordagens Baseadas em Protocolos
As abordagens baseadas em protocolos consistem na implementao de algum
protocolo que possibilite a identicao e o isolamento de redes distintas. Esse tipo de
abordagem requer apenas que os dispositivos da rede (ou um subconjunto deles) ofeream
suporte ao protocolo escolhido.
Um exemplo de virtualizao de redes baseada em protocolos so as VLANs (Vir-
tual Local Area Networks). VLANs consistem em parties lgicas sobre uma nica rede
subjacente. Dispositivos em uma VLAN comunicam-se uns com os outros como se es-
tivessem na mesma rede local, independente de sua localizao ou conectividade fsica.
Todos os quadros enviados pela rede so rotulados com o ID da VLAN a qual pertencem,
que so processados por roteadores habilitados e ento encaminhados conforme necess-
rio [LAN/MAN Standards Committee 2006].
Outra tcnica comumente utilizada consiste na criao de Redes Virtuais Priva-
das (Virtual Private Networks VPNs). VPNs so tipicamente usadas para prover um
canal seguro de comunicao entre ns geogracamente distribudos. Protocolos de tune-
lamento criptogrcos so usados para prover condencialidade de dados e autenticao
de usurios. VPNs podemser providas nas camadas fsica, de enlace ou de rede, de acordo
com os protocolos utilizados [Rosen et al. 2006].
2.3.2. Abordagens Baseadas em Virtualizao de Mquinas
As abordagens baseadas em virtualizao de mquinas consistem em criar redes
virtuais atravs de grupos de mquinas virtuais interconectadas. Monitores de Mquinas
Virtuais so usados para criar roteadores virtuais, e enlaces virtuais so criados entre
os mesmos, independente da topologia da rede fsica. A Tabela 2.1 mostra diferentes
tcnicas de virtualizao que podem ser usadas para criar redes virtuais, bem como uma
breve explicao e um exemplo de cada uma.
Tcnica Descrio Exemplo
Virtualizao
Completa
O Monitor de Mquinas Virtuais emula uma mquina completa,
baseada na arquitetura de hardware subjacente. O Sistema Ope-
racional hospedado executado sem nenhuma modicao.
VMware
Paravirtualizao O Monitor de Mquinas Virtuais emula uma mquina similar ao
hardware subjacente, com a adio de um hipervisor (hypervi-
sor). O hipervisor permite que o Sistema Operacional hospe-
dado execute tarefas complexas diretamente no hardware no
virtualizado. O Sistema Operacional hospedado precisa ser mo-
dicado para tirar proveito dessa caracterstica.
Xen
Virtualizao Ba-
seada em Conti-
neres
Ao invs de executar uma Mquina Virtual completa, essa tc-
nica prov contineres em nvel de Sistema Operacional, basea-
dos em espaos de usurio distintos. Em cada continer, o hard-
ware, bem como o Sistema Operacional e seu kernel, so idnti-
cos aos subjacentes.
OpenVZ
Tabela 2.1. Tcnicas de virtualizao.
Tal alternativa extremamente exvel, pois permite o uso de software personali-
zado, e relativamente barata, visto que no demanda o uso de hardware especco
4
. No
entanto, essa abordagem traz consigo os problemas da rea de virtualizao de servido-
res, alguns deles mencionados nas Sees 2.5 e 2.6. Um estudo geral sobre os proble-
mas de segurana advindos do uso da virtualizao pode ser encontrado no trabalho de
[van Cleeff et al. 2009].
4
A virtualizao de mquinas est disponvel nos computadores pessoais, em sistemas operacionais de
uso comum (Windows, Linux e OSX).
2.3.3. Redes Programveis
Roteadores programveis vem sendo utilizado para possibilitar a criao de redes
virtuais. Dentre as diversas tcnicas empregadas para atribuir programabilidade rede,
a que tem tido maior sucesso no passado recente consiste na criao de regras de uxos
para permitir o particionamento lgico da rede fsica. Fluxos de trfego pertencentes a
redes virtuais distintas so tratados com seus prprios conjuntos de regras, possibilitando
seu isolamento.
OpenFlow [McKeown et al. 2008], uma das tcnicas mais promissoras para a im-
plementao dessa tecnologia, consiste no uso de um protocolo seguro para a comunica-
o com os roteadores, dispositivos com suporte a esse protocolo e um controlador central
(ou potencialmente distribudo) para criar e gerenciar as regras dos roteadores. O Open-
Flow originou a iniciativa ONF (Open Networking Foundation), organizao comandada
por grandes empresas da rea de redes de computadores com a misso de difundir esse
tipo de tecnologia. Tal iniciativa ser descrita em mais detalhes na Seo 2.7.
2.4. Taxonomia
Essa seo descreve a taxonomia usada para organizar os trabalhos na rea. Para
esse propsito, duas classicaes bem conhecidas da rea de segurana em redes de
computadores foram escolhidas. Os artigos foram organizados de acordo com as ameaas
de segurana que visam mitigar e, aps, pelos servios de segurana que visam prover.
Como existem denies distintas para esses conceitos por parte de diferentes autores,
tais classicaes so explicadas, em linhas gerais, nas subsees seguintes. A ligao
das mesmas com a rea de segurana em redes virtualizadas se d, respectivamente, nas
sees 2.5 e 2.6.
Alm dessas duas classicaes amplas, subcategorias foram criadas de forma a
aumentar a granularidade da taxonomia. A Figura 2.2 apresenta a classicao hierr-
quica completa que ser usada nas prximas duas sees desse captulo. As caixas de
cor cinza escuro representam as categorias amplas usadas na literatura, enquanto que as
caixas brancas reetem subdivises propostas e criadas pelos autores.
2.4.1. Ameaas de Segurana
H uma srie de aes maliciosas, ou ameaas, que podem violar restries de
segurana de sistemas computacionais. [Shirey 2000] descreve e divide as consequncias
de tais ameaas em quatro categorias, especicamente divulgao, fraude, disrupo e
usurpao.
Divulgao no autorizada denida como a obteno de acesso no autorizado
a informaes protegidas. Dados sigilosos podem ser erroneamente expostos a entidades
no autorizadas, ou adquiridos por atacantes que burlam a segurana de um sistema.
Fraude caracterizada pela tentativa intencional de iludir outras entidades. Por
exemplo, uma entidade maliciosa pode enviar informaes falsas ou incorretas a outras,
levando-as a acreditar que tais informaes so corretas. Identidades falsas podem ser
usadas de modo a incriminar outrem ou obter acesso ilegtimo.
Ameaas
Divulgao
Fraude
Disrupo
Usurpao
Vazamento de Informaes
Interceptao de Informaes
Introspeco
Fraude de Identidade
Explorao de Vulnerabilidades
Ataques de Negao de Servio
Sobrecarga de Recursos Fsicos
Perda de Entradas de Registro
Ataques de Replay
Complicaes em Migrao
Servios
Controle de Acesso
Autenticao
Confidencialidade
Integridade
No-repdio
Disponibilidade
Gerenciamento de Recursos Fsicos
Migrao de Recursos Fsicos
Isolamento de Recursos Fsicos
Escalabilidade e Desempenho
Domnios Virtuais Confiveis
Sandboxes
Interoperabilidade Entre Federaes
Baseada em Certificados
Baseada em Chaves
Criptografia
Marcas Temporais
Limitar Introspeco
VLANs e VPNs
Tunelamento e Criptografia
Caminhos Variveis
Limitar Introspeco
Resilincia de Redes Virtuais
Figura 2.2. Taxonomia usada nesse captulo.
Disrupo signica causar a falha ou a degradao de sistemas, afetando negativa-
mente os servios providos pelos mesmos. Isso pode ser feito por meio da incapacitao
direta de um componente do sistema ou dos canais utilizados para transmitir as informa-
es, ou ento induzindo o sistema a transmitir informaes corrompidas.
Finalmente, por meio da usurpao, atacantes podem obter controle no autori-
zado sobre um sistema. Tal controle no autorizado pode permitir que atacantes acessem
dados ou servios protegidos de forma ilegtima, ou que adulterem o prprio sistema para
causar comportamento incorreto ou malicioso.
2.4.2. Servios de Segurana
Em virtude da existncia das ameaas previamente descritas, sistemas computaci-
onais devem prover uma srie de servios com o objetivo de manter um nvel desejvel
de segurana. [Stallings 2006] categoriza esses servios essenciais em seis subdivises,
respectivamente controle de acesso, autenticao, condencialidade, integridade, no-
repdio e disponibilidade.
O controle de acesso permite que um sistema administre quais entidades podero
acessar suas funes, e quais permisses cada uma ter. Para conceder direitos de acesso
e permisses individuais, entidades devem estar propriamente autenticadas no sistema.
O propsito da autenticao assegurar que entidades comunicando-se entre si
so, de fato, as entidades que armam ser. O receptor de uma mensagem deve ser capaz
de identicar corretamente seu originador, e uma entidade no deve ser capaz de usar a
identidade de outra.
Por condencialidade de dados adequada, entende-se assegurar que terceiros no
tenhamacesso a informaes condenciais sendo transmitidas entre duas entidades. Alm
disso, o sistema deve evitar que atacantes possam derivar informaes sensveis por meio
da anlise de caractersticas do uxo de dados.
O servio de integridade de dados tem como propsito garantir que dados arma-
zenados por entidades ou transmitidos por uma rede no sero corrompidos, adulterados
ou destrudos. Ataques como duplicao, modicao, reordenamento e reenvio de men-
sagens devem ser prevenidos. Adicionalmente, mecanismos para recuperao de dados
corrompidos tambm podem ser oferecidos.
Em comunicaes entre pares, o no-repdio prov uma forma de resolver dispu-
tas quando uma entidade nega ter efetuado uma ao. O objetivo desse servio prevenir
que entidades neguem falsamente terem participado de qualquer atividade relacionada
rede.
A disponibilidade de um sistema tambm denida como um servio de segu-
rana. Recursos do sistema devem estar disponveis no momento em que entidades au-
torizadas os requisitam, e o sistema deve obedecer suas especicaes de desempenho.
Para manter a disponibilidade, contramedidas para ataques como os de negao de servio
devem ser providas.
2.5. Ameaas de Segurana
Nesta seo, apresenta-se uma lista abrangente de ameaas encontradas em ambi-
entes de virtualizao de redes. Essas ameaas foram agrupadas de acordo com a classi-
cao descrita na Subseo 2.4.1.
2.5.1. Divulgao
Em um ambiente em que recursos fsicos so compartilhados entre diversas redes
virtuais, h uma srie de comportamentos que podem resultar em divulgao indevida de
informaes. Ameaas relacionadas divulgao de informaes privadas ou condenci-
ais so explicadas a seguir.
Vazamento de Informaes
[Cavalcanti et al. 2006] mencionam a possibilidade de vazamento de mensagens
entre uma rede virtual e outra. Nesse tipo de ataque, uma entidade pode divulgar informa-
es privadas ou condenciais a membros de outras redes virtuais, que no deveriam ter
acesso a tais informaes. [Wolinsky et al. 2006] descrevem um ataque similar, em que
ns virtuais enviam mensagens para fora dos limites de um ambiente de virtualizao de
redes. Dessa forma, seria possvel transmitir mensagens a ns fsicos que no pertencem
a nenhuma rede virtual.
Interceptao de Informaes
Atacantes emumambiente de rede virtual podemcapturar mensagens sendo trans-
mitidas entre duas entidades, visando acessar seu contedo. Esse tipo de ataque, descrito
por [Cabuk et al. 2007] como eavesdropping, leva ao furto de informaes conden-
ciais. Tal ataque uma ameaa comum em qualquer ambiente de redes, porm o uso de
recursos fsicos compartilhados por mltiplas redes virtuais agrava esse problema. De
acordo com esses e outros autores, como [Cui et al. 2009], solues de rede providas por
monitores de mquinas virtuais podem no isolar corretamente dados pertencentes a dife-
rentes redes virtuais. Isso signica que membros de uma rede virtual podem ser capazes
de acessar dados sendo transmitidos por outras redes virtuais compartilhando o mesmo
substrato.
Mesmo que dados dentro de pacotes de rede sejam protegidos (por exemplo, por
meio do uso de criptograa), entidades podem derivar informaes condenciais de tais
pacotes. Em ataques de anlise de trfego, descritos por [Huang et al. 2010], entidades
adquirem tais informaes atravs da anlise de caractersticas de uxos de trfego entre
entidades que esto se comunicando em redes virtuais.
Introspeco
Introspeco uma caracterstica presente em monitores de mquinas virtuais que
concede acesso a dados internos de mquinas virtuais hospedadas nestes. No entanto, de
acordo com [van Cleeff et al. 2009], tal caracterstica pode ser utilizada de forma inde-
vida ou explorada por atacantes visando divulgar dados condenciais. Esse problema
agravado pelo fato de que ns virtuais podem ser movidos ou copiados entre mltiplos
monitores de mquinas virtuais, ampliando a possibilidade de roubo de informaes.
2.5.2. Fraude
Foram identicadas trs subcategorias de ameaas que podem levar fraude em
ambientes de redes virtuais. Essas subdivises especicamente, fraude de identidade,
perda de entradas de registro e ataques de replay so explicadas a seguir.
Almde lidar comdivulgao no autorizada, [Cabuk et al. 2007] tambmdescre-
vemameaas relacionadas fraude emambientes de redes virtuais. Mais especicamente,
entidades podem injetar mensagens mal-intencionadas em uma rede virtual, iludindo as
demais e levando-as a acreditar que tais mensagens foram enviadas por outra entidade.
Certas caractersticas de ambientes de virtualizao de redes dicultam o trata-
mento de fraude de identidade. A agregao de diferentes redes virtuais em uma rede
composta, conhecida como federao, apontada por [Chowdhury et al. 2009] como uma
de tais caractersticas. A federao d margem a questes como a presena de papis dis-
tintos e possveis incompatibilidades entre mecanismos de segurana ou polticas dessas
redes. Outro fator complicador mencionado pelos autores a entrada e sada dinmica
de entidades. Tal caracterstica pode ser explorada por atacantes visando obter novas
identidades.
Outras dessas caractersticas envolvem operaes como a migrao e a duplicao
de ns virtuais, conforme mencionado por [van Cleeff et al. 2009]. O estudo dos autores
refere-se a ambientes de virtualizao em geral, portanto considera-se que tais ns virtu-
ais podem referir-se a roteadores virtuais ou estaes de trabalho virtualizadas. Se um n
virtual migrado de um ponto do substrato fsico para outro, a identidade do dispositivo
fsico que contm esse n virtual pode mudar. Alm disso, a duplicao de ns virtu-
ais, utilizada para prover redundncia, pode levar a mltiplas entidades compartilhando a
mesma identidade. Ambas essas questes podem causar inconsistncias na identicao
de origem de mensagens na rede, dando margem a ataques de fraude de identidade.
Perda de Entradas de Registro
[van Cleeff et al. 2009] tambm mencionam questes relacionadas a registros de
operaes em ambientes de virtualizao. Se informaes referentes a quais entidades
foram responsveis por cada operao na rede so armazenadas em registros dentro de
mquinas virtuais, entradas desses registros podem ser perdidas durante operaes de
rollback. Dessa forma, registros de atividades maliciosas realizadas por atacantes podem
ser perdidos. Alm disso, as chaves usadas para assinar tais entradas, armazenadas dentro
de mquinas virtuais, podem ser roubadas e copiadas por atacantes.
Ataques de Replay
[Fernandes and Duarte 2011b] mencionam ataques de replay como outra forma
de fraude em ambientes de redes virtuais. Nesse tipo de ataque, uma entidade maliciosa
captura pacotes legtimos sendo transmitidos atravs da rede e os retransmite, levando
outras entidades a acreditarem que tal mensagem foi enviada mltiplas vezes. Os autores
explicam que tais ataques podem ser lanados por roteadores virtuais com a inteno de
corromper o plano de dados do domnio atacado.
2.5.3. Disrupo
Em ambientes de virtualizao de redes, o gerenciamento adequado de recursos
crucial para evitar disrupo. Recursos virtuais devem ser cuidadosamente distribudos ao
longo do substrato fsico para evitar a sobrecarga de recursos fsicos. Adicionalmente, ns
fsicos podem falhar ou precisar ser interrompidos, causando uma preocupao constante
ao longo do ciclo de vida da rede.
Ataques de Negao de Servio
Durante seu ciclo de vida, redes virtuais podem sofrer ataques que visam causar
disrupo. Tais ataques podem se originar dentro da prpria rede virtual, ou ento de
fontes externas. A ameaa mais comum so ataques de negao de servio (DoS), citada
por diversos autores [Yu and Zhou 2008, Roschke et al. 2009, Mazzariello et al. 2010].
Sobrecarga de Recursos Fsicos
[Alkmim et al. 2011], assim como [Cheng et al. 2011] e [Zhou et al. 2010], lidam
com restries de capacidade de recursos fsicos. Atributos como a capacidade de CPU e
o limite de largura de banda devem ser levados em considerao em operaes de implan-
tao ou gerncia de redes virtuais. A sobrecarga de recursos fsicos pode levar falha de
ns virtuais, ou causar a degradao do desempenho da rede, fazendo com que o mesmo
caia abaixo dos requisitos mnimos. Tal degradao causa congestionamento e perda de
pacotes emredes virtuais, conforme armam[Zhang et al. 2009] e [He et al. 2008]. Alm
de causar disrupo em redes virtuais j estabelecidas, a sobrecarga de recursos tambm
prejudica a implantao de novas redes.
Os prprios requisitos de utilizao de recursos podem ser um ponto de con-
ito em ambientes de redes virtuais. Conforme explicado por [Marquezan et al. 2009,
Marquezan et al. 2010], mltiplas redes virtuais podem exigir uma quantidade excessiva
de recursos em uma mesma rea do substrato fsico. Tais exigncias podem ocorrer de
forma no intencional ou caracterizar um ataque coordenado. Isso acontece no s du-
rante a implantao, mas tambm durante o ciclo de vida das redes virtuais. Tais conitos
demandam uma adaptao dinmica dos recursos fsicos para evitar a interrupo ou de-
gradao dos servios de rede.
Tambm possvel que uma rede virtual cause disrupo em outra utilizando
recursos fsicos de forma excessiva. Tal preocupao explorada por diversos autores
[Govindan et al. 2009, Wu et al. 2010, Kokku et al. 2010, Fernandes and Duarte 2011b,
Fernandes and Duarte 2011a]. O isolamento e a distribuio adequada de recursos fsi-
cos entre redes virtuais so essenciais para manter o ambiente de virtualizao de redes
operando adequadamente. Isso inclui assegurar que os requisitos mnimos de cada rede
sero cumpridos, bem como proibir que redes consumam recursos alm do que lhes
permitido.
Por m, o prprio processo de virtualizao gera sobrecarga, o que causa preocu-
paes relacionadas ao desempenho e escalabilidade. Tais preocupaes so expostas
por autores como [Bhatia et al. 2008] e [El-Darieby and Rolia 2006].
Complicaes em Migrao
Migrao em tempo real pode ser necessria para redistribuir a carga de recursos
ao longo do substrato fsico, ou para compensar ns fsicos que foram interrompidos. No
entanto, a migrao em tempo real possui uma srie de desaos, expostos em diversas
publicaes [Du et al. 2010, Pisa et al. 2010, Mattos et al. 2011]. Durante esse processo,
ns virtuais que esto sendo migrados devem ser desabilitados, movidos e ento restau-
rados, o que resulta, em alguns casos, na perda de pacotes. Portanto, o tempo despendido
durante processos de migrao deve ser minimizado para evitar ou atenuar a disrupo
de servios. A migrao de recursos virtuais causa sobrecarga de desempenho e de rede,
os quais devem ser minimizados conforme possvel. Sendo assim, atacantes podem, por
exemplo, forar a migrao de ns virtuais visando causar disrupo em pontos espec-
cos do substrato fsico.
Alm disso, [Wang et al. 2008] mencionam erros humanos durante o gerencia-
mento de redes como uma fonte potencial de disrupo. possvel que erros aconteam
durante operaes de manuteno de rede ou implantaes de novos protocolos. Mesmo
que nenhum problema ocorra, a prpria manuteno programada fonte de preocupa-
es, conforme explicado por [Yeow et al. 2011]. Ademais, em alguns casos existem ns
crticos na rede provendo servios essenciais e que, portanto, no toleram interrupes.
2.5.4. Usurpao
Em um ambiente de redes virtualizadas, ataques de usurpao podem permitir que
um atacante tenha acesso a operaes privilegiadas sobre roteadores virtuais ou a dados
condenciais armazenados nestes. Tais ataques podem ser uma decorrncia de fraudes de
identidade ou de explorao de vulnerabilidades, explicados a seguir.
J mencionados na Subseo 2.5.2, os ataques de fraude podem ser usados para
personicar outra entidade dentro da rede. Dessa forma, possvel que um atacante
faa-se passar por uma entidade com alto nvel de privilgios dentro da rede, podendo,
ento, lanar mo de um ataque de usurpao. Por exemplo, a injeo de mensagens com
remetentes falsos citada por [Cabuk et al. 2007] usada para esse propsito. Ao enviar
uma mensagem que parece ter como origem uma entidade privilegiada, um atacante pode
vir a executar aes a que no teria acesso normalmente, inclusive com o propsito de
elevar seu prprio nvel de privilgios.
Explorao de Vulnerabilidades
[Roschke et al. 2009] mencionam que monitores de mquinas virtuais so suscet-
veis explorao de falhas que tirem proveito de vulnerabilidades em sua implementao.
Os autores armam que, obtendo controle sobre um monitor de mquinas virtuais, ata-
cantes podem romper o limite de mquinas virtuais para obter acesso camada de hard-
ware. Em um ambiente de redes virtualizadas que lana mo de virtualizao completa
ou paravirtualizao para criar roteadores virtuais, tal explorao de falhas pode levar um
atacante a ter controle sobre roteadores fsicos. Obtendo acesso aos dispositivos fsicos,
um atacante poderia facilmente comprometer quaisquer redes virtuais providas por tal
infraestrutura.
2.6. Servios de Segurana
Nesta seo, so exploradas as solues publicadas na literatura que visam prover
segurana e proteger o ambiente dos riscos mencionados anteriormente. Essas publica-
es foram categorizadas de acordo com os servios de segurana descritos na Subseo
2.4.2.
2.6.1. Controle de Acesso
O controle de acesso visa assegurar o cumprimento de determinados nveis de
privilgios, a m de discriminar a utilizao da rede virtual. Esse servio descrito
em duas abordagens na literatura selecionada, a saber: domnios virtuais conveis e
sandboxes, explicados a seguir.
Domnios Virtuais Conveis
[Cabuk et al. 2007] desenvolveram um arcabouo para prover redes seguras entre
grupos de mquinas virtuais. Os objetivos de segurana nessas redes incluem isolamento,
condencialidade, integridade e controle sobre o uxo de informaes. Esse arcabouo
oferece os servios de segurana mencionados por meio do uso de Domnios Virtuais
Conveis (Trusted Virtual Domains TVDs). Cada TVD representa um domnio iso-
lado, composto por elementos de virtualizao e canais de comunicao entre eles.
Nesse trabalho, os elementos de virtualizao so estaes de trabalho virtuais. No en-
tanto, os autores armam que os TVDs podem ser aplicados sobre qualquer dispositivo
com suporte virtualizao.
O controle de acesso realizado quando do ingresso de mquinas virtuais em
um TVD. Ele assegura que mquinas que no satisfaam determinados pr-requisitos
no possam participar de um TVD. Esse controle de admisso pode ser aplicado de forma
contnua, caso os pr-requisitos precisem ser atualizados, e pode exigir certicados. Alm
disso, um TVD prov polticas de acesso e barreiras de conteno para impedir o acesso
indevido.
Sandboxes
[Wolinsky et al. 2006] utilizam sandboxes nas mquinas virtuais para oferecer se-
gurana a um ambiente colaborativo de larga escala. Apesar desse trabalho focar em
redes de mquinas virtuais hospedando estaes de trabalho virtuais, tal conceito tambm
aplicvel a redes virtualizadas. Os autores utilizam sandboxes para limitar o acesso da
mquina virtual aos recursos da mquina fsica. Dessa forma, uma mquina virtual mali-
ciosa no pode acessar os dados de outras mquinas virtuais. Adicionalmente, cada m-
quina virtual suporta IPSec, possibilitando a criao de canais de comunicao seguros,
e X.509, para oferecer autenticao. O processo de autenticao, explicado na Subseo
2.6.2, utiliza certicados digitais para as mquinas virtuais, possibilitando o controle de
quais delas podem acessar a rede.
2.6.2. Autenticao
Nesta seo, so descritas as abordagens encontradas na literatura que visam pro-
ver autenticao nos ambientes de virtualizao de redes.
Interoperabilidade entre Redes Virtuais Federadas
Apesar do isolamento ser um dos principais requisitos da virtualizao de redes,
existem casos em que redes virtuais distintas podem precisar colaborar. A federao de
redes virtuais pode, por exemplo, viabilizar conectividade m-a-m perpassando dis-
positivos virtuais de redes virtuais distintas ou permitir o acesso a servios distintos.
No entanto, a interoperabilidade no pode ser garantida devido natureza heterognea
das redes virtuais (as quais podem implementar protocolos distintos e incompatveis).
[Chowdhury et al. 2009] atacam esse problema com um arcabouo que gerencia as iden-
tidades desse tipo de ambiente. O principal objetivo do trabalho prover um sistema
de identicao global que no restrinja os mecanismos de identicao utilizados local-
mente pelas redes virtuais, permitindo que cada rede virtual tenha seu esquema de nomes
interno. Alm disso, o arcabouo dene interfaces e mecanismos para possibilitar a co-
nectividade m-a-m sem prejudicar as funcionalidades internas das redes. Ademais, os
identicadores no restringem a mobilidade das mquinas ou dispositivos da rede, pois
so independentes da localizao fsica. Por m, para garantir a conana e a segurana
no sistema, o arcabouo exige que os identicadores globais sejam nicos e imutveis nos
sistemas-m.
Baseada em Certicados
[Cabuk et al. 2007] utilizam Trusted Virtual Domains (TVDs) para oferecer con-
trole de acesso e isolamento na rede. A autenticao necessria a esse controle de acesso
provida por meio de certicados digitais. Os certicados asseguram a identidade e a
conabilidade das entidades que ingressam na rede. Adicionalmente, o sistema utiliza
Redes Virtuais Privadas (Virtual Private Networks VPNs) para atribuir autenticidade s
comunicaes entre as entidades da rede.
De modo anlogo, [Wolinsky et al. 2006] utilizam o IPSec em conjunto com o
X.509 para prover autenticao e amparar o controle de acesso ao sistema. Por meio
dessas tecnologias, possvel oferecer suporte a certicados de chave pblica e listas de
revogao. Para obter acesso ao sistema, as mquinas ingressantes precisam adquirir um
certicado de alguma Autoridade Certicadora (Certication Authority CA). A autori-
dade certicadora emite certicados assinados com o endereo IP da mquina requisitante
para impedir que outras mquinas possam utilizar o mesmo certicado.
Baseada em Chaves
[Fernandes and Duarte 2011a, Fernandes and Duarte 2011b] apresentam uma ar-
quitetura, o XNetMan, para prover roteamento eciente, isolamento de recursos e um
canal de comunicao seguro entre os roteadores virtuais e o Monitor de Mquinas Vir-
tuais (Virtual Machine Monitor VMM) hospedados em um dado roteador fsico. Para
garantir a ecincia do sistema, os roteadores virtuais copiam as informaes pertinentes
ao roteamento para o Monitor de Mquinas Virtuais nesse caso referido como hipervi-
sor. Esse processo realizado atravs do mdulo de separao de planos, o qual separa o
plano de dados (lista com as regras de roteamento), do plano de controle (responsvel pela
criao das regras propriamente ditas). Dessa forma, pacotes identicados pelas regras da
tabela do hipervisor no precisam ser redirecionados aos roteadores virtuais, gerando um
ganho signicativo de desempenho. No entanto, o processo de cpia precisa ser auten-
ticado de modo que um roteador malicioso no possa comprometer o plano de dados de
outro roteador.
Para garantir que as identidades no possam ser forjadas, o sistema exige autenti-
cao mtua entre os roteadores virtuais e o VMM. A soluo proposta utiliza criptograa
assimtrica para realizar uma etapa inicial de troca de chaves de sesso, viabilizando a cri-
ao de um canal de comunicao seguro. A Figura 2.3 ilustra a arquitetura desenvolvida
pelos autores. Cada roteador virtual, ao ser instanciado, conecta-se ao hipervisor pelo
paradigma cliente-servidor. Aps o procedimento de troca de chaves, o mdulo de co-
municao segura utilizado pelos demais mdulos do sistema para viabilizar a troca de
mensagens com o hipervisor.
Hipervisor (Dom0)
XNetMan (servidor)
Comunicao
Segura
Roteador Virtual 3 (DomU
3
)
2
)
1
)
XNetMan (cliente)
Comunicao
Segura
Separao
de Planos
. . .
Separao
de Planos
. . .
Interfaces de Rede (virtuais)
Interfaces de Rede (virtuais)
Interfaces de Rede (fsicas)
Figura 2.3. Verso simplicada da arquitetura de [Fernandes and Duarte 2011a,
Fernandes and Duarte 2011b], exibindo os mdulos responsveis pela comuni-
cao segura.
2.6.3. Condencialidade
Conforme mencionado anteriormente, a condencialidade um servio de segu-
rana extremamente importante em ambientes em que dispositivos fsicos so compar-
tilhados por mltiplas entidades. Esta subseo explora as propostas apresentadas na
literatura para o aprovisionamento desse servio.
VLANs e VPNs
Os objetivos de segurana tratados por [Cabuk et al. 2007] incluem integridade,
isolamento, condencialidade de dados e controle sobre o uxo de informaes. Os l-
timos trs objetivos mencionados, segundo os autores, esto diretamente relacionados e
podem ser tratados por um servio de condencialidade de dados. O arcabouo desenvol-
vido utiliza TVDs (Trusted Virtual Domains) para controlar o acesso aos dados. Porm,
mquinas virtuais pertencentes a diferentes TVDs podem ser hospedadas na mesma m-
quina fsica. Portanto, preciso garantir um isolamento apropriado para prevenir que
dados de um TVD possam ser acessados por membros de outro TVD.
A soluo proposta para esse desao utiliza uma combinao entre Redes Lo-
cais Virtuais (Virtual Local Area Networks VLANs) e Redes Virtuais Privadas (Virtual
Private Networks VPNs). As VLANs so utilizadas para identicar os pacotes das dife-
rentes redes. Com isso, dispositivos com suporte a essa tecnologia realizam o roteamento
dos pacotes para as interfaces apropriadas, fornecendo um isolamento adequado. Por ou-
tro lado, um meio fsico no convel requer um nvel de segurana maior. Portanto,
caso necessrio, VPNs so utilizadas para oferecer condencialidade de dados por meio
de criptograa m-a-m.
Tunelamento e Criptograa
[Wolinsky et al. 2006] utilizam tunelamento para assegurar isolamento ao trfego
de comunicao de rede entre mquinas virtuais (ou seja, estaes de trabalho). O tune-
lamento provido por meio de duas abordagens. Na primeira abordagem, o sistema ope-
racional hospedeiro executa um software de tunelamento que captura os pacotes oriundos
das interfaces fsicas e repassa-os s mquinas virtuais. Na segunda abordagem, o soft-
ware de tunelamento executado nas mquinas virtuais e o trfego restringido na rede
virtual por meio de regras instanciadas em um rewall. [Wolinsky et al. 2006] concluem
que a segunda abordagem mais simples e fcil de implantar, mas salientam que usurios
maliciosos podem acabar subvertendo o rewall e comprometendo o sistema. Apesar do
foco desse trabalho ser o isolamento de estaes de trabalho virtuais, os autores deste
minicurso acreditam que as tcnicas utilizadas para tal isolamento podem ser estendidas
a roteadores virtuais em um ambiente de virtualizao de redes.
[Fernandes and Duarte 2011a, Fernandes and Duarte 2011b] lidam com a con-
dencialidade de dados na comunicao entre roteadores virtuais, instanciados em mqui-
nas virtuais em um roteador fsico (implementado em uma mquina de uso geral), e o Mo-
nitor de Mquinas Virtuais (Virtual Machine Monitor VMM), localizado nesse mesmo
roteador. Aps uma etapa inicial de troca de chaves de sesso, descrita na Subseo 2.6.2,
os roteadores virtuais utilizam criptograa simtrica para estabelecer a comunicao com
o VMM. Por meio dessa tcnica, possvel realizar a transmisso segura de dados.
[Huang et al. 2010] apresentam um arcabouo para prover roteamento seguro. No
ambiente apresentado, as informaes de roteamento propagadas pela rede virtual so
condenciais, devendo permanecer em sigilo de determinados ns da rede. As informa-
es de roteamento so categorizadas em mltiplos grupos, e chaves de grupo so atribu-
das aos roteadores. Dessa forma, as informaes de roteamento podem ser criptografadas
e somente os roteadores que possuam a chave correta podem descriptografar essas infor-
maes. Assim, informaes referentes a um grupo so protegidas contra acesso indevido
por parte de outros grupos, outras redes virtuais ou da rede fsica.
Caminhos Variveis
Alm de criptografar informaes de roteamento, [Huang et al. 2010] usam ca-
minhos variveis nas redes virtuais para propagar o uxo de dados. De acordo com os
autores, essa abordagem de particionamento de caminhos auxilia a mitigar ataques de
anlise de trfego provenientes da rede fsica.
Limitar Introspeco
Finalmente, [van Cleeff et al. 2009] apresentam recomendaes para o uso seguro
da virtualizao. Uma dessas limitar, ou mesmo desabilitar, o uso da ferramenta de
introspeco, pois essa permite que os Monitores de Mquinas Virtuais tenham acesso a
informaes internas das mquinas virtuais. Apesar de ser uma ferramenta til, atacantes
em um ambiente de redes virtualizadas podem tirar vantagem dessa tcnica para obter
informaes armazenadas em roteadores virtuais.
2.6.4. Integridade
A integridade dos dados uma propriedade de suma importncia para as redes vir-
tuais, prevenindo que entidades possam adulterar os dados que trafegam nos dispositivos
compartilhados.
Criptograa
Alm de autenticao (ou seja, integridade de origem) e condencialidade, o ar-
cabouo desenvolvido por [Cabuk et al. 2007] faz uso de VPNs para prover integridade
de dados s redes. O uso de protocolos de tunelamento com criptograa previne que en-
tidades maliciosas possam manipular as mensagens que trafegam na rede. Conforme dis-
cutido anteriormente, os autores utilizam o IPSec como protocolo de tunelamento. Alm
disso, essa tecnologia tambm utilizada para oferecer o servio de integridade de dados.
Marcas Temporais
Alm de utilizar criptograa para prover condencialidade dos dados transferidos,
a arquitetura proposta por [Fernandes and Duarte 2011a, Fernandes and Duarte 2011b]
adiciona timestamps nas mensagens trocadas. Tal tcnica possibilita a deteco de men-
sagens duplicadas e ajuda a evitar ataques de replay.
Limitar Introspeco
Alm de mitigar o roubo de informaes, desabilitar ou limitar o uso da ferra-
menta de introspeco tambm previne adulterao dos dados. [van Cleeff et al. 2009]
armam que essa funcionalidade possibilita que o VMM altere as aplicaes que execu-
tam dentro de ns virtuais, o que pode ocasionar inconsistncias. Outra recomendao
consiste em projetar aplicaes especcas que auxiliem o processamento em lote e o uso
de checkpoints. De acordo com os autores, isso acaba minimizando problemas de segu-
rana associados a operaes de restaurao, os quais poderiam ameaar a integridade do
sistema.
2.6.5. No-repdio
O servio de no-repdio possibilita o fornecimento de evidncias sobre as aes
de cada entidade, permitindo que meios legais possam provar quais aes (potencial-
mente maliciosas) foram executadas por quais entidades. Esse servio muito importante
no contexto de virtualizao de redes, em que diversos dispositivos fsicos so compar-
tilhados entre diferentes usurios. Apesar disso, nenhuma das publicaes avaliadas tem
esse servio como foco de estudo.
2.6.6. Disponibilidade
A disrupo da rede virtual pode ocorrer em diferentes fases ao longo do seu
tempo de vida. Oferecer disponibilidade signica proteger a rede durante cada uma des-
sas fases. Os trabalhos relacionados a esta subseo foram categorizados reetindo essa
diviso.
Gerenciamento de Recursos Fsicos
No contexto de virtualizao de redes, o gerenciamento de recursos fsicos con-
siste no particionamento, correto e eciente, dos recursos do substrato fsico aos rotea-
dores e enlaces virtuais. A distribuio eciente desses recursos previne a sobrecarga da
rede fsica, alm de ajudar a minimizar os efeitos ocasionados por falhas, auxiliando na
disponibilidade da rede.
Em [Alkmim et al. 2011], apresenta-se um algoritmo para mapeamento de redes
virtuais que considera as caractersticas dos ns fsicos, dos enlaces fsicos e das ima-
gens que contm o conjunto de software e protocolos necessrios para instanciar as redes
virtuais. Utilizando esse trabalho como base, os autores deste minicurso esto desenvol-
vendo uma arquitetura que considera, tambm, requisitos de segurana. Dessa forma,
clientes podem especicar o nvel de segurana desejado para suas redes virtualizadas
no momento em que realizam uma requisio. Isso se d por meio da adio de carac-
tersticas como redundncia e criptograa do disco virtual, alm de identicadores que
garantam a autenticidade de roteadores virtuais. Pode-se, tambm, solicitar que os enla-
ces fsicos alocados para sua rede sejam criptografados e/ou exclusivos, evitando, assim, a
interceptao e o vazamento de informaes. No que se refere s imagens utilizadas para
instanciar os roteadores virtuais, estas podem conter servios que garantam a segurana
do sistema operacional dos mesmos.
[Cheng et al. 2011] propem uma modelagem matemtica para o problema do
mapeamento de redes virtuais em substratos fsicos. Os autores lanam mo de um es-
quema de classicao e ordenamento para realizar esse mapeamento de maneira eci-
ente. Nesse processo de classicao, os atributos de cada roteador ou enlace fsico ou
virtual so levados em considerao. Roteadores fsicos so avaliados de acordo com a
capacidade de processamento disponvel e a largura de banda de seus enlaces. O processo
repetido recursivamente na vizinhana para determinar a importncia do roteador. Dessa
forma, roteadores que possuem vizinhos com classicao elevada so considerados mais
importantes em relao a outros. Um exemplo pode ser observado na Figura 2.4. A
ilustrao apresenta dois segmentos de uma mesma rede, salientando os roteadores R
1
e
R
2
. Nesse caso, ambos possuem as mesmas capacidades de processamento e largura de
banda (20 unidades de processamento e quatro enlaces com 8 unidades de banda
5
).
5
[Cheng et al. 2011] tratam o problema de maneira genrica e no especicam nenhuma unidade de
medida. Sendo assim, os autores deste minicurso utilizaram os termos unidades de processamento e
unidades de banda para capturar essa generalidade. No entanto, em casos reais seria necessrio utilizar
8
8
8
8
20
10
10 10
5
5
5 5
10
D
1
R
1
A
1
B
1
C
1
8
8
8
8
20
7
7 7
3
3
5
7
D
2
R
2
A
2
B
2
C
2
Figura 2.4. Roteadores R
1
e R
2
possuem mesma capacidade de processamento
e largura de banda total, e mesma topologia. No entanto, a vizinhana de R
1
possui mais recursos disponveis que a vizinhana de R
2
. Portanto, R
1
tem maior
importncia em relao a R
2
[Cheng et al. 2011].
Apesar de serem idnticos, os roteadores da vizinhana de R
1
possuem maior capacidade
do que os da vizinhana de R
2
. Portanto, R
1
ter uma classicao melhor em relao a
R
2
.
Aps o processo de classicao, tanto da rede fsica quanto das redes virtuais,
ocorre o processo de mapeamento propriamente dito. Nesse procedimento, os ns virtuais
com maior classicao so mapeados em ns fsicos com maior classicao. Analo-
gamente, ns virtuais com menor classicao so mapeados em ns fsicos com menor
classicao (sempre respeitando as demandas das redes virtuais e as capacidades da rede
fsica). Essa estratgia visa realizar o mapeamento das redes virtuais em regies relati-
vamente similares na rede fsica, minimizando indiretamente a quantidade de gargalos
formados aps o mapeamento. Os autores tambm desenvolvem diversas mtricas para
comparar essa estratgia com a literatura. Eles concluem que os algoritmos propostos
oferecem um ganho representativo em relao aos trabalhos anteriores.
No contexto da virtualizao de redes, provedores de infraestrutura fsica visam
maximizar o uso dos seus recursos de forma a aumentar o lucro obtido. Os provedores de
servio, por outro lado, procuram utilizar os recursos contratados da melhor forma poss-
vel. [Zhou et al. 2010] utilizam teoria dos jogos para modelar a relao entre essas duas
entidades na forma de um jogo no-cooperativo. Os autores tambm utilizam incentivos
econmicos para encorajar o comportamento eciente (do ponto de vista do substrato)
entre os jogadores. Como as redes virtuais no podem coordenar estratgias entre si, os
provedores de infraestrutura oferecem esquemas de preo para encorajar essas redes a
mudarem suas estratgias. De acordo com os autores, a soluo atinge o Equilbrio de
alguma unidade adequada situao (por exemplo, percentual de carga ou nmero de ncleos para
processadores, e pacotes ou bits por segundo para largura de banda).
Nash situao na qual cada jogador opta pela melhor estratgia global.
A alocao tima da largura de banda entre as redes virtuais tambm o objetivo
de [He et al. 2008]. Nesse trabalho, o substrato fsico ajusta, periodicamente, o compar-
tilhamento de banda entre as redes. Esse ajuste dinmico da largura de banda considera o
atraso de propagao e a vazo de cada enlace. Os autores tambm utilizam um confor-
mador de trfego para obrigar as redes virtuais a cumprirem as alocaes em cada enlace.
O sistema proposto oferece uma rede virtual para acomodar cada tipo de classe de trfego,
com protocolos de controle personalizados. O processo de balanceamento leva em consi-
derao o valor de satisfao de cada rede virtual e o custo de congestionamento de
cada enlace (o qual aumenta de acordo com o delay e a perda de pacotes). Alm disso,
sempre que possvel, o sistema distribui o trfego da rede entre os mltiplos caminhos
que interconectam os sistemas-m. Isso feito por meio do uso de rtulos; roteadores
virtuais colocam rtulos em cada pacote para for-los a seguir caminhos especcos. Os
autores apresentam uma srie de experimentos para demonstrar a capacidade do sistema
em se adaptar a congestionamentos e falhas em enlaces, e de convergir para o valor timo.
Migrao de Recursos Fsicos
Com base em trabalhos anteriores, possvel notar que existe uma demanda por
solues que considerem a dinamicidade das redes virtuais. De fato, os requisitos ou
a demanda por recursos podem mudar. Alm disso, falhas no substrato podem exigir
a realocao de algumas redes. O remapeamento das redes virtuais frequentemente
necessrio para acomodar os novos requisitos, evitar sobrecargas, ou compensar falhas
nos recursos fsicos. A migrao de recursos tambm pode ser necessria para otimizar a
utilizao do substrato.
A Figura 2.5 ilustra, em linhas gerais, como se d o processo de migrao. Rote-
adores e enlaces devem ser realocados durante esse processo, permitindo que o uxo de
mensagens seja redirecionado. Primeiramente, o roteador virtual a ser migrado (RV2)
movido da origem (Roteador Fsico B) ao destino (Roteador Fsico C). A seguir, os u-
xos que passam pelo roteador realocado precisam ser movidos. Na imagem esquerda,
o uxo original representado por linhas slidas, e o uxo adaptado nova topologia,
por linhas tracejadas. Em geral, durante essa etapa ambos os roteadores (antigo e novo)
funcionam paralelamente. Uma vez que todos os uxos foram movidos, o roteador antigo
pode ser desativado.
Salienta-se que a maioria dos artigos dessa categoria foca na migrao como uma
forma de tolerncia a falhas. No entanto, tal ao pode ser utilizada como uma resposta
a ataques, visando, por exemplo, mitigar os efeitos de uma tentativa de negao de ser-
vio. A seguir descreve-se alguns dos principais trabalhos que lidam com o processo de
migrao de redes virtuais e seus componentes.
[Marquezan et al. 2009, Marquezan et al. 2010] introduzem uma abordagem dis-
tribuda para a realocao de roteadores e enlaces virtuais. O processo de realocao
efetuado em cinco etapas. Primeiro, heursticas so utilizadas para identicar padres de
trfego que sobrecarregam os enlaces do substrato. Essa ao identica os roteadores que
precisam ser realocados. No segundo estgio, roteadores vizinhos na rede fsica trocam
informaes sobre os roteadores que sero realocados. A seguir, cada vizinho analisa essa
Roteador Fsico A Roteador Fsico B
Roteador Fsico C
RV1 RV2
Roteador Fsico A Roteador Fsico B
Roteador Fsico C
RV1
RV2
Figura 2.5. Exemplo de migrao de um roteador virtual (adaptado de
[Wang et al. 2008]). O roteador virtual RV2 movido do roteador fsico B para
o roteador fsico C, e os enlaces da rede virtual so adaptados para preservar a
topologia original.
informao e o roteador fsico que precisa realocar o roteador virtual decide para onde este
ser movido. Essa deciso nalizada no quarto estgio, quando os recursos necessrios
so alocados no destino. Somente no quinto e ltimo estgio, os roteadores e enlaces vir-
tuais so efetivamente movidos. De acordo com os autores, esse processo transparente
para os roteadores virtuais; porm, durante o processo de realocao, os mesmos cam
inacessveis e todos os pacotes relacionados aos roteadores virtuais envolvidos precisam
ser enleirados. A avaliao apresentada na primeira publicao [Marquezan et al. 2009]
mostra que o tempo de inacessibilidade (downtime) linearmente proporcional quanti-
dade de armazenamento utilizada pelos roteadores virtuais envolvidos na migrao.
[Wang et al. 2008] propem o conceito de migrao em tempo real como uma
primitiva de gerenciamento de rede. A arquitetura proposta oferece virtualizao de ro-
teadores fsicos, baseada na separao entre os planos de controle e dados, o que permite
que roteadores virtuais sejam movidos livremente entre roteadores fsicos. Para oferecer
suporte a esse processo de migrao, os autores propem um hipervisor para operar entre
esses dois planos. O processo propriamente dito dividido em cinco etapas, e pode ser
visualizado na Figura 2.6.
Inicialmente, tneis so estabelecidos entre os roteadores fsicos fonte e destino,
permitindo que o plano de controle continue em funcionamento durante o processo de
migrao (Figura 2.6.a). A segunda etapa envolve a instanciao de uma nova imagem
do roteador virtual no roteador fsico de destino. Os autores presumem que todos os rote-
adores virtuais utilizam a mesma imagem, disponibilizada dentro de cada roteador fsico.
Isso elimina a necessidade de copi-la atravs da rede; somente os arquivos de congu-
rao precisam ser copiados. No terceiro passo, uma imagem (snapshot) da memria
copiada do roteador fonte para o destino, e o roteador virtual restaurado. O resultado da
segunda e terceira etapas exibido na Figura 2.6.b.
No quarto passo, ocorre o processo de clonagem do plano de dados (Figura 2.6.c).
Devido ao uso do hipervisor, o plano de dados no precisa ser copiado atravs da rede,
visto que o plano de controle, migrado para o destino na etapa 3, capaz de recri-lo. A
ltima etapa realiza a migrao de todos os enlaces do roteador fonte para o destino (Fi-
gura 2.6.d). Esse processo realizado de forma assncrona; os planos de dados de ambos
Roteador Fsico A
Roteador Fsico B
RV1
(a) Instanciao de tneis para redi-
recionamento de mensagens
Roteador Fsico A
Roteador Fsico B
RV1
(b) Plano de controle remoto com re-
direcionamento de mensagens
RV1
Roteador Fsico B
Roteador Fsico A
(c) Plano de dados duplicados du-
rante migrao assncrona de enlaces
Roteador Fsico B
Roteador Fsico A
RV1
(d) Remoo do plano de dados an-
tigo e dos tneis
Trfego de dados 2 Redirecionamento de mensagens
Trfego de dados 1 Mensagens
Figura 2.6. Representao grca de diferentes etapas do processo de migrao
proposto por [Wang et al. 2008].
os roteadores permanecem ativos enquanto os enlaces so gradativamente transferidos da
origem ao destino. Os autores realizam experimentos para demostrar que o processo no
causa disrupo no plano de dados e tem impacto mnimo sobre o plano de controle.
De forma anloga, [Pisa et al. 2010] propem um modelo de migrao em tempo
real com separao de planos, com o objetivo de minimizar a perda de pacotes durante o
processo. O plano de controle reside em cada roteador virtual, ao passo que o plano de
dados mantido em um domnio separado no Monitor de Mquinas Virtuais. O processo
inicia pela cpia das pginas de memria modicada, do roteador fonte para o destino.
Durante essa etapa, o caminho de dados (data path) mantm-se ativo, e os pacotes so
salvos em um buffer para que sejam entregues no nal do processo de migrao. Uma vez
que a cpia de memria foi completada, o roteador virtual reinstanciado em sua nova
localizao, e as conexes de rede necessrias so criadas. Aps essa etapa, um tnel
criado entre o novo roteador e o antigo, permitindo que os pacotes de controle salvos
possam ser transferidos, e que novas mensagens de controle possam ser encaminhadas.
Por m, uma mensagem do tipo ARP reply enviada em modo broadcast para atualizar
os enlaces, e o caminho de dados do antigo roteador removido. Os autores vericam,
atravs de experimentos, que esse processo de migrao possui um tempo de inacessi-
bilidade menor em comparao com processos de migrao sem separao de planos.
Adicionalmente, nenhum pacote perdido durante o processo.
[Mattos et al. 2011] apresentam outra proposta baseada na separao de planos. A
maior diferena entre essa e as demais abordagens o uso de um plano de dados baseado
em uxos (ow-based data plane). O processo de migrao descrito pelos autores com-
posto de trs etapas. Na primeira etapa, o plano de controle migrado do roteador fonte
ao destino de forma similar ao esquema anterior. Na etapa seguinte ocorre a migrao do
plano de dados, quando todos os uxos relacionados ao roteador fonte so migrados ao
destino. Durante essa etapa, preciso adaptar cada uxo de acordo com o novo mape-
amento entre as interfaces fsicas e virtuais do roteador destino. Finalmente, os enlaces
virtuais entre o roteador virtual destino e os seus vizinhos precisam ser migrados para o
novo roteador fsico. Para realizar essa operao, novas entradas so adicionadas s tabe-
las de uxo dos roteadores localizados entre o novo roteador e seus destinos virtuais. Os
experimentos realizados mostram que o esquema utilizado reduz o tempo de suspenso
do plano de controle, bem como o tempo total do processo de migrao. Alm disso, no
provoca perda adicional de pacotes durante o processo, apesar de existir a possibilidade
dos mesmos serem recebidos fora de ordem.
No cenrio considerado pelas publicaes anteriores, a operao de transfern-
cia de memria entre os roteadores uma parte importante do processo de migrao.
[Du et al. 2010] apresentam uma abordagem eciente para essa etapa de propagao de
memria. Apesar dessa publicao se referir a ambientes de virtualizao em geral, e no
especicamente virtualizao de redes, ela aplicvel nesse contexto. Para otimizar o
processo de migrao, pginas de memria so agrupadas em faixas (stripes) de tama-
nhos iguais, e a ordem na qual as mesmas so transferidas depende da taxa de escrita de
cada uma. Dessa forma, pginas de memria com alta taxa de escrita so transferidas por
ltimo, absorvendo mais modicaes antes da transferncia. Como resultado, minimiza-
se o nmero de pginas sujas (dirty memory pages) a serem transferidas. A largura de
banda da rede tambm levada em considerao e utilizada como limiar para regular a
transferncia de pginas com alta taxa de escrita. Experimentos mostram que essa so-
luo reduz o perodo de inatividade (downtime), a quantidade de pginas de memria
transferidas e, por consequncia, o tempo total de migrao.
Isolamento de Recursos Fsicos
Outra preocupao o abuso de recursos por parte de redes virtuais. As redes vir-
tuais podem tentar utilizar a capacidade mxima dos dispositivos fsicos para maximizar
seu desempenho. Se o ambiente no estiver adequadamente protegido, esse comporta-
mento pode levar exausto dos recursos fsicos, comprometendo a disponibilidade das
outras redes virtuais que compartilham o mesmo substrato. Portanto, os recursos fsicos
precisam ser compartilhados de maneira justa, e as aes efetuadas por uma rede virtual
no deveriam impactar (negativamente) as outras.
De acordo com [Wu et al. 2010], a granularidade do compartilhamento de recur-
sos fsicos dos processadores realizada por ncleo de processamento (core). Os autores
armam que, para prover um nvel adequado de escalabilidade virtualizao de redes, a
granularidade do compartilhamento deve ser maior. Dessa forma, o sistema proposto per-
mite que mltiplas threads compartilhem o mesmo ncleo concorrentemente, com isola-
mento e utilizao justa do poder de processamento. No entanto, abordagens multithread
tipicamente consideram um ambiente cooperativo, o que no o caso da virtualizao
de redes. Os autores consideram um mecanismo que possibilita a associao de pesos
para cada thread, de forma a incrementar ou decrementar suas prioridades. O mecanismo
proposto tambm leva em considerao o histrico do uso de processamento cada thread.
O tempo de inatividade tambm considerado para garantir que as threads no quem
ociosas por muito tempo. A avaliao realizada pelos autores mostra que o mecanismo
proposto distribui corretamente o poder de processamento de acordo com os pesos de-
nidos. Ademais, apesar do mecanismo ter um custo em capacidade de processamento,
ele prov uma utilizao melhor dos recursos em comparao com abordagens de menor
granularidade.
[Kokku et al. 2010] propem um esquema de virtualizao de redes que fornece
o servio de isolamento de recursos enquanto busca maximizar a utilizao dos mesmos.
O esquema proposto capaz de gerenciar os recursos compartilhados para tratar, simulta-
neamente, reservas baseadas em largura de banda e em recursos de processamento. Cada
fatia (slice) de reserva de recurso separada em dois grupos de acordo com seu tipo; es-
tas so tratadas de maneira independente pelo escalonador de fatias (slice scheduler). O
escalonador calcula o peso para cada fatia baseando-se na sua reserva e na sua taxa m-
dia de utilizao de recursos. Esse ento escalona a fatia com o peso mximo calculado
para o prximo instante. De acordo com os autores, o prottipo implementado capaz de
assegurar que cada fatia atinja a reserva solicitada.
[Fernandes and Duarte 2011b] apresentam um monitor de rede que utiliza a se-
parao de planos para propiciar o isolamento de recursos no ambiente de virtualizao
de redes. O sistema capaz de alocar os recursos utilizando reserva xa, alm de re-
distribuir os recursos ociosos para atender as redes virtuais com maior demanda. Alm
disso, um administrador capaz de controlar a quantidade de recursos utilizada por cada
rede virtual, e congurar prioridades para a utilizao dos recursos ociosos. O sistema
monitora, continuamente, o consumo de recursos fsicos por cara roteador virtual. Caso
algum roteador virtual exceda o seu uso mximo permitido de banda, processamento ou
armazenamento, punido atravs do descarte de pacotes ou de um percentual das rotas
armazenadas. Punies mais graves so utilizadas caso no haja recursos fsicos ociosos.
Por outro lado, as punies so gradualmente reduzidas caso o roteador volte a consumir
somente os recursos alocados. Os autores armam que o sistema capaz de prevenir a
sobrecarga dos recursos fsicos, e que os pacotes descartados no causam grande impacto
no trfego da rede.
Em outra publicao [Fernandes and Duarte 2011a], os mesmos autores estendem
o monitor de rede descrito anteriormente. Esse novo sistema capaz de controlar re-
servas de curto ou longo prazos. Reservas de curto prazo podem ser alocadas sob
demanda ou de forma exclusiva. Reservas de curto prazo sob demanda so alocadas
somente quando forem necessrias. Por outro lado, reservas de curto prazo exclusivas
garantem que uma rede virtual sempre ter a quantidade de recursos alocada, mesmo que
uma parcela destes esteja ociosa. Reservas de longo prazo so garantidas somente em
um intervalo de tempo maior, e caso exista demanda. Os autores tambm propem um
controle adaptativo para aumentar a probabilidade de que as reservas a longo prazo, caso
necessrio, sero cumpridas. O sistema calcula um peso para cada rede virtual baseando-
se na razo entre seus recursos a longo prazo no utilizados e os recursos a longo prazo
no utilizados por todas as redes virtuais. Esse peso utilizado para priorizar as redes vir-
tuais com reservas de longo prazo maiores. A avaliao apresentada mostra que o sistema
possui aprimoramentos em relao ao original [Fernandes and Duarte 2011b] quanto
garantia de que as demandas de cada rede virtual sero cumpridas, alm de reduzir a
carga nos recursos do substrato fsico.
De acordo com [Govindan et al. 2009], comum que mquinas virtuais experi-
mentem atrasos (delays) na comunicao de rede ao esperarem que os recursos fsicos
tornem-se disponveis. Os autores desenvolvem um escalonador de CPU que visa redu-
zir o atraso agregado das mquinas virtuais alocadas em uma mquina fsica, ao mesmo
tempo em que garante as alocaes de processamento. O trabalho apresenta tal soluo
focando na virtualizao de servidores. Porm, por ser um escalonador orientado prin-
cipalmente a operaes de entrada e sada, tal soluo possui grande aplicabilidade em
redes virtuais. O algoritmo apresentado seleciona a mquina virtual que, ao ser escalo-
nada, resulta na reduo do atraso ao maior nmero de pacotes. Nesse caso, somente so
selecionadas mquinas que no violam as reservas de alocao. Essa priorizao alo-
cao de mquinas virtuais crticas resulta em uma diviso potencialmente injusta a curto
prazo. No entanto, essa distribuio desigual controlada e o escalonador garante que,
a longo prazo, cada mquina virtual ir receber a quantidade reservada. Alm disso, as
redes virtuais podem consumir os recursos diretamente, ou atravs do Monitor de Mqui-
nas Virtuais. Dessa forma ambos so contabilizados e atribudos s respectivas redes. Os
experimentos realizados pelos autores mostram que o sistema atinge o objetivo de esca-
lonamento justo a longo prazo, e possui um desempenho melhor na maioria dos casos.
Escalabilidade e Desempenho
[El-Darieby and Rolia 2006] apresentam um protocolo escalvel para a criao de
redes virtuais em cenrios em que existe um aumento na demanda e no tamanho dessas
redes. Com o intuito de manter a escalabilidade, os autores desenvolvem um processo
hierrquico para a criao de redes virtuais, em que ns so divididos em domnios hie-
rarquicamente organizados. Nveis mais altos na hierarquia desse modelo consistem em
maiores graus de abstrao na topologia de rede. Por exemplo, elementos em um nvel
n organizam-se em domnios que so abstrados, representados e gerenciados por um
nico elemento de nvel n+1. Tal abstrao entre nveis hierrquicos pode ser visua-
lizada na Figura 2.7, em que os Domnios 1, 2 e 3 do primeiro nvel so representados
por trs elementos no segundo nvel; por sua vez, os trs elementos do segundo nvel so
agrupados e representados por um elemento nico no nvel superior. A comunicao entre
os domnios preservada nos nveis de abstrao superiores. De acordo com a avaliao
apresentada, essa proposta escalvel quanto sobrecarga gerada pelo processo de con-
gurao, e quanto ao tempo total de instanciao. No entanto, devido ao alto custo da
soluo, os autores recomendam que essa tcnica seja utilizada para a criao de redes
virtuais com alto consumo de banda e longa vida til.
Domnio*
Domnio 1
BB*
Domnio 2 Domnio 3
Figura 2.7. Uma representao grca do sistema de hierarquias utilizado por
[El-Darieby and Rolia 2006].
Desempenho tambm o foco do trabalho de [Bhatia et al. 2008]. Os autores
apresentam uma plataforma capaz de criar redes virtuais exveis e de alto desempenho.
Essa plataforma utiliza virtualizao baseada em contineres, um mtodo de virtualiza-
o que separa as instncias virtuais em diferentes contineres no sistema operacional por
meio do uso de namespaces. Esse tipo de virtualizao prov alto desempenho ao custo da
exibilidade, pois as estruturas de dados devem ser compartilhadas entre os contineres.
No entanto, a soluo proposta compensa essa limitao atravs do uso de namespaces
de rede diferentes, permitindo que cada continer personalize aspectos da pilha de rede.
Adicionalmente, um mecanismo de tunelamento baseado em Encapsulamento Genrico
de Roteamento (Generic Routing Encapsulation) utilizado para oferecer virtualizao
de enlaces de forma transparente. O uso desse mdulo de tunelamento permite que ro-
teadores virtuais na mesma rede fsica utilizem espaos de endereamento sobrepostos.
Os experimentos apresentados comprovam a vantagem de desempenho dessa soluo em
comparao a modelos de virtualizao completa, nos quais o hardware virtual simu-
lado por completo.
Resilincia de Redes Virtuais
Mesmo com o gerenciamento adequado do substrato fsico, assegurar disponibi-
lidade permanece como um desao para a virtualizao de redes. A camada de virtua-
lizao precisa ser resiliente, conservando desempenho e mitigando ataques, de forma a
manter sua disponibilidade.
A soluo apresentada por [Yeow et al. 2011] visa fornecer infraestruturas de rede
resilientes a falhas em roteadores fsicos. Esse objetivo atingido atravs do uso de re-
cursos de backup (ou seja, roteadores e enlaces redundantes). Todavia, os recursos redun-
dantes permanecem ociosos, reduzindo a utilizao do substrato fsico. Para minimizar
esse problema, os autores propem o compartilhamento dos recursos de backup, e a cria-
o e gerenciamento dinmicos desses recursos. Esse mecanismo minimiza o nmero de
instncias de reserva necessrias para manter um certo nvel predeterminado de conabi-
lidade. Por outro lado, cada roteador fsico restringe-se a armazenar um nmero mximo
de backups sem sacricar a conabilidade.
A Figura 2.8.a ilustra, de forma simples, como ns de backup podem ser com-
partilhados por diferentes redes virtuais (VInfs). Na Figura 2.8.b exibido, em maiores
detalhes, como se d a alocao de backups a roteadores virtuais. Um roteador virtual C
1
possui como backups os roteadores virtuais B
1
e B
2
, e tais backups preservam a conectivi-
dade que este possui com o roteador virtual N
1
em termos de nmero de enlaces e largura
de banda. Ao mesmo tempo, a Figura 2.8.c mostra como tal topologia pode ser alocada na
rede fsica. Os roteadores virtuais previamente mencionados, representados por crculos,
so instanciados em diferentes roteadores fsicos, representados por quadrados. Os en-
laces da rede fsica utilizados pelos enlaces virtuais so representados por linhas slidas,
enquanto que os enlaces no utilizados so representados por linhas tracejadas.
Rede
Virtual 1
Rede
Virtual 2
Rede
Virtual 3
(a) Compartilhamento de recursos de bac-
kup entre redes virtuais
N
1
C
1
B
1
B
2
1 1
1
(b) Rede virtual resi-
liente
N
1
C
1
B
1
B
2
1
1
1
1
R
1
R
2
R
3
R
4
R
5
R
6
(c) Mapeamento de
ns de backup
Figura 2.8. Exemplos de compartilhamento e mapeamento de ns de backup,
utilizados por [Yeow et al. 2011] para prover resilincia a redes virtuais.
[Zhang et al. 2009] utilizam redes virtuais redundantes para prover conabilidade
em servios de live streaming. O sistema apresentado capaz de detectar falhas nos cami-
nhos e congestionamento de trfego, e redirecionar o uxo de dados de forma dinmica.
Inicialmente, o uxo distribudo igualitariamente entre as redes virtuais disponveis. A
Figura 2.9 exibe a diviso do uxo de dados entre diferentes redes virtuais, utilizando
diversos caminhos entre um servidor e um cliente. Ao longo do tempo, o nmero de pa-
cotes roteados gradativamente adaptado s capacidades de banda de cada rede virtual.
Alm disso, um mecanismo de sensoriamento utilizado para detectar falhas fsicas (tais
como inacessibilidade de um enlace ou roteador) ou de roteamento na rede (por exem-
plo, mudanas nas tabelas de roteamento podem ter grande impacto em aplicaes de live
streaming). Caso ocorra a deteco de alguma falha, o sistema redireciona os uxos de
dados das redes com problema entre as demais. Os experimentos realizados demostram
as vantagens no uso de mltiplas redes ao invs de uma nica rede, com ganhos signica-
tivos quando utilizam-se at quatro redes. Alm disso, os autores armam que o custo de
banda utilizado pelo mecanismo de deteco de falhas negligencivel.
Ataques de negao de servio distribudos (Distributed Denial of Service attacks
DDoS) so uma ameaa comum disponibilidade de servios na rede. O sistema apre-
Servidor
Cliente 1
Cliente 2
Cliente M
. . .
Rede
Virtual 1
Rede
Virtual 2
Rede
Virtual N
. . .
Figura 2.9. Um uxo de live streaming dividido por diversos caminhos entre
diferentes redes virtuais, mecanismo utilizado por [Zhang et al. 2009].
sentado por [Yu and Zhou 2008] visa detectar tais ataques em um ambiente de redes co-
munitrias (redes virtuais federadas pertencentes a entidades cooperantes). A soluo
utiliza esse ambiente colaborativo para detectar possveis ataques ainda em fase inicial.
Nessa proposta, roteadores de borda monitoram o trfego e calculam a entropia de cada
uxo de dados. Qualquer utuao abrupta e contnua em algum desses uxos dimi-
nui drasticamente a entropia, o que indica um possvel ataque. Caso isso acontea, os
roteadores de borda noticam os roteadores de ncleo a que esto conectados para que
estes calculem a entropia do uxo suspeito. Os valores calculados so comparados; se
similares, o ataque conrmado.
2.7. Anlise do Estado da Arte e Tendncias
Nesta seo, apresentada uma anlise e discusso sobre o contedo apresentado
em geral, sumarizando as informaes reveladas pelo estudo, tais como os principais
desaos e ameaas, o estado da arte e tendncias para o futuro.
2.7.1. Anlise do Estado da Arte
Diversas ideias podem ser obtidas a partir deste estudo literrio. Primeiramente,
possvel vericar que bibliograa selecionada no est igualitariamente distribuda nas
principais categorias. Certos tipos de ameaas e servios so estudados por um nmero
muito maior de publicaes do que outros. As Tabelas 2.2 e 2.3 mostram, respectiva-
mente, as ameaas de segurana e os servios apresentados nessas publicaes. Emambas
as tabelas, as publicaes foram agrupadas, quando possvel, de acordo com os elementos
de segurana abordados.
possvel observar que disrupo e disponibilidade, ameaa e servio de segu-
rana diretamente relacionados, so apresentados na grande maioria das publicaes.
Percebe-se, ainda, que apenas um pequeno grupo de publicaes apresenta sobreposies
entre diferentes ameaas ou servios. Alm disso, nenhuma das publicaes lidou com
mais do que duas das quatro categorias de ameaas, ou apresentou solues para prover
mais do que quatro dos seis servios de segurana categorizados. Finalmente, um servio
de segurana em particular o no-repdio no foi abordado por nenhuma das publi-
caes analisadas. A combinao de autenticao e integridade, apresentada em algumas
publicaes, pode ser considerada como a base para o aprovisionamento do no-repdio,
mas este servio no foi especicamente abordado.
Assim como esperado, muitos dos problemas de segurana abordados pelas pu-
blicaes advm do compartilhamento dos recursos fsicos. Em geral, as entidades no
consideram os outros usurios do mesmo substrato fsico antes de tomarem suas deci-
ses. Em virtude disso, os provedores de infraestrutura devem impor limites a essas aes.
Ademais, sempre existe a possibilidade de que usurios tomem aes intencionalmente
maliciosas, o que requer protees especcas ou aes de punio. Outra consequncia
do compartilhamento de recursos advm da possibilidade de que uma falha fsica em um
nico ponto do substrato possa danicar diversas infraestruturas virtuais.
Finalmente, verica-se o uso de diversas tcnicas de virtualizao distintas. Es-
sas tcnicas variam desde plataformas de virtualizao completa (por exemplo, Xen e
VMware), virtualizao baseada em contineres (por exemplo, VServer e OpenVZ), ou
at mesmo redes de roteadores programveis (por exemplo, OpenFlow). Cada uma dessas
plataformas tem seu conjunto de vantagens e suas prprias preocupaes com segurana,
as quais precisam ser consideradas em implementaes reais.
2.7.2. Projetos e Tendncias
Atualmente, h uma srie de projetos de pesquisa ativos no mundo focados na
pesquisa de redes virtuais e da Internet do Futuro. A seguir, so apresentados alguns
dos principais projetos e seus objetivos, agrupados pela localizao geogrca de seus
membros.
Amrica do Norte
O projeto GENI (Global Environment for Network Innovations) [GENI 2012]
uma das mais conhecidas frentes de pesquisa relacionadas Internet do Futuro. Apoiado
pela NSF (National Science Foundation), o projeto norte-americano visa prover um am-
biente de rede programvel capaz de dar suporte a experimentos em larga escala. A pro-
gramabilidade da rede, alcanada por meio da virtualizao, permite o particionamento
do substrato e a coexistncia de diversas arquiteturas de rede. Atravs desse ambiente,
espera-se fomentar inovaes em segurana, bem como o desenvolvimento de novas tec-
nologias, servios e aplicaes.
VINI (Virtual Network Infrastructure) [VINI 2012] outra iniciativa para a cria-
o de um ambiente de experimentao em larga escala. O mesmo utiliza extenses ao
kernel do PlanetLab para oferecer suporte virtualizao da camada de enlace. Dessa
forma, aplicaes executando nesse ambiente podem denir os protocolos da camada de
Publicao
Ameaas
DI FR DR US
[Wolinsky et al. 2006]
[Cui et al. 2009]
[Huang et al. 2010]
[van Cleeff et al. 2009]
[Cabuk et al. 2007]
[Chowdhury et al. 2009]
[Fernandes and Duarte 2011b]
[Roschke et al. 2009]
[Yu and Zhou 2008]
[Bhatia et al. 2008]
[El-Darieby and Rolia 2006]
[Cheng et al. 2011]
[Zhou et al. 2010]
[Zhang et al. 2009]
[He et al. 2008]
[Marquezan et al. 2009]
[Govindan et al. 2009]
[Wu et al. 2010]
[Kokku et al. 2010]
[Fernandes and Duarte 2011a]
[Du et al. 2010]
[Pisa et al. 2010]
[Mattos et al. 2011]
[Wang et al. 2008]
[Yeow et al. 2011]
[Mazzariello et al. 2010]
Tabela 2.2. Ameaas de segurana mencionadas nas publicaes. Da esquerda
para a direita: Divulgao, Fraude, Disrupo, Usurpao.
rede sem impactar no funcionamento dessa infraestrutura. Atualmente o projeto utiliza
uma infraestrutura privada, porm existem planos para que a infraestrutura atual do Pla-
netLab passe a aderir a essa mudana.
A Open Networking Foundation (ONF) [ONF 2012] uma organizao sem ns
lucrativos com o objetivo de difundir, de forma rpida e colaborativa, novos padres,
solues e arquiteturas ao mercado de redes de computadores. Essa iniciativa teve seu
bero no OpenFlow [McKeown et al. 2008], um protocolo de programao remota de
dispositivos de rede desenvolvido pelo projeto Clean Slate
6
da universidade de Stanford
[CleanSlate 2012]. A principal misso da ONF a de acelerar o processo de implantao
de Redes Denidas por Software (Software-Dened Networking SDN). Atualmente, o
conselho da ONF composto por Deutsche Telekom, Facebook, Google, Microsoft, Ve-
rizon e Yahoo! (tambm responsveis pela sua criao). A organizao ainda conta com
a participao de dezenas de empresas internacionais com grande inuncia no mercado
de redes como Cisco, Juniper, Netgear, Hitachi, etc.
6
O projeto Clean Slate foi nalizado em janeiro de 2012 dando origem a outros grupos de pesquisa,
dentre eles destaca-se o OpenFlow and Software Dened Networking (http://openow.org, acessado em
maro de 2012).
Publicao
Servios
CA AU CO IN NR DI
[Huang et al. 2010]
[Wolinsky et al. 2006]
[Cabuk et al. 2007]
[Fernandes and Duarte 2011b]
[Fernandes and Duarte 2011a]
[van Cleeff et al. 2009]
[Chowdhury et al. 2009]
[Yu and Zhou 2008]
[Bhatia et al. 2008]
[El-Darieby and Rolia 2006]
[Alkmim et al. 2011]
[Cheng et al. 2011]
[Zhou et al. 2010]
[Zhang et al. 2009]
[He et al. 2008]
[Govindan et al. 2009]
[Wu et al. 2010]
[Kokku et al. 2010]
[Du et al. 2010]
[Pisa et al. 2010]
[Mattos et al. 2011]
[Wang et al. 2008]
[Yeow et al. 2011]
Tabela 2.3. Servios de segurana providos pelas publicaes. Da esquerda
para a direita: Controle de Acesso, Autenticao, Condencialidade, Integridade,
No-repdio, Disponibilidade.
sia
Apoiado pelo NICT (National Institute of Information and Communications Tech-
nology), instituto japons de pesquisa em comunicao e informao, o projeto AKARI
7
[AKARI 2012] tem como objetivo implementar a base tecnolgica para uma rede de nova
gerao at o ano de 2015. A pesquisa foca no desenvolvimento dessa nova rede seguindo
a abordagem clean slate, ou seja, a arquitetura sendo desenvolvida no baseia-se nas tec-
nologias utilizadas atualmente na Internet. Na etapa vigente, o projeto j conta com um
modelo conceitual, o qual est sendo aprimorado e materializado por meio da implemen-
tao de um prottipo.
Brasil
O projeto ReVir (Redes Virtuais na Internet do Futuro) [ReVir 2012] envolve di-
versas universidades brasileiras, sendo nanciado pelo Centro de Pesquisa e Desenvolvi-
mento em Tecnologias Digitais para Informao e Comunicao (CTIC). Essa iniciativa
visa vencer desaos referentes rea de virtualizao de redes, alm de prover um arca-
7
AKARI no constitui uma sigla, somente um nome prprio. O signicado literal de AKARI uma
pequena luz.
bouo para a implantao em larga escala desse tipo de ambiente. Os principais objetivos
incluem uma infraestrutura com suporte segurana e garantia de isolamento, bem como
ferramentas de controle, gerenciamento e qualidade de servio para as redes virtuais.
Por sua vez, o projeto GIGA
8
[GIGA 2012] visa prover uma rede experimental
de alta velocidade (denominada Rede GIGA) para promover a pesquisa e o desenvolvi-
mento de novas tecnologias e aplicaes de rede. Esse projeto coordenado pelo Centro
de Pesquisa e Desenvolvimento (CPqD), em parceria com a Rede Nacional de Ensino e
Pesquisa (RNP), e nanciado pelo Fundo para o Desenvolvimento Tecnolgico das Te-
lecomunicaes (FUNTTEL). Seus objetivos, alm do desenvolvimento e da atualizao
contnua da Rede GIGA, incluem o desenvolvimento de novas tecnologias de rede p-
tica, de servios e aplicaes de rede, bem como a disponibilizao de tais tecnologias a
empresas brasileiras.
Europa
O projeto Trilogy [Trilogy 2012] nanciado pelo FP7 (Framework Programme
7), um programa de apoio pesquisa e desenvolvimento tecnolgico criado pela Unio
Europeia. Esse projeto tem o objetivo de prover novas tecnologias para o gerenciamento
da Internet, vencendo obstculos existentes atualmente como problemas de segurana e
limitaes de protocolos de roteamento inter-domnios. O nome do projeto parte da exis-
tncia de um trio de frentes de pesquisa internas mecanismos de roteamento, controle
de recursos e controle social e comercial.
O FIRE (Future Internet Research and Experimentation) [FIRE 2012] uma ini-
ciativa (tambm nanciada pelo FP7) que, assim como a norte-americana GENI, visa a
criao de um ambiente de experimentao em larga escala, sustentvel e dinmico. O
FIRE visa atingir esses objetivos por meio da conexo gradual e da federao dos ambien-
tes de experimentao atuais e futuras implementaes. Adicionalmente, a iniciativa visa
a criao de um arcabouo nico para a comunidade de pesquisa experimental europeia.
Outra iniciativa visando prover uma infraestrutura de rede experimental o pro-
jeto FEDERICA (Federated E-infrastructure Dedicated to European Researchers Innova-
ting in Computing network Architectures) [FEDERICA 2012]. Coordenado pelo GARR
(Gruppo per lArmonizzazione delle Reti della Ricerca), rede italiana de pesquisa acad-
mica, esse mais um projeto nanciado pelo FP7. Os membros do projeto visam imple-
mentar uma rede experimental agnstica em relao a protocolos, servios e tecnologias
utilizadas, permitindo que experimentos sejam realizados sobre redes de produo, sem
causar disrupo em seu trfego usual. O FEDERICA tambm visa lidar explicitamente
com a repetibilidade dos experimentos, ou seja, com a possibilidade de realizar repeties
nos mesmos sem que haja diferenas signicativas nos resultados.
Brasil/Europa
Financiado por uma cooperao entre o FP7 da Comisso Europeia e o Conse-
lho Nacional de Desenvolvimento Cientco e Tecnolgico (CNPq) do Brasil, o projeto
SecFuNet (Security for Future Networks) [SecFuNet 2012] trata de desenvolver uma ar-
quitetura de segurana para ambientes de redes virtualizadas e computao em nuvem.
8
Assim como o AKARI, GIGA tambm um nome prprio e no uma sigla.
Os principais objetivos dessa arquitetura so prover mtodos seguros de identicao,
autenticao, transferncia de dados, bem como privacidade e infraestruturas seguras de
virtualizao. O projeto conta com a participao de uma srie de universidades brasilei-
ras, bem como universidades e empresas de diversos pases da Europa especicamente,
Frana, Polnia, Alemanha e Portugal.
Assim como o SecFuNet, o projeto FIBRE (Future Internet testbeds experimen-
tation between BRazil and Europe) [FIBRE 2012], nanciado pelo CNPq e pelo FP7,
composto por diversas universidades e empresas brasileiras e europeias, alm de contar
com a participao da Austrlia. O principal objetivo do projeto a concepo, a imple-
mentao e a avaliao de um ambiente de experimentao compartilhado entre a Europa
e o Brasil. As principais atividades do projeto compreendem: (i) o desenvolvimento de
um novo ambiente de experimentao no Brasil (denominado FIBRE-BR); (ii) o aprimo-
ramento de dois ambientes de experimentao europeus j consagrados (a saber, OFELIA
e OneLab); (iii) a federao e integrao desses ambientes de experimentao visando
a criao de uma nica instalao compartilhada; e (iv) a implementao de aplicaes-
piloto de utilidade pblica para evidenciar o poder dessa nova instalao.
De forma similar, o projeto Horizon [Horizon 2012] nanciado pela Financi-
adora de Estudos e Projetos (FINEP) e pela ANR (Agence Nationale de la Recherche)
francesa. O projeto constitudo por uma srie de empresas e universidades, tanto brasi-
leiras quanto francesas. O mesmo foca em superar as limitaes da Internet atual no que
diz respeito a, por exemplo, mobilidade, ambientes ad hoc e redes de sensores. Para isso,
proposto um sistema de piloto automtico, composto por mecanismos inteligentes
adaptados a redes virtuais, com o objetivo de prover escalabilidade, segurana, robustez e
qualidade de servio.
2.8. Concluso
A virtualizao de redes traz inmeros benefcios ao permitir a subdiviso de uma
nica infraestrutura fsica em mltiplas arquiteturas virtuais. Tais benefcios podem ser
observados em uma ampla gama de aplicaes, incluindo a criao de ambientes de ex-
perimentao (testbeds), redes comunitrias e infraestruturas de computao em nuvem.
Ademais, esse paradigma vem sendo proposto por pesquisadores como a base de uma
nova arquitetura para a Internet, permitindo a criao de ambientes de rede pluralistas
com suporte a uma ampla gama de protocolos de rede simultaneamente.
Por outro lado, existem questes de segurana associadas aos ambientes de vir-
tualizao que precisam ser consideradas. O estudo bibliogrco revelou uma srie de
ameaas de segurana, cobrindo as quatro categorias denidas por [Shirey 2000]. O sim-
ples ato de compartilhar a infraestrutura fsica entre mltiplas partes indicado como
sendo a fonte de diversas dessas ameaas.
O estudo realizado mostrou que existem diversos esforos para aumentar o nvel
de segurana em redes virtualizadas. No entanto, esses esforos no foram organizados
de forma compreensvel. Este captulo sistematiza o conhecimento na rea, categorizando
os trabalhos que denem o estado-da-arte e evidenciando as diferentes abordagens para
lidar com segurana. Adicionalmente, tambm possvel observar o desequilbrio que
existe entre os diferentes aspectos de segurana em redes virtualizadas.
Por m, acredita-se que a categorizao das ameaas e dos servios de segurana
apresentada neste captulo facilita a anlise de quais caractersticas de segurana ainda
precisam ser abordadas e quais tipos de ataques precisam ser mitigados. Alm disso, a
mesma auxilia na identicao de diversas solues j existentes que visam prover segu-
rana a redes virtualizadas.
Agradecimentos
Os autores deste minicurso agradecem ao Conselho Nacional de Desenvolvimento
Cientco e Tecnolgico (CNPq) e ao Centro de Pesquisa e Desenvolvimento em Tec-
nologias Digitais para Informao e Comunicao (CTIC) pelas bolsas e infraestrutura
disponibilizadas para a realizao desta pesquisa.
Referncias
[AKARI 2012] AKARI (2012). Akari. National Institute of Information and Commu-
nications Technology (NICT). http://akari-project.nict.go.jp/eng/index2.htm, acessado
em maro de 2012.
[Alkmim et al. 2011] Alkmim, G. P., Batista, D. M., and Fonseca, N. L. S. (2011). Op-
timal mapping of virtual networks. In Global Telecommunications Conference (GLO-
BECOM 2011), 2011 IEEE, pages 16.
[Bhatia et al. 2008] Bhatia, S., Motiwala, M., Muhlbauer, W., Mundada, Y., Valancius,
V., Bavier, A., Feamster, N., Peterson, L., and Rexford, J. (2008). Trellis: a platform
for building exible, fast virtual networks on commodity hardware. In Proceedings of
the 2008 ACM CoNEXT Conference, CoNEXT 08, pages 72:172:6, New York, NY,
USA. ACM.
[Cabuk et al. 2007] Cabuk, S., Dalton, C. I., Ramasamy, H., and Schunter, M. (2007).
Towards automated provisioning of secure virtualized networks. In Proceedings of
the 14th ACM conference on Computer and communications security, CCS 07, pages
235245, New York, NY, USA. ACM.
[Campista et al. 2010] Campista, M. E. M., Ferrz, L. H. G., Moraes, I. M., Lanza, M.
L. D., Costa, L. H. M. K., and Duarte, O. C. M. B. (2010). Interconexo de redes na in-
ternet do futuro: Desaos e solues. In Minicursos, chapter 2, pages 47101. XXVIII
Simpsio Brasileiro de Redes de Computadores e Sistemas Distribudos - SBRC2010,
Gramado, RS, Brasil.
[Cavalcanti et al. 2006] Cavalcanti, E., Assis, L., Gaudencio, M., Cirne, W., and Brasi-
leiro, F. (2006). Sandboxing for a free-to-join grid with support for secure site-wide
storage area. In Proceedings of the 2nd International Workshop on Virtualization Te-
chnology in Distributed Computing, VTDC 06, pages 11, Washington, DC, USA.
IEEE Computer Society.
[Cheng et al. 2011] Cheng, X., Su, S., Zhang, Z., Wang, H., Yang, F., Luo, Y., and Wang,
J. (2011). Virtual network embedding through topology-aware node ranking. In SIG-
COMM Computer Communication Review, volume 41, pages 3847, New York, NY,
USA. ACM.
[Chowdhury et al. 2009] Chowdhury, N. M. M. K., Zaheer, F.-E., and Boutaba, R.
(2009). imark: an identity management framework for network virtualization environ-
ment. In Proceedings of the 11th IFIP/IEEE international conference on Symposium
on Integrated Network Management, IM09, pages 335342, Piscataway, NJ, USA.
IEEE Press.
[CleanSlate 2012] CleanSlate (2012). Clean slate: An interdisciplinary research pro-
gram. Cisco, Docomo, Deutsche Telekom, NEC, National Science Foundation (NSF),
XILINX Ericsson. http://cleanslate.stanford.edu, acessado em maro de 2012.
[Cui et al. 2009] Cui, Q., Shi, W., and Wang, Y. (2009). Design and implementation of a
network supporting environment for virtual experimental platforms. In Proceedings of
the 2009 WRI International Conference on Communications and Mobile Computing -
Volume 03, pages 406412, Washington, DC, USA. IEEE Computer Society.
[Du et al. 2010] Du, Y., Yu, H., Shi, G., Chen, J., and Zheng, W. (2010). Microwiper:
Efcient memory propagation in live migration of virtual machines. In Proceedings
of the 2010 39th International Conference on Parallel Processing, ICPP 10, pages
141149, Washington, DC, USA. IEEE Computer Society.
[El-Darieby and Rolia 2006] El-Darieby, M. and Rolia, J. (2006). Hierarchical crea-
tion of virtual networks. In Network Operations and Management Symposium, 2006.
NOMS 2006. 10th IEEE/IFIP, pages 220229.
[Farias et al. 2011] Farias, F. N. N., Jnior, J. M. D., Salvatti, J. J., Silva, S., Abelm,
A. J. G., Salvador, M. R., and Stanton, M. A. (2011). Pesquisa experimental para a
internet do futuro: Uma proposta utilizando virtualizao e o framework openow. In
Minicursos, chapter 1, pages 161. XXIX Simpsio Brasileiro de Redes de Computa-
dores e Sistemas Distribudos - SBRC2011, Campo Grande, MS, Brasil.
[FEDERICA 2012] FEDERICA (2012). Federica: Federated e-infrastructure dedicated
to european researchers innovating in computing network architectures. Framework
Programme 7 (FP7). http://www.fp7-federica.eu, acessado em maro de 2012.
[Feldmann 2007] Feldmann, A. (2007). Internet clean-slate design: what and why? SIG-
COMM Computer Communication Review, 37:5964.
[Fernandes et al. 2010] Fernandes, N., Moreira, M., Moraes, I., Ferraz, L., Couto, R.,
Carvalho, H., Campista, M., Costa, L., and Duarte, O. (2010). Virtual networks: Iso-
lation, performance, and trends. In Annals of Telecommunications.
[Fernandes and Duarte 2011a] Fernandes, N. C. and Duarte, O. C. M. B. (2011a). Pro-
vendo isolamento e qualidade de servio em redes virtuais. In XXIX Simpsio Brasi-
leiro de Redes de Computadores e Sistemas Distribudos - SBRC2011, Campo Grande,
MS, Brazil.
[Fernandes and Duarte 2011b] Fernandes, N. C. and Duarte, O. C. M. B. (2011b). Xnet-
mon: A network monitor for securing virtual networks. In Proceedings of the IEEE
International Conference on Communications (ICC 2011 - Next Generation Networ-
king and Internet Symposium (NGNI)), Kyoto, Japan. IEEE.
[FIBRE 2012] FIBRE (2012). Fibre: Future internet testbeds/experimentation between
brazil and europe. Conselho Nacional de Desenvolvimento Cientco e Tecnolgico
(CNPq), Framework Programme 7 (FP7). http://www.bre-ict.eu, acessado em maro
de 2012.
[FIRE 2012] FIRE (2012). Fire: Future internet research and experimentation. Fra-
mework Programme 7 (FP7). http://cordis.europa.eu/fp7/ict/re, acessado em maro
de 2012.
[GENI 2012] GENI (2012). Geni: Global environment for network innovations. National
Science Foundation (NSF). http://www.geni.net, acessado em maro de 2012.
[GIGA 2012] GIGA (2012). Giga: Rede experimental de alta velocidade. Centro de
Pesquisa e Desenvolvimento (CPqD), Rede Nacional de Ensino e Pesquisa (RNP),
Fundo para o Desenvolvimento Tecnolgico das Telecomunicaes (FUNTTEL).
http://www.giga.org.br, acessado em maro de 2012.
[Govindan et al. 2009] Govindan, S., Choi, J., Nath, A., Das, A., Urgaonkar, B., and
Sivasubramaniam, A. (2009). Xen and co.: Communication-aware cpu manage-
ment in consolidated xen-based hosting platforms. IEEE Transactions on Computers,
58(8):11111125.
[He et al. 2008] He, J., Zhang-Shen, R., Li, Y., Lee, C.-Y., Rexford, J., and Chiang, M.
(2008). Davinci: dynamically adaptive virtual networks for a customized internet. In
Proceedings of the 2008 ACM CoNEXT Conference, CoNEXT 08, pages 15:115:12,
New York, NY, USA. ACM.
[Horizon 2012] Horizon (2012). Horizon: A new horizon to the internet. Financi-
adora de Estudos e Projetos (FINEP), Agence Nationale de la Recherche (ANR).
http://www.gta.ufrj.br/horizon, acessado em maro de 2012.
[Huang et al. 2010] Huang, D., Ata, S., and Medhi, D. (2010). Establishing secure virtual
trust routing and provisioning domains for future internet. In GLOBECOM 2010, 2010
IEEE Global Telecommunications Conference, pages 16.
[Kokku et al. 2010] Kokku, R., Mahindra, R., Zhang, H., and Rangarajan, S. (2010).
Nvs: a virtualization substrate for wimax networks. In Proceedings of the sixteenth
annual international conference on Mobile computing and networking, MobiCom 10,
pages 233244, New York, NY, USA. ACM.
[LAN/MAN Standards Committee 2006] LAN/MAN Standards Committee (2006). Ieee
standard for local and metropolitan area networks virtual bridged local area networks.
IEEE Std 802.1Q-2005 (incorpora IEEE Std 802.1Q1998, IEEE Std 802.1u-2001,
IEEE Std 802.1v-2001, e IEEE Std 802.1s-2002).
[Marquezan et al. 2010] Marquezan, C., Granville, L., Nunzi, G., and Brunner, M.
(2010). Distributed autonomic resource management for network virtualization. In
Network Operations and Management Symposium (NOMS), 2010 IEEE, pages 463
470.
[Marquezan et al. 2009] Marquezan, C. C., Nobre, J. C., Granville, L. Z., Nunzi, G.,
Dudkowski, D., and Brunner, M. (2009). Distributed reallocation scheme for virtual
network resources. In Proceedings of the 2009 IEEE international conference on Com-
munications, ICC09, pages 23092313, Piscataway, NJ, USA. IEEE Press.
[Mattos et al. 2011] Mattos, D., Fernandes, N. C., and Duarte, O. C. M. B. (2011). Xen-
ow: Um sistema de processamento de uxos robusto e eciente para migrao em
redes virtuais. In XXIX Simpsio Brasileiro de Redes de Computadores e Sistemas
Distribudos - SBRC2011, Campo Grande, MS, Brazil.
[Mazzariello et al. 2010] Mazzariello, C., Bifulco, R., and Canonico, R. (2010). Integra-
ting a network ids into an open source cloud computing environment. In Information
Assurance and Security (IAS), 2010 Sixth International Conference on, pages 265270.
[McKeown et al. 2008] McKeown, N., Anderson, T., Balakrishnan, H., Parulkar, G., Pe-
terson, L., Rexford, J., Shenker, S., and Turner, J. (2008). Openow: enabling innova-
tion in campus networks. SIGCOMM Computer Communication Review, 38:6974.
[ONF 2012] ONF (2012). Open networking foundation. Deutsche Telekom, Facebook,
Google, Microsoft, Verizon, and Yahoo!. https://www.opennetworking.org, acessado
em maro de 2012.
[Pisa et al. 2010] Pisa, P., Fernandes, N., Carvalho, H., Moreira, M., Campista, M.,
Costa, L., and Duarte, O. (2010). Openow and xen-based virtual network migration.
In Communications: Wireless in Developing Countries and Networks of the Future,
volume 327 of IFIP Advances in Information and Communication Technology, pages
170181. Springer Boston.
[ReVir 2012] ReVir (2012). Revir: Redes virtuais na internet do futuro. Centro de Pes-
quisa e Desenvolvimento em Tecnologias Digitais para Informao e Comunicao
(CTIC). http://www.gta.ufrj.br/revir, acessado em maro de 2012.
[Roschke et al. 2009] Roschke, S., Cheng, F., and Meinel, C. (2009). Intrusion detection
in the cloud. In Proceedings of the 2009 Eighth IEEE International Conference on De-
pendable, Autonomic and Secure Computing, DASC 09, pages 729734, Washington,
DC, USA. IEEE Computer Society.
[Rosen et al. 2006] Rosen, E., Cisco Systems, I., Rekhter, Y., and Juniper Networks, I.
(2006). Rfc 4364: Bgp/mpls ip virtual private networks (vpns). Internet Engineering
Task Force (IETF). http://www.ietf.org/rfc/rfc4364.txt.
[SecFuNet 2012] SecFuNet (2012). Secfunet: Security for future networks. Conse-
lho Nacional de Desenvolvimento Cientco e Tecnolgico (CNPq), Framework Pro-
gramme 7 (FP7). http://www.secfunet.eu, acessado em maro de 2012.
[Shirey 2000] Shirey, R. (2000). Rfc 2828: Internet security glossary. Internet Enginee-
ring Task Force (IETF). http://www.ietf.org/rfc/rfc2828.txt.
[Stallings 2006] Stallings, W. (2006). Cryptography and network security: principles
and practice. The William Stallings Books on Computer and Data Communications.
Pearson/Prentice Hall, 4th edition.
[Stuckmann and Zimmermann 2009] Stuckmann, P. and Zimmermann, R. (2009). Euro-
pean research on future internet design. Wireless Communications, 16:1422.
[Trilogy 2012] Trilogy (2012). Trilogy: Architecting the future internet. Framework
Programme 7 (FP7). http://www.trilogy-project.org, acessado em maro de 2012.
[van Cleeff et al. 2009] van Cleeff, A., Pieters, W., and Wieringa, R. J. (2009). Security
implications of virtualization: A literature study. In Proceedings of the 2009 Inter-
national Conference on Computational Science and Engineering - Volume 03, pages
[VINI 2012] VINI (2012). Vini: Virtual network infrastructure. www.vini-veritas.net,
acessado em maro de 2012.
[Wang et al. 2008] Wang, Y., Keller, E., Biskeborn, B., van der Merwe, J., and Rexford,
J. (2008). Virtual routers on the move: live router migration as a network-management
primitive. In SIGCOMM Computer Communication Review, volume 38, pages 231
242, New York, NY, USA. ACM.
[Wolinsky et al. 2006] Wolinsky, D. I., Agrawal, A., Boykin, P. O., Davis, J. R., Gan-
guly, A., Paramygin, V., Sheng, Y. P., and Figueiredo, R. J. (2006). On the design
of virtual machine sandboxes for distributed computing in wide-area overlays of vir-
tual workstations. In Proceedings of the 2nd International Workshop on Virtualization
Technology in Distributed Computing, VTDC 06, pages 8, Washington, DC, USA.
[Wu et al. 2010] Wu, Q., Shanbhag, S., and Wolf, T. (2010). Fair multithreading on pac-
ket processors for scalable network virtualization. In Proceedings of the 6th ACM/IEEE
Symposiumon Architectures for Networking and Communications Systems, ANCS 10,
pages 1:11:11, New York, NY, USA. ACM.
[Yeow et al. 2011] Yeow, W.-L., Westphal, C., and Kozat, U. C. (2011). Designing and
embedding reliable virtual infrastructures. In SIGCOMM Computer Communication
Review, volume 41, pages 5764, New York, NY, USA. ACM.
[Yu and Zhou 2008] Yu, S. and Zhou, W. (2008). Entropy-based collaborative detection
of ddos attacks on community networks. In Proceedings of the 2008 Sixth Annual
IEEE International Conference on Pervasive Computing and Communications, pages
[Zhang et al. 2009] Zhang, Y., Gao, L., and Wang, C. (2009). Multinet: multiple vir-
tual networks for a reliable live streaming service. In Proceedings of the 28th IEEE
conference on Global telecommunications, GLOBECOM09, pages 22542259, Pis-
cataway, NJ, USA. IEEE Press.
[Zhou et al. 2010] Zhou, Y., Li, Y., Sun, G., Jin, D., Su, L., and Zeng, L. (2010). Game
theory based bandwidth allocation scheme for network virtualization. In GLOBECOM
2010, 2010 IEEE Global Telecommunications Conference, pages 15.
Captulo
3
Estado da Arte de Sistemas de Controle e Monito-
ramento de Infraestruturas para Experimentao
de Redes de Comunicao
Cesar Augusto Cavalheiro Marcondes (UFSCar), Joberto Martins (UNIFACS),
Jos Augusto Suruagy Monteiro (UFPE), Kleber Vieira Cardoso (UFG), Ant-
nio Jorge G. Abelm (UFPA), Vagner Nascimento (UFPA), Iara Machado
(RNP), Tereza C.M.B. Carvalho (USP), Charles C. Miers (USP/UDESC),
Marcos Salvador (CPqD) e Christian Esteve Rothenberg (CPqD)
Abstract
In the last years, the research in communication networks has focused on innovations,
following two main approaches: clean-slate and the incremental deployment as possible
proposals for the Future Internet. These new ideas need strict investigation in large scale
by employing a large amount of available tools such as simulators, emulators and experi-
mental infrastructures. In the context of infrastructures, complex architectures of control
and monitoring have been developed, allowing inexperienced experimenters to test new
ideas with minimal effort. The control and monitoring frameworks allow registering re-
sources, registering the experimenter, controlling the access to infrastructures services,
creating slices and recording of resource utilization, managing experiment cycle, moni-
toring results, storing the results, among others actions. The aim of this short course is
to survey the state of the art of these systems, making an introduction to them, providing
details about their requirements, commenting implementations and deployments, and pre-
senting some cake recipes tested in experimentation infrastructures around the world. We
also discuss the efforts of the federation control systems infrastructure for experimenta-
tion in order to have a larger and heterogeneous infrastructure to conduct experiments.
The course has a theoretical approach, detailing concepts and services of the CMFs, pos-
sibly with some detailing about a specic CMF or federation solution such as PlanetLab,
ProtoGENI, OFELIA, OMF and SFA 2. We will show some videos and practical examples
about the use of such technology in order to call the attention of Brazilian experimen-
ters in networks and distributed systems on the ease of conducting experiments with these
frameworks.
Resumo
Nos ltimos anos, a pesquisa em redes de comunicao tem focado em inovaes que
seguem duas abordagens principais: clean-slate e as que tm implantao incremental
como possveis propostas de Internet do futuro. Essas novas ideias necessitam de rigo-
rosa investigao em larga escala, usando uma grande quantidade de ferramentas dis-
ponveis como simuladores, emuladores e infraestruturas para experimentao de redes.
Dentro do contexto das infraestruturas, tm sido desenvolvidas complexas arquiteturas de
controle e monitoramento que habilitam experimentadores sem experincia a testar novas
ideias com o mnimo de esforo. Os arcabouos de controle e monitoramento, chamados
CMFs (Control and Monitoring Frameworks), permitem registrar os recursos, registrar o
experimentador, controlar o acesso aos servios da infraestrutura, criar e registrar fatias
de utilizao de recursos, gerenciar o ciclo de experimentos, monitorar os resultados,
armazenar os resultados, entre outras. O objetivo desse minicurso fazer um levanta-
mento terico do estado da arte destes sistemas, fazendo uma introduo aos mesmos,
passando por detalhar desde os seus requisitos, at as implementaes, implantaes e
cobriremos tambm receitas de bolo de teste, feitas em ambientes de experimentao ao
redor do mundo. Tambm abordaremos os esforos de federao dos sistemas de controle
de infraestruturas para experimentao de modo a ter uma infraestrutura maior e hete-
rognea para a realizao de experimentos. O curso tem um enfoque terico, detalhando
conceitos e servios dos CMFs, eventualmente com algum detalhamento de CMF e/ou
esquema de federao especco como o Planetlab, ProtoGENI, OFELIA, OMF e o SFA
2. Mostraremos alguns vdeos e exemplos prticos sobre o uso dessas tecnologia de modo
a chamar a ateno de experimentadores em redes e sistemas distribudos brasileiros
sobre a facilidade de conduzir experimentos com esses arcabouos.
3.1. Introduo a Infraestruturas para Experimentao em Internet do Fu-
turo
Este minicurso tem o objetivo de realizar uma introduo ao tema de Sistemas de Con-
trole e Monitoramento de Infraestruturas para Experimentao de Redes de Comunicao,
ou em ingls, os Control and Monitoring Frameworks (CMFs). Estes sistemas, normal-
mente, criado integrados a suas prprias redes de experimentao, as chamadas testbeds
permitem que pesquisadores possam fazer estudos de larga escala em redes e sistemas
distribudos. Exemplo dessas testbeds vo desde a GENI nos EUA (Global Environment
for Network Innovations), FIRE na Europa (Future Internet Research & Experimenta-
tion), OFELIA (OpenFlow in Europe: Linking Infrastructure and Applications) testbed
especca para redes baseadas em OpenFlow e demais iniciativas e projetos relacionados,
como a futura testbed FIBRE (Future Internet testbeds/experimentation between BRazil
and Europe) da qual participam os autores deste minicurso.
Atualmente, essas testbeds e CMFs tm despertado grande interesse na comuni-
dade, e tm gerado esforo considervel em uma melhor especicao e em uma anlise
minuciosa para tornar tais sistemas mais genricos e mais fceis para uso e suportar a fe-
derao de seus recursos. O objetivo ambicioso, permitindo que recursos independentes
e distribudos na rede formem um grande conjunto de recursos para testes de novas ideias
em sistemas distribudos e redes.
De modo a contextualizar os leitores sobre as Infraestruturas para Experimenta-
o em Internet do Futuro, ns organizamos este texto para cobrir quatro reas principais:
os Requisitos tanto do ponto de vista de usurios (Seo 3.2), quanto de programadores
que desenvolvem a parte de controle (Seo 3.3) e a parte monitoramento (Seo 3.4) dos
CMFs. Em seguida, descrevemos resumidamente as Testbeds e respectivos CMFs com
maior visibilidade internacional, mostrando um pequeno histrico, a arquitetura e em
alguns casos, exemplos de uso e teste de cada uma delas (Seo 3.5). A seguir, apresenta-
mos uma discusso sobre o esforo de padronizao da Federao de testbeds (SFA) [Pe-
terson et al. 2010] (Seo 3.6). E tambm apresentamos dois Estudos de Caso OFELIA
CF (Seo 3.7) e OMF CF (Seo 3.8) detalhando como pesquisadores brasileiros podem
instalar, congurar, gerenciar e utilizar testbeds usando recursos prprios de seus grupos
de pesquisa para inovar, validar e gerar resultados signicativos para a comunidade de
redes e sistemas distribudos. Ao nal, encerramos o minicurso com algumas concluses
(Seo 3.9).
3.2. Requisitos Gerais das Infraestruturas do Ponto de Vista do Experimen-
tador
Os Sistemas de Controle e Monitoramento de Infraestruturas formam um interessante
ecossistema de ferramentas de suporte a experimentao de rede provendo um workow
completo para a pesquisa aplicada em redes de computadores e sistemas distribudos.
Estes aspectos tm que ser documentados no que se refere ao ambiente de aplicao. Os
requisitos do usurio so a base para o bom desenvolvimento de um projeto.
A documentao deve contemplar todas as informaes advindas do usurio, bem
como sua viso de um ambiente de experimentao, como ele interagiria com o mesmo e
quais funcionalidades seriam necessrias para planejar, implantar e executar seu experi-
mento, entre outros aspectos envolvidos na infraestrutura.
Para garantir a qualidade dos requisitos necessrio um formalismo que permita
que cada requisito seja identicado de forma nica, desta forma uma referncia nica ser
possvel a partir dos documentos gerados nesta fase com o conhecimento do experimen-
tador.
Abordaremos o exemplo genrico que atende a maioria dos requisitos funcionais
de experimentadores, o workow GENI, que cobre 3 fases principais: Planejamento de
Experimentos, Implantao dos Experimentos e Execuo dos Experimentos. Em
particular, descreveremos o que feito em cada fase, como por exemplo, deteco de
recursos disponveis, obteno de credenciais, instalao de software de apoio, controle
de experimentos, instrumentao de cdigo e medies ativas e passivas at a coleta de
resultados.
3.2.1. Planejamento de Experimentos
a fase onde o usurio planeja como o experimento ser conduzido no ambiente. Ele
ir determinar os recursos e ferramentas necessrios para programar o experimento, os
servios de instrumentao disponveis e suas conguraes. O Planejamento de Expe-
rimentos constitudo por quatro etapas: Apresentao de Credenciais, Descoberta de
Recursos, Descoberta de Ferramentas e Desenvolvimento de Verso.
Nesta primeira etapa de Apresentao de Credenciais, um experimento criado
contendo a alocao de recursos, e com esta a necessidade de certos privilgios, nomes e
identicadores nicos. Por sua vez, experimentos podem ser associados a mltiplos expe-
rimentadores e estes tambm podem ter diferentes privilgios, tais como, a capacidade de
adicionar novos experimentadores e atribuir-lhes privilgios, ou a capacidade de adicionar
ou remover recursos para o experimento e a capacidade de visualizao dos dados coleta-
dos. Finalmente, experimentadores com privilgios diferentes podem ser adicionados ou
removidos a qualquer momento durante o ciclo de vida de um experimento.
Na fase de Descoberta de recursos o experimentador procura os recursos ne-
cessrios para executar um experimento. Para permitir escalabilidade, a descoberta de
recursos pode possuir vrias fases, por exemplo, receber informaes sobre os recursos e,
em seguida, ter a capacidade de renar consultas para obter informaes mais detalhadas
sobre os recursos especcos ou conjuntos dos mesmos. Alm disto, a descoberta de re-
cursos um processo em constante execuo sobre os novos recursos adicionados a um
experimento.
Em linhas gerais, a descoberta de recursos pode acontecer das seguintes formas:
Automaticamente: O projeto pode apoiar uma ou mais linguagens de especica-
o de experimento. Estas linguagens sero usadas para descrever os atributos de
um experimento, incluindo os recursos necessrios, congurao e dados a serem
coletados durante a execuo do mesmo.
Manualmente: permite ao experimentador escrever um script ou programa que
consulta recursos em outros ambientes.
Interface Grca: A partir de uma interface interativa os experimentadores devem
ser capazes de ver os recursos, como em um ambiente shell ou um ambiente grco
intuitivo e de fcil utilizao.
No caso do GENI, os experimentadores podem alocar recursos pelo navegador,
se estiverem autorizados para isso. Uma vez que os recursos necessrios para executar
o experimento sejam descobertos, o experimentador ter que aprender sobre as ferra-
mentas necessrias para programar e congurar esses recursos. Isso acontece na etapa
de Descoberta de Ferramentas. Nesta etapa, experimentadores podem aprender sobre
as restries a serem contabilizadas para programar e utilizar estes recursos. Possibilita
tambm apontar para emuladores de recursos especializados que podem ser usados para
desenvolver e validar software antes que ele seja implantado.
Finalmente, na etapa de Desenvolvimento de Verso, o experimentador desen-
volve os softwares e congura os arquivos que iro eventualmente ser carregados nos
recursos descobertos para o experimento. No caso do GENI, estes softwares podem ser
testados em um laboratrio utilizando emuladores de recursos especializados ou no pr-
prio ambiente GENI.
O planejamento do experimento, contm uma serie de denies de servios e
ferramentas, que incluem:
O fornecimento de uma ferramenta que possa interpretar uma especicao de ex-
perimento e consultar ambientes apropriados para a descoberta de recursos;
Uma API que possa ser usada para consultar os recursos. Esta API torna mas fcil
a chamada de bibliotecas internas;
Uma ferramenta grca para acessar os recursos. Uma interface ideal deveria uti-
lizar tcnicas familiares usando um navegador para procurar recursos em outros
domnios, tais como busca de arquivos em sistemas de arquivo ou mesmo livros em
um catlogo on-line.
Alm das informaes sobre os recursos de uma maneira formal, por exemplo,
usando o padro Rspec, que descreve os recursos solicitados. Informaes que
podem ser necessrias. O ambiente tambm deve fornecer ferramentas para extrair
essas informaes e torn-las disponiveis para o experimentador.
3.2.2. Implantao dos Experimentos
A implantao de um experimento composta de quatro etapas: Apresentao de Cre-
denciais, Alocao de Recursos, Instalao de Software/Hardware e Vericao da
Implantao. A fase de Apresentao de Credenciais autentica o usurio e verica se ele
realmente tem permisso para alocar recursos e us-los para a experimentao.
O experimentador ento aloca recursos para o experimento. Alocaes de recur-
sos garantem que os recursos solicitados sero disponibilizados para o experimento nos
horrios especicados. O processo de alocao de recursos semelhante navegao pe-
los recursos e consiste em trs fases: Automaticamente a partir de uma especicao do
experimento, de forma pragmtica ou usando uma interface interativa. Por m denido
um tempo de incio e a durao da alocao dos recursos.
Na instalao de software/hardware o experimentador pode ento congurar os re-
cursos obtidos pela: Instalao dos softwares, instalao dos hardwares, congurao dos
componentes, denio da(s) topologia(s), habilitar as ligaes com a Internet, conectar-
se a um experimento em execuo (composio de experimento).
Finalmente, o experimentador pode vericar a implantao: Vericando se os
recursos necessrios foram obtidos e programados com as verses corretas de software
e se os uxos de trfego so os esperados. A vericao de uma implantao que usa
recursos ligados intermitantemente pode ser um desao.
A implantao dos experimentos consiste em uma srie de denies de servios
e ferramentas que incluem o fornecimento:
De uma lista de itens a serem considerados antes de implantar um experimento.
Ferramenta que possa interpretar uma especicao de experimento e alocar recur-
sos em ambientes apropriados para recursos.
Ferramentas para coordenar os horrios para a composio de experimentos de
grande porte.
Ferramenta de software em experimentos distribudos, incentivando a utilizao de
software dentro de um grande nmero de componentes, instalao desses software,
controle de verso.
Mecanismo que permita que um experimento possa se conectar a outro experimento
j em execuo.
Ferramentas e servios para validar uma congurao de experimento: recursos
alocados, verso de software instalado e a congurao de caminhos para comuni-
cao.
Um experimentador deve ser capaz de salvar uma lista de recursos alocados nesta
fase e, em um momento futuro, solicitar que estes mesmos recursos sejam dis-
ponibilizados para o experimento. Isto ir permitir que um experimentador possa
retornar a uma congurao que foi vlida.
Ferramentas e servios para ajudar o experimentador a gerenciar os recursos aloca-
dos. Por exemplo, um servio que notique o experimentador quando um recurso
alocado por ele est prestes a ter seu tempo expirado.
3.2.3. Execuo dos Experimentos
A execuo dos experimentos dividida em sete etapas: Controle do Experimento, Co-
leta e Anlise dos dados, Anlise de Uso dos Recursos, Injeo de Falha, Manuteno
Operacional e Tratamento de Exceo durante o ciclo de vida de um experimento. Uma
vez que o experimento estiver congurado, o experimentador o controla pelas aes de
iniciar, pausar, retomar, reiniciar e nalizar. Os experimentos podem ser controlados em
diferentes nveis de granularidade: completo, no nvel de recurso ou mesmo atravs do
agrupamento de recursos. Adicionalmente, diferentes experimentadores podem permitir
diferentes nveis de controle sobre os experimentos.
Outra atividades relacionada ao controle do experimento, inclui o crescimento ou
diminuio do experimento, adicionando ou removendo recursos, ajustando o nvel de
instrumentao, ligando ou desligando o uxo de/para a Internet, e conectar ou desconec-
tar de outros experimentos em curso.
O experimentador pode ligar e desligar os diferentes nveis de instrumentao. A
medio do desempenho de software distribudo e a utilizao dos recursos utilizados so
alguns exemplos. Dados de instrumentao podem ser visualizados em tempo real ou
salvos para anlise futura.
O experimentador pode especicar aes automticas a serem tomadas quando
partes do experimento falhar, se os recursos a serem utilizado tornarem-se indisponveis
ou recursos adicionais se tornarem disponveis. O experimentador tambm pode injetar
falhas no sistema. Estas falhas podem gerar falhas de recursos, uma reduo na quanti-
dade de recursos disponveis, duplicao de mensagens, etc.
O experimentador tambm pode monitorar e manter experimentos do ponto de
vista operacional. Eles podem usar ferramentas para solucionar problemas de congura-
o, se as coisas no saem como planejado, por exemplo, ferramentas para visualizar logs
do sistema e diagnosticar problemas estaro disponveis. Eles tambm podem dispor de
um help-desk para dar suporte na resoluo de problemas.
A execuo dos experimentos conta tambm com uma srie de denies de ser-
vios e ferramentas que incluem:
Fornecer ferramentas para controlar um experimento de programao ou usar uma
ferramenta interativa. Um experimentador ou um grupo de experimentadores deve
ser capaz de monitorar e controlar os experimentos de vrios locais. Idealmente,
devem ser capazes de controlar um experimento a partir de qualquer computador
usando uma interface web.
Fornecer ferramentas e bibliotecas para que os experimentadores possam imple-
mentar mecanismos padro para sistemas distribudos tais como barriers, onde di-
ferentes partes do programa distribudo no podem ter progresso at que todas as
partes tenham atingido certo ponto;
Boas ferramentas de instrumentao so crticas para o sucesso do projeto, por
causa da importncia da medio e anlise de experimentos cientcos. As fer-
ramentas devem permitir que o experimentador varie dinamicamente o nvel de
instrumentao, controlando o uxo de medies para ferramentas de anlise e ar-
quivando esses dados. O sistema de instrumentao deve ter um impacto mnimo
ou nenhum para o desempenho do experimento. So necessrios mecanismos para
controlar o acesso aos dados coletados, j que alguns destes experimentos podem
coletar dados ou trfego que esto sujeitos a polticas de privacidade. Nestes casos,
o projeto deve:
Fornecer ferramentas para visualizar os dados coletados.
Proporcionar ferramentas para injetar uma variedade de diferentes tipos de
falhas de uma maneira controlada.
Os usurios devem ser capazes de adicionar as suas prprias ferramentas de injeo
de falhas em um framework de controle.
Fornecer ferramentas e servios para depurar problemas operacionais em um expe-
rimento causados pela incapacidade de atingir ou obter certos recursos ou compor-
tamento inesperado. Tambm pode haver um help-desk para ajudar experimentado-
res a solucionar problemas operacionais.
Fornecer mecanismos para que os experimentadores especiquem aes a serem
tomadas quando determinado padro ou exceo ocorram durante a execuo do
experimento.
3.3. Descrio das Principais Funcionalidades da Parte de Controle dos CMFs
A questo crucial de uma testbed o controle dos recursos e como coordenar os experi-
mentos. Para controlar, preciso autenticar, listar quais os recursos disponveis e deixar
disponvel via API, maneiras automticas de congurao da testbed.
Nesta seo apresentaremos os requisitos e principais funcionalidades de con-
trole para os arcabouos de controle e monitoramento. Para tanto, faremos uma reviso
de especicaes descritas nas referncias de controle do GENI [GENI 2009] que serve
de base e modelo para todos os CMFs.
A arquitetura de controle do GENI pode ser resumida pela Figura 3.1. No topo,
est a infraestrutura chamada Clearinghouse que inclui todos os cadastros dos compo-
nentes e atores do sistema GENI que permitem a autenticao dos mesmos. Entre eles,
pode-se notar: o registro dos pesquisadores (chamados de principals), registro de com-
ponentes, registro de fatias ou fatias de experimentao (chamadas de slices) e, opcional-
mente registros relacionados auditoria de recursos e repositrio de software.
Na parte inferior da Figura 3.1, existem diversas entidades independentes (chama-
das Aggregates) que possuem recursos computacionais para serem agregados a um experi-
mento e que sero controlados pelo plano de controle, disposto em formato de barramento
(Control Plane). Cada agregado deve possuir um gerenciador do mesmo (Aggregate Ma-
nager), e opcionalmente outros gerenciadores especcos para componentes (Component
Figura 3.1. Viso Geral dos Servios de Controle da Arquitetura GENI
Manager). Outra opo avanada a incluso de servios de corretores (brokers) de re-
cursos, que tipicamente podem funcionar como gerenciadores de conjuntos de agregados,
buscando a melhor disposio de recursos para seus clientes.
Finalmente, no canto esquerdo da Figura 3.1, existem as entidades associadas com
o pesquisador (Principal no GENI) que estar utilizando, administrando e gerenciando
recursos para seu experimento. Para isso, uma das alternativas utilizar um navegador
que permita acessar um portal para facilitar a interao com as ferramentas e comandos.
Baseado nas vrias entidades descritas, possvel denir precisamente o arca-
bouo da parte de controle como o sendo responsvel por:
Realizar o interfaceamento entre todas as entidades (Clearinghouse, Aggregates,
Principal);
Denir os tipos de mensagens do arcabouo, incluindo a sintaxe e funcionalidade
de protocolos bsicos de controle;
Denir o uxo de mensagens dentro do arcabouo para realizar cenrios de experi-
mentao.
Em seguida descreveremos com maiores detalhes os diferentes requisitos de controle.
3.3.1. Requisitos de Controle de Acesso e Credenciais
Os Principals so pessoas que esto trabalhando a partir de um navegador, gerenciando,
controlando e utilizando os recursos do GENI. Estas precisam de um identicador global,
de uma etapa de registro que pode denir acesso privilegiado a recursos. E nalmente,
aps o registro, a obteno de uma chave criptogrca, comumente chamada de creden-
cials, para acesso. Os tipos de usurios no abrangem somente os pesquisadores usurios
mas podem tambm denir: operadores da testbed, gerentes de projetos, administradores
de slices, PIs e pesquisadores.
3.3.2. Requisitos de Agregados e Componentes
Os agregados e seus componentes so os blocos principal do sistema GENI. No agregado
so encapsulados os recursos, como mquinas virtuais, recursos lgicos (portas) e sint-
ticos (virtual paths) chamados de componentes. Opcionalmente, tais agregados podem
revelar a estrutura interna de seus componentes. Do ponto de vista de controle, existe um
gerenciador chamado Aggregate Manager (AM) que exporta uma interface bem-denida
para o sistema GENI. Cada Aggregate deve ter uma identicao global e um registro
permitindo sua posterior alocao.
3.3.3. Requisitos de Fatias
Para conduzir experimentos preciso alocar recursos, dentro no controle do GENI,
usada uma abstrao chamada de Fatia (Slice), que consiste em um conjunto interconec-
tado de recursos reservados. Baseando-se ainda na Figura 3.1, a Fatia um alocao
horizontal nos agregados provendo a interconexo de seus componentes e provendo o
plano de controle isolado ao experimentador.
Tais recursos reservados (chamados de Slivers) podem estar localizados em di-
ferentes e heterogneos agregados. O sistema de controle de referncia do GENI deve
prover um acesso remoto que permita aos pesquisadores descobrir, reservar, congurar,
programar, debugar, operar, gerenciar e desligar recursos dentro de uma fatia para com-
pletar um experimento.
As Fatias devem ter um tempo de vida considervel, e portanto poderiam ser uti-
lizadas em vrios experimentos em sequncia, por exemplo. Elas precisam ter uma iden-
ticao global e registro autenticado da alocao de Fatias. A partir das Fatias, cabe
ao controle permitir funes de congurao de experimentos, a partir de servios como
descoberta da topologia e descoberta de recursos. Os recursos, por sua vez, deveriam,
para melhor aproveitamento e multiplexao, suportar virtualizao ou outras formar de
compartilhamento justo. Para o uso de recursos deve haver a autorizao e alocao dos
mesmos a partir dos agregados, tudo isso pautado por polticas de uso a serem estabele-
cidas. Tais polticas de uso podero ser baseadas em uma variedade de parmetros como:
relaces de conana e de contrato com os atores do sistema, o status acadmico do pes-
quisador, a presena de um sistema econmico baseado em moeda virtual, e claro, na
disponibilidade momentnea do recurso.
3.4. Monitoramento dos CMFs Requisitos e Funcionalidades
Nesta seo apresentaremos os requisitos e principais funcionalidades de monitoramento
para os arcabouos de controle e monitoramento. Nos basearemos na Arquitetura de
Instrumentao e Monitorao do GENI (GENI I&M) [GENI 2010, Mussman 2012] por
ser uma das mais abrangentes e, assim sendo, poder servir como modelo de referncia
apesar de ainda se encontrar em estgios iniciais de seu desenvolvimento.
3.4.1. Requisitos de Monitorao
Redes experimentais necessitam basicamente de dois tipos de monitorao: monitorao
dos experimentos executados que sero teis para a anlise e reproduo dos experimen-
tos, e a monitorao da infraestrutura por parte dos operadores da mesma de modo que
possam acompanhar o estado de seus diversos componentes, identicar eventuais falhas,
garantindo assim um ambiente convel para a realizao dos experimentos. Natural-
mente, os experimentadores podem tambm ter acesso aos dados da monitorao da in-
fraestrutura para auxiliar-lhes na execuo de seus experimentos assim como para garantir
a reprodutibilidade dos mesmos.
Os objetivos gerais a serem alcanados pelo sistema de instrumentao e monito-
rao do GENI (GIMS GENI I&M System) so [GENI 2010]:
Fornecer funcionalidades abrangentes de coleta, anlise e arquivo de dados neces-
srios para a execuo com sucesso dos experimentos e do funcionamento da infra-
estrutura;
Remover do pesquisador a necessidade de ser um especialista em monitorao do
experimento e da infraestrutura de modo que ele possa se concentrar no seu experi-
mento propriamente dito;
Realizar as medies com alta preciso e acurcia de forma ubqua, extensvel, com
alta disponibilidade, segura e integrada sem impactar negativamente os experimen-
tos que esto sendo executados;
Prover informaes detalhadas sobre o desempenho do sistema e dos recursos da
rede ao nvel de cada etapa (hop), enlace (link), caminho (path) e fatia (slice) em
termos de disponibilidade, integridade e diagnstico de problemas percebidos e/ou
que causem impedimentos reais;
Permitir e facilitar que grupos de usurios possam acessar e controlar funes que
envolvam interaes entre subservios de I&M, incluindo recursos tais como deri-
vaes fsicas na rede, sensores de tempo, pontos de medio baseados em software
ou em hardware, MIBs de comutadores ou roteadores assim como arquivos de da-
dos de medio;
Prover uma transparncia do desempenho do estado dos componentes individuais
do subservio de I&M e suas interfaces com outros subservios de modo a garantir
a corretude das medies realizadas;
Prover mecanismos que tratem segurana, privacidade e controle de acessos aos
arquivos de dados de medio para permitir o acesso apenas a usurios autorizados,
e tambm para fornecer vises diferentes dos dados baseadas nos privilgios da
autorizao.
3.4.2. Grupos de Usurios e Casos de Uso
Do ponto de vista de monitoramento, no GENI I&M, foram identicados os seguintes
grupos de usurios: pesquisadores experimentadores, usurios de experimentos, operado-
res centrais, provedores e operadores de agregados, provedores e operadores de arquivos,
pesquisadores que fazem uso dos dados armazenados de monitorao.
Os pesquisadores experimentadores so aqueles que executam os experimentos
para a futura Internet utilizando fatias em diversos componentes da rede experimental.
Estes tm interesse em realizar testes que possam comprovar que os recursos solicitados
estejam efetivamente disponveis para os seus experimentos, com as caractersticas soli-
citadas. Eles tambm tm interesse de acompanhar o andamento de seus experimentos
em tempo de execuo de modo a observar qualquer problema. Podem tambm consultar
o estado de recursos de suas fatias para identicar eventuais problemas na infraestrutura
que podem estar causando inconsistncias nos dados de seus experimentos. Tm interesse
tambm em dados arquivados de medies de desempenho dos recursos de suas fatias de
modo que possam analis-los mesmo aps o tempo de vida das mesmas. Desejam ativar
pontos de medio ativa e/ou passiva e interfaces de modo a monitorar os dados coletados
utilizando ferramentas genricas ou especcas a algum fabricante. Podem solicitar que
sejam noticados em caso de alguma anomalia detectada a partir de limiares e ferramen-
tas especicadas pelos mesmos. Podem ainda solicitar que as medies de desempenho
de suas fatias sejam compartilhadas em tempo de execuo ou aps os mesmos com os
usurios do experimento ou com outros pesquisadores com a possibilidade de estabelecer
diferentes nveis de permisso.
Os usurios de experimentos, como o prprio nome diz, so usurios que par-
ticipam de algum experimento para utilizar seus recursos, aplicaes ou servios. Estes,
apesar de simples usurios do experimento, devem ter acesso a medies de desempenho
dos recursos que lhes foram alocados e/ou da aplicao ou servio que esto utilizando.
Com estes dados, tm condies de reportar ao pesquisador responsvel pelo experimento
sobre eventuais problemas de desempenho.
Os operadores centrais monitoram os recursos e processos da rede experimental
de uma forma consistente e convel para toda a infraestrutura formada por diversos agre-
gados e/ou componentes pertencentes a diferentes organizaes. Com esta nalidade eles
devem monitorar as diversas fatias para identicar alguma que possa comprometer os de-
mais experimentos e remov-la. Devem tambm ser capazes de identicar problemas em
recursos em diferentes agregados pertencentes a um dado experimento a partir de solicita-
o direta dos experimentadores. Devem ser capazes de congurar diversas monitoraes
passivas e ativas, disponibilizar estes dados em tempo real, assim como arquiv-los. De-
vem ainda ser capazes de analisar eventuais problemas na infraestrutura que possam ter
comprometido algum experimento.
Os provedores e operadores de agregados so aqueles que disponibilizam com-
ponentes computacionais ou de rede para serem utilizados nos experimentos, permitindo
aos usurios vericar o estado e disponibilidade destes componentes. Estes tm necessi-
dades semelhantes s dos operadores centrais, mas limitadas aos recursos que disponibi-
lizaram para a infraestrutura.
Os provedores e operadores de arquivos so responsveis pela catalogao dos
conjuntos de dados coletados em um repositrio fornecendo ferramentas para o com-
partilhamento, anotao, busca e referncia a estes conjuntos de dados de monitorao.
Necessitam de informaes dos demais usurios para poder catalogar mais ecientemente
os conjuntos de dados. Devem possuir mecanismos de autenticao que permitam contro-
lar o acesso dos diversos tipos de usurios aos dados armazenados. interessante ainda
que possam receber novas ferramentas que facilitem a anlise e visualizao dos dados
armazenados.
Finalmente, os pesquisadores que fazem uso dos dados armazenados de mo-
nitorao so usurios que nem realizaram nem participaram dos experimentos mas que
desejam utilizar os dados fornecidos pelos provedores de arquivos para analisar os dados,
testar hipteses, etc. Estes desejam realizar buscas nos dados, assim como compartilhar,
anotar e citar os dados utilizados para os seus estudos.
3.4.3. Servios de Instrumentao e Monitorao (I&M) para o GENI
Figura 3.2. Viso Geral dos Servios da Arquitetura GENI I&M
Na Arquitetura de Instrumentao e Monitorao do GENI [GENI 2010] foram
denidos os seguintes servios, que sero detalhados a seguir: Servio de Orquestrao
de Medies, Servio de Ponto de Medio, Servio de Informaes de Medio,
Servio de Coleta de Medies, Servio de Anlise e Apresentao de Medies e
Servio de Arquivo de Dados de Medio. Uma viso geral destes servios e de seus
relacionamentos apresentada na Figura 3.2.
O servio de Orquestrao de Medies (MO Measurement Orchestration)
faz parte de um servio de Controle do Experimento e tem como nalidade orquestrar as
funes de outros servios de I&M. Ou seja, da mesma forma que um experimentador
utiliza servios ou ferramentas de controle do experimento para reunir recursos numa
determinada fatia, congur-los e/ou program-los e executar seu experimento, ele utiliza
o MO para gerenciar os seus servios de I&M.
O servio de Ponto de Medio (MP Measurement Point) prov a funciona-
lidade de monitorao propriamente dita interagindo diretamente com a infraestrutura da
rede experimental, ou com os recursos de uma determinada fatia, exportando os dados
atravs de esquemas padronizados.
Dentre os MPs podemos citar sensores de enlace, de ns e de tempo. Os sensores
de enlace obtm sinais bsicos dos enlaces atravs de alguma derivao. Os sensores de
ns so instalados em todos os sistemas e provem dados bsicos de utilizao, estado e
congurao. Finalmente, os sensores de tempo so instalados em diversas instalaes
para produzir marcas de tempo de alta resoluo.
As aplicaes de um dado experimento podem fazer uso dos dados obtidos por
um determinado MP para algum tipo de adaptao de seu comportamento. Servios per-
sistentes, por exemplo, de dados da infraestrutura, podem ser registrados de modo que
possam ser usados por operadores e, se permitido, tambm por experimentadores.
Os servios de ponto de medio utilizam dados provenientes de diversas ferra-
mentas e/ou interfaces. Por exemplo, podem obter dados de MIBs (Management Infor-
mation Bases), de comutadores ou roteadores ou obter dados atravs de placas de captura
como as DAGs (Data Acquisition and Generation)
1
.
O servio de Informaes de Medio (MI Measurement Information) prov
um servio de registro e descoberta de dados de medio, incluindo informaes sobre a
topologia da infraestrutura de modo que os dados disponveis possam ser mapeados na
mesma.
O servio de Coleta de Medies (MC Measurement Collection) um servio
que recebe como entrada dados de medies e efetua algum processamento nos mesmos
tais como combinaes, transformaes ou armazenamento temporrio (cache). Espera-
se que seja desenvolvida uma grande variedade de opes em servidores de propsito
geral usando pacotes de software padronizados. Tanto as entradas como as sadas devem
usar esquemas denidos.
Oservio de Anlise e Apresentao de Medies (MAP Measurement Analy-
sis and Presentation) um sistema que recebe dados de medio de MCs ou diretamente
de MPs, analisa os mesmos e produz algum tipo de apresentao. Assim como os MCs,
espera-se que seja desenvolvida uma grande variedade de opes em servidores de pro-
psito geral usando pacotes de software padronizados. Tanto as entradas como as sadas
devem usar esquemas denidos.
Finalmente, o servio de Arquivo de Dados de Medio (MDA Measurement
Data Archive) prov um repositrio dos dados de medio tanto para experimentadores
como para operadores, assim como um Portal de acesso aos pesquisadores, se tiverem
autorizao para tal.
Espera-se que sejam disponibilizadas ferramentas que favoream o compartilha-
mento dos dados armazenados nestes repositrios.
1
http://dag.cs.waikato.ac.nz/
3.4.4. Cenrios de Uso dos Servios
Estes servios podem ser usados, por exemplo, para que: (i) um experimentador utilize
dados de medio de sua fatia; (ii) um operador obtenha dados da infraestrutura da rede
experimental; ou (iii) um experimentador utilize dados de medio de sua fatia e da infra-
estrutura da rede.
Nos casos em que experimentadores utilizem dados de medio de sua fatia, os
servios MP, MC e MAP fazem parte da fatia do experimentador e, portanto, so criados,
congurados e gerenciados pelos mesmos. O servio MO faz parte dos servios de Con-
trole do Experimento e utilizado pelo experimentador para gerenciar os seus servios de
I&M. Os dados de medio esto contidos na fatia e pertencem, portanto, ao experimen-
tador que pode compartilh-los ou no com outros experimentadores, pesquisadores e/ou
operadores.
Um operador poder criar, atravs de servios/ferramentas de Controle de Expe-
rimento, uma fatia para monitorar os recursos do operador. Numa infraestrutura federada
como a GENI tipicamente teremos MPs sendo executados por diferentes provedores de
servio que podem registrar os seus uxos de dados de medio no servio MI, de modo
que o operador consultando-o passe a receber estes uxos que podem ser ento analisados
e apresentados atravs de grcos da infraestrutura da rede. Neste caso os servios MP,
MI e MAP tm diferentes proprietrios e fazem parte de diferentes fatias.
Finalmente, caso um experimentador deseje tambm receber dados da infraestru-
tura da rede, ele dever descobrir a disponibilidade destes dados atravs de uma consulta
ao servio MI e, sendo autorizado para usar o uxo, congurar um MC para receber os
dados tanto de seus MPs como de MPs pertencentes ao provedor de servio.
3.4.5. Tipos de Servios
Os servios de I&M do GENI foram classicados em quatro tipos de acordo com o seu
uso: (1) servio contido em uma fatia; (2) plataforma de servio comum com mltiplos
pedaos de componentes (slivers) dedicados a mltiplos experimentos; (3) servio comum
com dados compartilhados fornecidos a mltiplos experimentos; e (4) servio MDA com
um portal para o compartilhamento de dados.
No tipo 1, o servio est contido dentro de uma nica fatia de propriedade de um
experimentador, de um provedor de servio ou de um operador. Em muitos casos podem
ser usados servios de I&M em srie dentro de uma fatia. Neste caso, necessrio um
processo de costura (stitching) para que haja um uxo de dados de monitorao da sada
de um servio para a entrada do prximo servio.
No tipo 2, h uma plataforma de servio comum montada, congurada e gerenci-
ada por um provedor de servio e mltiplos pedaos que so adquiridos, congurados e
gerenciados por vrios proprietrios de fatias (experimentadores ou operadores).
No tipo 3, h um servio comum montado, congurado e gerenciado por um pro-
vedor de servio que prov dados de medies para mltiplas fatias (de propriedade de
experimentadores ou operadores). O provedor deve determinar como os dados podem ser
usados ou compartilhados com experimentadores e/ou operadores.
No tipo 4, o compartilhamento dos dados de monitorao realizado atravs do
acesso a um portal. O proprietrio dos dados decide como ele pode ser compartilhado
com outros experimentadores e pesquisadores que no estejam associados mesma fatia.
3.4.6. Ferramentas de I&M Relacionadas
Conforme mencionamos anteriormente, o GIMS ainda se encontra em fase preliminar de
desenvolvimento. De qualquer forma, nesta subseo apresentaremos duas infraestruturas
que esto sendo montadas baseadas em ferramentas pr-existentes buscando uma conver-
gncia para o GIMS: a GEMINI e GIMI, e uma infraestrutura independente desenvolvida
no contexto do projeto OneLab, a TopHat.
O GEMINI (A GENI Measurement and Instrumentation Infrastructure) [Swany
et al. 2011] um projeto da quarta espiral do GENI que ir estender e integrar as fer-
ramentas produzidas pelos projetos LAMP e INSTOOLS iniciados na segunda espiral
aproveitando a complementariedade das mesmas.
O projeto LAMP (Leveraging and Abstracting Measurements with perfSONAR)
[Swany and Boyd ] tem como objetivo aproveitar as ferramentas e servios desenvolvi-
dos para o perfSONAR
2
(PERFormance Service Oriented Network monitoring ARchitec-
ture) [Hanemann et al. 2005] um ambiente de monitorao de redes multidomnios
orientada a servios. Neste ambiente, ferramentas de monitorao tais como BWCTL
3
e
OWAMP
4
so usadas para efetuar medies ativas de largura de banda, atraso e perdas
em um sentido entre pontos de medio (MPs) instalados em pontos estratgicos de uma
infraestrutura de redes. No cenrio original de uso, so realizados testes regulares ou sob
demanda para que sejam identicados eventuais problemas de desempenho que possam
indicar falhas de conectividade, roteamento, etc. O perfSONAR um middleware que in-
terage com ferramentas de monitorao e dados de medio coletados das mais variadas
formas e disponibiliza estes mesmos dados atravs de uma interface padro orientada a
servios, utilizando esquemas denidos pelo grupo de trabalho de monitorao de redes
(NM-WG Network Monitoring Working Group)
5
do Open Grid Forum (OGF)
6
.
No projeto LAMP foi criado umsistema de instrumentao e monitorao baseado
na verso PS do perfSONAR
7
no qual foi includa a ferramenta Ganglia
8
para o moni-
toramento de grades computacionais, no contexto do ambiente de controle ProtoGENI a
ser apresentado na Subseo 3.5.2. A inteno dos pesquisadores responsveis por este
projeto era a de colaborar no planejamento e desenvolvimento da arquitetura do GIMS
enfatizando um formato extensvel de armazenamento e compartilhamento dos dados. De
fato, h uma grande semelhana entre os servios e formatos de dados do perfSONAR e
aqueles que esto sendo considerados para o GIMS.
Enquanto que o LAMP teve a sua origem no monitoramento de infraestruturas de
2
http://www.perfsonar.net/
3
http://www.internet2.edu/performance/bwctl/
4
http://www.internet2.edu/performance/owamp/
5
http://www.ogf.org/gf/group_info/view.php?group=nm-wg
6
http://www.ogf.org/
7
http://www.internet2.edu/performance/pS-PS/
8
http://ganglia.sourceforge.net
redes, o INSTOOLS (Instrumentation Tools for a GENI Prototype) [GENI 2012, Duerig
et al. 2012,Grifoen et al. 2009] teve a sua origememinstrumentar o ambiente de usurio,
inicialmente no Emulab e posteriormente no ProtoGENI, atravs de uma interface simples
e fcil de ser utilizada dentro de uma fatia do GENI.
O INSTOOLS composto basicamente por pontos de medio (MPs) passiva que
so instalados automaticamente em cada recurso da fatia e capturam dados de medio de
diversas formas e por controladores de medies (MCs Measurement Controllers) que
coletam, armazenam, processam e apresentam os dados atravs de um portal. O sistema
cria pelo menos um MC para cada um dos agregados que so utilizados no experimento
(na fatia). Isto feito para que o MC seja adaptado a cada agregado e possa oferecer
recursos de monitorao que sejam especcos a cada um deles.
No GEMINI espera-se utilizar a interface existente do INSTOOLS com os arca-
bouos de controle, assim como o seu portal e se beneciar dos padres e denies de
metadados do perfSONAR/LAMP, para facilitar o acesso de outras ferramentas de visua-
lizao aos dados coletados [Grifoen ]. Espera-se ainda incluir ferramentas de medio
ativas disponveis hoje apenas no LAMP.
Alm destes aproveitamentos de cada um dos projetos anteriores est prevista a
realizao de novos desenvolvimentos tais como [Swany et al. 2011]: o desenvolvimento
de um registro global (GGR GEMINI Global Registry) estendendo o UNIS (Unied
Network Information Services) j disponvel no LAMP; implementao da funcionalidade
de publicao e assinatura; a ampliao das medies (origens dos dados); integrao do
OpenFlow [McKeown et al. 2008]; visualizao com a ferramenta WorldView
9
; extenso
do sistema de arquivamento (est sendo considerado o uso do iRODS
10
); e renamento e
adaptao arquitetura do GIMS.
O projeto GIMI (Large-scale GENI Instrumentation and Measurement Infras-
tructure) [Zink 2011] tem como objetivo prover ferramentas fceis de usar baseadas na
OML (Orbit Measurement Library)
11
[Singh et al. 2005] para o ambiente GENI, colabo-
rando com os demais projetos, em particular, o GEMINI.
A OML um ambiente de software distribudo que permite a coleta de dados em
tempo real num ambiente de larga escala. Apesar de ter sido desenvolvido para o ambi-
ente ORBIT, ele pode ser usado em qualquer outro ambiente. A OML possui trs com-
ponentes principais: o servio OML (OML-Service), a biblioteca de cliente (OML-Client
library) e o servidor de coleta de dados (OML-Collection-Server). O servio OML gera
o cdigo necessrio para que aplicaes escritas em C/C++ possam interagir com a OML
criando tambm arquivos de execuo do experimento para o cliente e servidor baseados
na denio do experimento. A biblioteca de cliente instalada nos ns participantes do
experimento e poder agregar e ltrar os dados recebidos das aplicaes participantes do
experimento enviando-os ao servidor central. Este contm tambm um servidor proxy
para armazenar os dados caso este esteja temporariamente desconectado do servidor, o
que bem comum em ns mveis. Finalmente, o servidor de coleta de dados coleta os
dados provenientes de todos os ns envolvidos no experimento armazenando-os em uma
9
http://globalnoc.iu.edu/worldview.html
10
http://www.irods.org
11
http://www.orbit-lab.org/wiki/Documentation/OML
base mySQL.
Ao ser usado no GINI o cliente OML deve ser instalado em cada n como MPs e
o servidor OML como um MC em cada fatia do experimento. Dado que as fatias so no
persistentes, convm exportar os dados do servidor para um servidor persistente no espao
do usurio ou num portal, antes que a fatia expire. Para o armazenamento dos dados,
assim como no GIMINI, tambm est sendo considerado o uso do iRODS. Podem ainda
ser associados servios de anlise aos servidores OML, cujos dados tambm podem vir
a ser exportados atravs de uma interface perfSONAR para compartilhamento de dados
utilizando ferramentas do GEMINI.
TopHat o componente de medies ativas do PlanetLab Europa (PLE) que prov
para as aplicaes do PL e, em particular, ao MySLICE
12
, um servio de monitorao de
topologia durante todo o ciclo de vida de um experimento [Bourgeau et al. 2010]. A partir
das medies realizadas, os usurios podem melhor alocar sua fatia, recursos que melhor
atendam os requisitos do experimento, incluindo conectividade e atrasos.
O TopHat alimenta de forma transparente o MySlice com informaes de diver-
sos sistemas de monitorao tais como a TDMI (TopHat Dedicated Measurement), o
DIMES
13
que estuda a estrutura e topologia da Internet, ETOMIC [Csabai et al. 2010]
(que prov um servio semelhante ao obtido com o perfSONAR usando a ferramenta
OWAMP), SONoMA
14
, e de outros servios de informao tais como o Team Cymru
15
que prov um servio de mapeamento de endereo IP para AS (Autonomous System).
3.5. Exemplos de Testbeds e respectivos CMFs
Nesta seo sero resumidas descries de vrias testbeds e os CMFs relacionados s
mesmas. Cada resumo cobrir desde histrico, os conceitos bsicos, breve descrio
sobre a arquitetura, e exemplo de testes.
3.5.1. Planetlab
O PlanetLab
16
uma plataforma de computao distribuda que foi criada e mantida por
uma comunidade de pesquisa em mais de 405 localidades em mais de 35 pases. Os par-
ticipantes do PlanetLab disponibilizam uma quantidade de ns (normalmente pequena, e
no mnimo dois computadores) e em contrapartida podem utilizar os recursos comparti-
lhados disponveis em toda a plataforma para implantar e avaliar experimentos de rede
em uma escala global [Peterson and Roscoe 2006]. Os objetivos que motivaram a criao
do PlanetLab [Peterson et al. 2003] foram:
Fornecer para os pesquisadores uma plataforma de experimentao para servios
de rede em mbito global;
Fornecer uma plataforma para servios de rede inovadores que possam ser implan-
tados e usados por uma comunidade real de usurios; e
12
myslice.onelab.eu
13
http://www.netdimes.org/
14
http://complex.elte.hu/sonoma/
15
http://www.team-cymru.org/
16
http://www.planet-lab.org/
(a) Componentes dos Ns PlanetLab (b) Arquitetura do PlanetLab
Figura 3.3. PlanetLab
Proporcionar um catalizador da evoluo da Internet em uma arquitetura orientada
a servios.
importante frisar que o PlanetLab foi projetado para executar experimentos de
servio de rede em condies similares ao mundo real, no para fornecer um ambiente
controlado de testes. Isso uma consequncia natural da plataforma devido quantidade
de recursos envolvidos e que so controlados por diversas organizaes do mundo, su-
jeitos a diferentes condies. Exemplicando: algumas das mquinas que faziam parte
de uma experincia executada ontem podem ter falhado, cado sem espao em disco, fo-
ram atualizadas ou reconguradas; entre muitos outros possveis problemas, tornando-as
indisponveis para a repetio de um experimento.
3.5.1.1. Arquitetura
O PlanetLab composto de vrias ilhas que esto distribudas em vrias localidades. Os
principais elementos do PlanetLab so:
Sistema operacional dos ns. Fornece isolamento das fatias e audita o comporta-
mento dos ns;
Central do PlanetLab (PlanetLab Central PLC). Gerencia remotamente os ns.
Alm disso, realiza o servio de inicializao para instanciar e controlar as fatias;
Servios de infraestrutura. Monitoram as fatias e suas condies operacionais, des-
cobrem os recursos disponveis, criam/conguram as fatias e realizam a alocao
de recursos.
Cada n PlanetLab (gura 3.3(a)) possui software preparado para interagir com
os elementos do PlanetLab, permitindo a sua conexo com as autoridades da plataforma
e tambm concedendo alguns direitos de administrao local. As mquinas virtuais de-
vem ser conguradas usando uma imagem padro disponvel na plataforma, a m de que
possam ser gerenciadas e fornecer os dados para as anlises dos experimentadores.
A gura 3.3(b) ilustra os principais elementos da arquitetura do PlanetLab:
Ilhas. Cada ilha pertence a uma instituio que proprietria dos ns que a compe.
Hospeda um ou mais ns PlanetLab;
Escolhe uma Autoridade de Gerenciamento a qual ir se subordinar e aprova
uma ou mais Autoridades de Fatia de Experimentao.
Provedores de Servios (Desenvolvedores):
Desenvolvem e implementam experimentos de servios de rede;
Responsveis pelo comportamento dos servios;
Autoridade de Gerenciamento (Management Authority MA):
Responsvel por instalar e manter atualizados os softwares nos ns;
Cria mquina virtuais (Virtual Machines VM) e monitora o seu comporta-
mento;
Autoridade de Fatia de Experimentao (Slice Authority SA):
Registra os Provedores de Servio;
Cria fatias e as conecta com o provedor adequado/responsvel.
3.5.2. ProtoGENI
O ProtoGENI um arcabouo de controle que parte integrante do Cluster C [gen 2012]
do projeto GENI desenvolvido pelo Flux Research Group
17
da Universidade de Utah. Seu
projeto est fortemente baseado no sistema Emulab
18
, que foi desenvolvido pela mesma
equipe.
O arcabouo de controle do ProtoGENI foi projetado com base na arquitetura
SFA Slice-based Facility Architecture, que ser discutida na seo 3.6. Sendo assim, o
ProtoGENI interage com os vrios testbeds atravs da organizao destes em federaes
que interagem como arcabouo de modo a aprovisionar e fornecer os recursos necessrios
para realizar as tarefas envolvidas em um experimento. A estrutura do ProtoGENI
formada pelos seguintes elementos (gura 3.4):
Central de Informaes (Clearinghouse): inclui o registro de usurios, fatias e
Agregados/Componentes. Alm de alguns servios comuns e especcos para re-
gistros;
Autoridade de Fatias de Experimentao (Slice Authority SA);
Gerenciador de Agregados (Aggregate Manager AM); e
Usurios (incluindo os experimentadores).
Todas as autoridades do ProtoGENI possuem uma interface XMLRPC
19
com os
clientes atravs de HTTP e SSL. Cada servio possui uma nica URL na Central de In-
formaes e todas as requisies so realizadas atravs deste endereo, sendo que tanto o
cliente como o servidor devem se autenticar durante o estabelecimento da conexo. Alm
disso, cada membro da federao possui um certicado X.509 auto assinado e todos os
certicados so distribudos pela Central de Informaes. O cdigo do ProtoGENI est
disponvel atravs de um repositrio GIT
20
.
17
http://www.cs.utah.edu/flux/index.html
18
http://www.emulab.net/
19
http://www.protogeni.net/trac/protogeni/wiki/XMLRPCInterface
20
http://users.emulab.net/trac/emulab/wiki/GitRepository
Figura 3.4. Viso Geral do arcabouo do ProtoGENI
3.5.2.1. Central de Informaes
A Central de Informaes o elemento central para encontrar informaes sobre os com-
ponentes gerenciados, usurios, fatias, etc. Seus objetivos so:
Ajudar os Gerenciadores de Componentes e os utilizadores dos recursos (experi-
mentadores) a encontrarem os elementos necessrios para elaborar suas experin-
cias atravs dos registros.
Estabelecer conana na federao, servindo como um ponto central de conana,
por onde todos os membros da federao podem trocar certicados e Listas de
Certicados Revogados.
3.5.2.2. Autoridade de Fatias de Experimentao
A Autoridade de Fatias de Experimentao responsvel por uma ou mais fatias, sendo
responsvel por atribuir nomes, registrar e permitir que os usurios acessem e controlem
suas fatias. A Autoridade de Fatias de Experimentao deve fornecer uma interface de
contato para obter informaes sobre as fatias ou para responder a qualquer abuso iden-
ticado nas fatias. Cada membro da federao executa um servidor XMLRPC para a
Autoridade de Fatias de Experimentao. Os experimentadores utilizam certicados para
se autenticarem com a Autoridade de Fatias de Experimentaos local, que por sua vez
permite validar o usurio em toda a federao.
3.5.2.3. Gerenciador de Agregados
No ProtoGENI o elemento mais bsico a ser gerenciado o componente, que pode ser:
um computador, roteador personalizvel ou um ponto de acesso programvel. Cada com-
ponente encapsula uma conjunto de recursos, que incluem recursos fsicos (e.g., CPU,
memria, disco, banda de rede), recursos lgicos (e.g., descritores de arquivo e nmeros
de portas) e recursos sintticos (e.g., atalhos para encaminhamento de pacotes). Esses
recursos podem estar contidos em um nico dispositivo ou dispersos em um conjunto de
dispositivos, dependendo da natureza de cada componente. importante ressaltar que
um recurso s pode pertencer a um componente. Os componentes por sua vez podem ser
agrupados em agregados, lembrando que todos os componentes de um agregado devem
estar sob autoridade do mesmo Gerenciador de Agregados e que este tambm governa
o agregado. O Gerenciador de Agregados exporta uma interface que torna o agregado
remotamente acessvel. Quando o Gerenciador de Agregados contm apenas um com-
ponente, ele pode ser considerado tambm um Gerenciador de Componentes. Tanto o
Gerenciador de Agregados como o Gerenciador de Componentes denem as operaes
disponveis aos servios a nvel do usurio para gerenciar as alocaes dos recursos para
diferentes usurios e experimentos.
O Gerenciador de Agregados do ProtoGENI suporta:
Autenticao de usurios e vericao de credenciais;
A Component Manager API que permite aos contribuidores informarem os compo-
nentes que esto disponibilizando para o PlanetLab;
Anunciar os seus recursos disponveis, atravs de RSpec;
Aceitar a requisies de criao de fatias de qualquer membro da federao;
Polticas locais simples para fornecer recursos a usurios de outros membros da
federao;
Criar multiplas instncias (slivers) nos computadores; e
Criar as topologias de rede entre os computadores disponveis.
O arcabouo de controle do ProtoGENI possibilita a incluso de vrios agregados
federados e seus componentes, possibilitando uma ampla gama de recursos aos experi-
mentadores.
3.5.2.4. Exemplos
O ProtoGENI possui um formato prprio que usado para a especicao dos recursos,
chamado RSpec. O RSpec utilizado para divulgar, requisitar e descrever os recursos
disponveis a serem usados pelos experimentadores, sendo este baseado em um formato
similar ao utilizado pelo Emulab. Um exemplo simples para alocar um nico n:
set nodeA [$ns node]
tb-set-hardware $nodeA pcfedphys
tb-fix-node $nodeA urn:publicid:IDN+emulab.net+node+
*
Nesse exemplo est sendo requisitado o n pcfedphys, que uma mquina fsica
(foram apresentadas apenas as informaes relevantes do arquivo NS, onde so denidas
as associaes dos componentes). Est especicado que o n seja alocado a partir do
cluster de Utah, mas no est especicado nenhum n em especco, logo o sistema vai
alocar qualquer n livre. Caso seja desejado alocar um n especco, pode-se mudar o
URN para:
tb-fix-node $nodeA urn:publicid:IDN+emulab.net+node+pc333
Nesse comando especicado um n, porm este n deve obrigatoriamente estar
livre e disponvel quando o experimento for instanciado.
Para instanciar o experimento, necessrio acessar a interface Web do Emulab/-
ProtoGENI e utilizar a opo Begin Experiment. Na interface deve ser selecionado o
projeto em que o experimento ser congurado e preenchido os campos Name e Descrip-
tion com o nome e descrio do experimento, respectivamente. No campo Your NS le,
deve ser informado o caminho para o arquivo NS criado anteriormente. Aps a submis-
so, o experimento ser processado e, se no houver erros, os recursos solicitados sero
alocados. Quando o experimento estiver alocado, possvel vericar o sucesso da alo-
cao atravs da pgina Show Experiment, onde o n alocado para o experimento dever
estar listado. Este n um proxy para os recursos administrados pelo ProtoGENI, cli-
cando sobre o nome do n ser possvel acessar uma variedade de informaes sobre este
n. O campo de Hostname a informao que deve ser utilizada para acessar o n via
SSH.
Alm de alocar mquinas fsicas tambm possvel alocar mquinas virtuais.
Caso a aplicao do usurio permita, ser possvel utilizar vrias mquinas virtuais em
uma nica mquina fsica e, deste modo, oferecer uma outra alternativa de se obter todos
os recursos desejados para o experimento. Exemplo:
set nodeA [$ns node]
set nodeB [$ns node]
tb-set-node-os $nodeA GENIVM
tb-set-hardware $nodeA pcfed
*
tb-set-node-os $nodeB GENIVM
tb-set-hardware $nodeB pcfed
*
Aps instanciar o experimento, possvel visualizar na pgina Show Experiment
os dois ns listados. Clicando sobre os nomes dos ns, possvel encontrar a informao
de Hostname, bem como o nmero da porta SSH que necessria para conectar-se a este
n. Por exemplo, se o Hostname for pc76.emulab.net e o nmero da porta 32333, ento o
comando para acessar este n ser:
ssh -p 32333 pc76.emulab.net
3.5.3. PrimoGENI
O PrimoGENI
21
um agregado integrado ao arcabouo de controle do ProtoGENI para
possibilitar a simulao de redes em tempo real. As instncias do agregado PrimoGENI
so compostas de recursos virtuais, como a rede virtual que inclui elementos simulados
(roteadores, servidores, enlaces e protocolos) e elementos emulados (hosts e roteadores
executando em mquinas virtuais); e os meta recursos associados instanciao da rede
virtual.
O PrimoGENI usa o ProtoGENI/Emulab para gerenciar, controlar e acessar os
seus meta recursos. Alm disso, o simulador PRIME [Pri 2012] empregado para criar,
gerenciar, controlar e acessar os recursos virtuais. Os meta recursos so instanciados a
partir das instalaes fsicas denidas no ambiente ProtoGENI/Emulab. Por sua vez, os
recursos virtuais so instanciados sobre os meta recursos previamente instanciados.
O PrimoGENI possui uma interface de interao com outros elementos do arca-
bouo de controle, que utiliza a API de Controle de Componente do ProtoGENI para se
comunicar com as centrais de informaes utilizando os protocolos XMLRPC, HTTPS e
21
http://groups.geni.net/geni/wiki/PrimoGENIDesignDocument
SSH.
3.5.4. ORCABEN
O ORCABEN
22
um arcabouo de controle que parte integrante do Cluster D [gen
2012] do projeto GENI desenvolvido pelo Flux Research Group. O ORCABEN um
projeto conjunto entre o grupo NRIG (Rede de Pesquisa e Grupo de Infraestrutura) do
Instituto RENCI
23
e o grupo NiCl da Universidade Duke. O projeto tem como objetivo
adaptar o arcabouo de controle ORCA da NiCl infraestrutura BEN
24
, uma rede ptica
experimental de escala metropolitana, para permitir ao ORCA criar e gerenciar fatias de
experimentao na infraestrutura BEN em vrias camadas: desde a camada fsica, atravs
de DWDM (Dense Wavelenght Division Multiplexing) at as camadas 2 e 3.
3.5.4.1. Viso Geral do ORCA
O ORCA um arcabouo de controle de cdigo aberto para gerenciar recursos comparti-
lhados controlveis atravs de programao, que podem conter qualquer combinao de
servidores, equipamentos de armazenamento, redes, ou outros componentes de computa-
o em nuvem.
Existem trs agentes principais na arquitetura do ORCA, representando os pro-
vedores de recursos, experimentadores e intermedirios, respectivamente. Podem haver
vrias instncias de cada um desses agentes, por exemplo, que representem diferentes
provedores de recursos ou diferentes experimentadores. So eles (gura 3.5):
Figura 3.5. Viso Geral do ORCA
Gerenciador de Agregados (Aggregate Manager AM). Controla o acesso a um
subconjunto de componentes;
Gerenciador de Fatias de Experimentao (Slice Manager SM). responsvel por
criar, congurar e adaptar uma ou mais fatias;
Intermediador (Broker). Possibilita a descoberta e alocao de recursos, contro-
lando o agendamento dos recursos a um ou vrios prestadores de recursos ao longo
do tempo. Pode ser visto como um dos servios que executado dentro de um
Centro de Informao.
22
http://groups.geni.net/geni/wiki/ORCABEN
23
http://www.renci.org/
24
https://ben.renci.org/
O Gerenciador de Agregados disponibiliza os recursos para serem alocados atra-
vs do Intermediador (um Gerenciador de Agregados pode disponibilizar os recursos para
um ou mais Intermediadores). O Intermediador reserva os recursos requisitados at o SM
solicit-los. Os AMs criam as instncias de recursos e passam o controle das instncias
ao SM.
3.5.4.2. Viso Geral do BEN
A infraestrutura BEN (Rede Experimental Particionvel) uma plataforma nica para a
experimentao de redes localizada no Research Triangle Park, na Carolina do Norte e
composto por vrios segmentos de bra escura, formando um recurso de tempo com-
partilhado que est disponvel para a comunidade de pesquisa. O BEN uma instalao
criada e gerida por pesquisadores e cientistas, a m de promover a descoberta cientca,
fornecendo uma infraestrutura e recursos para a experimentao com tecnologias de rede
disruptivas.
Cada PoP RENCI
25
compartilha a arquitetura de rede, o que permite os seguintes
recursos de apoio investigao:
Comutador de bra recongurvel (camada 0) fornece acesso dos pesquisadores
s portas de bra para atribuir dinamicamente novas conexes, o que possibilita
congurar diferentes topologias fsicas;
Soluo de gerenciamento Out-of-band, permitindo o acesso aos equipamentos ins-
talados no PoP; e
Gerenciamento remoto de energia para permitir a reinicializao automtica e des-
ligamento do equipamento experimental.
3.5.5. OFELIA-CF
O OFELIA uma iniciativa da European Union 7th Framework Programme - FP7 que
prov uma infraestrutura experimental (testbed) nica baseada em Openow, alm do
software OFELIA CF (OCF) estar disponvel publicamente. Este projeto permite que
pesquisadores no quem somente restritos a testar a rede, mas tambm, permite o com-
pleto controle da mesma de maneira precisa e dinmica, a partir do substrato OpenFlow.
Iniciou a operao em 2010 e possui 8 ilhas OpenFlow interconectadas na Europa. Tais
ilhas permitem experimentao em multi-camadas e multi-tecnologias de redes, com pro-
gramabilidade suciente para o experimentador montar sua prpria rede em nuvem.
O OFELIA faz uso de vrios servios web e softwares como Expedient e Optin (Fi-
gura 3.6(a)) para gerenciar os recursos das ilhas OpenFlow. Sua interface web inspirada
em sites de viagens, nos quais o usurio pode reservar um vo, hotel, carro, no mesmo
sistema. A Figura 3.7(a) apresenta os principais componentes do arcabouo [Kopsel and
Woesner 2011].
25
http://www.renci.org/
(a) Arquitetura OFELIA (b) Parte Interna do OFELIA
Figura 3.6. OFELIA
Internamente o OFELIA CF (Figura 3.6(b)), utiliza-se do software proxy de con-
trole do openow, o chamado FlowVisor (FV na gura), para criar fatias de experimen-
tao. O FlowVisor trabalha com o conceito de FlowSpaces, particionando a rede, do
ponto de vista de controle, para suportar vrios controladores OpenFlowao mesmo tempo.
Esse particionamento baseado em conjuntos de campos de cabealhos como rtulos de
VLAN onde, baseado nos cabealhos, mensagens de controle sero enviadas aos respec-
tivos controladores dos usurios. A partir disso, um Controlador do experimentador pode
controlar switches Openow (representado por X na gura) da infraestrutura e instan-
ciar mquinas virtuais (VMs) associadas a esses rtulos de VLAN para seu experimento.
Maiores detalhes do OFELIA CF so apresentadas na seo 3.7.
3.5.6. OMF
O ORBIT Management Framework (OMF) foi desenvolvido na Universidade Rutgers em
conjunto com o NICTA (National ICT Australia) para controlar experimentos de redes
sem-o atravs da criao de testbeds. Seu desenvolvimento comeou em 2003 e desde
ento passou a ser adotado em projetos de testbeds da Internet como mdulo sem-o.
A Figura 3.7(a) apresenta os principais componentes do arcabouo [Raychaudhuri et al.
2005]:
Node Handler: Dissemina scripts experimentais usando multicast para o n Agente
que residem nos ns individuais, a m de orquestrar o experimento.
Collection Server: Coleta as medidas noticadas durante o experimento.
Disk Loading Server: Permitir uma rpida re-imagem de discos rgidos em ns
conforme as exigncias do experimentador.
Node Agent: Trata-se do equivalente ao componente NodeHandler que reside em
ns ORBIT e escuta comandos do Node Handler ORBIT.
(a) Arquitetura OMF (b) Workow OMF
Figura 3.7. OMF
ORBIT Measurement Library (OML): Dene as estruturas de dados e funes para
envio / recepo e (de)codicao de dados de medio que so trocados em for-
mato XDR.
Para criar e executar experimentos em OMF, conforme a Figura 3.7(b), existe um
script com as conguraes detalhando e identicando as caractersticas dos ns do expe-
rimento a ser realizado. Ele passado para o Node Handler que assume a responsabilidade
de escalar os Node Agents. Cada Node Agent tem n antenas e um OML-Client que se
conecta ao OML-Server. O OML-Server pega os dados do OML-Client gerado pelas an-
tenas e ento processa gerando as estatsticas que so armazenadas em Banco de Dados.
Assim quando o observador acessar as pginas, essa acessar a base de dados gerando os
grcos.
3.5.6.2. Exemplos
Exemplos de pesquisas experimentais incluem redes para veiculares e redes P2P sem
o [Dwertmann et al. 2009]. A inteno dos pesquisadores incluir interfaces com
o PlanetLab, ORCA e GENI de tal forma que essas testbeds incluam o OMF nas suas
respectivas testbeds [Stasi et al. 2009].
O Network Implementation Testbed ou NITOS um testbed com foco em redes
sem o de cdigo aberto, administrado pelo CERTH, um parceiro do projeto OneLab.
O NITOS consiste de 50 ns localizados na Universidade de Thessaly, e j foram feitas
pesquisas de coliso de pacotes, erros, frequncias, algoritmos de controle de carga e
otimizao de trfego, ecincia energtica, etc. Tambm h um suporte a operaes
off-line importante em experimentos de mobilidade.
Existem outros testbeds sem o menores que fazem parte do OneLab e usam tam-
bm o OMF para prova de conceitos: ETH Zurich e INRIA. No total, mais de 20 testbeds
do mundo todo usam o OMF, incluindo seis de larga escala (meso-scale) com suporte a
WiMAX.
(a) Arquitetura Panlab (b) Sistema Teagle na arquitetura Panlab
Figura 3.8. Panlab
3.5.7. Panlab
O Pan-European Laboratory (Panlab) uma iniciativa do European Union 6th Fra-
mework Programme - FP6, com o objetivo de conceber uma plataforma de rede com
o conceito de oferecer facilidades de testes sob a tica de federao de testbeds. O con-
ceito do Panlab interconectar diversos laboratrios no conceito de federao e oferecer
um servio m-a-m coordenados a partir de uma entidade centralizada.
O Panlab pode ser classicado como uma rede de domnios federados (Network Domain
Federation NDF) [Wahle et al. 2008] e organizado conforme mostra a gura 3.8(a).
A arquitetura constituda por trs entidades descritas a seguir:
Panlab Partners: Entidades participantes do Panlab que oferecem elementos de
infra-estrutura de comunicao e servios (recursos). Cada parceiro possui sua pr-
pria infra-estrutura que disponibilizada a partir de um acordo com a Federao
Panlab.
Panlab Customer: Entidade usuria dos servios oferecidos pelo administrador
(Panlab Ofce) utilizando os recursos dos parceiros (Panlab Partners).
Panlab Ofce: Entidade administrativa que realiza a coordenao do sistema global
e negocia os recursos de teste solicitados pelos usurios (Panlab Customers). Ela
responsvel por provisionar a infraestrutura atravs dos participantes da federao
(Panlab Partners) atravs de uma ferramenta apropriada.
A ligao fsica entre os parceiros para criar a rede de teste pode ser estabele-
cida conforme a tecnologia disponvel. No entanto, consideramos que deve ser uma
tecnologia que propicie uma rede sobreposta (overlay) denindo caminhos como Vir-
tual Private Network (VPN) [Andersson and Madsen 2005], Virtual Private LAN Service
(a) Interfaces do sistema Teagle (b) Arquitetura do sistema Teagle
Figura 3.9. Teagle
(VPLS) [Kompella and Rekhter 2007], Generic Routing Encapsulation (GRE) ou Vir-
tual LAN (VLAN). O elemento gerenciador central chamado Teagle [Wahle 2008], cuja
localizao na arquitetura e funcionalidade mostrada na gura 3.8(b).
3.5.7.2. Teagle
O sistema Teagle [Wahle 2008] o elemento central de gerenciamento do Panlab im-
plementando a congurao e orquestrao do testbed. O Teagle prov uma interface
para os usurios (Panlab Customer) que recebe suas necessidades e determina a melhor
maneira de atend-los. A interface baseada em Web apresenta aos usurios todas as in-
formaes sobre a plataforma de testes, assim como as funcionalidades disponveis. Essa
plataforma tambm pode combinar diferentes componentes de teste em uma entidade fun-
cional nica, tornando possvel testes complexos onde um simples testbed no seria capaz
de oferecer [Magedanz et al. 2008].
O Teagle capaz de gerenciar vrios domnios, cada qual com sua prpria ad-
ministrao, que concordam em colaborar formando uma federao. O sistema dispe
das informaes de cada domnio, e a partir da requisio do usurio, ir determinar o
caminho mais adequado e estabelecer a melhor congurao. Cada domnio possui um
gerenciador de domnio, Domain Manager DM), responsvel por realizar a congura-
o em seus prprios dispositivos.
Como uma federao no pressupe a uniformidade de equipamentos, as inter-
faces entre seus componentes precisam estar bem denidas. A gura 3.9(a) mostra as
interfaces do sistema Teagle e o DM. As interfaces U denem a relao com os usurios
e as interfaces T entre o Teagle, os DMs e os equipamentos.
A gura 3.9(b) mostra a arquitetura detalhada do sistema Teagle. Essa ferramenta
prov uma interface para o usurio baseada em Web possibilitando que ele possa visu-
alizar os recursos disponveis e realizar o provisionamento do Virtual Customer Testbed
(VCT).
3.6. Federao de Testbeds: Criando Valor para Experimentadores (SFA 1.0
e 2.0)
Nesta seo, descreveremos o esforo que tem sido feito para denir, de uma maneira
padronizada, um conjunto mnimo de interfaces e tipos de dados que permitem a intero-
perao de vrias testbeds atravs do uso de abstraes como a federao do substrato
das redes participantes e a alocao de recursos baseada em fatias. Apresentaremos
tambm os principais conceitos relacionados a federao, tais como: entidades, compo-
nentes, agregados, dentre outros. Por m, descreveremos a principal API para federao
conhecida como SFA (Slice-based Federation Archicteture).
3.6.1. Introduo
No contexto de infraestruturas para experimentao de redes de comunicao, a federao
pode ser denida como a alocao unicada de recursos disponveis em diferentes test-
beds para realizao de testes [OneLab2_Executive_Committee_and_guests 2009]. Os
recursos disponveis em uma testbed podem ser os mais variados, tais como mquinas
(fsicas ou virtuais), roteadores, switches, pontos de acesso sem o, etc. Cada testbed
pode ter um controle administrativo independente, o que leva a uma conceito chave em
federao: existncia de objetivos comuns. Em uma federao de testbeds, esperado
que o principal objetivo seja realizar experimentos, em geral, com o intuito de estudar,
vericar, avaliar e/ou mensurar novas propostas (de algoritmos, mecanismos, arquitetu-
ras, sistemas, etc) para redes de comunicao ou sistemas distribudos. Alguns exemplos
de outros objetivos potenciais da federao de testbeds so: A) aumentar a escala dos
testes; B) aumentar o nvel de realismo ao qual prottipos so expostos; C) ter acesso
a recursos variados; D) economizar atravs de compartilhamento, acessando recursos de
outras testbeds; E) melhorar a qualidade da pesquisa, trocando resultados e criando uma
comunidade.
Por outro lado, a federao de testbeds precisa lidar com questes que afetam de
diferentes maneiras seus objetivos. Em geral, essas questes surgem porque cada testbed
em uma federao pode ter um conjunto de regras, polticas, hardware e software que
inuenciam sua relao com as demais, conforme ilustrado nos exemplos a seguir. Uma
testbed pode suportar repetibilidade de experimentos atravs da captura de traces e ree-
xecuo (replay) dos mesmos, enquanto outra testbed semelhante em termos de hardware
no oferece suporte emseu software de controle. Emuma federao podemhaver testbeds
que foram projetadas para garantir isolamento dos experimentos enquanto outras foram
desenvolvidas para permitir variabilidade semelhante do mundo real, ou seja, sem con-
trole. A heterogeneidade de hardware pode ser muito alta em uma federao, dicultando
a reserva de recursos e orquestrao de experimentos.
Neste documento, vamos abordar a federao de infraestruturas para experimen-
tao de redes de comunicao de maneira ampla, ou seja, considerando que testbeds
com caractersticas notadamente diferentes e em diferentes partes do mundo podem ter
interesse de se juntar a uma mesma federao. Por essa razo, apresentaremos a SFA
em detalhes nas sees que seguem, pois ela a proposta mais madura e abrangente para
federao de testbeds em escala global. No entanto, vamos citar algumas propostas alter-
nativas de escopo mais limitado. Em [Faber and Wroclawski 2008], os autores propem
uma arquitetura de federao chamada DFA (DETER Federation Architecture) com en-
foque em segurana de computadores. DETER (cyber-DEfense Technology Experimental
Research) baseado no software Netbed do Emulab [White et al. 2002], o qual foi uma
das primeiras implementaes de um arcabouo para controle e monitoramento de test-
beds. Os autores de [Sanchez et al. 2011] propem uma soluo para federao de test-
beds de rdios cognitivos. O objetivo oferecer recursos para lidar com as necessidades
especcas de redes cognitivas e de acesso dinmico ao espectro.
3.6.2. SFA 1.0
Originalmente, a SFA [Peterson et al. 2009c] (que expandia originalmente para Slice-
based Facility Architecture) foi proposta como uma especicao para suportar federao
entre infraestruturas como PlanetLab, Emulab, VINI e GENI, mas deveria estar preparada
para lidar comoutras testbeds comprojetos diferentes das anteriores. Aespecicao SFA
dene um conjunto mnimo de interfaces e tipos de dados que permitem a interoperabili-
dade de uma federao de testbeds que sejam baseadas em fatias de experimentao (ou
slices). Conforme descrito em [Tronco 2010], o ncleo da SFA a autorizao baseada
em autenticao de usurios de testbed. A autenticao realizada atravs de certicados
X.509 e a autorizao feita de maneira distribuda com base em polticas que so de-
nidas localmente pelo proprietrio do recurso. Assim, os principais aspectos arquiteturais
da SFA podem ser resumidos como um mecanismo de autenticao e uma linguagem para
descrever recursos, requisit-los e conceder acesso fatia de experimentao.
A SFA dene quatro tipos de pers de usurios na federao, chamados de atores:
Proprietrios so os donos de partes do substrato de rede, sendo responsveis por
denir o comportamento visvel externamente de seus equipamentos e estabelecer
as polticas de alto nvel para uso da sua poro do substrato.
Operadores administram partes do substrato de rede, em geral trabalhando para
os proprietrios. As principais tarefas dos operadores so manter a plataforma fun-
cionando, fornecer um servio aos pesquisadores e prevenir atividades maliciosas
ou que possam provocar danos plataforma.
Pesquisadores e desenvolvedores empregam o substrato de rede para realizar
experimentos, implantar servios experimentais, mensurar aspectos da plataforma,
dentre outras aes.
Investigadores principais (PIs - Principal Investigators) representam organiza-
es de pesquisa que assumem a responsabilidade por pesquisadores individuais.
A SFA se prope a mediar as seguintes atividades:
Permitir que proprietrios declarem polticas para alocao e uso de recursos para
infraestruturas sobre seu controle e fornecer mecanismos para fazer cumprir essas
polticas. A suposio que existiro mltiplos proprietrios e uma federao das
infraestruturas que formaro a totalidade da rede de testes.
Permitir que operadores gerenciem o substrato de rede, o que inclui instalao de
novo hardware e remoo de antigo ou com defeito, instalao e atualizao de
software e monitorao da rede em termos de desempenho, funcionalidade e segu-
rana. O gerenciamento provavelmente descentralizado, havendo mais de uma
organizao administrando colees disjuntas de infraestruturas.
Permitir que pesquisadores criem e populem fatias de experimentao, reservem
recursos para elas e executem experimentos nelas.
Permitir que PIs identiquem o conjunto de pesquisadores da sua organizao que
possuem permisso para utilizar uma infraestrutura.
A SFA dene trs entidades principais no contexto da federao:
Autoridade de gerenciamento (MA Management Authority) responsvel por
um subconjunto de componentes do substrato, tendo as seguintes atribuies: for-
necer estabilidade operacional para os componentes, garantir que os componentes
se comportem de acordo com as polticas de uso e executar a alocao de recursos
desejada pelo proprietrio do componente.
Autoridade de fatia de experimentao (SA Slice Authority) responsvel
pelo comportamento de um conjunto de fatias de experimentao, autenticando os
pesquisadores que realizam experimentos em cada fatia e tomando as devidas aes
se houver falha ou uso indevido da fatia de experimentao.
Usurio uma pessoa executando um ou mais papis em uma infraestrutura.
Exemplos: um pesquisador que deseja executar um experimento, um operador que
gerencia alguma parte do substrato, um PI de uma instituio que conduz uma pes-
quisa na infraestrutura ou um proprietrio que oferece recursos para uma infraes-
trutura.
Nas subsees a seguir, apresentamos uma sntese das abstraes, do esquema
de nomes e identicadores usados na SFA. Apresentaremos tambm os tipos de dados e
interfaces denidas pela SFA. Por m, vamos mostrar as origens e o uxo de conana
atravs de um sistema baseado em SFA. Detalhes sobre todos esses tpicos podem ser
encontrados na especicao da SFA 1.04 [Peterson et al. 2009c].
3.6.2.1. Abstraes
Duas abstraes so fundamentais: componentes e fatias de experimentao (slices).
Componentes so blocos de construo bsicos da arquitetura. So exemplos de
componentes: computador, roteador customizvel e ponto de acesso programvel. Um
componente encapsula uma coleo de recursos que podem ser fsicos (como CPU, me-
mria e disco), lgicos (como descritores de arquivos e nmeros de portas) e sintticos
(como caminhos para encaminhamento de pacotes). Os recursos podem estar contidos em
um nico dispositivo fsico ou distribudo por um conjunto deles, dependendo da natureza
do componente. No entanto, um recurso pertence a apenas um componente.
Cada componente controlado atravs de um gerenciador de componentes (CM
Component Manager) que exporta uma interface bem denida acessvel remotamente. O
gerenciador de componentes dene as operaes disponveis para gerenciar a alocao de
recursos para diferentes usurios e seus experimentos. Uma autoridade de gerenciamento
(MA) estabelece as polticas sobre como os recursos so atribudos aos usurios.
Deve ser possvel multiplexar (ou fatiar) recursos de componentes entre mlti-
plos usurios. O fatiamento pode ser realizado atravs de virtualizao do componente
ou do particionamento do componente em conjuntos de recursos distintos. Em ambas as
abordagens, o recurso oferecido ao usurio chamado de poro (sliver) do componente.
Cada componente deve incluir mecanismos de hardware ou software que isolem as por-
es umas das outras, de maneira que uma poro possa ser tratada como um container
de recursos.
Algumas vezes conveniente representar uma coleo de componentes como um
nico agregado. Por exemplo, ns e enlaces de uma rede podem ser tratados como um
agregado. Um agregado pode ser acessado atravs de um gerenciador de agregado (AM
Aggregate Manager) que exporta uma interface semelhante a de um componente indi-
vidual.
Fatia de experimentao (slice) denida pelo conjunto de pores (slivers)
espalhadas por um conjunto de componentes e o conjunto associado de usurios que pos-
suem permisso para acesso s referidas pores. Uma fatia de experimentao recebe
um nome e um conjunto (que pode ser vazio) de pores. A partir da perspectiva de um
pesquisador, uma fatia de experimentao uma rede de recursos de computao e co-
municao capaz de executar um experimento ou servio de rede experimental federada.
A partir da perspectiva de um operador, fatia de experimentao constitui a abstrao
primria para ns de contabilidade.
Uma fatia de experimentao tem trs estgios durante a sua existncia, cada um
correspondendo a uma ao (operao) que pode ser realizada na fatia, a saber: 1) Re-
gistrar (Register) a fatia recebe um nome e vinculada a um conjunto de usurios; 2)
Instanciar (Instantiate) a fatia instanciada em um conjunto de componentes e os recur-
sos so atribudos a ela; 3) Ativar (Activate) a fatia ativada (inicializada), realizando o
experimento do usurio.
As fatias so registradas em uma SA apenas uma vez, mas o conjunto de usu-
rios associados pode mudar ao longo do tempo. O registro de uma fatia tem um tempo
de vida limitado e responsabilidade da SA atualizar o registro periodicamente. A ins-
tanciao de um fatia pode ser repetida mltiplas vezes e frequentemente envolve dois
passos. Uma fatia inicialmente instanciada em um conjunto de componentes com re-
cursos atribudos em um regime de melhor-esforo, ou seja, sem garantias. No segundo
passo, a fatia pode receber recursos adicionais, eventualmente, de maneira garantida. Du-
rante a fase de ativao, mltiplos experimentos podem ser executados em uma nica
fatia. Para cada execuo de experimento, os parmetros, o conjunto de componentes e o
conjunto de recursos podem ser alterados. A velocidade de recongurao de uma fatia
de experimentao depende de como as operaes de provisionamento e instanciao so
implementadas.
3.6.2.2. Nomes e Identicadores
A SFA dene um identicador global (GID Global IDentier) para cada objeto que
compe uma federao. Exemplos de objetos: componentes, fatias, servios e as trs
entidades principais (MA, SAe usurio). Os GIDs formama base para umsistema seguro,
no qual uma entidade que possui um GID capaz de conrmar sua legitimidade assim
como vericar a autenticidade de objetos que tambm possuam GIDs.
Um GID um certicado que associa trs informaes:
GID = (PublicKey, UUID, Lifetime)
O objeto identicado pelo GID mantm a chave privada correspondente chave
pblica (PublicKey), formando a base para a autenticao. Cada objeto possui um
identicador universalmente nico (UUID Universally Unique IDentier) [x667 2004]
que imutvel e absoluto. Ou seja, o UUID permanece o mesmo se a chave pblica
mudar e identica o objeto univocamente dentro de uma federao. O tempo de vida
(Lifetime) descreve a validade do GID, o qual precisa ser periodicamente atualizado.
Uma autoridade tambm identicada por seu prprio GID. Logo, possvel vericar um
GID atravs de chaves criptogrcas que levam de volta, possivelmente em uma cadeia,
at uma ou mltiplas razes bem conhecidas.
A SFA dene um registro como o mapeamento de um nome (humanamente) leg-
vel (HRN Human-Readable Name) para um GID, podendo incluir informaes adici-
onais sobre o objeto, tais como: o URI (Uniform Resource Identier) do gerenciador de
objetos, o endereo IP (ou de hardware) da mquina na qual o objeto implementado, o
nome e endereo postal da organizao que hospeda o objeto, dentre outras informaes.
De maneira semelhante a um nome no servio DNS (Domain Name System), um
HRN para um objeto identica a sequncia de autoridades que so responsveis pelo ob-
jeto. A SFA permite que os registros sejam organizados de maneira arbitrria. No entanto,
em uma federao efetivamente operacional recomendado que o espao de nomes siga
uma estrutura hierrquica das autoridades que delegam o direito de criar e nomear compo-
nentes e fatias de experimentao. Essa hierarquia deve assumir uma autoridade de nvel
mais alto que seja convel para todas as entidades, resultando em nomes com o seguinte
formato:
top-level_authority.sub_authority.sub_authority.name
Exemplos de autoridades de nvel mais alto (top-level_authority) seriam
geni, planetlab e fibre. O registro mantm informao sobre uma hierarquia
de MAs junto com o conjunto de componentes pelos quais as MAs so responsveis. Por
exemplo: fibre.br.rnp.go.gyn. Esse registro identicaria um componente no PoP
(Point of Presence) de Gois (situado em Goinia) que faz parte do backbone da RNP.
O registro mantm tambm informao sobre a hierarquia de SAs junto com o
conjunto de fatias de experimentao pelas quais as SAs so responsveis. Por exemplo:
fibre.br.ufg.inf. Esse registro daria nome a uma fatia de experimentao criada
pela SA FIBRE, a qual delegou para o BR que repassou para a UFG o direito de aprovar
fatias para projetos ou grupos de pesquisa nessa instituio (e.g. INF).
Por m, importante observar que um registro pode ser distribudo, tendo um
servidor que implementa uma parte de uma hierarquia e que aponta (atravs de um URI)
para um servidor que implementa uma sub-rvore da hierarquia.
3.6.2.3. Tipos de Dados
A SFA dene quatro tipos principais de dados alm do GID: especicao de recurso (RS-
pec Resource Specication, tambm usado no ProtoGENI), registro (Registry Record),
bilhete (Ticket) e credencial (Credential). A seguir, apresentada a denio abstrata de
cada um desses tipos de dados, sendo que a denio concreta est fora do escopo da
SFA [Peterson et al. 2009c].
Uma RSpec descreve um componente em termos de recursos que ele possui e suas
restries e dependncias na alocao de recursos. A forma exata de uma RSpec no
denida pela especao da SFA, mas os dois campos seguintes devem existir alm das
informaes sobre os recursos dos componentes: (StartTime, Duration). Esses
campos indicam durante quanto tempo se deseja reservar os recursos ou durante quanto
tempo foi autorizado o uso dos recursos.
Um Registro (registry record) guarda informaes sobre objetos em um sistema
(por exemplo, componentes e fatias de experimentao) e sobre entidades (por exemplo,
MAs, SAs e usurios). Os registry records so denidos de acordo com o seguinte for-
mato:
Record = (HRN, GID, Type, Info).
Onde Type pode ser SA, MA, Component, Slice ou User. De acordo com o
valor de Type, Info pode receber diferentes contedos, a saber:
se Type = SA, ento Info = (PI[], Organization)
se Type = MA, ento Info = (Owner[], Operator[], Organization)
se Type = Component, ento Info = (URI, LatLong, IP, DNS)
se Type = Slice, ento Info = (URI, Researcher[], InitScript)
se Type = User, ento Info = (PostalAddr, Phone, Email, AuthTokens[])
Em geral, as informaes disponveis em um registro so relativamente estticas.
Para obter informaes mais detalhadas e dinmicas sobre um objeto necessrio con-
tactar quem o controla ou responde por ele. Por exemplo, para obter mais informaes
sobre um componente, o seu CM deve ser contactado atravs do URI fornecido pelo seu
registry record.
Um componente assina uma RSpec para produzir um Ticket, indicando um com-
promisso pelo componente de vincular os recursos ao portador do bilhete em algum mo-
mento. Esses bilhetes so emitidos por um componente e, posteriormente, resgatados
para a aquisio de recursos no componente. De acordo com a SFA, os bilhetes devem
receber as seguintes informaes: Ticket = (RSpec, GID, SeqNum). O nmero
de sequncia (SeqNum) garante que o bilhete seja nico. Essa informao assinada
pelo componente que emite o bilhete.
Uma Credencial carrega os direitos emitidos para uma entidade emparticular. Por
exemplo, um usurio pode receber uma credencial que o permite instanciar uma fatia de
experimentao em um conjunto de componentes por um determinado perodo de tempo.
Uma credencial descrita pela seguinte tupla:
Credential = (CallerGID, ObjectGID, ObjectHRN, Expires,
Privileges, Delegate)
Onde CallerGID identica a entidade para a qual a credencial foi emitida;
ObjectGID e ObjectHRN identicam o objeto para o qual a credencial se aplica;
Expires informa por quanto tempo a credencial vlida, Privileges identica a
classe de operaes que o detentor da credencial tempermisso para invocar; e Delegate
informa se o detentor da credencial pode delegar a credencial para outra entidade.
Cada privilgio (Privilege) implica no direito de invocar uma certa quantidade
de operaes em uma ou mais interfaces da SFA. A Tabela 3.1 resume a relao entre
privilgios, interfaces e operaes.
Tabela 3.1. Operaes em cada interface de acordo com o privilgio.
Privilgio Interface Operaes
authority Registry todas
refresh Registry Remove, Update
resolve Registry Resolve, List, GetCredential
pi Slice todas
instantiate Slice GetTicket, CreateSlice,
DeleteSlice, UpdateSlice
bind Slice GetTicket, LoanResources
control Slice UpdateSlice, StopSlice,
StartSlice, DeleteSlice
info Slice ListSlices, ListComponents,
GetSliceResources,
GetSliceBySignature
operator Management todas
3.6.2.4. Interfaces
Semelhante aos tipos de dados, as interfaces so denidas apenas em alto nvel pela es-
pecicao da SFA. Devido limitao de espao, apenas listaremos as operaes su-
portadas em cada interface e seus parmetros. Detalhes sobre as operaes podem ser
encontradas em [Peterson et al. 2009c].
Interface Registry Suporta seis operaes: 1) Register(Credential, Record), 2)
Remove(Credential, Record), 3) Update(Credential, Record), 4) Record
= Resolve(Credential, HRN, Type), 5) Record[] = List(Credential, HRN,
Type) e 6) Credential = GetCredential(Credential, HRN, Type).
Interface Slice Suporta 14 operaes que so separadas em 4 grupos de acordo com
sua funo, a saber: instanciao, provisionamento, controle e informao.
Instanciao de Fatia: 1) Ticket = GetTicket(Credential, RSpec),
2) RedeemTicket(Ticket), 3) ReleaseTicket(Ticket) e
4) CreateSlice(Credential, RSpec).
Provisionamento de Fatia: 1) NewTicket = SplitTicket(Ticket, GID, RSpec),
2) LoanResources(Credential, GID, RSpec) e 3) UpdateSlice(Credential,
RSpec).
Controle de Fatia: 1) StartSlice(Credential), 2) StopSlice(Credential),
3) ResetSlice(Credential) e 4) DeleteSlice(Credential).
Informao sobre Fatia: 1) SlicesNames[] = ListSlices(Credential),
2) RSpec = GetResources(Credential) e
3) SliceName = GetSliceBySignature(Credential, Signature).
importante destacar que a interface slice usada para criar e controlar fatias
de experimentao, ou seja, ela dene um plano de controle para as fatias. A partir da
interface slice, possvel obter uma fatia de experimentao devidamente instanciada e
onde termina as atribuies do plano de controle proposto pela SFA. O comportamento
individual das pores, isto , como so acessadas, programadas e usadas, especco de
cada componente.
Interface Management Suporta trs operaes: 1) SetBootState(Credential,
State), 2) State = GetBootState(Credential) e 3) Reboot(Credential).
3.6.2.5. Controle de Acesso e Autorizao
Todos os direitos relacionados a fatias de experimentao originam com SAs que apro-
vam ou se responsabilizam por fatias e usurios associados com elas. Cada SA tem im-
plicitamente o privilgio authority para os registros correspondentes ao conjunto de
usurios e fatias pelas quais responsvel.
Todos os direitos relacionados a recursos de componentes originam com MAs que
denem as polticas de alocao de recursos (para os componentes que eles gerenciam) e
aprovam todos os usurios que operam tais componentes. Cada MA tem implicitamente
o privilgio authority para os registros correspondentes ao conjunto de usurios e
componentes pelos quais responsvel.
Usurios, componentes e autoridades recebem o privilgio refresh para seus
prprios registros. Usurios tambm possuem o privilgio refresh para as fatias de
experimentao a que estejam aliados. Todos os usurios e autoridades recebem o privi-
lgio resolve para todos os registros e o privilgio info para todas as fatias.
Usurios associados com uma SA (i.e. PIs) tm o privilgio pi para todas as fatias
registradas naquela SA, assim como em todas as fatias registradas em qualquer subauto-
ridade que tem aquela SA como raiz. Usurios associados com uma fatia (i.e. pesquisa-
dores) possuem os privilgios de instantiate, bind e control para aquela fatia.
Todos os usurios (pesquisadores) recebem o privilgio info para todas as fatias e para
todos os componentes que hospedam fatias.
Usurios associados comuma MA(i.e. operadores) possuemo privilgio operator
para todos componentes gerenciados por aquela MA. Operadores tambm recebem o pri-
vilgio pi em todos os componentes que eles gerenciam, incluindo todas as pores das
fatias hospedadas nesses componentes.
Cada componente implementa uma poltica de alocao de recursos que determina
quantos recursos so atribudos a cada fatia de experimentao. Um usurio que recebe
os privilgios instantiate ou bind para uma determinada fatia visto como tendo o
direito de solicitar recursos a um componente. No entanto, depende de cada componente
a deciso de hospedar ou no uma fatia e de quanto recurso alocar a ela.
3.6.3. SFA 2.0
A verso 2.0 da SFA [Peterson et al. 2010] (que passou a expandir para Slice-based
Federation Architecture) uma tentativa de unicar implementaes diferentes, por exem-
plo, as apresentadas em [Peterson et al. 2009a, Peterson et al. 2009b] que foram baseadas
em sua verso anterior [Peterson et al. 2009c]. Basicamente, a verso 2.0 consolida as
adequaes que foram identicadas a partir da experincia adquirida com as implementa-
es.
3.6.3.1. Principais Diferenas entre as Verses 1.0 e 2.0
Inicialmente, a verso 2.0, substitui o usurio PI por um novo tipo de usurio mais ge-
ral, chamado ncora de identidade (identity anchor) ou fornecedor de identidade (IdP
Identity Provider). O papel do IdP conduzir a autorizao atravs da declarao de
atributos ou papis para outros usurios. Por exemplo, um IdP poderia declarar que um
determinado usurio um PI de uma instituio de pesquisa.
Como consequncia da substituio do usurio PI, o privilgio pi no mais
denido como padro nas credenciais da verso 2.0.
As denies de AM e de CM foram simplicadas na verso 2.0, deixando claro
que CM apenas um caso especial de um AM que contm um nico componente.
Na verso 2.0, houve uma reestruturao signicativa na parte de registro que
passou a ser tratada de maneira unicada, incluindo o esquema de nomes, credenciais,
controle de acesso, autorizao, tipos de dados e interface. Embora ainda existam in-
formaes sobre registro em outras partes do texto da verso 2.0 da SFA, a maior parte
passou a se concentrar em uma nica seo mais coesa.
A operao ListSlices(Credential) foi modicada para fornecer GIDs
e, opcionalmente, nomes simblicos ou HRNs. Como consequncia, na verso 2.0, houve
alterao na outra operao relacionada a informaes sobre a fatia de experimentao:
RSpec = GetResources(Credential, GID)
Na parte de controle de acesso e autorizao, a verso 2.0 prope que seja pos-
svel utilizar um arcabouo ABAC (Attribute-Based Access Control) ou um subconjunto
adaptado s necessidades da federao.
Por m, a verso 2.0 apresenta algumas consideraes sobre o uso de um sistema
de capacidade (capability system) que umcaso especial de umarcabouo ABAC. Emum
sistema de capacidade, todos os atributos representam diretamente privilgios especcos
para objetos especcos. Essa caracterstica oferece uma simplicao signicativa, uma
vez que uma credencial pode representar diretamente os privilgios que ela habilita. As-
sim, qualquer entidade pode determinar os privilgios inspecionando apenas a credencial,
sem a necessidade de um procedimento para inferncia.
3.7. Estudo de Caso de Implantao do CMF OFELIAemuma Testbed Open-
Flow
Nesta seo, nosso objetivo mostrar um exemplo prtico que possa orientar outros pes-
quisadores que gostariam de instalar testbeds experimentais locais em seus departamen-
tos. Para tanto, demonstraremos o Sistema de Controle OFELIA (OCF), que oferece
servios de experimentao em redes baseadas em OpenFlow.
3.7.1. Requisitos e infraestrutura
Conforme apresentado na Seo 3.5, o Sistema de Controle (CF) do OFELIA subdivi-
dido em trs componentes: Expedient, VT Manager e Optin Manager. Esses componentes
so implantados preferencialmente em um mesmo equipamento, o qual ser denominado
servidor ao longo deste documento. Os equipamentos responsveis pela proviso de re-
cursos de virtualizao para os experimentos so chamados de agentes.
Os componentes do OFELIA so escritos na linguagem Python, utilizando o fra-
mework Django para as interfaces web. Nota-se que o OFELIA possui como dependncia
a verso 2 da linguagem. Adicionalmente, ele utiliza um conjunto de servios que devem
ser instalados previamente.
Tanto para o servidor quanto para os agentes, recomenda-se a utilizao de um
computador de arquitetura x86 ou x86_64 com a distribuio Linux Debian Squeeze.
Utiliza-se o software de virtualizao Xen nos agentes, sendo que no necessrio equi-
pamento com suporte de virtualizao por hardware (HVM).
Neste documento, assume-se que o servidor possui ao menos duas interfaces de
rede, utilizadas respectivamente para trfego out-of-band e de controle. Os agentes devem
possuir pelo menos trs interfaces de rede; as primeiras interfaces sero utilizadas para
trfego out-of-band e de controle, enquanto as demais sero utilizadas para a rede de ex-
perimentao. sugerido que o software de autocongurao da rede (NetworkManager)
seja desativado ou desinstalado.
3.7.2. Instalando e Congurando o OFELIA CF
3.7.2.1. Congurao da Rede Mquina Servidor
Na congurao utilizada, uma interface de rede (eth0) utilizada para trfego out-of-
band, enquanto outra (eth1) utilizada para a rede de controle do OFELIA. Neste docu-
mento, ser utilizada a VLAN 999 para o trfego de controle. A seguir apresentado o
contedo do arquivo/etc/network/interfaces para a congurao descrita:
auto eth0
iface eth0 inet static
address 192.168.254.193
netmask 255.255.255.0
auto eth1.999
address 172.16.1.101
netmask 255.255.255.0
vlan_raw_device eth1
Nota-se que a congurao de VLANs possui como dependncia o pacote vlan
(apt-get install vlan). Aps a congurao, necessrio reiniciar as interfaces
(/etc/init.d/networking restart ).
3.7.2.2. Instalao do Flowvisor - Mquina Servidor
O Flowvisor um controlador utilizado como proxy transparente para outros controla-
dores, multiplexando a infraestrutura de rede OF para vrios experimentos e isolando-os
entre si. Para seu funcionamento, necessrio instalar um ambiente Java. Assumindo que
o repositrio nonfree esteja habilitado no Debian, a instalao pode ser realizada da
seguinte forma:
vim /etc/apt/sources.list (repositrio non-free habilitado)
apt-get update
apt-get install sun-java6-jre sun-java6-jre
apt-get install sun-java6-plugin ant
update-java-alternatives -s java-6-sun
Para compilar o Flowvisor a partir do cdigo-fonte disponibilizado no repositrio
GIT, interessante instalar ferramentas de desenvolvimento adicionais. Abaixo est indi-
cado o procedimento para compilao do Flowvisor:
apt-get install build-essential autoconf automake libtool git
git clone git://gitosis.stanford.edu/flowvisor.git
cd flowvisor
make
adduser flowvisor
make install -prefix=/usr
update-rc.d flowvisor defaults
/etc/init.d/flowvisor start
3.7.2.3. MySQL Mquina Servidor
O OFELIA CF utiliza o banco de dados MySQL para armazenar as informaes dos
usurios, projetos, slices e demais recursos. Aps a instalao do software necessrio
criar um banco de dados para cada componente, conforme descrito a seguir.
apt-get install mysql-server
mysql -p
create user fibre identified by senha;
create database expedient;
create database optin;
create database vt_am;
grant all on expedient.
*
to fibre identified by senha ;
grant all on optin.
*
grant all on vt_am.
*
\q
Por motivos de segurana, recomenda-se concatenar uma string aleatria ao nal
do nome de cada database em um ambiente de produo.
3.7.2.4. OFELIA CF Mquina Servidor
A instalao do OFELIA CF realizada a partir do tarball existente na pgina do
projeto no Codebasin
26
. O contedo do tarball obtido deve ser extrado no diretrio
/opt/ofelia.
Para cada componente do OFELIA CF h um diretrio correspondente. A instala-
o realizada com a execuo do script ofver, localizado no subdiretrio bin de cada
componente. Ressalta-se que o script sensvel ao diretrio corrente, sendo necessrio
estar no diretrio bin para execut-lo corretamente. O procedimento de execuo dos
scripts demonstrado abaixo:
cd /opt/ofelia/expedient/bin
ofver install -f
cd /opt/ofelia/optin_manager/bin
ofver install -f
cd /opt/ofelia/vt_manager/bin
ofver install -f
Dependncias adicionais sero encontradas e instaladas automaticamente durante
o processo de instalao. Para cada componente gerado um certicado SSL com as in-
formaes fornecidas na instalao. Os certicados sero utilizados pelo software Apache
para disponibilizar as interfaces web dos componentes.
Durante a instalao, requisita-se a edio de arquivos de congurao do OFE-
LIACF. Os parmetros a serem editados denem o nome de usurio, senha e e-mail de um
usurio administrador inicial, dados para conexo com o banco de dados, assim como o
IP e porta para a interface do componente. Abaixo encontram-se trechos da congurao
dos componentes Expedient, Optin Manager e VT Manager, considerando a congurao
descrita neste documento.
Por padro, o Expedient utiliza a porta 443, o Optin Manager utiliza a porta 8443,
e o VT Manager utiliza a porta 8445. Todas as interfaces so disponibilizadas somente
por HTTPS.
26
http://codebasin.net/redmine/projects/ocf
Expedient
ROOT_USERNAME = "fibre"
ROOT_PASSWORD = "minha_senha"
ROOT_EMAIL = "meu@email.com"
ISLAND_NAME = "minha_ilha"
ADMINS = [
("Nome do Admin", ROOT_EMAIL),
]
MANAGERS = ADMINS
SITE_DOMAIN deve ser alterado em um ambiente de produo
SITE_DOMAIN = "192.168.254.193"
SITE_IP_ADDR = "192.168.254.193"
DATABASE_USER = "fibre"
DATABASE_PASSWORD = "senha_bd"
DATABASE_HOST = "127.0.0.1"
DATABASE_NAME = "expedient"
VT Manager
General parameters
VTAM_IP = "192.168.254.193"
VTAM_PORT = "8445"
Database parameters
DATABASE_NAME = "vt_am"
Optin Manager
ADMINS = [
("Nome do Admin", ROOT_EMAIL),
]
MANAGERS = ADMINS
SITE_DOMAIN deve ser alterado em um ambiente de produo
SITE_DOMAIN = "192.168.254.193"
SITE_IP_ADDR = "192.168.254.193"
DATABASE_NAME = "optin"
3.7.2.5. Congurao da Rede Mquinas Agentes
Para os agentes, uma interface de rede (eth0) utilizada para trfego out-of-band. Uma
segunda interface (eth1) utilizada para a rede de controle do OFELIA. As demais inter-
faces sero utilizadas para a rede de experimentao. A congurao abaixo representa o
arquivo de congurao /etc/network/interfaces para um agente:
auto eth0
address 192.168.254.148
netmask 255.255.255.0
auto eth1.999
address 172.16.1.103
netmask 255.255.255.0
vlan_raw_device eth1
auto eth2
auto eth3
## [...]
3.7.2.6. Instalao e Congurao do Xen Mquinas Agentes
O OFELIA utiliza o hypervisor Xen como plataforma de virtualizao. No Debian Sque-
eze, a instalao bsica pode ser realizada da seguinte maneira:
# Distribuio x86
apt-get install xen-linux-system-2.6-xen-686 vlan python-libvirt libvirt-dev xen-tools
# Distribuio x86_64
apt-get install xen-linux-system-2.6-xen-amd64 vlan python-libvirt libvirt-dev xen-tools
necessrio reiniciar o computador e selecionar o kernel com Xen habilitado no boot.
Uma vez reiniciado, deve-se congurar o Xen. No arquivo/etc/xen/xend-config,
remover os comentrios das seguintes linhas:
(xend-http-server yes)
(xend-port 8000)
#Adicionar o network-multi-bridge-vlan manualmente
(network-script network-multi-bridge-vlan)
A seguir, as linhas abaixo devem ser inseridas no arquivo /etc/modules, de
forma a carregar explicitamente os respectivos mdulos:
8021q
loop max_loop=64
No arquivo /etc/default/xendomains, deve-se desabilitar o parmetro
XENDOMAINS_RESTORE e comentar o parmetro XENDOMAINS_SAVE:
#XENDOMAINS_SAVE=/var/lib/xen/save
XENDOMAINS_RESTORE=false
Finalmente, deve-se obter os arquivos no repositrio OFELIA da UFSCar ($SITE)
27
e armazen-los conforme descrito a seguir.
wget $SITE/network-bridge-vlan -o \
/etc/xen/scripts/network-bridge-vlan
wget $SITE/network-multi-bridge-vlan -o \
/etc/xen/scripts/network-multi-bridge-vlan
chmod +x /etc/xen/scripts/
*
wget http://www2.comp.ufscar.br/ ricardofg/OFELIA/xend -o /etc/init.d/xend
Como os scripts do Xen no conguram VLANs devidamente, preciso congu-
rar nomes e endereamento de interfaces na funo configure_vlans() do arquivo
/etc/init.d/xend. As conguraes denidas nesse arquivo sobrescrevem as pre-
sentes no arquivo /etc/network/interfaces.
3.7.2.7. Obtendo o OFELIA Mquinas Agentes
A instalao do OFELIA nos agentes realizada a partir do mesmo tarball existente na
pgina do projeto no Codebasin. Descompacta-se o tarball da mesma forma mencionada
anteriormente. Realiza-se, ento, o seguinte procedimento:
mkdir -p /opt/OFELIA/oxa
ln -s /opt/OFELIA /opt/OFELIA/oxa/repository
3.7.2.8. Criao de uma VM Template Mquinas Agentes
Como o template default do OFELIA no est disponvel publicamente no momento,
necessrio criar um template para posterior instanciao. Sugere-se seguir o roteiro
abaixo para gerar um template com ferramentas bsicas de desenvolvimento e de rede.
27
http://www2.comp.ufscar.br/~ricardofg/OFELIA
cd /etc/xen-tools/role.d
wget $SITE
wget $SITE/xen/OFELIA-helper.sh
chmod +x OFELIA
*
xen-create-image -passwd -role=OFELIA -install-method=debootstrap -dist=squeeze -ip=172.16.1.99
-netmask=255.255.255.0 -hostname=fibre-default
mkdir /home/vm-images
mkdir /mnt/xen
mount -o loop /home/xen/domains/algum_hostname/disk.img /mnt/xen
cd /mnt/xen
tar pcfz /home/vm-images/default.tar.gz
*
umount /mnt/xen
cd /home/vm-images/
md5sum default.tar.gz default.hash
Terminada a gerao do template, deve-se editar o arquivo /opt/OFELIA/vt_manager
/src/ python/ agent/ tools/versions/default/install/lib/template
, de modo que o script de instalao obtenha com sucesso os arquivos necessrios. Uma
opo consiste em disponibilizar os arquivos da pasta /home/vm-images em um ser-
vidor web e editar as URLs correspondentes.
3.7.2.9. Instalao do OFELIA - Mquinas Agentes
Novamente, a instalao realizada com a execuo do script ofver. Segue abaixo os
passos para a instalao do agente de virtualizao:
cd /opt/OFELIA/oxa/repository/vt_manager/src/python/agent/tools
./ofver install
O agente congurado automaticamente para iniciar durante o processo de inici-
alizao do sistema. A interface XMLRPC do agente utiliza a porta 9229.
3.7.3. Congurando e administrando o OFELIA CF
Nesta subseo demonstramos como administrar o OFELIA CF, desde a criao de recur-
sos at a autorizao e alocao dos owspaces OF. Todas essas conguraes se fazem
necessrias no Expedient, VT Manager e OptIn para que seja possvel realizar um expe-
rimento.
3.7.3.1. Acessando as interfaces do OFELIA
Durante a instalao do OFELIA so pedidas informaes para a criao de um usu-
rio administrador e senha para as trs interfaces WEB do OFELIA: Expedient, OptIn e
VTManager.
A tela inicial de cada uma das interfaces quando no se tem usurio logado, a
tela de login. Para acesso como administrador, basta preencher os campos username e
password com os denidos na ocasio da instalao do OFELIA. A interface inicial aps
o login chamada DashBoard.
3.7.3.2. Expedient Viso de administrador
O Expedient faz a administrao do FlowVisor, um proxy de controladores para o Open-
Flow. O FlowVisor gerenciado a partir de Flowspaces, que so basicamente tipos de
uxo de rede, que podem ser diferenciados por diversos campos de cabealho de proto-
colo, desde o nvel 2 at o nvel 4. Portanto, chama-se de owspaces quaisquer ltragens
que possa se desejar fazer. Esses owspaces determinaro o trfego que ser redirecio-
nado para o controlador do experimento. Resumindo, FlowSpace o nome que se d ao
uxo denido por uma regra no owvisor.
Com um usurio logado no Expedient estaro disponveis as seguintes opes para
o administrador na aba Dashboard.
Message & Logs: So exibidas as ltimas 3 mensagens de log do sistema, relativas
a aes como uma mquina virtual iniciada como sucesso. A opo Go to Message
Center leva a uma interface que exibe todas as mensagens de logs.
Projects: Aqui so exibidos todos os projetos alocados em uma ilha (termo usado
para designar uma testbed OFELIA). As informaes exibidas so o nome do pro-
jeto, quantos usurios so gerentes do projeto, quantos membros, quais fatias foram
alocadas, e aes que podem ser tomadas no projeto, como excluir o projeto.
Island Aggregate Managers: Mostra os agregados (recursos) atuais do sistema. A
combo box Aggregate Type permite escolher o tipo de agregado a se criar, que pode
ser um de dois tipos, OpenFlow Aggregate ou Virtualization Aggregate. Escolhido
o mesmo, clicar no boto Add Aggregate. Mostraremos mais detalhes sobre como
criar e editar agregados em seguida.
Permission Management: Serve para aceitar ou negar pedidos de permisso dos
usurios em geral.
Em outra rea do sistema (Account) so exibidas informaes de um usurio em
especco do sistema. O administrador pode alterar informaes relativas sua conta
como primeiro nome, ltimo nome, e-mail, senha, aliao, entre outras. Por outro lado, a
aba User administration permite ao administrador monitorar e controlar todos os usurios
presentes no sistema, podendo adicionar ou remover usurios do sistema. Para essa aba
temos duas sees importantes (Current users e Create new user), uma tabela que lista
os usurios cadastrados no Expedient e um formulrio no qual digitamos as informaes
do novo usurio a ser cadastrado. O boto Create user valida os campos presentes no
formulrio.
Em outra rea do sistema (Aggregate) possvel adicionar agregados ao Expedient
para posterior uso. Existemdois tipos, agregados OpenFlowe agregados de Virtualizao.
Para o agregado OpenFlow preciso marcar dados como nome, localizao, disponibili-
dade, e os parmetros para a gerncia desse agregado via OptIn (login, senha do Optin, url
do servidor em formato xmlrpc). Os campos para a criao de agregados de virtualizao
usam campos semelhantes.
Aps a criao de agregados e contas de usurio, o gerenciamento acontece pela
interface web, sendo que cada sistema web (expedient, optin, vtmanager) cuida de seus
respectivos tipos de recursos. Assim sendo, no VT Manager ser possvel adicionar uma
mquina virtual atravs do comando Add Server. Para esses recursos preciso especicar
tipo de distribuio Linux, hypervisor, URL xmlrpc da mquina Agente, parmetros de
rede, como a interface eth1.999 que a subrede de controle congurada com o Xen. Na
parte de Data Bridges faz-se o cadastro das demais interfaces virtuais a serem usadas
na rede de experimentao. Por exemplo, colocar a porta virtual eth2 conectada com o
switch (DATAPATH) permitindo a conexo daquela mquina virtual com um dos switches
OpenFlow da rede. Depois, ainda na dashboard, ser preciso cadastrar uma faixa de IPs
e faixa de MACs a serem usados pelas VMs.
O prximo passo a congurao do Optin. Neste caso ser preciso informar
as conguraes do FlowVisor, como login, senha, a URL xmlrpc de onde foi denida a
instalao do FlowVisor. E depois informar quais usurios podero gerenciar esse recurso
do FlowVisor, o que chamado de Set ClearingHouse.
A parte nal consiste em congurar o Expedient para adicionar os agregados con-
forme comentado acima. E posteriormente solicitar de maneira off-line uma requisio
(owspace request) de isolamento do controle atravs de owspaces, por exemplo, de-
nindo rtulos de VLAN a ser liberada pelo administrador. Uma vez atendido o pedido
de owspace. De volta ao dashboard do Expedient, na parte Projects possvel criar um
projeto, criar uma fatia, e denir o tempo de expirao desta fatia. Uma vez criada a fatia
(Slice na interface), basta o usurio entrar em Details, e clicar na regio Aggregates, de
modo a adicionar agregados sua fatia. Sendo pelo menos 1 agregado OpenFlow (onde
ser congurado o pedido de FlowSpaces) e 1 ou mais agregados de virtualizao.
3.7.4. Executando um experimento no OFELIA CF
Para que um pesquisador interessado possa utilizar a infraestrutura supervisionada pelo
OFELIA, so necessrios alguns passos preparatrios antes de efetivamente realizar expe-
rimentos e testes. Alm da criao de uma conta de usurio (via web), preciso criar uma
fatia em que o experimento ser montado. Nesta fatia so instanciadas as mquinas que
sero necessrias para o experimento. Na fatia ser feita uma requisio de um ou mais
owspaces (ltragens para isolamento dos experimentos). Relembrando que esses ows-
paces determinaro que o trfego de controle ser redirecionado para o controlador do
experimento. Por m, d-se incio ao controlador do experimento, congura-se na inter-
face web do OFELIA o endereo do mesmo (tipicamente em uma VM da prpria fatia) e
realiza-se o experimento, utilizando as mquinas virtuais que foram criadas previamente.
3.7.4.1. Exemplo
Um detalhamento deste procedimento ser realizado de maneira mais ilustrativa com um
exemplo. Neste ser abordada a instanciao de 2 hosts e um teste de ping entre eles,
passando por um switch OpenFlow. Esse switch estar sendo controlado por uma instn-
cia do pyswitch.py (executado com o NOX) em uma terceira VM da fatia. Para isso,
seguiremos os seguintes passos:
Acessar o endereo da interface web, fornecendo os dados: nome, email, senha,
organizao, ilha (do OFELIA) e uma chave pblica (que pode ser gerada com o
comando ssh-keygen -t dsa. Uma vez criada, um e-mail ser enviado con-
rmando a autorizao da criao da conta no email fornecido durante o cadastro.
Uma vez autorizada a conta, loga-se na ilha em que se registrou. Em seguida, ao
navegar pela interface web, a primeira coisa a se fazer instanciar uma fatia para
o experimento. Ao clicar no boto create slice, sero requisitados: nome da fatia,
resumo do experimento e data de expirao do experimento.
Em seguida, criam-se as mquinas virtuais. Escolhe-se o servidor em que se de-
seja criar a VM, e, em seguida, fornece-se nome da VM, quantidade de memria,
imagem base e tipo de virtualizao.
Para preparar as VMs para o experimento, faz-se acesso individual atravs do ssh.
Na interface web possvel visualizar o IP de cada mquina e tambm a senha de
root para quaisquer necessidades de instalao e congurao do sistema. Neste
caso particular, criam-se 3 VMs, todas com 256M de memria, SO debian, de no-
mes Host1, Host2 e Controller. Host1 e Host2 so as mquinas usadas no teste de
ping, e o Controller a VM em que se instanciar o controlador.
Dando sequncia, acessando a opo Book OpenFlow and Planetlab Resources,
congura-se o Flowspace do experimento. Nessa tela, visualiza-se a infra-estrutura
disponvel, e seleciona-se os caminhos que deseja-se ter controle. Neste caso, um
switch OpenFlow e as portas que o conectam a cada um dos servidores envolvi-
dos. Ao avanar para a segunda tela, montam-se as regras para denir o Flowspace,
preenchendo-se campos como MAC origem, MAC destino, porta, etc. Tambm se
seleciona, para cada regra, quais os caminhos que essa regra cobrir, dentre os sele-
cionados previamente para o experimento. Neste caso, no se criou nenhuma regra
especca, considerando que deseja-se todo o trfego no caminho especicado.
Ao ser autorizado pelo administrador, o Flowspace aparecer como Granted Flows-
pace na interface, e ter uma identicao de VLAN. Para que o OFELIA faa cor-
retamente a separao do trfego do experimento, necessrio congurar todas as
interfaces das VMs envolvidas no experimento com essa VLAN. Para tanto, faz-se
ssh nas VMs, e, supondo que a VLAN seja a 15, congura-se da sequinte maneira.
Congurao de cada uma das VMs:
ifconfig eth1 up
ifconfig eth2 up
modprobe 8021q
vconfig add eth1 15
ifconfig eth1 0.0.0.0
ifconfig eth1.15 <endereo IP do experimento> up
Dessa maneira, o trfego do experimento ser todo na VLAN 15, e o OFELIA o
ltrar de acordo. Para este experimento, congura-se as interfaces na mesma subrede,
para que o ping seja bem sucedido entre os hosts. Utilizou-se 192.168.1.1/24 no Host1
e 192.168.1.2/24 no Host2. Faz-se o ping do Host1 ao Host2 e vice-versa e verica-se
que ainda no h conectividade entre ambos. Para que isso acontea, acessa-se via ssh
o Controller, e instancia-se o controlador do experimento, que, neste exemplo, feito
utilizando o NOX para rodar a aplicao pyswitch.py (ambos existentes na instalao
do OpenFlow 1.0), dando o seguinte comando no Controller:
nox_core pyswitch.py ptcp:6633
Para que o Controller seja o controlador do experimento, dene-se na interface
web, no boto Set Slice Controller o endereo e a porta do controlador, como sendo o
endereo do Controller (a que se d o ssh) e a porta 6633 (que a porta em que este foi
instanciado). Ao aplicar esta congurao, tenta-se novamente o ping entre o Host1 e o
Host2, que desta vez ser bem-sucedido.
3.8. Estudo de Caso de Implantao de OMF em uma Testbed Sem Fio
Nesta seo, apresentaremos a instalao, congurao e uso do OMF em uma pequena
testbed sem o. Forneceremos informaes sucientes para que uma implantao simi-
lar possa ser replicada, assim como referncias que auxiliam na resoluo de eventuais
problemas. Alm disso, ilustraremos o uso do OMF atravs de dois exemplos bsicos
que empregam recursos desse arcabouo para congurao do ambiente, execuo do
experimento e coleta de resultados.
3.8.1. Requisitos e infraestrutura
O OMF possui trs componentes crticos: gerenciador de agregado (AM aggregate
manager), controlador de experimentos (EC experiment controller) e controlador de re-
curso (RC resource controller). Enquanto o RCdeve ser implantado emcada dispositivo
que estar disponvel para o experimentador, o AM e o EC fazem parte da infraestrutura
de suporte aos experimentos. De fato, o EC pode ser implantado fora da infraestrutura
de experimentao, por exemplo, no sistema de um experimentador remoto. No entanto,
h questes relacionadas a acesso e segurana nesse tipo de congurao que no sero
abordados nesse curso. Utilizaremos uma congurao mais simples, na qual AM e EC
esto em um nico equipamento.
O OMF possui tambm um recurso para medies, ltragem e coleta de resulta-
dos conhecido como OML, o qual est dividido em trs partes: servidor, cliente e proxy
(opcional). A parte cliente est disponvel atravs de uma biblioteca que fornece uma
API para que aplicaes distribudas sejam desenvolvidas ou modicadas para serem ca-
pazes de armazenar as medies em um servidor OML. Posteriormente, apresentaremos
um exemplo que utiliza uma aplicao instrumentada com OML. Embora o OML seja
considerado um recurso opcional do OMF, ter um servio de medies muito impor-
tante em testbeds e, portanto, vamos descrever tambm a instalao e congurao do
servidor OML. Novamente, optaremos por uma congurao mais simples, na qual o ser-
vidor OML instalado no mesmo equipamento que o AM. Nesta seo, chamaremos de
servidor o equipamento no qual sero instalados AM, EC e servidor OML.
Apesar de o OMF ser escrito na linguagem Ruby, no suciente apenas ter um
interpretador dessa linguagem para execut-lo. O OMF faz uso de um conjunto de servi-
os que precisam estar disponveis e devidamente congurados para sua correta execuo.
Apresentaremos a instalao e congurao mnima dos servios necessrios ao OMF.
Para a instalao do AM, do EC e do servidor OML, recomendamos que seja
usado um computador de arquitetura x86 com sistema operacional Linux instalado. Assu-
mindo que todos os servios relacionados ao OMF tambm sero instalados nesse equipa-
mento, recomendado um computador com processador equivalente a Intel i3 (3 GHz),
com 2 GB de RAM e 50 GB livres de disco. interessante ter duas interfaces de rede
no equipamento, sendo uma para acesso Internet e outra para controle e monitoramento
da infraestrutura de testes. Qualquer distribuio pode ser usada, mas nesse material des-
creveremos os procedimentos especcos para instalao no Ubuntu 11.10 oneiric, pois
esse sistema possui pacotes para todos os servios necessrios, inclusive o prprio OMF
na verso 5.4 (a mais recente durante a elaborao desse material). Utilizamos a docu-
mentao dos desenvolvedores do OMF [OMF 2012d] como base para a implantao que
descrevemos nesta seo.
O controlador de recurso (RC) pode ser instalado em qualquer equipamento que
possua um interpretador Ruby, permitindo que vrios tipos diferentes de equipamentos
possam ser utilizados como ns de experimentao em uma testbed. Nesta seo, vamos
descrever a instalao em um pequeno computador com a seguinte congurao: placa-
me mini-ITX, processador VIA C7 de 1,8 GHz, 1 GB de RAM, HD de 320 GB com
2,5 polegadas (usado em laptops), duas placas de rede Ethernet e duas interfaces sem
o IEEE 802.11 b/g (conectadas atravs de USB). A disponibilidade de duas interfaces
de rede Ethernet til para separar o trfego de dados e de controle. possvel utilizar
ns de experimentao mais simples e de custo mais baixo, como os baseados em SBCs
(Single Board Computers) [OMF 2012b] ou em pontos de acesso [Stasi et al. 2009]. No
entanto, o uso de equipamentos com mais recursos permite a realizao de experimentos
mais sosticados e a explorao de mais recursos disponveis no OMF, como a possi-
bilidade de escolher diferentes sistemas operacionais para serem carregados nos ns de
experimentao. Um recurso opcional, porm muito til em uma testbed para uso remoto,
o controle remoto de energia. H diferentes maneiras de implementar esse recurso, con-
forme descrito em [OMF 2012e, NITLab 2012].
3.8.2. Congurao da Rede
No servidor, sugerimos a desativao ou remoo de software para autocongurao da
rede como NetworkManager e Avahi. Na distribuio Linux sugerida (Ubuntu 11.10), o
NetworkManager instalado por padro e pode ser removido com o seguinte comando:
apt-get remove network-manager
Na congurao que utilizamos, uma das interfaces de rede (eth0) foi conectada
Internet, enquanto a outra foi usada para controlar e monitorar os ns de teste. A seguir,
apresentamos o contedo do arquivo /etc/network/interfaces para congura-
o da interface eth0 de maneira semelhante a de uma estao convencional (que obtm
seu endereo IP atravs de DHCP) e da interface eth1 para gerncia do ambiente de
testes (e, portanto, com endereo IP xo):
auto eth0
iface eth0 inet dhcp
auto eth1
address 10.0.0.200
netmask 255.255.255.0
Aps a congurao, importante reiniciar as interfaces (ifdown ethX; ifup
ethX) e vericar se elas esto com os endereos IP corretos (ifconfig ethX) e se h
conectividade (ping ou outra ferramenta).
Nesta seo, usaremos a rede 10.0.0.0/8 para o ambiente de testes, no entanto,
importante vericar se essa faixa de endereos no a utilizada na rede de produo
(onde a interface eth0 foi conectada).
Por m, importante vericar se os servios de shell remoto seguro (SSH) e
sincronizao de tempo (NTP) esto instalados. No Ubuntu 11.10, no necessria con-
gurao adicional aps a instalao bsica que pode ser realizada da seguinte maneira:
apt-get install ssh ntp
3.8.3. Servios
Apresentamos a seguir, os principais servios utilizados pelo OMF e uma breve descrio
do uso desses servios no contexto da infraestrutura de experimentao.
Congurao automtica de endereos IP utilizada para congurar a interface
de controle dos ns de teste. Usaremos o software dnsmasq para implementar
esse servio.
Traduo de nomes permite que nomes, ao invs de endereos IP, sejam usados
para identicar os servidores (AM e OML) e os prprios ns de experimentao.
Usaremos o software dnsmasq para implementar esse servio.
Inicializao remota auxilia na customizao completa de um n, permitindo que
at o sistema operacional seja substitudo na inicializao do equipamento. Usa-
remos o software dnsmasq em conjunto com Syslinux para implementar esse
servio.
Middleware orientado a mensagens constitui o ncleo do OMF, provendo a co-
municao entre AM, EC, RC e OML para fornecer as funcionalidade de controle
e monitoramento dos experimentos. Usaremos o software Openfire para imple-
mentar esse servio.
Base de dados armazena o inventrio dos ns, usurios, resultados coletados e
demais informaes para operao e uso do testbed. Usaremos o software MySQL
para implementar esse servio. O servidor OML utiliza o SQLite, porm no
necessria nenhuma congurao adicional aps a instalao bsica.
As subsees a seguir, apresentam detalhes sobre a instalao e congura do
software utilizado pelo OMF, assim como de seus componentes: AM, EC e OML. Con-
forme comentamos anteriormente, o RC pode ser instalado em um sistema operacional
com um interpretador Ruby para transformar o equipamento em um n de experiment-
o. Neste material, apresentamos o uso de uma imagem do sistema operacional Linux
com o RC previamente instalado, o qual pode ser implantado em um n usando a pr-
pria infraestrutura do OMF. Detalhes sobre a instalao do RC podem ser encontrados
em [OMF 2012d].
3.8.3.1. Software dnsmasq e Syslinux
Alm do dnsmasq, recomendamos a instalao do software Syslinux no mesmo
passo, pois o servio de inicializao (ou boot) remota para um sistema Linux depende de
ambos. No Ubuntu 11.10, a instalao pode ser realizada da seguinte forma:
apt-get install syslinux dnsmasq
A primeira parte da congurao realizada no arquivo /etc/dnsmasq.conf,
o qual deve ter as seguintes linhas adicionadas ao nal:
interface=eth1
dhcp-range=10.0.0.201,10.0.0.254,255.255.255.0,12h
dhcp-option=3
dhcp-option=option:ntp-server,10.0.0.200
dhcp-boot=net:control,pxelinux.0
enable-tftp
tftp-root=/tftpboot
Basicamente, o arquivo acima dene a seguinte congurao: 1) interface na qual
o servio estar disponvel (eth1); 2) no h roteador padro para os ns; 3) faixa de
endereos IP usados de maneira dinmica (10.0.0.201-10.0.0.254); 4) servidor
para sincronizao de tempo (10.0.0.200); 5) nome do arquivo (pxelinux.0) para
inicializao remota, mas apenas se o rtulo control estiver congurado; 6) ativao
do suporte a transferncia de arquivo de inicializao atravs de TFTP (Trivial FTP); 7)
diretrio raiz para o TFTP. Nessa congurao, os endereos IP de 10.0.0.1 a 10.0.0.199
esto disponveis para congurao automtica das interfaces de controle dos ns.
A congurao automtica das interfaces de controle utiliza o endereo MAC de
cada uma para associar sempre o mesmo IP e nome a cada n, facilitando a identi-
cao dos equipamentos. A seguir apresentado o contedo de um arquivo exemplo
(/etc/dnsmasq.d/mytestbed.conf) para trs ns hipotticos:
dhcp-host=net:control,00:01:02:03:04:05,node1,10.0.0.1
dhcp-host=net:control,00:06:07:08:09:10,node2,10.0.0.2
dhcp-host=net:control,00:AA:BB:CC:DD:EE,node3,10.0.0.3
Aps a criao e preenchimento adequado do arquivo, necessrio reiniciar o
software dnsmasq:
/etc/init.d/dnsmasq restart
Por padro, o software dnsmasq utiliza o arquivo /etc/hosts como a base
de dados de nomes do domnio. Portanto, importante adicionar entradas para os ns e
servidores que estaro em operao na testbed.
O restante desta seo diz respeito ao software Syslinux, o qual permite inici-
alizar um sistema operacional Linux atravs da rede. De fato, o Syslinux um carre-
gador de inicializao (boot loader) capaz de lidar com diferentes fontes de inicializao,
como um sistema de arquivos FAT, um disco de CD-ROM e a rede. A inicializao pela
rede utiliza a especicao da Intel chamada Preboot Execution Environment ou PXE.
Inicialmente, necessrio criar os diretrios que contero os arquivos de congu-
rao e inicializao usados para o boot remoto PXE, por exemplo:
mkdir -p /tftpboot/pxelinux.cfg
Em seguida, necessrio copiar (ou referenciar) o carregador de inicializao:
ln -s /usr/lib/syslinux/pxelinux.0 /tftpboot/
O diretrio /tftpboot precisa receber dois arquivos: o ncleo (kernel) do Li-
nux e o seu respectivo disco de RAM inicial (initial RAM disk ou initrd) para monta-
gemdo sistema de arquivo raiz. Os desenvolvedores do OMF oferecemambos os arquivos
para inicializao de ns x86 convencionais no site do projeto [OMF 2012f].
Agora, necessrio criar o arquivo /tftpboot/pxelinux.cfg/pxeconfig
com o seguinte contedo:
SERIAL 0 19200 0
DEFAULT linux
LABEL linux
KERNEL linux-omf-pxe-3.0.4
APPEND console=tty0 console=ttyS0,19200n8 vga=normal quiet
root=/dev/ram0 rw load_ramdisk=1 prompt_ramdisk=1
ramdisk_size=32768 initrd=initramfs-omf-pxe-5.4.bz2
control=eth0 xmpp=srv.fibre.ufg.br slice=pxe_slice
hrn=omf.fibre.%hostname%
PROMPT 0
importante ter cuidado para que em cada linha no haja quebras, inclusive na
que se inicia com APPEND e que possui um grande nmero de parmetros. Os arquivos
indicados em KERNEL e initrd devem ser os que foram obtidos anteriormente.
Seguem algumas consideraes adicionais sobre a linha dos parmetros a serem
passados para o ncleo (linha iniciada por APPEND). O parmetro control deve ser
congurado para a interface Ethernet escolhida para controle, sendo necessariamente a
eth0 se houver apenas uma placa de rede (Ethernet). Na congurao que estamos
apresentando, o parmetro xmpp deve referenciar o nome do servidor onde o AM est
instalado (por exemplo, srv.fibre.ufg.br). Como o dnsmasq est sendo usado, a
traduo desse nome deve estar no arquivo /etc/hosts. O importante com relao ao
parmetro hrn (human readable name) a uniformidade ao longo de toda a congurao.
Em nossa congurao, os nomes HRN denidos para os ns so omf.fibre.node1,
omf.fibre.node2 e omf.fibre.node3. Por essa razo, o parmetro hrn recebeu
o valor omf.fibre.%hostname%.
Um arquivo (/tftpboot/pxelinux.cfg/default) deve ser criado para
indicar a congurao padro para inicializao, tendo o seguinte contedo:
DEFAULT harddrive
LABEL harddrive
localboot 0
Dentro do diretrio /tftpboot/pxelinux.cfg/, deve ser criado um link
simblico para cada n com base no endereo MAC de sua interface de controle. O nome
do link simblico deve ser igual ao endereo MAC precedido de 01 com cada octeto
separado por hfen. Por exemplo, para os ns apresentados previamente, teramos os
seguintes links simblicos:
ln -s pxeconfig 01-00-01-02-03-04-05; ln -s pxeconfig 01-00-06-07-08-09-10; ln -s pxeconfig 01-00-AA-BB-CC-DD-EE
Nesse ponto, possvel inicializar os ns de testes a partir do servidor. impor-
tante congurar cada n para inicializao remota atravs da rede, deixando o boot pelo
disco rgido local como segunda opo. Se no houver erros, os ns recebero os endere-
os IP congurados anteriormente e estaro acessveis atravs de shell remoto (telnet).
O sistema inicializado atravs da rede reduzido, possuindo apenas a conta de superu-
surio (root), algumas ferramentas bsicas e o RC, o qual permite que uma imagem
completa de um SO seja trazida e aplicada ao disco rgido do n. Durante a inicializao
remota, as mensagens de interao entre um n e o servidor so reportadas no arquivo
/var/log/syslog (no servidor), podendo ser til analis-lo em caso de erros.
Caso a inicializao remota dos ns seja bem sucedida, os links simblicos para
o arquivo pxeconfig devem ser removidos. A princpio, esse procedimento faz os ns
inicializarem por seus discos rgidos locais. No entanto, aps a sua instalao completa,
o OMF criar e remover links simblicos para os ns sob a orientao (implcita) do
experimentador, permitindo alterar o dispositivo de boot (rede ou disco rgido).
3.8.3.2. Software Openre
O software Openre uma implementao de um servidor XMPP (eXtensible Messaging
and Presence Protocol). XMPP um protocolo aberto baseado em XML (eXtensible
Markup Language) para middleware orientado a mensagens. Conforme comentamos an-
teriormente, o OMF faz uso intensivo desse protocolo e, portanto, AM, EC e RC precisam
ter acesso ao servidor XMPP. Novamente, utilizamos a abordagem mais simples e apre-
sentaremos a implantao do Openre no mesmo servidor do AM e do EC.
Os desenvolvedores do OMF recomendam que para sua verso 5.4 sejam insta-
lados o Openfire 3.7.1 e o SUN Java 6. Os passos a seguir ilustram como esse
procedimento pode ser realizado no Ubuntu 11.10:
apt-get install python-software-properties; add-apt-repository ppa:ferramroberto/java; apt-get update; apt-get
install sun-java6-jre; wget http://www.igniterealtime.org/downloadServlet?filename=openfire/openfire_3.7.1_all.deb
-O openfire_3.7.1_all.deb; dpkg -i openfire_3.7.1_all.deb
Caso exista alguma ltragem de pacotes no servidor (por uma rewall), as seguin-
tes portas TCP devem ser abertas: 5222, 5269 e 9090. A instalao do Openre j deve
inici-lo, porm pode levar algum tempo. Logo, verique se o processo (.../bin/java
-server -Dopenfire...) est executando antes de tentar congur-lo.
A congurao do Openre feita atravs de uma interface Web que pode ser
acessada atravs da porta 9090 do servidor. A primeira vez que o servidor acessado, o
usurio conduzido por um auxiliar de congurao e deve fornecer as informaes que
seguem: 1) Idioma. 2) Conguraes do servidor. No h necessidade de alterar as portas
e usamos o nome do servidor (srv.fibre.ufg.br) como o valor para Domnio. 3)
Conguraes do banco de dados. Recomendamos o uso da opo Banco de dados
interno. 4) Conguraes de perl. A opo Padro suciente. 5) Senha do
administrador. Aps esse passo, o Openfire est congurado para uso pelo OMF.
3.8.3.3. Instalao e Congurao do AM e do servidor OML
Como os desenvolvedores do OMF fornecem os pacotes para o Ubuntu 11.10 oneiric,
podemos incluir o site de pacotes do projeto OMF na lista de repositrios do nosso servi-
dor (/etc/apt/sources.list):
deb http://pkg.mytestbed.net/ubuntu oneiric/
Agora, podemos atualizar a lista de repositrios e instalar o AMe o servidor OML:
apt-get update; apt-get install omf-aggmgr-5.4 oml2-server
A seguir so apresentados os passos para a primeira parte da congurao do AM.
1. Copiar /usr/share/doc/omf-aggmgr-5.4/examples/omf-aggmgr.yaml
para /etc/omf-aggmgr-5.4/
2. Alterar o arquivo /etc/omf-aggmgr-5.4/omf-aggmgr.yaml para indicar o
nome correto do servidor XMPP (srv.fibre.ufg.br).
3. Ativar os servios do OMF atravs da criao dos seguintes links simblicos:
cd /etc/omf-aggmgr-5.4/enabled; ln -s ../available/cmcStub.yaml; ln -s ../available/frisbee.yaml; ln
-s ../available/pxe.yaml; ln -s ../available/inventory.yaml; ln -s ../available/result.yaml; ln -s
../available/saveimage.yaml
4. Por m, dentro do diretrio /etc/omf-aggmgr-5.4/available/, pre-
ciso editar os arquivos saveimage.yaml e frisbee.yaml para alterar as in-
terfaces para salvar imagens de sistemas operacionais (saveimage) e multicast,
respectivamente. Em nossa congurao, ambas devem receber o endereo IP da
interface de controle do AM, ou seja, 10.0.0.200.
A segunda parte da congurao do AM diz respeito ao inventrio da infraestru-
tura de experimentao. Inicialmente, instalamos o servidor MySQL e a ferramenta de
gerncia com interface Web chamada phpmyadmin:
apt-get install mysql-server libdb4.6 phpmyadmin
Durante a instalao do servidor MySQL pedida uma senha para o administrador
do banco de dados. Durante a instalao do phpmyadmin questionado qual deve ser o
servidor Web utilizado, para o qual indicamos o apache2. Ainda durante a instalao do
phpmyadmin, necessrio decidir se a congurao do banco de dados ser feita com
o auxlio da ferramenta dbconfig-common ou no. A resposta deve ser negativa, pois
faremos a congurao manualmente.
Com a instalao e congurao bsica pronta, podemos conectar ao servidor
MySQL (mysql -u root -p) e criar uma conta para o OMF da seguinte forma:
use mysql;
create user omf@localhost;
grant all on
*
.
*
to omf@localhost;
set password for omf@localhost=password(omf);
quit;
Finalmente, podemos efetuar uma conexo ao servidor MySQL com o usurio
OMF (mysql -u omf -pomf) e criar a base de dados do inventrio:
create database inventory;
quit;
O pacote do AM traz um arquivo SQL de exemplo de inventrio que contm todas
as tabelas e algumas entradas como amostras. Esse arquivo de exemplo pode ser impor-
tado da seguinte maneira:
cd /usr/share/doc/omf-aggmgr-5.4/examples; zcat inventory.sql.gz | mysql -u omf -pomf inventory
Atravs da interface Web fornecida pelo phpmyadmin possvel acessar a base
de dados do inventrio e realizar as alteraes necessrias de acordo com as caractersticas
da testbed. A tabela testbeds deve ser alterada para reetir o nome da testbed que est
sendo gerenciada, por exemplo fibre_ufg. Para cada n, as seguintes tabelas tambm
devem ser editadas e modicadas de acordo: locations, motherboards, nodes
e pxeimages. Em geral, as tabelas da base de dado so autoexplicativas e uma breve
descrio (um pouco desatualizada) da estrutura pode ser encontrada em [OMF 2012a].
A congurao do inventrio concluda com a vericao do arquivo
/etc/omf-aggmgr-5.4/available/inventory.yaml para conrmar se as in-
formaes esto de acordo com a congurao do servidor MySQL.
A parte nal da congurao do AM est relacionada criao de tpicos de
Publicao-Inscrio (Publique-Assine ou PubSub) no servidor XMPP para a comunica-
o entre as entidades do OMF (AM, OML, EC e RC). Em geral, o termo n mais usado
que o termo tpico no contexto XMPP, como pode ser visto em [Millard et al. 2012]. No
entanto, nesta seo, vamos preferir o termo tpico para evitar confuso com o uso prvio
de n cujo o sinnimo equipamento ou dispositivo.
Para criar a rvore de tpicos PubSub, no nosso ambiente, executamos o comando:
omf_create_psnode-5.4 srv.fibre.ufg.br mksys
Para carregar imagens de sistemas operacionais nos ns, necessrio criar uma
fatia de experimentao (slice) com o nome pxe_slice e todos os ns devem ser acres-
centados a ela. Em nossa congurao, o seguinte comando realiza essa tarefa:
omf_create_psnode-5.4 srv.fibre.ufg.br mkslice pxe_slice omf.fibre.node1 omf.fibre.node2 omf.fibre.node3
Caso um novo n seja acrescentado testbed, necessrio repetir o ltimo passo
com todos os ns. Esse procedimento no gera duplicatas.
Experimentos tambm so executados dentro de uma fatia e, portanto, os ns es-
colhidos para realizar um experimento devem ser previamente adicionados fatia de ex-
perimentao. O comando a seguir ilustra a criao de uma fatia (slice) com os nossos
ns:
omf_create_psnode-5.4 srv.fibre.ufg.br mkslice default_slice omf.fibre.node1 omf.fibre.node2 omf.fibre.node3
Esse ltimo passo deve ser realizado para se acrescentar novos ns fatia de ex-
perimentao. A congurao do AM est concluda, sendo suciente reiniciar o servio:
/etc/init.d/omf-aggmgr-5.4 restart
3.8.3.4. Instalao e Congurao do EC
O EC precisa ter acesso ao servidor XMPP e, para a maior parte dos testes, tambm aos
ns de teste. Em nossa congurao, o EC se encontra no mesmo servidor que o AM e
servidor OMF. Logo, o site de pacotes dos desenvolvedores do OMF j foi adicionado
lista de repositrios. Assim, a instalao do EC se resume ao seguinte comando:
apt-get install omf-expctl-5.4
Novamente, um arquivo de congurao fornecido juntamente com o pacote do
software e deve ser usado como base:
cd /usr/share/doc/omf-expctl-5.4/examples/; zcat omf-expctl.yaml.gz > /etc/omf-expctl-5.4/omf-expctl.yaml
O arquivo /etc/omf-expctl-5.4/omf-expctl.yaml possui mltiplas
sees de congurao, mas apenas a :default: precisa ser alterada. Para a nossa
congurao, seguem os parmetros modicados e seus respectivos valores:
:domain: fibre_ufg
:omluri: tcp:srv.fibre.ufg.br:3003
:web:
:host: 10.0.0.200
:communicator:
:xmpp:
:pubsub_gateway: srv.fibre.ufg.br
:services:
:uri: http://srv.fibre.ufg.br:5054
Conclumos ento a instalao e congurao do EC. Seguem alguns passos nais
para concluir a congurao do OMF e vericar o funcionamento da testbed.
Os desenvolvedores do OMF oferecemuma imagemdo sistema operacional Linux
com o RC j instalado. Sugerimos obter essa imagem e armazen-la conforme descrito:
cd /var/lib/omf-images-5.4; wget http://pkg.mytestbed.net/files/5.4/baseline/baseline.ndz
A imagem padro (baseline.ndz) pode ser carregada em todos os ns com o
seguinte comando:
omf load
Se os ns foram inicializados pelo arquivo padro (/tftpboot/pxelinux.cfg
/default), provavelmente eles no possuem o RC e, portanto, necessrio reinici-los
manualmente nesse primeiro uso. Aps o boot, o OMF providencia a criao dinmica
dos links simblicos e consequentemente da carga de um pequeno sistema operacional
com o RC que providencia a aquisio da imagem do sistema operacional e sua escrita
no disco rgido. Esse procedimento destri qualquer sistema de arquivos que esteja pre-
viamente no n. Aps a concluso o n reinicializado e os links simblicos removidos,
fazendo com que o boot PXE indique o disco rgido local de cada equipamento para ini-
cializao. Cada n inicializada com a imagem que foi previamente gravada.
Os ns esto prontos para testes. Recomendamos a leitura dos tutoriais sobre
controle dos recursos da testbed com OMF [OMF 2012g], nos quais so apresentadas
informaes sobre como salvar imagens de SOs, vericar o estado dos ns, ligar/desligar
ns, etc.
3.8.4. Testes
O OMF dene e utiliza uma linguagem de domnio especco para descrever um experi-
mento. Essa linguagem chamada OEDL (OMF Experiment Description Language) e
baseada na linguagem Ruby. Ou seja, a OEDL estende a linguagem Ruby com comandos
para oferecer funcionalidades para manipulao de topologia, agrupamento de recursos,
denio aplicaes, execuo de tarefas, dentre outras. Mais detalhes sobre a linguagem
OEDL e seus comandos podem ser encontrados em [OMF 2012c].
Aps escrever a descrio de um experimento em OEDL, possvel execut-lo
com um comando semelhante ao descritor a seguir:
omf exec exemplo.rb
A seguir so apresentados dois exemplos de experimentos descritos em OEDL que
podem ser executados em uma testbed controlada pelo OMF.
3.8.4.1. Exemplo 1
O Cdigo fonte 3.1 apresenta um exemplo muito simples que mostra como executar um
comando remotamente em dois ns da testbed.
3.8.4.2. Exemplo 2
O Cdigo fonte 3.2 ilustra o uso de uma verso modicada do Iperf que capaz de arma-
zenar seus resultados no servidor OML.
Aps a concluso do experimento, por padro, gerado um arquivo com extenso
.sq3 dentro do /tmp. Nesse arquivo, encontram-se os dados do experimento organiza-
dos em tabelas do banco de dados.
Cdigo fonte 3.1. Exemplo 1
# Def i ne o grupo de r e c u r s o s t e s t e
def Gr oup ( t e s t e , omf . f i b r e . node2 , omf . f i b r e . node2 )
#Quando t odos os nos e s t i v e r e m pr ont os , e x e c ut e / bi n / l s l a
onEvent ( : ALL_UP_AND_INSTALLED) do | e ve nt |
# I mpri me al guma i nf or macao na t e l a
put s " Execut ando o comando / bi n / l s l a em t odos os nos . . . "
gr oup ( " t e s t e " ) . exec ( " / bi n / l s l a " )
#Aguarda 10 s egundos
wa i t 10
# Encerra o e x pe r i me nt o
Exper i ment . done
end
Cdigo fonte 3.2. Exemplo 2
# Def i ne o grupo de r e c u r s o s s e r v i d o r
def Gr oup ( s e r v i d o r , " omf . f i b r e . node1 " ) do | node |
node . ne t . e1 . i p = " 1 9 2 . 1 6 8 . 0 . 1 "
# Adi ci ona a apl i c ac ao pred e f i n i d a I p e r f
node . a ddAppl i c a t i on ( " t e s t : app : i p e r f " ) { | app |
# Conf i gur a pr opr i e dade s da apl i c ac ao l ado s e r v i d o r
app . s e t P r o p e r t y ( s e r v e r , t rue )
app . s e t P r o p e r t y ( p o r t , 5000)
}
end
# Def i ne o grupo de r e c u r s o s c l i e n t e
def Gr oup ( c l i e n t e , " omf . f i b r e . node2 " ) do | node |
node . ne t . e1 . i p = " 1 9 2 . 1 6 8 . 0 . 2 "
node . a ddAppl i c a t i on ( " t e s t : app : i p e r f " ) do | app |
# Conf i gur a pr opr i e dade s da apl i c ac ao l ado c l i e n t e
app . s e t P r o p e r t y ( c l i e n t , 1 9 2 . 1 6 8 . 0 . 1 )
app . s e t P r o p e r t y ( p o r t , 5000)
app . s e t P r o p e r t y ( t i me , 30)
app . s e t P r o p e r t y ( i n t e r v a l , 1)
# Ut i l i z a um pont o de c o l e t a pred e f i n i d o na apl i c ac ao
app . measur e ( TCP_Info , : s ampl es => 1)
end
end
onEvent ( : ALL_UP_AND_INSTALLED) do | e ve nt |
wa i t 5
gr oup ( " s e r v i d o r " ) . s t a r t Ap p l i c a t i o n s
wa i t 5
gr oup ( " c l i e n t e " ) . s t a r t Ap p l i c a t i o n s
wa i t 40
Exper i ment . done
end
3.9. Concluses
O presente minicurso introduz o estado da arte em arcabouos de controle e monitora-
mento para ambientes de experimentao em redes e sistemas distribudos. No material
cobrimos desde os requisitos bsicos, passando por diversos exemplos de testbeds e seus
CMFs, discutimos federao e apresentamos dois casos de uso baseados nos CMFs: OFE-
LIA e OMF. A pesquisa em CMFs ainda est na sua infncia, com o exemplo apontamos
o desenvolvimento em espiral do GENI que ainda est evoluindo, e portanto difcil
prever com preciso quais as tendncias futuras. Entretanto podemos, ainda assim, re-
alizar uma tentativa de identicar as reas mais promissoras em CMFs, como a criao
de novas tcnicas de virtualizao que permitiriam recursos como enlaces sem o serem
compartilhados, que permitam recursos de mquinas virtuais serem mais escalveis e e-
xveis com potencial interao com computao em nuvem (IaaS). Dentro do aspecto de
controle importante o desenvolvimento de uma alocao de recursos mais dinmica e
gil, e que a reproducibilidade de experimentos seja padro nas testbeds. Com relao a
monitoramento, que seja possvel ao usurio ter todo tipo de caracterstica pertinente ao
seu experimento para posterior anlise. Finalmente, preciso implantar mais e maiores
testbeds como a do projeto FIBRE (projeto em conjunto Brasil e Europa) focado em tec-
nologia OpenFlow e com ilhas heterognea com caractersticas especcas, algumas com
enlaces sem o, outras focadas em redes mveis (como as redes DTN baseadas em pes-
soas). Todo esse esforo pode gerar novos requisitos para testbeds e CMFs no futuro, e at
pode precisar atender outros tipos de pesquisadores, interessados em interaes humanas
em larga escala e na sua inuncia na disseminao de dados na rede.
Agradecimentos
Os autores gostariam de agradecer s equipes FIBRE-BR da UFSCar, UFPA, UNIFACS,
UFG, USP e demais membros do FIBRE-BR. Tambm agradecemos a Marcial Fernandez
(UECE), Jorge Barros (CPqD), Mateus Cerezini (UFES). Este minicurso foi parcialmente
suportado com recursos do projeto Projeto FIBRE/CNPq No. 590022/2011-3, FAPESPA
e FAPEG Proc. No. 200910267000343.
Referncias
[gen 2012] (2012). GENI projects: Software integration.
http://groups.geni.net/geni/wiki/SpiralThree#SoftwareIntegration.
[Pri 2012] (2012). Primeproject - public - modeling and networking systems research
group. https://www.primessf.net/bin/view/Public/PRIMEProject.
[Andersson and Madsen 2005] Andersson, L. and Madsen, T. (2005). Provider Provisio-
ned Virtual Private Network (VPN) Terminology. RFC 4026 (Informational).
[Bourgeau et al. 2010] Bourgeau, T., Aug, J., and Friedman, T. (2010). TopHat: sup-
porting experiments through measurement infrastructure federation. In Proceedings of
TridentCom2010, Berlin, Germany.
[Csabai et al. 2010] Csabai, I., Fekete, A., Hga, P., Hullr, B., Kurucz, G., Laki, S.,
Mtray, P., Stger, J., Vattay, G., Espina, F., Garcia-Jimenez, S., Izal, M., Magana,
E., Morat, D., Aracil, J., Gmez, F., Gonzalez, I., Lpez-Buedo, S., Moreno, V., and
Ramos, J. (2010). ETOMIC advanced network monitoring system for future internet
experimentation. In Proceedings of TridentCom2010, Berlin, Germany.
[Duerig et al. 2012] Duerig, J., Ricci, R., Stoller, L., Strum, M., Wong, G., Carpenter,
C., Fei, Z., Grifoen, J., Nasir, H., Reed, J., and Wu, X. (2012). Getting started with
GENI: a user tutorial. SIGCOMM Comput. Commun. Rev., 42(1):7277.
[Dwertmann et al. 2009] Dwertmann, C., Ergin, M. A., Jourjon, G., Ott, M., Rakotoari-
velo, T., Seskar, I., and Gruteser, M. (2009). DEMO: Mobile Experiments Made Easy
with OMF/Orbit. In Proceedings of the ACM SIGCOMM 2009 (Demo Session).
[Faber and Wroclawski 2008] Faber, T. and Wroclawski, J. (2008). Access control for
federation of emulab-based network testbeds. In Proceedings of the conference on
Cyber security experimentation and test, pages 6:16:6. USENIX Association.
[GENI 2009] GENI (2009). GENI control framework requirements. Technical report,
GENI. Document ID: GENI-SE-CF-RQ-01.3.
[GENI 2010] GENI (2010). GENI instrumentation and measurement architecture. Tech-
nical report, GENI. Document ID: GENI-SE-IM-ARCH-1.0.
[GENI 2012] GENI (2012). Instrumentation tools for a GENI prototype (INSTOOLS).
ltimo acesso em 21/02/12.
[Grifoen ] Grifoen, J. From INSTOOLS to GEMINI. GEC12 Slides. 2011.
[Grifoen et al. 2009] Grifoen, J., Fei, Z., and Nasir, H. (2009). Architectural design
and specication of the INSTOOLS measurement system. Technical report, Labora-
tory of Advanced Networking, University of Kentucky.
[Hanemann et al. 2005] Hanemann, A., Boote, J. W., Boyd, E. L., Durand, J., Kudari-
moti, L., Lapacz, R., Swany, D. M., Trocha, S., and Zurawski, J. (2005). PerfSONAR:
a service oriented architecture for multi-domain network monitoring. In Proceedings of
the Third international conference on Service-Oriented Computing, ICSOC05, pages
241254, Berlin, Heidelberg. Springer-Verlag.
[Kompella and Rekhter 2007] Kompella, K. and Rekhter, Y. (2007). Virtual Private LAN
Service (VPLS) Using BGP for Auto-Discovery and Signaling. RFC 4761 (Proposed
Standard). Updated by RFC 5462.
[Kopsel and Woesner 2011] Kopsel, A. and Woesner, H. (2011). Ofelia pan-european
test facility for openow experimentation. In Towards a Service-Based Internet, vo-
lume 6994 of Lecture Notes in Computer Science, pages 311312. Springer Berlin /
Heidelberg.
[Magedanz et al. 2008] Magedanz, T., Schreiner, F., and Wahle, S. (2008). From NGN
to Future Internet Testbed Management - Collaborative Testbeds as Enabler for Cross-
Technology, Cross-Layer, and Cross-Domain Communication and Network Research.
Tele Kommunikation Aktuell, 62(5-6):2040. ISSN 1619-2036.
tion in campus networks. SIGCOMM Comput. Commun. Rev., 38:6974.
[Millard et al. 2012] Millard, P., Saint-Andre, P., and Meijer, R. (2012). XEP-0060:
Publish-Subscribe. http://xmpp.org/extensions/xep-0060.html. [l-
timo acesso: 06-Fevereiro-2012].
[Mussman 2012] Mussman, H. (2012). GENI instrumentation and measurement work in
progress. ltimo acesso em 20/02/12.
[NITLab 2012] NITLab (2012). CM cards. http://nitlab.inf.uth.gr/
NITlab/index.php/testbed/hardware/cm-card. [ltimo acesso: 20-
Janeiro-2012].
[OMF 2012a] OMF (2012a). Description of the OMF Inventory
Schema. http://www.mytestbed.net/projects/omf/wiki/
InstallationInventory_. [ltimo acesso: 20-Janeiro-2012].
[OMF 2012b] OMF (2012b). Low Cost Node Overview. http://www.mytestbed.
net/projects/lcn/wiki. [ltimo acesso: 20-Janeiro-2012].
[OMF 2012c] OMF (2012c). OEDL - The OMF Experiment Description Lan-
guage. http://www.mytestbed.net/projects/omf/wiki/The_
Experiment_Controller_AP%I. [ltimo acesso: 20-Janeiro-2012].
[OMF 2012d] OMF (2012d). OMF 5.4 installation guide. http://www.
mytestbed.net/projects/omf/wiki/Installation_Guide_54. [l-
timo acesso: 20-Janeiro-2012].
[OMF 2012e] OMF (2012e). OMF System Prerequisites. http://mytestbed.
net/projects/omf/wiki/Prerequisites. [ltimo acesso: 20-Janeiro-
2012].
[OMF 2012f] OMF (2012f). PXE les. http://pkg.mytestbed.net/files/
5.4/pxe/. [ltimo acesso: 20-Janeiro-2012].
[OMF 2012g] OMF (2012g). Tutorials on Controlling Testbed Resources.
http://www.mytestbed.net/projects/omf/wiki/Advanced_
Tutorials_for_Exper%imenters. [ltimo acesso: 20-Janeiro-2012].
[OneLab2_Executive_Committee_and_guests 2009] OneLab2_Executive_Committee_and_guests
(2009). Whitepaper 01 - On Federations... http://www.onelab.eu/images/
PDFs/Whitepapers/onelab2_whitepaper01.pdf. [ltimo acesso:
12-Fevereiro-2012].
[Peterson et al. 2003] Peterson, L., Anderson, T., Culler, D., and Roscoe, T. (2003). A
blueprint for introducing disruptive technology into the internet. SIGCOMM Comput.
Commun. Rev., 33:5964.
[Peterson et al. 2010] Peterson, L., Ricci, R., Falk, A., and Chase, J. (2010). Slice-Based
Federation Architecture.
[Peterson and Roscoe 2006] Peterson, L. and Roscoe, T. (2006). The design principles
of planetlab. SIGOPS Oper. Syst. Rev., 40:1116.
[Peterson et al. 2009a] Peterson, L., Sevinc, S., Baker, S., Mack, T., Moran, R., and Ah-
med, F. (2009a). PlanetLab Implementation of the Slice-Based Facility Architecture.
[Peterson et al. 2009b] Peterson, L., Sevinc, S., Baker, S., Mack, T., Moran, R., and Ah-
med, F. (2009b). PlanetLab Implementation of the Slice-Based Facility Architecture.
[Peterson et al. 2009c] Peterson, L., Sevinc, S., Lepreau, J., Ricci, R., Wroclawski, J.,
Faber, T., Schwab, S., and Baker, S. (2009c). Slice-Based Facility Architecture.
[Raychaudhuri et al. 2005] Raychaudhuri, D., Ott, M., and Secker, I. (2005). Orbit radio
grid tested for evaluation of next-generation wireless network protocols. In Procee-
dings of the First International Conference on Testbeds and Research Infrastructures
for the DEvelopment of NeTworks and COMmunities, TRIDENTCOM 05, pages 308
[Sanchez et al. 2011] Sanchez, A., Moerman, I., Bouckaert, S., Willkomm, D., Hauer, J.,
Michailow, N., Fettweis, G., DaSilva, L., Tallon, J., and Pollin, S. (2011). Testbed
Federation: An Approach for Experimentation-Driven Research in Cognitive Radios
and Cognitive Networking. In Proceedings of the Future Network Summit, pages 19.
[Singh et al. 2005] Singh, M., Ott, M., Seskar, I., and Kamat, P. (2005). ORBIT measu-
rements framework and library (OML): motivations, implementation and features. In
Testbeds and Research Infrastructures for the Development of Networks and Commu-
nities, 2005. Tridentcom 2005. First International Conference on, pages 146 152.
[Stasi et al. 2009] Stasi, G. D., Avallone, S., and Canonico, R. (2009). Integration of
omf-based testbeds in a global-scale networking facility. In Quality of Service in He-
terogeneous Networks, Lecture Notes of the Institute for Computer Sciences, Social
Informatics and Telecommunications Engineering, pages 545555. Springer Berlin
Heidelberg.
[Swany and Boyd ] Swany, M. and Boyd, E. Leveraging and abstracting measurements
with perfSONAR (LAMP). ltimo acesso em 21/02/12.
[Swany et al. 2011] Swany, M., Small, C., Boyd, E., Grifoen, J., and Fei, Z. (2011).
GEMINI: A GENI measurement and instrumentation infrastructure. GEC12 Slides.
[Tronco 2010] Tronco, T. (2010). New Network Architectures The Path to the Future
Internet. Springer-Verlag Berlin Heidelberg, Warsaw, Poland, 1st edition.
[Wahle 2008] Wahle, S. (2008). Teagle - The Central Testbed Federation Tool. In Panlab
Seminar - Testbed Federation in Europe, Dinard, France.
[Wahle et al. 2008] Wahle, S., Gavras, A., Gouveia, F., Hrasnica, H., and Magedanz, T.
(2008). Network Domain Federation - Infrastructure for Federated Testbeds. In 2008
NEM Summit - Towards Future Media Internet, pages 179 184, Saint-Malo, France.
Eurescom GmbH. ISBN 978-3-00-025978-4.
[White et al. 2002] White, B., Lepreau, J., Stoller, L., Ricci, R., Guruprasad, S., New-
bold, M., Hibler, M., Barb, C., and Joglekar, A. (2002). An integrated experimental
environment for distributed systems and networks. SIGOPS Oper. Syst. Rev., 36:255
270.
[x667 2004] x667 (2004). Information technology Open Systems Interconnection
Procedures for the operation of OSI Registration Authorities: Generation and registra-
tion of Universally Unique Identiers (UUIDs) and their use as ASN.1 object identier
components.
[Zink 2011] Zink, M. (2011). GIMI: Large-scale GENI instrumentation and measure-
ment infrastructure. GEC12 Slides.
Captulo
4
Redes Denidas por Software:
uma abordagem sist emica para o desenvolvimento
de pesquisas em Redes de Computadores
Dorgival Guedes, Luiz Filipe Menezes Vieira, Marcos Menezes Vieira,
Henrique Rodrigues e Rog erio Vinhal Nunes
Abstract
Software Dened Networks (SDN) are a new paradigm for the development 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 stan-
dard, 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 environments and network applications which can be developed easily and with-
out the limitations of the current network technologies. This short course take a systemic
approach to the topic, with theoretical and practical 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 on-
going 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.
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 ga-
nhando a atenc ao de grande parte da comunidade 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 ele-
mentos 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
Minicursos Livro Texto 161
das limitac oes das tecnologias de rede atuais. Este minicurso adota uma abordagem
sist emica da area, com aspectos de teoria e pr atica. Na parte te orica, discutimos os di-
versos componentes de um sistema de rede denido por software, 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 di-
versos 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 sis-
tema operacional de redes POX, desenvolvido especicamente para ns de pesquisa e
ensino.
4.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
162 XXX Simp osio Brasileiro de Redes de Computadores e Sistemas Distribudos - SBRC 2012
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.
4.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.
4.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 focaram
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.
4.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 identicados
com o paradigma de forma a dar ao leitor uma vis ao geral do papel de cada compo-
nente 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 disponveis
para a implementac ao de SDNs;
6. Aplicac oes discute como o conceito de SDN pode ser aplicado a diferentes con-
textos 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 diver-
sos 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.
4.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 4.1 ilustra essa organizac ao, para uma rede com elementos com e sem o.
D
i
v
i
s
o
r
Figura 4.1. Estrutura geral de uma SDN
4.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
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).
4.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.
4.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.
4.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.
4.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.
4.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 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.
4.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 par-
tir 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 4.2
apresenta uma vis ao geral de uma entrada da tabela OpenFlow. Cada pacote que chega
a um comutador OpenFlow e comparado com cada entrada dessa tabela; caso um casa-
mento seja encontrado, considera-se que o pacote pertence ` aquele uxo e aplica-se as
ac oes relacionadas ` a esse uxo. Caso um casamento n ao seja encontrado, o pacote e en-
caminhado 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. Esses contado-
res s ao implementados para cada entrada da tabela de uxos e podem ser acessados pelo
controlador atrav es do protocolo.
Figura 4.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 4.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 4.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.
4.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.
4.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.4), o Open vSwitch e composto por dois
componentes principais: um m odulo presente no n ucleo do sistema operacional, deno-
minado 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 uxos 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.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.
4.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 en-
capsulamento e desencapsulamento 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.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 4.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 4.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 handover; nalmente, hard handover engloba dois con-
juntos 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 4.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.
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
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 4.6. FlowVisor: organizac ao do sistema e uxo de comandos. Um co-
mando 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 encaminhado por um switch OpenFlow para o contro-
lador e processado pelo demultiplexador para identicar qual o controlador do
nvel acima que e repons avel por aquela faixa dos atributos de entrada.
completamente implementado.
4.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.
4.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 umpacote recebido
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 associadas
` 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 um pedido 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 4.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 4.7. O manipulador switch join abaixo invoca o
repetidor quando o switch se junta ` a rede. A func ao repetidor instala regras no switch
que o instruem a enviar pacotes da porta 1 para a porta 2 e vice-versa. As regras s ao
permanentes (prioridade DEFAULT e tempo limite None).
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)])
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.
4.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 como
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. Um exemplo de
arquivo de congurac ao e apresentado a seguir.
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
4.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 componentes
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
4.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.
4.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 .
4.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 4.8. Sintaxe de Consulta do Frenetic
A gura 4.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
ltro 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 operadores de conjunto como intersec ao (and fp), uni ao (or fp),diferenca
(diff fp) e complemento(not fp). Cl ausulas GroupBy([qh1,...,qhn]) subdividem o con-
junto de pacotes 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) limitam o n umero de pacotes
em cada subconjunto. Um exemplo de consulta utilizando Frenetic e apresentado a seguir.
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.
4.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.
4.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.
4.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].
4.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.
4.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.
4.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.
4.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.
4.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 ao 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 que 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 simplicar a express ao de comportamentos que de-
vem 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
operacional 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.
4.6.2. Alguns projetos de pesquisa
Pela caracterstica recente do tema, diversos projetos de pesquisa ainda focam o desen-
volvimento de controladores de rede que preencham as caractersticas de um sistema ope-
racional de rede, na denic ao de SDN. Esses projetos j a foram discutidos na sec ao 4.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
afetam 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 des-
ses projetos.
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. 2011b, Rodrigues et al. 2011a].
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
4.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 4.9.
Figura 4.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.
4.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
.
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/
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 na sec ao 4.5.12, 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
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
3
https://github.com/
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 sistema de controle de eventos e implementado na
biblioteca revent. O princpio geral 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.
4.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 ambiente de threads cooperativas, que 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 outra
thread.
As threads cooperativas precisam ser criadas criando uma classe que estenda
recoco.Task e implemente um m etodo run. Ap os a criac ao a thread precisa ser esca-
lonada e quando for escolhida para executar, ela pode considerar que executar a atomica-
mente 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 coope-
rativa do recoco, isso pode ser feito utilizando locks normais e estruturas threadsafe
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
recoco.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 default)
started se False, precisa chamar .start() para iniciar o timer
selfStoppable se True, 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):
4.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.
4.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
interagir 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 pacotes.
Possui diversas implementac oes que simulam switches (nveis 2 e 3) com compor-
tamento diferenciado para o ambiente openow.
4.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 openflow, o m odulo packet, e a bibli-
oteca revent, que e a respons avel por gerar os eventos do POX, j a discutidos anterior-
mente.
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)
Biblioteca packet
A biblioteca packet possibilita que se acesse detalhes do pacote sendo manipulado. 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 correspondemaos enderecos Ethernet do pacote
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 encontrados
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.
4.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.
4.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 com-
ponente 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
seguido 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
automaticamente 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 Con-
nectionUp 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,))
...
4.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 endereco/porta de origem p/ atualizar 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?
3a) Envie o pacote por todas as portas
FIM
4) O endereco de destino N
AO esta na tabela endereco/porta?

4a) Envie o pacote por todas as portes
FIM
5) A porta de sada e a mesma de entrada?
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 nas guras 4.10 e 4.11. Elementos importantes
do c odigo s ao discutidos a seguir. Comando de log s ao utilizados de forma simplicada
para reduzir o tamanho do c odigo. Posteriormente discutimos o uso de mensagens de log
mais elaboradas usando recursos de Python.
1 c l a s s l 2 f a c t o r y ( Event Mi xi n ) :
2
3 Es per a por conexoes de s wi t c he s OpenFlow e c r i a o o b j e t o pa r a
4 t r a ns f or m a l o s em s wi t c h e s L2 com a pr e ndi z a do .
5
6 def i n i t ( s e l f ) :
7 s e l f . l i s t e n To ( c or e . openf l ow )
8
9 def handl e Connect i onUp ( s e l f , e ve nt ) :
10 l og . debug ( Connect i on %s % ( e ve nt . c onne c t i on , ) )
11 Le a r ni ngSwi t c h ( e ve nt . c onne c t i on )
12
13 def l a unch ( ) :
14 c or e . r e gi s t e r Ne w ( l 2 f a c t o r y )
Figura 4.10. C odigo geral para registro de switches L2 com aprendizado no POX
O c odigo da gura 4.11 dene a classe LearningSwitch, que implementa
o switch propriamente dito. Antes de analisarmos esse c odigo, entretanto, devemos
observar que o c odigo da gura 4.10 dene outra classe derivada de EventMixin,
l2 factory. Essa ultima classe age como uma f abrica de switches: seu construtor
(linhas 67) se registra com o componente openflow do core, de forma que o tratador
de eventos para novas conex oes (novos comutadores) e instalado (linhas 911). Ao de-
tectar uma conex ao de um novo comutador um objeto da classe LearningSwitch e
criado e associado ` a conex ao. As linhas 1314 denem a func ao launch() para esse
m odulo: ela registra um objeto da classe construtora junto ao core do POX.
J a na gura 4.11, encontramos a denic ao do comportamento dos switches com
aprendizado, como discutido anteriormente. A classe LearningSwitch tamb em herda
de EventMixin para ser capaz de tratar eventos de chegada de pacotes. Objetos
dessa classe comecam (construtor, linhas 25) identicando a conex ao de controle do
comutador OpenFlow, criando um dicion ario para registrar os enderecos MAC conheci-
dos e registrando-se para receber eventos gerados pelo comutador nesse caso, even-
tos 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
12), o preenchimento da tabela de enderecos (linha 13) e o acesso a diversas informac oes
derivadas do processamento do pacote (linhas 15, 19, 23), o uso de func oes de log para
registrar a evoluc ao do c odigo. Finalmente, as linhas de 35 a 41 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.
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 s e r a c o n t r o l a d a
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 ) # Par 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 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 qui .
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 )
Figura 4.11. C odigo para implementac ao de um switch L2 com aprendizado no POX
4.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
anteriormente, 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 um tratamento especial ao evento de Update, mas logo em seguida 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) po-
der ao trat a-los normalmente como qualquer outro evento do POX.
4.7.10. Utilizac ao do componente de log
O POX tem uma funcionalidade de logging facilmente utilizada e congur avel em di-
versos nveis. Para ter acesso a essa ferramenta, basta utilizar a func ao getLogger
da biblioteca core, passando o nome do componente registrado que voc e deseja aces-
sar (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 4.11 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 umnovo uxo no comutador (linha 34) na gura 4.11 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
componente 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, passando para o ultimo o par ametro web.webcore=INFO, o que de-
nir a o nvel de INFO para o log do componente web.webcore.
4.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 encon-
tradas 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 .
4.8. Desaos de pesquisa
O paradigma de Redes Denidas por Software abre uma grande gama de novas possi-
bilidades para a pesquisa em Redes de Computadores. A sec ao 4.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 para-
digma ainda est ao por ser identicados e desenvolvidos em modelos de pesquisa consoli-
dados.
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.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 mencionado 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.
4.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
[bea 2012] (2012). The beacon controller. https://openow.stanford.edu/display/Beacon/Home.
[o 2012] (2012). Floodlight. http://oodlight.openowhub.org/.
[nec 2012] (2012). Nec programmable ow. http://www.necam.com/pow/.
[ope 2012] (2012). Openstack:open source software for building private and public
clouds. http://openstack.org/.
[sna 2012] (2012). Simple network access control. http://www.openow.org/wp/snac/.
[tre 2012] (2012). Trema: Full-stack openow framework for ruby and c.
http://trema.github.com/trema/.
[Braga et al. 2010] 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 Local Computer Networks, pages 408415, Los Alamitos, CA, USA.
[Cai et al. 2010] 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 et al. 2011] Calvert, K. L., Edwards, W. K., Feamster, N., Grinter, R. E., Deng,
Y., and Zhou, X. (2011). Instrumenting home networks. SIGCOMM Comput. Com-
mun. Rev., 41(1):8489.
[Casado et al. 2010a] 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 et al. 2009] Casado, M., Freedman, M. J., Pettit, J., Luo, J., Gude, N., McKe-
own, N., and Shenker, S. (2009). Rethinking enterprise network control. IEEE/ACM
Transactions on Networking, 17(4):12701283.
[Casado et al. 2010b] 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 and Farrel 2008] Davie, B. S. and Farrel, A. (2008). MPLS: Next Steps: Next
Steps. Morgan Kaufmann Publishers Inc., San Francisco, CA, USA.
[Dixon et al. 2010] 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 and Falk 2009] Elliott, C. and Falk, A. (2009). An update on the geni project.
SIGCOMM Comput. Commun. Rev., 39(3):2834.
[Farias et al. 2011] 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 2010] Feamster, N. (2010). Outsourcing home network security. In Proce-
edings of the 2010 ACM SIGCOMM workshop on Home networks, HomeNets 10,
pages 3742, New York, NY, USA. ACM.
[Foster et al. 2010] 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 et al. 2008] 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 et al. 2010a] 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 et al. 2010b] Heller, B., Seetharaman, S., Mahadevan, P., Yiakoumis, Y., Sharma,
P., Banerjee, S., and Mckeown, N. (2010b). Elastictree: Saving energy in data center
networks. In Proceedings of the 7th Usenix Symposium on Networked Systems Design
and Implementation (NSDI).
[Hinrichs et al. 2009] Hinrichs, T. L., Gude, N. S., Casado, M., Mitchell, J. C., and Shen-
ker, S. (2009). Practical declarative network management. In Proceedings of the 1st
ACM workshop on Research on enterprise networking, WREN 09, pages 110, New
York, NY.
[Kempf et al. 2011] 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 et al. 2000] 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 et al. 2010] 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 control platform for large-scale production networks. In Procee-
dings of the 9th USENIX conference on Operating systems design and implementation,
OSDI10, pages 16, Berkeley, CA. USENIX Association.
[Lantz et al. 2010] Lantz, B., Heller, B., and McKeown, N. (2010). A network in a lap-
top: rapid prototyping for software-dened networks. In Proceedings of the Ninth
ACM SIGCOMM Workshop on Hot Topics in Networks, Hotnets 10, pages 19:119:6,
New York, NY, USA. ACM.
[Mattos et al. 2011] 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.
tion in campus networks. SIGCOMM Comput. Commun. Rev., 38:6974.
[Mehdi et al. 2011] Mehdi, S. A., Khalid, J., and Khayam, S. A. (2011). Revisiting trafc
anomaly detection using software dened networking. In Proceedings of the 14th
International Symposium on Recent Advances in Intrusion Detection (RAID), pages
161180.
[Mogul et al. 2010] 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 et al. 2009] Mundada, Y., Sherwood, R., and Feamster, N. (2009). An open-
ow switch element for click. In Proceedinds on the Symposium on Click Modular
Router.
[Nascimento et al. 2011] 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 approach leveraging software-dened networks. In Proceedings of the
6th International Conference on Future Internet Technologies (CFI), pages 03.
[Peterson and Roscoe 2006] Peterson, L. and Roscoe, T. (2006). The design principles
of planetlab. SIGOPS Oper. Syst. Rev., 40(1):1116.
[Pettit et al. 2010] Pettit, J., Gross, J., Pfaff, B., Casado, M., and Crosby, S. (2010). Vir-
tual 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 et al. 2009] Pfaff, B., Pettit, J., Amidon, K., Casado, M., Koponen, T., and Shen-
ker, S. (2009). Extending networking into the virtualization layer. In Proceedings of
the Eighth ACM Workshop on Hot Topics in Networks (HotNets-VIII).
[Ram et al. 2010] 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 et al. 2011] Reitblatt, M., Foster, N., Rexford, J., and Walker, D. (2011). Con-
sistent updates for software-dened networks: Change you can believe in. In Pro-
ceedings of ACM SIGCOMM Workshop on Hot Topics in Networks (HotNets), pages
16.
[Rodrigues et al. 2011a] Rodrigues, H., Santos, J. R., Turner, Y., Soares, P., and Guedes,
D. (2011a). 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.
[Rodrigues et al. 2011b] Rodrigues, H., Soares, P. V., Santos, J. R., Turner, Y., and Gue-
des, D. (2011b). Isolamento de tr afego eciente em ambientes virtualizados. In
Anais do XXIX Simp osio Brasileiro de Redes de Computadores e Sistemas Distribudos
(SBRC), pages 114. SBC.
[Sherwood et al. 2010] Sherwood, R. et al. (2010). Carving research slices out of your
production networks with openow. SIGCOMM Comput. Commun. Rev., 40:129130.
[Sherwood et al. 2009] 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 et al. 2011] Silva, G., Arantes, A., Steding-Jessen, K., Hoepers, C., Chaves, M.,
Jr., W. M., and Guedes, D. (2011). SpSb: um ambiente seguro para o estudo de spam-
bots. In Anais do Simp osio Brasileiro de Seguranca, pages 15, Braslia, DF. SBC.
[Tennenhouse and Wetherall 2007] Tennenhouse, D. L. and Wetherall, D. J. (2007).
Towards an active network architecture. SIGCOMM Comput. Commun. Rev.,
37(5):8194.
[Tootoonchian and Ganjali 2010] Tootoonchian, A. and Ganjali, Y. (2010). Hyperow:
a distributed control plane for openow. In Proceedings of the 2010 internet network
management conference on Research on enterprise networking, INM/WREN10, pa-
ges 33, Berkeley, CA. USENIX Association.
[Turner 2006] Turner, J. S. (2006). A proposed architecture for the geni backbone plat-
form. In Proceedings of the 2006 ACM/IEEE symposium on Architecture for networ-
king and communications systems, ANCS 06, pages 110, New York, NY, USA.
ACM.
Captulo
5
Redes Orientadas a Contedo:
Um Novo Paradigma para a Internet
Gabriel M. de Brito, Pedro B. Velloso e Igor M. Moraes
Laboratrio MdiaCom, PGC-TCC/Instituto de Computao
Universidade Federal Fluminense
Abstract
Content-Oriented Networks (CONs) are a new communication paradigm to the Internet.
This new paradigm focuses on the content delivery to users regardless of the location of
the content rather than the current Internet architecture that focuses on the communica-
tion between end systems. In CONs, the network infrastructure also actively contributes
to content caching and distribution. The main advantage of this new paradigm is to in-
crease the efciency of content delivery and also the content availability. Furthermore,
CONs simplies the solution of current Internet problems, such as mobility and content
security. This chapter presents the basic concepts of CONs, describes the main architec-
ture proposals for these networks, and discusses the main challenges for its development.
The challenges include naming, routing, and caching on the network-core elements and
also several aspects of content security, users privacy, and issues to implement CONs in
practice.
Resumo
As Redes Orientadas a Contedo (Content-Oriented Networks), ou simplesmente ROCs,
representamumnovo paradigma de comunicao para a Internet. Nesse novo paradigma,
o foco a entrega de um dado contedo para os usurios independentemente da local-
izao desse contedo, ao contrrio da arquitetura atual da Internet em que o foco a
comunicao entre sistemas nais. Nas ROCs a infraestrutura da rede tambm participa
ativamente do armazenamento e da distribuio dos contedos. A principal vantagem
desse novo paradigma, portanto, aumentar a ecincia da entrega e a disponibilidade
de contedos. Alm disso, as ROCs simplicam solues para problemas da Internet
atual, como a mobilidade e a segurana dos contedos. Este captulo apresenta os con-
ceitos bsicos das ROCs, descreve as principais propostas de arquiteturas para tais redes
e discute os principais desaos para seu desenvolvimento. Entre esses desaos esto a
nomeao de contedos, o roteamento e o uso de caches de contedo nos elementos do
ncleo da rede e tambm questes relativas segurana de contedos, privacidade dos
usurios e aos aspectos prticos para implantao das ROCs.
212 XXX Simpsio Brasileiro de Redes de Computadores e Sistemas Distribudos - SBRC 2012
5.1. Introduo
No incio do desenvolvimento da Internet, o principal problema a ser resolvido
em termos de comunicao entre computadores era o compartilhamento de recursos [Ja-
cobson et al. 2009a, Jacobson et al. 2012]. Estaes interconectadas necessitavam trocar
informaes, como arquivos e registros em bancos de dados, e tambm permitiam acesso
a equipamentos remotos, como impressoras. O objetivo, portanto, era a comunicao
eciente entre estaes. Hoje, novas tecnologias de rede de ncleo e de acesso propor-
cionam um aumento signicativo da banda passante disponvel e reduo dos custos de
conexo de usurios. Essa popularizao do acesso Internet estimula a criao de no-
vas aplicaes, como sistemas de publicao de vdeos e redes par-a-par (peer-to-peer -
P2P) de compartilhamento de arquivos, remodelando completamente a forma de uso da
Internet pelos usurios nais. Portanto, a distribuio de contedo na Internet passou por
um processo de evoluo, afastando-se da denio de sistema de informao textual em
direo de um sistema de informao multimdia, no qual dados, servios e aplicaes
so consumidos como contedos [Plagemann et al. 2005]. Esse novo modelo enfatiza
o interesse pelo contedo, independente de sua localizao fsica ou lgica. Contedo,
nesse contexto, consiste de dados codicados ou dados multimdias, como vdeo, udio,
documentos, imagens e pginas web, por exemplo, e metadados, isto , dados a respeito
dos dados que possibilitam sua localizao, sua interpretao e seu gerenciamento [Plage-
mann et al. 2005]. Essa nova caracterizao implica a existncia de uma infraestrutura
que possibilite a requisio e transmisso de contedo de forma eciente, segura e com
alta disponibilidade. Apesar dessa mudana na caracterstica de uso das aplicaes, os
protocolos mais utilizados para a obteno de contedo na Internet so, ainda, orientados
localizao.
Atualmente, ainda no existe uma soluo nica que contemple todos os requi-
sitos da distribuio de contedo. Basicamente, existem tcnicas que tentam atender
parcialmente esses requisitos e contornar as limitaes da atual arquitetura da Internet.
Redes P2P e redes de distribuio de contedos (Content Distribution Networks - CDNs)
so solues largamente adotadas para o atendimento desse objetivo, como comprova
o sucesso de aplicaes como o BitTorrent e de provedores de CDNs como a Akamai.
Porm, a arquitetura atual da Internet remete a problemas de persistncia, disponibilidade
e segurana dos contedos, uma vez que tais aplicaes fazem uso de solues espec-
cas e/ou proprietrias. O uso de redirecionamentos HTTP (HyperText Transfer Protocol)
e DNS (Domain Name System) dinmico em CDNs, por exemplo, no garante a persistn-
cia das informaes. O reposicionamento dos dados na rede tambm requer consultas a
estruturas centralizadas, aumentando o tempo total de entrega do contedo [Koponen et al.
2007]. Portanto, se faz necessria uma mudana radical na arquitetura atual da Internet.
Deve-se levar em conta aspectos para aumentar a ecincia da localizao e da entrega
e a disponibilidade de contedos. Esses requisitos so atendidos pelas redes orientadas a
contedo (ROCs).
As redes orientadas a contedo introduzem um novo paradigma de comunicao
para a Internet. As ROCs enfatizam o acesso informao independentemente de sua
localizao. Diferentemente da abordagem tradicional da Internet, centrada na identica-
o e localizao de estaes, as ROCs utilizam conceitos inovadores como contedo
nomeado, roteamento baseado em nomes, segurana aplicada diretamente a contedos e
armazenamento de dados nos elementos do ncleo da rede [Jacobson et al. 2009a, Kopo-
nen et al. 2007, Visala et al. 2009] Tais conceitos permitem criar uma arquitetura mais
eciente para a distribuio de contedo, evitando assim todos os remendos necessrios
arquitetura vigente da Internet, como o IP Multicast, o uso do DNS, IPSec etc. A arquite-
tura baseada em contedo pode, ento, prover de forma nativa novas funcionalidades,
como o compartilhamento eciente de recursos e de dados, mecanismos para aumentar
a disponibilidade dos contedos, suporte segurana intrnseca de contedos, suporte
mobilidade etc.
Neste captulo so apresenta os conceitos bsicos das ROCs, apontando seus prin-
cipais diferenciais em relao arquitetura tradicional da Internet centrada na comunica-
o entre usurios. So tambm descritas e analisadas as principais propostas de arquite-
tura para as ROCs, bem como os projetos de pesquisa de maior destaque. Por m, so
apresentados os principais desaos para o desenvolvimento das ROCs, como a nomeao
e o roteamento de contedos a segurana de contedos e a privacidade de usurios, o
uso de caches de contedo nos elementos do ncleo da rede e aspectos prticos para a
implantao das ROCs em larga escala.
O restante deste captulo organizado em quatro sees. A Seo 5.2, de forma
sucinta, caracteriza a atual arquitetura da Internet e discute suas limitaes para o desen-
volvimento de aplicaes de distribuio de contedo. Descreve-se, ainda, as principais
tcnicas empregadas para contornar essas limitaes, como a comunicao multidesti-
natria, as redes par-a-par, os sistemas publish/subscribe e as redes de distribuio de
contedo. A Seo 5.3 apresenta o novo paradigma introduzido pelas ROCs, descrevendo
suas principais caractersticas, propostas de arquitetura existentes e projetos mais rele-
vantes. A Seo 5.4 discute alguns dos principais problemas ainda em aberto no desen-
volvimento das ROCs, como a nomeao, o roteamento, o armazenamento (caching), a
segurana do contedo e a viabilidade tcnica. Por m, a Seo 5.5 apresenta algumas
consideraes sobre o tema e as perspectivas futuras para desenvolvimento desse novo
paradigma de comunicao para a Internet.
5.2. A Distribuio de Contedo na Internet
No incio, as aplicaes na Internet erambaseadas em informaes textuais. Usu-
rios apenas trocavam mensagens de correio eletrnico, transferiam arquivos via FTP (File
Transfer Protocol) e acessavam servidores remotamente. Hoje, a Internet considerada
um complexo sistema de informao multimdia baseado na distribuio de contedos.
Entende-se por contedo dados textuais, codicados ou multimdias, como documentos,
pginas web, arquivos de udio e vdeo, e tambm metadados, que so usados para lo-
calizar, interpretar e gerenciar os prprios contedos [Plagemann et al. 2005]. Essa nova
caracterizao da Internet implica a existncia de uma infraestrutura de rede que pos-
sibilite a requisio e transmisso de contedos de forma eciente. Para tanto, alguns
requisitos bsicos devem ser atendidos. O primeiro requisito garantir a persistncia
dos contedos. A persistncia uma propriedade dos identicadores
1
de contedos que
dene que eles devem ser nicos e vlidos enquanto o contedo associado permanecer
vlido. Atualmente, mesmo usurios leigos conseguem facilmente publicar contedos na
1
Neste captulo os termos identicadores e nomes so utilizados como sinnimos.
Internet, o que confere um carter bastante voltil s informaes geradas. Por isso, o uso
persistente de identicadores representa um grande desao distribuio de contedo na
Internet. O segundo requisito a escalabilidade, ou seja, os mecanismos de localizao e
encaminhamento de contedos devem ser ecientes para o nmero de usurios e de con-
tedos disponibilizados na escala da Internet. O acesso seguro a contedos o terceiro
requisito, que visa garantir a autenticidade e o controle de acesso aos contedos disponi-
bilizados. Atualmente no existe uma nica soluo que contemple todos esses requisitos.
Existem apenas tcnicas que tentam atend-los de forma parcial e contornar as limitaes
da atual arquitetura da Internet.
5.2.1. A Arquitetura Centrada em Sistemas Finais e suas Limitaes
Trs caractersticas da arquitetura atual da Internet so os principais fatores que
impedem que os requisitos das aplicaes de distribuio de contedo sejam atendidos
satisfatoriamente: a ausncia de garantias de (i) qualidade de servio e (ii) segurana
m-a-m e de (iii) mecanismos de encaminhamento escalveis.
A Internet uma rede de comutao de pacotes de escala global na qual os pacotes
so encaminhados segundo o modelo de melhor esforo oferecido pelo protocolo IP (In-
ternet Protocol). No h reserva de recursos para cada usurio da rede, nem diferenciao
no tratamento dos pacotes encaminhados pelos roteadores. Assim, no h garantias de de-
sempenho ou segurana m-a-m para a distribuio de contedo na Internet atual. Alm
disso, o foco da arquitetura atual a comunicao entre sistemas nais.Nesse contexto,
a comunicao entre estaes na Internet centrada em sistemas nais, j que a estao
de origem precisa indicar no cabealho dos pacotes o endereo IP da estao de destino
com a qual deseja se comunicar. O encaminhamento de tais pacotes realizado por cada
um dos ns (hops) existentes no caminho entre as estaes de origem e destino, utilizando
como nico balizador o endereo IP da estao de destino nal. Esse paradigma atende as
aplicaes iniciais da Internet, cujo objetivo era o compartilhamento de recursos. Porm,
ele no eciente para a distribuio de contedo, pois, entre outros fatores, exige que o
usurio conhea a localizao e no somente a identicao do contedo.
Atualmente existem solues paliativas, ou remendos" para aumentar a ecin-
cia da distribuio de contedo na Internet. Um exemplo o redirecionamento HTTP
usado para tratar a localizao de contedos em virtude da volatilidade desses contedos.
Objetos web so requisitados atravs de localizadores de recursos, denominados URLs
(Uniform Resource Locator), presentes no cabealho das mensagens HTTP. Os redire-
cionamentos HTTP so eventos disparados pelo servidor que originalmente hospedava os
objetos, enviando como resposta mensagens de redirecionamento coma nova URL emseu
cabealho. Como tal soluo dependente da localizao do contedo, se faz necessrio
desenvolver mecanismos que garantam o acesso persistente a esses contedos, indepen-
dentemente de localizao, propriedade ou qualquer outra caracterstica pertinente associ-
ada a eles. Esse exemplo tambm ilustra os conceitos do modelo cliente-servidor adotado
por muitas das aplicaes de distribuio de contedo na Internet atual. Nesse modelo,
um canal de comunicao ponto-a-ponto estabelecido entre um determinado cliente e
um servidor. Assim, diversos usurios que solicitam simultaneamente um mesmo con-
tedo so atendidos atravs do estabelecimento de mltiplos canais ponto-a-ponto e do
envio de uma cpia do mesmo contedo em cada canal. Nesse cenrio, quanto mais pop-
ular um contedo, maior a inecincia no uso dos recursos, principalmente, em termos de
banda passante. Assim, a adoo de solues em larga escala requer o desenvolvimento
de tcnicas de encaminhamento ecientes que conram escalabilidade distribuio de
contedo na Internet.
As aplicaes atuais de distribuio de contedos buscam, ainda, garantir a auten-
ticidade das informaes e segurana na comunicao sobre a Internet. Para tal, utilizam
mecanismos que visam assegurar o canal de comunicao ao invs de utilizar segurana
explicitamente sobre o contedo. Isso gera uma camada adicional de complexidade e
sobrecarga de mensagens e processamento [Smetters e Jacobson 2009]. O IPSec (Inter-
net Protocol Security) outro exemplo de remendo utilizado no tratamento de segurana.
Atravs da insero de cabealhos de autenticao (Authentication Headers - AH), de
criptograa aplicada s informaes e encapsulamento do pacote original (Encapsulating
Security Payloads - ESP) e de mecanismos de administrao de chaves, o IPSec per-
mite estabelecimento de conexes conveis entre os ns. Essa abordagem orientada
a conexo amarra a segurana do contedo conana na estao que o armazena e
conexo estabelecida entre as partes, impossibilitando aumento de escalabilidade com o
compartilhamento do contedo entre sistemas distintos. necessrio o estabelecimento
de mltiplas conexes seguras entre fontes de contedos e os diversos usurios, impossi-
bilitando o armazenamento e uso posterior de contedo previamente requisitados [Smet-
ters e Jacobson 2009].
5.2.2. Comunicao Multidestinatria
A comunicao multidestinatria (multicast) foi uma das primeiras alternativas
propostas a m de aumentar a ecincia da distribuio de contedo na Internet. Uma
proposta para implement-la na camada de rede o servio IP Multicast [Deering 1989].
Esse servio permite o envio de datagramas para mltiplos sistemas nais, cujos inter-
esses comuns de recepo de dados permitem agreg-los em grupos. Esses grupos so
identicados por um nico endereo IP. Assim, se uma estao enviar um datagrama ao
endereo IP do grupo, todas as estaes que fazem parte desse grupo o recebero. re-
sponsabilidade da rede encaminhar e replicar, quando necessrio, esse datagrama por toda
a rvore de distribuio que cobre os receptores interessados. Apesar de suas vantagens
e de ter sido proposto na dcada de 90, a implantao do IP Multicast em larga escala
na Internet ainda no ocorreu, em virtude da complexidade para congurar e gerenciar o
conjunto de protocolos exigidos por esse servio. Essa complexidade introduzida pelo
prprio modelo de servio IP Multicast, que dene um grupo como uma conversao
aberta muitos-para-muitos [Costa e Duarte 2003].
5.2.3. Redes Par-a-Par
As redes par-a-par (peer-to-peer - P2P) tambm buscam aumentar a ecincia da
distribuio de contedo. Dada a diculdade da adoo da comunicao multidestinatria
na camada de rede, por exigir modicao no ncleo da rede, solues que implementam
tal comunicao na camada de aplicao so propostas [Moraes et al. 2008]. Esse
o caso das redes P2P, as quais so formadas por ns que, atravs do compartilhamento
de recursos computacionais e de contedos, dividem a carga de provimento de servios
entre si de forma cooperativa. Cada par contribui com parte de seus recursos e usufrui do
servio distribudo prestado pela rede [Passarella 2012]. Dessa forma, cada novo par que
adentra a rede utiliza uma parcela da capacidade total enquanto disponibiliza seus prprios
recursos aos demais pares. Isso faz da escalabilidade uma caracterstica intrnseca s
redes P2P. Consequentemente, quanto mais ns pertencerem rede P2P, maior ser a
capacidade da rede em atender seus usurios, o que pode reduzir o tempo de entrega e
aumentar a disponibilidade de contedos [Moraes et al. 2008].
Outra caracterstica fundamental a de que umusurio est interessado emreceber
um dado contedo, seja ele um arquivo ou uxo multimdia, sem se importar com quem
o envia. No BitTorrent, por exemplo, um par, ao entrar na rede P2P, seleciona aleatori-
amente seus parceiros, com os quais trocar pedaos do contedo. Esses parceiros so
sorteados de um subconjunto dos pares que se interessam por um mesmo contedo e nen-
huma informao sobre localizao ou identicao dos pares levada em considerao
nesse processo de escolha. O sucesso das redes P2P de compartilhamento de arquivos
e de distribuio de vdeo, que possuem milhes de usurios, um forte indicativo da
mudana de paradigma das aplicaes da Internet e que sustenta o principal fundamento
das ROCs, como ser visto na Seo 5.3: usurios cada vez mais esto interessados no
contedo e no mais em quem o envia.
Apesar de serem solues escalveis para a distribuio de contedo na Inter-
net, as redes P2P apresentam problemas cruciais de segurana e incentivo colaborao
para o seu uso na distribuio de contedos. Uma vez que a rede distribuda e suas
funcionalidades so executadas de forma colaborativa por todos os ns, a conana nos
dados encaminhados pelos ns passa a ser um ponto crtico, o qual as redes P2P devem
tratar. Outro ponto crtico a robustez entrada e sada de ns da rede (churn) que acar-
reta problemas de ecincia de distribuio e disponibilidade de contedos, uma vez que
no existe uma infraestrutura dedicada para gerenciar esses eventos.
5.2.4. Redes de Distribuio de Contedo
As redes de distribuio de contedo (Content Distribution Networks - CDNs)
forampropostas para o aumentar a ecincia e a escalabilidade do modelo cliente-servidor
empregado por aplicaes de distribuio de contedos na Internet [Passarella 2012]. As
CDNs so formadas por um conjunto de servidores distribudos, interconectados pela In-
ternet, que operam de forma cooperativa na distribuio de contedo [Buyya et al. 2008].
Os aumentos de disponibilidade e da ecincia na distribuio de contedos se do atravs
da replicao de contedos em diferentes localidades e, sempre que possvel, em difer-
entes provedores de acesso Internet. A idia principal de redirecionar as requisies
de contedo para uma das rplicas de acordo com regras de seleo/redirecionamento.
Assim, o armazenamento dos contedos em servidores mais prximos aos clientes torna
a entrega desses contedos mais eciente, aumentando as taxas de transferncia de dados
devido diminuio dos gargalos nas redes de acesso e reduzindo a latncia no acesso
dada a proximidade entre os sistemas nais envolvidos.
O conceito bsico de uma arquitetura de CDN pode ser representado por dois blo-
cos funcionais: um servio de distribuio e replicao de contedos e um servio de redi-
recionamento de requisies de contedo [Passarella 2012]. O servio de distribuio e
replicao de contedos intimamente ligado aos produtores de contedo e trata questes
relativas localizao de servidores, alocao de espao de armazenamento e alocao
de contedos nos servidores. O servio de redirecionamento de requisies, interface da
CDN com os consumidores de contedos, responsvel pelo recebimento de requisies
de contedo e encaminhamento aos ns da rede CDN mais adequados para atender de-
manda. Uma CDNtpica composta por dois tipos de servidores: o servidor de origeme o
servidor de rplica. O servidor de origem o responsvel pelo armazenamento, atribuio
de identicadores e divulgao do contedo. O servidor de rplica, por sua vez, respon-
svel por encaminhar o contedo para um dado cliente. Requisies enviadas para o
servidor de origem so redirecionadas para o servidor de rplica mais prximo do cliente,
uma vez que o contedo desejado esteja disponvel em tal servidor, processo ilustrado na
Figura 5.1. Dessa forma, os mecanismos de redirecionamento so extremamente impor-
tantes para o correto funcionamento das CDNs.
Figure 5.1. O funcionamento de uma CDN [Moraes et al. 2008].
A tcnica mais simples de redirecionamento utilizar o HTTP, em que todas as
requisies de objetos web so feitas atravs de um navegador de Internet executado nos
sistemas nais dos usurios. Ao receber a requisio, o servidor de origem envia men-
sagens de redirecionamento HTTP com o endereo do servidor de rplica adequado. Tal
tcnica delega ao servidor de origem todo o processamento de requisies, tornando-o
um gargalo potencial e ponto singular de falha. Outra tcnica bastante utilizada consiste
em aplicar conguraes dinmicas do DNS que, quando consultado sobre o nome as-
sociado ao servidor de origem, envia como resposta o endereo do servidor de rplica
mais adequado. Ambas as tcnicas podem utilizar informaes relativas distncia do
servidor de rplica em relao ao cliente, como quantidade de saltos ou tempos de ida
e volta (Round-Trip Time - RTT), bem como informaes de utilizao dos servidores
que podem ser coletadas periodicamente pelos sistemas. Ainda que permitam o encam-
inhamento de requisies a servidores diferentes dos originalmente endereados, tais tc-
nicas no conferem persistncia efetiva aos dados. Alteraes de propriedade, domnio
e outras caractersticas de determinado contedo podem inviabilizar sua obteno par-
tir da URL previamente conhecida. Adicionalmente, o reposicionamento dos dados na
rede requer consultas a estruturas centralizadas, aumentando o tempo total de entrega do
contedo [Koponen et al. 2007].
As CDNs, porm, no so projetadas visando a interoperabilidade de aplicaes,
e sim o atendimento de demandas especcas, como o caso da obteno de objetos web.
Por isso, so baseadas em implementaes proprietrias a cada aplicao consumidora
de contedos. Uma vez que no propicia um substrato genrico o suciente para o trata-
mento do problema de distribuio de contedo, as CDNs no se adaptam totalmente s
demandas dos assinantes. Adicionalmente, decises sobre posicionamento de servidores,
dimensionamento da capacidade de armazenamento de cada n, bem como polticas de
atualizao de cache so fundamentais para e ecincia das CDNs [Passarella 2012]. Evi-
dentemente, tais processos so altamente custosos, tanto do ponto de vista computacional,
uma vez que algoritmos para deciso e distribuio de rplicas devem ser executados em
tempo real, quanto do ponto de vista nanceiro, j que a distribuio geogrca de re-
cursos computacionais e de rede reete altos investimentos por parte dos provedores dos
servios de CDN.
Existem diversos exemplos de provedores de CDNs tanto acadmicas, como a
CoDeeN [Wang et al. 2004], quanto comerciais, como a Limelight
2
e a Akamai
3
, sendo
a ltima a mais popular. Estima-se que a Akamai possua mais de 100 mil servidores
espalhados pela Internet, com pontos de presena em 72 pases, suportando trilhes de
interaes por dia [Akamai Technologies 2012].
5.2.5. Sistemas Publish/Subscribe
Os sistemas publish/subscribe (pub/sub), assim como as redes P2P, podem ser
vistos como um dos principais indicativos da mudana de paradigma das aplicaes da
Internet. Em ambos os casos, os usurios das aplicaes esto interessados em receber o
contedo de interesse, no importando quem o envie.
Em sistemas pub/sub, as informaes de interesse dos usurios so denominadas
eventos, enquanto o ato de entrega dessas informaes denominado de noticao.
Assim, assinantes (subscribers) so capazes de expressar seus interesses em eventos ou
padres de eventos denidos pelos publicadores. Uma vez tendo manifestado interesse,
um assinante ser noticado sempre que for gerado um evento por quaisquer publicadores
(publishers) que casem com seu interesse.
Os sistemas pub/sub dissociam assinantes e publicadores tanto no espao quanto
no tempo [Eugster et al. 2003]. Um assinante, por exemplo, pode manifestar o inter-
esse em um evento ainda no publicado ou em um instante no qual o publicador desse
evento no est em funcionamento. A dissociao uma caracterstica desejvel, pois
proporciona escalabilidade ao sistema, uma vez que permite aos participantes do sistema
operarem de forma independente [Eugster et al. 2003]. Produtores publicam contedos
apenas injetando informaes no sistema usando a funo publish(), enquanto con-
sumidores expressam seus interesses atravs de assinaturas declarativas, usando a funo
subscribe(), delegando ao sistema pub/sub a responsabilidade do armazenamento de
assinaturas e da entrega dos contedos a todos os assinantes interessados, como ilustrado
na Figura 5.2. Essa caracterstica permite a disseminao de informaes entre milhes
de produtores e assinantes, uma vez que produtores no necessitam manter estados rel-
ativos a todos os interesses dos assinantes, enquanto estes recebem as informaes sem
conhecer, especicamente, o produtor que as enviou [Majumder et al. 2009]. Esse mais
2
http://www.limelight.com/
3
http://www.akamai.com/
um exemplo claro de que usurios esto interessados nos contedos e no mais em quem
os envia.
Figure 5.2. Servio de assinatura e noticao de eventos em arquiteturas
pub/sub [Eugster et al. 2003].
Os primeiros sistemas pub/sub propostos eram baseados em tpicos identicados
por palavras-chave (Topic-based Pub/Sub). Sistemas de integrao de aplicaes corpo-
rativas, de monitorao do mercado de aes, de alimentao RSS (Really Simple Sindy-
cation), plataformas de jogos on-line, so exemplos desse tipo de sistema [Chockler et al.
2007]. Em sistemas baseados em tpicos, os usurios assinam e publicam eventos atravs
do tpico, que possui um conceito bastante similar ao conceito de comunicao multides-
tinatria, visto na Seo 5.2.2. Cada tpico visto como um servio de eventos nico,
identicado por um nome nico, que fornece interfaces para a utilizao das funes de
publicao e assinatura.
Tambmforampropostos sistemas pub/sub baseados emcontedo (Content-based
Pub/Sub) como uma evoluo dos sistemas de tpicos. Esses sistemas permitem a assi-
natura de eventos baseada em propriedades dos prprios eventos e no em caractersticas
estticas e previamente denidas como a identicao de tpicos. Usurios podemespeci-
car ltros para denio de suas assinaturas, utilizando restries baseadas em pares de
atributos-valores (Attribute-Value Pairs - AVPs) e operadores lgicos comparativos bsi-
cos, como =, <, >, e . Restries podem, ainda, ser combinadas logicamente atravs
de operadores AND, OR, etc., formando padres complexos de assinaturas. Tais padres
so utilizados na identicao de eventos de interesse de determinado assinante, alm de
serem usados no encaminhamento das noticaes de eventos por toda a rede. Os l-
tros conferem aos sistemas baseados em contedo uma maior liberdade na declarao de
interesses em relao aos sistemas baseados em tpicos, muito embora tenha como con-
trapartida um grande sobrecarga de comunicao dada grande sobreposio de eventos
que pode existir no caso de um interesse parcialmente declarado. Siena [Carzaniga et al.
2001] e Kyra [Cao et al. 2004] so exemplos de sistemas pub/sub baseados em contedos.
Independente da forma com a qual usurios especicam os eventos de interesse, a
arquitetura dos sistemas pub/sub pode ser classicada em centralizada ou distribuda [Eu-
gster et al. 2003]. A arquitetura centralizada opera de forma que produtores de eventos
enviam mensagens a uma entidade especca que as armazena e redireciona sob demanda
aos assinantes. Aplicaes baseadas em arquiteturas centralizadas possuem requisitos
estritos em relao disponibilidade e consistncia dos dados, j que se estruturam so-
bre uma nica entidade central. A arquitetura distribuda, por sua vez, no possui uma
entidade central responsvel por tratar interesses e noticaes, distribuindo tais respon-
sabilidades entre todos os ns do sistema. Arquiteturas distribudas so adequadas para
a entrega rpida e eciente de dados, uma vez que utilizam mecanismos de comunicao
multidestinatria. Assim, sistemas pub/sub baseados em tpicos podem beneciar-se do
conceito de comunicao em grupo, porm a comunicao multidestinatria eciente em
sistemas pub/sub baseados em contedos um grande desao j que seu desempenho
altamente afetado pelo custo computacional da ltragem de eventos para distribuio, o
qual depende diretamente da quantidade de assinaturas no sistema.
5.3. Redes Orientadas a Contedo
As redes orientadas a contedo mudam radicalmente o paradigma de comuni-
cao da Internet. Apresentando uma nova abordagem de comunicao baseada apenas
no contedo, as ROCs enfatizam o acesso informao independente de sua localiza-
o, tornando a arquitetura da rede adequada para a distribuio de contedo. As ROCs
utilizam alguns conceitos inovadores como contedo nomeado, roteamento baseado em
nomes, segurana aplicada diretamente a contedos e armazenamento de dados nos ns
intermedirios da rede [Jacobson et al. 2009a]. Por isso, este novo enfoque traz uma srie
de desaos ao desenvolvimento das ROCs, como mtodos para nomeao e roteamento
de contedos, tcnicas para proteo de contedos e usurios, planejamento e utilizao
de cache no ncleo da rede, entre outros. Nesta seo so apresentados os conceitos bsi-
cos relativos s ROCs, ressaltando suas vantagens e desvantagens. So tambm descritas
as principais arquiteturas propostas e projetos de maior destaque.
5.3.1. Nomeao de Contedos
Como visto na Seo 5.2.1, a obteno de contedo na arquitetura atual da Inter-
net, centrada em sistemas nais, implica o conhecimento de todas as partes envolvidas
nas transferncias de dados atravs de seus endereos IP. Dessa forma a obteno de um
determinado contedo requer o conhecimento a priori da sua localizao na topologia da
rede, ou seja, o conhecimento do endereo do sistema nal que o hospeda, para o esta-
belecimento posterior de uma conexo a m de que seja possvel requisitar uma cpia
do contedo. Esta caracterstica amarra de forma estrita os conceitos de identicao e
localizao de contedos.
Em se tratando de identicao de contedos, a abordagem das ROCs baseia-se
em uma premissa bastante diferente da abordagem tradicional da arquitetura centrada em
estaes. Por tratar os contedos como primitiva bsica de rede, as ROCs tornam possvel
a obteno de contedo atravs, apenas, de sua identicao ou nome, utilizando esque-
mas de nomeao de contedos, com propriedades bastante especcas. Um esquema
ideal para nomeao de contedos deve apresentar as seguintes caractersticas:
Unicidade: Garantir a identicao do contedo de forma nica, sem falsos posi-
tivos ou negativos.
Persistncia: Validar o nome do contedo em sincronismo com a validade do
prprio contedo.
Escalabilidade: Permitir sua adoo em uma variedade de cenrios, servindo a
espaos de nomes de pequeno a grande porte, no impondo limitaes quanto sua
natureza, local de armazenamento ou qualquer outra caracterstica.
Para tal, so utilizados esquemas de nomeao que permitem identicar o conte-
do e requisitar sua distribuio infraestrutura de rede de forma eciente, segura e com
alta disponibilidade. So empregadas trs tcnicas bsicas de nomeao em redes orien-
tadas a contedo: nomeao plana, nomeao hierrquica e nomeao por atributos.
5.3.1.1. Nomeao Plana
Os nomes planos podem ser entendidos por cadeias de bits de aparncia aleatria,
utilizados na identicao de contedos. Os esquemas de nomeao plana aplicados
identicao de contedos utilizam diferentes abordagens de mapeamento de contedos
em identicadores planos, sendo o mais comum a utilizao de funes hash de crip-
tograa. Devido ao fato de no possurem semntica, isto , regras para formatao ou
codicao de informaes nos identicadores, os nomes planos so persistentes, pois no
h relao direta entre localizao, propriedade ou qualquer outra caracterstica alm do
vnculo entre o contedo em si e seu nome. Por exemplo, a funo hash SHA-1
4
mapeia
palavras originais menores que 2
64
bits em chaves hash de 160 bits, utilizando diversas
operaes booleanas em blocos de bits da palavra original [Wang et al. 2005]. Tal ma-
peamento depende somente do contedo da palavra original, retornando uma palavra de
tamanho xo para diferentes comprimentos de palavras originais, composta de caracteres
sem correlao. A unicidade tambm , de certo modo, garantida, dado que as funes
hash devem conferir uma baixa probabilidade de coliso em seu mapeamento [Peyravian
et al. 1998]. Uma vez que as funes hash de criptograa retornam cadeias de bits de
comprimento xo a partir de blocos de dados arbitrrios, uma caracterstica comum s
propostas de nomeao plana o comprimento xo de seus identicadores.
Um conceito importante, possibilitado pela utilizao de nomes planos, a au-
tocerticao de contedos e seus identicadores. Utilizando-se pares de hashes crip-
togrcos no formato P:L, no qual P representa o hash criptogrco da chave pblica do
publicador [Koponen et al. 2007] ou do contedo em si [Dannewitz et al. 2010] e L rep-
resenta um rtulo arbitrrio escolhido pelo publicador, os usurios possuem meios para
vericar a validade da chave utilizada na codicao do contedo e do vnculo entre este
e seu nome [Ghodsi et al. 2011b]. Dessa forma, havendo um vnculo entre nome e chave
de criptograa dos publicadores, basta aos usurios reconhecerem o vnculo entre nome
e a identidade real do publicador para uma certicao completa dos contedos. Uma
vez que sistemas robustos e escalveis de distribuio de chaves representam problema
bastante conhecido, o uso de mecanismos semelhantes de conana externos poderia ser
aplicado nas ROCs [Ghodsi et al. 2011b]. Adicionalmente, uma vez que chaves criptogr-
cas so utilizadas na formao dos nomes planos, os mesmos tornam-se no-amigveis
ao usurio nal, sendo necessria a adoo de mecanismos externos adicionais, como
servios de busca e recomendao, para a resoluo e mapeamento entre nomes e conte-
dos em espaos de nomes privados de cada usurio [Koponen et al. 2007].
4
Disponvel em http://http://www.xorbin.com/tools/sha1-hash-calculator/.
A utilizao de nomes planos traz consigo uma caracterstica indesejvel a qual-
quer identicador de objetos em rede que a impossibilidade de agregao direta, o que
conforma um grave problema de escalabilidade para os protocolos de roteamento. No
sendo agregveis, necessrio dispor de uma entrada para cada contedo nas tabelas
de encaminhamento e roteamento, fato que visivelmente prejudicial ecincia destes
protocolos e suas implementaes.
5.3.1.2. Nomeao Hierrquica
Estruturas hierrquicas para atribuio de nomes tambm foram propostas para
utilizao em ROCs. Atravs da concatenao de diferentes componentes hierrquicos
de nome, identicadores nicos podem ser formados para atribuio a contedos. Em
oposio aos nomes gerados em um sistema de nomeao plana, os nomes hierrquicos
possuem uma caracterstica semntica, uma vez que suas estruturas e cada um dos com-
ponentes que as compem reetem alguma informao respeito da natureza do con-
tedo: propriedade, verso, formato etc. Dessa forma, estruturas semelhantes a identi-
cadores uniformes de recursos (Uniform Resource Identiers - URIs) [Mealling e Denen-
berg 2002] podem ser utilizados na representao de nomes hierrquicos.
Para obter contedo gerado dinamicamente necessrio que os usurios sejam ca-
pazes de construir, de forma determinstica, os nomes dos dados desejados sem qualquer
conhecimento prvio do nome ou contedo em si [Ghodsi et al. 2011b]. A utilizao de
nomes parciais e requisies relativas um recurso que permite determinar sequncias de
nomes de forma simplicada, explorando as relaes hierrquicas entre os componentes
do nome. Um usurio pode requisitar o contedo br.uff/video/intro.avi, por
exemplo, baseado na composio representada na Figura 5.3 e receber um pedao (chunk)
especco desse contedo, denominado br.uff/video/intro.avi/1/1. Num se-
gundo instante, esse pedao recebido pode ser utilizado para selecionar e requisitar outros
pedaos do contedo de forma relativa ao primeiro segmento obtido, como por exemplo
o pedao 3, cujo nome br.uff/video/intro.avi/1/3.
Figure 5.3. Nome hierrquico estruturado como URI.
Uma consequncia direta da utilizao de nomes hierrquicos possibilidade de
agreg-los atravs da utilizao de mapeamento de prexos longos, de forma anloga
agregao de rotas realizada pelos protocolos de roteamento IP. Dessa forma grande parte
dos mecanismos j propostos para o tratamento de endereos IP podem ser adaptados
para o tratamento de nomes hierrquicos, facilitando o processo de adoo gradativa das
ROCs e reduzindo a carga sobre os protocolos de roteamento [Jacobson et al. 2009a]. Jus-
tamente por reetir propriedades dos contedos de forma estrita, os nomes hierrquicos
no possuem uma caracterstica forte de persistncia. A semntica por trs destes nomes
no permite o uso persistente dos mesmos, uma vez que qualquer mudana hierrquica,
como a transferncia de propriedade ou de entidade publicadora do contedo deve ser
reetida nos componentes do nome.
5.3.1.3. Nomeao por Atributos
Diferentemente dos demais esquemas de nomeao apresentados, nomeao por
atributos no prov uma identicao estrita a cada um dos contedos. Pares de atribu-
tos, no formato [atributo = valor], chamados de pares valor-atributo (attribute-
value pairs - AVPs), so atribudos aos contedos e tornam possvel a sua identicao.
Por exemplo, ao invs de ser requisitado atravs de um nome explcito, um contedo
nomeado por atributos poderia apresentar a identicao [classe = "alerta",
severidade = 6, dispositivo = "web-server", tipo = "falha de
hardware]" e ser requisitado atravs das restries [severidade >2 classe
= "alerta"] [Carzaniga e Wolf 2003]. Aos conjuntos de restries que podem ser
utilizadas para identicao de contedos d-se o nome de predicados [Carzaniga et al.
2000]. H um mapeamento direto entre os predicados, seus conjuntos de restries e os
contedos por eles representados, ao qual d-se o nome de cobertura. Determinado pred-
icado cobre outro predicado se e somente se todos os contedos obtidos pelo ltimo esto
contidos no conjunto obtido pelo primeiro.
Consequncia direta da cobertura de predicados de identicao a possibilidade
de agregao de nomes. Uma vez que as restries que os denem so compostas ape-
nas por operadores lgicos e AVPs, pode-se facilmente obter predicados agregados cuja
cobertura inclui diversos subconjuntos de contedos, aliviando consideravelmente a carga
sobre os protocolos de roteamento. Outra facilidade propiciada pela nomeao por atribu-
tos possibilidade de realizar busca por contedo diretamente na rede, sem a necessidade
de aplicaes ou mecanismos externos para esse m. Uma vez que os contedos no so
nomeados explicitamente, pode-se especicar predicados que atendam a determinados in-
teresses do usurio sendo o nico objetivo vericar quais contedos seriam obtidos dessa
forma.
O uso de pares de atributos e conjuntos de restries para identicar contedos im-
plica alguns problemas s ROCs. O primeiro deles a diculdade em expressar determi-
nado conjunto de restries mnimo necessrio para a correta identicao do contedo,
gerando problemas de unicidade. Uma vez que no consegue explicitar, exatamente, o
contedo desejado, o usurio deve tratar o excesso ou falta de contedos disponibilizados
aps a solicitao, prejudicando o desempenho de suas aplicaes. No caso de disponibi-
lizao de contedo em excesso h, ainda, uso inecaz dos recursos de rede, que entregam
contedos no-desejados.
5.3.2. Roteamento de Contedos
Diferentemente das redes centradas na comunicao entre estaes, as ROCs de-
vemser capazes de entregar os contedos requisitados por nome semqualquer informao
referente localizao, tanto de usurios quanto de armazenamento de contedos. Para
tal, os ns da ROC necessitam obter informaes a respeito dos contedos existentes na
rede a m de encaminhar, da melhor forma possvel, as requisies de contedo at cpias
dos contedos requisitados. O roteamento de contedos deve apresentar as seguintes car-
actersticas:
Orientao a contedo: Endereamento de pacotes atravs da utilizao dos nomes
de contedos, sem informaes ou indicaes de remetente e destinatrio.
Robustez: Tolerncia a falhas e recuperao rpida em situaes de descontinuida-
de, evitando encaminhamento de dados a ns falhos.
Ecincia: Baixo impacto na quantidade de trfego na rede devido a informaes
de controle.
Escalabilidade: Permitir sua adoo em diferentes cenrios, servindo a topologias
de pequeno a grande porte.
Esse tipo de roteamento denominado baseado em nomes e possui uma srie de
caractersticas particulares no que tange a forma como as informaes de roteamento so
trocadas entre os ns e como tais informaes so armazenadas na rede. Os mecanismos
podem ser divididos em dois grandes grupos: roteamento no-hierrquico e roteamento
hierrquico.
5.3.2.1. Roteamento No-Hierrquico
O roteamento no-hierrquico, ou no-estruturado, no apresenta estruturas ded-
icadas ao armazenamento de informaes de roteamento ou estruturas hierrquicas para
organizao dos roteadores. Baseado no estabelecimento de enlaces sob demanda entre
os ns, de acordo com necessidades instantneas de entrega de dados, o roteamento no-
hierrquico permite que todos os ns sejam capazes de obter contedos vlidos. Como
no h um n para armazenamento centralizado das informaes de roteamento e nem
uxo determinstico dos pacotes, as informaes de roteamento devem ser difundidas en-
tre os ns em escala global, permitindo que todos calculem as melhores rotas para entrega
dos contedos, seja qual for o critrio.
Esse tipo de roteamento torna possvel a utilizao de mltiplos caminhos, uma
vez que o conhecimento do mapa completo da rede permite o clculo de rotas livres
de loops, alm de aumentar a disponibilidade da rede como um todo, pois no existe um
ponto nico de falha. Os protocolos de roteamento tradicionalmente utilizados na Internet
so, de modo geral, no-hierrquicos. Dessa forma, grande parte dos problemas encon-
trados para esses protocolos j foi identicada e solues no-hierrquicas adotadas nas
ROCs podem se aproveitar desse conhecimento prvio [Jacobson et al. 2009a, Carzaniga
et al. 2004].
5.3.2.2. Roteamento Hierrquico
No roteamento hierrquico, ou estruturado, o mecanismo de roteamento assume
que os roteadores da rede seguem uma estrutura hierrquica, garantindo um uxo deter-
minstico de informaes de roteamento e de dados. Baseados na premissa de que os
roteadores so organizados em diversos nveis, os protocolos de roteamento hierrquicos
so capazes de reduzir a quantidade de informaes de controle trafegadas na rede, pois se
aproveitamdas relaes hierrquicas existentes entre os roteadores. As ROCs apresentam,
basicamente, duas propostas de roteamento hierrquico: baseado em rvores hierrquicas
e baseado em tabelas hash distribudas (Distributed Hash Tables - DHT). O uso de rvores
hierrquicas como topologia de rede, como ilustra a Figura 5.4(a), implica a denio de
relacionamentos entre os roteadores, dependente de suas posies na hierarquia. Con-
ceitos como liao, paridade, superioridade e inferioridade so intrnsecos s estruturas
hierrquicas, os quais podem ser aplicados ao roteamento de contedo nomeado. Ns
pais so ditos aqueles que possuem conexo com um ou mais ns lhos, congurando
a raiz da subrvore qual o n lho pertence. Ns pares so todos os ns pertencentes
ao mesmo nvel hierrquico em relao a um n raiz em comum. Concentrando as in-
formaes de roteamento em ns pais, razes de subrvores, o agrupamento dos ns da
rede em nveis hierrquicos permite que cada roteador seja capaz de encaminhar dados
para elementos de seu nvel de forma direta, atravs de rotas explcitas, sendo necessrio
recorrer a um elemento de nvel hierrquico superior somente quando houver necessidade
de encaminhamento para fora do nvel [Koponen et al. 2007]. Essa caracterstica permite
agregar a carga de roteamento de toda a rede em ns pais, diminuindo a quantidade de
informaes utilizadas por cada n no clculo de rotas e, como consequncia, reduzindo
seus requisitos computacionais, como processamento e memria. No necessrio que
cada n tenha um mapa completo da rede, sendo necessrio armazenar somente as in-
formaes de roteamento dos ns lhos. Evidentemente, o n pai concentra todas as
informaes de roteamento de seus ns lhos, consistindo em um ponto nico de falha,
podendo eventualmente causar a remoo de ramos inteiros da rvore de distribuio.
(a) rvore hierrquica de domnios. (b) DHTs especcas a cada
domnio.
Figure 5.4. rvore hierrquica e uma H-DHT sobreposta topologia fsica.
As DHTs so estruturas adotadas para a distribuio de uma tabela de cdigos
hash criptogrcos entre os ns participantes. A responsabilidade da manuteno do ma-
peamento entre valores e chaves dividida entre os ns, formando uma estrutura plana
para a distribuio uniforme de carga, garantindo proteo contra pontos nicos de fal-
has [Ganesan et al. 2004]. Os mecanismos baseados em DHTs hierrquicas (Hierarchical
Distributed Hash Tables - H-DHT) permitem, ainda, o arranjo dos ns em redes sobre-
postas, encaminhando ecientemente mensagens em direo a determinadas chaves hash,
sob responsabilidade de ns especcos.As estruturas de H-DHTs garantem que todos os
ns em determinados domnios e subdomnios faam parte de uma DHT exclusiva, de
modo que nveis hierrquicos superiores so compostos por fuses de nveis mais baixos.
Por exemplo, na topologia apresentada na Figura 5.4(a), diversos nveis hierrquicos, ou
subdomnios, compem o domnio UFF. Os ns pertencentes a esta rede participam da
cada um dos subdomnios existentes, como RSDP e ES, utilizando recursos manuteno
de cada uma das distintas DHTs, como na Figura 5.4(b). Assim, o n A comunica-se to
somente com os ns B e C na DHT correspondente ao domnio RSDP, enquanto na DHT
correspondente ao domnio IC possvel comunicar-se com os ns B, C, D, E e F.
A estrutura hierrquica de uma H-DHT confere isolamento de falhas ao mecan-
ismo de roteamento uma vez que interaes entre ns de um domnio no podem ser afe-
tadas por falhas de ns externos. Adicionalmente, a distribuio de carga e funcionalidade
entre os ns em uma DHT confere aos domnios uma tolerncia a falhas internas aumen-
tada, j que falhas em ns afetam apenas uma frao do espao de chaves, permitindo
uma rpida recuperao e redistribuio de chaves entre os ns participantes [Ganesan
et al. 2004].
5.3.3. Armazenamento de Contedos (Caching)
Em semelhana s propostas de redes para distribuio de contedo na Internet
apresentadas anteriormente, as ROCs tambm representam cenrios promissores para a
aplicao de tcnicas de armazenamento de contedo nos elementos de rede (in-network
caching). Baseado na caracterstica de acesso a contedos na Internet, no qual uma
pequena parcela de contedos populares contribuem com a maior parte do trfego na
rede [Breslau et al. 1999], a replicao de contedos e disponibilizao dos mesmos
por ns da rede mais prximos aos usurios implica um grande potencial de reduo
de trfego e melhoria nos nveis de qualidade de servio [Wang 1999]. Roteadores de
contedo podem ter suas funcionalidades estendidas para prover uma infraestrutura dis-
tribuda de armazenamento, nos mesmos moldes das tradicionais CDNs. medida que
encaminha contedos a diferentes ns da rede, um roteador pode armazenar os contedos
mais frequentemente acessados em memria, operando como um cache de rede [Jacobson
et al. 2009a].
A abordagem para armazenamento de contedos nas ROCs diverge da adotada
pelas solues tradicionais de CDNs. Nas CDNs, alm de avaliar a popularidade dos
contedos atravs da quantidade de requisies feitas por usurios em escala global, os
ns operam de forma orquestrada com um gerenciamento centralizado para otimizar a
distribuio de rplicas e a utilizao de recursos. O processo decisrio de armazena-
mento de contedo nas ROCs baseia-se somente nas informaes locais de contedo,
isto , os ns utilizam apenas as requisies e contedos em trnsito na determinao do
armazenamento. Em essncia, qualquer n da rede, incluindo as estaes de usurios,
pode atuar como um cache, a qualquer instante, possibilitando estender as vantagens hoje
proporcionadas por CDNs privadas a uma rede verdadeiramente pblica e global de ar-
mazenamento e distribuio de contedos.
Apesar de no tratar a localizao do contedo de forma direta, como visto anteri-
ormente, a utilizao de armazenamento em rede acaba por distribuir cpias dos conte-
dos para ns distantes um dos outros, em termos de topologia de rede. Este cenrio pode
congurar um problema para os protocolos de roteamento uma vez que a agregao de
rotas pode tornar-se uma questo bastante complexa, impactando a distribuio tima de
informaes de roteamento.
5.3.4. Arquiteturas e Projetos em Desenvolvimento
Nesta seo algumas das principais arquiteturas propostas para as ROCs so ap-
resentadas, dando-se enfoque forma de aplicao dos conceitos apresentados anterior-
mente em cada uma das propostas, bem como os projetos que as implementam.
5.3.4.1. Content-Based Networking/Combined Broadcast and Content-Based
A arquitetura CBN(Content-Based Networking) [Carzaniga et al. 2000] uma
das propostas pioneiras para o desenvolvimento das ROCs. Fortemente baseada em con-
ceitos provenientes dos sistemas de noticao de eventos publish/subscribe. CBN im-
plementa uma arquitetura na qual contedos so publicados sem endereos explcitos de
destinatrios, entregando-os aos usurios com interesse de recebimento declarado atravs
de predicados.
Em CBN cada n anuncia rede um predicado que dene mensagens de interesse
de recebimento, chamado de predicado de receptor (receiver predicate, ou predicado-
r). Mensagens so identicadas por AVPs, apresentados na Seo 5.3.1.3, unicamente
identicados por tipo, nome e valor. Por exemplo, um conjunto de AVPs vlido se-
ria [string companhia = PET, int preo = 30]. Predicados so usual-
mente representados atravs de uma conjuntos de restries, ou ltros, sobre tais AVPs.
O predicado [string companhia = PET int preo <40], por exemplo,
caracteriza um predicado vlido correspondente mensagem representada anteriormente.
Alm do predicado-r, pode-se divulgar um predicado de emissor (sender predicate, ou
predicado-s), denindo mensagens que o usurio tem a inteno de enviar. Melhorou
Um predicado-r, ao denir o interesse por mensagens de determinado n, pode ser in-
terpretado como seu endereo de rede baseado em contedo, j que estabelece o estado
necessrio na rede para o recebimento de contedos, estabelecendo o conceito de assi-
natura. Dessa forma, as restries declaradas pelo predicado-r funcionam como ltro de
mensagens publicadas e difundidas pela rede.
Sob uma tica geral, o mecanismo de encaminhamento em CBN organizado
como uma estrutura de mapeamento entre atributos, restries e interfaces do roteador. O
mecanismo de encaminhamento implementa o uxo representado na Figura 5.5, no qual
todos os atributos encontrados nos predicados recebidos pelo roteador encontram-se es-
querda, na entrada do processo. Sobre tais atributos incidem as restries impostas pelos
predicados, conectadas s interfaces atravs de operadores booleanos. Tais operadores
implementam as conjunes de restries estabelecidas pelos predicados [Carzaniga e
Wolf 2003], estabelecendo o estado necessrio para o encaminhamento de mensagens
pelas interfaces de sada. A construo da tabela de encaminhamento propiciada pelo
Figure 5.5. Mecanismo simplicado do encaminhamento [Carzaniga e Wolf 2003].
esquema de roteamento Combined Broadcast and Content-Based (CBCB), sobrepondo
uma camada baseada em contedo sobre uma camada de difuso [Carzaniga et al. 2004].
A camada de difuso trata cada mensagem como uma mensagem para difuso global, en-
quanto a camada baseada em contedo poda dinamicamente os caminhos de distribuio,
limitando a propagao de cada mensagem baseada nos predicados declarados. A camada
de difuso garante que toda mensagem ua do n emissor a todos os receptores atravs
de caminhos sem laos e possivelmente mais curtos. Tal camada pode ser implementada
utilizando-se mecanismos conhecidos para a construo de topologias sem laos, como
mecanismos de spanning trees, rvores centradas em fontes (per-source trees) e outros
mecanismos de difuso, como encaminhamento por caminho reverso (reverse-path for-
warding).
As informaes de roteamento em CBCB so propagadas atravs de dois mecan-
ismos distintos: o envio de anncios pelos receptores (receiver advertisements - RAs) e a
requisio de emissores (sender requests - SRs). RAs so emitidos por todos os ns, pe-
riodicamente ou toda vez que o mesmo altera seu predicado-r. RAs transportam os novos
predicados dos receptores, propagando tais informaes a todos os potenciais emissores,
estabelecendo os estados de encaminhamento necessrios para a correta distribuio de
mensagens aos ns de interesse. Toda vez que recebe umRAemdada interface, o roteador
de contedos verica se o endereo anunciado coberto pelo predicado da interface re-
ceptora do RA. Em caso positivo, o RA e o ltro anunciado so descartados. Em caso
negativo, o roteador computa o conjunto de interfaces pertencentes rvore centrada no
n emissor do RA, encaminhando o RA a tais interfaces e estabelecendo caminhos para
o uxo de mensagens. Uma ltima etapa envolve a atualizao da tabela de roteamento
em que o ltro apontado pelo RA includo ao predicado da interface receptora atravs
da conjuno lgica dos endereos.
Os SRs so utilizados pelos roteadores para buscar informaes sobre todos os
receptores a m de atualizar sua tabela de roteamento. Ao receber um SR, os ns o re-
spondem com update replies (URs), contendo todos os predicados de suas interfaces. O
recebimento de um SR implica o encaminhamento imediato do mesmo a todas as inter-
faces participantes na rvore de difuso centrada no emissor do SR. Assim, os ns que
replicaram o SR somente enviam o UR em resposta ao emissor original aps o recebi-
mento de todos os URs pelas interfaces utilizadas na retransmisso ou com o estouro de
um contador de tempo. O protocolo permite, ainda, que os roteadores faam o armazena-
mento e reuso de URs em situaes especcas, porm bastante comuns, como no cenrio
em que todos os ns receptores de determinada interface sejam os mesmos ns receptores
da rvore de difuso centrada no n emissor do SR original. Essa modicao permite
reduzir a quantidade de trfego de controle e de processamento nos roteadores.
As primeiras implementaes da arquitetura, desenvolvidas para a avaliao de
desempenho dos conceitos propostos em CBN [Carzaniga e Wolf 2003, Carzaniga et al.
2004], indicam resultados promissores dos mecanismos de encaminhamento e rotea-
mento. O mecanismo de busca e encaminhamento de contedos apresenta desempenho
aceitvel mesmo na presena de milhes de restries possveis para aplicao. Os resul-
tados experimentais obtidos com o protocolo de roteamento CBCB indicam sua capaci-
dade em entregar, efetivamente, todo contedo de interesse dos usurios. A identicao
de contedos atravs de AVPs, como visto na Seo 5.3.1.3, gera uma diculdade de
expresso de nomes de contedos com unicidade, dada a possibilidade de cobertura dos
predicados. Dessa forma, as implementaes apresentaram uma taxa de falsos positivos
aceitvel, que geram o overhead constante de aproximadamente 10% do trfego de men-
sagens. Adicionalmente, propriedades interessantes foram observadas, como intensidade
de trfego de controle proporcional taxa de mudana de predicados e diminuio dos
requisitos de memria dos ns devido ao uso de armazenamento e reuso de URs, con-
ferindo alguma escalabilidade arquitetura.
5.3.4.2. Data-Oriented Network Architecture
DONA (Data-Oriented Network Architecture) [Koponen et al. 2007] uma ar-
quitetura baseada nos conceitos clean-slate
5
de nomeao e localizao de contedos
para a distribuio persistente e convel dos mesmos em uma rede hierrquica. DONA
propicia persistncia e autenticidade atravs da utilizao de nomes planos e autocerti-
cadores. A alta disponibilidade conferida pelo mecanismo de localizao de contedos,
guiando as requisies de contedos s cpias com menor custo de obteno, evitando
ns falhos ou sobrecarregados.
Em DONA todo nome gerado por um outorgante, entidade associada a um par
de chaves pblico-privadas as quais so utilizadas na identicao dos contedos. Essa
associao fundamental na formao dos nomes de contedos em DONA. Nomes ap-
resentam o formato P:L, em que P representa o hash criptogrco da chave pblica do
outorgante e L um rtulo arbitrrio escolhido pelo mesmo, de modo que o nome de cada
contedo seja nico em seu domnio. Os outorgantes possuem papel de publicadores e
administradores de contedo, uma vez que somente ns autorizados pela chave P podem
prover acesso a objetos nomeados do tipo P:L. Uma vez que todo usurio, ao requisitar
um contedo P:L ir receber como resposta o contedo composto pelos dados, chave
pblica de P, o rtulo L, metadados e uma assinatura do contedo [Ghodsi et al. 2011b],
pode-se imediatamente checar a autenticidade do publicador dos dados vericando-se que
o hash da chave pblica , de fato, P e que a mesma foi utilizada na assinatura do con-
tedo. A utilizao de nomes planos acarreta a diculdade de associao dos nomes de
5
O termo em ingls refere-se proposio de ideias inovadoras, desconsiderando tcnicas e/ou conceitos
pr-concebidos e rompendo com as tecnologias atuais.
contedo pelos usurios. A arquitetura considera como premissa o fato de que usurios
obtm nomes atravs de diversos mecanismos externos rede, como sistemas de busca,
comunicao privada, servios de recomendao, e demais sistemas de recomendao e
conana utilizados pelos usurios.
O mecanismo de resoluo de nomes, isto , de roteamento de requisies de
contedo nomeado, implementado em ns denominados manipuladores de registros
(register handlers - RHs), que implementam um protocolo bastante simples e ecaz. Pa-
cotes FIND(P:L) so enviados ao RH local para localizar determinado objeto P:L,
que por sua vez encaminha a solicitao s cpias mais prximas do contedo. Men-
sagens REGISTER(P:L), por sua vez, estabelecem o estado necessrio para que RHs
encaminhem os pacotes FINDs de forma ecaz. Ns devidamente autorizados pelo out-
organte tambm podem enviar pacotes REGISTER(P:
*
) a seu RH local. Dessa forma,
independente do rtulo L utilizado, toda requisio de contedos sob reponsabilidade do
outorgante P ser encaminhada pelo RH local do n que registrou P:
*
. Os RHs man-
tm entradas separadas na tabela de registros para P:
*
e P:L, mapeando de forma dis-
tinta os prximos saltos para cada uma das entradas. A existncia de entradas na tabela
de registros crucial no encaminhamento dos pacotes FIND s cpias mais prximas
do contedo. No havendo uma entrada pertinente na tabela o RH encaminha o pacote
FIND ao RH de nvel hierrquico superior, eventualmente encontrado uma entrada vlida
na tabela de registros, uma vez que RHs de nveis hierrquicos superiores concentram as
informaes de roteamento de seus RH lhos (ou subdomnios), funcionando como uma
espcie de gateway padro. DONA, em semelhana arquitetura apresentada em CBN,
na Seo 5.3.4.1, no prev o rompimento por completo com o IP. O pacote FIND car-
acterizado por sua insero entre os cabealhos IP e da camada de transporte, limitando-
se resoluo dos endereos de contedos. Assim, os mecanismos convencionais de
transporte so acionados para a realizao da entrega dos contedos partir de cpias ar-
mazenadas na rede, apenas orientando tais mecanismos a nomes, sem maiores mudanas
nos protocolos e infraestrutura que os suportam.
A seleo automtica de servidores, uma das funcionalidades desejadas em qual-
quer sistema de distribuio de contedos, pode ser obtida de forma nativa em DONA.
RHs podem optar pelo encaminhamento de FINDs a vizinhos de menor custo, segundo
a mtrica de roteamento em DONA. Multi-homing e mobilidade so, tambm, carac-
tersticas intrnsecas a DONA. FINDs podem ser encaminhados a mais de um RH por
um n multi-homed, resultando na utilizao de mltiplos caminhos para obteno de
contedo. O protocolo de registro de contedos, baseado nas mensagens REGISTER e
UNREGISTER, o responsvel por conferir mobilidade aos sistemas nais, j que antes
da mudana de posicionamento do host na topologia de rede, o mesmo deve cancelar os
registros de seus endereos de contedo e registr-los novamente em sua nova localidade.
Dessa forma, assim que os novos registros tiverem sido divulgados e estabelecido o estado
de encaminhamento necessrio, todos os FINDs sero roteados a essa nova localidade.
A distribuio de contedo no formato multicast , tambm, realizada de forma nativa j
que a utilizao de identicadores P:L, com o rtulo arbitrrio L representando a iden-
ticao de um grupo multicast do tipo (S,G), permitem a criao de grupos centrados
em fontes especcas, similar implementao da comunicao multicast SSM (Source-
Specic Multicast) [Bhattacharyya 2003, Holbrook e Cain 2006].
Algumas extenses opcionais a DONA foram propostas, intensicando seu im-
pacto na distribuio de contedos. A utilizao de cache nos RHs estendem suas fun-
cionalidades, implementando uma infraestrutura genrica e sempre disponvel nos camin-
hos de distribuio para o armazenamento de contedos, conferindo ganhos de qualidade
de servio no acesso de contedos. Mecanismos de assinatura de contedos e noticao
de atualizaes atravs de FINDs de longa durao, isto , adicionados de TTLs (time-to-
live). Enquanto o FIND for vlido, atualizaes pertinentes ao contedo desejado sero
enviadas em direo ao host interessado. Outra funcionalidade desejvel a capacidade
de se evitar servidores falhos ou sobrecarregados no provimento de contedos. Ao enviar
REGISTERs rede, tais ns podem incluir informaes a respeito de carga e proces-
samento, facilitando a tomada de decises relativas a encaminhamento de FINDs pelos
RHs.
5.3.4.3. Content-Centric Networking/Named-Data Networking
CCN (Content-Centric Networking) [Jacobson et al. 2009a] uma arquitetura de
ROC baseada na utilizao do contedo como objeto elementar da rede, tratando questes
como alta disponibilidade e segurana de contedos, independente da localizao. CCN,
em analogia s propostas j apresentadas, preserva alguns dos conceitos do TCP/IP que
o tornaram simples, robusto e escalvel, estendendo-os para prover uma camada de rede
exvel, com poucas restries camada de enlace.
Uma das principais caractersticas em CCN a diviso dos contedos em pedaos
(chunks), estruturas nomeadas com identicadores nicos e hierrquicos, requisitados
de forma individual. Os nomes so compostos por varivel nmero de componentes,
exatamente como apresentado na Seo 5.3.1.2. Cada componente formado por um
nmero arbitrrio de octetos, sem qualquer signicado camada de transporte, podendo
ser, inclusive, criptografados. Uma vantagem direta da utilizao de nomes hierrquicos
a possibilidade de agregar nomes fazendo-se referncia aos ns razes da rvore hi-
errquica. A estruturao do nome em forma hierrquica permite, ainda, a expresso do
posicionamento dentro da estrutura hierrquica, denindo inclusive o posicionamento rel-
ativo a outros ns da rvore de nomes. Em uma rvore de nomes, como a representada
na Figura 5.3, pode-se requisitar contedo por relacionamentos. Caso um usurio queira
a verso anterior do contedo, por exemplo, o usurio pode solicit-la atravs do iden-
tifcador br.uff/video/intro.avi/1/anterior. Se quer o prximo pedao,
pode solicit-lo usando br.uff/video/intro.avi/1/1/posterior. Dados sat-
isfazem ao interesse declarado rede caso o nome do contedo no pacote de interesse for
um prexo do nome do pacote de dados. Isso equivale a dizer que o pacote de dados est
na subrvore de nomes especicados pelo pacote de interesse.
Aarquitetura CCN baseada emduas primitivas bsicas: a declarao do interesse
por determinado chunk e o envio deste em resposta ao interesse. Usurios requisitam
contedo diretamente rede difundindo seu interesse por determinado chunk, na forma de
pacote de interesse (interest packet, ou I-packet), em todas as interfaces disponveis. Ns
vizinhos respondem ao I-packet enviando como resposta o pacote de dados (data packet,
ou D-packet) caso o tenham armazenado em memria. Caso contrrio encaminham o
I-packet aos seus vizinhos at que, eventualmente, o interesse encontre um n com o
dado armazenado. Dados so somente enviados como resposta a interesses, consumindo
o interesse pendente equivalente em cada n no caminho reverso, estabelecendo uma
espcie de balano entre requisies e atendimento.
Figure 5.6. N CCN e estruturas do mecanismo de encaminhamento [Jacobson
et al. 2009a].
O encaminhamento de pacotes realizado pelos ns em CCN fortemente derivado
do IP, consistindo do bsico mapeamento entre nome do contedo e interface associada
rvore de distribuio do pacote, com algumas caractersticas especiais. Cada roteador
utiliza trs estruturas distintas nas operaes de encaminhamento de pacotes: o CS (Con-
tent Store), a PIT (Pending Interest Table) e a FIB (Forwarding Information Base), ilustra-
dos na Figura 5.6. AFIB uma base de dados utilizada no armazenamento de informaes
de encaminhamento de pacotes, realizando o mapeamento entre nomes de contedo e uma
ou mais interfaces para encaminhamento, permitindo a utilizao de mltiplas fontes de
forma nativa. CS a estrutura de cache do roteador em CCN, rea de armazenamento de
chunks pelo tempo mais longo possvel, utilizando polticas de atualizao de cache sim-
ilares a LFU ou LRU [Podlipnig e Bszrmenyi 2003]. A PIT uma tabela na qual so
armazenados os interesses encaminhados adiante, registrando a interface de origem para
que os dados enviados como resposta possam ser encaminhados em direo ao solicitante.
Ao receber um I-packet, o roteador primeiro checa em seu CS a existncia de uma entrada
para o nome requisitado. Em caso positivo, envia como resposta o D-packet relativo. No
caso de no haver uma entrada armazenada no CS o roteador verica se j h um interesse
pendente na PIT. Em caso positivo, a interface de recebimento do I-packet adicionada
a lista de interfaces para encaminhamento do contedo na PIT e o I-packet descartado.
Caso no haja entrada na PIT, o roteador encaminha o pacote de acordo com as regras de
sua FIB, criando na PIT um registro da interface de origem. Caso no haja entrada na FIB
para determinado contedo realizado o descarte do interesse, uma vez que no h rota
vlida para o mesmo. Esse encaminhamento difuso visa encontrar, eventualmente, um n
que possa atender solicitao e enviar o pacote de dados no caminho reverso, sinalizado
pelas entradas das PITs. Somente uma entrada na PIT valida a admisso de D-packet pelo
roteador, com todos os outros cenrios levando ao descarte do pacote. necessrio que as
fontes de dados registrem sua inteno de prover determinados contedos, atravs de uma
primitiva de registro (register), criando o estado de encaminhamento inicial necessrio
para o envio de interesses s fontes.
A camada de estratgia implementa o mecanismo decisrio de encaminhamento
de pacotes que atua na FIB, determinando dinamicamente a forma como um roteador en-
caminha os pacotes de interesse. Diferentemente do TCP, em CCN cabe camada de
estratgia do receptor requisitar contedos no entregues ou corrompidos. O controle de
uxo tambm implementado pela camada de estratgia, uma vez que o envio de mlti-
plos pacotes de interesses em paralelo endereados a chunks sequenciais possui funo
equivalente janela TCP, controlando a quantidade de trfego que pode ser inserida na
rede pelas fontes de dados.
Dadas as caractersticas de nomeao e encaminhamento presentes emCCN, qual-
quer esquema de roteamento por estado de enlace vlido para IP possui uso potencial em
CCN. O mecanismo de encaminhamento de CCN no impem restries quanto ao uso
de mltiplas fontes ou destinos, uma vez que a utilizao da PIT impede a formao
de laos na rede. A utilizao de nomes hierrquicos, com semntica semelhante dos
endereos IP, confere agregabilidade aos endereos de rede em CCN, aplicando-se o mes-
mos mecanismo de casamento do maior prexo (longest prex match).
CCN aplica conceitos de segurana diretamente aos contedos, independente dos
mecanismos de segurana adotados pelos meios de transporte. A autenticao do vnculo
entre nome e dados obtido pela assinatura do publicador do contedo sobre o nome e os
dados do contedo. O vnculo entre nome e contedo permite que publicadores atribuam
nomes arbitrrios s suas publicaes e as torna facilmente autenticveis, pois qualquer
n da rede pode avaliar se o vnculo entre nome e contedo foi assinado por determinada
chave. A determinao do mecanismo de autenticao de vnculo pode variar entre difer-
entes conjuntos de publicadores e usurios, criando uma exibilidade de adequao dos
recursos computacionais de acordo com a necessidade de cada aplicao. Pode-se, ainda,
distribuir a carga computacional de autenticao entre vrios pacotes, apesar de pacotes
serem pensados como autenticveis individualmente. A validao do vnculo simples-
mente sinttica, isto , valida-se que a chave foi utilizada na assinatura do contedo sem
inserir nenhum signicado a ela, como propriedade ou critrios para conana na chave.
A arquitetura proposta em CCN a base para o desenvolvimento do projeto NDN
(Named Data Networking) [Zhang et al. 2010]. O projeto NDN visa desenvolver as tc-
nicas complementares necessrias plena adoo das ROCs, abordadas na proposio
da CCN. Questes como o roteamento global, o encaminhamento eciente de contedo
nomeado, o desenvolvimento de aplicaes, as tcnicas de segurana e privacidade, en-
tre outras, fazem parte da agenda de pesquisa do projeto. O projeto NDN possui um
testbed com 11 ns distribudos pelos principais centros de pesquisas dos Estados Unidos.
Usurios conectam-se ao testbed via tneis UDP, estendendo o alcance da ROC a todo o
campus e s redes domiciliares dos usurios.
5.3.4.4. Publish-Subscribe Internet Routing Paradigm/Publish-Subscribe Internet Tech-
nologies
O projeto Publish-Subscribe Internet Routing Paradigm (PSIRP) [Lagutin et al.
2010], de encontro s demais propostas de ROCs, especica uma arquitetura de ROC sem
aplicar tecnologias de conectividade e transporte existentes, como o TCP/IP. Fortemente
baseada nas primitivas de redes publish/subscribe, PSIRP dene as publicaes (como
so chamados os contedos) como associaes persistentes entre identicadores e dados
criados pelo publicador. Identicadores autocerticveis so utilizados neste vnculo en-
tre nome e contedo, na forma de hashes, uma vez que cada publicao possui um nico
publicador lgico.
PSIRP utiliza o conceito de rendezvous
6
[Visala et al. 2009] para implementar
a resoluo de nomes de contedos. Publicadores anunciam contedo em redes de ren-
dezvous locais, que realizam a associao de fontes de dados e assinantes interessados
no contedo armazenado. Publicadores anunciam os escopos (Scope ID - S
id
), identi-
cadores relacionados aos contedos que autorizam sua distribuio por outras fontes
de dados. Fontes de dados so ns de armazenamento, localizadas nas extremidades da
rede que utilizam o sistema de rendezvous para a divulgao dos contedos existentes, o
identicador de rendezvous (Rendezvous ID - R
id
). Dessa forma, todo contedo deve ser
solicitado atravs do uso da dupla de identicadores S
id
, que direciona a forma de dis-
tribuio autorizando determinadas fontes, e R
id
, indicando a publicao desejada neste
escopo. S
id
e R
id
utilizam pares de identicadores "P:L" em que P a chave pblica do
proprietrio do espao de nomes e L um rtulo arbitrrio da publicao. As redes locais
de rendezvous so interligadas atravs da interconexo de rendezvous (Rendezvous Inter-
connect - RI), uma DHT hierrquica com presena em todos os domnios da arquitetura
PSIRP, que permite resolver S
id
s e R
id
s de contedos disponveis em domnios distintos.
A resoluo dos identicadores de uma publicao na RI devolve ao usurio a in-
dicao de ns de ramicao (Branching Nodes - BNs) da rvore de distribuio relativa
publicao. A requisio de assinatura da publicao , ento, encaminhada atravs dos
diversos domnios de PSIRP, utilizando rotas para os BNs corretos, como na Figura 5.7.
O sistema de roteamento responsvel pela determinao e manuteno da rvore de
entrega de cada publicao e pelo processo de armazenamento de contedos populares
na rede. Os BNs selecionam as rotas para novas assinaturas baseados nas informaes de
topologia da rede e de mtricas obtidas a partir de medidas de intensidade de trfego, obti-
das por um sistema distribudo de gerenciamento topolgico, alm de gerenciar grandes
caches e realizar a ramicao das rvores de distribuio quando h mltiplas requi-
sies, semelhante ao multicast.
O sistema de encaminhamento [Jokela et al. 2009] encarrega-se da entrega das
publicaes aos assinantes atravs de rvores de entrega ecientes. Os ns de encamin-
hamento (Forwarding Nodes - FNs) entregam pacotes atravs do mapeamento da rvore
de distribuio da publicao e um identicador de encaminhamento (Forwarding ID -
F
id
) e utilizam de tais F
id
s no encaminhamento. F
id
s so identicadores baseados em l-
tros de Bloom construdos pelo sistema, numa espcie de roteamento pela fonte. Uma vez
6
Termo em francs para a palavra encontro.
Figure 5.7. Arquitetura simplicada adotada em PSIRP [Lagutin et al. 2010].
que todos os enlaces possuem uma identicao (Link ID), tambm um ltro de Bloom,
possvel codicar a rvore de entrega atravs de um ltro e utiliz-lo como F
id
para
encaminhamento. Cada FN na rvore de entrega do contedo realiza uma simples oper-
ao lgica AND no link ID de sada e no ltro de Bloom no cabealho do pacote. Se o
resultado da operao for o prprio link ID, assume-se que o mesmo faz parte da rvore
de entrega e o pacote encaminhado pela interface correspondente. Esse mecanismo
sujeito a falsos positivos na identicao de interfaces de encaminhamento, causando o
envio do pacote a ns que, na verdade, no participam da rvore. Um exemplo deste
mecanismo representado na Figura 5.8.
Figure 5.8. Exemplo do encaminhamento de dados adotado em PSIRP [Jokela
et al. 2009].
Baseado nos conceitos levantados pela proposio da arquitetura PSIRP, o pro-
jeto PURSUIT (Publish / Subscribe Internet Technologies) [Fotiou et al. 2010] foi criado
com o objetivo de explorar e renar ainda mais a proposta da PSIRP. Mobilidade, pri-
vacidade, armazenamento em rede e contabilizao so temas de grande importncia no
desenvolvimento do projeto. Um dos principais objetivos do projeto PURSUIT o desen-
volvimento de solues e mecanismos aplicveis criao e oferta de servios inovadores,
aproveitando todo o potencial dessas novas estruturas de informao. A identicao al-
gortmica de contedos um conceito explorado em PURSUIT atravs de novas tcnicas
de fragmentao do contedo e armazenamento distribudo eciente. A natureza da ar-
quitetura em PURUSIT, recursiva e hierrquica, permite gerenciar mobilidade de forma
nativa, orientada ao n mvel, de forma transparente ao ncleo da rede. Assim, suporte
a mobilidade um dos tpicos de interesse no desenvolvimento do projeto. Mecanismos
de autenticao e contabilizao devem ser estendidos para suportar os sistemas de PUR-
SUIT. Questes relacionadas ao gerenciamento de politicas de topologia, roteamento e
encaminhamento, em todos os nveis da arquitetura, requerem o desenvolvimento de uma
plataforma de gerenciamento global. O projeto PURSUIT possui um testbed com servi-
dores dedicados localizados em diversas instituies americanas e europeias, executando
mais de 25 ns da rede PURSUIT simultaneamente.
5.3.4.5. Demais arquiteturas
Alm das arquiteturas apresentadas, outras tambm foram propostas visando a im-
plementao das ROCs. TRIAD [Cheriton e Gritter 2000], NetInf [Ahlgren et al. 2008]
e MultiCache [Katsaros et al. 2011] so bons exemplos. TRIAD foi a arquitetura pi-
oneira a propor a comunicao baseada em contedos, utilizando as URLs presentes
nas requisies HTTP como nome de contedos. TRIAD realiza o redirecionamento
das requisies para cpias mais prximas, conceitualmente bastante prxima das CDNs,
implementado a camada de contedo e armazenamento em todos os roteadores de con-
tedo. NetInf, proposta pelo projeto 4WARD
7
, utiliza conceitos em comum com DONA
e PSIRP/PURSUIT, como nomes planos e roteamento baseado em DHT. NetInf propi-
cia o uso de identicadores persistentes, como apresentado na Seo 5.4.1 e a separao
entre publicao e dados, permitindo a utilizao de mltiplas verses da mesma publi-
cao. MultiCache explora a comunicao multidestinatria como meio de distribuio
de contedo, implementando uma rede sobreposta baseada em Pastry [Rowstron e Dr-
uschel 2001] para o armazenamento de contedo em rede, localizao de rplicas na rede
e distribuio do contedo em si.
5.3.4.6. Comparativo Geral
A Tabela comparativa 5.1 apresenta as principais caractersticas de cada uma das
arquiteturas apresentadas. CBN, por utilizar AVPs na nomeao de contedos, permite
a busca em rede e assinatura prvia de contedos ainda no publicados. Porm, como
todos os atributos existentes podem ou no ser utilizados na identicao de contedos,
as tabelas de roteamento acabam por sofrer impacto considervel, da ordem de 2
A
, onde
A representa a quantidade total de atributos, diretamente relacionada com expressividade.
Adicionalmente, todas as mudanas de predicados no cobertos devem ser difundidas por
7
http://www.4ward-project.eu/
Table 5.1. Tabela comparativa geral.
Caracterstica CBN DONA CCN/NDN PSIRP/PURSUIT
Nomeao Plana X X
Nomeao Hierrquica X
Nomeao por AVPs X
Roteamento Estruturado X X
Roteamento No-estruturado X X
Caching em rede X X X
Segurana intrnseca de contedos X X
toda a rede, impactando consideravelmente na quantidade de trfego de controle.
Em DONA, por sua vez, utiliza-se nomeao plana de contedos, o que confere
persistncia e unicidade de identicadores. Como a arquitetura utiliza uma estrutura hi-
errquica de roteamento, denindo uxos sistemticos e centralizao das informaes
de roteamento, o impacto do trfego de controle na rede no tende a ser signicativo.
O uso de identicadores no-agregveis, porm, implica na utilizao de uma entrada
por contedo nas tabelas de roteamento, caracterizando um ponto crtico no que tange a
escalabilidade.
J os projetos CCN/NDN so baseados em estruturas hierrquicas de nomeao,
conferindo agregabilidade aos nomes de contedo. O mecanismo de difuso de interesses,
porm, impacta consideravelmente na quantidade de trfego de controle na rede. O uso
de cache, ainda, distribui os contedos mais prximos da borda da rede, dicultando
o processo de agregao de rotas. Ao adotar princpios de design semelhantes ao IP,
CCN/NDN permitem a adoo de mecanismos legados, comprovadamente funcionais,
para uma adoo gradual e eventual substituio de tecnologia.
PSIRP/PURSUIT, em semelhana a DONA, nomeia seus contedos com iden-
ticadores planos, conferindo as mesmas propriedades de persistncia e unicidade. A
estrutura de DHT hierrquica do sistema de rendezvous permite distribuir a carga de
roteamento entre todos os domnios participantes, normalizando os requisitos computa-
cionais dos ns da rede. Pormao romper totalmente comos conceitos provenientes do IP,
PSIRP/PURSUIT institui uma arquitetura clean slate, dicultando sua adoo em escala
global.
5.4. Desaos
A pesquisa relativa s ROCs, apesar de bastante recente, apresentou uma srie de
avanos e proporcionou uma gama de solues para diferentes questes. Porm, ainda h
diversos problemas em aberto e aspectos prticos de implementao que necessitam de
denies mais bem estudadas e detalhadas. Esta seo discute alguns desses desaos e
indica possveis rumos para os quais o desenvolvimento das ROCs pode ir ao encontro.
5.4.1. Nomeao de Contedos
Todos os conceitos propostos para as ROCs tornaram-se viveis graas a uma pre-
missa bsica: a utilizao de contedos nomeados como primitiva bsica de rede. Por ser
o alicerce de todas as arquiteturas vistas na Seo 5.3.4, o desenvolvimento dos mecan-
ismos de identicao ou nomeao de contedos representam um grande desao para
a adoo das ROCs. Mecanismos distintos para nomeao de contedos foram propos-
tos, como visto na Seo 5.3.1, podendo ser agrupados em trs classes bsicas: nomes
planos, hierrquicos e baseados em atributos [Choi et al. 2011]. Cada uma das classes de
nomes atende parcialmente os requisitos exigidos dos mecanismos de nomeao, como
persistncia, escalabilidade e inteligibilidade ao usurio nal. o caso, por exemplo, da
nomeao hierrquica que escalvel, mas possui restries ao uso persistente dos nomes.
Existem, ainda, questes relativas segurana das ROCs que permeiam a nomeao dos
contedos, porm tais aspectos so tratados na Seo 5.4.4.
A principal crtica feita nomeao plana o fato de que a ausncia de hier-
arquia acarreta problemas de escalabilidade. Ghodsi et al., entretanto, alegam que a
falta de hierarquia dos nomes planos no impede a agregao explcita de nomes [Gh-
odsi et al. 2011b]. Utilizando-se de nomes planos nicos, no j citado formato P:L,
pode-se formar identicadores agregados atravs da concatenao de nomes na forma
nome
1
.nome
2
.nome
3
...nome
n
, em que cada componente nome
i
um nome plano
individual. Dessa forma, no so necessrias quaisquer mudanas nas tabelas de rotea-
mento. As tabelas possuementradas individuais para cada umdos nomes, possibilitando o
encaminhamento individual de cada contedo pelo roteador. Porm, quando confrontado
com concatenaes de nomes, o roteador realiza o encaminhamento baseado no casa-
mento mais especco (deepest match). Assim, a busca por entradas casadas na tabela de
roteamento inicia-se pelo nome de nvel mais baixo, da direita para a esquerda. Suponha
um nome concatenado na forma A.B.C, no qual A, B e C so nomes planos individuais.
Nesse caso, a primeira entrada a ser buscada relativa ao nome C). No havendo uma rota
especca para C, o mecanismo executa o mesmo procedimento para B e, em ltima caso,
utiliza-se a rota de nvel mais alto para A. De forma anloga aos nomes hierrquicos, a
concatenao de nomes planos pode ser utilizada para representar contedo estruturado.
Por exemplo, no identicador agregado A.B.C, A pode representar todo o contedo agre-
gado de determinado publicador, B pode representar um grande arquivo e C, por sua vez,
um determinado pedao (chunk) que o compe. A agregao explcita de nomes planos
confere uma caracterstica de hierarquia virtual ao mecanismo de nomeao plana. Ela
tambm permite que um mesmo nome seja agregado de diversas formas distintas ao con-
trrio da agregao caracterstica da nomeao hierrquica que permite somente a agre-
gao de nomes em prexos de nveis hierrquicos maiores.
Se o desao para mecanismos de nomeao plana ser capaz de agregar nomes, o
desao para os mecanismos de nomeao hierrquica garantir a persistncia dos nomes.
A capacidade de agregao intrnseca dos nomes hierrquicos tanto contribui para a escal-
abilidade quanto diculta o uso persistente de nomes nas arquiteturas baseadas em nomes
hierrquicas. A escalabilidade proporcionada pela potencial reduo do tamanho e dos
tempos de atualizao das tabelas de roteamento. Tambm h unicidade de prexos,
garantindo o roteamento por prexos atravs de mecanismos de casamento do maior pre-
xo, como o usado por protocolos de roteamento da Internet atual. A persistncia preju-
dicada justamente porque os nomes hierrquicos reetem propriedades dos contedos de
forma explcita. Assim, qualquer mudana hierrquica como, por exemplo, transferncia
de propriedade ou de entidade publicadora do contedo, deve ser reetida nos compo-
nentes do nome.
Os nomes planos, no formato P:L, em geral, tambm no conferem persistncia
plena aos nomes, pois a chave pblica do publicador utilizada na gerao do nome.
Dessa forma, o nome est atrelado propriedade do contedo. Assim, uma mudana
de proprietrio implica mudana da chave P e consequentemente mudana de nome do
contedo. A arquitetura NetInf especica uma soluo para a utilizao de nomes planos
efetivamente persistentes. Para tanto, a NetInf desatrela os nomes do conceito de pro-
priedade [Dannewitz et al. 2010]. So propostas duas abordagens para prover tal inde-
pendncia. Na abordagem mais simples, os nomes planos, diferentemente do apresentado
na Seo 5.3.1.1, possuema componente de hash constituda por uma chave pblica PK
IO
,
atrelada ao contedo em si e no a um publicador ou outorgante, resultando no identi-
cador PK
IO
:L. Sempre que houver uma mudana sobre a posse do contedo, a chave sec-
reta SK
IO
deve ser passada ao novo proprietrio atravs de um canal seguro, permitindo
que as publicaes sejam assinadas utilizando a mesma chave. A abordagem mais com-
plexa prev a utilizao de novos pares PK/SK sempre que o proprietrio do contedo for
alterado. Para que o nome continue vlido, isto , mantenha sua persistncia, o hash da
chave pblica original PK
IO
permanece inalterado no nome do contedo. Porm, o novo
proprietrio assina o contedo com sua chave privada SK
latest
, inserindo a informao
em metadados vericveis atravs de PK
latest
. O par PK
latest
/SK
latest
autorizado pelo
par de chaves originais PK
IO
/SK
IO
atravs de uma cadeia de certicados [Clarke et al.
2001]. A cadeia de certicados consiste da autorizao de um par de chaves pblico-
privada atravs da utilizao de um certicado pai. A relao entre os diversos nveis
hierrquicos de certicados estabelece uma cadeia de conana, denominada caminho de
certicao. Para garantir a validade da assinatura digital inserida nos metadados e da
autenticao do vinculo entre PK
latest
e SK
IO
, todo o caminho de certicao deve ser
vericado para a obteno do certicado raiz original, assinado por PK
IO
.
Existe um consenso em relao s caractersticas desejveis dos mecanismos de
nomeao, mais especicamente em relao unicidade, autocerticao e inteligi-
bilidade pelos usurios, informalmente conhecido como Tringulo de Zooko
8
. Embora
no haja uma prova formal, tal consenso arma que qualquer mecanismo de nomeao
pode apresentar at duas das trs caractersticas citadas, porm no as trs simultanea-
mente. Os conceitos apresentados na Seo 5.3.1 corroboram tal viso, uma vez que
nenhum dos mecanismos de nomeao aplicados s ROCs apresentam todas as carac-
tersticas simultaneamente. At mesmo os nomes hierrquicos, que eventualmente espel-
ham as caractersticas das URLs, podem ser baseados em componentes no-amigveis
aos usurios. O uso de nomes no-amigveis implica o uso de mecanismos externos
para a resoluo e obteno de identicadores, como mecanismos de busca e redes de
recomendao [Koponen et al. 2007].Como alternativa aos mecanismos centralizados
para resoluo de endereos, so propostos mecanismos de nomeao pessoal, atuando
como abstraes amigveis aos diversos mecanismos de nomeao utilizados na Inter-
net, como o Pnames [Allman 2007]. Allman arma que a utilizao de um espao de
nomes pessoal permite a identicao de recursos atravs de apelidos locais, amigveis
ao usurio, sem maiores requisitos quanto unicidade. Nomes podem ter distintos sig-
8
Disponvel em ttp://www.zooko.com/distnames.tml
nicados em cada um dos espaos de nomes, uma vez que so diretamente administrados
pelos usurios. Tais espaos inserem uma camada de abstrao de nomes, cujo mecan-
ismo bsico o mapeamento de identicadores de recursos de rede em espaos de nomes
distintos, prprios ou no, dependendo do contexto. O compartilhamento de pores dos
espaos de nomes pode ser direto, atravs de trocas entre indivduos, ou atravs de uma
base centralizada que aberta a consultas e edio das entradas pblicas e privadas e
que pode ser acessada por todos os usurios. Outra abordagem que visa a no-utilizao
de mecanismos externos de resoluo a utilizao de nomes hierrquicos atribudos
pelos provedores de acesso [Zhang et al. 2010], muito semelhante atribuio de en-
dereos IP, porm sem a limitao no tamanho dos identicadores. Dessa forma, um
recurso disponibilizado por um usurio atendido por determinado Provedor A poderia
ser nomeado /provedor/users/usuario/conteudo. Apesar de facilitar a ad-
ministrao dos provedores e de aumentar o potencial de agregao de rotas dados os
identicadores do provedor, tal soluo tende a atrelar os identicadores localizao
dos recursos. Dessa forma, a resoluo de nomes nas ROCs , ainda, um desao bastante
importante a ser estudado visto que no h consenso sobre qual a abordagem com mais
pontos positivos do que negativos.
5.4.2. Roteamento de Contedos
Outro importante desao no desenvolvimento das ROCs o roteamento de con-
tedos baseado em nomes. Esse tipo de roteamento rompe com o atual paradigma na
Internet, no qual o caminho mais curto a ser percorrido por uma pacote determinado
pelo endereo IP de destino que ele carrega [Saltzer et al. 1984]. Por utilizar nomes como
identicadores em nvel de rede a invs do endereos IP, os protocolos de roteamento de
contedos baseados emnomes so suscetveis s caractersticas particulares dos diferentes
mecanismos de nomeao de contedos. A utilizao de mecanismos de nomeao no
agregveis, por exemplo, congura um grave problema de escalabilidade para os protoco-
los de roteamento. No sendo agregveis, o impacto da manuteno de diversas entradas
para contedos distintos nas tabelas de roteamento visivelmente prejudicial ecin-
cia desses protocolos e, no pior caso, pode levar exploso das tabelas de roteamento.
Alm do impacto direto das diversas tcnicas de nomeao, o roteamento apresenta de-
saos intrnsecos s diversas arquiteturas discutidas. Por ser um tema de pesquisa recente,
muitos dos desaos relacionados ao roteamento baseado em nomes encontram-se ainda
sem tratamento adequado, de modo que a literatura disponvel , ainda, limitada. Assim,
muitas das abordagens ilustradas nesta seo tratam de abordagens utilizadas em outros
cenrios, podendo ser facilmente adaptadas s ROCs.
O roteamento baseado em nomes quebra a semntica sobrecarregada do IP, ou
seja, separa-se a localizao fsica da identicao das estaes que na arquitetura atual
feita por um nico endereo IP [Campista et al. 2010] . Essa dissociao entre localizador
e identicador facilita a mobilidade das estaes. Na arquitetura atual da Internet, quando
uma estao muda a sua localizao, ela necessariamente deve mudar seu endereo IP se
muda de rede. Assume-se, porm, que os endereos IP no se alteram durante toda a co-
municao entre duas estaes. Se h mudana de endereo, perdem-se as comunicaes
estabelecidas com o endereo IP anterior. Nas ROCs esse problema no ocorre visto que
os nomes, em geral, no carregam informaes sobre a localizao de quem os publica.
Por isso, diz-se que o problema da mobilidade simplicado nas ROCs.
Anteriormente s ROCs, algumas propostas de roteamento baseado em nomes sur-
giram, principalmente para resolver o problema da mobilidade de estaes descrito ante-
riormente. Alguns exemplos so o TRIAD [Cheriton e Gritter 2000], que utiliza as URLs
enviadas nas requisies HTTP como nomes hierrquicos de contedo, o ROFL [Caesar
et al. 2006], que utiliza tcnicas oriundas das DHTs para roteamento de nomes planos
em redes fsicas e diversos sistemas pub/sub, como os vistos na Seo 5.2.5, que encam-
inham noticaes de eventos baseadas em interesses identicados atravs de AVPs, sem
qualquer informao adicional sobre identicao ou localizao de assinantes [Martins e
Duarte 2010]. Dessa forma, como a viabilidade dos mecanismos de roteamento baseado
em nomes j foi estudada, o desenvolvimento complementar desses mecanismos para
ROCs deve priorizar o tratamento de questes relativas ecincia dos protocolos em ter-
mos da quantidade de mensagens de controle trafegadas na rede, da escalabilidade devido
ao tamanho das tabelas de roteamento e demais estruturas utilizadas no roteamento e ao
esticamento de rotas em relao rota de menor caminho entre fonte e destino. Rotas
so consideradas esticadas sempre que possuem um caminho mais longo que o caminho
fsico timo, de acordo comalguma mtrica de proximidade do roteamento, como nmero
de saltos ou tempos de ida e volta (RTT). Rotas que apresentam esticamento implicam a
perda na qualidade do servio de entrega de contedos dinmicos e sensveis a atraso,
como a distribuio de vdeo, devido principalmente latncia.
De forma geral, o uso de estruturas hierrquicas tem sido a tcnica mais usada
para prover escalabilidade aos protocolos de roteamento. As estruturas hierrquicas per-
mitem o roteamento em agregados de nveis hierrquicos maiores at que seja atinjido o
nvel do destino, apresentando agregados de maior granularidade. Estruturas hierrquicas
requerem, normalmente, endereos dependentes de localizao, o que contraria os princ-
pios das ROCs e podem resultar em considerveis esticamentos de rotas dada a rigidez
topolgica [Singla et al. 2010]. Uma soluo trivial para esse problema de roteamento
a utilizao de difuso de informaes para todos os ns. Tal difuso pode ser im-
plementada atravs da inundao (ooding) que, em termos de roteamento, no requer o
armazenamento de estados, adapta-se a modicaes de topologia e aumenta a disponibil-
idade das informaes [Martins e Duarte 2010]. A adoo de mecanismos de roteamento
no-hierrquicos traz o problema de escalabilidade devido ao excesso de mensagens de
controle de roteamento trafegadas na rede em virtude da inundao.
Uma forma de reduzir a quantidade dessas mensagens utilizar algoritmos em
que roteadores necessitem somente de informaes locais [Zhang et al. 2010], ou seja,
somente as prprias informaes e as de vizinhos diretos. Uma tcnica que pode ser
empregada para esse m o uso de roteamento de requisies (query routing). Em S-
BECON [Rosensweig e Kurose 2009], migalhas de po (breadcrumbs - BC) so estru-
turas de dados volteis que armazenam, emcada roteador, informaes relativas ao recebi-
mento e encaminhamento de contedos. O mecanismo utiliza o seguinte princpio proba-
bilstico: dado que determinado contedo foi recebido e encaminhado recentemente pelo
roteador, pode-se armar que o encaminhamento de uma nova requisio do contedo
em direo fonte (interface de recebimento, ou upstream) ou em direo aos usurios
servidos (interface de encaminhamento, ou downstream) ir, com alguma probabilidade,
encontrar uma cpia vlida do contedo. O uso de polticas do tipo LRU e encamin-
hamento downstream podem proporcionar maiores ganhos, uma vez que armazena-se por
mais tempo os contedos mais recentes e aumenta-se a probabilidade de atendimento
requisio. Resultados de simulaes mostram que, quando o tamanho do cache relati-
vamente menor que a variedade de contedos, o uso de BCs torna possvel obter conte-
dos com grande eccia, mostrando que restries no tamanho do cache nos roteadores
afetam muito mais os tempos necessrios para obteno de contedos do que sua disponi-
bilidade absoluta. Outra abordagem semelhante utilizada em SCAN [Lee et al. 2011],
que um mecanismo escalvel de roteamento baseado em nomes planos. O SCANutiliza,
entre outras tcnicas, a troca peridica de informaes de roteamento entre ns vizinhos
e permite que qualquer roteador, ao receber uma requisio de contedo, realize o dire-
cionamento dessas requisies aos vizinhos, cujas informaes de roteamento permitam
atender requisio. Esse processo de busca do contedo baseado nas informaes de
vizinhos denominado roteamento de varredura (scan routing) e utiliza a mesma lgica
de S-BECON. Tal mecanismo ser resumidamente descrito mais adiante.
Outra questo fundamental quando se utiliza o roteamento baseado em nomes de
contedos ao invs do roteamento baseado em endereos o crescimento das tabelas de
roteamento. Como a primitiva de rede deixa de ser baseada em ns, na ordem dos bilhes
atualmente na Internet, passando a ser baseada em contedos, estimados na ordem de
centenas de trilhes, devem ser adotadas tcnicas que favoream a reduo das tabelas de
roteamento. Lida-se, usualmente, com esse desao atravs da agregao de endereos, o
que reduz a quantidade de memria para armazenar a tabela e o tempo de processamento
da busca na tabela por um dado contedo. Porm, em muitas das solues propostas para
as ROCs, a agregao impossvel ou bastante difcil, sendo necessria a utilizao de
estruturas de dados compactas para a representao das tabelas de roteamento, capazes de
reduzir os requisitos de armazenamento e utilizao destas informaes.
O SCAN, como visto anteriormente, prev a troca de informaes de roteamento
de contedos entre ns vizinhos para a realizao de varreduras. Tais informaes so
provenientes da tabela de roteamento de contedos (content routing table - CRT), que
so estruturas compactas para o armazenamento de informaes relativas ao armazena-
mento de contedos nos ns. Como a quantidade de entradas numa tabela desse tipo
pode crescer consideravelmente, o SCAN comprime tais informaes utilizando ltros de
Bloom [Broder e Mitzenmacher 2002]. Filtros de Bloom so estruturas de dados proba-
bilsticas que permitem vericar se determinado elemento faz parte de um conjunto. Um
ltro de Bloom , usualmente, formado por uma cadeia de m bits, todos inicialmente
preenchidos com 0. Quando se deseja inserir um elemento no ltro, aplica-se a esse el-
emento k funes hashes independentes, que retornam inteiros entre 0 e m1. Dessa
forma, os bits correspondentes aos k resultados das funes hash so carregados com 1.
Dessa forma, para realizar a vericao se determinado elemento pertence ao ltro, basta
checar se os k elementos registram o valor 1 (ou, no caso de aceitar-se aproximaes, se
uma quantidade de bits menor que k signicante suciente registram 1) [Lee et al. 2011].
Cabe notar que ltros de Bloom so estruturas probabilsticas e, dessa forma, os mapea-
mentos possibilitados por tais estruturas esto sujeitos a falsos positivos. Em termos de
sua aplicao em redes, essa caracterstica se traduz em envio de dados a ns errados, car-
acterizando um aumento na sobrecarga de controle, que pode ser minimizada escolhendo-
se adequadamente o tamanho em bits do ltro e a quantidade de funes hash utilizadas.
Carzaniga et al. propem o B-DRP, um mecanismo de roteamento para sistemas pub/sub
baseados em contedos que utiliza particionamento dinmico de receptores (dynamic re-
ceiver partitioning - DRP) e ltros de Bloom na representao de predicados [Carzaniga
et al. 2009]. O B-DRP requer que cada roteador conhea os predicados anunciados por
todos os roteadores, o que caracteriza um severo obstculo escalabilidade. Por isso, o
B-DRP tambm prev a compactao dessas informaes atravs da codicao desses
predicados em estruturas baseadas em ltros de Bloom. Algumas propostas [Kumar et al.
2005,Lee et al. 2011] utilizam o conceito de ltro de Bloom com decaimento exponencial
(exponential decay Bloom lter - EDBF), que representa a inverso de bits 1 para 0 com
probabilidade aumentando exponencialmente com a distncia do n emissor do EDBF.
Dessa forma, as informaes de roteamento locais so compartilhadas, porm possuem
muito mais relevncia e validade num pequeno raio em torno do n, diminuindo tambm
o trfego de controle na rede.
Por m, o potencial de esticamento de rotas propiciado pelas solues de rotea-
mento baseadas em nomes deve-se, em grande parte, ao rompimento entre identicao e
localizao das ROCs. Ns em estruturas hierrquicas de nomes ou objetos com chaves
de um espao de nomes circular de uma DHT podem no possuir o estado necessrio para
estabelecimento de rotas com o caminho fsico mais curto ainda que possuam vizinhana
no plano de nomes ou da aplicao. O ROFL, por exemplo, possui, na prtica, um estica-
mento alto, tendendo ao ilimitado em topologias genricas [Singla et al. 2010]. A forma
mais comum de lidar com esses esticamentos de rotas introduzir nos mecanismos de
roteamento aspectos ligados proximidade fsica dos ns, como o roteamento por prox-
imidade (proximity routing) e a seleo de vizinhos por proximidade (proximity neighbour
selection) [Ratnasamy et al. 2002]. Essas duas solues amplamente adotadas em redes
P2P. O roteamento por proximidade consiste em levar em considerao a proximidade
dos ns de prximo salto existentes na tabela de roteamento. Dessa forma, o roteamento
mantm o equilbrio entre o avano em direo ao identicador de destino e a seleo de
ns mais prximos da origem. So exemplos de aplicao de roteamento por proximidade
as propostas de redes P2P CAN [Ratnasamy et al. 2001] e Chord [Stoica et al. 2003],
que utilizam medies de RTT de seus vizinhos (CAN) e listas de ns mais prximos que
possibilitam saltos para regies especcas do plano de nomes (Chord), e utilizando o n
com menor RTT (ou o mais prximo) dentre os que possibilitam avano em direo ao
destino. Tal abordagemconfere umpotencial de reduo do esticamento ao mecanismo de
roteamento, porm como existem muito mais ns na rede sobreposta prximos origem
do que vizinhos, a reduo dos caminhos obtidos pode ser bastante limitada. O mecan-
ismo de seleo de vizinhos por proximidade consiste em construir tabelas de roteamento
levando-se a topologia em considerao. Toda entrada na tabela de roteamento de um n
referente a um n prximo, de acordo com alguma mtrica de proximidade, como con-
tiguidade no espao de nomes e RTT. Isso permite uma reduo na distncia percorrida
pelas mensagens, sem aumento signicativo na quantidade de saltos [Castro et al. 2002].
MultiCache [Katsaros et al. 2011] uma proposta de arquitetura sobreposta para ROCs,
que implementa o Pastry [Rowstron e Druschel 2001] como substrato de roteamento. O
Pastry utiliza a seleo de vizinhos por proximidade, gerando rotas mais curtas e conver-
gentes para uxos com origens prximas e mesmos destinos. Dessa forma, a considerao
de proximidade no estabelecimento de enlaces com vizinhos confere a estes sistemas um
melhor desempenho, j que os caminhos utilizados na distribuio de contedos tendem
a apresentar atrasos menores.
5.4.3. Armazenamento na Rede (caching)
Um dos principais fundamentos de uma ROC o armazenamento de contedo na
rede atravs do uso de cache em todos os roteadores da rede [Ghodsi et al. 2011a]. O
principal objetivo consiste no aumento do desempenho da rede na distribuio dos conte-
dos. Esse aumento de desempenho proporcionado pela diminuio do atraso percebido
pelo usurio, pelo aproveitamento mais eciente da banda passante no ncleo da rede,
pela disponibilidade de mltiplas cpias evitando assim o ponto nico de falha e pela
diminuio do trfego prximo fonte de contedo, que reduz a carga de processamento.
O armazenamento de contedo e o uso de cache so temas bastante estudados, sobretudo
a partir do surgimento da Web. Recentemente, o emprego de CDNs tambm incitou um
grande nmero de trabalhos, principalmente sobre o problema de distribuio dos caches
na rede bem como a distribuio dos contedos nos caches de maneira a minimizar o
atraso e otimizar o uso da banda passante na rede. No entanto, o uso do cache em redes
orientadas a contedo possui caractersticas bemdistintas das mencionadas anteriormente.
A primeira caracterstica importante o emprego do cache em todos os componentes da
rede, formando uma rede de caches
9
, ao contrrio do web-caching, o qual apresenta uma
topologia hierrquica em rvore, e das CDNs, nas quais os caches so posicionados em
pontos especcos da rede. Essa caracterstica proporciona uma grande exibilidade para
alocao de contedo, expandindo o acesso a tal funcionalidade a todos os ns da rede
e no somente aos servidores de contedo, como acontece nas CDNs. A segunda car-
acterstica relevante que, dependendo da arquitetura de ROC, os caches armazenam
pedaos de mesmo tamanho (chunks) dos contedos ao invs de armazenar o contedo
inteiro. O tamanho dos contedos pode ter um grande impacto no desempenho do sis-
tema de armazenamento de contedo [Podlipnig e Bszrmenyi 2003]. Em arquiteturas,
como a CCN, o fato de haver um tamanho nico para os pedaos armazenados simplica
o problema.
Os principais temas de pesquisa nesta rea podem ser resumidos por: (i) modelos
analtico para redes de cache, (ii) estratgias de descarte de contedo e (iii) polticas de
armazenamento. Todos os trabalhos presentes na literatura realizam algum tipo de avali-
ao do desempenho da rede de cache a m de investigar o modelo proposto, a poltica
de cache, a poltica de armazenamento, o modelo de segurana, entre outros aspectos
funcionais. As mtricas mais utilizadas para medir o desempenho das redes de caches
so (i) a taxa de acerto (hit ratio), que dene a frao de pedidos de contedo que foram
encontrados no cache, (ii) o atraso percebido pelo usurio, que mede o tempo de espera
para receber um dado contedo aps o envio da respectiva requisio e (iii) nmero mdio
de saltos que um pedido atravessa antes de ser atendido. Todos os trabalhos utilizam a
distribuio Zipf-like (1/i
) para modelar a popularidade dos contedos [Breslau et al.

1999]. Porm, os trabalhos utilizam diferentes valores para o parmetro .
Em seguida so apresentados os principais desaos e trabalhos propostos em cada
um dos temas de pesquisa mencionados anteriormente.
9
O termo usado em ingls in-network caching.
5.4.3.1. Modelos Analticos para Redes de Cache
O maior desao nesta rea de pesquisa a grande complexidade que representa
uma rede de caches do tamanho da Internet. Existem muitos trabalhos que propem novos
modelos na tentativa de compreender a dinmica e analisar o desempenho das redes de
caches [Rosensweig et al. 2010, Psaras et al. 2011, Caroglio et al. 2011a, Caroglio
et al. 2011b, Fricker et al. 2012]. Existem alguns trabalhos que modelam sistemas de
web-caching hierrquicos, com topologias especcas nas quais o servidor de origem do
contedo est conectado ao topo da hierarquia, como nas topologias em rvore [Che
et al. 2001, Che et al. 2002]. Alm disso, devido a complexidade desses modelos,
esses so usualmente empregados em topologias pequenas, como em rvores de dois
nveis [Rosensweig et al. 2010].
Em um dos primeiros esforos para modelar as redes de caches, Rosensweig et
al. propem um algoritmo aproximativo para caracterizar o comportamento de redes de
caches com topologias genricas [Rosensweig et al. 2010]. A abordagem utilizada con-
siste em denir um modelo para apenas um roteador com um nico cache. Assim, os
pedidos que chegam a esse roteador so todos aqueles vindos diretamente para o roteador
somados aos pedidos no encontrados nos caches dos vizinhos. Considera-se, nesse caso,
que aps um pedido no ser encontrado, ele reencaminhado pelo menor caminho at a
origem dos contedos. Em um processo interativo, o algoritmo atualiza os pedidos que
chegam em cada roteador at que toda a rede convirja para um estado estacionrio. Os au-
tores armam que o modelo proposto serve para qualquer topologia independentemente
da escala. Porm, a complexidade do algoritmo dada por O(KB), o que prejudica o uso
desse modelo para redes com muitos contedos (K) e com tamanhos grandes de cache
(B) [Psaras et al. 2011]. A m de resolver este problema, Psaras et al. propem um
modelo mais simples para o cache de apenas um roteador [Psaras et al. 2011]. Esse mod-
elo utiliza uma cadeia de Markov contnua e homognea, na qual cada estado da cadeia
representa a posio atual do contedo no cache. Os autores consideram que sempre que
um contedo requisitado, ele armazenado na primeira posio do cache (topo). No
caso de ser um contedo que no esteja no cache, todos os outros contedos so movidos
uma posio para baixo. Caso contrrio, o contedo requisitado movido para o topo,
e apenas os contedos armazenados acima do contedo encontrado no cache mudam de
posio. Assim, considerando N o tamanho do cache, um elemento no estado N +1 da
cadeia est fora do cache. O modelo , tambm, estendido para uma rede de caches. O
maior objetivo calcular o tempo em que um contedo permanece no cache. Por m, os
autores estendem o modelo para dois roteadores em cascata e analisam o desempenho de
uma rede de caches em rvore.
Utilizando uma abordagem diferente, Caroglio et al. propem um modelo para
transferncias de pedaos de contedo (chunks) em redes de caches [Caroglio et al.
2011b]. Primeiramente, proposto um modelo probabilstico de falha na busca por um
determinado contedo (probabilidade de erro) em apenas um roteador. O processo de
requisies modelado em dois nveis: contedo e pedao de contedo. O processo de
chegada de requisies modelado a partir de um processo [1]MMRP (Markov Modu-
lated Rate Process). Em seguida, os autores estendem o modelo para uma rede de caches
come semagregao de pedidos, baseado emuma topologia emrvore ou emcascata. Por
m, apresentada uma frmula fechada para a mdia da vazo estacionria em relao
a diversos parmetros, tais como, probabilidade de acerto, popularidade do contedo,
tamanho do contedo e do cache. Em um segundo trabalho, Caroglio et al. estendem o
modelo anteriormente proposto para considerar limitaes de banda passante e de capaci-
dade de armazenamento [Caroglio et al. 2011a]. Dessa maneira, os autores apresentam
uma frmula fechada para o atraso mdio de entrega de um contedo considerando estas
limitaes acrescentadas ao modelo.
Com o intuito de avaliar o impacto de diferentes tipos de trfego no desempenho
de redes de caches, Fricker et al. modelam uma rede de caches estruturada em rvore,
considerando quatro tipos de contedos diferentes: objetos web, compartilhamento de
arquivos, contedos gerados por usurios e vdeo sob demanda [Fricker et al. 2012]. Essas
categorias apresentamcaractersticas bemdistintas emtermos de popularidade, populao
e tamanho de contedo. O modelo baseado em uma aproximao do desempenho das
polticas LRU (Least Recently Used) e LFU (Least Frequently Used) [Che et al. 2002].
Os autores mostram que o compromisso entre o tamanho do cache e a banda passante
utilizada est fortemente relacionado com as caractersticas do contedo armazenado.
5.4.3.2. Estratgias de Descarte de Contedo
As polticas de descarte de pacotes esto associadas substituio de contedos
quando o cache atinge sua capacidade mxima de armazenamento e um novo contedo,
ainda no armazenado no cache, requisitado. Por isso, necessria uma estratgia para
escolher qual contedo ser descartado para dar lugar ao ltimo requisitado. As duas
polticas mais utilizadas so a LRU e a LFU. A primeira, a mais simples, descarta o con-
tedo acessado menos recentemente enquanto a segunda descarta o contedo usado menos
frequentemente. Segundo Podlipnig e Bszrmenyi, apesar de haver uma quantidade sig-
nicativa de diferentes propostas de polticas de descarte de contedo, existe um forte
argumento alegando que o estudo de novas polticas mais ecientes menos importante
j que a capacidade dos dispositivos de armazenamento apresentava uma forte tendn-
cia de crescimento, aliada diminuio constante dos preos [Podlipnig e Bszrmenyi
2003]. Portanto, as polticas de descarte mais simples apresentam desempenho semel-
hante s polticas mais complexas. No entanto, nas redes de cache a realidade outra. O
tamanho dos caches nos roteadores so limitados a quantidades relativamente pequenas
de armazenamento se comparado ao universo de contedos a ser armazenado, em razo
de custo e desempenho [Perino e Varvello 2011]. Contudo, mesmo com a limitao de
capacidade de armazenamento dos roteadores, existe ainda um compromisso entre a com-
plexidade da poltica de descarte e a capacidade de processamento do roteador. Por isso,
a maioria dos trabalhos analisam apenas o desempenho das polticas LFU e LRU, sendo
esda ltima considerada um limite superior de velocidade para as outras polticas [Rossi
e Rossini 2011a]. Ainda assim, muitos trabalhos avaliam o desempenho das redes de
caches considerando diferentes polticas de descarte de contedo.
Em uma das primeiras tentativas de investigar o desempenho das redes de caches,
Choi et al. avaliam por meio de simulaes dois tipos especcos de topologia para redes
orientadas a contedo [Choi et al. 2009]. Nesse trabalho, so consideradas a topologia em
rvore e a topologia baseada em DHTs. Os autores analisam o tamanho do cache, o atraso
de transferncia e a robustez a falhas aleatrias de roteadores em ambas as topologias.
Rossi e Rossini analisam o desempenho das redes de caches baseado em carac-
tersticas da infraestrutura da rede [Rossi e Rossini 2012]. Os autores consideram diversas
mtricas de centralidade, tais como grau, proximidade (closeness) e intermediao (be-
tweenness), entre outras. Essas mtricas reetem, de maneiras diferentes, a importncia
de um n na rede. Assim, eles utilizam algumas topologias reais, com diferentes carac-
tersticas estruturais. Por m, so propostos dois critrios para atribuio de tamanhos
de cache para cada n da rede, proporcional s mtricas de centralidade. O resultado
mais importante desse trabalho mostra que o impacto da topologia na denio de caches
de tamanhos diferentes insignicante, sobretudo em relao a complexidade acrescen-
tada pelo mecanismo proposto. Em outro trabalho, Rossi e Rossini analisam o desem-
penho de redes de cache com diversas polticas de descarte de contedo [Rossi e Rossini
2011a]. Entre as polticas analisadas esto a LRU, FIFO, na qual o contedo armazenado
mais antigo descartado, UNIF, onde um contedo escolhido aleatoriamente com dis-
tribuio uniforme, e BIAS, na qual dois contedos so sorteados e o mais popular
descartado. Em um terceiro trabalho, Rossi e Rossini alm de diferentes polticas de
descarte, consideram ainda modelos de localidade e estratgias de encaminhamento da
arquitetura CCN [Rossi e Rossini 2011b].
Caroglio et al. apresentam duas novas estratgias para o descarte de contedos
a m de prover qualidade de servio [Caroglio et al. 2011c]. Na primeira estratgia, os
autores sugerem a utilizao da tcnica de particionamento de cache [Lu et al. 2004], na
qual uma frao da memria alocada para cada aplicao. Pelo fato da alocao pro-
posta ser esttica, surge o problema de subutilizao do cache quando uma determinada
aplicao preenche toda a sua frao da memria e comea a usar a poltica de descarte,
enquanto ainda h espao livre na memria reservado a outras aplicaes. A segunda
estratgia consiste em denir categorias de prioridades para as aplicaes e realizar o
gerenciamento do descarte de acordo com essas prioridades, escolhendo assim qual cat-
egoria ter um pedao descartado. Em um dos algoritmos propostos, um determinado
pedao s poder ser descartado para dar lugar a um outro pedao de prioridade igual ou
superior a sua.
5.4.3.3. Polticas de Armazenamento
As polticas de armazenamento denem que contedos devem ser armazenados no
cache. A poltica mais utilizada na literatura consiste em armazenar todos os contedos
que no foram encontrados no cache, indiscriminadamente. Rossi e Rossini avaliam o
desempenho, atravs de simulaes, de diferentes polticas de armazenamento [Rossi e
Rossini 2011a]. A primeira a poltica de armazenar tudo que chega nos roteadores sem
discriminao. A segunda poltica analisada [Arianfar et al. 2010b] armazena o contedo
aleatoriamente com uma probabilidade xa P. Por ltimo, analisada a poltica LCD
(Leave a Copy Down), na qual os contedos que no so encontrados no cache de um
determinado roteador so armazenados apenas no roteador seguinte (prximo salto) no
caminho para o usurio que o requisitou.
Cho et al. propem um esquema de armazenamento no qual o nmero de pedaos
a ser armazenado depende da popularidade do contedo [Cho et al. 2012]. Alm disso,
os roteadores indicam aos seus vizinhos se um dado pedao deve ser armazenado ou no,
marcando um bit de armazenamento. Dessa maneira, evita-se que muitos ns do caminho
armazenem os mesmos contedos. Nesse esquema, os roteadores tendem a empurrar"
os contedos mais populares na direo dos roteadores mais prximos dos usurios que
zeram o pedido.
Existem tambm pesquisas de novas polticas de armazenamento e posiciona-
mento de caches em redes baseadas no paradigma pub/sub. Diallo et al. introduzem
novas polticas de armazenamento [Diallo et al. 2011]. As diferentes polticas priorizam
diferentes tipos de contedo tais como contedos que tm um pedido pendente ou que
j foram expedidos. Os autores tambm analisam o desempenho das polticas propostas
usando diferentes polticas de descarte. Sourlas et al. propem um algoritmo para denir
o posicionamento de caches e a atribuio de rplicas de contedo a m de possibilitar o
acesso a contedos cujo publicador" j se desconectou da rede [Sourlas et al. 2011].
5.4.4. Segurana
Um dos principais problemas de segurana nas ROCs a conana no contedo,
isto , como saber que um determinado contedo realmente aquele que est sendo req-
uisitado. Na arquitetura atual, esse problema resolvido a partir do conhecimento da
origem do contedo e das caractersticas da comunicao. O conhecimento da origem
pressupem conana no site de busca, bem como no sistema DNS [Smetters e Jacobson
2009]. Portanto, existem trs problemas bsicos a serem resolvidos para se prover con-
ana no contedo: (i) vericar a integridade do documento, (ii) vericar a provenincia
do contedo e (iii) vericar a relevncia do contedo obtido em relao ao requisitado.
Muitos trabalhos [Koponen et al. 2007, Walsh et al. 2004, Popescu et al. 2005] focam
em resolver [2]esses problemas com nomes autocerticadores (self-certifying names), no
qual cada nome gerado atravs de uma operao criptogrca com o prprio contedo.
No entanto, essa abordagem d origem a um espao de nomes plano, no qual a busca por
contedos signicativamente mais complexa que usar a nomeao baseada em DHTs.
Alm disso, essa tcnica de nomes autocerticadores resolve apenas o problema de in-
tegridade. Uma outra abordagem consiste em realizar uma operao criptogrca com a
chave que foi usada para assinar o contedo. Essa abordagem possibilita que a provenin-
cia seja vericada [Popescu et al. 2005]. No entanto, o maior problema de ambas as
tcnicas a necessidade de haver um mapeamento entre os nomes gerados a partir das
funes hash e nomes amigveis para os usurios. Esse problema exige a existncia de
ummecanismo que possa prover conana no mapeamento. Para evitar esse mapeamento,
Koponen et al. propem a concatenao de um rtulo escolhido pelo publicador do con-
tedo, que represente um nome amigvel, com o resultado do hash da chave pblica do
publicador [Koponen et al. 2007]. Entretanto, o rtulo no assinado e, por isso, permite
que um atacante associe um contedo vlido e assinado a um rtulo qualquer de sua es-
colha. Dannewitz et al. possuem uma abordagem similar anterior para prover nomes
com autocerticao [Dannewitz et al. 2010]. Smetters e Jacobson propem autenticar
a relao entre nomes e contedos, ao invs de autenticar cada um deles [Smetters e Ja-
cobson 2009]. Assim, os nomes teriam a funo apenas de identicador dos contedos de
forma amigvel e de localizador dos mesmos, enquanto a autenticao seria atingida por
meio da validao do mapeamento de um contedo e seu respectivo nome.
Ainda com relao nomeao, outro problema identicado a falta de privaci-
dade. O uso de nomes dos contedos para realizar as operaes bsicas da rede introduz
uma falha na privacidade dos usurios. Nas ROCs, os roteadores tm acesso direto req-
uisio de contedo dos usurios bastando, portanto, que um dos roteadores da rede seja
comprometido para permitir que um atacante seja capaz de monitorar os pedidos enviados
pelos usurios. Alm disso, a censura de contedos, prtica adotada por alguns pases,
bastante facilitada, pelo acesso direto a informaes de contedo requisitado. Arian-
far et al. propem um mecanismo para aumentar a privacidade dos usurios, dicultando
o trabalho dos atacantes de monitorar os pedidos realizados [Arianfar et al. 2011]. O es-
quema proposto visa dicultar a identicao de uma requisio a um contedo proibido,
bem como dicultar que um contedo recuperado seja identicado como um contedo
proibido. A tcnica utilizada consiste em misturar blocos de contedos proibidos com
contedos normais de maneira que um pedao de contedo seja composto por mais de um
bloco. Assim, o usurio deve requisitar um nmero de pedaos que o permita recuperar
mais de um contedo, e no somente o proibido. Dessa maneira, o trabalho do atacante
para descobrir o que est sendo requisitado baseado apenas nos pedidos de pedaos
bastante dicultado.
Outro problema importante de segurana presente nas ROCs a vulnerabilidade
poluio de cache [Gao et al. 2006]. Esse ataque consiste em enviar pedidos de con-
tedo aleatrios com o intuito de alterar a popularidade dos contedos, provocando o
armazenamento de contedos de pouca popularidade nos caches dos roteadores. Uma
variao desse ataque fazer apenas requisies de contedos pouco populares. No en-
tanto, necessrio o conhecimento prvio da popularidade dos contedos. Um caso mais
grave desse ataque consiste em fazer pedidos de contedos falsos, criados apenas para
poluir os caches e que esto fora do universo de contedos vlidos. Xie et al. propem
um mecanismo de armazenamento que reduz o efeito de um ataque de poluio [Xie
et al. 2012]. O mecanismo proposto armazena apenas os contedos pedidos com maior
frequncia. Os autores mostram atravs de simulaes a ecincia do mecanismo pro-
posto para ataques de envio de requisies contedos legtimos mas de forma aleatria,
uniformemente distribuda.
Apesar de a segurana ser uma rea importante com muitas questes em aberto, os
esforos empreendidos no sentido de resolver estes problemas so ainda bastante restritos
e insipientes.
5.4.5. Aspectos Prticos
Diferentes arquiteturas, como as descritas na Seo 5.3.4, so avaliadas em plata-
formas de teste experimentais e possuem prottipos das suas pilhas de protocolos, como
o caso do CCNx
10
. Para adoo dessas propostas em larga escala, no entanto, necessrio
denir questes prticas de implementao das ROCs. Entre essas questes esto a
denio de um modelo econmico para uma nova Internet baseada em ROCs, a im-
plementao de roteadores de contedo e o desenvolvimento e a avaliao de aplicaes
10
http://www.ccnx.org.
tipicamente conversacionais. A seguir, essas questes prticas so discutidas.
5.4.5.1. Modelo econmico
Para a adoo das ROCs em larga escala, fundamental denir um modelo que
estimule os atuais operadores de rede e de servios a migrarem para uma arquitetura de
ROCs e que garanta a remunerao de suas atividades, mesmo com a adoo de novas
tecnologias [Feamster et al. 2007].
O modelo de negcios adotado atualmente na Internet baseado na conectividade.
Em geral, os usurios pagam aos seus ISPs locais para terem acesso rede [Trossen e
Biczk 2010]. A funo de um ISP, nesse caso, simplesmente encaminhar pacotes.
Como os servios de rede so prestados m-a-m e a Internet organizada em sistemas
autnomos, os ISPs tambm pagam para enviar seu trfego para outros ISPs.
Os servios bsicos de entrega esto se tornando commodities e, por isso, os ISPs
procuram por novos servios que aumentem suas receitas [Feamster et al. 2007]. At-
ualmente, j existem servios diferenciados que oferecem distribuio de voz e vdeo e
usurios que pagam mais por tal diferenciao [Trossen e Biczk 2010]. Outro exemplo
nesse sentido so as CDNs que adotam um modelo de negcios particular. Um provedor
de CDN oferece seus servios para produtores que pagam para distribuir seus contedos
aos consumidores de forma mais eciente. O provedor de CDN possui uma plataforma
central que coordena o provisionamento de servios, oferece garantias de nvel de servio
e responsvel pela tarifao dos usurios. Entretanto, esse modelo no eciente para
as ROCs, uma vez que fortemente baseado em um elemento central e, por isso, compro-
mete a escalabilidade de tais redes.
Ainda no h um modelo econmico denido e bem aceito para as ROCs, mas j
existem algumas propostas [Trossen et al. 2010, Zhang et al. 2011, Biraghi et al. 2011].
Zhang et al. denem os atores de um modelo de negcios proposto para ROCs [Zhang
et al. 2011]. So eles os produtores de contedo, que criam contedos, os provedores
de contedo, que so portais que agregam contedos de diferentes produtores e os con-
sumidores, que solicitam o contedo. Os autores tambm consideram a existncia de
provedores de datacenter, que oferecem recursos de processamento e armazenamento e
de ISPs, que so divididos em provedores de redes de acesso (Internet Access network
Providers - IAPs) e provedores de backbone (Internet Backbone Providers - IBPs). Por
m, existem anunciantes, que correlacionam sua marca com os contedos durante o pro-
cesso de distribuio, e patrocinadores, que adicionam suas marcas aos contedos durante
a fase de produo. Esses atores atuam nas duas camadas propostas para a distribuio de
contedos: a camada de produo de contedo e a camada de interconexo.
A camada de produo de contedo a de mais alto nvel, na qual a unidade de
dados so objetos digitais como vdeos, msicas, arquivos, etc. A Figura 5.9(a) mostra
uma rede de valor
11
simplicada para a camada de produo, na qual esto ilustrados
os processos de (i) criao e publicao de contedo, (ii) as diferentes possibilidades
11
Uma rede de valor um mtodo usado para analisar modelos de negcio que descrevem recursos
tcnicos e sociais e ilustra as interligaes entre os diferentes atores do modelo.
de armazenamento desse contedo e (iii) as diferentes fontes de receita do provedor de
contedo. Os ns representam os atores e as setas que interconectam os ns representam
as transferncias de trfego, monetrias e os benefcios intangveis entre os atores.
(a) ROC - camada de produo de contedo.
(b) ROC - camada de interconexo. (c) Cliente-servidor - camada de interconexo.
Figure 5.9. As redes de valor para uma ROC e para o modelo cliente-servidor.
A camada de interconexo prov a infraestrutura de rede necessria para o en-
caminhamento e o armazenamento do contedo. A unidade de dados nessa camada so
os bits. A Figura 5.9(b) ilustra uma rede de valor simplicada para a camada de inter-
conexo, na qual a espessura das setas indica o volume relativo de trfego entre os atores.
importante notar que a distribuio se d entre os consumidores e provedores de con-
tedo e no envolve os produtores. A diferena bsica dessa rede de valor para a do
modelo cliente-servidor, ilustrada na Figura 5.9(c), a presena do servidor de cache nos
IAPs e IBPs [Zhang et al. 2011]. Um dos benefcios em virtude da introduo do cache
nesses atores a reduo do trfego entre os prprios IAPs e IBPs e entre tais provedores
e os provedores de contedo, como indicam a setas de menor espessura na Figura 5.9(b).
Outro detalhe que o custo do Consmuidor 2 maior do que o do Consumidor 1, pois ele
se encontra em um IAP diferente do provedor de contedo.
A possibilidade de armazenamento de contedos nos elementos de rede propor-
ciona reduo de trfego e, consequentemente, do custo de encaminhamento. Entretanto,
introduz novos desaos relativos tarifao e ao gerenciamento das ROCs. A reduo
do custo de encaminhamento, por exemplo, obtida em troca do armazenamento na rede.
Atualmente essa troca interessante visto que o custo do armazenamento decai mais rap-
idamente do que o de transmisso. Porm, a comparao entre os custos de ambos
difcil, pois o armazenamento e transmisso so tarifados de maneira diferente [Biraghi
et al. 2011]. Em geral, paga-se por uma determinada capacidade de armazenamento que
reservada e pode ser reutilizada mltiplas vezes. Um mesmo contedo, por exemplo,
pode ser acessado mltiplas vezes no cache e a cobrana no se d por esse nmero de
acessos, mas sim pelo espao ocupado pelo contedo. Por outro lado, o encaminhamento
um servio do tipo pague-pelo-uso, ou seja, a cada reenvio se fatura o mesmo pacote.
Outra questo primordial se o cache deve ser transparente ou baseado em acor-
dos comerciais. Para a maioria das arquiteturas de ROCs, o cache transparente, ou seja,
todos os roteadores armazenam contedos sem distino de quem os publica ou solicita.
Entretanto, atualmente nas CDNs ele feito baseado em acordos comerciais com grande
sucesso [Biraghi et al. 2011]. Alm disso, ainda no h uma denio sobre quem deve
decidir sobre o armazenamento de um dado contedo em um elemento da rede: o ISP
e/ou o provedor de contedo. Em caso de ambos terem controle, podem existir conitos
e, por isso, necessrio desenvolver mecanismos de controle multipartite. Por exemplo,
IAPs podem atualizar seu cache com uma frequncia mais baixa do que a desejada pelo
provedor de contedo. Medidas contratuais e incentivos monetrios podem resolver esse
conito. Nesse cenrio tambm pode existir o regulador de contedo, que o elemento
responsvel pela resoluo de conitos de interesse entre os atores da rede, sejam eles
consumidores, ISPs ou provedores de contedo. O regulador pode determinar, por exem-
plo, se um contedo sensvel e, por isso, no deve ser armazenado pelos elementos da
rede ou ainda se os elementos que armazenam um dado contedo so qualicados para
tanto. Outro ponto ainda sem denio se o cache feito apenas pelos elementos da
rede, como roteadores e servidores de cache, ou tambm pelos sistemas nais. As duas
solues so implementadas atualmente pelas CDNs e pelas redes P2P, respectivamente.
Da mesma forma, no h denio se os elementos de rede esto sob a mesma adminis-
trao ou se so abertos. A propriedade do local de armazenamento dene quem o
responsvel por pagar pelo cache e quem se benecia dele.
Uma questo fundamental para adoo das ROCs estimular os ISPs a mudarem
o atual modelo de negcios. Hoje, como indica o modelo adotado pelas CDNs, os prove-
dores de contedo esto mais dispostos a pagar por servios diferenciados de entrega
de contedo do que os ISPs [Trossen e Biczk 2010]. Entretanto, os ISPs tm papel
fundamental para as ROCs, visto que eles so os locais onde os caches devem ser im-
plementados. Os IAPs podem ser estimulados pela reduo de trfego interdomnio e de
custos com a adoo de caches. Atualmente, os IBPs sofrem com a queda de preo das
trocas de trfego e, por isso, buscam novas fontes de receita [Zhang et al. 2011]. Alguns
se tornaram tambm provedores de CDN, o que pode indicar que os IBPs esto abertos s
mudanas introduzidas pelas ROCs.
Roteadores de Contedo
A implementao dos roteadores de contedo outro grande desao para o desen-
volvimento das ROCs [Ahlgren et al. 2008, Arianfar et al. 2010a, Perino e Varvello 2011].
Esses roteadores, diferentemente dos roteadores tradicionais, no so responsveis ape-
nas pelo encaminhamento dos pacotes e clculo das tabelas de rotas. A operao chave
desses elementos o armazenamento dos contedos, que passa a ser operao interna dos
roteadores e no mais um procedimento coordenado por outros elementos da rede [Ar-
ianfar et al. 2010a]. Assim, cada roteador de contedo deve ser capaz de encaminhar,
armazenar e procurar contedos em seu cache com base nos identicadores dos conte-
dos e no mais nos endereos de destino, bem como encaminhar e processar pacotes de
controle. Alm disso, tambm deve manter estados para encaminhar de volta um dado
contedo para um usurio que demonstrou interesse nesse contedo.
A introduo das operaes associadas ao armazenamento de contedos requer
modicaes de hardware e software nos roteadores de pacotes atuais. O encamin-
hamento de contedos baseados em nomes e o cache na granularidade de pacotes ex-
igem, por exemplo, velocidades de processamento maiores do que as dos roteadores at-
uais. Outra modicao o aumento do nmero de estados a serem armazenados pelos
roteadores em virtude da mudana de espao de endereamento. Atualmente, esse espao
consiste de um bilho de endereos IP, entretanto, passar a ser de pelo menos um trilho
de nomes de contedos [Perino e Varvello 2011]. Por outro lado, a adoo de um cache
local pode reduzir o nmero de operaes de encaminhamento realizadas por um roteador.
Arianfar et al. avaliama viabilidade da implementao de roteadores de contedos
com base nas conguraes de hardware e software de roteadores atuais [Arianfar et al.
2010a]. Para tanto, os autores denem um modelo de referncia para um roteador de con-
tedo e propem mecanismos para implementar suas funcionalidades. O modelo denido
considera a implementao do armazm de contedos (Content Store - CS) denido para
os ns da arquitetura CCN, ilustrado na Figura 5.6, e a hierarquia de memria em trs
nveis adotada por roteadores-padro atuais que usam CAM (Content-Addressable Mem-
ory), SRAM (Static Random-Access Memory) e DRAM (Dynamic Random-Access Mem-
ory). O CS composto por dois componentes principais: o armazm de pacotes e a tabela
de indexao. Cada entrada da tabela contm o identicador do pacote, seu endereo de
memria no armazm de pacotes e informaes de estado. As entradas da tabela de in-
dexao so divididas entre a DRAM e a SRAM para reduzir a quantidade de memria
SRAM usada e, consequentemente, o custo do equipamento, como pode ser vericado
pela Tabela 5.2. O armazm usa apenas memria DRAM.
Table 5.2. Parmetros caractersticos dos tipos de memria [Perino e Varvello 2011].
Tipo Tempo de Tamanho Custo (USD/MB) Consumo
acesso (ms) mximo energtico (W/MB)
TCAM 4 20 Mb 200 15
SRAM 0,45 210 Mb 27 0,12
RLDRAM 15 2 Gb 0,27 0,027
DRAM 55 10 GB 0,016 0,023
High-speed SSD 1.000 10 TB 0,03 0,00005
SSD 10.000 1 TB 0,003 0,00001
Entre as funcionalidades de um roteador de contedo denidas por Arianfar et al.
esto a insero, a remoo e a busca de pacotes de contedo no CS e a identicao,
o enleiramento e o encaminhamento de pacotes. A partir dessas denies, estimam-
se os recursos computacionais exigidos por cada funcionalidade individualmente. Os
recursos avaliados so poder de processamento, tempo de acesso memria, quantidade
de memria exigida para armazenamento de contedos e consumo de energia.
O processamento no um fator crtico. As operaes relacionadas ao CS en-
volvem a busca, a vericao e a atualizao da tabela de indexao, o que requer poucos
ciclos de relgio considerando o uso de ASICs e FPGAs. Por outro lado, o tempo de
acesso memria pode ser um gargalo. O tempo de acesso tpico de uma DRAM da
ordem de 50 ns e os intervalos entre a chegada de pacotes de 40 bytes em enlaces de
10 Gb/s (OC-192) e 40 Gb/s (OC-768) so, respectivamente, 32 ns e 8 ns. Nesse caso, a
soluo mais simples para evitar o gargalo usar bancos de memria em paralelo ou sub-
stituir as atuais DRAMpor memrias mais rpidas como as RLDRAMs (Reduced Latency
DRAMs), que possuem tempo de acesso da ordem de 15 ns, como indica a Tabela 5.2.
Para avaliar a quantidade de memria necessria para o armazm de contedos, os au-
tores assumem que todo o trfego que passa por uma interface de rede de 10 Gb/s em
um intervalo de 10 s armazenado. Isso exige uma quantidade de memria DRAM de
aproximadamente 100 Gb com custo de at USD 300, atualmente. Alm disso, calcula-se
que devem ser mantidas 9 milhes de entradas de 36 bits na poro da tabela de index-
ao armazenada na SRAM. Logo, so necessrios 324 Mb com custo atual aproximado
de USD 500. No total, o custo com memria por porta do roteador de USD 800,00.
Atualmente, um roteador comercial de 10 Gb/s possui custo por porta entre USD 1.500 e
2.500. Portanto, a adaptao de um roteador convencional para um roteador de contedo
aumentaria em no mximo 30% o seu custo por porta. O aumento do consumo de energia
por cada interface em virtude do aumento de memria seria da ordem de 100 kWh/ano,
o que representa um pequena parcela do consumo total do equipamento e um aumento
de custo de USD 20. Portanto, os autores concluem que a transformao dos roteadores
convencionais em roteadores de contedo vivel em termos da quantidade de recursos
necessria e dos custos desses recursos adicionais.
Perino e Varvello tambm analisam a viabilidade da implementao de roteadores
de contedo usando as conguraes de hardware e software de roteadores atuais [Perino
e Varvello 2011]. No entanto, utilizam um modelo de referncia mais complexo para os
roteadores de contedo, que leva em considerao os demais componentes de um roteador
CCN alm do CS: a FIB (Forwarding Information Base) e a PIT (Pending Interest Table).
Basicamente, cada componente modelado individualmente de acordo a taxa de chegada
de pacotes de interesse e de dados e da taxa de servio de cada componente. A partir desse
modelo e considerando diferentes mtricas, indicam-se que tipos de memria devem ser
usados por cada componente do roteador de contedo. O CS avaliado em funo da
taxa de acerto do cache de contedos. Intuitivamente, quanto maior a probabilidade de
encontrar um contedo requisitado no CS, menor a quantidade de pacotes encaminhados
para a FIB. No entanto, esse comportamento s garantido se a memria usada para ar-
mazenar a tabela de indexao sucientemente rpida para processar todos os pacotes
que chegam ao CS. Do contrrio, pacotes sero encaminhados diretamente para a FIB.
Assim, para garantir uma taxa de acerto de 90%, que similar a de uma CDN atual, de-
vem ser usadas memrias RLDRAM e SRAM para armazenar a tabela de indexao. A
PIT avaliada em funo da taxa de chegada de pacotes de interesse, que no pior caso,
igual a taxa de chegada ao CS. Assim, o tamanho estimado para a PIT de 1,4 Gb
considerando um enlace de entrada de 100 Gb/s e por isso pode-se usar memria RL-
DRAM. Por m, a busca na FIB avaliada em funo do nmero de prexos de nomes
de contedo. Verica-se que at 20 milhes de prexos so suportados para garantir que
seja feita apenas uma busca na memria externa (off-chip), considerando uma memria
interna (in-chip) de 200 Mb. Esse nmero de prexos corresponde a 25% dos nomes de
estaes ativas na Internet atual. Em virtude desses resultados, a principal concluso dos
autores que os atuais roteadores ao serem adaptados para roteadores de contedo podem
operar na escala de uma CDN ou de um ISP e ainda no na escala global da Internet.
Os autores tambm apresentam duas possveis conguraes para roteadores de
contedo de ncleo e borda. A quantidade adicional de memria para transformar cada
roteador determinada em funo da taxa de chegada de pacotes de interesse por segundo.
O objetivo da anlise estimar o aumento do custo e do consumo de energia do equipa-
mento. O modelo usado como roteador de borda um Cisco 7507 que possui 5 interfaces
de rede Gigabit Ethernet. Para que ele se torne um roteador de contedo e suporte uma
taxa de 15 Mpck/s devem ser usados 1 TB de memria High-speed SSD para implementar
o armazm de pacotes, 6 GB de DRAM para a tabela de indexao, 70 Mb de RLDRAM
para a PIT, 200 Mb de SRAM para a memria interna da FIB e, por m, 140 MB de
memria DRAM para a memria externa da FIB. Esses recursos adicionais elevariam em
195 W o consumo de pico e em aproximadamente USD 30.000 o preo de um equipa-
mento. O modelo do roteador de ncleo um Cisco CRS 1 com oito interfaces de rede
de 40 Gb/s. Para torn-lo um roteador de contedo que suporta uma taxa de chegada de
1 Gpck/s e 250 milhes de prexos, deve-se implementar um armazm de pacotes por
interface, cada um com 10 GB de memria DRAM e uma tabela de indexao de 266 Mb
duplicadas em dois chips RLDRAM, uma PIT por interface com 560 Mb de SRAM, alm
de 4 Gb de SRAM para implementar a memria interna da FIB e 1,5 GB de DRAM para
a memria externa. Esses recursos adicionais elevariam em aproximadamente 3000 W o
consumo de pico e em USD 130.000 o preo do equipamento.
Aplicaes Conversacionais e em Tempo-Real
As ROCs aumentam a ecincia de aplicaes de distribuio de contedo. En-
tretanto, necessrio investigar o desempenho de aplicaes tipicamente conversacionais,
como o correio eletrnico e a transmisso de voz sobre IP (Voice over IP), nas ROCs uma
vez que os contedos so encaminhados com base em seus nomes e no mais nos en-
dereos IP.
Jacobson et al. propem e implementam uma aplicao de telefonia sobre a ar-
quitetura CCN, chamada de VoCCN [Jacobson et al. 2009b]. O principal objetivo
mostrar a viabilidade de mapear protocolos conversacionais, como o SIP (Session Initia-
tion Protocol) e o RTP (Real-time Transfer Protocol), em modelos baseados em contedo.
Para tanto, os autores identicam dois principais problemas: como iniciar uma chamada
e como o receptor identica e responde ao originador. Na Internet atual, um nmero de
porta usado como ponto de encontro para estabelecimento de chamadas. Para iniciar
uma chamada, o originador deve solicitar o estabelecimento de conexo com o recep-
tor, cujo endereo conhecido, enviando para ele pacotes com esse nmero de porta. O
receptor, por sua vez, envia de volta pacotes de conrmao da abertura, uma vez que
que os pacotes recebidos possuem o endereo do originador. Na arquitetura CCN isso
no trivial. necessrio implementar um mecanismo de publicao sob-demanda para
iniciar uma chamada. Como visto na Seo 5.3.4.3, a arquitetura CCN no exige que
um contedo seja publicado e registrado na infraestrutura antes de ser solicitado. Assim,
os usurios enviam requisies para contedos que ainda no foram publicados. Essas
requisies so encaminhadas para publicadores potenciais que, ao receb-las, criam e
publicam o contedo desejado em resposta. Assim, a chamada iniciada. O segundo
problema fazer com que o publicador consiga enviar contedos para o consumidor,
uma vez que os pacotes CCN no possuem identicao de quem solicita o contedo. A
soluo usar nomes construveis. A idia que seja possvel construir o nome de um
dado pedao do contedo sem ter conhecimento prvio de informaes desse contedo.
Para garantir essa propriedade, necessrio usar um algoritmo determinstico que pos-
sibilite ao publicador e ao consumidor construrem o mesmo nome e que o consumidor
possa solicitar contedos com nomes parcialmente especicados [Jacobson et al. 2009b].
Uma vez garantida a propriedade de nomes construveis, basta que o publicador receba
um pacote de interesse, crie o contedo nomeado de acordo com as informaes conti-
das nesse pacote e envie um pacote de dados. Esse pacote ser, ento, encaminhado de
volta ao consumidor pelo caminho reverso construdo a partir dos rastros deixados pelo
pacote de interesse. Assim, cria-se um uxo bidirecional de dados entre consumidor e
publicador. Resultados experimentais mostram que a aplicao VoCCN mais simples,
segura e escalvel do que uma aplicao VoIP equivalente baseada na arquitetura atual.
Vale ressaltar ainda que a VoCCN mantm a interoperabilidade com as aplicaes atuais,
pois usa implementaes-padro dos protocolos SIP e RTP e um gateway IP-para-CCN
simples e sem estados.
Uma aplicao semelhante VoCCN, chamada de VoPSI, proposta por Stais et
al. para a arquitetura PSIRP [Stais et al. 2011]. Outra aplicao, a ACT (Audio Con-
ference Tool), uma extenso da VoCCN que implementa funcionalidades de audiocon-
ferncia, como a descoberta de conferncias em andamento e de seus participantes [Zhu
et al. 2011]. Tsilopoulos e Xylomenos, por sua vez, propem mecanismos de diferen-
ciao de trfego para ROCs [Tsilopoulos e Xylomenos 2011]. A idia que contedos
sejam tambm encaminhados de acordo com seu tipo e no apenas de acordo com seus
nomes. Os contedos so classicados em documentos e canais. Pedaos de contedo
sensveis a perdas so classicados como documentos. Do contrrio, so classicados
como canais. Alm disso, os documentos so divididos em dois grupos: sob demanda e
de tempo real. Aplicaes multimdias em geral so classicas como canais. Transfer-
ncia de arquivos, vdeo sobre HTTP e correio eletrnico so documentos sob demanda.
Por m, jogos online, salas de bate-papo, mensageiros instantneos so documentos de
tempo real.
5.5. Consideraes Finais
O acesso a contedos em suas mais diversas formas j representa mais da metade
do trfego atual da Internet [Sandvine 2011]. Somente no Brasil, 53% do trfego ger-
ado por redes P2P de compartilhamento de arquivos e por aplicaes de distribuio de
udio e vdeo [Sandvine 2011]. Ainda que tais aplicaes j representem um grande
sucesso em termos de usurios e, em alguns casos, de gerao de receita, a distribuio
de contedo na arquitetura atual da Internet encontra uma srie de obstculos tcnicos
que aumentam consideravelmente a complexidade de implementao e administrao de
tais aplicaes. Esses obstculos exigem uma srie de remendos na Internet para que
as aplicaes funcionem, muitas vezes baseados em solues proprietrias e que tambm
podem comprometer a escalabilidade da rede.
As ROCs inserem-se nesse contexto como substrato de rede alternativo e vivel
no somente para o desenvolvimento de aplicaes de distribuio de contedo, mas tam-
bm para aplicaes tipicamente conversacionais. A principal vantagem das ROCs
prover de forma nativa o compartilhamento eciente de recursos e de dados, mecanis-
mos para aumentar a disponibilidade dos contedos, suporte segurana intrnseca de
contedos e mobilidade de usurios. Em geral, as ROCs adotam solues mais simples
do que as propostas para a Internet atual.
As pesquisas em andamento se concentram principalmente na proposta de novas
arquiteturas e na avaliao das polticas de cache para ROCs. Porm, o desenvolvimento
de tais redes remete, ainda, a outros desaos no-tcnicos, principalmente relacionados
aos interesses das partes envolvidas na distribuio de contedos. H conitos de inter-
esses nas relaes de peering entre provedores, falta de estmulo para a adoo de cache
nas redes de acesso e diculdade do processo de contabilizao no acesso aos contedos.
A padronizao e a interoperabilidade das ROCs ainda outra questo em aberto. Atual-
mente, existem grupos de trabalho do IETF para a padronizao do armazenamento de pa-
cotes na rede (DECADE) [Song et al. 2012] e interconexo entre CDNs (CDNI) [Niven-
Jenkins et al. 2012]. Porm no h inciativas para denir mecanismos de interoperabili-
dade entre arquiteturas de ROC, como CCN, DONA, etc.
Esse cenrio com diversos desaos tcnicos e econmico-nanceiros o que torna
o desenvolvimento das ROCs umcampo de pesquisa promissor e que potencialmente pode
resultar em uma mudana radical do paradigma de comunicao da Internet.
Agradecimentos
Este trabalho foi realizado com recursos do CNPq, CAPES, FAPERJ, FINEP,
CTIC e FUNTTEL.
Referncias
[Ahlgren et al. 2008] Ahlgren, B., DAmbrosio, M., Marchisio, M., Marsh, I., Dan-
newitz, C., Ohlman, B., Pentikousis, K., Strandberg, O., Rembarz, R. e Vercellone,
V. (2008). Design considerations for a network of information. Em Re-Architecting
the Internet Workshop - ReARCH, pginas 66:166:6.
[Akamai Technologies 2012] Akamai Technologies (2012). Akamai handles a signicant
portion of world wide web trafc - over a trillion interactions every day. http://
www.akamai.com/html/about/index.html. Acessado em 12 de maro de
2012.
[Allman 2007] Allman, M. (2007). Personal namespaces. Em ACM Workshop on Hot
Topics in Networks - HotNets.
[Arianfar et al. 2011] Arianfar, S., Koponen, T., Raghavan, B. e Shenker, S. (2011). On
preserving privacy in content-oriented networks. Em ACM SIGCOMM Workshop on
Information-Centric Networking - ICN, pginas 1924.
[Arianfar et al. 2010a] Arianfar, S., Nikander, P. e Ott, J. (2010a). On content-centric
router design and implications. Em Re-Architecting the Internet Workshop - ReARCH,
pginas 5:15:6.
[Arianfar et al. 2010b] Arianfar, S., Nikander, P. e Ott, J. (2010b). Packet-level caching
for information-centric networking. Relatrio tcnico, Aalto University.
[Bhattacharyya 2003] Bhattacharyya, S. (2003). An overview of source-specic multi-
cast (SSM). IETF Network Working Group RFC 3569.
[Biraghi et al. 2011] Biraghi, A. M., Gonalves, J., Lev, T., Ferreira, R. J., Zhang, N.,
Correia, L., Sebastio, D., Ohlman, B. e Salo, J. (2011). New business models and
business dynamics of the future networks. Relatrio Tcnico FP7-ICT-2009-5-257448-
SAIL/D.A.7, Scalable and Adaptable Internet Solutions (SAIL) Project.
[Breslau et al. 1999] Breslau, L., Cao, P., Fan, L., Phillips, G. e Shenker, S. (1999). Web
caching and zipf-like distributions: Evidence and implications. Em IEEE INFOCOM,
pginas 126134.
[Broder e Mitzenmacher 2002] Broder, A. e Mitzenmacher, M. (2002). Network appli-
cations of Bloom lters: A survey. Em Internet Mathematics, pginas 636646.
[Buyya et al. 2008] Buyya, R., Pathan, M. e Vakali, A. (2008). Content Delivery
Networks. Springer, 1a. edio.
[Caesar et al. 2006] Caesar, M., Condie, T., Kannan, J., Lakshminarayanan, K. e Stoica,
I. (2006). ROFL: routing on at labels. Em ACM SIGCOMM, pginas 363374.
[Campista et al. 2010] Campista, M. E. M., Ferraz, L. H. G., Moraes, I. M., Lanza, M.
L. D., Costa, L. H. M. K. e Duarte, O. C. M. B. (2010). Interconexo de redes na
Internet do futuro: Desaos e solues. Em Minicursos do Simpsio Brasileiro de
Redes de Computadores - SBRC, pginas 47101.
[Cao et al. 2004] Cao, F., e Singh, J. P. (2004). Efcient event routing in content-based
publish-subscribe service networks. Em IEEE INFOCOM.
[Caroglio et al. 2011a] Caroglio, G., Gallo, M. e Muscariello, L. (2011a). Bandwidth
and storage sharing performance in information centric networking. Em ACM SIG-
COMM Workshop on Information-Centric Networking - ICN, pginas 2631.
[Caroglio et al. 2011b] Caroglio, G., Gallo, M., Muscariello, L. e Perino, D. (2011b).
Modeling data transfer in content-centric networking. Em International Teletrafc
Congress - ITC, pginas 111118.
[Caroglio et al. 2011c] Caroglio, G., Gehlen, V. e Perino, D. (2011c). Experimental
evaluation of memory management in content-centric networking. Em IEEE Interna-
tional Communications Conference - ICC, pginas 16.
[Carzaniga et al. 2009] Carzaniga, A., Carughi, G. T., Hall, C. e Wolf, A. L. (2009).
Practical high-throughput content-based routing using unicast state and probabilistic
encodings. Relatrio Tcnico 2009/06, Faculty of Informatics, University of Lugano.
[Carzaniga et al. 2000] Carzaniga, A., Rosenblum, D. S. e Wolf, A. L. (2000). Content-
based addressing and routing: A general model and its application. Relatrio Tcnico
CU-CS-902-00, Department of Computer Science, University of Colorado.
[Carzaniga et al. 2001] Carzaniga, A., Rosenblum, D. S. e Wolf, A. L. (2001). Design
and evaluation of a wide-area event notication service. ACM Transactions on Com-
puter Systems, 19(3):332383.
[Carzaniga et al. 2004] Carzaniga, A., Rutherford, M. J. e Wolf, A. L. (2004). A routing
scheme for content-based networking. Em IEEE INFOCOM, pginas 918928.
[Carzaniga e Wolf 2003] Carzaniga, A. e Wolf, A. L. (2003). Forwarding in a content-
based network. Em ACM SIGCOMM, pginas 163174.
[Castro et al. 2002] Castro, M., Druschel, P., Hu, Y. C. e Rowstron, A. (2002). Exploiting
network proximity in distributed hash tables. Em International Workshop on Future
Directions in Distributed Computing - FuDiCo, pginas 5255.
[Che et al. 2002] Che, H., Tung, Y. e Wang, Z. (2002). Hierarchical web caching sys-
tems: Modeling, design and experimental results. IEEE Journal on Selected Areas in
Communications, 20(7):13051314.
[Che et al. 2001] Che, H., Wang, Z. e Tung, Y. (2001). Analysis and design of hierarchi-
cal web caching systems. Em IEEE INFOCOM, pginas 14161424.
[Cheriton e Gritter 2000] Cheriton, D. e Gritter, M. (2000). TRIAD: A new next genera-
tion Internet architecture. Relatrio tcnico, Computer Science Department, Stanford
University.
[Cho et al. 2012] Cho, K., Lee, M., Park, K., Kwon, T. T., Choi, Y. e Pack, S. (2012).
WAVE: Popularity-based and collaborative in-network caching for content-oriented
networks. Em Workshop on Emerging Design Choices in Name-Oriented Networking
- NOMEN.
[Chockler et al. 2007] Chockler, G., Melamed, R., Tock, Y. e Vitenberg, R. (2007). Spi-
derCast: a scalable interest-aware overlay for topic-based pub/sub communication. Em
ACM International Conference on Distributed Event-Based Systems - DEBS, pginas
1425.
[Choi et al. 2009] Choi, J., Han, J., Cho, E., Kwon, T., Kim, H. e Choi, Y. (2009). Per-
formance comparison of content-oriented networking alternatives: A hierarchical tree
versus a at distributed hash table. Em IEEE Conference on Local Computer Networks
- LCN, pginas 253256.
[Choi et al. 2011] Choi, J., Han, J., Cho, E., Kwon, T. T. e Choi, Y. (2011). A survey
on content-oriented networking for efcient content delivery. IEEE Communications
Magazine, 49(3):121127.
[Clarke et al. 2001] Clarke, D. E., Elien, J.-E., Ellison, C. M., Fredette, M., Morcos, A. e
Rivest, R. L. (2001). Certicate chain discovery in SPKI/SDSI. Journal of Computer
Security, 9(4):285322.
[Costa e Duarte 2003] Costa, L. H. M. K. e Duarte, O. C. M. B. (2003). Roteamento mul-
ticast na Internet. Em Minicursos do Simpsio Brasileiro de Redes de Computadores -
SBRC.
[Dannewitz et al. 2010] Dannewitz, C., Golic, J., Ohlman, B. e Ahlgren, B. (2010). Se-
cure naming for a network of information. Em IEEE INFOCOM Workshops, pginas
16.
[Deering 1989] Deering, S. (1989). Host extensions for IP multicasting. IETF Network
Working Group RFC 1112.
[Diallo et al. 2011] Diallo, M., Fdida, S., Sourlas, V., Flegkas, P. e Tassiulas, L. (2011).
Leveraging caching for Internet-scale content-based publish/subscribe networks. Em
IEEE International Communications Conference - ICC, pginas 15.
[Eugster et al. 2003] Eugster, P., Felber, P., Guerraoui, R. e Kermarrec, A. (2003). The
many faces of publish/subscribe. ACM Computing Surveys, 35(2):114131.
[Feamster et al. 2007] Feamster, N., Gao, L. e Rexford, J. (2007). How to lease the Inter-
net in your spare time. ACM SIGCOMM Computer Communication Review, 37(1):61
64.
[Fotiou et al. 2010] Fotiou, N., Nikander, P., Trossen, D. e Polyzos, G. (2010). Develo-
ping information networking further: From PSIRP to PURSUIT. Em ICST BROAD-
NETS.
[Fricker et al. 2012] Fricker, C., Robert, P., Roberts, J. e Sbihi, N. (2012). Impact of
trafc mix on caching performance in a content-centric network. Em Workshop on
Emerging Design Choices in Name-Oriented Networking - NOMEN.
[Ganesan et al. 2004] Ganesan, P., Gummadi, K. e Garcia-Molina, H. (2004). Canon in
G major: Designing DHTs with hierarquical structure. Em International Conference
on Distributed Computing Systems - ICDCS, pginas 263272.
[Gao et al. 2006] Gao, Y., Deng, L., Kuzmanovic, A. e Chen, Y. (2006). Internet cache
pollution attacks and countermeasures. EmIEEE International Conference on Network
Protocols - ICNP, pginas 5464.
[Ghodsi et al. 2011a] Ghodsi, A., Koponen, T., Raghavan, B., Shenker, S., Singla, A. e
Wilcox, J. (2011a). Information-centric networking: seeing the forest for the trees. Em
ACM Workshop on Hot Topics in Networks - HotNets, pginas 1:11:6.
[Ghodsi et al. 2011b] Ghodsi, A., Koponen, T., Rajahalme, J., Sarolahti, P. e Shenker, S.
(2011b). Naming in content-oriented architectures. Em ACM SIGCOMM Workshop
on Information-Centric Networking - ICN, pginas 16.
[Holbrook e Cain 2006] Holbrook, H. e Cain, B. (2006). Source-specic multicast for
IP.
[Jacobson et al. 2009a] Jacobson, V., Smetters, D., Thornton, J., Plass, M., Briggs, N. e
Braynard, R. (2009a). Networking named content. Em International Conference on
emerging Networking EXperiments and Technologies - CoNEXT.
[Jacobson et al. 2009b] Jacobson, V., Smetters, D. K., Briggs, N. H., Plass, M. F.,
Stewart, P., Thornton, J. D. e Braynard, R. L. (2009b). VoCCN: voice-over content-
centric networks. Em Re-Architecting the Internet Workshop - ReARCH, pginas 16.
[Jacobson et al. 2012] Jacobson, V., Smetters, D. K., Thornton, J. D., Plass, M., Briggs,
N. e Braynard, R. (2012). Networking named content. Communications of the ACM,
55(1):117124.
[Jokela et al. 2009] Jokela, P., Zahemszky, A., Arianfar, S., Nikander, P. e Esteve, C.
(2009). LIPSIN: Line speed publish/subscribe inter-networking. Em ACM SIGCOMM,
pginas 195206.
[Katsaros et al. 2011] Katsaros, K. V., Xylomenos, G. e Polyzos, G. C. (2011). MultiCa-
che: An overlay architecture for information-centric networking. Computer Networks,
55(4):936947.
[Koponen et al. 2007] Koponen, T., Shenker, S., Stoica, I., Chawla, M., Chun, B., Ermo-
linsky, A. e Kim, K. (2007). A data-oriented (and beyond) network architecture. Em
ACM SIGCOMM, pginas 181192.
[Kumar et al. 2005] Kumar, A., Xu, J. e Zegura, E. W. (2005). Efcient and scalable
query routing for unstructured peer-to-peer networks. Em IEEE INFOCOM, pginas
11621173.
[Lagutin et al. 2010] Lagutin, D., Visala, K. e Tarkoma, S. (2010). Publish/subscribe for
Internet: PSIRP perspective. Em Towards the Future Internet - Emerging Trends from
European Research, chapter 8, pginas 7584. IOS Press.
[Lee et al. 2011] Lee, M., Cho, K., Park, K., Kwon, T. e Choi, Y. (2011). SCAN: Scalable
content routing for content-aware networking. Em IEEE International Communicati-
ons Conference - ICC, pginas 15.
[Lu et al. 2004] Lu, Y., Abdelzaher, T. F. e Saxena, A. (2004). Design, implementation,
and evaluation of differentiated caching services. IEEE Transactions on Parallel and
Distributed Systems, 15(5):440452.
[Majumder et al. 2009] Majumder, A., Shrivastava, N., Rastogi, R. e Srinivasan, A.
(2009). Scalable content-based routing in pub/sub systems. Em IEEE INFOCOM,
pginas 567575.
[Martins e Duarte 2010] Martins, J. L. e Duarte, S. (2010). Routing algorithms for
content-based publish/subscribe systems. IEEE Communications Surveys and Tuto-
rials, 12(1):3958.
[Mealling e Denenberg 2002] Mealling, M. e Denenberg, R. (2002). Report from the
Joint W3C/IETF URI Planning Interest Group: Uniform Resource Identiers (URIs),
URLs, and Uniform Resource Names (URNs): Clarications and Recommendations.
IETF Network Working Group RFC 3305.
[Moraes et al. 2008] Moraes, I. M., Campista, M. E. M., Moreira, M. D. D., Rubinstein,
M. G., Costa, L. H. M. K. e Duarte, O. C. M. B. (2008). Distribuio de vdeo sobre
redes par-a-par: Arquiteturas, mecanismos e desaos. Em Minicursos do Simpsio
Brasileiro de Redes de Computadores - SBRC, pginas 115171.
[Niven-Jenkins et al. 2012] Niven-Jenkins, B., Faucheur, F. L. e Bitar, N. (2012). Con-
tent Distribution Network Interconnection (CDNI) problem statement. IETF Network
Working Group Internet-Draft (Work In Progress).
[Passarella 2012] Passarella, A. (2012). A survey on content-centric technologies for the
current Internet: CDN and P2P solutions. Computer Communications, 35(1):132.
[Perino e Varvello 2011] Perino, D. e Varvello, M. (2011). A reality check for content
centric networking. Em ACM SIGCOMM Workshop on Information-Centric Networ-
king - ICN, pginas 4449.
[Peyravian et al. 1998] Peyravian, M., Roginsky, A. e Kshemkalyani, A. D. (1998). On
probabilities of hash value matches. Computers and Security, 17(2):171176.
[Plagemann et al. 2005] Plagemann, T., Goebel, V., Mauthe, A., Mathy, L., Turletti, T.
e Urvoy-Keller, G. (2005). From content distribution networks to content networks -
issues and challenges. Internation Journal for the Computer and Telecommunications
Industry, 29:551566.
[Podlipnig e Bszrmenyi 2003] Podlipnig, S. e Bszrmenyi, L. (2003). A survey of
web cache replacement strategies. ACM Computing Surveys, 35(4):374398.
[Popescu et al. 2005] Popescu, B. C., van Steen, M., Crispo, B., Tanenbaum, A. S., Sa-
cha, J. e Kuz, I. (2005). Securely replicated web documents. Em IEEE International
Parallel and Distributed Processing Symposium - IPDPS, pginas 104b104b.
[Psaras et al. 2011] Psaras, I., Clegg, R. G., Landa, R., Chai, W. K. e Pavlou, G. (2011).
Modelling and evaluation of CCN-caching trees. Em IFIP NETWORKING11.
[Ratnasamy et al. 2001] Ratnasamy, S., Francis, P., Handley, M., Karp, R. e Shenker, S.
(2001). A scalable content-addressable network. Em ACM SIGCOMM, pginas 161
172.
[Ratnasamy et al. 2002] Ratnasamy, S., Stoica, I. e Shenker, S. (2002). Routing algo-
rithms for DHTs: Some open questions. Em International Workshop on Peer-to-Peer
Systems - IPTPS, pginas 4552.
[Rosensweig e Kurose 2009] Rosensweig, E. J. e Kurose, J. (2009). Breadcrumbs: Ef-
cient, best-effort content location in cache networks. Em IEEE INFOCOM, pginas
26312635.
[Rosensweig et al. 2010] Rosensweig, E. J., Kurose, J. e Towsley, D. (2010). Approxi-
mate models for general cache networks. Em IEEE INFOCOM, pginas 19.
[Rossi e Rossini 2011a] Rossi, D. e Rossini, G. (2011a). Caching performance of content
centric networks under multi-path routing (and more). Relatrio tcnico, Telecom
ParisTech.
[Rossi e Rossini 2011b] Rossi, D. e Rossini, G. (2011b). A dive into the caching perfor-
mance of content centric networking. Relatrio tcnico, Telecom ParisTech.
[Rossi e Rossini 2012] Rossi, D. e Rossini, G. (2012). On sizing CCN content store by
exploiting topological information. Em Workshop on Emerging Design Choices in
Name-Oriented Networking - NOMEN.
[Rowstron e Druschel 2001] Rowstron, A. e Druschel, P. (2001). Pastry: Scalable, de-
centralized object location, and routing for large-scale peer-to-peer systems. Em
IFIP/ACM International Conference on Distributed Systems Platforms Heidelberg -
Middleware, pginas 329350.
[Saltzer et al. 1984] Saltzer, J. H., Reed, D. P. e Clark, D. D. (1984). End-to-end argu-
ments in system design. ACM Transactions on Computer Systems, 2(4):277288.
[Sandvine 2011] Sandvine (2011). Global Internet phenomena report. Relatrio tcnico,
Sandvine.
[Singla et al. 2010] Singla, A., Godfrey, B., Fall, K. R., Iannaccone, G. e Ratnasamy, S.
(2010). Scalable routing on at names. Em International Conference on emerging
Networking EXperiments and Technologies - CoNEXT, pginas 20:120:12.
[Smetters e Jacobson 2009] Smetters, D. e Jacobson, V. (2009). Securing network con-
tent. Relatrio Tcnico TR-2009-1, Xerox Palo Alto Research Center - PARC.
[Song et al. 2012] Song, H., Zong, N., Yang, Y. e Alimi, R. (2012). DECoupled Appli-
cation Data Enroute (DECADE) problem statement. IETF Network Working Group
Internet-Draft (Work In Progress).
[Sourlas et al. 2011] Sourlas, V., Flegkas, P., Paschos, G. S., Katsaros, D. e Tassiulas, L.
(2011). Storage planning and replica assignment in content-centric publish/subscribe
networks. Computer Networks, 55(18):40214032.
[Stais et al. 2011] Stais, C., Diamantis, D., Aretha, C. e Xylomenos, G. (2011). VoPSI:
Voice over a publish-subscribe internetwork. Em Future Network and Mobile Summit
- FutureNetw, pginas 18.
[Stoica et al. 2003] Stoica, I., Morris, R., Liben-Nowell, D., Karger, D. R., Kaashoek,
M. F., Dabek, F. e Balakrishnan, H. (2003). Chord: a scalable peer-to-peer lookup
protocol for internet applications. IEEE/ACM Transactions on Networking, 11(1):17
32.
[Trossen e Biczk 2010] Trossen, D. e Biczk, G. (2010). Not paying the truck dri-
ver: Differentiated pricing for the future internet. Em Re-Architecting the Internet
Workshop - ReARCH, pginas 16.
[Trossen et al. 2010] Trossen, D., Sarela, M. e Sollins, K. (2010). Arguments for an
information-centric internetworking architecture. ACM SIGCOMM Computer Com-
munication Review, 40(2):2633.
[Tsilopoulos e Xylomenos 2011] Tsilopoulos, C. e Xylomenos, G. (2011). Supporting
diverse trafc types in information centric networks. Em ACM SIGCOMM Workshop
[Visala et al. 2009] Visala, K., Lagutin, D. e Tarkoma, S. (2009). LANES: An inter-
domain data-oriented routing architecture. Em Re-Architecting the Internet Workshop
- ReARCH, pginas 5560.
[Walsh et al. 2004] Walsh, M., Balakrishnan, H. e Shenker, S. (2004). Untangling the
web from DNS. Em USENIX/ACM Symposium on Networked Systems Design and
Implementation - NSDI, pginas 1717.
[Wang 1999] Wang, J. (1999). A survey of web caching schemes for the Internet. ACM
SIGCOMM Computer Communication Review, 29(5):3646.
[Wang et al. 2004] Wang, L., Park, K. S., Pang, R., Pai, V. e Peterson, L. (2004). Relia-
bility and security in the CoDeeN content distribution network. Em USENIX Annual
Technical Conference - ATC, pginas 1414.
[Wang et al. 2005] Wang, X., Yin, Y. L. e Yu, H. (2005). Finding collisions in the full
SHA-1. Em CRYPTO, volume 3621, pginas 1736.
[Xie et al. 2012] Xie, M., Widjaja, I. e Wang, H. (2012). Enhancing cache robustness for
content-centric networking. Em IEEE INFOCOM.
[Zhang et al. 2010] Zhang, L., Estrin, D., Burke, J., Jacobson, V., Thornton, J., Smetters,
D. K., Zhang, B., Tsudik, G., Claffy, K., Krioukov, D., Massey, D., Papadopoulos,
C., Abdelzaher, T., Wang, L., Crowley, P. e Yeh, E. (2010). Named Data Networking
(NDN) project. Relatrio Tcnico NDN-0001, Xerox Palo Alto Research Center -
PARC.
[Zhang et al. 2011] Zhang, N., Lev, T. e Hmminen, H. (2011). Two-sidedness of
internet content delivery. Em IEEE Conference on Telecommunications Internet and
Media Techno-Economics - CTTE, pginas 1618.
[Zhu et al. 2011] Zhu, Z., Wang, S., Yang, X., Jacobson, V. e Zhang, L. (2011). ACT:
audio conference tool over named data networking. Em ACM SIGCOMM Workshop
ndice por Autor
A
Abelm, A. J. G. . . . . . . . . . . . . . . . . . . . 99
B
Barcellos, M. P. . . . . . . . . . . . . . . . . . . . . 59
Bays, L. R. . . . . . . . . . . . . . . . . . . . . . . . . 59
C
Campista, M. E. M. . . . . . . . . . . . . . . . . . . 1
Cardoso, K. V. . . . . . . . . . . . . . . . . . . . . . 99
Carvalho, T. C. M. B. . . . . . . . . . . . . . . . 99
Costa, L. H. M. K. . . . . . . . . . . . . . . . . . . . 1
D
da Fonseca, N. L. S. . . . . . . . . . . . . . . . . 59
de Amorim, M. D. . . . . . . . . . . . . . . . . . . . 1
de Brito, G. M. . . . . . . . . . . . . . . . . . . . 211
Duarte, O. C. M. B. . . . . . . . . . . . . . . . . . . 1
F
Florissi, P. . . . . . . . . . . . . . . . . . . . . . . . . . . 1
G
Gaspary, L. P. . . . . . . . . . . . . . . . . . . . . . . 59
Guedes, D. . . . . . . . . . . . . . . . . . . . . . . . 160
M
Machado, I. . . . . . . . . . . . . . . . . . . . . . . . 99
Madeira, E. R. M. . . . . . . . . . . . . . . . . . . 59
Marcondes, C. A. C. . . . . . . . . . . . . . . . . 99
Martins, J. . . . . . . . . . . . . . . . . . . . . . . . . . 99
Miers, C. C. . . . . . . . . . . . . . . . . . . . . . . . 99
Monteiro, J. A. S. . . . . . . . . . . . . . . . . . . 99
Moraes, I. M. . . . . . . . . . . . . . . . . . . . . . 211
N
Nascimento, V. . . . . . . . . . . . . . . . . . . . . 99
Nunes, R. V. . . . . . . . . . . . . . . . . . . . . . . 160
O
Oliveira, R. R. . . . . . . . . . . . . . . . . . . . . . 59
R
Rodrigues, H. . . . . . . . . . . . . . . . . . . . . . 160
Rothenberg, C. E. . . . . . . . . . . . . . . . . . . 99
Rubinstein, M. G. . . . . . . . . . . . . . . . . . . . 1
S
Salvador, M. . . . . . . . . . . . . . . . . . . . . . . . 99
V
Vieira, L. F. M. . . . . . . . . . . . . . . . . . . . 160
Vieira, M. M. . . . . . . . . . . . . . . . . . . . . . 160
Velloso, P. B. . . . . . . . . . . . . . . . . . . . . . 211

Livrodeminicursos PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Livrodeminicursos PDF

Uploaded by

Copyright:

Available Formats

XXX Simpsio Brasileiro de Redes de Computadores e

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

AO esta na tabela endereco/porta?

) para modelar a popularidade dos contedos [Breslau et al.

You might also like