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.
著作権（C）インターネット協会（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チャネル、サブ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キロビット/秒のモデム、56および64キロビット/秒ISDNのBチャンネルを転送パス上で使用されていない（または非常に非効率的に）可能性が、あるいはサブT1リンク。これらのリンク上で使用されるカプセル化形式は、任意のデータと厳しい遅延要件を満たさなければならないリアルタイム情報を同時に輸送には適していません。 28.8キロビット/秒のモデムリンク上の1500バイトのパケットの送信は約400ミリ秒のリアルタイム情報の伝送のため、このリンクが使用できなくなります。リアルタイムの会話のために許容できない - これは、少なくとも第二のオーダーの往復遅延で動作するリアルタイムアプリケーションを引き起こし、最悪の場合の遅延が追加されます。加えて、使用されるプロトコルスタックと関連するヘッダオーバヘッドは、リアルタイム情報パケット当たり数十バイトまで圧縮がしばしば望ましい低ビットレートのリンクに法外です。例えば、少なくとも44（+ 20 + 12 + 8 4）のオーバーヘッドが完全にそのようなG.723.1 ACELP音声フレームのために必要19.75バイトのような典型的なオーディオペイロードを曇らせるHDLC / PPP、IP、UDP、及びRTPのバイト - 14.4キロビット/秒のリンクが完全に第2の全あたり40リアルタイムフレームにのみ、このヘッダのオーバーヘッドによって消費される（すなわち、まだ、データのために残された空間を有する一つのストリーム又は二つの流れのために50ミリ秒、25ミリ秒のパケット化遅延、で） 。ヘッダーオーバーヘッドが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優先順位フィールドを使用）。好ましくは、1つは、特別な治療、すなわち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).
ヘッダ圧縮は、要素の様々なプロトコルアーキテクチャのレベルの多様で行うことができます。パソコン船アプリケーションのためのインターネットテレフォニー製品のような多くのベンダーが、それらに最も明らかであるアプローチは、（または実際に非標準を使用して、すなわちUDPなどのトランスポートプロトコルの上に、アプリケーションレベルでヘッダ圧縮を行うことにより、オーバーヘッドを低減することです効率的に）最初にヘッダを符号化されました。
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ヘッダ圧縮の設計原理の一つは、それが層下部層（外側）ヘッダ内の情報から推測することができないの意味で停止することです。したがって、単独でこのヘッダ圧縮技術は、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バイトの倍数でなければならない）パスMTU探索では、IPレベルの断片化は、小のMSSを使用するTCPの実装を引き起こします断片あたり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.
これらの（および他の）機能を有する一リアルタイムカプセル化フォーマットは、ITU-T H.223 [13]、H.324モデムベースのテレビ電話規格によって使用される多重[14]に記載されています。互換性は、将来のテレビ電話対応（H.324可能）モデムで使用される本明細書で達成することができるかどうかを調べました。 H.223の多重化能力は、一般的なインターネット利用のための15のスケジュール（多重ヘッダで識別することができるパケットタイプの配列の定義）が、これらに限定されるので、スーパーセット、またはより一般的なカプセル化が必要とされたであろう。また、PPP形式のネゴシエーションプロトコルを使用して（必ずしも延びる）多重のパラメータを設定するためのITU-T H.245 [15]の代わりに必要でした。 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リアルタイムフレーミング実装が知られているいくつかに送信される各バイトの送信を制御することができる、（原因のFIFOに例えば、）遅延を有界。例えば、これは、直接バイトによって、または非常に小さな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、PPPリアルタイムフレーミング実装と伝送ハードウェアとの間のインタフェースは、バイトのストリームの観点からではなく、複数の形態のフレーム、例えば、換算で（優先順位）を直接キューを送りますハードウェアでサポートされています。これは特に、低ビットレート多数のリンクをサポートするために持っているもの同期リンクのためのルータシステムの多くの場合、真実です。それは、伝送のために受け継がれてきた後、タイプ2の送信者は、フレームを一時停止する方法がありませんので、それらは一般的に、キュー・オブ・フラグメント近づき、長いパケットは常にアクセス遅延目標を維持するのに十分に小さい単位に分割されて使用されます優先度の高いトラフィック用。大フラグメントサイズと小さなフラグメントサイズを選択することによって、すべての長いパケットのために発生されるオーバーヘッドから生じるアクセス遅延の変化との間のトレードオフがあります。
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受信機はPPPフレーム内のバイトの流れを完全に制御を受けた受信機タイプ1タイプは、（いくつかの知られていると、例えばによる等のFIFOに遅延を境界）直ちにPPPリアルタイムフレーミング実装に利用可能です。
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型受信機、PPPリアルタイムフレーミング実装とレシーバタイプ2は、フレームのホールドを取得し、即ち、最終フラグが（典型的には、直接メモリ・バッファを満たすいくつかの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.
一つは、PPPマルチリンクプロトコルへのマルチクラス拡張、キュー・オブ・断片的なアプローチのためのソリューションを提供している。現在の実装の機能の多様性の結果として、そこにリアルタイムのカプセル化のための2つの仕様は今あります複数のクラスによって単一ストリームPPPマルチリンクプロトコルを拡張することによって、[8]。本明細書の末尾がサスペンド/レジューム型アプローチのためのソリューションを提供し、[9]動的1つのHDLCフレーム内で複数のフラグメントを区切るための方法によってそれを拡張上の他のカプセル化、リアルタイム指向のHDLCのようなフレーミングにおけるPPPは、ビルド。
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.)
ヘッダ圧縮に関する議論のための良好なベースラインは、IPv6 [2]の開発に関連して設計された新しいIPヘッダ圧縮仕様です。技術は、約6バイト（同時ストリームの数に応じて）へのIPv4 / UDPヘッダの28のバイトが低減することができる使用しました。 RTPの残りのHDLC / PPPオーバーヘッドの4バイトと12バイトの総ヘッダーオーバーヘッドは約半分が、それでもG.723.1のACELPフレームのサイズを超えることができます。 IPヘッダ圧縮とは対照的に、ここで説明する環境は、全二重PPPリンクの存在を前提とし、従って、IPヘッダー圧縮は、同じ情報の繰り返し送信を必要とする場合、ネゴシエーションに頼ることができることに留意されたいです。 （リンク層マルチキャスト有する本文書のアーキテクチャを使用することは未だ検討されていません。）
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).
追加の設計作業は、RTPヘッダー圧縮のために必要でした。 RTPヘッダ内の12バイト、7バイト（タイムスタンプ、シーケンス、およびマーカービット）RANDOMとして適格であろう（少なくとも）のIPヘッダ圧縮の概念を適用します。下位レイヤヘッダが明確セマンティクスを識別しないと誤っ減圧を検出するために信頼することができない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パケットのシーケンス番号とタイムスタンプの差分符号化は、ペイロード・データ・フォーマットの特定の場合のための効率的なアプローチです。例えば、音声フローは、一般的に、配列番号1によって、およびタイムスタンプ単位でフレームサイズ、RESP増加タイムスタンプフィールドを持っています; 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).
これらのシステムはルータである場合は、この同意は、ルータの状態としてインストールする必要があります。これらのシステムは、ホストされている場合、それは彼らのネットワークカーネルに知らなければなりません。リアルタイムの情報フローのソースは、すでにカーネルおよび[4]のRSVP PATHメッセージ内のTSpecの形態におけるルータにこれらのフローの特性を記述しています。これらのメッセージは、ルータアラートオプションを利用するので、パス上のすべてのルータによって見られています。パケットストリームについての経路状態は、通常、RSVPを実装し、これらのルータのそれぞれに設置されています。追加のRSVPオブジェクトは、低ビットレートリンク上で良好なパフォーマンスを望むそれらのアプリケーションがPATHメッセージに含まれているように定義することができ、これらのオブジェクトは、（[4]、セクション3.10で定義されたクラス数11bbbbbb）それらに興味がないルータによって無視されるように符号化されるであろう。
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ヘッダ圧縮仕様は、順方向に圧縮されたストリームについての情報を提供することによって、シンプレックスおよびマルチキャストリンクを考慮しよう。例えば、完全なIP / UDPヘッダは無視合計オーバーヘッド（例えば、1つの完全なヘッダーごとに150のG.723.1パケット）ですが、リアルタイム伝送をスケジューリングするには、慎重に検討しなければならないF_MAX_TIME（現在は3秒）、後に送信されなければなりません。 （マルチキャスト機能は、無線システムでより重要になるかもしれないが）どちらも単体およびマルチキャストのリンクは、低ビットレートの環境で普及していません。この文書では、我々はそのための全二重機能を前提としています。
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.
[2] Degermark, M., Nordgren, B. and S. Pink, "IP Header Compression", RFC 2507, February 1999.
[2] Degermark、M.、Nordgren、B.とS.ピンク、 "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]スコット・2000 Petrackと、エドEllesson、 "C / RTPのためのフレームワーク：適応差分ヘッダ圧縮を使用して圧縮RTP"、メーリングリストrem-conf@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]ブレーデン、R.、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（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.、ロイド、B.、マクレガー、G.、カー、D.およびT. Coradetti、 "PPPマルチリンクプロトコル（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.、フレデリック、R.と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.ヤコブソンを、RFC 2508、1999年2月 "低速シリアルリンクのIP / UDP / RTPヘッダの圧縮"。
[8] Bormann, C., "The Multi-Class Extension to Multi-Link PPP", RFC 2686, September 1999.
[8]ボルマン、C.、RFC 2686 "マルチリンクPPPへのマルチクラス拡張"、1999年9月を。
[9] Bormann, C., "PPP in a Real-time Oriented HDLC-like Framing", RFC 2687, September 1999.
[9]ボルマン、C.、 "リアルタイムでのPPP指向HDLCのようなフレーミング"、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.ボルマン、 "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.、ヤマウズラ、C.およびR.ゲラン。 「保証されたサービスの質の仕様」、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
カールステンボルマンUniversitaetブレーメンTZI FB3 POSTFACH 330440 D-28334ブレーメン、ドイツ
Phone: +49.421.218-7024 Fax: +49.421.218-7000 EMail: cabo@tzi.org
電話：+ 49.421.218-7024ファックス：+ 49.421.218-7000 Eメール：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.
このドキュメントにつながった初期の議論の多くは、スコット・2000 Petrackとし、ケーリーフィッツジェラルドで行われました。スティーブCasner、ミカエルDegermark、スティーブJackowski、デイブ・オラン、ISSLLサブグループの他のメンバーの低ビットレートのリンク（ISSLOW）上、特にISSLL WGの共同議長エリッククローリーとジョンWroclawskiは、このアーキテクチャを現実のもの作りに役立っています。
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。