[要約] RFC 2689は、低ビットレートリンク上で統合サービスを提供するためのガイドラインです。その目的は、低帯域幅のネットワーク上で効果的なサービス品質を実現するための手法を提供することです。
Network Working Group C. Bormann
Request for Comments: 2689 Universitaet Bremen TZI
Category: Informational September 1999
Providing Integrated Services over Low-bitrate Links
低ビトレートリンクを介して統合サービスを提供します
Status of this Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（1999）。無断転載を禁じます。
Abstract
概要
This document describes an architecture for providing integrated services over low-bitrate links, such as modem lines, ISDN B-channels, and sub-T1 links. It covers only the lower parts of the Internet Multimedia Conferencing Architecture [1]; additional components required for application services such as Internet Telephony (e.g., a session initiation protocol) are outside the scope of this document. 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.
このドキュメントでは、モデムライン、ISDN Bチャネル、Sub-T1リンクなど、低ビトレートリンクを介して統合サービスを提供するためのアーキテクチャについて説明します。インターネットのマルチメディア会議アーキテクチャの下部のみをカバーしています[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. Important elements of this development are:
「ベストエフォルト」サービスの拡張として、インターネットは有名であるため、リアルタイムのマルチメディア情報の輸送をサポートする追加の種類のサービス（「統合サービス」）が開発され、インターネットに展開されています。この開発の重要な要素は次のとおりです。
- parameters for forwarding mechanisms that are appropriate for real-time information [11, 12],
- リアルタイム情報に適した転送メカニズムのパラメーター[11、12]、
- a setup protocol that allows establishing special forwarding treatment for real-time information flows (RSVP [4]),
- リアルタイム情報フローのための特別な転送処理の確立を可能にするセットアッププロトコル（RSVP [4]）、
- a transport protocol for real-time information (RTP/RTCP [6]).
- リアルタイム情報用のトランスポートプロトコル（RTP/RTCP [6]）。
In addition to these elements at the network and transport levels of the Internet Multimedia Conferencing Architecture [1], further components are required to define application services such as Internet Telephony, e.g., protocols for session initiation and control. These components are outside the scope of this document.
インターネットマルチメディア会議アーキテクチャ[1]のネットワークおよび輸送レベルのこれらの要素に加えて、インターネットテレフォニーなどのアプリケーションサービス、たとえばセッションの開始と制御のプロトコルなどのアプリケーションサービスを定義するには、さらにコンポーネントが必要です。これらのコンポーネントは、このドキュメントの範囲外です。
Up to now, the newly developed services could not (or only very inefficiently) be used over forwarding paths that include low-bitrate links such as 14.4, 33.6, and 56 kbit/s modems, 56 and 64 kbit/s ISDN B-channels, or even sub-T1 links. The encapsulation formats used on these links are not appropriate for the simultaneous transport of arbitrary data and real-time information that has to meet stringent delay requirements. Transmission of a 1500 byte packet on a 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. In addition, the header overhead associated with the protocol stacks used is prohibitive on low-bitrate links, where compression down to a few dozen bytes per real-time information packet is often desirable. E.g., the overhead of at least 44 (4+20+8+12) bytes for HDLC/PPP, IP, UDP, and RTP completely overshadows typical audio payloads such as the 19.75 bytes needed for a G.723.1 ACELP audio frame -- a 14.4 kbit/s link is completely consumed by this header overhead alone at 40 real-time frames per second total (i.e., at 25 ms packetization delay for one stream or 50 ms for two streams, with no space left for data, yet). While the header overhead can be reduced by combining several real-time information frames into one packet, this increases the delay incurred while filling that packet and further detracts from the goal of real-time transfer of multi-media information over the Internet.
これまで、新しく開発されたサービスは、14.4、33.6、および56 Kbit/sモデム、56および64 kbit/s ISDN Bチャネルなどの低ビトレートリンクを含む転送パスを介して使用できませんでした（または非常に非効率的に）使用できませんでした。、またはsub-t1リンクもあります。これらのリンクで使用されるカプセル化形式は、任意のデータと厳しい遅延要件を満たす必要があるリアルタイム情報の同時輸送には適していません。28.8 kbit/sモデムリンクに1500バイトのパケットを送信すると、このリンクは約400ミリ秒のリアルタイム情報の送信では利用できなくなります。これにより、最悪の遅延が追加され、リアルタイムの会話には、少なくとも1秒の順序で往復遅延が発生し、往復の遅延で動作します。さらに、使用されるプロトコルスタックに関連付けられたヘッダーオーバーヘッドは、低ビトル酸リンクでは法外なものであり、リアルタイムの情報パケットごとに数十バイトダウンまでの圧縮が望ましいことがよくあります。たとえば、HDLC/PPP、IP、UDP、およびRTPの少なくとも44（4 20 8 12）バイトのオーバーヘッドは、G.723.1 ACELPオーディオフレームに必要な19.75バイトなどの典型的なオーディオペイロードを完全に覆い隠します-14.4 KBIT/sリンクは、このヘッダーのオーバーヘッドだけで完全に消費されます。40秒あたりの40リアルタイムフレーム（つまり、1つのストリームで25ミリ秒のパケット化遅延、2つのストリームで50ミリ秒で、データ用のスペースが残っていません）。ヘッダーのオーバーヘッドは、いくつかのリアルタイム情報フレームを1つのパケットに組み合わせることで削減できますが、これにより、そのパケットを埋めながら発生した遅延が増加し、インターネット上のマルチメディア情報のリアルタイム転送の目標からさらに損なわれます。
This document describes an approach for addressing these problems. 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.
- この交渉を行うためにアプリケーションで使用される発表プロトコル。
The main design goal for an architecture that addresses real-time multimedia flows over low-bitrate links is that of minimizing the end-to-end delay. More specifically, the worst case delay (after removing possible outliers, which are equivalent to packet losses from an application point of view) is what determines the playout points selected by the applications and thus the delay actually perceived by the user.
低ビトレートリンク上のリアルタイムマルチメディアフローに対処するアーキテクチャの主な設計目標は、エンドツーエンドの遅延を最小化することです。より具体的には、最悪のケースの遅延（アプリケーションの観点からのパケット損失に相当する可能性のある外れ値を削除した後）は、アプリケーションによって選択されたプレイアウトポイントを決定するため、ユーザーが実際に知覚する遅延を決定します。
In addition, any such architecture should obviously undertake every attempt to maximize the bandwidth actually available to media data; overheads must be minimized.
さらに、このようなアーキテクチャは、メディアデータが実際に利用できる帯域幅を最大化するためのあらゆる試みを明らかに引き受ける必要があります。オーバーヘッドを最小限に抑える必要があります。
An important component of the integrated services architecture is the provision of reservations for real-time flows. One of the problems that systems on low-bitrate links (routers or hosts) face when performing admission control for such reservations is that they must translate the bandwidth requested in the reservation to the one actually consumed on the link. Methods such as data compression and/or header compression can reduce the requirements on the link, but admission control can only make use of the reduced requirements in its calculations if it has enough information about the data stream to know how effective the compression will be. One goal of the architecture therefore is to provide the integrated services admission control with this information. A beneficial side effect may be to allow the systems to perform better compression than would be possible without this information. This may make it worthwhile to provide this information even when it is not intended to make a reservation for a real-time flow.
統合サービスアーキテクチャの重要な要素は、リアルタイムフローの予約の提供です。低ビトレートリンクのシステム（ルーターまたはホスト）が直面する問題の1つは、そのような予約のために入学制御を実行する際に直面することです。予約で要求された帯域幅をリンクで実際に消費した帯域幅に変換する必要があることです。データ圧縮やヘッダー圧縮などの方法は、リンクの要件を減らすことができますが、入場制御は、圧縮の効果がどれほど効果的かを知るためにデータストリームに関する十分な情報がある場合にのみ、計算の要件を減らすことができます。したがって、アーキテクチャの目標の1つは、この情報を統合されたサービス入学制御に提供することです。有益な副作用は、この情報がなければ、システムが可能になるよりも優れた圧縮を実行できるようにすることです。これにより、リアルタイムフローの予約を意図していない場合でも、この情報を提供する価値があります。
Many technical approaches come to mind for addressing these problems, in particular a new form of low-delay encapsulation to address delay and header compression methods to address overhead. This section shows that these techniques should be combined to solve the problem.
これらの問題に対処するために多くの技術的なアプローチが思い浮かびます。特に、頭上に対処するための遅延とヘッダーの圧縮方法に対処するための低遅延のカプセル化の新しい形式です。このセクションでは、これらの手法を組み合わせて問題を解決する必要があることを示しています。
The purpose of defining a real-time link-layer encapsulation protocol is to be able to introduce newly arrived real-time packets into the link-layer data stream without having to wait for the currently transmitted (possibly large) packet to end. Obviously, a real-time encapsulation must be part of any complete solution as the problem of delays induced by large frames on the link can only be solved on this layer.
リアルタイムのリンク層カプセル化プロトコルを定義する目的は、現在送信されている（おそらく大きな）パケットが終了するのを待つことなく、新しく到着したリアルタイムパケットをリンク層データストリームに導入できることです。明らかに、リンク上の大きなフレームによって引き起こされる遅延の問題は、このレイヤーでのみ解決できるため、リアルタイムのカプセル化は完全なソリューションの一部でなければなりません。
To be able to switch to a real-time packet quickly in an interface driver, it is first necessary to identify packets that belong to real-time flows. This can be done using a heuristic approach (e.g., favor the transmission of highly periodic flows of small packets transported in IP/UDP, or use the IP precedence fields in a specific way defined within an organization). Preferably, one also could make use of a protocol defined for identifying flows that require special treatment, i.e. RSVP. Of the two service types defined for use with RSVP now, the guaranteed service will only be available in certain environments; for this and various other reasons, the service type chosen for many adaptive audio/video applications will most likely be the controlled-load service. Controlled-load does not provide control parameters for target delay; thus it does not unambiguously identify those packet streams that would benefit most from being transported in a real-time encapsulation format. This calls for a way to provide additional parameters in integrated services flow setup protocols to control the real-time encapsulation.
インターフェイスドライバーでリアルタイムパケットにすばやく切り替えることができるようにするには、まずリアルタイムフローに属するパケットを識別する必要があります。これは、ヒューリスティックアプローチを使用して実行できます（たとえば、IP/UDPで輸送される小さなパケットの非常に周期的なフローの伝達を支持するか、組織内で定義された特定の方法でIP優先フィールドを使用します）。好ましくは、特別な治療、つまりRSVPを必要とするフローを識別するために定義されたプロトコルを使用することもできます。RSVPで使用するために定義された2つのサービスタイプのうち、保証されたサービスは特定の環境でのみ利用可能になります。これおよびその他のさまざまな理由のために、多くの適応オーディオ/ビデオアプリケーションに選択されたサービスタイプは、おそらく制御されたロードサービスです。制御されたロードは、ターゲット遅延の制御パラメーターを提供しません。したがって、リアルタイムのカプセル化形式で輸送されることから最も恩恵を受けるパケットストリームを明確に識別することはありません。これには、統合サービスフローセットアッププロトコルに追加のパラメーターを提供して、リアルタイムのカプセル化を制御する方法が必要です。
Real-time encapsulation is not sufficient on its own, however: Even if the relevant flows can be appropriately identified for real-time treatment, most applications simply cannot operate properly on low-bitrate links with the header overhead implied by the combination of HDLC/PPP, IP, UDP, and RTP, i.e. they absolutely require header compression.
ただし、リアルタイムのカプセル化はそれ自体では十分ではありません。関連するフローをリアルタイム治療のために適切に識別できる場合でも、ほとんどのアプリケーションは、HDLC/の組み合わせによって暗示されるヘッダーオーバーヘッドとの低ビトレートリンクで適切に動作することはできません。PPP、IP、UDP、およびRTP、つまり、ヘッダー圧縮が絶対に必要です。
Header compression can be performed in a variety of elements and at a variety of levels in the protocol architecture. As many vendors of Internet Telephony products for PCs ship applications, the approach that is most obvious to them is to reduce overhead by performing header compression at the application level, i.e. above transport protocols such as UDP (or actually by using a non-standard, efficiently coded header in the first place).
ヘッダー圧縮は、さまざまな要素で、プロトコルアーキテクチャのさまざまなレベルで実行できます。PCS船舶用のインターネットテレフォニー製品のベンダーの多くは、アプリケーションに最も明白なアプローチは、アプリケーションレベルでヘッダー圧縮を実行することでオーバーヘッドを減らすことです。そもそも効率的にコーディングされたヘッダー）。
Generally, header compression operates by installing state at both ends of a path that allows the receiving end to reconstruct information omitted at the sending end. Many good techniques for header compression (RFC 1144, [2]) operate on the assumption that the path will not reorder the frames generated. This assumption does not hold for end-to-end compression; therefore additional overhead is required for resequencing state changes and for compressed packets making use of these state changes.
一般に、ヘッダー圧縮は、受信側が送信端で省略された情報を再構築できるようにするパスの両端に状態をインストールすることにより動作します。ヘッダー圧縮のための多くの優れた手法（RFC 1144、[2]）は、パスが生成されたフレームを再注文しないという仮定で動作します。この仮定は、エンドツーエンドの圧縮には当てはまりません。したがって、状態の変更を再標準化し、これらの状態の変更を利用する圧縮パケットには、追加のオーバーヘッドが必要です。
Assume that a very good application level header compression solution for RTP flows could be able to save 11 out of the 12 bytes of an RTP header [3]. Even this perfect solution only reduces the total header overhead by 1/4. It would have to be deployed in all applications, even those that operate on systems that are attached to higher-bitrate links.
RTPフローの非常に優れたアプリケーションレベルのヘッダー圧縮ソリューションが、RTPヘッダーの12バイトのうち11を節約できる可能性があると仮定します[3]。この完璧なソリューションでさえ、総ヘッダーのオーバーヘッドを1/4に減らすだけです。それは、すべてのアプリケーション、さらには高ビトレートリンクに接続されているシステムで動作するアプリケーションで展開する必要があります。
Because of this limited effectiveness, the AVT group that is responsible for RTP within the IETF has decided to not further pursue application level header compression.
この限られた効果のため、IETF内のRTPの原因となるAVTグループは、アプリケーションレベルのヘッダー圧縮をさらに追求しないことを決定しました。
For router and IP stack vendors, the obvious approach is to define header compression that can be negotiated between peer routers.
ルーターとIPスタックベンダーの場合、明らかなアプローチは、ピアルーター間で交渉できるヘッダー圧縮を定義することです。
Advanced header compression techniques now being defined in the IETF [2] certainly can relieve the link from significant parts of the IP/UDP overhead (i.e., most of 28 of the 44 bytes mentioned above).
IETF [2]で現在定義されている高度なヘッダー圧縮技術は、IP/UDPオーバーヘッドの重要な部分（つまり、上記の44バイトの28のほとんど）からリンクを緩和できます。
One of the design principles of the new IP header compression developed in conjunction with IPv6 is that it stops at layers the semantics of which cannot be inferred from information in lower layer (outer) headers. Therefore, this header compression technique alone cannot compress the data that is contained within UDP packets.
IPv6と組み合わせて開発された新しいIPヘッダー圧縮の設計原則の1つは、下層（外側）ヘッダーの情報から推測できないセマンティクスがレイヤーで停止することです。したがって、このヘッダー圧縮手法だけでは、UDPパケットに含まれるデータを圧縮できません。
Any additional header compression technique runs into a problem: If it assumes specific application semantics (i.e., those of RTP and a payload data format) based on heuristics, it runs the risk of being triggered falsely and (e.g. in case of packet loss) reconstructing packets that are catastrophically incorrect for the application actually being used. A header compression technique that can be operated based on heuristics but does not cause incorrect decompression even if the heuristics failed is described in [7]; a companion document describes the mapping of this technique to PPP [10].
追加のヘッダー圧縮手法は問題に陥ります。ヒューリスティックに基づいて特定のアプリケーションセマンティクス（つまり、RTPおよびペイロードデータ形式の形式）を想定している場合、誤ってトリガーされるリスクを実行します（例えば、パケット損失の場合）再構築します。 実際に使用されているアプリケーションに対して壊滅的に間違っているパケット。 ヒューリスティックに基づいて動作できるが、ヒューリスティックが故障した場合でも誤った減圧を引き起こさないヘッダー圧縮手法は[7]で説明されています。 コンパニオンドキュメントは、この手法のPPPへのマッピングについて説明しています[10]。
With all of these techniques, the total IP/UDP/RTP header overhead for an audio stream can be reduced to two bytes per packet. This technology need only be deployed at bottleneck links; high-speed links can transfer the real-time streams without routers or switches expending CPU cycles to perform header compression.
これらすべての手法では、オーディオストリームの合計IP/UDP/RTPヘッダーオーバーヘッドをパケットごとに2バイトに削減できます。このテクノロジーは、ボトルネックリンクに展開するだけです。高速リンクは、ルーターまたはスイッチを使用せずにリアルタイムストリームを転送し、CPUサイクルを使用してヘッダー圧縮を実行できます。
The main design goal for a real-time encapsulation is to minimize the delay incurred by real-time packets that become available for sending while a long data packet is being sent. To achieve this, the encapsulation must be able to either abort or suspend the transfer of the long data packet. As an additional goal is to minimize the overhead required for the transmission of packets from periodic flows, this strongly argues for being able to suspend a packet, i.e. segment it into parts between which the real-time packets can be transferred.
リアルタイムのカプセル化の主な設計目標は、長いデータパケットが送信されている間に送信できるようになるリアルタイムパケットによって発生する遅延を最小限に抑えることです。 これを達成するには、カプセル化が長いデータパケットの転送を中止または停止できる必要があります。 追加の目標は、周期的なフローからのパケットの送信に必要なオーバーヘッドを最小限に抑えることであるため、これはパケットを一時停止できることを強く主張します。つまり、リアルタイムパケットを転送できる部分にセグメント化します。
Transmitting only part of a packet, to allow higher-priority traffic to intervene and then resuming its transmission later on, is a kind of fragmentation. Fragmentation is an existing functionality of the IP layer: An IPv4 header already contains fields that allow a large IP datagram to be fragmented into small parts. A sender's "real-time PPP" implementation might simply indicate a small MTU to its IP stack and thus cause all larger datagrams to be fragmented down to a size that allows the access delay goals to be met (this assumes that the IP stack is able to priority-tag fragments, or that the PPP implementation is able to correlate the fragments to the initial one that carries the information relevant for prioritizing, or that only initial fragments can be high-priority). (Also, a PPP implementation can negotiate down the MTU of its peer, causing the peer to fragment to a small size, which might be considered a crude form of negotiating an access delay goal with the peer system -- if that system supports priority queueing at the fragment level.)
パケットの一部のみを送信して、より優先順位のトラフィックが介入し、その後その送信を後で再開できるようにすることは、一種の断片化です。フラグメンテーションは、IPレイヤーの既存の機能です。IPv4ヘッダーには、大きなIPデータグラムを小さな部分に断片化できるフィールドが既に含まれています。送信者の「リアルタイムPPP」の実装は、単にIPスタックに小さなMTUを示す可能性があるため、すべての大きなデータグラムをサイズに断片化させて、アクセス遅延目標を満たすことができます（これは、IPスタックが可能であると仮定します優先タグフラグメント、またはPPPの実装が、優先順位付けに関連する情報を運ぶ最初の断片とフラグメントを相関させることができる、または初期フラグメントのみが優先度が高い可能性があること。（また、PPPの実装により、ピアのMTUを交渉して、ピアが小さなサイズに断片化することができます。フラグメントレベルで。）
Unfortunately, a full, 20 byte IP header is needed for each fragment (larger when IP options are used). This limits the minimum size of fragments that can be used without too much overhead. (Also, the size of non-final fragments must be a multiple of 8 bytes, further limiting the choice.) With path MTU discovery, IP level fragmentation causes TCP implementations to use small MSSs -- this further increases the per-packet overhead to 40 bytes per fragment.
残念ながら、各フラグメントに対して完全な20バイトIPヘッダーが必要です（IPオプションが使用される場合は大きく）。これにより、オーバーヘッドをあまり使用することなく使用できるフラグメントの最小サイズが制限されます。（また、非ファイナルフラグメントのサイズは8バイトの倍数である必要があり、選択をさらに制限します。）PATH MTU発見により、IPレベルの断片化によりTCP実装が小さなMSSSを使用します。これにより、パケットごとのオーバーヘッドがさらに増加します。フラグメントごとに40バイト。
In any case, fragmentation at the IP level persists on the path further down to the datagram receiver, increasing the transmission overheads and router load throughout the network. With its high overhead and the adverse effect on the Internet, IP level fragmentation can only be a stop-gap mechanism when no other fragmentation protocol is available in the peer implementation.
いずれにせよ、IPレベルでのフラグメンテーションは、データグラムレシーバーまでさらにパスで持続し、ネットワーク全体の伝送オーバーヘッドとルーターの負荷を増加させます。オーバーヘッドが高く、インターネットに悪影響を及ぼし、IPレベルの断片化は、ピア実装で他の断片化プロトコルが利用できない場合にのみ、ストップギャップメカニズムになります。
Cell-oriented multiplexing techniques such as ATM that introduce regular points where cells from a different packet can be interpolated are too inefficient for low-bitrate links; also, they are not supported by chips used to support the link layer in low-bitrate routers and host interfaces.
異なるパケットからのセルを補間できる通常のポイントを導入するATMなどの細胞指向の多重化技術は、低ビトレートリンクには非効率的です。また、それらは、低ビトレートルーターとホストインターフェイスのリンク層をサポートするために使用されるチップによってサポートされていません。
Instead, the real-time encapsulation should as far as possible make use of the capabilities of the chips that have been deployed. On synchronous lines, these chips support HDLC framing; on asynchronous lines, an asynchronous variant of HDLC that usually is implemented in software is being used. Both variants of HDLC provide a delimiting mechanism to indicate the end of a frame over the link. The obvious solution to the segmentation problem is to combine this mechanism with an indication of whether the delimiter terminates or suspends the current packet.
代わりに、リアルタイムのカプセル化は、展開されたチップの機能を可能な限り利用する必要があります。同期線では、これらのチップはHDLCフレーミングをサポートします。非同期線では、ソフトウェアに通常実装されるHDLCの非同期バリアントが使用されています。HDLCの両方のバリアントは、リンク上のフレームの終了を示す境界線を提供します。セグメンテーション問題の明らかな解決策は、このメカニズムを、デリミッターが現在のパケットを終了または停止するかどうかを示すことと組み合わせることです。
This indication could be in an octet appended to each frame information field; however, seven out of eight bits of the octet would be wasted. Instead, the bit could be carried at the start of the next frame in conjunction with multiplexing information (PPP protocol identifier etc.) that will be required here anyway. Since the real-time flows will in general be periodic, this multiplexing information could convey (part of) the compressed form of the header for the packet. If packets from the real-time flow generally are of constant length (or have a defined maximum length that is often used), the continuation of the suspended packet could be immediately attached to it, without expending a further frame delimiter, i.e., the interpolation of the real-time packet would then have zero overhead. Since packets from low-delay real-time flows generally will not require the ability to be further suspended, the continuation bit could be reserved for the non-real-time packet stream.
この兆候は、各フレーム情報フィールドに追加されたオクテットにある可能性があります。ただし、オクテットの8ビットのうち7ビットが無駄になります。代わりに、とにかくここで必要とされる多重化情報（PPPプロトコル識別子など）と組み合わせて、次のフレームの開始時にビットを運ぶことができます。リアルタイムフローは一般に周期的であるため、この多重化情報は、パケットのヘッダーの圧縮形式を（の一部）伝達する可能性があります。リアルタイムのフローからのパケットが一般に一定の長さ（または頻繁に使用される最大長が定義されている）の場合、さらにフレームデリミタ、つまり補間を消費することなく、吊りパケットの継続をすぐに取り付けることができます。リアルタイムパケットのオーバーヘッドはゼロになります。低遅延のリアルタイムフローからのパケットは、一般にさらに吊り下げる能力を必要としないため、継続ビットは非リアルタイムパケットストリームに予約される可能性があります。
One real-time encapsulation format with these (and other) functions is described in ITU-T H.223 [13], the multiplex used by the H.324 modem-based videophone standard [14]. It was investigated whether compatibility could be achieved with this specification, which will be used in future videophone-enabled (H.324 capable) modems. However, since the multiplexing capabilities of H.223 are limited to 15 schedules (definitions of sequences of packet types that can be identified in a multiplex header), for general Internet usage a superset or a more general encapsulation would have been required. Also, a PPP-style negotiation protocol was needed instead of using (and necessarily extending) ITU-T H.245 [15] for setting the parameters of the multiplex. In the PPP context, the interactions with the encapsulations for data compression and link layer encryption needed to be defined (including operation in the presence of padding). But most important, H.223 requires synchronous HDLC chips that can be configured to send frames without an attached CRC, which is not possible with all chips deployed in commercially available routers; so complete compatibility was unachievable.
これらの（およびその他の）関数を使用した1つのリアルタイムカプセル化形式は、H.324モデムベースのビデオフォン標準[14]で使用される多重であるITU-T H.223 [13]で説明されています。この仕様で互換性を達成できるかどうかを調査しました。これは、将来のビデオフォン対応（H.324対応）モデムで使用されるものです。ただし、H.223の多重化機能は15のスケジュール（マルチプレックスヘッダーで識別できるパケットタイプのシーケンスの定義）に制限されているため、一般的なインターネット使用のために、スーパーセットまたはより一般的なカプセル化が必要でした。また、マルチプレックスのパラメーターを設定するために、ITU-T H.245 [15]を使用（および必然的に拡張）する代わりに、PPPスタイルのネゴシエーションプロトコルが必要でした。PPPコンテキストでは、データ圧縮およびリンク層暗号化のカプセルとの相互作用を定義する必要がありました（パディングの存在下での操作を含む）。しかし、最も重要なことは、H.223では、CRCが添付されていないフレームを送信するように構成できる同期HDLCチップが必要です。これは、市販のルーターに展開されているすべてのチップでは不可能です。したがって、完全な互換性は達成できませんでした。
Instead of adopting H.223, it was decided to pursue an approach that is oriented towards compatibility both with existing hardware and existing software (in particular PPP) implementations. The next subsection groups these implementations according to their capabilities.
H.223を採用する代わりに、既存のハードウェアと既存のソフトウェア（特にPPP）の実装の両方との互換性に向けられたアプローチを追求することが決定されました。次のサブセクションは、これらの実装をその機能に従ってグループ化します。
This section introduces a number of terms for types of implementations that are likely to emerge. It is important to have these different implementation models in mind as there is no single approach that fits all models best.
このセクションでは、出現する可能性のある実装の種類について多くの用語を紹介します。すべてのモデルに最適な単一のアプローチがないため、これらの異なる実装モデルを念頭に置くことが重要です。
There are two fundamental approaches to real-time transmission on low-bitrate links:
低ビトレートリンクにリアルタイムトランスミッションには2つの基本的なアプローチがあります。
Sender type 1 The PPP real-time framing implementation is able to control the transmission of each byte being transmitted with some known, bounded delay (e.g., due to FIFOs). For example, this is generally true of PC host implementations, which directly access serial interface chips byte by byte or by filling a very small FIFO. For type 1 senders, a suspend/resume type approach will be typically used: When a long frame is to be sent, the attempt is to send it undivided; only if higher priority packets come up during the transmission will the lower-priority long frame be suspended and later resumed. This approach allows the minimum variation in access delay for high-priority packets; also, fragmentation overhead is only incurred when actually needed.
送信者タイプ1 PPPリアルタイムフレーミング実装は、既知の境界遅延（FIFOSなど）で送信される各バイトの送信を制御できます。たとえば、これは一般に、バイトでシリアルインターフェイスチップバイトに直接アクセスするか、非常に小さなFIFOを埋めることで直接アクセスするPCホストの実装に当てはまります。タイプ1の送信者の場合、通常、一時停止/履歴書タイプのアプローチが使用されます。長いフレームを送信する場合、試行は分割されていません。トランスミッション中により高い優先パケットが登場した場合にのみ、より低い優先度の長いフレームが吊り下げられ、後に再開されます。このアプローチにより、高優先度パケットのアクセス遅延の最小変動が可能になります。また、フラグメンテーションオーバーヘッドは、実際に必要な場合にのみ発生します。
Sender type 2 With type 2 senders, the interface between the PPP real-time framing implementation and the transmission hardware is not in terms of streams of bytes, but in terms of frames, e.g., in the form of multiple (prioritized) send queues directly supported by hardware. This is often true of router systems for synchronous links, in particular those that have to support a large number of low-bitrate links. As type 2 senders have no way to suspend a frame once it has been handed down for transmission, they typically will use a queues-of-fragments approach, where long packets are always split into units that are small enough to maintain the access delay goals for higher-priority traffic. There is a trade-off between the variation in access delay resulting from a large fragment size and the overhead that is incurred for every long packet by choosing a small fragment size.
タイプ2の送信者タイプ2、タイプ2の送信者、PPPリアルタイムフレーミングの実装とトランスミッションハードウェアの間のインターフェイスは、バイトのストリームの観点ではなく、たとえば複数（優先順位付け）の形式でフレームの観点から直接送信されます。ハードウェアでサポートされています。これは、同期リンクのルーターシステム、特に多数の低ビトレートリンクをサポートする必要があるルーターシステムに当てはまることがよくあります。タイプ2の送信者は、送信のために伝達されるとフレームを一時停止する方法がないため、通常、長いパケットが常にアクセス遅延の目標を維持するのに十分な小さいユニットに分割されるフラグメントのQueues of-Fragmentsアプローチを使用します。より優先順位のトラフィック用。大きなフラグメントサイズの大きさから生じるアクセス遅延の変動と、小さなフラグメントサイズを選択して各長いパケットに発生するオーバーヘッドとの間にトレードオフがあります。
Although the actual work of formulating transmission streams for real-time applications is performed at the sender, the ability of the receiver to immediately make use of the information received depends on its characteristics:
リアルタイムアプリケーション用の送信ストリームを策定する実際の作業は送信者で実行されますが、受信者が受信した情報をすぐに利用する能力は、その特性によって異なります。
Receiver type 1 Type 1 receivers have full control over the stream of bytes received within PPP frames, i.e., bytes received are available immediately to the PPP real-time framing implementation (with some known, bounded delay e.g. due to FIFOs etc.).
受信機タイプ1タイプ1レシーバーは、PPPフレーム内で受信したバイトのストリームを完全に制御できます。つまり、受信したバイトは、PPPリアルタイムフレーミングの実装にすぐに利用できます（たとえば、FIFOなどによる既知の境界遅延など）。
Receiver type 2 With type 2 receivers, the PPP real-time framing implementation only gets hold of a frame when it has been received completely, i.e., the final flag has been processed (typically by some HDLC chip that directly fills a memory buffer).
レシーバータイプ2タイプ2レシーバーでは、PPPリアルタイムフレーミングの実装は、完全に受信されたときにフレームを保持します。つまり、最終フラグが処理されました（通常、メモリバッファーを直接満たすHDLCチップによって）。
As a result of the diversity in capabilities of current implementations, there are now two specifications for real-time encapsulation: One, the multi-class extension to the PPP multi-link protocol, is providing the solution for the queues-of-fragments approach by extending the single-stream PPP multi-link protocol by multiple classes [8]. The other encapsulation, PPP in a real-time oriented HDLC-like framing, builds on this specification end extends it by a way to dynamically delimit multiple fragments within one HDLC frame [9], providing the solution for the suspend/resume type approach.
現在の実装の機能の多様性の結果として、リアルタイムカプセル化のための2つの仕様が現在あります。1つは、PPPマルチリンクプロトコルのマルチクラス拡張です。シングルストリームPPPマルチリンクプロトコルを複数のクラス[8]を拡張することにより。他のカプセル化、リアルタイム指向のHDLCのようなフレーミングのPPPは、この仕様の端に構築され、1つのHDLCフレーム内で複数のフラグメントを動的に区切る方法[9]に拡張し、一時停止/履歴書タイプのアプローチのソリューションを提供します。
A good baseline for a discussion about header compression is in the new IP header compression specification that was designed in conjunction with the development of IPv6 [2]. The techniques used there can reduce the 28 bytes of IPv4/UDP header to about 6 bytes (depending on the number of concurrent streams); with the remaining 4 bytes of HDLC/PPP overhead and 12 bytes for RTP the total header overhead can be about halved but still exceeds the size of a G.723.1 ACELP frame. Note that, in contrast to IP header compression, the environment discussed here assumes the existence of a full-duplex PPP link and thus can rely on negotiation where IP header compression requires repeated transmission of the same information. (The use of the architecture of the present document with link layer multicasting has not yet been examined.) Additional design effort was required for RTP header compression. Applying the concepts of IP header compression, of the (at least) 12 bytes in an RTP header, 7 bytes (timestamp, sequence, and marker bit) would qualify as RANDOM; DELTA encoding cannot generally be used without further information since the lower layer header does not unambiguously identify the semantics and there is no TCP checksum that can be relied on to detect incorrect decompression. Only a more semantics-oriented approach can provide better compression (just as RFC 1144 can provide very good compression of TCP headers by making use of semantic knowledge of TCP and its checksumming method).
ヘッダー圧縮に関する議論のための優れたベースラインは、IPv6の開発と組み合わせて設計された新しいIPヘッダー圧縮仕様にあります[2]。そこに使用される手法は、28バイトのIPv4/UDPヘッダーを約6バイトに減らすことができます（同時ストリームの数に応じて）。残りの4バイトのHDLC/PPPオーバーヘッドとRTPの12バイトで、総ヘッダーオーバーヘッドは約半分になりますが、G.723.1 ACELPフレームのサイズを超えています。IPヘッダー圧縮とは対照的に、ここで説明する環境は、全二重PPPリンクの存在を想定しているため、IPヘッダー圧縮に同じ情報の繰り返し伝送が必要な交渉に依存できることに注意してください。（リンクレイヤーマルチキャストを使用した現在のドキュメントのアーキテクチャの使用はまだ検討されていません。）RTPヘッダー圧縮には追加の設計努力が必要でした。RTPヘッダーの（少なくとも）12バイトのIPヘッダー圧縮の概念を適用すると、7バイト（タイムスタンプ、シーケンス、およびマーカービット）がランダムに適格です。下層ヘッダーはセマンティクスを明確に識別せず、誤った減圧を検出するために依存することができるTCPチェックサムはないため、通常、デルタエンコーディングは詳細情報なしでは使用できません。よりセマンティクス指向のアプローチのみがより良い圧縮を提供できます（RFC 1144がTCPのセマンティック知識とそのチェックサム化方法を利用することにより、TCPヘッダーの非常に良好な圧縮を提供できるように）。
For RTP packets, differential encoding of the sequence number and timestamps is an efficient approach for certain cases of payload data formats. E.g., speech flows generally have sequence numbers and timestamp fields that increase by 1 and by the frame size in timestamp units, resp.; the CRTP (compressed RTP) specification makes use of this relationship by encoding these fields only when the second order difference is non-zero [7].
RTPパケットの場合、シーケンス番号とタイムスタンプの差動エンコードは、ペイロードデータ形式の特定のケースの効率的なアプローチです。たとえば、音声フローには、一般に、シーケンス番号とタイムスタンプフィールドがあり、タイムスタンプユニットのフレームサイズによって増加します。CRTP（圧縮RTP）仕様は、2次の差が非ゼロの場合にのみこれらのフィールドをエンコードすることにより、この関係を利用します[7]。
As argued, the compressor can operate best if it can make use of information that clearly identifies real-time streams and provides information about the payload data format in use.
議論されているように、コンプレッサーは、リアルタイムのストリームを明確に識別し、使用中のペイロードデータ形式に関する情報を提供する情報を使用できる場合に最適に動作できます。
If these systems are routers, this consent must be installed as router state; if these systems are hosts, it must be known to their networking kernels. Sources of real-time information flows are already describing characteristics of these flows to their kernels and to the routers in the form of TSpecs in RSVP PATH messages [4]. Since these messages make use of the router alert option, they are seen by all routers on the path; path state about the packet stream is normally installed at each of these routers that implement RSVP. Additional RSVP objects could be defined that are included in PATH messages by those applications that desire good performance over low-bitrate links; these objects would be coded to be ignored by routers that are not interested in them (class number 11bbbbbb as defined in [4], section 3.10).
これらのシステムがルーターである場合、この同意はルーター状態としてインストールする必要があります。これらのシステムがホストである場合、ネットワークカーネルに知られている必要があります。リアルタイムの情報フローのソースは、RSVPパスメッセージのTSPECの形で、これらのフローの特性を既に説明しています[4]。これらのメッセージはルーターアラートオプションを使用しているため、パス上のすべてのルーターに表示されます。パケットストリームに関するPATH状態は、通常、RSVPを実装するこれらの各ルーターにインストールされます。低ビトレートリンクよりも優れたパフォーマンスを望むアプリケーションによってパスメッセージに含まれる追加のRSVPオブジェクトを定義できます。これらのオブジェクトは、それらに興味のないルーターによって無視されるようにコード化されます（クラス番号11BBBBBB [4]、セクション3.10で定義されています）。
Note that the path state is available in the routers even when no reservation is made; this allows informed compression of best-effort traffic. It is not quite clear, though, how path state could be torn down quickly when a source ceases to transmit.
予約が行われない場合でも、パス状態はルーターで利用可能であることに注意してください。これにより、ベストエフォルトトラフィックの情報に基づいた圧縮が可能になります。しかし、ソースが送信をやめたときにどのようにパス状態をすぐに引き裂くことができるかは明確ではありません。
The IP header compression specification attempts to account for simplex and multicast links by providing information about the compressed streams only in the forward direction. E.g., a full IP/UDP header must be sent after F_MAX_TIME (currently 3 seconds), which is a negligible total overhead (e.g. one full header every 150 G.723.1 packets), but must be considered carefully in scheduling the real-time transmissions. Both simplex and multicast links are not prevailing in the low-bitrate environment (although multicast functionality may become more important with wireless systems); in this document, we therefore assume full-duplex capability.
IPヘッダー圧縮仕様は、圧縮されたストリームに関する情報を前方向にのみ提供することにより、シンプレックスおよびマルチキャストリンクを説明しようとします。たとえば、F_MAX_TIME（現在3秒）後に完全なIP/UDPヘッダーを送信する必要があります。これはごくわずかなオーバーヘッド（たとえば150 G.723.1パケットごとに1つのフルヘッダー）ですが、リアルタイムの送信のスケジュールで慎重に考慮する必要があります。。シンプレックスリンクとマルチキャストの両方のリンクは、低ビトル酸塩環境では一般的ではありません（ただし、ワイヤレスシステムではマルチキャスト機能がより重要になる可能性があります）。したがって、このドキュメントでは、全二重機能を想定しています。
As compression techniques will improve, a negotiation between the two peers on the link would provide the best flexibility in implementation complexity and potential for extensibility. The peer routers/hosts can decide which real-time packet streams are to be compressed, which header fields are not to be sent at all, which multiplexing information should be used on the link, and how the remaining header fields should be encoded. PPP, a well-tried suite of negotiation protocols, is already used on most of the low-bitrate links and seems to provide the obvious approach. Cooperation from PPP is also needed to negotiate the use of real-time encapsulations between systems that are not configured to automatically do so. Therefore, PPP options that can be negotiated at the link setup (LCP) phase are included in [8], [9], and [10].
圧縮技術が改善するにつれて、リンク上の2人のピア間の交渉は、実装の複雑さと拡張性の可能性に最適な柔軟性を提供します。ピアルーター/ホストは、どのリアルタイムパケットストリームを圧縮するかを決定できます。ヘッダーフィールドはまったく送信されません。リンクで使用するマルチプレックス情報、および残りのヘッダーフィールドをエンコードする方法を決定できます。よく訓練された交渉プロトコルのスイートであるPPPは、ほとんどの低ビトレートリンクですでに使用されており、明らかなアプローチを提供しているようです。PPPからの協力は、自動的にそうするように構成されていないシステム間のリアルタイムカプセルの使用を交渉するためにも必要です。したがって、リンクセットアップ（LCP）フェーズでネゴシエートできるPPPオプションは、[8]、[9]、および[10]に含まれています。
Header compression protocols that make use of assumptions about application protocols need to be carefully analyzed whether it is possible to subvert other applications by maliciously or inadvertently enabling their use.
アプリケーションプロトコルに関する仮定を使用するヘッダー圧縮プロトコルは、悪意を持って使用できるか不注意に他のアプリケーションを破壊できるかどうかにかかわらず、慎重に分析する必要があります。
It is generally not possible to do significant hop-by-hop header compression on encrypted streams. With certain security policies, it may be possible to run an encrypted tunnel to a network access server that does header compression on the decapsulated packets and sends them over an encrypted link encapsulation; see also the short mention of interactions between real-time encapsulation and encryption in section 4 above. If the security requirements permit, a special RTP payload data format that encrypts only the data may preferably be used.
一般に、暗号化されたストリームで重要なホップバイホップヘッダー圧縮を行うことはできません。特定のセキュリティポリシーを使用すると、暗号化されたトンネルをネットワークアクセスサーバーに実行し、脱カプセル化パケットにヘッダー圧縮を行い、暗号化されたリンクカプセル化を介して送信することができます。上記のセクション4のリアルタイムカプセル化と暗号化との相互作用の短い言及も参照してください。セキュリティ要件が許可されている場合、データのみを暗号化する特別なRTPペイロードデータ形式が望ましい場合があります。
[1] Handley, M., Crowcroft, J., Bormann, C. and J. Ott, "The Internet Multimedia Conferencing Architecture", Work in Progress.
[1] Handley、M.、Crowcroft、J.、Bormann、C。、およびJ. Ott、「インターネットマルチメディア会議アーキテクチャ」、進行中の作業。
[2] Degermark, M., Nordgren, B. and S. Pink, "IP Header Compression", RFC 2507, February 1999.
[2] Degermark、M.、Nordgren、B。およびS. Pink、「IPヘッダー圧縮」、RFC 2507、1999年2月。
[3] Scott Petrack, Ed Ellesson, "Framework for C/RTP: Compressed RTP Using Adaptive Differential Header Compression", contribution to the mailing list rem-conf@es.net, February 1996.
[3] Scott Petrack、Ed Ellesson、「C/RTPのフレームワーク：適応微分ヘッダー圧縮を使用した圧縮RTP」、メーリングリストremconf@es.net、1996年2月への貢献。
[4] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[4] Braden、R.、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「リソース予約プロトコル（RSVP） - バージョン1機能仕様」、RFC 2205、1997年9月。
[5] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T. Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, August 1996.
[5] Sklower、K.、Lloyd、B.、McGregor、G.、Carr、D。、およびT. Coradetti、「The PPP Multilink Protocol（MP）」、RFC 1990、1996年8月。
[6] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.
[6] Schulzrinne、H.、Casner、S.、Frederick、R。and V. Jacobson、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、RFC 1889、1996年1月。
[7] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999.
[7] Casner、S。およびV. Jacobson、「低速シリアルリンク用のIP/UDP/RTPヘッダーの圧縮」、RFC 2508、1999年2月。
[8] Bormann, C., "The Multi-Class Extension to Multi-Link PPP", RFC 2686, September 1999.
[8] Bormann、C。、「マルチリンクPPPへのマルチクラス拡張」、RFC 2686、1999年9月。
[9] Bormann, C., "PPP in a Real-time Oriented HDLC-like Framing", RFC 2687, September 1999.
[9] Bormann、C。、「リアルタイム指向のHDLCのようなフレーミングのPPP」、RFC 2687、1999年9月。
[10] Engan, M., Casner, S. and C. Bormann, "IP Header Compression over PPP", RFC 2509, February 1999.
[10] Engan、M.、Casner、S。、およびC. Bormann、「PPP上のIPヘッダー圧縮」、RFC 2509、1999年2月。
[11] Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC 2211, September 1997.
[11] Wroclawski、J。、「制御されたロードネットワーク要素サービスの仕様」、RFC 2211、1997年9月。
[12] Shenker, S., Partridge, C. and R. Guerin. "Specification of Guaranteed Quality of Service", RFC 2212, September 1997.
[12] Shenker、S.、Partridge、C。およびR. Guerin。「保証されたサービス品質の仕様」、RFC 2212、1997年9月。
[13] ITU-T Recommendation H.223, "Multiplexing protocol for low bit rate multimedia communication", International Telecommunication Union, Telecommunication Standardization Sector (ITU-T), March 1996.
[13] ITU-Tの推奨H.223、「低ビットレートマルチメディア通信用の多重化プロトコル」、国際電気通信ユニオン、電気通信標準化セクター（ITU-T）、1996年3月。
[14] ITU-T Recommendation H.324, "Terminal for low bit rate multimedia communication", International Telecommunication Union, Telecommunication Standardization Sector (ITU-T), March 1996.
[14] ITU-Tの推奨H.324、「低ビットレートマルチメディア通信の端末」、国際電気通信ユニオン、電気通信標準化セクター（ITU-T）、1996年3月。
[15] ITU-T Recommendation H.245, "Control protocol for multimedia communication", International Telecommunication Union, Telecommunication Standardization Sector (ITU-T), March 1996.
[15] ITU-Tの推奨H.245、「マルチメディアコミュニケーションのための制御プロトコル」、国際電気通信ユニオン、電気通信標準化セクター（ITU-T）、1996年3月。
Carsten Bormann Universitaet Bremen FB3 TZI Postfach 330440 D-28334 Bremen, GERMANY
Carsten Bormann Universitaet Bremen FB3 TZI POSTFACH 330440 D-28334ブレーメン、ドイツ
Phone: +49.421.218-7024
Fax: +49.421.218-7000
EMail: cabo@tzi.org
Acknowledgements
謝辞
Much of the early discussion that led to this document was done with Scott Petrack and Cary Fitzgerald. Steve Casner, Mikael Degermark, Steve Jackowski, Dave Oran, the other members of the ISSLL subgroup on low bitrate links (ISSLOW), and in particular the ISSLL WG co-chairs Eric Crawley and John Wroclawski have helped in making this architecture a reality.
この文書につながった初期の議論の多くは、スコット・ペトラックとキャリー・フィッツジェラルドで行われました。スティーブ・キャスナー、ミカエル・デジャーマーク、スティーブ・ジャコウスキー、デイブ・オラン、低ビットレートリンク（ISSLOW）のISSLLサブグループの他のメンバー、特にISSLL WG共同議長のエリッククローリーとジョンロクラウスキーは、この建築を現実にするのに役立ちました。
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（1999）。無断転載を禁じます。
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.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
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エディター機能の資金は現在、インターネット協会によって提供されています。