RFC3717 日本語訳
3717 IP over Optical Networks: A Framework. B. Rajagopalan, J.Luciani, D. Awduche. March 2004. (Format: TXT=124421 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group B. Rajagopalan
Request for Comments: 3717 Consultant
Category: Informational J. Luciani
Marconi Communications
D. Awduche
MCI
March 2004
Rajagopalanがコメントのために要求するワーキンググループB.をネットワークでつないでください: 3717年のコンサルタントカテゴリ: 2004年の情報のJ.のマルコニーのコミュニケーションD.Awduche MCI Luciani行進
IP over Optical Networks: A Framework
光学の上のIPは以下をネットワークでつなぎます。 フレームワーク
Status of this Memo
この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.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2004). All Rights Reserved.
Copyright(C)インターネット協会(2004)。 All rights reserved。
Abstract
要約
The Internet transport infrastructure is moving towards a model of high-speed routers interconnected by optical core networks. The architectural choices for the interaction between IP and optical network layers, specifically, the routing and signaling aspects, are maturing. At the same time, a consensus has emerged in the industry on utilizing IP-based protocols for the optical control plane. This document defines a framework for IP over Optical networks, considering both the IP-based control plane for optical networks as well as IP-optical network interactions (together referred to as "IP over optical networks").
インターネット輸送インフラは光学コアネットワークによってインタコネクトされた高速ルータのモデルに近づいています。 IPと光学ネットワーク層との相互作用のための建築選択(明確にルーティングとシグナリング局面)は、熟しています。 同時に、光学制御飛行機にIPベースのプロトコルを利用するとき、コンセンサスは産業で現れました。 このドキュメントはIPのためにOpticalネットワークの上でフレームワークを定義します、IP光学のネットワーク相互作用と同様に光学ネットワークのために両方がIPベースの制御飛行機であると考える場合(一緒にいる、「光学ネットワークの上のIP」と呼ばれる、)
Rajagopalan, et al. Informational [Page 1] RFC 3717 IP over Optical Networks: A Framework March 2004
Rajagopalan、他 光学ネットワークの上の情報[1ページ]のRFC3717IP: 2004年のフレームワーク行進
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Concepts . . . . . . . . . . . . . . . . . . . 4
3. The Network Model. . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Network Interconnection. . . . . . . . . . . . . . . . . 8
3.2. Control Structure. . . . . . . . . . . . . . . . . . . . 11
4. IP over Optical Service Models and Requirements. . . . . . . . 13
4.1. Domain Services Model. . . . . . . . . . . . . . . . . . 13
4.2. Unified Service Model. . . . . . . . . . . . . . . . . . 14
4.3. Which Service Model? . . . . . . . . . . . . . . . . . . 15
4.4. What are the Possible Services?. . . . . . . . . . . . . 16
5. IP transport over Optical Networks . . . . . . . . . . . . . . 16
5.1. Interconnection Models . . . . . . . . . . . . . . . . . 17
5.2. Routing Approaches . . . . . . . . . . . . . . . . . . . 18
5.3. Signaling-Related. . . . . . . . . . . . . . . . . . . . 21
5.4. End-to-End Protection Models . . . . . . . . . . . . . . 23
6. IP-based Optical Control Plane Issues. . . . . . . . . . . . . 25
6.1. Addressing . . . . . . . . . . . . . . . . . . . . . . . 25
6.2. Neighbor Discovery . . . . . . . . . . . . . . . . . . . 27
6.3. Topology Discovery . . . . . . . . . . . . . . . . . . . 28
6.4. Protection and Restoration Models. . . . . . . . . . . . 29
6.5. Route Computation. . . . . . . . . . . . . . . . . . . . 30
6.6. Signaling Issues . . . . . . . . . . . . . . . . . . . . 32
6.7. Optical Internetworking. . . . . . . . . . . . . . . . . 34
7. Other Issues . . . . . . . . . . . . . . . . . . . . . . . . . 35
7.1. WDM and TDM in the Same Network. . . . . . . . . . . . . 35
7.2. Wavelength Conversion. . . . . . . . . . . . . . . . . . 36
7.3. Service Provider Peering Points. . . . . . . . . . . . . 36
7.4. Rate of Lightpath Set-Up . . . . . . . . . . . . . . . . 36
7.5. Distributed vs. Centralized Provisioning . . . . . . . . 37
7.6. Optical Networks with Additional Configurable
Components . . . . . . . . . . . . . . . . . . . . . . . 38
7.7. Optical Networks with Limited Wavelength Conversion
Capability . . . . . . . . . . . . . . . . . . . . . . . 38
8. Evolution Path for IP over Optical Architecture. . . . . . . . 39
9. Security Considerations. . . . . . . . . . . . . . . . . . . . 41
9.1. General Security Aspects . . . . . . . . . . . . . . . . 42
9.2. Security Considerations for Protocol Mechanisms. . . . . 43
10. Summary and Conclusions. . . . . . . . . . . . . . . . . . . . 44
11. Informative References . . . . . . . . . . . . . . . . . . . . 44
12. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 45
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 46
14. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 47
15. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 48
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 2。 用語と概念. . . . . . . . . . . . . . . . . . . 4 3。 ネットワークモデル。 . . . . . . . . . . . . . . . . . . . . . . 8 3.1. インタコネクトをネットワークでつないでください。 . . . . . . . . . . . . . . . . 8 3.2. 構造を制御してください。 . . . . . . . . . . . . . . . . . . . 11 4. 光学サービスモデルと要件の上のIP。 . . . . . . . 13 4.1. ドメインサービスはモデル化されます。 . . . . . . . . . . . . . . . . . 13 4.2. 統一されたサービスモデル。 . . . . . . . . . . . . . . . . . 14 4.3. どのサービスがモデル化されますか? . . . . . . . . . . . . . . . . . . 15 4.4. Possible Servicesは.165に何です。 Optical Networks. . . . . . . . . . . . . . 16 5.1の上のIP輸送。 インタコネクトは.175.2をモデル化します。 アプローチ. . . . . . . . . . . . . . . . . . . 18 5.3を発送します。 シグナリング関連です。 . . . . . . . . . . . . . . . . . . . 21 5.4. 終わりから終わりへの保護は.236をモデル化します。 IPベースの光学コントロール飛行機問題。 . . . . . . . . . . . . 25 6.1. .256.2を扱います。 隣人発見. . . . . . . . . . . . . . . . . . . 27 6.3。 トポロジー発見. . . . . . . . . . . . . . . . . . . 28 6.4。 保護と王政復古モデル。 . . . . . . . . . . . 29 6.5. 計算を発送してください。 . . . . . . . . . . . . . . . . . . . 30 6.6. 問題. . . . . . . . . . . . . . . . . . . . 32 6.7に合図します。 光学インターネットワーキング。 . . . . . . . . . . . . . . . . 34 7. 他の問題. . . . . . . . . . . . . . . . . . . . . . . . . 35 7.1。 同じネットワークにおけるWDMとTDM。 . . . . . . . . . . . . 35 7.2. 波長変換。 . . . . . . . . . . . . . . . . . 36 7.3. サービスプロバイダーのじっと見ることは指します。 . . . . . . . . . . . . 36 7.4. Lightpathセットアップ. . . . . . . . . . . . . . . . 36 7.5の速度。 集結された食糧を供給. . . . . . . . 37 7.6することに対して分配されています。 追加構成可能なコンポーネント. . . . . . . . . . . . . . . . . . . . . . . 38 7.7がある光学ネットワーク。 株式会社波長変換能力. . . . . . . . . . . . . . . . . . . . . . . 38 8がある光学ネットワーク。 光学アーキテクチャの上のIPのための発展経路。 . . . . . . . 39 9. セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 41 9.1. 総合証券局面. . . . . . . . . . . . . . . . 42 9.2。 プロトコルメカニズムのためのセキュリティ問題… 43 10。 概要と結論。 . . . . . . . . . . . . . . . . . . . 44 11. 有益な参照. . . . . . . . . . . . . . . . . . . . 44 12。 承認。 . . . . . . . . . . . . . . . . . . . . . . . 45 13. 貢献者. . . . . . . . . . . . . . . . . . . . . . . . . 46 14。 作者のアドレス. . . . . . . . . . . . . . . . . . . . . . 47 15。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 48
Rajagopalan, et al. Informational [Page 2] RFC 3717 IP over Optical Networks: A Framework March 2004
Rajagopalan、他 光学ネットワークの上の情報[2ページ]のRFC3717IP: 2004年のフレームワーク行進
1. Introduction
1. 序論
Optical network technologies are evolving rapidly in terms of functions and capabilities. The increasing importance of optical networks is evidenced by the copious amount of attention focused on IP over optical networks and related photonic and electronic interworking issues by all major network service providers, telecommunications equipment vendors, and standards organizations. In this regard, the term "optical network" is used generically in practice to refer to both SONET/SDH-based transport networks, as well as switched optical networks (including all-optical networks).
光学ネットワーク技術は機能と能力に関して急速に発達することです。 光学ネットワークの増加する重要性は光学ネットワークの上でIPに焦点を合わせられた豊富な量の注意で証明されます、そして、関連するフォトニックの、そして、電子の織り込むのはすべての主要なネットワークでサービスプロバイダー、通信機器ベンダー、および規格組織を発行します。 この点で、「光学ネットワーク」という用語は両方のSDH Sonet/を拠点とする転送ネットワークを示すのに実際には一般的に使用されます、切り換えられた光学ネットワークと同様に(オール光学のネットワークを含んでいて)。
It has been realized that optical networks must be survivable, flexible, and controllable. There is, therefore, an ongoing trend to introduce intelligence in the control plane of optical networks to make them more versatile [1]. An essential attribute of intelligent optical networks is the capability to instantiate and route optical layer connections in real-time or near real-time, and to provide capabilities that enhance network survivability. Furthermore, there is a need for multi-vendor optical network interoperability, when an optical network may consist of interconnected vendor-specific optical sub-networks.
光学ネットワークが生存可能で、フレキシブルで、制御可能であるに違いないと実感されました。 したがって、それらをより多能な[1]にするように光学ネットワークの制御飛行機で知性を導入するために、進行中の傾向があります。 知的な光学ネットワークの不可欠の属性はリアルタイムでか近いところでリアルタイムで状態で光の層の接続を例示して、発送して、ネットワークの生存性を高める能力を提供する能力です。 その上、マルチベンダの光学ネットワーク相互運用性の必要があります、光学ネットワークがインタコネクトされたベンダー特有の光学サブネットワークから成るかもしれないなら。
The optical network must also be versatile because some service providers may offer generic optical layer services that may not be client-specific. It would therefore be necessary to have an optical network control plane that can handle such generic optical services.
また、いくつかのサービスプロバイダーがクライアント特有でないかもしれないジェネリック光の層のサービスを提供するかもしれないので、光学ネットワークも多能であるに違いありません。 したがって、そのようなジェネリックの光のサービスを扱うことができる光学ネットワーク制御飛行機を持つのが必要でしょう。
There is general consensus in the industry that the optical network control plane should utilize IP-based protocols for dynamic provisioning and restoration of optical channels within and across optical sub-networks. This is based on the practical view that signaling and routing mechanisms developed for IP traffic engineering applications could be re-used in optical networks. Nevertheless, the issues and requirements that are specific to optical networking must be understood to suitably adopt and adapt the IP-based protocols. This is especially the case for restoration, and for routing and signaling in all-optical networks. Also, there are different views on the model for interaction between the optical network and client networks, such as IP networks. Reasonable architectural alternatives in this regard must be supported, with an understanding of their relative merits.
光学ネットワーク制御飛行機がサブネットワーク以内と光学サブネットワークの向こう側に光学チャンネルのダイナミックな食糧を供給するのと修復にIPベースのプロトコルを利用するはずであるという産業における全体的な合意があります。 これはIP交通工学アプリケーションのために開発されたシグナリングとルーティングメカニズムが光学ネットワークに再使用されるかもしれないという実用的な意見に基づいています。 それにもかかわらず、適当にIPベースのプロトコルを採用して、適合させるのを光のネットワークに特定の問題と要件を、理解しなければなりません。 これは特にオール光学のネットワークにおける回復、ルーティング、およびシグナリングのためのそうです。 また、光学ネットワークとクライアントネットワークの間には、相互作用のためのモデルに関する異なった意見があります、IPネットワークなどのように。 それらの優劣の理解でこの点で合理的な建築代替手段をサポートしなければなりません。
Thus, there are two fundamental issues related to IP over optical networks. The first is the adaptation and reuse of IP control plane protocols within the optical network control plane, irrespective of the types of digital clients that utilize the optical network. The
したがって、光学ネットワークの上でIPに関連する2つの基本的な問題があります。 1番目は、光学ネットワーク制御飛行機の中のIP規制飛行機プロトコルの適合と再利用です、光学ネットワークを利用するデジタルクライアントのタイプの如何にかかわらず。 The
Rajagopalan, et al. Informational [Page 3] RFC 3717 IP over Optical Networks: A Framework March 2004
Rajagopalan、他 光学ネットワークの上の情報[3ページ]のRFC3717IP: 2004年のフレームワーク行進
second is the transport of IP traffic through an optical network together with the control and coordination issues that arise therefrom.
2番目に、光学ネットワークを通してIPトラフィックの輸送がそこから起こるコントロールとコーディネート問題と共にあります。
This document defines a framework for IP over optical networks covering the requirements and mechanisms for establishing an IP- centric optical control plane, and the architectural aspects of IP transport over optical networks. In this regard, it is recognized that the specific capabilities required for IP over optical networks would depend on the services expected at the IP-optical interface as well as the optical sub-network interfaces. Depending on the specific operational requirements, a progression of capabilities is possible, reflecting increasingly sophisticated interactions at these interfaces. This document therefore advocates the definition of "capability sets" that define the evolution of functionality at the interfaces as more sophisticated operational requirements arise.
このドキュメントはIPのためにIPの中心の光学制御飛行機を設立するために要件とメカニズムを含んでいる光学ネットワーク、および光学ネットワークの上のIP輸送の建築局面についてフレームワークを定義します。 この点で、IPに光学ネットワークに関して必要である特定の能力が光学サブネットワークインタフェースと同様にIP光学のインタフェースで予想されたサービスによると認められます。 特定の操作上の要件によって、これらのインタフェースでますます洗練された相互作用を反映して、能力の進行は可能です。 したがって、より洗練された操作上の要件が起こるとき、このドキュメントはインタフェースにおける機能性の発展を定義する「能力セット」の定義を支持します。
This document is organized as follows. In the next section, terminology covering some basic concepts related to this framework are described. The definitions are specific to this framework and may have other connotations elsewhere. In Section 3, the network model pertinent to this framework is described. The service model and requirements for IP-optical, and multi-vendor optical internetworking are described in Section 4. This section also considers some general requirements. Section 5 considers the architectural models for IP-optical interworking, describing the relative merits of each model. It should be noted that it is not the intent of this document to promote any particular model over the others. However, particular aspects of the models that may make one approach more appropriate than another in certain circumstances are described. Section 6 describes IP-centric control plane mechanisms for optical networks, covering signaling and routing issues in support of provisioning and restoration. The approaches described in Section 5 and 6 range from the relatively simple to the sophisticated. Section 7 describes a number of specialized issues in relation to IP over optical networks. Section 8 describes a possible evolution path for IP over optical networking capabilities in terms of increasingly sophisticated functionality that may be supported as the need arises. Section 9 considers security issues pertinent to this framework. Finally, the summary and conclusion are presented in Section 10.
このドキュメントは以下の通りまとめられます。 次のセクション、いくつかをカバーする用語で、このフレームワークに関連する基本概念は説明されます。 定義は、このフレームワークに特定であり、ほかの場所に他の含蓄を持っているかもしれません。 セクション3では、このフレームワークに適切なネットワークモデルは説明されます。 IP光学とマルチベンダの光学インターネットワーキングのためのサービスモデルと要件はセクション4で説明されます。 また、このセクションはいくつかの一般的な要件を考えます。 それぞれのモデルの優劣について説明して、セクション5はIP光学の織り込むために建築モデルを考えます。 他のものの上でどんな特定のモデルも昇進させるのが、このドキュメントの意図でないことに注意されるべきです。 しかしながら、1つのアプローチを別のものより適切にするかもしれないモデルの特定の局面はある特定の状況では説明されます。 セクション6は光学ネットワークのためにIP中心の制御飛行機メカニズムについて説明します、食糧を供給するのと回復を支持してシグナリングとルーティング問題を含んでいて。 セクション5と6で説明されたアプローチは比較的簡単から洗練まで及びます。 セクション7は光学ネットワークの上のIPと関連して多くの専門化している問題について説明します。 セクション8はIPのために光学ネットワーク能力の上で必要に応じてサポートされるかもしれないますます洗練された機能性に関して可能な発展経路について説明します。 セクション9は、安全保障問題がこのフレームワークに適切であると考えます。 最終的に、概要と結論はセクション10に提示されます。
2. Terminology and Concepts
2. 用語と概念
This section introduces terminology pertinent to this framework and some related concepts. The definitions are specific to this framework and may have other interpretations elsewhere.
このセクションはこのフレームワークといくつかの関連する概念に適切な用語を紹介します。 定義は、このフレームワークに特定であり、ほかの場所に他の解釈を持っているかもしれません。
Rajagopalan, et al. Informational [Page 4] RFC 3717 IP over Optical Networks: A Framework March 2004
Rajagopalan、他 光学ネットワークの上の情報[4ページ]のRFC3717IP: 2004年のフレームワーク行進
WDM
WDM
Wavelength Division Multiplexing (WDM) is a technology that allows multiple optical signals operating at different wavelengths to be multiplexed onto a single optical fiber and transported in parallel through the fiber. In general, each optical wavelength may carry digital client payloads at a different data rate (e.g., OC-3c, OC- 12c, OC- 48c, OC-192c, etc.) and in a different format (SONET, Ethernet, ATM, etc.). For example, there are many commercial WDM networks in existence today that support a mix of SONET signals operating at OC-48c (approximately 2.5 Gbps) and OC-192 (approximately 10 Gbps) over a single optical fiber. An optical system with WDM capability can achieve parallel transmission of multiple wavelengths gracefully while maintaining high system performance and reliability. In the near future, commercial dense WDM systems are expected to concurrently carry more than 160 wavelengths at data rates of OC-192c and above, for a total of 1.6 Tbps or more. The term WDM will be used in this document to refer to both WDM and DWDM (Dense WDM).
波長事業部Multiplexing(WDM)は異なった波長で作動する複数の光学信号が単一の光ファイバに多重送信されて、ファイバーを通して平行に輸送されるのを許容する技術です。 一般に、それぞれの光学波長は異なったデータ信号速度(例えば、OC-3c、OC12c、OC48c、OC-192cなど)において異なった形式(Sonet、イーサネット、ATMなど)でデジタルクライアントペイロードを運ぶかもしれません。 例えば、単一の光ファイバの上にOC-48c(およそ2.5Gbps)とOC-192(およそ10Gbps)で作動するSonet信号のミックスをサポートする今日現存する多くの商業WDMネットワークがあります。 WDM能力がある光学系は高いシステム性能と信頼性を維持している間、優雅に複数の波長の並列伝送を実現できます。 近い将来、市販の濃いWDMシステムは、同時にOC-192cのデータ信号速度における160以上の波長を運ぶと予想されて、上です、合計1.6Tbpsのために。 WDMという用語は、WDMとDWDMの両方(濃いWDM)について言及するのに本書では使用されるでしょう。
In general, it is worth noting that WDM links are affected by the following factors, which may introduce impairments into the optical signal path:
一般に、WDMリンクが光学信号経路に損傷を取り入れるかもしれない以下の要素で影響を受けることに注意する価値があります:
1. The number of wavelengths on a single fiber.
2. The serial bit rate per wavelength.
3. The type of fiber.
4. The amplification mechanism.
5. The number and type of nodes through which the signals pass before
reaching the egress node or before regeneration.
1. 単一のファイバーの波長の数。 2. シリーズは1波長あたりのレートに噛み付きました。 3. ファイバーのタイプ。 4. 増幅メカニズム。 5. 信号が出口ノードに達する前か再生の前に通るノードの数とタイプ。
All these factors (and others not mentioned here) constitute domain specific features of optical transport networks. As noted in [1], these features should be taken into account in developing standards based solutions for IP over optical networks.
これらのすべての要素(そして、ここに言及されなかった他のもの)が光学転送ネットワークのドメインの特定の機能を構成します。 [1]に述べられるように、これらの特徴は光学ネットワークの上のIPのための規格が基礎づけた開発におけるアカウントに連れていかれたソリューションを述べられるべきです。
Optical cross-connect (OXC)
光学十字接続(OXC)
An OXC is a space-division switch that can switch an optical data stream from an input port to a output port. Such a switch may utilize optical-electrical conversion at the input port and electrical-optical conversion at the output port, or it may be all- optical. An OXC is assumed to have a control-plane processor that implements the signaling and routing protocols necessary for computing and instantiating optical channel connectivity in the optical domain.
OXCは入力ポートから出力ポートに光のデータ・ストリームを切り換えることができるスペース分割スイッチです。 そのようなスイッチが入力ポートと電気的に光の変換のときに出力ポートで光学的に電気の変換を利用するかもしれませんか、またはそれはオール光学であるかもしれません。 OXCにはシグナリングとルーティングが光学ドメインに光学チャンネルの接続性を計算して、例示するのに必要なプロトコルであると実装する制御飛行機プロセッサがあると思われます。
Rajagopalan, et al. Informational [Page 5] RFC 3717 IP over Optical Networks: A Framework March 2004
Rajagopalan、他 光学ネットワークの上の情報[5ページ]のRFC3717IP: 2004年のフレームワーク行進
Optical channel trail or Lightpath
光学チャンネル道かLightpath
An optical channel trail is a point-to-point optical layer connection between two access points in an optical network. In this document, the term "lightpath" is used interchangeably with optical channel trail.
光学チャンネル道は光学ネットワークにおける2つのアクセスポイントの間の二地点間光の層の接続です。 本書では、"lightpath"という用語は光学チャンネル道と共に互換性を持って使用されます。
Optical mesh sub-network
光学メッシュサブネットワーク
An optical sub-network, as used in this framework, is a network of OXCs that supports end-to-end networking of optical channel trails providing functionality like routing, monitoring, grooming, and protection and restoration of optical channels. The interconnection of OXCs in this network can be based on a general mesh topology. The following sub-layers may be associated with this network:
このフレームワークに使用される光学サブネットワークは光学チャンネルのルーティングのように機能性を提供する光学チャンネル道の終わりから終わりへのネットワーク、モニター、グルーミング、保護、および修復をサポートするOXCsのネットワークです。 このネットワークにおけるOXCsのインタコネクトは一般的なメッシュトポロジーに基づくことができます。 以下の副層はこのネットワークに関連しているかもしれません:
(a) An optical multiplex section (OMS) layer network: The optical
multiplex section layer provides transport for the optical
channels. The information contained in this layer is a data
stream comprising a set of optical channels, which may have a
defined aggregate bandwidth.
(a) 光学マルチプレックス部分(OMS)層のネットワーク: 光学マルチプレックスセクション層は光学チャンネルのための輸送を提供します。 この層に含まれた情報は1セットの光学チャンネルを包括するデータ・ストリームです。(そのデータ・ストリームには、定義された集合帯域幅があるかもしれません)。
(b) An optical transmission section (OTS) layer network: This layer
provides functionality for transmission of optical signals
through different types of optical media.
(b) 光伝送部(OTS)の層のネットワーク: この層は異なったタイプの光のメディアによる光学信号の伝達のための機能性を提供します。
This framework does not address the interaction between the optical sub-network and the OMS, or between the OMS and OTS layer networks.
このフレームワークは光学サブネットワークとOMSか、OMSとOTS層のネットワークとの相互作用を扱いません。
Mesh optical network (or simply, "optical network")
光学ネットワークを網の目にかけてください。(または、単に「光学ネットワーク」)
A mesh optical network, as used in document, is a topologically connected collection of optical sub-networks whose node degree may exceed 2. Such an optical network is assumed to be under the purview of a single administrative entity. It is also possible to conceive of a large scale global mesh optical network consisting of the voluntary interconnection of autonomous optical networks, each of which is owned and administered by an independent entity. In such an environment, abstraction can be used to hide the internal details of each autonomous optical cloud from external clouds.
ドキュメントで使用されるメッシュの光学ネットワークはaが収集を位相的に接続したということです。ノード度合いが2を超えるかもしれない光学サブネットワークについて。 そのような光学ネットワークがただ一つの管理実体の範囲の下にあると思われます。 また、自治の光学ネットワークの自発的のインタコネクトからそれぞれ成るそれの光学ネットワークが独立実体によって所有されて、管理される大規模グローバルなメッシュを想像するのも可能です。 そのような環境で、外部の雲からそれぞれの自治の光学雲の内部の詳細を隠すのに抽象化を使用できます。
Optical internetwork
光学インターネットワーク
An optical internetwork is a mesh-connected collection of optical networks. Each of these networks may be under a different administration.
光学インターネットワークは光学ネットワークのメッシュで接続された収集です。 それぞれのこれらのネットワークが異なった管理の下にあるかもしれません。
Rajagopalan, et al. Informational [Page 6] RFC 3717 IP over Optical Networks: A Framework March 2004
Rajagopalan、他 光学ネットワークの上の情報[6ページ]のRFC3717IP: 2004年のフレームワーク行進
Wavelength continuity property
波長連続の特性
A lightpath is said to satisfy the wavelength continuity property if it is transported over the same wavelength end-to-end. Wavelength continuity is required in optical networks with no wavelength conversion feature.
それが同じ波長の終わりから終わりの間、輸送されるなら、lightpathは波長連続の特性を満たすと言われます。 波長の連続が波長変換機能なしで光学ネットワークで必要です。
Wavelength path
波長経路
A lightpath that satisfies the wavelength continuity property is called a wavelength path.
波長連続の特性を満たすlightpathは波長経路と呼ばれます。
Opaque vs. transparent optical networks
見え透いた光学ネットワークに対して不透明です。
A transparent optical network is an optical network in which optical signals are transported from transmitter to receiver entirely in the optical domain without OEO conversion. Generally, intermediate switching nodes in a transparent optical network do not have access to the payload carried by the optical signals.
見え透いた光学ネットワークは光学信号が完全な光学ドメインでOEO変換なしで送信機から受信機まで輸送される光学ネットワークです。 一般に、見え透いた光学ネットワークにおける中間的切り換えノードは光学信号によって運ばれたペイロードに近づく手段を持っていません。
Note that amplification of signals at transit nodes is permitted in transparent optical networks (e.g., using Erbium Doped Fiber Amplifiers << EDFAs).
トランジットノードの信号の増幅が見え透いた光学ネットワーク(例えば、Erbium Doped Fiber Amplifiers<<EDFAsを使用する)で受入れられることに注意してください。
On the other hand, in opaque optical networks, transit nodes may manipulate optical signals traversing through them. An example of such manipulation would be OEO conversion which may involve 3R operations (reshaping, retiming, regeneration, and perhaps amplification).
他方では、不明瞭な光学ネットワークでは、トランジットノードはそれらを通して横断される光学信号を操作するかもしれません。 そのような操作に関する例は3R操作(造り直すこと、再調節、再生、および恐らく増幅)にかかわるかもしれないOEO変換でしょう。
Trust domain
信頼ドメイン
A trust domain is a network under a single technical administration in which adequate security measures are established to prevent unauthorized intrusion from outside the domain. Hence, it may be assumed that most nodes in the domain are deemed to be secure or trusted in some fashion. Generally, the rule for "single" administrative control over a trust domain may be relaxed in practice if a set of administrative entities agree to trust one another to form an enlarged heterogeneous trust domain. However, to simplify the discussions in this document, it will be assumed, without loss of generality, that the term trust domain applies to a single administrative entity with appropriate security policies. It should be noted that within a trust domain, any subverted node can send control messages which can compromise the entire network.
信頼ドメインは十分な安全性測定がドメインの外から権限のない侵入を防ぐために確立されるただ一つの技術的な管理の下でネットワークです。 したがって、そのドメインのほとんどのノードが安全であると考えられるか、または何らかのファッションで信じられると思われるかもしれません。 一般に、1セットの管理実体が、お互いが拡大した異種の信頼ドメインを形成すると信じるのに同意するなら、信頼ドメインの上の「単一」の運営管理コントロールのための規則は実際にはリラックスするかもしれません。 しかしながら、本書では議論を簡素化するために、一般性の喪失なしで用語信頼ドメインが適切な安全保障政策でただ一つの管理実体に適用されると思われるでしょう。 信頼ドメインの中では、どんな打倒されたノードも全体のネットワークに感染することができるコントロールメッセージを送ることができることに注意されるべきです。
Rajagopalan, et al. Informational [Page 7] RFC 3717 IP over Optical Networks: A Framework March 2004
Rajagopalan、他 光学ネットワークの上の情報[7ページ]のRFC3717IP: 2004年のフレームワーク行進
Flow
流れ
In this document, the term flow will be used to signify the smallest non-separable stream of data, from the point of view of an endpoint or termination point (source or destination node). The reader should note that the term flow is heavily overloaded in contemporary networking literature. In this document, we will consider a wavelength to be a flow, under certain circumstances. However, if there is a method to partition the bandwidth of the wavelength, then each partition may be considered a flow, for example using time division multiplexing (TDM), it may be feasible to consider each quanta of time within a given wavelength as a flow.
本書では、用語流動はデータの最も小さい非分離できるストリームを意味するのに使用されるでしょう、終点か終了ポイント(ソースか目的地ノード)の観点から。 読者は、用語流動が現代のネットワーク文学で大いに積みすぎられることに注意するべきです。 本書では、私たちは、ある状況の下で波長が流れであると考えるつもりです。 しかしながら、波長の帯域幅を仕切るメソッドがあれば、各パーティションは流れであると考えられるかもしれません、例えば、時分割多重化(TDM)を使用して、流れとして与えられた波長の中でそれぞれが時間の量子であると考えるのは可能であるかもしれません。
Traffic Trunk
トラフィックトランク
A traffic trunk is an abstraction of traffic flow traversing the same path between two access points which allows some characteristics and attributes of the traffic to be parameterized.
トラフィックトランクは2つのアクセスポイントの間のトラフィックのいくつかの特性と属性がparameterizedされるのを許容するのと同じ経路を横断する交通の流れの抽象化です。
3. The Network Model
3. ネットワークモデル
3.1. Network Interconnection
3.1. ネットワーク相互接続
The network model considered in this memo consists of IP routers attached to an optical core internetwork, and connected to their peers over dynamically established switched optical channels. The optical core itself is assumed to be incapable of processing individual IP packets in the data plane.
このメモで考えられたネットワークモデルは光学コアインターネットワークに付けられて、ダイナミックに設立された切り換えられた光学チャンネルの上に彼らの同輩に接されたIPルータから成ります。 光学コア自体がデータ飛行機で個々のIPパケットを処理できないと思われます。
The optical internetwork is assumed to consist of multiple optical networks, each of which may be administered by a different entity. Each optical network consists of sub-networks interconnected by optical fiber links in a general topology (referred to as an optical mesh network). This network may contain re-configurable optical equipment from a single vendor or from multiple vendors. In the near term, it may be expected that each sub-network will consist of switches from a single vendor. In the future, as standardization efforts mature, each optical sub-network may in fact contain optical switches from different vendors. In any case, each sub-network itself is assumed to be mesh-connected internally. In general, it can be expected that topologically adjacent OXCs in an optical mesh network will be connected via multiple, parallel (bi-directional) optical links. This network model is shown in Figure 1.
光学インターネットワークが複数の光学ネットワークから成ると思われます。それは異なった実体によってそれぞれ管理されるかもしれません。 それぞれの光学ネットワークは一般的なトポロジー(光学網目状ネットワークと呼ばれる)で光ファイバリンクによってインタコネクトされたサブネットワークから成ります。 このネットワークは単一のベンダーか複数のベンダーからの再構成可能な光学機器を含むかもしれません。 近いうちに、各サブネットワークが単一のベンダーからのスイッチから成ると予想されるかもしれません。 将来、標準化取り組みが熟すとき、事実上、それぞれの光学サブネットワークは異なったベンダーからの光学スイッチを含むかもしれません。 どのような場合でも、メッシュによって各サブネットワーク自体によって内部的に接続されていると思われます。 一般に、光学網目状ネットワークにおける隣接しているOXCsが複数の、そして、平行な(双方向の)光学リンクを通して接続されるとそんなに位相的に予想できます。 このネットワークモデルは図1で見せられます。
In this environment, an optical sub-network may consist entirely of all-optical OXCs or OXCs with optical-electrical-optical (OEO) conversion. Interconnection between sub-networks is assumed to be implemented through compatible physical interfaces, with suitable
この環境で、光学サブネットワークがオール光学のOXCsかOXCsから完全に成るかもしれない、光学、電気、光学、(OEO)変換。 適当であるとのコンパチブル物理インターフェースを通してサブネットワークの間のインタコネクトが実装されると思われます。
Rajagopalan, et al. Informational [Page 8] RFC 3717 IP over Optical Networks: A Framework March 2004
Rajagopalan、他 光学ネットワークの上の情報[8ページ]のRFC3717IP: 2004年のフレームワーク行進
optical-electrical conversions where necessary. The routers that have direct physical connectivity with the optical network are referred to as "edge routers" with respect to the optical network. As shown in Figure 1, other client networks (e.g., ATM) may also connect to the optical network.
光学的に電気の変換、必要であるところ。 光学ネットワークがあるダイレクト物理的な接続性を持っているルータは光学ネットワークに関して「縁のルータ」と呼ばれます。 また、図1に示されるように、他のクライアントネットワーク(例えば、ATM)は光学ネットワークに接続するかもしれません。
The switching function in an OXC is controlled by appropriately configuring the cross-connect fabric. Conceptually, this may be viewed as setting up a cross-connect table whose entries are of the form <input port i, output port j>, indicating that the data stream entering input port i will be switched to output port j. In the context of a wavelength selective cross-connect (generally referred to as a WXC), the cross-connect tables may also indicate the input and output wavelengths along with the input and output ports. A lightpath from an ingress port in an OXC to an egress port in a remote OXC is established by setting up suitable cross-connects in the ingress, the egress and a set of intermediate OXCs such that a continuous physical path exists from the ingress to the egress port. Optical paths tend to be bi-directional, i.e., the return path from the egress port to the ingress port is typically routed along the same set of intermediate interface cards as the forward path, but this may not be the case under all circumstances.
OXCのスイッチング関数は、適切に十字接続骨組みを構成することによって、制御されます。 概念的に、これはエントリーがフォーム<入力ポートiのものである十字接続テーブルをセットアップすると見なされるかもしれません、出力ポートj>、入力ポートiに入るデータ・ストリームがポートjを出力するために切り換えられるのを示して。 また、波長の選択している十字接続(一般に、WXCと呼ばれる)の文脈では、十字接続テーブルは入出力ポートに伴う入出力波長を示すかもしれません。 OXCのイングレスポートからリモートOXCの出口港までのlightpathは、連続した物理的な経路がイングレスから出口港まで存在するように中間的OXCsのイングレス、出口、およびセットで適当な十字接続をセットアップすることによって、設立されます。 光路は、双方向である傾向がありますが、すなわち、出口港からイングレスポートまでのリターンパスは同じセットのフォワードパスへの中間的インタフェースカードに沿って通常発送されますが、これはあらゆる情勢のもとでそうでないかもしれません。
Rajagopalan, et al. Informational [Page 9] RFC 3717 IP over Optical Networks: A Framework March 2004
Rajagopalan、他 光学ネットワークの上の情報[9ページ]のRFC3717IP: 2004年のフレームワーク行進
Optical Network
+---------------------------------------+
| |
| Optical Subnetwork |
+---------+ | +-----------------------------------+ |
| | | | +-----+ +-----+ +-----+ | |
| IP | | | | | | | | | | |
| Network +-UNI --+-+ OXC +------+ OXC +------+ OXC + | |
| | | | | | | | | | | |
+---------+ | | +--+--+ +--+--+ +--+--+ | |
| +----|------------|------------|----+ |
| | | | |
| INNI INNI INNI |
+---------+ | | | | |
| | | +----+------+ | +-------+----+ |
| IP + UNI- | | +-----+ | | |
| Network | | | Optical | | Optical | |
| | | |Subnetwork +---INNI---+ Subnetwork | |
+---------+ | | | | | |
| +-----+-----+ +------+-----+ |
| | | |
+-------+-----------------------+-------+
| |
ENNI ENNI
| |
+-------+-----------------------+-------+
| |
| Optical Network |
| |
+-------+-----------------------+-------+
| |
UNI UNI
| |
+-----+----- --+ +-----+------+
| | | |
| Other Client | |Other Client|
| Network | | Network |
| (e.g., ATM) | | |
+- ------------+ +------------+
光学ネットワーク+---------------------------------------+ | | | 光学サブネットワーク| +---------+ | +-----------------------------------+ | | | | | +-----+ +-----+ +-----+ | | | IP| | | | | | | | | | | | ネットワーク+-UNI--++OXC+------+ OXC+------+ OXC+| | | | | | | | | | | | | | +---------+ | | +--+--+ +--+--+ +--+--+ | | | +----|------------|------------|----+ | | | | | | | INNI INNI INNI| +---------+ | | | | | | | | +----+------+ | +-------+----+ | | IP+UNI| | +-----+ | | | | ネットワーク| | | 光学| | 光学| | | | | |サブネットワーク+---INNI---+ サブネットワーク| | +---------+ | | | | | | | +-----+-----+ +------+-----+ | | | | | +-------+-----------------------+-------+ | | ENNI ENNI| | +-------+-----------------------+-------+ | | | 光学ネットワーク| | | +-------+-----------------------+-------+ | | UNI UNI| | +-----+----- --+ +-----+------+ | | | | | 他のクライアント| |他のクライアント| | ネットワーク| | ネットワーク| | (例えば、気圧) | | | +- ------------+ +------------+
Figure 1: Optical Internetwork Model
図1: 光学インターネットワークモデル
Multiple traffic streams exiting from an OXC may be multiplexed onto
a fiber optic link using WDM technology. The WDM functionality may
exist outside of the OXC, and be transparent to the OXC. Or, this
function may be built into the OXC. In the later case, the cross-
connect table (conceptually) consists of pairs of the form, <{input
port i, Lambda(j)}, {output port k, Lambda(l)}>. This indicates that
WDM技術を使用することでOXCから出る複数のトラフィック小川を光ファイバーリンクに多重送信するかもしれません。 WDMの機能性は、OXCの外に存在していて、OXCに見え透いているかもしれません。 または、OXCはこの機能に組み込まれるかもしれません。 後の場合では、十字は接続します。出力はkを移植します、Lambda(l)。テーブルがフォームの組から(概念的に)成って、<がポートi、Lambda(j)を入力した、>。 これはそれを示します。
Rajagopalan, et al. Informational [Page 10] RFC 3717 IP over Optical Networks: A Framework March 2004
Rajagopalan、他 光学ネットワークの上の情報[10ページ]のRFC3717IP: 2004年のフレームワーク行進
the data stream received on wavelength Lambda(j) over input port i is switched to output port k on Lambda(l). Automated establishment of lightpaths involves setting up the cross-connect table entries in the appropriate OXCs in a coordinated manner such that the desired physical path is realized.
入力ポートiの上の波長Lambda(j)で受けられたデータ・ストリームは、Lambda(l)の上のポートkを出力するために切り換えられます。 lightpathsの自動化された設立は、必要な物理的な経路が実現されるように適切なOXCsで連携方法で十字接続テーブル項目をセットアップすることを伴います。
Under this network model, a switched lightpath must be established between a pair of IP routers before the routers can transfer user traffic among themselves. A lightpath between IP routers may traverse multiple optical networks and be subject to different provisioning and restoration procedures in each network.
このネットワークモデルの下では、ルータがユーザトラフィックを自分たちに移すことができる前に1組のIPルータの間に切り換えられたlightpathを設立しなければなりません。 IPルータの間のlightpathは複数の光学ネットワークを横断して、各ネットワークにおける異なった食糧を供給するのと回復手順を受けることがあるかもしれません。
The IP-based control plane issue for optical networks pertains to the design of standard signaling and routing protocols for provisioning and restoration of lightpaths across multiple optical networks. Similarly, IP transport over optical networks involves establishing IP reachability and seamlessly constructing forwarding paths from one IP endpoint to another over an optical network.
光学ネットワークのためのIPベースのコントロール飛行機問題は複数の光学ネットワークの向こう側にlightpathsの食糧を供給するのと修復のための標準のシグナリングとルーティング・プロトコルのデザインに関係します。 同様に、光学ネットワークの上のIP輸送は、光学ネットワークの上でIPの可到達性を確立して、シームレスに推進経路を構成することを1つのIP終点から別の終点まで伴います。
3.2. Control Structure
3.2. 制御構造
There are three logical control interfaces identified in Figure 1. These are the client-optical internetwork interface, the internal node-to-node interface within an optical network (between OXCs in different sub-networks), and the external node-to-node interface between nodes in different optical networks. These interfaces are also referred to as the User-Network Interface (UNI), the internal NNI (INNI), and the external NNI (ENNI), respectively.
図1で特定された3つの論理的なコントロールインタフェースがあります。 これらは、クライアント光学のインターネットワークインタフェースと、光学ネットワーク(異なったサブネットワークにおけるOXCsの間の)の中のノードからノードへの内部のインタフェースと、外部のノードからノードへの異なった光学ネットワークにおけるノードの間のインタフェースです。 また、これらのインタフェースはそれぞれUser-ネットワークInterface(UNI)、内部のNNI(INNI)、および外部のNNI(ENNI)と呼ばれます。
The distinction between these interfaces arises out of the type and amount of control information flow across them. The client-optical internetwork interface (UNI) represents a service boundary between the client (e.g., IP router) and the optical network. The client and server (optical network) are essentially two different roles: the client role requests a service connection from a server; the server role establishes the connection to fulfill the service request -- provided all relevant admission control conditions are satisfied.
これらのインタフェースの区別はそれらの向こう側に制御情報流動のタイプと量から起こります。 クライアント光学のインターネットワークインタフェース(UNI)はクライアント(例えば、IPルータ)と光学ネットワークの間のサービス境界を表します。 クライアントとサーバ(光学ネットワーク)は本質的には2つの異なる役割です: クライアントの役割はサーバからサービス連結部を要求します。 すべての関連入場コントロール状態が満たされているなら、サーバーの役割は、サービスのリクエストを実現させるために接続を確立します。
Thus, the control flow across the client-optical internetwork interface is dependent on the set of services defined across it and the manner in which the services may be accessed. The service models are described in Section 4. The NNIs represent vendor-independent standardized interfaces for control flow between nodes. The distinction between the INNI and the ENNI is that the former is an interface within a given network under a single technical administration, while the later indicates an interface at the administrative boundary between networks. The INNI and ENNI may thus differ in the policies that restrict control flow between nodes.
したがって、クライアント光学のインターネットワークインタフェースの向こう側のコントロール流動はサービスがアクセスされるかもしれないそれの向こう側に定義されたサービスと方法のセットに依存しています。 サービスモデルはセクション4で説明されます。 NNIsはノードの間のコントロール流動のためにベンダーから独立している標準化されたインタフェースを表します。 INNIとENNIの区別は前者がただ一つの技術的な管理の下における与えられたネットワークの中のインタフェースであるということです、後がネットワークの間の管理境界でインタフェースを示しますが。 その結果、INNIとENNIはノードの間のコントロール流動を制限する方針において異なるかもしれません。
Rajagopalan, et al. Informational [Page 11] RFC 3717 IP over Optical Networks: A Framework March 2004
Rajagopalan、他 光学ネットワークの上の情報[11ページ]のRFC3717IP: 2004年のフレームワーク行進
Security, scalability, stability, and information hiding are important considerations in the specification of the ENNI. It is possible in principle to harmonize the control flow across the UNI and the NNI and eliminate the distinction between them. On the other hand, it may be required to minimize flow of control information, especially routing-related information, over the UNI; and even over the ENNI. In this case, UNI and NNIs may look different in some respects. In this document, these interfaces are treated as distinct.
ENNIの仕様でセキュリティ、スケーラビリティ、安定性、および情報隠蔽は重要な問題です。 原則としてUNIとNNIの向こう側にコントロール流動を調和させて、それらの間で区別を排除するのは可能です。 他方では、それがUNIの上で制御情報の流れ、特にルーティング関連の情報を最小にするのに必要であるかもしれません。 そして、ENNIの上で同等です。 この場合、UNIとNNIsはある点で異なるように見えるかもしれません。 本書では、これらのインタフェースは異なるとして扱われます。
The client-optical internetwork interface can be categorized as public or private depending upon context and service models. Routing information (i.e., topology state information) can be exchanged across a private client-optical internetwork interface. On the other hand, such information is not exchanged across a public client- optical internetwork interface, or such information may be exchanged with very explicit restrictions (including, for example abstraction, filtration, etc). Thus, different relationships (e.g., peer or over-lay, Section 5) may occur across private and public logical interfaces.
公共の、または、個人的な依存が文脈とサービスのときにモデル化されるとき、クライアント光学のインターネットワークインタフェースを分類できます。 個人的なクライアント光学のインターネットワークインタフェースの向こう側にルート設定情報(すなわち、トポロジー州の情報)を交換できます。 他方では、公共のクライアント光学インターネットワークインタフェースの向こう側にそのような情報を交換しないか、または非常に明白な制限(包含、例えば、抽象化、濾過など)でそのような情報を交換するかもしれません。 その結果、異なった関係、(例えば、じっと見てください。さもないと、オーバレイ、セクション5)は個人的で公共の論理的なインタフェースの向こう側に起こるかもしれません。
The physical control structure used to realize these logical interfaces may vary. For instance, for the client-optical internetwork interface, some of the possibilities are:
これらの論理的なインタフェースがわかるのに使用される物的管理構造は異なるかもしれません。 例えば、クライアント光学のインターネットワークインタフェースに関して、可能性のいくつかは以下の通りです。
1. Direct interface: An in-band or out-of-band IP control channel
(IPCC) may be implemented between an edge router and each OXC to
which it is connected. This control channel is used for
exchanging signaling and routing messages between the router and
the OXC. With a direct interface, the edge router and the OXC it
connects to are peers with respect to the control plane. This
situation is shown in Figure 2. The type of routing and signaling
information exchanged across the direct interface may vary
depending on the service definition. This issue is addressed in
the next section. Some choices for the routing protocol are OSPF
or ISIS (with traffic engineering extensions and additional
enhancements to deal with the peculiar characteristics of optical
networks) or BGP, or some other protocol. Other directory-based
routing information exchanges are also possible. Some of the
signaling protocol choices are adaptations of RSVP-TE or CR-LDP.
The details of how the IP control channel is realized is outside
the scope of this document.
1. ダイレクトに、連結してください: バンドの、または、バンドで出かけているIP制御チャンネル(IPCC)はそれが関連している縁のルータと各OXCの間で実装されるかもしれません。 この制御チャンネルは、ルータとOXCの間でシグナリングとルーティング・メッセージを交換するのに使用されます。 ダイレクトインタフェースで、縁のルータとそれが接続するOXCは制御飛行機に関する同輩です。 この状況は図2に示されます。 サービス定義によって、情報がダイレクトインタフェースの向こう側に交換したルーティングとシグナリングのタイプは異なるかもしれません。 この問題は次のセクションで扱われます。 ルーティング・プロトコルのためのいくつかの選択が、OSPF、イシス(光学ネットワークの持ち味に対処する交通工学拡大と追加増進がある)、BGP、またはある他のプロトコルです。 また、他のディレクトリベースのルーティング情報交換も可能です。 シグナリングプロトコル選択のいくつかはRSVP-TEかCR-自由民主党の適合です。 このドキュメントの範囲の外にIP制御チャンネルがどう実現されるかに関する詳細があります。
2. Indirect interface: An out-of-band IP control channel may be
implemented between the client and a device in the optical network
to signal service requests and responses. For instance, a
management system or a server in the optical network may receive
service requests from clients. Similarly, out-of-band signaling
2. 間接的なインタフェース: バンドで出かけているIP制御チャンネルは、サービスのリクエストと応答に合図するためにクライアントとデバイスの間で光学ネットワークで実装されるかもしれません。 例えば、マネージメントシステムか光学ネットワークにおけるサーバがクライアントからサービスのリクエストを受け取るかもしれません。 同様である、バンドで出ているシグナリング
Rajagopalan, et al. Informational [Page 12] RFC 3717 IP over Optical Networks: A Framework March 2004
Rajagopalan、他 光学ネットワークの上の情報[12ページ]のRFC3717IP: 2004年のフレームワーク行進
may be used between management systems in client and optical
networks to signal service requests. In these cases, there is no
direct control interaction between clients and respective OXCs.
One reason to have an indirect interface would be that the OXCs
and/or clients do not support a direct signaling interface.
サービスのリクエストに合図するのにマネージメントシステムの間でクライアントと光学ネットワークに使用されるかもしれません。 これらの場合には、クライアントとそれぞれのOXCsとの直轄相互作用が全くありません。 間接的なインタフェースを持つ1つの理由はOXCs、そして/または、クライアントがダイレクトシグナリングインタフェースをサポートしないということでしょう。
+---------------------------+ +---------------------------+ | | | | | +---------+ +---------+ | | +---------+ +---------+ | | | | | | | | | | | | | | | Routing | |Signaling| | | | Routing | |Signaling| | | | Protocol| |Protocol | | | | Protocol| |Protocol | | | | | | | | | | | | | | | +-----+---+ +---+-----+ | | +-----+---+ +---+-----+ | | | | | | | | | | | | | | | | | | +--+-----------+---+ | | +--+-----------+---+ | | | | | | | | | | | IP Layer +....IPCC.....+ IP Layer | | | | | | | | | | | +------------------+ | | +------------------+ | | | | | | Edge Router | | OXC | +---------------------------+ +---------------------------+
+---------------------------+ +---------------------------+ | | | | | +---------+ +---------+ | | +---------+ +---------+ | | | | | | | | | | | | | | | ルート設定| |シグナリング| | | | ルート設定| |シグナリング| | | | プロトコル| |プロトコル| | | | プロトコル| |プロトコル| | | | | | | | | | | | | | | +-----+---+ +---+-----+ | | +-----+---+ +---+-----+ | | | | | | | | | | | | | | | | | | +--+-----------+---+ | | +--+-----------+---+ | | | | | | | | | | | IP層+…IPCC…+ IP層| | | | | | | | | | | +------------------+ | | +------------------+ | | | | | | 縁のルータ| | OXC| +---------------------------+ +---------------------------+
Figure 2: Direct Interface
図2: ダイレクトに、連結してください。
3. Provisioned interface: In this case, the optical network services
are manually provisioned and there is no control interactions
between the client and the optical network.
3. 食糧を供給されたインタフェース: この場合、光のネットワーク・サービスは手動で食糧を供給されます、そして、クライアントと光学ネットワークとのコントロール相互作用が全くありません。
Although different control structures are possible, further descriptions in this framework assume direct interfaces for IP- optical and optical sub-network control interactions.
異なった制御構造は可能ですが、このフレームワークにおけるさらなる記述はIPの光学の、そして、光学のサブネットワークコントロール相互作用のためにダイレクトインタフェースを仮定します。
4. IP over Optical Service Models and Requirements
4. 光学サービスモデルと要件の上のIP
In this section, the service models and requirements at the UNI and the NNIs are considered. Two general models have emerged for the services at the UNI (which can also be applied at the NNIs). These models are as follows.
このセクションでは、UNIとNNIsのサービスモデルと要件は考えられます。 2つの一般的なモデルがUNI(また、NNIsに適用できる)でのサービスのために現れました。 これらのモデルは以下の通りです。
4.1. Domain Services Model
4.1. ドメインサービスモデル
Under the domain services model, the optical network primarily offers high bandwidth connectivity in the form of lightpaths. Standardized signaling across the UNI (Figure 1) is used to invoke the following services:
ドメインサービスモデルの下では、光学ネットワークはlightpathsの形で主として高帯域の接続性を提供します。 UNI(図1)の向こう側の標準化されたシグナリングは以下のサービスを呼び出すのに使用されます:
Rajagopalan, et al. Informational [Page 13] RFC 3717 IP over Optical Networks: A Framework March 2004
Rajagopalan、他 光学ネットワークの上の情報[13ページ]のRFC3717IP: 2004年のフレームワーク行進
1. Lightpath creation: This service allows a lightpath with the
specified attributes to be created between a pair of termination
points in the optical network. Lightpath creation may be subject
to network-defined policies (e.g., connectivity restrictions) and
security procedures.
1. Lightpath作成: このサービスは、指定された属性があるlightpathが光学ネットワークにおける、1組の終了ポイントの間で作成されるのを許容します。 Lightpath作成はネットワークによって定義された方針(例えば、接続性制限)とセキュリティ手順を受けることがあるかもしれません。
2. Lightpath deletion: This service allows an existing lightpath to
be deleted.
2. Lightpath削除: このサービスは、既存のlightpathが削除されるのを許容します。
3. Lightpath modification: This service allows certain parameters of
the lightpath to be modified.
3. Lightpath変更: このサービスは、lightpathのあるパラメタが変更されるのを許容します。
4. Lightpath status enquiry: This service allows the status of
certain parameters of the lightpath (referenced by its ID) to be
queried by the router that created the lightpath.
4. Lightpath状態調査: このサービスは、lightpath(IDによって参照をつけられる)のあるパラメタの状態がlightpathを作成したルータによって質問されるのを許容します。
An end-system discovery procedure may be used over the UNI to verify local port connectivity between the optical and client devices, and allows each device to bootstrap the UNI control channel. Finally, a "service discovery" procedure may be employed as a precursor to obtaining UNI services. Service discovery allows a client to determine the static parameters of the interconnection with the optical network, including the UNI signaling protocols supported. The protocols for neighbor and service discovery are different from the UNI signaling protocol itself (for example, see LMP [2]).
エンドシステム発見手順は、光学とクライアントデバイスの間のローカルのポートの接続性について確かめるのにUNIの上で使用されるかもしれなくて、各デバイスがUNI制御チャンネルを独力で進むのを許容します。 最終的に、「サービス発見」手順は先駆としてUNIサービスを得るのに使われるかもしれません。 クライアントはサービス発見で光学ネットワークがあるインタコネクトの静的なパラメタを決定できます、プロトコルがサポートしたUNIシグナリングを含んでいて。 隣人のためのプロトコルとサービス発見はUNIシグナリングプロトコル自体と異なっています。(例えば、LMP[2])を見てください。
Because a small set of well-defined services is offered across the UNI, the signaling protocol requirements are minimal. Specifically, the signaling protocol is required to convey a few messages with certain attributes in a point-to-point manner between the router and the optical network. Such a protocol may be based on RSVP-TE or LDP, for example.
UNIの向こう側に小さい明確なサービスを提供するので、シグナリングプロトコル要件は最小限です。 明確に、シグナリングプロトコルが、ある属性で二地点間方法でルータと光学ネットワークの間にいくつかのメッセージを伝えるのに必要です。 そのようなプロトコルは例えば、RSVP-TEか自由民主党に基づくかもしれません。
The optical domain services model does not deal with the type and nature of routing protocols within and across optical networks.
光学ドメインサービスモデルはネットワーク以内と光学ネットワークの向こう側にルーティング・プロトコルのタイプと本質に対処しません。
The optical domain services model would result in the establishment of a lightpath topology between routers at the edge of the optical network. The resulting overlay model for IP over optical networks is discussed in Section 5.
光学ドメインサービスモデルは光学ネットワークの縁のルータの間のlightpathトポロジーの設立をもたらすでしょう。 セクション5で光学ネットワークの上のIPの結果として起こるオーバレイモデルについて議論します。
4.2. Unified Service Model
4.2. 統一されたサービスモデル
Under this model, the IP and optical networks are treated together as a single integrated network from a control plane point of view. In this regard, the OXCs are treated just like any other router as far as the control plane is considered. Thus, in principle, there is no distinction between the UNI, NNIs and any other router-to-router
このモデルの下では、IPと光学ネットワークはコントロール飛行機観点からただ一つの統合ネットワークとして一緒に扱われます。 この点で、制御飛行機が考えられる限り、OXCsはまさしくいかなる他のルータのようにも扱われます。 したがって、原則として、いかなる他のUNIと、NNIsとルータからルータの間にはも、区別が全くありません。
Rajagopalan, et al. Informational [Page 14] RFC 3717 IP over Optical Networks: A Framework March 2004
Rajagopalan、他 光学ネットワークの上の情報[14ページ]のRFC3717IP: 2004年のフレームワーク行進
interface from a routing and signaling point of view. It is assumed that this control plane is IP-based, for example leveraging the traffic engineering extensions for MPLS or GMPLS, as described in [1]. The unified service model has so far been discussed only in the context of a single administrative domain. A unified control plane is possible even when there are administrative boundaries within an optical internetwork, but some of the integrated routing capabilities may not be practically attractive or even feasible in this case (see Section 5).
ルーティングとシグナリング観点から、連結してください。 この制御飛行機がIPベースであると思われます、例えば、MPLSかGMPLSのために交通工学が拡大であると利用して、[1]で説明されるように。 今までのところ、ただ一つの管理ドメインの文脈だけで統一されたサービスモデルについて議論しました。 光学インターネットワークの中に管理境界さえありさえするときさえ、統一された制御飛行機は可能ですが、統合ルーティング能力のいくつかが、この場合実際に魅力的であるか、または可能でさえないかもしれません(セクション5を見てください)。
Under the unified service model and within the context of a GMPLS network, optical network services are obtained implicitly during end-to-end GMPLS signaling. Specifically, an edge router can create a lightpath with specified attributes, or delete and modify lightpaths as it creates GMPLS label-switched paths (LSPs). In this regard, the services obtained from the optical network are similar to the domain services model. These services, however, may be invoked in a more seamless manner as compared to the domain services model. For instance, when routers are attached to a single optical network (i.e., there are no ENNIs), a remote router could compute an end-to- end path across the optical internetwork. It can then establish an LSP across the optical internetwork. But the edge routers must still recognize that an LSP across the optical internetwork is a lightpath, or a conduit for multiple packet-based LSPs.
統一されたサービスモデルの下と、そして、GMPLSネットワークの文脈の中では、終わりから終わりへのGMPLSシグナリングの間、それとなく光のネットワーク・サービスを得ます。 明確に、縁のルータが指定された属性があるlightpathを作成できるか、GMPLSを作成するとき、lightpathsを削除して、変更してください。ラベルで切り換えられた経路(LSPs)。 この点で、光学ネットワークから得られたサービスはドメインサービスモデルと同様です。 しかしながら、ドメインサービスモデルと比べて、これらのサービスは、よりシームレスの方法で呼び出されるかもしれません。 例えば、ルータがただ一つの光学ネットワークに付けられているとき(すなわち、ENNIsが全くありません)、リモートルータは光学インターネットワークの向こう側に終わりから端への経路を計算するかもしれません。 そして、それは光学インターネットワークの向こう側にLSPを設立できます。 しかし、縁のルータは、光学インターネットワークの向こう側のLSPがlightpath、または複数のパケットベースのLSPsのための経路であるとまだ認めなければなりません。
The concept of "forwarding adjacency" can be used to specify virtual links across optical internetworks in routing protocols such as OSPF [3]. In essence, once a lightpath is established across an optical internetwork between two edge routers, the lightpath can be advertised as a forwarding adjacency (a virtual link) between these routers. Thus, from a data plane point of view, the lightpaths result in a virtual overlay between edge routers. The decisions as to when to create such lightpaths, and the bandwidth management for these lightpaths is identical in both the domain services model and the unified service model. The routing and signaling models for unified services is described in Sections 5 and 6.
OSPF[3]などのルーティング・プロトコルの光学インターネットワークの向こう側に仮想のリンクを指定するのに「推進隣接番組」の概念を使用できます。 本質では、2つの縁のルータの間の光学インターネットワークの向こう側にいったんlightpathを設立すると、これらのルータの間の推進隣接番組(仮想のリンク)としてlightpathの広告を出すことができます。 したがって、データ飛行機観点から、lightpathsは縁のルータの間の仮想のオーバレイをもたらします。 これらのlightpathsのためにいつそのようなlightpaths、および帯域幅管理を創設するかまで同じコネがあるとき両方のドメインサービスがモデル化されるという決定と統一されたサービスモデル。 ルーティングと統一されたサービスのためのモデルに合図するのはセクション5と6で説明されます。
4.3. Which Service Model?
4.3. どのサービスがモデル化されますか?
The relative merits of the above service models can be debated at length, but the approach recommended in this framework is to define routing and signaling mechanisms in support of both models. As noted above, signaling for service requests can be unified to cover both models. The developments in GMPLS signaling [4] for the unified service model and its adoption for UNI signaling [5, 6] under the domain services model essentially supports this view. The significant difference between the service models, however, is in routing protocols, as described in Sections 5 and 6.
十分上のサービスモデルの優劣について討論できますが、このフレームワークにおけるお勧めのアプローチは両方のモデルを支持してルーティングとシグナル伝達機構を定義することです。 上で述べたように、両方のモデルをカバーするためにサービスのリクエストのために合図するのを統一できます。 ドメインサービスモデルの下で本質的にはUNIシグナリング[5、6]への統一されたサービスモデルとその採用のための[4]に合図するとこの視点がサポートするGMPLSでの開発。 しかしながら、ルーティング・プロトコルにはサービスモデルの著しい違いがセクション5と6で説明されるようにあります。
Rajagopalan, et al. Informational [Page 15] RFC 3717 IP over Optical Networks: A Framework March 2004
Rajagopalan、他 光学ネットワークの上の情報[15ページ]のRFC3717IP: 2004年のフレームワーク行進
4.4. What are the Possible Services?
4.4. Possible Servicesは何ですか?
Specialized services may be built atop the point-to-point connectivity service offered by the optical network. For example, optical virtual private networks and bandwidth on demand are some of the services that can be envisioned.
専門化しているサービスは光学ネットワークによって提供された二地点間接続性サービスの上で組み込まれるかもしれません。 例えば、光学仮想私設網とオンデマンドの帯域幅は思い描くことができるサービスのいくつかです。
4.4.1. Optical Virtual Private Networks (OVPNs)
4.4.1. 光学仮想私設網(OVPNs)
Given that the data plane links between IP routers over an optical network amounts to a virtual topology which is an overlay over the fiber optic network, it is easy to envision a virtual private network of lightpaths that interconnect routers (or any other set of clients) belonging to a single entity or a group of related entities across a public optical network. Indeed, in the case where the optical network provides connectivity for multiple sets of external client networks, there has to be a way to enforce routing policies that ensure routing separation between different sets of client networks (i.e., VPN service).
飛行機がIPルータの間で結ぶデータが光ファイバーネットワークの上で光学ネットワークの上でオーバレイである仮想のトポロジーに達するなら、公立の光学ネットワークの向こう側に単一体に属しながらルータ(または、いかなる他のセットのクライアントも)とインタコネクトするlightpathsの仮想私設網か関連する実体のグループを思い描くのは簡単です。 本当に、光学ネットワークが複数のセットの外部クライアントネットワークに接続性を提供する場合には、異なったセットのクライアントネットワーク(すなわち、VPNサービス)の間に分離を発送するのを確実にするルーティング方針を実施する方法がなければなりません。
5. IP transport over Optical Networks
5. Optical Networksの上のIP輸送
To examine the architectural alternatives for IP over optical networks, it is important to distinguish between the data and control planes. The optical network provides a service to external entities in the form of fixed bandwidth transport pipes (optical paths). IP routers at the edge of the optical networks must necessarily have such paths established between them before communication at the IP layer can commence. Thus, the IP data plane over optical networks is realized over a virtual topology of optical paths. On the other hand, IP routers and OXCs can have a peer relation with respect to the control plane, especially for routing protocols that permit the dynamic discovery of IP endpoints attached to the optical network.
IPがないかどうか光学ネットワークの上で建築代替手段を調べるために、データと制御飛行機を見分けるのは重要です。 光学ネットワークは固定帯域幅輸送管(光路)の形に外部実体に対するサービスを供給します。 光学ネットワークの縁のIPルータで、IP層のコミュニケーションが始まることができる前に必ずそれらの間でそのような経路を確立しなければなりません。 したがって、光学ネットワークの上のIPデータ飛行機は光路の仮想のトポロジーの上で実感されます。 他方では、IPルータとOXCsは制御飛行機に関して同輩関係を持つことができます、特に光学ネットワークに付けられたIP終点のダイナミックな発見を可能にするルーティング・プロトコルのために。
The IP over optical network architecture is defined essentially by the organization of the control plane. The assumption in this framework is that an IP-based control plane [1] is used, such as GMPLS. Depending on the service model(Section 4), however, the control planes in the IP and optical networks can be loosely or tightly coupled. This coupling determines the following characteristics:
光学ネットワークアーキテクチャの上のIPは本質的には制御飛行機の組織によって定義されます。 このフレームワークにおける仮定はIPベースの制御飛行機[1]がGMPLSなどのように使用されるということです。 しかしながら、サービスモデル(セクション4)に頼っていて、ゆるみかしっかりIPと光学ネットワークにおける制御飛行機を結合できます。 このカップリングは以下の特性を決定します:
o The details of the topology and routing information advertised by
the optical network across the client interface;
o クライアントのの向こう側に光学ネットワークによって広告に掲載されたトポロジーとルーティング情報の詳細は連結します。
o The level of control that IP routers can exercise in selecting
explicit paths for connections across the optical network;
o IPルータが接続のために光学ネットワークの向こう側に明白な経路を選択する際に運動させることができる管理水準。
Rajagopalan, et al. Informational [Page 16] RFC 3717 IP over Optical Networks: A Framework March 2004
Rajagopalan、他 光学ネットワークの上の情報[16ページ]のRFC3717IP: 2004年のフレームワーク行進
o Policies regarding the dynamic provisioning of optical paths
between routers. These include access control, accounting, and
security issues.
o ルータの間の光路のダイナミックな食糧を供給するのに関する方針。 これらはアクセスコントロール、会計、および安全保障問題を含んでいます。
The following interconnection models are then possible:
次に、以下のインタコネクトモデルは可能です:
5.1. Interconnection Models
5.1. インタコネクトモデル
5.1.1. The Peer Model
5.1.1. 同輩モデル
Under the peer model, the IP control plane acts as a peer of the optical transport network control plane. This implies that a single instance of the control plane is deployed over the IP and optical domains. When there is a single optical network involved and the IP and optical domains belong to the same entity, then a common IGP such as OSPF or IS-IS, with appropriate extensions, can be used to distribute topology information [7] over the integrated IP-optical network. In the case of OSPF, opaque LSAs can be used to advertise topology state information. In the case of IS-IS, extended TLVs will have to be defined to propagate topology state information. Many of these extensions are occurring within the context of GMPLS.
同輩モデルの下では、IP制御飛行機は光学転送ネットワーク制御飛行機の同輩として作動します。 これは、制御飛行機のただ一つのインスタンスがIPと光学ドメインの上で配布されるのを含意します。 または、かかわったただ一つの光学ネットワークとIPがあって、光学ドメインが同じ実体に属して、その時がOSPFなどの一般的なIGPである、-、統合IP光学のネットワークの上にトポロジー情報[7]を分配するのに適切な拡大と共に使用できます。 OSPFの場合では、トポロジー州の情報の広告を出すのに不透明なLSAsを使用できます。 ケース、-、拡張TLVsは、トポロジー州の情報を伝播するために定義されなければならないでしょう。 これらの拡大の多くがGMPLSの文脈の中に起こっています。
When an optical internetwork with multiple optical networks is involved (e.g., spanning different administrative domains), a single instance of an intra-domain routing protocol is not attractive or even realistic. In this case, inter-domain routing and signaling protocols are needed. In either case, a tacit assumption is that a common addressing scheme will be used for the optical and IP networks. A common address space can be trivially realized by using IP addresses in both IP and optical domains. Thus, the optical network elements become IP addressable entities as noted in [1].
複数の光学ネットワークがある光学インターネットワークがかかわるとき(例えば、異なった管理ドメインにかかっています)、イントラドメインルーティング・プロトコルのただ一つのインスタンスは、魅力的でないか、または現実的でさえあります。 この場合、相互ドメインルーティングとプロトコルに合図するのが必要です。 どちらかの場合では、暗黙の仮定は一般的なアドレシング体系が光学とIPネットワークに使用されるということです。 IPと光学ドメインの両方でIPアドレスを使用することによって、一般的なアドレス空間を些細なことに実現できます。 したがって、光学ネットワーク要素は[1]に述べられるようにIPのアドレス可能な実体になります。
5.1.2. The Overlay Model
5.1.2. オーバレイモデル
Under the overlay model, the IP layer routing, topology distribution, and signaling protocols are independent of the routing, topology distribution, and signaling protocols within the optical domain. This model is conceptually similar to the classical IP over ATM or MPOA models, but applied to an optical internetwork instead. In the overlay model, a separate instance of the control plane (especially the routing and signaling protocols) would have to be deployed in the optical domain, independent of what exists in the IP domain. In certain circumstances, it may also be feasible to statically configure the optical channels that provide connectivity for the IP domain in the overlay model. Static configuration can be effected through network management functions. Static configuration, however,
オーバレイモデルの下では、IP層のルーティングと、トポロジー分配と、プロトコルに合図するのは光学ドメインの中でルーティングと、トポロジー分配と、プロトコルに合図するのから独立しています。 このモデルは、代わりに古典的なIPとATMかMPOAモデルの上で概念的に同様ですが、光学インターネットワークに適用されています。 オーバレイモデルでは、制御飛行機(特にルーティングとシグナリングプロトコル)の別々のインスタンスは光学ドメインで配布されなければならないでしょう、IPドメインに存在するものの如何にかかわらず。 また、ある特定の状況では、静的にオーバレイモデルのIPドメインに接続性を提供する光学チャンネルを構成するのも可能であるかもしれません。 静的な構成はネットワークマネージメント機能を通して作用できます。 しかしながら、静的な構成
Rajagopalan, et al. Informational [Page 17] RFC 3717 IP over Optical Networks: A Framework March 2004
Rajagopalan、他 光学ネットワークの上の情報[17ページ]のRFC3717IP: 2004年のフレームワーク行進
is unlikely to scale in very large networks, and may not support the rapid connection provisioning requirements of future highly competitive networking environments.
非常に大きいネットワークを計量しそうになくて、将来の非常に競争力があるネットワーク環境の要件に食糧を供給する急速な接続をサポートしないかもしれません。
5.1.3. The Augmented Model
5.1.3. 増大しているモデル
Under the augmented model, there are separate routing instances in the IP and optical domains, but certain types of information from one routing instance can be passed through to the other routing instance. For example, external IP addresses could be carried within the optical routing protocols to allow reachability information to be passed to IP clients.
増大しているモデルの下では、別々のルーティングインスタンスがIPと光学ドメインにありますが、1つのルーティングインスタンスからのあるタイプの情報はもう片方のルーティングインスタンスに通り抜けることができます。 例えば、可到達性情報がIPクライアントに渡されるのを許容する光学ルーティング・プロトコルの中で外部のIPアドレスを運ぶことができました。
The routing approaches corresponding to these interconnection models are described below.
これらのインタコネクトモデルにおいて、対応するルーティングアプローチは以下で説明されます。
5.2. Routing Approaches
5.2. ルート設定アプローチ
5.2.1. Integrated Routing
5.2.1. 統合ルート設定
This routing approach supports the peer model within a single administrative domain. Under this approach, the IP and optical networks are assumed to run the same instance of an IP routing protocol, e.g., OSPF with suitable "optical" extensions. These extensions must capture optical link parameters, and any constraints that are specific to optical networks. The topology and link state information maintained by all nodes (OXCs and routers) may be identical, but not necessarily. This approach permits a router to compute an end-to-end path to another router across the optical network. Suppose the path computation is triggered by the need to route a label switched path (LSP) in a GMPLS environment. Such an LSP can be established using GMPLS signaling, e.g., RSVP-TE or CR-LDP with appropriate extensions. In this case, the signaling protocol will establish a lightpath between two edge routers. This lightpath is in essence a tunnel across the optical network, and may have capacity much larger than the bandwidth required to support the first LSP. Thus, it is essential that other routers in the network realize the availability of excess capacity within the lightpath so that subsequent LSPs between the routers can use it rather than instantiating a new lightpath. The lightpath may therefore be advertised as a virtual link in the topology as a means to address this issue.
このルーティングアプローチはただ一つの管理ドメインの中で同輩モデルをサポートします。 このアプローチで、IPと光学ネットワークがIPルーティング・プロトコル(例えば、適当な「光学」の拡大を伴うOSPF)の同じインスタンスを実行すると思われます。 これらの拡大は光学リンクパラメータ、および光学ネットワークに特定のどんな規制も得なければなりません。 すべてのノード(OXCsとルータ)で州の情報が維持したトポロジーとリンクは、同じですが、必ず同じであるかもしれないというわけではありません。 このアプローチは、ルータが光学ネットワークの向こう側に終わりから端への経路を別のルータに計算することを許可します。 経路計算が発送する必要性によって引き起こされるなら、ラベルはGMPLS環境における経路(LSP)を切り換えました。 例えばGMPLSシグナリングを使用することでそのようなLSPを設立できます。適切な拡大を伴うRSVP-TEかCR-自由民主党。 この場合、シグナリングプロトコルは2つの縁のルータの間のlightpathを設立するでしょう。 このlightpathは光学ネットワークの向こう側の本質におけるトンネルであり、容量を帯域幅が最初のLSPをサポートするのが必要であるというよりもはるかに大きくするかもしれません。 したがって、ルータの間のその後のLSPsが新しいlightpathを例示するよりむしろそれを使用できるようにネットワークにおける他のルータがlightpathの中で過剰生産能力の有用性がわかるのは、不可欠です。 したがって、仮想のリンクとしてこの問題を扱う手段としてのトポロジーにlightpathの広告を出すかもしれません。
The notion of "forwarding adjacency" (FA) described in [3] is essential in propagating existing lightpath information to other routers. An FA is essentially a virtual link advertised into a link state routing protocol. Thus, an FA could be described by the same parameters that define resources in any regular link. While it is
[3]で説明された「推進隣接番組」(FA)の概念は既存のlightpath情報を他のルータに伝播するのにおいて不可欠です。 FAは本質的にはリンク州のルーティング・プロトコルに広告に掲載された仮想のリンクです。 したがって、どんな通常のリンクでもリソースを定義するのと同じパラメタでFAについて説明できました。 それはそうですが
Rajagopalan, et al. Informational [Page 18] RFC 3717 IP over Optical Networks: A Framework March 2004
Rajagopalan、他 光学ネットワークの上の情報[18ページ]のRFC3717IP: 2004年のフレームワーク行進
necessary to specify the mechanism for creating an FA, it is not necessary to specify how an FA is used by the routing scheme. Once an FA is advertised in a link state protocol, its usage for routing LSPs is defined by the route computation and traffic engineering algorithms implemented.
FAを作成するのにメカニズムを指定するのに必要です、FAがルーティング体系によってどう使用されるかを指定するのは必要ではありません。 FAがリンク州のプロトコルにいったん広告に掲載されると、ルーティングLSPsのための用法はアルゴリズムが実装した経路計算と交通工学によって定義されます。
It should be noted that at the IP-optical interface, the physical ports over which routers are connected to OXCs constrain the connectivity and resource availability. Suppose a router R1 is connected to OXC O1 over two ports, P1 and P2. Under integrated routing, the connectivity between R1 and O1 over the two ports would have been captured in the link state representation of the network. Now, suppose an FA at full port bandwidth is created from R1 to another router R2 over port P1. While this FA is advertised as a virtual link between R1 and R2, it is also necessary to remove the link R1-O1 (over P1) from the link state representation since that port is no longer available for creating a lightpath. Thus, as FAs are created, an overlaid set of virtual links is introduced into the link state representation, replacing the links previously advertised at the IP-Optical interface. Finally, the details of the optical network captured in the link state representation is replaced by a network of FAs. The above scheme is one way to tackle the problem. Another approach is to associate appropriate dynamic attributes with link state information, so that a link that cannot be used to establish a particular type of connection will be appropriately tagged. Generally, however, there is a great deal of similarity between integrated routing and domain-specific routing (described next). Both ultimately deal with the creation of a virtual lightpath topology (which is overlaid over the optical network) to meet certain traffic engineering objectives.
IP光学のインタフェースでは、ルータがOXCsに接続される物理的なポートが接続性とリソースの有用性を抑制することに注意されるべきです。 ルータであるなら、R1は2つのポート、P1、およびP2の上でOXC O1に接続されます。 統合ルーティングの下では、ネットワークのリンク州の代理で2つのポートの上のR1とO1の間の接続性を得たでしょう。 今度は、完全なポート帯域幅のFAがR1から別のルータR2までポートP1の上に作成されると仮定してください。 このFAはR1とR2との仮想のリンクとして広告に掲載されていますが、また、そのポートがもうlightpathを作成するのに利用可能でないので、リンク州の表現からリンクR1-O1(P1の上の)を取り外すのも必要です。 したがって、FAsが作成されるとき、かぶせられたセットの仮想のリンクはリンク州の表現に取り入れられます、以前にIP光学のインタフェースの広告に掲載されたリンクを取り替えて。 最終的に、リンク州の表現で得られた光学ネットワークの細部をFAsのネットワークに取り替えます。 上の体系は問題に取り組むことにおいて一方通行です。 別のアプローチは適切なダイナミックな属性をリンク州の情報に関連づけることです、特定のタイプの接続を証明するのに使用できないリンクが適切にタグ付けをされるように。 一般に、しかしながら、統合ルーティングとドメイン特有のルーティング(次に、説明される)の間には、多くの類似性があります。 両方が、結局、ある交通工学目的を満たすために仮想のlightpathトポロジー(光学ネットワークの上でかぶせられる)の作成に対処します。
5.2.2. Domain-Specific Routing
5.2.2. ドメイン特有のルート設定
The domain-specific routing approach supports the augmented interconnection model. Under this approach, routing within the optical and IP domains are separated, with a standard routing protocol running between domains. This is similar to the IP inter- domain routing model. A specific approach for this is considered next. It is to be noted that other approaches are equally possible.
ドメイン特有のルーティングアプローチは増大しているインタコネクトモデルをサポートします。 このアプローチの下では、掘って、中に、標準のルーティング・プロトコルがドメインの間で稼働であっている中に、光学とIPドメインは切り離されます。 これはIP相互ドメインルーティングモデルと同様です。 これのための特定のアプローチは次に、考えられます。 他のアプローチが等しく可能であることに注意されることになっています。
5.2.2.1. Domain-Specific Routing using BGP
5.2.2.1. BGPを使用するドメイン特有のルート設定
The inter-domain IP routing protocol, BGP [8], may be adapted for exchanging routing information between IP and optical domains. This would allow routers to advertise IP address prefixes within their network to the optical internetwork and to receive external IP address prefixes from the optical internetwork. The optical internetwork transports the reachability information from one IP
相互ドメインIPルーティング・プロトコル(BGP[8])は、IPと光学ドメインの間でルーティング情報を交換するために適合させられるかもしれません。 これで、ルータは、それらのネットワークの中にIPアドレス接頭語の光学インターネットワークに広告を出して、光学インターネットワークから外部のIPアドレス接頭語を受け取るでしょう。 光学インターネットワークは1IPからの可到達性情報を輸送します。
Rajagopalan, et al. Informational [Page 19] RFC 3717 IP over Optical Networks: A Framework March 2004
Rajagopalan、他 光学ネットワークの上の情報[19ページ]のRFC3717IP: 2004年のフレームワーク行進
network to others. For instance, edge routers and OXCs can run exterior BGP (EBGP). Within the optical internetwork, interior BGP (IBGP) is may be used between border optical switches, and EBGP may be used between different networks (over ENNI, Figure 1).
他のものにネットワークでつなぎます。 例えば、縁のルータとOXCsは外のBGP(EBGP)を実行できます。 内部のBGP(IBGP)による境界の光学スイッチの間で使用されるかもしれなくて、EBGPが異なったネットワーク(ENNIの上で図1)の間で使用されるかもしれないという光学インターネットワークの中では、ことです。
Under this scheme, it may be necessary to identify the egress points in the optical internetwork corresponding to externally reachable IP addresses. To see this, suppose an edge router intends to establish an LSP to a destination node across the optical internetwork. It may request a direct lightpath to that destination, without explicitly specifying the egress optical port for the lightpath because the optical internetwork has knowledge of externally reachable IP addresses. However, if the same edge router were to establish another LSP to a different external destination, then for efficiency reasons, it may first need to determine whether there is an existing lightpath (with sufficient residual capacity) to the target destination. For this purpose, it may be necessary for edge routers to keep track of which egress ports in the optical internetwork lead to which external destinations. Thus, a border OXC receiving external IP prefixes from an edge router through EBGP must include its own IP address as the egress point before propagating these prefixes to other border OXCs or edge routers. An edge router receiving this information need not propagate the egress address further, but it must keep the association between external IP addresses and egress OXC addresses. When optical VPNs are implemented, the address prefixes advertised by the border OXCs may be accompanied by some VPN specific identification.
この体系の下では、外部的に届いているIPアドレスに対応する光学インターネットワークで出口ポイントを特定するのが必要であるかもしれません。 これを見るには、縁のルータが光学インターネットワークの向こう側に目的地ノードにLSPを設立するつもりであると仮定してください。 それはその目的地にダイレクトlightpathを要求するかもしれません、光学インターネットワークには外部的に届いているIPアドレスに関する知識があるので明らかに出口の光学港をlightpathに指定しないで。 しかしながら、同じ縁のルータが異なった外部の目的地に別のLSPを設立することであったなら、効率理由で、それは、最初に、目標の目的地には既存のlightpathがあるかを(十分な残りの容量で)決定する必要があるかもしれません。 このために、それが動向をおさえる光学インターネットワークにおける出口港がどの外部の目的地に導く縁のルータに必要であるかもしれません。 したがって、他の境界OXCsか縁のルータにこれらの接頭語を伝播するポイント前に、EBGPを通して縁のルータから外部のIP接頭語を受け取る境界OXCは出口としてそれ自身のIPアドレスを含まなければなりません。 この情報を受け取る縁のルータはさらに出口アドレスを伝播する必要はありませんが、それは外部のIPアドレスと出口OXCアドレスの協会を間に置かなければなりません。 光学VPNsが実装されるとき、何らかのVPNの特定の識別で境界OXCsによって広告に掲載されたアドレス接頭語は伴われるかもしれません。
There are however, some potential negative effects that could result from domain-specific routing using BGP in an IPO environment:
しかしながら、何らかの可能性に、IPO環境でBGPを使用することでドメイン特有のルーティングから生じることができるだろうマイナスの効果があります:
o The amount of information that optical nodes will have to maintain
will not be bound by the size of the optical network anymore, but
will have to include external routes as well.
o 光学ノードが維持しなければならない情報量は、それ以上光学ネットワークのサイズによって縛られませんが、また、外部経路を含まなければならないでしょう。
o The stability of the optical network control plane will no longer
be dictated solely by the dynamics emanating within the optical
network, but may be affected by the dynamics originating from
external routing domains from which external reachability
information is received.
o 光学ネットワーク制御飛行機の安定性は、もう唯一光学ネットワークの中で発する力学によって書き取られませんが、外部の可到達性情報が受信されている外部の経路ドメインから発する力学で影響を受けるかもしれません。
5.2.3. Overlay Routing
5.2.3. オーバレイルート設定
The overlay routing approach supports the overlay interconnection model. Under this approach, an overlay mechanism that allows edge routers to register and query for external addresses is implemented. This is conceptually similar to the address resolution mechanism used for IP over ATM. Under this approach, the optical network could
オーバレイルーティングアプローチはオーバレイインタコネクトモデルをサポートします。 このアプローチで、外部アドレスのためにそれで縁のルータを登録して、質問するオーバレイメカニズムは実装されます。 これは概念的にIPにATMの上で使用されるアドレス解決メカニズムと同様です。 このアプローチで、光学ネットワークはそうすることができました。
Rajagopalan, et al. Informational [Page 20] RFC 3717 IP over Optical Networks: A Framework March 2004
Rajagopalan、他 光学ネットワークの上の情報[20ページ]のRFC3717IP: 2004年のフレームワーク行進
implement a registry that allows edge routers to register IP addresses and VPN identifiers. An edge router may be allowed to query for external addresses belonging to the same set of VPNs it belongs to. A successful query would return the address of the egress optical port through which the external destination can be reached.
縁のルータがIPアドレスを登録できる登録とVPNが識別子であると実装してください。 縁のルータはそれが属すVPNsの同じセットに属す外部アドレスのための質問に許容されるかもしれません。 うまくいっている質問は外部の目的地に達することができる出口の光学港のアドレスを返すでしょう。
Because IP-optical interface connectivity is limited, the determination of how many lightpaths must be established and to what endpoints are traffic engineering decisions. Furthermore, after an initial set of such lightpaths are established, these may be used as adjacencies within VPNs for a VPN-wide routing scheme, for example, OSPF. With this approach, an edge router could first determine other edge routers of interest by querying the registry. After it obtains the appropriate addresses, an initial overlay lightpath topology may be formed. Routing adjacencies may then be established across the lightpaths and further routing information may be exchanged to establish VPN-wide routing.
IP光学のインタフェースの接続性が限られているので、いくつのlightpathsの決断を確立しなければならないか、そして、どんな終点には、交通工学決定があるか。 その上、1人の始発のそのようなlightpathsが設立された後にこれらはVPN全体のルーティング体系、例えば、OSPFに隣接番組としてVPNsの中で使用されるかもしれません。 このアプローチで、縁のルータは、最初に、登録について質問することによって、興味がある他の縁のルータを決定するかもしれません。 適切なアドレスを得た後に、初期のオーバレイlightpathトポロジーは形成されるかもしれません。 次に、lightpathsの向こう側にルート設定隣接番組を確立するかもしれません、そして、VPN全体のルーティングを証明するためにさらなるルーティング情報を交換するかもしれません。
5.3. Signaling-Related
5.3. シグナリング関連です。
5.3.1. The Role of MPLS
5.3.1. MPLSの役割
It is possible to model wavelengths, and potentially TDM channels within a wavelength as "labels". This concept was proposed in [1], and "generalized" MPLS (GMPLS) mechanisms for realizing this are described in [4]. MPLS signaling protocols with traffic engineering extensions, such as RSVP-TE, can be appropriately extended and used for signaling lightpath requests. These protocols can be adapted for client/server signaling in the case of the domain services model, and for end-to-end integrated signaling in the case of the unified services model.
「ラベル」として波長の中で波長、および潜在的にTDMチャンネルをモデル化するのは可能です。 この概念は[1]で提案されました、そして、これがわかるための「一般化された」MPLS(GMPLS)メカニズムは[4]で説明されます。 シグナリングlightpath要求にMPLSはRSVP-TEなどの交通工学拡大でプロトコルに合図して、適切に広げていて、使用できます。 ドメインサービスモデルの場合におけるクライアント/サーバシグナリング、および統一されたサービスモデルの場合における終わらせる終わりの統合シグナリングのためにこれらのプロトコルを適合させることができます。
5.3.2. Signaling Models
5.3.2. シグナリングモデル
With the domain-services model, the signaling control plane in the IP and optical network are completely separate as shown in Figure 3 below. This separation also implies the separation of IP and optical address spaces (even though the optical network would be using internal IP addressing). While RSVP-TE and LDP can be adapted for UNI signaling, the full functionality of these protocols will not be used. For example, UNI signaling does not require the specification of explicit routes. On the other hand, based on the service attributes, new objects need to be signaled using these protocols as described in [5, 6].
ドメインサービスで、モデル、IPと光学ネットワークにおけるシグナリング制御飛行機は以下の図3に示されるように完全に別々です。 また、この分離はIPと光学アドレス空間の分離を含意します(光学ネットワークは内部のIPアドレシングを使用しているでしょうが)。 UNIシグナリングのためにRSVP-TEと自由民主党を適合させることができる間、これらのプロトコルの完全な機能性は使用されないでしょう。 例えば、UNIシグナリングは明白なルートの仕様を必要としません。 他方では、サービス属性に基づいて、新しいオブジェクトは、[5、6]で説明されるようにこれらのプロトコルを使用することで合図される必要があります。
Rajagopalan, et al. Informational [Page 21] RFC 3717 IP over Optical Networks: A Framework March 2004
Rajagopalan、他 光学ネットワークの上の情報[21ページ]のRFC3717IP: 2004年のフレームワーク行進
MPLS Signaling UNI Signaling MPLS or other signaling
|
+-----------------------------+ | +-----------------------------+
| IP Network | | | Optical Internetwork |
| +---------+ +---------+ | | | +---------+ +---------+ |
| | | | | | | | | | | | |
| | Router +---+ Router +-----+------+ OXC +---+ OXC | |
| | | | | | | | | | | | |
| +-----+---+ +---+-----+ | | | +-----+---+ +---+-----+ |
+-----------------------------+ | +-----------------------------+
|
|
Completely Separated Addressing and Control Planes
MPLS Signaling UNI Signaling MPLSか他のシグナリング| +-----------------------------+ | +-----------------------------+ | IPネットワーク| | | 光学インターネットワーク| | +---------+ +---------+ | | | +---------+ +---------+ | | | | | | | | | | | | | | | | ルータ+---+ ルータ+-----+------+ OXC+---+ OXC| | | | | | | | | | | | | | | | +-----+---+ +---+-----+ | | | +-----+---+ +---+-----+ | +-----------------------------+ | +-----------------------------+ | | 完全に切り離されたアドレシングと制御飛行機
Figure 3: Domain Services Signaling Model
図3: ドメインサービスシグナリングはモデル化されます。
With the unified services model, the addressing is common in the IP network and optical internetwork and the respective signaling control are related, as shown in Figure 4. It is understood that GMPLS signaling is implemented in the IP and optical domains, using suitably enhanced RSVP-TE or CR-LDP protocols. But the semantics of services within the optical internetwork may be different from that in the IP network. As an example, the protection services offered in the optical internetwork may be different from the end-to-end protection services offered by the IP network. Another example is with regard to bandwidth. While the IP network may offer a continuum of bandwidths, the optical internetwork will offer only discrete bandwidths. Thus, the signaling attributes and services are defined independently for IP and optical domains. The routers at the edge of the optical internetwork must therefore identify service boundaries and perform suitable translations in the signaling messages crossing the IP-optical boundary. This may still occur even though the signaling control plane in both networks are GMPLS-based and there is tighter coupling of the control plane as compared to the domain services model.
統一されたサービスモデルについて、アドレシングはIPネットワークと光学インターネットワークで一般的です、そして、それぞれのシグナリングコントロールは関係づけられます、図4に示されるように。 GMPLSシグナリングがIPと光学ドメインで実装されるのが理解されています、適当に高められたRSVP-TEかCR-自由民主党プロトコルを使用して。 しかし、光学インターネットワークの中のサービスの意味論はそれとIPネットワークにおいて異なっているかもしれません。 例として、光学インターネットワークで提供された保護サービスは終わりから終わりに対する保護IPネットワークによって提供されたサービスと異なっているかもしれません。 帯域幅に関して別の例はあります。 IPネットワークが帯域幅の連続を提供しているかもしれない間、光学インターネットワークは離散的な帯域幅だけを提供するでしょう。 したがって、シグナリング属性とサービスは独自にIPと光学ドメインと定義されます。 光学インターネットワークの縁のルータは、IP光学の境界に交差しながら、したがって、サービス境界を特定して、シグナリングメッセージにおける適当な翻訳を実行しなければなりません。 両方のネットワークにおけるシグナリング制御飛行機はGMPLSベースです、そして、ドメインサービスモデルと比べて、制御飛行機のカップリングが、よりきつくありますが、これはまだ起こっているかもしれません。
Rajagopalan, et al. Informational [Page 22] RFC 3717 IP over Optical Networks: A Framework March 2004
Rajagopalan、他 光学ネットワークの上の情報[22ページ]のRFC3717IP: 2004年のフレームワーク行進
Service Boundary Service Boundary
| |
IP Layer GMPLS Signaling | Optical Layer GMPLS | IP Layer GMPLS
| |
+--------+ +--------+ | +-------+ +-------+ | +--------+
| | | | | | | | | | | |
| IP LSR +--+ IP LSR +--+--+Optical+--+Optical+-+--+ IP LSR +---
| | | | | | LSR | | LSR | | | |
+-----+--+ +---+----+ | +-----+-+ +---+---+ | +--------+
サービス境界サービス境界| | IP層のGMPLSシグナリング| 光学層のGMPLS| IP層のGMPLS| | +--------+ +--------+ | +-------+ +-------+ | +--------+ | | | | | | | | | | | | | IP LSR+--+ IP LSR+--+--+ 光学+--+ 光学++--+ IP LSR+--- | | | | | | LSR| | LSR| | | | +-----+--+ +---+----+ | +-----+-+ +---+---+ | +--------+
Common Address Space, Service Translation
一般的なアドレス空間、サービス翻訳
Figure 4: Unified Services Signaling Model
図4: 統一されたサービスシグナリングはモデル化されます。
Thus, as illustrated in Figure 4, the signaling in the case of unified services is actually multi-layered. The layering is based on the technology and functionality. As an example, the specific adaptations of GMPLS signaling for SONET layer (whose functionality is transport) are described in [10].
したがって、図4で例証されるように、統一されたサービスの場合におけるシグナリングは実際に多層性です。 レイヤリングは技術と機能性に基づいています。 例として、Sonet層(機能性は輸送である)のために合図するGMPLSの特定の適合は[10]で説明されます。
5.4. End-to-End Protection Models
5.4. 終わりから終わりへの保護モデル
Suppose an LSP is established from an ingress IP router to an egress router across an ingress IP network, a transit optical internetwork and an egress IP network. If this LSP is to be afforded protection in the IP layer, how is the service coordinated between the IP and optical layers?
LSPがイングレスIPネットワーク、トランジットの光学インターネットワーク、および出口IPネットワークの向こう側にイングレスIPルータから出口ルータまで設立されると仮定してください。 このLSPによるIP層における都合された保護であるつもりであるなら、サービスはIPと光学層の間でどのように調整されますか?
Under this scenario, there are two approaches to end-to-end protection:
このような筋書で、終わりから終わりへの保護への2つのアプローチがあります:
5.4.1. Segment-Wise Protection
5.4.1. セグメント的な保護
The protection services in the IP layer could utilize optical layer protection services for the LSP segment that traverses the optical internetwork. Thus, the end-to-end LSP would be treated as a concatenation of three LSP segments from the protection point of view: a segment in the ingress IP network, a segment in the optical internetwork and a segment in the egress IP network. The protection services at the IP layer for an end-to-end LSP must be mapped onto suitable protection services offered by the optical internetwork. Suppose that 1+1 protection is offered to LSPs at the IP layer, i.e., each protected LSP has a pre-established hot stand-by in a 1+1 or 1:1 configuration. In case of a failure of the primary LSP, traffic can be immediately switched to the stand-by. This type of protection can be realized end-to-end as follows. With reference to Figure 5, let an LSP originate at (ingress) router interface A and terminate at (egress) router interface F. Under the first protection option, a
IP層における保護サービスは光学インターネットワークを横断するLSPセグメントのための光の層の保護サービスを利用するかもしれません。 したがって、終わりから終わりへのLSPは保護観点から3つのLSPセグメントの連結として扱われるでしょう: イングレスIPネットワークにおけるセグメント、光学インターネットワークにおけるセグメント、および出口IPネットワークにおけるセグメント。 終わりから終わりへのLSPのためのIP層での保護サービスを光学インターネットワークによって提供された適当な保護サービスに写像しなければなりません。 1+1保護をIP層のLSPsに提供して、すなわち、それぞれの保護されたLSPが1つの+1か1:1構成でプレ確立した高温待機を持っていると仮定してください。 プライマリLSPの失敗の場合には、すぐに、トラフィックを予備に切り換えることができます。 このタイプの保護は、実感された以下の終わりから終わりであるかもしれません。 図5に関して、LSPに最初の保護オプションを(イングレス)ルータインタフェースAで溯源して、(出口)ルータインタフェースF.Underで終えさせてください、a
Rajagopalan, et al. Informational [Page 23] RFC 3717 IP over Optical Networks: A Framework March 2004
Rajagopalan、他 光学ネットワークの上の情報[23ページ]のRFC3717IP: 2004年のフレームワーク行進
primary path for the LSP must be established first. Let this path be as shown in Figure 5, traversing router interface B in the ingress network, optical ports C (ingress) and D (egress), and router interface E in the egress network. Next, 1+1 protection is realized separately in each network by establishing a protection path between points A and B, C and D and E and F. Furthermore, the segments B-C and D-E must themselves be 1+1 protected, using drop- side protection. For the segment between C and D, the optical internetwork must offer a 1+1 service similar to that offered in the IP networks.
最初に、LSPのためのプライマリ経路を確立しなければなりません。 図5でこの経路が示されるとしてそうであることをさせてください、出口ネットワークにおけるイングレスネットワーク、光学ポートC(イングレス)とD(出口)、およびルータインタフェースEでルータインタフェースBを横断して。 次に、1+1保護は、別々に各ネットワークで低下サイド保護を使用することで+1が保護した1、自分たちでAとBとCとDとEとF.Furthermore、セグメントB-CとD-Eがそうしなければならないポイントの間の保護経路を確立することによって、実現されます。 CとDの間のセグメントのために、光学インターネットワークはIPネットワークで提供されたそれと同様の1+1サービスを提供しなければなりません。
+----------------+ +------------------+ +---------------+ | | | | | | A Ingress IP Net B----C Optical Internet D----E Egress IP Net F | | | | | | +----------------+ +------------------+ +---------------+
+----------------+ +------------------+ +---------------+ | | | | | | イングレスIPネットB----Cの光学インターネットD----E出口IPネットF| | | | | | +----------------+ +------------------+ +---------------+
Figure 5: End-to-End Protection Example
図5: 終わりから終わりへの保護例
5.4.2. Single-Layer Protection
5.4.2. 単一層保護
Under this model, the protection services in the IP layer do not rely on any protection services offered in the optical internetwork. Thus, with reference to Figure 5, two SRLG-disjoint LSPs are established between A and F. The corresponding segments in the optical internetwork are treated as independent lightpaths in the optical internetwork. These lightpaths may be unprotected in the optical internetwork.
このモデルの下では、IP層における保護サービスは光学インターネットワークで提供された少しの保護サービスにも依存しません。 その結果、図5、twoに関してSRLGばらばらになっているLSPsはAとF.の間に設立されます。光学インターネットワークにおける対応するセグメントは光学インターネットワークで独立しているlightpathsとして扱われます。 これらのlightpathsは光学インターネットワークにおいて保護がないかもしれません。
5.4.3. Differences
5.4.3. 違い
A distinction between these two choices is as follows. Under the first choice, the optical internetwork is actively involved in end- to-end protection, whereas under the second choice, any protection service offered in the optical internetwork is not utilized directly by client IP network. Also, under the first choice, the protection in the optical internetwork may apply collectively to a number of IP LSPs. That is, with reference to Figure 5, many LSPs may be aggregated into a single lightpath between C and D. The optical internetwork protection may then be applied to all of them at once leading to some gain in scalability. Under the second choice, each IP LSP must be separately protected. Finally, the first choice allows different restoration signaling to be implemented in the IP and optical internetwork. These restoration protocols are "patched up" at the service boundaries to realize end-to-end protection. A further advantage of this is that restoration is entirely contained within the network where the failure occurs, thereby improving the restoration latency, and perhaps network stability as a fault within
これらの2つの選択の区別は以下の通りです。 最初の選択で、光学インターネットワークで提供された少しの保護サービスも第二希望で直接クライアントIPネットワークによって利用されませんが、光学インターネットワークは活発に終わりまでの終わりの保護にかかわります。 また、最初の選択で、光学インターネットワークにおける保護は多くのIP LSPsにまとめて適用されるかもしれません。 すなわち、図5に関して多くのLSPsがCとD.の間の単一のlightpathに集められるかもしれません。次に、光のインターネットワーク保護は、すぐにスケーラビリティにおける何らかの利得に通じながら、彼らのすべてに適用されるかもしれません。 第二希望で、別々に各IP LSPを保護しなければなりません。 最終的に、最初の選択はIPと光学インターネットワークで実装されるのを示す異なった回復を許容します。 これらの回復プロトコルは、終わりから終わりへの保護がわかるためにサービス境界で「繕われます」。 さらなるこの利点は回復が中に欠点としての失敗が起こるネットワーク、その結果、回復潜在を改良して、および恐らくネットワークの安定性の中に完全に含まれているということです。
Rajagopalan, et al. Informational [Page 24] RFC 3717 IP over Optical Networks: A Framework March 2004
Rajagopalan、他 光学ネットワークの上の情報[24ページ]のRFC3717IP: 2004年のフレームワーク行進
an optical domain is contained and corrected within the domain. For instance, if there is a failure in the optical internetwork, optical network protocols restore the affected internal segments. Under the second choice, restoration signaling is always end-to-end between IP routers, essentially by-passing the optical internetwork. A result of this is that restoration latency could be higher. In addition, restoration protocols in the IP layer must run transparently over the optical internetwork in the overlay mode. IP based recovery techniques may however be more resource efficient, as it may be possible to convey traffic through the redundant capacity under fault-free scenarios. In particular, it may be possible to utilize classification, scheduling, and concepts of forwarding equivalence class to route lower class traffic over protect facilities and then possibly preempt them to make way for high priority traffic when faults occur.
光学ドメインは、ドメインの中で保管されていて、修正されます。 例えば、光学インターネットワークに失敗があれば、光学ネットワーク・プロトコルは影響を受ける内節を回復します。 第二希望で、光学インターネットワークを本質的には迂回させて、いつも、回復シグナリングは、IPルータの間の終わりから終わりです。 この結果は回復潜在が、より高いかもしれないということです。 さらに、IP層の回復プロトコルは透過的にオーバレイモードによる光学インターネットワークをひかなければなりません。 しかしながら、IPのベースのリカバリ技術は、より多くのリソース効率的であるかもしれません、無欠点のシナリオの下における余分な容量を通してトラフィックを伝えるのが可能であるときに。 分類を利用するのは特に、可能であるかもしれません、計画をしていて、労働者階級トラフィックを発送する推進同値類の概念は、施設を保護して、欠点が起こると、次に、高い優先権トラフィックに道をあけるためにことによるとそれらを先取りします。
6. IP-based Optical Control Plane Issues
6. IPベースの光学コントロール飛行機問題
Provisioning and restoring lightpaths end-to-end between IP networks requires protocol and signaling support within optical sub-networks, and across the INNI and ENNI. In this regard, a distinction is made between control procedures within an optical sub-network (Figure 1), between sub-networks, and between networks. The general guideline followed in this framework is to separate these cases, and allow the possibility that different control procedures are followed inside different sub-networks, while a common set of procedures are followed across sub-networks and networks.
IPネットワークの間の終わりから終わりが必要とするlightpathsに食糧を供給して、返すのは議定書を作ります、そして、シグナリングは光学サブネットワーク、以内に横切ってINNIとENNIをサポートします。 この点で、光学サブネットワーク(図1)の中のコントロール手順の間と、そして、サブネットワークの間と、そして、ネットワークの間で区別をします。 このフレームワークで従った一般的ガイドラインは、これらのケースを分離して、異なったサブネットワークで異なったコントロール手順に従っている可能性を許容することです、一般的なセットの手順はサブネットワークとネットワークの向こう側に従われていますが。
The control plane procedures within a single vendor sub-network need not be defined since these can be proprietary. Clearly, it is possible to follow the same control procedures inside a sub-network and across sub-networks. But this is simply a recommendation within this framework document, rather than an imperative requirement. Thus, in the following, signaling and routing across sub-networks is considered first, followed by a discussion of similar issues across networks.
これらが独占である場合があるので、ただ一つのベンダーサブネットワークの中のコントロール飛行機手順は定義される必要はありません。 明確に、サブネットワークの中と、そして、サブネットワークの向こう側に同じコントロール手順に従うのは可能です。 しかし、これは単に必須の要件よりむしろこのフレームワークドキュメントの中の推薦です。 したがって、以下では、サブネットワークの向こう側のシグナリングとルーティングは同様の問題の議論がネットワークの向こう側にいうことになった1番目であると考えられます。
6.1. Addressing
6.1. アドレシング
For interoperability across optical sub-networks using an IP-centric control plane, one of the fundamental issues is that of addressing. What entities should be identifiable from a signaling and routing point of view? How should they be addressed? This section presents some high level guidelines on this issue.
IP中心の制御飛行機を使用する光学サブネットワークの向こう側の相互運用性のために、基本的な問題の1つはアドレシングのものです。 どんな実体がシグナリングとルーティング観点から身元保証可能であるべきですか? それらはどのように扱われるべきですか? このセクションはこの問題に関するいくつかの高い平らなガイドラインを提示します。
Rajagopalan, et al. Informational [Page 25] RFC 3717 IP over Optical Networks: A Framework March 2004
Rajagopalan、他 光学ネットワークの上の情報[25ページ]のRFC3717IP: 2004年のフレームワーク行進
Identifiable entities in optical networks include OXCs, optical links, optical channels and sub-channels, Shared Risk Link Groups (SRLGs), etc. An issue here is how granular the identification should be as far as the establishment of optical trails are concerned. The scheme for identification must accommodate the specification of the termination points in the optical network with adequate granularity when establishing optical trails. For instance, an OXC could have many ports, each of which may in turn terminate many optical channels, each of which contain many sub-channels etc. It is perhaps not reasonable to assume that every sub-channel or channel termination, or even OXC ports could be assigned a unique IP address. Also, the routing of an optical trail within the network does not depend on the precise termination point information, but rather only on the terminating OXC. Thus, finer granularity identification of termination points is of relevance only to the terminating OXC and not to intermediate OXCs (of course, resource allocation at each intermediate point would depend on the granularity of resources requested). This suggests an identification scheme whereby OXCs are identified by a unique IP address and a "selector" identifies further fine-grain information of relevance at an OXC. This, of course, does not preclude the identification of these termination points directly with IP addresses(with a null selector). The selector can be formatted to have adequate number of bits and a structure that expresses port, channel, sub-channel, etc, identification.
光学ネットワークにおける身元保証可能な実体はOXCsと光学リンクと光学チャンネルとサブチャンネル、Shared Risk Link Groups(SRLGs)などを含んでいます。 ここの問題は光学道の設立に関する限り、識別がどれくらい粒状であるべきであるかということです。 光学道を確立するとき、識別の体系は適切な粒状と共に光学ネットワークで終了ポイントの仕様に対応しなければなりません。 例えば、OXCは多くのポートを持つことができました。それはそれぞれ順番に多くの光学チャンネルを終えるかもしれません。それはそれぞれ多くのサブチャンネルなどを含みます。 それがあらゆるサブチャンネルかチャンネル終了であると仮定するのが恐らく妥当でないか、またはOXCポートにさえ固有のIPアドレスは割り当てることができました。 また、ネットワークの中の光学道のルーティングは正確な終了ポイント情報、しかし、むしろ終わっているOXCだけによりません。 したがって、終了ポイントの、よりよい粒状識別は中間的OXCsではなく、終わっているOXCだけへの関連性のもの(もちろん、それぞれの中間的ポイントの資源配分は要求されたリソースの粒状による)です。 これは、OXCsが固有のIPアドレスと「セレクタ」によって特定される識別体系がOXCで関連性のさらにすばらしい粒の情報を特定するのを示します。 これはもちろん直接IPアドレス(ヌルセレクタがある)によるこれらの終了ポイントの識別を排除しません。 ポート、チャンネル、サブチャンネル(識別)などを言い表すビットと構造の適切な数を持つためにセレクタをフォーマットできます。
Within the optical network, the establishment of trail segments between adjacent OXCs require the identification of specific port, channel, sub-channel, etc. With a GMPLS control plane, a label serves this function. The structure of the label must be such that it can encode the required information [10].
光学ネットワークの中では、隣接しているOXCsの間の道のセグメントの設立は特定のポート、チャンネル、サブチャンネルなどの識別を必要とします。 GMPLS制御飛行機で、ラベルはこの機能を果たします。 ラベルの構造は必須情報[10]をコード化できるようにものであるに違いありません。
Another entity that must be identified is the SRLG [11]. An SRLG is an identifier assigned to a group of optical links that share a physical resource. For instance, all optical channels routed over the same fiber could belong to the same SRLG. Similarly, all fibers routed over a conduit could belong to the same SRLG. The notable characteristic of SRLGs is that a given link could belong to more than one SRLG, and two links belonging to a given SRLG may individually belong to two other SRLGs. This is illustrated in Figure 6. Here, the links 1,2,3 and 4 may belong to SRLG 1, links 1,2 and 3 could belong to SRLG 2 and link 4 could belong to SRLG 3. Similarly, links 5 and 6 could belong to SRLG 1, and links 7 and 8 could belong to SRLG 4. (In this example, the same SRLG, i.e., 1, contains links from two different adjacencies).
特定しなければならない別の実体はSRLG[11]です。 SRLGは物理資源を共有する光学リンクのグループに配属された識別子です。 例えば、同じファイバーの上に発送されたすべての光学チャンネルが同じSRLGに属すことができました。 同様に、経路の上に発送されたすべてのファイバーが同じSRLGに属すかもしれません。 SRLGsの顕著な特徴は与えられたリンクが1SRLGに属すかもしれないということです、そして、与えられたSRLGに属す2個のリンクが個別に他の2SRLGsに属すかもしれません。 これは図6で例証されます。 ここで、リンク1、2、3、および4はSRLG1に属すかもしれません、そして、リンク1、2、および3はSRLG2に属すかもしれません、そして、リンク4はSRLG3に属すかもしれません。 同様に、リンク5と6はSRLG1に属すかもしれません、そして、リンク7と8はSRLG4に属すかもしれません。 (この例では、同じSRLG(すなわち、1)は2つの異なった隣接番組からのリンクを含んでいます。)
Rajagopalan, et al. Informational [Page 26] RFC 3717 IP over Optical Networks: A Framework March 2004
Rajagopalan、他 光学ネットワークの上の情報[26ページ]のRFC3717IP: 2004年のフレームワーク行進
While the classification of physical resources into SRLGs is a manual operation, the assignment of unique identifiers to these SRLGs within an optical network is essential to ensure correct SRLG- disjoint path computation for protection. SRLGs could be identified with a flat identifier (e.g., 32 bit integer).
SRLGsへの物理資源の分類は手動ですが、光学ネットワークの中のこれらのSRLGsへのユニークな識別子の課題は、正しいSRLGが保護のための経路計算をばらばらにならせるのを保証するのに不可欠です。 平坦な識別子(例えば、32ビットの整数)とSRLGsを同一視できました。
Finally, optical links between adjacent OXCs may be bundled for advertisement into a link state protocol [12]. A bundled interface may be numbered or unnumbered. In either case, the component links within the bundle must be identifiable. In concert with SRLG identification, this information is necessary for correct path computation.
最終的に、隣接しているOXCsの間の光学リンクは広告のためにリンク州のプロトコル[12]に添付されるかもしれません。 添付されたインタフェースは、番号付である、または無数であるかもしれません。 どちらかの場合では、バンドルの中のコンポーネントリンクは身元保証可能であるに違いありません。 SRLG識別と協力して、この情報が正しい経路計算に必要です。
6.2. Neighbor Discovery
6.2. 隣人発見
Routing within the optical network relies on knowledge of network topology and resource availability. This information may be gathered and used by a centralized system, or by a distributed link state routing protocol. In either case, the first step towards network- wide link state determination is the discovery of the status of local links to all neighbors by each OXC. Specifically, each OXC must determine the up/down status of each optical link, the bandwidth and other parameters of the link, and the identity of the remote end of the link (e.g., remote port number). The last piece of information is used to specify an appropriate label when signaling for lightpath provisioning. The determination of these parameters could be based on a combination of manual configuration and an automated protocol running between adjacent OXCs. The characteristics of such a protocol would depend on the type of OXCs that are adjacent (e.g., transparent or opaque).
光学ネットワークの中のルート設定はネットワーク形態とリソースの有用性に関する知識を当てにします。 この情報は、集権制、または分配されたリンク州のルーティング・プロトコルによって集められて、使用されるかもしれません。 どちらかの場合では、ネットワークの広いリンク州の決断に向かった第一歩は各OXCによるすべての隣人への地方のリンクの状態の発見です。 明確に、各OXCはリンク(例えば、リモートポートナンバー)のリモートエンドについて上がるそれぞれ光学の/下に状態がリンクする、リンクの帯域幅と他のパラメタ、およびアイデンティティを決定しなければなりません。 情報の最後の断片は、lightpathの食糧を供給するために合図するとき、適切なラベルを指定するのに使用されます。 これらのパラメタの決断は隣接しているOXCsの間で稼働する手動の構成と自動化されたプロトコルの組み合わせに基づくことができました。 そのようなプロトコルの特性を隣接しているOXCsのタイプに頼っているだろう、(例えば、透明であるか不透明である、)
Neighbor discovery would typically require in-band communication on the bearer channels to determine local connectivity and link status. In the case of opaque OXCs with SONET termination, one instance of a neighbor discovery protocol (e.g., LMP [2]) would run on each OXC port, communicating with the corresponding protocol instance at the neighboring OXC. The protocol would utilize the SONET overhead bytes to transmit the (configured) local attributes periodically to the neighbor. Thus, two neighboring switches can automatically determine the identities of each other and the local connectivity, and also keep track of the up/down status of local links. Neighbor discovery with transparent OXCs is described in [2].
隣人発見は、ローカルの接続性を決定して、状態をリンクするためにバンドにおける運搬人チャンネルに関するコミュニケーションを通常必要とするでしょう。 Sonetの終了がある不透明なOXCsの場合では、隣人発見の1つのインスタンスが議定書を作ります。(例えば、LMP[2])はそれぞれのOXCポートで走るでしょう、隣接しているOXCの対応するプロトコルインスタンスで交信して。 プロトコルは、定期的に(構成される)の地方の属性を隣人に伝えるのにSonetオーバーヘッドバイトを利用するでしょう。 したがって、2個の隣接しているスイッチが、自動的に互いのアイデンティティとローカルの接続性を決定して、また、上がるか下がることの道が地方のリンクの状態であることを保つことができます。 透明なOXCsとの隣人発見は[2]で説明されます。
Rajagopalan, et al. Informational [Page 27] RFC 3717 IP over Optical Networks: A Framework March 2004
Rajagopalan、他 光学ネットワークの上の情報[27ページ]のRFC3717IP: 2004年のフレームワーク行進
+--------------+ +------------+ +------------+
| +-1:OC48---+ +-5:OC192-+ |
| +-2:OC48---+ +-6:OC192-+ |
| OXC1 +-3:OC48---+ OXC2 +-7:OC48--+ OXC3 |
| +-4:OC192--+ +-8:OC48--+ |
| | | | +------+ |
+--------------+ +----+-+-----+ | +----+------+-----+
| | | | |
| | | | |
+--------------+ | | | | |
| | +----+-+-----+ | | +------+-----+
| +----------+ +--+ | | |
| OXC4 +----------+ +----+ | |
| +----------+ OXC5 +--------+ OXC6 |
| | | +--------+ |
+--------------+ | | | |
+------+-----+ +------+-----+
+--------------+ +------------+ +------------+ | +-1: OC48---+ +-5: OC192-+| | +-2: OC48---+ +-6: OC192-+| | OXC1+-3: OC48---+ OXC2+-7: OC48--、+ OXC3| | +-4: OC192--+ +-8: OC48--+| | | | | +------+ | +--------------+ +----+-+-----+ | +----+------+-----+ | | | | | | | | | | +--------------+ | | | | | | | +----+-+-----+ | | +------+-----+ | +----------+ +--+ | | | | OXC4+----------+ +----+ | | | +----------+ OXC5+--------+ OXC6| | | | +--------+ | +--------------+ | | | | +------+-----+ +------+-----+
Figure 6: Mesh Optical Network with SRLGs
図6: SRLGsと共に光学ネットワークを網の目にかけてください。
6.3. Topology Discovery
6.3. トポロジー発見
Topology discovery is the procedure by which the topology and resource state of all the links in a network are determined. This procedure may be done as part of a link state routing protocol (e.g., OSPF, ISIS), or it can be done via the management plane (in the case of centralized path computation). The implementation of a link state protocol within a network (i.e., across sub-network boundaries) means that the same protocol runs in OXCs in every sub-network. If this assumption does not hold then interworking of routing between sub- networks is required. This is similar to inter-network routing discussed in Section 6.7. The focus in the following is therefore on standardized link state routing.
トポロジー発見はネットワークにおけるすべてのリンクのトポロジーとリソース状態が決定している手順です。 リンク州のルーティング・プロトコル(例えば、OSPF、イシス)の一部としてこの手順をするかもしれませんか、または管理飛行機(集結された経路計算の場合における)を通してそれができます。 ネットワーク(すなわち、サブネットワーク境界の向こう側の)の中のリンク州のプロトコルの実装は、同じプロトコルがあらゆるサブネットワークでOXCsへ駆け込むことを意味します。 この仮定が成立しないなら、サブネットワークの間のルーティングを織り込むことが必要です。 これはセクション6.7で議論したインターネットワークルーティングと同様です。 以下の焦点がしたがって、標準化されたリンク州のルーティングにあります。
In general, most of the link state routing functionality is maintained when applied to optical networks. However, the representation of optical links, as well as some link parameters, are changed in this setting. Specifically,
一般に、光学ネットワークに適用されると、リンク州のルーティングの機能性の大部分は維持されます。 しかしながら、この設定で光学リンクの表現、およびいくつかのリンクパラメータを変えます。 明確に
o The link state information may consist of link bundles [12]. Each
link bundle is represented as an abstract link in the network
topology. Different bundling representations are possible. For
instance, the parameters of the abstract link may include the
number, bandwidth and the type of optical links contained in the
underlying link bundle [12]. Also, the SRLGs corresponding to
each optical link in the bundle may be included as a parameter.
o リンク州の情報はリンクバンドル[12]から成るかもしれません。 それぞれのリンクバンドルは抽象的なリンクとしてネットワーク形態に表されます。 異なったバンドリング表現は可能です。 例えば、抽象的なリンクのパラメタは基本的なリンクバンドル[12]に含まれた光学リンクの数、帯域幅、およびタイプを含むかもしれません。 また、バンドルでそれぞれの光学リンクに対応するSRLGsはパラメタとして含まれるかもしれません。
Rajagopalan, et al. Informational [Page 28] RFC 3717 IP over Optical Networks: A Framework March 2004
Rajagopalan、他 光学ネットワークの上の情報[28ページ]のRFC3717IP: 2004年の枠組みの行進
o The link state information should capture restoration-related
parameters for optical links. Specifically, with shared
protection (Section 6.5), the link state updates must have
information that allows the computation of shared protection
paths.
o リンク州の情報は光学リンクのための回復関連のパラメタを得るべきです。 明確に、リンク州のアップデートには、共有された保護(セクション6.5)によって、共有された保護経路の計算を許す情報がなければなりません。
o A single routing adjacency could be maintained between neighbors
which may have multiple optical links (or even multiple link
bundles) between them. This reduces the protocol messaging
overhead.
o 隣人の間でただ一つのルーティング隣接番組を維持できました(それらの間の複数の光学リンク(または、複数のリンクバンドルさえ)を持っているかもしれません)。 これはプロトコルメッセージングオーバーヘッドを下げます。
o Since link availability information changes dynamically, a
flexible policy for triggering link state updates based on
availability thresholds may be implemented. For instance, changes
in availability of links of a given bandwidth (e.g., OC-48) may
trigger updates only after the availability figure changes by a
certain percentage.
o 以来、ダイナミックに、リンク州のアップデートの引き金となるためのフレキシブルな方針が有用性敷居に基礎づけたリンク有用性情報変化は実行されるかもしれません。 例えば、ある割合に応じて有用性図が変化した後にだけ与えられた帯域幅(例えば、OC-48)のリンクの有用性における変化はアップデートの引き金となるかもしれません。
These concepts are relatively well-understood. On the other hand, the resource representation models and the topology discovery process for hierarchical routing (e.g., OSPF with multiple areas) are areas that need further work.
これらの概念がそうである、比較的、よく理解されています。 他方では、階層型ルーティング(例えば、複数の領域があるOSPF)のためのリソース表現モデルとトポロジー発見の過程はさらなる仕事を必要とする領域です。
6.4. Protection and Restoration Models
6.4. 保護と王政復古モデル
Automatic restoration of lightpaths is a service offered by optical networks. There could be local and end-to-end mechanisms for restoration of lightpaths within a network (across the INNI). Local mechanisms are used to select an alternate link (or network segment) between two OXCs across the INNI when a failure affects the primary link (or primary network segment) over which the (protected) lightpath is routed. Local restoration does not affect the end-to- end route of the lightpath. When local restoration is not possible (e.g., no alternate link is available between the adjacent OXCs in question), end-to-end restoration may be performed. Under this scenario this, the affected lightpath may be rerouted over an alternate diverse path to circumvent failed resources. For end-to- end restoration, alternate paths may be pre-computed to expedite the recovery time. End to end restoration may also be mixed with local recovery in various ways depending on acceptable tradeoffs between utilization of network resources and recovery times.
lightpathsの自動修復は光学ネットワークによって提供されたサービスです。 ネットワーク(INNIの向こう側の)の中のlightpathsの修復のためのメカニズムは、地方であり、終わりに終わることができました。 失敗が(保護されます)lightpathが発送される第一のリンク(または、第一のネットワークセグメント)に影響するとき、局所機構は、INNIの向こう側に2OXCsの間の交互のリンク(または、ネットワークセグメント)を選択するのに使用されます。 地方の回復は終わりから終わりへのlightpathのルートに影響しません。 地方の回復が可能でないときに(例えば、どんな交互のリンクも問題の隣接しているOXCsの間で利用可能ではありません)、終わりから終わりへの回復は実行されるかもしれません。 このような筋書でこれ、影響を受けるlightpathは、失敗したリソースを回避するために交互のさまざまの経路にわたって別ルートで送られるかもしれません。 終わりから終わりへの回復において、代替パスは、回復時間を速めるためにあらかじめ計算されるかもしれません。 また、回復を終わらせる終わりはいろいろネットワーク資源と回復回の利用の間の許容できる見返りによる地方の回復に混ぜられるかもしれません。
End-to-end protection may be based on two types of protection schemes; "1 + 1" protection or shared protection. Under 1 + 1 protection, a back-up path is established for the protected primary path along a physically diverse route. Both paths are active and the failure along the primary path results in an immediate switch-over to the back-up path. Under shared protection, back-up paths
終わりから終わりへの保護は2つのタイプの保護計画に基づくかもしれません。 「1+1インチの保護か共有された保護。」 1+1保護で、バックアップ経路は物理的に多様なルートに沿った保護された第一の経路に確立されます。 両方の経路はアクティブです、そして、第一の経路に沿った失敗はオーバーバックアップ経路への即座のスイッチをもたらします。 共有された保護で、経路をバックアップしてください。
Rajagopalan, et al. Informational [Page 29] RFC 3717 IP over Optical Networks: A Framework March 2004
Rajagopalan、他 光学ネットワークの上の情報[29ページ]のRFC3717IP: 2004年の枠組みの行進
corresponding to physically diverse primary paths may share the same network resources. When a failure affects a primary path, it is assumed that the same failure will not affect the other primary paths whose back-ups share resources.
物理的に多様な第一の経路に対応するのは同じネットワーク資源を共有するかもしれません。 失敗が第一の経路に影響するとき、同じ失敗がバックアップがリソースを共有する他の第一の経路に影響しないと思われます。
It is possible that different restoration schemes may be implemented within optical sub-networks. It is therefore necessary to consider a two-level restoration mechanism. Path failures within an optical sub-network could be handled using procedures specific to the sub- network. If this fails, end-to-end restoration across sub-networks could be invoked. The border OXC that is the ingress to a sub- network can act as the source for restoration procedures within a sub-network. The signaling for invoking end-to-end restoration across the INNI is described in Section 6.6.3. The computation of the back-up path for end-to-end restoration may be based on various criteria. It is assumed that the back-up path is computed by the source OXC, and signaled using standard methods.
異なった回復計画が光学サブネットワークの中で実行されるのは、可能です。 したがって、2レベルの回復メカニズムを考えるのが必要です。 サブネットワークに特定の手順を用いることで光学サブネットワークの中の経路失敗を扱うことができるでしょう。 これが失敗するなら、サブネットワークの向こう側の終わりから終わりへの回復は呼び出されるかもしれません。 サブネットワークへのイングレスである境界OXCは回復手順のためのソースとしてサブネットワークの中で機能できます。 INNIの向こう側に終わりから終わりへの回復を呼び出すためのシグナリングはセクション6.6.3で説明されます。 終わりから終わりへの回復のためのバックアップ経路の計算は様々な評価基準に基づくかもしれません。 バックアップ経路がソースOXCによって計算されて、合図されると標準方法を使用することで思われます。
6.5. Route Computation
6.5. 経路計算
The computation of a primary route for a lightpath within an optical network is essentially a constraint-based routing problem. The constraint is typically the bandwidth required for the lightpath, perhaps along with administrative and policy constraints. The objective of path computation could be to minimize the total capacity required for routing lightpaths [13].
光学ネットワークの中のlightpathのための幹線道路の計算は本質的には規制ベースのルーティング問題です。 通常、規制はlightpathと、恐らく管理と方針規制と共に必要である帯域幅です。 経路計算の目的はルーティングlightpaths[13]に必要である総容積を最小にすることであることができました。
Route computation with constraints may be accomplished using a number of algorithms [14]. When 1+1 protection is used, a back-up path that does not traverse on any link which is part of the same SRLG as links in the primary path must be computed. Thus, it is essential that the SRLGs in the primary path be known during alternate path computation, along with the availability of resources in links that belong to other SRLGs. This requirement has certain implications on optical link bundling. Specifically, a bundled LSA must include adequate information such that a remote OXC can determine the resource availability under each SRLG that the bundled link refers to, and the relationship between links belonging to different SRLGs in the bundle. For example, considering Figure 3, if links 1,2,3 and 4 are bundled together in an LSA, the bundled LSA must indicate that there are three SRLGs which are part of the bundle (i.e., 1, 2 and 3), and that links in SRLGs 2 and 3 are also part of SRLG 1.
規制による経路計算は、多くのアルゴリズム[14]を使用することで実行されるかもしれません。 1+1保護が使用されているとき、それが第一の経路のリンクと同じSRLGの一部であるどんなリンクの上にも横断しないバックアップ経路を計算しなければなりません。 したがって、第一の経路のSRLGsが代替パス計算の間知られているのは、不可欠です、他のSRLGsに属すリンクのリソースの有用性と共に。 この要件は光のリンクバンドリングに、ある意味を持っています。 明確に、束ねられたLSAは、リモートOXCは束ねられたリンクが言及する各SRLGの下でリソースの有用性を決定して、バンドルで異なったSRLGsに属すリンクの間で関係を決定できるように適切な情報を含まなければなりません。 例えば、リンク1、2、3、および4がLSAに一緒に束ねられるなら図3を考える場合、束ねられたLSAはバンドル(すなわち、1、2、および3)の一部である3SRLGsがあって、また、SRLGs2と3のリンクがSRLG1の一部であることを示さなければなりません。
To encode the SRLG relationships in a link bundle LSA, only links which belong to exactly the same set of SRLGs must be bundled together. With reference to Figure 3, for example, two bundles can be advertised for links between OXC1 and OXC2, with the following information:
リンクバンドルLSAでSRLG関係をコード化するために、SRLGsのまさに同じセットのものリンクだけを一緒に束ねなければなりません。 図3に関して、例えば、OXC1とOXC2とのリンクに2つのバンドルの広告を出すことができます、以下の情報で:
Rajagopalan, et al. Informational [Page 30] RFC 3717 IP over Optical Networks: A Framework March 2004
Rajagopalan、他 光学ネットワークの上の情報[30ページ]のRFC3717IP: 2004年の枠組みの行進
Bundle No. SRLGs Link Type Number Other Info
-------------------------------------------------------
1 1,2 OC-48 3 ---
2 1,3 OC-192 1 ---
バンドルNo. SRLGsリンク形式数他のインフォメーション------------------------------------------------------- 1 1、2OC-48 3--- 2 1、3OC-192 1---
Assuming that the above information is available for each bundle at every node, there are several approaches possible for path computation. For instance,
上記の情報があらゆるノードにおける各バンドルに利用可能であると仮定して、経路計算に、可能ないくつかのアプローチがあります。 例えば
1. The primary path can be computed first, and the (exclusive or
shared) back-up is computed next based on the SRLGs chosen for the
primary path. In this regard,
1. 最初に第一の経路を計算できます、そして、(排他的であるか共有される)のバックアップは次に、第一の経路に選ばれたSRLGsに基づいて計算されます。 この点で
o The primary path computation procedure can output a series of
bundles the path is routed over. Since a bundle is uniquely
identified with a set of SRLGs, the alternate path can be
computed right away based on this knowledge. In this case, if
the primary path set up does not succeed for lack of resources
in a chosen bundle, the primary and backup paths must be
recomputed.
o 第一の経路計算手順は経路が発送される一連のバンドルを出力できます。バンドルが唯一SRLGsの1セットと同一視されているので、すぐ、この知識に基づいて代替パスは計算できます。 この場合、セットアップされた第一の経路が財源不足で選ばれたバンドルに成功しないなら、予備選挙とバックアップ道を再計算しなければなりません。
o It might be desirable to compute primary paths without choosing
a specific bundle apriori. That is, resource availability over
all bundles between a node pair is taken into account rather
than specific bundle information. In this case, the primary
path computation procedure would output a series of nodes the
path traverses. Each OXC in the path would have the freedom to
choose the particular bundle to route that segment of the
primary path. This procedure would increase the chances of
successfully setting up the primary path when link state
information is not up to date everywhere. But the specific
bundle chosen, and hence the SRLGs in the primary path, must be
captured during primary path set-up, for example, using the
RSVP-TE Route Record Object [15]. This SRLG information is
then used for computing the back-up path. The back-up path may
also be established specifying only which SRLGs to avoid in a
given segment, rather than which bundles to use. This would
maximize the chances of establishing the back-up path.
o アプリオリに特定のバンドルを選ばないで第一の経路を計算するのは望ましいかもしれません。 すなわち、ノード組の間のすべてのバンドルの上のリソースの有用性は特定のバンドル情報よりむしろ考慮に入れられます。 この場合、第一の経路計算手順は経路が横断する一連のノードを出力するでしょう。 経路の各OXCには、第一の経路のそのセグメントを発送するために特定のバンドルを選ぶ自由があるでしょう。 この手順はいたる所でリンク州の情報が最新でないときに首尾よく第一の経路をセットアップするという可能性を高めるでしょう。 例えば、第一の経路セットアップの間、RSVP-TE Route Record Object[15]を使用することでしかし、選ばれた特定のバンドル、およびしたがって、第一の経路のSRLGsを捕らえなければなりません。 そして、このSRLG情報は、バックアップ経路を計算するのに使用されます。 また、どのバンドルを使用したらよいかよりむしろ与えられたセグメントでどのSRLGsを避けるだけであったらよいかを指定しながら、バックアップ経路は確立されるかもしれません。 これはバックアップ経路を確立するという可能性を最大にするでしょう。
2. The primary path and the back-up path are computed together in one
step, for example, using Suurbaale's algorithm [16]. In this
case, the paths must be computed using specific bundle
information.
2. 例えば、第一の経路とバックアップ経路は、ワンステップでSuurbaaleのアルゴリズム[16]を使用することで一緒に計算されます。 この場合、特定のバンドル情報を使用することで経路を計算しなければなりません。
To summarize, it is essential to capture sufficient information in link bundle LSAs to accommodate different path computation procedures and to maximize the chances of successful path establishment. Depending on the path computation procedure used, the type of support
まとめるのに不可欠である、異なった経路計算手順に対応して、うまくいっている経路設立の機会を最大にするためにリンクバンドルLSAsの十分な情報を得るのは不可欠です。 経路計算実行した手順、サポートのタイプに頼っています。
Rajagopalan, et al. Informational [Page 31] RFC 3717 IP over Optical Networks: A Framework March 2004
Rajagopalan、他 光学ネットワークの上の情報[31ページ]のRFC3717IP: 2004年の枠組みの行進
needed during path establishment (e.g., the recording of link group or SRLG information during path establishment) may differ.
経路設立の間、必要であることで、(例えば、経路設立の間のリンク群かSRLG情報の録音)は異なるかもしれません。
When shared protection is used, the route computation algorithm must take into account the possibility of sharing links among multiple back-up paths. Under shared protection, the back-up paths corresponding to SRLG-disjoint primary paths can be assigned the same links. The assumption here is that since the primary paths are not routed over links that have the same SRLG, a given failure will affect only one of them. Furthermore, it is assumed that multiple failure events affecting links belonging to more than one SRLG will not occur concurrently. Unlike the case of 1+1 protection, the back-up paths are not established apriori. Rather, a failure event triggers the establishment of a single back-up path corresponding to the affected primary path.
共有された保護が使用されているとき、ルート計算アルゴリズムは複数のバックアップ経路の中でリンクを共有する可能性を考慮に入れなければなりません。 共有された保護で、第一の経路をSRLGばらばらにならせるように対応するバックアップ経路に同じリンクを割り当てることができます。 第一の経路が同じSRLGを持っているリンクの上に発送されないので与えられた失敗がそれらについて1つだけに影響するという仮定がここにあります。 その上、1SRLGに属すリンクに影響する複数の失敗出来事が同時に起こらないと思われます。 1+1保護に関するケースと異なって、バックアップ経路はアプリオリに確立されません。 むしろ、失敗出来事は影響を受ける第一の経路に対応するただ一つのバックアップ経路の設立の引き金となります。
The distributed implementation of route computation for shared back- up paths require knowledge about the routing of all primary and back-up paths at every node. This raises scalability concerns. For this reason, it may be practical to consider the centralization of the route computation algorithm in a route server that has complete knowledge of the link state and path routes. Heuristics for fully distributed route computation without complete knowledge of path routes are to be determined. Path computation for restoration is further described in [11].
共有された逆経路のための経路計算の分配された実現はあらゆるノードのすべての第一の、そして、逆上がっている経路のルーティングに関する知識を必要とします。 これはスケーラビリティ関心を高めます。 この理由で、リンク状態と経路ルートに関する完全な知識を持っているルートサーバにおける、ルート計算アルゴリズムの中央集権化を考えるのは実用的であるかもしれません。 経路ルートに関する完全な知識のない完全に分配された経路計算のための発見的教授法は断固とすることです。 回復のための経路計算は[11]でさらに説明されます。
6.6. Signaling Issues
6.6. シグナリング問題
Signaling within an optical network for lightpath provisioning is a relatively simple operation if a standard procedure is implemented within all sub-networks. Otherwise, proprietary signaling may be implemented within sub-networks, but converted back to standard signaling across the INNI. This is similar to signaling across the ENNI, as described in Section 6.7. In the former case, signaling messages may carry strict explicit route information, while in the latter case the route information should be loose, at the level of abstraction of sub-networks. Once a route is determined for a lightpath, each OXC along the path must appropriately configure their cross-connects in a coordinated fashion. This coordination is conceptually analogous to selecting incoming and outgoing labels in a label-switched environment. Thus, protocols like RSVP-TE [9] may be adapted and used across the INNI for this purpose. The adaptation of IP-based signaling protocols must take into account a number of peculiar attributes of optical networks.
標準手続きがすべてのサブネットワークの中で実行されるなら、lightpathの食糧を供給するために光学ネットワークの中で合図するのは、比較的簡単な操作です。 さもなければ、独占シグナリングは、サブネットワークの中で実行されますが、INNIの向こう側に標準のシグナリングに変換して戻されるかもしれません。 これはセクション6.7で説明されるようにENNIの向こう側に合図するのと同様です。 前の場合では、シグナリングメッセージは厳しい明白な経由地案内を運ぶかもしれません、後者の場合では、経由地案内がゆるいはずですが、サブネットワークの抽象化のレベルで。 ルートがlightpathのためにいったん決定すると、経路に沿った各OXCは連携ファッションで適切にそれらの十字接続を構成しなければなりません。 このコーディネートは概念的にラベルで切り換えられた環境で送受信のラベルを選択するのに類似しています。 したがって、RSVP-TE[9]のようなプロトコルは、INNIの向こう側にこのために適合させられて、使用されるかもしれません。 IPベースのシグナリングプロトコルの適合は光学ネットワークの多くの独特の属性を考慮に入れなければなりません。
Rajagopalan, et al. Informational [Page 32] RFC 3717 IP over Optical Networks: A Framework March 2004
Rajagopalan、他 光学ネットワークの上の情報[32ページ]のRFC3717IP: 2004年の枠組みの行進
6.6.1. Bi-Directional Lightpath Establishment
6.6.1. 双方向のLightpath設立
Lightpaths are typically bi-directional. That is, the output port selected at an OXC for the forward direction is also the input port for the reverse direction of the path. Since signaling for optical paths may be autonomously initiated by different nodes, it is possible that two path set-up attempts are in progress at the same time. Specifically, while setting up an optical path, an OXC A may select output port i which is connected to input port j of the "next" OXC B. Concurrently, OXC B may select output port j for setting up a different optical path, where the "next" OXC is A. This results in a "collision". Similarly, when WDM functionality is built into OXCs, a collision occurs when adjacent OXCs choose directly connected output ports and the same wavelength for two different optical paths. There are two ways to deal with such collisions. First, collisions may be detected and the involved paths may be torn down and re-established. Or, collisions may be avoided altogether.
Lightpathsは通常双方向です。 また、すなわち、順方向のためにOXCで選択された出力ポートは経路の反対の方向のための入力ポートです。 光路に合図するのが異なったノードによって自主的に開始されるかもしれないので、2つの経路セットアップ試みが同時に進行しているのは、可能です。 明確に、OXC Aは光路をセットアップしている間、「次」のOXC B.Concurrentlyのポートjを入力するためにつなげられる出力ポートiを選択するかもしれなくて、OXC Bは、異なった光路をセットアップするために出力ポートjを選択するかもしれません。(そこでは、「次」のOXCが「衝突」でA.This結果です)。 OXCsがWDMの機能性に組み込まれるとき、同様に、隣接しているOXCsが2つの異なった光路への直接接続された出力ポートと同じ波長を選ぶと、衝突は起こります。 そのような衝突に対処する2つの方法があります。 まず最初に、衝突が検出されるかもしれなくて、かかわった経路は、取りこわされて、復職するかもしれません。 または、衝突は全体で避けられるかもしれません。
6.6.2. Failure Recovery
6.6.2. 失敗回復
The impact of transient partial failures must be minimized in an optical network. Specifically, optical paths that are not directly affected by a failure must not be torn down due to the failure. For example, the control processor in an OXC may fail, affecting signaling and other internodal control communication. Similarly, the control channel between OXCs may be affected temporarily by a failure. These failure may not affect already established optical paths passing through the OXC fabric. The detection of such failures by adjacent nodes, for example, through a keepalive mechanism between signaling peers, must not result in these optical paths being torn down.
光学ネットワークで一時的な部分的な失敗の影響を最小にしなければなりません。 明確に、失敗のため失敗で直接影響を受けない光路を取りこわしてはいけません。 例えば、シグナリングと他のinternodalコントロールコミュニケーションに影響する場合、OXCの制御プロセッサは失敗するかもしれません。 同様に、OXCsの間の制御チャンネルは失敗で一時影響を受けるかもしれません。 失敗が影響しないかもしれないこれらは既にOXC織物を通り抜ける光路を設置しました。 隣接しているノードによるそのような失敗の検出は、取りこわしながら、例えばシグナリング同輩の間のkeepaliveメカニズムを通してこれらの光路をもたらしてはいけません。
It is likely that when the above failures occur, a backup processor or a backup control channel will be activated. The signaling protocol must be designed such that it is resilient to transient failures. During failure recovery, it is desirable to recover local state at the concerned OXC with least disruption to existing optical paths.
上の失敗が起こるとき、バックアッププロセッサかバックアップ制御チャンネルが動きそうでしょう。 シグナリングプロトコルを設計しなければならないので、それは一時障害に弾力があります。 失敗回復の間、関係があるOXCで既存の光路の最少の分裂で地方の状態を回復するのは望ましいです。
6.6.3. Restoration
6.6.3. 王政復古
Signaling for restoration has two distinct phases. There is a reservation phase in which capacity for the protection path is established. Then, there is an activation phase in which the back-up path is actually put in service. The former phase typically is not subject to strict time constraints, while the latter is.
回復のために合図するのにおいて、2つの異なったフェーズがあります。 保護経路への容量が確立される予約フェーズがあります。 そして、バックアップ経路が実際にサービスに入れられる活性化相があります。 前のフェーズは厳しい時間規制を通常受けることがありませんが、後者はそうです。
Rajagopalan, et al. Informational [Page 33] RFC 3717 IP over Optical Networks: A Framework March 2004
Rajagopalan、他 光学ネットワークの上の情報[33ページ]のRFC3717IP: 2004年の枠組みの行進
Signaling to establish a "1+1" back-up path is relatively straight- forward. This signaling is very similar to signaling used for establishing the primary path. Signaling to establish a shared back-up path is a little bit different. Here, each OXC must understand which back-up paths can share resources among themselves. The signaling message must itself indicate shared reservation. The sharing rule is as described in Section 6.4: back-up paths corresponding to physically diverse primary paths may share the same network resources. It may therefore be necessary for the signaling message to carry adequate information that allows an OXC to verify that appropriateness of having a set of back-up paths sharing certain.
aを設立すると合図する、「1 +1 」 バックアップ経路は前方で比較的まっすぐです。 このシグナリングは第一の経路を確立するのに使用されるシグナリングと非常に同様です。 共有されたバックアップ経路を確立すると合図するのはほんの少し異なっています。 ここで、各OXCは、どのバックアップ経路が自分たちの中でリソースを共有できるかを理解しなければなりません。 シグナリングメッセージ必須自体は共有された予約について簡単に述べます。 共有規則がセクション6.4で説明されるようにあります: 物理的に多様な第一の経路に対応するバックアップ経路は同じネットワーク資源を共有するかもしれません。 したがって、確かな状態でバックアップ経路のセットを共有させるその適切さについて確かめるのがOXCを許容する適切な情報を運ぶシグナリングメッセージに必要であるかもしれません。
Under both 1+1 and shared protection, the activation phase has two parts: propagation of failure information to the source OXC from the point of failure, and activation of the back-up path. The signaling for these two phases must be very fast in order to realize response times in the order of tens of milliseconds. When optical links are SONET-based, in-band signals may be used, resulting in expedited response. With out-of-band control, it may be necessary to consider fast signaling over the control channel using very short IP packets and prioritized processing. While it is possible to use RSVP or CR- LDP for activating protection paths, these protocols do not provide any means to give priority to restoration signaling as opposed to signaling for provisioning. For instance, it is possible for a restoration-related RSVP message to be queued behind a number of provisioning messages thereby delaying restoration. It may therefore be necessary to develop a notion of prioritization for restoration signaling and incorporate appropriate mechanisms into existing signaling protocols to achieve this. Alternatively, a new signaling mechanism may be developed exclusively for activating protection paths during restoration.
+1と共有された保護、起動が位相を合わせる1の下に、2つの部品があります: 失敗のポイントからのソースOXCへの失敗情報の伝播、およびバックアップ経路の起動。 これらの二相のためのシグナリングは、何十ミリセカンドもの注文における応答時間がわかるために非常に速くなければなりません。 光学リンクがSonetベースであるときに、速められた応答をもたらして、バンドにおける信号は使用されるかもしれません。 バンドの外とのコントロール、制御チャンネルの上に非常に脆いIPパケットと最優先する処理を使用することで速く合図すると考えるのが必要であるかもしれません。 保護経路を活性化するのにRSVPかCR自由民主党を使用するのが可能である間、これらのプロトコルは食糧を供給するために合図することと対照的に回復シグナリングに優先的に取り扱うどんな手段も提供しません。 例えば、その結果、回復を遅らせながら多くの食糧を供給するメッセージの後ろに列に並ばせられるべき回復関連のRSVPメッセージに、それは可能です。 したがって、回復シグナリングのために優先順位づけの概念を発生して、これを達成するためにプロトコルに合図しながら存在するのに適切な手段を組み入れるのが必要であるかもしれません。 あるいはまた、新しいシグナル伝達機構は、排他的に回復の間、保護経路を活性化するために開発されるかもしれません。
6.7. Optical Internetworking
6.7. 光学インターネットワーキング
Within an optical internetwork, it must be possible to dynamically provision and restore lightpaths across optical networks. Therefore:
光学インターネットワークの中では、光学ネットワークの向こう側にダイナミックにlightpathsに食糧を供給して、返すのは可能であるに違いありません。 したがって:
o A standard scheme for uniquely identifying lightpath end-points in
different networks is required.
o 異なったネットワークで唯一lightpathエンドポイントを特定することの標準の計画が必要です。
o A protocol is required for determining reachability of end-points
across networks.
o プロトコルが、ネットワークの向こう側にエンドポイントの可到達性を決定するのに必要です。
o A standard signaling protocol is required for provisioning
lightpaths across networks.
o 標準のシグナリングプロトコルが、ネットワークの向こう側にlightpathsに食糧を供給するのに必要です。
Rajagopalan, et al. Informational [Page 34] RFC 3717 IP over Optical Networks: A Framework March 2004
Rajagopalan、他 光学ネットワークの上の情報[34ページ]のRFC3717IP: 2004年の枠組みの行進
o A standard procedure is required for the restoration of lightpaths
across networks.
o 標準手続きがlightpathsの修復にネットワークの向こう側に必要です。
o Support for policies that affect the flow of control information
across networks will be required.
o ネットワークの向こう側に制御情報の流れに影響する方針のサポートが必要でしょう。
The IP-centric control architecture for optical networks can be extended to satisfy the functional requirements of optical internetworking. Routing and signaling interaction between optical networks can be standardized across the ENNI (Figure 1). The functionality provided across ENNI is as follows.
光学インターネットワーキングに関する機能条件書を満たすために光学ネットワークのためのIP中心の規制構造を広げることができます。 ENNI(図1)の向こう側にルート設定と光学ネットワークの間の相互作用に合図するのを標準化できます。 ENNIの向こう側に提供された機能性は以下の通りです。
6.7.1. Neighbor Discovery
6.7.1. 隣人発見
Neighbor discovery procedure, as described in Section 6.2, can be used for this. Indeed, a single protocol should be standardized for neighbor discovery within and across networks.
これにセクション6.2で説明される隣人発見手順は用いることができます。 本当に、ただ一つのプロトコルは隣人発見のためにネットワーク以内とネットワークの向こう側に標準化されるべきです。
6.7.2. Addressing and Routing Model
6.7.2. アドレシングとルート設定はモデル化されます。
The addressing mechanisms described in Section 6.1 can be used to identify OXCs, ports, channels and sub-channels in each network. It is essential that the OXC IP addresses are unique within the internetwork.
各ネットワークでOXCs、ポート、チャンネル、およびサブチャンネルを特定するのにセクション6.1で説明されたアドレシングメカニズムは使用できます。 OXC IPアドレスがインターネットワークの中でユニークであることは、不可欠です。
Provisioning an end-to-end lightpath across multiple networks involves the establishment of path segments in each network sequentially. Thus, a path segment is established from the source OXC to a border OXC in the source network. From this border OXC, signaling across NNI is used to establish a path segment to a border OXC in the next network. Provisioning then continues in the next network and so on until the destination OXC is reached. The usage of protocols like BGP for this purpose need to be explored.
複数のネットワークの向こう側に終わりから終わりへのlightpathに食糧を供給すると、各ネットワークへの経路セグメントの設立は連続してかかわります。 したがって、経路セグメントはソースOXCから境界OXCまでソースネットワークに確立されます。 この境界OXCから、NNIの向こう側に合図するのは、次のネットワークで経路セグメントを境界OXCに証明するのに使用されます。 目的地OXCに達するまで、その時に食糧を供給するのは次のネットワークなどで続きます。 この探検されるべき目的の必要性のためのBGPのようなプロトコルの用法。
6.7.3. Restoration
6.7.3. 王政復古
Local restoration across the ENNI is similar to that across INNI described in Section 6.6.3. End-to-end restoration across networks is likely to be either of the 1+1 type, or segmented within each network, as described in Section 6.4.
ENNIの向こう側の地方の回復はセクション6.6.3で説明されたINNIの向こう側にそれと同様です。 ネットワークの向こう側の終わりから終わりへの回復は、1+1タイプのどちらかであることがありそうであり、各ネットワークの中で区分されます、セクション6.4で説明されるように。
Rajagopalan, et al. Informational [Page 35] RFC 3717 IP over Optical Networks: A Framework March 2004
Rajagopalan、他 光学ネットワークの上の情報[35ページ]のRFC3717IP: 2004年の枠組みの行進
7. Other Issues
7. 他の問題
7.1. WDM and TDM in the Same Network
7.1. 同じネットワークにおけるWDMとTDM
A practical assumption would be that if SONET (or some other TDM mechanism that is capable partitioning the bandwidth of a wavelength) is used, then TDM is leveraged as an additional method to differentiate between "flows". In such cases, wavelengths and time intervals (sub-channels) within a wavelength become analogous to labels (as noted in [1]) which can be used to make switching decisions. This would be somewhat akin to using VPI (e.g., wavelength) and VCI (e.g., TDM sub-channel) in ATM networks. More generally, this will be akin to label stacking and to LSP nesting within the context of Multi-Protocol Lambda Switching [1]. GMPLS signaling [4] supports this type of multiplexing.
実用的な仮定はSonet(または、波長の帯域幅を仕切るある他のできるTDMメカニズム)が使用されているなら区別する追加方法が「流れる」ときTDMが投機されているということでしょう。 そのような場合、波長の中の波長と時間間隔(サブチャンネル)はラベルに類似するようになります。(切り換え決定をするのに使用できる[1])に述べられるように。 これはATMネットワークにVPI(例えば、波長)とVCI(例えば、TDMサブチャンネル)を使用するのといくらか同系でしょう。 より一般に、これはラベルの積み重ねであることと、そして、Multi-プロトコルLambda Switching[1]の文脈の中で巣ごもるLSPと同系になるでしょう。 GMPLSシグナリング[4]はマルチプレクシングのこのタイプを支持します。
7.2. Wavelength Conversion
7.2. 波長変換
Some form of wavelength conversion may exist at some switching elements. This however may not be the case in some pure optical switching elements. A switching element is essentially anything more sophisticated than a simple repeater, that is capable of switching and converting a wavelength Lambda(k) from an input port to a wavelength Lambda(l) on an output port. In this display, it is not necessarily the case that Lambda(k) = Lambda(l), nor is it necessarily the case that the data carried on Lambda(k) is switched through the device without being examined or modified.
何らかの形式の波長変換はいくつかのスイッチング素子で存在するかもしれません。 しかしながら、これはいくつかの純粋な光学スイッチング素子がそうでないかもしれません。 簡単なリピータよりスイッチング素子が本質的には何かであること洗練されたもの、出力ポートの上で入力ポートから波長Lambda(l)まで波長Lambda(k)を切り換えて、それは変換できます。 この表示では、Lambda(k)がλ(l)と等しいのが、必ず事実であるというわけではなく、それは必ずLambda(k)で運ばれたデータが装置を通して調べられるか、または変更されないで切り換えられるのによるケースであるというわけではありません。
It is not necessary to have a wavelength converter at every switching element. A number of studies have attempted to address the issue of the value of wavelength conversion in an optical network. Such studies typically use the blocking probability (the probability that a lightpath cannot be established because the requisite wavelengths are not available) as a metric to adjudicate the effectiveness of wavelength conversion. The IP over optical architecture must take into account hybrid networks with some OXCs capable of wavelength conversion and others incapable of this. The GMPLS "label set" mechanism [4] supports the selection of the same label (i.e., wavelength) across an NNI.
あらゆるスイッチング素子に波長コンバータを持つのは必要ではありません。 多くの研究が、光学ネットワークにおける、波長変換の価値の問題を記述するのを試みました。 そのような研究は波長変換の有効性に判決を下すためにはメートル法のaとしてブロッキング確率(必要な波長が有効でないのでlightpathを設立できないという確率)を通常使用します。 光学構造の上のIPは波長変換ができるいくつかのOXCsとこれであることができない他のものとのハイブリッド回路網を考慮に入れなければなりません。 GMPLS「ラベル・セット」メカニズム[4]はNNIの向こう側に同じラベル(すなわち、波長)の選択を支持します。
7.3. Service Provider Peering Points
7.3. サービスプロバイダーじっと見るポイント
There are proposed inter-network interconnect models which allow certain types of peering relationships to occur at the optical layer. This is consistent with the need to support optical layer services independent of higher layers payloads. In the context of IP over optical networks, peering relationships between different trust domains will eventually have to occur at the IP layer, on IP routing
あるタイプのじっと見る関係を光学層に起こらせるインターネットワーク内部連絡モデルは提案されます。 これは、より高い層のペイロードの如何にかかわらず光の層のサービスを支持する必要性と一致しています。 光学ネットワークの上のIPの文脈では、異なった信用ドメインの間のじっと見る関係は結局IP層に起こらなければならないでしょう、IPルーティングで
Rajagopalan, et al. Informational [Page 36] RFC 3717 IP over Optical Networks: A Framework March 2004
Rajagopalan、他 光学ネットワークの上の情報[36ページ]のRFC3717IP: 2004年の枠組みの行進
elements, even though non-IP paths may exist between the peering routers.
非IP経路はじっと見るルータの間に存在するかもしれませんが、要素。
7.4. Rate of Lightpath Set-Up
7.4. Lightpathセットアップの速度
Dynamic establishment of optical channel trails and lightpaths is quite desirable in IP over optical networks, especially when such instantiations are driven by a stable traffic engineering control system, or in response to authenticated and authorized requests from clients.
光学チャンネル道とlightpathsのダイナミックな設立は光学ネットワークに関してIPで十分望ましいです、特にそのような具体化が安定した交通工学制御システム、またはクライアントからの認証されて認可された要求に対応して追い立てられると。
However, there are many proposals suggesting the use of dynamic, data-driven shortcut-lightpath setups in IP over optical networks. The arguments put forth in such proposals are quite reminiscent of similar discussions regarding ATM deployment in the core of IP networks. Deployment of highly dynamic data driven shortcuts within core networks has not been widely adopted by carriers and ISPs for a number of reasons: possible CPU overhead in core network elements, complexity of proposed solutions, stability concerns, and lack of true economic drivers for this type of service. This document assumes that this paradigm will not change and that highly dynamic, data-driven shortcut lightpath setups are for future investigation. Instead, the optical channel trails and lightpaths that are expected to be widely used at the initial phases in the evolution of IP over optical networks will include the following:
しかしながら、光学ネットワークの上にIPにおけるダイナミックなデータ駆動型近道-lightpathセットアップの使用を示す多くの提案があります。 そのような提案で差し出された議論はIPネットワークのコアでATM展開についての同様の議論のかなりなごりです。 コアネットワークの中の非常にダイナミックなデータ駆動の近道の展開はキャリヤーとISPによって広く様々な意味で採用されません: コアネットワーク要素における可能なCPUオーバーヘッド、このタイプのサービスのための本当の経済ドライバーの提案された解決策、安定性関心、および不足の複雑さ。 このドキュメントはこのパラダイムが変化しないで、非常にダイナミックなデータ駆動型近道のlightpathセットアップが今後の調査のためのものであると仮定します。 代わりに、光学ネットワークの上でIPの発展に広く初期位相に使用されると予想される光学チャンネルの道とlightpathsは以下を含むでしょう:
o Dynamic connections for control plane traffic and default path
routed data traffic,
o コントロール飛行機通行とデフォルト経路のためのダイナミックな接続はデータ通信量を発送しました。
o Establishment and re-arrangement of arbitrary virtual topologies
over rings and other physical layer topologies.
o リングの上の任意の仮想のtopologiesと他の物理的な層のtopologiesの設立と配列換え。
o Use of stable traffic engineering control systems to engineer
lightpath connections to enhance network performance, either for
explicit demand based QoS reasons or for load balancing).
o 機能アップするlightpath接続を設計する安定した交通工学制御システムの使用がベースのQoSが推論する明白な要求かロードバランシングのために性能をネットワークでつなぐ、)
Other issues surrounding dynamic connection setup within the core center around resource usage at the edge of the optical domain. One potential issue pertains to the number of flows that can be processed by an ingress or egress network element either because of aggregate bandwidth limitations or because of a limitation on the number of flows (e.g., lightpaths) that can be processed concurrently.
コアの中でダイナミックな接続設定を囲む他の問題が光学ドメインの縁にリソース用法を中心に置きます。 潜在的1冊は同時に処理できる流れ(例えば、lightpaths)の数で集合帯域幅制限のため制限によるイングレスか出口ネットワーク要素で処理できる流れの数に関係します。
Another possible short term reason for dynamic shortcut lightpath setup would be to quickly pre-provision paths based on some criteria (e.g., a corporate executive wants a high bandwidth reliable connection, etc.). In this scenario, a set of paths can be pre- provisioned, but not actually instantiated until the customer
lightpathセットアップがすぐにあるダイナミックな近道に関して、プレ支給経路がいくつかの評価基準を基礎づけた(例えば、会社重役は高帯域の頼もしい接続などが欲しいです)別の可能な短期間理由。 このシナリオでは、1セットの経路をあらかじめ食糧を供給されますが、実際に顧客まで例示できません。
Rajagopalan, et al. Informational [Page 37] RFC 3717 IP over Optical Networks: A Framework March 2004
Rajagopalan、他 光学ネットワークの上の情報[37ページ]のRFC3717IP: 2004年の枠組みの行進
initiates an authenticated and authorized setup requests, which is consistent with existing agreements between the provider and the customer. In a sense, the provider may have already agreed to supply this service, but will only instantiate it by setting up a lightpath when the customer submits an explicit request.
認証されて認可されたセットアップが要求する開始、どれがプロバイダーと顧客との現存協定と一致していますか? ある意味で、プロバイダーは、このサービスを供給するのに既に同意したかもしれませんが、顧客が明白な要求を提出するときlightpathをセットアップすることによって、それを例示するだけでしょう。
7.5. Distributed vs. Centralized Provisioning
7.5. 集結された食糧を供給することに対して分配されます。
This document has mainly dealt with a distributed model for lightpath provisioning, in which all nodes maintain a synchronized topology database, and advertise topology state information to maintain and refresh the database. A constraint-based routing entity in each node then uses the information in the topology database and other relevant details to compute appropriate paths through the optical domain. Once a path is computed, a signaling protocol (e.g., [9]) is used to instantiate the lightpath.
このドキュメントはlightpathの食糧を供給する分配されたモデルに主に対処しました。(そこでは、すべてのノードが、連動しているトポロジーデータベースを維持して、データベースを維持して、リフレッシュするためにトポロジー州の情報の広告を出します)。 そして、各ノードの規制ベースのルーティング実体は、光学ドメインを通して適切な経路を計算するのにトポロジーデータベースに他の関連詳細に情報を使用します。 一度、経路は計算されて、シグナリングは議定書を作ります。(例えば、[9])はlightpathを例示するのが使用されます。
Another provisioning model is to have a centralized server which has complete knowledge of the physical topology, the available wavelengths, and where applicable, relevant time domain information.
別の食糧を供給しているモデルはaを持っているのが物理的なトポロジーに関する完全な知識を持っているサーバを集結しました、有効な波長ということであり、どこが適切で、関連している時間領域情報であるか。
A corresponding client will reside on each network element that can source or sink a lightpath. The source client would query the server in order to set up a lightpath from the source to the destination. The server would then check to see if such a lightpath can be established based on prevailing conditions. Furthermore, depending on the specifics of the model, the server may either setup the lightpath on behalf of the client or provide the necessary information to the client or to some other entity to allow the lightpath to be instantiated.
対応するクライアントはlightpathを出典を明示するか、または沈めることができるそれぞれのネットワーク要素の上に住むでしょう。 ソースクライアントは、ソースから目的地までlightpathをセットアップするためにサーバについて質問するでしょう。 そして、サーバは、行き渡っている状態に基づいてそのようなlightpathを設立できるかどうか確認するためにチェックするでしょう。 その上、モデルの詳細によって、サーバは、lightpathが例示されるのを許容するためにクライアントを代表してlightpathをセットアップするか、またはクライアント、または、ある他の実体に必要事項を提供するかもしれません。
Centralization aids in implementing complex capacity optimization schemes, and may be the near-term provisioning solution in optical networks with interconnected multi-vendor optical sub-networks. In the long term, however, the distributed solution with centralization of some control procedures (e.g., traffic engineering) is likely to be the approach followed.
中央集権化は、複雑な容量が最適化体系であると実装する際に支援して、光学ネットワークでインタコネクトされたマルチベンダ光学サブネットワークがあるソリューションに食糧を供給する短期間であるかもしれません。 しかしながら、長期で、いくつかのコントロール手順(例えば、交通工学)の中央集権化に伴う分配されたソリューションはアプローチであるということになった傾向があります。
7.6. Optical Networks with Additional Configurable Components
7.6. 追加構成可能なコンポーネントがある光学ネットワーク
Thus far, this memo has focused mainly on IP over optical networks where the cross-connect is the basic dynamically re-configurable device in the optical network. Recently, as a consequence of technology evolution, various types of re-configurable optical components are now available, including tunable lasers, tunable filters, etc. Under certain circumstances, it may be necessary to
これまでのところ、このメモは十字接続が光学ネットワークで基本的なダイナミックに再構成可能なデバイスである光学ネットワークの上で主にIPに焦点を合わせました。 最近、技術発展の結果として、様々なタイプの再構成可能な光学部品は現在利用可能です、波長可変レーザ、チューナブル・フィルタなどを含んでいて 確信事情であり、それが必要であるかもしれないことを
Rajagopalan, et al. Informational [Page 38] RFC 3717 IP over Optical Networks: A Framework March 2004
Rajagopalan、他 光学ネットワークの上の情報[38ページ]のRFC3717IP: 2004年のフレームワーク行進
parameterize the characteristics of these components and advertise them within the control plane. This aspect is left for further study.
これらのコンポーネントの特性をparameterizeして、制御飛行機の中にそれらの広告を出します。 この局面はさらなる研究に出られます。
7.7. Optical Networks with Limited Wavelength Conversion Capability
7.7. 株式会社波長変換能力がある光学ネットワーク
At the time of the writing of this document, the majority of optical networks being deployed are "opaque". In this context the term opaque means that each link is optically isolated by transponders doing optical-electrical-optical conversions. Such conversions have the added benefit of permitting 3R regeneration. The 3Rs refer to re-power, signal retiming and reshaping. Unfortunately, this regeneration requires that the underlying optical equipment be aware of both the bit rate and frame format of the carried signal. These transponders are quite expensive and their lack of transparency constrains the rapid introduction of new services [17]. Thus there are strong motivators to introduce "domains of transparency" wherein all-optical networking equipment would transport data unfettered by these drawbacks.
このドキュメントの書くこと時点で、配布される光学ネットワークの大部分が「不透明です」。 このような関係においては不透明であるという用語が、各リンクが光学的にしながらトランスポンダーによって隔離されることを意味する、光学、電気、光学、変換。 そのような変換には、再生を3Rに可能にする付加利益があります。 3Rsは再パワー、信号再調節、および造り直すことについて言及します。 残念ながら、この再生は、基本的な光学機器がビット伝送速度と運ばれた信号のフレーム形式の両方を意識しているのを必要とします。 これらのトランスポンダーはかなり高価です、そして、それらの透明性の不足は新種業務[17]の急速な導入を抑制します。 したがって、オール光学のネットワーク設備がこれらの欠点によって自由にされたデータを輸送する「透明のドメイン」を導入するために、強い動機付け要因がいます。
Thus, the issue of IP over optical networking in all optical sub- networks, and sub-networks with limited wavelength conversion capability merits special attention. In such networks, transmission impairments resulting from the peculiar characteristics of optical communications complicate the process of path selection. These transmission impairments include loss, noise (due primarily to amplifier spontaneous emission -- ASE), dispersion (chromatic dispersion and polarization mode dispersion), cross-talk, and non- linear effects. In such networks, the feasibility of a path between two nodes is no longer simply a function of topology and resource availability but will also depend on the accumulation of impairments along the path. If the impairment accumulation is excessive, the optical signal to noise ratio (OSNR) and hence the electrical bit error rate (BER) at the destination node may exceed prescribed thresholds, making the resultant optical channel unusable for data communication. The challenge in the development of IP-based control plane for optical networks is to abstract these peculiar characteristics of the optical layer [17] in a generic fashion, so that they can be used for path computation.
その結果、光のネットワークの上のすべての光学サブネットワークにおける、IPの問題、および限られた波長変換能力長所特別番組注意があるサブネットワーク。 そのようなネットワークでは、光通信の持ち味から生じるトランスミッション損傷が経路選択のプロセスを複雑にします。 これらのトランスミッション損傷は損失、雑音(主としてアンプ自然放出への支払われるべきもの--ASE)、分散(色彩の分散と偏波モード分散)、混線、および非直線的な効果を含んでいます。 そのようなネットワークでは、2つのノードの間の経路に関する実現の可能性は、もう単にトポロジーとリソースの有用性の関数ではありませんが、また、経路に沿って損傷の蓄積によるでしょう。 損傷蓄積が過度であるなら、光学SN比(OSNR)としたがって、目的地ノードの(BER)が超えるかもしれない電気ビット誤り率は敷居を定めました、結果の光学チャンネルをデータ通信に使用不可能にして。 光学のこれらの持ち味が層にする要約には光学ネットワークのためのIPベースの制御飛行機の開発における挑戦が、[17] ジェネリックファッション経路計算にそれらを使用できるようにあります。
8. Evolution Path for IP over Optical Architecture
8. 光学アーキテクチャの上のIPのための発展経路
The architectural models described in Section 5 imply a certain degree of implementation complexity. Specifically, the overlay model was described as the least complex for near term deployment and the peer model the most complex. Nevertheless, each model has certain advantages and this raises the question as to the evolution path for IP over optical network architectures.
セクション5で説明された建築モデルはある度合いの実装の複雑さについて暗示します。 明確に、短期間展開のための最少の複合体と同輩が最も多くの複合体をモデル化するとき、オーバレイモデルは説明されました。 それにもかかわらず、各モデルには、ある利点があります、そして、これはIPのために発展経路に関して光学ネットワークアーキテクチャの上に疑問を引き起こします。
Rajagopalan, et al. Informational [Page 39] RFC 3717 IP over Optical Networks: A Framework March 2004
Rajagopalan、他 光学ネットワークの上の情報[39ページ]のRFC3717IP: 2004年のフレームワーク行進
The evolution approach recommended in this framework is the definition of capability sets that start with simpler functionality in the beginning and include more complex functionality later. In this regard, it is realistic to expect that initial IP over optical deployments will be based on the domain services model (with overlay interconnection), with no routing exchange between the IP and optical domains. Under this model, direct signaling between IP routers and optical networks is likely to be triggered by offline traffic engineering decisions. The next step in the evolution of IP-optical interaction is the introduction of reachability information exchange between the two domains. This would potentially allow lightpaths to be established as part of end-to-end LSP set-up. The final phase is the support for the full peer model with more sophisticated routing interaction between IP and optical domains.
このフレームワークにおけるお勧めの発展アプローチは初めに、より簡単な機能性から始まって、後でより複雑な機能性を含んでいる能力セットの定義です。 この点で、光の展開の上の初期のIPがIPと光学ドメインの間のルーティング交換なしでドメインサービスモデル(オーバレイインタコネクトがある)に基づくと予想するのは現実的です。 このモデルの下では、IPルータと光学ネットワークの間のダイレクトシグナリングはオフライン交通工学決定で引き起こされそうです。 IP光学の相互作用の発展における次のステップは2つのドメインの間の可到達性情報交換の導入です。 これで、lightpathsは終わりから終わりへのLSPセットアップの一部として潜在的に創業するでしょう。 最終段階はIPと光学ドメインとの、より洗練されたルーティング相互作用に伴う完全な同輩モデルのサポートです。
Using a common signaling framework (based on GMPLS) from the beginning facilitates this type of evolution. In this evolution, the signaling capability and semantics at the IP-optical boundary would become more sophisticated, but the basic structure of signaling would remain. This would allow incremental developments as the interconnection model becomes more sophisticated, rather than complete re-development of signaling capabilities.
始めから一般的なシグナリングフレームワーク(GMPLSに基づいている)を使用すると、このタイプの発展は容易にされます。 この発展では、IP光学の境界のシグナリング能力と意味論は、より洗練されるようになるでしょうが、シグナリングの基本構造は残っているでしょう。 インタコネクトモデルがシグナリング能力の、より多くの完全であるというよりむしろ洗練された再開発になるとき、これは増加の開発を許すでしょう。
From a routing point of view, the use of Network Management Systems (NMS) for static connection management is prevalent in legacy optical networks. Going forward, it can be expected that connection routing using the control plane will be gradually introduced and integrated into operational infrastructures. The introduction of routing capabilities can be expected to occur in a phased approach.
ルーティング観点から、Network Management Systems(NMS)の静的な接続管理の使用はレガシーの光学ネットワークで一般的です。 進んでいて、制御飛行機を使用する接続ルーティングが徐々に導入されて、操作上のインフラストラクチャと統合されると予想できます。 ルーティング能力の導入が段階的なアプローチで起こると予想できます。
It is likely that in the first phase, service providers will either upgrade existing local element management (EMS) software with additional control plane capabilities (and perhaps the hardware as well), or upgrade the NMS software in order to introduce some degree of automation within each optical subnetwork. For this reason, it may be desirable to partition the network into subnetworks and introduce IGP interoperability within each subnetwork (i.e., at the I-NNI level), and employ either static or signaled interoperability between subnetworks. Consequently, it can be envisioned that the first phase in the evolution towards network level control plane interoperability in IP over Optical networks will be organized around a system of optical subnetworks which are interconnected statically (or dynamically in a signaled configuration). During this phase, an overlay interconnection model will be used between the optical network itself and external IP and MPLS routers (as described in Section 5.2.3).
第1段階では、サービスプロバイダーは、それぞれの光学サブネットワークの中でいくらかのオートメーションを導入するために追加コントロール飛行機能力(そして、恐らくまた、ハードウェア)で既存のローカルの要素管理(EMS)ソフトウェアをアップグレードさせそうであるか、またはNMSソフトウェアをアップグレードさせそうでしょう。 この理由で、ネットワークをサブネットワークに仕切って、各サブネットワーク(すなわち、I-NNIレベルにおける)の中でIGP相互運用性を導入して、サブネットワークの間で静的であるか合図された相互運用性を使うのは望ましいかもしれません。 その結果、それがそうであることができる、思い描かれて、ネットワークレベルに向かった発展における第1段階がOpticalネットワークの上でIPで飛行機相互運用性を制御するのが静的にインタコネクトされる光学サブネットワークのシステムの周りで組織化される、(ダイナミックである、aが構成に合図したコネ) この段階の間、オーバレイインタコネクトモデルは光学ネットワーク自体と、外部のIPとMPLSルータの間で使用されるでしょう(セクション5.2.3で説明されるように)。
Rajagopalan, et al. Informational [Page 40] RFC 3717 IP over Optical Networks: A Framework March 2004
Rajagopalan、他 光学ネットワークの上の情報[40ページ]のRFC3717IP: 2004年のフレームワーク行進
Progressing with this phased approach to IPO routing interoperabibility evolution, the next level of integration will be achieved when a single carrier provides dynamic optical routing interoperability between subnetworks and between domains. In order to become completely independent of the network switching capability within subnetworks and across domains, routing information exchange may need to be enabled at the UNI level. This would constitute a significant evolution: even if the routing instances are kept separate and independent, it would still be possible to dynamically exchange reachability and other types of routing information. Another more sophisticated step during this phase is to introduce dynamic routing at the E-NNI level. This means that any neighboring networks (independent of internal switching capability) would be capable of exchanging routing information with peers across the E-NNI.
独身のキャリヤーがダイナミックな光学ルーティング相互運用性をサブネットワークの間と、そして、ドメインの間に提供するとき、IPOルーティングinteroperabibility発展へのこの段階的なアプローチで進歩して、統合の次のレベルは達成されるでしょう。 サブネットワークとドメインの向こう側にネットワークスイッチング能力から完全に独立するようになるように、ルーティング情報交換は、UNIレベルで可能にされる必要があるかもしれません。 これは重要な発展を構成するでしょう: ルーティングインスタンスが別々で独立しているように保たれても、ダイナミックにルーティング情報の可到達性と他のタイプを交換するのはまだ可能でしょう。 この段階の間の、より高度なもう1ステップはE-NNIレベルでダイナミックルーティングを紹介することです。 これは、どんな隣接しているネットワーク(内部のスイッチング能力の如何にかかわらず)もE-NNIの向こう側にルーティング情報を同輩と交換できることを意味します。
Another alternative would be for private networks to bypass these intermediate steps and directly consider an integrated routing model from the onset. This direct evolution strategy is realistic, but is more likely to occur in operational contexts where both the IP (or MPLS) and optical networks are built simultaneously, using equipment from a single source or from multiple sources that are closely affiliated. In any case, due to the current lack of operational experience in managing this degree of control plane interaction in a heterogeneous network (these issues may exist even if the hardware and software originate from the same vendor), an augmented model is likely to be the most viable initial option. Alternatively, a very modular or hierarchical peer model may be contemplated. There may be other challenges (not just of a technical, but also administrative and even political issues) that may need to be resolved in order to achieve full a peer model at the routing level in a multi-technology and multi-vendor environment. Ultimately, the main technical improvement would likely arise from efficiencies derived from the integration of traffic-engineering capabilities in the dynamic inter-domain routing environments.
別の代替手段は、私設のネットワークがこれらの途中経過を迂回させて、開始から統合ルーティングモデルを直接考えるだろうことです。 このダイレクト発展戦略は、現実的ですが、IP(または、MPLS)と光学ネットワークの両方が同時に造られる操作上の文脈では、より起こりそうです、単独のソース、または、密接に合併される複数のソースから設備を使用して。 どのような場合でも、異機種ネットワーク(ハードウェアとソフトウェアが同じベンダーから発しても、これらの問題は存在するかもしれない)でのこの度合いのコントロール飛行機相互作用を管理することにおける、運用経験の現在の不足のために、増大しているモデルは最も実行可能な初期のオプションである傾向があります。 あるいはまた、非常にモジュール的、または、階層的な同輩モデルは熟考されるかもしれません。 マルチ技術とマルチベンダ環境にはルーティングレベルで同輩モデルをいっぱいに達成するために決議される必要があるかもしれない他の挑戦(技術的な、しかし、管理の、そして、も政治上でない問題だけのさえ)があるかもしれません。 結局、主な技術革新はダイナミックな相互ドメインルーティング環境における、交通工学能力の統合から得られた効率からおそらく起こるでしょう。
9. Security Considerations
9. セキュリティ問題
The architectural framework described in this document requires a number of different protocol mechanisms for its realization. Specifically, the role of neighbor discovery, routing, and signaling protocols were highlighted in previous sections. The general security issues that arise with these protocols include:
本書では説明された建築フレームワークは実現のために多くの異なったプロトコルメカニズムを必要とします。 明確に、隣人発見の役割と、ルーティングと、プロトコルに合図するのは前項で強調されました。 これらのプロトコルで起こる総合証券問題は:
o The authentication of entities exchanging information (e.g.,
signaling, routing, or link management) across a control
interface;
o コントロールインタフェースの向こう側に情報交換する(例えば、シグナリング、ルーティング、またはリンク管理)実体の認証。
Rajagopalan, et al. Informational [Page 41] RFC 3717 IP over Optical Networks: A Framework March 2004
Rajagopalan、他 光学ネットワークの上の情報[41ページ]のRFC3717IP: 2004年のフレームワーク行進
o Ensuring the integrity of the information exchanged across the
interface;
o 情報の保全を確実にすると、インタフェースは横切って交換されました。
o Protection of the control mechanisms from intrusions and other
modes of outside interference.
o 侵入からの制御機構の保護と第三者の干渉の他のモード。
Because optical connections may carry high volumes of traffic and are generally quite expensive, mechanisms are required to safeguard optical networks against intrusions and unauthorized utilization of network resources.
光の接続がトラフィックの高い量を運ぶかもしれなくて、一般にかなり高価であるので、メカニズムはネットワーク資源の侵入と権限のない利用に対して光学ネットワークを保護しなければなりません。
In addition to the security aspects relating to the control plane, the data plane must also be protected from external interference.
また、制御飛行機に関連するセキュリティ局面に加えて、外部の干渉からデータ飛行機を保護しなければなりません。
An important consideration in optical networks is the separation of control channels from data channels. This decoupling implies that the state of the bearer channels carrying user traffic cannot be inferred from the state of the control channels. Similarly, the state of the control channels cannot be inferred from the state of the data channels. The potential security implications of this decoupling should be taken into account in the design of pertinent control protocols and in the operation of IPO networks.
光学ネットワークにおける重要な考慮すべき事柄はデータ・チャンネルからの制御チャンネルの離別です。 このデカップリングは、制御チャンネルの状態からユーザトラフィックを運ぶ運搬人チャンネルの状態を推論できないのを含意します。 同様に、データ・チャンネルの状態から制御チャンネルの状態を推論できません。 このデカップリングの潜在的セキュリティ含意は適切な制御プロトコルのデザインとIPOネットワークの操作で考慮に入れられるべきです。
Another issue in IPO networks concerns the fact that the underlying optical network elements may be invisible to IP client nodes, especially in the overlay model. This means that traditional IP tools such as traceroute cannot be used by client IP nodes to detect attacks within the optical domain.
IPOネットワークにおける別の問題は基本的な光学ネットワーク要素がIPクライアントノードに目に見えないかもしれないという事実に関係があります、特にオーバレイモデルで。 これはトレースルートなどの伝統的なIPツールがクライアントIPノードによって使用されて、光学ドメインの中に攻撃を検出することがないことができることを意味します。
For the aforementioned reasons, the output of the routing protocol security (RPSEC) efforts within the IETF should be considered in the design of control protocols for optical networks.
前述の理由で、IETFの中のルーティング・プロトコルセキュリティ(RPSEC)取り組みの出力は光学ネットワークのために制御プロトコルのデザインで考えられるべきです。
In Section 2, the concept of a trust domain was defined as a network under a single technical administration in which adequate security measures are established to prevent unauthorized intrusion from outside the domain. It should be strongly noted that within a trust domain, any subverted node can send control messages which can compromise the entire network.
セクション2では、信頼ドメインの概念は十分な安全性測定がドメインの外から権限のない侵入を防ぐために確立されるただ一つの技術的な管理の下でネットワークと定義されました。 信頼ドメインの中では、どんな打倒されたノードも全体のネットワークに感染することができるコントロールメッセージを送ることができることに強く注意されるべきです。
9.1. General security aspects
9.1. 総合証券局面
Communication protocols usually require two main security mechanisms: authentication and confidentiality. Authentication mechanisms ensure data origin verification and message integrity so that intrusions and unauthorized operations can be detected and mitigated. For example, with reference to Figure 1, message authentication can prevent a malicious IP client from mounting a denial of service attack against
通常、通信プロトコルは2台の主なセキュリティー対策を必要とします: 認証と秘密性。 認証機構は、侵入と権限のない操作を検出して、緩和できるようにデータ発生源検証とメッセージの保全を確実にします。 例えば、図1に関して、通報認証はサービスの否定が攻撃する取り付けからの悪意があるIPクライアントを防ぐことができます。
Rajagopalan, et al. Informational [Page 42] RFC 3717 IP over Optical Networks: A Framework March 2004
Rajagopalan、他 光学ネットワークの上の情報[42ページ]のRFC3717IP: 2004年のフレームワーク行進
the optical network by invoking an excessive number of connection creation requests across the UNI interface. Another important security consideration is the need to reject replayed control packets. This capability can assist in countering some forms of denial of service attacks. Replay protection provides a form of partial sequence integrity, and can be implemented in conjunction with an authentication mechanism.
過度の数の接続作成を呼び出すのによる光学ネットワークは横切ってUNIインタフェースを要求します。 別の重要な警備上の配慮は再演されたコントロールパケットを拒絶する必要性です。 この能力は、いくつかの形式のサービス不能攻撃に対抗するのを助けることができます。 反復操作による保護は、部分的な系列保全のフォームを提供して、認証機構に関連して実装することができます。
Confidentiality of signaling messages is also desirable, especially in scenarios where message attributes between communicating entities include sensitive or private information. Examples of such attributes include account numbers, contract identification information, and similar types of private data.
また、シグナリングメッセージの秘密性も望ましいです、特に実体を伝えることの間のメッセージ属性が敏感であるか個人的な情報を含んでいるシナリオで。 そのような属性に関する例は口座番号、契約識別情報、および同様のタイプの個人的なデータを含んでいます。
The case of equipment that are not co-located presents increased security threats. In such scenarios, the communicating entities engaged in protocol message transactions may be connected over an external network. Generally, the external network may be outside the span of control of the optical network (or client IP network) administrators. As a result, the protocol messages may be subject to increased security threats, such as address spoofing, eavesdropping, and intrusion. To mitigate such threats, appropriate security mechanisms must be employed to protect the control channels and associated signaling and routing messages.
共同見つけられなかった設備に関するケースは増強された軍事的脅威を提示します。 そのようなシナリオでは、プロトコルメッセージトランザクションに従事している交信実体は外部のネットワークの上に関連づけられるかもしれません。 一般に、光学ネットワーク(または、クライアントIPネットワーク)管理者の管理限界の外に外部のネットワークがあるかもしれません。 その結果、プロトコルメッセージはアドレススプーフィングや、盗聴や、侵入などの増強された軍事的脅威を受けることがあるかもしれません。 そのような脅威を緩和するなら、制御チャンネル、関連シグナリング、およびルーティング・メッセージを保護するのに適切なセキュリティー対策を使わなければなりません。
Requests for optical connections from client networks must also be filtered using appropriate policies to protect against security infringements and excess resource consumption. Additionally, there may be a need for confidentiality of SRLGs in some circumstances.
また、セキュリティ侵害と余分なリソース消費から守るのに適切な方針を使用することでクライアントネットワークからの光の接続を求める要求をフィルターにかけなければなりません。 さらに、いくつかの事情にはSRLGsの秘密性の必要があるかもしれません。
Optical networks may also be subject to subtle forms of denial of service attacks. An example of this would be requests for optical connections with explicit routes that induce a high degree of blocking for subsequent requests. This aspect might require some global coordination of resource allocation.
また、光学ネットワークも微妙な形式のサービス不能攻撃を受けることがあるかもしれません。 明白なルートとのその後の要求のための高度合いのブロッキングを引き起こす光の接続を求めてこの例は要求でしょう。 この局面は資源配分の何らかのグローバルなコーディネートを必要とするかもしれません。
Another related form of subtle denial of service attack could occur when improbable optical paths are requested (i.e., paths within the network for which resources are insufficiently provisioned). Such requests for improbable paths may consume ports on optical switching elements within the network resulting in denial of service for subsequent connection requests.
ありそうもない光路が要求されているとき(すなわち、リソースが不十分に食糧を供給されるネットワークの中の経路)、別の関連する形式の微妙なサービス不能攻撃は起こることができました。 ありそうもない経路を求めるそのような要求は、その後の接続要求のためのサービスの否定をもたらしながら、ネットワークの中で光学スイッチング素子の上のポートを消費するかもしれません。
Rajagopalan, et al. Informational [Page 43] RFC 3717 IP over Optical Networks: A Framework March 2004
Rajagopalan、他 光学ネットワークの上の情報[43ページ]のRFC3717IP: 2004年のフレームワーク行進
9.2. Security Considerations for Protocol Mechanisms
9.2. プロトコルメカニズムのためのセキュリティ問題
The security requirements for IP-centric control protocols employed in the control plane of optical networks would depend on the specific characteristics of the protocols and the security risks that exist in a particular operational context. Such details relating to particular operational contexts are beyond the scope of this document and hence are not considered further. Nevertheless, it must be stated that such control protocols must take into account the issues associated with the separation of control channels from data channels in switched optical networks, and the magnitude and extent of service interruptions within the IP domain that could result from outages emanating from the optical domain.
光学ネットワークの制御飛行機で使われたIP中心の制御プロトコルのためのセキュリティ要件はプロトコルの特定の特性と特定の操作上の文脈に存在するセキュリティリスクに依存するでしょう。 特定の操作上の文脈に関連するそのような詳細が、このドキュメントの範囲を超えていて、したがって、さらに考えられません。 それにもかかわらず、そのような制御プロトコルが光学ドメインから発する供給停止から生じることができたIPドメインの中で停電の切り換えられた光学ネットワークのデータ・チャンネル、大きさ、および範囲から制御チャンネルの離別に関連している問題を考慮に入れなければならないと述べなければなりません。
10. Summary and Conclusions
10. 概要と結論
The objective of this document was to define a framework for IP over optical networks, considering the service models, and routing and signaling issues. There are a diversity of choices for IP-optical control interconnection, service models, and protocol mechanisms. The approach advocated in this document was to support different service models which allow for future enhancements, and define complementary signaling and routing mechanisms to enable these capabilities. An evolutionary scenario, based on a common signaling framework (e.g., based on GMPLS) was suggested, with the capability to increase the complexity of interworking functionality as the requirements become more sophisticated. A key aspect of this evolutionary principle is that the IP-optical control and service interaction is first based on the domain services model with overlay interconnection that will eventually evolve to support full peer interaction.
このドキュメントの目的はIPのために光学ネットワークの上でフレームワークを定義することでした、サービスモデルと、ルーティングと問題に合図すると考える場合。 IP光学のコントロールインタコネクトのための選択の多様性、サービスモデル、およびプロトコルメカニズムがあります。本書では支持されたアプローチはこれらの能力を可能にするために今後の増進を考慮して、補足的なシグナリングとルーティングメカニズムを定義する異なったサービスモデルをサポートすることでした。 進化論のシナリオ、一般的なシグナリングに基づいてフレームワーク(例えば、GMPLSに基づいている)は示されました、要件が、より洗練されるようになるので機能性を織り込む複雑さを増強する能力で。 この進化論の原則の特徴はIP光学に制御されるということです、そして、サービス相互作用は最初に、結局完全な同輩相互作用をサポートするために発展するオーバレイインタコネクトでドメインサービスモデルに基づいています。
11. Informative References
11. 有益な参照
[1] Awduche, D. and Y. Rekhter, "Multi-Protocol Lambda Switching:
Combining MPLS Traffic Engineering Control With Optical
Crossconnects", IEEE Communications Magazine, March 2001.
[1]AwducheとD.とY.Rekhter、「以下を切り換えるマルチプロトコルλ」 「MPLS交通工学コントロールを光学Crossconnectsに結合する」IEEEコミュニケーション雑誌、2001年3月。
[2] Lang, J., et al., "Link Management Protocol", Work in progress.
[2] ラング、J.、他、「リンク管理プロトコル」、進行中のWork。
[3] Kompella, K. and Y. Rekhter, "LSP Hierarchy with MPLS TE",
Internet Draft, Work in progress.
[3]KompellaとK.とY.Rekhter、「MPLS TEとのLSP階層構造」、インターネットDraft、進行中のWork。
[4] Berger, L., Ed., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Functional Description", RFC 3471, January
2003.
[4] エドバーガー、L.、RFC3471、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)は機能的な記述を示す」1月2003日
Rajagopalan, et al. Informational [Page 44] RFC 3717 IP over Optical Networks: A Framework March 2004
Rajagopalan、他 光学ネットワークの上の情報[44ページ]のRFC3717IP: 2004年のフレームワーク行進
[5] Rajagopalan, B., "Documentation of IANA Assignments for Label
Distribution Protocol (LDP), Resource ReSeVation Protocol
(RSVP), and Resource ReSeVation Protocol-Traffic Engineering
(RSVP-TE) Extensions for Optical UNI Signaling", RFC 3476,
March 2003.
[5] Rajagopalan、B.、「ラベル分配プロトコル(自由民主党)のためのIANA課題のドキュメンテーション、リソースReSeVationは光学UNIシグナリングのために(RSVP)、およびリソースReSeVationプロトコル交通工学(RSVP-Te)拡大について議定書の中で述べます」、RFC3476、2003年3月。
[6] The Optical Interworking Forum, "UNI 1.0 Signaling
Specification", December 2001.
[6] 光学織り込むフォーラム、「UNI1.0シグナリング仕様」、2001年12月。
[7] Kompella, K., et al., "OSPF Extensions in Support of
Generalized MPLS," Work in Progress.
[7]Kompella、K.、他、「一般化されたMPLSを支持したOSPF拡張子」、ProgressのWork。
[8] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP4)",
RFC 1771, March 1995.
[8]RekhterとY.と1995年のT.李、「ボーダ・ゲイトウェイ・プロトコル4(BGP4)」、RFC1771行進。
[9] Berger, L., Ed., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReSeVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[9] エドバーガー、L.、RFC3473、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)はリソースReSeVationプロトコル交通工学(RSVP-Te)拡大を示す」1月2003日
[10] Mannie, E., "GMPLS Extensions for SONET/SDH Control", Work in
Progress.
[10] マニー、E.、「Sonet/SDHコントロールのためのGMPLS拡張子」が進行中で働いています。
[11] Doshi, B., Dravida, S., Harshavardhana, P., et. al, "Optical
Network Design and Restoration," Bell Labs Technical Journal,
Jan-March, 1999.
etドーシと、B.と、ドラヴィダ人と、S.と、Harshavardhanaと、P.と、アルと、「光学ネットワークデザインと王政復古」(ベル研究所Technical Journal)が1月行進させる[11]、1999。
[12] Kompella, K., et al., "Link Bundling in MPLS Traffic
Engineering", Work in Progress.
[12]Kompella、K.、他、「MPLS交通工学におけるリンクバンドリング」、ProgressのWork。
[13] Ramamurthy, S., Bogdanowicz, Z., Samieian, S., et al.,
"Capacity Performance of Dynamic Provisioning in Optical
Networks", Journal of Lightwave Technology, January 2001.
[13]Ramamurthy、S.、Bogdanowicz、Z.、Samieian、S.、他、「光学ネットワークにおける、ダイナミックな食糧を供給することの容量パフォーマンス」、Lightwave Technology(2001年1月)のJournal。
[14] Crawley, E., Nair, R., Rajagopalan, B. and H. Sandick, "A
Framework for QoS-based Routing in the Internet", RFC 2386,
August 1998.
[14] クローリーとE.とナイアとR.とRajagopalanとB.とH.Sandick、「インターネットのQoSベースのルート設定のためのフレームワーク」、RFC2386、1998年8月。
[15] Awduche, D., Berger, L., Gan, D., Li, T., Swallow, G. and V.
Srinivasan, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC
3209, December 2001.
[15]Awduche、D.、バーガー、L.、ガン、D.、李、T.、ツバメ、G.、およびV.Srinivasan、「RSVP-Te:」 「LSP TunnelsのためのRSVPへの拡大」、RFC3209、2001年12月。
[16] Suurballe, J., "Disjoint Paths in a Network", Networks, vol. 4,
1974.
[16]Suurballe、J.、「ネットワークで経路をばらばらにならせてください」、Networks、vol.4、1974。
[17] Chiu, A., et al., "Impairments and Other Constraints On Optical
Layer Routing", Work in Progress.
[17] チウ、A.、他、「光学における損傷と他の規制はルート設定を層にする」ProgressのWork。
Rajagopalan, et al. Informational [Page 45] RFC 3717 IP over Optical Networks: A Framework March 2004
Rajagopalan、他 光学ネットワークの上の情報[45ページ]のRFC3717IP: 2004年のフレームワーク行進
12. Acknowledgments
12. 承認
We would like to thank Zouheir Mansourati (Movaz Networks), Ian Duncan (Nortel Networks), Dimitri Papadimitriou (Alcatel), and Dimitrios Pendarakis (Tellium) for their contributions to this document. The Security Considerations section was revised to reflect input from Scott Bradner and Steve Bellovin.
このドキュメントへの彼らの貢献についてZouheir Mansourati(Movaz Networks)、イアン・ダンカン(ノーテルNetworks)、ディミトリPapadimitriou(アルカテル)、およびデーメートリオスPendarakis(Tellium)に感謝申し上げます。 Security Considerations部は、スコット・ブラドナーとスティーブBellovinからの入力を反映するために改訂されました。
13. Contributors
13. 貢献者
Contributors are listed alphabetically.
アルファベット順に、貢献者は記載されています。
Brad Cain Cereva Networks 3 Network Dr. Marlborough, MA 01752
ブラッドカインCerevaネットワーク3はマールバラ博士、MA 01752をネットワークでつなぎます。
EMail: bcain@cereva.com
メール: bcain@cereva.com
Bilel Jamoussi Nortel Networks 600 Tech Park Billerica, MA 01821
ビルリカ、Bilel Jamoussiノーテルネットワーク600の科学技術のPark MA 01821
Phone: 978-288-4734 EMail: jamoussi@nortelnetworks.com
以下に電話をしてください。 978-288-4734 メールしてください: jamoussi@nortelnetworks.com
Debanjan Saha
Debanjanシャハ
EMail: debanjan@acm.org
メール: debanjan@acm.org
Rajagopalan, et al. Informational [Page 46] RFC 3717 IP over Optical Networks: A Framework March 2004
Rajagopalan、他 光学ネットワークの上の情報[46ページ]のRFC3717IP: 2004年のフレームワーク行進
14. Authors' Addresses
14. 作者のアドレス
Bala Rajagopalan Tellium, Inc. 2 Crescent Place P.O. Box 901 Oceanport, NJ 07757-0901
私書箱901Oceanport、Bala Rajagopalan Tellium Inc.2の三日月形Placeニュージャージー07757-0901
EMail: braja@tellium.com
メール: braja@tellium.com
James V. Luciani Marconi Communications 2000 Marconi Dr. Warrendale, PA 15086
Warrendale、ジェームスV.Lucianiマルコニーコミュニケーション2000マルコニーPA博士 15086
EMail: james_luciani@mindspring.com
メール: james_luciani@mindspring.com
Daniel O. Awduche MCI 22001 Loudoun County Parkway Ashburn, VA 20147
Loudounカウンティーの公園道路Ashburn、ダニエルO.Awduche MCI22001ヴァージニア 20147
Phone: 703-886-1753 EMail: awduche@awduche.com
以下に電話をしてください。 703-886-1753 メールしてください: awduche@awduche.com
Rajagopalan, et al. Informational [Page 47] RFC 3717 IP over Optical Networks: A Framework March 2004
Rajagopalan、他 光学ネットワークの上の情報[47ページ]のRFC3717IP: 2004年のフレームワーク行進
15. Full Copyright Statement
15. 完全な著作権宣言文
Copyright (C) The Internet Society (2004). 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.
Copyright(C)インターネット協会(2004)。 このドキュメントは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 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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に情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Rajagopalan, et al. Informational [Page 48]
Rajagopalan、他 情報[48ページ]
一覧
スポンサーリンク
