RFC2126 日本語訳
2126 ISO Transport Service on top of TCP (ITOT). Y. Pouffary, A.Young. March 1997. (Format: TXT=51032 bytes) (Updates RFC1006) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group Y. Pouffary
Request for Comments: 2126 Digital Equipment Corporation
Category: Standards Track A. Young
ISODE Consortium
March 1997
Pouffaryがコメントのために要求するワーキンググループY.をネットワークでつないでください: 2126年のDECカテゴリ: 1997年の標準化過程のA.の若いISODE共同体行進
ISO Transport Service on top of TCP (ITOT)
TCPの上のISO Transport Service(ITOT)
Status of the Memo
メモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
This document is a revision to STD35, RFC1006 written by Marshall T. Rose and Dwight E. Cass. Since the release of RFC1006 in May 1987, much experience has been gained in using ISO transport services on top of TCP. This document refines the protocol and will eventually supersede RFC1006.
このドキュメントはSTD35、マーシャル・T.ローズとドワイト・E.キャスによって書かれたRFC1006への改正です。 1987年5月のRFC1006のリリース以来、TCPの上でISO輸送サービスを使用する際に多くの経験をしています。 このドキュメントは、プロトコルを洗練して、結局、RFC1006に取って代わるでしょう。
This document describes the mechanism to allow ISO Transport Services to run over TCP over IPv4 or IPv6. It also defines a number of new features, which are not provided in RFC1006.
このドキュメントは、ISO Transport ServicesがIPv4かIPv6の上でTCPをひくのを許容するためにメカニズムについて説明します。 また、それは多くの新機能を定義します。(新機能はRFC1006に提供されません)。
The goal of this version is to minimise the number of changes to RFC1006 and ISO 8073 transport protocol definitions, while maximising performance, extending its applicability and protecting the installed base of RFC1006 users.
このバージョンの目標は性能を最大にしている間、RFC1006とISO8073輸送プロトコル定義への変化の数を最小とならせることです、適用性を広げていて、RFC1006ユーザのインストールされたベースを保護して。
Table of Contents
目次
1. Introduction, Motivation.....................................2 2. The Model....................................................3 2.1 ISO Transport Model.........................................3 2.2 ISO Transport over TCP (ITOT) Model.........................4 2.3 Overview of Protocol and Service............................5 3 Service Definition............................................5 3.1 Transport Service Definition................................5 3.1.1 Transport Service Definition Primitives...................6 3.2 Network Service Definition..................................7 3.2.1 ISO 8348 CONS primitives..................................7 3.2.2 TCP Service primitives....................................8 3.2.3 Mapping TCP as a Network Service Provider.................8
1. 序論、動機…2 2. モデル…3 2.1 ISOはモデルを輸送します…3 2.2 ISOはTCP(ITOT)の上でモデルを輸送します…4 プロトコルの、そして、サービスの2.3概要…5 3は定義を修理します…5 3.1 サービス定義を輸送してください…5 3.1 .1 サービス定義基関数を輸送してください…6 3.2 サービス定義をネットワークでつないでください…7 3.2 .1 ISO8348コンズ基関数…7 3.2 .2 TCP Service基関数…8 3.2 .3 ネットワークとしてのマッピングTCPはプロバイダーを修理します…8
Pouffary & Young Standards Track [Page 1] RFC 2126 ISO Transport on top of TCP March 1997
TCP行進1997の上のPouffaryとヤングStandards Track[1ページ]RFC2126ISO Transport
3.2.3.1 Network Connection Establishment........................8 3.2.3.2 Network Data Transfer...................................9 3.2.3.3 Network Connection Release.............................10 4. Transport Protocol Specification............................10 4.1 Class 0 over TCP...........................................10 4.1.1 Connection Establishment.................................11 4.1.2 Data Transfer............................................11 4.1.3 Connection Release.......................................11 4.2 Class 2 over TCP...........................................12 4.2.1 Connection Establishment.................................12 4.2.2 Data Transfer............................................13 4.2.3 Connection Release.......................................15 4.3 TPKT Packet Format.........................................15 5. Address representations.....................................16 5.1 String representation of ITOT access point addresses.......17 5.2 OSI Network Address encoding...............................17 6. Notes to Implementors.......................................17 6.1 TCP Connection Establishment...............................17 6.2 TCP Data transfer..........................................17 6.3 Class negotiation..........................................18 6.4 Default maximum TPDU size..................................18 6.5 Class 0 TPDU bit encoding..................................18 6.6 Class 2 Options............................................19 6.7 Class 2 Expedited Data Acknowledgement.....................21 6.8 Class 2 Normal Data and Expedited Data handling............21 6.9 Class 2 Forward Connection procedure.......................22 6.10 TPKT......................................................22 7. Rationale - Interoperability with RFC1006...................22 8. Security Considerations.....................................23 Acknowledgements...............................................23 References.....................................................23 Authors' Addresses.............................................25
3.2.3.1 コネクション確立をネットワークでつないでください…8 3.2 .3 .2 データ転送をネットワークでつないでください…9 3.2 .3 .3 コネクション解放をネットワークでつないでください…10 4. プロトコル仕様を輸送してください…10 4.1 TCPの上のクラス0…10 4.1 .1 接続設立…11 4.1 .2データ転送…11 4.1 .3 接続リリース…11 4.2 TCPの上のクラス2…12 4.2 .1 接続設立…12 4.2 .2データ転送…13 4.2 .3 接続リリース…15 4.3 TPKTパケット・フォーマット…15 5. 表現を扱ってください…16 5.1 ITOTアクセスポイントアドレスの表現を結んでください…17 5.2 OSI Network Addressコード化…17 6. 作成者への注意…17 6.1 TCPコネクション確立…17 6.2 TCP Dataは移します…17 6.3 クラス交渉…18 6.4 デフォルトの最大のTPDUサイズ…18 6.5 クラス0TPDUはコード化に噛み付きました…18 6.6 クラス2オプション…19 6.7 クラス2はデータ承認を速めました…21 6.8 クラス2Normal DataとExpedited Data取り扱い…21 6.9 クラス2Forward Connection手順…22 6.10TPKT…22 7. 原理--、RFC1006がある相互運用性…22 8. セキュリティ問題…23の承認…23の参照箇所…23人の作者のアドレス…25
1. Introduction, Motivation
1. 序論、動機
There are two basic approaches which can be taken when "porting" ISO applications to TCP/IP ([RFC793],[RFC791]) and IPv6 [IPV6] environments. One approach is to port each individual application separately, developing local protocols on top of TCP. A second approach is based on the notion of layering the ISO Transport Service over TCP/IP. This approach solves the problem for all applications which use the ISO Transport Service. This document describes the second approach.
TCP/IP[RFC793]、[RFC791)、およびIPv6[IPV6]環境にISOアプリケーションを「移植する」とき取ることができる2つの基本的なアプローチがあります。 1つのアプローチはTCPの上でローカルのプロトコルを開発して、別々にそれぞれの個々のアプリケーションを移植することです。 2番目のアプローチはTCP/IPの上でISO Transport Serviceを層にするという概念に基づいています。 このアプローチはISO Transport Serviceを使用するすべてのアプリケーションのための問題を解決します。 このドキュメントは2番目のアプローチについて説明します。
The protocol described in this memo is based on the observation that both the Internet Protocol Suite and the ISO Protocol Suite are layered systems. A key aspect of the layering principle is that of layer-independence. The concept of layer-independence means that if
このメモで説明されたプロトコルはインターネットプロトコルSuiteとISOプロトコルSuiteの両方が階層構造であるという観測に基づいています。レイヤリング原則の特徴は層独立のものです。 層独立の概念はそれを意味します。
Pouffary & Young Standards Track [Page 2] RFC 2126 ISO Transport on top of TCP March 1997
TCP行進1997の上のPouffaryとヤングStandards Track[2ページ]RFC2126ISO Transport
one preserves the services offered by a particular layer (the Service-Provider) then the Service-User at that layer is completely unaffected by changes in the underlying layers or by the protocol used within the layer.
1つは特定の層(Service-プロバイダー)で提供されたサービスを保持して、次に、その層のService-ユーザは下位層における変化か層の中で使用されたプロトコルで完全に影響を受けないです。
This document defines a Transport Service which appears to be identical to the Services and Interfaces offered by the ISO Transport Service Definition [ISO8072], but which will in fact implement the ISO Transport Protocol [ISO8073] on top of TCP/IP (IPv4 or IPv6), rather than the ISO Network Service [ISO8348].
このドキュメントはISO Transport Service Definition[ISO8072]によって提供されたServicesとInterfacesと同じであるように見えますが、事実上、ISO Network Service[ISO8348]よりむしろTCP/IP(IPv4かIPv6)の上でISO Transportがプロトコル[ISO8073]であると実装するTransport Serviceを定義します。
The basis of this document is STD35, RFC1006 [RFC1006] written by Marshall T. Rose and Dwight E. Cass and it defines two transport classes of service. Transport Class 0 refines and supersedes the RFC1006 protocol and is aimed at preserving the RFC1006 installed base. Transport Class 2 defines a number of new features which are not provided in RFC1006, such as independence of Normal and Expedited Data channels and Explicit Transport Disconnection. These new features are largely based on RFC1859 [RFC1859] and extend the applicability of RFC1006 to new groups of applications.
このドキュメントの基礎はSTD35、マーシャル・T.ローズとドワイト・E.キャスによって書かれたRFC1006[RFC1006]です、そして、それは2つの輸送のクラスのサービスを定義します。 輸送Class0は、洗練されて、RFC1006プロトコルに取って代わって、保存が目的とされて、RFC1006がベースをインストールしたということです。 輸送Class2はNormal、Expedited Dataチャンネル、およびExplicit Transport Disconnectionからの独立などのRFC1006に提供されない多くの新機能を定義します。 これらの新機能は、RFC1859[RFC1859]に主に基づいていて、アプリケーションの新しいグループにRFC1006の適用性を広げています。
This document specifies changes to the standards mentioned above and must be read in the context of the above mentioned standards. It will not be meaningful on its own.
このドキュメントを前記のように規格への変化を指定して、上記の規格の文脈で読まなければなりません。 それはそれ自身のところで重要にならないでしょう。
The 'well known' TCP port 102 is reserved for hosts which implement the Protocol described in this document. Note that the Protocol does not mandate the use of TCP port 102 for all connections.
'よく知られている'TCPポート102はプロトコルが本書ではそれの道具について説明したホストのために予約されます。 プロトコルがTCPポート102のすべての接続の使用を強制しないことに注意してください。
2. The Model
2. モデル
This section describes the differences between the model used by the ISO Transport and that described in this document.
このセクションはISO Transportによって使用されたモデルと本書では説明されたそれの違いについて説明します。
2.1 ISO Transport Model
2.1 ISO輸送モデル
The ISO 8072 standard describes the ISO Transport Service Definition (TS). The ISO Transport Service Definition describes the services offered by the Transport Service Provider and the interfaces used to access these services.
ISO8072規格はISO Transport Service Definition(TS)について説明します。 ISO Transport Service DefinitionはTransport Service Providerによって提供されたサービスとこれらのサービスにアクセスするのに使用されるインタフェースについて説明します。
The ISO 8073 standard describes the ISO Transport Protocol Specification (TP). The ISO Transport Protocol specifies common encoding rules and a number of classes of transport protocol procedure which can be used with different network Quality of Service.
ISO8073規格はISO TransportプロトコルSpecification(TP)について説明します。 ISO TransportプロトコルはServiceの異なったネットワークQualityと共に用いることができる一般的な符号化規則と多くのクラスのトランスポート・プロトコル手順を指定します。
Pouffary & Young Standards Track [Page 3] RFC 2126 ISO Transport on top of TCP March 1997
TCP行進1997の上のPouffaryとヤングStandards Track[3ページ]RFC2126ISO Transport
The ISO 8348 standard describes the ISO Network Service Definition (NS). The ISO Network Service Definition describes the services offered by the network service Provider and the interfaces used to access these services.
ISO8348規格はISO Network Service Definition(NS)について説明します。 ISO Network Service Definitionはネットワーク・サービスProviderによって提供されたサービスとこれらのサービスにアクセスするのに使用されるインタフェースについて説明します。
The ISO Network Service specifies two type of service:
ISO Network Serviceはサービスの2タイプを指定します:
- Connection Oriented Network Service (CONS)
- 接続はネットワーク・サービスを適応させました。(まやかし)
- ConnectionLess Network Service (CLNS)
- コネクションレスなネットワーク・サービス(CLNS)
The ISO Transport Protocol specifies five classes of procedures when operating over CONS and one class of procedure when operating over CLNS.
CLNSの上で作動するとき、コンズと1つのクラスの手順の上で作動するとき、ISO Transportプロトコルは5つのクラスの手順を指定します。
The relationship of these ISO standards is illustrated below:
これらのISO規格の関係は以下で例証されます:
Transport Service User
|
|-ISO Transport Service Definition [ISO8072]
|
+--------------------------------------------------+
| Transport Service Provider |
| ISO Transport Protocol Specification [ISO8073] |
+--------------------------------------------------+
|
|-ISO Network Service Definition [ISO8348]
|
輸送サービス利用者| |-ISO輸送サービス定義[ISO8072]| +--------------------------------------------------+ | 輸送サービスプロバイダー| | ISO輸送プロトコル仕様[ISO8073]| +--------------------------------------------------+ | |-ISOネットワーク・サービス定義[ISO8348]|
2.2 ISO Transport over TCP (ITOT) Model
2.2 TCP(ITOT)モデルの上のISO輸送
This document defines a model which provides ISO Transport Service, with minor extensions, running over TCP.
このドキュメントはTCPをひいて、小さい方の拡大にISO Transport Serviceを提供するモデルを定義します。
The ISO 8072 Transport Service is supported with minor modifications. See section 3.1.
ISO8072Transport Serviceは小さい方の変更でサポートされます。 セクション3.1を見てください。
The ISO 8073 Transport Protocol with some modifications is used to provide the modified Transport Service.
いくつかの変更があるISO8073Transportプロトコルは、変更されたTransport Serviceを提供するのに使用されます。
The Transmission Control Protocol is used in place of the ISO 8348 to provide a CONS like service. See section 4.
通信制御プロトコルは、サービスのようなコンズを提供するのにISO8348に代わって使用されます。 セクション4を見てください。
This document specifies a simple encapsulation mechanism between the modified ISO 8073 Transport Protocol and the TCP.
このドキュメントは変更されたISO8073TransportプロトコルとTCPの間の簡単なカプセル化メカニズムを指定します。
Pouffary & Young Standards Track [Page 4] RFC 2126 ISO Transport on top of TCP March 1997
TCP行進1997の上のPouffaryとヤングStandards Track[4ページ]RFC2126ISO Transport
ISO 8073 Transport Protocol specifies five classes when operating over ISO 8348 CONS. This document specifies how to operate class 0 and 2 over TCP. This document does not prevent use of other classes from operating over TCP, but their specification is beyond the scope of this document.
ISO8348コンズの上で作動するとき、ISO8073Transportプロトコルは5つのクラスを指定します。 このドキュメントはTCPでクラス0と2を経営する方法を指定します。 このドキュメントは、他のクラスの使用がTCPの上で作動するのを防ぎませんが、それらの仕様はこのドキュメントの範囲を超えています。
The relationship of these standards is illustrated below:
これらの規格の関係は以下で例証されます:
Transport Service User
|
|-ISO Transport Service (modified)
|
+--------------------------------------------------+
| Transport Service Provider |
| ISO Transport Protocol (modified) Specification |
+--------------------------------------------------+
|
|-TCP as a Connection Oriented Network Service
|
輸送サービス利用者| |-ISO輸送サービス(変更されます)| +--------------------------------------------------+ | 輸送サービスプロバイダー| | ISOトランスポート・プロトコル(変更される)仕様| +--------------------------------------------------+ | |-接続の指向のネットワーク・サービスとしてのTCP|
2.3 Overview of Protocol and Service
2.3 プロトコルの、そして、サービスの概要
This document defines use of the ISO Transport Protocol (with some extensions) running over TCP. Two variants of the protocol are defined, "Class 0 over TCP" and "Class 2 over TCP", which are based closely on the ISO Transport Class 0 and 2 Protocol.
このドキュメントは、TCPをひきながら、ISO Transportプロトコル(いくつかの拡大を伴う)の使用を定義します。 プロトコルの2つの異形が、定義されて、「TCPの上で0を分類し」て、「TCPの上で2を分類する」(密接にISO Transport Class0と2プロトコルに基づいています)。
Section 3 defines the Service offered to the Transport User by this protocol, and shows the differences from the ISO Transport Service. The mapping between the Service primitives in the ISO Network Service and TCP are defined. Section 4 defines the Transport Protocol.
セクション3には、このプロトコルでTransport Userに提供されたServiceを定義して、差異がISO Transport Serviceからあります。 ISO Network ServiceとTCPのService基関数の間のマッピングは定義されます。 セクション4はTransportプロトコルを定義します。
3 Service Definition
3 サービス定義
This section describes the Transport Service offered to the Transport User. It also defines the mapping between the Network Service Definition and the TCP Service Definition.
このセクションはTransport Userに提供されたTransport Serviceについて説明します。 また、それはNetwork Service DefinitionとTCP Service Definitionの間のマッピングを定義します。
3.1 Transport Service Definition
3.1 輸送サービス定義
ISO 8072 Transport Service is supported with the following extensions:
ISO8072Transport Serviceは以下の拡大でサポートされます:
- Use of Quality of Service parameter is not defined
- ServiceパラメタのQualityの使用は定義されません。
- Access to Non-disruptive Transport Disconnection
- 非破壊的な輸送断線へのアクセス
Pouffary & Young Standards Track [Page 5] RFC 2126 ISO Transport on top of TCP March 1997
TCP行進1997の上のPouffaryとヤングStandards Track[5ページ]RFC2126ISO Transport
3.1.1 Transport Service Definition Primitives
3.1.1 輸送サービス定義基関数
Information is transferred to and from the TS-User in the Transport Service primitives listed below:
ユーザと以下にリストアップされたTransport Service基関数のTS-ユーザから情報を移します:
Actions
動作
T-CONNECT.REQUEST
- a TS-User indicates that it wants to establish transport
connection
T-CONNECT.REQUEST--TS-ユーザは、輸送接続を確立したがっているのを示します。
T-CONNECT.RESPONSE
- a TS-User indicates that it will honour the request
T-CONNECT.RESPONSE--TS-ユーザは、要求を尊敬するのを示します。
T-DISCONNECT.REQUEST
- a TS-User indicates that the transport connection is to
be closed
T-DISCONNECT.REQUEST--TS-ユーザは、輸送接続が閉店していることになっているのを示します。
T-DATA.REQUEST
- a TS-User sends data
T-DATA.REQUEST--TS-ユーザはデータを送ります。
T-EXPEDITED DATA.REQUEST
- a TS-User sends "expedited" data
T-EXPEDITED DATA.REQUEST--TS-ユーザは「速められた」データを送ります。
Events
イベント
T-CONNECT.INDICATION
- a TS-User is notified that a transport connection
establishment is in progress
T-CONNECT.INDICATION--TS-ユーザは輸送コネクション確立が進行しているように通知されます。
T-CONNECT.CONFIRMATION
- a TS-User is notified that the transport connection has been
established
T-CONNECT.CONFIRMATION--TS-ユーザは輸送接続が確立されたことに通知されます。
T-DISCONNECT.INDICATION
- a TS-User is notified that the transport connection is closed
T-DISCONNECT.INDICATION--TS-ユーザは輸送接続が閉じられるように通知されます。
T-DATA.INDICATION
- a TS-User is notified that data can be read from the transport
connection
T-DATA.INDICATION--TS-ユーザは輸送接続からデータを読むことができるように通知されます。
T-EXPEDITED_DATA.INDICATION
- a TS-User is notified that expedited data can be read from
the transport connection
T-EXPEDITED_DATA.INDICATION--TS-ユーザは輸送接続から速められたデータを読むことができるように通知されます。
Pouffary & Young Standards Track [Page 6] RFC 2126 ISO Transport on top of TCP March 1997
TCP行進1997の上のPouffaryとヤングStandards Track[6ページ]RFC2126ISO Transport
3.2 Network Service Definition
3.2 ネットワーク・サービス定義
This section describes how TCP is used to provide ISO 8348 CONS.
このセクションはTCPがISO8348コンズを提供するのにどう使用されるかを説明します。
3.2.1 ISO 8348 CONS primitives
3.2.1 ISO8348コンズ基関数
Information is transferred to and from the NS-provider in the Network Service Primitives listed below:
プロバイダーと以下に記載されたNetwork Service PrimitivesのNS-プロバイダーから情報を移します:
Actions
動作
N-CONNECT.REQUEST
- a NS-user indicates that it wants to establish a network
connection
N-CONNECT.REQUEST--NS-ユーザは、ネットワーク接続を確立したがっているのを示します。
N-CONNECT.RESPONSE
- a NS-user indicates that it will honour the request
N-CONNECT.RESPONSE--NS-ユーザは、要求を尊敬するのを示します。
N-DISCONNECT.REQUEST
- a NS-user indicates that the network connection is to be
closed
N-DISCONNECT.REQUEST--NS-ユーザは、ネットワーク接続が閉店していることになっているのを示します。
N-DATA.REQUEST
- a NS-user sends data
N-DATA.REQUEST--NS-ユーザはデータを送ります。
N-EXPEDITED_DATA.REQUEST
- a NS-user sends "expedited" data
N-EXPEDITED_DATA.REQUEST--NS-ユーザは「速められた」データを送ります。
Events
イベント
N-CONNECT.INDICATION
- a NS-user is notified that a network connection establishment
is in progress
N-CONNECT.INDICATION--NS-ユーザはネットワークコネクション確立が進行しているように通知されます。
N-CONNECT.CONFIRMATION
- a NS-user is notified that the network connection has been
established
N-CONNECT.CONFIRMATION--NS-ユーザはネットワーク接続が確立されたことに通知されます。
N-DISCONNECT.INDICATION
- a NS-user is notified that the network connection is closed
N-DISCONNECT.INDICATION--NS-ユーザはネットワーク接続が閉じられるように通知されます。
N-DATA.INDICATION
- a NS-user is notified that data can be read from the network
connection
N-DATA.INDICATION--NS-ユーザはネットワーク接続からデータを読むことができるように通知されます。
N-EXPEDITED_DATA.INDICATION
- a NS-user is notified that expedited data can be read from
the connection
N-EXPEDITED_DATA.INDICATION--NS-ユーザは接続から速められたデータを読むことができるように通知されます。
Pouffary & Young Standards Track [Page 7] RFC 2126 ISO Transport on top of TCP March 1997
TCP行進1997の上のPouffaryとヤングStandards Track[7ページ]RFC2126ISO Transport
3.2.2 TCP Service primitives
3.2.2 TCP Service基関数
The mapping between, ISO 8348 CONS primitives and TCP Service primitives, defined in this document assumes that the TCP offers the following service primitives:
TCPが以下のサービス基関数を提供する間のマッピングとISO8348コンズ基関数とTCP Service基関数、このドキュメントが仮定する定義されたコネ:
Actions
動作
TCP-LISTEN_PORT
- PASSIVE open on given port
TCP-LISTEN_PORT--与えられたポートで開いているPASSIVE
TCP-OPEN_PORT
- ACTIVE open to the given port
TCPオープン_PORT--与えられたポートに開かれているACTIVE
TCP-READ_DATA
- data is read from the connection
TCP-READ_DATA--データは接続から読まれます。
TCP-SEND_DATA
- data is sent on the connection
TCP-SEND_DATA--データを接続に送ります。
TCP-CLOSE
- the connection is closed (pending data is sent)
TCP-CLOSE--接続は閉じられます。(未定のデータを送ります)
Events
イベント
TCP-CONNECTED
- open succeeded (either ACTIVE or PASSIVE)
TCP-CONNECTED--戸外は成功しました。(アクティブであるか受動)です。
TCP-CONNECT_FAIL
- ACTIVE open failed
TCP-CONNECT_FAIL--ACTIVE戸外は失敗しました。
TCP-DATA_READY
- Data can be read from the connection
TCP-DATA_READY--接続からデータを読むことができます。
TCP-ERRORED
- the connection has errored and is now closed
TCP-ERRORED--接続は、erroredして、現在、閉店します。
TCP-CLOSED
- an orderly disconnection has started
TCP-CLOSED--規則的な断線は始まりました。
3.2.3 Mapping TCP as a Network Service Provider
3.2.3 ネットワークサービスプロバイダーとしてTCPを写像すること。
3.2.3.1 Network Connection Establishment
3.2.3.1 ネットワークコネクション確立
In order to perform a N-CONNECT.REQUEST action, the TS-Provider performs a TCP-OPEN_PORT to the desired IPv4 or IPv6 address using the selected TCP port. When the TCP signals either success or failure, this results in an N-CONNECT.INDICATION action.
N-CONNECT.REQUEST動作を実行するために、TS-プロバイダーは選択されたTCPポートを使用することで必要なIPv4かIPv6アドレスにTCPオープン_PORTを実行します。 TCPが成功か失敗のどちらかに合図するとき、これはN-CONNECT.INDICATION動作をもたらします。
Pouffary & Young Standards Track [Page 8] RFC 2126 ISO Transport on top of TCP March 1997
TCP行進1997の上のPouffaryとヤングStandards Track[8ページ]RFC2126ISO Transport
In order to await a N-CONNECT.INDICATION event, a server performs a TCP-LISTEN_PORT to the selected TCP port. When a client successfully connects to this port, the TCP-CONNECTED event occurs and an implicit N-CONNECT.RESPONSE action is performed.
N-CONNECT.INDICATIONイベントを待つために、サーバは選択されたTCPポートにTCP-LISTEN_PORTを実行します。 クライアントが首尾よくこのポートに接続するとき、TCP-CONNECTEDイベントは起こります、そして、暗黙のN-CONNECT.RESPONSE動作は実行されます。
Mapping parameters between the TCP service and the ISO 8348 CONS service is done as follow:
サービスが行われるTCPサービスとISO8348コンズ間のパラメタを写像して、続いてください:
Network Service TCP --------------- --- CONNECTION ESTABLISHMENT
ネットワーク・サービスTCP--------------- --- コネクション確立
Called address server's IPv4 or IPv6 address
and TCP port number.
サーバの着呼アドレスIPv4かIPv6アドレスとTCPが数を移植します。
Calling address client's IPv4 or IPv6 address
アドレスクライアントのIPv4かIPv6をアドレスと呼びます。
all others parameters ignored
無視されたすべての他のものパラメタ
Please also refer to 'Notes to Implementors' section 6.1.
また、'Implementorsへの注意'セクション6.1を参照してください。
TCP port 102 is reserved for implementations conforming to this specification. Use of any TCP port is conformant to this specification.
TCPポート102はこの仕様に従う実装のために予約されます。 どんなTCPポートの使用もこの仕様へのconformantです。
3.2.3.2 Network Data Transfer
3.2.3.2 ネットワークデータ転送
In order perform a N-DATA.REQUEST action, the TS-provider constructs the desired transport protocol data unit (TPDU), encapsulates the TPDU in a discrete unit called TPKT and uses the TCP-SEND_DATA primitive. Please also refer to 'Notes to Implementors' section 6.2.
N-DATA.REQUEST動作を実行するために、TS-プロバイダーは、原始的に必要なトランスポート・プロトコルデータ単位(TPDU)を構成して、TPKTと呼ばれる離散的なユニットでTPDUをカプセル化して、TCP-SEND_DATAを使用します。 また、'Implementorsへの注意'セクション6.2を参照してください。
In order to trigger a N-DATA.INDICATION action, the TCP indicates that data is ready through TCP-DATA_READY event and a TPKT is read using the TCP-READ_DATA primitive.
N-DATA.INDICATION動作の引き金となるように、TCPは、データがTCP-DATA_READYイベントを通して準備ができているのを示します、そして、TPKTは原始的にTCP-READ_DATAを使用することで読まれます。
Mapping parameters between the TCP service and the ISO 8348 CONS service is done as follow:
サービスが行われるTCPサービスとISO8348コンズ間のパラメタを写像して、続いてください:
Network Service TCP --------------- --- DATA TRANSFER
ネットワーク・サービスTCP--------------- --- データ転送
NS User Data (NSDU) DATA
ナノ秒、利用者データ(NSDU)データ
Pouffary & Young Standards Track [Page 9] RFC 2126 ISO Transport on top of TCP March 1997
TCP行進1997の上のPouffaryとヤングStandards Track[9ページ]RFC2126ISO Transport
3.2.3.3 Network Connection Release
3.2.3.3 ネットワークコネクション解放
In order to perform an N-DISCONNECT.REQUEST action, the TS-provider simply closes the TCP connection through TCP-CLOSE primitive.
N-DISCONNECT.REQUEST動作を実行するために、TS-プロバイダーは単に原始的にTCP-CLOSEを通したTCP接続を終えます。
In order to trigger a N-DISCONNECT.INDICATION, the TCP indicates that the connection has been closed through TCP-CLOSE event. If the TCP connection has failed the TCP indicates that the connection has been closed through TCP-ERRORED event, this trigger a N- DISCONNECT.INDICATION.
N-DISCONNECT.INDICATIONの引き金となるように、TCPは、接続がTCP-CLOSEイベントを通して閉店したのを示します。 TCP接続が失敗したなら、TCPは、接続がTCP-ERROREDイベントを通して閉店したのを示して、この引き金はN DISCONNECT.INDICATIONです。
Mapping parameters between the TCP service and the ISO 8348 CONS service is done as follow:
サービスが行われるTCPサービスとISO8348コンズ間のパラメタを写像して、続いてください:
Network Service TCP --------------- --- CONNECTION RELEASE
ネットワーク・サービスTCP--------------- --- コネクション解放
all parameters ignored
無視されたすべてのパラメタ
4. Transport Protocol Specification
4. トランスポート・プロトコル仕様
ISO 8073 Transport Protocol Classes 0 and 2 are supported with extensions as defined in each subsections below.
それぞれで以下の小区分を定義するとき、ISO8073TransportプロトコルClasses0と2は拡大でサポートされます。
A Transport Protocol class is selected for a particular transport connection based on the requirements of the TS-User.
TransportプロトコルのクラスはTS-ユーザの要件に基づく特定の輸送接続のために選択されます。
ISO 8073 Transport Protocol exchanges information between peers in discrete units of information called transport protocol data units (TPDU). The protocol defined in this document encapsulates these TPDUs in discrete units termed Packets (TPKT).
ISO8073Transportプロトコルはトランスポート・プロトコルデータ単位(TPDU)と呼ばれる離散的なユニットの情報の同輩の間で情報交換します。 本書では定義されたプロトコルはPackets(TPKT)と呼ばれた離散的なユニットでこれらのTPDUsをカプセル化します。
This document mandates the implementation of ISO 8073 Transport Protocol options negotiation (which includes class negotiation).
このドキュメントはISO8073Transportプロトコルオプション交渉(クラス交渉を含んでいる)の実装を強制します。
Please refer to 'Notes to Implementors' section 6.3 with respect to Class negotiation and to the 'Rationale' section 7. with respect to Interoperability with RFC1006.
RFC1006と共にInteroperabilityに関してClass交渉と'原理'セクション7への'Implementorsへの注意'セクション6.3を参照してください。
4.1 Class 0 over TCP
4.1 TCPの上のクラス0
Class 0 provides the functions needed for connection establishment with negotiation, data transfer with segmentation, and protocol error reporting. It provides Transport Connection with flow control based on that of the NS-provider (TCP). It provides Transport Disconnection based on the NS-provider Disconnection.
クラス0は交渉、分割があるデータ転送、およびプロトコル誤り報告をコネクション確立に必要である機能に提供します。 それはNS-プロバイダー(TCP)のものに基づくフロー制御をTransport Connectionに提供します。 それはNS-プロバイダーDisconnectionに基づくTransport Disconnectionを提供します。
Pouffary & Young Standards Track [Page 10] RFC 2126 ISO Transport on top of TCP March 1997
TCP行進1997の上のPouffaryとヤングStandards Track[10ページ]RFC2126ISO Transport
Class 0 is suitable for data transfer with no Explicit Transport Disconnection.
クラス0はExplicit Transport Disconnectionなしでデータ転送に適しています。
4.1.1 Connection Establishment
4.1.1 コネクション確立
The principles used in connection establishment are based upon those described in ISO 8073, with the following extensions:
コネクション確立に使用される原則は以下の拡大を伴うISO8073で説明されたものに基づいています:
- Connect Data may be exchanged using the user data fields
of Connect Request (CR) and Connect Confirm (CC) TPDUs
- 交換された使用がConnect Request(CR)とConnect Confirm(CC)TPDUsのユーザデータ・フィールドであったかもしれないならDataを接続してください。
- Use of "Expedited Data Transfer Service" may be negotiated
using the negotiation mechanism specified in ISO 8073. The
default is to not use "Expedited Data Transfer Service".
- 「速められたデータ転送サービス」の使用は、ISO8073で指定された交渉メカニズムを使用することで交渉されるかもしれません。 デフォルトは「速められたデータ転送サービス」を使用しないことです。
- Non-standard TPDU size may be negotiated using the negotiation
mechanism specified in ISO 8073. The maximum TPDU size is 65531
octets. The Default maximum TPDU size is 65531 octets.
Please refer to 'Notes to Implementors' section 6.4.
- 標準的でないTPDUサイズは、ISO8073で指定された交渉メカニズムを使用することで交渉されるかもしれません。 最大のTPDUサイズは65531の八重奏です。 Defaultの最大のTPDUサイズは65531の八重奏です。 'Implementorsへの注意'セクション6.4を参照してください。
4.1.2 Data Transfer
4.1.2 データ転送
The elements of procedure used during transfer are based upon those presented in ISO 8073, with the following extension:
転送の間の実行した手順の要素は以下の拡大を伴うISO8073に提示されたものに基づいています:
- Expedited Data may be supported (if negotiated during connection
establishment) by sending the defined Expedited Data (ED) TPDU.
- 速められたDataは、定義されたExpedited Data(エド)TPDUを送ることによって、サポートされるかもしれません(コネクション確立の間、交渉されるなら)。
The ED TPDU is sent inband on the same TCP connection as all of the other TPDUs.
ED TPDUは他のTPDUsのすべてと同じTCP接続に「不-バンド」を送ります。
To support Expedited Data a non-standard TPDU is defined. The format used for the ED TPDU is nearly identical to the format for the Normal Data (DT) TPDU. The only difference between ED TPDU and DT TPDU is that the value used for the TPDU code is ED and not DT. The size of a Expedited Data user data field is 1 to 16 octets.
Expedited Dataが標準的でないTPDUであるとサポートするのが定義されます。 Normal Data(DT)TPDUに、ED TPDUに使用される形式は形式とほとんど同じです。 ED TPDUとDT TPDUの唯一の違いはTPDUコードに使用される値がDTではなく、EDであるということです。 Expedited Dataユーザデータ・フィールドのサイズは1〜16の八重奏です。
For TPDU bit encoding please refer to 'Notes to Implementors' section 6.5.
TPDUビットコード化について、'Implementorsへの注意'セクション6.5を参照してください。
4.1.3 Connection Release
4.1.3 コネクション解放
The elements of procedure used during a connection release are identical to those presented in ISO 8073.
コネクション解放の間の実行した手順の要素はISO8073に提示されたものと同じです。
Transport Disconnection is based on the NS-provider (TCP) Disconnection and is therefore disruptive.
輸送DisconnectionはNS-プロバイダー(TCP)断線に基づいていて、したがって、破壊的です。
Pouffary & Young Standards Track [Page 11] RFC 2126 ISO Transport on top of TCP March 1997
TCP行進1997の上のPouffaryとヤングStandards Track[11ページ]RFC2126ISO Transport
4.2 Class 2 over TCP
4.2 TCPの上のクラス2
Class 2 provides the functions needed for connection establishment with negotiation, data transfer with segmentation, and protocol error reporting. It provides Transport Connection with flow control based on that of the NS-provider (TCP). It provides Explicit Transport Disconnection.
クラス2は交渉、分割があるデータ転送、およびプロトコル誤り報告をコネクション確立に必要である機能に提供します。 それはNS-プロバイダー(TCP)のものに基づくフロー制御をTransport Connectionに提供します。 それはExplicit Transport Disconnectionを提供します。
Class 2 is suitable when independence of Normal and Expedited Data channels are required or when Explicit Transport Disconnection is needed.
NormalとExpedited Dataチャンネルからの独立が必要である、またはExplicit Transport Disconnectionが必要であるときに、クラス2は適当です。
4.2.1 Connection Establishment
4.2.1 コネクション確立
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 use of "Transport Expedited Data Transfer" service.
"Transport Expedited Data Transfer" service is selected
by setting bit 1 of the "Additional Option" parameter,
and is negotiated using the mechanism specified in ISO 8073.
- 接続RequestとConnection Confirmation TPDUsは「輸送の速められたデータ転送」サービスの使用を交渉するかもしれません。 「輸送Expedited Data Transfer」サービスは、「追加オプション」パラメタのビット1を設定することによって選択されて、ISO8073で指定されたメカニズムを使用することで交渉されます。
The default is to not use "Transport Expedited Data Transfer
Service".
デフォルトは「輸送の速められたデータ転送サービス」を使用しないことです。
- Connection Request and Connection Confirmation TPDUs may
negotiate use of "Expedited Data Acknowledgement".
"Expedited Data Acknowledgement" is selected by setting
bit 6 of the "Additional Option" parameter, and is
negotiated using the mechanism specified in ISO 8073.
- 接続RequestとConnection Confirmation TPDUsは「速められたデータ承認」の使用を交渉するかもしれません。 「速められたData Acknowledgement」は、「追加オプション」パラメタのビット6を設定することによって選択されて、ISO8073で指定されたメカニズムを使用することで交渉されます。
The default is to not use "Expedited Data Acknowledgement"
for Expedited Data transfer.
デフォルトはExpedited Data転送に「速められたデータ承認」を使用しないことです。
- Connection Request and Connection Confirmation TPDUs may
negotiate use of the "Non-blocking Expedited Data" service.
"Non-blocking Expedited Data" is selected by setting
bit 7 of the "Additional Option" parameter, and is
negotiated using the mechanism specified in ISO 8073.
- 接続RequestとConnection Confirmation TPDUsは「非ブロッキングの速められたデータ」サービスの使用を交渉するかもしれません。 「非ブロッキングExpedited Data」は、「追加オプション」パラメタのビット7を設定することによって選択されて、ISO8073で指定されたメカニズムを使用することで交渉されます。
The default is to not use the "Non-blocking Expedited
Data" service.
デフォルトは「非ブロッキングの速められたデータ」サービスを利用しないことです。
- Connection Request and Connection Confirmation TPDUs may
negotiate use of either "Forward Connection (Splitting
and Recombining)" or "Reverse Connection" procedure for
Expedited Data transfer.
- 接続RequestとConnection Confirmation TPDUsは「前進の接続(分かれるのと再結合)」か「逆の接続」手順のどちらかのExpedited Data転送の使用を交渉するかもしれません。
Pouffary & Young Standards Track [Page 12] RFC 2126 ISO Transport on top of TCP March 1997
TCP行進1997の上のPouffaryとヤングStandards Track[12ページ]RFC2126ISO Transport
Use of "Forward Connection" or use of "Reverse Connection"
procedure is selected by setting bit 4 of the "Additional
Option" parameter, and is negotiated using the mechanism
specified in ISO 8073.
「前進の接続」の使用か「逆の接続」手順の使用が、「追加オプション」パラメタのビット4を設定することによって選択されて、ISO8073で指定されたメカニズムを使用することで交渉されます。
The default is to use "Forward Connection" procedure for
Expedited Data transfer.
デフォルトはExpedited Data転送に「前進の接続」手順を用いることです。
- Connection Request and Connection Confirmation TPDUs must not
negotiate the use of "Explicit Flow Control".
- 接続RequestとConnection Confirmation TPDUsは「明白なフロー制御」の使用を交渉してはいけません。
- Non-standard TPDU size may be negotiated using the negotiation
mechanism specified in ISO 8073. The maximum TPDU size is 65531
octets. The default maximum TPDU size is 65531 octets.
Please refer to 'Notes to Implementors' section 6.4.
- 標準的でないTPDUサイズは、ISO8073で指定された交渉メカニズムを使用することで交渉されるかもしれません。 最大のTPDUサイズは65531の八重奏です。 デフォルトの最大のTPDUサイズは65531の八重奏です。 'Implementorsへの注意'セクション6.4を参照してください。
In the absence of a Flow Control policy, the use of ISO 8073 Multiplexing procedure lead to degradation of the quality of service. The Protocol defined in this document does not supported Multiplexing.
Flow Control方針、サービスの質の低下へのISO8073Multiplexing手順リードの使用がないとき。 本書では定義されたプロトコルはどんなサポートしているMultiplexingもしません。
For the values of the "Additional Option" parameter please refer to 'Notes to Implementors' section 6.6.
「追加オプション」パラメタの値について、'Implementorsへの注意'セクション6.6を参照してください。
For Class 2 options Profile please also refer to 'Notes to Implementors' section 6.6.
また、Class2について、オプションProfileは'Implementorsへの注意'セクション6.6を示してください。
4.2.2 Data Transfer
4.2.2 データ転送
The elements of procedure used during transfer are based upon those presented in ISO 8073, with the following extensions:
転送の間の実行した手順の要素は以下の拡大を伴うISO8073に提示されたものに基づいています:
- Expedited Data may be supported (if negotiated during connection
establishment) by sending Expedited Data (ED) TPDU.
- 速められたDataは送付Expedited Data(エド)TPDUによってサポートされるかもしれません(コネクション確立の間、交渉されるなら)。
- "Expedited Data Acknowledgement" may be supported (if negotiated
during connection establishment) by sending Expedited Data
Acknowledgement (EA) TPDU.
- 「速められたData Acknowledgement」は送付Expedited Data Acknowledgement(EA)TPDUによってサポートされるかもしれません(コネクション確立の間、交渉されるなら)。
When using "Expedited Data Acknowledgement", ED TPDUs require
acknowledgement, and once an ED TPDU is transmitted no further
DT/ED TPDUs may be sent until the outstanding ED TPDU has been
acknowledged.
「速められたデータ承認」を使用するとき、ED TPDUsは承認を必要とします、そして、これ以上いったんED TPDUを伝えないと、傑出しているED TPDUが承認されるまで、DT/ED TPDUsを送るかもしれません。
When non-use of "Expedited Data Acknowledgement" has been
negotiated, ED TPDUs require no acknowledgement, and further DT/ED
TPDUs may be sent immediatly.
「速められたデータ承認」の非使用が交渉されたとき、ED TPDUsは承認を全く必要としません、そして、一層のDT/ED TPDUsを調停して送るかもしれません。
Pouffary & Young Standards Track [Page 13] RFC 2126 ISO Transport on top of TCP March 1997
TCP行進1997の上のPouffaryとヤングStandards Track[13ページ]RFC2126ISO Transport
Please refer to 'Notes to Implementors' section 6.7 and section
6.8.
'Implementorsへの注意'セクション6.7とセクション6.8を参照してください。
- "Non-blocking Expedited Data" service may be supported (if
negotiated during connection establishment).
- 「非ブロッキングExpedited Data」サービスはサポートされるかもしれません(コネクション確立の間、交渉されるなら)。
When using "Non-blocking Expedited Data" service, the sender of an
ED TPDU shall send the ED TPDU on both the Normal Data and
Expedited Data TCP connections. Transmission of subsequent DT TPDU
will not be interrupted. The receiver of ED TPDU counts how many
ED TPDU it has seen on each TCP connection, and will only deliver
to the TS-User the ED TPDU from the TCP connection with the higher
count.
「非ブロッキングの速められたデータ」サービスを利用するとき、ED TPDUの送付者はNormal DataとExpedited Data TCPの両方のED TPDUに接続を送るものとします。 その後のDT TPDUのトランスミッションは中断されないでしょう。 それがいくつのED TPDUカウントED TPDUを持つかに関する受信機は、それぞれのTCP接続のときに見て、ED TPDUをより高いカウントとのTCP関係からTS-ユーザに提供するだけでしょう。
When non-use of "Non-blocking Expedited Data" has been negotiated,
ED TPDUs will not be duplicated.
「非ブロッキングはデータを速めたこと」の非使用が交渉されたとき、ED TPDUsがコピーされないでしょう。
Please refer to 'Notes to Implementors' section 6.7 and section
6.8.
'Implementorsへの注意'セクション6.7とセクション6.8を参照してください。
- For Expedited Data transfer, there are two possible
procedures for the establishment and assignment of the Expedited
Data TCP connection. Which one is used is negotiated during
connection establishment.
- Expedited Data転送のために、Expedited Data TCP接続の設立と課題のための2つの可能な手順があります。 どれが使用されているかはコネクション確立の間、交渉されます。
Both the "Forward Connection" procedure and "Reverse Connection"
procedure guarantee independence of the Normal Data TCP connection
from the Expedited Data TCP connection. They also ensure that a
busy Normal Data TCP connection cannot block an Expedited Data TCP
connection.
ともに、「前進の接続」手順と「逆の接続」手順はExpedited Data TCP接続からNormal Data TCP接続からの独立を保証します。 また、彼らは、忙しいNormal Data TCP接続がExpedited Data TCP接続を妨げることができないのを確実にします。
The Expedited Data TCP connection created by either procedure must
be between the same pair of hosts as the Normal Data 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.
どちらの手順でも創造されたExpedited Data TCP接続は、Normal Data TCP接続への同じ組のホストの間には、あるに違いなくて、Transportコネクションズの中で共有されてはいけなくて、Transport Connectionがどの時にそれを閉じなければならないかとき終えられるまで、確立していたままでいなければなりません。
TCP connections created for Expedited Data transfer should also use
the TCP primitives defined in this document.
また、Expedited Data転送のために創造されたTCP接続は本書では定義されたTCP基関数を使用するべきです。
The Forward Connection (Splitting and Recombining) procedure is
defined in ISO 8073. This procedure allows a transport connection
to make use of multiple TCP connections. Please refer to 'Notes to
Implementors' section 6.9.
Forward Connection(分かれるのとRecombining)手順はISO8073で定義されます。 この手順で、輸送接続は複数のTCP接続を利用できます。 'Implementorsへの注意'セクション6.9を参照してください。
The Reverse Connection procedure is not defined in ISO 8073. When
using the Reverse Connection procedure the initiator of a Transport
Connection creates a Normal Data TCP connection using an
Reverse Connection手順はISO8073で定義されません。 Reverse Connection手順を用いるとき、Transport Connectionの創始者はNormal Data TCP接続使用を作成します。
Pouffary & Young Standards Track [Page 14] RFC 2126 ISO Transport on top of TCP March 1997
TCP行進1997の上のPouffaryとヤングStandards Track[14ページ]RFC2126ISO Transport
arbitrarily-chosen local TCP port 'x' and a known remote TCP port
(either the ITOT well-known port, or some other). The initiator
listens for an incoming TCP connection on the TCP port 'x'. The
responder of the Transport Connection must create a second TCP
connection (to be used for Expedited Data) using an arbitrarily-
chosen local TCP port 'y' and the remote TCP port 'x' , before it
can issue a CC TPDU on the Normal Data TCP connection. The
initiator need not listen for further TCP connections on port 'x'
after the Expedited Data TCP connection is established.
または、任意に地方のTCPポート'x'と知られている遠く離れたTCPポートを選ぶ、(ITOTウェルノウンポート、ある他の) 創始者はTCPポート'x'の上で入って来るTCP接続の聞こうとします。 Transport Connectionの応答者は任意に選ばれた地方のTCPポート'y'と遠く離れたTCPポート'x'を使用することで2番目のTCP接続(Expedited Dataに使用される)を創造しなければなりません、Normal Data TCP接続のときにCC TPDUを発行できる前に。 Expedited Data TCP接続が確立された後に創始者はポート'x'の上でさらなるTCP接続の聞こうとする必要はありません。
4.2.3 Connection Release
4.2.3 コネクション解放
The elements of procedure used during a connection release are based upon those described in ISO 8073. A connection can be terminated by the TS-user in one of two ways:
コネクション解放の間の実行した手順の要素はISO8073で説明されたものに基づいています。 TS-ユーザは2つの方法の1つで接続を終えることができます:
- Disruptive Disconnect
- 破壊的な分離
- Non-Disruptive Disconnect
- 非破壊的な分離
Disconnect Request (DR) and Disconnect Confirm (DC) TPDUs are exchanged in both cases. The DR TPDU carries a Reason code indicating the reason for the Disconnection.
どちらの場合も、分離Request(DR)とDisconnect Confirm(DC)TPDUsを交換します。 DR TPDUはDisconnectionの理由を示すReasonコードを運びます。
Disruptive Disconnect specifies that all TPDUs still at the source are not required to be sent to the destination before the connection is disconnected. The DR Reason code is normal (80 hex).
破壊的なDisconnectは、まだソースのすべてのTPDUsが接続から切断する前に目的地に送るのに必要であるというわけではないと指定します。 DR Reasonコードは正常です(80十六進法)。
Non-Disruptive Disconnect specifies that all TPDUs already given to the local TS-provider must be delivered to the remote TS-user, before the connection is disconnected. The DR Reason code is normal (80 hex) with Additional Information parameter value set to 80 hex.
非破壊的なDisconnectは、既にローカルのTS-プロバイダーに与えられたすべてのTPDUsをリモートTS-ユーザに提供しなければならないと指定します、接続切断される前に。 DR ReasonコードはAdditional情報パラメタ選択値群のために80十六進法に正常です(80十六進法)。
4.3 TPKT Packet Format
4.3 TPKTパケット・フォーマット
A fundamental difference between the TCP and the ISO Network Service expected by ISO Transport is that the TCP manages a continuous stream of octets, with no explicit boundaries.
ISO Transportによって予想されたTCPとISO Network Serviceの基本的な違いはTCPが八重奏の連続したストリームを管理するということです、明白な境界なしで。
ISO Transport expects information to be sent and delivered in discrete objects termed Network Service Data Units (NSDU). Although ISO Transport allows combination of more than one TPDU inside a single NSDU for the purposes of discussion an NSDU is identical to a TPDU. Please refer to ISO 8073 for the valid set of concatenated TPDUs.
ISO Transportは、情報がNetwork Service Data Units(NSDU)と呼ばれた離散的なオブジェクトで送られて、提供されると予想します。 ISO Transportは議論の目的のための独身のNSDUの中の1TPDUの組み合わせを許しますが、NSDUはTPDUと同じです。 連結されたTPDUsの有効なセットについてISO8073を参照してください。
Pouffary & Young Standards Track [Page 15] RFC 2126 ISO Transport on top of TCP March 1997
TCP行進1997の上のPouffaryとヤングStandards Track[15ページ]RFC2126ISO Transport
The protocol described by this memo uses a simple packetization scheme in order to delimit TPDU. Each packet (TPKT), is viewed as an object of variable length composed of an integral number of octets.
このメモで説明されたプロトコルは、TPDUを区切るのに簡単なpacketization体系を使用します。 各パケット(TPKT)による変数のオブジェクトとして見なされて、長さが構成されたということです。整数の八重奏について。
A TPKT consists of two part:
TPKTは2部分から成ります:
- a Packet Header
- パケットのヘッダー
- a TPDU.
- TPDU。
The format of the Packet Header is constant regardless of the type of TPDU. The format of the Packet Header is as follows:
Packet Headerの形式はTPDUのタイプにかかわらず一定です。 Packet Headerの形式は以下の通りです:
+--------+--------+----------------+-----------....---------------+ |version |reserved| packet length | TPDU | +----------------------------------------------....---------------+ <8 bits> <8 bits> < 16 bits > < variable length >
+--------+--------+----------------+-----------....---------------+ |バージョン|予約されます。| パケット長| TPDU| +----------------------------------------------....---------------+ 16ビットの8ビットの8ビットの<><><><可変長>。
where:
どこ:
- Protocol Version Number
length: 8 bits
Value: 3
- バージョンNumberの長さについて議定書の中で述べてください: 8ビットのValue: 3
- Reserved
length: 8 bits
Value: 0 - (See 'Notes to Implementors' section 6.10)
- 予約された長さ: 8ビットのValue: 0 - ('Implementorsへの注意'セクション6.10を見ます)
- Packet Length
length: 16 bits
Value: Length of the entire TPKT in octets, including Packet
Header
- パケットLengthの長さ: 16ビットのValue: Packet Headerを含む八重奏における、全体のTPKTの長さ
- TPDU
ISO Transport TPDU as defined in ISO 8073 and as defined in this
document.
- ISO8073、本書では定義されるように定義されるTPDU ISO Transport TPDU。
5. Address representations
5. アドレス表現
It is desirable to be able to represent ITOT access point addresses as:
それはITOTアクセスポイントアドレスを表すことができるのにおいて望ましいです:
- Printable strings
- 印刷可能なストリング
- OSI Network Addresses (often known as NSAP addresses
or simply NSAPAs)
- OSIネットワーク・アドレス(NSAPアドレスか単にNSAPAsとしてしばしば知られています)
This section defines the formats which MUST be used in each case.
このセクションはその都度使用しなければならない書式を定義します。
Pouffary & Young Standards Track [Page 16] RFC 2126 ISO Transport on top of TCP March 1997
TCP行進1997の上のPouffaryとヤングStandards Track[16ページ]RFC2126ISO Transport
5.1 String representation of ITOT access point addresses
5.1 ITOTアクセスポイントアドレスのストリング表現
RFC1278 [RFC1278] defines a general string representation for OSI Presentation Addresses, including specific reference to RFC1006 addresses which encapsulate IPv4 addresses. RFC1278 is also applicable to ITOT addresses which encapsulate IPv4 addresses.
RFC1278[RFC1278]はOSI Presentation Addressesの一般的なストリング表現を定義します、IPv4にアドレスをカプセル化するRFC1006アドレスの特定指示を含んでいて。 また、RFC1278もIPv4にアドレスをカプセル化するITOTアドレスに適切です。
This RFC is currently being updated to define a string representation for ITOT addresses which encapsulate IPv6 addresses.
現在、IPv6にアドレスをカプセル化するITOTアドレスのストリング表現を定義するためにこのRFCをアップデートしています。
ITOT access point address string representation specify an IP address (IPv4 or IPv6) and an optional TCP port number.
ITOTアクセスポイントアドレスストリング表現はIPアドレス(IPv4かIPv6)と任意のTCPポートナンバーを指定します。
5.2 OSI Network Address encoding
5.2 OSI Network Addressコード化
RFC1277 [RFC1277] defines a general mechanism to encode addressing information within OSI Network Addresses (NSAPA), including specific reference to RFC1006 using IPv4. RFC1277 is also applicable to ITOT addresses using IPv4.
RFC1277[RFC1277]はOSI Network Addresses(NSAPA)の中でアドレス指定情報をコード化するために一般的機構を定義します、IPv4を使用することでRFC1006の特定指示を含んでいて。 また、RFC1277もIPv4を使用するのにおいてITOTアドレスに適切です。
The RFC "IPv6 addresses inside an NSAPA" [IPv6] defines general mechanisms for the support of NSAP addressing in an IPv6 network. It also defines how to embed an IPv6 address inside a OSI NSAP address.
「IPv6はNSAPAの中で扱う」RFC[IPv6]はIPv6ネットワークにおける、NSAPアドレシングのサポートのために一般的機構を定義します。 また、それはOSI NSAPアドレスでIPv6アドレスを埋め込む方法を定義します。
This RFC is applicable to ITOT addresses using IPv6. For ITOT addresses, the default selector of the NSAPA is defined to have the value '10000000'B.
このRFCはIPv6を使用するのにおいてITOTアドレスに適切です。 ITOTアドレスにおいて、NSAPAのデフォルトセレクタは、値'10000000'のBを持つために定義されます。
It should be noted that given that an IPv6 addresses can encode IPv4 addresses, this format can also encode ITOT addresses using IPv4.
また、IPv6アドレスがIPv4アドレスをコード化できるなら、この形式がIPv4を使用するITOTアドレスをコード化できることに注意されるべきです。
6. Notes to Implementors
6. 作成者への注意
6.1 TCP Connection Establishment
6.1 TCPコネクション確立
Implementors should be aware that ISO transport protocols assume that they will be told by the network service provider (in this case TCP/IP) when the network connection being used to transmit their TPDUs is unexpectedly terminated. It is therefore strongly suggested that the TCP keep alive mechanism be selected, as this ensures reporting of network connection loss.
作成者はISOトランスポート・プロトコルが、それらがそれらのTPDUsを伝えるのに使用されているネットワーク接続がいつ不意に終えられるかネットワークサービスプロバイダー(この場合TCP/IP)によって言われると仮定するのを意識しているべきです。 したがって、強く示されて、TCPがメカニズムを生かすのは、そうです。選択されてください、これが、ネットワーク接続の損失について報告するのを確実にするとき。
6.2 TCP Data transfer
6.2 TCP Data転送
For performance reason it is suggested that the Nagle algorithm [RFC 896] be disabled (using the TCP_NODELAY socket option). This feature allows TPKT data to be sent without delay.
性能理由で、ネーグルアルゴリズム[RFC896]が無効にされることが提案されます(TCP_NODELAYソケットオプションを使用して)。 この特徴は、TPKTデータが即刻送られるのを許容します。
Pouffary & Young Standards Track [Page 17] RFC 2126 ISO Transport on top of TCP March 1997
TCP行進1997の上のPouffaryとヤングStandards Track[17ページ]RFC2126ISO Transport
6.3 Class negotiation
6.3 クラス交渉
The principle used in Class negotiation is identical to those described in ISO 8073. Class and options are negotiated during Connection establishment. The choice made by the Transport will depend upon the TS-User requirements as expressed via T-CONNECT service primitives.
Class交渉に使用される原則はISO8073で説明されたものと同じです。 クラスとオプションはConnection設立の間、交渉されます。 Transportによってされた選択はT-CONNECTサービス基関数で言い表されるようにTS-ユーザ要件によるでしょう。
The initiator of the Transport Connection proposes a preferred class and may propose an alternative class.
Transport Connectionの創始者は、都合のよいクラスを提案して、代替のクラスを提案するかもしれません。
The responder selects one class defined in the table below.
応答者は以下のテーブルで定義された1つのクラスを選択します。
If the preferred class is not selected then on receipt of the connect confirm TPDU the initiator adjusts its operation according to the class selected.
接続してください。都合のよいクラスがその時選択されない、選択されて、クラスに従って、創始者のTPDUが操作を調整すると確認してください。
+---------------------------------------------+----------------------+ | Proposed in CR TPDU | CC TPDU | | | | |Preferred class | Alternative class | Response | +--------------------+------------------------+----------------------+ | | | | |class 0 | none | class 0 | | | | | |class 2 | class 0 | class 2 or 0 | | | | | |class 2 | none | class 2 | | | | | +---------------------------------------------+----------------------+
+---------------------------------------------+----------------------+ | CR TPDUでは、提案されます。| CC TPDU| | | | |都合のよいクラス| 代替のクラス| 応答| +--------------------+------------------------+----------------------+ | | | | |クラス0| なし| クラス0| | | | | |クラス2| クラス0| クラス2か0| | | | | |クラス2| なし| クラス2| | | | | +---------------------------------------------+----------------------+
6.4 Default maximum TPDU size
6.4 デフォルトの最大のTPDUサイズ
The default maximum TPDU size value specified in this document breaks ISO Transport negotiation rule which states that the maximum TPDU size specified or defaulted by the CC TPDU cannot be greater than the maximum TPDU size proposed by the CR TPDU.
破るサイズ値がこれで指定した最大のTPDUが最大のTPDUサイズがCC TPDUで指定したか、またはデフォルトとしたと述べるISO Transport交渉規則をドキュメントであるデフォルトは最大のTPDUサイズがCR TPDUで提案したよりすばらしいはずがありません。
To avoid the consequences of this, it is strongly recommended that the CC TPDU always specifies the maximum TPDU size value.
この結果を避けるために、CC TPDUがいつも最大のTPDUサイズ価値を指定することが強く勧められます。
6.5 Class 0 TPDU bit encoding
6.5 クラス0TPDUはコード化に噛み付きました。
This protocol no longer allows credit and TPDU-NR (bits 0 to 6) fields to be ignored on input, which is in line with ISO 8073 encoding rules. RFC1006 TPDU encoding defined inconsistent encoding rules.
このプロトコルは、もうクレジットとTPDU-NR(ビット0〜6)分野が入力のときに無視されるのを許容しません。(ISO8073符号化規則に沿って入力があります)。 RFC1006 TPDUコード化は矛盾した符号化規則を定義しました。
Pouffary & Young Standards Track [Page 18] RFC 2126 ISO Transport on top of TCP March 1997
TCP行進1997の上のPouffaryとヤングStandards Track[18ページ]RFC2126ISO Transport
6.6 Class 2 Options
6.6 クラス2オプション
Class 2 Additional Option parameter value
クラス2Additional Optionパラメタ価値
+--------------------------------------------------------------------+ | BIT | OPTION | +--------------------------------------------------------------------+ | | | | 8 | Not applicable | | | | | 7 | = 1 Use of Non-blocking Expedited Data | | | = 0 Non-use of Non-blocking Expedited Data (default) | | | | |(*) 6 | = 1 Use of Expedited Data Acknowledgement | | | = 0 non-use of Expedited Data Acknowledgement (default) | | | | | 5 | Not applicable | | | | |(*) 4 | = 1 Use of Reverse Connection procedure | | | = 0 Use of Forward Connection procedure (default) | | | | | 3 | Not applicable | | | | | 2 | Not applicable | | | | | 1 | = 1 Use of Transport Expedited Data Service | | | = 0 Non-use of Transport Expedited Data Service (default) | | | | +--------------------------------------------------------------------+
+--------------------------------------------------------------------+ | ビット| オプション| +--------------------------------------------------------------------+ | | | | 8 | 適切でない| | | | | 7 | = 1 非ブロッキングの使用はデータを速めました。| | | = 0 非ブロッキングの非使用はデータ(デフォルト)を速めました。| | | | |(*) 6 | = 1 速められたデータ承認の使用| | | = 0 Expedited Data Acknowledgement(デフォルト)の非使用| | | | | 5 | 適切でない| | | | |(*) 4 | = 1 Reverse Connection手順の使用| | | = 0 Forward Connection手順(デフォルト)の使用| | | | | 3 | 適切でない| | | | | 2 | 適切でない| | | | | 1 | = 1 輸送の使用はデータサービスを速めました。| | | = 0 輸送の非使用はデータサービス(デフォルト)を速めました。| | | | +--------------------------------------------------------------------+
(*) In ISO 8073, bit 4 is defined as use of "Network Expedited" and bit 6 is defined as "Request Acknowledgement".
ISO8073の(*)、ビット4は「速められたネットワーク」の使用と定義されます、そして、ビット6は「要求承認」と定義されます。
Pouffary & Young Standards Track [Page 19] RFC 2126 ISO Transport on top of TCP March 1997
TCP行進1997の上のPouffaryとヤングStandards Track[19ページ]RFC2126ISO Transport
Class 2 Options Profile
クラス2オプションプロフィール
+--------------------------------------------------------------------+ | Bits Service selected | | 1 4 6 7 | +--------------------------------------------------------------------+ | 0 x x x Non-use of Transport Expedited Data Service | | ---------------------------------------------------------| | Bits 4 6 7 are not applicable (*) | +--------------------------------------------------------------------+ | 1 x x x Use of Transport Expedited Data Service | | ---------------------------------------------------------| | 1 0 x x Use of Expedited Data Service with Forward Connection| | -----------------------------------------------------| | 1 0 1 0 Forward Connection with Expedited Data | | Acknowledgement | | 1 0 1 1 Forward Connection with Expedited Data | | Acknowledgement and use of Non-blocking | | Expedited Data (**) | | --------------------------------------------| | 1 0 0 0 Forward Connection with non-use of Expedited| | Data Acknowledgement (***) | | 1 0 0 1 Forward Connection with non-use of Expedited| | Data Acknowledgement and use of Non-blocking| | Expedited Data | | -----------------------------------------------------| | 1 1 x x Use of Expedited Data Service with Reverse Connection| | -----------------------------------------------------| | 1 1 1 0 Reverse Connection with Expedited Data | | Acknowledgement | | 1 1 1 1 Reverse Connection with Expedited Data | | Acknowledgement and use of Non-blocking | | Expedited Data (**) | | --------------------------------------------| | 1 1 0 0 Reverse Connection with non-use of Expedited| | Data Acknowledgement (***) | | 1 1 0 1 Reverse Connection with non-use of Expedited| | Data Acknowledgement and use of Non-blocking| | Expedited Data | +--------------------------------------------------------------------+
+--------------------------------------------------------------------+ | Serviceが選択したビット| | 1 4 6 7 | +--------------------------------------------------------------------+ | 0 Transport Expedited Data Serviceを非使用しているx x x| | ---------------------------------------------------------| | ビット4 6 7は適切ではありません(*)。| +--------------------------------------------------------------------+ | 1 Transport Expedited Data Serviceのx x x使用| | ---------------------------------------------------------| | Forward ConnectionとのExpedited Data Serviceの1 0x x使用| | -----------------------------------------------------| | 速められたデータとの1 0 1 0の前進の関係| | 承認| | 速められたデータとの1 0 1 1の前進の関係| | Non-ブロッキングの承認と使用| | 速められたデータ(**)| | --------------------------------------------| | Expeditedの非使用がある1 0 0 0の前進のConnection| | データ承認(***)| | Expeditedの非使用がある1 0 0 1の前進のConnection| | Non-ブロッキングのデータAcknowledgementと使用| | 速められたデータ| | -----------------------------------------------------| | Reverse ConnectionとのExpedited Data Serviceの1 1x x使用| | -----------------------------------------------------| | 1 1 1 0は速められたデータとの関係を逆にします。| | 承認| | 1 1 1 1は速められたデータとの関係を逆にします。| | Non-ブロッキングの承認と使用| | 速められたデータ(**)| | --------------------------------------------| | 1 1 0 0はExpeditedの非使用でConnectionを逆にします。| | データ承認(***)| | 1 1 0 1はExpeditedの非使用でConnectionを逆にします。| | Non-ブロッキングのデータAcknowledgementと使用| | 速められたデータ| +--------------------------------------------------------------------+
(*) Note the default (0000) provides an RFC1006-like service with Explicit Transport Disconnection.
(*) デフォルト(0000)がRFC1006のようなサービスにExplicit Transport Disconnectionを提供することに注意してください。
(**) Note in this case use of Expedited Data Acknowledgement with use of Non-blocking Expedited Data is a wasted effort (See section 6.5)
(**) この場合、Nonを妨げているExpedited Dataの使用によるExpedited Data Acknowledgementの使用が無駄な取り組みであることに注意してください。(セクション6.5を見ます)
Pouffary & Young Standards Track [Page 20] RFC 2126 ISO Transport on top of TCP March 1997
TCP行進1997の上のPouffaryとヤングStandards Track[20ページ]RFC2126ISO Transport
(***) Note in this case Normal and Expedited Data TPDU are not synchronised. (See section 6.6)
この場合、NormalとExpedited Data TPDUがあるという(***)メモは連動しませんでした。 (セクション6.6を見ます)
6.7 Class 2 Expedited Data Acknowledgement
6.7 クラス2はデータ承認を速めました。
The Protocol specified in this document does not define any relationship between use of "Expedited Data Acknowledgement" option and use of "Non-blocking Expedited Data" service.
本書では指定されたプロトコルは「速められたデータ承認」オプションの使用と「非ブロッキングの速められたデータ」サービスの使用との少しの関係も定義しません。
However please note that when using "Non-blocking Expedited Data" service it is a wasted effort to use "Expedited Data Acknowledgement", since ED TPDUs are duplicated and sent on both the Normal Data and Expedited Data TCP connections.
しかしながら、使用するのが、無駄な取り組みであるサービスが「データ承認を速めた」という「非ブロッキングの速められたデータ」を使用するときにはそれに注意してください、Normal DataとExpedited Data TCP接続の両方でED TPDUsをコピーして、送るので。
6.8 Class 2 Normal Data and Expedited Data handling
6.8 クラス2Normal DataとExpedited Data取り扱い
There exist two separate application requirements for using Expedited Data:
Expedited Dataを使用するための2つの別々のアプリケーション要件が存在しています:
1- Synchronisation of the order of delivery between Normal
and Expedited Data TPDU.
1 NormalとExpedited Data TPDUの間の配送の注文の連動。
2- Independence of Normal and Expedited data channels. A busy
Normal Data channel should not block an Expedited Data channel.
2 NormalとExpeditedデータ・チャンネルからの独立。 忙しいNormal DataチャンネルはExpedited Dataチャンネルを妨げるべきではありません。
The protocol described in this document can accommodate both requirements, separately or in combination.
本書では説明されたプロトコルは別々にか組み合わせにおける両方の要件を収容できます。
Synchronisation:
If synchronised order of delivery between Normal and Expedited
Data TPDU is required then use of either "Expedited Data
Acknowledgement" TPDU or use of the "Non-blocking Expedited Data"
service must be negotiated during connection establishment.
連動: NormalとExpedited Data TPDUの間の配送の連動した注文を必要とするなら、コネクション確立の間、「速められたデータ承認」TPDUか「非ブロッキングの速められたデータ」サービスの使用のどちらかの使用を交渉しなければなりません。
If synchronised order of delivery between Normal and Expedited
Data TPDU is not required then non-use of "Expedited Data
Acknowledgement" need not be negotiated during connection
establishment.
NormalとExpedited Data TPDUの間の配送の連動した注文を必要としないなら、コネクション確立の間、「速められたデータ承認」の非使用を交渉する必要はありません。
Independence:
If Independence of Normal and Expedited data channels is required
then Forward or Reverse connection must be negotiated during
connection establishment. Expedited data TPDU must be sent on the
Expedited data channel.
独立: NormalとExpeditedデータ・チャンネルのIndependenceが必要であるなら、コネクション確立の間、ForwardかReverse接続を交渉しなければなりません。 Expeditedデータ・チャンネルで速められたデータTPDUを送らなければなりません。
Pouffary & Young Standards Track [Page 21] RFC 2126 ISO Transport on top of TCP March 1997
TCP行進1997の上のPouffaryとヤングStandards Track[21ページ]RFC2126ISO Transport
If Independence of Normal and Expedited data channels is not
required then Forward connection should be negotiated during
connection establishment and the Expedited data channels should
never be established. Expedited data TPDU is then sent inband on
the Normal data channel.
NormalとExpeditedデータ・チャンネルのIndependenceは必要でないなら、Forward接続がコネクション確立の間、交渉されるべきです、そして、Expeditedデータ・チャンネルは決して確立されるべきではありません。 そして、Normalデータ・チャンネルで速められたデータTPDUに「不-バンド」を送ります。
Finally please note that independence of Normal and Expedited data channels without synchronisation relaxes the Transport Service definition of Expedited data and is not consistent with ISO 8072.
最終的に、連動のないNormalとExpeditedデータ・チャンネルからの独立は、ExpeditedデータのTransport Service定義を弛緩して、ISO8072と一致していません。
6.9 Class 2 Forward Connection procedure
6.9 クラス2Forward Connection手順
As defined in ISO 8073, when "Forward Connection" (Splitting and Recombining) procedure is used for Expedited Data transmission, ED TPDU must only be sent over an outgoing NS-provider TCP connection.
ISO8073年に定義されるように、外向的なNS-プロバイダーTCP接続の上にED TPDUを送るだけでよいです。(その時、「前進の接続」(分かれるのとRecombining)手順はExpedited Dataトランスミッションに用いられます)。
As defined in ISO 8073, this document does not mandates use of the Splitting procedure for Expedited Data transmission. The Recombination procedure, which associates Data (normal and expedited) TPDUs arriving for a transport connection over two TCP connections must be handled.
ISO8073で定義されるように、このドキュメントはSplitting手順のExpedited Dataトランスミッションの使用をどんな命令にもしません。 Recombination手順であり、どれが輸送接続のために2つのTCP接続の上で到着するData(正常で速められた)TPDUsを関連づけるか扱わなければなりません。
It is legal to send Expedited Data TPDU inband on the Normal Data TCP connection.
Normal Data TCP接続にExpedited Data TPDU inbandを送るのは法的です。
Please note that the protocol specified in this document does not define when an Expedited Data TCP connection should be established. This is an implementation choice.
本書では指定されたプロトコルは、Expedited Data TCP接続がいつ確立されるべきであるかを定義しません。 これは実装選択です。
When using "Non-blocking Expedited Data" service it is recommended to not delay establishing Expedited Data TCP connection.
「非ブロッキングの速められたデータ」サービスを利用するとき、Expedited Data TCP接続を確立するのを遅らせないのはお勧めです。
6.10 TPKT
6.10 TPKT
This document specifies the value of the TPKT reserved field.
このドキュメントはTPKTの予約された分野の値を指定します。
Implementation should not interpret and act upon any value in a reserved field. To avoid Interoperability issues with RFC1006, this field should be ignored on input.
実装は、予約された分野の少しの値も解釈して、作用するべきではありません。 RFC1006のInteroperability問題を避けるために、この分野は入力のときに無視されるべきです。
7. Rationale - Interoperability with RFC1006
7. 原理--RFC1006がある相互運用性
We have chosen to maintain the same TPKT protocol version in ITOT as in RFC1006 (version 3). The reason for this decision is that the changes in this document do not conflict with RFC1006. If we were to change the protocol version we would prevent existing RFC1006 implementations which mandate version 3 from interoperating with the protocol defined in this document.
私たちは、RFC1006(バージョン3)のようにITOTの同じTPKTプロトコルバージョンを維持するのを選びました。 この決定の理由は変化が本書ではRFC1006と衝突しないということです。 私たちがプロトコルバージョンを変えるなら、プロトコルで共同利用するのからの命令バージョン3が本書では定義した既存のRFC1006実装を防ぐでしょうに。
Pouffary & Young Standards Track [Page 22] RFC 2126 ISO Transport on top of TCP March 1997
TCP行進1997の上のPouffaryとヤングStandards Track[22ページ]RFC2126ISO Transport
One consequence of this decision relates to class negotiation. The protocol described in this document introduces Class 2 over TCP, and it therefore introduces the need to be able to perform class negotiation between Class 2 and Class 0. While all Transport implementations should be able to handle Class negotiation, we recognise that some RFC1006 implementations cannot. Therefore Implementors should be aware that Class 2 Connect Request (with no Alternative class) could be accepted with a Class 0 Connect Confirm, at which point the Connect Confirm should be rejected as specified in ISO 8073.
この決定の1つの結果がクラス交渉に関連します。 本書では説明されたプロトコルはTCPの上にClass2を紹介します、そして、したがって、それはClass2とClass0とのクラス交渉を実行できる必要性を紹介します。 すべてのTransport実装がClass交渉を扱うことができるべきである間、私たちは、いくつかのRFC1006実装がそうすることができないと認めます。 したがって、ImplementorsがClass0Connect Confirmと共にClass2Connect Request(Alternativeのクラスのない)を受け入れることができたのを意識しているべきである、Connect Confirmがどのポイントで拒絶されるべきであるかはISO8073で指定しました。
8. Security Considerations
8. セキュリティ問題
Security issues are not specifically addressed in this document. Operation of this protocol is no more and no less secure than operation of TCP and ISO 8073 protocols. The reader is directed there for further reading.
安全保障問題は明確に本書では扱われません。 このプロトコルの操作は、TCPとISO8073プロトコルの操作ほど多くでなくてまたより安全でないというわけではありません。 読者は、さらに読書するためにそこで指示されます。
Acknowledgements
承認
The authors are pleased to acknowledge the suggestions and comments of Harald T. Alvestrand, Jim Bound, John Day, Mike Dyer, Peter Furniss, Dan Harrington, Steve Kille, Keith G. Knightson, Keith Sklower, Matt Thomas, Robert Watson and many other members of the IETF TOSI mailing list. The support of Allison Mankin of the IESG was essential.
作者は、ハラルドT.Alvestrand、ジムBound、ジョンデイマイクDyer、ピーター・ファーニス、ダン・ハリントン、スティーブKille、キースG.Knightson、キースSklower、マット・トーマス、ロバート・ワトソン、およびIETF TOSIメーリングリストの多くの他のメンバーの提案とコメントを承諾して、嬉しいです。 IESGのアリソン・マンキンのサポートは不可欠でした。
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." ISO 8073:1992 and 8073:1992/Amd.5:1995.
[ISO8073]ISO。 「国際規格8073。」 情報処理システム--オープン・システム・インターコネクション: 「プロトコル仕様を輸送してください。」 1992とISO8073:8073: 1992/Amd.5:1995。
[ISO8348] ISO. "International Standard 8348. Information Processing
Systems - Open Systems Interconnection: Network Service
Definition."
[ISO8348]ISO。 「国際規格8348。」 情報処理システム--オープン・システム・インターコネクション: 「サービス定義をネットワークでつないでください。」
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC791] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[RFC793] ポステル、J.、「通信制御プロトコル」、STD7、RFC793、1981年9月。
Pouffary & Young Standards Track [Page 23] RFC 2126 ISO Transport on top of TCP March 1997
TCP行進1997の上のPouffaryとヤングStandards Track[23ページ]RFC2126ISO Transport
[RFC896] Nagle, J., "Congestion Control in IP/TCP Inertnetworks",
RFC 896, January 1984.
[RFC896] ネーグル、J.、「IP/TCP Inertnetworksの輻輳制御」、RFC896、1984年1月。
[RFC1006] Rose, M., and D. Cass, "ISO Transport Services on Top of
the TCP Version 3", STD 35, RFC 1006, May 1987.
上、[RFC1006] ローズ、M.、およびD.キャス、「ISOがサービスを輸送する、TCPバージョン、3インチ、STD35、RFC1006(1987インチ年5月)
[RFC1277] Hardcastle-Kille, S., "Encoding Network Addresses to
support operation over non-OSI lower layers", RFC 1277,
November 1991.
S. [RFC1277]Hardcastle-Kille、1991年11月、「非OSIの低級層の上の操作をサポートするためにNetwork Addressesをコード化すること」でのRFC1277。
[RFC1278] Hardcastle-Kille, S., "String encoding of Presentation
Address", RFC 1278, November 1991.
[RFC1278] Hardcastle-Kille、S.、「Presentation Addressのストリングコード化」、RFC1278、1991年11月。
A string encoding of Presentation Address
update to RFC1278, Work in Progress.
RFC1278、ProgressのWorkへのPresentation Addressアップデートの五弦コード化。
[RFC1859] Pouffary, Y., "ISO Transport Class 2 Non-use of Explicit
Flow Control over TCP - RFC1006 extension", RFC 1859,
October 1995.
[RFC1859]Pouffary、Y.、「2がNon使用するTCPの上のExplicit Flow ControlのISO Transport Class--、RFC1006拡張子、」、RFC1859(1995年10月)
[IPV6] Deering, S., and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 1883, December 1995.
[IPV6]のデアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC1883、12月1995日
Hinden,, R., and S. Deeing, "IP Version 6 Addressing
Architecture", RFC 1884, December 1995.
Hindenである、R.、およびS.Deeing、「IPバージョン6アドレッシング体系」、RFC1884、12月1995日
Bound, J., Carpenter, B., Harrington, D., Houldsworth, J.,
and A. Lloyd, "OSI NSAPs and IPv6", RFC 1888, August 1996.
バウンドとJ.と大工とB.とハリントンとD.とHouldsworth、J.とA.ロイドと「OSI NSAPsとIPv6"、RFC1888、1996年8月。」
Pouffary & Young Standards Track [Page 24] RFC 2126 ISO Transport on top of TCP March 1997
TCP行進1997の上のPouffaryとヤングStandards Track[24ページ]RFC2126ISO Transport
Authors' Addresses
作者のアドレス
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-35 EMail: pouffary@taec.enet.dec.com
以下に電話をしてください。 +33 92-95-62-85Fax: +33 92-95-62-35 メールしてください: pouffary@taec.enet.dec.com
Alan Young ISODE Consortium The Dome The Square Richmond, UK
アランヤングISODE共同体のドームの正方形のリッチモンド、イギリス
Phone: +44 181 332 9091 Fax: +44 181 332 9019 EMail: A.Young@isode.com
以下に電話をしてください。 +44 181 332、9091Fax: +44 9019年の181 332メール: A.Young@isode.com
Pouffary & Young Standards Track [Page 25]
Pouffaryと若い標準化過程[25ページ]
一覧
スポンサーリンク
