Resumo

  • draft-many-teas-rsvp-power-00 propõe cinco modos para suspender e despertar bilateralmente um recurso TE identificado sem ambiguidade. A revisão 00 é um Internet-Draft individual; os valores do objeto RSVP POWER ainda não foram atribuídos.
  • O protocolo coordena vizinhos, enquanto um gestor local realiza a ação física. A conclusão confiável requer evidência do hardware nas duas pontas, custódia do estado TE, caminho de despertar que sobreviva e encaminhamento observado depois da restauração.

A sequência terminou sem erro: SleepPrepare, aceite, GoSleep, confirmação. O painel marcou o enlace como adormecido. O consumo não mudou porque uma condição local impediu a atuação no hardware.

Essa diferença está no centro de Power Transition Framework for TE Resources, de 30 de setembro de 2026. A sinalização proposta organiza o acordo entre equipamentos adjacentes; o gestor de energia local, fora do escopo, altera o estado físico. O documento proíbe declarar êxito apenas porque o pedido de suspensão foi enviado.

Trata-se da revisão 00 de um rascunho individual ligado ao TEAS, com status Standards Track pretendido e validade até 3 de abril de 2027. Não é RFC, consenso de grupo, atribuição da IANA ou prova de implementação. A classe e o C-Type do novo objeto POWER continuam TBD.

A transação precisa nomear o recurso exato

Dois roteadores podem compartilhar vários enlaces paralelos, cada um com reserva e proteção diferentes. Uma mensagem recebida por uma adjacência relacionada não autoriza escolher outra interface. A transação vale para um único recurso explícito.

No caso numerado, a realização RSVP usa o endereço local do emissor com índice zero. No caso não numerado, combina o identificador do roteador com o identificador TE local. Se o receptor não resolver a tupla de modo único, precisa rejeitar.

O recibo deve guardar essa identidade composta, o vizinho autenticado e a interface local resolvida. “A pediu a B que economizasse energia” não informa qual fibra foi retirada. A identidade delimita o risco.

Preparado não significa fisicamente desligado

Operating, Requisition, Ready, Pending e Sleeping são afirmações diferentes. SleepPrepareAck leva a Ready: o receptor aceita participar, mas ainda pode faltar autorização local e nenhuma ação material está provada. GoSleep inicia a etapa final; Pending espera confirmação.

Até GoSleepAck precisa ser relacionado à telemetria local. A mensagem pode demonstrar que o par correto percorreu o estado esperado. Ela não mede alimentação, não verifica o laser e não confirma que as duas pontas fizeram a mesma coisa.

Uma trilha forte junta dois planos. No protocolo: par, recurso, papel, estado esperado, mensagem e timeout. Na execução: decisão do gestor local e estado observado do hardware em cada ponta. Sem essa costura, “Sleeping” é apenas um rótulo bem organizado.

Falhar deve manter o enlace acordado

Recurso desconhecido, capacidade ausente, relação de par inválida, recusa local, mensagem defeituosa, falha de envio ou estado inesperado não podem desligar nada. O recurso permanece ou volta a Operating.

O perfil RSVP recomenda espera de 180 segundos nas fases de preparação e confirmação. É um temporizador, não um SLA medido. Quando expira, a transação é liberada, a falha é registrada e o timeout não autoriza a operação física.

Se as pontas iniciarem o mesmo recurso ao mesmo tempo, o maior identificador estável fica como Sender; a outra cancela sua tentativa e vira Receiver. A regra não trata enlaces paralelos distintos como uma única colisão. Ela resolve a corrida de protocolo, não a decisão econômica de reduzir capacidade.

O estado TE precisa atravessar o sono

Identidade, endereçamento, atributos TE e distinção entre enlaces paralelos permanecem disponíveis. LSPs, caminhos, reservas, rótulos e proteção devem ser preservados ou reconciliados segundo protocolo e política. Suspensão não é teardown implícito.

Preservação, porém, não garante coerência. Uma reserva pode envelhecer; uma base pode excluir o recurso enquanto outra ainda o oferece. Novos usos devem ser bloqueados durante a indisponibilidade e a elegibilidade só retorna após o despertar e a prontidão local.

O recibo de restauração precisa mostrar o que foi mantido, retirado, alterado e reinstalado. Guardar um objeto torna a volta possível; não demonstra que todos os controladores convergiram.

O despertador não pode usar o enlace adormecido

Qualquer ponta, política ou requisito de serviço pode iniciar GoWakeup, e repetições são idempotentes. O pedido, contudo, deve viajar por um caminho independente do recurso adormecido. Pelo menos uma rota de controle precisa sobreviver.

O nome “rede de gestão” não basta. Ela pode compartilhar placa, duto, trecho óptico ou alimentação. A proposta não exige uma topologia específica, mas transforma essa independência em obrigação de arquitetura local.

Receber o despertar também não encerra a recuperação. É preciso observar hardware pronto, adjacência ou alcance de volta, estado reconciliado, participação TE restabelecida e tráfego passando. Entrega da mensagem e retorno do serviço são eventos distintos.

A cadeia inclui versão, política autorizada, identidade composta, elegibilidade bilateral, preparação, ordem final, recibos físicos, custódia TE, caminho independente, prontidão, retorno ao TE e encaminhamento. Economia de energia e impacto de carbono exigem medição própria.

A formulação de Lu Heng sobre especificação inicial mínima mantém a camada comum focada em identidade, mensagens, papéis, colisões e falha segura. Elegibilidade, atuação, evidência e limiar de serviço ficam com o operador. Adoção voluntária aparece no código em execução e nos resultados, não na publicação.

Fontes