OSPF

O protocolo OSPF ´e um dos objetos de estudo deste trabalho. Ele foi desenvolvido para atender `as necessidades colocadas pela Internet, que demandava um protocolo IGP eficiente, n˜ao propriet´ario e interoper´avel com outros protocolos de roteamento. Ele ´e enquadrado na categoria de protocolo de roteamento dinˆamico, respons´avel por encami- nhar os pacotes de rede pelo caminho mais curto e baseando-se no algoritmo de estado de enlace.

Para computar o caminho mais curto, o OSPF se baseia nos custos dos enlaces. O custo de um enlace ´e calculado conforme Equa¸c˜ao 3.1.

Custo = Largura de Banda de Referˆencia

Largura de Banda , (3.1) onde a largura de banda de referˆencia difere de equipamento para equipamento, sendo que a Equa¸c˜ao 3.1 ´e apenas uma recomenda¸c˜ao e n˜ao obrigatoriedade, pois ´e configur´avel.

Supondo uma largura de banda de referˆencia de 100 Gb/s e um enlace de 10 Gb/s usado para chegar ao destino, o custo desse enlace seria 10. J´a um enlace de 1 Gb/s teria custo 100. Portanto, o caminho escolhido usaria o enlace de 100 Gb/s. A Figura 3.2 mostra outro exemplo. O roteador R1 decide qual caminho escolher para se comunicar com R4 analisando as capacidades dos enlaces. O caminho superior, passando por R2, possui um custo total de 75, maior do que o custo do caminho inferior, passando por R3, que ´e igual a 30. Ent˜ao, R1 escolhe o caminho inferior como melhor caminho, uma vez que ele possui o menor custo.

Figura 3.2: Custo no protocolo OSPF. O caminho de menor custo ser´a sempre escolhido, sendo o custo total do caminho calculado como a soma dos custos dos enlaces que o comp˜oe. No exemplo, o caminho de menor custo entre R1 e R4 ´e R1-R3-R4.

O pacote OSPF sempre possui um cabe¸calho padr˜ao de 24 B. A Figura 3.3 mostra o conte´udo e o tamanho em bits de cada campo do cabe¸calho [15]. Os campos carregam as seguintes informa¸c˜oes:

• Vers˜ao: indica o n´umero da vers˜ao do protocolo OSPF; – 2: OSPFv2 opera com IPv4;

– 3: OSPFv3 opera com IPv6; • Tipo: indica o tipo do pacote OSPF;

• Tamanho do Pacote: indica o tamanho do pacote em bytes, incluindo o cabe¸calho; • ID do Roteador: indica o identificador do roteador que enviou o pacote;

• ID da ´Area: indica a ´area a qual o pacote pertence;

• Soma de Verifica¸c˜ao: ´e um c´odigo usado para verificar a integridade de dados trans- mitidos. ´E aplicado ao pacote completo, incluindo o cabe¸calho, mas excluindo os 64 bits de autentica¸c˜ao;

• Tipo de Autentica¸c˜ao: indica o tipo de autentica¸c˜ao a ser usado no pacote. Nor- malmente s˜ao trˆes op¸c˜oes;

– Sem Autentica¸c˜ao;

– Autentica¸c˜ao com senha simples;

– Autentica¸c˜ao MD5 (Message-Digest algorithm 5 );

• Autentica¸c˜ao: informa o esquema de autentica¸c˜ao a ser utilizado; – Sem Autentica¸c˜ao nada ´e especificado (´e usado por padr˜ao);

– Autentica¸c˜ao com senha simples nada mais ´e do que um simples texto;

– Autentica¸c˜ao MD5 permite usar uma chave de autentica¸c˜ao a ser configurada por rede, roteadores no mesmo dom´ınio devem ser configurados com a mesma chave. ´E usado um resumo criptogr´afico para que a senha n˜ao seja divulgada abertamente por toda a rede.

O OSPF possui cinco tipos distintos de pacotes: 1. Pacote de aviso (Hello packet );

2. Pacote de informa¸c˜oes do Banco de Dados (Database Description packet ); 3. Pacote de Requisi¸c˜ao de estado de enlace (Link State Request packet ); 4. Pacote de Atualiza¸c˜ao de estado de enlace (Link State Update packet );

5. Pacote de Reconhecimento de estado de enlace (Link State Acknowledgment packet ). O OSPF envia mensagens constantemente para manter a topologia da rede atua- lizada, essas s˜ao as mensagens Hello. Ap´os a convergˆencia das tabelas de roteamento, as mensagens com informa¸c˜oes sobre a topologia s˜ao enviadas apenas quando ocorre alguma altera¸c˜ao na topologia, isto ´e, quando um enlace ´e habilitado ou desabilitado, ou novos roteadores s˜ao inclu´ıdos na rede [8], essas s˜ao as mensagens Link State.

Quando um roteador ´e iniciado, o mesmo envia uma mensagem Hello por todas as suas linhas ponto-a-ponto, transmitindo-a por difus˜ao nas LANs (Local Area Network ) at´e o grupo que consiste em todos os outros roteadores. J´a para as WANs (Wide ´Area Network ), o roteador precisa de informa¸c˜oes de configura¸c˜ao para saber quem contatar. Com isso, os roteadores descobrem quem s˜ao seus vizinhos [21]. Na maioria dos equipa- mentos de diferentes fornecedores, o tempo padr˜ao entre o envio de cada pacote Hello ´e de 10 segundos.

Cada roteador gera uma estrutura de dados conhecida como an´uncio de estado de enlace (LSA - Link State Advertisement ) que descreve o estado local de uma rede ou do roteador. Para um roteador, o “estado” ´e composto pelo estado das interfaces do roteador e suas adjacˆencias. Essa estrutura de dados deve ser inundada pela rede para que todos os roteadores passem a conhecer a topologia da rede. Existem diversos tipos de LSAs, dentre os quais os mais usados est˜ao descritos a seguir. Cada tipo de LSA deve ser transportado em uma determinada ´area. A divis˜ao da rede em ´areas ser´a discutida mais `a frente, ainda neste cap´ıtulo.

