“RFC 2205 -- Resource ReSerVation
Protocol (RSVP) -- Version 1
Functional Specification
UNIVERSIDADE FEDERAL DO PARANÁ
MESTRADO EM TELECOMUNICAÇÕES
TE723 - COMUNICAÇÃO DE DADOS
Ronald Ferdinand Stahlke
Curitiba, janeiro de 2004
“
Índice













O RSVP
Fluxo de Dados
Modelo de reserva
Estilos de reserva
Tipos de estilos
Mensagens do RSVP
Fusão de Flowspecs e Soft State
Teardown
Erros
Controle de política
Segurança
Nuvens não-RSVP
Modelo do Host
O RSVP











Protocolo de configuração de reserva de recursos
Utilizado por um host para solicitar uma qualidade de serviço específica
da rede para um determinado fluxo de dados
Faz alocações de recursos para aplicações unicast e multicast,
adaptando-se dinamicamente a mudanças de grupos de sociedade bem
como a variações de rotas.
Simplex.
Orientado ao receptor.
Mantém um "Soft State" em roteadores e hosts - adaptação automática
às mudanças de roteamento.
Não é um protocolo de roteamento mas depende destes.
Transporta e mantém os parâmetros de controle de tráfego e política de
controle - são transparentes ao RSVP.
Fornece vários modelos de reserva "estilos" para se ajustar a aplicações.
Provê operação transparente através de roteadores que não o suportam.
Suporta IPv4 e IPv6.
Fluxo de Dados



O RSVP define uma "sessão" como um fluxo de dados
com um destino e protocolo de transporte-camada.
O RSVP trata cada sessão de maneira independente.
Uma sessão de RSVP é definida pelo trio: (DestAddress,
ProtocolId, [, DstPort]).
– DestAddress, endereço IP de destino dos pacotes de dados,
unicast ou multicast.
– ProtocolId é o ID do protocolo IP.
– DstPort (opcional) é um porto "de destino geral”, ou seja, algum
ponto de demultiplexação adicional no transporte ou na camada
de protocolo de aplicação.
Fluxo de dados
• Fluxo de pacotes em uma sessão RSVP, multicast.
• Nuvem -> Representa a malha de distribuição criada pelo
roteamento multicast. Remete uma cópia de cada pacote de dados
de um remetente Si para todo receptor Rj;
* Uma sessão unicast tem um único receptor R.
Modelo de reserva




Um pedido de reserva RSVP consiste em um:
"flowspec" + "especificação de filtro” = descrição de fluxo.
– Flowspec especifica um QoS desejado. Utilizado para ajustar
parâmetros no nó do agendador de pacote.
– Especificação do filtro + especificação da sessão, define o conjunto de
pacotes de dados para receber o QoS definido pelo flowspec. É usado
para ajustar parâmetros no classificador de pacote.
Pacotes de dados endereçados a uma dada sessão mas não se
encaixam em nenhum dos filtros de especificação são tratados
como tráfego de melhor-esforço.
O flowspec em um pedido de reserva inclui, em geral, uma classe
de serviço e dois conjuntos de parâmetros numéricos:
– (1) “Rspec” (R para ‘Reserva’) que define o QoS desejado,
– (2) “Tspec” (T para ‘Tráfego’) que descreve o fluxo de dados.

* O formato exato de uma especificação de filtro depende se é o
IPv4 ou o IPv6 que está em uso.
Modelo de reserva

Pelo fato de os números de portos UDP/TCP serem usados para
classificação de pacotes, cada roteador deve ser capaz de examinar
estes campos. Isto levanta três problemas em potencial:
1. Deve-se evitar a fragmentação do IP de um fluxo de dados para o
qual uma reserva de recurso é desejada.
2. O IPv6 insere um número variável de cabeçalhos de camada
Internet de comprimento variável antes do cabeçalho de transporte,
aumentando a dificuldade e o custo de classificação do pacote para
QoS.
3. A segurança a nível de IP, sob o IPv4 ou IPv6, pode codificar todo
o cabeçalho de transporte, escondendo os números de porto dos
pacotes de dados de roteadores intermediários.
Modelo de reserva

