wiki.sj.ifsc.edu.br · agradecimentos primeiramente agradeço a deus, por ter me dado forças para...

Ana Luiza Scharf

Implantação de engenharia de tráfego comMPLS-TE em rede WAN

São José - SC

agosto/2017

Ana Luiza Scharf

Implantação de engenharia de tráfego com MPLS-TE emrede WAN

Monografia apresentada à Coordenação deEngenharia de Telecomunicações do InstitutoFederal de Santa Catarina para a obtençãodo diploma Bacharel em Engenharia de Tele-comunicações.

Instituto Federal de Santa Catarina – IFSC

Campus São José

Engenharia de Telecomunicações

Orientador: Prof. Dr. Marcelo Maia Sobral

São José - SCagosto/2017

Ana Luiza ScharfImplantação de engenharia de tráfego com MPLS-TE em rede WAN/ Ana Luiza

Scharf. – São José - SC, agosto/2017-138 p. : il. (algumas color.) ; 30 cm.

Orientador: Prof. Dr. Marcelo Maia Sobral

Monografia (Graduação) – Instituto Federal de Santa Catarina – IFSCCampus São JoséEngenharia de Telecomunicações, agosto/2017.1. MPLS. 2. Engenharia de tráfego. 3. Qualidade de serviço. I. Prof. Dr. Mar-

celo Maia Sobral II. Instituto Federal de Santa Catarina. III. Campus São José. IV.Implantação de engenharia de tráfego com MPLS-TE em rede WAN

Ana Luiza Scharf

Implantação de engenharia de tráfego com MPLS-TE emrede WAN

Monografia apresentada à Coordenação deEngenharia de Telecomunicações do InstitutoFederal de Santa Catarina para a obtençãodo diploma Bacharel em Engenharia de Tele-comunicações.

Trabalho aprovado. São José - SC, 11 de agosto de 2017:

Prof. Dr. Marcelo Maia SobralOrientador

Prof. Dr. Jorge Henrique BusattoCasagrande

IFSC

Prof. Dr. Odilson Tadeu ValleIFSC

São José - SCagosto/2017

Dedico este trabalho aos meus pais, Jaime e Marli, por tornar esse sonho possível.

Agradecimentos

Primeiramente agradeço a Deus, por ter me dado forças para superar todos osobstáculos e aprender com eles.

Agradeço imensamente aos meus pais, meus exemplos de vida. Sempre me propor-cionaram a melhor educação, amor incondicional, paciência e dedicação. Vocês são a luzque ilumina a minha vida, vocês são o meu lar.

Ao meu orientador, Marcelo Maia Sobral, por seu: conhecimento, paciência ededicação. Por ser mais que um orientador neste trabalho, me ajudou a crescer emocional-mente/profissionalmente e por guiar-me nessa nova etapa da minha vida.

Agradeço todos os professores que dividiram seus conhecimentos e experiênciascomigo e que sempre estavam de prontidão para ajudar. Especialmente ao professor EraldoSilveira e Silva, por ser interessar e auxiliar nesse trabalho.

Aos meus parentes e amigos, que me apoiaram, compreenderam minhas ausênciase torceram por todas as conquistas alcançadas.

E aos meus colegas e amigos de faculdade, pela nossa união para chegar até aqui.Com vocês não compartilhei só conhecimento, mas, também momentos valiosos.

“Desde que a minha vida saiu dos trilhoseu sinto que posso ir a qualquer lugar."

(Zack Magiezi)

ResumoA demanda por rede Wide Area Network (WAN) com alta capacidade de transmissãosempre aumenta. Empresas espalhadas geograficamente e provedores de dados são exemplosdesse tipo de infraestrutura. O presente trabalho propõe aplicar a tecnologia MultiprotocolLabel Switching (MPLS) combinada com engenharia de tráfego como uma forma de atenderquatro demandas típicas de redes WAN. A primeira envolve facilitar a implantação deenlaces para clientes, o que envolve automatizar a escolha de caminhos dentro da rede. Asegunda diz respeito a incrementar a robustez a falhas, para maximizar a conectividadedos enlaces dos clientes. A terceira se relaciona com o aumento do aproveitamento dascapacidades dos enlaces da rede, com o objetivo de melhorar seu desempenho. A quartademanda se refere ao tratamento diferenciado para tráfegos em função de seus tipos oudos clientes que os geraram. Experimentos realizados com um simulador demonstraramo atendimento dessas demandas em uma rede MPLS usando técnicas de engenharia detráfego e diferenciação de serviços.

Palavras-chave: MPLS-TE, Engenharia de tráfego, QoS, Simulação.

Abstract

There is an always increasing demand for high capacity Wide Area Network (WAN)networks. Networks pertaining to geographically dispersed companies and data serviceproviders are examples of this kind of infrastructure. This work proposes the use ofMultiprotocol Label Switching (MPLS) technology and traffic engineering to attend fourtypical demands of WAN networks. The first one relates to facilitate the deployment ofdata links to network clients, and this implies the automated selection of paths within thenetwork. The second one corresponds to the increase of network resilience, to maximizeconectivity time of clients data links. The third is related to the improvement of utilizationof data links capacities, such that network performance is increased. The fourth demandconcerns to the differentiated treatment of network traffic with respect to the kinds of flowsor the clients who generated them. Simulation experiments demonstrated the fulfillmentof these demands in a MPLS network with traffic engineering techniques and servicedifferentiation.

Keywords: MPLS-TE, Traffic engineering, QoS, Simulation.

Lista de Figuras

Figura 1 – Exemplo de cenário sem/com engenharia de tráfego. . . . . . . . . . . 25Figura 2 – Exemplo de cenário sem engenharia de tráfego. . . . . . . . . . . . . . 30Figura 3 – Exemplo de cenário com engenharia de tráfego. . . . . . . . . . . . . . 30Figura 4 – Cenário com componentes do MPLS. . . . . . . . . . . . . . . . . . . . 32Figura 5 – Localização do MPLS em relação ao modelo TCP/IP. . . . . . . . . . . 33Figura 6 – Encapsulamento do MPLS. . . . . . . . . . . . . . . . . . . . . . . . . 33Figura 7 – Campos do frame MPLS. . . . . . . . . . . . . . . . . . . . . . . . . . 34Figura 8 – Relação da LIB com as demais tabelas. . . . . . . . . . . . . . . . . . . 36Figura 9 – Diagrama de tempo da troca de mensagens do LDP. . . . . . . . . . . 39Figura 10 – Túnel LSP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Figura 11 – Cenário indicando as interfaces. . . . . . . . . . . . . . . . . . . . . . . 40Figura 12 – Sessões LDPs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41Figura 13 – Cenário MPLS com suas tabelas de encaminhamento. . . . . . . . . . . 41Figura 14 – Transmissão de pacotes no domínio MPLS. . . . . . . . . . . . . . . . . 42Figura 15 – Particionamento de áreas pelo OSPF. . . . . . . . . . . . . . . . . . . . 44Figura 16 – Cenário de RSVP com origem finalizando o fluxo de pacotes. . . . . . 46Figura 17 – Cenário de RSVP com destino finalizando o fluxo de pacotes. . . . . . 46Figura 18 – Cenário de RSVP com erro na mensagem ResvErr. . . . . . . . . . . . 47Figura 19 – Cenário de RSVP com erro na mensagem PathErr. . . . . . . . . . . . 47Figura 20 – Cenário de distribuição dos rótulos com MPLS RSVP–TE. Fonte: (INC,

2013). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47Figura 21 – Cenário do domínio BGP. . . . . . . . . . . . . . . . . . . . . . . . . . 50Figura 22 – Cenário para explicar o VRF Fonte: (BUBNOV, 2016). . . . . . . . . . 52Figura 23 – Reserva de largura de banda com MAM. . . . . . . . . . . . . . . . . . 60Figura 24 – Reserva de largura de banda com RDM. . . . . . . . . . . . . . . . . . 61Figura 25 – Topologia base para simulação dos ambientes. . . . . . . . . . . . . . . 63Figura 26 – Cenário protótipo com o particionamento de áreas pelo OSPF. . . . . . 65Figura 27 – Cenário para os teste de balanceamento de carga. . . . . . . . . . . . . 70Figura 28 – Cenário com desligamento do roteador R18. . . . . . . . . . . . . . . . 72Figura 29 – Cenário com desligamento do roteador R17. . . . . . . . . . . . . . . . 73Figura 30 – Empilhamento de rótulos por causa da VPN. . . . . . . . . . . . . . . 75Figura 31 – Diagrama dos mecanismos de QoS para arquitetura Diffserv. . . . . . . 76Figura 32 – Topologia indicando as VPNs. . . . . . . . . . . . . . . . . . . . . . . . 81Figura 33 – Topologia indicando os túneis. . . . . . . . . . . . . . . . . . . . . . . . 82Figura 34 – Topologia indicando as políticas de serviços na interface. . . . . . . . . 83Figura 35 – Cenário1: Topologia indicando os tráfegos oriundos do Cliente02. . . . 88

Figura 36 – Cenário2: Topologia indicando os tráfegos oriundos do Cliente02. . . . 89Figura 37 – Cenário3: Topologia indicando os tráfegos oriundos do Cliente02 e

Cliente04. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90Figura 38 – Gráfico das taxas do tráfego de melhor esforço para o Cenário1. . . . . 91Figura 39 – Gráfico das taxas do tráfego de melhor esforço para o Cenário2. . . . . 92Figura 40 – Gráfico das taxas do tráfego de melhor esforço para o Cenário3. . . . . 92Figura 41 – Gráfico com a taxa do tráfego de melhor esforço em 1 Mbps para o

todos os cenários. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93Figura 42 – Cenário 1 com tráfego de melhor esforço com a taxa de 2 Mbps. . . . . 96Figura 43 – Cenário 2 com tráfego de melhor esforço com a taxa de 2 Mbps . . . . 97Figura 44 – Gráfico das taxas do tráfego de melhor esforço para o Cenário3 para o

Cliente04. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

Lista de tabelas

Tabela 1 – Tabela NHLFE (SANTOS et al., 2003). . . . . . . . . . . . . . . . . . 36Tabela 2 – Tabela ILM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37Tabela 3 – Tabela FTN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37Tabela 4 – Comparação entre L–LSP e E-LSP. . . . . . . . . . . . . . . . . . . . . 59Tabela 5 – Endereços dos equipamentos. . . . . . . . . . . . . . . . . . . . . . . . 63Tabela 6 – Teste01: túneis com a mesma largura de banda. . . . . . . . . . . . . . 71Tabela 7 – Teste02: distribuição de túneis. . . . . . . . . . . . . . . . . . . . . . . 71Tabela 8 – Teste03: túneis com prioridades diferente e um único caminho disponível. 71Tabela 9 – Classificação e politica de mapeamento Input. . . . . . . . . . . . . . . 83Tabela 10 – Classificação e politica de mapeamento Core. . . . . . . . . . . . . . . 84Tabela 11 – Dados dos relatórios do PJSUA para todos os cenários. . . . . . . . . . 95Tabela 12 – Comparação entre o comportamento pretendido e ocorridos, variando a

taxa do tráfego do fundo. . . . . . . . . . . . . . . . . . . . . . . . . . 98Tabela 13 – Comparação entre o comportamento pretendido e ocorridos, entre os

cenários. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99Tabela 14 – Conversão do DSCP para nível de precedência. . . . . . . . . . . . . . 108Tabela 15 – Dados dos relatórios do PJSUA do Cliente4 para o Cenário 3. . . . . . 109Tabela 16 – Configuração do VRF com VPN. . . . . . . . . . . . . . . . . . . . . . 110Tabela 17 – Configuração dos comandos globais. . . . . . . . . . . . . . . . . . . . 110Tabela 18 – Configuração para interface loopback. . . . . . . . . . . . . . . . . . . . 110Tabela 19 – Configuração para interface que se conecta ao cliente. . . . . . . . . . . 110Tabela 20 – Configuração para interface que se conecta ao LER. . . . . . . . . . . . 111Tabela 21 – Configuração do OSPF-TE. . . . . . . . . . . . . . . . . . . . . . . . . 111Tabela 22 – Configuração do BGP e da VPN. . . . . . . . . . . . . . . . . . . . . . 112Tabela 23 – Configuração do túnel da engenharia de tráfego. . . . . . . . . . . . . . 113Tabela 24 – Configurações possíveis para a classificação. . . . . . . . . . . . . . . . 113Tabela 25 – Configurações para marcação e policiamento de tráfego. . . . . . . . . 113Tabela 26 – Configurações para condicionamento de tráfego e reserva da largura de

banda. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

Lista de abreviaturas e siglas

AS Autonomous System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

ATM Asynchronous Transfer Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

BA Behavior Aggregate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

BGP Border Gateway Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

CE Custumer Edge Equipament . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

CFTV Circuito Fechado de Televisão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

CoS Classes of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

CSPF Constrained Shortest Path First . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

CT Class Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

DCN Data Communication Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Diffserv Serviços Diferenciados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23

DSCP Differentiated Services Code Point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54

DS–TE MPLS com DiffServ-TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

eBGP externa Border Gateway Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

E–LSP EXP - Inferred - LSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

EF Expedited Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

FEC Forwarding Equivalency Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

FRR Fast Reroute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

FTN FEC-To-NHLFE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

iAS inter-AS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51

iBGP interna Border Gateway Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50

IBM International Business Machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

IETF Internet Engineering Task Force . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31

IGP Interior Gateway Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43

ILM Incoming Label Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

IntServ Serviços Integrados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

IP Internet Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

IPSec Internet Protocol Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

IPv4 Internet Protocol version 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

IPv6 Internet Protocol version 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

IS–IS Intermediate System to Intermediate System Protocol . . . . . . . . . . . . . . . . . . . . . . . . 43

L2TP Layer 2 Tunnelling Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

LDP Label Distribution Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

LER Label Edge Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

LIB Label Information Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35

L–LSP Label-Only-Inferred-LSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .59

LSA Link-State Advertisement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

LSP Label Switch Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31

LSR Label Switch Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

MAC Media Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

MAM Maximum Allocation Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

MP–BGP Multiprotocol–Border Gateway Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52

MPLS Multiprotocol Label Switching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

MPLS–TE Multiprotocol Label Switching com Engenharia de Tráfego . . . . . . . . . . . . . 23

MTU Maximum Transmission Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

NHLFE Next Hop Label Forwarding Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

NS–2 Network Simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23

OPGW Optical Ground Wire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21

OSI Open Systems Interconnection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

OSPF Open Shortest Path First . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

OSPF-TE Open Shortest Path First - Traffic Engineering . . . . . . . . . . . . . . . . . . . . . . . . .44

PE Provider Edge Equipament . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

PDU Professional Development Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

PHB Per Hop Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

PHB–AF PHB - Assured Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

PHB–EF PHB - Expedited Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58

PPTP Point-to-Point Tunneling Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48

QoS Quality of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

RD Route Distinguisher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

RDM Russian Doll Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

RED Random Early Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

RFC Request For Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

RIP Routing Information Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

RSVP Resource Reservation Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37

RSVP–TE Resource Reservation Protocol - Traffic Engineering . . . . . . . . . . . . . . . . . . . 47

RTP Real-time Transport Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

RTT Round–Trip Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

SIP Session Initiation Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

SLA Service Level Agreement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

TCP Transmission Control Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

TED Traffic Engineering Database. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44

ToS Type of Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

TTL Time To Live . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

UDP User Datagram Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

VLAN Virtual Local Area Vetwork . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

VPN Virtual Private Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

VPRN Virtual Private Routed Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

VRF Virtual Routing and Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

WAN Wide Area Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

WFQ Weighted Fair Queuing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55

WRED Weighted Random Early Detectionn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56

Sumário

1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231.2 Objetivo geral e específico . . . . . . . . . . . . . . . . . . . . . . . . 231.3 Organização do texto . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2 FUNDAMENTAÇÃO TEÓRICA . . . . . . . . . . . . . . . . . . . . 252.1 Engenharia de tráfego . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.1.1 Subsistemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.1.1.1 Medição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.1.1.2 Modelagem e análise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.1.1.3 Otimização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.1.2 Funcionalidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.1.2.1 Controle de admissão de novas conexões . . . . . . . . . . . . . . . . . . . . 282.1.2.2 Roteamento baseado em restrições . . . . . . . . . . . . . . . . . . . . . . . 282.1.2.3 Rerroteamento das conexões já estabelecidas . . . . . . . . . . . . . . . . . . 282.1.3 SLA-Service Level Agreement . . . . . . . . . . . . . . . . . . . . . . . . 292.1.4 Exemplo de cenários de engenharia de tráfego . . . . . . . . . . . . . . . . 292.2 Multiprotocol Label Switching - MPLS . . . . . . . . . . . . . . . . . 312.2.1 Histórico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312.2.2 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322.2.2.1 PDU- (Professional Development Unit) . . . . . . . . . . . . . . . . . . . . . 322.2.2.2 Label Switch Router - LSR . . . . . . . . . . . . . . . . . . . . . . . . . . . 342.2.2.3 Label Edge Router - LER . . . . . . . . . . . . . . . . . . . . . . . . . . . 352.2.2.4 Forwarding Equivalence Class - FEC . . . . . . . . . . . . . . . . . . . . . . 352.2.2.5 Label Information Base - LIB . . . . . . . . . . . . . . . . . . . . . . . . . 352.2.2.6 Next Hop Label Forwarding Entry - NHLFE . . . . . . . . . . . . . . . . . . 362.2.2.7 Incoming Label Map - ILM . . . . . . . . . . . . . . . . . . . . . . . . . . 362.2.2.8 FEC–to–NHLFE – FTN. . . . . . . . . . . . . . . . . . . . . . . . . . . . 372.2.2.9 Label Switched Path - LSP . . . . . . . . . . . . . . . . . . . . . . . . . . . 372.2.3 Label Distribution Protocol - LDP . . . . . . . . . . . . . . . . . . . . . . 382.2.3.0.1 Categorias das mensagens LDP . . . . . . . . . . . . . . . . . . . . . . . . . . 38

2.2.3.1 Empilhamento de rótulos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392.2.3.2 Funcionamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402.3 MPLS-TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422.3.1 Estabelecimento de LSP . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

2.3.1.1 Open Shortest Path First - Traffic Engineering - OSPF-TE . . . . . . . . . . . 432.3.1.2 Resource Reservation Protocol - RSVP . . . . . . . . . . . . . . . . . . . . . 452.3.1.2.1 Mensagens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

2.3.1.2.2 RSVP–TE com MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

2.4 VPN MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482.4.1 Virtual Private Network - VPN . . . . . . . . . . . . . . . . . . . . . . . . 482.4.2 MPLS VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492.4.2.1 Border Gateway Protocol - BGP . . . . . . . . . . . . . . . . . . . . . . . . 492.4.2.1.1 Sessão BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

2.4.2.1.2 Atributos BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

2.4.2.1.3 Rotas do BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

2.4.2.2 Virtual Routing and Forwarding - VRF . . . . . . . . . . . . . . . . . . . . . 512.5 MPLS com qualidade de serviço . . . . . . . . . . . . . . . . . . . . . 532.5.1 QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532.5.1.1 Mecanismo de QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532.5.1.1.1 Classificação e Marcação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

2.5.1.1.2 Policiamento - Policing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

2.5.1.1.3 Priorização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

2.5.1.1.4 Prevenção de congestionamento - Congestion Avoidance . . . . . . . . . . . . . . . 56

2.5.1.1.5 Condicionamento de tráfego –Traffic Shaping . . . . . . . . . . . . . . . . . . . 56

2.5.2 MPLS-TE e DiffServ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 572.5.2.1 Arquitetura Diffserv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 572.5.2.1.1 Mapeamento do Diffserv para MPLS . . . . . . . . . . . . . . . . . . . . . . . 58

2.5.2.2 DiffServ com engenharia de tráfego . . . . . . . . . . . . . . . . . . . . . . . 59

3 IMPLANTAÇÃO DA REDE MPLS . . . . . . . . . . . . . . . . . . . 623.1 Cenário de simulação . . . . . . . . . . . . . . . . . . . . . . . . . . . 623.2 Configuração inicial do MPLS . . . . . . . . . . . . . . . . . . . . . . 643.3 MPLS com engenharia de tráfego . . . . . . . . . . . . . . . . . . . . 663.3.1 Balanceamento de carga . . . . . . . . . . . . . . . . . . . . . . . . . . . 703.3.2 Recuperação de perda da conectividade . . . . . . . . . . . . . . . . . . . 723.4 VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 743.5 QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

4 SIMULAÇÕES E RESULTADOS . . . . . . . . . . . . . . . . . . . . 794.1 Planejamento da simulação . . . . . . . . . . . . . . . . . . . . . . . . 794.1.1 Roteadores de borda (LER) . . . . . . . . . . . . . . . . . . . . . . . . . . 794.1.2 Roteadores de núcleo (LSR) . . . . . . . . . . . . . . . . . . . . . . . . . 804.1.3 Cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 814.1.4 VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

4.1.5 Engenharia de tráfego . . . . . . . . . . . . . . . . . . . . . . . . . . . . 824.1.6 Diffserv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 824.2 Formato dos experimentos . . . . . . . . . . . . . . . . . . . . . . . . 844.2.1 Cenários dos testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 874.3 Análise dos resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . 904.3.1 Taxa de transmissão do tráfego de melhor esforço . . . . . . . . . . . . . . 904.3.2 Dados da chamada SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 944.3.3 Taxa de transmissão do trafego da chamada SIP . . . . . . . . . . . . . . 964.3.4 Resultados e discussão . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

5 CONCLUSÕES E TRABALHO FUTUROS . . . . . . . . . . . . . . 100

REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

APÊNDICES 107

APÊNDICE A – TABELA DE CONVERSÃO DO DSCP . . . . . . 108

APÊNDICE B – RESULTADOS DO CLIENTE04 . . . . . . . . . . 109

APÊNDICE C – CONFIGURAÇÃO DOS ROTEADORES . . . . . 110C.1 Explicação dos comandos de configuração . . . . . . . . . . . . . . . 110C.2 Configuração do roteador R11 . . . . . . . . . . . . . . . . . . . . . . 114C.3 Configuração do roteador R12 . . . . . . . . . . . . . . . . . . . . . . 118C.4 Configuração do roteador R13 . . . . . . . . . . . . . . . . . . . . . . 120C.5 Configuração do roteador R14 . . . . . . . . . . . . . . . . . . . . . . 122C.6 Configuração do roteador R15 . . . . . . . . . . . . . . . . . . . . . . 123C.7 Configuração do roteador R16 . . . . . . . . . . . . . . . . . . . . . . 128C.8 Configuração do roteador R17 . . . . . . . . . . . . . . . . . . . . . . 132C.9 Configuração do roteador R18 . . . . . . . . . . . . . . . . . . . . . . 136

21

1 Introdução

Uma rede Wide Area Network (WAN) pode ser entendida como uma rede decomputadores ou de telecomunicações que se estende por uma ampla área geográfica, desdecidades até países. Esse tipo de rede aparece na forma de redes corporativas, metropolitanas,estaduais e provedores de dados, e interliga uma grande quantidade de clientes. Os recursosusados para compor tais redes, tais como enlaces de longa distância e roteadores, apresentamum custo significativo. Devido a características de uso da capacidade de uma rede WAN,que transporta os dados de clientes por ela interligados, o aproveitamento e a garantia dedisponibilidade desses recursos da rede apresentam desafios. Dentre as tecnologias pararedes WAN existentes, Multiprotocol Label Switching (MPLS) oferece um conjunto detécnicas para atender essas e outras necessidades.

Um tipo de rede WAN corresponde a redes corporativas, em que uma empresapossui uma rede para interligar diversas unidades distribuídas geograficamente. Umexemplo é o da rede da Eletrosul – Centrais Elétricas S.A. Ela atua nos segmentos degeração, transmissão e comercialização de energia. Para entregar energia elétrica a todosos cidadãos, esse tipo de empresa normalmente tem uma infraestrutura de distribuiçãoampla para abranger todas as cidades do seu território de atuação. No caso da Eletrosul,a mesma infraestrutura para prover energia elétrica é utilizada para conceber a redede telecomunicações. Especificamente é o cabo Optical Ground Wire (OPGW) queproporciona esse aproveitamento. Nas linhas de transmissão de energia elétrica eles sãoutilizados como cabo pára-raios. Já o núcleo do OPGW contém fibra óptica, que serve paratransportar um grande fluxo de dados em longas distâncias (GOMES, 2013). A necessidadede possuir uma infraestrutura de telecomunicações surgiu para identificar o rompimentoda linha de transmissão de energia. Posteriormente, ela também foi usada para transportaros dados gerados pelas usinas e pelas subestações, que são monitoradas remotamente.

A infraestrutura da empresa Eletrosul está espalhada pelos três estados da RegiãoSul e o estado de São Paulo. Por causa do extenso território, esse tipo de rede temmais de uma unidade (centro de operações) para abranger essa região. A Eletrosulpossui sua sede em Florianópolis e diversas unidades espalhadas pela região. Através dosistema de telecomunicações, a Eletrosul disponibiliza diversos serviços, tais como redecorporativa, medição de tráfego, medição de faturamento, Circuito Fechado de Televisão(CFTV), rede Data Communication Network (DCN) para controlar os equipamentos detelecomunicações, telefonia e rede de convivência (acesso a Internet via wifi em horáriosespecíficos). Todos esses dados trafegam por uma rede WAN, por meio do sistema decomunicação óptica de alta velocidade.

Capítulo 1. Introdução 22

Esse tipo de infraestrutura de telecomunicações pode também estar presente emoutras empresas, organizações, prestadoras de serviços de acesso dedicado à internet etelecomunicações, citando-se o governo estadual, Telebras, Celesc, Oi e Petrobras. Esseperfil de empresa possui várias filiais dispostas em locais estratégicos de acordo com suasnecessidades de operação. Além disso, a existência de diversos tipos de tráfego circulandopor essa rede é comum nesse contexto.

Nessas redes WAN algumas necessidades podem ser identificadas. A primeiraé facilitar o processo de virtualização do enlace, para diminuir a intervenção de umoperador de rede para cada nó ou cliente que se conecte à malha. A segunda demanda égarantir conectividade da rede, mesmo que haja falha de enlace. A terceira é melhorar oaproveitamento da capacidade da rede, representada pela utilização do seu conjunto deenlaces. Por fim, é necessário atender requisitos de qualidade de serviço para diferentestipos de tráfego.

Um requisito fundamental para as empresas é manter a conectividade, especialmentese a própria empresa tiver sua infraestrutura. No caso dos provedores de serviço e detelecomunicações isso é mais premente, pois os clientes pagam para ter disponibilidadeintegral. Contudo, as empresas não podem prever quando e onde haverá rompimento deum enlace. Diante disso, a infraestrutura de telecomunicações deve se apresentar comuma topologia em malha, de forma que existam caminhos alternativos para que os dadospossam ser redirecionados em caso de necessidade. Além disso, deseja-se simplificar avirtualização do enlace, de forma que os clientes da rede não precisem tomar conhecimentosobre o caminho específico que seus pacotes percorrem ao longo da topologia da redeWAN.

Outra demanda é melhorar o aproveitamento dos recursos da rede, principalmentesobre a utilização do enlace. Se o tráfego for mal distribuído pode favorecer congestiona-mentos, por ter mais dados direcionados por um enlace do que sua capacidade suportada.Enquanto isso, os demais enlaces ficam ociosos, ou seja, o recurso de largura de bandado conjunto de enlaces não é aproveitado. Se o tráfego for distribuído uniformemente, achance de congestionamento diminui e não ocorre o desperdício dos enlaces.

Por isso, há necessidade de utilizar uma tecnologia capaz de resolver esses problemas.Uma possível solução para atender essas demandas é a tecnologia de rede MPLS, combinadacom técnicas e mecanismos de engenharia de tráfego. Com isso, pode-se melhorar odesempenho da rede, por meio da distribuição igualitária do tráfego para todos os enlacesda rede.

