1.Introdução.

O protocolo de reserva de recursos ou Resource Reservation Protocol(RSVP), é um protocolo de controle de rede que habilita os aplicativos da internet a obterem qualidades de serviço especiais(QoSs) para o seu fluxo de dados. O RSVP não é um protocolo de roteamento; ao invés disso, ele trabalha em conjunto com os protocolos de roteamento e instala o equivalente a listas dinâmicas de acesso ao longo das rotas que os protocolos de roteamento calculam. O RSVP foi originalmente desenvolvido pelos pesquisadores da Universidade do Sul da Califórnia (USC), Information Sciences Institute(ISI) e pelo Xerox Palo Alto Reaserch Center. O Internet Task Force( IETF) está no momento trabalhando na padronização através de um grupo de trabalho em RSVP.

A figura 1 mostra um exemplo de implementação do ambiente RSVP.

Podemos dizer que o RSVP tem como principais características:

• O RSVP faz reservas de recursos tanto para aplicações unicast como também para aplicações multicast do tipo muitos para muitos.
• O RSVP é simplex, isto é, faz reservas para um fluxo unidirecional de dados.
• O RSVP é orientado ao receptor, isto é, O receptor do fluxo de dados inicializa e mantém a reserva de recursos usado no fluxo.
• O RSVP mantém um estado "soft" nos routers e nos hosts, o que é utilizado para possibilitar uma mudança dinâmica dos membros nos membros das rotas, bem como das características das rotas.
• O RSVP não é um protocolo de roteamento, mas depende de dos mesmos.
• O RSVP transporta e mantém um controle de tráfico e controle político. O controle de tráfico determina quando um nó tem recursos suficientes para suprir uma QoS requisitada. O controle político determina quando um usuário tem permissão para fazer a reserva.
• O RSVP possui vários modelos de reserva ou estilos que se adaptam a uma variedade de aplicações.
• RSVP prove uma operação transparente através de router que não o suportam.
• O RSVP suporta tanto o Ipv4 quanto o Ipv6.

No RSVP, um fluxo de dados é uma seqüência de mensagens que possuem o mesma fonte, destino(um ou mais) e qualidade de serviço(QoS). A QoS requerida é comunicada através da rede por meio de uma especificação de fluxo, ou flowspec , que é uma estrutura de dados utilizada pelos hosts da rede para requisitarem serviços especiais da rede.

O RSVP suporta três tipos de tráfico: Melhor esforço, sensível a taxa e sensível a atraso. Os tipos de serviço de fluxo de dados usados para suportar esses tipos de dados dependem do RSVP implementado. Uma melhor descrição de QoS é dada mais a diante.

O tráfico tipo melhor esforço é tráfico IP tradicional. Exemplos de aplicativos incluem transferência de arquivos, transmissões de E-mail, logins interativos, etc. Serviços implementados utilizando tráfico do tipo melhor esforço são chamados Serviços de melhor esforço.

Tráficos do tipo sensíveis a taxa abrem mão de uma taxa mais rápida em troca de uma taxa constante.Geralmente são aplicações que foram portadas de uma rede de circuito chaveado( como ISDN ou ATM) para uma rede de Datagramas (IP).

Aplicações dessa categoria são chamadas de Serviços de taxa de bit garantida.

Tráfico sensível a atraso é aquele que requer o menor atraso possível na entrega da informação, e varia a sua taxa de transmissão de acordo com essa necessidade. MPEG-II vídeo, por exemplo, tem uma taxa entre 3 a 7 Mbps , de acordo com a variação de uma figura para outra.

Serviços que suportam este tráfico são chamados de Serviços de controle de atraso.

O fluxo de dados RSVP é geralmente caracterizado por sessões, sobre as quais os pacotes de dados fluem. Uma sessão é um fluxo de dados um endereço particular de destino e protocolo de camada de transporte. Podemos dizer que uma sessão RSVP é definida pelo trio ( DestAddress, ProtocolId, DstPort).O DestAdress é o endereço IP de destino dos pacotes de dados, que pode ser um endereço unicast ou multicast, ProtocolId é o ID do protocolo IP utilizado, e o parâmetro opcional DstPort é a "porta geral de destino". Os pacotes de dados de uma sessão em particular são direcionados para o mesmo endereço IP de destino ou para uma porta geral de destino. O endereço IP de destino pode ser um grupo de endereços para entregas em multicast ou o endereço unicast de um simples destinatário. Uma porta geral de destino pode ser definida por intermédio de campo de destino da porta UDP/TCP, um campo equivalente em outro protocolo de transporte, ou alguma informação especifica do aplicativo.

