ESTUDOS SOBRE O MPLS

Capítulo 1: Fundamentos

1.1 Perspectiva Histórica

Vamos examinar os principais aspectos do MPLS que são relevantes nos dias
de hoje.

1 - Escalabilidade da camada de roteamento de rede: Usando “labels” para

agregar todas as informações de encaminhamento, enquanto trabalha na
presença de hierarquias de roteamento.
As L3 VPNs são um bom exemplo de agregação de informação de
encaminhamento, apenas os Routers Edge necessitam das informações de
roteamento, e o “Core MPLS” precisa apenas das informações de
encaminhamento.

2 - Ótima flexibilidade na entrega de serviços de roteamento: Usando

“labels” para identificar um tráfego em particular, recebidos de serviços
especiais (QoS), usando os labels para identificar esse tráfego ao longo de um
caminho específico.
MPLS tem a propriedade de identificar fluxos de tráfego em particular, que
devem receber um tratamento para serviços especiais, também chamado de
QoS. Isso nos traz propriedades de engenharia de tráfego que permitem todo o
encaminhamento por um caminho específico. Duas propriedades são
combinadas para isso. DiffServ e Aware Traffic Engineering, que veremos mais
pra frente.

3 - Aumento na performance da rede: Usando o paradigma da troca de

“labels” para otimizar a performance da rede.
Por conta dos roteadores modernos já exercerem a função de
encaminhamento de pacotes já em hardware, torna o encaminhamento de
pacotes IP e MPLS similar. Entretanto, otimizar a performance da rede implica
em um amplo conceito que simplifica a performance de nodes individuais.
Certamente o MPLS ajuda em um amplo conceito, usando a engenharia de
tráfego para evitar congestionamentos e usar o “fast reroute" para reduzir a
interrupção de tráfego quando um link cai.

4 - Simplifica a interação entre roteadores e switches: Faz com que haja um

“peering” entre roteadores e switches, torna disponível uma informação da
topologia física nos procedimentos de camada de rede. Na camada de
roteamento, emprega endereçamentos IP na rede, com roteamento e mantendo
procedimentos para a gerência da rede.

1.2 Tendências Atuais

No momento que estou escrevendo isso, a visão mais ampla em questão de

clientela em serviços de MPLS, é o L3VPN. Em algumas redes, o MPLS é
usado apenas para a engenharia de tráfego e capacidades de rápida
convergência.
Outra questão que vem em bastante crescimento, são as aplicações de
transporte ponto-a-ponto de camada 2, que transportam todo o tráfego ethernet
de clientes, ou como componentes de ATM e Frame Relay.
E por fim, o VPLS, onde o provedor pode fornecer uma impressão ao cliente
que seus sites estão localizados na mesma LAN, com alta disponibilidade.
Muitas operadoras estudam entregar muito mais serviços para os clientes
utilizando serviços baseados em MPLS, isso entrega menos custos de capital e
operacionais.
Este livro vai mostrar como os mecanismos do MPLS podem prover os
mecanismos necessários para a convergência da rede.

1.3 Mecanismos do MPLS

A principal propriedade do MPLS na rede é que pode ser usado para

“tunelar” múltiplos tipos de tráfego dentro do Core da rede.
Tunelamento é uma ferramenta poderosa, porque somente os roteadores de
“entrada” e “saída” devem entender o contexto do tráfego subjacente carregado
dentro desse túnel.
Esse detalhe é “escondido” dos roteadores de dentro do Core MPLS. Como
consequência, os dispositivos do core precisam suportar o protocolo e tê-lo
ativo para trocar pacotes MPLS encapsulados preservando seu conteúdo
subjacente. Ao lado dessas propriedades de agregação que são aplicadas nos
túneis em geral, os túneis MPLS têm que seguir propriedades particulares.
1. O tráfego precisa ser especificamente roteado, depende de qual protocolo
de sinalização vai ser usado.
2. Recursão para que possa existir túneis dentro de outro túneis.
3. Tem proteção contra “spoofing” de dados, já que o único lugar que pode
ser inserido dados dentro do túnel MPLS é no começo e no fim do túnel.
Em contraste, nos túneis IP, qualquer dispositivo pode injetar dados no túnel
desde que tenha conectividade com o dispositivo que “carregue” o túnel.
4. O encapsulamento do cabeçalho é relativamente baixo, cerca de 4 bytes
por cabeçalho MPLS.
Uma rede MPLS consiste em dispositivos Edge conhecidos como “Label
Edge Routers” (LERs) ou “Provider Edge” (PE) routers, já os roteadores do
Core MPLS são conhecidos como “Label Switching Routers” (LSRs) ou
Provider (P) routers. Uma malha de túneis unidirecionais, conhecidos como
“Label Switched Paths” é feita entre os LERs na ordem que o pacote entra na
rede, ao entrar na rede, ele será transportado até seu LER de saída apropriado.
Quando o pacote entra na rede, o roteador de entrada determina o FEC
(Forwarding Equivalence Class) o qual o pacote equivale. Pacotes que têm o
mesmo ponto de saída como destino, e usam o mesmo caminho e o mesmo
tratamento de tráfego, são equivalentes ao mesmo FEC e percorrem o mesmo
LSP.
Em um exemplo simples, pacotes cujo destino seja o mesmo endereço de IP e
tem o mesmo next-hop BGP são considerados pelo roteador de entrada que
utilizarão o mesmo LSP, classificados pelo FEC.
Essa função do LER de entrada determina o LER de saída e a LSP associada
até o LER de saída associado ao FEC determinado.
MPLS tem a propriedade de “multiplexar” diversos tipos de tráfego em um
único LSP. Entretanto, se for do desejo do Analista de Rede, um LSP pode ser
usado para transportar todo o tráfego entre uma entrada e saída em particular.
Roteadores de trânsito ao longo do caminho podem tomar decisões de
encaminhamento com base num formato fixo do cabeçalho MPLS, e por isso
não é necessário guardar as “rotas” relativas ao tráfego subjacente do túnel. Isso
é uma importante propriedade de escalabilidade, por outro lado cada um dos
roteadores de Core tem de carregar as informações de roteamento equivalentes à
um resumo da informação de roteamento por todos os “routers edge” na rede.
 1.3.1 Mecanismos do Plano de Encaminhamento

Todos os dados transportados em uma rede MPLS tem um ou mais

cabeçalhos MPLS aplicados em ordem no transporte através da rede.
A estrutura de um cabeçalho MPLS é mostrada abaixo.

Label TC S TTL

1. Um valor de label de 20bits. Pacotes MPLS são encaminhados com base

nesse campo, esse valor é usado como indicador na MPLS forwarding table.
2. Traffic Class (TC) Field (3bits). Anteriormente conhecidos como EXP
bits, por que por muitos anos foram denominados bits experimentais. Comunica
a Class of Service aplicada ao pacote. Por exemplo, LSRs e LERs usam esse
campo para determinar se um tráfego deve se encaixar em um queue de QoS
específica.
3. Stack-bit inferior. (S-bit). Descrito anteriormente neste capítulo,
cabeçalhos MPLS podem ser empilhados. o S-bit é identificado no cabeçalho do
pacote MPLS como o inferior da pilha.
4. Time-to-live. Usado para evitar loops de encaminhamento e também pode
ser usado para traçar o caminho. Esse valor é decrementado em cada salto e o
pacote é descartado se o valor chegar em 0.

Pacotes chegam na rede com um ou mais cabeçalhos MPLS aplicados pelo

LER de entrada. O LER de entrada identifica qual será o LER de saída que o
pacote deverá ser encaminhado e qual a LSP correspondente ao destino. O valor
de label é correspondente ao LSP onde foi atribuído o pacote. O próximo
roteador faz uma análise desse label e determina o label de saída que vai ser
usado para o próximo passo dessa LSP. Essa análise no LSR envolve ler o label
de entrada, isso resulta em um novo valor de label que vai ser usado e em qual
interface de saída ele vai ser encaminhado.
Dessa forma, ocorre o processo de troca de label ou label-swapping, o pacote
é transmitido dessa forma ao longo da LSP desde o roteador de entrada até a
saída.

Em casos simples, o uso de um único label MPLS é suficiente, como por

exemplo, quando é transportado tráfego de IP público ao longo da rede. Nesse
caso, uma vez que o pacote chega ao LER de saída, esse LER executa uma
análise de pacote IP normal, e determina qual link de saída vai ser usado.
Normalmente um processo chamado de PHP (Penultimate Hop POPping) é
usado, nesse processo, após o LER de saída (O penúltimo roteador ao longo da
LSP), “abre” o label MPLS e encaminha ao node de saída como um pacote IP.
Isso simplifica o processo necessário ao node de saída, que por outro lado, seria
necessário abrir o label, analisar ele como pacote IP e encaminhar ele como
pacote IP. Isso não é uma obrigatoriedade, ter o LER para executar o PHP, mas
é o padrão de muitas implementações.
Em outros casos, um único cabeçalho MPLS é insuficiente. Isso porque os
LERs em algumas redes em particular, podem estar envolvidos em múltiplos
serviços. - Como L3VPN, L2VPN, VPLS - em vez de apenas um IP público.
Nesse caso, o LER precisa saber qual o serviço e qual instância desse serviço
(ou cliente) o pacote terá. Isso é realizado por um cabeçalho MPLS adicional
que é aplicado pelo LER de entrada, correspondente ao serviço e instância
usada pelo serviço que o pacote deve ter para ser encaminhado ao LER de saída
específico. Isso pode ser mostrado na figura abaixo.

Vamos verificar como um pacote com dois cabeçalhos é transportado entre

LERs de entrada e saída. O cabeçalho interior com label Y identifica o serviço e
a instância de serviço, e o cabeçalho exterior, também chamado como
“cabeçalho de transporte”, este é necessário para transportar o pacote do LER
de entrada, PE1, para o LER de saída correto, PE2. Por exemplo, um LER em
particular pode estar rodando serviços importantes de L2VPN, L3VPN e VPLS.
A capacidade de empilhar cabeçalhos, faz com que o MPLS tenha propriedade
para multiplexar e hierarquizar serviços. Permitindo que um único LSP consiga
carregar todo o tráfego entre dois pontos.
 A figura acima mostra que o pacote deixa o LER de entrada, PE1, com um
