Configuração do PCEP

Entender o MPLS RSVP-TE

A engenharia de tráfego (TE) trata da otimização de desempenho das redes operacionais, mapeando principalmente os 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 da funcionalidade disponível a partir de um modelo de overlay, de forma integrada e a um custo menor do que as alternativas concorrentes atualmente. O principal motivo para implementar a engenharia de tráfego MPLS é controlar caminhos pelos 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) de 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 de provedor (PE) do roteador de borda do cliente (CE) tem rótulos aplicados a ele, e depois é encaminhado para o roteador PE de saída. Os rótulos são removidos no roteador de saída e depois são encaminhados 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 dos rótulos usados para encaminhar o tráfego entre e através dos LSRs. RSVP-TE é um desses protocolos 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 de RSVP. O objetivo principal do software Junos OS RSVP é oferecer suporte à sinalização dinâmica dentro de caminhos comutados por rótulos (LSPs). O RSVP reserva recursos, como para 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 atribuídos ao mesmo valor de rótulo por um nó específico pertence à mesma classe de equivalência de encaminhamento (FEC) e define 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 comutados por rótulos. O RSVP-TE se baseia no protocolo de núcleo 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 estabelecer túneis LSP.

Em geral, o RSVP-TE estabelece um caminho comutador de rótulos que garante a entrega de quadros da entrada ao roteador de 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 comutado por rótulos usando uma rota explícita completa ou parcial (RFC 3209).

• Estabelecimento LSP baseado em restrições por links que cumprem requisitos, como largura de banda e propriedades de enlace.

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

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

• O MPLS reroute rápido (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 classes 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 de prioridade 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 vários problemas relacionados ao padrão de demanda, especialmente dentro de uma configuração comum e de manter a prioridade.

• Natureza assíncrona 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 do serviço do LSP exigindo excesso de largura de banda, bem como os outros LSPs que atendem aos requisitos de largura de banda do enlace 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 ingresso 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 – por meio do G-B-D-F. Da mesma forma, quando o roteador A recebe a terceira demanda de capacidade 10 para A-E, em seguida, ele sinaliza um LSP, LSP3, através de 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 enlace B-D com base na ordem das demandas recebidas, o LSP3 não é sinalizado.

Assim, embora a largura de banda de fluxo máximo adequada esteja disponível para todos os LSPs, o LSP3 está sujeito a degradação de serviços potencialmente demorada. Isso se deve à falta de visibilidade da demanda global do Roteador A e à falta de coordenação sistêmico 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, é necessária uma entidade de computação de caminhos externos com uma visão global de por LSP, é necessária uma demanda por dispositivo na rede independentemente da capacidade disponível.

Atualmente, apenas a computação de caminhos de roteamento baseado em restrições on-line e em tempo real é fornecida em uma rede MPLS RSVP-TE. Cada roteador executa 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 que geralmente são recentes, mas não completamente precisas. As colocações de LSP são otimizadas localmente, com base no status atual da rede. 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 de engenharia de tráfego existentes, a funcionalidade MPLS RSVP-TE é estendida para incluir uma entidade de computação de caminhos externos, 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, consulte 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 elemento de computação de caminhos

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

Figura 3 ilustra a relação entre um PCE, PCC e o papel 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 pcep e permanece conectado a um PCE durante a sessão do PCEP.

Uma vez estabelecida a sessão 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 LSP presente no PCC. O PCE que inicia o LSP envia os parâmetros LSP para o PCC que indicou sua capacidade de dar 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 — Após a sincronização das informações estaduais do LSP, o PCC delega os LSPs externos a um PCE, que é o principal PCE ativo e 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 retenção). Os parâmetros especificados na configuração local são substituídos pelos parâmetros definidos pelo PCE principal.

   Nota:

   Quando a sessão pcep com o PCE principal é encerrada, 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 pelo PCE um LSP-ID exclusivo e delega automaticamente o LSP ao PCE. Um PCC não pode revogar a delegação dos LSPs iniciados pelo PCE para uma sessão de PCEP ativa.

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

   O controle sobre LSPs iniciados por PCE volta para o PCC no expiração do delegation cleanup timeout. Quando o delegation cleanup timeout expira, e nenhum outro PCE adquiriu o controle sobre o LSP a partir do PCE falhou, o PCC assume o controle local do LSP iniciado por PCE não delegado. Mais tarde, quando o PCE original ou novo ativo stateful deseja adquirir o controle dos LSPs iniciados por PCE controlados localmente, o PCC delega esses LSPs ao PCE e o lsp cleanup timer temporizador é interrompido.

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

   Quando o lsp cleanup timer expira, e nenhum outro PCE adquiriu o controle sobre os LSPs do PCE com falha, o PCC exclui todos os LSPs provisionados pelo PCE com falha.

   Nota:

   Em conformidade com o draft-ietf-pce-stateful-pce-09, a revogação das delegações LSP iniciadas pelo PCE por um PCC acontece de forma make-before-break antes que os LSPs sejam redelegados para um PCE alternativo. A partir do Junos OS Release 18.1R1, o lsp-cleanup-timer que precisa ser maior ou igual ao delegation-cleanup-timeout PCC para revogar as delegações de LSP. Se não, o intervalo de tempo de redenção para o PCC pode ser definido como infinito, onde as delegações de LSP para esse PCE permanecem intactas 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 PRINCIPAL PCE ativo stateful, 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 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 executa roteamento local baseado em restrições para descobrir o conjunto completo de hops. Em vez disso, o PCC fornece RSVP com o caminho fornecido pelo PCE, como é, 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 do lado do cliente na rede habilitada para RSVP-TE MPLS. Os roteadores de entrada A e G são os PCCs 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 procurar o banco de dados de engenharia de tráfego. O PCE stateful ativo modifica um ou mais atributos LSP e envia uma atualização ao PCC. O PCC usa os parâmetros que recebe do PCE para re-sinalizar o LSP.

