Resumo

  • O RFC 3429 atribuiu o valor reservado 14 do MPLS ao OAM Alert Label para identificar pacotes OAM do plano de usuário; isso não definiu todas as funções da recomendação Y.1711.
  • No caso de PHP coberto pelo texto, o LSR penúltimo podia remover o rótulo superior comum e preservar o rótulo OAM e o payload até um egresso MPLS com suporte a OAM. Um terminal incapaz de processar rótulos era outro caso, fora do escopo então previsto para Y.1711.
  • O TTSI transportado no pacote ajuda a identificar o LSR de ingresso. Não prova que o LSP esteja íntegro, que o tráfego do cliente chegou ou que um alarme foi tratado.

Uma rede pede PHP quando quer poupar o equipamento de saída de uma busca de rótulo. O valor 3, implicit-null, é distribuído pelo plano de controle para indicar que o LSR penúltimo deve remover o rótulo superior; esse valor nunca aparece no pacote. O ganho operacional, porém, abre uma questão diferente para a manutenção: depois de retirar esse rótulo, o que ainda informa ao egresso que o pacote é OAM e não tráfego comum?

O RFC 3429 separou as duas coisas. Ele destinou o valor 14, antes reservado no espaço definido pelo RFC 3032, ao OAM Alert Label. Esse rótulo identifica pacotes MPLS OAM do plano de usuário. Não é um protocolo completo de monitoramento, não descreve sozinho cada função da carga útil e tampouco obriga um roteador a suportá-lo.

O marcador permanece; o processamento depende do egresso

A recomendação Y.1711 da ITU-T define funções OAM e a estrutura de seus pacotes. O RFC 3031 descreve a arquitetura MPLS e o PHP. O RFC 3429 atribui um identificador de pacote dentro do espaço de rótulos MPLS. São peças de uma composição: uma especifica o mecanismo de manutenção, outra o encaminhamento e a terceira permite reconhecer o pacote depois da retirada do rótulo superior.

O primeiro cenário de PHP descrito no RFC mantém o egresso como LSR MPLS, com planos de controle e de dados. Esse equipamento pede o PHP porque não consegue executar duas buscas de rótulo à velocidade de linha. O LSR penúltimo tira o rótulo superior, mas encaminha intactos o OAM Alert Label e o payload. Se o egresso implementar MPLS OAM, ele reconhece o valor 14 no topo da pilha restante e trata o pacote como OAM.

O TTSI (Trail Termination Source Identifier) dentro do payload identifica o LSR de ingresso que originou a mensagem segundo esse mecanismo. É uma forma de preservar a referência à origem depois que o rótulo externo foi removido. Não reconstrói a história de cada salto, não atesta o caminho de volta e não confirma que uma aplicação remota recebeu dados. A identificação do emissor de uma prova e o resultado do serviço continuam sendo evidências diferentes.

PHP não significa sempre um destino MPLS

Há um segundo cenário: o destino não tem capacidade de buscar ou processar rótulos MPLS e nem reconhece pacotes rotulados. Ele também pode solicitar implicit-null e PHP. Mas o fato de o pedido ser igual não lhe dá um processador OAM. O RFC 3429 diz que as funções Y.1711 então descritas só podiam ser aplicadas ao primeiro cenário. O segundo permanecia para estudo futuro; cenários carrier supporting carrier também foram deixados para trabalho posterior.

Quando o egresso não suporta MPLS OAM, RFC 3429 afirma que o pacote é descartado. Isso pode deixar a equipe sem observação no terminal, mas não autoriza a concluir que o LSP estava saudável ou que o PHP causou a falha. O RFC 3031 explica por que uma etiqueta desconhecida não deve ser removida por tentativa e erro: o rótulo pode carregar significado que não pode ser recuperado do cabeçalho IP. Descartar pode ser mais seguro do que inventar uma interpretação, embora a lacuna de visibilidade permaneça.

Registro é uma convenção, não um inventário

O registro IANA de valores de rótulo MPLS continua associando o valor 14 ao OAM Alert Label e ao RFC 3429. A continuidade da alocação sustenta uma linguagem comum entre documentos. Ela não informa quais roteadores atuais implementam Y.1711, quais LSPs usam PHP ou quais contadores um fabricante expõe.

Publicado como RFC Informational em novembro de 2002, o documento não mede adoção. Sua contribuição foi estabelecer uma divisão verificável: a ITU-T especificava funções OAM, o IETF reservava uma etiqueta MPLS para identificá-las, e o suporte no ponto de terminação continuava necessário. O rótulo facilita a classificação; não presta o serviço de monitoramento no lugar do equipamento.

Uma avaliação operacional precisa separar pelo menos o pedido implicit-null, a ação do LSR penúltimo, a pilha recebida pelo egresso, a presença do rótulo 14, o suporte local a OAM, a correlação do TTSI e o resultado de cada função. A entrega de tráfego do cliente exige outra evidência. “Valor 14 registrado”, “OAM habilitado” e “LSP ativo” não são três maneiras de dizer que o cliente recebeu o serviço.

Fontes