Você está na página 1de 5

ENGENHARIA DE TRFEGO NAS REDES MPLS: UMA ANLISE

COMPARATIVA DE SEU DESEMPENHO EM FUNO DE SUAS


DIFERENTES IMPLEMENTAES
Edson Josias Cruz Gimenez 1, Rodrigo Ramos Vieira 2, Maximiliano Jos Sales Cardoso 3,
Guilherme Alexandre Ferrari 4
Abstract The convergence of services and technologies in
the modern networks shows itself as a trend of
telecommunications market. Offering more solutions
efficient that adds security, facilities and quality of services
in real time, has become a challenge to the networks
designers. Supporting this new demand is necessary the
implantation of an efficient and transparent technology
through the backbone, which permits the convergence of
diversity protocols and technologies and increase the quality
over it, as the traffic engineering over the MPLS
Multiprotocol Label Switching.
The mainly subject of this paper is analysis of the MPLS
architecture and its different implementation to traffic
engineering standards by IETF (Internet Engineering Task
Force), CR-LDP and the RSVP-TE, comparing and pointing
its principal differences.
Index Terms Engenharia de Trfego, CR-LDP, MPLS,
RSVP-TE.

INTRODUO
A utilizao do MPLS tem apresentado uma rpida expanso
devido s facilidades de agregao de servios rede,
possibilitando implementar de forma relativamente simples
servios tais como QoS (Quality of Service), VPNs (Virtual
Privates Networks) e engenharia de trfego. Estas solues
no so novas e nem exclusivas do MPLS, vrias outras
propostas foram desenvolvidas com o intuito de agregar
qualidade de servio rede tais como as arquiteturas Intserv
e Diffserv em um ambiente IP clssico.
O MPLS baseado no esforo, principalmente do setor
privado, para criao e padronizao do ento novo
paradigma, a comutao IP.
A engenharia de trfego um dos maiores benefcios
que o MPLS prov. Este termo refere-se habilidade para
controlar o fluxo de trfego na rede, com o objetivo de
reduzir problemas de congestionamento e conseguir um
melhor uso dos recursos disponveis. A soluo para o
problema na engenharia de trfego consiste no fato de que
rtulos e caminhos de comutao baseados em rtulos

podem ser estabelecidos por uma variedade de mdulos de


controle.
Para o estabelecimento dessas rotas deve ser utilizado
um conjunto de protocolos adequados para encontrar e
reservar recursos necessrios para, por exemplo, garantia de
QoS para um servio.
O IETF MPLS Working Group, primeiramente, lanou
duas propostas para sinalizao do mecanismo de
distribuio de rtulos, para implementao de rotas
explicitas com o objetivo de otimiz-las, sendo elas o CRLDP (Constraint Based Routed - Label Distribution
Protocol), descrito em [7], e o RSVP-TE (Resource
Reservation Protocol Traffic Engineering), descrito em
[6]. Este trabalho, atravs das resolues do IETF MPLS
Working Group, busca a anlise destes protocolos de
sinalizao, objetivando algumas de suas semelhanas e
diferenas.

O PROTOCOLO MPLS
Protocolo desenvolvido pelo IETF (Internet Engineering
Task Force), tem sua arquitetura descrita em [3], procurando
padronizar os diversos estudos a respeito da comutao IP.
Por comutao IP pode-se entender como a capacidade de
encaminhar pacotes IP sem a necessidade de analisar seu
cabealho de camada de rede a cada hop, possibilitando
assim uma otimizao da rede, eliminao de redundncias
no plano de controle e menor processamento de pacotes.
O LER (Label Edge Router) o equipamento
responsvel por inserir e remover rtulos nos pacotes,
tomando como base critrios como endereo de destino,
engenharia de trfego, multicast, VPN, portas, etc. Estes
rtulos so atribudos a uma FEC (Forwarding Equivalence
Class), sendo que os pacotes atribudos a uma mesma FEC
recebem o mesmo tratamento. Quando um pacote rotulado
chega a um LSR (Label Switching Router), o rtulo
analisado e ento trocado por um rtulo apropriado de sada
e, por fim, o pacote enviado para o prximo hop.
A comutao por rtulos um esquema j utilizado por
algumas tecnologias, como por exemplo, o ATM
(Asynchronous Transfer Mode), que usa a mesma tcnica
para enviar clulas por um caminho virtual atravs dos