label interno Y e o label externo X. Os roteadores P1 e P2 realizam uma análise
baseada no label externo e não precisam ler ou tomar qualquer outra ação
baseada no label interno. P1 faz a troca do label X para o label W. Se o PHP
estiver em uso, que normalmente é o caso, o roteador P2 vai abrir o cabeçalho
externo e encaminha o que resta do pacote para o PE2. E então, o pacote vai
chegar até o PE2, o label “mais externo” (e único) e originalmente label interno,
Y, que vai ser usado pelo PE2 para identificar o pacote usado nos serviços de
L3VPN da Companhia A.
Como o LER de saída sabe qual o valor de label usado? O label de transporte
é aprendido através de qualquer protocolo de sinalização, sendo ele RSVP ou
LDP. Que serão descritos com mais detalhes depois neste capítulo. O label
interno na maioria dos casos é aprendido via BGP ( L3VPN, Sinalização-BGP e
L2VPNs). Entretanto, há alguns casos onde o LDP é utilizado (Sinalização-LDP
em transportes de circuitos L2).

1.3.1.1 Suporte MPLS e DiffServ

DiffServ foi desenvolvido como uma solução para prover Quality-of-Service

(QoS). Isso faz com que o tráfego seja dividido em pequenos números de
classes e alocando recursos de rede baseado em classe. Para evitar a necessidade
de um protocolo de sinalização. A classe é marcada diretamente com o
cabeçalho do pacote. A solução DiffServ visava as redes IP então marcando os
o cabeçalho IP com os “6-bit DiffServ Code Point”. O DSCP determina a QoS
tratada por um pacote em um host em particular na rede. Isso é chamado de
PHB (per-hop behavior) é expressado em termos de reserva e preferência de
drop de pacotes. De um ponto de vista de implementação, o PHB informa qual a
queue vai ser utilizada para o encaminhamento, a probabilidade de drop se
exceder o limite da queue, e os recursos reservados para cada queue e a
frequência com que são usadas.
O primeiro desafio em suportar o DiffServ em uma rede MPLS é que os
LSRs tomarão decisões de encaminhamento baseados em um cabeçalho MPLS
sozinho, e então o PHB vai ser deduzido nisso. A IETF resolveu esse problema
atribuindo o EXP (three experimental bits) no cabeçalho MPLS para carregar as
informações de DiffServ.
Essa solução resolve o problema inicial de carregar o PHB desejado no
cabeçalho MPLS. Enquanto introduz outro problema: como mapear valores
DSCP expressos em um campo de 6 bits que pode codificar até 64 valores em
um campo EXP de 3 bits que pode transportar no máximo oito valores
distintos? Aqui temos duas soluções para este problema, discutidas
separadamente abaixo.
A primeira solução é aplicada em redes que podem suportar menos que 8
PHBs.
Aqui, o mapeamento é mais “sincero”: um DSCP em particular é equivalente
à combinação de bits EXP, e a um PHB em particular. Durante o
encaminhamento, o label determina onde encaminhar o pacote e o campo EXP
determina o PHB. Os bits EXP não são propriedades sinalizadas quando é
estabelecido um LSP. O mapeamento de PHB é configurado em cada node da
rede. Os bits EXP podem ser setados de acordo aos bits DSCP dos pacotes IP
carregados no LSP, ou eles podem ser setados pelo operador de rede. LSPs para
cada PHB são chamadas de E-LSPs (Onde o E seria para EXP inserido). E-
LSPs podem carregar pacotes com até 8 PHBs em um único LSP.
A segunda solução é aplicada em redes que podem suportar mais de 8 PHBs.
Aqui, os bits EXP sozinhos carregam toda a informação necessária para serem
distinguidos entre os PHBs. O único campo no cabeçalho MPLS que pode ser
usado para esse propósito é o label por si só. Durante o encaminhamento, o
label determina onde vai ser encaminhado e qual o comportamento de reserva
vai ser concedido à ele, e os bits EXP carregam a informação de prioridade de
drop atribuída ao pacote. Então, o PHB é determinado por ambos, pelo label e
pelos bits EXP. Por conta do vínculo implícito do label com o PHB, a
informação precisa ser carregada quando o LSP é sinalizado. LSPs que podem
usar o label para carregar essa informação são chamados de L-LSPs (onde o L
significa “label-inserido”). L-LSPs podem carregar pacotes de um único PHB
ou de PHBs que seguem o mesmo regime de reserva mas com regras de drop
diferentes.
A tabela abaixo resume as diferenças entre E-LSP e L-LSP.

E-LSP L-LSP

PHB é definida pelos bits EXP PHB é determinada pelo label ou

pelos bits EXP e label juntos.
Podem carregar com até 8 PHB
definidas em um único LSP Podem carregar um único PHB em
um LSP, ou PHB com o mesmo
Uso conservativo de labels e os regime de reserva mas com
mantém estáveis, já que os labels são prioridades de drop diferentes
usados apenas para carregar as
informações de caminho Usa mais labels e se mantém mais
estável, já que os labels carregam
Não precisa de sinalização para informação do caminho e da reserva.
carregar as informações de PHB
O PHB precisa ser sinalizado
Até 8 PHB são suportadas na rede quando a LSP é estabelecida.
quando somente E-LSP são usadas, E-
LSP podem ser usadas em conjunto Qualquer número de PHB é
com L-LSP se necessário mais PHB. suportado na rede.

1.3.2 Mecanismos do plano de controle

Até então vimos como o MPLS usa os labels para o encaminhamento, mas
como acontece os vínculos entre os labels e FECs ao longo da rede?
Antigamente a configuração manual não era uma opção, claramente era
necessário para que o protocolo disseminasse a informação. De um ponto de
vista prático, haviam duas opções: a) inventar um novo protocolo que
distribuísse os vínculos de labels. b) estender um protocolo existente para
carregar os labels e em adição ter informações de roteamento. A questão de se
inventar um protocolo novo, ou estender protocolos POPulares no mundo
MPLS, vamos discutir em detalhes nos próximos capítulos. Neste ponto, é
suficiente dizer que as questões foram resolvidas, e ambas opções foram
seguidas.
 Levando em consideração a distribuição de vínculos de labels, a comunidade
de engenharia inventou um novo protocolo (LDP, Label Distribution Protocol) e
estendeu dois protocolos existentes (RSVP, Resource Reservation Protocol, e o
BGP, Border Gateway Protocol). O formato do pacote e a base de operação
desses protocolos é explicada em vários textos introdutórios. E será replicada
aqui, vamos examinar as propriedades dos diferentes protocolos, e ver seus
benefícios e limitações de cada um deles.

1.3.2.1 LDP

LDP é resultado do MPLS Working Group. Diferente do RSVP e BGP, que

funcionavam bem antes do MPLS, e foram estendidos para realizar a
distribuição de labels, LDP foi especificamente designado para distribuir os
labels na rede. Desde o começo a função do LDP é distribuir labels, LDP não
performa nenhuma função de roteamento e confia no IGP para todas as decisões
de roteamento. As especificações originais do LDP foram definidas em
configurar LSPs para os FECs representados em IPv4 ou IPv6. Essa é a
funcionalidade descrita nessa seção. As extensões do LDP usadas por
pseudowires e sinalização VPLS serão discutidas em seus capítulos apropriados.
LDP foi designado com a extensibilidade em mente. Toda informação
trocada pelo LDP é decodificada como TLVs (type-length-value triplets). O tipo
e o valor são o começo da decodificação, e seu comprimento é definido depois.
O tipo identifica qual a informação que é trocada e determina como o resto da
decodificação será entendido. O valor é a informação atual trocada, e o
comprimento, é o comprimento do campo de valor. TLVs fazem com que seja
fácil para: a) adicionar novas funcionalidades por adicionar novos tipos b)
passar objetos desconhecidos, ignorando o tanto de dados especificados no
campo de comprimento. Ao longo dos anos, muitas novas funcionalidades
foram adicionadas ao protocolo graças à sua construção escalável.
A Operação de LDP é dirigida por mensagens trocadas entre os peers.
Potencialmente peers, também conhecidos como neighbors, que são diretamente
conectados um com o outro, seja ponto a ponto ou em uma interface LAN, são
automaticamente descobertos por mensagens hello multicast identificando
portas UDP. O protocolo também permite a descoberta de neighbors usando
mensagens de hello setadas. Nesse caso, mensagens hello unicast UDP são
encaminhadas ao endereço remoto do neighbor em pode passar por vários saltos
até chegar ao peer. Desta forma, um peer em potencial é descoberto, uma
conexão TCP é estabelecida e uma sessão LDP sobe. Se um par de peers é
conectado por mais de uma interface, apenas uma sessão LDP é estabelecida
entre os dois. No tempo de inicialização da sessão, os peers trocam informação
a respeito de suas funcionalidades e modos de operação que suportam. Depois
que a sessão sobe, os peers trocam informações a respeito de vínculos de labels
aos FECs sobre a conexão TCP. O uso do TCP garante a confiabilidade da
entrega da informação e permite incrementar atualizações periódicas. LDP usa o
recebimento regular de mensagens do protocolo para garantir a “saúde” da
sessão. Na ausência de atualização para serem trocadas entre os dois peers, são
encaminhadas mensagens de keep alive.
A associação entre um FEC e um label é anunciada via mensagens de label:
mensagens de label-mapping para anunciar novos labels, mensagens label with-
draw que são para remover labels, etc. Uma regra fundamental para os estados
do LDP, como: LSR A recebe uma mensagem de mapeamento com o label L
para o FEC F, de seu peer LDP LSR B, ele vai usar o label L para encaminhar
somente se o LSR B for o destino mais perto no FEC F, no ponto de vista do
LSR A. Isso indica que os LSP subirão via LDP sempre seguindo o caminho
LDP, o LDP usa o IGP para evitar loops.

Relacionamento entre LDP e o IGP

O fato do LDP confiar no IGP para a função de roteamento, traz várias

implicações.

1. O LDP estabelece LSPs sempre seguindo o caminho preferido pelo IGP.