A distribuição de dados RSVP é feita tanto por via multicast quanto unicast. Tráficos multicast envolvem uma cópia de cada pacote de dados de um simples transmissor para múltiplos destinatários. O tráfico unicast por sua vez envolvem um simples destinatário. Mesmo que o endereço de destino seja unicast, pode conter múltiplos receptores, que se distinguem por uma porta geral. Múltiplos transmissores podem existir para um destino unicast, sendo que neste caso o RSVP pode providenciar reservas para transmissão multiponto – para – ponto.

Cada transmissor e receptor RSVP pode corresponder a um único host internet. Um host simples, em todo caso, pode conter múltiplos transmissores e receptores lógicos, que podem ser identificados por portas generalizadas.

No contexto do RSVP, a qualidade de serviço(QoS) é um atributo especificado nas especificações de fluxo que é utilizada para determinar o modo que a troca de dados e gerenciada pelas entidades participantes(routers, receptores e transmissores).O RSVP é usado para especificar a QoS tanto do host quando do router. Os hosts usam o RSVP para requisitar um nível de QoS da rede em nome de um fluxo de dados de uma aplicação. Routers usam RSVP para entregar requisições de QoS para outros routers ao longo do caminho do fluxo de dados. Fazendo assim, RSVP mantém o estado do router e do host para prover o serviço requisitado.

Uma requisição elementar RSVP consiste de um flowspec junto com um filterspec; este par é chamado descrição do fluxo. O flowspec especifica ao QoS desejado. O filterspec, junto com uma especificação da sessão, define o conjunto de pacotes de dados(o fluxo) que receberá o QoS definido pelo flowspec. Como o próprio nome diz, ele age como um filtro, separando os pacotes que interessam. Dados que pertencem a uma determinada sessão, mas que não se enquadram em nenhum tipo de filterspec são tratados como tráfico de melhor esforço.Normalmente, os filterspec são o endereço IP da fonte ou número de porta UDP/TCP.

As mensagens RSVP que transportam as requisições de reserva originadas nos receptores são passadas para cima (Isto é, em direção ao transmissor).

Para iniciar uma sessão multicast RSVP, um receptor primeiro se junta a um grupo multicast especificado por um endereço IP de destino através do uso do Internet Group Menbership Protocol(IGMP). No caso de uma sessão unicast, roteadores unicast disponibilizam as funções que o IGMP, em conjunto com Protocol Independent Multicast(PIM), disponibilizam no caso do multicast. Depois do receptor se juntar a um grupo, um potencial transmissor começa a mandar mensagens de caminhos RSVP para o endereço IP de destino. A aplicação de recepção recebe uma mensagem de caminho e começa a mandar requerimentos apropriados de reserva especificando o desejado fluxo descrito usando o RSVP. Depois da aplicação transmissora receber uma mensagem de requisição de reserva, ele começa a mandar os pacotes de dados.

6.Estilo de reserva RSVP

Estilo de reserva se refere a um conjunto de opções de controles que especificam um número de parâmetros suportados. O RSVP suporta duas maiores classes de reserva: reserva distinta e reserva compartilhada. Reserva distinta instala um fluxo para cada transmissor relevante em cada sessão. Uma reserva compartilhada é usada por um conjunto de transmissores que se sabe que não interferem uns nos outros. A figura 2 ilustra o estilo de reserva distinto e compartilhado no contexto do seu escopo. Cada combinação de estilo de reserva suportado e escopo é descrita seguindo se a ilustração.

6.1.Estilo filtro coringa (WF)

O estilo filtro coringa (WF) especifica uma reserva compartilhada com uma extensão coringa. Com uma reserva estilo WF, uma simples reserva é criada no qual o fluxo de todos transmissores superior é misturado. Reservas podem ser pensadas como sendo um duto compartilhado cuja largura é da maior requisição de recursos do link de todos os receptores, independente do número de transmissores. A reserva se propaga para cima através de todos os transmissores hosts e é automaticamente estendida para novos transmissores que possam aparecer.

