RFC5145 日本語訳
5145 Framework for MPLS-TE to GMPLS Migration. K. Shiomoto, Ed.. March 2008. (Format: TXT=44646 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group K. Shiomoto, Ed. Request for Comments: 5145 NTT Category: Informational March 2008
ワーキンググループK.Shiomoto、エドをネットワークでつないでください。コメントのために以下を要求してください。 5145年のNTTカテゴリ: 情報の2008年3月
Framework for MPLS-TE to GMPLS Migration
GMPLS移行へのMPLS-Teのためのフレームワーク
Status of This Memo
このメモの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
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.
Multiprotocol Label Switching(MPLS)トラフィックEngineering(TE)からGeneralized MPLS(GMPLS)までの移行は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.
このフレームワークドキュメントは、また、織り込むことで支援されるかもしれない1セットのソリューションを記載して、1セットの潜在的問題を強調します。
Shiomoto Informational [Page 1] RFC 5145 Framework for MPLS-TE to GMPLS Migration March 2008
GMPLS移行行進2008へのMPLS-TeのためのShiomotoの情報[1ページ]のRFC5145フレームワーク
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
1. 序論…3 2. このドキュメントで中古のコンベンション…3 3. 移行に関する動機…4 4. GMPLS移行へのMPLSはモデル化します…5 4.1. 島のモデル…5 4.1.1. 諸島のバランスをとります…6 4.1.2. 諸島の均衡を失わせます…6 4.2. 統合モデル…7 4.3. モデルの位相を合わせます…8 5. 移行戦略とツールキット…8 5.1. 移行ツールキット…9 5.1.1. ネットワークを層にします…9 5.1.2. ルート設定の織り込むこと…11 5.1.3. シグナリングの織り込むこと…12 5.1.4. 経路計算要素…13 6. 管理可能性問題…13 6.1. 機能と方針のコントロール…13 6.2. 情報とデータはモデル化されます…14 6.3. 活性検出であってモニターすること…14 6.4. 正しい操作について確かめます…14 6.5. 他のプロトコルと機能部品に関する要件…14 6.6. ネットワーク操作のときに、影響を与えてください…15 6.7. 他の問題…15 7. セキュリティ問題…15 8. 承認…16 9. 参照…16 9.1. 標準の参照…16 9.2. 有益な参照…17 10. 貢献者のアドレス…17
Shiomoto Informational [Page 2] RFC 5145 Framework for MPLS-TE to GMPLS Migration March 2008
GMPLS移行行進2008へのMPLS-TeのためのShiomotoの情報[2ページ]のRFC5145フレームワーク
1. Introduction
1. 序論
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.
Generalized MPLS(GMPLS)移行へのMultiprotocol Label Switching Traffic Engineering(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.
そのような移行に関するいくつかの動機、新機能を利用する主に願望、およびGMPLSプロトコルに追加された機能があります。(機能はパケット網のためにMPLS-TEに存在していません)。 さらに、移行する前に、GMPLS制御飛行機を使用することへの制御飛行機(例えば、管理飛行機で、制御される)のない下層ネットワークは最初に移行していますMPLS-TEからのGMPLS、1つへのパケット交換網が、選ぶかもしれない。 これは高められた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.
適切な移行戦略はサービスプロバイダーのネットワーク展開プラン、ネットワーク機器であると配布される顧客要求、運用政策などを含む様々な要素に基づいて選択されるでしょうが、また、メカニズムが使用した変遷は既存のMPLS-TEネットワークの操作のときに影響を最小にしている間新たに導入されたGMPLSネットワークの一貫した操作を提供するべきです。
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プロトコルが共存できることに注意してください。
2. Conventions Used in This Document
2. 本書では使用されるコンベンション
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.
これは要件ドキュメントではありません、とそれにもかかわらず、キーワード“MUST"、「必須NOT」が「必要でした」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはされる推薦状をはっきりさせるためにRFC2119[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」が明らかに使用されます。
Shiomoto Informational [Page 3] RFC 5145 Framework for MPLS-TE to GMPLS Migration March 2008
GMPLS移行行進2008へのMPLS-TeのためのShiomotoの情報[3ページ]のRFC5145フレームワーク
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])だけを示すのに使用されて、他のMPLSプロトコルを除きます、ラベル分配プロトコル(自由民主党)などのように。 MPLSのTEの機能性はそうであるかもしれません。わたられて、GMPLSの、しかし、非TEの機能性はそうすることができませんでした。 非TE MPLSが意図するなら、それは明らかに示されます。
The reader is assumed to be familiar with the terminology introduced in [RFC3945].
読者が[RFC3945]で紹介される用語によく知られさせると思われます。
3. Motivations for Migration
3. 移行に関する動機
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できるLabel Switching Router(LSR)の移行は1つ以上の理由で実行されるかもしれません、以下を徹底的でなく含んでいて
o To add all GMPLS PSC features to an existing MPLS network (upgrade
MPLS LSRs).
o すべてのGMPLS PSCを加えるのは(アップグレードMPLS LSRs)を既存のMPLSネットワークに特集します。
o To add specific GMPLS PSC features and operate them within an MPLS
network (e.g., [RFC4872] and [RFC4873]).
o 特定のGMPLS PSCの特徴を加えて、MPLSの中でそれらを操作するには、(例えば、[RFC4872]と[RFC4873])をネットワークでつないでください。
o To integrate a new GMPLS PSC network with an existing MPLS network
(without upgrading any of the MPLS LSRs).
o 既存のMPLSネットワーク(MPLS LSRsのどれかをアップグレードさせることのない)と新しいGMPLS PSCネットワークを統合するために。
o To allow existing MPLS LSRs to interoperate with new non-MPLS LSRs
supporting only GMPLS PSC and/or non-PSC features.
o 新しい非MPLS LSRsが、GMPLS PSC、そして/または、唯一の非PSCが特徴であるとサポートしていて既存のMPLS LSRsが共同利用するのを許容するために。
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までの移行の目的はすべてのLSRs、および全体のネットワークが、GMPLSがプロトコルであるとサポートするということです。 このプロセスの間、状況が本書では説明した織り込むことをもたらして、様々な当座の状況は存在するかもしれません。 当座の状況はかなりの期間に存在するかもしれませんが、究極の目的はこれらの状況を保存しないことです。 このドキュメントの目的のために、それらは一時的で一時的であると考えられるべきです。
Shiomoto Informational [Page 4] RFC 5145 Framework for MPLS-TE to GMPLS Migration March 2008
GMPLS移行行進2008へのMPLS-TeのためのShiomotoの情報[4ページ]のRFC5145フレームワーク
4. MPLS to GMPLS Migration Models
4. GMPLS移行モデルへのMPLS
Three reference migration models are described below. Multiple migration models may coexist in the same network.
3つの参照移行モデルが以下で説明されます。 複数の移行モデルが同じネットワークで共存するかもしれません。
4.1. Island Model
4.1. 島のモデル
In the island model, "islands" of network nodes operating one protocol exist within a "sea" of nodes using the other protocol.
島のモデルでは、1つのプロトコルを操作するネットワーク・ノードの「島」は、ノードの「海」の中にもう片方のプロトコルを使用することで存在しています。
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.
また、低級層の、そして、手動で食糧を供給されたネットワーク(例えば、Time事業部Multiplexing(TDM)ネットワーク)がMPLS PSCネットワークの下で構成されるのも、可能です。 移行するプロセスの間、GMPLSへの両方のネットワーク、下層ネットワークはそうです。最初に、移行しました。 これはGMPLS島としてMPLS海の中に現れるでしょう。
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.
時間がたつにつれて、新しいGMPLS島を作成するか、または既存のものを広げるためにMPLSデバイスの収集を取り替えるか、またはアップグレードさせます、そして、全体のネットワークが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.
移行/織り込む観点から、私たちは、これらの島がどのように置かれるか、そして、Label Switched Paths(LSPs)が島の間でどのように接続するかを調べる必要があります。
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であることに基づいて織り込むことの振舞いは調べられます。
Shiomoto Informational [Page 5] RFC 5145 Framework for MPLS-TE to GMPLS Migration March 2008
GMPLS移行行進2008へのMPLS-TeのためのShiomotoの情報[5ページ]のRFC5145フレームワーク
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、5ヵ国蔵相会議、およびG6)の境界のノードは「島の境界ノード」と呼ばれます。 GMPLS島が非PSCであるなら、GMPLSベースのトランジット島(G3とG4)の中の島の境界ノード以外のすべてのノードが非PSCデバイスでしょうに、すなわち、光学機器(TDM、Lambda Switch Capable(LSC)、およびFiber Switch Capable(FSC))。
................. .......................... .................. : MPLS : : GMPLS : : MPLS : :+---+ +---+ +----+ +---+ +----+ +---+ +---+: :|R1 |__|R11|___| G1 |_________|G3 |________| G5 |___|R31|__|R3 |: :+---+ +---+ +----+ +-+-+ +----+ +---+ +---+: : ________/ : : _______/ | _____ / : : ________/ : : / : : / | / : : / : :+---+ +---+ +----+ +-+-+ +----+ +---+ +---+: :|R2 |__|R21|___| G2 |_________|G4 |________| G6 |___|R41|__|R4 |: :+---+ +---+ +----+ +---+ +----+ +---+ +---+: :................: :........................: :................:
................. .......................... .................. : MPLS: : GMPLS: : MPLS: :+---+ +---+ +----+ +---+ +----+ +---+ +---+: :| R1|__|R11|___| G1|_________|G3|________| 5ヵ国蔵相会議|___|R31|__|R3|: :+---+ +---+ +----+ +-+-+ +----+ +---+ +---+: : ________/ : : _______/ | _____ / : : ________/ : : / : : / | / : : / : :+---+ +---+ +----+ +-+-+ +----+ +---+ +---+: :| R2|__|R21|___| G2|_________|G4|________| G6|___|R41|__|R4|: :+---+ +---+ +----+ +---+ +----+ +---+ +---+: :................: :........................: :................:
|<-------------------------------------------------------->|
e2e LSP
| <。-------------------------------------------------------->| e2e LSP
Figure 1: Example of the island model
for MPLS-GMPLS-MPLS interworking
図1: MPLS-GMPLS-MPLSの織り込む島のモデルに関する例
4.1.1. Balanced Islands
4.1.1. バランスのとれている諸島
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場合では、LSPsは、同じプロトコルを使用することで終始します。 可能な戦略は:
- tunneling the signaling across the island network using LSP nesting
or stitching [RFC5150] (the latter is only for GMPLS-PSC)
- [RFC5150]を入れ子にするか、またはステッチするLSPを使用することで島のネットワークの向こう側にシグナリングにトンネルを堀ります。(後者はGMPLS-PSCのためだけのものです)
- protocol interworking or mapping (both are only for GMPLS-PSC)
- プロトコルの織り込むかマッピング(ともに、GMPLS-PSCのためだけに、あります)
4.1.2. Unbalanced Islands
4.1.2. アンバランスな諸島
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
この場合、LSPはMPLS島の中で始まるか、GMPLS(PSC)島に終わって、対応する終わるか、または始まります。 またはプロトコルの織り込むことを使用することでこの運転モードを扱うことができるだけである。
Shiomoto Informational [Page 6] RFC 5145 Framework for MPLS-TE to GMPLS Migration March 2008
GMPLS移行行進2008へのMPLS-TeのためのShiomotoの情報[6ページ]のRFC5145フレームワーク
mapping. Figure 2 shows the reference model for this migration scenario. Head-end and tail-end LSRs are in distinct control plane clouds.
写像します。 図2はこの移行シナリオのために規範モデルを示しています。 異なったコントロール飛行機雲にはギヤエンドと末端LSRsがあります。
............................ ............................. : MPLS : : GMPLS (PSC) : :+---+ +---+ +----+ +---+ +---+: :|R1 |________|R11|_______| G1 |________|G3 |________|G5 |: :+---+ +---+ +----+ +-+-+ +---+: : ______/ | _____/ : : ______/ | ______/ : : / | / : : / | / : :+---+ +---+ +----+ +-+-+ +---+: :|R2 |________|R21|_______| G2 |________|G4 |________|G6 |: :+---+ +---+ +----+ +---+ +---+: :..........................: :...........................:
............................ ............................. : MPLS: : GMPLS(PSC): :+---+ +---+ +----+ +---+ +---+: :| R1|________|R11|_______| G1|________|G3|________|5ヵ国蔵相会議|: :+---+ +---+ +----+ +-+-+ +---+: : ______/ | _____/ : : ______/ | ______/ : : / | / : : / | / : :+---+ +---+ +----+ +-+-+ +---+: :| R2|________|R21|_______| G2|________|G4|________|G6|: :+---+ +---+ +----+ +---+ +---+: :..........................: :...........................:
|<-------------------------------------------------->|
e2e LSP
| <。-------------------------------------------------->| 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が設立される方向でこのシナリオに影響を与えるのは重要です。
4.2. Integrated Model
4.2. 統合モデル
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とGMPLSの両方をサポートするためにアップグレードするとき、ネットワークは、MPLS制御飛行機で作動し続けていますが、また、いくつかのLSRsがGMPLS制御飛行機で作動できます。 それで、サービスの片端ポイントがレガシーMPLSノードであり、エンドポイントの間の選択された経路がGMPLSできないレガシーノードを横断するMPLSプロトコルを使用することでLSPsは食糧を供給されます。 しかし、それは、GMPLSできるノードだけを使用するのをサービスに提供できるところ[RFC5073]に、それに従って、発送されるかもしれなくて、GMPLSの特徴を利用することによって、より高いレベルの機能性を達成できます。
Shiomoto Informational [Page 7] RFC 5145 Framework for MPLS-TE to GMPLS Migration March 2008
GMPLS移行行進2008へのMPLS-TeのためのShiomotoの情報[7ページ]のRFC5145フレームワーク
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つのプロトコルセットの共存に関係があります。 実際の織り込むのは関心ではありません。
4.3. Phased Model
4.3. 段階的なモデル
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ネットワークにひとつずつ取り入れます。 例えば、いくつかのオブジェクトかサブオブジェクト(Explicit Route Object(ERO)ラベルサブオブジェクト、[RFC3473]などの)がそうでなければMPLSできるLSRsによって使用されたシグナリングに取り入れられるかもしれません。 これは一種のハイブリッド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.
同時にネットワークにおけるすべてのLSRsをアップデートするというわけではないならこの移行モデルが悪化させて、特徴のどの部分集合の明確な理解があるか、しかし、相互運用性関心はハイブリッドLSRsに含まれることです。 ハイブリッドLSRと変わりのないMPLS LSRの間の織り込むのは、前項で説明されるようにGMPLS LSRの役割にハイブリッドLSRを入れて、MPLS LSRの役割に変わりのないLSRを入れます。 ネットワークの中の異なったハイブリッドの可能性は件をかなり複雑にするでしょう。 したがって、配布するべき新機能のセットがよく知られていて限られているときの使用、どこに明確な理解があるか、そして、および協定だけに、このモデルはこのセットの特徴で設備が移行にかかわるすべてのベンダーと同様にかかわるISPのネットワーク・オペレータで適切です。
5. Migration Strategies and Toolkit
5. 移行戦略とツールキット
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
PSCネットワークのために、移行戦略は前項で説明されたモデルの間の選択を伴います。 選択が最終的な目的による、(完全なGMPLS能力と、部分
Shiomoto Informational [Page 8] RFC 5145 Framework for MPLS-TE to GMPLS Migration March 2008
GMPLS移行行進2008へのMPLS-TeのためのShiomotoの情報[8ページ]のRFC5145フレームワーク
upgrade to include specific GMPLS features, or no change to existing IP/MPLS networks), and upon the immediate objectives (full, phased, or staged upgrade).
特定の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が移行するように、非PSCネットワークの中で1番目をGMPLSにネットワークでつないで、次に、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.
前項で説明されたこれらの移行戦略と移行モデルは必ず互いに排他的ではありません。 すべての戦略とモデルの混合物を適用できました。 モデルと戦略が選択した移行はケースが以下のセクションで説明した織り込むことのより多くのものをもたらすでしょう。
5.1. Migration Toolkit
5.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とGMPLSの間の織り込むことを達成するための代替手段のいくつかを出します、そして、それは扱われる必要がある問題のいくつかを特定します。 このドキュメントはこれらの問題にソリューションについて説明しません。
Note that it is possible to consider upgrading the routing and signaling capabilities of LSRs from MPLS to GMPLS separately.
別々にLSRsのルーティングとシグナリング能力をMPLSからGMPLSまでアップグレードさせると考えるのが可能であることに注意してください。
5.1.1. Layered Networks
5.1.1. 階層型ネットワーク
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
バランスのとれている島のモデルでは、LSPトンネル[RFC4206]は両立しないノードの島の向こう側に終わりから終わりへのLSPsを運ぶソリューションです。 ネットワークレイヤリングは、異なったデータ飛行機技術のドメインを切り離すのにしばしば使用されます。 また、異なったコントロール飛行機技術(MPLSやGMPLSプロトコルなどの)のドメインを切り離すのにそれを使用できました、そして、解決策は複数のデータ飛行機のために見いだされました。
Shiomoto Informational [Page 9] RFC 5145 Framework for MPLS-TE to GMPLS Migration March 2008
GMPLS移行行進2008へのMPLS-TeのためのShiomotoの情報[9ページ]のRFC5145フレームワーク
technologies can be usefully applied to this situation [RFC3945], [RFC4206], and [RFC4726]. [MLN-REQ] gives a discussion of the requirements for multi-layered networks.
有効にこの状況[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.
同輩モデルで合図するのは隣接のLSPs、ステッチされたLSPs[RFC5150](GMPLS PSCのためだけの)、または入れ子にされたLSPsをもたらすかもしれません。 ネットワーク島が非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のMPLS-GMPLS-MPLS島のモデルと非PSC GMPLS島に合っています。 シグナリングの織り込むのが同輩モデルのために説明されるように必要です。
Shiomoto Informational [Page 10] RFC 5145 Framework for MPLS-TE to GMPLS Migration March 2008
GMPLS移行行進2008へのMPLS-TeのためのShiomotoの情報[10ページ]のRFC5145フレームワーク
5.1.2. Routing Interworking
5.1.2. ルート設定の織り込むこと
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情報を含むようにIGPsによって広告に掲載されたTE情報を広げています。 MPLS情報と共に運ばれる追加TLVsとしてGMPLS情報を提供するので、MPLS LSRsはまるで彼らがMPLS PSC LSRsであるかのようにすべてのGMPLS LSRsを「見ることができます」。 彼らは、また、他の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島の移動モデルに、それは適当です。
- 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ルーティング情報の存在はMPLS LSRsがルートを選択する方法を妨げないでしょう。 これはPSCだけネットワークでは問題ではありませんが、非PSCノードを含んでいる同輩構造ネットワークで問題を起こすことができました、MPLSノードが、他のLSRsの切り換えタイプを決定できないで、PSCであるように終わりから終わりへのすべてのLSRsを仮定するLSPsに合図するのを試みるとき。 この事実は、異なったスイッチング能力の島の向こう側にトンネルをセットアップするために引き起こされた行動を取るために島の境界ノードを必要とするでしょう。
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).
MPLS LSRsによって開始された広告における、GMPLS-特殊情報の欠如でGMPLS LSRsに影響を与えるかもしれません。 特定の手順が、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
- それらを1つのプロトコルで受け取って、もう片方で伝えることができるように広告を発送する転向者を写像して、議定書を作ってください。 例えば、GMPLSルーティング広告は、GMPLS-特殊情報のすべてが取り除かれるのを出すことができて、MPLS広告としてあふれさせることができました。 織り込むことのこのモードはMPLS広告がGMPLS特有の分野のデフォルト値を必要とする正しい振舞いの慎重な標準化を必要とするでしょう。
Shiomoto Informational [Page 11] RFC 5145 Framework for MPLS-TE to GMPLS Migration March 2008
GMPLS移動行進2008へのMPLS-TeのためのShiomotoの情報[11ページ]のRFC5145枠組み
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).
広告をさらにあふれさせることができる前に発生してください。 また、密接にかみ合っているネットワークにおける、混乱のかなりのリスクが多くのLSRsがMPLSとGMPLSできるインタフェースを持っているところにあります。 移動の間のルーティングの織り込むこのオプションはどんな移動モデルのためのNOT RECOMMENDEDです。 GMPLS特有のサブTLVsをMPLS特有のものに変換しますが、GMPLS特有のものを剥取らないのが前の弾丸の提案された解決策の異形であると考えられることに注意してください(未知のサブTLVsは無視されるべきですが[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つの例が、独立していて、同じタイプのLSRsの間でルーティング隣接番組を作成するのに使用されます。 統合移動モデルに、この運転モードは適切であるかもしれません。
5.1.3. Signaling Interworking
5.1.3. シグナリングの織り込むこと
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.
シグナリングプロトコルは、LSPsを証明するのに使用されて、移動の間の織り込むのに関する主たる関心事です。 互換性の問題はMPLSとGMPLSシグナリングによって使用されましたが、機能性の違いのためにもMPLSとGMPLSによって提供されたencodingsとcodepointsの違いで起こります。
- 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モデルのために容易に達成されますが、例えば、終わりから終わりへの双方向のLSPsが要求されているとき、GMPLS-MPLS-GMPLSモデルで達成するのは困難であるかもしれません、MPLS島が双方向のLSPsを支持しないので。
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
- プロトコルマッピングはMPLSとGMPLSの間のシグナリングメッセージの変換です。 このメカニズムはプロトコル分野とそれらがどう写像されるかに関する慎重なドキュメンテーションを必要とします。 MPLS-GMPLS方向に合図されたLSPsに、これはMPLS-GMPLSの気が転倒した島のモデルで比較的簡単です。 しかしながら、逆方向に合図されたLSPsには、それは、より複雑であるかもしれません、そして、これは複雑になるでしょう。
Shiomoto Informational [Page 12] RFC 5145 Framework for MPLS-TE to GMPLS Migration March 2008
GMPLS移動行進2008へのMPLS-TeのためのShiomotoの情報[12ページ]のRFC5145枠組み
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.
GMPLSできない出口LSRでMPLS島の上でサービスをGMPLSに供給して、それらのサービスを終えるためのかなりの複雑さに通じてください。 さらに、バランスのとれている島のモデルと特に、複数の小さい(個々のノード)島がどこにあるかで、シグナリングパラメタの繰り返された変換は情報(そして、機能性)か誤要求の損失を出すかもしれません。
- 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がLSPsを設立するのをGMPLSシグナリングプロトコルを使用することでLSPsを設立するようにプロトコルとGMPLS LSRsに合図するMPLSを使用することで許容するのに統合移動モデルで夜の船を使用できました。 両方のセットのプロトコルを扱うことができるLSRsはLSRsの両方のタイプで働くかもしれません、そして、プロトコルの変換は全く必要でないでしょう。
5.1.4. Path Computation Element
5.1.4. 経路計算要素
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].
Path Computation Element(PCE)[RFC4655]はGMPLS移動にMPLSを支援する追加ツールを提供するかもしれません。 階層型ネットワークアプローチ(セクション5.1.1)が使用されているなら、PCEsは、[PCE-INT]異なった層のLSPsのために経路の計算を容易にするのに使用されるかもしれません。
6. Manageability Considerations
6. 管理可能性問題
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.
ネットワークが移動と移動の後にどう経営されるかに計画されている移動の間、注意を与えるべきです。 例えば、異なったプロトコル能力のLSRsは別々にか1つの管理ドメインとして管理されるでしょうか? 例えば、Model島の中では、別々に周囲の海から1つの能力の島を管理すると考えるのは可能です。 異なったスイッチング能力を持っている島の場合では、島が移動の前に適所に既に別々の管理を持っているのは、可能です: 結果は移動しました。ネットワークは、管理を合併しようとするか、または分離を保存しようとするかもしれません。
6.1. Control of Function and Policy
6.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でどのインタフェースがどのプロトコルをサポートするかを示すのは可能であるに違いありません。 さらに、島の境界は方針を適用する自然な場所です、そして、経営者側はそのような方針の構成を許すべきです。
Shiomoto Informational [Page 13] RFC 5145 Framework for MPLS-TE to GMPLS Migration March 2008
GMPLS移動行進2008へのMPLS-TeのためのShiomotoの情報[13ページ]のRFC5145枠組み
6.2. Information and Data Models
6.2. 情報とデータモデル
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管理ツールまでの移動を含意することに注意してください。 移動の間、したがって、LSRsと管理アプリケーションが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モジュールに拡大と増大で建てられます。 これで移動するのは可能になるかもしれません。彼らが管理するLSRsの前の管理アプリケーション。
6.3. Liveness Detection and Monitoring
6.3. 活性検出とモニター
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のために複数のスイッチング能力の向こう側に既に存在するものの上のOperations、政権、およびManagement(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.
しかしながら、マルチ層のOAMのテクニックのための要件が平坦なPSC MPLSネットワークが島のモデルを使用することで移動している、GMPLSの向こう側に接続するのにトンネルを使用する階層型ネットワークとして扱われた島であるなら以前に平坦なOAM問題スペースで定義されたことに取り入れられるかもしれないことに注意してください。 MPLS/GMPLSの織り込むことのOAM枠組みはさらなる考慮を必要とするでしょう。
6.4. Verifying Correct Operation
6.4. 正しい操作について確かめます。
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]をことにステッチする過程は以前にaがネットワークが平坦であるということでした。
6.5. Requirements on Other Protocols and Functional Components
6.5. 他のプロトコルと機能部品に関する要件
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
また、階層化アーキテクチャを支持して移動島の向こう側にシグナリングとルーティングの接続性を提供するのがプロトコルトンネルの使用を必要とするかもしれないのが観測されるべきである、(Genericなど
Shiomoto Informational [Page 14] RFC 5145 Framework for MPLS-TE to GMPLS Migration March 2008
GMPLS移動行進2008へのMPLS-TeのためのShiomotoの情報[14ページ]のRFC5145枠組み
Routing Encapsulation (GRE)) between island border nodes. Such tunnels may impose additional configuration requirements at the border nodes.
Encapsulation(GRE)を島の境界ノードの間に発送します。 そのようなトンネルは境界ノードで追加構成必要条件を課すかもしれません。
6.6. Impact on Network Operation
6.6. ネットワーク操作のときに、影響を与えてください。
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.
特に異なったネットワーク島が別々の管理ドメインとして管理されるのを許容するので移動が重要な操作上の期間広がるとき、ネットワークマネージャは島のモデルを好むかもしれません。 これは周囲のLSRs隠されたままでプロトコル島の細部が残っているオーバレイ、増大しているネットワーク、および境界同輩モデルで特にそうです。
6.7. Other Considerations
6.7. 他の問題
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状態に述べる動きを含意するかもしれません。 両方のMPLSでGMPLSできるためにいったんLSPの経路に沿ったLSRsのすべてをアップデートすると、これは起こるかもしれません。 メカニズムに合図して、交通を中断しないでGMPLS LSPへのMPLS LSPの交換品を達成するのは、以前開閉している手順[RFC3209]と[RFC3473]で存在していて、操作員制御の下で慎重に管理されるべきです。
7. Security Considerations
7. セキュリティ問題
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領域かAutonomous System(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
変化は全くMPLS、GMPLSシグナリング、およびルーティングが組み込まれたセキュリティ手順に提案されません。 GMPLSシグナリングとルーティングはMPLSシグナリングとルーティングから少しも変化なしで彼らのセキュリティー対策を引き継ぎます。 したがって、シナリオを織り込むのにおいてセキュリティには追加設定が全くないでしょう。 さらに、MPLS、GMPLSシグナリング、およびルーティングのときに、ホップごとのベース、およびすべて以来セキュリティを提供します。
Shiomoto Informational [Page 15] RFC 5145 Framework for MPLS-TE to GMPLS Migration March 2008
GMPLS移動行進2008へのMPLS-TeのためのShiomotoの情報[15ページ]のRFC5145枠組み
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.
交換がどんな組のLSRsの間の使用のために本書では説明したシグナリングとルーティングはMPLSかGMPLSのどちらかに基づいていて、セキュリティ手順に必要などんな変化もありません。
8. Acknowledgements
8. 承認
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.
作者はこのドキュメントへの初期の作業の間、嶋崎大作に議論に感謝しています。 作者はディーン・チェンとエードリアン・ファレルに彼らの貴重なコメントに感謝しています。
9. References
9. 参照
9.1. Normative References
9.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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.、Srinivasan、V.、およびG.が飲み込まれる、「RSVP-Te:」 「LSP TunnelsのためのRSVPへの拡大」、RFC3209、2001年12月。
[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.(エド))は「資源予約プロトコル交通工学(RSVP-Te)拡大に合図しながら、マルチプロトコルラベルスイッチング(GMPLS)を一般化しました」、RFC3473、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.Yeung、「(Te)拡大をOSPFにバージョン2インチ設計する交通、RFC3630、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)のための拡大、」、RFC3784(2004年6月)
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945] エドマニー、E.、RFC3945、「一般化されたマルチプロトコルラベルは(GMPLS)構造を切り換えること」での10月2004日
[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)回復を一般化しました」、RFC4872、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セグメント回復」、RFC4873は2007がそうするかもしれません。
[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は交通工学ノード能力の発見のためのプロトコル拡大を発送すること」でのRFC5073(2007年12月)。
Shiomoto Informational [Page 16] RFC 5145 Framework for MPLS-TE to GMPLS Migration March 2008
GMPLS移動行進2008へのMPLS-TeのためのShiomotoの情報[16ページ]のRFC5145枠組み
9.2. Informative References
9.2. 有益な参照
[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)を階層構造とラベルします」、RFC4206、2005年10月。
[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)ベースの構造」、RFC4655、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、「相互ドメインMultiprotocolラベル切り換え交通工学のための枠組み」、RFC4726(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.ファレル)は「一般化されたMultiprotocolラベル切り換え交通工学でステッチされる切り換えられた経路をラベルします」、RFC5150、2008年2月。
[RFC5146] Kumaki, K., Ed., "Interworking Requirements to Support
Operation of MPLS-TE over GMPLS Networks", RFC 5146, March
2008.
[RFC5146] エドKumaki、K.、RFC5146、「GMPLSネットワークの上でMPLS-Teの操作を支持するという要件を織り込む」3月2008日
[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.
[百万REQ] K.、Papadimitriou、D.、ル・ルー、J.L.、ビグルー、M.、およびD.Brungard、「GMPLSを拠点とするマルチ領域の、そして、マルチ層のネットワーク(MRN/百万)のための要件」というShiomotoは進行中(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.、ル・ルー、J-L.、およびA.ファレル、「PCEベースの相互層のMPLSとGMPLS交通工学のための枠組み」は進行中(2008年1月)で働いています。
10. Contributors' Addresses
10. 貢献者のアドレス
Dimitri Papadimitriou Alcatel Francis Wellensplein 1, B-2018 Antwerpen, Belgium Phone: +32 3 240 8491 EMail: dimitri.papadimitriou@alcatel-lucent.be
ディミトリPapadimitriouアルカテルフランシスWellensplein1、B-2018アントウェルペン(ベルギー)は以下に電話をします。 +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
ジャン・ルイル・ルーフランステレコムavピアーMarzin22300Lannion、フランス電話: +33 2 96 05 30 20はメールされます: jeanlouis.leroux@orange-ftgroup.com
Shiomoto Informational [Page 17] RFC 5145 Framework for MPLS-TE to GMPLS Migration March 2008
GMPLS移動行進2008へのMPLS-TeのためのShiomotoの情報[17ページ]のRFC5145枠組み
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秒間ローレルAve。 ミドルタウン、ニュージャージー 07748、米国は以下に電話をします。 +1 1573年の732 420メール: dbrungard@att.com
Zafar Ali Cisco Systems, Inc. EMail: zali@cisco.com
ZafarアリシスコシステムズInc.EMail: 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社の庭の空気Tower飯田橋、千代田区、東京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の美土里の3 9-11テロの武蔵野、東京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
イチローの井上のNTTの美土里の3 9-11テロの武蔵野、東京180-8585(日本)は以下に電話をします。 +81 422 59 3441はメールされます: inoue.ichiro@lab.ntt.co.jp
Tomohiro Otani KDDI Laboratories EMail: otani@kddilabs.jp
智宏オータニKDDI研究所はメールされます: 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
Kohei ShiomotoのNTTの美土里の3 9-11テロの武蔵野、東京180-8585(日本)は以下に電話をします。 +81 422 59 4402はメールされます: shiomoto.kohei@lab.ntt.co.jp
Shiomoto Informational [Page 18] RFC 5145 Framework for MPLS-TE to GMPLS Migration March 2008
GMPLS移動行進2008へのMPLS-TeのためのShiomotoの情報[18ページ]のRFC5145枠組み
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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に情報を記述してください。
Shiomoto Informational [Page 19]
Shiomoto情報です。[19ページ]
一覧
スポンサーリンク
