TCP上のISOトランスポートサービス このメモのステータス このメモは、インターネット社会のための標準を指定する。TCP上にISOトランスポートサービスを 実装することを選ぶインターネット上のホストは、この標準を採用し実装すると予想される。 TCPポート102は、この標準を実装するホストのために予約してある。このメモの分配は無制限である。 このメモは、プロトコルのバージョン3を指定し、[RFC983]に取って代わる。 RFC983に記述されるプロトコルとこのメモの間の変更は小さいが、残念ながら非互換性である。 1. 序文と哲学 インターネット社会は、エンドユーザにネットワークとトランスポートのサービスを提供するのに非常に 成功した、トランスポートとネットワーク間のプロトコルのよく開発され成熟したセット(TCP/IP)を持つ。 CCITTとISOは、国際社会と多数のベンダによって採用された、様々なセッション、 プレゼンテーション、アプリケーションの勧告を定義した。 最大の可能な程度まで、既存の機能をこわさずに、 ARPAインターネットにおいて直接より高いレベルを提供することが望ましい。 これは、ユーザが以前にARPAインターネットにおいて利用可能でなかったISOとCCITTの アプリケーションを備えた専門技術を開発することを可能にする。 中期また長期的には、それはTCP/IPに基づいたネットワークからISOに基づいたネットワークへの もっとゆっくりした収束と推移戦略をも許す。 ISOやCCITTのアプリケーションをTCP/IP環境へ「移す」時に、得られる基礎的なアプローチは2つある。 1つのアプローチは、TCP上にローカルのプロトコルを開発し、個々のアプリケーションをそれぞれ 別々に移すことである。これは短期では有用だが(TCPへの特別の目的のインタフェースを速く 開発できるので)、汎用性を欠く。 別のアプローチは、ARPAインターネットプロトコル組とISOプロトコル組の両方が、両方とも、 階層状システムであるという観察に基づく(前者はより実用的な観点から層を使うが)。 層状化原理の重要な点は、層の独立である。このセクションはほとんどの読者にとって余分だが、 ほんの少しの背景資料はこの概念を導入するのに必要である。 外部的には、層は2つの定義によって定義される: サービスに提供された定義、層によって提供されるサービスと、 それらのサービスにアクセスするために層が提供するインタフェースを記述;　そして、 サービスに要求された定義、層によって利用されるサービスと、 それらのサービスにアクセスするために層が使用するインタフェースを記述。 集団的には、サービスを提供するために協力するネットワーク中の実体はすべて、サービスプロバイダ として知られる。個々には、これらの実体の各々はサービスピアとして知られる。 内部的には、層は1つの定義によって定義される: プロトコル定義、他のサービスピアと通信する場合、各サービスピアが使用する規則を記述。 これをすべて組み立て、サービスプロバイダは、上層に対するサービスを提供するために 下層からのプロトコルとサービスを使う。 プロトコル検証は、例えば、これが実際起こると証明することを扱う (そしてコンピュータサイエンスにおける多くの博士論文のための肥沃なフィールドでもある)。 層独立の概念は、とても簡単には次のとおり: もしサービスプロバイダによって提供されたサービスを予約したら、 サービスユーザは、サービスピアが使うプロトコルに関して完全に知らなくてよい。 このメモの目的のため、我々は、ISO/CCITTのトランスポートサービスアクセス点(TSAPI)によって提供される サービス及びインタフェースと同一に見えるようなTSAPIを定義するために層独立を使う ([ISO8072]で定義されるように)が、実際は、ISO/CCITTのネットワークプロトコルの上ではなく、 TCP/IP上にISO TP0プロトコルを実装する([RFC793、RFC791]で定義されるように)。 トランスポートクラス0プロトコルがTCP/IP接続上で使われるので、トランスポートクラス4と同一の機能を達成する。 従って、ISO/CCITTのより高いレベル層(すべてのセッション、プレゼンテーション、アプリケーションの実体)は、 TCP/IPネットワーク間上でそれらが走っているという事実を知らずに完全に動作できる。 2. 動機づけ TCP/IP使用からISOプロトコルへ移動する際に、試みるかもしれないいくつかの戦略がある。 このメモは心の中では1つの特別の戦略で書かれた。 このメモが使う特別の移住戦略は、トランスポート層で、TCP/IPとISOプロトコル組の間に ゲートウェイを設けるという考えに基づく。このアプローチに対する2つの強い議論がある: 1. 低レベルプロトコルのよい実装を得るには、高レベルプロトコルの実装を得るためにかかるのと ちょうど同じくらい長くかかると経験は我々に教える。 特に、ISOのネットワークとトランスポート層で行われている多くの仕事がまだあると見られてきた。 その結果、これらの層の上のプロトコルの実装は積極的に追求されていない。 従って、高レベルプロトコルを開発できる媒体を提供するために「今」何かがなされなければならない。 TCP/IPは成熟していて本質的に同じ機能を提供するので、この開発をサポートする理想的媒体である。 2. IPとISO IP層のゲートウェイの実装は、恐らく長期的には一般に使われない。 事実、これは、TP4とTCPの両方をサポートすることを各インターネットホストに要求する。 そのため、よりよい戦略は、ISOプロトコルが十分に成熟した場合、 ARPAインターネットのためのTCP/IPからISOプロトコルへのゆっくりした移住パスを実装することだ。 これらの議論は両方とも、トランスポート層サービスアクセス点で、 またはアクセス点より上でゲートウェイが生じるべきであることを示す。 さらに、第1の議論は、開発できるISO層の数を最大限にするために、最良のアプローチは、 まさにそのトランスポートサービスアクセス点でゲートウェイを実行することであると示唆する。 注:このメモは、移住の役割をしたり、文書を妨害したりするつもりではない。 このメモは、上で議論されたニーズを満たすことをのみ意図している。 しかしながら、このメモに記述されたプロトコルが推移計画全体の一部を形成 するかもしれないことは予期しないわけではない。 そのような計画の記述はしかし、完全にこのメモの範囲外である。 最後に、一般に、TCP/IPとISOプロトコル組における他の層の間のゲートウェイ構築は、 うまくいったとしても疑わしい。 要約:このメモに記述された標準の主要な動機は、より高レベルのISOプロトコル (セッション、プレゼンテーション、アプリケーション)の経験を増やすプロセスを促進することである。 TCP/IPの安定性と成熟は、実際の実装と独立した確実なトランスポートサービスの提供にとって理想的である。 3. モデル [ISO8072]標準は、今後TPと呼ばれるISOトランスポートサービス定義を記述する。 本論を離れて:このメモは、CCITT勧告よりむしろISO仕様書を参照する。 これらの並列の標準間の違いは全く小さく、このメモに関しては、一般性を失わず無視できる。 読者にその関連を提供するため： トランスポートサービス[ISO8072][X.214]、 トランスポートプロトコル[ISO8073][X.224]、 セッションプロトコル[ISO8327][X.225] ISOトランスポートサービス定義は、TS供給者によって提示されたサービス(トランスポートサービス)と、 それらのサービスにアクセスするのに使われるインタフェースを記述する。 このメモは、ARPA送信制御プロトコル(TCP)[RFC793]がどのように サービスを提供しインタフェースを準備するのに使われうるか、に注目する。 図 解説のため、次の略語が使われる: TSピア　　　このメモによって記述されるプロトコルを実装するプロセス TSユーザ　　TSピアのサービスを使って話すプロセス TS供給者　　このメモによって記述されるプロトコルを実装するブラックボックス実体 TSAPプロトコルのバージョン2を記述するこのメモのために、 1つの例外を除いて[ISO8072]のすべての面がサポートされる: サービスパラメータの品質。 CCITTの精神では、これが「さらなる研究」に残される。 プロトコルの将来のバージョンは、様々なTCPパラメータ上にこれらをマッピングすることにより、 TPのためのQOSパラメータを恐らくサポートするだろう。 ISO標準は、(TSAPI IDと名付けられる)セッションポートのフォーマットを指定しない。 このメモは、このフィールドの解釈のために、GOSIP仕様[GOSIP86]の使用を命じる。 (「上位層アドレッシング」と題するセクション5.2を参照) 最後に、ISO TSAPは、振る舞いにおいて基本的に対称である。 基礎となるクライアント/サーバーモデルはない。 よく知られたポート上で聞くサーバの代わりに、接続が確立される場合、TS供給者は、 TSユーザが捕らえ、その上で動作しそうなINDICATIONイベントを生成する。 INDICATIONイベントを立てっ放しにしてサーバを「聞かせる」ことにより 実装されるかもしれないが、ISOのTSAPの見地から、 REQUESTを生成するかINDICATIONを受け取るまで、TSユーザはすべてただIDLE状態のままである。 4. 要素 プロトコルは、TCP[RFC793]が次のサービス要素を提供することを仮定する: イベント connected - オープン成功(ACTIVEとPASSIVEのいずれか) connect fails - ACTIVEオープン失敗 data ready - データは接続から読める errored - 接続はエラーしていて、今閉じられる closed - 秩序立った切断が開始した アクション listen on port - 与えられたポートでPASSIVEで開く open port - 与えられたポートでACTIVEで開く read data - データは接続から読まれる send data - データは接続で送られる close - 接続は閉じた(保留データが送られる) このメモは、[ISO8073]で要求される次のサービス要素をエミュレートするために、 これらのサービスを使う方法を記述する: イベント N-CONNECT.INDICATION - NSユーザ(応答者)は、接続確立が進行中と通知される N-CONNECT.CONFIRMATION - NSユーザ(応答者)は、接続確立されたと通知される N-DATA.INDICATION - NSユーザは、接続からデータを読めると通知される N-DISCONNECT.INDICATION - NSユーザは、接続が閉まっていると通知される アクション N-CONNECT.REQUEST - NSユーザ(開始者)は、それが接続を確立したいと示す N-CONNECT.RESPONSE - NSユーザ(応答者)は、それが要求を引き受けるだろうと示す N-DATA.REQUEST - NSユーザは、データを送る N-DISCONNECT.REQUEST - NSユーザは、接続が閉まるだろうと示す プロトコルは、TSユーザに、[ISO8072]で定義されるような、次のサービス要素を提供する: イベント T-CONNECT.INDICATION - TSユーザ(応答者)は、接続確立が進行中と通知される T-CONNECT.CONFIRMATION - TSユーザ(開始者)は、接続が確立されたと通知される T-DATA.INDICATION - TSユーザは、接続からデータを読めると通知される T-EXPEDITED DATA.INDICATION - TSユーザは、接続から「緊急」データを読めると通知される T-DISCONNECT.INDICATION - TSユーザは、接続が閉まっていると通知される アクション T-CONNECT.REQUEST - TSユーザ(開始者)は、それが接続を確立したいと示す T-CONNECT.RESPONSE - TSユーザ(応答者)は、それが要求を引き受けるだろうと示す T-DATA.REQUEST - TSユーザは、データを送る T-EXPEDITED DATA.REQUEST - TSユーザは「緊急」データを送る T-DISCONNECT.REQUEST - TSユーザは、接続が閉まるだろうと示す 5. プロトコル このメモによって指定されるプロトコルは、次の例外を除いて、ISOトランスポートクラス0用のプロトコルと同一である: - テストのため、初期データは接続設立中に変化するかもしれない。 - テストのため、緊急データサービスがサポートされる。 - 性能のため、はるかに大きなTSDUサイズがサポートされる。 - プロトコルによって使われるネットワークサービスは、TCPによって提供される。 ISOトランスポートプロトコルは、トランスポートプロトコルデータユニット(TPDU)と呼ばれる、 情報の不連続なユニットでピア間情報を交換する。 このメモに定義されたプロトコルは、TPKTと呼ばれる不連続なユニットでこれらのTPDUをカプセルに入れる。 これらのTPKTの構造と、それらとTPDUとの関係は次のセクションで議論される。 要素 TCPサービス要素とトランスポートクラス0によって期待されるサービス要素との間のマッピングは全く簡単である: ネットワークサービス TCP 接続確立 N-CONNECT.REQUEST オープン完了 N-CONNECT.INDICATION 聞く(PASSIVEオープン)終了 N-CONNECT.RESPONSE 聞く完了 N-CONNECT.CONFIRMATION オープン(ACTIVEオープン)終了 データ転送 N-DATA.REQUEST データ送信 N-DATA.INDICATION データ読出しが後に続くデータレディ 接続解除 N-DISCONNECT.REQUEST 閉じる N-DISCONNECT.INDICATION 接続終了またはエラー パラメータのマッピングも簡単である: ネットワークサービス TCP 接続確立 呼ばれるアドレス サーバのIPアドレス(4オクテット) 呼ぶアドレス クライアントのIPアドレス(4オクテット) それ以外すべて 無視 データ転送 NSユーザデータ(NSDU) データ 接続解除 全パラメータ 無視 接続確立 接続確立中に使われる手続きの要素は、3つの例外を除き、[ISO8073]で示されるものと同一である。 試験、接続要求、接続確認を促進するために、TPDUはこれらのTPDUのユーザデータフィールドを使い、 ユーザ初期データを交換するかもしれない。 緊急データサービス、接続要求、接続確認で実験するために、 [ISO8073]で指定される交渉メカニズムを使って、 TPDUが緊急データ転送の使用を交渉するかもしれない。 (例えば、「付加的なオプション選択」変数部分の中の 「トランスポート緊急データ転送サービスの使用」ビットをセットして)。 デフォルトは、トランスポート緊急データ転送サービスを使わない。 よい性能を達成するために、デフォルトTPDUサイズは128オクテットの代わりに、65531オクテットである。 より小さな(標準)TPDUサイズを交渉するために、[ISO8073]で指定された交渉メカニズムが使われる (例えば、「TPDUサイズ」変数部分の中の希望のビットをセットして)。 N-CONNECT.REQUEST動作を実行するために、TSピアは、 TCPポート102を使う希望のIPアドレスへACTIVEオープンを実行する。 TCPが成功か失敗のいずれかを示す場合、N-CONNECT.INDICATION動作に帰着する。 N-CONNECT.INDICATIONイベントを待つために、サーバはTCPポート102上で聞く。 クライアントがこのポートへ成功裡に接続する場合、 イベントが生じ、暗黙のN-CONNECT.RESPONSE動作が実行される。 注:ほとんどの実装では、一人のサーバが永久にポート102上で聞き、作られた時に接続を離れる。 データ転送 データ転送中に使われる手続きの要素は、1つの例外を除き、[ISO8073]で示されるものと同一である： 修正されたED TPDU(下に記述)を送ることによって、 (もし接続確立中にそのように交渉されれば)緊急データがサポートされるかもしれない。 TPDUは、他のTPDUのすべてと同じようなTCP接続で送られる。 この方法は、[ISO8072]の精神に忠実でないが、仕様の文字には忠実である。 N-DATA.REQUEST動作を実行するために、TSピアは希望のTPKTを構築し、TCPデータ送信要素を使う。 N-DATA.INDICATION動作を引き起こすために、TCPは、データが準備できていて、 TCPデータ読出し要素を使ってTPKTが読まれることを示す。 接続解除 N-DISCONNECT.REQUEST動作を実行するために、TSピアは単にTCP接続を閉じる。 TCPが接続閉じたかエラーしたとTSピアに通知する場合、N-DISCONNECT.INDICATIONイベントを示す。 6. パケットフォーマット TCPとTP0によって期待されたネットワークサービスとの基本的な差は、 TCPが明示的な境界なしで、オクテットの連続的な流れを管理するということである。 TP0は、ネットワークサービスデータユニット(NSDU)と呼ばれる 不連続なオブジェクトで送られ伝えられる情報を予期する。 トランスポートの他のクラスは、単一NSDUの内部では1つを越えるTPDUを組み合わせるかもしれないが、 トランスポートクラス0はこの機能を使わない。 従って、NSDUは、我々の議論の目的ではTPDUと同一である。 このメモで記述されるプロトコルは、TPDUの限界を定めるために単純なパケット化方式を使う。 各パケットは、TPKTと名付けられ、整数個のオクテットからなる可変長のオブジェクトとして見える。 注:プレゼンテーションのために、これらのオブジェクトは4オクテット(32ビット幅)として示される。 この表現はこのメモのスタイルの弊害であり、 TPKTが4オクテットの倍数の長さであるべきと要求するように解釈されてはならない。 TPKTは2つの部分からなる : パケットヘッダとTPDU。 ヘッダのフォーマットは、パケットのタイプにかかわらず一定である。 パケットヘッダのフォーマットは以下のとおり: 図 ここで: vrsn　8ビット このフィールドは、このメモで記述されたプロトコルのバージョンのため、常に3である。 パケット長さ　16ビット(最小7、最大65535) 　 このフィールドは、パケットヘッダを含む全パケットのオクテットでの長さを含む。 これは、65531オクテットの最大TPDUサイズを許す。 データ転送(DT)TPDUのサイズに基づくと、65524オクテットの最大TSDUサイズを許す。 TPDUのフォーマットは[ISO8073]で定義される。 トランスポートクラス0のためにフォーマットされたTPDUだけが交換されることに注意 (異なるトランスポートクラスはわずかに異なるフォーマットを使うかもしれない)。 --------------------- 緊急データをサポートするために、緊急データのための非標準のTPDUが可能になる。 ED TPDUのために使われたフォーマットは、正常なデータ、DT、TPDUのためのフォーマットとほとんど同一である。 ただ一つの違いは、TPDUのコードのために使われた値はDTではなくEDであるということ: 図 信用フィールド(出力においては常に0、入力においては無視)の後に、 ユーザデータに先立って1つの追加フィールドがある。 TPDU-NRとEOT 8ビット ビット7(最上位ビット、ビットマスク1000 0000)は、TSDUの終了を示す。 他のすべてのビットは、出力において0、入力において無視されるべきである。 TP仕様が、緊急トランスポートサービスデータユニット(XSDU)のサイズを16オクテットに制限することに注意。 7. コメント 1986年4月のRFC983リリース以来、TCP上にISOトランスポートサービスを使った多くの経験を獲得した。 1986年9月、社会からのコメントにほとんど基づき、プロトコルのバージョン2の使用を導入した。 1987年1月、プロトコルのバージョン2と実際のトランスポートクラス0定義との違いが実際非常に小さいと発見した。 振り返ると、この実現が、実現されるべきであるよりはるかに長くかかった: 信頼できるネットワークサービス(例えばX.25)上でTP0が走ることを意味する。 TCPは、このタイプのサービスを提供するために使え、また、大きすぎる声で苦情を誰も言わなければ、 このメモがTPOをTCPの内部にカプセル化する方法をまさに本当に記述すると述べることもできた! プロトコルのバージョン1からバージョン2まで、その後バージョン3まで進む変化は、すべて比較的小さい。 最初に、バージョン1について記述する際に、ISOトランスポートプロトコルからのTPDUフォーマットを使うと決定した。 これは、自然に上述された発展に結びついた。 8. 参照 [GOSIP86] The U.S. Government OSI User's Committee. "Government Open Systems Interconnection Procurement (GOSIP) Specification for Fiscal years 1987 and 1988." (December, 1986) [draft status] [ISO8072] ISO. "International Standard 8072. Information Processing Systems -- Open Systems Interconnection: Transport Service Definition." (June, 1984) [ISO8073] ISO. "International Standard 8073. Information Processing Systems -- Open Systems Interconnection: Transport Protocol Specification." (June, 1984) [ISO8327] ISO. "International Standard 8327. Information Processing Systems -- Open Systems Interconnection: Session Protocol Specification." (June, 1984) [ RFC 791 ] Internet Protocol. Request for Comments 791 (MILSTD 1777) (September, 1981) [ RFC 793 ] Transmission Control Protocol. Request for Comments 793 (MILSTD 1778) (September, 1981) [ RFC 983 ] ISO Transport Services on Top of the TCP. Request for Comments 983 (April, 1986) [X.214] CCITT. "Recommendation X.214. Transport Service Definitions for Open Systems Interconnection (OSI) for CCITT Applications." (October, 1984) [X.224] CCITT. "Recommendation X.224. Transport Protocol Specification for Open Systems Interconnection (OSI) for CCITT Applications." (October, 1984) [X.225] CCITT. "Recommendation X.225. Session Protocol Specification for Open Systems Interconnection (OSI) for CCITT Applications." (October, 1984) Back to the RFC HomePage