FLOWSPEC 構造体 (qos.h)
FLOWSPEC 構造体は、RSVP SP にサービス品質パラメーターを提供します。 これにより、QOS 対応アプリケーションは、特定のフローの QOS 設定を呼び出し、変更、または削除できます。 FLOWSPEC の一部のメンバーは、既定値に設定できます。 詳細については、「解説」を参照してください。
構文
typedef struct _flowspec {
ULONG TokenRate;
ULONG TokenBucketSize;
ULONG PeakBandwidth;
ULONG Latency;
ULONG DelayVariation;
SERVICETYPE ServiceType;
ULONG MaxSduSize;
ULONG MinimumPolicedSize;
} FLOWSPEC, *PFLOWSPEC, *LPFLOWSPEC;
メンバー
TokenRate
フローの有効期間中にデータを送信できる許容レートを指定します。 TokenRate メンバーは、トークンがクレジットに似ている Frame Relay などの WAN テクノロジで見られる他のトークン バケット モデルに似ています。 このようなトークンがすぐに使用されない場合は、一定の定期的な制限 (Windows 2000 サービス品質の場合は PeakBandwidth) までのデータ転送を許可するために発生します。 ただし、クレジットの計上は、指定された金額 (TokenBucketSize) に制限されます。 合計クレジット (トークン) を制限すると、たとえば、一定の期間非アクティブなフローが、大量の未収トークンで使用可能な帯域幅に殺到する状況を回避できます。 フローは時間の経過と同時に ( TokenRate 値で) TokenBucketSize の最大値までしか発生せず、 PeakBandwidth へのバースト転送が制限されているため、トラフィック制御とネットワーク デバイス リソースの整合性が維持されます。 トラフィック制御 は、フローが一度に送信できるデータが多すぎず、ネットワーク デバイスリソースの整合性が維持されるためです。
このモデルでは、アプリケーションは十分なクレジットが利用可能な場合にのみデータを送信できます。 十分なクレジットが利用できない場合、アプリケーションは( QOS_SD_MODEの値に基づいて) トラフィックを待機または破棄する必要があります。 そのため、アプリケーションは送信要件に対する合理的な期待に基づいて TokenRate 要求をベースにすることが重要です。 たとえば、ビデオ アプリケーションでは、 TokenRate は通常、ピークからピークまでの平均ビット レートに設定されます。
TokenRate が受信側でのみQOS_NOT_SPECIFIEDに設定されている場合、TokenRate には最大伝送単位 (MTU) が使用され、転送レート (トークン バケット モデル) の制限は有効になりません。 したがって、 TokenRate は 1 秒あたりのバイト数で表されます。
TokenRate メンバーを 0 に設定することはできません。 また、送信 FLOWSPEC の既定値 (つまり、QOS_NOT_SPECIFIEDに設定) として設定することもできません。
TokenBucketSize
時間に関係なく、フローの特定の方向で発生できるクレジットの最大量 (バイト単位)。 ビデオ アプリケーションでは、 TokenBucketSize が最大の平均フレーム サイズになる可能性があります。 定数レート アプリケーションでは、小さなバリエーションを可能にするために TokenBucketSize を設定する必要があります。
PeakBandwidth
特定のフローに対する時間ベースの送信アクセス許可の上限 (1 秒あたりのバイト数)。 PeakBandwidth メンバーは、1 秒あたりのデータ転送上限を適用することで、大量の送信クレジットが発生した可能性があるフロー、または 1 回限りのデータ バーストまたは循環的なデータ バーストによるネットワーク リソースへの過剰な負荷からのトークンを制限します。 一部の中間システムでは、この情報を利用できるため、リソースの割り当てが効率的になります。
Latency
送信側によるビットの送信と、1 つ以上の目的の受信側による受信までの最大許容遅延 (マイクロ秒単位)。 この数値の正確な解釈は、QOS 要求で指定された保証レベルによって異なります。
DelayVariation
パケットで発生する可能性のある最大遅延と最小遅延の差 (マイクロ秒単位)。 アプリケーションは DelayVariation を使用して、フローの受信側で必要なバッファー領域の量を決定します。 このバッファー・スペース情報は、元のデータ伝送パターンを復元するために使用できます。
ServiceType
フローのネゴシエートするサービスのレベルを指定します。 ServiceType メンバーには、次の定義されたサービスの種類のいずれかを指定できます。
| 値 | 意味 |
|---|---|
|
指定した方向にトラフィックが送信されていないことを示します。 双方向対応メディアでは、この値は基になるソフトウェアに一方向接続のみを設定するように信号を送ります。 このサービスの種類は、TC API では無効です。 |
|
RSVP SP によって実行されたアクションはありません。 ただし、トラフィック制御では BESTEFFORT フローが作成され、フロー上のトラフィックは他の BESTEFFORT トラフィックと同様にトラフィック制御によって処理されます。 |
|
データ パスに沿って関連付けられているネットワーク コンポーネントからアンロードされた条件下で予想されるように、ベスト エフォート サービスによって提供される伝送品質に近いエンドツーエンドの QOS を提供します。
したがって、SERVICETYPE_CONTROLLEDLOADを使用するアプリケーションでは、次のことが想定される場合があります。
|
|
データグラムが保証された配信時間内に到着し、フローのトラフィックが指定されたトラフィック パラメーター内に留まる場合は、キューオーバーフローのために破棄されないことを保証します。 このサービスは、データグラムがソースによって送信された後、一定の時間内に到着することを確実に保証する必要があるアプリケーションを対象としています。 |
|
アプリケーションが BESTEFFORT 伝送よりも優れているが、その伝送要件を定量化できないことを示します。 SERVICETYPE_QUALITATIVEを使用するアプリケーションは、アプリケーション識別子ポリシー オブジェクトを指定できます。 アプリケーション識別ポリシー オブジェクトを使用すると、ネットワーク上のポリシー サーバーがアプリケーションを識別し、それに応じて適切なサービス品質を要求に割り当てることができます。 アプリケーション識別の詳細については、IETF インターネット ドラフト draft-ietf-rap-rsvp-appid-00.txt、またはアプリケーション識別に関する Microsoft ホワイト ペーパーを参照してください。 トラフィック制御は、ローカル コンピューター上の BESTEFFORT トラフィックと同じ優先順位で、この種類のフローを処理します。 ただし、アプリケーション プログラマは、 QOS_TRAFFIC_CLASS QOS オブジェクトを使用して、関連付けられているフローのレイヤー 2 設定を変更することで、このようなフローの優先度を高めることができます。 |
|
ネットワークの変更を通知するために使用されます。 |
|
制御パケット (RSVP シグナリング メッセージなど) の送信にのみ使用されます。 この ServiceType の優先度は最も高くなります。 |
|
すべてのサービスの種類がフローでサポートされることを指定します。 送信側でのみ使用できます。 |
|
この ServiceType 値を使用した転送のサービス品質が変更されないことを示します。 SERVICETYPE_NOCHANGEは、一方向のみのサービス品質の変更を要求する場合、または QoS 仕様の ProviderSpecific パラメーター内でのみ変更を要求する場合に使用でき、 SendingFlowspec または ReceivingFlowspec では使用できません。 |
|
不適合なトラフィックを示すために使用されます。 |
|
指定した方向にトラフィック制御を呼び出さないでください。 |
|
指定した方向の RSVP シグナリングを抑制します。 |
次の一覧は、 ServiceType 設定の相対的な優先度を示しています。
SERVICETYPE_NETWORK_CONTROL
SERVICETYPE_GUARANTEED
SERVICETYPE_CONTROLLED_LOAD
SERVICETYPE_BESTEFFORT
SERVICETYPE_QUALITATIVE
準拠していないトラフィック
簡単な例として、特定のネットワーク デバイスがリソースに境界があり、上記のいずれかの ServiceType 設定からパケットを送信することを選択する必要がある場合、最初にSERVICETYPE_NETWORKCONTROLのパケットを送信し、その ServiceType のパケットが送信を必要としない場合は、 ServiceType SERVICETYPE_GUARANTEED のパケットを送信します。
MaxSduSize
トラフィック フローで許可または使用される最大パケット サイズをバイト単位で指定します。
MinimumPolicedSize
要求されたサービス品質を提供する最小パケット サイズをバイト単位で指定します。 このサイズより小さいパケットは、トラフィック制御によって MinimumPolicedSize として扱われます。 FLOWSPEC 構造体を RSVP と関連付けて使用する場合、MinimumPolicedSize の値を 0 にすることはできません。ただし、特に TC API で FLOWSPEC 構造体を使用している場合は、MinimumPolicedSize を 0 に設定できます。
注釈
FLOWSPEC 構造体の多くのメンバーは、メンバーを QOS_NOT_SPECIFIED に設定することで既定値に設定できます。 デフォルト値に設定できるメンバーは、FLOWSPEC が受信側 FLOWSPECか送信側FLOWSPEC かによって異なります。
トラフィック制御で FLOWSPEC を使用する場合は、いくつかの考慮事項に留意する必要があります。
- TokenRate は、SERVICETYPE_NETWORKCONTROL、SERVICETYPE_QUALITATIVE、SERVICETYPE_BESTEFFORTに対してQOS_NOT_SPECIFIEDできます。 TokenRate は、他のすべての ServiceType 値に対して有効である必要があります。
- PeakBandwidth を指定する場合は、TokenRate 以上である必要があります。
- 制御されたロード・サービス・レシーバーの場合、デフォルト値は送信側 TSPEC から派生します。
- 保証されたサービス レシーバーの場合は、 ServiceType と TokenRate を 指定する必要があります。
ServiceType の値が SERVICETYPE_GUARANTEED に設定されている場合は、次も適用されます。
- RSPEC の RATE 値は TokenRate の値に設定されます。
- RSPEC の DELAYSLACKTERM 値は DelayVariation に設定され、DelayVariation が QOS_NOT_SPECIFIED に設定されている場合は 0 に設定されます。
- SERVICETYPE_GUARANTEEDを要求する受信側の場合は、受信側 の TokenRate を 指定する必要があります。 これは、 TokenRate をQOS_NOT_SPECIFIEDに設定できるSERVICETYPE_CONTROLLEDLOAD レシーバーとは対照的です。
トラフィック制御: 次の ServiceTypeは、特に Traffic Control を使用する場合は無効です。 Traffic Control を直接操作しているかどうかわからない場合 (そのため、次の ServiceTypeが状況に適用されるかどうかについて懸念する必要がある場合)、次の操作は行わない可能性があります。
- SERVICE_NO_TRAFFIC_CONTROL
- SERVICE_NO_QOS_SIGNALING
- SERVICETYPE_GENERAL_INFORMATION
- SERVICETYPE_NETWORK_UNAVAILABLE
- SERVICETYPE_NOCHANGE
- SERVICETYPE_NOTRAFFIC
要件
| 要件 | 値 |
|---|---|
| サポートされている最小のクライアント | Windows 2000 Professional [デスクトップ アプリのみ] |
| サポートされている最小のサーバー | Windows 2000 Server [デスクトップ アプリのみ] |
| Header | qos.h |
こちらもご覧ください
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示