19
ANAIS DO WPEIF 2015
ANAIS DO WPEIF 2015
WPEIF2015 Welcome Message
We have come a long way since the first edition of WPEIF, in SBRC 2010, in Gramado/RS.At that time, the term software-defined networking (SDN) had not yet been coined andonly a handful of researchers in Brazil knew about OpenFlow, let alone those capableof developing of OpenFlow applications or technology. We realized SDN and OpenFlowwould be key to anyone interested in investigating future Internet technology, approachesand solutions and, thus, held a tutorial on SDN and OpenFlow taught by the creators ofOpenFlow, from Stanford University. The response from the community was very positiveand crystal clear.
We held WPEIF again in 2011 and given the positive feedback from the commu-nity we kept holding WPEIF year after year as part of the SBRC workshop programme.Throughout the years we have both fostered and testimonied the networking communityfrom the academy and the industry engage in SDN, OpenFlow and Future Internet froman experimental research mindset and attitude. We have also seen the insurgence of someinfrastructures for the experimentation of future Internet and SDN, such as FIBRE -Future Internet testbed/experimentation between BRazil and Europe.
As we reach the sixth edition of WPEIF in this year’s SBRC, it has become evident thatSDN, OpenFlow and future Internet are now mainstream in SBRC. We believe WPEIFhas positively contributed to this situation and, therefore, delivered on its promisses andmet its purpose of promoting and fostering future Internet experimental research, infras-tructures for experimentation of future Internet proposals and collaborations with localand international peers in the topic.
We have always tried to match WPEIF’s program with the level of maturity of thecommunity. As such, this year’s edition of WPEIF focuses on experiences from the com-munity in developing future Internet SDN technology and applications and in using someof the state-of-the-art large-scale infrastructures for experimental research.
We wish you a pleasant and constructive WPEIF in Vitoria. See you soon.Thanks a lot!
Marcos Rogerio Salvador (Lenovo)
Michael Stanton (RNP)
INDICE
Uma Implementacao do Anycast IPv6 Usando o Click Modular Router 1Gustavo Bassil Heimovski (UPPR), Elias P. Duarte Jr. (UFPR)
Deployment and Experimentation of the Entity Title Architecture at OFELIA Testbed:Learned Lessons Revealed 5Natal Neto (UFU), Caio Ferreira (UFU), Maurıcio A. Goncalves (UFU), Flavio deOliveira Silva (UFU), Joao Henrique de Souza Pereira (UFU), Pedro Frosi Rosa(UFU), Sergio Takeo Kofuji (USP), Carlos Guimaraes (Universidade de Aveiro),Daniel Corujo (Universidade de Aveiro), Augusto Neto (Universidade de Aveiro),Rui Aguiar (Universidade de Aveiro)
Proposta de Administracao de Redes Definidas por Software Usando um Banco deDados em Grafo 9Pedro M. Salvador (UFPA), Izabelly M. A. Peres (UFPA), Fernando N. N. Farias(UFPA), Antonio J. G. Abelem (UFPA)
NovaGenesis: Convergent Information Architecture 13Antonio M. Alberti (INATEL), Lucio H. de Oliveira (INATEL), Marco A. F. Casaroli(INATEL)
Uma Implementacao do Anycast IPv6 Usando o ClickModular Router
Gustavo Bassil Heimovski1,Elias P. Duarte Jr1
1Departamento de Informatica – Universidade Federal do Parana (UFPR)Caixa Postal – – Curitiba – PR – Brazil
Abstract. This paper describes an implementation of anycast using IPv6 proto-col on a router implemented in software, called Click Modular Router. Anycastis a communication strategy in which a group of different hosts that providethe same service has the same network address. In anycast, the packets arerouted to the nearest host according to the routing protocol. The Click Modu-lar Router or simply Click, is a software that implements the functionality of acommon router, packet classification, queuing, and forwarding. An experimentis reported in which we evaluated the flow of packets to the routers, in particularthe overhead was measured to compare anycast with unicast.
Resumo. Este trabalho descreve uma implementacao de anycast usando o pro-tocolo IPv6 em um roteador implementado em software, denominado ClickModular Router. O anycast e uma estrategia de comunicacao onde um grupode hosts diferentes que prove um mesmo servico possui o mesmo endereco derede. No anycast, os pacotes sao encaminhados para o host mais proximo deacordo com o protocolo de roteamento. O Click Modular Router, ou simples-mente Click, e um software que implementa as funcionalidades de um roteadorcomum, incluindo encaminhamento, classificacao e enfileiramento de pacotes.No experimento foi avaliada a vazao de pacotes no roteador, em particular foimedida a sobrecarga do anycast em comparacao a comunicacao unicast.
1. Introducao
Este trabalho tem como objetivo descrever um experimento realizado com o Click Mod-ular Router [KOHLER 2000], ferramenta importante no contexto de pesquisa na Internetdo Futuro. Uma das propostas para a Internet do Futuro e a ‘programabilidade’ de redes,que e a insercao de novas funcionalidades e servicos sem necessidade de substituicao dainfraestrutura de rede.E especificamente neste contexto que o Click surge.
O Click Modular Router e um roteador baseado em software e implementa atravesde modulos as funcionalidades de um roteador comum, tais como classificacao de pacotes,escalonamento, enfileiramento e a interface com dispositivos da rede. A arquitetura doClick e baseada em modulos chamados elementos, que sao blocos de codigo que imple-mentam as funcionalidades do roteador. Os elementos sao organizados na forma de umgrafo que descreve o caminho dos pacotes no roteador Click.
Na literatura, diversos trabalhos tem sido reportados do uso do Click para imple-mentar solucoes inovadoras de roteamento e servicos de rede. Em [CERRONI et al. 2010]
1
o Click e utilizado para implementar uma arquitetura flexıvel para roteadores oticos pro-gramaveis. A estrategia implementada e baseada em emulacao dos componentes doroteador otico, incluindo a matriz de comutacao e os modulos de controle. Sao repor-tados resultados experimentais que demonstram a viabilidade da proposta, que permitiriaa implementacao neste tipo de rede de servicos da Internet do Futuro.
Outro trabalho que utiliza o Click e [KIM et al. 2008], que descreve uma arquite-tura de rede chamada SEATTLE. Esta arquitetura combina caracterısticas da rede IP – emparticular o fato de ser escalavel – com a simplicidade da Ethernet para criar uma redede facil gerenciamento e operacao que prove roteamento escalavel auto-configuravel. OClick foi usado para implementar o plano de dados do SEATTLE, incluindo o processa-mento de pacotes.
No experimento implementado com o Click Modular Router foi utilizada a es-trategia de comunicacao anycast, que permite que um mesmo endereco de rede seja uti-lizado para identificar um grupo de hosts diferentes [WEBER and CHENG 2004]. Noanycast, os pacotes sao encaminhados para o host mais proximo de acordo com o proto-colo de roteamento. A utilizacao do anycast tem algumas possıveis vantagens, tais como:melhora no tempo de resposta de uma aplicacao, pois o servidor e o cliente estao maisproximos, aumento da disponibilidade e confiabilidade do servico, uma vez que, este pos-sui servidores redundantes, alem de distribuicao de carga entre os servidores.
A implementacao do anycast usando o Click Modular Router tem como basea criacao de uma estrutura de dados que representa um grupo, nela esta representadoo IPv6 [DEERING and HINDEN 1998] do grupo, assim como um conjunto de servi-dores individuais. Cada servidor possui seu proprio endereco unicast IPv6, assim comodistancia para o cliente, sendo esta calculada dinamicamente no recebimento de um pa-cote. No calculo da distancia foram utilizadas duas metricas, a primeira delas e a de menordistancia em hops e a outra e calculada atraves do RTT (Round-Trip Time). No trabalhosao reportados resultados de um experimento, que e a verificacao da vazao de pacotes noroteador Click utilizando-se pacotes unicast em um cenario e em outro somente pacotesanycast.
O trabalho esta estruturado em quatro secoes, descritas a seguir. Na proxima secaoe descrita a implementacao do anycast IPv6 no Click. Na secao 3 sao apresentados osresultados experimentais e na secao 4 e feita uma conclusao do trabalho e sao comentadosalguns possıveis trabalhos futuros.
2. Implementando Anycast IPv6 no ClickA arquitetura do roteador Click e baseada em modulos chamados elementos, que sao blo-cos de software escritos em C++ que implementam varias operacoes de um roteador. Esteselementos que compoem um roteador sao organizados na forma de um grafo direcionadoque descreve o caminho percorrido pelos pacotes no roteador. Os vertices do grafo sao oselementos propriamente ditos; um elemento realiza alguma funcao no momento em queo pacote passa por ele. As arestas sao as conexoes entre estes elementos. Um exemplode configuracao do Click e a seguinte [cli ]: FromDevice(eth0) → Counter → Discard.Esta configuracao recebe pacotes da interface de rede eth0 atraves do elemento FromDe-vice, em seguida armazena as informacoes de numero de pacotes e bytes recebidos com oelemento Counter, e por ultimo, descarta os pacotes com Discard.
2
Para a implementacao do anycast IPv6 no Click foi criado um elemento doClick denominado IP6AnycastTable que funciona como uma tabela de roteamento paraenderecos anycast. A tabela e uma estrutura que possui o endereco IPv6 do grupo e osservidores pertencentes ao grupo. Cada servidor possui o seu proprio endereco unicastIPv6 e sua distancia para o cliente, sendo esta calculada dinamicamente no recebimento deum pacote. A tabela foi criada no proprio elemento IP6AnycastTable devido a limitacaodo Click em suas tabelas de roteamento, as quais nao possuem distancias em suas en-tradas. No Click tambem nao esta implementado um protocolo de roteamento. Destemodo, nao foi possıvel fazer uma implementacao padrao do anycast, onde o responsavelpela atualizacao das rotas na tabela de roteamento e o protocolo de roteamento.
Para o calculo das distancias aos membros do grupo anycast foram escolhidasduas metricas. A primeira metrica e a menor distancia em hops, calculada atraves daferramenta traceroute, encontrada em um sistema Linux. A segunda metrica e baseada noRTT, mas usa aleatoriedade em seus dados, ao inves de realizar uma estimativa baseadano historico de tempos de transmissao entre a origem e o destino.
O funcionamento basico do anycast no Click e o seguinte: qualquer pacote quechega no roteador Click e encaminhado para o modulo anycast. Neste modulo ha averificacao se o endereco de destino do pacote IP e igual ao endereco de um dos gruposanycast previamente configurados. Se forem iguais, sao calculadas as distancias para osservidores pertencentes ao grupo anycast e e selecionado o nodo com a menor distancia.O destino do pacote original e reescrito para o endereco unicast desse nodo de menordistancia e encaminhado pelo roteador para a interface de rede correta. Se o enderecode destino do pacote original nao for igual a nenhum dos grupos anycast, o pacote eencaminhado por uma outra interface para a tabela de roteamento padrao do Click.
3. Resultados experimentais
Nesta secao e descrito um experimento, que faz a verificacao da vazao de pacotes doroteador Click usando o anycast, tendo em vista, a observacao da sobrecarga do anycastem comparacao a comunicacao unicast.
A geracao de todos os pacotes dos testes foi realizada atraves do elemento Infinite-Source do Click e a interface utilizada para os testes foi a loopback de um sistema Linux.A interface loopback foi configurada com 20 enderecos IPv6, de ::1 a ::20. Os pacotestinham o tamanho de 64 bytes. Todos os testes realizados utilizaram a metrica de rotea-mento RTT porque se fosse utilizada a outra metrica, o numero de hops seria o mesmo,no caso 1, assim nao seria possıvel ver a distribuicao de pacotes entre os hosts.
O experimento realizado foi o de vazao de pacotes no roteador Click usandocomunicacao unicast e anycast. Foram executados testes para 10.000, 100.000 e ummilhao de pacotes. Os resultados sao mostrados na figura 1.
Fazendo a comparacao entre os dois testes - unicast e anycast - nota-se que odesempenho da comunicacao unicast e melhor; em media a vazao unicast ficou cercade 1,85 vezes maior. Este resultado era o esperado, pois, a implementacao do anycastutiliza uma tabela que a cada pacote deve ser consultada, resultando em um tempo deprocessamento maior.
3
Figure 1. Razao entre numero de pacotes unicast e anycast e tempo para pro-cessamento no roteador.
4. ConclusaoNeste trabalho foi apresentada uma implementacao da estrategia anycast usando o ClickModular Router. O Click e um roteador baseado em software que se encaixa no cenario de‘programabilidade’ de redes, permitindo a experimentacao com protocolos de roteamentoe de infraestrutura de rede, sem necessidade de mudanca na estrutura de rede fısica. Foirealizado um experimento para observacao da sobrecarga do anycast em comparacao acomunicacao unicast, sendo que esta apresentou uma vazao 1.85 vezes maior. Ha diversostrabalhos futuros possıveis, relacionados a ‘programabilidade’ de redes no contexto daInternet do Futuro. A ‘programabilidade’ permite a insercao de novos servicos criadospelos usuarios na rede, o que estende e ‘customiza’ a rede de acordo com as necessidadesdas aplicacoes.
ReferencesClick Modular Router. Disponıvel em : <http://read.cs.ucla.edu/click/click>. Acesso em
marco de 2015.
CERRONI, W., RAFFAELLI, C., and SAVI, M. (2010). Software emulation of pro-grammable optical routers. 11th IEEE International Conference on High PerformanceSwitching and Routing (HPSR).
DEERING, S. and HINDEN, R. (1998). Internet Protocol, Version 6 (IPv6) Specification.RFC 2460.
KIM, C., CAESAR, M., and REXFORD, J. (2008). Floodless in seattle: A scalableethernet architecture for large enterprises. SIGCOMM.
KOHLER, E. (2000). The Click Modular Router. Ph.D. Thesis, MIT.
WEBER, S. and CHENG, L. (2004). A survey of anycast in ipv6 networks. Communica-tions Magazine, IEEE, 42(1):127 – 132.
4
Deployment and Experimentation of the Entity TitleArchitecture at OFELIA Testbed: Learned Lessons Revealed
Natal Neto1, Caio Ferreira1, Maurıcio A. Goncalves1, Flavio de Oliveira Silva1,Joao Henrique de Souza Pereira1, Pedro Frosi Rosa1, Sergio Takeo Kofuji2,
Carlos Guimaraes3,Daniel Corujo3, Augusto Neto3, Rui Aguiar3
1Faculdade de Computacao (FACOM) – Universidade Federal de Uberlandia (UFU)Caixa Postal 593 – 38.400-902 – Uberlandia, MG – Brasil
2Escola Politecnica da USP (EPSUP) – Universidade de Sao Paulo (USP)Caixa Postal 61.548 – 05.424-970 – Sao Paulo, SP – Brasil
3Instituto de Telecomunicacoes – Universidade de AveiroCampus Universitario de Santiago - P-3810-193 – Aveiro, Portugal
[email protected],[email protected]
{flavio,,joaohs,pfrosi}@ufu.br,[email protected]
{cguimaraes, dcorujo, augusto, ruilaa}@av.it.pt
Abstract. Usually the published material about a research project presents thetechnical challenges, the work conducted and the results from the technical pointof view. This work reveals the learned lessons during our participation at theOFELIA project. This different perspective provided from the research con-tributes with the community by presenting the key success factors which enabledthe achievement of the proposed objectives and other important outcomes.
1. IntroductionIn 2006 a professor and some students started to think about a new type of net-working, capable of providing the communication requirements of users and appli-cations. At the end of 2009, a vision about how to accomplish this was proposed[de Souza Pereira et al. 2009]. However, to bring this vision to life it was necessary toface several challenges. At the same time, the OpenFlow [McKeown et al. 2008] Specifi-cation version 1.0.0 was published [McKeown et al. 2009].
During 2010, we concluded that our vision of networking has a natural matchwith Software Defined Networking (SDN) [Greene 2009]. Since then, our research groupdeepened into OpenFlow and SDN. At 2011, during the II WPEIF we proposed the Do-main Title System (DTS) [Silva et al. 2011]. At that time, the most viable way to experi-ment these ideas was to use Mininet [Lantz et al. 2010]. In September, 2011, a proposal toexperiment the DTS at OFELIA test bed [OFELIA 2011] was selected during the MyFireContest [MyFire 2011]. Thus it was possible to use an OpenFlow based infrastructure togo further in our research.
By using this new bridge built with Europe, the Extending and Deploying OFE-LIA in Brazil (EDOBRA) proposal was prepared and accepted [OFELIA 2012], then wejoined the OFELIA project as partners. As a result there is currently an OFELIA Islandat Uberlandia.
5
This work reveals the research work from a different perspective and present thelearned lessons during enhancement and the use of the OFELIA experimental facility.
This paper briefly presents, at Section 2, the work conducted under the EDO-BRA work package inside of the OFELIA project. Section 3 presents some concludingremarks.
2. Extending and Deploying OFELIA in Brazil (EDOBRA)The EDOBRA work package had four challenging objectives: i) provide mobility controlmechanisms for OpenFlow Openwrt software switches [Guimaraes et al. 2013]; ii) ex-tend the Entity Title Architecture (ETArch) [de Oliveira Silva et al. 2012], a clean-slatenetwork architecture based on a OpenFlow substrate to be fully integrated with the IEEE802.21 protocol in order to support seamless multicast and mobility [Silva et al. 2013][Guimaraes et al. 2014]; iii) increase the physical extension of OFELIA by deploying anew island in Brazil and iv) carry out multicast and mobility experiments at OFELIAusing the results of the previous objectives [Guimaraes et al. 2014].
Figure 1. Resultant OFELIA Tesbed after EDOBRA Work Package
The team was composed by the Instituto de Telecomunicacoes (IT), from Aveiro,Portugal; the University of Sao Paulo (USP) and the Federal University of Uberlandia(UFU). The work package had seven different deliverables to be accomplished in oneyear project and three objectives where in the critical path.
In order to achieve the objectives, to handle and provide response to risks, man-agement tools where essential during the project. Weekly meetings helped the projectmonitoring and control and several risk mitigation actions where executed during workpackage.
Another key factor to the work package was the team. Everybody was focusedon the objectives and the members were always ready to help and share tasks when nec-essary. One previous action, revealed important in the end: before the project start, one
6
member from UFU spent one extra month at Aveiro and this period was important to laythe cornerstone of a strong partnership.
One challenging task was federation between the OFELIA island at UFU andUBristol, at Europe. A dedicated circuit between these institutions were created. Thesetup of the circuit demanded extensive communication by email and meetings betweenthe different involved institutions (UFU, ALGAR Telecom, CPqD, RNP, AMPATH, IN-TERNET2 and JANET). The planning and deployment of the circuit took about fourmonths and it was necessary to execute several tests of this connectivity considering indi-vidual network managers and specific configurations at each hop of circuit.
The deployed island at UFU enabled several experiments, as planned by theEDOBRA work package. By using the infrastructure at UFU, it was possible to con-duct several tests regarding ETArch, especially the ones related with multicast and mo-bility, which considered novel application scenarios that were enabled by ETArch andby the exploitation of the media-independent mobile concepts in wireless environments[Guimaraes et al. 2014].
3. Concluding RemarksDespite its challenges, the EDOBRA work package achieved its objectives and providethe planned deliveries. The software components of the DTS, i.e., the Domain Title Ser-vice Agent (DTSA) were completely re-factored and a new SDN research project was anoutcome [Ferreira et al. 2014]. Besides that, new parters start a work to improve ETArchby adding QoS extensions [Silva et al. 2014] [Castillo et al. 2014]. Moreover, the solidfoundation created allowed ETArch to follow the road ahead.
Management tools, weekly meetings by video conference, a team focused on theobjectives and ready to help each other were some of the key success factors of the EDO-BRA work package.
Collaboration between different research groups with complementary expertise isfundamental in this research area. Build strong teams in Brazil, focusing on researchand experimentation will enhance the impact of our work and will allow us, as researchcommunity, be protagonist in this way towards the Future Internet.
References[Castillo et al. 2014] Castillo, J., Silva, F., Neto, A., Silva, F., Frosi, P., Guimaraes, C.,
Corujo, D., and Aguiar, R. (2014). Evolving Future Internet Clean-Slate Entity Ti-tle Architecture with Quality-Oriented Control Plane Extensions. pages 161–167.
[de Oliveira Silva et al. 2012] de Oliveira Silva, F., Goncalves, M., de Souza Pereira, J.,Pasquini, R., Rosa, P., and Kofuji, S. (2012). On the analysis of multicast traffic overthe Entity Title Architecture. In 2012 18th IEEE International Conference on Networks(ICON), pages 30–35.
[de Souza Pereira et al. 2009] de Souza Pereira, J., Kofuji, S., and Rosa, P. (2009). Hori-zontal address ontology in internet architecture. In New Technologies, Mobility andSecurity (NTMS), 2009 3rd International Conference on, pages 1 –6.
[Ferreira et al. 2014] Ferreira, C. C., Neto, N., Mota, A., Silva, F. d. O., Pereira, J. H.d. S., Neto, A., Corujo, D., Guimaraes, C., Rosa, P. F., Kofuji, S. T., and Aguiar, R.
7
(2014). Towards a Carrier Grade SDN Controller: Integrating OpenFlow with TelecomServices. In The Tenth Advanced International Conference on Telecommunications(AICT), Paris. IARIA.
[Greene 2009] Greene, K. (2009). TR10: Software-Defined networking. MIT TechnologyReview, 112(2).
[Guimaraes et al. 2014] Guimaraes, C., Corujo, D., Silva, F. d. O., Rosa, P. F.,Venancio Neto, A. J., and Aguiar, R. L. (2014). IEEE 802.21-enabled Entity TitleArchitecture for Handover Optimization. In 2014 IEEE Wireless and Communicationsand Networking Conference, Piscataway, NJ:. IEEE.
[Guimaraes et al. 2013] Guimaraes, C., Corujo, D., Aguiar, R. L., Silva, F. d. O., and Rosa,P. (2013). Empowering Software Defined Wireless Networks Through Media Inde-pendent Handover Management. In Globecom 2013 - Next Generation NetworkingSymposium (GC13 NGN), Atlanta, USA.
[Lantz et al. 2010] Lantz, B., Heller, B., and McKeown, N. (2010). A network in a lap-top: rapid prototyping for software-defined networks. Proceedings of the Ninth ACMSIGCOMM Workshop on Hot Topics in Networks, page 19:1–19:6. ACM ID: 1868466.
[McKeown et al. 2008] McKeown, N., Anderson, T., Balakrishnan, H., Parulkar, G., Peter-son, L., Rexford, J., Shenker, S., and Turner, J. (2008). OpenFlow: enabling innova-tion in campus networks. SIGCOMM Comput. Commun. Rev., 38(2):69–74. ACM ID:1355746.
[McKeown et al. 2009] McKeown, N., Pfaff, B., Heller, B., Talayco, D., Erickson, D., Gibb,G., Appenzeller, G., Tourrilhes, J., Pettit, J., Yap, K., Casado, M., Kobayashi, M.,Balland, P., Price, R., Sherwood, R., and Yiakoumis, Y. (2009). OpenFlow SwitchSpecification. Version 1.0.0.
[MyFire 2011] MyFire (2011). MyFire Contest. http://www.my-fire.eu/contest.
[OFELIA 2011] OFELIA (2011). OpenFlow in europe - linking infrastructure and applica-tions. http://www.fp7-ofelia.eu/about-ofelia/.
[OFELIA 2012] OFELIA (2012). OFELIA second open call for OpenFlow experi-ments success and new partners. http://www.fp7-ofelia.eu/news-and-events/press-releases/ofelia-2nd-open-call-success/.
[Silva et al. 2013] Silva, F. d. O., Corujo, D., Guimaraes, C., Pereira, J. H. d. S., Rosa, P.F. R., Kofuji, S. T., and Aguiar, R. (2013). Enabling Network Mobility by UsingIEEE 802.21 Integrated with the Entity Title Architecture. In Anais do IV Workshopde Pesquisa Experimental na Internet do Futuro (WPEIF), pages 29–34, Brasılia. So-ciedade Brasileira de Computacao.
[Silva et al. 2011] Silva, F. d. O., Pereira, J. H. d. S., Kofuji, S. T., and Rosa, P. F. (2011).Domain title service for future internet networks. In Anais do II Workshop de PesquisaExperimental na Internet do Futuro (WPEIF), Campo Grande. SBC.
[Silva et al. 2014] Silva, F. S. D. d., Lema, J. C., Neto, A. J., Silva, F. d. O., Rosa, P. F.,Corujo, D., Guimaraes, C., and Aguiar, R. (2014). Entity Title Architecture ExtensionsTowards Advanced Quality-oriented Mobility Control Capabilities. In 19th IEEE Sym-posium on Computers and Communications (IEEE ISCC 2014), Madeira, Portugal.
8
Proposta de Administração de Redes Definidas por Software Usando um Banco de Dados em Grafo1
Pedro M. Salvador1, Izabelly M. A. Peres1, Fernando N. N. Farias1, Antônio J. G. Abelém1
1 Grupo de Estudos em Redes de Computadores e Comunicação Multimídia Instituto de Informática – Universidade Federal do Pará (UFPA)
[email protected],{marrianny,fernnf,abelem}@ufpa.br
Abstract. Current SDN controllers still stores their data in a traditional manner, using relational databases, however this organization is not gainful to the controller or to the networking itself. This paper introduces a proposal for modeling and administrating SDN using a graph-oriented database. The network's abstraction data in the graph database represents its own global view, using graph concepts such as nodes and relationships. Additionally, the data stored by the controller in this approach preserves the data plane's view within these relationships, enabling economy of scale in the control plane usage, facilitating the search for the SDN information.
Resumo. Os atuais controladores SDN ainda usam maneiras tradicionais de armazenar seus dados, utilizando banco de dados relacionais. No entanto, sua organização não traz vantagens ao controlador e tão pouco a rede em si. O presente estudo apresenta uma proposta de modelagem e administração de redes SDN usando banco de dados baseado em grafos. Desta maneira, os dados das abstrações da rede no banco representam sua própria visão global, usando os mesmos conceitos de grafo, tais como nós e relacionamentos. Adicionalmente, os dados armazenados nesta proposta são incorporados no controlador, preservando a visão contida no plano de dados dentro de relacionamentos entre os nós do grafo, permitindo a economia nos recursos do plano de controle e facilitando a localização e extração de informações da rede SDN.
1. Introdução Nas redes definidas por software (SDN), diversos aplicativos e serviços de gerenciamento de redes necessitam de uma visão topológica da rede e da recuperação de informações vinculadas a esta, por exemplo, roteamento por políticas, listas de Controle de Acesso e Qualidade de Serviço. Em casos cuja quantidade de informação produzida é muito grande, há a necessidade de armazenar os dados, sem deixá-los diretamente em memória, com o objetivo de evitar problemas de escalabilidade com o controlador, principalmente os que trabalham no modelo de cluster. Em tais situações, costuma-se armazenar as informações em banco de dados. Por outro lado, modelos tradicionais baseados em banco de dados relacionais não oferecem a eficiência necessária, principalmente pelo limitado grau de correlação entre os dados e pela dificuldade de se adaptar rápida e completamente a diferentes cenários de aplicações.
Neste contexto, os bancos de dados não relacionais, denominados “No SQL”, vêm se tornando as alternativas mais utilizadas para resolver tais problemas. Com ênfase, menciona-se o modelo baseado em grafos (GDM – Graph Database Model), primeiramente por ser apontado como o mais eficiente e robusto para armazenar, gerenciar e atualizar dados e relacionamentos
1 Agradeçemos ao Serviço Federal de Processamento de Dados (SERPRO) pela a realização deste trabalho através do Projeto “Convênio entre o SERPRO e a Universidade Federal do Pará (UFPA) para a realização conjunta de pesquisa científico-tecnológica baseada em software livre aplicada em redes de computadores para governo eletrônico”.
9
(JOUILI e VANSTEENBERGHE, 2013); posteriormente, por utilizar a teoria de grafos para representar as relações dentro do banco que, atualmente, é muito utilizado para modelar as redes de computadores de maneira natural, direta e precisa, cujo emprego é prática comum em aplicações de gerência de redes, inclusive voltadas para SDN, como descrito por (PANTUZA, SAMPAIO, et al., 2014) e (RAGHAVENDRA, LOBO e LEE, 2012).
O modelo supracitado se adequa perfeitamente aos problemas de gerenciamento e armazenamento de dados existentes nas redes definidas por software. A própria visão do modelo de armazenamento de dados ou de relacionamentos é semelhante à visão topológica da rede, auxiliando na solução de outros problemas (p. ex. spanning tree, learning Switch, redes virtuais/overlay ou roteamento). Além disso, cada elemento (p. ex. arestas ou vértices) do grafo pode ter informações ou propriedades relacionadas a ele, enriquecendo a forma de consultas ou buscas dentro do grafo. Adicionalmente, outra vantagem que este modelo traz para as SDNs é o auxílio à busca e descoberta de recursos, sem a necessidade de acessar os equipamentos diretamente, utilizando-se apenas a visão do grafo armazenado pelo banco de dados.
O presente estudo propõe a abordagem de gerenciamentos de SDNs através do emprego de banco de dados baseadas em grafos, integrando características do banco de dados e teoria de grafos, cujo intuito é auxiliar na escalabilidade, tanto no crescimento da rede como no gerenciamento da grande quantidade de dados gerados. Ademais, o presente estudo contribui com arquitetura e modelagem do banco de dados em grafo, tais como, relacionamentos, nós e propriedades, aplicadas a uma rede SDN.
A estrutura do presente estudo é composta de introdução e mais três seções. Na Seção 2, são apresentados os trabalhos relacionados ao uso de grafos para administração de SDNs. Na Seção 3, descreve-se a proposta, definindo a representação de banco de dados de grafos, a arquitetura da proposta e a modelagem do banco para redes SDN. Finalmente, a Seção 4 apresenta a conclusão e perspectivas para trabalhos futuros.
2. Trabalhos Relacionados Raghavendra et al. (2012) propõem a utilização de grafos para auxiliar na tomada de decisão em redes SDN. Adicionalmente, os autores desenvolveram uma API, que fornece queries dentro do grafo, e buscas de rotas. Apesar de simplificar a gerência das redes SDN, a proposta não guarda qualquer informação da rede integrada ao grafo, que poderia enriquecer sobremaneira a utilização da API.
Patuza et al., (2014) também abordam a simplificação da gerência de redes SDN com o uso de grafos. Paralelamente ao trabalho anterior, os autores aplicam a utilização do modelo em um controlador SDN. Os autores apenas mantêm uma visão topológica da rede, na qual não integram os dados ao seu grafo, fato que limita as possibilidades de buscas no grafo. Observou-se também que a proposta tem a fragilidade de manter tudo em memória, a qual pode sofrer com sérios problemas de escalabilidade.
Dentro de cenário apresentado, observa-se que os trabalhos relacionados apresentam o uso de teoria de grafos como uma boa solução para simplificação da gerência em redes SDN, porém não se observa preocupação com o crescimento da rede e a quantidade de informação gerada.
3. Proposta
3.1. Definição de banco de dados baseado em grafo Um banco de dados de grafos é um modelo definido como grafo com propriedades, que é basicamente um grafo direcional, composto por arestas rotuladas, atributos e multigrafo, representado por:
10
𝐺 = 𝑉, 𝐼,𝜔,𝐷, 𝐽, 𝛾,𝑃,𝑄,𝑅, 𝑆 (1) Onde, 𝑉 é o conjunto de vértices, 𝐼 é o conjunto de identificadores dos vértices,
𝜔:𝑉 → 𝐼 é uma função que associa cada vértice a um identificador, 𝐷 é um conjunto de arestas direcionais, 𝐽 é um conjunto de identificadores de cada aresta, 𝛾:𝐷 → 𝐽 é a função que associa cada aresta a um identificador, 𝑃 é o domínio de atributos dos vértices, 𝑄 é o domínio de valores de atributos permitidos dos vértices, 𝑅 é domínio de atributos das arestas e 𝑆 é o domínio de valores de atributos permitidos das arestas.
Atualmente, pode-se destacar o Neo4j2 como principal referência de banco de dados em grafo, o qual segue o modelo definido na Equação 1. As principais vantagens são: a possibilidade de transações concorrentes; oferecer garantias ACID (Atomicidade, Consistência, Isolamento e Durabilidade); e uma graph query language (Cypher).
3.2. Arquitetura da Proposta A arquitetura proposta, ao presente estudo, segue o modelo de camadas do SDN, dividindo-as em dados, controle, gerenciamento e aplicação. Desta maneira, a proposta tem seus componentes localizados na camada de gerenciamento, distinguindo-se de outros controladores, que apresentam a camada de persistência localizada na camada de controle.
Figura 1. Arquitetura de integração com banco de dados de grafo
Seguindo este contexto, a proposta esta dividida em quatro módulos: monitor, javaAPI, Rest/Json API e topologia. Os módulos Java e Rest/Json API especificam as interfaces de integração das aplicações e outros módulos à manipulação de informações no banco de dados, dentre as quais tem-se o acesso aos nós e enlaces da topologia, a criação e remoção de nós e enlaces, cálculos de caminhos (com ou sem restrições) e envio de scripts baseado na linguagem cypher para buscas especializadas no banco. O módulo monitor coleta e atualiza as informações a respeito dos elementos da rede SDN, por exemplo, queda de um link, atualizações de portas (habilitar ou desabilitar), atualizações de estatísticas de portas ou atualizações do canal de controle. Finalmente, o módulo topologia GDB gerencia as inserções e remoções de dados do banco a partir dos demais módulos construídos, por meio da linguagem de consulta do próprio banco Neo4j, o cypher ou pela API Java, disponível pelo Neo4j.
A Figura 2 ilustra a modelagem inicial do banco e as suas propriedades, tanto dos nós como dos seus relacionamentos para redes SDN. Os relacionamentos estão divididos em tipos com propriedades simples (com apenas o ID), mas, a partir do crescimento do banco, elas poderão conter mais propriedades. No entanto, o relacionamento CONECTADO_A contém a propriedade “peso”, o qual é utilizado para especializar a prioridade da aresta. Ademais, os
2Projeto Neo4J. Disponível em: http://neo4j.com/
Aplicação ALTO
AplicaçãoDCN
AplicaçãoROUTE
Camada de Gerenciam
ento
Camada de Aplicação
Camada de controle
Camada de Dados
Java
API
Cyph
er
Lang
uage
Module Java Api
Monitors
Neo4J
OF SwitchOF Switch OF SwitchOF Switch OF Switch
Módulos de Controle
Topologia GDB
Device Manager HostTracer OFConnection
Module Rest/Json APIInterface
11
vértices, tal como as arestas, também possuem suas propriedades específicas, ilustradas na Figura 2. Finalmente, tem-se o meta modelo inicial do banco, que controla o modo como os nós e relacionamentos devem ser criados. Atualmente, ele possui apenas quatro nós, definidos como: Estatística (armazena medições relacionadas tanto a um comutador como a um fluxo), Comutador (representa um nó SDN), Cliente (pode ser um cliente ligado a uma porta do equipamento, uma sub-rede ou uma fronteira com outro domínio), e Fluxo (representa as informações dos fluxos contidos em cada comutador).
Figura 2. Modelagem do banco de dados de grafos para redes SDN
4. Conclusão e Trabalhos Futuros No presente estudo, apresenta-se uma proposta de aplicação de dois modelos - o banco de dados e a teoria de grafos - com o intuito de vencer o aumento na densidade do número de elementos de rede e, proporcionalmente, a quantidade de informações geradas pelo controlador e comutadores em uma rede SDN. Adicionalmente, a visão do banco GDM ainda pode ser utilizada para criar novos algoritmos de buscas, de modo que qualquer uma de suas propriedades podem ser utilizadas como critério de restrição, reforçando a flexibilização destes algoritmos.
Estabelece-se uma arquitetura, aplicando a sua integração dentro do modelo SDN, o qual pode ser aplicado posteriormente a um controlador. Atualmente, existe um protótipo inicial de implementação dessa arquitetura aplicado ao controlador Floodlight e, utilizando-se a versão 1.3 do protocolo OpenFlow.
Visando a obtenção de futuras contribuições, está em desenvolvimento a aplicação da proposta em um controlador SDN, da qual pretende-se colher resultados sobre o desempenho da rede a medida que ocorre o aumento do número de nós e relacionamentos. Almeja-se, pois, formular algoritmos baseados nas buscas de informações dentro do banco, além de permitir gerenciamento de políticas de redes vinculadas aos nós do grafo.
Referências JOUILI, S.; VANSTEENBERGHE, V. An Empirical Comparison of Graph Databases. 2013
International Conference on Social Computing (SocialCom). Alexandria, VA : IEEE. 2013. p. 708 - 715.
PANTUZA, G. et al. Network management through graphs in Software Defined Networks. 10th International Conference on Network and Service Management (CNSM). Rio de Janeiro: IEEE. 2014. p. 400 - 405.
RAGHAVENDRA, R.; LOBO, J.; LEE, K. Dynamic Graph Query Primitives for SDN-based Cloudnetwork Management. Proceedings of the First Workshop on Hot Topics in Software Defined Networks. Helsinki, Finland: ACM. 2012. p. 97-102.
Propriedade dos NósPropriedade dos Relacionamentos
Meta Modelo
ComutadorCONECTAD
O_A
Cliente
MEM
BRO
Fluxo
Estatística
CONTÊM
GERA
GERA
Comutador Propriedades
IDDPIDN° PortasTipo
Cliente Propriedades
IDTipoMACSub Rede
Máscara
Fluxo Propriedades
IDGrupoMatchStatusDuração
Estatística Propriedades
IDTipo
Pacotes
Bytes
Fluxo ID
GERA
CONTÊM
MEMBRO
CONECTADO_A PropriedadesID
Peso
PropriedadesID
PropriedadesID
PropriedadesID
12
NovaGenesis: Convergent Information Architecture
Antonio M. Alberti1, Lucio H. de Oliveira1, Marco A. F. Casaroli1
1ICT Lab - Instituto Nacional de Telecomunicacoes (INATEL)Joao de Camargo 510, Centro – CEP 37.540-000
Santa Rita do Sapucaı – MG – Brazil
{alberti,luciol}@inatel.br; [email protected]
Abstract. This paper reports the development of a “clean slate” convergentinformation architecture called NovaGenesis, which is aimed to integrate in-formation processing, exchanging, and storage. NovaGenesis synergisticallymerges emerging paradigms for information and communications technolo-gies (ICT), such as information-centric networking, service-centric networking,identifier/locator splitting, software-defined networking, network function virtu-alization, self-organizing networks, and Internet of things. The project startedin 2008 and has a proof of concept implemented in C++ programming languagefor Linux operating system. This paper quickly presents NovaGenesis prototype,giving details of adopted design choices and developed components. It describesour ongoing developments while integrating hot topics on ICT.
1. IntroductionThe Internet is undoubtedly one of the most important artifacts of human ingenuity. Itpermeates every aspect of our lives. It changed the way we communicate, work, and play.It is very important to the economy, especially for the third sector — service sector, whichaccounts for 70% of the gross domestic product on developed countries.
Today, there are thousands of application scenarios on the Internet, which greatlydiffer from the panorama in the 70’s. The Internet has changed from a substrate forend-to-end computers communication to massive content distribution. Now, mobile com-puting is the role, instead of fixed computers. Security and privacy should be provided forcontents, services, and networks. People want to access content and services irrespectiveof where they are. Network operators and content providers claim for more flexibility oncontrol and management of ICT resources, reducing human intervention and making eas-ier the introduction of new technologies on the infrastructure. Elasticity of network andcomputing resources is a major claim towards reducing operational costs. Users claimfor information architectures that can “understand” their intents and policies, being ableto reduce the gap between natural language (rich on expressiveness and semantics) andmachine language. Users claim for data integrity, provenance, and privacy. In fact, aspeople are increasingly using the Internet they are realizing its limitations to fulfill theneeds of our information society in the next decades.
Concerned with this reality, many researchers started wondering whether the cur-rent stack can support or not the multifaceted exponential growths we are experienc-ing today in number of devices, mobility, interactivity, content, and traffic. Concernedwith this situation, several initiatives emerged worldwide to reshape the Internet underthe banner of the so called “future Internet” (FI) design [Pan et al. 2011, Alberti 2013,
13
Alberti et al. 2012]. This includes evolutionary approaches, where the fundamental pro-tocols of the current Internet are maintained and where new ideas are introduced in-crementally; or revolutionary approaches, where the architecture is redesigned fromscratch. The revolutionary approaches are usually called as “clean-slate” architectures[Rexford and Dovrolis 2010]. The idea is to perform a more deep redesign — a revolu-tion on the Internet architecture. The argument is that some limitations on the Internet arefundamentally architectural. They can not be definitely solved by incremental patches.
With this perspective in mind, we are developing a new architecture called No-vaGenesis (NG1). NovaGenesis is a clean slate architecture to be universally applied. Itembraces not only content exchanging and distribution, e.g. Internet, transport networks,content-centric networks (CCN) [Jacobson 2011] or service-centric networking (SCN)[Wu et al. 2014], but also content processing and storage, e.g. cloud computing servicesand applications. NG is under the concept of a convergent information architecture(CIA), i.e. an ICT architecture that covers data processing, storage, and exchanging.
2. NovaGenesis Fundamental Concepts
2.1. Naming, Name Binding, and Name Resolution
Names are symbols used to denote one or more individual entities (or more broadly, ex-istences). In this case, to denote means to represent something by a set of symbols. Bydefinition, names denote meaning and sense. NovaGenesis adopts a generic naming struc-ture where any kind of names can be used. Not only self-verifying names (SVNs), butalso natural language names (NLNs) are allowed. It enables people to express intent usingNLNs, but improves security using SVNs. SVNs can be obtained via cryptographic hashfunctions. The binary input of the hash function can be the existence itself (e.g. computerprogram executable, source code, or information files) or other binary input related to theexistence being named (e.g. entities’ immutable attributes).
We define a name-binding (NB) as an additional entity that represents relation-ships among two or more existences by linking their names (NLNs and/or SVNs). Fre-quently, names are related to each other to capture relationships between underlying en-tities. In other words, the relationships among named-existences are represented by therelationships among their names. For example, the name of a street (“Esplanade”) canbe related to the name of a city (“Chico”). Relationships like “Esplanade” is containedby “Chico” can be used to represent relationships between named physical world entities.NG implements name resolution system (NRS) by searching in a distributed NBs graph(DNBG). Entities can query for NLNs and SVNs that are distributedly stored.
2.2. Publish, Subscribe, and Rendezvous
NovaGenesis employs a publish/subscribe communication model as an alternative for the“receiver accepts all” model used on the current Internet. To publish means to make avail-able some NB to possible peers, while to subscribe means to query for some publishedNB. The rendezvous is the process of authenticating and authorizing the subscriber ac-cording to the publisher’s instructions. NovaGenesis services can organize themselvesbased on names, name-bindings, and contracts to meet semantically rich goals and poli-cies. Every component of the architecture is offered to others by publishing several NBs.
1http://www.inatel.br/novagenesis/
14
The architecture adopts NBs to relate one name to several other related names. The NBsare structured in a [key, value(s)] format.
2.3. Services Structure
NovaGenesis named-services are virtual entities aimed at exchanging, processing, andstoring information in any computational substrate, which can be physical or virtual (over-lay or simulated). Therefore, named-services (using NLN and/or SVN) can be imple-mented as components inside a simulator, as object instances inside a physical or virtualcomputer operating system, or even as parallel processes in a physical hardware platform.
3. Proof-of-ConceptThe current implementation is based on four core services that implement content andservices life-cycling, pub/sub of NBs and content, and name-based routing over Linuxraw sockets (also supports TCP/UDP/IP socket for compatibility reasons):
• Hash table service (HTS) - It provides a distributed hash table that is used to storepublished NBs. It also stores NB-related content in a local directory.• Generic indirection resolution service (GIRS) - It aims to forward NBs to one or more
HTS instance(s). The current version has a fixed rule to select the proper HTS instancewhile storing a NB. It selects based on the binary pattern of the source name (key).Future versions will provide more intelligent storage, enabling GIRS instances to selectbased on locality, usage, load balancing, etc.• Publish/subscribe service (PSS) - It is the narrow waist for NG services. Any service
will use the pub/sub directives provided by the PSS distributed system. Services canpublish NBs and content to other services and subscribe other NBs of their interest.PSS also provides a notification function that notifies services about published NBs.A service that receives such notification, can immediately subscribe the informed NBkey. The PSS does the rendezvous among publisher and subscribers authenticating andauthorizing access to published NBs. The PSS enables services to securely expresstheir interests. The keys subscribed are encrypted and have their integrity checked.Therefore, privacy of content interest is granted.• Proxy/gateway service (PGS) - It aims to encapsulate NG messages over traditional
(or new) networking technologies. Therefore, it is a gateway for NG messages thatleave or enter the NG cloud. Additionally, the PGS is a proxy for other NG servicesinside some operating system (OS). It represents these services during bootstrapping,forwarding public name bindings to other friend PGSs. It opens and maintains socketsin the OS to enable NG messages encapsulation.
Inter service communication inside a host was implemented using shared mem-ory (usually know as interprocess communication), while service communication amonghosts was implemented using traditional Linux OS sockets (raw, TCP, or UDP sockets).Inside the NG services, all the communication is based on SVNs. However, during boot-strapping the processes use a well-know key to generate a shared memory ID. After afirst “hello” message, every service proposes a new key, that is linked to the process SVNand stored on a local hash table (HT). Every service initializes the communication to thelocal OS PGS. The inter service communication among hosts starts similarly. Every PGSis initialized with the MAC address of peer PGSs and sends a “hello” message for them.A binding between the PGS SVN and the legacy address is stored on a local HT of the
15
peer PGSs. Future versions will dispense legacy addresses, since all the required serviceswill have SVNs. Thus, the PGSs would store only SVN-to-SVN bindings at initializationprocedure. After the “hello” phase, the PGSs exchange the NBs they have. The coreservices can now discover possible peers by consulting the PGS HT on their local OS.If some service matches the NLN queries used, core services store locally the peer ser-vices’ SVNs. User applications use a pub/sub application programming interface (API)provided by the PSS. They are able to pub/sub NLNs and SVNs, discover candidate peers,establish contracts, and finally exchange named user information.
4. Concluding RemarksWe have successfully applied NovaGenesis architecture to software-defined networking(together with OpenFlow) on [Alberti et al. 2014]. We are also employing NovaGenesisservices to extend the cognitive radio scenario presented on [Raimundo-Neto et al. 2014].Experimental named-content distribution was investigated in 2013 and is under develop-ment. Future work include: (i) the design of a new software version; (ii) extension of NGservices to opportunistic and socially-driven networks; and (iii) scalability evaluation.
Acknowledgments
This work was partially supported by Finep/Funttel Grant No. 01.14.0231.00,under the Radiocommunication Reference Center (Centro de Referencia emRadicomunicacoes- CRR) project of the National Institute of Telecommunications (In-stituto Nacional de Telecomunicacoes - Inatel), Brazil.
ReferencesAlberti, A., de O Fernandes, V., Casaroli, M., de Oliveira, L., Pedroso, F., and Singh,
D. (2014). A novagenesis proxy/gateway/controller for openflow software definednetworks. In Network and Service Management (CNSM), 2014 10th InternationalConference on, pages 394–399.
Alberti, A. M. (2013). A conceptual-driven survey on future internet requirements, tech-nologies, and challenges. Journal of the Brazilian Computer Society, 19(3):291–311.
Alberti, A. M., Vaz, A., Brandao, R., and Martins, B. (2012). Internet of informationand services (iois): a conceptual integrative architecture for the future internet. InProceedings of the 7th International Conference on Future Internet Technologies, CFI’12, pages 45–45, New York, NY, USA. ACM.
Jacobson, V. (2011). Ccn routing and forwarding. Technical report, Stanford NetSeminar.
Pan, J., Paul, S., and Jain, R. (2011). A survey of the research on future internet architec-tures. Communications Magazine, IEEE, 49(7):26 –36.
Raimundo-Neto, E., da Rosa, J. R. G., Casaroli, M. A. F., Feliciano da Costa, I., Alberti,A. M., and Arismar, C. S. (2014). Implementation of an optical-wireless network withspectrum sensing and dynamic resource allocation using optically controlled reconfig-urable antennas. International Journal of Antennas and Propagation, 2014:11.
Rexford, J. and Dovrolis, C. (2010). Future internet architecture: clean-slate versus evo-lutionary research. Commun. ACM, 53(9):36–40.
Wu, Q., Li, Z., Zhou, J., Jiang, H., Hu, Z., Liu, Y., and Xie, G. (2014). Sofia: towardservice-oriented information centric networking. Network, IEEE, 28(3):12–18.
16