• LSA tipo 1 (Router LSA): gerado por cada roteador para cada ´area `a qual ele pertence e descreve o estado e os custos dos enlaces do roteador para a ´area;

• LSA tipo 2 (Network LSA): gerado por um DR (Designated Router ), que ´e res- pons´avel pelo envio de LSAs em redes de acesso m´ultiplo, para descrever vizinhos conectados a um determinado segmento;

• LSA tipo 3 (Summary LSA 3 ): gerado pelo ABR (Area Border Router ) para des- crever a rota para vizinhos fora da ´area;

• LSA tipo 4 (Summary LSA 4 ): gerado pelo ABR para descrever a rota para um ASBR (Autonomous System Border Router ) para vizinhos fora da ´area;

• LSA tipo 5 (AS external LSA): gerado pelo ASBR para divulgar dentro da ´area as rotas externas para o AS;

• LSA tipo 7 (NSSA LSA): gerado pelo ASBR dentro de uma ´area NSSA (Not-So- Stubby Area) para divulgar dentro da NSSA as rotas externas para o AS.

Cada roteador emite por inunda¸c˜ao mensagens Link State Update (LSU) para cada um de seus dispositivos adjacentes. Nessa mensagem est˜ao contidas informa¸c˜oes como estado e custo dos enlaces presentes no banco de dados da topologia. Em outras palavras, cada LSU carrega um conjunto de LSAs, podendo esse conjunto ser formado pelos LSAs de diversos roteadores. As mensagens LSU possuem um servi¸co confi´avel, ou seja, s˜ao confirmadas atrav´es de mensagens Link State Acknowledgement (LSAck). As mensagens tamb´em possuem n´umero de sequˆencia, onde o roteador pode ver se uma mensagem LSU recebida ´e antiga ou recente. Mensagens LSU tamb´em s˜ao enviadas quando um enlace ´e ativado ou desativado, ou quando os custos se alteram [21].

As mensagens Database Description (DBD) fornecem os n´umeros de sequˆencias de todas as entradas de estado de enlace mantidas no momento pelo transmissor. Assim, o receptor pode comparar seus valores armazenados com os valores do transmissor, para verificar quem possui o registro mais recente. Em geral, essas mensagens s˜ao enviadas quando ocorre a interrup¸c˜ao de um enlace.

Cada roteador pode solicitar informa¸c˜oes de estado de enlace para os roteadores vizinhos usando mensagens Link State Request (LSR) quando detectam que seu banco de dados n˜ao est´a atualizado. Isso ocorre quando o roteador compara o DBD recebido com o seu pr´oprio banco de dados. O roteador que recebe um LSR, responde com um LSU. Todas as mensagens OSPF s˜ao enviadas em pacotes IP [21].

Uma caracter´ıstica importante do protocolo OSPF ´e a possibilidade de dividir o dom´ınio OSPF em ´areas menores, formando uma hierarquia entre as ´areas. O dom´ınio OSPF ´e um conjunto de roteadores sob mesma administra¸c˜ao. O roteamento entre as ´

areas ´e poss´ıvel atrav´es da utiliza¸c˜ao dos roteadores de borda (ABRs). A forma¸c˜ao de uma hierarquia entre as ´areas permite que o OSPF seja usado em redes de grande escala. Isso ´e poss´ıvel porque o roteador de uma ´area s´o deve manter a base de dados da topologia da ´area a qual ele pertence. Assim, o roteador de uma ´area n˜ao tem conhecimento da topologia fora dessa ´area e compartilha seu banco de dados apenas com roteadores dentro da sua ´area e n˜ao com todo o dom´ınio OSPF. Com isso, reduz-se o n´umero de LSAs e o tr´afego de controle, al´em do tamanho da base de dados topol´ogica que cada roteador deve manter [7]. Como consequˆencia, os roteadores n˜ao precisam armazenar uma tabela de roteamento muito grande com rotas para todas as sub-redes. Isso tem impacto direto na utiliza¸c˜ao da mem´oria do roteador. Al´em disso, uma menor base de dados implica em menos LSAs para processar e, portanto, resulta em menor carga de processamento no roteador. Ademais, como a base de dados deve ser mantida apenas dentro da ´area, o algoritmo de inunda¸c˜ao (flooding) ´e limitado a essa ´area, reduzindo a sobrecarga de controle na rede. Por tudo isso, percebe-se que h´a muitos benef´ıcios associados `a utiliza¸c˜ao da divis˜ao por ´areas do protocolo OSPF.

