システムネットワークアーキテクチャ

システムネットワークアーキテクチャ^[1] ( SNA )は、1974年に開発されたIBM独自のネットワークアーキテクチャです。 ^[2]これは、コンピュータとそのリソースを相互接続するための完全なプロトコルスタックです。SNAはフォーマットとプロトコルを記述しますが、それ自体はソフトウェアではありません。SNAの実装は、さまざまな通信パッケージの形式を取りますが、最も有名なのは、SNA通信用のメインフレームソフトウェアパッケージであるVirtual Telecommunications Access Method (VTAM)です。

SNAは、1974年9月にIBMが発表した「Advanced Function for Communications」の一部として公開されました。^[3]これには、新しい通信製品へのSNA/SDLC（同期データリンク制御）プロトコルの実装が含まれていました。

• IBM 3767通信端末（プリンター）
• IBM 3770データ通信システム

これらは、IBM 3704/3705通信コントローラとそのネットワーク制御プログラム（NCP）、System/370とそのVTAM、およびCICSやIMSなどの他のソフトウェアによってサポートされていました。この発表に続いて、1975年7月に別の発表が行われ、IBM 3760データエントリステーション、IBM 3790通信システム、およびIBM 3270ディスプレイシステムの新しいモデルが導入されました。^[4]

SNAは、コンピュータ業界が階層化通信の概念を完全には採用していなかった時代に設計された。アプリケーション、データベース、通信機能が同じプロトコルまたは製品に混在していたため、保守と管理が困難だった。^{[5] [6] SNAは主に米国}ノースカロライナ州リサーチトライアングルパークのIBMシステム開発部門研究所で設計され、[ ^{7] SNA/SDLCを実装した他の研究所の支援を受けた。IBMは後に、システムリファレンスライブラリのマニュアルと}IBM Systems Journalで詳細を公開した。

SNA は、銀行やその他の金融取引ネットワーク、および多くの政府機関で現在でも広く使用されています。1999 年には、推定 3,500 社が「11,000 台の SNA メインフレームを所有」していました。^[8]主要なハードウェアの 1 つである3745/3746通信コントローラは、IBM によって市場から撤退しました^[a]。IBM は、ユーザーをサポートするために、ハードウェア保守サービスとマイクロコード機能を提供し続けています。小規模企業の堅調な市場は、3745/3746、機能、部品、およびサービスを引き続き提供しています。VTAM も IBM によってサポートされており、3745/3746 コントローラに必要な NCP も同様です。

2008 年に IBM の出版物で次のように述べられました。

TCP/IP の普及と成長に伴い、SNA は真のネットワーク アーキテクチャから「アプリケーションとアプリケーション アクセス アーキテクチャ」と呼ばれるものへと変化しています。言い換えれば、SNA で通信する必要があるアプリケーションは依然として多くありますが、必要な SNA プロトコルは IP によってネットワーク上で伝送されます。^[9]

1970 年代半ばの IBM は、主にハードウェア ベンダーであると自認していたため、その時期のすべてのイノベーションはハードウェアの売上増加を目的としていました。SNA の目的は、多数の端末の運用コストを削減し、バッチシステムではなく対話型端末ベースのシステムの開発や拡張を顧客に促すことでした。対話型端末ベースのシステムの拡張により、端末の売上が増加し、さらに重要なことに、メインフレーム コンピューターと周辺機器の売上が増加しました。これは、システムで実行される作業量が単純に増加するためと、対話型処理ではバッチ処理よりもトランザクションごとに多くの計算能力が必要になるためです。

したがって、SNA は、以前の通信プロトコルを使用して大規模ネットワークを運用する際の主な非コンピュータ コストやその他の困難を軽減することを目的としていました。困難には次のようなものがありました。

• 異なるタイプの端末では、既存の通信プロトコルの異なる「方言」が使用されているため、通信回線を共有できないことがよくありました。1970 年代初頭までは、コンピュータ コンポーネントが非常に高価でかさばっていたため、端末に汎用通信インターフェイス カードを組み込むことは不可能でした。すべてのタイプの端末には、同じ回線上の他のタイプの端末との互換性がなく、1 種類の端末の操作のみをサポートする有線通信カードがありました。
• 原始的な通信カードが処理できるプロトコルは効率的ではありませんでした。各通信回線は、現代の回線よりもデータの送信に多くの時間を費やしました。
• 当時の通信回線の品質ははるかに低かった。たとえば、今日のダイヤルアップ回線の 1 秒あたり 56,000 ビットと比較すると、圧倒的なエラー率のため、ダイヤルアップ回線を 1 秒あたり 19,200 ビット以上で動作させることはほとんど不可能だった。また、1970 年代初頭には、1 秒あたり 2,400 ビット以上で動作している専用回線はほとんどなかった (このような低速は、比較的技術の低い環境におけるシャノンの法則の結果である)。

