Estratgia de Projeto de VPNs MPLS com Qualidade de Servio A Ado Boava Dissertao de Mestrado

Instituto de Computao Universidade Estadual de Campinas

Estratgia de Projeto de VPN MPLS com Qualidade de Servio (QoS) Ado Boava
Junho de 2004

Banca Examinadora: Prof. Dr. Maurcio Ferreira de Magalhes (Orientador) Faculdade de Engenharia Eltrica, Unicamp. Prof. Dr. Edmundo Roberto Mauro Madeira Instituto de Computao, Unicamp. Prof. Dr. Leonardo de Souza Mendes Instituto de Computao, Unicamp.

ii

Estratgia de Projeto de VPN MPLS com Qualidade de Servio (QoS)

Este exemplar corresponde redao final da dissertao devidamente corrigida e defendida por Ado Boava e aprovada pela banca examinadora

Campinas, Junho de 2004

Maurcio Ferreira de Magalhes Faculdade de Engenharia Eltrica, Unicamp Orientador

Dissertao apresentada ao Instituto de Computao, Unicamp, como requisito parcial para obteno do ttulo de mestre em Cincia da Computao.

iii

 Ado Boava, 2004. Todos os direitos reservados.

iv

Dedicatria

in memoriam do meu pai

Agradecimentos
Deus, por eu existir e possibilitar realizar esse trabalho. Aos meus pais, Lidia e Jos Boava, minha esposa Suzana, ao Murillo, a Brbara e demais familiares pelo incentivo e apoio durante todo o trabalho. Ao Professor Maurcio Ferreira Magalhes pela sua orientao e amizade. Aos membros da banca, pela sua presena na banca examinadora. Aos funcionrios do instituto de computao da Unicamp.

vi

Contedo
Dedicatria ------------------------------------------------------------------------------------------------------------- v Agradecimentos ------------------------------------------------------------------------------------------------------ vi Contedo ------------------------------------------------------------------------------------------------------------- vii Lista de Figuras ------------------------------------------------------------------------------------------------------ xi Lista de Tabelas -----------------------------------------------------------------------------------------------------xiv Lista de Siglas ------------------------------------------------------------------------------------------------------- xv Resumo --------------------------------------------------------------------------------------------------------------xvii Abstract ---------------------------------------------------------------------------------------------------------------xix Captulo 1 Introduo --------------------------------------------------------------------------------------------- 1 1.1. Proposta do Trabalho -------------------------------------------------------------------------------------- 1 1.2. Contribuies e Trabalhos relacionados --------------------------------------------------------------- 2 1.3. Tendncias Mercadologica das VPN MPLS --------------------------------------------------------- 3 1.3.1 Tendncias das VPNs baseadas em Rede e CPE ----------------------------------------------------- 6 1.4. Estrutura do Trabalho -------------------------------------------------------------------------------------- 7 Captulo 2 Fundamentos Conceituais -------------------------------------------------------------------------- 8 2.1. O que uma VPN ------------------------------------------------------------------------------------------- 9 2.1.1 Definio de VPN Intranet e Extranet------------------------------------------------------------------ 9 2.2. Modelo Overlay ------------------------------------------------------------------------------------------- 12 2.3. Modelo Peer ------------------------------------------------------------------------------------------------ 16 2.3.1 Modelo com roteador compartilhado----------------------------------------------------------------- 17

vii

2.3.2 Modelo com roteador dedicado ----------------------------------------------------------------------- 17 2.3.3 Implementao do modelo Peer ---------------------------------------------------------------------- 18 2.3.3.1 Endereos VPN-IP ------------------------------------------------------------------------------ 19 2.3.3.2 MPLS --------------------------------------------------------------------------------------------- 19 2.4. RFC 2547 --------------------------------------------------------------------------------------------------- 21 2.4.1 Viso Geral ---------------------------------------------------------------------------------------------- 21 2.4.2 Implementao da RFC 2547------------------------------------------------------------------------- 23 2.4.2.1 Componentes de Rede -------------------------------------------------------------------------- 23 2.4.2.2 Modelo Operacional ---------------------------------------------------------------------------- 27 2.5. Implementando DiffServ em VPN MPLS ---------------------------------------------------------- 31 2.5.1 Arquitetura DiffServ------------------------------------------------------------------------------------ 34 2.5.2 PHBs DIffServ ------------------------------------------------------------------------------------------ 35 2.5.3 DiffServ e Pacotes IP ----------------------------------------------------------------------------------- 37 2.6. Benefcios das VPNs MPLS --------------------------------------------------------------------------- 37 2.7. Comparando as diversas tecnologias de VPNs ---------------------------------------------------- 39 2.8. Resumo do captulo --------------------------------------------------------------------------------------- 39 Captulo 3 Estratgia de implementao proposto -------------------------------------------------------- 41 3.1. Comparando: IPoATM, MPLS baseado em Roteador e MPLS baseado em Clula ------ 42 3.1.1 Questo de transio------------------------------------------------------------------------------------- 43 3.2. Passos ------------------------------------------------------------------------------------------------------- 46 3.2.1 Passo 1 Especificao dos requisitos dos aplicativos -------------------------------------------- 46 3.2.1.1 Caracterizao do trfego -------------------------------------------------------------------- 46 3.2.2 Passo 2 Diviso dos aplicativos em mltiplas classes ------------------------------------------- 49 3.2.2.1 BE Classe Padro Best Effort--------------------------------------------------------------- 50 3.2.2.2 AF Classe Dados com prioridade ---------------------------------------------------------- 50 3.2.2.3 EF Classe Tempo Real ---------------------------------------------------------------------- 52 3.2.2.4 Definio dos aplicativos e portas------------------------------------------------------------ 52 3.2.2.5 Mapeamento dos campos DSCP em EXP--------------------------------------------------- 53

viii

3.2.3 Passo 3 Determinao da tecnologia de acesso --------------------------------------------------- 54 3.2.3.1 Provendo acesso DSL para as VPNs MPLS ------------------------------------------------ 55 3.2.3.2 Fluxo para atendimento com vrias tecnologias de acesso para VPNs MPLS --------- 56 3.2.4 Passo 4 Determinao do CPE/CE ----------------------------------------------------------------- 57 3.2.4.1 Acessos sem QoS Classe BE --------------------------------------------------------------- 58 3.2.4.2 Acessos com QoS Classes AF e EF-------------------------------------------------------- 58 3.2.4.3 Mltiplas VPNs nos CEs (Multi VRFs CE) ---------------------------------------------- 59 3.2.5 Passo 5 Configurao da VPN MPLS ------------------------------------------------------------- 61 3.2.6 Passo 6 Teste de Conectividade e Isolamento ---------------------------------------------------- 61 3.2.7 Passo 7 Teste de QoS das VPNs MPLS ----------------------------------------------------------- 62 3.3. Resumo do captulo --------------------------------------------------------------------------------------- 62 Captulo 4 Configurao da VPN------------------------------------------------------------------------------ 63 4.1 Configurao da VPN MPLS-------------------------------------------------------------------------------- 63 4.1.1 Configurao dos roteadores virtuais ----------------------------------------------------------------- 65 4.1.2 Definir e configurar as rotas distinguishers e endereos VPN-IPv4 ------------------------------ 66 4.1.2.1 RDs e as famlias de endereos VPN-IPv4 ------------------------------------------------- 66 4.1.2.2 Configurao dos identificadores de rotas (RD) ------------------------------------------- 69 4.1.2.3 Rotas Targets------------------------------------------------------------------------------------ 70 4.1.2.4 Extranet ------------------------------------------------------------------------------------------ 71 4.1.3 Definio das polticas de importao e exportao das rotas------------------------------------- 72 4.1.4 Configurao do enlace CE-PE ------------------------------------------------------------------------ 72 4.1.5 Associao de interfaces CE nas VRFs definidas --------------------------------------------------- 75 4.1.6 Configurao do Multiprocolo BGP ------------------------------------------------------------------ 76 4.2. Resumo do captulo --------------------------------------------------------------------------------------- 76 Captulo 5 Testes e anlise dos resultados obtidos --------------------------------------------------------- 78 5.1. Classes de Servios Diferenciadas------------------------------------------------------------------------ 80 5.2. Organizao dos Testes ------------------------------------------------------------------------------------ 80 5.3. Recursos utilizados ----------------------------------------------------------------------------------------- 81

ix

5.4. Topologia de testes ----------------------------------------------------------------------------------------- 81 5.5. Teste de Conectividade ------------------------------------------------------------------------------------ 82 5.5.1 Teste de Conectividade Intra VPNs ------------------------------------------------------------------- 82 5.5.2 Teste de Isolamento de Trfego entre VPNs --------------------------------------------------------- 83 5.6. Teste de Qualidade de Servio ---------------------------------------------------------------------------- 85 5.6.1 Avaliao do QoS no CE ------------------------------------------------------------------------------- 85 5.6.2 Avaliao do QoS no PE------------------------------------------------------------------------------- 100 5.7. Resumo do Captulo --------------------------------------------------------------------------------------- 111 Captulo 6 Concluses e trabalhos futuros------------------------------------------------------------------ 112 7.1. Concluses -------------------------------------------------------------------------------------------------- 112 7.2. Trabalhos futuros ------------------------------------------------------------------------------------------ 113 Bibliografia ---------------------------------------------------------------------------------------------------------- 114 Anexo A Conceitos bsicos de BGP -------------------------------------------------------------------------- 118 Anexo B MPLS baseado em Roteador e MPLS baseado em Clula----------------------------------- 125 Anexo C Metodo de encapsulamento de xDSL ------------------------------------------------------------ 128 Anexo D Escolhendo o melhor protocolo de roteamento para as VPNs MPLS --------------------- 132

Lista de Figuras
Figura 1.1 Tendncias das VPNs IP baseadas em redes ou CPE ---------------------------------------------- 6 Figura 2.1 VPN BGP MPLS: Redes do usurios e backbone ----------------------------------------------- 10 Figura 2.2 Um novo subconjunto de polticas ------------------------------------------------------------------ 10 Figura 2.3 Uma terceira VPN criada--------------------------------------------------------------------------- 11 Figura 2.5 Viso geral de uma VPN MPLS--------------------------------------------------------------------- 12 Figura 2.5 Modelo Overlay --------------------------------------------------------------------------------------- 13 Figura 2.6 Modelo de roteador compartilhado ----------------------------------------------------------------- 17 Figura 2.7 Modelo de roteador dedicado ------------------------------------------------------------------------ 18 Figura 2.8 Controle e encaminhamento no MPLS ------------------------------------------------------------- 20 Figura 2.9 Cabealho MPLS -------------------------------------------------------------------------------------- 21 Figura 2.10 Componentes da VPN MPLS ---------------------------------------------------------------------- 23 Figura 2.11 Configurao de reflectores de rotas -------------------------------------------------------------- 24 Figura 2.12 Software normalmente suportado pelos PEs ----------------------------------------------------- 25 Figura 2.13 Uma VRF Criada ---------------------------------------------------------------------------------- 26 Figura 2.14 Componente de Rede-------------------------------------------------------------------------------- 27 Figura 2.15 Estabelecimento de LSP ---------------------------------------------------------------------------- 29 Figura 2.16 Fluxos de Dados ------------------------------------------------------------------------------------- 30 Figura 2.17 Arquitetura de domnio DiffServ ------------------------------------------------------------------ 34 Figura 2.18 Custo e complexidade de solues ---------------------------------------------------------------- 35 Figura 2.19 Classes AF -------------------------------------------------------------------------------------------- 36 Figura 3.1 Fluxo de formao de VPNs MPLS ---------------------------------------------------------------- 45

xi

Figura 3.2 Classificao das aplicaes ------------------------------------------------------------------------- 49 Figura 3.3 Efeito das perdas de pacotes ------------------------------------------------------------------------- 52 Figura 3.4 Formas de acessos tradicionais das redes VPN/MPLS------------------------------------------- 54 Figura 3.5 Formato do encapsulamento DSL------------------------------------------------------------------- 55 Figura 3.6 VPN/MPLS com acesso ADSL --------------------------------------------------------------------- 56 Figura 3.7 Fluxo de escolha da tecnologia de acesso---------------------------------------------------------- 57 Figura 4.1 Topologia Intranet das VPN/MPLS---------------------------------------------------------------- 64 Figura 4.2 Roteador PE compara as rotas BGP---------------------------------------------------------------- 68 Figura 4.3 Roteadores PEs comparam as rotas VPN-IPv4--------------------------------------------------- 68 Figura 4.4 Exemplo de topologia atravs de RT -------------------------------------------------------------- 70 Figura 4.5 Modelo de Extranet----------------------------------------------------------------------------------- 71 Figura 4.6 BGP entre CE e PE ----------------------------------------------------------------------------------- 74 Figura 5.1 Topologia para teste de conectividade e isolamento --------------------------------------------- 82 Figura 5.2 Topologia para teste de QoS do CE ---------------------------------------------------------------- 85 Figura 5.3 a 5.21 QoS no CE-------------------------------------------------------------------------------- 87 - 98 Figura 5.22 RTT x Utilizao ------------------------------------------------------------------------------------ 99 Figura 5.23 Topologia para teste de QoS do PE-------------------------------------------------------------- 100 Figura 5.24 a 5.42 QoS no PE ---------------------------------------------------------------------------- 102-110 Figura A.1 Formato da mensagem do cabealho BGP ------------------------------------------------------- 119 Figura A.2 Formato de mensagem OPEN---------------------------------------------------------------------- 121 Figura A.3 Formato de mensagem NOTIFICAO --------------------------------------------------------- 121 Figura A.4 VPN-IPv4 -------------------------------------------------------------------------------------------- 123 Figura A.5 RD tipo=0 -------------------------------------------------------------------------------------------- 123 Figura A.6 RD tipo=1 -------------------------------------------------------------------------------------------- 124 Figura C Formato do encapsulamento DSL ------------------------------------------------------------------- 128 Figura C.1 RFC 1483 Routead ---------------------------------------------------------------------------------- 128 Figura C.2 RFC 1483 Bridged----------------------------------------------------------------------------------- 119 Figura C.3 PPPoE ------------------------------------------------------------------------------------------------- 130

xii

Figura C.4 PPPoA ------------------------------------------------------------------------------------------------- 131 Figura D.1 Topologia tpica das VPNs tradicionais---------------------------------------------------------- 132 Figura D.2 Migrao para VPN MPLS ------------------------------------------------------------------------ 133

xiii

Lista de tabelas
Tabela 2.1 Recomendao dos valores DSCP AF------------------------------------------------------------- 37 Tabela 2.2 Quadro comparativo das solues de VPNs ------------------------------------------------------ 39 Tabela 3.1 Comparao entre IPoATM, Comutao de Clula e Roteamento IP ------------------------ 42 Tabela 3.2 Requerimentos das aplicaes ---------------------------------------------------------------------- 49 Tabela 3.3 Classificao das aplicaes ------------------------------------------------------------------------ 53 Tabela 3.4 Mapeamento do DSCP em EXP-------------------------------------------------------------------- 54 Tabela 4.1 Endereos das VPNs dos usurios e loopback do provedor ------------------------------------ 65 Tabela 4.2 Definio dos Identificadores de Rotas (RDs) --------------------------------------------------- 70 Tabela 4.3 Matriz da configurao das RTs VRFs------------------------------------------------------------ 71 Tabela 5.1 Parmetros por classes de servios - CE ---------------------------------------------------------- 71 Tabela 5.2 Resultado de Sada do Iperf------------------------------------------------------------------------- 86 Tabela 5.3 Parmetros por classes de servios - PE---------------------------------------------------------- 101

xiv

Lista de Siglas
ADSL AF AS ATM ASBR BA BGP CE CPE CU DiffServ DLCI DoS DSCP EBGP ECN EF FEC GRE IBGP IGP IntServ IP ISP IPSec IS-IS LDP LSP L2TP MPLS OSPF P PDU Asymmetric Digital Subscriber Line Assured Forwarding Autonomous system Asynchronous transfer mode Autonomous System Boundary/Border Router Behavior Aggregate Border Gateway Protocol Customer Edge Customer Premise Equipament Currently Unused Differentiated Service Data-Link Connection Identifier Denial of Service DiffServ Codepoint External BGP Explicit Congestion Notification Expedited Forwarding Forwarding Equivalence Class Generic Routing Encapsulation Internal BGP Interior Gateway Protocol Integrated Services Internet Protocol Internet Service Provider IP Security Protocol Intermediate System to Intermediate System Label Distribution Protocol Label Switched Path Layer 2 Tunneling Protocol Multiprotocol Label Switching Open Shortest Path First Provider Protocol Data Unit

xv

PE PHB PIR POP PPPoA PPPoE QoS RD RED RFC RR RT RTT RSVP SLA SP ToS UDP VCI VoIP VPI VPN VRF

Provider Edge Per-Hop Behavior Packet Inserted Rate Point Of Presence Point-to-Point Protocol over ATM Point-to-Point Protocol over Ethernet Quality Of Service Route Distinguisher Random Early Detection Request For Comments Route Reflector Rotas Targets Round-trip time Resource Reservation Protocol Service-level agreement Service Provider Type Of Service User Datagram Protocol Virtual Channel Identifier Voice over IP Virtual Path Identifier Virtual Private Network VPN Routing and Forwarding

xvi

Resumo
A garantia de nveis de servio das Redes Privadas Virtuais (VPNs) depende fundamentalmente da presena de um modelo de projeto que seja funo, no somente dos recursos da rede, como tambm dos servios de comunicao (fim a fim) das estaes e das aplicaes. Esse modelo deve ser de fcil atualizao e flexvel o suficiente para a implantao rpida e eficiente de novas funcionalidades. As tecnologias VPN/MPLS e DiffServ tm sido propostas para o provimento de qualidade de servio para a prxima gerao das VPNs. Esta dissertao apresenta uma estratgia para o projeto de redes VPNs baseada nestas tecnologias. O trabalho proposto utiliza um ambiente de teste desenvolvido para esta dissertao com o objetivo de validar a implementao de VPNs MPLS com DiffServ. Foram realizados trs tipos de testes voltados para a gerao de dados referentes conectividade, isolamento e qualidade de servio. Esses dados permitiram a realizao de anlises do desempenho das VPNs MPLS. O trabalho apresenta tambm o desenvolvimento, o uso e implementao do modelo de projeto de VPNs MPLS para vrias classes de servios. O modelo descreve uma estratgia simplificada para dimensionamento das classes de servios por VPN. De forma geral, capaz de representar o desenvolvimento de VPNs MPLS para vrias classes com qualidade de servio fim a fim, as quais transportam trfegos de diversas aplicaes: trfego melhor esforo (best effort), trfego com prioridades (AF1, AF2, AF3, AF4) e trfego de voz (EF). Os conceitos relacionados conectividade e ao isolamento dos roteadores virtuais utilizados nas VPNs MPLS tambm so abordados neste trabalho. A tendncia do mercado

xvii

de VPNs IP tambm apresentada, sendo estas comparadas s VPNs de nvel 2 predominantes no mercado e, normalmente, baseadas na tecnologia Frame Relay.

xviii

Abstract
The guarantee of degrees of VPN service depends largely on the existence of a project model that is a function of network resources, as well as of communication services (end-to-end), stations and applications. This model must be easily updated and flexible enough so that new functions may be added to it when necessary. VPN MPLS and DiffServ are being analyzed for the provision of service quality necessary to the next VPN generation. This work proposes a strategy for the project based on VPNs in these technologies. This work is based on an environment of tests, which was developed to this work and had as its objective to investigate the viability of implementing a VPN/MPLS with DiffServ. Three tests were performed in such environment and provided data referring to the connectivity, isolation and quality of service. This data permitted to analyze some VPN MPLS performance. This work also shows the development, application and implementation of the VPN IP MPLS model in several degrees of services. Such model offers a simplified methodology of VPN IP MPLS projects. Besides that, it permits to measure the type of services by VPN. In general, this model is able to represent the VPN IP MPLS development to several degrees of services with the quality of end-to-end services, which transport traffic of diverse applications: Data (Best Effort), Data with priority (AF1, AF2, AF3, AF4) and Voice (EF). The ideias about connectivity and isolation of Router Virtuals of VPN IP MPLS are analyzed in this work. The VPN IP markets tendency is also presented, comparing VPN IP to those of level 2, which prevail on market.

xix

Ficha Catalogrfica elaborada pela biblioteca do IMECC da Unicamp

Boava, Ado B63e Estratgia de Projeto de VPN MPLS com QoS/ Ado Boava Campinas,[S.P.:s.n],2004. Orientador: Maurcio Ferreira de Magalhes Dissertao (Mestrado) Universidade Estadual de Campinas, Instituto de Computao. 1.MPLS (Sistema). 2. Redes de Computao. 3. Estratgia I Magalhes, Maurcio Ferreira. II Universidade Estadual de Campinas

xx

Captulo 1 Introduo
1.1 Proposta do Trabalho
Observa-se nos ltimos anos um aumento das exigncias por servios de comunicao de dados capazes de integrar vrias mdias como dados, voz e imagem, com qualidade de servio e segurana. Constata-se um crescente interesse pelas aplicaes multimdia distribudas (vdeo-conferncia, telemedicina, telefonia IP, etc.) na utilizao das redes IP na forma de redes privadas. Essas aplicaes caracterizam-se, principalmente, pelo emprego de diversos tipos de mdia que impem requisitos distintos de QoS ao sistema de comunicao. Como exemplos de atributos de QoS podemos destacar: retardo mximo, variao mxima do atraso, taxa de transmisso, taxa de perda, disponibilidade, etc. Entretanto, as VPNs IP tradicionais, com seu modelo de servios do tipo melhor esforo, comeam a dar sinais de estrangulamento. Uma das conseqncias da adoo desse modelo que todo o trfego tratado de maneira uniforme, sem nenhum tipo de diferenciao ou priorizao. Contudo, nem todos os tipos de trfego e transaes so equivalentes ou tm a mesma importncia para os usurios. desejvel que algumas aplicaes recebam tratamento diferenciado segundo suas demandas especficas, o que no possvel no modelo atual. Por essa razo, pesquisas tm sido conduzidas nesse sentido, dando origem a vrias arquiteturas de 1

servios que buscam integrar as tecnologias VPN MPLS e DiffServ. Constata-se, tambm , que para garantir uma qualidade de servio diferenciada na rede importante que os elementos finais dessa cadeia, os servidores SAP, Web, VoIP, etc, sejam tambm capazes de oferecer um tratamento diferenciado s solicitaes dos vrios clientes. So muitos os desafios relacionados ao projeto de redes VPN baseadas na tecnologia MPLS com qualidade de servio (QoS). O principal desafio deste trabalho determinar, de maneira clara e objetiva, um modelo de projeto que contemple qualidade de servio de acordo com os requisitos da aplicao do usurio atravs do emprego de vrias tecnologias de acesso.

1.2 Contribuies e Trabalhos Relacionados

VPNs MPLS so tratadas na RFC 2547 e Qualidade de Servio por meio de DiffServ proposta nos seguintes documentos: RFC 2475 (Uma arquitetura de Servios diferenciados), RFC 2983 (Servios Diferenciados e Tneis) e RFC 3270 (MPLS suportando DiffServ). Atualmente, os grandes provedores de servios possuem uma enorme quantidade e disponibilidade de tecnologias de acesso como, por exemplo, Frame Relay, ATM, Linhas dedicadas e ADSL. As VPNs MPLS podem permitir a integrao de todas essas tecnologias viabilizando a otimizao da planta instalada. Uma contribuio das VPNs MPLS o nvel de segurana equivalente s VPNs de nvel 2 como Frame Relay e ATM. Uma das grandes barreiras para a migrao de usurios de VPNs nvel 2 para VPNs nvel 3 IP sempre foi a segurana que as VPNs de nvel 2 oferecem para seus usurios, pois as mesmas so orientadas conexo por meio de circuitos virtuais privados (CVP). Com o surgimento das VPNs MPLS criou-se o conceito de LSP, que equivalente ao CVP do nvel 2 do Frame Relay , oferecendo os mesmos nveis de segurana. Outra contribuio das VPNs MPLS para as operadoras o fato de usar o conceito de Roteador Virtual que reduz significativamente a necessidade de equipamento para cada enlace do usurio dentro da operadora.

O mercado de VPNs formado basicamente pelos segmentos governo, corporativo, pequenas e mdias empresas, sendo o governo e o segmento corporativo atendidos quase totalmente por VPNs de nvel 2, e as pequenas e mdias empresas por VPN de nvel 3 sem QoS e segurana. A proposta deste trabalho sugere o desenvolvimento das VPNs MPLS com vrias classes de servio. Este trabalho contribui com a classe de dados melhor esforo para o mercado de pequenas e mdias empresas e as classes AF (AF1, AF2, AF3, AF4) e EF para o mercado governo e corporativo. A principal contribuio deste trabalho oferecer uma estratgia de projeto de VPNs MPLS que contemple QoS por meio de vrias classes de servios. Para isso foi necessrio a unio das principais caractersticas das VPNs MPLS com DiffServ de acordo com suas respectivas RFCs.

1.3 Tendncias mercadolgica das VPNs MPLS

As VPNs IP aliadas ao MPLS oferecem grandes benefcios s empresas. Juntos, elas fazem com que a rede seja mais segura e tenha maior agilidade no trfego. Permitem, tambm, a integrao de qualquer tipo de rede, planos de endereamento e roteamento, fato que os protocolos convencionais no conseguem fazer. O IP , hoje, o centro das atenes da maioria dos projetos de redes virtuais. O protocolo da internet, ainda segundo a IDC1, deve responder por 40% do trfego de longa distncia em 2005 no Brasil e movimentar mais de US$ 800 milhes. As VPNs baseadas em MPLS so, hoje, uma das principais estratgias de operadoras, fabricantes e integradores. A AT&T uma das empresas que fornece o servio VPN e j possui cerca de 1.200 clientes no Brasil que usam a rede VPN IP. As boas perspectivas de demanda foram um dos aspectos que tambm levaram a Intelig a apostar na VPN IP como plataforma de transmisso. O crescimento dos projetos de VPNs tambm vem estimulando os fabricantes de dispositivos de rede a investirem alto no desenvolvimento da tecnologia. O mercado brasileiro de telecomunicaes est passando pelo segundo momento mais importante de toda a sua existncia. O primeiro momento ocorreu em 1997 e 1998, com a privatizao do setor e, agora, com desregulamentao e ampliao da
1

