[要約] RFC 5146は、MPLS-TEをGMPLSネットワーク上で運用するための相互運用要件を定義しています。このRFCの目的は、MPLS-TEとGMPLSの統合に関するガイドラインを提供し、効率的なネットワーク運用を実現することです。
Network Working Group K. Kumaki, Ed.
Request for Comments: 5146 KDDI Corporation
Category: Informational March 2008
Interworking Requirements to Support Operation of MPLS-TE over GMPLS Networks
GMPLSネットワークを介したMPLS-TEの動作をサポートするためのインターワーキング要件
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Abstract
概要
Operation of a Multiprotocol Label Switching (MPLS) traffic engineering (TE) network as a client network to a Generalized MPLS (GMPLS) network has enhanced operational capabilities compared to those provided by a coexistent protocol model (i.e., operation of MPLS-TE over an independently managed transport layer).
マルチプロトコルラベルスイッチング（MPLS）トラフィックエンジニアリング（TE）ネットワークの一般化MPLS（GMPLS）ネットワークへのクライアントネットワークとしての動作により、共存するプロトコルモデル（すなわち、MPLS-TEの動作が提供されているものと比較して、運用機能が強化されています。独立して管理された輸送層）。
The GMPLS network may be a packet or a non-packet network, and may itself be a multi-layer network supporting both packet and non-packet technologies. An MPLS-TE Label Switched Path (LSP) originates and terminates on an MPLS Label Switching Router (LSR). The GMPLS network provides transparent transport for the end-to-end MPLS-TE LSP.
GMPLSネットワークは、パケットまたは非パケットネットワークである可能性があり、それ自体がパケットテクノロジーと非パケットテクノロジーの両方をサポートする多層ネットワークである可能性があります。MPLS-TEラベルスイッチ付きパス（LSP）は、MPLSラベルスイッチングルーター（LSR）で発生および終了します。GMPLSネットワークは、エンドツーエンドMPLS-TE LSPに透明な輸送を提供します。
This document describes a framework and Service Provider requirements for operating MPLS-TE networks over GMPLS networks.
このドキュメントでは、GMPLSネットワークを介してMPLS-TEネットワークを操作するためのフレームワークおよびサービスプロバイダーの要件について説明します。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Terminology ................................................4
2. Reference Model .................................................4
3. Detailed Requirements ...........................................5
3.1. End-to-End Signaling .......................................5
3.2. Triggered Establishment of GMPLS LSPs ......................5
3.3. Diverse Paths for End-to-End MPLS-TE LSPs ..................6
3.4. Advertisement of MPLS-TE Information via the GMPLS
Network ....................................................6
3.5. Selective Advertisement of MPLS-TE Information via
a Border Node ..............................................6
3.6. Interworking of MPLS-TE and GMPLS Protection ...............7
3.7. Independent Failure Recovery and Reoptimization ............7
3.8. Complexity and Risks .......................................7
3.9. Scalability Considerations .................................7
3.10. Performance Considerations ................................8
3.11. Management Considerations .................................8
4. Security Considerations .........................................8
5. Recommended Solution Architecture ...............................9
5.1. Use of Contiguous, Hierarchical, and Stitched LSPs ........10
5.2. MPLS-TE Control Plane Connectivity ........................10
5.3. Fast Reroute Protection ...................................10
5.4. GMPLS LSP Advertisement ...................................11
5.5. GMPLS Deployment Considerations ...........................11
6. Acknowledgments ................................................11
7. References .....................................................11
7.1. Normative References ......................................11
7.2. Informative References ....................................12
8. Contributors' Addresses ........................................13
Multiprotocol Label Switching traffic engineering (MPLS-TE) networks are often deployed over transport networks such that the transport networks provide connectivity between the Label Switching Routers (LSRs) in the MPLS-TE network. Increasingly, these transport networks are operated using a Generalized Multiprotocol Label Switching (GMPLS) control plane. Label Switched Paths (LSPs) in the GMPLS network provide connectivity as virtual data links advertised as TE links in the MPLS-TE network.
マルチプロトコルラベルスイッチングトラフィックエンジニアリング（MPLS-TE）ネットワークは、輸送ネットワークがMPLS-TEネットワークのラベルスイッチングルーター（LSR）間の接続を提供するように、トランスポートネットワーク上に展開されることがよくあります。ますます、これらの輸送ネットワークは、一般化されたマルチプロトコルラベルスイッチング（GMPLS）制御プレーンを使用して動作します。GMPLSネットワークのラベルスイッチ付きパス（LSP）は、MPLS-TEネットワークのTEリンクとして宣伝されている仮想データリンクとして接続性を提供します。
GMPLS protocols were developed as extensions to MPLS-TE protocols. MPLS-TE is limited to the control of packet switching networks, but GMPLS can also control technologies at layers one and two.
GMPLSプロトコルは、MPLS-TEプロトコルの拡張として開発されました。MPLS-TEはパケットスイッチングネットワークの制御に限定されていますが、GMPLSはレイヤー1と2でテクノロジーを制御することもできます。
The GMPLS network may be managed by an operator as a separate network (as it may have been when it was under management plane control before the use of GMPLS as a control plane), but optimizations of management and operation may be achieved by coordinating the use of the MPLS-TE and GMPLS networks and operating the two networks with a close client/server relationship.
GMPLSネットワークは、オペレーターが別のネットワークとして管理することができます（コントロールプレーンとしてGMPLSを使用する前に管理機の制御下にあった場合があります）が、使用を調整することで管理と運用の最適化を達成することができます。MPLS-TEおよびGMPLSネットワークと、クライアント/サーバーの密接な関係で2つのネットワークを操作します。
GMPLS LSP setup may be triggered by the signaling of MPLS-TE LSPs in the MPLS-TE network so that the GMPLS network is reactive to the needs of the MPLS-TE network. The triggering process can be under the control of operator policies without needing direct intervention by an operator.
GMPLS LSPセットアップは、MPLS-TEネットワーク内のMPLS-TE LSPのシグナルによってトリガーされる場合があり、GMPLSネットワークがMPLS-TEネットワークのニーズに反応します。トリガープロセスは、オペレーターによる直接的な介入を必要とせずに、オペレーターポリシーの管理下にある可能性があります。
The client/server configuration just described can also apply in migration scenarios for MPLS-TE packet switching networks that are being migrated to be under GMPLS control. [RFC5145] describes a migration scenario called the Island Model. In this scenario, groups of nodes (islands) are migrated from the MPLS-TE protocols to the GMPLS protocols and operate entirely surrounded by MPLS-TE nodes (the sea). This scenario can be effectively managed as a client/server network relationship using the framework described in this document.
説明されているクライアント/サーバーの構成は、GMPLS制御下にあるように移行されているMPLS-TEパケットスイッチングネットワークの移行シナリオにも適用できます。[RFC5145]は、島モデルと呼ばれる移行シナリオを説明しています。このシナリオでは、ノードのグループ（島）はMPLS-TEプロトコルからGMPLSプロトコルに移行し、MPLS-TEノード（海）に完全に囲まれた動作を行います。このシナリオは、このドキュメントで説明されているフレームワークを使用して、クライアント/サーバーネットワーク関係として効果的に管理できます。
In order to correctly manage the dynamic interaction between the MPLS and GMPLS networks, it is necessary to understand the operational requirements and the control that the operator can impose. Although this problem is very similar to the multi-layer networks described in [MLN-REQ], it must be noted that those networks operate GMPLS protocols in both the client and server networks, which facilitates smoother interworking. Where the client network uses MPLS-TE protocols over the GMPLS server network, there is a need to study the interworking of the two protocol sets.
MPLSネットワークとGMPLSネットワーク間の動的な相互作用を正しく管理するには、オペレーターが課すことができる運用要件と制御を理解する必要があります。この問題は[MLN-REQ]で説明されている多層ネットワークに非常に似ていますが、これらのネットワークは、クライアントネットワークとサーバーネットワークの両方でGMPLSプロトコルを操作していることに注意する必要があります。クライアントネットワークがGMPLSサーバーネットワークを介してMPLS-TEプロトコルを使用する場合、2つのプロトコルセットの相互作用を調査する必要があります。
This document examines the protocol requirements for protocol interworking to operate an MPLS-TE network as a client network over a GMPLS server network, and provides a framework for such operations.
このドキュメントでは、MPLS-TEネットワークをGMPLSサーバーネットワーク上のクライアントネットワークとして動作させるためのプロトコルインターワーキングのプロトコル要件を調べ、そのような操作のフレームワークを提供します。
Although this Informational document is not a protocol specification, 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 [RFC2119] for clarity of exposure of the requirements.
この情報ドキュメントはプロトコルの仕様ではありませんが、キーワードは「必須」、「必須」、「必須」、「しなければ」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「「、このドキュメントの「オプション」は、要件の露出を明確にするために[RFC2119]に記載されているように解釈されます。
The reference model used in this document is shown in Figure 1. It can easily be seen that the interworking between MPLS-TE and GMPLS protocols must occur on a node and not on a link. Nodes on the interface between the MPLS-TE and GMPLS networks must be responsible for handling both protocol sets and for providing any protocol interworking that is required. We call these nodes Border Routers.
このドキュメントで使用されている参照モデルを図1に示します。MPLS-TEとGMPLSプロトコル間のインターワーキングは、リンクではなくノードで発生する必要があることが簡単にわかります。MPLS-TEとGMPLSネットワークの間のインターフェイス上のノードは、両方のプロトコルセットの処理と、必要なプロトコルインターワーキングの提供を担当する必要があります。これらのノードを境界線ルーターと呼びます。
-------------- ------------------------- --------------
| MPLS Client | | GMPLS Server Network | | MPLS Client |
| Network | | | | Network |
| | | | | |
| ---- --+--+-- ----- ----- --+--+-- ---- |
| | | | | | | | | | | | | |
| |MPLS|_| Border |__|GMPLS|_|GMPLS|__| Border |_|MPLS| |
| |LSR | | Router | | LSR | | LSR | | Router | |LSR | |
| | | | | | | | | | | | | |
| ---- --+--+-- ----- ----- --+--+-- ---- |
| | | | | |
| | | | | |
-------------- ------------------------- --------------
| | GMPLS LSP | |
| |<------------------------->| |
| |
|<--------------------------------------------->|
End-to-End MPLS-TE LSP
Figure 1. Reference model of MPLS-TE/GMPLS interworking
図1. MPLS-TE/GMPLSインターワーキングの参照モデル
MPLS-TE network connectivity is provided through a GMPLS LSP which is created between Border Routers. End-to-end connectivity between MPLS LSRs in the client MPLS-TE networks is provided by an MPLS-TE LSP that is carried across the MPLS-TE network by the GMPLS LSP using hierarchical LSP techniques [RFC4206], LSP stitching segments
MPLS-TEネットワーク接続は、ボーダールーター間で作成されるGMPLS LSPを介して提供されます。クライアントMPLS-TEネットワークのMPLS LSRS間のエンドツーエンドの接続は、階層LSPテクニック[RFC4206]、LSPステッチセグメントを使用してGMPLS-TEネットワーク全体でGMPLS-TEネットワークを介して運ばれるMPLS-TE LSPによって提供されます。
[RFC5150], or a contiguous LSP. LSP stitching segments and contiguous LSPs are only available where the GMPLS network is a packet switching network.
[RFC5150]、または隣接するLSP。LSPステッチセグメントと隣接するLSPは、GMPLSネットワークがパケットスイッチングネットワークである場合にのみ使用できます。
This section describes detailed requirements for MPLS-TE/GMPLS interworking in support of the reference model shown in Figure 1.
The functional requirements for GMPLS-MPLS interworking described in this section must be met by any device participating in the interworking. This may include routers, servers, network management devices, path computation elements, etc.
このセクションで説明したGMPLS-MPLSインターワーキングの機能要件は、インターワーキングに参加するデバイスによって満たされる必要があります。これには、ルーター、サーバー、ネットワーク管理デバイス、パス計算要素などが含まれます。
The solution MUST be able to preserve MPLS signaling information signaled within the MPLS-TE client network at the start of the MPLS-TE LSP and deliver it on the other side of the GMPLS server network for use within the MPLS-TE client network at the end of the MPLS-TE LSP. This may require protocol mapping (and re-mapping), protocol tunneling, or the use of remote protocol adjacencies.
このソリューションは、MPLS-TE LSPの開始時にMPLS-TEクライアントネットワーク内でシグナル伝達されたMPLSシグナリング情報を保存し、GMPLSサーバーネットワークの反対側に配信する必要があります。MPLS-TE LSPの終わり。これには、プロトコルマッピング（および再マッピング）、プロトコルトンネル、またはリモートプロトコルの隣接の使用が必要になる場合があります。
The solution MUST provide the ability to establish end-to-end MPLS-TE LSPs over a GMPLS server network. It SHOULD be possible for GMPLS LSPs across the core network to be set up between Border Routers triggered by the signaling of MPLS-TE LSPs in the client network, and in this case, policy controls MUST be made available at the border routers so that the operator of the GMPLS network can manage how core network resources are utilized. GMPLS LSPs MAY also be pre-established as the result of management plane control.
このソリューションは、GMPLSサーバーネットワークを介してエンドツーエンドのMPLS-TE LSPを確立する機能を提供する必要があります。クライアントネットワークでのMPLS-TE LSPのシグナリングによってトリガーされるボーダールーター間でコアネットワークを介したGMPLS LSPをセットアップすることが可能である必要があります。GMPLSネットワークのオペレーターは、コアネットワークリソースの利用方法を管理できます。GMPLS LSPは、管理プレーン制御の結果として事前に確立される場合があります。
Note that multiple GMPLS LSPs may be set up between a given pair of Border Routers in support of connectivity in the MPLS client network. If these LSPs are advertised as TE links in the client network, the use of link bundling [RFC4201] can reduce any scaling concerns associated with the advertisements.
MPLSクライアントネットワークでの接続をサポートするために、特定のボーダールーターのペアの間に複数のGMPLS LSPがセットアップできることに注意してください。これらのLSPがクライアントネットワークのTEリンクとして宣伝されている場合、リンクバンドル[RFC4201]の使用は、広告に関連するスケーリングの懸念を減らすことができます。
The application of the Path Computation Element (PCE) [RFC4655] in the context of an inter-layer network [PCE-INT] may be considered to determine an end-to-end LSP with triggered GMPLS segment or tunnel.
層間ネットワーク[PCE-INT]のコンテキストでのパス計算要素（PCE）[RFC4655]の適用は、トリガーされたGMPLSセグメントまたはトンネルを備えたエンドツーエンドのLSPを決定するために考慮される場合があります。
The solution SHOULD provide the ability to establish end-to-end MPLS-TE LSPs having diverse paths for protection of the LSP traffic. This means that MPLS-TE LSPs SHOULD be kept diverse both within the client MPLS-TE network and as they cross the server GMPLS network. This means that there SHOULD be a mechanism to request the provision of diverse GMPLS LSPs between a pair of Border Routers to provide protection of the GMPLS span, but also that there SHOULD be a way to keep GMPLS LSPs between different Border Routers disjoint.
このソリューションは、LSPトラフィックを保護するための多様なパスを持つエンドツーエンドのMPLS-TE LSPを確立する機能を提供する必要があります。つまり、MPLS-TE LSPは、クライアントMPLS-TEネットワーク内およびサーバーGMPLSネットワークを横断する際の両方で多様に保つ必要があります。これは、GMPLSスパンの保護を提供するために、境界線ルーターのペア間で多様なGMPLS LSPの提供を要求するメカニズムが必要であることを意味しますが、異なる境界ルーター間のGMPLS LSPを維持する方法があるはずです。
The solution SHOULD provide the ability to exchange advertisements of TE information between MPLS-TE client networks across the GMPLS server network.
このソリューションは、GMPLSサーバーネットワーク全体のMPLS-TEクライアントネットワーク間でTE情報の広告を交換する機能を提供する必要があります。
The advertisement of TE information from within an MPLS-TE client network to all LSRs in the client network enables a head-end LSR to compute an optimal path for an LSP to a tail-end LSR that is reached over the GMPLS server network.
MPLS-TEクライアントネットワーク内からクライアントネットワーク内のすべてのLSRへのTE情報の広告により、ヘッドエンドLSRはLSPの最適なパスをGMPLSサーバーネットワークに到達したテールエンドLSRに計算できます。
Where there is more than one client MPLS-TE network, the TE information from separate MPLS-TE networks MUST be kept private, confidential and secure.
複数のクライアントMPLS-TEネットワークがある場合、個別のMPLS-TEネットワークからのTE情報をプライベート、機密、安全に保つ必要があります。
The solution SHOULD provide the ability to distribute TE reachability information from the GMPLS server network to MPLS-TE networks selectively. This information is useful for the LSRs in the MPLS-TE networks to compute paths that cross the GMPLS server network and to select the correct Border Routers to provide connectivity.
このソリューションは、GMPLSサーバーネットワークからMPLS-TEネットワークにTEリーチ可能性情報を選択的に配布する機能を提供する必要があります。この情報は、MPLS-TEネットワークのLSRSがGMPLSサーバーネットワークを横断するパスを計算し、正しいボーダールーターを選択して接続を提供するために役立ちます。
The solution MUST NOT distribute TE information from within a non-PSC (Packet Switch Capable) GMPLS server network to any client MPLS-TE network as that information may cause confusion and selection of inappropriate paths.
ソリューションは、非PSC（パケットスイッチ対応）GMPLSサーバーネットワーク内からTE情報をクライアントMPLS-TEネットワークに配布してはなりません。その情報は、不適切なパスの混乱と選択を引き起こす可能性があるためです。
The use of PCE [RFC4655] may provide a solution for non-PSC GMPLS networks supporting PSC MPLS networks.
PCE [RFC4655]の使用は、PSC MPLSネットワークをサポートする非PSC GMPLSネットワークのソリューションを提供する可能性があります。
If an MPLS-TE LSP is protected using MPLS Fast Reroute (FRR) [RFC4090], then similar protection MUST be provided over the GMPLS island. Operator and policy controls SHOULD be made available at the Border Router to determine how suitable protection is provided in the GMPLS island.
The solution SHOULD provide failure recovery and reoptimization in the GMPLS server network without impacting the MPLS-TE client network and vice versa. That is, it SHOULD be possible to recover from a fault within the GMPLS island or to reoptimize the path across the GMPLS island without requiring signaling activity within the MPLS-TE client network. Similarly, it SHOULD be possible to perform recovery or reoptimization within the MPLS-TE client network without requiring signaling activity within the GMPLS server networks.
このソリューションは、MPLS-TEクライアントネットワークに影響を与えることなく、GMPLSサーバーネットワークで障害回復と再最適化を提供する必要があります。つまり、GMPLS島内の障害から回復したり、MPLS-TEクライアントネットワーク内のシグナル伝達活動を必要とせずにGMPLS島を横断するパスを再現することが可能であるはずです。同様に、GMPLSサーバーネットワーク内でシグナリングアクティビティを必要とせずに、MPLS-TEクライアントネットワーク内で回復または再最適化を実行することが可能であるはずです。
If a failure in the GMPLS server network can not be repaired transparently, some kind of notification of the failure SHOULD be transmitted to MPLS-TE network.
GMPLSサーバーネットワークの障害を透過的に修復できない場合、障害のある種の通知をMPLS-TEネットワークに送信する必要があります。
The solution SHOULD NOT introduce unnecessary complexity to the current operating network to such a degree that it would affect the stability and diminish the benefits of deploying such a solution in service provider networks.
このソリューションは、現在のオペレーティングネットワークに不必要な複雑さを、安定性に影響を与え、サービスプロバイダーネットワークにそのようなソリューションを展開する利点を減らす程度まで導入すべきではありません。
The solution MUST scale well with consideration to at least the following metrics.
ソリューションは、少なくとも次のメトリックを考慮して十分にスケーリングする必要があります。
- The number of GMPLS-capable nodes (i.e., the size of the GMPLS server network).
-
- The number of MPLS-TE-capable nodes (i.e., the size of the MPLS-TE client network).
- MPLS-TE対応ノードの数（つまり、MPLS-TEクライアントネットワークのサイズ）。
- The number of MPLS-TE client networks.
- MPLS-TEクライアントネットワークの数。
- The number of GMPLS LSPs.
- GMPLS LSPの数。
- The number of MPLS-TE LSPs.
-
The solution SHOULD be evaluated with regard to the following criteria.
ソリューションは、次の基準に関して評価する必要があります。
- Failure and restoration time.
- 故障と回復時間。
- Impact and scalability of the control plane due to added overheads.
- オーバーヘッドが追加されたためのコントロールプレーンの衝撃とスケーラビリティ。
- Impact and scalability of the data/forwarding plane due to added overheads.
- オーバーヘッドが追加されたためのデータ/転送面の影響とスケーラビリティ。
Manageability of the deployment of an MPLS-TE client network over GMPLS server network MUST addresses the following considerations.
GMPLSサーバーネットワーク上のMPLS-TEクライアントネットワークの展開の管理可能性は、以下の考慮事項に対処する必要があります。
- Need for coordination of MIB modules used for control plane management and monitoring in the client and server networks.
- クライアントおよびサーバーネットワークでの制御プレーン管理と監視に使用されるMIBモジュールの調整が必要です。
- Need for diagnostic tools that can discover and isolate faults across the border between the MPLS-TE client and GMPLS server networks.
- MPLS-TEクライアントとGMPLSサーバーネットワークの間の境界全体に障害を発見および分離できる診断ツールが必要です。
Border routers in the model described in this document are present on administrative domain boundaries. That is, the administrative boundary does not lie on a link as it might in the inter-Autonomous-System (inter-AS) case seen in IP networks. Thus, many security concerns for the inter-domain exchange of control plane messages do not arise in this model -- the border router participates fully in both the MPLS and the GMPLS network and must participate in the security procedures of both networks. Security considerations for MPLS-TE and GMPLS protocols are discussed in [SECURITY].
このドキュメントに記載されているモデルのボーダールーターは、管理ドメインの境界に存在します。つまり、管理境界は、IPネットワークで見られる自律システム間（AS間）ケースにあるように、リンク上にありません。したがって、このモデルでは、コントロールプレーンのメッセージのドメイン間交換に関する多くのセキュリティ上の懸念が生じません。ボーダールーターはMPLSとGMPLSネットワークの両方に完全に参加し、両方のネットワークのセキュリティ手順に参加する必要があります。MPLS-TEおよびGMPLSプロトコルのセキュリティ上の考慮事項は、[セキュリティ]で説明されています。
However, policy considerations at the border routers are very important and may be considered to form part of the security of the networks. In particular, the server network (the GMPLS network) may wish to protect itself from behavior in the client network (such as frequent demands to set up and tear down server LSPs) by appropriate policies implemented at the border routers. It should be observed that, because the border routers form part of both networks, they are trusted in both networks, and policies configured (whether locally or centrally) for use by a border router are expected to be observed.
ただし、ボーダールーターでの政策上の考慮事項は非常に重要であり、ネットワークのセキュリティの一部を形成すると考えられる場合があります。特に、サーバーネットワーク（GMPLSネットワーク）は、Border Routersで実装された適切なポリシーにより、クライアントネットワーク（サーバーLSPのセットアップを頻繁に設定および取り壊すなど）の動作から自分自身を保護したい場合があります。ボーダールーターは両方のネットワークの一部を形成するため、ボーダールーターが使用するために（ローカルまたは中央であろうと）両方のネットワークで信頼されているため、ボーダールーターが使用するために信頼されることが観察されます。
Nevertheless, authentication and access controls for operators will be particularly important at border routers. Operators of the client MPLS-TE network MUST NOT be allowed to configure the server GMPLS network (including setting server network policies), and operators of the server GMPLS network MUST NOT be able configure the client MPLS-TE network. Obviously, it SHOULD be possible to grant an operator privileges in both networks. It may also be desirable to give operators of one network access to (for example) status information about the other network.
それにもかかわらず、オペレーターの認証とアクセス制御は、ボーダールーターで特に重要です。クライアントMPLS-TEネットワークのオペレーターは、サーバーGMPLSネットワーク（サーバーネットワークポリシーの設定を含む）を構成することを許可されていない必要があり、サーバーGMPLSネットワークのオペレーターがクライアントMPLS-TEネットワークを構成できない必要があります。明らかに、両方のネットワークでオペレーターの特権を付与することが可能であるはずです。また、1つのネットワークアクセスのオペレーターに、他のネットワークに関する（たとえば）ステータス情報へのアクセスを提供することも望ましい場合があります。
Mechanisms for authenticating operators and providing access controls are not part of the responsibilities of the GMPLS protocol set, and will depend on the management plane protocols and techniques implemented.
オペレーターを認証し、アクセス制御を提供するためのメカニズムは、GMPLSプロトコルセットの責任の一部ではなく、実装された管理プレーンプロトコルと技術に依存します。
The recommended solution architecture to meet the requirements set out in Section 3 is known as the Border Peer Model. This architecture is a variant of the Augmented Model described in [RFC3945]. The remainder of this document presents an overview of this architecture.
セクション3に記載されている要件を満たすための推奨ソリューションアーキテクチャは、Border Peerモデルとして知られています。このアーキテクチャは、[RFC3945]で説明されている拡張モデルのバリアントです。このドキュメントの残りの部分は、このアーキテクチャの概要を示しています。
In the Augmented Model, routing information from the lower layer (server) network is filtered at the interface to the higher layer (client) network and a subset of the information is distributed within the higher layer network.
拡張モデルでは、下層（サーバー）ネットワークからのルーティング情報がインターフェイスで高層（クライアント）ネットワークにフィルタリングされ、情報のサブセットが高層ネットワーク内に分散されます。
In the Border Peer Model, the interface between the client and server networks is the Border Router. This router has visibility of the routing information in the server network yet also participates as a peer in the client network. Thus, the Border Router has full visibility into both networks. However, the Border Router does not distribute server routing information into the client network, nor does it distribute client routing information into the server network.
Border Peerモデルでは、クライアントネットワークとサーバーネットワークの間のインターフェイスがBorder Routerです。このルーターは、サーバーネットワーク内のルーティング情報の可視性を持っていますが、クライアントネットワークのピアとしても参加しています。したがって、Border Routerは両方のネットワークを完全に可視化します。ただし、Border Routerは、サーバールーティング情報をクライアントネットワークに配布することも、クライアントルーティング情報をサーバーネットワークに配布することもありません。
The Border Peer Model may also be contrasted with the Overlay Model [RFC3945]. In this model there is a protocol request/response interface (the user network interface (UNI)) between the client and server networks. [RFC4208] shows how this interface may be supported by GMPLS protocols operated between client edge and server edge routers while retaining the routing information within the server network. That is, in the Overlay Model there is no exchange of routing or reachability information between client and server networks, and no network element has visibility into both client and server networks. The Border Peer Model can be viewed as placing the UNI within the Border Router thus giving the Border Router peer capabilities in both the client and server network.
ボーダーピアモデルは、オーバーレイモデル[RFC3945]とも対照的です。このモデルでは、クライアントネットワークとサーバーネットワークの間にプロトコル要求/応答インターフェイス（ユーザーネットワークインターフェイス（UNI））があります。[RFC4208]は、サーバーネットワーク内でルーティング情報を保持しながら、クライアントエッジとサーバーエッジルーターの間で動作するGMPLSプロトコルによってこのインターフェイスがどのようにサポートされるかを示しています。つまり、オーバーレイモデルでは、クライアントネットワークとサーバーネットワーク間のルーティングや到達可能性の情報の交換はなく、クライアントネットワークとサーバーネットワークの両方を可視化するネットワーク要素はありません。ボーダーピアモデルは、UNIをボーダールーター内に配置すると見なすことができ、クライアントネットワークとサーバーネットワークの両方でボーダールーターのピア機能を提供します。
All three LSP types MAY be supported in the Border Peer Model, but contiguous LSPs are the hardest to support because they require protocol mapping between the MPLS-TE client network and the GMPLS server network. Such protocol mapping can be achieved currently since MPLS-TE signaling protocols are a subset of GMPLS, but this mechanism is not future-proofed.
3つのLSPタイプはすべて、Border Peerモデルでサポートされる場合がありますが、MPLS-TEクライアントネットワークとGMPLSサーバーネットワークの間のプロトコルマッピングが必要なため、隣接するLSPはサポートが最も困難です。MPLS-TEシグナル伝達プロトコルはGMPLSのサブセットであるため、このようなプロトコルマッピングは現在達成できますが、このメカニズムは将来的には把握されていません。
Contiguous and stitched LSPs can only be supported where the GMPLS server network has the same switching type (that is, packet switching) as the MPLS-TE network. Requirements for independent failure recovery within the GMPLS island require the use of loose path reoptimization techniques [RFC4736] and end-to-end make-before-break [RFC3209], which will not provide rapid recovery.
隣接したステッチLSPは、GMPLSサーバーネットワークがMPLS-TEネットワークと同じスイッチングタイプ（つまり、パケットスイッチング）を持っている場合にのみサポートできます。GMPLS島内の独立した障害回復の要件には、ゆるい経路再最適化技術[RFC4736]およびエンドツーエンドのメイクブレイク[RFC3209]を使用する必要がありますが、これは迅速な回復を提供しません。
For these reasons, the use of hierarchical LSPs across the server network is RECOMMENDED for the Border Peer Model, but see the discussion of Fast Reroute protection in Section 5.3.
これらの理由から、サーバーネットワーク全体で階層LSPの使用がBorder Peerモデルに推奨されますが、セクション5.3の高速リルート保護の説明を参照してください。
Control plane connectivity between MPLS-TE LSRs connected by a GMPLS island in the Border Peer Model MAY be provided by the control channels of the GMPLS network. If this is done, a tunneling mechanism (such as GRE [RFC2784]) SHOULD be used to ensure that MPLS-TE information is not consumed by the GMPLS LSRs. But care is required to avoid swamping the control plane of the GMPLS network with MPLS-TE control plane (particularly routing) messages.
境界ピアモデルのGMPLS島で接続されたMPLS-TE LSR間の制御プレーン接続は、GMPLSネットワークの制御チャネルによって提供される場合があります。これが行われた場合、GMPLS LSRSによってMPLS-TE情報が消費されないようにするために、トンネリングメカニズム（GRE [RFC2784]など）を使用する必要があります。ただし、MPLS-TEコントロールプレーン（特にルーティング）メッセージを使用してGMPLSネットワークのコントロールプレーンを圧倒しないように注意する必要があります。
In order to ensure scalability, control plane messages for the MPLS-TE client network MAY be carried between Border Routers in a single hop MPLS-TE LSP routed through the data plane of the GMPLS server network.
スケーラビリティを確保するために、GMPLSサーバーネットワークのデータプレーンを介してルーティングされた単一のホップMPLS-TE LSPで、MPLS-TEクライアントネットワークのコントロールプレーンメッセージをボーダールーター間で運ぶことができます。
If the GMPLS network is packet switching, Fast Reroute protection can be offered on all hops of a contiguous LSP. If the GMPLS network is packet switching then all hops of a hierarchical GMPLS LSP or GMPLS stitching segment can be protected using Fast Reroute. If the end-to-end MPLS-TE LSP requests Fast Reroute protection, the GMPLS packet switching network SHOULD provide such protection.
GMPLSネットワークがパケットスイッチングである場合、隣接するLSPのすべてのホップで高速リルート保護を提供できます。GMPLSネットワークがパケットスイッチングである場合、階層的なGMPLS LSPまたはGMPLSステッチセグメントのすべてのホップを、高速再ルートを使用して保護できます。エンドツーエンドのMPLS-TE LSPが高速リルート保護を要求する場合、GMPLSパケットスイッチングネットワークはそのような保護を提供するはずです。
However, note that it is not possible to provide FRR node protection of the upstream Border Router without careful consideration of available paths, and protection of the downstream Border Router is not possible where hierarchical LSPs or stitching segments are used.
ただし、利用可能なパスを慎重に考慮せずに上流の境界ルーターのFRRノード保護を提供することはできないことに注意してください。また、階層的なLSPまたはステッチセグメントが使用される場合、下流の境界ルーターの保護は不可能です。
Note further that Fast Reroute is not available in non-packet technologies. However, other protection techniques are supported by GMPLS for non-packet networks and are likely to provide similar levels of protection.
さらに、Fast Rerouteは非パケットテクノロジーでは利用できないことに注意してください。ただし、他の保護技術は、非パケットネットワークのGMPLによってサポートされており、同様のレベルの保護を提供する可能性があります。
The limitations of FRR need careful consideration by the operator and may lead to the decision to provide end-to-end protection for the MPLS-TE LSP.
FRRの制限は、オペレーターによる慎重な検討が必要であり、MPLS-TE LSPにエンドツーエンドの保護を提供する決定につながる可能性があります。
In the Border Peer Model, the LSPs established by the Border Routers in the GMPLS server network SHOULD be advertised in the MPLS-TE client network as real or virtual links. In case real links are advertised into the MPLS-TE client network, the Border Routers in the MPLS-TE client network MAY establish IGP neighbors. The Border Routers MAY automatically advertise the GMPLS LSPs when establishing them.
Border Peerモデルでは、GMPLSサーバーネットワークのBorder Routersによって確立されたLSPは、MPLS-TEクライアントネットワークで実際のリンクまたは仮想リンクとして宣伝する必要があります。実際のリンクがMPLS-TEクライアントネットワークに宣伝されている場合、MPLS-TEクライアントネットワークのボーダールーターがIGP近隣を確立する可能性があります。ボーダールーターは、GMPLS LSPを確立するときに自動的に宣伝する場合があります。
The Border Peer Model does not require the existing MPLS-TE client network to be GMPLS aware and does not affect the operation and management of the existing MPLS-TE client network. Only border routers need to be upgraded with the GMPLS functionality. In this fashion, the Border Peer Model renders itself for incremental deployment of the GMPLS server network, without requiring reconfiguration of existing areas/ASs, changing operation of IGP and BGP or software upgrade of the existing MPLS-TE client network.
Border Peerモデルでは、既存のMPLS-TEクライアントネットワークがGMPLSを認識する必要はなく、既存のMPLS-TEクライアントネットワークの操作と管理に影響しません。GMPLS機能でアップグレードする必要があるのは、ボーダールーターのみです。この方法で、ボーダーピアモデルは、既存の領域/ASSの再構成、IGPおよびBGPの動作の変更、または既存のMPLS-TEクライアントネットワークのソフトウェアアップグレードを必要とせずに、GMPLSサーバーネットワークの増分展開にそれ自体をレンダリングします。
The author would like to express thanks to Raymond Zhang, Adrian Farrel, and Deborah Brungard for their helpful and useful comments and feedback.
著者は、レイモンド・チャン、エイドリアン・ファレル、デボラ・ブランガードに、彼らの役に立つ有用なコメントとフィードバックをしてくれたことに感謝します。
[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月。
[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トンネルのRSVPへの拡張」、RFC 3209、12月2001年。
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945] Mannie、E.、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）アーキテクチャ」、RFC 3945、2004年10月。
[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
[RFC4090] Pan、P.、Ed。、Ed。、Swallow、G.、Ed。、およびA. Atlas、ed。、「LSP TunnelsのRSVP-TEへの拡張速度」、RFC 4090、2005年5月。
[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
[RFC4201] Kompella、K.、Rekhter、Y.、およびL. Berger、「MPLS Traffic Engineering（TE）のリンクバンドリング」、RFC 4201、2005年10月。
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
[RFC4206] Kompella、K。およびY. Rekhter、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）トラフィックエンジニアリング（TE）を備えたラベルスイッチ付きパス（LSP）階層」、2005年10月。
[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, "Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model", RFC 4208, October 2005.
[RFC4208] Swallow、G.、Drake、J.、Ishimatsu、H。、およびY. Rekhter、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）ユーザーネットワークインターフェイス（UNI）：リソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）オーバーレイモデルのサポート」、RFC 4208、2005年10月。
[RFC5150] Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel, "Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE)", RFC 5150, February 2008.
[RFC5150] Ayyangar、A.、Kompella、K.、Vasseur、Jp。、およびA. Farrel、「一般化されたマルチプロトコルラベルスイッチングトラフィックエンジニアリング（GMPLS TE）を使用したラベルスイッチパスステッチ」、RFC 5150、2008年2月。
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[RFC2784] Farinacci、D.、Li、T.、Hanks、S.、Meyer、D。、およびP. Traina、「Generic Routing Cancapstulation（GRE）」、RFC 2784、2000年3月。
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4655] Farrel、A.、Vasseur、J.-P。、およびJ. Ash、「パス計算要素（PCE）ベースのアーキテクチャ」、RFC 4655、2006年8月。
[RFC4736] Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "Reoptimization of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Loosely Routed Label Switched Path (LSP)", RFC 4736, November 2006.
[RFC4736] Vasseur、Jp。、ed。、ekejiri、Y。、およびR. Zhang、「マルチプロトコルラベルスイッチング（MPLS）交通工学（TE）の再オプチミー化（TE）ゆるいルーティングラベルスイッチドパス（LSP）」、RFC 4736、2006年11月。
[RFC5145] Shiomoto, K., Ed., "Framework for MPLS-TE to GMPLS Migration", RFC 5145, March 2008.
[RFC5145] Shiomoto、K。、ed。、「MPLS-TEからGMPLS移行のフレームワーク」、RFC 5145、2008年3月。
[MLN-REQ] Shiomoto, K., Papadimitriou, D., Le Roux, J.L., Vigoureux, M., and D. Brungard, "Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN)", Work in Progress, January 2008.
[MLN-Req] Shiomoto、K.、Papadimitriou、D.、Le Roux、J.L.、Vigoureux、M。、およびD. Brungard、「GMPLSベースのマルチレジオンおよびマルチレイヤーネットワーク（MRN/MLN）の要件」、作業中の2008年1月。
[PCE-INT] Oki, E., Le Roux , J-L., and A. Farrel, "Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering," Work in Progress, January 2008.
[PCE-INT] Oki、E.、Le Roux、J-L。、およびA. Farrel、「PCEベースの層間MPLSおよびGMPLSトラフィックエンジニアリングのフレームワーク」、2008年1月、Work in Progress。
[SECURITY] Fang, L., "Security Framework for MPLS and GMPLS Networks", Work in Progress, November 2007.
[セキュリティ] Fang、L。、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、2007年11月、Work in Progress。
Tomohiro Otani KDDI R&D Laboratories, Inc. 2-1-15 Ohara Kamifukuoka Saitama, 356-8502, Japan
Tomohiro Otani Kddi R＆D Laboratories、Inc。2-1-15 Ohara Kamifukuoka Saitama、356-8502、日本
Phone: +81-49-278-7357
EMail: otani@kddilabs.jp
Shuichi Okamoto NICT JGN II Tsukuba Reserach Center 1-8-1, Otemachi Chiyoda-ku, Tokyo, 100-0004, Japan
岡本nict jgn ii tsukuba Reserach Center 1-8-1、Otemachi chiyoda-ku、東京、100-0004、日本
Phone: +81-3-5200-2117
EMail: okamoto-s@nict.go.jp
Kazuhiro Fujihara NTT Communications Corporation Tokyo Opera City Tower 3-20-2 Nishi Shinjuku, Shinjuku-ku Tokyo 163-1421, Japan
カズヒロ藤原ntt通信会社東京オペラシティタワー3-20-2西shinjuku、shinju-ku tokyo 163-1421、日本
EMail: kazuhiro.fujihara@ntt.com
Yuichi Ikejiri NTT Communications Corporation Tokyo Opera City Tower 3-20-2 Nishi Shinjuku, Shinjuku-ku Tokyo 163-1421, Japan
Yuichi ikejiri ntt Communications Corporation Tokyo Opera City Tower 3-20-2 Nishi Shinjuku、Shinjuku-Ku Tokyo 163-1421、日本
EMail: y.ikejiri@ntt.com
Editor's Address
編集者のアドレス
Kenji Kumaki KDDI Corporation Garden Air Tower Iidabashi, Chiyoda-ku, Tokyo, 102-8460, JAPAN
Kenji Kumaki Kddi Corporation Garden Air Tower Iidabashi、Chiyoda-Ku、Tokyo、102-8460、日本
EMail: ke-kumaki@kddi.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。