A divis˜ao em ´areas ´e poss´ıvel desde que sejam respeitadas as seguintes regras: • Deve existir uma rede backbone, que combina ´areas independentes em um ´unico

dom´ınio. A ´area backbone tamb´em ´e chamada de ´Area 0.

• Cada ´area que n˜ao seja a ´area backbone deve ser diretamente conectada na ´area backbone;

• A ´area backbone n˜ao pode ser particionada caso aconte¸ca alguma falha, como queda de um enlace ou de um roteador.

A Figura 3.4 ilustra um dom´ınio OSPF dividido em ´areas. A ´area backbone ´e obrigat´oria e interconecta todas as outras ´areas atrav´es de roteadores ABR. O roteador ABR ´e respons´avel por divulgar as rotas aprendidas para dentro de outra ´area e, portanto, deve sempre possuir pelo menos uma interface na ´area backbone e uma interface em outra ´

area. A ´area normal n˜ao possui nenhuma restri¸c˜ao de distribui¸c˜ao de LSAs. Os roteadores ASBR (Autonomous System Boundary Router ) presentes nas ´areas normais realizam a

redistribui¸c˜ao de rotas de outros ASes para dentro do dom´ınio OSPF. No exemplo da Figura 3.4 o ASBR realiza a redistribui¸c˜ao de rotas do AS 65551 para o AS 65536, e vice versa.

