RFC2689 日本語訳
2689 Providing Integrated Services over Low-bitrate Links. C. Bormann. September 1999. (Format: TXT=34345 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group C. Bormann Request for Comments: 2689 Universitaet Bremen TZI Category: Informational September 1999
コメントを求めるワーキンググループC.ボルマンの要求をネットワークでつないでください: 2689年のUniversitaetブレーメンTZIカテゴリ: 情報の1999年9月
Providing Integrated Services over Low-bitrate Links
低いbitrateリンクの上に統合サービスを供給します。
Status of this Memo
この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)インターネット協会(1999)。 All rights reserved。
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などの低いbitrateリンクの上の統合サービスにリンクを提供するために構造について説明します。 それはインターネットMultimedia Conferencing Architecture[1]の下部だけを覆っています。 このドキュメントの範囲の外にインターネットTelephony(例えば、セッション開始プロトコル)などのアプリケーション・サービスに必要である追加コンポーネントがあります。 構造の主な成分は以下の通りです。 非同期で同期の低いbitrateリンクのためのリアルタイムのカプセル化形式、ヘッダー圧縮構造は本当の時間流れ、ルータ(またはホストとルータの間で)の間で使用される、交渉プロトコルの原理、およびこの交渉が行われるのを許容するのにアプリケーションで使用される発表プロトコルのために最適化されました。
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. 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])。
Bormann Informational [Page 1] RFC 2689 Integrated Services over Low-bitrate Links September 1999
安値-bitrateの上の統合サービスリンクスボルマン情報[1ページ]のRFC2689 1999年9月
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.
インターネットMultimedia Conferencing Architecture[1]のネットワークと輸送レベルにおけるこれらの要素に加えて、さらなるコンポーネントはセッション開始とコントロールのためにインターネットTelephonyなどのアプリケーション・サービス、例えばプロトコルを定義しなければなりません。 このドキュメントの範囲の外にこれらのコンポーネントがあります。
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、および64kbit/s ISDN Bチャネルなどの低いbitrateリンク、またはサブT1リンクさえ含んでいる推進経路の上で新たに開発されたサービスは利用できませんでした(非常に効率悪いだけ)。 厳しい遅れ必要条件を満たさなければならない任意のデータとリアルタイムの情報の同時の輸送には、これらのリンクの上に使用されるカプセル化形式は適切ではありません。 28.8kbit/sモデムリンクにおける1500年のバイトのパケットのトランスミッションで、このリンクは原稿Thisが、最悪の場合が遅らせると言い足すおよそ400のためのリアルタイムのアプリケーションが少なくとも1秒の注文での往復の遅れで作動するリアルタイムの情報の伝達を入手できなくなります--リアルタイムの会話において、容認できません。 圧縮がダウンするところでいくつかに、リアルタイムの情報パケットあたり12バイトはしばしばさらに、使用されるプロトコル・スタックに関連しているヘッダーオーバーヘッドが低いbitrateリンクでひどく高いのが望ましいです。 例えば、HDLC/PPP、IP、UDP、およびRTPのための少なくとも44(4+20+8+12)バイトのオーバーヘッドはG.723.1 ACELPオーディオフレームに必要である19.75バイトなどの典型的なオーディオペイロードを完全に曇らせます--14.4kbit/sリンクは2番目の合計(すなわち、1つの流れのための25ms packetization遅れかデータまで残っているスペースのない2つの流れのための50msでまだ)あたり40個のリアルタイムのフレームでこのヘッダーオーバーヘッドで単独で完全に消費されます。 いくつかのリアルタイムの情報フレームを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,
- 非同期で同期の低いbitrateのためのリアルタイムのカプセル化形式はリンクされます。
- 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.
- この交渉が行われるのを許容するのにアプリケーションで使用される発表プロトコル。
Bormann Informational [Page 2] RFC 2689 Integrated Services over Low-bitrate Links September 1999
安値-bitrateの上の統合サービスリンクスボルマン情報[2ページ]のRFC2689 1999年9月
2. Design Considerations
2. デザイン問題
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.
低いbitrateリンクの上のリアルタイムのマルチメディア流れを記述する構造の主なデザイン目標は終わりから終わりへの遅れを最小にするものです。 より明確に、最悪の場合遅れ(アプリケーション観点からのパケット損失に同等な可能なアウトライアーを取り除いた後の)はアプリケーションで選択された再生ポイントとその結果実際にユーザによって知覚された遅れを決定することです。
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.
統合サービス構造の重要な成分はリアルタイムの流れの予約の支給です。 そのような予約のための入場コントロールを実行するとき低いbitrateリンク(ルータかホスト)の上のシステムが直面している問題の1つは予約で実際にリンクで消費されたものに要求された帯域幅を翻訳しなければならないということです。 データ圧縮、そして/または、ヘッダー圧縮などの方法はリンクに関する要件を減らすことができますが、それにデータ・ストリームの圧縮がどれくらい効果的になるかを知ることができるくらいの情報がある場合にだけ、入場コントロールは計算で減少している要件を利用できます。 構造の1つの目標はしたがって、この情報と共に入場コントロールを統合サービスに提供することです。 有益な副作用で、システムはこの情報なしで可能であるだろうより良い圧縮を実行することになっていることができるかもしれません。 これで、いつリアルタイムの流れの予約をすることを意図しないかというこの情報を提供するのは価値があるようになるかもしれません。
3. The Need for a Concerted Approach
3. 協調したアプローチの必要性
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.
多くの技術的なアプローチが、遅れとオーバーヘッドを記述するヘッダー圧縮方法を記述するためにこれらの問題、特に新しいフォームの低い遅れカプセル化を記述するために思い浮かびます。 このセクションは、これらのテクニックが問題を解決するために結合されるべきであるのを示します。
3.1. Real-Time Encapsulation
3.1. リアルタイムのカプセル化
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.
リアルタイムのリンクレイヤカプセル化プロトコルを定義する目的は現在伝えられた(ことによると大きい)パケットが終わるのを待つ必要はなくて新たに到着したリアルタイムのパケットをリンクレイヤデータ・ストリームに取り入れることであることができます。 明らかに、この層でリンクの上の大きいフレームによって引き起こされた遅れの問題を解決できるだけであるので、リアルタイムのカプセル化はどんな完全解の一部であるに違いありません。
Bormann Informational [Page 3] RFC 2689 Integrated Services over Low-bitrate Links September 1999
安値-bitrateの上の統合サービスリンクスボルマン情報[3ページ]のRFC2689 1999年9月
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の組み合わせによる低いbitrateリンクを絶対に適切に作動させることができません、すなわち、彼らはヘッダー圧縮を絶対に必要とします。
3.2. Header Compression
3.2. ヘッダー圧縮
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).
さまざまな要素とプロトコル構造のさまざまなレベルにおいてヘッダー圧縮を実行できます。 PCのためのインターネットTelephony製品の多くの業者がアプリケーションを出荷するのに従って、それらに、最も明白な進入路はアプリケーションレベルでヘッダー圧縮を実行することによって、経費を削減することになっています、すなわち、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.
一般に、ヘッダー圧縮は、犠牲者が送信側に省略された情報を再建できる経路の両端に状態をインストールすることによって、作動します。 ヘッダー圧縮のための多くの良いテクニック、(RFC1144、[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,
RTPが流れるのでアプリケーションの非常に良いレベルヘッダー圧縮溶液がRTPヘッダー[3]の12バイトのうちの11を救うことができるかもしれないと仮定してください。 この完全な解決さえ総ヘッダーオーバーヘッドを1/4下げるだけです。 それはすべてのアプリケーションで配備されなければならないでしょう。
Bormann Informational [Page 4] RFC 2689 Integrated Services over Low-bitrate Links September 1999
安値-bitrateの上の統合サービスリンクスボルマン情報[4ページ]のRFC2689 1999年9月
even those that operate on systems that are attached to higher- bitrate links.
より高いbitrateリンクに取り付けられるシステムを作動させるものさえ。
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ヘッダーオーバーヘッドを1パケットあたり2バイトまで下げることができます。 この技術はボトルネックリンクで配備されるだけでよいです。 高速リンクは、ヘッダー圧縮を実行するためにCPUサイクルを費やしながら、ルータもスイッチなしでリアルタイムの流れを移すことができます。
4. Principles of Real-Time Encapsulation for Low-Bitrate Links
4. 低いBitrateリンクへのリアルタイムのカプセル化のプリンシプルズ
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.
リアルタイムのカプセル化の主なデザイン目標は長いデータ・パケットを送る間、発信するのに利用可能になるリアルタイムのパケットによって被られた遅れを最小にすることです。 これを達成するために、カプセル化は、長いデータ・パケットの転送を中止にならなければならないか、または中断させることができなければなりません。 追加目標がパケットのトランスミッションに周期的な流れから必要であるオーバーヘッドを最小にすることであるので、これはパケット、すなわち、セグメントを中断させることができる存在のために強くリアルタイムのパケットを移すことができる部品にそれについて論争します。
Bormann Informational [Page 5] RFC 2689 Integrated Services over Low-bitrate Links September 1999
安値-bitrateの上の統合サービスリンクスボルマン情報[5ページ]のRFC2689 1999年9月
4.1. Using existing IP fragmentation
4.1. 既存のIP断片化を使用します。
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」実現で、単に小さいMTUをIPスタックに示して、その結果、すべての、より大きいデータグラムをアクセス遅延目標が達成されるのを許容するサイズまで断片化するかもしれません(これは、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の平らな断片化で、TCP実現は小さいMSSsを使用します--これはさらに1パケットあたりのオーバーヘッドを1断片あたり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の平らな断片化は間に合せのメカニズムであるかもしれません。
4.2. Link-Layer Mechanisms
4.2. リンクレイヤメカニズム
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.
低いbitrateリンクには、異なったパケットからのセルを補間できる正則点を紹介するATMなどのセル指向のマルチプレクシングのテクニックは効率が悪過ぎます。 また、それらは低いbitrateルータでリンクレイヤを支えるのに使用されるチップとホスト・インターフェースによって支持されません。
Bormann Informational [Page 6] RFC 2689 Integrated Services over Low-bitrate Links September 1999
安値-bitrateの上の統合サービスリンクスボルマン情報[6ページ]のRFC2689 1999年9月
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のスケジュール(マルチプレックスヘッダーで特定できるパケットタイプの系列の定義)に制限されるので、一般的なインターネット用法には、しかしながら、スーパーセットか、より一般的なカプセル化が必要だったでしょう。 また、マルチプレックスのパラメタを設定するのにITU-T H.245[15]を使用すること(必ず広がっていて)の代わりにPPP-スタイル交渉プロトコルが必要でした。 PPP文脈では、データ圧縮とリンクレイヤ暗号化のためのカプセル化との相互作用は、定義される必要がありました(詰め物があるとき操作を含んでいて)。 しかし、すべてのチップが商業的に利用可能なルータで配備されている状態で、どれが最も重要です、H.223が付属CRCなしでフレームを送信するために構成できる同期HDLCチップを必要とするのが可能でないか。 それで、完全な両立性は「非-達成可能」でした。
Bormann Informational [Page 7] RFC 2689 Integrated Services over Low-bitrate Links September 1999
安値-bitrateの上の統合サービスリンクスボルマン情報[7ページ]のRFC2689 1999年9月
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)実現との互換性に向かって適応するアプローチを追求するために決められました。 彼らの能力に従って、次の小区分はこれらの実現を分類します。
4.3. Implementation models
4.3. 実現モデル
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.
このセクションは現れそうな実現のタイプの項数を導入します。 すべてのモデルに最もよく合うどんなただ一つのアプローチもないとき、これらの異なった実現モデルを考えているのは重要です。
4.3.1. Sender types
4.3.1. 送付者はタイプします。
There are two fundamental approaches to real-time transmission on low-bitrate links:
低いbitrateリンクの上にリアルタイムのトランスミッションへの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.
送付者は知られていた状態でPPPのリアルタイムの縁どり実現が伝えられるそれぞれのバイトの送信をいくつか制御できる1をタイプします、境界がある遅れ(例えば、先入れ先出し法のため)。 例えば、一般に、これがPCホスト導入に関して本当である、どれが直接シリアルインタフェースにアクセスするかがバイトか非常に小さい先入れ先出し法をいっぱいにすることによって、バイトを欠きます。 送付者、aは、タイプ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.
送付者タイプ2Withは2人の送付者をタイプして、フレームに関してPPPのリアルタイムの縁どり実現とトランスミッションハードウェアとのインタフェースがバイトの流れに関してあるのではなく、あります、例えば、直接ハードウェア的に支持された複数の(最優先します)送信キューの形で。 これはしばしば同期リンク(特に多くの低いbitrateリンクを支えなければならないもの)のルータシステムに関して本当です。 2人の送付者がそれがいったん手渡されるとフレームを吊すどんな方法にもトランスミッションのために倒させないタイプとして、彼らは断片の待ち行列アプローチを通常使用するでしょう、長いパケットがいつもより高い優先度交通のアクセス遅延目標を維持できるくらい小さい単位に分けられるところで。 大きい断片サイズから生じるアクセス遅延の変化とあらゆる長いパケットのために小さい破片サイズを選ぶことによって被られるオーバーヘッドの間には、トレードオフがあります。
Bormann Informational [Page 8] RFC 2689 Integrated Services over Low-bitrate Links September 1999
安値-bitrateの上の統合サービスリンクスボルマン情報[8ページ]のRFC2689 1999年9月
4.3.2. Receiver types
4.3.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.).
受信機タイプ1Type1受信機には、PPPフレームの中に受け取られたバイトの流れの完全なコントロールがあります、すなわち、受け取られたバイトはすぐ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).
受信機タイプ2Withは2台の受信機をタイプします、それを完全に受け取ったときだけ、PPPのリアルタイムの縁どり実現がフレームをつかみます、すなわち、最終的な旗が処理されました(通常直接メモリ・バッファをいっぱいにするあるHDLCチップで)。
4.4. Conclusion
4.4. 結論
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マルチリンクプロトコルへのマルチのクラス拡大)は、複数のクラス[8]でただ一つの流れのPPPマルチリンクプロトコルを広げることによって、断片の待ち行列アプローチの解決法を提供しています。 もう片方のカプセル化、リアルタイムの指向のHDLCのような縁どり、この仕様終わりの体格におけるPPPがHDLCが解決法を提供する[9]を縁どる1の中でダイナミックに複数の断片を区切る方法でそれを広げている、タイプアプローチを中断するか、または再開してください。
5. Principles of Header Compression for Real-Time Flows
5. リアルタイムのためのヘッダー圧縮のプリンシプルズは流れます。
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ヘッダー圧縮仕様にあります。 そこで使用されたテクニックは28バイトのIPv4/UDPヘッダーをおよそ6バイトまで減少させることができます(同時発生の流れの数によって)。 RTPのための残っている4バイトのHDLC/PPPオーバーヘッドと12バイトによると、総ヘッダーオーバーヘッドは、半分にされるのに関してあることができますが、まだG.723.1 ACELPフレームのサイズを超えています。 ここで議論した環境がIPヘッダー圧縮と対照して全二重PPPリンクの存在を仮定して、IPヘッダー圧縮が同じ情報の繰り返された伝達を必要とするところでその結果、交渉に依存できることに注意してください。 (リンクレイヤマルチキャスティングがある現在のドキュメントの構造の使用はまだ調べられていません。)
Bormann Informational [Page 9] RFC 2689 Integrated Services over Low-bitrate Links September 1999
安値-bitrateの上の統合サービスリンクスボルマン情報[9ページ]のRFC2689 1999年9月
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ヘッダーでIPヘッダー圧縮、(少なくとも)12バイトの概念を適用して、7バイト(タイムスタンプ、系列、およびマーカービット)はRANDOMの資格を得るでしょう。 下層ヘッダーが明白に意味論を特定しないで、また不正確な減圧を検出するために当てにすることができるTCPチェックサムが全くないので、一般に、詳細なしでデルタのコード化を使用できません。 より意味論指向のアプローチだけが、より良い圧縮を提供できます(ちょうどTCPの意味知識を利用して、方法をchecksummingすることによってRFC1144が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]であるときにだけこれらの分野をコード化することによって、この関係を利用します。
6. Announcement Protocols Used by Applications
6. アプリケーションで使用される発表プロトコル
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 PATHメッセージ[4]のTSpecsの形で既にそれらのカーネルと、そして、ルータへのこれらの流れの特性について説明しています。 これらのメッセージがルータ警戒オプションを利用するので、それらは経路のすべてのルータによって見られます。 通常、パケットの流れに関する経路州はRSVPを実行するそれぞれのこれらのルータにインストールされます。 PATHメッセージに低いbitrateリンクの上の望ましい市場成果を望んでいるそれらのアプリケーションで含まれている追加RSVP物は定義できました。 これらの物は、それら([4]で定義されるクラス番号11bbbbbb、セクション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.
予約を全くしてさえいないとき、経路州がルータで利用可能であることに注意してください。 これはベストエフォート型交通の知識がある要約を許します。 もっとも、ソースが、いつ伝わるのをやめるかは、どうしたらすばやく経路州を取りこわすことができたかが全く明確であるというわけではありません。
Bormann Informational [Page 10] RFC 2689 Integrated Services over Low-bitrate Links September 1999
安値-bitrateの上の統合サービスリンクスボルマン情報[10ページ]のRFC2689 1999年9月
7. Elements of Hop-By-Hop Negotiation Protocols
7. ホップごとの交渉プロトコルのElements
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の_マックス_タイム誌(現在の3秒)に送らなければなりませんが、リアルタイムのトランスミッションの計画をする際に慎重に考えなければなりません。(タイム誌は、取るにたらない合計です)。 シンプレクスとマルチキャストリンクの両方が低いbitrate環境で行き渡っていません(マルチキャストの機能性はワイヤレスシステムによって、より重要になるかもしれませんが)。 したがって、本書では、私たちは全二重能力を仮定します。
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(交渉プロトコルのよく吟味されているスイート)は、低いbitrateリンクの大部分で既に使用されて、明白なアプローチを提供するように思えます。 また、PPPからの協力が、自動的にそうするために構成されないシステムの間のリアルタイムのカプセル化の使用を交渉するのに必要です。 したがって、リンクセットアップ(LCP)フェーズで交渉できるPPPオプションは[8]、[9]、および[10]に含まれています。
8. Security Considerations
8. セキュリティ問題
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.
一般に、コード化された流れのときにホップごとの重要なヘッダー圧縮をするのは可能ではありません。ある安全保障政策で、コード化されたトンネルをdecapsulatedパケットでヘッダー圧縮をして、コード化されたリンクカプセル化の上にそれらを送るネットワークアクセス・サーバーに動かすのは可能であるかもしれません。 また、セクション4のリアルタイムのカプセル化と暗号化との相互作用の短い言及が上であることを見てください。 セキュリティ要件が可能にするなら、望ましくは、データだけをコード化する特別なRTPペイロードデータの形式は使用されるかもしれません。
Bormann Informational [Page 11] RFC 2689 Integrated Services over Low-bitrate Links September 1999
安値-bitrateの上の統合サービスリンクスボルマン情報[11ページ]のRFC2689 1999年9月
9. References
9. 参照
[1] Handley, M., Crowcroft, J., Bormann, C. and J. Ott, "The
Internet Multimedia Conferencing Architecture", Work in
Progress.
[1] 「インターネットマルチメディア会議構造」というハンドレー、M.、クロウクロフト、J.、ボルマン、C.、およびJ.オットは進行中で働いています。
[2] Degermark, M., Nordgren, B. and S. Pink, "IP Header
Compression", RFC 2507, February 1999.
[2] デーゲルマルクとM.とNordgrenとB.とS.ピンク、「IPヘッダー圧縮」、RFC2507、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] スコットPetrack、エドEllesson、「C/RTP枠組み:」 「圧縮されたRTP Using Adaptive Differential Header Compression」、メーリングリスト 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の機能的な仕様」、RFC2205、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)について議定書の中で述べます」、RFC1990、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.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、RFC1889、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.、およびRFC2508、1999年2月対「低速連続のリンクへのIP/UDP/RTPヘッダーを圧縮する」ジェーコブソン
[8] Bormann, C., "The Multi-Class Extension to Multi-Link PPP", RFC
2686, September 1999.
[8] ボルマン、C.、「マルチリンクpppへのマルチのクラス拡大」、RFC2686、1999年9月。
[9] Bormann, C., "PPP in a Real-time Oriented HDLC-like Framing",
RFC 2687, September 1999.
[9] ボルマン、C.、「リアルタイムの指向のHDLCのような縁どりにおけるppp」、RFC2687、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ヘッダー圧縮」、RFC2509、1999年2月。
[11] Wroclawski, J., "Specification of the Controlled-Load Network
Element Service", RFC 2211, September 1997.
[11]Wroclawski、J.、「制御負荷ネットワーク要素サービスの仕様」、RFC2211、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.ゲラン。 「保証されたサービスの質の仕様」、RFC2212、1997年9月。
Bormann Informational [Page 12] RFC 2689 Integrated Services over Low-bitrate Links September 1999
安値-bitrateの上の統合サービスリンクスボルマン情報[12ページ]のRFC2689 1999年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 Recommendation H.223、「低いビット伝送速度マルチメディア通信のためのマルチプレクシングプロトコル」、国際電気通信連合、Telecommunication Standardization Sector(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 Recommendation H.324、「低いビット伝送速度マルチメディア通信のための端末」、国際電気通信連合、Telecommunication Standardization Sector(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 Recommendation H.245、「マルチメディア通信のための制御プロトコル」、国際電気通信連合、Telecommunication Standardization Sector(ITU-T)、1996年3月。
10. Author's Address
10. 作者のアドレス
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
承認
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.
スコットPetrackとケーリー・フィッツジェラルドと共にこのドキュメントにつながった早めの議論の多くのことをしました。 スティーブCasner、マイケル・デーゲルマルク、スティーブJackowski、デーヴ・オラン、低いbitrateの上のISSLLサブグループの他のメンバーは(ISSLOW)、および特に共同いすのエリック・クローリーとジョンWroclawskiがこの構造を現実のものにする際に助けたISSLL WGをリンクします。
Bormann Informational [Page 13] RFC 2689 Integrated Services over Low-bitrate Links September 1999
安値-bitrateの上の統合サービスリンクスボルマン情報[13ページ]のRFC2689 1999年9月
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 Informational [Page 14]
ボルマンInformationalです。[14ページ]
一覧
スポンサーリンク
