[要約] RFC 6511は、RSVP-TEラベルスイッチパスの非ペニュルティメイトホップポッピング動作とアウトオブバンドマッピングに関する規格です。このRFCの目的は、ネットワークの効率性と信頼性を向上させるために、RSVP-TEラベルスイッチパスの動作を定義することです。
Internet Engineering Task Force (IETF) Z. Ali
Request for Comments: 6511 G. Swallow
Category: Standards Track Cisco Systems
ISSN: 2070-1721 R. Aggarwal
Juniper Networks
February 2012
Non-Penultimate Hop Popping Behavior and Out-of-Band Mapping for RSVP-TE Label Switched Paths
rsvp-teラベルスイッチ付きパスの非ペナルなホップポップ動作と帯域外マッピング
Abstract
概要
There are many deployment scenarios that require an egress Label Switching Router (LSR) to receive binding of the Resource Reservation Protocol - Traffic Engineering (RSVP-TE) Label Switched Path (LSP) to an application and a payload identifier using some "out-of-band" (OOB) mechanism. This document defines protocol mechanisms to address this requirement. The procedures described in this document are equally applicable for point-to-point (P2P) and point-to-multipoint (P2MP) LSPs.
リソース予約プロトコル - トラフィックエンジニアリング（RSVP-TE）ラベルスイッチ付きパス（LSP）のバインディングを受信するために、出力ラベルスイッチルーター（LSR）が「いくつかの「Out of」を使用してペイロード識別子のバインディングを受信する必要がある多くの展開シナリオがあります。-BAND "（OOB）メカニズム。このドキュメントは、この要件に対処するためのプロトコルメカニズムを定義しています。このドキュメントで説明されている手順は、ポイントツーポイント（P2P）およびポイントツーマルチポイント（P2MP）LSPに等しく適用できます。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 5741のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6511.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6511で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。あなたの権利と制限を尊重して説明しているので、これらの文書を注意深く確認してください
to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書に。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................3
2. RSVP-TE Signaling Extensions ....................................3
2.1. Signaling Non-PHP Behavior .................................3
2.2. Signaling OOB Mapping Indication ...........................5
2.3. Relationship between OOB and Non-PHP Flags .................6
2.4. Egress Procedure for Label Binding .........................6
3. Security Considerations .........................................7
4. IANA Considerations .............................................7
4.1. Attribute Flags for LSP Attributes Object ..................7
4.2. New RSVP Error Sub-Code ....................................8
5. Acknowledgements ................................................8
6. References ......................................................8
6.1. Normative References .......................................8
6.2. Informative References .....................................9
When Resource Reservation Protocol - Traffic Engineering (RSVP-TE) is used for applications like Multicast Virtual Private Network (MVPN) [RFC6513] and Virtual Private LAN Service (VPLS) [RFC4761], an egress Label Switching Router (LSR) receives the binding of the RSVP-TE Label Switched Path (LSP) to an application and a payload identifier using an "out-of-band" (OOB) mechanism (e.g., Border Gateway Protocol (BGP)). In such cases, the egress LSR cannot make correct forwarding decisions until such OOB mapping information is received. Furthermore, in order to apply the binding information, the egress LSR needs to identify the incoming LSP on which traffic is coming.
リソース予約プロトコル-Traffic Engineering（RSVP -TE）がマルチキャスト仮想プライベートネットワーク（MVPN）[RFC6513]や仮想プライベートLANサービス（VPLS）[RFC4761]などのアプリケーションに使用される場合、Eugressラベルスイッチングルーター（LSR）がバインディングを受け取ります。RSVP-TEラベルの「パス（LSP）は、「帯域外」（OOB）メカニズム（Border Gateway Protocol（BGP）など）を使用したアプリケーションとペイロード識別子にスイッチされたパス（LSP）のアプリケーションとペイロード識別子のものです。そのような場合、出力LSRは、そのようなOOBマッピング情報を受信するまで正しい転送決定を下すことはできません。さらに、拘束力のある情報を適用するには、出力LSRは、トラフィックが来ている入っているLSPを特定する必要があります。
Therefore, non-Penultimate Hop Popping (non-PHP) behavior is required to apply OOB mapping. Non-PHP behavior requires the egress LSRs to assign a non-NULL label for the LSP being signaled.
したがって、OOBマッピングを適用するには、非ペニル化ホップポップ（非PHP）動作が必要です。非PHPの動作には、LSPがシグナルを課されるために非ヌルラベルを割り当てるには、出力LSRが必要です。
There are other applications that require non-PHP behavior. When RSVP-TE point-to-multipoint (P2MP) LSPs are used to carry IP multicast traffic non-PHP behavior enables a leaf LSR to identify the P2MP TE LSP on which traffic is received. Hence, the egress LSR can determine whether traffic is received on the expected P2MP LSP and discard traffic that is not received on the expected P2MP LSP. Non-PHP behavior is also required to determine the context of upstream assigned labels when the context is a MPLS LSP. Non-PHP behavior may also be required for MPLS Transport Profile (MPLS-TP) LSPs [RFC5921].
非PHP動作を必要とする他のアプリケーションがあります。RSVP-TEポイントツーマルチポイント（P2MP）LSPが使用される場合、IPマルチキャストトラフィックの運搬ではありません。したがって、出力LSRは、予想されるP2MP LSPでトラフィックが受信されるかどうかを判断し、予想されるP2MP LSPで受信されないトラフィックを破棄できます。コンテキストがMPLS LSPである場合、上流に割り当てられたラベルのコンテキストを決定するには、非PHPの動作も必要です。MPLS輸送プロファイル（MPLS-TP）LSP [RFC5921]には、非PHPの動作も必要になる場合があります。
This document defines two new flags in the Attributes Flags TLV of the LSP Attributes object defined in [RFC5420]: one flag for communication of non-PHP behavior and one flag to indicate that the binding of the LSP to an application and a payload identifier (Payload ID) needs to be learned via an out-of-band mapping mechanism. As there is one-to-one correspondence between bits in the Attribute Flags TLV and the Record Route Object (RRO) Attributes subobject, corresponding flags to be carried in the RRO Attributes subobject are also defined.
このドキュメントでは、[RFC5420]で定義されているLSP属性オブジェクトの属性フラグTLVの2つの新しいフラグを定義します。非PHP動作の通信のための1つのフラグと、LSPのアプリケーションとペイロード識別子への結合（ペイロードID）バンド外マッピングメカニズムを介して学習する必要があります。属性フラグTLVのビットとレコードルートオブジェクト（RRO）属性の間に1対1の対応があるため、サブオブジェクトに掲載される対応するフラグも定義されています。
The procedures described in this document are equally applicable for point-to-point (P2P) and P2MP LSPs. Specification of the OOB communication mechanism(s) is beyond the scope of this document.
このドキュメントで説明されている手順は、ポイントツーポイント（P2P）およびP2MP LSPに等しく適用できます。OOB通信メカニズムの仕様は、このドキュメントの範囲を超えています。
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 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
This section describes the signaling extensions required to address the above-mentioned requirements.
このセクションでは、上記の要件に対処するために必要なシグナリング拡張について説明します。
In order to request non-PHP behavior for an RSVP-TE LSP, this document defines a new flag in the Attributes Flags TLV of the LSP Attributes object defined in [RFC5420]:
RSVP-TE LSPの非PHP動作を要求するために、このドキュメントは、[RFC5420]で定義されているLSP属性オブジェクトの属性フラグTLVの新しいフラグを定義します。
Bit Number 7: Non-PHP behavior flag
ビット番号7：非PHP動作フラグ
In order to indicate to the ingress LSR that the egress LSR recognizes the "Non-PHP behavior flag", the same bit is used in the Flags field of the Record Route Object (RRO) Attributes subobject.
出力LSRが「非PHP動作フラグ」を認識することを侵入LSRに示すために、同じビットがレコードルートオブジェクト（RRO）のフラグフィールドで使用されます。
An ingress LSR sets the "Non-PHP behavior flag" to signal that the egress LSRs SHOULD assign a non-NULL label for the LSP being signaled. This flag MUST NOT be modified by any other LSRs in the network. LSRs other than the egress LSRs SHOULD ignore this flag.
Ingress LSRは、「非PHPの動作フラグ」を設定して、出力LSRがシグナリングされているLSPの非ヌルラベルを割り当てる必要があることを示します。このフラグは、ネットワーク内の他のLSRによって変更されてはなりません。出力LSR以外のLSRは、このフラグを無視する必要があります。
If an egress LSR receiving the Path message supports the LSP Attributes object and the Attributes Flags TLV and also recognizes the "Non-PHP behavior flag", it MUST allocate a non-NULL local label. The egress LSR MUST also set the "Non-PHP behavior flag" in the Flags field of the RRO Attributes subobject.
パスメッセージを受信する出力LSRがLSP属性オブジェクトと属性フラグTLVをサポートし、「非PHP行動フラグ」も認識している場合、非ヌルローカルラベルを割り当てる必要があります。出力LSRは、RRO属性Subobjectのフラグフィールドに「非PHP動作フラグ」も設定する必要があります。
If the egress LSR
出口lsrの場合
- supports the LSP Attributes object but does not recognize the Attributes Flags TLV; or
- LSP属性オブジェクトをサポートしますが、属性フラグTLVを認識しません。また
- supports the LSP Attributes object and recognizes the Attributes Flags TLV, but does not recognize the "Non-PHP behavior flag";
- LSP属性オブジェクトをサポートし、属性フラグTLVを認識しますが、「非PHP行動フラグ」を認識しません。
then it silently ignores the request according to the processing rules of [RFC5420].
次に、[RFC5420]の処理ルールに従って、黙ってリクエストを無視します。
An ingress LSR requesting non-PHP behavior SHOULD examine the "Non-PHP behavior flag" in the Flags field of the RRO Attributes subobject and MAY send a Path Tear to the egress, which has not set the "Non-PHP behavior flag". An ingress LSR requesting non-PHP behavior MAY also examine the label value corresponding to the egress LSR(s) in the RRO and MAY send a Path Tear to the egress, which assigns a NULL label value.
非PHPの動作を要求する侵入LSRは、RRO属性サブオブジェクトのフラグフィールドの「非PHP動作フラグ」を調べ、「非PHP動作フラグ」を設定していない出口にパス裂け目を送る可能性があります。非PHP動作を要求する侵入LSRは、RROの出力LSRに対応するラベル値を調べ、ヌルラベル値を割り当てる出口にパス裂け目を送信する場合があります。
When signaling a P2MP LSP, a source node may wish to solicit an individual response to the "Non-PHP behavior flag" from the leaf nodes. Given the constraints on how the LSP Attributes may be carried in Path and Resv messages according to [RFC5420], in this situation, the source node MUST use a separate Path message for each leaf in networks where [RFC6510] is not supported. In networks with [RFC6510] deployed, either a single leaf per Path message or multiple leaves per Path message MAY be used by the source node.
P2MP LSPを信号する場合、ソースノードは、葉のノードからの「非PHP行動フラグ」に対する個々の応答を求めることをお勧めします。この状況では、[RFC5420]に従って、[RFC5420]に従って、[RFC5420]に従ってPATHおよびRESVメッセージにLSP属性をどのように伝達するかについての制約を考えると、[RFC6510]がサポートされていないネットワークの各リーフに個別のパスメッセージを使用する必要があります。[RFC6510]が展開されているネットワークでは、ソースノードでは、パスごとに単一の葉またはパスごとの複数の葉が使用される場合があります。
This document defines a single flag to indicate that the normal binding mechanism of an RSVP session is overridden. The actual out-of-band mappings are beyond the scope of this document. The flag is carried in the Attributes Flags TLV of the LSP Attributes object defined in [RFC5420] and is defined as follows:
このドキュメントでは、RSVPセッションの通常の結合メカニズムがオーバーライドされていることを示す単一のフラグを定義します。実際の帯域外マッピングは、このドキュメントの範囲を超えています。フラグは、[RFC5420]で定義されているLSP属性オブジェクトの属性フラグTLVに掲載され、次のように定義されています。
Bit Number 8: OOB mapping flag
ビット番号8：OOBマッピングフラグ
In order to indicate to the ingress LSR that the egress LSR recognizes the "OOB mapping flag", the following same bit is used in the Flags field of the Record Route object (RRO) Attributes subobject.
出力LSRが「OOBマッピングフラグ」を認識していることをIngress LSRに示すために、レコードルートオブジェクト（RRO）のフラグフィールドで同じビットがSubObjectの属性を属性にします。
An ingress LSR sets the "OOB mapping flag" to signal the egress LSR that the binding of RSVP-TE LSP to an application and a payload identifier is being signaled out-of-band. This flag MUST NOT be modified by any other LSRs in the network. LSRs other than the egress LSRs SHOULD ignore this flag.
Ingress LSRは、「OOBマッピングフラグ」を設定して、RSVP-TE LSPのアプリケーションへの結合とペイロード識別子が帯域外に合図されていることをEgress LSRに通知します。このフラグは、ネットワーク内の他のLSRによって変更されてはなりません。出力LSR以外のLSRは、このフラグを無視する必要があります。
When an egress LSR that supports the "OOB mapping flag" receives a Path message with that flag set, the egress LSR MUST set the "OOB mapping flag" in the Flags field of the RRO Attributes subobject. The rest of the RSVP signaling proceeds as normal. However, the LSR MUST have received the OOB mapping before accepting traffic on the LSP. This implies that the egress LSR MUST NOT set up forwarding state for the LSP before it receives the OOB mapping.
「OOBマッピングフラグ」をサポートする出力LSRがそのフラグセットでパスメッセージを受信する場合、出力LSRはRRO属性Subobjectのフラグフィールドに「OOBマッピングフラグ」を設定する必要があります。残りのRSVPシグナリングは通常どおりに進行します。ただし、LSRは、LSPのトラフィックを受け入れる前にOOBマッピングを受信している必要があります。これは、出力LSRがOOBマッピングを受信する前にLSPの転送状態を設定してはならないことを意味します。
Note that the payload information SHOULD be supplied by the OOB mapping. If the egress LSR receives the payload information from OOB mapping, then the LSR MUST ignore the L3PID (Layer 3 Protocol ID) in the Label Request Object [RFC3209].
ペイロード情報はOOBマッピングによって提供される必要があることに注意してください。出力LSRがOOBマッピングからペイロード情報を受信した場合、LSRはラベル要求オブジェクト[RFC3209]のL3PID（レイヤー3プロトコルID）を無視する必要があります。
If the egress LSR
出口lsrの場合
- supports the LSP Attributes object but does not recognize the Attributes Flags TLV; or
- LSP属性オブジェクトをサポートしますが、属性フラグTLVを認識しません。また
- supports the LSP Attributes object and recognizes the Attributes Flags TLV, but does not recognize the "OOB mapping flag";
- LSP属性オブジェクトをサポートし、属性フラグTLVを認識しますが、「OOBマッピングフラグ」を認識しません。
then it silently ignores the request according to the processing rules of [RFC5420].
次に、[RFC5420]の処理ルールに従って、黙ってリクエストを無視します。
An ingress LSR requesting OOB mapping SHOULD examine the "OOB mapping flag" in the Flags field of the RRO Attributes subobject and MAY send a Path Tear to the egress, which has not set the "OOB mapping flag".
OOBマッピングを要求するIngress LSRは、RRO属性サブオブジェクトのフラグフィールドにある「OOBマッピングフラグ」を調べ、「OOBマッピングフラグ」を設定していない出口にパス裂け目を送信する場合があります。
When signaling a P2MP LSP, a source node may wish to solicit an individual response to the "OOB mapping flag" from the leaf nodes. Given the constraints on how the LSP Attributes object may be carried in Path and Resv messages according to [RFC5420], in this situation, the source node MUST use a separate Path message for each leaf in networks where [RFC6510] is not supported. In networks with [RFC6510] deployed, either a single leaf per Path message or multiple leaves per Path message MAY be used by the source node.
P2MP LSPを信号する場合、ソースノードは、リーフノードからの「OOBマッピングフラグ」に対する個々の応答を求めることをお勧めします。この状況では、[RFC5420]に従って、[RFC5420]に従って、LSP属性オブジェクトをパスおよびRESVメッセージに携帯する方法に対する制約を考えると、ソースノードは[RFC6510]がサポートされていないネットワークの各リーフに個別のパスメッセージを使用する必要があります。[RFC6510]が展開されているネットワークでは、ソースノードでは、パスごとに単一の葉またはパスごとの複数の葉が使用される場合があります。
In deploying applications where the egress LSR receives the binding of the RSVP-TE LSP to an application and a payload identifier using an OOB mechanism, it is important to recognize that the OOB mapping is sent asynchronously with respect to the signaling of RSVP-TE LSP. The egress LSR only installs forwarding state for the LSP after it receives the OOB mapping. In deploying applications using an OOB mechanism, an ingress LSR may need to know when the egress is properly set up for forwarding (i.e., has received the OOB mapping). How the ingress LSR determines that the LSR is properly set up for forwarding at the egress LSR is beyond the scope of this document. Nonetheless, if the OOB mapping is not received by the egress LSR within a reasonable time, the procedure defined in Section 2.4 to tear down the LSP is followed.
出力LSRがRSVP-TE LSPのアプリケーションとペイロード識別子への結合をOOBメカニズムを使用して展開する際に、OOBマッピングがRSVP-TE LSPのシグナル伝達に関して非同期に送信されることを認識することが重要です。出力LSRは、OOBマッピングを受信した後、LSPの転送状態のみをインストールします。OOBメカニズムを使用してアプリケーションを展開する際に、侵入LSRは、出力が転送のために適切にセットアップされていることを知る必要がある場合があります（つまり、OOBマッピングを受信しました）。Ingress LSRがどのようにLSRが出口LSRで転送するために適切に設定されていると判断しているかは、このドキュメントの範囲を超えています。それにもかかわらず、OOBマッピングが妥当な時間内に出口LSRによって受信されない場合、LSPを取り壊すためにセクション2.4で定義された手順が続きます。
The "Non-PHP behavior flag" and "OOB mapping flag" can appear and be processed independently of each other. However, as mentioned earlier, in the context of the applications discussed in this document, OOB mapping requires non-PHP behavior. An ingress LSR requesting the OOB mapping MAY also set the "Non-PHP behavior flag" in the LSP Attributes object in the Path message.
「非PHP行動フラグ」と「OOBマッピングフラグ」が表示され、互いに独立して処理されます。ただし、前述のように、このドキュメントで説明したアプリケーションのコンテキストでは、OOBマッピングには非PHP動作が必要です。OOBマッピングを要求するIngress LSRは、パスメッセージのLSP属性オブジェクトに「非PHP動作フラグ」を設定することもできます。
RSVP-TE signaling completion and the OOB mapping information reception happen asynchronously at the egress. As mentioned in Section 2.2, egress waits for the OOB mapping before accepting traffic on the LSP. Nonetheless, MPLS Operations, Administration, and Maintenance (OAM) mechanisms, e.g., LSP ping and traceroute, as defined in [RFC4379] and [RFC6425], are expected to work independently of OOB mapping learning process.
RSVP-TEシグナリングの完了とOOBマッピング情報受信は、出口で非同期に発生します。セクション2.2で述べたように、出力はLSPのトラフィックを受け入れる前にOOBマッピングを待ちます。それにもかかわらず、[RFC4379]および[RFC6425]で定義されているように、MPLSの操作、管理、およびメンテナンス（OAM）メカニズム、例えばLSP PingおよびTracerouteは、OOBマッピング学習プロセスとは無関係に機能すると予想されます。
In order to avoid unnecessary use of the resources and possible black-holing of traffic, an egress LSR MAY send a Path Error message if the OOB mapping information is not received within a reasonable time. This Path Error message SHOULD include the error code/sub-code "Notify Error / no OOB mapping received" for all affected LSPs. If a notify request was included when the LSP was initially set up, a
リソースの不必要な使用とトラフィックのブラックホーリングの可能性を回避するために、OOBマッピング情報が妥当な時間内に受信されない場合、出力LSRはパスエラーメッセージを送信する場合があります。このパスエラーメッセージには、影響を受けるすべてのLSPに対してエラーコード /サブコード「通知エラー / no oobマッピングが受信されます」を含める必要があります。LSPが最初にセットアップされたときに通知要求が含まれている場合、
Notify message (as defined in [RFC3473]) MAY also be used for delivery of this information to the ingress LSR. An egress LSR MAY implement a cleanup timer for this purpose. The time-out value is a local decision at the egress, with a RECOMMENDED default value of 60 seconds.
通知メッセージ（[RFC3473]で定義されているように）は、この情報をイングレスLSRに配信するためにも使用できます。出力LSRは、この目的のためにクリーンアップタイマーを実装する場合があります。タイムアウト値は、出口でのローカル決定であり、推奨されるデフォルト値は60秒です。
The addition of non-PHP behavior adds a variety of attacks on the label assigned by the egress node. As change in the value of the egress label reported in the RRO can cause the LSP to be torn down, additional security considerations for protecting labels assigned by the egress node are required. Security mechanisms as identified in [RFC5920], [RFC2205], [RFC3209], [RFC3473], [RFC5420], and [RFC4875] can be used for this purpose. This document does not introduce any additional security issues above those identified in [RFC5920], [RFC2205], [RFC3209], [RFC3473], [RFC5420], and [RFC4875].
非PHPの動作を追加すると、出口ノードによって割り当てられたラベルにさまざまな攻撃が追加されます。RROで報告されている出力ラベルの値の変化により、LSPが取り壊される可能性があるため、出力ノードによって割り当てられたラベルを保護するための追加のセキュリティ上の考慮事項が必要です。[RFC5920]、[RFC2205]、[RFC3209]、[RFC3473]、[RFC5420]、および[RFC4875]で特定されたセキュリティメカニズムは、この目的に使用できます。この文書は、[RFC5920]、[RFC2205]、[RFC3209]、[RFC3473]、[RFC5420]、および[RFC4875]で特定されたものよりも追加のセキュリティ問題を導入しません。
The following changes to the Resource Reservation Protocol - Traffic Engineering (RSVP-TE) Parameters registry are required.
リソース予約プロトコルの以下の変更 - トラフィックエンジニアリング（RSVP -TE）パラメーターレジストリが必要です。
The following new flags are defined for the Attributes Flags TLV in the LSP Attributes object.
次の新しいフラグは、LSP属性オブジェクトの属性フラグTLVに対して定義されています。
o Non-PHP behavior flag:
o 非PHP行動フラグ：
This flag is used in the Attributes Flags TLV in a Path message. The flag has a corresponding new flag to be used in the RRO Attributes subobject. As per [RFC5420], the bit numbering in the Attribute Flags TLV and the RRO Attributes subobject is identical. That is, the same attribute is indicated by the same bit in both places. This flag is not allowed in the Attributes Flags TLV in a Resv message. Specifically, attributes of this flag are as follows:
このフラグは、パスメッセージの属性フラグTLVで使用されます。フラグには、RRO属性Subobjectで使用される対応する新しいフラグがあります。[RFC5420]によると、属性フラグTLVとRRO属性のビット番号は同一です。つまり、同じ属性が両方の場所で同じビットによって示されます。このフラグは、RESVメッセージの属性フラグTLVで許可されていません。具体的には、このフラグの属性は次のとおりです。
- Bit Number: 7
- ビット番号：7
- Attribute flag carried in Path message: Yes
- パスメッセージに掲載された属性フラグ：はい
- Attribute flag carried in Resv message: No
- resvメッセージに掲載された属性フラグ：いいえ
- Attribute flag carried in RRO message: Yes
- rroメッセージで掲載された属性フラグ：はい
o OOB mapping flag:
o OOBマッピングフラグ：
This flag is used in the Attributes Flags TLV in a Path message. The flag has a corresponding new flag to be used in the RRO Attributes subobject. As per [RFC5420], the bit numbering in the Attribute Flags TLV and the RRO Attributes subobject is identical. That is, the same attribute is indicated by the same bit in both places. This flag is not allowed in the Attributes Flags TLV in a Resv message. Specifically, attributes of this flag are as follows:
このフラグは、パスメッセージの属性フラグTLVで使用されます。フラグには、RRO属性Subobjectで使用される対応する新しいフラグがあります。[RFC5420]によると、属性フラグTLVとRRO属性のビット番号は同一です。つまり、同じ属性が両方の場所で同じビットによって示されます。このフラグは、RESVメッセージの属性フラグTLVで許可されていません。具体的には、このフラグの属性は次のとおりです。
- Bit Number: 8
- ビット番号：8
- Attribute flag carried in Path message: Yes
- パスメッセージに掲載された属性フラグ：はい
- Attribute flag carried in Resv message: No
- resvメッセージに掲載された属性フラグ：いいえ
- Attribute flag carried in RRO message: Yes
- rroメッセージで掲載された属性フラグ：はい
For Error Code = 25 "Notify Error" (see [RFC3209]), the following sub-code is defined.
エラーコード= 25「通知エラー」（[RFC3209]を参照）の場合、次のサブコードが定義されています。
Sub-code Value
-------- -----
No OOB mapping received 12
OOBマッピングは12を受け取りません
The authors would like to thank Yakov Rekhter for his suggestions on this document.
著者は、この文書に関する彼の提案についてYakov Rekhterに感謝したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205] Braden、R.、Ed。、Zhang、L.、Berson、S.、Herzog、S.、およびS. Jamin、「リソース予約プロトコル（RSVP） - バージョン1機能仕様」、RFC 2205、9月1997年。
[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.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、 "RSVP-TE：LSP TunnelsのRSVPへの拡張"、RFC 3209、12月2001年。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473] Berger、L.、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナリングリソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）拡張」、RFC 3473、2003年1月。
[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. Yasukawa, Ed., "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May 2007.
[RFC4875] Aggarwal、R.、ed。、ed。、Papadimitriou、D.、ed。、およびS. Yasukawa、ed。、「リソース予約プロトコルへの拡張 - ポイントツーマルチポイントTEラベルの交通工学（RSVP-TE）スイッチPaths（LSP） "、RFC 4875、2007年5月。
[RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A. Ayyangarps, "Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)", RFC 5420, February 2009.
[RFC5420] Farrel、A.、ed。、ed。、Papadimitriou、D.、Vasseur、Jp。、およびA. Ayyangarps、「リソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）を使用したMPLS LSP確立の属性のエンコード」、RFC 5420、2009年2月。
[RFC6510] Berger, L. and G. Swallow, "Resource Reservation Protocol (RSVP) Message Formats for Label Switched Path (LSP) Attributes Objects", RFC 6510, February 2012.
[RFC6510] Berger、L。およびG. Swallow、「リソース予約プロトコル（RSVP）Label Switched Path（LSP）属性オブジェクトのメッセージ形式」、RFC 6510、2012年2月。
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
[RFC4379] Kompella、K。およびG. Swallow、「Multi-Protocol Label Switched（MPLS）データプレーン障害の検出」、RFC 4379、2006年2月。
[RFC4761] Kompella, K., Ed., and Y. Rekhter, Ed., "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, January 2007.
[RFC4761] Kompella、K.、ed。、およびY. Rekhter、ed。、「自動配置とシグナル伝達のためにBGPを使用した仮想プライベートLANサービス（VPLS）」、RFC 4761、2007年1月。
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[RFC5920] Fang、L.、ed。、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、RFC 5920、2010年7月。
[RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, L., and L. Berger, "A Framework for MPLS in Transport Networks", RFC 5921, July 2010.
[RFC5921] Bocci、M.、ed。、Bryant、S.、ed。、Frost、D.、ed。、Levrau、L。、およびL. Berger、「輸送ネットワークのMPLSのフレームワーク」、RFC 5921、2010年7月。
[RFC6425] Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A., Yasukawa, S., and T. Nadeau, "Detecting Data-Plane Failures in Point-to-Multipoint MPLS - Extensions to LSP Ping", RFC 6425, November 2011.
[RFC6425] Saxena、S.、Ed。、Ed。、Swallow、G.、Ali、Z.、Farrel、A.、Yasukawa、S.、およびT. Nadeau、「ポイントツーマルチポイントMPLSのデータ面障害の検出 - LSP Pingへの拡張 "、RFC 6425、2011年11月。
[RFC6513] Rosen, E., Ed., and R. Aggarwal, Ed., "Multicast in MPLS/BGP IP VPNs", RFC 6513, February 2012.
[RFC6513] Rosen、E.、ed。、およびR. Aggarwal、ed。、「Mpls/BGP IP VPNSのマルチキャスト」、RFC 6513、2012年2月。
Authors' Addresses
著者のアドレス
Zafar Ali Cisco Systems, Inc. EMail: zali@cisco.com
Zafar Ali Cisco Systems、Inc。メール：zali@cisco.com
George Swallow Cisco Systems, Inc. EMail: swallow@cisco.com
George Swallow Cisco Systems、Inc。メール：swallow@cisco.com
Rahul Aggarwal Juniper Networks EMail: raggarwa_1@yahoo.com
Rahul Aggarwal Juniper Networks Email：raggarwa_1@yahoo.com