Resumo

  • A RFC 5420 usa transporte de atributos baseado em TLV porque o campo Flags de oito bits de SESSION_ATTRIBUTE não comportava extensões contínuas. As extensões se aplicam a LSPs MPLS e GMPLS, tanto de pacotes quanto não baseados em pacotes.
  • O TLV Attribute Flags não marca, por si só, um atributo como obrigatório. Ele pode aparecer em LSP_ATTRIBUTES ou em LSP_REQUIRED_ATTRIBUTES; o objeto que o carrega determina encaminhamento transparente ou exame obrigatório em todo o caminho.
  • LSP_ATTRIBUTES tem classe 197, na forma C-Num: um LSR que não reconhece o objeto deve encaminhá-lo inalterado, em vez de rejeitar a mensagem Path. Dentro dele, TLV não reconhecido e bit de Attribute Flags não reconhecido também seguem inalterados. LSP_REQUIRED_ATTRIBUTES tem classe 67: cada LSR de trânsito deve examinar e agir sobre o conteúdo; objeto, tipo de TLV ou bit marcado desconhecido exige PathErr com o TLV Unknown Attributes ou o erro Unknown Attributes Bit correspondente.
  • “Obrigatório” exige exame ao longo do caminho, mas não define uma reação universal para todo atributo não suportado. Se o atributo é reconhecido, mas não suportado, a RFC que define aquele TLV ou bit continua sendo a autoridade semântica.

Solicitante, trânsito e encaminhamento seguinte

O solicitante ou a entrada escolhe a fronteira de dependência. Se somente a saída precisa agir, ou se basta interpretação seletiva, LSP_ATTRIBUTES preserva a possibilidade de atravessar nós legados. Se o exame por todos os LSRs de trânsito é condição do estabelecimento, escolhe-se LSP_REQUIRED_ATTRIBUTES. O TLV Attribute Flags não faz essa escolha sozinho: o mesmo TLV ou bit pode estar em qualquer um dos dois objetos, e o objeto transportador determina a consequência.

Cada LSR de trânsito aplica as regras de reconhecimento do objeto. Em LSP_ATTRIBUTES, objeto, TLV ou bit desconhecido não é, por essa regra, motivo para rejeitar o Path; o conteúdo deve seguir inalterado. Em LSP_REQUIRED_ATTRIBUTES, um LSR que não reconhece o objeto, o TLV ou o set bit deve rejeitar o estabelecimento com o PathErr de Unknown Attributes correspondente. Quando o LSR reconhece o atributo, mas não o suporta, a autoridade não é uma regra universal de class 67: deve-se seguir a RFC que define o TLV ou bit.

O encaminhamento para os próximos nós é uma terceira questão. Encaminhar LSP_ATTRIBUTES sem alteração mostra transporte, não prova que o LSR entendeu ou aplicou o atributo. A ação da saída e o comportamento de um key-transit precisam ser avaliados pela semântica da RFC definidora e pelos relatórios que ela autorizar. O solicitante pode exigir exame de caminho, mas não pode usar o objeto-base para substituir a semântica do atributo.

Os três contrafactuais são explícitos. Primeiro, TLV ou bit desconhecido em LSP_ATTRIBUTES é encaminhado inalterado. Segundo, objeto, TLV ou set bit desconhecido em LSP_REQUIRED_ATTRIBUTES rejeita o estabelecimento. Terceiro, atributo reconhecido mas não suportado segue a RFC que o define, e não uma regra universal de rejeição ou continuidade.

LSP_REQUIRED_ATTRIBUTES não é usado no Resv. LSP_ATTRIBUTES no Resv pode informar o estado do LSP inteiro; isso não é o mesmo que o status específico de cada salto no subobjeto RRO Attributes. Esse subobjeto fica vinculado ao LSR identificado pelo subobjeto de endereço ou interface imediatamente anterior. Um nó não deve inserir Attributes sem inserir também esse identificador. Um bit de RRO Attributes pode informar compliance ou non-compliance, mas se o relatório é significativo ou obrigatório depende da RFC que define o atributo. Portanto, a existência de relatório não é uma prova universal.

Relatórios por salto podem expor estado operacional e consomem espaço do RRO e da mensagem RSVP. Se o subobjeto adicional tornar o RRO grande demais para uma mensagem Path ou Resv, aplicam-se as regras de RRO excedente da RFC 3209.

Na fronteira de uma região LSP, um forwarding-adjacency LSP pode herdar parte dos Attributes TLV quando a política local permite e a fronteira suporta os objetos relevantes. Caso contrário, os objetos de atributo são copiados junto com o ERO herdado. O TLV Attribute Flags e o subobjeto RRO Attributes compartilham um único espaço de numeração de bits administrado pela IANA; cada RFC definidora precisa dizer onde o bit tem significado e como tratar o padrão zero. A RFC 7570 é uma extensão genérica posterior do mecanismo da RFC 5420 para atributos de ERO/RRO específicos por salto e orientação de registros.

Ela não prova implantação universal e não é um mecanismo especificamente voltado a proteção. A distinção entre transporte opcional e exame obrigatório permanece.

Três dependências e seus custos

  • Somente saída: o transporte opcional preserva a passagem por nós legados. A ação da saída precisa ser confirmada pela semântica do atributo ou por evidência de RRO; a criação bem-sucedida do LSP, sozinha, não comprova aplicação.
  • Trânsito-chave: se o key-transit não entende o atributo, o modo opcional pode preservar o encaminhamento, mas não a garantia. Se esse salto é uma condição, a RFC definidora e a política do solicitante devem exigir exame apropriado.
  • Todos os LSRs: quando cada salto precisa entender, class 67 faz um objeto, TLV ou bit desconhecido provocar resultado fail-closed. Para atributo reconhecido mas não suportado, volta-se à RFC definidora; não se presume rejeição ou continuidade universais.

O exame obrigatório beneficia serviços que realmente precisam de suporte em todo o caminho, mas reduz o domínio compatível e pode converter um único salto sem suporte em setup failure. O transporte opcional preserva compatibilidade, com garantia mais fraca. Relatórios no RRO consomem espaço e podem revelar o estado operacional de cada salto; herança de FA-LSP exige política de fronteira; e o registro compartilhado exige coerência semântica futura.

O conjunto de fontes não informa quais fornecedores ou operadores implementam atributos ou relatórios específicos, nem prevalência, taxas de falha, latência de estabelecimento, desempenho, valores comerciais ou resultados de clientes. Também não determina quais atributos futuros devem ser optional, required, egress-only ou key-hop-specific; isso depende da RFC definidora e da política operacional. A página de errata congelada é o registro atual da RFC 5420, sem uma alegação adicional de correção neste texto.

Fontes