要約

  • RFC 9801 は、失われた、または破棄された PLE パケットのペイロードを同量の代替データで埋めるよう受信側に求める。全実装が既定値 0xAA を生成できなければならない。
  • 0と1の交互パターンはクロック同期を保ち、64B/66B で不正な同期ヘッダーを避ける。欠けた情報を復元するものではない。
  • 運用証跡は、受信パケット、シーケンス欠落、並べ替え、代替区間、holdover、L/R、PLOS/DEG、PLE 統計、ネイティブ信号、利用者結果を分離する必要がある。

監視盤で「クロック同期」と表示されていても、内容の同期まで確認できたとは限らない。出力ポートが規定速度で動き、64B/66B の同期ヘッダーが壊れていなくても、その一部は遠端から届いたデータではなく、受信装置がその場で生成した 0xAA かもしれない。

これは RFC 9801 が意図した保護動作である。2025年7月に提案標準として公開された同文書は、TDM、Ethernet PHY、Fibre Channel、OTN などのビットストリームをパケット網越しにエミュレートする。パケット網の時間は揺れるが、同期インターフェースの時間は止まらない。その差を出口の IWF が引き受ける。

欠損を埋めることと、過去を復元すること

アーキテクチャの土台は RFC 3985 の pseudowire である。入口は顧客側の連続信号を固定長ペイロードに分け、制御ワード、RTP 時間情報、VPWS の識別子、PSN ヘッダーを付ける。出口はそれを外し、別の顧客側回線へ連続信号を再構成する。

両端は同じサービス種別、ペイロード種別、ペイロード長を使い、その長さを VPWS の存続中に変えない。1,024 バイトは全実装が対応する共通値である。RFC 4385 に沿う制御ワードのシーケンス番号はパケットごとに増える。番号の飛びは欠損を示すが、原因の所在までは示さない。

RTP ヘッダーは RFC 3550 の時間表現を利用する。ただし RTCP、SRTP、ヘッダー拡張などを提供するわけではない。200 Gbit/s 以下のタイムスタンプは 125 MHz、それより上は 250 MHz で進む。RFC 4197 の相対同期モデルにより、入力回線と共通基準の差を遠端へ渡し、出力クロックを回復する。

この情報は「いつ出すか」を再現する。欠けた位置に「何があったか」は再現しない。

de-jitter buffer は待つ権限を配分する

受信 IWF は de-jitter buffer を持つ。順序が入れ替わったパケットを戻す機能があれば救済できるが、なければ破棄しなければならない。つまり、正しい内容を持つ遅着パケットも、時間制約を超えれば出力に使えない。

起動時にはバッファの約50%まで貯めるのが典型的だと RFC 9801 は述べる。遅延が増える側にも減る側にも余地を残すためだ。大きいバッファは PDV に強い代わりに遅延を増やす。小さいバッファは速いが、遅着を損失へ変換しやすい。

欠けたペイロードについて、受信側は同量の代替データを出す。内容は設定可能だが、0xAA は必須である。交互ビットは同期を保ち、64B/66B の不正な同期ヘッダーを避ける。holdover はクロックをつなぐ。いずれも元データの推定ではない。

記録 限定された意味
受信パケットと番号 そのペイロードが到着した
番号の欠落 判断時点に期待位置がなかった
並べ替え・破棄 遅着をローカル方針で処理した
代替区間 ローカル生成バイトを出力した
回復クロック 宣言した観測範囲でテンポを保った
保守信号 ネイティブ層に限定的な障害を示した
顧客測定 特定アプリケーションが結果を観測した

出口の信号が連続し、途中のキャプチャに穴があることは矛盾しない。IWF が穴を埋めたからである。監査上の問題は、埋めた事実を消して出口だけを保存することだ。

L と R は異なる観測者の発言

L ビットは送信側の接続回線障害によりペイロードが無効だと PE が判断したことを示す。遠端は適切な代替データを出し、必要ならサービス固有の下流障害信号を注入する。R ビットは受信 IWF が PSN 損失を経験している、またはサーバー層の後方障害通知を受けたことを相手に知らせる。

L と R を一つの「回線障害」に丸めると、方向と観測面が失われる。どちらにも欠損ペイロードは含まれず、顧客装置の反応も含まれない。

連続損失が設定時間に達すると PLOS になる。既定は1ミリ秒である。損失率が設定閾値を連続する1秒窓で超えると DEG になる。文書の既定値は15%を7区間である。最初の欠落、閾値到達、状態宣言、保守信号の出力には別の時刻がある。

ES-PLE は少なくとも1パケットの損失、PLOS または DEG がある秒を数える。SES-PLE は15%超の損失、PLOS または DEG の秒を数える。UAS-PLE は連続する深刻な秒の後に開始し、連続する正常秒の後に終了する。既定は両方10秒だ。しかし接続回線の性能監視はサービスごとで、RFC 9801 の範囲外である。SES-PLE だけでは失われた Ethernet フレーム数や Fibre Channel 処理数を証明できない。

整った出力は、網の余裕を証明しない

RFC 4553、RFC 5086、RFC 4842 は同期サービスを pseudowire に載せる先行方式であり、時間・番号・代替の背景を示す。RFC 9801 はそれを広いサービスにまとめる。

PLE は一定速度の非弾力的トラフィックで、RFC 2914 が期待する TCP 的な混雑応答はできない。QoS、帯域予約を伴う traffic engineering、admission control、過剰設備などで低損失・低ジッタを用意する必要があるが、方法は範囲外だ。出口が滑らかでも、帯域が十分だったとは限らない。端末が不足を短時間吸収した可能性がある。

セキュリティも同様である。PLE 自体は暗号化、完全性、認証を追加せず、RFC 5920 に沿った隔離済みの信頼できる MPLS/SRv6 網を仮定する。注入、遅延、並べ替え、廃棄による deterministic network のリスクは RFC 9055 が整理する。PTP 時刻には RFC 7384 の遅延操作などの脅威がある。クロックが安定しても、内容や経路は認証されない。

RFC Editor の情報、正誤情報、IETF の履歴 は文書の状態を示す。IANA PWE3 レジストリ は割り当てを示す。RFC 8214 は EVPN-VPWS を扱うが、RFC 9801 の PLE シグナリング拡張は範囲外である。これらは配備結果ではない。

テキスト版 と XML 版 から規範文を検証できても、特定回線の代替区間は運用記録がなければ分からない。

継続は動作であり、忠実性は立証すべき結論である。欠損を美しく隠せる仕組みほど、代替した事実を明示的に残さなければならない。

出典