IDC International Data Corporation do Brasil realiza estudo de mercado no Brasil

concorrncia no mesmo. A tecnologia IP vem se desenvolvendo nos ltimos anos e hoje considerada uma das principais ferramentas que vai fortalecer a concorrncia nos prximos anos. Novos servios, como Unified Messaging, Voz sobre IP (VoIP) e acessos privativos virtuais (VPNs) so alguns dos servios que sero alavancados com a evoluo da tecnologia IP e estaro cada vez mais acessveis aos usurios, com a ampliao da concorrncia. A tecnologia IP est sendo e deve continuar a ser a principal ferramenta adotada por operadoras para oferecer servios em outras regies (Telefnica oferecer servio na rea da Telemar e Vice Versa), pois apresenta diversas caractersticas favorveis para atuar em novas reas e ampliar a competio. Entretanto, ainda no ser a principal tecnologia adotada para oferecer servios na rea atual de operao, uma vez que ainda existem muitas incertezas, tais como o comportamento da tecnologia IP, para o trfego de voz em grandes volumes (como o trfego gerado na cidade de So Paulo). O trfego telefnico tradicional est sofrendo um impacto com a entrada da telefonia IP uma vez que haver queda no preo do minuto utilizado e novos servios que agregaro valor aos servios de voz. O trfego existente tradicional migrar para as redes de comunicao de dados, alterando todo o servio existente atualmente e principalmente a forma de tarifao. Porm, isso ocorrer gradativamente, medida que IP comece a trabalhar conjuntamente com MPLS com o objetivo de oferecer qualidade de servio para as aplicaes de voz. A ampliao e evoluo da oferta dos servios tambm ser o foco das operadoras e a tecnologia IP, aliada ao MPLS e a possibilidade de unificar as redes de voz e dados, alavanca benefcios econmicos e tecnolgicos para as operadoras, tais como reduo nos custos de manuteno das redes, unificao da tarifao, entre outros. As operadoras tradicionais de telecomunicaes no Brasil j esto em fase de implementao de seus servios baseados na tecnologia IP/MPLS; porm, essa oferta de servios dever estar concentrada na expanso geogrfica dos servios e no nas redes atuais, pois a inteno destes fornecedores otimizar a utilizao das redes existentes e disponibilizar servios sobre as mesmas. Acredita-se que o mercado de VPN/MPLS IP comear a surgir no segundo semestre de 2004, principalmente com ofertas para o setor corporativo de mdias e grandes empresas. Muitas destas empresas j possuem redes de comunicao de dados 4

implementadas, usando como acesso tecnologias tradicionais como Frame Relay, ATM e DSL. Portanto, essas empresas devero ser as primeiras beneficirias das solues de VPN/MPLS em suas redes e principais usurias dos novos servios que estaro agregando valor tecnologia. O segmento de pequenas e mdias empresas dever ser o segundo grande mercado a receber os benefcios deste novo cenrio de telecomunicaes no Brasil. Com a ampliao da concorrncia e a reduo nos custos de implantao de uma rede de comunicao de dados, este mercado deve migrar gradativamente para os novos servios baseados em comunicao de dados e servios de valor agregado. Contudo, essa nova tecnologia requer novos investimentos, o que ocorrer ao longo dos prximos anos. O segmento residencial ser o ltimo setor a utilizar esses novos servios e usufruir os benefcios da Tecnologia IP. muito provvel que com a evoluo das tecnologias de acesso banda larga (xDSl, cable modem,etc.) as classes de maior poder aquisitivo (A e B) comearo a utilizar os novos servios e, principalmente, voz sobre IP e videoconferncia. Servios X.25 continuam em declnio no mercado, embora ainda respondam por 6% do mercado total; porm, nos prximos anos iro perder ainda mais participao devido migrao dos seus clientes para outras tecnologias. Essas redes so uma herana do antigo Sistema Telebrs, o qual utilizava esta tecnologia para interligar o Brasil em uma grande rede de pacotes, principalmente as operadoras de cartes de crdito. Essas redes devem sobreviver por mais alguns anos, pois, como toda a atual tecnologia, j est passando por um processo de congelamento e transio a outras formas de atendimento, principalmente o frame relay. O frame relay, por sua vez, uma tecnologia em expanso no mercado brasileiro. Est sendo muito utilizado para fornecer servios ao segmento de pequenas e mdias empresas, em virtude do seu menor preo mensal, se comparado s linhas dedicadas. O frame relay obteve uma participao no mercado de aproximadamente 14% do total. Um dos principais aceleradores deste mercado a migrao dos clientes X.25 e linhas dedicadas para as redes frame relay. Os servios IP so responsveis por aproximadamente 14% do mercado. As redes ATM para acesso do usurio final ainda so incipientes no Brasil, respondendo por apenas 3% do faturamento total das empresas. As principais operadoras do mercado tm 5

investido na comunicao por pacotes e na procura por novos clientes corporativos, ao passo que os clientes procuram formas de atendimento que satisfaam suas necessidades de comunicao de forma rpida, com qualidade e menor custo. Por esses motivos, os servios de transmisso por pacotes vm crescendo no mercado. A queda nos preos mensais outro importante fator para o crescimento do mercado de comunicao de dados por pacotes.

1.3.1 - Tendncias de VPNs baseadas em Rede e CPE

Tendncia das VPNs baseadas em :CPE x REDE
7 (em milhes de dolares) 6 5 4 3 2 1 0

VPN na Rede

VPN em CPE

2000 2001 2002 2003

2004

2005 2006

2007

Fonte:Yankee Group, 2003

Figura 1.1 Tendncias das VPNs baseadas em CPE e Rede Anlise visvel o grande crescimento a partir de 2004 no mercado mundial das VPNs IP baseada em CPE2 (configurao da VPN realizada de CPE a CPE) e principalmente aquelas baseadas em Rede (configurao da VPN realizada na rede do provedor). Estudos tm mostrado que o Brasil seguir a mesma tendncia mundial de crescimento das VPNs IP. As demandas por servio legado esto em queda e novos servios esto sendo desenvolvidos pelas operadoras; um desses so as VPNs MPLS. Oferecer VPNs MPLS para o mercado significa maior gerenciamento, melhor relao benefcio/custo, maior

CPE: Customer Premise Equipment Designa o equipamento que instalado no ambiente do usurio utilizado para conectar com a rede do provedor.

flexibilidade de rede e principalmente maior fidelizao do cliente. Os servios de VPN desenvolvidos devem ser adequados para os diversos segmentos, inclusive o residencial. Apesar de ser uma tecnologia nova no Brasil, j percebido que as VPN MPLS comeam a dominar as solues de comunicao. Podemos citar os casos do SPB (Sitema Brasileiro de Pagamento) e, recentemente, o Banco do Brasil (Aproximadamente 8000 acessos ligando todas s agncias). O crescimento do servio tem a tendncia de seguir o modelo mundial, ou seja, um crescimento exponencial.

1.4 Estrutura do Trabalho

Esta dissertao encontra-se organizada da seguinte forma: o captulo 2 apresenta um resumo dos principais conceitos e protocolos utilizados neste trabalho; o captulo 3 apresenta o mtodo para o desenvolvimento de VPNs MPLS para vrias classes de servios formado por 7 passos; o captulo 4 mostra um estudo de caso elaborado para validar o passo 5 apresentado no captulo 3, que trata da configurao da VPN MPLS; no captulo 5 so realizados testes de conectividade, isolamento e QoS das VPNs MPLS e, por ltimo, o captulo 6 apresenta as concluses do trabalho.

Captulo 2 Fundamentos
Neste captulo ser apresentada inicialmente uma descrio das caractersticas mais importantes das tecnologias VPN, MPLS, BGP e Diffserv para a modelagem de construo de VPNs MPLS com QoS. Na sequncia so apresentados os principais conceitos e caractersticas dos Modelos Overlay e Peer. Em seguida so mostrados os mtodos tradicionais de construo das VPNs MPLS. apresentado, ainda, o conceito de servios diferenciados com o objetivo de fornecer qualidade de servio no modelo das VPNs MPLS. Por fim, apresenta-se um resumo das principais implementaes de VPN MPLS baseadas na RFC 2547bis e suas vantagens. Cada empresa tem diferentes necessidades de qualidade de servio (QoS), segurana, nmero de pontos de acesso, nmero de usurios, complexidade de roteamento, aplicaes de misso crtica e volumes de trfego. Para satisfazer essas necessidades, os provedores de servios oferecem um portflio em que constam diferentes modelos de solues de VPN: VPNs Tradicionais o Frame Relay (Nvel 2) o ATM (Nvel 2) VPNs baseadas em CPE o PPTP e L2TP(Nvel 2) o IPSec (Nvel 3) VPNs aprovisionada pelo provedor

o VPNs de nvel 2 baseadas em MPLS o VPNs BGP/MPLS de nvel 3 ou RFC2547bis Este captulo estar focado no entendimento do Modelo das VPNs MPLS baseadas no BGP[8] e DiffServ[1] que atualmente de grande interesse dos provedores de servios.

2.1 O que uma VPN

Considere uma empresa que tem um conjunto de pontos3 geograficamente dispersos. Para interconectar esses pontos a empresa precisa de uma rede. A rede privada, pois usada somente por esta empresa. Tambm privada, porque os planos de endereamento e roteamento atravs da rede so totalmente independentes dos planos de todas as outras redes. A rede virtual, pois as facilidades usadas no necessariamente precisam ser dedicadas para um nico usurio. Pode-se dizer, informalmente, que VPN um conjunto de pontos de acesso do usurio que podem comunicar entre si. Mas, formalmente, uma VPN definida como um conjunto de polticas que controlam a conectividade e qualidade de servio da rede privada [18]. Muitas das contribuies concebidas para a arquitetura de Rede Virtual Privada (VPN) tm sido submetidas aos rgos de padronizao. Outro aspecto importante que vrios provedores tm implementado o servio VPN sobre uma infra-estrutura MPLS (Multiprotocol Label Switching) [3].

2.1.1 - Definio de VPN Intranet e Extranet

Conforme mencionado no item anterior, uma VPN pode ser definida como um subconjunto de pontos de acesso do usurio baseado em um conjunto de polticas. No exemplo apresentado na figura 2.1, seis diferentes pontos so incorporados pela rede do backbone do provedor de servio. Os pontos A, B e C pertencem a uma empresa e os pontos X,Y e Z pertencem a outra empresa. Os pontos A, B e C podem compartilhar

Ponto e rede de cliente/usurio equivale a site em ingls nesse trabalho

conectividade IP entre si porque eles fazem parte do mesmo subconjunto de polticas, ou seja, eles esto na mesma VPN (VPN ABC). Os pontos X,Y e Z so partes de uma outra VPN, pois compartilham um conjunto de polticas diferente daquele associado VPN ABC. Ponto X Ponto A Ponto B Ponto Y Ponto C

Backbone

Ponto Z

Figura 2.1 BGP4/MPLS VPN: Sites e Backbone de rede A figura 2.2 a seguir apresenta o cenrio onde um novo conjunto de polticas introduzido definindo que os pontos A e Z compartilham conectividade IP. Ponto B Ponto Y Ponto C

Ponto X Ponto A

Backbone

Ponto Z

Figura 2.2 Um novo subconjunto de polticas

BGP/MPLS VPN usa os benefcios do BGP para troca de rotas entre os roteadores de borda no backbone do provedor

10

Dois pontos podem unicamente ter conectividade IP atravs do backbone da rede se h no mnimo uma VPN que contenha ambos os pontos. Pode haver a situao em que todos os pontos que esto em uma VPN pertenam a uma nica empresa. Nesse caso, a VPN chamada de Intranet5. As VPNs ABC e XYZ so exemplos desses tipos. Se os pontos em uma VPN pertencem a mais que uma companhia, por exemplo a VPN AZ, temos uma VPN extranet (figura 2.3). VPN XYZ VPN ABC Ponto A VPN AZ Ponto X

Ponto B

Ponto Y

Ponto C

Ponto Z

Figura 2.3 - Uma terceira VPN criada Ambas as topologias (Intranet e Extranet) apresentadas anteriormente so possveis de ser implementadas com a tecnologia VPN MPLS (RFC 2574bis). Uma VPN MPLS consiste de duas redes: a rede do provedor e a rede do cliente. A rede do provedor constituda de roteadores de borda (PE) que provem servios de VPN e conectividade para as redes dos clientes. As redes dos clientes so normalmente constitudas, fisicamente, por diferentes pontos de acessos. Os roteadores dos clientes que se conectam aos provedores dos servios das VPNs so chamados de Router Customer Edge (CE) , como mostra a figura 2.4. Basicamente, uma VPN MPLS usa uma combinao dos benefcios das tecnologias no orientada a conexo( CE-PE) com a tecnologia orientada a conexo (PEPE). Os protocolos de roteamento entre o CE e PE podero ser: RIPv2, Rota esttica, BGP4

O termo Intranet refere-se ao fato de que a aplicao Internet (www, ftp, correio) est sendo executada completamente em uma rede privativa.

11

ou OSPF e entre os PEs utilizado Multiprotocolo BGP (MP-BGP). As prximas sesses do captulo iro abordar em detalhe a implementao de VPN MPLS. MP Sesses iBGP entre os roteadores PEs VPNA Rede de Cliente CE PE P CE Provedor de Rede P e-BGP RIP OSPF Rotas Estticas P e-BGP RIP OSPF Rotas Estticas PE VPNA Rede de Cliente

Figura 2.4 Viso Geral de uma VPN MPLS

2.2 Modelo Overlay

As tcnicas mais comuns atualmente para prover servios VPN so baseadas no modelo Overlay (predominantemente Frame Relay6). Neste modelo, cada ponto de acesso do ambiente do usurio tem um roteador que conectado, atravs de enlaces ponto a ponto, at outro roteador remoto do usurio. O ambiente do usurio pode ter um ou mais roteadores que podem ser conectados a todos os outros pontos ou a um subconjunto destes. A tecnologia utilizada para oferecer enlaces ponto a ponto pode ser: linhas dedicadas, Frame Relay ou ATM. A rede formada por estes enlaces ponto a ponto e os roteadores instalados formam um Backbone Virtual. nesse backbone virtual que os provedores de servios formam as VPNs para interligar os pontos das redes dos usurios (Figura 2.5).

Frame Relay tecnologia que domina o mercado para implementao de VPNs de nvel 2. Esta tecnologia surgiu no fim da dcada de 80 como uma simplificao do X.25, para aumentar, principalmente, a vazo e reduzir o atraso.

12

Rede 1

Rede Frame Relay ou ATM

Rede 2

Rede 3

Rede 4

Figura 2.5 Modelo Overlay

As solues das VPNs baseadas no modelo overlay so as predominantes no mercado mundial. Este tipo de soluo apresenta vrios problemas que limitam o desenvolvimento em larga escala do servio VPN. O primeiro problema vem da necessidade que o cliente tem em operar e projetar sua prpria VPN no backbone virtual. Neste caso necessrio um conhecimento sobre roteamento IP, o que no comum na maioria das organizaes pois estas esto focadas em seus negcios e no em redes IP, principalmente nas pequenas e mdias empresas. Como resultado, muitas empresas no utilizam o servio VPN pois requerem projeto e operao nos seus backbones virtuais. H necessidade tambm do conhecimento em QoS IP, QoS de camada 2 e mapeamento entre QoS da camada IP com a camada 2. Isso porque, enquanto ATM e Frame Relay podem prover QoS, essa QoS expressa em termos dos parmetros da camada dois e no em termos de QoS IP. Com o objetivo de resolver este problema, provedores de servios oferecem o que conhecido como Roteador Gerencivel no qual o provedor projeta e opera o backbone virtual para cada VPN dos clientes. Portanto, enquanto se resolve um problema, 13

cria-se outro, pois requer que o provedor de servio opere um backbone virtual para cada VPN de cliente. Essa necessidade faz com que o provedor encontre dificuldade em oferecer servios para um grande nmero de clientes (imagine um provedor que tem 100.000 VPN de clientes e tendo que operar 100.000 backbone virtuais, um para cada cliente). Tambm como conseqncia desse problema, o custo do servio torna-se alto. O servio de gerenciamento de roteador, somente, no resolve o problema. A dificuldade em suportar um grande nmero de clientes justamente um dos problemas do modelo overlay. O segundo problema vem dos clientes que tm um grande nmero de pontos (100 ou mais) e precisam conectividade completa com todos os pontos (configurao mesh). Neste caso, para uma VPN com n pontos, cada roteador precisar de (n-1) pontos de troca de trfego (peering). Este problema o mesmo encontrado na interconexo baseada no modelo overlay de redes IP sobre ATM. Outro problema com o modelo overlay a quantidade de configurao necessria para incluso de um novo ponto em uma VPN existente. Para uma VPN que requer conectividade completa (full mesh) entre todos os pontos, cada um destes pontos necessita de uma conexo e roteamento ponto a ponto com todos os outros pontos da VPN. Uma variao do modelo overlay o modelo em que o provedor de servio desenvolve roteadores que so capazes de atuar como Roteadores Virtuais (VR). Nesse caso, um simples roteador atua como uma coleo de roteadores virtuais. Um VR funcionalmente equivalente a um roteador convencional, exceto que compartilha CPU, largura de banda e recursos de memria com outros roteadores virtuais. Um Roteador Virtual conectado a outro, via enlaces ponto a ponto. Para reduzir o nmero de enlaces ponto a ponto requerido, possvel fazer a multiplexao de vrias conexes em um nico enlace por meio de Frame Relay ou ATM, atravs da introduo de alguma forma de multiplexao do cabealho do pacote. Cada ambiente do usurio possui um roteador conectado em um roteador virtual. Nesse caso, o backbone virtual composto de tais roteadores virtuais e os enlaces que os interligam. Uma das vantagens do uso do Roteador Virtual que ele reduz a quantidade de equipamentos fsicos que um provedor necessita disponibilizar. O uso do roteador virtual no altera o modelo; ele permite simplesmente que um nico roteador seja fisicamente compartilhado por vrios roteadores virtuais.

14

A garantia de QoS no modelo overlay usualmente expressa em termos de largura de banda (CIR7) em um determinado Circuito Virtual (VC) e da taxa mxima de transmisso (PCR). A garantia de banda usualmente provida por meio de servios estatsticos da camada 2, mas depende da estratgia de overbooking do provedor de servio. Alm dos circuitos Frame Relay e ATM, poderiam tambm ser utilizado mecanismo de tneis como GRE e IPSec para conectar os roteadores. Entretanto, tneis GRE e IPSec atuam unicamente para prover um mecanismo de conexo de roteador ponto a ponto mantendo as caractersticas do modelo Overlay e introduzem um novo problema conhecido como spoofing de dados. Uma das principais deficincias dos protocolos e servios TCP/IP usar esquemas baseados em endereos IP para autenticar mquinas na rede. A autenticao feita com base no endereo IP de origem de um pacote recebido, todavia, impossvel determinar com certeza a identidade da mquina que originou o pacote. Isso torna muito fcil para atacantes personificarem outras mquinas. Esta tcnica de personificao conhecida como IP spoofing. Um dos caminhos para resolver o problema de spoofing de dados a utilizao de IPSec em vez de GRE. No caso do IPSec, o final do tnel poder autenticar o transmissor permitindo que somente os pacotes iniciados originalmente pelo seu dono cheguem ao final do tnel. Todos os outros pacotes so rejeitados. A vantagem oferecida pelos tneis GRE e IPSec sobre Frame Relay e ATM a habilidade de oferecer servios de VPNs para qualquer lugar onde exista conectividade com a Internet.

2.3 O Modelo Peer

A principal contribuio desse modelo, relativamente ao modelo overlay, a possibilidade de oferecer o servio de VPN em grande escala. O modelo peer prov um nmero de vantagens sobre o modelo overlay:
7

CIR a taxa que a rede concorda suportar para uma determinada conexo no modo frame.

15

O roteamento, do ponto de vista do usurio, torna-se essencialmente simples, pois o roteador do cliente troca informaes de roteamento com um (ou poucos) roteador(es) de borda do provedor, enquanto no modelo overlay este nmero de roteadores pode crescer significativamente.

Considerando

principalmente

uma

topologia

full

mesh,

aprovisionamento da largura de banda simples porque necessrio especificar somente a largura de banda de entrada e sada para cada acesso da VPN entre CE e o PE. No caso do modelo overlay o aprovisionamento mais complexo, pois ser necessrio uma anlise fim a fim em cada CVPs, acessos e banda da VPN. A adio de um novo ponto/site simples porque o aprovisionamento pelo provedor do servio unicamente adicionar um ponto/site com um roteador CE e configurar um dos protocolos de roteamento entre o CE e o roteador PE. No modelo overlay de VPN o provedor de servio dever aprovisionar um conjunto inteiro de VCs do ponto principal/origem para o outro ponto/destino do cliente da VPN. A implementao de VPN baseada no modelo de pares (modelo peer) tem, no caso do MPLS, duas possibilidades de implementao: Mtodo com roteador compartilhado [4] Nesse mtodo, os usurios compartilham o mesmo roteador PE; Mtodo com roteador dedicado [4] Nesse mtodo, cada usurio tem um roteador PE dedicado.

2.3.1 Mtodo com roteador compartilhado

Neste caso, o roteador na borda da rede do provedor compartilhado entre vrios usurios. As listas de acessos tm que ser configuradas em todas as interfaces PE-CE nos roteadores PE para garantir isolao entre usurios das VPNs (ilustrado no teste de isolamento da VRF realizado no captulo 5), prevenindo que um cliente de uma VPN possa

16

acessar outra VPN, ou at mesmo para evitar ataques do tipo Denial-of-Service (DoS)8 em outra VPN.
Porto Alegre Usurio X

CE

Backbone do Provedor de Servio POP PE

Curitiba Usurio X

CE
Enlace Roteador Compartilhado

Braslia Usurio Y

CE

Os PEs compartilhados contm todas as rotas dos clientes

Figura 2.6 Modelo de Roteador compartilhado

2.3.2 Mtodo com roteador dedicado

Nesse mtodo, todas as VPNs dos usurios tm seu prprio roteador PE dedicado (como mostra a figura 2.7 abaixo) e possuem seus acessos somente para os roteadores includos na tabela de roteamento do roteador PE.

A essncia dos ataques se baseia no princpio de saturar a capacidade de processamento dos servios

17

Porto Alegre Usurio X

CE

Backbone do Provedor de Servio POP

Os roteadores Ps contm todas as rotas das VPNs dos usurios Enlace

Curitiba Usurio X

CE

Roteador PE Usurio X

Roteador P

Braslia Usurio Y

CE

Roteador PE Usurio Y

Os roteadores PEs dedicados contm unicamente as rotas dos ambientes dos usurios

Figura 2.7 Modelo VPN Peer-to-Peer com roteador dedicado

O modelo de roteador dedicado usa protocolos de roteamento para criar tabelas de roteamento para cada VPN nos roteadores PEs. Estas tabelas contm somente as rotas anunciadas pela VPN conectada, resultando em uma perfeita isolao entre as mesmas. O roteamento no roteador dedicado pode ser implementado da seguinte forma: O protocolo de roteamento executado entre os roteadores PE e o CE; O BGP executado entre os roteadores PE e P; Os roteadores PEs redistribuem as rotas recebidas do CE atravs do BGP; Os roteadores Ps propagam as rotas unicamente com o BGP community (observar o anexo A, item A.5) para os roteadores PEs. Esse modelo com roteador dedicado, no entanto, no tem sido implementado na prtica em funo da alta quantidade de roteador necessrio.

2.3.3 - A implementao do modelo Peer

18

A implementao do modelo peer pode ser realizada atravs da utilizao de um novo tipo de endereamento (VPN-IP) e atravs da tecnologia MPLS.

2.3.3.1 Endereos VPN-IP

At esse momento foram apresentados mecanismos que permitem especificar como feito o controle da conectividade entre os pontos dos usurios de uma VPN bsica. Mas esses mecanismos usam BGP que assume determinadas condies sobre o endereamento IP. Especificamente, o BGP assume que os endereamentos IP sejam nicos. Esta associao no adequada no ambiente de VPN pois um mesmo bloco de endereamento IP poder ser simultaneamente utilizado por mltiplas VPNs dos usurios. Tambm, para o uso do BGP, necessrio entender como usar o BGP em um ambiente onde endereos IP no so nicos [49]. Uma soluo natural para esse problema seria estender o endereo IP atravs da agregao de um novo campo de modo a permitir a identificao das VPNs. Este novo tipo de endereo denomina-se de endereo de VPN e deve ser nico. Pela definio, um endereamento VPN-IP construdo pela concatenao de um campo de comprimento fixo denominado Route Distinguisher com o endereo IPv4. Um Route Distinguisher estruturado de forma a permitir que cada provedor de servio VPN crie rotas prprias, sem o risco da mesma ser utilizada por outro provedor de servio (veja captulo 4 Identificador de Rotas -RD). Com o objetivo de facilitar o entendimento do protocolo BGP o anexo A contm uma breve descrio dos conceitos fundamentais do protocolo.

2.3.3.2 MPLS
MPLS - Multiprotocol Label Switching [43] uma tecnologia desenvolvida no mbito do IETF-Internet Engineering Task Force, inicialmente com o objetivo de tornar o encaminhamento e a comutao eficientes de fluxos de trfegos atravs da rede. O MPLS uma tecnologia utilizada em backbones9 e tem o objetivo de solucionar problemas atuais de
9

Backbone uma conexo de alta velocidade que funciona como espinha dorsal de uma rede de comunicao

19