Os pedidos de reserva => receptores para emissores. A cada nó
intermediário, ocorrem duas ações:
1. Faz uma reserva em uma conexão
– O processo RSVP passa o pedido ao controle de admissão e ao controle
de política.
– Falha, a reserva é recusada -> mensagem de erro
– Sucesso, o nó configura o classificador de pacote - selecionar os
pacotes definidos pelo filtro de especificação, obtendo o QoS definido
pelo flowspec.
2. Encaminha o pedido adiante
– O pedido é propagado aos remetentes, dentro do “escopo” do pedido.
– Obs. O pedido de reserva encaminhado pode diferir do recebido pois o
controle de tráfego pode modificar o flowspec a cada salto.
Modelo de reserva




O receptor pode solicitar uma mensagem de confirmação de
(provável) instalação na rede.
Um pedido com sucesso se propaga ao longo da árvore de multicast
até alcançar um ponto onde uma reserva existente é igual ou maior
que a solicitada. Neste ponto, o pedido é fundido com a reserva e
não precisa mais ser encaminhado;
O nó pode retornar uma mensagem de confirmação de reserva
Obs. Não há garantia de que o serviço pedido está presente em
todo o caminho até o emissor.
Estilos de reserva


Um pedido de reserva inclui um conjunto
de opções que são chamadas de “estilo”
de reserva.
Cuida do tratamento de reservas para
diferentes remetentes dentro da mesma
sessão:
– Estabelece uma reserva “distinta” para
cada remetente,
– Faz uma única reserva “compartilhada”
pelos pacotes dos remetentes
selecionados.

Controla a seleção de remetentes;
– Lista “explícita” dos remetentes
selecionados.
– “Wildcard” seleciona implic os remetentes
Tipos de estilos




Filtro Wildcard (WF)
Implica em: reserva "compartilhada" e seleção de rem. “wildcard".
WF (* {Q}), * - seleção wildcard e Q - flowspec.
Filtro Fixo (FF)
Implica em: reservas “distintas" e seleção de remetente “explícita".
FF (S{Q}), S - remetente selecionado Q - flowspec
Compartilhamento Explícito (SE)
Implica em: reserva "compartilhada" e seleção de rem. “explícita”.
SE ((S1,S2,...) {Q})
As regras do RSVP não permitem a fusão de reservas
compartilhadas com reservas distintas. Também não permitem a
fusão de uma seleção de remetentes explícitos com wildcard.
Mensagens do RSVP


Há dois tipos fundamentais de mensagens RSVP: Resv e Path.
Cada host receptor envia mensagens de pedido de reserva RSVP
(Resv) até chegar aos hosts remetentes.
– Criam e mantém o “estado de reserva” em cada nó ao longo do(s)
caminho(s).
– Configuram os parâmetros de controle de tráfego para o 1o salto.

Cada host remetente RSVP transmite mensagens RSVP "Path“.
– Armazenam o Path state em cada nó ao longo do caminho. inclui o
endereço IP unicast do nó do salto anterior.

Uma mensagem Path também contém:
– Template do Remetente (formato dos pacotes gerados pelo remetente)
– Remetente Tspec (características de tráfego do fluxo de dados) usado
pelo controle de tráfego p/ evitar sobre-reserva.
– Adspec, carregar um pacote com informação de aviso OPWA,
Fusão de Flowspecs e Soft State