Um ASBR na ´area NSSA propaga suas rotas para um ABR tamb´em na ´area NSSA, convertendo um LSA do tipo 5 para um LSA do tipo 7, propagando assim suas rotas para o restante do dom´ınio OSPF. A ´area stub n˜ao propaga rotas externas (LSAs do tipo 5). Para os roteadores da ´area stub alcan¸carem redes externas, o ABR precisa injetar uma rota padr˜ao na ´area stub. Os ABRs tamb´em n˜ao propagam LSAs do tipo 4 neste tipo de ´

area, j´a que tamb´em s˜ao de rotas externas. Portanto, em uma ´area stub, as rotas externas s˜ao substitu´ıdas por uma ´unica rota padr˜ao. Por fim, a ´area totalmente stub tamb´em n˜ao recebe LSAs do tipo 4 ou 5 dos ABRs, por serem an´uncios de rotas externas. Al´em disso, n˜ao recebem LSAs do tipo 3, que anunciam rotas para vizinhos fora da ´area. Todo o roteamento nessas ´areas ´e feito com base em uma ´unica rota padr˜ao anunciada pelo ABR da ´area.

Figura 3.4: Dom´ınio OSPF dividido em diferentes tipos de ´areas OSPF. Todas as ´areas devem se conectar `a ´area backbone.

Cap´ıtulo 4

Desempenho em Redes de

Comunica¸c˜ao Resilientes

A resiliˆencia pode ser entendida como a capacidade da rede de manter n´ıveis aceit´aveis de opera¸c˜ao frente a anomalias, como sobrecarga operacional e falhas em equipamentos. A resiliˆencia de uma rede depende de sua topologia f´ısica e da habilidade de seus pro- tocolos reagirem a falhas [3]. As redes backbone devem estar dispon´ıveis e operacionais o m´aximo de tempo poss´ıvel, proporcionando o melhor desempenho. Assim, ´e essen- cial que essas redes estejam preparadas para resistir aos problemas que levam `a falta de conectividade, implementando medidas t´ecnicas para mitig´a-los, fortalecendo suas capa- cidades de defesa, detec¸c˜ao, remedia¸c˜ao e recupera¸c˜ao [11]. Sistemas preparados para prever antecipadamente os acontecimentos que levem `a falta de conectividade podem rea- gir rapidamente, reduzindo o tempo de interrup¸c˜ao dos servi¸cos prestados. Al´em disso, o crescimento exponencial de servi¸cos de miss˜ao cr´ıtica e outras necessidades de comunica- ¸c˜ao ininterrupta aumenta a necessidade de criar e manter redes cada vez mais robustas e tolerantes a falhas [19]. Por isso, estudos voltados para o aumento da resiliˆencia em redes de comunica¸c˜ao ´e um tema de suma importˆancia.

Este cap´ıtulo apresenta um conjunto de m´etricas utilizadas para a an´alise de de- sempenho em redes de comunica¸c˜ao resilientes e destaca aquelas usadas neste trabalho.

4.1

M´etricas de desempenho

A qualidade de um servi¸co (QoS - Quality of Service) ´e medida atrav´es de m´etricas de desempenho, tais como atraso, jitter, taxa de erro de bits (BER - Bit Error Rate), taxa de perda de pacotes e largura de banda dispon´ıvel. De acordo com os valores encontrados para essas m´etricas, um servi¸co pode ser classificado em uma determinada classe. A Figura 4.1 mostra a rela¸c˜ao entre QoS e a disponibilidade de um servi¸co. Se um servi¸co cumprir todos os parˆametros QoS definidos, ele ´e considerado com QoS compat´ıvel. Se algum parˆametro de QoS for violado, o servi¸co ser´a considerado degradado. Um segundo conjunto de parˆametros de QoS pode ser definido para determinar a disponibilidade do servi¸co. Esses parˆametros s˜ao indicados como QoSR. A escolha do QoSR depende das

aplica¸c˜oes [22]. O ajuste dos parˆametros de QoSR deve estar fortemente relacionado `a

diferencia¸c˜ao das classes de servi¸co. Se os parˆametros QoSR forem violados, o servi¸co

