Resumo

  • O RFC 5150 combina LSPs de segmento GMPLS dedicados, ou S-LSPs, em um LSP fim a fim.
  • Cada S-LSP admite no máximo um LSP e2e e dedica toda a sua banda à associação.
  • A origem pede stitching pelo bit 5 de LSP_ATTRIBUTES; o destino responde com o bit correspondente de pronto no RRO.
  • Um destino capaz devolve rótulo não nulo; se reconhece e não suporta, usa Routing Problem valor 30.
  • A troca de prontidão prepara o segmento, mas não comprova a programação posterior do encaminhamento e2e.
  • As pontas podem parecer adjacentes na topologia TE sem terem forwarding adjacency no plano de dados.
  • Label e Upstream Label no salto e2e sobre o S-LSP não têm significado e devem ser ignorados.
  • A continuidade depende de swaps locais nas duas bordas e, no caso bidirecional, nos dois sentidos.
  • O RRO e2e registra o ponto terminal do segmento e omite os enlaces e nós intermediários internos.
  • O encerramento do S-LSP e o do LSP e2e são independentes; a reação exata de recuperação está fora do escopo.
  • A autenticação RSVP protege vizinhos do controle, não o plano de dados separado nem a carga útil.
  • Reserva, prontidão, execução, saúde interna, recuperação e resultado do cliente exigem recibos distintos.

Exclusividade é uma regra de admissão

Na hierarquia, um H-LSP pode carregar vários LSPs de camada superior, usando rótulos significativos para separá-los. O stitching permanece na mesma camada. Um S-LSP só pode ser associado a um LSP e2e, e toda a banda do segmento é atribuída a essa relação.

Depois da alocação, a banda não reservada deve ir a zero. Se vários S-LSPs forem agrupados em um único enlace TE, cada componente continua limitado a uma associação e seus parâmetros de banda precisam ser recalculados. Essa regra evita que o cálculo ou a admissão coloquem dois LSPs no mesmo recurso dedicado.

Ela não mede o que atravessou o recurso. Reserva é estado do controle; throughput, perda, atraso, fila e sessão da aplicação pertencem ao plano de dados. Um zero correto na TED pode coexistir com swap ausente na borda ou falha dentro do segmento.

A preparação diz que o destino sabe participar

Antes do uso e2e, o head end do S-LSP coloca LSP stitching desired no bit 5 do TLV Attributes Flags. O destino que reconhece e suporta o procedimento aloca um rótulo não nulo na Resv e marca LSP segment stitching ready no subobjeto Attributes do RRO.

Quando entende o pedido mas não consegue executar o comportamento, ele retorna PathErr com Routing Problem, valor 30 Stitching unsupported. Uma implementação que conhece o objeto, mas não reconhece o TLV ou o bit, pode ignorar a solicitação. A origem precisa conferir o retorno e não pode usar um segmento cujo bit esteja limpo.

Pronto, nesse contrato, é uma declaração de capacidade e preparação do segmento. Não é uma leitura dos swaps do LSP e2e, que ainda será selecionado conforme switching type, ERO, banda e política local. Também não é uma sonda de tráfego.

O rótulo do salto abstrato não encaminha

Um LSP e2e bidirecional precisa enviar Upstream Label no Path sobre o salto S-LSP, e o destino precisa enviar Label no Resv. O formato se parece com uma troca de encaminhamento normal. O significado é diferente.

Não existe forwarding adjacency entre as pontas do S-LSP. O RFC permite qualquer valor e manda o destinatário ignorá-lo. Esses objetos mantêm o procedimento RSVP-TE através do salto lógico, mas não nomeiam uma operação direta de dados entre as pontas.

O encaminhamento real depende de ações locais. A entrada troca o tráfego do trecho e2e anterior para dentro do S-LSP. A saída troca o tráfego do S-LSP para o trecho e2e seguinte. Serviço bidirecional requer ações inversas. Para provar continuidade, é preciso ler ambos os pontos e enviar tráfego; contar objetos Label produz apenas uma evidência sintática.

Um enlace TE pode esconder muitos enlaces

O S-LSP pode ser anunciado como enlace TE e usado no cálculo. Na topologia, as pontas parecem adjacentes. No plano de dados, o segmento pode atravessar vários nós e não cria adjacência direta. A publicidade é opcional e aumenta a base de estado de enlace.

O RRO do LSP e2e deve registrar o endereço ou identificador não numerado do enlace S-LSP. Os nós e enlaces intermediários do próprio segmento não devem ser listados naquele salto. Um RRO completo comprova a abstração prevista, não o interior.

Em uso interdomínio, o segmento local pode nem ser anunciado fora do domínio; cálculo por domínio ou PCE preenche parte da lacuna. Nenhuma dessas representações demonstra diversidade física, estado de cada LSR ou caminho efetivamente percorrido por uma carga.

Criar sob política local cria uma origem decisória

O S-LSP pode nascer por configuração administrativa ou dinamicamente em resposta a uma solicitação. O gatilho de fronteira de regiões usado na hierarquia não deve ser aplicado ao stitching. As capacidades de comutação dos enlaces anterior e seguinte precisam ser iguais, e a política local decide a criação dinâmica.

Essa política é parte da evidência: versão, proprietário, restrições de ERO, banda e escolha do componente. Dizer apenas “o protocolo criou” apaga quem decidiu usar um recurso dedicado e quem aceitou o custo de ocultar o trecho.

O mecanismo também pode contornar nós legados, inclusive entre LSRs capazes de P2MP. O próprio RFC pede exame cuidadoso porque a configuração pode reduzir a atratividade do RSVP P2MP. Compatibilidade imediata pode se tornar dependência duradoura.

A banda pode voltar antes ou depois da sessão

S-LSP e LSP e2e têm sessões e teardown independentes. Um pode encerrar com ADMIN_STATUS e o outro retirar estado imediatamente. Um segmento estático pode permanecer após o fim do e2e; um dinâmico pode ser removido por política quando ficar ocioso.

O teardown do S-LSP deveria ser tratado como falha do e2e e acionar recuperação ou encerramento, mas o procedimento exato fica fora do RFC 5150. Uma ação disparada não é um caminho restaurado.

O atraso recomendado de cerca de 30 segundos antes de apagar um segmento dinâmico reduz mensagens simultâneas de erro e teardown. Não reserva continuidade para o usuário. É preciso acompanhar liberação de banda, rótulos, nova rota, swaps e fluxo real.

Mensagens RSVP ainda podem viajar por interface diferente daquela que descrevem. A associação de segurança se prende aos vizinhos de controle e suas identidades IP. Autenticação válida não prova o plano de dados. Os valores IANA e a errata editorial estabilizam a linguagem, não confirmam implantação.

Fontes

  1. RFC 5150, HTML
  2. RFC 5150, texto
  3. Registro no RFC Editor
  4. Registro no IETF Datatracker
  5. Histórico do RFC 5150
  6. Referências do RFC 5150
  7. Errata do RFC 5150
  8. RFC 4206
  9. RFC 3209
  10. RFC 3473
  11. RFC 4420
  12. RFC 3477
  13. RFC 4201
  14. RFC 4203
  15. RFC 4205
  16. RFC 2747
  17. RFC 3032
  18. RFC 5151
  19. Parâmetros RSVP da IANA
  20. Minimum Initial Specification
  21. On Reality Layers
  22. Running-Code Primacy