Figura 4: Exemplo DE 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 restrita entre domínios mais curta. Ela elimina cenários de congestionamento em que 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 de LSP

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

Tabela 1 lista as declarações de configuração MPLS e LSP 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 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 fazem efeito.

Proteção LSP controlada por PCE

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

LSP ERO 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 PCEP.

A partir do Junos OS Release 17.2, além external cspfde, 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 restrito. Os endpoints e restrições são dados ao módulo RSVP para configurar o LSP com o caminho IGP.

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

  • Quando o PCE envia local cspf TLV, e quando o junos OS configuração 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 pelo PCE.

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

Com esses novos tipos de computação, um PCC pode aceitar um objeto ERO 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, um objeto ERO vazio ou ERO solto é usado e o caminho a ser tomado é decidido pelo PCC.

LSPs RSVP-TE de ponto a multiponto 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 LSP. Isso inclui LSPs ponto a ponto controlados por PCC, delegados por PCE e iniciados por PCE. A partir do Junos OS Release 15.1F6 e 16.1R1, esse recurso é estendido para relatar LSPs ponto a multiponto também. Para um PCE, o LSP ponto a multiponto é semelhante ao RSVP de LSP ponto a multiponto, onde o LSP ponto a multiponto é tratado como uma coleta de LSPs ponto a ponto agrupados sob um identificador ponto a ponto 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 níveis de [edit protocols pcep pce pce-name] 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 ponto a multiponto em troca, o PCC reportará a árvore LSP completa de ponto a multiponto ao PCE para sincronização de estado LSP.

Um PCC com o recurso de LSP TE 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 o 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

• Configurando a entrada avançada no roteador apontando para um LSP provisionado.

LSPs 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. Mais cedo, 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 pelo PCE, um PCE pode iniciar e provisionar um LSP de engenharia de tráfego ponto a ponto dinamicamente sem a necessidade de um LSP configurado localmente no PCC. Ao receber uma mensagem PCCreate de um PCE, o PCC cria o LSP iniciado pelo PCE e delega automaticamente o LSP ao PCE.

Por padrão, um PCC rejeita a solicitação de provisionamento de LSPs ponto a ponto iniciados por PCE a partir 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 [edit protocols pcep pce-group group-id] hierarquia.

Um PCC indica sua capacidade de dar suporte a LSPs ponto a ponto iniciados por PCE, ao mesmo tempo em que estabelece a sessão de 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 pelo 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 inicia o LSP não fornece parâmetros LSP de ponto a ponto iniciados pelo 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 pelo PCE quando os parâmetros LSP não forem fornecidos pelo PCE. Para configurar um modelo LSP para LSPs 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 pelo PCE edelegation cleanup timeoutlsp cleanup timerevitar interrupções nos serviços. Durante esse 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 pelo PCE ao PCC para permitir a transferência de LSP entre PCEs. O controle sobre LSPs iniciados por PCE volta 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 do PCE falhou, o PCC assume o controle local do LSP iniciado por PCE não delegado. Mais tarde, quando o PCE original ou novo ativo stateful deseja adquirir o controle dos LSPs ponto a ponto iniciados localmente, o PCC delega esses LSPs ao PCE e o temporizador de limpeza LSP é interrompido.

O PCC aguarda a expiração do temporizador de limpeza LSP antes de excluir os LSPs ponto a ponto não delegados iniciados por PCE do PCE com falha. Quando o temporizador de limpeza LSP expira, e nenhum outro PCE adquiriu controle sobre os LSPs do PCE com falha, o PCC elimina todos os LSPs provisionados pelo PCE falho.

