要約

  • LLCカプセル化では各AAL5 PDUの先頭にLLC/SNAP識別子を置くため、一つのATM VCを複数プロトコルで共有できた。VC多重化では種類をPDUに一般表示せず、一つのVCを一つのプロトコルに対応させた。
  • VC多重化はPDUごとのオーバーヘッドを減らす一方、PVCの設定またはSVCの呼設定を解釈契約の一部にした。AAL5の再構成成功は、正しい対応表、上位層の受理、アプリケーション完了を証明しない。

最初の利用者PDUより前に決まること

ATMのスイッチド仮想回線では、利用者のPDUが到着する前にSETUPとCONNECTが交わされる。端点、AAL、トラフィック条件、下位層の互換性が選ばれ、合意できなければ呼は成立しない。データ面だけを眺めると見えないが、後で届くバイトの読み方は、すでにこの時点で拘束されうる。

1993年7月の RFC 1483 は、AAL5 CPCS-PDUでルーティングPDUとブリッジPDUを運ぶ二方式を定めた。LLCカプセル化はIEEE 802.2 LLCヘッダーを付け、必要に応じてSNAPを続ける。非ISOのルーティングPDUなら、AA-AA-03、OUI、PID/EtherTypeが種類を示す。IPの例はOUIゼロと0x0800である。

この方式では、PDUが自分の振り分け材料を持ってくる。複数のプロトコルが同じVCを共有しても、受信側は各PDUの先頭を読んで次の処理を選べる。

VC多重化は反対である。一般的な種類表示をAAL5ペイロードに置かず、VCそのものがプロトコルを暗黙に示す。一つのVCは一種類だけを運び、複数種類には別々のVCが必要になる。RFC 1483の情報記録が示す二方式の差は、単なるヘッダー形式ではなく、意味を証言する場所の差だった。

省かれた識別子は制御面に残った

LLC/SNAPには毎回の帯域と処理の費用がある。VC多重化ならその費用を減らし、短いパケットが余分なATMセルにまたがるのを避けられる場合もある。しかし、受信側が種類を知る必要はなくならない。

PVCなら、そのVCがLLCかVC多重化か、後者なら何を運ぶかを両端に管理設定する。SVCなら呼設定信号で選ぶ。データ内の明示的なフィールドは、VC識別子と外部状態表との関係へ移された。

ブリッジPDUでは、この関係がさらに分かりやすい。LLC/SNAPのOUIとPIDは元の媒体種別やFCS保持の有無まで示す。AAL5の長さとCRCが正しくても、出力側ブリッジが内側のフレームをどう扱うかは別の情報である。外側の完全性は内側の意味を代行しない。

障害単位も異なる。壊れたLLC/SNAP値は一つのPDUを誤らせるかもしれない。間違ったVC対応表は、正しく再構成された多数のPDUを一貫して誤ったパーサーへ送れる。規格は形式を規定するが、特定現場の両端表が一致した事実までは作らない。

B-LLIは合意を記録したが、配送を証明しなかった

RFC 1755 は、Classical IP over ATMのSVCでB-LLIを使ってカプセル化を提示・選択する手順を具体化した。発呼側はVC多重化を優先しつつLLC/SNAPも提示でき、着呼側は対応可能な方式を選ぶ。共通方式がなく、または必須情報が欠けていれば呼をクリアする。RFC 1755情報ページは、この文書を実装間相互運用のための信号処理ガイドとして位置づける。

これは重要な事前証拠である。だが、CONNECTは後続データの受領証ではない。呼設定が成功しても、PDUの到着、AAL5 CRC、VC対応表の維持、IPの受理、アプリケーション処理はそれぞれ別に確認しなければならない。

既定値は未知を埋める規則であって、観測ではない

RFC 2225 は、他の知識や合意がない場合のClassical IP/ATMARPの既定をLLC/SNAPにした。独立実装の出発点を揃えるためであり、RFC 2225情報ページが記す安定した基線の一部だった。

同文書では、VCに結びつくAAL種別もセルヘッダーには入らず、PVCでは管理設定、SVCでは呼設定で端点に知らされる。ATMは初めから、データ中にある事実と接続関係にある事実を組み合わせていた。

またAAL5は非保証サービスである。VC内のセル順序と誤り検出があっても、再送は上位層の仕事だ。正しいCRCは一つの外被についての証拠であり、エンドツーエンドの成功宣言ではない。

PPPの認証も同じVCの全フローを覆わない

RFC 2364 はPPP over AAL5にも両方式を用いた。VC多重化PPPの種類は両端の設定または制御面手順で暗黙に合意され、LLC方式では各PDUの中で明示される。RFC 2364情報ページが示すように、PPPならリンク制御、認証、圧縮を利用できる。

それでも証拠は融合しない。RFC 2364は、あるPPPセッションの認証が同じVC上の他のLLCフローを保護するとは限らないと警告した。外側のVCを共有しても、内側の主体と権限は共有されない。

RFC 2684は二方式を残し、十分条件ではないとした

1999年の RFC 2684 はRFC 1483を置き換え、実装で見つかった曖昧さを整理した。LLCは多プロトコル環境のVC数を減らしやすく、VC多重化はPDUごとの負担を減らしやすい。PVCでは設定、SVCでは信号で選ぶという構造は残った。RFC 2684情報ページは置換関係を記録するが、旧実装が一斉に消えたとは言わない。

さらに同文書は、多プロトコルカプセル化がATM上のルーティングとブリッジに必要でも、通常は十分でないと明記した。識別と運搬の形式は、アドレス解決、論理サブネット、経路、認可、配送結果を代替しない。

情報源