RFC3006 日本語訳
3006 Integrated Services in the Presence of Compressible Flows. B.Davie, C. Iturralde, D. Oran, S. Casner, J. Wroclawski. November 2000. (Format: TXT=31588 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group B. Davie
Request for Comments: 3006 C. Iturralde
Category: Standards Track D. Oran
Cisco Systems, Inc.
S. Casner
Packet Design
J. Wroclawski
MIT LCS
November 2000
コメントを求めるワーキンググループB.デイビー要求をネットワークでつないでください: 3006年のC.イトゥラルデカテゴリ: 標準化過程D.オランシスコシステムズInc.S.CasnerパケットデザインJ.Wroclawski MIT LCS2000年11月
Integrated Services in the Presence of Compressible Flows
圧縮性の流れがあるとき統合サービス
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
Abstract
要約
An Integrated Services (int-serv) router performs admission control and resource allocation based on the information contained in a TSpec (among other things). As currently defined, TSpecs convey information about the data rate (using a token bucket) and range of packet sizes of the flow in question. However, the TSpec may not be an accurate representation of the resources needed to support the reservation if the router is able to compress the data at the link level. This specification describes an extension to the TSpec which enables a sender of potentially compressible data to provide hints to int-serv routers about the compressibility they may obtain. Routers which support appropriate compression take advantage of the hint in their admission control decisions and resource allocation procedures; other routers ignore the hint. An initial application of this approach is to notify routers performing real-time transport protocol (RTP) header compression that they may allocate fewer resources to RTP flows.
Integrated Services(int-serv)ルータはTSpec(特に)に含まれた情報に基づく入場コントロールと資源配分を実行します。 現在定義されるように、TSpecsは問題の流れのパケットサイズのデータ信号速度(象徴バケツを使用する)と範囲の周りで情報を伝達します。 しかしながら、ルータがリンク・レベルでデータを圧縮できるなら、TSpecは予約を支持するのに必要であるリソースの正確な表現でないかもしれません。 この仕様は潜在的に圧縮性のデータの送付者がそれらが得るかもしれない圧縮性に関してint-servルータにヒントを提供するのを可能にするTSpecに拡大について説明します。 適切な圧縮を支持するルータがそれらの入場コントロール決定と資源割付け手順におけるヒントを利用します。 他のルータはヒントを無視します。 このアプローチの初期の応用は、より少ないリソースをRTP流れに割り当てるかもしれないようにリアルタイムのトランスポート・プロトコル(RTP)ヘッダー圧縮を実行するルータに通知することです。
Davie, et al. Standards Track [Page 1] RFC 3006 Integrated Services in Compressible Flows November 2000
デイビー、他 標準化過程[1ページ]RFC3006は2000年11月に圧縮性の流れにおけるサービスを統合しました。
Table of Contents
目次
1 Introduction ........................................... 2 2 Addition of a Hint to the Sender TSpec ................. 3 3 Admission Control and Resource Allocation .............. 4 4 Object Format .......................................... 8 4.1 Hint Numbering ......................................... 9 5 Backward Compatibility ................................. 10 6 Security Considerations ................................ 10 7 IANA Considerations .................................... 11 8 Acknowledgments ........................................ 11 9 References ............................................. 11 10 Authors' Addresses ..................................... 12 11 Full Copyright Statement ................................ 13
1つの序論… 送付者TSpecへのヒントの2 2添加… 3 3の入場コントロールと資源配分… 4 4物の形式… 8 4.1は付番について暗示します… 9 5の後方の互換性… 10 6 セキュリティ問題… 10 7 IANA問題… 11 8つの承認… 11 9つの参照箇所… 11 10人の作者のアドレス… 12 11の完全な著作権宣言文… 13
1. Introduction
1. 序論
In an Integrated Services network, RSVP [RFC 2205] may be used as a signalling protocol by which end nodes and network elements exchange information about resource requirements, resource availability, and the establishment and removal of resource reservations. The Integrated Services architecture currently defines two services, Controlled-Load [RFC 2211] and Guaranteed [RFC 2212]. When establishing a reservation using either service, RSVP requires a variety of information to be provided by the sender(s) and receiver(s) for a particular reservation which is used for the purposes of admission control and allocation of resources to the reservation. Some of this information is provided by the receiver in a FLOWSPEC object; some is provided by the sender in a SENDER_TSPEC object [RFC 2210].
Integrated Servicesネットワークでは、RSVP[RFC2205]はエンドノードとネットワーク要素が資源予約のリソース要件、リソースの有用性、設立、および取り外しに関して情報交換する合図プロトコルとして使用されるかもしれません。 Integrated Services構造は現在、2つのサービス、Controlled-負荷[RFC2211]、およびGuaranteed[RFC2212]を定義します。 サービスを利用することで予約を確立するとき、RSVPは、さまざまな情報が送付者と受信機によって入場コントロールの目的とリソースの配分に予約に使用される特定の予約に提供されるのを必要とします。 受信機はこの何らかの情報をFLOWSPEC物に提供します。 或るものは送付者によってSENDER_TSPEC物[RFC2210]に提供されます。
A situation that is not handled well by the current specs arises when a router that is making an admission control decision is able to perform some sort of compression on the flow for which a reservation is requested. For example, suppose a router is able to perform IP/UDP/RTP header compression on one of its interfaces [RFC 2508]. The bandwidth needed to accommodate a compressible flow on that interface would be less than the amount contained in the SENDER_TSPEC. Thus the router might erroneously reject a reservation that could in fact have been accommodated. At the same time, the sender is not at liberty to reduce its TSpec to account for the compression of the data, since it does not know if the routers along the path are in fact able to perform compression. Furthermore, it is probable that only a subset of the routers on the path (e.g., those connected to low-speed serial links) will perform compression.
入場コントロール決定をしているルータが予約が要求されている流れにある種の圧縮を実行できるとき、現在の仕様によってよく扱われない状況は起こります。 例えば、ルータがインタフェース[RFC2508]の1つにIP/UDP/RTPヘッダー圧縮を実行できると仮定してください。 帯域幅は、_SENDERに含まれた量以下がTSPECであったならそのインタフェースで圧縮性の流れに対応する必要がありました。 したがって、ルータは誤って事実上、設備されたかもしれない予約を拒絶するかもしれません。 同時に、送付者はデータの要約を説明するためにTSpecを減少させるのにおいて自由ではありません、事実上、経路に沿ったルータが圧縮を実行できるかどうかを知らないので。 その上、経路(例えば低速連続のリンクに接続されたもの)のルータの部分集合だけが圧縮を実行するのは、ありえそうです。
Davie, et al. Standards Track [Page 2] RFC 3006 Integrated Services in Compressible Flows November 2000
デイビー、他 標準化過程[2ページ]RFC3006は2000年11月に圧縮性の流れにおけるサービスを統合しました。
This specification describes a mechanism by which the sender can provide a hint to network elements regarding the compressibility of the data stream that it will generate. Network elements may use this hint as an additional piece of data when making admission control and resource allocation decisions.
この仕様は送付者がそれが発生させるデータ・ストリームの圧縮性に関するネットワーク要素にヒントを供給できるメカニズムについて説明します。 入場コントロールと資源配分を決定にするとき、ネットワーク要素は追加データとしてこのヒントを使用するかもしれません。
This specification is restricted to the case where compression is performed only on a link-by-link basis, as with header compression. Other cases (e.g., transcoding, audio silence detection) which would affect the bandwidth consumed at all downstream nodes are for further study. In these latter cases, it would be necessary to modify a sender TSpec as it is passed through a compressing node. In the approach presented here, the sender TSpec that appears on the wire is never modified, just as specified in [RFC 2210].
この仕様は圧縮がヘッダー圧縮のようにリンクごとのベースだけに実行されるケースに制限されます。 さらなる研究にはすべての川下のノードで消費された帯域幅に影響する他のケース(例えば、コード変換、オーディオの沈黙検出)があります。 これらの後者の場合では、圧縮ノードを通り抜けるとき、送付者TSpecを変更するのが必要でしょう。 ここに提示されたアプローチでは、ワイヤの上に現れる送付者TSpecが決して変更されません、ちょうど[RFC2210]で指定されるように。
2. Addition of a Hint to the Sender TSpec
2. 送付者TSpecへのヒントの添加
The appropriate place for a `compressibility hint' is the Sender TSpec. The reasons for this choice are:
'圧縮性ヒント'のための適切な場所はSender TSpecです。 この選択の理由は以下の通りです。
- The sender is the party who knows best what the data will look
like.
- 送付者はデータが何に似るかを特に知っているパーティーです。
- Unlike the Adspec, the Sender TSpec is not modified in transit
- Adspecと異なって、Sender TSpecはトランジットで変更されません。
- From the perspective of RSVP, the Sender TSpec is a set of
opaque parameters that are passed to `traffic control'
(admission control and resource allocation); the
compressibility hint is just such a parameter.
- RSVPの見解から、Sender TSpecは'トラフィックコントロール'(入場コントロールと資源配分)に通過される1セットの不明瞭なパラメタです。 圧縮性ヒントはただそのようなパラメタです。
An alternative to putting this information in the TSpec would be to use an additional object in the RSVP PATH message. While this could be made to work for RSVP, it does not address the issue of how to get the same information to an intserv router when mechanisms other than RSVP are used to reserve resources. It would also imply a change to RSVP message processing just for the purposes of getting more information to entities that are logically not part of RSVP (admission control and resource allocation). The inclusion of the information in the TSpec seems preferable and more consistent with the Integrated Services architecture.
この情報をTSpecに入れることへの代替手段はRSVP PATHメッセージで追加物を使用するだろうことです。 これはRSVPのために働かされることができた間、それがRSVP以外のメカニズムがリソースを予約するのに使用されるとき、どう同じ情報をintservルータに得るかに関する問題を記述しません。 また、それはまさしくRSVP(入場コントロールと資源配分)の一部ではなく、実体への詳しい情報を論理的に得る目的のためのRSVPメッセージ処理への変化を含意するでしょう。 TSpecでの情報の包含はIntegrated Services構造と望ましくより一致しているように見えます。
The contents of the hint are likely to vary depending on the exact scenario. The hint needs to tell the routers that receive it:
正確なシナリオによって、ヒントの内容は異なりそうです。 ヒントは、それを受けるルータを言う必要があります:
- the type of compression that is possible on this flow (e.g.
IP/UDP/RTP);
- これで可能な圧縮のタイプは流れます(例えば、IP/UDP/RTP)。
Davie, et al. Standards Track [Page 3] RFC 3006 Integrated Services in Compressible Flows November 2000
デイビー、他 標準化過程[3ページ]RFC3006は2000年11月に圧縮性の流れにおけるサービスを統合しました。
- enough information to enable a router to determine the likely
compression ratio that may be achieved.
- ルータが達成されるかもしれないありそうな圧縮比を測定するのを可能にすることができるくらいの情報。
In a simple case such as IP/UDP/RTP header compression, it may be sufficient to tell the routers nothing more than the fact that IP/UDP/RTP data is being sent. Knowing this fact, the maximum packet size of the flow (from the TSpec), and the local conditions at the router, may be sufficient to allow the router to determine the reduction in bandwidth that compression will allow. In other cases, it may be helpful or necessary for the sender to include additional quantitative information to assist in the calculation of the compression ratio. To handle these cases, additional parameters containing various amounts of information may be added to the sender TSpec. Details of the encoding of these parameters, following the approach originally described in [RFC 2210] are described below.
IP/UDP/RTPヘッダー圧縮などの簡単な場合では、それは、IP/UDP/RTPデータがただ事実ですが、送って、ありながらルータを言うために十分であるかもしれません。 この事実、流れ(TSpecからの)の最大のパケットサイズ、およびルータにおける現地の状況を知っているのは、ルータが圧縮が許容する帯域幅での減少を決定するのを許容するために十分であるかもしれません。 他の場合では、送付者が圧縮比の計算を助けるために追加量的な情報を入れるのが、役立っているか、または必要であるかもしれません。 これらのケースを扱うために、様々な量の情報を含む追加パラメタは送付者TSpecに加えられるかもしれません。 これらのパラメタのコード化の詳細であり、元々[RFC2210]で説明されたアプローチに続くのは以下で説明されます。
3. Admission Control and Resource Allocation
3. 入場コントロールと資源配分
Integrated Services routers make admission control and resource allocation decisions based on, among other things, information in the sender TSpec. If a router receives a sender TSpec which contains a compressibility hint, it may use the hint to calculate a `compressed TSpec' which can be used as input to the admission control and resource allocation processes in place of the TSpec provided by the sender. To make this concrete, consider the following simple example. A router receives a reservation request for controlled load service where:
統合Servicesルータは入場コントロールと資源配分を特に送付者TSpecの情報に基づく決定にします。 ルータが圧縮性ヒントを含む送付者TSpecを受けるなら、それは、送付者によって提供されたTSpecに代わって入場コントロールと資源配分の過程に入力されるように使用できる'圧縮されたTSpec'について計算するのにヒントを使用するかもしれません。 このコンクリートを作るには、以下の簡単な例を考えてください。 ルータは制御負荷を求める要求がどこを修理するかという条件を受けます:
- The Sender TSpec and Receiver TSpec contain identical token
bucket parameters;
- Sender TSpecとReceiver TSpecは同じ象徴バケツパラメタを含んでいます。
- The rate parameter in the token bucket (r) is 48 kbps;
- 象徴バケツ(r)の中のレートパラメタは48キロビット毎秒です。
- The token bucket depth (b) is 120 bytes;
- 象徴バケツの深さ(b)は120バイトです。
- The maximum packet size (M) in the TSpecs is 120 bytes;
- TSpecsの最大のパケットサイズ(M)は120バイトです。
- The minimum policed unit (m) is 64 bytes;
- 最小の取り締まられた単位(m)は64バイトです。
- The Sender TSpec contains a compressibility hint indicating
that the data is IP/UDP/RTP;
- Sender TSpecはデータがIP/UDP/RTPであることを示す圧縮性ヒントを含んでいます。
- The compressibility hint includes a compression factor of 70%,
meaning that IP/UDP/RTP header compression will cause a
reduction in bandwidth consumed at the link level by a factor
of 0.7 (the result of compressing 40 bytes of IP/UDP/RTP header
to 4 bytes on a 120 byte packet)
- 圧縮性ヒントは70%の圧縮要素を含んでいます、IP/UDP/RTPヘッダー圧縮が0.7の要素によってリンク・レベルで消費された帯域幅での減少を引き起こすことを意味して(IP/UDP/RTPヘッダーの40バイトを120バイトのパケットの4バイトに圧縮するという結果)
Davie, et al. Standards Track [Page 4] RFC 3006 Integrated Services in Compressible Flows November 2000
デイビー、他 標準化過程[4ページ]RFC3006は2000年11月に圧縮性の流れにおけるサービスを統合しました。
- The interface on which the reservation is to be installed is
able to perform IP/UDP/RTP header compression.
- インストールされる予約がことであるインタフェースはIP/UDP/RTPヘッダー圧縮を実行できます。
The router may thus conclude that it can scale down the token bucket parameters r and b by a factor of 0.7, i.e., to 33.6 kbps and 84 bytes respectively. M may be scaled down by the same factor (to 84 bytes), but a different calculation should be used for m. If the sender actually sends a packet of size m, its header may be compressed from 40 bytes to 4, thus reducing the packet to 28 bytes; this value should be used for m.
その結果、ルータは、すなわち、0.7の要素、33.6キロビット毎秒と84バイトに象徴バケツパラメタrとbをそれぞれ縮小させることができると結論を下すかもしれません。 同じ要素(84バイトへの)によってMは縮小させられるかもしれませんが、異なった計算はmに使用されるべきです。 送付者が実際にサイズmのパケットを送るなら、ヘッダーは40バイトから4まで圧縮されるかもしれません、その結果、パケットを28バイトまで減少させます。 この値はmに使用されるべきです。
Note that if the source always sends packets of the same size and IP/UDP/RTP always works perfectly, the compression factor is not strictly needed. The router can independently determine that it can compress the 40 bytes of IP/UDP/RTP header to 4 bytes (with high probability). To determine the worst-case (smallest) gain provided by compression, it can assume that the sender always sends maximum sized packets at 48 kbps, i.e., a 120 byte packet every 20 milliseconds. The router can conclude that these packets would be compressed to 84 bytes, yielding a token bucket rate of 33.6 kbps and a token bucket depth of 84 bytes as before. If the sender is willing to allow an independent calculation of compression gain by the router, the explicit compression factor may be omitted from the TSpec. Details of the TSpec encoding are provided below.
ソースがいつも同じサイズのパケットを送って、IP/UDP/RTPが完全にいつも働くなら、圧縮要素は厳密に必要でないことに注意してください。 ルータは、IP/UDP/RTPヘッダーの40バイトを4バイト(高い確率がある)に圧縮できることを独自に決定できます。 最悪の場合(最も小さい)を決定するには、送付者が20ミリセカンド毎にすなわち、48キロビット毎秒、120バイトのパケットでいつも最大の大きさで分けられたパケットを送ると圧縮で仮定できるなら、獲得してください。 ルータは、これらのパケットが84バイトに圧縮されると結論を下すことができます、従来と同様33.6キロビット毎秒の象徴バケツレートと84バイトの象徴バケツの深さをもたらして。 送付者が、ルータで圧縮利得の独立している計算を許容しても構わないと思っているなら、明白な圧縮要素はTSpecから省略されるかもしれません。 TSpecコード化の詳細は以下に明らかにされます。
To generalize the above discussion, assume that the Sender TSpec consists of values (r, b, p, M, m), that the explicit compression factor provided by the sender is f percent, and that the number of bytes saved by compression is N, independent of packet size. The parameters in the compressed TSpec would be:
上の議論を一般化するために、Sender TSpecが値(r、b、p、M、m)から成って、送付者によって提供された明白な圧縮要素がfパーセントであり、圧縮で節約されたバイト数がNであると仮定してください、パケットサイズの如何にかかわらず。 圧縮されたTSpecのパラメタは以下の通りでしょう。
r' = r * f/100
b' = b * f/100
p' = p
M' = M-N
m' = m-N
'b*f/100r*f/100r'=b'=pは= M-N m'p Mと等し''がm-Nと等しいです。
The calculations for r' and b' reflect that fact that f is expressed as a percentage and must therefore be divided by 100. The calculations for M' and m' hold only in the case where the compression algorithm reduces packets by a certain number of bytes independent of content or length of the packet, as is true for header compression. Other compression algorithms may not have this property. In determining the value of N, the router may need to make worst case assumptions about the number of bytes that may be removed by compression, which depends on such factors as the presence of UDP checksums and the linearity of RTP timestamps.
'r'とbのための計算'はfを割合として言い表されて、したがって、100で分割しなければならないというその事実を反映します。 'Mと'm'のための計算は圧縮アルゴリズムがそのままなパケットの内容か長さの如何にかかわらずヘッダー圧縮のために本当にパケットをある数のバイト減少させるケースだけを抑制します。 他の圧縮アルゴリズムには、この特性がないかもしれません。 Nの値を決定する際に、ルータは、最悪の場合仮定をUDPチェックサムの存在のような要素に依存する圧縮で取り除かれるかもしれないバイトのおよそ数とRTPタイムスタンプの直線形にする必要があるかもしれません。
Davie, et al. Standards Track [Page 5] RFC 3006 Integrated Services in Compressible Flows November 2000
デイビー、他 標準化過程[5ページ]RFC3006は2000年11月に圧縮性の流れにおけるサービスを統合しました。
All these adjusted values are used in the compressed TSpec. The router's admission control and resource allocation algorithms should behave as if the sender TSpec contained those values. [RFC 2205] provides a set of rules by which sender and receiver TSpecs are combined to calculate a single `effective' TSpec that is passed to admission control. When a reservation covering multiple senders is to be installed, it is necessary to reduce each sender TSpec by its appropriate compression factor. The set of sender TSpecs that apply to a single reservation on an interface are added together to form the effective sender TSpec, which is passed to traffic control. The effective receiver TSpec need not be modified; traffic control takes the greatest lower bound of these two TSpecs when making its admission control and resource allocation decisions.
これらのすべての調整値が圧縮されたTSpecで使用されます。 まるで送付者TSpecがそれらの値を含んでいるかのようにルータの入場コントロールとリソース割り当てアルゴリズムは反応するべきです。 [RFC2205]は送付者と受信機TSpecsが入場コントロールに渡される独身の'有効な'TSpecについて計算するために結合される1セットの規則を提供します。 複数の送付者を覆う予約がインストールされることであるときに、適切な圧縮要素でそれぞれの送付者TSpecを減少させるのが必要です。 インタフェースのただ一つの予約に適用する送付者TSpecsのセットは、有効な送付者TSpecを形成するために合計されます。(TSpecはトラフィックコントロールに渡されます)。 有効な受信機TSpecは変更される必要はありません。 入場をコントロールにして、資源配分を決定にするとき、トラフィックコントロールはこれらの2TSpecsの最も大きい下界を取ります。
The handling of the receiver RSpec depends on whether controlled load or guaranteed service is used. In the case of controlled load, no additional processing of RSpec is needed. However, a guaranteed service RSpec contains a rate term R which does need to be adjusted downwards to account for compression. To determine how R should be adjusted, we note that the receiver has chosen R to meet a certain delay goal, and that the terms in the delay equation that depend on R are b/R and C/R (when the peak rate is large). The burstsize b in this case is the sum of the burstsizes of all the senders for this reservation, and each of these numbers has been scaled down by the appropriate compression factor. Thus, R should be scaled down using an average compression factor
受信機RSpecの取り扱いは制御負荷か保証されたサービスが使用されているかどうかによります。 制御負荷の場合では、RSpecのどんな追加処理も必要ではありません。 しかしながら、保証されたサービスRSpecは圧縮を説明するように下向きに調整される必要があるレート用語Rを含んでいます。 Rがどのように調整されるべきであるかを決定するために、私たちはRによる遅れ方程式による用語が受信機が、ある一定の遅れ目標を達成するためにRを選んで、b/RとC/Rであることに注意します(ピークレートが大きいときに)。 burstsizeする、この場合、bが合計でそう、この予約のためにすべての送付者にburstsizesして、適切な圧縮要素によってそれぞれこれらの数についてスケーリングされました。 したがって、Rは、平均した圧縮要素を使用することで縮小するべきです。
f_avg = (b1*f1 + b2*f2 + ... + bn*fn)/(b1 + b2 + ... bn)
f_avgは/と等しいです(b1*f1+b2*f2+…+bn*fn)。(…b1+b2+bn)
where bk is the burstsize of sender k and fk is the corresponding compression factor for this sender. Note that f_avg, like the individual fi's, is a percentage. Note also that this results in a compression factor of f in the case where all senders use the same compression factor f.
Bkがそうである、burstsizeする、送付者では、kとfkはこの送付者への対応する圧縮要素です。 f_avgが個々のfiのもののように割合であることに注意してください。 また、これがfのすべての送付者が同じ圧縮要素fを使用するケースの中の圧縮要素をもたらすことに注意してください。
To prevent an increase in delay caused by the C/R term when the reduced value of R is used for the reservation, it is necessary for this hop to `inflate' its value of C by dividing it by (f_avg/100). This will cause the contribution to delay made by this hop's C term to be what the receiver would expect when it chooses its value of R.
Rの減少している値が予約に使用されるC/R用語によって引き起こされた遅れの増加を防ぐために、このホップが(f_avg/100)にそれを割ることによってCの値を'ふくらませる'であることが必要です。 これは、このホップCの用語によって作られた遅れへの貢献がそれであるときに受信機が予想することがRの値を選ぶということであることを引き起こすでしょう。
There are certain risks in adjusting the resource requirements downwards for the purposes of admission control and resource allocation. Most compression algorithms are not completely deterministic, and thus there is a risk that a flow will turn out to be less compressible than had been assumed by admission control. This risk is reduced by the use of the explicit compression factor provided by the sender, and may be minimized if the router makes
入場コントロールと資源配分の目的のために下向きにリソース要件を調整するのにおいて特定のリスクがあります。 ほとんどの圧縮アルゴリズムが完全に決定論的であるというわけではありません、そして、その結果、流れが入場コントロールで想定されたほど圧縮性でないと判明するというリスクがあります。 この危険は、送付者によって提供された明白な圧縮要素の使用で減少して、ルータ造であるなら最小にされるかもしれません。
Davie, et al. Standards Track [Page 6] RFC 3006 Integrated Services in Compressible Flows November 2000
デイビー、他 標準化過程[6ページ]RFC3006は2000年11月に圧縮性の流れにおけるサービスを統合しました。
worst case assumptions about the amount of compression that may be achieved. This is somewhat analogous to the tradeoff between making worst case assumptions when performing admission control or making more optimistic assumptions, as in the case of measurement-based admission control. If a flow turns out to be less compressible that had been assumed when performing admission control, any extra traffic will need to be policed according to normal intserv rules. For example, if the router assumed that the 48 kbps stream above could be compressed to 33.6 kbps and it was ultimately possible to compress it to 35 kbps, the extra 1.4 kbps would be treated as excess. The exact treatment of such excess is service dependent.
最もひどく達成されるかもしれない圧縮量に関する仮定をケースに入れてください。 これは入場コントロールを実行するとき、最悪の場合仮定をするか、または、より楽観的な仮定をすることの間の見返りにいくらか類似しています、測定ベースの入場コントロールに関するケースのように。 入場コントロール(余分な交通が正常なintserv規則に従って取り締まられるために必要とするいずれも)を実行するとき、流れがそれほど圧縮性でないと判明するなら、それは想定されました。 35キロビット毎秒にそれを圧縮するのが結局可能であった、例えば、ルータが、48キロビット毎秒が上に流れると仮定するなら33.6キロビット毎秒に圧縮できて、余分な1.4キロビット毎秒は過剰として扱われるでしょう。 そのような過剰の正確な処理はサービス扶養家族です。
A similar scenario may arise if a sender claims that data for a certain session is compressible when in fact it is not, or overstates the extent of its compressibility. This might cause the flow to be erroneously admitted, and would cause insufficient resources to be allocated to it. To prevent such behavior from adversely affecting other reserved flows, any flow that sends a compressibility hint should be policed (in any router that has made use of the hint for its admission control) on the assumption that it is indeed compressible, i.e., using the compressed TSpec. That is, if the flow is found to be less compressible than advertised, the extra traffic that must be forwarded by the router above the compressed TSpec will be policed according to intserv rules appropriate for the service. Note that services that use the maximum datagram size M for policing purposes (e.g. guaranteed service [RFC 2210]) should continue to use the uncompressed value of M to allow for the possibility that some packets may not be successfully compressed.
送付者が事実上、それが主張しないとき、あるセッションのためのデータが圧縮性であると主張するか、または圧縮性の範囲を言いすぎるなら、同様のシナリオは起こるかもしれません。 これで、流れが誤って認められることを引き起こすかもしれなくて、不十分なリソースをそれに割り当てるでしょう。 そのような振舞いが他の予約された流れに悪影響を与えるのを防ぐために、圧縮性ヒントを送るどんな流れもすなわち、本当に、それが圧縮されたTSpecを使用することで圧縮性であるという前提で取り締まられるべきです(入場コントロールにヒントを利用したどんなルータでも)。 すなわち、流れが広告を出すほど圧縮性でないことがわかっていると、サービスに、適切なintserv規則に従って、圧縮されたTSpecの上のルータで進めなければならない余分な交通は取り締まられるでしょう。 目的(例えば、アフターサービスを保証します[RFC2210])を取り締まるのに最大のデータグラムサイズMを使用するサービスが、いくつかのパケットが首尾よく圧縮されないかもしれない可能性を考慮するのにMの解凍された値を使用し続けるべきであることに注意してください。
Note that RSVP does not generally require flows to be policed at every hop. To quote [RFC 2205]:
一般に、RSVPが、流れがあらゆるホップで取り締まられるのを必要としないことに注意してください。 [RFC2205]を引用するために:
Some QoS services may require traffic policing at some or all of
(1) the edge of the network, (2) a merging point for data from
multiple senders, and/or (3) a branch point where traffic flow
from upstream may be greater than the downstream reservation being
requested. RSVP knows where such points occur and must so
indicate to the traffic control mechanism.
いくつかのQoSサービスが(2) (1) ネットワークの縁、複数の送付者からのデータのための合併しているポイント、そして/または、(3)のいくつかかすべてで上流からの交通の流れが要求されている川下の予約よりすごいかもしれないブランチポイントを取り締まる交通を必要とするかもしれません。 そのようなポイントがどこに起こるかを知っているので、RSVPはメカニズムをトラフィックコントロールに示さなければなりません。
For the purposes of policing, a router which makes use of the compressibility hint in a sender TSpec should behave as if it is at the edge of the network, because it is in a position to receive traffic from a sender that, while it passed through policing at the real network edge, may still need to be policed if the amount of data sent exceeds the amount described by the compressed TSpec.
取り締まりの目的のために、まるでそれがネットワークの縁にあるかのように送付者TSpecで圧縮性ヒントを利用するルータは振る舞うべきです、それが送られたデータ量が圧縮されたTSpecによって説明された量を超えるなら本当のネットワーク縁の取り締まりを通り抜けた間にまだ取り締まられる必要があるかもしれない送付者からの交通を受ける立場にあるので。
Davie, et al. Standards Track [Page 7] RFC 3006 Integrated Services in Compressible Flows November 2000
デイビー、他 標準化過程[7ページ]RFC3006は2000年11月に圧縮性の流れにおけるサービスを統合しました。
4. Object Format
4. 物の形式
The compressibility hint may be included in the sender TSpec using the encoding rules of Appendix A in [RFC 2210]. The complete sender TSpec is as follows:
圧縮性ヒントは、送付者TSpecに[RFC2210]でAppendix Aの符号化規則を使用することで含まれるかもしれません。 完全な送付者TSpecは以下の通りです:
31 24 23 16 15 8 7 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | 0 (a) | reserved | 10 (b) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 | 1 (c) |0| reserved | 9 (d) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3 | 127 (e) | 0 (f) | 5 (g) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4 | Token Bucket Rate [r] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5 | Token Bucket Size [b] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6 | Peak Data Rate [p] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7 | Minimum Policed Unit [m] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8 | Maximum Packet Size [M] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
9 | 126 (h) | 0 (i) | 2 (j) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
10 | Hint (assigned number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
11 | Compression factor [f] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
31 24 23 16 15 8 7 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 | 0 (a)| 予約されます。| 10 (b)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | 1 (c)|0| 予約されます。| 9 (d)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | 127 (e)| 0 (f)| 5 (g)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | 象徴Bucket Rate[r](32ビットのIEEE浮動小数点)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5 | 象徴Bucket Size[b](32ビットのIEEE浮動小数点)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 | ピークData Rate[p](32ビットのIEEE浮動小数点)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7 | 最小のPoliced Unit[m](32ビットの整数)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8 | 最大のPacket Size[M](32ビットの整数)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 9 | 126 (h)| 0 (i)| 2 (j)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 10 | ヒント(規定番号)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 11 | 圧縮要素[f](32ビットの整数)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(a) - Message format version number (0)
(b) - Overall length (10 words not including header)
(c) - Service header, service number 1 (default/global
information)
(d) - Length of service 1 data, 9 words not including header
(e) - Parameter ID, parameter 127 (Token_Bucket_TSpec)
(f) - Parameter 127 flags (none set)
(g) - Parameter 127 length, 5 words not including header
(h) - Parameter ID, parameter 126 (Compression_Hint)
(i) - Parameter 126 flags (none set)
(j) - Parameter 126 length, 2 words not including header
(a)--メッセージ・フォーマットバージョン数(0)(b)--全長(ヘッダーを含まない10の単語)(c)--認識番号1(デフォルト/グローバルな情報)(d)--勤続年数1データ、ヘッダー(e)を含まない9つの単語--ヘッダー、Parameter IDを修理してください; パラメタ127(象徴_Bucket_TSpec)(f)--パラメタ127旗パラメタ126(圧縮_ヒント)(i)--パラメタ126旗(なにもセットしなかった)の(j)--(g)--パラメタ127の長さ、ヘッダー(h)を含まない5つの単語--Parameter ID、パラメタ126の長さ(なにもセットしませんでした)、ヘッダーを含まない2つの単語
The difference between this TSpec and the one described in [RFC 2210] is that the overall length contained in the first word is increased by 3, as is the length of the `service 1 data', and the original TSpec parameters are followed by a new parameter, the compressibility hint. This parameter contains the standard parameter header, and an
[RFC2210]で説明されたこのTSpecとものの違いは最初の単語で含まれた全長が'サービス1データ'の長さのように3つ増加して、新しいパラメタ(圧縮性ヒント)が元のTSpecパラメタのあとに続いているということです。 そしてこのパラメタが標準のパラメタヘッダーを含んでいる。
Davie, et al. Standards Track [Page 8] RFC 3006 Integrated Services in Compressible Flows November 2000
デイビー、他 標準化過程[8ページ]RFC3006は2000年11月に圧縮性の流れにおけるサービスを統合しました。
assigned number indicating the type of compression that is possible on this data. Different values of the hint would imply different compression algorithms may be applied to the data. Details of the numbering scheme for hints appear below.
このデータで可能な圧縮のタイプを示す規定番号。 ヒントの異価は、異なった圧縮アルゴリズムがデータに適用されるかもしれないのを含意するでしょう。 ヒントのためのナンバリングスキームの詳細は以下に現れます。
Following the hint value is the compression factor f, expressed as a 32 bit integer representing the factor as a percentage value. The valid range for this factor is (0,100]. A sender that does not know what value to use here or wishes to leave the compression factor calculation to the routers' discretion may use the reserved value 0 to indicate this fact. Zero is reserved because it is not possible to compress a data stream to zero bits per second. The value 100 indicates that no compression is expected on this stream.
ヒント値に続くのは、割合値として要素を表す32ビットの整数として言い表された圧縮要素fです。 この要素のための有効枠は(0,100]です。ここでどんな値を使用したらよいかを知りたくないか、またはルータの思慮深さへの要素計算に圧縮を残したがっている送付者は、この事実を示すのに予約された値0を使用するかもしれません。bpsのゼロを合わせるためにデータ・ストリームを圧縮するのが可能でないので、ゼロは予約されています。値100は、圧縮が全くこの流れのときに予想されないのを示します。
In some cases, additional quantitative information about the traffic may be required to enable a router to determine the amount of compression possible. In this case, a different encoding of the parameter would be required.
いくつかの場合、交通の追加量的な情報が、ルータが可能な圧縮量を測定するのを可能にするのに必要であるかもしれません。 この場合、パラメタの異なったコード化が必要でしょう。
In some cases it may be desirable to include more than one hint in a Tspec (e.g., because more than one compression scheme could be applied to the data.) In this case, multiple instances of parameter 126 may appear in the Tspec and the overall length of the Tspec and the length of the Service 1 data would be increased accordingly.
いくつかの場合、Tspecの1つ以上のヒントを含んでいるのは望ましいかもしれません(例えば、1つ以上の圧縮技術をデータに適用できたので)。 この場合、パラメタ126の複数の例がTspecに現れるかもしれません、そして、Tspecの全長とService1データの長さはそれに従って、増加するでしょう。
Note that the Compression_Hint is, like the Token_Bucket_Tspec, not specific to a single service, and thus has a parameter value less than 128. It is also included as part of the default/global information (service number 1).
Compression_ヒントがToken_Bucket_Tspecのようにただ一つのサービスに特定でなく、その結果、パラメタに128未満を評価させることに注意してください。 また、それはデフォルト/グローバルな情報(認識番号1)の一部として含まれています。
4.1. Hint Numbering
4.1. ヒント付番
Hints are represented by a 32 bit field, with the high order 16 bits being the IP-compression-protocol number as defined in [RFC 1332] and [RFC 2509]. The low order 16 bits are a sub-option for the cases where the IP-compression-protocol number alone is not sufficient for int-serv purposes. The following hint values are required at the time of writing:
ヒントは高位がある32ビットの分野によって16ビット[RFC1332]で定義されるようにIP圧縮プロトコル番号であり、[RFC2509]表されます。 下位16ビットはIP圧縮プロトコル番号だけがint-serv目的のために十分でないケースのためのサブオプションです。 以下のヒント値がこれを書いている時点で必要です:
- hint = 0x002d0000: IP/TCP data that may be compressed according
to [RFC 1144]
- ヒントは0x002d0000と等しいです: IP/TCPデータそれが圧縮されるかもしれない[RFC1144]
- hint = 0x00610000: IP data that may be compressed according to
[RFC 2507]
- ヒント=0x00610000: IPデータそれが圧縮されるかもしれない[RFC2507]
- hint = 0x00610100: IP/UDP/RTP data that may be compressed
according to [RFC 2508]
- ヒント=0x00610100: IP/UDP/RTPデータそれが圧縮されるかもしれない[RFC2508]
Davie, et al. Standards Track [Page 9] RFC 3006 Integrated Services in Compressible Flows November 2000
デイビー、他 標準化過程[9ページ]RFC3006は2000年11月に圧縮性の流れにおけるサービスを統合しました。
5. Backward Compatibility
5. 後方の互換性
It is desirable that an intserv router which receives this new TSpec format and does not understand the compressibility hint should silently ignore the hint rather than rejecting the entire TSpec (or the message containing it) as malformed. While [RFC 2210] clearly specifies the format of TSpecs in a way that they can be parsed even when they contain unknown parameters, it does not specify what action should be taken when unknown objects are received. Thus it is quite possible that some RSVP implementations will discard PATH messages containing a TSpec with the compressibility hint. In such a case, the router should send a PathErr message to the sending host. The message should indicate a malformed TSpec (Error code 21, Sub-code 04). The host may conclude that the hint caused the problem and send a new PATH without the hint.
この新しいTSpec書式を受けて、圧縮性ヒントを理解していないintservルータが奇形として全体のTSpec(または、それを含むメッセージ)を拒絶するより静かにむしろヒントを無視するのは、望ましいです。 [RFC2210]が明確に彼らが未知のパラメタを含むときさえ彼らを分析できる方法でTSpecsの形式を指定している間、それは、未知の物が受け取られているとき、どんな行動が取られるべきであるかを指定しません。 したがって、いくつかのRSVP実現が圧縮性ヒントでTSpecを含むPATHメッセージを捨てるのは、かなり可能です。 このような場合には、ルータはPathErrメッセージを送付ホストに送るべきです。 メッセージは奇形のTSpec(エラーコード21、Sub-コード04)を示すべきです。 ホストは、ヒントが問題を引き起こしたと結論づけて、ヒントなしで新しいPATHを送るかもしれません。
For the purposes of this specification, it would be preferable if unknown TSpec parameters could be silently ignored. In the case where a parameter is silently ignored, the node should behave as if that parameter were not present, but leave the unknown parameter intact in the object that it forwards. This should be the default for unknown parameters of the type described in [RFC 2210].
この仕様の目的のために、静かに未知のTSpecパラメタを無視できるなら、望ましいでしょうに。 パラメタが静かに無視される場合では、まるでそのパラメタが存在していないかのようにノードは振る舞うはずですが、未知のパラメタをそれが進める物で完全なままにしてください。 これは[RFC2210]で説明されたタイプの未知のパラメタのためのデフォルトであるべきです。
It is possible that some future modifications to [RFC 2210] will require unknown parameter types to cause an error response. This situation is analogous to RSVP's handling of unknown objects, which allows for three different response to an unknown object, based on the highest two bits of the Class-Num. One way to handle this would be to divide the parameter space further than already done in [RFC 2216]. For example, parameter numbers of the form x1xxxxxx could be silently ignored if unrecognized, while parameter numbers of the form x0xxxxxx could cause an error response if unrecognized. (The meaning of the highest order bit is already fixed by [RFC 2216].) A third possibility exists, which is to remove the unrecognized parameter before forwarding, but this does not seem to be useful.
[RFC2210]へのいくつかの今後の変更が、未知のパラメータの型が誤り応答を引き起こすのを必要とするのは、可能です。 この状況は未知の物のRSVPの取り扱いに類似しています、Class-ヌムの最も高い2ビットに基づいて。(取り扱いは未知の物への3の異なった応答を考慮します)。 これを扱う1つの方法は[RFC2216]で既にするより遠くにパラメタスペースを分割するだろうことです。 例えば、静かに無視されていますが、フォームx1xxxxxxのパラメタ番号は認識されていないかもしれません、認識されていないなら、フォームx0xxxxxxのパラメタ番号が誤り応答を引き起こす場合がありましたが。 (最も高いオーダービットの意味は[RFC2216]によって既に修理されています。) 推進の前に認識されていないパラメタを取り除くことである3番目の可能性は存在していますが、これは役に立つように思えません。
6. Security Considerations
6. セキュリティ問題
The extensions defined in this document pose essentially the same security risks as those of [RFC 2210]. The risk that a sender will falsely declare his data to be compressible is equivalent to the sender providing an insufficiently large TSpec and is dealt with in the same way.
本書では定義された拡大は[RFC2210]のものとして本質的には同じセキュリティに危険を引き起こします。 送付者が、彼のデータが圧縮性であると間違って宣言するという危険は、不十分に大きいTSpecを提供する送付者にとって同等であり、同様に、対処されています。
Davie, et al. Standards Track [Page 10] RFC 3006 Integrated Services in Compressible Flows November 2000
デイビー、他 標準化過程[10ページ]RFC3006は2000年11月に圧縮性の流れにおけるサービスを統合しました。
7. IANA Considerations
7. IANA問題
This specification relies on IANA-assigned numbers for the compression scheme hint. Where possible the existing numbering scheme for compression algorithm identification in PPP has been used, but it may in the future be necessary for IANA to assign hint numbers purely for the purposes of int-serv.
この仕様は圧縮技術ヒントのIANA-規定番号を当てにします。 可能であるところでは、PPPでの圧縮アルゴリズム識別のための既存のナンバリングスキームが使用されましたが、IANAがint-servの目的のために純粋にヒント番号を割り当てるのが将来、必要であるかもしれません。
8. Acknowledgments
8. 承認
Carsten Borman and Mike DiBiasio provided much helpful feedback on this document.
カルステン・ボーマンとマイクDiBiasioはこのドキュメントの多くの役立っているフィードバックを提供しました。
9. References
9. 参照
[RFC 1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed
Serial Links", RFC 1144, February 1990.
[RFC1144] 1990年2月のジェーコブソン対「低速連続のリンクへのTCP/IPヘッダーを圧縮すること」でのRFC1144
[RFC 1332] McGregor, G., "The PPP Internet Protocol Control Protocol
(IPCP)", RFC 1332, May 1992.
[RFC1332] マクレガー(G.、「pppインターネットプロトコル制御プロトコル(IPCP)」RFC1332)は1992がそうするかもしれません。
[RFC 2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.
[RFC2205] ブレーデン、R.、チャン、L.、Berson、S.、ハーツォグ、S.、およびS.ジャマン、「資源予約は(RSVP)について議定書の中で述べます--バージョン1の機能的な仕様」、RFC2205、1997年9月。
[RFC 2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
Services", RFC 2210, September 1997.
[RFC2210] Wroclawski、J.、「IETFの統合サービスとのRSVPの使用」、RFC2210、1997年9月。
[RFC 2211] Wroclawski, J., "Specification of the Controlled-Load
Network Element Service", RFC 2211, September 1997.
[RFC2211] Wroclawski、J.、「制御負荷ネットワーク要素サービスの仕様」、RFC2211、1997年9月。
[RFC 2212] Shenker, S., Partridge, C. and R. Guerin, "Specification
of Guaranteed Quality of Service", RFC 2212, September
1997.
[RFC2212] ShenkerとS.とヤマウズラとC.とR.ゲラン、「保証されたサービスの質の仕様」、RFC2212、1997年9月。
[RFC 2216] Shenker, S. and J. Wroclawski, "Network Element Service
Specification Template", RFC 2216, September 1997.
[RFC2216] ShenkerとS.とJ.Wroclawski、「ネットワーク要素サービス仕様テンプレート」、RFC2216、1997年9月。
[RFC 2507] Degermark, M., Nordgren, B. and S. Pink,"Header
Compression for IP", RFC 2507, February 1999.
[RFC2507] デーゲルマルクとM.とNordgrenとB.とS.ピンク、「IPのためのヘッダー圧縮」、RFC2507、1999年2月。
[RFC 2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP
Headers for Low-Speed Serial Links", RFC 2508, February
1999.
[RFC2508] Casner、S.、およびRFC2508、1999年2月対「低速連続のリンクへのIP/UDP/RTPヘッダーを圧縮する」ジェーコブソン
[RFC 2509] Engan, M., Casner, S. and C. Bormann, "IP Header
Compression over PPP", RFC 2509, February 1999.
[RFC2509] EnganとM.とCasnerとS.とC.ボルマン、「pppの上のIPヘッダー圧縮」、RFC2509、1999年2月。
Davie, et al. Standards Track [Page 11] RFC 3006 Integrated Services in Compressible Flows November 2000
デイビー、他 標準化過程[11ページ]RFC3006は2000年11月に圧縮性の流れにおけるサービスを統合しました。
10. Authors' Addresses
10. 作者のアドレス
Bruce Davie Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA, 01824
Driveチェルムズフォード、ブルースデイビーシスコシステムズInc.250アポロMA 01824
EMail: bsd@cisco.com
メール: bsd@cisco.com
Carol Iturralde Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA, 01824
Driveチェルムズフォード、キャロルイトゥラルデシスコシステムズInc.250アポロMA 01824
EMail: cei@cisco.com
メール: cei@cisco.com
Dave Oran Cisco Systems, Inc. 170 Tasman Drive San Jose, CA, 95134
Driveサンノゼ、デーヴオランシスコシステムズInc.170タスマン・カリフォルニア 95134
EMail: oran@cisco.com
メール: oran@cisco.com
Stephen L. Casner Packet Design 66 Willow Place Menlo Park, CA 94025
スティーブンL.Casnerパケットデザイン66はメンローパーク、Placeカリフォルニア 94025をウイロにかけます。
EMail: casner@acm.org
メール: casner@acm.org
John Wroclawski MIT Laboratory for Computer Science 545 Technology Sq. Cambridge, MA 02139
ジョンWroclawski MIT Laboratory for Computer Science545技術平方です。 ケンブリッジ、MA 02139
EMail: jtw@lcs.mit.edu
メール: jtw@lcs.mit.edu
Davie, et al. Standards Track [Page 12] RFC 3006 Integrated Services in Compressible Flows November 2000
デイビー、他 標準化過程[12ページ]RFC3006は2000年11月に圧縮性の流れにおけるサービスを統合しました。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 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機能のための基金は現在、インターネット協会によって提供されます。
Davie, et al. Standards Track [Page 13]
デイビー、他 標準化過程[13ページ]
一覧
スポンサーリンク
