UFPR - UNIVERSIDADE FEDERAL DO PARANÁ
MESTRADO EM TELECOMUNICAÇÕES
AUTOR: MARCELO NELSON WADECK
ORIENTADO POR: PROF. DR. EDUARDO PARENTE RIBEIRO
NOVEMBRO DE 2001
INTRODUÇÃO AO MPLS
ABSTRACT
The
rapid growth of the IP networks and the need for new services and quality
garantees show the shortcomings of the IP stack to fulfill the management and
control needs of this networks. Solutions like IP over ATM are expensive and do
not provide the necessary escalability.
This work is a survey about the new
paradigm of quality provinioning and management for IP networks: the
MultiProtocol Label Switching – MPLS, giving an introductory overview of this
protocol, its architecture and associated signalings.
KEYWORDS:
IP Networks, Quality of Service (QoS), MPLS, RVSP-TE, CR-LDP.
RESUMO
A crescente escalada das redes IP e a demanda por novos serviços e garantias de qualidade mostram as deficiências da família de protocolos IP para suprir as necessidades de controle e gerência destas redes. Soluções como IP over ATM se mostram custosas e sem a escalabilidade necessária.
Este trabalho é um apanhado geral do novo paradigma para a provisão de qualidade e gerência em redes IP: o MultiProtocol Label Switching – MPLS, fornecendo uma visão introdutório sobre este protocolo, sua arquitetura e sinalizações associadas.
PALAVRAS-CHAVE:
Redes IP, Qualidade de Serviço
(QoS), MPLS, RVSP-TE, CR-LDP.
1. Introdução: IP, um mundo do melhor esforço
Um dos mercados mais competitivos atualmente no ramo das telecomunicações é o do transporte de dados e de redes convergentes. E a grande maioria do tráfego a ser transportado é baseada em IP. Mas o IP é uma tecnologia regida pela lei do menor esforço, não foi desenvolvida para para prover qualidade diferenciada a clientes e serviços. As características do família de protocolos IP somada ao rápido desenvolvimento das redes baseadas IP apresenta vários desafios aos seus operadores de serviço.
As novas aplicações requerem
serviços que são determinísticos por natureza e essas aplicações devem ser
garantidas através de toda a rede por onde trafegam os dados. O desafio é
prover tais condições em uma rede não-determinística como a rede IP.
As tecnologias de roteamento atuais
levam em conta apenas o endereço de destino para determinar o melhor caminho,
não considerando as características e atributos dos dados.
Com o crescimento da rede os
roteadores tem que lidar com grandes volumes de informações de roteamento. Além
disso, a decisão de encaminhamento é feita a cada hop, o que inibe
escalabilidade e performance.
A redução de custos de deposição de equipamentos,
manutenção e operação é essencial para os operadores de redes de grande porte
(WANs). Se eles pudessem construir redes apenas baseadas em IP, seus custos
diminuiriam sensivelmente. Contudo, o IP não está a altura desta tarefa,
principalmente porque lhe falta mecanismos de engenharia de tráfego os quais os
operadores necessitam para cumprir os contratos de Service Level Agreement
(SLA) com seus clientes.
Como protocolo não orientado a conexão, o IP não
realiza nenhuma destas tarefas. Embora suporte priorização de pacotes, o IP não
pode garantir que os recursos da rede estejam disponíveis quando necessários. E
ainda o IP faz o encaminhamento de tráfego entre dois pontos sempre sobre a
mesma rota, mesmo durante períodos de congestionamento, enquanto outras rotas
ficam sub-utilizadas.
Esta é outra razão pela qual muitos operadores
utilizam ATM para transportar o tráfego IP, como apontado por Bellman[1]. Eles precisam dos circuitos virtuais do ATM para
controlar a alocação de banda em rotas congestionadas. E porque o ATM é
orientado a conexão, ele fornece aos operadores as ferramentas de engenharia de
tráfego que eles necessitam para controlar o QoS e a utilização de recursos.
Mas o IP sobre ATM não é uma solução perfeita.
Primeiramente, esta metodologia superposta significa que o operador de rede tem
que lidar com dois planos de controle, administrando tanto roteadores IP e
switches ATM. Tal solução é por demais custosa, além de impedir sua
escalabilidade.
A escalabilidade é também comprometida já que cada
roteador necessita de um VC separado para cada outro roteador. Quando a rede
cresce, o número de rotas e VCs cresce exponencialmente, eventualmente
superando a capacidade tanto de switches como roteadores.
O MultiProtocol Label Switching (MPLS) é um novo
paradigma que permite tornar uma rede baseada somente em IP uma realidade,
provendo a capacidade de engenharia de tráfego que os operadores necessitam.
Capacidade que não pode ser subestimada, especialmente no mundo orientado a SLA
dos controladores de rede. A engenharia de tráfego provê aos operadores o
controle da qualidade de serviço (QoS) e a otimização dos recursos da rede.
Além disso, também fornece a base natural para a criação de redes privadas
virtuais (VPNs). O MPLS trata destes problemas diretamente, trazendo conexões
tipo ATM sob o controle de protocolos de roteamento IP.
2. MPLS: um novo paradigma de qualidade
No MPLS os
pacotes são encaminhados baseado em pequenos labels, ao invés dos mecanismos
tradicionais de análise do cabeçalho IP. A cada pacote que entre na rede é
anteposto um label que direciona-o a um fluxo.
A tecnologia MPLS utiliza informações de roteamento
da camada três enquanto executa a comutação na camada dois (através de suporte
de hardware), resultando em um roteamento rápido através da rede, e que onde os
requisitos de QoS das aplicações são levados em conta.
Uma rede MPLS compreende
uma série de “label switch routers” (LSRs), que são roteadores e/ou switches
ATM com capacidade MPLS. Cada vez que um pacote entra na rede, a LSR de entrada
atribui a ele um label baseado no seu destino, se faz parte de uma VPN, tipo de
serviço, etc.
A cada próximo hop, um LSR utiliza este label como
índice em uma tabela de encaminhamento. Esta tabela atribui a cada pacote um
novo label – para prover escalabilidade, os labels tem apenas significado local
– e direciona o pacote para uma porta de saída. Como resultado, todos os
pacotes marcados com o mesmo label seguem o mesmo caminho, o “label switched
patch” (LSP), através da rede.
Figura 1:
Operação básica do MPLS.
Diferenças entre o MPLS e o roteamento convencional IP
incluem o fato que pacotes enviados entre dois pontos podem ter labels
diferentes e então seguir caminhos diferentes. Ainda o encaminhamento MPLS é
rápido e simples, porque cada LSR analisa apenas o label e nada mais.
|
|
Roteamento
IP tradicional |
Comutação
por labels |
|
Análise
completa do cabeçalho IP |
Executada
a cada hop na rede. |
Executada
apenas uma vez no ingresso do pacote na rede. |
|
Suporte
para Unicast e Multicast |
Requer
mecanismos especiais para roteamento multicast e algoritmos de
encaminhamento. |
Requer
apenas um algoritmo de encaminhamento. |
|
Decisões
de roteamento |
Baseado
unicamente no endereço destino do cabeçalho IP. |
Baseado
em um número de parâmetros, incluindo endereço de destino, QoS, tipo de
dados, etc. |
Tabela 1:
Diferenças entre roteamento IP tradicional e comutação por labels MPLS
No roteamento convencional IP, um roteador utiliza o endereço de destino no cabeçalho IP para determinar o encaminhamento do pacote. Em uma rede MPLS um label (rótulo) de 20 bits é utilizado para tomar esta decisão. No encaminhamento tradicional, cada decisão de encaminhamento tomada por um roteador é independente das demais já tomadas. No MPLS esta decisão é feita uma única vez, no ingresso do pacote na rede. Um vez atribuído um label a um pacote, este viaja com ele até o próximo nó. Todos os demais pacotes que atendam aos mesmos critérios são rotulados com o mesmo label. Não haverá mais analises dos cabeçalhos dentro da rede, apenas do label. O label é utilizado como índice em uma tabela, que fornecerá o próximo nó e um novo label, que substituirá o antigo, e o pacote será encaminhado ao próximo nó.
Este label é similar aos identificadores de conexão VPI/VCI do ATM e é utilizado para identificar uma classe equivalente de encaminhamento (FEC – Forwarding Equivalence Class). Uma FEC descreve um conjunto de pacotes encaminhados pela mesma rota pela rede, mesmo que seus destinos finais sejam diferentes. Todos os pacotes assinalados para um FEC em particular são enviados por um Label Switched Patch (LSP), o equivalente funcional de um VC, já que define o caminho entre a entrada e a saída da rede.
Um exemplo de cabeçalho MPLS pode
ser observado abaixo:
L2 Layer MPLS Header IP
Header User data
Label CoS S TTL
32 bits no total
20
bits 3 bits 1 bit
8 bits
O campo Label (20 bits) carrega o rótulo MPLS.
O campo Class of Service (QoS), também chamado de
extensão (EXT) pode afetar os mecanismos de enfileiramento e descarte aplicados
aos pacotes no transverso da rede.
O campo de Stack (S) é um bit que indica a ordem
hierárquica no label stacking.
O campo Time-to-live (TTL) provê a mesma funcionalidade
do IP TTL.
O MPLS é constituído por uma série de blocos
funcionais, nas quais se destacam os mecanismos de atribuição/encaminhamento
por labels e o de distribuição de labels.
O primeiro componente inclui o algoritmo de de
classificação dos pacotes no ingresso da rede para marcá-los com um label
inicial, bem como a tabela de encaminhamento para uma porta/label de entrada
para um pacote entrante.
O mecanismo de distribuição de labels representa a
sinalização de controle, que utiliza protocolos de roteamento/distribuição de
labels como o BGP, o RSVP e o LDP, para trocar informações com outros
roteadores, e construir a tabela de encaminhamento com a informação obtida.
Existem três funções básicas dos roteadores na rede
MPLS, realizadas pelos LSRs:
a) Roteador de ingresso: é o roteador no início de um
LSP. É seu trabalho encapsular os pacotes IP com um frame MPLS e encaminhado
até o próximo LSR no caminho.
b) Roteador de saída: é o fim de um LSP, deve remover
o encapsulamento, transformando o pacote novamente em um pacote IP convencional
e encaminhando-o a seu destino final.
c) Roteador trânsito: qualquer LSR intermediário no
LSP entre o roteador de ingresso e o de saída da rede MPLS, que executa o
encaminhamento dos pacotes ao próximo LSR.
Existem dois tipos de LSPs, os estáticos, cuja
configuração é executada manualmente, de maneira semelhante a configuração
estática de rotas em IP; e os LSPs dinâmicos, criados através dos mecanismos de
distribuição de labels como o RSVP e o CR-LDP.
Uma outra facilidade do
MPLS bastante útil aos operadores de serviço é o empilhamento de labels (“label
stacking”). Label stacking permite aos LSRs inserir um label adicional na frente
de cada pacote já marcado com um label, criando um túnel encapsulado que pode
ser compartilhado por múltiplos LSPs. Ao final do túnel, um outro LSR retira o
label stack, revelando o label interno. Ao contrário do ATM, que permite apenas
um nível de empilhamento – Virtual Channels dentro de Virtual Paths – o MPLS
suporta empilhamento ilimitado, o que permite o agregamento de fluxos de dados.
Os provedores de serviço podem utilizar label stacking para unir centenas de
milhares de LSPs em um número relativamente pequeno de túneis backbone entre
pontos de presença, o que leva a tabelas de roteamento menores, tornando mais
fácil aos provedores a tarefa de prover escalibilidade da rede.
A construção de VPNs pode não ser o objetivo
principal do MPLS, mas é sem dúvida uma de suas facilidade com maior apelo de
marketing. MPLS permite aos operadores de serviço criar VPNs com a
flexibilidade do IP mas com o QoS do ATM. Labels separados garantem a
privacidade entre VPNs sem recorrer a criptografia. De fato, a criação de
VPNs está entre as primeiras aplicações
do MPLS para muitos operadores.
Figura 4:
Construção de Redes Privadas Virtuais (VPNs) utilizando o MPLS.
3. Mapeamento e comutação por labels
A atribuição e encaminhamento por labels representam
o componente principal do MPLS. A análise do cabeçalho IP é feita apenas uma
vez no ingresso no Label Switched Patch (LSP) para a classificação dos pacotes.
Os pacotes que são encaminhados para o mesmo próximo nó são agrupados em
"Forwarding Equivalence Class" (FECs) baseados em um ou mais
parâmetros como prefixo do endereço, endereço de host, qualidade de serviço
(QoS), etc.
Este FEC ao qual os pacotes pertencem são codificados
pro labels, que são repassados ao próximo hop. Nos próximos encaminhamentos,
não é feita mais a análise do cabeçalho IP, mas apenas o label é utilizado como
índice em uma tabela, que estabelece o próximo hop e um novo label que subsituí
o antigo.
Figura 5:
Encaminhamento por Forwarding Equivalent Class.
Um LSR sabe como encaminhar os pacotes rotulados do MPLS através da criação de um vínculo entre o label MPLS e uma classe de encaminhamento equivalente. O vínculo entre label/FEC é feito através da sinalização utilizando um protocolo de distribuição de labels (por ex. LDP, RSVP). Cada LSR em um domínio MPLS deve atribuir labels e distribuí-los aos seus parceiros para criar um caminho – Label Switched Path (LSP) por onde o fluxo de dados vai trafegar.
Um label MPLS é colocado sobre o pacote para indicar a que FEC ele pertence. Este mapeamento do pacote a FEC é feito apenas uma vez, na entrada da rede.
Os labels tem significado local e são utilizados para
identificar FECs baseados no tipo de rede sobre a qual o MPLS é utilizado. Por
exemplo, em redes ATM, o Virtual Path Identifier (VPI) e o Virtual Channel
Identifier (VCI) são utilizados para se chegar ao label.
Um LSR Downstream é o nó que aceita
os pacotes rotulados, e é responsável pela geração do label para a criação do
vínculo label/FEC e distribuição ao LSR Upstream deste vínculo. A geração dos
labels e distribuição dos vínculos é feita opostamente ao fluxo de dados. O
label para o vínculo FEC deve ser único no nó MPLS que aceita o label, para
previnir que outro nó aceite o mesmo label para uma FEC diferente. É Trabalho
do LSR Downstream garantir um vínculo um-a-um entre o label e a FEC.
Um LSR Upstream é o nó enviando os
pacotes rotulados. O MPLS suporta dois métodos para o nó upstream obter o label
para o vínculo FEC. O primeiro é referido como método “downsteam em demanda”. O
nó upstream faz uma requisição ao próximo nó para obter um label vinculado a
FEC indicado. O segundo método permite a um LSR distribuir vínculos que não
foram explicitamente requisitados (“rotulamento downstream não solicitado”). Um
nó MPLS pode suportar ambos estes métodos, mas cada adjacência LSP deve
concordar em qual dos métodos utilizar.
Dois métodos para o controle de
vínculos de labels LSP existem: controles ordenado e independente.
Controle Ordenado é utilizado por um LSR apenas para
vincular um label a uma FEC em particular se ele é o LSR de engresso para
aquela FEC ou se já tiver recebido um vínculo para aquela FEC do próximo nó
desta FEC. Controle Ordenado deve ser utilizado para garantir que o tráfego em
uma FEC em particular siga um caminho com algum conjunto de propriedades
especificado.
Controle Independente é utilizado
quando cada LSR que reconhece uma FEC específica faz um decisão independente de
vincular um label a esta FEC e então distribui este vínculo aos seus parceiros
LSP. Contudo, com Controle Independente alguns LSRs podem iniciar um tráfego
MPLS para uma FEC antes do LSP estar completamente estabelecido e
consequentemente causar problemas, como gerar tráfego para um FEC em um caminho
que não tenha o conjunto especificado de propriedades.
Figura 6:
Distribuições de labels ordenada e independente
O MPLS possuí ainda algumas facilidades
para o mapeamente e distribuição de labels, como agregação, união, desagregação
e retenção de labels.
A agregação é utilizada para economizar labels e diminuir o
tráfego de sinalização em um domínio MPLS, sendo realizada através da
atribuição de um único label para uma união de FECs que atravessam o mesmo
caminho. A agregação tem diferentes níveis de granularidade. As escolhas para
agregação incluem agregar todos os FECs com caminhos similares em um único FEC
(melhor esforço), agregá-los em conjuntos de FECs (ex. label por nível de CoS)
ou não agregá-los (serviço garantido).
União (merging) é a agregação feita
ao nível de LSP ao invés de ao nível dos pacotes. Pacotes chegando a um nó MPLS
de diferentes LSPs mas pertencendo ao mesmo FEC podem ser unidos e enviados em
um único LSP.
A desagregação é realizada onde o
LSP termina. No ponto de desagregação uma decisão deve ser tomada baseada nos
parâmetros da camada 3 para decidir pelo envio do pacote a outro LSP ou a um
domínio não MPLS.
Retenção de labels. Existem dois
métodos para retenção de labels: liberal e conservador. O primeiro permite ao
nó MPLS manter um label no vínculo FEC para um nó que não é mais o próximo hop.
O benefício disto é que o vínculo pode ser utilizado imediatamente se o nó
tornar-se o próximo hop novamente. É menos sensível a mudanças de rota, mas
requer espaço extra nas tabelas de encaminhamento. Já no método conservador, o
vínculo label/FEC é removido caso o próximo hop deixe de sê-lo. Utiliza menos
espaço das tabelas de encaminhamento mas requer que o vínculo seja recriado se
o nó tornar-se novamente o próximo hop.
A classificação dos pacotes que
entram no domínio MPLS não pode ser realizada até que o fluxo ao qual o pacote
pertença tenha estabelecido um LSP, cuja criação pode ser baseada em
informações de gerência ou através de protocolos de sinalização. O resultado da
classificação é determinado através dos seguintes atributos: classe de serviço
pela qual o pacote deve ser transportado, prioridades de atraso e descarte para
os diferentes serviços, parâmetros que determinam a qualidade de serviço
desejada.
Uma manutenção sobre o estado da
classificação é executada para garantir que vínculos LSP que não são mais
necessários sejam apagados. Esta remoção pode ser invocada das seguintes
maneiras: time out do fluxo, fim de um fluxo individual, ou eventos de
sinalização que indiquem o fim de uma requisição de reserva.
O mapeamento dos pacotes aos labels
apropriados é feito baseado no resultado da classificação. De modo a corretamente
mapear um pacote a um fluxo o mapeamento deve levar em conta os atributos de
tráfego associados com o fluxo bem como as informações de topologia. Dois tipos
de mapeamento são possíveis: métodos direto e indireto.
Mapeamento Direto é o realizado diretamente do classificador para o LSP, podendo ser realizado apenas para serviços que não tenham garantias explícitas (por exemplo aqueles serviços sem garantia de banda). Mapeamente Indireto é realizado quando para reservas que tenham garantias explícitas.
4. Distribuição de labels
Protocolos de
distribuição de labels são utilizados por dois LSRs para negociar os vínculos
label/FEC. No MPLS estes vínculos são sempre realizados pelo LSR Downstream, ou
seja, aquele que irá receber o fluxo dos dados (atribuição dos labels em
sentido oposto ao do fluxo de dados). O vínculo é então repassado ao LSR
Upstream.
Os requisitos
gerais para a distribuição de labels, cuja estrutura todos os protocolos devem
prover, são os seguintes:
Setup Request,
utilizado para requisitar o estabelecimento de um LSP. Carrega os atributos
desejados para a sua criação.
Setup
Modification, utilizado para modificar os atributos de um LSP já estabelecido.
Setup
Acknowledge, utilizado para confirmar (aceitar) um Setup Request ou Setup
Modification.
Setup
Reject, utilizado para indicar que um ou mais atributos de um Setup Request ou
Setup Modification não podem ser atendidos.
Label
Distribution, utilizado pelo LSR downstream para distribuir o mapeamento de labels
aos seus parceiros.
Label Removal, utilizado pelo parceiro Downstream indicar ao parceiro Upstream que o label associado a um dado fluxo não é mais válido.
As mensagens tipo Discovery provêm um mecanismo onde
LSRs indicam sua presença na rede através do envio de mensagens Hello
periodicamente, transmitidas como pacotes UDP para a porta LDP de todos os
membros do grupo multicast "todos os roteadores nesta subrede".
Quando um LSR decide estabelecer uma sessão com outro LSR descoberto via mensagem
Hello, ele utiliza o procedimento de inicialização LDP com transporte por TCP.
Após uma bem sucedida execução deste mecanismo de inicialização os dois LSRs
são LDP peers e podem trocar mensagens tipo Advertisement.
O LSR solicita um mapeamento de label ao LSR vizinho
quando precisa de um e anuncia um mapeamento de label ao LSR vizinho quando
deseja que este utiliza um label. O LDP utiliza o TCP como transporte a
mensagens tipo Session, Advertisement e Notification, uma vez que o TCP provê
uma entrega confiável de mensagens.
A
distribuição de labels é conseguida através de três modos:
a) BGP - Extendendo-se os protocolos de roteamento como o BGP (Border Gateway Protocol) para suportar a distribuição de labels. Neste caso, quando um par de LSRs trocar informações de rotas, eles devem também trocar informações de mapeamento de labels para estas rotas, através do envio destas informações na forma de carona na mesma mensagem Update do BGP quando tracando rotas.
b) RVSP-TE
- Utilizando mecanismos de sinalização RSVP
(Resource ReSerVation Protocol), com estensões para engenharia de
tráfego (TE - Traffic Engineering), para distribuir labels mapeados a fluxos
RSVP. A informação de requisição de labels para lables associados a fluxos RSVP
podem ser carregados como parte das mensagens RSVP Patch e a informação de
resposta como parte das mensagens RSVP Resv.
c) LDP -
Utilizando o Label Distribution Protocol (LDP), que é um conjunto de
procedimentos e mensagens através das quais LSRs estabelecem LSPs pela rede,
através do mapeamento de informações de roteamento da camada de rede
diretamente a caminhos da camada de enlace.
4.1 LDP – Label Distribution Protocol
O LDP (Label Distribution Protocol) é uma das
propostas de sinalização dos vínculos label/FEC e capacidades MPLS entre
roteadores/nós MPLS. Embora sua especificação básica não possua nenhuma
parametrização de engenharia de tráfego, possui estensões para lidar com
roteamento explícito (o chamado CR-LDP).
Suporta quatro categorias de mensagens:
- Discovery messages, utilizadas para anunciar um LSR
na rede.
- Session messages,
utilizadas para estabelecer, manter e terminar sessões entre
parceiros LDP.
- Advertisement messages,
utilizadas para criar, mudar e apagar mapeamentos de labels para FECs.
- Notification messages,
utilizadas para prover informações e sinalizar erros.
Para estabelecer e manter
um LSP, o LDP suporta as seguintes mensagens:
- Request Message,
utilizada pelo LSR upstream para requisitar explicitamente que um LSR
downstream mapeie e anúncie um label para um fluxo.
- Acknowledge Message, enviada por um LSR se ele não
puder processar um mensagem Advertisement recebida ou em resposta a uma
mensagem Query.
- Withdraw Message, enviada pelo LSR downstream para indicar
ao LSR upstream que o label a ele fornecido não é mais válido.
- Release Message, enviado pelo LSR upstream para
indicar que ele não está mais utilizando o label recebido.
- Query Message, utilizada para prevenção de loop,
juntamente com algoritmos difusos para assegurar que o novo caminho criado para
um LSP não possuí loops.
- Advertisement Message, utilizada pelo LSR
downstream para distribuir o mapeamento de label de um fluxo a seus parceiros
LDP.
O mecanismo pelo qual um LSR descobre seus parceiros
LDP é chamado de LDP Discovery. Este mecanismo torna desnecessário configurar
explicitamente os parceiros de comutação de labels. O protocolo LDP suporta
dois mecanismos de descoberta de parceiros: básico e estendido.
O mecanismo básico é utilizado para descobrir LSRs
vizinhos que estão diretamente conectados no nível de enlace. É realizado
através do envio de Hellos periódicos na forma de pacotes UDP endereçados à
porta LDP para o grupo multicast "todos os roteadores nesta subrede".
O mecanismo estendido é utilizado para descobrir LSRs
vizinhos que não estão conectados diretamente ao nível de enlace. É realizado
através do envio de Hellos periódicos na forma de pacotes UDP endereçados a um
endereço IP específico.
Para as demais mensagens LDP, é necessário um
mecanismo de transporte confiável, e por isso o TCP é utilizado.
A estensão do LDP para engenharia de tráfego é
denominado CR-LDP (Constraint-based Routed LDP), utilizado para sinalizar os
requisitos de recursos de um fluxo em cada nó da rede. As informações de
roteamento forçado que este protocolo suporta estão descritas a seguir:
- Roteamento Explícito Restrito e Vago (Strict and
Loose Explicit Routing): a mensagem de requisição de label conterá informações
de rota explícita representadas na forma de uma lista de nós específicos ou
grupo de nós pelos quais a rota vai sr especificada.
- Especificação de parâmetros de tráfego, como banda
(taxas contratadas e de pico) e variações de atraso.
- Preferência CRLSP, onde caso não existam recursos
para atender um caminho, outros caminhos podem ser reroteados para
disponibilizar recursos para este caminho prioritário.
- Fixação de rotas (Route Pinning). Um LSP pode ser
estabelecido utilizando fixação de rotas para evitar mudanças no caminho
utilizado por ele quando um melhor próximo hop se torna disponível, quando da
utilização de roteamento explícito vago.
- Classe de recursos, que indica o tipo de enlace o
LSP pode atravessar.
Podemos observar abaixo um exemplo[2] de roteamento explícito restrito utilizando CR-LDP:
Figura 7:
Exemplo de um roteamento explícito restrito utilizando CR-LDP.
4.2
RSVP-TE – Resource reSerVation Protocol (Traffic Engineering)
O protocolo de reserva de recursos RSVP foi espandido
para sua utilização em domínios MPLS. As seguintes mensagens são utilizadas:
- RSVP Path message, utilizada para Setup Request e
Setup Modification.
- RSVP Resv message, provê a distribuição dos labels e Setup Acknowledgement.
- RSVP Path error mesages, utilizadas para Setup rejection
em casos de que os atributos requisitados não possam ser cumpridos pelo LSR que
recebeu o Setup Request.
O nó de ingresso MPLS requisita um vínculo de um
label a um LSP ou túnel LST através do envio da mensagem Path que contém um
novo objeto chamado Label_Request. No nó downstream os labels são alocados e
distribuídos ao nó upstream através da mensagem Resv que contém o novo objeto
Label.
A remoção de um label pode ser feita tanto através de
um mensagem RSVP ResvTear, ou pela falta de mensagens periódicas RSVP ou ainda
por uma mensagens Patch com nenhum label. Quando é detectado que um label deve
ser removido, a mensagem Path deve ser enviada sem nenhum label. Qualquer LSRs
recebendo esta mensagem pode alocar um novo label e enviar uma mensagem RSVP
com este novo label para reestabelecer a conexão LSP.
A mensagem RSVP Path foi espandida para conter também
um objeto que permite roteamento explícito pelo nó que inicia uma conexão.
O nó MPLS downstream (receptor) é responsável pro
selecionar o estilo de reserva para cada sessão RSVP. Cada sessão RSVP deve
possuir um estilo:
- Estilo Filtro Fixo (Fixed Filter - FF), que cria
uma reserva distinta para cada tráfego enviado que não é compartilhada com
outros usuários. O total de banda reservada é a soma das reservas individuais
de cada emissor.
- Estilo Compartilhamento Explícito (Shared Explicit
- SE), que permite ao receptor explicitar os emissores incluídos na reserva
(banda compartilhada). Cada emissor esta listado na mensagem RSVP e labels
diferentes vão ser atribuídos a cada um deles, criando consequentemente
diferentes LSPs.
- Estilo Filtro Coringa (Wildcard Filter WF), onde
uma única reserva é utilizada para todos os emissores (LSP multiponto-a-ponto),
útil para aplicações nas quais nem todos os emissores envirão tráfego ao mesmo
tempo.
O suporte a túneis LSP é feito através do objeto
LSP_Tunnel_Ipv4 da mensagem RSVP Session. Para criar um túnel LSP o primeiro nó
MPLS no caminho gera uma mensagem RSVP Patch com o tipo de sessão marcado para
LSP_Tunnel_Ipv4 e um objeto Label_Request. Se o nó emissor tem conhecimento de
uma rota que satisfaça os requerimentos de tráfego do túnel, ele irá incluir um
objeto Explicit_Route nesta mesma mensagem. Se o nó emissor deseja ligar a
gravação de rota para este túnel, ele irá incluir um objeto chamado
Record_Route.
O nó de destino responde a um label_Request incluindo
um objeto Label na mensagem RSVP de resposta. A mensagem Resv é enviada de
volta ao emissor, que utiliza o objeto Label para o fluxo de tráfego associado
a este túnel. Se o nó anterior não for o emissor, este aloca um novo label e o
coloca no campo Label da mensagem Resv enviada ao nó anterior. Este label
enviado ao nó anterior é aquele que ele deve utilizar para identificar o
tráfego associado com este túnel. Quando a mensagem Resv se propagar até o
emissor, o túnel está estabelecido.
Os túneis podem ser estabelecidos nó-a-nó
(hop-by-hop) entre os nós de entrada e saída do domínio MPLS ou explicitados a
partir de um nó, como podemos observar no exemplo abaixo[3]:
Figura 8:
Exemplo de roteamento explícito vago utilizando RSVP.
5. Aplicações do MPLS: Engenharia de Tráfego
A engenharia de tráfego é uma ferramenta poderosa para os operadores de rede, pois estes podem balancear a carga entre os vários links, roteadores e switches da rede, otimizando-os e maximizando os recursos da rede, e consequentemente, seus lucros.
Além disso, permite aos operadores evitar de criar rotas primárias por pontos conhecidos de engarrafamento e congestionamento da rede, prover controle preciso sobre a quantidade de tráfego rerouteada quando a rota primária sobre falhas, prover o uso eficiente do agregamento de fluxos, maximizar a eficiência operacional, reduzindo custos e tornando-se mais competitivo, e criação de novos serviços
Compreende planejamento da capacidade, controle de rotas, gerência de tráfego e de encaminhamento.
Entre as vantagens de se utilizar o MPLS para a engenharia de tráfego em backbones IP podemos destacar: uma topologia de rede menos complexa, uma vez que a engenharia de tráfego não está mais limitada à camada 2; interfaces óticas mais rápidas podem ser utilizadas, pela dissociação da engenharia de tráfego da camada 2; redução de custos operacionais e de manutenção pela utilização de apenas um plano de controle; e a habilidade de prover serviços adicionais.
A engenharia de tráfego utilizando MPLS é portanto um dos mais importantes tópicos de discussão atualmente. Esta discussão incluí a utilização do MPLS em conjunto (interoperabilidade/compatibilidade) com outros esforços de provisão de qualidade de serviço em redes IP, como o IntServ e o DiffServ, como veremos a seguir (baseado em conceitos fornecidos por documentos da Alcatel[4]).
A gerência de tráfego é um conjunto de funções para controlar
e priorizar como o tráfego é enfileirado, encaminhado e, sob situação de
congestionamento severo, descartado. É de seu encargo estabelecer os níveis
distintos de qualidade de serviço (QoS), bem como o uso eficiente da banda
disponível.
Para obter interoperabilidade e
compatibilidade, padrões de gerência de tráfego estão sendo criados para QoS em
redes IP. Como os esforços atuais do MPLS dentro do IETF se concentram em torno
do IP, seus padrões de gerência atualmente também se concentram sobre o IP. No
futuro, é de se esperar que o MPLS carregue payloads outros que o IP, e
portanto siga outros padrões.
Padões de QoS IP só recentemente se
tornaram firmes o suficiente para serem implementados. Dois conjuntos de
padrões existem, conhecidos como “Differentiated Services” (DiffServ) e
“Integrated Services” (IntServ). O IETF está juntando ambos os esforços dentro
de um grupo de IP QoS, a fim de garantir que eles se complementem e interoperem
de maneira transparente. Os trabalhos com gerência de tráfego MPLS começou com
suporte a DiffServ, como o objetivo inicial de garantir que os mecanismos de
QoS são compatíveis com a comutação por labels.
O modelo IntServ prove qualidade de
serviço fim-a-fim para as aplicações, desde garantias de taxa de fluxo a
limites de atraso fim-a-fim e perda de pacotes. Ele utiliza o protoclo RSVP
(Resource reSerVation Protocol) para garantir que os recursos requeridos
estejam disponíveis e reservados em todos os hops da rota escolhida. O IntServ
requer que todos os nós na rota mantenham o estado IntServ para cada fluxo de
tráfego, o que claramente limita sua escalabilidade e uso em backbones IP, mas
pode ser utilizado para pequenas redes corporativas. Um modo para utilização do
IntServ através de backbones é agregar fluxos IntServ em tráfego DiffServ na
borda da rede.
O IntServ tem padronizado dois tipos
de serviço:
Serviço Garantido (GS – Guaranteed Service), que
prove banda garantida e um limite de atraso de pacotes e nenhuma perda, cuja
alvo são aplicações sensíveis a atraso, como áudio e vídeo.
Serviço de Carga Controlada (CL – Controlled-load),
que prove as mesmas garantias de banda, mas sem garantias firmes para atraso e
perda de pacotes.
Diferentemente do IntServ, a gerência de tráfego no
DiffServ é realizada em agregados de tráfego ao invés de fluxos individuais de
aplicações. No ingresso do nó de entrada da rede, os fluxos de tráfego dos
clientes são classificados em agregados de comportamento (BA – Behavior
Aggregates) e os pacotes são rotulados com um codepoint DiffServ (DSCP) para
indicar a política de gerência de tráfego a ser executada pelos roteadores no
cerne da rede. Estas políticas são bem definidas e aplicadas uniformemente a
cada hop da rota, e são apropriadamente chamadas “per hop behavior” (PHB).
É importante notar que a gerência de tráfego é
realizada a cada nó da rede, baseada no comportamento do agregado. Esta é a
chave da escalabilidade do DiffServ, uma vez que cada pacote pertencente a um
BA carrega um rótulo com o DSCP apropriado, o nó DiffServ sabe exatamente como
tratá-lo, já que está configurado para saber tudo sobre os PHBs associados aos
DSCPs. Não há necessidade de se manter informações de estado no cerne da rede.
Três tipos de PHB estão definidos na padronização do
DiffServ: Assured Forwarding (AF), Expedited Forwarding (EF) e Best-Effort
(BE).
Pacotes marcados com EF irão receber um serviço de
encaminhamento qualitativamente superior ao tráfego Best-Effort. Isto é
alcançado garantindo que a taxa de saída para um agregado EF seja sempre igual
ou superior a sua taxa de entrada. Em qualquer nó, o tráfego EF vai encontrar
baixa latência, baixo atraso de jitter e baixa perda de pacotes, com mínima
alocação de banda.
O serviço tipo AF oferece diferentes níveis de
garantias para o agregado baseado na quantidade de recursos de encaminhamento,
espaço em buffer e configuração de banda para grupos PHB deste tipo. Um grupo
PHB tipo AF corresponde a três diferentes níveis de preferência de descarte
(baixo, médio e alto), sendo o nível baixo significando uma menor probabilidade
do pacote ser descartado em caso de congestionamento. Cada grupo PHB AF é
encaminhado independentemente, e existem DSCPs reservados para até quatro
grupos tipo AF em uma rede.
Embora o DiffServ forneça escalabilidade à rede, ele
o faz ignorando os requisitos de tráfego dos fluxos individuais das aplicações
em favor dos agregados de fluxos, o que torna difícil a integração transparente
do DiffServ com o IntServ, pois este necessita de mais do que garantia
qualitativa dos níveis de serviço. Por exemplo, uma aplicação pode demandar
garantia de banda.
Voltando ao protocolo MPLS, ele tem provisão para
gerência de fluxos agregados através dos três bits definidos no campo EXP
(experimental) em seu cabeçalho. Este campo pode ser utilizado de maneira
similar ao campo DiffServ do cabeçalho IP, tornando possível o mapeamento de
serviços DiffServ em MPLS, salvo algumas restrições devido a difereça de
tamanho dos campos. E em adição à gerência de fluxos agregados, os LSPs MPLS
podem ser gerenciados individualmente com políticas padrão de gerência de
tráfego.
Os comportamentos DiffServ podem ser mapeados para o
MPLS multiplicando-se o número de BAs DiffServ pelo número de classes
equivalentes de encaminhamento (FEC) para criar uma tabela de correlação
BA-FEC. Este mapeamento pode ser feito de três diferentes maneiras, como
descrito no internet draft (draft-ietf-mpls-diff-ext-07.txt, de agosto de
2000):
- E-LSP – EXP-inferred PHB scheduling class IP:
mapeie cada FEC a um LSP, mapeie DSCPs para todos os BAs (máximo de oito) nesta
FEC para os equivalentes valores EXP do MPLS, marque o campo EXP no cabeçalho
MPLS de acordo quando encapsulando os pacotes IP. Porém como o campo EXP pode
suportar apenas oito valores, este método não pode acomodar mais que oito DSCPs
(atualmente já estão definidos 14 DSCPs para o DiffServ). Otimizações
adicionais podem ser realizadas retirando a preferência de descarte do campo
EXP e mapeando-a a funções do cabeçalho da camada 2, reduzindo assim as DSCPs
que tem que ser mapeadas para apenas seis.
- L-LSP –
Label only-inferred PHB scheduling class LSP: crie um LSP para cada par BA-FEC.
Cada LSP teria um conjunto
de gerência de tráfego equivalente ao BA DiffServ que está carregando. Este
método leva o número de LSPs para um dado FEC ser multiplicado pelo número de
BAs. Contudo a mesma otimização descrita acima pode ser utilizada para reduzir
o número de LSPs a um terço.
- Um modelo híbrido E-LSP e L-LSP pode ser utilizado,
por exemplo implementantod L-LSP para EF e E-LSP para AF e BE.
Figura 9:
Mapeando DiffServ em MPLS.
Como os pacotes DiffServ devem ser processados como
agregados a cada nó, os pacotes MPLS que chegam aos nós não podem ser
encaminhados apenas pela análise do label. Os pacotes de todos os LSPs devem
passar pelo processamento PHB do DiffServ a cada nó, onde alguns pacotes podem
ser denotados para um PHB mais baixo e rerotulados de acordo. Embora
processamento extra seja necessário ao MPLS para suportar DiffServ, este modelo
ainda é escalável, já que não é necessário guardar informações de estado em
cada nó. E o processamento extra pode ser facilmente suprido com as tecnologias
de processadores e memória.
No que se refere a gerência de rotas no MPLS, um LSP
é um túnel análogo a um PVC ATM ou Frame Relay. O uso de mecanismos de gerência
de rotas é dependente do tipo de serviço oferecido pela rede bem como dos
requisitos de engenharia de tráfego e operacionais.
Existem muitas maneira de se criar rotas em uma rede
MPLS, as três mais comuns são:
- Generic LSP (G-LSP): caminho definido pela rede,
calculado através de mecanismos normais de roteamento (IGP), e sinalizado
através do LDP (Label Distribution Protocol).
- Explicit Route LSP (ER-LSP): caminho definido pelo
usuário, sinalizado através do CR-LDP (Constraint-Routed Label Distribution
Protoco) ou do RVSP estendido. Este processo pode ser automatizado através de
um sistema de gerência com uma interface gráfica com o usuário. Uma LSP deste
tipo sobrescreveria a tabela de roteamento criada pelo IGP em um LSR e
habilitaria a rota desejada pelo usuário.
- Constraint routed LSP (CR-LSP): um caminho definido
pela rede, calculado pelas extensões do protocolo IGP e sinalizado pelo RSVP ou
CR-LDP. Estas extensões do IGP provem um LSR com informações adicionais de
roteamento, como disponibilidade de banda de um nó para diferentes classes de
serviço, de modo a prover engenharia de tráfego.
Conclusões
O novo foco de negócios para provedores de serviços IP introduziu novos requisitos para um novo patamar de qualidade de serviço, incluindo performance, confiabilidade, e a habilidade de oferecer diferentes níveis de serviço (ouro, prata e bronze, por exemplo). Graças aos avanços tecnológicos, os provedores de serviço tem a oportunidade de ir além de simplesmente adicionar mais banda para tentar prover tal nível de qualidade. Devem aumentar a eficiência de suas redes e reduzir suas incertezas, reduzir a complexidade de controle e gerência de múltiplos planos de protocolos. O MPLS foi desenvolvido como uma resposta direta a estas necessidades, a fim de aumentar o controle, a eficiência e a confiabilidade – e consequentemente o lucro – das redes IP. A base para as redes de próxima geração é uma infraestrutura IP otimizada, capaz de suportar serviços legados, bem como um conjunto de novos serviços.
Com o crescimento das redes, os desafios são
escalonar as redes enquanto aumentam os requisitos de performance, controle e
custos. Em uma arquitetura IP over ATM existem as questões de custo de
deposição e operação de dois planos de protocolos, bem como a necessidade de
criação de VPs entre cada par de roteadores adjacentes, o que leva a problemas
de escalabilidade e estabilidade dos protocolos de roteamento a medida em que a
rede cresce.
Embora os requisitos de banda de uma
rede atualmente possam ser facilmente atendidos, o IP não pode atender os
requisitos de roteamento e engenharia de tráfego demandados pelos novos
serviços.
O MPLS representa a resposta a estes problemas apresentados, através da união de protocolos de roteamento e comutação em uma camada localizada entre o IP e a camada 2. De uma maneira simplificada, podemos afirmar que o MPLS define labels associados com propriedades de encaminhamento IP e os mecanismos de sinalização utilizados para defini-los.
Além das diversas
aplicações apresentadas, o MPLS tem um outro benefício: injetar novo ânimo no
mercado de produtos AMT. Adicionar suporte MPLS a uma estrutura ATM permite aos
operadores oferecer serviços IP sem os problemas de escalabilidade do IP over
ATM, e ainda continuar a oferecer
tráfego não-IP sobre os mesmos backbones.
O MPLS está invadindo ainda outros mercados, como a
comutação ótica, onde sua extensão o MPlamdaS ou GMPLS (Generalized MPLS)
fornece planos de controle para o mundo das switches óticas.
Mas o MPLS ainda está longe de ser perfeito. O IETF e
o MPLS Forum ainda tem muitas questões em aberto a discutir, como um processo
padrão para mapear o uso do DiffServ, que utiliza o campo tipo de serviço do
cabeçalho IP, em labels e sua interpretação pelos LSRs. Ou ainda formalizar um
padrão para a deposição de VPNs.
O MPLS não é a solução definitiva que dominará o mercado e suprirá todas as suas
necessidades. Nenhuma tecnologia é capaz de fazê-lo, por mais promissora que
pareça. De fato, novas técnicas de roteamento que já estão surgindo prometem
tornar o MPLS obsoleto.
Contudo, atualmente é uma solução que apresenta uma
ampla gama de benefícios aos operadores de rede. Uma solução elegante capaz de
maximizar seus recursos, reduzir seus custos, e consequentemente, maximizar sua
competitividade e seus lucros.
Bibliografia
Leituras básicas:
. Appying Label Switching
Technology in the Carrier Network. Unisphere Solutions.
. Multiprotocol Label Swithing
White Paper. Future Software Limited, India, 2001. www.futsoft.com
. The role of MPLS technology
in Next Generation Networks. Alcatel, outubro de 2000. www.cid.alcatel.com.
BELLMAN, Bob. MPLS: Panacea or
passing fancy? Bussiness Comminications Review, fevereiro de 2001.
FRASER, Sean. MPLS
Traffic Engineering. Unisphere Solutions, março de 2000.
PULLEY, Robert & CHRISTENSEN, Peter. A Comparison of MPLS Traffic
Engineering Initiatives. NetPlane Systems, 2000.
Leituras complementares:
. A Comparison of
MPLS Traffic-Engeneering Iniciatives. Harries & Jeffries. www.iec.org.
. Aggregated
Packet Flow in Label Switching Network.
. Building
Scalable Service Provider IP Networks. Marconi, julho de 2000.
. Switching
Services Configuration Guide. Cisco Systems, maio de 2001
. MPLS Controller Software Configuration Guide. Cisco Systems, maio de 2001.
. Delivering New World
Virtual Private Networks with MPLS. Cisco Systems,
2000.
. Deploying MPLS
for Traffic Engineering and Backbone VPNs.
Cisco Systems, abril de 2000.
. GMPLS - A major
component of future network. Siticom UK, 2000.
. Introduction to
MPLS and Traffic Engineering. Cisco Systems, 2001.
. Layer 3 Swithcing
Using MPLS. Netplane, 2000.
. Leveraging
MPLS to Enhance Network Transport Capabilities. Extreme Networks, 2001.
. MPLS - Making the
most of Ethernet in the Metro. Riverstone Networks, 2001.
. MPLS and the
Virtual Router Architecture. CoSine Communications, 2001.
. MPLS Archicteture.
MPLS Working Group, agosto de 1997.
. MPLS based
transparent LAN services. Riverstone Networks, 2000.
. MPLS for
Metropolitan Area Networks. Riverstone Networks, 2000.
JERRAM, Neil & FARREL, Neil. MPLS in Optical Networks.
Data Connection Limited, 2001.
. MPLS
Interoperability Testing Case Study. Agilent
Technologies, 2000.
. The Evolution
Toward Multi-Service IP-MPLS Networks. Integral
Access, 2000.
ABOUL-MAGD, Osama & JAMOUSSI, Bilel. QoS and Service
Interworking Using CR-LDP. IEEE Communications Magazine, maio de
2001, p. 134-39.
ASHWOOD-SMITH, Peter & JAMOUSSI, Bilel. MPLS Tutorial and
Operational Experience. Nortel Networks, outubro de 1999.
BANERJEE, Ayan, DRAKE, John, LANG, Jonathan, TURNER, Brad, KOMPELLA,
Kireeti, REKHTER, Yakov. GMPLS
- An Overview of Routing and Management Enhancements.
IEEE
Communications Magazine, janeiro de 2001, p.144-50.
BANERJEE, Ayan, DRAKE, John, LANG, Jonathan, TURNER, Brad, KOMPELLA,
Kireeti, REKHTER, Yakov. GMPLS
- An Overview of Signaling Enhancements and Recovery Techniques.
IEEE Communications Magazine, julho de 2001, p.144-51.
BRITTAIN, Paul & FARREL, Adrian. MPLS Traffic Engineering - A Choise of
Signaling Protocols. Data Connection Limited, 2000.
BRITTAIN, Paul & FARREL, Adrian. MPLS Virtual Private Networks. Data
Connection Limited, 2000.
DOYLE, Jeff. Resolving
Routes for MPLS Traffic Enginnering. Juniper
Networks, 2000.
HARRISON, Ed, FARREL, Adrian, MILLER, Ben. Protection and
Restoration in MPLS Networks. Data Connections Limited, outubro de
2001.
JAEGER, Rob. Transitioning
from IP-over-LANE-ATM to IP-MPLS Networks.
Juniper Networks, 2001.
IZZO, Paul. Traffic
Enginnering a QoS Enabled Path in a Packet Network.
Tenor Networks, 2000.
KOMPELLA, Kireeti, KOLON, Matt, BICHON, Pierre, DONNELL, Annette. MPLS-based Layer
2 Virtual Private Networks. Juniper Networks, 2001.
LASSERRE, Marc. Deploying
MPLS in MANs. Riverstone Networks, 2000.
PASSMORE, David. Clearing Up MPLS Confusion. Business
Communications Review, junho de 2000, p. 18-20.
RANGER, Jon. MPLS
and IPSec - A Misunderstood Relantionship.
Riverstone Networks, 2000.
REDFORD, Rob. Enabling
Business IP Services with Multiprotocol Label Switching.
Cisco Systems, 1999.
SEMERIA, Chuck. RSVP
Signaling Extensions for MPLS Traffic Engeneering.
Juniper Networks, 2000.
SEMERIA, Chuck. MPLS
- Enhancing Routing in the New Public Network.
Juniper
Networks, março de 1999.
SEMERIA, Chuck.. Traffic
Engineering for the New Public Network.
Juniper Networks, 2000.
WU, Tim. MPLS
VPNs - Layer 2 or layer 3? Understanting the choise.Riverstone
Networks, 2000.
Para mais informações, visite:
www.tesla.eletrica.ufpr.br/~wadeck