RFC1538 日本語訳
1538 Advanced SNA/IP : A Simple SNA Transport Protocol. W. Behl, B.Sterling, W. Teskey. October 1993. (Format: TXT=21217 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group W. Behl
Request for Comments: 1538 McDATA Corporation
Category: Informational B. Sterling
McDATA Corporation
W. Teskey
I/O Concepts
October 1993
Behlがコメントのために要求するワーキンググループW.をネットワークでつないでください: 1538年のMcDATA社のカテゴリ: 情報の英貨のB.の社のW.Teskey入出力概念McDATA1993年10月
Advanced SNA/IP : A Simple SNA Transport Protocol
高度なSNA/IP: 簡単なSNAトランスポート・プロトコル
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはインターネット標準を指定しません。 このメモの分配は無制限です。
Abstract
要約
This RFC provides information for the Internet community about a method for establishing and maintaining SNA sessions over an IP internet. While the issues discussed may not be directly relevant to the research problems of the Internet, they may be interesting to a number of researchers and implementors. Any questions or comments relative to the contents of this RFC may be sent to the following Internet address: snaip@mcdata.com.
このRFCはSNAセッションを確立して、維持するためのメソッドに関してIPインターネットの上にインターネットコミュニティのための情報を提供します。 議論した問題が直接インターネットの研究課題に関連していないかもしれない間、多くの研究者と作成者にとって、それらはおもしろいかもしれません。 このRFCのコンテンツに比例したどんな質問やコメントも以下のインターネット・アドレスに送るかもしれません: snaip@mcdata.com 。
Table of Contents
目次
1. Introduction.................................................. 2 2. Motivation and Rationale...................................... 2 3. SNA/IP Protocol Specification................................. 3 3.1 Glossary..................................................... 3 3.2 Conventions and Assumptions.................................. 3 3.3 The Protocol................................................. 3 3.3.1 Connection Establishment................................... 3 3.3.2 Data Transfer.............................................. 5 3.3.3 Connection Termination and Loss............................ 6 3.3.4 Session Data Flow.......................................... 7 3.3.5 State Transition Table for the Initiating Node............. 8 4. LLC to SNA/IP Conversion...................................... 8 5. Performance................................................... 8 6. VTAM Definition............................................... 9 7. Acknowledgments............................................... 9 8. References.................................................... 9 9. Security Considerations....................................... 10 10. Authors' Addresses........................................... 10 11. Disclaimer................................................... 10
1. 序論… 2 2. 動機と原理… 2 3. SNA/IPプロトコル仕様… 3 3.1用語集… 3 3.2のコンベンションと仮定… 3 3.3 プロトコル… 3 3.3 .1 接続設立… 3 3.3 .2データ転送… 5 3.3 .3の接続終了と損失… 6 3.3 .4 セッションデータは流れます… 7 3.3 .5 開始ノードのために変遷テーブルを述べてください… 8 4. SNA/IP変換へのLLC… 8 5. パフォーマンス… 8 6. VTAM定義… 9 7. 承認… 9 8. 参照… 9 9. セキュリティ問題… 10 10. 作者のアドレス… 10 11. 注意書き… 10
Behl, Sterling & Teskey [Page 1] RFC 1538 Advanced SNA/IP October 1993
SNA/IP1993年10月に高度なBehl、英貨、およびTeskey[1ページ]RFC1538
1. Introduction
1. 序論
Advanced SNA/IP suggests a method for the transmission of SNA session data over an IP network. This memo documents the SNA/IP protocol as implemented in the McDATA LinkMaster(R) 6200 Network Gateway, McDATA LinkMaster(R) 7100 Network Controller, and I/O Concepts X-Direct TN3270 Server.
高度なSNA/IPはIPネットワークの上にSNAセッションデータの伝達のためのメソッドを示します。 このメモはMcDATA LinkMaster(R)6200Networkゲートウェイ、McDATA LinkMaster(R)7100Network Controller、および入出力ダイレクトにConcepts X TN3270 Serverで実装されるようにSNA/IPプロトコルを記録します。
Advanced SNA/IP differs from other protocols designed to enable routing of SNA session traffic over an IP network. SNA/IP was originally designed for implementation in peripheral network nodes like SNA gateways and downstream nodes (DSNs). It is the authors' view, however, that SNA/IP could also be implemented in intermediate network nodes like routers as the base for an LLC to IP subnet gateway or data link switch function.
高度なSNA/IPはIPネットワークの上でSNAセッショントラフィックのルーティングを可能にするように設計された他のプロトコルと異なっています。 SNA/IPは元々、SNAゲートウェイと川下のノード(DSNs)のような周囲のネットワーク・ノードの実装のために設計されました。 しかしながら、また、IPサブネットゲートウェイへのLLCのためのベースとしてのルータかデータがスイッチ機能をリンクするように中間ネットワークノードでSNA/IPを実装することができたのは、作者の視点です。
2. Motivation and Rationale
2. 動機と原理
The token-ring media access control (MAC) protocol 802.5 and logical link control (LLC) protocol 802.2 were the first set of LAN protocols used to provide a reliable and connection-oriented data link service for SNA sessions in a LAN environment.
トークンリングメディアアクセス制御(MAC)プロトコル802.5と論理的なリンク制御(LLC)プロトコル802.2はLAN環境におけるSNAセッションのための信頼できて接続指向のデータ・リンクサービスを提供するのに使用されるLANプロトコルの第一セットでした。
McDATA's experience with transporting SNA over 802.5 networks led to an 802.3/802.2 (Ethernet) based variation. As prospective customers were introduced to these Ethernet products, the question of routability arose. Network administrators, accustomed to working with Ethernet networks and the IP-based protocols, required an IP routable solution. McDATA's "SNA over Ethernet" products were bridgeable, but were not routable.
輸送SNAより多くの802.5ネットワークのMcDATAの経験は802.3/802.2(イーサネット)のベースの変化につながりました。 予想購買者がこれらのイーサネット製品に取り入れられたとき、routabilityの問題は起こりました。 イーサネットネットワークとIPベースのプロトコルで働くのに慣れているネットワーク管理者はIP発送可能ソリューションを必要としました。 McDATAの「イーサネットの上のSNA」製品は、架橋できましたが、発送可能ではありませんでした。
SNA sessions require a reliable and connection-oriented data link. TCP running over IP provides a reliable and connection-oriented transport service and has the added benefit of being routable. It seemed the UDP and TCP protocols could be used in place of 802.2 Type I and Type II levels of service used in traditional SNA token-ring implementations. Advanced SNA/IP was created as a result of these observations.
SNAセッションは信頼できて接続指向のデータ・リンクを必要とします。 IPをひくTCPが信頼できて接続指向の輸送サービスを提供して、発送可能の付加利益を持っています。 それはUDPに見えました、そして、TCPプロトコルは802.2Typeに代わって使用されて、私とType IIレベルのサービスが伝統的なSNAトークンリングで実装を使用したということであるかもしれません。 高度なSNA/IPはこれらの観測の結果、創設されました。
Behl, Sterling & Teskey [Page 2] RFC 1538 Advanced SNA/IP October 1993
SNA/IP1993年10月に高度なBehl、英貨、およびTeskey[2ページ]RFC1538
3. SNA/IP Protocol Specification
3. SNA/IPプロトコル仕様
3.1. Glossary
3.1. 用語集
Data Link Switching (DLSw) - This is best described as a routing protocol used for the conversion of LLC-based SNA sessions to an IP form. The initial version of the DLSw protocol is documented in the informational RFC 1434 [1].
データLink Switching(DLSw)--LLCベースのSNAセッションの変換にIPフォームに使用されるルーティング・プロトコルとしてこれを記述するのは最も良いです。 DLSwプロトコルの初期のバージョンは情報のRFC1434[1]に記録されます。
Downstream Node (DSN) - An SNA Physical Unit (PU) type 2.0 or 2.1 device connected to the SNA network via a LAN (802.5, 802.3, etc.) as opposed to an SDLC, X.25, or channel connection.
川下のNode(DSN)--SNA Physical Unit(PU)タイプ2.0か2.1デバイスはSDLC、X.25、またはチャンネル接続と対照的にLAN(802.5、802.3など)を通したSNAネットワークに接続しました。
SNA Gateway - A device that provides a data link control (DLC) conversion function for SNA PU type 5 (host) devices and LAN- attached DSNs.
SNAゲートウェイ--SNA PUタイプ5台の(ホスト)デバイスとLANにデータリンク制御(DLC)変換機能を提供するデバイスはDSNsを取り付けました。
Subnet SNA Gateway - A device connected to both a traditional SNA token-ring segment and an IP network that performs local termination of the LLC connections, a mapping function of source address to destination IP address, and a conversion (switching) function of LLC to IP.
サブネットSNAゲートウェイ--デバイスはLLC接続の地方の終了、送付先IPアドレスへのソースアドレスのマッピング機能、およびIPへのLLCの変換(切り換え)機能を伝統的なSNAトークンリングセグメントと働くIPネットワークの両方に関連づけました。
3.2. Conventions and Assumptions
3.2. コンベンションと仮定
Frame formats are shown starting with the IP header. Other headers will, of course, appear in the actual frames sent, but these headers, and the numbers of them, will vary across MAC types.
フレーム形式はIPヘッダーから始めるのが示されます。 他のヘッダーは、実際のフレームで送られるようにもちろん見えるでしょうが、これらのヘッダー、およびそれらの数はMACタイプの向こう側に異なるでしょう。
It is assumed the reader is familiar with both the standard SNA protocol (to the extent it applies to SNA Gateway and DSN functions) and the base set of TCP/IP protocols. Where practical, the reader is asked to refer to appropriate SNA and TCP/IP documentation.
読者が標準のSNAプロトコル(それがSNAゲートウェイとDSN機能に適用されるという範囲への)とTCP/IPプロトコルの基底集合の両方に詳しいと思われます。 実用的であるところでは、読者が適切なSNAとTCP/IPドキュメンテーションを参照するように頼まれます。
3.3. The Protocol
3.3. プロトコル
Conceptually, there are three phases to the Advanced SNA/IP protocol: the Connection Establishment phase, the Data Transfer phase, and the Connection Termination phase.
概念的に、Advanced SNA/IPプロトコルへの三相があります: Connection特権階級フェーズ、Data Transferフェーズ、およびConnection Terminationフェーズ。
3.3.1. Connection Establishment
3.3.1. コネクション確立
Connection Establishment involves the exchange of logical XID packets between the connecting end nodes and culminates in the establishment of a TCP connection. This process is similar to the IBM-specified Test, XID, SABME and UA exchange used to establish a Type II 802.2 connection for SNA traffic [2]. In place of the 802.2 Type I messages, SNA/IP defines the following set of UDP datagrams:
接続特権階級は、接続エンドノードの間の論理的なXIDパケットの交換にかかわって、TCP接続の設立に終わります。 このプロセスは交換がSNAトラフィック[2]のためのType II802.2接続を証明するのに使用したIBMによって指定されたTest、XID、SABME、およびUAと同様です。 802.2Type Iメッセージに代わって、SNA/IPは以下のセットのUDPデータグラムを定義します:
Behl, Sterling & Teskey [Page 3] RFC 1538 Advanced SNA/IP October 1993
SNA/IP1993年10月に高度なBehl、英貨、およびTeskey[3ページ]RFC1538
Logical Null XID
論理的なヌルXID
Use: Sent by an initiating node (such as a DSN) when the
connection to another SNA node is desired.
使用: 別のSNAノードとの接続が望まれているとき、開始ノード(DSNなどの)で、発信しました。
The Logical Null XID communicates the sending node's
desire to negotiate connection parameters. Once those
parameters are established, the Logical Null XID
communicates the sender's TCP port to which a connection
is to be made.
Logical Null XIDは接続パラメタを交渉する送付ノードの願望を伝えます。 それらのパラメタがいったん確立されると、Logical Null XIDは接続が作られていることになっている送付者のTCPポートを伝えます。
Format:
形式:
------------------------------------
| IP Header | UDP Header | 0xBF |
------------------------------------
------------------------------------ | IPヘッダー| UDPヘッダー| 0xBF| ------------------------------------
Source IP address: The IP address of the initiating
node.
Destination IP address: The IP address of the partner SNA
node.
Source UDP Port: Must match the TCP port number to be
used in the eventual TCP connection.
Destination UDP Port: A known port on the partner node
that expects SNA/IP datagrams.
ソースIPアドレス: 開始ノードのIPアドレス。 送付先IPアドレス: パートナーSNAノードのIPアドレス。 ソースUDPは以下を移植します。 最後のTCP接続に使用されるためにTCPポートナンバーを合わせなければなりません。 目的地UDP港: SNA/IPデータグラムを予想するパートナーノードの上の知られているポート。
XID Request
XID要求
Use: Sent in response to a Logical Null XID and requests the
receiving node to send a Logical SNA XID datagram.
使用: Logical Null XIDと要求に対応して、Logical SNA XIDデータグラムを送るために受信ノードを送りました。
Format:
形式:
------------------------------------
| IP Header | UDP Header | 0xBF |
------------------------------------
------------------------------------ | IPヘッダー| UDPヘッダー| 0xBF| ------------------------------------
The source and destination IP and UDP port numbers follow,
logically, from those provided in the Logical Null XID
datagram.
ソース、目的地IP、およびUDPポートナンバーはLogical Null XIDデータグラムに提供されたものから論理的に従います。
The format of the XID Request and Logical Null XID are the
same. The two types are distinguished by the roles assumed by
the two nodes. In current implementations, the DSN initiates
the XID exchange by sending the Logical Null XID. The SNA
Gateway responds with the XID request.
XID RequestとLogical Null XIDの形式は同じです。 2つのタイプが2つのノードによって引き受けられた役割によって区別されます。 現在の実装では、DSNは、Logical Null XIDを送ることによって、XID交換を起こします。 SNAゲートウェイはXID要求で応じます。
Behl, Sterling & Teskey [Page 4] RFC 1538 Advanced SNA/IP October 1993
SNA/IP1993年10月に高度なBehl、英貨、およびTeskey[4ページ]RFC1538
Logical SNA XID
論理的なSNA XID
Use: Sent in response to an XID Request and in the context of
SNA XID negotiation.
使用: XID Requestに対応したSNA XID交渉の文脈では、発信しました。
Format:
形式:
----------------------------------------------------
| IP Header | UDP Header | 0xBF | SNA XID data |
----------------------------------------------------
---------------------------------------------------- | IPヘッダー| UDPヘッダー| 0xBF| SNA XIDデータ| ----------------------------------------------------
For PU 2.0 nodes, the SNA XID data consists of a Format 0 XID
[3].
For PU 2.1 nodes, the SNA XID data consists of a Format 3 XID
[3].
PU2.0に関しては、ノードであり、SNA XIDデータはFormat0XID[3]から成ります。 PU2.1に関しては、ノードであり、SNA XIDデータはFormat3XID[3]から成ります。
A typical Connection Establishment data flow appears below.
典型的なConnection特権階級データフローは以下に現れます。
Node 1 Node 2
ノード1ノード2
Logical Null XID ------------------------->
<------------------------ XID Request
Logical SNA XID -------------------------->
<------------------------ TCP SYN
TCP SYN ACK ----------------------------->
<------------------------ TCP ACK
論理的なヌルXID-------------------------><。------------------------ XIDは論理的なSNA XIDを要求します。--------------------------><。------------------------ TCP SYN TCP SYN ACK-----------------------------><。------------------------ TCP ACK
Note: The source UDP port of the Logical Null XID equals the destination TCP port of the TCP SYN segment.
以下に注意してください。 Logical Null XIDのソースUDP港はTCP SYNセグメントの目的地TCP港と等しいです。
Retries of the Logical Null XID by the initiating node should occur periodically until an XID Request is received in reply. The frequency of the retries is left up to the implementor. The lower bound on the retry timer should be more than the expected round trip time for a packet on the network.
開始ノードによるLogical Null XIDの再試行は回答でXID Requestを受け取るまで定期的に起こるべきです。 再試行の頻度は作成者に任せられます。 再試行タイマにおける下界はネットワークのパケットのための予想された周遊旅行時間より多いはずです。
3.3.2. Data Transfer
3.3.2. データ転送
There are no special packets defined for the Data Transfer phase. Once the TCP connection is established, SNA Request Units (RUs) may be exchanged between the two end nodes. The SNA session data appears as TCP segment data. The only added SNA/IP requirement is that each SNA message consisting of a Transmission Header (TH), Request/Response Header (RH) and an optional Request/Response Request Unit (RU) be preceded by a two octet length field. Examples of Data
Data Transferフェーズのために定義されたどんな特別なパケットもありません。 いったんTCP接続を確立すると、2つのエンドノードの間でSNA Request Units(RUs)を交換するかもしれません。 SNAセッションデータはTCPセグメントデータとして現れます。 唯一の加えられたSNA/IP要件は2八重奏長さの分野がTransmission Header(TH)、Request/応答Header(RH)、および任意のRequest/応答Request Unit(RU)から成るそれぞれのSNAメッセージに先行するということです。 データに関する例
Behl, Sterling & Teskey [Page 5] RFC 1538 Advanced SNA/IP October 1993
SNA/IP1993年10月に高度なBehl、英貨、およびTeskey[5ページ]RFC1538
Transfer frames are shown below.
転送フレームは以下で見せられます。
-------------------------------------------------------
| IP Header | TCP Header | SNA Msg 1 len | SNA Msg 1 |
-------------------------------------------------------
------------------------------------------------------- | IPヘッダー| TCPヘッダー| SNAエムエスジー1len| SNAエムエスジー1| -------------------------------------------------------
----------------------------------------------
| IP Header | TCP Header | SNA Msg 1 cont'd ->
----------------------------------------------
--------------------------------
| SNA Msg 2 len | SNA Msg 2 |
--------------------------------
---------------------------------------------- | IPヘッダー| TCPヘッダー| SNAエムエスジー1contがそうするだろう、->。---------------------------------------------- -------------------------------- | SNAエムエスジー2len| SNAエムエスジー2| --------------------------------
The length field is passed in big endian format. 0 is a valid length value.
長さの野原はビッグエンディアン形式で通り過ぎられます。 0は有効な長さの値です。
The format of the SNA Message pieces are as defined by SNA [3].
SNA[3]で定義されて、Message断片があるSNAの形式。
Reliable and sequential delivery of data is provided by the TCP protocol [5,6].
TCPプロトコル[5、6]はデータの信頼できて連続した配送を提供します。
3.3.3. Connection Termination and Loss
3.3.3. 接続終了と損失
Either SNA node may, at any time, terminate the logical SNA connection by issuing a TCP-level FIN segment. Dictates of the TCP protocol apply to this termination process [5,6].
どちらのSNAノードも、いつでも、TCP-レベルFINセグメントを発行することによって、論理的なSNA接続を終えるかもしれません。 TCPプロトコルの命令はこの終了プロセス[5、6]に適用されます。
A connection is also terminated, though not as cleanly, if a TCP Reset segment is sent by either SNA node.
どちらのSNAノードでもTCP Resetセグメントを送るなら、接続は、また、終えられて、もっとも、きれい好きではありません。
Once a connection is terminated, a new connection may be established by the process outlined in the Connection Establishment section. For reconnections made to the LinkMaster 6200 gateway, the same UDP source port must be used by the initiating node. This implies that the same TCP port is used. This requirement stems from the fact the gateway may not always be aware that a TCP connection has been terminated. This would happen if the DSN became disabled prior to sending a FIN or Reset segment. Under these circumstances, SNA host resources remain allocated and a reconnection from a DSN, which the host believes to already be in session, is not allowed. By requiring the DSN to use the same port when reestablishing a connection, the LinkMaster 6200 is able to recognize when a reset of the host connection is required.
接続がいったん終えられると、新しい接続はConnection特権階級部で概説されたプロセスによって確立されるかもしれません。 LinkMaster6200ゲートウェイにされた再接続のために、開始ノードで同じUDPソースポートを使用しなければなりません。 これは、同じTCPポートが使用されているのを含意します。 この要件はゲートウェイがTCP接続が終えられたのをいつも意識しているかもしれないというわけではないという事実によります。 FINかResetセグメントを送る前にDSNが障害があるようになるなら、これは起こるでしょうに。 こういう事情ですから、SNAホストリソースは割り当てたままで残っています、そして、DSNからの再接続は許容されていません。(ホストはセッションのときに、既にいるとDSNを信じています)。 接続を回復させるときDSNが同じポートを使用するのを必要とすることによって、ホスト接続のリセットであるときに6200が認識できるLinkMasterが必要です。
Behl, Sterling & Teskey [Page 6] RFC 1538 Advanced SNA/IP October 1993
SNA/IP1993年10月に高度なBehl、英貨、およびTeskey[6ページ]RFC1538
3.3.4. Complete Session Data Flow
3.3.4. 完全なセッションデータフロー
Node 1 Node 2
ノード1ノード2
Logical Null XID ------------------------->
(UDP Datagram)
Logical Null XID ------------------------->
(UDP Datagram)
<------------------------ XID Request
(UDP Datagram)
Logical SNA XID -------------------------->
(UDP Datagram)
<------------------------ TCP SYN
(TCP Message)
TCP SYN ACK ----------------------------->
(TCP Message)
<------------------------ TCP SYN
(TCP Message)
論理的なヌルXID------------------------->(UDPデータグラム)の論理的なヌルXID------------------------->(UDPデータグラム)<。------------------------ XIDは(UDPデータグラム)論理的なSNA XIDを要求します。-------------------------->(UDPデータグラム)<。------------------------ TCP SYN(TCPメッセージ)TCP SYN ACK----------------------------->(TCPメッセージ)<。------------------------ TCP SYN(TCPメッセージ)
****************** Connection Established *******************
****************** 接続は*******************を設立しました。
<------------------------ SNA ACTPU
(TCP Message)
SNA ACTPU Response --------------------->
(TCP Message)
<------------------------ SNA ACTLU
(TCP Message)
SNA ACTLU Response --------------------->
(TCP Message)
.
.
.
<------------------------ TCP FIN
(TCP Message)
TCP FIN ACK ------------------------>
(TCP Message)
<------------------------ TCP ACK
(TCP Message)
<。------------------------ SNA ACTPU(TCPメッセージ)SNA ACTPU応答--------------------->(TCPメッセージ)<。------------------------ SNA ACTLU(TCPメッセージ)SNA ACTLU応答--------------------->(TCPメッセージ)… <。------------------------ TCPフィン(TCPメッセージ)TCPフィンACK------------------------>(TCPメッセージ)<。------------------------ TCP ACK(TCPメッセージ)
******************** Connection Closed *********************
******************** 閉じている接続*********************
Logical Null XID ----------------------->
(UDP Datagram)
.
.
.
.
論理的なヌルXID----------------------->(UDPデータグラム)…
Behl, Sterling & Teskey [Page 7] RFC 1538 Advanced SNA/IP October 1993
SNA/IP1993年10月に高度なBehl、英貨、およびTeskey[7ページ]RFC1538
3.3.5. State Transition Table for the Initiating Node
3.3.5. 開始ノードのための状態遷移テーブル
Transition State
Given State | No Conn | Null XID Sent | SNA XID Sent | Conn Estb
------------+---------+---------------+--------------+-----------
No | | Internal Act. | |
Connection | | Stimulus | |
| | ---> Sends | |
| | 1st Null XID | |
------------+---------+---------------+--------------+-----------
Null XID | | Internal | XID Request |
Sent | | Timer Event | Received |
| | ----> Resend | ----> Sends |
| | Null XID | SNA XID |
------------+---------+---------------+--------------+-----------
SNA XID | | Internal | SNA XID | Indication
Sent | | Timer Event | Received | that TCP
| | ----> Resend | ----> Send | connection
| | Null XID | SNA XID | is estb.
| | | |
------------+---------+---------------+--------------+-----------
Connection | Indica- | | | SNA
Established | tion | | | Session
| that | | | Data
| TCP conn| | |
| term. | | |
状態に与えられた変遷状態| コンがありません。| ヌルXIDは発信しました。| SNA XIDは発信しました。| コンEstb------------+---------+---------------+--------------+----------- いいえ| | 内部の条例。 | | 接続| | 刺激| | | | --->は発信します。| | | | 最初のヌルXID| | ------------+---------+---------------+--------------+----------- ヌルXID| | 内部| XID要求| 発信します。| | タイマイベント| 受信します。| | | ---->は再送します。| ---->は発信します。| | | ヌルXID| SNA XID| ------------+---------+---------------+--------------+----------- SNA XID| | 内部| SNA XID| 指示は発信しました。| | タイマイベント| 受信します。| そのTCP| | ---->は再送します。| ---->は発信します。| 接続| | ヌルXID| SNA XID| estbはそうですか? | | | | ------------+---------+---------------+--------------+----------- 接続| インディカ| | | 確立されたSNA| tion| | | セッション| それ| | | データ| TCPコン| | | | 用語。 | | |
A gateway state transition table is not provided here because the state transitions are dependent on the nature of the SNA host interface (3172 Channel Protocol, 3174 Channel Protocol, SDLC, etc.).
状態遷移がSNAホスト・インターフェース(3172年のChannelプロトコル、3174年のChannelプロトコル、SDLCなど)の自然に依存しているので、ゲートウェイ状態遷移テーブルはここに提供されません。
4. LLC to SNA/IP Conversion
4. SNA/IP変換へのLLC
The use of Advanced SNA/IP to convert conventional token ring- based SNA traffic to a routable form is both conceivable and practical. While interesting, a discussion of this application falls outside the context of this RFC. Very briefly, it can be said that an SNA/IP- based "subnet SNA gateway" application could do many of the things being discussed in the context of the DLSw specification [1].
従来のトークンリングに基づいているSNAトラフィックを発送可能フォームに変換するAdvanced SNA/IPの使用は、想像できて、かつ実用的です。 おもしろいのですが、このアプリケーションの議論はこのRFCの文脈をそらせます。 アプリケーションがことの多くができたそのベースのSNA/IP「サブネットSNAゲートウェイ」前述の存在がDLSw仕様[1]の文脈で議論されていたなら、非常に簡潔に、それはそうすることができます。
5. Performance
5. パフォーマンス
The performance of SNA sessions running over an SNA/IP connection will be affected by the bandwidth available on the network and by how much traffic is on the network. SNA/IP is poised to take full advantage of the prioritization and class of service enhancements promised in the next generation of IP. Today, SNA/IP can take
ネットワークで利用可能な帯域幅とどのくらいのトラフィックがネットワークにあるかによってSNA/IP接続をひくSNAセッションの性能は影響を受けるでしょう。 SNA/IPは、IPの次世代で約束されたサービス増進の優先順位づけとクラスを最大限に利用するために用意ができています。 今日、SNA/IPは取ることができます。
Behl, Sterling & Teskey [Page 8] RFC 1538 Advanced SNA/IP October 1993
SNA/IP1993年10月に高度なBehl、英貨、およびTeskey[8ページ]RFC1538
advantage of router packet prioritization schemes based on port number. SNA/IP also leaves intact the standard SNA class of service prioritization protocol.
ルータパケット優先順位づけ体系の利点はポートナンバーを基礎づけました。 また、SNA/IPはサービス優先順位づけプロトコルの標準のSNAのクラスを完全なままにします。
Performance measures taken at McDATA comparing the throughput of SNA/IP and LLC across a single token-ring segment showed approximately a 15 percent decrease in the maximum transactions per hour (1500 bytes to the DSN, 50 bytes out to the host) for SNA/IP. This decrease is well within the expected levels given the added processing requirements of TCP/IP over LLC in the LinkMaster 6200 and LinkMaster 7100 operating environments.
ただ一つのトークンリングセグメントの向こう側にSNA/IPに関するスループットを比較するMcDATAとLLCで実施されるパフォーマンス対策はSNA/IPのために毎時(DSNへの1500バイトと、ホストへの50バイト)の最大のトランザクションの15パーセントのおよそ減少を示しました。 LinkMaster6200とLinkMaster7100操作環境におけるLLCの上のTCP/IPの加えられた処理所要を考えて、予想水準のかなり中にこの減少はあります。
6. VTAM Definition
6. VTAM定義
The host VTAM definition of SNA/IP downstream nodes is dependent on the gateway implementation. Downstream nodes may appear as switched major nodes connected to an XCA or as downstream nodes connected to a PU 2.0 controller [4].
SNA/IPの川下のノードのホストVTAM定義はゲートウェイ実装に依存しています。 XCAか川下のノードがPU2.0コントローラ[4]に接したとき切り換えられた多重ノードが接続したので、川下のノードは現れるかもしれません。
7. Acknowledgments
7. 承認
The authors wish to acknowledge that the definition of SNA/IP was a collaborative effort involving many individuals ranging from customers to sales and marketing personnel to engineers. Particular thanks go to David Beal, Steve Cartwright, Tracey Floming, Audrey McEwen, Mark Platte, Paul Schroeder, Chuck Weil, and Marty Wright, who all played key roles in the development and testing of this protocol and also in the editing of this RFC.
作者は、SNA/IPの定義が顧客から営業人員まで技術者に及ぶ多くの個人にかかわる共同努力であったと認めたがっています。 特定の感謝はこのプロトコルの開発とテストとこのRFCの編集でも重要な役割をすべてプレーしたデヴィッド・ビール、スティーブCartwright、トレーシーFloming、オードリー・マキューエン、マーク・プラット、ポール・シュローダー、チャック・ウィル、およびマーティ・ライトのものになります。
8. References
8. 参照
[1] Dixon, R., and D. Kushi, "Data Link Switching: Switch-to-Switch
Protocol", RFC 1434, IBM, March 1993.
[1] ディクソン、R.、およびD.Kushi、「データは切り換えをリンクします」。 「スイッチからスイッチへのプロトコル」、RFC1434、IBM、1993年3月。
[2] "Token-Ring Network Architecture Reference", IBM document #SC30-
3374-02.
[2] 「トークンリングネットワークアーキテクチャ参照」、IBMドキュメント#SC30-3374-02。
[3] "Systems Network Architecture Formats", IBM document #GA27-3136-
12.
[3]「システム・ネットワーク体系形式」、IBMドキュメント#GA27-3136- 12。
[4] "VTAM Resource Definition Reference", IBM document #SC31-6438-1.
[4] 「VTAMリソース定義参照」、IBMドキュメント#SC31-6438-1。
[5] Comer, D., "Internetworking with TCP/IP Volume I", Prentice Hall
1991.
[5] 新来者、D.、「TCP/IPボリュームIがあるインターネットワーキング」、新米のホール1991。
[6] Postel, J., "Transmission Control Protocol - DARPA Internet
Program Protocol Specification", STD 7, RFC 793, USC/Information
Sciences Institute, September 1981.
[6] ポステル、J.、「転送管理は議定書を作ります--DARPAインターネットプログラムプロトコル仕様」、STD7、RFC793、科学が設けるUSC/情報、1981年9月。
Behl, Sterling & Teskey [Page 9] RFC 1538 Advanced SNA/IP October 1993
SNA/IP1993年10月に高度なBehl、英貨、およびTeskey[9ページ]RFC1538
9. Security Considerations
9. セキュリティ問題
This RFC does not address issues of security. SNA level security procedures and protocols apply when SNA/IP is used as the transport.
このRFCはセキュリティの問題を扱いません。 SNA/IPが輸送として使用されるとき、SNAレベルセキュリティ手順とプロトコルは適用されます。
10. Authors' Addresses
10. 作者のアドレス
Wilfred Behl 310 Interlocken Parkway Broomfield, Colorado 80021
Interlockenパークウェイのブルームフィールド、ウィルフレッドBehl310コロラド 80021
Phone: 303-460-4142 Email: wil@mcdata.com
以下に電話をしてください。 303-460-4142 メールしてください: wil@mcdata.com
Barbara Sterling 310 Interlocken Parkway Broomfield, Colorado 80021
バーバラSterling310Interlockenパークウェイのブルームフィールド、コロラド 80021
Phone: 303-460-4211 Email: bjs@mcdata.com
以下に電話をしてください。 303-460-4211 メールしてください: bjs@mcdata.com
William Teskey 2125 112th Ave. North East Suite 303 Bellevue, WA 98004
ウィリアムTeskey2125第112Ave。 ワシントン 東北Suite303ベルビュー、98004
Phone: 206-450-0650 Email: wct@ioc-sea.com
以下に電話をしてください。 206-450-0650 メールしてください: wct@ioc-sea.com
Note: Any questions or comments relative to the contents of this RFC should be sent to snaip@mcdata.com. This address will be used to coordinate the handling of responses.
以下に注意してください。 このRFCのコンテンツに比例したどんな質問やコメントも snaip@mcdata.com に送るべきです。 このアドレスは、応答の取り扱いを調整するのに使用されるでしょう。
11. Disclaimer
11. 注意書き
McDATA, the McDATA logo, and LinkMaster are registered trademarks of McDATA Corporation. All other product names and identifications are trademarks of their respective manufacturers, who are not affiliated with McDATA Corporation.
McDATA、McDATAロゴ、およびLinkMasterはMcDATA社の登録商標です。 他のすべての製品名と識別は彼らのそれぞれのメーカーの商標です。(そのメーカーは、McDATA社に所属しません)。
Behl, Sterling & Teskey [Page 10]
Behl、英貨、およびTeskey[10ページ]
一覧
スポンサーリンク
