[要約] RFC 3006は、圧縮可能なフローの存在下での統合サービスに関する要約です。その目的は、圧縮可能なフローの特性を考慮しながら、統合サービスの提供を向上させることです。
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.
Copyright（c）The Internet Society（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に含まれる情報（とりわけ）に含まれる情報に基づいて、入場制御とリソース割り当てを実行します。現在定義されているように、TSPECSは、問題のフローのデータレート（トークンバケットを使用）とパケットサイズの範囲に関する情報を伝えます。ただし、TSPECは、ルーターがリンクレベルでデータを圧縮できる場合、予約をサポートするために必要なリソースの正確な表現ではない場合があります。この仕様では、潜在的に圧縮可能なデータの送信者が、取得する圧縮性に関するINT-SERVルーターにヒントを提供できるようにする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は、入場管理とリソースのリソースの割り当ての目的に使用される特定の予約のために、送信者と受信機によって提供されるさまざまな情報を必要とします。この情報の一部は、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.
現在の仕様によってうまく処理されない状況は、入学管理の決定を下しているルーターが、予約が要求されるフローで何らかの圧縮を実行できる場合に発生します。たとえば、ルーターがそのインターフェイスの1つでIP/UDP/RTPヘッダー圧縮を実行できるとします[RFC 2508]。そのインターフェイスの圧縮性フローに対応するために必要な帯域幅は、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を変更する必要があります。ここに示されているアプローチでは、[RFC 2210]で指定されているように、ワイヤに表示される送信者TSPECは変更されません。
The appropriate place for a `compressibility hint' is the Sender TSpec. The reasons for this choice are:
「圧縮性ヒント」に適した場所は、送信者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パスメッセージで追加のオブジェクトを使用することです。これはRSVPで機能するようにすることができますが、RSVP以外のメカニズムがリソースの予約に使用された場合、同じ情報をIntServルーターに取得する方法の問題には対処しません。また、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;
- 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;
- 送信者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倍に減少します（40バイトのIP/UDP/RTPヘッダーを圧縮した結果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.
したがって、ルーターは、トークンバケットパラメーターRとBを0.7、つまり33.6 kbpsと84バイトに縮小できると結論付けることができます。Mは同じ係数（84バイト）で縮小される場合がありますが、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の常に完全に機能する場合、圧縮係数は厳密に必要ではないことに注意してください。ルーターは、40バイトのIP/UDP/RTPヘッダーを4バイト（確率が高い）に圧縮できることを独立して決定できます。圧縮によって提供される最悪のケース（最小）ゲインを決定するために、送信者は常に48 kbps、つまり20ミリ秒ごとに120バイトパケットで最大サイズのパケットを送信すると仮定できます。ルーターは、これらのパケットが84バイトに圧縮され、前に33.6 kbpsのトークンバケットレートと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が値（R、B、P、M、M、M）で構成されていること、送信者によって提供される明示的な圧縮係数がFパーセントであり、圧縮によって保存されたバイト数はnであると仮定します。、パケットサイズとは無関係です。圧縮されたTSPECのパラメーターは次のとおりです。
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を変更する必要はありません。交通制御は、入場制御とリソースの割り当ての決定を行う際に、これら2つの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であることに注意してください（ピークレートが大きい場合）。この場合のバーストサイズBは、この予約のすべての送信者のバーストサイズの合計であり、これらの各数値は適切な圧縮係数によって縮小されています。したがって、平均圧縮係数を使用してRをスケーリングする必要があります
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は送信者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項によって引き起こされる遅延の増加を防ぐために、このホップがCの値を「f_avg/100）で除算することにより「膨張」する必要があります。これにより、このホップの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 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ルールに従って追加のトラフィックをポリシングする必要があります。たとえば、ルーターが上記の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は一般に、すべてのホップでポリシーをポリシングするためにフローを必要としないことに注意してください。引用する[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サービスでは、（1）ネットワークのエッジ、（2）複数の送信者からのデータのマージポイント、および/または（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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(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.
[RFC 2210]で説明されているこのtspecとの違いは、最初の単語に含まれる全体の長さが「サービス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.
ヒント値に従うのは、パーセンテージ値として係数を表す32ビット整数として表される圧縮係数Fです。この係数の有効な範囲は（0,100]です。ここで使用する価値がわからない送信者、またはルーターの裁量に圧縮係数の計算を残したい送信者は、予約額0を使用してこの事実を示すことができます。データストリームを1秒あたりゼロビットに圧縮することはできません。値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:
ヒントは32ビットフィールドで表され、高次の16ビットは[RFC 1332]および[RFC 2509]で定義されているIP圧縮プロトコル数です。低次の16ビットは、IP-Compression-Protocol数だけではINT-Servの目的では不十分な場合のサブオプションです。執筆時点では、次のヒント値が必要です。
- hint = 0x002d0000: IP/TCP data that may be compressed according to [RFC 1144]
- Hint = 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]
- Hint = 0x00610100：[RFC 2508]に従って圧縮される可能性のあるIP/UDP/RTPデータ
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を含むパスメッセージを破棄する可能性があります。そのような場合、ルーターは送信ホストにpatherrメッセージを送信する必要があります。メッセージは、奇形のTSPECを示している必要があります（エラーコード21、サブコード04）。ホストは、ヒントが問題を引き起こし、ヒントなしで新しいパスを送信すると結論付けることができます。
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]の将来の変更には、エラー応答を引き起こすために不明なパラメータータイプが必要になる可能性があります。この状況は、RSVPの未知のオブジェクトの処理に類似しており、クラスNumの最高の2ビットに基づいて、未知のオブジェクトに対する3つの異なる応答を可能にします。これを処理する1つの方法は、[RFC 2216]ですでに行われているよりもパラメーター空間をさらに分割することです。たとえば、フォームx1xxxxxxのパラメーター番号は、認識されていない場合は静かに無視できますが、フォームx0xxxxxxのパラメーター番号は、認識されていない場合はエラー応答を引き起こす可能性があります。（最高順序ビットの意味は、[RFC 2216]によってすでに固定されています。）3番目の可能性が存在します。これは、転送前に認識されていないパラメーターを削除することですが、これは有用ではないようです。
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.
Carsten BormanとMike Dibiasioは、このドキュメントについて非常に役立つフィードバックを提供しました。
[RFC 1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial Links", RFC 1144, February 1990.
[RFC 1144] Jacobson、V。、「低速シリアルリンクのTCP/IPヘッダーの圧縮」、RFC 1144、1990年2月。
[RFC 1332] McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, May 1992.
[RFC 1332] McGregor、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] Braden、R.、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「リソース予約プロトコル（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。、「IETF統合サービスでのRSVPの使用」、RFC 2210、1997年9月。
[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.、Partridge、C。およびR. Guerin、「保証されたサービス品質の仕様」、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. Pink、「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。and V. Jacobson、「低速シリアルリンクのIP/UDP/RTPヘッダーの圧縮」、RFC 2508、1999年2月。
[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. Bormann、「PPP上のIPヘッダー圧縮」、RFC 2509、1999年2月。
Bruce Davie Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA, 01824
ブルース・デイビー・シスコ・システムズ、250アポロ・ドライブ・チェルムスフォード、マサチューセッツ州、01824
EMail: bsd@cisco.com
Carol Iturralde Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA, 01824
Carol Iturralde Cisco Systems、Inc。250 Apollo Drive Chelmsford、MA、01824
EMail: cei@cisco.com
Dave Oran Cisco Systems, Inc. 170 Tasman Drive San Jose, CA, 95134
Dave Oran Cisco Systems、Inc。170 Tasman Drive San Jose、CA、95134
EMail: oran@cisco.com
Stephen L. Casner Packet Design 66 Willow Place Menlo Park, CA 94025
Stephen L. Casner Packet Design 66 Willow Place Menlo Park、CA 94025
EMail: casner@acm.org
John Wroclawski MIT Laboratory for Computer Science 545 Technology Sq. Cambridge, MA 02139
コンピューターサイエンスのためのJohn Wroclawski MIT Laboratory 545 Technology Sq。ケンブリッジ、マサチューセッツ州02139
EMail: jtw@lcs.mit.edu
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。