Pós-Graduação em Ciência da Computação
CLÁUDIO LUIZ
AVALIAÇÃO DA CONVERGÊNCIA DO ROTEAMENTO NA
ARQUITETURA RINA
Universidade Federal de Pernambuco
www.cin.ufpe.br/~posgraduacao
RECIFE
2017
CLÁUDIO LUIZ
AVALIAÇÃO DA CONVERGÊNCIA DO ROTEAMENTO NA
ARQUITETURA RINA
ORIENTADOR: Prof. Dr. José Augusto
Suruagy Monteiro
RECIFE
2017
Este trabalho foi apresentado à Pós-
Graduação em Ciência da Computação do
Centro de Informática da Universidade
Federal de Pernambuco como requisito
parcial para obtenção do grau de Mestre
Profissional em Ciência da Computação.
Catalogação na fonte
Bibliotecária Monick Raquel Silvestre da S. Portes, CRB4-1217
L953a Luiz, Cláudio Avaliação da convergência do roteamento na arquitetura RINA / Cláudio
Luiz. – 2017. 73 f.: il., fig., tab. Orientador: José Augusto Suruagy Monteiro. Dissertação (Mestrado) – Universidade Federal de Pernambuco. CIn,
Ciência da Computação, Recife, 2017. Inclui referências e anexos.
1. Redes de computadores. 2. Roteamento. I. Monteiro, José Augusto Suruagy (orientador). II. Título. 004.6 CDD (23. ed.) UFPE- MEI 2017-239
Cláudio Luiz
AVALIAÇÃO DA CONVERGÊNCIA DO ROTEAMENTO NA
ARQUITETURA RINA.
Dissertação apresentada ao Programa de Pós-
Graduação em Ciência da Computação da
Universidade Federal de Pernambuco, como requisito
parcial para a obtenção do título de Mestre
Profissional em 29 de junho de 2017.
Aprovado em: 29/06/2017.
BANCA EXAMINADORA
__________________________________________
Prof. Dr. Kelvin Lopes Dias
Centro de Informática/UFPE
__________________________________________
Prof. Dr. Leobino Nascimento Sampaio
Universidade Federal da Bahia
__________________________________________
Prof. Dr. José Augusto Suruagy Monteiro
Centro de Informática/UFPE
(Orientador)
À minha esposa, Aline Monteiro Silva.
AGRADECIMENTOS
Agradeço a Deus por me permitir sonhar e por me manter firme na realização de meus
sonhos.
Ao professor orientador DR. JOSÉ AUGUSTO SURUAGY MONTEIRO pelo auxílio
às atividades e pelas discussões sobre o andamento desta dissertação de mestrado.
Aos demais idealizadores e colaboradores do CIn, bem como a todos os professores e
colegas de turma, pela dedicação e entusiasmo demonstrado ao longo do curso.
Aos colegas de trabalho do Instituto Federal Fluminense que me ajudaram direta ou
indiretamente nessa conquista.
“No, technology does not change the world. Imagination does.”
― JOHN DAY
RESUMO
Algumas restrições da pilha de protocolos TCP/IP se tornaram fatores limitadores para
o crescimento da Internet atual. Dentre esses fatores estão limitações no roteamento, que é feito
com pouca granularidade e sobre grandes escopos por protocolos como o BGP (Border
Gateway Protocol). A Arquitetura Interredes Recursiva é uma proposta clean slate para a
Internet do futuro (IF) que propõe soluções alternativas para esses limites. Denomina-se
convergência de roteamento ao conjunto de ações tomadas para manter os caminhos da rede
que ligam os remetentes aos destinatários em face de mudanças na topologia causadas por
quedas ou descobertas de melhores caminhos. Essa dissertação descreve um trabalho que teve
por objetivo avaliar a convergência de roteamento da arquitetura RINA em comparação com a
convergência dos protocolos de roteamento da Internet atual. Para alcançar esse objetivo, o
comportamento dos componentes da rede RINA foi emulado através do protótipo ProtoRINA
e, como representante do roteamento na Internet atual, emulou-se o comportamento do
protocolo BGP. Os cenários construídos no desenvolvimento do trabalho permitiram uma
comparação entre os tempos de resposta na rede RINA e na Internet atual, tendo ambas, sido
submetidas, a convergências provocadas por quedas de caminhos.
Palavras-chave: RINA. ProtoRINA. BGP. Roteamento. Convergência de Roteamento.
ABSTRACT
Some restrictions in the TCP/IP protocol stack have become limiting factors for
growing the Internet. Some of these factors are limitations in routing, which is done with little
granularity and over large scopes by protocols such as BGP (Border Gateway Protocol).
The Recursive InterNetwork Architecture (RINA) is a clean slate proposal for Future Internet
(FI) which proposes alternative solutions for these limitations. Routing convergence is the set
of actions to maintain the network paths that connect senders to recipients in the face of changes
in topology caused by failures or discoveries of better paths. This dissertation describes a work
that aimed to evaluate the convergence of routing of the RINA architecture in comparison to
the convergence of the current Internet. In order to reach this objective, the behavior of the
components of the RINA network was emulated through the ProtoRINA prototype and, as a
representative of the current Internet routing, the behavior of the BGP protocol was emulated.
The scenarios constructed in the development of this work allowed a comparison between the
response times in the RINA network and in the current Internet, both of which were submited
to convergences caused by path failures.
Keywords: RINA. ProtoRINA. BGP. Routing. Routing Convergence.
LISTA DE FIGURAS
Figura 1.1- Tempo de viagem de ida e volta (RTT) ................................................................. 16
Figura 2.1 - Camadas estáticas da Internet atual .................................................................... 23
Figura 2.2 - Exemplo de fullmesh IBGP ................................................................................. 25
Figura 2.3 - Cenário BGP com três escopos de roteamento .................................................. 26
Figura 2.4- Configuração do roteador R12 ............................................................................ 26
Figura 2.5 – Configuração de routemap ................................................................................. 27
Figura 3.1 - Camadas dinâmicas vs. Camadas estáticas ......................................................... 28
Figura 3.2 – Independência de localização ............................................................................ 31
Figura 4.1 – Diagrama da Classe topo ................................................................................... 36
Figura 4.2 - Zebra Deamons ................................................................................................... 37
Figura 4.3 – Personalização da classe Node ........................................................................... 38
Figura 4.4 – Nó RINA ............................................................................................................. 39
Figura 4.5 - Exemplo básico de uma rede RINA ..................................................................... 40
Figura 4.6 – Funcionamento do IPC no ProtoRINA............................................................... 41
Figura 4.7 – Topologia de uma rede RINA ............................................................................. 43
Figura 4.8 - Topologia de uma rede RINA .............................................................................. 44
Figura 4.9 – Possíveis estados de um thread .......................................................................... 45
Figura 4.10 Personalização para envio de mensagens ........................................................... 46
Figura 5.1–Cenário do BGP ................................................................................................... 49
Figura 5.2- Cenário da RINA .................................................................................................. 50
Figura 5.3 - Arquivo com registros de requisição e retorno do BGP ..................................... 51
Figura 5.4 - Arquivo com registros de requisição e retorno da RINA .................................... 51
Figura 5.6 - Cenário BGP com 3 escopos de roteamento....................................................... 54
Figura 5.7 - Cenário RINA com 3 escopos de roteamento ...................................................... 54
Figura 5.8 - Cenário BGP com 5 escopos de roteamento....................................................... 55
Figura 5.9 - Cenário RINA com 5 escopos de roteamento ..................................................... 56
Figura 5.10–Cenário BGP com 7 escopos de roteamento ...................................................... 57
Figura 5.11– Cenário RINA com 7 escopos de roteamento .................................................... 57
Figura 5.12– Cenário BGP com 7 escopos de roteamento ...................................................... 58
Figura 5.13– Cenário RINA com 9 escopos de roteamento .................................................... 58
LISTA DE ACRÔNIMOS
ADN - Application Driven Networking
API - Application Programming Interface
BGP - Border Gateway Protocol
CDAP - Common Distributed Application Protocol
DAF - Distributed Application Facility
DIF - Distributed IPC Facility
DNS - Domain Name System
DTP - Data Transfer Protocol
EGP - Exterior Gateway Protocol
GENI - Global Environment for Network Innovations
IANA - Internet Assigned Numbers Authority
ICMP - Internet Control Message Protocol
IDD - Inter DIF Directory
IGP - Interior Gateway Protocols
IPC - Inter-Process Communication
LACNIC- Latin American and Caribbean Internet Addresses Registry
NAT - Network Address Translation
OSPF - Open Shortest Path Fist
RIB - Resource Information Base
RINA - Recursive InterNetwork Architecture
RIR - Registros Regionais da Internet
RORA - Routing in Recursive Architectures
ASN - Autonomous System Number
TCP - Transmission Control Protocol
SUMÁRIO
1 INTRODUÇÃO .................................................................................................................... 13
1.1 Limitações da Internet ............................................................................................. 13
1.2 Motivação .................................................................................................................. 15
1.3 Objetivos.................................................................................................................... 17
1.3.1 Objetivo Geral ............................................................................................................ 17
1.3.2 Objetivos Específicos ................................................................................................. 17
1.4 Metodologia ............................................................................................................... 17
1.5 Estrutura da Dissertação ......................................................................................... 18
2 ROTEAMENTO NA ARQUITETURA ATUAL DA INTERNET ................................. 19
2.1 Roteamento e convergência de roteamento............................................................ 19
2.2 Protocolos de roteamento dinâmico ........................................................................ 20
2.3 BGP (Border Gateway Protocol) ............................................................................ 21
2.3.1 Princípios básicos ....................................................................................................... 21
2.3.2 Anomalias do BGP ..................................................................................................... 23
2.3.3 Routereflector ............................................................................................................. 24
2.3.4 Routemap.................................................................................................................... 26
2.4 Considerações Finais ................................................................................................ 27
3 A ARQUITETURA RINA .................................................................................................. 28
3.1 RINA: visão geral ..................................................................................................... 28
3.2 Roteamento na arquitetura RINA .......................................................................... 30
3.3 Protótipos e simuladores para RINA ..................................................................... 32
3.4 Considerações Finais ................................................................................................ 33
4 CONSTRUÇÃO DO AMBIENTE DE EMULAÇÃO ...................................................... 34
4.1 Visão geral do ambiente construído........................................................................ 34
4.2 Mininet ...................................................................................................................... 35
4.2.1 API Python para o Mininet ......................................................................................... 35
4.2.2 Uso de scripts Python para orquestração .................................................................... 36
4.3 Quagga Routing Suite .............................................................................................. 37
4.4 ProtoRINA ................................................................................................................ 38
4.5 Roteamento no ProtoRINA ..................................................................................... 40
4.6 APIs Java paraThreads e Sockets ........................................................................... 44
4.7 Ferramenta para cálculo de RTT ........................................................................... 46
4.8 Considerações Finais ................................................................................................ 47
5 COMPARAÇÃO DO DESEMPENHO DAS CONVERGÊNCIAS DE ROTEAMENTO
SOB OS CENÁRIOS PROPOSTOS .................................................................................. 48
5.1 Definição dos experimentos ..................................................................................... 48
5.1.1 Coleta de dados .......................................................................................................... 50
5.2 Resultados Obtidos ................................................................................................... 52
5.3 Discussão ................................................................................................................... 59
5.4 Considerações Finais ................................................................................................ 60
6 CONCLUSÕES E TRABALHOS FUTUROS .................................................................. 61
REFERÊNCIAS ................................................................................................................... 63
ANEXO A – ROTEIROS DE EXPERIMENTAÇÕES NO FIBRE................................ 68
ROTEIRO 1 – EXPERIMENTO DE REGISTRO DE IPC ................................. 68
ROTEIRO 2 – EXPERIMENTO DE ALOCAÇÃO DE FLUXO E
TRANSFERÊNCIA DE DADOS ............................................................................ 69
ROTEIRO 3 – EXPERIMENTO DE FORMAÇÃO DINÂMICA DE DIF........ 71
ROTEIRO 4 – CONSTRUÇÃO DE TOPOLOGIA USADA PARA
EXPERIMENTOS DE ROTEAMENTO E MULTHOMING ............................ 73
13
1 INTRODUÇÃO
Segundo (DAY, 2008), mesmo com todo o trabalho desenvolvido por tantos anos, a
Internet ainda é, em seu núcleo, apenas uma demonstração inacabada. O autor propõe um
retorno às origens para a solução definitiva dos problemas que limitam o crescimento da
Internet atual. O funcionamento da Internet atual se baseia na pilha de protocolos TCP/IP que
apresenta várias limitações em diferentes áreas como: segurança, mobilidade, roteamento,
multihoming, escalabilidade e outros.
Neste capítulo será feita uma introdução aos assuntos abordados nessa dissertação.
Inicialmente serão demostradas algumas limitações da Internet atual dando-se mais destaque às
questões relacionadas ao roteamento. Em seguida será abordada a motivação do trabalho bem
como os seus objetivos, metodologia e estrutura.
1.1 Limitações da Internet
Roteamento é um problema na Internet atual porque nela existem conflitos em relação
à identificação de hosts dentro das redes (CAESAR et al., 2006). Na arquitetura atual da
Internet, o endereço IP (Internet Protocol) serve tanto para identificar quanto para localizar os
hosts dentro da rede.
A localização de objetos em uma rede de dados está relacionada com como achar um
determinado objeto. Já a identificação de objetos se relaciona com como distinguir determinado
objeto de outros na mesma rede. Existe uma clara diferença de significado entre estes dois
conceitos, porém, na Internet atual, usa-se um mesmo rótulo (endereço IP da interface) para
ambos.
Para (SOUSA; PENTIKOUSIS; CURADO, 2011), multihoming é a técnica de utilizar
múltiplos pontos de conexão a fim de evitar uma parada da rede se uma das conexões falhar.
Além de permitir múltiplos pontos de conexão outro fator importante é o fato de permitir o
equilíbrio da carga, diminuindo o número de computadores que acessam a Internet por qualquer
uma das conexões. Assim sendo, o multihoming otimiza o desempenho e diminui os tempos de
espera.
A premissa básica do multihoming é prover uma solução para eliminar problemas de
conexão à rede por falhas em um único ponto. Por isso, multhoming é um requisito necessário
na Internet atual (KUROSE, J. F., & ROSS, 2010).
14
Porém para (DAY, 2008) há uma impossibilidade de se prover multhoming na Internet
atual. O autor argumenta que essa impossibilidade é devida à forma de endereçamento usada:
se endereça a interface quando o correto seria endereçar os processos de comunicação. O
verdadeiro multhoming, segundo (DAY, 2008), não é possível na Internet atual porque duas
conexões de um mesmo host são vistas como se fossem dois hosts diferentes.
O excesso de semântica do endereço IP e o fato de se endereçar a interface ao invés dos
processos de comunicação impactam negativamente fatores como roteamento e multhoming.
Esses fatores são requisitos decisivos para o crescimento da Internet atual.
O roteamento na Internet atual é suportado por protocolos como o BGP (Border
Gateway Protocol) que impõe uma visão sobre a rede na qual ela é dividida em escopos
chamados Sistemas Autônomos (SA). Desta forma, a Internet atual pode ser vista como uma
grande rede dividida em SAs (REKHTER; LI; HARES, 2006).
As estratégias de roteamento usadas pelo BGP também são fortemente afetadas pelo
excesso de semântica do endereço IP e pelo fato de se endereçar a interface ao invés dos
processos de comunicação. Isso faz com que o BGP tenha que trabalhar fazendo uso de um
escopo muito grande.
Além disso, para prover roteamento, o BGP agrupa sub-redes em blocos representados
pelos prefixos de destino agregado. O problema com esses blocos é que eles fazem com que o
roteamento da Internet atual deixe de ter granularidade.
A falta de granularidade e o tamanho do escopo tornam caras as convergências de
roteamento suportadas pelo BGP e necessárias na Internet atual. Como consequência, tem-se
um aumento no tempo de resposta entre hosts que, para se comunicar, usam conexões que
passam por caminhos afetados pelas convergências.
Como soluções para esses problemas há várias pesquisas em Internet do futuro (IF) que
buscam entender melhor as limitações do TCP/IP e soluciona-las de diferentes maneiras: (PAN;
PAUL; JAIN, 2011); (CAMPISTA et al., 2014); (FISHER, 2014); (KHONDOKER et al.,
2014); (UL HAQUE et al., 2013); (GEORGIOS et al., 2011); (BIFFI; TUISSI, 2017). As
pesquisas em IF se dividem em dois grandes grupos: incrementais e Clean Slate (FELDMANN,
2007).
As pesquisas do tipo Clean Slate não se dedicam a resolver problemas nas áreas
específicas do TCP/IP. Ao invés disso, essas pesquisas apontam soluções que, por não serem
compatíveis com a arquitetura atual da Internet, também são chamadas de Non IP (VASSEUR;
DUNKELS, 2010).
15
RINA (Recursive InterNetwork Architecture) é uma proposta completa de arquitetura
de rede em IF do tipo Clean Slate. RINA propõe uma estratégia de roteamento diferente da
vigente na Internet atual. Nela, os escopos são menores e existe fina granularidade
(ISHAKIAN; MATTA; AKINWUMI, 2010). Esses fatores levam a crer que o tempo de
resposta nas redes RINA seria menor do que nas redes da Internet atual.
1.2 Motivação
Experimentações práticas com a arquitetura RINA não são tão comuns por se tratar de
uma arquitetura clean slate, ou seja, não compatível com TCP/IP. Por outro lado, a visão prática
das soluções propostas na arquitetura é uma necessidade para a aceitação dessas soluções.
Diante dessa necessidade, buscou-se nesse trabalho, formas de levar à prática as
soluções propostas na arquitetura RINA para problemas que limitam a Internet atual. Mais
especificamente, buscou-se formas de experimentar vertentes da RINA relacionadas com
roteamento e com a convergência de roteamento.
Na Internet atual, o comportamento de protocolos como o BGP, faz com que as
convergências de roteamento sejam mais lentas do que o necessário. O reflexo negativo desse
comportamento pode ser averiguado por fatores como o aumento do tempo de resposta na rede.
Tempo de resposta na rede é o tempo transcorrido desde que um remetente envia uma
requisição a um destinatário até o momento no qual esse remetente recebe a resposta. Uma
forma de se observar o desempenho da rede em relação ao tempo de resposta é através do
cálculo do RTT. Para (KUROSE, J. F., & ROSS, 2010) o RTT é composto por quatro tipos de
atrasos em roteadores e comutadores intermediários: atraso de transmissão de pacotes; atraso
de propagação de pacotes; atraso de espera em fila de pacotes; atraso de processamento de
pacotes. O autor ilustra o RTT através da figura 1.1. Nela ele esclarece que numa conexão do
tipo cliente/servidor, o RTT é o tempo que leva para um pacote viajar do cliente ao servidor e
de volta ao cliente.
16
Figura 1.1- Tempo de viagem de ida e volta (RTT)
Fonte: (KUROSE, J. F., & ROSS, 2010) com adaptações
O RTT pode servir como um indicador da qualidade do serviço ofertado pela rede
(OHSAKI et al., 2002). Isso ocorre porque as aplicações disponíveis através da rede geralmente
têm a qualidade do seu serviço afetada quando os tempos de resposta estão muito altos. Devido
a essa relação entre o tempo de resposta e a qualidade do serviço da rede, os administradores
frequentemente medem o RTT para monitorar problemas nos diferentes caminhos que
interconectam remetentes a destinatários (MARCHETTA et al., 2014).
Define-se como convergência de roteamento à série de ações tomadas, em conjunto,
pelos roteadores de um determinado escopo de roteamento, para que haja uma mudança para
um outro caminho. Essa mudança de caminho geralmente ocorre em função de uma queda ou
da descoberta de uma melhor opção de rota (LABOVITZ et al., 2001).
Convergências de roteamento são necessárias já que os caminhos da rede tendem a ser
alterados devido às mudanças das topologias. Porém a forma como a Internet atual lida com as
convergências afeta negativamente o funcionamento da rede.
A estratégia de roteamento presente na arquitetura RINA lida de forma mais eficiente
com as convergências de roteamento e isso pode ser constatado pela diminuição do RTT entre
hosts que estão separados por caminhos afetados por estas convergências.
A principal motivação desse trabalho é avaliar as soluções relacionadas ao roteamento
da rede propostas na arquitetura RINA e os impactos dessas soluções na diminuição do RTT
17
mesmo quando convergências de roteamento estão ocorrendo entre os caminhos que separam
remetentes de destinatários.
1.3 Objetivos
1.3.1 Objetivo Geral
Este trabalho objetiva avaliar as estratégias para convergências de roteamento propostas
na arquitetura RINA em comparação com as estratégias vigentes na Internet atual.
1.3.2 Objetivos Específicos
➢ Levar à prática as propostas da arquitetura RINA de forma genérica e de forma
específica as vertentes da arquitetura relacionadas com convergências de roteamento;
➢ Observar como as funcionalidades propostas na RINA se comportam quando
submetidas a situações comuns às redes atuais como as convergências de roteamento
provocadas por mudanças de localidade e quedas de caminhos;
➢ Praticar aquilo que os idealizadores da proposta RINA chamam de verdadeiro
multihoming e os seus impactos no roteamento da rede;
➢ Observar a extensão dinâmica e sob demanda do escopo de roteamento com o uso de
DIFs ao invés de Sistemas Autônomos.
➢ Comparar o tempo de resposta na rede RINA com o da Internet atual quando ambos são
submetidos a atrasos provocados por convergências de roteamento.
1.4 METODOLOGIA
Para atingir os objetivos propostos foi necessário um estudo sobre o estado da arte em
roteamento na Internet atual com ênfase no protocolo BGP. Também foi necessário um
levantamento teórico da forma como o roteamento é proposto na RINA para que se pudesse
entender as experimentações práticas que foram posteriormente realizadas. O protótipo
ProtoRINA (WANG et al., 2014), desenvolvido pela Universidade de Boston, foi descoberto
como uma ferramenta capaz de auxiliar nas experimentações e foi personalizado para que
18
funcionasse em ambientes como o FIBRE (LUIZ; MONTEIRO, 2016), e Mininet (LANTZ;
HELLER; MCKEOWN, 2010). Após a personalização do ProtoRINA foram construídos pares
de cenários que emulam o comportamento da rede RINA e do protocolo BGP. Uma ferramenta
para cálculo de RTT foi construída e utilizada para geração dos dados e gráficos que permitem
uma discussão sobre as vantagens da estratégia de roteamento proposta em RINA quando
comparada com o que se pratica na Internet atual com protocolos como o BGP.
1.5 Estrutura da Dissertação
O primeiro capítulo dessa dissertação faz uma introdução aos assuntos que serão
abordados. Os dois próximos capítulos, dizem respeito, respectivamente, a um levantamento
teórico feito em relação ao roteamento na arquitetura atual da Internet e às principais
fundamentações da arquitetura RINA com ênfase na estratégia de roteamento dessa arquitetura.
No capítulo quatro foi descrita a construção do ambiente de emulação, através do qual, foram
feitas as experimentações que permitiram que, no capítulo cinco, houvesse uma comparação do
desempenho das convergências de roteamento entre RINA e a Internet atual. Finalmente, no
capítulo seis, foram dispostas conclusões sobre o trabalho apresentado.
19
2 ROTEAMENTO NA ARQUITETURA ATUAL DA INTERNET
Neste capítulo será vista a forma como o roteamento e a convergência de roteamento
são praticados na Internet atual. Os princípios básicos de funcionamento do protocolo BGP
serão definidos e também algumas anomalias presentes nesses princípios. Por fim, serão vistas
as técnicas de routereflector e routemap que são úteis na configuração de roteadores BGP e
foram empregadas nos experimentos realizados nesse trabalho.
2.1 Roteamento e convergência de roteamento
Roteamento é o conjunto de ações efetuadas pela camada de rede para determinar a rota
ou caminho tomado pelos pacotes ao fluírem de um remetente para um destinatário (KUROSE,
J. F., & ROSS, 2010).
A Internet pode ser vista como uma coleção de várias redes que se interconectam através
de equipamentos chamados roteadores. Há uma organização entre os roteadores da Internet,
eles são agrupados em escopos de roteamento que recebem o nome de Sistema Autônomo (SA)
(J. HAWKINS, 1996).
Na arquitetura atual da Internet, as interfaces dos hosts que estão dentro de uma rede
são individualizadas através do endereço IP. Da mesma forma, os SAs também possuem
endereços que os individualizam. Esses endereços são denominados ASNs (Autonomous
System Numbers) e assim como os endereços IP, são atribuídos pela Internet Assigned Numbers
Authority (IANA)1.
Na prática, a IANA fornece os endereços, dentro de grandes blocos, para entidades
chamadas Registros Regionais da Internet (RIR). O RIR apropriado, então, subdivide os
endereços para os SAs das entidades dentro de sua área de responsabilidade. A RIR responsável
pelo registro no território brasileiro é a LACNIC2 (Latin American and Caribbean Internet
Addresses Registry).
Dentre outros fatores, devido à queda de um ou mais roteadores podem ocorrer
mudanças na topologia da rede. O tempo de convergência é o período decorrido até que os
roteadores completem a execução de uma reação a essa queda, escolhendo outro caminho
1 Site oficial da IANA: https://www.iana.org/- Acessado em 06/05/17
2 Site oficial da LACNIC:http://www.lacnic.net - - Acessado em 06/05/17
20
disponível para os destinos afetados (LABOVITZ et al., 2001). Chama-se estado de
convergência ao estado normal de funcionamento de um SA que ocorre quando os roteadores
desse SA já executaram as ações relacionadas às convergências e a rede está normalmente
configurada.
Tempo de convergência é uma métrica que demonstra quão rápido um grupo de
roteadores, em um escopo de roteamento, chega ao estado de convergência. O tempo de
convergência é um dos principais indicadores de desempenho para os protocolos de roteamento
(CISCO, 2014), (BENJAMIN, 2002). O tempo de convergência tem impactos negativos no
funcionamento da rede aumentando o tempo de resposta. Quando esse aumento é muito grande,
o remetente pode até mesmo encerrar a conexão com o destinatário e isso pode levar à perda de
pacotes (ZHANG, B.; MASSEY; ZHANG, 2004).
O tempo de convergência do protocolo BGP é lento, em escala de dezenas de segundos
(YANNUZZI; MASIP-BRUIN; BONAVENTURE, 2005). A convergência de roteamento tem
tamanho impacto no desempenho da Internet atual que há várias pesquisas que buscam diminuir
esse tempo de diferentes maneiras: (BASIT; AHMED, 2017), (OLEKSANDR; OLENA;
TETIANA, 2016), (ZHOU et al., 2017).
O roteamento na Internet atual é dividido em dois grandes grupos, o roteamento interno
(GROSS, 1992) e roteamento externo (D.L. MILLS, 1984). As regras sobre o roteamento
interno são definidas pelos protocolos de roteamento interno, também conhecidos como IGP
(Interior Gateway Protocols). Já para o roteamento externo, as regras são definidas pelos
protocolos do tipo EGP (Exterior Gateway Protocol). Atualmente o protocolo padrão para
roteamento externo é o BGP e para roteamento interno é o OSPF (Open Shortest Path Fist).
2.2 Protocolos de roteamento dinâmico
Em redes pequenas é possível que a configuração dos roteadores seja feita através do
uso de rotas estáticas. Porém, em redes de grande porte o ideal é que seja usado o roteamento
dinâmico. Através do roteamento dinâmico os roteadores podem descobrir rotas de forma
automática e compartilhar essas informações com outros roteadores.
Protocolos de roteamento dinâmico permitem determinar o próximo melhor caminho
para um destino se o atual se tornar indisponível. Os caminhos na rede podem ficar
indisponíveis devido a diversos fatores como a queda de um link ou em virtude de
congestionamentos.
21
O OSPF (MOY, 1998) exerce suas funções dentro dos SAs fazendo com que os
roteadores construam mapas topológicos. Os roteadores que fazem uso do OSPF rodam
localmente o algoritmo de caminho mais curto (e.g., Dijkstra) e, assim, determinam uma árvore
de caminhos para as sub-redes, sendo o próprio roteador que iniciou essa consulta o nó raiz.
2.3 BGP (Border Gateway Protocol)
O protocolo BGP (REKHTER; LI; HARES, 2006) exerce suas funções fora do SA e o
objetivo dessas funções é justamente interligar os SAs entre si. A função primária do BGP é
permitir a troca de informação de roteamento entre os roteadores que estão configurados com
o protocolo. As informações trocadas entre os roteadores BGP incluem listas de Sistemas
Autônomos alcançáveis além de políticas e rotas usadas nos SAs. Com isso o BGP permite que
cada sub-rede anuncie sua existência ao restante da Internet (KUROSE, J. F., & ROSS, 2010).
Desta forma, o BGP consegue prover meios para que se obtenha e também para que se
propaguem informações de alcançabilidade3. Por outro lado, o BGP apresenta sérias anomalias
em relação à segurança das redes na Internet atual (BUTLER et al., 2010).
2.3.1 Princípios básicos
O BGP usa o protocolo TCP (Transmission Control Protocol) estabelecendo conexões
na porta 179. Os dois roteadores nas extremidades de cada conexão TCP são denominados pares
BGP. A conexão TCP, juntamente com todas as mensagens BGP enviadas através dessa
conexão, são chamadas sessões BGP (KUROSE, J. F., & ROSS, 2010). Um requisito comum
atualmente com o BGP é o multihoming. Essa prática consiste em interligar um SA a pelo
menos dois outros SAs. Isso geralmente é feito para balanceamento de carga ou para que haja
redundância.
Em BGP os destinos não são hospedeiros, mas sim prefixos ciderizados4, sendo que
cada prefixo representa uma sub-rede ou um conjunto de sub-redes. Cada roteador BGP tem
uma espécie de base dados com informações de roteamento denominada RIB. Essa base é
3Em teoria dos grafos, a alcançabilidade se refere à capacidade de ir de um vértice para outro em um
grafo.
4 Relativo a CIDR (Classless Inter-Domain Routing). Permite a agregação de endereços com prefixos de
qualquer tamanho.
22
dividida em três partes: Adj-RIBs-In, Adj-RIBs-Out e Loc-RIB. Na base do tipo Adj-RIBs-In
são guardadas todas as informações de roteamento recebidas de outros roteadores. Nesta base
é possível que haja diversos caminhos para um dado prefixo. Na base Loc-RIB só existe um
caminho para cada prefixo armazenado, não é permitida repetição de prefixos nessa base. Já a
base Adj-RIBs-Out armazena informações de roteamento que podem ser propagadas para
outros roteadores través das mensagens do tipo UPDATE (POWELL; JAILLET; ODONI,
1995).
A distância entre dois SAs é medida em termos de saltos, que representam o número de
SAs em um determinado caminho. Geralmente o BGP opta pelo menor caminho na seleção de
uma rota, porém outras opções também podem ser tomadas. O BGP tem alguns atributos
chamados atributos de caminho. Esses atributos são importantes no processo de seleção de rotas
do BGP. Alguns dos principais atributos de caminho do BGP são: NEXT_HOP, ROUTER_ID,
WEITGH, AS_PATH, ORIGIN.
Para descobrir e manter rotas, o BGP usa quatro tipos de mensagens: OPEN, UPDATE,
NOTIFICATION e KEEPALIVE (POWELL; JAILLET; ODONI, 1995). A mensagem OPEN é
a primeira a ser trocada entre os roteadores BGP e contém informações para que as sessões
BGP sejam iniciadas. As mensagens do tipo UPDATE transportam informações de rota e são
usadas para anunciar rotas na rede e também anunciar quando uma rota ficou inoperante devido
a uma queda, por exemplo. A mensagem KEEPALIVE é enviada por cada roteador
periodicamente para checar se a comunicação com o outro roteador ainda existe. A mensagem
NOTIFICATON é usada para informar sobre um erro em outra troca de mensagens, ela fecha
conexões defeituosas entre pares de roteadores BGP.
Quando recebe uma mensagem de UPDATE, o roteador executa um processo chamado
"path selection". Essa mensagem recebida pode trazer consigo uma nova rota, uma rota a ser
retirada ou substituída.
As sessões BGP que conectam pares de roteadores dentro de um mesmo SA são
chamadas de sessões iBGP. Já as sessões entre pares de roteadores em SAs diferentes são
chamadas de sessões eBGP (KUROSE, J. F., & ROSS, 2010). A principal diferença de
comportamento entre os roteadores que participam de sessões iBGP e eBGP é que, por padrão,
um roteador que descobre uma rota para o vizinho iBGP não envia essa rota para um outro
roteador iBGP como ocorre com roteadores em seções eBGP.
23
2.3.2 Anomalias do BGP
Esses princípios básicos de funcionamento do BGP enfrentam várias críticas porque
revelam anomalias em seu funcionamento. Essas anomalias presentes no roteamento da Internet
atual são consequências de problemas fundamentais, ou seja, da forma como a Internet foi
concebida. A figura 2.1 representa a estrutura sob a qual a Internet atual baseia o seu
funcionamento: a pilha de protocolos TCP/IP.
A figura 2.1 mostra os dois principais protocolos da camada de transporte, a opção por
um desses protocolos deveria disponibilizar ou não a opção de orientação a conexão nas
interligações da rede. Representa-se, no centro da figura, o núcleo da Internet que tem na
camada de rede funções de transferência de dados. Essas funções são desempenhadas pelos
roteadores.
Os protocolos, originalmente, deveriam servir para especificar regras genéricas, mas
estão em um número tão grande na prática atual porque representam regras de aplicações
específicas como Web, DNS, E-mail e outras.
Figura 2.1 - Camadas estáticas da Internet atual5
Destaca-se com a cor vermelha na figura 2.1 que, muitas vezes, ocorrem mudanças
indiscriminadas no endereçamento da rede como o que é feito pelo protocolo NAT (Network
Address Translation). Na Internet atual se endereça apenas a interface de rede e isso faz com
que a conexão dos vários processos de comunicação que passam por essas interfaces deixem
de ser individualizadas pois essas conexões de processos ficam agrupadas e são representadas
somente pelo endereço colocado na interface. Além do fato de não se estar individualizando
com endereços os processos de comunicação, as interfaces erroneamente endereçadas, são
5 Os endereços usados nessa figura não são reais e sevem somente para exemplificar o uso de NAT nas
redes de dados atuais.
24
juntadas em blocos representados por um único endereço no caso do NAT. A formação desses
blocos também acorre com os prefixos de destino agregado do BGP.
Essa falta de individualização dos processos de comunicação e a formação desses blocos
diminui a granularidade na gerência do roteamento e faz com que o BGP tenha que lidar com
grandes escopos quando convergências de roteamento são necessárias. Tendo que lidar com
grandes escopos e com a falta de granularidade nas convergências de roteamento o BGP torna-
se lento e essa lentidão pode ser notada por fatores como o aumento do tempo de resposta.
Segundo (ISHAKIAN; MATTA; AKINWUMI, 2010), é mais difícil gerenciar uma rede de
blocos do que seria gerenciar uma rede de processos de comunicação, que é a que se propõe em
RINA.
O BGP também enfrenta anomalias relacionadas às sessões iBGP e essas anomalias se
referem ao fato de que, em muitos casos, essas sessões não têm uma correta interação com
protocolos IGP como o OSPF. Nesses casos, ocorre a disseminação incorreta de rotas
(VISSICCHIO et al., 2012).
Outra grave anomalia encontrada no funcionamento do BGP é descrita como
“Chattiness of BGP” (YANNUZZI; MASIP-BRUIN; BONAVENTURE, 2005). Essa
anomalia diz respeito ao fato de que para descobrir e manter as rotas, o BGP precisa espalhar
informações por longos escopos de roteamento.
O BGP apresenta várias outras anomalias que têm provocado vários esforços no sentido
de melhorar o roteamento na Internet atual: (YANNUZZI; MASIP-BRUIN;
BONAVENTURE, 2005); (MARTIN; VÖLKER; ZITTERBART, 2011); (YOU et al., 2015);
(CHANDRASHEKAR et al., 2005).
2.3.3 Routereflector
Existe um requerimento nos cenários internos do BGP (iBGP) conhecido como full-
mesh. Esse requerimento é necessário porque em cenários internos, os roteadores não anunciam
rotas dentro do mesmo SA e isso torna necessária a configuração desses roteadores de forma
que eles estejam totalmente conectados entre si, formando assim, uma rede de malha completa
ou rede full-mesh.
Porém efetuar conexões entre todos os roteadores de um SA é algo complexo como pode
ser visto na figura 2.2. Nesta figura podem ser vistos doze roteadores e suas respectivas sessões
iBGP (linhas vermelhas) em uma rede do tipo malha completa. Há uma fórmula para o cálculo
25
do número de sessões requeridas para uma rede do tipo malha completa: v(v-1)/2, onde v é o
número de roteadores BGP. Aplicando-se essa fórmula na rede da figura 2.2 obtém-se a
quantidade total de sessões iBGP para essa rede: ((12*11)/2) = 66 sessões. Desta forma percebe-
se que o número de sessões cresce muito rapidamente e isso afeta o consumo de recursos
escassos e não escaláveis, como a CPU e a memória dos roteadores. Uma alternativa melhor
que o uso de redes de malha completa é conhecida como routereflector (CHANDRA, 1996).
A figura 2.3 mostra um dos cenários para experimentação de convergência de
roteamento do protocolo BGP usados neste trabalho. O routereflector teve que ser usado na
construção dessa rede para que se evitasse o uso de rede de malha completa.
Figura 2.2 - Exemplo de fullmesh IBGP6
Figura 2.3 - Cenário BGP com três escopos de roteamento
6 Fonte: https://memoria.rnp.br/newsgen/0109/bgp4_dicas2.html - Acessado em 02/05/2017.
26
Como exemplo do emprego de routereflector nos cenários de experimentação deste
trabalho, vê-se na figura 2.4 a configuração do roteador R12 cuja topologia foi vista na figura
2.3. É possível notar na configuração do R12 que os roteadores R11 e R13 foram definidos
como clientes routereflector.
Figura 2.4- Configuração do roteador R12
2.3.4 Routemap
Routemap foi outra configuração do BGP que teve que ser utilizada neste trabalho. O
roteador R11, que pode ser visto na figura 2.3, foi configurado com routemap para que
conseguisse enviar o atributo de caminho NEXT-HOP para o roteador R12. Configurações de
routemap servem para o BGP controlar e modificar informações de roteamento e também
definir as condições da propagação de rotas entre domínios (MOUBARAK; ELBAYOUMY;
MEGAHED, 2017).
Quando um roteador BGP tem uma sessão com outro roteador que não está no mesmo
SA (sessão eBGP) e tem que repassar o anúncio de rotas desse roteador externo para seus
vizinhos iBGP, o atributo de caminho NEXT-HOP é frequentemente um problema (CISCO,
2014). Isso porque esse atributo contém o endereço IP do roteador que anunciou a rota, mas os
roteadores em sessões iBGP não mudam esse endereço. Devido a essa não alteração do
endereço, os roteadores iBGP não passam o seu próprio endereço como NEXT-HOP fazendo
com que o roteador que recebe esse anúncio use o roteador errado como NEXT-HOP. O roteador
errado, neste caso, é o roteador que se encontra na sessão eBGP e o roteador correto seria o
vizinho iBGP que repassou a rota.
27
É possível alterar o endereço do atributo NEXT-HOP com a configuração do parâmetro
NEXT-HOP-SELF que foi empregada e pode ser vista na configuração do R12 (Figura 2.4).
Porém há casos mais complexos, nos quais essa configuração mais simples não funciona. A
figura 2.5 mostra o exemplo de um caso mais complexo no qual se teve que usar routemap
para alteração do endereço do atributo de caminho NEXT-HOP.
Figura 2.5 – Configuração de routemap
2.4 Considerações Finais
Neste capítulo foram abordadas as estratégias de roteamento e de convergência de
roteamento presentes na Internet atual. Dentre os protocolos de roteamento, o BGP foi abordado
de forma mais detalhada. No próximo capítulo as estratégias de roteamento e de convergência
de roteamento continuarão a ser abordadas, porém de acordo com novas propostas presentes na
arquitetura RINA.
28
3 A ARQUITETURA RINA
Nesse capítulo será apresentada a arquitetura RINA e, de forma mais detalhada, a
estratégia de roteamento presente na arquitetura. Também serão vistos alguns trabalhos que
buscam por em prática as ideias presentes na arquitetura através de simuladores e de protótipos
para emulação.
3.1 RINA: VISÃO GERAL
Diferente do que está em prática na Internet atual e foi detalhado na Subseção 2.3.2,
RINA propõe uma estrutura dividida em um número dinâmico de camadas. A figura 3.1 mostra
uma comparação entre a arquitetura RINA e a arquitetura presente na Internet atual. Ao invés
das cinco camadas estáticas do TCP/IP, em RINA há um número variável de camadas de acordo
com a necessidade em função do escopo de cobertura da rede, todas com a mesma
funcionalidade. Deste modo, em cada uma das camadas, há apenas dois protocolos que definem
regras genéricas ao invés dos muitos protocolos com regras específicas da Internet atual (DAY,
2008).
Figura 3.1 - Camadas dinâmicas vs. Camadas estáticas7
7 Essa figura foi feita, inspirada nas ideias contidas em (WANG; ESPOSITO; MATTA, 2013).]
29
Para movimentação de dados, RINA propõe o protocolo DTP (Data Transfer Protocol).
Já para questões mais relacionadas ao comportamento das aplicações8 na rede, é proposto o
protocolo CDAP (Common Distributed Application Protocol).
O tipo de camada proposta na RINA tem a capacidade de se repetir recursivamente em
escopos diversos permitindo com isso que a quantidade total de camadas seja variável
(TROUVA et al., 2012). Porém, no exemplo visto na figura 3.2 são observadas as duas
principais camadas em uma rede qualquer: física e aplicação.
Na camada de aplicação de uma rede RINA tem-se algo conhecido como DAF
(Distributed Application Facility) que pode ser encarado como um escopo ou um conjunto
formado por processos de comunicação que cooperam para prover funções na rede. Quando
essas funções são estritamente relacionadas à comunicação entre os processos, o conjunto
recebe o nome de DIF (Distributed IPC Facility).
RINA propõe uma rede mais simples do que a rede vigente na arquitetura atual da
Internet. A rede em RINA é vista simplesmente como um conjunto de processos que desejam
se comunicar e para isso se organizam cooperativamente em escopos denominados DIF ou
DAF. Esses escopos são criados, estendidos, reduzidos ou apagados sob demanda (WANG;
ESPOSITO; MATTA, 2013).
Percebe-se então, que na arquitetura RINA, o processo de comunicação é o principal
componente, ele é chamado de processo IPC (Inter-Process Communication) (DAY; MATTA;
MATTAR, 2008).
Na rede RINA há um serviço para localização de processos IPC que trabalha de forma
semelhante ao DNS (Domain Name System) ele é conhecido como IDD (Inter DIF Directory)
(TROUVA et al. 2012).
RINA é uma proposta completa de arquitetura de rede em IF do tipo Clean Slate.
Segundo (DAY, 2008), para que se entenda RINA, é necessário mudar a forma de se pensar,
do modelo de redes tradicional de camadas estáticas, para pensar em termos de aplicações
distribuídas que proveem IPC recursivamente.
Na proposta RINA são encontradas soluções para várias limitações da arquitetura atual
da Internet como: segurança, gerenciamento, multihoming, roteamento e outras.
8 Exemplos de ações relacionadas ao comportamento de aplicações na rede: ler/escrever; criar/deletar;
iniciar/parar (DAY, 2008).
30
Em relação à segurança, os processos IPCs, antes de passarem a existir na rede, devem
se apresentar ao gerente da DIF e, de forma opcional, efetuar a troca de informações de
autenticação.
Em relação ao gerenciamento há, para cada processo IPC, um banco de dados com
informações de gerenciamento denominado RIB (Resource Information Base). A RIB também
guarda informações de roteamento (ISHAKIAN; MATTA; AKINWUMI, 2010).
Em relação a multihoming e roteamento, há na arquitetura RINA, uma série de questões
que abrangem inclusive o endereçamento da rede. Para (DAY, 2008), em RINA, o componente
mais importante da rede é endereçado e consequentemente individualizado: o processo IPC.
Desta forma, com a individualização do processo IPC, se um mesmo host possuir dois
IPCs em conexões distintas, a rede não os percebe como duas conexões independentes como
ocorre na Internet atual onde a interface é que é individualizada. Um mesmo host com mais de
uma conexão com a rede sendo percebido de forma individual: esse é o verdadeiro multihoming
segundo (DAY, 2008). Por isso, o autor afirma que, na Internet atual, o suporte ao verdadeiro
multihoming não é possível já que a identidade do host está presa à sua interface.
Como os processos IPCs é que são individualizados com endereços e trabalham de
forma cooperativa dentro de escopos chamados DIF, o roteamento proposto em RINA é feito
com granularidade fina e em escopos menores quando comparado ao roteamento da arquitetura
atual da Internet como será apresentado na próxima seção.
3.2 Roteamento na arquitetura RINA
A figura 3.2 demonstra um conceito conhecido na arquitetura RINA como
independência de localização. Esse conceito está diretamente ligado à estratégia de roteamento
proposto na arquitetura.
31
Figura 3.2 – Independência de localização
Fonte: (DAY, 2008), com adaptações
Para (DAY, 2008) as aplicações que pretendem se comunicar na rede devem estabelecer
e manter comunicação com independência de localização. Na figura 3.2 demonstra que as
aplicações remetente e destinatário trocam informações através de um fluxo alocado e mantido
por processos IPC. As aplicações remetente e destinatário que aparecem na camada de nível
superior da figura desconhecem as ações feitas pelos processos IPC de mesmo nível e de níveis
inferiores para alocar e manter o fluxo.
Desta forma, na figura 3.2 os processos IPC é que são responsáveis por alocar e manter
o fluxo, mesmo que para isso, através do multhoming, os processos IPC tenham que alterar
esses caminhos sem ciência das aplicações e ao nível de processo. Numa rede RINA, como a
demonstrada na figura 3.2, os processos IPC é que são móveis: os processos IPC têm a
capacidade de se juntar a novas DIFs e de abandonar DIFs anteriores com movimentos locais.
Na rede RINA o movimento local dos processos IPC só resulta em atualizações de rotas locais.
Desta forma, percebe-se que na RINA as aplicações são independentes de localização enquanto
os endereços é que são dependentes de localização.
A estratégia de roteamento presente na RINA é chamada RORA (Routing in Recursive
Architectures). Nessa estratégia, os endereços dos processos IPC podem servir como ponto de
conexão (PoA9) para outros processos IPC de um nível superior (ISHAKIAN; MATTA;
AKINWUMI, 2010). Em RORA os endereços devem ser dependentes de localização sem serem
dependentes de rota. É proposta por (DAY, 2008) uma abstração, através de grafos que
permaneça invariável mesmo quando o grafo da rede variar.
9 Conceito nomeado, literalmente, na proposta RINA como “point of attachment” e que pode ser visto
com mais detalhes em (DAY, 2008).
32
Na RINA os endereços auxiliam no roteamento, pois eles possuem indicações da
posição que o processo IPC ocupa na topologia da rede, sendo chamados de endereços
topológicos.
Em RORA, nas decisões tomadas a cada etapa (hop-by-hop10), o IPC acha o destino e
traça a rota de volta para onde ele está, o destino é sempre relativo à localização atual do IPC.
Com essa estratégia de roteamento, a movimentação de dados na rede RINA é feita sem que
haja dependência de rota, com um menor escopo e uma granularidade mais fina. Além do que,
as mudanças causadas por distorções na topologia como quedas de caminhos que geram
convergências de roteamento, só precisariam ser propagadas nas proximidades, ou seja, entre
os vizinhos mais próximos. Se um processo IPC não estiver próximo de onde houve a distorção,
ele não tem que saber que essa distorção ocorreu.
Conforme foi visto no capítulo 2, na Internet atual, devido aos blocos criados pelo NAT
e pelos agregados do BGP, as informações de roteamento têm que ser espalhadas por grandes
escopos e com pouca granularidade.
3.3 Protótipos e simuladores para RINA
Alguns protótipos e simuladores foram desenvolvidos para permitir a avaliação das
propostas da arquitetura RINA usando simulação e também usando emulação.
Simulações em RINA podem ser feitas através do RINASim11, que é um simulador
baseado no OMNeT++ (VARGA, 2010). Em (VESELÝ et al., 2015) os autores demonstram
como alguns elementos da RINA são tratados no RINASim e também como ocorre a relação
entre esses elementos.
Há também algumas iniciativas para permitir experimentações em RINA, nas quais se
interage com cenários mais próximos da realidade. Dentre essas iniciativas, há o projeto
IRATI12. Em (VRIJDERS et al., 2014) os autores tiveram como foco a apresentação dos
requisitos de implementação desse protótipo sobre o kernel do sistema operacional Linux.
10Em roteamento de redes, são decisões de repasse tomadas pelos roteadores a cada momento no qual
eles repassam um pacote. Numa analogia com a Internet atual, em RINA, a decisão de repasse é derivada
do endereço presente no PDU e do endereço do roteador por onde o pacote está passando no momento
(DAY, 2008).
11https://rinasim.omnetpp.org/
12http://irati.eu/
33
Outra iniciativa para permitir experimentações em RINA é o protótipo ProtoRINA. Em
(WANG et al., 2014) é feita uma introdução ao ProtoRINA na qual ele é apresentado como um
veículo para tornar concretos os conceitos em RINA e para encorajar pesquisadores a usar os
benefícios desse protótipo.
Também há trabalhos recentes (WANG; MATTA; AKHTAR, 2015) que usam o
ProtoRINA para prover um framework unificado e com mecanismos que, segundos os autores,
habilitam o gerenciamento da rede de acordo com os princípios disponíveis em
"Applicationdriven Networking" (ADN).
ADN é uma linha de pesquisa que visa criar um novo tipo de rede de dados baseada em
modelos de serviço que são dedicados e customizados especificamente para as aplicações
(TEGUEU et al., 2016); (TEGUEU et al., 2016).
Optou-se nesse trabalho, por experimentações com a arquitetura RINA, usando-se
emulação, através do protótipo ProtoRINA13 que foi desenvolvido na Universidade de Boston.
De acordo com o que foi visto neste capítulo, é proposta em RINA, uma estratégia
diferenciada para fazer o roteamento na rede: RORA. Essa estratégia também foi experimentada
em alguns trabalhos usando o ProtoRINA. Em (WANG; MATTA; AKHTAR, 2014) os autores
usaram ProtoRINA sobre o ambiente de experimentação GENI14 (Global Environment for
Network Innovations) para demonstrar que as estratégias de roteamento da RINA tornam as
convergências de roteamento mais rápidas.
Como será mais detalhado nos capítulos 4 e 5, nesse trabalho, foram feitas
experimentações com o ProtoRINA, utilizando-se o ambiente FIBRE (LUIZ; MONTEIRO,
2016) e também o Mininet.
3.4 Considerações Finais
Nesse capítulo descreveu-se a arquitetura RINA e a sua estratégia de roteamento.
Também foram apresentados simuladores e protótipos da arquitetura e entre eles o protótipo
ProtoRINA. Para realização das experimentações presentes nesse trabalho foi construído um
ambiente com o uso do protótipo ProtoRINA e de outras ferramentas que serão apresentadas
no próximo capítulo.
13http://csr.bu.edu/rina/
14http://www.geni.net/.
34
4 CONSTRUÇÃO DO AMBIENTE DE EMULAÇÃO
Este capítulo apresenta as etapas seguidas para a construção do ambiente de emulação
que foi usado nesse trabalho para as experimentações e comparações entre o roteamento na
arquitetura RINA e no protocolo BGP. Também serão apresentados os detalhes dos
experimentos que foram necessários para atingir os objetivos desse trabalho.
4.1 Visão geral do ambiente construído
De acordo com os objetivos desse trabalho, foi construído um ambiente para
experimentações práticas nas quais se buscou comparar as estratégias relativas ao roteamento
propostas na arquitetura RINA com estratégias presentes na arquitetura atual da internet.
Essas experimentações com a RINA foram efetuadas no ambiente de emulação através
da adequação a esse ambiente, do protótipo ProtoRINA. Como representante do roteamento na
internet atual, também foi adicionado nesse ambiente, o protocolo BGP.
Para construção do ambiente de experimentação, o Mininet foi instalado em um servidor
de rack Dell Inc. PowerEdgeR71015 de propriedade do Instituto Federal Fluminense. O servidor
tem um total de memória RAM de 32 GB; Processador Intel Xeon E5620 de 2,40GHz por
núcleo com um total de 8 núcleos; Disco Rígido SAS de 10 TB. Foi utilizado o sistema
operacional Linux Ubuntu14.04.2 LTS com todas as atualizações disponíveis até o momento,
incluindo a atualização do kernel.
Como será explicado adiante, as personalizações iniciais feitas no ProtoRINA, fizeram
com que os componentes desse protótipo pudessem ser portados para diversos outros ambientes
experimentais como o FIBRE (LUIZ; MONTEIRO, 2016), o Mininet e até mesmo uma rede
TCP/IP real com computadores e switches. Optou-se pelo uso do Mininet nas experimentações
da convergência de roteamento que serão detalhadas nesse capítulo porque ele se apresentou
como uma alternativa de fácil acesso, robusta e estável.
Outro fator decisivo para o uso do Mininet foi a possibilidade de se fazer alterações nas
topologias dos experimentos de uma forma rápida e centralizada, através do uso de scripts
Python para orquestração e com o auxílio da API Python para o Mininet. Também foi decisiva
15Mais informações sobre a configuração de hardware do servidor estão disponíveis em:
http://www.dell.com/br/empresa/p/poweredge-r710/pd
35
na escolha do Mininet, a possibilidade de emular o comportamento de roteadores BGP através
do software Quagga16 e emular o comportamento de uma rede RINA através das
personalizações feitas no ProtoRINA com o auxílio da API Java para Threads e Sockets.
4.2 Mininet
O Mininet foi desenvolvido na Universidade de Stanford, nos Estados Unidos (LANTZ;
HELLER; MCKEOWN, 2010). Utiliza um tipo de virtualização diferente da convencional
conhecida como virtualização a nível de processo ou virtualização leve (HANDIGOL et al.,
2012). Nesse tipo de virtualização há o compartilhamento de alguns recursos como a tabela de
paginação e estruturas de dados do kernel do sistema de arquivos. Esse tipo de virtualização
utilizado no Mininet permite uma grande escalabilidade com grandes quantidades de máquinas
virtuais que são iniciadas de forma extremamente rápida.
A opção pelo uso do Mininet foi feita porque ele apresentou os requisitos desejáveis
para o ambiente de emulação: permitir a realização de experimentos nas duas arquiteturas
(RINA e BGP); possibilidade de execução de diversas máquinas virtuais em um único servidor;
permitir a automatização do processo de criação e configuração das máquinas virtuais. No
ambiente, os nós do Mininet emulam o comportamento de roteadores BGP e também emulam
o comportamento de computadores na representação da Internet atual. Outros nós do Mininet
emulam o comportamento de componentes da rede RINA como os processos IPC e o servidor
IDD.
4.2.1 API Python para o Mininet
O Mininet disponibiliza uma API (Application Programming Interface) que possibilita
o uso de classes e métodos do Python para o gerenciamento da rede virtual. Como exemplo
dessa API, a figura 4.1 mostra a classe topo que contém subclasses e métodos para criação e
manutenção das topologias de rede no Mininet (LANTZ; HELLER; MCKEOWN, 2010).
16 Site oficial: http://www.nongnu.org/quagga/ - Acessado em 06/05/17
36
Figura 4.1 – Diagrama da Classe topo
Fonte: http://mininet.org/api/classmininet_1_1topo_1_1Topo.html
Acessado em: 05/05/2017
Além da classe topo foram usadas outras classes e métodos da API na construção do
ambiente de emulação. Por exemplo, através do método system da classe OS, foram utilizados
comandos do Linux para iniciar processos do Quagga e isso permitiu a emulação do
comportamento de roteadores BGP. Como será visto adiante, a API Python do Mininet, permite
a utilização de scripts para orquestração de cenários.
4.2.2 Uso de scripts Python para orquestração
Com o tipo diferenciado de virtualização disponível no Mininet e com o auxílio da API
Python, é possível orquestrar cenários iniciando, desligando ou reiniciando os componentes das
topologias. Também é possível personalizar os componentes do Mininet disponibilizando nas
topologias emuladas: computadores, switches, roteadores, links, vlans e etc. Desta forma, é
possível que as topologias dos cenários do Mininet tenham o seu comportamento totalmente
orquestrado por um script Python. Isso é útil em experimentações nas quais se deseja mudar o
comportamento dos cenários de forma centralizada e com a intenção de emular quedas de link,
convergências de roteamento e outras.
Nos cenários do ambiente de emulação foi usado o software Quagga que permite a
configuração de roteadores e o armazenamento dessas configurações em arquivos de texto.
Toda a orquestração desses cenários foi feita com o uso de scripts Python. Estes scripts também
foram usados nos cenários para automatizar a criação de roteadores através da escrita dos
arquivos de texto com as configurações do Quagga. Com isso as transformações das topologias
37
nos cenários foram feitas de forma centralizada e extremamente rápida em momentos nos quais
essa agilidade foi necessária para as experimentações.
Vários trabalhos usam scripts para orquestração dos cenários de emulação (ZHANG,
H.; YAN, 2015), (GODAN; COLMAN; GRAMPIN, 2017), (BASIT; AHMED, 2017),
(SALSANO et al., 2014), (HONGBO; KITSUWAN, 2016), (ZENG et al., 2014).
4.3 Quagga Routing Suite
Quagga é um conjunto de programas reunidos em uma mesma plataforma com o
objetivo de disponibilizar roteamento para redes com a utilização de computadores, que através
desse conjunto de programas, passam a agir como roteadores e implementar os principais
protocolos de roteamento da Internet como: RIP, OSPF e BGP (JAKMA; LAMPARTER,
2014). Quagga pode ajudar profissionais de rede a construir soluções customizadas, pode ajudar
pesquisadores a incrementar a visibilidade de seus trabalhos tornando esses trabalhos mais
práticos (JAKMA; LAMPARTER, 2014).
Segundo o seu site oficial, Quagga é um software livre, de licença GPL, que funciona
sobre os sistemas operacionais Linux, Unix, FreeBSD, Solaris e NetBSD. O núcleo do conjunto
de programas Quagga é composto pelo software Zebra que age como uma camada de abstração
para o kernel do Sistema Operacional e disponibiliza a API Zserv. Através dessa API é possível
a implementação de protocolos de roteamento como OSPF e BGP que se tornam disponíveis
na rede através do daemon do Zebra. A figura 4.2 mostra os protocolos de roteamento
disponíveis no Quagga através do Zebra.
Figura 4.2 - Zebra Deamons
Fonte: site oficial do Guagga
38
Acessado em: 02/05/2017
4.4 . ProtoRINA
Conforme visto na seção 3.3, ProtoRINA é um protótipo para a arquitetura RINA
implementada em Java por pesquisadores da Universidade de Boston. Tendo sido feito em Java,
o ProtoRINA é totalmente baseado nos princípios de orientação a objetos. Isso significa que
para que ele fosse personalizado de acordo com o que se objetivava fazer no ambiente de
emulação desse trabalho, teve-se que interagir com as diversas classes e métodos que formam
o protótipo. Essa interação com as classes e métodos teve que ser feita mantendo-se o respeito
a princípios de orientação a objetos com: herança, polimorfismo, encapsulamento e outros.
A classe Node é um exemplo dessas personalizações feitas no ProtoRINA. A figura 4.3
mostra essa classe que foi importada e personalizada na classe No2. Desta forma, conseguiu-se
que alguns nós se comportassem na rede RINA do ambiente como remetente, intermediário e
destinatário. Nas redes RINA do ambiente de emulação, cada host virtual do Mininet
corresponde a um nó personalizado do ProtoRINA.
Figura 4.3 – Personalização da classe Node
39
Segundo a proposta original, numa rede RINA, diferente da Internet atual, não se
endereça as interfaces de rede e sim os processos de comunicação (IPC). Vê-se na figura 4.4 o
comportamento desses processos IPC na rede RINA.
Conforme foi visto no capítulo 3, RINA propõe uma forma diferente na separação da
rede em camadas funcionais. Por isso, a figura 4.4 demonstra uma quantidade variável de
camadas. Nessa figura vê-se o comportamento de um nó RINA no protótipo ProtoRINA. Esse
nó, que contém vários processos IPC, implementa, a partir da camada de aplicação (DAF),
camadas inferiores, de forma recursiva, até atingir o nível mais baixo. No ProtoRINA essa
camada mais baixa é representada pelo shim layer ou shim DIF. De forma genérica, um Shim
DIF é uma camada que se apresenta ao usuário como uma DIF, mas que implementa suas
funções parcialmente ou não baseada em IPC. No ProtoRINA, Shim DIF é o equivalente ao
cabo de rede ou à camada física. Porém no ProtoRINA, ao invés de conexões físicas, são usadas
portas TCP para as conexões entre os processos IPC.
Figura 4.4 – Nó RINA
Fonte: (WANG et al., 2014)
A figura 4.5 mostra um exemplo básico de rede RINA implementada no ambiente de
emulação. Nessa figura é possível ver alguns componentes da arquitetura RINA que foram
explicados com mais detalhes na seção 3.1. Esses componentes são: Servidor IDD, DIF e
processo IPC. Vê-se também na figura 4.5 a atuação dos nós personalizados (figura 4.3) que
contêm os processos IPC. Além disso, também é possível ver na figura 4.5 a atuação do shim
DIF, que interliga os nós ao servidor IDD.
40
Figura 4.5 - Exemplo básico de uma rede RINA
Fonte: (LUIZ; MONTEIRO, 2016)
As personalizações iniciais feitas com o ProtoRINA possibilitaram que essas redes
RINA pudessem ser implementadas em diferentes ambientes de experimentação como o FIBRE
(LUIZ; MONTEIRO, 2016) e o Mininet. Devido a esses esforços também é possível emular o
funcionamento de uma rede RINA utilizando-se para isso computadores interligados por
switches sob uma rede TCP/IP real.
No “Anexo A” foram descritos alguns roteiros que demonstram como se deve agir para
implementar certas funcionalidades da arquitetura RINA sobre o ambiente FIBRE.
4.5 ROTEAMENTO NO PROTORINA
A figura 4.6 mostra o funcionamento do IPC no ProtoRINA. Percebe-se nessa figura
que cada IPC tem um banco de dados (RIB) no qual são armazenadas informações de
gerenciamento e também de roteamento. Outro componente visto na figura 4.6 que tem relação
com o roteamento é o RoutingDaemon. Através do RoutingDaemon, dos endereços topológicos
e da API Java para Threads e Sockets, o ProtoRINA implementa a estratégia de roteamento
proposta originalmente na arquitetura RINA. Essa estratégia foi detalhada no capítulo 3.2.
Quando um novo processo IPC surge na rede, para passar a fazer parte da DIF, ele tem
que se apresentar ao gerente que, dentre outras ações, lhe fornecerá um endereço que dependerá
da posição que esse processo IPC ocupa na topologia (endereço topológico).
41
Uma vez que tenha tido o seu registro aprovado pelo gerente e tenha adquirido um
endereço, o processo IPC passará a verificar apenas a sua vizinhança mais próxima em busca
de outros processos IPC que estejam ligados diretamente a ele. Desta forma, cada processo IPC
em uma rede RINA conhece apenas os seus vizinhos mais próximos.
Figura 4.6 – Funcionamento do IPC no ProtoRINA
Fonte: (WANG et al., 2014)
Assim como na Internet atual, também é possível que haja mudanças na topologia da
rede RINA obrigando a troca de caminhos. Essas mudanças são causadas por quedas de
caminhos ou mesmo pela aparição de um caminho melhor.
Os saltos que formam os caminhos na rede RINA são os processos IPC e para se adequar
a essas mudanças eles, assim como na Internet atual, também têm que participar de
convergências de roteamento.
Diferente da internet atual, quando ocorrem convergências de roteamento por mudanças
na rede RINA, nem todos os saltos que compõem o caminho, desde o remetente até o
destinatário precisam, necessariamente, ser afetados por essa convergência. Isso ocorre na rede
RINA devido à forma de funcionamento do Routing Daemon, que não busca por todos os saltos
entre a origem e o destino para formar uma rota como no BGP. Ao invés disso, o Routing
Daemon só reconhece os vizinhos que estão diretamente ligados e forma assim um escopo de
roteamento menor do que aquele visto na Internet atual.
42
Após a fase inicial de registro17, o processo IPC passa a integrar a DIF, individualizado
por um endereço topológico, possuindo uma tabela de roteamento gerada e mantida pelo
Routing Daemon.
Um exemplo da forma como os endereços topológicos foram implementados no
ProtoRINA pode ser visto na figura 4.7, na DIF 6. O processo IPC 15 é o gerente da DIF 6 e
tem o endereço 6. Antes de passar a existir na rede, o IPC16 teve que se apresentar ao gerente
e recebeu o endereço 61 que indica sua posição na topologia em relação ao gerente. O mesmo
ocorreu com os outros processos IPC dessa DIF. Desta forma, o endereço 62 (IPC19) indica
tratar-se do segundo vizinho do gerente e assim por diante.
Na proposta RINA e também na implementação que foi feita no ProtoRINA, os
endereços são locais e não têm relação com o número da DIF como aparece na figura 4.7. A
figura foi construída dessa forma apenas para tornar a explicação sobre os endereços
topológicos mais didática.
Após esse posicionamento inicial, o Routing Daemon efetua mudanças em relação aos
vizinhos sempre que ocorre qualquer mudança na topologia, mantendo com isso, as tabelas de
roteamento do processo IPC atualizada, porém esses endereços iniciais não são alterados.
Observou-se (figura 4.4) que os processos IPC podem passar por várias camadas até
atingirem o shim DIF. Na figura 4.7 observa-se um cenário implementado no ambiente de
emulação, no qual o nó 1 tem processos IPC em duas DIFs de nível inferior (DIF1 e DIF 4) e
em uma DIF de nível superior (DIF 6). O cenário da figura 4.7 foi implementado dessa forma
para permitir comparações com a Internet atual através do protocolo BGP.
17 Essa fase é chamada literalmente de enrollment e nela, dependendo da política da rede, o gerente da
DIF pode exigir credenciais de autenticação para liberar a entrada do novo processo IPC. Lembra-se que tudo isso
ocorre ao nível de processo.
43
DIF6IPC 1962
Nó 4
IPC 17611
NóX
IPC 186111
AppRemetente
Nó 8
AppDestinátario
IPC 156
Nó 1
IPC 11
IPC 211
IPC 3111
IPC 94
IPC 1041
IPC 11411
IPC 42
IPC 521
IPC 63
IPC 731
IPC 8311
IPC 127 IPC 13
51
IPC 14511
IPC 1661
Nó 2
Nó 3
Nó 6
Nó 7
Nó 5
DIF1 DIF2DIF3
DIF4DIF5
X
X
No9
IPC 2071
IPC 215
IPC 22621
No10
DIF7
Tabela de Roteamento{61=61, 62=62, 621 = 62, 611 = 61, 6111 = 61 }
Figura 4.7 – Topologia de uma rede RINA
Enquanto no BGP os escopos de roteamento são segmentados em Sistemas Autônomos,
na RINA eles são segmentados em DIFs. Sempre que um processo IPC dentro de uma DIF
precisa se conectar a um processo IPC que está em outra DIF, é criada uma terceira DIF, de
nível superior, para permitir essa conexão (WANG; ESPOSITO; MATTA, 2013). Na figura
4.7, essa DIF de nível superior é a DIF 6 e ela interliga processos IPC de várias outras DIFs de
nível inferior.
Na figura 4.7 nota-se que há dois caminhos alternativos entre o remetente e o
destinatário: o caminho de cima e o caminho de baixo. O caminho de cima é formando pelos
processos IPC 1, 2, 3, 4, 5, 6, 7 e 8. O caminho de baixo é formado pelos processos IPC 9, 10,
11, 12, 20, 21, 13 e 56.
As aplicações remetente e destinatário vistas na figura 4.7 são mantidas pelos processos
IPC subjacentes a elas. Para estabelecer a conexão com o destinatário, o remetente do cenário
da figura 4.7 não faz uso de uma rota como ocorreria com o BGP. Observando-se a tabela de
roteamento do IPC 15 na figura 4.7, percebe-se que para chegar ao destinatário (endereço 6111)
o remetente sabe somente que o próximo salto é o seu vizinho cujo endereço é 61. Ou seja, o
remetente só conhece o próximo salto para chegar ao destinatário e não todos os saltos do
caminho através de uma rota completa como ocorre no BGP.
No caso de haver queda em um dos saltos (processos IPC) do caminho que está sendo
usado para conectar o remetente ao destinatário, todos os saltos desse cenário teriam que ser
afetados e deveriam convergir para que o outro caminho passasse a ser usado.
44
Porém no cenário visto na figura 4.8, caso houvesse uma falha em um dos caminhos,
somente os saltos próximos a essa falha seriam afetados por ela. Como a rede RINA não
depende de rotas, no cenário da figura 4.8, os processos IPC que mantêm a aplicação remetente
e destinatário sequer saberiam que houve a queda.
No capítulo 5 serão apresentados alguns resultados de experimentos que demonstram
vantagens dessa forma de se fazer roteamento proposta na RINA quando comparada à forma
tradicional, presente na Internet atual.
DIF 2
IPC 622
IPC 5 2
Nó8
IPC 721
DIF1
IPC18 111
IPC 8211
Nó2
IPC 4 3
IPC15 1
DIF 3
IPC 9 4
IPC19 1111
DIF 4 DIF 6
Nó1 Nó3 Nó5
IPC 3 31
IPC 10 41
IPC 1 51
IPC13 121
AppDestinatario
Nó6
IPC 12 61
Nó7
IPC20 11111
AppRemetente
IPC16 13
IPC17 11
IPC 11 6
IPC 2 5
DIF 5
IPC14 12
Nó4
X
X
Figura 4.8 - Topologia de uma rede RINA
4.6 APIs Java paraThreads e Sockets
Java disponibiliza a concorrência para o programador de aplicativos por meio de suas
classes que fazem parte da API para threads. A principal função dos threads é permitir que os
programadores especifiquem atividades concorrentes, ou seja, a realização de mais de uma
atividade por vez.
Para (DEITEL, 2004), de forma semelhante ao que ocorre com um processo, um thread
também pode permanecer em vários estados diferentes como pode ser visto na figura 4.9. A
interface Runnnable, presente na API do Java para threads, é o modo mais usado para criar
aplicativos concorrentes. Ela declara um único método chamado run, (JAVA, 2016).
45
Figura 4.9 – Possíveis estados de um thread
Fonte: (DEITEL, 2004)
Com sockets de fluxo, um processo pode estabelecer uma conexão com outro processo.
Enquanto a conexão estiver ativa, os dados fluem entre os processos em um fluxo contínuo
(ANGELL, 2001).
No ProtoRINA, a API para threads foi usada para representar os processos de
comunicação (processo IPC) propostos na arquitetura RINA. Já os sockets foram usados para
estabelecer conexões entre os processos IPC e também para troca de mensagens.
Na figura 4.10 vê-se um trecho de código fonte usado para personalizar um processo
IPC remetente de modo que ele passasse a enviar uma determinada quantidade de mensagens
para o processo IPC destinatário. Após o envio de cada mensagem coloca-se a thread em estado
de espera por 1 segundo (figura 4.10-D) antes de se iniciar o próximo envio. Essa pausa de 1
segundo foi feita para que essas mensagens enviadas na rede RINA tivessem o mesmo tempo
das mensagens ICMP (Internet Control Message Protocol) enviadas na rede que emulou o
comportamento da Internet atual.
46
Figura 4.10 Personalização para envio de mensagens
4.7 Ferramenta para cálculo de RTT
Além do envio de mensagens, a figura 4.10 também mostra a primeira fase de execução
da ferramenta que foi desenvolvida nesse trabalho, para cálculo de RTT. Inicialmente compõe-
se uma string contendo apenas o número de sequência da mensagem enviada (figura 4.10-A).
Depois se guarda, num arquivo de texto, o timestamp do momento no qual a mensagem é
enviada (figura 4.10-B). Usa-se sockets para fazer alocação de fluxo com a aplicação
destinatário e enviar a mensagem através desse fluxo alocado (figura 4.10-C).
A aplicação no destinatário também foi personalizada. Mais uma vez foram usados os
métodos da API Java para que se conseguisse monitorar os sockets, procurando-se por
mensagens de chegada. Desta forma, quando o destinatário percebe que chegou uma
mensagem, ele imediatamente envia uma mensagem de resposta ao remetente.
Os sockets também são monitorados no remetente e guarda-se, no arquivo de texto, o
timestamp do momento no qual a mensagem de resposta chegou. Desta forma, durante a troca
de mensagens entre remetente e destinatário tem-se, em um mesmo arquivo de texto, os
timestamps do momento no qual a mensagem foi enviada e do momento de chegada da
mensagem de resposta.
47
4.8 Considerações Finais
Neste capítulo foi feita uma apresentação sobre a construção do ambiente de emulação
e sobre as ferramentas utilizadas nessa construção. Dentre essas ferramentas foi apresentada a
que foi construída para cálculo de RTT, porém somente a sua primeira fase de execução. No
próximo capítulo será descrita a forma como foi feita a coleta de dados nesse trabalho com o
uso da segunda fase de funcionamento da ferramenta para cálculo de RTT. Além disso serão
descritas outras ações efetuadas para a avaliação da convergência de roteamento da arquitetura
RINA.
48
5 COMPARAÇÃO DO DESEMPENHO DAS CONVERGÊNCIAS DE
ROTEAMENTO SOB OS CENÁRIOS PROPOSTOS
Nesse capítulo será descrita a forma como se deu a avaliação da convergência de
roteamento da arquitetura RINA quando comparada à convergência da Internet atual. Serão
vistos os cenários (RINA e BGP) usados para a comparação e será descrita a forma como se
deu a coleta de dados através do uso de uma ferramenta desenvolvida nesse trabalho cujo
funcionamento também será descrito. Finalmente, serão discutidos os resultados obtidos.
5.1 Definição dos experimentos
Os experimentos feitos nesse trabalho buscam avaliar o impacto do tempo de
convergência sobre o tempo de resposta na rede RINA quando comparado ao impacto causado
na Internet atual.
Na seção 2.1, o tempo de convergência foi definido como uma métrica que indica o
quão rápido um grupo de roteadores reage a uma mudança em um ou mais caminhos da
topologia efetuando ações para passar a usar outro caminho. Viu-se também nessa seção, que o
tempo gasto com essa reação provoca um aumento no tempo de resposta da rede. Desta forma,
os experimentos desse trabalho avaliam o impacto do tempo de convergência sobre o tempo de
resposta da rede medindo para isso o RTT.
Para medição do RTT, conforme descrito na sessão 4.7, foram usadas mensagens ICMP
para a emulação da Internet atual. Já para emulação da RINA as mensagens foram manipuladas
com o uso de threads e sockets.
Foram construídos seis pares de cenários com o objetivo de experimentar o
comportamento da RINA quando convergências de roteamento são necessárias. Para
representar a Internet atual, cada cenário do RINA tem um par, com uma topologia semelhante,
porém emulando o comportamento do protocolo BGP.
Os nós da rede RINA são constituídos por instâncias do protótipo ProtoRINA.
Representando o funcionamento da Internet atual, os pares de cenários que emulam o
comportamento do BGP são constituídos por quantidades variadas de Sistemas Autônomos
dentro dos quais há roteadores e em alguns casos computadores. Para emular o comportamento
dos roteadores BGP utilizou-se o software Quagga que foi detalhado na sessão 4.3.
49
Conforme visto na seção 3.2 são propostas, na arquitetura RINA, estratégias de
roteamento completamente diferentes daquelas vigentes na Internet atual. Os cenários foram
personalizados para possibilitar as comparações entre as estratégias de roteamento propostas na
arquitetura RINA e aquelas presentes na arquitetura atual da Internet.
Na figura 5.1, por exemplo, vemos um cenário tipicamente encontrado na Internet atual
com o protocolo BGP. Esse cenário tem como componentes principais: o destinatário e o
remetente; uma determinada quantidade de saltos que são os roteadores e alguns escopos de
roteamento que são os Sistemas Autônomos. Já na figura 5.2 vemos o cenário par, para a RINA,
daquele cenário visto na figura 5.1. As semelhanças entre os pares de cenários são evidenciadas
pelas características comuns. Dentre essas características destaca-se: a mesma quantidade de
saltos entre a origem e o destino, a mesma quantidade de escopos de roteamento e a mesma
quantidade de caminhos em potencial.
De acordo com o que foi explicado no capítulo 2 (BGP) e no capítulo 3 (RINA), algumas
características são totalmente diferentes entre RINA e BGP, por isso já era de se esperar que os
cenários também mostrassem essas diferenças. Como exemplo dessas diferenças, no BGP
(figura 5.1), os saltos são roteadores que têm as suas placas de rede endereçadas, já na RINA
(figura 5.2), os processos de comunicação é que são individualizados com endereços. No BGP
temos uma ligação direta entre os escopos de roteamento (SA), na RINA temos uma DIF de
nível superior que junta diferentes DIFs de nível inferior. Além dessas, a principal diferença
proposta na RINA e vista nos cenários é a forma como os caminhos são descobertos e mantidos,
sem dependência de rota, conforme proposto em (DAY, 2008).
Figura 5.1–Cenário do BGP
50
Figura 5.2- Cenário da RINA
5.1.1 Coleta de dados
Os gráficos da próxima seção mostram os resultados das comparações do tempo de
resposta entre RINA e BGP nos seis pares de cenários.
Nos gráficos, o tempo de resposta varia em função da quantidade de quedas devido à
influência do tempo de convergência. Em todas as topologias, de todos os pares de cenários, há
dois caminhos entre o remetente e o destinatário como pode ser visto nas figuras 5.1 e 5.2. O
script Python que faz a orquestração dos cenários disponibiliza, inicialmente, apenas um desses
caminhos e depois de um determinado tempo, esse mesmo script, liga o caminho que estava
inoperante e desliga o que estava em funcionamento. Desta forma, o script força, por um
determinado número de vezes, que ocorra a convergência para o caminho que ficou operante.
O tempo no qual o script força a convergência foi definido de forma que se tivesse certeza de
que antes da próxima convergência a anterior já tivesse sido concluída.
Enquanto as convergências provocadas pelas quedas de caminho ocorrem, os dados
sobre os tempos de resposta na rede, calculados através do RRT, são colhidos e armazenados
em um arquivo de texto. Ou seja, cada gráfico mostra a variação do tempo de resposta, para a
RINA e para o BGP, em função das quedas.
51
Foi construída uma ferramenta para coletar os dados dos pares de cenários e calcular os
RTTs. Essa ferramenta funciona em duas fases distintas. Na primeira fase a ferramenta funciona
dentro dos cenários RINA ou BGP, precisamente nos remetentes.
No caso do BGP, a primeira fase da ferramenta usa o TCPDUMP18 para “ouvir” o
protocolo ICMP. É utilizado o comando ping do remetente para o destinatário e desta forma a
ferramenta grava o timestamp do momento no qual a mensagem de requisição ICMP foi enviada
e também do momento no qual a mensagem ICMP de retorno chegou. A figura 5.3 mostra um
trecho desse arquivo que guarda as mensagens de requisição e de retorno.
Figura 5.3 - Arquivo com registros de requisição e retorno do BGP
Na RINA, a primeira fase da ferramenta para cálculo dos tempos de resposta funciona
também dentro do remetente, porém utilizou-se a troca de mensagens e também a audição da
rede RINA através do uso de threads e sockets do Java que foram explicados com mais detalhes
na sessão 4.6.
A cada segundo envia-se uma mensagem do remetente para o destinatário e observa-se
o seu timestamp de requisição e de retorno exatamente da mesma forma que se fez com o uso
do protocolo ICMP nos cenários relativos ao BGP. A figura 5.4 mostra um trecho do arquivo
que guarda as mensagens de requisição e retorno da rede RINA.
Figura 5.4 - Arquivo com registros de requisição e retorno da RINA
18http://www.tcpdump.org/tcpdump_man.html - acessado em 06/05/17
52
A segunda fase da ferramenta funciona de forma comum para RINA e BGP. Essa fase
é constituída de um script Python que lê o arquivo no qual foram registrados os timestamps e
efetua a diferença entre o tempo de partida de mensagem de requisição e o tempo de chegada
da mensagem de retorno, obtendo com isso, o RTT. Essa segunda fase da ferramenta limita a
quantidade de RTTs calculados somente à última queda. Assim, tem-se a cada
queda/convergência de caminho, somente a amostra de dados que contém os RTTs relativos,
especificamente, a essa queda/convergência. Na sequência, a ferramenta calcula a média dos
RTTs dessa última queda.
5.2 Resultados Obtidos
Nos cenários mostrados na figura 5.1 (RINA) e na figura 5.2 (BGP) pode-se ver as
primeiras duas topologias comparadas. O gráfico 1 mostra que nas topologias desses cenários
iniciais, as estratégias de roteamento propostas na RINA e aquelas vigentes na Internet atual,
têm desempenhos parecidos. Pode-se afirmar isso porque no gráfico 1 é possível notar que em
alguns momentos a RINA tem um melhor desempenho na rede, apresentando tempos de
resposta inferiores. Já em outros momentos o BGP é que tem tempos de resposta menores.
Gráfico 5.1- Semelhança na comparação entre RINA e BGP
53
A tabela 5.1 mostra as médias e também os intervalos de confiança dos dados do par de
cenários da figura 5.1 (RINA) e da figura 5.2 (BGP) com um nível de confiança de 95%. A
tabela 5.1 mostra que a média dos tempos de resposta do BGP está dentro dos limites do
intervalo de confiança do RINA e que a média do RINA está próxima19 dos limites do intervalo
de confiança do BGP. Segundo (JAIN, 1991), quando se deseja comparar dois sistemas
submetidos a cargas semelhantes pode-se calcular as médias e os intervalos de confiança e se a
média de um dos sistemas estiver dentro do intervalo de confiança do outro pode-se afirmar
que eles são equivalentes.
Tabela 5.1 - Semelhança na comparação entre RINA e BGP
BGP RINA
Limite Inferior Média Limite Superior Limite Inferior Média Limite Superior
486 ms 544 ms 603 ms 408 ms 483 ms 557 ms
Essa semelhança no desempenho da convergência do roteamento vista no gráfico 1 e na
tabela 5.1 é devida ao fato de que, nessa topologia, todos os escopos de roteamento têm,
necessariamente, que ser atualizados no momento da convergência. Porém há situações, nas
convergências que ocorrem na Internet atual, nas quais nem todos os escopos de roteamento
precisariam ser envolvidos. Mesmo nesses casos o BGP envolve todos esses escopos porque,
conforme visto no capítulo 2, ele trabalha com dependência de rota através do uso das
mensagens do tipo UPDATE e tem o seu funcionamento comprometido por anomalias como a
“Chattiness of BGP”. Por outro lado, o que se propõe na RINA, conforme visto no capitulo 3,
é uma convergência com um escopo menor e com granularidade fina.
Na figura 5.6 nota-se mais uma típica topologia da Internet atual que envolve o
protocolo BGP. Os roteadores R12 e R14 foram interrompidos pelo script Python para forçar a
convergência entre os dois caminhos vistos na imagem. Mais uma vez, enquanto os caminhos
se revezavam, a ferramenta desenvolvida nesse trabalho, calculou os RTTs. Essas mesmas
ações foram feitas para o cenário RINA visto na figura 5.7. Nota-se que nesse par de cenários
das figuras 5.6 e 5.7 há um total de três escopos de roteamento em cada par, ou seja, três DIFs
no cenário da RINA e três Sistemas Autônomos no cenário do BGP.
19 Como a média do RINA ficou próxima, mas não ficou dentro dos limites do intervalo de confiança do
BGP, foi feito o teste Z para a hipótese da diferença entre as médias ser nula e esse teste indicou aceitação para
essa hipótese.
54
Figura 5.6 - Cenário BGP com 3 escopos de roteamento.
Figura 5.7 - Cenário RINA com 3 escopos de roteamento
O gráfico 2 ainda demonstra similaridade no tempo de resposta da RINA e do BGP.
Porém será observado adiante a superioridade da RINA na medida em que se aumenta o
tamanho das topologias, adicionando escopos de roteamento em ambos os lados do escopo
central: DIF 1 para a RINA e AS 65021 para o BGP.
Remetente Destinatário
55
Gráfico 5.2– RINA x BGP com 3 escopos
As figuras 5.8 e 5.9 mostram outro par de cenários com mais um escopo de roteamento
acrescido em cada lado do escopo central e entre o destinatário e o remetente. Esse par de
cenários possui um total de cinco escopos de roteamento. O gráfico 5.3 começa a revelar uma
vantagem no tempo de resposta da RINA em relação ao do BGP.
Figura 5.8 - Cenário BGP com 5 escopos de roteamento
Remetente Destinatário
56
Figura 5.9 - Cenário RINA com 5 escopos de roteamento
Gráfico 5.3 RINA x BGP com 5 escopos
Na figura 5.10, na figura 5.11 e no gráfico 5.4, nota-se o aumento da vantagem da
estratégia de roteamento proposta na arquitetura RINA em relação ao protocolo BGP. Essa
vantagem é evidenciada pelo menor tempo de resposta da RINA em comparação com o tempo
de resposta do BGP. Os cenários mostrados nessas figuras têm um total de sete escopos de
roteamento.
57
Figura 5.10–Cenário BGP com 7 escopos de roteamento
Figura 5.11– Cenário RINA com 7 escopos de roteamento
Gráfico 5.4 – RINA x BGP com 7 escopos
Para completar a demonstração da comparação da arquitetura RINA com o protocolo
BGP, observa-se na figura 5.12 e na figura 5.13 um par de cenários com 9 escopos de
Remetente Destinatário
58
roteamento. No gráfico 5.5 fica clara a superioridade no desempenho da RINA que apresenta
tempos de resposta mais baixos mesmo quando submetida à mesma quantidade de
convergências do BGP.
Figura 5.12– Cenário BGP com 7 escopos de roteamento
Figura 5.13– Cenário RINA com 9 escopos de roteamento
Gráfico 5.5 – RINA x BGP com 9 escopos
Remetente Destinatário
59
5.3 Discussão
Conforme detalhado no capítulo 2, o BGP descobre e mantém os caminhos que
interligam os remetentes aos destinatários com total dependência de rota. Os roteadores se
comunicam com seus pares através de mensagens de UPDATE e um dos principais objetivos
dessas mensagens é justamente manter as rotas. Para chegar num determinado destino, o pacote
do remetente segue pelos diversos roteadores (saltos) de um caminho que foram previamente
configurados, de forma automática, com a rota correta.
Quando ocorre uma convergência, devido a uma queda ou à descoberta de um caminho
melhor, todos os roteadores no caminho são afetados por ela e têm que convergir para o novo
caminho. Até mesmo aqueles roteadores que não têm relação com a convergência são afetados
por ela no BGP.
Segundo o que foi abordado no capítulo 3, na arquitetura RINA é proposta uma forma
diferente para se descobrir e manter os caminhos na rede. Nessa forma proposta na RINA não
existe dependência de rota. Logo, quando ocorre uma mudança na rede que obrigue a ida para
outro caminho, somente os saltos envolvidos nessa mudança são afetados por ela. Desta forma,
participam da convergência para o novo caminho, uma quantidade de componentes menor do
que os que participam da convergência no BGP.
Como há uma quantidade menor de componentes participando da convergência na rede
RINA, essa convergência ocorre de forma mais rápida e consequentemente, o tempo de resposta
nessa rede é menor mesmo quando várias mudanças de caminho estão ocorrendo. Em outras
palavras, RINA precisa espalhar as informações de roteamento por um escopo menor que o
escopo do BGP.
Foi feito um resumo dos experimentos dos cenários anteriores no gráfico 6. Deste modo,
ele mostra a variação no tempo de resposta em função do aumento da quantidade de escopos de
roteamento.
60
Gráfico 5.6 – RINA x BGP
O gráfico 5.6 mostra, claramente, que a rede RINA oferece um melhor suporte para as
convergências diante do aumento da quantidade de escopos de roteamento. Os intervalos de
confiança desse gráfico foram calculados com um nível de confiança de 95%.
Esse melhor suporte disponível na arquitetura RINA é algo necessário na Internet atual
porque nela, os escopos de roteamento que separam os remetentes dos destinatários, sofrem
constates alterações em seus tamanhos.
Conforme demonstrado nas experimentações descritas nesse capítulo, a estratégia de
roteamento proposta na arquitetura RINA é mais eficiente quando comparada àquela utilizada
na Internet atual. Essa afirmação é feita diante dos resultados obtidos, pois a RINA apresentou
um desempenho melhor com tempos de resposta mais baixos.
5.4 Considerações Finais
Esse capítulo descreveu a forma como se deu a avaliação da convergência de roteamento
da arquitetura RINA, bem como os cenários e ferramentas usadas nessa avaliação. Também foi
feita uma discussão baseada nos resultados obtidos. No próximo capítulo serão apresentadas as
conclusões do trabalho assim como propostas de trabalhos futuros.
61
6 CONCLUSÕES E TRABALHOS FUTUROS
Neste trabalho foi feita uma verificação das estratégias para convergências de
roteamento propostas na arquitetura RINA em comparação com as estratégias vigentes na
Internet atual.
Depois de um levantamento teórico sobre o roteamento na Internet atual e na arquitetura
RINA, o protótipo ProtoRINA foi personalizado de forma que pudesse ser implementado sobre
ambientes como FIBRE, Mininet ou até mesmo em uma rede TCP/IP real com computadores e
switches. Isso trouxe uma contribuição para futuras pesquisas em RINA, pois essa versão
personalizada pode ser usada em outros trabalhos em todos esses ambientes.
Na sequência, conforme demonstrado no capítulo quatro, foi proposto um ambiente para
tornar possível a verificação das estratégias de roteamento da arquitetura RINA em comparação
com as estratégias da Internet atual. Esse ambiente foi construído com auxílio do Mininet, do
ProtoRINA, do Quagga e disponibilizou meios para que fossem feitas experimentações
práticas.
Ambientes nos quais se consiga experimentar características da arquitetura RINA ainda
não são comuns. Isso ocorre por se tratar de uma proposta de arquitetura de rede clean slate,
cujo comportamento não comunga com as redes atuais que têm o seu funcionamento baseado
na pilha de protocolos TCP/IP. Desta forma, esse ambiente construído no Mininet também pode
funcionar como auxílio para outros pesquisadores interessados no mesmo assunto.
No capítulo cinco, usando-se o ambiente construído no Mininet, foi feita uma avaliação
do desempenho das convergências de roteamento da arquitetura RINA em comparação com as
convergências praticadas na internet atual pelo protocolo BGP. Constatou-se nessa avaliação
que os tempos de resposta da rede RINA são menores do que os tempos da Internet atual,
mesmo quando as duas arquiteturas são submetidas a convergências de roteamento provocadas
por quedas de caminhos.
Concluiu-se dessa forma que a arquitetura RINA apresenta propostas de estratégias de
roteamento superiores às estratégias em prática na Internet atual. Pode-se afirmar isso, diante
dos resultados da comparação efetuada.
Diante do exposto, percebe-se que o presente trabalho permitiu verificar de forma
genérica soluções propostas na arquitetura RINA para alguns dos diversos problemas que
limitam o crescimento da Internet atual como: segurança, multihoming, roteamento e outros.
Percebe-se também que, de forma mais específica, o trabalho permitiu a verificação da
62
estratégia de roteamento proposta em RINA comparando-a com o que se pratica na Internet
atual.
Como trabalho futuro, é interessante que o ambiente seja ampliado para permitir
comparações com outras vertentes da proposta RINA tais como: gerenciamento, segurança,
controle de tráfego e outros.
Também seria interessante, como trabalhos futuros, a adição aos estudos realizados, de
técnicas envolvendo NFV (Network Functions Virtualization). Essas técnicas permitiriam
experimentação mais precisa da forma como a arquitetura RINA propõe a expansão sob
demanda dos escopos de comunicação representados pelas DIFs. Isso seria demonstrado de
forma melhor com o uso de NFV, pois seria possível acrescentar aos ambientes de emulação
rápida modificação dos recursos de rede em tempo real.
63
REFERÊNCIAS
ANGELL, K. W. The Java Secure Socket Extensions. Dr. Dobb’s Journal of Software
Tools, v. 26, n. 2 (2001), p. 21–22, 24, 26, 28, 2001.
BASIT, A.; AHMED, N. Path diversity for Inter-domain Routing security. 14th
International Bhurban Conference on Applied Sciences and Technology (IBCAST) jan. 2017,
[S.l.]: IEEE, jan. 2017. p. 384–391. Disponível em:
<http://ieeexplore.ieee.org/document/7868083/>. Acesso em: 28 abr. 2017.
BENJAMIN, H. CCNP Practical Studies : Routing CCNP ® Practical Studies : Routing.
Scenario, p. 1–498, 2002.
BIFFI, C. A.; TUISSI, A. Stato dell’arte sulle tecniche di produzione additiva per
metalli. Metallurgia Italiana, v. 109, n. 1, p. 5–10, 2017.
BUTLER, K. et al. A survey of BGP security issues and solutions. Proceedings of the
IEEE, v. 98, n. 1, p. 100–122, 2010.
CAESAR, M. et al. ROFL: Routing on Flat Labels. Proceedings of the ACM SIGCOMM
2006 Conference on Applications, Technologies, Architectures, and Protocols for Computer
Communications, v. 36, n. 4, p. 363–374, 2006. Disponível em:
<http://delivery.acm.org/10.1145/1160000/1159955/p363-
caesar.pdf?ip=186.237.55.66&id=1159955&acc=PUBLIC&key=344E943C9DC262BB.5C8E
39E7CA3AB3A2.4D4702B0C3E38B35.4D4702B0C3E38B35&CFID=758620273&CFTOK
EN=79278344&__acm__=1493893470_7cf69d88915908335d9f928>. Acesso em: 4 maio
2017.
CAMPISTA, M. E. M. et al. Challenges and Research Directions for the Future
Internetworking. IEEE Communications Surveys & Tutorials, v. 16, n. 2, p. 1050–1079, 2014.
Disponível em: <http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=6644748>.
Acesso em: 3 maio 2017.
CHANDRA, R. BGP Route Reflection: An Alternative to Full Mesh IBGP RFC 1966.
IETF, p. 1–8, 1996. Disponível em: <https://tools.ietf.org/html/rfc2796>. Acesso em: 2 maio
2017.
CHANDRASHEKAR, J. et al. Limiting path exploration in BGP. Proceedings - IEEE
INFOCOM, vol. 4, 2005. p. 2337–2348.
CISCO. Cisco Networking Academy Connecting Networks Companion Guide:
Hierarchical Network Design. Cisco Press. [S.l: s.n.]. Disponível em:
<http://www.ciscopress.com/articles/article.asp?p=2202410&seqNum=4>. , 2014
D.L. MILLS. Exterior Gateway Protocol Formal Specification. Historic, RFC 904,
IETF, April 1984, p. 1–30, 1984. Disponível em: <https://tools.ietf.org/html/rfc904>. Acesso
em: 1 maio 2017.
DAY, J. Patterns in Network Architecture: A Return to Fundamentals. [S.l.]: Pearson
Education, 2008.
DAY, J.; MATTA, I.; MATTAR, K. Networking is IPC: a guiding principle to a better
internet. ACM CoNEXT, p. 67, 2008. Disponível em:
<http://portal.acm.org/citation.cfm?id=1544079>.
DEITEL, H. P. D. Java How to Program (7th Edition). Editora: Prentice Hall Usa,
2007, isbn: 9780132222204.
64
FELDMANN, A. Internet Clean-Slate Design : What and Why ? Computer
Communication Review, v. 37, n. 3, p. 59–64, 2007.
FISHER, D. A look behind the future internet architectures efforts. ACM SIGCOMM
Computer Communication Review, v. 44, n. 3, p. 45–49, 2014. Disponível em:
<http://dl.acm.org/citation.cfm?doid=2656877.2656884>.
GEORGIOS, E. et al. Next-Generation Internet Architectures and Protocols. [S.l: s.n.],
2011.
GODAN, F.; COLMAN, S.; GRAMPIN, E. Multicast BGP with SDN control plane.
International Conference on the Network of the Future, IEEE, nov. 2017. p. 1–5. Disponível
em: <http://ieeexplore.ieee.org/document/7810140/>. Acesso em: 28 abr. 2017.
GROSS, P. Choosing a Common IGP for the IP Internet. RFC 1371, IETF, 1992.
Disponível em: <https://tools.ietf.org/html/rfc1371>. Acesso em: 1 maio 2017.
HANDIGOL, N. et al. Reproducible network experiments using container-based
emulation. 2012, New York, New York, USA: ACM Press, 2012. p. 253. Disponível em:
<http://dl.acm.org/citation.cfm?doid=2413176.2413206>. Acesso em: 27 abr. 2017.
HONGBO, Z.; KITSUWAN, N. Measuring of failure switch-over time in software-
defined network. IEEE International Conference on High Performance Switching and Routing,
HPSR, IEEE, jun. 2016. p. 118–119. Disponível em:
<http://ieeexplore.ieee.org/document/7525653/>. Acesso em: 28 abr. 2017.
ISHAKIAN, V.; MATTA, I.; AKINWUMI, J. On the cost of supporting mobility and
multihoming. 2010 IEEE Globecom Workshops, GC’10, n. 2, p. 310–314, 2010.
J. HAWKINS, T. B. Guidelines for creation, selection, and registration of an
Autonomous System (AS). RFC 1930, IETF, Networ Networking Group Best Current Practices.
[S.l: s.n.], 1996. Disponível em: <https://tools.ietf.org/html/rfc1930>. Acesso em: 1 maio 2017.
JAIN, R. The Art of Computer Systems Performance Analysis. Performance
Evaluation, p. 179–200, 1991.
JAKMA, P.; LAMPARTER, D. Introduction to the Quagga Routing Suite. IEEE
Network. [S.l: s.n.]. Disponível em: <http://ieeexplore.ieee.org/document/6786612/>. Acesso
em: 28 abr. 2017. , mar. 2014
JAVA WEB PAGE. Learn About Java Technology. Disponível em:
<https://www.java.com/en/about/>. Acesso em: 22 abr. 2017
KHONDOKER, R. et al. Security of Selected Future Internet Architectures: A Survey.
2014 Eighth International Conference on Innovative Mobile and Internet Services in
Ubiquitous Computing, p. 433–440, 2014. Disponível em:
<http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=6975502>.
KUROSE, J. F., & ROSS, K. W. REDES DE COMPUTADORES Uma abordagem top-
Down. Editora: Pearson Education, 2010.
LABOVITZ, C. et al. Delayed internet routing convergence. IEEE/ACM Transactions
on Networking, v. 9, n. 3, p. 293–306, 2001.
LANTZ, B.; HELLER, B.; MCKEOWN, N. A network in a laptop. 2010, Proceedings
of the Ninth ACM SIGCOMM Workshop on Hot Topics in Networks - Hotnets '10, New York,
USA: ACM Press, 2010. p. 1–6. Disponível em:
<http://portal.acm.org/citation.cfm?doid=1868447.1868466>. Acesso em: 27 abr. 2017.
LUIZ, C.; MONTEIRO, J. A. S. Investigação do Protótipo ProtoRINA utilizando o
65
Ambiente FIBRE. Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos
(SBRC), p. 1–4, 2016. Disponível em:
<http://www.sbrc2016.ufba.br/downloads/WPEIF/154481_1-Investigacao-do-ProtoRINA-
Ambiente-FIBRE.pdf>. Acesso em: 2 maio 2017.
MARCHETTA, P. et al. Dissecting round trip time on the slow path with a single
packet. Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial
Intelligence and Lecture Notes in Bioinformatics), 2014. p. 88–97.
MARTIN, D.; VÖLKER, L.; ZITTERBART, M. A flexible framework for Future
Internet design, assessment, and operation. Computer Networks, v. 55, n. 4, p. 910–918, 2011.
Disponível em: <http://dx.doi.org/10.1016/j.comnet.2010.12.015>.
MOUBARAK, M. T.; ELBAYOUMY, A. D.; MEGAHED, M. H. Design and
implementation of BGP novel control mechanism (BGP-NCM) based on network performance
parameters. Ain Shams Engineering Journal, 2017. Disponível em:
<http://www.sciencedirect.com/science/article/pii/S2090447917300345>. Acesso em: 2 maio
2017.
MOY, J. OSPF Version 2. RFC 2328, IETF, v. 53, n. 9, p. 1689–1699, abr. 1998.
Disponível em: <https://www.rfc-editor.org/info/rfc2328>. Acesso em: 1 maio 2017.
OHSAKI, H. et al. On Modeling Round-Trip Time Dynamics of the Internet using
System Identication. Time, n. 1, p. 1–9, 2002.
OLEKSANDR, L.; OLENA, N.; TETIANA, V. Hierarchical coordination method of
inter-area routing in telecommunication network. IEEE International Scientific Conference
"Radio Electronics and Info Communications", UkrMiCo 2016 - Conference Proceedings
IEEE, 2016. p. 135–138. Disponível em: <http://ieeexplore.ieee.org/document/7905359/>.
Acesso em: 1 maio 2017.
PAN, J.; PAUL, S.; JAIN, R. A survey of the research on future internet architectures.
Communications Magazine, IEEE, v. 49, n. 7, p. 26–36, 2011.
POWELL, W. B.; JAILLET, P.; ODONI, A. Network Routing. [S.l.]: Elsevier, 1995. v.
8. Disponível em: <http://www.sciencedirect.com/science/article/pii/S0927050705801070>.
REKHTER, Y.; LI, T.; HARES, S. A Border Gateway Protocol 4 (BGP-4). RFC 1771.
[S.l: s.n.], 2006. Disponível em: <https://tools.ietf.org/html/rfc1654>. Acesso em: 1 maio 2017.
SALSANO, S. et al. OSHI - Open source hybrid IP/SDN networking (and its emulation
on mininet and on distributed SDN testbeds). 3rd European Workshop on Software-Defined
Networks, EWSDN, set. 2014. p. 13–18. Disponível em:
<http://ieeexplore.ieee.org/document/6984045/>. Acesso em: 28 abr. 2017.
SOUSA, B. M.; PENTIKOUSIS, K.; CURADO, M. Multihoming management for
future networks. Mobile Networks and Applications, v. 16, n. 4, p. 505–517, 2011.
TEGUEU, F. S. et al. Towards application driven networking. IEEE Workshop on Local
and Metropolitan Area Networks, IEEE, jun. 2016. Disponível em:
<http://dl.acm.org/citation.cfm?doid=2934872.2959075>. Acesso em: 5 maio 2017.
TROUVA, E. et al. Layer discovery in RINA networks. 17th International Workshop
on Computer Aided Modeling and Design of Communication Links and Networks, CAMAD
2012, set. 2012, IEEE. p. 368–372. Disponível em:
<http://ieeexplore.ieee.org/document/6335369/>. Acesso em: 4 maio 2017.
UL HAQUE, M. et al. Name-based routing for information centric future internet
architectures. 2013, [S.l: s.n.], 2013. p. 517–522.
66
VARGA, A. OMNeT++. Modeling and Tools for Network Simulation. Published by
Springer Berlin Heidelberg, 2010. p. 35–59. Disponível em:
<http://link.springer.com/10.1007/978-3-642-12331-3_3>.
VASSEUR, J.-P.; DUNKELS, A. Non-IP Smart Object Technologies. Interconnecting
Smart Objects with IP. [S.l: s.n.], 2010. p. 295–302. Disponível em:
<http://www.sciencedirect.com/science/article/pii/B9780123751652000193>.
VESELÝ, V. et al. Skip This Paper - RINASim: Your Recursive InterNetwork
Architecture Simulator. Proceedings of the “OMNeT++ Community Summit 2015, p. 1–5,
2015. Disponível em: <http://arxiv.org/abs/1509.03550>.
VISSICCHIO, S. et al. iBGP deceptions: More sessions, fewer routes. Proceedings -
IEEE INFOCOM: IEEE, mar. 2012. p. 2122–2130. Disponível em:
<http://ieeexplore.ieee.org/document/6195595/>. Acesso em: 1 maio 2017.
VRIJDERS, S. et al. Prototyping the recursive internet architecture: the IRATI project
approach. IEEE Network, v. 28, n. 2, p. 20–25, 2014. Disponível em:
<http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=6786609>.
WANG, Y. et al. Introducing ProtoRINA. ACM SIGCOMM Computer Communication
Review, v. 44, n. 3, p. 129–131, 2014. Disponível em:
<http://dl.acm.org/citation.cfm?id=2656877.2656897>.
WANG, Y.; ESPOSITO, F.; MATTA, I. Demonstrating RINA using the GENI testbed.
mar. 2013, [S.l.]: IEEE, mar. 2013. p. 93–96. Disponível em:
<http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=6601423>. Acesso em: 30
abr. 2017.
WANG, Y.; MATTA, I.; AKHTAR, N. Application-Driven Network Management with
ProtoRINA. Proceedings of the NOMS 2016 - 2016 IEEE/IFIP Network Operations and
Management Symposium. [S.l: s.n.], 2015. Disponível em:
<http://csr.bu.edu/rina/papers/BUCS-TR-2015-003.pdf>.
WANG, Y.; MATTA, I.; AKHTAR, N. Experimenting with Routing Policies Using
ProtoRINA over GENI. 2014 Third GENI Research and Educational Experiment Workshop, p.
61–64, 2014. Disponível em:
<http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=6877550>.
YANNUZZI, M.; MASIP-BRUIN, X.; BONAVENTURE, O. Open issues in
interdomain routing: A survey. IEEE Network, v. 19, n. 6, p. 49–56, 2005.
YOU, L. et al. An inter-domain multi-path flow transfer mechanism based on SDN and
multi-domain collaboration. Proceedings of the 2015 IFIP/IEEE International Symposium on
Integrated Network Management, IM 2015. IEEE, maio 2015. p. 758–761. Disponível em:
<http://ieeexplore.ieee.org/document/7140369/>. Acesso em: 1 maio 2017.
ZENG, P. et al. On the resilience of software defined routing platform. APNOMS 2014
- 16th Asia-Pacific Network Operations and Management Symposium. IEEE, set. 2014. p. 1–
4. Disponível em: <http://ieeexplore.ieee.org/document/6996605/>. Acesso em: 28 abr. 2017.
ZHANG, B.; MASSEY, D.; ZHANG, L. Destination reachability and BGP convergence
time. in Proc. of IEEE Globecom, Global Internet and Next Generation Networks, p. 1383–
1389, 2004.
ZHANG, H.; YAN, J. Performance of SDN Routing in Comparison with Legacy
Routing Protocols. set. 2015, [S.l.]: IEEE, set. 2015. p. 491–494. Disponível em:
<http://ieeexplore.ieee.org/document/7307865/>. Acesso em: 28 abr. 2017.
67
ZHOU, Haifeng et al. SDN-LIRU: A Lossless and Seamless Method for SDN Inter-
Domain Route Updates. IEEE/ACM Transactions on Networking, 2017. , p. 1–11. Disponível
em: <http://ieeexplore.ieee.org/document/7896622/>. Acesso em: 1 maio 2017.
68
ANEXO A – ROTEIROS DE EXPERIMENTAÇÕES NO FIBRE
De acordo com o explicado no capítulo 4, o protótipo ProtoRINA foi personalizado e
pode ser usado em experimentações em vários ambientes, dentre eles o FIBRE. Esse anexo
descreve roteiros que podem ser seguidos para a repetição de experimentos com o ProtoRINA
sobre o ambiente FIBRE.
ROTEIRO 1 – EXPERIMENTO DE REGISTRO DE IPC
➢ No arcabouço de controle Ofelia (OCF) foi criado e autorizado um novo projeto;
➢ Ao projeto foi adicionado um agregado com os recursos disponíveis na ilha da UFPE
do OCF
➢ Foi criado um slice e associado a ele o agregado previamente definido;
➢ Dentro do slice foram criadas 3 máquinas virtuais: Nó1, Nó2, Nó3;
➢ Esses 3 Nós se comportam como componente da rede RINA porque são nós
do ProtoRINA cujo comportamento foi personalizado.
➢ O Nó1 abriga o servidor IDD, já os Nós 02 e 03 se comportam como clientes RINA (nós
que contêm IPCs).
➢ Ao iniciar o Nó1, o IDD é iniciado e disponibiliza na rede RINA o serviço de localização
de IPCs.
➢ Ao iniciar o Nó2, são criados o IPC1 (gerente de DIF) e a DIF1.
69
➢ Ao iniciar o Nó3 ele passará a fazer parte da DIF1 (processo de registro). Nesse processo
de registro houve exigência de credenciais de autenticação.
➢ O arquivo de log do nó Nó2 mostra que o registro do IPC2 na DIF1 teve sucesso.
ROTEIRO 2 – EXPERIMENTO DE ALOCAÇÃO DE FLUXO E
TRANSFERÊNCIA DE DADOS
➢ Dentro do slice foram criadas 3 máquinas virtuais: Nó 1 (IDD), Nó 2, Nó 3;
➢ Ao iniciar o Nó1, o IDD é iniciado e disponibiliza na rede RINA o serviço de localização
de IPCs.
➢ Ao iniciar o Nó 01 dentro do qual reside o IPC 1, esse IPC passa a fazer parte da DIF 1.
A AppA usa o IPC 1 como o seu IPC subjacente.
70
➢ Depois que o primeiro nó foi iniciado, o segundo passo é iniciar o nó 02.
Dentro desse nó existe o IPC2 que se juntará à DIF 01 através do IPC01 (processo de
registro do roteiro 1). A App B usa o IPC 02 como o seu IPC subjacente.
➢ Como terceiro passo, a App B aloca um canal de comunicação com a App A. A
App A usa os serviços de comunicação providos pela DIF1 (nível subjacente). Com o
canal aberto, a App B envia mensagens para a App A.
71
ROTEIRO 3 – EXPERIMENTO DE FORMAÇÃO DINÂMICA DE DIF
➢ Dentro do slice foram criadas 4 máquinas virtuais: Nó 1 (IDD), Nó 2, Nó 3, Nó 4;
➢ Inicia-se o nó 02 dentro do qual residem dois IPCs: IPC 01 e IPC 03. Os IPCs 01 e 03
pertencem às DIFs 01 e 02, respectivamente. A App A (retransmissor) usa os IPCs 01
e 03 como IPCs subjacentes.
➢ O segundo passo é iniciar o nó 03, nele residem o IPC04 e a App C
(destinatário). A AppC usa o IPC 4 como nível inferior. O IPC 04 vai se juntar à DIF
02 através do IPC 3;
72
➢ O terceiro passo é iniciar o nó 1. Nele residem o IPC 2 e a App B (remetente). A App
B usa o IPC 02 como nível inferior. O IPC 02 vai se juntar à DIF 01 através do IPC
01. A App B vai tentar alocar fluxo para estabelecer um canal de comunicação com a
App C, porém essas Apps não têm uma DIF de nível inferior em comum. Para
resolver o problema, a AppB envia uma requisição para App A e a registra como
retransmissor (“relay service”).
➢ A App A cria a DIF 3 que tem o IPC5 como o seu primeiro membro (gerente). A App
A solicita à App B e à App C que criem novos IPCs (IPC6 e IPC7). Os IPCs 6 e 7 se
juntam à DIF 3 através do IPC5. Após o processo de criação dinâmica da DIF3, a App
B conseguirá alocar fluxo e criar um canal de comunicação com a App C.
73
ROTEIRO 4 – CONSTRUÇÃO DE TOPOLOGIA USADA PARA
EXPERIMENTOS DE ROTEAMENTO E MULTHOMING
➢ Dentro do slice foram criadas 5 máquinas virtuais: Nó 1 (IDD), Nó 2, Nó 3, Nó 4, Nó
5;
➢ Ao iniciar o Nó1, o IDD é iniciado e disponibiliza na rede RINA o serviço de localização
de IPCs.
➢ O Nó 1 possui o IPC 1 que por sua vez pertence à DIF1. O Nó 2 possui o IPC 2 que
entrará na DIF1 através do IPC1. O Nó 03 possui o IPC 3 e entrará na DIF1 ligando-se
ao IPC2.
➢ O nó 04 possui o IPC4 e entrará na DIF1 ligando-se ao IPC1 e ao IPC3. Agora há 2
caminhos com o mesmo custo interligando o IPC1 ao IPC3.
Top Related