Configuração do PCEP

Entendendo o MPLS RSVP-TE

A engenharia de tráfego (TE) lida com a otimização de desempenho das redes operacionais, mapeando principalmente fluxos de tráfego em uma topologia física existente. A engenharia de tráfego oferece a capacidade de mover o fluxo de tráfego para longe do caminho mais curto selecionado pelo protocolo de gateway interior (IGP) e para um caminho físico potencialmente menos congestionado em uma rede.

Para a engenharia de tráfego em redes grandes e densas, os recursos MPLS podem ser implementados porque eles potencialmente fornecem a maior parte das funcionalidades disponíveis a partir de um modelo overlay, de forma integrada e a um custo menor do que as alternativas concorrentes atualmente. A principal razão para a implementação da engenharia de tráfego MPLS é o controle de caminhos ao longo dos quais o tráfego flui por uma rede. A principal vantagem da implementação da engenharia de tráfego MPLS é que ela fornece uma combinação dos recursos de engenharia de tráfego do ATM, juntamente com a diferenciação de classe de serviço (CoS) do IP.

Em uma rede MPLS, as informações do plano de dados são encaminhadas usando comutação de rótulos. Um pacote que chega em um roteador de borda (PE) do roteador de borda do cliente (CE) tem rótulos aplicados a ele, e depois é encaminhado para o roteador PE de saída. As etiquetas são removidas no roteador de saída e depois são encaminhadas para o destino apropriado como um pacote IP. Os roteadores de comutação de rótulos (LSRs) no domínio MPLS usam protocolos de distribuição de rótulos para comunicar o significado de rótulos usados para encaminhar tráfego entre e através dos LSRs. RSVP-TE é um protocolo de distribuição de rótulos que permite que um peer LSR aprenda sobre os mapeamentos de rótulos de outros pares.

Quando o MPLS e o RSVP são habilitados em um roteador, o MPLS torna-se um cliente do RSVP. O objetivo principal do software RSVP do Junos OS é oferecer suporte à sinalização dinâmica dentro de caminhos comuados por rótulos (LSPs). O RSVP reserva recursos, como fluxos IP unicast e multicast, e solicita parâmetros de qualidade de serviço (QoS) para aplicativos. O protocolo é estendido na engenharia de tráfego MPLS para permitir que o RSVP configure LSPs que possam ser usados para engenharia de tráfego em redes MPLS.

Quando o MPLS e o RSVP são combinados, os rótulos são associados a fluxos RSVP. Uma vez estabelecido um LSP, o tráfego pelo caminho é definido pelo rótulo aplicado no nó de entrada do LSP. O mapeamento do rótulo para o tráfego é realizado usando critérios diferentes. O conjunto de pacotes que recebem o mesmo valor de rótulo por um nó específico pertence à mesma classe de equivalência de encaminhamento (FEC) e definem efetivamente o fluxo de RSVP. Quando o tráfego é mapeado em um LSP dessa forma, o LSP é chamado de túnel LSP.

Os túneis LSP são uma maneira de estabelecer caminhos unidirecionais comutadores de rótulos. O RSVP-TE se baseia no protocolo de núcleo do RSVP, definindo novos objetos e modificando objetos existentes usados nos objetos PATH e RESV para o estabelecimento de LSP. Os novos objetos — objeto DE SOLICITAÇÃO DE RÓTULO (LRO), objeto DE ROTA DE REGISTRO (RRO), objeto LABEL e objeto EXPLICIT-ROUTE (ERO) — são opcionais em relação ao protocolo RSVP, com exceção dos objetos LRO e LABEL, ambos obrigatórios para a criação de túneis LSP.

Em geral, o RSVP-TE estabelece um caminho comuído por rótulos que garante a entrega de quadros do roteador de entrada à saída. No entanto, com os novos recursos de engenharia de tráfego, as seguintes funções são suportadas em um domínio MPLS:

• Possibilidade de estabelecer um caminho comutada por rótulos usando uma rota explícita completa ou parcial (RFC 3209).

• Estabelecimento de LSP baseado em restrições em links que atendem a requisitos, como largura de banda e propriedades de link.

• Controle de endpoint, associado à criação e gerenciamento de túneis LSP nos roteadores de entrada e saída.

• Gerenciamento de enlaces, que gerencia recursos de enlaces para fazer roteamento consciente de recursos de LSPs de engenharia de tráfego e para programar rótulos MPLS.

• O MPLS redireciona rapidamente (FRR), que gerencia os LSPs que precisam de proteção e atribui informações de túnel de backup a esses LSPs.

Limitações atuais do MPLS RSVP-TE

Embora as extensões RSVP para engenharia de tráfego permitam uma melhor utilização da rede e atendam aos requisitos das aulas de tráfego, o conjunto de protocolos MPLS RSVP-TE de hoje tem vários problemas inerentes à sua natureza distribuída. Isso causa uma série de problemas durante a disputa pela capacidade de bisação, especialmente dentro de uma classe prioritária de LSP, onde um subconjunto de LSPs compartilha a configuração comum e detém valores prioritários. As limitações do RSVP-TE incluem:

• Falta de visibilidade individual por LSP, demandas de largura de banda por dispositivo — Os roteadores de entrada em uma rede MPLS RSVP-TE estabelecem LSPs sem ter uma visão global da demanda de largura de banda na rede. As informações sobre a utilização de recursos de rede só estão disponíveis como capacidade total reservada por classe de tráfego por interface. O estado LSP individual está disponível localmente em cada roteador de borda de rótulo (LER) apenas para seus próprios LSPs. Como resultado, surgem uma série de problemas relacionados ao padrão de demanda, particularmente dentro de uma configuração comum e de manter a prioridade.

• Natureza assíncronos e independente da sinalização RSVP — No RSVP-TE, as restrições para o estabelecimento de caminhos são controladas por um administrador. Como tal, a largura de banda reservada a um túnel LSP é definida pelo administrador e não implica automaticamente qualquer limite no tráfego enviado pelo túnel. Portanto, a largura de banda disponível em um link de engenharia de tráfego é a largura de banda configurada para o link, excluindo a soma de todas as reservas feitas no link. Assim, as demandas não assinadas em um túnel LSP levam à degradação de serviço do LSP exigindo excesso de largura de banda, bem como os outros LSPs que atendem aos requisitos de largura de banda do link de engenharia de tráfego.

• LSPs estabelecidos com base em opções de caminho dinâmicas ou explícitas na ordem de preferência — os roteadores de entrada em uma rede MPLS RSVP-TE estabelecem LSPs para demandas com base na ordem de chegada. Como os roteadores de entrada não têm uma visão global da demanda de largura de banda na rede, usar a ordem de preferência para estabelecer LSPs pode fazer com que o tráfego seja descartado ou os LSPs não sejam estabelecidos quando há um excesso de demanda de largura de banda.

Como exemplo, Figura 2 é configurado com MPLS RSVP-TE, no qual A e G são os roteadores de borda de rótulo (LERs). Esses roteadores de entrada estabelecem LSPs de forma independente com base na ordem das demandas e não têm conhecimento ou controle sobre os LSPs uns dos outros. Os roteadores B, C e D são roteadores intermediários ou de trânsito que se conectam aos roteadores de saída E e F.

Figura 2: Exemplo mpls engenharia de tráfego

Os roteadores de entrada estabelecem LSPs com base na ordem em que as demandas chegam. Se o Roteador G receber duas demandas de capacidade 5 cada para G-F, g sinaliza dois LSPs — LSP1 e LSP2 — através do G-B-D-F. Da mesma forma, quando o Roteador A recebe a terceira demanda de capacidade 10 para A-E, então ele sinaliza um LSP, LSP3, por A-B-C-E. No entanto, se a demanda no A-E LSP aumentar de 10 para 15, o roteador A não pode sinalizar LSP3 usando o mesmo caminho (A-B-C-E), porque o enlace B-C tem uma capacidade menor.

O roteador A deveria ter sinalizado o aumento da demanda por LSP3 usando o caminho A-B-D-C-E. Como o LSP1 e o LSP2 utilizam o link B-D com base na ordem das demandas recebidas, o LSP3 não é sinalizado.

Assim, embora a largura de banda máxima de fluxo máximo esteja disponível para todos os LSPs, o LSP3 está sujeito a degradação de serviço potencialmente prolongada. Isso se deve à falta de visibilidade da demanda global do Roteador A e à falta de coordenação sistêmica na colocação da demanda pelos roteadores de entrada A e G.