Por fim, MPLS permite trabalhar juntamente com Quality of Service (QoS) paraque os diversos tipos de serviços e tráfegos possam ser tratados de forma diferenciada. Issotem por objetivo atender “requisitos das aplicações para a qual exige-se que determinadoparâmetros (atrasos, vazão, perdas,...) estejam dentro de limites bem definidos (valor


máximo, valor mínimo)” (CHISTE, 2004). A diferenciação de serviços em uma rede MPLSpode ser realizada seguindo o modelo Serviços Diferenciados (Diffserv). Segundo Request.et al. (1998), esse modelo se baseia em classificação, marcação e condicionamento detráfego na borda da rede, e encaminhamento diferenciado no núcleo da rede. Possuir QoSna rede possibilita que os clientes possam contratar serviços conforme sua demanda detráfego e seus requisitos de aplicação.

1.1 MotivaçãoEste trabalho se baseou na rede da empresa da Eletrosul - Centrais Elétricas

S.A, para estudar o cenário de empresas com rede WAN de alta velocidade. O estudo seconcentrou principalmente nas tecnologias de camada de rede e de enlace.

Duas necessidades se evidenciaram durante a investigação: i) a subutilização dacapacidade da rede, e ii) a deficiência no tempo de recuperação da conectividade em casode falha de enlace. Relacionada com a primeira delas, não existiam formas de controlar oudeterminar os caminhos dentro da rede por onde passam os diversos tráfegos, e desconheciaquais deles utilizam mais a rede. Isso inclusive dificultava o atendimento de seus requisitosde QoS.

Foi sugerido pela Eletrosul averiguar se a tecnologia MPLS, em conjunto comengenharia de tráfego, poderia atender essas necessidades. Existem vários estudos sobre oemprego dessas técnicas. O MPLS possui diversos artigos e livros explicando sua estruturae cenário onde foi empregado, pois, essa tecnologia já está consolidada.

Um exemplo desse estudo é a tese de doutorado de Maia (2006), cujo objetivo éusar MPLS para dar suporte tanto à engenharia de tráfego e a qualidade de serviço, paraassegurar os tráfegos de dados, voz e vídeo.

Outro estudo foi a tese de mestrado por Purificação (2002). Ele implementaMultiprotocol Label Switching com Engenharia de Tráfego (MPLS–TE) com garantias deQoS. Foi realizado um cenário de simulação utilizando o simulador Network Simulator(NS–2), para avaliar as seguintes métricas: redução na perda de pacotes, atraso e variaçãode atraso e o aumento da vazão agregada.

1.2 Objetivo geral e específicoEste trabalho tem como objetivo implantar na rede WAN a tecnologia MPLS,

explorando a engenharia de tráfego para maximizar a utilização da sua capacidade. Seusobjetivos específicos são:

• Melhorar a utilização da capacidade da rede: aplicar a tecnologia de engenharia


de tráfego;

• Facilitar o processo de virtualização do enlace: utilizar Virtual PrivateNetwork (VPN) agregado com a tecnologia MPLS;

• Reduzir o tempo de recuperação de falha de enlace: via tecnologia MPLS;

• Atender requisitos de QoS: implantar um modelo de QoS.

1.3 Organização do textoO texto está organizado da seguinte forma: No Capítulo 2 é apresentada uma

revisão teórica sobre MPLS, além de virtualização de enlaces, engenharia de tráfego, QoS earquitetura Diffserv, relacionando esses conceitos. No Capítulo 3 é apresentada a propostadesse trabalho de conclusão de curso, que foi a simulação da implantação do MPLS–TEem rede WAN a fim de investigar o comportamento das tecnologias envolvidas em algunscenários representativos. O Capítulo 4 trata dos experimentos realizados deste trabalho eseus resultados. Por fim, o Capítulo 5 apresenta as conclusões desse estudo.

25

2 Fundamentação Teórica

2.1 Engenharia de tráfegoO grande fluxo de pacotes trafegando na rede pode causar um subaproveitamento

de sua capacidade, o que se manifesta por congestionamentos em setores de uma redeenquanto em outros há ociosidade. A engenharia de tráfego é um conjunto de técnicasque visa melhorar o aproveitamento da capacidade de uma rede. Segundo Awduche. et al.(2009), as principais metas da engenharia de tráfego são facilitar operações de rede eficientese confiáveis e, conjuntamente, poupar os recursos da rede e melhorar seu desempenho.

Engenharia de tráfego implica no estudo da rede para determinar a melhor forma dedistribuir os fluxos de pacotes, evitando congestionamentos e enlaces ociosos. A Figura 1.amostra roteamento de pacotes utilizando o protocolo Open Shortest Path First (OSPF),que roteia os pacotes pelo menor caminho entre origem e destino. Percebe-se que o caminhoselecionado está congestionado, pois nesse enlace passam todos os pacotes, enquantocaminhos alternativos estão livres. A Figura 1.b, mostra esse mesmo cenário, porém coma utilização da engenharia de tráfego. Nessa situação, todos os caminhos são utilizados,promovendo uma maior eficiência da rede e maior aproveitamento de seus recursos.

Figura 1 – Exemplo de cenário sem/com engenharia de tráfego.

Capítulo 2. Fundamentação Teórica 26

Diversos tipos de procedimentos e técnicas compõem a engenharia de tráfego. Aengenharia de tráfego engloba aplicações e princípios científicos de medidas, modelagem,caracterização e controle de tráfego (PAIXÃO et al., 2007), como meio para melhorar odesempenho da rede. Há dois objetivos principais referentes à engenharia de tráfego:

• tráfego orientado: com intuito de melhorar o desempenho, aperfeiçoa os requisitosde QoS no fluxo de dados, assim melhora o performance das seguintes métricas:minimiza a perda de pacotes, minimiza o atraso, maximiza a vazão e reforça osacordos estabelecidos para os tráfegos que possuem requisitos de QoS (PAIXÃO etal., 2007);

• recurso orientado: utilizado pela engenharia de tráfego para aproveitar melhor osrecursos da rede. Isto é, haverá subconjuntos de recursos da rede, evitando casosde sobrecarregamento e subutilização dos subconjuntos (PAIXÃO et al., 2007). Deacordo com Awduche. et al. (2009), a largura de banda é o recurso fundamental paraser gerido pela engenharia de tráfego.

2.1.1 Subsistemas

Segundo Awduche. et al. (2002), a engenharia de tráfego possui quatro subsiste-mas: medição, modelagem, análise e otimização. Nas subseções a seguir, será explicadodetalhadamente cada subsistema.

2.1.1.1 Medição

A medição é essencial para o processo de engenharia de tráfego. Ela coleta dadospara indicar o estado atual da rede, que são diversos, pois, dependem da finalidadeda engenharia de tráfego. Citam-se como exemplos característica dos pacotes, fluxo dedados, características dos clientes, entre outros. Com o resultado desse monitoramento dosparâmetros escolhidos, a engenharia de tráfego pode conferir o desempenho medido darede com a otimização desejada (AWDUCHE. et al., 2002).

2.1.1.2 Modelagem e análise

Para a engenharia de tráfego, a etapa de modelagem é fundamental para todo oprocesso (AWDUCHE. et al., 2002). Nela ocorre o levantamento de todas as característicasda rede e de seus componentes, dentre eles os enlaces, a topologia e limitações da rede epossivelmente outros fatores. Deste modo, a modelagem facilita o processo de análise darede, para posteriormente modificar esses atributos e promover maior eficiência.

De acordo com Awduche. et al. (2002), a modelagem se divide em duas categorias:estrutural e comportamental. A primeira dedica-se apenas a organizar as redes e seus


componentes. Já a modelagem comportamental se concentra principalmente nos fluxos depacotes que trafegam na rede, ou seja, como esses fluxos se comportam, por onde passam,quando acontece o maior volume fluxo de tráfego e a origem e destino dos pacotes.

Entre os dois enfoques, o mais utilizado é a modelagem comportamental, vistoque ele fornece dados sobre como os fluxos de pacotes transitam pela rede. Quanto maispreciso forem esses dados, maior conhecimento do comportamento da rede se tem, com isso,podem-se inferir pontos problemáticos, tais como congestionamentos, pontos de falhas,gargalos e limitações dos enlaces.

Para analisar, utiliza-se a simulação para investigar o comportamento da rede. Asinformações obtidas na análise possibilitam a criação de um modelo de simulação e adefinição de cenários. Pode-se simular a rede de tal forma identificar problemas, tais comoaqueles citados no parágrafo anterior. Os resultados da simulação possibilitam analisar ocomportamento da rede e consequentemente, sugerir e experimentar soluções para essesproblemas. Esse mesmo método é utilizado para verificar se ampliação da rede é viável esatisfatória.

2.1.1.3 Otimização

O componente de otimização tem como propósito corrigir os problemas que aconte-cem na rede. Segundo Awduche. et al. (2002), são divididos em dois modos, o primeiro éotimização corretiva, ela tem a intenção de solucionar os problemas ocorridos ou que estãoiniciando. O segundo modo refere-se a melhorar o desempenho, sem que haja efetivamenteum problema na rede.

A otimização permite alterar o tráfego de pacotes. Ela monitora o fluxo de dados,conhecendo os caminhos dos pacotes e como eles estão distribuídos da rede. Com essacompreensão da rede, a otimização é capaz de proteger ou amenizar um congestionamento,garantindo a entrega dos pacotes. A otimização acontece principalmente para cenáriosocasionais, tais quais: rompimento de um enlace ou uma grande demanda de dados. Nessescasos, a rede tem que corrigir esses problemas o mais breve possível para que não hajagrande perda de pacotes, durante esse incidente (AWDUCHE. et al., 2002).

2.1.2 Funcionalidades

Conforme Girish, Zhou e Hu (2000), a engenharia de tráfego possui algumas funções,porém, as quatro principais são: controle de admissão de novas conexões, roteamentobaseado em restrições, rerroteamento das conexões já estabelecidas e planejamento derecursos de redes. Esses itens serão explicados detalhadamente nas seções a seguir.


2.1.2.1 Controle de admissão de novas conexões

O controle de admissão de novas conexões é a capacidade de aceitar ou negaruma nova requisição. Para conceder esse pedido, há uma série de levantamentos sobreo estado da rede. Verifica se há largura de banda suficiente em toda topologia da rede.Também é averiguado se a solicitação não irá sobrecarregar a capacidade dos enlaces. Casoa requisição respeite esse dois fatores, é designado um caminho para todo fluxo de dados,consequentemente, se aceita uma nova conexão.

2.1.2.2 Roteamento baseado em restrições

Segundo XIAO (s.d) o roteamento baseado em restrição é o processo de determinaro caminho mais adequado respeitando as restrições de uma conexão. Esses requisitos sãobaseados por diversos parâmetros, tais quais: números de nós intermediários, taxa detransmissão, capacidade do enlaces, confiabilidade, atraso fim-a-fim, variação de atrasofim-a-fim e etc.

Para aplicar essa restrição, deve-se utilizar um protocolo de sinalização. Ele éresponsável pelo levantamento de todos os caminhos possíveis que respeitem as restriçõesdas conexões. Com todos os caminhos possíveis, a engenharia de tráfego seleciona a melhorrota para conexão, a qual almeja atender os objetivos específicos de desempenho desejadospelo provedor de serviço (RESENDE, 2001).

2.1.2.3 Rerroteamento das conexões já estabelecidas

O processo de rerroteamento das conexões acontece quando os pacotes são enca-minhados para outra rota, pois a estabelecida previamente sofreu algum problema. Orerroteamento permite que a engenharia de tráfego tenha a capacidade de resiliência.Segundo Aggelou (2008, apud (VASCONCELOS; SALLES, 2012, p. 597)): "Consideraresiliência como a habilidade de uma entidade de tolerar, resistir e automaticamentese recuperar de mudanças nas condições da rede, ataques coordenados e anomalias notráfego".

Um exemplo de resiliência no rerroteamento é quando ocorre falha no enlace eos pacotes são desviados por outro caminho. Quando o enlace é restabelecido acontecenovamente o rerroteamento de conexões, pois, o enlace reparado irá receber novamentefluxo de pacotes. Outro cenário é quando um enlace começa congestionar, assim, parte dotráfego de pacotes é encaminhado para outra rota.

Outro exemplo de rerroteamento diz respeito ao tratamento de pacotes com priori-dade. Neste caso, o tráfego de baixa prioridade é reencaminhado para uma rota auxiliar,quando este compete pelo mesmo caminho, com um tráfego que possui um nível deprioridade maior.


Entretanto, o rerroteamento das conexões já estabelecidas pode gerar congestiona-mento. Segundo Maia (2006), a engenharia de tráfego deve usar esse método com cautelae periodicamente, porque o rerroteamento gera troca de mensagens entre os elementos darede para selecionar uma nova rota. Caso o rerroteamento fosse considerado instantâneo, asmensagens seriam enviadas em um intervalo de tempo mínimo, como se fosse um fluxo dedados contínuo. Isso pode torná-lo um agente congestionador de tráfego, por sobrecarregara rede com suas mensagens para o restabelecimento.

2.1.3 SLA-Service Level Agreement

O conceito de Service Level Agreement (SLA) é empregado principalmente nocenário de provedor de serviço e cliente. De acordo com Hofmann e Beaumont (2005) nesseambiente há um acordo ou contrato que estabelece o serviço a ser prestado. Este acordo étanto para o provedor de serviço como o cliente. O primeiro só pode garantir os termos doSLA caso o cliente esteja com um tráfego adequado para o serviço estabelecido.

Para a prestação de serviço são acordados parâmetros de serviços, tais como:limitação de largura de banda, atrasos, confiabilidade, perda de dados e disponibilidade(CECHIN, 2008b). Comumente, o processo de elaboração do SLA também é aproveitadopara definir os requisitos de aplicação utilizados pelo QoS.

2.1.4 Exemplo de cenários de engenharia de tráfego

No cenário da Figura 2 existem dois fluxos de dados: um de 40 Mbps e outro de75 Mbps. O tráfego da rede segue as rotas determinadas por meio do protocolo OSPF,que determina rotas de acordo com caminhos de menor custo. Neste cenário o custo édeterminado pela quantidade de nós, assim, quanto maior for à quantidade de nós, maiorserá o custo do caminho. Deste modo, ambos os fluxos passam pelos mesmos caminhos,ou seja, o roteador C está congestionado. Isso acontece porque a necessidade de banda deambos os tráfegos combinada é maior que a capacidade do enlaces.


Figura 2 – Exemplo de cenário sem engenharia de tráfego.

Na Figura 3, é o mesmo cenário, todavia, utiliza-se a técnica de engenharia detráfego. Novamente há os dois fluxos de dados, contudo a distribuição de cada fluxo para omelhor caminho possível. O fluxo de 40 Mbps continua a passar pelo mesmo caminho quena Figura 2, pois, a capacidades dos enlaces desse caminho são de 50 Mbps, suportando anecessidade de banda desse tráfego. O segundo fluxo, precisa de uma largura de banda de75 Mbps, assim o caminho mais adequado é passando pelos roteadores F e E. Os enlacesdestes caminhos suportam até 100 Mbps, suficientes para esse fluxo de dados. O uso datécnica de engenharia de tráfego nesse cenário, não congestiona nenhuns enlaces. Além deaproveitar toda a topologia da rede e os recursos oferecidos por ela.

Figura 3 – Exemplo de cenário com engenharia de tráfego.

Para cenários mais complexos, contendo milhares de fluxos na rede, a engenharia detráfego procura distribuir esses fluxos de dados de melhor modo possível, para que não haja


congestionamento. Caso a quantidade de tráfego seja maior que capacidade de transmissãoda rede, somente os fluxos que possuírem maior prioridade serão encaminhados.

2.2 Multiprotocol Label Switching - MPLS

2.2.1 Histórico

O MPLS é uma tecnologia que realiza comutação de pacotes baseada em rótulospara estabelecer circuitos virtuais Label Switch Path (LSP). Ela surgiu pela necessidadede obter uma tecnologia para rede WAN que melhor se integrasse com redes InternetProtocol (IP), e foi motivada pelas limitações da tecnologia de redes AsynchronousTransfer Mode (ATM).

O ATM é uma tecnologia que surgiu entre 1980 e 1990. O ATM é uma arquiteturade redes e seu principal objetivo na época era transmitir em altas velocidades e ser capazde interligar outras redes com diferentes tecnologias (FOROUZAN, 2009). O modelo detransmissão para a rede ATM se baseou circuitos virtuais, com unidades de transmissãodenominadas células, que são pacotes pequenos de tamanho fixo. O projeto desse tipo derede enfatizou altas taxas de transmissão com baixa latência (HÜMMELGEN; FONSECA,2006), e atendimento de requisitos de QoS para diferentes perfis de tráfego.

Porém, a tecnologia ATM não era facilmente interoperável redes IP. O ATM ébaseado em modelo de conexão e circuitos virtuais enquanto o protocolo IP não é orientadoà conexão, além disso, eles possuíam esquema de endereçamento e alocação de recursosdiferentes (S; FARREL, 2008). Na época essas diferenças eram muito complexas paraserem resolvidas. Não haveria grandes vantagens de utilizar ATM, mesmo com suas altasvelocidades, se não tivesse interoperabilidade com a rede IP. Além do que, o ATM tinha ainconveniência de ser uma tecnologia de alto custo.

Em meados de 1990, várias empresas criaram tecnologias proprietárias com omesmo objetivo: encaminhamento dos dados por etiquetas (rótulo), como alternativaa tecnologia ATM com integração com o protocolo IP. Algumas delas foram: AggregateRoute-Based IP Switching da International Business Machines (IBM), Cell SwitchingRouter da Toshiba e Tag Switching da Cisco, (S; FARREL, 2008).

Como surgimento de diversas tecnologias e com soluções semelhantes à InternetEngineering Task Force (IETF), em abril de 1997, criou um grupo de trabalho paradesenvolver um protocolo para padronizar a comutação de pacotes baseada em rótulos(MENDONÇA JOSE MARIO OLIVEIRA, 2012). Surge então a tecnologia MPLS, aqual, sendo padronizada, possibilita a interoperabilidade entre equipamentos de diferentesfabricantes.

O MPLS é considerado uma tecnologia da camada 2.5 do modelo Open Systems


Interconnection (OSI), ou seja, está entre a camada de enlace e a camada de rede. SegundoMinei e Lucek (2010), o MPLS possui uma série de benefícios, tais quais:

• Agregação de Informação de encaminhamento: um exemplo é o isolamentode VPNs por meio do valor do rótulo;

• Simplicidade de integração: têm a capacidade de adaptar a alterações da topolo-gia, por exemplo: adição ou remoção de nós na rede;

• Distinção de tráfego: capacidade de identificar os diferentes tipos de tráfegos,permitindo que cada um dos tráfegos seja tratado de formas distintas. Isso possibilitao atendimento de requisitos de QoS;

• Maior desempenho: o MPLS permite utilizar outras tecnologias como engenhariade tráfego para evitar congestionamento e redirecionamento rápido em caso de falhade enlace.

2.2.2 Arquitetura

Nesta seção serão explicados os principais componentes da rede MPLS, além deapresentar algumas terminologias. Para maior entendimento na Figura 4, mostra-se umavisão geral dos componentes no domínio MPLS.

Figura 4 – Cenário com componentes do MPLS.

2.2.2.1 PDU- (Professional Development Unit)

Afim de maior compreensão sobre a Professional Development Unit (PDU) doMPLS deve-se relembrar a arquitetura de redes Transmission Control Protocol (TCP)/IP


para compreender a localização exata onde será inserido o valor do rótulo no cabeçalhodo pacote. A Figura 5 mostra todas as camadas do modelo TCP/IP e que a tecnologiaMPLS está entre a camada de rede e a camada física e de enlace.

Figura 5 – Localização do MPLS em relação ao modelo TCP/IP.

A Figura 6 mostra um exemplo de inserção de rótulo entre os cabeçalhos dodatagrama IP (camada de rede) e o quadro Ethernet (camada física e de enlace). Issosignifica que, antes de encapsular um datagrama IIP em um quadro Ethernet, primeiroadiciona-se um cabeçalho MPLS como um prefixo do datagrama. Por fim, o campo typedo cabeçalho Ethernet recebe o valor 8847H para informar que seu conteúdo se refere aum pacote MPLS.

Figura 6 – Encapsulamento do MPLS.

Segundo Rosen (2001), o rótulo MPLS é uma etiqueta de comprimento fixo e curto.É inserido um rótulo ao pacote quando ele entra no domínio MPLS e só é retirado noúltimo roteador do domínio. A seguir há a Figura 7, que representa o formato e os camposcontidos em no rótulo MPLS.


Figura 7 – Campos do frame MPLS.

• rótulo: campo de 20 bits referente ao valor atual do rótulo;

• Classes of Service (CoS)/EXP: campo de 3 bits referente ao enfileiramento e al-goritmos de descarte aplicados ao pacote transmitido. Utilizado para a implementaçãode QoS;

• Stack/S: campo de 1 bit que indica se suporta enfileiramento do rótulo. De acordocom Bassil (2013), quando o bit é zero significa que só tem um rótulo na pilha(stack) ou ele era o último da pilha. Caso o bit for um, representa que há uma pilhade rótulos, que serão roteadas hierarquicamente;

• Time To Live (TTL): campo de 8 bits referente ao tempo de vida do pacote. Acada salto do pacote é decrementado o valor do TTL, se porventura ele ficar em zero,o pacote é descartado. Esse campo evita que os pacotes fiquem em loop na rede.

2.2.2.2 Label Switch Router - LSR

O Label Switch Router (LSR) é um nó localizado no núcleo do domínio MPLS. Eleé um roteador cuja função é comutar/encaminhar pacotes através do rótulo, assim, essecomponente da rede não depende de nenhuma outra informação contida em cabeçalhosdos pacotes (como, por exemplo, endereço IP de destino).

Quando chega o pacote ao LSR, ele lê o valor do rótulo e procura esse valor comoíndice na tabela de encaminhamento. Ela contém duas informações importantes. A primeiraé o novo valor do rótulo do pacote, pois, toda vez que o pacote passa por um LSR, ocorreà troca dos rótulos, conhecidas como Label Swap. A segunda informação é sobre qual é aporta de saída que será encaminhado o pacote, que indica qual é o próximo LSR por ondeo pacote passará, ou seja, o próximo salto (hop).


2.2.2.3 Label Edge Router - LER

O Label Edge Router (LER) é o roteador da borda do domínio MPLS. Ele faza comunicação com os equipamentos de fora da rede MPLS. O LERs são classificadocomo egresso e ingresso. O primeiro é no momento que o pacote sai do domínio MPLS,quando acontece a retirada do rótulo e depois analisa o pacote IP, para encaminhá-loao seu destino. O LER ingresso é quando o pacote entra na nuvem MPLS. Ele avalia ocabeçalho IP, classifica o pacote conforme a sua Forwarding Equivalency Class (FEC),por fim, adiciona o rótulo ao pacote.

2.2.2.4 Forwarding Equivalence Class - FEC

A FEC representa um conjunto de pacotes que possuem o mesmo tratamentoe trafegam pelo mesmo caminho (LSP). O valor da FEC está associado a um rótulo einterface de saída. Segundo Cechin (2008a), a determinação do valor da FEC pode sebasear em uma ou mais informações, dentre elas i) QoS, ii) endereço IP de destino, origemou da rede e iii) número da porta de origem ou destino.

De acordo com Paixão et al. (2007), quando um datagrama entra na rede MPLS, oLER de ingresso verifica a qual FEC o pacote pertence, e adiciona um cabeçalho MPLScom rótulo correspondente à classe de equivalência. Esse é o único momento que o cabeçalhoIP do pacote é analisado, nos demais roteadores da nuvem MPLS é verificado somente orótulo para fins de encaminhamento.

2.2.2.5 Label Information Base - LIB

Os LSRs e LERs precisam de uma base de dados para armazenar todas as infor-mações para ocorrer o encaminhamento dos pacotes baseado pelo rótulo. De acordo comGiladi (2008), a Label Information Base (LIB) é onde ficam as informações necessáriaspara o próximo salto do pacote, ou seja, por qual interface o pacote será encaminhado. Etambém possui informações sobre a operação sobre os rótulos, que são: substituir, adicionarou remover um rótulo.

Na LIB existe a tabela de encaminhamento do roteador. Ela recebe informaçõesatravés do Label Distribution Protocol (LDP), protocolo de distribuição de rótulos, parafazer a associação entre os rótulos e a interface do roteador. Há diversas formas de montaruma LIB, normalmente utiliza-se a tabela do Incoming Label Map (ILM), FEC-To-NHLFE (FTN) e Next Hop Label Forwarding Entry (NHLFE), (GILADI, 2008). Aseguir a Figura 8 mostra a relação entre esses elementos.


Figura 8 – Relação da LIB com as demais tabelas.

2.2.2.6 Next Hop Label Forwarding Entry - NHLFE

O NHLFE representa a saída da LIB. Ele é utilizado quando há o encaminhamentode um pacote rotulado. O NHLFE contém informações importantes para o LSR determinaro LSP por onde encaminhar o pacote.

Segundo Rosen (2001), existem vários dados no NHLFE, mas há dois fundamentais.O primeiro indica o próximo salto do pacote. A segunda informação é sobre qual operaçãoserá realizada, que são: empilhamento (PUSH ), substituição (REPLACE) e remoção (POP)do rótulo que está no topo da pilha de rótulos. Também pode haver dados adicionais,como: tipo de encapsulamento utilizado na transmissão, codificação da pilha de rótulosque a tecnologia utiliza e outra informação caso necessitar. A seguir a Tabela 1 tem umexemplo da tabela NHLFE, com todas as informações que mencionadas anteriormente.

Rótulo de Saída Ação Próximo salto Encapsulamento Codificação40 POP 80.1.0.0/16 SVC16 REPLACE 60.1.0.0/16 SNAP SVC27 PUSH 50.1.0.0/16 SVC

Tabela 1 – Tabela NHLFE (SANTOS et al., 2003).

2.2.2.7 Incoming Label Map - ILM

Para encontrar o índice adequado na NHLFE, precisa de outra tabela. O ILM éuma tabela de encaminhamento de rótulo de entrada, usada somente pelo LSR e LER deegresso. De acordo com DATACOM (s.d), “ o ILM mapeia cada rótulo de entrada a umaNHLFE (conjunto de rotas de rótulos) permitindo a tomada de decisões/ações a seremrealizadas”.


A Tabela 2 apresenta o ILM. Ele tem duas colunas: a primeira é o índice da tabela,neste caso cada índice é um rótulo. Conforme o rótulo de entrada utiliza a segunda coluna,índice NHLFE, para indicar qual é o índice correspondente da tabela NHLFE.

Rótulo de Entrada Índice NHFLE40 816 1127 4

Tabela 2 – Tabela ILM.

2.2.2.8 FEC–to–NHLFE – FTN.

O FTN é semelhante ao ILM, entretanto, é utilizado no LER de ingresso, onde éinserido a rótulo no pacote. Para determinar o valor do rótulo deve-se saber qual FECque o pacote pertence. Então, o FTN mapeia cada FEC para um conjunto de NHLFEs.

A necessidade de possuir vários NHLFEs é para oferecer o balanceamento de cargapara os múltiplos caminhos com o mesmo custo (ROSEN, 2001). Porém, o pacote só podeescolher um único índice NHLFE.

A seguir a Tabela 3, ela específica os parâmetros da tabela do FTN. Ela possuiduas colunas, a direita refere-se ao endereço de destino e da esquerda ao índice da tabelaNHLFE, que corresponde ao índice da tabela NHLFE, onde há as instruções para oencaminhamento do pacote e a inserção do rótulo.

FEC Índice NHFLEFEC1 2FEC2 5FEC3 4FEC2 7

Tabela 3 – Tabela FTN.

2.2.2.9 Label Switched Path - LSP

Segundo Mendonça Jose Mario Oliveira (2012) “um LSP é uma sequência ordenadade LSRs, sendo o primeiro um LER de ingresso e o último um LER de saída”. O LSP éuma abstração similar a um circuito virtual da rede ATM (PÁDUA et al., ). O caminhoestabelecido é sempre unidirecional no sentido de origem ao destino.