6.2Estilo de filtro fixo (FF)

O estilo de filtro fixo(FF) especifica um reserva distinta com uma extensão explícita. Com uma reserva estilo FF, uma requisição de reserva distinta é criada pólos pacotes de dados de um transmissor particular.A extensão de reserva é determinada por uma lista explícita de transmissores.A reserva total em um link para uma dada sessão é o total da reserva FF de todos transmissores requisitados. Reserva FF que são requisitadas por diferentes receptores, mas que seletam o mesmo transmissor,em todo caso, precisam se juntar para compartilhar uma simples reserva em um dado nó.

6.3.Estilo Compartilhamento explicito

O estilo de reserva compartilhamento explicito(SE ) especifica um ambienta de reserva compartilhada com um escopo explicito de reserva. O estilo SE cria uma reserva simples no qual todos os fluxos dos servidores superiores são misturados. Como no caso de uma reserva FF, o conjunto de servidores é especificado implicitamente pelo receptor que está fazendo a reserva.

6.4.Implicações do estilo de reserva RSVP

WF e SF são ambas reservas compartilhadas que são apropriadas para aplicações multicast nos quais múltiplas fontes de dados dificilmente irão transmitir simultaneamente. Um exemplo pode ser áudio conferência, onde um limitado número de pessoas fala de cada vez. Cada receptor pode requisitar reservas WF ou SE duplas por canal de áudio. O estilo FF cria reservas independentes para o fluxo de diferentes transmissores. O estilo FF é mais apropriado para sinais de vídeo. Infelizmente, não é possível juntas reservas compartilhadas com reservas distintas.

No contexto de RSVP, um soft state se refere a um estado no router e nos nós fim que podem ser adaptados através de certas mensagens RSVP. As características soft state permitem a uma rede RSVP suportar mudanças dinâmicas nos membros do grupo e adaptam as mudanças na rota. Em geral, o soft state é mantido por uma rede baseada em RSVP para habilitar a rede a mudar o estado sem consultar os pontos finais. Este contraste com um circuito de arquitetura de conexões no qual um ponto final faz uma chamada e, no caso de falha, faz uma nova chamada.

Mecanismos RSVP provêem uma facilidade geral por criar e manter um estado de reserva distribuído por uma junção de multicast e caminhos de entrega de unicast.

Para manter um estado de reserva, RSVP localiza um estado soft no holter e nos nós host. O RSVP soft state é criado e periodicamente confirmado por mensagens de path e mensagens de pedido de reserva. O estado é apagado se nenhuma mensagem de refresh chega antes do vencimento de um intervalo de cleanup. O soft state também pode ser apagado como o resultado de uma mensagem de teardown explícita. RSVP verifica o soft state periodicamente para construir e passar adiante o path e a mensagem de requisição.

Quando uma rota mudar, a próxima mensagem de path inicializa o estado de caminho na rota nova. Mensagens de reserva futuras estabelecem um estado de reserva. O estado no segmento não mais utilizado é descartado.. (A especificação de RSVP requer iniciação de reservas novas pela rede dois segundos depois de uma mudança de topologia.)

Quando mudanças de estado acontecerem, o RSVP propaga essas mudanças de fim a fim dentro de uma rede de RSVP sem demora. Se o estado recebido diferir do estado armazenado, o estado armazenado é atualizado.

Sobre o RSVP, recursos são reservados para um fluxo de dados simples(isto é, para um fluxo de dados unidirecional). Cada transmissor é logicamente distinto do receptor, mas cada aplicação pode agir como transmissor e como receptor. Os receptores são responsáveis pelas requisições de reserva. A figura 3 apresenta o ambiente geral de aplicação.

A inicialização RSVP começa quando um router RSVP consulta o protocolo local de roteamento para obter as rotas. Um host manda mensagens para se juntar a um grupo multicast e mensagens para reservar recursos ao longo do path de entrega para esse grupo. Cada router que é capaz de participar na reserva de recursos passa as mensagens que chegam para um classificador de pacotes. O classificador de pacotes determina a rota e a qualidade de serviço para cada pacote.

