Resumo

  • Uma ERO em um PCRep bem-sucedido descreve a solução calculada para uma TED, restrições, objetivo e política específicos. Ela ainda não é confirmação de execução pelo PCC.
  • Sinalização, reserva, RIB/FIB, estado do LSP, tráfego observado e desempenho do serviço formam etapas posteriores, cada uma com sua própria evidência.

O controlador recebeu a resposta esperada. A rota aparece inteira no mapa, sem lacunas. É nesse ponto que uma boa interface pode produzir uma má conclusão: como o caminho parece completo, alguém registra que o serviço foi provisionado.

Nenhum roteador, porém, confirmou a instalação. A beleza da rota existe no domínio do cálculo. O plano de dados ainda não falou.

Em RFC 4655, Adrian Farrel, Jean-Philippe Vasseur e Jerry Ash desenharam uma arquitetura em que essa fronteira permanece visível. Um PCE calcula uma rota sobre um grafo e aplica restrições. Ele pode morar no roteador ou fora dele. Na composição externa, o headend consulta o PCE antes de iniciar a sinalização; o PCE usa a TED sob política local e devolve uma resposta.

O documento não coloca a sinalização dentro da resposta. Tampouco transforma o PCE em dono do encaminhamento. Essa modéstia arquitetural é uma força.

Um resultado condicionado pela informação disponível

A TED reúne topologia e recursos. Pode aprender por IGP ou por sincronização externa. Em qualquer caso, representa o que chegou ao PCE, não uma garantia de simultaneidade perfeita com todos os dispositivos.

RFC 4655 observa que uma sincronização menos eficiente pode aumentar falhas ou produzir caminhos subótimos. Assim, uma rota calculada deve ser acompanhada de sua proveniência: qual versão da TED, qual horário dos recursos e qual domínio de visibilidade.

O pedido também tem semântica própria. RFC 5440, de Vasseur e Jean-Louis Le Roux, descreve o PCReq com endpoints, banda, prioridades e outros objetos. Restrições estabelecem condições obrigatórias. RFC 5541 permite escolher uma função objetivo. A política local decide o que pode ser solicitado, calculado ou devolvido.

Esses campos não são sinônimos. Uma função objetivo pode minimizar custo entre caminhos já admissíveis; ela não substitui uma restrição de banda. Uma política pode mudar o resultado sem alterar a topologia. O ERO final só é reproduzível quando essas escolhas continuam disponíveis.

O significado limitado do sucesso

No fluxo positivo de RFC 5440, o PCE recebe o PCReq, calcula com sucesso e envia a solução ao PCC em um PCRep. A ERO codifica o caminho calculado do TE LSP e fica disponível para sinalização imediata.

Ficar disponível é entregar a próxima entrada. Não é receber o próximo recibo.

Se o ambiente usa RSVP-TE, RFC 3209 governa sinalização e reserva. O pedido percorre nós cujo estado pode divergir da TED usada no cálculo. Se usa Segment Routing, RFC 9256 diferencia candidate path, segment list, SR Policy no headend e o tráfego que é efetivamente direcionado. RFC 8664 transporta caminhos SR por PCEP; não lê a FIB nem observa pacotes.

As tecnologias executam de formas diferentes. A disciplina de evidência, no entanto, é comum: a representação de um caminho ainda não é o seu uso.

Mais estado exige mais precisão

O modelo stateful acrescenta relatórios, sincronização e delegação. RFC 8231 deixa claro que o PCC retém a propriedade do estado do LSP e aplica sua política local aos atributos vindos do PCE. A delegação concede controle sobre atributos de um LSP e pode ser revogada; não entrega o roteador ao PCE.

O PCRpt é uma evidência posterior. O PCC informa Up ou Active quando o LSP atinge esse estado e informa Down com a causa se a configuração falhar. O próprio RFC afirma que não há correlação direta entre PCRep e PCRpt e que vários relatórios podem seguir uma resposta.

Isso explica por que stateful não significa infalível. Significa que o protocolo dispõe de mensagens adicionais para representar mudanças reais. RFC 8281 permite que o PCE inicie um LSP, mas iniciar continua diferente de observar sua conclusão.

Do controle ao serviço

Uma cadeia de verificação madura começa pela aceitação do PCC. Depois pergunta se houve sinalização ou programação, se recursos foram reservados quando necessário e se o estado apareceu na RIB e na FIB. Só então procura os pacotes: contadores de interface, probes, traces ou telemetria de fluxo. Perda, latência, jitter e disponibilidade em um intervalo definido sustentam a última alegação, a de serviço.

As fronteiras evitam atalhos perigosos. RIB não é FIB. FIB não é tráfego. Tráfego pontual não é SLA. Um LSP Up pode provar mais que o PCRep sobre o controle, mas não certifica a experiência completa do cliente.

A documentação PCEP da Juniper trata separadamente sessão, LSP, detalhes de SPRING-TE e rotas, e diz que o PCC volta a sinalizar após receber atributos. Um guia de troubleshooting do Paragon descreve um pedido reconhecido pelo servidor enquanto o LSP permanece Down porque o PCC não consegue sinalizar. É uma implementação específica, mas mostra um caso real em que confirmação de controle e estado operacional divergem.

O crédito que cabe a Farrel

O registro público de Farrel no IETF reúne dezenas de RFCs e funções. Aqui, o crédito é concreto e compartilhado: RFC 4655, com Vasseur e Ash, oferece a arquitetura que separa a pergunta computacional da execução. Vasseur e Le Roux assinam o PCEP básico. O grupo PCE, autores posteriores, comunidades de RSVP-TE e SR, implementadores e operadores completam o sistema.

Não atribuir tudo a Farrel não diminui sua contribuição. Pelo contrário, aplica à autoria a mesma honestidade usada na operação: uma peça importante não deve ser confundida com a cadeia inteira.

Registro de fontes