[要約] RFC 5145は、MPLS-TEからGMPLSへの移行のためのフレームワークを提供しています。その目的は、MPLS-TEネットワークをGMPLSネットワークに移行するためのガイドラインを提供し、ネットワークの柔軟性と効率を向上させることです。
Network Working Group K. Shiomoto, Ed.
Request for Comments: 5145 NTT
Category: Informational March 2008
Framework for MPLS-TE to GMPLS Migration
MPLS-TEからGMPLS移行のフレームワーク
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
概要
The migration from Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) to Generalized MPLS (GMPLS) is the process of evolving an MPLS-TE control plane to a GMPLS control plane. An appropriate migration strategy will be selected based on various factors including the service provider's network deployment plan, customer demand, and operational policy.
マルチプロトコルラベルスイッチング（MPLS）トラフィックエンジニアリング（TE）から一般化されたMPLS（GMPLS）への移行は、MPLS-TEコントロールプレーンをGMPLSコントロールプレーンに進化させるプロセスです。サービスプロバイダーのネットワーク展開計画、顧客需要、運用ポリシーなど、さまざまな要因に基づいて、適切な移行戦略が選択されます。
This document presents several migration models and strategies for migrating from MPLS-TE to GMPLS. In the course of migration, MPLS-TE and GMPLS devices, or networks, may coexist that may require interworking between MPLS-TE and GMPLS protocols. Aspects of the required interworking are discussed as it will influence the choice of a migration strategy. This framework document provides a migration toolkit to aid the operator in selection of an appropriate strategy.
このドキュメントでは、MPLS-TEからGMPLに移行するためのいくつかの移行モデルと戦略を示しています。移行の過程で、MPLS-TEおよびネットワークは、MPLS-TEとGMPLSプロトコル間のインターワーキングを必要とする可能性のある共存する可能性があります。必要なインターワーキングの側面については、移行戦略の選択に影響を与えるため説明されます。このフレームワークドキュメントは、オペレーターが適切な戦略の選択を支援するための移行ツールキットを提供します。
This framework document also lists a set of solutions that may aid in interworking, and highlights a set of potential issues.
このフレームワークドキュメントには、インターワーキングに役立つソリューションのセットもリストされており、潜在的な問題のセットを強調しています。
Table of Contents
目次
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................3
3. Motivations for Migration .......................................4
4. MPLS to GMPLS Migration Models ..................................5
4.1. Island Model ...............................................5
4.1.1. Balanced Islands ....................................6
4.1.2. Unbalanced Islands ..................................6
4.2. Integrated Model ...........................................7
4.3. Phased Model ...............................................8
5. Migration Strategies and Toolkit ................................8
5.1. Migration Toolkit ..........................................9
5.1.1. Layered Networks ....................................9
5.1.2. Routing Interworking ...............................11
5.1.3. Signaling Interworking .............................12
5.1.4. Path Computation Element ...........................13
6. Manageability Considerations ...................................13
6.1. Control of Function and Policy ............................13
6.2. Information and Data Models ...............................14
6.3. Liveness Detection and Monitoring .........................14
6.4. Verifying Correct Operation ...............................14
6.5. Requirements on Other Protocols and Functional
Components ................................................14
6.6. Impact on Network Operation ...............................15
6.7. Other Considerations ......................................15
7. Security Considerations ........................................15
8. Acknowledgements ...............................................16
9. References .....................................................16
9.1. Normative References ......................................16
9.2. Informative References ....................................17
10. Contributors' Addresses .......................................17
Multiprotocol Label Switching Traffic Engineering (MPLS-TE) to Generalized MPLS (GMPLS) migration is the process of evolving an MPLS-TE-based control plane to a GMPLS-based control plane. The network under consideration for migration is, therefore, a packet-switching network.
マルチプロトコルラベルスイッチングトラフィックエンジニアリング（MPLS-TE）一般化MPLS（GMPLS）への移行への移行は、MPLSベースのコントロールプレーンをGMPLSベースのコントロールプレーンに進化させるプロセスです。したがって、移行を検討しているネットワークは、パケットスイッチングネットワークです。
There are several motivations for such migration, mainly the desire to take advantage of new features and functions added to the GMPLS protocols, which are not present in MPLS-TE for packet networks. Additionally, before migrating a packet-switching network from MPLS-TE to GMPLS, one may choose to first migrate a lower-layer network with no control plane (e.g., controlled by a management plane) to using a GMPLS control plane. This may lead to the desire for MPLS-TE/GMPLS (transport network) interworking to provide enhanced TE support and facilitate the later migration of the packet-switching network.
このような移行にはいくつかの動機があります。主に、パケットネットワーク用にMPLS-TEには存在しないGMPLSプロトコルに追加された新機能と機能を利用したいという願望です。さらに、Packet-SwitchingネットワークをMPLS-TEからGMPLSに移行する前に、最初にGMPLSコントロールプレーンを使用してコントロールプレーン（たとえば、管理プレーンによって制御される）を使用して下層ネットワークを移行することを選択できます。これにより、MPLS-TE/GMPLS（Transport Network）インターワーキングが強化されたTEサポートを提供し、パケットスイッチングネットワークのその後の移行を促進するための欲求につながる可能性があります。
Although an appropriate migration strategy will be selected based on various factors including the service provider's network deployment plan, customer demand, deployed network equipments, operational policy, etc., the transition mechanisms used should also provide consistent operation of newly introduced GMPLS networks, while minimizing the impact on the operation of existing MPLS-TE networks.
適切な移行戦略は、サービスプロバイダーのネットワーク展開計画、顧客需要、展開ネットワーク機器、運用ポリシーなどを含むさまざまな要因に基づいて選択されますが、使用される移行メカニズムは、新しく導入されたGMPLSネットワークの一貫した動作を提供する必要があります。既存のMPLS-TEネットワークの動作への影響。
This document describes several migration strategies and the interworking scenarios that arise during migration. It also examines the implications for network deployments and for protocol usage. As the GMPLS signaling and routing protocols are different from the MPLS-TE control protocols, interworking mechanisms between MPLS-TE and GMPLS networks, or network elements, may be needed to compensate for the differences.
このドキュメントでは、いくつかの移行戦略と、移行中に発生するインターワーキングシナリオについて説明します。また、ネットワークの展開とプロトコルの使用に対する影響も調べます。GMPLSシグナリングおよびルーティングプロトコルはMPLS-TEコントロールプロトコルとは異なるため、MPLS-TEとGMPLSネットワークの間のインターワーキングメカニズム、またはネットワーク要素が必要になる場合があります。
Note that MPLS-TE and GMPLS protocols can coexist as "ships in the night" without any interworking issues.
MPLS-TEおよびGMPLSプロトコルは、インターワーキングの問題なしに「夜間の船」として共存できることに注意してください。
This is not a requirements document, nevertheless 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] in order to clarify the recommendations that are made.
これは要件ドキュメントではなく、キーワード「必須」、「必須」、「必須」、「しなければ」、「そうしない」、「そうではない」、「必要はない」、「推奨」、「5月」、このドキュメントの「オプション」は、行われた推奨事項を明確にするために、RFC 2119 [RFC2119]に記載されているように解釈されます。
In the rest of this document, the term "GMPLS" includes both packet switching capable (PSC) and non-PSC. Otherwise, the term "PSC GMPLS" or "non-PSC GMPLS" is used explicitly.
このドキュメントの残りの部分では、「GMPLS」という用語には、パケットスイッチング可能（PSC）と非PSCの両方が含まれます。それ以外の場合、「PSC GMPLS」または「非PSC Gmpls」という用語が明示的に使用されます。
In general, the term "MPLS" is used to indicate MPLS traffic engineering (MPLS-TE) only ([RFC3209], [RFC3630], and [RFC3784]) and excludes other MPLS protocols, such as the Label Distribution Protocol (LDP). TE functionalities of MPLS could be migrated to GMPLS, but non-TE functionalities could not. If non-TE MPLS is intended, it is indicated explicitly.
一般に、「MPLS」という用語は、MPLSトラフィックエンジニアリング（MPLS-TE）のみを示すために使用されます（[RFC3209]、[RFC3630]、[RFC3784]）、ラベル分布プロトコル（LDP）などの他のMPLSプロトコルを除外します。。MPLSのTE機能はGMPLSに移行する可能性がありますが、非TTE機能はできませんでした。非TEMPLSが意図されている場合、それは明示的に示されています。
The reader is assumed to be familiar with the terminology introduced in [RFC3945].
読者は、[RFC3945]で導入された用語に精通していると想定されています。
Motivations for migration will vary for different service providers. This section is presented to provide background so that the migration discussions may be seen in context. Sections 4 and 5 provide examples to illustrate the migration models and processes.
移行の動機は、サービスプロバイダーによって異なります。このセクションは、移行の議論が文脈で見られるように背景を提供するために提示されます。セクション4および5では、移行モデルとプロセスを説明する例を示します。
Migration of an MPLS-capable Label Switching Router (LSR) to include GMPLS capabilities may be performed for one or more reasons, including, not exhaustively:
GMPLS機能を含めるためのMPLS対応ラベルスイッチングルーター（LSR）の移行は、1つ以上の理由で実行される場合があります。
o To add all GMPLS PSC features to an existing MPLS network (upgrade MPLS LSRs).
o すべてのGMPLS PSC機能を既存のMPLSネットワーク（MPLS LSRSのアップグレード）に追加する。
o To add specific GMPLS PSC features and operate them within an MPLS network (e.g., [RFC4872] and [RFC4873]).
o 特定のGMPLS機能を追加し、MPLSネットワーク内で操作します（例：[RFC4872]および[RFC4873]）。
o To integrate a new GMPLS PSC network with an existing MPLS network (without upgrading any of the MPLS LSRs).
o 新しいGMPLS PSCネットワークを既存のMPLSネットワークと統合する（MPLS LSRをアップグレードせずに）。
o To allow existing MPLS LSRs to interoperate with new non-MPLS LSRs supporting only GMPLS PSC and/or non-PSC features.
o 既存のMPLS LSRがGMPLS PSCおよび/または非PSC機能のみをサポートする新しい非MPLS LSRと相互運用できるようにするため。
o To integrate multiple control networks, e.g., managed by separate administrative organizations, and which independently utilize MPLS or GMPLS.
o たとえば、個別の管理組織が管理する複数の制御ネットワークを統合し、MPLSまたはGMPLを独立して利用します。
o To build integrated PSC and non-PSC networks. The non-PSC networks are controlled by GMPLS.
o 統合されたPSCおよび非PSCネットワークを構築します。非PSCネットワークはGMPLSによって制御されます。
The objective of migration from MPLS to GMPLS is that all LSRs, and the entire network, support GMPLS protocols. During this process, various interim situations may exist, giving rise to the interworking situations described in this document. The interim situations may exist for considerable periods of time, but the ultimate objective is not to preserve these situations. For the purposes of this document, they should be considered as temporary and transitory.
MPLSからGMPLSへの移行の目的は、すべてのLSRとネットワーク全体がGMPLSプロトコルをサポートすることです。このプロセス中に、さまざまな暫定的な状況が存在する可能性があり、このドキュメントで説明されているインターワーキング状況を生み出します。暫定的な状況はかなりの期間存在する可能性がありますが、究極の目的はこれらの状況を維持することではありません。この文書の目的のために、それらは一時的かつ一時的なものと見なされるべきです。
Three reference migration models are described below. Multiple migration models may coexist in the same network.
3つの参照移行モデルを以下に説明します。複数の移行モデルは、同じネットワークに共存する場合があります。
In the island model, "islands" of network nodes operating one protocol exist within a "sea" of nodes using the other protocol.
島のモデルでは、1つのプロトコルを動作させるネットワークノードの「島」は、他のプロトコルを使用してノードの「SEA」内に存在します。
For example, consider an island of GMPLS-capable nodes (PSC) that is introduced into a legacy MPLS network. Such an island might be composed of newly added GMPLS nodes, or it might arise from the upgrade of existing nodes that previously operated MPLS protocols.
たとえば、レガシーMPLSネットワークに導入されたGMPLS対応ノードの島（PSC）を検討してください。このような島は、新しく追加されたGMPLSノードで構成されている可能性があり、以前にMPLSプロトコルを操作した既存のノードのアップグレードから生じる可能性があります。
The opposite is also quite possible. That is, there is a possibility that an island happens to be MPLS-capable within a GMPLS sea. Such a situation might arise in the later stages of migration, when all but a few islands of MPLS-capable nodes have been upgraded to GMPLS.
逆も非常に可能です。つまり、島がたまたまGMPLS海でMPLS対応になる可能性があります。このような状況は、MPLS対応ノードのいくつかの島を除くすべてがGMPLSにアップグレードされた場合に、移動の後期段階で発生する可能性があります。
It is also possible that a lower-layer, manually-provisioned network (for example, a Time Division Multiplexing (TDM) network) is constructed under an MPLS PSC network. During the process of migrating both networks to GMPLS, the lower-layer network might be migrated first. This would appear as a GMPLS island within an MPLS sea.
また、MPLS PSCネットワークの下に、低層の手動でプロビジョニングされたネットワーク（たとえば、タイムディビジョンマルチプレックス（TDM）ネットワーク）が構築される可能性もあります。両方のネットワークをGMPLに移行する過程で、低層ネットワークが最初に移行される可能性があります。これは、MPLS海の中のGMPLS島として表示されます。
Lastly, it is possible to consider individual nodes as islands. That is, it would be possible to upgrade or insert an individual GMPLS-capable node within an MPLS network, and to treat that GMPLS node as an island.
最後に、個々のノードを島と見なすことができます。つまり、MPLSネットワーク内に個々のGMPLS対応ノードをアップグレードまたは挿入し、そのGMPLSノードを島として扱うことが可能です。
Over time, collections of MPLS devices are replaced or upgraded to create new GMPLS islands or to extend existing ones, and distinct GMPLS islands may be joined together until the whole network is GMPLS-capable.
時間が経つにつれて、MPLSデバイスのコレクションが交換またはアップグレードされて新しいGMPLS島を作成したり、既存の島を拡張したりします。ネットワーク全体がGMPLS対応になるまで、個別のGMPLS島を結合できます。
From a migration/interworking point of view, we need to examine how these islands are positioned and how Label Switched Paths (LSPs) connect between the islands.
移行/協力の観点からは、これらの島がどのように配置されているか、ラベルの切り替えパス（LSP）が島間でどのようにつながるかを調べる必要があります。
Four categories of interworking scenarios are considered: (1) MPLS-GMPLS-MPLS, (2) GMPLS-MPLS-GMPLS, (3) MPLS-GMPLS, and (4) GMPLS-MPLS. In case 1, the interworking behavior is examined based on whether the GMPLS islands are PSC or non-PSC.
インターワーキングシナリオの4つのカテゴリが考慮されます。（1）MPLS-GMPLS-MPLS、（2）GMPLS-MPLS-GMPLS、（3）MPLS-GMPLS、および（4）GMPLS-MPLS。ケース1では、GMPLS島がPSCまたは非PSCであるかどうかに基づいて、インターワーキング動作を調べます。
Figure 1 shows an example of the island model for MPLS-GMPLS-MPLS interworking. The model consists of a transit GMPLS island in an MPLS sea. The nodes at the boundary of the GMPLS island (G1, G2, G5, and G6) are referred to as "island border nodes". If the GMPLS island was non-PSC, all nodes except the island border nodes in the GMPLS-based transit island (G3 and G4) would be non-PSC devices, i.e., optical equipment (TDM, Lambda Switch Capable (LSC), and Fiber Switch Capable (FSC)).
図1は、MPLS-GMPLS-MPLSインターワーキングの島モデルの例を示しています。このモデルは、MPLS海の輸送GMPLS島で構成されています。GMPLS島（G1、G2、G5、およびG6）の境界にあるノードは、「島の境界ノード」と呼ばれます。GMPLS島が非PSCである場合、GMPLSベースのトランジットアイランド（G3およびG4）の島の境界ノードを除くすべてのノードは、非PSCデバイス、つまり光学機器（TDM、Lambdaスイッチが能力（LSC）、およびファイバースイッチ対応（FSC））。
................. .......................... ..................
: MPLS : : GMPLS : : MPLS :
:+---+ +---+ +----+ +---+ +----+ +---+ +---+:
:|R1 |__|R11|___| G1 |_________|G3 |________| G5 |___|R31|__|R3 |:
:+---+ +---+ +----+ +-+-+ +----+ +---+ +---+:
: ________/ : : _______/ | _____ / : : ________/ :
: / : : / | / : : / :
:+---+ +---+ +----+ +-+-+ +----+ +---+ +---+:
:|R2 |__|R21|___| G2 |_________|G4 |________| G6 |___|R41|__|R4 |:
:+---+ +---+ +----+ +---+ +----+ +---+ +---+:
:................: :........................: :................:
|<-------------------------------------------------------->|
e2e LSP
Figure 1: Example of the island model for MPLS-GMPLS-MPLS interworking
図1：MPLS-GMPLS-MPLSインターワーキングの島モデルの例
In the MPLS-GMPLS-MPLS and GMPLS-MPLS-GMPLS cases, LSPs start and end using the same protocols. Possible strategies include:
MPLS-GMPLS-MPLSおよびGMPLS-MPLS-GMPLSの場合、LSPは同じプロトコルを使用して開始および終了します。可能な戦略は次のとおりです。
- tunneling the signaling across the island network using LSP nesting or stitching [RFC5150] (the latter is only for GMPLS-PSC)
- LSPネスティングまたはステッチを使用して島ネットワークを横断するシグナリングをトンネル[RFC5150]（後者はGMPLS-PSCのみです）
- protocol interworking or mapping (both are only for GMPLS-PSC)
- プロトコルインターワーキングまたはマッピング（両方ともGMPLS-PSCのみです）
As previously discussed, there are two island interworking models that support bordering islands. GMPLS(PSC)-MPLS and MPLS-GMPLS(PSC) island cases are likely to arise where the migration strategy is not based on a core infrastructure, but has edge nodes (ingress or egress) located in islands of different capabilities.
前述のように、境界線をサポートする2つの島の交流モデルがあります。GMPLS（PSC）-MPLSおよびMPLS-GMPLS（PSC）島のケースは、移行戦略がコアインフラストラクチャに基づいていないが、異なる機能の島にあるエッジノード（イングレスまたは出口）を備えている場合に発生する可能性があります。
In this case, an LSP starts or ends in a GMPLS (PSC) island and correspondingly ends or starts in an MPLS island. This mode of operation can only be addressed using protocol interworking or mapping. Figure 2 shows the reference model for this migration scenario. Head-end and tail-end LSRs are in distinct control plane clouds.
この場合、LSPはGMPLS（PSC）島で開始または終了し、それに応じてMPLS島で終了または開始します。この動作モードは、プロトコルインターワーキングまたはマッピングを使用してのみ対処できます。図2は、この移行シナリオの参照モデルを示しています。ヘッドエンドとテールエンドのLSRは、明確な制御プレーン雲にあります。
............................ .............................
: MPLS : : GMPLS (PSC) :
:+---+ +---+ +----+ +---+ +---+:
:|R1 |________|R11|_______| G1 |________|G3 |________|G5 |:
:+---+ +---+ +----+ +-+-+ +---+:
: ______/ | _____/ : : ______/ | ______/ :
: / | / : : / | / :
:+---+ +---+ +----+ +-+-+ +---+:
:|R2 |________|R21|_______| G2 |________|G4 |________|G6 |:
:+---+ +---+ +----+ +---+ +---+:
:..........................: :...........................:
|<-------------------------------------------------->|
e2e LSP
Figure 2: GMPLS-MPLS interworking model
図2：GMPLS-MPLSインターワーキングモデル
It is important to underline that this scenario is also impacted by the directionality of the LSP, and the direction in which the LSP is established.
このシナリオは、LSPの方向性とLSPが確立される方向にも影響を与えることを強調することが重要です。
The second migration model involves a more integrated migration strategy. New devices that are capable of operating both MPLS and GMPLS protocols are introduced into the MPLS network.
2番目の移行モデルには、より統合された移行戦略が含まれます。MPLSとGMPLSプロトコルの両方を操作できる新しいデバイスは、MPLSネットワークに導入されます。
In the integrated model, there are two types of nodes present during migration:
統合モデルには、移行中に2種類のノードが存在します。
- those that support MPLS only (legacy nodes); and
- MPLSのみをサポートするもの（レガシーノード）;と
- those that support MPLS and GMPLS.
- MPLSおよびGMPLSをサポートするもの。
In this model, as existing MPLS devices are upgraded to support both MPLS and GMPLS, the network continues to operate with an MPLS control plane, but some LSRs are also capable of operating with a GMPLS control plane. So, LSPs are provisioned using MPLS protocols where one end point of a service is a legacy MPLS node and/or where the selected path between end points traverses a legacy node that is not GMPLS-capable. But where the service can be provided using only GMPLS-capable nodes [RFC5073], it may be routed accordingly and can achieve a higher level of functionality by utilizing GMPLS features.
このモデルでは、既存のMPLSデバイスがMPLSとGMPLの両方をサポートするようにアップグレードされるため、ネットワークはMPLSコントロールプレーンで動作し続けますが、一部のLSRはGMPLSコントロールプレーンで動作することもできます。したがって、LSPはMPLSプロトコルを使用してプロビジョニングされます。ここでは、サービスの1つのエンドポイントがレガシーMPLSノードであるか、および/またはエンドポイント間の選択されたパスがGMPLS対応ではないレガシーノードを通過する場合です。ただし、GMPLS対応ノードのみを使用してサービスを提供できる場合[RFC5073]、それに応じてルーティングされ、GMPLS機能を利用することでより高いレベルの機能を達成できます。
Once all devices in the network are GMPLS-capable, the MPLS-specific protocol elements may be turned off, and no new devices need to support these protocol elements.
ネットワーク内のすべてのデバイスがGMPLS対応になると、MPLS固有のプロトコル要素がオフになる可能性があり、これらのプロトコル要素をサポートする新しいデバイスは必要ありません。
In this model, the questions to be addressed concern the coexistence of the two protocol sets within the network. Actual interworking is not a concern.
このモデルでは、対処すべき質問は、ネットワーク内の2つのプロトコルセットの共存に関係しています。実際のインターワーキングは心配ではありません。
The phased model introduces GMPLS features and protocol elements into an MPLS network one by one. For example, some objects or sub-objects (such as the Explicit Route Object (ERO) label sub-object, [RFC3473]) might be introduced into the signaling used by LSRs that are otherwise MPLS-capable. This would produce a kind of hybrid LSR.
フェーズドモデルは、GMPLS機能とプロトコル要素をMPLSネットワークに1つずつ導入します。たとえば、一部のオブジェクトまたはサブオブジェクト（明示的ルートオブジェクト（ERO）ラベルサブオブジェクト、[RFC3473]など）は、MPLS対応のLSRが使用するシグナルに導入される場合があります。これにより、一種のハイブリッドLSRが生成されます。
This approach may appear simpler to implement as one is able to quickly and easily pick up new key functions without needing to upgrade the whole protocol implementation. It is most likely to be used where there is a desire to rapidly implement a particular function within a network without the necessity to install and test the full GMPLS function.
このアプローチは、プロトコルの実装全体をアップグレードする必要なく、新しいキー関数をすばやく簡単にピックアップできるため、実装する方が簡単に見える場合があります。完全なGMPLS関数をインストールおよびテストする必要なく、ネットワーク内で特定の機能を迅速に実装したい場合に使用される可能性が最も高くなります。
Interoperability concerns though are exacerbated by this migration model, unless all LSRs in the network are updated simultaneously and there is a clear understanding of which subset of features are to be included in the hybrid LSRs. Interworking between a hybrid LSR and an unchanged MPLS LSR would put the hybrid LSR in the role of a GMPLS LSR, as described in the previous sections, and puts the unchanged LSR in the role of an MPLS LSR. The potential for different hybrids within the network will complicate matters considerably. This model is, therefore, only appropriate for use when the set of new features to be deployed is well known and limited, and where there is a clear understanding of and agreement on this set of features by the network operators of the ISP(s) involved as well as all vendors whose equipment will be involved in the migration.
ただし、ネットワーク内のすべてのLSRが同時に更新され、ハイブリッドLSRに含まれる機能のサブセットを明確に理解していない限り、この移行モデルによって相互運用性の懸念が悪化します。ハイブリッドLSRと変更されていないMPLS LSRとの間のインターワーキングは、前のセクションで説明されているように、ハイブリッドLSRをGMPLS LSRの役割に導き、MPLS LSRの役割に変更されていないLSRを置きます。ネットワーク内のさまざまなハイブリッドの可能性は、問題を大幅に複雑にします。したがって、このモデルは、展開する一連の新機能がよく知られており、限られている場合にのみ使用するのに適しており、ISPのネットワーク演算子によるこの一連の機能について明確な理解と合意がある場合関与するだけでなく、機器が移行に関与するすべてのベンダーも関与しています。
An appropriate migration strategy is selected by a network operator based on factors including the service provider's network deployment plan, customer demand, existing network equipment, operational policy, support from its vendors, etc.
適切な移行戦略は、サービスプロバイダーのネットワーク展開計画、顧客需要、既存のネットワーク機器、運用ポリシー、ベンダーからのサポートなどの要因に基づいて、ネットワークオペレーターによって選択されます。
For PSC networks, the migration strategy involves the selection between the models described in the previous section. The choice will depend upon the final objective (full GMPLS capability, partial upgrade to include specific GMPLS features, or no change to existing IP/MPLS networks), and upon the immediate objectives (full, phased, or staged upgrade).
PSCネットワークの場合、移行戦略には、前のセクションで説明したモデル間の選択が含まれます。選択は、最終目標（完全なGMPLS機能、特定のGMPLS機能を含めるための部分的なアップグレード、または既存のIP/MPLSネットワークに変更なし）、および当面の目標（完全、段階的、または段階的なアップグレード）に依存します。
For PSC networks serviced by non-PSC networks, two basic migration strategies can be considered. In the first strategy, the non-PSC network is made GMPLS-capable, first, and then the PSC network is migrated to GMPLS. This might arise when, in order to expand the network capacity, GMPLS-based non-PSC sub-networks are introduced into the legacy MPLS-based networks. Subsequently, the legacy MPLS-based PSC network is migrated to be GMPLS-capable, as described in the previous paragraph. Finally, the entire network, including both PSC and non-PSC nodes, may be controlled by GMPLS.
非PSCネットワークがサービスを提供するPSCネットワークの場合、2つの基本的な移行戦略を考慮することができます。最初の戦略では、非PSCネットワークは最初にGMPLS対応になり、次にPSCネットワークがGMPLSに移行されます。これは、ネットワーク容量を拡大するために、GMPLSベースの非PSCサブネットワークがレガシーMPLSベースのネットワークに導入されると発生する可能性があります。その後、前の段落で説明されているように、レガシーMPLSベースのPSCネットワークはGMPLS対応に移行されます。最後に、PSCノードと非PSCノードの両方を含むネットワーク全体がGMPLSによって制御される場合があります。
The second strategy is to migrate the PSC network to GMPLS first, and then enable GMPLS within the non-PSC network. The PSC network is migrated as described before, and when the entire PSC network is completely converted to GMPLS, GMPLS-based non-PSC devices and networks may be introduced without any issues of interworking between MPLS and GMPLS.
2番目の戦略は、最初にPSCネットワークをGMPLSに移行し、次に非PSCネットワーク内でGMPLSを有効にすることです。PSCネットワークは前述のように移行され、PSCネットワーク全体がGMPLSに完全に変換されると、GMPLSベースの非PSCデバイスとネットワークがMPLSとGMPLのインターワーキングの問題なく導入される場合があります。
These migration strategies and the migration models described in the previous section are not necessarily mutually exclusive. Mixtures of all strategies and models could be applied. The migration models and strategies selected will give rise to one or more of the interworking cases described in the following section.
これらの移行戦略と前のセクションで説明した移行モデルは、必ずしも相互に排他的ではありません。すべての戦略とモデルの混合を適用できます。選択された移行モデルと戦略は、次のセクションで説明されている1つまたは複数のインターワーキングケースを生じさせます。
As described in the previous sections, an essential part of a migration and deployment strategy is how the MPLS and GMPLS or hybrid LSRs interwork. This section sets out some of the alternatives for achieving interworking between MPLS and GMPLS, and it identifies some of the issues that need to be addressed. This document does not describe solutions to these issues.
前のセクションで説明したように、移行および展開戦略の重要な部分は、MPLSおよびGMPLSまたはハイブリッドLSRSインターワークの方法です。このセクションでは、MPLSとGMPLの間でインターワーキングを達成するための代替案の一部を説明し、対処する必要がある問題の一部を特定します。このドキュメントでは、これらの問題の解決策は説明されていません。
Note that it is possible to consider upgrading the routing and signaling capabilities of LSRs from MPLS to GMPLS separately.
MPLSからGMPLSへのLSRのルーティングおよびシグナル伝達機能のアップグレードを個別にアップグレードすることを検討することが可能であることに注意してください。
In the balanced island model, LSP tunnels [RFC4206] are a solution to carry the end-to-end LSPs across islands of incompatible nodes. Network layering is often used to separate domains of different data plane technology. It can also be used to separate domains of different control plane technology (such as MPLS and GMPLS protocols), and the solutions developed for multiple data plane technologies can be usefully applied to this situation [RFC3945], [RFC4206], and [RFC4726]. [MLN-REQ] gives a discussion of the requirements for multi-layered networks.
バランスの取れた島モデルでは、LSPトンネル[RFC4206]は、互換性のないノードの島全体にエンドツーエンドのLSPを運ぶソリューションです。ネットワークレイヤーは、さまざまなデータプレーンテクノロジーのドメインを分離するためによく使用されます。また、さまざまなコントロールプレーンテクノロジー（MPLSやGMPLSプロトコルなど）のドメインを分離するためにも使用でき、複数のデータプレーンテクノロジー用に開発されたソリューションは、この状況[RFC3945]、[RFC4206]、および[RFC4726]に有用に適用できます。。[MLN-REQ]は、多層ネットワークの要件について説明しています。
The GMPLS architecture [RFC3945] identifies three architectural models for supporting multi-layer GMPLS networks, and these models may be applied to the separation of MPLS and GMPLS control plane islands.
GMPLSアーキテクチャ[RFC3945]は、多層GMPLSネットワークをサポートするための3つのアーキテクチャモデルを識別し、これらのモデルはMPLSおよびGMPLSコントロールプレーン島の分離に適用される場合があります。
- In the peer model, both MPLS and GMPLS nodes run the same routing instance, and routing advertisements from within islands of one level of protocol support are distributed to the whole network. This is achievable only, as described in Section 5.1.2, either by direct distribution or by mapping of parameters.
- ピアモデルでは、MPLSノードとGMPLSノードの両方が同じルーティングインスタンスを実行し、プロトコルサポートの1つのレベルの島からのルーティング広告がネットワーク全体に配布されます。これは、直接分布またはパラメーターのマッピングによって、セクション5.1.2で説明されているように、実現可能です。
Signaling in the peer model may result in contiguous LSPs, stitched LSPs [RFC5150] (only for GMPLS PSC), or nested LSPs. If the network islands are non-PSC, then the techniques of [MLN-REQ] may be applied, and these techniques may be extrapolated to networks where all nodes are PSC, but where there is a difference in signaling protocols.
ピアモデルでのシグナル伝達は、連続したLSP、ステッチされたLSP [RFC5150]（GMPLS PSCのみ）、またはネストされたLSPをもたらす可能性があります。ネットワーク島が非PSCである場合、[MLN-REQ]の手法が適用される場合があり、これらの手法は、すべてのノードがPSCであるネットワークに外挿する場合がありますが、シグナル伝達プロトコルに違いがあります。
- The overlay model preserves strict separation of routing information between network layers. This is suitable for the balanced island model, and there is no requirement to handle routing interworking. Even though the overlay model preserves separation of signaling information between network layers, there may be some interaction in signaling between network layers.
- オーバーレイモデルは、ネットワークレイヤー間のルーティング情報の厳密な分離を保持します。これは、バランスの取れた島モデルに適しており、ルーティングインターワーキングを処理するための要件はありません。オーバーレイモデルは、ネットワークレイヤー間のシグナリング情報の分離を保持していますが、ネットワークレイヤー間のシグナリングにはある程度の相互作用があるかもしれません。
The overlay model requires the establishment of control plane connectivity for the higher layer across the lower layer.
オーバーレイモデルには、下層を横切るより高い層のコントロールプレーン接続を確立する必要があります。
- The augmented model allows limited routing exchange from the lower-layer network to the higher-layer network. Generally speaking, this assumes that the border nodes provide some form of filtering, mapping, or aggregation of routing information advertised from the lower-layer network. This architectural model can also be used for balanced island model migrations. Signaling interworking is required as described for the peer model.
- 拡張モデルにより、低層ネットワークから高層ネットワークへの限られたルーティング交換が可能になります。一般的に言えば、これは、ボーダーノードが、下層ネットワークから宣伝されているルーティング情報の何らかの形のフィルタリング、マッピング、または集約を提供することを前提としています。このアーキテクチャモデルは、バランスの取れた島モデルの移動にも使用できます。ピアモデルについて説明されているように、シグナリングインターワーキングが必要です。
- The border peer architecture model is defined in [RFC5146]. This is a modification of the augmented model where the layer border routers have visibility into both layers, but no routing information is otherwise exchanged between routing protocol instances. This architectural model is particularly suited to the MPLS-GMPLS-MPLS island model for PSC and non-PSC GMPLS islands. Signaling interworking is required as described for the peer model.
- ボーダーピアアーキテクチャモデルは[RFC5146]で定義されています。これは、レイヤーボーダールーターが両方のレイヤーに可視性を持つ拡張モデルの変更ですが、それ以外の場合はルーティングプロトコルインスタンス間でルーティング情報が交換されません。このアーキテクチャモデルは、PSCおよび非PSC GMPLS島のMPLS-GMPLS-MPLS島モデルに特に適しています。ピアモデルについて説明されているように、シグナリングインターワーキングが必要です。
Migration strategies may necessitate some interworking between MPLS and GMPLS routing protocols. GMPLS extends the TE information advertised by the IGPs to include non-PSC information and extended PSC information. Because the GMPLS information is provided as additional TLVs that are carried along with the MPLS information, MPLS LSRs are able to "see" all GMPLS LSRs as though they were MPLS PSC LSRs. They will also see other GMPLS information, but will ignore it, flooding it transparently across the MPLS network for use by other GMPLS LSRs.
移行戦略により、MPLSとGMPLSルーティングプロトコルの間の相互作用が必要になる場合があります。GMPLSは、IGPSによって宣伝されているTE情報を拡張して、非PSC情報と拡張PSC情報を含めます。GMPLS情報はMPLS情報とともに携帯される追加のTLVとして提供されるため、MPLS LSRは、MPLS PSC LSRであるかのようにすべてのGMPLS LSRを「表示」することができます。また、他のGMPLS情報も表示されますが、それを無視し、他のGMPLS LSRSが使用するためにMPLSネットワーク全体に透過的にあふれます。
- Routing separation is achieved in the overlay and border peer models. This is convenient since only the border nodes need to be aware of the different protocol variants, and no mapping is required. It is suitable to the MPLS-GMPLS-MPLS and GMPLS-MPLS-GMPLS island migration models.
- オーバーレイおよびボーダーピアモデルでは、ルーティング分離が実現されます。これは、境界線ノードのみが異なるプロトコルバリアントを認識する必要があり、マッピングが必要ないため、便利です。MPLS-GMPLS-MPLSおよびGMPLS-MPLS-GMPLS Island Migrationモデルに適しています。
- Direct distribution involves the flooding of MPLS routing information into a GMPLS network, and GMPLS routing information into an MPLS network. The border nodes make no attempt to filter the information. This mode of operation relies on the fact that MPLS routers will ignore, but continue to flood, GMPLS routing information that they do not understand. The presence of additional GMPLS routing information will not interfere with the way that MPLS LSRs select routes. Although this is not a problem in a PSC-only network, it could cause problems in a peer architecture network that includes non-PSC nodes, as the MPLS nodes are not capable of determining the switching types of the other LSRs and will attempt to signal end-to-end LSPs assuming all LSRs to be PSC. This fact would require island border nodes to take triggered action to set up tunnels across islands of different switching capabilities.
- 直接分布には、MPLSルーティング情報のGMPLSネットワークへの洪水と、情報情報をMPLSネットワークにルーティングすることが含まれます。ボーダーノードは、情報をフィルタリングしようとはしません。この動作モードは、MPLSルーターが無視するという事実に依存しています。追加のGMPLSルーティング情報の存在は、MPLS LSRがルートを選択する方法を妨げません。これはPSCのみのネットワークでは問題ではありませんが、MPLSノードは他のLSRのスイッチングタイプを決定できず、シグナルを試みるため、非PSCノードを含むピアアーキテクチャネットワークに問題を引き起こす可能性があります。すべてのLSRがPSCであると仮定したエンドツーエンドLSP。この事実には、島の境界ノードが、さまざまなスイッチング機能の島にトンネルを設置するためにトリガーされたアクションを実行する必要があります。
GMPLS LSRs might be impacted by the absence of GMPLS-specific information in advertisements initiated by MPLS LSRs. Specific procedures might be required to ensure consistent behavior by GMPLS nodes. If this issue is addressed, then direct distribution can be used in all migration models (except the overlay and border peer architectural models where the problem does not arise).
GMPLS LSRは、MPLS LSRSによって開始された広告にGMPLS固有の情報がないことにより影響を受ける可能性があります。GMPLSノードによる一貫した動作を確保するために、特定の手順が必要になる場合があります。この問題に対処すると、すべての移行モデル（問題が発生しないオーバーレイおよびボーダーピアアーキテクチャモデルを除く）で直接分布を使用できます。
- Protocol mapping converts routing advertisements so that they can be received in one protocol and transmitted in the other. For example, a GMPLS routing advertisement could have all of its GMPLS-specific information removed and could be flooded as an MPLS advertisement. This mode of interworking would require careful standardization of the correct behavior especially where an MPLS advertisement requires default values of GMPLS-specific fields to be generated before the advertisement can be flooded further. There is also considerable risk of confusion in closely meshed networks where many LSRs have MPLS- and GMPLS-capable interfaces. This option for routing interworking during migration is NOT RECOMMENDED for any migration model. Note that converting GMPLS-specific sub-TLVs to MPLS-specific ones but not stripping the GMPLS-specific ones is considered a variant of the proposed solution in the previous bullet (unknown sub-TLVs should be ignored [RFC3630] but must continue to be flooded).
- プロトコルマッピングは、ルーティング広告を変換して、1つのプロトコルで受信して他のプロトコルで送信できるようにします。たとえば、GMPLSルーティング広告は、すべてのGMPLS固有の情報を削除し、MPLS広告として浸水する可能性があります。このインターワーキングモードでは、特にMPLS広告が広告をさらに浸水させる前にGMPLS固有のフィールドのデフォルト値を生成する必要がある場合、正しい動作の慎重な標準化が必要です。また、多くのLSRにMPLSおよびGMPLS対応インターフェイスがある密接にメッシュ化されたネットワークには、混乱のリスクもかなりあります。移行中のインターワーキングをルーティングするためのこのオプションは、移行モデルには推奨されません。GMPLS固有のサブTLVをMPLS固有のものに変換するが、GMPLS固有のものをストリップしないことは、以前の弾丸で提案されたソリューションのバリアントと見なされることに注意してください（未知のサブTLVは無視する必要があります[RFC3630]浸水）。
- Ships in the night refers to a mode of operation where both MPLS and GMPLS routing protocol variants are operated in the same network at the same time as separate routing protocol instances. The two instances are independent and are used to create routing adjacencies between LSRs of the same type. This mode of operation may be appropriate to the integrated migration model.
- 夜の船は、MPLSとGMPLSルーティングプロトコルの両方のプロトコルバリエーションが、個別のルーティングプロトコルインスタンスと同時に同じネットワークで動作する動作モードを指します。2つのインスタンスは独立しており、同じタイプのLSR間にルーティング隣接を作成するために使用されます。この動作モードは、統合された移行モデルに適している場合があります。
Signaling protocols are used to establish LSPs and are the principal concern for interworking during migration. Issues of compatibility arise because of differences in the encodings and codepoints used by MPLS and GMPLS signaling, but also because of differences in functionality provided by MPLS and GMPLS.
シグナル伝達プロトコルは、LSPを確立するために使用され、移行中のインターワーキングの主な関心事です。互換性の問題は、MPLSおよびGMPLSシグナル伝達によって使用されるエンコーディングとコードポイントの違いによって発生しますが、MPLSおよびGMPLによって提供される機能の違いによっても発生します。
- Tunneling and stitching [RFC5150] (GMPLS-PSC case) mechanisms provide the potential to avoid direct protocol interworking during migration in the island model because protocol elements are transported transparently across migration islands without being inspected. However, care may be needed to achieve functional mapping in these modes of operation since one set of features may need to be supported across a network designed to support a different set of features. In general, this is easily achieved for the MPLS-GMPLS-MPLS model, but may be hard to achieve in the GMPLS-MPLS-GMPLS model, for example, when end-to-end bidirectional LSPs are requested, since the MPLS island does not support bidirectional LSPs.
- トンネルとステッチの[RFC5150]（GMPLS-PSCケース）メカニズムは、プロトコル要素が検査されずに移動島を越えて透過的に輸送されるため、島モデルでの移動中の直接プロトコルインターワーキングを回避する可能性を提供します。ただし、さまざまな機能をサポートするように設計されたネットワーク全体で1つの機能をサポートする必要があるため、これらの動作モードで機能マッピングを実現するには注意が必要になる場合があります。一般に、これはMPLS-GMPLS-MPLSモデルで簡単に達成されますが、MPLS島がそうするため、エンドツーエンドの双方向LSPが要求される場合、GMPLS-MPLS-GMPLSモデルで達成するのは難しい場合があります。双方向LSPをサポートしていません。
Note that tunneling and stitching are not available in unbalanced island models because in these cases, the LSP end points use different protocols.
これらの場合、LSPエンドポイントは異なるプロトコルを使用しているため、不均衡な島モデルではトンネリングとステッチが利用できないことに注意してください。
- Protocol mapping is the conversion of signaling messages between MPLS and GMPLS. This mechanism requires careful documentation of the protocol fields and how they are mapped. This is relatively straightforward in the MPLS-GMPLS unbalanced island model for LSPs signaled in the MPLS-GMPLS direction. However, it may be more complex for LSPs signaled in the opposite direction, and this will lead to considerable complications for providing GMPLS services over the MPLS island and for terminating those services at an egress LSR that is not GMPLS-capable. Further, in balanced island models, and in particular where there are multiple small (individual node) islands, the repeated conversion of signaling parameters may lead to loss of information (and functionality) or mis-requests.
- プロトコルマッピングは、MPLSとGMPLS間のシグナリングメッセージの変換です。このメカニズムには、プロトコルフィールドの慎重な文書化とそれらのマッピング方法が必要です。これは、MPLS-GMPLS方向でシグナルがあるLSPのMPLS-GMPLSの不均衡な島モデルで比較的簡単です。ただし、反対方向に信号を送るLSPにとってはより複雑である可能性があり、これはMPLS島でGMPLSサービスを提供し、GMPLS対応ではない出力LSRでそれらのサービスを終了するためのかなりの合併症につながります。さらに、バランスの取れた島モデル、特に複数の小さな（個々のノード）島がある場合、シグナリングパラメーターの繰り返し変換は、情報（および機能性）または誤った要求の損失につながる可能性があります。
- Ships in the night could be used in the integrated migration model to allow MPLS-capable LSRs to establish LSPs using MPLS signaling protocols and GMPLS LSRs to establish LSPs using GMPLS signaling protocols. LSRs that can handle both sets of protocols could work with both types of LSRs, and no conversion of protocols would be needed.
- 夜間の船は、統合された移行モデルで使用され、MPLS対応LSRSがMPLSシグナル伝達プロトコルとGMPLS LSRを使用してLSPを確立できるようにして、GMPLSシグナル伝達プロトコルを使用してLSPを確立できます。両方のプロトコルを処理できるLSRは、両方のタイプのLSRで動作する可能性があり、プロトコルの変換は必要ありません。
The Path Computation Element (PCE) [RFC4655] may provide an additional tool to aid MPLS to GMPLS migration. If a layered network approach (Section 5.1.1) is used, PCEs may be used to facilitate the computation of paths for LSPs in the different layers [PCE-INT].
パス計算要素（PCE）[RFC4655]は、GMPLSの移行にMPLSを支援するための追加のツールを提供する場合があります。階層化されたネットワークアプローチ（セクション5.1.1）を使用すると、PCESを使用して、異なるレイヤー[PCE-INT]のLSPのパスの計算を促進することができます。
Attention should be given during migration planning to how the network will be managed during and after migration. For example, will the LSRs of different protocol capabilities be managed separately or as one management domain? For example, in the Island Model, it is possible to consider managing islands of one capability separately from the surrounding sea. In the case of islands that have different switching capabilities, it is possible that the islands already have separate management in place before the migration: the resultant migrated network may seek to merge the management or to preserve the separation.
移行計画中に、移行中および移行後にネットワークがどのように管理されるかに注意を払う必要があります。たとえば、異なるプロトコル機能のLSRは、個別にまたは1つの管理ドメインとして管理されますか？たとえば、島のモデルでは、周囲の海とは別に1つの能力の島を管理することを検討することができます。スイッチング機能が異なる島の場合、島々は移行前にすでに別々の管理を施している可能性があります。
The most critical control functionality to be applied is at the moment of changeover between different levels of protocol support. Such a change may be made without service halt or during a period of network maintenance.
適用される最も重要な制御機能は、さまざまなレベルのプロトコルサポート間の切り替えの瞬間です。このような変更は、サービスが停止せずに、またはネットワークメンテナンスの期間中に行われる場合があります。
Where island boundaries exist, it must be possible to manage the relationships between protocols and to indicate which interfaces support which protocols on a border LSR. Further, island borders are a natural place to apply policy, and management should allow configuration of such policies.
島の境界が存在する場合、プロトコル間の関係を管理し、どのインターフェイスが境界LSRのどのプロトコルをサポートするかを示すことが可能でなければなりません。さらに、島の境界線はポリシーを適用するための自然な場所であり、管理はそのようなポリシーの構成を許可する必要があります。
No special information or data models are required to support migration, but note that migration in the control plane implies migration from MPLS management tools to GMPLS management tools. During migration, therefore, it may be necessary for LSRs and management applications to support both MPLS and GMPLS management data.
移行をサポートするために特別な情報またはデータモデルは必要ありませんが、制御面での移行はMPLS管理ツールからGMPLS管理ツールへの移行を意味することに注意してください。したがって、移行中、LSRと管理アプリケーションがMPLSとGMPLS管理データの両方をサポートする必要がある場合があります。
The GMPLS MIB modules are designed to allow support of the MPLS protocols, and they are built on the MPLS MIB modules through extensions and augmentations. This may make it possible to migrate management applications ahead of the LSRs that they manage.
GMPLS MIBモジュールは、MPLSプロトコルのサポートを可能にするように設計されており、拡張および増強を通じてMPLS MIBモジュール上に構築されます。これにより、管理するLSRに先立って管理アプリケーションを移行することが可能になる可能性があります。
Migration will not impose additional issues for Operations, Administration, and Management (OAM) above those that already exist for inter-domain OAM and for OAM across multiple switching capabilities.
移行は、営業、管理、管理（OAM）の追加の問題を、ドメイン間OAMおよび複数のスイッチング機能にわたってOAMに既に存在する問題よりも課されません。
Note, however, that if a flat PSC MPLS network is migrated using the island model, and is treated as a layered network using tunnels to connect across GMPLS islands, then requirements for a multi-layer OAM technique may be introduced into what was previously defined in the flat OAM problem-space. The OAM framework of MPLS/GMPLS interworking will need further consideration.
ただし、島モデルを使用してフラットPSC MPLSネットワークが移行し、GMPLS島全体に接続するためにトンネルを使用して層状ネットワークとして扱われる場合、多層OAM技術の要件が以前に定義されたものに導入される場合があることに注意してください。フラットOAM問題空間で。MPLS/GMPLSインターワーキングのOAMフレームワークには、さらに考慮する必要があります。
The concerns for verifying correct operation (and in particular, correct connectivity) are the same as for liveness detection and monitoring. Specifically, the process of migration may introduce tunneling or stitching [RFC5150] into what was previously a flat network.
正しい操作（特に正しい接続性）を確認するための懸念は、責任の検出と監視と同じです。具体的には、移行のプロセスにより、トンネリングまたはステッチの[RFC5150]を以前のフラットネットワークに導入する場合があります。
No particular requirements are introduced on other protocols. As it has been observed, the management components may need to migrate in step with the control plane components, but this does not impact the management protocols, just the data that they carry.
他のプロトコルには特定の要件は導入されていません。観察されたように、管理コンポーネントはコントロールプレーンコンポーネントでステップで移行する必要がある場合がありますが、これは管理プロトコルに影響を与えず、それらが携帯するデータだけです。
It should also be observed that providing signaling and routing connectivity across a migration island in support of a layered architecture may require the use of protocol tunnels (such as Generic Routing Encapsulation (GRE)) between island border nodes. Such tunnels may impose additional configuration requirements at the border nodes.
また、階層化されたアーキテクチャを支援する移動島全体にシグナル伝達とルーティングの接続を提供すると、島の境界ノード間のプロトコルトンネル（一般的なルーティングカプセル化（GRE）など）の使用が必要になる場合があることが観察される必要があります。このようなトンネルは、境界ノードに追加の構成要件を課す可能性があります。
The process of migration is likely to have significant impact on network operation while migration is in progress. The main objective of migration planning should be to reduce the impact on network operation and on the services perceived by the network users.
移行のプロセスは、移行が進行中のネットワーク操作に大きな影響を与える可能性があります。移行計画の主な目的は、ネットワークの操作とネットワークユーザーが知覚するサービスへの影響を減らすことです。
To this end, planners should consider reducing the number of migration steps that they perform and minimizing the number of migration islands that are created.
この目的のために、プランナーは、実行する移行ステップの数を減らし、作成された移動島の数を最小限に抑えることを検討する必要があります。
A network manager may prefer the island model especially when migration will extend over a significant operational period because it allows the different network islands to be administered as separate management domains. This is particularly the case in the overlay, augmented network and border peer models where the details of the protocol islands remain hidden from the surrounding LSRs.
ネットワークマネージャーは、異なるネットワーク島を別々の管理ドメインとして管理できるため、特に移行が重要な運用期間にわたって延長される場合、島モデルを好む場合があります。これは特に、プロトコル諸島の詳細が周囲のLSRから隠されたままであるオーバーレイ、拡張ネットワーク、ボーダーピアモデルの場合です。
A migration strategy may also imply moving an MPLS state to a GMPLS state for an in-service LSP. This may arise once all of the LSRs along the path of the LSP have been updated to be both MPLS- and GMPLS-capable. Signaling mechanisms to achieve the replacement of an MPLS LSP with a GMPLS LSP without disrupting traffic exist through make-before-break procedures [RFC3209] and [RFC3473], and should be carefully managed under operator control.
移行戦略は、MPLS状態をインサービスLSPのGMPLS状態に移動することを意味する場合があります。これは、LSPの経路に沿ったすべてのLSRがMPLSおよびGMPLS対応の両方に更新されると発生する可能性があります。MPLS LSPのGMPLS LSPを破壊することなくGMPLS LSPに置き換えることを達成するためのシグナル伝達メカニズムは、ブレイク前の手順[RFC3209]および[RFC3473]を通じて存在し、オペレーター管理下で慎重に管理する必要があります。
Security and confidentiality is often applied (and attacked) at administrative boundaries. Some of the models described in this document introduce such boundaries, for example, between MPLS and GMPLS islands. These boundaries offer the possibility of applying or modifying the security as when crossing an IGP area or Autonomous System (AS) boundary, even though these island boundaries might lie within an IGP area or AS.
セキュリティと機密性は、多くの場合、管理境界で適用されます（および攻撃されます）。このドキュメントで説明されているモデルの一部は、たとえばMPLSとGMPLS島の間にそのような境界を導入しています。これらの境界は、これらの島の境界がIGPエリア内またはAS内にある場合でも、IGPエリアまたは自律システム（AS）の境界（AS）の境界を横切るときのように、セキュリティを適用または変更する可能性を提供します。
No changes are proposed to the security procedures built into MPLS and GMPLS signaling and routing. GMPLS signaling and routing inherit their security mechanisms from MPLS signaling and routing without any changes. Hence, there will be no additional issues with security in interworking scenarios. Further, since the MPLS and GMPLS signaling and routing security is provided on a hop-by-hop basis, and since all signaling and routing exchanges described in this document for use between any pair of LSRs are based on either MPLS or GMPLS, there are no changes necessary to the security procedures.
MPLSおよびGMPLSシグナルとルーティングに組み込まれたセキュリティ手順に変更は提案されていません。GMPLSシグナリングとルーティングは、変更なしにMPLSシグナリングとルーティングからセキュリティメカニズムを継承します。したがって、インターワーキングシナリオのセキュリティに関する追加の問題はありません。さらに、MPLSおよびGMPLSシグナリングとルーティングセキュリティはホップバイホップベースで提供されているため、このドキュメントで説明されているすべてのシグナリングおよびルーティング交換は、LSRのペア間で使用されているため、MPLSまたはGMPLSに基づいているため、セキュリティ手順に変更は必要ありません。
The authors are grateful to Daisaku Shimazaki for discussion during the initial work on this document. The authors are grateful to Dean Cheng and Adrian Farrel for their valuable comments.
著者は、この文書の最初の作業中に議論してくれたDaisaku Shimazakiに感謝しています。著者は、貴重なコメントをしてくれたディーン・チェンとエイドリアン・ファレルに感謝しています。
[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年。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473] Berger、L.、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナリングリソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）拡張」、RFC 3473、2003年1月。
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
[RFC3630] Katz、D.、Kompella、K。、およびD. Yeung、「Traffic Engineering（TE）Extensions to OSPFバージョン2」、RFC 3630、2003年9月。
[RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, June 2004.
[RFC3784] Smit、H。およびT. Li、「トラフィックエンジニアリングの中間システム（IS-IS）拡張（TE）」、RFC 3784、2004年6月。
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945] Mannie、E.、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）アーキテクチャ」、RFC 3945、2004年10月。
[RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, Ed., "RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery", RFC 4872, May 2007.
[RFC4872] Lang、J.、ed。、Rekhter、Y.、ed。、およびD. Papadimitriou、ed。、「RSVP-TE拡張機能エンドツーエンド一般化マルチプロトコルラベルスイッチング（GMPLS）回復をサポートする"、RFC 4872、2007年5月。
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, "GMPLS Segment Recovery", RFC 4873, May 2007.
[RFC4873] Berger、L.、Bryskin、I.、Papadimitriou、D。、およびA. Farrel、「Gmplsセグメントリカバリー」、RFC 4873、2007年5月。
[RFC5073] Vasseur, J., Ed., and J. Le Roux, Ed., "IGP Routing Protocol Extensions for Discovery of Traffic Engineering Node Capabilities", RFC 5073, December 2007.
[RFC5073] Vasseur、J.、ed。、およびJ. Le Roux、ed。、「トラフィックエンジニアリングノード機能の発見のためのIGPルーティングプロトコル拡張」、RFC 5073、2007年12月。
[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月。
[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月。
[RFC4726] Farrel, A., Vasseur, J.-P., and A. Ayyangar, "A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering", RFC 4726, November 2006.
[RFC4726] Farrel、A.、Vasseur、J.-P。、およびA. Ayyangar、「ドメイン間マルチプロトコルラベルスイッチングトラフィックエンジニアリングのフレームワーク」、RFC 4726、2006年11月。
[RFC5150] Ayyangar, A., Kompella, A., Vasseur, JP., and A. Farrel, "Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering", RFC 5150, February 2008.
[RFC5150] Ayyangar、A.、Kompella、A.、Vasseur、Jp。、およびA. Farrel、「一般化されたマルチプロトコルラベルスイッチングトラフィックエンジニアリングでのラベルスイッチングパスステッチ」、RFC 5150、2008年2月。
[RFC5146] Kumaki, K., Ed., "Interworking Requirements to Support Operation of MPLS-TE over GMPLS Networks", RFC 5146, March 2008.
[RFC5146] Kumaki、K.、ed。、「GMPLSネットワークを介したMPLS-TEの運用をサポートするためのインターワーキング要件」、RFC 5146、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。
Dimitri Papadimitriou Alcatel Francis Wellensplein 1, B-2018 Antwerpen, Belgium Phone: +32 3 240 8491 EMail: dimitri.papadimitriou@alcatel-lucent.be
Dimitri Papadimitriou Alcatel Francis Wellensplein 1、B-2018 Antwerpen、Belgium電話：32 3 240 8491メール：dimitri.papadimitriou@alcatel-lucent.be
Jean-Louis Le Roux France Telecom av Pierre Marzin 22300 Lannion, France Phone: +33 2 96 05 30 20 EMail: jeanlouis.leroux@orange-ftgroup.com Deborah Brungard AT&T Rm. D1-3C22 - 200 S. Laurel Ave. Middletown, NJ 07748, USA Phone: +1 732 420 1573 EMail: dbrungard@att.com
Jean-Louis Le Roux France Telecom Av Pierre Marzin 22300 Lannion、France電話：33 2 96 05 30 20メール：jeanlouis.leroux@orange-ftgroup.com Deborah Brungard AT＆T RM。D1-3C22-200 S.ローレルアベニューミドルタウン、ニュージャージー州07748、米国電話：1 732 420 1573メール：dbrungard@att.com
Zafar Ali Cisco Systems, Inc. EMail: zali@cisco.com
Zafar Ali Cisco Systems、Inc。メール：zali@cisco.com
Kenji Kumaki KDDI Corporation Garden Air Tower Iidabashi, Chiyoda-ku, Tokyo 102-8460, JAPAN Phone: +81-3-6678-3103 EMail: ke-kumaki@kddi.com
Kenji Kumaki Kddi Corporation Garden Air Tower Iidabashi、Chiyoda-Ku、Tokyo 102-8460、日本電話：81-3-6678-3103メール：ke-kumaki@kddi.com
Eiji Oki NTT Midori 3-9-11 Musashino, Tokyo 180-8585, Japan Phone: +81 422 59 3441 EMail: oki.eiji@lab.ntt.co.jp
eiji oki ntt midori 3-9-11 Musashino、東京180-8585、日本電話：81 422 59 3441メール：oki.eiji@lab.ntt.co.jp
Ichiro Inoue NTT Midori 3-9-11 Musashino, Tokyo 180-8585, Japan Phone: +81 422 59 3441 EMail: inoue.ichiro@lab.ntt.co.jp
ICHIRO INOUE NTT MIDORI 3-9-11 MUSASHINO、東京180-8585、日本電話：81 422 59 3441メール：inoue.ichiro@lab.ntt.co.jp
Tomohiro Otani KDDI Laboratories EMail: otani@kddilabs.jp
Tomohiro Otani Kddi Laboratories Email：otani@kddilabs.jp
Editor's Address
編集者のアドレス
Kohei Shiomoto NTT Midori 3-9-11 Musashino, Tokyo 180-8585, Japan Phone: +81 422 59 4402 EMail: shiomoto.kohei@lab.ntt.co.jp
小屋shiomoto ntt midori 3-9-11 Musashino、Tokyo 180-8585、日本電話：81 422 59 4402電子メール：shiomoto.kohei@lab.ntt.co.jp
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への情報をお問い合わせください。