1 Edson Josias Cruz Gimenez, INATEL, Av. Joo de Camargo, 510, 37540-000, Santa Rita do Sapucai, MG, Brazil, edsonjcg@inatel.br
2 Rodrigo Ramos Vieira, INATEL, Av. Joo de Camargo, 510, 37540-000, Santa Rita do Sapucai, MG, Brazil, rodrigovieira@inatel.br
3 Maximiliano Jos Sales Cardoso, INATEL, Av. Joo de Camargo, 510, 37540-000, Santa Rita do Sapucai, MG, Brazil, max@inatel.br
4 Guilherme Alexandre Ferrari , INATEL, Av. Joo de Camargo, 510, 37540-000, Santa Rita do Sapucai, MG, Brazil, rodrigovieira@inatel.br

2006 WCCSETE

March 19 - 22, 2006, So Paulo, BRAZIL


World Congress on Computer Science, Engineering and Technology Education
570

campos de identificao VPI (Virtual Path Identifiers) / VCI


(Virtual Channel Identifiers).
O rtulo um cabealho de encalo (shim header),
inserido entre os cabealhos de camada de enlace e camada
de rede (quando trabalhamos em um ambiente de pacotes),
como ilustrado na Figura 1, e seu modelo segue a
recomendao do IETF como mostrado na Figura 2.

anteriormente ao encaminhamento MPLS, ou seja, trata-se


de um protocolo orientado a conexo. A criao deste
caminho virtual definida pela sinalizao MPLS com base
em protocolos auxiliares ou configuraes manuais.
Ao deixar o domnio MPLS, o pacote enviado para um
domnio externo com seu devido protocolo de camada de
rede (para um ambiente de pacotes). Este processo consiste
em remover o rtulo do cabealho do pacote enviando este
ao protocolo de nvel trs apropriado para tratamentos
adicionais e seu encaminhamento fora do domnio MPLS.

ENGENHARIA DE TRFEGO
FIGURA 1
POSICIONAMENTO DO RTULO ENTRE CAMADAS

FIGURA 2
FORMATO DO RTULO MPLS

O campo Label contm o valor deste.


O campo EXP define a classe de servio a que um
pacote pertence, indicando assim a prioridade do pacote.
O campo S (stack) suporta o enfileiramento de rtulos.
Ser utilizado quando o pacote receber mais de um
rtulo.
O campo TTL (Time to Live) tem aqui a mesma funo
que no datagrama IP, determinar o numero mximo de
hops.

Quando o plano de controle do MPLS opera em uma


rede ATM, somente os campos VPI /VCI so alterados, no
sendo necessria a incluso de um rtulo, como ilustra a
Figura 3.

FIGURA 3
MAPEAMENTO ATM UTILIZANDO O PLANO DE CONTROLE MPLS.

O pacote rotulado deve ser capaz de atravessar um LSP


(Label Switched Path) sendo esse um caminho configurado

2006 WCCSETE

Pode-se definir engenharia de trfego como o processo de


organizao do trfego que flui atravs da rede para evitar
congestionamentos causados por uma utilizao desigual da
rede. Um dos maiores objetivos da engenharia de trfego
fazer com que a operao de troca de dados na rede seja
eficiente e confivel enquanto h uma otimizao de seu
desempenho.
Devido ao alto custo dos equipamentos e das
necessidades atuais do mercado, a engenharia de trfego j
considerada fundamental em redes de grande porte, onde a
qualidade de servio tem se tornado cada vez mais
necessria. importante perceber que a engenharia de
trfego no necessariamente tomar o caminho mais curto
entre os dois equipamentos e que tambm dois fluxos de
pacotes originados de um mesmo n e que tambm possuam
como destino um mesmo n, sigam caminhos diferentes se,
por exemplo, estes possurem requisitos de QoS diferentes.

