RSVP MPLS

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

Melhor Esforço

Serviços Diferenciados

ServiçosIntegrados

Reserva de Recursos Fim-a-FimProtocolo de Sinalizaçã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 IPComparaçã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.

Servidor Cliente

1. Solicita conexão com o servidor

9001

Aplicação multimídi

acom

suporte a RSVP

Aplicação com

Suporte a RSVP

2. Informa requisitos para o cliente (PATH)

3. Solicita Reserva (RESV)

4. Confirma Reserva (RESVconf)

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

Host

Controle de Política

Controle de Admissão

Classificador Escalonador

dados

Roteador

dados

Dados

RSVPaplicaçã

o

Processo

RSVP

ProcessoRSVP

Classificador Escalonador

Processoroteamento

RSVP

Controle de Política

RSVP

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.

Servidor Cliente

REDE

1. Solicita serviço

2. Especifica os requisitos

3. Faz reserva

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])

Unicast(168.100.64.5,TCP,5000)

IGMP

EndereçoClasse D

Os receptores precisam formar

um grupo multicast para poder receber

as mensagens.

Transmissor

Receptor

ReceptorTransmissor

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.

Serviço Garantido se

r <= R

b bytes

r bytes/s

chegada

p bytes/s

saída

d <= b/p

r

saída(bytes/s)

p

t

R

B

reserva

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 RSVPEncapsulado diretamente sobre IP

Msg Type: 8 bits

1 = Path2 = Resv3 = PathErr4 = ResvErr5 = PathTear6 = ResvTear7 = ResvConf

...

Objetos de tamanho variávelSession

FlowSpecFilterSpecAdSpec

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

ADSPEC TPEC

PATH

Servidor 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.

S

servidor

21

3

C

cliente

1) PATH 2) PATH 3) PATH

Estado: S Estado: 1 Estado: 2

4

Estado: 1

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.

Flow Spec Filter Spec

RESV

Servidor Cliente....Service Class

Rspec

Tspec

IP origem

Porta origemou

Flow Label

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.

S

servidor

21

3

C

cliente

3) RESV 2) RESV 1) RESV


4

Estado: 1‘

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

R1 RS R2 R3 R4 R5

5 Mb/s 4 Mb/s 2 Mb/s 4 Mb/s 3,5 Mb/s

Resv(R1,S1)

R1 = 2,5 Mb/s e S1= 0

Resv(R1,S1)Resv(R1,S1)

ResvErr

R1 RS R2 R3 R4 R5

5 Mb/s 4 Mb/s 2 Mb/s 4 Mb/s 3,5 Mb/s

Resv(R1,S1)

R1 = 3 Mb/s e S1= 10 ms, S2 = 10 ms – delay provocado por R3

Resv(R1,S1)Resv(R1,S1)Resv(R1,S2)Resv(R1,S2) Resv(R1,S2)

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.

S

servidor

21

3

C

cliente

RESVconf


4

Estado: 1‘

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.

S

servidor

21

3

C

cliente

3) TearDown

Estado: S

4

1) TearDown

Estado: 1‘

2) TearDown

Estado: 1

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.

Nuvem não RSVP

servidor cliente

O endereço de destino das mensagens PATH é do próximo roteador que suporta RSVP.

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.uni-ulm.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

64.11

64.12

Para: 1) 64.12.100.112) 64.12.100.113) 64.12.100.254) 64.12.100.255) 64.12.101.10 6) 64.12.101.10 7) 64.12.101.468) 64.12.101.46

Roteamento + Envio

Destino: 64.11Interface: 2Destino: 64.12.100Interface: 1Destino: 64.12.101Interface: 1

Destino: 64.10Interface: 2Destino: 64.11Interface: 1Destino: 64.12.100Interface: 3Destino: 64.12.101Interface: 3

31

2

2

1

64.10

• 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.

Roteamento tradicional (Hop by Hop)Eduardo Guimarães Nobre

64.11

64.12

64.10

Fluxo #3 (5+6)Fluxo #4 (7+8)

Fluxo #2 (3+4)Fluxo #1 (1+2)

2 informações de estado4 informações de estado

