要約

  • RFC 5143 は SONET/SDH 回線を MPLS 上で模擬する Historic 文書であり、新規実装には標準化過程の RFC 4842 を使う必要がある。
  • 32ビットの CEM ヘッダーは DBA、遠端障害、シーケンス番号、構造ポインター、ポインター調整、ECC-6 を持つ。
  • ECC-6 はヘッダーの1ビット誤りを訂正し、2ビットまで検出するが、回線ペイロードは保護しない。
  • 正常または訂正済みのヘッダーも、失われたパケット、乱順、空のジッターバッファ、パケット同期を修復できない。
  • 損失の確定は再生時点で行われ、必要なデータが回線の期限までに届いたかがそこで初めて決まる。
  • シーケンス番号は欠損と乱順を検出する。並べ直さない実装は乱順パケットを捨て、設定済みの代替パターンを再生する。
  • パケット同期を失うと、パケット網側へ CEM-RDI、構造化回線側へ AIS-P が送られる。
  • DBA は送信周期を保ったままペイロードを意図的に省けるため、パケットの存在は利用者データの存在を示さない。
  • クロック回復は独立機能であり、ヘッダーの正しさから周波数、位相、ジッター、ワンダーは証明できない。
  • 旧ヘッダーは IPv4 のように見える場合があり、ペイロード型 ECMP がジッターや乱順を招く危険を持っていた。
  • セキュリティは下位のパケット網を上回らず、ネイティブ TDM より弱い可能性もある。ECC は認証でも来歴証明でもない。
  • 経営判断には、ヘッダー、順序、バッファ、時刻、保守信号、実回線出力を別々に示す証跡が必要である。

一定の送信周期が隠すもの

監視画面には、一定間隔で届くパケットが並ぶ。ラベルもヘッダーも解釈でき、シーケンス番号も進んでいる。ところが D ビットが示す DBA 状態では、SONET/SDH のペイロードが最初から入っていないことがある。AIS-P または Unequipped の状態を伝えるため、必要なヘッダーだけが通常と同等の周期で送られているからだ。

周期を保つ設計には理由がある。遠端のジッターバッファを突然枯らしたり満杯にしたりせず、パケット網の断絶と意図した回線コンディショニングを区別しやすくする。したがってこれは故障した挙動ではない。むしろ状態を正確に伝える挙動である。

誤りは観測側で起きる。一定周期をそのまま「トラフィック正常」と呼べば、保守状態がサービス成功へ置き換えられる。共有プロトコルが狭く正確であるほど、上位のダッシュボードは意味を足し過ぎてはいけない。

訂正符号が守る対象は明記されている

RFC 5143 の CEM ヘッダーは32ビットである。D は Dynamic Bandwidth Allocation、R は CEM Remote Defect Indication を示す。10ビットのシーケンス番号は0から1023まで循環し、構造ポインターは同期ペイロード包絡の位置を示す。N/P は通常時のポインター調整や警報表現に使われ、末尾の6ビットが ECC-6 である。

Appendix B は検査行列とシンドロームの扱いを定義する。受信側は単一ビットの誤りを訂正し、二重ビットまでの誤りを検出できる。ECC フィールド自身も同じ訂正・検出の対象になる。運用設定で無効にすることもでき、その場合はゼロが送られる。

ここに曖昧さはない。保護されるのは CEM ヘッダーである。SONET/SDH ペイロードは範囲外だ。届かなかったバイトを生成せず、遅着したパケットを期限内へ戻さず、クロックを正しくしない。訂正成功が証明するのは、狭い共有レコードを解釈可能に戻したことだけである。

薄い共有層としては、それで十分だ。両端が同じ最小情報を解釈できれば相互運用は成立する。バッファ方針、クロック回復、保守処理、顧客影響は、実装と運用者のローカルな判断として残るべきである。

順番を知ることと、内容を取り戻すこと

シーケンス番号は次に何が来るはずだったかを示す。欠番、重複、逆転を発見するには強力だが、発見した欠損を埋める力はない。RFC 5143 は、デパケタイザーに損失と乱順の検出を要求する。並べ替えは可能だが、行わない場合は乱順パケットを破棄しなければならない。欠けたペイロードには設定可能なバイトパターンが入る。

出力回線はそれでも刻み続ける。これは電気的・光学的な連続性を守るための仕組みであり、利用者データの正しさではない。ポートが up であること、クロックが出ていること、バイトが流れていることは、それぞれ事実だが、中身が有効だという結論にはならない。

パケット同期も単一パケットの属性ではない。起動時の受信側は同期外であり、連続した番号を持つ設定数のパケットを再生して初めて同期を取得する。同期中に連続して欠損または空パケットがしきい値を超えると、同期を失う。

特に重要なのは、損失の判断時刻である。到着を待っている途中では、パケットは紛失ではなく遅延かもしれない。回線へ当該バイトを出す瞬間になって初めて、使える形で届かなかったと確定する。ネットワークの到着記録とサービスの再生結果は、同じ時計で語れない。

ジッターバッファが結果を変える

パケット網は不規則に到着し、回線は規則的に消費する。その間にある CEM ジッターバッファが時刻の差を吸収する。深さは調整可能であり、平均到着量はバッファが表す期間にわたって固定再生量と釣り合う必要がある。

