RFC1963 日本語訳
1963 PPP Serial Data Transport Protocol (SDTP). K. Schneider, S.Venters. August 1996. (Format: TXT=38185 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group K. Schneider
Request for Comments: 1963 S. Venters
Category: Informational ADTRAN, Inc.
August 1996
コメントを求めるワーキンググループK.シュナイダーの要求をネットワークでつないでください: 1963秒間母カテゴリ: 情報のADTRAN Inc.1996年8月
PPP Serial Data Transport Protocol (SDTP)
pppシリアルデータトランスポート・プロトコル(SDTP)
Status of This 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.
このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols for establishing and configuring different network-layer protocols.
Pointからポイントへのプロトコル(PPP)[1]はポイントツーポイント接続の上でマルチプロトコルデータグラムを輸送するための標準方法を提供します。 PPPは、異なったネットワーク層プロトコルを設立して、構成するために広げることができるLink Controlプロトコルを定義して、Network Controlプロトコルのファミリーを提案します。
This document describes a new Network level protocol (from the PPP point of view), PPP Serial Data Transport Protocol, that provides encapsulation and an associated control protocol for transporting serial data streams over a PPP link. This protocol was developed for the purpose of using PPP's many features to provide a standard method for synchronous data compression. The encapsulation uses a header structure based on that of the ITU-T Recommendation V.120 [2].
このドキュメントは新しいNetwork平らなプロトコル(PPP観点からの)、PPPリンクの上にシリアルデータストリームを輸送するのにカプセル化と関連制御プロトコルを提供するPPP Serial Data Transportプロトコルについて説明します。 このプロトコルは同期データ圧縮に標準方法を提供するPPPの多くの特徴を使用する目的のために開発されました。 カプセル化はITU-T Recommendation V.120[2]のものに基づくヘッダー構造を使用します。
Table of Contents
目次
1. Introduction .......................................... 2
2. SDTP Packets .......................................... 3
2.1 Padding ......................................... 4
2.2 Packet Formats .................................. 4
3. Serial Data Control Protocol .......................... 11
4. SDCP Configuration Option Format ...................... 12
4.1 Packet-Format ................................... 13
4.2 Header-Type ..................................... 13
4.3 Length-Field-Present ............................ 14
4.4 Multi-Port ...................................... 14
4.5 Transport-Mode .................................. 15
4.6 Maximum-Frame-Size .............................. 16
4.7 Allow-Odd-Frames ................................ 16
4.8 FCS-Type ........................................ 17
4.9 Flow-Expiration-Time ............................ 18
SECURITY CONSIDERATIONS ...................................... 19
1. 序論… 2 2. SDTPパケット… 3 2.1 そっと歩きます… 4 2.2 パケット形式… 4 3. 連続のデータコントロールは議定書を作ります… 11 4. SDCP設定オプション形式… 12 4.1 パケット形式… 13 4.2 ヘッダーでタイプしてください… 13 4.3長さの分野プレゼント… 14 4.4 マルチポート… 14 4.5交通機関… 15 4.6 最大のフレーム・サイズ… 16 4.7 変なフレームを許容してください… 16 4.8 FCSタイプしてください… 17 4.9 流れ満了時間… 18 セキュリティ問題… 19
Schneider & Venters Informational [Page 1] RFC 1963 PPP SDTP August 1996
[1ページ]RFC1963ppp SDTP1996年8月の情報のシュナイダーと母
REFERENCES ................................................... 19
CHAIR'S ADDRESS .............................................. 20
AUTHORS' ADDRESSES ........................................... 20
参照… 19 議長のアドレス… 20人の作者のアドレス… 20
1. Introduction
1. 序論
This document is a product of the TR30.1 ad hoc committee on compression of synchronous data. It represents a component of a proposal to use PPP to provide compression of synchronous data in DSU/CSUs.
このドキュメントは同期データの要約のTR30.1専門委員会の製品です。 それはDSU/CSUsでの同期データの要約を提供するのにPPPを使用するという提案の成分を表します。
In addition to providing support for multi-protocol datagrams, the Point-to-Point Protocol (PPP) [1] has defined an effective and robust negotiating mechanism that can be used on point to point links. When used in conjunction with the PPP Compression Control Protocol [3] and one of the PPP Compression Protocols [4-10], PPP provides an interoperable method of employing data compression on a point-to- point link.
マルチプロトコルデータグラムのサポートを提供することに加えて、Pointからポイントへのプロトコル(PPP)[1]はリンクを指すのにポイントの上で使用できる有効で強健な交渉メカニズムを定義しました。 PPP Compression Controlプロトコル[3]とPPP Compressionプロトコル[4-10]の1つに関連して使用されると、PPPはポイントからポイントへのリンクの上にデータ圧縮を使う共同利用できるメソッドを提供します。
This document provides a PPP encapsulation for serial data, specifying a transport protocol, PPP Serial Data Transport Protocol (PPP-SDTP), and an associated control protocol, PPP Serial Data Control Protocol (PPP-SDCP). When these protocols are added to above mentioned PPP protocols, PPP can be used to provide compression of serial data on a point-to-point link.
このドキュメントはPPPカプセル化をシリアルデータに提供します、トランスポート・プロトコル、PPP Serial Data Transportプロトコル(PPP-SDTP)、および関連制御プロトコル(PPP Serial Data Controlプロトコル(PPP-SDCP))を指定して これらのプロトコルが上記のPPPプロトコルに追加されるとき、ポイントツーポイント接続におけるシリアルデータの要約を提供するのにPPPを使用できます。
This first edition of PPP-SDTP/SDCP covers HDLC-like synchronous serial data and asynchronous serial data. It does this by using a terminal adaption header based on that of ITU-T Recommendation V.120 [2]. Support may be added in the future for other synchronous protocols as the marketplace demands.
PPP-SDTP/SDCPのこの初版はHDLCのような同期シリアルデータと非同期なシリアルデータを含んでいます。 それは、ITU-T Recommendation V.120[2]のものに基づく端末の適応ヘッダーを使用することによって、これをします。 市場が要求するようにサポートは将来、他の同期プロトコルのために加えられるかもしれません。
The V.120 terminal adaption header allows transported data frames to be split over several packets, supports the transport of DTE port idle and error information, and optionally supports the transport of DTE control state information.
V.120の端末の適応ヘッダーは、輸送されたデータフレームがいくつかのパケットの上で分けられるのを許容して、DTEポート活動していない、そして、誤り情報の輸送をサポートして、任意にDTEコントロール州の情報の輸送をサポートします。
In addition to the V.120 Header, fields can be added to the packet format through negotiation to provide support for features not included in the V.120 header. The extra fields are: a Length Field, which is used to distinguish packets in compound frames, and a Port field, which is used to provide multi-port multiplexing capability. The protocol also allows reserved bits in the V.120 header to be used to transport non-octet aligned frames and to provide a flow control mechanism.
V.120 Headerに加えて、V.120ヘッダーに含まれていなかった特徴のサポートを提供するために交渉でパケット・フォーマットに分野を加えることができます。 付加的な分野は以下の通りです。 (Length Fieldは、合成フレームでパケットを区別するのに使用されます)。Length FieldとPort分野。(それは、能力を多重送信しながらマルチポートを提供するのに使用されます)。 また、プロトコルは、V.120ヘッダーの予約されたビットが非八重奏の並べられたフレームを輸送して、フロー制御メカニズムを提供するのに使用されるのを許容します。
Schneider & Venters Informational [Page 2] RFC 1963 PPP SDTP August 1996
[2ページ]RFC1963ppp SDTP1996年8月の情報のシュナイダーと母
To provide these features, PPP-SDTP permits a single frame format to be selected from several possible formats by using PPP-SDCP negotiation. The terminal adaption header can be either fixed length or variable length, to allow either simplicity or flexibility.
これらの特徴を提供するために、PPP-SDTPは、シングルフレーム形式がいくつかの可能な形式からPPP-SDCP交渉を使用することによって選択されるのを可能にします。 端末の適応ヘッダーは、簡単さか柔軟性のどちらかを許容するためには固定長か可変長のどちらかであるかもしれません。
The default frame format places the terminal adaption header at the end of the packet. This permits optimal transmitter timelines when user frames are segmented and compression is also used in conjunction with this protocol.
デフォルトフレーム形式は端末の適応ヘッダーをパケットの端に置きます。 ユーザフレームが区分されて、圧縮がまた、このプロトコルに関連して使用されるとき、これは最適の送信機スケジュールを可能にします。
2. SDTP Packets
2. SDTPパケット
Before any SDTP packets may be communicated, PPP must reach the Network-Layer Protocol phase, and the SDTP Control Protocol must reach the Opened state.
どんなSDTPパケットも伝えられるかもしれない前に、PPPはNetwork-層のプロトコルフェーズに達しなければなりません、そして、SDTP ControlプロトコルはOpened状態に達しなければなりません。
By default, exactly one SDTP packet is encapsulated in the PPP Information field, where the PPP Protocol field indicates type hex 0049 (PPP-SDTP). If the Length-Field-Present Configuration Option and the LCP Compound-Frames Configuration Option are successfully negotiated, multiple SDTP packets may be placed in the PPP Information field, and they are distinguished by the presence of Length fields in each packet.
デフォルトで、ちょうど1つのSDTPパケットがPPP情報分野でカプセルに入れられます。そこで、PPPプロトコル分野は、タイプが0049(PPP-SDTP)人に魔法をかけるのを示します。 LengthがプレゼントをさばいているConfiguration OptionとLCP Compound-フレームであるなら、Configuration Optionは首尾よく交渉されます、そして、複数のSDTPパケットがPPP情報分野に置かれるかもしれません、そして、それらは各パケットでのLength分野の存在によって区別されます。
The maximum length of the SDTP datagram transmitted over a PPP link is limited only by the negotiated Maximum-Frame-Size and the maximum length of the Information field of a PPP encapsulated packet. Note that if compression is used on the PPP link, this the maximum length of the SDTP datagram may be larger or smaller than the maximum length of the Information field of a PPP encapsulated packet, depending on the particular compression algorithm and protocol used.
PPPリンクの上に送られたSDTPデータグラムの最大の長さは交渉されたMaximumフレームサイズとパケットであるとカプセル化されたPPPの情報分野の最大の長さだけによって制限されます。 圧縮がPPPリンクの上に使用されるなら、それに注意してください、これ。最大の長さのSDTPデータグラムは、PPPの情報分野の最大の長さがパケットをカプセルに入れったよりさらに大きいか、または小さいかもしれません、使用される特定の圧縮アルゴリズムとプロトコルによって。
ITU-T Recommendation V.120 [2] defines an adaption header that is used with its asynchronous and synchronous modes of operation. SDTP packets include this header as a Header field to provide the protocol adaption function. Using negotiation, additional fields can be added to the packet to provide sequencing and multiplexing capability within SDTP. SDTP also has an option of using the reserved bits of the header to provide a flow control mechanism and support for transporting non-octet aligned data frames.
ITU-T Recommendation V.120[2]はその操作の非同期、そして、同期モードと共に使用される適応ヘッダーを定義します。 SDTPパケットは、プロトコル適応機能を提供するためにHeader分野としてこのヘッダーを含んでいます。 交渉を使用して、SDTPの中で能力を配列して、多重送信しながら提供するために追加分野をパケットに加えることができます。 また、SDTPには、フロー制御メカニズムを提供して、非八重奏の並べられたデータを輸送するためにフレームを支えるのにヘッダーの予約されたビットを使用するオプションがあります。
The default SDTP packet format is designed to allow the efficient use of the protocol's segmentation feature when combined with a PPP Compression Protocol [4-10]. This format is a little different from other PPP NCP's in that data is read from both ends of the packet. The Header field is placed at the end of the SDTP packet, with the order of the octets reversed. This somewhat unique format has been selected to allow optimal transmitter timelines when compression is
PPP Compressionプロトコル[4-10]に結合されると、デフォルトSDTPパケット・フォーマットは、プロトコルの分割機能の効率的な使用を許すように設計されます。 この形式はPPP NCPの他のものとデータがパケットの両端から読まれるという点において少し異なっています。 Header野原はSDTPパケットの端に八重奏の注文を逆にしていて置かれます。 圧縮が許容するとき、このいくらかユニークな形式が最適の送信機スケジュールを許容するのが選択されました。
Schneider & Venters Informational [Page 3] RFC 1963 PPP SDTP August 1996
[3ページ]RFC1963ppp SDTP1996年8月の情報のシュナイダーと母
used and transported data frames are split into multiple SDTP packets. In such a situation, the Header field contains the information about whether the data is split into multiple packets or not, so if it is located at the end of a packet, the decision can be made after observing the compressed size of the packet. The Header field can then simply be run through the compressor after the decision has been made.
中古の、そして、輸送されたデータフレームは複数のSDTPパケットに分けられます。 そのような状況で、Header分野がデータが複数のパケットに分けられるかどうかの情報を含んでいるので、パケットの端にそれを位置させるなら、パケットの圧縮されたサイズを観測した後に、決定をすることができます。 そして、決定をした後にコンプレッサーを通して単にHeader分野を実行できます。
When the Header field is placed before the data, as in the optional packet format, the transmitter must make the decision about whether to split a frame over multiple packets without knowing about the compressibility of the frame. Therefore the optional format is designed to be used when transported frames are not split into multiple SDTP packets or where SDTP is not coupled with compression. It is believed that this format may be useful for some hardware implementations.
Header野原がデータの前に任意のパケット・フォーマットのように置かれるとき、送信機は複数のパケットの上でフレームの圧縮性に関して知らないでフレームを分けるかどうかに関する決定をしなければなりません。 したがって、任意の形式は、輸送されたフレームが複数のSDTPパケットに分けられないか、またはSDTPが圧縮に結びつけられないところで使用されるように設計されています。 この形式がいくつかのハードウェア実装の役に立つかもしれないと信じられています。
2.1. Padding
2.1. 詰め物
If padding is used, SDTP packets require the use of the Length Field or the previous negotiation of the LCP Self-Describing-Padding Configuration Option [11].
詰め物が使用されているなら、SDTPパケットはLength Fieldの使用かそっと歩くと説明するLCP Self Configuration Option[11]の前の交渉を必要とします。
2.2. Packet Formats
2.2. パケット・フォーマット
The default SDTP packet format is shown below. The fields are transmitted from left to right.
デフォルトSDTPパケット・フォーマットは以下に示されます。 野原は左から右まで伝えられます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PPP Protocol ID | Transported Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Header - H |
+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | pppプロトコルID| データを輸送します… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ヘッダー--H| +-+-+-+-+-+-+-+-+
The two complete frame formats are shown below: Header-Last and Header-First. Header-Last is the default packet format. The additional fields provided support for: Control State Information (CS), multiple packets and multi-port multiplexing. Again, the fields are transmitted from left to right. Descriptions of the fields follow the packet formats.
2つの完全なフレーム形式が以下に示されます: ヘッダー最終とヘッダー-1番目。 ヘッダー最終はデフォルトパケット・フォーマットです。 追加分野は以下のサポートを提供しました。 州情報(CS)、複数のパケット、およびマルチポートマルチプレクシングを制御してください。 一方、野原は左から右まで伝えられます。 分野の記述はパケット・フォーマットを次に続かせています。
Schneider & Venters Informational [Page 4] RFC 1963 PPP SDTP August 1996
[4ページ]RFC1963ppp SDTP1996年8月の情報のシュナイダーと母
Header-Last
ヘッダー最終
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PPP Protocol ID | (Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Port) | Transported Data / (Odd-Pad) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Header - (CS) : H |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | pppプロトコルID| (長さ) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (ポート) | 輸送されたデータ/(変なパッド)… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ヘッダー--(Cs): H| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Header-First
ヘッダー-1番目
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PPP Protocol ID | (Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Port) | Header - H : (CS) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transported Data / (Odd-Pad) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | pppプロトコルID| (長さ) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (ポート) | ヘッダー--、H: (Cs) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 輸送されたデータ/(変なパッド)… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PPP Protocol ID
pppプロトコルID
The PPP Protocol ID field is described in the Point-to-Point
Protocol Encapsulation [1].
PPPプロトコルID分野はPointからポイントへのプロトコルEncapsulation[1]で説明されます。
When the SDTP Protocol is successfully negotiated by the SDTP
Control Protocol (SDCP), the value is 0049 hex. This value may be
compressed to one octet when Protocol-Field-Compression is
negotiated, or if one of the PPP compression protocols [4-10] is
used.
SDTP Controlプロトコル(SDCP)によってSDTPプロトコルが首尾よく交渉されるとき、値は0049年の十六進法です。 プロトコル分野圧縮が交渉されるとき、この値は1つの八重奏に圧縮されるかもしれなくて、PPP圧縮プロトコル[4-10]の1つが使用されているかどうかをそうされます。
Length
長さ
The optional Length field is present in every SDTP packet upon
successful negotiation of the Length-Field-Present Configuration
Option.
任意のLength分野はLengthがプレゼントをさばいているConfiguration Optionのうまくいっている交渉でのあらゆるSDTPパケットに存在しています。
The value of the Length field is the combined lengths of the
Length, Port (if present), Header, Transmitted Data, and Odd-Pad
(if present) fields in octets.
Length分野の値はLengthの結合した長さです、Port(存在しているなら)、八重奏におけるHeader、Transmitted Data、およびOdd-パッド(存在しているなら)分野。
The length of the Length field defaults to one octet. Valid
lengths are from 2 to 255 octets, since each packet must include
Length分野の長さは1つの八重奏をデフォルトとします。 パケットが含まなければならないそれぞれ以来の2〜255の八重奏まで有効な長さがあります。
Schneider & Venters Informational [Page 5] RFC 1963 PPP SDTP August 1996
[5ページ]RFC1963ppp SDTP1996年8月の情報のシュナイダーと母
at least a one octet Header field.
少なくとも1つの八重奏のHeader分野。
If desired, the length field can be negotiated to be two octets in
length. In that case, valid lengths are from 2 to 65535 octets,
and the field is transmitted most significant octet first.
望まれているなら、長さにおける2つの八重奏になるように長さの分野を交渉できます。 その場合、有効な長さは2〜65535の八重奏です、そして、最初に、分野は伝えられた最も重要な八重奏です。
In either case, a length of 0 means that the combined length is
the same as the length of the remainder of the PPP Information
Field.
どちらの場合ではも、0の長さは、結合した長さがPPP情報Fieldの残りの長さと同じであることを意味します。
Port
ポート
The optional Port field is present in every SDTP packet upon
successful negotiation of the Multi-Port Option.
任意のPort分野はMulti-ポートOptionのうまくいっている交渉でのあらゆるSDTPパケットに存在しています。
The length of the Port field is one octet. Valid Port numbers are
0 to 254. Port number 255 is reserved for control purposes (see
section on flow control).
Port分野の長さは1つの八重奏です。 有効なPort番号は、0〜254です。 ポートナンバー255は管理目的のために予約されます(フロー制御のセクションを見てください)。
Header
ヘッダー
The Header field is the terminal adaption header from ITU-T
Recommendation V.120. As specified in that document, it contains
up to two octets: The terminal adaption header octet (H), and the
optional header extension for control state information (CS).
SDTP only supports the protocol sensitive operation of V.120; bit
transparent operation is not supported. The descriptions of the
header bits provided below are derived from the descriptions
provided in Recommendation V.120. In addition to the bit
definitions of V.120, SDTP optionally permits the use of reserved
bits to be used for flow control and to provide support for non-
octet aligned frames.
Header分野はITU-T Recommendation V.120からの端末の適応ヘッダーです。 そのドキュメントで指定されるように、最大2つの八重奏を含んでいます: 端末の適応ヘッダー八重奏(H)、およびコントロール州の情報(CS)のための任意のヘッダー拡大。 SDTPは、プロトコルがV.120の敏感な操作であるとサポートするだけです。 噛み付いているわかりやすい操作はサポートされません。 Recommendation V.120に提供された記述から以下に提供されたヘッダービットの記述を得ます。 V.120の噛み付いている定義に加えて、SDTPは、予約されたビットの使用が非八重奏の並べられたフレームのサポートをフロー制御に使用されて、提供するのを任意に可能にします。
The length of the Header field is either one or two octets, and is
determined by the value of the E bit in the first octet. By
default, the E-bit must be set in the H octet and the CS octet is
not present. A Configuration Option may be negotiated to allow
the use of the CS octet, or even to require its presence in every
packet.
Header分野の長さは、どちらかか2つの八重奏であり、最初の八重奏における、Eビットの価値によって測定されます。 デフォルトで、H八重奏でE-ビットを設定しなければなりません、そして、CS八重奏は存在していません。 Configuration Optionは、CS八重奏の使用を許すか、またはあらゆるパケットで存在を必要とするのさえ交渉されるかもしれません。
Schneider & Venters Informational [Page 6] RFC 1963 PPP SDTP August 1996
[6ページ]RFC1963ppp SDTP1996年8月の情報のシュナイダーと母
H (V.120 Terminal Adaption Header)
H(V.120の端末の適応ヘッダー)
The format of the first octet of the Header field is shown
below:
Header分野の最初の八重奏の書式は以下に示されます:
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| E | BR | Res | FC | C2 | C1 | B | F |
+-----+-----+-----+-----+-----+-----+-----+-----+
0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | E| Br| Res| FC| C2| C1| B| F| +-----+-----+-----+-----+-----+-----+-----+-----+
E - Extension Bit
E--拡大に噛み付きました。
The E bit is the extension bit. If set to 0, it indicates
that the Control-2 field is present.
Eビットは拡大ビットです。 0に設定されるなら、それは、Control-2分野が存在しているのを示します。
BR - Break / HDLC Idle Bit
Br--中断/HDLCアイドル・ビット
In asynchronous mode, the BR bit indicates the invocation of
the BREAK function by the DTE. A value of 1 indicates
BREAK.
非同期モードで、BRビットはDTEでBREAK機能の実施を示します。 1の値はBREAKを示します。
In synchronous HDLC mode, the BR bit is used to indicate
that DTE port is receiving HDLC idle condition. A value of
1 indicates this idle condition.
同期HDLCモードで、BRビットはそのDTEが移植するのを示すのにおいて使用されているのが、HDLCの活動していない状態を受け取ることであるということです。 1の値はこの活動していない状態を示します。
Res - Reserved
Res--予約されます。
This bit is reserved and MUST be set to 0. (This is a
reserved bit in V.120.)
このビットを予約されていて、0に設定しなければなりません。 (これはV.120の予約されたビットです。)
FC - Flow Control
FC--フロー制御
This bit can be used for flow control of SDTP traffic on the
network, for applications which require it. When SDTP is
used in conjunction with data compression, flow control may
be needed. Reasons for this could be that the DTE port uses
an X.21 interface (and therefore does not have independent
control of DTE transmit and receive clocks), or simply that
the underlying link layer (such as PPP in HDLC-like Framing)
does not include a mechanism for network flow control, so
some flow control mechanism is needed.
ネットワークのSDTPトラフィックのフロー制御、それを必要とするアプリケーションにこのビットを使用できます。 SDTPがデータ圧縮に関連して使用されるとき、フロー制御が必要であるかもしれません。 この理由は単に、基本的なリンクレイヤ(HDLCのようなFramingのPPPなどの)がネットワークフロー制御のためのメカニズムを含まないで、DTEポートがX.21インタフェース(そして、したがって、DTEの独立制御に時計を送受信させない)を使用するので何らかのフロー制御メカニズムが必要であるということであるかもしれません。
This bit set to a value of 0 indicates that the receiver is
ready to receive data (Flow-On). A value of 1 indicates that
the receiver does not wish to receive data and the
transmitting peer should stop sending it (Flow-Off). Flow
0の値に設定されたこのビットは、受信機をデータを受け取る準備ができているのを(流れオンな)示します。 1の値は、受信機がデータを受け取りたがっていないのを示します、そして、伝わっている同輩はそれ(下に流れ)を送るのを止めるべきです。 流れ
Schneider & Venters Informational [Page 7] RFC 1963 PPP SDTP August 1996
[7ページ]RFC1963ppp SDTP1996年8月の情報のシュナイダーと母
control operates on a per port basis. Flow control messages
on Port 255 affect all ports.
コントロールはポート基礎あたりのaを作動させます。 Port255に関するフロー制御メッセージはすべてのポートに影響します。
To ensure that a missed Flow-On message cannot cause a
hangup condition, a Flow-Off is defined to expire after a
time of T1 seconds. If a unit desires to keep its peer in
the Flow-Off state for more than T1 seconds, it MUST
transmit another Flow-Off message after every period of T1
seconds. A unit that receives a Flow-Off message may resume
transmitting T1 seconds after the last Flow-Off was
received. The value of T1 is controlled by the Flow-
Expiration-Time Configuration Option. The default value is
10 seconds. There is not a separate value for T1 for each
port; all ports use the same T1 value.
逃されたFlowオンなメッセージがハングアップ状態を引き起こさない場合があるのを保証するなら、下にFlowは、しばらくしてT1秒の期限が切れるために定義されます。 ユニットが、下にFlow状態にT1秒以上で同輩を閉じ込めることを望んでいるなら、それはいつも期間のT1秒以降に別の下にFlowメッセージを送らなければなりません。 下にFlowメッセージを受け取るユニットは、下に最後のFlowを受け取ったT1秒後に伝わるのを再開するかもしれません。 T1の値はFlow満了時間Configuration Optionによって制御されます。 デフォルト値は10秒です。 各ポートへのT1のための別々の値がありません。 すべてのポートが同じT1値を使用します。
(This bit is a reserved bit in V.120, which requires the bit
to be set to a value of zero. The above definition of flow
control provides compatibility with this definition when
flow control is not used.)
(このビットはV.120の予約されたビットです。(V.120は、ビットがゼロの値に設定されるのを必要とします)。 フロー制御が使用されていないとき、フロー制御の上の定義はこの定義を互換性に提供します。)
C1, C2 - Error Control Bits
C1、C2--誤り制御ビット
The C1 and C2 bits are used for DTE port Error detection and
transmission. Their meaning is defined in the following
table:
C1とC2ビットはDTEポートError検出とトランスミッションに使用されます。 それらの意味は以下のテーブルで定義されます:
+----+----+--------------+--------------+
| | Meaning |
+----+----+--------------+--------------+
| C1 | C2 | Synchronous | Asynchronous |
+----+----+--------------+--------------+
| 0 | 0 | No Error | No Error |
| | | Detected | Detected |
+----+----+--------------+--------------+
| 0 | 1 | FCS Error | Stop-bit |
| | | (DTE) | Error |
+----+----+--------------+--------------+
| 1 | 0 | Abort | Parity Error |
| | | | on the Last |
| | | | Character in |
| | | | Frame |
+----+----+--------------+--------------+
| 1 | 1 | DTE Overrun* | Stop-bit and |
| | | | Parity Error |
+----+----+--------------+--------------+
+----+----+--------------+--------------+ | | 意味| +----+----+--------------+--------------+ | C1| C2| 同期| 非同期| +----+----+--------------+--------------+ | 0 | 0 | 誤りがありません。| 誤りがありません。| | | | 検出されます。| 検出されます。| +----+----+--------------+--------------+ | 0 | 1 | FCS誤り| ストップビット| | | | (DTE) | 誤り| +----+----+--------------+--------------+ | 1 | 0 | アボート| パリティエラー| | | | | 最終に関して| | | | | 中のキャラクター| | | | | フレーム| +----+----+--------------+--------------+ | 1 | 1 | DTE超過*| そしてストップビット。| | | | | パリティエラー| +----+----+--------------+--------------+
Schneider & Venters Informational [Page 8] RFC 1963 PPP SDTP August 1996
[8ページ]RFC1963ppp SDTP1996年8月の情報のシュナイダーと母
Appropriate responses to these bits are provided in Sections
2.2.1 and 2.2.2 of the V.120 standard (where R reference
point is translated to mean DTE port.)
これらのビットへの適切な応答をセクション2.2.1に提供します、そして、2.2は.2のV.120規格を提供します。(R参照ポイントがDTEポートを意味するために翻訳されるところ。)
B, F - Segmentation Bits
B、F--分割ビット
The B and F bits are used for segmenting and reassembly of
the transported frames in synchronous HDLC mode. Setting
the B bit to 1 indicates that the packet contains the
beginning of a transported frame or a Begin Frame. Setting
the F bit indicates that the packet contains the final
portion of a transported frame, or a Final Frame. A packet
that contains neither the beginning of a frame nor the end
is said to contain a Middle Frame. For asynchronous mode
and bit transparent mode operation both bits MUST be set to
1. The following table summarizes the use of these bits:
BとFビットは同期HDLCモードによる輸送されたフレームの区分と再アセンブリに使用されます。 Bビットを1に設定するのは、パケットが輸送されたフレームかBegin Frameの始まりを含むのを示します。 Fビットを設定するのは、パケットが輸送されたフレームの最終的な部分、またはFinal Frameを含むのを示します。 フレームの始まりも終わりも含まないパケットはMiddle Frameを含むと言われています。 非同期モードと噛み付いている透過モード操作において、両方のビットを1に設定しなければなりません。 以下のテーブルはこれらのビットの使用をまとめます:
+---+---+--------------+----------------+
| | Application |
+---+---+--------------+----------------+
| B | F | Synchronous | Asynchronous |
+---+---+--------------+----------------+
| 1 | 0 | Begin Frame | Not Applicable |
+---+---+--------------+----------------+
| 0 | 0 | Middle Frame | Not Applicable |
+---+---+--------------+----------------+
| 1 | 0 | Final Frame | Not Applicable |
+---+---+--------------+----------------+
| 1 | 1 | Single Frame | Required |
+---+---+--------------+----------------+
+---+---+--------------+----------------+ | | アプリケーション| +---+---+--------------+----------------+ | B| F| 同期| 非同期| +---+---+--------------+----------------+ | 1 | 0 | フレームを始めてください。| 適切でない| +---+---+--------------+----------------+ | 0 | 0 | 中央フレーム| 適切でない| +---+---+--------------+----------------+ | 1 | 0 | 最終的なフレーム| 適切でない| +---+---+--------------+----------------+ | 1 | 1 | シングルフレーム| 必要です。| +---+---+--------------+----------------+
CS (V.120 optional Header Extension for Control State Information)
Cs(Control州情報のためのV.120の任意のHeader Extension)
The format of the second Header octet (CS) is shown below:
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| E | DR | SR | RR | Res |(Odd-Pad Length) |
+-----+-----+-----+-----+-----+-----+-----+-----+
2番目のHeader八重奏(CS)の書式は以下に示されます: 0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | E| 博士| SR| RR| Res|(変なパッドの長さ) | +-----+-----+-----+-----+-----+-----+-----+-----+
E - Extension Bit
E--拡大に噛み付きました。
The E bit is the extension bit, and allows further extension
of the Header field. It is set to 1, to indicate no further
extension of the Header field.
Eビットは、拡大ビットであり、Header分野のさらなる拡大を許します。 1にそれがこれ以上Header分野の拡大を示さないように設定されます。
Schneider & Venters Informational [Page 9] RFC 1963 PPP SDTP August 1996
[9ページ]RFC1963ppp SDTP1996年8月の情報のシュナイダーと母
DR - Data Ready
DR--、データ準備ができている。
This bit set to 1 indicates that the DTE port is activated.
1に設定されたこのビットは、DTEポートが活性であることを示します。
SR - Send Ready
SR--準備ができていた状態で、発信してください。
This bit set to 1 indicates that the DTE is ready to send
data.
1に設定されたこのビットは、DTEをデータを送る準備ができているのを示します。
RR - Receive Ready
RR--準備ができていた状態で、受信してください。
This bit set to 1 indicates that the DTE is ready to receive
data. It can be used for DTE flow control in half-duplex
transmissions.
1に設定されたこのビットは、DTEをデータを受け取る準備ができているのを示します。 半二重通信によるDTEフロー制御にそれを使用できます。
Res - Reserved
Res--予約されます。
This bit is reserved and set to 0. (This is a V.120 reserved
bit.)
このビットは、0に予約されて、設定されます。 (これはV.120予約されたビットです。)
Odd-Pad Length (Optional)
変なパッドの長さ(任意)です。
The Odd-Pad Length field is used when non-octet aligned HDLC
frames are allowed. It is a 3-bit field, that can take on
the values of 0 through 7. Its value is the length of the
Odd-Pad field in bits. This value is determined as the
number of bits necessary to have the combined length of the
Transported Data Field and the Odd-Pad Field be aligned with
an octet boundary.
非八重奏の並べられたHDLCフレームが許容されているとき、Odd-パッドLength分野は使用されています。 それが3ビットの分野である、それは0〜7の値を呈することができます。 値はビットのOdd-パッド分野の長さです。 この値はTransported Data Fieldの結合した長さとOdd-パッドFieldを八重奏境界に並べさせるのに必要なビットの数として決定しています。
If non-octet aligned frames are not allowed, this field is
not used and all bits are set to the value of 0. (These
bits are reserved in V.120.)
非八重奏の並べられたフレームが許容されていないなら、この分野は使用されていません、そして、すべてのビットが0の値に設定されます。 (これらのビットはV.120で予約されます。)
Transported Data
輸送されたデータ
The transported data field contains the transported serial data.
輸送されたデータ・フィールドは輸送されたシリアルデータを含んでいます。
When the serial data type has been negotiated to be HDLC-like
synchronous, this field will contain all or part of a transported
HDLC-like frame.
シリアルデータがいつタイプするかは、HDLCのようになるように交渉されました。同時です、この分野は輸送されたHDLCのようなフレームのすべてか一部を含むでしょう。
A sample transported HDLC frame is shown below. The figure does
not show bits inserted for transparency.
輸送されたHDLCが縁どるサンプルは以下で見せられます。 図は透明ために挿入されたビットを示しません。
Schneider & Venters Informational [Page 10] RFC 1963 PPP SDTP August 1996
[10ページ]RFC1963ppp SDTP1996年8月の情報のシュナイダーと母
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flag:01111110 | (Address, Control and Information Fields) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (FCS) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - - - - - - - -+
| Flag:01111110 |
+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 旗: 01111110| (アドレス、コントロール、および情報フィールド) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (FCS) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - - - - - - - -+ | 旗: 01111110| +-+-+-+-+-+-+-+-+
Only the data between the flags is transported. The flags are not
transported. The FCS is tranported unless the FCS-Mode
Configuration Option has been successfully negotiated otherwise.
旗の間のデータだけが輸送されます。 旗は輸送されません。 FCS-モードConfiguration Optionが別の方法で首尾よく交渉されていない場合、FCSはtranportedされます。
Odd-Pad
変なパッド
The optional Odd-Pad (Odd Frame Pad) field is used when the
transported data frame is non-octet aligned, and the Allow-Odd-
Frames Option has been successfully negotiated. It contains the
bits that are required to pad the Transported Data field out to an
octet boundary. The Odd-Pad field is in the high order bits of
the last octet of the Transported Data field. The values of these
bits are all zero.
輸送されたデータフレームが並べられた非八重奏であるときに、任意のOdd-パッド(変なFrame Pad)分野は使用されています、そして、Allow変なフレームのOptionは首尾よく交渉されました。 それはTransported Data分野を八重奏境界に広げなければならないビットを含んでいます。 Odd-パッド分野がTransported Data分野の最後の八重奏の高位のビットにあります。 これらのビットの値はすべてゼロです。
3. Serial Data Control Protocol
3. シリアルデータ制御プロトコル
The Serial Data Control Protocol (SDCP) is responsible for configuring, enabling and disabling the SDTP modules on both ends of the point-to-point link. SDCP uses the same packet exchange mechanism and state machine as the Link Control Protocol. SDCP packets may not be exchanged until PPP has reached the Network-Layer Protocol phase. SDCP packets received before this phase is reached SHOULD be silently discarded.
Serial Data Controlプロトコル(SDCP)はポイントツーポイント接続の両端でSDTPモジュールを構成して、可能にして、無効にするのに原因となります。 SDCPはLink Controlプロトコルとして同じパケット交換メカニズムと州のマシンを使用します。 PPPがNetwork-層のプロトコルフェーズに達するまで、SDCPパケットは交換されないかもしれません。 捨てられて、このフェーズが達しているSHOULDである前に受け取られたSDCPパケットは静かにそうです。
The Serial Data Control Protocol is exactly the same as the Link Control Protocol [1] with the following exceptions:
Serial Data Controlプロトコルはまさに以下の例外でLink Controlプロトコル[1]と同じです:
Frame Modifications
フレーム変更
The packet may utilize any modifications to the basic frame format
which have been negotiated during the Link Establishment phase.
パケットは基本枠形式へのLink特権階級段階の間に交渉されているどんな変更も利用するかもしれません。
Data Link Layer Protocol Field
データリンク層プロトコル分野
Exactly one SDCP packet is encapsulated in the PPP Information
field, where the PPP Protocol field indicates type hex 8049 (PPP-
SDCP).
ちょうど1つのSDCPパケットがPPP情報分野でカプセルに入れられます。そこで、PPPプロトコル分野は、タイプが8049(PPP- SDCP)人に魔法をかけるのを示します。
Schneider & Venters Informational [Page 11] RFC 1963 PPP SDTP August 1996
[11ページ]RFC1963ppp SDTP1996年8月の情報のシュナイダーと母
Code Field
コード分野
Only Codes 1 through 7 (Configure-Request, Configure-Ack,
Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack,
and Code-Reject) are used. other Codes SHOULD be treated as
unrecognized and SHOULD result in Code-Rejects.
Codes1だけ、通じて、7 (要求を構成する、Configure-Ack、Configure-Nak、Configure-廃棄物、Terminate-要求、Terminate-Ack、およびCode-廃棄物) 中の認識されていない、そして、SHOULDの扱われた結果がCode-廃棄物であったなら. 中古の他はCodes SHOULDですか?
Timeouts
タイムアウト
SDCP packets may not be exchanged until PPP has reached the
Network-Layer Protocol phase. An implementation SHOULD be
prepared to wait for Authentication and Link Quality Determination
to finish before timing out waiting for a Configure-Ack or other
response. It is suggested that an implementation give up only
after user intervention or a configurable amount of time.
PPPがNetwork-層のプロトコルフェーズに達するまで、SDCPパケットは交換されないかもしれません。 実装SHOULD、AuthenticationとLink Quality Determinationが、以前タイミングが外でConfigure-Ackか他の応答を待ち終えるのを待つように用意してください。 実装がユーザ介入か構成可能な時間の後にだけあきらめることが提案されます。
Configuration Option Types
設定オプションタイプ
SDCP has a distinct set of Configuration Options which are defined
in this document.
SDCPには、本書では定義されるConfiguration Optionsの異なったセットがあります。
4. SDCP Configuration Option Format
4. SDCP設定オプション形式
SDCP Configuration Options allow modifications to the default SDCP characteristics to be negotiated. If a Configuration Option is not included in a Configure-Request packet, the default value for that Configuration Option is assumed.
SDCP Configuration Optionsは、デフォルトSDCPの特性への変更が交渉されるのを許容します。 Configuration OptionがConfigure-リクエスト・パケットに含まれていないなら、そのConfiguration Optionのためのデフォルト値は想定されます。
SDCP uses the same Configuration Option format defined in LCP [1], with a separate set of Options.
SDCPはOptionsの別々のセットでLCP[1]で定義された同じConfiguration Option書式を使用します。
The Option Types are:
Option Typesは以下の通りです。
1 Packet-Format
2 Header-Type
3 Length-Field-Present
4 Multi-Port
5 Transport-Mode
6 Maximum-Frame-Size
7 Allow-Odd-Frames
8 FCS-Type
9 Flow-Expiration-Time
1変なフレームを許容しているパケット・フォーマット2ヘッダータイプ3長さの分野プレゼント4マルチポート5交通機関6最大のフレーム・サイズ7 8FCS-タイプ9流れ満了時間
Note that Option Types 5-8 are specific to a single port and require port numbers in their format. Option Types 6-8 are specific to the HDLC-Synchronous Transport-Mode.
Option Types5-8が単一のポートに特定であり、それらの形式でポートナンバーを必要とすることに注意してください。 オプションTypes6-8はHDLC同期のTransport-モードに特定です。
Schneider & Venters Informational [Page 12] RFC 1963 PPP SDTP August 1996
[12ページ]RFC1963ppp SDTP1996年8月の情報のシュナイダーと母
4.1. Packet-Format
4.1. パケット・フォーマット
This option selects whether the Header field precedes or follows the data field. When the Header field follows the data field, the order of its octets are reversed.
このオプションは、Header分野がデータ・フィールドに先行するか、または続くかを選択します。 Header野原が続くとき、データ・フィールド、八重奏の注文を逆にします。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Format |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| 形式| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
1
1
Length
長さ
3
3
Format
形式
0 Header-Last (default)
1 Header-First
0 最初にヘッダー最後の(デフォルト)1ヘッダー
4.2. Header-Type
4.2. ヘッダータイプ
This option selects the type of the Header field. The Header-Type of H-and-CS means that the CS octet will be present if indicated by the E-bit in the H-octet. The Header-Type of H-and-CS-Always signifies that both the H and CS octets are present in every packet.
このオプションはHeader分野のタイプを選びます。 HとCSのHeader-タイプは、E-ビットによってH-八重奏で示されるとCS八重奏が存在することを意味します。 Header-タイプ、HとCS、いつも、HとCS八重奏の両方があらゆるパケットに存在しているのを意味します。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Header-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| ヘッダータイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
2
2
Length
長さ
3
3
Schneider & Venters Informational [Page 13] RFC 1963 PPP SDTP August 1996
[13ページ]RFC1963ppp SDTP1996年8月の情報のシュナイダーと母
Header-Type
ヘッダータイプ
0 H-Only (default)
1 H-and-CS
2 H-and-CS-Always
0時間(デフォルト)だけの1時間とCs、2時間とCs、いつも
4.3. Length-Field-Present
4.3. 長さの分野プレゼント
By default, a PPP Information Field contains only a single SDTP packet, and an SDTP Packet does not contain a length field. Successful negotiation of this option causes all SDTP packets to contain the length field, and allows SDTP packets to be contained in compound frames (see LCP Compound-Frames Configuration Option [11]).
デフォルトで、PPP情報Fieldは単一のSDTPパケットだけを含んでいます、そして、SDTP Packetは長さの分野を含んでいません。 このオプションのうまくいっている交渉は、すべてのSDTPパケットが長さの分野を含むことを引き起こして、SDTPパケットが合成フレームに含まれるのを許容します。(LCP Compound-フレームConfiguration Option[11])を見てください。
This option is required if the LCP Length-Field-Present Configuration option has been negotiated.
LCP Length分野プレゼントConfigurationオプションが交渉されたなら、このオプションが必要です。
The size of the Length field is negotiated via the Length-Size parameter.
Length分野のサイズはLength-サイズ・パラメータで交渉されます。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Length-Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| 長さ-サイズ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
3
3
Length
長さ
3
3
Length-Size
長さ-サイズ
0 No Length Field (default)
1 Length field of 1 octet
2 Length field of 2 octets
0 2つの八重奏の1つの八重奏の2Length分野のLength Field(デフォルト)の1Lengthの分野がありません。
4.4. Multi-Port
4.4. マルチポート
By default, packets do not contain a port number and all packets are sent to the default port, Port 0. The Successful negotiation of the Multi-Port configuration option means that every packet will contain a port number. The maximum port number, and hence the number of ports, is negotiated by using the Max-Port-Num field. A value of 0 specifies that a single port is to be used and no port field will be
デフォルトで、パケットはポートナンバーを含んでいません、そして、デフォルトポート、Port0にすべてのパケットを送ります。 Multi-ポート設定オプションのSuccessful交渉は、あらゆるパケットがポートナンバーを含むことを意味します。 最大のポートナンバー、およびしたがって、ポートの数は、マックス・Portヌム分野を使用することによって、交渉されます。 0の値は、単一のポートが使用されていることになっていると指定します、そして、どんなポート分野も指定しないでしょう。
Schneider & Venters Informational [Page 14] RFC 1963 PPP SDTP August 1996
[14ページ]RFC1963ppp SDTP1996年8月の情報のシュナイダーと母
present in an SDTP packet. (This is the same as not negotiating or rejecting this option.) Port numbers begin with 0 and range to 254. Port number 255 is reserved for control purposes (see section on flow control).
SDTPパケットでは、存在しています。 (これは、交渉しないのと同じであるかこのオプションを拒絶します。) ポートナンバーは、0で始まって、254に変化します。 ポートナンバー255は管理目的のために予約されます(フロー制御のセクションを見てください)。
Protocol Specific negotiations which are on a per port basis, require the port number to be specified as part of the configuration negotiation.
ポート基礎あたりのaにあるSpecific交渉について議定書の中で述べてください、そして、ポートナンバーが構成交渉の一部として指定されるのを必要であってください。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Max-Port-Num |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| マックス・Portヌム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
4
4
Length
長さ
3
3
Max-Port-Num
マックス・Portヌム
The maximum port number that can be used. The number of ports
present is Max-Port-Num + 1. The value can range from 0 to 254.
使用できる最大のポートナンバー。 ポートの数プレゼントはマックス・Portヌム+1です。 値は0〜254まで及ぶことができます。
4.5. Transport-Mode
4.5. 交通機関
This parameter selects the mode of transport for the specified port.
このパラメタは指定されたポートのための輸送の方法を選択します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Port | Mode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| ポート| モード| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
5
5
Length
長さ
4
4
Schneider & Venters Informational [Page 15] RFC 1963 PPP SDTP August 1996
[15ページ]RFC1963ppp SDTP1996年8月の情報のシュナイダーと母
Port
ポート
The port for which this option applies.
このオプションが適用されるポート。
Mode
モード
The transport mode to be used for this port.
このポートに使用されるべき交通機関。
0 HDLC Synchronous (default)
1 Asynchronous
0HDLC同期の(デフォルト)1非同期です。
4.6. Maximum-Frame-Size
4.6. 最大のフレーム・サイズ
This parameter specifies the maximum number of octets allowed in a transported data frame.
このパラメタは輸送されたデータフレームに許容された八重奏の最大数を指定します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum-Frame-Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| ポート| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 最大のフレーム・サイズ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
6
6
Length
長さ
7
7
Port
ポート
The port for which this option applies.
このオプションが適用されるポート。
Maximum-Frame-Size
最大のフレーム・サイズ
The maximum allowed length of a transported data frame in octets.
Default is 10,000. Negotiable range is 1 to 2**31 - 1. The value
0 is reserved to mean no limit. This field is transmitted most
significant octet first.
最大は八重奏における、輸送されたデータフレームの長さを許容しました。 デフォルトは1万です。 交渉可能な範囲は1〜2**31--1です。 値0は、限界を全く意味しないように予約されます。 最初に、この分野は伝えられた最も重要な八重奏です。
4.7. Allow-Odd-Frames
4.7. 変なフレームを許容してください。
By default, only octet-aligned data frames are allowed for transport. Successful negotiation of this option allows the transport of non- octet aligned frames. The size of the padding required to align the
デフォルトで、八重奏で並べられたデータフレームだけが輸送のために許容されています。 このオプションのうまくいっている交渉は非八重奏の並べられたフレームの輸送を許容します。 詰め物のサイズが並ぶのが必要です。
Schneider & Venters Informational [Page 16] RFC 1963 PPP SDTP August 1996
[16ページ]RFC1963ppp SDTP1996年8月の情報のシュナイダーと母
frames is carried in the CS Header octet.
フレームはCS Header八重奏で運ばれます。
Use of Header-Type H-Only is not permitted in conjunction with this option.
Hだけがこのオプションに関連して受入れられないHeader-タイプの使用。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| ポート| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
7
7
Length
長さ
3
3
Port
ポート
The port for which this option applies.
このオプションが適用されるポート。
4.8. FCS-Type
4.8. FCS-タイプ
By default, the transported data frame FCS is transported. This option allows the FCS to be removed by the transmitter and regenerated by the receiver.
デフォルトで、輸送されたデータフレームFCSは輸送されます。 このオプションは、FCSが送信機によって取り外されて、受信機によって作り直されるのを許容します。
It is important that implementations not use regeneration unless they are using PPP Reliable Transmission [12] or operating over some other layer that will provide reliable notification of a dropped packet. Implementations are not permitted to send a incomplete or bad frame to the user with a good (regenerated) FCS.
PPP Reliable Transmission[12]を使用するか、または下げられたパケットの信頼できる通知を提供するある他の層の上で作動していない場合実装が再生を使用しないのは、重要です。 実装が良い(作り直される)FCSをもっているユーザに不完全であるか悪いフレームを送ることが許可されていません。
This option also selects the type of user FCS that will be regenerated.
また、このオプションは作り直されるユーザFCSのタイプを選びます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Port | FCS-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| ポート| FCS-タイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
8
8
Schneider & Venters Informational [Page 17] RFC 1963 PPP SDTP August 1996
[17ページ]RFC1963ppp SDTP1996年8月の情報のシュナイダーと母
Length
長さ
4
4
Port
ポート
The port for which this option applies.
このオプションが適用されるポート。
FCS-Type
FCS-タイプ
0 Transparent-Transport (Default)
1 16-bit ITU-T CRC
2 32-bit ITU-T CRC
0 わかりやすい輸送の(デフォルト)1 16ビットのITU-T CRC2の32ビットのITU-T CRC
4.9. Flow-Expiration-Time
4.9. 流れ満了時間
As described in section 2.2, Flow-Off messages expire after T1 seconds. By default, T1 is 10 seconds. This configuration option allows the value of T1 to be changed.
セクション2.2で説明されるように、下にFlowメッセージはT1秒以降、期限が切れます。 デフォルトで、T1は10秒です。 この設定オプションで、T1の値は変化します。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow-Expiration-Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 流れ満了時間| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
9
9
Length
長さ
5
5
Flow-Expiration-Time
流れ満了時間
The Flow-Expiration-Time field contains a 16 bit unsigned integer
which is used to specify the value to be assigned to T1 as
follows: T1 = Flow-Expiration-Time / 10 seconds. Therefore this
value is in units of 1/10 of a second, with allowable values from
1 to 2^16-1 (0.1 to 6553.5 seconds). It is transmitted most
significant octet first. The default value is 100 (10 seconds),
which all must support.
Flow満了時間分野は以下のT1に割り当てられる値を指定するのに使用される16の噛み付いている符号のない整数を含んでいます: T1=流れ満了時間/10秒。 したがって、この値は1秒の1/10のユニットにあります、1〜2^16-1(0.1〜6553.5秒)からの許容量で。 最初に、それは伝えられた最も重要な八重奏です。 デフォルト値は100(10秒)です。(すべてがその100をサポートしなければなりません)。
Schneider & Venters Informational [Page 18] RFC 1963 PPP SDTP August 1996
[18ページ]RFC1963ppp SDTP1996年8月の情報のシュナイダーと母
Security Considerations
セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
References
参照
[1] Simpson, W., ed., "The Point-to-Point Protocol (PPP)", STD
51, RFC 1661, July 1994.
[1] シンプソン、W.、教育、「二地点間プロトコル(ppp)」、STD51、RFC1661、7月1994日
[2] CCITT Recommendation V.120 (09/92), "Support by an ISDN of
Data Terminal Equipment with V-Series Type Interfaces with
Provision for Statistical Multiplexing", 1993.
[2] CCITT推薦V.120(09/92)、「支給とのV-シリーズタイプインタフェースがあるデータ端末装置のISDNによる統計的多重化のサポート」、1993。
[3] Rand, D., "The PPP Compression Control Protocol (CCP)", RFC
1962, June 1996.
D.、「ppp圧縮制御プロトコル(CCP)」、RFC1962 1996年6月の[3]底ならし革。
[4] Friend, R., and W. Simpson, "PPP Stac LZS Compression
Protocol", RFC 1974, August 1996.
[4] 友人、R.とW.シンプソン、「ppp Stac LZS圧縮プロトコル」、RFC1974、1996年8月。
[5] Rand, D., "PPP Predictor Compression Protocol", RFC 1978,
August 1996.
[5] 底ならし革、D.、「ppp予言者圧縮プロトコル」、RFC1978、1996年8月。
[6] Petty, J., "PPP Hewlett-Packard Packet-by-Packet Compression
(HP PPC) Protocol", Work in Progress.
[6] 小さくて、J.、「パケットごとのpppヒューレット・パッカードの圧縮(hp PPC)プロトコル」が進行中で働いています。
[7] Carr, D., "PPP Gandalf FZA Compression Protocol", Work in
Progress.
[7] カー、D.、「pppガンダルフFZA圧縮プロトコル」が進行中で働いています。
[8] Schryver, V., "PPP BSD Compression Protocol", RFC 1977,
August 1996.
[8]Schryver、V.、「ppp BSD圧縮プロトコル」、RFC1977、1996年8月。
[9] Schremp, et. al., "PPP Magnalink Variable Resource
Compression", RFC 1975, August 1996.
et[9]Schremp、アル、「pppのMagnalinkの可変リソース圧縮」、RFC1975、8月1996日
[10] Schneider, K., "PPP Stacker LZS Compression Protocol using a
DCP Header (LZS-DCP)", RFC 1967, August 1996.
[10]シュナイダー、K.、「DCPヘッダー(LZS-DCP)を使用するpppスタッカLZS圧縮プロトコル」、RFC1967、1996年8月。
[11] Simpson, W.A., "PPP LCP Extensions", RFC 1570, January 1994.
[11] シンプソン、W.A.、「ppp LCP拡張子」、RFC1570、1994年1月。
[12] Rand, D., "PPP Reliable Transmission", RFC 1663, July 1994.
[12] 底ならし革、D.、「pppの信頼できる送信」、RFC1663、1994年7月。
Schneider & Venters Informational [Page 19] RFC 1963 PPP SDTP August 1996
[19ページ]RFC1963ppp SDTP1996年8月の情報のシュナイダーと母
Chair's Address
議長のアドレス
The working group can be contacted via the current chair:
現在のいすを通してワーキンググループに連絡できます:
Karl Fox Ascend Communications 3518 Riverside Drive, Suite 101 Columbus, Ohio 43221
カールフォックスはオハイオ コミュニケーション3518リバーサイド・ドライブ、Suite101コロンブス、43221を昇ります。
EMail: karl@ascend.com
メール: karl@ascend.com
Authors' Addresses
作者のアドレス
Questions about this memo should be directed to:
このメモに関する質問による以下のことよう指示されるべきです。
Kevin Schneider Adtran, Inc. 901 Explorer Blvd. Huntsville, AL 35806-2807
ケビンシュナイダーAdtran Inc.901エクスプローラーBlvd. ハンツビル、AL35806-2807
Phone: (205) 971-8000 EMail: kevin@adtran.com
以下に電話をしてください。 (205) 971-8000 メールしてください: kevin@adtran.com
Stuart Venters Adtran, Inc. 901 Explorer Blvd. Huntsville, AL 35806-2807
スチュアート母、Adtran Inc.901エクスプローラーBlvd. ハンツビル、AL35806-2807
Phone: (205) 971-8000 EMail: sventers@adtran.com
以下に電話をしてください。 (205) 971-8000 メールしてください: sventers@adtran.com
Schneider & Venters Informational [Page 20]
シュナイダーと母、情報[20ページ]
一覧
スポンサーリンク