O caminho LSP muda na rede apenas quando há mudança no IGP, em vez de
quando cair, ir para um caminho predefinido.
2. O escopo do estabelecimento de LSPs é limitado ao escopo do IGP.
Então, LSPs LDP não podem atravessar limites de ASs. Ele precisa de LSPs
Inter-ASs, isso foi uma solução proposta pela IETF para estabelecer as LSPs, é
explicado em capítulos posteriores.
3. Durante a convergência, o tráfego pode ser descartado (blackholed) ou
loopar. A existência de loops e a possibilidade de perda de tráfego é um fato da
vida dos IGPs durante a convergência. As mesmas propriedades são adotadas
pelo LDP, por virtude da confiança nos IGPs para as decisões de roteamento.
Discutiremos como loops surgem em capítulos posteriores.
 4. Em mais implantações recentes, a convergência IGP tem um tempo
menor que a convergência LDP. Assumindo que o IGP implementou uma
convergência rápida e inteligente o tráfego perdido pode ser de alguns
milissegundos, pelo menos, um pouco mais que o tempo de convergência com
RSVP. Entretanto, enquanto escrevo este livro, foram adicionadas recentemente
funcionalidades de convergência para o LDP. Que serão discutidas em capítulos
posteriores.
5. A perda da sincronização do LDP com o IGP pode causar a perda de
tráfego. Como sempre, para situações onde dois protocolos operam em
conjunto, podem haver condições potenciais de corrida.

Vamos ter uma visão mais breve focando na condição de corrida causada pela
perda da sincronização entre o LDP e o IGP. Nessa topologia de losango
mostrada na figura 1.4, LSR A está anunciando um vínculo para a sua
Loopback, o FEC A. Para começarmos, todos os links tem o mesmo custo, e o
link C-D não existe na topologia. Do ponto de vista do D, o LSP para o FEC A
segue o caminho D-B-A. Após um tempo o caminho C-D foi adicionado à
topologia com um custo melhor que o link B-D, fazendo com que do ponto de
vista do D, o algoritmo SPF mude o caminho para o FEC A para o link D-C-A.
Considerando que o IGP reaja mais rápido que o LDP. Em breve o D vai saber
sobre a mudança de roteamento, e ele para de usar o vínculo recebido do B,
causando uma quebra no LSP. O LSP ficará down, até que seja recebido um
novo vínculo para o FEC A via LDP pelo C. Isso pode demorar um pouco,
dependendo o quão rápido será o estabelecimento de sessão. Essa situação
descrita aqui é particularmente indesejada, desde que um caminho alternativo
exista na topologia e poderia ser usado para que a sessão LDP ficasse up no link
C-D.
O exemplo acima mostra uma perda de sincronização causada pelo fato da
sessão LDP ser estabelecida depois de uma sessão IGP quando um link sobe.
Essa não é a única maneira em que uma perda de sincronização pode ocorrer:
Esquecendo de habilitar o LDP em uma interface, não configurar uma
autenticação que é necessária, tendo filtros de firewall que bloqueia o tráfego
LDP, ou qualquer outro evento que possa fazer com que o IGP use um link e o
LDP não use, causa o mesmo efeito.
Uma solução para esse problema é amarrar (através de configuração) o custo
do IGP de um link em particular à existência de uma sessão LDP no link [RFC
5443]. Quando a sessão LDP cair, o custo do IGP anunciado para o caminho
ficará mais alto. Entretanto, se um caminho alternativo estiver disponível, os
labels LDP naquele caminho serão usados. Isso é discutido com mais detalhes
no capítulo 13 - Gerenciamento MPLS.
Agora, vamos supor que o link entre o C e D esteja operacional mas ele sofre
um flap. Isso quer dizer que ele caiu e voltou após alguns segundos. Apesar que
a técnica descrita na [RFC 5443] previna blackholing de tráfego enquanto a
sessão entre C e D seja restabelecida e as labels sejam trocadas, o tráfego pode
seguir um caminho fora do ideal durante esse tempo. Uma técnica adicional
chamada de “LDP Session Protection” é suportada por algumas implementações
LDP para evitar esse problema. Isso acontece da seguinte forma. Enquanto o
link entre C e D está up, eles trocam regularmente mensagens de hello no
caminho normal. Quando LDP Session Protection está em uso, em adição, Ce D
também trocam hellos “targeted”. Apesar de serem trocadas dois tipos de
mensagens hello, apenas uma sessão é mantida.
Se o link entre C e D cair, os hellos trocados regularmente não serão
propagados, mas contanto que haja conexão IP entre C e D (via A e B no
exemplo), os hellos targeted vão continuar sendo encaminhados entre C e D, e
então a sessão LDP permanecerá up. Isso faz com que o quando o link entre C e
D seja restabelecido, a sessão LDP não precisa ser restabelecida ou ter troca de
vínculos de label. Uma vez que as mensagens de hello do LDP sejam trocadas
sob o link, o link pode ser usado para o encaminhamento mais uma vez. Até
aqui nós vimos as implicações de que o LDP tem de confiar no IGP para as
funções de roteamento. Agora, vamos ver a escolha de distribuição de labels e
os modos de retenção feitos por implementações LDP comuns.

Modos de distribuição e retenção de labels

Modo de retenção de label - Como os labels são mantidos? As

especificações LDP permitem o uso de ambos modos de retenção liberal e
conservador.
A retenção conservadora significa manter apenas esses labels que são usados
para o encaminhamento e descartar o restante. Essa política faz sentido para
dispositivos onde o espaço de labels é um recurso precioso, que deve ser
gerenciado com atenção. Isso salva o uso de labels assim como o custo. Uma
vez que as labels “não interessantes” são descartadas, elas devem ser solicitadas
novamente se elas se tornarem “interessantes” mais tarde, devido alguma
mudança no roteamento. Até que a solicitação de label chegue, o tráfego é
perdido. Essa propriedade indesejável, combinada com o fato de que o espaço
de label não é mais preocupante em roteadores modernos, faz com que a
maioria das implementações hoje usem o modo de retenção liberal.
Modo de distribuição de label - Quem atribui labels? A função chave do
LDP é distribuir vínculos de labels com FECs. A meta é construir uma tabela de
encaminhamento contendo um mapeamento entre os labels de entrada e saída. O
tráfego que chega a um LSR vem “etiquetado” com um label de entrada, e
encaminhado com um label de saída. Quando uma tabela de encaminhamento é
construída, a questão é se será usado o label que foi escolhido localmente na
entrada ou saída. A arquitetura MPLS [RFC 3031] usa o vínculo de labels
downstream, que significa que o roteador espera receber o tráfego com o label
que foi escolhido localmente. Por exemplo, se o LSR A recebe label L1 para o
FEC F, e anuncia label L2 para isso, ele espera que o tráfego destinado ao FEC
F venha etiquetado com o label L2. Quando encaminhando o tráfego para o
FEC F, o LSR A etiqueta o tráfego com o label L1. O tráfego flui para a direção
oposta da distribuição de labels. O método é chamado de “downstream” porque
o label, que é vinculado ao tráfego até o ponto P na rede, foi atualmente
escolhido pelo roteador que está um salto à frente na direção do fluxo de tráfego
(downstream) para o P.
 A próxima questão é: As labels devem ser anunciadas apenas à quem solicita
(on-demand label distribution) ou para todos(unsolicited label distribution)?
Nós já vimos distribuições sob-demanda que tem a indesejável propriedade de
perder o tráfego até que seja solicitado o label. Por essa razão, a maioria das
implementações usam o modo de distribuição de labels não solicitados. Como o
LDP usa a alocação de labels downstream, o modo de distribuição de labels
também é chamado de downstream unsolicited.
Retenção liberal, combinado com os anúncios de label não solicitados,
garante que os labels recebidos dos peers fiquem prontamente disponíveis. Isso
é importante para manusear as mudanças de roteamento de um modo perfeito.
Para melhor entender isso, vamos olhar para o LSR A, o qual recebe dois labels
não solicitados para o FEC F, um label L1 do peer B e um label L2 do peer C.
LSR A mantém ambos labels, desde que seja feita a retenção liberal. Assumindo
que a rota do IGP para o FEC F prefira o peer B, LSR A instala o label L1 na
tabela de encaminhamento. Se em algum ponto posteriormente a rota IGP
mudar, e o ponto preferido for o peer C, tudo que o LSR A fará é mudar a tabela
de encaminhamento e vai passar a usar o label L2.

Controle sobre o estabelecimento de LSP

O único propósito da distribuição de vínculos entre labels e FECs é

estabelecer label-switched paths (LSPs) na rede. Até aqui discutimos várias
propriedades interessantes do LDP, mas não temos nenhuma resposta para duas
perguntas: (a) qual FEC que será vinculado e (b) quando é anunciado esse
vínculo.
A escolha dos FECs é derivada de LSPs que devem ser estabelecidas na rede.
Isso é independente do protocolo LDP e portanto as especificações LDP são
silenciadas nesse quesito. Todas vendors permitem o controle sobre a escolha
dos FECs através da configuração, mas o comportamento na ausência de
configurações definidas pelo usuário é diferente para diferentes vendors. Alguns
anunciam o vínculo para todo prefixo contido na tabela de roteamento, já outros
apenas anunciam um vínculo para o FEC correspondente ao endereço de
loopback do LSR. O resultado em termos de números de LSP que são
estabelecidas e dos destinos alcançáveis via essas LSPs é bastante diferente.
Não tem uma decisão certa e errada aqui, são implementações diferentes que
têm diferentes contrastes. Contudo, de um ponto de vista de operação da rede
(NOC), é uma má ideia
 permitir que o LDP anuncie vínculos para FECs que não serão usados para o
encaminhamento. Os vínculos extra e informações de LSP usam recursos na
rede e tornam o troubleshooting extremamente difícil.
A escolha do FEC determina qual LSP será estabelecido. A decisão quando
anunciar um vínculo de label determina quem terá controle sobre quando o LSP
será estabelecido. As especificações LDP permitem dois modos de operação:
controle ordenado e controle independente. Já que nem todos os vendors
implementaram o mesmo modo, vamos olhar as duas opções e suas
propriedades em referência a figura 1.5. Para o propósito da discussão, vamos
assumir que a if5 não existe, esse link será usado para discussões posteriores
nessa sessão.

