RFC4829 日本語訳
4829 Label Switched Path (LSP) Preemption Policies for MPLS TrafficEngineering. J. de Oliveira, Ed., JP. Vasseur, Ed., L. Chen, C.Scoglio. April 2007. (Format: TXT=43892 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. de Oliveira, Ed.
Request for Comments: 4829 Drexel University
Category: Informational JP. Vasseur, Ed.
Cisco Systems, Inc.
L. Chen
Verizon Laboratories
C. Scoglio
Kansas State University
April 2007
作業部会のJ.deオリベイラ、エドをネットワークでつないでください。Commentsのために以下を要求してください。 4829年のドレクセル大学Category: 情報のJP。 エドVasseur、シスコシステムズInc.L.チェンベライゾン研究所C.Scoglioカンザス州立大学2007年4月
Label Switched Path (LSP) Preemption Policies for
MPLS Traffic Engineering
ラベルはMPLS交通工学のために経路(LSP)先取り方針を切り換えました。
Status of This Memo
このメモの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
IESG Note
IESG注意
This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and, in particular, notes that the decision to publish is not based on IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this document should exercise caution in evaluating its value for implementation and deployment. See RFC 3932 for more information.
このRFCはインターネットStandardのどんなレベルの候補ではありません。 IETFは配備されたプロトコルとのセキュリティのようなもの、輻輳制御、または不適当な相互作用のために、発行するという決定がIETFレビューに基づいていないというどんな目的と特に注意のためのこのRFCのフィットネスに関するどんな知識も放棄します。 RFC Editorは、自己判断でこのドキュメントを発表するのを選びました。 このドキュメントの読者は実現と展開のために値を評価する際に警戒するべきです。 詳しい情報に関してRFC3932を見てください。
Abstract
要約
When the establishment of a higher priority (Traffic Engineering Label Switched Path) TE LSP requires the preemption of a set of lower priority TE LSPs, a node has to make a local decision to select which TE LSPs will be preempted. The preempted LSPs are then rerouted by their respective Head-end Label Switch Router (LSR). This document presents a flexible policy that can be used to achieve different objectives: preempt the lowest priority LSPs; preempt the minimum number of LSPs; preempt the set of TE LSPs that provide the closest amount of bandwidth to the required bandwidth for the preempting TE LSPs (to minimize bandwidth wastage); preempt the LSPs that will have the maximum chance to get rerouted. Simulation results are given and
より高い優先度(交通Engineering Label Switched Path)TE LSPの設立が低優先度TE LSPsの1セットの先取りを必要とするとき、ノードはどのTE LSPsが先取りされるかを選択するというローカルの決定をしなければなりません。 そして、先取りされたLSPsは彼らのそれぞれのHead-終わりのLabel Switch Router(LSR)によって別ルートで送られます。 このドキュメントは異なった目的を達成するのに使用できるフレキシブルな方針を提示します: 最も低い優先度LSPsを先取りしてください。 LSPsの最小の数を先取りしてください。 先取りTE LSPs(帯域幅消耗を最小にする)のために最も近い量の帯域幅を必要な帯域幅に供給するTE LSPsのセットを先取りしてください。 別ルートで送らせる最大の機会を持っているLSPsを先取りしてください。 そしてシミュレーションの結果を与える。
de Oliveira, et al. Informational [Page 1] RFC 4829 LSP Preemption Policies for MPLS-TE April 2007
deオリベイラ、他 MPLS-Te2007年4月のための情報[1ページ]のRFC4829LSP先取り方針
a comparison among several different policies, with respect to preemption cascading, number of preempted LSPs, priority, wasted bandwidth and blocking probability is also included.
いくつかの異なった方針の中の比較、先取り滝に関して、先取りされたLSPsの数(優先権)は帯域幅を浪費しました、そして、また、確率を妨げるのは含まれています。
Table of Contents
目次
1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. LSP Setup Procedure and Preemption . . . . . . . . . . . . . . 5
4. Preemption Cascading . . . . . . . . . . . . . . . . . . . . . 6
5. Preemption Heuristic . . . . . . . . . . . . . . . . . . . . . 7
5.1. Preempting Resources on a Path . . . . . . . . . . . . . . 7
5.2. Preemption Heuristic Algorithm . . . . . . . . . . . . . . 8
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Simple Case: Single Link . . . . . . . . . . . . . . . . . 10
6.2. Network Case . . . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
9. Informative References . . . . . . . . . . . . . . . . . . . . 17
1. 動機. . . . . . . . . . . . . . . . . . . . . . . . . . 3 2。 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 3。 LSPは手順と先取り. . . . . . . . . . . . . . 5 4をセットアップします。 先取り滝. . . . . . . . . . . . . . . . . . . . . 6 5。 先取りヒューリスティック. . . . . . . . . . . . . . . . . . . . . 7 5.1。 経路. . . . . . . . . . . . . . 7 5.2に関するリソースを先取りします。 先取りヒューリスティックアルゴリズム. . . . . . . . . . . . . . 8 6。 例. . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.1。 簡単なケース: 単一のリンク. . . . . . . . . . . . . . . . . 10 6.2。 ケース. . . . . . . . . . . . . . . . . . . . . . . 12 7をネットワークでつないでください。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 16 8。 承認. . . . . . . . . . . . . . . . . . . . . . . 16 9。 有益な参照. . . . . . . . . . . . . . . . . . . . 17
de Oliveira, et al. Informational [Page 2] RFC 4829 LSP Preemption Policies for MPLS-TE April 2007
deオリベイラ、他 MPLS-Te2007年4月のための情報[2ページ]のRFC4829LSP先取り方針
1. Motivation
1. 動機
The IETF Traffic Engineering Working Group has defined the requirements and protocol extensions for DiffServ-aware MPLS Traffic Engineering (DS-TE) [RFC3564] [RFC4124]. Several Bandwidth Constraint models for use with DS-TE have been proposed [RFC4127] [RFC4128] [RFC4126] and their performance was analyzed with respect to the use of preemption.
IETF Traffic Engineering作業部会はDiffServ意識しているMPLS Traffic Engineering(DS-TE)[RFC3564][RFC4124]のために要件とプロトコル拡大を定義しました。 DS-TEとの使用のための数個のBandwidth Constraintモデルが提案されました、そして、[RFC4127][RFC4128][RFC4126]彼らの性能は先取りの使用に関して分析されました。
Preemption can be used as a tool to help ensure that high priority LSPs can always be routed through relatively favorable paths. Preemption can also be used to implement various prioritized access policies as well as restoration policies following fault events [RFC2702].
比較的好ましい経路を通していつも高その優先度LSPsを確実にするのを助けるツールを発送できるように先取りを使用できます。 また、欠点出来事[RFC2702]に続いて、回復方針と同様に様々な最優先するアクセス政策を実施するのに先取りを使用できます。
Although not a mandatory attribute in the traditional IP world, preemption becomes important in networks using online, distributed Constrained Shortest Path First (CSPF) strategies for their Traffic Engineering Label Switched Path (TE LSP) path computation to limit the impact of bandwidth fragmentation. Moreover, preemption is an attractive strategy in an MPLS network in which traffic is treated in a differentiated manner and high-importance traffic may be given special treatment over lower-importance traffic [DEC-PREP, ATM-PREP]. Nevertheless, in the DS-TE approach, whose issues and requirements are discussed in [RFC3564], the preemption policy is considered an important piece on the bandwidth reservation and management puzzle, but no preemption strategy is defined. Note that preemption also plays an important role in regular MPLS Traffic Engineering environments (with a single pool of bandwidth).
伝統的なIP世界の義務的な属性ではありませんが、先取りは、彼らのTraffic Engineering Label Switched Path(TE LSP)経路計算が帯域幅断片化の影響を制限するのにオンラインの、そして、分配されたConstrained Shortest Path First(CSPF)戦略を使用することでネットワークで重要になります。 そのうえ、先取りは交通が微分された方法で扱われて、高重要性交通が特別な処理を下側の重要性交通[12月-PREP、ATM-PREP]の上に与えられるかもしれないMPLSネットワークで魅力的な戦略です。 それにもかかわらず、DS-TEアプローチでは、先取り方針は帯域幅の予約と管理パズルに関する重要な断片であると考えられますが、先取り戦略は全く定義されません。([RFC3564]で問題とアプローチの要件について議論します)。 また、先取りが通常のMPLS Traffic Engineering環境(帯域幅の単一のプールがある)で重要な役割を果たすことに注意してください。
This document proposes a flexible preemption policy that can be adjusted in order to give different weight to various preemption criteria: priority of LSPs to be preempted, number of LSPs to be preempted, amount of bandwidth preempted, blocking probability. The implications (cascading effect, bandwidth wastage, priority of preempted LSPs) of selecting a certain order of importance for the criteria are discussed for the examples given.
このドキュメントは様々な先取り評価基準に異なった重さを与えるように調整できるフレキシブルな先取り方針を提案します: 先取りされるべきLSPsの優先権(先取りされるべきLSPsの数)は確率を妨げて、先取りされた帯域幅を達させます。 出された例のために評価基準のためにある重要な注文を選択する含意(滝の効果、帯域幅消耗、先取りされたLSPsの優先権)について議論します。
2. Introduction
2. 序論
In [RFC2702], issues and requirements for Traffic Engineering in an MPLS network are highlighted. In order to address both traffic- oriented and resource-oriented performance objectives, the authors point out the need for priority and preemption parameters as Traffic Engineering attributes of traffic trunks. The notion of preemption and preemption priority is defined in [RFC3272], and preemption attributes are defined in [RFC2702] and [RFC3209].
[RFC2702]では、MPLSネットワークにおけるTraffic Engineeringのための問題と要件は強調されます。 適応する交通とリソース指向のパフォーマンス目標の両方を記述するために、作者は交通トランクスのTraffic Engineering属性として優先権と先取りパラメタの必要性を指摘します。 先取りと先取り優先権の概念は[RFC3272]で定義されます、そして、先取り属性は[RFC2702]と[RFC3209]で定義されます。
de Oliveira, et al. Informational [Page 3] RFC 4829 LSP Preemption Policies for MPLS-TE April 2007
deオリベイラ、他 MPLS-Te2007年4月のための情報[3ページ]のRFC4829LSP先取り方針
A traffic trunk is defined as an aggregate of traffic flows belonging to the same class that are placed inside an LSP [RFC3564]. In this context, preemption is the act of selecting an LSP that will be removed from a given path in order to give room to another LSP with a higher priority (lower preemption number). More specifically, the preemption attributes determine whether an LSP with a certain setup preemption priority can preempt another LSP with a lower holding preemption priority from a given path, when there is competition for available resources. Note that competing for resources is one situation in which preemption can be triggered, but other situations may exist, themselves controlled by a policy.
交通トランクはLSP[RFC3564]の中に置かれるのと同じクラスに属す交通の流れの集合と定義されます。 このような関係においては、先取りは、より高い優先度(下側の先取り番号)と共に別のLSPに人に機会を与えるために与えられた経路から取り外されるLSPを選択する行為です。 より明確に、先取り属性は、あるセットアップ先取り優先があるLSPが下側の把持先取り優先度で与えられた経路から別のLSPを先取りできるかどうか決定します、利用可能資源の競争があるとき。 リソースを競争するのが、方針で制御された先取りが引き起こされましたが、他の状況は存在するかもしれません、自分たちということであるかもしれない1つの状況であることに注意してください。
For readability, a number of definitions from [RFC3564] are repeated here:
読み易さにおいて、[RFC3564]からの多くの定義がここで繰り返されます:
Class-Type (CT): The set of Traffic Trunks crossing a link that is governed by a specific set of Bandwidth constraints. CT is used for the purposes of link bandwidth allocation, constraint-based routing, and admission control. A given Traffic Trunk belongs to the same CT on all links.
クラスタイプ(コネチカット): 特定のBandwidth規制で治められるリンクを越えるTraffic Trunksのセット。 コネチカットはリンク帯域幅配分、規制ベースのルーティング、および入場コントロールの目的に使用されます。 与えられたTraffic Trunkはすべてのリンクの上の同じコネチカットに属します。
TE-Class: A pair of:
Teクラス: 以下の1組
i. A Class-Type.
i。 クラスタイプ。
ii. A preemption priority allowed for that Class-Type. This means that an LSP transporting a Traffic Trunk from that Class-Type can use that preemption priority as the set-up priority, as the holding priority, or both.
ii。 先取り優先はそのClass-タイプを考慮しました。 これは、そのClass-タイプからTraffic Trunkを輸送するLSPがセットアップ優先権としてその先取り優先権を使用できることを意味します、把持優先権、または両方として。
By definition, there may be more than one TE-Class using the same CT, as long as each TE-Class uses a different preemption priority. Also, there may be more than one TE-Class with the same preemption priority, provided that each TE-Class uses a different CT. The network administrator may define the TE-Classes in order to support preemption across CTs, to avoid preemption within a certain CT, or to avoid preemption completely, when so desired. To ensure coherent operation, the same TE-Classes must be configured in every Label Switched Router (LSR) in the DS-TE domain.
定義上、同じコネチカットを使用する複数のTE-クラスがあるかもしれません、各TE-クラスが異なった先取り優先を使用する限り。 また、同じ先取り優先権がある複数のTE-クラスがあるかもしれません、各TE-クラスが異なったコネチカットを使用すれば。 ネットワーク管理者はある一定のコネチカットの中で先取りを避けるか、または先取りを完全に避けるためにCTsの向こう側に先取りを支持するためにTE-クラスを定義するかもしれません、そう望まれていると。 一貫性を持っている操作を確実にするために、DS-TEドメインのあらゆるLabel Switched Router(LSR)で同じTE-クラスを構成しなければなりません。
As a consequence of a per-TE-Class treatment, the Interior Gateway Protocol (IGP) needs to advertise separate Traffic Engineering information for each TE-Class, which consists of the Unreserved Bandwidth (UB) information [RFC4124]. The UB information will be used by the routers, checking against the bandwidth constraint model parameters, to decide whether preemption is needed. Details on how to calculate the UB are given in [RFC4124].
処理、ゲートウェイプロトコル(IGP)がUnreserved Bandwidth(UB)情報[RFC4124]から成る各TE-クラスのための別々のTraffic Engineering情報の広告を出す必要があるTEのクラスあたり1Interiorの結果として。 UB情報はルータによって使用されるでしょう、先取りが必要であるかどうか決めるために帯域幅規制モデルパラメータに対してチェックして。 どうUBについて計算するかに関する詳細は[RFC4124]に述べられます。
de Oliveira, et al. Informational [Page 4] RFC 4829 LSP Preemption Policies for MPLS-TE April 2007
deオリベイラ、他 MPLS-Te2007年4月のための情報[4ページ]のRFC4829LSP先取り方針
3. LSP Setup Procedure and Preemption
3. LSPセットアップ手順と先取り
A new LSP setup request has two important parameters: bandwidth and preemption priority. The set of LSPs to be preempted can be selected by optimizing an objective function that represents these two parameters, and the number of LSPs to be preempted. More specifically, the objective function could be any, or a combination, of the following [DEC-PREP, ATM-PREP]:
新しいLSPセットアップ要求には、2つの重要なパラメタがあります: 帯域幅と先取り優先権。 先取りされるためにこれらの2つのパラメタを表す目的関数、およびLSPsの数を最適化することによって、先取りされるべきLSPsのセットを選択できます。 より明確に、目的関数は、以下のいずれ、または組み合わせであるかもしれません[12月-PREP、ATM-PREP]:
* Preempt the LSPs that have the least priority (preemption
priority). The Quality of Service (QoS) of high priority traffic
would be better satisfied, and the cascading effect described below
can be limited.
* 最少の優先権(先取り優先権)を持っているLSPsを先取りしてください。 高い優先権交通のService(QoS)のQualityは満足するほうがよいでしょう、そして、以下で説明された滝の効果は制限できます。
* Preempt the least number of LSPs. The number of LSPs that need to
be rerouted would be lower.
* LSPsの最少の数を先取りしてください。 別ルートで送られる必要があるLSPsの数は低いでしょう。
* Preempt the least amount of bandwidth that still satisfies the
request. Resource utilization could be improved. The preemption
of larger TE LSPs (more than requested) by the newly signaled TE
LSP implies a larger amount of bandwidth to be rerouted, which is
likely to increase the probability of blocking (inability to find a
path for some TE LSPs).
* まだ要望に応じている帯域幅の最小量を先取りしてください。 リソース利用を改良できました。 新たに合図されたTE LSPによる、より大きいTE LSPs(要求されているよりさらに)の先取りは別ルートで送られる多く以上の量の帯域幅を含意します。(それは、(いくつかのTE LSPsに関して経路を見つけることができないこと)を妨げるという確率を増加させそうです)。
* Preempt LSPs that minimize the blocking probability (risk that
preempted TE LSP cannot be rerouted).
* ブロッキング確率を最小にするLSPsを先取りしてください(TE LSPを先取りした危険は別ルートで送ることができません)。
After the preemption selection phase is finished, the selected LSPs are signaled as preempted and the new LSP is established (if a new path satisfying the constraints can be found). The UB information is then updated via flooding of an IGP-TE update and/or simply pruning the link where preemption occurred. Figure 1 shows a flowchart that summarizes how each LSP setup request is treated in a preemption- enabled scenario.
先取り選択段階が終わっていた後に、選択されたLSPsは先取りされるとして合図されます、そして、新しいLSPは設立されます(規制を満たす新しい経路を見つけることができるなら)。 UB情報は、次に、IGP-TEアップデートの氾濫を通してアップデートする、そして/または、単に、先取りが起こったリンクから余計なものを取り除いています。 図1はそれぞれのLSPセットアップ要求が先取りの可能にされたシナリオでどう扱われるかをまとめるフローチャートを示しています。
de Oliveira, et al. Informational [Page 5] RFC 4829 LSP Preemption Policies for MPLS-TE April 2007
deオリベイラ、他 MPLS-Te2007年4月のための情報[5ページ]のRFC4829LSP先取り方針
LSP Setup Request
(TE-Class i, bw=r)
|
|
v NO
UB[TE-Class i] >= r ? -------> Reject LSP
Setup and flood an updated IGP-TE
| LSA/LSP
|YES
v NO
Preemption Needed ? -------> Setup LSP/Update UB if a threshold is
| crossed
| YES
v
Preemption ----> Setup LSP/Reroute Preempted LSPs
Algorithm Update UB
LSP Setup Request(TE-クラスi、bw=r)| | NO UB[TE-クラスi]>=rに対して? ------->はLSP Setupを拒絶して、アップデートされたIGP-TEをあふれさせます。| LSA/LSP|必要でないPreemption全くに対してはい? ------->セットアップLSP/アップデートUBが敷居であるならあります。| 交差されます。| Preemptionに対してはい----セットアップLSP/が別ルートで送る>はLSPsアルゴリズムアップデートUBを先取りしました。
Figure 1: Flowchart for LSP setup procedure.
図1: LSPセットアップ手順のためのフローチャート。
In [DEC-PREP], the authors propose connection preemption policies that optimize the discussed criteria in a given order of importance: number of LSPs, bandwidth, and priority; bandwidth, priority, and number of LSPs. The novelty in our approach is the use of an objective function that can be adjusted by the service provider in order to stress the desired criteria. No particular criteria order is enforced. Moreover, a new criterion is added to the objective function: optimize the blocking probability (to minimize the risk that an LSP is not rerouted after being preempted).
[12月-PREP]では、作者は与えられた重要な注文における議論された評価基準を最適化する接続先取り方針を提案します: LSPs、帯域幅、および優先権の数。 LSPsの帯域幅、優先権、および数。 私たちのアプローチにおける目新しさはサービスプロバイダーが必要な評価基準を強調するように調整できる目的関数の使用です。 どんな特定の評価基準オーダーも励行されません。 そのうえ、新しい評価基準は目的関数に加えられます: ブロッキング確率(LSPが先取りされた後に別ルートで送られないという危険を最小にする)を最適化してください。
4. Preemption Cascading
4. 先取り滝
The decision of preempting an LSP may cause other preemptions in the network. This is called preemption cascading effect and different cascading levels may be achieved by the preemption of a single LSP. The cascading levels are defined in the following manner: when an LSP is preempted and rerouted without causing any further preemption, the cascading is said to be of level zero. However, when a preempted LSP is rerouted, and in order to be established in the new route it also causes the preemption of other LSPs, the cascading is said to be of level 1, and so on.
LSPを先取りする決定はネットワークで他の先取りを引き起こすかもしれません。 これは先取りの滝の効果と呼ばれます、そして、異なった滝のレベルは独身のLSPの先取りで達成されるかもしれません。 滝のレベルは以下の方法で定義されます: LSPがどんなさらなる先取りも引き起こさないで先取りされて、別ルートで送られるとき、滝はレベルゼロがあると言われます。 しかしながら、先取りされたLSPが別ルートで送られて、また、新しいルートに設立されるために他のLSPsの先取りを引き起こすとき、滝はレベル1などがあると言われます。
Preemption cascading is not desirable and therefore policies that minimize it are of interest. Typically, this can result in severe network instabilities. In Section 5, a new versatile preemption heuristic will be presented. In Section 6, preemption simulation results will be discussed and the cascading effect will be analyzed.
先取り滝は望ましくはありません、そして、したがって、それを最小にする方針は興味があります。 通常、これは厳しいネットワークの不安定性をもたらすことができます。 セクション5では、新しい多能な先取りヒューリスティックは提示されるでしょう。 セクション6では、先取りシミュレーションの結果について議論するでしょう、そして、滝の効果は分析されるでしょう。
de Oliveira, et al. Informational [Page 6] RFC 4829 LSP Preemption Policies for MPLS-TE April 2007
deオリベイラ、他 MPLS-Te2007年4月のための情報[6ページ]のRFC4829LSP先取り方針
5. Preemption Heuristic
5. 先取りヒューリスティック
5.1. Preempting Resources on a Path
5.1. 経路に関するリソースを先取りします。
It is important to note that once a request for an LSP setup arrives, each LSR along the TE LSP path checks the available bandwidth on its outgoing link. For the links in which the available bandwidth is not enough, the preemption policy needs to be activated in order to guarantee the end-to-end bandwidth reservation for the new LSP. This is a distributed approach, in which every node on the path is responsible for running the preemption algorithm and determining which LSPs would be preempted in order to fit the new request. A distributed approach may not lead to an optimal solution.
LSPセットアップを求める要求がいったん到着すると、TE LSP経路に沿った各LSRが出発しているリンクにおける利用可能な帯域幅をチェックすることに注意するのは重要です。 利用可能な帯域幅が十分でないリンクに、先取り方針は、終わりから終わりへの新しいLSPの帯域幅予約を保証するために動かされる必要があります。 これは分散型アプローチです。(そこでは、新しい要求に合うように先取りアルゴリズムを述べて、どのLSPsが先取りされるかを決定するのに経路のあらゆるノードが原因となります)。 分散型アプローチは最適解につながらないかもしれません。
Alternatively, in a centralized approach, a manager entity runs the preemption policy and determines the best LSPs to be preempted in order to free the required bandwidth in all the links that compose the path. The preemption policy would try to select LSPs that overlap with the path being considered (preempt a single LSP that overlaps with the route versus preempt a single LSP on every link that belongs to the route).
あるいはまた、集結されたアプローチでは、マネージャ実体は、経路を構成するすべてのリンクの必要な帯域幅を解放するために先取り方針を述べて、最も良いLSPsが先取りされることを決定します。 先取り方針が考えられる経路に重なるLSPsを選択しようとするだろう、(ルートに重なるa独身のLSPを先取りする、先取り、ルートに属すあらゆるリンクの上の独身のLSP)
Both centralized and distributed approaches have advantages and drawbacks. A centralized approach would be more precise, but require that the whole network state be stored and updated accordingly, which raises scalability issues. In a network where LSPs are mostly static, an offline decision can be made to reroute LSPs and the centralized approach could be appropriate. However, in a dynamic network in which LSPs are set up and torn down in a frequent manner because of new TE LSPs, bandwidth increase, reroute due to failure, etc., the correctness of the stored network state could be questionable. Moreover, the setup time is generally increased when compared to a distributed solution. In this scenario, the distributed approach would bring more benefits, even when resulting in a non-optimal solution (The gain in optimality of a centralized approach compared to a distributed approach depends on many factors: network topology, traffic matrix, TE strategy, etc.). A distributed approach is also easier to be implemented due to the distributed nature of the current Internet protocols.
両方が集中しました、そして、分散型アプローチには、利点と欠点があります。 それに従って、全体のネットワーク州を格納して、アップデートするのが必要であるのを除いて、集結されたアプローチは、より正確でしょう(スケーラビリティ問題を提起します)。 LSPsがほとんど静的であるネットワークでは、LSPsを別ルートで送るのをオフライン決定をすることができます、そして、集結されたアプローチは適切であるかもしれません。 しかしながら、LSPsが増加をセットして、新しいTE LSPs、帯域幅による頻繁な方法で取りこわされるダイナミックなネットワークでは、失敗(疑わしいかもしれないネットワークが、述べる格納の正当性)などのためコースを変更してください。 そのうえ、分配された解決策と比べると、一般に、準備時間は増加します。 非最適解をもたらすときさえ、このシナリオでは、分散型アプローチは、より多くの利益をもたらすでしょう(分散型アプローチにたとえられた集結されたアプローチの最適における利得を多くの要素に依存します: ネットワーク形態、交通マトリクス、TE戦略など)。 分散型アプローチはまた、より簡単であるのが、現在のインターネットプロトコルの分配された本質への実行された支払われるべきものであるということです。
Since the current Internet routing protocols are essentially distributed, a decentralized approach was selected for the LSP preemption policy. The parameters required by the new preemption policies are currently available for OSPF and Intermediate System to Intermediate System (IS-IS).
以来、現在のインターネットルーティング・プロトコルは本質的には分配されて、分散アプローチはLSP先取り方針のために選択されました。 新しい先取り方針によって必要とされたパラメタが現在Intermediate SystemへのOSPFとIntermediate Systemに利用可能である、(-、)
de Oliveira, et al. Informational [Page 7] RFC 4829 LSP Preemption Policies for MPLS-TE April 2007
deオリベイラ、他 MPLS-Te2007年4月のための情報[7ページ]のRFC4829LSP先取り方針
5.2. Preemption Heuristic Algorithm
5.2. 先取りヒューリスティックアルゴリズム
Consider a request for a new LSP setup with bandwidth b and setup preemption priority p. When preemption is needed, due to lack of available resources, the preemptable LSPs will be chosen among the ones with lower holding preemption priority (higher numerical value) in order to fit r=b-Abw(l). The variable r represents the actual bandwidth that needs to be preempted (the requested, b, minus the available bandwidth on link l: Abw(l)).
帯域幅bとセットアップ先取り優先権pがある新しいLSPセットアップを求める要求を考えてください。 先取りが利用可能資源の不足のため必要であるときに、preemptable LSPsは、r=b-Abw(l)に合うようにものの中で下側の把持先取り優先度(より高い数値)で選ばれるでしょう。 可変rは先取りされる必要がある実際の帯域幅を表します。(要求、リンクl: Abw(l))における利用可能な帯域幅を引いたb。
L is the set of active LSPs having a holding preemption priority lower (numerically higher) than p. So L is the set of candidates for preemption. b(l) is the bandwidth reserved by LSP l in L, expressed in bandwidth units, and p(l) is the holding preemption priority of LSP l.
Lは把持先取り優先をpより低く(数の上でさらに高い)するアクティブなLSPsのセットです。 それで、Lは先取りの候補のセットです。b(l)は帯域幅ユニットで言い表されたLでLSP l保有された帯域幅です、そして、p(l)はLSP lの把持先取り優先権です。
In order to represent a cost for each preemption priority, an associated cost y(l) inversely related to the holding preemption priority p(l) is defined. For simplicity, a linear relation y(l)=8-p(l) is chosen. y is a cost vector with L components, y(l). b is a reserved bandwidth vector with dimension L, and components b(l).
それぞれの先取り優先権のために費用を表すために、y(l)が逆に把持先取り優先権p(l)に関係づけた関連費用は定義されます。 簡単さにおいて、直線的な関係y(l)=8-p(l)は選ばれています。yはLコンポーネント(y(l))がある費用ベクトルであり、bは寸法L、およびコンポーネントb(l)がある予約された帯域幅ベクトルです。
Concerning the objective function, four main objectives can be reached in the selection of preempted LSPs:
目的関数に関して、4つの主な目標に先取りされたLSPsの品揃えで達することができます:
* minimize the priority of preempted LSPs, * minimize the number of preempted LSPs, * minimize the preempted bandwidth, * minimize the blocking probability.
* 先取りされたLSPsの優先権を最小にしてください、そして、*先取りされたLSPsの数を最小にしてください、そして、*先取りされた帯域幅を最小にしてください、そして、*ブロッキング確率を最小にしてください。
To have the widest choice on the overall objective that each service provider needs to achieve, the following equation was defined (for simplicity chosen as a weighted sum of the above mentioned criteria):
各サービスプロバイダーが達成する必要がある総合的な目的で最も広い選択を持つために、以下の方程式は定義されました(上記の評価基準の荷重している合計として選ばれた簡単さのために):
H(l)= alpha y(l) + beta 1/b(l) + gamma (b(l)-r)^2 + theta b(l)
H(l)はアルファy(l)+ベータ1/b(l)+ガンマ(b(l)-r)^2+θbと等しいです。(l)
In this equation:
この方程式で:
- alpha y(l) captures the cost of preempting high priority LSPs.
- アルファy(l)は高優先度LSPsを先取りする費用を得ます。
- beta 1/b(l) penalizes the preemption of low bandwidth LSPs,
capturing the cost of preempting a large number of LSPs.
- 多くのLSPsを先取りする費用を得て、ベータ1/b(l)は低い帯域幅LSPsの先取りを罰します。
- gamma (b(l)-r)^2 captures the cost of preemption of LSPs that are
much larger or much smaller than r.
- ガンマ(b(l)-r)^2ははるかに大きいか、またはrよりはるかに小さいLSPsの先取りの費用を得ます。
- theta b(l) captures the cost of preempting large LSPs.
- θb(l)は大きいLSPsを先取りする費用を得ます。
de Oliveira, et al. Informational [Page 8] RFC 4829 LSP Preemption Policies for MPLS-TE April 2007
deオリベイラ、他 MPLS-Te2007年4月のための情報[8ページ]のRFC4829LSP先取り方針
Coefficients alpha, beta, gamma, and theta can be chosen to emphasize one or more components of H.
Hの1つ以上のコンポーネントを強調するために係数アルファ、ベータ、ガンマ、およびθを選ぶことができます。
The coefficient theta is defined such that theta = 0 if gamma > 0. This is because when trying to minimize the blocking probability of preempted LSPs, the heuristic gives preference to preempting several small LSPs (therefore gamma, which is the weight for minimizing the preempted bandwidth enforcing the selection of LSPs with similar amount of bandwidth as the requested, needs to be set as zero). The selection of several small LSPs in a normally loaded portion of the network will increase the chance that such LSPs are successfully rerouted. Moreover, the selection of several small LSPs may not imply preempting much more than the required bandwidth (resulting in low-bandwidth wastage), as it will be seen in the discussed examples. When preemption is to happen in a heavy loaded portion of the network, to minimize blocking probability, the heuristic will select fewer LSPs for preemption in order to increase the chance of rerouting.
係数θが定義されるので、θはガンマ>0であるなら0と等しいです。 これは先取りされたLSPsのブロッキング確率を最小にしようとするとき、ヒューリスティックが数個の小さいLSPsを先取りするのに優先を与えるから(したがって、ガンマ(要求として同様の量の帯域幅があるLSPsの品揃えを実施する先取りされた帯域幅を最小にするための重さである)は、ゼロとして設定される必要があります)です。 ネットワークの通常、ロードされた部分での数個の小さいLSPsの品揃えはそのようなLSPsが首尾よく別ルートで送られるという可能性を高めるでしょう。 そのうえ、数個の小さいLSPsの品揃えは先取りを必要な帯域幅よりはるかに含意しないかもしれません(低バンド幅消耗をもたらして)、それが議論された例で見られるように。 先取りがブロッキング確率を最小にするためにネットワークの重いロードされた部分で起こることになっているなら、コースを変更するという可能性を高めて、ヒューリスティックは先取りのために、より少ないLSPsを選択するでしょう。
H is calculated for each LSP in L. The LSPs to be preempted are chosen as the ones with smaller H that add enough bandwidth to accommodate r. When sorting LSPs by H, LSPs with the same value for H are ordered by bandwidth b, in increasing order. For each LSP with repeated H, the algorithm checks whether the bandwidth b assigned to only that LSP is enough to satisfy r. If there is no such LSP, it checks whether the bandwidth of each of those LSPs added to the previously preempted LSPs' bandwidth is enough to satisfy r. If that is not true for any LSP in that repeated H-value sequence, the algorithm preempts the LSP that has the larger amount of bandwidth in the sequence, and keeps preempting in decreasing order of b until r is satisfied or the sequence is finished. If the sequence is finished and r is not satisfied, the algorithm again selects LSPs to be preempted based on an increasing order of H. More details on the algorithm are given in [PREEMPTION].
HはL.の各LSPのために計算されます。先取りされるべきLSPsは、より小さいHがあるrを収容できるくらいの帯域幅を加えるものとして選ばれています。 HでLSPsを分類するとき、帯域幅bはオーダーを増加させる際にHのための同じ値があるLSPsを注文します。 各LSPがないかどうか、H、繰り返されるのによるアルゴリズムは、そのLSPだけに割り当てられた帯域幅bがrを満たすために十分であるかどうかチェックします。 どれかそのようなLSPがなければ、それは、以前に先取りされたLSPsの帯域幅に加えられたそれぞれのそれらのLSPsの帯域幅がrを満たすために十分であるかどうかチェックします。 どんなLSPにも、それがその繰り返されたH-値の系列で本当でないなら、アルゴリズムは系列における多く以上の量の帯域幅を持って、rを満たしているか、または系列が終わるまでbの減少している注文で先取りし続けるLSPを先取りします。 系列が終わっていて、rが満たされていないなら、アルゴリズムは、LSPsがアルゴリズムに関する詳細が[PREEMPTION]に述べられるH.Moreの増加する注文に基づいて先取りされるのを再び選択します。
When the objective is to minimize blocking, the heuristic will follow two options on how to calculate H:
目的がブロッキングを最小にすることであるときに、ヒューリスティックはどうHについて計算するかに関する2つのオプションに続くでしょう:
* If the link in which preemption is to happen is normally loaded,
several small LSPs will be selected for preemption using H(l)=
alpha y(l) + theta b(l).
* 先取りが起こることになっているリンクが通常積み込まれると、数個の小さいLSPsが、先取りのためにアルファy(l)+θH(l)=b(l)を使用することで選択されるでしょう。
* If the link is overloaded, few LSPs are selected using H(l)= alpha
y(l) + beta 1/b(l).
* リンクが積みすぎられるなら、わずかなLSPsしか、H(l)=アルファy(l)+ベータ1/b(l)を使用することで選択されません。
de Oliveira, et al. Informational [Page 9] RFC 4829 LSP Preemption Policies for MPLS-TE April 2007
deオリベイラ、他 MPLS-Te2007年4月のための情報[9ページ]のRFC4829LSP先取り方針
6. Examples
6. 例
6.1. Simple Case: Single Link
6.1. 簡単なケース: 単一のリンク
We first consider a very simple case, in which the path considered for preemption is composed by a single hop. The objective of this example is to illustrate how the heuristic works. In the next section, we will study a more complex case in which the preemption policies are being tested on a network.
私たちは最初に、非常に簡単な場合を考えます。(先取りのために考えられた経路は単一のホップによってそれで構成されます)。 この例の目的はヒューリスティックがどう働いているかを例証することです。 次のセクションで、私たちは先取り方針がネットワークでテストすることにされるのであるより複雑な場合を研究するつもりです。
Consider a link with 16 LSPs with reserved bandwidth b in Mbps, preemption holding priority p, and cost y, as shown in Table 1. In this example, 8 TE-Classes are active. The preemption here is being performed on a single link as an illustrative example.
Mbpsの予約された帯域幅b、優先権pを保持する先取り、および費用yがある16LSPsとのリンクを考えてください、Table1に示されるように。 この例では、8つのTE-クラスが活動的です。 ここでの先取りは説明に役立つ実例として単一のリンクに実行されています。
------------------------------------------------------------------
LSP L1 L2 L3 L4 L5 L6 L7 L8
------------------------------------------------------------------
Bandwidth (b) 20 10 60 25 20 1 75 45
Priority (p) 1 2 3 4 5 6 7 5
Cost (y) 7 6 5 4 3 2 1 3
------------------------------------------------------------------
LSP L9 L10 L11 L12 L13 L14 L15 L16
------------------------------------------------------------------
Bandwidth (b) 100 5 40 85 50 20 70 25
Priority (p) 3 6 4 5 2 3 4 7
Cost (y) 5 2 4 3 6 5 4 1
------------------------------------------------------------------
Table 1: LSPs in the considered link.
------------------------------------------------------------------ LSP L1 L2 L3 L4 L5 L6 L7 L8------------------------------------------------------------------ 帯域幅(b)20 10 60 25 20 1 75 45優先権(p)1 2 3 4 5 6 7 5費用(y)7 6 5 4 3 2 1 3------------------------------------------------------------------ LSP L9 L10 L11 L12 L13 L14 L15 L16------------------------------------------------------------------ 帯域幅(b)100 5 40 85 50 20 70 25優先権(p)3 6 4 5 2 3 4 7費用(y)5 2 4 3 6 5 4 1------------------------------------------------------------------ テーブル1: 考慮のLSPsはリンクします。
A request for an LSP establishment arrives with r=175 Mbps and p=0 (highest possible priority, which implies that all LSPs with p>0 in Table 1 will be considered when running the algorithm). Assume Abw(l)=0.
LSP設立を求める要求はr=175 Mbpsとp=0(アルゴリズムを走らせるとき、p>0がTable1にあるすべてのLSPsが考えられるのを含意する可能な限り高い優先度)と共に到着します。 Abw(l)=0を仮定してください。
If priority is the only important criterion, the network operator configures alpha=1, beta=gamma=theta=0. In this case, LSPs L6, L7, L10, L12, and L16 are selected for preemption, freeing 191 bandwidth units to establish the high-priority LSP. Note that 5 LSPs were preempted, but all with a priority level between 5 and 7.
優先権が唯一の重要な評価基準であるなら、ネットワーク・オペレータは、アルファが1、ベータ=ガンマ=θ=0と等しいのを構成します。 この場合、LSPs L6、L7、L10、L12、およびL16は先取りのために選択されます、高優先度LSPを証明するために191帯域幅ユニットを解放して。 しかし、優先順位がすべて、5と7の間ある状態で5LSPsが先取りされたことに注意してください。
In a network in which rerouting is an expensive task to perform (and the number of rerouted TE LSPs should be as small as possible), one might prefer to set beta=1 and alpha=gamma=theta=0. LSPs L9 and L12 would then be selected for preemption, adding up to 185 bandwidth units (less wastage than the previous case). The priorities of the selected LSPs are 3 and 5 (which means that they might themselves preempt some other LSPs when rerouted).
コースを変更するのが実行する(別ルートで送られたTE LSPsの数はできるだけ少ないはずです)高価なタスクであるネットワークでは、人は、ベータ=1とアルファ=ガンマ=θ=0を設定するのを好むかもしれません。 次に、LSPs L9とL12は先取りのために選択されるでしょう、最大185帯域幅ユニット(先の事件より少ない消耗)を加えて。 選択されたLSPsのプライオリティは、3と5(別ルートで送られると、どれが、彼らがそうするかもしれないことを自分たちで意味するかがある他のLSPsを先取りする)です。
de Oliveira, et al. Informational [Page 10] RFC 4829 LSP Preemption Policies for MPLS-TE April 2007
deオリベイラ、他 MPLS-Te2007年4月のための情報[10ページ]のRFC4829LSP先取り方針
Suppose the network operator decides that it is more appropriate to configure alpha=1, beta=10, gamma=0, theta=0 (the parameters were set to values that would balance the weight of each component, namely priority and number, in the cost function), because in this network rerouting is very expensive, LSP priority is important, but bandwidth is not a critical issue. In this case, LSPs L7, L12, and L16 are selected for preemption. This configuration results in a smaller number of preempted LSPs when compared to the first case, and the priority levels are kept between 5 and 7.
ネットワーク・オペレータが、アルファ=1を構成するために、ベータは10、ガンマ=0、θ=0と等しいです(パラメタはすなわち、各コンポーネント、優先権の重さと費用関数の数のバランスをとる値に設定されました)、このネットワークでは、コースを変更するのが非常に高価であるのでより適切であると決めますが、LSP優先権が重要ですが、帯域幅があらゆる重大でない問題であるなら。 この場合、LSPs L7、L12、およびL16は先取りのために選択されます。 最初のケースと比べると、この構成は先取りされたLSPsの、より少ない数をもたらします、そして、優先順位は5〜7であることが保たれます。
To take into account the number of LSPs preempted, the preemption priority, and the amount of bandwidth preempted, the network operator may set alpha > 0, beta > 0, and gamma > 0. To achieve a balance among the three components, the parameters need to be normalized. Aiming for a balance, the parameters could be set as alpha=1, beta=10 (bringing the term 1/b(l) closer to the other parameters), and gamma=0.001 (bringing the value of the term (b(l)-r)^2 closer to the other parameters). LSPs L7 and L9 are selected for preemption, resulting in exactly 175 bandwidth units and with priorities 3 and 7 (note that less LSP are preempted but they have a higher priority which may result in a cascading effect).
先取りされたLSPsの数、先取り優先権、および帯域幅の量が先取りしたアカウントを連れていくために、ネットワーク・オペレータはアルファ>0、ベータ>0、およびガンマ>0を設定するかもしれません。 3つのコンポーネントの中でバランスを獲得するために、パラメタは、正常にされる必要があります。 バランスを目指して、アルファ=1、ベータ=10(1/b(l)という用語を他のパラメタの、より近くに持って来る)、およびガンマが0.001と等しいときに(2という用語(b(l)-r)^の値を他のパラメタの、より近くにもたらして)、パラメタは設定されるかもしれません。 LSPs L7とL9は先取りのために選択されます、まさに175帯域幅ユニットとプライオリティ3と7でなって(より少ないLSPが先取りされますが、それらには滝の効果をもたらすかもしれないより高い優先度があることに注意してください)。
If the minimization of the blocking probability is the criterion of most interest, the cost function could be configured with theta=1, alpha=beta=gamma=0. In that case, several small LSPs are selected for preemption: LSPs L2, L4, L5, L6, L7, L10, L14, and L16. Their preemption will free 181 Mbps in this link, and because the selected LSPs have small bandwidth requirement there is a good chance that each of them will find a new route in the network.
ブロッキング確率の最小化がほとんどの関心の評価基準であるなら、費用関数はθ=1、アルファ=ベータ=ガンマ=0によって構成されるかもしれません。 その場合、数個の小さいLSPsが先取りのために選択されます: LSPs L2、L4、L5、L6、L7、L10、L14、およびL16。 彼らの先取りはこのリンクの181Mbpsを解放するでしょう、そして、選択されたLSPsには小さい帯域幅要件があるので、それぞれの彼らがネットワークで新しいルートを見つけるという十分な見込みがあります。
From the above example, it can be observed that when the priority was the highest concern and the number of preempted LSPs was not an issue, 5 LSPs with the lowest priority were selected for preemption. When only the number of LSPs was an issue, the minimum number of LSPs was selected for preemption: 2, but the priority was higher than in the previous case. When priority and number were important factors and a possible waste of bandwidth was not an issue, 3 LSPs were selected, adding more bandwidth than requested, but still with low preemption priority. When considering all the parameters but the blocking probability, the smallest set of LSP was selected, 2, adding just enough bandwidth, 175 Mbps, and with priority levels 3 and 7.
上記の例から、優先権が最も高い関心であり、先取りされたLSPsの数が問題でなかったときに、最も低い優先度がある5LSPsが先取りのために選択されたのを観測できます。 LSPsの唯一の数が問題であったときに、LSPsの最小の数は先取りのために選択されました: 2 優先度だけが先の事件より高かったです。 優先権と数が重要な要素であり、帯域幅の可能な浪費が問題でなかったときに、3LSPsが選択されました、しかし、まだ低い先取り優先度で要求されているより多くの帯域幅を加えて。 すべてのパラメタにもかかわらず、ブロッキング確率を考える場合、LSPの最も小さいセットが選択されたとき、帯域幅、175Mbpsをちょうど十分加えて、優先順位3と7でそうする2です。
When the blocking probability was the criterion of interest, several (8) small LSPs were preempted. The bandwidth wastage is low, but the number of rerouting events will increase. Given the bandwidth requirement of the preempted LSPs, it is expected that the chances of finding a new route for each LSP will be high.
ブロッキング確率が興味がある評価基準であったときに、数個の(8)の小さいLSPsが先取りされました。 帯域幅消耗は低いのですが、コースを変更する出来事の数は増加するでしょう。 先取りされたLSPsに関する帯域幅要件を考えて、各LSPに関して新しいルートを見つけるという可能性が高くなると予想されます。
de Oliveira, et al. Informational [Page 11] RFC 4829 LSP Preemption Policies for MPLS-TE April 2007
deオリベイラ、他 MPLS-Te2007年4月のための情報[11ページ]のRFC4829LSP先取り方針
6.2. Network Case
6.2. ネットワークケース
For these experiments, we consider a 150 nodes topology with an average network connectivity of 3. 10% of the nodes in the topology have a degree of connectivity of 6. 10% of the links are OC3, 70% are OC48, and 20% are OC192.
これらの実験のために、私たちは、150のノードが3の平均したネットワークの接続性があるトポロジーであると考えます。 トポロジーのノードの10%には、6の1段階の接続性があります。 リンクの10%はOC3です、そして、70%はOC48です、そして、20%はOC192です。
Two classes of TE LSPs are in use: Voice LSPs and Data Internet/VPN LSPs. For each class of TE LSP, the set of preemptions (and the proportion of LSPs for each preemption) and the size distributions are as follows (a total of T LSPs is considered):
TE LSPsの2つのクラスが使用中です: LSPsとデータインターネット/VPN LSPsを声に出してください。 TE LSPの各クラスにおいて、先取り(そして、各先取りのためのLSPsの割合)のセットとサイズ配は以下の通りです(T LSPsの合計は考えられます):
T: total number of TE LSPs in the network (T = 18,306 LSPs)
T: ネットワークにおける、TE LSPsの総数(1万8306T=LSPs)
Voice:
声:
Number: 20% of T Preemption: 0, 1 and 2 Size: uniform distribution between 30M and 50M
数: 20%のT先取り: 0、1、および2サイズ: 30Mと50Mの間の一様分布
Internet/VPN TE:
インターネット/VPN Te:
Number: 4% of T Preemption: 3 Size: uniform distribution between 20M and 50M
数: 4%のT先取り: 3サイズ: 20Mと50Mの間の一様分布
Number: 8% of T Preemption 4 Size: uniform distribution between 15M and 40M
数: 8%のT先取り4サイズ: 15Mと40Mの間の一様分布
Number: 8% of T Preemption 5 Size: uniform distribution between 10M and 20M
数: 8%のT先取り5サイズ: 10Mと20Mの間の一様分布
Number: 20% of T Preemption 6 Size: uniform distribution between 1M and 20M
数: 20%のT先取り6サイズ: 1Mと20Mの間の一様分布
Number: 40% of T Preemption 7 Size: uniform distribution between 1K and 1M
数: 40%のT先取り7サイズ: 1Kと1Mの間の一様分布
LSPs are set up mainly due to network failure: a link or a node failed and LSPs are rerouted.
LSPsは主にネットワーク失敗のためセットアップされます: リンクかノードが失敗しました、そして、LSPsは別ルートで送られます。
de Oliveira, et al. Informational [Page 12] RFC 4829 LSP Preemption Policies for MPLS-TE April 2007
deオリベイラ、他 MPLS-Te2007年4月のための情報[12ページ]のRFC4829LSP先取り方針
The network failure events were simulated with two functions:
ネットワーク失敗イベントは2つの機能でシミュレートされました:
- Constant: 1 failure chosen randomly among the set of links every 1
hour.
- 定数: 1 毎1時間リンクのセットの中で手当たりしだいに選ばれた失敗。
- Poisson process with interarrival average = 1 hour.
- 1interarrival平均=時間があるポアソン過程。
Table 2 shows the results for simulations with constant failure. The simulations were run with the preemption heuristic configured to balance different criteria (left side of the table), and then with different preemption policies that consider the criteria in a given order of importance rather than balancing them (right side of the table).
テーブル2はシミュレーションのために一定の失敗で結果を示しています。 シミュレーションは異なった評価基準(テーブルの左側)のバランスをとるために構成される先取りヒューリスティック、およびそして、与えられたオーダーにおける評価基準が重要であるとむしろ考えるそれら(テーブルの右側)のバランスをとっているのと異なった先取り方針がある走行でした。
The proposed heuristic was configured to balance the following criteria:
提案されたヒューリスティックは以下の評価基準のバランスをとるために構成されました:
HPB: The heuristic with priority and bandwidth wastage as the most important criteria (alpha=10, beta=0, gamma=0.001, theta=0).
HPB: 最も重要な評価基準(アルファは10、ベータ=0、ガンマ=0.001、θ=0と等しい)としての優先権と帯域幅消耗があるヒューリスティック。
HBlock: The heuristic considering the minimization of blocking probability (normal load links: alpha=1, beta=0, gamma=0, theta=0.01) (heavy load links: alpha=1, beta=10).
HBlock: ブロッキング確率の最小化(正常な負荷リンク: アルファ=1、ベータ=0、ガンマ=0、θ=0.01)(重量物リンク: 1、アルファ=ベータ=10)を考えるヒューリスティック。
HNB: The heuristic with number of preemptions and wasted bandwidth in consideration (alpha=0, beta=10, gamma=0.001, theta=0).
HNB: 考慮(アルファは0、ベータ=10、ガンマ=0.001、θ=0と等しい)における先取りと無駄な帯域幅の数があるヒューリスティック。
Other algorithms that consider the criteria in a given order of importance:
与えられたオーダーにおける評価基準が重要であると考える他のアルゴリズム:
P: Sorts candidate LSPs by priority only.
P: 優先権だけは候補LSPsを分類します。
PN: Sorts the LSPs by priority, and for cases in which the priority is the same, orders those LSPs by decreasing bandwidth (selects larger LSPs for preemption in order to minimize number of preempted LSPs).
PN: 優先的に、そして、およびそれらのLSPsが優先権が同じであるよう帯域幅を静まらせることによって命令する場合(先取りされたLSPsの数を最小にして、先取りのために、より大きいLSPsを選択する)のためにLSPsを分類します。
PB: Sorts the LSPs by priority, and for LSPs with the same priority, sorts those by increasing bandwidth (select smaller LSPs in order to reduce bandwidth wastage).
Pb: 優先的に、そして、および同じ優先権があるLSPsのためにLSPsを分類して、帯域幅(帯域幅消耗を抑えるために、より小さいLSPsを選択する)を増加させることによって、それらを分類します。
de Oliveira, et al. Informational [Page 13] RFC 4829 LSP Preemption Policies for MPLS-TE April 2007
deオリベイラ、他 MPLS-Te2007年4月のための情報[13ページ]のRFC4829LSP先取り方針
-------------------------------------------------
| Heuristic | Other algorithms |
-------------------------------------------------
| HPB | HBlock| HNB | P | PN | PB |
-----------------------------------------------------------------
Need to be | 532 | 532 | 532 | 532 | 532 | 532 |
Rerouted | | | | | | |
-----------------------------------------------------------------
Preempted | 612 | 483 | 619 | 504 | 477 | 598 |
-----------------------------------------------------------------
Rerouted |467|76%|341|73%|475|77%|347|69%|335|70%|436|73%|
Blocked |145|24%|130|27%|144|23%|157|31%|142|30%|162|27%|
-----------------------------------------------------------------
Max Cascading | 4.5 | 2 | 5 | 2.75 | 2 | 2.75 |
-----------------------------------------------------------------
Wasted Bandwidth| | | | | | |
AVR (Mbps) | 6638 | 532 | 6479 | 8247 | 8955 | 6832 |
Worst Case(Mbps)| 35321 |26010 |36809 | 28501 | 31406 | 23449 |
-----------------------------------------------------------------
Priority | | | | | | |
Average | 6 | 6.5 | 5.8 | 6.6 | 6.6 | 6.6 |
Worst Case | 1.5 | 3.8 | 1.2 | 3.8 | 3.8 | 3.8 |
-----------------------------------------------------------------
Extra Hops | | | | | | |
Average | 0.23 | 0.25 | 0.22 | 0.25 | 0.25 | 0.23 |
Worst Case | 3.25 | 3 | 3.25 | 3 | 3 | 2.75 |
-----------------------------------------------------------------
Table 2: Simulation results for constant network failure:
1 random failure every hour.
------------------------------------------------- | ヒューリスティック| 他のアルゴリズム| ------------------------------------------------- | HPB| HBlock| HNB| P| PN| Pb| ----------------------------------------------------------------- 必要です。| 532 | 532 | 532 | 532 | 532 | 532 | コースを変更します。| | | | | | | ----------------------------------------------------------------- 先取りされます。| 612 | 483 | 619 | 504 | 477 | 598 | ----------------------------------------------------------------- コースを変更します。|467|76%|341|73%|475|77%|347|69%|335|70%|436|73%| 妨げられます。|145|24%|130|27%|144|23%|157|31%|142|30%|162|27%| ----------------------------------------------------------------- マックスCascading| 4.5 | 2 | 5 | 2.75 | 2 | 2.75 | ----------------------------------------------------------------- 無駄な帯域幅| | | | | | | AVR(Mbps)| 6638 | 532 | 6479 | 8247 | 8955 | 6832 | 最悪の場合(Mbps)| 35321 |26010 |36809 | 28501 | 31406 | 23449 | ----------------------------------------------------------------- 優先権| | | | | | | 平均| 6 | 6.5 | 5.8 | 6.6 | 6.6 | 6.6 | 最悪の場合| 1.5 | 3.8 | 1.2 | 3.8 | 3.8 | 3.8 | ----------------------------------------------------------------- 余分なホップス| | | | | | | 平均| 0.23 | 0.25 | 0.22 | 0.25 | 0.25 | 0.23 | 最悪の場合| 3.25 | 3 | 3.25 | 3 | 3 | 2.75 | ----------------------------------------------------------------- テーブル2: 一定のネットワーク失敗のためのシミュレーションの結果: 1 毎時間の偶発故障。
From Table 2, we can conclude that among the heuristic (HPB, HBlock, HNB) results, HBlock resulted in the smaller number of LSPs being preempted. More importantly, it also resulted in an overall smaller rejection rate and smaller average wasted bandwidth (and second overall smaller worst-case wasted bandwidth.)
Table2から、私たちは、発見的な(HPB、HBlock、HNB)結果の中では、HBlockが先取りされるLSPsの、より少ない数をもたらしたと結論を下すことができます。 また、より重要に、それは総合的なよりわずかな返品率と、より小さい平均した無駄な帯域幅をもたらしました。(2番目の総合的なより小さい最悪の場合は帯域幅を浪費しました。)
Although HBlock does not try to minimize the number of preempted LSPs, it ends up doing so, because it preempts LSPs with lower priority mostly, and therefore it does not propagate cascading much further. Cascading was the overall lowest (preemption caused at most two levels of preemption, which was also the case for the policy PN). The average and worst preemption priority was very satisfactory (preempting mostly lowest-priority LSPs, like the other algorithms P, PN, and PB).
HBlockは先取りされたLSPsの数を最小にしようとしませんが、結局そうします、低優先度でLSPsをほとんど先取りします、そして、したがって、はるかに遠くにどっと落しながら、伝播しません。 滝は最も低く総合的(先取りはまた、方針PNのためのケースであった2つのレベルの先取りを高々引き起こした)でした。 平均して最も悪い先取り優先権は非常に満足できました(ほとんど他のアルゴリズムのP、PN、およびPBのような最も低い優先度LSPsを先取りします)。
When HPB was in use, more LSPs were preempted as a consequence of the higher cascading effect. That is due to the heuristic's choice of preempting LSPs that are very similar in bandwidth size to the
HPBが使用中であったときに、より多くのLSPsが、より高いのが効果をどっと落させる結果として先取りされました。 それは帯域幅サイズにおいて非常に同様のLSPsを先取りすることのヒューリスティックの選択のためにいます。
de Oliveira, et al. Informational [Page 14] RFC 4829 LSP Preemption Policies for MPLS-TE April 2007
deオリベイラ、他 MPLS-Te2007年4月のための情報[14ページ]のRFC4829LSP先取り方針
bandwidth size of the preemptor LSP (which can result in preempting a higher priority LSP and therefore causing cascading). The wasted bandwidth was reduced when compared to the other algorithms (P, PN, PB).
先買権所有者LSP(より高い優先度を先取りするのにLSPの結果になって、したがって、引き起こす滝の結果になることができる)の帯域幅サイズ。 他のアルゴリズム(P、PN、PB)と比べると、無駄な帯域幅は減少しました。
When HNB was used, cascading was higher than the other cases, due to the fact that LSPs with higher priority could be preempted. When compared to P, PN, or PB, the heuristic HNB preempted more LSPs (in fact, it preempted the largest number of LSPs overall, clearly showing the cascading effect), but the average wasted bandwidth was smaller, although not as small as HBlock's (the HNB heuristic tries to preempt a single LSP, meaning it will preempt LSPs that have a reserved bandwidth similar to the actual bandwidth needed. The algorithm is not always successful, because such a match may not exist, and in that case, the wasted bandwidth could be high). The preempted priority was the highest on average and worse case, which also shows why the cascading level was also the highest (the heuristic tries to select LSPs for preemption without looking at their priority levels). In summary, this policy resulted in a poor performance.
HNBが使用されたとき、滝は他のケースより高かったです、さらに高い優先度があるLSPsを先取りできたという事実のため。 比べると、P、PN、またはPB、ヒューリスティックに、HNBは、より多くのLSPsを先取りしましたが(事実上、全体的に見てLSPsの最多数を先取りしました、明確に滝の効果を示して)、平均した無駄な帯域幅は、より小さかったです、HBlockのほど小さくはありませんが(HNBヒューリスティックは独身のLSPを先取りしようとします、必要である実際の帯域幅と同様の予約された帯域幅を持っているLSPsを先取りすることを意味して。 アルゴリズムはいつもうまくいくというわけではありません、そのようなマッチが存在しないかもしれなくて、無駄な帯域幅がその場合高いかもしれないので). 先取りされた優先度は平均して、より悪いケースで最も高かったです。(それは、示します中でも滝のレベルもなぜまた、ものであったか(彼らの優先順位を見ないで、ヒューリスティックは先取りのためにLSPsを選択しようとします)最も高い)。 概要では、この方針は不十分な性能をもたらしました。
Policy PN resulted in the small number of preempted LSPs overall and small number of LSPs not successfully rerouted. Cascading is low, but bandwidth wastage is very high (overall highest bandwidth wastage). Moreover, in several cases in which rerouting happened on portions of the network that were underloaded, the heuristic HBlock preempted a smaller number of LSPs than PN.
方針PNは首尾よく別ルートで送られなかったLSPsの先取りされたLSPs総合的で少ない番号の少ない数をもたらしました。 滝は低いのですが、帯域幅消耗は非常に高いです(総合的な最も高い帯域幅消耗)。 そのうえ、いろいろな場合にどのコースを変更するかがunderloadedされたネットワークの一部で起こったかに、発見的なHBlockはLSPsのPNより少ない数を先取りしました。
Policy P selects a larger number of LSPs (when compared to PN) with low priority for preemption, and therefore it is able to successfully reroute less LSPs when compared to HBlock, HPB, HNB, or PN. The bandwidth wastage is also higher when compared to any of the heuristic results or to PB, and it could be worse if the network had LSPs with a low priority and large bandwidth, which is not the case.
方針Pは先取りのために、低い優先度で多くのLSPs(PNと比べると)を選択します、そして、したがって、HBlock、HPB、HNB、またはPNと比べると、それは首尾よくより少ないLSPsを別ルートで送ることができます。 また、発見的な結果のどれか、または、PBと比べると、帯域幅消耗も、より高いです、そして、ネットワークに低い優先度と大きい帯域幅があるLSPs(ケースでない)があるなら、より悪いかもしれないでしょうに。
Policy PB, when compared to PN, resulted in a larger number of preempted LSPs and an overall larger number of blocked LSPs (not rerouted), due to preemption. Cascading was slightly higher. Since the selected LSPs have low priority, they are not able to preempt much further and are blocked when the links are congested. Bandwidth wastage was smaller since the policy tries to minimize wastage, and preempted priority was about the same on average and worst case.
PNと比べると、方針PBは多くの先取りされたLSPsと多くの総合的な妨げられたLSPs(コースを変更しない)をもたらしました、先取りのため。 滝はわずかに高かったです。 選択されたLSPsには低い優先度があるので、リンクが混雑しているとき、彼らは、より遠くに多くを先取りできないで、妨げられます。 方針が消耗を最小にしようとするので、帯域幅消耗は、より小さかったです、そして、先取りされた優先権は平均して最も悪いケースでほぼ同じくらいでした。
The simulation results show that when preemption is based on priority, cascading is not critical since the preempted LSPs will not be able to propagate preemption much further. When the number of LSPs is considered, fewer LSPs are preempted and the chances of rerouting increases. When bandwidth wastage is considered, smaller
先取りされたLSPsがはるかに遠くに先取りを伝播できないので、滝はシミュレーションの結果が、先取りがいつ優先権に基づいているかをそれに示すことに批判的ではありません。 LSPsの数が考えられるとき、より少ないLSPsが先取りされます、そして、コースを変更するという可能性は増加します。 帯域幅消耗が、より小さく考えられるとき
de Oliveira, et al. Informational [Page 15] RFC 4829 LSP Preemption Policies for MPLS-TE April 2007
deオリベイラ、他 MPLS-Te2007年4月のための情報[15ページ]のRFC4829LSP先取り方針
LSPs are preempted in each link and the wasted bandwidth is low. The heuristic seems to combine these features, yielding the best results, especially in the case of blocking probability. When the heuristic was configured to minimize blocking probability (HBlock), small LSPs with low priority were selected for preemption on normally loaded links and fewer (larger) LSPs with low priority were selected on congested links. Due to their low priority, cascading was not an issue. Several LSPs were selected for preemption, but the rate of LSPs that were not successfully rerouted was the lowest. Since the LSPs are small, it is easier to find a new route in the network. When selecting LSPs on a congested link, fewer larger LSPs are selected improving load balance. Moreover, the bandwidth wastage was the overall lowest. In summary, the heuristic is very flexible and can be configured according to the network provider's best interest regarding the considered criteria.
LSPsは各リンクで先取りされます、そして、無駄な帯域幅は低いです。 特に確率を妨げる場合で最も良い結果をもたらして、ヒューリスティックはこれらの特徴を結合するように思えます。 ヒューリスティックがブロッキング確率(HBlock)を最小にするために構成されたとき、低い優先度がある小さいLSPsは先取りのために通常、積み込まれたリンクの上に選択されました、そして、低い優先度がある、より少ない(より大きい)のLSPsが混雑しているリンクの上に選択されました。 それらの低い優先度のために、滝は問題ではありませんでした。 数個のLSPsが先取りのために選択されましたが、首尾よく別ルートで送られなかったLSPsのレートは最も低かったです。 LSPsが小さいので、ネットワークで新しいルートを見つけるのは、より簡単です。 混雑しているリンクの上のLSPsを選択するとき、より少ないより大きいLSPsが、負荷バランスを改良しながら、選択されます。 そのうえ、帯域幅消耗は最も低く総合的でした。 概要では、ヒューリスティックは、非常にフレキシブルであり、考えられた評価基準に関するネットワーク内の提供者の最も良い関心に従って、構成できます。
For several cases, the failure of a link resulted in no preemption at all (all LSPs were able to find an alternate path in the network) or resulted in preemption of very few LSPs and subsequent successfully rerouting of the same with no cascading effect.
数個のケースのために、リンクの失敗は、先取りを全く(すべてのLSPsがネットワークで代替パスを見つけることができた)もたらさなかったか、または滝の効果なしで同じくらい首尾よくコースを変更しながら、LSPsでその後でほんのわずかの先取りをもたらしました。
It is also important to note that for all policies in use, the number of extra hops when LSPs are rerouted was not critical, showing that preempted LSPs can be rerouted on a path with the same length or a path that is slightly longer in number of hops.
また、LSPsが別ルートで送られるとき、使用中のすべての方針には、余分なホップの数が重要でなかったことに注意するのも重要です、経路でわずかに長い間ホップの数にある同じ長さか経路で先取りされたLSPsを別ルートで送ることができるのを示して。
7. Security Considerations
7. セキュリティ問題
The practice described in this document does not raise specific security issues beyond those of existing TE.
本書では説明された習慣は既存のTEのものを超えて特定の安全保障問題を提起しません。
8. Acknowledgements
8. 承認
We would like to acknowledge the input and helpful comments from Francois Le Faucheur (Cisco Systems) and George Uhl (Swales Aerospace).
フランソアLe Faucheur(シスコシステムズ)とジョージ・ウフル(低湿地Aerospace)から入力と役に立つコメントを承諾したいと思います。
de Oliveira, et al. Informational [Page 16] RFC 4829 LSP Preemption Policies for MPLS-TE April 2007
deオリベイラ、他 MPLS-Te2007年4月のための情報[16ページ]のRFC4829LSP先取り方針
9. Informative References
9. 有益な参照
[ATM-PREP] Poretsky, S. and Gannon, T., "An Algorithm for
Connection Precedence and Preemption in Asynchronous
Transfer Mode (ATM) Networks", Proceedings of IEEE ICC
1998.
[気圧予習] PoretskyとS.とギャノン、T.、「非同期通信モード(気圧)ネットワークにおける接続先行と先取りのためのアルゴリズム」、IEEE ICC1998の議事。
[DEC-PREP] Peyravian, M. and Kshemkalyani, A. D. , "Decentralized
Network Connection Preemption Algorithms", Computer
Networks and ISDN Systems, vol. 30 (11), pp. 1029-1043,
June 1998.
[12月-PREP]のPeyravianとM.とKshemkalyaniとA.D.と「分散ネットワーク接続先取りアルゴリズム」とコンピュータNetworksとISDN Systems、vol.、30(11)、ページ 1029-1043と、1998年6月。
[PREEMPTION] de Oliveira, J. C. et al., "A New Preemption Policy for
DiffServ-Aware Traffic Engineering to Minimize
Rerouting", Proceedings of IEEE INFOCOM 2002.
[PREEMPTION]deオリベイラ、J.C.他、「DiffServ意識している交通のためのコースを変更することを最小にするために設計する新しい先取り方針」、IEEE INFOCOM2002のProceedings。
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and
J. McManus, "Requirements for Traffic Engineering Over
MPLS", RFC 2702, September 1999.
[RFC2702]AwducheとD.とマルコムとJ.とAgogbuaとJ.とオデル、M.とJ.マクマナス、「MPLSの上の交通工学のための要件」RFC2702(1999年9月)。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
V., and G. Swallow, "RSVP-TE: Extensions to RSVP for
LSP Tunnels", RFC 3209, December 2001.
[RFC3209] Awduche、D.、バーガー、L.、ガン、D.、李、T.、Srinivasan、V.、およびG.が飲み込まれる、「RSVP-Te:」 「LSP TunnelsのためのRSVPへの拡大」、RFC3209、2001年12月。
[RFC3272] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X.
Xiao, "Overview and Principles of Internet Traffic
Engineering", RFC 3272, May 2002.
[RFC3272] Awduche、D.、チウ、A.、Elwalid、A.、ウィジャヤ、I.、およびX.Xiao、「概観とインターネットプリンシプルズ交通工学」(RFC3272)は2002がそうするかもしれません。
[RFC3564] Le Faucheur, F. and W. Lai, "Requirements for Support
of Differentiated Services-aware MPLS Traffic
Engineering", RFC 3564, July 2003.
[RFC3564] Le FaucheurとF.とW.レイ、「微分されたサービス意識しているMPLS交通工学のサポートのための要件」、RFC3564、2003年7月。
[RFC4124] Le Faucheur, F., "Protocol Extensions for Support of
Diffserv-aware MPLS Traffic Engineering", RFC 4124,
June 2005.
[RFC4124]Le Faucheur、F.、「Diffserv意識しているMPLS交通工学のサポートのためのプロトコル拡大」、RFC4124、2005年6月。
[RFC4126] Ash, J., "Max Allocation with Reservation Bandwidth
Constraints Model for Diffserv-aware MPLS Traffic
Engineering & Performance Comparisons", RFC 4126,
June 2005.
[RFC4126] 灰、J.、「Diffserv意識しているMPLS交通工学とパフォーマンス比較の予約帯域幅規制モデルとのマックスAllocation」、RFC4126(2005年6月)。
[RFC4127] Le Faucheur, F., "Russian Dolls Bandwidth Constraints
Model for Diffserv-aware MPLS Traffic Engineering",
RFC 4127, June 2005.
[RFC4127]Le Faucheur、F.、「ロシアのドールズ帯域幅規制はDiffserv意識しているMPLS交通工学のためにモデル化する」RFC4127、2005年6月。
de Oliveira, et al. Informational [Page 17] RFC 4829 LSP Preemption Policies for MPLS-TE April 2007
deオリベイラ、他 MPLS-Te2007年4月のための情報[17ページ]のRFC4829LSP先取り方針
[RFC4128] Lai, W., "Bandwidth Constraints Models for
Differentiated Services (Diffserv)-aware MPLS Traffic
Engineering: Performance Evaluation", RFC 4128,
June 2005.
[RFC4128] レイ、W.、「微分されたサービス(Diffserv)の意識しているMPLS交通への以下を設計する帯域幅規制モデル」 「業績評価」、RFC4128、2005年6月。
Authors' Addresses
作者のアドレス
Jaudelice C. de Oliveira (editor) Drexel University 3141 Chestnut Street (ECE Dept.) Philadelphia, PA 19104 USA
Jaudelice C.deオリベイラ(エディタ)ドレクセル大学3141チェストナット・ストリート(ECE部) フィラデルフィア、PA19104米国
EMail: jau@ece.drexel.edu
メール: jau@ece.drexel.edu
JP Vasseur (editor) Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719 USA
Boxborough、JP Vasseur(エディタ)シスコシステムズInc.1414MA01719米国マサチューセッツ通り
EMail: jpv@cisco.com
メール: jpv@cisco.com
Leonardo Chen Verizon Laboratories 40 Sylvan Rd. LA0MS55 Waltham, MA 02451 USA
レオナルドチェンベライゾン研究所40の森の通り LA0MS55MA02451ウォルサム(米国)
EMail: leonardo.c.chen@verizon.com
メール: leonardo.c.chen@verizon.com
Caterina Scoglio Kansas State University 2061 Rathbone Hall Manhattan, Kansas 66506-5204 USA
カテリーナScoglioカンザス州立大学2061ラスボーン・Hallカンザス66506-5204マンハッタン(米国)
EMail: caterina@eece.ksu.edu
メール: caterina@eece.ksu.edu
de Oliveira, et al. Informational [Page 18] RFC 4829 LSP Preemption Policies for MPLS-TE April 2007
deオリベイラ、他 MPLS-Te2007年4月のための情報[18ページ]のRFC4829LSP先取り方針
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78とwww.rfc-editor.org/copyright.htmlに含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
de Oliveira, et al. Informational [Page 19]
deオリベイラ、他 情報[19ページ]
一覧
スポンサーリンク
