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.
著作権（C）インターネット協会（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チャネル、サブ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.
この文書では、[6]のサービスを低ビットレートのリンクのためのIETF統合サービスのサービスのマッピングを定義し、特に制御負荷[5]と保証されています。アプローチは、これらのサービスを提供する要素の評価基準と一緒に、これらのサービスを実装するためのガイドラインと考慮事項のセットの形をとります。
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]と断片化を可能にするPPPプロトコルの拡張セットの両方を含む、[2]または懸濁液[3]のフローからのパケットに有利な大きなパケットのより厳しいサービス要件を持ちます。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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プリフラグメンテーションに関連付けられたヘッダのオーバーヘッドを最小化することによって、利用可能な帯域幅を最適化するようにより良い遅延を提供することができます。しかし、これはすべての送信データを準備して、サスペンド/レジューム制御情報のためにすべての着信データをスキャンを犠牲にして。断片化アプローチは、（ハードウェアであってもよいbit- /バイト・スタッフィング、超えて）データ・ストリームの追加走査することなく実施のみフレーム指向の送信制御を提供するシステムにも適用可能であることができます。サスペンド/フラグメンテーションに対して再開の選択[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フラグメンテーションに記載されているように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.
低速シリアルリンク上で制御されたロードまたは保証サービスを提供してルータが流れ-SERV INTに属するパケットのための「許容遅延」のいくつかの概念を持っている必要があります。フラグメンテーションを使用している場合、ルータは知っている必要がありフラグメントパケットにどのようなサイズに。サスペンド/レジュームを使用している場合、別の遅延目標を達成するための一つのパケットを中断することが適切であるとき、それは知っている必要があります。
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つのアプローチは、直接、その遅延のパフォーマンスに影響しますルータのネットワークオペレータの設定パラメータをさせることです。我々は、保証されたサービスは、ルータは理想流体流れモデルから逸脱して、CとD、速度依存性および速度に依存しない誤差項は、[6]で定義された2つの誤差項を用いて偏差の程度をアドバタイズすることを可能にすることを確認します。ネットワークオペレータは、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.
リンクレベルの断片化が使用される場合、低速リンクを制御するルータは、特定のフラグメントサイズで構成することができます。これは、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:
使用されるかもしれクラスマッピングの比較的単純な方法は、クラス値は、サービスの事前定義されたレベルに対応するものです。この構成では、すべての許可されたフローは、各バケットが概ねその中に配置されたフローのための所望のサービスのレベルに対応するいくつかのバケットのいずれかに分類されます。マッピングの設定例を以下に表示されます：
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
0b00と0b0000 0b000ベストエフォートNA 0b0001 0b001予約0B01 0b0010 0b010遅延に敏感な、何の束縛NA 0b0011 0b011予約NA 0b0100 0b100予約0b10と0b0101 0b101遅延に敏感、500msのは敏感、250msのバウンド0b11に0b0111 0b111ネットワークコントロールNA 0b0110 0b110遅延を束縛しません
Table 1: Example Mappings of Classes to Services
表1：サービスへのクラスの例マッピング
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.
MCMLクラス識別の2及び4ビットを可能にする二つのフォーマット、短いシーケンス番号、および長いシーケンス番号を有することに留意されたいです。 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ネゴシエーション時に知られており、接続の帯域幅が比較的小さい場合に有用です。これらの条件が当てはまる場合には、知られているこれらのフローのために、特定のクラスは、必要に応じてそれらとプレフィックスエリジオン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.
（つまり、4つのクラスが提供されている）MCMLショートシーケンス番号断片フォーマットを使用してPPPリンクを考えます。ベストエフォートトラフィックを運ぶに加えて、それを前提と、このリンクは、5つの保証されたサービス・フロー、A、B、C、Dを搬送され、そしてE.はまた、リンク容量は100kbit / sであると仮定し、待ち時間が100ミリ秒です。最後に、BEトラフィックはすべての回で完全なパイプを維持するのに十分であり、それがGS-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.)
時間（ミリ秒）アクション0は、トラフィックは、送信されたBEトラフィックの10kbitパケットから0 2kbitフラグメントをキューに入れられ送ることから0（...）8 2kbitフラグメントをCLS、フローAから0（10kbitパケットが行われる）9 8kbitパケットをCLSれBE 10 2kbitフラグメントは流れC、Dから13の8kbitのパケットは2（8kbitフローBパケットスタート）CLS、送信された、1（8kbitフローパケットスタート）CLSフローBから11 8kbitパケットBから12 2kbitフラグメント到着送信から到着、及びEは、送信されたCから14 2kbit断片到着3（8kbitフローCのパケット開始）送信Dから16 2kbit断片CLS、送信から0（8kbitフローDパケット開始）18 2kbit断片をCLS、Bが送信1~20 2kbit断片CLS CLS送信から2 22 2kbit断片は、送信された1〜24 2kbit断片をCLS 1が送信Eから26 2kbit断片、CLS（8kbit行うパケットフロー）1（8kbit流Eパケット開始）フローAから27 8kbitパケットが到着CLS送信Bから28 2kbitフラグメントは、C 2〜30 2kbitフラグメントが送信CLS送信Eから3 32 2kbit断片をCLS、B 1から34 2kbit断片が送信CLS、2（8kbitフローBパケットが行わ）CLS送信されたEから36 2kbit断片、1つの38 2kbitフラグメントが送信フローCLSは、（8kbitフローパケット開始）（など）をCLS
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つの提案は、すべてのBEトラフィックは、論理的に、0-15で短いシーケンス番号フラグメント形式（MCMLクラス0-3 QoSトラフィックから分離し、フラグメント化にマッピングされなければならないということです長いシーケンス番号断片フォーマット）または懸濁（RTFクラス0〜6）クラス。 BEトラフィックはほとんどの実装では（つまり、何もCLではないか、GSトラフィックが伝送のために準備ができている）リンクが空であるときを除き、送信のためにスケジュールされることはありませんので、実装者は、BEトラフィックのクラス番号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.
BEと非適合トラフィックが伝送に関しては異なって処理されているかどうか、（例えば、リンクへの非準拠トラフィックより優先アクセスが与えられBE）またはトラフィックの各タイプ内の特別な処理は、個々のフロー（例えば、WFQに与えられるかどうかREDなど）は、サービスに依存しています。
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プロトコルを使用する場合、バイトスタッフィングも、POTSモデムに最も頻繁に、多くのPPPリンク上で使用されています。バイトスタッフィングは、非常に多様な性質のために、特に保証サービスの場合には、アドミッション制御の困難な問題を提起します。最悪の場合には、バイトスタッフィングは、フレームサイズの倍増につながることができます。その結果、バイトの保証負荷のためのアドミッション制御の厳格な実施は、PPPリンクがフローアドミッション決定を行う際にリンクトラフィックのRSpecのを倍にすべきであるのぬいぐるみ。ビットスタッフィングと同様に、バイトスタッフィングとのリンクのための制御負荷サービスアドミッション制御アルゴリズムの実装は、観察介し平均パケット拡張を決定しようとするか、または理論上の最悪の場合の値を使用してもよいです。
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.
ヘッダ圧縮：バン・ジェイコブソンまたはCasner、ヤコブソン[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.
接頭エリジオンは、上位層で圧縮することができないプレフィックスをElideのためにMLPPPクラスへのマッピングの流れを利用することができます。リンク全体での合意を確立することにより、送信者は、トラフィックの特定のクラスの接頭辞をElideのも、そのクラスにパケットを受信すると、受信機は、プレフィックスを復元することができます。
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）で圧縮を実行する能力は、送信者がヒントの提供に依存してもよいことに留意されたいです。
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サイズのパケットのリンク層で効果的なサイズです。 FRAGは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はバイトのRにおけるバケットの深さが要求されたレートです。 DLINKリンク（モデム、DSU、高速の光、等）のための固定オーバーヘッド遅延です。 ERATEは、圧縮や断片化後の有効率です。
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、およびERATEを計算しなければなりませんし、それが保証サービスのために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-ヘッダ）[整数除算] Last_Frag_Size = CMTUのMOD（FRAG-ヘッダ
If Last_Frag_Size != 0 eMTU = (#_of_Fragments) * FRAG + Last_Frag_Size + Header Else eMTU = (#_of_Fragments) * FRAG
もしLast_Frag_Size！= 0 EMTU =（#_of_Fragments）* FRAG + Last_Frag_Size +ヘッダーエルス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.
アドミッション制御は、要求されたレートを配信することが可能かどうかを判断するために利用できる残りの帯域幅に対する要求のERATEを比較する必要があります。
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 =リンク+ FRAG /リンクレート
in the case of a fragementing implementation and
fragementing実装の場合と
D = Dlink + pHeader + pDelay
D =リンク+ヘッダー+ディレイ
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.
、クラスにマッピング、パケットを断片化する責任がある - リンクレベルスケジューラ - 私たちは、スケジューラの第二部に渡す前に二つの部分、送信用のどのスケジュールパケットの最初を持つものとしてリンクスケジューラと考えることがありそして、クラス間のスケジューリング。
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.
動的または静的クラスマッピングアプローチのいずれかで、リンクレベルのスケジューラは、任意の時点で、各クラスに割り当てられているどのくらいのリンク帯域幅を制御するように注意してください。スケジューラは、現在のクラスに割り当てられているパケットを持っているすべてのフローの合計のために予約された帯域幅に応じたクラスに帯域幅を割り当てる必要があります。フローAおよびEからのパケットは、同じクラス（クラス1）に割り当てられた場合、セクション3.3の例では、スケジューラは、それが20kbit / sの合計予約からのトラフィックを運んでいたという事実を反映して、クラス1に多くの帯域幅を割り当てることに注意してください他のクラスは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.
bit-によるアドミッション制御またはバイトスタッフィング中に観測されたかのどちらかの理論的平均パケット拡張に頼るときPPPリンク上でサービスの品質を提供することに関連する特定のセキュリティ上の考慮事項が表示されます。これらのパケットの拡張値に基づいた実装は、サービス拒否攻撃に対する潜在的な脆弱性が含まれています。敵は意図的に最悪の場合bit-またはバイトスタッフィングパケットの展開になりますトラフィックを送信することができます。これは、順番に過度に寛容なアドミッション制御のために他のフローのために満たされていないサービス保証の品質につながる可能性があります。サービス攻撃のこの潜在的な否定はしても、制御負荷サービスのために、アドミッション制御の計算には最悪の展開係数を使用するため、強く主張しています。
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]ボルマン、C.、 "低ビットレートリンク上で統合サービスの提供"、RFC 2689、1999年9月を。
[2] Bormann, C., "The Multi-Class Extension to Multi-Link PPP", RFC 2686, September 1999.
[2]ボルマン、C.、RFC 2686 "マルチリンクPPPへのマルチクラス拡張"、1999年9月を。
[3] Bormann, C., "PPP in a Real-time Oriented HDLC-like Framing", RFC 2687, September 1999.
[3]ボルマン、C.、 "リアルタイムでのPPP指向HDLCのようなフレーミング"、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.ヤコブソンを、RFC 2508、1999年2月 "低速シリアルリンクのIP / UDP / RTPヘッダの圧縮"。
[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]ウズラ、C.とR.ゲラン、 "保証されたサービスの質の仕様"、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]ジェーコブソン、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.デイビーら。 「圧縮性流れの存在下での統合サービス」、プログレス（ドラフト-デイビー・イントサーブ-圧縮-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.ボルマン、 "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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.、ロイド、B.、マクレガー、G.、カー、D.およびT. Coradettim、 "PPPマルチリンクプロトコル（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]ブレーデン、R.とL.チャン、 "資源予約プロトコル（RSVP） - バージョン1つのメッセージ処理ルール"、RFC 2209、1997年9月。
Steve Jackowski Deterministic Networks, Inc. 245M Mt Hermon Rd, #140 Scotts Valley, CA 95060 USA
スティーブJackowski確定ネットワークス株式会社245M山ヘルモンRdを、＃140スコッツバレー、CA 95060 USA
Phone: +1 (408) 813 6294 EMail: stevej@DeterministicNetworks.com
電話：+1（408）813 6294 Eメール：stevej@DeterministicNetworks.com
David Putzolu Intel Architecture Labs (IAL) JF3-206-H10 2111 NE 25th Avenue Hillsboro, OR 97124-5961 USA
デビッドPutzoluインテル・アーキテクチャ研究所（IAL）JF3-206-H10 2111 NE 25日アベニューヒルズボロ、OR 97124から5961 USA
Phone: +1 (503) 264 4510 EMail: David.Putzolu@intel.com
電話：+1（503）264 4510 Eメール：David.Putzolu@intel.com
Eric S. Crawley Argon Networks, Inc. 25 Porter Road Littleton, MA 01460 USA
エリックS.クローリーアルゴンネットワークス株式会社25ポーター道路リトルトン、MA 01460 USA
Phone: +1 (978) 486-0665 EMail: esc@argon.com
電話：+1（978）486-0665 Eメール：esc@argon.com
Bruce Davie Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA, 01824 USA
ブルース・デイビーシスコシステムズ社250アポロドライブチェルムズフォード、MA、01824 USA
Phone: +1 (978) 244 8921 EMail: bdavie@cisco.com
電話：+1（978）244 8921 Eメール：bdavie@cisco.com
Acknowledgements
謝辞
This document draws heavily on the work of the ISSLL WG of the IETF.
この文書は、IETFのISSLL WGの作業に大きく描画します。
Appendix A. Admission Control Considerations for POTS Modems
POTSモデムの付録A.アドミッション制御の考慮事項
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プロトコルは、条件をリンクするために適応され、接続の期間にわたって伝送速度を複数回再較正することができます。典型的には、これは、コールの最初の分以内に最初の接続を介して伝送速度の小さい（〜10％）の増加をもたらすであろう。他の結果は、利用可能な帯域幅の減少を含め、同様に可能であること、しかし、注意することが重要です。彼らが起こるようにアドミッション制御アルゴリズムは、考慮し、そのような変更を行う必要があり、かつ実装が正常リンクレートは、実際のリンクの現在予約容量を下回った場合、病理学的に対処できなければなりません。
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.
POTSモデムを介してトラフィックが経験する遅延は、時間の経過とともに大きく異なります。リンク速度とは異なり、遅延は、多くの場合、安定した値に収束しません。 V.42プロトコルは、リンク層の信頼性を提供するために、ほとんどのPOTSモデムで使用されています。再送信を経由して実装されている。この信頼性は、フレームが大幅に遅延が発生する可能性があります。再送も暗黙のうちに他のトラフィックからのリンクの帯域幅を盗みます。リンク帯域幅におけるこれらの遅延や削減は、それは非常に困難保証サービスのご予約を称えるために作ります。実際に軽くまたは適度にロードされているリンクでは、制御負荷サービスはある程度負荷の軽いリンクの行動の一環として、このようなイベントを受け入れることができます。残念ながら、実際のリンク使用率が増加すると、V.42の再送信は、利用可能なリンク帯域幅の大きい方と大きい方の分画を盗むの可能性を秘めています。再送が発生したときに高いリンク利用で提供しても、制御負荷サービスが困難になります。
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。