Uma mensagem de Resv encaminhada por um salto anterior
leva um flowspec que é o "maior" dos flowspecs pedidos pelos
próximos saltos. Diz-se então que os flowspecs foram fundidos.
O RSVP adota uma abordagem "Soft State" no gerenciamento
do estado de reservas em roteadores e hosts.
O RSVP Soft State é criado e periodicamente atualizado pelas
mensagens de Path e de Resv.
O estado é apagado por timeout ou mensagem de teardown
O estado mantido pelo RSVP é dinâmico; para mudar um
conjunto de remetentes Si ou mudar qualquer pedido de QoS,
um host simplesmente começa a enviar mensagens atualizadas
de Path e/ou de Resv.
Teardown

Há dois tipos de mensagens de RSVP teardown:
– PathTear – trafega aos receptores abaixo de seu ponto de início e
apaga o estado de caminho e estados de reserva dependentes, no
caminho.
– ResvTear - apaga o estado de reserva em direção a todos os
remetentes acima de seu ponto de início.

Pode ser iniciada por uma aplicação no final do sistema (remetente
ou receptor), ou por um roteador como resultado de um timeout.
Erros



Há duas mensagens de erro RSVP:
PathErr -simples- enviada acima para o remetente que criou o erro,
não altera o estado de caminho dos nós pela qual ela passa.
ResvErr –complexa- pode ser o resultado da fusão de n pedidos, o
erro deve ser informado a todos os receptores responsáveis. A
fusão de pedidos heterogêneos cria o “killer reservation”, onde um
pedido pode negar serviço a outro.
–
1. O KR-I surge quando já existe uma reserva Q0 instalada. Se outro
receptor agora faz para uma reserva maior Q1>Q0, o resultado da
fusão de Q0 e Q1 pode ser rejeitado pelo controle de admissão em
algum nó acima. Tal fato não deve negar serviço a Q0.
– A solução: quando o controle de admissão falha para um pedido de
reserva, qualquer reserva já existente é mantida.
Controle de política




Pedidos de QoS mediados pelo RSVP permitem que usuários
obtenham acesso preferencial aos recursos da rede.
Criar uma política de controle para coibir abusos.
O RSVP fornece o “Policy data” que pode incluir credenciais que
identificam os usuários ou classes de usuários, cotas, etc.
Como os flowspecs, os "policy data” são transparentes ao RSVP que
simplesmente os passam ao controle de política.
Segurança

O RSVP levanta as seguintes questões de segurança:

Integridade das mensagens e autenticação de nó
– Pedidos de reserva corrompidos ou falsos. O RSVP utiliza um mecanismo
de autenticação salto-a-salto com codificação.

Autenticação de usuário
– O controle de política dependerá de uma autenticação do usuário. O
"policy data” pode incluir certificados de usuário protegidos por
criptografia.
Nuvens Não-RSVP


O protocolo RSVP deve fornecer uma operação correta mesmo quando
dois roteadores RSVP são unidos por uma nuvem qualquer de
roteadores não-RSVP.
Quando uma mensagem de Path atravessa uma nuvem não-RSVP, ela
leva ao próximo nó RSVP o endereço IP do último roteador RVSP
antes de ter entrado na nuvem e passa um flag ‘NonRSVP’ para o
mecanismo de controle de tráfego local.
Modelo do Host







Antes que uma sessão possa ser criada, uma identificação de sessão
(DestAddress, ProtocolId [, DstPort]) deve ser feita e comunicada a
todos os remetentes e receptores através de algum outro mecanismo.
Quando uma sessão RSVP está sendo configurada, os seguintes
eventos ocorrem nas pontas do sistema.
H1 - Um receptor se junta ao grupo de multicast especificado pelo
DestAddress, usando o IGMP.
H2 - Um remetente em potencial começa a enviar mensagens de Path
RSVP para o DestAddress.
H3 - Um aplicativo do receptor recebe uma mensagem de Path.
H4 - Um receptor começa a enviar as mensagens de Resv
apropriadas, especificando os descritores de fluxo desejados.
H5 - Um aplicativo do remetente recebe a mensagem de Resv.
H6 - Um remetente começa o envio dos pacotes de dados.
FIM