その結果、多数の端末を稼働させるには、今日必要な数よりもはるかに多くの通信回線が必要になりました。特に、異なるタイプの端末をサポートする必要がある場合や、ユーザーが同じ場所から異なるタイプのアプリケーション (CICS または TSO など) を使用したい場合には、その傾向が顕著でした。純粋に財務的な観点から言えば、SNA の目的は、主に通信会社を犠牲にして、端末ベースのシステムに対する顧客の支出を増やすと同時に、その支出における IBM のシェアを増やすことでした。

SNA は、IBM のSystem/370メインフレームがSystem/360から継承したアーキテクチャの制限を克服することも目的としていました。各 CPU は最大 16 のI/O チャネル^[10]に接続でき、各チャネルは最大 256 の周辺機器を処理できました。つまり、CPU あたり最大 4096 の周辺機器がありました。SNA が設計された当時は、各通信回線が周辺機器としてカウントされていました。そのため、強力なメインフレームが通信できる端末の数は限られていました。

コンピュータ コンポーネント テクノロジの改良により、特定の種類の端末にのみ適した非常に簡素なプロトコルではなく、単一の標準通信プロトコルを操作できる、より強力な通信カードを搭載した端末を構築することが可能になりました。その結果、1970 年代に複数の多層通信プロトコルが提案され、そのうち IBM の SNA とITU-TのX.25 が後に主流となりました。

SNA の最も重要な要素は次のとおりです。

• IBMネットワーク制御プログラム（NCP）^{[11] [12]は、} 3705およびそれ以降の37xx通信プロセッサ上で実行される通信プログラムであり、SNAで定義されたパケット交換プロトコルを実装しています。このプロトコルは、主に2つの機能を実行します。
  • これはパケット転送プロトコルであり、現代のスイッチのように動作し、データ パッケージを次のノード (メインフレーム、端末、または別の 3705) に転送します。通信プロセッサは、ラインの終端にあるマシンが同時にクライアントとサーバーの両方になることができるピアツーピア ネットワークをサポートする現代のルーターとは異なり、メインフレームを中心とする階層型ネットワークのみをサポートしていました。
  • これは、複数の端末を CPU への 1 つの通信回線に接続するマルチプレクサであり、CPU あたりの通信回線の最大数の制約を緩和します。3705 は、より多くの回線 (当初は 352) をサポートできましたが、CPU とチャネルでは 1 つの周辺機器としてのみカウントされました。SNA の発売以来、IBM は改良された通信プロセッサを導入しており、その最新のものは3745です。
• 同期データリンク制御^[13]（SDLC）は、単一リンク上のデータ転送の効率を大幅に向上させたプロトコルである。^[14]
  • これはスライディング ウィンドウ プロトコルであり、端末と 3705 通信プロセッサが、前のフレームの確認応答を待たずにデータ フレームを次々に送信できるようにします。通信カードには、送受信された最後の 7 つのフレームを記憶し、エラーを含むフレームのみの再送信を要求し、再送信されたフレームを次のステージに転送する前にシーケンス内の適切な場所に挿入するのに十分なメモリと処理能力がありました。
  • これらのフレームはすべて同じタイプのエンベロープ（フレームヘッダーとトレーラー）^[15]を持っており、これには異なるタイプの端末からのデータパッケージを同じ通信回線で送信するのに十分な情報が含まれていたため、メインフレームはコンテンツのフォーマットや異なるタイプの端末とのダイアログを管理するルールの違いに対処できました。

リモート端末 (電話回線でメインフレームに接続されている端末など) と 3705 通信プロセッサには、SDLC 対応の通信カードが搭載されます。

これは、最終的に今日のTCP/IP技術へと進化したパケット通信の前身です^[要出典]。SDLC自体は、専用通信回線の基本技術の1つであるHDLC ^{[16]へと進化しました。}

