要約

  • RFC 9633のietf-detnetはNMDAに従い、アプリケーションフロー、トラフィックプロファイル、サービス／転送サブレイヤーと一部の運用状態を表す。
  • max-latencyは要件、app-flow-status=readyは限定された装置報告である。どちらにも、期限を検証するパケット、観測区間、時計は入っていない。
  • 信頼できる受領証は、意図した設定、各ノードへの適用、設定世代、カウンターの時点、正確なフロー選択、独立測定、アプリ側の受領を結び付ける。

管理画面では、必要な枝がすべて存在し、入口の状態はreadyだった。ところがアプリケーションは、その前のパケットを期限切れとして捨てていた。

二つの記録は矛盾しない。管理面の準備と、時間内の配達を同じ出来事だと見なした側が間違っていた。

RFC 9633はDetNet用YANGモジュールを定義する。アプリケーションフローをトラフィックプロファイルに結び、サービスサブレイヤーと転送サブレイヤーをたどり、設定と運用データを区別できる。複数装置で構成されるサービスに共通の語彙を与える点で重要である。

ただし、語彙が精密になっても、記録対象は変わらない。ツリーは管理状態を表す。期限はパケットと時計の間に現れる。

プロファイルは判定条件であって判定結果ではない

traffic-profileには、最小帯域、最大遅延、最大遅延変動、最大損失、連続損失許容数、最大順序逆転を置ける。単位が付いているため、実測値のように見えやすい。しかし、これらはサービスが満たすべき条件である。

traffic-specは送信元からネットワークへの約束または要求として、周期、周期当たりのパケット数、ペイロードサイズを記述する。ネットワークはこれを資源割当てやキュー調整に使う。設定された約束は、送信元が実際に守った証拠でも、ネットワークが結果を返した証拠でもない。

最大遅延の葉は比較すべき境界を示すが、入口と出口の時刻を持たない。最大損失の葉は、送受信した母集団を持たない。連続損失と順序逆転にはシーケンスの意味が必要で、総パケット数だけでは復元できない。

要件を「実績」欄へ転記すれば、仕様が自分自身の達成を証明する循環になる。

readyを全体判定へ拡張しない

RFCはnone、ready、failed、out-of-service、partial-failedを定義する。アプリケーションフローの状態はconfig falseで、設定が不完全ならnoneとなる。設定が存在するだけで準備完了と推測するより、はるかに良い。

それでもreadyは、ある装置がある入口または出口について報告する状態である。観測時間、パケット集合、遠隔時計、受信アプリの応答は含まれない。partial-failedでは、一部出口が準備済みで他が失敗していても、入口がreadyなら利用可能な場合がある。この複雑さを緑色一つへ圧縮してはならない。

状態には、装置、フロー、方向、サブレイヤー参照、datastore、読取時刻、設定世代を添える必要がある。同じ文字列でも、対象と時点が違えば別の証言である。

一つのモデルでも、適用時刻は一つではない

RFC 9633は信号プロトコルに依存せず、経路上の装置にエンドツーエンドDetNetサービスを設定できる。これは管理方法の自由であり、全ノードの原子的コミットではない。

新しいプロファイルを受け入れたノード、古い転送参照を残したノード、操作を拒否したノードが同時に存在し得る。収集中にロールアウトが進めば、個々には正しい値を組み合わせて、実際には一度も存在しなかった全体像を作ることもできる。

セキュリティ節は、経路上の全装置で調整されない変更がサービス拒否を起こし得ると警告する。したがって、管理受領証は各装置の応答と時刻を持ち、同じサービス識別子と設定世代で結合されなければならない。

NMDAは意図と運用状態を整理するが、分散した履歴を自動的に一枚の写真へしない。トランザクションID、モジュール版、ノード集合、サブレイヤー参照、全体を有効とみなした規則が要る。

安全な読取りは測定の代わりではない

NETCONF/SSH、RESTCONF/HTTPS、NACMは管理面へのアクセスを保護する。誰が何を読書きできるかを制限し、フローを壊したり検査を迂回させたりする不正変更を減らす。

認証された応答は発言者を特定する。実装が正しいこと、値が新しいこと、装置が対象パケットの経路にいたことまでは保証しない。権限のある担当者も、誤ったprofileを正しく書き込める。

「誰が状態を出したか」と「どのパケットがどう届いたか」は、別の証拠で答えるべき問いである。

カウンターには起点、片方向遅延には時計関係が要る

RFCの例は、DetNet状態とインターフェース統計のdiscontinuity-timeを並べる。リセット後のカウンターは、事故全体を覆わない。異なる起点のカウンターを差し引けば、存在しない損失や成功を作れる。

片方向遅延には、関係が分かる二つの時計と、サービス境界を挟む観測点が必要である。損失には共通のパケット母集団、順序には識別子が必要だ。複製フローでは、コピー、重複除去、遅着の扱いも決める。

測定方式は能動、受動、混合のいずれでもよいが、それは別のOAM設計である。YANGのフロー選択と、方向、インターフェース、DSCP、ラベル、メンバー経路まで一致しなければ、測っているサービスが違う。

五つの記録を接続する

第一はサービス定義で、フロー識別、マッチ条件、profile、要件、サブレイヤー、版を保存する。第二は管理操作で、権限者、対象ノード、応答、適用時刻を保存する。

第三は各ノードの運用状態で、partial-failedを消さない。第四はパケット測定で、観測点、方向、時計、期間、母集団、サンプリング、リセット処理を明記する。第五はアプリケーションまたはサービス責任者の判断で、受入れ、拒否、例外、ロールバックを記録する。

Heng Luの現実層という考え方は、ここでは抽象論ではない。調整記録、設置状態、実行結果を結びつけても同一視しない、という運用規律になる。共通モデルは責任を明確にするために使い、観測していない結果の権威にしてはならない。

情報源