要約

  • RFC 9657 はresource preservation、operating efficiency、dynamic reachabilityという三つの決定論的TVR use caseを示すが、具体的mechanismやsolutionは定義しない。
  • 近い将来に失効するlinkをfilterする判断は、link failureの観測ではない。scheduleはclock、接触、data rate、転送、配送を証明しない。
  • receiptはforecast sourceとrevision、time authority、local policy、route computation、observed adjacency、queue/forwarding、destination resultを分離して結ぶ。

今は使える、しかし選ばない

通常のroute selectionは現在のmetricを比較する。Time-Variant Routingは「この状態はいつまで続くか」を加える。現在upのadjacencyでも、すぐに消えると予測されれば、大きなtransferや長いflowには使わない方がよい。

RFC 9657 は、時間ベースまたは予定されたnetwork changeをrouting computationが考慮するuse caseを整理する。Informational RFCであり、wire protocolもschedule formatも定義しない。三分類はresource preservation、operating efficiency、dynamic reachabilityである。

文書が認めるのは予測の有用性である。予測が観測と同じauthorityを持つとは述べない。

Filteringは未来に対するpolicy

Dynamic reachabilityでは、mobile nodeの軌道とenvironmentが十分予測可能なら、adjacency expiration、resumption、data-rate changeを先に計算できる。route computationは、まもなく失効するlinkやrateが大きく下がるlinkをfilterできる。

ここでdashboardが「down」と表示すると証拠が壊れる。linkはその時点で実際にはupだったかもしれない。正確な表現は「forecast revision Xに基づき、expiryまでの余裕がpolicy thresholdを下回ったため非選択」である。

後から確認すべきものは、実際のadjacency end、実rate、選ばれたalternative path、flow outcomeである。予測より長くlinkが残った場合も、判断評価に必要な事実であって、削除すべきnoiseではない。

規則的な軌道にも突然の故障がある

LEO constellationはTVRの分かりやすい例である。spacecraftの軌道は比較的安定し、ground stationのview windowを計算できる。複数spacecraftが順番にground contactを持つなら、時刻ごとに異なるsubpathを準備できる。

RFCは同時に、inter-satellite link failureが不確実性を持ち込むと明記する。ferryやplaneも予測可能なrouteを持つが、weather、occultation、terminal pointing、actual rateは別である。非決定論的vehicle-to-vehicle scenarioはscope外だが、scope内が無誤差になるわけではない。

予定されたcontactはfuture graphのedgeである。observed neighborはcontrol-plane fact、packet transitはdata-plane fact、deliveryはdestination factである。

nodeを守るための計画停止

Resource preservationでは、power、thermal range、storageの制約からradioをoffにする。消費と再蓄積、resource-management functionが十分安定していれば、networkから抜ける時刻と戻る時刻を計画できる。

solar-powered sensorの例はt1、t2、t3で異なるconnectivityを示す。予定停止を故障として扱わないことは合理的である。しかしRFCは、nodeがjoinした後にもdiscoveryとneighborhood synchronizationがforwardingを遅らせ得ると述べる。

power-on scheduleはroute-ready scheduleではない。device state、discovery、adjacency、route installation、first packetをそれぞれ測る必要がある。

Costが時刻の関数になる

Operating efficiencyはcostを定数から時間関数へ変える。測定可能、予測可能、反応できるほど持続し、差が十分大きいことが前提である。高価なlinkをfilterし、burstのためにdataを貯め、安い時間まで待つことができる。

N1からN2へt1で送り、N2で保持し、t3でN3へ送る例は、待機がpathの一部になることを示す。RFC 4838 と RFC 9171 はdelay-tolerant/store-carry-forwardの背景を与える。

必要なのはqueue identity、custody、expiry、storage、release、actual cost、deliveryである。予測された低cost windowは、後半が起きた証拠ではない。

Clockはtopology controlである

RFC 3339 はdate/time表現、RFC 5905 はNTPv4、RFC 8633 はtime security practiceを示す。正しい文字列、同期状態、信頼できるsourceは別々のclaimである。

RFC 9657はtime synchronizationがcriticalで、unauthorized clock changeがnetworkを妨害しDoSになり得ると警告する。短いwindowでは、小さなoffsetが両端を別のtopologyに置く。

time source、offset、uncertainty、sync status、clock stepをdecisionと同じ記録に置くべきである。

Schedule modelとforecast modelを分ける

RFC 9922 は共通YANG schedule、validation、statusを定義するが、trigger actionを仮定せず、conflict resolutionをscope外にする。RFC 7758 はNETCONFのtime capabilityを提供する。

これらは時間意図の表現を助ける。軌道、価格、energy、需要という入力worldは検証しない。既存RFC 9922記事が所有するschedule-status/action境界を繰り返さず、本稿はforecast network stateとobserved network stateの境界を所有する。

予測から配送まで

目的、forecast producer、assumption、model build、issued time、validityを保存する。time authority、distribution、local acceptance、route computation、filter理由を追加する。実行時にdevice state、neighbor、adjacency、rate、next hopを観測する。

待機dataにはqueue、custody、expiry、releaseを付け、destination receiptで閉じる。failed forecastを保存し、accuracy metricへ返す。

Heng Luのreality layers はforecast、schedule、decision、outcomeを混ぜない。Minimum Initial Specification は共通の最小時間語彙とlocal authorityを両立させる。running-code primacy は最後に実際のtransitionとdeliveryを要求する。

RFC 9845 のgreen networking contextでも、予定停止がenergy benefitを生んだかは測定事項である。

出典