redes de computadores como velocidade, escalabilidade, gerenciamento de qualidade de servio (QoS) e a necessidade de engenharia de trfego-TE. No roteamento tradicional em redes IP os pacotes seguem o menor caminho at o destino. Alguns roteadores podem ento ficar sobrecarregados enquanto outros so subutilizados. Outro problema que as buscas nas tabelas de rotas so demoradas pois as entradas no tm tamanho fixo: procura-se o maior prefixo de endereo que coincida com o endereo de destino do pacote (este mtodo conhecido como Longest Match). Alm disso, o processo de roteamento, incluindo as buscas nas tabelas de rotas, realizado em cada roteador para cada pacote recebido. Quando se utiliza MPLS nas redes IP convencionais, h drstica reduo do tempo de busca nas tabelas de rtulos em comparao com as buscas nas tabelas de roteamento. Uma das vantagens do MPLS a sua utilizao sobre ATM. Neste caso h a eliminao do problema conhecido como problema N2 (o captulo 3 detalha melhor esse problema) que surgiu com IP sobre ATM, em que so necessrias N-1 conexes para cada um dos N comutadores ATM. O MPLS contribui, basicamente, com a separao dos componentes dos planos de controle e encaminhamento. A figura 2.8 mostra abaixo a separao dos planos.
Protocolo de Roteamento

Controle
Tabela de Roteamento

Tabela de Encaminhamento Comutao

Encaminhamento

Figura 2.8 Controle e Encaminhamento no MPLS

20

O plano de controle possui duas principais funes: determinar o caminho que envolve a criao das tabelas de roteamento e a funo de sinalizao. O protocolo de roteamento troca informaes com outros roteadores para construir e manter as tabelas de roteamento, usando alguns protocolos de nvel trs (OSPF ou BGP-4). Os rtulos que compem as tabelas de encaminhamento so distribudos na rede por meio de um dos protocolos de sinalizao (LDP ou RSVP). O cabealho MPLS formado de 32 bits e possui os seguintes campos. 8 bits TTL 1 bits S 3 bits EXP 20 bits LABEL/Rtulo

Figura 2.9 - Cabealho MPLS LABEL formado de 20 bits e transporta o valor atual do cabealho MPLS. EXP Campo EXPerimental para prover QoS S O campo Stack suporta uma hierarquia de pilha de label. TTL Campo do tempo de vida.

2.4 - RFC 2547bis

Nessa seo ser feito um resumo da implementao da RFC 2547 realizada pelos principais fornecedores de solues VPN BGP/MPLS.

2.4.1 Viso Geral

Redes Virtuais Privadas MPLS na RFC-2547bis [8] definem um mecanismo pelo qual os provedores de servio podem usar seu backbone para prover servio de VPN para seus clientes. Uma VPN um conjunto de pontos que compartilham informaes de roteamento e cuja conectividade controlada por um conjunto de regras. A RFC-2547bis tambm conhecida como VPN BGP-MPLS porque o BGP o protocolo utilizado para

21

distribuio da informao de roteamento das VPNs e pela utilizao do MPLS estabelecimento dos circuitos virtuais e encaminhamento do trfego.

no

Um provedor pode gerenciar mltiplas VPNs desde que as regras estejam habilitadas para manter separadas as rotas das diferentes VPNs (O captulo 5 avalia o isolamento da VPN). A conexo entre os roteadores CE e PE pode ser uma conexo remota atravs de Frame Relay ou ATM ou, ainda, um enlace Ethernet. As redes dos clientes trocam rotas com provedores de servios (CE para PE), usando rotas estticas ou via RIP, OSPF ou EBGP (Ver captulo 4 seo 6). Quando o roteador PE recebe a rota atualizada criada uma tabela de roteamento e as informaes de alcanabilidade so encaminhadas para cada ponto da VPN conectada no roteador. Os roteadores PEs estabelecem sesses MP-iBGP10 para trocar rotas de clientes. O trfego da rede do provedor passa atravs do LSP (Label Switched Path) prestabelecido atravs dos protocolos de sinalizao LDP ou RSVP-TE. O roteador PE adiciona dois rtulos como prefixos para cada pacote do trfego IP do cliente. O rtulo mais externo identifica o prximo salto ao longo do LSP do provedor de rede, enquanto o rtulo mais interno identifica a VPN particular do cliente, conectada no roteador de destino. A informao do rtulo trocada durante a sesso de configurao MP-iBGP. Os principais objetivos da RFC 2547bis so: Oferecer servios simples para os usurios com todo o potencial do roteamento IP; Oferecer servio com grande escalabilidade e flexibilidade; Permitir regras que so usadas para criar uma VPN que ser implementada pelo provedor do servio, de forma independente ou trabalhando junto com o cliente; Permitir ao provedor de servio a entrega de um servio de valor adicionado que possa fidelizar seus clientes.

10

MP-iBGP so sesses BGP PE a PE por meio do backbone VPN/MPLS

22

2.4.2 Implementao da RFC 2547

Na arquitetura tradicional de roteamento IP h uma clara distino entre rotas externas e internas. Na viso de um provedor de servio, rotas internas incluem todos os enlaces internos do provedor e interfaces de loopback11. Essas rotas internas so trocadas com outras rotas na rede, por meio do protocolo IGP, tais como OSPF ou IS-IS. Todas as rotas aprendidas na Internet por meio de pontos de troca de trfego (peering) ou de pontos de clientes so classificadas como rotas externas e so distribudas por meio do protocolo externo (EGP), tais como BGP. Na arquitetura IP tradicional, o nmero de rotas internas bem menor que o nmero de rotas externas [38].

2.4.2.1 Componentes da Rede

No contexto da RFC 2547bis, uma VPN uma coleo de regras para controle da conectividade entre um conjunto de redes. Uma rede de cliente conectado pelo provedor do servio por uma ou mais portas, sendo que o provedor de servio associa cada porta com uma tabela de roteamento VPN. Na RFC 2574bis, a tabela de roteamento VPN chamada VPN Routing and Forwarding (VRF). A figura 2.10 ilustra os blocos fundamentais para a VPN BGP/MPLS: Rede 1 VPN Vermelha Rede 4 VPN AZUL CE CE P PE Provedor de Rede P P PE CE CE Rede 2 VPN Vermelha Rede 3 VPN AZUL

Figura 2.10 Componentes da VPN/MPLS

Customer Edge Devices (CE) Equipamento de borda do cliente

Loopback Cada roteador PE necessita de um endereo nico (Usualmente chamado de loopback) que utilizado para alocar um rtulo e habilitar o encaminhamento dos pacotes da VPN atravs do backbone.

11

23

Um customer edge (CE) prov acesso do cliente at o provedor de servio de rede. Tipicamente, o equipamento CE um roteador IP que estabelece uma conexo diretamente com o roteador PE. Depois de estabelecida a conexo, o roteador CE anuncia as rotas dos pontos da VPN local para o roteador PE e aprende as rotas remotas da VPN. Provider Edge Routers (PE) Equipamento de borda do provedor Os roteadores PEs trocam informao de roteamento com os roteadores CEs atravs de roteamento esttico, RIPv2, OSPF ou eBGP. Esse modelo de VPN reala a escalabilidade da RFC 2574bis porque elimina a necessidade dos roteadores PEs manterem rotas VPNs com todos os PEs do Provedor de Servio. Cada roteador PE mantm uma VRF para cada ponto conectado diretamente. Observa-se que mltiplas interfaces do roteador PE podem ser associadas com uma nica VRF se todos os pontos de acesso participam da mesma VPN. Aps aprender as rotas das VPNs locais dos roteadores CEs, um roteador PE troca informao de roteamento com os outros PEs atravs do BGP (conhecida como iBGP, conforme figura 2.11). Roteadores PEs podem manter sesses IBGP para rotas refletidas (figura 2.11b) como uma alternativa para uma sesso full mesh (todos conversam com todos). Quando foi concebido o BGP para as VPN MPLS, foi definido que todos os roteadores PEs de uma rede que utiliza BGP necessita de uma comunicao direta entre si (MP - iBGP), portanto uma combinao de todos os roteadores da rede, dois-a-dois, ou seja, um full-mesh de sesses. Para melhorar a escalabilidade e simplificar a configurao, foi criado o papel do Route Reflector, onde todos os roteadores estabelecem uma sesso BGP somente com estes elementos da rede. O segundo elemento existe para redundncia.

RR

RR

Figura 2.11 (a) Combinao dos PEs dois a dois. (b) Configurao atravs de Route Reflector.

24

Finalmente, quando utiliza-se o MPLS para encaminhar o trfego de dados das VPNs por meio do backbone do provedor, os roteadores PEs de ingresso e egresso funcionam como LSRs de ingresso e egresso respectivamente. A figura 2.12 apresenta o conjunto de protocolos normalmente disponvel nos roteadores PEs para atender as necessidades dos provedores de servios. Na figura 2.12, mltiplos protocolos de acesso so suportados para permitir ao provedor do servio flexibilidade em oferecer aos seus clientes vrios mtodos de tecnologia de acesso. O PE tambm suporta um nmero de protocolos que so especficos para aplicaes de B-RAS (Servidor de acesso Banda Larga) que so: IP/PPP/ATM, IP/PPP/Ethernet/ATM, IP/PPP/FR, IP/PPP/Ethernet/FR. Protocolo de roteamento
BGP-4 OSPF IS-IS RIP MPLS

Protocolo de transporte
TCP UDP

Camada de Rede
IP

Camada de Enlace
Frame Relay

PPP

PPPoE

ATM

L2TP

Camada Fsica

DSx/Ex DS1/E1 DS3/E3

Ethernet 100 Base T Gigabit/Ethernet

SONET STM1 STM4

Figura 2.12 Software normalmente suportado pelos PEs

Provider Routers (P) Um Router Provider(P) um roteador na rede do provedor que no troca

informao diretamente com o equipamento CE. A funo dos roteadores Ps como 25

transporte MPLS encaminhar trfego de dados para os roteadores PEs, desde que o trfego seja encaminhado por meio do backbone MPLS, usando duas camadas da pilha de rtulo (label stack) [3]. Os roteadores Ps so utilizados para manter rotas para os roteadores PEs; eles no so necessrios para manter informao de roteamento especfico para cada acesso do cliente. Tabela de Roteamento e Encaminhamento (VRF) da VPN Um conceito chave na arquitetura VPN BGP/MPLS o elemento chamado de tabela de Encaminhamento e Roteamento dos roteadores PE (figura 2.13). A VRF uma tabela de encaminhamento e roteamento para cada VPN dentro dos roteadores PEs. Uma VRF privada acessvel unicamente pelas interfaces que fazem parte da VPN correspondente. Todos os pontos conectados no roteador PE devem fazer parte de uma VRF. Todas as informaes das VPNs so refletidas na VRF e os pacotes que viajam atravs daquele ponto sero roteados e encaminhados com base unicamente na informao encontrada na VRF correspondente. O processo de como uma rota includa na VRF ser explicada na sesso Distribuio de Rotas. Enlace do Backbone Tabela de roteamento Global

Roteador PE

Tabela 1 de roteamento e encaminhamento (VRF1)

Enlace para o site

Tabela 2 de roteamento e encaminhamento (VRF2)

Enlace para o site

Tabela n de roteamento e encaminhamento (VRFn)

Enlace para o site

Figura 2.13 - Criao de VRF 26

2.4.2.2 - Modelo Operacional

Dois fluxos fundamentais de trfego ocorrem em uma VPN BGP MPLS: Um fluxo de controle que usado para distribuio de rotas VPN e estabelecimento de LSPs (Label Switched Paths); Um fluxo de dados que usado para os usurios encaminharem seu trfego de dados. Topologia de Rede Simples A figura 2.14 mostra uma topologia de rede simples, em que um provedor de servio entrega um servio de VPN BGP MPLS para diferentes empresas. Nessa rede h dois roteadores PEs conectados com quatro diferentes redes de clientes. Rede 1 CE1 10.1/16 PE1 Rede 4 CE4 10.1/16 VRF P P VRF Provedor de Rede P VRF VRF PE2 CE3 CE2 Rede 2 10.2/16

Rede 3 10.2/16

Figura 2.14 - Componente de Rede A conectividade entre as redes dos usurios pode ser descrita pelas seguintes regras: Um computador na rede 1 pode enviar trfego para um computador na rede 2 e vice-versa; Um computador na rede 3 pode enviar trfego para um computador na rede 4 e vice-versa.

27

Fluxo de Controle Em uma VPN BGP/MPLS, o fluxo de controle consiste de dois subfluxos: O primeiro subfluxo de controle responsvel para a troca de informao de roteamento entre os roteadores CE e PE no backbone do provedor e entre os roteadores PEs; O segundo subfluxo de controle responsvel pelo estabelecimento dos LSPs entre os roteadores PEs do provedor de servio. a) Troca de Informao de roteamento Nesse exemplo, PE1 configurado para associar a VRF vermelha com a interface ou subinterface sobre as rotas aprendidas do CE1. Quando CE1 anuncia a rota do prefixo 10.1/16 para PE1, esta ltima habilita uma rota local para 10.1/16 na VRF Vermelha. PE1 anuncia a rota 10.1/16 para PE 2, usando IBGP. Antes de anunciar a rota, PE1 seleciona um rtulo (por exemplo, 222) para anunciar com a rota e designar o endereo de loopback12 como o prximo salto do BGP. A RFC 2547bis suporta espao de endereamento overlapping (Endereo privado definido na RFC 1918) pelo uso de rotas distinguidas (RD Ver captulo 4, passo 5) e a famlia de endereo de VPN-IP4. A RFC 2547bis constri a distribuio de informao de roteamento tambm nos roteadores PEs pelo uso de rotas baseadas em filtros dos atributos estendidos do BGP (rotas targets). Quando o PE2 recebe as rotas do PE1, determina se dever instalar a rota para o prefixo 10.1/16 dentro da VRF vermelha atravs dos filtros baseados nos atributos estendidos do BGP. Se PE2 decide instalar as rotas na VRF vermelha, ento ele anuncia a rota pelo prefixo 10.1/16 para o CE 2. b) Estabelecimento do LSP

12

Loopback Cada roteador PE necessita de um endereo nico (Usualmente chamado de loopback) que utilizado para alocar um rtulo e habilitar o encaminhamento dos pacotes da VPN atravs do backbone.

28

Os roteadores PEs estabelecem sesses MP-BGP entre os roteadores de bordas PEs para trocar rotas de clientes. O trfego da rede do provedor passa atravs do LSP (Label Switched Path Caminho Comutado de Rtulo) pr-estabelecido atravs dos protocolos de sinalizao LDP ou RSVP-TE. O roteador PE adiciona dois rtulos como prefixos para cada pacote do trfego IP do cliente. O rtulo mais externo identifica o prximo salto ao longo do LSP do provedor de rede, enquanto o rtulo mais interno identifica a VPN particular do cliente, conectada no roteador de destino. A informao do rtulo trocada durante a sesso de configurao MP-BGP. Uma limitao do uso convencional do BGP4 para o suporte s VPNs BGP/MPLS que ele foi originalmente designado para transportar informao somente da famlia de endereamento IPv4. Em funo dessa limitao, o IETF est trabalhando para padronizar o Multiprotocol Extensions for BGP4 Extenso do Multiprotocolo BGP4. Essa extenso foi originalmente definida na RFC 2283 e mais tarde atualizada na RFC 2858. A extenso permite ao BGP4 transportar informao de roteamento de mltiplos protocolos (IPv6, IPX, VPN-IPv4,etc.) da camada de rede entre os PEs da VPN BGP/MPLS. As VPNs BGP/MPLS permitem a troca de informao de roteamente da famlia de endereos VPNIPv4 entre os PEs do backbone da rede, sendo conhecido como MP-BGP. A referncia [8] aborda com mais detalhes esse tema. Para usar o MPLS para o encaminhamento do trfego da VPN por meio do backbone do provedor, Um LSPs deve ser estabelecido entre o roteador PE que aprende a rota e o roteador PE que anuncia a rota. A figura 2.15 ilustra esse conceito. Rede 1 10.1/16 VRF PE1 Rede 4 CE4 10.1/16 VRF P P P
LSP

CE1

Provedor de Rede
LSP

CE2 VRF PE2 CE3 VRF

Rede 2 10.2/16

Rede 3 10.2/16

Figura 2.15 Estabelecimento do LSP

29

LSPs podem ser estabelecidos atravs das redes dos provedores de servio, usando Protocolo de Distribuio de Rtulo (LDP) ou Protocolo de Reserva de Recursos (RSVP). O provedor usa LDP se deseja estabelecer um LSP de melhor esforo entre dois roteadores PEs. O provedor usa RSVP se deseja desempenho por largura de banda no LSP, ou usar engenharia de trfego para selecionar um caminho explcito para o LSP. Suporte de LSP baseado em RSVP permite definio a uma qualidade de servio especfica. Para garantir interoperabilidade, todos os roteadores PE e P devem estar preparados para suportar, no mnimo, LDP. Se o provedor definiu usar LDP, uma topologia em malha completa (full-mesh) de LSPs melhor esforo (best effort) estabelecida por meio do backbone para suportar conectividade PE-PE. Se o provedor definiu usar RSVP, LSPs baseados em RSVP tm maior prioridade que os baseados em LDP. LSPs baseados em LDP ou RSVP devem existir entre um par de roteadores PE. Fluxo de Dados A figura 2.16 apresenta o fluxo de dados da VPN atravs do backbone do provedor de servio de um ponto de presena do usurio para um outro. Assume-se que o computador 10.2.3.4 na rede 2 deseja comunicar-se com o servidor 10.1.3.8 na rede 1. Rede 1 CE1 Server 10.1.3.8 PE1 Rede 4 10.1/16 CE4 VRF P P VRF
LSP

Provedor de Rede P VRF

CE2 Rede 2 Computador 10.2.3.4 PE2 VRF CE3 Rede 3 10.2/16

Figura 2.16 Fluxo de Dados 30

O computador 10.2.3.4 encaminha todos os pacotes de dados para o servidor 10.1.3.8 (gateway default). Quando chegam os pacotes no CE2, este realiza uma longa procura de rotas e encaminha os pacotes IPv4 para o PE2. PE2 recebe os pacotes e realiza uma procura de rota na VRF Vermelha, obtendo a informao de encaminhamento: O rtulo do MPLS anunciado pelo PE1 com as rotas (rtulo=222); O next hop (prximo salto) BGP para a rota (O endereo de loopback do PE1); Subinterface de sada para o LSP de PE2 para PE1; O rtulo inicial MPLS para o LSP de PE2 para PE1; Conforme comentado anteriormente, o trfego dos usurios so encaminhado de PE2 para PE1, usando MPLS, com a pilha de rtulo (label stack) contendo dois rtulos. Para esse fluxo de dados, PE2 o LSR de ingresso para o LSP e PE1 o LSR de egresso para o mesmo LSP. Antes de transmitir o pacote, o PE2 coloca o rtulo 222 dentro da pilha, marcando como ltimo rtulo. Como visto, este rtulo originalmente instalado na VRF vermelha quando PE2 recebe, via IBGP anncios do PE1 para a rota 10.1/16. O PE2 coloca o rtulo associado ao LSP para o PE1 dentro da pilha marcando no rtulo mais externo (top label). Depois de criada a pilha de rtulo (label stack), PE2 encaminha o pacote MPLS atravs da interface no primeiro roteador P ao longo do PE2 para PE1. Os roteadores Ps comutam pacotes por meio do ncleo da rede do backbone do provedor de servio baseado no rtulo mais externo da pilha. No penltimo roteador com relao a PE1, o rtulo mais externo da pilha (top label) retirado e o pacote encaminhado para o PE1. Quando o PE1 recebe o pacote, ele retira o rtulo criando o pacote nativo IPv4. PE1 usa o ltimo rtulo (222) para identificar o CE correspondente ao prximo pulo para 10.1/16. Finalmente, o PE1 encaminha o pacote IPv4 nativo para CE1 que encaminha os pacotes para o servidor 10.1.3.8 na rede 1.

2.5 Implementao de DiffServ em VPN MPLS

Entre as alternativas disponveis para oferecer qualidade de servio s VPNs MPLS, temos atualmente duas arquiteturas em uso:

31

Servios Integrados IntServ [15] Servios Diferenciados - DiffServ [18]

A arquitetura IntServ apresenta problemas de escalabilidade, limitando-se a redes de pequeno a mdio porte. DiffServ, por outro lado, provou ser bastante escalvel pois a maior parte do trabalho feita na borda e, consequentemente, no precisa manter qualquer estado de microfluxo no ncleo como no caso da arquitetura IntServ. A caracterstica aleatria da chegada de fluxos em diferentes classes de servio obriga a utilizao de alguma tcnica para fornecimento da QoS. As principais tcnicas so: provisionamento em excesso dos recursos e provisionamento dinmico. A grande vantagem do provisionamento em excesso a facilidade de implantao, pois aproveita a infraestrutura existente, apenas aumentando a taxa de transmisso ou a capacidade de armazenamento nos dispositivos de comutao. A caracterstica dessa tcnica que normalmente no h classes de servios diferentes e todos os fluxos desfrutam do mesmo recurso e QoS. A principal desvantagem que manter um canal de comunicao com capacidade acima da demanda produz um aumento de custo, induzindo maiores tarifas na prestao do servio. O aprovisionamento dinmico consiste em utilizar canais de comunicao compatveis com a demanda e executar mecanismos de reconfigurao que ofeream a QoS desejada para determinados fluxos. A grande vantagem que h um aproveitamento maior da capacidade da rede atravs do oferecimento de um servio de melhor qualidade mantendo a infra-estrutura dimensionada de acordo com a demanda. Assim, possvel dizer que o aprovisionamento dinmico pode oferecer QoS com um custo menor. A desvantagem desse mecanismo que exige alterao nos equipamentos de rede, alm de introduzir uma complexidade adicional. Em virtude da complexidade dos mecanismos de aprovisionamento dinmico e principalmente em funo do excesso de banda em seus backbone, a maioria das operadoras tem preferido superdimensionar os recursos para obter a QoS desejada. Esse procedimento, no entanto, apresenta um custo muito alto, tanto pela capacidade no utilizada na maior parte do tempo (deve-se aprovisionar pelo pico) como pela necessidade

32

de planejar o crescimento, j que construir infra-estrutura de telecomunicaes exige uma estimativa de trfego futuro, que tende a ser imprecisa. Com o advento das redes de acesso banda larga xDSL, os backbones das operadoras esto encontrando dificuldades para manter os nveis de servios para seus clientes usando apenas superprovisionamento. Tambm a necessidade de oferecer servios com menor custo e preos mais competitivos esto levando as operadoras a implementarem aprovisionamento dinmico. O superprovisionamento se mostrou um modelo adequado no perodo de monoplio do Setor de Telecomunicaes. A utilizao de mecanismos de aprovisionamento dinmico no so suficientes para garantir a qualidade de servio em toda a VPN. necessrio executar o controle de aprovisionamento, bem como um gerenciamento sobre todo o domnio da VPN, isto , em todo o conjunto de equipamentos da operadora e do cliente (CE a CE). A diferenciao de Servios (DiffServ) uma proposta de arquitetura para oferecer recursos de QoS sem o problema da escalabilidade. Nesse caso, os fluxos so agregados em classes de servio com um padro de QoS especfico. Com uma quantidade de classes limitada, a necessidade de recursos computacionais nos roteadores reduzida pela menor quantidade de estados a tratar. Nos backbones onde a operadora deseja disponibilizar solues de VPN BGP/MPLS com classes diferentes de servio para os seus clientes recomenda-se a utilizao de aprovisionamento dinmico com DiffServ. No captulo 5 so realizados testes do servio VPN com QoS baseados na arquitetura DiffServ. A identificao da classe de servio (no modelo sugerido sero seis) feita pela marcao no campo DS Servios Diferencial, antigo campo TOS (Tipo de Servio) no cabealho IP. O campo DS contm um valor chamado codepoint que associado a cada classe de servio. O tratamento que uma determinada classe recebe depende de um conjunto de regras aplicadas a essa agregao, que inclui formas de classificao, escalonamento e tratamento de fila. Esse conjunto de regras chamado PHB Per Hop Behavior, isto , comportamento por n. Um operador de rede que oferece servio DiffServ tem um contrato de servio SLA com o usurio e deve cumprir parmetros de QoS para o trfego do usurio que cruza a VPN, isto , parmetros como retardo, variao do retardo (jitter) e descarte.

33

2.5.1 - Arquitetura DiffServ

Para evitar o problema de escalabilidade da arquitetura IntServ, na qual os roteadores de ncleo no conseguem tratar uma grande quantidade de fluxos, a arquitetura DiffServ foi dividida em dois tipos de roteadores de acordo com a sua posio no domnio: de ncleo ou de borda. Os roteadores de borda ficam na fronteira do domnio e tm a funo de fazer a comunicao com roteadores de outras operadoras de backbone ou clientes. Os roteadores de ncleos encontram-se todos no ncleo da rede, sem contato com outros backbones de operadoras ou clientes, e onde o trfego e a quantidade de fluxos so maiores devido agregao dos trfegos originrios de vrios roteadores de borda. A figura 2.17 mostra esquematicamente a arquitetura de um domnio DiffServ. Na arquitetura DiffServ, os roteadores de borda realizam toda a complexidade de classificao, marcao, suavizao e policiamento. Como esses roteadores tratam uma quantidade menor de fluxos, essas funes, computacionalmente intensas, podero ser realizadas sem prejuzo da escalabilidade. Domnio DiffServ Ncleo Borda Marcador Classificador Policiador

Ncleo Escalonador Gerenciador de filas Borda

Figura 2.17 Arquitetura de domnio DiffServ

Os roteadores de ncleo realizam apenas as funes de classificao, escalonamento e gerenciamento de filas. Como o problema de escalabilidade crtico nos roteadores de ncleo devido a quantidade de fluxos e a demanda de processamento, esses roteadores apenas tratam individualmente cada PHB.

34

Incremento do custo

IntServ DiffServ Best-effort Incremento da complexidade

Figura 2.18 Custo e complexidade de Solues de Servios Diferenciados

2.5.2 - PHBs DiffServ

Os dois principais PHBs padronizados so: Encaminhamento Expresso (EF) e Encaminhamento Assegurado (AF). Os trfegos no classificados nessas classes so chamados de melhor esforo (BE), isto , trfego sem nenhuma garantia de QoS. Encaminhamento Expresso (EF) O servio denominado de Encaminhamento Expresso (EF), definido na RFC 2598, permite a adaptao do modelo de servio garantido da arquitetura IntServ arquitetura de servios diferenciados. Ele oferece garantias de QoS elevadas , com baixos valores de perda, atraso e jitter, fornecendo o equivalente a uma linha privada virtual, com largura de banda fixa entre dois computadores. indicado para aplicaes de telefonia sobre IP, videoconferncia e para a criao de linhas dedicadas em redes privadas virtuais (VPNs). Sua vantagem sobre o servio equivalente na arquitetura IntServ est na simplicidade de implementao, pois no necessrio manter nos roteadores nenhuma informao relativa a fluxos. Geralmente, no deve ser usado RED como o mecanismo de gerenciamento da fila, quando suportando o PHB EF, porque a maioria do trfego baseada em UDP, e UDP no responde diminuio dos pacotes pela reduo da taxa de transmisso. Encaminhamento Garantido (AF) A classe de servio Encaminhamento Garantido (Assured Forwarding AF), definida na RFC 2597, destina-se s aplicaes que demandam da rede um servio mais 35