Existem duas formas de fazer o estabelecimento do LSP. A primeira é estática, dessaforma todos os roteadores pertencentes à MPLS devem ser configurados manualmente paracada FEC existente. A segunda forma é dinâmica, sendo realizada por meio de protocolosde sinalização usados para descobrir caminhos e negociar valores de rótulos a serem usadosnos enlaces entre os LSR. Exemplos de protocolos usados pra sinalização são Resource


Reservation Protocol (RSVP), OSPF, Border Gateway Protocol (BGP). A negociaçãode rótulos entre roteadores vizinhos diretos usualmente se faz com um protocolo específicoLDP (DATACOM, s.d).

2.2.3 Label Distribution Protocol - LDP

O MPLS apresenta um protocolo específico para a distribuição de rótulos, chamadoLDP. De acordo com Andersson (2007), o LDP é definido como “conjunto de procedimentose mensagens, para a distribuição dos rótulos entre os LSRs para a criação dos LSPs".

O LDP tem como função essencial fazer a descobertas dos pares LSR, para eles seencontrarem e comunicar entre si. Essa comunicação ocorre só com os vizinhos diretos doLSR, deste modo, um LSR não precisa ter em suas tabelas todas as informações sobretodos os roteadores da rede.

No MPLS os rótulos distribuídos pelo LDP são relacionados com as FEC associadasàs subredes dos enlaces de cada roteador. Portanto, o LDP permite o mapeamento depacotes específicos para cada LSP. Isso significa que, conforme a FEC do pacote, haveráum LSP para ele, onde, as informações para estabelecer o LSP foram distribuídas peloLDP.

2.2.3.0.1 Categorias das mensagens LDP

O protocolo LDP possui quatro classes de mensagens, a seguir haverá explicaçõessobre elas conforme (ANDERSSON, 2007):

• Discovery messages: empregada para anunciar e manter um LSR na rede;

• Session messages: utilizadas para iniciar, manter e terminar uma sessão entre osLDP;

• Advertisement messages: para criar, alterar, excluir o mapeamento de rótulosvinculados a uma FEC;

• Notification messages: quando ocorre um erro utiliza as mensagens de Notifica-tion para fazer a sinalização e informar o problema.

Todas as mensagens de LDP utilizam do protocolo TCP, para ter garantia deentrega das mensagens. Exceto as mensagens de DISCOVERY, que são transmitidas viaprotocolo User Datagram Protocol (UDP).

Para ter o conhecimento dos vizinhos LSR, é enviada uma mensagem HELLO,periodicamente para um grupo multicast. Porém, só o LSR vizinho direto responde amensagem Hello. Com isso, inicia o processo de estabelecimento da conexão TCP, para


posteriormente de fato começar a sessão LDP. Essa é sempre bidirecional, para que ambosLSRs possam trocar informações sobre rótulos (MÜLLER et al., 2002). A seguir a Figura9 representa um diagrama de tempo da troca de mensagens do LDP.

Figura 9 – Diagrama de tempo da troca de mensagens do LDP.

2.2.3.1 Empilhamento de rótulos

Um pacote pode carregar mais de um rótulo, ou seja, há o encapsulamento de umpacote MPLS em outro pacote MPLS. Essa associação de rótulo intitula-se de empilhamentode rótulos (stack label). O empilhamento de rótulos é bem simples, cada rótulo que éadicionado é colocado no início da pilha e é o primeiro a ser retirado, first-in first out.Portanto, quando o pacote é analisado no roteador, somente a rótulo de cima da pilha éverificado. Para saber se o pacote possui ou não um empilhamento de rótulos, verifica ocampo S do cabeçalho MPLS, que já foi explicado na seção 2.2.2.1.

O empilhamento de rótulos permite a criação de túneis LSPs e também é usadoem VPNs com MPLS, que será discutida na seção 2.4.2. O túnel LSP simula um enlaceponto-a-ponto, onde pode trafegar um ou mais LSPs no túnel (FARREL; BRYSKIN, 2005).A capacidade de hierarquia dos rótulos permite essa agregação de LSP.

A Figura 14 mostra dois LSPs no roteador LER1, que usam o túnel LSP para oencaminhamento dos seus pacotes. No roteador LSR1, só o rótulo no topo da pilha seráanalisado, que no caso teve seu valor alterado. Já no roteador LSR2 ocorreu a remoçãodo rótulo, então, parte do pacote que estava atribuída a esse rótulo é encaminhado paraLER2. Já o restante do pacote continua ser encaminhado pelo túnel, até chegar ao roteadorLSR4, onde o rótulo é removido e o pacote será entregue ao LER3. Percebe-se que ambosos LSRs, os rótulos foram retirados um salto antes de chegar ao fim do domínio MPLS.Isso acontece, pelo fato que para o rótulo o destino é o LER e não que está fora da nuvem


MPLS, que é o destino final do pacote, por isso, há essa remoção do rótulo.

Figura 10 – Túnel LSP.

2.2.3.2 Funcionamento

Esta seção traz uma visão geral do funcionamento da rede MPLS. A Figura 11representa um cenário de um domínio MPLS, indicando as interfaces de cada roteador.Por meio desse cenário podem-se explicar as etapas de estabelecimento da comunicação emuma rede MPLS, desde a criação das tabelas em roteadores até a transmissão de pacotes.

Figura 11 – Cenário indicando as interfaces.

Primeiramente cada roteador utiliza o protocolo LDP para estabelecer uma sessãocom cada vizinho direto. Essa etapa está representada na Figura 12. Após estabeleceremuma sessão LDP esses pares de roteadores passam a trocar informações sobre seus rótulos,para negociar e concordar no significado dos rótulos que serão encaminhados entre eles(MÜLLER et al., 2002).


Figura 12 – Sessões LDPs.

Depois que rótulos foram negociados e estabelecidos para comunicação entreroteadores vizinhos, é possível transmitir pacotes usando esses rótulos. A Figura 13 mostratodas as tabelas de encaminhamento necessárias nesse cenário. Através dessa figura percebe-se que a LIB é um conjunto de tabelas. No caso dos LERs eles possuem apenas as tabelasFTN e NHLFE, mas, ela também pode possuir a tabela ILM e sua respectiva NHLFE. Éque nesse cenário específico não houve a necessidade de montar essas tabelas. Em relaçãoaos LSRs, a LIB foi constituída pela tabela ILM e sua respectiva NHLFE. Dado que osroteadores do núcleo da rede não precisam tabela FTN.

Figura 13 – Cenário MPLS com suas tabelas de encaminhamento.

A Figura 14 mostra dois pacotes que entraram no domínio MPLS. O primeiro éum pacote que entra no LER1 e saí no LER2. Nesta figura esse pacote irá trafegar pelaLSP1, essa rota foi determinada devido o valor da FEC do pacote. Ao entra no domínio


MPLS, é inserido rótulo 10, o qual foi determinado pela LIB do LER1. Depois esse pacoteé encaminhado pelo LSR1, onde o seu rótulo é trocado para 13 e é encaminhado paraLSR2. Este é o penúltimo salto do pacote na nuvem MPLS, por isso, que houve a remoçãodo rótulo e o pacote é enviado para o LER2. Logo em seguida, o pacote é transmitidopara fora do domínio MPLS, por meio do LER2.

Figura 14 – Transmissão de pacotes no domínio MPLS.

Essa mesma Figura 14 mostra outro pacote que irá atravessar o domínio MPLS.Porém, este entra no LER2 e sai pelo LER1. Conforme a FEC do pacote, o LSP escolhidofoi o 2. Esse pacote entra na nuvem MPLS e recebe o rótulo 04, de acordo com a tabela deencaminhamento do LER2. Ele é enviado ao LSR3, que de acordo com LIB deve ocorrer àremoção do rótulo, uma vez, que este LSR é o penúltimo salto do pacote na nuvem MPLS.Assim, o pacote é encaminhado para fora da rede, através do roteador LER1, que nestecaso, faz o papel do LER de egresso.

2.3 MPLS-TEA vantagem de utilizar MPLS com a engenharia de tráfego, é que o MPLS permite

usufruir da maioria das funcionalidades disponíveis da TE, pelo fato de ser um modelode sobreposição, de forma integrada (AWDUCHE. et al., 1999). Assim, a união das duastecnologias permite estabelecimento de caminhos alternativos, proporciona redundância eevita congestionamento. De acordo com Mendonça Jose Mario Oliveira (2012), o MPLS-TE“pode trazer benefício para todas as tecnologias e/ou aplicações que requerem banda,atraso ou variação dos níveis (jitter)”.

Essa união permite que os recursos de rede sejam mais bem administrados edistribuídos de forma mais eficientes. Deste modo há o mapeamento dos recursos disponíveis


e também o mapeamento dos caminhos redundantes, prevenindo de possíveis gargalos derede.

Segundo Mendonça Jose Mario Oliveira (2012), são listados principais benefíciosreferentes ao MPLS-TE, são eles:

1. O LSP não está vinculado somente a um único caminho pré-estabelecido, se necessitar,outro caminho pode ser definido para o LSP;

2. Possibilita que um fluxo de tráfego tenha garantia e qualidade de serviço;

3. Permite a criação de LSPs "paralelos" para pacotes oriundos da mesma origem epossuem o mesmo destino. A capacidade de LSPs "paralelos" serve para melhorardistribuição dos tráfegos pela topologia da rede;

4. Automatização da gerência de recursos. Quando os LSPs antigos liberam os recursosutilizados por eles, esses são imediatamente alocados para as necessidades dos novosLSPs;

5. Em caso de falha são atribuídos LSPs alternativos (backup) até que o enlace sejarestabelecido.

2.3.1 Estabelecimento de LSP

Existe um conjunto de protocolos de roteamento que atuam em um AutonomousSystem (AS), denominados de Interior Gateway Protocols (IGP). Sua principal função éo intercambio de informação de roteamento entre os nós de um AS. Como exemplo de pro-tocolos IGP podem-se citar : Routing Information Protocol (RIP), OSPF e IntermediateSystem to Intermediate System Protocol (IS–IS).

Tanto o OSPF e o IS–IS são protocolos de estado de enlace, que utilizam umalgoritmo para calcular o menor caminho entre os nós da rede. Nesta seção será explicadoo funcionamento do protocolo OSPF com versão estendida para engenharia de tráfego equal é sua relação com a criação do LDP.

2.3.1.1 Open Shortest Path First - Traffic Engineering - OSPF-TE

O OSPF é um protocolo de estado de enlace que usa as informações da rede paradeterminar o caminho de menor custo de acordo com o algoritmo de Dijkstra (F; ROSS,2010). Cada roteador descobre seus vizinhos e envia em broadcast essas informações paratodos demais roteadores. Assim, todos os nós conhecem os dados dos demais nós e nãosomente dos seus vizinhos diretos.

Outra característica importante do OSPF é a roteamento hierárquico, para provermaior escalabilidade e melhorar a eficiência de roteamento (WARNOCK; NATHOO, 2011).


Então, o AS é divididas em áreas e deve existir a área principal, backbone, denominadaárea 0. Essa se conecta com as demais áreas. O particionamento de áreas serve parasimplificar e minimizar a comunicação. Os roteadores que pertencem à mesma área sóconhecem os roteadores que pertencem a ele e o roteador conectado à área 0. Assim atroca de informações fica mais restrita as áreas e não à rede toda. A seguir, a Figura 15mostra a ideia de particionamento por área.

Figura 15 – Particionamento de áreas pelo OSPF.

O roteador sempre deve avisar para todos outros quando houve mudança dos custosde um enlace, enviado por um pacote Link-State Advertisement (LSA). O peso atribuídoao enlace é inversamente proporcional a sua capacidade. Quando há caminhos com omesmo custo, o OSPF não elege uma única rota para o encaminhamento do tráfego, eledisponibiliza todas as rotas para fornecer uma melhor distribuição dos tráfegos de dados.As atualizações das informações são sempre transmitidas de forma periódica, para garantirexatidão dos dados. Contudo, isso gera de um grande fluxo de dados na rede (F; ROSS,2010).

Ao se estender o OSPF para engenharia de tráfego, tem-se como resultado o OpenShortest Path First - Traffic Engineering (OSPF-TE). De acordo com Tombi (2007) aescolha do caminho mais curto utiliza o Constrained Shortest Path First (CSPF). Essealgoritmo também usa o algoritmo de Dijkstra para fazer o cálculo da rota, porém, observarestrições para a determinação dos caminhos. O CSPF possui a Traffic EngineeringDatabase (TED), que é uma tabela com uma série de informações sobre a topologia darede, tais como: i) as restrições de engenharia de tráfego ii) reservas de largura de bandaiii) interfaces habilitadas para MPLS da área e os enlaces que os conectam (NETIRON,s.d).

Por meio das informações contidas na TED, o CSPF pode fazer o cálculo do menorcusto, que devem respeitar uma série de restrições. Segundo Manayya (2010), as restrições


do CSPF são relacionadas ao atributo do LSP, tais quais:

• Requisitos de largura de banda;

• Limitações de salto do pacote;

• Prioridade;

• Atributos do enlace.

As informações entre os protocolos OSPF e LDP devem ser sincronizadas para nãoexistir erro na tabela de encaminhamento. Por exemplo, se o OSPF anuncia que um nó foiremovido, na tabela de encaminhamento todos os rótulos que estão vinculados a esse nódevem ser retirados.

2.3.1.2 Resource Reservation Protocol - RSVP

Segundo Purificação (2002), o RSVP é um protocolo de sinalização, para alocardinamicamente reservas de recursos. Ele proporciona métodos para reservar recursos como:largura de banda do enlace, espaço no buffer dos equipamentos, entre outros, ao longo detodo caminho entre o destino e origem.

Uma terminologia utilizada em RSVP é a sessão. Ela é definida como um fluxo dedados que contém as mesmas características de recursos e vão para o mesmo destino. Essasessão pode ser tanto multicast ou unicast, mas, o sentido do fluxo é sempre unidirecional.Caso precise reservar recursos em ambas as direções, origem e destino e destino e origem,é necessário duas sessões, pois, são independentes entre si.

2.3.1.2.1 Mensagens

Para estabelecer uma sessão, envia-se uma mensagem para todos os equipamentosutilizados ao longo do caminho, explicitando os recursos solicitados. Contudo, o equipa-mento ao receber essa mensagem não é obrigado aceitar essa sessão, mas, deve enviar aorigem uma mensagem de notificação para avisar que não tem recursos suficientes. A seguirapresentam-se as principais mensagens do RSVP, e sua descrição conforme (BRADENL. ZHANG, 1997):

• Path:Conforme Dotti (2004), a mensagem de Path ao passar pelos roteadoresidentifica tanto o caminho e o fluxo de dados do momento, como também informaa possível necessidade de reserva. Cada roteador no caminho guarda quem foi oroteador anterior, pois, caso haja reserva de recursos ele sabe para quem enviar atéa reserva chegar à fonte;


• Resv: é enviada pelo caminho inverso, isto é, do destino até a origem. O Resv fazefetivamente o pedido de reserva de recursos;

• PathErr : sinaliza erro durante a mensagem Path;

• ResvErr : sinaliza erro durante a mensagem Resv;

• PathTear : quando um roteador do caminho ou da própria origem desiste da reservade recurso. A PathTear é enviada em direção ao destino, cancelando todas as reservas;

• ResvTear : quando um roteador do caminho ou do próprio destino desiste da reservade recurso. A ResvTear é enviada em direção a origem, cancelando todas as reservas.

A seguir temos quatro figuras mostrando alguns cenários de troca de mensagens.A Figura 16 descreve um cenário onde se conseguiu transmitir o fluxo de dados e quemfinaliza a operação é o cliente, origem. Já na Figura 17, é praticamente o mesmo cenário,contudo, quem finaliza o fluxo de dados é o destino. Na Figura 18, há a tentativa de fazera reserva de recursos, mas, o R2 não tem recursos suficiente, logo, ele envia uma mensagemResvErr, para os roteadores até o destino. Por fim, há a Figura 19, na primeira etapa,onde são enviadas as mensagens Paths, ocorre um erro na hora de chegar no R3. Sendoassim, ele envia uma mensagem dele até a origem, informando esse erro.

Figura 16 – Cenário de RSVP com origem finalizando o fluxo de pacotes.

Figura 17 – Cenário de RSVP com destino finalizando o fluxo de pacotes.


Figura 18 – Cenário de RSVP com erro na mensagem ResvErr.

Figura 19 – Cenário de RSVP com erro na mensagem PathErr.

2.3.1.2.2 RSVP–TE com MPLS

O protocolo de sinalização RSVP é responsável por realizar reserva de recursos.Ao estender para Resource Reservation Protocol - Traffic Engineering (RSVP–TE)acrescenta a capacidade desse protocolo realizar a distribuição dos rótulos. Significa que oRSVP–TE é responsável tanto por fazer as reservas de recursos como distribuir os rótulos.A seguir na Figura 20 apresenta um exemplo do funcionando da RSVP–TE. Segundo aInc (2013) a mensagem Path é emitida para realizar os pedidos de reservas, quando elachega ao destino é enviada a mensagem Resv. Ela faz todo o caminho inverso e confere seos roteadores aceitaram os pedidos de reserva. A mensagem de Resv também distribui orótulo, onde ela representa o caminho e as reservas dos recursos da rota. A distribuiçãodos rótulos é a principal funcionalidade do RSVP–TE para MPLS, pois, quando chegauma requisição é difundindo os rótulos para o LSP que será estabelecido.

Figura 20 – Cenário de distribuição dos rótulos com MPLS RSVP–TE. Fonte: (INC, 2013).


2.4 VPN MPLSNesta seção será apresentado o conceito de VPN e como ele interage com a tecnologia

MPLS. Incluindo o protocolo de roteamento BGP e a criação de tabelas virtuais VirtualRouting and Forwarding (VRF).

2.4.1 Virtual Private Network - VPN

VPN é a extensão da rede privadas sobre a infraestrutura da rede publica, normal-mente a Internet (CARDOSO, 2010). No ponto de vista dos usuários da rede privada écomo os seus dispositivos de computação estivessem conectados diretamente. A necessidadede utilizar a tecnologia VPN pode ser explicada pelo seguinte cenário. Empresas distribuí-das geograficamente precisam de um acesso seguro para troca de informações. Contudo, émuito dispendioso para as empresas construir toda infraestrutura de telecomunicações.Para reduzir gastos, utiliza a infraestrutra da rede pública. No entanto, nesse tipo de redeé necessário certificar que os dados da empresa serão mantidos em segurança (S; FARREL,2008).

A tecnologia VPN propõe a solucionar o problema de segurança. De acordo com Fe Ross (2010), "o trafego interdepartamental é criptografado antes de entrar na Internetpública." O uso da VPN em grandes empresas ultrapassa o limite da comunicação entresede e filiais. Também é utilizada para prover acesso remoto aos funcionários que estão emuma rede pública para acessar os recurso e aplicações da empresa.

De acordo com Lemos (2007), para um pacote ser transmitido por uma VPN, elepassa pelo processo de tunelamento, que acontece em três etapas: encapsular, encaminhare desencapsular. A primeira etapa acontece na origem, toda informação do pacote éencapsulada e são inseridas informações extras para auxiliar no roteamento. Depois oprocesso encaminhado, acontece o estabelecimento de um túnel, caminho lógico, por ondeo pacote trafegará pela rede intermediária. Por fim, o desencapsulamento do pacote, que éa entrega efetiva do pacote ao seu destinatário.

A tecnologia VPN atua como uma camada intermediária, em que os dados podemser transportados tanto pela camada de enlace (ex: Layer 2 Tunnelling Protocol (L2TP)e Point-to-Point Tunneling Protocol (PPTP)) quanto pela de rede (ex: Internet ProtocolSecurity (IPSec) e BGP/MPLS). Percebe-se que existem diversas protocolos que podemestar associados à VPN. Este trabalho aborda MPLS, então, somente o BGP/MPLS seráexplicado nas seções seguintes.


2.4.2 MPLS VPN

As tecnologias MPLS e VPN são independentes entre si, ou seja, podem serempregadas em diversos cenários onde serão proveitosas e funcionais. Contudo segundoBoava (2004), ao uni-las surge uma série vantagens, que são:

• Facilitar as operações da rede para os usuários, ao mesmo tempo em que os provedoresde serviços possibilitam escalabilidade;

• Sem restrição a quantidade de endereços em cada VPN;

• O cliente não necessita se preocupar com roteamento entre redes cabe ao provedorde serviços essa responsabilidade;

• O usuário não administra backbone virtual e nem os acessos aos roteadores;

• Sem a necessidade dos provedores de serviços terem infraestrutra para cada VPN;

• Segurança no envio de dados;

• Propicia flexibilidade e escalabilidade para QoS.

MPLS VPN de camada 3 são conhecidas como Virtual Private Routed Network(VPRN). Os usuários utilizam algum protocolo de roteamento, como OSPF ou BGP paracomunicar com os roteadores de borda, ou seja, o LER. Esses roteadores de bordas, queestão conectados a clientes VPNs, precisam de uma tecnologia capaz de montar tabelade encaminhamento específica para cada VPN, conhecida como VRF. E um protocolode roteamento, BGP, para distribuir as informações necessárias para as montagens dastabelas do VRF.

Após todos esses procedimentos, haverá conectividade entre os usuários da mesmaVPN. Quando um cliente deseja comunicar-se com outro, o seu pacote chega ao LER paradescobrir qual VPN ele pertence e sua rota de encaminhamento, toda essa informação éfornecida pelo VRF. Com isso, é atribuído um rótulo para o pacote e ocorre efetivamenteo seu encaminhamento por toda rede MPLS até chegar ao LER de destino (FILHO;MOREIRA, 2016).

2.4.2.1 Border Gateway Protocol - BGP

O BGP é protocolo utilizado para o roteamento entre AS, inter-AS. De acordo como F e Ross (2010), o BGP provê para todos os ASs, as seguintes características:

• Informações de atingibilidade de sub-rede através do ASs vizinhos;

• Os dados de atingibilidade sejam conhecidos por todos os roteadores internos do AS;


• Determinar as melhores rotas para as sub-redes, por meio dos dados de atingibilidadee das políticas dos ASs.

No cenário com MPLS, o BGP é utilizado tanto para fazer a troca de rótulos edeterminar as rotas. A troca de rótulos é utilizada principalmente quando deseja construirVPN.

Criou-se uma versão deste protocolo, o BGP4, para ser empregado junto ao MPLS.Segundo S e Farrel (2008), ele proporciona suporte às diversas famílias de endereços, comoInternet Protocol version 4 (IPv4) e Internet Protocol version 6 (IPv6). A tecnologiaMPLS estabelece um endereço, onde tem o prefixo de rede e um ou mais rótulos. Por meioda codificação dos rótulos e do prefixo, o BGP inicia o processo de divulgação tanto derotas como dos rótulos.

2.4.2.1.1 Sessão BGP

No BGP a troca de informações entre roteadores se dá por uma conexão TCP naporta 179. A conexão TCP entre dois roteadores é denominada de pares BGP. O termosessão BGP é a conexão TCP mais todas as mensagens BGP trocada entre pares BGP.Ela pode ser dividida em duas classes, sessão externa Border Gateway Protocol (eBGP),para pares BGP de ASs diferentes e sessão interna Border Gateway Protocol (iBGP)para redes BGP do mesmo AS. A Figura 21 descreve esse cenário, indicando o que é umAS e os tipos de sessão.

Figura 21 – Cenário do domínio BGP.


2.4.2.1.2 Atributos BGP

Conforme F e Ross (2010) uma rota é o prefixo de um endereço mais os atributosBGPs, assim, pares BGP comunicam suas rotas um para outro. Nesta seção, há explicaçãosobre os principais atributos do BGP, conforme (REKHTER, 2006):

• ORIGIN : específica onde a informação foi gerada;

• AS-PATH : lista de ASs por onde o prefixo foi anunciado;

• NEXT-HOP: é a interface do roteador que cria as AS-PATH ;

• MULTI-EXIT-DISC : determinar a melhor entrada ou saída no cenário de inter-AS (iAS);

• LOCAL-PREF : utilizado para informar a rota de preferência dentro de um AS;

• ATOMIC-AGGREGATE: informa que a rota foi alcançada por meio de agrega-ção;

• AGGREGATOR: indica qual é o número do AS e endereço de IP para incluir anova rota.

2.4.2.1.3 Rotas do BGP

O BGP faz toda a divulgação de rotas entre os roteadores do mesmo AS e entreAS, ou seja, é estabelecido tantos sessões eBGP e iBGP. Ao final de toda distribuição derotas, há casos em que o roteador tem mais de um caminho possível para o mesmo prefixo.Essa circunstância obriga o BGP seguir uma série de regras para estabelecer uma rotafavorita entre as demais.

Quando há várias rotas, o AS utiliza o atributo de preferência para escolher a rota,optando pela que tiver o valor mais alto da preferência. Caso as rotas disponíveis tenhamo mesmo nível de preferência, então, a rota que possui o menor atributo AS-PATH é aescolhida. Se o valor do AS-PATH não desempatar, deve-se eleger a rota que possui oNEXT-HOP mais próximo (REKHTER, 2006).

2.4.2.2 Virtual Routing and Forwarding - VRF

Como mencionado nas seções anteriores o uso da tecnologia VRF é essencial nocenário VPRN. De acordo com Boava (2004), o VRF foi desenvolvido para garantir priva-cidade. Uma solução existente e muito dispendiosa era conectar cada cliente ao um únicoroteador de borda. Surge o VRF, que possibilita separar as tabelas de encaminhamento eroteamento de cada VPN, ou seja, há o isolamento das diferentes VPNs. Isso permite a


sobreposição de endereço, cada VRF pode ter endereços de IP iguais em relação a outraVRF, mas, como existe a separação das informações, não gera complicações.

Afim de, compreender melhor como funciona o VRF há Figura 22. Neste cenárioexistem quatro Custumer Edge Equipament (CE), que são equipamentos fora do domínioMPLS que se conectam ao Provider Edge Equipament (PE), que é o LER de ingressoconectado ao CE. Onde há duas VPNs, representadas pelas cores vermelha e verde, paraidentificar a VPN do CE. Caso não haja nenhuma identificação de VPN, significa que opacote será tratado pela tabela global de roteamento. Quando o CE envia um pacote aoPE, é examinado se pertence a uma VRF, caso sim, verifica sua tabela de encaminhamento.Como a figura mostra, o VRF abstrai as tabelas, é como houvesse um equipamento deroteamento para cada VPN.

Figura 22 – Cenário para explicar o VRF Fonte: (BUBNOV, 2016).

O VRF tem uma tabela de roteamento para cada VPN. O protocolo BGP éresponsável por distribuir as rotas das VPNs pelos demais roteadores da rede. Para auxiliaro BGP na sua função, o VRF possui dois campos:

• Route Distinguisher (RD): serve como identificação para cada VRF. Ele é a combi-nação entre o valor do domínio AS ou endereço IP mais um número de identificaçãoda VPN (MENDONÇA JOSE MARIO OLIVEIRA, 2012);

• route-target: é um campo do VRF que define se suas rotas podem ser exportadaspara outras VRFs e se ele pode aprender (importar) rotas de outras VRFs.

O VRF possui sobreposição de endereços privados, devido a combinação dele como campo RD, cujo valor torna-se único. A união de um endereço IPv4 mais o RD édenominada de VPNv4. Como o protocolo BGP não tem suporte a VPNv4, utiliza-seuma versão especial chamada Multiprotocol–Border Gateway Protocol (MP–BGP), aqual tem a capacidade de distribuir endereçamento VPNv4. Ela também é responsávelpor distribuir as rotas da VRF que serão importadas e exportadas para as outras VRFs.


2.5 MPLS com qualidade de serviçoNesta seção serão introduzidos os conceitos de qualidade de serviços e o seu