A partir do Junos OS Release 21.1R1, oferecemos suporte ao roteamento ativo (NSR) ininterrupto para LSPs ponto a ponto e ponto a multiponto iniciados por PCE. Apenas o mecanismo de roteamento primário mantém a sessão 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 diminui e se restabelece 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 é ativado quando o NSR é configurado.

LSP de bypass iniciado por PCE

• Entender 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 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 entre 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 LSPs iniciados por PCE, criados localmente e LSPs SR delegados no plano de encaminhamento IPv6.

Benefícios dos LSPs SRv6 no PCEP

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

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

Para configurar uma sessão 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 for ativada, 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 commit 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 do SR-TE para o 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 com 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 em 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 por 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 pcep pode interromper os serviços de rede. Se as mensagens PCEP alteradas forem enviadas a um PCC, LSPs inadequados 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 PCC na execução efetiva das funcionalidades do PCE, o Junos OS Release 16.1 introduz o recurso de proteger uma sessão PCEP usando a autenticação TCP-MD5 de acordo com o RFC 5440. Esse recurso protege a comunicação entre um PCE e um PCC por meio de 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, recomenda-se 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. No entanto, você também pode usar um chaveiro predefinido do [edit security authentication-key-chains key-chain] nível de hierarquia para proteger uma sessão de PCEP. Nesse caso, você deve vincular o chaveiro predefinido à sessão PCEP no nível de [edit protocols pcep pce pce-id] hierarquia.

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

• Usando a chave de autenticação MD5:

• Usando chaveiro de autenticação predefinido:

Para que as 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 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 derrubados. No entanto, esses requisitos causam sobrecarga de protocolo de controle substancial 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 a computação distribuída realizada entre vários PCEs, os problemas de sincronização e prevenção das condições de corrida tornam-se 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 de LSP de engenharia de tráfego ponto a multiponto em resposta às demandas dos aplicativos por meio da criação dinâmica e da derrubada 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 o novo sub-LSP da filial é sinalizado e não resulta em re-sinalização de toda a árvore de ponto a multiponto.

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

• When a branch is deleted (Pruning)— O sub-LSP de filial excluído é derrubado 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 o Explicit Route Object (ERO), largura de banda ou prioridade, pode acontecer por causa da otimização ou da 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 transferência 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 pelo 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 de LSPs de ponto a multiponto iniciados por PCE após falha na sessão do PCEP

Quando uma sessão PCEP falha, os LSPs de ponto a multiponto iniciados pelo PCE ficam órfãos até a expiração do state timeout temporizador. Após a expiração do state timeout temporizador, os LSPs iniciados pelo 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 expira.

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 são suportados em um PCC. Para habilitar esse recurso, inclua as p2mp-lsp-init-capability declarações e p2mp-lsp-update-capability as declarações nos [edit protocols pcep pce pce-name] níveis de hierarquia.[edit protocols pcep pce-group group-id]

A p2mp-lsp-init-capability declaração fornece a capacidade de provisionar LSPs RSVP-TE ponto a multiponto por um PCE. A p2mp-lsp-update-capability declaração fornece a capacidade de atualizar parâmetros de RSVP-TE LSP 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 ponto a multiponto iniciados pelo PCE:

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

• A partir do Junos OS Release 21.1R1, oferecemos suporte ao roteamento ativo (NSR) ininterrupto para LSPs de ponto a multiponto baseados em RSVP iniciados por PCE. Apenas o mecanismo de roteamento primário mantém a sessão 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 diminui e se restabelece 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 é ativado quando o NSR é configurado.

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

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

• Delegação de controle de LSP.

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

• Solicitação/resposta de mensagens.

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

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

• O IPv6 não tem suporte.

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

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

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

Mapeando LSPs de ponto a multiponto iniciados por PCE para MVPN

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

• Distinguidor de rotas (RD) 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 até o túnel.

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

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

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

• Seção 3.1.2 — Recursos publicitários de 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 habilitar o mapeamento de LSPs 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 o recurso de especificação de fluxo (também chamado de direção de tráfego) pelo PCC.

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

  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 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 instância MVPN específica, então o processo PCCD não configura (S,G) dinamicamente.

• Se você desativar a external-controller pccd configuração da CLI, 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 da 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, em seguida, 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 informa todo o PCCD configurado (S,G) ao controlador externo.

• Se o usuário habilitar external-controller pccd uma instância MVPN específica, o MVPN solicita que o processo PCCD configure (S,G), se houver algum presente.

• Se houver grandes alterações de configuração em uma instância MPVN específica, o MVPN solicita o processo PCCD para reconfigurar 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 é retirada com um erro.

