[要約] 要約：RFC 3717は、光ネットワーク上でのIP通信のフレームワークを提供しています。このRFCの目的は、光ネットワーク上での効率的なIP通信の実現と、ネットワークの設計と運用のガイドラインを提供することです。
Network Working Group B. Rajagopalan
Request for Comments: 3717 Consultant
Category: Informational J. Luciani
Marconi Communications
D. Awduche
MCI
March 2004
IP over Optical Networks: A Framework
光ネットワークを介したIP：フレームワーク
Status of this Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004). All Rights Reserved.
著作権（c）The Internet Society（2004）。無断転載を禁じます。
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ベースの制御プレーンとIP光ネットワークインタラクションの両方を考慮して、光ネットワークを介したIPのフレームワークを定義します（「光学ネットワークを超えるIP」と呼ばれる）。
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
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).
光ネットワークテクノロジーは、機能と機能の点で急速に進化しています。光ネットワークの重要性の増加は、すべての主要なネットワークサービスプロバイダー、通信機器ベンダー、および標準組織による、光ネットワークおよび関連するフォトニックおよび電子インターワーキングの問題に焦点を当てた大量の注意によって証明されています。この点で、「光学ネットワーク」という用語は、SONET/SDHベースの輸送ネットワークの両方を参照するために、一般的に実際に使用されます。
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ベースのプロトコルを適切に採用および適応させるために理解する必要があります。これは特に、復元の場合、およびすべての光学ネットワークでのルーティングとシグナリングの場合です。また、光ネットワークなどの光ネットワークとクライアントネットワークの間の相互作用のためのモデルにはさまざまなビューがあります。この点で合理的な建築的代替案は、相対的なメリットを理解してサポートする必要があります。
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 second is the transport of IP traffic through an optical network together with the control and coordination issues that arise therefrom.
したがって、光ネットワークを介したIPに関連する2つの基本的な問題があります。1つ目は、光ネットワークを利用するデジタルクライアントの種類に関係なく、光ネットワーク制御プレーン内のIPコントロールプレーンプロトコルの適応と再利用です。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に示されています。
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.
このセクションでは、このフレームワークといくつかの関連する概念に関連する用語を紹介します。定義はこのフレームワークに固有のものであり、他の場所に他の解釈がある場合があります。
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).
波長分割多重化（WDM）は、異なる波長で動作する複数の光学信号を単一の光ファイバに多重化し、ファイバーを介して並行して輸送できるようにするテクノロジーです。一般に、各光波長は、デジタルクライアントのペイロードを異なるデータレート（例：OC-3C、OC-12C、OC-48C、OC-192Cなど）と異なる形式（SONET、イーサネット、ATM、等。）。たとえば、1つの光ファイバーでOC-48C（約2.5 Gbps）とOC-192（約10 Gbps）で動作するソネット信号の混合をサポートする多くの商用WDMネットワークが現在存在しています。WDM機能を備えた光学システムは、システムのパフォーマンスと信頼性を維持しながら、複数の波長の平行伝送を優雅に実現できます。近い将来、市販のWDMシステムは、OC-192C以上のデータレートで合計1.6 Tbps以上のデータレートで160を超える波長を同時に運ぶと予想されます。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.波長あたりのシリアルビットレート。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は、光領域の光学チャネル接続の計算とインスタンス化に必要なシグナルおよびルーティングプロトコルを実装するコントロールプレーンプロセッサを持っていると想定されています。
Optical channel trail or 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:
このフレームワークで使用されている光学サブネットワークは、光学チャネルのルーティング、監視、グルーミング、保護、回復などの機能を提供する光学チャネルトレイルのエンドツーエンドネットワークをサポートするOXCのネットワークです。このネットワークでのOXCの相互接続は、一般的なメッシュトポロジに基づいています。次のサブ層がこのネットワークに関連付けられている場合があります。
(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）レイヤーネットワーク：光学マルチプレックスセクションレイヤーは、光チャネルの輸送を提供します。このレイヤーに含まれる情報は、一連の光学チャネルを含むデータストリームであり、定義された集計帯域幅を持つ場合があります。
(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.
ドキュメントで使用されているメッシュ光ネットワークは、ノードの程度が2を超える可能性のある光学サブネットワークのトポロジカル接続コレクションです。このような光学ネットワークは、単一の管理エンティティの範囲内にあると想定されています。また、自律型光学ネットワークの自発的な相互接続で構成される大規模なグローバルメッシュ光ネットワークを考案することも可能です。それぞれが独立したエンティティによって所有および管理されています。このような環境では、抽象化を使用して、外部クラウドから各自律光学クラウドの内部の詳細を隠すことができます。
Optical internetwork
光学インターネットワーク
An optical internetwork is a mesh-connected collection of optical networks. Each of these networks may be under a different administration.
光学インターネットワークは、光ネットワークのメッシュ接続コレクションです。これらの各ネットワークは、別の管理下にある場合があります。
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.
波長連続性プロパティを満たす光パスは、波長経路と呼ばれます。
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ドープ繊維アンプ<< 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操作（再形成、retiming、再生、およびおそらく増幅）を含む可能性のある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.
信頼ドメインは、ドメインの外部からの不正な侵入を防ぐために適切なセキュリティ対策が確立される単一の技術管理の下でのネットワークです。したがって、ドメイン内のほとんどのノードは、何らかの形で安全または信頼されているとみなされると想定される場合があります。一般的に、一連の管理事業体が互いに拡大した不均一な信頼ドメインを形成することに同意する場合、信頼ドメインに対する「単一の」管理制御のルールは実際に緩和される可能性があります。ただし、このドキュメントの議論を簡素化するために、一般性を失うことなく、Trust Domainという用語が適切なセキュリティポリシーを持つ単一の管理エンティティに適用されると想定されます。トラストドメイン内では、いずれかの破壊されたノードは、ネットワーク全体を損なう可能性のあるコントロールメッセージを送信できることに注意してください。
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）を使用すると、特定の波長内の各時間の量子量子量子量子をaとして考慮することができます。流れ。
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つのアクセスポイント間の同じパスを通過するトラフィックフローの抽象化であり、トラフィックのいくつかの特性と属性をパラメーター化できます。
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.
光学インターネットワークは、複数の光学ネットワークで構成されていると想定されており、それぞれが別のエンティティによって管理される場合があります。各光学ネットワークは、一般的なトポロジ（光メッシュネットワークと呼ばれる）の光ファイバリンクによって相互接続されたサブネットワークで構成されています。このネットワークには、単一のベンダーまたは複数のベンダーからの再構成可能な光学機器が含まれる場合があります。近期では、各サブネットワークは単一のベンダーからのスイッチで構成されると予想される場合があります。将来、標準化の取り組みが成熟するにつれて、各光学サブネットワークには、実際には異なるベンダーからの光スイッチが含まれている場合があります。いずれにせよ、各サブネットワーク自体は内部でメッシュ接続されていると想定されています。一般に、光学メッシュネットワーク内のトポロジカルに隣接するOXCは、複数の並列（双方向）光リンクを介して接続されることが予想されます。このネットワークモデルを図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 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.
この環境では、光学電気術（OEO）変換を伴うすべての光学的OXCまたはOXCSから完全に構成されている可能性があります。サブネットワーク間の相互接続は、必要に応じて適切な光電気変換を伴う互換性のある物理インターフェイスを介して実装されると想定されています。光ネットワークと直接物理的な接続性を持つルーターは、光ネットワークに関して「エッジルーター」と呼ばれます。図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>のフォームであるエントリのクロスコネクトテーブルのセットアップと見なされる場合があります。波長選択的クロスコネクト（一般にWXCと呼ばれる）のコンテキストでは、クロスコネクトテーブルは、入力と出力ポートとともに入力波長と出力波長を示している場合があります。OXCの侵入ポートからリモートOXCの出口ポートまでの光パスは、侵入、出口、および侵入から侵入から連続的な物理的経路が存在するように中間OXCの適切なクロスコネクトをセットアップすることにより確立されます。出力ポート。光学パスは双方向である傾向があります。つまり、出口ポートからイングレスポートへのリターンパスは、通常、フォワードパスと同じ中間インターフェイスカードに沿ってルーティングされますが、これはあらゆる状況ではそうではない場合があります。
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) | | |
+- ------------+ +------------+
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 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.
OXCから出る複数のトラフィックストリームは、WDMテクノロジーを使用して光ファイバーリンクに多重化される場合があります。WDM機能はOXCの外側に存在し、OXCに対して透過的である可能性があります。または、この関数はOXCに組み込まれる場合があります。後のケースでは、クロスコネクトテーブル（概念的に）は、フォームのペアで構成されています<{入力ポートI、ラムダ（j）}、{出力ポートK、ラムダ（L）}>。これは、入力ポートI上の波長ラムダ（j）で受信されたデータストリームが、ラムダ（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.
このネットワークモデルでは、ルーターがユーザートラフィックを転送する前に、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ベースのコントロールプレーンの問題は、複数の光パスをプロビジョニングおよび復元するための標準シグナル伝達とルーティングプロトコルの設計に関係しています。同様に、光ネットワークを介したIPトランスポートには、IPリーチビリティを確立し、光ネットワークを介してあるIPエンドポイントから別のIPエンドポイントへの転送パスをシームレスに構築することが含まれます。
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つの論理制御インターフェイスがあります。これらは、クライアントオプティックインターネットワークインターフェイス、光ネットワーク内の内部ノード間インターフェイス（異なるサブネットワークのOXCの間）、および外部ノードからノードへのノードです。異なる光ネットワークのノード間のインターフェース。これらのインターフェイスは、それぞれユーザーネットワークインターフェイス（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は、ノード間の制御フローを制限するポリシーが異なる場合があります。
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を介して、制御情報、特にルーティング関連情報の流れを最小限に抑える必要がある場合があります。そしてエンニの上でさえ。この場合、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またはISIS（トラフィックエンジニアリング拡張機能と、光ネットワークの独特な特性に対処するための追加の拡張機能）、またはBGP、またはその他のプロトコルです。他のディレクトリベースのルーティング情報交換も可能です。シグナル伝達プロトコルの選択の一部は、RSVP-TEまたはCR-LDPの適応です。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 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.
2. 間接インターフェイス：クライアントと光ネットワーク内のデバイスの間にバンド外のIPコントロールチャネルが実装され、サービスの要求と応答を信号することができます。たとえば、光ネットワーク内の管理システムまたはサーバーは、クライアントからサービスリクエストを受信する場合があります。同様に、クライアントの管理システムと光学ネットワークの間で帯域外シグナリングを使用して、サービス要求を信号することができます。これらの場合、クライアントとそれぞれのOXCとの間に直接的な制御相互作用はありません。間接的なインターフェイスを持つ理由の1つは、OXCSおよび/またはクライアントが直接シグナリングインターフェイスをサポートしていないことです。
+---------------------------+ +---------------------------+
| | | |
| +---------+ +---------+ | | +---------+ +---------+ |
| | | | | | | | | | | |
| | Routing | |Signaling| | | | Routing | |Signaling| |
| | Protocol| |Protocol | | | | Protocol| |Protocol | |
| | | | | | | | | | | |
| +-----+---+ +---+-----+ | | +-----+---+ +---+-----+ |
| | | | | | | |
| | | | | | | |
| +--+-----------+---+ | | +--+-----------+---+ |
| | | | | | | |
| | IP Layer +....IPCC.....+ IP Layer | |
| | | | | | | |
| +------------------+ | | +------------------+ |
| | | |
| Edge Router | | 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光および光学サブネットワーク制御の相互作用の直接的なインターフェイスを想定しています。
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でのサービスモデルと要件を考慮します。UNIでのサービスのために2つの一般的なモデルが登場しました（これはNNISでも適用できます）。これらのモデルは次のとおりです。
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: 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.
ドメインサービスモデルでは、光学ネットワークは主にLightPathsの形で高い帯域幅接続を提供します。UNI全体の標準化されたシグナル伝達（図1）は、次のサービスを呼び出すために使用されます。1。LightPathの作成：このサービスは、光ネットワークの終了点のペア間で指定された属性を作成することを可能にします。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またはLDPに基づいている場合があります。
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.
光学ドメインサービスモデルは、光ネットワークの端にあるルーター間のライトパストポロジーを確立することになります。結果のIPオーバーオプティカルネットワークのオーバーレイモデルについては、セクション5で説明します。
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 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と光ネットワークは、コントロールプレーンの観点から単一の統合ネットワークとして一緒に扱われます。この点で、OXCは、コントロールプレーンを考慮する限り、他のルーターと同じように扱われます。したがって、原則として、ルーティングとシグナリングの観点から、UNI、NNIS、およびその他のルーター間インターフェイスとの間に区別はありません。[1]で説明されているように、この制御面はIPベースであると想定されています。統一されたサービスモデルは、これまでのところ、単一の管理ドメインのコンテキストでのみ議論されてきました。光学的インターネットワーク内に管理境界がある場合でも、統合された制御プレーンが可能ですが、統合されたルーティング機能の一部は、この場合、実際に魅力的または実行可能でさえない場合があります（セクション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.
Unified Service Modelの下で、GMPLSネットワークのコンテキスト内で、エンドツーエンドGMPLSシグナリング中に光ネットワークサービスが暗黙的に取得されます。具体的には、エッジルーターは、指定された属性を備えたLightPathを作成したり、GMPLSラベルスイッチパス（LSP）を作成したりするため、LightPathsを削除および変更できます。この点で、光ネットワークから取得したサービスは、ドメインサービスモデルに似ています。ただし、これらのサービスは、ドメインサービスモデルと比較して、よりシームレスな方法で呼び出される場合があります。たとえば、ルーターが単一の光学ネットワークに接続されている場合（つまり、エニスはありません）、リモートルーターは光学インターネットワーク全体にエンドツーエンドパスを計算できます。その後、光学インターネットワーク全体にLSPを確立できます。しかし、エッジルーターは、光学インターネットワーク全体のLSPがLightPath、または複数のパケットベースのLSPの導管であることを認識する必要があります。
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の帯域幅管理は、ドメインサービスモデルと統一サービスモデルの両方で同じです。統一されたサービスのルーティングモデルとシグナリングモデルは、セクション5および6で説明されています。
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.
上記のサービスモデルの相対的なメリットは長々と議論することができますが、このフレームワークで推奨されるアプローチは、両方のモデルをサポートするルーティングとシグナルメカニズムを定義することです。上記のように、サービスリクエストのシグナリングは、両方のモデルをカバーするために統合できます。統一されたサービスモデルのGMPLSシグナリング[4]の開発と、ドメインサービスモデルの下でのUNIシグナル伝達[5、6]の採用は、本質的にこの見解をサポートしています。ただし、セクション5および6で説明されているように、サービスモデル間の大きな違いはルーティングプロトコルです。
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.
専門サービスは、光ネットワークが提供するポイントツーポイント接続サービスの上に構築できます。たとえば、光学仮想プライベートネットワークとオンデマンドの帯域幅は、想定できるサービスの一部です。
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サービス）の異なるセット間のルーティング分離を確保するルーティングポリシーを実施する方法が必要です。
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ルーターとOXCは、特に光ネットワークに接続された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は、基本的に制御プレーンの組織によって定義されます。このフレームワークの仮定は、GMPLSなどのIPベースのコントロールプレーン[1]が使用されることです。ただし、サービスモデル（セクション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ルーターが光学ネットワークを横切る接続の明示的なパスを選択する際に行使できるコントロールのレベル。
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:
次の相互接続モデルが可能です。
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やIS-ISなどの一般的なIGPを使用して、統合IPを介してトポロジ情報[7]を配布することができます。 - 光学ネットワーク。OSPFの場合、不透明なLSAを使用してトポロジー状態情報を宣伝できます。IS-ISの場合、トポロジー状態情報を伝播するために拡張TLVを定義する必要があります。これらの拡張機能の多くは、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アドレス可能なエンティティになります。
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, is unlikely to scale in very large networks, and may not support the rapid connection provisioning requirements of future highly competitive networking environments.
オーバーレイモデルでは、IPレイヤールーティング、トポロジ分布、およびシグナル伝達プロトコルは、光領域内のルーティング、トポロジ分布、およびシグナルプロトコルに依存しません。このモデルは、ATMまたはMPOAモデルを介した古典的なIPに概念的に類似していますが、代わりに光学的インターネットワークに適用されます。オーバーレイモデルでは、コントロールプレーン（特にルーティングおよびシグナル伝達プロトコル）の個別のインスタンスを、IPドメインに存在するものとは無関係に、光ドメインに展開する必要があります。特定の状況では、オーバーレイモデルのIPドメインの接続性を提供する光学チャネルを静的に構成することも可能です。静的構成は、ネットワーク管理機能を介して実行できます。ただし、静的構成は非常に大きなネットワークで拡張する可能性は低く、将来の非常に競争力のあるネットワーク環境の迅速な接続プロビジョニング要件をサポートしない場合があります。
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ドメインと光学ドメインには個別のルーティングインスタンスがありますが、あるルーティングインスタンスからの特定の種類の情報を他のルーティングインスタンスに渡すことができます。たとえば、外部IPアドレスを光学ルーティングプロトコル内で携帯して、到達可能性情報をIPクライアントに渡すことができます。
The routing approaches corresponding to these interconnection models are described below.
これらの相互接続モデルに対応するルーティングアプローチを以下に説明します。
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および光ネットワークは、適切な「光学的」拡張機能を備えたOSPFなどのIPルーティングプロトコルと同じインスタンスを実行すると想定されています。これらの拡張機能は、光リンクパラメーターと、光ネットワークに固有の制約をキャプチャする必要があります。すべてのノード（OXCとルーター）によって維持されるトポロジとリンク状態情報は同一である場合がありますが、必ずしもそうではありません。このアプローチでは、ルーターがエンドツーエンドパスを光ネットワークを介して別のルーターに計算できます。GMPLS環境でラベルスイッチドパス（LSP）をルーティングする必要性により、パス計算がトリガーされるとします。このようなLSPは、適切な拡張機能を備えたRSVP-TEまたはCR-LDPなどのGMPLSシグナル伝達を使用して確立できます。この場合、シグナル伝達プロトコルは2つのエッジルーター間にライトパスを確立します。このLightPathは本質的に光ネットワークを横切るトンネルであり、最初のLSPをサポートするために必要な帯域幅よりもはるかに大きい容量を持っている可能性があります。したがって、ネットワーク内の他のルーターがLightPath内の過剰な容量の可用性を認識して、ルーター間のその後のLSPが新しい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 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.
[3]に記載されている「隣接する転送」（FA）の概念は、既存のLightPath情報を他のルーターに伝播するのに不可欠です。FAは、本質的にリンク状態ルーティングプロトコルに宣伝されている仮想リンクです。したがって、FAは、通常のリンクのリソースを定義するのと同じパラメーターで説明できます。FAを作成するためのメカニズムを指定する必要がありますが、ルーティングスキームでFAがどのように使用されるかを指定する必要はありません。FAがリンク状態プロトコルで宣伝されると、ルーティングLSPの使用法は、実装されたルート計算およびトラフィックエンジニアリングアルゴリズムによって定義されます。
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光学インターフェイスでは、ルーターがOXCに接続されている物理ポートが接続性とリソースの可用性を制限することに注意する必要があります。ルーターR1が2つのポート、P1とP2にわたってOXC O1に接続されているとします。統合されたルーティングでは、2つのポートにわたるR1とO1の間の接続性が、ネットワークのリンク状態表現でキャプチャされていました。ここで、ポートP1を介してR1から別のルーターR2にフルポート帯域幅のFAが作成されるとします。このFAはR1とR2の間の仮想リンクとして宣伝されていますが、そのポートはLightPathの作成に使用できなくなったため、リンク状態表現からリンクR1-O1（P1を超える）を削除する必要もあります。したがって、FASが作成されると、仮想リンクのオーバーレイセットがリンク状態表現に導入され、以前にIP光インターフェイスで宣伝されていたリンクを置き換えます。最後に、リンク状態表現でキャプチャされた光ネットワークの詳細は、FAのネットワークに置き換えられます。上記のスキームは、問題に取り組む1つの方法です。別のアプローチは、適切な動的属性をリンク状態情報に関連付けることです。そのため、特定のタイプの接続を確立するために使用できないリンクが適切にタグ付けされます。ただし、一般的に、統合されたルーティングとドメイン固有のルーティングとの間には非常に多くの類似性があります（次に説明）。どちらも最終的に、特定のトラフィックエンジニアリングの目標を達成するために、仮想LightPathトポロジ（光ネットワーク上にオーバーレイされている）の作成を扱います。
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ドメインルーティングモデルに似ています。これに対する特定のアプローチが次に考慮されます。他のアプローチも同様に可能であることに注意する必要があります。
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 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).
ドメイン間IPルーティングプロトコルであるBGP [8]は、IPドメインと光学ドメイン間のルーティング情報を交換するために適応する場合があります。これにより、ルーターはネットワーク内のIPアドレスプレフィックスを光学インターネットワークに宣伝し、光学インターネットワークから外部IPアドレスプレフィックスを受信できます。光学インターネットワークは、1つのIPネットワークから他のネットワークに到達可能な情報を輸送します。たとえば、エッジルーターとOXCは外部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を宛先ノードに確立するつもりであるとします。光学インターネットワークには外部に到達可能なIPアドレスの知識があるため、LightPathの出力光ポートを明示的に指定することなく、その目的地に直接LightPathを要求する場合があります。ただし、同じエッジルーターが別の外部宛先に別のLSPを確立する場合、効率的な理由で、最初にターゲット宛先に既存のLightPath（十分な残留容量）があるかどうかを判断する必要がある場合があります。この目的のために、エッジルーターが光学的インターネットワークのどの出力ポートが外部の宛先につながるかを追跡する必要があるかもしれません。したがって、EBGPを介したエッジルーターから外部IPプレフィックスを受信するボーダーOXCは、これらのプレフィックスを他の境界OXCまたはエッジルーターに伝播する前に、出口点として独自のIPアドレスを含める必要があります。この情報を受信するエッジルーターは、出力アドレスをさらに伝播する必要はありませんが、外部IPアドレスと出力OXCアドレスの間の関連性を維持する必要があります。光学VPNが実装されると、Border OXCSによって宣伝されているアドレスのプレフィックスには、VPN固有の識別が伴う場合があります。
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 光ネットワーク制御プレーンの安定性は、光ネットワーク内で発せられるダイナミクスだけによって決定されることはありませんが、外部のリーチ性情報が受信される外部ルーティングドメインに由来するダイナミクスの影響を受ける可能性があります。
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 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.
オーバーレイルーティングアプローチは、オーバーレイの相互接続モデルをサポートします。このアプローチでは、エッジルーターが登録および外部アドレスのクエリを許可するオーバーレイメカニズムが実装されます。これは、ATMを介したIPに使用されるアドレス解像度メカニズムと概念的に類似しています。このアプローチでは、光学ネットワークは、Edgeルーターが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最適なインターフェイスの接続性は限られているため、LightPathを確立する必要がある数と、トラフィックエンジニアリングの決定とは異なるものを決定します。さらに、このようなLightPathの最初のセットが確立された後、これらは、たとえばOSPFなど、VPN全体のルーティングスキームのVPN内の隣接として使用できます。このアプローチにより、エッジルーターは、レジストリを照会することにより、最初に対象の他のエッジルーターを決定できます。適切なアドレスを取得した後、最初のオーバーレイLightPathトポロジが形成される場合があります。その後、ルーティングの隣接はライトパス全体に確立され、さらにルーティング情報を交換してVPN全体のルーティングを確立することができます。
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]で説明されています。RSVP-TEなどのトラフィックエンジニアリング拡張機能を備えたMPLSシグナリングプロトコルは、適切に拡張して、LightPath要求のシグナリングに使用できます。これらのプロトコルは、ドメインサービスモデルの場合のクライアント/サーバーシグナル伝達、および統一されたサービスモデルの場合のエンドツーエンドの統合シグナリングに適合させることができます。
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].
ドメインサービスモデルを使用すると、以下の図3に示すように、IPおよび光学ネットワークのシグナリング制御プレーンが完全に分離されています。この分離は、IPと光学アドレススペースの分離も意味します（光ネットワークが内部IPアドレス指定を使用している場合でも）。RSVP-TEおよびLDPはUNIシグナル伝達に適合させることができますが、これらのプロトコルの完全な機能は使用されません。たとえば、UNIシグナルは明示的なルートの仕様を必要としません。一方、サービス属性に基づいて、[5、6]で説明されているように、これらのプロトコルを使用して新しいオブジェクトを信号する必要があります。
MPLS Signaling UNI Signaling MPLS or other signaling
|
+-----------------------------+ | +-----------------------------+
| IP Network | | | Optical Internetwork |
| +---------+ +---------+ | | | +---------+ +---------+ |
| | | | | | | | | | | | |
| | Router +---+ Router +-----+------+ OXC +---+ OXC | |
| | | | | | | | | | | | |
| +-----+---+ +---+-----+ | | | +-----+---+ +---+-----+ |
+-----------------------------+ | +-----------------------------+
|
|
Completely Separated Addressing and Control Planes
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.
統一されたサービスモデルでは、図4に示すように、IPネットワークと光学インターネットワークでアドレス指定が一般的であり、それぞれのシグナル伝達制御が関連しています。-TEまたはCR-LDPプロトコル。しかし、光学インターネットワーク内のサービスのセマンティクスは、IPネットワークのセマンティクスとは異なる場合があります。例として、光学インターネットワークで提供される保護サービスは、IPネットワークが提供するエンドツーエンドの保護サービスとは異なる場合があります。別の例は、帯域幅に関するものです。IPネットワークは帯域幅の連続体を提供する場合がありますが、光学インターネットワークは個別の帯域幅のみを提供します。したがって、信号属性とサービスは、IPおよび光学ドメインに対して独立して定義されます。したがって、光学インターネットワークの端にあるルーターは、サービス境界を識別し、IP光の境界を横切る信号メッセージで適切な翻訳を実行する必要があります。これは、両方のネットワークのシグナリング制御プレーンがGMPLSベースであり、ドメインサービスモデルと比較してコントロールプレーンのより緊密な結合がある場合でも発生する可能性があります。
Service Boundary Service Boundary
| |
IP Layer GMPLS Signaling | Optical Layer GMPLS | IP Layer GMPLS
| |
+--------+ +--------+ | +-------+ +-------+ | +--------+
| | | | | | | | | | | |
| IP LSR +--+ IP LSR +--+--+Optical+--+Optical+-+--+ 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]で説明されています。
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?
Ingress IPルーターから、Ingress IPネットワーク全体の出口ルーター、トランジット光学インターネットワーク、出力IPネットワークにLSPが確立されているとします。このLSPがIPレイヤーで保護される場合、IPレイヤーと光層の間でサービスはどのように調整されますか？
Under this scenario, there are two approaches to end-to-end protection:
このシナリオでは、エンドツーエンドの保護には2つのアプローチがあります。
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 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.
IPレイヤーの保護サービスは、光学インターネットワークを横断するLSPセグメントに光学レイヤー保護サービスを利用できます。したがって、エンドツーエンドのLSPは、保護ポイントからの3つのLSPセグメントの連結として扱われます。IngressIPネットワークのセグメント、光学インターネットワークのセグメント、およびEgress IPネットワークのセグメントです。エンドツーエンドLSPのIPレイヤーの保護サービスは、光学インターネットワークが提供する適切な保護サービスにマッピングする必要があります。IPレイヤーでLSPに1 1の保護が提供されていると仮定します。つまり、保護された各LSPには、1 1または1：1の構成で事前に確立されたホットスタンドバイがあります。プライマリLSPが失敗した場合、トラフィックはすぐにスタンバイに切り替えることができます。このタイプの保護は、次のようにエンドツーエンドで実現できます。図5を参照して、LSPを（イングレス）ルーターインターフェイスAで発信し、（出口）ルーターインターフェイスFで終了します。最初の保護オプションでは、LSPの主要なパスを最初に確立する必要があります。このパスを図5に示すように、イングレスネットワークのルーターインターフェイスB、光ポートC（イングレス）およびD（出口）、および出口ネットワークのルーターインターフェイスEを通過します。次に、ポイントAとB、C、D、およびEとFの間の保護パスを確立することにより、各ネットワークで1 1保護が個別に実現されます。さらに、ドロップサイド保護を使用して、セグメントB-CとD-Eは1 1保護されている必要があります。CとDの間のセグメントの場合、光学インターネットワークは、IPネットワークで提供されるものと同様の1 1サービスを提供する必要があります。
+----------------+ +------------------+ +---------------+
| | | | | |
A Ingress IP Net B----C Optical Internet D----E Egress IP Net F
| | | | | |
+----------------+ +------------------+ +---------------+
Figure 5: End-to-End Protection Example
図5：エンドツーエンドの保護の例
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を参照すると、AとFの間に2つのSRLG-Disjoint LSPが確立されます。光学インターネットワークの対応するセグメントは、光学インターネットワークの独立した光パスとして扱われます。これらのLightPathは、光学的インターネットワークでは保護されていない場合があります。
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 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.
これら2つの選択肢の区別は次のとおりです。最初の選択では、光学インターネットワークはエンドツーエンドの保護に積極的に関与していますが、2番目の選択では、光学インターネットワークで提供される保護サービスは、クライアントIPネットワークによって直接使用されません。また、最初の選択の下で、光学インターネットワークの保護は、多くのIP LSPに集合的に適用される場合があります。つまり、図5を参照すると、多くのLSPがCとDの間の単一のLightPathに集約される可能性があります。その後、光学的インターネットワーク保護を一度にすべてに適用できます。2番目の選択では、各IP LSPを個別に保護する必要があります。最後に、最初の選択により、IPおよび光学インターネットワークに異なる復元シグナリングを実装できます。これらの修復プロトコルは、エンドツーエンドの保護を実現するために、サービス境界で「パッチアップ」されます。これのさらなる利点は、復元が障害が発生するネットワーク内に完全に含まれているため、回復潜時を改善し、おそらく光学ドメイン内の障害としてのネットワークの安定性が封じ込められ、ドメイン内に修正されることです。たとえば、光学インターネットワークに障害がある場合、光ネットワークプロトコルは影響を受ける内部セグメントを復元します。2番目の選択では、復元シグナルは常にIPルーター間のエンドツーエンドであり、基本的に光学インターネットワークをバイパスします。この結果、回復潜時が高くなる可能性があります。さらに、IPレイヤーの復元プロトコルは、オーバーレイモードの光学インターネットワークを透過的に実行する必要があります。ただし、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ネットワーク間のエンドツーエンドのライトパスのプロビジョニングと復元には、光学サブネットワーク内のプロトコルとシグナリングサポートが必要です。この点で、光学サブネットワーク内（図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.
単一のベンダーサブネットワーク内の制御プレーンの手順は、これらが独自のものになる可能性があるため定義する必要はありません。明らかに、サブネットワーク内およびサブネットワーク全体で同じ制御手順に従うことができます。しかし、これは、命令的な要件ではなく、このフレームワークドキュメント内の単なる推奨事項です。したがって、以下では、サブネットワーク全体のシグナルとルーティングが最初に見なされ、その後、ネットワーク全体で同様の問題について議論します。
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つはアドレス指定の問題です。シグナリングとルーティングの観点から特定できるエンティティは何ですか？彼らはどのように対処すべきですか？このセクションでは、この問題に関するいくつかの高レベルのガイドラインを紹介します。
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.
光ネットワークの識別可能なエンティティには、OXC、光学リンク、光学チャネル、サブチャネル、共有リスクリンクグループ（SRLG）などが含まれます。ここでの問題は、光学トレイルの確立に関する限り識別が粒状である必要があることです。識別のスキームは、光学トレイルを確立する際に、光学ネットワーク内の終端ポイントの仕様に適切な粒度を備えた仕様に対応する必要があります。たとえば、OXCには多くのポートがあり、それぞれが多くの光学チャネルを終了する可能性があります。それぞれが多くのサブチャネルなどを含む可能性があります。すべてのサブチャネルまたはチャネル終了、またはOXCさえも想定することは合理的ではないでしょう。ポートには、一意のIPアドレスを割り当てることができます。また、ネットワーク内の光学トレイルのルーティングは、正確な終端ポイント情報に依存するのではなく、終了OXCのみに依存します。したがって、終端ポイントのより細かい粒度の識別は、中間のOXCではなく終端OXCにのみ関連します（もちろん、各中間点でのリソース割り当ては、要求されたリソースの粒度に依存します）。これは、OXCが一意のIPアドレスによって識別される識別スキームと、「セレクター」がOXCでの関連性のさらに細粒情報を識別することを示唆しています。これは、もちろん、これらの終端ポイントの識別をIPアドレス（nullセレクターを使用して）で直接排除することはできません。セレクターをフォーマットして、適切な数のビットと、ポート、チャネル、サブチャネルなどを表現する構造を識別できます。
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].
光ネットワーク内では、隣接するOXC間のトレイルセグメントの確立には、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の顕著な特性は、特定のリンクが複数のSRLGに属し、特定のSRLGに属する2つのリンクが個別に他の2つのSRLGに属する可能性があることです。これを図6に示します。ここでは、リンク1、2、3および4はSRLG 1に属し、リンク1,2および3がSRLG 2に属し、リンク4がSRLG 3に属する可能性があります。同様に、リンク5および6に属する可能性があります。SRLG 1に属する可能性があり、リンク7と8はSRLG 4に属する可能性があります（この例では、同じSRLG、つまり1には2つの異なる隣接からのリンクが含まれています）。
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への物理リソースの分類は手動操作ですが、光ネットワーク内のこれらのSRLGへの一意の識別子の割り当ては、保護のために正しいSRLG-Disjointパス計算を確保するために不可欠です。SRLGは、フラット識別子（32ビット整数など）で識別できます。
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.
最後に、隣接するOXC間の光学リンクは、広告のためにリンク状態プロトコルにバンドルされる場合があります[12]。バンドルされたインターフェイスに番号が付けられているか、数字が付いていない場合があります。どちらの場合でも、バンドル内のコンポーネントリンクを識別できる必要があります。SRLG識別と協力すると、この情報は正しいパス計算に必要です。
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は、各光リンクのアップ/ダウンステータス、リンクの帯域幅およびその他のパラメーター、およびリンクのリモートエンドのID（例：リモートポート番号）を決定する必要があります。最後の情報は、LightPathのプロビジョニングのシグナリング時に適切なラベルを指定するために使用されます。これらのパラメーターの決定は、手動構成と隣接するOXC間で実行される自動プロトコルの組み合わせに基づいている可能性があります。このようなプロトコルの特性は、隣接するOXCのタイプ（透明または不透明など）に依存します。
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の場合、隣接するOXCポートで隣接発見プロトコル（LMP [2]など）の1つのインスタンスが実行され、隣接するOXCの対応するプロトコルインスタンスと通信されます。プロトコルは、ソネットのオーバーヘッドバイトを利用して、（構成された）ローカル属性を定期的に隣接に送信します。したがって、2つの隣接するスイッチは、互いのアイデンティティとローカル接続性を自動的に決定し、ローカルリンクのアップ/ダウンステータスを追跡できます。透明なOXCを使用した隣接の発見は[2]で説明されています。
+--------------+ +------------+ +------------+
| +-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：SRLGを使用したメッシュ光ネットワーク
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、ISISなど）の一部として実行されるか、管理プレーン（集中パス計算の場合）を介して実行できます。ネットワーク内でのリンク状態プロトコルの実装（つまり、サブネットワークの境界全体）は、すべてのサブネットワークで同じプロトコルがOXCで実行されることを意味します。この仮定が保持されない場合、サブネットワーク間のルーティングの相互作用が必要です。これは、セクション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]。また、バンドルの各光リンクに対応するSRLGは、パラメーターとして含まれる場合があります。
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）は、さらなる作業が必要な領域です。
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の自動回復は、光ネットワークが提供するサービスです。ネットワーク内のライトパスを回復するためのローカルおよびエンドツーエンドのメカニズムがあります（イニを横切っています）。ローカルメカニズムは、障害が（保護された）LightPathがルーティングされているプライマリリンク（またはプライマリネットワークセグメント）に影響を与える場合、INNI全体の2つのOXC間の代替リンク（またはネットワークセグメント）を選択するために使用されます。局所的な修復は、LightPathのエンドツーエンドルートに影響しません。局所的な修復が不可能である場合（たとえば、問題の隣接するOXCの間に代替リンクが利用できない場合）、エンドツーエンドの復元を実行できます。このシナリオでは、影響を受ける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 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.
エンドツーエンドの保護は、2種類の保護スキームに基づいている場合があります。「1 1」保護または共有保護。1 1の保護下で、身体的に多様なルートに沿った保護された一次パスのバックアップパスが確立されます。両方のパスがアクティブであり、主要なパスに沿った障害により、バックアップパスへの即時のスイッチがなります。共有保護の下で、物理的に多様な一次パスに対応するバックアップパスは、同じネットワークリソースを共有する場合があります。障害が主要な経路に影響を与える場合、バックアップがリソースを共有する他の主要なパスに同じ障害が影響しないと想定されています。
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によって計算され、標準的な方法を使用してシグナルとされると想定されています。
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の一部であるリンクを横断しないバックアップパスを計算する必要があります。したがって、プライマリパスのSRLGは、代替パス計算中に、他のSRLGに属するリンク内のリソースの可用性とともに、認識されることが不可欠です。この要件には、光リンクバンドリングに特定の意味があります。具体的には、バンドルされたLSAには、リモートのOXCがバンドルされたリンクが指す各SRLGの下でのリソースの可用性と、バンドル内の異なるSRLGに属するリンク間の関係を決定できるように、適切な情報を含める必要があります。たとえば、図3を考慮して、リンク1、2、3、4がLSAにまとめられている場合、バンドルされたLSAは、バンドルの一部である3つのSRLGがあることを示す必要があります（つまり、1、2、および3）、およびSRLGS 2および3のリンクもSRLG 1の一部です。
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:
Bundle No. SRLGs Link Type Number Other Info
-------------------------------------------------------
1 1,2 OC-48 3 ---
2 1,3 OC-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. 一次パスを最初に計算でき、（排他的または共有）バックアップを次に、プライマリパスに選択したSRLGに基づいて計算されます。この点について、
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 プライマリパス計算手順は、パスがルーティングされる一連のバンドルを出力できます。バンドルは一連のSRLGと一意に識別されるため、この知識に基づいて代替パスはすぐに計算できます。この場合、選択したバンドルにリソースが不足しているために設定されたプライマリパスが成功しない場合、プライマリとバックアップパスを再計算する必要があります。
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 特定のバンドルAprioriを選択せずに、一次パスを計算することが望ましい場合があります。つまり、特定のバンドル情報ではなく、ノードペア間のすべてのバンドルにわたるリソースの可用性が考慮されます。この場合、プライマリパス計算手順は、パスが通過する一連のノードを出力します。パス内の各OXCは、プライマリパスのセグメントをルーティングするために特定のバンドルを選択する自由があります。この手順は、リンク状態情報がどこにでも最新ではない場合に、主要なパスを正常にセットアップする可能性を高めます。しかし、選択した特定のバンドル、したがってプライマリパスのSRLGSは、たとえばRSVP-TEルートレコードオブジェクト[15]を使用して、プライマリパスのセットアップ中にキャプチャする必要があります。このSRLG情報は、バックアップパスの計算に使用されます。また、バックアップパスは、使用するバンドルではなく、特定のセグメントで回避するSRLGのみを指定することも確立できます。これにより、バックアップパスを確立する可能性が最大になります。
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]を使用して、1つのステップで一緒に計算されます。この場合、特定のバンドル情報を使用してパスを計算する必要があります。
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 needed during path establishment (e.g., the recording of link group or SRLG information during path establishment) may differ.
要約すると、リンクバンドルLSAで十分な情報をキャプチャして、さまざまなパス計算手順に対応し、パス確立の成功の可能性を最大化することが不可欠です。使用するパス計算手順に応じて、パス確立中に必要なサポートのタイプ（たとえば、パス確立中のリンクグループまたは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-Disjointプライマリパスに対応するバックアップパスに同じリンクを割り当てることができます。ここでの仮定は、主要なパスが同じSRLGを持つリンク上にルーティングされていないため、特定の障害はそれらの1つだけに影響するということです。さらに、複数のSRLGに属するリンクに影響を与える複数の障害イベントは、同時に発生しないと想定されています。1 1保護の場合とは異なり、バックアップパスはAprioriを確立していません。むしろ、障害イベントは、影響を受ける一次パスに対応する単一のバックアップパスの確立を引き起こします。
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]でさらに説明されています。
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ベースのシグナル伝達プロトコルの適応は、光ネットワークの多くの独特な属性を考慮する必要があります。
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の入力ポートJに接続されている出力ポートIを選択できます。「次の」OXCはAです。これにより、「衝突」が発生します。同様に、WDM機能がOXCSに組み込まれている場合、隣接するOXCが直接接続された出力ポートを選択し、2つの異なる光パスで同じ波長を選択すると衝突が発生します。このような衝突に対処するには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.
一時的な部分障害の影響は、光ネットワークで最小化する必要があります。具体的には、障害によって直接影響を受ける光パスは、障害のために取り壊されてはなりません。たとえば、OXCの制御プロセッサが故障し、シグナル伝達やその他の節間制御通信に影響を与える可能性があります。同様に、OXC間の制御チャネルは、障害によって一時的に影響を受ける可能性があります。これらの障害は、OXCファブリックを通るすでに確立された光パスに影響を与えない可能性があります。たとえば、隣接するノードによるそのような障害の検出は、たとえば、シグナリングピアの間のキープライブメカニズムを介して、これらの光学パスが取り壊されることになってはなりません。
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の地方状態を回復することが望ましい。
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つの異なるフェーズがあります。保護パスの能力が確立される予約段階があります。次に、バックアップパスが実際に使用されるアクティベーションフェーズがあります。以前のフェーズは通常、時間の制約の対象ではありませんが、後者は厳密な時間制約の対象ではありません。
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.
「1 1」のバックアップパスを確立するためのシグナリングは、比較的簡単です。このシグナル伝達は、一次パスの確立に使用されるシグナル伝達に非常に似ています。共有バックアップパスを確立するためのシグナリングは少し異なります。ここでは、各OXCは、どのバックアップパスがリソースを共有できるかを理解する必要があります。信号メッセージ自体は、共有予約を示している必要があります。共有ルールは、セクション6.4に記載されているとおりです。物理的に多様なプライマリパスに対応するバックアップパスは、同じネットワークリソースを共有する場合があります。したがって、Signalingメッセージが、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つの部分があります。故障情報の故障情報の伝播と、バックアップパスの活性化です。これら2つのフェーズのシグナル伝達は、数十ミリ秒の順に応答時間を実現するために非常に高速でなければなりません。光リンクがSONETベースの場合、帯域内の信号を使用して、迅速な応答をもたらします。バンド外の制御を使用すると、非常に短いIPパケットと優先処理を使用して、制御チャネル上の高速な信号を検討する必要がある場合があります。保護パスをアクティブにするためにRSVPまたはCR-LDPを使用することは可能ですが、これらのプロトコルは、プロビジョニングのシグナル伝達とは対照的に、修復信号を優先する手段を提供しません。たとえば、復元関連のRSVPメッセージを多数のプロビジョニングメッセージの背後にキューに留めて、復元を遅らせる可能性があります。したがって、回復シグナル伝達の優先順位付けの概念を開発し、これを達成するために既存のシグナル伝達プロトコルに適切なメカニズムを組み込む必要があるかもしれません。あるいは、復元中に保護経路を活性化するためだけに新しいシグナル伝達メカニズムを開発することができます。
Within an optical internetwork, it must be possible to dynamically provision and restore lightpaths across optical networks. Therefore:
光学インターネットワーク内では、光ネットワーク全体でLightPathを動的にプロビジョニングおよび復元できる必要があります。したがって：
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のプロビジョニングには、標準のシグナル伝達プロトコルが必要です。
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全体で提供される機能は次のとおりです。
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で説明されているように、近隣発見手順はこれに使用できます。実際、単一のプロトコルは、ネットワーク内およびネットワーク全体の近隣発見のために標準化する必要があります。
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.
セクション6.1で説明したアドレス指定メカニズムは、各ネットワークのOXC、ポート、チャネル、およびサブチャネルを識別するために使用できます。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のようなプロトコルの使用を調査する必要があります。
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全体の復元に似ています。セクション6.4で説明されているように、ネットワーク全体のエンドツーエンドの復元は、各ネットワーク内の1つのタイプのいずれか、または各ネットワーク内のセグメント化されている可能性があります。
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サブチャネルなど）を使用することに幾分似ています。より一般的には、これはラベルスタッキングと、マルチプロトコルラムダスイッチングのコンテキスト内でのLSPネストに似ています[1]。GMPLSシグナリング[4]は、このタイプの多重化をサポートしています。
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.
一部のスイッチング要素には、何らかの形の波長変換が存在する場合があります。ただし、一部の純粋な光スイッチング要素には当てはまらない場合があります。スイッチング要素は、基本的に単純なリピーターよりも洗練されたものであり、出力ポートの入力ポートから波長ラムダ（L）に波長ラムダ（k）を切り替えて変換することができます。このディスプレイでは、必ずしもラムダ（k）= lambda（l）であるとは限りません。また、ラムダ（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.
すべてのスイッチング要素に波長コンバーターを持つ必要はありません。多くの研究が、光ネットワークでの波長変換の価値の問題に対処しようとしました。このような研究は通常、ブロッキング確率（必要な波長が利用できないためにライトパスを確立できない確率）を使用して、波長変換の有効性を裁定するメトリックとして使用します。光学アーキテクチャを介したIPは、波長変換が可能な一部のOXCを備えたハイブリッドネットワークを考慮し、他のIPはこれに能力がないものを考慮する必要があります。GMPLS「ラベルセット」メカニズム[4]は、NNI全体で同じラベル（つまり、波長）の選択をサポートしています。
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 elements, even though non-IP paths may exist between the peering routers.
特定の種類のピアリング関係が光層で発生する可能性のあるネットワーク間相互接続モデルが提案されています。これは、高層のペイロードとは無関係に光層サービスをサポートする必要性と一致しています。光ネットワークを介したIPのコンテキストでは、ピアリングルーターの間に非IPパスが存在する可能性がある場合でも、IPルーティング要素では、異なる信頼ドメイン間のピアリング関係が最終的に発生する必要があります。
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での動的なデータ駆動型のショートカットパスセットアップの使用を示唆する多くの提案があります。そのような提案に基づいている議論は、IPネットワークの中核におけるATMの展開に関する同様の議論をまったく連想させます。コアネットワーク内の高度に動的なデータ駆動型ショートカットの展開は、いくつかの理由でキャリアやISPによって広く採用されていません。サービスの。このドキュメントは、このパラダイムが変わらず、非常に動的でデータ駆動型のショートカットのライトパスのセットアップが将来の調査のためのものであることを前提としています。代わりに、光ネットワークを介したIPの進化の初期フェーズで広く使用されると予想される光チャネルトレイルとライトパスには、以下が含まれます。
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 リングやその他の物理層トポロジに対する任意の仮想トポロジの確立と再配置。
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 明示的な需要に基づくQoSの理由または負荷分散のために、ネットワークのパフォーマンスを向上させるために、LightPath接続を設計するための安定した交通工学制御システムを使用します。
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つは、帯域幅の制限が集合されるか、同時に処理できるフローの数（ライトパスなど）の制限のために、イングレスまたは出力ネットワーク要素によって処理できるフローの数に関連しています。
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 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を設定することによってのみインスタンス化します。
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 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.
集中化は、複雑な容量最適化スキームの実装に役立ち、相互接続されたマルチベンダー光ネットワークを備えた光ネットワークの短期的なプロビジョニングソリューションである可能性があります。ただし、長期的には、いくつかの制御手順（たとえば、トラフィックエンジニアリング）の集中化を伴う分散ソリューションが、そのアプローチに続く可能性があります。
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 parameterize the characteristics of these components and advertise them within the control plane. This aspect is left for further study.
これまでのところ、このメモは主に、クロスコネクトが光ネットワークの基本的に動的に再構成可能なデバイスである光ネットワーク上のIPに焦点を当ててきました。最近、テクノロジーの進化の結果として、調整可能なレーザー、調整可能なフィルターなど、さまざまなタイプの再構成可能な光学コンポーネントが利用可能になりました。特定の状況では、これらのコンポーネントの特性をパラメーター化して宣伝する必要がある場合があります。コントロールプレーン。この側面はさらなる研究のために残されています。
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つのノード間のパスの実現可能性は、単にトポロジとリソースの可用性の関数ではなく、パスに沿った障害の蓄積にも依存します。障害の蓄積が過剰な場合、光信号対騒音比（OSNR）、したがって宛先ノードの電気ビットエラー率（BER）は規定のしきい値を超えているため、結果の光学チャネルはデータ通信に使用できなくなります。光ネットワーク用のIPベースの制御プレーンの開発における課題は、光学層[17]のこれらの特異な特性を一般的な方法で抽象化し、パス計算に使用できるようにすることです。
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の進化パスに関する疑問が生じます。
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つのドメイン間の到達可能性情報交換の導入です。これにより、エンドツーエンドのLSPセットアップの一部としてLightPathを確立できる可能性があります。最終段階は、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.
ルーティングの観点から、静的接続管理にネットワーク管理システム（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ソフトウェアをアップグレードして、ある程度の自動化を導入するために各光学サブネットワーク。このため、ネットワークをサブネットワークに分割し、各サブネットワーク内にIGPの相互運用性を導入し（つまり、I-NNIレベル）、サブネットワーク間で静的またはシグナル付きの相互運用性のいずれかを使用することが望ましい場合があります。したがって、光学ネットワーク上のIPのネットワークレベル制御プレーンの相互運用性に向けた進化の最初のフェーズは、静的に（またはシグナル構成で動的に）相互接続された光学サブネットワークのシステムを中心に編成されることを想定できます。このフェーズでは、オーバーレイ相互接続モデルが光ネットワーク自体と外部IPおよびMPLSルーターの間で使用されます（セクション5.2.3で説明されています）。
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ルーティングの相互作用性の進化に対するこの段階的なアプローチを進めると、単一のキャリアがサブネットワーク間とドメイン間の動的光学ルーティングの相互運用性を提供する場合、次のレベルの統合が達成されます。サブネットワーク内およびドメイン全体のネットワークスイッチング機能から完全に独立するためには、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.
もう1つの選択肢は、プライベートネットワークがこれらの中間ステップをバイパスし、開始から統合されたルーティングモデルを直接検討することです。この直接的な進化戦略は現実的ですが、単一のソースまたは密接に関連している複数のソースから機器を使用して、IP（またはMPL）の両方が同時に構築される運用コンテキストで発生する可能性が高くなります。いずれにせよ、不均一なネットワークでのこの程度のコントロールプレーンの相互作用を管理する際の運用経験が現在欠けているため（ハードウェアとソフトウェアが同じベンダーから発生した場合でも、これらの問題が存在する可能性があります）、拡張モデルは最も実行可能な初期オプション。あるいは、非常にモジュール式または階層的なピアモデルを検討することもできます。マルチテクノロジーおよびマルチベンダー環境でルーティングレベルで完全なピアモデルを達成するために解決する必要があるかもしれない他の課題（技術だけでなく、管理上および政治的問題さえ）があるかもしれません。最終的に、主な技術的改善は、動的なドメイン間ルーティング環境におけるトラフィックエンジニアリング機能の統合から導き出された効率から生じる可能性があります。
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 コントロールインターフェイス全体で情報（シグナリング、ルーティング、またはリンク管理など）を交換するエンティティの認証。
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クライアントノードには見えない可能性があるという事実に関するものです。これは、Tracerouteなどの従来の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では、信頼ドメインの概念は、ドメインの外部からの不正な侵入を防ぐために適切なセキュリティ対策が確立される単一の技術管理の下でネットワークとして定義されました。信頼ドメイン内では、破壊されたノードは、ネットワーク全体を侵害できるコントロールメッセージを送信できることに強く注意する必要があります。
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 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.
通信プロトコルには、通常、認証と機密性という2つの主要なセキュリティメカニズムが必要です。認証メカニズムにより、データの起源の検証とメッセージの整合性が保証され、侵入と不正な操作を検出および軽減できるようになります。たとえば、図1を参照すると、メッセージ認証は、悪意のあるIPクライアントが、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.
クライアントネットワークからの光接続の要求も、セキュリティ侵害と過剰なリソース消費から保護するために、適切なポリシーを使用してフィルタリングする必要があります。さらに、状況によっては、SRLGの機密性が必要になる場合があります。
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.
微妙なサービス拒否攻撃の別の関連形式は、ありそうもない光学パスが要求されたときに発生する可能性があります（つまり、リソースが不十分にプロビジョニングされているネットワーク内のパス）。このようなありそうもないパスのリクエストは、ネットワーク内の光スイッチング要素のポートを消費する可能性があり、その後の接続要求のサービス拒否をもたらします。
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ドメイン内のサービス中断の大きさと範囲を考慮に入れる必要があると述べなければなりません。光学ドメイン。
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最適な制御相互接続、サービスモデル、およびプロトコルメカニズムには多様な選択があります。このドキュメントで提唱されているアプローチは、将来の強化を可能にするさまざまなサービスモデルをサポートし、これらの機能を有効にするために補完的なシグナル伝達とルーティングメカニズムを定義することでした。一般的なシグナル伝達フレームワーク（たとえば、GMPLに基づく）に基づく進化シナリオが提案され、要件がより洗練されるにつれて、インターワーキング機能の複雑さを高める能力があります。この進化の原則の重要な側面は、IP光学的制御とサービスの相互作用が、最終的に完全なピアインタラクションをサポートするために進化するオーバーレイ相互接続を備えたドメインサービスモデルに基づいていることです。
[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トラフィックエンジニアリングコントロールと光クロスコネクトを組み合わせる」、IEEE Communications Magazine、2001年3月。
[2] Lang, J., et al., "Link Management Protocol", Work in progress.
[2] Lang、J.、et al。、「Link Management Protocol」、作業進行中。
[3] Kompella, K. and Y. Rekhter, "LSP Hierarchy with MPLS TE", Internet Draft, Work in progress.
[3] Kompella、K。およびY. Rekhter、「MPLS TEとのLSP階層」、インターネットドラフト、進行中の作業。
[4] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[4] Berger、L.、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナル伝達機能説明」、RFC 3471、2003年1月。
[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。、「ラベル分布プロトコル（LDP）、リソース再測定プロトコル（RSVP）、および光学UNIシグナル伝達のためのリソース再節約プロトコルトラフィックエンジニアリング（RSVP-TE）拡張のためのIANA割り当てのドキュメント」、2003年3月RFC 3476
[6] The Optical Interworking Forum, "UNI 1.0 Signaling Specification", December 2001.
[6] 2001年12月、光学インターワーキングフォーラム「UNI 1.0信号仕様」。
[7] Kompella, K., et al., "OSPF Extensions in Support of Generalized MPLS," Work in Progress.
[7] Kompella、K.、et al。、「一般化されたMPLSをサポートするOSPF拡張」、Work in Progress。
[8] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP4)", RFC 1771, March 1995.
[8] Rekhter、Y。およびT. Li、「A Border Gateway Protocol 4（BGP4）」、RFC 1771、1995年3月。
[9] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReSeVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[9] Berger、L.、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナリングリソースの再測定プロトコルトラフィックエンジニアリング（RSVP-TE）拡張」、RFC 3473、2003年1月。
[10] Mannie, E., "GMPLS Extensions for SONET/SDH Control", Work in Progress.
[10] Mannie、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.
[11] Doshi、B.、Dravida、S.、Harshavardhana、P.、et。AL、「光ネットワークの設計と修復」、Bell Labs Technical Journal、1999年1月から3月。
[12] Kompella, K., et al., "Link Bundling in MPLS Traffic Engineering", Work in Progress.
[12] Kompella、K.、et al。、「MPLS Traffic Engineeringのリンクバンドリング」、進行中の作業。
[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.、et al。、「光ネットワークにおける動的プロビジョニングの容量性能」、Journal of Lightwave Technology、2001年1月。
[14] Crawley, E., Nair, R., Rajagopalan, B. and H. Sandick, "A Framework for QoS-based Routing in the Internet", RFC 2386, August 1998.
[14] Crawley、E.、Nair、R.、Rajagopalan、B。、およびH. Sandick、「インターネットでのQoSベースのルーティングのフレームワーク」、RFC 2386、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.、Berger、L.、Gan、D.、Li、T.、Swallow、G。and V. Srinivasan、「RSVP-TE：LSPトンネルのRSVPへの拡張」、RFC 3209、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] Chiu、A.、et al。、「光層ルーティングの障害およびその他の制約」、進行中の作業。
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）、Ian Duncan（Nortel Networks）、Dimitri Papadimitriou（Alcatel）、およびDimitrios Pendarakis（Tellium）にこの文書に貢献してくれたことに感謝します。セキュリティ上の考慮事項セクションは、スコット・ブラッドナーとスティーブ・ベロヴィンからの意見を反映するために改訂されました。
Contributors are listed alphabetically.
貢献者はアルファベット順にリストされています。
Brad Cain Cereva Networks 3 Network Dr. Marlborough, MA 01752
Brad Cain Cereva Networks 3ネットワークDr. Marlborough、MA 01752
EMail: bcain@cereva.com
Bilel Jamoussi Nortel Networks 600 Tech Park Billerica, MA 01821
Bilel Jamoussi Nortel Networks 600 Tech Park Billerica、MA 01821
Phone: 978-288-4734 EMail: jamoussi@nortelnetworks.com
電話：978-288-4734メール：jamoussi@nortelnetworks.com
Debanjan Saha
デバンジャン・サハ
EMail: debanjan@acm.org
Bala Rajagopalan Tellium, Inc. 2 Crescent Place P.O. Box 901 Oceanport, NJ 07757-0901
Bala Rajagopalan Tellium、Inc。2 Crescent Place P.O.Box 901 Oceanport、NJ 07757-0901
EMail: braja@tellium.com
James V. Luciani Marconi Communications 2000 Marconi Dr. Warrendale, PA 15086
ジェームズV.ルシアーニマルコーニコミュニケーション2000マルコーニ博士ウォレンデール、ペンシルベニア州15086
EMail: james_luciani@mindspring.com
Daniel O. Awduche MCI 22001 Loudoun County Parkway Ashburn, VA 20147
ダニエルO.アウドゥッシュMCI 22001ラウドン郡パークウェイアシュバーン、バージニア州20147
Phone: 703-886-1753 EMail: awduche@awduche.com
電話：703-886-1753メール：awduche@awduche.com
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.
著作権（c）The Internet Society（2004）。この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となりますが、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。