• VTAM ^{[17] [18]}メインフレーム内でログイン、セッション維持、ルーティングサービスを提供するソフトウェアパッケージ。端末ユーザーはVTAMを介して特定のアプリケーションまたはアプリケーション環境（CICS、IMS、DB2、TSO / ISPFなど）にログインする。VTAMデバイスは、ユーザーがログアウトして別のアプリケーションにログインするまで、その端末から適切なアプリケーションまたはアプリケーション環境にデータをルーティングする。IBMハードウェアのオリジナルバージョンでは、端末ごとに1つのセッションしか維持できなかった。1980年代には、さらなるソフトウェア（主にサードパーティベンダー製）により、端末が異なるアプリケーションまたはアプリケーション環境と同時にセッションを持つことが可能になった。

SNA は、リンク制御をアプリケーション プログラムから削除し、NCP に配置しました。これには、次の利点と欠点がありました。

• 通信リンクを実際に処理するソフトウェアの量は比較的少なかったため、通信ネットワークの問題の特定は容易でした。エラー報告システムは 1 つだけでした。
• 通常、割り込みプロセッサとソフトウェア タイマーを必要とするリンク制御ソフトウェアの困難な領域がシステム ソフトウェアとNCPに委ねられたため、アプリケーション プログラムに通信機能を追加することがはるかに簡単になりました。
• 拡張ピアツーピア ネットワーキング(APPN)の出現により、ルーティング機能は、ルーターではなくコンピューターの責任になりました (TCP/IP ネットワークの場合と同様)。各コンピューターは、転送メカニズムを定義するノードのリストを保持していました。ネットワーク ノードと呼ばれる集中型ノード タイプは、他のすべてのノード タイプのグローバル テーブルを保持していました。APPN により、エンドポイント間の接続を明示的に定義する拡張プログラム間通信(APPC) ルーティング テーブルを保持する必要がなくなりました。APPN セッションは、宛先が見つかるまで、他の許可されたノード タイプを介してエンドポイントにルーティングされます。これは、インターネット プロトコルおよび Netwareインターネットワーク パケット交換プロトコルのルーターが機能する方法に似ています。 (APPN は、PU2.1 または物理装置 2.1 と呼ばれることもあります。APPC は、LU6.2 または論理装置 6.2 と呼ばれることもあり、APPN ネットワークに定義された唯一のプロトコルでしたが、もともとは LU0、LU1、LU2 (3270 端末)、LU3 とともに VTAM/NCP でサポートされる多くのプロトコルの 1 つでした。APPC は、2 フェーズ コミット処理用のプロトコルに接続するため、主に CICS 環境間やデータベース サービスで使用されていました)。物理装置は、PU5 (VTAM)、PU4 (37xx)、PU2 (クラスタ コントローラ) でした。PU5 は最も有能で、すべての通信でプライマリと見なされていました。他の PU デバイスは PU5 からの接続を要求し、PU5 は接続を確立することも確立しないこともできます。他の PU タイプは、PU5 に対してセカンダリになることしかできませんでした。PU2.1 は、ピアツーピア環境で別の PU2.1 に接続する機能を PU2.1 に追加しました。^[19]）

• 非 SNA ネットワークへの接続は困難でした。現在のバージョンの SNA でサポートされていない通信方式へのアクセスを必要とするアプリケーションは、障害に直面しました。IBM がSNA にX.25サポート (NPSI) を組み込む前は、X.25 ネットワークへの接続は困難でした。X.25 プロトコルと SNA プロトコル間の変換は、NCP ソフトウェアの変更または外部プロトコル コンバーターによって提供できました。
• ネットワーク内の各ノード ペア間の代替パスの束を事前に設計し、中央に保存する必要がありました。SNA によるこれらのパスの選択は固定的であり、現在のリンク負荷を利用して最適な速度を得ることはできませんでした。
• SNA ネットワークのインストールと保守は複雑で、SNA ネットワーク製品は高価です (または高価でした)。IBMアドバンスト ピアツーピア ネットワーキング機能を追加して SNA ネットワークの複雑さを軽減する試みは、従来の SNA から SNA/APPN への移行が非常に複雑で、少なくとも当初は付加価値があまりなかったため、あまり成功しませんでした。SNA ソフトウェア ライセンス (VTAM) は、ハイエンド システムの場合、月額 10,000 ドルもかかります。また、SNA IBM 3745通信コントローラは通常 100,000 ドル以上します。TCP /IP は、1980 年代後半まで金融業界などの商用アプリケーションには不向きと見られていましたが、1990 年代にはピアツーピア ネットワーキングとパケット通信テクノロジにより急速に普及しました。
• SNA の接続ベースのアーキテクチャは、すべてを追跡するために巨大なステート マシン ロジックを呼び出しました。APPN は、異なるノード タイプの概念によってステート ロジックに新しい次元を追加しました。すべてが正しく実行されているときは安定していましたが、それでも手動による介入が必要でした。コントロール ポイント セッションの監視などの単純な作業は手動で行う必要がありました。APPN に問題がなかったわけではありません。初期の頃は、APPN サポートに問題が見つかったため、多くのショップが APPN の使用を中止しました。しかし、時間が経つにつれて、多くの問題が解決されましたが、1990 年代初頭に TCP/IP がますます普及し、SNA の終焉の始まりとなりました。

