RFC1613 日本語訳
1613 cisco Systems X.25 over TCP (XOT). J. Forster, G. Satz, G. Glick,R. Day. May 1994. (Format: TXT=29267 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Forster
Request for Comments: 1613 G. Satz
Category: Informational G. Glick
cisco Systems, Inc.
R. Day
JANET
May 1994
コメントを求めるワーキンググループJ.フォルスター要求をネットワークでつないでください: 1613年のG.サッツカテゴリ: 情報のG.グリックコクチマスSystems Inc.R.デージャネット1994年5月
cisco Systems X.25 over TCP (XOT)
TCPの上のコクチマスSystems X.25(XOT)
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Table of Contents
目次
1. Introduction....................................................1 2. Conventions.....................................................2 3. Relationship Between XOT and X.25...............................2 4. Overall Packet Format...........................................3 4.1 XOT Header....................................................4 5. TCP Connection, Port Number, and Logical Channel Numbers (LCNs).4 6. XOT Packets.....................................................5 6.1 Virtual Circuit Setup and Clearing............................5 6.2 Data and Flow Control.........................................6 6.3 Interrupt, and Reset Packets..................................8 6.4 Restart, DTE Reject, Diagnostics, and Registration............8 6.5 PVC Setup.....................................................8 7. Acknowledgments................................................12 8. Security Considerations........................................12 9. References.....................................................12 10. Authors' Addresses.............................................13
1. 序論…1 2. コンベンション…2 3. XOTとX.25との関係…2 4. 総合的なパケット・フォーマット…3 4.1XOTヘッダー…4 5. TCP接続は数、および論理チャネル番号(LCNs).4 6を移植してください。 XOTパケット…5 6.1 仮想の回路セットアップと開拓地…5 6.2のデータとフロー制御…6 6.3 中断してください、そして、パケットをリセットしてください…6.4が再開する8、DTE廃棄物、病気の特徴、および登録…8 6.5 PVCはセットアップします…8 7. 承認…12 8. セキュリティ問題…12 9. 参照…12 10. 作者のアドレス…13
1. Introduction
1. 序論
It is sometimes desirable to transport X.25 over IP internets. The X.25 Packet Level requires a reliable link level below it and normally uses LAPB. This memo documents a method of sending X.25 packets over IP internets by encapsulating the X.25 Packet Level in TCP packets.
IPインターネットの上でX.25を輸送するのは時々望ましいです。 X.25 Packet Levelはそれの下で信頼できるリンク・レベルを必要として、通常、LAPBを使用します。 このメモはIPインターネットの上でTCPパケットでX.25 Packet Levelをカプセル化することによってパケットをX.25に送るメソッドを記録します。
TCP provides a reliable byte stream. X.25 requires that the layer below it provide message semantics, in particular the boundary between packets. To provide this, a small (4-byte) XOT header is used between TCP and X.25. The primary content of this header is a
TCPは信頼できるバイト・ストリームを供給します。 X.25は、それの下の層がメッセージ意味論、特にパケットの間の境界を提供するのを必要とします。 これを提供するために、(4バイト)の小さいXOTヘッダーはTCPとX.25の間で使用されます。 このヘッダーのプライマリ内容はaです。
Forster, Satz, Glick & Day [Page 1] RFC 1613 X.25 Over TCP (XOT) May 1994
1994年のTCP(XOT)の上のRFC1613X.25がそうするフォルスター、サッツ、グリック、および日[1ページ]
length field, which is used to separate the X.25 packets within the TCP stream.
長さの分野。(その分野は、TCPストリームの中でX.25パケットを分離するのに使用されます)。
In general, the normal X.25 protocol packet formats and state transition rules apply to the X.25 layer in XOT. Exceptions to this are noted.
一般に、正常なX.25プロトコルパケット・フォーマットと状態遷移規則はXOTのX.25層に適用されます。 これへの例外は注意されます。
2. Conventions
2. コンベンション
The following language conventions are used in the items of specification in this document:
以下の言語コンベンションは仕様に関する条項で本書では使用されます:
o MUST, SHALL, or MANDATORY -- This item is an absolute
requirement of the specification.
o SHALL、MANDATORY--この項目は仕様に関する絶対条件であるに違いありません。
o SHOULD or RECOMMEND -- This item should generally be followed
for all but exceptional circumstances.
o SHOULDかRECOMMEND--一般に、この商品はほとんど例外的な事情のために従われるべきです。
o MAY or OPTIONAL -- This item is truly optional and may be
followed or ignored according to the needs of the implementor.
o 5月かOPTIONAL--作成者の必要性に従って、この商品は、本当に、任意であり、従われているか、または無視されるかもしれません。
In some places in this document, there is parenthetical material labeled "DISCUSSION". This material is intended to give clarification and explanation of the preceding text.
このドキュメントには、所々、「議論」とラベルされた挿入句の材料があります。 この材料が前のテキストに関する明確化と説明をすることを意図します。
3. Relationship Between XOT and X.25
3. XOTとX.25との関係
When a networking device (a host, router, etc.) has an X.25 engine (i.e., protocol implementation), that engine may be connected to interface(s) running LAPB, and/or to logical interface(s) running LLC or XOT/TCP/IP. In general, the XOT layer itself is not at all sensitive to what kind of packets the X.25 engine passes to it. However, to improve interoperability between separate implementations, this document in some cases does specify behavior of the X.25 engine.
ネットワークデバイス(ホスト、ルータなど)にX.25エンジン(すなわち、プロトコル実装)があると、そのエンジンは、LAPBを実行する、そして/または、LLCかXOT/TCP/IPを論理的なインタフェースに実行しながら(s)を連結するように接続されるかもしれません。 一般に、XOT層自体はX.25エンジンがどういうパケットをそれに通過するかに全く敏感ではありません。 しかしながら、いくつかの場合、別々の実装の間の相互運用性を改良するために、このドキュメントはX.25エンジンの働きを指定します。
While this document primarily discusses XOT from the perspective of switching X.25 traffic (i.e., connecting an X.25 Virtual Circuit between the local X.25 interfaces of two networking devices), this should not prevent a host from offering X.25 connectivity using XOT.
このドキュメントが切り換えX.25トラフィック(すなわち、2台のネットワークデバイスの地方のX.25インタフェースの間のX.25 Virtual Circuitを接続する)の見解からXOTについて主として議論している間、これによって、ホストはXOTを使用することでX.25の接続性を提供できないべきではありません。
The various X.25 standards may call a given packet type by a different name according to the assigned DTE/DCE role of the interface that originated the packet. XOT is intended to be insensitive to the DTE/DCE role of the local interfaces at either end of an XOT TCP connection, so, for this document, the following terms are interchangeable unless stated otherwise:
パケットを溯源したインタフェースの割り当てられたDTE/DCEの役割に従って、様々なX.25規格は異なった名前で与えられたパケットタイプを呼ぶかもしれません。 XOTがXOT TCP接続のどちらかの終わりに局所界面のDTE/DCEの役割に神経が鈍いことを意図するので、別の方法で述べられない場合、このドキュメントに関して、次の用語は交換可能です:
Forster, Satz, Glick & Day [Page 2] RFC 1613 X.25 Over TCP (XOT) May 1994
1994年のTCP(XOT)の上のRFC1613X.25がそうするフォルスター、サッツ、グリック、および日[2ページ]
o Call, Call Request and Incoming Call
o Call Confirm, Call Accepted and Call Connected
o Clear, Clear Request and Clear Indication
o Clear Confirm, DTE Clear Confirmation and DCE Clear Confirmation
o Data, DTE Data and DCE Data
o Interrupt, DTE Interrupt and DCE Interrupt
o Interrupt Confirm, DTE Interrupt Confirmation and
DCE Interrupt Confirmation
o RR, DTE RR and DCE RR
o RNR, DTE RNR and DCE RNR
o REJ, Reject and DTE REJ
o Reset, Reset Request and Reset Indication
o Reset Confirm, DTE Reset Confirmation and DCE Reset Confirmation
o Restart, Restart Request and Restart Indication
o Restart Confirm, DTE Restart Confirmation and
DCE Restart Confirmation
o Incoming Call oのCall Connected oのClear Indication oのDCE Clear Confirmation oのDCE Data oのDCE Interrupt oの呼び出し、Call Request、Call Confirm、Call Accepted、Clear、Clear Request、Clear Confirm、DTE Clear Confirmation、Data、DTE Data、Interrupt、DTE Interrupt、Interrupt Confirm、DTE Interrupt Confirmation、およびDCE Interrupt Confirmation o RR; DCE RR oのDCE RNR oのDTE REJ oのReset Indication oのDCE Reset Confirmation oのRestart Indication oのDTE RR、RNR、DTE RNR、REJ、Reject、Reset、Reset Request、Reset Confirm、DTE Reset Confirmation、Restart、Restart Request、Restart Confirm、DTE Restart Confirmation、およびDCE Restart Confirmation
4. Overall Packet Format
4. 総合的なパケット・フォーマット
The entire encapsulated packet has the following format:
全体のカプセル化されたパケットには、以下の形式があります:
---------------------------------
| |
| IP Header |
| |
---------------------------------
| |
| TCP Header |
| |
---------------------------------
| |
| XOT Header |
| |
---------------------------------
| |
| X.25 Packet |
| |
---------------------------------
--------------------------------- | | | IPヘッダー| | | --------------------------------- | | | TCPヘッダー| | | --------------------------------- | | | XOTヘッダー| | | --------------------------------- | | | X.25パケット| | | ---------------------------------
RFC convention is that a packet format is represented graphically with the data sent first above the data sent later. This convention is followed in this document, and therefore, while we refer to X.25 being transported over TCP, we draw the packet format with the X.25 portion of the packet lower on the page than the TCP portion.
RFCコンベンションはパケット・フォーマットがグラフィカルに最初に、後で送られたデータの上にデータを送って表されるということです。 このコンベンションは本書では続かれています、そして、したがって、TCPの上で輸送されるX.25について言及している間、私たちはTCP部分よりページで低くパケットのX.25部分があるパケット・フォーマットを描きます。
Forster, Satz, Glick & Day [Page 3] RFC 1613 X.25 Over TCP (XOT) May 1994
1994年のTCP(XOT)の上のRFC1613X.25がそうするフォルスター、サッツ、グリック、および日[3ページ]
4.1 XOT Header
4.1 XOTヘッダー
The XOT header has the format:
XOTヘッダーには、形式があります:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バージョン| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version (2 octets)
バージョン(2つの八重奏)
The version number of the XOT protocol is encoded in the first
two octets. The version number MUST be 0. Other values of
this field are reserved for future use. If a value other than
0 is received, then the TCP connection MUST be closed.
XOTプロトコルのバージョン番号は最初の2つの八重奏でコード化されます。 バージョン番号は0であるに違いありません。 この分野の他の値は今後の使用のために予約されます。 0以外の値が受け取られているなら、TCP接続は閉店しなければなりません。
Length (2 octets)
長さ(2つの八重奏)
The length of the X.25 packet is encoded in the second two
octets. Values must be legal X.25 packet lengths. If the
Length field has an illegal value, then the TCP connection MUST
be closed.
X.25パケットの長さは2番目の2つの八重奏でコード化されます。 値は法的なX.25パケット長でなければなりません。 Length分野に不法な値があるなら、TCP接続は閉店しなければなりません。
5. TCP Connection, Port Number, and Logical Channel Numbers (LCNs)
5. TCP接続、ポートナンバー、および論理チャネル番号(LCNs)
A separate TCP connection MUST be used for each X.25 virtual circuit. All connections MUST be made to TCP port number 1998. This port number is an IANA Registered Port Number registered by cisco Systems; cisco has designated it for use by XOT.
それぞれのX.25の仮想の回路に別々のTCP接続を使用しなければなりません。 すべての接続をTCPポートNo.1998まで作らなければなりません。 このポートナンバーはコクチマスSystemsによって登録されたIANA Registered Port Numberです。 コクチマスはXOTによる使用のためにそれを指定しました。
The TCP connection MUST be created before the virtual circuit can be established. The TCP connection MAY be maintained after the virtual circuit has been cleared. Data MUST NOT be passed along with the TCP SYN packet.
仮想の回路を確立できる前にTCP接続を創造しなければなりません。 仮想の回路がきれいにされた後にTCP接続は維持されるかもしれません。 TCP SYNパケットと共にデータを通過してはいけません。
The Logical Channel Number (LCN) field in the X.25 header has no significance and has arbitrary values. A corollary of this is that there is no assignment of one side of the connection to be DTE and another to be DCE.
X.25ヘッダーのLogical Channel Number(LCN)分野は、意味を全く持っていなくて、任意の値を持っています。 この推論はDCEであるDTEと別のものになるように接続の半面の課題が全くないということです。
DISCUSSION
議論
Consider three devices A, B and C, where A and B both conduct XOT
sessions to C. It's possible that C could receive two calls with
the same LCN and, unless the X.25 engine could tell that they were
received on different logical (XOT) interfaces, here would a
danger of call collision (indeed a valid LCN on one interface may
3台のデバイスがAであると考えてください、B、C(AとBはXOTセッションを同じLCNとのCが受信されることができたのが可能なC.Itの2つの呼び出しまで行って、X.25エンジンがそれを言うことができなかったなら、それらはここに異なった論理的な(XOT)インタフェースに受け取られた)がBであるだろう、呼び出し衝突という危険、(本当に1つのインタフェースの有効なLCNはそうするかもしれません。
Forster, Satz, Glick & Day [Page 4] RFC 1613 X.25 Over TCP (XOT) May 1994
1994年のTCP(XOT)の上のRFC1613X.25がそうするフォルスター、サッツ、グリック、および日[4ページ]
not even be valid on a different interface). It is therefore
necessary for C's X.25 engine to distinguish between the two
streams, but the LCN field is not sufficient to do this. The XOT
protocol design decision was to expect the XOT layer to
communicate the stream identification to the X.25 layer.
異なったインタフェースで有効でさえない、) したがって、CのX.25エンジンが2つのストリームを見分けるのが必要ですが、LCN分野は、これをするために十分ではありません。 XOTプロトコルデザイン決定はXOT層がストリーム識別をX.25層に伝えると予想することでした。
6. XOT Packets
6. XOTパケット
For each X.25 packet received from the TCP connection to be sent out a local interface, an XOT implementation MUST set the packet's logical channel number to that used on the outgoing interface. For the purposes of this RFC, a logical channel number is the 12 bit field confusingly defined by the X.25 Recommendations as the high- order 4 bit "logical channel group number" and low-order 8 bit "logical channel number", where the latter phrase is used to refer to both the aggregated 12 bits and the low-order 8 bits.
出して、局所界面、XOT実装がセットしなければならないということになるようにTCP接続から受け取られたそれぞれのX.25パケットに関しては、外向的で使用されるそれへのパケットの論理チャネル番号は連結します。 このRFCの目的のために、高いオーダー4が「論理チャネルグループ番号」と下位の8ビット「論理チャネル番号」(後者の句は集められた12ビットと下位の8ビットの両方について言及するのに使用される)に噛み付いたので、論理チャネル番号はX.25 Recommendationsによって紛らわしく定義された12ビットの分野です。
An XOT implementation SHOULD NOT modify the X.25 packet header information received on a local interface to be transmitted over the TCP connection.
TCP接続の上に伝えられて、SHOULD NOTが局所界面に受け取られたX.25パケットヘッダー情報を変更するXOT実装。
An XOT implementation MUST modify the X.25 packet header information as required for proper X.25 protocol operation for packets received on a TCP connection to be transmitted over a local interface.
XOT実装は局所界面の上に伝えられるためにTCP接続の上に受け取られたパケットのための適切なX.25プロトコル操作のために必要に応じてX.25パケットヘッダー情報を変更しなければなりません。
An XOT implementation MAY support connection between interfaces that use different flow control modulos. If this feature is supported, XOT MUST modify the packet General Format Identifier on all packets received over the TCP connection to set the proper modulus identifier.
XOT実装は異なったフロー制御法を使用するインタフェースの間の接続をサポートするかもしれません。 この特徴がサポートされるなら、XOT MUSTは適切な係数識別子を設定するためにTCP接続の上に受け取られたすべてのパケットでパケットの司令官のFormat Identifierを変更します。
6.1 Virtual Circuit Setup and Clearing
6.1 仮想の回路セットアップと開拓地
Once a TCP connection has been established, the X.25 Call packet is sent by the XOT that initiated the TCP connection. Eventually a Call Confirm or Clear packet is received, or the X.25 T11/T21 timeout occurs or the XOT TCP connection is closed. The usual X.25 state transitions are followed.
TCP接続がいったん確立されると、X.25 CallパケットはTCP接続を開始したXOTによって送られます。 結局、Call ConfirmかClearパケットが受け取られているか、X.25 T11/T21タイムアウトが起こるか、またはXOT TCP接続は閉じられます。 普通のX.25状態遷移は続かれています。
Any legal X.25 facilities from the family of X.25 protocols (including but not limited to the 1980, 1984 and 1988 CCITT X.25 Recommendations) MAY be included in the Call, Call Confirm and Clear packets. Receipt of an unknown or unsupported X.25 facility received from the TCP connection SHOULD be ignored (i.e., not presented in the packet sent out the local interface) or treated as an error as defined by the X.25 standard implemented.
X.25プロトコルのファミリーからのどんな法的なX.25施設、も(他を含んでいる、1980、1984と1988CCITT X.25 Recommendations) Call、Call Confirm、およびClearパケットに含まれるかもしれません。 未知の、または、サポートされないX.25施設の領収書は無視されたか(すなわち、提示されないで、パケットでは、局所界面は出されていました)、またはX.25によって定義される誤りとして扱われた規格が実装したTCP接続SHOULDから受信されました。
Forster, Satz, Glick & Day [Page 5] RFC 1613 X.25 Over TCP (XOT) May 1994
1994年のTCP(XOT)の上のRFC1613X.25がそうするフォルスター、サッツ、グリック、および日[5ページ]
To simplify end-to-end flow control, the packet size and window size are always sent explicitly as facilities in the Call packet. The Call packet MUST contain both Packet Size and Window Size facilities. The Call Confirm packet MAY contain these facilities. The handling of a Call received over a TCP connection that does not encode one or both of the flow control facilities is a local matter--if the XOT accepts such a Call, it MUST encode the missing flow control facility values that apply to the connection in the returned Call Confirm packet.
終わりから終わりへのフロー制御を簡素化するために、施設としてCallパケットでいつも明らかにパケットサイズとウィンドウサイズを送ります。 CallパケットはPacket SizeとWindow Size施設の両方を含まなければなりません。 Call Confirmパケットはこれらの施設を含むかもしれません。 XOTがそのようなCallを受け入れるので返されたCall Confirmパケットでの接続に適用されるなくなったフロー制御施設値をコード化しなければならないなら、フロー制御施設の1か両方をコード化しないTCP接続の上に受け取られたCallの取り扱いは地域にかかわる事柄です。
DISCUSSION
議論
X.25 interfaces normally have a concept of network default values
for packet size and window size. It was thought that when
connecting diverse sites over a TCP/IP network this concept would
be difficult to achieve in practice. If there is no network
default, then each call must state the packet size and window
size. This is the reason for requiring the packet size and window
size facilities. It is expected that this can be achieved either
by the XOT layer itself, or by configuring the X.25 engine such
that there no network default on this interface.
X.25インタフェースには、通常、パケットサイズとウィンドウサイズのためのネットワークデフォルト値の概念があります。 それはTCP/IPの上の接続のさまざまのサイトがこの概念をネットワークでつなぐとき実際には達成するのが難しい考えでした。 ネットワークデフォルトが全くなければ、各呼び出しはパケットサイズとウィンドウサイズを述べなければなりません。 これはパケットサイズとウィンドウサイズ施設を必要とする理由です。 XOT層自体、またはX.25エンジンを構成することによってこれを達成できると予想されて、どんなネットワークもそこでこのインタフェースを怠りません。
After sending a Clear the TCP connection MAY be closed immediately without waiting for the Clear Confirm. A Clear Confirm received on the TCP connection MAY be silently discarded.
Clearを送った後に、すぐClear Confirmを待たないで、TCP接続は閉店するかもしれません。 TCP接続のときに受け取られたClear Confirmは静かに捨てられるかもしれません。
A packet with an invalid X.25 Packet Type Identifier (PTI) received over the TCP connection before a Call has been received (i.e., while in the P1 state) MUST be silently discarded.
Callを受け取る(すなわちP1状態で)前に静かに無効のX.25 Packet Type Identifier(PTI)をTCP接続の上に受け取っているパケットを捨てなければなりません。
6.2 Data and Flow Control
6.2のデータとフロー制御
DISCUSSION
議論
The implementation of X.25 flow control is a local matter, but
different implementation choices affect XOT behavior.
X.25フロー制御の実装は地域にかかわる事柄ですが、異なった実装選択はXOTの振舞いに影響します。
An XOT implementation may implement either end-to-end flow
control, where DATA, RR and RNR packets are sent over the TCP
connection as received over the local interface, or local flow
control, where flow control packets (RR, RNR and, if supported,
REJ) are sent on a VC according to local criteria, a complete
packet sequence of DATA packets may be fragmented or combined, and
data packet numbering normally has only local DTE-DCE
significance.
XOT実装は、終わりから終わりへのフロー制御か局所流のどちらかがコントロールであると実装するかもしれません、地方の評価基準に応じてフロー制御パケット(RR、RNR、およびサポートされるときのREJ)をVCに送って、DATAパケットの完全なパケット系列が断片化されるか、または結合されるかもしれなくて、通常、データ・パケット付番にはローカルのDTE-DCE意味しかないところで。そこでは、DATA、RR、およびRNRパケットが局所界面の上に受け取るようにTCP接続の上に送られます。
Existing implementations of XOT perform end-to-end flow control.
Data and flow control packets are simply transferred between the
XOTの既存の実装は終わりから終わりへのフロー制御を実行します。 単にデータとフロー制御パケットを移します。
Forster, Satz, Glick & Day [Page 6] RFC 1613 X.25 Over TCP (XOT) May 1994
1994年のTCP(XOT)の上のRFC1613X.25がそうするフォルスター、サッツ、グリック、および日[6ページ]
two local interfaces via the TCP connection, adjusting the X.25
header data as necessary for mixed modulo operation. This does
not preclude an XOT implementation that performs local flow
control, but interoperability requires that a local flow control
implementation conduct the XOT session such that a connecting
end-to-end flow control implementation receives Data packets of
the proper size and flow control fields with appropriate P(S) and
P(R) values.
複雑な法操作に必要に応じてX.25ヘッダー・データを調整するTCP接続を通した2つの局所界面。 これが局所流コントロールを実行するXOT実装を排除しませんが、相互運用性が、局所流コントロール実装がXOTセッションを行うのを必要とするので、接続終わりから終わりへのフロー制御実装は適切なP(S)とP(R)値で適切なサイズとフロー制御分野のDataパケットを受けます。
An X.25 implementation that performs local flow control similarly
may set up a Call between two local interfaces where each logical
channel has its own packet and window sizes and Data packets must
be fragmented or collected between the interfaces and each
interface manages distinct packet sequence numbers; XOT operation
is simply an extension to this operation as a VC is connected
between the local interface and an XOT/TCP virtual interface, each
of which have distinct window and packet sizes.
同様に局所流コントロールを実行するX.25実装は各論理チャネルがそれ自身のパケットを持っている2つの局所界面の間のCallをセットアップするかもしれません、そして、インタフェースの間にウィンドウサイズとDataパケットを断片化されなければならないか、または集めなければなりません、そして、各インタフェースは異なったパケット一連番号を管理します。 VCが局所界面とXOT/TCP仮想インターフェースの間で接続されるとき、XOT操作は単にこの操作への拡大です。それのそれぞれには、異なった窓とパケットサイズが仮想インターフェースのためにあります。
An XOT that implements local flow control MUST send data packet acknowledgements across the TCP connection for the DATA packets it receives from the TCP connection, using the received packet numbers, and MUST observe the maximum packet sizes agreed to across the TCP connection.
局所流がコントロールであると実装するXOTは容認されたパケット番号を使用して、それがTCP接続から受けるDATAパケットのためのTCP接続の向こう側にデータ・パケット承認を送らなければならなくて、最大のTCP接続に同意するパケットサイズを観測しなければなりません。
An XOT implementation MUST NOT assume that an RNR sent across the TCP connection will stop the flow of DATA packets in the other direction. An RNR packet received from the TCP connection MAY cause an RNR packet to be sent across the local interface; end-to-end flow control implementations MAY communicate the P(R) in an RNR packet received from the TCP connection by sending an RR packet on the local interface.
XOT実装は、TCP接続の向こう側に送られたRNRがもう片方の方向のDATAパケットの流れを止めると仮定してはいけません。 TCP接続から受け取られたRNRパケットで、局所界面の向こう側にRNRパケットを送るかもしれません。 終わりから終わりへのフロー制御実装は、TCP接続から受け取られたRNRパケットでRRパケットを局所界面に送ることによって、P(R)を伝えるかもしれません。
An XOT implementation that allows mixed-modulo connections and implements end-to-end flow control MUST intervene in the window size negotiation process when a modulo 128 Call Request proposes a window size of 8 or larger to an XOT connection that serves a modulo 8 interface. The intervention MUST either refuse the connection or lower the too-large window size(s) to a value valid for the interface and indicate the final result of the window size negotiation process in the Call Confirm packet returned over the TCP connection.
複雑な法接続と法であるときに終わりから終わりへのフロー制御がウィンドウサイズ交渉プロセスで介入しなければならない道具に128Call Requestを許容するXOT実装は8のウィンドウサイズを提案します。8インタフェースに法に勤めるXOT接続において、より大きいです。 介入は、接続を拒否しなければならないか、また、大きいウィンドウサイズをインタフェースに、有効な値に下ろして、またはTCP接続の上に返されたCall Confirmパケットでウィンドウサイズ交渉プロセスの最終的な結果を示さなければなりません。
For any type of flow control implementation that supports mixed modulo connections, both cooperating XOTs MUST interpret the the P(S) and P(R) values received from the TCP connection and perform any flow control operation appropriate for correct X.25 operation of the local interface. End-to-end flow control implementations MUST translate between the two modulos and construct the analogous X.25 header P(S) and P(R) fields for DATA, RR and RNR packets.
複雑な法が接続であるとサポートするどんなタイプのフロー制御実装のためにも、ともに協力関係を持っているXOTsは値がTCP接続から受けたP(S)とP(R)を解釈して、局所界面の正しいX.25操作に、適切などんなフロー制御操作も実行しなければなりません。 終わりから終わりへのフロー制御実装は2個の法と構造物の間で類似のX.25ヘッダーP(S)を翻訳しなければなりません、そして、P(R)はDATA、RR、およびRNRのためにパケットをさばきます。
Forster, Satz, Glick & Day [Page 7] RFC 1613 X.25 Over TCP (XOT) May 1994
1994年のTCP(XOT)の上のRFC1613X.25がそうするフォルスター、サッツ、グリック、および日[7ページ]
An XOT implementation MAY support connecting two XOT TCP sessions to each other. If this feature is supported, XOT MUST simply connect the two TCP sessions without modifying the data passed.
XOT実装は互いに2つのXOT TCPセッションを接続にサポートするかもしれません。 この特徴がサポートされるなら、XOT MUSTは単に、データを変更することのないセッションが渡した2TCPを接続します。
6.3 Interrupt, and Reset Packets
6.3 中断、およびリセットパケット
Interrupt, Interrupt Confirm, Reset and Reset Confirm packets are sent over the TCP connection using the normal X.25 packet formats and state transitions. The end-to-end nature of both the Interrupt and Reset services MUST be maintained for correct X.25 operation.
正常なX.25パケット・フォーマットを使用することでInterrupt Confirm、Reset、およびReset ConfirmパケットをTCP接続の上に送ります、そして、中断してください、そして、状態は移行します。 正しいX.25操作のために終わりから終わりへのInterruptとResetサービスの両方の自然を維持しなければなりません。
6.4 Restart, DTE Reject, Diagnostics, and Registration
6.4 再開、DTE廃棄物、病気の特徴、および登録
X.25 packets that have only a local DTE/DCE interface significance (Restart, Restart Confirm, DTE Reject, Diagnostic, Registration Request and Registration Confirmation) MUST NOT be sent over the TCP connection. If one of these packets is received, then it MUST be silently discarded.
ローカルのDTE/DCEインタフェース意味(再開、Restart Confirm、DTE Reject、Diagnostic、Registration Request、およびRegistration Confirmation)しか持っていないX.25パケットをTCP接続の上に送ってはいけません。 これらのパケットの1つが受け取られているなら、静かにそれを捨てなければなりません。
6.5 PVC Setup
6.5 PVCセットアップ
An XOT implementation MAY support connecting a PVC via XOT.
XOT実装は、XOTを通して接続がPVCであるとサポートするかもしれません。
DISCUSSION
議論
X.25 PVCs are Virtual Circuits that are presumed to be available
when the X.25 service is available (i.e., in the R1 state).
Connecting a PVC via XOT is complicated because no Call, Call
Confirm, Clear or Clear Confirm packets are transferred (or
allowed) across the X.25 interface--PVCs are simply available
because they have been provisioned by the network provider as
contracted for by the network users.
X.25 PVCsはX.25サービスが利用可能であるときに(すなわち、R1状態の)あえて利用可能であるVirtual Circuitsです。 XOTを通してPVCを接続するのはX.25インタフェースの向こう側にどんなCall、Call Confirm、ClearもまたはClear Confirmパケットも移さないので(または、許容されています)、複雑です--ネットワーク利用者によって請け負われるように彼らがネットワーク内の提供者によって食糧を供給されたので、PVCsは単に利用可能です。
Supporting a PVC using XOT requires a data exchange between the
XOT entities that is outside the scope of the X.25 standards, and
must provide for a number of error conditions.
XOTを使用することでPVCをサポートするのはX.25規格の範囲の外にあって、多くのエラー条件に備えなければならないXOT実体の間のデータ交換を必要とします。
The setup of a PVC between two XOT entities is performed by exchanging a non-standard X.25 packet type (encapsulated in an XOT Header); the PVC setup exchange takes place immediately after a new TCP XOT connection has been established. The XOT implementation that initiated the TCP connection is the initiator; the other XOT is the responder.
2つのXOT実体の間のPVCのセットアップは標準的でないX.25パケットタイプ(XOT Headerでは、要約する)を交換することによって、実行されます。 新しいTCP XOT接続が確立された直後PVCセットアップ交換は起こります。 TCP接続を開始したXOT実装は創始者です。 もう片方のXOTは応答者です。
Forster, Satz, Glick & Day [Page 8] RFC 1613 X.25 Over TCP (XOT) May 1994
1994年のTCP(XOT)の上のRFC1613X.25がそうするフォルスター、サッツ、グリック、および日[8ページ]
The PVC Setup packet includes the X.25 General Format Identifier, LCN and Packet Type Identifier fields followed by additional data. This non-standard packet type takes the form:
PVC SetupパケットはX.25Format Identifier司令官、LCN、およびPacket Type Identifier分野を含んでいます、続いて、追加データを含んでいます。 この標準的でないパケットタイプは形を取ります:
+--+--+--+--+--+--+--+--+--+ | X.25 GFI | X.25 LCN | +--+--+--+--+ + | | +--+--+--+--+--+--+--+--+--+ | X.25 PTI | PVC setup PTI (= 0xF5) +--+--+--+--+--+--+--+--+--+ | | version (= 0x81) +--+--+--+--+--+--+--+--+--+ | | status +--+--+--+--+--+--+--+--+--+ | | initiator interface name length (N) +--+--+--+--+--+--+--+--+--+ | | initiator LCN (high octet) +--+--+--+--+--+--+--+--+--+ | | initiator LCN (low octet) +--+--+--+--+--+--+--+--+--+ | | responder interface name length (M) +--+--+--+--+--+--+--+--+--+ | | responder LCN (high octet) +--+--+--+--+--+--+--+--+--+ | | responder LCN (low octet) +--+--+--+--+--+--+--+--+--+ | | sender incoming window +--+--+--+--+--+--+--+--+--+ | | sender outgoing window +--+--+--+--+--+--+--+--+--+ | | sender incoming max. packet size +--+--+--+--+--+--+--+--+--+ | | sender outgoing max. packet size +--+--+--+--+--+--+--+--+--+ | | initiator interface name (N octets) | | +--+--+--+--+--+--+--+--+--+ | | responder interface name (M octets) | | +--+--+--+--+--+--+--+--+--+
+--+--+--+--+--+--+--+--+--+ | X.25 GFI| X.25 LCN| +--+--+--+--+ + | | +--+--+--+--+--+--+--+--+--+ | X.25 PTI| PVCセットアップPTI(0xF5と等しい)+--+--+--+--+--+--+--+--+--+| | バージョン(=0x81)+--+--+--+--+--+--+--+--+--+| | 状態+--+--+--+--+--+--+--+--+--+| | 創始者インタフェース名長さ(N)+--+--+--+--+--+--+--+--+--+| | 創始者LCN(高い八重奏)+--+--+--+--+--+--+--+--+--+| | 創始者LCN(低い八重奏)+--+--+--+--+--+--+--+--+--+| | 応答者インタフェース名長さ(M)+--+--+--+--+--+--+--+--+--+| | 応答者LCN(高い八重奏)+--+--+--+--+--+--+--+--+--+| | 応答者LCN(低い八重奏)+--+--+--+--+--+--+--+--+--+| | 送付者の入って来る窓+--+--+--+--+--+--+--+--+--+| | 送付者の出発している窓+--+--+--+--+--+--+--+--+--+| | 送付者の入って来る最大パケットサイズ+--+--+--+--+--+--+--+--+--+| | 送付者の外向的な最大パケットサイズ+--+--+--+--+--+--+--+--+--+| | 創始者インタフェース名(N八重奏)| | +--+--+--+--+--+--+--+--+--+ | | 応答者インタフェース名(M八重奏)| | +--+--+--+--+--+--+--+--+--+
DISCUSSION
議論
The PVC setup packet was designed so that the responder could
simply modify a few fields of the received packet and send it back
to the initiator.
PVCセットアップパケットは、応答者が単に容認されたパケットのいくつかの分野を変更して、それを創始者に送り返すことができるように、設計されました。
Forster, Satz, Glick & Day [Page 9] RFC 1613 X.25 Over TCP (XOT) May 1994
1994年のTCP(XOT)の上のRFC1613X.25がそうするフォルスター、サッツ、グリック、および日[9ページ]
The Packet Type Identifier was chosen from the unused X.25 PTI
values so it is distinct from the standard X.25 Packet Type
Identifiers.
Packet Type Identifierが未使用のX.25 PTI値から選ばれたので、それは標準のX.25 Packet Type Identifiersと異なっています。
The PVC setup version value was chosen to prevent connections with
prior experimental implementations.
PVCセットアップバージョン価値は、先の実験的な実装との関係を防ぐために選ばれました。
The PVC status field has the following values defined:
PVC状態分野には、定義された以下の値があります:
Status Meaning
------ --------------------------------------
0x00 Waiting to connect
状態意味------ -------------------------------------- 0×00 接続するのを待つこと。
0x08 Destination disconnected
0x09 PVC/TCP connection refused
0x0A PVC/TCP routing error
0x0B PVC/TCP connect timed out
外で調節された0x0B PVC/TCPが接続する0x0A PVC/TCPルーティング誤りが拒否された0×09PVC/TCP接続であると切断された0×08の目的地
0x10 Trying to connect via TCP
0x11 Awaiting PVC-SETUP reply
0x12 Connected
0x13 No such destination interface
0x14 Destination interface is not up
0x15 Non-X.25 destination interface
0x16 No such destination PVC
0x17 Destination PVC configuration mismatch
0x18 Mismatched flow control values
0x19 Can't support flow control values
0x1A PVC setup protocol error
0×10 TCP0x11Awaiting PVC-SETUPを通して接続しようとして、そのような目的地のインタフェース0x14Destinationが連結する回答0×12Connected0x13ノー、はどんなそのような0×16の目的地PVC0x17Destination PVC構成ミスマッチ0x18Mismatchedフロー制御も評価しない0×15Non-X.25目的地のインタフェースに、0×19Canが、フロー制御値が0x1A PVCセットアッププロトコル誤りであるとサポートしないということではありません。
DISCUSSION
議論
Not all of the PVC status values are appropriate for a PVC setup
packet; these values represent a particular implementation that
chose to assign values in three groups that correspond to a short
timer for a connect attempt (0x00 through 0x07), a long timer for
a connect attempt (0x08 through 0x0F) and no attempt to connect
(greater than 0x0F). The values that are appropriate for a PVC
setup packet are 0x00 and those values greater than 0x12.
PVCセットアップパケットに、PVC状態値のすべてが適切であるというわけではありません。 これらの値はaが試み(0×00から0×07)を接続するので短いタイマに一致している3つのグループで値を割り当てるのを選んだ特定の実装を表して、試み(0x0Fを通した0×08)を接続しますが、aのための長いタイマは接続するどんな試み(0x0Fよりすばらしい)も接続しません。 PVCセットアップパケットに、適切な値は、0×00とそれらの値より多くの0x12です。
Most of the PVC status error values that may be found in a setup
message are self-explanatory, with a few exceptions. The value
0x17, "Destination PVC configuration mismatch" may returned in the
case that the targeted PVC already has an XOT PVC connection
active. The value 0x19, "Can't support flow control values", may
be returned when the flow control values match but, for instance,
a modulo 8 interface is requested to set up a PVC with a window
size greater than 7 or an interface is requested to set up a PVC
セットアップメッセージで見つけられるかもしれないPVC状態誤り値の大部分は自明です、若干の例外はあるものの。 狙っているPVCが既にXOT PVC接続をアクティブにして、0×17、「目的地PVC構成ミスマッチ」がそうする値は戻りました。 フロー制御値が合っていると、「フロー制御値をサポートすることができない」という値0x19を返すかもしれませんが、例えば、PVCに設定してください7以上かインタフェースが要求されているウィンドウサイズでPVCをセットアップするよう法8インタフェースを要求します。
Forster, Satz, Glick & Day [Page 10] RFC 1613 X.25 Over TCP (XOT) May 1994
1994年のTCP(XOT)の上のRFC1613X.25がそうするフォルスター、サッツ、グリック、および日[10ページ]
with a maximum packet size that is too large for its data link
layer to transfer.
最大のパケットサイズで、それはデータ・リンク層が移されることができないくらい大きいです。
An XOT MAY retry a failed PVC setup; if implemented the XOT SHOULD wait between attempts (5 minutes is suggested).
XOT MAYは失敗したPVCセットアップを再試行します。 XOT SHOULDであると実装されるなら、試みの間で待ってください(5分は示されます)。
Each XOT PVC is configured with the identity of the other XOT (i.e., IP address), the name of the interface to connect to, the Logical Channel Number on that interface and the flow control values to use. These data are present in the PVC setup packets and the responding XOT verifies the configurations are compatible.
各XOT PVCはもう片方のXOT(すなわち、IPアドレス)のアイデンティティ、接続するインタフェースの名前、そのインタフェースのLogical Channel Number、および使用するフロー制御値によって構成されます。 これらのデータはセットアップパケットと応じているXOTが確かめるPVCに存在しています。構成は互換性があります。
The interface name fields are the ASCII names of the two interfaces involved. These names SHOULD be case-insensitive. There MUST NOT be any padding or trailing zero octets between or after the interface names.
インタフェース名前欄は2つのインタフェースの名前がかかわったASCIIです。 これらはSHOULDを命名します。大文字と小文字を区別しなくいてください。 名の間かインタフェース名の後に、どんな詰め物か八重奏を全く引きずるもあってはいけません。
The flow control values are the values from the perspective of the local interface of the XOT implementation that sent the PVC setup packet. The maximum packet size values are encoded as they are in the packet size facility, (i.e., the base-2 log of the size in octets, so 7 represents a maximum packet size of 128 octets). If the responding XOT implements end-to-end flow control, it will require that the configured flow control values be complimentary, so a returned status of 0x18 will indicate the values required by the responding XOT (note that the incoming value of one local interface corresponds to the outgoing value of the connecting local interface, and vice-versa).
フロー制御値はPVCセットアップパケットを送ったXOT実装の局所界面の見解からの値です。 それらがパケットサイズ施設、(すなわち、八重奏におけるサイズに関するベース-2ログ、7が128の八重奏の最大のパケットサイズに表すそう)にあって、最大のパケットサイズ値はコード化されます。 応じているXOTが終わりから終わりへのフロー制御を実装すると、構成されたフロー制御値が賞賛であることが必要であるので、0×18の返された状態は、値が応じているXOTが必要であることを(1つの局所界面の入って来る値が接続局所界面の外向的な値に対応することに注意してください、そして、逆もまた同様です)示すでしょう。
After establishing the TCP connection the initiator sends a PVC setup packet, the status value MUST be 0x00; the responder will reply with its own PVC setup packet or by closing the TCP connection. An XOT PVC setup is successful if the responder returns a status of 0x00. Once the XOT PVC connection is successfully established, each XOT MUST complete a Reset procedure on the local interface, so if each local interface LCI is in state D1, a Reset packet would be generated both to the local interface and the XOT TCP connection.
創始者がPVCセットアップパケットを送るTCP接続を確立した後に、状態値は0×00であるに違いありません。 応答者は、それ自身のPVCセットアップパケットかTCP接続を終えることによって、返答するでしょう。 応答者が0×00の状態を返すなら、XOT PVCセットアップはうまくいっています。 XOT PVC接続がいったん首尾よく確立されると、各XOT MUSTがReset手順を局所界面に完了するので、各局所界面LCIが州のD1にあるなら、Resetパケットは局所界面とXOT TCP接続に生成されるでしょう。
An XOT PVC connection is broken by simply closing the TCP connection; X.25 packets that are not legal for PVCs MUST NOT be transferred across an XOT PVC connection. When a local interface undergoes the Restart procedure, the XOT PVC connections MUST be either perform a Reset (which is appropriate if the interface remains in state R1) or close the XOT PVC connection.
XOT PVC接続は単にTCP接続を終えることによって、調教されます。 XOT PVC接続の向こう側にPVCsには、法的でないX.25パケットを移してはいけません。 局所界面がRestart手順を受けるとき、XOT PVC接続はReset(インタフェースが州のR1に残っているなら、適切である)を実行するか、またはXOT PVC接続を終えることであるに違いありません。
Forster, Satz, Glick & Day [Page 11] RFC 1613 X.25 Over TCP (XOT) May 1994
1994年のTCP(XOT)の上のRFC1613X.25がそうするフォルスター、サッツ、グリック、および日[11ページ]
DISCUSSION
議論
An XOT implementation SHOULD also consider how a PVC setup
collision will be handled. Receipt of an XOT PVC setup for a PVC
that is itself attempting to setup an XOT connection could either
accept a (valid) setup attempt and, if two TCP XOT connections
result, simply use one connection to send XOT data (XOT MUST NOT
send traffic over both) and accept XOT data on either, or it can
close the incoming attempt and, if no connections result, retry
the connection after waiting for a random interval. If two
connections are allowed for a PVC, closure of one SHOULD result in
the closure of the other.
また、XOT実装SHOULDは、PVCセットアップ衝突がどのように扱われるかを考えます。 XOT接続をセットアップするのを試みているPVCのためのXOT PVCセットアップの領収書が(有効)のセットアップ試みを受け入れて、2つのTCP XOT接続が結果になるならデータをXOTに送るのに単に1つの接続を使用するかもしれなくて(XOT MUST NOTは両方の上にトラフィックを送ります)、どちらかに関するXOTデータを受け入れてくださいか、それは、入って来る試みを終えて、どんな接続も結果にならないなら、無作為の間隔の間、待った後に、接続を再試行できます。 2つの接続がPVCのために許されているなら、もう片方の閉鎖で1つのSHOULD結果の閉鎖です。
7. Acknowledgments
7. 承認
Greg Satz is the original designer and implementor of X.25 over TCP. Aviva Garrett of cisco Systems reviewed the specification and made many editorial corrections.
グレッグSatzはTCPの上のX.25のオリジナルのデザイナーと作成者です。 コクチマスSystemsのAvivaギャレットは、仕様を再検討して、多くの編集上の訂正をしました。
8. Security Considerations
8. セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
9. References
9. 参照
[1] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
USC/Information Sciences Institute, July 1992.
[1] USC/情報科学が1992年7月に設けるレイノルズ、J.、およびJ.ポステル、「規定番号」、STD2、RFC1340。
[2] CCITT, Blue Book Volume VIII--Fascicle VIII.2, "Data
Communication Networks: Services and Facilities, Interfaces";
Recommendation X.25, "Interface Between Data Circuit-Terminating
Equipment (DCE) for Terminals Operating in the Packet Mode and
Connected to Public Data Networks by Dedicated Circuit", 1989,
Geneva.
[2]CCITT、紳士録巻VIII--分冊VIII.2、「データ通信は以下をネットワークでつなぎます」。 「サービスと施設、インタフェース」。 推薦X.25、「専用回路によってパケット形態で作動して、公衆データネットワークにつなげられた端末へのデータ回路を終える設備(DCE)の間のインタフェース」、1989、ジュネーブ。
Forster, Satz, Glick & Day [Page 12] RFC 1613 X.25 Over TCP (XOT) May 1994
1994年のTCP(XOT)の上のRFC1613X.25がそうするフォルスター、サッツ、グリック、および日[12ページ]
10. Authors' Addresses
10. 作者のアドレス
James R. Forster
Engineering Dept.
cisco Systems
1525 O'Brien Dr.
Menlo Park. CA. 94025
ジェームスR.フォルスターEngineering部コクチマスSystems1525オブライエン博士メンローパーク。 カリフォルニア。 94025
Phone: 1.415.688.8245
Fax: 1.415.688.8282
EMail: forster@cisco.com
以下に電話をしてください。 1.415.688.8245 Fax: 1.415.688.8282 メールしてください: forster@cisco.com
Greg Satz
Engineering Dept.
cisco Systems
1525 O'Brien Dr.
Menlo Park. CA. 94025
グレッグSatz Engineering部コクチマスSystems1525オブライエン博士メンローパーク。 カリフォルニア。 94025
Phone: 1.415.688.8245
Fax: 1.415.688.8282
EMail: satz@cisco.com
以下に電話をしてください。 1.415.688.8245 Fax: 1.415.688.8282 メールしてください: satz@cisco.com
Gilbert Glick
Engineering Dept.
cisco Systems
1525 O'Brien Dr.
Menlo Park. CA. 94025
ギルバートグリックEngineering部コクチマスSystems1525オブライエン博士メンローパーク。 カリフォルニア。 94025
Phone: 1.415.688.8245
Fax: 1.415.688.8282
EMail: gglick@cisco.com
以下に電話をしてください。 1.415.688.8245 Fax: 1.415.688.8282 メールしてください: gglick@cisco.com
Bob Day
Joint Network Team
c/o Rutherford Appleton Laboratory
Chilton
Didcot
Oxfordshire OX11 0QX
United Kingdom
ボブDay共同しているネットワークチーム気付ラザフォード・アップルトーン研究所チルトン・ジドコットオックスフォードシアOX11 0QXイギリス
Phone: 44.235.44.5163
Fax: 44.235.44.6251
EMail: R.Day@jnt.ac.uk
以下に電話をしてください。 44.235.44.5163 Fax: 44.235.44.6251 メールしてください: R.Day@jnt.ac.uk
Forster, Satz, Glick & Day [Page 13]
フォルスター、サッツ、グリック、および日[13ページ]
一覧
スポンサーリンク
