Resumo

  • A RFC 3472 transformou GMPLS em REQUEST, MAPPING e TLVs do CR-LDP; a subida podia estar utilizável antes de voltar o mapeamento de descida.
  • REQUEST encaminhada, Upstream Label válido ou tráfego em uma direção eram recibos parciais, não prova de serviço bidirecional concluído.

“Bidirecional” parece uma propriedade indivisível. Na cronologia da RFC 3472, porém, cada direção podia tornar-se real em momento diferente.

Publicada em janeiro de 2003 na trilha de padrões, ela deu formato CR-LDP às funções gerais da RFC 3471. Solicitação, rótulo, banda, sugestão, conjunto, proteção, estado administrativo e identificação de interface ganharam TLVs e procedimentos. A RFC 3473 fez o equivalente para RSVP-TE.

A REQUEST de um LSP bidirecional levava um Upstream Label. O valor precisava ser válido para encaminhamento no instante do envio. Cada receptor verificava sua aceitabilidade. Antes de repassar a REQUEST, cada intermediário alocava o rótulo de saída para subida e estabelecia o caminho interno que ligava os segmentos locais.

Ao chegar ao terminador, esse caminho já podia conduzir dados rumo ao iniciador. O terminador tinha permissão para usar imediatamente o Upstream Label. O outro sentido ainda aguardava Generalized Labels retornarem em MAPPING e serem aceitos e instalados salto por salto.

Assim, tráfego de subida com MAPPING de descida incompleto era um estado legítimo. A chegada da solicitação não provava reciprocidade, continuidade óptica ou sucesso de uma aplicação que dependesse de ida e volta.

Os controles da Generalized Label Request também eram distribuídos. Ingresso definia encoding e G-PID; Switching Type podia mudar. Cada nó testava entrada, capacidade local e saída ou túnel. Política local autorizava criar uma Forwarding Adjacency. Uma mensagem propagada não significava a mesma verificação em todos os lugares.

G-PID normalmente era examinado no egresso, com exceção PSC/PHP. Ausência de erro antes dali não constituía aprovação da carga cliente.

Suggested Label era apenas antecipação. Erros nela eram ignorados; se o jusante devolvesse outro valor, o montante reconfigurava ou rejeitava. O ingresso não deveria transmitir com a sugestão antes de receber a etiqueta correspondente. Preparar hardware não era decidir a alocação.

Label Set descrevia admissibilidade, não estoque. TLVs incluíam ou excluíam valores e intervalos; sua ausência tornava todos aceitáveis, não livres. Cada nó intersectava o conjunto com recursos reais. Interseção vazia encerrava o pedido.

A comparação usava comprimentos de onda físicos, embora enlaces pudessem numerá-los de maneira diferente. O nó traduzia para significado consistente ou removia a opção. Conversores podiam retirar o conjunto antes de encaminhar, ocultando restrições anteriores na mensagem final.

Bandas espelhadas exigiam trocar início e fim, nos dois sentidos de um túnel bidirecional. Mesmo intervalo lógico não significava associação física igual.

Explicit Label Control vinculava Label ER-Hop ao endereço ou IF_ID anterior. Ordem e direção incoerentes geravam erro. A origem das informações no head-end ficava fora do escopo.

Quando controle e dados eram separados, IF_ID nomeava o canal e voltava no MAPPING. Perder sinalização fora da fibra não deveria derrubar conexões existentes; recuperar a sessão não comprovava o cross-connect antigo.

CR-LDP não tinha a notificação rápida do RSVP. RELEASE e WITHDRAW propagavam a falha e liberavam recursos. A remoção invalidava rótulos de subida e descida; encaminhamento posterior seria estado residual.

A RFC 3468 registrou a escolha do IETF de cessar o desenvolvimento padrão do CR-LDP em favor do RSVP-TE. Isso explica a trajetória institucional, não apaga o mecanismo nem prova retirada instantânea.

Pelo princípio de código em execução de Heng Lu, mensagem é coordenação até hardware e tráfego confirmarem efeito. Especificação mínima deixa política local fora do núcleo. Camadas da realidade separam admissão, alocação, conexão, mapeamento, tráfego e aplicação.

O recibo completo guarda REQUEST, decisão e alocação em cada salto, aceitação terminal, primeiro tráfego, cada MAPPING de descida, observação dos dois sentidos e retirada. Só então “bidirecional” descreve serviço, não intenção.

Fontes