ser´a considerado indispon´ıvel. Caso contr´ario, o servi¸co est´a dispon´ıvel, podendo estar degradado, ou n˜ao.

Figura 4.1: Rela¸c˜ao entre QoS, QoSR e disponibilidade de servi¸co. Um servi¸co degradado

pode estar dispon´ıvel desde que os parˆametros de QoSR n˜ao sejam violados. (Adaptado

pelos autores [22])

A indisponibilidade de um servi¸co ´e geralmente causada por falhas inesperadas. A indisponibilidade de um servi¸co refere-se principalmente ao tr´afego de pacotes. Isto ´e, um servi¸co ´e considerado indispon´ıvel n˜ao somente pela perda de sinal, mas tamb´em pelo desempenho da rede em rela¸c˜ao `a perda de pacotes e aos atrasos [22]. Para especificar a disponibilidade de um servi¸co podem ser mensurados alguns fatores de qualidade, cha- mados parˆametros de QoR (Quality of Resilience) [22]. O objetivo da QoR ´e caracterizar a probabilidade de um servi¸co estar dispon´ıvel. De acordo com a defini¸c˜ao de QoR, um servi¸co deve atender aos requisitos de QoSR predefinidos. Os parˆametros de QoS, QoR e

QoSR est˜ao listados na Figura 4.2.

Figura 4.2: Parˆametros de QoS e QoR para defini¸c˜ao de classes de servi¸co. (Adaptado pelos autores [22])

O MTTR (Mean Time to Repair ) ´e o per´ıodo m´edio de tempo entre dois eventos. O primeiro ´e o in´ıcio da perda do servi¸co e o segundo ´e o in´ıcio do recebimento de um servi¸co adequado. O primeiro evento pode ocorrer devido a uma falha, enquanto o segundo pode ocorrer ap´os um mecanismo de prote¸c˜ao ou restaura¸c˜ao ser bem sucedido. Neste trabalho, o MTTR pode ser definido como o tempo de convergˆencia do protocolo de roteamento ap´os uma falha. Isso ´e poss´ıvel porque ap´os a convergˆencia as rotas est˜ao reestabelecidas e o servi¸co passa a ser oferecido novamente com perda de pacotes e atraso aceit´aveis. O MTBF (Mean Time Between Failures) ´e o per´ıodo m´edio de tempo decorrido a partir de uma falha at´e que ocorra a pr´oxima falha. Neste trabalho, o MTBF ´e considerado nulo, pois considera-se que as falhas ocorrem simultaneamente. O MTBF refere-se a toda interrup¸c˜ao de servi¸co causada por falhas f´ısicas ou pela diminui¸c˜ao da qualidade detectada. Como ´e not´orio, para conex˜oes muito importantes, o servi¸co ininterrupto ´e necess´ario, independentemente de ocorrer mais de uma falha na rede. Por isso, cada vez mais m´etodos baseados em reconfigura¸c˜ao cont´ınua s˜ao estudados e implantados nas redes [22].

A ideia apresentada neste trabalho est´a relacionada ao estudo da qualidade do tr´afego de dados existentes nos enlaces de uma rede backbone. Mais especificamente, o foco ´e investigar o desempenho da rede em opera¸c˜ao normal e ap´os a ocorrˆencia de m´ultiplas falhas em n´os estrat´egicos. Para tanto, os parˆametros de QoS avaliados s˜ao a perda de pacotes e o atraso m´edio. A perda de pacotes tamb´em ´e parˆametro de QoSR.

Cap´ıtulo 5

Emula¸c˜ao de uma rede de backbone

As redes backbone s˜ao redes de alto desempenho e elevada capacidade que servem para transportar dados entre redes que se encontram em diferentes localidades, dentro ou fora de um pa´ıs. O primeiro backbone nacional nasceu no ambiente acadˆemico. Esse projeto inicial deu origem `a Rede Ipˆe, que pertence `a Rede Nacional de Ensino e Pesquisa (RNP). Neste cap´ıtulo, apresenta-se a Rede Ipˆe e suas caracter´ısticas principais. A topologia dessa rede ´e utilizada em uma emula¸c˜ao que tem como objetivo analisar o desempenho de uma rede backbone quando falhas ocorrem. A metodologia utilizada para an´alise do desempenho tamb´em ´e apresentada neste cap´ıtulo.

5.1

A Rede Ipˆe

A Rede Ipˆe ´e um backbone da Internet, operada pela RNP e dedicada `a comunidade brasileira de ensino superior e pesquisa. Essa rede interconecta universidades e seus hospitais, institutos de pesquisa e institui¸c˜oes culturais. A Rede Ipˆe foi inaugurada em 2005, como evolu¸c˜ao de uma rede inicialmente implantada em 1992, e foi a primeira rede ´