SNA は、その中核として、さまざまな接続層をセキュリティで包む機能を備えて設計されました。SNA 環境内で通信するには、まずノードに接続し、ネットワークへのリンク接続を確立して維持する必要があります。次に、適切なセッションをネゴシエートし、セッション自体内のフローを処理する必要があります。各レベルには、接続を管理し、セッション情報を保護できるさまざまなセキュリティ制御があります。^[20]

SNAネットワークにおけるネットワークアドレス可能ユニットとは、アドレスを割り当てられ、情報を送受信できるコンポーネントのことである。これらはさらに以下のように区別される。^[21]

• システムサービス制御ポイント（SSCP）は、サブエリアネットワーク内のユーザーにリソース管理やその他のセッションサービス（ディレクトリサービスなど）を提供します。^[22]
• 物理ユニットは、他のノードへのリンクを制御するハードウェアとソフトウェアのコンポーネントの組み合わせです。^[23]
• 論理ユニットはユーザーとネットワークの間の仲介役として機能します。^[24]

SNA は本質的に透過的な通信を提供します。つまり、LU-LU 通信に制約を課さない機器の詳細を提供します。ただし、アプリケーションは端末機器の機能 (画面サイズやレイアウトなど) を考慮する必要があるため、最終的には LU タイプを区別する目的があります。

SNA には、ローカル ディスプレイ端末とプリンターを接続するための 3 種類のデータ ストリームがあります。LU1 端末用および未フォーマット システム サービス (USS) による SNA ネットワークへのログオン用に使用される SNA 文字列 (SCS)、System/370やその後継機 ( zSeriesファミリーを含む)などのメインフレームで主に使用される3270 データ ストリーム、 System/34、System/36、System/38、AS/400やその後継機 (System i およびIBM i を実行するIBM Power Systemsを含む)などのミニコンピューター/サーバーで主に使用される5250 データ ストリームです。

SNAは論理ユニットタイプと呼ばれるいくつかの種類のデバイスを定義しています。^[25]

• LU0 は未定義のデバイスに対応し、独自のプロトコルを構築します。これは、TCAMまたは VTAM でサポートされる非 SNA 3270 デバイスにも使用されます。
• LU1 デバイスはプリンター、またはキーボードとプリンターの組み合わせです。
• LU2 デバイスは IBM 3270 ディスプレイ端末です。
• LU3 デバイスは、3270 プロトコルを使用するプリンターです。
• LU4 デバイスはバッチ端末です。
• LU5 は定義されていません。
• LU6 は 2 つのアプリケーション間のプロトコルを提供します。
• LU7 は IBM 5250 端末とのセッションを提供します。

主に使用されるのは、LU1、LU2、およびLU6.2 (アプリケーション間の会話のための高度なプロトコル) です。

• PU1ノードはIBM 6670やIBM 3767などの端末コントローラです。
• PU2ノードは、 IBM 3174、IBM 3274、IBM 4701またはIBM 4702ブランチコントローラなどの構成サポートプログラムを実行するクラスタコントローラです。
• PU2.1ノードはピアツーピア （APPN）ノードである
• PU3は定義されなかった
• PU4ノードは、 IBM 37xxシリーズなどのネットワーク制御プログラム（NCP）を実行するフロントエンドプロセッサです。
• PU5ノードはホストコンピュータシステムである^[26]

37xxという用語は、IBM の SNA 通信コントローラ ファミリを指します。3745 は最大 8 つの高速T1回線をサポートし、3725 はホスト用の大規模ノードおよびフロントエンド プロセッサであり、 3720 はコンセントレータおよびルーターとして機能するリモート ノードです。

IBMトークン リングネットワークに接続された VTAM/NCP PU4 ノードは、ワークステーションやサーバーと同じローカル エリア ネットワーク インフラストラクチャを共有できます。NCP は SNA パケットをトークン リング フレームにカプセル化し、セッションがトークン リング ネットワーク上で流れるようにします。実際のカプセル化とカプセル化解除は 3745 で行われます。

