Consegui 2012

CONSEGI 2012 V Congresso Internacional Software Livre e Governo Eletrnico
Inovando Servios com Mobilidade Digital
Ministrio das relaes exteriores
Ministro de Estado Secretrio-Geral
Embaixador Antonio de Aguiar Patriota Embaixador Ruy Nunes Pinto Nogueira
Fundao alexandre de GusMo
Presidente Instituto de Pesquisa de Relaes Internacionais Centro de Histria e Documentao Diplomtica Diretor
Embaixador Jos Vicente de S Pimentel
Embaixador Maurcio E. Cortes Costa
A Fundao Alexandre de Gusmo, instituda em 1971, uma fundao pblica vinculada ao Ministrio das Relaes Exteriores e tem a finalidade de levar sociedade civil informaes sobre a realidade internacional e sobre aspectos da pauta diplomtica brasileira. Sua misso promover a sensibilizao da opinio pblica nacional para os temas de relaes internacionais e para a poltica externa brasileira.
Ministrio das Relaes Exteriores Esplanada dos Ministrios, Bloco H Anexo II, Trreo, Sala 1 70170-900 Braslia, DF Telefones: (61) 2030-6033/6034 Fax: (61) 2030-9125 Site: www.funag.gov.br
CONSEGI 2012 V Congresso Internacional Software Livre e Governo Eletrnico

Inovando Servios com Mobilidade Digital
Braslia, 2012
Direitos de publicao reservados Fundao Alexandre de Gusmo Ministrio das Relaes Exteriores Esplanada dos Ministrios, Bloco H Anexo II, Trreo 70170-900 Braslia DF Telefones: (61) 2030-6033/6034 Fax: (61) 2030-9125 Site: www.funag.gov.br E-mail: funag@itamaraty.gov.br
Equipe Tcnica: Eliane Miranda Paiva Fernanda Antunes Siqueira Gabriela Del Rio de Rezende Jess Nbrega Cardoso Rafael Ramos da Luz Wellington Solon de Souza Lima de Arajo Programao Visual e Diagramao: Grfica e Editora Ideal
Impresso no Brasil 2012

C749 Congresso internacional software livre e governo eletrnico (5: 2012: Belm, Brasil). Congresso internacional software livre e governo eletrnico: inovando servios com mobilidade digital: 3 a 7 de dezembro de 2012, Belm, Brasil. Braslia-DF : FUNAG, 2012. 149 p.; 23 cm. Apresentao de Marcos Vinicius Ferreira Mazoni. Textos de Benedicto Fonseca Filho, Alisson Wilker Andrade, Ronaldo Agra, Viviane Malheiros, Djamel F. H. Sadok, Fernando N. N. Farias, Joo J. Salvatti, Antnio J. G. Abelm, Flvio Gomes da Silva Lisboa. Inclui bibliografia. ISBN: 978-85-7631-411-0 1. Software livre. 2. Governo. .I. Servio Federal de Processamento de Dados SERPRO. II. Fundao Alexandre de Gusmo - FUNAG. III. CONSEGI. CDU: 004.4::35
Ficha catalogrfica elaborada pela bibliotecria Talita Daemon James CRB-7/6078 Depsito Legal na Fundao Biblioteca Nacional conforme Lei n 10.994, de 14/12/2004.
Apresentao
com grande satisfao que apresento este livro cujas pginas renem um compndio de textos relativos a tecnologias emergentes no mundo das Tecnologias da Informao e Comunicao (TICs). A descrio destas tecnologias so reflexes acerca de projetos e aes em curso nacional e internacionalmente. Elas compem temas que sero amplamente discutidos durante o V Congresso Internacional de Software Livre e Governo Eletrnico CONSEGI. O CONSEGI 2012 ter vrios eixos temticos em torno do tema software livre, com destaque para o tema mobilidade digital em sistemas de governo. Inmeros governos do mundo inteiro incrementaram, em 2012, a disponibilizao de servios de governo em plataformas mveis, principalmente em plataformas baseadas em sistema operacional Linux. A disponibilizao de servios cresce na mesma proporo que cresce o acesso Internet mvel, sendo que o Brasil o lder em crescimento de banda larga mvel na Amrica Latina. Alm disto, o Brasil hoje o quarto maior mercado de mobilidade no mundo, com mais de 260 milhes de conexes mveis ativas, ou seja, a mobilidade o maior vetor para disponibilizao de servios de governo eletrnico em banda larga no pas. A utilizao de plataformas mveis tem a enorme capacidade de redefinir o tema governo eletrnico por meio de uma nova arquitetura, que pode ser resumida, no nvel mais geral, a partir de trs objetivos. So estes: - mG2G, Governo mvel para Governo resolutividade da mquina pblica a partir de uma lista de servios disponveis em lojas virtuais;
MARCOS VINICIUS FERREIRA MAZONI
- mG2E, Governo mvel para Empresas reduo do custo das obrigaes por meio de aplicativos de governo; - mG2C, Governo mvel para Cidados provimento de direitos e cidadania a partir de acesso mvel pervasivo. A inovao trazida pela mobilidade digital tambm est na capacidade de se criar novas interfaces humano-computador para servios de governo j existentes em plataformas fixas, ou seja, uma utilizao prtica de reuso a partir de uma arquitetura orientada a servios. Novas inovaes em hardwares para dispositivos mveis so criadas a todo o instante e hoje vemos uma profuso de fabricantes e modelos que vo desde TV conectada a smartphones, passando por ultrabooks e tablets, criando uma diversidade de oferta que beneficia em muito a populao. Finalmente, espero que este material auxilie na difuso do conhecimento de temas tecnolgicos emergentes e que seja um convite participao colaborativa para o crescimento da comunidade de software livre. Boa leitura! Marcos Vinicius Ferreira Mazoni Presidente do SERPRO
Sumrio
Introduo...........................................................................................................9 Benedicto Fonseca Filho Mobilidade digital aplicada ao governo brasileiro ..................................13 Alisson Wilker Andrade, Ronaldo Agra, Viviane Malheiros Mobilidade digital: tecnologias e tendncias ............................................41 Djamel F. H. Sadok Experimentao no futuro da Internet: pesquisa utilizando virtualizao e o framework OpenFlow ......................................................55 Fernando N. N. Farias, Joo J. Salvatti, Antnio J. G. Abelm Beyonder mobilidade digital livre com PHP........................................139 Flvio Gomes da Silva Lisboa
Introduo Benedicto Fonseca Filho
As Tecnologias da Informao e das Comunicaes (TICs) vm assumindo um papel cada vez mais central na sociedade, medida que transformam o modo como os indivduos se comunicam e interagem e se tornam ferramentas bsicas, essenciais para a ampliao da produtividade, em praticamente todos os setores da economia. Nesse contexto, a intensificao das discusses sobre temas relacionados s TICs, tanto no plano interno quanto no plano internacional, um desdobramento natural, dada a importncia estratgica e o crescente interesse por essa rea. No plano interno, destacam-se os esforos para universalizao do acesso Internet; as iniciativas para modernizar a administrao pblica, conferindo maior transparncia e abertura na relao com os cidados, por meio da Internet; bem como a utilizao dessas tecnologias como ferramenta para modernizar e fortalecer a economia. No plano internacional, a necessidade de coordenao de esforos para enfrentar os desafios dessa nova realidade enfatizada na Agenda de Tnis para a Sociedade da Informao (documento final da Cpula Mundial sobre Sociedade da Informao), a qual reconhece a crescente importncia do papel das TICs no apenas como um meio de comunicao, mas tambm como habilitadoras do desenvolvimento e ferramentas para o cumprimento de metas e objetivos acordados internacionalmente, dentre eles as Metas de Desenvolvimento do Milnio. Nesse contexto, a Agenda de Tnis reconhece que a superao do hiato digital requer investimentos adequados e sustentveis na infraestrutura e nos servios de TICs, bem como a construo de capacidades e a transferncia de tecnologia.
9
BENEDICTO FONSECA FILHO
O lanamento recente do Plano TI Maior pelo Ministrio da Cincia, Tecnologia e Inovao evidencia a prioridade que o governo brasileiro confere a esses temas. O fomento s empresas start-ups, a atrao de centros globais de pesquisa e desenvolvimento no campo das TICs, com vistas formao de uma rede local de desenvolvimento cientfico e tecnolgico, bem como o estabelecimento de polos de negcios internacionais com o objetivo de contribuir para o desenvolvimento e a internacionalizao de empresas brasileiras que atuam nessa rea, so objetivos centrais do TI Maior. Com enfoque diferente, porm igualmente relevante do ponto de vista do fortalecimento da sociedade da informao, o Plano Nacional de Banda Larga (PNBL), lanado em maio de 2010 pelo Ministrio das Comunicaes no apenas visa massificao do acesso Internet em banda larga no Brasil, por meio da ampliao da infraestrutura e da reduo dos preos desse servio, como tambm tem por objetivo promover a difuso dos servios de governo eletrnico e a capacitao da populao para o uso das tecnologias da informao. Ambos os planos oferecem amplas possibilidades de cooperao na esfera internacional. No caso do PNBL, em particular, a ampliao da infraestrutura nacional coincide com esforo regional para integrao das redes de fibra tica entre os pases da Amrica do Sul. A formao do chamado anel tico sul-americano permitir a reduo dos custos de interconexo internacional, o que, por sua vez, contribuir para a oferta de servios de banda larga a preos menores na regio. A concepo do Congresso Internacional Software Livre e Governo Eletrnico (CONSEGI) confirma, de um lado, a centralidade dessas questes, e evidencia, de outro, a necessidade de articular o debate nacional com a cooperao internacional. Nesta sua quinta edio, as discusses em torno do tema principal da mobilidade ensejaro o tratamento de questes que tambm vm sendo amplamente discutidas no plano internacional, entre as quais mobilidade digital, segurana ciberntica, informtica e sociedade e governo eletrnico. A adoo de um pas focal em cada edio do CONSEGI tambm contribui para o intercmbio de experincias e para a explorao de convergncias com outros pases. Com base nesse cenrio e em linha com as estratgias e prioridades definidas internamente, a atuao internacional do Itamaraty busca, em coordenao com os rgos competentes da administrao pblica, identificar reas de interesse comum e explorar oportunidades de cooperao internacional em reas como governana da Internet, incluso digital, governo eletrnico e software livre.
10
INTRODUO
No mbito regional, cabe meno Estratgia para a Sociedade da Informao na Amrica Latina e no Caribe (eLAC), que em seu Plano de Ao mais recente estabelece metas e prioridades para a regio em matria de acesso, em especial a massificao da infraestrutura de acesso Internet em banda larga; governo eletrnico, visto como direito dos cidados, devendo ser transacional e participativo; meio ambiente, em especial o uso das Tecnologias da Informao e Comunicao (TICs) para combater a mudana do clima e prevenir desastres naturais; desenvolvimento produtivo e inovao, incluindo fomento pesquisa e ao desenvolvimento de TICs na regio; e educao. O Projeto Mercosul Digital, por sua vez, tambm contribui para a difuso das TICs entre os pases que integram o bloco, a partir do objetivo de promover polticas e estratgias comuns na rea da Sociedade da Informao, atravs da capacitao, da harmonizao dos regulamentos, da implementao da infraestrutura tcnica e do intercmbio de conhecimentos. A criao da Escola Virtual do Mercosul, que oferece cursos de capacitao atravs de plataforma virtual, um dos resultados concretos dessa iniciativa. Valeria mencionar, ainda, outras iniciativas de cooperao bilateral que o Brasil vem desenvolvendo tanto com pases desenvolvidos, como com pases em desenvolvimento. Com a Unio Europeia mantemos Dilogo anual sobre Sociedade da Informao, com o objetivo de dar continuidade cooperao e troca de experincias em Pesquisa e Desenvolvimento na rea de TICs, Regulao, Desenvolvimento da Banda Larga, Transmisso Digital, Governana da Internet, Contedos Digitais e Computao em Nuvem. Alm de proveitoso intercmbio em todas essas reas, o lanamento de editais conjuntos para o desenvolvimento de projetos de cooperao em pesquisa e desenvolvimento na rea de TICs tem permitido auferir resultados concretos da cooperao com o lado europeu. Afigura-se igualmente promissora a concertao bilateral no campo da governana da Internet, tema que, a partir deste ano, dever figurar na agenda de discusses entre os dois parceiros. Com os Estados Unidos, institumos Grupo de Trabalho sobre Internet e TICs como o objetivo de promover intercmbio de informaes e explorar, onde cabvel, oportunidades de cooperao, inclusive em temas relacionados governana global da Internet. O Canad outro pas com o qual o Brasil tem buscado maior aproximao na rea de TICs. O Plano de Ao conjunta em cincia e tecnologia adotado no incio deste ano inclui, entre suas prioridades, o estabelecimento de cooperao bilateral em reas como computao em nuvem e contedos digitais, bem como a organizao, pelo Brasil, em
11
BENEDICTO FONSECA FILHO
cooperao com o Canad, da Conferncia Brasil 3.0, inspirada em evento anual semelhante organizado naquele pas pelo qual se articulam os setores privado, acadmico e governamental em busca de solues digitais para demandas da sociedade. A primeira edio da Conferncia Brasil 3.0 ser realizada em Joo Pessoa, nos dias 3 e 4 de dezembro prximo. No caso do Uruguai, pas focal do CONSEGI 2012, cabe ressaltar a criao, este ano, pela Presidenta Dilma Rousseff e pelo Presidente Jos Mujica, de um Grupo de Alto Nvel encarregado de consolidar um Plano de Ao para o Desenvolvimento Sustentvel e a Integrao Brasil-Uruguai, o qual inclui, entre as reas prioritrias, Cincia, Tecnologia e Inovao e Comunicao e Informao. No mbito das TICs, os esforos estaro voltados para a implementao de plataforma de e-learning, com vistas formao de recursos humanos, criao de Centro Binacional de Tecnologias da Informao e das Comunicaes, bem como para a promoo da interconexo das redes acadmicas avanadas de ambos os pases. Nesse contexto amplo, o Ministrio das Relaes Exteriores reafirma o apoio ao Congresso Internacional de Software Livre e Governo Eletrnico, no entendimento de que se encontra em sintonia com as prioridades nacionais nessa rea e contribui para fomentar o debate sobre temas relevantes no campo das TICs, com ampla participao de todos os setores da sociedade brasileira, alm de buscar fortalecimento da interao com parceiros-chave.
12
Mobilidade digital aplicada ao governo brasileiro Alisson Wilker Andrade, Ronaldo Agra, Viviane Malheiros1
1. A mobilidade e sua influncia no cotidiano dos brasileiros O uso de dispositivos mveis possibilita o acesso a servios e informaes a qualquer momento, por meio de redes sem fio e de diversos recursos, como: texto, voz, vdeo, internet, GPS, cmera, msica e televiso. Estes recursos integrados podem melhorar significativamente a prestao de servios, e, em particular, de servios de governo eletrnico. As possibilidades vo muito alm da realizao de chamadas telefnicas, e so aplicveis a diversas reas como: educao, bancria, entretenimento, turismo e sade. Explorar recursos de mobilidade digital uma oportunidade para o governo oferecer servios mais adequados ao cidado brasileiro, alm de ter servios governo-governo mais eficientes e dinmicos. Isto porque a disponibilidade de acesso Internet e o uso de dispositivos mveis cada vez maior no pas. Em 2011, houve um crescimento de quase 100% no total de acessos Internet mvel [1]. Em maio de 2012, a difuso de smartphones j atingia 14% da populao, segundo relatrio da Google sobre o mercado de mobilidade brasileiro [2]. O aumento do uso de smartphones no Brasil tem impactado diretamente o cotidiano dos brasileiros [2]: 42% dos usurios de smartphones acessam diariamente a Internet a partir de seus dispositivos mveis; 80% deles pesquisam um produto no dispositivo antes de comprar; e 31%
1
{alisson-wilker.silva, jose-ronaldo.souza, viviane.malheiros}@serpro.gov.br.
13
ALISSON WILKER ANDRADE, RONALDO AGRA, VIVIANE MALHEIROS
fazem compras a partir do dispositivo [2]. Os smartphones so utilizados principalmente para: comunicar-se (redes sociais, e-mails), manter-se informado (jornais, blogs, revistas) e entreter-se (msica, vdeo, jogos) [2]. A nova forma de executar atividades comuns do dia a dia influencia o relacionamento de empresas com seus clientes. Por exemplo, as empresas adaptam seus sites e propagandas para clientes, que agora chegam a eles atravs de um dispositivo mvel, tanto de dentro de um nibus, como realizando exerccios fsicos num parque da cidade. Da mesma forma, para assuntos relacionados ao governo, pode-se imaginar um cidado consultando sua certido eleitoral ou sua matrcula na universidade por meio de um dispositivo mvel. Na perspectiva do Serpro, o desenvolvimento de aplicativos para dispositivos mveis uma oportunidade de oferecer solues diferenciadas para o governo e de manter-se como referncia de tecnologia da informao, mostrando-se alinhado com as tendncias de mercado e com as necessidades dos brasileiros. Alm de ser uma grande oportunidade, o uso abrangente de computao mvel para o governo , tambm, um grande desafio. fundamental ter infraestrutura e dominar o ambiente para explorar adequadamente questes relacionadas a particularidades dos dispositivos mveis, como: (i) limitaes de memria, bateria, processamento, tamanho de tela e teclado, capacidade de armazenamento, largura de banda e consumo de energia; (ii) grande diversidade de aparelhos e plataformas de desenvolvimento (proprietrias e livres); (iii) segurana; e (iv) forma de publicao de aplicativos. Alguns rgos e empresas do governo j possuem aplicativos e contedo web adaptado para dispositivos mveis (especialmente, tablets e smartphones) [3] [4] [5] [6]. Em 2012, o Serpro desenvolveu e publicou aplicaes mveis para a Receita Federal do Brasil [7] [8] [9] [10] e para o DNIT (Departamento Nacional de Infraestrutura de Transportes) [11] [12]. O desenvolvimento destas solues suscitou o estudo das caractersticas do desenvolvimento para dispositivos mveis e discusses arquiteturais abrangentes. A experincia obtida com estes projetos est sendo utilizada na definio de aes e modelos corporativos para habilitar o Serpro a oferecer solues inovadoras para o governo. Neste contexto, este artigo apresenta: (i) caractersticas do desenvolvimento de aplicativos para dispositivos mveis; (ii) possveis arquiteturas de aplicaes para dispositivos mveis e como escolher a mais adequada a partir de seus requisitos; e (iii) dois estudos de caso de mobilidade para o governo desenvolvidos pelo Serpro.
14
MOBILIDADE DIGITAL APLICADA AO GOVERNO BRASILEIRO
2. Caractersticas do desenvolvimento para dispositivos mveis
Figura 1: Novas possibilidades com o uso de dispositivos mveis.
O desenvolvimento para dispositivos mveis deve levar em considerao uma experincia de usurio diferente daquela observada em estaes de trabalho. Com os novos recursos (como leitura de cdigo, reconhecimento facial, GPS e comunicao por aproximao), processos podem ser eliminados e melhorados; e a interao homem-mquina pode ser repensada (Figura 1). Ao mesmo tempo, a relao tempo e espao com os servios diferente.
Fatores a serem considerados no desenvolvimento para dispositivos mveis (extrados de [13]) Capacidades de cada plataforma (hardware e software) Memria RAM e de armazenamento Tempo de bateria limitado limitadas Entrada de dados via toques, gestos e voz, Custo de conectividade quando taxada mas lenta para textos por volume de dados Pouca ateno do usurio pelo uso em Telas de tamanho reduzido e aplicaes contextos de movimento, agitao ou que ocupam toda a tela luz solar direta Perda temporria de conectividade por Usabilidade de cada plataforma baixo sinal da rede Baixa largura de banda
Quadro 1: Especificidades do desenvolvimento para dispositivos mveis.