Controle ordenado: Sob o controle ordenado, LSR de entrada, o PE1 inicia

o estabelecimento de um LSP vinculando o label L1 ao FEC correspondente ao
seu endereço de loopback e anuncia esse mapeamento para o seu peer A. Após
o recebimento do mapeamento de label, A avalia se PE1 é no IGP o caminho
mais curto para o FEC. Após a checagem ser feita, A atribui o label L2 para o
FEC PE1, instala o estado de swapping no encaminhamento, de L1 para L2, e
anuncia o vínculo do L2 para o FEC PE1 para o seu peer B, o qual fará um
processo similar, se a checagem não for bem sucedida, ele não faria o anúncio
do FEC para ninguém mais. Nesse modelo, o LSP será estabelecido em ordem
de entrada até a saída. Cada LSR consulta o IGP para duas decisões: (a) se vai
anunciar um mapeamento para o FEC e (b) se vai usar o label para o
encaminhamento.
Controle independente: Com o controle independente, cada LSR atribui um
label para o FEC PE1 e anuncia esse vínculo independente dos peers. Cada LSR
usa um label localmente atribuído como label de entrada na tabela de
encaminhamento. O label de saída na tabela de encaminhamento é preenchido
quando o LSR recebe o label para o FEC PE1 de um peer que tem o menor
caminho no IGP para o PE1. Os LSRs usam o IGP para apenas uma decisão: Se
o label será usado para o encaminhamento ou não. O sucesso do
estabelecimento do LSP depende de todos os LSR anunciando labels para os
mesmos FECs. Por exemplo, se o LSR A estiver configurado para não anunciar
um label para o FEC PE1, o LSP para o PE1 nunca será estabelecido.
Até esse ponto, é provável que tenha ficado claro o comportamento padrão
para a escolha de FECs que serão anunciados, que discutimos anteriormente
nesta seção, não é arbitrário.
Com o controle ordenado, o roteador que será de entrada do LSP, decide qual
o FEC para iniciar os LSPs. Portanto, um comportamento padrão racional para
uma implementação realizando controle ordenado é anunciar o mapeamento
para os endereços de loopback das saídas. Com o controle independente, todos
os roteadores da rede devem anunciar o mesmo conjunto de FECs. Então, uma
coisa mais racional a se fazer para realizar uma implementação de controle
independente, é anunciar um mapeamento para todos os prefixos na tabela de
roteamento. Outro ponto para se notar, é que quando houver uma mudança no
comportamento padrão com uma configuração, com um controle ordenado a
mudança é aplicada em um roteador apenas, na saída, agora com um controle
independente, a mudança deve ser uniformemente aplicada por toda a rede. O
requisito para aplicar a mudança de forma uniforme, é devido à operação
independente dos roteadores na rede: a não ser que eles concordem em anunciar
no mesmo FEC, LSPs não serão estabelecidas fim-a-fim ao longo da rede,
causando perda de tráfego. Essa situação acontece pelo fato de que o protocolo
não tem uma detecção de configurações incompatíveis.
Os diferentes comportamentos dos controles com relação à propagação de
labels têm importantes implicações em relação ao estabelecimento de LSPs.
Com o controle ordenado, os vínculos devem ser propagados da saída para a
entrada depois do LSP ser estabelecido, e o tráfego ser encaminhado por ele. Se
em uma aplicação (como uma L3 VPN) confia-se na existência de uma LSP, ela
não poderia encaminhar o tráfego até que acontecesse toda a propagação e
algum tráfego passasse por essa LSP. Esse comportamento não é limitado
somente à configuração inicial das LSPs. As mesmas dinâmicas são aplicadas à
mudança de roteamento. Com o controle ordenado dos labels deve ser
propagado para os roteadores no novo caminho IGP, enquanto com o controle
independente os labels já estão disponíveis nestes roteadores. Isso, entretanto,
não é ruim, se tivermos a visão que: quando tem mudanças de roteamento, as
mensagens IGP devem ser propagadas e novas rotas computadas, então a
propagação dos labels LDP não é pior que a propagação de mensagens IGP.
Um cenário mais interessante é um caso de falha onde o LDP não consegue
seguir o IGP. Vamos voltar ao exemplo da figura 1.5.

Assumindo que a interface if5 não exista nessa rede.

O LSP para o FEC PE1 (a loopback do PE1) é estabelecido ao longo dos
roteadores PE2-C-B-A-PE1. Até que, o analista decide adicionar uma interface
if5 e inclui ela no IGP, mas esquece de habilitar o LDP nela. Como resultado, o
IGP tem como melhor caminho o FEC PE1 sendo C-A-PE1.
Com o controle ordenado, LSR C notifica que o anúncio de label que foi
recebido para o FEC PE1 do LSR B não combina com o melhor caminho do
IGP, retira esse anúncio para o FEC PE1 e remove ele do estado de
encaminhamento. Quando o LSR PE2 recebe a remoção, ele remove o FEC PE1
do estado de encaminhamento. PE2 sabe que o LSP não está operacional e não
vai encaminhar tráfego por ele. Com protocolo independente, LSR C notifica
que houve uma mudança no roteamento e que o label de saída para o FEC PE1
já não é mais válido e remove ele do estado de encaminhamento. PE2 não tem
mudança no estado de encaminhamento, já que do seu ponto de vista o melhor
caminho para o PE1 permanece sendo o C. O efeito é que o LSP para o PE1 foi
quebrado no C, mas o PE2 inconsciente da falha. Ele continua sendo
encaminhado ao tráfego através dessa LSP e o tráfego é dropado pelo C. Esse
tipo de falha silenciosa é muito problemática para ambientes de VPN, que nós
veremos posteriormente. A solução para essa questão é o esquema descrito na
[RFC 5443], em que o custo do link no IGP fica alto quando o LDP não está
operacional por ali. Como descrito anteriormente, esse esquema é também uma
solução para as condições de corrida entre o LDP e IGP.
Implementações que suportam cada um dos dois modos de operação podem
ter e usá-los juntos na mesma rede [RFC 5037]. A chave para
ininterruptibilidade é o fato dos LSRs não assumirem nada em relação ao
comportamento dos seus peers, exceto na instalação consistente dos estados de
encaminhamento seguindo o IGP.

Agora temos que discutir a maneira que os labels LDP são distribuídos,
vamos olhar o exemplo de um LSP LDP.
A figura 1.6 mostra um LSP LDP, que tem seu ponto de saída sendo o
roteador D. O LDP forma uma estrutura ponto-multiponto enraizada no D, com
cada um dos roteadores de entrada. Da mesma forma, LDP forma estruturas
ponto-multiponto enraizadas em cada um dos roteadores na rede, mas isso não
está sendo mostrado no diagrama para clareza.
 Os números dentro das caixas mostram os custos do IGP em cada link. As
flechas mostram a direção do fluxo de dados, e o número ao lado da flecha
mostra o label LDP usado no link para o LSP até o D. Podemos ver que cada
caminho LSP segue a melhor rota determinada pelo IGP. Em um link em
particular, o label usado para chegar no roteador de destino em particular é o
mesmo, sem considerar a origem do pacote. Então, por exemplo, no link F-C
todos os pacotes com destino ao D, tem o label de valor 27, sem considerar que
eles sejam originados do G ou A ou F. Também, se o espaço total de labels de
uma plataforma estiver quase sendo usado, o roteador C (por exemplo) anuncia
o mesmo label a caminho do D para todos os seus neighbors, então todo tráfego
que passe via C para chegar ao D terá o mesmo label em todos os links do C.
Por isso, o tráfego do B para o D terá o valor de 27 no link B-C. Note que, no
exemplo, D anuncia o valor de label 3 para os seus neighbors. Esse valor de
label é especial, chamado de Implicit Null label [RFC 3032]. Isso engatilha o
PHP nos nodes C e D. Por conta do significado especial do label 3, um pacote
de dados MPLS nunca vai poder ter o valor 3 em seu label. Como já
apresentado, o diagrama mostra apenas a estrutura enraizada ao D. Na realidade
temos várias estruturas na rede que sobrepõe outras, cada uma enraizada em um
roteador diferente. Como resultado, em um único link vários labels podem estar
em uso se vários roteadores podem estar alcançáveis através daquele link.
 Assim como no IGP, normalmente em implementações LDP são instaladas
várias entradas na tabela de encaminhamento em situações de ECMP ou Equal
Cost Multi-Path. Por exemplo, na figura 1.6, se o custo entre E e D for 5 ao
invés de 10, ali teríamos dois caminhos de custo igual do F para o D, F-E-D e F-
C-D. Por isso, F instala duas entradas na tabela de encaminhamento para o D,
uma correspondente a cada caminho. O tráfego que chega ao F para o D, será
balanceado entre os dois caminhos.

Principais propriedades do LDP

Aqui temos um resumo das principais propriedades do LDP:

● Descoberta automática de peers. LDP usa mensagens de descoberta para
procurar peers. Isso tem dois benefícios importantes:
Facilidade de configuração. O analista não precisa configurar cada peer
manualmente. Adicionando um LSR na rede, requer apenas a configuração do
novo LSR, mas não em outros LSR na rede (em contrato com o RSVP). A
descoberta automática construída no protocolo LDP é uma das razões mais
atraentes para escolher o LDP como protocolo de distribuição de label em redes
que a engenharia de tráfego não é necessária.
Manutenção da sessão. A quantia do estado de sessões em um LSR deve se
manter proporcional ao número de neighbors. Na ausência de peers setados, este
número é constante, sem considerar o tamanho da rede.
Transporte confiável. LDP usa TCP como transporte das mensagens, exceto
as de descoberta. Uma vez anunciado, a informação não precisa ser atualizada.
Mensagens de keepalive são encaminhadas periodicamente para manter a
sessão, o número é proporcional ao número de sessões, não à quantia de
informação que é trocada através da sessão.
Design escalável. LDP usa TLVs para passar informações pra frente. Isso
provou-se repetidamente à medida que o protocolo foi escalável ao longo dos
anos.
Confiança no IGP. LDP confia no IGP para decisões de roteamento. LSP
estabelecidas pelo LDP seguem o melhor caminho pelo IGP e são influenciados
por essas mudanças de roteamento. Durante os períodos de convergência da
rede, LSPs LDP são afetadas, e o tráfego pode loopar ou ser perdido.
Retenção de labels liberal e distribuição de labels não solicitada
downstream. Os labels são anunciados para todos os peers e mantidos pelos
peers se eventualmente não estiverem ativos para o encaminhamento. Então o
LDP reage rapidamente às mudanças de roteamento.