• Você pode associar um LSP ponto a multiponto apenas com especificações seletivas de tipo de fluxo, caso contrário, a mensagem de iniciação do PC é retirada 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, 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ções 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 pelo 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 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 IDs diferentes 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 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 de 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 draft 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 de salto soltos ou rigorosos.

  Nota:

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

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

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

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 inter domínio (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.

• Habilitado para compressão de pilhas de rótulos
• Compressão de pilha de rótulos desabilitada

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 ser 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 de 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 do 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 em caminhos individuais de candidatos.

  • include-any— Especifica que qualquer enlace com pelo menos um dos grupos administrativos configurados na lista é aceitável para que o caminho atravesse.

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

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

• 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 dos candidatos ao SR-TE . Cada hop precisa ser um endereço IPv4 e pode ser do tipo rigoroso ou solto. Se o tipo de hop 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 de caminho explícita.

• Maximum number of segment lists (ECMP paths)

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

  Você pode configurar esse 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 de ECMP que satisfaçam todas as outras restrições, como o 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 esse 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 de protocolos de 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 esse 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 dos candidatos ao SR-TE são computados localmente para que satisfaçam as restrições configuradas. Quando a compressão da pilha de rótulos é desativada, o resultado da computação CSPF multi-caminho é um conjunto de pilhas DE SID de adjacência. Quando a compressão da pilha de rótulos é ativada, o resultado é um conjunto de pilhas de rótulos compactadas (compostas por SIDs adjacentes e SIDs de nó).

Quando os caminhos secundários são computados, os enlaces, 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 quaisquer LSPs com resultado de computação mal-sucedido, a computação é revarinada com alterações no banco de dados de engenharia de tráfego (TED).

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

• Pesos associados a caminhos de uma política SR-TE
• Detecção de linhas de vida da BFD
• herdou-label-nexthops
• 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 LSPs PCEP SR-TE

• Os LSPs podem ter vários caminhos até um destino

• Oferece recursos de balanceamento de carga em vários caminhos

• Alinha-se ao projeto de arquitetura SR-TE

Os seguintes recursos de caminho múltiplos 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 o PCEP para vários caminhos, a compute-profile restrição para o número máximo de listas de segmentos (maximum-computed-segment-lists) como 1 é removida.

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 EXPLICIT-ROUTE (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. Os caminhos secundários incluem TLV MULTIPATH-BACKUP com conjunto de bandeiras.

As seguintes funcionalidades de PCEP são suportadas:

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

• Objeto MULTIPATH-BACKUP TLV em atributo de caminho (PATH-ATTRIB) apenas para LSPs SR-TE controlados por PCC

• TLV MULTIPATH-CAP em objeto LSP PCEP

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

• Vários caminhos primários e caminhos secundários no caminho do candidato ao 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 candidatos iniciados 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

• Suporte para BFD

• Sessão PCEP IPv6 para Junos até NorthStar Controller 6.2

• Vários caminhos de ERO para caminhos de candidatos de pce iniciados, configurados e controlados por PCC e delegados de caminhos de candidatos coloridos e não coloridos

• Relatar caminho de sub-candidato criado localmente com vários EROs/caminhos

• Compatível com o retrocompatível com versões anteriores do Paragon Pathfinder. Para compatibilidade reversa, você precisa configurar disable-multipath-capability a declaração de configuração no nível [edit protocols pcep] da hierarquia.

• Preferência do SR por caminhos de candidatos delegados e iniciados pelo PCE

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

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

As seguintes mensagens de erro do 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 composto

• Quando o recurso multicaminho é desativado no PCEP, não é permitido configurar vários caminhos de sub-candidato. No entanto, em dispositivos Junos sem recursos multicaminho (versões do Junos OS antes de 22.4R1), é permitida uma configuração de caminho de vários sub-candidatos. Quando o multi-segmento 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 caminhos de candidato SR-MPLS e SRv6 configurados e controlados (com configurações primárias individuais ou múltiplas). Não há impacto para caminhos de candidatos delegados e iniciados pelo PCE.

• Quando o recurso multicaminho PCEP é habilitado, as configurações de caminhos secundários são permitidas para caminhos de candidatos não delegados. Quando o recurso multicaminho PCEP é desativado, as configurações de caminhos secundários não são permitidas.

• Os caminhos dos candidatos 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 pelo 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.

Cópia de

Para permitir que o PCCD envie recursos multicaminhos 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, a TLV não é enviada 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 as seguintes rastreações 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 comutados por rótulos (LSPs) conhecidos pelo Cliente de Computação de Caminhos (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 spring-traffic-engineering lsp detail— Exibir detalhes de ingresso da engenharia de tráfego SPRING.