[要約] RFC 7571は、GMPLS RSVP-TE拡張機能であるLock InstructとLoopbackに関するものであり、制御面でのループバックテストとリンクのロック制御をサポートすることを目的としています。
Internet Engineering Task Force (IETF) J. Dong
Request for Comments: 7571 M. Chen
Category: Standards Track Huawei Technologies
ISSN: 2070-1721 Z. Li
China Mobile
D. Ceccarelli
Ericsson
July 2015
GMPLS RSVP-TE Extensions for Lock Instruct and Loopback
ロック命令およびループバック用のGMPLS RSVP-TE拡張
Abstract
概要
This document specifies extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) to support Lock Instruct (LI) and Loopback (LB) mechanisms for Label Switched Paths (LSPs). These mechanisms are applicable to technologies that use Generalized MPLS (GMPLS) for the control plane.
このドキュメントでは、リソース予約プロトコル-トラフィックエンジニアリング（RSVP-TE）の拡張機能について説明し、ラベルスイッチドパス（LSP）のロック命令（LI）およびループバック（LB）メカニズムをサポートします。これらのメカニズムは、コントロールプレーンにGeneralized MPLS（GMPLS）を使用するテクノロジーに適用できます。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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/rfc7571.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7571で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 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 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文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Flag Definitions for LI and LB . . . . . . . . . . . . . . . 3
2.1. Lock Instruct Indication . . . . . . . . . . . . . . . . 3
2.2. Extensions for Loopback . . . . . . . . . . . . . . . . . 3
3. Operational Procedures . . . . . . . . . . . . . . . . . . . 3
3.1. Lock Instruct . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Loopback . . . . . . . . . . . . . . . . . . . . . . . . 4
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
4.1. Attribute Flags . . . . . . . . . . . . . . . . . . . . . 6
4.2. RSVP Error Value Sub-Codes . . . . . . . . . . . . . . . 6
4.3. Allocation Rule for ERO Subobjects . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Normative References . . . . . . . . . . . . . . . . . . 7
6.2. Informative References . . . . . . . . . . . . . . . . . 8
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
The requirements for Lock Instruct (LI) and Loopback (LB) in the Multiprotocol Label Switching Transport Profile (MPLS-TP) are specified in [RFC5860], and the framework of LI and LB is specified in [RFC6371]. A Label Switched Path (LSP) that is locked, using LI, is prevented from carrying user data traffic. The LB function can only be applied to an LSP that has been previously locked.
マルチプロトコルラベルスイッチングトランスポートプロファイル（MPLS-TP）のロックインストラクション（LI）およびループバック（LB）の要件は[RFC5860]で指定され、LIおよびLBのフレームワークは[RFC6371]で指定されます。 LIを使用してロックされているラベルスイッチドパス（LSP）は、ユーザーデータトラフィックを伝送できません。 LB機能は、以前にロックされたLSPにのみ適用できます。
In general, the LI and LB are useful Operations, Administration, and Maintenance (OAM) functions for technologies that use Generalized MPLS (GMPLS) for the control plane, e.g., time-division multiplexing, wavelength-division multiplexing, and packet switching. It is natural to use and extend the GMPLS control-plane protocol to provide a unified approach for LI and LB provisioning in all these technologies.
一般に、LIとLBは、時分割多重化、波長分割多重化、パケットスイッチングなど、コントロールプレーンに汎用MPLS（GMPLS）を使用するテクノロジーの運用、管理、保守（OAM）機能に役立ちます。 GMPLSコントロールプレーンプロトコルを使用および拡張して、これらすべてのテクノロジーでLIおよびLBプロビジョニングの統合アプローチを提供することは自然なことです。
[RFC7487] specifies the RSVP-TE extensions for the configuration of proactive MPLS-TP OAM functions, such as Continuity Check (CC), Connectivity Verification (CV), Delay Measurement (DM), and Loss Measurement (LM). The provisioning of on-demand OAM functions such as LI and LB are not covered in that document.
[RFC7487]は、Continuity Check（CC）、Connectivity Verification（CV）、Delay Measurement（DM）、およびLoss Measurement（LM）などの予防的MPLS-TP OAM機能の構成のためのRSVP-TE拡張を指定します。このドキュメントでは、LIやLBなどのオンデマンドOAM機能のプロビジョニングについては説明していません。
This document specifies extensions to Resource Reservation Protocol-Traffic Engineering (RSVP-TE) to support lock instruct and loopback mechanisms for LSPs. The mechanisms are applicable to technologies that use GMPLS for the control plane. For a network supporting MPLS-TP, the mechanisms defined in this document are complementary to [RFC6435].
このドキュメントでは、LSPのロック指示およびループバックメカニズムをサポートするために、リソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）への拡張を指定します。このメカニズムは、コントロールプレーンにGMPLSを使用するテクノロジーに適用できます。 MPLS-TPをサポートするネットワークの場合、このドキュメントで定義されているメカニズムは、[RFC6435]を補完するものです。
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]で説明されているように解釈されます。
In order to indicate the lock/unlock status of the LSP, the A (Administratively down) bit in the Administrative Status (ADMIN_STATUS) Object [RFC3471] [RFC3473] is used.
LSPのロック/ロック解除ステータスを示すために、管理ステータス（ADMIN_STATUS）オブジェクト[RFC3471] [RFC3473]のA（管理上ダウン）ビットが使用されます。
In order to indicate the loopback mode of LSP, a new bit flag is defined in the Attribute Flags TLV [RFC5420].
LSPのループバックモードを示すために、新しいビットフラグが属性フラグTLV [RFC5420]で定義されています。
Loopback flag:
ループバックフラグ：
This flag indicates a particular node on the LSP is required to enter loopback mode. This can also be used for specifying the loopback state of the node.
このフラグは、LSP上の特定のノードがループバックモードに入る必要があることを示します。これは、ノードのループバック状態を指定するためにも使用できます。
- Bit number: 13
- ビット数：13
- Attribute flag carried in Path message: Yes
- パスメッセージに含まれる属性フラグ：はい
- Attribute flag carried in Resv message: No
- Resvメッセージに含まれる属性フラグ：いいえ
- Attribute flag carried in the Record Route Object (RRO) Attributes subobject: Yes
- レコードルートオブジェクト（RRO）属性サブオブジェクトに含まれる属性フラグ：はい
When an ingress node intends to put an LSP into lock mode, it MUST send a Path message with the Administratively down (A) bit used as specified above and the Reflect (R) bit in the ADMIN_STATUS Object set.
入力ノードがLSPをロックモードにするつもりの場合、上記のように使用された管理上ダウン（A）ビットとADMIN_STATUSオブジェクトセットのリフレクト（R）ビットを含むパスメッセージを送信する必要があります。
On receipt of this Path message, the egress node SHOULD try to take the LSP out of service. If the egress node locks the LSP successfully, it MUST send a Resv message with the A bit in the ADMIN_STATUS Object set. Otherwise, it MUST send a PathErr message with the Error Code "OAM Problem" [RFC7260] and the new Error Value "Lock Failure", and the following Resv messages MUST be sent with the A bit cleared.
このPathメッセージを受信すると、出力ノードはLSPをサービス停止にする必要があります（SHOULD）。出口ノードがLSPを正常にロックした場合、ADMIN_STATUSオブジェクトセットのAビットを含むResvメッセージを送信する必要があります。それ以外の場合は、エラーコード「OAM Problem」[RFC7260]と新しいエラー値「Lock Failure」を含むPathErrメッセージを送信する必要があり、次のResvメッセージはAビットをクリアして送信する必要があります。
When an LSP is put in lock mode, the subsequent Path and Resv messages MUST keep the A bit in the ADMIN_STATUS Object set.
LSPがロックモードになると、後続のPathおよびResvメッセージは、ADMIN_STATUSオブジェクトセットのAビットを維持する必要があります。
When the ingress node intends to take the LSP out of the lock mode, it MUST send a Path message with the A bit in the ADMIN_STATUS Object cleared.
入力ノードがLSPをロックモードから外すつもりの場合、ADMIN_STATUSオブジェクトのAビットがクリアされたパスメッセージを送信する必要があります。
On receipt of this Path message, the egress node SHOULD try to bring the LSP back to service. If the egress node unlocks the LSP successfully, it MUST send a Resv message with the A bit in the ADMIN_STATUS Object cleared. Otherwise, it MUST send a PathErr message with the Error Code "OAM Problem" [RFC7260] and the new Error Value "Unlock Failure", and the following Resv messages MUST be sent with the A bit set.
このPathメッセージを受信すると、出力ノードはLSPをサービスに戻そうとする必要があります（SHOULD）。出力ノードがLSPのロックを正常に解除した場合、ADMIN_STATUSオブジェクトのAビットがクリアされたResvメッセージを送信する必要があります。それ以外の場合は、エラーコード「OAM Problem」[RFC7260]と新しいエラー値「Unlock Failure」を含むPathErrメッセージを送信する必要があり、次のResvメッセージはAビットを設定して送信する必要があります。
When an LSP is taken out of lock mode, the subsequent Path and Resv messages MUST keep the A bit in the ADMIN_STATUS Object cleared.
LSPのロックモードが解除された場合、後続のPathおよびResvメッセージは、ADMIN_STATUSオブジェクトのAビットをクリアしたままにする必要があります。
The loopback request can be sent either to the egress node or to a particular intermediate node. The mechanism defined in [RFC7570] is used for addressing the loopback request to a particular node on the LSP. The ingress node MUST ensure that the LSP is in lock mode before it requests setting a particular node on the LSP into loopback mode.
ループバック要求は、出口ノードまたは特定の中間ノードに送信できます。 [RFC7570]で定義されているメカニズムは、LSP上の特定のノードへのループバック要求のアドレス指定に使用されます。入力ノードは、LSP上の特定のノードをループバックモードに設定することを要求する前に、LSPがロックモードであることを確認する必要があります。
When an ingress node intends to put a particular node on the LSP into loopback mode, it MUST send a Path message with the Loopback Attribute Flag defined above in the Attribute Flags TLV set. The mechanism defined in [RFC7570] is used to address the loopback request to the particular node. The ingress node MUST ensure that the entity at which loopback is intended to occur is explicitly identified by the immediately preceding subobject of the Explicit Route Object (ERO) Hop Attributes subobject. The Administratively down (A) bit in the ADMIN_STATUS Object MUST be kept set to indicate that the LSP is still in lock mode.
入力ノードがLSP上の特定のノードをループバックモードにする場合、属性フラグTLVセットで上記で定義されたループバック属性フラグを含むパスメッセージを送信する必要があります。 [RFC7570]で定義されたメカニズムは、特定のノードへのループバック要求に対処するために使用されます。入力ノードは、ループバックが発生する予定のエンティティが、明示的ルートオブジェクト（ERO）ホップ属性サブオブジェクトの直前のサブオブジェクトによって明示的に識別されることを保証する必要があります。 LSPがまだロックモードであることを示すために、ADMIN_STATUSオブジェクトのAdministratively Down（A）ビットを設定したままにしておく必要があります。
On receipt of this Path message, the target node of the loopback request MUST check if the LSP is in lock mode by verifying that the Administratively down (A) bit is set in the ADMIN_STATUS Object. If the bit is not set, the loopback request MUST be ignored. If the bit is set, the node MUST check that the desired loopback entity is explicitly identified by the ERO subobject prior to the ERO Hop Attributes subobject. Currently, the type value MUST be verified to be less than 32 (i.e., able to identify a specific entity where a loopback can occur; see Section 4.3), and for type values 1 (IPv4 prefix) and 2 (IPv6 prefix), the prefix length MUST be 32 and 128, respectively. If the desired loopback entity is not explicitly identified, the request MUST be ignored and a "Bad EXPLICIT_ROUTE object" error SHOULD be generated. Otherwise, the node SHOULD try to put the LSP into loopback mode. The loopback SHOULD be enabled on the entity identified by the ERO subobject immediately prior to the ERO Hop Attributes subobject. If the immediately preceding subobject is a label subobject [RFC3473], the loopback SHOULD be enabled for the direction indicated by the U bit of the label subobject.
このPathメッセージを受信すると、ループバック要求のターゲットノードは、管理上ダウン（A）ビットがADMIN_STATUSオブジェクトに設定されていることを確認して、LSPがロックモードにあるかどうかを確認する必要があります。ビットが設定されていない場合は、ループバック要求を無視する必要があります。ビットが設定されている場合、ノードは目的のループバックエンティティがEROホップ属性サブオブジェクトの前にEROサブオブジェクトによって明示的に識別されていることを確認する必要があります。現在、タイプ値は32未満であることを確認する必要があります（つまり、ループバックが発生する可能性のある特定のエンティティを識別できます。セクション4.3を参照）。タイプ値1（IPv4プレフィックス）および2（IPv6プレフィックス）については、プレフィックス長は、それぞれ32と128でなければなりません。目的のループバックエンティティが明示的に識別されていない場合は、要求を無視する必要があり、「Bad EXPLICIT_ROUTEオブジェクト」エラーを生成する必要があります（SHOULD）。それ以外の場合、ノードはLSPをループバックモードにしようとする必要があります（SHOULD）。ループバックは、EROホップ属性サブオブジェクトの直前のEROサブオブジェクトによって識別されるエンティティで有効にする必要があります（SHOULD）。直前のサブオブジェクトがラベルサブオブジェクト[RFC3473]である場合、ラベルサブオブジェクトのUビットで示される方向でループバックを有効にする必要があります（SHOULD）。
If the node puts the LSP into loopback mode successfully, it MUST set the Loopback Attribute Flag if it adds, per [RFC7570], an RRO Hop Attributes subobject to the RRO of a Path or Resv message. The Administratively down (A) bit in the ADMIN_STATUS Object MUST be kept set in the message. If the node cannot put the LSP into loopback mode, it MUST send a PathErr message with the Error Code "OAM Problem" [RFC7260] and the new Error Value "Loopback Failure".
ノードがLSPをループバックモードにすることに成功した場合、[RFC7570]に従って、パスまたはResvメッセージのRROにRROホップ属性サブオブジェクトを追加する場合、ループバック属性フラグを設定する必要があります。 ADMIN_STATUSオブジェクトの管理上のダウン（A）ビットは、メッセージに設定されたままにしておく必要があります。ノードがLSPをループバックモードにできない場合は、PathErrメッセージをエラーコード「OAM Problem」[RFC7260]と新しいエラー値「Loopback Failure」とともに送信する必要があります。
When the ingress node intends to take the particular node out of loopback mode, it MUST send a Path message with the Loopback Attribute Flag in the Attribute Flags TLV cleared. The mechanism defined in [RFC7570] is used to indicate that the particular node SHOULD exit loopback mode for this LSP. The Administratively down (A) bit in the ADMIN_STATUS Object MUST be kept set to indicate the LSP is still in lock mode.
入力ノードが特定のノードをループバックモードから抜け出そうとする場合、属性フラグTLVのループバック属性フラグをクリアしたパスメッセージを送信する必要があります。 [RFC7570]で定義されたメカニズムは、特定のノードがこのLSPのループバックモードを終了する必要があることを示すために使用されます。 LSPがまだロックモードであることを示すために、ADMIN_STATUSオブジェクトのAdministratively Down（A）ビットを設定したままにしておく必要があります。
On receipt of this Path message, the target node SHOULD try to take the LSP out of loopback mode. If the node takes the LSP out of loopback mode successfully, it MUST clear the Loopback Attribute Flag in the RRO Hop Attributes subobject and push this subobject onto the RRO object in the corresponding Path or Resv message. The Administratively down (A) bit in the ADMIN_STATUS Object MUST be kept set in the message. Otherwise, the node MUST send a PathErr message with the Error Code "OAM Problem" [RFC7260] and the new Error Value "Exit Loopback Failure".
このPathメッセージを受信すると、ターゲットノードはLSPをループバックモードから抜け出そうとするべきです（SHOULD）。ノードがLSPをループバックモードから正常に解除した場合、RROホップ属性サブオブジェクトのループバック属性フラグをクリアし、このサブオブジェクトを対応するパスまたはResvメッセージのRROオブジェクトにプッシュする必要があります。 ADMIN_STATUSオブジェクトの管理上のダウン（A）ビットは、メッセージに設定されたままにしておく必要があります。それ以外の場合、ノードはPathErrメッセージを送信して、エラーコード「OAM Problem」[RFC7260]と新しいエラー値「Exit Loopback Failure」を送信する必要があります。
After the loopback mode is cleared successfully, the ingress node MAY remove the Lock Instruct using the mechanism defined in Section 3.1. The ingress node MUST NOT request to exit lock mode if the LSP is still in loopback mode. The egress node MUST ignore such a request when the LSP is still in loopback mode.
ループバックモードが正常にクリアされた後、入力ノードは、セクション3.1で定義されたメカニズムを使用してロック指示を削除する場合があります。 LSPがまだループバックモードの場合、入力ノードはロックモードの終了を要求してはなりません（MUST NOT）。 LSPがまだループバックモードの場合、出力ノードはそのような要求を無視する必要があります。
IANA has assigned new values defined in this document and summarized in this section.
IANAは、このドキュメントで定義され、このセクションで要約されている新しい値を割り当てました。
IANA maintains a registry called "Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Parameters" with a sub-registry called "Attribute Flags".
IANAは、「リソース予約プロトコル-トラフィックエンジニアリング（RSVP-TE）パラメータ」と呼ばれるレジストリを、「属性フラグ」と呼ばれるサブレジストリで管理しています。
IANA has assigned a new bit flag as follows:
IANAは、次のように新しいビットフラグを割り当てました。
Bit | | Attribute | Attribute | | |
No. | Name | Flags Path | Flags Resv | RRO | ERO | Reference
-----+-----------+------------+------------+-----+-----+-------------
13 | Loopback | Yes | No | Yes | Yes |this document
IANA maintains a registry called "Resource Reservation Protocol (RSVP) Parameters" with a sub-registry called "Error Codes and Globally-Defined Error Value Sub-Codes".
IANAは、「リソース予約プロトコル（RSVP）パラメータ」と呼ばれるレジストリを、「エラーコードとグローバルに定義されたエラー値のサブコード」と呼ばれるサブレジストリで管理しています。
IANA has assigned four new Error Value sub-codes for the "OAM Problem" Error Code:
IANAは、「OAM問題」エラーコードに4つの新しいエラー値サブコードを割り当てました。
Value | Description | Reference
-----------+-----------------------------+--------------
26 | Lock Failure | this document
27 | Unlock Failure | this document
28 | Loopback Failure | this document
29 | Exit Loopback Failure | this document
IANA maintains a registry called "Resource Reservation Protocol (RSVP) Parameters" with a sub-registry called "Class Names, Class Numbers, and Class Types".
IANAは、「リソース予約プロトコル（RSVP）パラメータ」と呼ばれるレジストリを、「クラス名、クラス番号、およびクラスタイプ」と呼ばれるサブレジストリで管理しています。
For Explicit Route Object, the allocation rule for subobject types in the range 5-31 (0x05 - 0x1F) has been updated as:
明示的なルートオブジェクトの場合、5-31（0x05-0x1F）の範囲のサブオブジェクトタイプの割り当てルールが次のように更新されました。
5-31 Unassigned (For explicit resource identification)
5-31未割り当て（明示的なリソース識別用）
This document does not introduce any new security issues beyond those identified in [RFC3209], [RFC3473], and [RFC7570]. For a more comprehensive discussion of GMPLS security and attack mitigation techniques, please see "Security Framework for MPLS and GMPLS Networks" [RFC5920].
このドキュメントでは、[RFC3209]、[RFC3473]、および[RFC7570]で特定された問題以外の新しいセキュリティ問題は紹介していません。 GMPLSのセキュリティおよび攻撃軽減技術のより包括的な説明については、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」[RFC5920]を参照してください。
In addition, the reporting of the loopback status using the RRO may reveal details about the node that the operator wishes to remain confidential. The privacy considerations as described in paragraph 3 of Section 5 of [RFC7570] also apply to this document.
さらに、RROを使用したループバックステータスの報告により、オペレーターが機密を保持したいノードに関する詳細が明らかになる場合があります。 [RFC7570]のセクション5のパラグラフ3で説明されているプライバシーに関する考慮事項は、このドキュメントにも適用されます。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, <http://www.rfc-editor.org/info/rfc3209>.
[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE：Extensions for RSVP for LSP Tunnels」、RFC 3209、DOI 10.17487 / RFC3209、2001年12月、<http://www.rfc-editor.org/info/rfc3209>。
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, DOI 10.17487/RFC3471, January 2003, <http://www.rfc-editor.org/info/rfc3471>.
[RFC3471] Berger、L.、Ed。、「Generalized Multi-Protocol Label Switching（GMPLS）Signaling Functional Description」、RFC 3471、DOI 10.17487 / RFC3471、2003年1月、<http://www.rfc-editor.org/ info / rfc3471>。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, DOI 10.17487/RFC3473, January 2003, <http://www.rfc-editor.org/info/rfc3473>.
[RFC3473] Berger、L.、Ed。、「Generalized Multi-Protocol Label Switching（GMPLS）Signaling Resource ReserVation Protocol-Traffic Engineering（RSVP-TE）Extensions」、RFC 3473、DOI 10.17487 / RFC3473、2003年1月、<http： //www.rfc-editor.org/info/rfc3473>。
[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, DOI 10.17487/RFC5420, February 2009, <http://www.rfc-editor.org/info/rfc5420>.
[RFC5420] Farrel、A.、Ed。、Papadimitriou、D.、Vasseur、JP。、およびA. Ayyangarps、「Resource Reservation Protocol Traffic Engineering（RSVP-TE）を使用したMPLS LSP確立のための属性のエンコーディング」、RFC 5420、 DOI 10.17487 / RFC5420、2009年2月、<http://www.rfc-editor.org/info/rfc5420>。
[RFC5860] Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed., "Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks", RFC 5860, DOI 10.17487/RFC5860, May 2010, <http://www.rfc-editor.org/info/rfc5860>.
[RFC5860] Vigoureux、M.、Ed。、Ward、D.、Ed。、and M. Betts、Ed。、 "Requirements for Operations、Administration、and Maintenance（OAM）in MPLS Transport Networks"、RFC 5860、DOI 10.17487 / RFC5860、2010年5月、<http://www.rfc-editor.org/info/rfc5860>。
[RFC7260] Takacs, A., Fedyk, D., and J. He, "GMPLS RSVP-TE Extensions for Operations, Administration, and Maintenance (OAM) Configuration", RFC 7260, DOI 10.17487/RFC7260, June 2014, <http://www.rfc-editor.org/info/rfc7260>.
[RFC7260] Takacs、A.、Fedyk、D。、およびJ. He、「運用、管理、および保守（OAM）構成用のGMPLS RSVP-TE拡張機能」、RFC 7260、DOI 10.17487 / RFC7260、2014年6月、<http ：//www.rfc-editor.org/info/rfc7260>。
[RFC7570] Margaria, C., Ed., Martinelli, G., Balls, S., and B. Wright, "Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO)", RFC 7570, DOI 10.17487/RFC7570, July 2015, <http://www.rfc-editor.org/info/rfc7570>.
[RFC7570]マーガリア、C。、編、マルティネリ、G。、ボール、S。、およびB.ライト、「明示的ルートオブジェクト（ERO）のラベルスイッチドパス（LSP）属性」、RFC 7570、DOI 10.17487 / RFC7570、2015年7月、<http://www.rfc-editor.org/info/rfc7570>。
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, <http://www.rfc-editor.org/info/rfc5920>.
[RFC5920] Fang、L。、編、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、RFC 5920、DOI 10.17487 / RFC5920、2010年7月、<http://www.rfc-editor.org/info/rfc5920>。
[RFC6371] Busi, I., Ed. and D. Allan, Ed., "Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks", RFC 6371, DOI 10.17487/RFC6371, September 2011, <http://www.rfc-editor.org/info/rfc6371>.
[RFC6371] Busi、I.、Ed。およびD. Allan編、「MPLSベースのトランスポートネットワークの運用、管理、およびメンテナンスフレームワーク」、RFC 6371、DOI 10.17487 / RFC6371、2011年9月、<http://www.rfc-editor.org/info/ rfc6371>。
[RFC6435] Boutros, S., Ed., Sivabalan, S., Ed., Aggarwal, R., Ed., Vigoureux, M., Ed., and X. Dai, Ed., "MPLS Transport Profile Lock Instruct and Loopback Functions", RFC 6435, DOI 10.17487/RFC6435, November 2011, <http://www.rfc-editor.org/info/rfc6435>.
[RFC6435] Boutros、S.、Ed。、Sivabalan、S.、Ed。、Aggarwal、R.、Ed。、Vigoureux、M.、Ed。、and X. Dai、Ed。、 "MPLS Transport Profile Lock Instruct andループバック機能」、RFC 6435、DOI 10.17487 / RFC6435、2011年11月、<http://www.rfc-editor.org/info/rfc6435>。
[RFC7487] Bellagamba, E., Takacs, A., Mirsky, G., Andersson, L., Skoldstrom, P., and D. Ward, "Configuration of Proactive Operations, Administration, and Maintenance (OAM) Functions for MPLS-Based Transport Networks Using RSVP-TE", RFC 7487, DOI 10.17487/RFC7487, March 2015, <http://www.rfc-editor.org/info/rfc7487>.
[RFC7487] Bellagamba、E.、Takacs、A.、Mirsky、G.、Andersson、L.、Skoldstrom、P。、およびD. Ward、「MPLSの予防的運用、管理、および保守（OAM）機能の構成- RSVP-TEを使用したベースのトランスポートネットワーク」、RFC 7487、DOI 10.17487 / RFC7487、2015年3月、<http://www.rfc-editor.org/info/rfc7487>。
Acknowledgments
謝辞
The authors would like to thank Greg Mirsky, Lou Berger, and Francesco Fondelli for their comments and suggestions.
著者は、コメントと提案をしてくれたGreg Mirsky、Lou Berger、Francesco Fondelliに感謝します。
Authors' Addresses
著者のアドレス
Jie Dong Huawei Technologies Huawei Campus, No.156 Beiqing Rd. Beijing 100095 China
J IE dong hu Aはテクノロジーhu Aはキャンパス、no.156 be i青RD北京100095中国
Email: jie.dong@huawei.com
Mach(Guoyi) Chen Huawei Technologies Huawei Campus, No.156 Beiqing Rd. Beijing 100095 China
Mach（GU O一）Chen hu Aはテクノロジーhu Aはキャンパス、no.156 be i青RD北京100095中国
Email: mach.chen@huawei.com
Zhenqiang Li China Mobile Unit2, Dacheng Plaza, No. 28 Xuanwumenxi Ave. Beijing 100053 China
Zは非常に強いl iチャイナモバイルユニット2、DAはプラザ、No。28 X uは5つのドアを押す北京100053中国
Email: lizhenqiang@chinamobile.com
Daniele Ceccarelli Ericsson Via A. Negrone 1/A Genova - Sestri Ponente Italy
Daniele Ceccarelli Ericsson Via A. Negrone 1 / A Genoa-セストリポネンテイタリア
Email: daniele.ceccarelli@ericsson.com