RFC2687 日本語訳
2687 PPP in a Real-time Oriented HDLC-like Framing. C. Bormann. September 1999. (Format: TXT=28699 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group C. Bormann Request for Comments: 2687 Universitaet Bremen TZI Category: Standards Track September 1999
コメントを求めるワーキンググループC.ボルマンの要求をネットワークでつないでください: 2687年のUniversitaetブレーメンTZIカテゴリ: 標準化過程1999年9月
PPP in a Real-time Oriented HDLC-like Framing
リアルタイムの指向のHDLCのような縁どりにおけるppp
Status of this Memo
この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)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
Abstract
要約
A companion document describes an architecture for providing integrated services over low-bitrate links, such as modem lines, ISDN B-channels, and sub-T1 links [1]. The main components of the architecture are: a real-time encapsulation format for asynchronous and synchronous low-bitrate links, a header compression architecture optimized for real-time flows, elements of negotiation protocols used between routers (or between hosts and routers), and announcement protocols used by applications to allow this negotiation to take place.
仲間ドキュメントは低いbitrateリンクの上に統合サービスを供給するために構造について説明します、モデム回線や、ISDN Bチャネルや、サブT1リンク[1]などのように。 構造の主な成分は以下の通りです。 非同期で同期の低いbitrateリンクのためのリアルタイムのカプセル化形式、ヘッダー圧縮構造はリアルタイムの流れ、ルータ(またはホストとルータの間で)の間で使用される、交渉プロトコルの原理、およびこの交渉が行われるのを許容するのにアプリケーションで使用される発表プロトコルのために最適化されました。
This document proposes the suspend/resume-oriented solution for the real-time encapsulation format part of the architecture. The general approach is to start from the PPP Multilink fragmentation protocol [2] and its multi-class extension [5] and add suspend/resume in a way that is as compatible to existing hard- and firmware as possible.
このドキュメントが提案する、構造のリアルタイムのカプセル化形式部分の/履歴書指向の解決策を中断させてください。 一般的方法は、PPP Multilink断片化プロトコル[2]とそのマルチのクラス拡大[5]から始めて、できるだけ一生懸命存在して、ファームウェアに互換性がある方法で中断するか、または再開するように言い足すことです。
1. Introduction
1. 序論
As an extension to the "best-effort" services the Internet is well-
known for, additional types of services ("integrated services") that
support the transport of real-time multimedia information are being
developed for, and deployed in the Internet.
インターネットがよく知られている「ベストエフォート型」のサービスへの拡大として、リアルタイムのマルチメディア情報の輸送を支持する追加タイプのサービス(「統合サービス」)は、インターネットで開発されて配備されています。
The present document defines the suspend/resume-oriented solution for the real-time encapsulation format part of the architecture. As described in more detail in the architecture document, a real-time encapsulation format is required as, e.g., a 1500 byte packet on a
現在のドキュメントが定義する、構造のリアルタイムのカプセル化形式部分の/履歴書指向の解決策を中断させてください。 構造ドキュメントのその他の詳細、形式が必要であるリアルタイムのカプセル化、例えば、aの1500年のバイトの中で同じくらい説明されたパケット
Bormann Standards Track [Page 1] RFC 2687 PPP in Real-time Oriented HDLC-like Framing September 1999
ボルマンStandardsはリアルタイムの指向のHDLCのような縁どり1999年9月にRFC2687pppを追跡します[1ページ]。
28.8 kbit/s modem link makes this link unavailable for the transmission of real-time information for about 400 ms. This adds a worst-case delay that causes real-time applications to operate with round-trip delays on the order of at least a second -- unacceptable for real-time conversation.
28.8kbit/sモデムリンクで、このリンクは原稿Thisが、最悪の場合が遅らせると言い足すおよそ400のためのリアルタイムのアプリケーションが少なくとも1秒の注文での往復の遅れで作動するリアルタイムの情報の伝達を入手できなくなります--リアルタイムの会話において、容認できません。
A true suspend/resume-oriented approach can only be implemented on a type-1 sender [1], but provides the best possible delay performance to this type of senders. The format defined in this document may also be of interest to certain type-2-senders that want to exploit the better bit-efficiency of this format as compared to [5]. The format was designed so that it can be implemented by both type-1 and type-2 receivers.
/履歴書指向のアプローチを中断させてください。本当である、タイプ-1送付者[1]の上で実行できるだけですが、可能な限り良い遅れ性能をこのタイプの送付者に提供します。 また、[5]と比べて、この形式の、より良いビット-効率を利用したがっている確信しているタイプ2送付者にとって、本書では定義された書式も興味深いかもしれません。 形式は、タイプ-1とタイプ-2台の受信機の両方でそれを実行できるように設計されました。
1.1. Specification Language
1.1. 仕様言語
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [8].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[8]で説明されるように本書では解釈されることであるべきですか?
2. Requirements
2. 要件
The requirements for this document are similar to those listed in [5].
このドキュメントのための要件は[5]に記載されたものと同様です。
A suspend/resume-oriented solution can provide better worst-case latency than the pre-fragmenting-oriented solution defined in [5]. Also, as this solution requires a new encapsulation scheme, there is an opportunity to provide a slightly more efficient format.
Aは履歴書指向の解決策が[5]で定義されたプレ断片化指向の解決策より良い最悪の場合潜在を提供できる/を中断させます。 また、この解決策が新しいカプセル化計画を必要とするとき、わずかに効率的な形式を提供する機会があります。
Predictability, robustness, and cooperation with PPP and existing hard- and firmware installations are as important with suspend/resume as with pre-fragmenting. A good suspend/resume solution achieves good performance even with type-2 receivers [1] and is able to work with PPP hardware such as async-to-sync converters.
予見性、丈夫さ、固いPPPと存在との協力、およびインストールが重要であるファームウェアは、プレ断片化のように中断するか、または再開します。 利益は、中断するか、または再開します。解決策は、タイプ-2台の受信機[1]があっても望ましい市場成果を達成して、asyncから同時性へのコンバータなどのPPPハードウェアで働くことができます。
Finally, a partial non-requirement: While the format defined in this draft is based on the PPP multilink protocol ([2], also abbreviated as MP), operation over multiple links is in many cases not required.
最終的に部分的な非要件: PPPマルチリンクプロトコル([2]に基づいていて、またMPを簡略化されたこの草稿で定義された書式)、多くの場合、複数のリンクの上の操作は必要ではありません。
3. General Approach
3. 一般的方法
As in [5], the general approach is to start out from PPP multilink and add multiple classes to obtain multiple levels of suspension. However, in contrast to [5], more significant changes are required to be able to suspend the transmission of a packet at any point and inject a higher priority packet.
[5]のように、一般的方法は、PPPマルチリンクから始めて、複数のレベルのサスペンションを入手するために複数のクラスを加えることです。 しかしながら、[5]と対照して、より重要な変化は、任意な点でパケットのトランスミッションを中断させて、より高い優先権パケットを注入できなければなりません。
Bormann Standards Track [Page 2] RFC 2687 PPP in Real-time Oriented HDLC-like Framing September 1999
ボルマンStandardsはリアルタイムの指向のHDLCのような縁どり1999年9月にRFC2687pppを追跡します[2ページ]。
The applicability of the multilink header for suspend/resume type implementations is limited, as the "end" bit is in the multilink header, which is the wrong place for suspend/resume operation. To make a big packet suspendable, it must be sent with the "end" bit off, and (unless the packet was suspended a small number of bytes before its end) an empty fragment has to be sent afterwards to "close" the packet. The minimum overhead for sending a suspendable packet thus is twice the multilink header size (six bytes, including a compressed multilink protocol field) plus one PPP framing (three bytes). Each suspension costs another six bytes (not counting the overhead of the framing for the intervening packet).
マルチリンクヘッダーの適用性、制限されたタイプ実現を、中断するか、または再開してください、そして、ビットが間違った場所であるマルチリンクヘッダーにある「終わり」として/復帰動作を中断させてください。 大きいパケット中断可能を作るために、「終わり」ビットがオフな状態でそれを送らなければなりません、そして、その後、パケットを「閉じる」ために(パケットが終わり以前少ない数のバイトのときに中断しなかったなら)空の断片を送らなければなりません。 その結果、中断可能パケットを送るための最小のオーバーヘッドはマルチリンクヘッダーサイズ(圧縮されたマルチリンクプロトコル分野を含む6バイト)と1つのPPP縁どり(3バイト)の2倍です。 各サスペンションはもう6バイト(介入しているパケットのための縁どりのオーバーヘッドを数えない)かかります。
Also, the existing multi-link header is relatively large; as the frequency of small high-priority packets increases, the overhead becomes significant.
また、既存のマルチリンクヘッダーも比較的大きいです。 小さい高優先度パケットの頻度が増加するのに従って、オーバーヘッドは重要になります。
The general approach of this document is to start from PPP Multilink with classes and provide a number of extensions to add functionality and reduce the overhead of using PPP Multilink for real-time transmission.
このドキュメントの一般的方法は、機能性を加えて、リアルタイムのトランスミッションにPPP Multilinkを使用するオーバーヘッドを下げるためにクラスと共にPPP Multilinkから始めて、多くの拡大を提供することです。
This document introduces two new features:
このドキュメントは2つの新機能を導入します:
1) A compact fragment format and header, and
1) そしてコンパクトな断片形式とヘッダー。
2) a real-time frame format.
2) リアルタイムのフレーム形式。
4. The Compact Fragment Format
4. コンパクトな断片形式
This section describes an optional multilink fragment format that is more optimized towards single-link operation and frequent suspension (type 1 senders)/a small fragment size (type 2 senders), with optional support for multiple links.
このセクションは小さい断片サイズにより単一のリンク操作に向かって最適化されて頻繁なサスペンション(1人の送付者をタイプする)/である任意のマルチリンク断片形式について説明します(2人の送付者をタイプしてください)、複数のリンクの任意のサポートで。
When operating over a single link, the Multilink sequence number is used only for loss detection. Even a 12-bit sequence number clearly is larger than required for this application on most kinds of links. We therefore define the following compact multilink header format option with a three-bit sequence number.
単一のリンクの上に作動するとき、Multilink一連番号は損失検出にだけ使用されます。 12ビットの一連番号さえこのアプリケーションのためにほとんどの種類のリンクの上に必要とされるより明確に大きいです。 したがって、私たちは3ビットの一連番号で以下のコンパクトなマルチリンクヘッダー形式オプションを定義します。
As, with a compact header, there is little need for sending packets outside the multilink, we can provide an additional compression mechanism for this format: the MP protocol identifier is not sent with the compact fragment header. This obviously requires prior negotiation (similar to the way address and control field compression are negotiated), as well as a method for avoiding the bit combination
マルチリンクの外で送付パケットの必要がコンパクトなヘッダーと共にほとんどないとき、私たちは追加圧縮機構をこの形式に提供できます: MPプロトコル識別子はコンパクトな断片ヘッダーと共に送られません。 これは明らかに交渉(アドレスと制御フィールド圧縮が交渉される方法と同様の)、およびビット・コンビネーションを避けるための方法を優先的に必要とします。
Bormann Standards Track [Page 3] RFC 2687 PPP in Real-time Oriented HDLC-like Framing September 1999
ボルマンStandardsはリアルタイムの指向のHDLCのような縁どり1999年9月にRFC2687pppを追跡します[3ページ]。
0xFF (the first octet in an LCP frame before any LCP options have been negotiated), as the start of a new LCP negotiation could otherwise not be reliably detected.
0xFF(どんなLCPオプションも交渉される前のLCPフレームにおける最初の八重奏)、そうでなければ、新しいLCPの始まりとして、交渉を確かに検出できませんでした。
Figure 1: Compact Fragment Format
図1: コンパクトな断片形式
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| R | sequence | class | 1 |
+---+---+---+---+---+---+---+---+
| data |
: :
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | R| 系列| クラス| 1 | +---+---+---+---+---+---+---+---+ | データ| : : +---+---+---+---+---+---+---+---+
Having the least significant bit always be 1 helps with HDLC chips that operate specially on least significant bits in HDLC addresses. (Initial bytes with the least significant bit set to zero are used for the extended compact fragment format, see next section.)
いつも最下位ビットが1であることを持っているのが特に、HDLCアドレスの最下位ビットを作動させるHDLCチップで助けます。 (ゼロに設定された最下位ビットがある初期のバイトは拡張コンパクトな断片形式に使用されます、と次のセクションは見ます。)
The R bit is the inverted equivalent of the B bit in the other multilink fragment formats, i.e. R = 1 means that this fragment resumes a packet previous fragments of which have been sent already.
Rビットが他のマルチリンク断片形式のBビットの逆さの同等物である、すなわち、R=1はこの断片がそれの前の断片が既に送られたパケットを再開することを意味します。
The following trick avoids the case of a header byte of 0xFF (which would mean R=1, sequence=7, and class=7): If the class field is set to 7, the R bit MUST never be set to one. I.e., class 7 frames by design cannot be suspended/resumed. (This is also the reason the sense of the B bit is inverted to an R bit in the compact fragment format -- class 7 would be useless otherwise, as a new packet could never be begun.)
以下のトリックは0xFF(R=1、系列=7、およびクラス=7を意味する)のヘッダーバイトに関するケースを避けます: 類体が7に設定されるなら、Rビットを1つに決して設定してはいけません。 すなわち、故意にクラス7フレームを吊すことができないか、再開できません。 (また、これはBビットの感覚がコンパクトな断片形式でRビットに逆にされる理由です--そうでなければ、クラス7は役に立たないでしょう、新しいパケットを決して始めることができなかったとき。)
As the sequence number is not particularly useful with the class field set to 7, it is used to distinguish eight more classes -- for some minor additional complexity, the applicability of prefix elision is significantly increased by providing more classes with possibly different elided prefixes.
一連番号が類体セットによって特に7の役に立たないので、それはもう8つのクラスを区別するのに使用されます--何らかの小さい方の追加複雑さにおいて、接頭語発音省略の適用性はことによると異なった削除された接頭語をより多くのクラスに提供することによって、かなり増加します。
For purposes of prefix elision, the actual class number of a fragment is computed as follows:
接頭語発音省略の目的のために、断片の実際のクラス番号は以下の通り計算されます:
- If the class field is 0 to 6, the class number is 0 to 6,
- 類体が0〜6であるなら、クラス番号は、0〜6です。
- if the class field is 7 and the sequence field is 0 to 7, the
class number is 7 to 14.
- 系列分野が0〜類体が7であり、7であるなら、クラス番号は、7〜14です。
Bormann Standards Track [Page 4] RFC 2687 PPP in Real-time Oriented HDLC-like Framing September 1999
ボルマンStandardsはリアルタイムの指向のHDLCのような縁どり1999年9月にRFC2687pppを追跡します[4ページ]。
As a result of this scheme, the classes 0 to 6 can be used for suspendable packets, and classes 7 to 14 (where the class field is 7 and the R bit must always be off) can be used for non-suspendable high-priority classes, e.g., eight highly compressed voice streams.
この計画の結果、中断可能パケットにクラス0〜6を使用できます、そして、非中断可能な高優先度のクラス、例えば、8つの非常に圧縮された声の流れに、クラス7〜14(類体がどこの7とRビットであるかはいつもオフであるに違いありません)を使用できます。
5. The Extended Compact Fragment Format
5. 拡張コンパクトな断片形式
For operation over multiple links, a three-bit sequence number will rarely be sufficient. Therefore, we define an optional extended compact fragment format. The option, when negotiated, allows both the basic compact fragment format and the extended compact fragment format to be used; each fragment indicates which format it is in.
複数のリンクの上の操作では、3ビットの一連番号はめったに十分ではありません。 したがって、私たちは任意の拡張コンパクトな断片書式を定義します。 交渉されると、オプションは、基本的なコンパクトな断片形式と拡張コンパクトな断片形式の両方が使用されるのを許容します。 各断片は、どの形式にそれがあるかを示します。
Figure 1: Extended Compact Fragment Format
図1: 拡張コンパクトな断片形式
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| R | seq LSB | class | 0 |
+---+---+---+---+---+---+---+---+
| sequence -- MSB | 1 |
+---+---+---+---+---+---+---+---+
| data |
: :
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | R| seq LSB| クラス| 0 | +---+---+---+---+---+---+---+---+ | 系列--MSB| 1 | +---+---+---+---+---+---+---+---+ | データ| : : +---+---+---+---+---+---+---+---+
In the extended compact fragment format, the sequence number is composed of three least significant bits from the first octet of the fragment header and seven most significant bits from the second octet. (Again, the least significant bit of the second octet is always set to one for compatibility with certain HDLC chips.)
拡張コンパクトな断片形式では、一連番号は断片ヘッダーと7つの最上位ビットの最初の八重奏から2番目の八重奏から3つの最下位ビットで構成されます。 (一方、2番目の八重奏の最下位ビットはいつもあるHDLCチップとの互換性のための1つに設定されます。)
For prefix elision purposes, fragments with a class field of 7 can use the basic format to indicate classes 7 to 14 and the extended format to indicate classes 7 to 1030. Different classes may use different formats concurrently without problems. (This allows some classes to be spread over a multi-link and other classes to be confined to a single link with greater efficiency.) For class fields 0 to 6, i.e. suspendable classes, one of the two compact fragment formats SHOULD be used consistently within each class.
接頭語発音省略目的のために、7の類体がある断片は7〜14にクラスを示すのに基本形式を使用できて、示す拡張フォーマットは7〜1030に属します。 異なったクラスは同時に問題なしで異なった形式を使用するかもしれません。. (これは、数人のクラスが、より大きい効率との単一のリンクに閉じ込められるためにマルチリンクと他のクラスの上に広げられるのを許容します。) すなわち、類体0〜6、中断可能のクラスのために、2のコンパクトな断片の1つはSHOULDをフォーマットします。各クラスの中で一貫して使用されてください。
If the use of the extended compact fragment format has been negotiated, receivers MAY keep 10-bit sequence numbers for all classes to facilitate senders switching formats in a class. When a sender starts sending basic format fragments in a class that was using extended format fragments, the 3-bit sequence number can be taken as a modulo-8 version of the 10-bit sequence number, and no discontinuity need result. In the inverse case, if a 10-bit sequence number has been kept throughout by the receiver (and no major slips
拡張コンパクトな断片形式の使用が交渉されたなら、すべてのクラスがクラスで形式を切り換える送付者を容易にするように、受信機は10ビットの一連番号を保つかもしれません。 送付者が拡張フォーマット断片を使用していたクラスで基本形式断片を送り始めるとき、10ビットの一連番号の法-8バージョンを結果として生じさせますが、どんな不連続も結果として生じる必要はないのに従って、3ビットの一連番号を取ることができます。 10ビットの一連番号があらゆる点で逆さのケース受信機によって保たれた、(少佐は全く滑りません。
Bormann Standards Track [Page 5] RFC 2687 PPP in Real-time Oriented HDLC-like Framing September 1999
ボルマンStandardsはリアルタイムの指向のHDLCのような縁どり1999年9月にRFC2687pppを追跡します[5ページ]。
of the sequence number have occurred), no discontinuity will result, although this cannot be guaranteed in the presence of errors. (Discontinuity, in this context, means that a receiver has to resynchronize sequence numbers by discarding fragments until a fragment with R=0 has been seen.)
一連番号が起こった、)、誤りがあるときこれを保証できませんが、不連続は全く結果として生じないでしょう。 (不連続は、受信機がR=0がある断片が見られるまで断片を捨てることによって一連番号を再連動させなければならないことをこのような関係においては意味します。)
6. Real-Time Frame Format
6. リアルタイムのフレーム形式
This section defines how fragments with compact fragment headers are mapped into real-time frames. This format has been designed to retain the overall HDLC based format of frames, so that existing synchronous HDLC chips and async to sync converters can be used on the link. Note that if the design could be optimized for async only operation, more design alternatives would be available [4]; with the advent of V.80 style modems, asynchronous communications is likely to decrease in importance, though.
このセクションはコンパクトな断片ヘッダーがある断片がどうリアルタイムのフレームに写像されるかを定義します。 この形式はフレームの総合的なHDLCベースの形式を保有するように設計されています、リンクの上に既存の同期HDLCチップとコンバータを同期させるasyncを使用できるように。 asyncに唯一の操作のためにデザインを最適化できるなら、より多くのデザイン選択肢が利用可能な[4]であることに注意してください。 もっとも、V.80スタイルモデムの到来で、非同期通信は重要性に縮小しそうです。
The compact fragment format provides a compact rendition of the PPP multilink header with classes and a reduced sequence number space. However, it does not encode the E-bit of the PPP multilink header, which indicates whether the fragment at hand is the last fragment of a packet.
コンパクトな断片形式はPPPマルチリンクヘッダーのコンパクトな表現をクラスと減少している一連番号スペースに提供します。 しかしながら、それはPPPマルチリンクヘッダーのE-ビットをコード化しません。(ヘッダーは手元の断片がパケットの最後の断片であるかどうかを示します)。
For a solution where packets can be suspended at any point in time, the E-bit needs to be encoded near the end of each fragment. The real-time frame format, to ensure maximum compatibility with type 2 receivers, encodes the E-bit in the following way: Any normal frame ending also ends the current fragment with E implicitly set to one. This ensures that packets that are ready for delivery to the upper layers immediately trigger a receive interrupt even at type-2 receivers.
パケットが時間内に任意な点で中断できる解決策のために、E-ビットは、それぞれの断片の端頃にコード化される必要があります。 リアルタイムのフレーム形式はタイプ2受信機との最大の互換性を確実にするために以下の方法でE-ビットをコード化します: また、どんな正常なフレーム結末もそれとなく1つに設定されたEと共に現在の断片を終わらせます。 これは、覚醒剤への配送がすぐによりこぎれいなaを層にするので準備ができるパケットがタイプ-2台の受信機でさえ中断を受けるのを確実にします。
Fragments of packets that are to be suspended are terminated within the HDLC frame by a special "fragment suspend escape" byte (FSE). The overall structure of the HDLC frame does not change; the detection and handling of FSE bytes is done at a layer above HDLC framing.
吊すことになっているパケットの断片はHDLCフレームの中に特別番組「断片はエスケープを中断する」バイト(FSE)によって終えられます。 HDLCフレームの全体的な構造は変化しません。 HDLC縁どりを超えてFSEバイトの検出と取り扱いを層にします。
The suspend/resume format with FSE detection is an alternative to address/control field compression (ACFC, LCP option 8). It does not apply to frames that start with 0xFF, the standard PPP-in-HDLC address field; these frames are handled as defined in [6] and [7]. (This provision ensures that attempts to renegotiate LCP do not cause ambiguities.)
FSEと共に形式を中断するか、または再開してください。検出は分野圧縮(ACFC、LCPオプション8)を記述するか、または制御する代替手段です。 それは0xFFから始まるフレーム、標準のHDLCのPPPアドレス・フィールドに適用されません。 これらのフレームは[6]と[7]で定義されるように扱われます。 (この支給は、LCPを再交渉する試みがあいまいさを引き起こさないのを確実にします。)
Bormann Standards Track [Page 6] RFC 2687 PPP in Real-time Oriented HDLC-like Framing September 1999
ボルマンStandardsはリアルタイムの指向のHDLCのような縁どり1999年9月にRFC2687pppを追跡します[6ページ]。
For frames that do not start with 0xFF, suspend/resume processing performs a scan of every HDLC frame received. The FCS of the HDLC frame is checked and stripped. Compact fragment format headers (both basic and extended) are handled without further FSE processing. (Note that, as the FSE byte was chosen such that it never occurs in compact fragment format headers, this does not require any specific code.)
0xFFから始まって、吊すか、または再開しないフレームに関しては、処理は受け取られたあらゆるHDLCフレームのスキャンを実行します。 HDLCフレームのFCSをチェックして、剥取ります。 コンパクトな断片形式ヘッダー(基本的なものと同様に拡張している)はさらなるFSE処理なしで扱われます。 (これがFSEバイトが選ばれたのでコンパクトな断片形式ヘッダーに決して起こらないように少しの特定のコードも必要としないことに注意してください。)
Within the remaining bytes of the HDLC frame ("data part"), an FSE
byte is used to indicate the end of the current fragment, with an E
bit implicitly cleared. All fragments up to the last FSE are
considered suspended (E = 0); the final fragment is terminated (E =
1), or, if it is empty, ignored (i.e., the data part of an HDLC frame
can end in an FSE to indicate that the last fragment has E = 0).
HDLCフレーム(「データ部分」)の残っているバイトの中では、FSEバイトは現在の断片の端を示すのに使用されます、Eビットがそれとなくきれいにされている状態で。 最後のFSEまでのすべての断片が吊していると(E=0)考えられます。 または、それが空であるなら、最終的な断片は終えられます(E=1)、と(すなわち、HDLCフレームの一部が最後の断片にはEがあるのを示すためにFSEに終わらせることができるデータ=0)は無視しました。
Each fragment begins with a normal header, so the structure of a frame could be:
各断片はフレームの構造が始まることができるように普通のヘッダーと共に始まります:
Figure 2: Example frame with FSE delimiter
図2: FSEデリミタがある例のフレーム
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| R | sequence | class | 1 |
+---+---+---+---+---+---+---+---+
| data |
: :
+---+---+---+---+---+---+---+---+
+ FSE + previous fragment implicitly E = 0
+---+---+---+---+---+---+---+---+
| R | sequence | class | 1 |
+---+---+---+---+---+---+---+---+
| data |
: :
+---+---+---+---+---+---+---+---+
| Frame | previous fragment implicitly E = 1
| CRC |
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | R| 系列| クラス| 1 | +---+---+---+---+---+---+---+---+ | データ| : : +---+---+---+---+---+---+---+---++FSE+前である、それとなくE=0+を断片化してください。---+---+---+---+---+---+---+---+ | R| 系列| クラス| 1 | +---+---+---+---+---+---+---+---+ | データ| : : +---+---+---+---+---+---+---+---+ | フレーム| 前である、それとなくE=1を断片化してください。| CRC| +---+---+---+---+---+---+---+---+
The value chosen for FSE is 0xDE (this is a relatively unlikely byte to occur in today's data streams, it does not trigger octet stuffing and triggers bit stuffing only for 1/8 of the possible preceding bytes).
FSEに選ばれた値は0xDE(これが今日のデータ・ストリームで起こる比較的ありそうもないバイトであり、それは、可能な前の1/8バイトだけ八重奏詰め物の引き金とならないで、ビット・スタッフィングの引き金となる)です。
The remaining problem is that of data transparency. In the scheme described so far, an FSE is always followed by a compact fragment header. In these headers, the combination of a class field set to 7
残った問題はデータ透明のものです。 今までのところ説明されている計画では、FSEはコンパクトな断片ヘッダーによっていつも後をつけられています。 これらのヘッダーでは、類体の組み合わせは7にセットしました。
Bormann Standards Track [Page 7] RFC 2687 PPP in Real-time Oriented HDLC-like Framing September 1999
ボルマンStandardsはリアルタイムの指向のHDLCのような縁どり1999年9月にRFC2687pppを追跡します[7ページ]。
with R=1 is reserved. Data transparency is achieved by making the occurrence of an FSE byte followed by one of 0x8F, 0x9F, ... to 0xFF special.
R=1が予約されている状態で。 0x8Fの1つをFSEバイトの発生に続かせていることによって、データ透明は達成されます、0x9F… 0xFFスペシャルに。
Figure 3: Data transparency with FSE bytes present
図3: FSEバイトが存在しているデータ透明
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| R | sequence | class | 1 |
+---+---+---+---+---+---+---+---+
| data |
: :
+---+---+---+---+---+---+---+---+
+ FSE + fragment NOT terminated
+---+---+---+---+---+---+---+---+
| R | S | T | U | 1 | 1 | 1 | 1 | R always is 1
+---+---+---+---+---+---+---+---+
| data | fragment continues
: :
0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | R| 系列| クラス| 1 | +---+---+---+---+---+---+---+---+ | データ| : : +---+---+---+---+---+---+---+---++FSE+断片は+を終えませんでした。---+---+---+---+---+---+---+---+ | R| S| T| U| 1 | 1 | 1 | 1 | いつもRは1+です。---+---+---+---+---+---+---+---+ | データ| 断片は続きます: :
In a combination of FSE/0xnF (where n is the first four-bit field in the second byte, RSTU in Figure 3), the n field gives a sequence of four bits indicating where in the received data stream FSE bytes, which cannot simply be transmitted in the data stream, are to be added by the receiver:
FSE/0xnF(nが2番目のバイト、図3のRSTUで最初の4ビットの分野であるところ)の組み合わせで、n分野はデータ・ストリームで絶対に伝えることができない受信データ流れのFSEバイトで受信機によって加えられることになっているように示す4ビットの系列を与えます:
0x8F: insert one FSE, back to data
0x9F: insert one FSE, copy two data bytes, insert one FSE, back to data
0xAF: insert one FSE, copy one data byte, insert one FSE, back to data
0xBF: insert one FSE, copy one data byte, insert two FSE bytes, back
to data
0xCF: insert two FSE bytes, back to data
0xDF: insert two FSE bytes, copy one data byte, insert one FSE, back
to data
0xEF: insert three FSE bytes, back to data
0xFF: insert four FSE bytes, back to data
0x8F: 1FSEをデータ0x9Fに挿入して戻してください: 1FSE、2データ・バイト(差し込み1FSE)がデータ0xAFに支持するコピーを挿入してください: 1FSE、1データバイト(差し込み1FSE)がデータ0xBFに支持するコピーを挿入してください: 1FSEを挿入してください、そして、1データ・バイトをコピーしてください、そして、データに0xCFを挿入してください: データに0xDFを挿入してください: 2FSEバイト、1データバイト(差し込み1FSE)がデータ0xEFに支持するコピーを挿入してください: データに0xFFを挿入してください: 4FSEバイトをデータに挿入して戻してください。
The data bytes following the FSE/0xnF combinations and corresponding to the zero bits in the N field may not be FSE bytes.
N分野でFSE/0xnF組み合わせに続いて、ゼロ・ビットに対応するデータ・バイトはFSEバイトでないかもしれません。
This scheme limits the worst case expansion factor by FSE processing to about 25 %. Also, it is designed such that a single data stream can either trigger worst-case expansion by octet stuffing (or by bit stuffing) or worst-case FSE processing, but never both. Figure 4 illustrates the scheme in a few examples; FSE/0xnF pairs are written in lower case.
この計画はおよそ25%へのFSE処理で最悪の場合膨張係数を制限します。 また、それは、ただ一つのデータ・ストリームが八重奏詰め物(またはビット・スタッフィングで)かしかし、最悪の場合FSE処理、決してどんな両方でも最悪の場合拡大の引き金となることができないように、設計されています。 図4はいくつかの例での計画を例証します。 FSE/0xnF組は小文字で書かれています。
Bormann Standards Track [Page 8] RFC 2687 PPP in Real-time Oriented HDLC-like Framing September 1999
ボルマンStandardsはリアルタイムの指向のHDLCのような縁どり1999年9月にRFC2687pppを追跡します[8ページ]。
Figure 4: Data transparency examples
図4: データ透明例
Data stream FSE-stuffed stream
データ・ストリームのFSEによって詰められた流れ
DD DE DF E0 DD de 8f DF E0
01 DE 02 DE 03 01 de af 02 03
DE DA DE DE DB de bf DA DB
DE DE DE DE DE DA de ff de 8f DA
DD DE DF0EのDD de 8f DF E0 01DE02DE03 01de af02 03DE DA DE DE DB de bf DA DB DE DE DE DE DE DA de ff de 8f DA
In summary, the real-time frame format is a HDLC-like frame delimited by flags and containing a final FCS as defined in [7], but without address and control fields, containing as data a sequence of FSE- stuffed fragments in compact fragment format, delimited by FSE bytes. As a special case, the final FSE may occur as the last byte of the data content (i.e. immediately before the FCS bytes) of the HDLC-like frame, to indicate that the last fragment in the frame is suspended and no final fragment is in the frame (e.g., because the desirable maximum size of the frame has been reached).
概要では、リアルタイムのフレーム形式は[7]で定義されますが、アドレスと制御フィールドなしで旗で区切られて、最終的なFCSを含むHDLCのようなフレームです、データとしてFSEバイト区切られたコンパクトな断片形式のFSEの詰められた断片の系列を含んでいて。 特殊なものとして、最終的なFSEはフレームにおける最後の断片が吊しているのを示すためにHDLCのようなフレームのデータ内容(すなわち、FCSバイトの直前)の最後のバイトとして起こるかもしれません、そして、どんな最終的な断片もフレームにありません(例えば、フレームの望ましい最大サイズに達したので)。
7. Implementation notes
7. 実現注意
7.1. MRU Issues
7.1. MRU問題
The LCP parameter MRU defines the maximum size of the packets sent on the link. Async-to-sync converters that are monitoring the LCP negotiations on the link may interpret the MRU value as the maximum HDLC frame size to be expected.
LCPパラメタMRUはリンクに送られたパケットの最大サイズを定義します。 最大のHDLCが予想されるためにサイズを縁どるとき、Asyncから同時性へのリンクのLCP交渉をモニターしているコンバータはMRU値を解釈するかもしれません。
Implementations of this specification should preferably negotiate a sufficiently large MRU to cover the worst-case 25 % increase in frame size plus the increase caused by suspended fragments. If that is not possible, the HDLC frame size should be limited by monitoring the HDLC frame sizes and possibly suspending the current fragment by sending an FSE with an empty final fragment (FSE immediately followed by the end of the information field, i.e. by CRC bytes and a flag) to be able to continue in a new HDLC frame. This strategy also helps minimizing the impact of lengthening the HDLC frame on the safety of the 16-bit FCS at the end of the HDLC frame.
望ましくは、この仕様の実現は、フレーム・サイズの最悪の場合の25%の増加と吊した断片によって引き起こされた増加を含むために十分大きいMRUを交渉するべきです。 それが可能でないなら、HDLCフレーム・サイズは、新しいHDLCフレームで続くことができるように空の最終的な断片(FSEはすぐに情報フィールドの端までに続きました、すなわち、CRCバイトと旗で)でFSEを送ることによって、HDLCフレーム・サイズをモニターして、ことによると現在の断片を吊すことによって、制限されるべきです。 また、この戦略は、HDLCフレームの端で16ビットのFCSの安全性でHDLCフレームを伸す衝撃を最小にするのを助けます。
7.2. Implementing octet-stuffing and FSE processing in one automaton
7.2. 1台のオートマトンで八重奏詰め物とFSE処理を実行します。
The simplest way to add real-time framing to an implementation may be to perform HDLC processing as usual and then, on the result, to perform FSE processing. A more advanced implementation may want to combine the two levels of escape character processing. Note, however, that FSE processing needs to wait until two bytes from the HDLC frame are available and followed by a third to ensure that the bytes are not the final HDLC FCS bytes, which are not subject to FSE
リアルタイムの縁どりを実現に加える最も簡単な方法はFSE処理を実行するためにいつものようと次に、結果にHDLC処理を実行することであるかもしれません。 より高度な実現は2つのレベルの拡張文字処理を結合したがっているかもしれません。 しかしながら、そのFSEに注意してください、HDLCフレームから2バイトが有効になるまで待つ必要性を処理して、続いて3分の1に注意します。(バイトが最終的なHDLC FCSバイトでないことを保証して、バイトはFSEを受けることがありません)。
Bormann Standards Track [Page 9] RFC 2687 PPP in Real-time Oriented HDLC-like Framing September 1999
ボルマンStandardsはリアルタイムの指向のHDLCのような縁どり1999年9月にRFC2687pppを追跡します[9ページ]。
processing. I.e., on the reception of normal data byte, look for an FSE in the second-to-previous byte, and, on the reception of a frame-end, look for an FSE as the last data byte.
処理。 フレームエンドのレセプションでは、すなわち、標準のデータ・バイトのレセプションでは、前への2番目のバイトでFSEを探してください、そして、最後のデータ・バイトとしてFSEを探してください。
8. Negotiable options
8. 交渉可能なオプション
The following options are already defined by MP [2]:
以下のオプションはMP[2]によって既に定義されます:
o Multilink Maximum Received Reconstructed Unit
o マルチリンクの最大の容認された再建された単位
o Multilink Short Sequence Number Header Format
o マルチリンクの短い一連番号ヘッダー形式
o Endpoint Discriminator
o 終点弁別器
The following options are already defined by MCML [5]:
以下のオプションはMCML[5]によって既に定義されます:
o Multilink Header Format
o マルチリンクヘッダー形式
o Prefix Elision
o 接頭語発音省略
This document defines two new code points for the Multilink Header Format option.
このドキュメントはMultilink Header Formatオプションのために2新法ポイントを定義します。
8.1. Multilink header format option
8.1. マルチリンクヘッダー形式オプション
The multilink header format option is defined in [5]. A summary of the Multilink Header Format Option format is shown below. The fields are transmitted from left to right.
マルチリンクヘッダー形式オプションは[5]で定義されます。 Multilink Header Format Option形式の概要は以下に示されます。 野原は左から右まで伝えられます。
Figure 5: Multilink header format option
図5: マルチリンクヘッダー形式オプション
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 = 27 | Length = 4 | Code | # Susp Clses |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =27をタイプしてください。| 長さ=4| コード| # Susp Clses| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
As defined in [5], this LCP option advises the peer that the
implementation wishes to receive fragments with a format given by
the code number, with the maximum number of suspendable classes (see
below) given. This specification defines two additional values for
Code, in addition to those defined in [5]:
[5]で定義されるように、このLCPオプションは、実現がコード番号で書式を与えていて断片を受け取りたがっていると同輩に忠告します、中断可能のクラス(以下を見る)の最大数を与えていて。 この仕様はCodeのために[5]で定義されたものに加えて2つの加算値を定義します:
- Code = 11: basic and extended compact real-time fragment format
with classes, in FSE-encoded HDLC frame
- =11をコード化してください: クラスがFSEによってコード化されたHDLCフレームにある基本的で拡張しているコンパクトなリアルタイムの断片形式
- Code = 15: basic compact real-time fragment format with classes,
in FSE-encoded HDLC frame
- =15をコード化してください: クラスがFSEによってコード化されたHDLCフレームにある基本的なコンパクトなリアルタイムの断片形式
Bormann Standards Track [Page 10] RFC 2687 PPP in Real-time Oriented HDLC-like Framing September 1999
ボルマンStandardsはリアルタイムの指向のHDLCのような縁どり1999年9月にRFC2687pppを追跡します[10ページ]。
An implementation MUST NOT request a combination of both LCP Address-and-Control-Field-Compression (ACFC) and the code values 11 or 15 for this option.
実現はLCP Addressとコントロール分野圧縮(ACFC)とこのオプションのためのコード値11か15の両方の組み合わせを要求してはいけません。
The number of suspendable classes negotiated for the compact real- time fragment format only limits the use of class numbers that allow suspending. As class numbers of 7 and higher do not require additional reassembly space, they are not subject to the class number limit negotiated.
コンパクトな本当の時間断片形式のために交渉された中断可能のクラスの数は中断するのを許容するクラス番号の使用を制限するだけです。 7について数をより高く分類してください。追加再アセンブリスペースを必要としないでください、そして、それらはクラス番号限界を条件として交渉されません。
9. Security Considerations
9. セキュリティ問題
Operation of this protocol is believed to be no more and no less secure than operation of the PPP multilink protocol [2]. Operation with a small sequence number range increases the likelihood that fragments from different packets could be incorrectly reassembled into one packet. While most such packets will be discarded by the receiver because of higher-layer checksum failures or other inconsistencies, there is an increase in likelihood that contents of packets destined for one host could be delivered to another host. Links that carry packets where this raises security considerations SHOULD use the extended sequence number range for multi-fragment packets.
PPPマルチリンクプロトコル[2]の操作ほど多くでなくてまたこのプロトコルの操作が、より安全でないというわけではないと信じられています。 小さい一連番号範囲がある操作は不当に異なったパケットからの断片を1つのパケットに組み立て直すことができた可能性を広げます。 そのようなほとんどのパケットが、より高い層のチェックサムの故障か他の矛盾のために受信機によって捨てられるでしょうが、1人のホストのために運命づけられたパケットのコンテンツを別のホストに送ることができたという見込みの増加があります。 これがセキュリティ問題SHOULDを上げるところまでパケットを運ぶリンクはマルチ断片パケットに拡張配列数の範囲を使用します。
10. References
10. 参照
[1] Bormann, C., "Providing Integrated Services over Low-bitrate
Links", RFC 2689, September 1999.
[1] C. ボルマン、1999年9月、「低いbitrateリンクの上に統合サービスを供給すること」でのRFC2689。
[2] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T.
Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, August
1996.
[2] Sklower、K.、ロイド、B.、マクレガー、G.、カー、D.、およびT.Coradetti、「pppマルチリンクは(MP)について議定書の中で述べます」、RFC1990、1996年8月。
[3] Simpson, W., "PPP in Frame Relay", RFC 1973, June 1996.
[3] シンプソン、W.、「フレームリレーにおけるppp」、RFC1973、1996年6月。
[4] Andrades, R. and F. Burg, "QOSPPP Framing Extensions to PPP",
Work in Progress.
[4] 「pppに拡大を縁どるQOSPPP」というアンドラデ、R.、およびF.町は進行中で働いています。
[5] Bormann, C., "The Multi-Class Extension to Multi-Link PPP", RFC
2686, September 1999.
[5] ボルマン、C.、「マルチリンクpppへのマルチのクラス拡大」、RFC2686、1999年9月。
[6] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
51, RFC 1661, July 1994.
[6] シンプソン、W.、エディタ、「二地点間プロトコル(ppp)」、STD51、RFC1661、1994年7月。
[7] Simpson, W., Editor, "PPP in HDLC-like Framing", STD 51, RFC
1662, July 1994.
[7] シンプソン、W.、エディタ、「HDLCのような縁どりにおけるppp」、STD51、RFC1662、1994年7月。
Bormann Standards Track [Page 11] RFC 2687 PPP in Real-time Oriented HDLC-like Framing September 1999
ボルマンStandardsはリアルタイムの指向のHDLCのような縁どり1999年9月にRFC2687pppを追跡します[11ページ]。
[8] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[8] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
11. Author's Address
11. 作者のアドレス
Carsten Bormann Universitaet Bremen FB3 TZI Postfach 330440 D-28334 Bremen, GERMANY
カルステンボルマンUniversitaetブレーメンFB3 TZI Postfach330440D-28334ブレーメン(ドイツ)
Phone: +49.421.218-7024 Fax: +49.421.218-7000 EMail: cabo@tzi.org
以下に電話をしてください。 +49.421 .218-7024Fax: +49.421 .218-7000メール: cabo@tzi.org
Acknowledgements
承認
The participants in a lunch BOF at the Montreal IETF 1996 gave useful input on the design tradeoffs in various environments. Richard Andrades, Fred Burg, and Murali Aravamudan insisted that there should be a suspend/resume solution in addition to the pre-fragmenting one defined in [5]. The members of the ISSLL subgroup on low bitrate links (ISSLOW) have helped in coming up with a set of requirements that shaped this solution.
様々な環境におけるデザイン見返りに関する役に立つ入力昼食の関係者。 リチャード・アンドラデ、フレッドBurg、およびMurali Aravamudanは、aがあるべきであると主張しました。1つが[5]で定義したプレ断片化に加えた解決策を中断するか、または再開してください。 低いbitrateリンク(ISSLOW)の上のISSLLサブグループのメンバーは、この解決策を形成した1セットの要件を思いつくのを手伝いました。
Bormann Standards Track [Page 12] RFC 2687 PPP in Real-time Oriented HDLC-like Framing September 1999
ボルマンStandardsはリアルタイムの指向のHDLCのような縁どり1999年9月にRFC2687pppを追跡します[12ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Bormann Standards Track [Page 13]
ボルマン標準化過程[13ページ]
一覧
スポンサーリンク
