Protocolo de Reserva de Recursos - Resource Reservation Protocol

O Resource Reservation Protocol ( RSVP ) é um protocolo da camada de transporte projetado para reservar recursos em uma rede usando o modelo de serviços integrados . RSVP opera em IPv4 ou IPv6 e fornece configuração iniciada pelo receptor de reservas de recursos para fluxos de dados multicast ou unicast . Ele não transporta dados do aplicativo, mas é semelhante a um protocolo de controle, como ICMP ( Internet Control Message Protocol ) ou IGMP ( Internet Group Management Protocol ). RSVP é descrito em RFC 2205 .  

O RSVP pode ser usado por hosts e roteadores para solicitar ou fornecer níveis específicos de qualidade de serviço (QoS) para fluxos de dados de aplicativos . RSVP define como os aplicativos fazem reservas e como eles podem abrir mão dos recursos reservados quando não forem mais necessários. As operações RSVP geralmente resultam na reserva de recursos em cada nó ao longo de um caminho. RSVP não é um protocolo de roteamento, mas foi projetado para interoperar com os protocolos de roteamento atuais e futuros.

O RSVP por si só raramente é implantado em redes de telecomunicações. Em 2003, o esforço de desenvolvimento foi mudado de RSVP para RSVP-TE para engenharia de teletráfico . Próximas etapas na sinalização (NSIS) foi uma substituição proposta para RSVP.

Suíte de protocolo de Internet
Camada de aplicação
Camada de transporte
Camada de Internet
Camada de link

Atributos principais

  1. RSVP solicita recursos para fluxos simplex : um fluxo de tráfego em apenas uma direção do emissor para um ou mais receptores.
  2. RSVP não é um protocolo de roteamento, mas funciona com protocolos de roteamento atuais e futuros.
  3. O RSVP é orientado para o receptor de forma que o receptor de um fluxo de dados inicie e mantenha a reserva de recursos para esse fluxo.
  4. O RSVP mantém o estado suave (a reserva em cada nó precisa de uma atualização periódica) das reservas de recursos do host e dos roteadores, suportando, portanto, a adaptação automática dinâmica às mudanças na rede.
  5. O RSVP fornece vários estilos de reserva (um conjunto de opções de reserva) e permite que estilos futuros sejam adicionados em revisões de protocolo para se adequar a aplicativos variados.
  6. O RSVP transporta e mantém os parâmetros de controle de tráfego e política opacos ao RSVP.

História e padrões relacionados

Os conceitos básicos do RSVP foram propostos originalmente em 1993.

RSVP é descrito em uma série de documentos RFC da IETF:

  • RFC  2205 : A especificação funcional da versão 1 foi descrita no RFC 2205 (setembro de 1997) pela IETF . A versão 1 descreve a interface para controle de admissão (tráfego) que se baseia "apenas" na disponibilidade de recursos. Posteriormente, a RFC2750 estendeu o suporte ao controle de admissão.
  • A RFC  2210 define o uso de RSVP com RFC 2211 de carga controlada e serviços de controle de QoS RFC 2212 garantidos. Mais detalhes em Serviços Integrados . Também define o uso e o formato de dados dos objetos de dados (que transportam informações de reserva de recursos) definidos pelo RSVP na RFC 2205.
  • RFC  2211 especifica o comportamento do elemento de rede necessário para fornecer serviços de carga controlada.
  • O RFC  2212 especifica o comportamento do elemento de rede necessário para fornecer serviços de QoS garantidos.
  • O RFC  2750 descreve uma extensão proposta para apoiar o controle de admissão baseado em políticas genéricas no RSVP. A extensão incluiu uma especificação de objetos de política e uma descrição sobre como lidar com eventos de política. (Janeiro de 2000).
  • RFC  3209 , "RSVP-TE: Extensions to RSVP for LSP Tunnels" (dezembro de 2001).
  • RFC  3473 , "Extensões de Protocolo de Engenharia de Tráfego de Reserva de Sinalização (GMPLS) Generalized Multi-Protocol Label Switching (RSVP-TE)" (janeiro de 2003).
  • RFC  3936 , "procedimentos para modificar a R esource re S er V ção P rotocolo (RSVP)" (Outubro de 2004), descreve as melhores práticas e especifica procedimentos actuais para a modificação de RSVP.
  • RFC  4495 , "Uma extensão do protocolo de reserva de recursos (RSVP) para a redução da largura de banda de um fluxo de reserva" (maio de 2006), estende o RSVP para permitir que a largura de banda de uma reserva existente seja reduzida em vez de destruir a reserva.
  • RFC  4558 , "Node-ID Based Resource Reservation Protocol (RSVP) Hello: A Clarification Statement" (junho de 2006).

Conceitos chave

Os dois conceitos-chave do modelo de reserva RSVP são flowspec e filterspec .

Flowspec

RSVP reserva recursos para um fluxo. Um fluxo é identificado pelo endereço de destino, o identificador do protocolo e, opcionalmente, a porta de destino. Na comutação de rótulo multiprotocolo (MPLS), um fluxo é definido como um caminho de comutação de rótulo (LSP). Para cada fluxo, o RSVP também identifica a qualidade de serviço (QoS) específica exigida pelo fluxo. Essas informações de QoS são chamadas de flowspec e o RSVP passa o flowspec do aplicativo para os hosts e roteadores ao longo do caminho. Esses sistemas, então, analisam o flowspec para aceitar e reservar os recursos. Um flowpec consiste em:

  1. Classe de serviço
  2. Especificação de reserva - define o QoS
  3. Especificação de tráfego - descreve o fluxo de dados

