RFC5146 日本語訳
5146 Interworking Requirements to Support Operation of MPLS-TE overGMPLS Networks. K. Kumaki, Ed.. March 2008. (Format: TXT=31624 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group K. Kumaki, Ed. Request for Comments: 5146 KDDI Corporation Category: Informational March 2008
ワーキンググループK.Kumaki、エドをネットワークでつないでください。コメントのために以下を要求してください。 5146年のKDDI社のカテゴリ: 情報の2008年3月
Interworking Requirements to Support Operation of MPLS-TE over GMPLS Networks
GMPLSネットワークの上でMPLS-Teの操作をサポートするという要件を織り込みます。
Status of This Memo
このメモの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
Operation of a Multiprotocol Label Switching (MPLS) traffic engineering (TE) network as a client network to a Generalized MPLS (GMPLS) network has enhanced operational capabilities compared to those provided by a coexistent protocol model (i.e., operation of MPLS-TE over an independently managed transport layer).
Generalized MPLS(GMPLS)ネットワークへのクライアントネットワークが運用能力を高めたので、Multiprotocol Label Switching(MPLS)交通工学(TE)ネットワークの操作は共存しているプロトコルモデル(すなわち、独自に管理されたトランスポート層の上のMPLS-TEの操作)によって提供されたものと比較されました。
The GMPLS network may be a packet or a non-packet network, and may itself be a multi-layer network supporting both packet and non-packet technologies. An MPLS-TE Label Switched Path (LSP) originates and terminates on an MPLS Label Switching Router (LSR). The GMPLS network provides transparent transport for the end-to-end MPLS-TE LSP.
そして、GMPLSネットワークがパケットか非パケット網であるかもしれない、それ自体、両方のパケットと非パケット技術をサポートするマルチ層のネットワークになるかもしれなくなってください。 MPLS-TE Label Switched Path(LSP)はMPLS Label Switching Router(LSR)で起因して、終わります。 GMPLSネットワークは終わりから終わりへのMPLS-TE LSPのためのわかりやすい輸送を提供します。
This document describes a framework and Service Provider requirements for operating MPLS-TE networks over GMPLS networks.
このドキュメントはGMPLSネットワークの上で操作MPLS-TEネットワークのためのフレームワークとService Provider要件について説明します。
Kumaki Informational [Page 1] RFC 5146 Operating MPLS-TE over GMPLS Networks March 2008
2008年3月にGMPLSネットワークの上でMPLS-Teを操作するKumakiの情報[1ページ]のRFC5146
Table of Contents
目次
1. Introduction ....................................................3 1.1. Terminology ................................................4 2. Reference Model .................................................4 3. Detailed Requirements ...........................................5 3.1. End-to-End Signaling .......................................5 3.2. Triggered Establishment of GMPLS LSPs ......................5 3.3. Diverse Paths for End-to-End MPLS-TE LSPs ..................6 3.4. Advertisement of MPLS-TE Information via the GMPLS Network ....................................................6 3.5. Selective Advertisement of MPLS-TE Information via a Border Node ..............................................6 3.6. Interworking of MPLS-TE and GMPLS Protection ...............7 3.7. Independent Failure Recovery and Reoptimization ............7 3.8. Complexity and Risks .......................................7 3.9. Scalability Considerations .................................7 3.10. Performance Considerations ................................8 3.11. Management Considerations .................................8 4. Security Considerations .........................................8 5. Recommended Solution Architecture ...............................9 5.1. Use of Contiguous, Hierarchical, and Stitched LSPs ........10 5.2. MPLS-TE Control Plane Connectivity ........................10 5.3. Fast Reroute Protection ...................................10 5.4. GMPLS LSP Advertisement ...................................11 5.5. GMPLS Deployment Considerations ...........................11 6. Acknowledgments ................................................11 7. References .....................................................11 7.1. Normative References ......................................11 7.2. Informative References ....................................12 8. Contributors' Addresses ........................................13
1. 序論…3 1.1. 用語…4 2. 参照モデル…4 3. 要件を詳しく述べます…5 3.1. 終わりから終わりへのシグナリング…5 3.2. GMPLS LSPsの設立の引き金となります…5 3.3. 終わりから終わりへのMPLS-Te LSPsに、さまざまの経路…6 3.4. GMPLS Networkを通したMPLS-TE情報の広告…6 3.5. Border Nodeを通したMPLS-TE情報の選択しているAdvertisement…6 3.6. MPLS-TeとGMPLS保護を織り込むこと…7 3.7. 独立している失敗の回復とReoptimization…7 3.8. 複雑さとリスク…7 3.9. スケーラビリティ問題…7 3.10. パフォーマンス問題…8 3.11. 管理問題…8 4. セキュリティ問題…8 5. お勧めのソリューションアーキテクチャ…9 5.1. 隣接の、そして、階層的で、ステッチされたLSPsの使用…10 5.2. MPLS-Teコントロール飛行機の接続性…10 5.3. 速く保護を別ルートで送ってください…10 5.4. GMPLS LSP広告…11 5.5. GMPLS展開問題…11 6. 承認…11 7. 参照…11 7.1. 標準の参照…11 7.2. 有益な参照…12 8. 貢献者のアドレス…13
Kumaki Informational [Page 2] RFC 5146 Operating MPLS-TE over GMPLS Networks March 2008
2008年3月にGMPLSネットワークの上でMPLS-Teを操作するKumakiの情報[2ページ]のRFC5146
1. Introduction
1. 序論
Multiprotocol Label Switching traffic engineering (MPLS-TE) networks are often deployed over transport networks such that the transport networks provide connectivity between the Label Switching Routers (LSRs) in the MPLS-TE network. Increasingly, these transport networks are operated using a Generalized Multiprotocol Label Switching (GMPLS) control plane. Label Switched Paths (LSPs) in the GMPLS network provide connectivity as virtual data links advertised as TE links in the MPLS-TE network.
Multiprotocol Label Switching交通工学(MPLS-TE)ネットワークが転送ネットワークの上でしばしば配布されるので、転送ネットワークはMPLS-TEネットワークにおけるLabel Switching Routers(LSRs)の間に接続性を供給します。 ますます、これらの転送ネットワークは、Generalized Multiprotocol Label Switching(GMPLS)制御飛行機を使用することで経営されます。 GMPLSネットワークにおけるラベルSwitched Paths(LSPs)はTEがMPLS-TEネットワークでリンクするので広告に掲載された仮想データリンクとして接続性を提供します。
GMPLS protocols were developed as extensions to MPLS-TE protocols. MPLS-TE is limited to the control of packet switching networks, but GMPLS can also control technologies at layers one and two.
GMPLSプロトコルは拡大としてMPLS-TEプロトコルに開発されました。 MPLS-TEはパケット交換網のコントロールに制限されますが、また、GMPLSは層1とtwoで技術を制御できます。
The GMPLS network may be managed by an operator as a separate network (as it may have been when it was under management plane control before the use of GMPLS as a control plane), but optimizations of management and operation may be achieved by coordinating the use of the MPLS-TE and GMPLS networks and operating the two networks with a close client/server relationship.
GMPLSネットワークは別々のネットワークとしてオペレータによって経営されるかもしれませんが(GMPLSの使用の前に、管理飛行機コントロールの下で制御飛行機としてそれがあった時であるときに)、管理と操作の最適化は、MPLS-TEとGMPLSネットワークの使用を調整して、近いクライアント/サーバ関係で2つのネットワークを経営することによって、達成されるかもしれません。
GMPLS LSP setup may be triggered by the signaling of MPLS-TE LSPs in the MPLS-TE network so that the GMPLS network is reactive to the needs of the MPLS-TE network. The triggering process can be under the control of operator policies without needing direct intervention by an operator.
GMPLS LSPセットアップがMPLS-TE LSPsのシグナリングによってMPLS-TEネットワークで引き起こされるかもしれないので、GMPLSネットワークはMPLS-TEネットワークの必要性に反応しています。 オペレータによる直接介入を必要としないで、引き金となるプロセスがオペレータ方針のコントロールの下にあることができます。
The client/server configuration just described can also apply in migration scenarios for MPLS-TE packet switching networks that are being migrated to be under GMPLS control. [RFC5145] describes a migration scenario called the Island Model. In this scenario, groups of nodes (islands) are migrated from the MPLS-TE protocols to the GMPLS protocols and operate entirely surrounded by MPLS-TE nodes (the sea). This scenario can be effectively managed as a client/server network relationship using the framework described in this document.
また、ただ説明されたクライアント/サーバ構成は、存在が移行したということであるMPLS-TEパケット交換網のための移行シナリオでGMPLSコントロールの下にあるのに申し込むことができます。 [RFC5145]はModel島と呼ばれる移行シナリオについて説明します。 このシナリオでは、ノード(島)のグループがそう、MPLS-TEプロトコルからGMPLSプロトコルまで移行して、MPLS-TEノード(海)によって完全に囲まれた状態で作動します。 本書では説明されたフレームワークを使用することで事実上、クライアント/サーバネットワーク関係としてこのシナリオに対処できます。
In order to correctly manage the dynamic interaction between the MPLS and GMPLS networks, it is necessary to understand the operational requirements and the control that the operator can impose. Although this problem is very similar to the multi-layer networks described in [MLN-REQ], it must be noted that those networks operate GMPLS protocols in both the client and server networks, which facilitates smoother interworking. Where the client network uses MPLS-TE protocols over the GMPLS server network, there is a need to study the interworking of the two protocol sets.
正しくMPLSとGMPLSネットワークとのダイナミックな相互作用を管理して、オペレータがでしゃばることができるのが、操作上の要件とコントロールを理解するのに必要です。 この問題は[MLN-REQ]で説明されたマルチ層のネットワークと非常に同様ですが、それらのネットワークが両方のクライアントとサーバネットワークでGMPLSプロトコルを運用することに注意しなければなりません(より滑らかな織り込むことを容易にします)。 クライアントネットワークがGMPLSサーバネットワークの上でMPLS-TEプロトコルを使用するところに、2つのプロトコルセットを織り込むことを研究する必要があります。
Kumaki Informational [Page 3] RFC 5146 Operating MPLS-TE over GMPLS Networks March 2008
2008年3月にGMPLSネットワークの上でMPLS-Teを操作するKumakiの情報[3ページ]のRFC5146
This document examines the protocol requirements for protocol interworking to operate an MPLS-TE network as a client network over a GMPLS server network, and provides a framework for such operations.
このドキュメントは、クライアントネットワークとしてGMPLSサーバネットワークでMPLS-TEネットワークを経営するためにプロトコルの織り込むのがないかどうかプロトコル要件を調べて、そのような操作にフレームワークを提供します。
1.1. Terminology
1.1. 用語
Although this Informational document is not a protocol specification, The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] for clarity of exposure of the requirements.
このInformationalドキュメントはプロトコル仕様ではありませんが、キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは要件の暴露の明快ために[RFC2119]で説明されるように本書では解釈されることであるべきですか?
2. Reference Model
2. 規範モデル
The reference model used in this document is shown in Figure 1. It can easily be seen that the interworking between MPLS-TE and GMPLS protocols must occur on a node and not on a link. Nodes on the interface between the MPLS-TE and GMPLS networks must be responsible for handling both protocol sets and for providing any protocol interworking that is required. We call these nodes Border Routers.
本書では使用される規範モデルは図1で見せられます。 容易に、MPLS-TEとGMPLSプロトコルの間の織り込むことがリンクの上に起こるのではなく、ノードの上に起こらなければならないのを見ることができます。 MPLS-TEとGMPLSネットワークの間のインタフェースのノードは両方のプロトコルセットを扱って、必要であるプロトコルの織り込むことを提供するのに原因となるに違いありません。 私たちは、これらのノードをBorder Routersと呼びます。
-------------- ------------------------- -------------- | MPLS Client | | GMPLS Server Network | | MPLS Client | | Network | | | | Network | | | | | | | | ---- --+--+-- ----- ----- --+--+-- ---- | | | | | | | | | | | | | | | | |MPLS|_| Border |__|GMPLS|_|GMPLS|__| Border |_|MPLS| | | |LSR | | Router | | LSR | | LSR | | Router | |LSR | | | | | | | | | | | | | | | | | ---- --+--+-- ----- ----- --+--+-- ---- | | | | | | | | | | | | | -------------- ------------------------- --------------
-------------- ------------------------- -------------- | MPLSクライアント| | GMPLSサーバネットワーク| | MPLSクライアント| | ネットワーク| | | | ネットワーク| | | | | | | | ---- --+--+-- ----- ----- --+--+-- ---- | | | | | | | | | | | | | | | | |MPLS|_| 境界|__|GMPLS|_|GMPLS|__| 境界|_|MPLS| | | |LSR| | ルータ| | LSR| | LSR| | ルータ| |LSR| | | | | | | | | | | | | | | | | ---- --+--+-- ----- ----- --+--+-- ---- | | | | | | | | | | | | | -------------- ------------------------- --------------
| | GMPLS LSP | | | |<------------------------->| | | | |<--------------------------------------------->| End-to-End MPLS-TE LSP
| | GMPLS LSP| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| |<--------------------------------------------->| 終わりから終わりへのMPLS-Te LSP
Figure 1. Reference model of MPLS-TE/GMPLS interworking
図1。 MPLS-TE/GMPLSの織り込むことの規範モデル
MPLS-TE network connectivity is provided through a GMPLS LSP which is created between Border Routers. End-to-end connectivity between MPLS LSRs in the client MPLS-TE networks is provided by an MPLS-TE LSP that is carried across the MPLS-TE network by the GMPLS LSP using hierarchical LSP techniques [RFC4206], LSP stitching segments
Border Routersの間で作成されるGMPLS LSPを通してMPLS-TEネットワークの接続性を提供します。 クライアントMPLS-TEネットワークにおけるMPLS LSRsの間の終わりから終わりへの接続性はMPLS-TEネットワークの向こう側に階層的なLSPのテクニック[RFC4206]を使用することでGMPLS LSPによって運ばれるMPLS-TE LSPによって提供されます、LSPがセグメントをステッチして
Kumaki Informational [Page 4] RFC 5146 Operating MPLS-TE over GMPLS Networks March 2008
2008年3月にGMPLSネットワークの上でMPLS-Teを操作するKumakiの情報[4ページ]のRFC5146
[RFC5150], or a contiguous LSP. LSP stitching segments and contiguous LSPs are only available where the GMPLS network is a packet switching network.
[RFC5150]、または隣接のLSP。 セグメントをステッチするLSPと隣接のLSPsはGMPLSネットワークがパケット交換網であるところで利用可能であるだけです。
3. Detailed Requirements
3. 詳細な要件
This section describes detailed requirements for MPLS-TE/GMPLS interworking in support of the reference model shown in Figure 1.
このセクションは図1で見せられた規範モデルを支持したMPLS-TE/GMPLSの織り込む詳細な要件について説明します。
The functional requirements for GMPLS-MPLS interworking described in this section must be met by any device participating in the interworking. This may include routers, servers, network management devices, path computation elements, etc.
織り込むことに参加するどんなデバイスでもこのセクションで説明されたGMPLS-MPLSの織り込む機能条件書を満たさなければなりません。 これはルータ、サーバ、ネットワークマネージメントデバイス、経路計算要素などを含むかもしれません。
3.1. End-to-End Signaling
3.1. 終わりから終わりへのシグナリング
The solution MUST be able to preserve MPLS signaling information signaled within the MPLS-TE client network at the start of the MPLS- TE LSP and deliver it on the other side of the GMPLS server network for use within the MPLS-TE client network at the end of the MPLS-TE LSP. This may require protocol mapping (and re-mapping), protocol tunneling, or the use of remote protocol adjacencies.
ソリューションは、MPLS- TE LSPの始めにMPLS-TEクライアントネットワークの中で合図されたMPLSシグナリング情報を保存して、使用のためにMPLS-TE LSPの端でMPLS-TEクライアントネットワークの中でGMPLSサーバネットワークの反対側でそれを提供できなければなりません。 これはリモートプロトコル隣接番組のプロトコルマッピング(そして、再マッピング)、プロトコルトンネリング、または使用を必要とするかもしれません。
3.2. Triggered Establishment of GMPLS LSPs
3.2. GMPLS LSPsの引き起こされた設立
The solution MUST provide the ability to establish end-to-end MPLS-TE LSPs over a GMPLS server network. It SHOULD be possible for GMPLS LSPs across the core network to be set up between Border Routers triggered by the signaling of MPLS-TE LSPs in the client network, and in this case, policy controls MUST be made available at the border routers so that the operator of the GMPLS network can manage how core network resources are utilized. GMPLS LSPs MAY also be pre- established as the result of management plane control.
ソリューションはGMPLSサーバネットワークの上に終わりから終わりへのMPLS-TE LSPsを設立する能力を提供しなければなりません。 それ、SHOULD、コアネットワークの向こう側のGMPLS LSPsがクライアントネットワークと、この場合MPLS-TE LSPsのシグナリングによって引き起こされているBorder Routersの間でセットアップされるのにおいて可能です、GMPLSネットワークのオペレータがコアネットワーク資源がどう利用されているかに対処できるように方針コントロールを境界ルータで利用可能にしなければならないということになってください。 また、GMPLS LSPsは管理飛行機コントロールの結果とプレ書き立てられるかもしれません。
Note that multiple GMPLS LSPs may be set up between a given pair of Border Routers in support of connectivity in the MPLS client network. If these LSPs are advertised as TE links in the client network, the use of link bundling [RFC4201] can reduce any scaling concerns associated with the advertisements.
複数のGMPLS LSPsが与えられた組のBorder Routersの間でMPLSクライアントネットワークにおける接続性を支持してセットアップされるかもしれないことに注意してください。 TEがクライアントネットワークでリンクするときこれらのLSPsが広告に掲載されるなら、リンクバンドリング[RFC4201]の使用は広告に関連しているどんなスケーリング関心も減少させることができます。
The application of the Path Computation Element (PCE) [RFC4655] in the context of an inter-layer network [PCE-INT] may be considered to determine an end-to-end LSP with triggered GMPLS segment or tunnel.
相互ネットワーク[PCE-INT]層の文脈における、Path Computation Element(PCE)[RFC4655]のアプリケーションは、引き起こされたGMPLSセグメントがある終わりから終わりへのLSPを決定するか、またはトンネルを堀ると考えられるかもしれません。
Kumaki Informational [Page 5] RFC 5146 Operating MPLS-TE over GMPLS Networks March 2008
2008年3月にGMPLSネットワークの上でMPLS-Teを操作するKumakiの情報[5ページ]のRFC5146
3.3. Diverse Paths for End-to-End MPLS-TE LSPs
3.3. 終わりから終わりへのMPLS-Te LSPsに、さまざまの経路
The solution SHOULD provide the ability to establish end-to-end MPLS-TE LSPs having diverse paths for protection of the LSP traffic. This means that MPLS-TE LSPs SHOULD be kept diverse both within the client MPLS-TE network and as they cross the server GMPLS network. This means that there SHOULD be a mechanism to request the provision of diverse GMPLS LSPs between a pair of Border Routers to provide protection of the GMPLS span, but also that there SHOULD be a way to keep GMPLS LSPs between different Border Routers disjoint.
ソリューションSHOULDはLSPトラフィックの保護のために終わりから終わりへのさまざまの経路を持っているMPLS-TE LSPsを設立する能力を提供します。 これは、ともに、クライアントMPLS-TEネットワーク、それらがサーバGMPLSネットワークに交差しているようにMPLS-TE LSPs SHOULDがさまざまに保たれることを意味します。 これがそこでそれを意味する、SHOULD、しかし、GMPLSの長さの保護、それもそこに提供するよう1組のBorder Routersの間のさまざまのGMPLS LSPsの設備に要求するメカニズムがSHOULDであったなら、異なったBorder Routersの間のGMPLS LSPsがばらばらにならせる生活費への道になってください。
3.4. Advertisement of MPLS-TE Information via the GMPLS Network
3.4. GMPLS Networkを通したMPLS-TE情報の広告
The solution SHOULD provide the ability to exchange advertisements of TE information between MPLS-TE client networks across the GMPLS server network.
ソリューションSHOULDはGMPLSサーバネットワークの向こう側にMPLS-TEクライアントネットワークの間でTE情報の広告を交換する能力を提供します。
The advertisement of TE information from within an MPLS-TE client network to all LSRs in the client network enables a head-end LSR to compute an optimal path for an LSP to a tail-end LSR that is reached over the GMPLS server network.
クライアントネットワークにおける、TE情報のMPLS-TEクライアントネットワークからすべてのLSRsまでの広告はGMPLSサーバネットワークの上で達しているLSPのために末端に最適経路を計算するギヤエンドLSR LSRを有効にします。
Where there is more than one client MPLS-TE network, the TE information from separate MPLS-TE networks MUST be kept private, confidential and secure.
1つ以上のクライアントMPLS-TEネットワークがあるところでは、別々のMPLS-TEネットワークからのTE情報を個人的で、秘密で安全に保たなければなりません。
3.5. Selective Advertisement of MPLS-TE Information via a Border Node
3.5. Border Nodeを通したMPLS-TE情報の選択しているAdvertisement
The solution SHOULD provide the ability to distribute TE reachability information from the GMPLS server network to MPLS-TE networks selectively. This information is useful for the LSRs in the MPLS-TE networks to compute paths that cross the GMPLS server network and to select the correct Border Routers to provide connectivity.
ソリューションSHOULDはGMPLSサーバネットワークからMPLS-TEネットワークまで選択的にTE可到達性情報を分配する能力を提供します。 この情報は、MPLS-TEネットワークにおけるLSRsがGMPLSサーバネットワークに交差する経路を計算して、正しいBorder Routersが接続性を提供するのを選択するために役に立ちます。
The solution MUST NOT distribute TE information from within a non-PSC (Packet Switch Capable) GMPLS server network to any client MPLS-TE network as that information may cause confusion and selection of inappropriate paths.
その情報が不適当な経路の混乱と品揃えを引き起こすとき、ソリューションは非PSC(パケットSwitch Capable)GMPLSサーバネットワークからどんなクライアントMPLS-TEネットワークまでもTE情報を分配してはいけません。
The use of PCE [RFC4655] may provide a solution for non-PSC GMPLS networks supporting PSC MPLS networks.
PCE[RFC4655]の使用はPSC MPLSがネットワークであるとサポートする非PSC GMPLSネットワークに解決法を提供するかもしれません。
Kumaki Informational [Page 6] RFC 5146 Operating MPLS-TE over GMPLS Networks March 2008
2008年3月にGMPLSネットワークの上でMPLS-Teを操作するKumakiの情報[6ページ]のRFC5146
3.6. Interworking of MPLS-TE and GMPLS Protection
3.6. MPLS-TeとGMPLS保護を織り込むこと
If an MPLS-TE LSP is protected using MPLS Fast Reroute (FRR) [RFC4090], then similar protection MUST be provided over the GMPLS island. Operator and policy controls SHOULD be made available at the Border Router to determine how suitable protection is provided in the GMPLS island.
MPLS Fast Reroute(FRR)[RFC4090]を使用することでMPLS-TE LSPを保護するなら、GMPLS島の上に同様の保護を提供しなければなりません。 オペレータと方針はSHOULDを制御します。Border Routerで利用可能に作られていて、適当な保護がどのようにGMPLS島に提供されるか決定してください。
3.7. Independent Failure Recovery and Reoptimization
3.7. 独立している失敗の回復とReoptimization
The solution SHOULD provide failure recovery and reoptimization in the GMPLS server network without impacting the MPLS-TE client network and vice versa. That is, it SHOULD be possible to recover from a fault within the GMPLS island or to reoptimize the path across the GMPLS island without requiring signaling activity within the MPLS-TE client network. Similarly, it SHOULD be possible to perform recovery or reoptimization within the MPLS-TE client network without requiring signaling activity within the GMPLS server networks.
逆もまた同様にMPLS-TEクライアントネットワークに影響を与えないで、ソリューションSHOULDは失敗回復と「再-最適化」をGMPLSサーバネットワークに供給します。 それはそうであり、それはSHOULDです。GMPLS島の中の欠点から回復するか、またはGMPLS島の向こう側にMPLS-TEクライアントネットワークの中でシグナル伝達活性を必要としないで経路を再最適化するのにおいて、可能であってください。 同様である、それ、SHOULD、MPLS-TEクライアントネットワークの中でGMPLSサーバネットワークの中でシグナル伝達活性を必要としないで回復か「再-最適化」を実行するのにおいて、可能であってください。
If a failure in the GMPLS server network can not be repaired transparently, some kind of notification of the failure SHOULD be transmitted to MPLS-TE network.
GMPLSサーバネットワークにおける失敗がそうすることができるなら、透過的に修理されないでください、失敗SHOULDのある種の通知。MPLS-TEネットワークに伝えられます。
3.8. Complexity and Risks
3.8. 複雑さとリスク
The solution SHOULD NOT introduce unnecessary complexity to the current operating network to such a degree that it would affect the stability and diminish the benefits of deploying such a solution in service provider networks.
ソリューションSHOULD NOTは安定性に影響するくらいの度合いへの現在の操作ネットワークに不要な複雑さを紹介して、そのようなソリューションが使用中のプロバイダーネットワークであると配布する利益を減少させます。
3.9. Scalability Considerations
3.9. スケーラビリティ問題
The solution MUST scale well with consideration to at least the following metrics.
ソリューションは考慮で少なくとも以下の測定基準によく比例しなければなりません。
- The number of GMPLS-capable nodes (i.e., the size of the GMPLS server network).
- GMPLSできるノード(すなわち、GMPLSサーバネットワークのサイズ)の数。
- The number of MPLS-TE-capable nodes (i.e., the size of the MPLS-TE client network).
- MPLS-TEできるノード(すなわち、MPLS-TEクライアントネットワークのサイズ)の数。
- The number of MPLS-TE client networks.
- MPLS-TEクライアントネットワークの数。
- The number of GMPLS LSPs.
- GMPLS LSPsの数。
- The number of MPLS-TE LSPs.
- MPLS-TE LSPsの数。
Kumaki Informational [Page 7] RFC 5146 Operating MPLS-TE over GMPLS Networks March 2008
2008年3月にGMPLSネットワークの上でMPLS-Teを操作するKumakiの情報[7ページ]のRFC5146
3.10. Performance Considerations
3.10. パフォーマンス問題
The solution SHOULD be evaluated with regard to the following criteria.
ソリューションSHOULD、以下の評価基準に関して、評価されてください。
- Failure and restoration time.
- 失敗と回復時間。
- Impact and scalability of the control plane due to added overheads.
- 制御飛行機の影響とスケーラビリティは加えられたオーバーヘッドがそうします。
- Impact and scalability of the data/forwarding plane due to added overheads.
- データ/推進飛行機の影響とスケーラビリティは加えられたオーバーヘッドがそうします。
3.11. Management Considerations
3.11. 管理問題
Manageability of the deployment of an MPLS-TE client network over GMPLS server network MUST addresses the following considerations.
サーバネットワークがそうしなければならないGMPLSの上のMPLS-TEクライアントネットワークの展開の管理可能性は以下の問題を扱います。
- Need for coordination of MIB modules used for control plane management and monitoring in the client and server networks.
- コントロール飛行機管理に使用されて、クライアントとサーバでネットワークをモニターするMIBモジュールのコーディネートに必要です。
- Need for diagnostic tools that can discover and isolate faults across the border between the MPLS-TE client and GMPLS server networks.
- それが発見して、隔離できる診断用道具の必要性は横切ってMPLS-TEクライアントとGMPLSサーバネットワークとの境界をとがめます。
4. Security Considerations
4. セキュリティ問題
Border routers in the model described in this document are present on administrative domain boundaries. That is, the administrative boundary does not lie on a link as it might in the inter-Autonomous- System (inter-AS) case seen in IP networks. Thus, many security concerns for the inter-domain exchange of control plane messages do not arise in this model -- the border router participates fully in both the MPLS and the GMPLS network and must participate in the security procedures of both networks. Security considerations for MPLS-TE and GMPLS protocols are discussed in [SECURITY].
本書では説明されたモデルの境界ルータは管理ドメイン境界に存在しています。 すなわち、管理境界はIPネットワークで見られた相互Autonomousシステム(相互AS)場合で位置するかもしれないようにリンクの上に位置していません。 したがって、コントロール飛行機メッセージの相互ドメイン交換のための多くの安全上の配慮はこのモデルに起こりません--境界ルータは、MPLSとGMPLSネットワークの両方に完全に参加して、両方のネットワークのセキュリティ手順に参加しなければなりません。 [SECURITY]でMPLS-TEのためのセキュリティ問題とGMPLSプロトコルについて議論します。
However, policy considerations at the border routers are very important and may be considered to form part of the security of the networks. In particular, the server network (the GMPLS network) may wish to protect itself from behavior in the client network (such as frequent demands to set up and tear down server LSPs) by appropriate policies implemented at the border routers. It should be observed that, because the border routers form part of both networks, they are trusted in both networks, and policies configured (whether locally or centrally) for use by a border router are expected to be observed.
しかしながら、境界ルータにおける方針問題は、非常に重要であり、ネットワークのセキュリティの一部を形成すると考えられるかもしれません。 特に、サーバネットワーク(GMPLSネットワーク)は振舞いからクライアントネットワーク(サーバLSPsをセットアップして、取りこわすという頻繁な要求などの)で境界ルータで実施される適切な政策によって我が身をかばいたがっているかもしれません。 境界ルータが両方のネットワークの一部を形成するので、それらが両方のネットワークで信じられるのが観測されるべきであり、使用のために境界ルータによって構成された(局所的か中心であることにかかわらず)方針が観測されると予想されます。
Nevertheless, authentication and access controls for operators will be particularly important at border routers. Operators of the client
それにもかかわらず、オペレータのための認証とアクセス制御は境界ルータで重要に特になるでしょう。 クライアントのオペレータ
Kumaki Informational [Page 8] RFC 5146 Operating MPLS-TE over GMPLS Networks March 2008
2008年3月にGMPLSネットワークの上でMPLS-Teを操作するKumakiの情報[8ページ]のRFC5146
MPLS-TE network MUST NOT be allowed to configure the server GMPLS network (including setting server network policies), and operators of the server GMPLS network MUST NOT be able configure the client MPLS- TE network. Obviously, it SHOULD be possible to grant an operator privileges in both networks. It may also be desirable to give operators of one network access to (for example) status information about the other network.
ネットワークにGMPLSがネットワークでつないで(サーバネットワーク方針を設定するのを含んでいます)、サーバGMPLSのオペレータがネットワークでつなぐサーバができるはずがないのを構成させてはいけないMPLS-TEはクライアントMPLS- TEネットワークを構成します。 明らかにそれ、SHOULD、両方のネットワークで特権をオペレータに与えるのにおいて、可能であってください。 また、(例えば、)もう片方のネットワークの状態情報への1回のネットワークアクセスをオペレータに与えるのも望ましいかもしれません。
Mechanisms for authenticating operators and providing access controls are not part of the responsibilities of the GMPLS protocol set, and will depend on the management plane protocols and techniques implemented.
オペレータを認証して、アクセス制御を提供するためのメカニズムは、GMPLSプロトコルセットの責任の一部でなく、プロトコルとテクニックが実装した管理飛行機によるでしょう。
5. Recommended Solution Architecture
5. お勧めのソリューションアーキテクチャ
The recommended solution architecture to meet the requirements set out in Section 3 is known as the Border Peer Model. This architecture is a variant of the Augmented Model described in [RFC3945]. The remainder of this document presents an overview of this architecture.
セクション3を始められた必要条件を満たすお勧めのソリューションアーキテクチャはBorder Peer Modelとして知られています。 このアーキテクチャは[RFC3945]で説明されたAugmented Modelの異形です。 このドキュメントの残りはこのアーキテクチャの概要を提示します。
In the Augmented Model, routing information from the lower layer (server) network is filtered at the interface to the higher layer (client) network and a subset of the information is distributed within the higher layer network.
Augmented Modelでは、下層(サーバ)ネットワークからのルーティング情報はインタフェースで、より高い層の(クライアント)ネットワークにフィルターにかけられます、そして、情報の部分集合は、より高い層のネットワークの中で分配されます。
In the Border Peer Model, the interface between the client and server networks is the Border Router. This router has visibility of the routing information in the server network yet also participates as a peer in the client network. Thus, the Border Router has full visibility into both networks. However, the Border Router does not distribute server routing information into the client network, nor does it distribute client routing information into the server network.
Border Peer Modelでは、クライアントとサーバネットワークとのインタフェースはBorder Routerです。 このルータは、クライアントネットワークでネットワークでつなぎますが、また、サーバのルーティング情報の目に見えることが同輩として参加するのをさせます。 したがって、Border Routerは両方のネットワークに完全な目に見えることを持っています。 しかしながら、Border Routerはサーバルーティング情報をクライアントネットワークに分配しません、そして、それはクライアントルーティング情報をサーバネットワークに分配しません。
The Border Peer Model may also be contrasted with the Overlay Model [RFC3945]. In this model there is a protocol request/response interface (the user network interface (UNI)) between the client and server networks. [RFC4208] shows how this interface may be supported by GMPLS protocols operated between client edge and server edge routers while retaining the routing information within the server network. That is, in the Overlay Model there is no exchange of routing or reachability information between client and server networks, and no network element has visibility into both client and server networks. The Border Peer Model can be viewed as placing the UNI within the Border Router thus giving the Border Router peer capabilities in both the client and server network.
また、Border Peer ModelはOverlay Model[RFC3945]に対して対照されるかもしれません。 このモデルには、クライアントとサーバネットワークとのプロトコル要求/応答インタフェース(ユーザネットワーク・インターフェース(UNI))があります。 [RFC4208]はこのインタフェースがサーバネットワークの中でルーティング情報を保有している間にクライアント縁とサーバ縁のルータの間で操作されたGMPLSプロトコルによってどうサポートされるかもしれないかを示しています。 すなわち、Overlay Modelには、クライアントとサーバネットワークの間には、ルーティングか可到達性情報の交換が全くありません、そして、どんなネットワーク要素もクライアントとサーバネットワークの両方に目に見えることを持っていません。 両方のBorder Router同輩能力にクライアントとサーバネットワークを与えながら、その結果、Border Routerの中にUNIを置くとBorder Peer Modelを見なすことができます。
Kumaki Informational [Page 9] RFC 5146 Operating MPLS-TE over GMPLS Networks March 2008
2008年3月にGMPLSネットワークの上でMPLS-Teを操作するKumakiの情報[9ページ]のRFC5146
5.1. Use of Contiguous, Hierarchical, and Stitched LSPs
5.1. 隣接の、そして、階層的で、ステッチされたLSPsの使用
All three LSP types MAY be supported in the Border Peer Model, but contiguous LSPs are the hardest to support because they require protocol mapping between the MPLS-TE client network and the GMPLS server network. Such protocol mapping can be achieved currently since MPLS-TE signaling protocols are a subset of GMPLS, but this mechanism is not future-proofed.
すべての3つのLSPタイプがBorder Peer Modelでサポートされるかもしれませんが、彼らがMPLS-TEクライアントネットワークとGMPLSサーバネットワークの間でプロトコルマッピングを必要とするので、隣接のLSPsは最もサポートしにくいです。 MPLS-TEシグナリングプロトコルがGMPLSの部分集合であるので現在、そのようなプロトコルマッピングを達成できますが、このメカニズムは未来によって検査されていません。
Contiguous and stitched LSPs can only be supported where the GMPLS server network has the same switching type (that is, packet switching) as the MPLS-TE network. Requirements for independent failure recovery within the GMPLS island require the use of loose path reoptimization techniques [RFC4736] and end-to-end make-before- break [RFC3209], which will not provide rapid recovery.
GMPLSサーバネットワークにはMPLS-TEネットワークと同じ切り換えタイプ(すなわち、パケット交換)があるところで隣接の、そして、ステッチされたLSPsをサポートすることができるだけです。 GMPLS島の中の独立している失敗回復のための要件は-以前中断[RFC3209]をしているゆるい経路「再-最適化」のテクニック[RFC4736]と終わりから終わりの使用を必要とします。(終わりは急速な回復を供給しないでしょう)。
For these reasons, the use of hierarchical LSPs across the server network is RECOMMENDED for the Border Peer Model, but see the discussion of Fast Reroute protection in Section 5.3.
これらの理由で、サーバネットワークの向こう側の階層的なLSPsの使用はBorder Peer ModelのためのRECOMMENDEDですが、セクション5.3における、Fast Reroute保護の議論を見てください。
5.2. MPLS-TE Control Plane Connectivity
5.2. MPLS-Teコントロール飛行機の接続性
Control plane connectivity between MPLS-TE LSRs connected by a GMPLS island in the Border Peer Model MAY be provided by the control channels of the GMPLS network. If this is done, a tunneling mechanism (such as GRE [RFC2784]) SHOULD be used to ensure that MPLS-TE information is not consumed by the GMPLS LSRs. But care is required to avoid swamping the control plane of the GMPLS network with MPLS-TE control plane (particularly routing) messages.
Border Peer ModelのGMPLS島によって接続されたMPLS-TE LSRsの間のコントロール飛行機の接続性はGMPLSネットワークの制御チャンネルによって提供されるかもしれません。 これであるなら、されたaトンネリングはメカニズム(GRE[RFC2784]などの)SHOULDです。使用されて、GMPLS LSRsによって消費されて、MPLS-TE情報がないのを保証してください。 しかし、注意が、MPLS-TE制御飛行機(特にルーティング)メッセージでGMPLSネットワークの制御飛行機を浸すのを避けるのに必要です。
In order to ensure scalability, control plane messages for the MPLS- TE client network MAY be carried between Border Routers in a single hop MPLS-TE LSP routed through the data plane of the GMPLS server network.
スケーラビリティを確実にするために、MPLS- TEクライアントネットワークへのコントロール飛行機メッセージはMPLS-TE LSPがGMPLSサーバネットワークのデータ飛行機を通して発送した単一のホップでBorder Routersに伝えられるかもしれません。
5.3. Fast Reroute Protection
5.3. 速く保護を別ルートで送ってください。
If the GMPLS network is packet switching, Fast Reroute protection can be offered on all hops of a contiguous LSP. If the GMPLS network is packet switching then all hops of a hierarchical GMPLS LSP or GMPLS stitching segment can be protected using Fast Reroute. If the end- to-end MPLS-TE LSP requests Fast Reroute protection, the GMPLS packet switching network SHOULD provide such protection.
GMPLSネットワークがパケット交換であるなら、隣接のLSPのすべてのホップに対してはFast Reroute保護を提供できます。 GMPLSネットワークがパケット交換であるなら、Fast Rerouteを使用することでセグメントをステッチする階層的なGMPLS LSPかGMPLSのすべてのホップを保護できます。 終わりから終わりへのMPLS-TE LSPがFast Reroute保護を要求するなら、GMPLSパケット交換網SHOULDはそのような保護を提供します。
However, note that it is not possible to provide FRR node protection of the upstream Border Router without careful consideration of available paths, and protection of the downstream Border Router is not possible where hierarchical LSPs or stitching segments are used.
しかしながら、階層的なLSPsかセグメントをステッチするのが使用されているところで利用可能な経路の熟慮、および川下のBorder Routerの保護のない上流のBorder Routerのノード保護をFRRに供給するのが可能でないことが、可能でないことに注意してください。
Kumaki Informational [Page 10] RFC 5146 Operating MPLS-TE over GMPLS Networks March 2008
2008年3月にGMPLSネットワークの上でMPLS-Teを操作するKumakiの情報[10ページ]のRFC5146
Note further that Fast Reroute is not available in non-packet technologies. However, other protection techniques are supported by GMPLS for non-packet networks and are likely to provide similar levels of protection.
Fast Rerouteが非パケット技術で利用可能でないことにさらに注意してください。 しかしながら、他の保護のテクニックは、非パケット網のためにGMPLSによってサポートされて、同じ水準の保護を提供しそうです。
The limitations of FRR need careful consideration by the operator and may lead to the decision to provide end-to-end protection for the MPLS-TE LSP.
FRRの限界は、オペレータによる熟慮を必要として、終わりから終わりへの保護をMPLS-TE LSPに供給するという決定に通じるかもしれません。
5.4. GMPLS LSP Advertisement
5.4. GMPLS LSP広告
In the Border Peer Model, the LSPs established by the Border Routers in the GMPLS server network SHOULD be advertised in the MPLS-TE client network as real or virtual links. In case real links are advertised into the MPLS-TE client network, the Border Routers in the MPLS-TE client network MAY establish IGP neighbors. The Border Routers MAY automatically advertise the GMPLS LSPs when establishing them.
Border Peer Model、GMPLSサーバネットワークSHOULDのBorder Routersによって設立されたLSPsでは、本当の、または、仮想のリンクとしてMPLS-TEクライアントネットワークで広告を出してください。 本当のリンクがMPLS-TEクライアントネットワークに広告に掲載されるといけないので、MPLS-TEクライアントネットワークにおけるBorder RoutersはIGP隣人を設立するかもしれません。 彼らを設立するとき、Border Routersは自動的にGMPLS LSPsの広告を出すかもしれません。
5.5. GMPLS Deployment Considerations
5.5. GMPLS展開問題
The Border Peer Model does not require the existing MPLS-TE client network to be GMPLS aware and does not affect the operation and management of the existing MPLS-TE client network. Only border routers need to be upgraded with the GMPLS functionality. In this fashion, the Border Peer Model renders itself for incremental deployment of the GMPLS server network, without requiring reconfiguration of existing areas/ASs, changing operation of IGP and BGP or software upgrade of the existing MPLS-TE client network.
Border Peer Modelは既存のMPLS-TEクライアントネットワークがGMPLSであることが意識していた状態で必要でなく、また既存のMPLS-TEクライアントネットワークの操作と経営のふりをしません。 境界ルータだけが、GMPLSの機能性でアップグレードする必要があります。 こんなやり方で、Border Peer ModelはGMPLSサーバネットワークの増加の展開のためにそれ自体をレンダリングします、既存の領域/ASsの再構成を必要としないで、IGPとBGPの操作か既存のMPLS-TEクライアントネットワークのソフトウェアの更新を変えて。
6. Acknowledgments
6. 承認
The author would like to express thanks to Raymond Zhang, Adrian Farrel, and Deborah Brungard for their helpful and useful comments and feedback.
作者はレイモンド・チャン、エードリアン・ファレル、およびデボラのおかげでそれらの役立っていて役に立つコメントとフィードバックのためにBrungardを急送したがっています。
7. References
7. 参照
7.1. Normative References
7.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月。
Kumaki Informational [Page 11] RFC 5146 Operating MPLS-TE over GMPLS Networks March 2008
2008年3月にGMPLSネットワークの上でMPLS-Teを操作するKumakiの情報[11ページ]のRFC5146
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945] エドマニー、E.、RFC3945、「一般化されたマルチプロトコルラベルは(GMPLS)構造を切り換えること」での10月2004日
[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
[RFC4090]なべ、P.(エド)、ツバメ、G.(エド)、およびA.Atlas(エド)は「LSP Tunnelsのために速くRSVP-Teに拡大を別ルートで送ります」、RFC4090、2005年5月。
[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
[RFC4201]Kompella、K.、Rekhter、Y.、およびL.バーガー、「MPLS交通工学(Te)におけるリンクバンドリング」、RFC4201、2005年10月。
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
[RFC4206]Kompella(K.とY.Rekhter)は「一般化されたマルチプロトコルラベルスイッチング(GMPLS)交通工学(Te)で切り換えられた経路(LSP)を階層構造とラベルします」、RFC4206、2005年10月。
[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, "Generalized Multiprotocol Label Switching (GMPLS) User- Network Interface (UNI): Resource ReserVation Protocol- Traffic Engineering (RSVP-TE) Support for the Overlay Model", RFC 4208, October 2005.
[RFC4208] ツバメ、G.、ドレイク、J.、Ishimatsu、H.、およびY.Rekhter、「一般化されたMultiprotocolはユーザネットワーク・インターフェース(UNI)と切り換え(GMPLS)をラベルします」。 「オーバレイモデルの資源予約プロトコル交通工学(RSVP-Te)サポート」、RFC4208、2005年10月。
[RFC5150] Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel, "Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE)", RFC 5150, February 2008.
[RFC5150]Ayyangar(A.、Kompella、K.、Vasseur(JP)、およびA.ファレル)は「一般化されたMultiprotocolラベル切り換え交通工学(GMPLS Te)でステッチされる切り換えられた経路をラベルします」、RFC5150、2008年2月。
7.2. Informative References
7.2. 有益な参照
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
2000年3月の[RFC2784]ファリナッチとD.と李とT.とハンクスとS.とマイヤー、D.とP.Traina、「一般ルーティングのカプセル化(GRE)」RFC2784。
[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月。
[RFC4736] Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "Reoptimization of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Loosely Routed Label Switched Path (LSP)", RFC 4736, November 2006.
[RFC4736]Vasseur(JP)、エド、Ikejiri、Y.、およびR.チャン、「Multiprotocolラベルの切り換え(MPLS)交通工学(Te)のReoptimizationは緩くラベルの切り換えられた経路(LSP)を発送しました」、RFC4736、11月2006
[RFC5145] Shiomoto, K., Ed., "Framework for MPLS-TE to GMPLS Migration", RFC 5145, March 2008.
[RFC5145] Shiomoto、K.、エド、「GMPLS移動へのMPLS-Teのための枠組み」、RFC5145、3月2008日
Kumaki Informational [Page 12] RFC 5146 Operating MPLS-TE over GMPLS Networks March 2008
2008年3月にGMPLSネットワークの上でMPLS-Teを操作するKumakiの情報[12ページ]のRFC5146
[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] Shiomoto、K.、Papadimitriou、D.、ル・ルー、J.L.、ビグルー、M.、D.Brungard、「GMPLSのための要件はマルチ領域の、そして、マルチ層のネットワーク(MRN/百万)を基礎づけたこと」は進行中(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月)で働いています。
[SECURITY] Fang, L., "Security Framework for MPLS and GMPLS Networks", Work in Progress, November 2007.
[セキュリティ] 牙、L.、「MPLSとGMPLSネットワークのためのセキュリティフレームワーク」が進歩、2007年11月に働いています。
8. Contributors' Addresses
8. 貢献者のアドレス
Tomohiro Otani KDDI R&D Laboratories, Inc. 2-1-15 Ohara Kamifukuoka Saitama, 356-8502, Japan
智宏オータニKDDI研究開発研究所Inc.2-1-15Ohara埼玉上福岡、356-8502日本
Phone: +81-49-278-7357 EMail: otani@kddilabs.jp
以下に電話をしてください。 +81-49-278-7357 メールしてください: otani@kddilabs.jp
Shuichi Okamoto NICT JGN II Tsukuba Reserach Center 1-8-1, Otemachi Chiyoda-ku, Tokyo, 100-0004, Japan
NICT JGN II筑波のReserachセンター1-8-1、千代田区大手町、Shuichi東京岡本100-0004(日本)
Phone: +81-3-5200-2117 EMail: okamoto-s@nict.go.jp
以下に電話をしてください。 +81-3-5200-2117 メールしてください: okamoto-s@nict.go.jp
Kazuhiro Fujihara NTT Communications Corporation Tokyo Opera City Tower 3-20-2 Nishi Shinjuku, Shinjuku-ku Tokyo 163-1421, Japan
新宿、Fujihara NTTコミュニケーションズ株式会社の東京オペラ市の西新宿区東京日本の塔3-20-2一浩163-1421
EMail: kazuhiro.fujihara@ntt.com
メール: kazuhiro.fujihara@ntt.com
Yuichi Ikejiri NTT Communications Corporation Tokyo Opera City Tower 3-20-2 Nishi Shinjuku, Shinjuku-ku Tokyo 163-1421, Japan
新宿、Yuichi Ikejiri NTTコミュニケーションズ株式会社オペラ市の西新宿区東京日本塔3-20-2東京163-1421
EMail: y.ikejiri@ntt.com
メール: y.ikejiri@ntt.com
Kumaki Informational [Page 13] RFC 5146 Operating MPLS-TE over GMPLS Networks March 2008
2008年3月にGMPLSネットワークの上でMPLS-Teを操作するKumakiの情報[13ページ]のRFC5146
Editor's Address
エディタのアドレス
Kenji Kumaki KDDI Corporation Garden Air Tower Iidabashi, Chiyoda-ku, Tokyo, 102-8460, JAPAN
Kenji Kumaki KDDI社の庭の空気Tower飯田橋、千代田区、東京102-8460(日本)
EMail: ke-kumaki@kddi.com
メール: ke-kumaki@kddi.com
Kumaki Informational [Page 14] RFC 5146 Operating MPLS-TE over GMPLS Networks March 2008
2008年3月にGMPLSネットワークの上でMPLS-Teを操作するKumakiの情報[14ページ]のRFC5146
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に情報を記述してください。
Kumaki Informational [Page 15]
Kumaki情報です。[15ページ]
一覧
スポンサーリンク