Uso de uma entidade de computação de caminho externo

Como uma solução para as limitações atuais encontradas na computação de caminhos MPLS RSVP-TE, uma entidade de computação de caminhos externos com uma visão global de cada LSP, é necessária uma demanda por dispositivo na rede independentemente da capacidade disponível.

Atualmente, apenas a computação de caminhos de roteamento baseada em restrições em tempo real e on-line é fornecida em uma rede MPLS RSVP-TE. Cada roteador realiza cálculos de roteamento baseados em restrições independentemente dos outros roteadores da rede. Esses cálculos são baseados em informações de topologia disponíveis atualmente — informações geralmente recentes, mas não completamente precisas. As colocações de LSP são otimizadas localmente, com base no status da rede atual. Os túneis MPLS RSVP-TE são configurados usando o CLI. Um operador configura o TE LSP, que é então sinalizado pelo roteador de entrada.

Além dos recursos existentes de engenharia de tráfego, a funcionalidade MPLS RSVP-TE é estendida para incluir uma entidade de computação de caminho externo, chamada de Elemento de Computação de Caminho (PCE). O PCE computa o caminho para os LSPs TE de roteadores de entrada que foram configurados para controle externo. O roteador de entrada que se conecta a um PCE é chamado de cliente de computação de caminho (PCC). O PCC está configurado com o Protocolo de Cliente de Computação de Caminho (PCEP) para facilitar a computação de caminhos externos por um PCE.

Para obter mais informações, veja Componentes da computação de caminhos externos.

Para permitir a computação de caminhos externos para os LSPs TE de um PCC, inclua a lsp-external-controller pccd declaração nos [edit mpls] níveis de hierarquia.[edit mpls lsp lsp-name]

Componentes da computação de caminhos externos

Os componentes que compõem um sistema de computação de caminho externo são:

• Elemento de computação de caminhos
• Cliente de computação de caminhos
• Protocolo de elementos de computação de caminho

Interação entre um PCE e um PCC usando PCEP

Figura 3 ilustra a relação entre UM PCE, PCC e a função do PCEP no contexto do MPLS RSVP-TE.

Figura 3: PCC e RSVP-TE

A comunicação PCE para PCC é habilitada pelo PCEP baseado em TCP. O PCC inicia a sessão de PCEP e permanece conectado a um PCE durante a sessão do PCEP.

Uma vez estabelecida a sessão do PCEP, o PCC executa as seguintes tarefas:

1. Sincronização de estado LSP — o PCC envia informações sobre todos os LSPs (locais e externos) para todos os PCEs conectados. Para LSPs externos, o PCC envia informações sobre qualquer mudança de configuração, mudança de RRO, mudança de estado e assim por diante para o PCE.

   Para LSPs iniciados por PCE, não há configuração de LSP presente no PCC. O PCE que inicia o LSP envia os parâmetros LSP para o PCC que indicou sua capacidade de suporte a LSPs iniciados por PCE.

   Nota:

   O suporte para LSPs iniciados por PCE é fornecido no Junos OS Release 13.3 e versões posteriores.

2. Delegação LSP — Depois que as informações estaduais do LSP são sincronizadas, o PCC então delega os LSPs externos a um PCE, que é o principal PCE ativo stateful. Apenas o PCE principal pode definir parâmetros para o LSP externo. Os parâmetros que o PCE principal modifica incluem largura de banda, caminho (ERO) e prioridade (configuração e espera). Os parâmetros especificados na configuração local são substituídos pelos parâmetros que são definidos pelo PCE principal.

   Nota:

   Quando a sessão do PCEP com o PCE principal é terminada, o PCC elege um novo PCE principal, e todos os LSPs delegados para o PCE anteriormente principal são delegados ao PCE principal recém-disponível.

   No caso de LSPs iniciados por PCE, o PCC cria o LSP usando os parâmetros recebidos do PCE. O PCC atribui ao LSP iniciado por PCE um LSP-ID exclusivo e delega automaticamente o LSP para o PCE. Um PCC não pode revogar a delegação dos LSPs iniciados pela PCE para uma sessão de PCEP ativa.

   Quando uma sessão de PCEP termina, o PCC inicia dois temporizadors sem excluir imediatamente os LSPs iniciados por PCE – e lsp cleanup timer – delegation cleanup timeout para evitar interrupções nos serviços. Durante este tempo, um PCE stateful ativo pode adquirir o controle dos LSPs provisionados pelo PCE fracassado, enviando uma solicitação de criação para o LSP.

   O controle sobre os LSPs iniciados por PCE reverte para o PCC no término da delegation cleanup timeout. Quando o delegation cleanup timeout expira, e nenhum outro PCE adquiriu o controle sobre o LSP a partir do PCE fracassado, o PCC assume o controle local do LSP iniciado por PCE não delegado. Mais tarde, quando o PCE original ou um novo PCE ativo e stateful deseja adquirir o controle dos LSPs iniciados por PCE controlados localmente, o PCC delega esses LSPs para o PCE e o lsp cleanup timer temporizador é parado.

   Um PCE pode devolver a delegação do LSP iniciado pela PCE ao PCC para permitir a transferência de LSP entre PCEs. Isso aciona o lsp cleanup timer LSP iniciado por PCE. O PCC espera que o temporizador de limpeza LSP expire antes de remover os LSPs iniciados por PCE não delegados do PCE com falha.

   Quando o lsp cleanup timer expira, e nenhum outro PCE adquiriu o controle sobre os LSPs a partir do PCE fracassado, o PCC apaga todos os LSPs provisionados pelo PCE fracassado.

   Nota:

   Em conformidade com o rascunho-ietf-pce-stateful-pce-09, a revogação das delegações LSP iniciadas pela PCE por um PCC acontece de forma de fazer antes do intervalo antes que os LSPs sejam redelegados para um PCE alternativo. A partir do Junos OS Release 18.1R1, deve lsp-cleanup-timer ser maior ou igual ao delegation-cleanup-timeout pcc para revogar as delegações LSP. Se não, o intervalo de tempo de redentor para o PCC pode ser definido para o infinito, onde as delegações de LSP para esse PCE permanecem intactos até que medidas específicas sejam tomadas pelo PCC para alterar os parâmetros definidos pelo PCE.

3. Sinalização LSP — Ao receber um ou mais parâmetros LSP do PCE stateful principal ativo, o PCC re-sinaliza o TE LSP com base no caminho fornecido pelo PCE. Se o PCC não configurar o LSP, ele notifica o PCE da falha de configuração e aguarda que o PCE principal forneça novos parâmetros para esse LSP e depois re-sinalize.

   Quando o PCE especifica um caminho incompleto ou com saltos soltos onde apenas os endpoints de caminho são especificados, o PCC não realiza roteamento local baseado em restrições para descobrir o conjunto completo de saltos. Em vez disso, o PCC fornece rsVP com o caminho fornecido pelo PCE, como ele é, para sinalização, e o caminho é configurado usando o roteamento IGP hop-by-hop.

Considerando a topologia usada Figura 2, Figura 4 ilustra a implementação parcial do PCE no lado do cliente na rede habilitada para RSVP-TE DO MPLS. Os roteadores de entrada A e G são os PCCs que estão configurados para se conectar ao PCE stateful externo por meio de uma conexão TCP.

O PCE tem uma visão global da demanda de largura de banda na rede e realiza computação de caminhos externos depois de analisar o banco de dados de engenharia de tráfego. O PCE stateful ativo então modifica um ou mais atributos LSP e envia uma atualização para o PCC. O PCC usa os parâmetros que recebe do PCE para re-sinalizar o LSP.

Figura 4: Exemplo PCE para MPLS RSVP-TE

Dessa forma, o PCE stateful oferece uma operação cooperativa de funcionalidade distribuída usada para enfrentar desafios específicos de uma computação de caminho restringida entre domínios mais curto. Ela elimina cenários de congestionamento em que os fluxos de tráfego são mapeados ineficientemente em recursos disponíveis, causando a superutilização de alguns subconjuntos de recursos de rede, enquanto outros recursos permanecem subutilizados.

Comportamento de LSP com computação externa

• Tipos de LSP
• Modo de controle LSP

Declarações de configuração suportadas para computação externa

Tabela 1 lista as declarações de configuração de LSP e MPLS existentes que se aplicam a um LSP controlado por PCE.

