RSVP MPLS

1. RSVP MPLS

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

3. Níveis de QoS Reserva de Recursos Fim-a-Fim Protocolo de Sinalização Serviços Integrados Priorização de Recursos de Acordo com SLAs pré-estabelecidos Serviços Diferenciados O primeiro pacote a chegar é o primeiro a ser atendido. Melhor Esforço

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

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

6. 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ídia com suporte a RSVP Aplicação com Suporte a RSVP 2. Informa requisitos para o cliente (PATH) 3. Solicita Reserva (RESV) 4. Confirma Reserva (RESVconf) Cliente Servidor 9001

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

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

9. Arquitetura do RSVP Controle de Admissão Host Roteador RSVP RSVP RSVP Processo RSVP Processo RSVP aplicação Processo roteamento Controle de Política Controle de Política dados dados Classificador Classificador Escalonador Escalonador Dados

10. 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 Cliente Servidor REDE 3. Faz reserva

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

12. Sessões RSVP • Podem ser de dois tipos: Multicast (239.0.64.240),TCP,[dstport]) IGMP Receptor Endereço Classe D Transmissor Os receptores precisam formar um grupo multicast para poder receber as mensagens. Unicast (168.100.64.5,TCP,5000) Transmissor Receptor

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

14. saída (bytes/s) d <= b/p p r t 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. r bytes/s R b bytes reserva chegada Serviço Garantido se r <= R saída R p bytes/s B

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

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

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

18. 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 Cliente Servidor .... TPEC ADSPEC

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

20. 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 2 1 S C 1) PATH 2) PATH 3) PATH Estado: 1 Estado: 2 Estado: 1 Estado: S

21. 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 Cliente Servidor .... Flow Spec Filter Spec Service Class IP origem Porta origem ou Flow Label Rspec Tspec

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

23. 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 2 1 S C 3) RESV 2) RESV 1) RESV Estado: 1‘ Estado: 2 Estado: 1 Estado: S

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

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

26. Exemplo 3,5 Mb/s 4 Mb/s 2 Mb/s 4 Mb/s 5 Mb/s R3 R4 R5 R R2 R1 S Resv(R1,S1) Resv(R1,S1) Resv(R1,S1) R1 = 2,5 Mb/s e S1= 0 ResvErr 3,5 Mb/s 4 Mb/s 2 Mb/s 4 Mb/s 5 Mb/s R3 R4 R5 R R2 R1 S Resv(R1,S2) Resv(R1,S2) Resv(R1,S2) Resv(R1,S1) Resv(R1,S1) Resv(R1,S1) R1 = 3 Mb/s e S1= 10 ms, S2 = 10 ms – delay provocado por R3

27. 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 2 1 S C RESVconf Estado: 1‘ Estado: 2 Estado: 1 Estado: S

28. 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 cliente 2 1 S C 1) TearDown 2) TearDown 3) TearDown Estado: 1‘ Estado: S Estado: 1

29. 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 cliente servidor

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

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

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

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

34. ANEXOS Estilos de Reserva RSVP

35. Estilos de Reserva • As reservas em RSVP podem ser feitas de formas diferentes (estilos):

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

37. 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},...}

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

39. MPLS Multi-Protocol Label Switching

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

41. Destino: 64.11 Interface: 2 Destino: 64.12.100 Interface: 1 Destino: 64.12.101 Interface: 1 Destino: 64.10 Interface: 2 Destino: 64.11 Interface: 1 Destino: 64.12.100 Interface: 3 Destino: 64.12.101 Interface: 3 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 2 64.10 1 3 1 2 64.12 • 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. 64.11

42. 2 informações de estado 4 informações de estado 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 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

43. NÓA NÓB NÓA NÓB REQUEST MAPPING PATH PATH PATH PATH RESV RESV RESV RESV Eduardo Guimarães Nobre RSVP x MPLS RSVP LDP/CR-LDP Terminado . . . Permanente Tempo

44. Label Switching LABEL 3 - BC - LABEL 5 LABEL 4 - BD - LABEL 6 LABEL 5 - CE - LABEL 7 C 5 1 LSR=1 3 9 7 A B E F LSR=2 10 2 4 6 8 LABEL 1 - B - LABEL 3 LABEL 2 - B - LABEL 4 D LABEL 7 - EF - LABEL 9 LABEL 8 - EF - LABEL 10 LFIB (Label Forwarding Information Base) LABEL 6 - DE - LABEL 8

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

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

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

48. Pilha de Rótulos pacote: ... N cabeçalho N2 1 cabeçalho N3 PDU Rótulo = # X Exp 0 TTL (1) pilha ... 1 Rótulo = # Y Exp TTL (N) • Estrutura a ser codificada no pacote ou célula; • Último rótulo deve ter o valor 1 no campo S.

49. 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 1 5 4- 3 F 9- 3 A D C E B G 8 9 - 7 4 - 7 2

50. FEC X: inserir rótulo R1 Rótulo R1: trocar por R2 e empilhar rótulo Ra N2 N3 DADOS N2 R1 N3 DADOS N2 Ra R2 N3 DADOS Rótulo Rc: retirar rótulo do topo Rótulo Ra: trocar por Rb N2 Rb R2 N3 DADOS N2 R2 N3 DADOS N2 Rc R2 N3 DADOS Rótulo Rb: trocar por Rc Rótulo R2: retirar a pilha N2 N3 DADOS Eduardo Guimarães Nobre Tunneling LER1 LSR1 LSP LSRB LSRC LSRA LER2 LSP