Podemos dizer que os passos são os seguintes:

• Um receptor se junta a um grupo multicast especificado pelo seu DestAddress, usando IGMP(Internet Group Member Protocol).
• Um transmissor em potencial começa a mandar Path RSVP para o DestAddress.
• Um Aplicação no receptor recebe uma mensagem de Path.
• Um receptor começa a mandar mensagens de reserva apropriadas , especificando o fluxo desejado.
• Um transmissor recebe a mensagem de reserva.
• Um transmissor começa a mandar os pacotes de dados.

10. Tunelamento RSVP

É impossível implementar o RSVP ou qualquer novo protocolo em toda a internet de uma vez só. Na verdade, é bem possível que o RSVP nunca seja implementado em toda a rede. Portanto , o RSVP precisa dispor de mecanismos para funcionarem em nuvens não RSVP. Nuvens não RSVP são incapazes de proverem reservas de recursos, portanto não podem serem feitas garantias de serviços. Porém, se essa nuvem tiver uma capacidade excedente, ela poderá prover serviços aceitáveis.

O RSVP suporta tunelamentos, Que ocorrem automaticamente através de nuvens não RSVP. Quando uma mensagem de path atravessa uma nuvem não RSVP, a mensagem de path armazena o endereço IP do último router RSVP, o que habilita as mensagens de requisição atravessarem a nuvem não RSVP, chegando a este último host RSVP, e a partir daí continuar a reserva.

O RSVP suporta quatro tipos de mensagens básicas: mensagem de requisição de reserva, mensagem de path, erro e mensagens de confirmação e mensagens de teardown.

11.1 Mensagens de requisição de reserva

São mandadas dos receptores até os transmissores. Esse mensagem é mandada seguindo o caminho inverso do Path através dos routers que os pacotes de dados usarão.Um mensagem de requisição de recursos precisa ser entregue para o transmissor para que este possa preparar os parâmetros apropriados de controle de tráfico.

11.2 Mensagens de Path

Uma mensagem RSVP de Path é manda por cada transmissor ao longo das rotas unicast e multicast .Uma mensagem de Path é usada para guardar os estado do caminho em cada nó.

O estado do caminho é usado para rotear as requisições de reserva na direção reversa.

11.3 Mensagens de erro e confirmação

Existem três tipos de mensagens de erro e confirmação: Path-error, reservation-request-error e reservation-request acknowledgment .

11.4 Mensagem de Teardown

Mensagens de teardown removem os estados de reserva sem ter que esperar por um período de timeout. Pode ser mandada tanto pelo receptor quanto pelo transmissor.

A figura 5 mostra um pacote RSVP

12.1 Campos do cabeçalho de mensagens RSVP

• Version- campo de 4 bits indicando a versão do protocolo
• Flags – Campo de 4 bits nos quais os flags ainda não foram definidos.
• Type – Campo de 8 bits com 6 possíveis valores, mostrados na figura 6.
• Checksum – Campo de 16 bits representando o checksum dos conteúdos da mensagem RSVP
• Length – Campo de 16 bits representando o tamanho deste pacote RSVP em bytes, incluindo o cabeçalho comum e os objetos de tamanho variável que se seguem.
• Send TLL – campo de 8 bits indicando o IP time-to –live (TTL) valor com o qual a mensagem foi mandada.
• Message ID – campo de 32 bits provendo um rótulo compartilhado por todos os fragmentos de uma mensagem de um dado próximo/anterior RSVP hop.
• More Fragments (MF) Flag – Bit de ordem baixa de uma palavra de um byte com os outros 7 bits reservados.
• Fragment OffSet – campo de 24 bits representando o offset byte do fragmento na mensagem.

• Length – Campo de 16 bits contendo o tamanho total do objeto em bytes
• Class-Num- Identifica a classe do objeto. Cada classe de objeto tem um nome. Ver figura 7.
• C-Type – Tipo do objeto, único dentro do Class-Num. O máximo tamanho do conteúdo do objeto é 65528 bytes.
• Object Contents- Conteúdo dos objetos.

The Internet Engineering Task Force Home Page (IETF)

http://www.ietf.org;

http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/rsvp.htm;

http://www.isi.edu/div7/rsvp/overview.html;

http://www.whatis.com/rsvp.htm;