funcionamento junto à tecnologia MPLS com expansão a engenharia de tráfego. Indicandoseus benefícios por adotar essa tática.

2.5.1 QoS

A Internet trabalha com o protocolo IP, este utiliza o serviço de melhor esforçopara todos os seus datagramas. Isto é, a Internet tenta entregar o datagrama o mais rápidopossível. Porém, esse serviço possui limitações devido ao atraso fim-a-fim, variação deatraso (jitter) e perda de pacotes, que não podem ser determinadas no serviço de melhoresforço (F; ROSS, 2010). Além disso, as aplicações em tempo real são as que sofrem maiscom esse tipo de serviço, uma vez que essas três características interferem diretamente naqualidade dessas aplicações.

Esse tipo de aplicação precisa receber um nível de qualidade de serviço (QoS).Não significa que haverá garantia que o pacote chegará ao destino no tempo "x", masque há uma grande probabilidade de isso acontecer. O QoS oferece tratamento diferentepara os diversos tipos de tráfegos, de acordo com os requisitos da aplicação. Por exemplo,cada fluxo de pacotes pode reservar uma largura de banda específica para ele. Assim, essetráfego não precisa competir com outros tráfegos pela largura de banda do enlace.

Segundo Forouzan (2009), o QoS procurar alcançar uma certa qualidade de serviçospara os fluxos de pacotes. Utiliza os seguintes parâmetros para atingir seus objetivos:disponibilidade, atraso fim-a-fim, variação de atraso (jitter), taxa de bits e perda depacotes.

A IETF define dois modelos de QoS para a Internet: arquitetura Serviços Integrados(IntServ) e a arquitetura Serviços Diferenciados(Diffserv). O primeiro modelo se baseiana reserva de recursos para cada fluxo de dados. Enquanto a arquitetura Diffserv selecionaos pacotes de acordo com classes já pré-estabelecidas, então, para cada classe há umadeterminada reserva de recursos. Este trabalho se delimitou a estudar somente a arquiteturaDiffserv, devido sua simplicidade, atende todos os requisitos necessários e possui maiorliteratura quando utilizado com MPLS–TE.

2.5.1.1 Mecanismo de QoS

As seções a seguir irão explicar detalhadamente os mecanismo de QoS, usados paratratar pacotes em trânsito com a finalidade de atender requisitos de QoS dos fluxos de rede.Primeiramente será apresentado o mecanismo de classificação emarcação dos pacotes deacordo com os parâmetros determinados. Depois, há o mecanismo de policiamento pararestringir os tráfegos que estão acima da capacidade permitida. Há também a priorização


ordenada à saída de pacotes de acordo com um algum critério. Logo em seguida, serãoexplicadas técnicas para prevenção de congestionamento. Por fim, o mecanismo decondicionamento de tráfego, que limita a taxa de saída dos pacotes.

2.5.1.1.1 Classificação e Marcação

Antes de explicar esses dois mecanismo de QoS, precisa-se do conceito de classede tráfego: um conjunto de fluxos que compartilham determinadas característica. Tantoo processo de classificação como o de marcação ocorre quando um fluxo de dados serátransmitido. Para que esse fluxo possa receber um tratamento especial, ele dever serprimeiramente analisado, para posteriormente identificar qual é sua classificação.

Segundo Mendonça Jose Mario Oliveira (2012), essa categorização pode ser por“porta física, IP de origem, IP de destino, endereço Media Access Control (MAC), portada aplicação, tipo de protocolos e outros critérios.” Após, os pacotes serem classificadoinicia a etapa de marcação. Nela os pacotes receberão uma informação para identificar aclasse a que pertencem. No caso do protocolo IP, essa informação está contida no campodo Differentiated Services Code Point (DSCP) do cabeçalho IP (ou Traffic Class noprotocolo IPv6). Também pode haver marcação no cabeçalho do MPLS, especificamenteno campo CoS.

2.5.1.1.2 Policiamento - Policing

O policiamento é um mecanismo para controlar os tráfegos que estão ultrapassandoos requisitos negociados, ou seja, são os tráfegos que não respeitam o contrato de serviçoSLA (JR, 2012).

Para os tráfegos que não respeitam essas condições, é aplicada uma prioridade menorem relação aos demais. Esse rebaixamento é uma forma de penalidade, que não interrompeo serviço, só prejudica, pois, ele desrespeitou as condições das reservas (MENDONÇAJOSE MARIO OLIVEIRA, 2012).

2.5.1.1.3 Priorização

A etapa de priorização é fundamental para fazer o processo de diferenciaçãodos tráfegos, é nesse momento que se atribui mais ou menos importância aos pacotes.Segundo Santana (2006), "a prioridade pode ser entendida como mecanismos que provêdiferentes tempos de esperas para o processamento da informação". Esse tempo de esperararamente é zero, ideal, uma vez que, o pacote nunca chega ao equipamento de roteamentoe imediatamente é processado e encaminhado. Normalmente nesse cenário ele disputarecursos do equipamento com outros pacotes. E para ser atendido o pacote fica em umafila de espera, onde o tempo de permanência na fila aumenta. A função do mecanismo de


priorização é ordenar o atendimento de acordo com algum critério. A consequência podeser tempos de espera maiores para pacotes de menor prioridade.

Para oferecer a priorização das classes de tráfegos é necessário aplicar disciplinade escalonamento. De acordo com F e Ross (2010) é o modo como "os fluxos de dadossão multiplexados e enfileirados para transmissão nos buffers de saída associados ao enlace."A seguir serão apresentados os três modos de disciplina de escalonamento mais conhecidos,são eles:

• Enfileiramento prioritário: Para cada prioridade existente haverá uma fila, assim,o política de atendimento é baseada na prioridade da fila. A fila que contém os pacotesmarcados com alta prioridade será atendida primeiro, até que ela esteja vazia. Quandonão houver mais nenhum pacote com aquela prioridade serão atendidas as que têmum nível prioridade mais inferior. Um problema desse tipo de tráfego é caso hajaum alto fluxo de pacotes marcados com alta prioridade, eles sempre serão atendidos.Logo os pacotes com menor prioridade nunca serão servidos (MENDONÇA JOSEMARIO OLIVEIRA, 2012). Esse processo é conhecido como morte por inanição(starvation);

• Varredura cíclica. De acordo com F e Ross (2010), ele é semelhante ao enfilei-ramento prioritário em relação que para cada prioridade há uma fila específica.Contudo, o diferencial é a forma que a fila é atendida, o servidor atende um pacotedepois vai para outra fila e atende outro pacote e assim sucessivamente até atendera primeira fila novamente. Essa varredura cíclica permite que o enlace nunca fiqueocioso quando há pacotes na fila;

• Weighted Fair Queuing (WFQ): de acordo com Nabas (2009), “o algoritmoescalona o tráfego prioritário para frente da fila, reduzindo o tempo de resposta.Ao mesmo tempo, compartilha o restante da banda com os outros tipos de fluxode uma forma justa”. O WFQ continua com a estratégia de uma fila para cadaclasse de tráfego e garante uma banda mínima para cada classe. Essa disciplina deescalonamento equaliza as transmissões de forma ponderada e garante uma bandaproporcional para cada classe de tráfego. Logo, todas as classes de tráfego sãoatendidas, assim, não existe o risco de uma fila sofrer inanição. Entretanto, o riscode descarte ainda existe, caso o espaço do buffer esgote, pacotes serão descartado(DATACOM, s.d).

Existem vários modos de implementar disciplina de escalonamento. Cabe o admi-nistrado da rede escolher o que melhor se encaixa ao seu cenário. De acordo com F e Ross(2010), no caso da arquitetura de QoS a disciplina que se melhor encaixa é o WFQ. Pelofato de que o período de permanência na fila dos pacotes de alta priorização seja menor.


E os pacotes de baixa prioridade possuem esse tempo de permanência maior, mas, sãoatendidos, diminuindo a possibilidade de descartados.

2.5.1.1.4 Prevenção de congestionamento - Congestion Avoidance

A prevenção de congestionamento serve para minimizar a chances de ocorrercongestionamento na rede. Quando a rede apresentar os primeiros sinais que haverá umcongestionamento, é aplicado um mecanismo de descarte de pacotes para diminuir ou zerara probabilidade do congestionamento acontecer. Existem dois mecanismos de descarte depacotes, a seguir será detalhado cada um deles.

O primeiro é o Random Early Detection (RED), cujos pacotes a serem descartadossão escolhidos de forma aleatória. Porém a chance de um pacote ser escolhido para serdescartado é proporcional ao tamanho da fila. Existe um limiar para fila, que é o pontode saturação, a partir desse ponto inicia o descarte de pacotes. Conforme a fila extrapolemais esse limiar a chance de ocorrer o descarte fica ainda maior.

Outro mecanismo é o Weighted Random Early Detectionn (WRED), semelhanteao RED, contudo, os pacotes que são descartados também são escolhidos de forma pseudo-aleatória. Significa que a aleatoriedade de escolha está relacionada à prioridade. Pacotes dealta prioridade têm pesos pequenos e de baixa prioridade tem pesos elevados. O WRED,preferencialmente descarte primeiro e mais, os pacotes com peso maior e depois e menosvezes os de menor peso.

2.5.1.1.5 Condicionamento de tráfego –Traffic Shaping

O Condicionamento de tráfego é uma forma de modelagem. Conforme Rochol et al.(2001) é o mecanismos para modificar as características do fluxo de tráfego, assim, essatécnica impede o transbordo das filas, overflow, perdas de pacotes e diminui a latência darede. Significa que o condicionamento de tráfego deve limitar a taxa de saída de pacotesda fila. Existem três técnicas capazes de realizar essa formatação do tráfego.

A primeira é conhecida como balde furado. O seu conceito é bem simples, aintenção é comparar o processo de encaminhamento de pacotes como se fosse um balde. Acapacidade da fila é o balde, a taxa de chegada dos pacotes é como fosse uma torneiraenchendo ele. A ideia de furar o balde no fundo representa a taxa de saída dos pacotesna fila. Então, a velocidade que a água sai pelo furo é sempre constante, independenteda velocidade que enche o balde. Quando o balde transborde, ocorrer descarte de pacote,pois, a velocidade de entrada de pacotes é superior a velocidade de saída. A técnica dobalde furado deixa a velocidade de saída de pacotes sempre constante, mesmo que a taxade pacotes chegando na fila varia (FOROUZAN, 2009).


A segunda é o balde de ficha, neste caso existe um balde que possui fichas. Elassão geradas a cada "x" tempo e o balde tem o limite "y" de fichas. Ou seja, a capacidade dobalde para guardar as fichas representa o tamanho da fila de pacotes que serão encaminhadopara o enlace, já a ficha representa a permissão para transmitir uma certa quantidade detráfego (FERREIRA, 2009). Então quando o pacote chega, ele deve esperar para receberuma ficha. Ao ganhar a ficha, o pacote está liberado para ser transmitido. De acordocom Forouzan (2009) "o balde de fichas permite tráfego em rajadas a uma velocidademáxima regular" enquanto a técnica de balde furado formata o tráfego em rajada parauma velocidade constante.

Por fim há a técnica de balde furado com fichas, como o nome informa é acombinação das duas técnicas anteriores. Primeiramente é aplicado o balde de fichas eposteriormente o balde furado (FOROUZAN, 2009). Assim o tráfego de rajadas é enviadocom uma velocidade máxima constante. Lembrando que a taxa média do balde furadodeve ser superior a velocidade de fichas utilizadas.

2.5.2 MPLS-TE e DiffServ

O MPLS concede conectividade da rede e facilidade o processo de implantação deVPN. Já a engenharia de tráfego é capaz de melhorar o desempenho da rede, através dautilização inteligente e sucinta da rede. Quando aplicadas juntas podem utilizar todasas funções da engenharia de tráfego sobre MPLS, MPLS–TE. No entanto a arquiteturaDiffserv permite classificar os fluxos de dados e com isso oferecer um tratamento diferenci-ado na rede conforme sua classificação. De acordo com Reale et al. (2011) ao combinartodas essa tecnologias, obtêm garantias de QoS mais rigorosas. Uma vez que, os recursossão utilizados de forma mais eficiente, não ha desperdício, consegue atender mais classesdo Diffserv.

Antes de explicar como todas essas tecnologias se interagem, primeiramente seráexplicada a arquitetura Diffserv, pois, as demais tecnologias já foram abordadas ante-riormente. Também será explicado como funcionamento do mapeamento Diffserv paraMPLS. E por fim, a relação da engenharia de tráfego com o Diffserv, MPLS com DiffServ-TE (DS–TE).

2.5.2.1 Arquitetura Diffserv

De acordo com Dias e Catarina (2004) "a arquitetura Diffserv busca dividir o tráfegoem um número limitado de classes, com diferentes níveis de QoS." O grande diferencialda arquitetura Diffserv é sua capacidade de ser escalonado e flexível. A necessidade deser escalonável surgiu pelo fato de existir milhares classes de tráfegos perambulando pelarede. Uma classe de tráfego pode deixar de existir e surgir novas classes, por isso, que acaracterística de flexibilidade é indispensável (F; ROSS, 2010).


Como há um limite para as classes no Diffserv, precisa de um modo de identificarcada uma delas. A IETF propõe a substituir tanto o campo Type of Services (ToS) doIPv4 e Traffic Class do IPv6 para o campo DS do modelo Diffserv (FOROUZAN, 2009). ODS é um campo de oito bits, onde seis bits pertencem ao subcampo DSCP e os demais doisbits estão reservados para aplicações futuras. É por meio do valor do subcampo DSCP queocorre a classificação dos pacotes conhecidos como classificação Behavior Aggregate (BA).Onde os pacotes como o mesmo valor de DSCP são classificados para mesma classe detráfego.

O campo DSCP também é utilizado para definir o comportamento por salto PerHop Behavior (PHB) do pacote. Segundo Gama, Carvalho e Lima (2003) as classes detráfegos que apresentam um comportamento de encaminhamento similar nos vários nós darede, apresentam o mesmo PHB. É por meio do PHB que a arquitetura Diffserv fornecesuas garantias, já que o PHB influencia diretamente no modo como o buffer e a largurade banda serão compartilhado entre as classes de tráfegos (F; ROSS, 2010). No modeloDiffserv foram definido três tipos PHBs, a seguir serão explicados todos eles de acordocom Forouzan (2009):

• DE PHB: é PHB padrão, ou seja, são os tráfegos encaminhados através do serviçode melhor esforço;

• PHB - Expedited Forwarding (PHB–EF): fornece serviços de baixa perda ebaixa latência;

• PHB - Assured Forwarding (PHB–AF): fornece o mais alto grau de garantia,o administrador da rede determina a garantia de serviços, mas, elas não podemexceder a capacidade dos roteadores.

A arquitetura Diffserv funciona do seguinte modo. Quando o pacote chega aum equipamento habilitado para Diffserv, ele será classificado para uma determinadaclasse de tráfego. Depois, haverá marcação do pacote no campo DSCP para os demaisroteadores possam identificar sua classe. Antes, de o tráfego ser encaminhado ele passarápelo mecanismo de condicionamento do tráfego. Ao chegar aos roteadores de núcleo darede, será verificado o valor do campo DSCP e o pacote será transmitido de acordo comPHB atribuído a ele (FOROUZAN, 2009).

2.5.2.1.1 Mapeamento do Diffserv para MPLS

De acordo com Faucheur. et al. (2002), é possível implantar a arquitetura Diffservsobre uma rede MPLS. Ao juntar MPLS com a arquitetura Diffserv surge o problema demapeamento do DSCP e o PHB para os rótulos do MPLS. Segundo Reale et al. (2011)a Request For Comments (RFC) 3270, atribui 3 bits do cabeçalho do MPLS, o campo


E–LSP L-LSPPHB Campo CoS/EXP Pelo rótulo ou pelo campo CoS/EXPSinalização - RSVP/LDP e entre outros

Mapeamento EXP 7−→ PHB : paraconfigurar os rótulos

rótulo 7−→ PHB : sinalizaçãoEXP 7−→ PHB : mapeamentoé conhecido

PHBs por LSP Até 8 Somente 1Quantidade de BAs quepodem ser suportados Até 8 BAs Até mais de 8 BAs

Tabela 4 – Comparação entre L–LSP e E-LSP.

CoS/Exp, para armazenar tanto PHB e DSCP. Se fosse só o valor do PHB já seria osuficiente. Contudo, há a complicações com o DSCP, pois este possui 64 valores (6 bits) ecomo suprimir em apenas 3 bits (oito valores possíveis)?

Para sanar essa pergunta a IETF criou duas soluções possíveis, cabendo aosadministradores da rede escolher a que se melhor adapta ao seu cenário. Em ambas assoluções utilizam o conceito de Diffserv BAs, onde o mesmo BAs possui o mesmo PHB quesão definidos na rede MPLS (REALE et al., 2011). As soluções propostas foram: EXP- Inferred - LSP (E–LSP) e Label-Only-Inferred-LSP (L–LSP), que serão explicadas aseguir, segundo (SAWANT; QADDOUR, 2003).

• E–LSP: o valor do campo CoS/EXP indica os BAs. O valor do rótulo é utilizadopara decisão de roteamento e o campo CoS/EXP serve para determinar o tipo dotratamento do pacote;

• L–LSP: cria-se um LSP para a combinação de uma FEC em BA. O LSR ficaresponsável para enviar o pacote da forma mais adequada, conforme, o valor dorótulo e do campo CoS/EXP codifica a presidência dos pacotes.

A seguir a Tabela 4 descrevendo detalhadamente as diferenças entre esses doistipos de LSPs, de acordo com (SAWANT; QADDOUR, 2003).

2.5.2.2 DiffServ com engenharia de tráfego

Combinar tanto MPLS–TE e arquitetura Diffserv possibilita uma série de vantagens:a otimização de recursos, melhor desempenho da rede e eficiência (LAI; FAUCHEUR,2003). Essa combinação é conhecida como DS–TE. Como mencionado na seção anterior aIETF já propôs modos de transferir as informações do PHB e do DSCP para o cabeçalhoMPLS.

Segundo Ashr (2005) o DS–TE é um mecanismo de alocação de banda paradiferentes classes de tráfegos, que são alocados para vários Class Type (CT)s. A quantidadede CT é limitada. De acordo com Faucheur (2005), o número ideal de CT são oito, onde


CT7 é que possui maior prioridade e CT0 é tratado como serviço de melhor esforço. Paracada CT é reservado os requisitos de banda necessária.

Ao aplicar a arquitetura Diffserv e a engenharia de tráfego, se ganha uma sériede benefícios. De acordo com S e Farrel (2008), o DS–TE possibilita o encaminhamentobaseado em restrição, controle de admissão e restrição de largura de banda para cadaCT. Já para Reale et al. (2011) o requisito de restrição de largura de banda é o maisimportante, pois, o DS–TE acarreta no acompanhamento da quantidade de largura debanda disponível para cada CT, em qualquer momento.

Para reservar a largura de banda exigida pelo CT utiliza o protocolo de sinalizaçãoRSVP–TE, para estabelecer o túnel DS–TE. Ao reservar uma largura de banda, diz quefoi reservada uma subpool, que é apenas uma parte da capacidade total da banda, globalpool (CISCO, s.d). Há casos onde a própria subpool possui o mesmo tamanho da globalsubpool. Existem dois modelos para reservar a largura de banda, são eles:

O modelo Maximum Allocation Model (MAM) possibilita que cada classede serviço aloque uma fração da largura de banda de um túnel. A Figura 23 apresenta alargura de banda total disponível, a qual foi dividida de acordo com as três prioridades:alta, média e baixa. Caso o tráfego da classe não esteja utilizando toda sua capacidade,este modelo não permite o compartilhamento de banda para pacotes de classes diferentes(REALE et al., 2016);

Figura 23 – Reserva de largura de banda com MAM.

O Russian Doll Model (RDM) é o modelo com compartilhamento de banda.A Figura 24 mostra a largura de banda total disponível, em que a classe com maiorprioridade pode usufruir toda capacidade do túnel. Caso a classe de maior prioridade nãoesteja utilizando toda a sua capacidade e um tráfego com uma prioridade menor delaprecise, a classe de alta prioridade cede temporariamente uma porcentagem da capacidadetotal da largura de banda (REALE; NETO; MARTINS, 2011).


Figura 24 – Reserva de largura de banda com RDM.

62

3 Implantação da rede MPLS

Este trabalho propôs implantar engenharia de tráfego baseada em MPLS–TE emuma rede WAN. A engenharia de tráfego se destina a melhorar o aproveitamento dosrecursos da rede. Para isso, implementou-se um cenário protótipo que representa umarede WAN, e nesse cenário as técnicas de engenharia de tráfego e MPLS foram aplicadase avaliadas. Mais especificamente, seu propósito foi verificar se as técnicas de engenhariade tráfego foram suficientes para solucionar os problemas de subutilização da rede evulnerabilidade à falha de enlace.

A tecnologia MPLS permite redirecionar o tráfego caso ocorra falha e simplifica oprocesso de virtualização do enlace. Ademais, isso abre as portas para outras melhorias. Aengenharia de tráfego proporciona a distribuição dos fluxos de pacotes entre os possíveiscaminhos na rede, evitando congestionamento em certos enlaces e ociosidade em outros.

Além da engenharia de tráfego, o MPLS–TE possibilita atender requisitos de QoS,com objetivo de diferenciar e priorizar certos tipos de tráfegos. Entre os dois modelos dearquitetura de QoS, neste trabalho investigou-se o modelo Diffserv. Sua escolha se deveu àmaior literatura disponível, simplicidade e atender todos os requisitos necessários, quandoassociado à engenharia de tráfego.

Neste capítulo são apresentados protocolos e tecnologias utilizados para imple-mentação de MPLS–TE em rede WAN, incluindo uma explicação detalhada sobre seufuncionamento.

3.1 Cenário de simulaçãoO presente trabalho se propôs a implantar na rede WAN o MPLS–TE. A Figura

25 mostra a topologia de rede utilizada neste estudo, e a Tabela 5 detalha as interfaces dosroteadores e seus respectivos endereços. Essa rede foi inspirada na rede de telecomunicaçõesda empresa Eletrosul. Porém, a rede da empresa possui em torno 40 nós em toda suaextensão. Para simplificar os testes e a implantação da rede, foi escolhida uma parte darede referente ao litoral da região Sul como modelo. A topologia adotada só difere em umúnico roteador em relação à da Eletrosul. O roteador R18 foi adicionado à rede, com afinalidade de ter mais rotas alternativas entre os clientes, caso, ocorresse uma falha deenlace. Essa adição do roteador R18 só aconteceu nos experimentos para verificar o requisitode recuperação de perda da conectividade. Por isso que na seção 3.3.1, balanceamento decarga, o roteador R18 não está presente.

Capítulo 3. Implantação da rede MPLS 63

Figura 25 – Topologia base para simulação dos ambientes.

Equipamento FastEthenet1/0

FastEthenet1/1

FastEthenet2/0

FastEthenet2/1

FastEthenet3/0 Ethernet0 Loopback

R11 192.168.90.1 192.168.98.1 192.168.99.1 10.0.83.2 - - 192.168.0.1R12 192.168.90.2 192.168.91.2 192.168.92.2 - - - 192.168.0.2R13 - 192.168.91.3 192.168.94.3 - - - 192.168.0.3R14 192.168.93.4 - 192.168.92.4 - - - 192.168.0.4R15 192.168.93.5 192.168.95.5 192.168.96.5 192.168.100.5 10.0.82.2 - 192.168.0.5R16 - 192.168.95.6 192.168.94.6 10.0.84.2 - - 192.168.0.6R17 - 192.168.98.7 192.168.96.7 10.0.81.2 - - 192.168.0.7R18 - - 192.168.99.8 192.168.100.8 - 192.168.0.8

Cliente01 - - - - - 10.0.81.1 200.1.0.1Cliente02 - - - - - 10.0.82.1 200.2.0.2Cliente03 - 10.0.83.1 200.2.0.3Cliente04 - - - - - 10.0.84.1 200.1.0.4

Tabela 5 – Endereços dos equipamentos.

Para simular a rede MPLS–TE utilizou-se o software GNS3, com roteadores Cisco dasérie 7200. O GNS3 é um software capaz de simular infraestrutura de rede telecomunicaçõesde maneira simples, rápida, sem restrição de tamanho e nem a necessidade de hardware(GNS3, s.d). Já para os clientes usou-se o programa de virtualização VirtualBox, que écapaz de comunicar com o GNS3. Isso possibilita a criação de infraestrutura de rede quecombina roteadores, switches e computadores.

Na infraestrutura da rede de simulada, todos os roteadores possuem as mesmas


características para todos os enlaces. A seguir serão apresentados os aspectos mais relevantesdos enlaces dos roteadores da série 7200, são elas:

• Capacidade de transmissão: FastEthernet (100Mb)/s;

• Full duplex;

• Maximum Transmission Unit (MTU): 1500 bytes;

• Largura de banda: 100 Gbit/sec;

• Atraso de propagação por enlace: 100 microssegundos.

3.2 Configuração inicial do MPLSO primeiro passo deste trabalho foi implantar a infraestrutura de rede. Isso implica

efetuar as conexões entre os roteadores e também entre os clientes. Uma vez definidos osenlaces, passou-se à etapa de configuração dos roteadores. Para cada interface de saídado roteador deve ser atribuído um endereço IP e uma máscara (isso vale também para ainterface de Loopback).

Com o endereçamento de todas as interfaces, iniciou-se o processo de introduzira tecnologia MPLS para os roteadores que farão parte do domínio MPLS. Ela deve serhabilitada em todas as interfaces de um roteador, as quais devem se comunicar usandoMPLS. No caso da Figura 25 todas as interfaces foram habilitadas para transmitir pacotesMPLS, exceto as que estavam conectadas aos clientes. Essas interfaces não faziam partedo domínio MPLS. A caixa de texto a seguir mostra o comando utilizado na interface doroteador Cisco série 7200 para habilitar MPLS. Para mais detalhes sobre cada comandode configuração, na seção C com as explicações de todos os comandos utilizados.

interface FastEthernet1/0mpls ip

Uma vez estando os roteadores conectados para formar uma topologia de rede,deve-se usar um protocolo IGP para computar todas as rotas dentro da rede WAN. Umavez determinadas essas rotas, deve-se usar o protocolo LDP para que cada roteador possaestabelecer um LSP para cada destino. Como o LDP deve ser habilitado para todas asinterfaces dos roteadores que fazem comutação por rótulos, para acioná-lo basta configurarcomo comando global. A caixa de texto a seguir apresentada contém o comando parahabitar o LDP.


mpls label protocol ldp

Como apresentado na seção 2.3.1, existem várias opções do protocolo IGP. Nestetrabalho optou-se pelo OSPF, por que oferece roteamento hierárquico, rápida convergênciae pode ser aplicado com engenharia de tráfego. Uma prática adotada nesse tipo de cenáriodo MPLS com OSPF é o particionamento da infraestrutura da rede em áreas. A Figura26 exibe esse particionamento no cenário protótipo. Como a região principal é domínioMPLS, essa recebeu o valor área 0, que representa o backbone da rede. Já para cada clientefoi atribuído uma área diferente.

Figura 26 – Cenário protótipo com o particionamento de áreas pelo OSPF.

O OSPF foi utilizado para distribuir informações sobre o estado da rede, principal-mente sobre as condições dos nós da rede e suas respectivas interfaces. Se houver algumaalteração nessa topologia, o OSPF é responsável por atualizar essas informações. Comoo OSPF distribui as informações sobre a infraestrutura da rede, ele utiliza o CSPF paracalcular o caminho de menor custo. As informações sobre quais são os custos do enlaces éfornecida para LIB.

O LDP só pode inserir o rótulo na tabela de encaminhamento, se as informaçõesde encaminhamento associadas a um rótulo (endereço da rede, máscara e o próximosalto) forem as mesmas contidas na tabela do OSPF. Significa que ambos os protocolosos precisam que suas informações estejam sincronizadas, para não ocorrer problema natabela de encaminhamento do nó.


