Resumo

  • O cliente solicita uma conexão entre CEs admitidos; o provedor aplica política, calcula o trecho PE-PE, reserva capacidade e conserva o controle do núcleo.
  • O contrato identifica quem deveria usar o serviço, mas autenticação de sinalização, leitura do cross-connect e entrega real precisam de comprovantes próprios.

A ordem de serviço tinha dois endereços, não um mapa

Um portal permite escolher origem e destino. O botão “conectar” dá ao cliente ação direta, mas não lhe entrega os equipamentos que ficam no caminho. RFC 5253 descreve essa divisão sem ambiguidade.

O cliente controla a topologia solicitada do L1VPN: cria, remove ou altera conexões entre bordas elegíveis. O provedor controla integralmente o segmento PE-PE. Pode calculá-lo sob demanda, usar um cálculo anterior ou encaixar a solicitação em um segmento já estabelecido. Uma ERO enviada pelo CE não pode impor a rota interna; o PE deve rejeitar essa tentativa.

Portanto, “controle do cliente” não significa soberania sobre a rede óptica. Significa autoridade para declarar um resultado desejado dentro de um conjunto permitido. A engenharia e a execução pertencem ao provedor.

Essa distinção muda a prova. Receber a ordem não é admiti-la. Admitir não é reservar. Reservar não é programar os dois lados. Programar não é entregar a carga ao destino certo. Cada verbo tem um controlador e um recibo.

Nenhuma rota cruza a borda, mas muita dependência cruza

Basic Mode não troca roteamento entre CE e PE. O CE aprende o CPI remoto por configuração, diretório ou outro processo específico. Dentro do domínio do provedor, o roteamento continua, e informações de associação podem circular entre PEs.

O desenho protege o núcleo e reduz acoplamento. Também deixa o cliente dependente de decisões que não enxerga: a tabela PIT correta, a associação vigente, a política de conectividade, a capacidade disponível e a versão do cálculo.

O cálculo pode ocorrer no PE, em um PCE ou num sistema de gestão. Podem existir vários segmentos para o mesmo par de bordas. Uma Path Key pode nomear um trecho confidencial sem revelar seus nós. É uma boa abstração — desde que ninguém confunda o nome opaco com prova de estado atual.

O provedor não precisa publicar sua malha. Precisa preservar internamente a ligação entre pedido, política, caminho, reserva, configuração e medição. O cliente não precisa conhecer a malha. Precisa receber evidência do resultado contratado.

Um identificador secreto não mede a luz

Políticas podem valer para todo o L1VPN ou para uma conexão individual e podem refletir o contrato comercial. Recursos podem ser particionados. Um segmento pré-estabelecido pode ser escolhido para um cliente específico.

Essas opções dão eficiência, mas também criam camadas onde a linguagem corre à frente dos fatos. Uma chave de caminho não mostra qual fibra está ativa. Um Resv não expõe a revisão da política que autorizou o pedido. Um atributo de proteção não demonstra independência física. Um status de faturamento não lê o equipamento.

A prova precisa de duas faces. A face interna guarda solicitação, decisão, cálculo, admissão, reserva, programação e leitura posterior. A face externa guarda os CEs acordados, a identidade remota, os objetivos de serviço, a proteção do conteúdo e a medição ponta a ponta. Elas podem ter níveis diferentes de detalhe; devem apontar para a mesma ocorrência.

O segredo topológico é assimétrico por projeto

O provedor consegue ocultar seu núcleo porque não distribui rotas ao CE. Pode filtrar o RRO, substituir no Notify um endereço interno pelo endereço do PE e usar uma chave para um caminho confidencial.

O cliente não fica invisível do mesmo modo. O provedor conhecerá ao menos endereços e locais dos CEs. Sem isso, não consegue associar portas, aplicar a matriz de conectividade e impedir mistura entre L1VPNs. O restante da rede do cliente pode continuar privado, mas os pontos de entrada são conhecidos.

Essa assimetria não prova abuso. Ela produz uma responsabilidade. Localização de CE pode revelar concentração, contingência e instalações críticas. Deve ter finalidade explícita, acesso mínimo, retenção limitada e trilha de uso.

Também há responsabilidade no outro sentido. Confidencialidade do núcleo não é autorização para promessas impossíveis de testar. O provedor pode esconder hops e ainda provar classe de diversidade, tempo de restauração e qualidade observada.