O restante das declarações de configuração de LSP são aplicáveis da mesma forma que para os LSPs existentes. Ao configurar qualquer uma das declarações de configuração acima para um LSP controlado por PCE, uma mensagem de log MPLS é gerada para indicar quando os parâmetros configurados entrarão em vigor.

Proteção LSP controlada por PCE

Os caminhos de proteção, incluindo o redirecionamento rápido e o desvio de LSPs, são computados localmente pelo PCC usando roteamento baseado em restrições. Um PCE stateful especifica apenas o caminho primário (ERO). Um PCE também pode acionar um caminho secundário sem standby, mesmo que a configuração local não tenha um caminho secundário sem standby para a proteção de LSP.

ERO LSP controlado por PCE

Para LSPs controlados por PCE (LSPs delegados por PCC e LSPs initados por PCE), apenas um objeto de rota explícita (ERO) completo precisa ser enviado do PCE para o PCC; caso contrário, o PCC rejeita a mensagem PCUpdate ou PCCreate para essa sessão de PCEP.

A partir do Junos OS Release 17.2, além de external cspf, dois novos tipos de computação de caminho são introduzidos para os LSPs controlados por PCE: local cspf e no cspf...

• local cspf— Um PCC usa o local cspf tipo de computação apenas quando o PCE envia um TLV de fornecedor da Juniper (número da empresa: 0x0a4c) do tipo 5.

• no cspf— Nem o PCE nem o PCC realizam um cálculo de caminho limitado. Os endpoints e restrições são dados ao módulo RSVP para a configuração do LSP com o caminho IGP.

  Um PCC usa no cspf tipo de computação nos seguintes casos:

  • Quando o PCE envia local cspf tlv, e quando a configuração do Junos OS ou modelo de correspondência para este LSP incluído no-cspf no LSP delegado por PCC.

  • Quando o PCE envia local cspf tlv, e quando o modelo de configuração do Junos OS para este LSP incluído no-cspf no LSP iniciado por PCE.

  • Quando o PCE não envia local cspf TLV com um ERO vazio ou ERO solto (com um bit solto definido no objeto ERO).

Com esses novos tipos de computação, um PCC pode aceitar um objeto ERO, seja como um ERO solto, ou como um ERO vazio. Uma entidade de computação de caminho externo que não é capaz de computar um caminho pode modificar parâmetros como largura de banda e cor, com base nas análises. Nesses casos, é usado um objeto ERO vazio ou ERO solto e o caminho a ser trilhado é decidido pelo PCC.

LSPs RSPs de RSVP-TE controlados por PCE

Após uma sessão de PCEP ser estabelecida entre um PCE e um PCC, o PCC informa todos os LSPs do sistema ao PCE para sincronização de estado de LSP. Isso inclui LSPs ponto a ponto controlados por PCC, delegados por PCE e iniciados por PCE. Começando pelo Junos OS Release 15.1F6 e 16.1R1, esse recurso é estendido para relatar LSPs ponto a multiponto também. Para um PCE, o LSP de ponto a multiponto é semelhante ao RSVP de LSP ponto a multiponto, onde o LSP ponto a multiponto é tratado como coleta de LSPs ponto a ponto agrupados sob um identificador ponto a multiponto.

Por padrão, o controle PCE de LSPs ponto a multiponto não é suportado em um PCC. Para adicionar esse recurso, inclua a p2mp-lsp-report-capability declaração nos [edit protocols pcep pce pce-name] níveis de hierarquia.[edit protocols pcep pce-group group-id] Após a configuração do recurso de relatório ponto a multiponto em um PCC, o PCC anuncia esse recurso para o PCE. Se o PCE anunciar o mesmo recurso de relatório de ponto a multiponto em troca, o PCC reportará a árvore LSP completa de ponto a multiponto ao PCE para sincronização de estado de LSP.

Um PCC com o recurso de LSP TE de ponto a multiponto oferece suporte a relatórios de LSPs TE de ponto a multiponto para PCEs stateful, atualização de ponto a multiponto e banco de dados LSP com suporte ao nome LSP ponto a multiponto como chave. No entanto, os seguintes recursos e funções não são suportados para o Junos OS Release 15.1F6 e 16.1:

• LSPs estáticos de ponto a multiponto

• LSPs de ponto a multiponto delegados por PCE e iniciados por PCE

• Largura de banda automática

• TE++

• Mensagem de solicitação e resposta do PCE

• Criação de LSPs ponto a multiponto usando templates

• Configuração da entrada avançada nos LSPs de ponto a multiponto iniciados por PCE

• Configuração da entrada avançada no roteador apontando para um LSP provisionado.

LSPs de ponto a ponto iniciados por PCE

A partir do Junos OS Release 16.1, a funcionalidade PCEP é estendida para permitir que um PCE stateful inicie e provisione LSPs de engenharia de tráfego por meio de um PCC. Anteriormente, os LSPs foram configurados no PCC e o PCC delegou o controle sobre os LSPs externos a um PCE. A propriedade do estado LSP foi mantida pelo PCC. Com a introdução dos LSPs iniciados por PCE, um PCE pode iniciar e provisionar dinamicamente um LSP de engenharia de tráfego ponto a ponto sem a necessidade de um LSP configurado localmente no PCC. Ao receber uma mensagem PCCreate de um PCE, o PCC cria o LSP iniciado pela PCE e delega automaticamente o LSP para o PCE.

Por padrão, um PCC rejeita a solicitação de provisionamento de LSPs ponto a ponto iniciados por PCE de um PCE. Para permitir o suporte de LSPs initados por PCE no PCC, inclua a declaração de provisionamento lsp nos [edit protocols pcep pce pce-id] níveis de hierarquia.[edit protocols pcep pce-group group-id]

Um PCC indica sua capacidade de oferecer suporte a LSPs ponto a ponto iniciados por PCE, ao mesmo tempo em que estabelece a sessão do Protocolo de Elementos de Computação de Caminho (PCEP) com o PCE. Um PCE seleciona um PCC com esse recurso para iniciar um LSP. O PCE fornece ao PCC os parâmetros LSP iniciados por PCE. Ao receber os parâmetros de LSP ponto a ponto iniciados pelo PCE, o PCC configura o LSP, atribui um ID LSP e delega automaticamente o LSP ao PCE.

Quando o PCE que inicia o LSP não fornece os parâmetros de LSP ponto a ponto iniciados por PCE, o PCC usa os parâmetros padrão. Um modelo de LSP opcional também pode ser configurado para especificar valores para o LSP ponto a ponto iniciado por PCE quando os parâmetros LSP não forem fornecidos pelo PCE. Para configurar um modelo LSP para LSPs de ponto a ponto iniciados por PCE no PCC, inclua a declaração de modelo de caminho comutada por rótulos no nível de [edit protocols mpls lsp-external-controller lsp-external-controller] hierarquia.

Quando uma sessão de PCEP termina, o PCC inicia dois temporizadors sem excluir imediatamente osLSPs iniciados por PCE edelegation cleanup timeoutlsp cleanup timerevitar interrupções nos serviços. Durante este tempo, um PCE stateful ativo pode adquirir o controle dos LSPs provisionados pelo PCE com falha.

Um PCE pode devolver a delegação do LSP ponto a ponto iniciado pela PCE ao PCC para permitir a transferência de LSP entre PCEs. O controle sobre os LSPs iniciados pela PCE reverte para o PCC no término do tempo limite de limpeza da delegação. Quando o tempo limite de limpeza da delegação expira, e nenhum outro PCE adquiriu o controle sobre o LSP a partir do PCE fracassado, o PCC assume o controle local do LSP iniciado por PCE não delegado. Mais tarde, quando o PCE original ou um novo PCE ativo e stateful deseja obter o controle dos LSPs ponto a ponto iniciados localmente controlados pela PCE, o PCC delega esses LSPs para o PCE e o temporizador de limpeza LSP é parado.

O PCC espera que o temporizador de limpeza LSP expire antes de excluir os LSPs ponto a ponto iniciados por PCE não delegados do PCE com falha no PCE. Quando o temporizador de limpeza LSP expira, e nenhum outro PCE adquiriu o controle sobre os LSPs a partir do PCE com falha, o PCC exclui todos os LSPs provisionados pelo PCE fracassado.