MPLS-TE - MULTIPROTOCOL LABEL


SWITCHING - TRAFFIC ENGINEERING
O roteamento convencional baseado em algoritmos IGP
(Interior Gateway Protocol), no proporciona uma
distribuio de forma balanceada do trfego, ou seja, alguns
recursos podem ser subutilizados enquanto outros podem
sofrer com cargas excessivas de trfego.
Um indicador limitado sobre engenharia de trfego pode
ser fornecido manipulando as mtricas do IGP associadas
com os enlaces da rede, entretanto estas informaes so
complicadas de administrar em ambientes com vrias opes
de encaminhamento entre dois pontos.
As mtricas determinadas pelos protocolos de
roteamento de estado de enlace e a forma como so
manipuladas no domnio MPLS so relativamente diferentes
de, por exemplo, as usadas em servios integrados (Intserv)
em uma rede IP tradicional. Com o caminho calculado pelas
mtricas do IGP em questo, torna-se necessrio a
sinalizao para implement-lo.
Duas possveis solues foram desenvolvidas pelo IETF
MPLS Working Group: o CR-LDP e o RSVP-TE.
interessante observar que, conforme publicado em [4], o
IETF MPLS Working Group decidiu abandonar os trabalhos
focados no desenvolvimento do CR-LDP a fim de

March 19 - 22, 2006, So Paulo, BRAZIL


World Congress on Computer Science, Engineering and Technology Education
571

concentrar esforos no protocolo RSVP-TE como o


protocolo de sinalizao para aplicaes de Engenharia de
Trfego com MPLS. Como o carter de nossa pesquisa
possui cunho acadmico, trataremos aqui das diferenas
entre essas duas implementaes.

CR-LDP CONSTRAINT BASED ROUTED LABEL DISTRIBUTION PROTOCOL


O CR-LDP construdo sobre o LDP, que j parte do
MPLS. Embora seus estudos pelo IETF MPLS Working
Group tenham sido abandonados, este possui resultados
satisfatrios e no precisa da implementao de um novo
protocolo, o que aumenta a carga de processamento, como o
preterido RSVP-TE.
Assim como o LDP, o CR-LDP usa um esquema de
codificao denominado TLV (Type-Length-Value). Trata-se
de mensagens passadas atravs da rede, que esto divididas
em trs campos bsicos. O campo type define o tipo de
mensagem; o campo length especifica o comprimento do
campo seguinte (value) em bytes; o campo value, de
tamanho length, codifica a informao que ser interpretada
de acordo com o campo type e a manipulao desses campos
se fazem como necessrio para implementar engenharia de
trfego no domnio MPLS.
O CR-LDP suporta roteamento explcito tipo strict, o
caminho completo a ser seguido fixo, e tambm o
roteamento explicito loose, onde somente alguns roteadores
so ns fixos em um caminho.
Utiliza o protocolo UDP (User Datagram Protocol)
para descobrir novos pontos em um domnio MPLS e TCP
(Transfer Control Protocol) para realizao de controle,
gerncia, label request e label mapping.
A sinalizao usando o CR-LDP descrita
resumidamente a seguir e ilustrada na Figura 4.

O LSR A constri uma mensagem de label request para


