Resumo

  • A RFC 3037 recomendou implementar o LDP básico em equipamentos que encaminham MPLS por caminhos normais, baseados em destino; não tornou o LDP obrigatório em todo equipamento MPLS nem provou que uma instância estivesse configurada e ativa.
  • O documento separou a distribuição salto a salto do tráfego com rota explícita e deixou visíveis vários comprovantes independentes: descoberta, conexão TCP, acordo de parâmetros, sessão operacional, troca de vínculos, estado retido, programação do encaminhamento e tráfego observado.

A palavra mais fácil de exagerar na RFC 3037 não é o nome de um protocolo. É “recomendado”. Em uma seção curta sobre nível de requisito, o texto recomendou implementar LDP nos equipamentos que realizam encaminhamento MPLS por caminhos normais escolhidos pelo roteamento baseado em destino. Era um juízo de engenharia delimitado. Não era um mandato universal, um certificado de implementação nem um relatório de uma rede em funcionamento.

Publicada em janeiro de 2001 como RFC Informational, ela respondia a uma pergunta de aplicabilidade: onde o LDP básico se encaixava entre as maneiras possíveis de distribuir rótulos MPLS? A resposta traçou uma fronteira em torno do caminho roteado comum. Lê-la com precisão exige não confundir adequação de protocolo com fato operacional.

O caminho em questão era o caminho normalmente roteado

O encaminhamento MPLS exigia que Roteadores de Comutação por Rótulos adjacentes compartilhassem o significado dos rótulos usados entre eles e através deles. O LDP fornecia procedimentos pelos quais um LSR anunciava um vínculo que havia criado. A RFC 3037 descreveu esses procedimentos como suporte à distribuição de rótulos ao longo de caminhos já escolhidos pelo roteamento baseado em destino — o encaminhamento MPLS salto a salto.

Essa função podia ligar mecanismos heterogêneos. LDP, um plano de roteamento IP e software capaz de programar conexões cruzadas ATM ou Frame Relay podiam transportar IP por redes comutadas sem uma sobreposição ou um sistema de endereçamento e roteamento próprio daquela tecnologia. Um LDP independente também evitava exigir o mesmo protocolo de roteamento capaz de transportar extensões em cada salto.

Cada “podia” tinha um objeto limitado. A arquitetura podia remover uma dependência; não provava que o software de conexão cruzada existisse em um comutador nomeado, que todos os saltos formassem sessão ou que o caminho resultante levasse tráfego. Aplicabilidade identificava uma maneira de montar o sistema. Não relatava que a montagem havia acontecido.

A mesma fronteira separava o LDP básico da engenharia de tráfego. LSPs com rota explícita não precisam seguir o caminho escolhido pelo roteamento comum. A RFC 3037 citou extensões CR-LDP e RSVP-TE como dois possíveis mecanismos e registrou que não havia então consenso sobre superioridade técnica. Cabia aos administradores escolher segundo suas necessidades e circunstâncias. O mecanismo de extensão do LDP permitia trabalho adicional; não tornava uma extensão parte do protocolo básico só porque existia um ponto de extensão.

A recomendação recaía sobre uma função, não sobre toda caixa

A declaração de requisito era precisa: a implementação era recomendada para equipamentos que realizavam encaminhamento MPLS em caminhos normais, baseados em destino. A condição importa. Um equipamento fora dessa função não se tornava não conforme por não ter LDP básico, e um equipamento com código LDP não se tornava operacional só porque a declaração o favorecia.

Implementação é apenas um comprovante. O software pode estar presente e a função desativada. Um processo ativo pode não descobrir par algum. A descoberta pode não produzir uma conexão TCP. A conexão pode falhar na negociação. Uma sessão operacional pode não trocar vínculo útil. Um vínculo pode nunca chegar à tabela de encaminhamento. Um rótulo programado pode não receber pacote algum.

O padrão podia recomendar a primeira capacidade sem observar nenhum dos estados seguintes. Isso não é defeito. É o que permite que a recomendação atravesse produtos e operadores sem fingir conhecer seu estado de execução.

Uma sessão era uma sequência, não uma única luz verde

A RFC 3037 resumiu o caminho de controle do LDP em etapas. A descoberta encontrava um par potencial. O estabelecimento da sessão criava uma conexão TCP. Os pares negociavam parâmetros, inclusive o método de distribuição. Só após o acordo a sessão se tornava operacional para distribuir rótulos.

O TCP fornecia entrega confiável das mensagens de sessão e dispensava atualização periódica dos rótulos e do estado associado. Mas a confiabilidade pertencia ao fluxo de bytes. Não provava que o par aceitara o significado pretendido, que o vínculo continuasse coerente com o roteamento, que o hardware estivesse programado ou que um pacote chegasse ao destino.

A ausência de atualização periódica também mudava o ônus da prova. Estado durável era eficiente, mas quem investigasse uma falha posterior não podia inferir atualidade da ausência de retransmissão. Continuidade da sessão, dependência do roteamento, ciclo de vida do vínculo e uso no plano de dados precisavam de seus próprios horários.