Para: 1) 64.12.100.112) 64.12.100.113) 64.12.100.254) 64.12.100.255) 64.12.101.10 6) 64.12.101.10 7) 64.12.101.468) 64.12.101.46

• Utiliza RSVP;

• Baixa escalabilidade;

• Informações de estado para cada fluxo gera alto tráfego de controle;

• Permanente tráfego de sinalização

Integrated Services (Intserv)Eduardo Guimarães Nobre

NÓA

NÓB

NÓA

NÓB

RSVP LDP/CR-LDP

REQUEST PATH

PATH

PATH

PATH

MAPPINGRESV

RESV

RESV

RESV

Terminado

PermanenteTempo

.

.

.

RSVP x MPLSEduardo Guimarães Nobre

Label Switching

A B

C

E F

DLABEL 1 - B - LABEL 3LABEL 2 - B - LABEL 4

LABEL 3 - BC - LABEL 5LABEL 4 - BD - LABEL 6

LABEL 6 - DE - LABEL 8

LABEL 5 - CE - LABEL 7

LABEL 7 - EF - LABEL 9LABEL 8 - EF - LABEL 10

1 3

5

7 9

2 46 8

10

LFIB (Label Forwarding Information Base)

LSR=2

LSR=1

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 Exp S TTL

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.

• Estrutura a ser codificada no pacote ou célula;

• Último rótulo deve ter o valor 1 no campo S.

Rótulo = # X Exp 0 TTL

Rótulo = # Y Exp 1 TTL

(1)

(N)...

cabeçalho N2 cabeçalho N3 PDU1 N...

pilha

pacote:

Pilha de Rótulos

Label Switching - Tunelamento

• Os rótulos internos não são comutados no interior do túnel.

A

C ED

5

B

9- 3 4- 3 1

8 9 - 7 4 - 7 2

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

LFIB no LSR C

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

LFIB no LSR E

F

G

LSRB LSRC

LER1 LSR1

LSRA

LER2

LSP

LSP

DADOSN2 N3R1

DADOSN2 N3Ra R2

DADOSN2 N3

DADOSN2 N3Rb R2

DADOSN2 N3Rc R2

DADOSN2 N3R2

DADOSN2 N3

FEC X: inserir rótulo R1 Rótulo R1: trocar por R2 e empilhar rótulo Ra

Rótulo Ra: trocar por Rb

Rótulo Rb: trocar por Rc

Rótulo Rc: retirar rótulo do topo

Rótulo R2: retirar a pilha

Tunneling

Eduardo Guimarães Nobre

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 HeaderPPP Header Layer 3 HeaderLayer 3 HeaderShim HeaderPPP Header(Packet over SONET/SDH)

Ethernet HdrEthernet Hdr Layer 3 HeaderLayer 3 HeaderShim HeaderEthernet

FR HdrFR Hdr Layer 3 HeaderLayer 3 HeaderShim HeaderFrame Relay

ATM Cell Header HECHEC DATADATACLPCLPPTIPTIVCIVCIGFCGFC VPIVPI

Label

HECHEC DATADATACLPCLPPTIPTIVCIVCIGFCGFC VPIVPI

Label

Subsequent cells

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;


LER1

LSR1

LSR3

LSR2

LSR4

LER3

LER2

64.11

64.12

64.10

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– Retirada de Rótulos

PDU/LDP

header PDU

msg LDP msg LDP

header TLV TLV subTLV

subTLV

header TLV TLV

ID do LSR

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.

R2

R3

R4

R1

10.1/16 – Label 1510.2/16 – Label 16

10.1/16 – Label 24

anúncio

10.2/16 – Label 30

Rede 10.1/16

Rede 10.2/16

FEC

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.

LSR1 LSR2 LSR3

IP de destino: 64.12Próx. Vizinho = LSR2

LSR4



IP de destino: 64.12Próx. Vizinho = LSRX

IP de destino: 200.25Próx. Vizinho = LSRY

Rótulo de entrada = #20FEC = 64.12Rótulo de saída = #150Próx. Vizinho = LSR2



Rótulo de entrada = #100FEC = 64.12Rótulo de saída = #134Próx. Vizinho = LSRX

Rótulo de entrada = #230FEC = 200.25Rótulo de saída = #194Próx. Vizinho = LSRY

