要約

  • RFC 1963の標準形式Header-Lastでは、送信側が圧縮後の大きさを見てから、そのSDTPパケットがシリアルフレームの開始・中間・終了・全体のどれかを示せた。
  • SDTPの分割ビットはB/Fであり、EはCSヘッダー拡張の存在を示す。SDTPにシーケンス番号はない。B/Eとシーケンス番号はRFC 1990のPPP Multilinkに属する。
  • Lengthは複合PPPフレーム内の各SDTPパケットを区切り、Portは交渉済みチャネルを選ぶ。しかし、欠落の不在、物理ポートの同一性、利用側サービスの回復は証明しない。

一般的なパケット図ではヘッダーが先頭にある。後続のバイトをどう読むかを最初に知らせるためだ。1996年8月にInformationalとして公開されたRFC 1963は、その習慣を意図的に崩した。PPP Serial Data Transport Protocolの標準パケットは、転送対象のシリアルデータを先に置き、Terminal Adaptationヘッダーを末尾に置く。さらにヘッダー内のオクテット順も反転する。受信側は前方のデータと後方の構造を両端から読むことになる。

理由は送信処理の時間関係にあった。この方式の背景には、DSU/CSUにおける同期データ圧縮の作業がある。圧縮された一つのシリアルフレームを複数のSDTPパケットに分ける場合、圧縮出力が十分に生成されるまで、送信側は現在のパケットが最後になるかを知らないことがある。ヘッダーを先に置けば、その判断を早すぎる時点で確定しなければならない。末尾なら、出力サイズを観測し、断片の種類を決め、その記述を圧縮器へ続けて渡せる。

Header-Lastは奇抜さのためではなく、決定が可能になる時点を線上形式へ移した設計だった。フレームを複数パケットに分けない場合、圧縮とSDTPが結び付いていない場合、あるいはハードウェアが通常順を好む場合にはHeader-Firstも交渉できた。選択された形式は共通の読み方を定めるだけで、圧縮率、圧縮器の同期、再構成成功を報告するものではない。

データ送信にも入口条件があった。PPPはNetwork-Layer Protocolフェーズに達し、SDCPはOpenedでなければならない。IANA登録ではPPP-SDTPが0x0049、PPP-SDCPが0x8049である。この状態と番号は両端が同じ文法を採用した証拠になる。しかし、その後のパケットが完全、真正、利用可能であることの証拠にはならない。

標準では、一つのPPP Informationフィールドに一つのSDTPパケットが入る。Lengthが現れるのは、SDTPのLength-Field-PresentとRFC 1570のLCP Compound-Framesがともに交渉された場合だけである。このとき複数のSDTPパケットを同じPPPコンテナに収められる。Lengthは自分自身、任意のPort、適応ヘッダー、データ、必要なOdd-Padを含む。一オクテットなら合計2から255、二オクテットなら65535までを表し、ゼロはPPP Informationフィールドの残り全体を意味する。

Lengthが証明するのは、パーサーが次の単位をどこから読めるかである。元のシリアルフレームが完成したかではない。複合フレーム内の隣接パケットは、別の断片、別のフレーム、別のポートに属し得る。コンテナを正確に分割できても、途中の断片が届かなかった事実は埋められない。

Multi-Portは、さらに交渉済みの名前空間を加えた。未交渉ならすべてが暗黙のPort 0に属し、Portオクテットはない。交渉後は各パケットが番号を持ち、0から254がデータ、255が制御用となる。設定の一部はポート単位だが、Port 255のフロー制御は全ポートへ影響し得る。

番号は多重分離に役立つが、身元証明ではない。RFC 1963はPort 7を特定のケーブル、装置、顧客、業務へ暗号学的に結び付けていない。意味は両端のローカルな対応表から生まれる。その対応が物理的現実と一致し続けているかは、パケット外の証拠で確認する必要がある。

シリアルフレームの境界を表すのはBとFである。同期HDLC系モードではBが開始、Fが最終部分を示す。どちらもゼロなら中間、両方が一なら一つのパケット内に完全なフレームがある。非同期モードでは両方を一にする。Eは別の役割を持ち、任意のCS拡張ヘッダーが続くことを示す。Eは終了ビットではない。

ここを混同すると別のプロトコルを持ち込むことになる。RFC 1990 PPP Multilinkは、複数のメンバーリンクからなるバンドルでB/Eと12ビットまたは24ビットのシーケンス番号を使った。RFC 1963のSDTPにはシーケンスフィールドがない。したがって、Multilinkの番号進行から欠落を推定する規則も持たない。

RFC本文にも慎重に読むべき箇所がある。B/F表はBegin FrameとFinal Frameの両方に1,0を印刷しているが、直前の文はFを最終部分の印として明確に定義する。周辺の定義もB/Fの意味を支える。だからといって、個別実装の動作を断定はできない。実際の扱いを知るにはコード、テスト、パケットトレースが必要であり、今回の資料には含まれていない。

再構成の限界は内側のFCSでさらに明白になる。HDLC系フレームでは、SDTPはFlag間のバイトを運び、Flag自体は運ばない。標準では内側FCSも転送する。FCS-Typeを交渉すると送信側でFCSを除去し、受信側で再生成できる。しかしRFC 1963は、PPP Reliable Transmissionまたは別の層がドロップを確実に通知しない限り、再生成を使うべきでないと警告した。不完全または不良なフレームに新しい正しいFCSを付けて利用者へ渡すことも禁じた。

この警告が、形式と完全性の違いを示す。B/Fは見かけ上の始点と終点、Lengthはパケットの範囲、Portは交渉済みの送り先を示す。いずれも損失通知ではない。中間パケットが失われても下位層が知らせなければ、受信側は整った形の材料を得ることがある。そこでFCSを作り直せば、欠落が有効性の外観に変わってしまう。

RFC 1663はNumbered-Mode、ウィンドウ、確認応答、再送を別途交渉した。RFC 1962は圧縮アルゴリズムとReset交換を扱った。それらの機能をSDTPのフィールドへ暗黙に足してはならない。Header-Lastは圧縮後の分割判断を可能にしたが、圧縮方式でも信頼性方式でもない。

Lu Hengが区別する宣言済み構造と実行可能な証拠という観点では、RFC 1963は小さな共通文法を公開した。位置、拡張、境界、長さ、ポート名である。稼働システムは、到着順、損失処理、バッファ方針、ローカルなポート対応、FCS処理、利用側への引き渡しをそれぞれ示さなければならない。仕様は問いを精密にしたが、機械に代わって答えを出したわけではない。

出典