RFC1859 日本語訳
1859 ISO Transport Class 2 Non-use of Explicit Flow Control over TCPRFC1006 extension. Y. Pouffary. October 1995. (Format: TXT=14572 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group Y. Pouffary Request For Comments: 1859 Digital Equipment Corporation Category: Informational October 1995
Pouffaryがコメントのために要求するワーキンググループY.をネットワークでつないでください: 1859年のDECカテゴリ: 情報の1995年10月
ISO Transport Class 2 Non-use of Explicit Flow Control over TCP
RFC1006 extension
TCP RFC1006拡張子の上のExplicit Flow ControlのISO Transport Class2Non-使用
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 - General recommendations.......................2 2. The protocol.................................................3 2.1 TCP service as a Network Service - The Primitives...........3 2.2 Connection Establishment....................................4 2.3 Data Transfer...............................................5 2.4 Connection Release..........................................6 3. Packet Format................................................6 4. DIGITAL DECnet over TCP/IP...................................8 Acknowledgements................................................9 References......................................................9 Author's Address................................................9
1. 序論--一般推薦…2 2. プロトコル…3 2.1 Network ServiceとしてのTCPサービス--Primitives…3 2.2 接続設立…4 2.3データ転送…5 2.4 接続リリース…6 3. パケット形式…6 4. TCP/IPの上のデジタルDECnet…8つの承認…9つの参照箇所…9作者のアドレス…9
1. Introduction - General recommendations
1. 序論--一般推薦
This document is an extension to STD35, RFC1006, a standard for the Internet community. The document does not duplicate the protocol definitions contained in RFC1006 and in International Standard ISO 8073. It supplements that information with the description of how to implement ISO Transport Class 2 Non-use of Explicit Flow Control on top of TCP.
このドキュメントはSTD35、RFC1006、インターネットコミュニティの規格への拡大です。 ドキュメントはRFC1006と国際規格ISO8073に含まれたプロトコル定義をコピーしません。 それはTCPの上でどう2がNon使用するExplicit Flow ControlのISO Transport Classを実装するかに関する記述でその情報を補います。
The document should be used in conjunction with the RFC1006 and ISO 8073.
ドキュメントはRFC1006とISO8073に関連して使用されるべきです。
The RFC1006 standard defines how to implement ISO 8073 Transport Class 0 on top of TCP. This memo defines how to implement ISO 8073 Transport Class 2 Non-use of Explicit Flow Control on top of TCP. Like ISO Transport Class 0, Class 2 Non-use of Explicit Flow Control provides basic connection with minimal overhead.
RFC1006規格はTCPの上でISO8073Transport Class0を実装する方法を定義します。 このメモはTCPの上でISO8073Transport Class2がExplicit Flow ControlのNon-使用であると実装する方法を定義します。 ISO Transport Class0のように、Explicit Flow ControlのClass2Non-使用は最小量のオーバーヘッドを基本接続に提供します。
A Transport protocol class is selected for a particular Transport connection based upon the characteristics of the lower layers and the
そしてTransportプロトコルのクラスが下層の特性に基づく特定のTransport接続のために選択される。
Pouffary Informational [Page 1] RFC 1859 ISO Transport and Flow Control October 1995
Pouffaryの情報[1ページ]のRFC1859ISO輸送とフロー制御1995年10月
requirements of the upper layer. Use of class 2 Non-use of Explicit Flow Control is suitable when the use of separate virtual data channels for normal and expedited Data are desirable or when an explicit disconnection of the Transport connection is desirable.
上側の層の要件。 正常で速められたDataの別々の仮想データチャンネルの使用が望ましいか、またはTransport接続の明白な断線が望ましいときに、2がNon使用するExplicit Flow Controlのクラスの使用は適当です。
Hosts which choose to implement this extension are expected to listen on the well-known TCP port number 399.
この拡大を実装するのを選ぶホストがよく知られるTCPポートNo.399で聴くと予想されます。
It is recommended that the well-known RFC1006 TCP port 102 not be used. This recommendation is done to minimise impact to an existing RFC1006 implementation.
よく知られるRFC1006 TCPポート102が使用されないのは、お勧めです。 既存のRFC1006実装に影響を最小とならせるようにこの推薦をします。
The memo also describes the use of this extension within the DIGITAL Network Architecture (DNA).
また、メモはDigital Network Architecture(DNA)の中でこの拡張子の使用について説明します。
2. The protocol
2. プロトコル
The protocol specified by this memo is fundamentally equivalent to the protocol ISO 8073 Transport Class 2 Non-use of Explicit Flow Control, with the following extensions:
このメモで指定されたプロトコルは基本的に2がNon使用するExplicit Flow ControlのプロトコルISO8073Transport Classに同等です、以下の拡大で:
- Expedited Data service is supported.
- 速められたDataサービスはサポートされます。
- Splitting and Recombining may be used for Expedited Data
transmission.
- 分かれるのとRecombiningはExpedited Dataトランスミッションに使用されるかもしれません。
- The Network Service used is provided by TCP.
- 使用されるNetwork ServiceはTCPによって提供されます。
The ISO 8073 Transport protocol Class 2 allows Multiplexing. It is recommended that this capability not be use for performance reasons.
ISO8073TransportプロトコルClass2はMultiplexingを許容します。 この能力が性能理由の使用でないことはお勧めです。
The ISO 8073 Transport protocol exchanges information between peers in discrete units of information called transport protocol data units (TPDUs). The protocol defined in this memo encapsulates these TPDUs in discrete units called TPKTs. The structure of these TPKTs and their relationship to TPDUs are discussed in the next sections.
ISO8073Transportプロトコルはトランスポート・プロトコルデータ単位(TPDUs)と呼ばれる離散的なユニットの情報の同輩の間で情報交換します。 このメモで定義されたプロトコルはTPKTsと呼ばれる離散的なユニットでこれらのTPDUsをカプセル化します。 次のセクションでこれらのTPKTsの構造とTPDUsとの彼らの関係について議論します。
2.1 TCP service as a Network Service - The Primitives
Network Serviceとしての2.1TCPサービス--Primitives
The mapping between the TCP service primitives and the service primitives expected by ISO 8073 Transport when operation over Connection-oriented network service is straightforward.
Connection指向のネットワーク・サービスの上の操作が簡単であるときにISO8073Transportによって予想されたTCPサービス基関数とサービス基関数の間のマッピング。
Pouffary Informational [Page 2] RFC 1859 ISO Transport and Flow Control October 1995
Pouffaryの情報[2ページ]のRFC1859ISO輸送とフロー制御1995年10月
Note: The following description of the mapping is a repeat from the RFC1006 standard.
以下に注意してください。 マッピングの以下の記述はRFC1006規格からの反復です。
network service TCP --------------- --- CONNECTION ESTABLISHMENT
ネットワーク・サービスTCP--------------- --- コネクション確立
N-CONNECT.REQUEST open completes
N-CONNECT.REQUEST戸外は完成します。
N-CONNECT.INDICATION listen (PASSIVE open) finishes
N-CONNECT.INDICATIONが聴く、(PASSIVEは開きます)終える。
N-CONNECT.RESPONSE listen completes
N-CONNECT.RESPONSEが聴く、完成
N-CONNECT.CONFIRMATION open (ACTIVE open) finishes
N-CONNECT.CONFIRMATION戸外(ACTIVEは開く)は終わります。
DATA TRANSFER
データ転送
N-DATA.REQUEST send data
N-DATA.REQUEST送信データ
N-DATA.INDICATION data ready followed by read data
N-DATA.INDICATIONデータは続いている読まれたデータを準備します。
CONNECTION RELEASE
コネクション解放
N-DISCONNECT.REQUEST close
N-DISCONNECT.REQUESTは閉じます。
N-DISCONNECT.INDICATION connection closes or errors
N-DISCONNECT.INDICATION接続閉鎖か誤り
Mapping parameters between the TCP service and the network service is also straightforward:
また、TCPサービスとネットワーク・サービスの間のパラメタを写像するのも簡単です:
network service TCP --------------- --- CONNECTION ESTABLISHMENT
ネットワーク・サービスTCP--------------- --- コネクション確立
Called address server's IP address (4 octets)
アドレスサーバのIPアドレスと呼ばれます。(4つの八重奏)
Calling address client's IP address (4 octets)
アドレスをクライアントのIPアドレスと呼びます。(4つの八重奏)
all others ignored
他のものが無視したすべて
DATA TRANSFER
データ転送
NS-user data (NSDU) data
NS-利用者データ(NSDU)データ
CONNECTION RELEASE
コネクション解放
all parameters ignored
無視されたすべてのパラメタ
Pouffary Informational [Page 3] RFC 1859 ISO Transport and Flow Control October 1995
Pouffaryの情報[3ページ]のRFC1859ISO輸送とフロー制御1995年10月
2.2 Connection Establishment
2.2 コネクション確立
The principles used in connection establishment are based upon those described in ISO 8073, with the following extensions.
コネクション確立に使用される原則は以下の拡大を伴うISO8073で説明されたものに基づいています。
- Connection Request and Connection Confirmation TPDUs may negotiate
the use of Expedited Data transfer using the negotiation mechanism
specified in ISO 8073.
- 接続RequestとConnection Confirmation TPDUsは、ISO8073で指定された交渉メカニズムを使用することでExpedited Data転送の使用を交渉するかもしれません。
- Connection Request and Connection Confirmation TPDUs must not
negotiate the Use of Explicit Flow Control.
- 接続RequestとConnection Confirmation TPDUsはExplicit Flow ControlのUseを交渉してはいけません。
To perform an N-CONNECT.REQUEST action, the TS-peer performs an active open to the desired IP address using the well know TCP port 399. When the TCP signals either success or failure, this results in an N-CONNECT.INDICATION action.
N-CONNECT.REQUEST動作を実行するために、TS-同輩は井戸を使用するとTCPが399に移植するのを知っている必要なIPアドレスにアクティブな戸外を実行します。 TCPが成功か失敗のどちらかに合図するとき、これはN-CONNECT.INDICATION動作をもたらします。
To await an N-CONNECT.INDICATION event, a server listens on the well know TCP port 399. When a client successfully connects to this port, the event occurs and an implicit N-CONNECT.RESPONSE action is performed.
N-CONNECT.INDICATIONイベント、サーバが井戸の上で聴くaを待つには、TCPポート399を知ってください。 クライアントが首尾よくこのポートに接続するとき、イベントは起こります、そして、暗黙のN-CONNECT.RESPONSE動作は実行されます。
2.3 Data Transfer
2.3データ転送
The elements of procedure used during transfer are based upon those presented in ISO 8073, with the two following extensions.
転送の間の実行した手順の要素は2つの次の拡大を伴うISO8073に提示されたものに基づいています。
- Expedited Data may be supported (if negotiated during connection
establishment).
- 速められたDataはサポートされるかもしれません(コネクション確立の間、交渉されるなら)。
In Non-Use of Explicit Flow Control Expedited Data requires no
Expedited Data Acknowledgement.
Explicit Flow Control Expedited DataをNon-使用で、Expedited Data Acknowledgementを全く必要としません。
- Splitting and Recombining may be used for Expedited Data
transmission.
- 分かれるのとRecombiningはExpedited Dataトランスミッションに使用されるかもしれません。
The procedure of Splitting and Recombining allows a transport
connection to make use of multiple TCP connections.
TCP connections created for Splitting purposes should also use
the primitives described in 2.1.
SplittingとRecombiningの手順で、輸送接続は複数のTCP接続を利用できます。 また、Splitting目的のために創造されたTCP接続は2.1で説明された基関数を使用するべきです。
It is recommended to only create a second TCP connection for
Expedited Data when transmission of Expedited Data is requested.
Expedited Dataのトランスミッションが要求されているとき、Expedited Dataのために2番目のTCP接続を創造するだけがお勧めです。
Expedited Data must only be sent over an outgoing TCP connection.
This second TCP connection must not be shared among transport
connections and must remain established until the transport
connection is terminated, at which time it must be closed.
外向的なTCP接続の上に速められたDataを送るだけでよいです。 輸送接続がどの時にそれを閉じなければならないかとき終えられるまで、この2番目のTCP接続は、輸送の接続で共有されてはいけなくて、確立していたままでいなければなりません。
Pouffary Informational [Page 4] RFC 1859 ISO Transport and Flow Control October 1995
Pouffaryの情報[4ページ]のRFC1859ISO輸送とフロー制御1995年10月
Implementors note: The procedure of Splitting and Recombining for Expedited Data transmission guaranties that a congested Normal Data TCP connection cannot block an Expedited Data TCP connection. It also ensures independence of the Normal Data TCP connection from the Expedited Data TCP connection.
作成者は以下に注意します。 Expedited Dataトランスミッション保証のための混雑しているNormal Data TCP接続がそうすることができないSplittingとRecombiningの手順はExpedited Data TCP接続を妨げます。 また、それはExpedited Data TCP接続からNormal Data TCP接続からの独立を確実にします。
To perform an N-DATA.REQUEST action, the TS-peer constructs the desired TPKT and uses the TCP send data primitive.
N-DATA.REQUEST動作を実行するために、TS-同輩は原始的にTCPがデータを送る必要なTPKTと用途を構成します。
To trigger an N-DATA.INDICATION action, the TCP indicates that data is ready and a TPKT is read using the TCP read data primitive.
N-DATA.INDICATION動作の引き金となるように、TCPは、データが準備ができているのを示します、そして、TPKTはデータが原始的に読まれたTCPを使用することで読まれます。
2.4 Connection Release
2.4 コネクション解放
The elements of procedure used during a connection release are identical to those presented in ISO 8073.
コネクション解放の間の実行した手順の要素はISO8073に提示されたものと同じです。
A connection can be terminated by the user in one of two ways:
ユーザは2つの方法の1つで接続を終えることができます:
- Abort Disconnect specifies that all messages at the source are not
required to be sent to the destination before the connection is
disconnected.
- アボートDisconnectは、ソースのすべてのメッセージが接続から切断する前に目的地に送るのに必要であるというわけではないと指定します。
- Synchronous Disconnect specifies that all messages at the source
must be sent to the destination, and that all messages at the
destination must be delivered, before the connection is
disconnected.
- 同期Disconnectはソースのすべてのメッセージを送付先に送らなければならなくて、目的地のすべてのメッセージを提供しなければならないと指定します、接続切断される前に。
Disconnect Request and Disconnect Confirmation TPDUs are exchanged in both cases. The Disconnect Request TPDU carries a code indicating the reason for the disconnection.
どちらの場合も、分離RequestとDisconnect Confirmation TPDUsを交換します。 Disconnect Request TPDUは断線の理由を示すコードを運びます。
In the case of a Synchronous Disconnect the Disconnect Request reason code is normal (80 hex). For an Abort Disconnect the Disconnect Request reason code is normal with additional information parameter value set to (c0 hex).
Synchronous Disconnectの場合では、Disconnect Request理由コードは正常です(80十六進法)。 Abort Disconnectに関しては、コードが追加情報パラメタ価値のために正常であるDisconnect Request理由は(c0十六進法)にセットしました。
Upon receipt of a Disconnect Confirmation TPDU a N-DISCONNECT.REQUEST action is performed to close the TCP connection.
Disconnect Confirmation TPDUを受け取り次第、N-DISCONNECT.REQUEST動作は、TCP接続を終えるために実行されます。
If the TCP connection fails for some other reason, this generates an N-DISCONNECT.INDICATION event.
TCP接続がある他の理由で失敗するなら、これはN-DISCONNECT.INDICATIONイベントを生成します。
3. Packet Format
3. パケット・フォーマット
A fundamental difference between TCP and the network service expected by ISO transport is that TCP manages a continuous stream of octets, with no explicit boundaries.
TCPとISO輸送で予想されたネットワーク・サービスの基本的な違いはTCPが八重奏の連続したストリームを管理するということです、明白な境界なしで。
Pouffary Informational [Page 5] RFC 1859 ISO Transport and Flow Control October 1995
Pouffaryの情報[5ページ]のRFC1859ISO輸送とフロー制御1995年10月
The protocol described in RFC1006 uses a simple packetization scheme in order to delimit TPDUs. Each packet, termed a TPKT, consists of two parts: a packet-header and a TPDU.
RFC1006で説明されたプロトコルは、TPDUsを区切るのに簡単なpacketization体系を使用します。 TPKTと呼ばれた各パケットは2つの部品から成ります: パケットのヘッダーとTPDU。
We use the same scheme described in RFC1006 for this extension. There is no need to change the version number. The ISO transport TPDU sufficiently describes the transport protocol class being used.
私たちはこの拡大のためにRFC1006で説明された同じ体系を使用します。 バージョン番号を変える必要は全くありません。 ISO輸送TPDUは使用されるトランスポート・プロトコルのクラスについて十分説明します。
The format of the packet-header described below is a repeat from RFC1006.
以下で説明されたパケットのヘッダーの形式はRFC1006からの反復です。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| vrsn | reserved | packet 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | vrsn| 予約されます。| パケット長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
どこ:
vrsn 8 bits
vrsn8ビット
This field is always 3 for the version of the protocol
described in this memo.
いつもこの分野はこのメモで説明されたプロトコルのバージョンのための3です。
packet length 16 bits (min=7, max=65535)
16ビットのパケット長(分=7、最大=65535)
The packet length is the length of the entire packet in
octets, including packet-header.
パケット長はパケットのヘッダーを含む八重奏で、全体のパケットの長さです。
The format of the ISO transport TPDU is defined in ISO 8073.
ISO輸送TPDUの書式はISO8073で定義されます。
4. DIGITAL DECnet over TCP/IP
4. TCP/IPの上のデジタルDECnet
DECnet over TCP/IP is implemented using the DECnet Session Control layer over this RFC1006 extension protocol.
TCP/IPの上のDECnetは、このRFC1006拡大プロトコルの上でDECnet Session Control層を使用することで実装されます。
The informational RFC defined in this document provides the Transport Service functionality required by DECnet Applications while operating over TCP/IP.
本書では定義された情報のRFCはTCP/IPの上で作動している間にDECnet Applicationsによって必要とされたTransport Serviceの機能性を提供します。
The next paragraph is a brief summary of the role of the DECnet Session Control Layer. For further details, refer to the DIGITAL DNA Session Control Layer Specification.
次のパラグラフはDECnet Session Control Layerの役割の簡潔な概要です。 さらに詳しい明細については、Digital DNA Session Control Layer Specificationを参照してください。
The DECnet Session Control Layer makes a Transport Service available to End Users of a network. This layer is concerned with system- dependent functions related to creating, maintaining, and destroying Transport Connections. Separate virtual data channels, known as
DECnet Session Control LayerはTransport Serviceをネットワークのエンドユーザにとって利用可能にします。 この層はシステムTransportコネクションズを作成して、維持して、破壊すると関連する依存する機能に関係があります。 仮想データチャンネルを切り離して、知られています。
Pouffary Informational [Page 6] RFC 1859 ISO Transport and Flow Control October 1995
Pouffaryの情報[6ページ]のRFC1859ISO輸送とフロー制御1995年10月
"Normal" and "Expedited", are provided to End Users. DECnet Session Control must be guaranteed independence of these channels by the Transport Layer. Expedited Data transmission cannot be blocked by a congested normal data channel. DECnet Session Control requires that all data in transit be delivered before initiating the release of the Transport Connection.
「標準」と「速められたこと」をエンドユーザに提供します。 Transport Layerはこれらのチャンネルからの独立をDECnet Session Controlに保証しなければなりません。 混雑している普通のデータ・チャンネルは速められたDataトランスミッションを妨げることができません。 DECnet Session Controlは、Transport Connectionのリリースを開始する前にトランジットにおけるすべてのデータが提供されるのを必要とします。
DECnet, DNA, and the DIGITAL logo are trademarks of Digital Equipment Corporation.
DECnet、DNA、およびDigitalロゴはDECの商標です。
Acknowledgements
承認
Bill Duane, Jim Bound, David Sullivan, Mike Dyer, Matt Thomas, Dan Harrington and many other members of the DECnet engineering team.
ビル・ドウェイン、ジムBound、デヴィッド・サリバン、マイクDyer、マット・トーマス、ダン・ハリントン、およびDECnet工学の多くの他のメンバーが組になります。
References
参照
[ISO8072] ISO. "International Standard 8072. Information
Processing Systems -- Open Systems Interconnection:
Transport Service Definition."
[ISO8072]ISO。 「国際規格8072。」 情報処理システム--オープン・システム・インターコネクション: 「サービス定義を輸送してください。」
[ISO8073] ISO. "International Standard 8073. Information
Processing Systems -- Open Systems Interconnection:
Transport Protocol Specification."
[ISO8073]ISO。 「国際規格8073。」 情報処理システム--オープン・システム・インターコネクション: 「プロトコル仕様を輸送してください。」
[ISO8327] ISO. "International Standard 8327. Information
Processing Systems -- Open Systems Interconnection:
Session Protocol Specification."
[ISO8327]ISO。 「国際規格8327。」 情報処理システム--オープン・システム・インターコネクション: 「セッションプロトコル仕様。」
[RFC791] Postel, J., "Internet Protocol - DARPA Internet Program
Protocol Specification", STD 5, RFC 791,
USC/Information Sciences Institute, September 1981.
[RFC791] ポステル、J.、「インターネットは議定書を作ります--DARPAインターネットはプロトコル仕様をプログラムする」STD5、RFC791、科学が1981年9月に設けるUSC/情報。
[RFC793] Postel, J., "Transmission Control Protocol - DARPA
Internet Program Protocol Specification", STD 7, RFC
793, USC/Information Sciences Institute, September 1981.
[RFC793]ポステル、J.、「転送管理は議定書を作ります--DARPAインターネットプログラムプロトコル仕様」、STD7、RFC793、科学が設けるUSC/情報、1981年9月。
[RFC1006] Rose, M., and D. Cass, "ISO Transport Services on Top of
the TCP - Version: 3", STD 35, RFC 1006, Northrop
Research and Technology Center, May 1987.
[RFC1006] ローズ、M.、およびD.キャス、「ISOはTCPの上でサービスを輸送します--、バージョン:、」 3インチ(STD35、RFC1006、ノースロップの研究、および技術センター)は、1987がそうするかもしれません。
Pouffary Informational [Page 7] RFC 1859 ISO Transport and Flow Control October 1995
Pouffaryの情報[7ページ]のRFC1859ISO輸送とフロー制御1995年10月
Security Considerations
セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Author's Address
作者のアドレス
Yanick Pouffary End Systems Networking Digital Equipment Corporation Centre Technique (Europe) B.P. 027 950 Routes des colles 06901 Sophia antipolis, France
Yanick Pouffary End Systems Networking DEC Centre Technique(ヨーロッパ)B.P.027 950Routes desコリス06901ソフィア「反-ポリス」、フランス
Phone: +33 92-95-62-85 Fax: +33 92-95-62-32 EMail: pouffary@taec.enet.dec.com
以下に電話をしてください。 +33 92-95-62-85Fax: +33 92-95-62-32 メールしてください: pouffary@taec.enet.dec.com
Pouffary Informational [Page 8]
Pouffary情報です。[8ページ]
一覧
スポンサーリンク