1.3.2.2 RSVP

Outro esquema de distribuição de labels para o transporte de LSPs é baseado

no Resource Reservation Protocol (RSVP). RSVP foi inventado antes do MPLS
vir à tona, e foi originalmente concebido com um esquema para criar reservas
de banda para um fluxo individual de tráfego na rede (como telefonia e sessões
de vídeo entre dois hosts em particular) como parte do até então chamado
modelo "int-serv". RSVP inclui mecanismos para reserva de banda ao longo de
cada salto na rede para sessões fim-a-fim. Entretanto a aplicação original do
RSVP, o int-serv falhou por conta das preocupações sobre escalabilidade: o
número de sessões entre hosts fim-a-fim dentro de uma rede de ISP tende a ser
gigantesco, e não é desejável para os roteadores dentro da rede terem que criar,
manter e derrubar e subir sessões à medida que vem e vão.
Entretanto, no contexto de MPLS, RSVP foi escalado para permitir que seja
usado para criação e manutenção de LSP, e criar reservas de banda associadas
aos LSPs [RFC 3209]. Quando usado nesse contexto, o número de sessões
RSVP na rede é muito pequeno em comparação com o modelo int-serv, pelo
fato de que o tráfego é agregado dentro de um LSP. Um único LSP requer
apenas uma sessão RSVP, e ele pode carregar o tráfego entre um par específico
de roteador de entrada e saída, contendo vários fluxos de tráfego fim-a-fim.
Um LSP sinalizado com RSVP tem a propriedade de que seu caminho não
precisa necessariamente seguir o melhor caminho dito pelo IGP. RSVP em sua
forma estendida, tem propriedades de roteamento explícitas em que o roteador
de entrada pode especificar o caminho inteiro fim-a-fim que o LSP deve seguir,
ou pode especificar em quais roteadores em particular a LSP deve passar. Aqui
temos algumas consequências das propriedades de roteamento explícitas do
RSVP:
1. O caminho não necessariamente segue o IGP. O caminho pode ser
computado para cumprir diferentes restrições que podem não ser levadas em
conta quando o IGP computa o caminho. Como tal, LSP sinalizados pelo RSVP
são componentes chaves para a engenharia de tráfego baseada em MPLS,
permitindo ao administrador da rede ter controle do caminho tomado por um
fluxo de tráfego entre dois pontos em particular, que passa por dentro de um
LSP.
 2. O caminho pode ser computado de forma “online” por um roteador, ou
de uma forma "offline'' por uma ferramenta de computação. No caso da
computação online, normalmente somente o roteador de entrada precisa estar
atento a qualquer restrição aplicada ao LSP. Além disso, o uso de rotas
explícitas elimina a necessidade de todos os roteadores ao longo do caminho
terem uma tabela de roteamento consistente, e um algoritmo de roteamento
consistente.
3. O caminho não é restrito à somente uma instância de roteamento.
Enquanto um caminho estiver especificado em somente um lado, RSVP não
estará limitado à somente uma instância de IGP (Então, por exemplo, não está
preso em somente um AS). Em contraste, LDO é dependente do IGP, então
embora os LSPs LDP possam atravessar áreas ou levels IGP, ele não pode
atravessar um AS para outro, desde que ASs rodem diferentes IGPs.
4. Um LSP pode ser sinalizado de tal maneira que o caminho pode ser
mudado pelo seu roteador de criação. Isso em contraste com o LDP, onde cada
LSR atualiza o seu estado de encaminhamento independente do estados de IGP
dos outros LSRs. Essa propriedade é muito importante no sentido de proteção
de tráfego como fast reroute, discutido com detalhes no capítulo 3. O esquema
de fast reroute envolve cada roteador ao longo do caminho de um LSP,
computando o local de falha, o caminho ignora o link de downstream se for uma
falha no link, ou ignora o node se ele for a falha. O tráfego encaminhado por
essa LSP é garantido que chegue ao roteador que foi configurado como reparo
da falha, desde que os roteadores envolvidos ao longo do caminho não tenham
mudanças no estado de encaminhamento após a falha (isso novamente em
contraste com o looping que poderia acontecer com o LDP seguindo a falha).

A criação de LSP sinalizado com RSVP é iniciado pelo LER de entrada. O

LER de entrada encaminha uma mensagem RSVP Path. O endereço de destino
da mensagem de caminho é o LER de saída. Entretanto, a RSVP Path tem uma
opção Router Alert, que é configurada para que os roteadores de trânsito
possam inspecionar a mensagem e fazer modificações necessárias.
Aqui temos alguns objetos contidos na mensagem RSVP Path.
1. Label Request Object. Solicita um label MPLS para o caminho. Como
consequência, o roteador de saída e os de trânsito alocam labels para essa sessão
do LSP.
2. Explicit Route Object (ERO). O ERO contém os endereços dos nodes que
o LSP deve passar.
 3. Record Route Object (RRO). RRO solicita que o caminho seguido pela
mensagem RSVP Path (e portanto, pelo próprio LSP, depois de criado) seja
recordado. Cada roteador por onde a mensagem RSVP Path passou adiciona seu
endereço na lista RRO. O roteador pode detectar loops de roteamento se ele ver
seu próprio endereço na lista RRO.
4. Sendet TSpec. TSpec possibilita o roteador de entrada solicitar uma
reserva de banda para o LSP em questão.

Em resposta a mensagem RSVP Path, o roteador de saída encaminha uma

mensagem Resv. Nota-se que o roteador de saída endereça a mensagem Resv
para o roteador adjacente de upstream, ou seja, o salto anterior à ele do ponto de
vista do roteador de entrada, ele encaminha ao roteador de upstream ao invés de
encaminhar a mensagem diretamente ao roteador de origem. Isso engatilha os
roteadores ao longo do caminho ao encaminhar mensagens Resv aos seus
roteadores de upstream, dos quais receberam a mensagem RSVP Path. Esse
esquema mostra como a mensagem Resv faz o caminho contrário da mensagem
RSVP Path. A figura 1.7 ilustra a troca de mensagens RSVP Path e Resv.

Aqui temos alguns objetos contidos nas mensagens Resv:

1. Label Object. Contém o label que será usado para a sessão do LSP. Por
exemplo, na figura 1.7 quando a mensagem Resv é enviada do roteador de saída
Z para o vizinho upstream Y, ele contém o valor de label que o Y vai usar para
encaminhar o tráfego do LSP em questão para o Z. Por sua vez, quando Y
encaminha a mensagem Resv para o X, ele sobrescreve o Label Object da
mensagem Resv com o valor de label que X usará para encaminhar o tráfego
dessa LSP para o Y. Dessa forma, para o LSP em questão, Y sabe o label que
chega o tráfego desse LSP e o label e interface em que o tráfego dessa LSP vai
sair para o Z. Portanto, isso será instalado na tabela de encaminhamento como
um swapping.
2. Record Route Object. Recorda o caminho tomado pela mensagem Resv,
de uma maneira similar ao RRO carregado pela mensagem RSVP Path.
Novamente um roteador pode detectar um loop de roteamento se ver o seu
endereço na lista RRO.

Como podemos ver, mensagens RSVP Path e Resv precisam viajar salto a
salto porque elas precisam estabelecer um estado a cada node que passam, para
reservar de banda e estabelecer o LSP.
Como consequência do esquema descrito acima, um LSP sinalizado com
RSVP necessita apenas da configuração no roteador de entrada. Em
implementações típicas, as propriedades do LSP e subjacentes da sessão RSVP,
tal como ERO, RRO e solicitação de reserva da banda, podem ser vistas por
qualquer roteador ao longo do caminho do LSP desce que a informação seja
conhecida por todos os roteadores do caminho.
RSVP requer uma troca de mensagens periódica enquanto um LSP está
estabelecido para manter (atualizar) o seu estado. Isso pode ser realizado por
mensagens RSVP Path e Resv encaminhadas periodicamente em cada LSP
ativo. Se um roteador não receber um certo número consecutivo de mensagens
RSVP Path ou Resv para um LSP em particular, ele considera que o LSP não é
necessário e remove seus estados (entrada na tabela de encaminhamento e
reserva de banda para ele) o que for do LSP. A sobrecarga no processamento
por conta do tal esquema, se tornou uma preocupação na escalabilidade de um
roteador que mantém um número grande de LSPs. Para isso, o “Refresh
Reduction Extensions” para RSVP foi concebido, para reduzir essa sobrecarga.
Isso inclui a Summary Refresh Extension para permitir múltiplas sessões RSVP
(logo, múltiplas LSPs) para ter o seu estado atualizado por uma única
mensagem encaminhada entre os vizinhos RSVP para atualizar o timer [RFC
2961].
RSVP tem um mecanismo de detecção de falhas opcional, no qual as
mensagens de hello são encaminhadas periodicamente entre vizinhos RSVP.
Sem esse mecanismo, um node pode ficar ciente da falha de um vizinho
somente se alguma sessão RSVP cair, e isso pode levar um bom tempo. Note
que o RSVP não segue o mesmo conceito seguido pelo LDP em casos com
ECMP. Um LSP sinalizado com RSVP segue apenas um caminho da entrada
até a saída. Se, realizando a computação do caminho, o roteador de entrada
achar vários caminhos em potencial para o LSP e que tenha uma métrica para a
escolha igual, ele escolhe apenas um desses caminhos para o LSP e sinaliza a
criação dele via RSVP. Por isso, uma vez que o tráfego entra em um LSP
sinalizado via RSVP, não ocorre a divisão e fusão do tráfego como ocorre
algumas vezes em casos com LDP. Por outro lado, se o roteador de entrada tiver
vários LSPs sinalizados com RSVP para um roteador de saída em particular, ele
pode balancear o tráfego nessas LSPs. Algumas implementações permitem que
o load-balance seja feito com pesos de acordo com as reservas de banda do
RSVP.
Em alguns casos, a rede pode ter um punhado de LSPs sinalizados com
RSVP, como uma tática de controle de fluxos de tráfego sobre alguns pontos de
acesso da rede. Nessa situação, os LSPs RSVP tem que ser criados e certos
pares de pontos finais para alcançar esses objetivos. Em outras redes, a razão
para entregar LSPs RSVP é para fazer uso do fast reroute, nesse caso o
administrador da rede pode escolher em conectar os PEs da rede com os LSPs
RSVP em uma topologia full mesh na rede.
Em propósito de resumo, aqui temos algumas propriedades chaves de RSVP:

● Explicit Routing. O LER de entrada tem controle sobre o caminho que

toma o LSP, especificando o caminho inteiro ou somente alguns nodes
que o LSP deve passar. Como consequência, RSVP usa a si mesmo para a
engenharia de tráfego e proteção de tráfego independente de, e mais
rápido que, o IGP.
● Troca de mensagens periódicas são necessárias para renovar o estado de
um LSP, apesar de existir o RSVP Refresh Reduction para reduzir a
sobrecarga.
● O tanto de sessões RSVP em estado de um roteador, é proporcional ao
número de LSP que passam pelo node. Isso tende a crescer como a rede
cresce (assumindo um alto grau de malhas LSPs RSVP).

1.3.2.3 Comparação RSVP e LDP

 Uma pergunta frequentemente feita é qual dos protocolos LDP e RSVP é
melhor para usar na entrega. Vamos comparar os dois protocolos considerando
fatos que podem afetar as escolhas para o uso:
1. Facilidade na configuração:
(a) Configuração inicial. LDP tem a vantagem de ser facilmente
configurado, precisa somente de uma linha de configuração em
algumas implementações, para permitir que o protocolo funcione
em uma interface. RSVP, por outro lado, necessita de uma
configuração explícita dos LSPs no roteador de entrada. Cada
roteador deve conhecer todos os outros roteadores que devem
estabelecer os LSPs.
(b) Configuração incremental quando um novo EDGE é adicionado.
Para o LDP, somente o novo dispositivo é configurado. Para o
RSVP, adicionando um novo roteador EDGE na rede, significa
configurar LSPs para ele em todos os roteadores existentes, ou
seja, consequentemente é necessário configuração em todos os
outros roteadores da rede.
Existem algumas formas de reduzir todo o esforço de configuração
usando o RSVP. Uma forma é automatizar essa capacidade de
malha, cada roteador EDGE da rede automaticamente cria um LSP
RSVP para os outros roteadores EDGE da rede. Outra
possibilidade é a autoconfiguração de largura de banda, quando
uma reserva de banda para LSP tem mudanças de acordo com o
volume de tráfego usado por esse LSP. Usados em combinação, o
esforço para a configuração não deve ser tão diferente do que é
associado ao LDP. Tais esquema não precisam de ajuda em todos
os casos, exceto quando cada LSP precisa de uma reserva de banda
fixa ou não pode ser variada dinamicamente.
2. Escalabilidade:
(a) Sessões do plano de controle. Para o LDP, cada roteador deve
manter um número de sessões igual ao número de vizinhos LDP.
Para o RSVP, o número de sessões é igual ao número total de LSP
que o roteador está envolvido, seja de entrada, trânsito ou saída.
Em uma topologia full mesh, o número total de LSP na rede é de
N² no caso do RSVP, quando N é o número de roteadores EDGE,
mas isso N é proporcional no caso do LDP, por causa que cada
roteador EDGE na rede é entrada para uma estrutura ponto-
 multiponto, sendo todos os outros roteadores EDGE um ponto de
saída.
(b) Manutenção de estado. LDP encaminha mensagens de hello e
keepalive periodicamente, mas somente para um número limitado e
constante de vizinhos/sessões. RSVP deve atualizar todas as
sessões para todos os LSPs que passam pelo roteador, número que
não se tem controle. RSVP Refresh Reduction reduz o número de
mensagens RSVP que devem ser criadas e encaminhadas para
ordenar a atualização das sessões, entretanto, o roteador ainda
precisa acompanhar o estado de cada sessão.
(c) Estado de encaminhamento. LDP mantém o estado de
encaminhamento para todos os FECs na rede. Por natureza do
protocolo, cada FEC é alcançável de todo ponto da rede. A
capacidade do LDP de suportar ECMP significa que ele pode
manter mais de um caminho. RSVP, por outro lado, mantém
somente os estados dos LSPs que passam por ele, e potencialmente
caminhos de proteção.

Para fins práticos, as considerações acima podem não ser de importância, a

menos que se tenha um número muito grande de roteadores que precisam ser
totalmente em malha com LSPs sinalizados por RSVP, resultando em um
volume insustentavelmente grande de número de LSPs a serem mantidos pelos
roteadores no core da rede. Nesses casos, os esquemas de hierarquia LDP sobre
RSVP ou LSP descrito mais adiante nesta seção podem ser usados.

3. Recursos suportados. Atualmente, somente o RSVP suporta engenharia de

tráfego.

A partir da análise acima, não é surpresa para ninguém que se não for
necessário as propriedades de engenharia de tráfego, o LDP quase sempre é o
escolhido. Vamos ter uma visão sobre a escolha do protocolo em contextos
onde a aplicação precisa de uma conectividade MPLS:

1. L3VPN. Esses serviços quando oferecidos não tem um SLA rigoroso em

termos de tempo fora ou de falhas do link, pode oferecer classes de
tráfego Diffserv, mas isso não é necessário a reserva de banda dentro do
core. As principais considerações para esse projeto são a fácil
 configuração e gerenciamento. Por tanto, o LDP recebeu uma
implantação mais ampla que o RSVP na maioria das redes.
2. Migração de serviços layer 2 para redes MPLS. Emulação de serviços
como ATM e Frame Relay sobre redes MPLS eventualmente requer uma
reserva de banda considerável. Por exemplo, se um ISP entrega um
acesso particular com uma classe de serviço em particular entre dois
pontos de acesso da rede, é necessário garantir que a banda entre os dois
pontos esteja reservada e incontestada. Devido a isso, as características da
engenharia de tráfego (e em particular DiffServ Aware Traffic
Engineering), RSVP é melhor que o LDP nessas implementações.
3. Serviços que precisam de uma restauração rápida, como serviços de voz.
Em alguns casos, não é necessário engenharia de tráfego, por conta da
banda utilizada pelo link ser muito baixa. Entretanto, as capacidades do
fast-reroute podem ser necessárias, devido à natureza do serviço (voz).
No passado, o RSVP era o único protocolo que suportava o rápido “re-
roteamento” assim como serviços que usavam LSPs RSVP como
transporte. Entretanto, recentemente o rápido re-roteamento foi
adicionado aos LSPs LDP e podem ser usados como alternativa para os
LSPs RSVP em certas topologias. Abordagens ao fast re-route para LSPs
RSVP e LDP serão discutidas com detalhes no capítulo 3.

Em muitas implantações, cada ponto de presença (POP) consistem em

diversos roteadores de acesso e um ou dois roteadores que fazem face ao core
da rede. O SP (Service Provider) pode desejar usar o RSVP para as
propriedades de engenharia de tráfego no core, mas ele não precisa de
engenharia de tráfego dentro do POP. Similarmente, pode ser necessário o fast
re-route no core, mas não dentro da infraestrutura do POP, já que temos a
premissa que um falha intra-POP é relativamente rara.
Nesses casos, o SP pode usar o LDP dentro dos POPs e LSPs sinalizados com
RSVP no core da rede. Isso é mostrado na figura 1.8.
 Na figura 1.8, cada POP tem 5 LERs e dois LSRs “core-facing” que são
conectados diretamente ao core da rede. Cada LER core-facing tem um LSP
sinalizado por RSVP para cada LSR core-facing nos outros POPs. Na imagem,
são mostrados com clareza apenas os LSPs sinalizados com RSVP do POP C
para o POP A. Sessões LDP apontadas são criadas entre os roteadores de
entrada e saída de cada LSP RSVP. Uma sessão LDP apontada permite que
labels LDP sejam trocados entre os roteadores mesmo que eles não sejam
diretamente conectados um com o outro, de modo que os labels LDP sejam
trocados sem envolver os roteadores de trânsito das LSPs RSVP. Por exemplo,
temos uma sessão LDP apontada entre P3 e P1, e os roteadores do core da rede
(P5, P6, P7 e P8) não estão envolvidos nessa sessão. Vamos ver o impacto que o
esquema LDP sobre RSVP tem no número total de LSPs RSVP na rede. Se o
número de roteadores core-facing na rede for Y, então esse número de LSPs
RSVP será reduzido de Y (Y - 1) para X (X - 1). Isso poderia ser uma redução
grande se a razão de Y para X for grande. Por exemplo, considerando que a rede
tenha 30 POPs, cada um contém dois roteadores core-facing e cinco roteadores
edge. Nesse caso onde temos todos os roteadores edge conectados full mesh
com LSPs RSVP, teremos 22350 (150 x 149) LSPs RSVP na rede. No caso
onde somente os dois roteadores core-facing de cada POP sejam conectados full
mesh, teremos um total de 3480 (60 x 58) LSPs RSVP na rede. Isso é quase um
requisito para redes já de magnitude pequena com casos full mesh. O pequeno
número de LSPs significa menor processamento nos protocolos e nos
roteadores. Isso, por si só, só tem consequências práticas se a carga nos
roteadores edge é insustentavelmente alta. Mais importante, menos LSPs
significam menos configuração e gerenciamento do ponto de vista de operação.