15
3. Arquiteturas de desenvolvimento para dispositivos mveis O desenvolvimento para dispositivos mveis engloba dois cenrios: (i) adaptao de stios e portais para utilizar por meio de navegadores, a partir de qualquer tablet ou smartphone; e (ii) desenvolvimento de aplicaes nativas adequadas para cada plataforma / tipo de dispositivo. Cada um desses cenrios requer uma arquitetura de soluo especfica, que valorize suas caractersticas principais. Ao mesmo tempo, possvel sugerir arquiteturas padres, que facilitem o reuso de cdigo e de infraestrutura. Assim, esta seo apresenta trs arquiteturas: (i) uma arquitetura para desenvolvimento de contedo web mvel, (ii) outra para desenvolvimento de contedo nativo mvel, (iii) e uma terceira arquitetura que chamada hbrida, pois engloba tanto o desenvolvimento nativo como o desenvolvimento web mvel, buscando valorizar o que h de melhor em cada cenrio. 3.1. Arquitetura para desenvolvimento de contedo web mvel O desenvolvimento de aplicaes para dispositivos mveis engloba, dentre outros, a construo de contedo web adaptado para a interao via estes dispositivos (Figura 2). Nesse caso, o usurio acessa um stio ou aplicao web atravs do navegador web de sua preferncia, instalado em seu smartphone ou tablet. Atravs de uma conexo com a internet ou a intranet (2G, 3G, 4G, Wi-Fi ou Bluetooth), o navegador realiza uma requisio ao servidor web que contm o contedo web da aplicao ou stio. Este, por sua vez, ao receber a requisio, identifica qual o dispositivo est solicitando o contedo web e realiza o redirecionamento para a pgina correta, seja um dispositivo mvel ou um computador pessoal. Dessa forma, um nico servidor web pode ser utilizado tanto para desktops como para dispositivos mveis. Por exemplo, o navegador desktop pode acessar o stio <http://www.serpro.gov.br> enquanto o navegador mvel acessa <http://m.serpro.gov.br>, mesmo que ambos tenham feito uma requisio por <http://www.serpro. gov.br>. Nesse caso, a verso do contedo ou da aplicao web acessada pelo dispositivo mvel deve possuir HTML2, CSS3, JavaScript4 e imagens adaptados para as caractersticas desse tipo de dispositivo (p. ex.: tamanho de tela, resoluo e acesso rede) e ao tipo de interao que o
2 3 4
<http://www.w3.org/TR/html/>. <http://www.w3.org/Style/CSS/>. <http://www.w3.org/standards/techs/js>.
16
usurio tem com este (como toque na tela, uso do dispositivo em movimento e entrada de textos limitada).
Figura 2: Viso geral de arquitetura para contedo web mvel.
Alm do servidor web, que disponibiliza recursos estticos do contedo ou aplicao web, um servidor de aplicao pode ser utilizado para gerar recursos dinmicos ou processar as regras de negcio de uma ou mais aplicaes. Para o navegador do dispositivo, essa comunicao entre servidores (web e de aplicao) transparente, ficando assim sua responsabilidade restrita renderizao do contedo recebido. Outra maneira de instanciar esta arquitetura possuir apenas um contedo ou aplicao web e usar layouts diferentes para cada tipo de dispositivo, o que chamado de design responsivo (responsive design). Design Responsivo uma tcnica de estruturao HTML e CSS, na qual a pgina adequa-se ao navegador do usurio sem a necessidade de diversas folhas de estilos para cada resoluo. Nesse caso, o CSS pode utilizar o recurso de media query para identificar o tamanho de tela do navegador e adaptar o layout do contedo ou aplicao web para um tamanho especfico. A vantagem de utilizar essa abordagem o menor custo de manuteno, se comparada alternativa de manter uma verso mvel e outra para desktop. Porm, essa abordagem pode penalizar o desempenho e a navegabilidade da aplicao, visto que as imagens, por exemplo, no so otimizadas para a capacidade do dispositivo [14] [15] [16]. Uma alternativa de soluo para adaptar as imagens do contedo web utilizar imagens vetoriais, como as de formato SVG, por exemplo, as quais podem ser facilmente redimensionadas sem perder a qualidade [17]. A melhor escolha entre essas alternativas deve ser guiada pelo tipo de contedo web, os objetivos de sua publicao e o perfil dos usurios esperados.
17
importante ressaltar tambm que a aplicao ou o contedo web desenvolvido para tablet pode ser bastante diferente daquele desenvolvido com foco em smartphones. Isto porque as dimenses e a resoluo de tela, bem como a forma de uso, so bem distintas entre esses dispositivos. O tamanho de tela e a resoluo maior permitem, e muitas vezes obrigam, que o contedo servido para um tablet seja mais completo e refinado do que aquele oferecido para um smartphone, onde a restrio de espao disponvel na tela muito maior. Assim, normalmente, o contedo servido para smartphones bem mais conciso, principalmente se comparado ao contedo servido para um navegador desktop [18]. Neste caso, tambm pode ser utilizada a tcnica de Design Responsivo para fazer a adaptao do contedo para tablets. Duas grandes vantagens do desenvolvimento de aplicaes e de contedo web em relao aplicao nativa (a ser detalhada nas prximas sees) so: a facilidade e a abrangncia da liberao de novas verses da aplicao. Uma vez que uma nova verso da aplicao disponibilizada no servidor web, automaticamente todos os usurios estaro utilizando a nova verso, sem que qualquer ao adicional do usurio ou do fornecedor daquela aplicao seja necessria. Alm disso, como a linguagem de desenvolvimento geralmente padronizada em HTML, CSS e JavaScript, o mesmo cdigo pode ser executado em qualquer dispositivo que possua navegador compatvel com essas linguagens, no importando os seus sistemas operacionais. Do ponto de vista organizacional, esta arquitetura reduz a complexidade operacional, pois no exige o domnio de diversas linguagens de programao e tecnologias especficas. 3.1.1. Vantagens Familiaridade do usurio com o continer da aplicao ou contedo web, que o seu navegador web de preferncia; Utilizao de um nico endereo (URL) para acessar contedo adaptado para tablets, smartphones e desktops, de forma transparente; Facilidade de implantar novas verses da aplicao, atualizando-se apenas os servidores; Reaproveitamento de cdigo da interface atravs do desenvolvimento com linguagens multiplataforma (HTML, CSS e JavaScript); Reaproveitamento de cdigo da lgica de negcio em aplicaes para desktop, smartphones e tablets;
18
Maior segurana para regras de negcio sensveis, pois elas ficam armazenadas no servidor e no no dispositivo; No depende de aprovao de terceiros para disponibilizar a aplicao em uma store (loja); Desnecessrio instalar contedo no dispositivo mvel do usurio. 3.1.2. Desvantagens Possibilidade de falha ou restrio de desempenho na aplicao devido ao navegador web escolhido pelo usurio; Necessidade de testes criteriosos em diversas verses de navegadores antes da liberao; Limitao de acesso aos recursos de hardware do dispositivo mvel (ex.: cmera, acelermetro) atravs do navegador web; Impossibilidade de acessar o banco de dados SQLite nativo dos ambientes Android e iOS; Inexistncia de um cone de aplicao na tela do dispositivo, embora esse fato possa ser contornado com a criao manual de um atalho para o contedo web na tela principal do dispositivo; Dependncia maior de conectividade com a internet. 3.1.3. Ferramentas de apoio Existem alguns frameworks que facilitam a construo de interfaces adaptadas navegao via telas sensveis ao toque e de tamanho limitado para aplicaes web [19] [20]. Esses frameworks web trabalham, normalmente, com tecnologias padronizadas na Internet, como o HTML5, o JavaScript e o CSS3. Usando essas tecnologias e diretrizes do paradigma de Web Design Responsivo, possvel construir aplicaes web que se adaptam s caractersticas de tela do tablet ou do smartphone, como tamanho, resoluo e profundidade de cores. Um exemplo desse tipo de tecnologia o jQuery Mobile [19]. Este framework facilita a criao de aplicaes web que funcionam nas plataformas mveis e nos navegadores mais populares, como Android, iOS, Windows Phone e BlackBerry. Trata-se de um projeto de software livre com uma comunidade ampla e ativa e com cdigo-fonte hospedado
19
no GitHub5. Seu objetivo garantir a uniformidade, atravs de um conjunto de imagens e folhas de estilos, entre a aplicao web e o estilo visual da plataforma mvel em que est sendo executada. No contexto da construo de portais web, o paradigma de Web Design Responsivo e o framework jQuery Mobile podem ser usados em conjunto com um sistema de gerenciamento de contedo (CMS6), como o Zope/Plone [21] ou o Liferay [22]. Ambos os CMSs possuem suporte nativo construo de portais que se adaptam visualmente para possibilitar a navegao atravs de dispositivos mveis. Dessa forma, com pouco esforo e algum conhecimento de CSS, possvel entregar portais web compatveis com as principais plataformas e navegadores mveis. 3.2. Arquitetura para aplicao nativa mvel Outra possibilidade de desenvolvimento para dispositivos mveis a construo de aplicaes nativas para cada plataforma mvel, como Android, iOS, Blackberry ou Windows Phone (Figura 3). Nesse caso, o desenvolvedor utiliza o ambiente de desenvolvimento e as bibliotecas fornecidas pelo fabricante da plataforma para desenvolver a aplicao. Assim, no caso do Android, o desenvolvedor deve se familiarizar com a sintaxe Java e as bibliotecas do Android, assim como o desenvolvedor para iOS deve se familiarizar com a linguagem Objective-C e suas bibliotecas. A aplicao nativa normalmente tem um visual mais integrado com a plataforma do dispositivo, visto que os componentes visuais como botes, menus e listas, por exemplo, so fornecidos e estilizados pela prpria plataforma. O usurio pode, ento, sentir-se mais confortvel ao utilizar a aplicao nativa, visto que j est familiarizado com as cores, as formas e os comportamentos desses componentes. Alm disso, nesta arquitetura de desenvolvimento, possvel utilizar diversos recursos de hardware do dispositivo, como acelermetro, GPS, bssola e cmera, que normalmente no podem ser acessados diretamente a partir de uma aplicao web executada em um navegador de Internet. Essa possibilidade leva criao de aplicaes muito mais ricas em termos de funcionalidades e integrao com o dispositivo mvel. Uma aplicao que utiliza bssola e GPS, por exemplo, pode conectar-se a um servidor remoto para acessar um banco de dados geogrficos, a fim de representar a posio e a direo do usurio em tempo real. Se estes
5 6
<https://github.com/jquery/jquery-mobile>. Sigla em ingls para Content Management System.
20
recursos forem usados em conjunto com a cmera, possvel identificar objetos e edifcios que estejam vista do usurio, fornecendo mais detalhes a respeito destes. Para o armazenamento de informaes, uma aplicao nativa pode realizar o armazenamento local tanto em arquivos como em banco de dados SQLite. O SQLite um banco de dados transacional leve e multiplataforma utilizado pelas principais plataformas mveis, como Android e iPhone [23]. Ele permite o armazenamento de strings, nmeros e dados binrios e pode ser consultado atravs da linguagem SQL diretamente da aplicao ou via linha de comando. Normalmente, uma aplicao desenvolvida nativamente ser submetida para validao e publicao em uma store7 de aplicaes a partir da qual o usurio poder instal-la em seu dispositivo mvel e, em seguida, acess-la atravs de um cone no menu de aplicaes ou na tela principal do aparelho.
Figura 3: Viso geral de arquitetura para aplicao nativa mvel.
Uma desvantagem da store de aplicaes que toda verso da aplicao deve passar por um novo ciclo de validao e publicao. Este processo de validao que precede a publicao da aplicao pode levar horas (caso do Android) ou mesmo semanas (caso do iOS) e, portanto, no pode ser desprezado, uma vez que isto pode atrasar a entrega do aplicativo para o usurio. Por outro lado, uma vantagem das lojas de aplicativos que o fabricante da plataforma se responsabiliza por toda a infraestrutura para
7
Store, ou loja de aplicativos, um catlogo de aplicaes que todas as plataformas utilizam para disponibilizar aos usurios os aplicativos existentes para a plataforma.
21
a publicao e distribuio das aplicaes. Desta forma, o desenvolvedor pode focar seus esforos do desenvolvimento da aplicao em si, no tendo que se preocupar com a forma pela qual seu usurio ir adquirir o software. Alm disso, tambm possvel monitorar os aplicativos com relao quantidade de downloads efetuados em determinado perodo, assim como outras informaes de usurios, como o ndice de satisfao, por exemplo. Por fim, como as linguagens e as orientaes de desenvolvimento para cada plataforma mvel so diferentes, importante ter uma equipe de desenvolvimento especializada em cada uma dessas plataformas. Uma alternativa para essa questo usar alguma ferramenta para gerar cdigo nas linguagens nativas de cada plataforma. Nesse caso, o desenvolvedor escreve o cdigo da aplicao em uma linguagem padro, como JavaScript, por exemplo, e depois a ferramenta transforma esse cdigo em aplicaes nativas das plataformas selecionadas pelo desenvolvedor [24]. Essa abordagem, porm, pode levar a outros problemas, como incompatibilidades, falhas de converso da ferramenta, falta de suporte, entre outros. 3.2.1. Vantagens Integrao da aplicao com o visual da plataforma em que ela executada; Integrao da aplicao com os recursos do dispositivo mvel, como acelermetro, GPS, cmera e bssola, por exemplo; Familiaridade do usurio com os componentes visuais da aplicao, que so renderizados pela prpria plataforma; Possibilidade de armazenamento local em arquivos ou em banco de dados SQLite; Monitorao das estatsticas de download e de satisfao dos usurios em relao a uma aplicao baixada da store de aplicaes; Mais possibilidades de protocolos de comunicao com o servidor remoto, alm daqueles suportados pelos navegadores web. 3.2.2. Desvantagens Demora para validar e publicar a aplicao em uma store de aplicaes; A migrao dos usurios para uma nova verso da aplicao no controlada;
22
Existncia de um custo extra de publicao da aplicao na store de aplicaes do fabricante; Especializao da equipe de desenvolvimento em uma ou mais plataformas mveis; Necessidade de disponibilizar o cdigo-fonte da aplicao para o proprietrio da store de aplicaes durante o processo de validao e publicao. 3.2.3. Ferramentas de apoio Para o desenvolvimento de aplicaes nativas, o conjunto de tecnologias de apoio diferente de acordo com a plataforma. No caso do iOS, a ferramenta principal de desenvolvimento o software XCode [25] da Apple. Essa a ferramenta oficial da Apple para desenvolvimento tanto de aplicativos para a plataforma OS X como para a plataforma mvel iOS, utilizada nos dispositivos iPhone, iPad e iPod. A ferramenta XCode gratuita, mas, para publicao da aplicao na loja iTunes da Apple, preciso ter uma conta de desenvolvedor Apple. A subscrio para ter a conta de desenvolvedor deve ser paga anualmente e depende do tipo da conta a ser adquirida (comum ou organizacional). No caso do Android, a ferramenta principal utilizada para desenvolvimento o Eclipse adicionado do plugin Android Development Tools (ADT) [26]. Esse pacote utilizado em conjunto com a instalao do Software Development Kit (SDK) do Android [27]. Ambos os pacotes so gratuitos e, para publicao na loja Play Store da Google, necessrio o pagamento de uma taxa nica, ou seja, no necessria uma subscrio. Para a plataforma Windows Phone, as ferramentas de desenvolvimento so baixadas atravs do pacote Windows Phone SDK [28]. Esse pacote de desenvolvimento gratuito, mas a publicao do aplicativo tambm requer uma subscrio anual de desenvolvedor Windows Phone. 3.3. Arquitetura para aplicao nativa + contedo web mvel A terceira abordagem para desenvolvimento de contedo para dispositivos mveis a composio de contedo nativo com contedo web, tambm conhecida como aplicao hbrida. Nesse caso, uma parte da aplicao escrita utilizando-se a linguagem padro da plataforma (Java ou Objective-C, nos casos do Android e do iOS, respectivamente) e outra
23
parte escrita utilizando-se linguagens de contedo web, como HTML, JavaScript e CSS, por exemplo. Usualmente, as plataformas mveis disponibilizam objetos visuais nativos para renderizar e executar contedo web. Em linhas gerais, esses objetos funcionam como um navegador web, renderizando HTML + CSS e processando scripts escritos em JavaScript; permitindo assim embarcar contedo web em aplicaes nativas. A aplicao construda com esses objetos tem todas as caractersticas de uma aplicao nativa, porm os componentes visuais com os quais o usurio interage so elementos da linguagem HTML, estilizados atravs de CSS, e cujo comportamento pode ser determinado via JavaScript. Uma aplicao hbrida normalmente construda quase completamente utilizando-se de linguagens padronizadas como HTML, CSS e JavaScript, e apenas uma pequena parte em linguagem nativa da plataforma. Dessa forma, boa parte do cdigo de uma aplicao hbrida construda para Android, por exemplo, pode ser reaproveitada no desenvolvimento para outras plataformas. Nesse caso, apenas a pequena parte do cdigo escrita em Java precisa ser alterada para a linguagem nativa da plataforma alvo.
Figura 4: Viso geral de arquitetura para aplicao nativa + contedo web mvel.
Conforme Figura 4, a aplicao hbrida pode se comunicar com um servidor remoto atravs de um link de Internet (3G, por exemplo), ou com um servidor local atravs de uma rede Wi-Fi na intranet da organizao.
24
Essa comunicao pode ocorrer via quaisquer protocolos de comunicao (p. ex.: HTTP, FTP, SMTP, WebDAV), seguros ou no, desde que compatveis com as capacidades do aparelho e da rede de comunicao utilizada. As informaes a serem trafegadas entre o dispositivo mvel e o servidor podem estar em diversos formatos de documento, como HTML, XML, JSON, ou mesmo em formato de streaming de dados. As informaes trafegadas entre aplicao mvel e servidor tambm podem ser dados ou descries de componentes de interface a serem renderizados pela aplicao, assim como pode ser feito em aplicaes nativas. Dessa forma, quando uma modificao afeta apenas a interface de usurio, essa alterao pode ser feita apenas no servidor remoto, evitando-se um novo ciclo de validao e publicao na store de aplicaes. A aplicao hbrida tambm permite tanto o armazenamento local em arquivos como o armazenamento em banco de dados SQLite. Normalmente, o acesso ao banco de dados SQLite escrito na linguagem nativa da plataforma alvo. Porm, alguns frameworks de desenvolvimento de aplicaes mveis hbridas oferecem API especfica para que este acesso seja escrito em JavaScript [29]. Essas APIs especficas do framework devem ser usadas com cautela, visto que podem ser uma fonte de defeitos ou podem ser descontinuadas com o passar do tempo. Aplicaes que obedecem a essa arquitetura so instaladas no dispositivo mvel a partir de uma store de aplicativos. Portanto, tambm esto sujeitas ao ciclo de validao e publicao determinado por cada store. Alm disso, assim como uma aplicao nativa, as aplicaes hbridas so acessadas via um cone da aplicao na tela do dispositivo e podem usar recursos do dispositivo, como acelermetro, GPS, bssola e cmera. A construo de aplicaes hbridas possibilita no somente o reaproveitamento de cdigo entre vrias plataformas, como tambm pode reduzir a quantidade de desenvolvedores especializados em cada plataforma. Isto acontece, principalmente, quando o cdigo nativo da aplicao hbrida se restringe apenas ao que no conveniente ou no possvel tratar com tecnologia web, como questes especficas de segurana ou acesso a recursos do dispositivo, por exemplo. A aplicao hbrida, porm, exige maior esforo na estilizao dos elementos HTML atravs de CSS, a fim de deixar a aplicao mais parecida com os componentes visuais nativos da plataforma. De outra forma, os usurios podem no se sentir confortveis com a aparncia e o comportamento dos componentes visuais da aplicao. Esse esforo deve ser planejado e executado levando sempre em considerao que o principal objetivo de embarcar o contedo web em uma aplicao nativa reaproveit-lo em vrias plataformas mveis.
25
Para construir aplicaes mveis hbridas, o desenvolvedor pode utilizar algum framework que visa a minimizar o esforo de construo e manuteno desse tipo de aplicao [30]. Normalmente, esses frameworks so integrados ao ambiente de desenvolvimento padro da plataforma para a qual a aplicao foi inicialmente desenvolvida. Em seguida, para portar essa aplicao para outra plataforma, o cdigo web comum deve ser copiado para o ambiente de desenvolvimento da nova plataforma alvo e o cdigo nativo deve ser reescrito na nova linguagem. 3.3.1. Vantagens Integrao da aplicao com os recursos do dispositivo mvel, como acelermetro, GPS, cmera e bssola, por exemplo; Escrita da maior parte do cdigo em linguagem padro multiplataforma (HTML, CSS e JavaScript), possibilitando o reaproveitamento de cdigo; Maior flexibilidade na escolha e na estilizao dos componentes visuais da aplicao (componentes nativos ou web); Possibilidade de reduo da quantidade de desenvolvedores especializados em cada plataforma; Possibilidade de armazenamento local em arquivos ou em banco de dados SQLite; Possibilidade de monitorar os downloads de uma aplicao baixada da store de aplicaes; Monitorao das estatsticas de download e de satisfao dos usurios em relao a uma aplicao baixada da store de aplicaes; Mais possibilidades de protocolos de comunicao com o servidor remoto, alm daqueles suportados pelos navegadores web; Possibilidade de reaproveitar a lgica de negcios da aplicao, visto que esta pode ser incorporada no servidor remoto, ao invs de estar no cliente. 3.3.2. Desvantagens Demora para validar e publicar a aplicao em uma store de aplicaes; Maior esforo para customizar os componentes da aplicao para deixar sua aparncia e comportamento similares ao da plataforma;
26
A migrao dos usurios para uma nova verso da aplicao no controlada; Existncia de um custo extra de publicao da aplicao na store de aplicaes do fabricante; Necessidade de disponibilizar o cdigo da aplicao para o proprietrio da store de aplicaes durante o processo de validao e publicao. 3.3.3. Ferramentas de apoio Para o desenvolvimento de aplicaes hbridas, a ferramenta mais utilizada uma biblioteca de desenvolvimento chamada PhoneGap [30]. O PhoneGap uma soluo da Adobe Systems que prov um conjunto de recursos para que o desenvolvedor possa construir aplicaes que sero distribudas para diversas plataformas, porm utilizando-se de HTML, CSS e JavaScript em vez de linguagens especficas de cada plataforma. Para construir uma aplicao com o PhoneGap, o desenvolvedor escolhe o ambiente de desenvolvimento mais conveniente (XCode, Eclipse, Visual Studio, entre outros) e cria inicialmente um projeto de desenvolvimento para a aplicao. No projeto da aplicao, o desenvolvedor referencia a biblioteca do PhoneGap, que lhe dar acesso a um conjunto de funes em JavaScript para que seja possvel acessar recursos embarcados no dispositivo mvel, como bssola, acelermetro, GPS, cmera, entre outros. Assim, o desenvolvedor constri a aplicao utilizando tecnologias Web e os recursos do PhoneGap, de forma que possa reutilizar esse cdigo-fonte em projetos criados em ambientes de outras plataformas. O PhoneGap, ento, no dispensa a necessidade de ter projetos diferentes para cada plataforma mvel. Porm, cada projeto subsequente precisa apenas referenciar a biblioteca do PhoneGap e utilizar o mesmo cdigo-fonte que foi construdo no primeiro projeto. Dessa forma, o custo de manuteno dos diversos projetos bastante reduzido, uma vez que o cdigo desenvolvido para um projeto quase todo reutilizado nos projetos subsequentes. 3.4. Orientaes para escolha da arquitetura Conforme apresentado nas Sees 3.1, 3.2 e 3.3, cada arquitetura possui vantagens e desvantagens que devem ser consideradas durante a
27
construo de qualquer aplicao mvel. Nesta seo, so apresentados critrios para que, de acordo com os requisitos e o roadmap da aplicao mvel a ser construda, a equipe de desenvolvimento possa escolher a arquitetura mais adequada (Figura 5). O primeiro critrio diz respeito ao acesso a recursos de hardware do dispositivo mvel. Quando a aplicao requer acesso a recursos como acelermetro, barmetro e bssola, por exemplo, as arquiteturas que envolvem cdigo nativo devem ser priorizadas. Isto porque, apesar de existirem esforos para a construo de especificaes de acesso a esse tipo de recurso via um navegador web, a maioria dessas especificaes ainda est em fase embrionria [31]. Portanto, normalmente bem mais fcil acessar esses recursos atravs de cdigo nativo.
Figura 5: Fluxo de deciso para escolha da arquitetura.
Outro critrio que aponta para o uso de arquiteturas que envolvem cdigo nativo o armazenamento local de informaes. Se a aplicao requer
28
armazenamento e recuperao de informaes estruturadas no dispositivo, as arquiteturas que envolvem cdigo nativo devem ser priorizadas, visto que permitem a utilizao de SQL para manipular um banco de dados local. Conforme explanado anteriormente, usando a arquitetura web, uma aplicao pode armazenar informaes localmente no dispositivo atravs de arquivos. Porm, essa arquitetura no permite acessar o banco de dados SQLite, disponibilizado pelas principais plataformas mveis. Outro critrio muito importante que pode levar escolha de uma das arquiteturas que envolvem cdigo nativo a conectividade com a Internet/intranet. Se a aplicao mvel a ser desenvolvida for utilizada em um contexto em que h restries de conectividade com a Internet/ intranet, a arquitetura web pode no ser a mais adequada. Isto porque a arquitetura web possui uma dependncia muito forte de conectividade, visto que a interface e as informaes da aplicao trafegam por meio da Internet/intranet para chegar ao navegador do dispositivo mvel. Essa necessidade, porm, pode ser amenizada com o uso de armazenamento local em arquivo. Assim, se a aplicao mvel a ser construda no exigir acesso a recursos de hardware do dispositivo mvel ou a um banco de dados e no possuir restries de conectividade, a arquitetura web mvel pode ser a mais recomendada. Por outro lado, se a aplicao no corresponde a esses requisitos, preciso considerar as arquiteturas que envolvem cdigo nativo como principais opes. Nesse caso, a necessidade de se criar uma aplicao mvel com visual integrado plataforma na qual ser executada pode ser o critrio mais importante para decidir entre a arquitetura nativa ou a arquitetura hbrida. Se esse for um requisito essencial da aplicao a ser construda, a arquitetura nativa pode ser a melhor opo, visto que os componentes visuais sero renderizados diretamente pela plataforma. Porm, se este no for o caso, a arquitetura hbrida pode ser uma alternativa suficiente e mais econmica. Independentemente de todos os critrios apresentados na Figura 5, pode ser interessante avaliar tambm as habilidades e a quantidade de pessoas na equipe que ir desenvolver a aplicao. A arquitetura nativa pode requerer mais desenvolvedores especializados em cada plataforma mvel (p. ex.: Android e iOS), enquanto as arquiteturas web e hbrida podem requerer menos pessoal especializado, visto que boa parte do cdigo pode ser desenvolvido em linguagem multiplataforma, como HTML, CSS e JavaScript.
29
4. Aplicaes mveis As arquiteturas apresentadas foram experimentadas em prottipos. Os prottipos desenvolvidos demonstraram que, para os casos estudados, a arquitetura para desenvolvimento de aplicaes nativas se mostrou mais vantajosa. O Serpro desenvolveu e publicou aplicaes mveis nativas para a RFB (Receita Federal do Brasil) e para o DNIT (Departamento Nacional de Infraestrutura de Transportes). As duas instituies inovaram em 2012, oferecendo solues para dispositivos mveis, no mbito do governo federal. Em junho de 2012, a RFB disponibilizou para os contribuintes o aplicativo mvel Pessoa Fsica e, desde julho, o Siesc Mobile est disponvel para apoiar a fiscalizao de obras pblicas em andamento. As subsees a seguir apresentam as caractersticas dessas aplicaes e analisam a seleo da arquitetura mais adequada para cada soluo. 4.1. Aplicao Pessoa Fsica (RFB) A aplicao Pessoa Fsica (Figura 6.a), disponibilizada pela RFB, permite que um contribuinte consulte a situao de sua restituio de Imposto de Renda (Figura 6.b). Alm disso, um cidado pode consultar a situao do seu Cadastro de Pessoa Fsica (CPF), identificando se est regular ou se existe alguma pendncia. A aplicao tambm apresenta informaes gerais sobre o Imposto de Renda e o processo de restituio.
Figura 6: Aplicativo Pessoa Fsica: (a) tela principal; (b) consulta da restituio do IRPF[7]; avaliao do aplicativo (c) na loja Google Play [8] e (d) na loja App Store [7].
30
O aplicativo Pessoa Fsica foi lanado no dia 06 de junho de 2012 e tem recebido avaliaes muito positivas desde ento. Na Google Play8, a loja de aplicativos Android, a aplicao est avaliada com 4,6 estrelas, de um mximo de 5 estrelas, segundo consulta realizada em outubro de 2012 [8] (Figura 6.c). J na App Store9, a loja de aplicativos iOS, a aplicao est avaliada, por 85 usurios, com nota 4, em um total de 5 (Figura 6.d) . Alm disso, o nmero de downloads em cada uma dessas lojas bem similar e por volta de 98 mil [7][8]. Esses nmeros indicam uma grande aceitao do aplicativo pelos contribuintes brasileiros. A soluo foi construda utilizando-se de linguagens e tecnologias disponveis para cada plataforma especfica, ou seja, um exemplo de uso da arquitetura de aplicaes nativas. A deciso pelo desenvolvimento com a arquitetura nativa foi baseada nos seguintes requisitos: (i) necessidade de integrao visual com cada plataforma; (ii) necessidade de disponibilizar nas lojas de aplicativos para dispositivos mveis, para facilitar o descobrimento dos aplicativos, dado o amplo reconhecimento destas fontes pelos usurios de smartphones; (iii) necessidade de adequar as imagens por plataforma para seguir o padro de qualidade visual da RFB (um aplicativo genrico, com todas as imagens, seria muito grande e o tempo de download seria muito grande). Como este foi o primeiro aplicativo para dispositivos mveis, lanado pela RFB, optou-se por investir em uma interface simples, fcil de usar e natural para os usurios, por isso a integrao visual com cada plataforma era to importante: para que os usurios se sentissem confortveis com a interface. A equipe observou que os aplicativos nativos, via de regra, eram mais bem avaliados no quesito interface. As avaliaes dos usurios demonstraram que a deciso foi acertada. Um dos primeiros usurios a registrar comentrios avaliou: Um bom comeo para uma app do governo. Usabilidade tranquila. Poucos servios. Direto ao ponto. Outro usurio registrou: Simples, fcil de usar . E, um terceiro: Simples e funcional. Essa foi a tnica das avaliaes positivas nas lojas. Apesar da deciso mostrar-se acertada, a escolha da arquitetura nativa requereu o desenvolvimento de dois aplicativos: um para a plataforma Android e outro para Apple. A escolha das plataformas foi baseada na representatividade no mercado brasileiro, j que o aplicativo deveria ser disponibilizado para os cidados. As duas plataformas mais representativas no mercado foram selecionadas. Alm disso, a plataforma Android tem
8 9
Google Play a loja de aplicativos Android. Esta loja, alm de disponibilizar o aplicativo, permite que o usurio o avalie com uma nota at 5. App Store a loja de aplicativos da Apple. Esta loja, alm de disponibilizar o aplicativo, permite que o usurio o avalie com uma nota at 5.
31
a grande vantagem de estimular o uso de software livre. A verso para Android foi construda com a linguagem Java e o ambiente Eclipse, em conjunto com o Software Development Kit (SDK) da Google para Android. J a verso para iOS (sistema operacional mvel da Apple) foi construda com a linguagem Objective-C e o ambiente de desenvolvimento XCode. Com o desenvolvimento por plataforma, duas equipes foram mobilizadas, e aps a fase de requisitos, as fases do desenvolvimento foram replicadas. Alm do retrabalho, essa estratgia demandou sincronizao constante entre as equipes para garantir a proximidade entre as duas verses. A complexidade do desenvolvimento e manuteno aumenta medida em que novas plataformas so consideradas. Assim, esta deve ser uma preocupao ao optar-se pelo desenvolvimento nativo. Outra questo vivenciada foi que a publicao nas lojas pode impactar no cronograma de disponibilizao dos aplicativos. A publicao, ou no, depende de uma avaliao de cada loja, e no h como priorizar publicaes. Antes de publicar, a loja avalia alguns critrios para autorizar a publicao de um novo aplicativo, ou at mesmo de uma nova verso. Esses critrios exigem alguns cuidados com o design dos aplicativos e recomendado o uso de uma lista de verificao na fase de requisitos e de testes para evitar problemas na publicao. Na loja da Apple, por exemplo, cada nova submisso, demanda ao menos 24 horas para avaliao. 4.2. Aplicao SIESC Mobile Outro aplicativo mvel desenvolvido pelo Serpro foi o SIESC Mobile. Seu objetivo principal melhorar a qualidade das fiscalizaes das obras que so de responsabilidade do DNIT, proporcionando tambm reduo de tempo e custo. Antes do SIESC Mobile, um engenheiro (que poderia ser de uma empreiteira contratada pelo governo) levava um formulrio impresso obra para preench-lo com todas as caractersticas observadas (localizao, altitude, comprimento, tipo...) e com sua situao atual (falhas na estrutura, avano da construo em relao ltima medio...). Aps o preenchimento desse formulrio, as informaes em papel eram transcritas para o Sistema de Acompanhamento de Contratos (SIAC). A partir do SIESC Mobile, as informaes so captadas in loco. Recursos integrados, como GPS e cmera, permitem a complementao das informaes com dados precisos de localizao e fotos do andamento da obra, que mostram melhor a sua situao atual. Alm disso, vrias validaes na entrada dos dados aumentam a qualidade das informaes,
32
agilizam o processo e evitam retornos desnecessrios obra para correo de dados invlidos, que algumas vezes s eram identificados no escritrio. Ou seja, o investimento no desenvolvimento de uma aplicao mvel foi importante para dar mais celeridade e confiabilidade ao processo de registro dos dados de fiscalizao. Isso particularmente importante, levando-se em considerao que as obras fiscalizadas, muitas vezes, esto em locais distantes da zona urbana e que o tempo de locomoo at o local e de volta at o posto de trabalho pode ser grande. A expectativa que a soluo SIESC Mobile possibilite quitar os servios contratados em um tero do tempo necessrio anteriormente com os formulrios de papel, e tambm que os valores dos contratos podem ser reduzidos mediante a reduo dos custos de fiscalizao para a empresa contratada. Durante a execuo de um piloto da soluo realizado em 21 de junho de 2012, o engenheiro Marcos Antnio Borges, da Strata Engenharia, usou a aplicao SIESC Mobile e comentou: Operei o SIESC no tablet, fiz fotos georreferenciadas, foi genial mesmo... a ferramenta vai facilitar o acompanhamento de cada fase de execuo e vai nos ajudar a ter uma viso macro da obra [32]. Assim como o Pessoa Fsica, o SIESC Mobile um exemplo de aplicao construda usando a arquitetura nativa, ou seja, utilizando-se de tecnologias que executam apenas em uma plataforma especfica. A deciso pelo desenvolvimento com a arquitetura nativa foi baseada nos seguintes requisitos: (i) necessidade de utilizar recursos especficos dos dispositivos, no caso, cmera e celular; (ii) restries de conectividade com a internet, j que as obras esto espalhadas pelo Brasil, muitas vezes, longe de centros urbanos, como o caso de estradas; e (iii) necessidade de armazenamento local, j que centenas de informaes so capturadas pelo dispositivo off-line. No caso do SIESC, a plataforma escolhida foi o Android. Essa escolha foi baseada no fato de que esta uma plataforma aberta e que possui dispositivos a preos mais acessveis. O fato de ser uma plataforma aberta demonstra o alinhamento da soluo com a estratgia governamental de adoo e fomento ao software livre. Alm disso, o preo mais acessvel dos dispositivos que rodam o sistema operacional Android importante para minimizar os custos de aquisio de tecnologia, visando reduo dos gastos pblicos. Essa deciso foi possvel porque, diferentemente da aplicao Pessoa Fsica, que foi desenvolvida para uso pelo cidado, o SIESC Mobile foi construdo para ser utilizado por engenheiros do DNIT e de empresas terceirizadas que fiscalizam obras de construo civil governamentais. medida que o aplicativo for sendo utilizado, caso haja a
33
necessidade de uso em outra plataforma, o desenvolvimento de uma nova verso poder ser considerado. O SIESC Mobile (Figura 7) foi construdo como uma aplicao para ser executada em tablets Android e possibilita a substituio dos formulrios de fiscalizao de obras por um dispositivo porttil com interface moderna e que agrega informaes de diversas obras. Alm disso, as informaes registradas na aplicao podem ser enviadas diretamente do tablet para o DNIT a partir de uma conexo mvel 3G, por exemplo, diminuindo o prazo de pagamento dos contratos e aumentando o fluxo de caixa do contrato.
Figura 7: Utilizao do SIESC Mobile para efetuar uma medio de contrato.
O aplicativo no foi disponibilizado na loja de aplicativos Google Play, j que seu pblico-alvo especfico. Em vez disso, a aplicao foi disponibilizada no prprio portal do DNIT, atravs de um link para download com instrues de instalao e uso (Figura 8). A distribuio de aplicativos por meio deste portal j natural para o pblico-alvo do aplicativo.
34
Figura 8: Pgina do Portal do DNIT que disponibiliza o SIESC Mobile para download.
5. Trabalhos Futuros O desenvolvimento de aplicaes para dispositivos mveis e o estabelecimento de modelos de arquitetura a serem utilizados por esse tipo de aplicao so algumas das iniciativas que o Serpro apresenta para proporcionar inovao a seus clientes. Com o domnio das tecnologias disponveis para dispositivos mveis, j est sendo possvel oferecer solues inovadoras para o governo brasileiro. O prximo passo ampliar a oferta de solues para estes dispositivos viabilizando uma aproximao cada vez maior entre os servios de governo e o cidado que utiliza estes servios. Com o objetivo de continuar a oferecer produtos eficientes e inovadores, o Serpro est constantemente estudando novas tecnologias. A partir de agora, os prximos passos estaro direcionados para o estudo de novas interfaces e formas de interao entre as solues de software de governo e os cidados. Dentre essas tecnologias, pode-se citar o mapeamento de gestos corporais para controlar hardware e software e a utilizao da TV digital como uma nova interface de usurio. Alm disso, o Serpro tambm tem prospectado tecnologias que permitam o gerenciamento e controle de dispositivos mveis e que
35
possibilitem a utilizao de dispositivos particulares em atividades corporativas; este ltimo vem despontando como uma tendncia no mercado, e conhecido pelo termo em ingls BYOD (Bring Your Own Device). 6. Concluso Este artigo apresentou um consolidado de dados que mostram que a presena da mobilidade no Brasil tem crescido a cada ano e que, muitas vezes, o ritmo desse crescimento tem sido maior do que o observado em outros pases. A presena da mobilidade no Brasil se evidencia principalmente atravs do crescimento do uso da internet mvel e do aumento significativo de vendas de dispositivos mveis, como tablets e smartphones, a cada ano. Esse crescimento tem impacto significativo na vida dos brasileiros, principalmente pelo uso frequente de aplicativos que utilizam recursos embarcados nos dispositivos mveis, como: GPS, cmera, acelermetro, entre outros. Esses aplicativos so utilizados principalmente para comunicao, informao e entretenimento, e podem ser construdos para plataformas especficas, como Android e iOS, ou como aplicao web para acesso via navegadores web mveis. Diferentes tipos de arquiteturas para aplicaes mveis foram discutidos, apresentando suas vantagens e desvantagens com base em requisitos e contexto de uso das solues. No mbito do governo federal brasileiro, foram apresentados dois estudos de caso desenvolvidos pelo Serpro, para os clientes Receita Federal e DNIT. Esses estudos de caso mostraram exemplos de como a mobilidade pode ser utilizada para prover servios de governo para o cidado, como o caso do aplicativo Pessoa Fsica, bem como para melhorar a eficincia das atividades de fiscalizao executadas pelo Estado, como o caso do aplicativo SIESC Mobile. Os estudos de caso apresentados neste artigo so uma parcela pequena dos aplicativos desenvolvidos pelos governos das esferas federal, estadual e municipal que podem ser encontrados nas lojas virtuais de aplicativos mveis das plataformas. Isso mostra que cada vez mais servios pblicos so oferecidos pelos governos atravs de aplicativos para dispositivos mveis, facilitando a vida do cidado brasileiro. Alm dos aplicativos desenvolvidos pelo governo, alguns aplicativos so construdos diretamente por cidados a partir de dados disponibilizados abertamente pelo governo. Dessa forma, o conjunto de servios governamentais para plataformas mveis no depende apenas de
36
rgos e empresas pblicas, mas tambm pode ser ampliado pelos prprios cidados que se beneficiam com o uso desses servios. Apesar do crescimento j evidenciado, a tendncia da mobilidade no Brasil ainda de crescimento. Com smartphones e tablets, os cidados dispem de um recurso poderoso para acessar servios a partir de qualquer lugar e a qualquer momento. Por isso, o Serpro tem investido fortemente em preparar-se e aproveitar a oportunidade de prover solues mveis para o governo e para o cidado melhorando a qualidade dos servios prestados e possibilitando uma aproximao maior dos servios de governo com a populao. Em especial, a Copa do Mundo 2014 e as Olimpadas 2016 sero timas oportunidades para disponibilizar uma variedade grande de servios mveis, que podem ajudar as pessoas que iro participar desses dois grandes eventos. 7. Referncias [1] Acesso a Internet mvel no Brasil praticamente dobra, Jornal O Povo Online. Disponvel em <http://www.opovo.com.br/app/opovo/ tendencias/2012/01/27/noticiasjornaltendencias,2774145/acesso-a-internetmovel-no-brasil-praticamente-dobra.shtml. Acessado em 26/10/2012>. [2] Nosso Planeta Mobile: Brasil, Google Inc.. Disponvel em <http:// services.google.com/fh/files/blogs/our_mobile_planet_brazil_pt_ BR.pdf>. Acessado em 26/10/2012. [3] Aplicativo Voos Online, Infraero. Disponvel em <http://www. infraero.gov.br/fiquepordentro/#/download>. Acessado em 26/10/2012. [4] Aplicativo Banco do Brasil, Banco do Brasil S.A. Disponvel em <https://play.google.com/store/apps/details?id=br.com.bb.android. Acessado em 26/10/2012>. [5] Celepar desenvolve novo site do Vero Paran para plataformas mveis, Celepar. Disponvel em <http://www.celepar.pr.gov.br/ modules/noticias/article.php?storyid=871. Acessado em 26/10/2012>. [6] Brasil em Cidades sucesso de downloads em um ms, Portal Brasil. Disponvel em <http://www.brasil.gov.br/noticias/arquivos/2011/12/5/ portal-brasil-em-cidades-oferece-informacoes-sobre-planejamento-urbanoaos-municipios-de-todo-o-pais>. Acessado em 26/10/2012.
37
[7] Aplicativo Pessoa Fsica na App Store. Disponvel em <https:// itunes.apple.com/br/app/pessoa-fisica/id529883041?mt=8>. Acessado em 26/10/2012. [8] Aplicativo Pessoa Fsica na Google Play. Disponvel em <https://play. google.com/store/apps/details?id=br.gov.fazenda.receita.pessoafisica>. Acessado em 26/10/2012. [9] Aplicativo Viajantes no Exterior na App Store. Disponvel em <https:// itunes.apple.com/br/app/viajantes-no-exterior/id547724184?mt=8>. Acessado em 26/10/2012. [10] Aplicativo Viajantes no Exterior na Google Play. Disponvel em <https://play.google.com/store/apps/details?id=br.gov.fazenda.receita. viajantesexterior>. Acessado em 26/10/2012. [11] Aplicativo SIESC Mobile no stio do DNIT. Disponvel em <https:// gestao.dnit.gov.br/sistemas-gerenciais/siesc. Acessado em 26/10/2012>. [12] Aplicativo SGO Mobile no stio do DNIT. Disponvel em <http:// www.dnit.gov.br/sistemas-gerenciais/sgo>. Acessado em 26/10/2012. [13] Scope of Mobile Web Best Practices, W3C Standards. Disponvel em <http://www.w3.org/TR/mobile-bp-scope/#s3>. Acessado em 26/10/2012. [14] Picking A Mobile Support Strategy For Your Website, Smashing Magazine. Disponvel em <http://mobile.smashingmagazine. com/2011/07/11/picking-a-mobile-support-strategy-for-your-website/>. Acessado em 26/10/2012. [15] The Goldilocks Approach, Front. Disponvel em <http:// goldilocksapproach.com/>. Acessado em 26/10/2012. [16] CSS Media Queries & Using Available Space CSS Tricks. Disponvel em <http://css-tricks.com/css-media-queries/>. Acessado em 26/10/2012. [17] Resolution Independence With SVG, Smashing Magazine. Disponvel em <http://coding.smashingmagazine.com/2012/01/16/resolutionindependence-with-svg/>. Acessado em 26/10/2012.
38
[18] Mobile Content: If in Doubt, Leave It Out, Jakob Nielsen. Disponvel em <http://www.useit.com/alertbox/mobile-writing.html>. Acessado em 26/10/2012. [19] jQuery Mobile, The jQuery Foundation. Disponvel em <http:// jquerymobile.com/>. Acessado em 26/10/2012. [20] Sencha Touch, Sencha Inc. Disponvel em <http://www.sencha. com/products/touch>. Acessado em 26/10/2012. [21] Plone, Plone Foundation. Disponvel em <http://plone.org/>. Acessado em 26/10/2012. [22] Liferay, Liferay Inc. Disponvel em <http://www.liferay.com/>. Acessado em 26/10/2012. [23] SQLite, SQLite. Disponvel em <http://www.sqlite.org/features. html>. Acessado em 26/10/2012. [24] AppAccelerator Titanium, AppAccelerator. Disponvel em <http://www.appcelerator.com/platform/titanium-sdk>. Acessado em 26/10/2012. [25] XCode, Apple. Disponvel em <https://developer.apple.com/ xcode/>. Acessado em 26/10/2012. [26] ADT Plugin, Google. Disponvel em <http://developer.android. com/tools/sdk/eclipse-adt.html>. Acessado em 26/10/2012. [27] SDK Android, Google. Disponvel em <http://developer.android. com/sdk/index.html>. Acessado em 26/10/2012. [28] Windows Phone SDK, Microsoft. Disponvel em <http://www. microsoft.com/en-us/download/details.aspx?id=27570>. Acessado em 26/10/2012. [29] PhoneGap Storage, Adobe Systems. Disponvel em <http://www. sqlite.org/features.html>. Acessado em 26/10/2012. [30] PhoneGap, Adobe Systems. Disponvel em <http://phonegap. com/>. Acessado em 26/10/2012.
39
[31] Standards for Web Applications on Mobile, W3C Standards. Disponvel em <http://www.w3.org/wiki/Standards_for_Web_ Applications_on_Mobile>. Acessado em 26/10/2012. [32] Na Palma da Mo, Revista Tema (pp. 14-19). Disponvel em <http:// tema.serpro.gov.br/pub/serpro//index.jsp?edicao=38>. Acessado em 26/10/2012.
40
Mobilidade digital: tecnologias e tendncias Djamel F. H. Sadok
Abstract Mobilidade em qualquer contexto sinnimo de liberdade. No mundo digital, governos e negcios reconhecem a importncia de aproveitar novos canais de comunicao em busca de melhorar seus servios e atingir novas massas. A mobilidade se manifesta hoje em trs dimenses: usurio, contedo e dispositivo. A taxa de inovao em ambientes mveis claramente ultrapassa os desafios regulatrios, de segurana, organizacionais, etc. Exemplos de aplicaes emergentes incluem mdicos acessando registros de pacientes por meio de tecnologias mveis, conexo de veculos e seus usurios, passageiros acessando a Internet em pleno voo. Este Keynote mostrar as tecnologias por trs destas conquistas e como elas esto evoluindo, alm de apontar desafios que devem ser considerados. Introduo A arquitetura Internet se baseia num conjunto de invariantes o suficiente para no sofrer mudanas profundas ao longo das ltimas trs dcadas. Muitos destes princpios so reiteradamente ameaados e questionados em nome de inmeras iniciativas como: a Internet do futuro, a Internet das coisas, Redes definidas por Software, Redes centradas em Contedo, Novas Arquiteturas para a Internet, etc.
41
DJAMEL F. H. SADOK
Duas escolas de pensamento surgiram entre os pesquisadores. A primeira corrente advoga que a arquitetura Internet est engessada por suas prprias regras e que uma alternativa deve considerar recomear do zero (clean slate). A segunda escolheu um caminho evolucionrio ao contrrio de uma revoluo. Atualmente, a maioria dos pesquisadores reconhece a dificuldade que propor um novo projeto totalmente desacoplado da arquitetura existente e admite a necessidade de mudanas gradativas. Ns reconhecemos hoje que o sucesso da Internet se deve a fatores inerentes a seu projeto original como: simplicidade de requisitos, abertura s contribuies do pblico em geral, apoio financeiro de um governo durante quase duas dcadas, decises baseadas em consenso aproximado e cdigo que executa. Hoje, quando visitamos este projeto podemos detectar vrias falhas nele. Podemos ver que a Internet posiciona a inteligncia das aplicaes totalmente nos pontos de borda e no nos elementos retransmissores. A rede inteira vista como uma linha de transmisso de acordo com o argumento fim a fim. A introduo de redes definidas por software e de redes centradas em contedo pode mudar este princpio e, consequentemente, o modelo de negcio por trs dele. Podemos, no futuro, enumerar todos os objetos de contedo e manipul-los independentemente, ao invs de simplesmente manipular pacotes. A mobilidade da informao deve ser registrada e rastreada pela rede quando requisitada por seus usurios. No podemos simplesmente culpar os pioneiros deste projeto Internet. Muitos servios que hoje consideramos essenciais num sistema de comunicao no eram conhecidos nem contemplados duas ou trs dcadas atrs. Os engenheiros de Telecom no pensavam nos anos 1970 e 1980 na existncia de: a) usurios mveis; b) sistemas intermedirios na rede como proxies e firewalls, na necessidade de desligar roteadores ou mover recursos de armazenamento dinamicamente na rede para economizar energia; c) identificao e mobilidade de contedo; d) segurana da informao; etc. O espao de endereamento IP, verses 4 e 6, apresenta a identificao do elemento fim como tambm a sua localizao na Internet. Descobrimos hoje que esta dupla responsabilidade do endereo atrapalha o roteamento da informao numa rede com destinos mveis j que enquanto a identificao do objeto fim no muda, a sua localizao muda. Pensando nos desafios impostos para a acomodao de usurios mveis na Internet, tivemos que revisitar a arquitetura Internet vrias vezes, de modo a produzir solues. Neste texto, vamos examinar estas tecnologias e solues introduzidas na arquitetura Internet e em Redes de Telecom convergentes para suportar a mobilidade de usurios e do contedo.
42
MOBILIDADE DIGITAL: TECNOLOGIAS E TENDNCIAS
Semelhana IP Mvel e Mobilidade Celular Com o surgimento dos sistemas celulares e redes sem fio nos anos 1990, ficou evidente a necessidade de introduzir o suporte mobilidade na arquitetura Internet. Esta nova comunidade de usurios sem fio demanda conectividade contnua quando se deslocam. A inspirao do mundo IP apareceu entre 1990 e 1995 com as primeiras pesquisas introduzindo esquemas que alteram o roteamento IP para contemplar cenrios com mobilidade. Este esquema parte do princpio de que a arquitetura IP lida apenas com padres nos nveis de rede (nvel do IP), transporte (nvel fim a fim com os protocolos TCP e UDP) e no nvel de aplicao. Assim, a mudana no IP, identificada como IP Mvel, requer a introduo de dois servidores: o home agent (que fica na rede original do usurio) e o foreign agent (que fica na rede visitada). Estes dois processos interceptam a transmisso dos pacotes para usurios mveis e redirecionam estes pacotes para a nova localizao do usurio.
Figura 1: Mobilidade Internet versus Sistema Celular.
A soluo IP Mvel muito semelhante soluo adotada pelos padres de telefonia celular para suportar Roaming. Examinando a Figura 1 podemos ver que o roteamento dos pacotes IP entre o n correspondente (correspondent node CN) e o n mvel (mobile node MN) passa sempre pela rede de origem deste no mvel e especificamente pelo agente home agent (HA). Diferentemente, as mensagens enviadas de MN para CN sero enviadas diretamente atravs da Internet. O leitor deve se perguntar o porqu desta diferena. Simplesmente porque MN mantm seu endereo enquanto muda de localizao e a rede s est preparada para encaminhar os pacotes destinados MN para a sua rede de origem. Alm disso, os pacotes devem vir com o endereo da sua rede local, neste caso, o endereo do seu agente caseiro (HA), para evitar que outros usurios anunciem endereos
43
DJAMEL F. H. SADOK
que no so deles e os hosts na Internet acreditem. No caso do IP Mvel, o HA da rede de origem do MN garante a confiabilidade da conexo. Este mais um exemplo onde, em nome da segurana, sacrificamos a eficincia. Este problema no se repete no caso do IPv6, j que ao contrrio do IP, este suporta segurana de maneira nativa. Dupla Responsabilidade do Endereo IP Com a queda dos investimentos nas empresas .com no incio da primeira dcada dos anos 2000, o governo americano decidiu investir em novas pesquisas incluindo projetos com propostas para novas arquiteturas Internet. No caso do endereo IP, ficou claro que a sua dupla responsabilidade prejudica a mobilidade de usurios e que um desacoplamento entre identificao e localizao se faz necessrio. O Host Identity Protocol (HIP) uma proposta que faz esta separao criando o localizador e o identificador (Host Identity HI) de um sistema fim. Assim, o HIP permite que um n tenha mais de um endereo. Este mecanismo conhecido como multihoming. Para atingir seu objetivo, o HIP desacopla a camada de transporte da camada do IP como mostra a Figura 2 (a).
Figura 2: Arquitetura HIP da Internet do Futuro.
Vemos tambm no lado (b) da Figura 2 que o HIP entre o HI e a localizao IP (parte em vermelho) esconde a mobilidade para os protocolos de alto nvel como o TCP, fazendo com que estes continuem funcionando corretamente, de maneira transparente, inclusive em cenrios mveis.
44
Micromobilidade Ambas as solues, Celular e IP Mvel, empregam servidores especializados no rastreamento dos usurios. No caso dos sistemas celulares, so duas bases de informao: a) os usurios da empresa de Telecom (Home Location Register HLR) e b) o banco de dados de usurios visitantes (Visitor Location Register VLR). Quando um usurio liga seu aparelho, ocorre uma operao de registro do aparelho e da localizao do usurio. Esta informao de localizao atualizada medida que o usurio se movimenta numa regio, ver Figura 1. De maneira semelhante, o IP Mvel emprega dois agentes (HA) e (FA) para registrar a localizao de usurios caseiros e visitantes, respectivamente. Fica claro que a atualizao da localizao do usurio nestas bases de informao deve acontecer cada vez que houver sua movimentao. Isso feito atravs de mensagens especiais de sinalizao. Quando as reas de cobertura so pequenas, a taxa de roaming cresce e o trfego de atualizao de localizao pode ficar pesado para o sistema, implicando na perda de escalabilidade. Este problema reconhecido por sistemas celulares e tambm pela comunidade Internet. Para sua soluo, um sistema de cobertura hierrquico adotado, ver exemplo na Figura 3. Podemos conectar usurios com alta mobilidade em clulas com cobertura grande para evitar uma alta frequncia de atualizaes. Temos hoje uma gama diversificada na hierarquia de clulas em termos de cobertura incluindo clulas macro, micro, pico e FemtoCells.
Figura 3: Macro e microclulas para Alta Mobilidade.
45
DJAMEL F. H. SADOK
No caso da Internet, vrias solues foram propostas, e uma delas coincidentemente chamada Cellular IP (CIP). O IP Mvel otimizado somente para mobilidade macro e com cenrios com baixa mobilidade. O CIP otimizado para hosts com alta mobilidade alm de ser compatvel com o IP Mvel como mostra a Figura 4. O CIP pode acomodar um alto nmero de usurios mveis separando os que so mveis dos outros.
Figura 4: Micromobilidade no Celular IP (CIP).
Femtocells Femtocells so pequenas clulas de baixa potncia semelhantes ao ponto de acesso Wireless LAN e que podem ser interligadas em qualquer lugar na Internet para oferecer mobilidade. Imagine um evento ou uma conferncia sendo organizados numa regio do pas sem cobertura celular. Muitos participantes vo se sentir isolados, neste caso, j que seus colegas e familiares no vo poder entrar em contato por meio da telefonia celular. As operadoras de telefonia celular oferecem Femtocell como uma estao rdio-base completa e porttil. Os organizadores do evento podem ento conectar a estao Femtocell Internet ou em outra linha dedicada, como um enlace de satlite. Assim, o resultado seria que os usurios estariam conectados atravs de uma cobertura celular normal emitida pela Femtocell que, por sua vez, estaria conectada com a Central de Comutao Celular (CCC) da operadora de Telecom atravs da Internet como mostra a Figura 5.
46
Figura 5: Exemplo de uso de uma Femtocell.
Para os interessados, hoje h uma implementao de software aberto de Femtocell, conhecida como OpenBTS. Este software precisa de outro software aberto chamado GNURadio, que implementa os mdulos de comunicao sem fio e de rdio em software. As nicas partes que no so em software neste caso so a antena e os conversores analgico-digital (A/D/A). IEEE 802.21 Em 2008 surgiu da IEEE o padro internacional IEEE 802.21, que descreve como efetuar um handoff entre tecnologias sem fio diferentes como 802.11 (WLAN), 802.16 (WiMax) e 3G. Na verdade, at redes cabeadas, como a Ethernet (802.3), so contempladas. Alm de reduzir o tempo de troca de tecnologia de acesso, o padro permite aos usurios mveis a seleo entre as tecnologias disponveis e a autenticao dos usurios. O 802.21 permite a continuidade de uma sesso de um usurio mvel de maneira transparente entre tecnologias diferentes.
47
DJAMEL F. H. SADOK
Figura 6: 802.21 Mobilidade Independente da Tecnologia sem Fio Empregada.
Mobilidade da informao na Internet do futuro A Internet viveu recentemente uma mudana de paradigma de processamento e distribuio de contedo conhecida como comunicao Peer-to-Peer (P2P). Diferentemente do modelo cliente/servidor, o modelo P2P limita o poder de servidores intermedirios para concentr-lo nos hosts fim. Aplicaes P2P, principalmente para a troca de contedo, surgiram. A localizao da informao neste caso baseada no uso de Tabelas Hash Distribudas (DHT). Algumas propostas para a prxima Internet identificaram as limitaes do Domain Name System (DNS) na sua potncia de escalar para redes que precisam de registros atualizados sobre usurios e contedos mveis. Obviamente, o DNS no foi otimizado para consultas complexas. Como soluo, vrias propostas propem extenses para o DNS com sistemas mais rpidos de acesso, como o DHT que tem uma mdia de acesso de log(n). Podemos imaginar um cenrio futuro no qual o e-mail de um usurio no seja ligado a sua localizao. Assim, caso o usurio mude de emprego, por exemplo, este no precisar mudar sua identificao de e-mail. Podemos aplicar este raciocnio para as pginas da Web que poderiam ser identificadas por meio de endereos desacoplados da localizao. Assim,
48
o sistema DHT ter a tarefa de localizar a entrada a partir da informao sobre um objeto, como um e-mail ou pgina Web. Cada vez que um objeto muda de localizao ou quando replicado na Internet, este deve avisar o sistema DHT para que haja atualizao em seus dados.
Figura 7: O Papel do DHT na Mobilidade.
Mobilidade de contedo redes centradas em contedo Redes centradas em contedo (Content-centric Networks CCN) pretendem oferecer uma disseminao eficiente da informao. Este novo paradigma quebra o argumento tradicional da Internet, conhecido como o argumento fim a fim. CCNs introduzem processamento nos elementos da rede com o pretexto de melhorar a mobilidade do contedo. Nestas propostas, objetos de informao so identificados de maneira nica e roteados na Internet. A mobilidade da informao caracterstica principal deste novo tipo de arquitetura. Mobilidade de recursos OpenFlow A fim de experimentar com a rede de um Campus Universitrio, pesquisadores da Universidade de Stanford inventaram o OpenFlow. Podemos considerar que o OpenFlow uma das tecnologias propostas para a Internet do futuro que mais atraiu interesse. Simplesmente, o OpenFlow permite a instalao em Switches e Roteadores de comandos e filtros gerenciados por um controlador central como mostra a Figura 8.
49
DJAMEL F. H. SADOK
Figura 8: Arquitetura e Protocolo OpenFlow.
Usando o OpenFlow, um gerente de uma rede pode pedir que certos pacotes sejam encaminhados para um destino especfico, tirados da rede, ter seus cabealhos alterados etc. Esta ltima ao, na forma de alterao dos cabealhos, permite a migrao de fluxos, ou seja, a mobilidade de usurios.
Figura 9: Campos que Podem Alterados e Aes de um Switch OpenFlow.
Assim, quando um pacote do experimento chega a um comutador ele encaminhado para o Controlador, que responsvel por escolher a melhor rota para o pacote seguir na rede a partir dos mecanismos do protocolo de roteamento proposto. Aps isso, o Controlador adiciona entradas na Tabela de Fluxos de cada comutador pertencente rota escolhida. Os prximos pacotes desse fluxo que forem encaminhados na rede no necessitaro ser enviados para o Controlador. Uma rede OpenFlow pode possuir pontos de acesso sem fio, permitindo que clientes mveis utilizem sua infraestrutura para se conectarem a Servidores ou Internet. Assim, mecanismos de handoff podem ser executados no Controlador realizando alterao dinmica das tabelas de fluxo dos comutadores de acordo com a movimentao do cliente,
50
permitindo a redefinio da rota utilizada. A Figura 10 mostra a migrao de fluxos (em amarelo pontilhado) acompanhando a mobilidade do usurio da esquerda para a direita.
Figura 10: Exemplo de Mobilidade de Fluxos de Dados usando a Tecnologia OpenFlow.
Podemos tambm visualizar um cenrio em que desejamos mover um roteador para economizar energia ou para a manuteno do equipamento fsico. Uma soluo seria transferir todos os fluxos sendo roteados por este roteador para outro roteador e em seguida desligar este equipamento. Assim temos de forma virtual, uma mobilidade de roteadores alcanada atravs do uso da tecnologia OpenFlow. Migrao de mquinas virtuais Uma das tecnologias-chave empregadas na Computao em Nuvens a virtualizao. Embora conhecida por muito tempo no mbito de sistemas operacionais de mainframe, est sendo reavivada em ambientes de Cloud Computing. O motivo simples: permitir um maior compartilhamento de recursos dividindo recursos fsicos de CPU, memria, disco e de comunicao de maneira virtual. A virtualizao est sendo usada tambm por operadoras oferecendo Clouds na forma de infraestrutura. O software de virtualizao usado para compartilhar os recursos entre, por exemplo, operadores de distribuio de contedo (Content Delivery Networks).
51
DJAMEL F. H. SADOK
Diferentemente de uma mquina fsica, o estado de uma mquina virtual (Virtual Machine VM) pode ser descrito usando informao independente do hardware. Portanto, uma VM pode ser migrada para outra mquina fsica. Este tipo de operao pode ser aproveitada em diversos cenrios. Por exemplo, noite, quando o processamento diminui em alguns pontos da rede, as mquinas virtuais podem ser distribudas entre estes pontos, desafogando pontos estressados. Em seguida, podemos desligar servidores ociosos e suas linhas de transmisso (caso possvel), discos, etc. Assim possvel mudar a topologia da rede com seus servidores, o que pode favorecer a economia de energia, por exemplo. A migrao de mquinas virtuais tem sido uma alternativa comumente adotada em clusters e datacenters devido principalmente s suas vantagens no balanceamento de carga, tolerncia falha e economia de energia. Diferentes abordagens de migrao de mquinas virtuais so disponibilizadas por hypervisores. No caso do Xen, estas so: stop-and-copy e pr-cpia. Outras tecnologias com suporte mobilidade Neste texto, abordamos algumas tecnologias sendo usadas para prover mobilidade de recursos, usurios, informao, etc. Existem outras tecnologias desenvolvidas com o intuito de facilitar a mobilidade de usurios e seus recursos. Abaixo mencionamos algumas: OpenID: um sistema de suporte autenticao nica permitindo a portabilidade das credenciais de usurios para poder acessar os recursos de TIC em qualquer lugar federado sua instituio. Este tipo de compartilhamento de controle de acesso est sendo usado em vrias partes do mundo para o acesso de alunos e universitrios s redes acadmicas e de pesquisa. Evidentemente, a segurana neste caso deve ser dobrada j que a quebra de identidade significa o acesso em todos os servios da federao OpenID. O uso de JavaCards e mdulos de hardware seguro, como o Trusted Platform Module (TPM), permite a autenticao forte de usurios assim como seus equipamentos e controlar seu acesso a recursos de TIC. Passaportes e outros documentos importantes j esto incluindo chips seguros e TPMs permitindo uma troca de informao segura independentemente do site de acesso.
52
Bibliografia [1] RFC 4423 Host Identity Protocol (HIP) Architecture (early informational snapshot). [2] A. T. Campbell, S. Kim, J. Gomez, C-Y. Wan, Z. Turanyi, A. Valko, draftietf-mobileip-cellularip-00.tx, IETF mobile IP Working Group Document, December 1999. [3] <http://www.ieee802.org/21>. [4] KyoungSoo Park, Vivek S. Pai, Larry Peterson and Zhe Wang, Improving DNS Performance and. Reliability via Cooperative Lookup. [5] <http://www.openflowswitch.org>.
53
Experimentao no futuro da Internet: pesquisa utilizando virtualizao e framework OpenFlow Fernando N. N. Farias1,3, Joo J. Salvatti2,3, Antnio J. G. Abelm1,2,3
Resumo A Internet um enorme sucesso mundial e vem mudando a forma como interagimos, trabalhamos e nos divertimos. Boa parte deste sucesso se deve grande flexibilidade da tecnologia IP. Apesar de todo o sucesso da Internet, a tecnologia bsica IP a causa das suas prprias limitaes, que se tornam cada vez mais evidentes. Um dos principais objetivos da atividade conhecida como Internet do Futuro (IF) a formulao e avaliao de arquiteturas alternativas para substituir o protocolo IP. Nesse contexto, duas abordagens esto sendo discutidas e investigadas: a primeira denominada limpa (Clean Slate) que visa substituir a arquitetura atual por uma nova totalmente reconstruda e a outra chamada evolucionria (Evolutionary), que pretende evoluir a arquitetura atual sem perder a compatibilidade com a anterior. No entanto, o maior desafio agora onde habilitar e testar as propostas das respectivas abordagens de modo a valid-las eficientemente, sem prejudicar a infraestrutura atual, j que haver a necessidade de que roteadores e switches sejam reconfigurados, recursos sejam alocados e monitorados. Em suma, a rede deve ser a mais flexvel possvel, para que
1
Instituto de Tecnologia Programa de Ps-graduao em Engenharia Eltrica e de Computao Universidade Federal do Par (UFPA) 66.075-110 Belm PA Brasil. Instituto de Cincias Exatas e Naturais Programa de Ps-graduao em Cincia da Computao Universidade Federal do Par (UFPA) 66.075-110 Belm PA Brasil. Grupo de pesquisa em Rede de Computadores e Comunicao Multimdia (GERCOM) Universidade Federal do Par (UFPA) 66.075-110 Belm PA Brasil.{fernnf,salvatti,abelem}@ufpa.br.
55
FERNANDO N. N. FARIAS, JOO J. SALVATTI, ANTNIO J. G. ABELM
essa infraestrutura permita a coexistncia de mltiplos modelos paralelos. Nesse sentido, a virtualizao (de rede, dispositivos, enlace e etc.) e a soluo OpenFlow vm se tornando uma interessante alternativa para habilitar mltiplos experimentos com novas arquiteturas em um ambiente de produo. Este captulo tem como principal objetivo apresentar os desafios e solues para se criar um ambiente de testes para a Internet do Futuro utilizando tcnicas de virtualizao de redes e o framework OpenFlow. 1. Introduo A Internet hoje est sendo usada para uma grande variedade de propsitos comerciais e no comerciais. Para muitas pessoas, uma ferramenta de trabalho crucial, para outras, seu local de trabalho. Porm, para a grande maioria, um eficiente meio de comunicao, entretenimento ou plataforma educacional. Ou seja, a Internet um enorme sucesso mundial e vem mudando a forma como interagimos, trabalhamos e nos divertimos. Boa parte deste sucesso se deve grande flexibilidade da tecnologia IP (Internet Protocol), que prov um mecanismo uniforme de transporte fim a fim, independente das tecnologias utilizadas nas camadas de mais baixo nvel. Apesar de todo o sucesso da Internet, a tecnologia bsica IP a causa das suas prprias limitaes, que se tornam cada vez mais evidentes. A noo central de tamanho nico, que requer tratamento idntico para todos os fluxos de informao na Internet ao nvel do pacote IP, no desejvel e nem necessariamente econmica, especialmente quando certas classes de aplicao, tais como de mdia interativa ou de acesso remoto a instrumentos cientficos, requerem garantias de qualidade de servio (Quality of Service QoS) desnecessrias para a maioria de outras aplicaes. A atual arquitetura da Internet, inicialmente projetada h aproximadamente 30 anos, sofreu muitas extenses nos anos recentes para incluir novas funcionalidades, as quais no foram previstas no projeto inicial. Muitos especialistas de rede agora consideram que necessrio conduzir um estudo de arquiteturas alternativas para Internet do Futuro (IF), como uma maneira realmente eficiente de resolver muitos dos problemas prementes que atualmente afligem a Internet. Algumas das desvantagens da continuada persistncia no uso da atual arquitetura incluem: exausto iminente do espao atualmente disponvel de identificadores de rede IP verso 4 (IPv4), causando uma balcanizao da Internet, sem verdadeira conectividade global;
56
EXPERIMENTAO NO FUTURO DA INTERNET
custos elevados dos roteadores IP, restringindo o crescimento da rede, motivado principalmente pela natureza no escalonvel das tabelas de roteamento, e dos requisitos de desempenho necessrios para poder processar essas gigantescas tabelas na mesma velocidade que seus enlaces; investimentos imensos em medidas paliativas para conter problemas de segurana atualmente causados por spam, negao de servio (DoS denial of service) e crimes de roubo de informao; dificuldades de combinar transparncia de acesso e desempenho de aplicao para usurios mveis. Devido a isso, nos ltimos anos, vem sendo aplicada arquitetura da Internet uma srie de modificaes pontuais ou remendos, para atender s limitaes encontradas. Entre os remendos, podem ser mencionados Classless Internet Domain Routing (CIDR), Network Address Translation (NAT), Servios Integrados (Intserv), Servios Diferenciados (Diffserv), IP Seguro, IP Mvel, firewalls e filtros de spam; estes so os mais conhecidos. Por conta disso, h um entendimento crescente entre os pesquisadores em redes de computadores que as solues para a maioria destes problemas dependero de um redesenho fundamental da atual arquitetura da Internet, baseada em IP. E como aliada na busca dessas solues, surge a atividade conhecida como Internet do Futuro, que inclui entre seus principais objetivos a formulao e avaliao de arquiteturas alternativas para substituir o IP, o qual frequentemente ilustrado pelo conhecido modelo da ampulheta da Internet, apresentado na Figura 1.
57
Figura 1.1: A evoluo do conceito da Internet [Banniza et. al., 2009]
Nesse contexto, duas abordagens esto sendo discutidas e investigadas. A primeira denominada limpa (Clean Slate), que visa substituir a arquitetura atual por uma nova totalmente reconstruda. A outra, chamada evolucionria (Evolutionary), que pretende evoluir a arquitetura atual sem perder a compatibilidade com a anterior. A proposta Clean Slate, que atualmente um dos esforos para o desenvolvimento da Internet do Futuro, tem como principal objetivo direcionar como ser efetuado o desenho da nova Internet [NICK, 2011]. Mas para que isso ocorra, a IF deve atender a um conjunto de requisitos importantes. Dentro desse contexto, David C. [2009] cita os caminhos e os requisitos fundamentais para o sucesso desta nova arquitetura, proposta que Clean Slate ir tomar para projetar a IF. Dentre esses requisitos, podemos destacar os principais desafios como: robustez e disponibilidade, suporte a ns mveis economicamente vivel e rentvel, gerenciabilidade com segurana e ser evolutiva. As pesquisas baseadas em Clean Slate permitem explorar radicalmente uma nova arquitetura para Internet, mas isso no quer dizer que sero imediatamente aplicadas. Desse modo, algumas dessas solues
58
podem ter ou no um caminho vivel de implantao na Internet atual [ANJA F., 2007]. Por outro lado, tem-se a abordagem Evolutionary ou Incremental, que tem a misso, como pesquisadores da Internet, de primeiro medir e entender o estado corrente que se encontra a infraestrutura atual da Internet, para poder prever qual caminho ela seguir e quais problemas enfrentar. Depois, com isso, criar o que pode ser referenciado como uma inteligente mutao [JENNIFER e CONSTATINE, 2010], ou seja, inovaes que podem, primeiro, afastar ou resolver estes desafios e, segundo, que possam ser adaptadas para a corrente infraestrutura da Internet, de uma forma que seja compatvel com as verses anteriores e possa ser incrementalmente expansvel. A adoo de qualquer uma das arquiteturas alternativas pode alterar a situao em que a Internet atual se encontra. Entretanto, um srio obstculo para adoo efetiva de tais inovaes tem sido a inabilidade de valid-las de maneira convincente. A reduo no impacto do mundo real de qualquer inovao se deve enorme base instalada de equipamentos e protocolos e relutncia em experimentar com trfego de produo, o que tem criado uma barreira extremamente alta para a entrada de novas ideias. O resultado que a maior parte das novas ideias da comunidade de pesquisa de rede no testada, levando crena comumente mantida de que a infraestrutura da Internet ossificou [PAUL, PAN e JAIN, 2011]. Tendo reconhecido o problema, a comunidade de pesquisa de rede est desenvolvendo solues alternativas para pesquisa experimental em IF. Suas atividades inicias, usando redes para experimentao (testbed), comearam nos EUA com os programas Global Environment for Network Innovations (GENI)[GENI, 2011] e Future Internet Design (FIND)[FIND, 2011], cujas principais propostas so testar e amadurecer um grande conjunto de pesquisas em comunicao de dados e sistemas distribudos. Alm disso, ainda h o FIRE na UE (Unio Europeia) [FIRE, 2011] que uma iniciativa de ambiente de pesquisa para experimentao e validao de ideias inovadoras e revolucionrias para novos paradigmas de redes e servios. Nesta mesma linha, temos o projeto AKARI no Japo [AKARI, 2011], um programa de pesquisa que tem como objetivo implementar a nova gerao de redes para 2015, baseada na proposta Clean Slate. E por fim, iniciativas semelhantes tambm foram lanadas mais recentemente em outras partes do mundo [CFI, 2011][JUN BI, 2011]. Neste sentido, redes de experimentao programveis e virtualizadas vm sendo utilizadas por esses projetos para diminuir a barreira de custo entrada de novas ideias, aumentando a taxa de inovao
59
da infraestrutura de rede. Com isso, so oferecidas infraestruturas capazes de habilitar, controlar e testar as respectivas abordagens, de modo a valid-las eficientemente, sem prejudicar a infraestrutura atual. No contexto de redes programveis, o framework OpenFlow a ferramenta que vem oferecendo a pesquisadores a possibilidade de testar seus protocolos experimentais em redes de produo como: redes de um campus, redes metropolitanas ou em um backbone de rede de ensino e pesquisa. O OpenFlow, alm de oferecer o protocolo de controle, chamado de OpenFlow protocol para manipular a tabela de encaminhamento dos roteadores e switches, tambm oferece uma API (Application Programming Interface) simples e extensvel para programar o comportamento dos fluxos de pacotes. Desta forma que, atravs desta API, pesquisadores podem rapidamente construir novos protocolos e aplic-los em um ambiente de produo sem prejudic-lo [MCKEOWN, 2008]. A virtualizao de computadores tem sido usada h muito tempo e hoje est amplamente disponvel em plataformas comuns. realizada por meio do compartilhamento de processadores e dispositivos de E/S, utilizando tcnicas de fatiamento de tempo e memria virtual. A virtualizao de redes mais recente e conseguida pelo uso de switches e roteadores virtuais e a multiplexao de enlaces [CHOUDHURY, 2010]. Observando isso, o uso das tcnicas de virtualizao de redes (dispositivos, enlace, etc.) em conjunto com a soluo OpenFlow vem se tornando uma excelente alternativa para habilitar mltiplos experimentos com novas arquiteturas em um ambiente de produo. Uma rede OpenFlow permite que se possa programar o comportamento da rede, alm de criar ambientes virtuais de rede chamados de fatias (redes virtuais com ns, enlaces e recursos) para testar novas ideias e modelos de protocolos para IF. Este captulo tem como principal objetivo apresentar as iniciativas para o desenvolvimento da IF, seus requisitos necessrios e o uso de virtualizao e OpenFlow para se criar um ambiente de testbed para experimentao e desenvolvimento de protocolos na abordagem de IF. Alm desta seo introdutria, o captulo est dividido da seguinte maneira: Seo 2 so apresentadas as recentes experincias realizadas para Internet do Futuro, tanto no Brasil como em backbones da Europa e da Amrica do Norte; Seo 3 detalhado o framework OpenFlow, incluindo os principais aspectos sobre virtualizao; Seo 4 so descritos os requisitos para construo de um testbed experimental;
60
Seo 5 tem-se um estudo de caso de criao de vrios slices de redes para testes de protocolos; Seo 6 so apresentadas as consideraes finais e tendncias futuras em relao pesquisa experimental e Internet do Futuro. 2. Pesquisa experimental em Internet do Futuro no Brasil e no mundo Atualmente, na comunidade acadmica, existe um amplo consenso de que a Internet atual sofre vrias limitaes, relacionadas escalabilidade, a suporte a redes mveis de vrios tipos (ad-hoc, multi-hop e mesh), mobilidade, ao consumo de energia, transparncia, segurana e a outros [RAJ JAIN, 2006]. A partir disso, nesta seo, so levantados e comentados os principais desafios que esto relacionados Internet do Futuro. Como tambm, so observados os projetos a respeito de investigao da IF como o caso do GENI (Global Environment for Network Innovation), financiado pela NSF (National Science Foundation), FIRE (Future Internet Research and Experimentation), pela Unio Europeia e FIBRE (Future Internet Experimentation between Brazil and Europe) no Brasil. 2.1. Desafios relacionados Internet do Futuro A ideia bsica da arquitetura da Internet foi desenvolvida h mais de trinta anos. Neste tempo, tem-se aprendido bastante sobre redes de computadores e encaminhamento de pacotes. Tambm, durante este mesmo perodo, a Internet vem sofrendo contnuas adaptaes, causadas pelo seu rpido crescimento e pela quantidade de usurios e de aplicaes habilitadas sobre sua arquitetura. Essas adaptaes ou remendos demonstram que o projeto inicial j no se ajusta s necessidades atuais na rede. Alm disso, a arquitetura atual da Internet j apresenta inmeros problemas ainda no solucionados, impedindo o atendimento dos requisitos destas novas aplicaes e servios. Muitos especialistas em rede de computadores chegaram a um consenso de que agora consideram extremamente necessrio conduzir um estudo de arquiteturas alternativas para Internet do Futuro como uma maneira realmente eficiente de resolver muitos dos problemas prementes que atualmente afligem a Internet. A seguir, so apresentados alguns dos principais desafios, que segundo Subharthi e Jianli e Raj [2011], a nova arquitetura da Internet deve atender.
61
2.1.1. Suporte a Novas Tecnologias de Rede A Internet atual projetada para tirar vantagem de uma grande gama de tecnologias de rede. No entanto, hoje h vrios desafios no horizonte, entre elas as tecnologias sem fio e as novas solues pticas. As redes sem fio abrangem uma srie de tecnologias que vai do wi-fi de hoje at as ultra-widebands e redes de sensores sem fio de amanh. Considera-se que as redes sem fio so talvez umas das maiores tecnologias de rede e com granularidade maior ou igual s redes locais (LAN). No entanto, uma consequncia das redes sem fio a mobilidade. Hoje, a mobilidade est borda da rede, mas os mecanismos para torn-la mais eficiente no funcionam de maneira satisfatria, principalmente nas questes relacionadas eficincia energtica, mudana de ponto de acesso e s aplicaes. Portanto, identificam-se os seguintes desafios para suporte s tecnologias sem fio: A Internet do Futuro deve suportar a mobilidade como o objetivo primordial em sua construo. Os ns devem ser capazes de modificar seu ponto de acesso na Internet e, mesmo assim, continuarem sendo alcanveis. A Internet do Futuro deve oferecer meios adequados para descobrir as caractersticas dos mais variados tipos de enlace de rede sem fio e se adaptar a eles, de maneira a prover as eficincias energticas destes ns. A Internet do Futuro deve facilitar o processo pelo qual os ns mveis, fisicamente prximos, descubram-se uns aos outros. Outra tecnologia revolucionria a rede de transporte ptica. A comunidade de pesquisadores em redes pticas est desenvolvendo maneiras de como usar as novas tecnologias como switches pticos e elementos lgicos para encaminhar dados em desempenhos maiores que as redes puramente eletrnicas. Isso envolve mudanas em vrios nveis de redes em anis para redes em malha, de redes com comprimentos de ondas fixamente alocados para transmissores e receptores dinamicamente alocados, de redes sem buffers pticos para redes com planos de controles inteligentes e com buffers pticos suficientes e de redes pticas que utilizam fixas larguras de bandas para as que permitem que a largura de banda seja dinamicamente alocada, acessadas e utilizadas. Logo se identificam os desafios para Internet do Futuro explorar a emergente capacidade ptica:
62
A Internet do Futuro deve ser projetada para permitir aos usurios a utilizao dessas novas capacidades de transporte pticos, incluindo uma melhor confiabilidade atravs de diagnsticos entre camadas. A Internet do Futuro deve permitir que os ns que so dinamicamente configurveis habilitem a camada eletrnica para o acesso dinmico de usurios. A Internet do Futuro deve incluir softwares de controle e gerenciamento que permitam rede formada por ns dinamicamente reconfigurveis ser configurada por aplicaes que necessitem de uma grande quantidade de recursos de rede, tal como largura de banda. 2.1.2. Segurana e robustez Talvez a razo que mais estimulou a comunidade acadmica a pensar em um redesenho da Internet foi ter uma rede com grandes avanos na segurana e robustez. Na Internet atual, no h nenhuma abordagem realmente abrangente para tratar questes de segurana. Ela possui muitos mecanismos, mas no uma arquitetura segura e muito menos um conjunto de regras determinando como esses mecanismos devem ser combinados para se obter uma boa segurana de maneira geral. A segurana em redes e principalmente a da Internet, atualmente se assemelha a um conjunto crescente de remendos, extremamente suscetvel a falhas. Para a construo de uma rede mais robusta e segura, identificam-se os seguintes desafios: Qualquer conjunto de hosts deve ser capaz de se comunicar entre si com alta confiabilidade e previsibilidade, e ns maliciosos ou defeituosos no podem ser capazes de interromper esta comunicao. Alm disso, os usurios devem esperar por um nvel de disponibilidade correspondente ou que exceda o sistema de telefonia de hoje. A segurana e robustez devem ser estendidas atravs de suas camadas, pois a segurana e a confiabilidade de um usurio final dependem da robustez, tanto nas camadas de comunicao quanto nas aplicaes distribudas.
63
2.1.3. Eficincia energtica na comunicao Atualmente, h uma preocupao mundial [WILLIAMS e CURTIS, 2008] por desenvolvimento de tecnologias que diminuam o consumo de energia, principalmente por redes, como as de sensores sem fio e as de dispositivos mveis wi-fi, em que recursos energticos so fatores relevantes em sua comunicao. Com as atuais tecnologias, comunicando um bit sobre um meio sem fio, em intervalos curtos, consomem mais energia do que o seu processamento, e no h tendncia de mudanas em um futuro prximo [Chen, 2006]. No entanto, a Internet atual no possui mecanismos que levem em considerao a comunicao com requisitos de eficincia de energia, de modo a adaptar o seu consumo mediante a observao do meio. Ou ainda, que adapte o uso de energia para oferecer uma comunicao eficiente, na transmisso de dados e no gerenciamento de rede, a baixos nveis energticos. Portanto, como desafio para o projeto da Internet do Futuro: Deve-se prover meios para uma eficincia energtica generalizada tanto para dispositivos sem fio quanto os com fio; Desenvolver tecnologias com foco no uso eficiente da energia eltrica; Incluir em sua arquitetura mecanismos que ofeream uma comunicao eficiente tanto na transmisso de dados como no gerenciamento de rede; Prover uma arquitetura para Internet do Futuro energeticamente otimizada. 2.1.4. Separao de Identidade e Endereo Na Internet atual, um sistema identificado pelo seu endereo IP. Como resultado, quando o sistema muda seu ponto de localizao da interligao, seu endereamento tambm muda. Ou seja, o endereo IP, neste caso, ao mesmo tempo, tem o papel de identificador e localizador. Devido a isso, os ns mveis se tornaram um desafio na Internet atual. Por essas caractersticas, os sistemas mveis tm dificuldades de serem atingidos. Este um problema bem conhecido na Internet e h um nmero considervel de tentativas e propostas para resolver esse problema, incluindo: mobile IP, Internet indirection infraestructure [Stoica et. al, 2002],
64
host identify protocol [MOSKOWITZ e NIKANDER, 2005] [MOSKOWITZ e NIKANDER e JOKELA, 2005] e outros [BALAKRISHNAN, 2004]. Assim, para a Internet do Futuro existem os seguintes desafios: Aplicar solues que permitam a localizao global de um determinado host, atravs da utilizao de um sistema de endereamento global; Definir novas formas de localizao e identificao, alm do desenvolvimento de endereamentos coesos s necessidades da rede. 2.1.5. Qualidade de Servio e Qualidade de Experincia A natureza do IP, no orientado a conexo, dificulta qualquer aplicao de garantia de QoS (Quality of Service). Alm disso, a caracterstica de encaminhamento de pacote baseado em melhor esforo faz com que qualquer abordagem relacionada a questes de reservar recursos ou prioridade interfira no funcionamento estabelecido para Internet atual. Desta maneira, embora a qualidade de servio tenha sido extremamente pesquisada na comunidade acadmica, ainda no h um modelo claro de como diferentes nveis de qualidade devem ser aplicados e de que forma ele se integrar arquitetura de rede atual. Desta forma, so desafios para a arquitetura da Internet do Futuro: Permitir uma variedade de garantias levando em considerao tanto a qualidade da aplicao na rede como a qualidade de experincia do usurio; Novos mtodos de encaminhamentos de pacote baseados nas caractersticas das aplicaes, principalmente as de tempo real. 2.1.6. Separao entre os planos de controle, gerenciamento e dados Na Internet atual, os planos de controle, gerenciamento e dados so unificados. Ou seja, mensagens de controle, por exemplo, mensagens de conexo TCP (Transmission Control Protocol) ou mensagens de gerenciamento SNMP (Simple Network Management Protocol) seguem no mesmo canal em que trafegam os dados. Como consequncia, isso possibilita um significante risco de segurana dos dados de controle, alm do desperdcio de recursos da rede.
65
Uma vantagem desta separao de planos a adoo de novas tecnologias de plano de dados pela arquitetura de rede como: um comprimento de onda; frame SONET; ou uma linha de transmisso de energia (Power Line Comunication PLC). Portanto, esta separao entre os planos deve ser parte integral desta prxima gerao da arquitetura da Internet. 2.1.7. Isolamento Para algumas aplicaes crticas, o usurio demanda isolamento em um ambiente compartilhado como na Internet atual. Isolamento significa garantir que o desempenho desta aplicao crtica no seja afetado por outras aplicaes que queiram compartilhar o mesmo recurso. Com o uso da virtualizao, o isolamento se tornou um fator ainda mais importante, principalmente para virtualizao de redes, onde um roteador ou uma infraestrutura de rede totalmente virtualizada, de forma que o encaminhamento de pacotes no pode, de maneira alguma, ser interferido ou interferir, em outras infraestruturas. Assim, a prxima gerao da Internet deve prover de modo eficiente um mix programvel em sua arquitetura de isolamento e compartilhamento, s suas aplicaes e servios. 2.1.8. Mobilidade Atualmente vem se observando uma crescente e diversificada quantidade de servios na Internet, impulsionada principalmente pelo aumento do acesso de dispositivos sem fio. Com isso, amplia-se a necessidade de mobilidade pelos usurios. Alm disso, a forma de comunicao estabelecida originalmente pela arquitetura da Internet atual como conexo ponto a ponto e entrega imediata, faz com que esses tipos de usurios no sejam atendidos satisfatoriamente. Principalmente, por causa de uma questo comum relacionada mobilidade, que so os handovers, criados com o objetivo de evitar que os ns mveis tenham a perda das suas conexes ativas. Os protocolos da Internet atual no preveem o tratamento desse comportamento. E ainda, protocolos como TCP tambm so prejudicados por no prever esse tipo de usurio. Com isso, a Internet do Futuro enfrenta o grande desafio de como permitir a movimentao do n entre diferentes pontos de acesso sem que as conexes ativas sejam perdidas.
66
2.1.9. Escalabilidade Com o aumento exponencial do nmero de estaes conectadas Internet, alguns componentes da arquitetura atual tm sofrido com problemas de escalabilidade. Esse o caso do sistema de roteamento, que sofre com o aumento e as atualizaes frequentes de suas tabelas. Ainda h a questo do endereamento que no capaz de suportar todos os elementos conectados rede como o caso do IPv4. Portanto, a Internet do Futuro ter o desafio de manter o sistema global de roteamento escalvel, alm de novos protocolos que mantenham essa escalabilidade, mesmo com o aumento do espao de endereamento. E tambm novas formas de endereamento para evitar a escassez do recurso. 2.2. Iniciativas para investigao em Internet do Futuro A comunidade acadmica, observando os problemas atuais da Internet, comeou uma corrida para solucionar os desafios da Internet do Futuro e, com isso, modelar a arquitetura que conduzir a prxima gerao da Internet. No entanto, estas novas propostas e especulaes tericas na direo destas solues devem ser suportadas por uma infraestrutura real de rede experimental e testadas em ambientes de larga escala. Estas instalaes experimentais desempenham o papel de rede de teste ou testbed, conduzindo experimentos para a prova de conceitos de novas arquiteturas, protocolos, tecnologias e servios. Alm disso, uma coexistncia com a rede de trfego de produo essencial para observao e captura de certos aspectos e fenmenos perceptveis apenas em instalaes operacionais e assim permitir que sejam avaliados os seus impactos sobre a sociedade e a economia. Observando essas necessidades, algumas iniciativas em pesquisa da Internet do Futuro comearam a surgir, principalmente nos Estados Unidos, Europa e no Brasil, conforme a seguir. 2.2.1. GENI (Global Environment for Network Inovation) A Global Environment for Network Inovation (GENI) a principal iniciativa americana em investigao e experimentao em Internet do Futuro. O GENI um conjunto de infraestruturas de redes de pesquisa,
67
dos mais variados modelos tais como: sem fio, ptico e eltrico. Patrocinada pela National Science Foundation (NSF), atualmente est em fase de desenvolvimento e prototipagem. O objetivo do projeto GENI montar um grande laboratrio virtual em larga escala para experimentaes em rede de computadores, cuja maior importncia prever e criar novas possibilidades para Internet do Futuro. Para o GENI, os conceitos principais relacionados experimentao em Internet do Futuro e que fazem parte do projeto de sua arquitetura so [GENI Sys, 2008]: Programabilidade: Os pesquisadores podero fazer upload de softwares aos ns do GENI para programar ou controlar o seu comportamento. Virtualizao e outras formas de compartilhamento de recursos: Qualquer que seja a implementao de mquina virtual sobre um n GENI, ser permitido que mltiplos pesquisadores simultaneamente compartilhem a mesma infraestrutura. Cada experimento ter sua disposio uma fatia ou slice isolado, com recursos fim a fim alocados dentro da infraestrutura do GENI. Federao: O GENI ser composto de infraestruturas prprias e de outras de apoio, operadas por organizaes parceiras ao projeto, criando o conceito de federaes de recursos e ns, que na viso de um pesquisador, comporta-se como se fosse nica infraestrutura. Experimentos baseados em fatias (Slices): Os experimentos no GENI sero interconectados a um conjunto de recursos reservados sobre uma plataforma em diversas localizaes, dando a ideia de uma fatia ou slice de recursos. Dentro dessa fatia o pesquisador poder remotamente descobrir, reservar, configurar, debugar, operar e gerenciar seus experimentos e recursos disponveis. Para se ter uma ideia de como o GENI ir funcionar aps a sua concepo, a Figura 2.1 ilustra o fluxo que um pesquisador percorrer para habilitar seu experimento dentro da infraestrutura do GENI.
68
Figura 2.1 A criao de um slice sobre a infraestrutura do GENI [GENI Sys, 2008]
Na Figura 2.1, observado o processo que um pesquisador ir executar para solicitar e utilizar um slice para experimentao de seus modelos ou protocolos na arquitetura do GENI. Esse processo formado por trs estgios intermedirios: descoberta de recurso, criao do slice e experimentao. Na descoberta de recursos (DR), Figura 2.1 (a), o pesquisador ter uma viso global dos recursos disponveis para o seu experimento. A partir disso, poder definir, de maneira simples, quais os recursos do GENI sero utilizados em seus experimentos. Na criao do slice (CS), Figura 2.1 (b), o pesquisador recebe um slice ou um continer vazio onde sero instanciados os softwares e os recursos que foram definidos pelo DR. Neste caso, um slice uma integrao de dois agregados: um cluster de computadores e uma rede ou um conjunto de redes. Por fim, na experimentao, Figura 2.1 (c), o pesquisador poder instalar os seus softwares, executar, parar e coletar resultados do experimento. O GENI o conjunto de grandes testbeds com vrias alternativas para experimentaes. Dentre estes testbeds, podemos destacar: PlanetLab, EmuLab e ORBIT [Spiral2, 2010] [RAJ JAIN et. al, 2011].
69
PlanetLab O PlanetLab [Peterson, 2006] um consrcio formado por instituies acadmicas, governamentais e industriais que visa criao de uma grande malha de computadores espalhados pelo mundo em diversas redes. Essa malha serve como um grande laboratrio, para testes e desenvolvimento de aplicaes distribudas. A significncia e abrangncia do projeto permite o compartilhamento de aplicaes em larga escala e uma grande integrao entre as instituies de pesquisa participantes. Hoje, ele possui mais de 700 mquinas espalhadas em 350 locais diferentes, totalizando 25 pases e mais de 275 projetos ativos. Na Figura 2.2, temos um mapa ilustrando os principais sites do PlanetLab.
Figura 2.2 Sites PlanetLab ao redor do mundo
No projeto GENI, o PlanetLab [SPIRAL2, 2010], ser uma alternativa de testbed aos seus pesquisadores. Atualmente, dirigido pela Universidade de Princeton e tem como escopo integrar logicamente os componentes GENI aos servios PlanetLab como: PLC (PlanetLab Central Sofware), responsvel por criar a rede sobreposta definindo a topologia virtual que ser usada para experimento; e o SFA (Slice-Based Facility Architecture), responsvel por localizar e alocar os recursos para os experimentos [PETERSON et. al, 2009].
70
ORBIT O projeto ORBIT prov um flexvel testbed sem fio, aberto comunidade acadmica. Ele foi desenvolvido para que pesquisadores entendessem as limitaes do mundo real das redes sem fio, que muitas vezes no so percebidas em simulaes por causa das simplificaes aplicadas ao modelo ou por terem sido aplicadas em uma quantidade pequena de ns. O ORBIT possui dois testbeds: o primeiro indoor, constitudo de 400 ns dispostos em uma grade 20x20 (ilustrado na Figura 2.3), separados por um metro de distncia entre os ns adjacentes, onde cada n composto por uma plataforma PC com mltiplas interfaces sem fio e com fio. O segundo testbed est localizado no campus da Universidade de Rutges, dentro de uma rea de 1,5 hectares quadrados. Entre eles existem ns fixos, e tambm ns mveis para prover mobilidade entre os roteadores.
Figura 2.3 Testbed Indoor do ORBIT
No GENI, sua integrao permitir que pesquisadores gerenciem esse testbed de redes sem fio dentro do GENI, alm de estender a capilaridade de ns do ORBIT para outros testbed sem fio. No GENI, o ORBIT ser integrado dentro do ambiente OMF (cOntrol and Management Framework) [OMF, 2011].
71
EmuLab EmuLab [Eide et. al, 2006] um testbed em redes de computadores que oferece aos seus pesquisadores um range de ambientes aos quais eles podem desenvolver, analisar e avaliar seus sistemas. O nome EmuLab refere-se tanto ao testbed quanto ao software de interao do usurio ao testbed. O projeto gerenciado pela Universidade Utah, onde foram desenvolvidos os primeiros ns do testbed. Atualmente, h mais de doze pases utilizando o EmuLab, totalizando um testbed com mais de cem ns. Na Figura 2.4, temos os clusters de computadores utilizados pelo EmuLab. Os ambientes disponveis no EmuLab so: Emulao (Emulation), neste ambiente o pesquisador define uma topologia arbitrria com switches ou roteadores e ns PC; Live-Internet, o Emulab oferece um ambiente federado para experimentos sobre Internet; No 802.11 Wireless, prov um ambiente com ponto de acesso, roteadores e cliente para experimentos em rede sem fio; e o ambiente Software-Defined Radio, o qual permite experimentaes em camada 1 para anlise de processamento de sinal.
Figura 2.4 Cluster EmuLab
No GENI, a integrao do EmuLab ao projeto conhecida de ProtoGENI [ProtoGENI, 2011], e permitir ao EmuLab expandir ainda
72
mais seu testbed, alm de controlar novos no oferecidos atualmente, por exemplo infraestrutura de altssima velocidade dos backbones da internet2. 2.2.2. Future Internet Research and Experimentation (FIRE) A iniciativa FIRE (Future Internet Research Experimentation) na Europa visa pesquisa experimental e ao financiamento de projetos que produzam infraestruturas para experimentao em Internet do Futuro. A meta que as pesquisas em tecnologias para Internet do Futuro sejam direcionadas rede ou a servio e tenham a possibilidade de comparar as solues correntes com as propostas futuras. Desta forma, afirma-se que o FIRE possui duas dimenses relacionadas que direcionam suas pesquisas e seus investimentos [FIRE, 2008]: Pesquisa Experimental: o objetivo integrar a pesquisa multidisciplinar e a experimentao em larga escala. A partir da, definir uma metodologia que direcionar pesquisa experimental na infraestrutura FIRE, baseada em um ciclo interativo que vai da pesquisa, passando pelo projeto e chegando experimentao. Facilidades para Testes: o objetivo oferecer um ambiente de testes, testbed, interconectados, suportando vrias tecnologias e envolvendo uma granularidade de testbeds federados, de modo que ele seja sustentvel, dinmico e integrado em larga escala. E ainda, que facilite a pesquisa experimental na comunidade acadmica, centros de pesquisa e indstria. Para o FIRE, as experincias prticas so extremamente necessrias para dar credibilidade e levantar o nvel de confiana na concluso da pesquisa. Alm disso, a experimentao deve ser executada em larga escala para que seja representativa, convincente, e para provar a escalabilidade da soluo testada. Os projetos de testbed em destaque financiados pela iniciativa FIRE incluem [FIRE, 2010]: BonFIRE, CREW e OFELIA. BonFIRE A iniciativa BonFIRE (Building Services Testbeds on FIRE) [BonFIRE, 2011] um projeto baseado em nuvens multi-site para o suporte pesquisa de aplicaes, servios e sistemas, visando a Internet de Servios dentro
73
da Internet do Futuro. O BonFIRE objetiva oferecer aos pesquisadores acesso a um ambiente experimental em larga escala para experimentao de seus sistemas e aplicaes, avaliaes do efeito cross-cutting da convergncia dos servios, infraestrutura de rede e a anlise do impacto socioeconmico. O BonFIRE ir operar uma nuvem baseada em IaaS (Infrastructure as a Service) com polticas e melhores prticas de experimentaes. Ele ir se adaptar a uma abordagem multiplataforma federada provendo interconexo e interoperao entre os servios e a rede no testbed. A plataforma ir oferecer servios avanados e ferramentas para pesquisa de novos servios, incluindo nuvens de federaes, gerenciamento de mquinas virtuais, modelagem, gerenciamento do ciclo de vida a experimentao, monitoramento da qualidade de servio e anlise de desempenho. A Figura 2.5 ilustra o ambiente BonFIRE.
Figura 2.5 Infraestrutura disponvel no BonFIRE [FIRE, 2010]
CREW O principal objetivo do CREW (Cognitive Radio Experimentation World) [CREW, 2011] estabelecer uma plataforma de teste aberta e federada que facilite o avano em pesquisa em avanados no sensoriamento de espectros, rdios cognitivos e estratgias de redes cognitivas em vises horizontais e verticais do espectro compartilhado em bandas licenciadas e no licenciadas.
74
O CREW incorpora quatros testbeds individuais sem fio utilizando um ranger de tecnologias sem fio como: heterogneos ISM, Celular e Sensores sem fio, com o estado da arte de plataforma de sensoriamento cognitivo. O CREW ir fisicamente e virtualmente federar componentes interligando entidades de software e hardware de diferentes padres usando APIs padronizadas. Alm disso, o CREW estabelecer um benchmark framework, habilitar experimentos controlados, metodologias para anlise automtica de performance e reproduzir condies para teste.
Figura 2.6 Ambiente federado CREW [FIRE, 2010]
OFELIA O projeto OFELIA [Ofelia, 2011] visa criar um ambiente experimental, testbed, que permita a seus pesquisadores no somente experimentao, mas tambm o controle a redes a sua maneira de forma precisa e dinmica. Para alcanar isso, o testbed OFELIA baseado em OpenFlow, atualmente uma emergente tecnologia de rede que permite virtualizar e controlar ambiente de rede, atravs de interfaces seguras e padronizadas. O OFELIA prover
75
equipamentos OpenFlow de alto desempenho para habilitar experimentos em alta escala. A infraestrutura federada pelo OFELIA, inclui ilhas OpenFlow na Blgica, Alemanha, Espanha, Sua e Reino Unido. Essas ilhas renem uma diversidade de infraestruturas baseadas em OpenFlow que permitir experimentaes em redes multicamadas e multitecnologias. Na Figura 2.7, apresentado como a estrutura dessas ilhas ser instalada em cada um desses pases. O OFELIA permitir o teste de novos algoritmos de roteamento, tunelamento, protocolos e planos de controle. Alm disso, novas aplicaes podero ser colocadas no controlador OpenFlow a qualquer momento na infraestrutura. Tambm permitir serem investigadas novas estruturas e formatos de endereamento e modelos de encaminhamentos.
Figura 2.7 Estrutura de uma ilha, baseada em OpenFlow no projeto OFELIA [Ofelia, 2011]
2.2.3. Iniciativas Brasileiras Os parceiros brasileiros contribuem no projeto com a experincia na implantao de instalaes de experimentao locais e na participao em diferentes projetos de pesquisa experimental em Internet do Futuro,
76
embora com pouca ou nenhuma coalizo estratgica entre elas. O primeiro desses projetos a se destacar o projeto de pesquisa e desenvolvimento GIGA e suas instalaes experimentais em grande escala conhecido como rede GIGA, coordenado conjuntamente pelo CPqD e a RNP [SCARABUCCI, 2005]. O projeto GIGA atualmente se concentra em redes pticas e definidas por software. Dever ser atualizado em breve com comutadores OpenFlow de 10G (o primeiro na Amrica do Sul) e uma soluo aberta (open-source) de roteamento de pacotes (o primeiro do mundo e neste momento disponvel para parceiros selecionados nos EUA e no Brasil) que roda sobre o NOX para controlar o encaminhamento de pacotes em redes com tecnologia OpenFlow habilitada. A rede GIGA conecta mais de 66 laboratrios de 23 instituies da Regio Sudeste do Brasil e est conectada com a rede nacional de ensino e pesquisa (Rede Ip). Atravs desta, interliga-se com redes de pesquisa e ensino em todo o mundo. A rede GIGA mantm um n GENI (ou seja, servidores) no CPqD. O segundo projeto de destaque o projeto Web Science [WEBSCIENCE, 2010], apoiado pelo CNPq. O projeto Web Science comeou efetivamente em 2010 e o subprojeto de Arquiteturas para a Internet do Futuro envolve a RNP e quatro Universidades parceiras com experincia em redes pticas e sem fio, estudos de simulao e emulao e monitoramento de rede. Um dos primeiros objetivos do projeto estabelecer ilhas experimentais nos laboratrios de cada parceiro e interlig-las em camada 2 atravs das redes de Ip e GIGA. FIBRE Coordenado pela Universidade Federal do Par, atravs do Grupo de Pesquisa em Redes de Computadores e Comunicao Multimdia (GERCOM) [22], o projeto FIBRE, aprovado no edital de Chamadas Coordenadas Brasil-Unio Europeia em TIC do CNPq e da CE no seu 7 Programa Quadro (FP7), representa a primeira colaborao direta em IF entre parceiros brasileiros e europeus, mas ambos os lados j tm entendimentos e colaboraes anteriores com iniciativas internacionais em outras partes do mundo. O objetivo principal do projeto FIBRE a concepo, implementao e validao de uma infraestrutura compartilhada de pesquisa em Internet do Futuro que suporte a experimentao conjunta de pesquisadores europeus
77
e brasileiros. Para alcanar este objetivo o projeto executar cinco atividades principais: O desenvolvimento e a operao de uma nova instalao experimental no Brasil, incluindo a instalao de equipamentos de apoio experimentao em diversas tecnologias (camada fixa 2 e camada 3, camada sem fio, camada ptica), bem como a concepo e a implementao de um arcabouo de controle para automatizar o uso e a operao da instalao experimental. O desenvolvimento e a operao de uma instalao experimental na Europa a partir de melhorias e da federao de duas infraestruturas experimentais existentes: OFELIA e OneLab. Duas ilhas OFELIA (i2CAT e UEssex) e a instalao experimental NITOS da UTH sero melhoradas pela i) incluso de mais recursos fsicos (servidores, switches OpenFlow e pontos de acesso sem fio) para poder lidar com um nmero maior de usurios e de casos de uso, ii) pela evoluo dos seus arcabouos de controle (baseado no Expedient e no OMF) e iii) pelo incremento da fora de trabalho para operar as instalaes experimentais. A federao das instalaes experimentais brasileiras e europeias, tanto no nvel de conectividade fsica quanto no nvel de arcabouo de controle, para apoiar o aprovisionamento de fatias de rede usando recursos das instalaes das duas regies. A concepo e a implementao de aplicaes piloto de utilidade pblica para demonstrar o potencial da instalao experimental em Internet do Futuro de larga escala compartilhada entre Europa e Brasil que foi desenvolvida. Aumentar a colaborao e troca de conhecimento entre pesquisadores europeus e brasileiros no campo de Internet do Futuro. O ambiente de teste brasileiro, o qual ser projetado e construdo no projeto, incluir localidades (tambm conhecidos como ilhas) em cada um dos nove parceiros brasileiros neste projeto. A Figura 2.8 mostra as localizaes geogrficas das ilhas brasileiras, das quais seis (incluindo a sede da RNP) so na Regio Sudeste, e uma nas Regies Norte, Nordeste e Centro Oeste. A Regio Norte inclui 45,27% do territrio nacional, incluindo a floresta amaznica, onde as solues cabeadas tradicionais de comunicaes e transmisso de energia eltrica so frequentemente difceis ou impossveis de se usar. O GERCOM na UFPA tem estudado solues
78
customizadas para comunicaes no ambiente da floresta tropical e traz esta experincia e sua instalao experimental para este projeto. Estas localidades sero interconectadas utilizando canais privados (de camada 2) por meio das redes de longa distncia e metropolitanas disposio da comunidade de pesquisa e educao brasileira. Estas incluem a rede backbone nacional Ip da RNP e a rede para experimentao GIGA, mantida conjuntamente pela RNP e CPqD. As redes metropolitanas da RNP, entre elas a Rede MetroBel, sero usadas para acesso quando necessrio e conexes internacionais RNP fornecero acesso a outros ambientes de teste internacionais, tais como de OFELIA e de NITOS, para fins de federao.
Figura 2.8 Localizao e interconexo das instalaes no Brasil
Cada ilha ter um ncleo comum de comutadores habilitados para OF, alguns baseados em NetFPGA e outros em comutadores de qualidade de produo, conjuntamente com seu(s) controlador(es), bem como um cluster de servidores de computao e armazenamento e outro cluster de ns sem fio Orbit, ambos apropriadamente virtualizados.
79
O projeto FIBRE pode ser visto como nico a partir de diferentes perspectivas. Primeiro, pela inovao de prover federao entre instalaes de menor escala entre a Europa e o Brasil visando o atendimento de uma escala de experimentao intercontinental. Segundo, porque o FIBRE habilita um conjunto de experimentaes multitecnologia e multicamada numa escala tambm intercontinental. Este aspecto nico torna-se possvel pelos avanos no estado da arte em programabilidade, virtualizao (ex.: camada ptica), monitorao e federao que o projeto FIBRE prover. 3. Framework OpenFlow e Virtualizao 3.1 Framework OPENFLOW A pesquisa na rea de redes de computadores possui diversos desafios em relao implementao e experimentao de novas propostas em ambientes reais. Isso ocorre devido dificuldade para o pesquisador possuir uma rede de testes prxima de uma rede real. Para isso, foi desenvolvido o OpenFlow [MCKEOWN, 2008] que prope um mecanismo para permitir que redes reais sejam utilizadas como um ambiente de experimentos. O OpenFlow uma proposta tecnolgica que, baseada no modelo de controle de rede logicamente centralizado, permite pesquisadores executarem seus experimentos em redes utilizadas no dia a dia, sem interferir no trfego de produo, fundamentado em switches ethernet comerciais e define um protocolo padro para controlar o estado dos switches (tabela de fluxos, estatsticas e etc.). O conceito de fluxo o bloco fundamental que habilita os pesquisadores definir o plano de encaminhamento na rede, conforme os objetivos definidos pelas novas propostas de arquiteturas e protocolos de rede. O OpenFlow tambm define um novo elemento de rede, o controlador. No OpenFlow, proposto um mecanismo que executado em todos os comutadores ou roteadores de forma que se possa haver isolamento entre os trfegos, o experimental e o de produo. Assim, o OpenFlow possibilita que os pesquisadores reprogramem os comutadores, provocando interferncia nas configuraes da rede de produo. Outro objetivo dessa proposta possibilitar que os fabricantes possam adicionar as funcionalidades do OpenFlow aos seus comutadores sem necessitarem expor o projeto desses equipamentos.
80
Alm disso, tais equipamentos devem possuir um baixo custo e desempenho semelhante aos j utilizados na universidade, de forma que os administradores da rede aceitem a substituio dos equipamentos j existentes. Com base no exposto, o projeto do OpenFlow tem como objetivo ser flexvel para atender aos seguintes requisitos: possibilidade de uso em implementao de baixo custo e de alto desempenho; capacidade de suportar uma ampla gama de pesquisas cientficas; garantia de isolamento entre o trfego experimental e o trfego de produo; consistncia com a necessidade de os fabricantes no exporem o projeto de suas plataformas. O OpenFlow explora a tabela de fluxo que existe nos switches atuais, que normalmente so utilizadas para implementar servios como NAT, firewall e VLANs. O switch OpenFlow constitudo de uma tabela de fluxos e um evento associado a cada entrada na tabela. Basicamente, a arquitetura do OpenFlow composto por trs partes: i. Tabela de Fluxos: Cada entrada na tabela de fluxos contm uma ao associada, e consiste em Campos do cabealho (utilizado para definir um fluxo), aes (define como os pacotes devem ser processados e para onde devem ser encaminhados) e contadores (utilizados para estatsticas ou remoo de fluxos inativos). ii. Canal Seguro: Para que a rede no sofra ataques de elementos mal intencionados, o Secure Channel assegura confiabilidade na troca de informaes entre o switch e o controlador. A interface utilizada para acesso ao trfego o protocolo Secure Socket Layer (SSL). O NOX tambm suporta outras interfaces (passivas ou ativas), TCP e PCAP. Essas so bem teis em ambientes virtuais, pela simplicidade de utilizao, pois no necessitam de chaves criptogrficas. iii. Protocolo OpenFlow: Disponibiliza um protocolo aberto para estabelecer a comunicao entre o switch e o controlador. Ao fornecer uma interface externa que atue sobre os fluxos de um switch, o Protocolo OpenFlow (OFP OpenFlow Protocol) evita a necessidade de um switch programvel.
81
3.1.2. Aplicaes Como visto anteriormente, o OpenFlow permite o experimento de novas propostas na rea de Redes de Computadores, utilizando uma infraestrutura de rede j existente. Dentre os possveis experimentos permitidos, podem ser citados os seguintes [N. MCKEOWN et al. 2008]: Novos Protocolos de Roteamento: Os algoritmos de um protocolo de roteamento podem ser implementados para executarem no controlador de uma rede OpenFlow. Assim, quando um pacote do experimento chegar a um comutador, ele encaminhado para o controlador, que responsvel por escolher a melhor rota para o pacote seguir na rede a partir dos mecanismos do protocolo de roteamento proposto. Aps isso, o controlador adiciona entradas na Tabela de Fluxos de cada comutador pertencente rota escolhida. Os prximos pacotes desse fluxo que forem encaminhados na rede no necessitaro serem enviados para o controlador. Mobilidade: Uma rede OpenFlow pode possuir pontos de acesso sem fio, permitindo que clientes mveis utilizem sua infraestrutura para se conectarem a Servidores ou Internet. Assim, mecanismos de handoff podem ser executados no Controlador realizando alterao dinmica das tabelas de fluxo dos comutadores de acordo com a movimentao do cliente, permitindo a redefinio da rota utilizada. Redes No-IP: Como visto anteriormente, um comutador OpenFlow pode ser desenvolvido para analisar campos arbitrrios de um pacote, permitindo flexibilidade na definio do fluxo. Assim, podem ser testadas, por exemplo, novas formas de endereamento e roteamento. Nos comutadores do tipo 0, os pacotes No-IP podem ser definidos pelo endereo MAC de origem ou destino ou a partir de um novo Tipo de Ethernet ou IP. Redes com Processamento de Pacotes: Existem propostas de protocolos que realizam processamento de cada pacote de um fluxo como, por exemplo, os protocolos de Redes Ativas. Esse tipo de proposta pode ser implementado no OpenFlow forando que cada pacote que um comutador receba seja enviado para o Controlador para ser processado. Outra alternativa enviar esses pacotes para processamento por um comutador programvel, como o caso de um roteador programvel baseado em Net-FPGA [J. LOCKWOOD et al. 2007].
82
3.1.2. Modos de funcionamento dos Switch Existem dois tipos de comutadores OpenFlow. O primeiro consiste em um comutador OpenFlow dedicado, que no suporta encaminhamento comum de Nvel 2 e Nvel 3. O segundo tipo consiste em um comutador ou roteador comercial com OpenFlow habilitado que, alm de suportar as funcionalidades do OpenFlow, realiza as funes comuns de um comutador ou roteador. Esses dois tipos so detalhados abaixo. Comutador OpenFlow Dedicado Esse tipo de comutador, exemplificado na Figura 3.1, um elemento que apenas encaminha o trfego entre as portas do comutador de acordo com a Tabela de Fluxos configurada remotamente, via controlador. O fluxo pode ser definido de diferentes formas. Por exemplo, um fluxo pode ser definido como todos os pacotes provenientes de certa porta TCP ou os pacotes com um determinado endereo MAC de destino. Alm disso, alguns comutadores OpenFlow podem tratar pacotes que no utilizam o IPv4, verificando campos arbitrrios de seu cabealho. Isso mostra a flexibilidade do OpenFlow para suportar diferentes tipos de experimentos.
Figura 3.1 Comutador OpenFlow Dedicado
83
Para cada entrada da Tabela de Fluxos definida uma ao para ser tomada com os pacotes oriundos de um determinado fluxo. As trs aes bsicas que todos Comutadores OpenFlow devem suportar so as seguintes: encaminhar os pacotes do fluxo para uma (ou vrias) porta(s) especfica(s). Isso permite que os pacotes sejam roteados pela rede. encapsular os pacotes e encaminh-los para o Controlador utilizando o Canal Seguro de comunicao. Essa ao pode ser executada no momento do envio do primeiro pacote de um fluxo, que ainda no tenha sido definido nas Tabelas de Fluxo dos comutadores, com o objetivo do Controlador configurar os comutadores com esse novo fluxo. Alm disso, a ao pode ser realizada em um experimento no qual necessrio processamento adicional nos pacotes de um fluxo. descartar o pacote. Essa ao pode ser utilizada em aplicaes de segurana para impedir, por exemplo, ataques de negao de servio. Uma entrada na Tabela de Fluxos possui trs campos, como apresentado na Figura 3.2a. O primeiro identifica o cabealho que define o fluxo. Por exemplo, no cabealho dos comutadores OpenFlow (comutadores tipo 0), um fluxo pode ser definido por 10 parmetros. Esses parmetros podem ser o MAC e IP de origem ou destino, as portas TCP usadas, entre outros como mostra a Figura 3.2b. Em outras geraes de comutadores OpenFlow, esses parmetros podem ser definidos arbitrariamente, permitindo o experimento de protocolos que no utilizam o IP.
Figura 3.2 Cabealhos que definem um fluxo em comutadores tipo 0
84
O segundo campo identifica a ao a ser tomada e o terceiro armazena as estatsticas do fluxo. Essas estatsticas podem ser o nmero de pacotes ou bytes referentes ao fluxo que passaram pelo comutador e o intervalo de tempo desde a ltima vez em que um pacote do fluxo foi identificado pelo comutador. Esse ltimo importante, por exemplo, para remoo de um fluxo da tabela caso esteja inativo. Comutador com OpenFlow Habilitado Esse tipo de comutador consiste nos equipamentos que j realizam encaminhamento normal de Nvel 2 e Nvel 3, mas adicionaram o OpenFlow com uma funcionalidade. Assim, o trfego de produo pode ser encaminhado utilizando o encaminhamento normal e permanece isolado do trfego experimental, que utiliza o mecanismo do OpenFlow. Para isso, esses comutadores podem adicionar outra ao alm das trs aes bsicas citadas anteriormente: encaminhar os pacotes do fluxo pelo pipeline normal do comutador. Nessa ao, um fluxo identificado como no sendo referente ao OpenFlow ser processado utilizando o encaminhamento normal. Como alternativa ao uso da ao anterior, um comutador pode isolar o trfego de produo do trfego OpenFlow atravs do uso de VLANs. Alguns comutadores podem suportar tanto essa alternativa como a outra. 3.1.3. Controlador O NOX [N. Gude et al. 2008] uma proposta de sistema operacional para redes, possuindo como objetivo facilitar o gerenciamento de redes de grande escala. O conceito de sistema operacional de rede pode ser entendido pela analogia com os sistemas operacionais utilizados nos computadores. As ideias bsicas dos sistemas operacionais de computadores so oferecer uma interface de alto nvel para as aplicaes utilizarem os recursos de hardware e tambm controlar a interao entre essas aplicaes. A interface de alto nvel oferecida na primeira ideia tornou os programas mais fceis de serem desenvolvidos e de executarem em diferentes plataformas de hardware. Isso ocorre porque os programadores
85
no precisam mais se preocupar com interaes de baixo nvel da aplicao com o hardware e escrevem seus programas utilizando primitivas genricas que funcionam em diversas arquiteturas. Em redes de computadores, o gerenciamento realizado por configuraes de baixo nvel que depende do conhecimento da rede, anlogo s aplicaes desenvolvidas sem os sistemas operacionais. Como exemplo, o controle de acesso aos usurios de uma rede utilizando uma ACL (Access Control List Lista de Controle de Acesso), necessita do conhecimento do endereo IP do usurio, que um parmetro de baixo nvel dependente da rede. Portanto, existe a necessidade de um sistema operacional de redes que fornea interfaces para controlar e observar uma rede, semelhantes s interfaces de leitura e escrita em diversos recursos oferecidos por um sistema operacional de computador [N. GUDE et al. 2008]. Assim, o sistema operacional de redes dever fornecer uma interface genrica de programao que permite o desenvolvimento de aplicaes de gerenciamento da rede. Esse sistema centraliza o gerenciamento da rede, necessitando haver uma grande preocupao com sua escalabilidade. O NOX um sistema operacional de rede que procura atender os requisitos j citados. Esse sistema foi desenvolvido para ser executado nos controladores de redes OpenFlow. Apesar do objetivo principal do OpenFlow ser o experimento de novas propostas, o NOX pode ser utilizado tambm no gerenciamento de redes de produo. A Figura 3 ilustra os principais componentes de uma rede baseada no NOX. Esse tipo de rede possui um ou mais servidores executando o NOX. Cada um realiza o papel do controlador OpenFlow. Esses controladores possuem aplicaes executando a partir do NOX. Todos os controladores compartilham uma nica viso da rede, que mantida na base de dados de um dos servidores. A viso da rede montada com base em informaes da rede coletadas pelo NOX e usada na tomada de decises pelas aplicaes de gerenciamento. As informaes coletadas podem ser a topologia dos comutadores, a localizao dos elementos da rede (ex. usurios, clientes, middleboxes) e os servios oferecidos (ex. HTTP ou NFS). As aplicaes iro manipular o trfego da rede a partir da configurao remota dos comutadores OpenFlow. Esse controle realizado no nvel de fluxo, ou seja, sempre quando um determinado controle realizado no primeiro pacote de um fluxo todos os outros pacotes desse fluxo sofrero a mesma ao.
86
Figura 3.3 Componentes de uma rede baseada no NOX
O funcionamento da rede baseada no NOX ocorre da seguinte forma: ao receber um pacote, o comutador verifica o cabealho do pacote para ver se ele est definido em sua Tabela de Fluxos. Se estiver definido, o comutador executa a ao especificada na Tabela de Fluxos e atualiza os contadores referentes estatstica do fluxo. Seno, encapsula o pacote e o envia para o NOX. O NOX ento ser responsvel por adicionar uma entrada na Tabela de Fluxos do comutador, identificando o fluxo referente quele pacote. Dependendo da aplicao, o NOX pode no adicionar essa entrada, forando que os comutadores enviem sempre para o NOX os pacotes que receberem. Como exemplo de aplicao que pode ser desenvolvida para o NOX, pode ser citado o gerenciamento de consumo de energia [N. GUDE et al. 2008]. Por exemplo, nesse tipo de gerenciamento, pode ser reduzida a velocidade de enlaces subutilizados ou esses enlaces podem ser simplesmente desligados. Com a Viso da Rede do NOX, na qual conhecida uma viso global da rede e as rotas em uso, pode-se adquirir conhecimento necessrio para realizar tais aes. Alm disso, essas aes podem ser auxiliadas por aplicaes desenvolvidas para o NOX, como
87
reduo de velocidade dos enlaces ou migrao dos fluxos de um comutador que ser desligado para outro comutador em uso. 3.2 Virtualizao A virtualizao uma tcnica que permite que um sistema execute processos oferecendo a cada um deles a iluso de executar sobre recursos dedicados. Inicialmente um mecanismo de isolamento, representa um fator de uso eficiente da crescente capacidade computacional disponvel [EGI et al. 2007] e a integra a arquiteturas nas quais os elementos comuns a um conjunto de processos virtualizados possuem apenas uma cpia em execuo, acessada de forma compartilhada [BHATIA et al. 2008]. O conceito foi estendido do mbito de ns para os demais elementos de uma rede de computadores, dando origem virtualizao de redes [Chowdhury e Boutaba 2010]. Em um processo paralelo quele descrito para a virtualizao tradicional, a aplicao da virtualizao de redes passou a permitir que os componentes de uma rede fsica particionassem sua capacidade de maneira a realizar simultaneamente mltiplas funes, estabelecendo infraestruturas lgicas distintas e mutuamente isoladas. Assim como no caso da virtualizao de sistemas, a virtualizao de redes tambm permitiu que as arquiteturas de redes se tornassem mais eficientes. Funes que tradicionalmente eram gerenciadas de forma distribuda passaram a ser projetadas para uma execuo e administrao centralizadas. o caso do encaminhamento do trfego IP: podem ser encontradas arquiteturas do estado-da-arte [BOLLA et al. 2009] [NASCIMENTO et al. 2010] em que decises de roteamento, originalmente tomadas de forma local por ns especializados, so encaminhados por comutadores a um sistema controlador, que executa em memria uma verso virtualizada da rede e dos respectivos elementos roteadores. Deriva decises da base de informaes de roteamento construda pela execuo desta rede virtual e as transmite aos comutadores, que reagem de acordo. 3.2.1. Virtualizao de Sistemas Uma soluo de virtualizao fornece aos sistemas, executando sob sua superviso, a abstrao de um ambiente computacional exclusivo sobre o qual eles esto operando (n convidado), quando de fato tem-se um computador (anfitrio) cujos recursos foram partilhados entre esses mesmos sistemas.
88
Pode-se realizar a virtualizao de sistemas de duas formas: a virtualizao completa, em que cada convidado executa seu sistema operacional, e a virtualizao baseada em containers, em que o sistema operacional do anfitrio distribui e isola os recursos disponveis entre os sistemas convidados [BHATIA et al. 2008]. Ainda segundo Bhatia [2008], na virtualizao completa, ilustrada na Figura 3.4, o anfitrio executa um Monitor de Mquinas Virtuais MMV, tambm chamado hipervisor. responsabilidade do MMV prover abstrao de hardware (chamada de mquina virtual) para que seja possvel executar o sistema operacional convidado, bem como mapear cada requisio dos convidados a seus respectivos dispositivos virtuais, para o elemento fsico correspondente.
Figura 3.4 Virtualizao Completa
Tambm existe uma variao desta tcnica chamada paravirtualizao, que consiste em otimizar a emulao de hardware provida pelo MMV com vistas a um ganho de desempenho. Nesta abordagem, porm, os sistemas operacionais convidados devem ser modificados para que possam ser executados o que no acontece na virtualizao completa. Em um sistema baseado em containers, apresentado na Figura 3.5, uma imagem de sistema operacional virtualizada compartilhada entre todos os convidados o que pode ser especialmente eficiente em cenrios em que se deseja apenas executar de forma isolada diversas cpias do mesmo software. Ainda assim, os ns virtuais podem ser individualmente gerenciados, tal como na virtualizao completa.
89
Figura 3.5 Virtualizao utilizando container
3.2.1.1 Principais ferramentas de virtualizao de sistemas A virtualizao empregada atravs de ferramentas que apresentam diferenas entre si e possuem suas vantagens e desvantagens. Atualmente, h uma gama enorme de softwares livres e empresas que fornecem solues com esse conceito. Neste captulo, comentaremos apenas as ferramentas Xen e o OpenVz, por serem as mais relevantes no contexto atual, bem como estabeleceremos uma comparao entre estas tecnologias. XEN O Xen um monitor de mquina virtual (VMM ou hypervisor), em software livre, para arquiteturas x86. Originrio de um projeto de pesquisa da Universidade de Cambridge, sua primeira verso foi criada em 2003, quatro anos antes de ser comprada pela Citrix System, em 2007. Ele apresenta uma soluo para virtualizao um pouco diferente das conhecidas. Seu conceito consiste em criar um hypervisor, responsvel por controlar os recursos das mquinas virtuais, mas que no possui drivers de dispositivos. Dessa forma, no possvel rodar um sistema operacional
90
diretamente no hypervisor. Assim, faz-se necessrio que um sistema seja invocado para fazer a comunicao entre o hypervisor e os sistemas hspedes. A Figura 3.6 apresenta uma viso geral do Xen. Esse sistema inicial chama-se domnio 0. Ele consiste em uma mquina virtual que executa um ncleo Linux modificado e possui privilgios para acessar dispositivos de entrada e sada s outras mquinas virtuais, onde podem rodar outros sistemas operacionais, chamados domnio U. Elas so criadas, inicializadas e desligadas atravs do domnio 0. Possuem um driver virtual para acesso aos recursos de hardware.
Figura 3.6 Viso geral do Arquitetura XEN
O domnio 0 possui os drivers dos dispositivos da mquina fsica, alm de dois drivers especiais que tratam as requisies de acesso rede e ao disco enviadas pelas mquinas virtuais. Assim, toda requisio de uso da mquina real feita por uma mquina do domnio U deve ser tratada pelo domnio 0 antes de ser enviada ao hypervisor. Originalmente, o Xen foi desenvolvido com o objetivo de implementar a tcnica de paravirtualizao, e, para isso, era necessrio modificar os sistemas hspedes para dar-lhes a conscincia de rodarem sobre um hypervisor. Essa estratgia foi tomada visando ganhos em desempenho, mas limitou a difuso do Xen aos sistemas Unix, de cdigo aberto.
91
OPENVZ O OpenVZ uma soluo de virtualizao em nvel de sistema operacional. Cria ambientes virtuais isolados, que funcionam como servidores convencionais, porm, utilizando um nico hardware em comum. Estes ambientes virtuais seguros so conhecidos como VE (Virtual Environment) ou como VPS (virtual private server). VPSs podem ser reinicializados independentes uns dos outros. Todos possuem hostname, acesso de root, endereo IP e tudo mais que um servidor pode ter, sendo assim uma soluo extremamente confivel e funcional de virtualizao. As capacidades bsicas dos VPSs so: Dynamic Real-time Partitioning: Partio de um nico servidor fsico em dezenas de VPSs, cada um com funcionalidade total. Resource Management: Atribuio e controle dos recursos dos VPSs. Realocao de recursos em tempo real. Mass Management: Gerenciamento unificado de uma grande quantidade de servidores fsicos e virtuais (VPSs).
Figura 3.7 Arquitetura de virtualizao utilizada pelo OpenVZ
92
Como pode ser visto na Figura 3.7, um servidor fsico pode conter diversos VPSs (Virtual Private Servers). Cada VPS possui isolamento total uns dos outros, inclusive com uma viso nica de seus Ambientes Virtuais (VEs). O OpenVZ prov uma soluo para Provedor de Servios de Hospedagem possibilitando que: centenas de usurios possuam seus prprios servidores privados (Virtual Private Servers) compartilhando um nico servidor fsico; prov para cada usurio uma garantia de qualidade de servio; transferncia transparente dos ambientes virtuais dos usurios para outros servidores fsicos, sem nenhum tipo de reconfigurao manual. que: O Virtual Private Server se comporta como um nico servidor, em cada VPS possui seus prprios processos, usurios e prov acesso completo de root via shell; cada VPS possui seu prprio endereo IP, nmero de portas, firewall e roteamento; cada VPS possui seus prprios arquivos de configurao para o sistema e aplicaes, como tambm suas prprias bibliotecas de sistema. 3.2.3. Virtualizao de redes Assim como a virtualizao prov o compartilhamento de recursos de um n computacional por mltiplos sistemas, a virtualizao de redes (VR) um mtodo para que mltiplas arquiteturas de rede heterogneas compartilhem o mesmo substrato fsico neste caso, componentes de uma rede como roteadores, comutadores, etc. Segundo Chowdhury and Boutaba [2010], existem quatro abordagens para a implementao de VR: as Redes Locais Virtuais (VLANs), as Redes Privadas Virtuais (VPNs) e as redes de sobreposio (Overlay). Em Sherwood [2010], apresenta-se uma quarta, a partir do conceito de redes programveis.
93
Redes Locais Virtuais (VLANs) Uma VLAN um agrupamento lgico de dispositivos ou usurios que podem ser unidos por funo, departamento ou aplicativo, independentemente da localizao de seus segmentos fsicos. A configurao de VLANs feita no switch, e possivelmente no roteador, atravs de software proprietrio do fabricante. Com efeito, numa rede local a comunicao entre as diferentes mquinas governada pela arquitetura fsica. Graas s redes virtuais (VLANs), possvel livrar-se das limitaes da arquitetura fsica (constrangimentos geogrficos, restries de endereamento, etc.), definindo uma segmentao lgica (software), baseada num agrupamento de mquinas com critrios como endereos MAC, nmeros de porta ou protocolo. Foram definidos vrios tipos de VLAN, de acordo com o critrio de comutao e o nvel em que se efetua: VLAN de nvel 1 (Port-Based VLAN) define uma rede virtual em funo das portas de conexo no comutador; VLAN de nvel 2 (MAC Address-Based VLAN) consiste em definir uma rede virtual em funo dos endereos MAC das estaes; e VLAN de nvel 3 distinguem-se vrios tipos de VLAN de nvel 3: VLAN por sub-rede (Network Address-Based VLAN), que associa sub-rede de acordo com o endereo IP fonte dos datagramas e VLAN por protocolo (em ingls Protocol-Based VLAN) que permite criar uma rede virtual por tipo de protocolo (por exemplo TCP/ IP, IPX, AppleTalk, etc.), agrupando assim todas as mquinas que utilizam o mesmo protocolo numa mesma rede. A VLAN permite definir uma nova rede acima da rede fsica e a esse respeito oferece mais flexibilidade para a administrao e modificaes da rede porque qualquer arquitetura pode ser alterada por simples parametrizao dos comutadores. E ainda, um ganho em segurana, porque as informaes so encapsuladas em um nvel suplementar e so eventualmente analisadas. A VLAN oferece tambm reduo da divulgao do trfego sobre a rede.
94
Redes Privadas Virtuais (VPNs) A ideia de utilizar uma rede pblica como a Internet em vez de linhas privativas para implementar redes corporativas denominada de Virtual Private Network (VPN) ou Rede Privada Virtual. As VPNs so tneis de criptografia entre pontos autorizados, criados atravs da Internet ou outras redes pblicas e/ou privadas para transferncia de informaes, de modo seguro, entre redes corporativas ou usurios remotos. A segurana a primeira e mais importante funo da VPN. Uma vez que dados privados sero transmitidos pela Internet, que um meio de transmisso inseguro, eles devem ser protegidos de forma a no permitir que sejam modificados ou interceptados. Outro servio oferecido pelas VPNs a conexo entre corporaes (Extranets) atravs da Internet, alm de possibilitar conexes dial-up criptografadas que podem ser muito teis para usurios mveis ou remotos, bem como filiais distantes de uma empresa. Uma das grandes vantagens decorrentes do uso das VPNs a reduo de custos com comunicaes corporativas, pois elimina a necessidade de links dedicados de longa distncia que podem ser substitudos pela Internet. As LANs podem, atravs de links dedicados ou discados, se conectarem a algum provedor de acesso local e interligarem-se a outras LANs, possibilitando o fluxo de dados atravs da Internet. Esta soluo pode ser bastante interessante sob o ponto de vista econmico, sobretudo nos casos em que enlaces internacionais ou nacionais de longa distncia esto envolvidos. Outro fator que simplifica a operacionalizao da WAN que a conexo LAN-Internet-LAN fica parcialmente a cargo dos provedores de acesso. Redes de Sobreposio (Overlay) Uma rede Overlay uma rede virtual que cria uma topologia virtual no topo da topologia fsica de outras redes. Os ns em uma rede de sobreposio so unidos por meio de ligaes virtuais que correspondem em caminhos na rede subjacente. As redes de sobreposio so tipicamente programadas na camada de aplicao, embora vrias implementaes nas camadas inferiores da pilha de redes o faa existir. As redes Overlay no so restritas geograficamente e so bastante flexveis e adaptveis a mudanas, se comparadas a qualquer outra rede. Como resultado, as redes sobrepostas tm sido usadas para implantar novos recursos e correes na Internet.
95
Figura 3.7 Modelo de rede de sobreposio
Uma infinidade de modelos de sobreposio tem sido proposta nos ltimos anos para tratar questes adversas que incluem: desempenho assegurado [SAVAGE,1999], disponibilidade de roteamento na internet [ANDERSEN, 2001], multicast [JANNOTTI, 2000][CHU, 2001], garantias de qualidade de servio [SUBRAMANIAN, 2004], ataque de negao de servios [ANDERSON, 2003], distribuio de contedo [KRISHNAMURTHY, 2001], compartilhamento de arquivos [LUA, 2005] e at sistemas de armazenamento [DABEK, 2001]. Overlay tambm est sendo usada como testbed, por exemplo PlanetLab [PETERSON, 2009], Federica [CAMPANELLA, 2009] e o GENI [GENI, 2011] para desenvolvimento e avaliao de novas arquiteturas. 3.2.4. Virtualizao de Rede com OpenFlow Similar virtualizao de computadores, a virtualizao de redes promete melhorar a alocao de recursos, permitir que seus operadores possam checar suas redes antes de eventuais mudanas e tambm que clientes compartilhem o mesmo equipamento de forma controlada e isolada. Portanto, analogamente, a rede em si deve ter uma camada de abstrao de hardware, similar ao que acontece na virtualizao de computadores. Esta camada deve ser facilmente fativel, para
96
que mltiplas redes completamente diferentes possam ser executadas simultaneamente em cima, sem interferir uns aos outros, sobre uma variedade de hardwares diferentes abaixo, incluindo switches, roteadores, pontos de acesso e assim por diante. Ou seja, acima desta camada de abstrao de hardware, tm-se novos protocolos e formatos de endereamento rodando independentemente de sua prpria fatia, uma mesma rede fsica, e na parte de baixo da camada de virtualizao, novos hardwares, podendo ser desenvolvidos para diferentes ambientes e diferentes velocidades, mdia (com fio e sem fio) e energia. De acordo com Rob [2010a], a camada de abstrao de hardware provida pelo OpenFlow e como camada de virtualizao se tem FlowVisor. Similar virtualizao de computadores, o FlowVisor uma cada de virtualizao que reside entre o hardware e o software dos componentes da arquitetura, conforme ilustrado na Figura 3.8. Portanto, a integrao FlowVisor e OpenFlow permite que em uma rede OpenFlow possam ser criadas vrias fatias de recursos de redes rodando simultaneamente e isoladamente.
Figura 3.8 Comparao entre o FlowVisor como camada de virtualizao com a virtualizao computacional [Sherwood, 2009]
O FlowVisor um controlador especializado que atua como um proxy transparente entre os switches de uma rede OpenFlow e seus mltiplos controladores. Todas as mensagens do protocolo OpenFlow tanto aquelas originrias dos switches para os controladores quanto as dos controladores para os switches, so interceptadas atravs do FlowVisor. Desse modo, os controladores no necessitam de modificaes e, devido interceptao transparente do FlowVisor, os mesmos acreditam estar se comunicando diretamente com os dispositivos da rede que constitui o plano de dados [ROB, 2010b].
97
Devido existncia da interface entre os planos de dados e o de controle, a tcnica empregada permite a partio do plano de dados em fatias (ou slices) que esto sob a gerncia do FlowVisor [SHERWOOD, 2009]. Cada slice est vinculado a um controlador. O FlowVisor define um slice como um conjunto de fluxos tambm chamado de espao de fluxo (ou flowspace). Devido verso atual do protocolo OpenFlow permitir a definio de um fluxo como uma combinao de dez campos do cabealho de pacote incluindo informaes das camadas fsica, de enlace, de rede e de transporte, o FlowVisor possibilita que se implemente slices com um elevado nvel de granularidade, no que diz respeito caracterizao do flowspace [ROB, 2010a]. Alm disso, os slices podem ser definidos por aes de negao, unio e interseco. A Figura 3.9 ilustra o particionamento da rede em slices por meio do FlowVisor. Nesta figura, alm do slice da rede de produo, tm-se mais dois slices identificados por Alice e Bob. Os crculos enumerados em ordem crescente indicam a dinmica de execuo durante o processamento das mensagens interceptadas pelo FlowVisor. Inicialmente, o FlowVisor intercepta as mensagens provenientes de um determinado controlador convidado no ambiente de controle (1). Utilizando a poltica do espao de fluxos definida para aquele slice (2), o FlowVisor reescreve a mensagem do controlador transparentemente para o slice da rede que compe o plano de dados (3). As mensagens originrias dos switches para o plano de controle (4), por sua vez, so novamente interceptadas pelo FlowVisor e reescritas para o respectivo controlador de acordo com a poltica que define o espao de fluxos.
98
Figura 3.9 Gerenciamento de slices por meio do FlowVisor. [Sherwood, 2009]
O particionamento da rede possibilita que as aes desenvolvidas em um de seus slices no interfiram negativamente nos demais, mesmo que estes estejam compartilhando a mesma infraestrutura fsica. Em arquiteturas mais tradicionais, a rede fatiada atravs da tcnica de VLAN (Virtual Local Area Network), porm, com a granularidade das redes, a estrutura de VLANs torna os experimentos, como IP Mobility ou Wireless Handover, por exemplo, bastante difceis de gerenciar. As caractersticas inerentes ao FlowVisor, como a virtualizao transparente, o forte isolamento entre os slices e a sua rica poltica de definio de flowspaces tornam mesmo uma ferramenta extremamente eficiente no que diz respeito virtualizao e implementao de redes programveis orientadas a software. 4. Requisitos para construo de um ambiente para experimento e virtualizao de redes Iniciativas [FIRE, 2010][GENI, 2011][AKARI, 2009] vm construindo infraestruturas para testar novos protocolos, servios e aplicaes em ambientes de larga escala, visando solucionar esses desafios da Internet atual e compor a arquitetura da chamada Internet do Futuro. Por essas razes, definir estratgias corretas para construo e operao destes testbeds para Internet do Futuro considerado uma etapa
99
vital. Alm disso, o ambiente deve combinar flexibilidade a um conjunto mnimo de restries e um completo controle do ambiente para seus pesquisadores [YOUNG et. al, 2009]. Deste modo, o OpenFlow vem se destacando como framework capaz de habilitar experimentos de novas tecnologias utilizando redes reais de produo. Nesta mesma linha, a virtualizao vem como uma ferramenta essencial, para permitir o acesso compartilhado de recursos, seja de rede ou computacional. Portanto nesta seo, observam-se as informaes importantes para construo de um testbed, levando em considerao a utilizao de OpenFlow e virtualizao. Verificam-se o modo que se descrevem, os hardwares utilizados dentro desta infraestrutura, tipos de enlaces, software de virtualizao e ferramentas para anlise de trfegos e gerao de trfego.
4.1. Tipos de Hardwares Para construo do testbed, so necessrios principalmente hardwares que suportem virtualizao e OpenFlow. Para isso, so necessrios dispositivos especiais para que o desempenho da rede virtual no tenha uma influncia nos experimentos realizados e possibilite sua otimizao de forma programvel. Entre esses dispositivos esto interfaces de redes programveis e switches programveis com OpenFlow habilitado. Interface de Rede Programvel O NetFPGA [LOCKWOOD, 2007][BILAL, 2009] uma plataforma aberta que permite estudantes e pesquisadores desenvolverem prottipos de sistemas de redes em alta velocidade e sistemas de acelerao de redes via hardware, alm de prottipos de switches ou roteadores IP para Internet do Futuro. A NetFPGA consiste em uma placa de desenvolvimento reconfigurvel, interface de ligao ao PC, utilizando PCI e PCI-e, dois processadores PowerPC, SDK para o desenvolvimento de novas funcionalidades, um troughput que varia de 8Gbps at 80 Gbps, dependendo da verso da placa, e quatro interfaces de 1 Gbps ethernet RJ-45 ou quatro interfaces 10 Gbps ethernet SFP+. A Figura 4.1 ilustra as duas verses de placas NetFPGA, modelos de 1 (Figura 4.1a) e 10 Gbps (Figura 4.1b). Alm disso, totalmente compatvel com Linux e OpenFlow.
100
(a) NetFPGA 4x1 Gbps PCI
(b) NetFPGA 4x10 Gbps PCI-e
Figura 4.1 Modelos de NetFPGA disponveis
Switches Programveis O OpenFlow um framework que permite o gerenciamento da tabela de encaminhamento de switches Ethernet, desacoplando a lgica de controle do equipamento do hardware de encaminhamento de pacotes, baseado no conceito chamado de Software-Defined Networking (SDN) [GREENE, 2009]. Esta separao no s permite um modelo de inovao aberta tanto no plano de controle quanto no plano de encaminhamento, mas tambm permite a virtualizao do plano de encaminhamento em fatias ou redes lgicas. Deste modo, so necessrios equipamentos que possuam o OpenFlow habilitado. No entanto, o protocolo Openflow ainda est em fase de padronizao nos switches e alguns fabricantes j disponibilizam verses de switches com OpenFlow habilitado, como o caso dos modelos Pronto 3290 para solues at 1GbE e o Pronto 3790 para 10 GbE e SFP+. Tambm h o projeto Indigo [INDIGO, 2011] que uma implementao aberta do OpenFlow que permite rodar sobre switches fsicos baseados em chipsets Broadcom. A cada switch suportado desenvolvido um firmware para essa linha de produto. Este firmware sobrescreve o original do switch, instalando a nova imagem com OpenFlow habilitado. Dentre os switches compatveis, temos, alm dos modelos da linha Pronto, os modelos Netgear GSM7328 (24 x 1 GbE) e GSM7352 (48 x 10 GbE). Servidores de alto desempenho Os servidores tambm so uma parte importante dentro do substrato, pois deles so virtualizados recursos como: CPU, armazenamento e I/O. Para isso, so necessrios servidores de alto poder computacional
101
para que no haja perda de desempenho no nvel virtualizado e suporte a quantidade de usurios locais e tambm os federados. Observando esses requisitos, as linhas de servidores do tipo BLADE surgem como uma excelente soluo para oferecer esse poder computacional. Blade uma nova forma de tecnologia computacional que permite a alta densidade de componentes e recursos incluindo servidores, armazenamento e interfaces de comunicao integradas em um mesmo chassi. A vantagem do uso de servidores blades a possibilidade do crescimento incremental mediante a demanda de usurios, devido a sua caracterstica modular, baseada em contineres de servidores, switches e armazenamento. O seu poder computacional pode ser incrementado com introduo de novas lminas blades, que so servidores que inseridos no chassi com recurso de processamento e memria. Alm disso, outra vantagem a sua otimizao para uso de virtualizao com barramento em altssimas taxas de velocidade e implementao de grupos de recursos dentro de conjunto virtualizado. O uso de blades est ligado principalmente a virtualizao de servidores e a computao em nuvem. 4.2. Arcabouos de Controle Os arcabouos de controle o corao de qualquer infraestrutura de experimentao baseada em virtualizao. Porm, muitos arcabouos so limitados a tipo de recurso e a um tipo de comunidade de pesquisa. Com base nisso, so apresentados alguns frameworks de controle que devem ser selecionados de acordo com o tipo de infraestrutura que se est oferecendo: ProtoGENI O ProtoGENI [PROTOGENI, 2011] atualmente dirigido pela Universidade de Utah. um framework que pretende controlar a integrao em larga escala de infraestruturas existentes e em construo no GENI. Esses testbeds so compostos principalmente por elementos embarcados e programveis no backbone, PCs com hardwares programveis e uma variedade de redes sem fio, redes de acesso e clusters programveis. Atualmente, o ProtoGENI est usando RSpec para descrever seus ns, enlaces e interfaces. Esses recursos so mapeados para o Emulab que aplica os mapas virtuais de recursos em ns locais e vlans.
102
FEDERICA O FEDERICA [SEZGEDI et. al, 2009] uma iniciativa composta de roteadores, switches e computadores para experimentaes em Internet do Futuro. Ele baseado em redes de Ensino & Pesquisa (NRENs National Research and Education Network) e no backbone da GEANT2. O Arcabouo FEDERICA capaz de alocar recursos para mltiplos slices e diferentes redes a serem utilizadas pelos pesquisadores que possuem o controle completo dos recursos de seu slice. Ele composto de pequenas ferramentas e outros recursos de instrumentao que vo desde a gerncia e controle de mquinas virtuais alocao de circuito fim a fim camada 2, camada 1 ou MPLS. ORCA O ORCA [ORCA, 2011] [BEN, 2011] framework de cdigo fonte aberto, utilizado para gerenciar e controlar a programabilidade de substratos (hardware) compartilhados, que podem incluir, servidores, storages, redes e outros componentes. O ORCA foi desenvolvido como um prottipo arcabouo GENI. No ORCA, h uma coleo dinmica de controladores de interao que trabalham juntas para o provisionamento e configurao de recursos para os slices requisitados pelos seus usurios de acordo com as polticas dos participantes. Atualmente, o ORCA est sendo estendido para incluir recursos pticos disponveis em metro-scale optical testbed na internet2. Tambm est em processo de integrao a seleo para utilizao de prottipos para redes de sensores e sem fio, de modo que o ORCA oferea a maior variedade de testbeds possveis. PII O objetivo do projeto PII [RAJ JAIN et. al, 2011] criar uma federao de instalaes experimentais entre diferentes plos de inovao regional na Europa. Isso permite que as empresas participantes possam testar novos servios de comunicao e aplicaes na Europa como um todo. O framework tambm ter como esforo integrar federados testbeds distribudos em laboratrios de redes espalhados pela Europa provendo um
103
realstico ambiente de teste para novos conceitos de servios, tecnologias de rede e modelos de negcios. Os mecanismos de seu framework incluem regras e procedimentos para alcanar nveis de teste e colaborao dentro dessas federaes de infraestruturas dentro da Europa. 4.3. Monitorao e Medio Medio e monitoramento so atividades que determinam o estado operacional da infraestrutura ou testbed que est sendo observada, de modo que se possa analisar informaes como: os desempenhos dos recursos disponveis no testbed, verificar a sua disponibilidade do recurso ou componente e medir as caractersticas dos componentes ou da rede que esto sendo disponibilizadas. O objetivo disso oferecer a outros sistemas uma viso dos recursos da infraestrutura, para auxiliar decises como: a possibilidade de alocao de recurso, bem como sua escolha e disponibilizao. Portando, dentro dos requisitos para construo dessas infraestruturas de testbed, esses elementos so essenciais. A seguir, so apresentados alguns softwares relacionados a caractersticas de medio e monitoramento. PerfSONAR O perfSONAR (PERFormance Service Oriented Network Monitoring Architecture) uma arquitetura orientada a servios (SOA) que foi projetada para o monitoramento de redes em ambientes interdomnios. No perfSONAR, existe um conjunto de servios bem definidos que realizam ou disponibilizam resultados de medies de desempenho em um ambiente federado. Esses servios atuam como uma camada intermediria entre as ferramentas de medies e as ferramentas de visualizao [TIERNEY, 2009]. Alm disso, o perfSONAR tambm definiu um protocolo comum entre os servios para permitir que sejam criados novos servios seguindo a padronizao deste protocolo, dando flexibilidade arquitetura. Tambm, criou-se uma representao unificada para definir, armazenar e arquivar os dados relativos s medidas do experimento que mais um componente chave, de modo que certo nvel de concordncia necessrio para fazer convergir esforos e melhorar a experincia, fidelidade e usabilidade das infraestruturas de experimentao em escala global.
104
Real-Time Unified Measurement Framework O UMF (Unifed Measurament Framework) um framework desenvolvido para oferecer capacidade de medies em tempo real a avaliaes de desempenho sobre vrios cenrios de infraestrutura, interfaces de integrao dos recursos de medio com os substratos e os framewoks de controle dos prottipos de GENI e outros sistemas que necessitem de suas medidas e a monitorao das condies dos recursos de um slice durante um experimento [UMF, 2011]. Inicialmente, o UMF est sendo desenvolvido para alimentar informaes dos demais arcabouos de controle do GENI e de visualizao dos usurios pesquisadores. Na Figura 4.2, mostra o esquema de interao dos frameworks com o UMF.
Figura 4.2 Esquema de interao do UMF com outros frameworks do GENI
UMF um arcabouo genrico para gerenciamento de testbed e coleta de mtricas de experimentos. Quando o experimento est sendo executado, os dados so medidos e coletados de acordo com a descrio do usurio. Pontos de medio so definidos dentro de uma aplicao C/C++ ou automaticamente, baseados em arquivos de configurao XML. Os dados medidos so transmitidos usando codificao XDR e salvos em um banco de dados para anlise posterior. Um novo banco de
105
dados de medio criado para cada experimento. O SQLite pode ser usado para manipular os dados ou estes podem ser exportados para gerao de grficos ou tabelas. No UMF, h medidores de desempenho (Performance Monitors) para os mais variados tipos de substratos fsicos, como: unidades externas de hardware, por exemplo, servidores com capacidade de armazenamento (storages), interface de ethernet NetFPGA (10G - NetFPGA). Outras interfaces ethernet seriam GPIB e wireless, e protocolos padres para medio como TL1, SNMP e NetConf. PS-Performance Toolkit O pS-NPToolkit [Ps-Performance, 2011] uma coleo de ferramentas de medida de desempenho de redes. Foi desenvolvida para coletar, armazenar e analisar o desempenho da rede. Esse toolkit usado parte para criar uma completa anlise em um determinado n, bem como para fazer o monitoramento peridico na infraestrutura do testbed. Alm disso, essas ferramentas podem ajudar a identificar mudanas de desempenhos na rede ou pontos que necessitam de uma atualizao em suas polticas para manter o desempenho esperado. BWCTL O BWCTL [HU, 2010] uma aplicao cliente/servidor que permite o agendamento de testes com polticas de medidas utilizando IPERF [MAZHAR, 2008], THRULAY [Shalunov, 2011] e NUTTCP [Fink, 2011]. Estes testes podem medir, por exemplo, a mxima largura de banda para TCP ou testes UDP para medir o atraso, a variao do atraso ou nvel de perda de datagrama na rede. BWCTL tem sido utilizado para testar as qualidades das reservas de circuitos. Neste caso, o seu cliente solicita e agenda um circuito, verifica se foi criado ou no, e caso seja criado, ele verifica se os desempenhos solicitados esto realmente disponveis. 4.4. Ferramentas para Gerncia de Virtualizao As ferramentas de gerncia so essenciais no desenvolvimento dos ambientes de experimentao, pois elas tm o papel de manipular, criar,
106
configurar e remover recursos em testbed. Portanto, abaixo, so apresentadas as principais ferramentas para gerenciamento de virtualizao, computao em nuvem e manipulao de slices.
LIBVIRT A LIBVIRT [WU, 2010] existe como um conjunto de APIs projetadas para serem usadas como um aplicativo de gerenciamento. Por meio de um mecanismo especfico de hypervisores, a LIBVIRT comunica-se com um hypervisor disponvel para executar as solicitaes da API. Deste modo, a LIBVIRT prov uma comum genrica e estvel camada para gerenciamento. A API pode acessar esse hypervisor permitindo o provisionamento, criao, modificao, controle, monitoramento, migrao e inicializao e paralisao de VM (virtual machine). No entanto, o suporte a todas essas operaes ir depender da tecnologia de virtualizao utilizada. Com a LIBVIRT, tm-se dois meios de controle distintos. O primeiro demonstrado na Figura 4.3, no lado esquerdo, em que o aplicativo de gerenciamento e os domnios existem no mesmo n. Nesse caso, o aplicativo de gerenciamento trabalha por meio da biblioteca libvirt para controlar os domnios locais. Outros meios de controle existente so quando o aplicativo de gerenciamento e os domnios esto em ns separados, que demostrado na Figura 4.3, lado direito. Este modo usa um daemon especial chamado libvirtd, que executado em ns remotos. Tal daemon iniciado automaticamente quando a libvirt instalada em um novo n e pode determinar, de forma automtica, os hypervisores locais e configurar drivers para eles. O aplicativo de gerenciamento se comunica por meio da libvirt local com o libvirt remoto atravs de um protocolo customizado [BOLTE, 2010].
107
Figura 4.3 Modos de controle de hypervisor [Wu, 2010]
A API LIBVIRT foi construda para trabalhar atravs de mltiplos ambientes de virtualizao. Dentre as tecnologias de virtualizao temos: QEMU, LXC, OpenVZ, User Mode Linux, KVM, VirtualBox e VMWare. Alm disso, tambm consegue gerenciar as seguintes tecnologias de armazenamento: Storage IDE/SCSI/USB, FiberChannel, LVM, iSCSI e NFS. Eucalyptus Eucalyptus [Nurmi, 2009] framework aberto para montagem e gerncia de ambientes de computao em nuvem utilizando virtualizao sendo o seu foco para pesquisa acadmica. Ele prov uma implementao baseada em IaaS (Infraestructure as a Service), ou seja, infraestrutura como recurso nuvem. Os usurios do Eucalyptus so capazes de iniciar, controlar, acessar e terminar mquinas virtuais (VMs). A atual verso do Eucalyptus suporta VMs, rodando sobre uma XEN hypervisor, mas h planos de utilizar KVM/QEMU e VMWare. O projeto Eucalyptus apresenta quatro caractersticas que o diferenciam de outras solues de computao em nuvem e virtualizao: o Eucalyptus foi projetado para ser simples, de modo que no h a obrigatoriedade da dedicao de recursos; o framework foi projetado para encorajar extenses de softwares de terceiros; possui uma interface externa que baseada na Amazon API EC2; e o Eucalyptus prov uma rede sobreposta virtual que isola o trfego de rede de diferentes usurios, permitindo que clusters remotos paream partes da mesma rede local.
108
A gerncia do Eucalyptus toda baseada em WebService que oferece alguns benefcios arquitetura como a exposio da API em forma bem conhecida e funcional como o WSDL (Web Service Description Language), definindo tanto as suas operaes aos quais seus servios podem desempenhar quanto as estruturas de dados de entrada e sada utilizadas. A arquitetura define trs nveis de gerenciamento da infraestrutura de nuvem: Instace Manager (IM): Controla a execuo, inspeo e finalizao das instncias de VMs nos hospedeiros que esto rodando. Group Manager (GM): Suas funcionalidades so as seguintes: escalonamento e gerenciamento de execuo de operaes sobre os IM, controle de operaes sobre a rede virtual sobreposta e reportar informaes sobre um conjunto de IMs. Cloud Manager (CM): Interage com os usurios e gerenciadores reportando informaes a respeito dos estados dos recursos da nuvem. O Eucalyptus flexvel e pode ser instalado em uma mnima infraestrutura (no mnimo duas mquinas), como tambm em milhares de ncleos e terabytes de armazenamento. Tudo totalmente integrado sobre uma rede sobreposta de interligao das infraestruturas de nuvem. E-GENI O Enterprise-GENI [E-GENI, 2011] uma arquitetura/framework utilizada para gerenciar o uso de slice em uma infraestrutura baseada em OpenFlow e FlowVisor. O objetivo do framework criar uma interface para visualizao e gerncias de mltiplos experimentos em rede OpenFlow. A Figura 4.4 mostra como est definida a arquitetura do E-GENI.
109
Figura 4.4 Arquitetura do E-GENI [E-Geni, 2011]
A arquitetura do E-GENI dividida em trs partes: OpenFlow-Based Substrate: Composto de switches que se comunicam utilizando o protocolo OpenFlow para uma aplicao do controlador. FlowVisor: Customizado para controlar slice de rede pelo isolamento e controle de trfego de experimentos individuais. Aggregate Manager: Uma aplicao integra o clearinghouse, responsvel pela manipulao dos experimentos, ao E-GENI FlowVisor utilizando o protocolo SOAP, baseado no GENILight Protocol. O E-GENI vem sendo desenvolvido para integrar redes do tipo OpenFlow ao framework GENI como mais uma alternativa de experimento dentro da infraestrutura de testbed para Internet do Futuro da GENI.
110
5. Estudo de Caso Com o propsito de criao de ambientes experimentais em Internet do Futuro, a comunidade acadmica vem orientando esforos considerveis na criao de testbeds baseados em redes programveis. Baseada em trfegos reais de usurios, a criao de testbeds programveis permite uma abordagem mais realstica com relao escalabilidade da rede e seu comportamento interativo. Por outro lado, a construo e manuteno destes ambientes possui custos elevados e a realizao de testes de novos protocolos, por exemplo, pode ser bastante dispendiosa e gerar muitos problemas devido a sua interferncia no trfego de produo. De maneira complementar a esta abordagem com testbeds, este estudo de caso tem por objetivo demonstrar como possvel implementar uma rpida prototipagem de protocolos de rede que seja facilmente aplicvel a redes reais. Ou seja, por meio de um ambiente local, possvel implementar uma funcionalidade que possa ser imediatamente aplicada para testes num ambiente global possibilitando uma maior inovao em redes programveis. Como importante proposta no contexto de redes programveis, neste estudo de caso utiliza-se do framework OpenFlow devido possibilidade de criao de uma infraestrutura de experimentao sobre uma rede de produo. Alm disso, por meio da utilizao do OpenFlow associado virtualizao, demonstra-se como possvel criar, utilizar e gerenciar vrios slices sobre uma infraestrutura de rede compartilhada, possibilitando que vrios experimentos de protocolos possam ser executados de maneira simultnea. Por meio deste estudo de caso demonstra-se que se pode implementar uma nova funcionalidade, ou mesmo uma nova arquitetura de rede em ambientes locais baseados em software. Estas funcionalidades podem ento ser testadas por seus usurios por meio de largas topologias e com trfegos especficos. Posteriormente, os mesmos cdigos que implementam estas funcionalidades podem ser empregados em ambientes de testbeds reais. 5.1. Definio do Ambiente Para exemplificar a utilizao do OpenFlow associado virtualizao, esse estudo de caso tem como principal objetivo apresentar como se pode desenvolver um ambiente capaz de suportar simultaneamente vrios experimentos de protocolos compartilhando a mesma infraestrutura fsica.
111
5.1.1. Dados de Implementao do Ambiente O estudo de caso formado por um laboratrio virtualizado que implementa o plano de controle e o plano de dados baseados em uma rede programvel. Com o objetivo de implementar um ambiente com suporte ao framework OpenFlow, utiliza-se dois servidores: um com Xen Server para criar os controladores virtualizados que sero utilizados nos experimentos e outro servidor utilizando apenas o sistema operacional Linux e o software Mininet. O Mininet utiliza virtualizao baseada em contineres para criar uma instncia virtual de cada switch (ou host) que seja utilizado no experimento. Alm disso, utiliza-se um switch SummitX150 para fazer a ligao entre o plano de controle e plano de dados de maneira fora da banda. A Figura 5.1 ilustra o ambiente que foi desenvolvido para realizao dos testes.
Figura 5.1 Ambiente de teste do estudo de caso
112
A Tabela 5.2 apresenta as configuraes dos servidores utilizados nos estudos de caso.
Tabela 5.1 Dados dos servidores
Dados Sistema Operacional Memria Interface de Rede 1GbE Armazenamento Virtualizao Servidor MiniNet Debian Lenny 5.0 4096 MB 2 320 GB SAS Continer Servidor de Controladores NOX Citrix XenServer 5.6 2048 MB 2 500 GB SATA XEN
No servidor de controladores virtuais tm-se trs VMs responsveis por conter cada servidor controlador NOX. Estes controladores gerenciam os slices criados no plano de dados da infraestrutura do estudo de caso. Cada controlador se comunica com FlowVisor usando 3-tuplas de informaes: VLAN, IP e porta TCP do processo. Com o objetivo de isolar o trfego de cada controlador para eventuais anlises do comportamento das informaes de controle entre os dois, as ligaes entre o controlador e o FlowVisor so divididas por VLAN. A Tabela 5.2 contm um resumo dos dados de configurao de cada VM contendo os controladores.
Tabela 5.2 Configuraes das VMs com os Controladores NOX
Dados Sistema Operacional Memria Interface de Rede 1GbE Endereamento IP VLAN Software Controlador Porta de Conexo Armazenamento Aplicao VM 1 Debian Lenny 5.0 512 MB 1 192.168.100.1 100 NOX 0.5 1515 4 GB Switch VM 2 Debian Lenny 5.0 512 MB 1 192.168.200.1 200 NOX 0.5 1516 4 GB Switch e SpanningTree VM3 Debian Lenny 5.0 512 MB 1 192.168.300.1 300 NOX 0.5 1517 4 GB Switch e Routing
No Servidor Mininet, tm-se dois ambientes distintos virtualizados. O primeiro contm o aplicativo Mininet virtualizando a infraestrutura fsica de switches e hosts, ou seja, ele responsvel pela
113
criao do plano de dados. No segundo ambiente tem-se o FlowVisor como o software que realiza a criao, remoo e gerncia dos slices no plano de dados do Mininet. Assim, todos switches se comunicam ao FlowVisor utilizando endereamento IP e porta TCP. A Tabela 5.3 resume as configuraes do servidor Mininet.
Tabela 5.3 Dados do servidor MiniNet
Dados Sistema Operacional Memria Interface de Rede 1GbE Armazenamento Virtualizao de Rede Virtualizao Porta FlowVisor Servidor MiniNet Debian Lenny 5.0 4096 MB 2 320 GB SAS FlowVisor 0.6 Continer Virtuais LXC 6633
Mesmo considerando a infraestrutura de switches Openflow como virtualizada, os procedimentos aqui executados so compatveis com aqueles realizados em ambientes reais. Portanto, as aplicaes utilizadas no plano de controle neste estudo de caso so aplicveis em uma rede com switches ou roteadores com protocolo Openflow habilitado. Desse modo, o ambiente desenvolvido aqui serve como um ponto de partida no desenvolvimento de uma nova soluo que depois pode ser aplicado em um ambiente Openflow real. 5.1.2. Plano de dados Para construo do plano de dados, o software Mininet utiliza um script que contm a descrio de ns (switches ou roteadores) e hosts (clientes) que so criados por meio de sua API. Alm disso, por meio deste script possvel definir a topologia da rede a ser utilizada. Neste estudo de caso, utiliza-se a topologia representada pela Figura 5.2. O script desenvolvido chamado shortCourse_topology.py est descrito detalhadamente no Apndice A.
114
Figura 5.2 Topologia do plano de dados
Para este trabalho optou-se pelo emprego de uma topologia em malha 3x3. O objetivo ter um cenrio com vrios ns no qual seja possvel alocar vrios slices com pontos em comum entre si e com isso demonstrar o compartilhamento de recursos e o isolamento entre eles. Alm disso, o cenrio oferece um ambiente fortemente sujeito a problemas de loops que podem ser tratados via aplicao no plano de controle de cada slice. Para este cenrio, alocou-se trs slices com as aplicaes de switch, roteamento e o algoritmo SpanningTree(stp). Nas extremidades dos ns, os hosts so utilizados para gerao de trfego no plano de dados por meio de requisies ICMP ou utilizando fluxos TCP ou UDP com uso da aplicao Iperf. 5.1.3. Plano de controle O servidor Mininet que implementa o plano de dados tambm abriga o FlowVisor que responsvel pela instncia de slices para cada experimento. Para este estudo de caso, como forma de demonstrar a implementao de regras de controle lgico sobre a rede virtualizada realizou-se a implementao de trs slices, conforme apresentado na Figura 5.3.
115
Figura 5.3 Slice dos experimentos
Desse modo, representando o controle lgico implementado pelos pesquisadores, criou-se trs instncias do controlador NOX no servidor correspondente ao plano de controle. Associado a esses controladores NOX tm-se uma aplicao especfica a ser executada que implementa o comportamento de encaminhamento no plano de dados. Para o primeiro slice, o experimento da aplicao switch simula o comportamento de encaminhamento em camada 2 e faz com que os ns se comportem como um switch. No segundo slice, a aplicao STP aplica o algoritmo SpanningTree como soluo para o problema gerado pela presena de loops no slice. J no terceiro slice, a aplicao roteador faz com que os ns encaminhem pacotes via camada 3, empregando aos mesmos o comportamento de roteadores. No ambiente controlador NOX, em cada uma das VMs designada a um slice, executou-se respectivamente os seguintes comandos, invocando a aplicao correspondente.
116
# nox_core v u i ptcp:1515 switch # nox_core v u i ptcp:1516 switch spanning_tree # nox_core v u i ptcp:1517 switch route No ambiente onde se encontra a aplicao do FlowVisor, foram criados os slices intitulados como switch, switch_stp e switch_router. Cada um destes slices destina-se a conectar a sua respectiva instncia de execuo do controlador NOX. As instrues a seguir, utilizando o comando fvctl, efetivam a criao dos slices. ufpa.br # fvctl createSlice switch tcp:192.168.100.1:1515 research_switch@
# fvctl createSlice switch_stp tcp:192.168.200.1:1516 research_ switch_stp@ufpa.br # fvctl createSlice switch_router tcp:192.168.300.1:1517 research_ router@ufpa.br Ao final de cada entrada ser solicitada uma senha especfica para aquele slice. Como forma de prover um controle de acesso, esta senha pode ser utilizada para obter informaes bsicas relacionadas aos slices no FlowVisor. O comando a seguir e sua sada exemplificam este controle e os slices existentes. # fvctl listSlices Enter roots password: Slice 0: root Slice 1: switch Slice 2: switch_stp Slice 3: switch_router 5.2. Aplicao Prtica A aplicao prtica apresenta o comportamento do que foi determinado nas aplicaes que esto sendo executadas no controlador NOX. A primeira aplicao apenas efetua encaminhamento seguindo regras de switch; a segunda alm de efetuar o encaminhamento, trata do aparecimento de loops na rede atravs do protocolo SpanningTree; e, a terceira, por fim, habilita o roteamento de pacotes dentro do slice alocado.
117
Slice Switch Representando a solicitao de recursos realizada por um pesquisador, para o slice switch, foi designada a topologia representada pela Figura 5.4. Nesta topologia, ao fluxo de pacotes entres os hosts que esto ligados aos elementos de rede so implementadas as aes de um switch.
Figura 5.4 Slice Switch
Nesta aplicao o comportamento de um switch consiste em analisar cada pacote e aprender sobre sua porta de origem, associando o endereo MAC de origem porta onde o mesmo est conectado. Caso o destino do pacote j esteja associado a uma dada porta, o pacote ser enviado diretamente, caso contrrio, o switch realizar a ao de flood em todas as portas aguardando que o destino responda requisio. Para efetivar a alocao de recursos para o slice, deve-se implementar via linha de comando o espao de fluxos que o compe. A definio inclui a especificao dos ns que compem o plano de dados e a caracterizao do fluxo ali corrente. Os comandos a seguir implementam esta ao.
118
# fvctl addFlowSpace 00:00:00:00:00:01 10 dl_vlan=100 Slice:switch=4 # fvctl addFlowSpace 00:00:00:00:00:02 10 dl_vlan=100 Slice:switch=4 # fvctl addFlowSpace 00:00:00:00:00:03 10 dl_vlan=100 Slice:switch=4 Nos comandos acima se tem a adio dos ns SW01, SW02 e SW03 da topologia subjacente ao slice switch. Os ns so identificados pelos endereos MAC (datapath id) 00:00:00:00:00:01, 00:00:00:00:00:02 e 00:00:00:00:00:03, respectivamente. Este endereamento atribudo por meio do script que define a topologia cujo cdigo-fonte est localizado no Apndice A. Alm disso, os comandos aplicam o isolamento de recursos por meio da identificao de vlans, neste caso igual a 100. Desse modo outros slices podem ser criados em paralelo utilizando os mesmos elementos do plano de dados, porm com uma caracterizao de fluxos diferente. Aps a incluso dos fluxos no FlowVisor os switches passam a ser reconhecidos pelo NOX e a executar as aes da aplicao instanciada no mesmo. Para ilustrar o funcionamento da aplicao switch, aplica-se um fluxo ICMP do tipo ECHO_REQUEST e ECHO_REPLY entre os hosts do slice. Na primeira tentativa de comunicao entre eles so trocadas informaes de controle entre o slice e o controlador NOX. O controlador impe ento as polticas de fluxo que so implementadas nas tabelas dos ns pertencentes neste slice (Figura 5.5a). Depois do primeiro estabelecimento de conexo entre os hosts, o trfego de dados no flui mais atravs do controlador. Neste momento os dados so transmitidos com as informaes contidas em cada switch e estes switches atualizam a tabela de fluxo do NOX com o status do enlace estabelecido (Figura 5.5a).
119
Figura 5.5a Troca de mensagens entre plano de dados e plano de controle
Figura 5.5b Encaminhamento sem troca de mensagens entre plano de dados e plano de controle
120
Slice STP Para o correto funcionamento de uma rede Ethernet, deve haver somente um caminho ativo entre dois sistemas finais. O protocolo STP, como um protocolo de gerenciamento de enlace, alm de prover redundncia por meio de caminhos alternativos entre estes sistemas, previne a existncia de loops indesejveis na rede. Para o slice denominado switch_stp, optou-se por implementar a topologia representada pela Figura 5.7. Nesta topologia tem-se um cenrio no qual h presena de loops no caminho entre os hosts finais. O objetivo, neste caso, tratar esta problemtica por meio da implementao do algoritmo SpanningTree no ambiente controlador que proprietrio deste slice.
Figura 5.6 Slice STP
No mdulo STP implementado, quando um novo switch conecta-se ao controlador Nox, o mdulo registra este momento e desabilita a operao de flood em todas as suas portas. Periodicamente o mdulo realiza consultas a uma lista com todos os enlaces. Esta lista utilizada para a construo da rvore do Spanning Tree. Os seguintes passos constroem esta estrutura:
121
Todos os switches candidatos so alocados em uma lista e ordenados (crescentemente) por meio de seu DPID; O primeiro elemento (com o menor DPID) removido da lista e definido como switch raiz; Nesse momento, todos os enlaces do switch raiz so examinados para que se identifique os switches de destino ligados a ele. O enlace para o qual o switch de destino no tem sido processado ainda nesta rodada habilitado (adicionado rvore SpanningTree). Somente um enlace deve levar a um dado destino. Caso haja mltiplos enlaces que levem a um switch de destino, o enlace mais rpido escolhido e, considerando a existncia de mltiplos enlaces com a mesma velocidade, o primeiro deles escolhido. Este procedimento ento executado para todos os switches candidatos que compem a lista. O mdulo SpanningTree utiliza-se do mdulo de descoberta, chamado Discovery, para localizar as ligaes dos switches com os seus ns vizinhos. A alocao de recursos ao slice switch_stp feita de maneira similar ao que foi implementado para slice switch. Para este fim, deve-se executar a seguinte sequncia de comandos: # fvctl addFlowSpace 00:00:00:00:00:04 10 dl_vlan=200 Slice:switch_stp=4 # fvctl addFlowSpace 00:00:00:00:00:05 10 dl_vlan=200 Slice:switch_stp=4 # fvctl addFlowSpace 00:00:00:00:00:07 10 dl_vlan=200 Slice:switch_stp=4 # fvctl addFlowSpace 00:00:00:00:00:08 10 dl_vlan=200 Slice:switch_stp=4 Neste experimento possvel observar a aplicao do Spanning Tree nos switches SW04, SW05, SW07 e SW08. Novamente os fluxos aplicados neste slice so caracterizados pela identificao de vlan cujo valor corresponde a 200. Pode-se observar que por meio da remoo do loop na topologia, h comunicao entre os hosts finais ligados diretamente aos switches. Como realizado no experimento anterior, foi gerado um fluxo ICMP entre os hosts que utilizam este slice. Uma vez encontrada a topologia o algoritmo SpanningTree ir calcular a melhor forma de desfazer o loop, desabilitando umas das portas do switch que foi escolhida no clculo. A Figura 5.8 mostra o momento que o controlador comea a efetuar flood em
122
portas e non-flood em outras para montar a rvore de ns. Nesta figura, os itens numerados de 1 a 5 mostram o processo de reconhecimento de caractersticas dos switches que compem o slice, alm da convergncia da aplicao na habilitao (e no habilitao) de portas.
Figura 5.7
O item 1 corresponde descoberta dos switches, neste momento o comando de non-flood enviado em todas as suas portas para que se possa iniciar o mapeamento da rvore de ns. No item 2, o primeiro switch selecionado, tem suas portas 1, 3 e 4 habilitadas com o envio de um food e a porta 2 desabilitada por meio de um non-flood. Deste modo o algoritmo segue para os prximos switches candidatos conforme itens 3, 4 e 5 at que a rvore esteja formada e o protocolo convergido completamente, habilitando assim o trfego entre os dois hosts. Toda a comunicao pode ser verificada como descrita no primeiro slice atravs do software Wireshark. Slice Roteamento Neste ltimo experimento os recursos alocados no slice switch_ router so controlados via NOX utilizando a aplicao de roteamento. Esta aplicao possui a capacidade de aplicar aos ns o comportamento de roteadores, efetuando encaminhamento camada 3. A topologia ilustrada na Figura 5.11 exibe como os recursos de rede so visualizados pelo controlador NOX.
123
Figura 5.8 Slice Roteamento
O mdulo roteador baseado em roteamento esttico. Durante o funcionamento do mdulo, cada n da rede ter uma sub-rede configurada. Quando um pacote destinado a um host que est nesta mesma sub-rede, o n age como um switch, encaminhando o pacote sem alteraes para uma porta conhecida ou de difuso. Caso um pacote seja destinado para um endereo IP no qual o roteador conhece o prximo salto, o mesmo modifica o cabealho e envia o pacote para a porta correta. Para aplicar os ns que fazem parte do slice neste experimento, a configurao do espao de fluxos para a aplicao switch_router recebe a seguinte implementao: # fvctl addFlowSpace 00:00:00:00:00:01 10 dl_vlan=300 Slice:switch_router=4 # fvctl addFlowSpace 00:00:00:00:00:02 10 dl_vlan=300 Slice:switch_router=4 # fvctl addFlowSpace 00:00:00:00:00:03 10 dl_vlan=300 Slice:switch_router=4
124
# fvctl addFlowSpace Slice:switch_router=4 # fvctl addFlowSpace Slice:switch_router=4
00:00:00:00:00:04 00:00:00:00:00:06
10 10
dl_vlan=300 dl_vlan=300
Neste caso, aplicam-se os switches SW01, SW02, SW03, SW04 e SW06 ao slice switch_route. Cada host est endereado com sub-redes diferentes por meio das seguintes configuraes de endereamento IP listadas pela Tabela 5.4:
Tabela 5.4 Endereamento IP dos hosts ligados ao slice
Host Host01 Host02 Host03 Endereo IP 0.0.0.0 0.0.0.0 0.0.0.0 Sub-rede 0.0.0.0 0.0.0.0 0.0.0.0
Para fins de testes, por meio da aplicao do Iperf, utilizam-se dois fluxos de pacotes, sendo o primeiro UDP e o segundo TCP. Desta forma, entre os hosts 01 e 02 tm-se um fluxo TCP na porta 200 e entre os hosts 01 e 03 tm-se um fluxo UDP na porta 100. Na primeira tentativa de estabelecimento de comunicao entre os hosts so trocadas informaes de controle, assim como informaes dos dados a serem transmitidos de modo que a tabela de fluxo nos elementos do slice seja construda. Diferentemente do slice switch, os campos utilizados desta vez correspondem a informaes da camada 3, correspondente a aplicao routing instanciada no controlador NOX (Figura 5.12a). Aps a definio da tabela de fluxo, os dados so trafegados entre os hosts com informaes contidas nos prprios switches e estes ficam responsveis por atualizar a tabela de fluxo junto ao NOX com o status do enlace (Figura 5.12b).
125
Figura 5.9a Slice Roteamento
Figura 5.9b Slice Roteamento
Esta aplicao de roteamento no baseada em algoritmos especficos tais como de vetor de distncia ou estado de enlace. Para que isso ocorra, tornando a aplicao mais sofisticada, faz-se necessrio a implementao destes algoritmos via ambiente controlador. Como exemplos de esforos neste sentido, existe a aplicao QuagFlow [Nascimento et. al, 2011]. Por meio do QuagFlow possvel aplicar algoritmos de roteamento em modo de compatibilidade com o conjunto de aplicaes Quagga [Quagga, 2011]. Desse modo, os mesmos algoritmos implementados para Quagga podem ser utilizados pelo NOX de modo que se possa atender aos requisitos mais exigentes de um ambiente real de execuo.
126
5.3. Concluso O estudo de caso mostrou que de uma maneira rpida e simplificada possvel construir infraestruturas prontas para experimento de protocolos baseadas em redes OpenFlow. Alm disso, uma excelente ferramenta para a experimentao em Internet do Futuro (IF). Observou-se que com pequenos recursos possvel iniciar estes estudos para IF virtualizando todo plano de dados alinhados s necessidades de um ambiente real. Alm disso, observa-se que o Openflow associado ao FlowVisor oferece de uma maneira muito flexvel a construo desse ambiente oferecendo uma API extensvel para a criao de aplicaes que modelem o comportamento dos fluxos no plano de dados. Um ponto fraco da soluo seria a no disponibilidade de interfaces de mais alto nvel, como interfaces web que facilitem a interao com FlowVisor. O que deixa a sua manipulao fortemente dependente do administrador da rede para criao do plano de dados virtual. 6. Consideraes finais e o futuro em Pesquisa Experimental em Internet do Futuro 6.1. Consideraes finais Observa-se que a Internet atual no conseguir sustentar todos os desafios que lhe so impostos, por isso a remodelagem de sua arquitetura um fato nesta prxima dcada. O processo de anlise e desenvolvimento desta nova arquitetura j comeou em muitos pases com iniciativas GENI, FIRE e FIBRE. Neste contexto, a virtualizao tornou-se a principal ferramenta para pesquisa de desenvolvimento e habilitao da Internet do Futuro em todas as comunicaes ou camadas computacionais dessas grandes infraestruturas. Com o uso da virtualizao na construo desses testbeds foi possvel desacoplar a complexidade dos recursos fsicos dos servios oferecidos e apresentar simples interfaces com usurio, em localizaes geogrficas distintas e independentes de dispositivo de acesso. Alm disso, a virtualizao ter um papel importante, pois ela permitir a comparao das novas tecnologias que esto sendo desenvolvidas para Internet do Futuro, com as tecnologias atuais. Tambm garantir que tecnologias desenvolvidas no passado possam ser disponveis nessa moderna infraestrutura.
127
Com isso, a construo dos frameworks para esses testbeds est sendo desenvolvida com base no conceitos de redes definidas por software (SDN) e virtualizao, seja ela baseada na virtualizao do substrato, seja na infraestrutura fsica que contm todos os hardwares e softwares para inicializar os recursos virtuais, bem como para a criao da infraestrutura virtual contendo os recursos virtuais e a topologia lgica, interligando-as. O framework OpenFlow uma dessas solues, pois prov um protocolo aberto para programao do comportamento de fluxos de pacote em diferentes switches e roteadores. A rede contendo OpenFlow pode ter o trfego particionado entre trfego de produo e trfego de experimentao, de maneira que pesquisadores possam controlar seus prprios fluxos. A rede de produo permanecer isolada e processada da mesma maneira que antes do uso do OpenFlow. Ainda, o OpenFlow integrado com a ferramenta FlowVisor capaz de criar e virtualizar elementos de redes de modo que uma mesma infraestrutura fsica possa ser compartilhada entre vrias topologias lgicas, onde cada um possui sua prpria lgica de encaminhamento e tratamento de fluxos de pacotes distintos. Por fim, o OpenFlow possibilita de maneira rpida e simples a criao de uma infraestrutura para concepo de novos protocolos, como apresentada na seo de estudos de casos onde em um nico servidor, conseguimos simular uma infraestrutura de switches e roteadores OpenFlow. Tambm conseguimos aplicar os conceitos de virtualizao baseada em slice de recursos e redes programveis. Este captulo apresentou o andamento da pesquisa experimental em Internet do Futuro no mundo e observou duas grandes tecnologias que estaro presentes nessas infraestruturas montadas em escala mundial. So elas: a virtualizao e o framework OpenFlow. 6.2. Tendncias futuras Em uma viso geral sobre as tendncias futuras, observa-se que essa corrida pela to sonhada Internet 3.0 ainda est em sua fase inicial, porm se expandindo extremamente rpida entre os continentes no mundo. No topo da corrida, esto a Amrica do Norte, Europa e Japo, seguidos do Brasil. Na amrica do norte, o projeto GENI est iniciando a sua terceira fase, chamada espiral 3 (Spiral 3). As tendncias, nesta terceira fase, sero iniciar o suporte de pesquisadores nas infraestruturas de experimentao
128
e a incrementao de recursos disponveis para uso entre seus usurios. Alm disso, ainda ir continuar os esforos na implementao, integrao e incio das operaes com switches OpenFlow e estaes base WiMax. J na Europa, o projeto FIRE, que est entrando na chamada first wave, est investindo 40 bilhes de euros para criao de testbed sustentveis em internet do futuro. Neste momento as convergncias do projeto esto na busca pela estabilizao das suas infraestruturas de experimentao, alm de iniciar as chamadas por parceiros para a criao de estudos de casos a serem aplicados em seus ambientes. No Japo, representado pelo projeto AKARI [AKARI, 2009], que est em seu segundo perodo de desenvolvimento, a tendncia futura iniciar as construes de seus testbeds e as primeiras demonstraes experimentais. O objetivo para o final de 2016 oferecer um prottipo da nova gerao de rede para disponibilidade aos pesquisadores. Por fim, no Brasil, a pesquisa em Internet do futuro iniciou-se atravs de projetos isolados, como o projeto Horizon [HORIZON, 2011] e o projeto Webscience [WEBSCIENCE, 2011], mas efetivamente se fortaleceu atravs do projeto FIBRE, de cooperao entre o Brasil e a Unio Europeia, que prev a construo de uma infraestrutura experimental brasileira compartilhada de larga escala, que permita a experimentao em infraestrutura de rede e aplicaes distribudas. Isso consistir em um novo ambiente de teste baseado em OpenFlow no Brasil e uma melhoria da instalao do projeto OFELIA, atualmente em desenvolvimento na Europa. Alm disso, possibilitar a federao de ambientes de teste dos parceiros brasileiros e europeus para permitir aos pesquisadores que usem recursos de ambos em um mesmo experimento. Tal iniciativa demonstrar o potencial das instalaes ao mostrar aplicaes baseadas em OpenFlow, estabelecidas sobre os recursos das instalaes federadas. Portanto, aumentar a colaborao e a troca de conhecimentos entre pesquisadores europeus e brasileiros no campo de Internet do Futuro. Referncias David C. Clack (2009). Toward the design of a future Internet. Technical Report: National Science Fundation. Disponvel em: <http://groups.csail. mit.edu/ana/People/ DDC/Future%20Internet%207-0.pdf>. Anja Feldmann. Internet clean-slate design: what and why?. SIGCOMM Comput. Commun. Rev. 37, 3 (July 2007), 59-64.
129
Banniza, T.-R., Boettle, D., Klotsche, R., Schefczik, P., Soellner, M. and Wuenstel, K. (2009), A European approach to a clean slate design for the future Internet. Bell Labs Technical Journal, 14: 522. Jennifer Rexford and Constantine Dovrolis. 2010Es. Future Internet architecture: clean-slate versus evolutionary research. Commun. ACM 53, 9 (September 2010), 36-40. Subharthi Paul, Jianli Pan, Raj Jain. Architectures for the Future Networks and the Next Generation Internet: A Survey Computer Communications, Vol. 34, No. 1. (15 January 2011), pp. 2-42. GENI. Global Environment for Network Innovations, Disponvel em: <http://www.geni.net. Acessado em 20/10/2012>. FIND. Future Internet Design. Disponvel em: <http://www.nets-find. net>. Acessado em: 20/10/2012. FIBRE. Future Internet Experimentation between Brazil and Europe. Disponvel em: <http://www.fibre.org.br>. Acessado em 20/10/2012. FIRE. Future Internet Research and Experimentation. Disponvel em: <http://cordis.eur opa.eu/fp7/ict/fire/>. Acessado em 20/10/2012. AKARI project (2009), New Generation Network Architecture: AKARI Conceptual Design (ver1.1), Disponvel em: <http://akari-project.nict. go.jp/eng/concept-design/>. AKARI <_fulltext_e_preliminary.pdf>. Acessado em 20/02/2011. CFI 2010: 5th International Conference on Future Internet Technologies (em conjunto com 2nd Future Internet Testbed & Research Workshop), June 16-18, 2010, Seoul, Korea, <http://as.kaist.ac.kr/cfi10/>. Acessado em 3/1/2011. Jun Bi, Future Internet related Research Activities in China, 30th APAN Meeting, August 2010, Hanoi, Vietnam. Disponvel em: <http://www. apan.net/meetings/Hanoi 2010/Session/Slides/FutureInternet/3-1.pdf>. Acessado em 20/02/2011.
130
Choudhury, N.M.M.K., and Boutaba, R. (2010), A survey of network virtualization, In: Computer Networks, Volume 54, Maro 2010, pp. 862-876. Nick McKeown, Tom Anderson, Hari Balakrishnan, Guru Parulkar, Larry Peterson, Jennifer Rexford, Scott Shenker, and Jonathan Turner. 2008. OpenFlow: enabling innovation in campus networks. SIGCOMM Comput. Commun. Rev. 38, 2 (March 2008), 69-74. R. Jain. Internet 3.0: Ten Problems with Current Internet Architecture and Solutions for the Next Generation. Military Communications Conference, 2006. MILCOM 2006, pages 1-9, October 2006. Michael Stanton; Iara Machado. Redes de Pesquisa e Educao: Cenrio do Futuro. Disponvel em: <http://www.ic.uff.br/~michael/futuro-daInternet/redes-de-pesquisa-2009.pdf>. Acessado em: 20/02/2011. Subharthi Paul, Jianli Pan, and Raj Jain, Architectures for the Future Networks and the Next Generation Internet: A Survey, Computer Communications, UK, Volume 34, Issue 1, 15 January 2011, Pages 2-42. Joseph Williams, Lewis Curtis, Green: The New Computing Coat of Arms?, IT Professional, pp. 12-16, January/February, 2008. I. Stoica, D. Adkins, S. Zhuang, et al, Internet Indirection Infrastructure, ACM SIGCOMM, Pittsburgh, PA, 2002, Disponvel em: <http://i3.cs. berkeley.edu/publications/papers/i3-sigcomm.pdf>. H. Balakrishnan, et al, A Layered Naming Architecture for the Internet, SIGCOMM 2004, pp. 343-352. R. Moskowitz, P. Nikander, Host Identity Protocol Architecture, Internet Draft, August 1, 2005, draft-ietf-hip-arch-03, 24 pp. R. Moskowitz, P. Nikander, P. Jokela, T. Henderson, Host Identity Protocol, Internet Draft, October 24, 2005, draft-ietf-hip-base-04, 99 pp. GENI (2008). GENI system overview. Relatrio Tcnico. Disponvel em: <http://groups.geni.net/geni/attachment/wiki/GeniSysOvrvw/ GENISysOvrvw092908.pdf>.
131
Spiral 2 (2010), GENI Spiral 2 Overview. Reltorio Tcnico. Disponvel em: <http://groups.geni.net/geni/attachment/wiki/SpiralTwo/ GENIS2Ovrvw060310.pdf>. B Boehm. 1986. A spiral model of software development and enhancement. SIGSOFT Softw. Eng. Notes 11, 4 (August 1986), 14-24. FIRE (2010). Future Internet Research and Experimentation: An Overview of European FIRE Initiative and its projects. Disponvel em: http://cordis. europa.eu/fp7/ict/fire/docs/fire-brochure-2010_en.pdf. FIRE (2008). Future Internet Research and Experiment: AREA 6. Disponvel em: <http://www.future-Internet.eu/fileadmin/documents/bled_ documents/experiemental_fac ilities/FIRE-Issues-paper-2.2.pdf>. WebScience. Brazilian Institute for Web Science Research. Disponvel em: <http://webscience.org.br/files/INCTportugues2010.pdf>. Acessado em: 20/02/2011. Scarabucci, R.R., et al. (2005), Project GIGA High-speed Experimental Network, In: First International Conference on Testbeds and Research Infrastructures for the DEvelopment of NeTworks and COMmunities (TRIDENTCOM05), Trento, Itlia, 02/2005, p. 242-251. D.Young Kim, L.Mathy, M. Campanella, R. Summerhill, J. Williams, S. Shimojo, Y. Kitamura, H. Otsuki, Future Internet: Challenges in Virtualization and Federation aict, pp.1-8, 2009 Fifth Advanced International Conference on Telecommunications, 2009. M.Campanella, The FEDERICA Project: creating cloud infrastructures, In Proceedings of Cloudcomp 2009 (CloudComp), October 19-21, 2009, Munich, Germany. Thrasyvoulos S.; Serge F.; Scott K. 2007. Future Internet: fundamentals and measurement. SIGCOMM Comput. Commun. Rev. 37, 2 (March 2007). P. Sezgedi, S. Figuerola, M. Campanella, V. Maglaris, C. Cervello-Pastor: With Evolution for Revolution: Managing FEDERICA for Future Internet Research, IEEE Communications Magazine, Vol.47, No.7, pp. 34-39, July 2009.
132
G. Di Stasi, R. Bifulco, F. P. DElia, S. Avallone, R. Canonico, A. Apostolaras, N. Giallelis, T. Korakis and L. Tassiulas. Experimenting with P2P traffic optimization for Wireless Mesh Networks in a federated OMF-PlanetLab environment. WCNC 2011, IEEE Wireless Communications & Networking Conference. Cancun (Mexico): March 28-31, 2011. Eric Eide, Leigh Stoller, Tim Stack, Juliana Freire, and Jay Lepreau. 2006. Integrated scientific workflow management for the Emulab network testbed. In Proceedings of the annual conference on USENIX 06 Annual Technical Conference (ATEC 06). USENIX Association, Berkeley, CA, USA, 33-33. L. Peterson, S. Sevinc, J. Lepreau, et al., Slice-Based Facility Architecture, Draft Version 1.04, April 7, 2009, <http://svn.planet-lab.org/attachment/ wiki/GeniWrapper/ sfa.pdf>. ProtoGENI. Disponvel em: <http://groups.geni.net/geni/wiki/ ProtoGENI>. Acessado em: 20/02/2011. ORCA, Open Resource Control Architecture Disponvel em: <http:// groups.geni.net/ geni/wiki/ORCABEN>. Acessado em: 20/02/2011. BEN. Breakable Experimental Network. Disponvel em: <https://geni-orca. renci.org/trac>. Acessado em: 20/02/2011. OMF. Control and Management Framework. Disponvel em: <http://omf. mytestbed.net>. Acessado em: 20/02/2011. P. Antoniadis, T. Friedman, X. Cuvellier, Resource Provision and Allocation in Shared Network Testbed Infrastructures, ROADS 2007, Warsaw, Poland, July 11-12, 2007. John W. Lockwood, Nick McKeown, Greg Watson, Glen Gibb, Paul Hartke, Jad Naous, Ramanan Raghuraman, and Jianying Luo. 2007. NetFPGA-An Open Platform for Gigabit-Rate Network Switching and Routing. In Proceedings of the 2007 IEEE International Conference on Microelectronic Systems Education (MSE 07). IEEE Computer Society, Washington, DC, USA, 160-161. Muhammad Bilal Anwer and Nick Feamster. 2009. Building a fast, virtualized data plane with programmable hardware. In Proceedings of the
133
1st ACM workshop on Virtualized infrastructure systems and architectures (VISA 09). ACM, New York, NY, USA, 1-8. Indigo, Disponvel em: <http://www.OpenFlowhub.org/display/ Indigo/Indigo+-+Open Flow+for+Hardware+Switches>. Acessado em: 20/02/2011. Kate Greene (2009-04), TR10: Software-Defined Networking, MIT Technology Review. Brian Tierney, Jeff Boote, Eric Boyd, Aaron Brown, Maxim Grigoriev, Joe Metzger, Martin Swany, Matt Zekauskas, Yee-Ting Li, and Jason Zurawski, Instantiating a Global Network Measurement Framework,LBNL Technical Report LBNL-1452E. Disponvel em: <http://acs.lbl.gov/~tierney/papers/ perfsonar-LBNL-report.pdf>. Acessado em janeiro de 2009. Y. P. Chen, A. L. Liestman and J. Liu. A Hierarchical Energy-Efficient Framework for Data Aggregation in Wireless Sensor Networks, IEEE Transactions on Vehicular Technology, 55(3):789-796, May 2006. Larry Peterson, Steve Muir, Timothy Roscoe, Araon Klingaman. PlanetLab Architecture: An Overview. Documento Tcnico, maio 2006. Disponvel em: <http://www.planet-lab.org/files/pdn/PDN-06-031/pdn-06-031.pdf>. BonFIRE. Building service testbeds on Future Internet Research and Experimentation. Disponvel em: <http://www.bonfire-project.eu/ project>. Acessado em: 20/02/2011. S. Savage, T. Anderson, A. Aggarwal, D. Becker, N. Cardwell, A. Collins, E. Hoffman, J. Snell, A. Vahdat, G. Voelker, J. Zahorjan, Detour: a case for informed internet routing and transport, IEEE Internet Computing 19 (1) (1999) 5059. D. Andersen, H. Balakrishnan, F. Kaashoek, R. Morris, Resilient overlay networks, SIGOPS Operating Systems Review 35 (5) (2001), 131145. J. Jannotti, D.K. Gifford, K.L. Johnson, M.F. Kaashoek, J. James, W. OToole, Overcast: reliable multicasting with an overlay network, in: Proceedings of the Fourth Conference on Symposium on Operating System Design & Implementation (OSDI00), 2000, pp. 197212.
134
Y. Chu, S. Rao, S. Seshan, H. Zhang, Enabling conferencing applications on the internet using an overlay multicast architecture, SIGCOMM Computer Communication Review 31 (4) (2001) 5567. L. Subramanian, I. Stoica, H. Balakrishnan, R. Katz, OverQoS: an overlay based architecture for enhancing internet QoS, in: Proceedings of the First Symposium on Networked Systems Design and Implementation (NSDI), 2004, pp. 7184. A. Keromytis, V. Misra, D. Rubenstein, SOS: secure overlay services, in: Proceedings of the ACM SIGCOMM Conference (SIGCOMM02), 2002. D.G. Andersen, Mayday: distributed filtering for internet services, in: Proceedings of the Fourth Conference on USENIX Symposium on Internet technologies and Systems (USITS03), USENIX Association, Berkeley, CA, USA, 2003. B. Krishnamurthy, C. Wills, Y. Zhang, On the use and performance of content distribution networks, in: Proceedings of the First ACM SIGCOMM Workshop on Internet Measurement (IMW01), ACM, New York, NY, USA, 2001, pp. 169182. E.K. Lua, J. Crowcroft, M. Pias, R. Sharma, S. Lim, A survey and comparison of peer-to-peer overlay network schemes, IEEE Communications Surveys & Tutorials 7 (2) (2005) 7293. F. Dabek, M.F. Kaashoek, D. Karger, R. Morris, I. Stoica, Wide-area cooperative storage with CFS, in: Proceedings of the 18th ACM Symposium on Operating Systems Principles (SOSP01), ACM, New York, NY, USA, 2001, pp. 202215. L. Peterson, T. Anderson, D. Culler, T. Roscoe, A blueprint for introducing disruptive technology into the Internet, SIGCOMM Computer Communication Review 33 (1) (2003) 5964. Sherwood, Rob; Glen, Gibb; Kobayashi Masayoshi. Carving Rearch Slices Out of Your Production Networks with OpenFlow. ACM SIGCOMM Computer Communication Review, Volume 40, Janeiro 2010.
135
Rob Sherwood, Glen Gibb, Kok-Kiong Yap, Guido Appenzeller, Martin Casado, Nick McKeown, and Guru Parulkar. 2010. Can the production network be the testbed?. In Proceedings of the 9th USENIX conference on Operating systems design and implementation (OSDI10). USENIX Association, Berkeley, CA, USA, 1-6. R. Sherwood, G. Gibb, K. Yap, G. Appenzeller, N. McKeown, and G. Parulkar. FlowVisor: A network virtualization layer, Relatrio Tcnico, 2009. Disponvel em: <http://OpenFlowswitch.org/downloads/ technicalreports/OpenFlow-tr-2009-1flowvisor.pdf>. CREW. Cognitive Radio Experimentation World. Disponvel em: <http:// www.crew-project.eu/>. Acessado em: 20/02/2011. OFELIA. OpenFlow in Europe Linking Infrastructure and Applications. Disponvel em: <http://www.fp7-ofelia.eu/>. Acessado em: 20/02/2011. UMF. Embedding real-time substrate measurements for cross-layer communications. Disponvel em: <http://groups.geni.net/geni/wiki/ Embedded%20Real-Time%20Measurements>. Acessado em: 20/02/2011. Matthias Bolte, Michael Sievers, Georg Birkenheuer, Oliver Niehrster, and Andr; Brinkmann. 2010. Non-intrusive virtualization management using libvirt. In Proceedings of the Conference on Design, Automation and Test in Europe (DATE 10). European Design and Automation Association, 3001 Leuven, Belgium, Belgium, 574-579. Song Wu, Li Deng, Hai Jin, Xuanhua Shi, Yankun Zhao, Wei Gao, Jianyin Zhang, and Jin Peng. 2010. Virtual Machine Management Based on Agent Service. In Proceedings of the 2010 International Conference on Parallel and Distributed Computing, Applications and Technologies (PDCAT 10). IEEE Computer Society, Washington, DC, USA, 199-204. Mazhar B. Tayel and Ashraf A. Taha. 2008. Effect of TCP and UDP parameters on the quality of video streaming delivery over the internet. WTOC 7, 6 (June 2008), 653-662. S. Shalunov. Thrulay Network capacity tester. Disponvel em: <http:// shlang.com/thrulay/>. Acessado em: 20/02/2011.
136
B. Fink, R. Scott. NUTTCP. Disponvel em: <ftp://ftp/lcp.nrl.navy.mil/ pub/nuttcp/2006>. Acesado em: 20/02/2011. en-Wei Hu, Hui-Min Chen, Te-Lung Liu, Hui-Min Tseng, Daniel Lin, Chu-Sing Yang, and C. Eugene Yeh. 2010. Implementation of Alarm Correlation System for Hybrid Networks Based upon the perfSONAR Framework. In Proceedings of the 2010 IEEE 24th International Conference on Advanced Information Networking and Applications Workshops (WAINA 10). IEEE Computer Society, Washington, DC, USA, 893-898. Ps-Performace. pS-Performace ToolKit. Disponvel em: <http://www. internet2.edu/ performance/toolkit>. Acessado em: 20/02/2011. Daniel Nurmi, Rich Wolski, Chris Grzegorczyk, Graziano Obertelli, Sunil Soman, Lamia Youseff, and Dmitrii Zagorodnov. 2009. The Eucalyptus Open-Source Cloud-Computing System. InProceedings of the 2009 9th IEEE/ ACM International Symposium on Cluster Computing and the Grid (CCGRID 09). IEEE Computer Society, Washington, DC, USA, 124-131. E-GENI. Enterprise GENI. Disponvel em: <http://OpenFlow.org/wk/ index.php/E-GENI>. Acessado em: 20/02/2011. Nick McKeown. Clean Slate Research Program. Disponvel em: <http:// cleanslate.stanford.edu/>. Acessado em: 20/02/2011. Horizon. Horizon Project: A New Horizon to The Internet. Disponvel em: <http://www.gta.ufrj.br/horizon/>. Acessado em: 20/02/2011. Marcelo Nascimento, Christian Rothenberg, Marcos Salvador, and Mauricio Magalhes. 2010. QuagFlow: Partnering Quagga with OpenFlow. SIGCOMM10 New Delhi, India. Quagga Routing Suite. Disponvel em: <http://www.quagga.net/>. Acessado em: 14/03/2011.
137
Beyonder mobilidade digital livre com PHP Flvio Gomes da Silva Lisboa
Resumo Beyonder um projeto de software livre, poliglota, multiplataforma, aderente a padres, voltado para o ruso de solues e integrado com as comunidades de software livre e aberto. Seu objetivo disponibilizar um mdulo acoplvel de reconhecimento de dispositivos mveis para seleo da interface com o usurio em aplicaes Web utilizando solues livres e um mdulo que permita a execuo local de aplicaes Web utilizando recursos de HTML 5 e Javascript. 1.1. Introduo Um dos principais destaques da pesquisa TIC Domiclios 2011, realizada pelo Comit Gestor da Internet do Brasil (CETIC.BR, 2012) foi o avano das tecnologias mveis. Alguns fatos apurados pela pesquisa foram os seguintes:
o telefone fixo apresenta estabilidade desde 2008; o celular passa o rdio e se torna a segunda mdia mais presente os notebooks avanam nos domiclios; o aumento da penetrao dos notebooks nos domiclios sugere
no domiclio;
um processo de substituio;
139
FLVIO GOMES DA SILVA LISBOA
o porttil j o primeiro computador em 9% dos domiclios com o aumento da posse dos computadores portteis se deu em todas Em 2011, a proporo de portteis e computadores se iguala na Em 2011, a banda larga mvel ultrapassa o acesso discado pela A banda larga mvel a principal responsvel pelo crescimento
computador;
as classes sociais; classe A;
primeira vez;
da banda larga. O celular caminha para ser uma mdia universalizada entre a populao; As propores de posse e uso do celular esto cada vez mais prximas; O envio de mensagens de texto e fotos pelo celular apresenta estabilidade; Acesso Internet via telefone celular cresce de forma expressiva; A diferena na proporo de pr-pagos e ps-pagos apresenta pequena reduo; Os planos de Internet para pr-pagos so responsveis por 81% do crescimento do uso da Internet nos celulares pr-pagos. A ascenso do uso das tecnologias mveis pela populao em geral indica que os dispositivos mveis tornam-se um meio preferencial de comunicao. O governo deve observar esse fato e procurar disponibilizar servios, para o cidado, que sejam acessveis por dispositivos mveis. Devemos observar que no estamos tratando do governo disponibilizar novos servios para o cidado, mas sim de oferec-los por meio de um novo canal de comunicao. Dessa forma, coloca-se a questo da necessidade ou no de refazer sistemas de informao para operarem nesse novo paradigma, e o custo envolvido nisso. Este o cenrio dentro do qual ser apresentado o projeto Beyonder. 1.2. O projeto O projeto Beyonder tem em seu escopo dois objetivos a serem alcanados:
criar um mdulo acoplvel de reconhecimento de dispositivos
mveis para seleo da interface com o usurio em aplicaes Web utilizando solues livres.
140
BEYONDER MOBILIDADE DIGITAL LIVRE COM PHP
criar um mdulo que permita a execuo local de aplicaes Web
utilizando recursos de HTML 5 e Javascript.
A motivao para alcanar esses dois objetivos tm um fundamento econmico, que se justifica pela austeridade que a administrao pblica deve praticar na conduo de suas atividades, com orientao de utilizar sempre os recursos pblicos da melhor forma: atendendo a populao com o mnimo de gastos possveis. Com relao proviso de reconhecimento de dispositivos mveis em aplicaes Web, temos de considerar o fato de que adaptar aplicaes para serem acessveis por dispositivos mveis evita gastos com novos desenvolvimentos. Com relao execuo local de aplicaes Web em dispositivos mveis, isso permite democratizar o acesso aos servios, no limitando os aparelhos que podem ser utilizados e evitando linhas de produo paralelas para os mesmos aplicativos. Como os dois objetivos envolvem produtos distintos, o projeto foi subdividido em dois subprojetos, denominados Cyborg e Omens. Eles sero descritos com mais detalhes a seguir. 1.2.1. Cyborg O subprojeto Cyborg consiste em um ambiente de desenvolvimento livre para criao de aplicaes embarcadas em dispositivos mveis. Seu objetivo ir alm das iniciativas atuais de desenvolvimento de aplicaes embarcadas para governo, como os aplicativos disponveis para Android e iOs da Receita Federal. Os desenvolvimentos atuais de solues instaladas em celulares e tablets, como os citados anteriomente, limitam-se a dois sistemas operacionais, o que obriga o cidado a ter de usar um determinado produto de software se quiser ter acesso aos servios mveis. No existe liberdade de escolha. O objetivo do projeto Beyonder Cyborg criar uma soluo geral para desenvolvimento de aplicaes que possam ser executadas localmente sem que tenham de ser nativas de determinado(s) sistema(s) operacional(s), dando ao cidado a liberdade de escolha, pois ningum deveria ser obrigado a adquirir determinada marca de produto tecnolgico para ter acesso a servios pblicos. Alm de democratizar o acesso, evita-se o custo de manter linhas de produo paralelas, onde o mesmo aplicativo
141
tem de ser desenvolvido para plataformas diferentes, porque eles no so portveis. 1.2.2. Omens Enquanto o subprojeto Cyborg trata da execuo local de aplicaes Web, e est em um contexto em que pode se pensar em baixa conectividade, o subprojeto Omens trata de um contexto mais amplo, ao lidar com aplicaes acessveis por dispositivos mveis largamente conectados. Uma vez que os dispositivos mveis possuem navegadores e conexo com Internet, as aplicaes Web tambm podem ser utilizadas a partir de celulares e tablets. Ocorre, porm, que as aplicaes existentes no foram originalmente pensadas para isso. O resultado que muitos stios e aplicativos so inoperveis por determinados dispositivos mveis. No necessrio criar novas aplicaes Web para serem acessveis por dispositivos mveis. A questo aqui est na interface. necessrio identificar qual o aparelho que est solicitando dados das aplicaes e apresentar as telas, ou melhor, pginas, mais adequadas quele aparelho, que inclusive saibam quais recursos do navegador podem ser utilizados. O objetivo deste projeto prover um componente que faa a identificao do dispositivo solicitante e selecione uma interface adequada, sem que seja necessrio alterar as demais camadas da aplicao Web. Novamente, no se trata de criar algo do zero, mas de estender e integrar projetos de software livre que j existem. O projeto TeraWURFL prov uma acurada deteco de dispositivos mveis com rpida distino entre Desktop e Mobile, utilizando uma base de dados de alta performance. Esse projeto pode ser integrado com outros que tratam de criao de interfaces especficas para dispositivos mveis, como o Dojo Toolkit e o Jquery.
142
Figura 1 Arquitetura do Omens
143
1.3. O ponto de Interseco Embora tenham focos diferentes, os dois projetos tm um ponto de interseco: nenhuma aplicao mvel hoje pode ser uma ilha. Existe comunicao entre o dispositivo e algum servidor que recebe ou prov dados. Ns continuamos em rede, e ficaremos cada vez mais conectados. Nada impede que uma aplicao Web mobile seja hbrida, quer dizer, ela tenha processamento realizado no servidor e processamento realizado no cliente. Assim com a aplicao embarcada pode realizar processamento local e enviar dados para o servidor, que realizar outro processamento. Por isso, alm dos projetos j mencionados, o Beyonder tambm ir incluir no seu escopo o estudo de plataformas livres para criao de aplicaes independentes de dispositivos que sejam executadas tanto no cliente quanto no servidor. Um exemplo o projeto Mojito, um framework Javascript disponibilizado pelo Yahoo! que explora as funcionalidades do HTML 5 e do Node.js, uma plataforma para construo de aplicaes em redes rpidas e escalveis. 1.4. Infraestrutura necessria Um processo de construo de software envolve codificao e testes. Neste caso, notadamente, os testes so parte intrnseca de um ciclo iterativo de desenvolvimento. Ao contrrio de uma aplicao Desktop ou Web, que poderia ser colocada em execuo na prpria estao de trabalho do desenvolvedor, esse projeto exige a execuo em dispositivos mveis. E mais, em dispositivos mveis com diferentes caractersticas, desde o tamanho fsico at os recursos disponveis pelos seus navegadores. Embora pudesse ser vivel solicitar o emprstimo de dispositivos dos respectivos fabricantes, que com certeza tm interesse de que seus aparelhos sejam compatveis com a maior quantidade possvel de servios, isso possivelmente iria implicar em algum custo. Mas os dados expostos na introduo desse trabalho j indicavam um outro caminho, muito mais simples e econmico para homologar os produtos do projeto em uma gama diversa de dispositivos mveis. Dados os nmeros expostos na introduo, pode-se imaginar que em qualquer empresa a maioria dos funcionrios contm um celular. Se considerarmos que o corpo gerencial tem necessidade de dispositivos mveis com amplos recursos, podemos imaginar que uma parcela dos funcionrios deve portar um tablet.
144
Ou seja, j existe um exrcito de testadores e homologadores para o projeto. Tudo o que eles precisam fazer requisitar uma pgina de seus dispositivos mveis e responder se a interface exibida est de acordo com o tamanho de seu dispositivo e se a aplicao completamente funcional. A validao pode ser feita por meio de um formulrio eletrnico, de fcil preenchimento e submisso. Dessa forma, a infraestrutura necessria para se alocar a esse projeto consiste to somente em uma estao de trabalho que funcione como ambiente de teste e homologao, uma mquina acessvel por Internet, que receba requisies de dispositivos mveis e faa a seleo das vises adequadas de acordo com o dispositivo. Essa mquina tambm far o download dos scripts a serem processados pelos dispositivos. Uma nica mquina atuando como servidora de dispositivos mveis permite que voluntrios acessem a aplicao de teste e relatem os resultados. Em suma, a infraestrutura necessria para o desenvolvimento consiste em uma mquina dedicada, conectada Internet e em voluntrios com celulares e tablets 3G. Essa estrutura simples permite a adeso de testadores e homologadores de outras organizaes interessadas e at da comunidade de usurios em geral, que tem interesse em que os servios digitais de informao sejam acessveis plenamente pelos seus dispositivos mveis. 1.5. Sustentabilidade O projeto tem como alicerce outros projetos de software livre, com suas respectivas comunidades. A orientao no criar um produto novo, e ter de manter uma equipe interna de manuteno e suporte dedicada. Uma vez lanada a primeira verso estvel, o objetivo manter o projeto como um conjunto de contribuies aos projetos originais, atualizando a parte genrica e mantendo apenas o que for particular ao projeto. Assim possvel ter apenas um desenvolvedor que atue como coordenador e de acordo com a demanda, e que envolva os recursos necessrios, de forma pontual, nunca contnua. O modelo de negcio no manter uma equipe dedicada, mas ter contribudores envolvidos nos projetos que formam a infraestrutura do projeto Beyonder.
145
O projeto j foi hospedado desde o princpio no Github, um repositrio de projetos de software que permite fcil clonagem e ramificao, o que torna mais simples contribuir com o software. Ele est aberto a contribuies de quaisquer voluntrios e seus resultados e produtos esto disponveis para todos que estiverem interessados. A abertura do cdigo-fonte permite que ele seja auditado, testado e melhorado de uma forma que no possvel para uma s equipe em uma nica empresa. 1.6 Os nomes O nome Beyonder vem do ingls e significa algo como aquele que est alm, acima ou fora do alcance, inclusive se referindo a algum de outro mundo. No caso deste projeto, o nome Beyonder tem dois propsitos: o primeiro, de usar a lngua franca de nosso tempo, e comunicar rapidamente a ideia de algo a distncia, o segundo de fazer uma homenagem a uma figura importante na histria das comunicaes no Brasil. O Marechal-do-Ar Casimiro Montenegro Filho, patrono da rea de Engenharia da FAB e da Academia Nacional de Engenharia, foi criador do ITA e CTA, instituies de ensino e pesquisa que permitiram ao Brasil criar uma indstria nacional de aviao. Mas antes das honrarias e dos empreendimentos em cincia e tecnologia, quando ainda era tenente do Exrcito, Casimiro realizou o primeiro voo do CAN (Correio Areo Nacional), levando a bordo de um biplano monomotor correspondncias do Rio de Janeiro para So Paulo. Ele foi pioneiro no uso do avio como instrumento de comunicao. O Correio Areo Nacional encurtou as distncias entre pessoas e empresas. Podemos dizer que o pioneirismo do Marechal Casimiro levou a comunicao alm dos limites a que estava presa, ao usar os ares como meio de transporte. Hoje, os celulares e tablets tambm usam os ares para interagirem com redes de comunicao, e no s a distncia entre cidades foi superada, como a distncia entre pases e continentes. O nome Beyonder portanto uma homenagem contribuio do Marechal Casimiro ao desenvolvimento das comunicaes no Brasil. Os nomes dos subprojetos tambm tem motivos inspirados. O subprojeto Cyborg tem esse nome para lembrar algo hbrido. Um ciborgue uma criatura metade homem, metade mquina. A aplicao
146
Web executada localmente algo hbrido, pois utiliza parcialmente processamento local e parcialmente conexo com um servidor. O subprojeto Omens tem esse nome para lembrar algo que est distncia e que alcanado por meio de um artefato com poderes para tal. Omens significa pressgio em ingls, e uma referncia espada de Lion-o, lder dos Thundercats, que conferia a ele a viso alm do alcance. A frase dita ao utilizar esse poder era Sword of Omens give me sight beyond sight. O nome da espada no original Sword of Omens. 1.7 Onde estamos agora O projeto Expresso 3 (https://github.com/explivre) possui sincronia com dispositivos mveis, mas no uma verso mobile para suas aplicaes. Por isso, ele foi escolhido como cliente para o Beyonder Omens, o primeiro subprojeto a ter um produto entregvel. Foi realizada a prospeco de APIs de reconhecimento de dispositivos com bancos de dados de caractersticas, e foram selecionados dois produtos livres: Browser Capabilities (BCP) e TERA WURFL. Com base nessas APIs, foi criada uma biblioteca de classes chamada Beyonder, seguindo o modelo de componentes do Zend Framework, que utilizado no backend do Expresso. A figura 2 mostra a estrutura dessa biblioteca.
Figura 2 Biblioteca Beyonder
147
Quatro aplicaes de exemplo foram criadas para testar essa biblioteca, que pode ser utilizada em uma aplicao PHP com Zend Framework. Elas esto disponveis dentro do site do Frum de Tecnologia em Software Livre nos seguintes endereos:
http://ftsl.org.br/bcomens http://ftsl.org.br/bcomens2 http://ftsl.org.br/twomens http://ftsl.org.br/twomens2
possvel acessar esses endereos e conferir pginas diferentes para acesso mobile e desktop. Todo o cdigo do projeto e das aplicaes criadas est disponvel em <https://github.com/fgsl/beyonder>. O ambiente tambm permite colaborao, estando aberto a sugestes e crticas. 1.8. Reflexes Temos um paradigma de desenvolvimento tecnolgico baseado em competio, que possui como grande referncia as guerras, mesmo as frias como a que teve como grande campo de batalha a corrida espacial entre Estados Unidos da Amrica e a extinta Unio Sovitica. No entanto, esse modelo de desenvolvimento em que uma das partes sempre perde acaba sendo danoso, porque a responsabilidade por manter algo sozinho muito grande. E sabemos da fragilidade de depender de um nico vencedor quando lembramos da Crise de 1929. Segundo Stephen Hawking, Sir Isaac Newton disse que, se havia visto mais longe, era porque estava sobre ombros de gigantes. Com isso ele queria dizer que no poderia ter criado o clculo diferencial e integral nem descoberto a lei da gravitao universal se no tivesse acesso aos trabalhos de outros pesquisadores, como Coprnico, Galileu, Kepler e Descartes. O avano da cincia e da tecnologia s realmente possvel, com benefcio para todos, pela agregao de conhecimento, feita com compartilhamento. 1.9. Concluses O projeto Beyonder totalmente realizvel. Ele est baseado em reuso de solues, tecnologia aberta e custo mnimo. Mas principalmente, est baseado no desenvolvimento de software em comunidade.
148
Esse projeto tem todas as condies de ser mantido com o mnimo custo por uma grande comunidade de desenvolvedores e usurios, dado que comunicao mvel algo que j faz parte do dia a dia do cidado, e os dispositivos mveis tornam-se um meio simples de levar servios pblicos de informao com presteza a todos. 1.10. Referncias CETIC.BR. TIC DOMICLIOS e USURIOS 2011 TOTAL BRASIL. Disponvel em <http://www.cetic.br/usuarios/tic/2011-total-brasil/ analises.htm> Acesso em 06/08/2012. HAWKING, STEPHEN. Os Gnios da Cincia: Sobre os Ombros dos Gigantes. 1.ed. So Paulo. Campus, 2004. THE DOJO FOUNDATION. Mobile. Disponvel em <http://dojotoolkit. org/features/mobile>. Acesso em 08/08/2012. THE JQUERY FOUNDATION. JQuery Mobile Framework. Disponvel em <http://jquerymobile.com/>. Acesso em 08/08/2012. YAHOO!. Mojito. Disponvel em <http://developer.yahoo.com/ cocktails/mojito/>. Acesso em 08/08/2012.
149
Formato Mancha grfica Papel Fontes
15,5 x 22,5 cm 12 x 18,3cm plen soft 80g (miolo), carto supremo 250g (capa) Verdana 13/17 (ttulos), Book Antiqua 10,5/13 (textos)

Consegui 2012

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Consegui 2012

Încărcat de

Drepturi de autor:

Formate disponibile

CONSEGI 2012 V Congresso Internacional Software Livre e Governo Eletrnico

Inovando Servios com Mobilidade Digital

Ministrio das relaes exteriores

Ministro de Estado Secretrio-Geral

Embaixador Antonio de Aguiar Patriota Embaixador Ruy Nunes Pinto Nogueira

Fundao alexandre de GusMo

Embaixador Jos Vicente de S Pimentel

Embaixador Maurcio E. Cortes Costa

CONSEGI 2012 V Congresso Internacional Software Livre e Governo Eletrnico

Impresso no Brasil 2012

MARCOS VINICIUS FERREIRA MAZONI

Introduo Benedicto Fonseca Filho

BENEDICTO FONSECA FILHO

BENEDICTO FONSECA FILHO

{alisson-wilker.silva, jose-ronaldo.souza, viviane.malheiros}@serpro.gov.br.

ALISSON WILKER ANDRADE, RONALDO AGRA, VIVIANE MALHEIROS

MOBILIDADE DIGITAL APLICADA AO GOVERNO BRASILEIRO

2. Caractersticas do desenvolvimento para dispositivos mveis

Figura 1: Novas possibilidades com o uso de dispositivos mveis.

Quadro 1: Especificidades do desenvolvimento para dispositivos mveis.

ALISSON WILKER ANDRADE, RONALDO AGRA, VIVIANE MALHEIROS

<http://www.w3.org/TR/html/>. <http://www.w3.org/Style/CSS/>. <http://www.w3.org/standards/techs/js>.

MOBILIDADE DIGITAL APLICADA AO GOVERNO BRASILEIRO

Figura 2: Viso geral de arquitetura para contedo web mvel.

ALISSON WILKER ANDRADE, RONALDO AGRA, VIVIANE MALHEIROS

MOBILIDADE DIGITAL APLICADA AO GOVERNO BRASILEIRO

ALISSON WILKER ANDRADE, RONALDO AGRA, VIVIANE MALHEIROS

<https://github.com/jquery/jquery-mobile>. Sigla em ingls para Content Management System.

MOBILIDADE DIGITAL APLICADA AO GOVERNO BRASILEIRO

Figura 3: Viso geral de arquitetura para aplicao nativa mvel.

ALISSON WILKER ANDRADE, RONALDO AGRA, VIVIANE MALHEIROS

MOBILIDADE DIGITAL APLICADA AO GOVERNO BRASILEIRO

ALISSON WILKER ANDRADE, RONALDO AGRA, VIVIANE MALHEIROS

MOBILIDADE DIGITAL APLICADA AO GOVERNO BRASILEIRO

ALISSON WILKER ANDRADE, RONALDO AGRA, VIVIANE MALHEIROS

MOBILIDADE DIGITAL APLICADA AO GOVERNO BRASILEIRO

ALISSON WILKER ANDRADE, RONALDO AGRA, VIVIANE MALHEIROS

Figura 5: Fluxo de deciso para escolha da arquitetura.

MOBILIDADE DIGITAL APLICADA AO GOVERNO BRASILEIRO

ALISSON WILKER ANDRADE, RONALDO AGRA, VIVIANE MALHEIROS

MOBILIDADE DIGITAL APLICADA AO GOVERNO BRASILEIRO

ALISSON WILKER ANDRADE, RONALDO AGRA, VIVIANE MALHEIROS

MOBILIDADE DIGITAL APLICADA AO GOVERNO BRASILEIRO

ALISSON WILKER ANDRADE, RONALDO AGRA, VIVIANE MALHEIROS

Figura 7: Utilizao do SIESC Mobile para efetuar uma medio de contrato.

MOBILIDADE DIGITAL APLICADA AO GOVERNO BRASILEIRO

ALISSON WILKER ANDRADE, RONALDO AGRA, VIVIANE MALHEIROS

MOBILIDADE DIGITAL APLICADA AO GOVERNO BRASILEIRO

ALISSON WILKER ANDRADE, RONALDO AGRA, VIVIANE MALHEIROS

MOBILIDADE DIGITAL APLICADA AO GOVERNO BRASILEIRO

ALISSON WILKER ANDRADE, RONALDO AGRA, VIVIANE MALHEIROS

Mobilidade digital: tecnologias e tendncias Djamel F. H. Sadok

MOBILIDADE DIGITAL: TECNOLOGIAS E TENDNCIAS

Figura 1: Mobilidade Internet versus Sistema Celular.

Figura 2: Arquitetura HIP da Internet do Futuro.

MOBILIDADE DIGITAL: TECNOLOGIAS E TENDNCIAS

Figura 3: Macro e microclulas para Alta Mobilidade.

Figura 4: Micromobilidade no Celular IP (CIP).

MOBILIDADE DIGITAL: TECNOLOGIAS E TENDNCIAS

Figura 5: Exemplo de uso de uma Femtocell.

Figura 6: 802.21 Mobilidade Independente da Tecnologia sem Fio Empregada.

MOBILIDADE DIGITAL: TECNOLOGIAS E TENDNCIAS

Figura 7: O Papel do DHT na Mobilidade.

Figura 8: Arquitetura e Protocolo OpenFlow.