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
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（GMPLS）ネットワークへのクライアント・ネットワークとして（MPLS）トラフィックエンジニアリング（TE）のネットワークをマルチプロトコルラベルスイッチングの動作は共存プロトコルモデルで提供されるものに比べて運用能力を強化した（すなわち、オーバー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）が発信され、ルータ（LSR）をスイッチングMPLSラベルに終了します。 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ネットワークは、MPLS-TEネットワークのニーズに反応性であるように、GMPLS LSPセットアップは、MPLS-TEネットワークにおけるMPLS-TE LSPのシグナリングによってトリガされてもよいです。トリガープロセスは、オペレータによる直接介入を必要とすることなく、オペレータポリシーの制御下に置くことができます。
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]は島のモデルと呼ばれる移行シナリオについて説明します。このシナリオでは、ノード（アイランド）の基は、GMPLSプロトコルにMPLS-TEプロトコルから移行され、完全にMPLS-TEノード（SEA）に囲まれて動作します。このシナリオでは、効果的に、この文書で説明するフレームワークを使用して、クライアント/サーバ・ネットワークの関係として管理することができます。
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.
この文書では、GMPLSサーバネットワークを介してクライアント・ネットワークとしてMPLS-TEネットワークを動作させるためのプロトコル相互動作のためのプロトコル要件を調べ、そのような操作のためのフレームワークを提供します。
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.
この情報文書はプロトコル仕様ではありませんが、キーワードは "MUST"、 "MUST NOT"、 "REQUIRED"、 "SHALL"、 "SHOULD"、 "ないもの"、 "推奨" "ない（SHOULD NOT）"、「MAY 」、および 『OPTIONAL』本書では[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.
本書で使用される参照モデルは、容易にMPLS-TEやGMPLSプロトコル間のインターワーキングノードではなく、リンク上で発生しなければならないことがわかる。図1に示されています。 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
MPLS-TE / GMPLS相互動作の図1参照モデル
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 LSRの間のエンドツーエンド接続は、階層LSP技術[RFC4206]、LSPステッチのセグメントを使用してGMPLS LSPによって、MPLS-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。 GMPLSネットワークがパケット交換ネットワークであるLSPステッチセグメントと隣接のLSPのみ利用可能です。
This section describes detailed requirements for MPLS-TE/GMPLS interworking in support of the reference model shown in Figure 1.
このセクションでは、図1に示した参照モデルのサポートでMPLS-TE / GMPLSインターワーキングのための詳細な要件を記載しています。
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シグナリング情報を保存することができるとでMPLS-TEクライアントネットワーク内で使用するための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を確立する能力を提供しなければなりません。コアネットワーク全体のGMPLSのLSPは、クライアントネットワーク内のMPLS-TE 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.
複数のGMPLSのLSPは、MPLSクライアントのネットワーク内の接続をサポートする境界ルータの所定の対間に設定することができることに注意してください。これらの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）の適用[RFC4655] [PCE-INT]はトリガ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クライアントネットワーク間での情報の広告を交換する能力を提供する必要があります。
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.
クライアントのネットワーク内のすべてのLSRにMPLS-TEクライアントネットワーク内からTE情報の広告はGMPLSサーバネットワーク上で到達したテールエンドLSRのLSPのための最適経路を計算するために、ヘッドエンド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.
溶液を選択的にMPLS-TEネットワークにGMPLSサーバネットワークからTE到達可能性情報を配布する能力を提供すべきです。 MPLS-TEネットワーク内のLSRは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内からのTE情報を配信してはならないこと情報が不適切な経路の混乱及び選択を引き起こす可能性があり、任意のクライアントMPLS-TEネットワークにGMPLSサーバネットワーク（パケットができるスイッチ）。
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.
MPLS-TE LSPは、高速リルート（FRR）[RFC4090] MPLSを使用して保護されている場合、同様の保護は、GMPLSアイランド上に設けなければなりません。オペレータとポリシーコントロールは、GMPLS島で提供される方法の適切な保護を決定するために境界ルータで利用できるようにすべきです。
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).
- GMPLS可能なノードの数（即ち、GMPLSサーバネットワークのサイズ）。
- 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.
- MPLS-TEのLSPの数。
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サーバネットワークMUSTオーバー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プロトコルのためのセキュリティ上の考慮事項は、[SECURITY]で議論されています。
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ネットワーク）は、境界ルータに実装され、適切なポリシーによって（例えば、サーバの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ネットワークできるのconfigureしているはずがありません。もちろん、両方のネットワークにオペレータ権限を付与することが可能です。また、他のネットワークについて（例えば）ステータス情報へのネットワークアクセスのオペレータを与えることが望ましいかもしれません。
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節に定める要件を満たすために推奨されるソリューションのアーキテクチャはボーダーピアモデルとして知られています。このアーキテクチャは、[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.
ボーダーピアモデルでは、クライアントとサーバネットワーク間のインタフェースは、境界ルータです。このルータは、まだサーバネットワーク内のルーティング情報の可視性を持っても、クライアントネットワーク内のピアとして参加しています。このように、境界ルータは、両方のネットワークへの完全な可視性を持っています。しかし、境界ルータは、クライアントのネットワークにサーバーのルーティング情報を配布しません。また、サーバネットワークにルーティング情報をクライアントに配布しません。
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タイプはボーダーピアモデルでサポートされるかもしれないが、彼らは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.
GMPLSサーバネットワークは、MPLS-TEネットワークと同じ交換型（すなわち、パケット交換である）を有し、ここで、連続およびステッチのLSPのみをサポートすることができます。 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の使用はボーダーピアモデルのために推奨されますが、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ネットワークの制御チャネルによって提供されてもよいです。これが行われる場合、（例えば、GRE [RFC2784]など）トンネリングメカニズムは、MPLS-TE情報はGMPLSののLSRによって消費されていないことを確認するために使用されるべきです。しかし、注意が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.
スケーラビリティを確保するために、MPLS-TEクライアントネットワークのための制御プレーンメッセージは、MPLS-TE LSPがGMPLSサーバネットワークのデータプレーンを介してルーティング単一ホップにおけるボーダールータ間で実行されてもよいです。
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.
高速リルートは、非パケット技術では利用できないことにさらに注意してください。しかし、他の保護技術は、非パケットネットワークのためのGMPLSによるサポートと保護の同様のレベルを提供する可能性があります。
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.
ボーダーピアモデルでは、GMPLSサーバネットワーク内の境界ルータによって確立された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.
ボーダーピアモデルは、GMPLSを認識するように、既存のMPLS-TEクライアントネットワークを必要とせず、既存のMPLS-TEクライアントネットワークの運用管理に影響を与えません。唯一の境界ルータは、GMPLS機能をアップグレードする必要があります。このように、ボーダーピアモデルは、既存エリア/のASの再構成を必要と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.
作者は彼らの役に立つと有益なコメントやフィードバックのためのレイモンド・チャン、エードリアンファレル、そしてデボラBrungardへの感謝を表したいと思います。
[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月。
[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。
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945]マニー、E.、エド。、 "一般化マルチプロトコルラベルスイッチング（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]パン、P.、エド。、ツバメ、G.、エド。、およびA.アトラス編、 "高速リルート機能拡張LSPトンネルのための-TEをRSVPする"、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.バーガー、 "MPLSでのリンクバンドルトラフィックエンジニアリング（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は、RFC 4206、2005年10月 "ラベル・パス（LSP）の階層は、一般マルチプロトコルラベルスイッチング（GMPLS）トラフィックエンジニアリング（TE）との交換しました"。
[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]ツバメ、G.、ドレイク、J.、石松、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.ファレルは、2008年2月、RFC 5150 "ラベルは、トラフィックエンジニアリング（TE GMPLS）をスイッチング汎用マルチプロトコルラベルとステッチスイッチパス"。
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[RFC2784]ファリナッチ、D.、李、T.、ハンクス、S.、マイヤー、D.、およびP. Trainaの、 "総称ルーティングカプセル化（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]ファレル、A.、Vasseur、J.-P.、およびJ.アッシュ、 "パス計算要素（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。、エド。、池尻、Y.、およびR.張は、 "マルチプロトコルラベルの再最適化スイッチング（MPLS）トラフィックエンジニアリング（TE）緩くルーティングラベルスイッチパス（LSP）"、RFC 4736、2006年11月。
[RFC5145] Shiomoto, K., Ed., "Framework for MPLS-TE to GMPLS Migration", RFC 5145, March 2008.
[RFC5145] Shiomoto、K.、エド。、 "GMPLSへの移行MPLS-TEのための枠組み"、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.、ルルー、JL、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]沖、E.、ル・ルー、J-L。、およびA.ファレル、進行中の作業、2008年1月 "PCEベースの層間MPLSおよびGMPLSトラフィックエンジニアリングのためのフレームワーク"。
[SECURITY] Fang, L., "Security Framework for MPLS and GMPLS Networks", Work in Progress, November 2007.
[SECURITY]牙、L.、 "MPLSおよびGMPLSネットワークのセキュリティフレームワーク"、進歩、2007年11月に作業。
Tomohiro Otani KDDI R&D Laboratories, Inc. 2-1-15 Ohara Kamifukuoka Saitama, 356-8502, Japan
ともひろ おたに Ｋっぢ Ｒ＆Ｄ ぁぼらとりえｓ、 いんｃ。 ２ー１ー１５ おはら かみふくおか さいたま、 ３５６ー８５０２、 じゃぱん
Phone: +81-49-278-7357 EMail: otani@kddilabs.jp
電話：+ 81-49-278-7357 Eメール：otani@kddilabs.jp
Shuichi Okamoto NICT JGN II Tsukuba Reserach Center 1-8-1, Otemachi Chiyoda-ku, Tokyo, 100-0004, Japan
しゅいち おかもと にＣＴ ＪＧん いい つくば れせらｃｈ せんてｒ １ー８ー１、 おてまち ちよだーく、 ときょ、 １００ー０００４、 じゃぱん
Phone: +81-3-5200-2117 EMail: okamoto-s@nict.go.jp
電話：+ 81-3-5200-2117 Eメール：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
かずひろ ふじはら んっｔ こっむにかちおんｓ こｒぽらちおん ときょ おぺら しｔｙ とうぇｒ ３ー２０ー２ にし しんじゅく、 しんじゅくーく ときょ １６３ー１４２１、 じゃぱん
EMail: kazuhiro.fujihara@ntt.com
メールアドレス：kazuhiro.fujihara@ntt.com
Yuichi Ikejiri NTT Communications Corporation Tokyo Opera City Tower 3-20-2 Nishi Shinjuku, Shinjuku-ku Tokyo 163-1421, Japan
ゆいち いけじり んっｔ こっむにかちおんｓ こｒぽらちおん ときょ おぺら しｔｙ とうぇｒ ３ー２０ー２ にし しんじゅく、 しんじゅくーく ときょ １６３ー１４２１、 じゃぱん
EMail: y.ikejiri@ntt.com
メールアドレス：y.ikejiri@ntt.com
Editor's Address
編集者の住所
Kenji Kumaki KDDI Corporation Garden Air Tower Iidabashi, Chiyoda-ku, Tokyo, 102-8460, JAPAN
けんじ くまき Ｋっぢ こｒぽらちおん がｒでん あいｒ とうぇｒ いいだばし、 ちよだーく、 ときょ、 １０２ー８４６０、 じゃぱん
EMail: ke-kumaki@kddi.com
メールアドレス：ke-kumaki@kddi.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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に情報を記述してください。