RSVP
MPLS
Estratégias para Implantação de QoS
• Atualmente, duas estratégias de QoS sobre redes IP
estão em desenvolvimento:
– Serviços Integrados
• Baseado em um procolo de sinalização: RSVP
• Permite efetuar reserva de recursos fim-a-fim para
garantir a QoS de um dado fluxo, no momento em
que o fluxo é criado.
– Serviços Diferenciados
• Não utiliza protocolo de sinalização.
• Utiliza um esquema de priorização de recursos
baseado em SLA (Service Level Agreements)
previamente configurados.
Níveis de QoS
Reserva de Recursos Fim-a-Fim
Protocolo de Sinalização
Serviços
Integrados
Serviços
Diferenciados
Melhor Esforço
Priorização de Recursos
de Acordo com SLAs préestabelecidos
O primeiro pacote a
chegar é o primeiro a
ser atendido.
Serviços Integrados
•
•
•
Serviços integrados definem duas classes de serviço:
Serviço Garantido
– Define garantia de banda fim-fim, com atraso conhecido.
– Destinado a aplicações em tempo-real que não toleram atraso ou perda
de pacotes.
Serviço de Carga Controlada
– Não provê garantias de QoS rígidas.
– Procura evitar a deterioração do QoS de cada fluxo, através de
mecanismos de antecipação de congestionamento.
– Destinado a aplicações que toleram um certo nível de atraso e perda de
pacotes.
Serviços Integrados sobre IP
Comparação com outras tecnologias
• Frame-Relay
– Trabalha apenas com priorização.
– Não tem procolo de sinalização.
• ATM
– Trabalha com priorização e reserva de recursos.
– Possui protocolo de sinalização próprio.
• IP
– Trabalha com priorização ou reserva de recursos.
– Utiliza o procolo de sinalização RSVP.
– Serviços integrados em IP podem utilizar recursos de
QoS disponíveis na camada de enlace.
• Integrated Services over Specific Lower Layers
RSVP: Resource Reservation Protocol
• Protocolo de sinalização que permite as aplicações
solicitarem Qos especiais para seus fluxos de dados.
1. Solicita conexão com o servidor
Aplicação
multimídi
a
com
suporte a
RSVP
2. Informa requisitos para o cliente (PATH)
3. Solicita Reserva (RESV)
Aplicaçã
o com
Suporte
a RSVP
4. Confirma Reserva (RESVconf)
Servidor
9001
Cliente
RSVP
• Padronizado pela RFC2205,Setembro de 1997.
– Complementada pelas RFCs 2206, 2207, 2210,
2380, 2745, 2747, 2961.
• Protocolo de controle, similar ao ICMP ou IGMP.
– Permite que os nós da rede recebem informações
para caracterizar fluxos de dados, definir caminhos e
características de QoS para esses fluxos ao longo
desses caminhos.
• RSVP não é um protocolo de roteamento.
– Ele depende de outros protocolos para execução
dessas funções.
Arquitetura do RSVP
• As funções de implementação do QoS pelos nós não
são de responsabilidade do RSVP. Outros módulos são
especificados na arquitetura:
– Módulos de Decisão:
• Controle de Admissão: verifica se existem
recursos para o pedido.
• Controle de Política: verifica se o usuário pode
pedir os recursos.
– Módulos de Controle de Tráfego:
• Classificador: determina a classe do pacote
• Escalonador: implementa o QoS
Arquitetura do RSVP
Controle de
Admissão
Host
RSVP
aplicaçã
o
dados
Process
o
RSVP
Roteador
RSVP
RSVP
Processo
RSVP
Processo
roteamento
Controle de
Política
Controle de
Política
dados
Classificador
Classificador
Escalonador
Dados
Escalonador
RSVP é Unidirecional
• As reservas em RSVP são sempre unidirecionais.
• As reservas podem ser em unicast ou multicast.
• No RSVP o pedido de uma reserva sempre é iniciado
pelo receptor.
– Os direitos da reserva são debitados na conta do
cliente.
1. Solicita serviço
2. Especifica os requisitos
Servidor
3. Faz reserva
REDE
Cliente
Sessões RSVP
• Em RSVP, a política de QoS não é aplicada
individualmente sobre cada pacote, mas sim em
sessões.
• Uma sessão é definida como um fluxo de dados para
um mesmo destino, utilizando um mesmo protocolo de
transporte.
• Uma sessão é definida por três parâmetros:
– Endereço de destino
– Identificador de Protocolo (TCP ou UDP)
– Porta de destino (Opcional).
Sessões RSVP
• Podem ser de dois tipos:
Multicast
(239.0.64.240),TCP,[dstport])
Transmissor
IGMP
Endereço
Classe D
Os receptores
precisam formar
um grupo multicast
para poder receber
as mensagens.
Unicast
(168.100.64.5,TCP,5000)
Transmissor
Receptor
Receptor
Especificação de fluxo
• 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.
O Token Bucket Model
• O modelo utilizado pelo RSVP é o Token Bucket.
– Este modelo é um método realiza para definir uma
taxa de transmissão variável com atraso limitado.
saída
(bytes/s)
d <= b/p
r bytes/s
p
r
R
b bytes
t
chegada
reserva
saída
R
p bytes/s
B
Serviço
Garantido se
r <= R
Tspec
• Assumindo o Token Bucket Model, Tspec é definido 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
Rspec
• 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.
Mensagens RSVP
Encapsulado diretamente sobre IP
Msg Type: 8 bits
1 = Path
2 = Resv
3 = PathErr
4 = ResvErr
5 = PathTear
6 = ResvTear
7 = ResvConf
...
Objetos de
tamanho
variável
Session
FlowSpec
FilterSpec
AdSpec
PolicyData,
Etc.
Mensagem PATH
• PATH: enviada do transmissor para o receptor
– Descreve os requisitos de QoS para o receptor
• A mensagem PATH contém dois parâmetros básicos:
– Tspec: estrutura de dados que especifica o que será
transmitido.
– Adspec (opcional): estrutura que especifica os
recursos disponíveis.
• Utilizado para cálculo do Slack Term
PATH
Servidor
ADSPEC
TPEC
....
Cliente
ADSPEC
• ADSPEC é utilizado para cálculo do Slack Term:
– A folga de atraso permite aos roteadores acomodarem mais
facilmente as requisições de banda.
• Os parâmetros passados são os seguintes:
– hopCount:
• número de elementos intermediários
– pathBW:
• estimativa da largura de banda
– minLatency:
• estimativa do retardo de propagação
– composedMTU:
• MTU composta do referido caminho
Mensagem PATH
• A mensagem PATH define uma rota entre o transmissor
e o receptor.
– Todos os roteadores que recebem a mensagem
PATH armazenam um estado definido PATH state.
3
4
servidor
cliente
S
1) PATH
Estado: 1
2
1
2) PATH
Estado: S
C
3) PATH
Estado: 1
Estado: 2
Mensagem RESV (Reservation Request)
• RESV: Enviada do receptor para o transmissor
• A mensagem RESV contém dois 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.
RESV
Servidor
Flow Spec
Filter Spec
Service Class
IP origem
Rspec
Porta origem
ou
Flow Label
Tspec
....
Cliente
Service Class (Classes de Serviço)
• 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.
Mensagem RESV
• A mensagem RESV segue o caminho definido por
PATH.
– Cada nó RSVP decide se pode cumprir os requisitos
de QoS antes de passar a mensagem adiante.
3
4
servidor
cliente
S
3) RESV
Estado: 1‘
2
1
2) RESV
Estado: S
C
1) RESV
Estado: 1
Estado: 2
Mensagem de Erro
• Quando um dispositivo de recebe a mensagem RESV,
ele:
– autentica a requisição
– alocar os recursos necessários.
• Se a requisição não pode ser satisfeita (devido a falta de
recursos ou falha na autorização), o roteador retorna um
erro para o receptor.
• Se aceito, o roteador envia a mensagem RESV para o
próximo roteador.
Mensagem de Erro
• Podem ser de dois tipos:
– Erros de Caminho (Path error)
• Caminho ambíguo.
– Erros de Reserva (Reservation Request error).
• Falha de admissão
– o solicitante não tem permissão para fazer a reserva.
• Banda indisponível.
• Serviço não suportado.
• Má especificação de fluxo.
Exemplo
S
5 Mb/s
4 Mb/s
R1
R2
2 Mb/s
4 Mb/s
R3
R4
Resv(R1,S1)
R1 = 2,5 Mb/s e S1= 0
S
R5
Resv(R1,S1)
R
Resv(R1,S1)
ResvErr
5 Mb/s
4 Mb/s
R1
R2
Resv(R1,S2)
3,5 Mb/s
2 Mb/s
R3
4 Mb/s
3,5 Mb/s
R4
Resv(R1,S2) Resv(R1,S2) Resv(R1,S1) Resv(R1,S1)
R5
R
Resv(R1,S1)
R1 = 3 Mb/s e S1= 10 ms, S2 = 10 ms – delay provocado por R3
RESVconf: Reservation Confirmation
• Enviada do transmissor até o receptor através do PATH.
• Esta mensagem confirma para o cliente que a reserva
foi bem sucedida.
3
4
servidor
cliente
S
1
2
C
RESVconf
Estado: 1‘
Estado: S
Estado: 1
Estado: 2
Tipos de Mensagem RSVP
• Mensagens Teardown:
– Enviada pelo cliente, servidor ou roteadores para
abortar a reserva RSVP.
– Limpa todas as reservas e informações de PATH.
3
4
servidor
S
1
3) TearDown
Estado: 1‘
cliente
2
2) TearDown
Estado: S
Estado: 1
C
1) TearDown
RSVP na Internet
• Para que o RSVP possa ser implementado na Internet,
utiliza-se técnicas de tunelamento para saltar os
roteadores que não suportam RSVP.
O endereço de destino das mensagens PATH é do próximo roteador
que suporta RSVP.
Nuvem
não RSVP
servidor
cliente
Problemas do RSVP
• No IPv4, o RSVP classifica os pacotes utilizando
informações do protocolo de transporte (portas)
• Isso causa problemas quando:
– Houver fragmentação.
• Solução: As aplicações devem transmitir as
informações com o mínimo MTU do caminho.
– IPsec ou outras técnicas de tunelamento podem
criptografar os pacotes:
• Uma extensão do IPsec foi proposta para suportar
RSVP.
Desenvolvimento de Aplicações RSVP
• Serviços integrados necessitam que as aplicações
sejam escritas de maneira a usar o protocolo RSVP.
• Já estão disponíveis API para desenvolver aplicações
RSVP em várias plataformas:
• Em Windows
– Winsock 2 QoS API
• Em Java
– Várias implementações em universidades
– JQoSAPI: http://www-vs.informatik.uniulm.de/soft/JavaQoS/
• Em Linux
– Suporta RSVP, mas API estão disponíveis para
serviços diferenciados.
Serviços Integrados na Internet
• A abordagem de serviços integrados não é vista como
apropriada para Internet.
• Estima-se que o RSVP seja pouco escalável pois:
– Muitas mensagens trocadas para estabelecimento da
reserva.
– Os roteadores necessitam de manter informações de
caminho (operação stateful)
• Serviços diferenciados são uma proposta alternativa do
IETF para implementação de QoS em provedores e
Backbones na Internet.
Conclusão
• Serviços Integrados:
– Garantia das características de QoS para os fluxos
numa comunicação fim-a-fim.
– A rede nunca “admite” mais tráfego do que é capaz.
– Pouco escalável devido ao alto custo de manter o
estado nos roteadores.
• Serviços Diferenciados:
– Policiamento e priorização de tráfego em domínios de
serviço diferenciado.
– A rede pode eventualmente ficar sobre-carregada e
não cumprir as características de QoS solicitadas.
– Escalável, pois não precisa manter rígidas condições
de estado nos roteadores.
ANEXOS
Estilos de Reserva RSVP
Estilos de Reserva
• As reservas em RSVP podem ser feitas de formas diferentes
(estilos):
Seleção do
Emissor
Reserva
Distinta
Reserva
Compartilhada
Explícita
Filtro Fixo (FF)
Explícito
Compartilhado (SE)
Curinga
Não Definido
Filtro com Curinga
(WF)
Exemplo de WildCard Filter
• WildCard-Filter (WF)
– Estabelece uma única reserva para todos os emissores de
uma sessão (tipicamente multicast, onde só um transmite de
cada vez).
– Só a maior requisição de reserva chega aos emissores.
– Sintaxe: WF (* {Q})
Exemplo de Fixed Filter
• Fixed-Filter (FF):
– Pacotes de emissores diferentes numa mesma sessão não
compartilham reservas.
– Mas as reservas são compartilhadas pelos receptores.
– Sintaxe: FF (S{Q}) ou FF(S1{Q1},S2{Q2},...}
Exemplo de Shared Explicit
• Shared-Explicit (SE):
– A reserva é propagada para todas as fontes no valor
máximo feito por cada receptor.
– Sintaxe: SE ((S1,S2,...){Q})
MPLS
Multi-Protocol Label Switching
MPLS - Multiprotocol Label Switching
• Histórico
– 1997: IETF MPLS Working Group
• Objetivos:
– Técnica de computação por rótulos
– Similar ao Frame-Relay e ao ATM
• permite definir múltiplos caminhos entre uma
origem e um destino na nuvem IP
– Utiliza protocolos de controle baseados em
tecnologia IP
Eduardo Guimarães Nobre
Roteamento tradicional (Hop by Hop)
Roteamento + Envio
Para:
1) 64.12.100.11
2) 64.12.100.11
3) 64.12.100.25
4) 64.12.100.25
5) 64.12.101.10
6) 64.12.101.10
7) 64.12.101.46
8) 64.12.101.46
64.10
Destino: 64.11
Interface: 2
Destino: 64.12.100
Interface: 1
Destino: 64.12.101
Interface: 1
1
2
2
3
1
64.12
Destino: 64.10
Interface: 2
Destino: 64.11
Interface: 1
Destino: 64.12.100
Interface: 3
Destino: 64.12.101
Interface: 3
64.11
•
Roteamento realizado no nível
3 (IP);
•
Baixa escalabilidade (aumento
significativo das tabelas de
rotas)
•
Lentidão na busca nas tabelas;
•
Sub-utilização de certas rotas e
super-utilização de outras.
Eduardo Guimarães Nobre
Integrated Services (Intserv)
Para:
1) 64.12.100.11
2) 64.12.100.11
3) 64.12.100.25
4) 64.12.100.25
5) 64.12.101.10
6) 64.12.101.10
7) 64.12.101.46
8) 64.12.101.46
4 informações de estado
2 informações de estado
64.10
Fluxo #1 (1+2)
Fluxo #2 (3+4)
64.12
Fluxo #3 (5+6)
Fluxo #4 (7+8)
64.11
•
Utiliza RSVP;
•
Baixa escalabilidade;
•
Informações de estado para cada fluxo
gera alto tráfego de controle;
•
Permanente tráfego de sinalização
Eduardo Guimarães Nobre
RSVP x MPLS
RSVP
NÓ
A
LDP/CR-LDP
NÓ
B
PATH
RESV
PATH
RESV
PATH
RESV
PATH
RESV
.
.
.
Tempo
Permanente
NÓ
A
NÓ
B
REQUEST
MAPPING
Terminado
Label Switching
LABEL 3 - BC - LABEL 5
LABEL 4 - BD - LABEL 6
LABEL 5 - CE - LABEL 7
C
5
LSR=1
1
3
A
LSR=2
2
9
7
B
4
LABEL 1 - B - LABEL 3
LABEL 2 - B - LABEL 4
E
F
10
6
8
D
LABEL 6 - DE - LABEL 8
LABEL 7 - EF - LABEL 9
LABEL 8 - EF - LABEL 10
LFIB (Label
Forwarding
Information Base)
Princípios do MPLS
• Os nós precisam ser configurados com as informações
sobre encaminhamento e troca de labels, usando a
tupla.
– INTERFACE ORIGEM - LABEL ORIGEM INTERFACE SAÍDA - LABEL SAÍDA
• As informações de roteamento IP são utilizadas uma
única vez para descoberta da rota entre 2 pontos
– Maior velocidade na busca na tabela de rótulos;
– Melhor utilização da infra-estrutura do backbone
Descoberta de Rota
• Manual
• Com protocolos para MPLS
– 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
Rótulo
• Identificador de 32 bits que é inserido no pacote ou
célula no momento da entrada destes no domínio MPLS.
• Indica o próximo roteador e as operações a serem
realizadas sobre o pacote.
• Estrutura:
– Rótulo (20 bits): valor do rótulo;
– Exp(3 bits): reservado. Para uso experimental;
– S (1 bit): base da pilha. O valor 1 indica que o rótulo é
a base da pilha;
– TTL (8 bits): Time to Live = copiado do IP.
Rótulo
Exp
S
TTL
Pilha de Rótulos
pacote:
cabeçalho N2
Rótulo = # X
...
1
Exp
0
cabeçalho N3
N
TTL
(1)
pilha
...
Rótulo = # Y
•
•
Exp
PDU
1
TTL
Estrutura a ser codificada no pacote ou célula;
Último rótulo deve ter o valor 1 no campo S.
(N)
Label Switching - Tunelamento
• Os rótulos internos não são comutados no interior do
túnel.
LFIB no
LSR C
LFIB no
LSR E
IF IN
Label in
Ação
IF OUT
Label out
De A
3
Troca/Envio
D
9,3
De B
3
Troca/Envio
D
9,7
IF IN
Label in
Ação
IF OUT
Label out
De D
4
Retirada
De D
3
Troca/Envio
F
1
De D
7
Troca/Envio
G
2
A
5
D
C
B
8
9-7
1
4- 3
9- 3
F
E
4-7
2
G
Eduardo Guimarães Nobre
Tunneling
N2
N3
DADOS
FEC X: inserir rótulo R1
LER1
N2
R1
N3
DADOS
Rótulo R1: trocar por R2
e empilhar rótulo Ra
LSR1
N2
Ra
R2
N3
DADOS
LSP
LSRA
LSRB
LSRC
Rótulo Rc: retirar rótulo do topo
Rótulo Ra: trocar por Rb
N2
N2
Rb
R2
N3
DADOS
R2
LER2
LSP
Rótulo Rb: trocar por Rc
N2
Rc
R2
N3
DADOS
Rótulo R2: retirar a pilha
N2
N3
DADOS
N3
DADOS
MPLS com ATM e Frame-Relay
• No Label MPLS pode ser transportado através dos Labels
do Frame-Relay e do ATM sem necessidade de inserir
novos cabeçalhos. Exceções:
– empilhamento de rótulos
– outros campos do MPLS são necessários
• No ATM
– Pacotes MPLS são trasnportados em AAL5
– Label MPLS é mapeado em VPI/VCI
• No Frame-Relay
– Label MPLS é mapeado no DLCI
Posição em Outra Tecnologias
PPP Header(Packet over
SONET/SDH)
Ethernet
Frame Relay
ATM Cell Header
GFC
PPP Header
Shim Header
Layer 3 Header
Ethernet Hdr
Shim Header
Layer 3 Header
FR Hdr
Shim Header
Layer 3 Header
VPI
VCI
PTI CLP HEC
DATA
VCI
PTI CLP HEC
DATA
Label
Subsequent cells GFC
VPI
Label
Eduardo Guimarães Nobre
LSR x LER
•
•
LER (Label Edge Routers): roteadores que ficam na borda do domínio
MPLS.
– Inserem ou retiram pilhas de rótulos dos pacotes/células;
LSR (Label Switching Routers): roteadores que ficam no núcleo do domínio
MPLS.
– Realizam operações sobre a pilha dos pacotes/células a partir da
análise do rótulo do topo;
64.10
LSR3
LER1
LSR1
LER2
LSR4
LSR2
LER3
64.11
64.12
LDP - Label Distribution Protocol
• Protocolo de Distribuição de Rótulos
– IETF (Janeiro de 2001)
– Quantidade de campos variável:
• TLV (Tipo -Tamanho - Valor)
• Executa quatro tipo de funções:
– Descoberta de LSRs
– Estabelecimento de conversação de controle
– Anúncio de Rótulos
ID do LSR
– Retirada de Rótulos
PDU/LDP
msg LDP
header
PDU
header TLV
msg LDP
TLV
sub
TLV
sub
TLV
header TLV
TLV
LDP
•
Quanto MPLS é habilitado em um roteador:
– O roteador aloca um label para cada rota em sua tabela.
– Ele anuncia ambos, a rota e o prefixo para os roteadores vizinhos
– O anuncio solicita que os roteadores vizinhos atachem o label anuciado nos
pacotes enviados a esse roteador.
Rede 10.1/16
anúncio
FEC
R3
10.1/16 – Label 24
R1
R2
R4
10.1/16 – Label 15
10.2/16 – Label 16
10.2/16 – Label 30
Rede 10.2/16
FEC
Forwarding Equivalence Class (FEC)
• FEC é o conjunto de pacotes encaminhados da mesma
forma.
• O conceito de FEC permite a agregação de vários
endereços, aumentando a escalabilidade de proposta
MPLS.
– Exemplos de FEC
• subrede
• tráfego agregado AF12
• conjunto de endereços IP
• Os LSR de borda (i.e., LER) são responsáveis por
mapear inicialmente as FEC aos rótulos MPLS.
Eduardo Guimarães Nobre
Roteamento Nó a Nó (Hop by Hop)
IP de destino: 64.12
Próx. Vizinho = LSR3
IP de destino: 64.12
Próx. Vizinho = LSR2
LSR1
IP de destino: 200.25
Próx. Vizinho = LSR4
LSR2
Rótulo de entrada = #20
FEC = 64.12
Rótulo de saída = #150
Próx. Vizinho = LSR2
Rótulo de entrada = #100
FEC = 64.12
Rótulo de saída = #134
Próx. Vizinho = LSRX
Rótulo de entrada = #150
FEC = 64.12
Rótulo de saída = #100
Próx. Vizinho = LSR3
Rótulo de entrada = #230
FEC = 200.25
Rótulo de saída = #194
Próx. Vizinho = LSRY
Rótulo de entrada = #420
FEC = 64.25
Rótulo de saída = #230
Próx. Vizinho = LSR4
LSR3
IP de destino: 64.12
Próx. Vizinho = LSRX
LSR4
IP de destino: 200.25
Próx. Vizinho = LSRY
LDP: Label Distribution Protocol
•
Existem quatro tipos de mensagens:
– 1. Discovery messages: HELLO (UDP Multicast)
• anunciar e manter a presença de um LSR na rede;
– 2. Session messages: Inicialização de Sessão (TCP)
• estabelecer, manter e terminar sessões entre colegas LDP;
– 3. Advertisement messages: Anúncio de Endereço e Rótulo (TCP)
• criar, mudar e terminar mapeamentos
– 4. Notification messages: Notificação de Erro (TCP)
• consulta e sinalização de erros.
Upstream
Downstream
Requisição de atribuição para Endereço
LSR1
LSR2
Atribuição de rótulo para Endereço
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 Rótulo (Label Mapping)
Remoção de Rótulo (Label Withdraw)
Liberação de Rótulo (Label Release)_
Utilizado apenas na
distribuição de rótulos sob
demanda
Controla o mapeamento
de FECs em LABELs
Distribuição de rótulos
• Métodos de distribuição de rótulos
– Downstream por Demanda
– Downstream não Solicitado
• O método é escolhido durante a fase de inicialização de
sessão (IS) do LDP
– bit A da mensagem IS = 1 para demanda
• Em caso de desacordo, a RFC 3036 define:
– ATM e Frame-Relay: Por Demanda
– Outras Tecnologias: Não Solicitado
• Os dois modos podem ser combinados em diferentes
enlaces de uma nuvem MPLS
Modos de Controle e Retenção de
Rótulos
• Controle Programado
– Os labels são sempre propagados na direção
upstream
• Controle Independente
– Os rótulos são propagados apenas quando há
requisição ou quando o LSR local vê uma boa razão
para isso.
• Retenção de Label Liberal
– Ao receber um anúncio melhor, o LSR mantém a rota
anterior.
• Retenção de Label Conservadora
– O LSR mantém apenas a melhor rota.
Eduardo Guimarães Nobre
Exemplo de domínio MPLS
Downstream Upstream
Upstream
64.10
LSR3
LER1
Downstream
LSP #1
64.12
LSR1
LER2
LSR4
LSR2
LER3
64.11
LSP #4
LSP #3
LSP #2
Eduardo Guimarães Nobre
Downstream Não-solicitado
LSP p/ FEC 64.12
Upstream
Downstream
LER1
Upstream
Downstream
LSR2
Atribuição de rótulo #150
p/ FEC 64.12
Rótulo de entrada = #20
FEC = 64.12
Rótulo de saída = #150
Próx. vizinho = LSR2
LSR3
Atribuição de rótulo #100
p/ FEC 64.12
Rótulo de entrada = #150
FEC = 64.12
Rótulo de saída = #100
Próx. vizinho = LSR3
Rótulo de entrada = #100
FEC = 64.12
Rótulo de saída = #134
Próx. vizinho = LSR4
Eduardo Guimarães Nobre
Downstream Sob demanda
LSP p/ FEC 64.12
Upstream
Downstream
Requisição de atribuição para 64.12
LER1
Upstream
Downstream
Requisição de atribuição para 64.12
LSR2
Atribuição de rótulo #150
p/ FEC 64.12
Rótulo de entrada = #20
FEC = 64.12
Rótulo de saída = #150
Próx. vizinho = LSR2
LSR3
Atribuição de rótulo #100
p/ FEC 64.12
Rótulo de entrada = #150
FEC = 64.12
Rótulo de saída = #100
Próx. vizinho = LSR3
Rótulo de entrada = #100
FEC = 64.12
Rótulo de saída = #134
Próx. vizinho = LSR4
Eduardo Guimarães Nobre
Controle Programado
64.10
LSR3
LER1
64.12
LSR1
LSP #1
LER2
LSP #2
LSR4
LSR2
LSP #3
LER3
64.11
LSP #4
Os labels são sempre propagados na direção upstream
Eduardo Guimarães Nobre
Controle Independente (Não-solicitado)
64.10
LSR3
LER1
64.12
LSR1
LSP #1
LER2
LSP #2
LSR4
LSR2
LSP #3
LER3
64.11
LSP #4
Eduardo Guimarães Nobre
Controle Independente (Sob-Demanda)
64.10
LSR3
LER1
64.12
LSR1
LSP #1
LER2
LSP #2
LSR4
LSR2
LSP #3
LER3
64.11
LSP #4
Eduardo Guimarães Nobre
Retenção de Label Conservadora
64.10
LSR3
LER1
64.12
LSR1
LSP #1
LER2
LSP #2
LSR4
LSR2
LSP #3
LER3
64.11
LSP #4
Eduardo Guimarães Nobre
Retenção de Label Liberal
64.10
LSR3
LER1
64.12
LSR1
LSP #1
LER2
LSP #2
LSR4
LSR2
LSP #3
LER3
64.11
LSP #4
Eduardo Guimarães Nobre
Combinando as Formas de Distribuição
de Rótulos
Rótulo de entrada = #20
FEC = 64.12
Rótulo de saída = #150
Próx. Vizinho = LSR2
Rótulo de entrada = #150
FEC = 64.12
Rótulo de saída = #100
Próx. Vizinho = LSR3
Requisição de atribuição para 64.12
LER1
Rótulo de entrada = #100
FEC = 64.12
Rótulo de saída = #134
Próx. Vizinho = LSR4
Requisição de atribuição para 64.12
LSR2
LSR3
Atribuição de rótulo #100
Atribuição de rótulo #150
Atribuição de rótulo #134
p/ FEC 64.12
LSR5
LSP p/ FEC 64.12
LSR4
Atribuição de rótulo #212
p/ FEC 64.12
Rótulo de entrada = #212
FEC = 64.12
Rótulo de saída = #47
Próx. Vizinho = LSR6
Rótulo de entrada = #134
FEC = 64.12
Rótulo de saída = #212
Próx. Vizinho = LSR5
Engenharia de Tráfego no MPLS
•
Mecanismos do MPLS para TE
1. LSP distinto do sugerido pelo OSPF
2. Reserva dinâmica de recursos junto com o
estabelecimento do LSP
3. Distribuição de tráfego por LSPs paralelos
4. Criação e Remoção dinâmica de LSPs conforme as
necessidades da rede
5. Utilização de LSPs como objetos gerenciáveis.
6. Tratamento de falhas pela migração de tráfego entre
LSPs altenativos e criação de LSPs backups ou de
espera.
7. As decisões de encaminho de tráfego são tomadas
apenas na entrada do LSP e não em cada nó.
Exemplo: Backbone RNP
Rotas Explícitas
•
•
Rota Explícita: O LDP pode ser utilizado para seguir uma rota explícita,
formada por uma seqüência de nós abstratos
• Um nó abstrato é formado por um ou mais LSRs
• A rota deve passar por pelo menos um LSR do nó abstrato
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.
* (estrito)
+ (flexível)
A*:B*:D*:E*:G*
A*:F+:G*
E
B
A
G
D
C
F
Requisitos o protocolo de sinalização MPLS
• Requisitos:
– O protocolo de roteamento precisa anunciar as
capacidades e os recursos disponíveis em cada
enlace.
– O requisitante do LSP deve indicar as características
do fluxo: largura de banda média, picos, requisitos de
qualidade.
• Protocolo de Sinalização
– Suporte a rotas explícitas
– Confrontar requisitos de QoS e capacidades
– Requisitar reservas ao longo do caminho
– Re-anúncio das disponibilidades de recurso
modificadas
Preempção
• Cada LSP tem dois parâmetros de prioridade:
– prioridade de retenção
• prioridade em reter recursos
– prioridade de configuração
• prioridade para tomar recursos
• Novos caminhos LSP podem ser configurados, mesmo
quando todos os recursos da rede tenham sido
esgotados.
– Isso é feito através da preempção de recursos de um
LSP sobre outros. Isso é feito se:
• prioridade de configuração > prioridade de
retenção
Protocolos de Sinalização para MPLS
• CR-LDP
– Contraint-Based LSP Setup Using LDP
– RFC 3212
• RSVP-TE
– Extensions to RSVP for LSP Tunnels
– RFC 3209
CR-LDP (Constrained –LDP)
• Baseado na adição de TLVs nas mensagens LDP
existentes
• Criação de LSPs fim-a-fim sob restrições
– Modo Downstream por Demanda
• Restrições impostas pelo LSR de ingresso
• Labels distribuídos a partir do LSR de egresso
– Prioridades podem ser atribuídas para as LSPs para
suportar o esquema de preempção
– Re-roteamento ou não em caso de falha
• Duas classes de Restrições:
– Rotas Explícitas
– Parâmetros de Tráfego
Mensagens CR-LDP
• Hello
– Descoberta de parceiros CR-LDP
• Label Request
– Requisitar anúncio de Rótulo
• Label Mapping
– Mapeamento de REC e Rótulo
• Label Release
– Liberar um LSP pelo solicitante (upstream)
• Label Withdraw
– Remover o LSP pelo fornecedor (downstream)
• Notification
– Informar erros ou eventos adicionais: i.e. TVL desconhecida
para LSRs que não suportam CR-LDP, recursos insuficientes,
etc.
TLV - Parâmetros de Tráfego
• Mensagem Label Request
– Tráfego Prometido
• Peak Data Rate - PDR (bytes por segundo)
• Peak Burst Size - PBS (bytes)
– Serviço Desejado
• Commited Data Rate - CDR (bytes por segundo)
• Commited Burst Size - EBS (bytes)
• Excess Burst Size - EBS (bytes)
Frequência de Amostragem e Peso
• Freqüência de amostragem:
• Muito frequente
– CDR garantido para quaisquer 2 pacotes
• Frequente
– CDR garantido para uma média de poucos pacotes pequenos
• Não Especificado
– Uso de uma intervalo razoável (i.e., 1 segundo)
• Peso
– Valor de 1 a 255
– Indica a capacidade do LSR de utilizar recursos disponíveis de
outros LSRs para transporte de tráfego excedente
– LSR com maior peso tem prioridade sobre os LSRs de menor
peso
Negociação
• A TLV de parâmetros de tráfego define um campo flag (1
byte), para indicar quais itens do pedido podem ser renegociados:
– bit 0: reservado
– bit 1: reservado
– bit 2: PDR
– bit 3: PBS
– bit 4: CDR
– bit 5: CBS
– bit 6: EBS
– bit 7: Peso
Fluxo de Mensagens: 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
Label Request
Label Request
2
1
A
B
2*
Notification
C
D
Fluxo de Mensagens: CR-LDP
•
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.
Label Request
Label Request
3
2
A
C
B
3*
Notification
3*
Notification
D
Fluxo de Mensagens: CR-LDP
•
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).
– Essa mensagem é propagada sem modificação até o nó de
ingresso.
– Os nós intermediários utilizam essa informação para atualizarem sua
reserva.
•
5) 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.
Label Request
3
A
C
B
4
Label Mapping
4
Label Mapping
5
Label Release
D
4
Label Mapping
Eduardo Guimarães Nobre
Roteamento Explícito
•
ER-Hop: Campo de 14 bits que carrega o tipo de ER:
– Valores atualmente definidos:
– 0x0801 - IPv4 prefix
– 0x0802 - IPv6 prefix
– 0x0803 - Autonomous system number
– 0x0804 - LSPID
LER1
Requisição de atribuição
Requisição de atribuição
contendo caminho explícito: 2,
contendo caminho explícito: 3,
3, 5
5
LSR2
LSR3
Atribuição de
rótulo
Atribuição de
rótulo
Requisição de
atribuição
Atribuição de
rótulo
LSR4
LSR5
LSP
RSVP-TE
• Baseado no RSVP, o qual foi expandido para suportar
as funções de distribuição de rótulo.
• O RSVP-TE reutiliza todas as sete mensagens RSVP:
– Path: pedido de reserva (cliente)
– Resv: confirmação de reserva (servidor)
– ResvConf: confirmação pelo cliente
– ResvTear: desistência pelo servidor
– ResvErr: notificação de erro ao receber pedido de
reserva
– PathErr: notificação de erro ao receber medido de
path
– PathTear: desistência pelo cliente
RSVP-TE
• Extensões feitas sobre o RSVP:
– Gerenciamento de rótulo
• Objeto "Label Request" na mensagem Path
• Objeto "Label" na mensagem Res
• Dois novos tipos de classe:
– IPv4 LSP Tunnel
– IPv6 LSP Tunnel
– Requisição e Registro de Rotas Explícitas
• Objeto "Rota Explícita" na mensagem Path
• Objeto "Registro de Rota" nas mensagens Path e Resv
– Recursos de Preempção
• Objeto "Atributo de Sessão" inclui as prioridades na
mensagem Path
– Manutenção de conectividade entre LSRs
• Mensagens Hellos trocadas entre LSRs adjacentes
Gerenciamento de Rotas
• Inclusão do Objeto "Rota Explícita" na mensagem Path
– Indica a seqüência de saltos estritos ou flexível, de
forma idêntico ao CRLDP
• Inclusão do Objeto "Registro de Rota" nas mensagens
Path e Resv (opcional)
– Indicam a seqüência completa de LSR utilizada para
compor o caminho
– Os rótulos intermediários podem também,
opcionalmente, serem coletados ao longo do
caminho
Eduardo Guimarães Nobre
Criação de um LSP com RSVP
1. Mensagem Path.
Contém o caminho ER
<2,3,4>
LER1
2. Nova Path State.
Mensagem Path enviada
para o próximo nó
LSR2
LSR3
LER4
LSP
5. Quando LER 1
receber Resv, o ER
será estabelecido
4. Nova Resv State.
Mensagem Resv
propagada upstream
3. Mensagem Resv gerada.
Contém o rótulo a ser usado e
o Tráfego / QoS requerido
Conclusão
• O IETF deseconraja a utilização do CR-LDP, sendo que
o protocolo é considerado apenas um padrão proposto.
– Grandes fornecedores, como a Cisco e a Juniper
utiliza o RSVP-TE
• RSVP-TE funciona sobre IP puro e não sobre TCP
(como o CRLDP).
– CRLDP: protocolo de estado rígido
• mantido pelas conexões TCP
– RSVP-TE: protocolo de estado flexível
• necessita de uma alteração explícita de estado
• Apenas RSVP-TE permite o compartilhamento de
recursos (criação de LSRs sobre caminhos existentes).