1
MPLS
Multi-Protocol LABEL Switching
Edgard Jamhour
Nesse módulo será vista a estratégia de roteamento e engenharia de tráfego denominada
MPLS: Multi-Protocol LABEL Switching.
O MPLS é, atualmente, uma das tecnologias mais utilizadas para criação de circuitos virtuais.
Sua principal aplicação é a venda de caminhos, com garantias de qualidade de serviço, para
clientes corporativos.
A configuração de um caminho MPLS pode ser feito de maneira manual ou automática. A
configuração automática é feita através de protocolos de sinalização especializados para o
MPLS denominados "Protocolos de Distribuição de LABELs".
Nesse módulo serão vistos os principais conceitos do MPLS, incluindo os principais
protocolos de distribuição de LABELs.
2
MPLS X Roteamento Tadicional (Hop by Hop)
Melhor caminho:
Nova demanda
50 Mbps para
200.0.0.128/25
Para 200.0.0.0/24: 1 -2 -3
Para 210.0.0.0/24: 1-4-5
100 Mbps para
200.0.0.0/25
1Gbps [900]
Cliente
1
2
100Mbps [0]
1Gbs [900]
100Mbps [50]
50 Mbps para
210.0.0.0/24
3
4
200.0.0.128/25
200.0.0.0/24
200.0.0.0/25
100Mbps [100]
100Mbps [100]
100Mbps [50]
100Mbps [50]
5
210.0.0.0/24
Edgard Jamhour
O MPLS: Multiprotocol LABEL Switching foi originalmente proposto pelo IETF em 1997,
como uma solução para acelerar o processo de roteamento na Internet. A idéia principal
por trás do MPLS era introduzir uma técnica de comutação por rótulos, similar a existente
nas tecnologias Frame-Relay e ATM.
A técnica de comutação por rótulos (LABEL Switching) é considerada mais eficiente que a
técnica Hop by Hop usada pelo protocolo IP. No protocolo IP, o endereço de destino de um
pacote pode estar contido em múltiplas rotas de destino ao mesmo tempo. Por exemplo, o
endereço 200.1.2.3 pode estar nas rotas 200.1.2.0/24, 200.1.0.0/16, 200.0.0.0/8 e até
mesmo 0.0.0.0/0. Dessa forma, um roteador precisa localizar a melhor rota para
encaminhar um pacote. No MPLS, por outro lado, o próprio quadro traz um código que
identifica a rota de destino de maneira única.
Além disso, a técnica de comutação por rótulos permite definir múltiplos caminhos para um
mesmo destino. Essa característica tornou o MPLS um instrumento primordial para
engenharia de tráfego, pois ele permite uma melhor distribuição do tráfego pelas rotas
alternativas que uma rede WAN oferece. Antes de discutir esse aspecto do MPLS, convém
ilustrar porque o roteamento Hop-by-Hop é considerado inadequado para engenharia de
tráfego.
Considere o exemplo ilustrado na figura. Suponha que uma operadora de
telecomunicações vendeu para um cliente um canal de 100 Mbps para a subrede
200.0.0.0/25 e 50 Mbps para a subrede 210.0.0.0/24. No roteamento hop-by-hop os
pacotes são sempre roteados pelo caminho de menor custo. Considerando as velocidades
dos enlaces, o caminho de menor custo para a rede 200.0.0.0/25 é 1-2-3 e para rede
210.0.0.0/24 é 1-4-5.
Suponha agora que a operadora deseja vender mais um canal de 50 Mbps para a rede
200.0.0.128/25. Considerando a velocidade dos enlaces, o melhor caminho para essa rede
também é 1-2-3. Como o enlace 2-3 já está exaurido, o novo canal não pode ser vendido.
Contudo, observando a rede, ainda seria possível alocar o canal usando o trajeto 1-4-5-3.
3
Roteamento MPLS
LFIB ⇒ LABEL Forwarding Information Base
SE LABEL de entrada for 1 ENTÃO enviar para 2 com LABEL 2
100 Mbps para
200.0.0.0/25 com
LABEL 10
if1
1
1
Cliente
2
2
3
4
if0
3
200.0.0.128/25
200.0.0.0/24
200.0.0.0/25
4
5
210.0.0.0/24
LSP: LABEL Switch Path
Edgard Jamhour
O MPLS utiliza uma técnica de roteamento denominada "comutação de rótulos" (LABEL
switching), que é muito utilizada pelas tecnologias que permitem criar "circuitos virtuais",
como o ATM e o Frame Relay. No MPLS, o termo LSP (LABEL Switch Path) é utilizado ao
invés de circuito virtual, todavia seu significa é muito similar. Um LSP é um caminho fixo
entre dois pontos da rede, definido como uma seqüência de enlaces de roteadores. Cada
enlace de roteador usado por um caminho específico é identificado por um LABEL, de
forma que um LSP é definido por uma seqüência de LABELs.
Um LABEL é um número inteiro (de 12 bits), contido no cabeçalho MPLS. O cabeçalho
MPLS é colocado entre os cabeçalhos de enlace (camada 2) e rede (camada 3) de cada
pacote. Por essa razão o MPLS é classificado com sendo pertencente a camada 2.5 do
modelo OSI.
A figura ilustra o conceito de LSP e comutação por LABELs. Primeiramente, considere o
caminho do cliente para a rede 200.0.0.0/5 (indicado em vermelho na figura). Esse LSP é
definido como sendo a seqüência de LABELs 1-2-3-4. Do ponto de vista do cliente,
contudo, o caminho é identificado apenas como sendo LABEL 10. Para o cliente usar o
caminho ele simplesmente configura a regra: "marcar com LABEL 1 todos os pacotes
direcionados para a rede 200.0.0.0/25).
Cada roteador possui uma tabela que indica como encaminhar pacotes marcados com
LABELs. Essa tabela denomina-se LFIB (LABEL Forwarding Information Base). A LFIB
indica duas informações básicas: para onde enviar o pacote e com que valor de LABEL. O
LABEL precisa ser trocado pelo roteador a fim de que não seja necessário ter um sistema
centralizado para evitar o uso de LABELs repetidos. Usando a estratégia de comutação por
LABELs, o valor dos LABELS tem significado apenas local ao enlace, isto é, os valores de
LABEL podem ser repetidos em enlaces distintos, mesmo que pertençam ao mesmo
caminho.
4
Roteamento MPLS
SE LABEL de entrada for 1 ENTÃO enviar para 2 com LABEL 1
SE LABEL de entrada for 2 ENTÃO enviar para 2 com LABEL 2
SE LABEL de entrada for 3 ENTÃO enviar para 4 com LABEL 1
SE LABEL de entrada for 2 ENTÃO enviar para 4 com LABEL 1
SE LABEL de entrada for 1 ENTÃO enviar para 3 com LABEL 1
2
Cliente
1
2
1
2
1
1
3
1
1
3
1
2
200.0.0.128/25
200.0.0.0/24
200.0.0.0/25
4
1
2
1
5
LSP: LABEL Switch Path
210.0.0.0/24
1
Edgard Jamhour
A figura ilustra como ficaria o cenário considerando os três caminhos simultaneamente. Um
caminho (LSP - LABEL Switched Path) é criado preenchendo-se as tabelas de
encaminhamento de LABELs (LFIB) de todos os roteadores da rede. Essa tabela pode ser
preenchida manualmente pelo administrador da rede quando o LSP é criado, ou
automaticamente, utilizando protocolos de sinalização criados para o MPLS, como o
RSVP-TE e o CR-LDP.
Caso a tabela seja preenchida manualmente, caberá ao administrador a escolha dos
valores dos LABELs. Os valores podem ser usados livremente, desde que não se use
LABELS repetidos para caminhos distintos no mesmo enlace. Por exemplo, se o caminho
vermelho for o primeiro a ser criado, poder-se-ia usar o mesmo valor de LABEL para todos
os enlaces (LABEL=1). Contudo, o LABEL=1 não pode ser mais usado para identificar o
caminho verde no enlace de entrada do roteador 1. Dessa forma, foram escolhidos os
LABELs 2 e 3 para identificar os caminhos verde e azul. Observe que na saída do roteador
1, o caminho vermelho continua com LABEL=1 e o caminho verde continua com LABEL=2.
Contudo, o caminho azul foi comutador para LABEL=1. Apesar do caminho azul e
vermelho usarem o mesmo valor de LABEL, não existe conflito, pois se tratam de enlaces
distintos.
Quando as tabelas são preenchidas através de um protocolo de sinalização, a escolha do
LABEL é feita pelo próprio roteador, simplesmente escolhendo um valor de LABEL
aleatório que não tenha sido ainda usado em seu enlace. O roteador pode escolher esse
LABEL sem necessidade de conhecer os outros LABELs usados na rede, o que justifica a
estratégia de LABEL switching.
5
LSR x LER
Se destino REDE A então inserir LABEL 1 e enviar para B
Se destino REDE B então inserir LABEL 2 e enviar para B
pacotes sem
rótulo
pacotes com
rótulo
LER de
Egresso
C
A
LER de
Ingresso
B
E
F
rede A
G
rede B
LSR
pacotes com
rótulo
pacotes sem
rótulo
Se chegar pacote LABEL 1, remover o LABEL e encaminhar para REDE A
Se chegar pacote LABEL 2, remover o LABEL e encaminhar para REDE B
Edgard Jamhour
Como sabemos, o roteamento puramente IP já estava bastante difundido quando o MPLS foi
introduzido. Dessa forma, quando o MPLS é adotado por uma operadora de
telecomunicações em seu backbone, é necessário criar mecanismos de conversão entre os
pacotes puramente IP vindos dos clientes e os pacotes marcados com MPLS usados no
backbone. Isto é, quando um cliente puramente IP injeta um pacote na rede o LABEL (ou
rótulo) deve ser inserido, e quando o pacote deixa o domínio da operadora o LABEL deve ser
removido para que os roteadores que não suportam MPLS possam interpretar o pacote.
Dessa forma, podemos definir que em uma rede MPLS existem dois tipos de roteadores os
LER (LABEL Edge Routers) e os LSR (LABEL Switch Routers). Roteadores LER ficam nas
bordas de um domínio MPLS. Sua função é inserir ou remover o cabeçalho MPLS que
contém os LABELs, fazendo o mapeamento entre o mundo IP e o MPLS. Já os roteadores
LSR realizam operações de encaminhamento de pacotes usando unicamente as informações
de LABEL.
A figura ilustra esse conceito. Observe que os roteadores A e G são roteadores do tipo LER e
os roteadores B, C, E e F são do tipo LSR. Um roteador do tipo LER possui uma tabela
especial, que associa a cada rota possível de destino um LABEL. Devemos lembrar que os
caminhos LSPs são sempre unidirecionais, sendo que os pacotes são sempre transmitidos de
um nó de ingresso para um nó de egresso. Para se ter um caminho bidirecional entre os
roteadores A e G é necessário criar dois LSPs distintos.
Os roteadores LER podem ser de dois tipos: LER de ingresso (que faz a inserção do LABEL)
e LER de egresso (que faz a remoção do LABEL). Observe que essa denominação é feita por
caminho, isto é, um roteador LER pode se comportar como ingresso para um dado caminho,
e como egresso para outro.
6
Forwarding Equivalence Class (FEC)
FEC1
44.1.2.0/24
LSR3
LSR2
LER2
55.1.2.0/24
1
LER1
2
LSR1
FEC2
3
LSR4
LER3
66.1.2.0/24
BE
FEC3
Se FEC1 inserir LABEL 1 e enviar para LSR1
Se FEC2 inserir LABEL 2 e enviar para LSR1
Se FEC3 inserir LABEL 3 e enviar para LSR1
60.1.2.0/24
EF
Edgard Jamhour
Em uma tabela de roteamento IP, o destino é sempre uma sub-rede (isto é, um endereço de
base e uma máscara de sub-rede). No MPLS, os destinos recebem uma denominação mais
genérica denominada FEC (Forward Equivalence Class). Uma FEC é definida como um ou
mais destinos para os quais os pacotes são encaminhados da mesma forma, isto é, seguindo
sempre o mesmo LSP (LABEL Switch Path).
O conceito de FEC permite a agregação de vários endereços, mesmo descontínuos, e a
diferenciação de caminhos para um mesmo destino, mas para aplicações ou níveis de
serviços distintos. A figura ilustra esse conceito.
No exemplo, a FEC1 agrupa as sub-redes 44.1.2.0/24 e 55.1.20/24. Isto significa, que os
pacotes enviados para qualquer uma dessas duas sub-redes seguirão sempre o mesmo
caminho, pelo menos na parte da rede que está estrutura em MPLS. Após o LER de egresso,
os pacotes podem seguir caminhos distintos, pois o roteamento passa a ser puramente IP.
As FECs 2 e 3 referem-se a mesma sub-rede 66.1.2.0/24. Contudo, a FEC2 representa o
tráfego do tipo Best Effort e a FEC3 do tipo Expedited Forwarding. Usando duas FECs
distintas permite que o tráfego EF siga um caminho com enlaces exclusivos, garantindo que
os pacotes com esse tipo de marcação sofram pouco atraso.
O roteador LER de ingresso (LER1) possui uma tabela que relaciona cada uma das FEC a
um LSP específico. O LER de ingresso é responsável por determinar por qual caminho cada
pacote irá percorrer. As regras de mapeamento de LABELs nas FECs podem levar em conta
diversos campos do pacote, como IP de origem, IP de destino, Tipo de Protocolo, byte DS
(DSCP) ou, até mesmo, as portas do protocolo de transporte.
7
Cabeçalho MPLS e Empilhamento de LABELs
LABEL do topo
LABEL empilhado
Cabeçalho L2
1
Cabeçalho L3
2
3
LABEL 1
Exp
0
TTL
LABEL 2
Exp
0
TTL
LABEL 3
Exp
1
TTL
O valor do campo S do último rótulo é 0
Edgard Jamhour
A estrutura do cabeçalho MPLS é mostrada na figura. Observe que o cabeçalho MPLS está
situado entre os cabeçalhos das camada 2 e 3. Por exemplo, o cabeçalho MPLS pode estar
entre o cabeçalho Ethernet e o IP. Por essa razão, muitos autores situam o MPLS como um
protocolo da camada 2.5.
Um cabeçalho MPLS pode aparecer múltiplas vezes em um mesmo pacote, criando uma pilha
de LABELs. Um roteador MPLS analisa sempre o LABEL que está no topo da pilha (isto é, o
que está no cabeçalho mais externo), a fim de tomar sua decisão de encaminhamento. Os
demais LABELs são considerados apenas quando o cabeçalho do topo é removido. Como
veremos, o empilhamento de LABELs é utilizado para criar túneis MPLS, que permite evitar
conflitos entre os LABELs adotados por uma operadora de serviços de comunicação e seus
clientes privados.
Um cabeçalho MPLS possui 32 bits, e contém apenas quatro campos:
LABEL (20 bits): contém o valor do LABEL MPLS. Note que é possível definir mais de 1
milhão de valores de LABELs distintos por enlace.
Exp (3 bits): bits reservados para uso experimental. Atualmente, sua maior aplicação é o
mapeamento de uma marcação similar ao DiffServ ao nível do cabeçalho MPLS. Se mais do
que um LSP atravessar o mesmo roteador, os pacotes de cada LSP poderão ser alocados em
filas distintas, e com um PHB específico, de acordo com o valor marcado nesses bits.
S (1 bit): base da pilha. Conforme ilustrado na figura, uma cabeçalho MPLS pode ser
empilhado. O valor 1 indica que o rótulo é a base da pilha, isto é, que ele é o último cabeçalho
empilhado;
TTL (8 bits): Time to Live = determina a quantidade máxima de saltos que o pacote poderá
percorrer. Quando o cabeçalho MPLS é inserido pelo LER, esse campo é copiado do TTL do
IP.
8
Posição do LABEL MPLS
Edgard Jamhour
Conforme seu nome diz, o MPLS foi definido para trabalhar com múltiplos protocolos, tanto de
enlace quanto de rede. Apesar do IPv4 ser o protocolo mais usado com o MPLS, ele pode ser
usado com outros protocolos de camada 3, como o IPv4, IPv6, IPX, e o AppleTalk. O MPLS
pode ser também encapsulado em múltiplas tecnologias de enlace, como o Etherenet, o ATM
e o Frame-Relay.
Em tecnologias como o Ethernet II e o IEEE 802.3 (com a sub-camada LLC), o rótulo MPLS
pode ser inserido integralmente, pois não existe informação equivalente nesses protocolos.
Para as tecnologias como Frame-Relay e ATM, contudo, já existe um campo reservado para
LABEL, de maneira que é possível mapear o LABEL MPLS nesses campos.
Para rótulos simples, isto é, não empilhados, o LABEL MPLS pode ser transportado através
dos LABELs do Frame-Relay e do ATM sem necessidade de inserir novos cabeçalhos. Caso
exista empilhamento de LABELs MPLS, apenas o LABEL do topo pode ser mapeado, sendo
que os demais LABELs da pilha precisam ser inseridos no cabeçalho. Caso os campos EXP
do MPLS precisem ser utilizados, nem mesmo o LABEL de topo poderá ser mapeado, sendo
necessário incluí-lo integralmente no cabeçalho MPLS.
A figura ilustra as diferentes situações de mapeamento. A primeira figura é o caso genérico,
em que toda a pilha de LABELs (MPLS Label Stack) é inserida entre os cabeçalhos 2 e 3 do
pacote. O segundo caso ilustra como ocorre a inserção da pilha de LABELs no caso do IEEE
802.3 com a sub-camada LLC.
A terceira figura ilustra a inserção da pilha de LABELs para o caso do ATM. Os pacotes
MPLS são transportados no formato AAL5 do ATM. Observe que o LABEL MPLS de topo é
mapeado nos campos VPI/VCI, e os demais LABELs são inseridos antes do cabeçalho IP.
De forma similar, o LABEL de topo do MPLS é mapeado no campo DLCI do Frame-Relay, e
os demais LABELs da pilha são inseridos antes do cabeçalho IP.
9
LABEL Switching com Tunelamento
Site B
Site A
A
5
C
B
A
G
8
H
F
E
D
7
6
5
23-6
20-6
C
B
7
6
6
7
F
E
D
G
H
6
20-7
23-7
7
8
Edgard Jamhour
Conforme dito anteriormente, o empilhamento de LABELs é utilizado para criar túneis MPLS,
onde os LABELs de uma operadora não entram em conflito com os LABELs utilizados por
seus clientes privados. A figura ilustra esse conceito.
Considere que uma organização privada deseja interligar dois sites remotos utilizando a
tecnologia MPLS. Suponha que esses sites precisam ter dois LSPs distintos (indicados nas
cores vermelha e azul na figura). Um desses LSPs poderia estar sendo usado para
transportar dados e outro para tráfego VoIP. A figura mostra a seqüência de LABELs para
cada um dos LSPs conforme configurado pelos administradores da organização privada.
Suponha que a organização não possua o enlace necessário para conectar os roteadores C e
F dos dois sites. Ela então precisará contratar um circuito virtual junto a uma operadora.
Suponha que a rede da operadora responsável por conectar os dois sites é formada pelos
roteadores D e E, mostrados na parte inferior da figura. Como a operadora também utiliza a
tecnologia MPLS para criar os circuitos virtuais, é necessário criar algum mecanismo para
evitar que os LABELs usados pelas organizações privadas sejam comutados pela rede da
operadora. Na situação ideal, os pacotes que chegarem ao roteador F precisam ter
exatamente os mesmos valores de LABEL que teriam caso o enlace entre os roteadores C e
F fosse físico.
Para esconder os LABELs de seus clientes, a operadora utiliza o empilhamento de LABELs.
Um novo LABEL de topo é inserido assim que o pacote do cliente entra na rede da operadora.
Durante o trajeto dentro da operadora, apenas o LABEL de topo é alterado. Quando o pacote
é entregue ao site remoto, o LABEL da operadora é removido, e o roteador F recebe os
pacotes em situação idêntica ao de um enlace físico.
O trecho da rede onde os pacotes são transportados com empilhamento de LABELs é
usualmente denominado túnel. É preciso ter cuidado, contudo, pois alguns autores utilizam a
palavra túnel de maneira indiscriminada, como um sinônimo de LSP, mesmo quando o
empilhamento não é utilizado.
10
Configuração do MPLS
No LER origem
FTN
FEC (destino)
FEC 1
FEC 2
Ação X Next Hop
No LSR
ILM
NHLFE
Push LABEL 1 Next-Hop ip LSR
FEC (destino)
Change LABEL 1 to LABEL 2 Next-Hop LER2
LABEL 1 X if1
Pop LABEL 2 Next-Hop SELF
LABEL 2 X if2
No LER destino
ILM
FEC (destino)
LABEL 2 X if1
LABEL 3 X if2
LABEL 1
LSR
LER1
if1
if1
Sem LABEL
LABEL 2
LER2
if2
if1
FEC1
if2
Edgard Jamhour
A configuração de um LSP em uma rede MPLS consiste no preenchimento de um conjunto de
tabelas. Diferente do que acontece com o protocolo IP, onde o formato das tabelas de
roteamento é o mesmo em todos os roteadores da rede, no MPLS o tipo de tabela pode
mudar bastante de acordo com o papel que o roteador desempenha na rede: LER de
ingresso, LSR ou LER de egresso.
A tabela mais importante do MPLS, que está presente em todos os roteadores, é denominada
The Next Hop LABEL Forwarding Entry (NHLFE). Essa tabela define um conjunto de ações
que segue genericamente o seguinte formato:
[Ação sobre o LABEL] X [Ação de Encaminhamento].
As ações sobre um LABEL podem ser: Remover (Pop), Inserir (Push) ou Trocar (Change). A
ação de encaminhamento indica qual o próximo salto do pacote (Next Hop). O próximo salto
pode se outro roteador, ou o próprio roteador (SELF). O modo SELF é usado quando o
roteador remove o LABEL de topo. Nesse caso, o pacote é re-enviado para pilha IP para que
seja roteador utilizando o endereço IP de destino do pacote.
Além da NHLFE, um roteador LER de ingresso (origem), é configurado através de uma tabela
denominada FEC-to-NHLFE Map (FTN). Essa tabela redireciona pacotes ainda sem LABELs
para uma entrada específica do NHLFE, baseado na FEC.
Ao invés da FTN, um roteador LSR utiliza uma tabela denominada Incoming LABEL Map
(ILM). Essa tabela indica o que fazer com pacotes já com LABELs, que chegam a uma
interface específica do roteador, apontando para a NHLFE. A tabela ILM também é utilizada
no roteador LER de egresso.
Para ilustrar o uso das tabelas, observe o cenário mostrado na parte inferior da figura, onde
um roteador LER de ingresso (LER1) envia pacotes para a FEC1 através do roteador LSR e
do roteador LER de egresso (LER2). A figura mostra também como as tabelas dos roteadores
são configuradas nesse cenário.
Observe que o LER1 possui uma FTN e uma NHLFE e o LSR e o LER3 possuem uma ILM e
uma NHLFE.
11
Distribuição de LABELs
Não Solicitado
10.1/16 – LABEL 10
10.1/16 – LABEL 10
10.2/16 – LABEL 20
1
R3
Rede 10.1/16
FEC
R4
Rede 10.2/16
FEC
2
R1
R2
1
anúncio
10.2/16 – LABEL 10
Solicitado
solicitação
FEC 10.1/16
R3
Rede 10.1/16
FEC
R4
Rede 10.2/16
FEC
1
R1
R2
2
3
10.2/16 – LABEL 20
10.2/16 – LABEL 10
anúncio
Edgard Jamhour
A configuração das tabelas do MPLS pode ser feita de duas formas: manual ou através de um
protocolo de distribuição de LABELs (protocolo de sinalização). A configuração manual
implica em que cada roteador seja acessado individualmente, e pode ser trabalhosa,
principalmente quando ocorrem alterações freqüentes nos LSPs.
Os protocolos de distribuição de LABELs, por sua vez, simplificam muito essa tarefa pois eles
permitem que a configuração de caminhos seja feita de forma automática ou semiautomática. Em uma rede MPLS, a distribuição de LABELs pode ser feita de duas formas: por
demanda ou não-solicitada.
No modo não solicitado, os roteadores de LER de egresso alocam um LABEL para cada rota
(FEC) em sua tabela. Ele anuncia ambos, a rota e o LABEL para todos os roteadores
vizinhos. Quando um roteador vizinho recebe o anúncio, ele repassa adiante, alterando o
valor do LABEL, conforme indicado na parte superior da figura.
No modo solicitado, um roteador LER de ingresso envia uma solicitação para obter um LABEL
para uma determinada FEC. Esse pedido irá se propagar pela rede até chegar a um roteador
LER de egresso que conheça a FEC. A partir desse ponto, é feito o anúncio para a FEC
solicitada, conforme indicado na parte inferior da figura.
Os protocolos de distribuição de LABELs podem operar com ou sem restrições. No modo sem
restrições, não existe diferenciação entre rotas. Geralmente, a rota escolhida para FEC
coincide com a rota de melhor custo determinada pelo protocolo de roteamento.
No modo sem restrições, é possível solicitar uma FEC, mas impondo restrições para o
caminho (como só aceitar enlaces que ainda tenham uma certa quantidade de banda
disponível).
Os protocolos de distribuição de LABELs que já foram definidos para o MPLS são os
seguintes:
Sem restrições: LDP (LABEL Discovery Protocol)
Com restrições: CR-LDP (Constraint-Based Routed LABEL Distributed Protocol)
RSVP-TE (Resource Reservation Protocol-Traffic Engineering)
12
LDP - LABEL Distribution Protocol
ID do LSR
PDU/LDP
msg LDP
header
PDU
Tipos
TLV
opcionais
header
msg LDP
TLV
TLV
100 Fec
101 Address List
103 Hop Count
104 Path Vector
200 Generic Label
201 ATM Label
202 Frame Relay Label
300 Status
301 Extended Status
sub
TLV
sub
TLV
header
TLV
TLV
302 Returned PDU
303 Returned Message
400 Common Hello Parameters.
401 Transport Address
402 Configuration Sequence Number
500 Common Session Parameters
501 ATM Session Parameters
502 Frame Relay Session Parameters
600 Label Request Message ID
Edgard Jamhour
O LDP (Label Distribution Protocol) foi o primeiro protocolo de distribuição de LABELs definido
pelo IETF (Janeiro de 2001).
A estrutura de uma mensagem LDP é definida conforme a figura. Assim como muitos
protocolos modernos, o LDP é formado por várias mensagens distintas, todas elas, com um
cabeçalho fixo e uma quantidade de campos variável. Os campos do LDP carregam uma
série de opções (tipos), definidas através do formato TLV (Tipo -Tamanho - Valor).
O LDP define quatro tipos de mensagens:
1. Discovery messages: HELLO (UDP Multicast)
Anuncia e mantem a presença de um LSR na rede;
2. Session messages: Inicialização de Sessão (TCP)
Estabelece, mantem e termina sessões entre roteadores vizinhos;
3. Advertisement messages: Anúncio de Endereço e Rótulo (TCP)
Cria, muda e termina mapeamentos
4. Notification messages: Notificação de Erro (TCP)
Consulta e sinaliza erros.
O LDP suporta dois métodos de distribuição de rótulos: Downstream por Demanda e
Downstream não Solicitado. O método é escolhido durante a fase de Inicialização de Sessão
(IS) do LDP. Nessa fase, cada roteador informa ao seu vinzinho qual o método desejado. Em
caso de desacordo, a RFC 3036 define que o método será escolhido conforme a tecnologia
do enlace que liga os roteadores, da seguinte forma:
ATM e Frame-Relay: Por Demanda
Outras Tecnologias: Não Solicitado
Os dois modos podem ser combinados em diferentes enlaces de uma nuvem MPLS
13
Tipos de Mensagem LDP
LSR Passivo
(menor ID)
LSR Ativo
(maior ID)
Hello (UDP)
Conexão TCP
Inicialização de Sessão (IS)
(IS) ou notificação de erro
tempo de KA
tamanho max PDU
Keep Alive (KA)
Anúncio de Endereços de Interface
Indica todos os endereços
do LSR
Solicitação de LABEL (LABEL Request)
Anúncio de LABEL (LABEL Mapping)
Remoção de LABEL (LABEL Withdraw)
Liberação de LABEL (LABEL Release)_
Utilizado apenas na
distribuição de rótulos sob
demanda
Controla o mapeamento de
FECs em LABELs
Edgard Jamhour
A figura ilustra uma seqüência típica de estabelecimento de negociação LDP. A descoberta
de nós vizinhos, isto é roteadores LSR com suporte ao MPLS, é feita através de mensagens
HELLO.
Uma vez que um vizinho tenha sido descoberto, o LSR ativo (aquele com o menor ID
recebido na mensagem de HELLO) estabelece uma conexão TCP com seu vizinho passivo.
Após essa fase, os roteadores trocam mensagens de inicialização, que definem qual o modo
de propagação de LABELs desejado (Não Solicitado ou Sob Demanda), a periodicidade das
mensagens Keep Alive e o MTU do enlace.
A mensagem de anúncio de endereços permitem que um roteador conheça os endereços de
toda as interfaces de seu vizinho.
A mensagem de solicitação de LABEL é enviada apenas no modo Sob Demanda.
O LDP define as seguintes mensagens de controle de LABEL:
Anúncio de LABEL: oferece ao vizinho um caminho associado a um FEC
Remoção de LABEL: remove a oferta de LABEL para uma FEC previamente anunciada
Liberação de LABEL: informa ao vizinho que um LABEL previamente solicitado para uma FEC
não é mais necessário.
A mensagem de notificação é utilizada quando ocorrem erros ou eventos adicionais durante a
troca de mensagens entre os LSRs. Exemplos de mensagens de notificação são: TVL
desconhecida para LSRs que não suportam CR-LDP, recursos insuficientes, etc.
14
Downstream Não-solicitado
LABELS
Downstream
LSP p/ FEC 64.12
LER1
LSR2
Oferta para p/ FEC 64.12
com label #150
LABEL de entrada = #20
FEC = 64.12
LABEL de saída = #150
Próx. vizinho = LSR2
LSR3
Oferta para FEC 64.12 com
label #100
LABEL de entrada = #150
FEC = 64.12
Rótulo de saída = #100
Próx. vizinho = LSR3
LABEL de entrada = #100
FEC = 64.12
LABEL de saída = #134
Próx. vizinho = LSR4
Upstream
DADOS
Edgard Jamhour
A figura ilustra o funcionamento de uma distribuição de LABELs no modo Downstream Não
Solicitado. O termo "Downstream" indica transmissão no sentido do LER de ingresso e
"Upstream" no sentido do LER de egresso. Observe que os dados são sempre transmitidos
no sentido Upstream e os LABELs se propagam no sentido Downstream.
No modo não solicitado, os roteadores fazem ofertas de caminho para todas as FEC que
conhecem para todos os seus vizinhos. Observe que um roteador pode conhecer a rota para
uma FEC em duas situações:
1) Porque está conectado diretamente a ela
2) Porque recebeu uma oferta de um roteador vizinho
O modo não solicitado não é útil para aplicações de engenharia de tráfego (isto é, quando se
deseja distribuir a carga por vários caminhos alternativos na rede). Sua função principal é
substituir o método de roteamento baseado puramente no endereço IP de destino pelo
roteamento baseado em LABELs, considerado mais eficiente.
Com a criação dos protocolos de suporte distribuição de LABELs com restrições, esse
método tornou-se pouco utilizado.
15
Downstream Sob Demanda
LABELS
Downstream
LSP p/ FEC 64.12
Requisição de atribuição para 64.12
LER1
Requisição de atribuição para 64.12
LSR2
Atribuição de label #150 p/
FEC 64.12
LABEL de entrada = #20
FEC = 64.12
LABEL de saída = #150
Próx. vizinho = LSR2
LSR3
Atribuição de label #100 p/
FEC 64.12
LABEL de entrada = #150
FEC = 64.12
LABEL de saída = #100
Próx. vizinho = LSR3
LABEL de entrada = #100
FEC = 64.12
LABEL de saída = #134
Próx. vizinho = LSR4
Upstream
DADOS
Edgard Jamhour
A figura ilustra o funcionamento de uma distribuição de LABELs no modo Downstream Sob
Demanda.
No modo sob demanda, um roteador LER de ingresso faz a solicitação de um LABEL para
uma determinada FEC enviando uma mensagem de solicitação de LABEL para o(s) seu(s)
vizinho(s), no sentido Upstream.
Quando um LSR recebe a solicitação, se ele conhecer a FEC, ele responde imediatamente.
Caso contrário, ele repassa a solicitação a seus vizinho. Quando a solicitação encontra um
roteador que conhece a FEC, um anúncio de LABEL é feito no sentido Downstream, apenas
para o roteador que fez a solicitação. O anúncio se propaga até atingir o LABEL de ingresso.
16
Combinando formas de Distribuição
Solicitação de LABEL para FEC
LER1
Solicitação de LABEL para FEC
LSR3
LSR2
Anúncio Solicitado
LABEL 3 para FEC
Anúncio Solicitado
LABEL 4 para FEC
Anúncio não solicitado
LABEL 2
FEC
LSR5
LSP p/ FEC
LSR4
Anúncio não solicitado
LABEL 1
Edgard Jamhour
Os métodos de distribuição de LABELS não solicitado e por demanda podem ser combinados
em uma mesma rede, pois a escolha do método é feita para roteadores vizinhos. Dessa
forma, um roteador pode ter um acordo de distribuição de LABELs pelo método não solicitado
com um vizinho, e com outro vizinho um acordo de distribuição de LABELs sob demanda.
A figura ilustra esse conceito. Observe que há um acordo de anúncio não solicitado entre os
roteadores LSR5 e LSR4, assim como entre os roteadores LSR4 e LSR4. Entre os roteadores
LSR3 e LSR2 o acordo é no modo solicitado, assim como entre os roteadores LSR2 e o
LER1.
Em uma situação inicial, o roteador LSR5 fará o anúncio de sua FEC conhecida para seu
vizinho LSR4 que, por sua vez, propagara esse anúncio para o LSR3. Contudo o LSR3 não
propagará o anúncio adiante.
Quando o LER1 desejar obter um LABEL, ele fará a solicitação ao LSR2, que por não
conhecer a FEC solicitada, repassará o pedido para o LSR3. Como o LSR3 já conhece a
FEC, ele responde ao LSR2 sem repassar o pedido aos demais roteadores.
17
CR-LDP - Constraint-Based LDP
ID do LSR
PDU/LDP
msg LDP
header
PDU
Tipos
TLV
adicionais
header
msg LDP
TLV
TLV
sub
TLV
821 LSPID
822 ResCls
503 Optical Session Parameters
800 Explicit Route
801-804 ER-Hop TLVS
810 Traffic Parameters
sub
TLV
header
TLV
TLV
820 Preemption
823 Route Pinning
910 Optical Interface Type
920 Optical Trail Desc
930 Optical Label
940 Lambada Set
Edgard Jamhour
O LDP foi o primeiro protocolo de distribuição de LABELs para o MPLS e não suporta
restrições. Quando o MPLS passou a ser visto como uma solução de engenharia de tráfego
(TE), e não apenas um método para acelerar o roteamento, novos protocolos com suporte a
restrições precisaram ser desenvolvidos.
O IETF definiu que a fim de suportar a engenharia de tráfego, esses novos protocolos
deveriam ser capazes de:
a) Definir um LSP distinto do sugerido pelo OSPF
b) Fazer reserva dinâmica de recursos junto com o estabelecimento do LSP
c) Distribuir o tráfego por LSPs paralelos
d) Criar e Remover dinamicamente LSPs conforme as necessidades da rede
e) Tratar falhas pela migração de tráfego entre LSPs altenativos e criação de LSPs backups
ou de espera.
f) Suportar rotas explícitas
g) Fazer controle de admissão para solicitação (a criação do LSP é negada caso não haja
recursos suficientes)
h) Fazer priorização de LSPs e preempção
Um desses protocolos foi denominado foi denominado CR-LDP, definido pela RFC 3212 de
janeiro de 2002. O CR-LDP é baseado na adição de TLVs nas mensagens LDP existentes.
As principais características do CR_LDP são as seguintes:
a) Criação de LSPs fim-a-fim sob restrições, utilizando o modo Downstream por demanda. As
restrições são impostas pelo LSR de ingresso, e os LABELs são distribuídos a partir do LSR
de egresso.
b) Prioridades podem ser atribuídas para as LSPs para suportar o esquema de preempção.
c) Re-roteamento ou não em caso de falha.
d) Suporte a duas classes de restrições: Rotas Explícitas e Parâmetros de Tráfego
18
Restrição por Roteamento Explícito
Requisição de LABEL com
Rota Explicita: 2, 3, 5
LER1
Requisição de LABEL com
Rota Explícita: 3, 5
LSR2
Anuncia o LABEL 30
LSR3
Anuncia o LABEL 20
Requisição de LABEL
com Rota Explícita: 5
Anuncia o LABEL 10
LSR4
* (estrito)
+ (flexível)
A*:B*:D*:E*:G* A
A*:F+:G*
E
B
LSP
G
D
C
LSR5
F
Edgard Jamhour
Quando um LER de ingresso faz a solicitação de um LABEL para uma determinada FEC ele
pode escolher de forma parcial ou absoluta o caminho até a FEC de destino utilizando as
restrições do tipo Rota Explícita.
O CR-LDP permite que a rota seja explicitada por endereços IPv4, IPv6, SAs ou
identificadores de LSR. Uma rota explícita é definida como uma seqüência de nós abstratos,
onde um nó abstrato é formado por um ou mais LSRs. A rota deve passar por pelo menos um
LSR do nó abstrato.
São definidos dois tipos de nós abstratos:
Estrito: Nenhum nó não especificado pode ser inserido entre o nó estrito e o nó anterior.
Flexível: A passagem pelo nó é obrigatória, mas ela pode ser feita inserindo-se nós não
especificados entre o nó flexível e o nós precedentes da rota.
19
Restrição por Parâmetros de Tráfego
Requisição de LABEL com
Tráfego Prometido e Serviço
Desejado
LER1
Requisição de LABEL com
Tráfego Prometido e Serviço
Desejado
LSR2
Anuncia o LABEL 30
LSR3
Anuncia o LABEL 20
Requisição de LABEL com
Tráfego Prometido e
Serviço Desejado
Anuncia o LABEL 10
LSR4
LSR5
LSP
Edgard Jamhour
O segundo tipo de restrição suportado pelo CR-LDP é baseado em parâmetros de tráfego.
Nesse tipo de restrição, quando o LER faz a solicitação de um LABEL para uma data FEC ele
inclui dois conjuntos de informações: Trafego Prometido e Serviço Desejado. O tráfego
transmitido é uma descrição daquilo que será enviado através do LSP.
O Tráfego Prometido é descrito na forma de dois parâmetros:
PDR (Peak Data Rate): taxa de pico de transmissão de dados (bytes por segundo)
PBS (Peak Burst Size): tamanho da rajada na taxa de pico (em bytes)
O Serviço Desejado é definido por três parâmetros:
CDR (Commited Data Rate): taxa média solicitada (bytes por segundo)
EBS (Commited Burst Size): tamanho da rajada garantida (bytes)
EBS (Excess Burst Size): tamanho da rajada permitida em momentos de pouco
congestionamento, mas não garantida em outros momentos (bytes).
A mensagem de requisição de LABEL inclui ainda as seguintes informações complementares:
Freqüência de Amostragem: Quando se solicita uma garantida de taxa média (CDR), é
necessário especificar sobre qual período a taxa média será amostrada. Os valores possíveis
são:
Muito freqüente: CDR garantido para quaisquer 2 pacotes
Freqüente: CDR garantido para uma média de poucos pacotes pequenos
Não Especificado: Uso de uma intervalo razoável (i.e., 1 segundo)
Peso: Indica a capacidade do LSR de utilizar recursos disponíveis de outros LSRs para
transporte de tráfego excedente. O LSR com maior peso tem prioridade sobre os LSRs de
menor peso:
Valor de 1 a 255
Flag de Negociação: A TLV de parâmetros de tráfego define um campo flag (1 byte), para
indicar quais itens do pedido podem ser re-negociados, caso não haja recursos na rede para
atender ao pedido inicial:
bit 0: reservado; bit 1: reservado; bit 2: PDR; bit 3: PBS; bit 4: CDR; bit 5: CBS; bit 6: EBS; bit
7: Peso
20
Fluxo de Mensagens: CR-LDP
A
C
B
1
LABEL
Request
[Trafego]
[Flag Neg.]
Notification
LABEL
Mapping
[Mínimo]
7 LABEL
Release
2
2*
6
LABEL
Request
[Reduzido]
Notification
LABEL
Mapping
[Mínimo]
8 LABEL
Release
D
LABEL
3 Request
[Reduzido]
3*
5
LABEL
Mapping
[Mínimo]
4
9 LABEL
Release
Edgard Jamhour
A figura ilustra uma seqüência típica de mensagens trocadas segundo o protocolo CR-LDP.
1) O LSR A (ingresso) envia a mensagem de LABEL Request com a TLV de parâmetros de
tráfego, indicando os itens negociáveis.
2) Se houver recursos suficientes, o LSR B efetua a reserva e repassa a mensagem adiante.
Se não houver recursos suficientes, mas houverem parâmetros negociáveis, o LSR B faz uma
reserva menor e repassa o pedido alterado para frente.
2*) Se o LSR B não tiver recursos e não houver itens renegociáveis, ele notifica a falha para o
LSR A
3) O LSR C executa o mesmo procedimento que o LSR B, podendo novamente, encaminhar
uma mensagem de LABEL Request modificada, com menos recursos que os recebidos do
LSR B.
3*) Caso o LSR C não tenha recursos para efetuar a reserva, ele encaminha uma mensagem
de notificação para B, fazendo com que ele libere os recursos previamente alocados.
4) O LSR D (egresso) envia uma mensagem de LABEL Mapping, que ecoa os parâmetros de
tráfego (que são os menores ao longo do caminho).
5) O LSR C ao receber a mensagem atualiza sua reserva, e repassa a mensagem ao LSR B
alterando apenas o valor do LABEL.
6) O LSR B também atualiza sua reserva e repassa a mensagem de LABEL Mapping ao nó
de ingresso.
7) Ao receber a mensagem de LABEL Mapping, o nó de ingresso decide se os parâmetros
alocados são suficientes. Se não forem, ele envia uma mensagem de LABEL Release, que irá
se propagar até o nó de egresso.
21
Preempção
A nova demanda irá derrubar o caminho vermelho
50 Mbps
Configuração 2
50 Mbps
Retenção 3
100 Mbps
2
1
100Mbps
50 Mbps
Retenção 2
100Mbps
3
4
200.0.0.128/25
200.0.0.0/24
200.0.0.0/25
100Mbps
100Mbps
100Mbps
5
Edgard Jamhour
A fim de suportar o mecanismo de preempção (tomada de recursos de LSR sobre outro já
estabelecido), uma prioridade deve ser associada a cada LSR. O mecanismo de preempção
adotado pelo CR-LDP define dois parâmetros de prioridade:
prioridade de retenção: prioridade em reter recursos
prioridade de configuração: prioridade para tomar recursos
Dessa forma, caso não exista recursos suficientes para atender ao pedido de criação de um
novo LSR, um LSP menos prioritário pode ser terminado, a fim de liberar recursos na rede.
Isso é feito se:
prioridade de configuração do novo LSR > prioridade de retenção do LSR já estabelecido
O exemplo da figura ilustra nesse conceito. Observe que a rede já possui dois LSRs
estabelecidos: em vermelho (com Retenção=2) e em azul (com Retenção=3). Suponha que a
rede tenha recebido o pedido para criação de um novo LSR em verde a partir do roteador 1.
Como não existem recursos disponíveis para atender o pedido, um dos LSRs já estabelecidos
precisa ser desfeito. Nesse caso, o LSR vermelho será desfeito pois sua prioridade de
retenção é inferior ao do novo caminho.
22
RSVP-TE (RSVP Traffic Extension)
• O RSVP-TE reutiliza todas as sete mensagens RSVP:
–
–
–
–
–
–
–
Path: pedido de reserva (ingresso)
Resv: confirmação de reserva (egresso)
ResvConf: confirmação pelo ingresso
ResvTear: desistência pelo egresso
ResvErr: notificação de erro ao receber pedido de reserva
PathErr: notificação de erro ao receber medido de path
PathTear: desistência pelo ingresso
PDU/RSVP-TE
header PDU
Tipo de
Mensagem
Objeto
Objeto
Objeto
Objeto
Edgard Jamhour
O segundo protocolo de distribuição de LABELs com restrições definido para o MPLS é o
RSVP-TE, definido pela RFC 3209 de dezembro de 2001.
O RSVP-TE (Resource Reservation Protocol - Traffic Extension) é baseado no RSVP,
definido para a metodologia de QoS denominada serviços integrados. O RSVP permite fazer
reservas fim-fim para fluxos de tráfego individuais, mas não possui recursos para distribuição
de LABELS. No RSVP-TE as mensagens foram expandidas para suportar distribuição de
LABELs e outros recursos previstos para um protocolo de sinalização para o MPLS. As
modificações foram:
a) Suporte ao gerenciamento de LABELs: Objetos "LABEL Request" na mensagem Path e
"LABEL" na mensagem Resv
b) Dois novos tipos de classe de serviço: IPv4 LSP Tunnel, IPv6 LSP Tunnel, em adição aos
serviços existentes: Carga Controlada (cria caminho sem reserva) e Serviço Garantido (cria
caminho com reserva).
c) Suporte a Requisição e Registro de Rotas Explícitas: Objetos "Rota Explícita" na
mensagem Path e "Registro de Rota" nas mensagens Path e Resv [Opcional]
d) Suporte a preempção: Objeto "Atributo de Sessão" inclui as prioridades na mensagem Path
e) Manutenção de conectividade entre LSRs: Além dos objetos incluídos nas mensagens já
existentes, uma nova mensagem denominada Hello para a ser trocada entre LSRs adjacentes
23
Criação de um LSP com RSVP-TE
1. Path. Define a FEC de
destino e restrições de
caminho <2,3,4> e recursos
LER1
2. Path propagada para o
próximo Nó
LSR2
LSR3
FEC
LER4
LSP
5. Resv com a
informação do Rótulo 3
4. Resv com a informação
do Rótulo 2
3. Resv com a informação do
Rótulo 1
Edgard Jamhour
O RSVP-TE utiliza duas mensagens Principais:
Path: Solicita um LABEL para uma FEC, incluindo restrições como Rota explícita e banda
requisitada ao longo do caminho
RESV: Enviada do receptor para o transmissor. Anuncia o LABEL caso a reserva possa ser
atendida. Além do LABEL, a mensagem RESV contém os seguintes parâmetros:
Flow Spec: Especifica a reserva desejada
Service Class: Serviço Garantido ou Carga Controlada
Tspec: requisitos do transmissor
Rspec: taxa de transmissão solicitada
Filter Spec: identifica os pacotes que devem de beneficiar da reserva
Protocolo de transporte e número de porta.
Um reserva em RSVP é caracterizada por uma estrutura de dados denominada
Flowspec.
Flowspec é composta por dois elementos:
Rspec (Reserve Spec):
indica a classe de serviço desejada.
Tspec (Traffic Spec):
indica o que será Transmitido.
OBS. Rspec e Tspec são definidas na RFC 2210 e são opacos para o RSVP.
Serviço de Carga Controlada (RFC 2211). Rspec não é especificado, apenas Tspec. Não é
feita reserva de banda. Os dispositivos evitam a deterioração das condições da rede limitando
o tráfego das aplicações. Limite (num intervalo T): < rT +b (bytes)
Serviço Garantido (RFC 2212): RSpec e TSpec são especificados. É feita reserva de banda.
24
O Token Bucket Model
saída
(bytes/s)
d <= b/p
r bytes/s
p
r
R
b bytes
t
reserva
chegada
saída
R
p bytes/s
Serviço
Garantido se
r <= R
B
Edgard Jamhour
O modelo utilizado pelo RSVP-TE é o Token Bucket. Este modelo é um método para definir
uma taxa de transmissão variável com atraso limitado. Os parâmetros do Token Bucket são
transmitidos através do objeto Tspec, e são definidos da seguinte forma:
r - taxa média em bytes/s
Taxa de longo prazo: 1 a 40 terabytes/s
b - tamanho do bucket (em bytes)
Taxa momentânea: 1 a 250 gigabytes
p - taxa de pico
m - tamanho mínimo do pacote
(pacotes menores que esse valor são contados como m bytes)
M - MTU (tamanho máximo do pacote)
Regra: seja T o tráfego total pelo fluxo num período T:
T < rT + b
Assumindo o Token Bucket Model, Rspec é definido da seguinte forma:
R - taxa desejável
Taxa média solicitada
s - Saldo (slack) de retardo
Valor excedente de atraso que pode ser utilizado pelos nós intermediários.
Ele corresponde a diferença entre o atraso garantido se a banda R for reservada e o
atraso realmente necessário, especificado pela aplicação.
25
Mensagens PATH e RESV
PATH
Session
Ingress
Service: IPv4-LSP
Destination: 10.0.1.7
Setup Prio 7
Hold Prio 7
Label
Request
Tspec
62500 bps
Explicit
Route
10.0.7.33,
10.0.1.7
Egress
RESV
Flow Spec
Filter Spec
Service Class
IP origem
Rspec
Porta origem
ou
Flow LABEL
Ingress
Tspec
....
LABEL
Egress
Edgard Jamhour
Um exemplo de mensagens PATH e RESV é mostrado a seguir:
Resource ReserVation Protocol (RSVP): PATH Message.
RSVP Header. PATH Message.
SESSION: IPv4-LSP, Destination 10.0.1.7, Tunnel ID 0, Ext ID a000103.
HOP: IPv4, 10.0.7.34
TIME VALUES: 30000 ms
EXPLICIT ROUTE: IPv4 10.0.7.33, IPv4 10.0.1.7
LABEL REQUEST: Basic: L3PID: IP (0x0800)
SESSION ATTRIBUTE: SetupPrio 7, HoldPrio 7, SE Style, [C1_t0]
SENDER TEMPLATE: IPv4-LSP, Tunnel Source: 10.0.1.3, LSP ID: 13.
SENDER TSPEC: IntServ: Token Bucket, 62500 bytes/sec.
ADSPEC
Resource ReserVation Protocol (RSVP): RESV Message.
RSVP Header. RESV Message.
SESSION: IPv4-LSP, Destination 10.0.1.7, Tunnel ID 0, Ext ID a000103.
HOP: IPv4, 10.0.7.33
TIME VALUES: 30000 ms
STYLE: Shared-Explicit (18)
FLOWSPEC: Controlled Load: Token Bucket, 62500 bytes/sec.
FILTERSPEC: IPv4-LSP, Tunnel Source: 10.0.1.3, LSP ID: 13.
LABEL: 0
26
Conclusão
• MPLS oferece a possibilidade de múltiplas rotas para o mesmo destino
• A definição dos caminhos pode ser feita de forma manual ou automática
• No modo automático utiliza-se protocolos de distribuição de LABELs.
• Dois protocolos são usados atualmente:
– CR-LDP
– RSVP-TE (Preferido pelo IETF)
Edgard Jamhour
O IETF desencoraja a utilização do CR-LDP, sendo que o protocolo é considerado apenas um
padrão proposto. Grandes fornecedores, como a Cisco e a Juniper utilizam o RSVP-TE. As
vantagens do RSVP-TE sobre o CR-LDP, que justificam essa posição pelo IETF são as
seguintes:
O RSVP-TE funciona sobre IP puro e não sobre TCP (como o CRLDP). Isso torna o protocolo
mais eficiente e consome menos recursos do roteador.
O CRLDP é um protocolo de estado rígido, o qual é mantido pelas conexões TCP. Um
protocolo de estado rígido pode manter reservas desnecessárias, pois é preciso enviar
mensagens explícitas de encerramento das reservas. O RSVP-TE, por outro lado, é um
protocolo de estado flexível. Em um protocolo de estado flexível, o estado se mantém apenas
se for renovado periodicamente. Caso a renovação falhe, o estado é removido, evitando o
desperdício de recursos da rede.
Apenas o RSVP-TE permite o compartilhamento de recursos (criação de LSPs sobre
caminhos existentes). O compartilhamento de recursos é importante para suportar a reserva
em comunicações do tipo ponto-multiponto (multicast).