optica nacional acadˆemica a entrar em opera¸c˜ao na Am´erica Latina. O projeto da Rede Ipˆe foi feito de forma a atender a demanda por capacidade de transmiss˜ao para trafegar dados de aplica¸c˜oes b´asicas da Internet, como navega¸c˜ao Web, correio eletrˆonico e transferˆencia de arquivos, e para trafegar dados de servi¸cos avan¸cados, como aplica¸c˜oes avan¸cadas e projetos cient´ıficos. Al´em disso, o projeto da Rede Ipˆe leva em considera¸c˜ao a capacidade de fornecer suporte `a experimenta¸c˜ao de novas tecnologias, servi¸cos e aplica¸c˜oes 1_.

A infraestrutura da Rede Ipˆe engloba 27 Pontos de Presen¸ca (PoPs), um em cada unidade da federa¸c˜ao, totalizando 42 enlaces, al´em de ramifica¸c˜oes para atender 1522 campi e unidades de institui¸c˜oes de ensino, pesquisa e sa´ude em todo o pa´ıs, atendendo a mais de 3,5 milh˜oes de usu´arios. A Figura 5.1, mostra a infraestrutura da Rede Ipˆe em 20182_{. A RNP disponibiliza diversas ferramentas online para obter informa¸c˜oes sobre}

a Rede Ipˆe. Por exemplo, o Via Ipˆe3 permite acompanhar o tr´afego e analisar diversas estat´ısticas dos enlaces entre os PoPs e as institui¸c˜oes de ensino, como mostra a Figura 5.2. J´a o Panorama4 permite acompanhar o tr´afego da rede backbone em tempo real, sendo atualizado a cada 3 minutos. Um exemplo do Panorama est´a mostrado na Figura 5.3.

2_{Dispon´ıvel em https://www.rnp.br/sobre/nossa-historia/evolucao-da-rede-ipe} 3_{Dispon´ıvel em https://viaipe.rnp.br/#@-22.898513415051685,-43.11756134033203,14z} 4

Figura 5.1: Infraestrutura da Rede Ipˆe em 2018. Os 27 PoPs servem mais de 1500 institui- ¸c˜oes de ensino e pesquisa no Brasil. Existe ainda conex˜ao com backbones internacionais.

Figura 5.2: Qualidade do enlace entre o PoP-RJ e a UFF. No per´ıodo analisado, o enlace apresentou uma m´edia de perda de pacotes menor do que 1% e maior do que 0,01%, sendo sua qualidade classificada como boa. A latˆencia m´edia no per´ıodo foi de 1,95 ms.

Figura 5.3: Panorama de tr´afego na Rede Ipˆe no dia 18/03/2019 `as 13:45:12. Cada enlace mostra o tr´afego em tempo real e as cores representam a carga sobre o enlace. Quando a carga est´a elevada, o enlace deixa de ser representado na cor verde.

Percebe-se, atrav´es da observa¸c˜ao do tr´afego capturado no dia 18/03/2019 mos- trado na Figura 5.3, que a rede backbone da RNP est´a funcionando sem falhas, com apenas alguns enlaces com carga de tr´afego acima de 60%. Al´em disso, tamb´em ´e poss´ıvel verifi- car quais as redes interconectadas por esse backbone. Contudo, n˜ao ´e poss´ıvel afirmar que