[要約] RFC 2688は、低速ネットワークにおける統合サービスのマッピングに関する規格であり、要約すると以下のようになります。1. 低速ネットワークにおける統合サービスのマッピングに関する規格。 2. 低速ネットワークでの統合サービスの実装と相互運用性を向上させるためのガイドライン。 3. 低速ネットワークにおける統合サービスの効果的な利用を促進するための目的を持つ規格。
Network Working Group S. Jackowski
Request for Comments: 2688 Deterministic Networks
Category: Standards Track D. Putzolu
Intel Architecture Labs
E. Crawley
Argon Networks
B. Davie
Cisco Systems
September 1999
Integrated Services Mappings for Low Speed Networks
低速ネットワーク用の統合サービスマッピング
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 (1999). All Rights Reserved.
Copyright（c）The Internet Society（1999）。無断転載を禁じます。
Abstract
概要
A set of companion documents describe an architecture for providing integrated services over low-bitrate links, such as modem lines, ISDN B-channels, and sub-T1 links [1, 2, 3, 4]. The main components of the architecture are: a set of real-time encapsulation formats for asynchronous and synchronous low-bitrate links, a header compression architecture optimized for real-time flows, elements of negotiation protocols used between routers (or between hosts and routers), and announcement protocols used by applications to allow this negotiation to take place.
一連のコンパニオンドキュメントは、モデムライン、ISDN Bチャネル、およびSUB-T1リンク[1、2、3、4]などの低ビトレートリンクを介して統合サービスを提供するためのアーキテクチャを説明しています。アーキテクチャの主なコンポーネントは次のとおりです。非同期および同期性低双性リンクのリアルタイムカプセル化形式、リアルタイムフロー用に最適化されたヘッダー圧縮アーキテクチャ、ルーター（またはホストとルーター）間で使用されるネゴシエーションプロトコルの要素、およびこの交渉を行うためにアプリケーションで使用される発表プロトコル。
This document defines the service mappings of the IETF Integrated Services for low-bitrate links, specifically the controlled load [5] and guaranteed [6] services. The approach takes the form of a set of guidelines and considerations for implementing these services, along with evaluation criteria for elements providing these services.
このドキュメントでは、低ビトレートリンクのIETF統合サービス、特に制御された負荷[5]および保証[6]サービスのサービスマッピングを定義します。このアプローチは、これらのサービスを実装するためのガイドラインと考慮事項のセットと、これらのサービスを提供する要素の評価基準の形式を取ります。
In addition to the "best-effort" services the Internet is well-known for, other types of services ("integrated services") are being developed and deployed in the Internet. These services support special handling of traffic based on bandwidth, latency, and other requirements that cannot usually be met using "best-effort" service.
インターネットがよく知られている「ベストエフォルト」サービスに加えて、他のタイプのサービス（「統合サービス」）が開発され、インターネットで展開されています。これらのサービスは、帯域幅、待ち時間、および通常「ベストエフォルト」サービスを使用して満たすことができないその他の要件に基づいたトラフィックの特別な取り扱いをサポートしています。
This document defines the mapping of integrated services "controlled load" [5] and "guaranteed" [6] services on to low-bandwidth links. The architecture and mechanisms used to implement these services on such links are defined in a set of companion documents. The mechanisms defined in these documents include both compression of flows (for bandwidth savings) [4,10] and a set of extensions to the PPP protocol which permit fragmentation [2] or suspension [3] of large packets in favor of packets from flows with more stringent service requirements.
このドキュメントでは、統合サービス「制御負荷」[5]および「保証」[6]サービスの低帯域幅リンクへのマッピングを定義します。このようなリンクにこれらのサービスを実装するために使用されるアーキテクチャとメカニズムは、一連のコンパニオンドキュメントで定義されています。これらのドキュメントで定義されているメカニズムには、フローの圧縮（帯域幅の節約用）[4,10]と、Flowsからのパケットを支持する大きなパケットの断片化[2]またはサスペンション[3]を許可するPPPプロトコルの拡張セットの両方が含まれます。より厳しいサービス要件を備えています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [11].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC 2119 [11]に記載されているように解釈される。
Unlike other link layers, the links referred to in this document operate only over low speed point to point connections. Examples of the kinds of links addressed here include dial-up lines, ISDN channels, and low-speed (1.5Mbps or less) leased lines. Such links can occur at different positions within the end-to-end path:
他のリンクレイヤーとは異なり、このドキュメントで言及されているリンクは、低速ポイントからポイント接続のみを超えて動作します。ここで説明するリンクの種類の例には、ダイヤルアップライン、ISDNチャネル、および低速（1.5Mbps以下）リースラインが含まれます。このようなリンクは、エンドツーエンドパス内の異なる位置で発生する可能性があります。
- host to directly connected host. - host to/from network access device (router or switch). - Edge device (subnet router or switch) to/from router or switch. - In rare circumstances, a link from backbone router to backbone router.
- 直接接続されたホストのホスト。 - ネットワークアクセスデバイス（ルーターまたはスイッチ）のホスト。 - ルーターまたはスイッチから/からのエッジデバイス（サブネットルーターまたはスイッチ）。 - まれな状況では、バックボーンルーターからバックボーンルーターへのリンク。
These links often represent the first or last wide area hop in a true end to end service. Note that these links may be the most bandwidth constrained along the path between two hosts.
これらのリンクは、多くの場合、真のエンドトゥエンドサービスで最初または最後のワイドエリアホップを表します。これらのリンクは、2つのホスト間のパスに沿って制約される最も帯域幅である可能性があることに注意してください。
The services utilized in mapping integrated services to these links are only provided if both endpoints on the link support the architecture and mechanisms referenced above. Support for these mechanisms is determined during the PPP negotiation. The non-shared nature of these links, along with the fact that point-to-point links are typically dual simplex (i.e., the send and receive channels are separate) allows all admission control decisions to be made locally.
これらのリンクへの統合サービスのマッピングに使用されるサービスは、リンク上の両方のエンドポイントが上記のアーキテクチャとメカニズムをサポートしている場合にのみ提供されます。これらのメカニズムのサポートは、PPP交渉中に決定されます。これらのリンクの非恥ずかしさの性質と、ポイントツーポイントリンクが通常デュアルシンプレックスであるという事実（つまり、送信チャネルと受信チャネルは個別です）により、すべての入場制御決定をローカルで行うことができます。
As described in [2] and [3], for systems that can exert real time control of their transmission at a finer grain than entire HDLC frames, the suspend/resume approach optimizes the available bandwidth by minimizing header overhead associated with MLPPP pre-fragmentation and can provide better delay. However, this comes at the expense of preparing all outgoing data and scanning all incoming data for suspend/resume control information. The fragmentation approach can be implemented without additional scanning of the data stream (beyond bit-/byte-stuffing, which may be in hardware) and is applicable to systems which provide only frame-oriented transmission control. Choice of suspend/resume versus fragmentation should be made based on the level of transmission control, the element's capability to handle the HDLC-like framing described in [2], and the system overhead associated with byte by byte scanning (required by suspend/resume).
[2]および[3]で説明されているように、HDLCフレーム全体よりも細かい穀物でのトランスミッションのリアルタイム制御を発揮できるシステムについては、MLPPPのプレラグ化に関連するヘッダーオーバーヘッドを最小化することにより、利用可能な帯域幅を最適化します。より良い遅延を提供できます。ただし、これは、すべての発信データを準備し、停止/履歴書制御情報のすべての着信データをスキャンすることを犠牲にして行われます。フラグメンテーションアプローチは、データストリームの追加スキャンなしで実装できます（ハードウェアにある可能性のあるビット/バイトストーフィングを超えて）、フレーム指向の伝送制御のみを提供するシステムに適用できます。一時停止/履歴書と断片化の選択は、送信制御のレベル、[2]で説明されているHDLCのようなフレーミングを処理する要素の機能、およびバイトスキャンによるバイトに関連付けられたシステムオーバーヘッドに基づいて行う必要があります（一時停止/履歴書で必要です）。
To provide controlled load or guaranteed service with the suspend/resume approach, when a packet for an admitted flow (QoS packet) arrives during transmission of a best effort packet and continued transmission of the best effort packet would violate delay constraints of the QoS service flows, the best effort packet is preempted, the QoS packet/fragments are added to the transmission, and the best effort packet transmission is then resumed: usually all in one transmission. The receiving station separates the best effort packet from the embedded QoS packet's fragments. It is also conceivable that one QoS flow's packet might suspend another flow's packet if the delivery deadline of the new packet is earlier than the current packet.
一時停止/履歴書アプローチで制御された負荷または保証サービスを提供するために、最良の努力パケットの送信中に入院フロー（QOSパケット）のパケットが到着し、最適な努力パケットの継続的な送信がQoSサービスフローの遅延制約に違反すると、最良の努力パケットが先制され、QoSパケット/フラグメントが送信に追加され、最良のパケット送信が再開されます。通常はすべて1つの伝送です。受信ステーションは、最良の努力パケットを埋め込まれたQoSパケットのフラグメントから分離します。また、新しいパケットの配信期限が現在のパケットよりも早い場合、1つのQoSフローのパケットが別のフローのパケットを停止する可能性があると考えられます。
For systems which use fragmentation, any packets longer than the maximum tolerable delay for packets from enhanced service flows are fragmented prior to transmission so that a short packet for another flow can be interleaved between fragments of a larger packet and still meet the transmission deadline for the flow requiring enhanced services.
断片化を使用するシステムの場合、拡張されたサービスフローからのパケットの最大許容遅延よりも長いパケットが送信前に断片化されるため、別のフローの短いパケットは、より大きなパケットのフラグメント間でインターリーブし、それでも送信期限を満たすことができます。強化されたサービスを必要とするフロー。
Note that the fragmentation discussed in this document refers to multilink PPP (MLPPP) fragmentation and associated MCMLPPP modifications as described in [2], not IP or other layer 3 fragmentation. MLPPP fragmentation is local to the PPP link, and does not affect end-to-end (IP) MTU.
このドキュメントで説明した断片化は、[2]で説明されているように、IPまたは他のレイヤー3の断片化ではなく、[2]で説明されているMultiLink PPP（MLPPP）断片化と関連するMCMLPPPの変更を指します。MLPPPフラグメンテーションはPPPリンクにローカルであり、エンドツーエンド（IP）MTUには影響しません。
A router which provides Controlled Load or Guaranteed Service over a low speed serial link needs to have some notion of the "acceptable delay" for packets that belong to int-serv flows. If using fragmentation, a router needs to know what size to fragment packets to; if using suspend/resume, it needs to know when it is appropriate to suspend one packet to meet the delay goals of another.
低速シリアルリンクを介して制御された負荷または保証サービスを提供するルーターは、Int-Servフローに属するパケットの「許容可能な遅延」の概念を持つ必要があります。断片化を使用する場合、ルーターはパケットをフラグメントするサイズを知る必要があります。一時停止/履歴書を使用している場合、別のパケットの遅延目標を満たすために、1つのパケットを一時停止することがいつ適切であるかを知る必要があります。
Unfortunately, there is no hard and fast way for a single delay bound to be determined for a particular flow; while the end-points of a flow have enough information to determine acceptable end-to-end delay bounds and to make reservation requests of the network to meet those bounds, they do not communicate a "per-hop" delay to routers.
残念ながら、特定のフローに対して決定される単一の遅延が決定されるための困難で高速な方法はありません。フローのエンドポイントには、許容可能なエンドツーエンドの遅延境界を決定し、それらの境界を満たすためにネットワークの予約要求を行うのに十分な情報がありますが、ルーターに「ホップごと」遅延を伝えません。
In the case of Guaranteed Service [6], one approach is to let the network operator configure parameters on the router that will directly affect its delay performance. We observe that guaranteed service allows routers to deviate from the ideal fluid flow model and to advertise the extent of the deviation using two error terms C and D, the rate-dependent and rate-independent error terms, defined in [6]. A network operator can configure parameters of the low speed link in such a way that D is set to a value of her choice.
保証されたサービス[6]の場合、1つのアプローチは、ネットワークオペレーターに、遅延パフォーマンスに直接影響するルーター上のパラメーターを構成できるようにすることです。保証されたサービスにより、ルーターは理想的な流体フローモデルから逸脱し、[6]で定義されているレート依存およびレートに依存しない誤差項である2つのエラー項CとDを使用して、偏差の範囲を宣伝できることが観察されます。ネットワークオペレーターは、Dが選択の値に設定されるように、低速リンクのパラメーターを構成できます。
If link-level fragmentation is used, the router controlling a low-speed link can be configured with a certain fragment size. This will enable a component of the error term D to be calculated based on the time to send one fragment over the link. (Note that D may have other components such as the speed of light delay over the link.) Details of the calculation of D are described below. Similarly, if suspend/resume is used, the router may be configured with a delay parameter, which would enable it to decide when it was appropriate to suspend a packet.
リンクレベルの断片化を使用すると、低速リンクを制御するルーターを特定のフラグメントサイズで構成できます。これにより、リンク上に1つのフラグメントを送信する時間に基づいて、エラー項Dのコンポーネントを計算できます。（Dは、リンク上の光遅延速度など、他のコンポーネントがある場合があることに注意してください。）Dの計算の詳細については、以下に説明します。同様に、一時停止/履歴書を使用すると、ルーターが遅延パラメーターで構成されている場合があります。これにより、パケットを一時停止するのがいつ適切かを決定できるようになります。
For Controlled Load, there are no error terms, and the router must decide how best to meet the requirements of the admitted reservations using only the information in their TSpecs. Since the definition of Controlled Load states that a CL flow with Tspec rate r should receive treatment similar to an unloaded network of capacity r, CL packets should not generally experience end-to-end delays significantly greater than b/r + propagation delays. Clearly a router connected to a low speed link should not introduce a delay greater than b/r due to transmission of other fragments; ideally it should introduce substantially less delay than b/r, since other hops on the end-to-end path may introduce delay as well. However, this may be difficult for flows with very small values of b.
制御された負荷の場合、エラー項はありません。ルーターは、TSPECの情報のみを使用して、入院した予約の要件を満たす最善の方法を決定する必要があります。制御された負荷の定義は、TSPECレートrのCLフローが容量rの無負荷ネットワークと同様の処理を受けるべきであると述べているため、CLパケットは一般に、B/Rの伝播遅延よりも大幅に大きいエンドツーエンドの遅延を発生させるべきではありません。明らかに、低速リンクに接続されているルーターは、他のフラグメントの送信のためにB/Rより大きい遅延を導入してはなりません。理想的には、エンドツーエンドのパス上の他のホップも遅延を導入する可能性があるため、B/Rよりも大幅に遅延が少ないはずです。ただし、これはbの値が非常に少ないフローでは難しい場合があります。
It is expected that implementers will make their own tradeoffs as to how low to make the delay for Controlled Load flows. Similarly, it may not be possible or desirable to configure the parameters affecting D to arbitrarily small values, since there is a cost in overhead in fragmenting packets to very small sizes. Conversely, if D is too large, some applications may find that they cannot make a reservation that will meet their delay objectives.
制御された負荷の流れの遅延をどの程度低くするかについて、実装者が独自のトレードオフを行うことが期待されています。同様に、非常に小さなサイズに断片化するパケットのオーバーヘッドにコストがあるため、Dから任意の小さな値に影響するパラメーターを構成することは不可能または望ましくない場合があります。逆に、Dが大きすぎる場合、一部のアプリケーションは、遅延目標を満たす予約を行うことができないことがわかります。
For the remainder of this document, we assume that a router has some notion of the acceptable delay that it may introduce before beginning transmission of a packet. This delay is in addition to any delay that a packet might be subjected to as a result of the "ideal" queuing algorithm that the router uses to schedule packets.
このドキュメントの残りの部分では、パケットの送信を開始する前に導入する可能性のある許容可能な遅延の概念がルーターにあると想定しています。この遅延は、ルーターがパケットをスケジュールするために使用する「理想的な」キューイングアルゴリズムの結果として、パケットが受けられる可能性のある遅延に追加されます。
Supporting integrated services over PPP links which implement MCML or RTF can be accomplished in several ways. Guidelines for mapping these services to PPP links and to the classes provided by the suspend/resume and fragmentation mechanisms are presented below. Note that these guidelines assume that some sort of signaling protocol is used to indicate desired quality of service to both the sender and receiver of a flow over a PPP link.
MCMLまたはRTFを実装するPPPリンクを介した統合サービスをサポートすることは、いくつかの方法で達成できます。これらのサービスをPPPリンクおよび一時停止/履歴書および断片化メカニズムによって提供されるクラスにマッピングするためのガイドラインを以下に示します。これらのガイドラインは、何らかの種類のシグナル伝達プロトコルが、PPPリンク上のフローの送信者と受信者の両方に望ましいサービス品質を示すために使用されることを想定していることに注意してください。
A relatively simple method of class mapping that MAY be used is one where class values correspond to predefined levels of service. In this arrangement, all admitted flows are grouped into one of several buckets, where each bucket roughly corresponds to the level of service desired for the flows placed in it. An example set of mappings appears below:
使用できるクラスマッピングの比較的単純な方法は、クラス値が事前定義されたレベルのサービスに対応する方法です。この配置では、認められたすべてのフローはいくつかのバケツの1つにグループ化され、各バケツは、その中に配置されたフローに対して望ましいサービスのレベルにほぼ対応しています。マッピングの例を以下に示します。
MCML Short MCML Long RTF Service
MCMLショートMCMLロングRTFサービス
0b00 0b0000 0b000 Best Effort
NA 0b0001 0b001 Reserved
0b01 0b0010 0b010 Delay Sensitive, no bound
NA 0b0011 0b011 Reserved
NA 0b0100 0b100 Reserved
0b10 0b0101 0b101 Delay Sensitive, 500ms bound
NA 0b0110 0b110 Delay Sensitive, 250ms bound
0b11 0b0111 0b111 Network Control
Table 1: Example Mappings of Classes to Services Note that MCML has two formats, short sequence numbers, and long sequence numbers, that allow for 2 and 4 bits of class identification. RTF allows for 3 bits of class identification in all formats.
表1：サービスへのクラスの例のマッピングの例MCMLには、2つのクラスの識別を可能にする2つの形式、短いシーケンス番号と長いシーケンス番号があることに注意してください。RTFでは、あらゆる形式で3ビットのクラス識別が可能になります。
Using a default-mapping method of assigning classes to flows in a fixed fashion comes with certain limitations. In particular, all flows which fall within a particular bucket (are assigned to a particular class) will be scheduled against each other at the granularity of packets, rather than at the finer grained level of fragments. This can result in overly conservative admission control when the number of available classes is small such as in MCML short sequence number format.
クラスを割り当てて固定された方法で流れるデフォルトマッピング方法を使用するには、一定の制限があります。特に、特定のバケツ内に該当するすべてのフロー（特定のクラスに割り当てられます）は、断片の細かいレベルではなく、パケットの粒度で互いにスケジュールされます。これにより、MCMLショートシーケンス番号形式のように、利用可能なクラスの数が少ない場合、過度に保守的な入場制御が発生する可能性があります。
In the case where fewer reservations are expected than the total number of classes negotiated for a PPP link, it is possible to assign individual flows to fixed class numbers. This assignment is useful in the case where the protocol identifier associated with one or more flows is known at LCP negotiation time and the bandwidth of the connection is relatively small. If these conditions hold true, then for those flows that are known, a specific class can optionally be assigned to them and the prefix elision PPP option [2] can be used for those classes to achieve a small bandwidth savings.
PPPリンクのために交渉されたクラスの総数よりも予約が少ない場合、個々のフローを固定クラス番号に割り当てることができます。この割り当ては、1つ以上のフローに関連付けられたプロトコル識別子がLCP交渉時間で知られており、接続の帯域幅が比較的小さい場合に役立ちます。これらの条件が当てはまる場合、既知のフローの場合、特定のクラスをオプションで割り当てることができ、プレフィックスelision PPPオプション[2]を使用して、小さな帯域幅の節約を達成できます。
In the case where predefined class mappings are not satisfactory, an implementer MAY map class values to individual packets rather than assigning flows to fixed classes. This can be done due to the fact that the classes that MCML and RTF provide can be viewed purely as PPP-specific segmentation/fragmentation mechanisms. That is, while the class number MUST remain constant on an intra-packet basis, it MAY vary on an inter-packet basis for all flows transiting a PPP link. Actual assignment of particular flows to fixed classes is unnecessary, as the class numbers are NOT REQUIRED to have any meaning other than in the context of identifying the membership of fragments/segments as part of a single packet. This point is sufficiently important that an example is provided below.
事前定義されたクラスマッピングが満足のいく場合には、実装者が固定クラスにフローを割り当てるのではなく、クラスの値を個々のパケットにマッピングできます。これは、MCMLとRTFが提供するクラスが純粋にPPP固有のセグメンテーション/断片化メカニズムと見なすことができるという事実のために行うことができます。つまり、クラス番号はパケット内ベースで一定のままでなければなりませんが、PPPリンクを通過するすべてのフローのパケット間ベースで異なる場合があります。特定のフローの固定クラスへの実際の割り当ては不要です。クラス番号は、単一のパケットの一部としてフラグメント/セグメントのメンバーシップを識別するコンテキスト以外の意味を持つ必要はないためです。この点は十分に重要であるため、例を以下に示します。
Consider a PPP link using the MCML short sequence number fragment format (that is, four classes are provided). Assume that in addition to carrying best effort traffic, this link is carrying five guaranteed service flows, A, B, C, D, and E. Further assume that the link capacity is 100kbit/s and the latency is 100ms. Finally, assume the BE traffic is sufficient to keep the pipe full at all times and that GS flows A-E are each 10kbit/s and all have delay bounds of 145ms.
MCMLショートシーケンス番号フラグメント形式を使用したPPPリンクを検討してください（つまり、4つのクラスが提供されます）。最善の努力トラフィックの運搬に加えて、このリンクは5つの保証されたサービスフロー、a、b、c、d、およびEを運んでいると仮定します。さらに、リンク容量が100kbit/sであり、レイテンシが100msであると仮定します。最後に、BEトラフィックが常にパイプを完全に保持するのに十分であり、GSフローA-Eはそれぞれ10kbit/sであり、すべてが145msの遅延境界を持っていると仮定します。
Time(ms) Action 0 BE traffic is queued up 0 2kbit fragment from 10kbit packet of BE traffic sent, cls 0 (...) 8 2kbit fragment from BE sent, cls 0 (10kbit BE packet done) 9 8kbit packet from flow A arrives 10 2kbit fragment from A sent, cls 1 (8kbit flow A packet start) 11 8kbit packet from flow B arrives 12 2kbit fragment from B sent, cls 2 (8kbit flow B packet start) 13 8kbit packets from flows C, D, and E arrive 14 2kbit fragment from C sent, cls 3 (8kbit flow C packet start) 16 2kbit fragment from D sent, cls 0 (8kbit flow D packet start) 18 2kbit fragment from A sent, cls 1 20 2kbit fragment from B sent, cls 2 22 2kbit fragment from A sent, cls 1 24 2kbit fragment from A sent, cls 1 (8kbit flow A packet done) 26 2kbit fragment from E sent, cls 1 (8kbit flow E packet start) 27 8kbit packet from flow A arrives 28 2kbit fragment from B sent, cls 2 30 2kbit fragment from C sent, cls 3 32 2kbit fragment from E sent, cls 1 34 2kbit fragment from B sent, cls 2 (8kbit flow B packet done) 36 2kbit fragment from E sent, cls 1 38 2kbit fragment flow A sent, cls 2 (8kbit flow A packet start) (etc.)
時間（ms）アクション0トラフィックは、10kbitのトラフィック送信の10kbitパケットからキューにキューに巻き込まれます。送信されたAから10の2kbitフラグメント、CLS 1（8kbit Flow Aパケットスタート）e到着Cが送信されたCから14 2kbitフラグメント、CLS 3（8kbit Flow Cパケット開始）16 2kbitフラグメントD送信、CLS 0（8Kbit Flow Dパケットスタート）cls 2 22 2kbit fragment from a sent、cls 1 24 2kbitフラグメント送信、Cls 1（8kbit flow Aパケットが完了）28 2 kbit fragment from b from b、cls 2 30 2kbit fragment from c sent、cls 3 32 2kbit fragment from e sent、cls 1 34 2kbitフラグメントは、c cls 2（8kbit flow bパケットが完了）CLS 1 38 2Kbitフラグメントフローa送信、CLS 2（8kbitフローパケットスタート）（etc.）
This example shows several things. First, multiple flows MAY share the same class, particularly in the case where there are more flows than classes. More importantly, there is no reason that a particular flow must be assigned to a fixed class - the only requirement is that each packet, when fragmented, MUST have the same class value assigned to all fragments. Beyond this requirement the link scheduler may assign individual to changing class numbers as necessary to meet reservation requirements.
この例はいくつかのことを示しています。第一に、特にクラスよりも多くのフローがある場合、複数のフローが同じクラスを共有する場合があります。さらに重要なことに、特定のフローを固定クラスに割り当てる必要がある理由はありません。唯一の要件は、各パケットが断片化されている場合、すべてのフラグメントに同じクラス値を割り当てなければならないことです。この要件を超えて、リンクスケジューラは、予約要件を満たすために必要に応じて、個別をクラス番号の変更に割り当てることができます。
One suggestion to implementers of integrated services on MCML and RTF links using dynamic mappings is that all BE traffic SHOULD be logically separated from QoS traffic, and mapped to a fragmentable (MCML classes 0-3 in short sequence number fragment format, 0-15 in long sequence number fragment format) or suspendable (RTF classes 0- 6) class. Since BE traffic will in most implementations not be scheduled for transmission except when a link is empty (that is, no CL or GS traffic is ready for transmission), implementers MAY choose to make use of class number 0 for BE traffic.
動的マッピングを使用したMCMLおよびRTFリンクの統合サービスの実装者への提案の1つは、すべてのトラフィックをQoSトラフィックから論理的に分離し、断片可能なものにマッピングする必要があることです（MCMLクラス0-3では、ショートシーケンス数フラグメント形式で、0-15インチ長いシーケンス番号フラグメント形式）またはサスペンド可能（RTFクラス0〜6）クラス。ほとんどの実装では、リンクが空の場合（つまり、CLまたはGSトラフィックが送信の準備ができていない場合）を除いて、ほとんどの実装が送信が予定されていないため、実装者はトラフィックのためにクラス番号0を使用することを選択できます。
Treatment of non-conformant QoS traffic is largely determined by the appropriate service specifications, but the detailed implementation in the context of this draft allows for some flexibility. Policing of flows containing non-conformant traffic SHOULD always be done at the level of granularity of individual packets rather than at a finer grained level. In particular, in those cases where a network element scheduling flows for transmission needs to drop non-conformant traffic, it SHOULD drop entire packets rather than dropping individual fragments of packets belonging to non-conformant traffic. In those cases where a network element forwards non-conformant traffic when link bandwidth is available rather than dropping the traffic, the implementation SHOULD fragment packets of such traffic as if it were best effort traffic.
不適合なQoSトラフィックの処理は、主に適切なサービス仕様によって決定されますが、このドラフトのコンテキストでの詳細な実装により、ある程度の柔軟性が可能になります。不適合トラフィックを含むフローのポリシングは、より細かい粒子レベルではなく、個々のパケットの粒度のレベルで常に行う必要があります。特に、伝送のためのネットワーク要素のスケジューリングが不適合なトラフィックを削除する必要がある場合、不適合トラフィックに属するパケットの個々のフラグメントをドロップするのではなく、パケット全体をドロップする必要があります。ネットワーク要素がトラフィックをドロップするのではなく、リンク帯域幅を使用できるときに不適合なトラフィックを転送する場合、実装はそのようなトラフィックのパケットを最適なトラフィックであるかのように断片化する必要があります。
Whether BE and non-conformant traffic are treated differently in regards to transmission (e.g., BE is given priority access over non-conformant traffic to the link) or whether within each type of traffic special treatment is afforded to individual flows (e.g., WFQ, RED, etc.) is service dependent.
伝播に関しては、伝染性と非変性のトラフィックの扱いが異なるかどうか（たとえば、リンクへの不適合トラフィックよりも優先アクセスが与えられます）、または各タイプのトラフィック内で特別な処理が個々のフローに与えられるかどうか（例：WFQ、赤など）はサービス依存です。
An important consideration in performing admission control for PPP links is reductions in effective link rate due to bit stuffing. Typical bit stuffing algorithms can result in as much as 20% additional overhead. Thus, admission control implementations for guaranteed service over links where bit stuffing is used SHOULD take the RSpec rate of all flows and multiply by 1.2, to account for the 20% overhead from bit stuffing, when determining whether a new flow can be admitted or not. Admission control implementations for controlled load reservations may use a similar algorithm using the TSpec peak rate or may attempt to measure the actual degree of expansion occurring on a link due to bit stuffing. This characterization can then be used to adjust the calculated remaining link capacity. Such measurements must be used cautiously, in that the degree of bit stuffing that occurs may vary significantly, both in an inter- and intra-flow fashion.
PPPリンクの入場制御を実行する際の重要な考慮事項は、ビット詰め物による効果的なリンクレートの削減です。典型的なビットスタッフィングアルゴリズムは、最大20％のオーバーヘッドになる可能性があります。したがって、ビット詰め物が使用されるリンクを介した保証されたサービスの入場制御の実装は、すべてのフローのRSPECレートを取得し、1.2を掛けて、新しいフローを認められるかどうかを判断する際に、ビット詰め物から20％のオーバーヘッドを説明する必要があります。。制御された荷重予約のための入場制御の実装は、TSPECピークレートを使用して同様のアルゴリズムを使用したり、ビットの詰め物のためにリンクで発生する拡張の実際の程度を測定しようとする場合があります。この特性評価を使用して、計算された残りのリンク容量を調整できます。このような測定値は、発生するビット詰め物の程度が、流量間の両方で大きく異なる場合があるという点で慎重に使用する必要があります。
Byte stuffing is also used on many PPP links, most frequently on POTS modems when using the v.42 protocol. Byte stuffing poses a difficult problem to admission control, particularly in the case of guaranteed service, due to its highly variable nature. In the worse case, byte stuffing can result in a doubling of frame sizes. As a consequence, a strict implementation of admission control for guaranteed load on byte stuffed PPP links SHOULD double the RSpec of link traffic in making flow admission decisions. As with bit stuffing, implementations of controlled load service admission control algorithms for links with byte stuffing MAY attempt to determine average packet expansion via observation or MAY use the theoretical worst case values.
バイトスタッピングは、V.42プロトコルを使用する場合、多くのPPPリンクでも使用されます。最も頻繁にPOTSモデムで使用されます。バイトスタッピングは、特にその非常に多様な性質のために、保証されたサービスの場合に、入場制御に困難な問題をもたらします。最悪の場合、バイトスタッピングはフレームサイズを2倍にする可能性があります。結果として、バイト詰め物PPPリンクの保証負荷のための入場制御の厳密な実装は、フロー入場の決定を下す際にリンクトラフィックのRSPECを2倍にするはずです。ビット詰め物と同様に、バイトスタッピングとのリンクの制御されたロードサービス入場制御アルゴリズムの実装は、観測による平均パケット拡張を決定しようとするか、理論的な最悪のケース値を使用する場合があります。
The architecture for providing integrated services over low bandwidth links uses several PPP options to negotiate link configuration as described in [4, 8, 10]. When deciding whether to admit a flow, admission control MUST compute the impact of the following on MTU size, rate, and fragment size:
[帯域幅の低いリンクを介して統合サービスを提供するためのアーキテクチャは、[4、8、10]で説明されているように、いくつかのPPPオプションを使用してリンク構成をネゴシエートします。フローを認めるかどうかを決定するとき、入場制御は、MTUのサイズ、レート、およびフラグメントサイズに次の影響を計算する必要があります。
Header compression: Van Jacobson or Casner-Jacobson [4,8,10]. Prefix Elision. CCP. Fragment header option used. Fragmentation versus suspend/resume approach.
ヘッダー圧縮：Van JacobsonまたはCasner-Jacobson [4,8,10]。プレフィックスエリジョン。CCP。使用されるフラグメントヘッダーオプション。断片化と中断/履歴書のアプローチ。
If any of the compression options are implemented for the connection, the actual transmission rate, and thus the bandwidth required of the link, will be reduced by the compression method(s) used.
接続のために圧縮オプションのいずれかが実装されている場合、実際の透過率、したがってリンクに必要な帯域幅は、使用される圧縮方法によって削減されます。
Prefix elision can take advantage of mapping flows to MLPPP classes to elide prefixes which cannot be compressed at higher layers. By establishing agreement across the link, the sender may elide a prefix for a certain class of traffic and upon receiving packets in that class, the receiver can restore the prefix.
プレフィックスelisionは、MLPPPクラスへのフローのマッピングを活用して、高層では圧縮できないプレフィックスを削除できます。リンク全体に合意を確立することにより、送信者は特定のクラスのトラフィックのプレフィックスを排除し、そのクラスでパケットを受信すると、受信者はプレフィックスを復元できます。
Both compression gain and elision gain MUST be included as described in the admission control section below. Note that the ability to perform compression at higher layers (e.g. TCP or RTP/UDP) may depend on the provision of a hint by the sender, as described in [9].
圧縮ゲインとエリジョンゲインの両方を含める必要があります。[9]で説明されているように、高層（TCPまたはRTP/UDPなど）で圧縮を実行する機能（TCPまたはRTP/UDPなど）が送信者によるヒントの提供に依存する可能性があることに注意してください。
Admission control MUST decide whether to admit a flow based on rate and delay. Assume the following:
入場管理は、レートと遅延に基づいてフローを認めるかどうかを決定する必要があります。以下を想定してください。
LinkRate is the rate of the link. MTU is the maximum transmission unit from a protocol. MRU is the maximum receive unit for a particular link. CMTU is the maximum size of the MTU after compression is applied. eMTU is the effective size at the link layer of an MTU-sized packet after link layer fragmentation and addition of the fragment headers. FRAG is the fragment size including MLPPP header/trailers.
LinkRateはリンクのレートです。MTUは、プロトコルからの最大送信ユニットです。MRUは、特定のリンクの最大受信ユニットです。CMTUは、圧縮が適用された後のMTUの最大サイズです。EMTUは、リンクレイヤーの断片化とフラグメントヘッダーの追加後のMTUサイズのパケットのリンク層の有効サイズです。フラグは、MLPPPヘッダー/トレーラーを含むフラグメントサイズです。
Header is the size of the header/trailers/framing for MLPPP/Fragments. pHeader is the additional header/framing overhead associated with suspend/resume. This should include FSE and worst case stuffing overhead. pDelay is the time take to suspend a packet already "in flight", e.g. due to the delay to empty the output FIFO. b is the bucket depth in bytes R is the requested Rate. Dlink is the fixed overhead delay for the link (Modem, DSU, speed-of-light, etc). eRate is the effective rate after compression and fragmentation.
ヘッダーは、MLPPP/フラグメントのヘッダー/トレーラー/フレーミングのサイズです。Pheaderは、サスペンド/履歴書に関連する追加のヘッダー/フレーミングオーバーヘッドです。これには、FSEと最悪のケースのオーバーヘッド詰め物を含める必要があります。Pdelayは、すでに「飛行中」にパケットを一時停止する時間です。出力FIFOを空にするのが遅いため。bはバケットの深さで、バイトの深さは要求されたレートです。DLINKは、リンクの固定オーバーヘッド遅延（モデム、DSU、ライト速度など）です。エレートは、圧縮と断片化後の有効な速度です。
The Dlink term MAY be configured by an administrative tool once the network is installed; it may be determined by real-time measurement means; or it MAY be available from hardware during link setup and/or PPP negotiation. Refer to Appendix A for more considerations on PPP link characteristics and delays.
DLINK用語は、ネットワークがインストールされると、管理ツールによって構成される場合があります。リアルタイム測定手段によって決定される場合があります。または、リンクのセットアップやPPP交渉中にハードウェアから利用できる場合があります。PPPリンクの特性と遅延に関する詳細については、付録Aを参照してください。
Admission control MUST compute CMTU, eMTU, and eRate for Controlled Load Service, and it MUST compute CMTU, eMTU, eRate, and D for Guaranteed Service:
入場制御は、制御された負荷サービスのためにCMTU、EMTU、および環境を計算する必要があり、保証されたサービスのためにCMTU、EMTU、ERATE、およびDを計算する必要があります。
To determine whether the requested rate is available, Admission Control MUST compute the effective rate of the request (eRate) - worst case - as follows:
要求されたレートが利用可能かどうかを判断するには、入学制御がリクエストの有効レート（ERATE） - 最悪の場合 - 次のように計算する必要があります。
#_of_Fragments = CMTU div (FRAG-Header) [Integer divide] Last_Frag_Size = CMTU mod (FRAG-Header
#_of_fragments = cmtu div（frag-header）[integer divition] last_frag_size = cmtu mod（frag-header
If Last_Frag_Size != 0
eMTU = (#_of_Fragments) * FRAG + Last_Frag_Size + Header
Else
eMTU = (#_of_Fragments) * FRAG
eRate = eMTU/CMTU * R [floating point divide]
erate = emtu/cmtu * r [浮動小数点分裂]
Admission control SHOULD compare the eRate of the request against the remaining bandwidth available to determine if the requested rate can be delivered.
入場制御は、要求された料金を配信できるかどうかを判断するために、利用可能な残りの帯域幅との要求の断線を比較する必要があります。
For Controlled Load Service, a flow can be admitted as long as there is sufficient bandwidth available (after the above computation) to meet the rate requirement, and if there is sufficient buffer space (sum of the token bucket sizes does not exceed the buffer capacity). While some statistical multiplexing could be done in computing admissibility, the nature of the low-bitrate links could make this approach risky as any delay incurred to address a temporary overcommitment could be difficult to amortize.
制御された負荷サービスの場合、レート要件を満たすのに十分な帯域幅（上記の計算の後）があり、十分なバッファースペースがある場合（トークンバケットサイズの合計がバッファ容量を超えない場合、フローを入れることができます。）。コンディショニングのコンピューティングでは統計的多重化を行うことができますが、低ビトレートリンクの性質により、一時的な過剰コミットメントに対処するために発生した遅延を償却するのが難しいため、このアプローチが危険にさらされる可能性があります。
Guaranteed Service requires the calculation of C and D error terms. C is a rate-dependent error term and there are no special considerations affecting its calculation in the low-speed link environment. The D term is calculated from the inherent link delay (Dlink) plus the potential worst case delay due to transmission of another fragment or suspend/resume overhead. Thus, D should be calculated as
保証されたサービスには、CおよびDエラー項の計算が必要です。Cはレート依存の誤差項であり、低速リンク環境での計算に影響を与える特別な考慮事項はありません。D用語は、固有のリンク遅延（DLINK）に加えて、別のフラグメントの透過または一時停止/再開による潜在的な最悪の遅延から計算されます。したがって、dはとして計算する必要があります
D = Dlink + FRAG/LinkRate
d = dlink frag/linkrate
in the case of a fragementing implementation and
狂った実装の場合
D = Dlink + pHeader + pDelay
for a suspend/resume implementation.
一時停止/履歴書の実装用。
We may think of the link scheduler as having two parts, the first of which schedules packets for transmission before passing them to the second part of the scheduler -- the link level scheduler -- which is responsible for fragmenting packets, mapping them to classes, and scheduling among the classes.
リンクスケジューラは2つの部分を持っていると考えるかもしれません。最初の部分は、スケジューラの2番目の部分（リンクレベルスケジューラ）に渡す前に送信用のパケットをスケジュールします。クラス間のスケジュール。
In the dynamic class mapping mode of Section 3.3, when deciding which class to assign a packet to, the link level scheduler should take account of the sizes of other packets currently assigned to the same class. In particular, packets with the tightest delay constraints should not be assigned to classes for which relatively large packets are in the process of being transmitted.
セクション3.3の動的クラスマッピングモードでは、パケットを割り当てるクラスを決定するとき、リンクレベルスケジューラは、現在同じクラスに割り当てられている他のパケットのサイズを考慮する必要があります。特に、最もタイトな遅延制約を備えたパケットは、比較的大きなパケットが送信されるプロセスにあるクラスに割り当てられないでください。
In either the dynamic or the static class mapping approach, note that the link-level scheduler SHOULD control how much link bandwidth is assigned to each class at any instant. The scheduler should assign bandwidth to a class according to the bandwidth reserved for the sum of all flows which currently have packets assigned to the class. Note that in the example of Section 3.3, when packets from flows A and E were assigned to the same class (class 1), the scheduler assigned more bandwidth to class 1, reflecting the fact that it was carrying traffic from reservations totaling 20kbit/s while the other classes were carrying only 10kbit/s.
動的クラスマッピングアプローチまたは静的クラスマッピングアプローチのいずれかで、リンクレベルのスケジューラは、任意の瞬間に各クラスに割り当てられるリンク帯域幅の量を制御する必要があることに注意してください。スケジューラは、現在クラスに割り当てられているパケットがあるすべてのフローの合計のために予約された帯域幅に従って、クラスに帯域幅を割り当てる必要があります。セクション3.3の例では、フローAとEのパケットが同じクラス（クラス1）に割り当てられた場合、スケジューラはクラス1により多くの帯域幅を割り当て、合計20kbit/sの予約からトラフィックを運ぶという事実を反映しています。他のクラスは10kbit/sのみを搭載していました。
General security considerations for MLPPP and PPP links are addressed in RFC 1990 [12] and RFC 1661 [13], respectively. Security considerations relevant to RSVP, used as the signaling protocol for integrated services, are discussed in RFC 2209 [14].
MLPPPおよびPPPリンクの一般的なセキュリティ上の考慮事項は、それぞれRFC 1990 [12]およびRFC 1661 [13]で対処されています。統合サービスのシグナリングプロトコルとして使用されるRSVPに関連するセキュリティ上の考慮事項は、RFC 2209で説明されています[14]。
A specific security consideration relevant to providing quality of service over PPP links appears when relying on either observed or theoretical average packet expansion during admission control due to bit- or byte-stuffing. Implementations based on these packet-expansion values contain a potential vulnerability to denial of service attacks. An adversary could intentionally send traffic that will result in worst case bit- or byte stuffing packet expansion. This in turn could result in quality of service guarantees not being met for other flows due to overly permissive admission control. This potential denial of service attack argues strongly for using a worst case expansion factor in admission control calculations, even for controlled load service.
PPPリンクを介したサービスの品質を提供することに関連する特定のセキュリティ検討は、ビットまたはバイトスタッフのために、入学制御中に観測または理論的な平均パケット拡張に依存する場合に表示されます。これらのパケット拡張値に基づく実装には、サービス拒否攻撃に対する潜在的な脆弱性が含まれています。敵は意図的にトラフィックを送信する可能性があり、最悪の場合はビットまたはバイトの詰め物パケット拡張をもたらします。これにより、過度に寛容な入院制御のために他のフローについて満たされていないサービス品質保証が得られる可能性があります。この潜在的なサービス拒否攻撃は、制御された負荷サービスであっても、入場制御計算に最悪のケース拡張係数を使用することについて強く主張しています。
Beyond the considerations documented above, this document introduces no new security issues on top of those discussed in the companion ISSLL documents [1], [2] and [3] and AVT document [4]. Any use of these service mappings assumes that all requests for service are authenticated appropriately.
上記の考慮事項を超えて、このドキュメントでは、コンパニオンISSLLドキュメント[1]、[2]および[3]およびAVT文書[4]で議論されているものの上に新しいセキュリティの問題を紹介しません。これらのサービスマッピングの使用は、すべてのサービス要求が適切に認証されていることを前提としています。
[1] Bormann, C., "Providing Integrated Services over Low-bitrate Links", RFC 2689, September 1999.
[1] Bormann、C。、「低ビトレートリンクを介して統合サービスを提供する」、RFC 2689、1999年9月。
[2] Bormann, C., "The Multi-Class Extension to Multi-Link PPP", RFC 2686, September 1999.
[2] Bormann、C。、「マルチリンクPPPへのマルチクラス拡張」、RFC 2686、1999年9月。
[3] Bormann, C., "PPP in a Real-time Oriented HDLC-like Framing", RFC 2687, September 1999.
[3] Bormann、C。、「リアルタイム指向のHDLCのようなフレーミングのPPP」、RFC 2687、1999年9月。
[4] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999.
[4] Casner、S。およびV. Jacobson、「低速シリアルリンク用のIP/UDP/RTPヘッダーの圧縮」、RFC 2508、1999年2月。
[5] Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC 2211, September 1997.
[5] Wroclawski、J。、「制御されたロードネットワーク要素サービスの仕様」、RFC 2211、1997年9月。
[6] Partridge, C. and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997.
[6] Partridge、C。およびR. Guerin、「保証されたサービス品質の仕様」、RFC 2212、1997年9月。
[7] Shenker, S. and J. Wroclawski, "General Characterization Parameters for Integrated Service Network Elements", RFC 2215, September 1997.
[7] Shenker、S。およびJ. Wroclawski、「統合されたサービスネットワーク要素の一般的な特性評価パラメーター」、RFC 2215、1997年9月。
[8] Jacobson, V., "TCP/IP Compression for Low-Speed Serial Links", RFC 1144, February 1990.
[8] Jacobson、V。、「低速シリアルリンクのTCP/IP圧縮」、RFC 1144、1990年2月。
[9] B. Davie et al. "Integrated Services in the Presence of Compressible Flows", Work in Progress (draft-davie-intserv-compress-00.txt), Feb. 1999.
[9] B.デイビー等。「圧縮性フローの存在下での統合サービス」、作業中の作業（Draft-Davie-Intserv-Compress-00.txt）、1999年2月。
[10] Engan, M., Casner, S. and C. Bormann, "IP Header Compression over PPP", RFC 2509, February 1999.
[10] Engan、M.、Casner、S。、およびC. Bormann、「PPP上のIPヘッダー圧縮」、RFC 2509、1999年2月。
[11] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[11] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[12] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T. Coradettim, "The PPP Multilink Protocol (MP)", RFC 1990, August 1996.
[12] Sklower、K.、Lloyd、B.、McGregor、G.、Carr、D。、およびT. Coradettim、「The PPP Multilink Protocol（MP）」、RFC 1990、1996年8月。
[13] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[13] シンプソン、W。、編集者、「ポイントツーポイントプロトコル（PPP）」、STD 51、RFC 1661、1994年7月。
[14] Braden, R. and L. Zhang, "Resource ReSerVation Protocol (RSVP) -- Version 1 Message Processing Rules", RFC 2209, September 1997.
[14] Braden、R。およびL. Zhang、「リソース予約プロトコル（RSVP） - バージョン1メッセージ処理ルール」、RFC 2209、1997年9月。
Steve Jackowski Deterministic Networks, Inc. 245M Mt Hermon Rd, #140 Scotts Valley, CA 95060 USA
Steve Jackowski Deceinistic Networks、Inc。245m Mt Hermon Rd、＃140 Scotts Valley、CA 95060 USA
Phone: +1 (408) 813 6294
EMail: stevej@DeterministicNetworks.com
David Putzolu Intel Architecture Labs (IAL) JF3-206-H10 2111 NE 25th Avenue Hillsboro, OR 97124-5961 USA
David Putzolu Intel Architecture Labs（IAL）JF3-206-H10 2111 NE 25th Avenue Hillsboro、または97124-5961 USA
Phone: +1 (503) 264 4510
EMail: David.Putzolu@intel.com
Eric S. Crawley Argon Networks, Inc. 25 Porter Road Littleton, MA 01460 USA
エリック・S・クローリー・アルゴンネットワークス、Inc。25ポーターロードリトルトン、マサチューセッツ州01460 USA
Phone: +1 (978) 486-0665
EMail: esc@argon.com
Bruce Davie Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA, 01824 USA
ブルース・デイビー・シスコ・システムズ、Inc。250 Apollo Drive Chelmsford、MA、01824 USA
Phone: +1 (978) 244 8921
EMail: bdavie@cisco.com
Acknowledgements
謝辞
This document draws heavily on the work of the ISSLL WG of the IETF.
このドキュメントは、IETFのISSLL WGの作業に大きく描かれています。
The protocols used in current implementations of POTS modems can exhibit significant changes in link rate and delay over the duration of a connection. Admission control and link scheduling algorithms used with these devices MUST be prepared to compensate for this variability in order to provide a robust implementation of integrated services.
POTSモデムの現在の実装で使用されるプロトコルは、接続期間中にリンクレートと遅延に大きな変化を示す可能性があります。これらのデバイスで使用されている入場制御およびリンクスケジューリングアルゴリズムは、統合サービスの堅牢な実装を提供するために、この変動を補うために準備する必要があります。
Link rate on POTS modems is typically reported at connection time. This value may change over the duration of the connection. The v.34 protocol, used in most POTS modems, is adaptive to link conditions, and is able to recalibrate transmission rate multiple times over the duration of a connection. Typically this will result in a small (~10%) increase in transmission rate over the initial connection within the first minute of a call. It is important to note, however, that other results are possible as well, including decreases in available bandwidth. Admission control algorithms MUST take such changes into consideration as they occur, and implementations MUST be able to gracefully handle the pathological case where link rate actually drops below the currently reserved capacity of a link.
POTSモデムのリンクレートは、通常、接続時に報告されます。この値は、接続の期間中に変更される場合があります。ほとんどのPOTSモデムで使用されるV.34プロトコルは、リンク条件に適応し、接続期間中に伝送速度を複数回再調整できます。通常、これにより、コールの最初の1分以内の初期接続で伝送速度がわずかに増加します。ただし、利用可能な帯域幅の減少など、他の結果も可能であることに注意することが重要です。入場制御アルゴリズムは、そのような変更を考慮して発生する必要があり、実装は、リンクレートが実際にリンクの現在予約済みの容量を下回る病理学的ケースを優雅に処理できる必要があります。
Delay experienced by traffic over POTS modems can vary significantly over time. Unlike link rate, the delay often does not converge to a stable value. The v.42 protocol is used in most POTS modems to provide link-layer reliability. This reliability, which is implemented via retransmission, can cause frames to experience significant delays. Retransmissions also implicitly steal link bandwidth from other traffic. These delays and reductions in link bandwidth make it extremely difficult to honor a guaranteed service reservation. On a link that is actually lightly or moderately loaded, a controlled load service can to some extent accept such events as part of the behavior of a lightly loaded link. Unfortunately, as actual link utilization increases, v.42 retransmissions have the potential of stealing larger and larger fractions of available link bandwidth; making even controlled load service difficult to offer at high link utilization when retransmissions occur.
ポット上のトラフィックが経験した遅延モデムは、時間とともに大幅に異なる場合があります。リンクレートとは異なり、遅延は安定した値に収束しないことがよくあります。V.42プロトコルは、リンク層の信頼性を提供するために、ほとんどのPOTSモデムで使用されます。再送信を通じて実装されるこの信頼性により、フレームが大幅に遅れていることがあります。また、再送信は、他のトラフィックからリンク帯域幅を暗黙的に盗みます。リンク帯域幅のこれらの遅延と削減により、保証されたサービス予約を尊重することは非常に困難です。実際に軽くまたは適度にロードされているリンクでは、制御されたロードサービスは、軽くロードされたリンクの動作の一部として、ある程度そのようなイベントを受け入れることができます。残念ながら、実際のリンクの使用率が増加するにつれて、v.42の再送信は、利用可能なリンク帯域幅のより大きくより大きな画分を盗む可能性があります。再送信が発生したときに、制御されたロードサービスでさえ高リンク利用で提供するのが難しくなります。
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（1999）。無断転載を禁じます。
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エディター機能の資金は現在、インターネット協会によって提供されています。