determinao da rota explicita e tambm com detalhes dos
parmetros de trfego requeridos para a nova rota. Ento, o
LSR A reserva os recursos requeridos para este novo LSP e
encaminha para o LSR B a mensagem de label request em
uma sesso TCP.
O LSR B recebe esta mensagem e percebe que no o
equipamento de egresso para este LSP, ento, caso possvel,
o LSR B reserva os recursos pedidos para o novo LSP,
modifica a informao para o roteamento explicito na
mensagem de label request e a encaminha para o LSR C.
O LSR C percebe que o equipamento de egresso para
o novo LSP, realiza as reservas de recursos requeridas, caso
possvel. Este ento aloca um rtulo para este novo LSP e
distribui o rtulo para o LSR B atravs de uma mensagem de
label mapping, que contm detalhes finais sobre os
parmetros reservados para o LSP. O LSR B recebe a
mensagem, finaliza a reserva, atualiza as tabelas
correspondentes e passa para o LSR A um novo rtulo
atravs me uma mensagem de label mapping.
Finalmente, no LSR A, processamento semelhante
ocorre para criao deste LSP, menos o processo para o
envio de mensagens para designao de rtulos, j que este
se trata do LSR de ingresso para este LSP.

RSVP-TE - RESOURCE RESERVATION


PROTOCOL -TRAFFIC ENGINEERING
Criado inicialmente para aplicaes em servios integrados
(Intserv) pelo IETF, o RSVP foi desenvolvido para ser um
mecanismo de sinalizao com o objetivo de reservar
recursos atravs de uma rede, permitindo a um host
especificar uma determinada requisio de servio para um
certo fluxo na rede.
As extenses do RSVP para engenharia de trfego
propiciaram uma excelente adequao deste para a
distribuio de rtulos MPLS, de forma otimizada.
Desde fevereiro de 2003, o IETF MPLS Working
Group, conforme [4], passou a concentrar seus esforos no
RSVP-TE para sinalizao e estabelecimento de rotas em
um ambiente MPLS.
O processo de sinalizao usando o RSVP-TE
bastante parecido quele com o uso do CR-LDP, e
mostrado de forma resumida abaixo, sendo ilustrado na
Figura 5.

FIGURA 4
SINALIZAO CR-LDP

O LSR A (Ingresso), determina que necessrio criar


um novo LSP para o LSR C. Os parmetros de trfego
requeridos para o encaminhamento ou polticas
administrativas para a rede determinam ao LSR A para
determinar um novo LSP atravs do LSR B, lembrando que
o numero de hops at o destino no fator determinante para
sua designao.

FIGURA 5
SINALIZAO RSVP-TE

2006 WCCSETE

March 19 - 22, 2006, So Paulo, BRAZIL


World Congress on Computer Science, Engineering and Technology Education
572

No processo utilizando o CR-LDP, o LSR A (Ingresso)


tem a funo de criar um LSP at LSR C. Os parmetros de
trfego requeridos para o encaminhamento ou polticas
administrativas para a rede indicam ao LSR A para
determinar um novo LSP atravs do LSR B. importante
ressaltar que a menor distancia no fator determinante para
escolha desta rota. O LSR A cria uma mensagem Path para
determinao da rota explicita e tambm com detalhes dos
parmetros de trfego requeridos para a nova rota. Ento, o
LSR A reserva os recursos requeridos para este novo LSP e
encaminha para o LSR B a mensagem Path em um
datagrama IP.
O LSR B recebe esta mensagem e percebe que no o
equipamento de egresso para este LSP. Ento, caso possvel,
o LSR B reserva os recursos pedidos para o novo LSP,
modifica a informao para o roteamento explicito na
mensagem Path e a encaminha para o LSR C. O LSR C
percebe que o equipamento de egresso para o novo LSP.
Ele realiza as reservas de recursos requeridas, caso possvel.
Este ento aloca um rtulo para este novo LSP e distribui o
rtulo para o LSR B atravs de uma mensagem Resv, que
contem detalhes finais sobre os parmetros reservados para o
LSP. O LSR B recebe a mensagem, finaliza a reserva,
atualiza as tabelas correspondentes e passa para o LSR A um
novo rtulo atravs de uma mensagem Resv, e assim, como
quando utilizamos o CR-LDP, o LSR A reserva os recursos
necessrios e no aloca ou encaminha para um LSR
ascendentes (upstream) um novo rtulo j que este o LSR
de ingresso, finalizando assim o este LSP.

