Network Working Group J. Ash
Request for Comments: 3214 AT&T
Category: Standards Track Y. Lee
Ceterus Networks
P. Ashwood-Smith
B. Jamoussi
D. Fedyk
D. Skalecki
Nortel Networks
L. Li
SS8 Networks
January 2002
LSP Modification Using CR-LDP
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
Abstract
抽象
This document presents an approach to modify the bandwidth and possibly other parameters of an established CR-LSP (Constraint-based Routed Label Switched Paths) using CR-LDP (Constraint-based Routed Label Distribution Protocol) without service interruption. After a CR-LSP is set up, its bandwidth reservation may need to be changed by the network operator, due to the new requirements for the traffic carried on that CR-LSP. The LSP modification feature can be supported by CR-LDP by use of the _modify_value for the _action indicator flag_ in the LSPID TLV. This feature has application in dynamic network resources management where traffic of different priorities and service classes is involved.
この文書では、帯域幅を変更するためのアプローチを提示し、確立されたCR-LSPの可能性が他のパラメータは、サービスを中断することなくCR-LDP（制約ベースルーティングラベル配布プロトコル）を使用して、（制約ベースルーティングラベルは、パスの交換しました）。 CR-LSPがセットアップされた後、その帯域幅予約は、CR-LSP上で伝送されるトラフィックのための新たな要件に起因するネットワーク・オペレータによって変更する必要があります。 LSPの変更機能はLSPID TLVで_actionインジケータflag_ため_modify_valueを用いてCR-LDPによって支持することができます。この機能は、異なる優先順位とサービスクラスのトラフィックが関与している動的なネットワーク資源管理における用途を有します。
Table of Contents
目次
1. Conventions Used in This Document ............................ 2
2. Introduction ................................................. 2
3. LSP Modification Using CR-LDP ................................ 3
3.1 Basic Procedure for Resource Modification .................. 3
3.2 Rerouting LSPs ............................................. 5
3.3 Priority Handling .......................................... 6
3.4 Modification Failure Case Handling ......................... 6
4. Application of LSP Bandwidth Modification in Dynamic Resource
Management ................................................... 7
5. Acknowledgments .............................................. 8
6. Intellectual Property Considerations ......................... 8
7. Security Considerations ...................................... 8
8. References ................................................... 8
9. Authors' Addresses ........................................... 9
10. Full Copyright Statement ..................................... 11
L: LSP (Label Switched Path) L-id: LSPID (LSP Identifier) T: Traffic Parameters R: LSR (Label Switching Router) FEC: Forwarding Equivalence Class NHLFE: Next Hop Label Forwarding Entry FTN: FEC To NHLFE TLV: Type Length Value
L：LSP（ラベルスイッチパス）L-ID：LSPID（LSP識別子）T：トラフィックパラメータR：LSR（ラベルスイッチングルータ）FEC：転送等価クラスNHLFE：ネクストホップラベル転送エントリFTN：FECにNHLFE TLV：タイプ長さ値
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 [4].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[4]。
Consider an LSP L1 that has been established with its set of traffic parameters T0. A certain amount of bandwidth is reserved along the path of L1. Consider then that some changes are required on L1. For example, the bandwidth of L1 needs to be increased to accommodate the increased traffic on L1. Or the SLA associated with L1 needs to be modified because a different service class is desired. The network operator, in these cases, would like to modify the characteristics of L1, for example, to change its traffic parameter set from T0 to T1, without releasing the LSP L1 to interrupt the service. In some other cases, network operators may want to reroute a CR-LSP to a different path for either improved performance or better network resource utilization. In all these cases, LSP modification is required. In section 3 below, a method to modify an active LSP using CR-LDP is
トラフィックパラメータのT0のセットで確立されたLSP L1を考えてみましょう。帯域幅の一定量は、L1の経路に沿って予約されています。いくつかの変更がL1上で必要であること、次に考えてみましょう。例えば、L1の帯域幅はL1上のトラフィックの増加に対応するために増加させる必要があります。またはL1に関連付けられたSLAは、異なるサービスクラスが望まれるため、変更する必要があります。ネットワークオペレータは、これらの場合に、サービスを中断するLSP L1を放出することなく、T0からT1へのトラフィックパラメータセットを変更するために、例えば、L1の特性を変更したいと思います。いくつかの他の場合では、ネットワークオペレータは、改善された性能又はより良好なネットワークリソース使用率のいずれかのために別のパスにCR-LSPを再ルーティングすることができます。これらすべてのケースでは、LSPの修正が必要とされます。以下のセクション3においては、CR-LDPを使用してアクティブLSPを変更する方法があります
presented. The concept of LSPID in CR-LDP is used to achieve the LSP modification, without releasing the LSP and interrupting the service and, without double booking the bandwidth. In Section 4, an example is described to demonstrate an application of the presented method in dynamically managing network bandwidth requirements without interrupting service. In CR-LDP, an action indicator flag of _modify_ is used in order to explicitly specify the behavior, and allow the existing LSPID to support other networking capabilities in the future. Reference [3], RFC XXXX, specifies the action indicator flag of _modify_ for CR-LDP.
提示。 CR-LDPでLSPIDの概念は、ダブルブッキングせずに、帯域幅をLSPを解放し、サービスを中断しなくて、LSPの修正を達成するために使用されます。第4節では、例としては、動的にサービスを中断することなく、ネットワーク帯域幅の要件を管理するに提示法の適用性を実証することが記載されています。 CR-LDPは、_modify_のアクションインジケータフラグが明示的に動作を指定し、既存のLSPIDが将来的に他のネットワーク機能をサポートできるようにするために使用されます。参考文献[3]、RFC XXXXは、CR-LDPのため_modify_のアクションインジケータフラグを指定します。
LSP modification can only be allowed when the LSP is already set up and active. That is, modification is not defined nor allowed during the LSP establishment or label release/withdraw phases. Only modification requested by the ingress LSR of the LSP is considered in this document for CR-LSP. The Ingress LSR cannot modify an LSP before a previous modification procedure is completed.
LSPがすでに設定してアクティブにしたときLSPの変更のみを許可することができます。これは、変更がLSPの確立やラベルのリリース時に定義されても許可されていないされて/フェーズを撤回。 LSPのイングレスLSRによって要求された唯一の変更は、CR-LSPのために、この文書で考えられています。前回の変更手続きが完了する前にイングレスLSRは、LSPを変更することはできません。
Assume that CR-LSP L1 is set up with LSPID L-id1, which is unique in the MPLS network. The ingress LSR R1 of L1 has in its FTN (FEC To NHLFE) table FEC1 -> Label A mapping where A is the outgoing label for LSP L1. To modify the characteristics of L1, R1 sends a Label Request Message. In the message, the TLVs will have the new requested values, and the LSPID TLV is included which indicates the value of L-id1. The Traffic Parameters TLV, the ER-TLV, the Resource Class (color) TLV and the Preemption TLV can have values different from those in the original Label Request Message, which has been used to set up L1 earlier. Thus, L1 can be changed in its bandwidth request (traffic parameter TLV), its traffic service class (traffic parameter TLV), the route it traverses (ER TLV) and its setup and holding (Preemption TLV) priorities. The ingress LSR R1 now still has the entry in its FTN as FEC1 -> Label A. R1 is waiting to establish another entry for FEC1.
CR-LSP L1がMPLSネットワーク内で一意であるLSPID L-ID1、で設定されているものとします。 >ラベルAがLSP L1の発信ラベルでマッピング - L1の入口LSR R1はFTN（FECにNHLFE）表FEC1に有しています。 L1の特性を変更するには、R1は、ラベル要求メッセージを送信します。メッセージは、TLVの新しい要求された値を持つことになり、そしてLSPID TLVは、L-ID1の値を示している含まれています。トラフィックパラメータTLV、ER-TLVは、リソースクラス（カラー）TLVとプリエンプションTLVは、以前のL1を設定するために使用された元のラベル要求メッセージ内のものとは異なる値を持つことができます。このように、L1は、その帯域幅要求（トラフィックパラメータTLV）、そのトラフィックのサービスクラス（トラフィックパラメータTLV）、それは横断ルート（ER TLV）と、その設定に変更し、（プリエンプションTLV）の優先順位を保持することができます。 >ラベルA. R1 FEC1のための別のエントリを確立するために待っている - イングレスLSR R1は今もFEC1としてのFTNのエントリがあります。
When an LSR Ri along the path of L1 receives the Label Request message, its behavior is the same as that of receiving any Label request message. The only extension is that Ri examines the LSPID carried in the Label Request Message, L-id1, and identifies if it already has L-id1. If Ri does not have L-id1, Ri behaves the same as receiving a new Label Request message. If Ri already has L-id1, Ri takes the newly received Traffic Parameter TLV and computes the new bandwidth required and derives the new service class. Compared with the already reserved bandwidth for L-id1, Ri now reserves only the difference of the bandwidth requirements. This prevents Ri from doing bandwidth double booking. If a new service class is requested, Ri also prepares to receive the traffic on L1 in just the same way as handling it for a Label Request Message, perhaps using a different type of queue. Ri assigns a new label for the Label Request Message.
L1の経路に沿ってLSR Riがラベル要求メッセージを受信した場合、その動作は、任意のラベル要求メッセージを受信するのと同じです。唯一の拡張は、Riはラベル要求メッセージ、L-ID1に搬入LSPIDを調べることであり、それはすでにL-ID1を持っている場合に識別します。 RiはL-ID1を持っていない場合は、Riが新しいラベル要求メッセージを受信したと同じように動作します。 RiはすでにL-ID1を持っている場合は、Riが新たに受信されたトラフィックパラメータTLVを取り、必要な新しい帯域幅を計算し、新しいサービスクラスを派生します。 L-ID1のため、既に確保された帯域幅と比較すると、Riが今帯域幅要件の唯一の違いを留保します。これは、帯域幅のダブルブッキングをやってからRiをを防ぐことができます。新しいサービスクラスが要求された場合は、R 1はまた、おそらくキューの異なるタイプを使用して、ラベル要求メッセージのためにそれを扱うとちょうど同じようにL1上のトラフィックを受信するための準備します。 Riがラベル要求メッセージのための新しいラベルを割り当てます。
When the Label Mapping message is received, two sets of labels exist for the same LSPID. Then the ingress LSR R1 will have two outgoing labels, A and B, associated with the same FEC, where B is the new outgoing label received for LSP L1. The ingress LSR R1 can now activate the new entry in its FTN, FEC1 - > Label B. This means that R1 swaps traffic on L1 to the new label _B_ (_new_ path) for L1. The packets can now be sent with the new label B, with the new set of traffic parameters if any, on a new path, that is, if a new path is requested in the Label Request Message for the modification. All the other LSRs along the path will start to receive the incoming packets with the new label. For the incoming new label, the LSR has already established its mapping to the new outgoing label. Thus, the packets will be sent out with the new outgoing label. The LSRs do not have to implement new procedures to track the new and old characteristics of the LSP.
Label Mappingメッセージを受信したときに、ラベルの二組は、同じLSPIDのために存在します。次いで、入口LSR R1は、Bは、新しい発信ラベルはLSP L1のために受信される同一のFEC、関連付けられた2つの発信ラベル、A及びBを有するであろう。イングレスLSR R1は今そのFTNに新しいエントリをアクティブにすることができ、FEC1 - >ラベルB.これは、R1は、L1のための新しいラベル_B_（_new_パス）にL1上のトラフィックを交換することを意味します。新しいパスが修正のためのラベル要求メッセージで要求されている場合、パケットは今トラフィックパラメータの新しいセットがあればと、新しいラベルBに送信することができ、新しいパス上で、それが、あります。パスに沿った他のすべてのLSRが新しいラベルを着信パケットの受信を開始します。入ってくる新しいラベルのために、LSRはすでに新しい発信ラベルへのマッピングを確立しています。このように、パケットは新しい発信ラベルに送信されます。 LSRは、LSPの新旧の特性を追跡するための新しい方法を実装する必要はありません。
The ingress LSR R1 then starts to release the original label A for LSP L1. The Label Release Message is sent by R1 towards the down stream LSRs. The Release message carries the LSPID of L-id1 and the Label TLV to indicate which label is to be released. The Release Message is propagated to the egress LSR to release the original labels previously used for L1. Upon receiving the Label Release Message, LSR Ri examines the LSPID, L-id1, and finds out that the L-id1 has still another set of labels (incoming/outgoing) under it. Thus, the old label is released without releasing the resource in use. That is, if the bandwidth has been decreased for L1, the delta bandwidth is released. Otherwise, no bandwidth is released. This modification procedure can not only be applied to modify the traffic parameters and/or service class of an active LSP, but also to reroute an existing LSP (as described in Section 3.2 below), and/or change its setup/holding priority if desired. After the release procedure, the modification of the LSP is completed.
イングレスLSR R1は、LSP L1のためのオリジナルラベルAを解放するために開始します。ラベル解放メッセージは、ダウンストリームLSRの方にR1によって送信されます。リリースメッセージは解放されるべきラベルを示すために、L-ID1とラベルTLVのLSPIDを運びます。解放メッセージは、以前L1のために使用された元のラベルを解放するために出口LSRに伝播されます。ラベル解放メッセージを受信すると、LSR RiがLSPID、L-ID1を調べ、そしてその下にL-ID1が依然として（着信/発信）ラベルの別の組を有していることを見出します。このように、古いラベルは、使用中のリソースを解放せずにリリースされます。帯域幅がL1のために減少した場合には、デルタ帯域幅が解放されています。そうでない場合は、帯域幅が解放されません。所望であれば、この変形手順は、トラフィックパラメータ及び/又は活性LSPのサービスクラスを変更するために適用することができないだけでなく、既存のLSPを再ルーティングする（セクション下記3.2に記載されるように）、および/またはそのセットアップ/保持優先順位を変更します。リリース手順の後、LSPの修正が完了しています。
The method described above follows the normal behavior of Label Request / Mapping / Notification / Release / Withdraw procedure of a CR-LDP operated LSR with a specific action taken on an LSPID. If a Label Withdraw Message is used to withdraw a label associated with an LSPID, the Label TLV should be included to specify which label to withdraw. Since the LSPID can also be used for other feature support, an action indication flag of _modify_ assigned to the LSPID would explicitly explain the action/semantics that should be associated with the messaging procedure. The details of this flag are addressed in the CR-LDP document, Reference [3].
上述の方法は、CR-LDPのラベルリクエスト/マッピング/通知/リリース/引き出し手順の通常の動作を以下LSPIDに沿った特定のアクションとLSRを運営。ラベル撤回メッセージがLSPIDに関連付けられたラベルを撤回するために使用されている場合は、ラベルTLVを撤回するためにどのラベルを指定することが含まれるべきです。 LSPIDはまた、他の機能をサポートするために使用することができるので、LSPIDに割り当て_modify_の動作指示フラグは、明示的メッセージ手順に関連付けられるべきアクション/意味論を説明するであろう。このフラグの詳細は、文献[3]は、CR-LDP文書にアドレス指定されます。
LSP modification can also be used to reroute an existing LSP. Only modification requested by the ingress LSR of the LSP is considered in this document for CR-LSP. The Ingress LSR cannot modify an LSP before a previous modification procedure is completed.
LSPの変更は、既存のLSPを再ルーティングするために使用することができます。 LSPのイングレスLSRによって要求された唯一の変更は、CR-LSPのために、この文書で考えられています。前回の変更手続きが完了する前にイングレスLSRは、LSPを変更することはできません。
As in the previous section, consider a CR-LSP L1 with LSPID L-id1. To modify the route of the LSP, the ingress LSR R1 sends a Label Request Message. In the message, the LSPID TLV indicates L-id1 and the Explicit Route TLV is specified with some different hops from the explicit route specified in the original Label Request Message. The action indication flag has the value _modify_.
前節と同様に、LSPID L-ID1とCR-LSP L1を考えます。 LSPのルートを変更するには、進入LSR R1は、ラベル要求メッセージを送信します。メッセージに、LSPID TLVは、L-ID1を示し、明示的ルートTLVは、元のラベル要求メッセージで指定された明示的経路からいくつかの異なるホップで指定されています。アクション指示フラグは、値_modify_を有しています。
At this point, the ingress LSR R1 still has an entry in FTN as FEC1 -> Label A. R1 is waiting to establish another entry for FEC1.
R1はFEC1のための別のエントリを確立するために待っている>ラベルA. - この時点では、イングレスLSR R1はまだFEC1としてFTNでのエントリーがあります。
When an LSR Ri along the path of L1 receives the Label Request message, its behavior is the same as that of receiving a Label Request Message that modifies some other parameters of the LSP. Ri assigns a new label for the Label Request Message and forwards the message along the explicit route. It does not allocate any more resources except as described in section 3.1.
L1の経路に沿ってLSR Riがラベル要求メッセージを受信した場合、その動作は、LSPのいくつかの他のパラメータを変更するラベル要求メッセージを受信するのと同じです。 Riがラベル要求メッセージのための新しいラベルを割り当て、明示的なルートに沿ってメッセージを転送します。これは、セクション3.1に記載されている場合を除き、それ以上のリソースを割り当てません。
At another LSR Rj further along the path, the explicit route diverges from the previous route. Rj acts as Ri, but forwards the Label Request message along the new route. From this point onwards the Label Request Message is treated as setting up a new LSP by each LSR until the paths converge at later LSR Rk. The _modify_ value of the action indication flag is ignored.
さらに、経路に沿った別のLSR Rjとに、明示的な経路が以前の経路から分岐します。 RJは、RIとして機能しますが、新しいルートに沿ったラベル要求メッセージを転送します。パスが後LSR Rkとに収束するまで、この時点から以降、ラベル要求メッセージは、各LSRによって新しいLSPを設定するものとして扱われます。アクション指示フラグの_modify_値は無視されます。
At Rk and subsequent LSRs, the Label Request Message is handled as at Ri.
Rkと、後続のLSRのでは、ラベル要求メッセージは、Riをのように扱われます。
On the return path, when the Label Mapping message is received, two sets of labels for the LSPID exist where the new route coincide with the old. Only one set of labels will exist at LSRs where the routes diverge.
ラベルマッピングメッセージを受信したときに新しいルートが古いと一致するところリターンパスで、LSPIDのラベルの2セットが存在します。ラベルのみの1セットは、ルートが分岐するのLSRに存在します。
When the Label Mapping message is received at the ingress LSR R1 it has two outgoing labels, A and B, associated with the same FEC, where B is the new outgoing label received for LSP L1. R1 can now activate the new entry in the FTN, FEC1 - > Label B and de-activate the old entry FEC1 - > Label A. This means that R1 swaps traffic on L1 to the new label B. The packets are now sent with the new label B, on the new path.
Label Mappingメッセージを入口LSR R1で受信される場合には、Bは、新しい発信ラベルはLSP L1のために受信される同一のFEC、関連付けられた2つの発信ラベル、A及びBを有します。これは、R1は、パケットが、今で送信された新しいラベルBにL1上のトラフィックを交換することを意味>ラベルA. - >ラベルBと古いエントリを非アクティブFEC1 - R1は今FEC1、FTNに新しいエントリをアクティブにすることができます新しいラベルB、新しいパス上。
The ingress LSR R1 then starts to release the original label A for LSP L1. The Label Release Message is sent by R1 towards the down stream LSRs following the original route. The Release message carries the LSPID of L-id1 and the Label TLV to indicate which label is to be released. At each LSR the old label is released - no further action is required to change the path of the data packets which are already following the new route programmed by the Label Mapping message.
イングレスLSR R1は、LSP L1のためのオリジナルラベルAを解放するために開始します。ラベル解放メッセージは、元のルート以下のダウンストリームLSRの方にR1によって送信されます。リリースメッセージは解放されるべきラベルを示すために、L-ID1とラベルTLVのLSPIDを運びます。古いラベルが解放され、各LSRで - それ以上のアクションは、すでにラベルマッピングメッセージによってプログラム新しいルートを以下れるデータパケットのパスを変更する必要はありません。
At some LSRs, where the routes diverged, there is only one label for the LSPID. For example, between Rj and Rk, the Label Release Message will follow the old route. At LSRs between Rj and Rk only the labels from the original route will exist for LSPID L-id1. At these LSRs the LSPID TLV does not need to be examined to release the correct label, but it must still be updated and passed on to the next LSR as the Label Release message is propagated. In this way, at Rk where the routes converge, the downstream LSR will know which label to release and can continue to forward the Label Release Message along the old route.
ルートが分岐し、いくつかのLSRでは、LSPIDのための唯一つのラベルがあります。例えば、RjのとRkの間、ラベル解放メッセージは、古いルートに従います。 R 1およびRkの間のLSRに元の経路からのみラベルがLSPID L-ID1のために存在します。これらのLSRではLSPID TLVは、正しいラベルを解放するために検討する必要はありませんが、それはまだ更新され、ラベル解放メッセージが伝播されるように次のLSRに渡さなければなりません。このように、ルートが収束Rkとで、下流LSRは解放するためにどのラベルを知っているだろうと、古いルートに沿ったラベル解放メッセージを転送し続けることができます。
When sending a Label Request Message for an active LSP L1 to request changes, the setup priority used in the label Request Message can be different from the one used in the previous Label Request Message, effectively indicating the priority of this _modification_ request. Network operators can use this feature to decide what priority is to be assigned to a modification request, based on their policies/algorithms and other traffic situations in the network. For example, the priority for modification can be determined by the priority of the customer/LSP. If a customer has exceeded the reserved bandwidth of its VPN LSP tunnel by too much, the modification request's priority may be given as a higher value. The Label Request message for the modification of an active LSP can also be sent with a holding priority different from its previous one. This effectively changes the holding priority of the LSP. Upon receiving a Label Request Message that requests a new holding priority, the LSR assigns the new holding priority to the bandwidth. That is, the new holding priority is assigned to both the existing incoming / outgoing labels and the new labels to be established for the LSPID in question. In this way self-bumping is prevented.
変更を要求するためにアクティブLSP L1用のラベル要求メッセージを送信する場合、ラベル要求メッセージで使用される設定の優先順位を効果的にこの_modification_要求の優先度を示す、以前のラベル要求メッセージで使用されるものとは異なることができます。ネットワークオペレータは彼らの政策/アルゴリズムや、ネットワーク内の他の交通状況に基づいて、変更要求に割り当てられるべきであるものを優先順位を決定するために、この機能を使用することができます。例えば、修飾のための優先順位は、顧客/ LSPの優先順位により決定することができます。顧客はあまりすることにより、そのVPN LSPトンネルの予約された帯域幅を超えた場合は、変更要求の優先度が高い値として与えてもよいです。アクティブLSPの修飾のためのラベル要求メッセージは、その前のものとは異なる保持優先的に送信することができます。これは、効果的にLSPの保持優先度を変更します。新しい保持優先度を要求ラベル要求メッセージを受信すると、LSRは、帯域幅に新しい保持優先度を割り当てます。それは、新しい保持優先度は、既存の着信/発信ラベルや質問にLSPIDのために確立される新しいラベルの両方に割り当てられています。このように、自己突沸を防止しています。
A modification attempt may fail due to insufficient resource or other situations. A Notification message is sent back to the ingress LSR R1 to indicate the failure of Label Request Message that intended to modify the LSP. A retry may be attempted if desired by the network operator. If the LSP on the original path failed when a modification attempt is in progress, the attempt should be aborted by using the Label Abort Request message as specified in the LDP document [5].
修正の試みが不十分なリソースまたはその他の状況に失敗することがあります。通知メッセージは、LSPを修正することを目的とラベル要求メッセージの失敗を示すために、入口LSR R1に送り返されます。ネットワークオペレータによって所望される場合、再試行が試みてもよいです。改変の試みが進行中であるときに元の経路上のLSPに障害が発生した場合LDP文献[5]で指定されるように、試みはラベルアボート要求メッセージを使用して中止されるべきです。
In the event of a modification failure, all modifications to the LSP including the holding priority must be restored to their original values.
修飾に障害が発生した場合に、保持優先度を含むLSPに対するすべての変更は、元の値に復元しなければなりません。
4. Application of LSP Bandwidth Modification in Dynamic Resource Management
動的なリソース管理におけるLSPの帯域幅変更の4.アプリケーション
In this section, we gave an example of dynamic network resource management using the LSP bandwidth modification capability. The details of this example can be found in a previous internet-draft [2]. Assume that customers or services are assigned with given CR-LSPs. These customers/services are assigned with one of three priorities: key, normal or best effort. The network operator does not want to bump any LSPs during an LSP setup, so after these CR-LSPs are set up, their holding priorities are all assigned as the highest value.
このセクションでは、我々は、LSP帯域幅の変更機能を使用して動的なネットワークリソース管理の一例を示しました。この例の詳細は、以前のインターネットドラフトに記載されています[2]。顧客やサービスが与えられたCR-LSPをと割り当てられていることを前提としています。キー、ノーマルまたはベストエフォート：これらの顧客/サービスは、3つの優先事項の一つで割り当てられています。ネットワークオペレータは、LSPのセットアップ時に任意のLSPをぶつけたくないので、これらのCR-のLSPが設定された後、その保持優先順位は、すべての最高値として割り当てられています。
The network operator wants to control the resource on the links of the LSRs, so each LSR keeps the usage status of its links. Based on the usage history, each link is assigned a current threshold priority Pi, which means that the link has no bandwidth available for a Label Request with a setup priority lower than Pi. When an LSP's bandwidth needs to be modified, the operator uses a policy-based algorithm to assign a priority for its modification request, say Mp for LSP L2. The ingress LSR then sends a Label Request message with Setup Priority = Mp. If there is sufficient bandwidth on the link for the modification, and the Setup priority in the Label Request Message is higher in priority (Mp numerically smaller) than the Pi threshold of the link, the Label Request Message will be accepted by the LSR. Otherwise, the Label Request message will be rejected with a Notification message which indicates that there are insufficient resources. It should also be noted that when OSPF (or IS-IS) floods the available-link-bandwidth information, the available bandwidth associated with a priority lower than Pi (numerical value bigger) should be interpreted as _0_.
ネットワークオペレータは、LSRのリンクの上のリソースを制御したいので、各LSRは、そのリンクの使用状況を保持します。使用履歴に基づいて、各リンクは、リンクがパイよりも低く設定優先順位のラベル要求のために利用可能な帯域幅を持っていないことを意味し、現在のしきい値の優先パイを、割り当てられています。 LSPの帯域幅を変更する必要がある場合、オペレータは、その変更要求の優先順位を割り当てるためのポリシーベースのアルゴリズムを使用して、LSP L2ため融点を言います。入口LSRは、セットアップ優先=融点とラベル要求メッセージを送信します。十分な変更のためのリンクの帯域幅、およびセットアップの優先順位は、ラベル要求メッセージに存在する場合は、リンクのパイのしきい値より（Mpは数値的に小さく）、優先度が高い、ラベル要求メッセージは、LSRによって受け入れられます。それ以外の場合は、ラベル要求メッセージは、リソースが不足していることを示す通知メッセージで拒否されます。またOSPF（またはIS-IS）は、利用可能なリンク帯域幅情報と、PIよりも低い優先度に関連付けられた利用可能な帯域幅をフラッディングことに留意すべきである（大きい数値）_0_として解釈されるべきです。
This example based on a priority threshold Pi is implementation specific, and illustrates the flexibility of the modification procedure to prioritize and control network resources. The calculation of Mp can be network and service dependent, and is based on the operator's routing policy. For example, the operator may assign a higher priority (lower Mp value) to L2 bandwidth modification if L2 belongs to a customer or service with _Key_ priority. The operator may also collect the actual usage of each LSP and assign a lower priority (higher Mp) to L2 bandwidth-increase modification if, for example, in the past week L2 has exceeded its reserved bandwidth by 2 times on the average. In addition, an operator may try to increase the bandwidth of L2 on its existing path unsuccessfully if there is insufficient bandwidth available on L2. In that case, the operator is willing to increase the bandwidth of another LSP, L3, with the same ingress/egress LSRs as L2, in order to increase the overall ingress/egress bandwidth allocation. However, in this case the L3 bandwidth modification is performed with a lower priority (higher Mp value) since L3 is routed on a secondary path, which results in the higher bandwidth allocation priority being given to the LSPs that are on their primary paths [2].
優先しきい値pIに基づいて、この例では、実装固有であり、優先順位の変更手順及び制御ネットワークリソースの柔軟性を示します。融点の計算は、ネットワーク及びサービスに依存することができ、オペレータのルーティングポリシーに基づいています。 L2は_Key_優先の顧客又はサービスに属している場合、例えば、操作者は、L2帯域幅の変更に優先順位の高い（低い融点の値）を割り当てることができます。オペレータは、各LSPの実際の使用状況を収集した場合、L2帯域増修飾に低い優先度（より高い融点）を割り当てることができ、例えば、先週L2に平均で2倍の帯域予約を超えています。また、オペレータは、L2で利用可能な十分な帯域幅がある場合に失敗し、その既存のパスにL2の帯域幅を増加しようとするかもしれません。その場合、オペレータは、全体的な入力/出力帯域幅の割り当てを増加させるために、L2と同じ入口/出口LSRsと、別のLSP、L3の帯域幅を増加させるために喜んでです。 L3は、そのプライマリパス上にあるのLSPに与えられるより高い帯域割当優先順位をもたらす二次経路上にルーティングされるので、この場合にはL3帯域幅修飾は低い優先度（より高い融点の値）を用いて実施されている[2 ]。
The authors would like to acknowledge the careful review and comments of Adrian Farrel.
著者は、慎重に検討し、エードリアンファレルのコメントを確認したいと思います。
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights.
IETFは、この文書に含まれる仕様の一部またはすべてについて記載知的財産権について通知されています。詳細については、要求された権利のオンラインリストを参照してください。
Protection against modification to LSPs by malign agents has to be controlled by the MPLS domain.
悪性物質によるのLSPへの変更に対する保護は、MPLSドメインによって制御されなければなりません。
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[1]ブラドナーの、S.、 "インターネット標準化プロセス - リビジョン3"、BCP 9、RFC 2026、1996年10月。
[2] Ash, J., "Traffic Engineering & QoS Methods for IP-, ATM-, & TDM-Based Multiservice Networks", Work in Progress.
[2]アッシュ、J.、 "トラフィックエンジニアリング＆IP-、ATM-、＆TDMベースのマルチサービスネットワークのためのQoSの方法" が進行中で働いています。
[3] Jamoussi, B., Editor, Andersson, L., Callon, R., Dantu, R., Wu, L., Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M., Gray, E., Heinanen, J., Kilty, T. and A. Malis, "Constraint-based LSP Setup Using LDP", RFC 3212, January 2002.
[3] Jamoussi、B.、エディタ、アンダーソン、L.、Callon、R.、Dantu、R.、ウー、L.、Doolan、P.、Worster、T.、フェルドマン、N.、Fredette、A.、 Girish、M.、グレー、E.、Heinanen、J.、Kilty、T.およびA. Malis、 "LDPを使用して制約ベースLSPセットアップ"、RFC 3212、2002年1月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[5] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and B. Thomas, "LDP Specification", RFC 3036, January 2001.
[5]アンダーソン、L.、Doolan、P.、フェルドマン、N.、Fredette、A.及びB.トーマス、 "LDP仕様"、RFC 3036、2001年1月。
[6] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[6]ローゼン、E.、Viswanathanの、A.とR. Callon、 "マルチプロトコルラベルスイッチングアーキテクチャ"、RFC 3031、2001年1月。
[7] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999.
[7] Awduche、D.、マルコム、J.、Agogbua、J.、オデル、M.及びJ.マクマナス、 "トラフィック過剰性能MPLSのための要件"、RFC 2702、1999年9月。
[8] Ash, J., Girish, M., Gray, E., Jamoussi,B. and G. Wright, "Applicability Statement for CR-LDP", RFC 3213, January 2002.
[8]アッシュ、J.、Girish、M.、グレー、E.、Jamoussi、B。そして、G.ライト、 "CR-LDPのための適用性に関する声明"、RFC 3213、2002年1月。
Gerald R. Ash AT&T Room MT D5-2A01 200 Laurel Avenue Middletown, NJ 07748 USA Phone: 732-420-4578 EMail: gash@att.com
ジェラルドR.アッシュAT＆TルームMT D5-2A01 200ローレルアベニューミドルタウン、NJ 07748 USA電話：732-420-4578 Eメール：gash@att.com
Bilel Jamoussi Nortel Networks Corp. 600 Tech Park Billerica, MA 01821 USA Phone: 978-288-4506 EMail: jamoussi@NortelNetworks.com
Bilel Jamoussiノーテルネットワークス（株）600ハイテクパークビレリカ、MA 01821 USA電話：978-288-4506 Eメール：jamoussi@NortelNetworks.com
Peter Ashwood-Smith Nortel Networks Corp. P O Box 3511 Station C Ottawa, ON K1Y 4H7 Canada Phone: +1 613 763-4534 EMail: petera@NortelNetworks.com
ピーター・アッシュウッド・スミスK1Y 4H7カナダの携帯電話にノーテルネットワークス（株）P Oボックス3511駅のCオタワ、：+1 613 763から4534 Eメール：petera@NortelNetworks.com
Darek Skalecki Nortel Networks Corp. P O Box 3511 Station C Ottawa, ON K1Y 4H7 Canada Phone: +1 613 765-2252 EMail: dareks@nortelnetworks.com
Darek Skaleckiノーテルネットワークス株式会社K1Y 4H7カナダの携帯電話にP Oボックス3511駅のCオタワ、：+1 613 765から2252 Eメール：dareks@nortelnetworks.com
Young Lee Ceterus Networks EMail: ylee@ceterusnetworks.com
ヤング・リーCeterusネットワークEメール：ylee@ceterusnetworks.com
Li Li SS8 Networks 495 March Rd., 5th Floor Kanata, Ontario K2K 3G1 Canada Phone: +1 613 592-2100 ext. 3228 EMail: lili@ss8networks.com
李SS8 Networksの495月Rdを、5階カナタ、オンタリオK2K 3G1カナダ電話：+1 613 592から2100内線。 3228 Eメール：lili@ss8networks.com
Don Fedyk Nortel Networks Corp. 600 Tech Park Billerica, MA 01821 USA Phone: 978-288-3041 EMail: dwfedyk@nortelnetworks.com
ドン・ルブランノーテルネットワークス株式会社600ハイテクパーク、ビレリカ、MA 01821 USA電話：978-288-3041 Eメール：dwfedyk@nortelnetworks.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。