ENGENHARIA DE TRÁFEGO NAS REDES MPLS: UMA ANÁLISE COMPARATIVA DE SEU DESEMPENHO EM FUNÇÃO DE SUAS DIFERENTES IMPLEMENTAÇÕES

Transcrição

1 ENGENHARIA DE TRÁFEGO NAS REDES MPLS: UMA ANÁLISE COMPARATIVA DE SEU DESEMPENHO EM FUNÇÃO DE SUAS DIFERENTES IMPLEMENTAÇÕES Edson Josias Cruz Gimenez 1, Rodrigo Ramos Vieira 2, Maximiliano José Sales Cardoso 3, Guilherme Alexandre Ferrari 4 Abstract The convergence of services and technologies in the modern networks shows itself as a trend of telecommunications market. Offering more solutions efficient that adds security, facilities and quality of services in real time, has become a challenge to the networks designers. Supporting this new demand is necessary the implantation of an efficient and transparent technology through the backbone, which permits the convergence of diversity protocols and technologies and increase the quality over it, as the traffic engineering over the MPLS Multiprotocol Label Switching. The mainly subject of this paper is analysis of the MPLS architecture and its different implementation to traffic engineering standards by IETF (Internet Engineering Task Force), CR-LDP and the RSVP-TE, comparing and pointing its principal differences. Index Terms Engenharia de Tráfego, CR-LDP, MPLS, RSVP-TE. INTRODUÇÃO A utilização do MPLS tem apresentado uma rápida expansão devido às facilidades de agregação de serviços à rede, possibilitando implementar de forma relativamente simples serviços tais como QoS (Quality of Service), VPNs (Virtual Privates Networks) e engenharia de tráfego. Estas soluções não são novas e nem exclusivas do MPLS, várias outras propostas foram desenvolvidas com o intuito de agregar qualidade de serviço à rede tais como as arquiteturas Intserv e Diffserv em um ambiente IP clássico. O MPLS é baseado no esforço, principalmente do setor privado, para criação e padronização do então novo paradigma, a comutação IP. A engenharia de tráfego é um dos maiores benefícios que o MPLS provê. Este termo refere-se à habilidade para controlar o fluxo de tráfego na rede, com o objetivo de reduzir problemas de congestionamento e conseguir um melhor uso dos recursos disponíveis. A solução para o problema na engenharia de tráfego consiste no fato de que rótulos e caminhos de comutação baseados em rótulos podem ser estabelecidos por uma variedade de módulos de controle. Para o estabelecimento dessas rotas deve ser utilizado um conjunto de protocolos adequados para encontrar e reservar recursos necessários para, por exemplo, garantia de QoS para um serviço. O IETF MPLS Working Group, primeiramente, lançou duas propostas para sinalização do mecanismo de distribuição de rótulos, para implementação de rotas explicitas com o objetivo de otimizá-las, sendo elas o CR- LDP (Constraint Based Routed - Label Distribution Protocol), descrito em [7], e o RSVP-TE (Resource Reservation Protocol Traffic Engineering), descrito em [6]. Este trabalho, através das resoluções do IETF MPLS Working Group, busca a análise destes protocolos de sinalização, objetivando algumas de suas semelhanças e diferenças. O PROTOCOLO MPLS Protocolo desenvolvido pelo IETF (Internet Engineering Task Force), tem sua arquitetura descrita em [3], procurando padronizar os diversos estudos a respeito da comutação IP. Por comutação IP pode-se entender como a capacidade de encaminhar pacotes IP sem a necessidade de analisar seu cabeçalho de camada de rede a cada hop, possibilitando assim uma otimização da rede, eliminação de redundâncias no plano de controle e menor processamento de pacotes. O LER (Label Edge Router) é o equipamento responsável por inserir e remover rótulos nos pacotes, tomando como base critérios como endereço de destino, engenharia de tráfego, multicast, VPN, portas, etc. Estes rótulos são atribuídos a uma FEC (Forwarding Equivalence Class), sendo que os pacotes atribuídos a uma mesma FEC recebem o mesmo tratamento. Quando um pacote rotulado chega a um LSR (Label Switching Router), o rótulo é analisado e então trocado por um rótulo apropriado de saída e, por fim, o pacote é enviado para o próximo hop. A comutação por rótulos é um esquema já utilizado por algumas tecnologias, como por exemplo, o ATM (Asynchronous Transfer Mode), que usa a mesma técnica para enviar células por um caminho virtual através dos 1 Edson Josias Cruz Gimenez, INATEL, Av. João de Camargo, 510, , Santa Rita do Sapucai, MG, Brazil, edsonjcg@inatel.br 2 Rodrigo Ramos Vieira, INATEL, Av. João de Camargo, 510, , Santa Rita do Sapucai, MG, Brazil, rodrigovieira@inatel.br 3 Maximiliano José Sales Cardoso, INATEL, Av. João de Camargo, 510, , Santa Rita do Sapucai, MG, Brazil, max@inatel.br 4 Guilherme Alexandre Ferrari, INATEL, Av. João de Camargo, 510, , Santa Rita do Sapucai, MG, Brazil, rodrigovieira@inatel.br 570