confivel que aquele de melhor esforo, mas sem todas as garantias de QoS oferecidas pelo encaminhamento expresso. Este servio no oferece limites superiores para o atraso e jitter, mas garante um tratamento preferencial ao trfego que dele se utilize. Ele indicado quando se deseja obter da rede um servio de entrega de pacotes mais consistentes, a fim de oferecer, por exemplo, uma melhor QoS a agregados de trfego, consistindo de rajadas de curta durao com destinos diferentes (o trfego na Web) [51]. O princpio aqui a diviso do trfego em N classes, cada uma com algum nvel de precedncia de descarte (M). A especificao atual define N = 4 e M = 3 (Figura 2.19), embora, em uma situao real, nem todas sejam necessrias. O servio fornecido por uma certa classe independe do servio das demais classes, sendo funo apenas dos recursos alocados para cada classe pelo sistema [35].

Menos precedncia de descarte da classe

AF11 AF12 AF13

AF21 AF22 AF23

AF31 AF32 AF33

AF41 AF42 AF43 Classes de PHB AF

Figura 2.19 - Classes AF Um usurio pode contratar de um provedor um dos quatro servios de encaminhamento diferenciado, cada um com trs nveis de prioridade de descarte. Em situaes de sobrecarga, o trfego de uma classe superior tem menor probabilidade de sofrer congestionamento que o trfego de uma classe inferior. O mecanismo de diferenciao aqui utilizado se baseia na prioridade de descarte: quando este for inevitvel, primeiro se descartam os pacotes pertencentes ao servio de melhor esforo e, s ento, passa-se para os pacotes associados ao servio de encaminhamento garantido, segundo sua classe e nvel de precedncia. Portanto, os pacotes pertencentes ao servio AF so os ltimos a serem descartados em situaes de congestionamento.

36

A tabela 2.1 apresenta os DSCPs recomendados para os quatros grupos AF PHB. Classe AF1 Precedncia Baixa Precedncia Mdia Precedncia Alta 0001010 001100 001110 Classe AF2 010010 010100 010110 Classe AF3 011010 011100 011110 Classe AF4 100010 100100 100110

Tabela 2.1 Recomendao dos valores DSCP AF.

2.5.3 - DiffServ e pacotes MPLS

A combinao de DiffServ e MPLS apresenta uma estratgia muito atrativa para os provedores de servios oferecerem servios de VPN MPLS com Qualidade de Servio (QoS). Algo que pode ser observado que existem 6 bits DSCP e somente 3 bits EXP. Como existem apenas oito valores EXP e 64 valores DSCP (dos quais 21 esto definidos atualmente), como oferecer, ento, servios DSCP no MPLS ?. Em uma rede no modo frame13 (quadro) possvel at trs bits EXP; necessrio mapear vrias classes DSCP para esses bits EXP. Contudo, na prtica, isso no provou ser um problema em redes de produo, pois praticamente nenhuma instalao de Qualidade de Servio (QoS) oferece servios que no possam ser providos com os 3 bits EXP MPLS. Est sendo realizado um trabalho no sentido de definir uma outra soluo denominada de L-LSP, mas no ser abordado neste trabalho. A RFC 3270 [23] trata desse tema.

2.6 - Benefcios das VPNs BGP/MPLS

O maior objetivo das VPNs BGP/MPLS simplificar a operao da rede para os usurios, enquanto permite ao provedor de servio oferecer escalabilidade e servios de

13

Mode Frame o termo usado quando encaminhado um pacote com um rtulo inserido ao pacote, na frente do cabealho da camada 3 ( o cabealho IP, por exemplo).

37

valor adicionado. As VPNs BGP/MPLS tm muitos benefcios. Sero destacados, aqui, os principais: No h restrio do plano de endereos utilizados em cada VPN do usurio. O usurio pode usar outros endereos, globais ou privados. Na perspectiva do provedor do servio, clientes diferentes podem ter endereos sobrepostos (Overlapping). Os roteadores CEs de cada ponto de presena do usurio no trocam informao de roteamento diretamente com outros roteadores CEs. Os usurios no tm de se preocupar com questes de roteamento entre redes porque estas so de responsabilidade do provedor de servio. Usurios no precisam administrar o backbone virtual e nem gerenciar acessos para os roteadores PE ou P. Provedor de Servio no tem um backbone separado ou virtual para administrar cada VPN do usurio. Segurana equivalente ao Frame Relay e ATM Provedor de Servio pode utilizar uma infra-estrutura comum para entregar servios de conectividade Internet e VPN Flexibilidade e Escalabilidade para servios de QoS so suportadas por meio do uso do EXP no shim header (cabealho MPLS) do MPLS ou pelo uso de engenharia de trfego.

38

2.7 Comparando as diversas tecnologias de VPNs

ATM/Frame Relay Estrela e Full Mesh Limitada em configurao full mesh

GRE

IPSEC

L2TP Estrela

MPLS Estrela e Full Mesh

Topologia Escalabilidade - Configurao e gerenciamento

Estrela e Full Estrela e Full Mesh Mesh Limitada em Limitada em configurao configurao full mesh full mesh

Segurana

Alta segurana

Nenhuma segurana, poder ser combinado com IPsec

Alta Segurana

Esttico e Dinmico

PVC e SVC ATM Frum atravs de classes de servios (CBR, ABR, VBR, UBR); Frame Relay usa CIR

Esttico

Esttico

No existem Nenhum limitaes na limite topologia Estrela Usa algoritmo Altamente segura, de similar a autenticao; ATM e pode ser Frame combinado Relay, pode com IPSec ser para trfego combinado com com IPSec criptografia Esttico e Dinmico Dinmico

QoS

QoS IP

QoS IP

QoS IP

MPLS EXP

Dependncia da tecnologia de acesso

Limitada em Frame Relay e No limitada No limitada ATM

Depende de uma tecnologia de acesso PPP

No limitada

Tabela 2.2 Quadro Comparativo das VPNs

2.8 - Resumo de Captulo

Este captulo apresentou os conceitos bsicos da arquitetura VPN BGP/MPLS e DiffServ, que so os assuntos base dessa dissertao. Inicialmente foram apresentados os conceitos de VPNs, modelo overlay e peer. Em seguida, foram apresentadas as caractersticas, vantagens e limitaes de cada modelo para a partir da apresentar a RFC

39

2547 (VPN BGP/MPLS). Ainda neste captulo, foram apresentadas algumas formas de implementao da RFC 2547. Finalmente, DiffServ foi apresentado para permitir a integrao com as VPNs BGP/MPLS e dessa forma ser possvel oferecer para o usurio qualidade de servio. O prximo captulo tratar de uma estratgia de projeto de VPN que ir integrar VPN BGP/MPLS com DiffServ.

40

Captulo 3 Estratgia de implementao proposta

Neste captulo apresentada uma estratrgia para construir VPN MPLS para aprovisionamento de recursos de rede em um domnio IP. A estratgia tem como ponto de partida a especificao das classes de servios para uma determinada aplicao. A estratgia formada de 7 passos principais. Antes de ser apresentada a estratgia, ser mostrado um quadro resumo das principais limitaes de IP sobre ATM (IPoATM) encontradas normalmente em um ambiente do provedor que oferece servio baseado em infra-estrutura de IPoATM. A razo da apresentao dessa discusso no contexto desse trabalho porque grande parte dos backbones (Telemar, Telefnica, Embratel e Brasiltelecom) dos provedores de VPN atualmente trabalham com a tecnologia IPoATM. Para a formao de VPN MPLS necessrio que o provedor faa uma migrao para MPLS. A tabela 3.1 a seguir faz uma comparao entre as principais diferenas entre as opes disponveis. So apresentadas duas opes que devem ser avaliadas em uma migrao de IPoATM para MPLS: MPLS baseado em Clula e MPLS baseado em Roteador. O anexo B apresenta informaes relacionadas a esse tema.

41

3.1 Comparao entre IPoATM, MPLS baseado em Clula e MPLS baseado em Roteador
MPLS baseado em Clula refere-se ao conjunto de procedimento que define como um comutador ATM pode funcionar como um LSR14 e comutar clulas, baseado no contedo dos campos VPI ou VPI/VCI das clulas. MPLS baseado em Roteador refere-se ao conjunto de procedimentos que definem como um roteador IP pode funcionar como um LSR, comutando pacotes baseado no rtulo mais externo transportado no shim header (cabealho MPLS) do pacote. IP over ATM Um plano de controle simples de gerncia Um nico tipo de equipamento para gerncia. Eliminao do overhead Clula da ATM Suporte nativo para IP DiffServ CoS Eliminao do IGP No No Sim No No Sim No MPLS baseado em clula Sim MPLS baseado em Roteador Sim

No No

No Sim

Sim Sim

Tabela 3.1 Comparao: IPoATM, MPLS baseado em clula e roteador

14

Um Label-Switching Router (LSR) um equipamento que implementa na rede MPLS os planos de controle e encaminhamento

42

3.1.1 - Questes de transio

Para a definio de qual a melhor opo de transio necessrio avaliar os benefcios de cada uma das arquiteturas. Em termos de custos, uma transio direta para MPLS baseado em roteador mais cara que uma transio para MPLS baseada em clula, porque ser necessrio comprar novos LSRs baseados em frames. Entretanto, aps completar essa transio, a rede ir imediatamente receber os benefcios de desempenho e escalabilidade, no precisando passar por uma nova transio. Uma transio inicial de IP sobre ATM para comutao de clula MPLS tem menor investimento que uma transio para MPLS baseado em roteador, porque possvel fazer uma atualizao de software e adicionar um mdulo de roteamento nos comutadores ATM. O desafio dessa proposta que em algum momento, eventualmente, ser necessrio fazer uma segunda transio de MPLS baseado em clula para MPLS baseado em roteador quando a limitao de desempenho e escalabilidade de uma estrutura ATM impactar a operao da rede. A combinao do custo de duas transies ser significantemente maior do que se for feita uma transio direta de IP sobre ATM para MPLS baseado em roteador. Para a estratgia apresentada ser considerado um backbone de MPLS baseado em roteador para formao de VPN MPLS. Os passos que fazem parte da estratgia para a construo de VPN baseada em MPLS so: Passo 1 - Especificao dos requisitos da aplicao o Classificao dos principais aplicativos e seus parmetros. Passo 2 - Mapeamento e Diviso dos aplicativos em mltiplas Classes de Servios o Dados (Best Effort)15 16 Classe 0 o Dados de Misso Crtica AF4 Classe 1 o Dados de Gerenciamento AF3 Classe 2 o Dados de Suporte a Negcio AF2 Classe 3 o Dados No Crticos AF1 Classe 4 o Voz (EF) Classe 5
15

Essa classe de servio, mesmo sendo Best Effort, trabalha sobre um backbone IP privativo e no Internet

43

Passo 3 - Seleo da Tecnologia de acesso o Frame Relay o ATM o DSL o Linha Dedicada Passo 4 - Seleo do Tipo do CPE/CE o Com QoS o Sem QoS Passo 5 - Configurao da VPN IP MPLS o Definir as configuraes dos Roteadores Virtuais (VRF). o Definir e configurar o Identificador de rotas17 (Identificador da VPN do usurio) o Definir e configurar as polticas de importao e exportao de rotas (RT) o Configurar o enlace PE-CE o Associar a interface CE previamente definida nas VRFs o Configurar o Multiprotocolo BGP. Passo 6 - Teste de Conectividade e Isolamento da VPN Passo 7 - Teste de QoS e CoS da VPN O passo 1 tem o objetivo de identificar os principais aplicativos encontrados atualmente no ambiente das organizaes e seus requisitos. O passo 2 sugere o mapeamento dos aplicativos em 6 classes de acordo com o padro DiffServ. O passo 3 apresenta uma novidade em relao as VPNs tradicionais que a implementao de VPN com acesso xDSL. O passo 4 avalia os requisitos dos parmetros mais importante dos CE/CPE em funo das classes de servios.Esse passo apresenta uma novidade em relao aos CEs tradicionais, que a nova implementao nos roteadores cisco de VRFs no prprio CE conhecida como Multi VRF. O passo 5 trata da configurao da VPN. Esta configurao de VPN uma das partes mais importante do projeto de VPN MPLS, pois qualquer erro de configurao pode refletir em um usurio de uma determinada VPN ter acesso indevido a outra VPN. Em funo da importncia do passo anterior sugerido o teste de conectividade e isolamento da VPN no passo 6. O passo 7 tem o objetivo de avaliar
17

O termo identificador de rotas (RD) equivale nesse texto a rotas distinguishers ou identificador da VPN

44

se a VPN est priorizando os pacotes e oferecendo os nveis de servio de acordo com a classificao realizada no passo 2. Para isso ser utilizado um software de domnio pblico conhecido como iperf e um ambiente montado para avaliao de desempenho A figura 3.1 apresenta o fluxo da estratgia18 proposta para a formao de VPNs IP MPLS.
Incio

Especificao dos requisitos da aplicao

Mapeamento da aplicao em classes

Teste de Conectividade e Isolamento da VPN

Seleo da tecnologia de acesso

No

Atende?

Sim
Seleo do CPE/CE Teste de QoS e Classes de Servios (CoS)

Configurao da VPN

No

Atende?

Sim

Implementao

Figura 3.1 Fluxo de Formao de VPNs MPLS

18

Essa estratgia conseqncia de vrios projetos e de acordo com as RFCs

45

As VPNs tradicionais tm se preocupado em fornecer, basicamente, conectividade entre os pontos de presena dos usurios usando as tecnologias de acessos tradicionais. Uma das contribuies deste trabalho oferecer uma estratgia de projeto de VPN BGP/MPLS que contemple Qualidade de Servio (QoS) e Classes de Servios (CoS) de CE a CE, utilizando vrias tecnologias de acesso, principalmente xDSL19.

3.2 - PASSOS
Aqui sero apresentados os 7 passos que fazem parte da estratgia da formao de VPN BGP/MPLS.

3.2.1 PASSO 1 Especificao dos Requisitos dos Aplicativos

Para determinar a que classe de servio (CoS) que os aplicativos devem ser classificados necessrio determinar seus requisitos para depois realizar a associao com uma das 6 classes que fazem parte da proposta apresentada. Os aplicativos sero identificados pelas suas respectivas portas UDP/TCP. Alguns aplicativos como FTP (21) e WWW (80) j possuem suas portas padronizadas.

3.2.1.1 Caracterizao dos fluxos de trfego

Um fluxo de rede pode ser caracterizado por sua direo e sua simetria. A direo especifica se os dados viajam em ambas as direes ou apenas em uma direo. A direo tambm especifica o caminho percorrido por um fluxo em sua viagem, da origem at o destino, por uma inter rede. Muitos aplicativos de rede tm requisitos diferentes em cada direo. Algumas tecnologias novas de transmisso, como a ADSL, tiram proveito de requisitos assimtricos. A seguir sero definidos os principais aplicativos que normalmente so encontrados no ambiente do usurio para posterior classificao de acordo com o modelo de 6 classes apresentado.
19

VoIP

A tecnologia de acesso xDSL permite oferecer VPN MPLS com baixo preo para o mercado.

46

Voz sobre IP (Protocolo Internet) a convergncia da tradicional rede de voz e a rede de dados. A implementao de VoIP em uma VPN MPLS requer ateno com alguns parmetros: disponibilidade de banda, perda de pacotes, atraso e jitter (variao do atraso). Videoconferncia Videoconferncia a transmisso de udio e vdeo entre dois ou mais pontos, em ambas as direes e em tempo real, permitindo interatividade entre os participantes. Ela permite ainda o compartilhamento de dados (textos, planilhas, grficos, etc) junto com a transmisso de udio e vdeo. Emulao de Terminal O trfego de Emulao de Terminal usualmente assimtrico. O terminal envia alguns caracteres e o host envia muitos caracteres. O Telnet um exemplo de aplicativo de emulao de terminal que gera trfego terminal/Host. Servidor de Nome e Domnio Este o protocolo que torna possvel que qualquer computador encontre qualquer outro na Internet. O fluxo do trfego DNS segue o modelo cliente servidor. Gerenciamento da rede e sistema Pode existir caso em que o usurio da VPN deseja que seu trfego de gerncia seja tratado de forma diferente em relao a outros trfegos. O perfil de trfego do gerenciamento da rede e sitema seguem o modelo dos protocolos ICMP, SNMP e Telnet. Protocolos de Transferncia de Arquivo (FTP) O FTP, especificado atravs da RFC959, baseia-se no modelo Cliente x Servidor e prov servios de transferncia, renomeao e remoo de arquivos. Prov tambm a criao, remoo e modificao de diretrios, entre outros. Para a prestao de tais servios, so estabelecidas duas conexes TCP entre o cliente e o servidor: uma conexo de controle, usada na transferncia de comandos, e outra de dados. A confiabilidade das transferncias de arquivos realizadas fica por conta do TCP, j que o FTP no implementa nenhum controle adicional sobre os arquivos, a no ser a exigncia da senha do usurio para permitir a transferncia. E-mail

47

O Sistema de Correio Eletrnico constitui-se de uma srie de servidores cooperantes interagindo atravs do protocolo SMTP. Essa transmisso feita mediante o estabelecimento de um canal de comunicao, conexo TCP, pelo qual transitaro as mensagens conduzidas por meio do protocolo SMTP. Grupo de Discusso Grupo de discusso envolve grande quantidade de pessoas. O trfego nesse tipo de aplicao no normalmente crtico ao negcio da organizao. HTTP O HTTP (Protocolo de transferncia Hipertexto) provavelmente o protocolo cliente/servidor de utilizao mais ampla no momento. Os clientes utilizam um aplicativo navegador da Web para se comunicar com os servidores Web. O fluxo de trfego bidirecional e assimtrico. O fluxo de trfego HTTP nem sempre ocorre entre o navegador da Web e o servidor da Web, devido ao cache. NFS NFS (Sistema de Arquivo de Rede) um conjunto de protocolos de sistema de arquivos distribudos desenvolvido pela Sun Microsystems e que permite acesso a arquivos remotos atravs de uma rede. De acordo com as prioridades e nveis de SLA desejados pelo usurio, os diferentes tipos de aplicativos e trfego que iro trafegar nas Redes VPN MPLS devem ser classificados em uma das 6 classes de servios, segundo as RFCs 2474 e 2475 (DiffServ) conforme a figura 3.2, complementados pela RFC 2597 (Assured Forwarding PHB) e pela RFC 2598 (Expedited Forwarding), alm de todo trfego no explicitamente definido nas referidas RFCs:

48

Aplicao Classificao

EF Classe 5

AF

BE Classe 0

AF4 Classe 4

AF3 Classe 3

AF2 Classe 2

AF1 Classe 1

Figura 3.2 Classificao das aplicaes de acordo com DiffServ importante que o provedor de servio implemente algumas alternativas para situaes de contigncia na rede. Uma das possveis implementaes seria uma configurao mnima para as classes de servio Misso Crtica (AF4) e Gerenciamento (AF3), e todo o trfego restante ser classificado como melhor esforo (B_E). A tabela 3.2 mostra os requisitos de QoS para algumas aplicaes tpicas. Aplicaes Tpicas e-mail FTP Telnet Mdia Streaming Videoconferncia VoIP Bandwidth Baixo Altas rajadas Baixas rajadas Mdia moderada Alta Moderada Requerimentos de QoS Latncia Moderado Sensvel Crtica Crtica Jitter Sensvel Crtica Crtica Perda de Pacote Sensvel Sensvel Sensvel

Tabela 3.2 Requerimentos das Aplicaes tradicionais

3.2.2 PASSO 2 Diviso dos Aplicativos em mltiplas classes

Esse passo apresenta a estratgia de classificao de pacotes com base nos aplicativos dos usurios A poltica de classificao ser de acordo com a requisio do

49

usurio. A tabela 3.3 apresenta os principais aplicativos. medida que outras aplicaes sejam necessrias, novas regras de mapeamento precisam ser criadas. Para oferecer servios diferenciados de acordo com a aplicao do usurio, os trfegos devem ser agrupados em classes segundo os requisitos das aplicaes. Cada classe deve ser diferenciada pela rede de acordo com o servio definido na configurao da QoS (Qualidade de Servio) para essa classe. A classificao o ato de examinar os pacotes da aplicao/porta do usurio para decidir por qual valor o DSCP deve ser definido no pacote e mapeado em EXP na rede do provedor. Essa classificao ocorre na borda da rede MPLS (equipamento PE). Na estratgia proposta so recomendadas 6 classes de servios as quais se encontram indicadas a seguir:

3.2.2.1 Padro BE - Classe Dados Padro Best Effort (BE) Classe 0

Classe de servio correspondente ao trfego de menor prioridade. equivalente ao servio Melhor Esforo disponvel na Internet. Essa classe de servio oferece, basicamente, conectividade com nenhuma garantia. Muitas aplicaes de dados, tais como o Protocolo de Transferncia de Arquivo (FTP), trabalham adequadamente com o servio Melhor Esforo. Todo trfego no explicitamente atribudo s quatro classes AF e classe EF ficar nesta classe. Sua finalidade permitir um valor muito baixo de recursos para trfegos no previstos ou ainda no identificados como trfegos importantes. Isso garante que tais tipos de trfego possam fluir se houver recursos disponveis na rede, porm, impede que estes afetem negativamente as demais classes.

3.2.2.2 Classe Dados com prioridades - AF

Classe de servio que prov uma priorizao de trfego das aplicaes crticas do usurio em relao a dados Melhor Esforo. Isso significa para o provedor de servio a possibilidade de oferecer nveis de servios diferentes por cliente e aplicao. A proposta apresentada neste trabalho sugere a diviso da classe de dados com prioridades em 4 subclasses:

50

AF1 Aplicaes no Crticas Classe 1

Aplicaes com mensagens de tamanho muito variado e no imprescindveis para o atendimento imediato aos usurios. Embora se trate de contedo importante, no so aplicaes que podem esperar por disponibilidade de recursos da rede da classe padro BE. Todas aplicaes classificadas nessa classe ter prioridade em relao as aplicaes padro BE. AF2 Aplicaes de Negcios Classe 2

Aplicaes no interativas, com grande volume de dados importantes para o atendimento complementar aos usurios da organizao, porm, sem necessidade de um tempo de resposta reduzido. Essas aplicaes sero consideradas prioritrias em relao s aplicaes no crticas e de melhor esforo. AF3 Gerenciamento Classe 3

Aplicaes de gerenciamento de redes e de sistemas, que necessitam de uma banda mnima para atividades de suporte tcnico, mesmo em situaes de congestionamento severo da rede. No ocupam banda suficiente para interferir nos demais trfegos em condies normais de operao. Essa classe ter prioridade em relao as anteriores.

AF4 Misso Crtica Classe 4

Aplicaes interativas crticas para o negcio e trfego DNS que exigem entrega garantida e tratamento prioritrio. A aplicao multimdia tambm ser includa nessa classe. Multimdia possui requisitos de qualidade de servios diferentes de aplicaes tradicionais como Simple Mail Transfer Protocol (SMTP), que trabalham bem com a classe de dados Melhor Esforo. A figura 3.3 apresenta o resultado da influncia das perdas de pacotes [53] para uma classe multimdia de uma simulao realizada para anlise das perdas de pacotes de 1%, 3% e 8%.

51

a 1% .

b 3% Figura 3.3 Efeitos da perda de pacotes

c 8%

3.2.2.3 Classe Tempo Real EF Classe 5

Aplicaes sensveis a retardo (delay) e variaes de retardo da rede (jitter), que exigem priorizao de pacotes e reserva de banda so adequadas para essa classe. Um servio que pode ser oferecido pela arquitetura VPN MPLS o trfego diferenciado de pacotes de voz. Esse trfego possui requisitos de Qualidade de Servio (QoS) que raramente podem ser atendidos por uma rede IP Melhor Esforo. Os parmetros de QoS relevantes para o trfego de voz so o atraso, a variao do atraso (jitter) e a taxa de perdas de pacotes. Esses parmetros refletem a continuidade de um fluxo de voz. Dada a natureza de interatividade do servio telefnico, o atraso o fator mais crtico.

3.2.2.4 Mapeamento dos aplicativos/portas em Classes

Este item apresenta a estratgia de classificao de pacotes, onde os pacotes sero classificados baseados nos aplicativos/portas utilizados pelos usurios. Aps uma anlise de quais os principais aplicativos disponveis no mercado e utilizados pelas organizaes, foi realizada a classificao abaixo. Cada aplicativo identificado por um nmero de porta TCP/UDP. As portas TCP/UDP so mapeadas em uma das 6 classes apresentada acima. No captulo 5 sero mostradas alguns testes realizados. Para isso foi utilizado uma ferramenta conhecida como iperf, basicamente essa ferramenta implementa a arquitetura cliente/servidor, e permite criar conexes TCP/UDP, sendo os nmeros das portas para os testes as definidas na tabela abaixo.

52

Classe de Servio Tempo Real (EF) Classe 0 Misso Crtica (AF4) Classe 1 Gerenciamento (AF3) Classe 2

Aplicativo Voz RTP/RTCP Transacional Sistema on line Multimdia RTP/RTCP DNS Gerenciamento da Rede e Sitema SNMP Telnet para controle remoto http/https CADView-3D

Porta/UDP/TCP * ** * 53 ** 161/162 23 80/443 649 150 1525 2439 ** 25 ** ** 21 **

Portas para teste 5001

5002

Suporte a Negcio (AF2) Classe 3

SQL-Net Oracle Sybase e-learning

5003

No crtico (AF1) Classe 4

Correio Eletrnico (SMTP) Browser (Intranet/Internet) Grupos de discusso FTP Vdeo Streaming NFS

