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
Integrated Services in the Presence of Compressible Flows
Status of this 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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
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.
統合サービス（INT-SERV）ルータは（とりわけ）TSpecの中に含まれる情報に基づいてアドミッション制御およびリソース割り当てを行います。現在定義されているように、のTSpecは、当該フローのパケットサイズのデータレート（トークンバケットを使用して）、および範囲についての情報を伝えます。しかし、TSpecのは、ルータがリンク・レベルでデータを圧縮することが可能である場合、予約をサポートするために必要なリソースの正確な表現ではないかもしれません。この仕様は、彼らが得ることができる圧縮についてルータ-SERV INTにヒントを提供するために、潜在的に圧縮可能なデータの送信元を可能にするTSpecの拡張機能について説明します。彼らのアドミッション制御の決定や資源配分手続におけるヒントの適切な圧縮テイク利点をサポートするルータ。他のルータはヒントを無視します。このアプローチの最初のアプリケーションは、それらがRTPフローに少ないリソースを割り当てることができるリアルタイムトランスポートプロトコル（RTP）ヘッダ圧縮を行うルータに通知することです。
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
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].
サービス統合型ネットワークでは、RSVP [RFC 2205]エンドノードとネットワーク要素がリソース要件、リソースの可用性、及び確立とリソース予約の除去についての情報を交換することにより、シグナリングプロトコルとして使用することができます。サービス統合型アーキテクチャは、現在、2つのサービスは、制御負荷[RFC 2211]保証[RFC 2212]を定義します。サービスのいずれかを使用して、予約を確立するときに、RSVP予約にアドミッション制御及びリソースの割り当ての目的のために使用される特定の予約のために送信者（S）と受信機（複数可）によって提供される各種情報を必要とします。この情報の一部は、FLOWSPECオブジェクト内の受信機によって提供されます。いくつかは、SENDER_TSPECオブジェクト[RFC 2210]に送信者によって提供されます。
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.
アドミッション制御の決定をしているルータは予約が要求されているフローに圧縮のいくつかの並べ替えを行うことが可能であるとき、現在のスペックでうまく処理されない状況が発生します。例えば、ルータは、そのインターフェイス[RFC 2508]のいずれかにIP / UDP / RTPヘッダ圧縮を行うことができると仮定する。そのインターフェイス上の圧縮性流れを収容するために必要な帯域幅は、SENDER_TSPECに含まれる量よりも少ないであろう。したがって、ルータが誤って実際に収容されている可能性が予約を拒否することがあります。同時に、送信者は、パスに沿ったルータが実際に圧縮を行うことができれば、それは知っていないので、データの圧縮を考慮して、そのTSpecのを減らすために自由ではありません。さらに、経路上のルータのサブセットのみ（例えば、低速シリアルリンクに接続されたもの）は、圧縮を実行する可能性が高いです。
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のは、[RFC 2210]で指定したのと同様に、変更されることはありません。
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とは異なり、送信者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の観点から、送信者TSpecのは 'トラフィック制御」（アドミッション制御及びリソース割り当て）に渡される不透明なパラメータのセットです。圧縮のヒントは、まさにそのようなパラメータです。
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以外のメカニズムがリソースを予約するために使用されている場合イントサーブルータに同じ情報を取得する方法の問題に対処しません。それはまた、単に論理的にRSVP（アドミッション制御およびリソース割り当て）の一部ではないエンティティに多くの情報を取得する目的のためにメッセージ処理をRSVPに変更を暗示します。 TSpecの中の情報を含めることが好ましいと統合サービスアーキテクチャとより一致すると思われます。
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）上で可能である圧縮のタイプ。
- 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のに加えてもよいです。元々[RFC 2210]に記載されたアプローチ以下、これらのパラメータの符号化の詳細は、以下に記載されています。
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:
サービス統合型ルータは、他のもののうち、送信者TSpecの中の情報をに基づいてアドミッション制御およびリソース配分の決定を行います。ルータは、圧縮性のヒントが含まれている送信元TSpecのを受信した場合、それは、送信者によって提供されるTSpecのに代えて、アドミッション制御及びリソース割り当てプロセスへの入力として使用することができる `圧縮TSpecの」を計算するためにヒントを使用してもよいです。このコンクリートを作るために、以下の簡単な例を考えてみましょう。ルータは、制御されたロード・サービス場所の予約要求を受信します。
- The Sender TSpec and Receiver TSpec contain identical token bucket parameters;
- 送信者TSpecのとレシーバTSpecのは、同一のトークン・バケット・パラメータが含まれています。
- The rate parameter in the token bucket (r) is 48 kbps;
- トークンバケット（R）で速度パラメータは48 kbpsです。
- The token bucket depth (b) is 120 bytes;
- トークンバケットの深さ（B）は120バイトです。
- The maximum packet size (M) in the TSpecs is 120 bytes;
- のTSpecで最大パケットサイズ（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;
- 送信者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)
- 圧縮性のヒントは、IP / UDP / RTPヘッダ圧縮は、0.7の因子（IP / UDP / RTPの40のバイトを圧縮した結果により、リンクレベルで消費される帯域幅の減少を引き起こすであろうことを意味し、70％の圧縮率を含みます120バイトのパケットに4バイトのヘッダ）
- 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.
ルータは、このように、それは、それぞれ33.6 kbpsの84バイトに0.7倍、すなわち、によってトークンバケットパラメータRとBを縮小することができると結論付けることができます。 Mは（84バイト）と同じ係数で縮小することができるが、異なる計算は、mに対して使用されるべきです。送信者が実際にサイズmのパケットを送信する場合、そのヘッダは、このように28バイトのパケットを減少、4に40バイトから圧縮されてもよいです。この値は、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は常に完璧に動作している場合、圧縮率が厳密に必要とされていないことに注意してください。ルータは、独立して、それは（高い確率で）4バイトのIP / UDP / RTPヘッダの40のバイトを圧縮することができると判断することができます。圧縮によって提供される最悪の場合（最小の）利得を決定するためには、送信者が常に48 kbpsの、即ち、120バイトのパケット毎に20ミリ秒で最大サイズのパケットを送信すると仮定することができます。ルータは、これらのパケットは、33.6 kbpsののトークンバケットレートと以前のように84バイトのトークン・バケット深さを得、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:
上記議論を一般化するために、送信者TSpecの送信者によって提供される明示的な圧縮係数をf％であること、および圧縮によって保存されたバイトの数がNであることは、値（R、B、P、M、M）から成ると仮定、パケットサイズに依存しません。圧縮TSpecの中のパラメータは次のようになります。
r' = r * f/100 b' = b * f/100 p' = p M' = M-N m' = m-N
R '= Rの*のF / 100 B' = b *表F / 100、P '= PをM' = M-Nの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タイムスタンプの線形性などの要因に依存し、圧縮することによって除去することができるバイトの数、約最悪の場合の仮定を行う必要があるかもしれません。
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のは、それらの値が含まれているかのようルータのアドミッション制御およびリソース割り当てアルゴリズムを振る舞うべき。 [RFC 2205]送信側と受信側のTSpecは、アドミッション制御に渡される単一 `有効」TSpecのを計算するために結合されるルールのセットを提供します。複数の送信者をカバー予約をインストールする場合、その適切な圧縮率で各センダTSpecのを低減する必要があります。インターフェイス上の単一の予約に適用される送信者のTSpecのセットは、トラフィック制御に渡される有効な送信者TSpecのを、一緒に添加されます。有効な受信機TSpecのは変更する必要はありません。そのアドミッション制御およびリソース配分の決定を行う際に、トラフィック制御は、これら二つのTSpecの最大の下限をとります。
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)
Vfj =（B 1 * P + 1つのBA *カテゴリ+ ... + *ベンのアート）/（B + 1つのBa + ...ベン）
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は、送信者kのburstsizeあり、FKは、この送信者についての対応する圧縮係数です。 Fi回線の個々のように、割合で、そのf_avgに注意してください。これは、すべての送信者が、同じ圧縮係数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のその値を膨らませる `このホップのために必要です。これは、Rのその値を選択したときに、受信機が期待するものであることを、このホップのC項によって作られた遅延に貢献を引き起こします
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 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.
アドミッション制御およびリソース割り当てのために下向きにリソース要件の調整に一定のリスクがあります。ほとんどの圧縮アルゴリズムは完全に決定論的ではありませんので、フローアドミッション制御で想定されていたよりも圧縮性であることが判明してしまうおそれがあります。このリスクは、送信者が提供する明示的な圧縮率を使用することによって削減され、ルータを達成することができる圧縮の量についての最悪の場合の仮定を行う場合は、最小化することができます。これは、測定ベースのアドミッション制御の場合と同様に、アドミッション制御を実行するか、より楽観的な仮定を行うときに最悪の場合の仮定を行うこととの間のトレードオフに幾分類似しています。フローアドミッション制御を行う場合に想定されていたものより少ない圧縮性であることが判明した場合、余分なトラフィックが通常のイントサーブ規則に従ってポリシングする必要があります。ルータは48 kbpsのは33.6 kbpsに圧縮され、35 kbpsにそれを圧縮するために最終的に可能であったことができ、上記ストリームと仮定した場合、余分な1.4 kbpsのは、過剰なものとして扱われることになります。そのような過剰の正確な治療がサービスに依存しています。
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の圧縮。流れがアドバタイズより少ない圧縮であることが判明した場合には、圧縮TSpecの上記ルータによって転送されなければならない余分なトラフィックがサービスに適しのIntServ規則に従ってポリシングされています。ポリシングのために最大データグラムサイズMを使用するサービス（例えば、保証されたサービスは、[RFC 2210]）いくつかのパケットが正常に圧縮されないかもしれないという可能性を可能にするために、Mの非圧縮の値を使用し続けるべきであることに留意されたいです。
Note that RSVP does not generally require flows to be policed at every hop. To quote [RFC 2205]:
一般的にフローを必要としないRSVPは、すべてのホップでポリシングされるように注意してください。 [RFC 2205]を引用すると：
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のによって記述量を超えた場合にポリシングする必要があるかもしれません。
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:
圧縮ヒントは、[RFC 2210]の付録Aの符号化規則を用いて、TSpecの送信者に含まれてもよいです。次のように完全な送信者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 |トークンバケットレート[R]（32ビットIEEE浮動小数点数）| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + 5 |トークンバケットサイズ[B]（32ビットIEEE浮動小数点数）| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + 6 |ピークデータレート[P]（32ビットIEEE浮動小数点数）| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + 7 |最小ポリシング単位[M]（32ビット整数）| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + 8 |最大パケットサイズ[M]（32ビット整数）| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + 9 | 126（H）| 0（ⅰ）| 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
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 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.
このTSpecのと[RFC 2210]で説明したものとの差は 'サービスデータ1」の長さは、第1のワードに含まれる全体の長さは、3だけ増加され、元のTSpecのパラメータが続いていることです新しいパラメータ、圧縮ヒント。このパラメータは標準パラメータヘッダを含み、割り当てられた番号は、このデータに可能である圧縮のタイプを示します。ヒントの異なる値は、異なる圧縮アルゴリズムがデータに適用されてもよい暗示します。ヒントのための番号付け方式の詳細は、以下に表示されます。
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.
以下のヒント値が圧縮係数fであり、パーセント値として係数を表す32ビット整数として表さ。この要因の有効な範囲は（0100]。ここで使用するためにどのような価値を知っているか、この事実を示すために予約された値0を使用してルータの裁量に圧縮係数の計算を残すことを希望しない送信者である。ゼロはために予約されています毎秒ゼロ・ビットにデータ・ストリームを圧縮することは不可能である。値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はつ以上のヒントを含めることが望ましいかもしれない。この場合、パラメータ126の複数のインスタンスがTspecはと全体に表示されることがTspecはおよびサービス1のデータの長さの長さはそれに応じて増加させることになります。
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_HintはToken_Bucket_Tspecように、単一のサービスに対して、特異的ではなく、したがって、パラメータ値未満128また、デフォルト/グローバル情報（サービス番号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:
ヒントは、[RFC 1332]と[RFC 2509]で定義されるように、上位16ビットがIP-圧縮プロトコル番号であると、32ビットのフィールドで表されます。下位16ビットは、単独で、IP-圧縮プロトコル番号がINT-SERVの目的のためには十分ではない場合のサブオプションです。以下のヒント値は、書き込み時に必要とされています。
- hint = 0x002d0000: IP/TCP data that may be compressed according to [RFC 1144]
- ヒント= 0x002d0000：[RFC 1144]に記載の圧縮することができるIP / TCPデータ
- hint = 0x00610000: IP data that may be compressed according to [RFC 2507]
- ヒント= 0x00610000：[RFC 2507]に記載の圧縮することができるIPデータ
- hint = 0x00610100: IP/UDP/RTP data that may be compressed according to [RFC 2508]
- ヒント= 0x00610100：IP / UDP / RTPデータ[RFC 2508]に記載の圧縮することができます
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の（またはそれを含むメッセージ）を拒絶するのではなく、ヒントを無視することが望ましいです。 [RFC 2210]は明確に彼らは未知のパラメータが含まれている場合でも解析できるような方法でのTSpecの形式を指定しますが、それは未知のオブジェクトを受信したときに実行するアクションを指定しません。したがって、いくつかのRSVPの実装は、圧縮のヒントとTSpecのを含むPATHメッセージを破棄することが十分に可能です。そのような場合には、ルータは、送信側ホストへのPathErrメッセージを送信する必要があります。メッセージは、不正なTSpecの（エラーコード21、サブコード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のパラメータは黙って無視することができれば、本明細書の目的のために、それが望ましいだろう。パラメータは無視された場合に、ノードは、そのパラメータが存在しない、それを転送することを目的に、無傷の未知パラメータを残すかのように振る舞うべきです。これは、[RFC 2210]に記載されているタイプの未知のパラメータのデフォルトにする必要があります。
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.
[RFC 2210]にはいくつかの将来の変更は、エラー応答を引き起こすために、未知のパラメータ型を必要とすることも可能です。この状況は、クラスのNumの上位2ビットに基づいて未知の物体、3つの異なる応答を可能にし、未知のオブジェクトのRSVPの取り扱いに類似しています。これを処理する1つの方法は、すでに[RFC 2216]で行うよりも、さらにパラメータ空間を分割することです。認識されていない場合は、フォームのx0xxxxxxのパラメータ番号がエラー応答を引き起こす可能性がありながら、例えば、フォームx1xxxxxxのパラメータ番号は黙って、認識されていない場合は無視することができます。 （最上位ビットの意味は既に[RFC 2216]で固定されている。）第三の可能性は、転送する前に認識されていないパラメータを削除することであり、存在するが、これは有用であると思われません。
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.
この文書で定義された拡張は、[RFC 2210]のものと基本的に同じセキュリティリスクをもたらします。送信者が誤って自分のデータが圧縮であることを宣言しますリスクは、送信者が不十分大きなTSpecのを提供し、同じように扱われると等価です。
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の目的のために純粋にヒント番号を割り当てることが将来的に必要であるかもしれません。
Carsten Borman and Mike DiBiasio provided much helpful feedback on this document.
カールステンボーマンとマイクDiBiasioは、この文書に多くの有益なフィードバックを提供します。
[RFC 1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial Links", RFC 1144, February 1990.
[RFC 1144]ジェーコブソン、V.、 "圧縮TCP /低速シリアルリンクのIPヘッダ"、RFC 1144、1990年2月。
[RFC 1332] McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, May 1992.
[RFC 1332]マクレガー、G.、 "PPPインターネットプロトコル制御プロトコル（IPCP）"、RFC 1332、1992年5月。
[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.
[RFC 2205]ブレーデン、R.、チャン、L.、Berson氏、S.、ハーツォグ、S.とS.ヤミン、 "リソース予約プロトコル（RSVP） - バージョン1の機能的な仕様"、RFC 2205、1997年9月。
[RFC 2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[RFC 2210] Wroclawski、J.、RFC 2210、1997年9月 "IETF統合サービスとRSVPの使用"。
[RFC 2211] Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC 2211, September 1997.
[RFC 2211] Wroclawski、J.、RFC 2211 "制御負荷ネットワーク要素サービスの仕様"、1997年9月。
[RFC 2212] Shenker, S., Partridge, C. and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997.
[RFC 2212] Shenker、S.、ヤマウズラ、C.とR.ゲラン、 "保証されたサービスの質の仕様"、RFC 2212、1997年9月。
[RFC 2216] Shenker, S. and J. Wroclawski, "Network Element Service Specification Template", RFC 2216, September 1997.
[RFC 2216] Shenker、S.およびJ. Wroclawski、 "ネットワーク要素サービス仕様テンプレート"、RFC 2216、1997年9月。
[RFC 2507] Degermark, M., Nordgren, B. and S. Pink,"Header Compression for IP", RFC 2507, February 1999.
[RFC 2507] Degermark、M.、Nordgren、B.とS.ピンク、 "IPのヘッダ圧縮"、RFC 2507、1999年2月。
[RFC 2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999.
[RFC 2508] Casner、S.とV.ヤコブソン、RFC 2508、1999年2月 "低速シリアルリンクのIP / UDP / RTPヘッダの圧縮"。
[RFC 2509] Engan, M., Casner, S. and C. Bormann, "IP Header Compression over PPP", RFC 2509, February 1999.
[RFC 2509] Engan、M.、Casner、S.とC.ボルマン、 "PPP上のIPヘッダー圧縮"、RFC 2509、1999年2月。
Bruce Davie Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA, 01824
ブルース・デイビーシスコシステムズ社250アポロドライブチェルムズフォード、MA、01824
EMail: bsd@cisco.com
メールアドレス：bsd@cisco.com
Carol Iturralde Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA, 01824
キャロルIturraldeシスコシステムズ社250アポロドライブチェルムズフォード、MA、01824
EMail: cei@cisco.com
メールアドレス：cei@cisco.com
Dave Oran Cisco Systems, Inc. 170 Tasman Drive San Jose, CA, 95134
デイブ・オランシスコシステムズ社170タスマン・ドライブサンノゼ、CA、95134
EMail: oran@cisco.com
メールアドレス：oran@cisco.com
Stephen L. Casner Packet Design 66 Willow Place Menlo Park, CA 94025
スティーブンL. Casnerパケットデザイン66ウィロー・プレイスメンロパーク、CA 94025
EMail: casner@acm.org
メールアドレス：casner@acm.org
John Wroclawski MIT Laboratory for Computer Science 545 Technology Sq. Cambridge, MA 02139
コンピュータサイエンス545平方技術のためのジョンWroclawski MIT研究所。ケンブリッジ、MA 02139
EMail: jtw@lcs.mit.edu
メールアドレス：jtw@lcs.mit.edu
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
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機能のための基金は現在、インターネット協会によって提供されます。