2 campos de identificação VPI (Virtual Path Identifiers) / VCI (Virtual Channel Identifiers). O rótulo é um cabeçalho de encalço (shim header), inserido entre os cabeçalhos de camada de enlace e camada de rede (quando trabalhamos em um ambiente de pacotes), como ilustrado na Figura 1, e seu modelo segue a recomendação do IETF como mostrado na Figura 2. FIGURA 1 POSICIONAMENTO DO RÓTULO ENTRE CAMADAS FIGURA 2 FORMATO DO RÓTULO MPLS O campo Label contém o valor deste. O campo EXP define a classe de serviço a que um pacote pertence, indicando assim a prioridade do pacote. O campo S (stack) suporta o enfileiramento de rótulos. Será utilizado quando o pacote receber mais de um rótulo. O campo TTL (Time to Live) tem aqui a mesma função que no datagrama IP, determinar o numero máximo de hops. Quando o plano de controle do MPLS opera em uma rede ATM, somente os campos VPI /VCI são alterados, não sendo necessária a inclusão de um rótulo, como ilustra a Figura 3. FIGURA 3 MAPEAMENTO ATM UTILIZANDO O PLANO DE CONTROLE MPLS. O pacote rotulado deve ser capaz de atravessar um LSP (Label Switched Path) sendo esse um caminho configurado anteriormente ao encaminhamento MPLS, ou seja, trata-se de um protocolo orientado a conexão. A criação deste caminho virtual é definida pela sinalização MPLS com base em protocolos auxiliares ou configurações manuais. Ao deixar o domínio MPLS, o pacote é enviado para um domínio externo com seu devido protocolo de camada de rede (para um ambiente de pacotes). Este processo consiste em remover o rótulo do cabeçalho do pacote enviando este ao protocolo de nível três apropriado para tratamentos adicionais e seu encaminhamento fora do domínio MPLS. ENGENHARIA DE TRÁFEGO Pode-se definir engenharia de tráfego como o processo de organização do tráfego que flui através da rede para evitar congestionamentos causados por uma utilização desigual da rede. Um dos maiores objetivos da engenharia de tráfego é fazer com que a operação de troca de dados na rede seja eficiente e confiável enquanto há uma otimização de seu desempenho. Devido ao alto custo dos equipamentos e das necessidades atuais do mercado, a engenharia de tráfego já é considerada fundamental em redes de grande porte, onde a qualidade de serviço tem se tornado cada vez mais necessária. É importante perceber que a engenharia de tráfego não necessariamente tomará o caminho mais curto entre os dois equipamentos e que também dois fluxos de pacotes originados de um mesmo nó e que também possuam como destino um mesmo nó, sigam caminhos diferentes se, por exemplo, estes possuírem requisitos de QoS diferentes. MPLS-TE - MULTIPROTOCOL LABEL SWITCHING - TRAFFIC ENGINEERING O roteamento convencional baseado em algoritmos IGP (Interior Gateway Protocol), não proporciona uma distribuição de forma balanceada do tráfego, ou seja, alguns recursos podem ser subutilizados enquanto outros podem sofrer com cargas excessivas de tráfego. Um indicador limitado sobre engenharia de tráfego pode ser fornecido manipulando as métricas do IGP associadas com os enlaces da rede, entretanto estas informações são complicadas de administrar em ambientes com várias opções de encaminhamento entre dois pontos. As métricas determinadas pelos protocolos de roteamento de estado de enlace e a forma como são manipuladas no domínio MPLS são relativamente diferentes de, por exemplo, as usadas em serviços integrados (Intserv) em uma rede IP tradicional. Com o caminho calculado pelas métricas do IGP em questão, torna-se necessário a sinalização para implementá-lo. Duas possíveis soluções foram desenvolvidas pelo IETF MPLS Working Group: o CR-LDP e o RSVP-TE. É interessante observar que, conforme publicado em [4], o IETF MPLS Working Group decidiu abandonar os trabalhos focados no desenvolvimento do CR-LDP a fim de 571