O cadastro no contrato não autentica o pacote

Ao adicionar um CE, a entidade é identificada no processo contratual e o canal de controle é estabelecido. RFC 5253 separa isso da autenticação: sem usar os procedimentos RSVP-TE adequados, a entidade de sinalização não está autenticada.

Contrato diz quem deveria ter autoridade. Configuração diz qual endereço o representa. Autenticação liga uma mensagem a uma credencial. Integridade detecta alteração. Autorização decide se a mensagem autêntica pode executar aquela ação.

Um único campo “cliente confiável” apaga falhas possíveis. Uma chave antiga pode sobreviver ao encerramento. Um cliente legítimo pode pedir uma conexão proibida. Uma mensagem íntegra pode terminar em cross-connect errado.

Nem o canal fisicamente separado encerra o tema. Ele pode ser considerado seguro, mas o RFC exige que mecanismos adicionais, como IPsec, permaneçam disponíveis. Quando o canal é compartilhado, a proteção deve existir e ser aplicada. Cabos separados descrevem arquitetura, não autenticam cada troca.

A recusa na saída cobra pedágio do núcleo

Restrições podem ser aplicadas no PE de entrada ou no de saída. Ambas impedem a conexão final. Só a primeira pode interromper cedo uma solicitação cuja inelegibilidade já é conhecida.

Se a decisão ficar para a saída, o pedido atravessa a rede, consome processamento e pode criar estado temporário. O próprio RFC reconhece esse desperdício de sinalização. Por isso, “tentativas bloqueadas” não é uma métrica suficiente.

É preciso registrar onde ocorreu o bloqueio, quantos sistemas foram tocados, quanto tempo o estado levou para desaparecer e se disputou recursos com pedidos legítimos. Validação no egresso continua útil como defesa adicional. Não deve substituir uma regra estável que poderia ser aplicada no ingresso.

Proteção precisa nomear o tipo de falha

Basic Mode aproveita mecanismos GMPLS para proteger o segmento PE-PE, links e o plano de controle. As combinações têm limites. Um pedido de proteção de link não protege isoladamente só CE-PE ou só PE-PE. O modelo não combina recuperação por link na borda com recuperação por segmento no núcleo. Recuperação CE-CE por dual-homing a PEs diversos fica fora do escopo.

“Conexão protegida” só ganha sentido quando identifica falha e fronteira: acesso, núcleo, equipamento, instalação ou risco compartilhado. Aceitar o pedido não prova que a reserva é independente. Recuperar RSVP não prova que a matriz óptica mudou. Restaurar a luz não prova que o aplicativo voltou.

O monitoramento deve manter os relógios separados. Essa separação mostra qual controlador cumpriu — ou não — sua parte.

Um circuito dedicado ainda pode terminar no lugar errado

Uma conexão óptica dedicada é mais difícil de interceptar, e limitar cada conexão a um L1VPN oferece isolamento. Mesmo assim, RFC 5253 mantém a misconnection como vulnerabilidade. Um cross-connect incorreto pode entregar dados ao consumidor errado enquanto o circuito continua parecendo exclusivo.

Verificar que os dois CEs pertencem ao mesmo L1VPN é necessário, mas não observa o destino físico final. Clientes com conteúdo sensível devem proteger sua própria camada, por exemplo com IPsec para tráfego IP.

A evidência forte nasce da sobreposição de visões. O provedor lê cross-connects e recursos. O cliente autentica a ponta e testa a entrega. Nenhum lado transforma seu ACK em certificado do domínio que não enxerga.

Duas autoridades, dois conjuntos de recibos

Cada conexão deve conservar: versão contratual e CEs elegíveis; credencial do canal; origem, destino e atributos; decisão de entrada; segmento e cálculo; admissão e reserva; leitura dos dois limites; escopo de proteção; campos de topologia filtrados; criptografia do cliente e resultado da entrega.

O cliente pode contestar sem exigir o mapa. O provedor pode demonstrar que não cedeu sua rota sem publicar o mapa. O elo entre os registros precisa ser acordado antes da falha.

RFC 5253 não cria um plano de comando compartilhado. Cria uma costura entre intenção e execução. Tornar essa costura auditável é o que impede que privacidade, contrato e sinalização sejam confundidos com serviço entregue.

Sources