O processo de LDP sobre RSVP está ilustrado com mais detalhes na figura
1.9, que mostra uma conexão que cruza o core da rede até o edge. Roteadores
A, B e C estão no mesmo POP. Roteadores F,G e H estão em outro POP. D e E
são os roteadores do core. O LDP é usado dentro dos POPs. Na rede, os
roteadores que fazem face ao core são conectados de forma full mesh com LSPs
sinalizados por RSVP. Nesse caso, temos um par de LSPs RSVP entre C e F,
um em cada direção. Também, temos sessões LDP apontadas entre os
roteadores core-facing em cada POP, entre C e D no diagrama. A sessão LDP
aponta permite que C e F troquem labels diretamente para os FECs associados
aos roteadores edge em seus respectivos POPs. Por exemplo, C aprende o label
do F para usar quando encaminhar o tráfego para o H. Roteadores D e E não são
envolvidos no processo de sinalização LDP, e não armazenam labels LDP.
Vamos considerar que o transporte dos pacotes chegam na rede no roteador A
e saiam da rede no roteador H. A operação do plano de encaminhamento segue:
Roteador de entrada A faz o push do label que aprendeu via LDP. No exemplo,
o valor do label é L1, e é o label associado com o H, o ponto de saída do pacote.
Roteador B faz o swap do label para um que tem o valor de L2. Roteador C é o
roteador de saída para o LSP RSVP que cruza o core. C faz o swap do label
existe L2 para o label de valor L3 que aprendeu via sessão LDP apontada com o
F. E também, faz o push de label de valor L5 aprendido via RSVP para esse
pacote. Por isso, neste ponto, a pilha de label consiste em um outer label de
valor L5 e um inner label de valor L3. Os roteadores core D e E sabem apenas
sobre os LSPs RSVP e por isso carregam somente as operações do outer label.
D faz o swap do label mais externo, o outer label de valor L5 para um label de
valor L6. Nota que o label abaixo de valor L3, é intocado. Se o PHP estiver em
uso, o roteador E faz o pop do label aprendido via RSVP, então deixando
apenas o label L3 aprendido via LDP pelo roteador C. O roteador F faz o swap
do label LDP para um label de valor L4. Se o PHP estiver em uso, o roteador G
fará o pop do label, deixando apenas o cabeçalho do pacote que estava
encapsulado. Isso pode ser um cabeçalho IP, ou pode ser um cabeçalho MPLS,
em casos de serviços VPN.
Em casos onde as propriedades trazidas pelo RSVP são necessárias de edge
para edge. O esquema acima de LDP sobre RSVP não é adequado. Entretanto,
em casos de redes de larga escala, pode não ser viável conectar todos os
roteadores edge com LSPs sinalizados por RSVP, por resultar em uma grande
quantidade de sessões RSVP no core da rede. O conceito de LSP hierárquico
[RFC 4206] foi introduzido para resolver este problema. Nesse esquema, uma
camada de roteador é conectada de forma full mesh com LSPs sinalizados com
RSVP. A camada é escolhida de tal modo que os roteadores envolvidos na
conexão full mesh sejam menores que o número de roteadores edge. Por
exemplo, com o esquema de LDP sobre o RSVP discutido anteriormente, os
roteadores escolhidos podem ser os roteadores core-facing de cada POP. Os
roteadores edge podem ser também conectados de forma full mesh com LSP
RSVP que estão aninhados dentro dos LSPs entre os core-facing. Os LSPs no
core da rede são chamados de Forwarding Adjacency (FA) LSPs. Referindo-se
a figura 1.8, no contexto do LSP hierárquico, os LSPs entre P1, P2, P3 e P4 são
os FA LSPs. Cada LER teria uma LSP sinalizada com RSVP para cada outro
LER na rede, o qual seria tunelado em dos FA-LSPs que cruzam a rede. Dessa
forma os roteadores no coração da rede (P5,P6,P7 e P8 na figura) teriam apenas
que lidar com a sessão que corresponde aos LSPs do core, e desconhecem o fato
das LSPs de LER para LER estarem encapsuladas nesses LSPs.
 O conceito de LSP hierárquico é ilustrado com mais detalhes na figura 1.10.
O diagrama mostra seis LERs, três em cada dos dois POPs. P1 é um roteador
core-facing em um POP e P3 é um roteador core-facing no outro POP. O
diagrama mostra um LSP sinalizado com RSVP entre P1 e P3. Usando LSP
hierárquico, LSPs edge-para-edge entre os LERs em dois POPs pode ser
aninhado no LSP do core entre P1 e P3. Por exemplo, aqui temos um LSP entre
PE1 e PE4, ou entre PE2 e PE5 em breve. Entretanto, P2 no core da rede não
sabe da existência desses LSPs e está envolvido apenas na manutenção do LSP
do core. Isso é por causa que as mensagens RSVP associadas aos LSP edge-
para-edge passam diretamente entre P1 e P3 sem ser processado pelo plano de
controle do P2. Nota que no plano de dados, as operações de label são análogas
para o LDP sobre RSVP, caso que foi mostrado na figura 1.9. O roteador de
entrada do FA-LSP faz o push de um label correspondente ao FA-LSP na pilha
de label existente. Esse label é trocado a cada salto do FA-LSP, deixando os
labels abaixo da pilha intocados, e ele é normalmente aberto pelo último
roteador no fim do FA-LSP, deixando expostos os labels que ficaram embaixo
da pilha para o próximo roteador que receber o tráfego.

1.3.2.4 Distribuição de labels BGP

O terceiro tipo de distribuição de labels, também confia em um protocolo pré-

existente, o BGP. O BGP suporta várias famílias de endereços, que fazem
frente para definir e carregar novos tipos de NLRI e atributos associados.
Portanto, por adicionar novas famílias de endereços no BGP, é possível
anunciar não somente prefixos mas também um ou mais labels associados ao
prefixo. Em VPNs Hierárquicas e Inter-AS no capítulo 9, veremos que essa
capacidade é essencial nos contextos de Inter-AS MPLS/VPNs. O capítulo
descreve várias soluções para qual o BGP é usado:
(a) Distribui as inner labels (labels VPN) necessárias para que o LER de
saída identifique o serviço e a instância do serviço que o pacote pertence.
(b) Distribui as outer label necessárias para transportar o pacote até o LER
apropriado.

A razão para escolher o BGP como protocolo para a solução é discutida com
detalhes em VPNs Hierárquicas e Inter-AS (Capítulo 9). Nesse ponto, vamos
ver alguns benefícios adicionados por pelo uso de BGP para distribuição de
labels.

● A habilidade de estabelecer LSPs que cruzam as bordas do AS. Um

exemplo de onde é necessário é em VPNs baseadas em MPLS que tem
pontos em vários provedores de serviços. Nesse caso, é necessário
distribuir labels que estejam em um alcance dos LERs, de modo que o
label de transporte chegue ao LER de outro AS. BGP é um protocolo que
é usado hoje em dia para transmitir NLRIs através de bordas de AS,
entretanto ele pode facilmente transmitir labels através de bordas do AS.
● É uma ajuda para a escalabilidade em redes MPLS de grande escala - Isso
é discutido com mais detalhes no contexto de MPLS desatado no capítulo
16.
● Redução do número de diferentes protocolos rodando dentro da rede. Em
vez de entregar inteiramente um novo protocolo, é feito reuso de um
protocolo existente para fazer mais de uma função.
● Reuso das capacidades de um protocolo existente. BGP suporta um
conjunto rico de atributos que permitem filtrar informações de
roteamento, controlar a seleção de pontos de saída, prevenir loops, etc.
Todas essas capacidades são prontamente disponíveis quando uma
informação de label é distribuída juntamente com um prefixo.
A distribuição de labels com BGP é também usada em contexto do esquema
6PE para habilitar o transporte de IPv6 sobre um core MPLS IPv4. Isso será
discutido na próxima sessão.

1.3.3 Transporte de IPv6 sobre um core MPLS IPv4

 Cada vez mais, os provedores de serviços estão vendo a necessidade de
carregar tráfego IPv6 assim como o tráfego IPv4 através de suas redes. Quanto
ao tráfego IPv4, o tráfego IPv6 pode ser dividido em duas categorias principais:
(i) Tráfego IPv6 público (ou tráfego internet IPv6). Nesse caso, o requisito
para o provedor de serviço é transportar os pacotes IPv6 entre os usuários IPv6
através da infraestrutura pública da internet. Em alguns casos, pacotes podem
ser transportados entre os usuários conectados à mesma rede do provedor de
serviço, mas é mais comum que a tarefa do provedor de serviços seja transportar
o tráfego de um usuário IPv6 até um peering IPv6, para ser entregue por um
outro provedor de serviço.
(ii) Tráfego IPv6 privado. Nesse caso, o requisito é entregar um serviço de
VPN, para permitir que o tráfego IPv6 seja transportado entre os sites de
clientes enquanto mantém separado e privado de outros clientes.

Nesta seção, nós vamos examinar o caso (i), o caso de IPv6 público em mais
detalhes. Caso (ii), tráfego IPv6 privado, será discutido no capítulo Tópicos
avançados em camada 3 VPNs MPLS/BGP.
O ISP tem as escolhas a seguir em termos de como carregar o tráfego IPv6
através do core da rede:
1. Habilitar o encaminhamento IPv6 e habilitar o IPv6 no IGP em todos os
roteadores da rede, e encaminhar os pacotes IPv6 de forma nativa.
2. Criar túneis full mesh (como túneis GRE) entre os roteadores PE na rede.
Então os pacotes IPv6 serão encapsulados em IPv4, evitando a
necessidade de habilitar o IPv6 no core da rede.
3. Usar LSPs MPLS entre os roteadores PE na rede para carregar os pacotes
IPv6.
 Opção 1 é de interesse de provedores de serviço que carregam o tráfego IPv4