3 concentrar esforços no protocolo RSVP-TE como o protocolo de sinalização para aplicações de Engenharia de Tráfego com MPLS. Como o caráter de nossa pesquisa possui cunho acadêmico, trataremos aqui das diferenças entre essas duas implementações. CR-LDP CONSTRAINT BASED ROUTED - LABEL DISTRIBUTION PROTOCOL O CR-LDP é construído sobre o LDP, que já é parte do MPLS. Embora seus estudos pelo IETF MPLS Working Group tenham sido abandonados, este possui resultados satisfatórios e não precisa da implementação de um novo protocolo, o que aumenta a carga de processamento, como o preterido RSVP-TE. Assim como o LDP, o CR-LDP usa um esquema de codificação denominado TLV (Type-Length-Value). Trata-se de mensagens passadas através da rede, que estão divididas em três campos básicos. O campo type define o tipo de mensagem; o campo length especifica o comprimento do campo seguinte (value) em bytes; o campo value, de tamanho length, codifica a informação que será interpretada de acordo com o campo type e a manipulação desses campos se fazem como necessário para implementar engenharia de tráfego no domínio MPLS. O CR-LDP suporta roteamento explícito tipo strict, o caminho completo a ser seguido é fixo, e também o roteamento explicito loose, onde somente alguns roteadores são nós fixos em um caminho. Utiliza o protocolo UDP (User Datagram Protocol) para descobrir novos pontos em um domínio MPLS e TCP (Transfer Control Protocol) para realização de controle, gerência, label request e label mapping. A sinalização usando o CR-LDP é descrita resumidamente a seguir e ilustrada na Figura 4. FIGURA 4 SINALIZAÇÃO CR-LDP O LSR A (Ingresso), determina que é necessário criar um novo LSP para o LSR C. Os parâmetros de tráfego requeridos para o encaminhamento ou políticas administrativas para a rede determinam ao LSR A para determinar um novo LSP através do LSR B, lembrando que o numero de hops até o destino não é fator determinante para sua designação. O LSR A constrói uma mensagem de label request para determinação da rota explicita e também com detalhes dos parâmetros de tráfego requeridos para a nova rota. Então, o LSR A reserva os recursos requeridos para este novo LSP e encaminha para o LSR B a mensagem de label request em uma sessão TCP. O LSR B recebe esta mensagem e percebe que não é o equipamento de egresso para este LSP, então, caso possível, o LSR B reserva os recursos pedidos para o novo LSP, modifica a informação para o roteamento explicito na mensagem de label request e a encaminha para o LSR C. O LSR C percebe que é o equipamento de egresso para o novo LSP, realiza as reservas de recursos requeridas, caso possível. Este então aloca um rótulo para este novo LSP e distribui o rótulo para o LSR B através de uma mensagem de label mapping, que contém detalhes finais sobre os parâmetros reservados para o LSP. O LSR B recebe a mensagem, finaliza a reserva, atualiza as tabelas correspondentes e passa para o LSR A um novo rótulo através me uma mensagem de label mapping. Finalmente, no LSR A, processamento semelhante ocorre para criação deste LSP, menos o processo para o envio de mensagens para designação de rótulos, já que este se trata do LSR de ingresso para este LSP. RSVP-TE - RESOURCE RESERVATION PROTOCOL -TRAFFIC ENGINEERING Criado inicialmente para aplicações em serviços integrados (Intserv) pelo IETF, o RSVP foi desenvolvido para ser um mecanismo de sinalização com o objetivo de reservar recursos através de uma rede, permitindo a um host especificar uma determinada requisição de serviço para um certo fluxo na rede. As extensões do RSVP para engenharia de tráfego propiciaram uma excelente adequação deste para a distribuição de rótulos MPLS, de forma otimizada. Desde fevereiro de 2003, o IETF MPLS Working Group, conforme [4], passou a concentrar seus esforços no RSVP-TE para sinalização e estabelecimento de rotas em um ambiente MPLS. O processo de sinalização usando o RSVP-TE é bastante parecido àquele com o uso do CR-LDP, e é mostrado de forma resumida abaixo, sendo ilustrado na Figura 5. FIGURA 5 SINALIZAÇÃO RSVP-TE 572

