Nesta página
Visão geral do RSVP
Visão geral do RSVP
O protocolo RSVP é usado por roteadores para fornecer solicitações de qualidade de serviço (QoS) a todos os nós ao longo do(s) caminho(s) de fluxo de dados e para estabelecer e manter o estado para o serviço solicitado. As solicitações de RSVP geralmente resultam em reservas de recursos em cada nó ao longo do caminho de dados. O RSVP tem os seguintes atributos:
Faz reservas de recursos para fluxos de dados unidirecionais.
Permite que o receptor de um fluxo de dados inicie e mantenha a reserva de recursos usada para esse fluxo, conforme mostrado em Figura 1.
Mantém um estado suave em roteadores e hosts, oferecendo suporte gracioso para mudanças dinâmicas de associação e adaptação automática às mudanças de roteamento.
Depende dos protocolos de roteamento atuais e futuros, mas não é um protocolo de roteamento em si.
Oferece vários modelos ou estilos de reserva para atender a uma variedade de aplicativos.
Oferece suporte a pacotes IPv4 e IPv6 que podem ser enviados por LSPs sinalizados por RSVP.
Visão geral da operação do RSVP
O RSVP cria sessões independentes para lidar com cada fluxo de dados. Uma sessão é identificada por uma combinação do endereço de destino, uma porta de destino opcional e um protocolo. Em uma sessão, pode haver um ou mais remetentes. Cada remetente é identificado por uma combinação de seu endereço de origem e porta de origem. Um mecanismo fora de banda, como um protocolo de anúncio de sessão ou comunicação humana, é usado para comunicar o identificador de sessão a todos os remetentes e receptores.
Uma sessão de RSVP típica envolve a seguinte sequência de eventos:
Um remetente em potencial começa a enviar mensagens de caminho do RSVP para o endereço da sessão.
Um receptor, querendo participar da sessão, se registra se necessário. Por exemplo, um receptor em um aplicativo multicast se registraria no IGMP.
O receptor recebe as mensagens de caminho.
O receptor envia mensagens Resv apropriadas em direção ao remetente. Essas mensagens carregam um descritor de fluxo, que é usado por roteadores ao longo do caminho para fazer reservas em seus meios de mídia de camada de link.
O remetente recebe a mensagem Resv e depois começa a enviar dados do aplicativo.
Essa sequência de eventos não é necessariamente estritamente sincronizada. Por exemplo, os receptores podem se registrar antes de receber mensagens de caminho do remetente, e os dados do aplicativo podem fluir antes que o remetente receba mensagens Resv. Os dados do aplicativo que são entregues antes da reserva real contida na mensagem resv normalmente são tratados como tráfego de melhor esforço e não em tempo real sem garantia de CoS.
Entendendo o protocolo de sinalização RSVP
RSVP é um protocolo de sinalização que lida com a alocação de largura de banda e a verdadeira engenharia de tráfego em uma rede MPLS. Assim como o LDP, o RSVP usa mensagens de descoberta e anúncios para trocar informações de caminho de LSP entre todos os hosts. No entanto, o RSVP também inclui um conjunto de recursos que controlam o fluxo de tráfego através de uma rede MPLS. Considerando que o LDP está restrito a usar o caminho mais curto do IGP configurado como o caminho de trânsito pela rede, o RSVP usa uma combinação do algoritmo De caminho mais curto limitado primeiro (CSPF) e objetos de rota explícitos (EROs) para determinar como o tráfego é roteado pela rede.
As sessões básicas de RSVP são estabelecidas exatamente da mesma forma que as sessões de LDP são estabelecidas. Ao configurar o MPLS e o RSVP nas interfaces de trânsito apropriadas, você permite a troca de pacotes RSVP e a criação de LSPs. No entanto, o RSVP também permite configurar a autenticação de links, caminhos LSP explícitos e coloração de enlaces.
Este tópico contém as seguintes seções:
- Fundamentos RSVP
- Requisito de reserva de largura de banda
- Objetos de rota explícitos
- Caminho mais curto restringido primeiro
- Coloração de enlaces
Fundamentos RSVP
O RSVP usa fluxos unidirecionais e simples pela rede para executar sua função. O roteador de entrada inicia uma mensagem de caminho RSVP e a envia rio abaixo para o roteador de saída. A mensagem do caminho contém informações sobre os recursos necessários para a conexão. Cada roteador ao longo do caminho começa a manter informações sobre uma reserva.
Quando a mensagem de caminho chega ao roteador de saída, começa a reserva de recursos. O roteador de saída envia uma mensagem de reserva upstream para o roteador de entrada. Cada roteador ao longo do caminho recebe a mensagem de reserva e a envia upstream, seguindo o caminho da mensagem de caminho original. Quando o roteador de entrada recebe a mensagem de reserva, o caminho de rede unidirecional é estabelecido.
O caminho estabelecido permanece aberto enquanto a sessão de RSVP estiver ativa. A sessão é mantida pela transmissão de mensagens adicionais de caminho e reserva que relatam o estado da sessão a cada 30 segundos. Se um roteador não receber as mensagens de manutenção por 3 minutos, ele encerra a sessão de RSVP e redireciona o LSP por outro roteador ativo.
Requisito de reserva de largura de banda
Quando uma reserva de largura de banda é configurada, as mensagens de reserva propagam o valor da largura de banda em todo o LSP. Os roteadores devem reservar a largura de banda especificada em todo o link para o LSP específico. Se a reserva total de largura de banda exceder a largura de banda disponível para um determinado segmento de LSP, o LSP será redirecionado por outro LSR. Se nenhum segmento puder suportar a reserva de largura de banda, a configuração do LSP falhará e a sessão de RSVP não estiver estabelecida.
Objetos de rota explícitos
Objetos de rota explícitos (EROs) limitam o roteamento LSP a uma lista especificada de LSRs. Por padrão, as mensagens RSVP seguem um caminho que é determinado pelo caminho mais curto do IGP da rede. No entanto, na presença de um ERO configurado, as mensagens RSVP seguem o caminho especificado.
Os EROs consistem em dois tipos de instruções: saltos soltos e saltos rigorosos. Quando um salto solto é configurado, ele identifica um ou mais LSRs de trânsito pelos quais o LSP deve ser roteado. O IGP de rede determina a rota exata do roteador de entrada para o primeiro salto solto, ou de um salto solto para o outro. O salto solto especifica apenas que um LSR específico seja incluído no LSP.
Quando um salto rigoroso é configurado, ele identifica um caminho exato pelo qual o LSP deve ser roteado. Os EROs de salto rigoroso especificam a ordem exata dos roteadores através dos quais as mensagens RSVP são enviadas.
Você pode configurar EROs de salto solto e rigoroso simultaneamente. Neste caso, o IGP determina a rota entre saltos soltos e a configuração de salto rigoroso especifica o caminho exato para determinados segmentos de caminho LSP.
Figura 2 mostra um LSP típico com sinal RSVP que usa EROs.
Na topologia mostrada Figura 2, o tráfego é roteado do Host C1 para o Host C2. O LSP pode passar pelos roteadores R4 ou roteador R7. Para forçar o LSP a usar R4, você pode configurar um ERO de salto solto ou rigoroso que especifica R4 como um salto no LSP. Para forçar um caminho específico pelo Roteador R4, R3 e R6, configure um ERO rigoroso através dos três LSRs.
Caminho mais curto restringido primeiro
Enquanto os IGPs usam o algoritmo de caminho mais curto primeiro (SPF) para determinar como o tráfego é roteado dentro de uma rede, o RSVP usa o algoritmo De caminho mais curto limitado primeiro (CSPF) para calcular caminhos de tráfego que estão sujeitos às seguintes restrições:
Atributos LSP — grupos administrativos, como coloração de links, requisitos de largura de banda e EROs
Atributos do link — Cores em um link específico e largura de banda disponível
Essas restrições são mantidas no banco de dados de engenharia de tráfego (TED). O banco de dados fornece ao CSPF informações atualizadas de topologia, a largura de banda reservada atual de links e as cores do link.
Ao determinar qual caminho escolher, o CSPF segue essas regras:
Computa os LSPs um de cada vez, começando com o LSP de maior prioridade — aquele com o menor valor de prioridade de configuração. Entre os LSPs de igual prioridade, o CSPF começa com aqueles que têm o mais alto requisito de largura de banda.
Poda o banco de dados de engenharia de tráfego de links que não são totalmente duplex e não têm largura de banda reserva suficiente.
Se a configuração LSP incluir a
includedeclaração, pode todos os links que não compartilham cores incluídas.Se a configuração LSP incluir a
excludedeclaração, pode todos os links que contêm cores excluídas. Se um link não tiver uma cor, ele será aceito.Encontra o caminho mais curto em direção ao roteador de saída do LSP, levando em conta quaisquer EROs. Por exemplo, se o caminho deve passar pelo Roteador A, dois algoritmos SPF separados são computados: um do roteador de entrada ao roteador A e outro do roteador A até o roteador de saída.
Se vários caminhos tiverem custo igual, escolha aquele com endereço de última hora o mesmo que o destino do LSP.
Se vários caminhos de igual custo permanecerem, selecione o caminho com o menor número de saltos.
Se vários caminhos de igual custo permanecerem, aplicará regras de balanceamento de carga CSPF configuradas no LSP.
Coloração de enlaces
O RSVP permite configurar grupos administrativos para a seleção de caminhos de CSPF. Um grupo administrativo é tipicamente nomeado com uma cor, atribuído um valor numérico e aplicado à interface RSVP para o link apropriado. Números mais baixos indicam maior prioridade.
Após a configuração do grupo administrativo, você pode excluir, incluir ou ignorar links dessa cor no TED:
Se você excluir uma cor específica, todos os segmentos com um grupo administrativo dessa cor serão excluídos da seleção do caminho do CSPF.
Se você incluir uma cor específica, apenas esses segmentos com a cor apropriada serão selecionados.
Se você não excluir nem incluir a cor, as métricas associadas aos grupos administrativos e aplicadas nos segmentos específicos determinam o custo de caminho para esse segmento.
O LSP com o menor custo total de caminho é selecionado para o TED.
Extensões de protocolo RSVP-TE para FRR
Começando com o Junos OS Release 16.1, extensões de protocolo RSVP Traffic Engineering (TE) para suporte a RSVP independente de intervalo de atualização (RI-RSVP) definida RFC 8370 para proteção rápida de instalações de redirecionamento (FRR) foram introduzidas para permitir maior escalabilidade de caminhos comulados por rótulos (LSPs) tempos de convergência mais rápidos e diminuir a sobrecarga de mensagens de sinalização RSVP de atualizações periódicas. O Junos RSVP-TE é executado no modo RI-RSVP aprimorado, conhecido como RI-RSVP, que inclui extensões de protocolo para dar suporte ao RI-RSVP para desvio de instalações de FRR originalmente especificado no RFC 4090.
As extensões de protocolo RI-RSVP implementadas no Junos são totalmente compatíveis para trás. Em ambientes mistos, onde um subconjunto de LSPs atravessa nós que não incluem esse recurso, o Junos RSVP-TE em execução no modo FRR aprimorado desativará automaticamente as novas extensões de protocolo em suas trocas de sinalização com nós que não suportam as novas extensões.
Como parte do perfil aprimorado do FRR, várias mudanças foram feitas e novos padrões foram adotados. Estas estão listadas aqui.
O RSVP-TE executa o modo "aprimorado" FRR, ou RI-RSVP, por padrão, que inclui aprimoramentos para facilitar cenários escalonados. Essas novas extensões de protocolo podem ser desabilitadas em um roteador com o comando sem aprimoramento do desvio .
As extensões de redução de atualização do RSVP definidas na RFC 2961 são habilitadas por padrão. O usuário pode desabitá-los com o comando não confiável (veja abaixo).
Nota:Os Hellos baseados em nós são habilitados por padrão, pois extensões aprimoradas de FRR ou RI-RSVP exigem a troca de mensagens Hello baseadas em Nós. O Hellos baseado em nós pode ser desativado com
node-hellocomando. Como as extensões de redução de atualização e as mensagens hello baseadas em nós são essenciais para extensões aprimoradas de FRR ou RI-RSVP, a desativação de qualquer uma delas desativará automaticamente extensões aprimoradas de FRR no nó.O tempo de atualização padrão das mensagens RSVP aumentou de 30 segundos para 20 minutos.
O valor padrão para o keep-multiplier, que é 3, é aplicado ao novo tempo de atualização padrão.
A reversão local é desativada por padrão. A configuração CLI existente para nós Hellos ainda está disponível,
[edit protocols rsvp node-hello]mas a ação é redundante. Se habilitada, uma mensagem é exibida para indicar que a configuração não é necessária em conjunto com FRR aprimorada.
Os comandos existentes para desativar a confiabilidade da mensagem agora são usados para desativar a redução de atualização do RSVP. Para reverter para o padrão anterior que permite a redução de atualização, use a
deleteversão dos seguintes comandos:Configure
no-reliableuma determinada interface para desativar aprimoramentos de escalabilidade FRR automaticamente para todos os LSPs que atravessam a interface. Da mesma forma, executar o RSVP-TE sem aprimoramentos na proteção das instalações de FRR e, sem redução de atualização, desativar a redução de atualização em cada interface. Use um dos comandos mostrados aqui:[edit protocols rsvp interface name no-reliable][edit logical-systems name protocols rsvp interface name no-reliable]
A reinicialização graciosa e o roteamento ativo ininterrupto (NSR) não são suportados enquanto o LSP passa por reparo local ou enquanto o LSP é atualizado durante a sinalização LSP de backup. Essa limitação já existe na implementação porque o switchover GR ou NSR durante o reparo local do FRR torna o cenário de múltiplas falhas.
Os seguintes comandos operacionais foram atualizados para incluir novas informações sobre os novos procedimentos introduzidos para as extensões de protocolo RSVP TE para proteção das instalações do FRR.
show rsvp versionmostra se os procedimentos aprimorados de FRR estão habilitados.show rsvp neighbor detailmostra se os procedimentos aprimorados de FRR estão habilitados no vizinho.show rsvp interface detailapresenta estatísticas condicionais do PathTear.show rsvp statisticsdisplays enviados e recebidos estatísticas para PathTear condicional, juntamente com outras estatísticas.show rsvp session extensivemostra se o nó é um ponto de fusão e, se for, mostra o endereço ponto de reparo local (PLR).
As opções de configuração CLI anteriores para habilitar ou desativar o agrupamento de mensagens foram preteridas (as configurações existentes são aceitas, mas um aviso é exibido na saída de configuração do show). Esses comandos são os seguintes:
Implementação do protocolo RSVP do Junos OS
A implementação do RSVP pelo Junos oferece suporte ao RSVP versão 1. O software inclui suporte para todos os objetos obrigatórios e tipos de mensagens RSVP, e oferece suporte à integridade da mensagem e autenticações de nós por meio do objeto Integrity.
O objetivo principal do software Junos RSVP é oferecer suporte à sinalização dinâmica dentro de caminhos comuados por rótulos MPLS (LSPs). Oferecer suporte a reservas de recursos pela Internet é apenas uma finalidade secundária da implementação do Junos OS. Como o suporte a reservas de recursos é secundário, o software Junos RSVP não oferece suporte aos seguintes recursos:
Sessões de multicasting IP.
Controle de tráfego. O software não pode fazer reservas de recursos para sessões de vídeo ou áudio em tempo real.
Em relação ao mecanismo de protocolo, processamento de pacotes e objetos RSVP suportados, a implementação do software junos OS é interoperável com outras implementações RSVP.
Autenticação RSVP
O Junos OS oferece suporte tanto ao estilo de autenticação RSVP descrito no RFC 2747 (permitindo a compatibilidade entre vários fornecedores) quanto ao estilo de autenticação RSVP descrito no draft da Internet draft-ietf-rsvp-md5-03.txt. O Junos OS usa o estilo de autenticação descrito no draft da Internet draft-ietf-rsvp-md5-08.txt por padrão. Se o roteador receber uma autenticação RSVP no estilo RFC 2747 de um vizinho, ele mudará para este estilo de autenticação para aquele vizinho. O estilo de autenticação do RSVP para cada roteador vizinho é determinado separadamente.
RSVP e IGP Olá Pacotes e temporizadores
O RSVP monitora o status dos vizinhos de protocolo de gateway interior (IGP) (IS-IS ou OSPF) e conta com os protocolos IGP para detectar quando um nó falha. Se um protocolo de IGP declara um vizinho desativado (porque pacotes de olá não estão mais sendo recebidos), o RSVP também derruba esse vizinho. No entanto, os protocolos IGP e RSVP ainda agem de forma independente ao criar um vizinho.
No Junos OS, o RSVP normalmente conta com a detecção de pacotes de olá IGP para verificar se há falhas de nós. Configurar um curto espaço de tempo para os timers IS-IS ou OSPF permite que esses protocolos detectem falhas de nó rapidamente. Quando o nó falha ou uma falha de nó é detectada, uma mensagem de erro de caminho é gerada e, embora a sessão de RSVP seja baixa, os vizinhos do IGP permanecem em alta.
Os olás RSVP podem ser confiados quando o IGP não reconhece um vizinho específico (por exemplo, se o IGP não estiver habilitado na interface) ou se o IGP for RIP (não IS-IS ou OSPF). Além disso, o equipamento de outros fornecedores pode estar configurado para monitorar sessões de RSVP com base em pacotes de olá RSVP. Este equipamento também pode reduzir a sessão de RSVP devido à perda de pacotes de olá RSVP.
Não recomendamos configurar um temporizante RSVP curto. Se for necessária a descoberta rápida de um vizinho com falha, configure os temporizantes curtos de IGP (OSPF ou IS-IS).
O OSPF e o IS-IS têm infraestrutura para gerenciar rapidamente o envio e o recebimento de mensagens de olá de forma confiável, mesmo que os protocolos de roteamento ou algum outro processo estejam restringindo a capacidade de processamento do roteador. Sob as mesmas circunstâncias, o RSVP pode sair prematuramente, mesmo que o vizinho esteja funcionando normalmente.
Tipos de mensagem de RSVP
O RSVP usa os seguintes tipos de mensagens para estabelecer e remover caminhos para fluxos de dados, estabelecer e remover informações de reserva, confirmar o estabelecimento de reservas e relatar erros:
- Mensagens de caminho
- Mensagens resv
- Mensagens PathTear
- Mensagens resvTear
- Mensagens do PathErr
- Mensagens resvErr
- Mensagens ResvConfirm
Mensagens de caminho
Cada host de remetente transmite mensagens de caminho rio abaixo ao longo das rotas fornecidas pelos protocolos de roteamento unicast e multicast. As mensagens de caminho seguem os caminhos exatos dos dados do aplicativo, criando estados de caminho nos roteadores ao longo do caminho, permitindo assim que os roteadores aprendam o nó de salto anterior e próximo salto para a sessão. As mensagens de caminho são enviadas periodicamente para atualizar os estados de caminho.
O intervalo de atualização é controlado por uma variável chamada refresh-time, que é o temporizador de atualização periódico expresso em segundos. Um tempo de estado de caminho é estabelecido se um roteador não receber um número especificado de mensagens de caminho consecutivas. Esse número é especificado por uma variável chamada keep-multiplier. Os estados de caminho são mantidos por( +keep-multiplier 0,5) x 1,5 x refresh-time ) segundos.
Mensagens resv
Cada host receptor envia mensagens de solicitação de reserva (Resv) upstream em direção a aplicativos de remetentes e remetentes. As mensagens resv devem seguir exatamente o caminho inverso das mensagens de caminho. As mensagens resv criam e mantêm um estado de reserva em cada roteador ao longo do caminho.
As mensagens resv são enviadas periodicamente para atualizar os estados de reserva. O intervalo de atualização é controlado pela mesma variável de tempo de atualização, e os estados de reserva são mantidos para ( +keep-multiplier 0,5) x 1,5 x refresh-time ) segundos.
Mensagens PathTear
As mensagens PathTear removem (derrubar) estados de caminho, bem como estados de reserva dependentes em quaisquer roteadores ao longo de um caminho. As mensagens do PathTear seguem o mesmo caminho que as mensagens de caminho. Um PathTear normalmente é iniciado por um aplicativo de remetente ou por um roteador quando seu caminho está em estado de saída.
As mensagens PathTear não são necessárias, mas melhoram o desempenho da rede porque liberam recursos de rede rapidamente. Se as mensagens PathTear forem perdidas ou não forem geradas, os estados de caminho eventualmente ficam sem tempo quando não forem atualizadas e os recursos associados ao caminho forem liberados.
Mensagens resvTear
As mensagens resvTear removem os estados de reserva ao longo de um caminho. Essas mensagens viajam upstream em direção aos remetentes da sessão. De certa forma, as mensagens ResvTear são o inverso das mensagens Resv. As mensagens resvTear normalmente são iniciadas por um aplicativo receptor ou por um roteador quando seu estado de reserva é desatualizado.
As mensagens resvTear não são necessárias, mas melhoram o desempenho da rede porque liberam recursos de rede rapidamente. Se as mensagens ResvTear forem perdidas ou não forem geradas, os estados de reserva eventualmente ficam sem tempo quando não forem atualizadas e os recursos associados à reserva forem liberados.
Mensagens do PathErr
Quando ocorrem erros de caminho (geralmente por causa de problemas de parâmetro em uma mensagem de caminho), o roteador envia uma mensagem de PathErr unicast para o remetente que emitiu a mensagem do caminho. As mensagens do PathErr são consultivas; essas mensagens não alteram nenhum estado de caminho ao longo do caminho.
Mensagens resvErr
Quando uma solicitação de reserva falha, uma mensagem de erro do ResvErr é entregue a todos os receptores envolvidos. As mensagens resvErr são consultivas; essas mensagens não alteram nenhum estado de reserva ao longo do caminho.
Mensagens ResvConfirm
Os receptores podem solicitar a confirmação de uma solicitação de reserva, e essa confirmação é enviada com uma mensagem resvConfirm. Devido às complexas regras de fusão de fluxo do RSVP, uma mensagem de confirmação não necessariamente fornece confirmação de ponta a ponta de todo o caminho. Portanto, as mensagens ResvConfirm são uma indicação, não uma garantia, de sucesso potencial.
Os roteadores da Juniper Networks nunca solicitam confirmação usando a mensagem ResvConfirm; no entanto, um roteador da Juniper Networks pode enviar uma mensagem resvConfirm se receber uma solicitação do equipamento de outro fornecedor.
Entendendo a malha automática do RSVP
Ao adicionar sites às VPNs BGP e MPLS que usam sinalização RSVP, é necessário mais configuração para adicionar roteadores de borda de provedor (PE) do que o necessário para adicionar dispositivos de borda do cliente (CE). A malha automática RSVP ajuda a reduzir essa carga de configuração.
Os provedores de serviços costumam usar VPNs BGP e MPLS para dimensionar a rede de forma eficiente e, ao mesmo tempo, fornecer serviços de geração de receita. Nesses ambientes, o BGP é usado para distribuir as informações de roteamento VPN pela rede do provedor de serviços, enquanto o MPLS é usado para encaminhar esse tráfego VPN de um site VPN para outro. As VPNs BGP e MPLS são baseadas em um modelo peer. Para adicionar um novo dispositivo CE (site) a uma VPN existente, você precisa configurar o roteador CE no novo local e o roteador PE conectado ao roteador CE. Você não precisa modificar a configuração de todos os outros roteadores PE que participam da VPN. Os outros roteadores PE aprendem automaticamente sobre as rotas associadas ao novo local, um processo chamado de descoberta automática (AD).
Os requisitos são um pouco diferentes se você precisar adicionar um novo roteador PE à rede. Uma VPN BGP e MPLS exige que a sessão BGP seja totalmente malhada e que também haja uma malha completa de caminhos de comutada por rótulos MPLS do roteador PE para PE entre todos os roteadores PE da rede. Quando você adiciona um novo roteador PE à rede, todos os roteadores PE existentes devem ser reconfigurados para peer com o novo roteador PE. Grande parte do esforço de configuração pode ser reduzido se você configurar refletores de rota BGP (mitigando o requisito de malha completa para BGP) e se você configurar (LDP) como o protocolo de sinalização para MPLS.
No entanto, se você precisar adicionar um novo roteador PE a uma rede configurada com uma malha completa de LSPs sinalizados por RSVP, você deve reconfigurar cada um dos roteadores PE para ter uma relação de peer com o novo roteador PE. Você pode configurar a malha automática RSVP para resolver este cenário operacional em particular. Quando você habilita a malha automática RSVP, os LSPs RSVP são criados dinamicamente entre um novo roteador PE e os roteadores PE existentes, eliminando a necessidade de reconfigurar todos os roteadores PE manualmente. Para que a criação dinâmica de LSP funcione corretamente, o BGP deve ser configurado para trocar rotas entre todos os roteadores PE participantes. Se dois pares BGP não trocarem rotas, não será possível configurar um LSP dinâmico entre eles. A tabela de roteamento inet.3 do roteador local deve incluir uma rota rotulada para cada próximo salto IBGP potencial (futuros roteadores PE em potencial ou destinos LSP).
O RSVP inclui inúmeros recursos que não estão disponíveis no LDP, incluindo redirecionamento rápido, controle de ponto final e gerenciamento de enlaces. A malha automática RSVP ajuda a reduzir os requisitos de operação e manutenção para RSVP, possibilitando a implantação de RSVP em redes maiores e mais complicadas.
Cada roteador PE pode alcançar todos os outros roteadores PE da rede porque essas informações são distribuídas pelo IGP. Um roteador PE pode configurar um RSVP LSP ponto a ponto para qualquer outro roteador PE na rede, desde que saiba que tal LSP é necessário. Para construir uma malha completa de LSPs entre os roteadores PE, é necessário que cada roteador PE saiba qual dos outros roteadores PE compõem a malha completa.
No Junos OS, a malha automática RSVP é configurada usando a rsvp-te declaração de configuração no nível de [edit routing-options dynamic-tunnels dynamic-tunnel-name] hierarquia. A rsvp-te declaração de configuração também está disponível para uso em instâncias de roteamento como uma opção de túnel de provedor. Quando implementado como uma opção de túnel de provedor, rsvp-te é usado para configurar os LSPs de ponto a multiponto RSVP para VPNs multiprotocol BGP multicast, para não configurar a malha automática RSVP.
Estilos de reserva do RSVP
Uma solicitação de reserva inclui opções para especificar o estilo de reserva. Os estilos de reserva definem como as reservas para diferentes remetentes na mesma sessão são tratadas e como os remetentes são selecionados.
Duas opções especificam como as reservas para diferentes remetentes na mesma sessão são tratadas:
Reserva distinta — cada receptor estabelece sua própria reserva com cada remetente upstream.
Reserva compartilhada — todos os receptores fazem uma única reserva que é compartilhada entre muitos remetentes.
Duas opções especificam como os remetentes são selecionados:
Remetente explícito — Liste todos os remetentes selecionados.
Remetente curinga — Selecione todos os remetentes, que depois participam da sessão.
Os seguintes estilos de reserva, formados por uma combinação dessas quatro opções, atualmente são definidos:
Filtro fixo (FF) — Esse estilo de reserva consiste em reservas distintas entre os sjás explícitos. Exemplos de aplicativos que usam reservas no estilo de filtro fixo são aplicativos de vídeo e aplicativos unicast, que exigem fluxos que tenham uma reserva separada para cada remetente. O estilo de reserva de filtro fixo é habilitado em LSPs RSVP por padrão.
Filtro curinga (WF)— Esse estilo de reserva consiste em reservas compartilhadas entre os curingas. Esse tipo de reserva reserva largura de banda para todo e qualquer stores, e propaga upstream em direção a todos os senders, estendendo-se automaticamente a novos sjígais conforme eles aparecem. Um aplicativo de amostra para reservas de filtros curingas é um aplicativo de áudio no qual cada remetente transmite um fluxo de dados distinto. Normalmente, apenas alguns remetentes estão transmitindo a qualquer momento. Esse fluxo não requer uma reserva separada para cada remetente; uma única reserva é suficiente.
Explícito compartilhado (SE)— Esse estilo de reserva consiste em reservas compartilhadas entre simetrilhas explícitas. Esse tipo de reserva reserva largura de banda para um grupo limitado de remetentes. Um aplicativo de amostra é um aplicativo de áudio semelhante ao descrito para reservas de filtros curingas.
Redução de atualização do RSVP
O RSVP conta com o soft-state para manter o caminho e os estados de reserva em cada roteador. Se as mensagens de atualização correspondentes não forem enviadas periodicamente, os estados eventualmente ficam sem tempo e as reservas são excluídas. O RSVP também envia suas mensagens de controle como datagramas ip sem garantia de confiabilidade. Ele conta com mensagens de atualização periódicas para lidar com a perda ocasional de mensagens Path ou Resv.
As extensões de redução de atualização do RSVP, baseadas na RFC 2961, resolvem os seguintes problemas resultantes da dependência de mensagens de atualização periódicas para lidar com a perda de mensagens:
Escalabilidade — O problema de escalamento surge da sobrecarga periódica de transmissão e processamento de mensagens de atualização, o que aumenta à medida que o número de sessões de RSVP aumenta.
Confiabilidade e latência — O problema de confiabilidade e latência decorre da perda de mensagens RSVP não raras ou mensagens RSVP únicas, como PathTear ou PathErr. O tempo de recuperação de tal perda geralmente está vinculado ao intervalo de atualização e ao temporizante keepalive.
O recurso de redução de atualização do RSVP é anunciado, permitindo a redução de atualização (RR) capaz de bit no cabeçalho comum RSVP. Essa bit só é significativa entre os vizinhos RSVP.
A redução de atualização do RSVP inclui os seguintes recursos:
Agrupamento de mensagens do RSVP usando a mensagem do pacote
ID de mensagem do RSVP para reduzir a sobrecarga do processamento de mensagens
Entrega confiável de mensagens RSVP usando ID de mensagens, Message Ack e Message Nack
Atualização sumária para reduzir a quantidade de informações transmitidas a cada intervalo de atualização
A especificação de redução de atualização do RSVP (RFC 2961) permite que você habilite alguns ou todos os recursos acima em um roteador. Ele também descreve vários procedimentos que um roteador pode usar para detectar os recursos de redução de atualização de seu vizinho.
O Junos OS oferece suporte a todas as extensões de redução de atualização, algumas das quais podem ser habilitadas ou desabilitadas seletivamente. O Junos OS oferece suporte ao ID da mensagem e, portanto, pode realizar uma entrega confiável de mensagens apenas para mensagens Path e Resv.
Para obter informações sobre como configurar a redução de atualização do RSVP, consulte Configurando a redução de atualização do RSVP.
Sinalização de MTU no RSVP
A unidade de transmissão máxima (MTU) é o pacote ou quadro de maior tamanho, em bytes, que pode ser enviado em uma rede. Uma MTU muito grande pode causar retransmissões. Um MTU muito pequeno pode fazer com que o roteador envie e lide com relativamente mais sobrecarga e reconhecimentos de cabeçalho. Existem valores padrão para MTUs associados a vários protocolos. Você também pode configurar explicitamente um MTU em uma interface.
Quando um LSP é criado em um conjunto de links com diferentes tamanhos de MTU, o roteador de entrada não sabe qual é o menor MTU no caminho LSP. Por padrão, o MTU para um LSP é de 1.500 bytes.
Se essa MTU for maior que a MTU de uma das ligações intermediárias, o tráfego pode ser descartado, porque os pacotes MPLS não podem ser fragmentados. Além disso, o roteador de entrada não está ciente desse tipo de perda de tráfego, pois o plano de controle para o LSP ainda funcionaria normalmente.
Para evitar esse tipo de perda de pacote em LSPs MPLS, você pode configurar a sinalização de MTU no RSVP. Este recurso é descrito na RFC 3209. A Juniper Networks oferece suporte ao objeto de Serviços Integrados para sinalização de MTU no RSVP. O objeto serviços integrados é descrito nos RFCs 2210 e 2215. A sinalização de MTU no RSVP é desativada por padrão.
Para evitar a perda de pacotes devido a incompatibilidades de MTU, o roteador de entrada precisa fazer o seguinte:
Sinalize o MTU no RSVP LSP — Para evitar a perda de pacotes de uma incompatibilidade de MTU, o roteador de entrada precisa saber qual é o menor valor de MTU ao longo do caminho trilhado pelo LSP. Assim que esse valor de MTU for obtido, o roteador de entrada pode atribuí-lo ao LSP.
Pacotes de fragmento — Usando o valor de MTU atribuído, os pacotes que excedem o tamanho do MTU podem ser fragmentados em pacotes menores no roteador de entrada antes de serem encapsulados no MPLS e enviados pelo LSP sinalizado pelo RSVP.
Assim que a sinalização de MTU e a fragmentação de pacotes forem habilitadas em um roteador de entrada, qualquer rota que seja solucionada para um RSVP LSP neste roteador usa o valor de MTU sinalizado. Para obter informações sobre como configurar esse recurso, consulte Configurando a sinalização de MTU no RSVP.
As seções a seguir descrevem como funciona a sinalização de MTU no RSVP:
Como o MTU correto é sinalizado no RSVP
Como o MTU correto é sinalizado no RSVP varia dependendo se os dispositivos de rede (por exemplo, roteadores) oferecem suporte explícito à sinalização de MTU no RSVP ou não.
Se os dispositivos de rede suportarem a sinalização de MTU no RSVP, os seguintes ocorrerão quando você habilita a sinalização de MTU:
O MTU é sinalizado do roteador de entrada para o roteador de saída por meio do objeto Adspec. Antes de encaminhar este objeto, o roteador de entrada entra no valor de MTU associado à interface sobre a qual a mensagem de caminho é enviada. Em cada salto no caminho, o valor de MTU no objeto Adspec é atualizado ao mínimo do valor recebido e do valor da interface de saída.
O roteador de entrada usa o objeto de especificação de tráfego (Tspec) para especificar os parâmetros para o tráfego que enviará. O valor de MTU sinalizado para o objeto Tspec no roteador de entrada é o valor máximo de MTU (9192 bytes para roteadores série M e Série T, 9500 bytes para roteadores de transporte de pacotes da Série PTX). Esse valor não muda no caminho para o roteador de saída.
Quando o objeto Adspec chega ao roteador de saída, o valor do MTU está correto para o caminho (o que significa que é o menor valor de MTU descoberto). O roteador de saída compara o valor de MTU no objeto Adspec com o valor de MTU no objeto Tspec. Ele sinaliza o MTU menor usando o objeto Flowspec na mensagem Resv.
Quando o objeto Resv chega ao roteador de entrada, o valor de MTU neste objeto é usado como MTU para os próximos saltos que usam o LSP.
Em uma rede onde existem dispositivos que não oferecem suporte à sinalização MTU no RSVP, você pode ter os seguintes comportamentos:
Se o roteador de saída não oferecer suporte à sinalização MTU no RSVP, o MTU será definido para 1.500 bytes por padrão.
Um roteador de trânsito da Juniper Networks que não oferece suporte à sinalização MTU no RSVP define um valor de MTU de 1.500 bytes no objeto Adspec por padrão.
Determinando um valor de MTU de saída
O valor de MTU de saída é o menor dos valores recebidos no objeto Adspec em comparação com o valor mtu da interface de saída. O valor de MTU da interface de saída é determinado da seguinte forma:
Se você configurar um valor MTU sob o nível de
[family mpls]hierarquia, esse valor será sinalizado.Se você não configurar um MTU, o
inetMTU será sinalizado.
Sinalização de MTU em limitações de RSVP
A seguir, as limitações para a sinalização de MTU no RSVP:
Alterações no valor do MTU podem causar uma perda temporária de tráfego nas seguintes situações:
Para proteção de enlaces e proteção de nós, a MTU do bypass só é sinalizada no momento em que o bypass se torna ativo. Durante o tempo necessário para que o novo caminho MTU seja propagado, a perda de pacotes pode ocorrer devido a uma incompatibilidade de MTU.
Para redirecionamento rápido, a MTU do caminho só é atualizada após o desvio ficar ativo, causando um atraso em uma atualização para a MTU no roteador de entrada. Até que o MTU seja atualizado, a perda de pacotes pode ocorrer se houver uma incompatibilidade de MTU.
Em ambos os casos, são perdidos apenas pacotes maiores do que a MTU de desvio ou desvio.
Quando um MTU é atualizado, ele desencadeia uma mudança no próximo salto. Qualquer mudança no próximo salto faz com que as estatísticas de rota sejam perdidas.
O MTU mínimo suportado para sinalização de MTU no RSVP é de 1.488 bytes. Esse valor impede que um valor falso ou configurado incorretamente seja usado.
Para LSPs de salto único, o valor de MTU exibido pelos comandos é o valor sinalizado pelo
showRSVP. No entanto, esse valor MPLS é ignorado e o valor de IP correto é usado.
Tabela de histórico de alterações
A compatibillidadde com o recurso dependerá da platadorma e versão utilizada. Use o Feature Explorer para saber se o recurso é compatível com sua plataforma.