受信数が同じでも結果は同じにならない。浅いバッファは遅延変動に弱く、深いバッファは遅延を増す。バースト到着で overflow が起き、短い空白で underflow が起きる。ネットワーク装置が受信済みと数えたパケットも、再生期限の後なら回線には使えない。

したがって received という一つの数値では足りない。再生できた数、遅着、破棄、代替パターン、バッファ深さ、underflow、overflow、同期状態を残す必要がある。RFC 4842 が後に、欠損・破棄と、バッファ障害・同期損失を別の性能項目として扱うのは、この現実を反映している。

警報は失敗ではなく、正直な出力である

パケット同期を失ったとき、RFC 5143 はパケット網へ CEM-RDI を返す。構造化 CEM では回線側へ AIS-P を出す。AIS-P は有効なエンドユーザーデータが運ばれていないことを示す保守信号である。

監視設計が AIS-P を単なる「ポートはまだ動いている」と数えれば、もっとも重要な意味を捨てる。逆に AIS-P を即座に原因と呼ぶのも誤りだ。それは下流に伝えられた状態であり、原因は上流回線、パケット同期、欠損、設定など別の場所にあり得る。

必要なのは、信号の発生点と変換経路を保つことだ。どの端で SONET/SDH 状態を観測し、どこで DBA を決め、どこでパケット同期を失い、どの端が AIS-P を再生したか。警報はサービス連続の証明ではないが、因果を追うための重要な証跡である。

ヘッダーのパリティは時間を直せない

出力側は入力サービスのクロックを再生しなければならない。RFC 5143 は同期モードと非同期モードを持ち、両端は同じモードに設定される。構造化同期方式では N/P のポインター調整を利用でき、シーケンス番号は重複や乱順による調整の多重適用を防ぐ。

それでもクロック品質は別問題である。非同期方式では適応型回復を使えるが、アルゴリズムの詳細は実装側に残る。後継 RFC 4842 も適応型アルゴリズムを規定範囲外としつつ、出力が SONET/SDH のジッターおよびワンダー限界を満たすことを求める。

正しい番号列から誤った周波数が生まれることはある。平均レートが合っていても短時間の位相変動は大きくなり得る。クロックが lock していても、再生内容は AIS-P かもしれない。ゆえにタイミングは回線出力で測り、ヘッダーやパケット周期から推定して済ませてはいけない。

旧形式が IPv4 に見えたとき

Historic になった理由を単なる年代で片付けるべきではない。RFC 5143 の先頭制御ビットは、特定の D/R 組合せで IPv4 の先頭ニブルのように見えることがある。中継装置がパケット種別を推測し、見かけのペイロードを ECMP ハッシュへ入れると、同じ擬似回線のパケットが異なる経路へ分かれる。RFC 4928 が説明するように、結果はジッターと乱順になり得る。

このときヘッダーのビット列そのものは正しく届く場合がある。ECC も問題なしと判定できる。しかし周囲の転送判断が、回線復元に必要な順序と時刻を変えている。レコードの完全性は、運搬経路に対する支配権ではない。

新規実装には RFC 4842 を使うという文書の指示を守る必要がある。本稿の価値は RFC 5143 を復活させることではなく、レガシー相互接続で何を観測し、どこから移行すべきかを明確にすることにある。

六つの証跡を分けて保つ

第一はヘッダー完全性である。正常、訂正済み、検出のみ、訂正不能、ECC 無効を区別する。第二はパケット連続性で、欠番、重複、乱順、並べ替え結果を持つ。第三はバッファ結果で、再生可否、期限超過、underflow、overflow、同期を持つ。第四はタイミング結果で、周波数、位相、ジッター、ワンダーを測る。第五は保守状態で、AIS-P、CEM-RDI、Unequipped、DBA の発生点と伝播を記録する。第六がサービス出力であり、有効な利用者データと接続機器の結果を確認する。

どれも他の証跡の代用にはならない。だが分離すれば診断が速くなる。訂正数だけが増えるならリンク品質、番号は連続しているのに underflow ならペーシングまたは経路変動、パケットとバッファが正常でタイミングだけ悪いならクロック回復、規則的な DBA と AIS-P なら回線条件を疑える。

情報源

  1. RFC 5143 HTML
  2. RFC 5143 テキスト
  3. RFC Editor レコード
  4. IETF Datatracker
  5. 文書履歴
  6. RFC 5143 Errata 検索
  7. IANA Pseudowire パラメーター
  8. RFC 4842:Circuit Emulation over Packet
  9. RFC 4553:Structure-Agnostic TDM over Packet
  10. RFC 5086:Structure-Aware TDM Circuit Emulation
  11. RFC 4447:LDP による Pseudowire 設定と保守
  12. RFC 4385:Pseudowire Control Word
  13. RFC 4928:MPLS で ECMP 処理を避ける
  14. RFC 3985:Pseudowire Emulation アーキテクチャ
  15. RFC 4023:MPLS の IP/GRE カプセル化
  16. RFC 5085:Pseudowire 接続性検証
  17. RFC 6374:MPLS パケット損失・遅延測定
  18. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  19. On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile
  20. Running-Code Primacy