Padro (BE) Classe 5

5004

Tabela 3.3 Classificao das aplicaes

(*)

Aplicaes real-time baseadas em RTP/RTCP necessitaro que o cliente informe qual o intervalo de

portas UDP que ser utilizado.

(**) Utilizao de portas no autorizadas pelo IANA.

3.2.2.5 Mapeamento dos campos DSCP em EXP

A proposta apresentada possui seis Classes de Servio previstas (voz-tempo real, misso crtica, gerenciamento, aplicaes de negcios, aplicaes no crticas e dados

53

padro melhor esforo) conforme tabela 3.3. Para cada uma destas classes previsto um tratamento diferente ao longo de toda a VPN. O modelo de QoS adotado est baseado em DiffServ. A classificao e marcao de DSCP dos pacotes IP ser realizada pelos CPEs/CEs, e a marcao de EXP dos pacotes MPLS ser feita pelos PEs envolvidos. A partir destas marcaes sero realizadas as classificaes em filas em cada roteador da Rede IP do Provedor. Cada fila est associada a uma Classe de Servio (CoS), onde sero definidas caractersticas de prioridade para transmisso (WFQ, WRR), tamanho da fila (buffer), polticas de controle de fluxo (WRED). As marcaes IP no DSCP sero mapeadas no campo EXP (MPLS), conforme tabela 3.4:
Classes de Servio (CS) Voz Tempo Real No Crtica Suporte a Negcio Gerenciamento Misso Critica Dados Best Effort (BE) Porta X1 X2 X3 X4 X5 X6 Valores de DSCP (IP) EF PHB AF11 PHB AF21 PHB AF31 PHB AF41 PHB DF PHB 001 010 001 010 010 010 011 010 100 010 000 000 EXP (MPLS) 001 001 010 011 100 000

Tabela 3.4 Mapeamento do DSCP em EXP

3.2.3 PASSO 3 - Determinao da tecnologia de acesso

Os servios oferecidos pelas VPNs MPLS foram inicialmente providos atravs de conexo permanente do CPE/CE20 do usurio com o roteador PE. Exemplos de tecnologias de acesso disponveis so as Linhas Dedicadas (Leased Lines), Frame Relay ou Asynchronous Transfer Mode (ATM), a figura 3.4 a seguir mostra essas alternativas. CE Frame Relay

PE VPN/MPLS

PE

Linha dedicada

CE

CE ATM

Figura 3.4 Formas de acessos tradicionais das redes VPN/MPLS

20

O termo CPE utilizado normalmente pelos provedores de servios, enquando CE utilizado nas RFCs

54

Para prover servios escalveis de VPN MPLS fim a fim, o provedor de servio deve possuir uma infra-estrutura de rede que suporte a integrao de diferentes tecnologias de acesso em uma VPN MPLS. Acessos Frame Relay, ATM e Linha Dedicada so tecnologias bem conhecidas. O prximo item focar em um novo mtodo de acesso a VPN MPLS conhecido como xDSL.

3.2.3.1 Provendo acesso xDSL para as VPNs MPLS

DSL usa ATM como um mecanismo bsico de transporte. Podem ser utilizados vrios mtodos de encapsulamento, dependendo do tipo de aplicao requerida. Todos os encapsulamentos usam a camada de adaptao 5 do ATM para segmentar dados em clulas e a RFC 1483 [13] para permitir o transporte de mltiplos protocolos sobre o mesmo PVC ATM. A RFC 1483 trabalha com dois mtodos. O primeiro mtodo permite que mltiplos protocolos sejam transportados sobre o mesmo PVC; o segundo faz a multiplexao implcita do protocolo por PVC, isto , um protocolo por PVC. Os possveis mtodos de encapsulamento so apresentados na figura 3.5. PPPoE PPPoE Ethernet PPPoA IP PPPoA Ethernet RFC 1483 RFC 1483 Bridged RFC 1483 Routed

RFC 1483 snap ou VC mux ATM AAL5 DSL Layer Figura 3.5 Formato de Encapsulamento DSL Cada um desses mtodos de encapsulamento e seu funcionamento com uma rede VPN MPLS para acesso remoto ser abordado no anexo C.

55

CPE DSL

DSLAM

PE Backbone MPLS VPN

Figura 3.6 VPN/MPLS com acesso ADSL As formas de conexo DSL com a VPN MPLS basicamente consistem de um PVC entre o CPE DSL e o PE. O DSLAM o concentrador dos acessos xDSL, o anexo C detalha essas formas de conexes.

3.2.3.2 Procedimento para atendimento com vrias tecnologias de acesso VPN MPLS
A simplificao na interoperabilidade das redes com tecnologias heterogneas por meio do MPLS veio possibilitar que as VPNs MPLS sejam atendidas por vrias formas de acesso21, como: Frame Relay, Leased Line, ATM e xDSL. Os custos de implementao dessas tecnologias so, no entanto, muito diferentes entre si. Como conseqncia, sugerido o modelo de atendimento descrito abaixo para uma operadora que tem como objetivo maior rentabilidade na construo e venda do servio. A primeira alternativa o atendimento via xDSL, caso seja possvel atender os requisitos das aplicaes (Ex: Velocidade) dos usurios e haja disponibilidade de acesso na localidade onde o usurio se encontra. Caso no seja possvel o atendimento por xDSL, a segunda alternativa visando o menor custo seria uma linha dedicada do cliente at o PE mais prximo. A terceira alternativa o atendimento atravs de acesso Frame Relay

21

Alm das formas de acesso mostrado acima, as operadoras comeam a trabalhar com acesso metroethernet.

56

A ltima alternativa o acesso ATM, em funo do alto custo da tecnologia dos equipamentos do usurio para implementar o protocolo ATM. DSL

Atende os requisitos

No

Leased Line

Atende os requisitos

No

Sim Implementa

Sim Implementa

Frame Relay

Atende os requisitos

No
ATM

Atende os requisitos

Sim Implementa Figura 3.7 Fluxo de escolha do melhor acesso

Sim Implementa

3.2.4 Passo 4 - Determinao do CPE

Nesse ponto do trabalho analisar-se- os principais aspectos no dimensionamento do CPE para determinadas classes de servios. Nos testes (captulo 5) realizados foram utilizados o modelo Cisco 827 com maior nfase nas caracterissticas apresentadas no item 3.9.2. A razo da anlise do CPE porque a QoS da VPN depende da marcao do pacote no CPE. Tambm, ser apresentado nesse contexto a implementao recente da Cisco em CPE, conhecida como VRF lite, ou seja, habilita a configurao de Mltiplas VRFs nos CPEs. Os CPEs podem ser divididos de acordo com as seguintes classes de servios:

57

3.2.4.1 Acessos sem QoS Classe BE Best Effort

Para as classes de dados padro Melhor Esforo (Best Effort), os CPEs/CEs tradicionais sem capacidade de classificao dos pacotes podero ser utilizados. Em funo da simplicidade do CPE, o seu custo bastante reduzido. As funes normalmente exigidas por esses CPEs so: Interfaces Wan: DSL (PPPoA e DHCP) e Frame Relay Interfaces Lan: Fast Ethernet 10/100 Protocolos de Roteamento: RIPv2 e OSPF Gerncia: SNMP Translao de Endereos de Rede: NAT

3.2.4.2 Acessos com QoS Classes AF (Misso Crtica, Gerenciamento, Suporte a Negcios e Aplicaes no crticas) e EF (Voz):
Para acessos com QoS para as Classes AFs e EF, os CEs devem apresentar algumas caractersticas que so fundamentais para o desempenho de uma VPN MPLS com qualidade de servio: Possibilidade de definio das classes de servios de acordo com a aplicao do usurio. O CPE deve possuir mecanismos de classificao dos pacotes, podendo ser combinados em: o Endereo IP de origem/destino; o Porta TCP / UDP de Origem / Destino; o Protocolos (p.ex. http, ftp e RTP/RTCP);; Mecanismos de Priorizao por CoS, abaixo ou equivalentes: o WFQ (Weighted Fair Queuing) ou WRR (Weighted Round Robin); o LLQ (Low Latency Queuing) ou Strict Priority; Fragmentao em Layer 2: o FRF.12 (Frame Relay Fragmentation Implementation Agreement); Buffer para armazenamento de pacotes em caso de congestionamento, com possibilidade de controle do dimensionamento por Classe de Servio;

58

Suporte a voz: o Suporte a H232 o Suporte a SIP o Suporte a MGCP

3.2.4.3 Mltiplas VRFs nos CPEs (Multi VRF CE)

Os CPEs das VPNs MPLS tradicionais no tm nenhum mecanismo para garantir privacidade da rede atrs do CE. Normalmente a privacidade garantida atravs da colocao de um novo Switch (Comutador), onde configurada uma VLAN para cada departamento (Figura 3.8).

Figura 3.8 - Usando um Switch para segmentar uma LAN Outra possibilidade adicionar um novo roteador para cada departamento como mostra a figura 3.9.

59

Figura 3.9 Segmentao da Lan atravs de um roteador Essas solues envolvem a instalao de novos equipamentos como switch/comutador e roteador, alm de aumentar a necessidade de gerenciamento. Uma alternativa elegante para superar as dificuldades acima foi desenvolvida atravs de Mltiplas VRFs. As Multi-VRF (Mltiplas VRFs) no CPE/CE uma nova facilidade introduzida recentemente nos equipamentos Cisco. Multi-VRF expande a capacidade de VRF no roteador PE para o roteador CE no modelo da VPN MPLS. O roteador CE fica habilitado em manter vrias tabelas separadas (VRFs). Isso permite oferecer o nvel de segurana e privacidade das VPN MPLS dentro do ambiente da LAN do usurio. Os roteadores CEs utilizam as VRFs para criar VLANs no ambiento da rede local do usurio. Cada VRF no roteador CE mapeada em uma VRF no roteador PE. No existe nenhuma troca de rtulo entre PE e CE. A conexo entre PE e CE no suporta LDP. Na figura 3.10 so configurado algumas VRFs por departamento. Cada subinterface est vinculada a uma VRF da VPN respectiva.

60

Figura 3.10 Configurando VRF no CE por departamento A figura 3.10 ilustra um exemplo em que as Multi-VRF CE podem ser usadas nos roteadores CEs. A conexo entre o roteador PE e a rede MPLS usa os mesmos mecanismos apresentados no captulo 2. Nesse exemplo, o roteador CE associa uma VRF especfica para cada departamento conectado na interface e troca informaes com o roteador PE, em seguida as rotas so instaladas dentro da Multi-VRF do CE.

3.2.5 - PASSO 5 Configurao da VPN MPLS

No prximo captulo ser analisada a configurao da VPN, esse passo o mais crtico, pois qualquer configurao indevida da VPN pode significar um acesso no autorizado de um cliente de uma determinada VPN em outra.

3.2.6 Passo 6 Teste de Conectividade e Isolamento das VPNs MPLS

Esse passo ser analisado em detalhes no captulo 5. Os mecanismos necessrios a este passo foram apresentados no captulo 2 e, na estratgia proposta, permitam que as VPNs MPLS implementem perfeito isolamento e conectividade entre as

61

mesmas. Para certificar essa funcionalidade necessrio realizar alguns testes para validar esse passo.

3.2.7 Passo 7 - Teste de QoS das VPNs MPLS

Esse passo ser analisado em detalhes no captulo 5, pois como a estratgia proposta baseada em oferecer QoS fim a fim na VPN de acordo com os aplicativo, necessrio que os roteadores CE e PE seja avaliados em condies normais e anormais de congestionamento.

3.3 - Resumo do Captulo

Este captulo apresentou uma estratgia de construo de VPN MPLS com qualidade de servio fim a fim. Para que isso fosse possvel, a estratgia foi dividida em 7 passos. Inicialmente foi feita uma avaliao que deve ser realizada pelo provedor de servio com o objetivo de identificar qual a melhor forma de implementar VPN MPLS no ncleo da Rede. O primeiro passo foi voltado para a anlise bsica dos requisitos das aplicaes do usurio, pois como o mtodo baseado em diferentes nveis de servios, a rede precisa conhecer quais os aplicativos/portas que devem ser priorizados em relao a outros. O segundo passo o mapeamento dos aplicativos em uma das classes EF, AF (AF1, AF2, AF3 e AF4) ou BE. No terceiro passo definida a tecnologia de acesso. No caso das VPNs MPLS so possveis vrias formas de acesso, sendo que a estratgia apresenta uma nova forma de acesso xDSL que, baseado principalmente no seu baixo custo, tem a tendncia de oferecer servio de VPN/MPLS com preos bastante inferiores em comparao aos tradicionais. A determinao do CE ou CPE realizada no passo 4 e o objetivo simplesmente certificar que os CEs iro atender s especificaes das aplicaes (Ex: VoIP) e do acesso. Tambm apresentada uma recente implementao nos CE/CPE que permite a criao de mltiplas VRFs. O passo 5 o mais importante em um projeto de VPN MPLS. Em funo disso ser dado maior nfase a ele no captulo 4. Os passos 6 e 7 tratam da questo de conectividade, isolamento e qualidade de servio. O objetivo validar se a VPN segura e oferece o desempenho definido pelo SLA.

62

Captulo 4 Configurao da VPN

No captulo 3 foi apresentada a estratgia de projeto de VPN MPLS, sendo a mesma formada de 7 passos. Neste captulo ser exposto um estudo de caso com o objetivo de validar o passo 5 que trata a configurao da VPN MPLS. A configurao ser tratada em um captulo exclusivo em funo de sua importncia e criticidade, pois uma configurao indevida de uma rota de determinada VPN em outra, significa o acesso a mesma por usurio no autorizado. Os conceitos de RD22 e RT23 que so fundamentais na arquitetura de VPN MPLS sero apresentados.

4.1 - Passo 5 Configurao da VPN IP MPLS

A partir dos conceitos bsicos da arquitetura da VPN BGP/MPLS apresentados nos captulos anteriores, possvel entender como implementar essa arquitetura em termos da configurao da VPN MPLS do estudo de caso abaixo. Para prover servios de VPNs por meio de backbone VPN/MPLS as seguintes configuraes so necessrias: Definir as configuraes dos Roteadores Virtuais (VRF); Definir e configurar o identificador de rotas/VPN (RD); Definir e configurar as polticas de importao e exportao de rotas (RT);
22 23

RD Route Distinguisher identifica a VPN de cada usurio RT Route Targets identifica as rotas que a VRF pode importar ou exportar

63

Configurar os enlaces PE-CE; Associar a interface CE previamente definida nas VRFs; Configurar o Multiprotocolo BGP.

A configurao do estudo de caso mostrar as principais preocupaes que devem ser consideradas na configurao de VPN MPLS. Estudo de Caso: A topologia apresentada na figura 4.1 uma estrutura de VPN bsica que prov conectividade um a um entre as redes dos usurios, usando o modelo peer discutido no captulo 2. A figura 4.1 apresenta o caso de um usurio que migrou para a topologia de VPN MPLS, e essa ser usada para mostrar as principais etapas de configuraes da VPN MPLS.
VPN A Rio de Janeiro

CE

VPN B Rio de Janeiro

VPN B Florianpolis

CE
SuperCom

Rio de Janeiro

VPN B

PE PE PE
Curitiba Braslia So Paulo

Campinas

CE

VPN A Porto Alegre

VPN A So Paulo

CE Figura 4.1 Topologia VPN/MPLS Intranet

CE

Na figura 4.1 acima, o Backbone VPN/MPLS do provedor de servio SuperCom tem duas VPNs definidas como VPN A e VPN B. O provedor de servio utiliza os protocolos de roteamento RIPv2 e rota esttica para aprender as rotas das VPNs dos usurios. Os sites das VPN A em Porto Alegre e a 64

VPN B em Florianpolis usam RIPv2 para se comunicarem com o backbone MPLS/VPN. Os sites das VPN B no Rio de Janeiro e Campinas, VPN A em So Paulo e Rio de Janeiro usam roteamento esttico. A tabela 4.1 mostra os endereos para as VPNs dos usurios e os endereos de loopback24 usados pelo provedor de servio para as sesses de BGP. Empresas Empresas Ponto de Presena Florianpolis VPN B Rio de Janeiro Campinas Porto Alegre VPN A Rio de Janeiro So Paulo So Paulo (Loopback) SuperCom Curitiba (Loopback) Rio de Janeiro (Loopback) Subnet 195.12.2.0/24 10.2.2.0/24 10.2.1.0/24 10.2.1.0/24 10.1.2.0/24 196.7.25.0/24 194.22.15.1/32 194.22.15.2/32 194.22.15.3/32 Prot. de Roteamento RIPv2 Roteamento esttico Roteamento esttivo RIPv2 Roteamento esttico Roteamento esttico

Tabela 4.1 Endereos das VPNs dos usurios e loopback do provedor

4.1.1 Configurao dos Roteadores Virtuais

O primeiro passo no projeto de um servio de VPN, baseado na arquitetura MPLS, definir e configurar o roteamento e encaminhamento virtual (VRF). No caso acima, isso significa configurar VRFs para cada VPN A e VPN B. Cada roteador PE deve ser conectado ao roteador CE do usurio que deseja receber rotas de uma VPN especfica. Os roteadores PEs da SuperCom em Curitiba, Rio de Janeiro e So Paulo so todos conectados s VPN A e VPN B. As configuraes das VRFs devem existir em todos os roteadores PEs. Os PEs suportam mltiplos roteadores dentro de um nico sistema. Isso permite ao provedor de servio configurar mltiplos roteadores separados dentro de um nico chassi. A aplicao para essa funo inclui a criao de roteadores individuais dedicados
24

Loopback Cada roteador PE necessita de um endereo nico (Usualmente chamado de loopback) que utilizado para alocar um rtulo e habilitar o encaminhamento dos pacotes da VPN atravs do backbone.

65

para os usurios. O roteador pode suportar at 1000 (Agregador PE da Juniper) roteadores virtuais por mdulo ou por chassi. O CPE/CE conectado no roteador PE v uma interface de roteador. O equipamento (CE) conectado no tem noo do roteador virtual atrs da interface. Por exemplo, um enlace Frame Relay pode ter circuitos que so conectados a diferentes roteadores virtuais. A camada fsica e enlace no ficam cientes que h mltiplas instncias de roteadores. O PE implementa o roteador virtual pela separao de cada estrutura de dado e permite a cada protocolo (TCP/UDP, RIP, OSPF, BGP-4, IS-IS) ser habilitado caso a caso. H uma tabela do roteador para associar a conexo do usurio (Exemplo: PPP ou Frame Relay), com uma ou mais interfaces IP dentro de um roteador virtual. Como mencionado acima, o protocolo de roteamento do PE prov todo o suporte para BGP-4, OSPF, IS-IS e RIP. Esses protocolos podem ser habilitados ou desabilitados para cada instncia de um roteador no PE. Esses protocolos sero tratados com maior detalhe nas prximas seces.

4.1.2 Definir e Configurar os Indentificadores de Rotas - RD e endereos VPN-IPv4

Multiprotocolo BGP (MP-BGP) um protocolo usado para distribuir rotas das VPNs entre os roteadores PEs. Antes de apresentar como as rotas so distribudas entre os PEs, deve-se primeiro analisar como as VPNs BGP/MPLS facilitam o roteamento original dos usurios. Nas VPNs BGP/MPLS as rotas dos usurios so independentes e isoladas de outras VPNs. Alm disso, as rotas so separadas pelo provedor de servio no backbone, sendo possvel mais de uma VPN usar o mesmo endereo da rede privada. A nica forma de realizar isso garantir que essas rotas possam ser distinguidas de outras. As VPNs BGP/MPLS conseguem isso por adicionarem um Identificador de Rotas (RD) nos endereos IPv4. O RD adicionado pelo PE. O resultado chamado VPN-IPv4.

4.1.2.1 - RDs e as famlias de endereamentos VPN-IPv4

O objetivo das VPNs BGP/MPLS ter um endereo nico para cada VPN. As Rotas dos clientes devem ser tratadas em diferentes caminhos, dependendo de qual VPN

66

elas pertencem. A extenso do protocolo BGP [9] permite ao BGP transportar rotas de mltiplas famlias de endereos [49]. Uma VPN-IPv4 composta de 12 bytes, iniciando com 8 bytes que corresponde ao RD e terminando com 4 bytes que se referem ao endereamento IPv4. O anexo A avalia os tipos de RDs em detalhes. Um RD consiste de trs campos: dois bytes que especificam o Tipo do Campo, um Campo do Administrador e um Nmero do Campo Atribudo (ASN). O valor do tipo de campo determina o comprimento dos outros dois campos, assim como, a semntica do campo administrador. O principal requisito da arquitetura VPN MPLS exige que todas as rotas dos usurios sejam nicas dentro do backbone, e que no restrinja o uso de endereamento privado. O MP-BGP seleciona um nico caminho entre todos os possveis, descrevendo uma rota para um dado destino (rede e mscara). Entretanto, o MP-BGP, por si s, no pode operar corretamente se os usurios utilizam os mesmos planos de endereos. Na figura 4.2 apresentado o problema quando o roteador PE da SuperCom no Rio de Janeiro recebe dois endereos idnticos IPv4, ou seja, o roteador PE do Rio de Janeiro no consegue distinguir entre as VPNs A e B. Para que o PE consiga distinguir e escolher a melhor rota entre as duas rotas recebidas necessrio utilizar o mecanismo de identificador de rotas (RD). Esse mecanismo consiste de uma seqncia de 64 bits na frente do endereo IPv4, que est contido no MP-BGP. Essa seqncia de bits conhecida como RD, e diferente para cada VPN, sendo nica dentro do backbone MPLS/VPN. A figura 4.3 ilustra como o roteador PE do Rio de Janeiro consegue agora distinguir entre duas rotas IPv4 e pode trat-las como entidades separadas e pertencentes devida VPN. A combinao dos endereamentos IPv4 e os Identificadores de Rotas fazem com que as rotas IPv4 sejam nicas atravs da rede VPN MPLS.

67

. VPN B Florianpolis

O roteador do Rio de Janeiro recebe duas atualizaes para 10.2.1.0/24 e escolhe o melhor caminho medida que as rotas so comparadas VPN B Campinas

PE - Rio de Janeiro

SuperCom
MP BGP Net=10.2.1.0/24 NH= PE Curitiba MP BGP Net=10.2.1.0/24 NH= PE So Paulo

10.2.1.0/24

PE - Curitiba VPN A Porto Alegre

P - Braslia

PE - So Paulo VPN A So Paulo

10.2.1.0/24 Figura 4.2 Roteador PE do Rio de Janeiro compara as mesmas rotas Ipv4 A figura 4.3 mostra que, quando o PE do Rio de Janeiro recebe os dados 10.2.1.0/24 dos roteadores PEs de Curitiba e So Paulo, esses dados so agora distinguidos, pois um Identificador de Rotas - RD foi criado. Para os dados recebidos do roteador PE de Curitiba foi criado um prefixo 100:26: 10.2.1.0/24 e os dados recebidos do roteador PE de So Paulo um prefixo 100:27: 10.2.1.0/24.
VPN B Florianpolis PE - Rio de Janeiro VPN B Campinas MP BGP RD: 100:26 Net=10.2.1.0/24 NH= PE So Paulo

SuperCom
MP BGP RD: 100:27 Net=10.2.1.0/24 NH= PE Curitiba

10.2.1.0/24

PE - Curitiba VPN A Porto Alegre

P - Braslia

PE - So Paulo VPN A So Paulo

10.2.1.0/24

Figura 4.3 Roteadores PEs comparam as rotas VPN-IPv4

68

Pelo mecanismo do RD (RD por VPN) possvel aos clientes de diferentes VPNs o uso dos mesmos endereos privados. Isso no resolve o problema de mltiplos clientes dentro da mesma VPN usarem o mesmo endereamento entre suas redes. A soluo para esse problema possvel atravs de implementao de NAT ou criando RDs por VRFs. Na prtica, as operadoras tm optado pela soluo atravs de NAT e implementar RD somente por VPN e no por VRF. A criao de RD por VRFs demanda grande incremento de memria e processamento dos PEs.

4.1.2.2 - Configurao dos Identificadores de Rotas (RD)

Cada VRF no roteador PE necessita ter um Identificador de Rotas associado, que pode estar relacionado a um site/ponto ou VPN. No caso mais comum, em que um ponto pertence unicamente a uma VPN intranet, tecnicamente recomendvel o uso de um nico identificador de rotas para a VPN. Entretanto, esse ponto no futuro poder ser membro de uma VPN extranet. Por exemplo, suponha-se um identificador de rotas que utilizado por VPN. Se um ponto particular (site 2 da figura 4.4) de rede desejar ser membro de mltiplas VPNs, no ser possvel determinar que identificador de rotas usar para esse ponto especfico, porque o mesmo pertence a mais que uma VPN. Entretanto, para uma topologia de um modelo Intranet simples (tabela 4.2), usa-se o mesmo identificador de rotas por VPN para reduzir o uso de memria do roteador PE. Quando certas topologias (como a Extranet apresentada na figura 4.5) so criadas, pode ser necessrio estender os identificadores de rotas por VRF/Site para um determinado modelo de projeto. Pode-se estabelecer a atribuio de um valor particular do Identificador de Rotas para cada VRF no roteador PE. A estrutura desse valor pode ser no formato ASN: nn ou endereo: nn IP. Recomenda-se o uso do ASN: nn com o Nmero do Sistema Autnomo (ASN), que atribudo pela Internet Assigned Numbers Authority (IANA) e que nico entre os provedores de servio. O provedor de servio atribui o valor da segunda parte do Identificador de Rotas. Como recomendado, esse valor normalmente dever ser nico por VRF. Em alguns casos, tais como o exemplo apresentado na figura 4.1, poder ser nico por VPN quando se trata de Intranet. A tabela 4.2 mostra os valores para cada VPN da SuperCom dos usurios.

69

VPN do usurio VPN B VPN A

ASN 100 100

Valor nico 26 27

Identificador de Rota/VPN (RD) 100:26 100:27

Tabela 4.2 Definio dos identificadores de rotas por VPN

4.1.2.3 Rotas Targets - RT