Filterpec

O filterspec define o conjunto de pacotes que devem ser afetados por um flowspec (ou seja, os pacotes de dados para receber o QoS definido pelo flowspec). Uma especificação de filtro normalmente seleciona um subconjunto de todos os pacotes processados ​​por um nó. A seleção pode depender de qualquer atributo de um pacote (por exemplo, o endereço IP do remetente e a porta).

Os estilos de reserva RSVP definidos atualmente são:

  1. Filtro fixo - reserva recursos para um fluxo específico.
  2. Explícito compartilhado - reserva recursos para vários fluxos e todos compartilham os recursos
  3. Filtro curinga - reserva recursos para um tipo geral de fluxo sem especificar o fluxo; todos os fluxos compartilham os recursos

Uma solicitação de reserva RSVP consiste em um flowspec e um filterspec e o par é chamado de flowdescriptor . O flowspec define os parâmetros do escalonador de pacotes em um nó e o Filterspec define os parâmetros no classificador de pacotes.

Mensagens

Existem dois tipos principais de mensagens:

  • Mensagens de caminho ( caminho )
A mensagem do caminho é enviada do host remetente ao longo do caminho de dados e armazena o estado do caminho em cada nó ao longo do caminho.
O estado do caminho inclui o endereço IP do nó anterior e alguns objetos de dados:
  1. modelo de remetente para descrever o formato dos dados do remetente na forma de um Filterspec
  2. remetente tspec para descrever as características de tráfego do fluxo de dados
  3. adspec que carrega dados de publicidade (consulte RFC 2210 para obter mais detalhes).
  • Mensagens de reserva ( resv )
A mensagem resv é enviada do receptor para o host do remetente ao longo do caminho de dados reverso. Em cada nó, o endereço IP de destino da mensagem resv mudará para o endereço do próximo nó no caminho reverso e o endereço IP de origem para o endereço do endereço do nó anterior no caminho reverso.
A mensagem resv inclui o objeto de dados flowspec que identifica os recursos de que o fluxo precisa.

Os objetos de dados em mensagens RSVP podem ser transmitidos em qualquer ordem. Para obter a lista completa de mensagens RSVP e objetos de dados, consulte RFC 2205.

Operação

Um host RSVP que precisa enviar um fluxo de dados com QoS específico transmitirá uma mensagem de caminho RSVP a cada 30 segundos que percorrerá as rotas unicast ou multicast pré-estabelecidas pelo protocolo de roteamento de trabalho. Se a mensagem do caminho chegar a um roteador que não entende RSVP, esse roteador encaminhará a mensagem sem interpretar o conteúdo da mensagem e não reservará recursos para o fluxo.

Aqueles que desejam ouvi-los enviam uma mensagem resv (abreviação de reserva ) correspondente, que então rastreia o caminho de volta ao remetente. A mensagem resv contém um flowspec . A mensagem resv também possui um objeto filterspec ; define os pacotes que receberão o QoS solicitado definido no flowspec. Uma especificação de filtro simples pode ser apenas o endereço IP do remetente e, opcionalmente, sua porta UDP ou TCP. Quando um roteador recebe a mensagem resv RSVP, ele irá:

  1. Faça uma reserva com base nos parâmetros do pedido. O controle de admissão processa os parâmetros de solicitação e pode instruir o classificador de pacotes a manipular corretamente o subconjunto selecionado de pacotes de dados ou negociar com a camada superior como o tratamento de pacotes deve ser executado. Se não puder ser compatível, uma mensagem de rejeição será enviada para informar ao ouvinte.
  2. Encaminhe a solicitação upstream (na direção do remetente). Em cada nó, o flowspec na mensagem resv pode ser modificado por um nó de encaminhamento (por exemplo, no caso de uma reserva de fluxo multicast, as solicitações de reserva podem ser mescladas).
  3. Os roteadores então armazenam a natureza do fluxo e, opcionalmente, configuram o policiamento de acordo com o flowspec para ele.

Se nada for ouvido por um determinado período de tempo, a reserva expirará e será cancelada. Isso resolve o problema se o remetente ou o receptor travar ou forem desligados sem antes cancelar a reserva.

Outras características

Integridade
As mensagens RSVP são anexadas a um resumo da mensagem criado pela combinação do conteúdo da mensagem e uma chave compartilhada usando um algoritmo de resumo da mensagem (geralmente MD5 ). A chave pode ser distribuída e confirmada usando dois tipos de mensagem: solicitação de desafio de integridade e resposta de desafio de integridade .
Relatório de erros
Quando um nó detecta um erro, uma mensagem de erro é gerada com um código de erro e é propagada upstream no caminho reverso para o remetente.
Informações sobre o fluxo de RSVP
Dois tipos de mensagens de diagnóstico permitem que um operador de rede solicite as informações de estado RSVP em um fluxo específico.
Instalação de diagnóstico
Uma extensão do padrão que permite ao usuário coletar informações sobre o estado RSVP ao longo de um caminho.

RFCs

Referências

  • John Evans; Clarence Filsfils (2007). Implantando QoS IP e MPLS para redes multisserviço: teoria e prática . Morgan Kaufmann. ISBN 978-0-12-370549-5.

links externos