A caixa de texto a seguir, apresenta a tabela de encaminhamento do roteadorR18. Ela apresenta as seguintes informações: rótulo de entrada, rótulo de saída, destino,interface de saída e próximo salto. A tabela de encaminhamento funciona no seguintemodo. O pacote chega ao roteador, é analisado o valor do seu rótulo, para saber qualíndice da tabela de encaminhamento o pacote pertence. Através do índice, sabe qual seráa operação que irá ocorrer no rótulo (adição, remoção (POP) ou troca) e qual é o destinodo pacote. Então, o pacote é encaminhado para o próximo salto por meio de uma interfaceespecífica.

Roteador18: show mpls forwarding-tableLocal Outgoing Prefix Bytes Label Outgoing Next HopLabel Label or Tunnel Id Switched interface18 17 192.168.0.6/32 0 Fa2/0 192.168.99.120 19 192.168.0.4/32 0 Fa2/0 192.168.99.121 20 192.168.0.3/32 0 Fa2/0 192.168.99.122 21 192.168.0.2/32 0 Fa2/0 192.168.99.123 Pop Label 192.168.0.1/32 0 Fa2/0 192.168.99.124 Pop Label 192.168.98.0/24 0 Fa2/0 192.168.99.125 22 192.168.96.0/24 0 Fa2/0 192.168.99.126 23 192.168.95.0/24 0 Fa2/0 192.168.99.127 24 192.168.94.0/24 0 Fa2/0 192.168.99.128 Pop Label 192.168.90.0/24 0 Fa2/0 192.168.99.129 27 192.168.91.0/24 0 Fa2/0 192.168.99.130 28 192.168.92.0/24 0 Fa2/0 192.168.99.131 25 192.168.93.0/24 0 Fa2/0 192.168.99.132 29 192.168.0.7/32 0 Fa2/0 192.168.99.1

3.3 MPLS com engenharia de tráfegoEngenharia de tráfego é usada para melhor alocar os recursos da rede e balancear

o tráfego, com o objetivo de evitar a subutilização dos enlaces da rede. Para aplicarengenharia de tráfego nessa rede, utilizou-se a técnica de túneis MPLS. De acordo comHeadquarters (2010), uma abordagem para engenharia de tráfego é construir uma malhade túneis entre os roteadores de borda, partindo de cada LER de ingresso para cada LERde egresso. A ideia é definir não só um único túnel para cada equipamento de borda dodomínio MPLS, e sim vários túneis para esse mesmo destino, variando parâmetros como


prioridade e largura de banda. A vantagem de construir a malha de túneis é balancear ostráfegos pela rede, por meio desses diversos túneis.

Os túneis são criados nos LERs e são unidirecionais. A caixa de texto abaixomostra a configuração de um túnel no roteador R11. O parâmetro (path-option) específicacomo será definido o caminho do túnel, que pode ser tanto explicito como dinâmico.Túneis explícitos são criados a partir de rotas definidas totalmente ou parcialmente pelooperador. Quando são configurados totalmente são determinados todos os saltos do túnel.A configuração parcial indica quais são os roteadores que irão participar da rota. Porexemplo, ao construir um túnel entre o roteador R11 para o R16, pode-se definir naconfiguração parcial que o roteador R14 é obrigatório estar na rota do túnel. Pode havertambém o caso de exclusão, em que se proíbe a participação do roteador R14.

interface Tunnel302ip unnumbered Loopback0tunnel destination 192.168.0.5tunnel mode mpls traffic-engtunnel mpls traffic-eng autoroute announcetunnel mpls traffic-eng priority 0 0tunnel mpls traffic-eng bandwidth 2000tunnel mpls traffic-eng path-option 1 dynamic

Túneis dinâmicos são definidos com base nas informações coletadas pelo OSPF-TE.A partir disso o algoritmo CSPF calcula as possíveis rotas que atendem os requisitos dotúnel, e escolhe a que possui o menor custo. Durante o trabalho percebeu-se que, ao subirum LER e seus respectivos túneis, o CSPF escolheu o caminho de menor custo. Porém,se fossem inseridos outros equipamentos na rede e o melhor caminho deixa ser aquelepreviamente determinado, todas as rotas seriam recalculadas de forma a determinar oscustos dos novos caminhos. Esse processo era desencadeado após uma hora, devido aotempo de atualização definido para o protocolo OSPF.

Como o túnel possui restrições, principalmente em relação à reserva de largura debanda, é necessário negociar essas reservas antes que inicie o tráfego de pacotes pelo túnel.Nesse ambiente, o protocolo RSVP–TE realiza essa tarefa, pois, ele é empregado paraefetuar reservas de recursos. Ele faz todas as trocas de mensagens entre todos os roteadoresestabelecidos pela rota do túnel, para fazer a reserva da largura de banda requisitada porele. Caso não haja capacidade suficiente para aquele túnel, começa novamente o processoem busca do caminho de menor custo com as reservas necessárias. Quando ele é utilizado


no modo de engenharia de tráfego, ocorre também a distribuição dos rótulos dos túneis. OLDP continua com a distribuição dos rótulos para os vizinhos diretos, mas, o RSVP–TEdistribui os rótulos que serão utilizados pelo túnel. Essa distribuição só ocorre após o CSPFescolher o caminho de menor custo. Então, o RSVP–TE inicia o processo de verificaçãode reserva de recursos nos roteadores. Como visto na seção 2.3.1.2.2, caso haja recursossuficientes, o RSVP–TE irá alocá-los e ao mesmo tempo distribui os rótulos que identificamo túnel, ou seja, o RSVP–TE estabelece um LSP para o túnel.

A caixa de texto abaixo mostra o relatório de um túnel, cuja origem é o roteadorR11 e o destino R15. Todas as propriedades mais relevantes estão destacadas em azul. Aprimeira informação é sobre o requisito de largura de banda do túnel (2000 kbps) e o nívelde prioridade (0). A segunda é o valor do rótulo de saída (31) e qual será a interface parao encaminhamento do pacote (FastEthernet2/0). Outra informação relevante no relatórioé o caminho do túnel, onde são especificados todos os seus endereços. Nesse exemplo, otúnel passa pelos seguintes roteadores: R11 → R17 → R15. Por fim, tem o número deidentificação do LSP apropriado para essa rota.


Roteador11>show mpls traffic-eng tunnelsP2P TUNNELS/LSPs:

Status:Admin: up Oper: up Path: valid Signalling: connectedpath option 1, type dynamic (Basis for Setup, path weight 2)

Config Parameters:Bandwidth: 2000 kbps (Global) Priority: 0 0 Affinity: 0x0/0xFFFFMetric Type: TE (default)AutoRoute: enabled LockDown: disabled Loadshare: 2000 [1000000] bw-basedauto-bw: disabled

Active Path Option Parameters:State: dynamic path option 1 is activeBandwidthOverride: disabled LockDown: disabled Verbatim: disabled

InLabel : -OutLabel : FastEthernet2/0, 31Next Hop : 192.168.99.8RSVP Signalling Info:

RSVP Path Info:My Address: 192.168.99.1Explicit Route: 192.168.98.7 192.168.96.5 192.168.0.5Record Route: NONETspec: ave rate=2000 kbits, burst=1000 bytes, peak rate=2000 kbits

RSVP Resv Info:Record Route: NONEFspec: ave rate=2000 kbits, burst=1000 bytes, peak rate=2000 kbits

History:Tunnel:Time since created: 10 minutes, 20 secondsTime since path change: 5 minutes, 39 seconds

Current LSP: [ID: 9]Uptime: 5 minutes, 39 seconds


3.3.1 Balanceamento de carga

Um túnel MPLS possui três características: destino, prioridade e largura de banda.Essa última está vinculada ao RSVP no seguinte modo. Cada interface indica qual é alargura de banda máxima que o protocolo RSVP pode reservar. Assim, todos os túneisestabelecidos só podem reservar até essa quantidade que foi delimitada na interface. Aseguir há a configuração do RSVP para a interface, a Tabela 20 contém a explicaçãodetalhada de todos esses comandos.

interface FastEthernet1/0ip rsvp bandwidth 4000 4000

O protocolo RSVP–TE, ao realizar as reservas dos túneis, verifica se cada interfacetem largura de banda disponível suficiente em relação aquela que a própria interfacedisponibilizou para o RSVP. No decorrer dessa etapa de verificação do comportamentodos túneis reservou-se para todas as interfaces da rede a mesma largura de banda de 110kbps. Em todos os testes realizados foram configurados três túneis que possuíam a mesmaorigem e destino. Para essas avaliações, utilizou-se a topologia de acordo com a Figura 27,percebesse que o roteador R18 não está presente, pois, nesse momento não havia surgido ànecessidade de adicioná-lo. Os túneis foram todos entre o roteador R11 com destino aoR15. Os resultados apresentados a seguir foram obtidos depois de repetidas execuções doexperimento.

Figura 27 – Cenário para os teste de balanceamento de carga.

O primeiro requisito que foi averiguado era ter três túneis cuja soma das suaslarguras de banda eram inferior à capacidade máxima da largura de banda reservada paracada interface. A seguir a Tabela 6 contém todos esses resultados. Percebe-se que todos ostúneis utilizaram o mesmo caminho. Nesse teste específico, todos os túneis requisitaram


30 kbps e definiu que a capacidade de reserva de largura de banda das interfaces eram 110kbps, logo sobravam ainda 20 kbps, por isso, que todos eles foram para o mesmo caminho.

Tunel Prioridade Largura de Banda RotaTunel01 6 30 R11 7−→ R15Tunel02 3 30 R11 7−→ R15Tunel03 0 30 R11 7−→ R15

Tabela 6 – Teste01: túneis com a mesma largura de banda.

Depois foi realizado outro teste, para verificar se, caso a soma de todas as largurasde banda for superior aos da interface, haveria o balanceamento do tráfego. De acordocom a Tabela 7, percebe-se que isso de fato ocorreu. Nesse mesmo teste verificou-se ocomportamento da característica de prioridade. Quanto mais baixa for a prioridade dotúnel, maior é sua precedência. Essa característica não envolve em escolher o caminhocom menor custo, mas, se houver dois túneis disputando o mesmo caminho o que possuirmaior precedência vence a disputa (FALSARELLA, 2008).

Tunel Prioridade Largura de Banda RotaTunel01 6 100 kbps R11 7−→ R12 7−→ R14 7−→ R15Tunel02 0 100 kbps R11 7−→ R15Tunel03 0 60 kbps R11 7−→ R17 7−→ R15

Tabela 7 – Teste02: distribuição de túneis.

Para compreender melhor o requisito de prioridade foi elaborado o seguinte teste,cujas características principais e os resultados estão apresentados na Tabela 8. Criaram-sedois túneis com os mesmos requisitos de banda (100 kbps) e o destino (Roteador R15),porém, um com prioridades diferentes, o Tunel01 tinha prioridade zero e do Tunel02 eraseis. Para conferir que o túnel de maior prioridade (Tunel01) foi de fato estabelecido, foireduzida a largura de banda reservada por interface para 50 kbps, exceto a interface que seconecta ao roteador R17, a qual continuou com 110 kbps. Logo, há somente um caminhopossível, mas existe apenas largura de banda suficiente para um único túnel. Então, oúnico túnel que foi construído foi o Tunel01, por possuir maior prioridade. O Tunel02estava invalido, pois o RSVP não conseguiu reserva de largura de banda suficiente.

Tunel Prioridade Largura de Banda RotaTunel01 6 100 R11 7−→ R17 7−→ R15Tunel02 0 100 Inválido

Tabela 8 – Teste03: túneis com prioridades diferente e um único caminho disponível.


3.3.2 Recuperação de perda da conectividade

A funcionalidade de recuperação de perda de conectividade é oferecida pelo MPLS.No decorrer desse trabalho foi testado se uma rede MPLS sem engenharia de tráfegoera capaz de recuperar conectividade. Através de experimentos, verificou-se que o MPLSredireciona o fluxo de dados em menos de um minuto para outro caminho em caso de falha.Todavia, foram realizados outros testes sobre recuperação de conectividade utilizandoMPLS–TE, para compreender como o túnel da engenharia de tráfego restabelece suasrotas em caso de falha na rede.

Após a implementação do MPLS–TE, foi avaliada a manutenção de conectividadeda rede por meio dos túneis. Foi nessa etapa que acrescentou o roteador R18 a rede, pois,desejava possuir dois caminhos com os mesmos custos. No teste foi transmitido um fluxode dados entre o Cliente03 e o Cliente02, e o túnel estabelecido para esse fluxo eraentre o R11 7−→ R18 7−→ R15. Então, desligou-se o roteador R18, e demorou menosde um minuto para a rede restabelecer o caminho e passar o tráfego pelos roteadoresR11 7−→ R17 7−→ R15. A nova rota escolhida era o caminho com menor custo. A seguir aFigura 28 mostra a rota estabelecida antes do desligamento do roteador R18 (setas azuis)e a nova rota escolhida (setas verdes).

Figura 28 – Cenário com desligamento do roteador R18.

Ao ligar novamente o roteador R18, após uma hora em relação a remoção doroteador R18, era recalculado à rota do túnel e o caminho escolhido novamente seriaR11 7−→ R18 7−→ R15. Contudo o caminho que passa pelo roteador R17 tem o mesmo


custo, logo não aconteceu à volta para o caminho original. Para averiguar se realmentevoltava para o melhor caminho, realizou-se o mesmo teste. Porém, retirou-se o roteadorR18, assim o túnel escolheu a rota R11 7−→ R17 7−→ R15. Então desligou-se o roteadorR17, e por volta de 1 minuto, estabeleceu a rota por: R11 7−→ R12 7−→ R14 7−→ R15.Ligou o roteador R17, após uma hora do desligamento de R17, a rede recalculou caminhode menor custo para o túnel, que era o caminho original (R11 7−→ R17 7−→ R15). AFigura 29 ilustra esse processo.

Figura 29 – Cenário com desligamento do roteador R17.

Esse tempo para estabelecer uma nova rota é devido à troca de mensagens queocorre na rede para identificar um problema e estabelecer uma nova topologia. O OSPFpercebe que houve uma alteração na topologia da rede, e começa enviar mensagens a todosos roteadores, avisando que ocorreu essa alteração. Com essas novas informações o CSPFrefaz os cálculos dos caminhos dos menores custos. Logo, se havia um túnel que passassepor essa falha, ele será restabelecido para outro caminho. Antes de começar a enviar osdados pelo novo túnel, o RSVP–TE verifica se há largura de banda suficiente para essetúnel. Caso exista, a reserva de capacidade é efetuada e o túnel é estabelecido.

Durante a execução do trabalho desejou-se investigar a tecnologia Fast Reroute(FRR). De acordo com Ghein (2007) ela diminui o tempo de recuperação de conectividade,em relação MPLS–TE. Teoricamente esse tempo de recuperação deveria ser menor que 50ms. Contudo, a tentativa de implantar essa tecnologia na rede não alterou o tempo derecuperação da rede.


3.4 VPNUm dos objetivos principais desse trabalho é facilitar o processo de virtualização da

camada de enlace. No momento que unimos MPLS com VPN, alcançamos esse objetivo.Como explicado na seção 2.4.2, existe uma série de vantagens quando isso acontece. Porém,a principal é isolar os tráfegos entre os clientes de forma simples. Para fazer tudo isso,basta o administrador configurar os PEs . Caso acrescente mais um novo integrante daVPN, só precisa ir aos PEs que participam dessa VPN específica e acrescentar algumasconfigurações. Em nenhum momento é necessário configurar o cliente e nem os roteadoresde núcleo da VPN.

Para introduzir à VPN a infraestrutura da rede baseada em MPLS, precisou-se deum protocolo de roteamento inter domínios, BGP, e da tecnologia VRF. Como um dosobjetivos do trabalho é que os clientes não possam se comunicar com determinados clientesadotou-se o modelo VPN peer–to–peer. Segundo Rosen (2006), nesse modelo as rotas deVPNs diferentes permanecem distintas e separadas. Assim os mesmos endereços privadospodem ser usados por diferentes clientes, uma vez que pertencem a diferentes VPN.

Com o modelo peer-to-peer, todas as informações da VPN estão contidas no PE,onde é construída a tabela de encaminhamento da VPN pelo VRF. Os PEs são os únicosque possuem configuração das VPNs, quando aplicado com MPLS. Para cada clienteconectado a ele, é criada uma tabela de roteamento independente, ou seja, associa-se ocliente a uma VPN específica. Essa separação das tabelas é responsabilidade da tecnologiaVRF.

As informações contidas nas tabelas são distribuídas entre os PEs, por meio do BGP.Nesse contexto utiliza-se o BGP com sua extensão para MPLS, MP–BGP. De acordo comBoava (2004), ele "é um protocolo usado para distribuir rotas das VPNs entre os roteadoresPEs" e também permite utilizar o VPNv4 como informação de roteamento. Então, astrocas de informações entre os PEs da mesma VPNs se dão por meio do MP–BGP. Eumas das informações trocadas entre eles é valor do rótulo da VPN. Deve-se observar queo rótulo da VPN não é modificado ao trafegar pela rede.

O pacote ao ser transmitido por meio de um VPN recebe dois rótulos, os quais sãoempilhados. O mais externo é referente ao caminho LSP do pacote. Já segundo é o própriorótulo da VPN, que é anunciado pelo MP–BGP de PE para PEs. O valor desse rótulo ésempre o mesmo no decorrer de todo o caminho, pois ele está na base da pilha de rótulos.Logo, não ocorre a troca de valor de seu rótulo durante o encaminhamento do pacote.

Porém, ao usar VPN, a informação de roteamento não restringe ao domínio MPLS,pois, o pacote precisa chegar até o cliente, e essa informação de qual é o cliente estáindicada pelo rótulo que foi distribuído pelo MP–BGP. Logo, o penúltimo salto do pacoteé o PE de destino do pacote. Neste momento ocorre a retirada do rótulo associado à VPN


e o pacote é encaminhado ao seu destino (cliente).

A seguir, a Figura 30 mostra todo o percurso do pacote que está vinculado a VPN,especialmente em relação às ações que acontecem sobre os rótulos. Quando o pacote entrano domínio MPLS ele recebe dois rótulos. O segundo, cujo valor é 30, está vinculado aVPN. Já o rótulo que está no topo da pilha, será analisado para o encaminhamento dopacote. Quando ele é removido no roteador R14, quem fica no topo da pilha é o rótulo 30.Ele será analisado e enviado para seu PE destino, onde o rótulo será removido e depoisencaminhado efetivamente para o destino do pacote (Cliente02).

Figura 30 – Empilhamento de rótulos por causa da VPN.

3.5 QoSNeste trabalho adotou-se a arquitetura Diffserv, onde o tráfego é dividido em

classes para entregar a estas certo nível de garantia QoS. No decorrer desse trabalhoutilizaram-se mecanismos de QoS para implementar o modelo Diffserv. A Figura 31 mostraesses mecanismos, e identifica a ordem que eles são executados.


Figura 31 – Diagrama dos mecanismos de QoS para arquitetura Diffserv.

A primeira etapa que um pacote passa em um domínio Diffserv é a classificação.Nesta ocorre à identificação dos tráfegos no LER de ingresso, conforme um critério qualquer.A classificação do tráfego utiliza diversos atributos, tais como: valor do campo DSCP,grupo de acesso, campo o CoS/EXP do rótulo, protocolo, endereço IP de destino, interfacede entrada, precedência do IP e Virtual Local Area Vetwork (VLAN). Deste modo, cadaclasse pode ser definida por um desses atributos ou conjunto deles, ou se apresenta unsdos requisitos. Caso o pacote não pertença a nenhuma classe, ele pode ser encaminhadopela rede como serviço de melhor esforço.

Depois da classificação acontece o policiamento de tráfego. Nessa etapa verifica se ofluxo está de acordo com o SLA definido para ele. O policiamento limita a largura de bandapara cada classe de tráfego, e caso o fluxo não esteja nessa conformidade, ele pode serdescartado ou penalizado. Conforme, as ações que acontecerem no policiamento, o pacoterecebe um valor diferente na etapa de marcação. A marcação corresponde à associaçãode um identificador de classe ao cabeçalho do pacote. Se o fluxo está nos conformes elerecebe um valor determinado no campo CoS/EXP do rótulo. Caso contrário, o tráfego quefoi penalizado, o pacote é marcado com um valor no campo CoS/EXP, cuja prioridade émenor em relação ao pacote que não foi.

Na sequência, os pacotes são colocados em uma fila de saída de acordo com suaclasse de serviço. Os pacotes ficam esperando no buffer da fila para serem encaminhados.É nesse momento que acontece o mecanismo de priorização, onde as filas cujos pacotestêm alta prioridade serão atendidos primeiro. Cabe ao administrador da rede escolherqual disciplina de escalonamento de filas mais adequada para sua rede. Caso haja risco decongestionamento, o mecanismo de prevenção de congestionamento entra em ação, parainiciar o descarte de pacote. Novamente fica por responsabilidade do administrador darede escolher qual mecanismo de descarte é mais apropriado, se RED ou WRED. Por fim,o último mecanismo, o condicionamento de tráfego, que limita a taxa de saída dos pacotespara cada classe.

A seguir são apresentadas duas caixas de texto, que contêm relatórios de dois


roteadores do cenário protótipo. Para melhor visualização, os aspectos mais importantesestão destacados em azul. A primeira caixa de texto mostra o que acontece com o pacoteao entrar no domínio Diffserv pelo roteador R11. Ela mostra especificamente o relatório daclasse AlfaInput, e os primeiros parâmetros em destaque correspondem às condições parao pacote ser classificado. Nesse exemplo são três requisitos (match): valor de precedênciaIP, protocolo e grupo de acesso. Logo em seguida mostram-se as exigências do mecanismode policiamento. Se o fluxo de dados respeita essas condições, o pacote recebe o valor 3 nocampo EXP do cabeçalho MPLS (set-mpls-exp-imposition-transmit). Caso contrário, opacote é penalizado e recebe o valor 2. Nesse exemplo, todos os 791 pacotes classificadoscomo AlfaInput estavam de acordo com as característica de policiamento, portanto todosos pacotes foram marcados com o valor 3.

Roteador11>show policy-map interfaceFastEthernet2/0Service-policy input: IN-POLICYClass-map: AlfaInput (match-all)791 packets, 77518 bytes5 minute offered rate 0 bps, drop rate 0 bpsMatch: ip precedence 1 2 3 4Match: protocol pingMatch: access-group 130police:cir 12 %, bc 300 , be 400

conformed 791 packets, 77518 bytes; actions:set-mpls-exp-imposition-transmit 3

exceeded 0 packets, 0 bytes; actions:set-mpls-exp-imposition-transmit 2

violated 0 packets, 0 bytes; actions:set-mpls-exp-imposition-transmit 2

conformed 0 bps, exceed 0 bps, violated 0

A segunda caixa de texto apresenta os mecanismo de QoS que são utilizados quandoo pacote já passou pela etapa inicial. Nesse exemplo, o relatório apresentado é do roteadorR18 e indica somente a classe Delta. O pacote é novamente classificado, porém dessa vezde acordo com valor do campo EXP. Em seguida, ele entra na fila da saída correspondentea sua classe. A taxa com que esses pacotes podem ser encaminhados é limitada pelomecanismo de condicionamento de tráfego.


O relatório do roteador R11 mostra só as etapas que acontecem antes dos pacotesentrarem na fila para serem encaminhados. Já o relatório do roteador R18 mostra todasas etapas envolvidas para o encaminhamento de pacotes para o próximo salto. Todavia,em nenhum momento apareceram os mecanismos de priorização e o de prevenção decongestionamento, já que eles não estão vinculados a uma classe específica. Eles definemcomo as filas de saída irão ser atendidas e quais pacotes serão descartados em caso decongestionamento.

Roteador18>show policy-map interface FastEthernet1/1 FastEthernet2/1Service-policy output: OUT-POLICYClass-map: Delta (match-all)1511 packets, 154122 bytes5 minute offered rate 0 bps, drop rate 0 bpsMatch: mpls experimental topmost 41511 packets, 154122 bytes5 minute rate 0 bps

Queueingqueueing 64 packets(queueing depht/total drops/no-buffers drops) 0/0/0(pkts outputs/bytes outputs) 1511/154122bandwidth 105 % (10000 kbps)shape (average cir 12000000, bc 48000, be 48000)target shape rate 120000000

79

4 Simulações e Resultados

Neste capitulo apresenta-se a topologia utilizada para implementação da tecnologiaMPLS–TE na rede WAN, detalhando os componentes da rede, os túneis e as VPNs. Issoinclui um conjunto de experimentos realizados sobre esse cenário, cujos resultados sãodiscutidos com base nos dados coletados.

4.1 Planejamento da simulaçãoCom intuito de obter resultados satisfatórios para analisar MPLS–TE sobre uma

rede WAN, escolheu-se elaborar uma infraestrutura simplificada que apresenta característi-cas típicas de rede WAN. Essencialmente, essa infraestrutura contém múltiplos roteadoresde núcleo formando uma topologia com caminhos alternativos, e roteadores de borda quefornecem acesso a clientes da rede WAN.

Para os experimentos que serão apresentados nesse capítulo, utilizou a mesmatopologia da Figura 25. Como o domínio MPLS tem os nós LERs e os LSRs, eles sãoconfigurados de forma diferente. As seções abaixo informam quais são as características decada um deles. Também é apresentado as dos clientes. Nessa mesma linha são informadasquais foram as VPNs criadas e os túneis estabelecidos.

4.1.1 Roteadores de borda (LER)

Conforme a Figura 25, existem quatro LERs na topologia protótipo (R11, R15,R16 e R17). Eles são os roteadores que estão na borda no domínio MPLS, e têm o papelde fazer a interface entre a rede MPLS e a rede IP. Em termos de configurações, o LERpossui um arranjo mais complexo. Para implementar um LER, é necessário configurar osseguintes itens:

• Configurar os endereços das interfaces e de loopback;

• Habilitar MPLS;

• Habilitar LDP;

• Configurar o protocolo OSPF-TE;

• Criar a VPN do cliente conectado:

– Configurar VRF;

– Configurar o protocolo BGP;

Capítulo 4. Simulações e Resultados 80

– Configurar VPNv4.

• Habilitar MPLS–TE por meio de túnel;

• Configurar RSVP–TE;

• Configurar o túnel da engenharia de tráfego;

• Aplicar Diffserv:

– Realizar a classificação dos pacotes.

– Configurar as políticas de mapeamento: entrada e intra MPLS:

∗ Marcação dos pacotes;∗ Policiamento de tráfego;∗ Condicionamento de tráfego;∗ Prevenção de congestionamento.

4.1.2 Roteadores de núcleo (LSR)

De acordo com a Figura 25 existem quatro LSRs na topologia protótipo (R12,R13, R14 e R18). Eles estão localizados no núcleo da rede MPLS, e portanto só realizama comutação de pacotes com base no rótulo MPLS. Em relação aos LERs , os LSR têmuma configuração mais simples. Para configurá-los é necessário o seguinte:

• Configurar os endereços das interfaces e de loopback;

• Habilitar MPLS;

• Habilitar LDP;

• Configurar o protocolo OSPF-TE;

• Habilitar MPLS–TE por meio de túnel;

• Configurar RSVP–TE;

• Aplicar Diffserv:

– Realizar a classificação dos pacotes;

– Configurar a política de mapeamento intra MPLS:

∗ Marcação dos pacotes;∗ Policiamento de tráfego;∗ Condicionamento de tráfego;∗ Prevenção de congestionamento.


4.1.3 Cliente

O software GNS3 pode ser comunicar com o programa de virtualização VirtualBox.Cada rede cliente foi representada por um computador virtualizado contendo o sistemaoperacional ubuntun–16.04–desktop–amd64. Como o foco do projeto é MPLS–TE, osclientes só foram criados para gerar e analisar tráfego. Foram configurados somente osaspectos relacionados ao endereçamento e encaminhamento de dados:

• Endereço da interface;

• Endereço da interface de loopback;

• Rota de encaminhamento;

• Campo DSCP.

4.1.4 VPNs

No cenário de simulação há quatro clientes. Entre eles deve haver o isolamentoentre as VPNs, ou seja, clientes pertencentes à mesma VPN, não podem "enxergar" aexistência dos demais clientes. Para fins de teste, estabeleceu-se que existem duas VPNs.A primeira é VPNA, na qual participam Cliente01 e Cliente04. A outra é VPNB eseus integrantes são Cliente02 e Cliente03. A Figura 32 mostra as VPNs na topologiada rede.

Figura 32 – Topologia indicando as VPNs.


4.1.5 Engenharia de tráfego

Túneis usados para realizar engenharia de tráfego são baseados em três informações:i) destino; ii) largura de banda e iii) prioridade. Para estabelecê-los, os mecanismos darede MPLS (OSPF-TE e CSPF, LDP, RSVP–TE) primeiramente verificam o caminhode menor custo e se tem largura de banda suficiente. No decorrer deste trabalho foramrealizados diversos testes para averiguar a característica de balanceamento de tráfegoobtido por meio de engenharia de tráfego. Foram criados vários tipos de túneis com omesmo destino, cuja finalidade era averiguar como seus caminhos eram determinados. Osresultados e conclusões desses testes estão na seção 3.3.1.

No trabalho definiu-se que haveria apenas duas VPNs, e assim foram configuradosapenas quatro túneis para fins de teste. Todos eles possuem o requisito de largura debanda de 2 Mbps e prioridade 0. Foram usados dois túneis para cada VPN, pois umacaracterística do túnel da engenharia de tráfego é sua unidirecionalidade. A seguir, haFigura 33 informa os túneis que foram usados nos teste nas seções seguintes.

Figura 33 – Topologia indicando os túneis.

4.1.6 Diffserv

A rede implantada seguiu um modelo Diffserv para atendimento de requisitos deQoS. Dentre os mecanismos previstos nesse modelo, não foram configurados priorizaçãoe prevenção de congestionamento. Nos roteadores utilizados nesse trabalho estão pré-configurados a disciplina de escalonamento WFQ e o tipo de descarte WRED. Já aclassificação foi configurada em todas as interfaces de todos os roteadores. Nessas mesmas,


também foram implantadas as políticas de mapeamento, que corresponde a um ou maisdos mecanismos de QoS restantes (marcação, condicionamento e policiamento).

Figura 34 – Topologia indicando as políticas de serviços na interface.

A Figura 34 mostra a política de mapeamento que foi usada nesta topologia. Apolítica de mapeamento Input (setas roxas) serve para os pacotes que entram no domínioMPLS. Nessa etapa ocorre o policiamento do tráfego e a marcação. Se o pacote está deacordo com sua classe ele recebe um valor no campo EXP. Se não, ele recebe outro valornesse mesmo campo, porém, com prioridade menor.

A Tabela 9 mostra como são classificados e marcados os pacotes nessa etapa. Todasas classes usaram o parâmetro ClienteX no requisito Origem. Ele representa o endereçoIP do cliente conectado ao um LER. Outro critério de classificação é o cabeçalho DSCPde datagramas IP, cujo valor é mapeado para oito valores (entre 0 e 7). No Apêndice Aapresenta-se a Tabela 14, com conversão do DSCP para nível de precedência.

Critério de classificação Marcação em relaçao ao campo EXClasse Origem Protocolo Precedência IPPoliciamento(% LB ) pacote aceito pacote recusado

AlfaInput ClienteX SSH 1, 2, 3 e 4 12 1 1BetaInput ClienteX SSH 5 e 6 12 2 1GamaInput ClienteX PING 1, 2, 3 e 4 12 3 2DeltaInput ClienteX PING 5 e 6 12 4 3

EpsilionInput ClienteX RTP e UDP 1, 2, 3 e 4 12 5 4ZetaInput ClienteX RTP e UDP 5 e 6 12 6 5

Tabela 9 – Classificação e politica de mapeamento Input.

A seta vermelha da Figura 34 representa a política de mapeamento no núcleo darede MPLS, denominada Core. Quando o pacote entra no domínio Diffserv ele é associado


a uma classe Input, e assim recebe um valor no campo EXP do cabeçalho MPLS. Quandoo pacote é encaminhado para o próximo salto, conforme o valor do campo EXP o pacote éselecionado para uma classe Core. Ela específica a quantidade da sua reserva da largura debanda e também do condicionamento de tráfego, cujos valores escolhidos estão descritos naTabela 10. Deve-se notar que tanto a reserva da classe, o condicionamento e o policiamentoconstantes na Tabela 9, estão vinculados a uma % da largura de banda (LB). Todos os trêspossuem os mesmos valores para todas as classes. Eles não foram alterados de acordo coma classe de tráfego, pois os experimentos realizados não demandaram valores diferentes.

Critério de classificaçãoClasse Campo EXReserva(% LB)

Condicionamento:taxa de saída em relação a % LB

Alfa 1 10 12Beta 2 10 12Gama 3 10 12Delta 4 10 12

Epsilion 5 10 12Zeta 6 10 12Eta 7 10 12

Tabela 10 – Classificação e politica de mapeamento Core.

Pelo modo que foi configurada a implantação da arquitetura Diffserv, cada classifi-cação esteve vinculada a uma política de mapeamento. Para compreender essa associação,basta analisar o seguinte cenário. Um pacote é enviado do Cliente01 para o roteadorR11. Antes de ser encaminhado para outro roteador o pacote é analisado, e de acordocom suas características ele é classificado, por exemplo, como BetaInput. De acordo comsua classificação o pacote passa pela etapa de policiamento e se respeitar as restriçõespara sua classe de tráfego ele recebe um valor no campo EXP do rótulo MPLS, e emseguida é encaminhado para outro roteador. Chegando ao próximo roteador, o critério declassificação deixa de ser os critérios das classes Input e sim o valor do campo EXP dorótulo. Após ser classificado, o pacote passa pelo condicionador de tráfego, para limitar ataxa de saída daquela classe. A etapa do Core acontece várias vezes até o pacote sair darede. Caso o pacote não se encaixe em nenhuma classificação ele é considerado class–default,o que implica seu tratamento na rede ser do tipo melhor esforço, marcado com valor zerono campo EXP do rótulo.

4.2 Formato dos experimentosNo decorrer desse trabalho foram elaborados três experimentos principais utilizando

a topologia da Figura 25. Foram mantidas as duas VPNs, descrita na seção 4.1.4, e quatrotúneis da engenharia de tráfego: R11 ↔ R18 ↔R15 e R16 ↔R15 ↔ R17.


Em todos os experimentos utilizaram-se duas aplicações para reproduzir tráfegosentre clientes pertencentes à mesma VPN. A primeira aplicação foi o iperf, que transmitiupacotes IPv4 para gerar tráfego de melhor esforço durante um intervalo de cinco minutos.Durante sua execução, o iperf armazenou as taxas (kbps) a cada cinco segundos em umarquivo. Através dos dados desse arquivo, pôde-se analisar o desempenho desse tipo detráfego. A caixa de texto abaixo refere-se ao comando utilizado no cliente para acionaraplicação iperf.

iperf -u -c [IP servidor] -b [taxa transmissão] -t 300 -i 5 > arquivo.log

O outro tráfego entre os clientes foi gerado pela ferramenta PJSUA. De acordocom Vieira (2010) o PJSUA "é uma biblioteca de alto nível e que serve para a cons-trução de aplicações multimıdia Session Initiation Protocol (SIP) de forma simples".Foram realizadas chamadas SIP entre clientes, com transmissão de áudio via Real-time Transport Protocol (RTP). Seus pacotes eram selecionados como classe DiffservExpedited Forwarding (EF), e isso significa que os mecanismos de QoS são usados paraque esse tráfego tenha prioridade em relação ao tráfego de melhor esforço. Essa ferramentaentrega um relatório ao final de cada chamada, o qual informa estatísticas de jitter e deperda de pacotes tanto para o transmissor e receptor, além da taxa de transmissão. Acaixa de texto abaixo mostra esse relatório e a seguir há explicações de cada parâmetro,são eles:

• pt: pacotes transmitidos ou recebidos;

• pkt loos número de pacotes perdidos;

• discrd: número de pacote descartados;

• dup: número de pacotes duplicados;

• reord: número de pacotes reordenados;

• loss period: tempo que não havia áudio, por causa da perda de pacotes (PJSIP,2009) 1;

• jitter: "é a variação no atraso entre pacotes pertencentes ao mesmo fluxo"(FOROUZAN,2009) 1;

1 possuí: mínimo(min), máximo(max), média(avg), último(last) e desvio padrão(dev) em milissegundos.


• Round–Trip Time (RTT): é o tempo que o pacote leva para chegar ao destinoe receber sua resposta(milissegundos) 1;

• avg: taxa média do fluxo, com e sem cabeçalho IP.

Call time: 00h:05m:03s, 1st res in 120 ms, conn in 124ms0 audio speex @16KHz, sendrecv, peer=10.0.83.1:4000SRTP status: Not active Crypto-suite:RX pt=98, last update: 00h:00m:02.779s agototal 15.1Kpkt 1.06MB (1.67MB + IP hdr) @avg=28.0Kbps/44Kbpspkt loss=0 (0.0%), discrd=0 (0.0%), dup=0 (0.0%), reord=0 (0.0%)

(msec) min avg max last devloss period: 0.000 0.000 0.000 0.000 0.000jitter : 1.187 11.827 39.062 6.437 3.910

TX pt=98, ptime=20, last update: 00h:00m:03.932s agototal 15.1Kpkt 1.06MB (1.67MB + IP hdr) @avg=27.9Kbps/43.9Kbpspkt loss=0 (0.0%), discrd=0 (0.0%), dup=0 (0.0%), reord=0 (0.0%)

(msec) min avg max last devloss period: 0.000 0.000 0.000 0.000 0.000jitter : 0.000 10.197 16.562 12.312 3.760

RT msec : 22.628 53.124 123.000 27.175 11.590

Antes de iniciar a chamada SIP, utilizou-se o utilitário tcpdump para fazer omonitoramento específico desse tráfego. Esse programa é um analisador de protocoloque captura os pacotes de uma interface de rede, e pode armazená-los em um arquivo.Utilizou-se também o programa wireshark para ler o arquivo de captura e analisar ospacotes ali contidos. A caixa de texto a seguir mostra o comando do tcpdump utilizado nocliente. Percebe-se que ele analisa somente os pacotes referentes ao protocolo UDP, poisos pacotes da chamada do PJSUA foram gerados pro protocolos SIP e RTP, e ambos sebaseiam em UDP.

tcpdump -i [interface do cliente] -w arquivo.cap udp port 4000

Para não haver disparidade entre os todos os experimentos realizados, sempreutilizou-se o mesmo arquivo de configuração para todos os componentes da topologia da


rede. Nesses testes todas as interfaces, cujos roteadores pertencem ao domínio MPLS,foram configuradas para reservarem até 4 Mbps de largura de banda para o protocoloRSVP. E todos os túneis requisitaram a mesma configuração de largura de banda de 2Mbps. A caixa de texto abaixo mostra o comando show ip rsvp interface para o roteadorR11, indicando se o RSVP está habilitado e qual é o taxa máxima de transmissão doRSVP por interface (i/f max). E qual interface teve sua largura de banda alocada para otúnel (allocated).

Roteador1>show ip rsvp interfaceinterface rsvp allocated i/f max flow max sub max VRFFa1/0 ena 0 4M 4M 0Fa1/1 ena 0 4M 4M 0Fa2/0 ena 2M 4M 4M 0

4.2.1 Cenários dos testes

A seguir estão apresentados os três cenários de testes realizados neste trabalho. Cadaum deles tem o objetivo de analisar um requisito ou comportamento. Todos eles seguema mesma premissa: transmitir vários tráfegos entre os pares de clientes. Especificamente,houve dois tipos de tráfegos, sendo um de melhor esforço gerado pelo iperf, e outro comrequisitos de QoS, que refere-se ao tráfego de dados das chamadas SIP.

Esses tráfego passou sempre por um túnel de engenharia de tráfego, cuja capacidademáxima de reserva de largura de banda foi de 2 Mbps. Devido a essa limitação, cadateste de cenário foi executado três vezes, pois em todos eles o tráfego do melhor esforçovariava entre 1 Mbps, 2 Mbps e 3 Mbps. Esses valores foram escolhidos para analisar ocomportamento de todos os tráfegos quando a taxa de transmissão dos dados enviadosentre os clientes estavam abaixo (1 Mbps), igual (2 Mbps) e superior (3 Mbps) a capacidademáxima reservada pelo túnel.

Todos os tráfegos passaram pelo túnel e este teve uma largura de banda limitada.Logo, o tráfego do SIP, que possui requisitos de QoS, deveria ter melhor desempenho, poisele possui prioridade em relação o do melhor esforço.

No primeiro cenário foi realizada a transmissão de pacotes entre um par de clien-tes. Nesse caso específico escolheu-se o Cliente02 para enviar tráfego para o Cliente03.Especificamente, o Cliente02 enviou dois tipos de tráfegos: uma transmissão do iperf, quefuncionou como tráfego de melhor esforço, e uma chamada SIP para ser o tráfego com


requisitos de QoS. Ambos os tráfegos eram enviados por um túnel, e a Figura 35 mostraesses tráfegos entre Cliente02 e Cliente03.

Nesse cenário específico o objetivo foi verificar o comportamento dos dois tráfegospelo túnel. Principalmente em relação ao tráfego da chamada SIP, para averiguar se seusrequisitos de QoS foram atendidos e como o tráfego de melhor esforço foi afetado.

Figura 35 – Cenário1: Topologia indicando os tráfegos oriundos do Cliente02.

O segundo cenário executado é semelhante ao Cenário1. A diferença foi a adição demais uma chamada pela ferramenta PJSUA realizada pelo Ciente02. A Figura 36 mostradetalhadamente esse cenário, que possui um tráfego de melhor esforço e duas chamadasSIPs. O propósito desse cenário é comparar os resultados com o do Cenário1 para verificaro desempenho das chamadas SIPs, uma vez que houve duas chamadas e isso implica odobro de tráfego disputando pelos recursos fornecidos pela classe. Além disso, comparou-seo comportamento do tráfego de melhor esforço quando acrescenta mais uma chamada.


Figura 36 – Cenário2: Topologia indicando os tráfegos oriundos do Cliente02.

Finalmente, o Cenário3 utilizou todos os quatro clientes da topologia. Houve trocade infamações entre: Cliente02 ↔ Cliente03 e Cliente01 ↔ Cliente04. Esse cenárioé semelhante ao Cenário1, dado que esses pares de clientes só trocam um fluxo de melhoresforço e uma chamada SIP. Por meio da Figura 37 nota-se que a rota entre Cliente02↔ Cliente03 continuou o mesmo. Já a rota entre o outro par de clientes foi R17 ↔ R15↔R16.

A finalidade desse teste foi comparar o desempenho dos tráfegos com os demaiscenários especialmente em relação ao Cenário1. Pois, os resultados entre eles devem sersemelhantes, já que somente foi acrescentado outro par de clientes para transmissão dosmesmos tráfegos. Além disso, não há o compartilhamento do enlace entre os túneis. Só oroteador R15 é de uso comum, já que ambos os túneis passaram por ele.


Figura 37 – Cenário3: Topologia indicando os tráfegos oriundos do Cliente02 e Cliente04.

4.3 Análise dos resultadosA seguir são abordados quatro tópicos em relação aos resultados obtidos nos

cenários de simulação. Os três primeiros são uma análise detalhada dos parâmetros decada cenário. A primeira seção discute a taxa de dados do tráfego de melhor esforço emtodos os testes realizados. Já a segunda foca sobre a taxa de dados da classe Diffserv EF.Depois, sobre os dados das chamadas SIP em todos os testes, como: jitter, período entreperdas e taxa de transmissão. Por fim, foram analisados todos esses dados, para ter umavisão total de todos os testes.

4.3.1 Taxa de transmissão do tráfego de melhor esforço

Nessa etapa foi analisada somente a taxa de dados do tráfego de melhor esforço,que foi gerada pela ferramenta iperf, na interface de saída do Cliente02. Esse tráfego nãorecebeu nenhuma garantia de QoS, ele somente usufrui dos requisitos de rede sobressalentesdurante sua transmissão. Entretanto, pacotes desse tipo de tráfego estavam sujeitos a nãoserem transmitidos caso não houvesse recursos suficientes. Nesta seção apresenta-se umasérie de gráficos que mostram a taxa de transferência (bits/s) momentânea a cada cincosegundos durante cinco minutos, para todos os testes realizados. Com isso examinou-seprincipalmente a variação dessa taxa para todos eles.


Figura 38 – Gráfico das taxas do tráfego de melhor esforço para o Cenário1.

O primeiro gráfico a ser analisado é a Figura 38. Ele mostra a variação da taxa detransferência do tráfego de melhor esforço para o Cenário1. Conforme, o valor da taxacresce, a quantidade de oscilações também aumenta. Para 1 Mbps não houve variaçõessignificativas, mas ao aumentar para 2 Mbps variações podem ser percebidas. Se a taxa dotráfego de melhor esforço fosse 2 Mbps e não houvesse o tráfego oriundo da chamada SIP,o comportamento do tráfego do melhor esforço seria semelhante ao da taxa de 1Mbps.Todavia, nesse teste, há o tráfego de melhor esforço e classe Diffserv EF, cujas taxas sãosuperiores a 2 Mbps, por isso, aconteceram quedas na taxa do tráfego do melhor esforço.

Essa oscilação na taxa aconteceu mais vezes para taxa de 3 Mbps, que era oesperado. Quanto maior for a parte da taxa que ultrapassa o limite da largura de bandaestabelecido pelo túnel, mais frequentemente a taxa de transmissão decai devido aocongestionamento. Comparando as oscilações entre o tráfego de 2 Mbps e 3 Mbps, percebe-se que ambos tiveram sua taxa de transmissão reduzida praticamente em 1 Mbps, umvalor bem significativo se comparado ao valor da taxa pretendida.



A Figura 39 exibe a taxa de transmissão do tráfego de melhor esforço para oCenário2. Comparando essa figura com o gráfico da Figura 38, acontece o mesmo com-portamento. Para taxas de tráfego acima de 2 Mbps a reserva do túnel fica saturada, e otráfego do melhor esforço sofre decaimento em suas taxas de transmissão. Continuandoa comparação com os dois cenários, percebe-se que o Cenário2 (Figura 39) possui muitomais oscilações na taxa do melhor esforço. Esse acontecimento era aguardado, pois hámais tráfego prioritário na rede. Logo o tráfego de melhor esforço tem menos largura debanda disponível, e devido a isso a quantidade de oscilações é mais elevada.


Já as informações da taxa de transferência do melhor esforço para o Cenário3 estão


demonstradas na Figura 40. Como esse cenário envolve também o Cliente04 e o Cliente01,no Apêndice B na Figura 44 apresenta-se o gráfico relacionado às taxas de transferênciado melhor esforço do Cliente04. Foi escolhido apresentar os dados desse cliente, pois elepossui o mesmo comportamento do Cliente02, que é enviar um tráfego de melhor esforço erealizar uma chamada SIP.

O intuito do Cenário2 é comparar seus resultados com os do Cenário1. Esperava-seque esses dados fossem semelhantes ao do Cenário1, todavia isso não aconteceu. Nessecenário o Cliente02 possui muitas oscilações. Acredita-se que isso ocorreu devido aocompartilhamento do roteador R15. Não houve compartilhamento de enlace, porém, etodos os túneis tinham como rota o R15. Logo, o roteador tinha o dobro de tráfego paraencaminhar por suas interfaces, e, por causa disso, houve mais oscilações na taxa deencaminhamento do tráfego de melhor esforço.

Figura 41 – Gráfico com a taxa do tráfego de melhor esforço em 1 Mbps para o todos oscenários.

Como as figuras acima estão numa escala de Mbps para aparecer todas as taxas, apequenas variações ficaram imperceptíveis. Isso acontece para a taxa de 1 Mbps, pois elapossui variações na ordem de kbps. A Figura 41 apresenta a taxa de 1 Mbps para todosos cenários. Percebe-se que essas taxas possuem variações, porém menores em relação àsdemais taxas. O foco desse gráfico é mostrar que, mesmo tendo largura de banda suficientepara todos os tráfegos, ainda existem variações na taxa de transmissão. Todavia, essasvariações são muito pequenas, situando-se entre 0.5 % á 4 % da taxa ideal de transmissão(1 Mbps).


4.3.2 Dados da chamada SIP

Durante todos os testes a ferramenta PJSUA entregou um relatório de cadachamada, contendo tanto informações dos dados transmitidos (TX) quanto dos dadosrecebidos (RX). Como há muitos parâmetros nesse relatório escolheu-se utilizar: lossperiod e jitter. Em ambos os casos, usaram-se somente os dados da média (avg) e dodesvio padrão (dev). Também foi analisado o @avg, porém não foram colocados nastabelas a seguir, já que em todos os testes para cada chamada a taxa era a mesma. Para ataxa sem cabeçalho IP fica em 27.9 e 28 kbps e com cabeçalho passava entre 43.9 e 44kbps.

A seguir a Tabela 11 contém informações coletadas no Cliente02 de todos oscenários e taxas de transmissão do tráfego de melhor esforço. O Cenário2 teve duaschamadas praticamente simultâneas e o PJSUA entregou um relatório para cada umadelas. Escolheu-se apenas o relatório referente à primeira chamada para ser representadanos dados na Tabela 11. Já no Cenário3, os dados do Cliente04 não foram inseridos nessatabela porque os resultados são semelhantes aos do Cliente02. Todavia, eles estão na seçãoB na Tabela 15. Não foram postos esses resultados na Tabela 11, pois o objetivo dessaseção é comparar os dados do Cliente02, para verificar se o comportamento esperado paracada cenário e taxa de tráfego de melhor esforço estavam conforme o esperado.

Antes de começar a analisar essa tabela, deve-se ressaltar que os testes forampara averiguar como foi tratada a prioridade de tráfego ao longo do túnel, visto que ofluxo de dados das chamadas SIP pertence a uma classe de tráfego e o de melhor esforçoé encaminhado como serviço de melhor esforço. Durante a configuração das classes detráfegos, foi estipulado que cada uma delas possui uma parte da largura de banda, masisso esteve associado à interface do roteador e não ao túnel. Assim, no túnel os requisitosde QoS ficam limitados à priorização e prevenção de congestionamento. De acordo com aclasse de tráfego do pacote, ele tem prioridade para ser encaminhado e menor chance deser descartado em caso de congestionamento.

Primeiramente observou-se o Cenário3 apresentou o pior desempenho. Ele foi o únicoa apresentar perdas em 2 Mbps e todos os seus resultados foram elevados, se comparados aosdemais cenários. Teoricamente o Cenário3 e Cenário1 deveriam ter resultados semelhantes.Acredita-se que o motivo dessa disparidade esteja relacionado à passagem de ambos ostráfegos Cliente01 ↔ Cliente04 e Cliente02 ↔ Cliente03 pelo roteador R15, todavia, elesutilizaram interfaces diferentes para encaminhar os pacotes. Essa questão precisaria serinvestigada com maior profundidade.


Período entreperdas (msec) Jitter (msec)

RX TX RX TXCenárioTaxa do tráfegode melhor esforço

(Mbps) media dev media dev media dev media dev1 1 0 0 0 0 11.827 3.910 10.197 3.7601 2 0 0 0 0 13.764 3.654 10.826 3.3861 3 0 0 50 30 15.462 3.541 11.883 2.8942 1 0 0 0 0 11.811 3.444 10.331 1.8212 2 0 0 0 0 14.253 3.651 11.336 3.6202 3 0 0 30 10 16.384 3.508 11.849 3.9193 1 0 0 0 0 22.121 6.904 21.075 8.2423 2 0 0 45.000 13.412 21.164 4.656 16.921 4.9963 3 60 0 179.149 53.966 27.364 4.496 21.802 6.853

Tabela 11 – Dados dos relatórios do PJSUA para todos os cenários.

Observou-se em que nenhum momento houve período entre perdas (loss period)para qualquer cenário cuja taxa de transmissão do tráfego de melhor esforço tenha sido1 Mbps. Esse resultado esteve como esperado, pois a reserva do túnel foi de 2 Mbps e otráfego de melhor esforço foi de 1Mbps. Isso significa que havia 1 Mbps para transmitir osdados da chamada SIP, que podia ser tanto 48 kbps (uma chamada) ou 96 kbps (duaschamadas). Logo, havia largura de banda excedente para todos os tráfegos, por isso, nãohouve perda de pacotes.

Desconsiderando o Cenário3 para 2 Mbps, os demais não tiveram perdas de pacotes.A taxa máxima de dados era de 2.096 Mbps, no pior caso, ultrapassando um poucoa capacidade de transmissão do túnel. Como havia dois fluxos de dados disputando alargura de banda do túnel, o tráfego da classe Diffserv EF possui prioridade na fila desaída dos roteadores. Além do que, como a política de descarte é WRED significa quehá mais chances dos pacotes do tráfego de melhor esforço serem descartados, do que ospacotes da chamada SIP, pois, eles pertencem a uma classe de tráfego. Nesse testes, houvecongestionamento devido à taxa de fluxo de dados estar ligeiramente acima da capacidadedo túnel, e só os pacotes de melhor esforço foram descartados. O WRED não precisoudescartar também pacotes da chamada SIP para descongestionar a rede. Já o Cenário3apresentou período entre perdas de pacotes, porque ambos os tráfegos passaram peloroteador R15 e houve congestionamento, de forma que mesmo os pacotes com prioridadeprecisaram ser descartados.

Quando a taxa do tráfego de melhor esforço foi de 3 Mbps, ocorreram períodosentre perdas para todos os cenários. A taxa de todos os tráfegos foi superior ao do túnel,provocando congestionamento. O túnel não teve capacidade suficiente de transmitir todosos pacotes, então houve o descarte de pacotes para descongestionar. Como a quantidadede pacotes para serem encaminhados era muito grande, até os pacotes que possuíamprioridade foram descartados.

Ao analisar o jitter numa visão geral, percebe-se que ele aumenta conforme cresce


a taxa do tráfego de melhor esforço. Esse aumento era esperado, uma vez que ao aumentaro tráfego que será encaminhado pelo túnel, mais pacotes irão ficar nas filas de saída dasinterfaces de roteadores para serem transmitidos. Esse tempo varia de pacote para pacote.Depende das quantidades de pacotes que estão aguardando em filas. O Cliente03 não teveesse comportamento, especialmente se comparar para a taxa do tráfego de melhor esforçopara 1 Mbps e 2 Mbps. O jitter para taxa de 2 Mbps foi menor em relação de 1 Mbps.O dobro de pacotes transmitidos não influenciou no aumento do jitter. Mesmo com essaressalva, os valores dos jitters entre todos os testes são bem aproximados. Em nenhumcaso, houve uma disparidade de valor.

4.3.3 Taxa de transmissão do trafego da chamada SIP

Antes de realizar os testes foi executado o programa tcpdump para gravar em umarquivo os dados dos pacotes UDP capturados. Em seguida, usou-se o programa wiresharkpara ler esses dados e gerar gráficos. Para o presente trabalho utilizou-se o tcpdump paracoletar as informações dos pacotes oriundos da ferramenta PJSUA. A seguir a Figura 42exibe um gráfico gerado pelo wireshark que relaciona o tempo e a taxa de bits/sec.

Figura 42 – Cenário 1 com tráfego de melhor esforço com a taxa de 2 Mbps.