Roteamento Nó a Nó (Hop by Hop)Eduardo Guimarães Nobre

LSR1 LSR2

Atribuição de rótulo para Endereço

Upstream Downstream

Requisição de atribuição para Endereço

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.

Tipos de Mensagem LDP

LSR Ativo(maior ID)

LSR Passivo(menor ID)

Hello (UDP)

Conexão TCP

Keep Alive (KA)

Anúncio de Endereços de Interface

tempo de KAtamanho max PDU

Inicialização de Sessão (IS)

(IS) ou notificação de erro

Anúncio de Rótulo (Label Mapping)Remoção de Rótulo (Label Withdraw)Liberação de Rótulo (Label Release)_

Indica todos os endereços do LSR

Controla o mapeamento de FECs em LABELs

Solicitação de LABEL (Label Request)Utilizado apenas na distribuição de rótulos sob demanda

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.

LER1

LSR1

LSR3

LSR2

LSR4

LER3

LER2

64.11

64.12

64.10

LSP #1

LSP #2

LSP #3

LSP #4

DownstreamUpstream Upstream

Downstream

Exemplo de domínio MPLSEduardo Guimarães Nobre

Rótulo de entrada = #100FEC = 64.12Rótulo de saída = #134Próx. vizinho = LSR4



LER1 LSR2 LSR3

Atribuição de rótulo #150 p/ FEC 64.12


Upstream Downstream Upstream Downstream

LSP p/ FEC 64.12

Downstream Não-solicitadoEduardo Guimarães Nobre




LER1 LSR2 LSR3



Upstream Downstream Upstream Downstream

LSP p/ FEC 64.12

Requisição de atribuição para 64.12 Requisição de atribuição para 64.12

Downstream Sob demandaEduardo Guimarães Nobre

LER1

LSR1

LSR3

LSR2

LSR4

LER3

LER2

64.11

64.12

64.10

Controle Programado

LSP #1

LSP #2

LSP #3

LSP #4


Os labels são sempre propagados na direção upstream

LER1

LSR1

LSR3

LSR2

LSR4

LER3

LER2

64.11

64.12

64.10

Controle Independente (Não-solicitado)

LSP #1

LSP #2

LSP #3

LSP #4


LER1

LSR1

LSR3

LSR2

LSR4

LER3

LER2

64.11

64.12

64.10

Controle Independente (Sob-Demanda)

LSP #1

LSP #2

LSP #3

LSP #4


LER1

LSR1

LSR3

LSR2

LSR4

LER3

LER2

64.11

64.12

64.10

Retenção de Label Conservadora

LSP #1

LSP #2

LSP #3

LSP #4


LER1

LSR1

LSR3

LSR2

LSR4

LER3

LER2

64.11

64.12

64.10

Retenção de Label Liberal

LSP #1

LSP #2

LSP #3

LSP #4


LSR5 LSR4

Requisição de atribuição para 64.12 Requisição de atribuição para 64.12

LER1 LSR2

Atribuição de rótulo #150

LSR3

Atribuição de rótulo #100



LSP p/ FEC 64.12






Combinando as Formas de Distribuição de Rótulos


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.

A

B

C

D

E

F

G

* (estrito)+ (flexível)

A*:B*:D*:E*:G*

A*:F+:G*

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 re-negociados:– 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

A B C D

1 2

2*

Label Request Label Request

Notification


• 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.

A B C D

2

Label Request

3

Label Request

3*3*

NotificationNotification


• 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.

A B C D

3Label Request

4Label Mapping

4Label Mapping

4

Label Mapping

5

Label Release

LER1 LSR2 LSR3

Atribuição de rótulo


LSP

Requisição de atribuição contendo caminho explícito: 2, 3, 5

LSR4

Requisição de atribuição contendo caminho explícito: 3, 5

LSR5

Requisição de atribuição


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


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

LER1 LSR2 LSR3 LER4

LSP

1. Mensagem Path. Contém o caminho ER

<2,3,4>

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

2. Nova Path State. Mensagem Path enviada

para o próximo nó

Criação de um LSP com RSVPEduardo Guimarães Nobre

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).

Documents

RSVP MPLS