O atributo RT identifica uma coleo de VRFs pelo qual um roteador PE distribui as rotas. Um roteador PE usa esse atributo (RT) para restringir a importao e exportao de rotas para as VRFs. Cada VRF tem uma poltica de configurao para importao e exportao das rotas. O roteamento que distribudo para outros PEs so marcados como atributos RT de exportao. As rotas que so recebidas pelo outro roteador PE so checadas se seu atributo RT de importao aceita inserir essa rota dentro da VRF. Esse mecanismo flexvel permite a construo de diferentes topologias de VPNs e modelos de negcios. Esse atributo definido em BGP Extended Communities Atribute [9]. Observe a figura 4.4, onde apresentado duas VPNs e trs sites, sendo a VPN A formada pelos sites 1 e 2, a VPN B formada pelos sites 2 e 3. importante observar que os identificadores de rotas (RD) na figura abaixo sero por site e no por VPN, caso contrrio (RD por VPN) o site 2 ficaria indeterminado entre o RD da VPN A e VPN B.

Site 1

Site 3

VPN A

VPN B

Site 2

Figura 4.4 Exemplo de topologia atravs do RT Essa topologia formada pela matriz (tabela 4.3) de configurao das VRFs RTs, onde a VRF2 para o site 2 est configurada para importar e exportar as rotas das

70

VPNs A e B. A VRF1 importa e exporta rotas somente da VPN A. A VRF3 importa e exporta rotas somente da VPN B. VRF 1 2 3 RT VPN A Importa e Exporta Importa e Exporta X RT VPN B X Importa e Exporta Importa e Exporta

Tabela 4.3 Matriz de configurao das RT por VRF Atravs dos conceitos de RT e RD por site foi possvel determinar que o site 1 pertena somente VPN A, o site 3 VPN B e o site 2 a ambas VPNs.

4.1.2.4 Extranet
Atravs dos conceitos bsicos de RD e RT (apresentados anteriormente) possvel implementar uma Extranet. Extranets (como apresentado no captulo 2) so redes de determinados usurios que podem compartilhar informaes com outras redes corporativas. Por exemplo, empresas de carto de crdito, ASPs (Provedores de Servios de aplicao) podem permitir o acesso a determinados servidores a partir de outras redes corporativas. A figura abaixo apresenta um exemplo com o suporte inicial para formao de VPNs Extranet. Neste exemplo, os acessos PBX1 e PBX2 fazem parte, simultaneamente, da VPN de suas respectivas redes corporativas e da VPN VoIP.
VoIP
SoftSwitch RD: VoIP RT: VoIP TrunkGW RD: VoIP RT: VoIP

V1 RD: V RT: V V2 RD: V RT: V

PBX 1 RD: V1 RT: V, VoIP V3 RD: V RT: V

PBX 2 RD: A1 RT: A, VoIP A2 RD: A RT: A

A1 RD: A RT: A A3 RD: A RT: A

Cliente Verde

Cliente Amarelo

Figura 4.5 Modelo de Extranet

71

Para que isto seja possvel, necessrio que sejam criadas duas VRFs exclusivamente para os acessos pertencentes ao PBX1 (com rotas das VPNs VoIP e Verde) e PBX2 (com rotas das VPNs VoIP e Amarelo).

4.1.3 Configurao das polticas de importao e exportao de rotas

O ltimo passo na configurao de cada VRF a adio das polticas de importao e exportao (RT) para cada usurio da VRF. A rota target (RT) BGP Extended Community apresentada no item anterior dita a poltica de importao e exportao usada pela VRF.

4.1.4 Configurar o enlace CE-PE

Para prover um servio de VPN, o roteador PE precisa ser configurado para que a informao de roteamento aprendida de uma VPN do usurio possa ser associada a uma determinada VRF. Isso possvel de ser feito por meio do processo padro do protocolo de roteamento, que conhecido como contexto de roteamento. Cada VRF usa um contexto de roteamento separado. Algumas rotas aprendidas por meio de uma interface que est associada a um protocolo de contexto de roteamento particular so instaladas dentro da VRF associada. Outras rotas aprendidas das interfaces que no fazem parte de algum contexto do roteamento so colocadas na tabela de roteamento global. Isso permite a separao da informao dentro de diferentes contextos, embora a informao seja aprendida pelo mesmo protocolo de roteamento. A informao de roteamento propagada de um ponto de rede do usurio para o provedor do servio. Mais precisamente, a informao propagada de um roteador CE para o roteador PE, para que o roteador CE seja conectado. H vrias opes de propagar essas informaes, tais como: RIP, roteamento esttico, OSPF ou BGP. Para que uma VPN funcione corretamente, necessrio que seja levantado qual o melhor protocolo de roteamento que deve ser utilizado e os parmetros associados em funo da necessidade do usurio. PE-CE - Roteamento Esttico

72

A primeira opo executar roteamento esttico entre os roteadores PE e CE. O roteamento esttico distribudo para dentro do BGP para anunciar, por meio de sesses MP-BGP, que conectam os roteadores PEs. Isso uma boa escolha quando o usurio tem um nico ponto de entrada na rede do provedor de servio, porque h pouco para ser realizado pela dinmica de aprendizagem das rotas dos usurios por meio do enlace PE-CE. No estudo de caso da figura 4.1, o roteador PE da SuperCom, em So Paulo, precisa ser configurado com rota esttica para as VPN A e VPN B. Cada roteador CE do usurio aponta para o default no roteador PE. Nesse caso, no necessrio considerar as configuraes no roteador CE. O primeiro passo nesse processo configurar todas as rotas estticas relevantes e coloc-las na VRF correta do PE, em vez da tabela de roteamento global. Configurao do Link PE-CE Rip Verso 2 Essa opo de conectividade prov a facilidade de executar RIP verso 2 entre os roteadores PE e CE. A informao recebida por meio do RIP de alguma VPN do roteador CE do usurio anexada dentro da VRF e ento anunciada por meio da VPN/MPLS, entre os roteadores PEs. O roteador PE do provedor SuperCom de Curitiba, no estudo de caso da figura 4.1, executa o RIP verso 2 com o site/ponto da VPN A em Porto Alegre e o site/ponto da VPN B em Florianpolis. Configurao do enlace PE-CE atravs de BGP Certos usurios que iro se conectar ao backbone da VPN BGP MPLS podero executar BGP com o provedor de servio e trocar rotas VPN por meio dessas sesses BGP. Com essa opo de conectividade, todas as rotas que so aprendidas de um CE do usurio sero anunciadas por meio da VPN MPLS, usando as sesses existentes entre os roteadores PEs do provedor de servio. A figura 4.6 mostra esse tipo de conectividade.

73

VPN B
Florianpolis

VPN B MP - BGP
Campinas

BGP

BGP

Curitiba
Porto Alegre

So Paulo Backbone do Provedor

So Paulo

VPN A

VPN A

Figura 4.6 BGP entre CE e PE Como pde ser visto na figura 4.6, ambos os clientes das suas respectivas VPNs conectam com o provedor da VPN MPLS por meio de BGP. Com essas configuraes, quailquer rota aprendida por meio de sesses com o roteador CE do cliente VPN A ser includa dentro da VRF associada desse cliente. Assim como qualquer rota aprendida por meio das sesses com o roteador CE do usurio VPN B ser colocada dentro da VRF do respectivo usurio. H dois requisitos principais para configurar BGP em um ambiente VPN MPLS. O primeiro, a configurao da sesso entre os roteadores PEs, conhecida tambm como MP-BGP; o segundo, a configurao do BGP entre os roteadores PE e CE. Para alcanar esse segundo objetivo, a famlia de endereamento deve ser configurada sob o processo BGP para cada VRF, que receber rotas da VPN do cliente usando BGP. Protocolo de Roteamento OSPF entre PE-CE: Configurao do enlace PE-CE com OSPF A ltima opo de conectividade que ser analisada o OSPF. Essa opo pode ser atraente para clientes que j utilizam OSPF em cada site de sua rede atravs, por exemplo de frame relay, e ainda deseja trocar informaes de roteamento OSPF entre os mesmos, sem ter que mudar para outros protocolos de roteamento como BGP ou RIPv2. Se o backbone da VPN MPLS utilizado para conectar as redes, no necessrio mudar o protocolo de roteamento OSPF, pois o backbone MPLS pode ser usado para trafegar a informao. 74

Usando o modelo Overlay, os provedores de servios tm capacidade de oferecer a infra-estrutura que poder ser til para as trocas de informaes de roteamento entre os ambientes dos usurios de forma transparente ao protocolo de roteamento. Com esse modelo, os roteadores das redes dos clientes formam roteamentos adjacentes com os outros roteadores remotos por meio dos circuitos virtuais Frame Relay ou ATM, sendo que eles trocam informaes IP diretamente entre os roteadores CEs por meio desses CVPs, usando o protocolo OSPF. Com a introduo das VPNs MPLS e o modelo de VPN peer-topeer, as trocas de informao de roteamento tornam-se um desafio. Roteamentos adjacentes diretos atravs de CVPs entre redes dos usurios no podem mais serem formados, porque no existe mais um circuito virtual direto entre os sites. Isso significa que necessrio um mecanismo que permita ao OSPF funcionar nesse ambiente. A nova soluo deve prover as mesmas funcionalidades que o modelo overlay oferece para OSPF, com a exceo que esta funcionalidade deve ser oferecida pelo modelo de VPN MPLS. As informaes de roteamento aprendidas dos usurios por meio do OSPF so colocadas dentro da VRF. Essas rotas so ento anunciadas por meio do backbone VPN MPLS, entre os roteadores PEs, usando MP-BGP, e so importadas para dentro das VRFs de outros PEs. Para suportar conectividade OSPF de PE a CE em um ambiente VPN MPLS, um nvel adicional de hierarquia de roteamento necessrio das redes dos usurios da VPN para executar processos de OSPF. Os protocolos OSPF j provm dois nveis de hierarquia do backbone, que so rea 0 e algumas reas conectadas. O terceiro nvel de hierarquia provido para que as redes possam ser conectadas com o backbone da VPN MPLS. Esse nvel extra de hierarquia o topo da rea 0. A refernncia [5] trata esse tema com mais detalhes.

4.1.5 Associao de interfaces CE nas VRFs definidas

Aps definir todas as VRFs no roteador PE, necessrio dizer ao PE qual interface pertence a qual VRF e, portanto, dever popularizar as rotas VRFs com os pontos conectados. Mais de uma interface pode pertencer mesma VRF. Quando a interface associada com uma VRF particular, o endereo IP removido da tabela de roteamento global, pois um acesso feito naquele endereo no ser 75

mais vlido por meio de mltiplas tabelas de roteamento e dever ser reconfigurado aps a interface se tornar membro da VRF.

4.1.6 Configurao do Multiprotocolo BGP

A configurao do BGP requer vrios passos e comandos de configurao. O BGP tem sido configurado para sesses MP-BGP PE a PE por meio do backbone VPN/MPLS, e para algumas sesses BGP PE a CE para usurios que desejam trocar BGP com o provedor de servio. Normalmente, a configurao padro nos roteadores IPv4, sendo necessrio ativar as sesses VPN-IPv4. Depois de ativar os roteadores para VPN-IPv4, o prximo passo na configurao do MP-BGP definir e ativar as sesses BGP entre os roteadores PEs. Processo de deciso para as VPN-IPv4 As rotas RT e RD do BGP controlam a seleo das rotas VPN-IPv4. Esse processo ocorre aps as rotas serem aprendidas de outros roteadores PEs, por meio das sesses MP-BGP, mas antes essas rotas so importadas para dentro de alguma VRF. O primeiro passo no processo de deciso BGP agrupar todas as rotas relevantes tal que elas possam ser comparadas. Antes do roteador PE selecionar as rotas, ele tem de conhecer que rotas da VPN existem e quais dessas rotas devem ser comparadas pelo processo de seleo BGP. Quando o roteador PE aprovisionado para servios de VPN, cada VRF configurada com declarao, que diz ao roteador PE quais rotas devem ser importadas para dentro da VRF (RT). Com essa informao, o roteador PE faz o seguinte: Analisa todas as rotas com as mesmas RT, com alguma declarao de importao de rotas para dentro da VRF; Considera todas as rotas que tm as mesmas RD como a designada para o processamento inicial da VRF; Cria novos caminhos BGP com um RD que igual para os RDs configuradas para a VRF que est iniciando o processo. Agora, todas as rotas so comparadas e, nesse ponto, o processo de seleo BGP executado. 76

Em funo dos motivos acima possvel entender por que esse processo pode influenciar a quantidade de memria requerida para reter as rotas da VPN no roteador PE. Se cada roteador PE usa uma RD diferente para cada VRF de uma VPN particular, a quantidade de memria necessria para armazenar todas as rotas da VPN aumentaria.

4.2 - Resumo do Captulo

Esse captulo apresentou um estudo de caso para validar o passo 5 que trata da configurao da VPN. A maior nfase neste captulo foi na configurao da VPN. O passo 5 detalhou os cuidados que devem ser tomados em um projeto de VPN MPLS que so: criar a VRF; criar um Identificador de Rotas (RD); especificar polticas de importao e exportao das VRFs (RT); estabelecer conectividade BGP entre os PEs; estabelecer MPBGP entre os roteadores e permitir a troca de VPN-IPv4 entre os roteadores. O captulo tambm avalia a possibilidade de criar RD por site ou por VPN. A escolha do melhor protocolo de roteamento analisada na ltima seo do trabalho. O prximo captulo anlisa os testes de conectividade, isolamento e qualidade de servio da VPN. Esses testes referem-se aos passos 6 e 7.

77

Captulo 5 Testes e anlise dos Resultados Obtidos (Passos 6 e 7)

Os testes contidos neste captulo tm o objetivo de validar a Estratgia proposta para projeto de VPNs MPLS com 6 classes de servios. A validao ser realizada por meio de trs testes: Teste de Conectividade das VPNs Teste de Isolamento das VPNs Teste de QoS das VPNs Para os testes de QoS no CE e PE so utilizados quatro cenrios (tabela 5.1). Cenrio 1: Voz (EF) e Dados Best Effort (BE), com a soma das bandas geradas (30 + 120) para cada classe menor que a velocidade do acesso (256). Cenrio 2: Voz (EF) e Dados Best Effort (BE), com a soma das bandas geradas para cada classe ( 30 + 300) maior que a velocidade de acesso (256). Cenrio 3: Voz (EF), Dados Best Effort (BE), Misso Critica (AF11) e Suporte a Negcio (AF31), com a soma das bandas geradas ( 30 + 50 + 30 + 20) menor que a velocidade de acesso (256). Cenrio 4: Voz (EF), Dados Best Effort (BE), Misso Critica (AF11) e Suporte a Negcio (AF31), com a soma das bandas geradas ( 30 + 50 + 30 + 200) maior que a velocidade de acesso.

78

Banda Cenrio Classe de servio Configurada (Kbps)

1 Voz (EF) Misso crtica (AF11) Suporte a negcio (AF31) Dados (BE) 2 Voz (EF) Misso crtica (AF11) Suporte a negcio (AF31) Dados (BE) 3 Voz (EF) Misso crtica (AF11) Suporte a negcio (AF31) Dados (BE) 4 Voz (EF) Misso crtica (AF11) Suporte a negcio (AF31) Dados (BE) 54 138 54 138 54 68 43

Trfego Gerado (Kbps)

30 120 30 300 30 50 30

Tamanho Pacote (bytes)

60 500 1200 60 500 1200 60 500 1200 500 1200 500 1200 200 500 1200 500 1200 500 1200 UDP UDP UDP UDP UDP UDP UDP 5001 5004 5001 5004 5001 5002 5003

Protocolo

Porta

27 54 68 43

20 30 50 30

UDP UDP UDP UDP

5004 5001 5002 5003

27

200

UDP

5004

Tabela 5.1 Configuraes das Classes

79

5.1 Classes de Servios diferenciados

Nveis de Servios Diferenciados so suportados pela manipulao de atributos chaves de certos fluxos que mudam a percepo do usurio da qualidade de servio que a rede est entregando. Esses atributos incluem: A quantidade de dados que podem ser transmitidos por unidade de tempo (thtoughput); O atraso para transmisso dos dados de um ponto para outro ponto na rede (delay ou latncia); A variao do atraso (jitter) para um dado fluxo. O percentual de dados transmitidos que no chegam ao destino corretamente (loss). A necessidade de oferecer mltiplas classes de servios para vrias aplicaes dos usurios deve-se competio por recursos gerada pela multiplexao estatstica dos pacotes. Com o objetivo de oferecer diferentes resultados relativamente vazo, atraso, jitter e perdas, necessrio que os pacotes recebam tratamento diferenciado. Para testar os parmetros de Qualidade de Servio (QoS), so necessrias algumas entidades de teste. O transmissor introduz o trfego de teste (iperf cliente) de modo a emular a gerao de trfego por parte da aplicao. O receptor (iperf servidor) consome o trfego de teste e responde se necessrio. Um monitor captura os fluxos de dados nos pontos de interesse para futura anlise.

5.2 - Organizao dos Testes

Este captulo organiza os testes por grupo, baseado na estratgia apresentada anteriormente. Cada grupo comea com um breve comentrio sobre os testes, seguido por uma srie de blocos descritivos; cada bloco descreve um nico teste. Cada bloco descritivo segue o seguinte formato: Nome do Teste: O nome do teste formado pela concatenao da sigla do teste. O nmero do grupo e o nmero de teste dentro do grupo, separados por (.). Dessa forma, o teste CON1.2 se refere ao segundo teste do primeiro grupo dentro do conjunto CONECTIVIDADE. O nmero do teste 1.2

80

Propsito: O propsito uma sentena curta descrevendo o objetivo do teste. Descreve sucintamente a funcionalidade ou capacidade a ser testada. Test Setup: Descreve a configurao de todos os equipamentos antes do incio do teste. Se o valor de um dado parmetro de protocolo no for especificado, o valor default do protocolo ser usado para o parmetro. Procedimento: Contm instrues passo-a-passo para a execuo do teste. Os passos incluem itens como: habilitar interfaces, desconectar equipamento da rede ou enviar pacotes de uma estao de teste. O procedimento de teste tambm sugere que o testador faa observaes que so interpretadas de acordo com os resultados observveis para aquela seo de teste. Dados a serem registrados: Relaciona as informaes a serem coletadas e registradas durante a execuo dos testes.

5.3 Recursos utilizados

Hardware: 3 Agregadores (PE) 3 Roteadores Cisco 827 (CE) Acessos ADSL 2 Roteadores Cisco 827-4V Teste de VoIP 2 Laptops com Windows 2000 ou XP, com placa Ethernet 10/100 Gerador de trfego - Iperf Os hardware e software so utilizados para os testes de conectividade, isolamento (figura 5.1) e QoS (figura 5.2).

Software:

5.4 A topologia para o teste de conectividade e isolamento est representada na figura abaixo

81

VPN B
Florianpolis

Cisco 827 Loopback: 10.20.0.1 Pool: 10.200.0.1/24 WAN: 10.0.0.5 RIP

Cisco 827 Loopback: 10.10.0.1 Pool: 10.100.0.1/24 WAN: 10.0.0.1 OSPF

VPN B Campinas

CE1 PE In (PPPoA) CE3 Porto

Alegre VPN A
Cisco 827 Loopback: 10.20.0.1 Pool: 10.200.0.1/24 WAN: 10.0.0.5 RIP

CE2 PE In (PPPoA) CE4 So Paulo Backbone/ Provedor

Cisco 827 Loopback: 10.10.0.1 Pool: 10.100.0.1/24 WAN: 10.0.0.1 RIP

Curitiba

So Paulo VPN A

Figura 5.1 Topologia para teste de conectividade e isolamento Procedimento: Configurar os agregadores PEs e roteadores Cisco 827, conforme scripts de configurao definidos previamente.

5.5 Grupo 1 : Conectividade

5.5.1 Teste CON1.1 Conectividade IntraVPN
Propsito: Testar conectividade entre pontos de uma mesma VPN (figura 5.1). Nos testes, basicamente, tem-se um cenrio de duas VPNs (VPN A e VPN B). Os testes foram realizados por meio dos comandos ICMP. Procedimento: 1 A partir de cada CE, tentar enviar mensagens de PING para os endereos IP de loopback23 dos outros CEs na mesma VPN. Ser executado este passo para as duas VPNs.

23

Os endereos de loopback aqui utilizado para o teste, normalmente em ambiente de produo da rede o backbone MPLS no permite o transporte de endereos loopback. Essa uma estratgia que depende de cada provedor.

82

Dados a serem registrados: Capturar log com resultado dos pings

Resultados obtidos:

Concluso do teste: Um dos pontos fundamental em uma soluo de VPN MPLS que seja possvel conectividade entre VPNs que utilizam inclusive os mesmo endereos (Os PEs de Curitiba e So Paulo apresentam duas VPNs com endereos iguais). Os resultados do teste mostram que existem conectividade entre os CEs da mesma VPN, mesmo que os endereos das duas VPNs sejam iguais (propositadamente) nos PEs.

5.5.2 Teste CON1.2 Isolamento de trfego entre VPNs

Propsito: Verificar que existe isolamento de trfego entre VPNs por meio da separao dos espaos de endereamento e roteamento. Verificar que quando h duas VPNs no mesmo roteador PE o trfego fica isolado. Em outras palavras, quando dois CEs com o mesmo espao de endereo em VPNs diferentes, somente o CE na mesma VPN recebe o trfego da fonte. Procedimento: Usando a configurao de base, verificar e capturar as seguintes informaes a partir da console de cada roteador CE: Verificar que cada CE somente pode ter acesso a outros membros de sua VPN.

83

Dados a serem registrados: Capturar log com resultados. Resultados Obtidos: VPN A (10.20.0.1) tenta se conectar com o CE2 (10.0.0.1)

VPN A (10.20.0.1) tenta se conectar com o (10.10.0.1)

Concluso do teste: Nesse teste de VPN MPLS foi mostrado a sua capacidade de separao de endereamento e roteamento. A nica possibilidade de ter acesso em outra VPN por meio de um ncleo MPLS se esse est configurado devidamente para isso (exemplo so as configuraes Extranet). No primeiro PING, tentou-se conectar ao endereo da interface WAN do roteador CE2. No segundo PING o objetivo era chegar ao endereo loopback, mas nenhum dos objetivos foi alcanado. Quando o ping foi gerado da VPN1 para a VPN2, foi medido na VPN1 se a mesma no recebia os mesmos endereos destinos. Certificando que os planos de endereos esto completamente isolados.

84

5.6 Grupo 2 : Teste de Qualidade de Servio (QoS)

5.6.1 Teste QoS2.1: Avaliao de QoS no CE (Cisco 827)
A razo de realizar os testes de QoS tambm no CE, porque na estratgia proposta os pacotes so classificados a partir do CE, e no como as VPNs MPLS tradicionais, onde os pacotes so classificados somente no PE. Propsito: Avaliar o comportamento dos parmetros de QoS para as classes de servio Voz (EF), Misso Crtica (AF11), Suporte ao Negcio (AF31) e Dados Melhor Esforo (BE), implementados no CE cisco 827, na presena de uma demanda de trfego superior banda nominal disponvel no acesso. Ou seja, o teste deve mostrar que os pacotes classificados como EF tenham prioridade em relao s classes AF e BE; que AF11 tenha prioridade em relao ao AF31 e BE; e finalmente que AF31 seja prioritrio em relao aos pacotes BE. Para esses testes foram utilizados os seguintes componentes: Gerador de trfego Nesse tipo de teste especfico, usado o Iperf (www.iperf.com), instalado nas mquinas geradora e receptora. Unidades de Capturas As unidades de capturas sero os monitores dos 2 computadores, onde sero gerados o trfego e os arquivos com todos os logs capturados. Test Setup:
256k< trfego gerado < 512K

Gerador

CE 256K

155M

512K

CE

10.200.0.2

PE Porto Alegre Ponto de congestionamento

PE Braslia

Receptor 10.100.0.2

Figura 5.2 Topologia para o teste de QoS do CE Procedimento:

85

Gerar fluxos de trfego para cada classe de servio de acordo com a tabela 5.1. Nessa tabela, a banda configurada refere-se ao CE; trfegos gerados, tamanhos de pacote, protocolo e porta so parmetros de entrada do Iperf (gerador). Dados a serem registrados: Valores dos parmetros de QoS Vazo, atraso, perdas de pacotes e jitter.

Ser mostrado, a ttulo de exemplo, o procedimento para capturar os dados da classe voz no caso do cenrio 1. Para os demais cenrios e classes foram realizados os mesmos procedimentos, sendo plotados somente os grficos. Ex: Configurar o servidor iperf para o fluxo UDP no computador de Porto Alegre. Receptor: Iperf s u p5001 b54k Configurar o cliente iperf para o fluxo UDP no computador de Braslia Gerador: Iperf c10.200.0.2 u p5001 b54k

Tabela 5.2 Resultados de sada do Iperf que esto plotados na figura 5.3 86

Consideraes de siglas utilizadas nos grficos: Misso Critica = M_C; Suporte ao Negcio = S_N; Bandwidth em Kbps= B.W; Jitter em ms= Jitter; Loss em %= Loss. A escala de tempo foi omitida dos grficos em funo de ser a mesma para todos os grficos. Os valores variam de 1 a 50 segundos em intervalos de 1 segundo.

Cenrio 1: Teste QoS2.1.1 Teste de QoS2.1(CE) no cenrio 1

Resultado obtido para o tamanho dos pacotes de dados de 500Kb RTT=173ms
QoS.2.1.1 - Jitter
25,00 20,00 Jitter(ms) 15,00 10,00 5,00 0,00 Tempo Dados (BE) Voz (EF)

Figura 5.3 QoS 2.1.1 - Jitter

87

QoS.2.1.1 - BandWidth
140 BandWidth (Kbps) 120 100 80 60 40 20 0 Tempo Dados (BE) Voz (EF)

Figura 5.4 QoS 2.1.1 - Bandwidth

Resultado obtido para o tamanho dos pacotes de dados de 1200 byte RTT=199ms QoS.2.1.1 - Jitter
40 35 30 Jitter (ms) 25 20 15 10 5 0 Tempo (s) Dados (BE) Voz (EF)

Figura 5.5 QoS 2.1.1 - Jitter

88

QOS.2.1.1 - Bandwidth
140 Bandwidth (Kbps) 120 100 80 60 40 20 0 Tempo (s) Dados (BE) Voz (EF)