A partir do Junos OS Release 21.1R1, oferecemos suporte ao roteamento ativo ininterrupto (NSR) para LSPs ponto a ponto e ponto a multiponto iniciados por RSVP iniciados por PCE. Apenas o mecanismo de roteamento primário mantém a sessão de PCEP com o controlador. Ele sincroniza todos os LSPs RSVP iniciados por PCEs, incluindo especificações de fluxo multicast para quaisquer LSPs P2MP iniciados por PCE, com o mecanismo de roteamento de backup. Durante uma troca, a sessão de PCEP cai e se restabelecerá quando o mecanismo de roteamento de backup se torna o mecanismo de roteamento principal. Isso reduz a perda de tráfego para o tráfego transportado por LSPs RSVP iniciados por PCE durante as transições do mecanismo de roteamento. Esse recurso é habilitado quando o NSR é configurado.

LSP de bypass iniciado por PCE

• Entendendo os LSPs de bypass iniciados por PCE
• Benefícios do LSP de bypass iniciado por PCE
• Comportamento dos LSPs de bypass iniciados por PCE durante a falha na sessão do PCEP

LSPs de ponto a multiponto iniciados por PCE

Com a introdução de LSPs iniciados por PCE de ponto a multiponto, um PCE pode iniciar e provisionar um LSP ponto a multiponto dinamicamente sem a necessidade de configuração de LSP local no PCC. Isso permite que o PCE controle o tempo e a sequência das computação de caminhos de ponto a multiponto dentro e por todas as sessões do Protocolo de Elementos de Computação de Caminho (PCEP), criando assim uma rede dinâmica que é controlada e implantada centralmente.

Para obter mais informações, consulte Understanding Path Computation Element Protocol para MPLS RSVP-TE com suporte para LSPs de ponto a multiponto iniciados por PCE.

SRv6 LSP em PCEP

O roteamento por segmentos pode ser aplicado ao plano de encaminhamento MPLS e IPv6. O elemento de computação de caminho (PCE) computa caminhos SR para o plano de encaminhamento MPLS e IPv6. O roteamento por segmentos para PCEP oferece suporte a LSPs SR, como PCE iniciado, criado localmente e LSPs SR delegados no plano de encaminhamento IPv6.

Benefícios dos LSPs SRv6 no PCEP

• Permite que você crie SRv6 LSPs iniciados por PCE.
• Delegar os LSPs SRv6 criados no roteador para o controlador.
• Reporte os LSPs criados localmente no roteador para o controlador.
• A programação de rede SRv6 oferece a flexibilidade para aproveitar o roteamento por segmentos sem implantar o MPLS.

O PCEP oferece suporte à criação, updation e exclusão de LSPs SRv6 coloridos e não coloridos. Quando o PCE iniciou o SRv6 LSP coexiste junto com um SRv6 LSP estático para o mesmo IP ou IP baseado em cores, então a rota de contribuição SRv6 TE LSP estática é preferida em relação à rota de contribuição SRv6 TE LSP iniciada pelo PCE.

Para configurar uma sessão de PCEP para ser capaz de SRv6, você precisa habilitar a srv6-capability declaração de configuração nos [protocolos de edição pcep pce pce-id] ou nos níveis [edit protocols pcep pce-group pce-id] de hierarquia. Se a srv6-capability declaração de configuração estiver habilitada, você também deve habilitar a declaração de configuração srv6 no nível [edit protocols source-packet-routing] de hierarquia de outra forma durante o compromisso e o erro será exibido.

Para configurar o SRv6 para SR-TE, você precisa adicionar a declaração de configuração srv6 no nível de hierarquia [editar protocolos de roteamento de pacotes de origem].