COMPARAO ENTRE O CR-LDP E O


RSVP-TE
As semelhanas entre os protocolos CR-LDP e RSVP-TE
so inmeras quando se trata do contedo das mensagens.
Basicamente o contedo o mesmo, exceto por alguns
pequenos detalhes. Ambos transportam as mesmas
informaes para o estabelecimento das rotas.
A principal diferena no funcionamento dos protocolos
se deve s implicaes decorrentes do RSVP-TE ser softstate, enquanto o CR-LDP hard-state. O fato do RSVP-TE
ser soft-state proporciona um overhead o que requere que
mensagens de refresh sejam enviadas periodicamente entre
cada n da rede para manuteno de um LSP.
Algumas alteraes foram propostas para solucionar
esse problema no RSVP-TE para minimizar os efeitos do
soft-state, como a introduo de um mecanismo de
reconhecimento de mensagem recebida (acknowledge),
tornando o protocolo de troca de mensagens confivel,
possibilitando reduzir o tempo de refresh dos estados e
consequentemente o overhead. Outro mecanismo para
reduo do overhead a possibilidade de com apenas uma
mensagem realizar o refresh de vrios estados
simultaneamente.
Outra diferena essencial no funcionamento destes
protocolos o mecanismo de rpida notificao de falhas

2006 WCCSETE

presentes no RSVP-TE, implementado pela mensagem


Notification. O protocolo CR-LDP tambm possui uma
mensagem de notificao (Notification), entretanto as
funes de ambas so distintas. No CR-LDP quando uma
falha em uma rota detectada ela propagada com as
mensagens Release/Withdraw a partir do ponto de falha. Os
recursos alocados devem ser liberados nesta fase. A
mensagem de notificao serve para informar falhas no
processamento de mensagens.
J no RSVP-TE a mensagem de notificao informa
sobre falhas em rotas e enviada diretamente do ponto de
deteco ao ponto de reparao (um LSR responsvel por
realizar a restaurao do LSP).
Na Tabela 1 so identificadas algumas semelhanas
entre ambos os protocolos, enquanto a Tabela 2 mostra as
suas principais diferenas.
TABELA 1
SIMILARIDADES ENTRE O CR-LDP E O RSVP-TE.
Caractersticas

CRLDP

RSVP-TE

Sinalizao
Inicial

Mensagens de
label request

Mensagens Path
contendo o pedido do
rtulo

Sinalizao de
confirmao

Mensagens de
label mapping

Mensagens RESV

Definio para
servios
diferenciados
(Diffserv)

DIFFSERV_PSC
TLV

DIFFSERV_PSC
object

Suporte para
LSPs point-tomultipoint

No

No

Capacidade para
rotas explcitas

Esta definida
pela sinalizao
contida na TLV.

Esta carregada no
objeto
EXPLICIT_ROUTE

TABELA 2
DIFERENAS ENTRE O CR-LDP E O RSVP-TE
Caractersticas

CRLDP

RSVP-TE

Estgio de
desenvolvimento

Recente

Antigo, com novas


extenses
adicionadas para
engenharia de
trfego.

Transporte de
Sinalizao

UDP para novas


descobertas, TCP
para
manuteno da
sesso

Datagramas IP ou
encapsulamento
UDP.

Estado da
Conexo

hard state

soft state

March 19 - 22, 2006, So Paulo, BRAZIL


World Congress on Computer Science, Engineering and Technology Education
573

Confiabilidade

Falhas produzem
uma resposta
Da sinalizao

Depende do tempo
entre as
mensagens de
refresh.

Extensiabilidade

TLVs
experimentais

Objetos
experimentais