O menu de modos continha um argumento sobre recursos

O LDP não impunha uma combinação universal. Em Downstream Unsolicited, um LSR anunciava um vínculo FEC-rótulo quando estava pronto para encaminhar aquela FEC. Em Downstream on Demand, respondia a uma solicitação. Retenção liberal guardava rótulos aprendidos de pares mesmo sem uso imediato; retenção conservadora liberava os desnecessários. Controle independente permitia anunciar quando o LSR considerasse adequado; controle ordenado esperava um vínculo do próximo salto da FEC ou a condição de egresso.

A RFC 3037 agrupou essas opções em torno da escassez. Quando os valores de rótulo eram limitados, como em enlaces ATM e Frame Relay, considerou apropriados distribuição sob demanda, retenção conservadora e controle ordenado. Quando eram abundantes, distribuição não solicitada, retenção liberal e controle independente podiam acelerar uma mudança de próximo salto, pois rótulos úteis já estavam disponíveis.

“Apropriado” era condicional, não absoluto. O protocolo admitia outras combinações e variantes híbridas. Poupar rótulos sacrificava alternativas retidas; guardar alternativas consumia estado. Anunciar cedo alterava o momento da alegação a montante; esperar alterava a dependência do estabelecimento. O documento oferecia uma superfície de decisão, não um teste que proclamasse um vencedor para toda rede.

Capacidade exigida ainda podia estar desativada

A regra de detecção de laços tornava explícita a diferença entre capacidade e estado. O LDP definia um mecanismo para proteger LSPs que atravessassem nuvens MPLS sem TTL. Um LSR conforme precisava implementá-lo, mas o operador podia desativá-lo por configuração.

Um equipamento podia, portanto, declarar conformidade e também declarar que a detecção estava desligada. Mesmo ativada num equipamento, isso não estabelecia proteção em todo o domínio. A cadeia útil de evidências era suporte de implementação, configuração local, parâmetros dos pares, informações propagadas de vetor de caminho ou saltos, estado de rota e encaminhamento observado.

O mecanismo de extensão tinha o mesmo limite. O LDP definia como introduzir novas mensagens e TLVs, reconhecer tipos desconhecidos e responder quando uma implementação não os suportasse. A RFC 3037 advertia que nem toda melhoria futura seria retrocompatível. Um procedimento correto para TLV desconhecido tornava a evolução mais segura; não provava que dois pares compartilhassem determinada extensão.

Afirmações de escala nomeavam custos, não capacidades

O documento explicou por que a distribuição incremental podia escalar: os vínculos não exigiam atualização periódica. Também nomeou os custos opostos. Modos para rótulos escassos restringiam a alocação. Retenção liberal reduzia redistribuição após uma mudança de próximo salto. O número de conexões TCP suportadas por uma implementação limitava seus pares. A detecção por vetor de caminho consumia memória, processamento e tráfego de controle.

Nada disso fornecia a capacidade numérica de um produto. O operador ainda precisava medir pares, espaço de rótulos, memória, CPU, mensagens, reconvergência e encaminhamento. Uma propriedade do protocolo explica quais contadores importam; não é a leitura do contador.

A segurança era igualmente estreita. TCP MD5 opcional podia dificultar a injeção de segmentos falsos no fluxo da sessão LDP. Não autenticava a legitimidade de uma FEC, não autorizava uma rota, não provava um vínculo verdadeiro nem protegia a aplicação carregada pelo LSP.

O consenso posterior não reescreveu a fotografia anterior

A RFC 3037 registrou um momento em que CR-LDP e RSVP-TE eram respostas possíveis para LSPs explicitamente roteados, sem um vencedor por consenso técnico. As RFCs 3209, 3212 e 3213 detalharam depois os dois ramos.

Em fevereiro de 2003, a RFC 3468 registrou a decisão posterior do grupo de trabalho e do IESG de concentrar novo trabalho de sinalização MPLS no RSVP-TE e não empreender novo trabalho de grupo sobre CR-LDP. Ela manteve deliberadamente o status dos RFCs CR-LDP existentes e não proibiu contribuições individuais. Essa decisão comprova uma alocação de trabalho de padronização em data posterior. Não comprova que todo operador migrou, que toda implementação desapareceu ou que a incerteza registrada em janeiro de 2001 estivesse errada quando foi publicada.

A lição histórica é uma disciplina de verbos. Um organismo de padronização recomenda. Um fabricante implementa. Um operador ativa. Pares descobrem, conectam e concordam. Um plano de controle distribui. O hardware instala. Pacotes atravessam. A RFC 3037 foi clara sobre o primeiro verbo. Os demais ainda exigiam comprovantes.

Fontes

Lu Heng não escreveu nem endossou a RFC 3037 ou os padrões relacionados. Seus ensaios são usados aqui como lentes analíticas declaradas.