Figura 5.6 QoS 2.1.1 - Bandwidth Concluso do cenrio 1: Os valores de vazo, atraso, jitter e perda de pacotes mantiveram-se em nveis normais, ou seja, em condies sem congestionamento o desempenho das aplicaes no prejudicado. Condies sem congestionamento aquela em que a soma dos trfegos gerados (30 + 120) pelas aplicaes menor que a soma no acesso (256Kbps). Os Valores de pacotes perdidos (loss) no foram apresentados nesse cenrio, pois no houve perda de pacotes.

89

Cenrio 2: Teste QoS2.1.2 Teste de QoS2.1(CE) no cenrio 2

Resultado obtido para o tamanho dos pacotes de dados de 500 bytes RTT=340ms
QoS.2.1.2 - Jitter
40,00 35,00 30,00 25,00 20,00 15,00 10,00 5,00 0,00 Tempo (s)

Jitter(ms)

Dados Voz

Figura 5.5 QoS.2.1.2 - Jitter

QoS.2.1.2 - Loss
70 60
Loss (%)

50 40 30 20 10 0
Tempo (s)

Dados Voz

Figura 5.6 QoS.2.1.2 - Loss

90

QoS.2.1.2 - Bandwidth
180 160 140 120 100 80 60 40 20 0 Tempo (s)

Bandwidth (Kbps)

Dados Voz

Figura 5.7 QoS.2.1.2 - Bandwidth

Resultado obtido para o tamanho dos pacotes de dados de 1200 bytes RTT=405ms
QoS.2.1.2 - Jitter
60,00 50,00 Jitter (ms) 40,00 30,00 20,00 10,00 0,00 Tempo (s) Dados Voz

Figura 5.8 QoS.2.1.2 Jitter

91

QoS.2.1.2 - Loss
60 50
Loss (%)

40 30 20 10 0
Tempo (s)

Dados Voz

Figura 5.9 QoS.2.1.2 Loss

QoS.2.1.2 - Bandwidth
250 Bandwidth (Kbps) 200 150 100 50 0 Tempo (s) Dados Voz

Figura 5.10 QoS.2.1.2 - Bandwidth Concluso do Cenrio 2: Para pacotes de dados de 500 bytes, os valores de vazo, atraso, jitter e perda de pacotes se mantiveram em nveis aceitveis para a classe VOZ (EF) e Dados mesmo numa situao de congestionamento, sendo uma situao de congestionamento aquela onde o trfego gerado pelas aplicaes (30 + 300) maior que a velocidade de acesso (256). Para pacotes de dados de 1200 bytes, nota-se uma diminuio da vazo, a ocorrncia de perdas de pacotes e um aumento no jitter para a classe VOZ. Este fato 92

conseqncia do tempo que o pacote (pequeno) de voz (60 bytes) tem que aguardar na fila enquanto um pacote (grande) de dados (1200 bytes) transmitido. Rocomenda-se fortemente o uso de mecanismos de LFI (Fragmentao e Intercalao da Camada de Enlace) nos acessos para manter os valores de jitter em nveis que no prejudiquem a qualidade da comunicao de voz. Deve ser feito um ajuste fino no tamanho da fila de VOZ no 827(CE) e no PE para se reduzir as perdas de pacotes.

Cenrio 3: Teste QoS2.1.3 Teste de QoS2.1 no cenrio 3

Resultado obtido para o tamanho dos pacotes de dados de 500 bytes RTT=181ms
QoS.2.1.3 - Jitter
25 20 Jitter (ms) 15 10 5 0 Tempo (s) Dados (BE) S_N (AF31) VOZ (EF) M_C (AF11)

Figura 5.11 QoS 2.1.3_Jitter

93

QoS.2.1.3 - Bandwidth
60 Bandwidth (Kbps) 50 40 30 20 10 0 Tempo (s) Dados (BE) S_N (AF31) VOZ (EF) M_C (AF11)

Figura 5.12 QoS 2.1.3 Bandwidth

Resultado obtido para o tamanho dos pacotes de dados de 1200 bytes RTT=207 ms QoS.2.1.3 - Jitter
40,00 35,00 30,00
Jitter (ms)

25,00 20,00 15,00 10,00 5,00 0,00

Tempo (s)

Dados_BE S_N (AF31) VOZ (EF) M_C (AF11)

Figura 5.13 QoS 2.1.3 Jitter

94

QoS.2.1.3 - Loss
3,5 3 2,5
Loss (%)

Dados (BE) S_N (AF31) VOZ (EF) M_C (AF11)

2 1,5 1 0,5 0
Tempo (s)

Figura 5.14 QoS 2.1.3 Loss

QoS.2.1.3 - Bandwidth
70 Bandwidth (kbps) 60 50 40 30 20 10 0 Tempo (s) Dados (BE) S_N (AF31) VOZ (EF) M_C (AF11)

Figura 5.15 QoS 2.1.3 Bandwidth Concluso do cenrio 3: Os valores de vazo, atraso, jitter e perda de pacotes mantiveram-se em nveis normais para essa situao sem congestiomento. O jitter para a classe voz no ultrapassou os 15ms para o tamanho do pacote de 500 bytes e 20ms para 1200 bytes, esses valores so considerados muito bons para voz. Na prtica o valor de at 30ms considerado excelente. A bandwidth para os tamanhos de pacotes de 500 e 1200 bytes mantiveram na mdia os

95

mesmos valores do trfego gerado. As perdas de pacotes foram mnimas para o tamanho de pacotes de 1200bytes, mas nada que possa preocupar.

Cenrio 4: Teste QoS2.1.4 Teste de QoS2.1 no cenrio 4

Resultado obtido para o tamanho dos pacotes de dados de 500 bytes RTT=365ms QoS.2.1.4 - Jitter
120,00 100,00 Jitter (ms) 80,00 60,00 40,00 20,00 0,00 Tempo (s)
Dados (BE) S_N (AF31) VOZ (EF) M_C (AF11)

Figura 5.16 QoS 2.1.4 - Jitter QoS.2.1.4 - Loss

80 70 60
Loss (%)

50 40 30 20 10 0
Tempo (s)

Dados (BE) S_N (AF31) VOZ (EF) M_C (AF11)

Figura 5.17 QoS 2.1.4 - Loss

96

QoS.2.1.4 - Bandwidth
80 70 Bandwidth (Kbps) 60 50 40 30 20 10 0 Tempo (s) Dados (BE) S_N (AF31) VOZ (EF) M_C (AF11)

Figura 5.18 QoS 2.1.4 - Bandwidth Resultado obtido para o tamanho dos pacotes de dados de 1200 bytes RTT=700 ms

QoS.2.1.4 - Jitter
250,00 200,00 Jitter (ms) Dados (BE) 150,00 100,00 50,00 0,00 Tempo (s) S_N (AF31) VOZ (EF) M_C (AF11)

Figura 5.19 QoS 2.1.4 - Jitter

97

QoS.2.1.4 - Loss
100 80 Loss (%)

Dados (BE)
60 40 20 0 Tempo (s)

S_N (AF31) VOZ (EF) M_C (AF11)

Figura 5.20 QoS 2.1.4 - Loss

QoS.2.1.4 - Bandwidth
250 Bandwidth (Kbps) 200 150 100 50 0 Tempo (s) Dados (BE) S_N (AF31) VOZ (EF) M_C (AF11)

Figura 5.21 QoS 2.1.4 - Bandwidth Concluso do Cenrio 4: Para pacotes de dados de 500 bytes, os valores de vazo, atraso, jitter e perda de pacotes se mantiveram em nveis aceitveis para as classes, inclusive VOZ, mesmo numa situao de congestionamento. Ocorreu um aumento do RTT em relao ao cenrio 3, pois o cenrio 4 representa uma situao de congestionamento. Para pacotes de dados de 1200 bytes, nota-se uma diminuio da vazo, a ocorrncia de perdas de pacotes e um aumento no jitter para a classe VOZ. Este fato conseqncia do tempo que o pacote (pequeno) de voz (60 bytes) tem que aguardar na fila

98

enquanto um pacote (grande) de dados (1200 bytes) transmitido. Rocomenda-se fortemente o uso de mecanismos de LFI (Fragmentao e Intercalao da Camada de Enlace) nos acessos para manter os valores de jitter em nveis que no prejudiquem a qualidade da comunicao de voz e tambm deve ser feito um ajuste fino no tamanho da fila de VOZ no 827 (CE) e no PE para se reduzir as perdas de pacotes. Ou seja, o resultado desse cenrio mostra que necessrio alm de DiffServ alguns mecanismos extras para oferecer a qualidade de servio a determinada aplicao Relao entre a utilizao da Bandwidth x RTT Dado que a nica componente do atraso fim a fim que pode se controlado o atraso da fila, o suporte para diferentes classes de servio baseado no controle do tipo de atraso para diferentes classes de trfegos durante perodo de congestionamento da rede. Na ausncia de alguma tcnica de gerenciamento de fila como RED (Random Early Detection), h uma relao direta entre a utilizao da bandwidth e o atraso RTT em um enlace que muito utilizado na prtica. Se a utilizao do enlace em um intervalo de 5 minutos24 fica em torno de 10% da largura da banda, ser mnima a perda de pacotes e o atraso RTT, porque o enlace estar subutilizada. Entretanto, no caso de um aumento da utilizao da banda acima de 50% (figura 5.22) nesse mesmo intervalo de 5 minutos, o RTT mdio apresentar um incremento exponencial.

Figura 5.22 RTT X Utilizao durante uma amostragem de 5 minutos Se o objetivo otimizar a largura de banda e tambm gerenciar os atrasos das filas para trfegos sensveis a atraso, para encontrar a soluo, primeiro deve-se determinar
24

Com a medio durante 5 minutos, tem-se uma razovel amostragem, esse perodo de 5 minutos usado na prtica normalmente.

99

que aplicaes na rede podem suportar o incremento e a variao do atraso. Aplicaes baseadas em TCP so especialmente projetadas para serem adaptadas e suportarem atrasos, mas h outros tipos de aplicaes, tais como voz em tempo real, que no esto habilitadas para operar com grandes atrasos e variao. Portanto, a soluo para melhor utilizao da largura de banda e tambm o melhor controle do atraso da fila, isolar a aplicao que no pode suportar atrasos de 50 a 60% de utilizao. possvel realizar isso, substituindo os pacotes daquelas aplicaes dentro de uma fila que no experimente o atraso causado pela alta utilizao do circuito. necessrio identificar certo conjuntos de aplicaes, isolar essas aplicaes de outros tipos de trfegos, substitu-las dentro de uma fila dedicada, e ento controlar a quantidade de atraso por enfileiramentos dessas aplicaes especficas. A fragmentao dos pacotes diminui o desvio padro dos pacotes manuseados pelas filas de sada, resultando na diminuio do tempo mdio de enfileiramento do pacote e do desvio padro deste tempo.

5.6.2 Teste QoS2.2:Avaliao de QoS no Agregador (PE)

Propsito: Avaliar o comportamento dos parmetros de QoS para as classes de servio Voz (EF), Misso Crtica M_C (AF11), Suporte a Negcio S_N (AF31) e Melhor Esforo , implementadas no agregador PE, na presena de uma demanda de trfego superior banda nominal disponvel no acesso. Ou seja, o teste deve mostrar que os pacotes classificados como EF tenham prioridade em relao a AF e BE; que AF11 tenha prioridade em relao ao AF31 e BE; e finalmente que AF31 seja prioritrio em relao aos pacotes BE.
256k< trfego gerado < 512K

Test Setup:
256K 155M 512K

Receptor

PE Porto Alegre Ponto de congestionamento

PE Braslia

Gerador

Figura 5.23 Topologia para o teste de QoS do PE Procedimento: Gerar fluxos de trfego para cada classe de servio de acordo com a tabela a seguir. Cada teste dever ser executado com tamanhos de pacote de 500 a 1200 bytes para 100

as classes de servio, Misso Crtica M_C (AF4) , Suporte a Negcio S_N (AF2) e Dados best effort (BE). A classe voz sempre ter o tamanho fixo em 60bytes. Banda Cenrio Classe de servio Configurada (Kbps)
1 Voz (EF) Misso crtica (AF11) Suporte a negcio (AF31) Dados (BE) 2 Voz (EF) Misso crtica (AF11) Suporte a negcio (AF31) S_N Dados (BE) 3 Voz (EF) Misso crtica (AF11) Suporte a negcio (AF31) Dados (BE) 4 Voz (EF) Misso crtica (AF11) Suporte a negcio (AF31) Dados (BE) 170 190 350 350 34 -

Trfego Gerado (Kbps)

30 150 30 300 30 40 40

Tamanho Pacote (bytes)

60 500 1200 60 500 1200 60 500 1200 500 1200 500 1200 200 500 1200 500 1200 500 1200 UDP UDP UDP UDP UDP UDP UDP 5001 5004 5001 5004 5001 5002 5003

Protocolo

Porta

34 -

34 80 80

80 30 40 40

UDP UDP UDP UDP

5004 5001 5002 5003

54 80 80

300

UDP

5004

Tabela 5.3 Parmetros por classes de Servios

101

Dados a serem registrados: Valores dos parmetros de QoS Vazo, atraso, perda de pacotes e jitter.

Consideraes: Misso Critica = M_C; Suporte ao Negcio = S_N.

Cenrio 1: Teste QoS2.2.1 Teste de QoS2.2(PE) no cenrio 1

Resultado obtido para o tamanho dos pacotes de dados de 500bytes RTT=160ms
QoS.2.2.1 - Jitter
50,00 40,00 Jitter (ms) 30,00 20,00 10,00 0,00 Tem po (s) Dados (BE) Voz (EF)

Figura 5.24 QoS.2.2.1_Jitter

QoS.2.2.1 - Bandwidth
140 Bandwidth (Kbps) 120 100 80 60 40 20 0 Tempo (s) Dados (BE) Voz (EF)

Figura 5.24 QoS 2.2.1 - Bandwidth Resultado obtido para o tamanho dos pacotes de dados de 1200 bytes

102

RTT=173ms
QoS.2.2.1 - Jitter
50,00 40,00 Jitter (ms) 30,00 20,00 10,00 0,00 Tem po (s) Dados (BE) Voz (EF)

Figura 5.25 QoS 2.2.1 - Jitter

QoS.2.2.1 - Bandwidth
160 140 120 100 80 60 40 20 0 Tempo (s)

Bandwidth (kbps)

Dados (BE) Voz (EF)

Figura 5.26 QoS 2.2.1 - Bandwidth Concluso do Cenrio 1 Os valores de vazo, jitter, atraso e perdas de pacotes se mantiveram em nveis normais para a situao sem congestionameto. No ocorreu nenhuma perda de pacotes para esse cenrio. O RTT se manteve com valores aceitveis para vrios tamanhos de pacotes.

Cenrio 2: Teste QoS2.2.2 Teste de QoS2.2(PE) no cenrio 2

Resultado obtido para o tamanho dos pacotes de dados de 500 bytes RTT=167ms

103

QoS2.2.2 - Jitter
50,00 40,00 Jitter (ms) 30,00 20,00 10,00 0,00 Tem po (s) Dados (BE) Voz (EF)

Figura 5.27 QoS 2.2.2_Jitter

QoS.2.2.2 - Loss
70 60 50 Loss (%) 40 30 20 10 0 Tem po (s) Dados (BE) Voz (EF)

Figura 5.28 QoS 2.2.2 - Loss

QoS.2.2.2 - Bandwidth
140 Bandwidth (Kbps) 120 100 80 60 40 20 0 Tempo (s) Dados (BE) Voz (EF)

Figura 5.29 QoS 2.2.2 - Bandwidth

104

Resultado obtido para o tamanho dos pacotes de dados de 1200bytes RTT=200 ms

QoS.2.2.2 - Jitter
25,00 20,00 Jitter (ms) 15,00 10,00 5,00 0,00 Tem po (s) Dados (BE) Voz (EF)

Figura 5.30 QoS 2.2.2 - Jitter

QoS.2.2.2 - Loss
60 50 Loss (%) 40 30 20 10 0 Tem po (s) Dados (BE) Voz (EF)

Figura 5.31 QoS 2.2.2 - Loss

105

QoS.2.2.2 - Bandwidth
160 140 120 100 80 60 40 20 0 Tempo (s)

Bandwidth (kbps)

Dados (BE) Voz (EF)

Figura 5.32 QoS 2.2.2 Bandwidth Concluso do cenrio 2: Os valores de vazo, atraso, jitter e perdas de pacotes se mantiveram em nveis normais para a classe VOZ, mesmo em situao de congestionamento. No ocorreu nenhuma de perda de pacotes (loss) para a classe voz nas situaes em que houve variao do tamanho dos pacotes.

Cenrio 3: Teste QoS2.2.3 Teste de QoS2.2 no cenrio 3

Resultado obtido para o tamanho dos pacotes de dados de 500 bytes RTT=172 ms
QoS.2.2.3 - Jitter
50,00 40,00 Jitter (ms) 30,00 20,00 10,00 0,00 Tem po (s) Dados (BE) S_N (AF31) VOZ (EF) M_C (AF11)

Figura 5.33 QoS 2.2.2 - Jitter

106

QoS.2.2.3 - Bandwidth
60,00 Bandwidth (ms) 50,00 40,00 30,00 20,00 10,00 0,00 Tempo (s) Dados (BE) S_N (AF31) VOZ (EF) M_C (AF11)

Figura 5.34 QoS 2.2.2 - Bandwidth Resultado obtido para o tamanho dos pacotes de dados de 1200 bytes RTT=195 ms
QoS2.2.3 - Jitter
70,00 60,00 50,00 Jitter (ms) 40,00 30,00 20,00 10,00 0,00 Tem po (s) Dados_BE S_N (AF31) VOZ (EF) M_C (AF11)

Figura 5.35 QoS 2.2.2 - Jitter

107

QoS.2.2.3 - Bandwidth
70 Bandwidth (Kbps) 60 50 40 30 20 10 0 Tempo (s) Dados (BE) S_N (AF31) VOZ (EF) M_C (AF11)

Figura 5.36 QoS 2.2.3 - Bandwidth Concluso do Cenrio 3: Os valores de vazo, atraso, jitter e perdas de pacotes se mantiveram em nveis normais. No ocorreu nenhuma perda de pacotes para as quatro classes nesse cenrio.

Cenrio 4: Teste QoS2.2.4 Teste de QoS2.2(PE) no cenrio 4

Resultado obtido para o tamanho dos pacotes de dados de 500 bytes RTT=290 ms

QoS.2.2.4 - Jitter
60,00 50,00 Jitter (ms) 40,00 30,00 20,00 10,00 0,00 Tem po (s) Dados (BE) S_N (AF31) VOZ (EF) M_C (AF11)

Figura 5.37 QoS 2.2.4 - Jitter

108

QoS.2.2.4 - Loss
100 80 Loss (%) 60 40 20 0 10 13 16 19 22 25 28 31 Tem po (s) 34 1 4 7 Dados (BE) S_N (AF31) VOZ (EF) M_C (AF11)

Figura 5.38 QoS 2.2.4 - Loss

QoS.2.2.4 - Bandwidth
80,00 70,00 60,00 50,00 40,00 30,00 20,00 10,00 0,00 Tempo (s)

Bandwidth (Kbps)

Dados (BE) S_N (AF31) VOZ (EF) M_C (AF11)

Figura 5.39 QoS 2.2.4 - Bandwidth

Resultado obtido para o tamanho dos pacotes de dados de 1200 bytes RTT=400 ms

109

QoS.2.2.4 - Jitter
100,00 80,00 Jitter (ms) Dados_BE 60,00 40,00 20,00 0,00 Tem po (s) S_N (AF31) VOZ (EF) M_C (AF11)

Figura 5.40 QoS.2.2.4 - Jitter

QoS.2.2.4 - Loss
100 80 Dados (BE) Loss (%) 60 40 20 0 Tem po (s) S_N (AF31) VOZ (EF) M_C (AF11)

Figura 5.41 QoS 2.2.4 - Loss

QoS.2.2.4 - Bandwidth
70,00 Bandwidth (Kbps) 60,00 50,00 40,00 30,00 20,00 10,00 0,00 Tempo (s) Dados (BE) S_N (AF31) VOZ (EF) M_C (AF11)

Figura 5.42 QoS 2.2.4 - Bandwidth

110

Concluso do Cenrio 4 Para pacotes de dados de 500 bytes, nota-se a ocorrncia de uma pequena perda de pacotes na classe de Misso Crtica. Para as classes voz e dados S_N, os valores de vazo, atraso, jitter e perda de pacotes se mantiveram em nveis normais.

5.7 - Resumo do captulo

Neste captulo foram apresentados o ambiente de desenvolvimento utilizado e a implemetao dos trs tipos de testes das VPNs. O software utilizado na montagem e verificao dos resultados totalmente gratuito (Iperf). Os testes constituem da verificao de conectividade, isolamento e qualidade de servios da VPN. Para o teste qualidade de servio foram simulados quatro cenrios para verficar se tanto o CE como o PE priorizam os pacotes em situao de congestionamento do acesso, de acordo com a classificao dos pacotes. Os resultados mostraram que os mecanismos de QoS analisados apresentam bom desempenho para os quatros cenrios. Alguns cuidados devem ser levados em considerao quando na transmisso da classe tempo real (EF) com relao ao tamanho de pacotes de dados na rede. Os testes de conectividade e isolamento mostraram que existe uma separao entre espao de roteamento e endereos por meio de uma tabela de roteamento por VPN. Os testes realizados foram baseados na estratgia mostrada no captulo 3, desde a definio da aplicao at o teste de QoS. Para evitar que o captulo ficasse excessivamente longo, procurou-se enfatizar basicamente os teste, considerando que os passos anteriores como as configuraes das VPNs j estivessem realizadas.

111

Captulo 6 Concluso e trabalhos futuros

6.1 - Concluso
No captulo 1 foi demostrado a tendncia das VPNs MPLS. No Brasil esperado um grande crescimento no mercado das pequenas e mdias empresas. Nos mercados Governo e Corporativos esperado uma grande migrao das VPNs de nvel 2 Frame Relay para VPN MPLS. Aps o que se demostra no captulo 2, possvel concluir que o provedor de servio pode minimizar seus custos de provisionamento e operao, oferecendo todos os servios por meio de uma nica plataforma de VPNs MPLS. No captulo 3 apresentou-se uma estratgia para projeto de VPNs MPLS. A principal contribuio que para um bom projeto de VPNs MPLS, deve-se partir primeiro das reais necessidades dos aplicativos do usurio at chegar ao passo 6, que a configurao da VPN. O mapeamento dos aplicativos em classes e a tecnologia de acesso so pontos que devem ser analisados antes de se configurar a VPN. Toda arquitetura tem benefcios e limitaes, e o provedor de servio deve efetuar uma cuidadosa anlise dos requisitos dos usurios e selecionar a melhor soluo para cada usurio. O captulo 4 mostrou os principais aspectos na configurao da VPN MPLS: criar uma VRF, Atribuir um nico identificador de rotas - RDpara cada VRF; especificar polticas de importar e exportar para cada VRF - RT; estabelecer conectividade BGP entre os roteadores PEs; estabelecer MP-iBGP entre os roteadores PEs e permitir trocas de rotas VPN-IPv4;

112

configurar o processo de roteamento por VRF. As configuraes dos identificadores das VPNs (RD) e as rotas target (RT) devem ser tratado em especial em um projeto de VPN MPLS. Se o projeto for apenas Intranet possvel considerar os RDs por VPNs, caso seja Extranet a implementao poder ser de duas maneiras : RD por VRF ou realizando NAT entre as VPNs. O Captulo 5 teve como objetivo apresentar uma plataforma simples, de baixo custo e de fcil uso, que permita um estudo da abordagem feita nos captulos anteriores, ou seja, permita validar a estratgia aplicada, comprovando os nveis de isolamento, conectividade e servios diferenciados em uma VPN MPLS. Os resultados apresentados nesse captulo mostram que possvel ter um nvel de segurana e principalmente qualidade de servios para as diversas aplicaes que trafegam em uma VPN MPLS com DiffServ. Os experimentos foram feitos para os tipos de trfegos EF, AF e BE. O que se pode concluir, portanto, desse captulo que possvel para o provedor, oferecer VPN segura e com qualidade de servio.

6.2 Trabalhos Futuros

VoMPLS sabido que o IP no um protocolo eficiente para transporte de voz, em funo disso, um trabalho muito interessante seria implementar transporte Voz diretamente sobre MPLS. Multicast em MPLS Hoje no Brasil nenhuma rede MPLS ainda suporta Multicast sobre MPLS; portanto um trabalho de como implementar Multicast sobre MPLS ser de grande utilidade. Voz sobre IPSec sobre LSP Um trabalho tambm bastante interessante seria analisar o desempenho dos LSPs quando os dados transportados so pacotes de voz com IPSec. IPv6 atravs de MPLS.

113

Bibliografia
[1] S.Blake, et. Al., RFC 2475, An Architecture for Differentiated Services,December 1998 [2] [3] [4] Vegesna, S. IP Quality of Service, Cisco Press 2001. U.Black., MPLS and Label Switching Networks Prentice Hall Series 2001 I. Pepelnjak, J. Guichard, MPLS and VPN Architectures Volume I Cisco Press 2002 [5] I. Pepelnjak, J. Guichard, J. Apcar. MPLS and VPN Architectures Volume II Cisco Press 2003 [6] [7] [8] [9] E. Osborne, A. Simba, Engenharia de Trfego com MPLS Cisco Press 2003 P. Tonsu, G. Wieser, MPLS-Based VPNs Prentice Hall series 2001 Y.Rekhter, E. Rosen, RFC 2574, BGP/MPLS VPNs,March 1999 S. Ramachandra, D. Tappan, BGP Extended Communities Attribute, [draftramachandra-bgp-ext-communities-09.txt], work in progress, June 2001. [10] E. Rosen, R Callon, A. Viswanathan, RFC 3031, Multiprotocol Label Switching Architecture, January 2001. [11] B. Jamoussi, L. Andersson, R. Callon and R. Dantu: Constraint-Based LSP Setup using LDP, RFC 3212, January 2002 [12] Dino Farinacci, Tony Li, A. Conta, Y Rekhter, Dan Tappan, E. Rosen, G. Fedorkom, RFC 3032, MPLS Label Stack Encoding, January 2001.