O propósito dessa seção é comparar as taxas de transmissão do PJSUA para oscasos de uma chamada e duas chamadas. Primeiramente foi analisado para uma únicachamada. A Figura 42 é um bom exemplo, e ela apresenta o tráfego de uma chamadaSIP no Cenário1. Percebe-se que a taxa durante os cinco minutos oscila, mas, sua médiase situa em 99 kbis/s, e esse valor é praticamente o mesmo apresentado no relatório doPJSUA. Nele a taxa média do fluxo (avg), considerando os cabeçalhos dos pacotes, é 88kbits/s. Percebe que a taxa na Figura 42 é de 99 kbps, pois, foram capturados os pacotesUDP. Como há protocolos que transmite seus pacotes UDP há o acréscimo mo dessa


taxa. Para duas chamadas, há a Figura 43 que mostra a taxa [bits/s] no Cenário2. Comoprevisto, a taxa dobrou de valor. Uma vez que uma chamada tem quase 100 Kbits/s,então, duas chamadas possuem 200 kbits/s.

Figura 43 – Cenário 2 com tráfego de melhor esforço com a taxa de 2 Mbps

4.3.4 Resultados e discussão

Este capítulo apresentou os experimentos realizados para avaliar o funcionamentode uma rede WAN com MPLS–TE. Foram abordados os componentes da rede, os cenários,as ferramentas para os testes e como foram estabelecidos: as VPNs, os túneis da engenhariade tráfego e o domínio Diffserv. Os resultados dos experimentos implicaram a investigaçãosobre a taxa de transferência do tráfego de melhor esforço, jitter, período entre perdas etaxa de dados das chamadas SIP. Esses resultados serviram para averiguar a infraestruturade rede com MPLS–TE e Diffserv se comportou para diferentes taxas de transmissão ecomo o tráfego da classe Diffserv EF e o de melhor esforço foram tratados.

Primeiramente analisou-se o comportamento em relação à taxa de dados do tráfegode melhor esforço. Quando essa taxa era 1 Mbps, independente do cenário, a capacidadeociosa do túnel foi superior a largura de banda requerida pelo tráfego. Logo, foi esperadoque não houvesse congestionamento. A classe Diffserv EF não apresentou em nenhummomento perdas de pacotes. Já o tráfego de melhor esforço teve poucas oscilações e osvalores delas eram em média 4 % abaixo da taxa que deveria ser transmitida.

Em seguida, injetaram-se tráfego de melhor esforço na rede com uma taxa de 2Mbps. As somas das taxas de tráfegos variaram entre 2.048 Mbps e 2.096 Mbps, dependendodo cenário, ou seja, o tráfego de dados estava até 2.4 % acima da capacidade do túnel,ocasionando congestionamento. O tráfego de melhor esforço sofreu mais oscilações emrelação ao de 1 Mbps e essas oscilações foram significativas. Houve momentos que a taxado tráfego de melhor esforço decaiu em 50 % (1 Mbps). Já o tráfego da classe Diffserv


EF, os resultados variaram conforme o cenário. Para o Cenário1 e Cenário2, não ocorreunenhuma perda de pacotes. No congestionamento, não houve necessidade de descartarpacotes de alta prioridade para descongestionar a rede. Em relação ao Cenário3, houvedescarte de pacotes que pertenciam à classe Diffserv EF.

A taxa máxima que foi definida para o tráfego do tráfego de melhor esforço foide 3 Mbps. Nesses testes as taxas de tráfegos foram superiores em relação à capacidadedo túnel. Em qualquer cenário houve perdas de pacotes do fluxo de dados da classeDiffserv EF, e isso significa que houve congestionamento e até os pacotes que pertenciama uma classe de tráfego foram descartados. O tráfego de melhor esforço apresentou o piordesempenho em relação aos testes que variavam a taxa do tráfego de melhor esforço. Aquantidade de oscilações mais que dobraram em comparação a taxa de 2 Mbps, porém, ovalor do decréscimo da taxa foram iguais (1 Mbps). Isso significa que o túnel não reduzdrasticamente a taxa do tráfego para evitar o congestionamento, até porque o tráfegochega constantemente, por isso, há várias reduções na taxa no decorrer do tempo paracontrolar os tráfegos.

Taxa do tráfego domelhor esforço Resultados esperados Resultados obtidos

1 Mbps –Sem perdas de pacotes da chamada SIP.–Sem oscilações no tráfego de melhor esforço.

–Sem perdas de pacote para o tráfego da chamada SIP.–Variações mínimas no tráfego de melhor esforço.

2 Mbps –Perdas de pacotes do SIP–Oscilações no tráfego de melhor esforço.

–Sem perdas de pacote para o tráfego SIP,exceto o Cenário3.–Variações significativas no tráfego de melhor esforço.

3 Mbps –Perdas de pacotes do SIP.–Várias oscilações no tráfego de melhor esforço

–Perdas de pacote para o tráfego SIP.–Várias oscilações no tráfego de melhor esforço

Tabela 12 – Comparação entre o comportamento pretendido e ocorridos, variando a taxado tráfego do fundo.

A Tabela 12 mostra a comparação entre os comportamentos esperados e os ocorridos.Para 1Mbps não deveria ocorrer perdas de pacotes e nem oscilações, pois, a capacidade detransmissão do túnel era superior às taxas de tráfegos que passavam por ele. A variaçãomínima que ocorreu no tráfego de melhor esforço está relacionada a eventos pontuais comoum pico de fluxo de dados chegando ao um roteador do que um congestionamento devido àgrande quantidade de tráfego. Já com o tráfego para 3 Mbps aconteceu exatamente o que seesperava: os pacotes da classe Diffserv EF foram descartados devido ao congestionamentoe ocorreram muitas oscilações no tráfego de melhor esforço.

Excluindo os resultados de período entre perdas de pacotes no Cenário3, a Tabela12 mostra que o comportamento foi melhor que o pretendido para 2 Mbps. Como todos ostráfegos juntos possuíam uma taxa de transmissão maior que 2 Mbps, largura de bandareservada ao túnel, deveria ter perdas de pacotes para todos os tipos de tráfegos. Contudo,os pacotes do da classe Diffserv EF não precisaram ser descartados, pois, as garantias dasua classe de tráfego evitaram esse acontecimento. Todavia, o tráfego de melhor esforço


teve momentos de queda na taxa de transmissão por causa da saturação do túnel porcausa da quantidade de tráfego.

Cenários Resultados esperados Resultados obtidos

Cenário1 XCenário2

–Cenário2 possui mais perda de pacotes nas chamadas no SIP.–Maiores variações no Cenário2 em relação aoCenário1 para o tráfego de melhor esforço.

– Comportamento semelhante das chamadas do SIPem relação aos cenários.–Maiores variações no Cenário2 em relação aoCenário1 para o tráfego de melhor esforço.

Cenário1 XCenário3

– Resultados semelhantes tanto para otráfego do SIP quanto o do tráfego de melhor esforço.

– Resultados distintos entre os cenários, tanto parao tráfego do SIP quanto o do melhor esforço.- O Cenário3 apresentou piores resultados emcomparação ao Cenário1.

Tabela 13 – Comparação entre o comportamento pretendido e ocorridos, entre os cenários.

Os cenários de teste foram elaborados para comparar Cenário1 com o Cenário2 eo Cenário1 com o Cenário3. A tabela 13 mostra os resultados almejados em relação aosocorridos. A comparação é relacionada ao o comportamento do túnel para quando houvesseuma única chamada SIP (Cenário1) e quando tivesse duas chamadas (Cenário2). Esperavaque o cenário com duas chamadas tivesse piores resultados. Uma vez que aumentou a taxade tráfego e esse acréscimo pertencia a uma classe do Diffserv EF. Se comparar com osdados dos relatórios do PJSUA (Tabela 11) verificam que os parâmetros: período entreperdas de pacotes e jitter foram bem semelhantes. Não houve tanta disparidade em relaçãoao desempenho das chamadas, pois, o tráfego do PJSUA pertence a uma classe DiffservEF. A classe tem como objetivo fornecer certos níveis de garantias aos seus pacotes. Nessecaso específico a capacidade de tráfego para essa classe não havia ultrapassado, logo,não houve o descarte desses pacotes. Em relação ao tráfego de melhor esforço observouque o Cenário2, teve várias oscilações comparadas ao Cenário1. Esse comportamento eraesperado, pois, quando houve duas chamadas, aumentou a taxas de dados transmitidospelo túnel, consequentemente, o tráfego de melhor esforço acaba tendo suas taxas detransmissão reduzidas para evitar o congestionamento.

Ao comparar o comportamento do Cenário1 com Cenário2 na Tabela 13, percebe-seque os resultados desejados foram diferentes dos obtidos. Ambos os cenários deveriamter desempenho semelhantes para todos os tráfegos, mas o Cenário3 apresentou pioresresultados. Supõe-se que esses resultados devem-se ao fato de todos os tráfegos do testepassarem pelo do roteador R15. Não houve o compartilhamento de nenhuma interfaceentre Cliente04 ↔ Cliente01 e o Cliente02 ↔ Cliente03. Entretanto todos os pacotespassam pelo R15 e isso implica o dobro de pacotes para serem analisados nas tabelas deencaminhamento, aumentando a espera para o pacote ser analisado e transmitido. Essaquestão precisa ser aprofundada em um próximo trabalho.

100

5 Conclusões e trabalho futuros

Apresentou-se neste trabalho uma proposta de como implantar engenharia detráfego baseada em MPLS–TE sobre a rede WAN. Para replicar de forma mais reala rede WAN, foi estabelecido que ela simulasse uma infraestrutura de rede espalhadageograficamente e que atendesse diversos clientes, interligando-os por meio de VPN. Alémdisso, implantou-se um domínio Diffserv para atender requisitos de QoS de tráfegos dedados dos clientes. Esse cenário apresentou uma série de necessidades, e assim investigou-secomo atendê-las usando uma infraestrutura baseada em MPLS–TE.

Uma necessidade era facilitar a implantação de enlaces virtuais. Ao utilizar oMPLS–TE, basta o gerente da rede configurar o roteador que estava conectado ao clientee fazer toda configuração da VPN e também configurar a existência de mais um novocliente em cada roteador de borda que pertencia àquela VPN. Não há mais a necessidadede configurar todos os roteadores da infraestrutura para cada novo cliente e nem configuraro próprio cliente. Em relação à VPN desejava-se que os clientes que não participavamda mesma VPN não poderiam se conectar. Por meio da tecnologia VRF conseguiu essaseparação entre as VPNs.

Outro requisito desejado era a capacidade da rede se restabelecer após uma falha deenlace ou de equipamento. A tecnologia MPLS–TE foi capaz de recuperar automaticamentea conectividade na rede em menos de um minuto. Estudou-se no decorrer desse trabalhoa técnica FRR, que deveria diminuir esse tempo de recuperação para 50 msec (GHEIN,2007). Todavia, na etapa de implantação dessa tecnologia, todos os testes realizados nãoobtiveram valores do tempo de recuperação da rede significativos em relação aos testesanteriores.

A engenharia de tráfego na rede MPLS foi implantada por meio de túneis, que eramestabelecidos de acordo com: destino, largura de banda e nível de prioridade. Os túneiseram o meio pela qual a engenharia de tráfego distribuía os fluxos de dados pela rede, cujointuito era evitar congestionamento de certos enlaces e ociosidade em outros. Nos testesde criação de diversos túneis verificou-se que houve essa distribuição mais uniforme dosfluxos de dados. Os roteadores estabeleceram túneis seguindo caminhos determinados deforma dinâmica. A garantia de reserva de banda e o caminho de menor custo até o destinoeram requisitos para a determinação de caminho. Caso esse caminho deixasse de ser omelhor, após um tempo os mecanismos de engenharia de tráfego recalculam a rota, a fimde melhorar o desempenho da rede.

Por meio de experimentos verificou-se que não é aconselhável transmitir tráfegospelo túnel cujas taxas extrapolem a capacidade de largura de banda do túnel. Se a taxa

Capítulo 5. Conclusões e trabalho futuros 101

de dados for inferior, o túnel fornece um ótimo desempenho para esse fluxo de dado. Casoessa taxa seja superior, ocorre congestionamento no túnel. O tráfego de melhor esforço éo primeiro a ser prejudicado, tendo sua taxa de transmissão reduzida. Conforme a taxade dados aumenta nem as garantias das classes de tráfegos conseguem evitar que os seuspacotes sejam descartados.

Em relação aos objetivos gerais desse trabalho o primeiro dele foi alcançando,por meio de um simulador em que se conseguiu implantar a tecnologia MPLS–TE numarede WAN. Com isso, foi verificado que a engenharia de tráfego realiza a distribuição dotráfego na rede por meio de túneis. O MPLS forneceu os requisitos desejados de diminuir àvulnerabilidade a falha e facilitou o processo de implantação de VPNs. Por fim, o requisitode aplicar QoS também foi atendido. Houve todo um processo no momento de implantaçãodesse trabalho para classificar e oferecer tratamento diferenciado para os diversos tipos detráfego.

Para trabalhos futuros sugere-se primeiramente estudar a tecnologia FRR paradiminuir o tempo de recuperação da rede para 50 msec. Caso não seja possível, deve-seestudar e implantar outra tecnologia capaz de reduzir esse tempo. Pois, no cenário real, otempo durante o qual a rede fica indisponível acarreta em uma série de consequências. Porexemplo, há um contrato estabelecido entre o cliente e a operadora de serviços de dados, eexiste um tempo máximo que a rede pode ficar indisponível, assim, caso se extrapole essetempo, pode haver multa ou quebra de contrato.

A segunda sugestão é utilizar os códigos contidos no Apêndice C e realizar maistestes. Principalmente sobre como configurar vários túneis e gerar diversos tráfegos comclasses de tráfegos diferentes e verificar o desempenho desses tráfegos nesse cenário. Porfim, estudar sobre como aplicar DS–TE na rede WAN. Para realizar vários testes sobreas diferentes formas de configurar o DS–TE, para comprovar qual delas possui o melhordesempenho para rede WAN.

102

Referências

ANDERSSON, I. M. e. B. T. L. LDP Specification. 2007. Citado na página 38.

ASHR, J. Max Allocation with Reservation Bandwidth Constraints Model forDiffserv-aware MPLS Traffic Engineering Performance Comparisons. 2005. Citado napágina 59.

AWDUCHE., D. et al. Requirements for Traffic Engineering Over MPLS. 1999. Citadona página 42.

AWDUCHE., D. et al. Overview and Principles of Internet Traffic Engineering. 2002.Citado 2 vezes nas páginas 26 e 27.

AWDUCHE., D. et al. Requirements for Traffic Engineering Over MPLS. 2009. Citado 2vezes nas páginas 25 e 26.

BASSIL, R. C. Garantindo qualidade de serviço através da engenharia de tráfego emredes mpls. Curitiba, 2013. Citado na página 34.

BOAVA, A. Estratégia de projeto de vpn mpls com qualidade de serviço (qos). Campinas,Brasil: Unicamp, 2004. Citado 3 vezes nas páginas 49, 51 e 74.

BRADEN L. ZHANG, S. B. S. H. e. S. J. R. Resource ReSerVation Protocol (RSVP).[S.l.], 1997. 1-112 p. Citado na página 45.

BUBNOV, D. VRF, MPLS and MPBGP Fundamentals. 2016. Disponível em:<https://www.slideshare.net/bubnovd/vrf-mpls-and-mpbgp-fundamentals>. Acesso em:27 de julho de 2017. Citado 2 vezes nas páginas 9 e 52.

CARDOSO, F. C. Conceitos de rede virtual privada para streaming seguro de vídeo.Universidade São Franscisco, 2010. Citado na página 48.

CECHIN, S. L. Encapsulando Frames Ethernet em Conexões MPLS. Tese (Doutorado) —UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL, 2008. Citado na página 35.

CECHIN, S. L. Métricas para Avaliação de Desempenho em Redes QoS sobre IP. Tese(Doutorado) — UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL, 2008. Citadona página 29.

CHISTE, J. G. S. Diferenciação de tráfego usando roteador Linux. Dissertação (Mestrado)— Universidade d Federal de Santa Catarina, 2004. Citado na página 23.

CISCO. MPLS Traffic Engineering—DiffServ Aware (DS-TE). [S.l.], s.d. Citado napágina 60.

DATACOM. Treinamento de Configurações, Operações e Manutenção da Linha deequipamentos Switches Ethernet. Rua América, 1000 - Eldorado do Sul, RS -Brasil, s.d.Citado 3 vezes nas páginas 36, 38 e 55.

DIAS, R. A.; CATARINA, S. Serviços diferenciados baseado na tecnologia mpls em redesheterogêneas. CEP, v. 88020, p. 300, 2004. Citado na página 57.

https://www.slideshare.net/bubnovd/vrf-mpls-and-mpbgp-fundamentals

Referências 103

DOTTI, F. L. RSVP -Resource reSerVation Protocol. 2004. Disponível em:<http://www.inf.pucrs.br/~fldotti/redes/aulas/rsvp.pdf>. Acesso em: 10 de novembro de2016. Citado na página 45.

F, K. J.; ROSS. Redes de computadores: uma abordagem top-down. [S.l.]: Person, 2010.Citado 9 vezes nas páginas 43, 44, 48, 49, 51, 53, 55, 57 e 58.

FALSARELLA, D. Implementação mpls te. iMasters, 2008. Citado na página 71.

FARREL, A.; BRYSKIN, I. GMPLS: architecture and applications. [S.l.]: Academic Press,2005. Citado na página 39.

FAUCHEUR. et al. RFC 3270: Multi-protocol Label Switching (MPLS) support fordifferentiated services. 2002. Citado na página 58.

FAUCHEUR, F. L. Protocol Extensions for Support of Diffserv-aware MPLS TrafficEngineering. 2005. Citado na página 59.

FERREIRA, M. V. A. classificação dos fluxos de voz baseado na importância da chamada.Dissertação (Mestrado) — Universidade Federal Fluminense- Centro Tecnológico, 2009.Citado na página 57.

FILHO, C. A. de M. V.; MOREIRA, T. S. Um estudo de vpns layer 3 mpls-basedutilizando multiprotocol bgp. 2016. Citado na página 49.

FOROUZAN, B. A. Comunicação de dados e redes de computadores. [S.l.]: AMGHEditora, 2009. Citado 6 vezes nas páginas 31, 53, 56, 57, 58 e 85.

GAMA, Ó.; CARVALHO, P.; LIMA, S. Estabelecimento e utilização de uma plataformadiffserv gerida por um bandwidth broker. FCCN, 2003. Citado na página 58.

GHEIN, L. MPLS fundamentals: forwarding labeled packets. [S.l.]: Cisco Press, USA, 2007.Citado 2 vezes nas páginas 73 e 100.

GILADI, R. Network processors: architecture, programming, and implementation. [S.l.]:Morgan Kaufmann, 2008. Citado na página 35.

GIRISH, M. K.; ZHOU, B.; HU, J.-Q. Formulation of the traffic engineering problems inmpls based ip networks. In: IEEE. Computers and Communications, 2000. Proceedings.ISCC 2000. Fifth IEEE Symposium on. [S.l.], 2000. p. 214–219. Citado na página 27.

GNS3. what is GNS3? s.d. Disponível em: <https://gns3.com/software>. Acesso em: 15de junho de 2017. Citado na página 63.

GOMES, K. D. D. C. Análise bidimensiona dos efeitos das descargas atmosféricas emcabos OPGW utilizando o método ADI-FDTD. Dissertação (Mestrado) — UniversidadeFederal Do PARÁ, aug 2013. Citado na página 21.

HEADQUARTERS, A. Cisco ios switching services configuration guide, release 12.2. 2010.Disponível em: <http://www.cisco.com/c/en/us/td/docs/ios/12_2/switch/configuration/guide/fswtch_c/xcftagov.html>. Acesso em: 13 de maio de 2017. Citado na página 66.

HOFMANN, M.; BEAUMONT, L. R. Content networking: architecture, protocols, andpractice. [S.l.]: Elsevier, 2005. 320, tradução nossa p. Citado na página 29.

http://www.inf.pucrs.br/~fldotti/redes/aulas/rsvp.pdf

https://gns3.com/software

http://www.cisco.com/c/en/us/td/docs/ios/12_2/switch/configuration/guide/fswtch_c/xcftagov.html

http://www.cisco.com/c/en/us/td/docs/ios/12_2/switch/configuration/guide/fswtch_c/xcftagov.html

Referências 104

HÜMMELGEN, M. L.; FONSECA, K. V. Redes TCP/IP Integradas e a Garantia deQualidade de Serviço em Aplicações Multimídia. 2006. Citado na página 31.

INC, C. S. Cisco ASR 9000 Series Aggregation Services Router MPLS ConfigurationGuide, Release 4.3.x. [S.l.], 2013. 1-320 p. Disponível em: <http://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k_r4-3/mpls/configuration/guide/b_mpls_cg43xasr9k.pdf>. Acesso em: 08 de outubro de 2016. Citado 2 vezes nas páginas 9 e 47.

JR, J. A. S. Policiamento de trÁfego para controle de retardo e tamanho mÉdio da filaem sistemas ofdm/tdma. In: Anais do XIX Congresso Brasileiro de Automática. [S.l.: s.n.],2012. Citado na página 54.

LAI, W.; FAUCHEUR, F. L. Requirements for support of differentiated services-awareMPLS traffic engineering. 2003. Citado na página 59.

LEMOS, F. Metodologia de Organizações Virtuais Aplicada ao Desenvolvimento doProduto em Empresas de Grande Porte. Tese (Doutorado), 2007. Citado na página 48.

MAIA, N. A. Engenharia de Tráfego em domínio MPLS utilizando técnicas de InteligênciaComputacional. Tese (Doutorado) — Universidade Federal de Minas Gerais, 2006. Citado2 vezes nas páginas 23 e 29.

MANAYYA, K. Constrained shortest path first. 2010. Citado na página 44.

MENDONÇA JOSE MARIO OLIVEIRA, R. D. L. R. Redes MPLS - fundamentos eaplicações. [S.l.]: BRASPORT, 2012. Citado 7 vezes nas páginas 31, 37, 42, 43, 52, 54 e 55.

MINEI, I.; LUCEK, J. MPLS-enabled applications: emerging developments and newtechnologies. [S.l.]: John Wiley & Sons, 2010. Citado na página 32.

MÜLLER, M. D. et al. Uma solução de autenticação fim a fim para o ldp (labeldistribution protocol). Florianópolis, SC, 2002. Citado 2 vezes nas páginas 39 e 40.

NABAS, K. K. Proposta de um modelo de análise se desempenho de um escalonador wfqalimentado com um tráfego lrd. 2009. Citado na página 55.

NETIRON, B. Multiprotocol Label Switch (MPLS) Configuration Guide. [S.l.], s.d. Citadona página 44.

PÁDUA, F. J. et al. Roteamento e atribuição de λs em redes gmlps/dwdm. Citado napágina 37.

PAIXÃO, V. J. dos R. et al. Politicas e mecanismos de engenharia de trafego para redesMPLS/DS. Dissertação (Mestrado) — Universidade Estadual de Campinas, 2007. Citado2 vezes nas páginas 26 e 35.

PJSIP. [pjsip] PJUSA: Call summary. 2009. Disponível em: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/2009-April/007018.html>. Acesso em: 03 de junho de2017. Citado na página 85.

PURIFICAÇÃO, C. S. d. MPLS como suporte à engenharia de tráfego em ambiente comdiferenciação de serviço. Dissertação (Mestrado) — Universidade Federal de Pernambuco,2002. Citado 2 vezes nas páginas 23 e 45.

http://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k_r4-3/mpls/configuration/guide/b_mpls_cg43xasr9k.pdf



http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/2009-April/007018.html

http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/2009-April/007018.html

Referências 105

REALE, R. F. et al. Uma visão tutorial dos modelos de alocação de banda (bam–bandwidht allocation models) como mecanismo de provisionamento de recursos em redesip/mpls/ds-te. Revista de Sistemas e Computação-RSC, v. 5, n. 2, 2016. Citado napágina 60.

REALE, R. F.; NETO, W. da C.; MARTINS, J. S. Modelo de alocação de bandacom compartilhamento oportunista entre classes de tráfego e aplicações em redesmultiserviço. SIMPÓSIO BRASILEIRO DE REDES DE COMPUTADORES ESISTEMAS DISTRIBUÍDOS-SBRC, v. 29, 2011. Citado na página 60.

REALE, R. F. et al. Allocct-sharing-um modelo oportunístico de alocação de banda pararedes ds-te. Universidade Salvador, 2011. Citado 4 vezes nas páginas 57, 58, 59 e 60.

REKHTER, T. L. e. S. H. Y. A Border Gateway Protocol 4 (BGP-4). 2006. Citado napágina 51.

REQUEST., S. B. et al. An Architecture for Differentiated Services. 1998. Citado napágina 23.

RESENDE, R. A. Roteamento de trafego adaptativo baseado em caminho minimo em redesMPLS. Dissertação (Mestrado) — Universidade Estadual de Campinas, 2001. Citado napágina 28.

ROCHOL, J. et al. Caracterização e conformação de fluxos de tráfego atm no ambiente deusuário. 2001. Citado na página 56.

ROSEN, A. V. e. R. C. E. Multiprotocol Label Switching Architecture. 2001. Citado 3vezes nas páginas 33, 36 e 37.

ROSEN, E. BGP/MPLS IP Virtual Private Networks (VPNs). [S.l.], 2006. 1-47 p.Citado na página 74.

S, B.; FARREL, A. MPLS: next steps. [S.l.]: Morgan Kaufmann, 2008. v. 1. Citado 4vezes nas páginas 31, 48, 50 e 60.

SANTANA, H. Qualidade de serviço (qos) em redes ip princípios básicos, parâmetrose mecanismos. Cursos de Telecom e Telemática, Universidade Santa Cecília-Unisanta,Brasil, 2006. Citado na página 54.

SANTOS, R. C. d. et al. Um estudo do uso da tecnologia mpls em backbones no brasil.Florianópolis, SC, 2003. Citado 2 vezes nas páginas 11 e 36.

SAWANT, A. R.; QADDOUR, J. Mpls diffserv: a combined approach. Illinois StateUniversity, Citeseer, 2003. Citado na página 59.

TOMBI, R. G. Proposta de extensão do protocolo PCE considerando parâmetros de QoTpara roteamento inter-domínios em redes GMPLS. Tese (Doutorado) — Universidade deSão Paulo, 2007. Citado na página 44.

VASCONCELOS, M. F.; SALLES, R. M. Emprego de resiliência na gerência de redes decomputadores. Anais do XXX Simpósio Brasileiro de Redes de Computadores e SistemasDistribuıdos, p. 596–609, 2012. Citado na página 28.

Referências 106

VIEIRA, W. V. Mobilidade com o protocolo sip: Concepç ao de uma plataforma de testese analise de cenarios. 2010. Citado na página 85.

WARNOCK, G.; NATHOO, A. Alcatel-Lucent Network Routing Specialist II (NRS II)Self-Study Guide: Preparing for the NRS II Certification Exams. [S.l.]: John Wiley &Sons, 2011. Citado na página 43.

XIAO, L. N. X. Internet qos: a big picture. IEEE Networks Magazine, v. 13, s.d. Citadona página 28.

Apêndices

108

APÊNDICE A – Tabela de conversão doDSCP

DSCP Precedência IPCS1, AF11, AF12 e AF13 1CS2, AF21, AF22 e AF23 2CS3, AF31, AF32 e AF33 3CS4,AF41,AF42,AF43 4

CS5 5CS6 6CS7 7

BE (melhor esforço) 0

Tabela 14 – Conversão do DSCP para nível de precedência.

109

APÊNDICE B – Resultados do Cliente04

Figura 44 – Gráfico das taxas do tráfego de melhor esforço para o Cenário3 para o Cli-ente04.

Período entreperdas (msec) Jitter (msec)

RX TX RX TXCenário 3Cliente 04 media dev média dev média dev media dev

iperf: 1Mbps 0 0 0 0 22.052 7.385 19.394 7.206iperf: 2Mbps 0 0 36.667 13.743 20.943 3.934 16.056 4.770iperf: 3Mbps 260 0 181.852 52.525 27.074 5.152 21.685 6.371

