RFC2688 日本語訳
2688 Integrated Services Mappings for Low Speed Networks. S.Jackowski, D. Putzolu, E. Crawley, B. Davie. September 1999. (Format: TXT=36685 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
Jackowskiがコメントのために要求するワーキンググループS.をネットワークでつないでください: 2688年の決定論的なネットワークカテゴリ: 規格はB.デイビーシスコシステムズ1999年9月にD.Putzoluインテル構造研究室E.クローリーアルゴンネットワークを追跡します。
Integrated Services Mappings for Low Speed Networks
低速ネットワークのための統合サービスマッピング
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
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.
1セットの仲間ドキュメントは低いbitrateリンクの上に統合サービスを供給するために構造について説明します、モデム回線や、ISDN Bチャネルや、サブT1リンク[1、2、3、4]などのように。 構造の主な成分は以下の通りです。 非同期で同期の低いbitrateリンクのための1セットのリアルタイムのカプセル化形式、ヘッダー圧縮構造はリアルタイムの流れ、ルータ(またはホストとルータの間で)の間で使用される、交渉プロトコルの原理、およびこの交渉が行われるのを許容するのにアプリケーションで使用される発表プロトコルのために最適化されました。
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.
このドキュメントは明確に低いbitrateリンク、制御負荷[5]、および保証された[6]サービスのためにIETF Integrated Servicesに関するサービス対応表を定義します。 アプローチはこれらのサービスを実行するのにマニュアルと問題の形を取ります、これらのサービスを提供する要素のための評価基準と共に。
Jackowski, et al. Standards Track [Page 1] RFC 2688 Integrated Services Mappings Low Speed Nets September 1999
Jackowski、他 標準化過程[1ページ]RFC2688は低速が1999年9月に網で覆うサービスマッピングを統合しました。
1. Introduction
1. 序論
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]サービスに関するマッピングを低バンド幅リンクと定義します。 そのようなリンクの上にこれらのサービスを実行するのに使用される構造とメカニズムは1セットの仲間ドキュメントで定義されます。 これらのドキュメントで定義されたメカニズムは流れからのパケットを支持してより厳しいサービス要件で流れ(帯域幅貯蓄のための)[4、10]の圧縮とPPPプロトコルへの1セットの断片化[2]を可能にする拡大か大きいパケットのサスペンション[3]の両方を含んでいます。
1.1. Specification Language
1.1. 仕様言語
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[11]で説明されるように本書では解釈されることであるべきですか?
2. Issues for Providing Controlled and Guaranteed Service
2. 提供するための問題は、サービスを制御して、保証しました。
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.
これらのリンクはしばしばサービスを終わらせる本当の終わりにおける1番目か最後の広い領域ホップを表します。 これらのリンクが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
リンクの上の両方の終点が上で参照をつけられた構造とメカニズムをサポートする場合にだけ、これらのリンクに対する統合サービスを写像する際に利用されたサービスを提供します。 これらのメカニズムのサポートはPPP交渉の間、決定しています。 非共有にされる
Jackowski, et al. Standards Track [Page 2] RFC 2688 Integrated Services Mappings Low Speed Nets September 1999
Jackowski、他 標準化過程[2ページ]RFC2688は低速が1999年9月に網で覆うサービスマッピングを統合しました。
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.
すなわち、これらのリンクの自然、そんなに二地点間の事実と共に、リンクが通常二元的なシンプレクスである、(チャンネルを送って、受けてください、別々である、)、局所的に作られているというすべての入場コントロール決定を許します。
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パケット/断片がトランスミッションに加えられて、次に、ベストエフォート型パケット伝送が再開されるとき: 通常オールインワン送信。 受入れステーションは埋め込まれた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.
本書では議論した断片化がマルチリンクPPP(MLPPP)断片化について言及して、何らかのIPではなく、[2]で説明される関連MCMLPPP変更が3断片化を層にすることに注意してください。 MLPPP断片化は、PPPリンクに地方であり、終わりから終わり(IP)へのMTUに影響しません。
Jackowski, et al. Standards Track [Page 3] RFC 2688 Integrated Services Mappings Low Speed Nets September 1999
Jackowski、他 標準化過程[3ページ]RFC2688は低速が1999年9月に網で覆うサービスマッピングを統合しました。
2.1 Calculating "Acceptable Delay" for Int-serv flows
2.1 Int-servにおいて、計算の「許容できる遅れ」は流れます。
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.
低速シリーズリンクの上にControlled LoadかGuaranteed Serviceを供給するルータは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.
残念ながら、ただ一つの遅れのための特定の流れのために必ず決定されるどんな困難で速い方法もありません。 流れのエンドポイントには終わりから端への遅れ許容できる領域を決定して、ネットワークがそれらの領域を満たすという予約要求をすることができるくらいの情報がある間、彼らは「ホップ」あたり1つの遅れをルータに伝えません。
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.
Guaranteed Service[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の成分が1個の断片をリンクの上に送る時間に基づいて計算されるのを可能にするでしょう。 (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.
Controlled Loadのために、誤差項は全くありません、そして、ルータはそれらのTSpecsの情報だけを使用することで認められた予約に関する必要条件を特に満たす方法を決めなければなりません。 Controlled Loadの定義が、Tspecレートrに従ったCL流動が容量rの降ろされたネットワークと同様の処理を受けるべきであると述べるので、一般に、CLパケットは終わりから終わりへのb/r+伝播遅延よりかなりすばらしい遅れを経験するはずがありません。 明確に、低速リンクに接続されたルータは他の断片のトランスミッションのためにb/rよりすばらしい遅れを導入するべきではありません。 理想的に、実質的にb/rより少ない遅れを導入するべきです、終わりから端への経路の他のホップがまた、遅れを導入するかもしれないので。 しかしながら、bの非常に小さい値に従った流れに、これは難しいかもしれません。
Jackowski, et al. Standards Track [Page 4] RFC 2688 Integrated Services Mappings Low Speed Nets September 1999
Jackowski、他 標準化過程[4ページ]RFC2688は低速が1999年9月に網で覆うサービスマッピングを統合しました。
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.
Controlled Loadのために遅れを作るのがどれくらい低く流れるかに関してimplementersがそれら自身のを見返りに作ると予想されます。 同様に、任意に小さい値に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.
このドキュメントの残りのために、私たちは、ルータにはパケットのトランスミッションを始める前にそれが導入するかもしれない許容できる遅れの何らかの考えがあると思います。 この遅れはパケットがルータがパケットの計画をするのに使用する「理想的な」待ち行列アルゴリズムの結果、かけられるかもしれないどんな遅れに加えています。
3. Controlled Load and Guaranteed Service Class Mapping
3. 制御負荷と保証されたサービスクラスマッピング
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リンクの上の送付者と流れの受信機の両方に必要なサービスの質を示すのに使用されると仮定することに注意してください。
3.1 Predefined Class Mappings
3.1 事前に定義されたクラスマッピング
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
0b00 0b0000 0b000の最も良いEffort NA 0b0001 0b001 Reserved 0b01 0b0010 0b010 Delay Sensitive、どんな制限されたNA 0b0011 0b011 Reserved NA 0b0100 0b100 Reserved 0b10 0b0101 0b101 Delay Sensitive、500msはNA 0b0110 0b110 Delay Sensitiveを縛りませんでした、250msの制限された0b11 0b0111 0b111 Network Control
Table 1: Example Mappings of Classes to Services
テーブル1: サービスへのクラスに関する例のマッピング
Jackowski, et al. Standards Track [Page 5] RFC 2688 Integrated Services Mappings Low Speed Nets September 1999
Jackowski、他 標準化過程[5ページ]RFC2688は低速が1999年9月に網で覆うサービスマッピングを統合しました。
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ビットを考慮する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の短い一連番号形式などのように少ないときに、これはひどく保守的な入場コントロールをもたらすことができます。
3.2 Predefined Class Mappings and Prefix Elision
3.2 事前に定義されたクラスマッピングと接頭語発音省略
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]を使用できます。
3.3 Dynamic Class Mappings
3.3 ダイナミックなクラスマッピング
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.
事前に定義されたクラスマッピングが満足できない場合では、implementerは固定クラスに流れを配属するよりむしろ個々のパケットに階級値を写像するかもしれません。 PPP特有の分割/断片化メカニズムとして純粋にMCMLとRTFが提供するクラスを見なすことができます。PPPリンクを通過して、すなわち、クラス番号がイントラパケットベースで一定のままで残らなければならない間すべての流れの相互パケットベースで異なるかもしれないという事実のためこれができます。 固定クラスへの特定の流れの実際の課題は不要です、クラス番号が断片/セグメントの会員資格が単一のパケットの一部であると認識することの文脈以外のどんな意味も持つNOT REQUIREDであるので。 例を以下に提供するというこのポイントは十分重要です。
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.Furtherが、リンク容量が100kbit/sであると仮定して、潜在が100ms. Finallyである、仮定、GS流れA-Eが各10kbit/sであり、交通がいつもパイプを完全に保つことができるくらい145ms.の遅れ領域をすべて持っているということになってください。
Jackowski, et al. Standards Track [Page 6] RFC 2688 Integrated Services Mappings Low Speed Nets September 1999
Jackowski、他 標準化過程[6ページ]RFC2688は低速が1999年9月に網で覆うサービスマッピングを統合しました。
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、交通があるということになってください、列を作られた0 2kbitは交通が送られて、clsな0(…)であったなら10kbitパケットから断片化します。 流れBからのA送られて、clsな1(8kbit流れAパケット始め)11 8kbitパケットから、流れCからの13のB送られて、clsな2(8kbit流れBパケット始め)8kbitパケットからの12 2kbit断片は届いていて、D、およびEは到着します。8 2kbitが断片化する、送ってください、cls0、(10kbit、流れAから、10 2kbit断片が行われたパケット) 9 8kbitがパケットであったなら届いている、Cからの2kbit断片が送った14、Dからの3(8kbit流れCパケット始め)16 2kbit断片が送ったcls、Aからの0(8kbit流れDパケット始め)18 2kbit断片が送ったcls、Bからのcls1 20 2kbit断片は発信しました; cls2 22 2kbit断片、A送られて、clsな1 24 2kbit断片から、Cからの30 2kbit断片が送ったB送られて、clsな2からの28 2kbit断片はA送られて、clsな1(行われた8kbit流れAパケット)26 2kbit断片から流れAからのE送られて、clsな1(8kbit流れEパケット始め)27 8kbitパケットから届いていて、Eからの32 2kbit断片が送ったcls3(Bからの34 2kbit断片が送ったcls1)はEからの36 2kbit断片が送った2(行われた8kbit流れBパケット)をclsします、1つの38 2kbit断片流動Aが送ったcls、cls2(8kbit流れAパケット始め)(など)
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リンクのimplementersへの1つの提案はすべてがQoS交通と論理的に切り離されて、「断片-可能」(長いひと続きの出来事数の断片形式におけるMCMLのクラス0-3 要するに一連番号断片形式、0-15)か中断可能(RTFのクラス0- 6)のクラスに写像された交通SHOULDであるということです。 以来リンクが空である(すなわち、CLがないGS交通がトランスミッションの準備ができています)、implementersがいつの間、クラス番号0を利用するのを選ぶかもしれないか以外に、交通がトランスミッションのためにほとんどの実現で予定されないということになってください。交通になってください。
Jackowski, et al. Standards Track [Page 7] RFC 2688 Integrated Services Mappings Low Speed Nets September 1999
Jackowski、他 標準化過程[7ページ]RFC2688は低速が1999年9月に網で覆うサービスマッピングを統合しました。
3.4 Non-Conformant Traffic
3.4 非Conformant交通
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.
非conformant QoS交通の処理は適切なサービス仕様で主に決定していますが、この草稿の文脈における詳細な実現は何らかの柔軟性を考慮します。 流れがいつも非conformant交通SHOULDを含むのが取り締まられて、よりすばらしい粒状のレベルでというよりむしろ個々のパケットの粒状のレベルでしてください。 トランスミッションのために流れの計画をするネットワーク要素が、非conformant交通を落とす必要があって、それがSHOULDであるそれらの場合では、特に、非conformant交通に属すパケットの個々の断片を落とすよりむしろ全体のパケットを落としてください。 リンク帯域幅が交通を落とすよりむしろ利用可能であるときにネットワーク要素が非conformant交通を進めるそれらの場合では、実現SHOULDはまるでそれがベストエフォート型交通であるかのようにそのような交通のパケットを断片化します。
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.
非conformantの上に与えられた優先権アクセスがあります。いてください。そうすれば、非conformantな交通がトランスミッションに関して異なって扱われる、(例えば、いてください、リンクへの交通) または、特別な処理は個々の流れ(例えば、WFQ、REDなど)に都合しているのが、サービス扶養家族であるというそれぞれのタイプの交通の中では、ことであるかどうか
4. Guidelines for Implementers
4. Implementersのためのガイドライン
4.1. PPP Bit and Byte Stuffing Effects on Admission Control
4.1. 入場コントロールへの効果を詰めるpppビットとバイト
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%の追加オーバーヘッドをもたらすことができます。 したがって、新しい流れを認めることができるかどうか決定するとき、ビット・スタッフィングが中古のSHOULDである保証されたサービスオーバーリンクのための入場コントロール実現にすべての流れの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
また、バイト詰め物は多くのPPPリンクの上に使用されて、v.42を使用するとき、頻繁にPOTSモデムの上の大部分は議定書を作ります。 バイト詰め物は入場コントロールに難問を引き起こします、特に保証されたサービスの場合で、非常に変化する本質のため。 より悪い場合では、バイト詰め物はフレーム・サイズの倍増をもたらすことができます。 結果、保証された負荷に、オンな入場コントロールの厳しい実現として
Jackowski, et al. Standards Track [Page 8] RFC 2688 Integrated Services Mappings Low Speed Nets September 1999
Jackowski、他 標準化過程[8ページ]RFC2688は低速が1999年9月に網で覆うサービスマッピングを統合しました。
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.
バイトの詰められたPPPは流れを入場決定にする際にリンク交通のRSpecのSHOULD二重をリンクします。 ビット・スタッフィングなら、5月を詰めるバイトとのリンクへの制御負荷サービス入場コントロールアルゴリズムの実現は、観測で平均したパケット拡大を決定するのを試みるか、または理論上の最悪の場合値を使用するかもしれません。
4.2. Compression Considerations
4.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.
ヘッダー圧縮: ジェーコブソンか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.
圧縮オプションのどれかが接続のために実行されると、実際の通信速度、およびその結果リンクについて必要である帯域幅は(s)が使用した圧縮方法で減少するでしょう。
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.
接頭語発音省略は、より高い層に圧縮できない接頭語を削除するのに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].
下の入場制御セクションで説明されるように含まれていて、圧縮利得と発音省略利得の両方はそうしなければなりません。 より高い層(例えば、TCPかRTP/UDP)で圧縮を実行する能力を送付者によるヒントの支給に依存するかもしれないことに注意してください、[9]で説明されるように。
4.3. Admission Control
4.3. 入場コントロール
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ヘッダー/トレーラを含む断片サイズです。
Jackowski, et al. Standards Track [Page 9] RFC 2688 Integrated Services Mappings Low Speed Nets September 1999
Jackowski、他 標準化過程[9ページ]RFC2688は低速が1999年9月に網で覆うサービスマッピングを統合しました。
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はパケットを中断させてください、bがバイトRで表現されるバケツの深さである時が要求されたRateであるということです。 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リンクの特性と遅れで、より多くの問題についてAppendix 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:
入場コントロールはControlled Load ServiceのためにCMTU、eMTU、およびeRateを計算しなければなりません、そして、Guaranteed Serviceのために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:
要求されたレートが有効であるかどうか決定するために、Admission Controlは以下の要求(eRate)(最悪の場合)の実効金利を計算しなければなりません:
#_of_Fragments = CMTU div (FRAG-Header) [Integer divide] Last_Frag_Size = CMTU mod (FRAG-Header
#_CMTU div(FRAG-ヘッダー)[整数分水嶺]最終_Frag_Size=CMTU_Fragments=モッズ、(FRAG-ヘッダー
If Last_Frag_Size != 0
eMTU = (#_of_Fragments) * FRAG + Last_Frag_Size + Header
Else
eMTU = (#_of_Fragments) * FRAG
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.
入場コントロールSHOULDは要求されたレートを送ることができるかどうか決定するために利用可能な残っている帯域幅に対して要求の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.
Controlled Load Serviceに関しては、利用可能な(上の計算の後の)レート必要条件を満たすことができるくらいの帯域幅がある限り、十分なバッファ領域があれば(象徴バケツサイズの合計は緩衝能を超えていません)、流れを認めることができます。 許容性を計算する際に何らかの統計的多重化ができていた間、低いbitrateリンクの自然で、一時的な過大割当てを記述するために被られたどんな遅れも清算するのが難しいかもしれないので、このアプローチは危険になるかもしれません。
Jackowski, et al. Standards Track [Page 10] RFC 2688 Integrated Services Mappings Low Speed Nets September 1999
Jackowski、他 標準化過程[10ページ]RFC2688は低速が1999年9月に網で覆うサービスマッピングを統合しました。
4.4 Error Term Calculations
4.4 誤差項計算
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
保証されたServiceはCとD誤差項の計算を必要とします。Cはレート依存する誤差項です、そして、低速リンク環境には計算に影響するどんな特別な問題もありません。 存在という固有のリンク遅れ(Dlink)から計算されたD用語と潜在的最悪の場合は、オーバーヘッドを別の断片のトランスミッションのため延着するか、中断するか、または再開します。 したがって、Dとして、計算されるべきです。
D = Dlink + FRAG/LinkRate
D=Dlink+は/LinkRateを破片手榴弾で殺傷します。
in the case of a fragementing implementation and
そしてfragementing実現に関するケース。
D = Dlink + pHeader + pDelay
DはDlink+pHeader+pDelayと等しいです。
for a suspend/resume implementation.
aに関しては、実現を中断するか、または再開してください。
4.5 Scheduling Considerations
4.5 スケジューリング問題
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つの部品を持っているとしてのリンクスケジューラと、それらをクラスに写像して、パケットを断片化するのに原因となるスケジューラ(リンク・レベルスケジューラ)の第二部にそれらを通過する前のトランスミッションのためのどのスケジュールパケット、およびスケジューリングの1番目を考えるかもしれないか。
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.
アプローチを写像する動力か静的なクラスのどちらかでは、リンク・レベルスケジューラSHOULDが、どのくらいのリンク帯域幅が何か瞬間に各クラスに配属されるかを制御することに注意してください。 現在パケットをクラスに配属させるすべての流れの合計で控えられた帯域幅に従って、スケジューラはクラスに帯域幅を配属するはずです。 流れAとEからのパケットが同じクラス(クラス1)に配属されたとき、セクション3.3に関する例では、スケジューラがクラス1により多くの帯域幅を配属したことに注意してください、他のクラスが10kbit/sだけを運んだ間に20kbit/sを合計する予約から交通を運んだという事実を反映して。
Jackowski, et al. Standards Track [Page 11] RFC 2688 Integrated Services Mappings Low Speed Nets September 1999
Jackowski、他 標準化過程[11ページ]RFC2688は低速が1999年9月に網で覆うサービスマッピングを統合しました。
5. Security Considerations
5. セキュリティ問題
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リンクはRFC1990[12]とRFC1661[13]にそれぞれ記述されます。 RFC2209[14]でシグナリングが統合サービスのために議定書を作るので使用されるRSVPに関連しているセキュリティ問題について議論します。
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]で議論したものの上でどんな新しい安全保障問題も紹介しません。 これらのサービス対応表のどんな使用も、サービスを求めるすべての要求が適切に認証されると仮定します。
6. References
6. 参照
[1] Bormann, C., "Providing Integrated Services over Low-bitrate
Links", RFC 2689, September 1999.
[1] C. ボルマン、1999年9月、「低いbitrateリンクの上に統合サービスを供給すること」でのRFC2689。
[2] Bormann, C., "The Multi-Class Extension to Multi-Link PPP", RFC
2686, September 1999.
[2] ボルマン、C.、「マルチリンクpppへのマルチのクラス拡大」、RFC2686、1999年9月。
[3] Bormann, C., "PPP in a Real-time Oriented HDLC-like Framing",
RFC 2687, September 1999.
[3] ボルマン、C.、「リアルタイムの指向のHDLCのような縁どりにおけるppp」、RFC2687、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.、およびRFC2508、1999年2月対「低速連続のリンクへのIP/UDP/RTPヘッダーを圧縮する」ジェーコブソン
[5] Wroclawski, J., "Specification of the Controlled-Load Network
Element Service", RFC 2211, September 1997.
[5]Wroclawski、J.、「制御負荷ネットワーク要素サービスの仕様」、RFC2211、1997年9月。
[6] Partridge, C. and R. Guerin, "Specification of Guaranteed
Quality of Service", RFC 2212, September 1997.
[6] ヤマウズラとC.とR.ゲラン、「保証されたサービスの質の仕様」、RFC2212、1997年9月。
Jackowski, et al. Standards Track [Page 12] RFC 2688 Integrated Services Mappings Low Speed Nets September 1999
Jackowski、他 標準化過程[12ページ]RFC2688は低速が1999年9月に網で覆うサービスマッピングを統合しました。
[7] Shenker, S. and J. Wroclawski, "General Characterization
Parameters for Integrated Service Network Elements", RFC 2215,
September 1997.
[7]ShenkerとS.とJ.Wroclawski、「統合サービスネットワークElementsへの一般的性質パラメタ」、RFC2215、1997年9月。
[8] Jacobson, V., "TCP/IP Compression for Low-Speed Serial Links",
RFC 1144, February 1990.
[8] ジェーコブソン、V.、「低速連続のリンクのためのTCP/IP圧縮」、RFC1144、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.デイビー他 「Compressible FlowsのPresenceの統合Services」、Progress(草稿-davie-intserv湿布-00.txt)のWork、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ヘッダー圧縮」、RFC2509、1999年2月。
[11] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[11] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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)について議定書の中で述べます」、RFC1990、1996年8月。
[13] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
51, RFC 1661, July 1994.
[13] シンプソン、W.、エディタ、「二地点間プロトコル(ppp)」、STD51、RFC1661、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メッセージ処理は統治する」RFC2209、1997年9月。
Jackowski, et al. Standards Track [Page 13] RFC 2688 Integrated Services Mappings Low Speed Nets September 1999
Jackowski、他 標準化過程[13ページ]RFC2688は低速が1999年9月に網で覆うサービスマッピングを統合しました。
7. Authors' Addresses
7. 作者のアドレス
Steve Jackowski Deterministic Networks, Inc. 245M Mt Hermon Rd, #140 Scotts Valley, CA 95060 USA
スティーブJackowski決定論的なネットワークInc.の245MのMt Hermon、#140Scottsカリフォルニア95060第バレー(米国)
Phone: +1 (408) 813 6294 EMail: stevej@DeterministicNetworks.com
以下に電話をしてください。 +1(408) 813 6294はメールされます: 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アベニューのヒルズバロ、または97124-5961米国
Phone: +1 (503) 264 4510 EMail: David.Putzolu@intel.com
以下に電話をしてください。 +1(503) 264 4510はメールされます: David.Putzolu@intel.com
Eric S. Crawley Argon Networks, Inc. 25 Porter Road Littleton, MA 01460 USA
エリックS.クローリーアルゴンはInc.25ポーターRoad MA01460リトルトン(米国)をネットワークでつなぎます。
Phone: +1 (978) 486-0665 EMail: esc@argon.com
以下に電話をしてください。 +1 (978) 486-0665 メールしてください: esc@argon.com
Bruce Davie Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA, 01824 USA
Driveチェルムズフォード、ブルースデイビーシスコシステムズInc.250アポロMA01824米国
Phone: +1 (978) 244 8921 EMail: bdavie@cisco.com
以下に電話をしてください。 +1(978) 244 8921はメールされます: bdavie@cisco.com
Acknowledgements
承認
This document draws heavily on the work of the ISSLL WG of the IETF.
このドキュメントは大いにIETFのISSLL WGの仕事を利用します。
Jackowski, et al. Standards Track [Page 14] RFC 2688 Integrated Services Mappings Low Speed Nets September 1999
Jackowski、他 標準化過程[14ページ]RFC2688は低速が1999年9月に網で覆うサービスマッピングを統合しました。
Appendix A. Admission Control Considerations for POTS Modems
入場が問題を制御する付録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モデムで使用されます。 この信頼性(「再-トランスミッション」を通して実行される)で、フレームは重要な遅れを経験できます。 また、Retransmissionsは他の交通からリンク帯域幅をそれとなく盗みます。 リンク帯域幅でのこれらの遅れと減少で、保証されたサービスの予約を守るのは非常に難しくなります。 実際に軽か適度に積み込まれるリンクの上では、制御負荷サービスは軽く積み込まれたリンクの振舞いの一部のような出来事をある程度受け入れることができます。 残念ながら、実際のリンクとして、利用増加、v.42 retransmissionsには、利用可能なリンク帯域幅について窃盗のますます大きい断片の可能性があります。 「再-トランスミッション」が現れると高いリンク利用で制御負荷サービスさえ提供するのを難しくします。
Jackowski, et al. Standards Track [Page 15] RFC 2688 Integrated Services Mappings Low Speed Nets September 1999
Jackowski、他 標準化過程[15ページ]RFC2688は低速が1999年9月に網で覆うサービスマッピングを統合しました。
9. Full Copyright Statement
9. 完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Jackowski, et al. Standards Track [Page 16]
Jackowski、他 標準化過程[16ページ]
一覧
スポンサーリンク