através da rede de forma nativa, porque o tráfego IPv6 é carregado de forma
análoga. Entretanto, em alguns casos, o provedor de serviços pode ter
roteadores que não são capazes de rodar o IPv6 ou podem estar relutantes para
habilitar o IPv6 nos roteadores core da rede.
Em contraste, a opção 2 evita a necessidade de habilitar o IPv6 nos roteadores
core, porque os pacotes IPv6 são encapsulados dentro de pacotes IPv4. Essa
questão com esse esquema, entretanto, geralmente envolve a configuração
manual dos túneis e tem uma sobrecarga operacional.
Opção 3 é atrativa para provedor de serviços que usam LSPs MPLS para
carregar seu tráfego IPv4, isso permite que seja usado os mesmos LSPs para
carregar o tráfego IPv6 também. Tem uma sobrecarga configuracional bem
mais baixa que a opção 2.
Vamos examinar a opção 3 com mais detalhes. Um esquema chamado 6PE
[RFC 4798] foi concebido para atender esse cenário. A premissa atrás do
cenário é que os roteadores core não suportam o IPv6, então somente os LERs
precisam ter suporte ao encaminhamento IPv6 e ao protocolo IPv6. Os LSPs
usados para transportar os pacotes são sinalizados utilizando IPv4 e podem usar
os mesmos LSPs que são usados para transportar o tráfego IPv4 e outros
tráfegos como tráfegos de camada 2. A figura 1.11 ilustra a infraestrutura
necessária para o esquema 6PE.
Os roteadores LERs do provedor de serviços cada um com uma sessão eBGP
rodando sobre IPv6 para os CEs conectados. De forma parecida, o roteador de
peering do provedor de serviços tem outras sessões eBGP rodando sobre IPv6
com peering e provedor de upstream. Dentro do core da rede, sombreado de
cinza, o endereçamento e o IGP é baseado em IPv4. Os LERs na rede são
conectados em full mesh com LSPs que são sinalizados com IPv4. As sessões
iBGP para trocar de rotas entre os LERs também funcionam sob IPv4.
Em paralelo, discutindo as operações de label associadas ao 6PE, vamos re-
examinar o LSP na figura 1.7. O LSP na na figura é sinalizado com RSVP, mas
o mesmo se mantém sinalizado usando LDP. Imagine um pacote simples de
IPv6 encapsulado no LSP mostrado na figura. Entre X e Y, o pacote terá o valor
de label 51. No Y, o label será aberto, com ação de pop, desde que o PHP esteja
em operação. Entretanto, o uso do PHP não é obrigatório, na prática, ele é usado
na maioria dos projetos MPLS. Isso daria origem a entrega de um pacote IPv6
puro, exposto pelo roteador Y. Entretanto, a premissa atrás do 6PE é que os
roteadores P não suportem o IPv6. Se for esse caso para o roteador Y, o
roteador Y vai desencapsular esse pacote IPv6 e por não rodar o protocolo, não
saberá o que fazer com ele, e não vai encaminhar para o roteador Z. Por
exemplo, se um link ethernet estiver em uso entre Y e Z, o roteador Y precisa
por o ethertype no frame ethernet com o valor associado à um payload IPv6.
Para superar o problema, o 6PE pode criar um label adicional para que o pacote
IPv6 não seja exposto para o penúltimo roteador. Isso é ilustrado na figura 1.12.

Aqui temos um LSP MPLS do PE1 para o PE2, sinalizado com LDP ou
RSVP. No PE1, é feito o push de um cabeçalho MPLS com o valor de label Y
em todo pacote IPv6. No topo disso, outro cabeçalho MPLS tem um valor de
label X, que é sinalizado por LDP ou RSVP. No P1, o outer label ou label mais
do topo, é trocado, ou seja, feito um swap, por um label de valor W. No P2, o
outer label é aberto, ou seja, feito o pop, expondo o inner label de valor Y. O
pacote é encaminhado com esse label para o PE2. Mas como o PE1 sabe qual o
valor de label é necessário para o inner label? A resposta é o uso do Multi-
Protocol BGP, ou MP BGP. Dessa forma, quando o PE2 anuncia seus prefixos
IPv6 no BGP, ele também anuncia os labels associados àquele prefixo. O
Address Family Indicator (AFI) usado para esse anúncio tem um valor de 2, que
significa IPv6. O Subsequent Address Family Indicator (SAFI) usado tem o
valor 4, que significa uma labeled route, ou seja, uma rota com label associado.
A mesma sessão BGP pode ser usada para anunciar prefixos IPv4, sem labels. O
mesmo LSP pode ser usado para carregar o tráfego IPv4 e o tráfego IPv6 entre
os PE1 e PE2. Em cada salto, a pilha de labels de um pacote IPv6 terá um label
mais empilhado do que um quando é encapsulado um pacote IPv4, por causa do
6PE.
Note que o 6PE não é um esquema de VPN. Se a necessidade é entregar um
serviço de VPN capaz de transportar os pacotes IPv6 de um cliente, o esquema
será discutido no capítulo Tópicos Avançados na camada 3 BGP/MPLS VPN.

Capítulo 2: Engenharia de Tráfego com MPLS

2.1 Introdução

Controlar o caminho tomado pelo tráfego através da rede é chamado de

engenharia de tráfego (TE). Aqui temos várias razões do porque os operadores
de rede querem influenciar o caminho tomado pelo tráfego em suas redes. A
razão mais popular é melhorar a utilização dos recursos da rede. A meta é
simples: evitar situações onde partes da rede estão congestionadas e outras são
subutilizadas. Outras razões para a utilização da engenharia de tráfego incluem
garantir que o caminho tenha certas características (garantindo que não tenha
uma alta latência), garantir que recursos de transmissão estejam disponíveis ao
longo de um caminho em particular, e determinar qual tráfego terá prioridade
em um período de crise de recursos (como um lin de rede fora).
 Esse capítulo descreve porque o MPLS é uma tecnologia útil para
implementar engenharia de tráfego e como ele pode realizar o objetivo de
direcionar o tráfego ao redor da rede.

2.2 Os Motivadores do Negócio

Influenciar no caminho tomado pelo tráfego na rede pode aumentar as

receitas de duas formas:
1. Oferecendo novos serviços com garantias extras.
2. Baixando o investimento em novos recursos de rede (primeiramente com
largura de banda) por melhorar a utilização dos recursos existentes.
“Oferecer novos serviços” significa que o operador da rede pode cobrar
qualquer dinheiro extra para. Um exemplo, o "serviço de garantia de largura de
banda”, onde simplesmente significa que uma certa largura de banda está
disponível para o tráfego de um cliente em particular, em situações de falha do
link e em condições estáveis da rede.
“Melhorando a utilização de recursos” significa evitar uma situação onde
parte da rede está congestionada enquanto outra parte está subutilizada. Por
exemplo, se alguma parte do tráfego é roteada de um link congestionado para
um link onde tem largura de banda disponível, o upgrade desse link
congestionado pode ser adiado. Evitar o congestionamento, também significa
melhorar a qualidade do tráfego do cliente: menos perda, menor latência e um
melhor throughput.
Outro importante “salvo de custo” é alcançado à medida que a engenharia de
tráfego é aumentada à máxima porcentagem de utilização do link. Analistas
constantemente monitoram a utilização do link para determinar em qual ponto é
necessário agendar um upgrade no link. Cada rede tem suas próprias regras de
upgrade, expressado em termos de porcentagem da utilização do link que
podem ser gatilho para uma melhoria no link. Uma regra comum é fazer um
upgrade em 50% de utilização, para ser capaz de suportar um aumento de
tráfego em caso de falha de algum link. O benefício da engenharia de tráfego
nesse contexto é que permite uma alta utilização dos links, por ter mais controle
do caminho tomado pelo tráfego na rede, em casos de operação normal e em
casos de falhas. Por melhorar a porcentagem média de uso dos links, os
upgrades nesses links podem ser adiados.
Dessa discussão, fica claro que nem sempre a engenharia de tráfego é
necessária. Se os recursos de largura de banda são abundantes ou o uso é baixo,
sem congestionamento de tráfego, mesmo seguido de uma falha de link. Se não
houver alta latência nos links da rede, não é necessário se preocupar com isso.
Na verdade, isso foi visto no capítulo 1, nem todos projetos MPLS são usados
para a engenharia de tráfego, e dependem do protocolo de distribuição de labels
utilizado, nem todas redes MPLS podem, na verdade, rodar a engenharia de
tráfego. Então, a engenharia de tráfego é associada ao MPLS, mas uma rede
MPLS por si só, não significa ter uma rede com engenharia de tráfego aplicada.
Uma coisa importante para se manter em mente quando discutimos os
benefícios da engenharia de tráfego é que o meio onde é implementada a
engenharia de tráfego, deve ser simples para implantar e manter ela. Em termos
financeiros, o custo adicional de operar uma rede mais complexa deve ser
justificado pela nova receita trazida pela engenharia de tráfego. MPLS fornece
uma simplicidade operacional necessária, juntamente com flexibilidade para
implementar políticas complexas de engenharia de tráfego.

2.3 Cenários de Aplicação

[RFC 2702] estabelece os requisitos para a engenharia de tráfego com MPLS

listando as propriedades desejáveis para a solução. Em vez de discutir os
requisitos em termos abstratos, a sessão seguinte ilustra isso se baseando em
três cenários de aplicação. Ao fim da sessão vamos discutir o porquê o MPLS é
uma ferramenta poderosa para satisfazer esses requisitos.

A topologia de rede usada em todos os cenários é mostrada na figura 2.1.

Duas origens, A e B, encaminham o tráfego com destino ao D através do node
C.
 O custo do caminho é definido em termos de métricas de link. Quando todas
as métricas são iguais, o custo se define ao número de saltos no caminho. Na
rede exemplo, dois caminhos de custo diferente existem entre C e D. Todos os
links têm a mesma capacidade e velocidade, a menos que seja especificado pelo
outro lado.
O primeiro cenário de aplicação destaca a necessidade de encaminhar o
tráfego ao longo do caminho pré-definido. Na rede exemplo da figura 2.1,
assumimos que A e B são dois clientes, e o cliente A contratou um serviço que
garante uma latência baixa. Assumindo que o link G-D é um link via satélite.
Do ponto de vista do operador, o requisito é que o tráfego originado no A deve
evitar a alta latência do link G-D. Então, o caminho de A para D deve ser
encontrado evitando o link G-D.
Na rede de exemplo da figura 2.1, o caminho de A para D pode ser facilmente
identificado A-C-E-F-D. Sem considerar como o caminho foi computado, o
problema passa a ser como encaminhar o tráfego de A ao longo do caminho A-
C-E-F-D.
É difícil satisfazer essa requisição em uma rede IP. O desafio com IP reside
no fato que o encaminhamento se torna independente em cada salto, baseado no
destino do tráfego. Por tanto,