DANILO LINS FONTES
FERNANDO HENRIQUE ESPIUCA DO NASCIMENTO JAILSON GOMES DA SILVA
RODRIGO MARQUES RAMOS
ENGENHARIA DE TRÁFEGO EM REDES
MPLS:
OTIMIZAÇÃO E GERENCIAMENTO
JAILSON GOMES DA SILVA RODRIGO MARQUES RAMOS
ENGENHARIA DE TRÁFEGO EM REDES
MPLS:
OTIMIZAÇÃO E GERENCIAMENTO
Trabalho de conclusão de curso apresentado ao Curso de Tecnologia de Redes de Computadores, para obtenção do título acadêmico de graduação em Redes de Computadores, da UNIBRATEC, sob a orientação dos Professores Dailson de Oliveira Fernandes e Marcos Antônio Alves Gondim.
Orientadores: Prof. Dailson de Oliveira Fernandes e Prof. Marcos Antônio Alves Gondim.
JAILSON GOMES DA SILVA RODRIGO MARQUES RAMOS
ENGENHARIA DE TRÁFEGO EM REDES
MPLS:
OTIMIZAÇÃO E GERENCIAMENTO.
Trabalho de conclusão de curso apresentado ao Curso de Tecnologia de Redes de Computadores, para obtenção do título acadêmico de graduação em Redes de Computadores, da UNIBRATEC, sob a orientação dos Professores Dailson de Oliveira Fernandes e Marcos Antônio Alves Gondim.
Aprovado em: ______/_______/_________
BANCA EXAMINADORA
__________________________________ Prof. Nome do Orientador
Orientador
___________________________________ Nome do 2º Membro
Função ou Instituição
___________________________________ Nome do 3º Membro
"A vitória está reservada para aqueles que estão dispostos a pagar o preço."
ENGENHARIA DE TRÁFEGO EM REDES MPLS: OTIMIZAÇÃO E GERENCIAMENTO. Trabalho de Conclusão de Curso (Graduação em Tecnologia em Redes de Computadores) - Faculdade de Tecnologia Ibratec. Recife-PE, 2015.
RESUMO
Em meados da década de noventa, com o surgimento das novas tecnologias de rede e a crescente demanda por recursos dos serviços de web o uso do MPLS (Multiprotocol Label Switching) tem sido bastante difundido, uma vez que ele permite esquemas dinâmicos de roteamento e a otimização no tráfego dos pacotes acrescido à implementação da ET (Engenharia de Tráfego). Ainda é possível adicionar qualidade de serviço no tráfego para garantir certas aplicações, criando túneis com base na análise de tráfego, encaminhando pela enorme malha de links disponíveis. Entendam que simplesmente aumentar a capacidade dos enlaces não é mais suficiente e a máxima do caminho mais curto ser o melhor para o tráfego não condiz com a realidade. Este trabalho tem como objeto de pesquisa apresentar as vantagens obtidas com a implementação dos serviços de Engenharia de Tráfego fim a fim em redes MPLS. Através de simulações no GNS3 usando os protocolos OSPF e RSVP será visto o ganho de performace em redes IP e BackBones quando comparado a não utilização da tecnologia da Engenharia de Tráfego.
ENGENHARIA DE TRÁFEGO EM REDES MPLS: OTIMIZAÇÃO E GERENCIAMENTO. Trabalho de Conclusão de Curso (Graduação em Tecnologia em Redes de Computadores) - Faculdade de Tecnologia Ibratec. Recife-PE, 2015.
ABSTRACT
In the mid-nineties, with the emergence of new network technologies and the growing demand for resources of web services using MPLS (Multiprotocol Label Switching) has been widespread, since it enables dynamic schemes routing and optimization in packet traffic acrecido the implementation of TE (Traffic Engineering). It's still possible add service quality traffic to ensure certain applications, creating tunnels based on traffic analysis forwarding the huge mesh available links. Understand that simply increasing the capacity of the links is no longer sufficient and the maximum shortest path is best for the traffic does not match reality. This work is research object has the advantages obtained with the implementation of traffic engineering services end to end MPLS networks. Through simulations using GNS3 OSPF and RSVP protocols will be seen gain performance on IP BackBones and networks compared to non-use of traffic engineering technology.
Figura 1: Formato do pacote no cabeçalho MPLS ... 17
Figura 2: Imagem ilustrativa do funcionamento do MPLS ... 20
Figura 3: Topologia de rede simples, demonstrando o algoritmo SPF ... 24
Figura 4: Topologia de rede simples demostrando o algoritmo CSPF... 24
Figura 5: Critério de Desempate do CSPF. ... 26
Figura 6: Modelo básico de aplicação QoS. ... 27
Figura 7: Classe de serviços QoS - IntServ X Diffserv. ... 30
Figura 8: Blocos funcionais dos pacotes ... 31
Figura 9: Datagrama do DSCP e CU. ... 31
Figura 10: Processo de Sinalização – Protocolo RSVP... 32
Figura 11: RSPV e as mensagens, PATH e RESV durante a configuração do lSP .. 33
Figura 12: Mensagens RSVP-TE ... 35
Figura 13: Ilustração da rota do pacote usando RSVP-TE. ... 36
Figura 14: RSVP-TE usado entre áreas OSPF. ... 37
Figura 15: Problema do Peixe roteamento explicito. ... 40
Figura 16:Projeto do Peixe usando o roteamento em MPLS. ... 40
Figura 17: Proteção de Caminhos ... 43
Figura 18: Elementos da Proteção Local ... 44
Figura 19: Detalhamento da Proteção do Enlace. ... 45
Figura 20: Proteção de Nó ... 46
Figura 21: Topologia de Engenharia de Tráfego. ... 47
Figura 22: Configuração do protocolo MPLS. ... 49
Figura 23: Resultado do comando “show mpls interfaces”. ... 50
Figura 24: Resultado do comando “show mpls ldp neighbor”. ... 51
Figura 27: Comando “show mpls traffic-eng tunnels brief”... 55
Figura 28: Configuração dos Túneis MPLS-TE no Roteador Backbone PE1... 56
Figura 29: Verificando os caminhos percorridos no MPLS-TE. ... 56
Figura 30: Topologia MPLS-TE ... 57
Figura 31: Ilustração do túnel 0. ... 58
Figura 32: Rastreando a rota do túnel 0 ... 58
Figura 33: Ilustração do túnel 1. ... 59
Figura 34: Rastreando a rota do túnel 1 ... 59
Figura 35: Ilustração do túnel 2 ... 60
Figura 36: Rastreando a rota do túnel 2 ... 60
Figura 37: Desativar roteador para demonstrar falha no ambiente. ... 61
Figura 38: Falha de simulação no Roteador P1. ... 61
Figura 39: Visualização da rota alternativa ... 62
Figura 40: Linha de comando manipulada ... 63
Figura 41: Ping realizado no Prompt de comando. ... 63
Tabela 1: Combinações do Mapa de Classes... 23
Tabela 2: Os cinco caminhos possíveis de RtA até RtN ... 25
Tabela 3: Tabela QoS: Natureza da aplicação x Requisitos... 29
Tabela 4: Endereçamento IP das Interfaces Seriais dos roteadores. ... 47
AS Autonomous System
ATM Asynchronous Transfer Mode
CE Customer Edges
CEF Cisco Express Cisco Express Forwarding CSPF Constrained Shortest Path First
EIGRP Enhanced Interior Gateway Routing Protocol FEC Forwading Equivalent class
FRR Fast Reroute
IETF Internet Engineering Task Force
IGP Internet Gateway Protocol
IGRP Internet Gateway Routing Protocol IP Internet Protocol
IS-IS Internacional System to Intermediate System ISP Internet Service Provider
LBS Label Based Switching LDP Label Distrbution protocol
LFIB Label Forwarding information base LIB
LSA
Label Information base Link State Advertisement LSP Label Switched Path LSR Label Switch Router MP Merge Point
MPLS Multi Protocol Label Switching
MPLS-TE MultI Protocol Label Switching Traffic Engineering NHOP Next-Hop-Router
NNHOP Next-Next-Hop-Router OSPF Open Shortest Path First PE Provider Edges
PHB Per Hop Behavior PLR Point of Local Repair
PS Providers
QoS RFC
Quality of Service Request for Comments RIP Routing Information Protocol RSVP Resource Reservation Protocol RSVP-TE
SPF
Resource Reservation Protocol Traffic Engineering Shortest Path First
TE Traffic Engineering TOS Type of Service TTL Time to Live
1. INTRODUÇÃO ... 14
1.2 JUSTIFICATIVA ... 15
1.3 OBJETIVOS ... 15
1.3.1 OBJETIVO GERAL ...15
1.3.2 OBJETIVOS ESPECÍFICOS ...15
2. DESENVOLVIMENTO ... 15
2.1 MPLS ... 15
2.1.1 LABEL ... 17
2.1.2 COMPONENTES DO MPLS ... 17
2.1.3 CONTROL PLANE DO MPLS ... 18
2.1.4 DATA PLANE DO MPLS ... 19
2.1.5 FUNCIONAMENTO DO MPLS... 19
2.1.6 VANTAGENS DO MPLS ... 20
2.1.7 DESVANTAGENS DO MPLS ... 20
2.2 PROTOCOLO OSPF ... 21
2.2.1 FUNCIONAMENTO DO CSPF ... 23
2.2.2 CRITÉRIOS DE DESEMPATE RELACIONADO AO CSPF ... 25
2.3 QOS (QUALIDADE DE SERVIÇO) ... 26
2.3.1 SERVIÇOS INTEGRADOS (INTSERV) ... 29
2.3.2 SERVIÇOS DIFERENCIADOS (DIFFSERV) ... 29
2.3.3 APLICAÇÕES EM TEMPO REAL ... 29
2.3.4 APLICAÇÕES ELÁSTICAS ... 30
2.3.5 CLASSIFICAÇÃO E MARCAÇÃO ... 30
2.4 RSVP (PROTOCOLO DE RESERVA DE RECURSOS) ... 31
2.5 RSVP-TE (ENGENHARIA DE TRÁFEGO) ... 34
2.6 ENGENHARIA DE TRÁFEGO ... 37
2.7 ENGENHARIA DE TRÁFEGO EM MPLS ... 38
2.8 PROTEÇÃO E RESTAURAÇÃO (FRR-FAST REROUTE) ... 41
2.8.1 PROTEÇÃO DE CAMINHOS ... 42
2.8.2 PROTEÇÃO LOCAL ... 43
2.8.3 PROTEÇÃO DE ENLACE (LINK PROTECTION)... 44
2.8.4 PROTEÇÃO DE NÓ (NODE PROTECTION) ... 45
3. TOPOLOGIA DO CENÁRIO ... 46
3.1 ENDEREÇAMENTO IP ... 47
3.1.1 HARDWARES ... 48
3.1.2 SISTEMAS OPERACIONAIS ... 49
3.2 CENÁRIO PROPOSTO ... 49
3.5 CONFIGURAÇÕES MPLS-TE ... 53
3.5.1 VALIDAÇÃO DE FUNCIONAMENTO ... 55
3.6 CONFIGURAÇÕES DOS TÚNEIS ... 58
3.7 SIMULAÇÃO DE FALHAS ... 61
3.8 BALANCEAMENTO DO TRÁFEGO ... 63
4. CONCLUSÃO E CONSIDERAÇÕES FINAIS ... 65
5. TRABALHOS FUTUROS ... 66
6. REFERÊNCIAS ... 66
APÊNDICE A – CONFIGURAÇÕES BÁSICAS DO MPLS NO ROTEADORES DO BACKBONE ... 69
1. INTRODUÇÃO
Com a crescente demanda dos serviços de rede e novas tecnologias sendo desenvolvidas a cada instante surge à necessidade de mitigar a sobrecarga aplicada aos roteadores e a saturação do processamento dos algoritimos já ineficientes pois, à medida que aumentamos a distância ou quantidades de saltos se torna mais difícil o encaminhamento dos pacotes nas redes IP (Mendonça, 2009).
Tomando como base este cenário observa-se que as redes baseadas no roteamento IP padrão não são escalonáveis. Não sendo possível aumentar o tamanho da rede indefinitivamente e por mais rápido que sejam, os roteadores individualmente, a repetição dos processos de roteamento tornariam o atraso da rede proibitivo (DEA 2002). A tecnologia MPLS foi desenvolvida inicialmente como provável solução para melhor otimização do tráfego de dados dos BackBones e por permitir máxima flexibilidade, capaz de agregar vários serviços como QoS.
Tem sido largamente utilizada pelas operadoras de telefonia e provedores de internet por estarem classificadas como redes de trânsito, transportando os pacotes entre os pontos de entrada e saída, ainda que, o seu objetivo não seja ligar sistemas finais. A tecnologia apresenta seu roteamento com base no rotulamento dos pacotes, onde monta um índice da tabela de encaminhanhento diferente do convencional quando utilizado a Engenharia de Tráfego, é um serviço que faz a organização dos tráfegos (Osborne 2002). Devido ao aumento dos equipamentos que estão crescendo em custo alto, uma das vantagens de usar a Engenharia de Tráfego em redes MPLS é ter uma topologia de rede menos robusta; redução de custo operacional; ter habilidade para colocar novos serviços na rede e fazer a manutenção mais simples e mais rápida. E a sua maior resposanbilidade é tornar os níveis mais acessível no QoS, para a melhoria da sua banda larga. Existem alguns algoritmos na ET que fazem uma distribuição do tráfego para não ter o congestionamento da rede e fazer a medição da distância entre os pontos fim a fim. O Djkstra será o algoritmo mais abordado em redes MPLS, combinado com os protocolos OSPF e RSVP.
1.2 JUSTIFICATIVA
A análise do tráfego nos BackBones das operadoras, é um assunto que merece atenção, a forma como são tratados os dados que transitam dentro dos provedores de serviço, pois, existem aplicações que demandam uma maior prioridade de tráfego e os roteadores de borda das operadoras precisam de mecanismos eficientes para o tratamento dessas informações.
Será apresentado através da Engenharia de Tráfego, o ganho de desempenho obtido através do MPLS e utilização dos protocolos OSPF, RSVP, RSVP-ET e da Qualidade dos Serviços.
1.3 OBJETIVOS
Nesta seção serão abordados alguns tópicos relacionados ao Objetivo geral e aos Objetivos específicos deste trabalho.
1.3.1 OBJETIVO GERAL
Apresentar o desenvolvimento de um estudo, implementando a Engenharia de Tráfego em uma infraestrutura de provedor de serviços, comprovando sua eficiência e mostrando os seus benefícios em comparação com a não utilização do protocolo.
1.3.2 OBJETIVOS ESPECÍFICOS Descrever o funcionamento do MPLS.
Abordar os protocolos: OSPF, RSVP e (RSVP-TE). Abordar (Qualidade de Serviços).
Apresentar conceitos e funcionamento da Engenharia de Tráfego.
Criar um ambiente, simulando testes e comprovando o ganho de desempenho através da Engenharia de Tráfego.
2. DESENVOLVIMENTO
Inicialmente quando a tecnologia ATM foi desenvolvida tinha uma expectativa muito grande que dominasse o mercado devido a suas altas taxas de transmissão, mas a tecnologia ATM não era compatível com as redes IP que até então era o protocolo mais utilizado nas redes de computadores, então foi criada a tecnologia LBS
– Label Based Switching que possibilitou a utilização de várias aplicações, nas redes IP e ATM. (Santos, 2006) em 1996, nos artigos sobre redes muito se falava sobre um novo conceito no mundo IP – a comutação IP.
Analisando alguns artigos aparentava que o roteamento IP tinha perdido seu lugar para a comutação de pacotes IP. Algumas empresas migraram para a tecnologia ATM como meio de comutação IP, a Cisco desenvolveu seu próprio conceito – a comutação de TAG, o IETF resolveu padronizar as tecnologias onde na combinação de várias tecnologias resultou o MPLS (Multiprotocol Label Switching).
O principal motivo para implementação do MPLS é a variedade de aplicações que o protocolo nos permite implementar, algumas dessas aplicações não podemos implementar em uma rede IP sem o auxílio de alguns mecanismos, como a Engenharia de Tráfego que iremos abordar neste trabalho.
O MPLS é uma tecnologia de comutação utilizada para transportar pacotes ponto-a-ponto de forma rápida e simples, o MPLS utiliza marcações especificas nos pacotes denominadas de rótulos (Labels), elas determinam a forma de como a rede MPLS trata cada um dos pacotes. A (RFC 3031) define o rótulo como “um identificador curto de tamanho físico e fisícamente contíguo usado para identificar uma FEC,
normalmente com significado local”, poderíamos dizer que um rótulo é um valor que é
inserido em um determinado pacote que informa por onde deve seguir na rede. (DEA, 2002)
podem aparecer como BS contem 1 bit e tem a função de identificar o empilhamento de Labels e por último temos o campo chamado TTL (time to live) que contem 8 bits, onde tem a função de determinar o tempo máximo de vida do pacote dentro da rede MPLS (Afonso, 2011). Esses campos estão detalhados na Figura 1.
Figura 1: Formato do pacote no cabeçalho MPLS.
Fonte: site www.teleco.com.br
2.1.1 LABEL
Segundo (Mendonça, 2012), os Labels (Rótulos), contém alguns valores específico que podem ser utilizados pelo protocolo MPLS. O tamanho do campo Label é de 20 bits no qual pode variar de 0 a 1.048.575. Alguns valores têm significados especiais, conforme será descrito a seguir:
Rótulo - 0 – O Rótulo deve ser retirado, após ser retirado o roteamento será feito por meio de endereço de rede;
Rótulo - 1 – O datagrama é analisado e posteriormente o encaminhamento é definido através do próximo rótulo do MPLS;
Rótulo – 2 - Tem a mesma função do valor 0 com aplicações ao protocolo IPv6; Rótulo – 3 - Utilizados pelos LSRs (Label Switch Routers) para distribuição de Labels (Rótulos) (LDP- Label Distribution Protocol);
Rótulos - 4 á 15 - Reservado para futuras aplicações;
Rótulos - 16 á 1.048.575 – Rótulos que são utilizados para roteamento.
O MPLS tem vários componentes importantes dentro de sua rede, que são utilizados nos provedores de serviço, onde cada um tem suas particularidades conforme será detalhado a seguir; o componente FEC (Forwading Equivalent class) serve para marcar os pacotes com características semelhantes, por exemplo: O mesmo destino de próximo salto, mesmas características de encaminhamento ou até com a mesma característica de tratamento, outro termo é o MPLS Header ou cabeçalho MPLS, onde se encontram os campos MPLS, LABEL, EXP (Experimental), S ou BS e o campo TTL, temos o LDP (Label distrbution protocol) é o protocolo que garante a capacidade de trocar informações sobre as etiquetas (tags) ele determina como o MPLS trabalha se tornando uma das partes fundamentais para o funcionamento do protocolo, temos também o LSR (Label switch Router) ou Provider Router é um roteador falando MPLS que consegue fazer encaminhamento baseado em rótulos, o Edge LSR ou Provider Edge Router tem a mesma função do LSR com uma função adicional de retirar ou inserir rótulos MPLSde um determinado pacote, o LSP (Label switchted Path) é o caminho pelo qual os roteadores LSRs fazem o encaminhamento dos pacotes pelo qual um FEC e transportado, a FIB (forwarding information base) tem informações do destino no qual deve ser entregue o label faz função similar a tabela de roteamento onde no MPLS tratamos de labels. A LIB (Label information base), guarda todas as informações detalhadas sobre as rotas de um
determinado destino e a LFIB (Label forwarding information base) utiliza informação das tabelas FIB e LIB para informar ao roteador o que ele deve fazer quando receber um label vindo de algum meio MPLS (Osborne, 2002).
2.1.3 CONTROL PLANE DO MPLS
2.1.4 DATA PLANE DO MPLS
Conforme (Mendonça, 2012), no Data Plane também conhecido como plano de encaminhamento, os pacotes são enviadosbaseados em camada 2 ou 3 e também é responsável pela troca de labels durante o encaminhamento, o Data Plane utiliza informações geradas e coletadas do Control Plane para encaminhar o tráfego baseado em labels. Vale salientar que o protocolo MPLS so funciona corretamente se o Control Plane e o Data Plane estiverem em seu funcionamento adequado.
2.1.5 FUNCIONAMENTO DO MPLS
Segundo (Osborne, 2002), nas redes MPLS os pacotes recebem os rótulos quando entram na rede e são direcionados, com base nas informações desses rótulos os roteadores verificam o encaminhamento evitando o intenso processo de dados de um roteamento convencional. Pode-se verificar também que em vez de um único rótulo pode haver uma pilha de rótulos.
A etapa inicial desse processo consiste na construção das tabelas de roteamento onde os protocolos irão determinar os melhores caminhos ate a rede de destino dentro do provedor. A próxima etapa acontece quando os pacotes são inseridos a rede onde os roteadores de borda (LSR) recebem e posteriormente inserem rótulo aos pacotes.
A terceira etapa de encaminhamento dos pacotes onde o LSR verifica o rótulo se esta de acordo com a tabela LFIB e o direciona. A última etapa é quando os roteadores de borda (LSR) removem os rótulos e os direcionam ao seu destino. Na Figura 2, é possivel observar o fluxo do tráfego entre 2 redes dentro de um Backbone MPLS, nota-se ainda a marcação através dos rótulos.
Fonte, site: www.gta.ufrj.br/grad/04_2/MPLS/funcionamento.htm
2.1.6 VANTAGENS DO MPLS
Possibilidade de criar túneis consequentemente tem um ganho em escalabilidade;
Facilitar a Engenharia de Tráfego nos provedores de serviço; Garantia de níveis de serviço;
Priorização de tráfego;
Utilização de serviços como QoS, VPN e Engenharia de Tráfego.
2.1.7 DESVANTAGENS DO MPLS
sim ter um bom conhecimento onde o protocolo vai operar isso inclui conhecimentos de ATM, Engenharia de Tráfego, QoS, BGP. (Mendonça, 2012).
2.2 PROTOCOLO OSPF
O Protocolo OSPF (Open Shortest Path First) teve sua trajetória inicial no ano de 1989 desenvolvido pelo grupo de trabalho dos IGPs (Internet Gateway Protocols) da IETF (Internet Engineering Task Force), uma espécie de força de engenharia da internet, grupo de pesquisadores e desenvolvedores que na sua maioria são voluntários (RFC 1131), que é uma categoria de protocolos de roteamento usado para troca de informações por meio de rotas definidas em um sistema autônomo abreviado pela sigla (AS).
Que por sua vez se clássifica como um grupo de roteadores que tem o objetivo de trocar informações de roteamento comum entre si, sob o controle de uma ou mais operadoras que detém uma política amplamente definida de roteamento na internet, conjunto de domínios (RFC 1930). Atualmente o OSPF é um dos protocolos de roteamento mais empregados no mercado devido a sua versatilidade, sendo suportado pela grande maioria dos roteadores, assim como servidores que faz uso de diversas plataformas de sistema como Linux, Unix. E além de tudo pode-se utiliza-lo tanto em redes pequenas como nas de grande porte.
Dentre as características e inumeras vantagens que o protocolo OSPF possui, destacam-se duas alternativas em que a primeira se trata de um protocolo aberto, pois significa que suas especificações são dedominio público. A segunda é que teve sua base de origem apartir do protocolo SPF (RFC 1247)
Vetor distância significa que as rotas são anunciadas como vetores de distância e direção, sendo que a distância e definida em contagem de saltos, e a direção é dada simplesmente pelo roteador do próximo salto ou pela interface de saída. Os protocolos de vetor distância usam o algoritmo de Bellman- Ford, este por fim escolhe o caminho mais curto para a comunição como o de Dijkstra, porem de forma mais lenta.
Alguns protocolos do vetor distância enviam periodicamente tabelas de roteamento completa a todos os vizinhos conectados, em grandes redes essas atualizações de roteamento podem ficar enormes causando tráfego significativo entre os links. Fonte: Academia Cisco
O Protocolo SPF segundo (Osbone, 2002) é um protoco de roteamento de estado de enlace onde cada roteador sabe a respeito de todos os outros roteadores em uma rede, e dos enlaces que conectam esses roteadores. Sobre o conceito de LSA é um tipo de uma unidade de formação característica do roteador ao qual o mesmo utiliza para inundar suas informações de conectividade, ou seja, obter informação das rotas e enlace dos outros roteadores.
Diante dessas informações obtidas de todas as rotas algoritmo de Dijkstraé lançado para determinar o caminho mais curto que um roteador calcula entre si na rede, pois como todos os roteadores executam o mesmo cálculo, cada roteador dispõe de uma imagem das suas configurações facilitando com que os pacotes de dados sejam lançados na comunicação de modo coerente.
Será mostrado um pouco de como funciona o cálculo de Dijkstra conforme a Figura 3.
Conforme a Tabela 1, o roteador “A” roda o SPF gerando a tabela de roteamento para os demais roteadores, pois assim que todos os outros roteadores estiverem inundados suas informações na rede para os demais roteadores e os enlaces entre eles, um banco de dados de enlace será formado em cada roteador.
Distância e Lista “TENT”) o cálculo de um roteador para os demais roteadores do seu ponto de vista.
No parágrafo anterior pode-se observar que a tabela de roteamento usada pelo roteador é formada por um trio; “Roteador, Distância e Lista “TENT”. De modo que a primeira parte do trio refere-se ao nome do roteador “ID” nomenclatura de identificação, já o segundo refere-se ao percurso que o pacote do roteador vai percorrer, e são classificados como saltos. É o terceiro ítem do trio está relacionado a distância do custo para se chegar ao nó em questão. Então até o destino final de comunicação nas rotas usa-se a duas listas a “PATH e TENT” descritas em letras maiúsculas como mostrado na Tabela 1.
Tabela 1: Combinações do Mapa de Classes.
ROTEADOR PARES DE VIZINHOS – CUSTOS
A (B,5) – (C,10)
B (A,5) – (C,3) – (D,8)
C (A,10) – (B,3) – (D,4)
D (D,8) – (C,4)
Fonte: Osborne, 2002.
2.2.1 FUNCIONAMENTO DO CSPF
Este protocolo faz uso de um túnel (ET) para alcançar o destino final, executado pela Engenharia de Tráfego MPLS, diferentemente do SPF que baseia-se no caminho mais curto para entrega de informações, o processo de escolha na determinação do melhor rota não é preparado como no SPF, tipo: é considerado apenas a extremidade do túnel para o objetivo final, então a operação e parada quando um nó ao qual o roteador esta tentando alcançar estive na lista “Path“ ao Ives de calcular o caminho mais curto para todos os nós para finalização do processo.
único até o final, não existe algum compartilhamento de carga, existe sim uma forma de desempate quando os mesmos caminhos possuem atributos iguais. Segundo (Osborne, 2002) são: Largura de banda mínima no caminho, medição de IGP mais baixa até um caminho e contagem de saltos mais baixo do caminho como exemplificado na Figura 4:
Figura 3: Topologia de rede simples, demonstrando o algoritmo SPF
Fonte: Osborne, 2002.
Figura 4: Topologia de rede simples demostrando o algoritmo CSPF
Fonte: Osborne, 2002.
Nesta topologia o toma-se como base que o roteador “A” está tentando
de 60 Mbps, e também que outro critério para a melhor rota do pacote pode ser obtida no percurso de entre os roteadores A->B->C->D-> com o custo total de 12Mbps
2.2.2 CRITÉRIOS DE DESEMPATE RELACIONADO AO CSPF
O método de desempate é usado quando se está tentando por um nó na lista de tentativas (TENT) em que o mesmo já se encontra na lista, lembrando que o objetivo do calculo não é calcular os caminhos até se chegar no destino é sim um único caminho (túnel). O autor (Osborne, 2002) sugere a seguinte ordem:
Usar o caminho com a maior largura de banda mínima disponível.
Se houver ainda empate usar o caminho com menor contagem de hops que faz referência ao número de roteadores no caminho.
Ainda sim se houver empate, escolher um caminho aleatoriamente.
E esses mesmo critérios para o desempate são aplicados à medida que um nó é colocado na lista de tentativas (TENT) no CSFP. Pois no SPF diferencia-se por que existem várias maneiras de se chegar a um determinado nó fazendo uso do compartilhamento de carga.
Na Figura 5, é possível observar a montagem de 5 túneis, com os possíveis caminhos de RtA até RtN, denominados de P1 a P5 conforme a Tabela 2:
Tabela 2: Os cinco caminhos possíveis de RtA até RtN.
Nome do Caminho
Roteadores no Caminho Custo do Minimo Caminho
Largura no Caminho em (MPLS)
P1 RtA-RtB-RC-RtN 21 100
P2 RtA-RtD-RtE-RtN 19 80
P3 RtA-RtF-RtG-RtH-RtN 19 90
P4 RtA-RtI-RtJ-RtN 19 90
P5 RtA-RtL-RtM-RtN 19 90
Fonte: Osborne, 2002.
Fonte: Osborne, 2002.
Na Figura 5, o autor (Osborne, 2002), afirma que o processo de decisão pelo qual o roteador (RTA) passa para escolher um desses caminhos por analise da tabela 2, onde P1 não é usado por que expõe o caminho com maior largura de banda entre os dois caminhos que equivale a 100 Mbps, P2 não é usado por que sua largura de banda mínima é 80 Mbps que é inferior as larguras de banda mínimas dos outros caminhos (P1, P3, P4 e P5). P3 também é descartado por que faz uso da contagem de saltos denominado de (HOPS) entre os roteadores equivalente a 5, enquanto os demais, detém 4 saltos. E finalmente (RTA) vai escolher P4 ou P5 quem estiver no topo da lista de tentativas (TENT), determinado na tabela 2 pelo menor custo do caminho igual a 19 e maior largura de banda igual a 90 Mbps.
2.3 QOS (QUALIDADE DE SERVIÇO)
vez mais largura de banda. De tal modo que a exigência hoje é que essas aplicações tenham um funcionamento correto, mesmo diante de situações de congestionamento. As aplicações multimídia estão em destaque, e apresentam classes de serviços diferentes que possuem necessidades de recursos e prioridades diferentes, conforme a recomendação da E.800(ITU-T), QoS é o grau de satisfação de um usuário, medido através do desempenho e entrega de um serviço. (Costa, 2006). Na Figura 6, é possível identificar o modelo básico de aplicações do QoS.
Figura 6: Modelo básico de aplicação QoS.
Fonte: Silva, 2000.
As redes IP não provem qualquer tipo de QoS, elas apenas oferecem um tipo de serviço baseado no melhor esforço (Best Effort). Este serviço consiste em oferecer o mesmo tratamento aos pacotes, onde todos os usuários da rede compartilham a mesma largura de banda para envio dos seus dados, por sua vez, este tráfego pode gerar um congestionamento e neste caso, os pacotes são descartados indiscriminadamente não havendo garantias quanto à entrega ou desepenho. (Mendonça, 2012).
O conceito de QoS; está relacionado as taxas de transmissão, taxas de erros e demais características que podem ser medidas, melhoradas e, até certo ponto, garantidas com antecedência. Ademais, os protocolos de sinalização possibilitam a troca de informações entre os roteadores no sentido de cooperarem e prover à garantia da qualidade de serviço. (Sega, 2000).
mínimos, e bem definidos tendo como referência os seguintes parâmetros: (Costa, 2006):
A vazão: como sendo a quantidade efetiva das informações transmitidas entre a fonte até seu destino.
Latência ou atraso: é o tempo medido desde a geração de uma mensagem pelo emissor até o seu recebimendo pelo receptor durante uma conexão. Latência faz referência aos equipamentos. O atraso é o tempo que os pacotes perdem percorrendo a rede, e será influenciado de acordo com a velocidade de transmissão e do processamento nos equipamentos utilizados na rede durante a comunicação.
Jitter: o Jitter é importante para as aplicações cujo resultado da operação está relacionado à garantia de que as informações são processadas em períodos de tempo bem definidos. E pode ser definido como a variação no tempo e na seqüência de entrega das informações conforme são realizadas. Levando-se em conta a variação de atraso da rede.
Perdas de pacote: em redes IP, essa perda tem influência principalmente em função do descarte de pacotes nos roteadores e switches, estouro de buffers, ou ocorrem também devido a erros durante o transporte dos pacotes em situações de congestionamento.
Ainda no cenário de QoS; as aplicações distribuídas podem ser classificadas como sendo de Tempo-Real ou Elásticas. Na Tabela 3 é possível observar a natureza das aplicações e requisições de QoS.
O IETF (Internet Engineering Task Force) define esses dois modelos para implementação numa rede IP: serviços integrados (IntServ) e serviços diferenciados (DiffServ). (Mendonça, 2012).
Tabela 3:Tabela QoS: Natureza da aplicação x Requisitos.
Correio eletrônico Alta Baixa Baixa Baixa
Transf. de Arquivos Alta Baixa Baixa Média
Acesso a Web Alta Média Baixa Média
Login remoto Alta Média Média Baixa
Áudio por demanda Baixa Baixa Alta Média
Video por demanda Baixa Baixa Alta Alta
Telefonia Baixa Alta Alta Baixa
Videoconferência Baixa Alta Alta Alta
Fonte: Revista Eletronica, FMB Vol. 2, 2006.
2.3.1 SERVIÇOS INTEGRADOS (INTSERV)
Esta arquitetura é responsável pelas requisições de QoS para os dispositivos intermediários e hosts geralmente realizada de forma explícita a fim de obter a largura de banda e latência durante a atuação de uma determinada apliação (Ribeiro, 2011).
2.3.2 SERVIÇOS DIFERENCIADOS (DIFFSERV)
Essa arquitetura foi introduzida como uma alternativa para a arquitetura de Serviços Integrados, como resultado de esforços para evitar os problemas de escalabilidade e complexibilidade. (Ribeiro, 2011).
Analisando a Figura 7, podemos identificar às principais diferênças em comparação com as classes de serviços de QoS.
2.3.3 APLICAÇÕES EM TEMPO REAL
esse acumulo é proporcional a quantidade de enlaces e dispositivos de comunicação intermediários (roteadores e switches). Certas aplicações não permitem adaptação e são consideradas inflexíveis, posto que os vários níveis de QoS podem influenciar a quantidade de hosts que compartilham os recursos ou são atendidos simultaneamente pela rede. (Sorrentino, 2001).
Figura 7: Classe de serviços QoS - IntServ X Diffserv.
Fonte: Teixeira, 2009 – QoS.
2.3.4 APLICAÇÕES ELÁSTICAS
São aplicações que não são em tempo real, por sua vez, elas não dependem tanto do rigor na entrega dos pacotes, suportando uma determinada variação no atraso de uma transmissão, porém são muito sensíveis aos erros e perdas dos pacotes, com um tempo ligeiramente maior para entrega fim-a-fim, podem-se retransmitir pacotes. (Sorrentino, 2001).
Atráves da classificação, os grupos de pacotes são identificados e fica definido quem recebe algum tratamento diferenciado, na Figura 8, está exemplificado essa marcação, que é feita de acordo com o tipo de interface e características dos equipamentos, podendo ser realizada nas camadas 2 (802.1p/q), e 3 (Precedence ou DSCP), conforme na Figura 9, ou ainda em rótulos MPLS. (Mendonça, 2012).
Figura 8:Blocos funcionais dos pacotes.
Fonte: Kurose, 2006.
Figura 9: Datagrama do DSCP e CU (Currently Unused) .
Fonte: RFC 2474
2.4 RSVP (PROTOCOLO DE RESERVA DE RECURSOS)
operação nos roteadores que, eventualmente, pode causar dificuldades nos BackBones das grandes redes. (Sega, 2000).
Sendo originalmente elaborado como uma técnica de sinalização utilizada pelas aplicações, para informar ou solicitar à rede suas necessidades e para garantir a qualidade do serviço (QoS). Atuando tanto na reserva dos recursos nos roteadores da rede como na distribuição de rótulos, na camada de transporte. (Microsoft, 2007). É um protocolo de controle comparável com o ICMP (Internet Control Message Protocol) ou IGMP (Internet Gateway Message Protocol).
O RSVP leva o pedido pela rede, visitando cada nó que a rede utiliza para transportar o fluxo. As reservas são iniciadas pelo receptor para tráfego de difusão seletiva e difusão ponto a ponto. (Sega, 2000).
Declarado então um protocolo usado para realizar a Engenharia de Tráfego (RSVP-TE) como explicado na RFC-3209 em uma intra-área MPLS ou entre áreas MPLS como mostrado na RFC-4105.
Figura 10: Processo de Sinalização – Protocolo RSVP.
Fonte: Site Roberto Mendonça, 2012
PATH – É utilizado para armazenamento das informações acerca do caminho em cada um dos nós e enlaces, mantendo a sinalização do fluxo. (Mendonça, 2012).
RESV – Logo que a mensagem path é recebida, o receptor manda uma mensagem de solicitação de reserva como resposta para o transmissor, pelo mesmo caminho que a mensagem path foi originada (sentido reverso). Então o receptor fica responsável pela requisição de QoS, na mensagem de solicitação de reserva está implícito a qualidade de serviço pretendida e fica estabelecido o estado de reserva em cada nó no caminho. Assim que a mensagem de solicitação de reserva é recebida com sucesso pelo transmissor, é iniciado o tráfego dos dados. Deste modo a reserva de recurso é feita no sentido receptor > transmissor. (Mendonça, 2012).
Figura 11: RSPV e as mensagens, PATH e RESV durante a configuração do lSP.
Fonte: (Engenharia de Tráfego com MPLS, 2002)
Conforme a Figura 11, temos:
mais largura de banda do que R2 pode fornecer), R2 envia uma mensagem de erro de volta para. R1.
Supondo que tudo está correto, passar para a etapa 2.
R2 envia uma mensagem PATH para R3. R3 passa pela mesma verificação da mensagem path realizada por R2.
R3 envia uma mensagem PATH para R4; as mesmas verificações acontecem.
R5 envia uma mensagem PATH para R6; as mesmas verificações acontecem.
R6 envia uma mensagem PATH para R7; as mesmas verificações acontecem.
R7 sendo no final do túnel, envia uma mensagem RESV para R6. Essa mensagem RESV indica o rótulo que R7 gostaria de ver no pacote para este túnel como R7 é ao final do túneo, ele envia um nulo implícito.
R6 envia uma mensagem RESV para R5 e indica que deseja ver rótulo de chegada 42 para este túnel.
Isso significa que, quando R6 recebe o rótulo 42, ele remove esse rótulo (por causa do nulo implicito) e envia o pacote em direção a R7.
R5 envia uma mensagem RESV a R3, sinalizando o rótulo 10921. Quando R5 recebe um pacote com o rótulo10921, ele troca esse rótulo para o rótulo 42 e envia um pacote para R6.
R3 envia uma mensagem RESV para R2, sinalizando rótulo 21.
R2 envia uma mensagem RESV para R1, sinalizando rótulo 18
2.5 RSVP-TE (ENGENHARIA DE TRÁFEGO)
RSVP é responsável por sinalizar e manter as reservas de recursos em uma rede. (Osborne, 2002).
Inicialmente a Cisco System enquanto desenvolvia a comutação por TAG fez uso do RSVP e foi a responsável por difundir esse tipo de aplicação. O RSVP-TE reutiliza o RSVP completamente e com muita facilidade. Onde todas as sete mensagens do protocolo têm seu uso no RSVP-TE. Conforme Figura 12. Mesmo quando o ResvConf, que é mensagem responsável pela reserva dos recursos ao longo do caminho seja a menos significativa que em comparação ao uso do RSVP.
Figura12:Mensagens RSVP-TE.
Fonte site: Jamhour, 2015.
periodicamente envia mensagens com o caminho e o Receptor continua mandando requisições de reserva de modo que a tabela de time-out esteja sempre atualizada inerente às mudanças que aconteceram provendo caminhos alternartivos ou fixos de acordo com o serviço de encaminhamento. (Sega, 2000).
Na Figura 13, é observado uma ilustração com a rota dos pacotes usando o RSVP-TE. O IETF tem publicado o RSVP-TE desde então. Por sua vez, o protocolo mesmo não atendendo a todas as exigências necessárias para o MPLS no que diz respeito à distribuição dos rótulos e o controle dos caminhos através das rotas explícitas. (Mendonça, 2012).
Figura 13:Ilustração da rota do pacote usando RSVP-TE.
Fonte: Cisco MPLS - Osborne, 2002
O protocolo RSVP é complexo e, portanto, é pouco realístico esperar que os roteadores empreguem muito recurso para interpretar as requisições RSVP e fazer controles de admissão para os estados estabelecidos. Se houver roteadores no caminho que não entendam o RSVP e não possam fazer a reserva de recursos, então
a conexão de um túnel onde foi implementado, Engenhária de Tráfego entre diversas redes MPLS que rodam o mesmo protocolo, desde que usem OSPF-TE em redes MPLS. (Lolito, 2007).
Figura 14: RSVP-TE usado entre áreas OSPF
Fonte: Lolito, 2007
2.6 ENGENHARIA DE TRÁFEGO
Engenharia de Tráfego é a arte de movimentar o tráfego de modo que o tráfego de um enlace congestionado seja movido para a capacidade não usada de outro enlace. (Osborne 2002)
Segundo Osborne,2002 mais um ponto importante para Engenharia de Tráfego, é que faz alteração dos pacotes, que é utilizá-la com o objetivo de proporcionar requisitos de QoS para determinados tráfegos de dados.
Engenharia de Tráfego é uma tecnologia de Internet, que lida com o desempenho e a otimização de redes IP (Internet Protocol). A Engenharia de Tráfego permite englobar dentro da sua aplicação tecnológica e também científica, mostrando os princípios para medição do balanceamento de cargas, caracterização e controle de tráfego da Internet (Awduche, 1999).
De acordo com Awduche 1999, a Engenharia de Tráfego é uma tecnologia que ajuda no combate do congestionamento do tráfego na rede, otimizando os serviços e fazendo a medição dos pacotes em uma rede IP.
A Engenhária de Tráfego tornou-se uma ferramenta importantíssima nas grandes redes, devido ao alto custo dos equipamentos e também ao grande caráter competitivo na Internet. Isto decorre, do fato das empresas estarem com mais exigências para satisfazer as necessidades de ter mais seguranças na melhor forma possível (Osbone, 2002).
Conforme Osborne, a ET é bastante utilizada em uma empresa, porque com o grande aumento do uso da Internet e a qualidade de serviço dentro de uma rede, a Engenharia de Tráfego pode obter melhorias no tráfego, evitando vários problemas de vulnerabilidade na sua infraestrutura.
Uma das aplicações do roteamento explicito é na Engenharia de Tráfego, onde o objetivo é apresentar como é possível garantir que os diversos caminhos possam ser utilizados para o envio de tráfego, sem sobrecarregar um determinado caminho deixando o outro subutilizado (Mendonça, 2012).
2.7 ENGENHARIA DE TRÁFEGO EM MPLS
para encontrar e estabelecer os caminhos adequados a determinados conjuntos de fluxos de redes. Pela maneira como o MPLS trabalha, pode-se diminuir o congestionamento (Osborne, 2002).
Osborne, ainda afirma que para criar túneis a Engenharia de Tráfego usa o protocolo MPLS-TE (MultIProtocol Label Switching Traffic Engineering), pois faz o balanceamento das cargas dos caminhos distintos ou caminhos diferentes com as taxas de transmissões, para encaminhar o melhor pacote com mais rapidez e mais flexibilidade na rede. Um dos benefícios do uso MPLS-TE é que permite usar o protocolo ISPs para fazer o melhor roteamento do tráfego nas redes e também oferece um dos melhores serviços aos usuários, pois ajudam a combater o atraso da rede. Os roteadores, em seu caminho fazem uma consulta em sua tabela de roteamento para fazer o encaminhamento dos pacotes na rede.
Segundo Mendonça, 2012, no MPLS-TE existe um esquema que é bastante usado para verificar o encaminhamento dos pacotes, chamado de “Problema do Peixe”, pois com esse esquema é feito a criação dos tunéis de Engenharia de Tráfego em MPLS, nele o balanceamento de cargas é suportado com menor custo desigual na rede. O nome foi dado de Problema do Peixe, pois o autor Regan 2002, viu que quando foi configurar uma topologia de uma rede, os roteadores de borda quando estão ligados aos roteadores BackBones formam um corpo de um peixe, essa situação pode ser vista na Figura 15 o caso de uso de Engenharia de Tráfego, sendo demostrado pelo Problema do Peixe.
Fonte: Mendonça, 2012
Olhando para Figura 16, pode-se perceber que existem dois caminhos para chegar o pacote na rede do R1 a R5.
Usando os caminhos faria o uso do (R1->R2->R5) ou (R1->R3->R4->R5). Sabendo que os roteadores tenham a mesma velocidade, usando o protocolo IGP (Interior Gateway Protocol), como o OSPF (Open Shortest Patch First), para ter uma boa escolha de trajeto seria essencial fazer o uso da capacidade, que é disponível nos caminhos de R1 a R5, pois o custo será bastante menor. Em outra ocasião o R1 e R5 se a sua banda foi maior que a velocidade dos outros, ocorrerá em perdas de pacotes.
Fonte: Mendonça, 2012
Nessa situação seria mais viável o uso do MPLS TE na configuração com mostra na Figura 16.
O R6 pega o tráfego R6->R1->R2->R5, já o R7 pegará outro caminho que vai de R7->R1->R3->R4->R5. Então usando o roteamento em MPLS-TE é praticamente possível fazer a configuração de dois caminhos, sendo usado por LSP (Label Switched Path) diferentes, pois cada um vai ter seu tráfego e não terá congestionamento na rede
Existe um grande problema com este cenário, se por acaso tenha um maior tráfego superior aos roteadores R1->R2->R5 os pacotes vão ser descartados, já nos caminhos dos roteadores R1->R3->R4->R5, ainda ficará sem ser usados, ao menos tenha acontecido algo no tráfego do caminho dos roteadores R1->R2->R5, que foi escolhido como prioridade para a passagem dos pacotes, então os caminhos R1->R3->R4->R5, ficará para redundância, quando tiver alguma queda na rede.
O MPLS-TE permite um esquema de Engenharia de Tráfego onde o roteador conhecido como Headend do LSP que é o R1 pode calcular a rota de forma mais eficiente através da rede em direção ao roteador conhecido como Tailend que é o R5. O Headend pode fazer isso se ele conhecer a topologia da rede. (Mendonça, 2012).
É bom ter um conhecimento da banda que está disponível em toda a topologia na rede, e praticamente seja necessário fazer configuração do roteador em MPLS para estabelecer a conexão do LSP nas redes fim a fim.
Na MPLS-TE teve uma grande necessidade para os administradores da rede, por causa das falhas de enlace e dos nós, quando começaram a ser usados os protocolos nas redes. Os túneis são unidirecionais quando é feita a ativação dos caminhos Headend e pelo Tailend. O protocolo IGP é responsável por fazer o roteamento bastante rápido para resolver o problema de contornar as falhas da rede. Porém este problema é resolvido pela MPLS-TE, se existe um enlace que foi enviado pelo LSP e falhar, o LSP será desfeito. É que o Headend faz um novo recálculo de novo caminho e o OSPF tem que novamente ser executado para ser roteado pelo túnel, quando a sua rota automática estiver no mesmo lugar.
Em caso de falhas, de um roteador ocorra o congestionamento da rede em alguma parte, o outro lado da rede fica totalmente livre de congestionamento para ser usado. (Osborne, 2002).
O mecanismo Fast Reroute é usado no MPLS-TE, pois nele os circuitos e roteadores são protegidos por túneis do MPLS-TE que ajuda na proteção de falha nos túneis dentro de uma rede com maior rapidez no tempo, e pode levar bastante segundos para levantar a sua rede, e isso pode causar perda de pacotes. Existem 2 tipos de proteção na Engenharia de Tráfego, são:
Proteção de Caminhos: esta é conhecida como proteção de fim a fim.
Proteção Local: está proteção tem dois tipos de proteção: Proteção do Enlance (Link Protection) e Proteção do Nó (Node Protection).
2.8.1 PROTEÇÃO DE CAMINHOS
A proteção de caminhos ou proteção fim a fim é bastante útil, pois o com essa proteção o estabelecimento do LSP é feito quando é adicionado a um LSP que já está sendo utilizado, porém somente irá ser usado o LSP que foi adicionado, quando o outro tiver algum problema na rede. (Osborne, 2002).
o LSP usado para transportar o tráfego é o principal ou o de proteção. (Osborne, 2002).
Conforme a Figura 17, mostra o caminho do túnel R1 até R7, pois é o caminho percorrido principal pelos roteadores R1->R3->R5->R7. E outro caminho do túnel de proteção que sai do R1 (Hendend) até R7 (Tailend), e passa por outros caminhos.
Figura 17: Proteção de Caminhos
Fonte: Osborne ,2002
2.8.2 PROTEÇÃO LOCAL
O termo proteção local é dado pois quando o túnel de backup é submetido para proteger somente o LSP principal. A proteção de caminhos, ou a proteção local, todos devem existir um LSP de backup, para ajudar na sinalização da rede.
Porém existem dois tipos de Proteção Local, são Proteção de Enlace (Link Protection) e Proteção do Nó (Node Protection).
A Figura 18 mostra as duas proteções, com o túnel principal indo de R1->R3->R5->R7, e em outro caso criando dois túneis de backup, fazendo que o túnel0 pegando o caminho R3->R4->R6->R5, sendo o R3 o Heandend e o R5 Tailend, e túnel1 que pega o caminho R3->R4->R6->R8->R7.
Figura 18: Elementos da Proteção Local
Fonte: Osborne, 2002.
2.8.3 PROTEÇÃO DE ENLACE (LINK PROTECTION)
Nos grandes BackBones das operadoras é bastante comum ter uma visualização dos grandes volumes de tráfegos que são muito importantes, porém quando é feita uma implementação do MPLS-TE nas redes, os LSPs são trazidos como fluxos importantes também. Pode carregar várias informações ao mesmo tempo quando recebe uma resposta em tempo real. (Osborne, 2002)
Enlace, responsáveis por formar LSPs importantes, que são os túneis de backups que estão sinalizados.
A Figura 19 mostra que o enlace R3->R5 é achado como o fator mais importante, pois ajuda a proteger o túnel principal que é o R1 e R7, ou seja, se o túnel principal tiver algum problema, outro túnel de backup será sinalizado em um novo enlace ao redor.
Figura 19: Detalhamento da Proteção do Enlace
Fonte: Osborne, 2002.
2.8.4 PROTEÇÃO DE NÓ (NODE PROTECTION)
Quando um enlace estiver com um problema em um nó protegido, ao mesmo tempo faz o uso de túneis de backups, ou seja, procura outro caminho para chegar ao seu determinado destino. (Osborne, 2002)
Conforme a Figura 6 mostra o problema usando o R5 como o (Nó Protegido) e depois coloca o novo túnel saindo de R3->R4->R6->R8->R7.
roteador R5. Com a proteção do Nó faz o uso de túneis de backups que são chamados de NNHOP (Next-Next-Hop-Router), e não túneis NHOP (Next-Hop Router), pois como mostra a Figura 20, o NNHOP tem como objetivo fazer a proteção contra a falha do próprio NHOP.
Figura 20: Proteção de Nó
Fonte: Osborne, 2002.
3. TOPOLOGIA DO CENÁRIO
3.1 ENDEREÇAMENTO IP
Nesse tópico serão demonstrados os IPs das interfaces dos roteadores que foram utilizados na configuração do laboratório, conforme as Tabelas 4 e 5.
Figura 21: Topologia de Engenharia de Tráfego.
Fonte: Produzida pelo autor
Uma máquina real, Dois CEs (Customer Edges); Dois PE (Provider Edges) e Três Ps (Providers)
Tabela 4: Endereços IP das Interfaces Seriais dos roteadores
Roteador F0/0 S1/0 S1/1 S1/2 S1/3
CE1 192.168.1.2/24 10.0.0.1/30 - - -
CE2 - - 10.0.0.30/24 - -
PE1 - 10.0.0.2/30 10.0.0.5/30 10.0.0.9/30 -
P1 - 10.0.0.13/30 10.0.0.6/30 - 10.0.0.21/30
P2 - 10.0.0.14/30 10.0.0.17/30 - -
P3 - 10.0.0.26/30 10.0.0.18/30 10.0.0.26/30 -
Máq. Real 192.168.1.1/24 - - - -
Gateway 192.168.1.2/24 - - -
Fonte: Produzida pelo autor
Foi configurada em cada roteador do Backbone uma interface Loopback, que será utilizado para estabelecer as vizinhanças entre os roteadores, segue o endereçamento conforme a Tabela 5.
Tabela 5: Endereços IP das Interfaces Loopback dos roteadores
Fonte: Produzida pelo autor
3.1.1 HARDWARES
Roteadores Loopback
PE1 2.2.2.2/24
PE2 6.6.6.6/24
P1 3.3.3.3/24
P2 5.5.5.5/24
Serão abordadas às configurações da parte dos Hardwares, foram usados 7 roteadores na topologia, e que foram distribuídos dessa seguinte forma:
Dois CE (Customer Edges), dois PEs (Provider Edges) e três Ps (Providers), com as seguintes configurações:
Modelo: Cisco 7200 Memória RAM: 512 MB. Memória NVRAM: 128 KB. Memória Flash: 64 MB.
3.1.2 SISTEMAS OPERACIONAIS
Nessa parte, será abordado o IOS dos roteadores que foram usados na implementação do ambiente.
Dois CEs (Customer Edges), dois PEs (Provider Edges) e três Ps (Providers), com os seguintes sistemas:
Nome do software: Cisco IOS (Internetwork Operating System). Versão: 15.1(45) M
Nome completo do arquivo: “c7200-adventerprisek9-mz.151-4.M5”
3.2 CENÁRIO PROPOSTO
Será apresentado a análise dos testes realizados no ambiente do BackBone MPLS, assim como as configurações que foram inseridas no cenário. As análises se encontram divididas nos tópicos a seguir:
Funcionamento no ambiente da operadora sem implementação da Engenharia de Tráfego.
Funcionamento no ambiente do BackBone após a implementação da Engenharia de Tráfego.
Inicialmente será demonstrado as configurações do protocolo MPLS que foram utilizadas na topologia proposta neste trabalho. A Figura 22, mostra os procedimentos para para realizar a configuração nos roteadores.
Figura 22: Configuração do protocolo MPLS
Fonte: Produzida pelo Autor
1º Procedimento
Inicialmente habilitar o CEF (Cisco Express Forwarding) que é usado para agilizar a comutação de pacotes nos roteadores, o comando otimiza o desempenho gerando uma escalabilidade dentro da rede. O CEF é habilitado através do comando IP CEF distributed em todos roteadores do BackBone:
Router(config) #ip cef [distributed].
2º Procedimento: Posteriormente vamos configurar o protocolo OSPF que é ativado pelo comando:
Router(config)#router ospf {process-id}
Router(config)#network {ip-address} {wilcard-mask} área {área-id}
4º Procedimento: E por último, configuramos o MPLS nas interfaces dos roteadores do BackBone, utilizando o comando:
Router(config)#interface {interface-type} {number} Router(config-if)#mpls ip
3.3 TESTES E VERIFICAÇÕES DE FUNCIONAMENTO
Nesse tópico serão realizados testes a respeito da operação e o funcionamento do protocolo MPLS.
Figura 23: Resultado do comando “Show mpls interfaces”
Fonte: Produzida pelo Autor.
Figura 24: Resultado do comando “show mpls ldp neighbor”
Fonte: Produzida pelo Autor
3.4 FUNCIONAMENTO DO BACKBONE SEM IMPLEMENTAÇÃO E APÓS A IMPLEMENTAÇÃO DA ENGENHARIA DE TRÁFEGO
Nesse tópico será apresentado as configurações que foram realizadas nos roteadores do cenário proposto, conforme a Figura 21 o ambiente encontra-se sem implementação da Engenharia de Tráfego. Utilizamos a conexão de uma interface loopback criada em uma máquina real. Foram realizados os testes de conectividade utilizando o comando TRACERT, para verificar a rota que o pacote segue até o roteador CE2.
Na Figura 25, foi executado o comando TRACERT da máquina real até o roteador CE2, o caminho percorrido foi CE1-PE1-P3-PE2-CE2 onde a rota foi escolhida pelo protocolo OSPF tomando como base a largura de banda reservada.
Fonte: Produzida pelo Autor
3.5 CONFIGURAÇÕES MPLS-TE
Inicialmente deverá ser configurada as interfaces dos roteadores que serão associados ao túnel. Recomenda-se utilizar uma interface loopback, pois essa interface encontra-se sempre ativa. É necessário realizar as seguintes configurações:
Router(config)#interface Loopback {number} Router(config-if)#ip address {ip-address} {mask}
Posteriormente habilita-se o MPLS-TE globalmente e nas interfaces, utilizando os seguintes comandos:
Router(config)#mpls traffic-eng tunnels
Router(config)#interface {interface-type} {number} Router(config-if)#ip address {ip-address} {mask} Router(config-if)#mpls traffic-eng tunnels
Router(config)#interface {interface-type} {number}
Router(config-if)#ip rsvp bandwidth {reservable-bandwidth 1-1000000kbps} {maximum-reservable-bandwidth-per-flow 1-1-1000000kbps}
Após realizado as configurações devem ser configurados os parâmetros dos túneis que serão utilizados. Neste trabalho propomos a criação de três túneis: (Túnel 0) que seguirá pelo caminho P1-PE2, (Túnel 1) que seguirá pelo caminho PE1-P3-PE2 e o (Túnel 2) que seguirá pelo caminho PE1-P1-P2-PE1-P3-PE2. É necessário executar os seguintes comandos para configuração dos túneis:
Router(config)#interface tunnel {number}
Router(config-if)#ip unnumbered loopback {number} Router(config)#tunnel mode mpls traffic-eng
Router(config)#tunnel destination {ip-address-of-remote-loopback}
Router(config)#tunnel mpls traffic-eng patch-option {priority} [dynamic bandwidth {override-bandwidth-config-value} | atributes {lsp-atributes-list-name} | lockdown explicit {identifier| name name } ]
Router(config)#tunnel mpls traffic-eng bandwidth {number-kbps}
Router(config)#tunnel mpls traffic-eng priority {setup-priority-value} {hold-priority-value}
Posteriormente configura-se o caminho que será utilizado como LSP da TE com os seguintes comandos, através do comando que pode-se visualizado:
A próxima etapa anuncia-se a interface túnel no protocolo IGP, neste trabalho propomos o uso do protocolo OSPF, a configuração será realizada através dos seguintes comandos:
Router(config)#interface tunnel {number}
Router(config-if)#tunnel mpls traffic-eng autoroute announce
E a última etapa, é fazer a configuração do protocolo IGP. O protocolo que foi utilizado em nosso ambiente de teste foi o OSPF, as configurações do protocolo serão realizadas através dos comandos:
Router(config)#router ospf {process-id}
Router(config-router)#mpls traffic-eng area {area-id}
Router(config-router)#mpls traffic-eng router-id {interface-type} {number}
3.5.1 VALIDAÇÃO DE FUNCIONAMENTO
O objetivo desse tópico é demonstrar que todas as configurações realizadas em nosso ambiente de trabalho, tiveram êxito em seus testes, e serão inseridos os resultados com os comados; “show IP rsvp interface”. Como pode ser verificado na Figura 26, o protocolo RSVP está sinalizado como ENABLE, e encontra-se habilitado em nas interfaces dos roteadores do BackBone.
Fonte: Produzida pelo Autor
Conforme a ilustração da Figura 27, foi realizado o comando “show mpls traffic-eng tunnels brief”, após a configuração de todos os parâmetros do MPLS-TE, foi relizado uma verificação de funcionamento da sinalização do RSVP, que pode ser verificado nos túneis que foram criados na interface do roteador do PE1 do Backbone.
Figura 27: Comando “show mpls traffic-eng tunnels brief”
Na Figura 28, pode ser verificado como foi realizado a configuração dos túneis no roteador PE1 do BackBone e quais os caminhos que o pacote deve seguir dentro da rede.
Figura 28: Configuração dos Túneis MPLS-TE no Roteador BackBone PE1
Fonte: Produzida pelo Autor.
A ilustração da Figura 29, pode ser verificado os caminhos que o pacote pode seguir dentro da rede até o roteador CE2.
Figura 29: Verificando os caminhos percorridos no MPLS-TE.
3.6 CONFIGURAÇÕES DOS TÚNEIS
Nesse tópico serão abordadas as configurações dos túneis relacionados nosso ambiente proposto, foram realizados testes com o comando TRACERT, no prompt de comando, da máquina real até o roteador CE2.
Na Figura 30, pode ser verificada a visualização dos túneis criados para passagem do tráfego, onde será implementado a Engenharia de Tráfego.
Figura 30: Topologia MPLS-TE
Fonte: Produzida pelo Autor
O túnel 0, segue da máquina real até o roteador CE2, pelo caminho (CE1-PE1-PE2-CE2), sendo visualizado pelas Figuras 31 e 32.
Figura 31: Ilustração do túnel 0.
Fonte: Produzida pelo Autor
Figura 32: Rastreando a rota do túnel 0
Fonte: Produzida pelo Autor
Figura 33: Ilustração do túnel 1.
Fonte: Produzida pelo Autor
Figura 34: Rastreando a rota do túnel 1
Fonte: Produzida pelo Autor
Figura 35: Ilustração do túnel 2.
Fonte: Produzida pelo Autor
Figura 36: Rastreando a rota do túnel 2
Fonte: Produzida pelo Autor
3.7 SIMULAÇÃO DE FALHAS
Figura 37: Desativar roteador para demonstrar falha no ambiente
Fonte: Produzida pelo Autor
Na Figura 38, pode ser verificado que o roteador P1 encontra-se inativo e a rota que continua ativa.
Figura 38: Falha de simulação no Roteador P1
Conforme pode ser verificado na Figura 39, após a falha no roteador P1 onde por ele passam as rotas dos túneis T0 e T2, foram realizados testes utilizado o comando TRACERT do PROMPT de comando da máquina real té o roteador CE2, onde pode ser verificado que o túnel T1 se torna a rota principal de tráfego dentro do ambiente da operadora.
Figura 39: Visualização da rota alternativa
Fonte: Produzida pelo Autor
3.8 BALANCEAMENTO DO TRÁFEGO
Outra finalidade da Engenharia de Tráfego é a distribuição de carga que pode ser realizada pelos túneis que foram criados, a distribuição dos pacotes entre os túneis tem a finalidade de impedir que roteadores do backbone fiquem ociosos, enquanto há uma sobrecarga sobre os demais roteadores dentro da rede, com essa distribuição há um ganho de desempenho dentro da rede.
Figura 40: Linha de comando manipulada
Fonte: Produzida pelo Autor
Após realizado as configurações, foi utilizado o PROMPT de comando da máquina real para realizar um PING ate o roteador CE2 conforme pode ser verificado na Figura 41.
Figura 41: Ping realizado no Prompt de comando
Na Figura 42, pode ser verificado os resultados dos testes realizados após a configuração das rotas no roteador PE1, mostrando a distribuição de carga entre os túneis que foram criados, podendo ser verificado que houve tráfego em todos os túneis que foram criados no ambiente da operadora.
Figura 42: Distribuição de tráfego entre os túneis
Fonte: Produzida pelo Autor
4. CONCLUSÃO E CONSIDERAÇÕES FINAIS
O MPLS está cada vez mais presente dentro das operadoras de serviço. É uma tecnologia considerada como promissora, com suporte a vários tipos de serviços; aplicações multimídia e VOIP. Com a crescente demanda e aumento dos enlaces, o MPLS surge como uma solução para as organizações otimizarem o tráfego dentro de suas redes.
O OSPF por sua vez, requer maior recurso de hardware não sendo considerado como única solução, quando comparado com a implementação da Engenharia de Tráfego, conforme propomos neste trabalho.
algum equipamento dentro da rede, além de gerenciar dentro desses BackBones, a criação de túneis para a passagem do tráfego e também a distribuição dos pacotes entre os túneis criados, proporcionando uma maior distribuição de carga (balanceamento), como também a redundância. Maximizar o ganho de desempenho no tráfego dentro da rede e a escalibilidade. Em nosso trabalho não foi possível o detalhamento das tecnologias abordadas, devido as limitações de implementação e pouco tempo, considerando as diversas atividades concorrentes no semestre. São necessários estudos complementares e simulações em cenários com topologias de grande porte.
5. TRABALHOS FUTUROS
Propõe-se então para trabalhos futuros, um aprofundamento relacionado a implementação da aplicação de QoS no BackBone. Deste modo será possível priorizar o tráfego dentro da rede. E também o estudo do endereçamento do protocolo IPV6 onde nas próximas gerações as redes utilizaram essa tecnologia.
6. REFERÊNCIAS
AFONSO, Eduardo, 2011. Protocolo MPLS
Acesso em: 14 de outubro de 2015. Disponível em:
<http://www.tiespecialistas.com.br/2011/04/protocolo-m-p-l-s/>.
AWDUCHE, D.; McManus J, 1999. Requirements for Traffic Engineering over MPLS, Internet.
Acesso em: 6 de outubro de 2015. Disponível em:
<http://www.normes-internet.com/normes.php?rfc=rfc2702&lang=pt>.
COSTA, Sanmia, 2006. Quality of Service.
Acesso em: 12 de agosto de 2015. Disponível em:
<http://www.fmb.edu.br/revista/edicoes/vol_2_num_1/QoS_Quality_Service_.pdf>.
DEA. Martin, 2002. MPLS.
Acesso em: 2 de setembro de 2015. Disponível em: < http://www.gta.ufrj.br/grad/01_2/mpls/>.
