Network Working Group K. Shiomoto, Ed.
Request for Comments: 5145 NTT
Category: Informational March 2008
Framework for MPLS-TE to GMPLS Migration
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（GMPLS）に（MPLS）トラフィックエンジニアリング（TE）をマルチプロトコルラベルスイッチングの移行はGMPLS制御プレーンにMPLS-TE制御プレーンを進化の過程です。適切な移行戦略は、サービスプロバイダーのネットワーク展開計画、顧客の需要、および運用ポリシーなど、さまざまな要因に基づいて選択されます。
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からGMPLSへ移行するためのいくつかの移行モデルと戦略を提示します。マイグレーション、MPLS-TEやGMPLSデバイス、またはネットワークの過程で、それは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（GMPLS）マイグレーショントラフィックエンジニアリング（MPLS-TE）をマルチプロトコルラベルスイッチングは、GMPLSベースの制御プレーンにMPLS-TEベースの制御プレーンを進化の過程です。移行の検討中のネットワークは、従って、パケット交換ネットワークです。
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プロトコルに追加された新機能や機能を利用する主な願望があります。また、GMPLSにMPLS-TEからパケット交換ネットワークを移行する前に、一方が第GMPLS制御プレーンを使用すること（例えば、管理プレーンによって制御される）無制御プレーンと下層ネットワークを移行することを選択することができます。これは、強化されたTEのサポートを提供し、パケット交換網の後の移行を容易にするために、MPLS-TE / GMPLS（トランスポートネットワーク）インターワーキングのための欲求につながる可能性があります。
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.
これは、 "MAY"、 "MUST NOT"、 "REQUIRED"、それにもかかわらず、キーワード "MUST" 要件ドキュメントではありません、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨します"、この文書における「OPTIONAL」が形成されている推奨事項を明確にするために、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" とのみ（[RFC3209]、[RFC3630]及び[RFC3784]）（MPLS-TE）MPLSトラフィックエンジニアリングを示すために使用され、そのようなラベル配布プロトコル（LDP）などの他のMPLSプロトコルを、除外されています。 MPLS TEの機能性は、GMPLSに移行することができますが、非TEの機能はありませんでした。非TE MPLSが意図されている場合は、それが明示的に示されています。
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).
既存のMPLSネットワークにすべてのGMPLS PSCの機能を追加するにはO（MPLSのLSRをアップグレードします）。
o To add specific GMPLS PSC features and operate them within an MPLS network (e.g., [RFC4872] and [RFC4873]).
特定のGMPLS PSCの機能を追加し、MPLSネットワーク内でそれらを操作するためのO（例えば、[RFC4872]及び[RFC4873]）。
o To integrate a new GMPLS PSC network with an existing MPLS network (without upgrading any of the MPLS LSRs).
oは（MPLSのLSRのいずれかをアップグレードせずに）既存のMPLSネットワークと新しいGMPLSのPSCネットワークを統合します。
o To allow existing MPLS LSRs to interoperate with new non-MPLS LSRs supporting only GMPLS PSC and/or non-PSC features.
既存のMPLSのLSRは、GMPLS PSCおよび/または非PSCの機能のみをサポートする新たな非MPLSのLSRと相互運用できるようにするには、O。
o To integrate multiple control networks, e.g., managed by separate administrative organizations, and which independently utilize MPLS or GMPLS.
O、複数の制御ネットワークを統合するなど、個別の行政機関によって管理され、独立してMPLSやGMPLSを利用するために。
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.
島モデルでは、あるプロトコルを動作するネットワークノードの「島」は、他のプロトコルを使用して、ノードの「海」の中に存在します。
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.
逆も十分に可能です。つまり、島がMPLS対応GMPLS海内であることが起こる可能性がある、あります。このような状況は、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.
また、下層は、手動でプロビジョニングネットワーク（例えば、時分割多重（TDM）ネットワーク）は、MPLSのPSCネットワークの下で構築されることも可能です。 GMPLSの両方のネットワークを移行する過程で、下層のネットワークが最初に移行するかもしれません。これは、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.
（3）MPLS-GMPLS、（2）GMPLS-MPLS-GMPLS、（1）MPLS-GMPLS-MPLS、及び（4）GMPLS-MPLS：インターワーキングシナリオの4種類が考えられます。ケース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だろう、ラムダは）（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
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.
第二の移行モデルは、より統合された移行戦略を必要とします。 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とGMPLSの両方をサポートするようにアップグレードされているように、このモデルでは、ネットワークは、MPLSコントロールプレーンを用いて動作を継続し、いくつかのLSRはまた、GMPLS制御プレーンで動作することが可能です。だから、LSPは、サービスのエンドポイントがレガシーMPLSノードおよび/またはエンドポイント間の選択されたパスは、GMPLS-できないレガシーノードを横断する場所MPLSプロトコルを使用してプロビジョニングされています。サービスのみ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.
一旦、ネットワーク内のすべてのデバイスは、MPLS-特定のプロトコル要素は、GMPLS対応オフにすることができるされ、新しいデバイスは、これらのプロトコル要素をサポートする必要がありません。
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.
段階的モデルは、MPLSネットワーク一つずつにGMPLS機能およびプロトコル要素を導入します。例えば、いくつかのオブジェクトまたはサブオブジェクト（例えば、明示的ルート・オブジェクト（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.
このアプローチは、1つの迅速かつ容易に全体のプロトコル実装をアップグレードすることなく、新しいキー機能を拾うことができているとして実装するシンプルな表示されることがあります。急速に、完全な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間のインターワーキングは、前のセクションで説明したように、GMPLS LSRの役割にハイブリッドLSRを入れて、MPLSのLSRの役割に変わらないLSRを置きます。ネットワーク内の異なるハイブリッドの可能性はかなり問題を複雑にします。展開される新機能のセットがよく知られており、限定されており、ISPのネットワークオペレータによって機能のセット（S）上の明確な理解と合意がある場合と、このモデルは、そのため、使用のためにのみ適切ですその機器の移行に関与することになり、すべてのベンダーと同様に関与。
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ネットワークでは、二つの基本的な移行戦略を考えることができます。第一の戦略では、非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.
第二の戦略は、最初にGMPLS PSCネットワークを移行し、その後非PSCネットワーク内GMPLSを可能にすることです。 PSCネットワークは、前述のように移行され、全体PSCネットワークが完全にGMPLSに変換されるとき、GMPLSベースの非PSCデバイスとネットワークがMPLSとGMPLS間のインターワーキングの問題なく導入することができます。
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またはハイブリッドのLSRがインターワーキングする方法です。このセクションでは、MPLSとGMPLS間のインターワーキングを実現するための選択肢のいくつかを設定し、それに対処する必要がある問題のいくつかを識別します。この文書では、これらの問題に対する解決策を説明していません。
Note that it is possible to consider upgrading the routing and signaling capabilities of LSRs from MPLS to GMPLS separately.
ルーティングをアップグレードし、別途GMPLSにMPLSからの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（のみGMPLS PSCのために）ステッチのLSP [RFC5150]、またはネストされた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非PSC情報及び拡張PSC情報を含むことのIGPによってアドバタイズTE情報を拡張します。 GMPLS情報がMPLS情報と共に運ばれる追加のTLVとして提供されるため、MPLSのLSRのは、彼らがMPLS PSCのLSRであるかのように、すべてのGMPLSのLSRを「見る」ことができます。彼らはまた、他のGMPLS情報が表示されますが、他のGMPLSのLSRが使用する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島の移行モデルに適しています。
- 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.
- 直接分布はGMPLSネットワークにルーティング情報をMPLSの洪水、及びMPLSネットワークにルーティング情報をGMPLSを含みます。境界ノードは、情報をフィルタリングする試みをしません。この動作モードは、MPLSルータは無視するが、彼らは理解していないことを、ルーティングGMPLS情報をあふれさせる続けるという事実に依存しています。ルーティング情報の追加GMPLSの存在は、それがLSRの選択ルートをMPLS方法を妨害しないであろう。このPSCのみのネットワークに問題がないが、それはMPLSノードは、他のLSRのスイッチングタイプを決定することができない、信号しようとするように、非PSCノードを含むピアツーピアアーキテクチャ、ネットワーク内の問題を引き起こす可能性がPSCするすべてのLSRを想定したエンド・ツー・エンドの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のLSRによって開始広告における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).
- プロトコルマッピングは、それらが、プロトコルで受信し、他に送信することができるように、ルーティング広告を変換します。例えば、GMPLSルーティング広告は、GMPLS固有の情報のすべてが削除されている可能性があり、MPLS広告としてフラッディングすることができます。インターワーキングのこのモードでは、広告がさらに浸水することができます前に、MPLS広告を生成するGMPLS固有のフィールドのデフォルト値を必要とし、特に、正しい行動を慎重に標準化が必要となります。多くのLSRはMPLS-とGMPLS対応のインターフェイスを持つ密接に噛み合うネットワークにおける混乱のかなりのリスクもあります。移行中にインターワーキングをルーティングするため、このオプションは、任意の移行のモデルにはお勧めできません。変換GMPLS固有サブのTLVをすることがMPLS-特定のものが、未知のサブTLVを無視しなければならない前弾丸で提案された解決策の変形例（[RFC3630]であると考えられるが、であり続けなければならないGMPLS特有のものを除去しないメモ浸水）。
- 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とGMPLSによって提供される機能の違いにより生じます。
- 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モデルで達成されるが、例えば、GMPLS-MPLS-GMPLSモデルで達成するのは難しいかもしれ、エンド・ツー・エンドの双方向LSPは要求されたとき、MPLS島がないので双方向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アンバランス島モデルでは比較的簡単です。しかし、それは逆方向にシグナリング、これはMPLSアイランド上GMPLSサービスを提供するとGMPLS-できない出口LSRでこれらのサービスを終了するためのかなりの合併症につながるのLSPのために、より複雑であってもよいです。さらに、バランスのとれた島モデルにおいて、特にここで、複数の小（個々のノード）の島は、シグナリングパラメータの反復変換情報（及び機能）またはミス要求の喪失につながる可能性があります。
- 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対応のLSRは、シグナリングプロトコルGMPLSを使用してLSPを確立するためのMPLSシグナリングプロトコルおよびGMPLSのLSRを使用して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）が使用される場合、のPCEは、異なる層[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.
特別な情報やデータモデルは、移行をサポートしていますが、GMPLS管理ツールへのMPLS管理ツールからの移行を意味し、コントロールプレーンでその移行を注意することは必要ありません。移行中に、したがって、それはMPLSとGMPLS管理データの両方をサポートするためのLSRと管理アプリケーションのために必要であり得ます。
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.
移行戦略はまた、サービスLSPのためのGMPLS状態にMPLSの移動状態を意味するものでもよいです。これは、MPLS-とGMPLS対応の両方に更新されました一度LSPのパスに沿ってのLSRの全てを生じる可能性があります。トラフィックを中断することなく、GMPLS LSPとMPLS 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）の境界を横断するときのようにセキュリティを適用するか、変更の可能性を提供します。
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.
作者はこのドキュメントの初期作業中の議論のための大作島崎に感謝しています。作者は彼らの貴重なコメントディーンチェンとエードリアンファレルに感謝しています。
[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。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473]バーガー、L.、エド。、 "一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナリング資源予約プロトコル - トラフィックエンジニアリング（RSVP-TE）を拡張"、RFC 3473、2003年1月。
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
[RFC3630]カッツ、D.、Kompella、K.、およびD.ヨン、 "トラフィックエンジニアリング（TE）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]スミット、H.、およびT.李、 "中間システムトラフィックエンジニアリング（TE）のための中間システム（IS-IS）への拡張"、RFC 3784、2004年6月。
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945]マニー、E.、エド。、 "一般化マルチプロトコルラベルスイッチング（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]ラング、J.、エド。、Rekhter、Y.、エド。、およびD. Papadimitriou、エド。、「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]バーガー、L.、Bryskin、I.、Papadimitriou、D.、およびA.ファレル、 "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.、エド。、およびJ.ル・ルー、エド。、 "トラフィックエンジニアリングノード能力の発見のための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は、RFC 4206、2005年10月 "ラベル・パス（LSP）の階層は、一般マルチプロトコルラベルスイッチング（GMPLS）トラフィックエンジニアリング（TE）との交換しました"。
[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月。
[RFC4726] Farrel, A., Vasseur, J.-P., and A. Ayyangar, "A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering", RFC 4726, November 2006.
[RFC4726]ファレル、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.ファレル、RFC 5150、2008年2月 "トラフィックエンジニアリングを切り替える汎用マルチプロトコルラベルとラベルスイッチパスのステッチ"。
[RFC5146] Kumaki, K., Ed., "Interworking Requirements to Support Operation of MPLS-TE over GMPLS Networks", RFC 5146, March 2008.
[RFC5146]熊木、K.、エド。、RFC 5146、2008年3月 "GMPLSネットワークの上にMPLS-TEの動作をサポートするための要件をインターワーキング"。
[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トラフィックエンジニアリングのためのフレームワーク"。
Dimitri Papadimitriou Alcatel Francis Wellensplein 1, B-2018 Antwerpen, Belgium Phone: +32 3 240 8491 EMail: dimitri.papadimitriou@alcatel-lucent.be
ディミトリPapadimitriouアルカテルフランシスVellensplein 1 B-2018アントワープ、Velgiomボイス：X2 + 3 240 8491 Eメール：δημήτρη.παπαδημητρίου@αλκατελ-λυκεντ.βε
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
ジャン=ルイ・ルーフランステレコムアベニューピエールMarzin 22300ラニオン、フランス電話：33 2月96 5月30日20電子メール：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
デボラBrungard AT＆T Rmの。 D1-3C22 - 200 S.ローレルアベニュー。ミドルタウン、NJ 07748、USA電話：+1 732 420 1573 Eメール：dbrungard@att.com
Zafar Ali Cisco Systems, Inc. EMail: zali@cisco.com
Zafarアリシスコシステムズ、株式会社Eメール：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
健二熊木KDDI株式会社ガーデンエアタワー飯田橋、東京都千代田区102-8460、JAPAN電話：+ 81-3-6678-3103 Eメール：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
えいじ おき んっｔ みどり ３ー９ー１１ むさしの、 ときょ １８０ー８５８５、 じゃぱん Ｐほね： ＋８１ ４２２ ５９ ３４４１ えまいｌ： おき。えいじ＠ぁｂ。んっｔ。こ。ｊｐ
Ichiro Inoue NTT Midori 3-9-11 Musashino, Tokyo 180-8585, Japan Phone: +81 422 59 3441 EMail: inoue.ichiro@lab.ntt.co.jp
いちろ いのうえ んっｔ みどり ３ー９ー１１ むさしの、 ときょ １８０ー８５８５、 じゃぱん Ｐほね： ＋８１ ４２２ ５９ ３４４１ えまいｌ： いのうえ。いちろ＠ぁｂ。んっｔ。こ。ｊｐ
Tomohiro Otani KDDI Laboratories EMail: otani@kddilabs.jp
智弘大谷KDDI研究所Eメール：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
こへい しおもと んっｔ みどり ３ー９ー１１ むさしの、 ときょ １８０ー８５８５、 じゃぱん Ｐほね： ＋８１ ４２２ ５９ ４４０２ えまいｌ： しおもと。こへい＠ぁｂ。んっｔ。こ。ｊｐ
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に情報を記述してください。