[要約] RFC 3214は、CR-LDPを使用したLSPの変更に関する規格であり、LSPの変更手順とプロトコルを定義しています。目的は、LSPの変更を効率的かつ信頼性の高い方法で実現することです。
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
CR-LDPを使用したLSP変更
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.
Copyright（c）The Internet Society（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-LDP（制約ベースのルーティングラベル分布プロトコル）を使用して、確立されたCR-LSP（制約ベースのルーティングラベルスイッチングパス）の帯域幅と場合によっては他のパラメーターを変更するアプローチを示します。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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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 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.
トラフィックパラメーターのセットT0で確立されたLSP L1を考えてみましょう。L1の経路に沿って、一定量の帯域幅が予約されています。次に、L1にいくつかの変更が必要であることを考えてください。たとえば、L1のトラフィックの増加に対応するには、L1の帯域幅を増やす必要があります。または、異なるサービスクラスが必要なため、L1に関連付けられているSLAを変更する必要があります。これらの場合、ネットワークオペレーターは、LSP L1をリリースしてサービスを中断することなく、T0からT1にセットを変更するなど、L1の特性を変更したいと考えています。他の場合には、ネットワークオペレーターがCR-LSPを別のパスに再ルーティングして、パフォーマンスを改善するか、ネットワークリソースの使用率を向上させたい場合があります。これらすべての場合において、LSPの変更が必要です。以下のセクション3では、CR-LDPを使用してアクティブなLSPを変更する方法が表示されます。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のIngress LSRによって要求された修正のみが、CR-LSPのこのドキュメントで考慮されています。Ingress 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がLSPID L-ID1を使用してセットアップされていると仮定します。これはMPLSネットワークで一意です。L1のIngress LSR R1には、FTN（FECからNHLFE）テーブルFEC1にあります。L1の特性を変更するために、R1はラベルリクエストメッセージを送信します。メッセージでは、TLVには新しい要求された値があり、L-ID1の値を示すLSPID TLVが含まれています。トラフィックパラメーターTLV、ER-TLV、リソースクラス（色）TLV、およびプリエンプションTLVは、L1を以前に設定するために使用されていた元のラベルリクエストメッセージの値とは異なる値を持つことができます。したがって、L1は、帯域幅要求（トラフィックパラメーターTLV）、トラフィックサービスクラス（トラフィックパラメーターTLV）、それが通過するルート（ER TLV）、およびセットアップと保持（先制TLV）優先順位で変更できます。Ingress LSR R1は、FEC1->ラベルAとしてFTNにエントリを依然として持っています。R1は、FEC1の別のエントリを確立するのを待っています。
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は帯域幅のダブル予約を行うことを防ぎます。新しいサービスクラスが要求されている場合、RIは、おそらく異なるタイプのキューを使用して、ラベル要求メッセージの処理と同じ方法で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.
ラベルマッピングメッセージを受信すると、同じLSPIDに対して2セットのラベルが存在します。イングレスLSR R1には、同じFECに関連付けられた2つの発信ラベルAとBがあり、BはLSP L1の新しい発信ラベルです。Ingress LSR R1は、FTN FEC1->ラベルBの新しいエントリをアクティブにすることができます。これは、R1がL1のトラフィックをL1の新しいラベル_B_（_New_ PATH）に交換することを意味します。パケットは、新しいラベル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.
Ingress LSR R1は、LSP L1の元のラベルAのリリースを開始します。ラベルリリースメッセージは、R1によってダウンストリームLSRに送信されます。リリースメッセージには、L-ID1とラベルTLVのLSPIDが含まれ、どのラベルがリリースされるかを示します。リリースメッセージは、L1に以前に使用されていた元のラベルをリリースするために、Egress 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].
上記の方法は、LSPIDで特定のアクションを使用して、CR-LDP操作LSRのラベルリクエスト /マッピング /通知 /リリース /撤回手順の通常の動作に従います。LSPIDに関連付けられたラベルを撤回するためにラベルの撤回メッセージを使用している場合、撤回するラベルを指定するためにラベルTLVを含める必要があります。LSPIDは他の機能サポートにも使用できるため、LSPIDに割り当てられた_modify_のアクション表示フラグは、メッセージング手順に関連付けられるアクション/セマンティクスを明示的に説明します。このフラグの詳細については、CR-LDP文書、参照[3]に記載されています。
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のIngress LSRによって要求された修正のみが、CR-LSPのこのドキュメントで考慮されています。Ingress 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のルートを変更するために、Ingress 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.
この時点で、Ingress LSR R1はFEC1->ラベルAとしてFTNのエントリをまだ持っています。R1はFEC1の別のエントリを確立するのを待っています。
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およびその後のLSRSでは、ラベル要求メッセージは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つのラベルが存在します。ルートが分岐するLSRSには、1つのラベルのセットのみが存在します。
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.
Ingress LSR R1でラベルマッピングメッセージが受信されると、同じFECに関連付けられた2つの発信ラベルAとBがあり、BはLSP L1の新しい発信ラベルです。R1は、FTN、FEC1->ラベルBの新しいエントリをアクティブにすることができ、古いエントリFEC1->ラベルAを除去することができます。これは、R1がL1のトラフィックを新しいラベルBに交換することを意味します。新しいパス上の新しいラベル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.
Ingress LSR R1は、LSP L1の元のラベルAのリリースを開始します。ラベルリリースメッセージは、R1によって元のルートに続いてダウンストリームLSRに向かって送信されます。リリースメッセージには、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のラベルは1つだけです。たとえば、RJとRKの間で、ラベルリリースメッセージは古いルートに従います。RJとRKの間のLSRSでは、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のラベル要求メッセージを送信して変更を要求する場合、ラベルリクエストメッセージで使用されるセットアップの優先順位は、以前のラベルリクエストメッセージで使用されているものとは異なる場合があります。ネットワークオペレーターは、この機能を使用して、ネットワーク内のポリシー/アルゴリズムおよびその他のトラフィック状況に基づいて、変更リクエストに割り当てられる優先度を決定できます。たとえば、変更の優先順位は、顧客/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].
リソースやその他の状況が不十分なため、変更の試みが失敗する可能性があります。通知メッセージがIngress LSR R1に送信され、LSPを変更することを意図したラベルリクエストメッセージの障害を示します。ネットワークオペレーターが必要とする場合、再試行を試みることができます。変更の試みが進行中のときに元のパスのLSPが失敗した場合、LDPドキュメント[5]で指定されているラベルAbort要求メッセージを使用して試行を中止する必要があります。
In the event of a modification failure, all modifications to the LSP including the holding priority must be restored to their original values.
変更の障害が発生した場合、保持優先度を含むLSPのすべての変更は、元の値に復元する必要があります。
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はリンクの使用状況を保持します。使用履歴に基づいて、各リンクには現在のしきい値優先度PIが割り当てられます。つまり、リンクには、PIよりも低いセットアップ優先度を持つラベルリクエストに使用可能な帯域幅がありません。LSPの帯域幅を変更する必要がある場合、オペレーターはポリシーベースのアルゴリズムを使用して、LSP L2のMPなどの修正要求の優先順位を割り当てます。Ingress LSRは、セットアップPriority = MPでラベル要求メッセージを送信します。変更のためのリンクに十分な帯域幅があり、ラベル要求メッセージのセットアップの優先度がリンクのPIしきい値よりも優先度（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に基づくこの例は、実装固有であり、ネットワークリソースを優先および制御するための変更手順の柔軟性を示しています。MPの計算は、ネットワークおよびサービスに依存する可能性があり、オペレーターのルーティングポリシーに基づいています。たとえば、L2が_Key_ Priorityの顧客またはサービスに属している場合、オペレーターはL2帯域幅の変更により高い優先度（MP値の低下）を割り当てることができます。また、オペレーターは各LSPの実際の使用法を収集し、L2が平均で予約帯域幅を2回超えた場合、L2帯域幅の増加の変更に低い優先度（より高いMP）を割り当てることもできます。さらに、オペレーターは、L2で利用可能な帯域幅が不十分な場合、既存のパスでL2の帯域幅を失敗させようとする場合があります。その場合、オペレーターは、L2と同じ侵入/出口LSRを備えた別のLSP L3の帯域幅を、全体的な侵入/出口帯域幅の割り当てを増やすことをいとわない。ただし、この場合、L3はセカンダリパスにルーティングされるため、L3帯域幅変更は優先度が低い（MP値が高い）ため実行されます。]。
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.
MALIGNエージェントによるLSPの変更に対する保護は、MPLSドメインによって制御する必要があります。
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[1] Bradner、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] Ash、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.、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。、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[5] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and B. Thomas, "LDP Specification", RFC 3036, January 2001.
[5] Andersson、L.、Doolan、P.、Feldman、N.、Fredette、A。and B. Thomas、「LDP仕様」、RFC 3036、2001年1月。
[6] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[6] Rosen、E.、Viswanathan、A。and R. Callon、「Multiprotocol Label Switching Architecture」、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.、Malcolm、J.、Agogbua、J.、O'Dell、M。、およびJ. McManus、「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] Ash、J.、Girish、M.、Gray、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ローレルアベニューミドルタウン、ニュージャージー州07748 USA電話：732-420-4578メール：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 Nortel Networks Corp. 600 Tech Park Billerica、MA 01821 USA電話：978-288-4506電子メール：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 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
Peter Ashwood-Smith Nortel Networks Corp. P O Box 3511 Station C Ottawa、K1Y 4H7カナダ電話：1 613 763-4534メール：Petera@nortelnetworks.com電話：1 613 765-2252メール：dareks@nortelnetworks.com
Young Lee Ceterus Networks EMail: ylee@ceterusnetworks.com
Young Lee Ceterus Networks Email：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
Li Li SS8 Networks 495 March Rd。、5階のカナタ、オンタリオK2K 3G1カナダ電話：1 613 592-2100 Ext。3228メール：lili@ss8networks.com
Don Fedyk Nortel Networks Corp. 600 Tech Park Billerica, MA 01821 USA Phone: 978-288-3041 EMail: dwfedyk@nortelnetworks.com
Don Fedyk Nortel Networks Corp. 600 Tech Park Billerica、MA 01821 USA電話：978-288-3041メール：dwfedyk@nortelnetworks.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。