Serviços Integrados
RSVP
Edgard Jamhour
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.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})