4 No processo utilizando o CR-LDP, o LSR A (Ingresso) tem a função de criar um LSP até LSR C. Os parâmetros de tráfego requeridos para o encaminhamento ou políticas administrativas para a rede indicam ao LSR A para determinar um novo LSP através do LSR B. É importante ressaltar que a menor distancia não é fator determinante para escolha desta rota. O LSR A cria uma mensagem Path para determinação da rota explicita e também com detalhes dos parâmetros de tráfego requeridos para a nova rota. Então, o LSR A reserva os recursos requeridos para este novo LSP e encaminha para o LSR B a mensagem Path em um datagrama IP. O LSR B recebe esta mensagem e percebe que não é o equipamento de egresso para este LSP. Então, caso possível, o LSR B reserva os recursos pedidos para o novo LSP, modifica a informação para o roteamento explicito na mensagem Path e a encaminha para o LSR C. O LSR C percebe que é o equipamento de egresso para o novo LSP. Ele realiza as reservas de recursos requeridas, caso possível. Este então aloca um rótulo para este novo LSP e distribui o rótulo para o LSR B através de uma mensagem Resv, que contem detalhes finais sobre os parâmetros reservados para o LSP. O LSR B recebe a mensagem, finaliza a reserva, atualiza as tabelas correspondentes e passa para o LSR A um novo rótulo através de uma mensagem Resv, e assim, como quando utilizamos o CR-LDP, o LSR A reserva os recursos necessários e não aloca ou encaminha para um LSR ascendentes (upstream) um novo rótulo já que este é o LSR de ingresso, finalizando assim o este LSP. COMPARAÇÃO ENTRE O CR-LDP E O RSVP-TE As semelhanças entre os protocolos CR-LDP e RSVP-TE são inúmeras quando se trata do conteúdo das mensagens. Basicamente o conteúdo é o mesmo, exceto por alguns pequenos detalhes. Ambos transportam as mesmas informações para o estabelecimento das rotas. A principal diferença no funcionamento dos protocolos se deve às implicações decorrentes do RSVP-TE ser softstate, enquanto o CR-LDP é hard-state. O fato do RSVP-TE ser soft-state proporciona um overhead o que requere que mensagens de refresh sejam enviadas periodicamente entre cada nó da rede para manutenção de um LSP. Algumas alterações foram propostas para solucionar esse problema no RSVP-TE para minimizar os efeitos do soft-state, como a introdução de um mecanismo de reconhecimento de mensagem recebida (acknowledge), tornando o protocolo de troca de mensagens confiável, possibilitando reduzir o tempo de refresh dos estados e consequentemente o overhead. Outro mecanismo para redução do overhead é a possibilidade de com apenas uma mensagem realizar o refresh de vários estados simultaneamente. Outra diferença essencial no funcionamento destes protocolos é o mecanismo de rápida notificação de falhas presentes no RSVP-TE, implementado pela mensagem Notification. O protocolo CR-LDP também possui uma mensagem de notificação (Notification), entretanto as funções de ambas são distintas. No CR-LDP quando uma falha em uma rota é detectada ela é propagada com as mensagens Release/Withdraw a partir do ponto de falha. Os recursos alocados devem ser liberados nesta fase. A mensagem de notificação serve para informar falhas no processamento de mensagens. Já no RSVP-TE a mensagem de notificação informa sobre falhas em rotas e é enviada diretamente do ponto de detecção ao ponto de reparação (um LSR responsável por realizar a restauração do LSP). Na Tabela 1 são identificadas algumas semelhanças entre ambos os protocolos, enquanto a Tabela 2 mostra as suas principais diferenças. TABELA 1 SIMILARIDADES ENTRE O CR-LDP E O RSVP-TE. Características CR LDP RSVP-TE Sinalização Inicial Sinalização de confirmação Definição para serviços diferenciados (Diffserv) Suporte para LSPs point-tomultipoint Capacidade para rotas explícitas Mensagens de label request Mensagens de label mapping DIFFSERV_PSC TLV Não Esta é definida pela sinalização contida na TLV. Mensagens Path contendo o pedido do rótulo Mensagens RESV DIFFSERV_PSC object Não Esta é carregada no objeto EXPLICIT_ROUTE TABELA 2 DIFERENÇAS ENTRE O CR-LDP E O RSVP-TE Características CR LDP RSVP-TE Estágio de desenvolvimento Transporte de Sinalização Estado da Conexão Recente UDP para novas descobertas, TCP para manutenção da sessão hard state Antigo, com novas extensões adicionadas para engenharia de tráfego. Datagramas IP ou encapsulamento UDP. soft state 573

