要約

  • RFC 892 の Transport Connection は、両端が別々に選ぶ16 bitの参照によって識別され、TPDUを運ぶ Network Connection とは別の状態だった。
  • 一つの Network Connection に複数の Transport Connectionを載せる multiplexing と、一つの Transport Connectionを複数の Network Connectionに載せる splitting が、逆向きの写像として定義された。
  • 分離の強さは class ごとに異なる。下位サービスの品質、共通化された機能、CR/CCで選ばれた class、再割当てと再同期の規則が連続性の限界を決めた。

RFC 892 は、Transport Connection を使う前に一つの Network Connectionへ割り当てるよう求めた。splittingを使う場合は複数でもよい。既存のNCを選ぶことも、新しいNCを作ることもできた。

ここで重要なのは、割当てが必要だから両者が同一なのではない、という点だ。列車には線路が要るが、どの運行状態かを線路番号だけでは判定できない。RFC 892では、運ぶものと運ばれる状態に別の識別と規則があった。

この文書は ARPA Internet の標準ではない。ISOの輸送プロトコル仕様を情報としてRFC化したものである。1984年の RFC 905 が新しいISO DP 8073本文としてRFC 892を置き換えたが、同じくARPA-Internet標準ではない。したがって本稿は「Internetが五つのOSI classを採用した」という歴史を書かない。

参照は相手に使わせるために選んだ

発信側は Connection Request TPDU、CR を送り、応答側は Connection Confirm TPDU、CC を返す。CRには発信側が選んだsource reference、CCには応答側が選んだreferenceが入る。それぞれの値は、相手が以後destination referenceとして使う。

参照は0にできず、使用中でも凍結中でもいけない。16 bitという狭い局所空間であり、世界的な名前でも認証情報でもない。受信側の状態表に該当するTCがあるときだけ、値は意味を持つ。

この選び方は対称だった。master/slaveを決めなくてもよく、同時発呼の衝突も一方的な番号配布者に依存しない。RFC 892は、この参照がNetwork Connectionから独立してTransport Connectionを識別すると説明した。

ただし、数字だけを別のNCに置けば継続するわけではない。到着したTPDUは、正しい相手のtransport entityを示すnetwork address、現在の割当て、protocol phaseと整合しなければならない。referenceは状態の索引であって、相手の法的身元や操作権限ではない。

CRは希望であり、CCが確定値だった

RFC 892には五つのclassがある。class 0は単純、class 1は基本的な誤り回復、class 2はmultiplexing、class 3は回復とmultiplexing、class 4は損失・重複・順序違いなどの検出と回復を担う。

initiatorはpreferred classと代替候補をCRで示す。class 0を希望するときだけ代替は出せない。送信直後は希望classが合意される前提で動き始めてよいが、その前提には期限がある。responderがCCでselected classを返したら、許容された別の結果へ機能を合わせなければならない。

最大TPDU sizeも独立の交渉だった。応答側は提案を受けてもよく、許容範囲内のより小さい値を返してもよい。optionsもproposedからselectedへ変わる。下位NCの成立、CRの受理、希望class、最終classは同じイベントではない。

選択は下位の品質に依存した。規格は、残留誤りと通知される障害の程度によってNetwork Serviceを分類した。ユーザーの要求と費用も判断材料である。到達できるNCでも、必要品質を満たせなかったり、既存のpervasive機能と新TCのclassが衝突したりすれば、割当て先として不適切だった。

multiplexingは独立性と共同運命を同時に作った

複数のTCを一つのNCで運ぶとき、各TPDUのdestination referenceが配送先のtransport stateを区別した。下位接続の確立費用を共有しても、上位の会話は一つにならない。

一方で、pervasiveとされた機能はNCを共有する全TCに及んだ。最初のTCがその機能を使うと、NCが生きている間は後から載るTCにも同じ選択が適用される。carrierはidentityではないが、共通の制約面にはなった。

逆方向がsplitting and recombiningである。一つのTCが複数のNCを使い、障害耐性やthroughputを上げる。機能表ではclass 4に限定されており、全classの一般特性ではない。この限定こそ、階層分離が能力表として実装されていた証拠である。

reassignmentもclassに依存した。NCがprovider側のdisconnectで失われると、回復classは別のNCへTCを割り当て、resynchronizationを行える。相手は新しいcarrierから届いた有効なTPDUとnetwork address、既存referenceを組み合わせて同じtransport entity間の状態だと認識する。

class 0では事情が違う。明示的なtransport releaseがなく、TCの寿命はNCの寿命と直接結び付いていた。RFC 892は、抽象的な「layer independence」を全classへ誇張しなかった。

下位サービスがTCPに替わっても、上の契約は残せた

RFC 983 は、外から見えるISO TSAP serviceを保ち、内部ではTCP/IPを使う案を示した。上位のsession、presentation、application entityは下位変更を知らずに動ける、とした一方、完全な移行計画はscope外と明記した。

RFC 1006 はその案をversion 3で置き換え、ISO transport class 0をTCP上で提供した。TCPは連続octet streamであり、TP0が期待する離散TPDU境界を持たない。そのためTPDUを長さ付きのTPKTに収めた。TPKTが示すのは境界であり、identity、authorization、integrityではない。

このmappingではTCP openが下位接続となり、TCP closeがdisconnectとなる。class 0なので下位と上位の寿命は近い。それでも、ISO transport serviceのinterfaceとTPDUは、1983年のNCとは別のcarrier上で維持された。

RFC 2126 はさらにIPv4またはIPv6上のTCPへclass 0とclass 2を載せ、RFC 1006のinstalled baseを守るためTPKT versionを維持した。TCP port 102は予約されたが、全connectionで必須ではないとも述べた。

現在の IANA Service Name and Port Number Registry にもiso-tsapと102が残る。これは番号の調整記録であり、実装の存在、class交渉、live reference、application resultの証明ではない。

出典と限界

本稿はRFC 892、RFC 905、RFC 983、RFC 1006、RFC 2126、IANA registryを用いた。ここから分かるのは仕様、文書の地位、TCPへのmappingである。現在の普及、QUICやSCTPへの直接系譜、全classのmultipath、相手認証、特定製品の動作、OSI移行の成功までは分からない。