メインフレーム ベースの組織が 37XX ベースのネットワークに代わるものを探していたため、IBM は1990 年代半ばにCiscoと提携し、共同でデータ リンク スイッチング(DLSw) を開発しました。DLSw は SNA パケットを IP データグラムにカプセル化し、セッションが IP ネットワーク上で流れるようにします。実際のカプセル化とカプセル化解除は、DLSw ピア接続の両端にある Cisco ルータで行われます。ローカル サイトまたはメインフレーム サイトでは、ルータはトークン リング トポロジを使用して VTAM にネイティブに接続します。接続のリモート (ユーザー) 側では、PU タイプ 2 エミュレーター (SNA ゲートウェイ サーバーなど) がルーターの LAN インターフェイスを介してピア ルーターに接続します。エンド ユーザー ターミナルは通常、SNA ゲートウェイに定義されている 3270 エミュレーション ソフトウェアを搭載した PC です。 VTAM/NCP PU タイプ 2 定義は、VTAM に対してローカルにできるスイッチド メジャー ノード (NCP なし) になり、さまざまなソリューション (3745 のトークン リング インターフェイス、3172 Lan チャネル ステーション、または Cisco ESCON互換のチャネル インターフェイス プロセッサなど) を使用して「回線」接続を定義できます。

Honeywell Bullメインフレームの独自のネットワークアーキテクチャは、分散システムアーキテクチャ（DSA）です。^[27] DSAの通信パッケージはVIPです。DSAはクライアントアクセスでもサポートされなくなりました。Bullメインフレームには、DSAをTCP/IPに変換するためのMainwayが装備されており、VIPデバイスはTNVIPターミナルエミュレーション（GLink、Winsurf）に置き換えられました。GCOS 8はTCP/IP上のTNVIP SEをサポートしています。

Univacメインフレームのネットワーク アーキテクチャは分散コンピューティング アーキテクチャ (DCA) であり、Burroughsメインフレームのネットワーク アーキテクチャは Burroughs ネットワーク アーキテクチャ (BNA) でした。両社が合併してUnisys が設立された後、両社は合併後の会社によって提供されました。両社とも 2012 年までにほぼ廃止されました。International Computers Limited (ICL) は情報処理アーキテクチャ (IPA) を提供しました。

DECnet ^{[28] [29] [30]は}、Digital Equipment Corporationが開発したネットワークプロトコルスイートであり、1975年に2台のPDP-11ミニコンピュータを接続するために最初にリリースされました。これは、最初のピアツーピアネットワークアーキテクチャの1つに進化し、1980年代にDECをネットワーク業界の大国へと変貌させました。

SNA は、ベンダー中立のネットワーク アーキテクチャを作成する試みであったISOのOpen Systems Interconnectionとも競合していましたが、「委員会による設計」の問題により失敗しました。^{[引用が必要]} OSI システムは非常に複雑であり、多くの関係者が関与しているため、当初の主な目的であった OSI システムの相互運用性を損なう広範な柔軟性が求められました。^{[引用が必要]}

TCP/IP スイートは、知的財産に対するコントロールが欠如していることもあって、長年 IBM では本格的な代替手段とは見なされていませんでした。^[要出典] Yakov Rekhterによって作成された1988 年のRFC  1041 では、Telnet経由でIBM 3270セッションを実行するオプションが定義されており、データ センターでの相互運用性に対する顧客の要求が明確に認識されています。その後、IETF は、他の複数の RFC でこの作業を拡張しました。これらの RFC で定義されているTN3270 (Telnet 32​​70) は、メインフレーム上の TN3270 サーバーと、エンド ユーザー サイトのコンピューター上の TN3270 エミュレーション パッケージを使用して、メインフレームへの直接クライアント サーバー接続をサポートします。このプロトコルにより、TCP/IP セッション経由で従来の 3270 端末プロトコルをサポートすることで、既存の VTAM アプリケーション (CICS、TSO) を従来の SNA からほとんどまたはまったく変更せずに実行できます。このプロトコルは、データリンク スイッチング(DLSw) やその他の SNA 代替テクノロジーよりも、従来の SNA 接続を置き換えるために広く使用されています。IBM 5250には、同様のTN5250 (Telnet 5250) バリアントが存在します。

IBM 以外の SNA ソフトウェアにより、IBM 以外のシステムがSNA プロトコルを使用して IBM メインフレームやAS/400ミッドレンジ コンピュータと通信できるようになりました。