5 Confiabilidade Extensiabilidade Escalabilidade Interoperabilidade Falhas produzem uma resposta Da sinalização TLVs experimentais Conexões hard state reduzem o processamento de sinalização Bem definida, suporte a maioria dos protocolos de camada de enlace. CONCLUSÃO Depende do tempo entre as mensagens de refresh. Objetos experimentais Requer redução de mensagens de refresh, agregação para diminuir o processamento. Tunelamento através de redes ATM pode ser configurado manualmente O MPLS aparece no cenário de redes como uma arquitetura emergente, baseada num modelo de encaminhamento de pacotes, sendo a tecnologia que se apresenta mais promissora na tentativa de melhorar o desempenho das redes, por ser flexível e por permitir seu mapeamento em várias tecnologias de rede. As suas melhores perspectivas se apresentam no uso conjunto com a tecnologia IP, adicionando a esta o paradigma de circuito virtual e a possibilidade de aplicar conceitos como a engenharia de tráfego e a garantia de QoS, sem haver a necessidade de alterar totalmente a estrutura já existente nas redes de dados atuais. A engenharia de tráfego torna-se cada vez mais necessária, não somente por seu caráter técnico, mas também como um fator econômico, um uso mais inteligente da rede cria a possibilidade de não ser necessário a atualização de equipamentos para atender alguma carência de, por exemplo, largura de banda para transmissão. Ambos os protocolos de sinalização aqui analisados, o CR-LDP e o RSVP-TE, disponibilizam funcionalidades similares para a implementação de engenharia de tráfego e para o estabelecimento de rotas, apesar de haver um consenso sobre o uso do RSVP-TE. Não há um motivo determinante para tal escolha, porém pode-se citar o fato do RSVP-TE ser largamente utilizado para reserva de recursos nas redes IP tradicionais, havendo apenas a necessidade de adicionar a capacidade de distribuição de rótulos, que é feito através de suas extensões. [2] OSBORNE, E.; SIMHA, A. Engenharia de tráfego com MPLS. Rio de Janeiro, Editora Campus, [3] E. ROSEN, E.; VISWANATHAN, A.; CALLON, R, Multiprotocol Label Switching Architecture, < ftp://ftp.rfc-editor.org/innotes/rfc3031.txt>. [4] Andersson, L.; Swallow, G. The Multiprotocol Label Switching (MPLS) Working Group decision on MPLS signaling protocols, < ftp://ftp.rfc-editor.org/in-notes/rfc3468.txt>. [5] International Engineering Consortium A Comparison of Multiprotocol Label Switching (MPLS) Traffic-Engineering Initiatives, < index.htm>. [6] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., Swallow G., RSVP-TE: Extensions to RSVP for LSP Tunnels, <ftp://ftp.rfceditor.org/in-notes/rfc3209.txt>. [7] Jamoussi, E.,B., Andersson L., Callon, R., Dantu, R., Wu, L., Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M., Gray, E., Heinanen, J., Kilty, T., Malis, A., Constraint-Based LSP Setup using LDP, <ftp://ftp.rfc-editor.org/in-notes/rfc3212.txt>. [8] Andersson L., Swallow G., The Multiprotocol Label Switching (MPLS) Working Group decision on MPLS signaling protocols <ftp://ftp.rfc-editor.org/in-notes/rfc3468.txt> REFERÊNCIAS [1] BRITTAIN,P, FARREL, A MPLS traffic engineering: a choice of signaling protocols. Data Connection Limited, 17 January ( 574