Escalabilidade

Conexes hard
state reduzem o
processamento
de sinalizao

Requer reduo de
mensagens de
refresh, agregao
para diminuir o
processamento.

Bem definida,
suporte a
maioria dos
protocolos de
camada de
enlace.

Tunelamento
atravs de redes
ATM pode ser
configurado
manualmente

Interoperabilidade

CONCLUSO
O MPLS aparece no cenrio de redes como uma arquitetura
emergente, baseada num modelo de encaminhamento de
pacotes, sendo a tecnologia que se apresenta mais
promissora na tentativa de melhorar o desempenho das
redes, por ser flexvel e por permitir seu mapeamento em
vrias tecnologias de rede.
As suas melhores perspectivas se apresentam no uso
conjunto com a tecnologia IP, adicionando a esta o
paradigma de circuito virtual e a possibilidade de aplicar
conceitos como a engenharia de trfego e a garantia de QoS,
sem haver a necessidade de alterar totalmente a estrutura j
existente nas redes de dados atuais.
A engenharia de trfego torna-se cada vez mais
necessria, no somente por seu carter tcnico, mas
tambm como um fator econmico, um uso mais inteligente
da rede cria a possibilidade de no ser necessrio a
atualizao de equipamentos para atender alguma carncia
de, por exemplo, largura de banda para transmisso.
Ambos os protocolos de sinalizao aqui analisados, o
CR-LDP e o RSVP-TE, disponibilizam funcionalidades
similares para a implementao de engenharia de trfego e
para o estabelecimento de rotas, apesar de haver um
consenso sobre o uso do RSVP-TE. No h um motivo
determinante para tal escolha, porm pode-se citar o fato do
RSVP-TE ser largamente utilizado para reserva de recursos
nas redes IP tradicionais, havendo apenas a necessidade de
adicionar a capacidade de distribuio de rtulos, que feito
atravs de suas extenses.

[2]

OSBORNE, E.; SIMHA, A. Engenharia de trfego com MPLS. Rio


de Janeiro, Editora Campus, 2002.

[3]

E. ROSEN, E.; VISWANATHAN, A.; CALLON, R, Multiprotocol


Label Switching Architecture, < ftp://ftp.rfc-editor.org/innotes/rfc3031.txt>.

[4]

Andersson, L.; Swallow, G. The Multiprotocol Label Switching


(MPLS) Working Group decision on MPLS signaling protocols, <
ftp://ftp.rfc-editor.org/in-notes/rfc3468.txt>.

[5]

International Engineering Consortium A Comparison of


Multiprotocol Label Switching (MPLS) Traffic-Engineering
Initiatives, <http://www.iec.org/online/tutorials/mpls_traffic/
index.htm>.

[6]

Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., Swallow G.,
RSVP-TE: Extensions to RSVP for LSP Tunnels, <ftp://ftp.rfceditor.org/in-notes/rfc3209.txt>.

[7]

Jamoussi, E.,B., Andersson L., Callon, R., Dantu, R., Wu, L., Doolan,
P., Worster, T., Feldman, N., Fredette, A., Girish, M., Gray, E.,
Heinanen, J., Kilty, T., Malis, A., Constraint-Based LSP Setup using
LDP, <ftp://ftp.rfc-editor.org/in-notes/rfc3212.txt>.

[8]

Andersson L., Swallow G. , The Multiprotocol Label Switching


(MPLS) Working Group decision on MPLS signaling protocols
<ftp://ftp.rfc-editor.org/in-notes/rfc3468.txt>

REFERNCIAS
[1]

BRITTAIN,P, FARREL, A MPLS traffic engineering: a choice of


signaling protocols. Data Connection Limited, 17 January 2000.
(http://www.datacon.co.uk)

2006 WCCSETE

March 19 - 22, 2006, So Paulo, BRAZIL


World Congress on Computer Science, Engineering and Technology Education
574

Você também pode gostar