Sun MicrosystemsのSunLink SNA製品ライン（PU2.1 Serverを含む）^[31]やHewlett-Packard / Hewlett Packard EnterpriseのSNAplus2製品^[32]など、一部のUnixシステムベンダーはSNAソフトウェアを提供していました。

マイクロソフトは1993年にWindows用のSNA Serverを導入しました。 ^{[33]現在は}Microsoft Host Integration Serverという名前になっています。

デジタル・イクイップメント・コーポレーションはVMS用のVMS/SNAを持っていました。^[34] Systems Strategies, Inc.のVAX Link製品など、VMS用のサードパーティ製SNAソフトウェアパッケージも利用可能でした。 ^[34]

ヒューレット・パッカードはHP 3000システム向けにSNAサーバーとSNAアクセスを提供した。^[35]

Brixton SystemsはいくつかのSNAソフトウェアパッケージを開発し、「Brixton " ^{[36] [37] [38] 、}例えばBrixton BrxPU21、BrxPU5、BrxLU62、BrxAPPCなど、ヒューレット・パッカード[ ^39]やサン・マイクロシステムズ^[40]のワークステーションなどのシステム向け。

IBMは、 HPシステム用のSNAplus2、[41]、Sun Solaris用のBrixton 4.1 SNA、[42]、Sun Solaris用のSunLink SNA 9.1 Supportなど、z/OSとの通信にAPPC/PU2.1/LU6.2の非IBMソフトウェア実装^の使用をサポート^しました。 [ 43 ^]

• ネットワークデータムーバー
• プロトコル戦争
• TN3270
• TN5250

• Friend, George E.; Fike, John L.; Baker, H. Charles; Bellamy, John C. (1988)。Understanding Data Communications (第 2 版)。インディアナポリス: Howard W. Sams & Company。ISBN 0-672-27270-9。
• ポーチ、ウド W.、グリーン、ウィリアム H.、モス、ゲイリー G. (1983)。『電気通信とネットワーク』。ボストン: リトル、ブラウン アンド カンパニー。ISBN 0-316-71498-4。
• Schatt, Stan (1991)。『LAN のリンク: マイクロ マネージャー ガイド』。McGraw- Hill。ISBN 0-8306-3755-9。
• システム ネットワーク アーキテクチャの一般情報(PDF)。初版。IBM。1975 年 1 月。GA27-3102-0。
• システム ネットワーク アーキテクチャの概念と製品(PDF)。第 2 版。IBM。1984 年 2 月。GC30-3072-1。
• システム ネットワーク アーキテクチャ技術概要。第 5 版。IBM。1994 年 1 月。GC30-3073-04。
• システム ネットワーク アーキテクチャ ガイド - SNA 出版物。第 3 版。IBM。1994 年 7 月。GC30-3438-02。

• SNA に関するシスコの記事
• APPN 実装者ワークショップ アーキテクチャ ドキュメント リポジトリ
• SNAプロトコルは非常に技術的である
• 関連ホワイトペーパー sdsusa.com
• 通信システム向け高度な機能の概要(PDF)。第 2 版。IBM。1975 年 7 月。GA27-3099-1。2014年5 月 22 日に取得。
• システム ネットワーク アーキテクチャ フォーマット(PDF)。第 21 版。IBM。2004 年 3 月。GA27-3136-20。
• システム ネットワーク アーキテクチャー - 論理ユニット間のセッション(PDF)。第 3 版。IBM。1981 年 4 月。GC20-1868-2。
• システム ネットワーク アーキテクチャー - 論理ユニット間のセッションの概要(PDF)。第 3 版。IBM。1979 年 12 月。GC20-1869-2。
• システム ネットワーク アーキテクチャ フォーマットおよびプロトコル リファレンス マニュアル: アーキテクチャ ロジック(PDF)。第 3 版。IBM。1980 年 11 月。SY20-3112-2。
• システム ネットワーク アーキテクチャー: LU タイプ 6.2 のトランザクション プログラマー リファレンス マニュアル。第 6 版。IBM。1993 年 6 月。GC30-3084-05。
• システム ネットワーク アーキテクチャ タイプ 2.1 ノード リファレンス。第 5 版。IBM。1996 年 12 月。SC30-3422-04。
• システム ネットワーク アーキテクチャ LU 6.2 リファレンス: ピア プロトコル。第 3 版。IBM。1996 年 10 月。SC31-6808-02。