114

[13] Juha Heinanen, RFC 1483, Multiprotocol Encapsulation over ATM Adaptation Layer 5, July 1993. [14] Bilel Jamoussi, et al, Constraint-Based LSP Setup using LDP,[draft-ietf-mplscrldp-05.txt], January 2001 [15] R. Braden, et al., RFC 2205, Resource ReServation Protocol (RSVP) Version 1, Functional Specification, September 1997. [16] Yakov Rekhter, Eric Rosen, RFC 3107, Carrying Label Information in BGP-4, May 2001 [17] K. Nichols, et al., RFC 2474, Definition of the Differentiated Services Filed (DS Field) in the IPv4 and IPv6 Headers, December 1998. [18] S. Blake, D. Black, M. Carlson, E.Davies: An Architecture for Differentiated Services, RFC 2475, December 1998. [19] Grossman, D. and Heinanem, J., RFC 2684, Multiprotocol Encapsulation over ATM Adaptation Layer 5. September 1999. [20] Conta, A., Doolan, P., and Malis, A, RFC 3034. Use of Label Switching on Frame Relay Networks. January 2001 [21] Davie, Bruce and Y.Rekhter MPLS Technology and Applications Morgan Kaufmann Publishers 2000 [22] Guichard, Jim and I, Pepelnjak MPLS and VPN Architectures: A Practical Guide to Understanding, Designing and Deploying MPLS and MPLS-Enabled VPNs Cisco Press 2000. [23] F.L Faucher, B. Davie, S. Davari, P. Vaananem: MPLS Suport of Differentiated Services, RFC 3270, May 2002 [24] Campanella, M., et al., Specification and Implementation plan for a Premium IP service, GEANT deliverable D9.1, March 2001. [25] Kamienski, C.A & Sodok, D., Qualidade de Servio na Internet, minicurso , 18 SBRC, Belo Horizonte/MG, May 2000

115

[26] Leinen, Leinen, S., Przybylski, M, Reijs, V. & Trocha, S., Testing of Traffic Measurement Tools,TF-NGN Deliverable D9.4, September 2001. [27] Nichols, K., Jacobson, V. & Zhang, L., A Two-bit Differentiated Services Architecture for the Internet, RFC 2638, July 1999. [28] Pan, P., Scalable Resource Reservation Signaling in the Internet, Ph.D. Thesis, Columbia University, 2002. [29] Tanenbaum, A. S., Computer Networks, Prentice Hall, 3rd edition, 1996. [30] TEQUILA Project, http://www.ist-tequila.org, 2000. [31] Xiao, X. & Ni, L. M., Internet QoS: A Big Picture, IEEE Network, March 1999. [32] White Paper The need for QoS, www.qosforum.com/white-

papers/Need_for_QoS-v4.pdf. [33] White Paper Introduction to QoS policies, www.qosforum.com/whitepapers/qospol_v11.pdf. [34] A White Paper by NetScreen Technologies, Inc. - Deploying Scalable, Secure, DynamicVirtual Private Networks, May 2003. [35] Magalhaes, M. F.; Cardozo, E. (1999). Qualidade de servio na Internet. Relatrio tcnico, UNICAMP/FEEC/DCA, Campinas, SP. [36] A White Paper by Cisco. - MPLS based VPNs: Equivalent to the security of Frame and ATM, March 2001. [37] Semeria, Chuck. RFC 2547bis: BGP/MPLS VPN Fundamentals,

www.juniper.net/techcenter/techpapers/200014, 2001 [38] Semeria, Chuck. RFC 2547bis: BGP/MPLS VPN Hierarchical and Recursive Applications, www.juniper.net/techcenter/techpapers/, 2001 [39] Semeria, Chuck.RFC 2547bis: Migration Strategies for IP Service Growth:Cellswitched MPLS or IP-routed MPLS, www.juniper.net/techcenter/techpapers/200026, 2002 [40] A White Paper by Soirent BGP/MPLS: Virtual Private Networks,2002

116

[41] Semeria, Chuck.; Stewart, W.J. Supporting Differentiated Service Classes in Large IP NEtworks, www.juniper.net/techcenter/techpapers/, 2001 [42] Bagasrawala, A. Next Generation VPNs, Lucent Technologies [43] A White Paper by Nortel Networks. - Deploying IP-VPN services on Passport Multiservice Networkswww.nortelnetworks.com [44] RFC 2598, An Expedited Forwarding PHB, http://www.ietf.org/rfc/rfc2598.txt [45] RFC 2597, Assured Forwarding PHB Group, http://www.ietf.org/rfc/rfc2597.txt [46] RFC 2338, Virtual Router Redundancy Protocol, http://www.ietf.org/rfc/rfc2338.txt [47] RFC 2917, A Core MPLS IP VPN Architecture, http://www.ietf.org/rfc/rfc2917.txt [48] RCF 2983, Differentiated Services and Tunnels, http://www.ietf.org/rfc/rfc2983.txt [49] RCF 1265, BGP Protocol Analysis, http://www.ietf.org/rfc/rfc1265.txt [50] RCF 1403, BGP OSPF Interaction, http://www.ietf.org/rfc/rfc1403.txt [51] Stoika, I.; Zhang, H. (1998). LIRA: An approach for service differentiation in the Internet.Proceedings of NOSSDAV. [52] McCabe, J.D. Practical Computer Network Analysis and Design. So Francisco, Califrnia: Morgan Kaufmann Publishers, In.; 1998 [53] Igor M. Moraes, Marco Dias D. Bicudo , Kleber V. Cardoso , Saulo V. de Vasconcellos ,Jos F. de Rezende , Otto Carlos M. B. Duarte Desenvolvimento de um Ambiente de Testes com Suporte Qualidade de Servico para Transmisso de Vdeo Digital, 2003

117

Anexo A Conceitos bsicos de BGP

A.1 BGP
O BGP um protocolo de roteamento dinmico, utilizado para comunicao entre sistemas autnomos (ASs). Baseados nessas informaes, os sistemas autnomos conseguem trocar informaes e determinar o melhor caminho para as redes que formam a Internet. Tal papel muito importante, sabendo-se que a todo momento as redes podem sofrer alteraes, podem ocorrer quedas de suas conexes, receber anncios invlidos, aplicar polticas, manter a conectividade por outros caminhos, adaptando-se rapidamente e mantendo a consistncia de seus anncios de forma eficiente. A divulgao das informaes de roteamento BGP [50] feita entre roteadores que estabelecem uma relao de vizinhana, sempre na forma de pares. Tendo essa relao, so trocadas as informaes contidas nas tabelas de roteamento BGP de cada um destes. Para estabelecer uma relao de vizinhana necessrio que dois roteadores tenham uma conexo direta entre eles, ou que algum protocolo IGP trate de garantir a alcanabilidade. Essa relao de vizinhana pode definir aos roteadores uma relao de speakers ou peers (pares). Tratando-se de um protocolo importante que requer confiabilidade em sua comunicao, para garantir a alcanabilidade entre todas as redes da Internet, necessrio que seja utilizada uma forma confivel de troca de informaes deste protocolo. Isso obtido pela utilizao do protocolo TCP entre dois roteadores que trocam informaes do protocolo BGP. A porta utilizada para a comunicao 179.

118

Para diferir e identificar univocamente em cada sistema autnomo (AS), cada AS possui um nmero que o identifica mediante os demais ASs da Internet. Este nmero varia entre 1 e 65535, sendo que a faixa entre 64512 e 65535 destinada a uso privado. A.2 - SESSO BGP Antes do estabelecimento de uma sesso BGP, os roteadores vizinhos trocam mensagens entre si para entrar em acordo sobre quais sero os parmetros (ex: tempo mximo de espera entre as mensagens hold time) da sesso. No havendo discordncia e nem erros durante a negociao dos parmetros entre as partes, a sesso BGP estabelecida. Caso contrrio, sero enviadas mensagens de erro e a sesso no ser aberta. Quando a sesso estabelecida entre os roteadores, so trocadas mensagens contendo todas as informaes de roteamento, ou seja, todos os melhores caminhos previamente selecionados por cada um, para os destinos conhecidos. Posteriormente, eles trocaro mensagens somente de atualizao das informaes de roteamento de forma incremental. Essa tcnica mostrou-se um avano no que se refere diminuio da carga das CPUs dos roteadores e na economia da banda dos enlaces, quando comparada a outros protocolos que, ao comunicarem suas atualizaes, enviam, periodicamente, a totalidade de rotas instaladas em suas tabelas. A.3 - Mensagem BGP As mensagens trocadas em sesses BGP tm o comprimento mximo de 4.096 bytes, e mnimos 19 bytes. Todas as mensagens so compostas de, no mnimo, um cabealho e, opcionalmente, uma parte de dados. O formato do cabealho das mensagens BGP est apresentado na figura A1. Campo Marcado (Marker) 16 bytes Campo de Comprimento (Lenght) 2 bytes Tipo de Campo (Type) 1 byte

Figura A.1 Formato da Mensagem do cabealho BGP Campo Marcador:

119

Serve para verificar a autenticidade da mensagem recebida e se houve perda de sincronizao entre os roteadores vizinhos BGP. Pode ter dois formatos: caso a mensagem seja do tipo OPEN (abrir), ou se a mensagem do tipo OPEN no possuir informao de autenticao, o campo deve estar todo preenchido com o nmero 1; seno, o campo marker ter seu contedo baseado em parte no mecanismo de autenticao usado. Campo do Comprimento: Deve conter um nmero que representa o comprimento total da mensagem, incluindo o cabealho. Como pode haver mensagens que no possuem dados aps o cabealho, a menor mensagem BGP enviada de 19 bytes. Tipo de Campo: Esse campo deve conter um nmero que representa o cdigo de um tipo de mensagem. Os tipos de mensagens so: KEEPALIVE, NOTIFICATION, OPEN e UPDATE A.4 - Tipos de Mensagens BGP Os roteadores vizinhos BGP-4 que suportam BGP-4 trocam mensagens de 4 tipos antes ou durante uma sesso BGP. A seguir apresenta-se para que serve cada tipo dessas mensagens. OPEN A mensagem do tipo OPEN enviada para se iniciar a abertura de uma sesso BGP entre os vizinhos BGP. O formato dessa mensagem est apresentado na figura A2.

120

Verso Nmero do AS Tempo de espera Identificador BGP

Comprimento dos

parmetros opcionais

Parmetros Opcionais

Figura A.2 Formato da mensagem OPEN

NOTIFICAO: Esse tipo de mensagem enviado no caso da deteco de erros durante ou aps

o estabelecimento de uma sesso BGP. O formato da mensagem NOTIFICAO est apresentado na figura A3. 32 bits Campo de erro 1 byte Campo Subcdigo de erro 1 byte

Campo de Dado Varivel

Figura A.3 Formato da mensagem NOTIFICAO

121

KEEPALIVE So mensagens trocadas periodicamente, com o propsito de verificar se a

comunicao entre os vizinhos est ativa. A mensagem do tipo KEEPALIVE composta apenas de cabealho padro das mensagens BGP, sem dados transmitidos aps o cabealho. O tempo mximo permitido para o recebimento da mensagem KEEPALIVE definido pelo hold time. A.5 - RDs e as famlias de endereamentos VPN-IPV4 O objetivo das VPNs BGP/MPLS ter um endereo distinto para cada VPN. Rotas dos clientes devem ser tratadas em diferentes caminhos, dependendo de qual VPN elas pertencem. O multiprotocolo BGP extenso [9] permite ao BGP transportar rotas de mltiplas famlias de endereos [49]. Uma VPN-IPv4 composta de bytes, iniciando com 8 bytes que corresponde ao RD e terminando com 4 bytes que se referem ao endereamento IPv4 (Ver figura A4). Se duas VPNs usam o mesmo endereamento IPv4, os PEs transladam, incluindo o prefixo de endereamento VPN-IPv4, para cada VPN. Isso garante que, se o mesmo endereo utilizado em duas VPNs diferentes, possvel instalar duas rotas completamente diferentes para o mesmo endereo, uma para cada VPN [8]. Um RD consiste de dois bytes que especificam o Tipo do Campo, um Campo do Administrador e um nmero do campo atribudo (ASN). O valor do tipo de campo determina o comprimento dos outros dois campos, to bem como a semntica do campo administrador. O campo administrador identifica um nmero atribudo autoridade e o nmero do campo atribudo contm um nmero que havia sido atribudo pelo identificador para um propsito particular. Essas duas variantes tinham sido definidas para permitir ao administrador da rede escolher uma nica RD, baseada em outro ASN ou endereo IP pblico. No entanto, as semnticas no influenciam o comportamento do BGP em algum caminho. Quando o BGP compara dois prefixos de endereos, ele ignora a estrutura inteiramente. O RD consiste de um campo de 8 bytes. Juntos com 4 bytes do endereo IPv4, ele constri a famlia de endereos das VPN-IPv4. O RD dividido em:

122

Tipo do Campo: 2 bytes Valor do Campo: 6 bytes A interpretao do valor do campo depende do valor do tipo de campo. At o

presente momento, dois so os valores do Tipo de Campo definido: 0 e 1. Quando o tipo de campo 0, o valor de campo consiste de dois subcampos (ver figura A5): Administrador do Subcampo: 2 bytes Nmero Atribudo ao Subcampo: 4 bytes Endereo VPN IPv4(96 bits) RD(64bits) Endereo IPv4(32bits)

Figura A.4 VPN/IPv4 Tipo de Campo. Valor do Campo

0x0000

ASN (16 bits)

Identificador(32 bits)

Figura A.5 RD Tipo=0 O administrador do Subcampo deve conter um ASN. Se esse ASN de um ASN pblico, ele deve ser atribudo pela Internet Assigned Numbers Association (IANA). O nmero atribudo ao subcampo pertence ao plano de numerao que administrado pela empresa da qual o ASN foi atribudo pela IANA. Quando o tipo de campo for 1, o valor do campo consiste de dois subcampos (v figura A6): Administrador do Subcampo: 4 bytes Nmero Atribudo ao Subcampo: 2 bytes

123

O administrador do subcampo deve conter um endereo IP. Se esse endereo IP tiver sido atribudo pela IANA para uma empresa particular, o nmero atribudo ao subcampo contm um nmero do espao de numerao, que administrado pela empresa para a qual o endereo foi atribudo. Tipo de Campo 0x0001 Valor do Campo Endereo IP (32 bits) Identificador (16 bits)

Figura A6 RD do Tipo=1

124

Anexo B MPLS baseado em Clula x MPLS baseado em Roteador

B.1 - Principais limitaes do IPoATM:
H um nmero de limitaes bem conhecidas associadas ao modelo tradicional de IP sobre ATM: IP sobre ATM incrementa a complexidade da rede pela necessidade do provedor de gerenciar dois planos de controle e fundamentalmente dois tipos diferentes de equipamentos de rede. IP sobre ATM resulta em uma ineficincia do uso da largura de banda da clula ATM, como conseqncia do cabealho da clula do ATM que corresponde a aproximadamente 25% de toda a informao transmitida em cada clula (clula TAX)25. As abordagens dos servios IP diferenciados (DiffServ) para as classes de servios no so bem mapeados com os mecanismos de QoS do ATM IP sobre ATM requer o desenvolvimento de N2 rotas adjacentes. Para resolver essas limitaes os provedores tm optado entre MPLS baseado em Clula ou MPLS baseado em Roteador. Ser apresentado agora as principais contribuies dessas duas arquiteturas para resolver as principais limitaes do IPoATM.

25

Clula TAX se refere a utilizao do ATM para transporte, ocasionando um grande overhead e ineficincia da largura de banda da rede

125

B.2 - MPLS baseado em clula

Basicamente h dois pontos principais em que a transio de IP sobre ATM para Comutao de clula MPLS pode remover a complexidade e simplificar a operao da rede. Reduzindo a nfase em IGP Um dos maiores problemas que dificulta o crescimento de IP sobre ATM que a criao de n2 circuitos virtuais permanentes (CVPs) pode levar a saturao o IGP durante situaes de falhas. Atravs do MPLS baseado em clula eliminada a necessidade de estabelecer uma topologia de n2 roteamentos. Simplificao no gerenciamento das CoS MPLS baseado em clula pode simplificar o gerenciamento da classe de servio (CoS) na rede, pois os planos de controle ATM e MPLS em uma rede IP sobre ATM podem ser substitudos por um nico plano de controle IP/MPLS. MPLS baseado em clula suporta CoS IP por meio do estabelecimento de mltiplos LSPs, sendo cada LSP dedicado a uma classe especfica de trfego. A diferena essencial entre IP sobre ATM e Comutao de clula MPLS que, em vez de usar sinalizao ATM para estabelecer PVCs, a sinalizao MPLS estabelece os LSPs. Enquanto um nico plano de controle tem o benefcio quando comparado com uma outra opo formada por dois planos de controle independentes, o desenvolvimento de MPLS baseado em clula no elimina a complexidade de gerenciamento associada ao desenvolvimento de dois tipos diferentes de equipamento Roteadores IP e Comutadores ATM.

B.3 - MPLS baseado em Roteador:

O desenvolvimento da infra-estrutura MPLS baseada em roteadores IP tem-se mostrado adequado para superar essas limitaes do IP sobre ATM. MPLS baseado em roteador elimina a complexidade de gerenciamento de dois planos de controle e dois diferentes tipos de equipamentos de rede, porque requerido um nico plano de controle IP/MPLS.

126

MPLS baseado em roteador prov mais eficincia no uso da largura de banda da rede, por no usar ATM como transporte. MPLS baseado em roteador pode suportar IP DiffServ CoS, pois LSRs baseados em Frame tm a habilidade de ler e escrever bits EXP no rtulo da pilha MPLS, que transporta a informao IP DiffServ. Essa capacidade permite mltiplos nveis de servio em um mesmo LSP.

MPLS baseado em roteador elimina a necessidade do estabelecimento de n2 conexes entre os roteadores de bordas.

127

Anexo C Metodos de encapsulamento xDSL

Cada um dos mtodos de encapsulamento abaixo e seu funcionamento com uma rede VPN MPLS para acesso remoto ser abordado em seguida.

PPPoE PPPoE Ethernet

PPPoA IP PPPoA

RFC 1483 Bridged

RFC 1483 Routed

Ethernet

RFC 1483

RFC 1483 snap ou VC mux ATM AAL5 DSL Layer Figura C Formato de Encapsulamento DSL C.1 - Acesso DSL usando a RFC 1483 com encapsulamento roteado Esse mtodo de conexo particularmente simples e consiste de um PVC ATM entre o CPE do acesso DSL e o roteador PE, como apresentado na figura C.1.
CE 10.6.1.0/24 CPE DSL Servidor DHCP pode est aqui ou pode atuar como um Relay Agent DSLAM Roteador PE Backbone MPLS VPN CE Servidor DHCP 196.7.25.32

Figura C.1 RFC 1483 Routed

128

Nenhuma autenticao e autorizao do usurio so necessrias nesse cenrio. Na viso da rede MPLS, no h diferena entre essa configurao e um outro circuito virtual permanente (CVP) como Frame Relay ou Linha Dedicada. Em funo do CPE ser um roteador, ele pode ser configurado com roteamento dinmico no roteador PE, se necessrio, e atuar como um servidor DHCP na rede local. C.2 - Acesso xDSL usando RFC 1483 com encapsulamento de nvel 2 (bridged) Nesse cenrio, todo trfego entre o acesso DSL do CPE e o roteador PE processado no nvel de enlace. O trfego transportado no PVC ATM como na RFC 1483 com a incluso da informao de nvel 2 (Endereamento Ethernet). Para o roteador apresentado na figura C.2, a subinterface ATM aparece como uma interface Lan.
CE DHCP Relay Servidor DHCP 196.7.25.32

10.6.1.0/24 CPE DSL

Subinterface ATM vista como uma interface LAN DSLAM Roteador PE

Backbone MPLS VPN CE

Figura C.2 RFC 1483 Bridged Como o CPE do acesso DSL no tem nenhuma funcionalidade de roteamento, ele no pode atuar como um servidor DHCP. Entretanto, se DHCP requerido, ento o servidor DHCP remoto dever prover o servio. C.3 - Acesso xDSL usando PPP sobre Ethernet (PPPoE) No acesso que utiliza PPP sobre Ethernet (PPPoE), como apresentado na figura C.3, o CPE conectado no roteador PE usando uma conexo simples, como na RFC 1483 com encapsulamento de nvel 2 (bridged) . Sesso PPPoE normalmente direcionada para PC, clientes com software PPPoE instalado e encapsulado (bridged) sobre PVC ATM, por meio de encapsulamento Ethernet dos quadros . O roteador PE tem uma interface de acesso virtual para cada PC cliente, como uma oposio ao PPPoA. A vantagem do PPPoE que

129

o software reside nos PCs clientes. Portanto, os CPEs DSL necessitam somente de capacidade de encapsulamento de nvel 2 (bridging). Nenhuma capacidade de roteamento necessria. Como conseqncia, tem-se um baixo custo de hardware, porque cada PC executa sua prpria sesso PPP e autenticao.
PVC ATM 10.6.1.0/24 CPE DSL Interface de acesso virtual para cada sesso PPPoE DSLAM Servidor RADIUS DHCP Relay

Roteador PE Backbone MPLS VPN

CE

Sesso PPPoE Figura C.3 - PPPoE

C.4 - Acesso xDSL usando PPP over ATM (PPPoA) No PPP sobre ATM (PPPoA), apresentado na figura C.4, o CPE do usurio tem funcionalidade de roteamento e usa PPP para conectar com o roteador PE. A sesso PPP executada sobre o PVC ATM entre o CPE DSL e o roteador PE, sendo ento chamada de PPP sobre ATM ou PPPoA. As mquinas locais podem tambm ser configuradas estaticamente com endereamento IP ou por solicitao ao servidor DHCP, que configurado no outro CPE DSL ou num servidor remoto na Intranet. A vantagem de usar PPPoA em um acesso DSL que pode ser feita uma simples autenticao na conexo DSL para todos os PCs atrs do CPE DSL. Os PCs podem obter seus endereos de um DHCP26 local, que configurado no CPE DSL, ou de um servidor DHCP do usurio.

26

DHCP Relay Agente Se o servidor DHCP est centralizado em algum lugar da rede, deve-se habilitar um DHCP agente Relay para consigurar a interface LAN do roteador do usurio que ir trocar mensagens entre o usurio e o Servidor DHCP.

130

Servidor DHCP pode estar aqui ou pode atuar como um Agent Relay Interface de 10.6.1.0/24 acesso virtual CPE DSL DSLAM

Servidor RADIUS

CE

Servidor DHCP 196.7.25.32

Roteador PE Backbone MPLS VPN

CE

Sesso PPPoA Figura C.4 - PPPoA

131

Anexo D Escolhendo o melhor protocolo de roteamento para as VPNs MPLS

importante entender qual protocolo de roteamento deve ser apropriado para determinado tipo de topologia. Para entender melhor essa anlise a topologia da figura D.1 foi alterada para uma topologia simples de VPN de um cliente tpico, como mostra a figura D.2. Site Central Site Central Backup

Rede Frame Relay

Figura D.1 Topologia tpica de rede das VPN tradicionais

132

A topologia apresentada acima tem dois pontos centrais, conectados por meio de Frame Relay para vrios pontos remotos. Os pontos centrais so conectados entre si e com os pontos remotos por meio de PVC. O roteamento realizado por meio do protocolo de gateway interior EIGRP [5]. O cliente decidiu migrar sua rede atual Frame Relay para uma VPN MPLS, com o objetivo de superar a complexidade e limitao do modelo da rede virtual privada Frame Relay, que usa o modelo Overlay. A nova infra-estrutura de rede usar um provedor de servio que oferece o servio de VPN MPLS, como pode ser visto na figura D.2.

Braslia Site Central Site Central Backup

Curitiba

Backbone VPN/MPLS

So Paulo VPN A

Rio de Janeiro Campinas VPN A VPN A

Figura D.2 Migrao para VPN MPLS A partir dessa topologia de rede necessrio decidir qual das quatros opes de conectividade PE-CE dever ser usada em cada ponto da rede. Como j foi discutido anteriormente, na seo OSPF, se o cliente j est trabalhando com OSPF entre cada ambiente, ele poder decidir pela continuidade do uso desse protocolo entre os roteadores PE e CE. Nessa circunstncia essa uma boa escolha de projeto em funo dos motivos j discutidos anteriormente.

133

No exemplo da figura D1, O protocolo utilizado o EGIRP, portanto, necessrio que o cliente migre o protocolo de roteamento usado por meio do enlace PE-CE para OSPF, BGP-4, RIPv2 ou usar roteamento esttico para que as rotas possam ser trocadas entre os pontos da VPN A e o Backbone da VPN MPLS. Dado o fato de que alguns pontos remotos tm um nico enlace com o backbone VPN MPLS, o roteamento esttico poder ser utilizado em cada roteador PE no Backbone VPN MPLS. Entretanto, alguns pontos como o central, o backup e Rio de Janeiro possuem mais que um enlace com o provedor da VPN. Roteamento esttico no realmente uma boa opo nesse caso; protocolos dinmicos de anncio das rotas so necessrios. A necessidade de roteamento nos pontos remoto e central diferente. No caso dos ambientes remotos, devem aprender outras rotas da VPN MPLS assim que o roteamento entre os pontos estiver disponvel. O ponto Central, entretanto, precisa aprender no somente rotas de outros pontos remotos, mas tambm precisa aplicar polticas em termos do fluxo de dados. Em adio, ele precisa ser um ponto de concentrao em termos de rota (Isso dever incluir rotas Internet aprendidas da VPN MPLS). Por essa razo, RIP v2 pode ser uma escolha adequada para os pontos remotos, mas BGP uma boa escolha para o ponto central, em funo de sua escalabilidade e polticas. Do ponto de vista do provedor de servio, o uso do BGP entre os roteadores CE e PE o protocolo preferido. Isso porque o uso do BGP oferece vrias vantagens para o provedor de servio: H reduo do Overhead, manuteno do roteador PE e as configuraes so simplificadas. Redistribuio entre protocolos de roteamento no necessrio se as rotas so aprendidas por meio do BGP.

134