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
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）をスイッチング出力ラベルが必要な展開シナリオがあります。 -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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2012 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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 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.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版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.
リソース予約プロトコルとき - トラフィックエンジニアリング（RSVP-TE）はマルチキャストバーチャルプライベートネットワーク（MVPN）[RFC6513]と仮想プライベートLANサービス（VPLS）[RFC4761]、出口ラベルスイッチングルータ（LSR）などのアプリケーションに使用されるバインディングを受け取りますアプリケーションおよび「アウトオブバンド」（OOB）メカニズムを使用してペイロード識別子にRSVP-TEラベルスイッチパス（LSP）の（例えば、ボーダーゲートウェイプロトコル（BGP））。このようOOBマッピング情報が受信されるまでこのような場合には、出力LSRは正しい転送先を決定することはできません。さらに、バインディング情報を適用するために、出口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.
したがって、非最後から二番目のホップポッピング（非PHP）挙動は、OOBマッピングを適用する必要があります。非PHPの振る舞いが通知されたLSPのために非NULLのラベルを割り当てるために出口の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マルチキャストトラフィックの非PHPの動作は、トラフィックが受信されているP2MP TE LSPを識別するために、葉のLSRを可能にします。したがって、出口LSRは、トラフィックが予想P2MP LSP上で受信されたか否かを決定し、予想P2MP LSP上で受信されていないトラフィックを廃棄することができます。非PHPの動作は、コンテキストがMPLS LSPである場合、上流割り当てられたラベルのコンテキストを決定する必要があります。非PHPの動作はまた、MPLSトランスポートプロファイル（MPLS-TP）のLSP [RFC5921]のために必要とされてもよいです。
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.
非PHPの振る舞いの通信のために1つのフラグと1つのフラグは、（アプリケーションおよびペイロード識別子にLSPの結合することを示すために、このドキュメントは、LSPのTLVは[RFC5420]で定義されたオブジェクト属性の属性フラグに二つの新しいフラグを定義しますペイロードID）は、アウトオブバンドマッピングメカニズムを介して学習する必要があります。属性フラグTLVとレコードルートオブジェクト（RRO）のビットとの間に1対1の対応が存在するようにRROにサブオブジェクトも定義されている属性搬送されるフラグを、対応するサブオブジェクト属性。
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の動作を要求するために、この文書属性フラグに新しいフラグを定義するLSPのTLVは[RFC5420]で定義されたオブジェクトの属性：
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.
入口LSRは出口LSRsが通知されるLSPのために非NULLラベルを割り当てる必要がありますことを知らせるために「非PHPの動作フラグ」を設定します。このフラグは、ネットワーク内の他のの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.
Pathメッセージを受信した出力LSRがLSPは、オブジェクトと属性フラグTLV属性も「非PHPの動作フラグを」認識してサポートしている場合、それは非NULLローカルラベルを割り当てる必要があります。出力LSRはまた、RROのフラグ欄に「非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.
RROのフラグ欄に「非PHPの動作フラグを」調べる必要があり非PHPの動作を要求するイングレスLSRは、サブオブジェクトの属性と「非PHPの振る舞いフラグ」を設定していない出口へのパスの涙を送信することができます。非PHPの動作を要求する入口LSRはまた、RROに出口LSR（S）に対応するラベルの値を検査することができるし、NULLラベル値を割り当てる出口へのパス引裂を送信することができます。
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の動作フラグ」に対する個々の応答を要請することを望むかもしれません。 LSPは、[RFC5420]に従ってパスとのResvメッセージ中で実施することができる属性の方法の制約を考えると、このような状況で、ソース・ノードは、[RFC6510]がサポートされていないネットワーク内の各リーフのために別々のPathメッセージを使用しなければなりません。 [RFC6510]に展開とネットワークでは、PathメッセージまたはPathメッセージごとに複数のリーフ毎に単一の葉のいずれかがソースノードによって使用されてもよいです。
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セッションの正常な結合機構がオーバーライドされることを示すために単一のフラグを定義します。実際のアウトオブバンドのマッピングは、このドキュメントの範囲を超えています。フラグは、LSPのTLVは[RFC5420]で定義されたオブジェクトの属性と次のように定義された属性フラグで運ばれます。
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マッピングフラグを」認識する入口LSRに示すために、以下の同じビットは、レコードルートオブジェクトのFlagsフィールドで使用されている（RRO）がサブオブジェクト属性。
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.
入口LSRは、アプリケーションとペイロード識別子にRSVP-TE LSPの結合は、アウトオブバンドシグナリングされていることを出口LSRに知らせるために、「OOBマッピングフラグ」を設定します。このフラグは、ネットワーク内の他のの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は、そのフラグが設定されたPathメッセージを受信した場合、出力LSRは、サブオブジェクトの属性RROのFlagsフィールドで「OOBマッピングフラグ」を設定しなければなりません。通常通り進行するRSVPシグナリングの残りの部分。しかし、LSRは、LSP上のトラフィックを受け入れる前に、OOBマッピングを受けていなければなりません。これは、OOBマッピングを受ける前に、出力LSRが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".
イングレスLSR要求OOBマッピングは、サブオブジェクトの属性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マッピングフラグ」に対する個々の応答を要請することを望むかもしれません。 LSPは、[RFC5420]によれば、オブジェクトがパスとのResvメッセージ中で実施することができる属性の方法の制約を考えると、このような状況で、ソース・ノードは、[RFC6510]がサポートされていないネットワーク内の各リーフのための別個のPathメッセージを使用しなければなりません。 [RFC6510]に展開とネットワークでは、PathメッセージまたはPathメッセージごとに複数のリーフ毎に単一の葉のいずれかがソースノードによって使用されてもよいです。
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は、OOBメカニズムを使用してアプリケーションおよびペイロード識別子にRSVP-TE LSPの結合を受信するアプリケーションをデプロイするには、OOBマッピングがRSVP-TE LSPのシグナリングに対して非同期に送信されることを認識することが重要です。それはOOBマッピングを受信した後出口LSRは、LSPの状態を転送インストール。 OOBメカニズムを使用してアプリケーションをデプロイするには、入口LSRは、出力を適切に転送するために設定されている（即ち、OOBマッピングを受信した）場合に知っておく必要があるかもしれません。イングレス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マッピングを要求イングレスLSRはまた、LSPにおける「非PHPの振る舞いフラグが」Pathメッセージでオブジェクト属性を設定するかもしれません。
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マッピング情報の受信が出口で非同期的に起こります。 OOBマッピングのための出口待機LSPのトラフィックを受け入れる前に、2.2節で述べました。それにもかかわらず、MPLS運用、管理、および保守[RFC4379]で定義されるように（OAM）メカニズム、例えば、LSPピングおよびトレースルート、および[RFC6425]は、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は、「エラー通知/なし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の振る舞いの追加は、出口ノードによって割り当てられたラベル上のさまざまな攻撃が追加されます。解体されるようにLSPを引き起こす可能性がありますRROで報告された出力ラベルの値の変化として、出口ノードによって割り当てられたラベルを保護するための追加のセキュリティの考慮が必要とされています。 [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:
このフラグは、PathメッセージにTLV属性フラグに使用されています。フラグは、RROサブオブジェクト属性で使用することに対応する新たなフラグを有しています。 [RFC5420]に従って、属性フラグTLVの番号ビットとRROは、サブオブジェクトが同一である属性。これは、同じ属性は、両方の場所で同じビットによって示されています。このフラグは、Resvメッセージ内の属性フラグTLVでは許可されていません。次のように具体的には、このフラグの属性は次のとおりです。
- Bit Number: 7
- ビット数：7
- Attribute flag carried in Path message: Yes
- Pathメッセージで運ばれた属性フラグ：はい
- 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:
このフラグは、PathメッセージにTLV属性フラグに使用されています。フラグは、RROサブオブジェクト属性で使用することに対応する新たなフラグを有しています。 [RFC5420]に従って、属性フラグTLVの番号ビットとRROは、サブオブジェクトが同一である属性。これは、同じ属性は、両方の場所で同じビットによって示されています。このフラグは、Resvメッセージ内の属性フラグTLVでは許可されていません。次のように具体的には、このフラグの属性は次のとおりです。
- Bit Number: 8
- ビット数：8
- Attribute flag carried in Path message: Yes
- Pathメッセージで運ばれた属性フラグ：はい
- 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.
（[RFC3209]を参照）「エラーを通知する」エラーコード= 25は、次のサブコードが定義されています。
Sub-code Value
-------- -----
No OOB mapping received 12
いいえOOBマッピングは12を受けていません
The authors would like to thank Yakov Rekhter for his suggestions on this document.
作者はこのドキュメントの彼の提案のためのヤコフ・レックターに感謝したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]ブレーデン、R.、エド、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（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.、バーガー、L.、ガン、D.、李、T.、スリニヴァサン、V.、およびG.ツバメ、 "RSVP-TE：LSPトンネルのための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]バーガー、L.、エド。、 "一般化されたマルチプロトコルラベルスイッチング（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]アガルワルは、R.、エド、Papadimitriou、D.、エド、およびS.安川、エド、「リソース予約プロトコルへの拡張 - 。。。は、ポイント・ツー・マルチポイントTEラベルのためのトラフィックエンジニアリング（RSVP-TE）は、スイッチパス（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]ファレル、A.編、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]バーガー、L.とG.ツバメは、RFC 6510、2012年2月 "ラベルスイッチパス（LSP）のためのリソース予約プロトコル（RSVP）メッセージ形式は、オブジェクトの属性"。
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
[RFC4379] Kompella、K.とG.ツバメ、2006年2月、RFC 4379 "を検出マルチプロトコルラベルは（MPLS）データプレーン障害をスイッチ"。
[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.、エド。、およびY. Rekhter、エド。、 "仮想プライベートLANサービス（VPLS）自動検出およびシグナリングのためにBGPを使用する"、RFC 4761、2007年1月。
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[RFC5920]牙、L.、エド。、 "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]ボッチ、M.編、ブライアント、S.、エド。、霜、D.、編、Levrau、L.、およびL.バーガー、 "トランスポートネットワークにおける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.、エド、ツバメ、G.、アリ、Z.、ファレル、A.、安川、S.、およびT.ナドー、ポイントツーマルチポイント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]ローゼン、E.、エド。、およびR.アガルワル、エド。、 "マルチキャストMPLS / BGP VPNのIPで"、RFC 6513、2012年2月。
Authors' Addresses
著者のアドレス
Zafar Ali Cisco Systems, Inc. EMail: zali@cisco.com
Zafarアリシスコシステムズ、株式会社Eメール：zali@cisco.com
George Swallow Cisco Systems, Inc. EMail: swallow@cisco.com
ジョージツバメシスコシステムズ、株式会社Eメール：swallow@cisco.com
Rahul Aggarwal Juniper Networks EMail: raggarwa_1@yahoo.com
ラウール・アガーウォールジュニパーネットワークスのEメール：raggarwa_1@yahoo.com