[Veja como entender a política SR-TE para túnel SRv6 para obter mais informações.

Para configurar a profundidade máxima da lista de segmentos para SRv6 LSP, você precisa habilitar a declaração de maximum-srv6-segment-list-depth configuração no nível [edit protocols pcep] de hierarquia.

Largura de banda automática e LSP controlado por PCE

A partir do Junos OS Release 14.2R4, o suporte à largura de banda automática é fornecido para LSPs controlados por PCE. Em versões anteriores, a opção de largura de banda automática não se aplicava aos LSPs controlados por PCE, embora os LSPs sob o controle de auto-bandwdith e roteamento baseado em restrições pudessem coexistir com LSPs controlados por PCE. A coleta de estatísticas para largura de banda automática só estava surtindo efeito quando o modo de controle de um LSP controlado por PCE muda de externo para local. Isso estava acontecendo em casos como nenhuma conectividade a um PCE ou quando um PCE retorna a delegação de LSPs de volta ao PCC.

Autenticação TCP-MD5 para sessões de PCEP

Um servidor PCE stateful automatiza a criação de caminhos de engenharia de tráfego por toda a rede, aumentando a utilização da rede e permitindo uma experiência de rede programável personalizada com o uso da comunicação pcep com um PCC. Um PCC envia relatórios LSP para um servidor PCE, e o PCE atualiza ou provisiona LSPs de volta ao PCC. Os dados enviados em uma sessão de PCEP são cruciais para que um servidor PCE realize a computação de caminhos externos. Como resultado, um ataque à comunicação do PCEP pode interromper os serviços de rede. Se as mensagens PCEP alteradas forem enviadas a um PCC, LSPs inapropriados podem ser configurados. Da mesma forma, se as mensagens PCEP alteradas forem enviadas a um PCE, uma visão incorreta da rede é aprendida pelo PCE.

Considerando a importância da comunicação do PCEP entre um PCE e o PCC na execução efetiva das funcionalidades pce, o Junos OS Release 16.1 apresenta o recurso de proteger uma sessão pcep usando autenticação TCP-MD5 de acordo com RFC 5440. Esse recurso protege a comunicação entre um PCE e o PCC durante uma sessão de PCEP, que pode estar sujeita a um ataque, e pode interromper os serviços de rede.

Para habilitar o mecanismo de segurança MD5 para uma sessão de PCEP, é recomendável que você defina e vincule a chave de autenticação MD5 no nível de [edit protocols pcep pce pce-id] hierarquia para uma sessão de PCEP. Você pode, no entanto, também usar um chaveiro predefinido do [edit security authentication-key-chains key-chain] nível de hierarquia para proteger uma sessão de PCEP. Neste caso, você deve vincular o chaveiro predefinido à sessão de PCEP no nível hierárquico [edit protocols pcep pce pce-id] .

A configuração a seguir é executada no PCC para estabelecer uma sessão de PCEP segura com um PCE:

• Usando a chave de autenticação MD5:

• Usando chaveiro de autenticação predefinido:

Para que sessões de PCEP seguras sejam estabelecidas com sucesso, a autenticação MD5 deve ser configurada com a chave de autenticação pré-compartilhada no servidor PCE e no PCC. O PCE e o PCC usam a mesma chave para verificar a autenticidade de cada segmento enviado na conexão TCP da sessão do PCEP.

Impacto da implementação de PCE do lado do cliente no desempenho da rede

A manutenção de um banco de dados stateful pode não ser trivial. Em um único ambiente PCE centralizado, um PCE stateful simplesmente precisa lembrar todos os LSPs TE que o PCE computou, os LSPs TE que foram realmente configurados (se isso pode ser conhecido) e quando os LSPs TE foram demolidos. No entanto, esses requisitos causam sobrecarga substancial do protocolo de controle em termos de estado, uso e processamento de rede e otimização de links globalmente em toda a rede. Assim, as preocupações de uma implementação de PCE stateful incluem:

• Qualquer mecanismo de sincronização confiável resulta em sobrecarga significativa do plano de controle. Os PCEs podem sincronizar o estado comunicando-se entre si, mas quando os LSPs TE são configurados usando computação distribuída realizada entre vários PCEs, os problemas de sincronização e prevenção da condição racial se tornam maiores e mais complexos.

• A sincronização de banco de dados de engenharia de tráfego fora de banda pode ser complexa com vários PCEs configurados em um modelo de computação PCE distribuído, e pode ser propensa a condições de corrida, preocupações com escalabilidade e assim por diante.

• Os cálculos de caminho que incorporam o estado total da rede são altamente complexos, mesmo que o PCE tenha informações detalhadas sobre todos os caminhos, prioridades e camadas.

Apesar das preocupações acima, a implementação parcial do PCE stateful no lado do cliente é extremamente eficaz em grandes sistemas de engenharia de tráfego. Ele oferece convergência rápida e benefícios significativos em termos de uso ideal de recursos, fornecendo o requisito de visibilidade global de um estado LSP TE e para o controle ordenado de reservas de caminho em dispositivos dentro do sistema que está sendo controlado.

Benefícios dos LSPs de ponto a multiponto iniciados por PCE

Atende aos requisitos da colocação LSP de engenharia de tráfego ponto a multiponto em resposta às demandas de aplicativos por meio da criação dinâmica e demolição de LSPs ponto a multiponto, criando assim uma rede dinâmica que é controlada e implantada centralmente.

Sinalização de LSPs de ponto a multiponto iniciados por PCE

A sinalização de LSPs de ponto a multiponto iniciados por PCE é a seguinte:

• When a new branch is added (Grafting)— Apenas a nova filial sub LSP é sinalizada e não resulta em re-sinalização de toda a árvore de ponto a multiponto.

  Se alguma alteração de topologia ocorreu antes do provisionamento do novo sub-LSP, então o Servidor de Computação de Caminho (PCS) re computa toda a árvore de ponto a multiponto e atualiza o LSP de ponto a multiponto usando uma mensagem de atualização do PC.

• When a branch is deleted (Pruning)— O sub LSP de filial excluído é demolido e não resulta em re-sinalização de toda a árvore de ponto a multiponto.

• When a branch sub-LSP parameter is changed— A mudança nos parâmetros sub LSP, como objeto de rota explícita (ERO), largura de banda ou prioridade, pode acontecer por otimização ou solicitação do usuário. Se houver uma solicitação de re-sinalização para um sub-LSP, toda a árvore de ponto a multiponto é re-sinalizada e, em seguida, a mudança para a nova instância acontece assim que as novas instâncias de todos os galhos estiverem ativas.

• When a branch sub-LSP path fails— Um erro é relatado ao PCS para o sub-LSP de filial com falha. Ao receber o novo ERO do PCS, toda a árvore de ponto a multiponto é re-sinalizada junto com o sub LSP de filial com falha, e a mudança para a nova instância acontece de forma make-before-break (MBB).

Comportamento dos LSPs de ponto a multiponto iniciados por PCE após falha na sessão do PCEP

Quando uma sessão de PCEP falha, os LSPs de ponto a multiponto iniciados por PCE ficam órfãos até o término do state timeout temporizador. Após o término do state timeout temporizador, os LSPs iniciados por PCE são limpos.

Para obter o controle de um LSP de ponto a multiponto iniciado por PCE após uma falha na sessão do PCEP, o PCE primário ou secundário envia uma PCInitiate mensagem antes que o state timeout temporizador expire.

Configuração do recurso de LSP de ponto a multiponto iniciado por PCE

Por padrão, a criação e o provisionamento de LSPs ponto a multiponto por um PCE não é suportado em um PCC. Para habilitar esse recurso, inclua as p2mp-lsp-init-capability declarações e p2mp-lsp-update-capability os níveis de [edit protocols pcep pce pce-name][edit protocols pcep pce-group group-id] hierarquia.

A p2mp-lsp-init-capability declaração fornece a capacidade de provisionar LSPs RSVP-TE de ponto a multiponto por um PCE. A p2mp-lsp-update-capability declaração fornece a capacidade de atualizar parâmetros RSVP-TE LSP de ponto a multiponto por um PCE.

Recursos suportados e sem suporte para LSPs de ponto a multiponto iniciados por PCE

Os recursos a seguir são suportados com LSPs de ponto a multiponto iniciados por PCE:

• Conformidade parcial com o rascunho do rascunho da Internet-ietf-pce-stateful-pce-p2mp (expira outubro de 2018), extensões de protocolo de elemento de computação de caminho (PCE) para uso de PCE stateful para caminhos comutação de rótulos de engenharia de tráfego de ponto a multiponto.

• A partir do Junos OS Release 21.1R1, oferecemos suporte ao roteamento ativo ininterrupto (NSR) para LSPs de ponto a multiponto iniciados por RSVP iniciados por PCE. Apenas o mecanismo de roteamento primário mantém a sessão de PCEP com o controlador. Ele sincroniza todos os LSPs RSVP iniciados por PCEs, incluindo especificações de fluxo multicast para quaisquer LSPs P2MP iniciados por PCE, com o mecanismo de roteamento de backup. Durante uma troca, a sessão de PCEP cai e se restabelecerá quando o mecanismo de roteamento de backup se torna o mecanismo de roteamento principal. Isso reduz a perda de tráfego para o tráfego transportado por LSPs RSVP iniciados por PCE durante as transições do mecanismo de roteamento. Esse recurso é habilitado quando o NSR é configurado.

Os recursos a seguir não são suportados com LSPs de ponto a multiponto iniciados por PCE:

• Delegação de LSP controlado localmente por ponto a multiponto.

• Delegação de controle de LSP.

• Extensão de protocolo de gateway interior (IGP) para descoberta de PCE em um domínio de roteamento IGP.

• Mensagens de solicitação/resposta.

• Movimento direto do sub LSP de filial de uma árvore de ponto a multiponto para outra.

  O mesmo pode ser conseguido excluindo um sub LSP de filial da primeira árvore de ponto a multiponto e reinstando-o a outro após a mensagem indicar a PCReport remoção de LSP do dispositivo.

• O IPv6 não é compatível.

• A sinalização baseada em SERO não é suportada.

• O recurso Empty-ERO não é suportado.

• A proteção de enlaces não é suportada.

Mapeamento de LSPs de ponto a multiponto iniciados por PCE para MVPN

Você pode associar um único ou intervalo de fluxos multicast MVPN (S,G) a um caminho de comutado por rótulos de ponto a multiponto (LSP) iniciado dinamicamente por PCE. Você pode especificar apenas tipos seletivos de fluxos para que esse recurso funcione. Isso inclui:

• Diferenciador de rota (RD), que é mapeado para a instância de roteamento MVPN.

• (S,G) que é a fonte de um pacote multicast e endereço de grupo multicast de destino. Isso é usado para filtrar o tráfego de entrada para mapeá-lo no túnel.

• LSP de ponto a multiponto usado para enviar tráfego que corresponda à especificação de fluxo acima mencionada.

Para obter mais detalhes, veja o rascunho do rascunho da Internet-ietf-pce-pcep-flowspec-05 (expira em 16 de fevereiro de 2020) Extensão pcep para especificação de fluxo.

A implementação atual deste recurso não implementa as seguintes seções do rascunho:

• Seção 3.1.2 — Recursos de publicidade PCE no IGP

• Seção 3.2 — Mensagem pcReq e PCRep

• Seção 7 — A maioria das especificações de fluxo, exceto distingu de rotaA implementação atual deste recurso não supporisher e especificações de fluxo multicast IPv4 não são suportadas.

Para permitir o mapeamento de LSPs de ponto a multiponto iniciados por PCE para MVPN:

• Inclua a pce_traffic_steering declaração no nível de [edit protocols pcep pce pce-id] hierarquia para indicar o suporte para a capacidade de especificação de fluxo (também chamado de direcionamento de tráfego) pelo PCC.

• Inclua a external-controller declaração no nível hierárquica [edit routing-instances routing-instance-name provider-tunnel] .

  A presença da configuração de external-controller túnel de provedor para MVPN indica que o LSP ponto a multiponto e (S,G) para esta instância MVPN podem ser fornecidos pelo controlador externo. Isso permite que o controlador externo configure dinamicamente (S,G) e LSP de ponto a multiponto para MVPN.

Leve o seguinte em consideração para o mapeamento de LSPs ponto a multiponto iniciados por PCE para MVPN:

• Se você não habilitar a external-controller pccd declaração para uma determinada instância MVPN, então o processo PCCD não configura (S,G) dinamicamente.

• Se você desativar a external-controller pccd configuração da CLI, então os fluxos multicast (S,G) aprendidos dinamicamente para essa instância MVPN em particular são excluídos e relatados ao controlador externo.

• Quando (S,G) já está configurado a partir do CLI, o PCC não pode configurar (S,G) dinamicamente, pois a configuração local tem uma prioridade maior.

• Se algum determinado (S,G) for aprendido com o controlador externo dinamicamente e então você configurar o mesmo (S,G) para a mesma instância MVPN, então o aprendizado dinâmico (S,G) é excluído e relatado ao controlador externo através do PCC.

• Se o processo de protocolo de roteamento for reiniciado, o processo PCCD reconfigura todos os (S,G) novamente.

• Se o processo PCCD for reiniciado, o MVPN informará todo o PCCD configurado (S,G) ao controlador externo.

• Se o usuário permitir external-controller pccd uma determinada instância MVPN, o MVPN solicitará que o processo PCCD configure (S,G), se houver algum presente.

• Se houver grandes mudanças de configuração em uma determinada instância MPVN, o MVPN solicitará ao processo PCCD que reconfigure todos (S,G) para essa instância MVPN em particular.

• Todas as especificações de fluxo associadas a qualquer LSP de ponto a multiponto iniciado por PCE devem ter o mesmo RD. Durante a iniciação do PC, se todas as especificações de fluxo não tiverem o mesmo RD, a mensagem de iniciação do PC será descartada com um erro.

• Você pode associar um LSP de ponto a multiponto apenas com especificações seletivas de tipo de fluxo, caso contrário, a mensagem de iniciação do PC é descartada com um erro.

• Durante a atualização do PC se todas as especificações de fluxo não tiverem o mesmo RD, seja devido a uma nova adição de especificação de fluxo, ou devido à atualização de especificação de fluxo existente, então o PCC deixa cair a mensagem de atualização.

• Durante a atualização do PC se todas as especificações de fluxo não atenderem à condição seletiva, seja devido à nova adição de especificação de fluxo, ou devido à atualização das especificações de fluxo existentes, o PCC deixa cair a mensagem de atualização.

• O comportamento para mapeamento do LSP ponto a multiponto iniciado por PCE com instância de roteamento MVPN e mapeamento de LSP estático (configurado localmente) de ponto a multiponto com instância MVPN é o mesmo no nível do usuário.

• Um ID de especificação de fluxo pode ser associado a apenas um LSP de ponto a multiponto. Para associar o mesmo RD e (S,G) a vários LSPs de ponto a multiponto, você pode adicionar várias especificações de fluxo com diferentes IDs e o mesmo RD &(S,G).

• Para a dinâmica mapeada por PCEP (S,G), o valor limite é sempre o valor padrão de 0.

• Não há limite no número de especificações de fluxo mapeadas para um único LSP de ponto a multiponto iniciado por PCE.

• A implementação atual deste recurso não oferece suporte:

  • Relatórios de estados de encaminhamento associados ao LSP de ponto a multiponto.

  • Configuração dinâmica de túnel de provedor inclusivo

  • Mapeamento para túnel de replicação de entrada MVPN

  • Processo de protocolo de roteamento programável (prpd)

  • Relatórios de LSP configurado de ponto a multiponto da CLI que é mapeado para fluxos multicast MVPN (S,G).

Restrições distribuídas de computação CSPF

Os caminhos LSP de roteamento por segmentos são computados quando todas as restrições configuradas são atendidas.

O recurso de computação CSPF distribuído oferece suporte ao seguinte subconjunto de restrições especificado no rascunho da Internet, draft-ietf-spring-segment-routing-policy-03.txt, Política de roteamento por segmentos para engenharia de tráfego:

• Inclusão e exclusão de grupos administrativos.

• Inclusão de endereços IP soltos ou rigorosos.

  Nota:

  Você pode especificar apenas IDs de roteador nas restrições de salto frouxas ou rigorosas. Rótulos e outros endereços IP não podem ser especificados como restrições de salto frouxas ou rigorosas no Junos OS Release 19.2R1-S1.

• Número máximo de IDs de segmentos (SIDs) na lista de segmentos.

• Número máximo de listas de segmentos por caminho de roteamento por segmentos do candidato.

O recurso de computação CSPF distribuído para LSPs de roteamento por segmentos não oferece suporte aos seguintes tipos de restrições e cenários de implantação:

• Endereços IPV6.

• LSPs de engenharia de tráfego de roteamento por segmentos entre domínios (SR-TE).

• Interfaces não numeradas.

• Vários protocolos de roteamento, como OSPF, ISIS e BGP-LS, habilitados ao mesmo tempo.

• Computação com prefixos ou endereçoscast como destinos.

• Incluindo e excluindo endereços IP de interface como restrições.

Algoritmo de computação CSPF distribuído

O recurso de computação CSPF distribuído para LSPs de roteamento por segmentos usa o algoritmo de compressão de pilha de rótulos com CSPF.

• Compressão de pilha de rótulos habilitada
• Desabilitação de pilha de rótulos

Banco de dados distribuído de computação CSPF

O banco de dados usado para computação SR-TE tem todos os links, nós, prefixos e suas características, independentemente de a engenharia de tráfego estar habilitada nesses nós de publicidade. Em outras palavras, é a união do banco de dados de engenharia de tráfego (TED) e do banco de dados de estado do enlace IGP de todos os domínios que o nó de computação aprendeu. Como resultado, para que o CSPF funcione, você deve incluir a igp-topology declaração no nível de [edit protocols isis traffic-engineering] hierarquia.

Configuração de restrições distribuídas de computação CSPF

Você pode usar um perfil de computação para agrupar logicamente as restrições de computação. Esses perfis de computação são referenciados pelos caminhos de roteamento por segmentos para computação dos LSPs de roteamento por segmentos primários e secundários.

Para configurar um perfil de computação, inclua a declaração de perfil de computação no nível de [edit protocols source-packet-routing] hierarquia.

A configuração para as restrições de computação suportadas incluem:

• Administrative groups

  Você pode configurar grupos administrativos sob o nível de [edit protocols mpls] hierarquia. O Junos OS aplica a configuração de grupo administrativo às interfaces de engenharia de tráfego de roteamento por segmentos (SR-TE).

  Para configurar as restrições de computação, você pode especificar três categorias para um conjunto de grupos administrativos. A configuração de restrição de computação pode ser comum a todos os caminhos de roteamento por segmentos de candidatos, ou pode estar nos caminhos individuais do candidato.

  • include-any— Especifica que qualquer link com pelo menos um dos grupos administrativos configurados da lista é aceitável para o caminho a percorrer.

  • include-all— Especifica que qualquer link com todos os grupos administrativos configurados da lista é aceitável para o caminho a percorrer.

  • exclude— Especifica que qualquer link que não tenha nenhum dos grupos administrativos configurados na lista é aceitável para o caminho a percorrer.

• Explicit path

  Você pode especificar uma série de IDs de roteador no perfil de computação como uma restrição para a computação dos caminhos do candidato SR-TE . Cada salto precisa ser um endereço IPv4 e pode ser do tipo rigoroso ou solto. Se o tipo de salto não estiver configurado, é usado rigoroso. Você deve incluir a opção compute na declaração da lista de segmentos ao especificar a restrição explícita do caminho.

• Maximum number of segment lists (ECMP paths)

  Você pode associar um caminho de candidato a uma série de listas dinâmicas de segmentos. Os caminhos são caminhos ECMP, onde cada lista de segmentos se traduz em um gateway de salto próximo com peso ativo. Esses caminhos são resultado da computação de caminhos com ou sem compressão.

  Você pode configurar este atributo usando a opção maximum-computed-segment-lists maximum-computed-segment-lists na declaração de configuração de perfil de computação . Essa configuração determina o número máximo dessas listas de segmentos computadas para um determinado LSP primário e secundário.

• Maximum segment list depth

  O parâmetro máximo de computação de profundidade da lista de segmentos garante que, entre os caminhos ECMP que satisfaçam todas as outras restrições, como grupo administrativo, apenas os caminhos que têm listas de segmentos menores ou iguais à profundidade máxima da lista de segmentos são usados. Quando você configura esse parâmetro como uma restrição sob o perfil de computação, ele substitui a maximum-segment-list-depth configuração sob o nível de [edit protocols source-packet-routing] hierarquia, se presente.

  Você pode configurar este atributo usando a opção maximum-segment-list-depth maximum-segment-list-depth na declaração de configuração de perfil de computação .

• Protected or unprotected adjacency SIDs

  Você pode configurar o SID de adjacência protegido ou desprotegido como uma restrição sob o perfil de computação para evitar links com o tipo SID especificado.

• Metric type

  Você pode especificar o tipo de métrica no link a ser usado para computação. Por padrão, os LSPs SR-TE usam métricas de engenharia de tráfego dos links para computação. A métrica de engenharia de tráfego para links é anunciada por extensões de engenharia de tráfego dos protocolos IGP. No entanto, você também pode optar por usar a métrica de IGP para computação usando a configuração do tipo métrica no perfil de computação.

  Você pode configurar este atributo usando a opção metric-type (igp | te) na declaração de configuração de perfil de computação .

Computação CSPF distribuída

Os caminhos do candidato SR-TE são computados localmente de modo que satisfaçam as restrições configuradas. Quando a compressão da pilha de rótulos é desativada, o resultado de computação CSPF multi-caminho é um conjunto de pilhas SID de adjacência. Quando a compressão da pilha de rótulos é habilitada, o resultado é um conjunto de pilhas de rótulos compactadas (compostas por SIDs adjacentes e SIDs de nós).

Quando os caminhos secundários são computados, os links, nós e SRLGs tomados pelos caminhos primários não são evitados para a computação. Para obter mais informações sobre caminhos primários e secundários, consulte Configuração de LSPs primários e secundários.

Para qualquer LSPs com resultado de computação mal-sucedido, a computação é retried à medida que o banco de dados de engenharia de tráfego (TED) muda.

Interação entre a computação distribuída de CSPF e os recursos SR-TE

• Pesos associados a caminhos de uma política SR-TE
• Detecção de linhas de vida do BFD
• nexthops herdados de rótulo
• Recurso de tradução automática

Configurações distribuídas de amostra de computação CSPF

• Exemplo 1
• Exemplo 2
• Exemplo 3

Benefícios de vários caminhos para PCEP SR-TE LSPs

• Os LSPs podem ter vários conjuntos de EROs até um destino

• Oferece recursos de balanceamento de carga configurando pesos para EROs individuais

• Alinha-se com o rascunho da arquitetura SR-TE para definir caminhos do candidato

Os recursos de caminho múltiplos PCEP a seguir são suportados:

• Quando o PCEP para vários caminhos é habilitado (padrão), você pode configurar vários caminhos primários (ou secundários) em um caminho de candidato configurado e controlado pelo PCC.

• Quando o PCEP para vários caminhos é desativado, você pode configurar apenas um caminho primário em um caminho de candidato. A configuração do caminho secundário não é permitida.

Se você habilitar multicaminhos PCEP, compute-profile agora pode ser configurado com número máximo de listas de segmentos (maximum-computed-segment-lists) superiores a 1.

Quando o recurso multicaminho pcep é habilitado, a configuração de caminho secundário é permitida para um caminho de candidato PCC não delegado, o objeto DE ROTA EXPLÍCITA (EROs) específico para o caminho secundário é enviado para o PCE com a bandeira de backup definida para o ERO. Os caminhos primários não incluem o MULTIPATH-BACKUP-TLV na mensagem PCRpt. O caminho secundário inclui MULTIPATH-BACKUP-TLV com conjunto de bandeiras de backup.

As seguintes funcionalidades multicaminho pcep são suportadas:

• Objeto de TLV de peso multicaminho (MULTIPATH-WEIGHT-TLV) em objeto de atributo de caminho (PATH-ATTRIB)

• Multipath-BACKUP TLV no objeto atributo de caminho (PATH-ATTRIB) apenas para LSPs SR-TE controlados pelo PCC

• MULTIPATH-CAP TLV em objeto LSP do PCEP

• Restringe vários caminhos primários e secundários no caminho do candidato SR quando o multicaminho PCEP é desativado

• Múltiplos caminhos primários e caminhos secundários no caminho do candidato SR quando o multicaminho PCEP é habilitado para LSPs controlados por PCC

• Listas de segmentos computadas máximas (max-computed-segment-lists) mais de 1 em perfil de computação SR-TE para LSPs delegados e iniciados por PCE

• Vários EROs para o caminho de candidato iniciado por PCE no SR-TE e no PCCD

• SRv6 LSPs

• SR MPLS (IPv4)

• Túneis dinâmicos SR MPLS (IPv4)

• Suporte a vários controladores

• Múltiplos caminhos de ERO para caminhos de candidato coloridos e não coloridos para PCE iniciados, configurados e controlados por PCC

• Compatível para trás com versões anteriores do Paragon Pathfinder. Para uma compatibilidade retrógrada, você precisa configurar disable-multipath-capability a declaração de configuração no nível [edit protocols pcep] de hierarquia.

• Suporte a código de erro para falha na validação de caminhos de candidatos iniciados por PCE

  • O total de caminhos de sub candidatos por candidato é limitado a 127. Para LSPs iniciados pelo PCE, se o número de caminhos de ERO se cruzar 127, o SR-TE lançar ERRO para PCCD (e o PCCD enviar mensagem de erro de PCEP para PCE) e os caminhos ERO correspondentes forem rejeitados.

As seguintes mensagens de erro de PCEP são suportadas:

Limitações

As seguintes limitações de PCEP aplicam-se:

• As TLVs a seguir mencionadas no draft-ietf-pce-multipath-06 não são suportadas:

  • TLV de backup multicaminho

  • Caminho de direção oposta multicaminho TLV

  • Caminho do candidato do Composto

• Quando o recurso multicaminho é desativado no PCEP, a configuração de vários caminhos de sub-candidato não é permitida. No entanto, em dispositivos Junos sem recursos multicaminho (versões do Junos OS antes de 22.4R1), é permitida a configuração de caminho de vários sub-candidatos. Quando o multissegmento PCEP é habilitado (por padrão), vários caminhos primários são permitidos para LSPs controlados por PCC com a finalidade de relatar. No entanto, apenas um caminho primário é suportado para o caminho do candidato delegado quando o multi-segmento pcep é habilitado.

• Grupos administrativos e quaisquer outras restrições não serão notificados ao PCE para pcc configurados e controlados caminhos de candidato SR-MPLS e SRv6 (com configurações primárias individuais ou múltiplas). Não há impacto para caminhos de candidatos delegados e iniciados pela PCE.

• Quando o recurso multicaminho PCEP é habilitado, a configuração de caminho secundário é permitida para caminhos de candidatos não delegados. Quando o recurso multicaminho PCEP é desativado, a configuração de caminho secundário não é permitida.

• Os caminhos do candidato não podem ter uma mistura de LSPs iniciados e delegados por PCE.

• Vários caminhos de sub-candidatos para um caminho de candidato colorido iniciado pela PCE não são suportados.

• Recursos de delegado com vários caminhos de sub-candidato em um caminho de candidato não são suportados.

Configuração

Para permitir que o PCCD envie recursos multicaminho tlv em objeto LSP para notificar a lista máxima de segmentos computados para um caminho de candidato específico, inclua a propagate-max-segmentlist declaração de configuração no nível [edit protocols pcep] hierarquia. Por padrão, o TLV não é enviado em objeto LSP.

Para desativar a sessão de vários recursos do PCEP para todos os PCEs, inclua a disable-multipath-capability declaração de configuração no nível [edit protocols pcep] de hierarquia.

Você pode habilitar os seguintes traceoptions de protocolo para diagnóstico:

• user@host# set protocols pcep traceoptions …

• user@host# set protocols pcep pce pce1 traceoptions …

• user@host# set protocols source-packet-routing traceoptions

Você pode usar os seguintes comandos de exibição para exibir o estado dos LSPs no PCC:

• user@host> show path-computation-client lsp— Exibir o estado dos caminhos comuados por rótulos (LSPs) conhecidos pelo Cliente de Computação de Caminho (PCC).

• user@host> show path-computation-client lsp extensive— Exibir um nível de saída extensivo sobre cada LSP conhecido — LSPs ponto a ponto e ponto a multiponto.

• user@host> show path-computation active-pce— Exibir o status do multicaminho nas sessões.

• user@host> show spring-traffic-engineering lsp detail— Exibir detalhes de entrada da engenharia de tráfego SPRING.

Benefícios de habilitar o TLS para sessões de PCEP

• Protege as sessões de PCEP contra ataques como spoofing (imitação de PCC ou PCE), espionagem (interceptação de mensagens), falsificação e negação de serviço.

• Aproveita os benefícios de segurança do TLS.

Habilitação de TLS no cliente de computação de caminhos (PCC)

Para habilitar o TLS no PCC e estabelecer a sessão PCEPS, definir a tls-strict declaração de CLI no nível [edit protocols pcep] de hierarquia.

Depois de habilitar uma declaração de configuração rigorosa, os seguintes eventos acontecem:

1. Flaps de sessão do PCEP. Qualquer conexão TCP existente é terminada e uma reconexão é feita usando TLS.

2. O PCC estabelece a conexão TCP com o PCE.

3. Os procedimentos de TLS são iniciados pela StartTLS mensagem do PCE ao PCC e do PCC ao PCE. A StartTLS mensagem é enviada pelo PCC e o StartTLSWait timer é iniciado. Você pode configurar o StartTLSWait temporizador configurando a start-tls-wait-timer seconds declaração de CLI no nível [edit protocols pcep pce pce-id] de hierarquia.

   Nota:

   O valor recomendado para o StartTLSWait temporizador é de 60 segundos e não deve ser menor do que o OpenWait temporizador. O valor padrão OpenWait do timer é definido em 60 segundos.

   • Se a mensagem aberta for recebida pelo PCC em vez de mensagem, PCErr mensagem com tipo de StartTLS erro definida para 1 (falha no estabelecimento de sessão do PCEP) e valor de erro definido para 1 (recepção de uma mensagem aberta inválida ou uma mensagem não aberta), e a sessão do TCP será fechada.

   • Se StartTLS a mensagem não for recebida do PCE, o StartTLSWait PCC enviará uma PCErr mensagem com o tipo de erro definido para 25 (falha no PCEP StartTLS ) e o valor de erro definido para 5 (sem StartTLS mensagem (nem PCErr/Open) antes StartTLSWait do término do temporizador, e a sessão do TCP será fechada.

4. A negociação e o estabelecimento da conexão TLS acontecem.

5. A troca de mensagens PCEP é iniciada conforme RFC5440.

Atualização de certificados usando a infraestrutura de chave pública (PKI)

O PKI não notifica o PCC sobre o término do certificado. Você deve atualizar manualmente o certificado usando o seguinte comando CLI. Neste método, você deve acompanhar a data de expiração do certificado.

Estabelecendo a conexão TLS

As etapas a seguir descrevem como uma conexão TLS (usando TLS v1.2) é estabelecida:

1. Gere certificados para os nós (dispositivos junos OS/pce-server). Você pode gerar os certificados usando um dos seguintes métodos:

   • Method 1— Gere o key-pair e o CSR no dispositivo e envie este CSR para a CA para obter o certificado. Assim que o certificado for emitido, ele é copiado para a caixa e instalado.

   • Method 2— Gere o key-pair e o certificado fora da caixa. Tanto o certificado quanto a chave privada são copiados no dispositivo e instalados juntos.

2. Carregue a autoridade de certificação (CA) no PCC para que o certificado de servidor PCE possa ser validado em relação ao CA carregado.

   Nota:

   Os CAs podem ser carregados em hierarquia plana como um CA independente. Se um CA é um sub-CA de outro CA, a cadeia é construída internamente pelo PKI.

   Nota:

   O certificado do servidor deve ser assinado por um CA. Certificados auto-assinados não são permitidos.

3. Habilite o TLS no PCC.

4. A sessão do PCEP está estabelecida sobre o TLS com o mecanismo de dissíduo de TLS.

5. O servidor PCE ouve a porta 4189 para solicitações de conexão de PCC por meio do TLS.

6. O PCC inicia a solicitação de conexão à porta de destino 4189.

7. Após a conclusão de um aperto de mão de três vias, o aperto de mão do TLS começa usando os certificados e a autenticação de ida é feita (o PCC autentica o certificado do servidor). Tanto o servidor quanto o cliente aguardam tempo para StartTLSWait receber a StartTLS mensagem. Você pode configurar o StartTLSWait temporizador configurando a start-tls-wait-timer seconds declaração de CLI no nível [edit protocols pcep pce pce-id] de hierarquia.

   Nota:

   O valor recomendado para o StartTLSWait temporizador é de 60 segundos e não deve ser menor do que o OpenWait temporizador. O valor padrão OpenWait do timer é definido em 60 segundos.

8. Após a sessão bem-sucedida do TLS, o PCC e o PCE iniciam o estabelecimento de sessões de PCEP sobre TLS durante as quais os parâmetros da sessão são negociados.

   • Se a validação do certificado falhar, o PCC encerrará a conexão TCP.

9. A mensagem PCEP é enviada pela conexão TLS como dados do aplicativo.

10. A criptografia e a descriptografia acontecem tanto no PCC quanto no PCE após um sucesso no TLS.

11. Quando a sessão do PCEP é fechada, a sessão do TLS é removida.

Entendendo o mecanismo básico de aperto de mão do TLS

O aperto de mão é uma série de mensagens trocadas entre um servidor e um cliente. As etapas exatas do aperto de mão variam dependendo do algoritmo de troca de chave, pacote de cifras etc. A seguir, as etapas básicas do mecanismo de dissibilimento do TLS:

1. Client Hello— O cliente inicia o aperto de mão enviando esta mensagem. Esta mensagem contém versão TLS, lista de algoritmos criptográficos suportados ou suíte de cifras e outros detalhes do cliente.

2. Server Hello— O servidor responde ao Client Hello enviando uma mensagem de Sever Hello. Esta mensagem contém certificado de servidor, algoritmo criptográfico selecionado, id de sessão e chave pública do servidor.

3. Authentication— O cliente em segundo plano verifica o certificado do servidor com a Autoridade de Certificado configurada que havia emitido o certificado. Em verificação bem-sucedida, o cliente confirma que o servidor é genuíno e continua interagindo.

4. Optional Client Certificate— Se o servidor tiver solicitado um certificado ao cliente na mensagem Server Hello, o cliente enviará o certificado de cliente (apenas em caso de TLS mútuo).

5. Client Key Exchange— O cliente envia uma chave secreta criptografada com a chave pública do servidor (adquirida na mensagem Server Hello).

6. Decrypt secret key— O servidor descriptografa a chave secreta usando a chave privada.

7. Client Finished— O cliente envia uma mensagem de finalização criptografada com a chave secreta compartilhada e sinais completos.

8. Server Finished— O servidor responde com uma mensagem de finalização criptografada com a chave secreta compartilhada e os sinais estão completos.

9. Exchange Messages— As mensagens após a conclusão do aperto de mão são simetricamente criptografadas.

Diagnóstico e validação de TLS para sessões de PCEP

Para diagnósticos, use as seguintes declarações de traceoptions CLI:

Habilite logs PKI usando a configuração a seguir e capture o mesmo arquivo de /var/log/<filename>

Verifique o certificado ca carregado usando o seguinte comando:

Saída de amostra

O seguinte é uma saída amostra de show path-computation-client statistics comando:

Esta saída de amostra fornece as seguintes informações:

• O TLS está habilitado no PCC.

• O PCE é capaz de TLS.

• A sessão de TLS está estabelecida. Isso também indica que o certificado de servidor PCE é válido.

• O status da sessão do PCEPS está em funcionamento.

Benefícios da otimização do caminho de relatórios e métricas computadas no PCEP

• Relatórios de métricas de otimização de caminho configurados no PCC ajuda o PCE a estar ciente das restrições usadas para a computação de caminhos.

• Relatórios de métricas computadas para o PCE. Isso ajuda o PCE a analisar se o LSP requer otimização adicional.

Entendendo as métricas de otimização

A seção a seguir descreve as métricas de otimização pretendidas e reais para LSPs RSVP e SR-TE (SR MPLS) em PCEP.

• LSP RSP criado localmente
• RSVP LSP delegado
• LSP RSP de RSVP iniciado por PCE
• LSP sr-TE delegado
• LSP SR-TE iniciado por PCE
• Envio de métrica de otimização em mensagem PCRpt
• Envio de métrica computada em mensagem pcrpt
• Incompatibilidade para trás para métrica de rota

Configuração de métricas de otimização para LSPs

Você pode configurar métricas de otimização (IGP, TE e atraso de caminho) para RSVP LSPs e SR-TE LSP.

Para configurar as métricas de otimização de IGP, TE e atraso de caminho para LSPs RSVP, inclua a metric-type <igp|te|delay|delay minimum> declaração CLI no nível [edit protocols mpls label-switched-path <lsp-name>] de hierarquia.

Para configurar as métricas de otimização de IGP, TE e atraso de caminho para LSPs SR-TE, inclua a metric-type <igp|te|delay|delay minimum> declaração CLI no nível [edit protocols source-packet-routing compute-profile <compute-profile-name>] de hierarquia.

Saída de amostra

Você pode usar os show path-computation-client lsp comandos e show path-computation-client lsp extensive CLI para exibir o estado dos caminhos comuados por rótulos (LSPs) conhecidos pelo Cliente de Computação de Caminho (PCC).

A seguir, uma saída amostral de show path-computation-client lsp extensive:

A saída mostra que o LSP é otimizado com o IGP do tipo métrica. O valor computado da métrica de IGP é de 50. A métrica de rota instalada na tabela de rotas é de 50.