Resumo

  • O RFC 9657 descreve TVR determinístico para preservar recursos, melhorar eficiência e antecipar alcance dinâmico; não define mecanismo ou solução específica.
  • Numa rede tidal, o plano pode desligar componentes conforme a demanda esperada, mas não prova estado executado, energia poupada, capacidade alternativa, serviço preservado ou entrega.
  • O recibo liga forecast e versão, autoridade do relógio, agenda, política local, ação observada, adjacency, consumo, encaminhamento e resultado do serviço.

Quando a topologia acompanha o prédio

Uma rede tidal tem ritmo previsível. Pessoas ocupam áreas diferentes ao longo do dia, e o volume migra com elas. Em períodos de baixa utilização, alguns componentes podem ser desativados para economizar energia. O routing precisa saber que a topologia mudará por decisão operacional, não por pane.

RFC 9657 inclui esse caso dentro de operating efficiency. O documento é Informational, organiza casos de uso e não define protocolo. As outras famílias são resource preservation e dynamic reachability.

Transformar o padrão em entrada de cálculo é útil. Transformar o padrão em prova de economia seria um salto indevido.

Um plano verde tem pelo menos três resultados

Primeiro existe a ação: portas ou elementos realmente foram desligados e ligados. Depois existe o efeito energético: consumo caiu em comparação com uma linha de base. Por fim existe a utilidade: a rota restante atendeu tráfego, latência, perda e disponibilidade.

Uma previsão de baixa demanda não responde a nenhuma dessas etapas sozinha. Pode haver evento inesperado, carga deslocada, equipamento que rejeitou a mudança ou caminho alternativo saturado. Um painel que conta “janela verde executada” a partir do calendário elimina justamente o feedback que deveria melhorar a política.

RFC 9845 descreve desafios e oportunidades de gestão para green networking. A combinação reforça uma regra: reduzir impacto sem destruir utilidade exige medir os dois lados.

Preservar o nó muda a rede

Resource preservation cobre equipamentos limitados por energia, temperatura ou armazenamento. Uma rádio pode desligar para preservar bateria, entrar em modo térmico seguro ou guardar energia para coleta. O caso supõe gasto conhecido, reposição previsível e função de custo consistente.

O exemplo de sensores alimentados por energia solar mostra conectividade diferente em t1, t2 e t3. A ausência prevista pode deixar de gerar um alarme de falha. O retorno previsto, porém, não prova forwarding. RFC 9657 lembra que descoberta e sincronização de vizinhança podem atrasar o tráfego depois do join.

O recibo deve seguir limiar, transição física, descoberta, adjacency, instalação de rota, primeiro pacote e resultado.

Custo variável torna esperar uma escolha

Operating efficiency trata custo como função do tempo. A tarifa, energia ou condição ambiental precisa ser mensurável, previsível, persistente e grande o bastante para justificar a reação. O nó pode filtrar um enlace caro, acumular dados para um burst ou esperar uma janela mais favorável.

O exemplo que envia de N1 para N2 em t1 e espera até t3 para alcançar N3 incorpora armazenamento ao caminho. RFC 4838 e RFC 9171 contextualizam redes tolerantes a atraso e Bundle Protocol.

Esperar exige identidade de fila, custódia, expiração, espaço, release e receipt no destino. A agenda não demonstra que o dado sobreviveu ao intervalo.

Movimento previsível não elimina o ambiente

Dynamic reachability utiliza movimento e ambiente suficientemente previsíveis para estimar expiração e retomada de adjacency, variação de taxa ou filtragem de um link que desaparecerá em breve. Satélites, ferries e aviões ajudam a visualizar o caso.

O RFC exclui cenários puramente não determinísticos, como veículo-a-veículo. Mesmo assim, uma constelação regular pode sofrer falha inesperada entre satélites. Tempo, ocultação, apontamento e distância alteram taxa e contato.

“Janela calculada” pertence ao forecast. “Terminal adquiriu” pertence à observação. “Pacote saiu” pertence ao data plane. “Aplicação recebeu” pertence ao destino.

A maré depende do relógio

RFC 3339 padroniza representação de data e hora. RFC 5905 define NTPv4; RFC 8633 trata práticas de segurança de tempo. Uma string válida não prova sincronismo nem autoridade.

RFC 9657 considera time synchronization crítica e alerta que mudança não autorizada de relógio pode interromper a rede ou causar DoS. Uma porta pode desligar enquanto o vizinho ainda acredita estar na janela anterior. A agenda continua igual; a realidade compartilhada desaparece.

Guarde fonte de tempo, offset, incerteza, estado de sync e passos de relógio com cada decisão.

Agenda expressa intenção, não valida demanda

RFC 9922 define tipos e grupos YANG comuns para schedules, validação e status, mas não presume a natureza da ação nem resolve conflitos. RFC 7758 oferece time capability em NETCONF.

Esses recursos descrevem quando. Não confirmam o forecast de tráfego que justificou desligar. Este artigo não repete a fronteira já publicada de RFC 9922 entre schedule e execução; trata da fronteira entre estado futuro previsto e estado real observado.

Um ledger que mede benefício e custo

Comece por objetivo, produtor do forecast, modelo, hipóteses, revisão e validade. Acrescente time authority, distribuição, política local e cálculo. Na execução, observe porta, rádio, adjacency, next hop e taxa. Para eficiência, registre energia antes/depois e linha de base; para utilidade, registre perda, latência, capacidade e resultado de aplicação.

Conserve também previsões que erraram. Elas mostram quando a maré deixou de ser regular.

As camadas de realidade de Heng Lu mantêm forecast, agenda, ação e efeito separados. A Especificação Inicial Mínima coordena o mínimo sem centralizar a decisão. A primazia do código em execução exige medição após a janela.

Fontes