Tabela 15 – Dados dos relatórios do PJSUA do Cliente4 para o Cenário 3.

110

APÊNDICE C – Configuração dosroteadores

C.1 Explicação dos comandos de configuração

Comando Explicaçãoip vrf [nome da VPN:] Associasse VRF a VPNrd [número do AS] : [número da VRF]: Identificador do domínio AS e da VRFroute-target export [AS]:[número da VRF]:route-target import [AS]:[número da VRF]:

Habilita a importação e/ou exportaçãoda VRF para comunidade BGP

Tabela 16 – Configuração do VRF com VPN.

Comando Explicaçãoip cef: Habilita a tecnologia CEFmpls traffic-eng tunnels: Habilita globalmente MPLS-TE

mpls label protocol ldp: Habilita o protocolo LDP para distribuição dos rótulos

Tabela 17 – Configuração dos comandos globais.

Comando Explicaçãoint Loopback0 : Identifica a interface deLoopbackip address [número do IP] [máscara]: Determina o endereço IP e máscara

no shutdown: Habilita a interface

Tabela 18 – Configuração para interface loopback.

Comando Explicaçãoint [nome e número da interface]: Identifica a interfaceip address [número do IP] [máscara] Determina o endereço IP e máscara

no shutdown Habilita a interface

service-policy input [nome]: Realiza politica de serviço de entradaip vrf forwarding [nome da VPN]: Associa a interface à VPN

Tabela 19 – Configuração para interface que se conecta ao cliente.

APÊNDICE C. Configuração dos roteadores 111

Comando Explicaçãoint [nome e número da interface]: Identifica a interfaceip address [número do IP] [máscara]: Determina o endereço IP e máscarano shutdown: Habilita a interfacempls ip: Habilita MPLS para a interfacempls traffic-eng tunnels: Habilita MPLS-TE para a interface

ip rsvp bandwidth [total] [único fluxo]:Define a largura de banda máxima que podeser reservada para a interface e para umúnico fluxo de dados em kbps.

service-policy output [nome]: Realiza politica de serviço de saída

Tabela 20 – Configuração para interface que se conecta ao LER.

Comando Explicaçãorouter ospf [número]: Identifica o OSPF

mpls traffic-eng router-id Loopback0: A TE utiliza o endereço da interfacede Loopback como identificação

mpls traffic-eng area [número]: A TE é aplicada para a área determinada

network [IP da rede] [mascará]area [número da área]:

Indica que o roteador será identificadopelo endereço da interface Loopback

Tabela 21 – Configuração do OSPF-TE.


Comando Explicaçãorouter bgp [AS] : Identifica a interfaceno synchronization: Desativa a sincronização do BGPredistribute static: Rotas estáticas entre cliente e PEneighbor [IP do PE de destino]remote-as [AS]:

Define qual sistema autonomo o PE évizinho

neighbor [IP do PE de destino]update-source Loopback0: Define o endereço de Loopback de PE

neighbor [IP do PE de destino]next-hop-self:

Força o BGP que este endereço comopróximo salto

no auto-summary: Habilita o transporte de sub-redes pelo BGPaddress-family vpnv4: Habilita endereçamento VPNv4neighbor [IP do PE de destino]activate:

Habilita para endereçamento VPNv4para os vizinhos

neighbor [IP do PE de destino]send-community extended:

Habilita o envio dos atributos VPNv4 paraos vizinhos

neighbor [IP do PE de destino]next-hop-self:

Força o BGP que este endereço comopróximo salto, por endereçamento VPNv4

exit-address-family: Sai da configuração do endereçamento VPNv4address-family ipv4vrf [nome da VPN]:

Define os parâmetros BGP, VRF paraendereçamento IPv4

redistribute connected: Distribui a tabela VRF BGP para os conectadosdiretamente

redistribute static: Distribui rotas estáticas VRF para a tabela VRF BGPneighbor [IP do CE de destino]remote-as [AS]: Define qual sistema autônomo o CE pertence

neighbor [IP do CE de destino]update-source[interface PE do conectada CE]:

Define qual interface o CE se conecta ao PE

neighbor [IP do CE de destino]activate: Habilita o CE

neighbor [IP do CE de destino]next-hop-self: Força o BGP a este endereço como próximo salto

no synchronization: Desativa a sincronização do BGPexit-address-family: Sai da configuração da VRFip route vrf [nome da VPN][endereço IP Loopback do CE][mascara] [endereço IP do PE]:

Define qual é o outro PE da VPN que não está conectadodiretamente a esse PE.

Tabela 22 – Configuração do BGP e da VPN.


Comando Explicaçãointerface Tunnel[número do túnel]: Identificação do túnel

ip unnumbered [interface de Loopback]: Define que não há nenhum endereço IP,vinculada aquela interface Loopback

tunnel destination [IP de destino]: Define o destino do túnel

tunnel mode mpls traffic-eng: Túnel encapsula no molo MPLS-TE

tunnel mpls traffic-eng autoroute announce: Determina que o cálculo do caminho do túneldeve-se ser por CSPF

tunnel mpls traffic-eng priority\[de configuração][prioridade de espera]:

Prioridade de configuração: para o processo deestabelecimento do túnel (tomada de recursos);Prioridade de espera: quando o túnel já estáestabelecido (retenção de recursos);Prioridade varia de [0-7], onde 0 é demaior prioridade

tunnel mpls traffic-eng bandwidth\[velocidade kbps]: Define a largura de banda do túnel em kbps

tunnel mpls traffic-eng path-option[identificação] [ dynamic/explicit]:

Define se o encaminhamento é dinâmico ouexplicito e atribui uma identificação.

Tabela 23 – Configuração do túnel da engenharia de tráfego.

Comando Explicaçãoaccess-list [identificação]permit [protocolo]host [endereço IP origem] any:

Lista de acesso é um filtro que só aceita os pacotes quepossuem essa origem e esse protocolo

class-map match-all [nome]: Classifica todos os pacotes que possuem todos os requsitos,que são determinados a seguir

match ip precedence [número]: Classifica por nível de precedência IPmatch protocol [protocolo]: Classifica de acordo com o protocolomatch access-group [nome]: Classifica de acordo com a lista de acesso protocolomatch mpls experimentaltopmost [número]:

Classifica de acordo com o valor do campo EX docabeçalho do MPLS

Tabela 24 – Configurações possíveis para a classificação.

Comando Explicaçãopolicy-map [nome]: Identificação da política de serviçoclass [nome]: Identificação da classe

police cir percent [número] bc [número] msbe [número] ms:

Determina a taxa média de transmissãoem relação a largura de bandaBC: número de bits enviados em cadaintervalo;BE: número máximo de bits enviados emcada intervalo;

conform-action set-mpls-exp-imposition-transmit[valor do campo EX]:

Valor do campo EX do cabeçalho MPLS parao trafego que adéqua ao policiamento

exceed-action set-mpls-exp-imposition-transmit[valor do campo EX]:

Valor do campo EX do cabeçalho MPLS para otráfego que não se adéqua ao policiamento

Tabela 25 – Configurações para marcação e policiamento de tráfego.


Comando Explicaçãopolicy-map [nome]: Identificação da política de serviçoclass [nome]: Identificação da classebandwidth percent [número] Reserva a largura de banda mínima para a classe

shape average percent [número] Determina o limite máximo da taxa de transmissãoda interface

Tabela 26 – Configurações para condicionamento de tráfego e reserva da largura de banda.

C.2 Configuração do roteador R111 hostname Roteador112

3 ip vrf VPN_B4 rd 65500:25 route - target export 65500:26 route - target import 65500:27

8 ip cef9 mpls traffic -eng tunnels

10 mpls label protocol ldp11

12 interface Loopback013 ip address 192.168.0.1 255.255.255.25514 no shutdown15 exit16

17 int f2/118 ip address 10.0.83.2 255.255.255.019 no shutdown20 service - policy input Input - policy21 service - policy output Output - policy22 ip vrf forwarding VPN_B23 exit24

25 int f1/026 ip address 192.168.90.1 255.255.255.027 no shutdown28 mpls ip29 mpls traffic -eng tunnels30 ip rsvp bandwidth 4000 400031 service - policy output Core - policy32 exit33

34 int f1/135 ip address 192.168.98.1 255.255.255.036 no shutdown


37 mpls ip38 mpls traffic -eng tunnels39 ip rsvp bandwidth 4000 400040 service - policy output Core - policy41 exit42


52 router ospf 153 mpls traffic -eng router -id Loopback054 mpls traffic -eng area 055 network 192.168.0.0 0.0.255.255 area 056 network 10.0.83.0 0.0.0.255 area 357 exit58

59 router bgp 6550060 no synchronization61 redistribute static62 neighbor 192.168.0.5 remote -as 6550063 neighbor 192.168.0.5 update - source Loopback064 neighbor 192.168.0.5 next -hop -self65 no auto - summary66 address - family vpnv467 neighbor 192.168.0.5 activate68 neighbor 192.168.0.5 send - community extended69 neighbor 192.168.0.5 next -hop -self70 exit -address - family71 address - family ipv4 vrf VPN_B72 redistribute connected73 redistribute static74 neighbor 10.0.83.1 remote -as 20075 neighbor 10.0.83.1 update - source FastEthernet2 /176 neighbor 10.0.83.1 activate77 neighbor 10.0.83.1 next -hop -self78 no synchronization79 exit -address - family80 exit81

82 ip route vrf VPN_B 200.2.0.3 255.255.255.255 10.0.83.183


84 interface Tunnel30285 ip unnumbered Loopback086 tunnel destination 192.168.0.587 tunnel mode mpls traffic -eng88 tunnel mpls traffic -eng autoroute announce89 tunnel mpls traffic -eng priority 0 090 tunnel mpls traffic -eng bandwidth 200091 tunnel mpls traffic -eng path - option 1 dynamic92

93 access -list 130 permit 0 host 10.0.83.1 any94 access -list 133 permit udp host 10.0.83.1 any95

96 class -map match -all AlfaInput97 match ip precedence 1 2 3 498 match protocol ssh99 match access -group 130

100 class -map match -all BetaInput101 match ip precedence 5 6 7102 match protocol ssh103 match access -group 130104 class -map match -all GamaInput105 match ip precedence 1 2 3 4106 match protocol ping107 match access -group 130108 class -map match -all DeltaInput109 match ip precedence 5 6 7110 match protocol ping111 match access -group 130112 class -map match -all EpsilionInput113 match ip precedence 1 2 3 4114 match protocol rtp115 match access -group 133116 class -map match -all ZetaInput117 match ip precedence 6 5 7118 match protocol rtp119 match access -group 133120 class -map match -any Alfa121 match mpls experimental topmost 1122 class -map match -any Beta123 match mpls experimental topmost 2124 class -map match -any Gama125 match mpls experimental topmost 3126 class -map match -any Delta127 match mpls experimental topmost 4128 class -map match -any Epsilion129 match mpls experimental topmost 5130 class -map match -any Zeta


131 match mpls experimental topmost 6132 class -map match -any Eta133 match mpls experimental topmost 7134 exit135

136 policy -map Input - policy137 class AlfaInput138 set mpls experimental imposition 1139 police cir percent 12 bc 300 ms be 400 ms140 conform - action set -mpls -exp -imposition - transmit 1141 exceed - action set -mpls -exp -imposition - transmit 1142 class BetaInput143 set mpls experimental imposition 2144 police cir percent 12 bc 300 ms be 400 ms145 conform - action set -mpls -exp -imposition - transmit 2146 exceed - action set -mpls -exp -imposition - transmit 1147 class GamaInput148 set mpls experimental imposition 3149 police cir percent 12 bc 300 ms be 400 ms150 conform - action set -mpls -exp -imposition - transmit 3151 exceed - action set -mpls -exp -imposition - transmit 2152 class DeltaInput153 set mpls experimental imposition 4154 police cir percent 12 bc 300 ms be 400 ms155 conform - action set -mpls -exp -imposition - transmit 4156 exceed - action set -mpls -exp -imposition - transmit 3157 class EpsilionInput158 set mpls experimental imposition 5159 police cir percent 12 bc 300 ms be 400 ms160 conform - action set -mpls -exp -imposition - transmit 5161 exceed - action set -mpls -exp -imposition - transmit 4162 class ZetaInput163 set mpls experimental imposition 6164 police cir percent 12 bc 300 ms be 400 ms165 conform - action set -mpls -exp -imposition - transmit 6166 exceed - action set -mpls -exp -imposition - transmit 5167 class class - default168 set mpls experimental imposition 0169 exit170

171 policy -map Core - policy172 class Alfa173 bandwidth percent 10174 shape average percent 12175 class Beta176 bandwidth percent 10177 shape average percent 12


178 class Gama179 bandwidth percent 10180 shape average percent 12181 class Delta182 bandwidth percent 10183 shape average percent 12184 class Epsilion185 bandwidth percent 10186 shape average percent 12187 class Zeta188 bandwidth percent 10189 shape average percent 12190 class Eta191 bandwidth percent 10192 shape average percent 12193 class class - default194 fair -queue195 random - detect196 exit

RoteadorR11.cfg


3 ip cef4 mpls traffic -eng tunnels5 mpls label protocol ldp6

7 interface Loopback08 ip address 192.168.0.2 255.255.255.2559 no shutdown

10 exit11


21 int f1/122 ip address 192.168.91.2 255.255.255.0


23 mpls ip24 mpls traffic -eng tunnels25 ip rsvp bandwidth 4000 400026 service - policy output Core - policy27 exit28


38 router ospf 139 mpls traffic -eng router -id Loopback040 mpls traffic -eng area 041 network 192.168.0.0 0.0.255.255 area 042 exit43

44 class -map match -any Alfa45 match mpls experimental topmost 146 class -map match -any Beta47 match mpls experimental topmost 248 class -map match -any Gama49 match mpls experimental topmost 350 class -map match -any Delta51 match mpls experimental topmost 452 class -map match -any Epsilion53 match mpls experimental topmost 554 class -map match -any Zeta55 match mpls experimental topmost 656 class -map match -any Eta57 match mpls experimental topmost 758 exit59

60 policy -map Core - policy61 class Alfa62 bandwidth percent 1063 shape average percent 1264 class Beta65 bandwidth percent 1066 shape average percent 1267 class Gama68 bandwidth percent 1069 shape average percent 12


70 class Delta71 bandwidth percent 1072 shape average percent 1273 class Epsilion74 bandwidth percent 1075 shape average percent 1276 class Zeta77 bandwidth percent 1078 shape average percent 1279 class Eta80 bandwidth percent 1081 shape average percent 1282 class class - default83 fair -queue84 random - detect85 exit

RoteadorR12.cfg




10 exit11


21 int f2/022 ip address 192.168.94.3 255.255.255.023 no shutdown24 mpls ip25 mpls traffic -eng tunnels


26 ip rsvp bandwidth 4000 400027 service - policy output Core - policy28 exit29



52 policy -map Core - policy53 class Alfa54 bandwidth percent 1055 shape average percent 1256 class Beta57 bandwidth percent 1058 shape average percent 1259 class Gama60 bandwidth percent 1061 shape average percent 1262 class Delta63 bandwidth percent 1064 shape average percent 1265 class Epsilion66 bandwidth percent 1067 shape average percent 1268 class Zeta69 bandwidth percent 1070 shape average percent 1271 class Eta72 bandwidth percent 10


73 shape average percent 1274 class class - default75 fair -queue76 random - detect77 exit

RoteadorR13.cfg




10 exit11




36 class -map match -any Alfa


37 match mpls experimental topmost 138 class -map match -any Beta39 match mpls experimental topmost 240 class -map match -any Gama41 match mpls experimental topmost 342 class -map match -any Delta43 match mpls experimental topmost 444 class -map match -any Epsilion45 match mpls experimental topmost 546 class -map match -any Zeta47 match mpls experimental topmost 648 class -map match -any Eta49 match mpls experimental topmost 750 exit51

52 policy -map Core - policy53 class Alfa54 bandwidth percent 1055 shape average percent 1256 class Beta57 bandwidth percent 1058 shape average percent 1259 class Gama60 bandwidth percent 1061 shape average percent 1262 class Delta63 bandwidth percent 1064 shape average percent 1265 class Epsilion66 bandwidth percent 1067 shape average percent 1268 class Zeta69 bandwidth percent 1070 shape average percent 1271 class Eta72 bandwidth percent 1073 shape average percent 1274 class class - default75 fair -queue76 random - detect77 exit

RoteadorR14.cfg

C.6 Configuração do roteador R15


1 hostname Roteador152

3 ip vrf VPN_B4 rd 65500:25 route - target export 65500:26 route - target import 65500:27




17 int f3/018 ip address 10.0.82.2 255.255.255.019 no shutdown20 service - policy input Input - policy21 service - policy output Output - policy22 ip vrf forwarding VPN_B23 exit24



43 int f2/144 ip address 192.168.100.5 255.255.255.045 no shutdown46 mpls ip47 mpls traffic -eng tunnels


48 ip rsvp bandwidth 4000 400049 service - policy output Core - policy50 exit51



68 router bgp 6550069 no synchronization70 redistribute static71 neighbor 192.168.0.1 remote -as 6550072 neighbor 192.168.0.1 update - source Loopback073 neighbor 192.168.0.1 next -hop -self74 no auto - summary75 address - family vpnv476 neighbor 192.168.0.1 activate77 neighbor 192.168.0.1 send - community extended78 neighbor 192.168.0.1 next -hop -self79 exit -address - family80 address - family ipv4 vrf VPN_B81 redistribute connected82 redistribute static83 neighbor 10.0.82.1 remote -as 20084 neighbor 10.0.82.1 update - source FastEthernet3 /085 neighbor 10.0.82.1 activate86 neighbor 10.0.82.1 next -hop -self87 no synchronization88 exit -address - family89 exit90

91 ip route vrf VPN_B 200.2.0.2 255.255.255.255 10.0.82.192

93 interface Tunnel20394 ip unnumbered Loopback0


95 tunnel destination 192.168.0.196 tunnel mode mpls traffic -eng97 tunnel mpls traffic -eng autoroute announce98 tunnel mpls traffic -eng priority 0 099 tunnel mpls traffic -eng bandwidth 2000

100 tunnel mpls traffic -eng path - option 1 dynamic101 exit102


106 class -map match -all AlfaInput107 match ip precedence 1 2 3 4108 match protocol ssh109 match access -group 120110 class -map match -all BetaInput111 match ip precedence 5 6 7112 match protocol ssh113 match access -group 120114 class -map match -all GamaInput115 match ip precedence 1 2 3 4116 match protocol ping117 match access -group 120118 class -map match -all DeltaInput119 match ip precedence 5 6 7120 match protocol ping121 match access -group 120122 class -map match -all EpsilionInput123 match ip precedence 1 2 3 4124 match protocol rtp125 match access -group 122126 class -map match -all ZetaInput127 match ip precedence 6 5 7128 match protocol rtp129 match access -group 122130 class -map match -any Alfa131 match mpls experimental topmost 1132 class -map match -any Beta133 match mpls experimental topmost 2134 class -map match -any Gama135 match mpls experimental topmost 3136 class -map match -any Delta137 match mpls experimental topmost 4138 class -map match -any Epsilion139 match mpls experimental topmost 5140 class -map match -any Zeta141 match mpls experimental topmost 6


142 class -map match -any Eta143 match mpls experimental topmost 7144 exit145


181 policy -map Core - policy182 class Alfa183 bandwidth percent 10184 shape average percent 12185 class Beta186 bandwidth percent 10187 shape average percent 12188 class Gama


189 bandwidth percent 10190 shape average percent 12191 class Delta192 bandwidth percent 10193 shape average percent 12194 class Epsilion195 bandwidth percent 10196 shape average percent 12197 class Zeta198 bandwidth percent 10199 shape average percent 12200 class Eta201 bandwidth percent 10202 shape average percent 12203 class class - default204 fair -queue205 random - detect206 exit

RoteadorR15.cfg


3 ip vrf VPN_A4 rd 65500:15 route - target export 65500:16 route - target import 65500:17




17 int f2/118 ip address 10.0.84.2 255.255.255.019 no shutdown20 service - policy input Input - policy21 service - policy output Output - policy22 ip vrf forwarding VPN_A23 exit


24




50 router bgp 6550051 no synchronization52 redistribute static53 neighbor 192.168.0.7 remote -as 6550054 neighbor 192.168.0.7 update - source Loopback055 neighbor 192.168.0.7 next -hop -self56 no auto - summary57 address - family vpnv458 neighbor 192.168.0.7 activate59 neighbor 192.168.0.7 send - community extended60 neighbor 192.168.0.7 next -hop -self61 exit -address - family62 address - family ipv4 vrf VPN_A63 redistribute connected64 redistribute static65 neighbor 10.0.84.1 remote -as 10066 neighbor 10.0.84.1 update - source FastEthernet2 /167 neighbor 10.0.84.1 activate68 neighbor 10.0.84.1 next -hop -self69 no synchronization70 exit -address - family


71 exit72

73 ip route vrf VPN_A 200.1.0.4 255.255.255.255 10.0.84.174

75 interface Tunnel40176 ip unnumbered Loopback077 tunnel destination 192.168.0.778 tunnel mode mpls traffic -eng79 tunnel mpls traffic -eng autoroute announce80 tunnel mpls traffic -eng priority 0 081 tunnel mpls traffic -eng bandwidth 200082 tunnel mpls traffic -eng path - option 1 dynamic83 exit84


88 class -map match -all AlfaInput89 match ip precedence 1 2 3 490 match protocol ssh91 match access -group 14092 class -map match -all BetaInput93 match ip precedence 5 6 794 match protocol ssh95 match access -group 14096 class -map match -all GamaInput97 match ip precedence 1 2 3 498 match protocol ping99 match access -group 140

100 class -map match -all DeltaInput101 match ip precedence 5 6 7102 match protocol ping103 match access -group 140104 class -map match -all EpsilionInput105 match ip precedence 1 2 3 4106 match protocol rtp107 match access -group 144108 class -map match -all ZetaInput109 match ip precedence 6 5 7110 match protocol rtp111 match access -group 144112 class -map match -any Alfa113 match mpls experimental topmost 1114 class -map match -any Beta115 match mpls experimental topmost 2116 class -map match -any Gama117 match mpls experimental topmost 3


118 class -map match -any Delta119 match mpls experimental topmost 4120 class -map match -any Epsilion121 match mpls experimental topmost 5122 class -map match -any Zeta123 match mpls experimental topmost 6124 class -map match -any Eta125 match mpls experimental topmost 7126 exit127


163 policy -map Core - policy164 class Alfa


165 bandwidth percent 10166 shape average percent 12167 class Beta168 bandwidth percent 10169 shape average percent 12170 class Gama171 bandwidth percent 10172 shape average percent 12173 class Delta174 bandwidth percent 10175 shape average percent 12176 class Epsilion177 bandwidth percent 10178 shape average percent 12179 class Zeta180 bandwidth percent 10181 shape average percent 12182 class Eta183 bandwidth percent 10184 shape average percent 12185 class class - default186 fair -queue187 random - detect188 exit

RoteadorR16.cfg


3 ip vrf VPN_A4 rd 65500:15 route - target export 65500:16 route - target import 65500:17




17 int f2/1


18 ip address 10.0.81.2 255.255.255.019 no shutdown20 service - policy input Input - policy21 service - policy output Output - policy22 ip vrf forwarding VPN_A23 exit24




50 router bgp 6550051 no synchronization52 redistribute static53 neighbor 192.168.0.6 remote -as 6550054 neighbor 192.168.0.6 update - source Loopback055 neighbor 192.168.0.6 next -hop -self56 no auto - summary57 address - family vpnv458 neighbor 192.168.0.6 activate59 neighbor 192.168.0.6 send - community extended60 neighbor 192.168.0.6 next -hop -self61 exit -address - family62 address - family ipv4 vrf VPN_A63 redistribute connected64 redistribute static


65 neighbor 10.0.81.1 remote -as 10066 neighbor 10.0.81.1 update - source FastEthernet2 /167 neighbor 10.0.81.1 activate68 neighbor 10.0.81.1 next -hop -self69 no synchronization70 exit -address - family71 exit72

73 ip route vrf VPN_A 200.1.0.1 255.255.255.255 10.0.81.174

75 interface Tunnel10476 ip unnumbered Loopback077 tunnel destination 192.168.0.678 tunnel mode mpls traffic -eng79 tunnel mpls traffic -eng autoroute announce80 tunnel mpls traffic -eng priority 0 081 tunnel mpls traffic -eng bandwidth 200082 tunnel mpls traffic -eng path - option 1 dynamic83 exit84


88 class -map match -all AlfaInput89 match ip precedence 1 2 3 490 match protocol ssh91 match access -group 11092 class -map match -all BetaInput93 match ip precedence 5 6 794 match protocol ssh95 match access -group 11096 class -map match -all GamaInput97 match ip precedence 1 2 3 498 match protocol ping99 match access -group 110

100 class -map match -all DeltaInput101 match ip precedence 5 6 7102 match protocol ping103 match access -group 110104 class -map match -all EpsilionInput105 match ip precedence 1 2 3 4106 match protocol rtp107 match access -group 111108 class -map match -all ZetaInput109 match ip precedence 6 5 7110 match protocol rtp111 match access -group 111



128 policy -map Input - policy129 class AlfaInput130 set mpls experimental imposition 1131 police cir percent 12 bc 300 ms be 400 ms132 conform - action set -mpls -exp -imposition - transmit 1133 exceed - action set -mpls -exp -imposition - transmit 1134 class BetaInput135 set mpls experimental imposition 2136 police cir percent 12 bc 300 ms be 400 ms137 conform - action set -mpls -exp -imposition - transmit 2138 exceed - action set -mpls -exp -imposition - transmit 1139 class GamaInput140 set mpls experimental imposition 3141 police cir percent 12 bc 300 ms be 400 ms142 conform - action set -mpls -exp -imposition - transmit 3143 exceed - action set -mpls -exp -imposition - transmit 2144 class DeltaInput145 set mpls experimental imposition 4146 police cir percent 12 bc 300 ms be 400 ms147 conform - action set -mpls -exp -imposition - transmit 4148 exceed - action set -mpls -exp -imposition - transmit 3149 class EpsilionInput150 set mpls experimental imposition 5151 police cir percent 12 bc 300 ms be 400 ms152 conform - action set -mpls -exp -imposition - transmit 5153 exceed - action set -mpls -exp -imposition - transmit 4154 class ZetaInput155 set mpls experimental imposition 6156 police cir percent 12 bc 300 ms be 400 ms157 conform - action set -mpls -exp -imposition - transmit 6158 exceed - action set -mpls -exp -imposition - transmit 5


159 class class - default160 set mpls experimental imposition 0161 exit162

163 policy -map Core - policy164 class Alfa165 bandwidth percent 10166 shape average percent 12167 class Beta168 bandwidth percent 10169 shape average percent 12170 class Gama171 bandwidth percent 10172 shape average percent 12173 class Delta174 bandwidth percent 10175 shape average percent 12176 class Epsilion177 bandwidth percent 10178 shape average percent 12179 class Zeta180 bandwidth percent 10181 shape average percent 12182 class Eta183 bandwidth percent 10184 shape average percent 12185 class class - default186 fair -queue187 random - detect188 exit

RoteadorR17.cfg




10 exit11






52 policy -map Core - policy53 class Alfa54 bandwidth percent 1055 shape average percent 1256 class Beta57 bandwidth percent 1058 shape average percent 12


59 class Gama60 bandwidth percent 1061 shape average percent 1262 class Delta63 bandwidth percent 1064 shape average percent 1265 class Epsilion66 bandwidth percent 1067 shape average percent 1268 class Zeta69 bandwidth percent 1070 shape average percent 1271 class Eta72 bandwidth percent 1073 shape average percent 1274 class class - default75 fair -queue76 random - detect77 exit

RoteadorR18.cfg

wiki.sj.ifsc.edu.br · agradecimentos primeiramente agradeço a deus, por ter me dado forças para...

Documents