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
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）インターネット協会（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).
光ネットワーク技術は、機能や能力の面で急速に進化しています。光ネットワークの重要性の高まりは、すべての主要なネットワークサービスプロバイダー、通信機器ベンダー、および標準化団体によって光ネットワークおよび関連フォトニック・電子インターワーキングの問題を介してIPに着目し、大量のによって証明されます。この点で、用語「光ネットワーク」は、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ベースのプロトコルを採用し、適応するために理解する必要があります。これは、特に回復のためのケースであり、全光ネットワークにおけるルーティングおよびシグナリングのため。また、このような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つの基本的な問題があります。最初にかかわらず、光ネットワークを利用するデジタルクライアントのタイプの、光ネットワーク制御プレーン内のIP制御プレーンプロトコルの適応および再利用です。第二は、一緒になって、そこから生じる制御と調整の問題に光ネットワークを介して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-光学インターワーキングのためのアーキテクチャモデルを考慮する。他のものよりも任意の特定のモデルを促進するために、このドキュメントの意図ではないことに留意すべきです。しかし、特定の状況では一つのアプローチより適切な別のより行うことができるモデルの特定の態様が記載されています。セクション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、デジタルクライアントペイロードを運ぶことができます等。）。例えば、単一の光ファイバ上にOC-48C（約2.5 Gbps）のとOC-192（約10ギガビット）で動作するSONET信号の混在をサポートする今日存在で多くの商業的WDMネットワークがあります。 WDM機能を有する光学系が正常に高いシステム性能と信頼性を維持しながら、複数の波長の並列伝送を実現することができます。近い将来、商業高密度WDMシステムは、同時に1.6 Tbpsの以上の合計、OC-192Cと、上記のデータレートで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つのアクセスポイント間のポイントツーポイント光層接続です。この文書では、用語「光路」は、光チャネル証跡と交換可能に使用されます。
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.
光パスは、それが同じ波長のエンドツーエンドの上で輸送される場合、波長連続性を満たすと言われています。波長の連続性がない、波長変換機能を有する光ネットワークで必要とされます。
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).
注トランジットノードでの信号の増幅（例えば、<<のEDFAが、エルビウムドープファイバ増幅器を使用して）透明な光ネットワークで許可されています。
On the other hand, in opaque optical networks, transit nodes may manipulate optical signals traversing through them. An example of such manipulation would be OEO conversion which may involve 3R operations (reshaping, retiming, regeneration, and perhaps amplification).
一方、不透明な光ネットワークでは、トランジットノードは、それらを介して通過する光信号を操作することができます。そのような操作の例は、3R操作（整形、リタイミング、再生、及び恐らく増幅）を含んでもよいOEO変換あろう。
Trust domain
信頼ドメイン
A trust domain is a network under a single technical administration in which adequate security measures are established to prevent unauthorized intrusion from outside the domain. Hence, it may be assumed that most nodes in the domain are deemed to be secure or trusted in some fashion. Generally, the rule for "single" administrative control over a trust domain may be relaxed in practice if a set of administrative entities agree to trust one another to form an enlarged heterogeneous trust domain. However, to simplify the discussions in this document, it will be assumed, without loss of generality, that the term trust domain applies to a single administrative entity with appropriate security policies. It should be noted that within a trust domain, any subverted node can send control messages which can compromise the entire network.
信頼ドメインは、十分なセキュリティ対策がドメイン外部からの不正侵入を防ぐために設立されている、単一の技術管理下のネットワークです。したがって、ドメイン内のほとんどのノードがセキュアまたは何らかの形で信頼されるとみなされると仮定することができます。管理エンティティのセットが拡大し、異種信頼ドメインを形成するために、お互いを信頼することに同意する場合、一般的に、信頼ドメインの上に「シングル」の管理制御のためのルールが実際に緩和することができます。しかし、この文書の議論を簡単にするために、長期的な信頼ドメインは、適切なセキュリティポリシーを単一の管理エンティティに適用されることを、一般性を失うことなく、仮定されます。信頼ドメイン内、いずれかの堕落ノードがネットワーク全体を危険にさらすことができ、制御メッセージを送信できることに留意すべきです。
Flow
フロー
In this document, the term flow will be used to signify the smallest non-separable stream of data, from the point of view of an endpoint or termination point (source or destination node). The reader should note that the term flow is heavily overloaded in contemporary networking literature. In this document, we will consider a wavelength to be a flow, under certain circumstances. However, if there is a method to partition the bandwidth of the wavelength, then each partition may be considered a flow, for example using time division multiplexing (TDM), it may be feasible to consider each quanta of time within a given wavelength as a flow.
この文書では、用語の流れは、エンドポイントまたは終了点（ソースまたは宛先ノード）の観点から、データの最小非分離ストリームを意味するために使用されます。読者は、用語の流れが大きく、現代のネットワーキング文献に過負荷になっていることに注意してください。この文書では、我々は、特定の状況下で、流れする波長を検討します。波長の帯域幅を分割する方法がある場合、各パーティションは時分割多重（TDM）を使用して、例えば、流れと考えることができるが、のように与えられた波長範囲内の時間の各量子を検討することが可能であってもよいですフロー。
Traffic Trunk
交通トランク
A traffic trunk is an abstraction of traffic flow traversing the same path between two access points which allows some characteristics and attributes of the traffic to be parameterized.
トラフィックトランクは、トラフィックのいくつかの特徴及び属性がパラメータ化されることを可能にする2つのアクセスポイント間で同じ経路を通過するトラフィックフローの抽象化です。
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又はのOXCを構成することができます。サブネットワーク間の相互接続が必要な場合に適した光 - 電気変換を用いて、互換性のある物理インターフェイスを介して実装されているものとします。光ネットワークとの直接の物理的接続を持つルータは光ネットワークに関して「エッジルータ」と呼ばれます。図1に示すように、他のクライアントのネットワーク（例えば、ATM）は、光ネットワークに接続することができます。
The switching function in an OXC is controlled by appropriately configuring the cross-connect fabric. Conceptually, this may be viewed as setting up a cross-connect table whose entries are of the form <input port i, output port j>, indicating that the data stream entering input port i will be switched to output port j. In the context of a wavelength selective cross-connect (generally referred to as a WXC), the cross-connect tables may also indicate the input and output wavelengths along with the input and output ports. A lightpath from an ingress port in an OXC to an egress port in a remote OXC is established by setting up suitable cross-connects in the ingress, the egress and a set of intermediate OXCs such that a continuous physical path exists from the ingress to the egress port. Optical paths tend to be bi-directional, i.e., the return path from the egress port to the ingress port is typically routed along the same set of intermediate interface cards as the forward path, but this may not be the case under all circumstances.
OXCのスイッチング機能を適切に相互接続ファブリックを構成することにより制御されます。概念的に、これは、データストリームiが、出力ポートjに切り替えられる入力ポートに入ることを示し、そのエントリフォーム<入力ポートI、出力ポートj>であるクロスコネクトテーブルを設定すると見なすことができます。 （一般WXCと称する）は、クロスコネクト選択波長の文脈では、クロスコネクトテーブルは、入力ポートと出力ポートと共に入出力波長をも示すことができます。リモートOXCにおける出力ポートにOXCに入力ポートからの光パスは、連続物理パスはへ侵入から存在するように入力、出力および中間の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がラムダ（L）に出力ポートkに切り替えられ、入力ポートを介して波長ラムダ（J）上で受信されたことを示しています。光パスの自動確立は、所望の物理パスが実現されるように協調して適切なのOXCにおけるクロスコネクトテーブル・エントリを設定することを含みます。
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ルータのペア間で確立されなければなりません。 IPルータとの間の光パスは、複数の光ネットワークを横断し、各ネットワークにおける異なるプロビジョニングおよび復旧手順の対象とすることができます。
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エンドポイントからの転送パスを構築することを含みます。
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.
したがって、クライアント光学インターネットワークインタフェースを横切る制御フローは、それを横切って定義されたサービスのセットとサービスがアクセスされる方法に依存しています。サービスモデルは、NNIには、ノード間の制御フローのためのベンダーに依存しない標準化されたインターフェイスを表し項4に記載されています。 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上、特にルーティング関連情報を、制御情報の流れを最小化するために必要とされ得ます。そして、さえENNIを超えます。この場合、UNI、NNIはいくつかの点で異なる場合があります。この文書では、これらのインタフェースは、別個のものとして扱われます。
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.直接インターフェイス：インバンドまたはアウトオブバンドエッジルータ及び各OXCの間に実施することができるIP制御チャネル（IPCC）は、それが接続されています。この制御チャネルは、シグナリングを交換し、ルータとOXC間でメッセージをルーティングするために使用されます。制御平面に対するピアは直接インターフェースと、エッジルータとOXCは、それが接続されています。この状況は、図2のルーティングのタイプを示し、シグナリング情報は、サービス定義に応じて変えることができるダイレクトインタフェースを介して交換しました。この問題は、次のセクションで扱われています。ルーティングプロトコルのためのいくつかの選択肢は、OSPFまたはIS-IS（トラフィックエンジニアリングの拡張及び光ネットワークの固有の特性に対応する追加の拡張を伴う）、または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の間には直接的な制御の相互作用はありません。間接的なインタフェースを持っている一つの理由は、のOXCおよび/またはクライアントが直接シグナリング・インタフェースをサポートしていないということでしょう。
+---------------------------+ +---------------------------+
| | | |
| +---------+ +---------+ | | +---------+ +---------+ |
| | | | | | | | | | | |
| | 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とNNIにのサービスモデルと要件が考慮されます。二つの一般的なモデルは（ものNNIで適用することができます）UNIでのサービスのために浮上しています。次のようにこれらのモデルがあります。
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:
ドメインサービスモデルでは、光ネットワークは、主に光パスの形で高帯域幅の接続性を提供しています。 UNI横切って標準化されたシグナル（図1）は、以下のサービスを呼び出すために使用されます。
1. Lightpath creation: This service allows a lightpath with the specified attributes to be created between a pair of termination points in the optical network. Lightpath creation may be subject to network-defined policies (e.g., connectivity restrictions) and security procedures.
1.光パスの作成：このサービスは、指定された属性を持つ光パスは、光ネットワーク内の終端点の対の間に作成されることを可能にします。光パスの作成は、被験体へのネットワーク定義のポリシー（例えば、接続性制約）とセキュリティ手順であってもよいです。
2. Lightpath deletion: This service allows an existing lightpath to be deleted.
2.光パスの削除：このサービスは、既存の光パスを削除することができます。
3. Lightpath modification: This service allows certain parameters of the lightpath to be modified.
3.光パス変更：このサービスは、光パスの特定のパラメータを変更することを可能にします。
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.光パスのステータスの照会：このサービスは、（そのIDによって参照）光パスの特定のパラメータのステータスが光パスを作成したルータによって照会することができます。
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、NNIは、ビューのルーティングおよびシグナリングポイントから他のルーターインターフェースとの間に区別はありません。 [1]に記載されているように、この制御プレーンは、MPLS又はGMPLSのトラフィックエンジニアリングの拡張を活用例えば、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.
統一されたサービスモデルの下とGMPLSネットワークのコンテキスト内で、光ネットワークサービスは、エンドツーエンドGMPLSシグナリング中に暗黙的に得られます。具体的には、エッジルータは、指定された属性を持つ光パスを作成し、またはそれはGMPLSラベルスイッチパス（LSPを）作成するように光パスを削除し、修正することができます。この点で、光ネットワークから得られるサービスは、ドメインサービスモデルと同様です。これらのサービスは、しかし、ドメインサービスモデルと比較して、よりシームレスに起動することができます。例えば、ルータは、単一の光ネットワークに接続されている場合（すなわち、何エニス存在しない）、リモートルータは、光インターネットを横切るエンドツーエンドパスを計算することができました。これは、光インターネットワーク全体でLSPを確立することができます。しかし、エッジルータは、依然として光学インターネットワークLSPは、光パス、または複数のパケット・ベースの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]。光パスは二つのエッジルータとの間の光インター横切って確立されると本質的には、光パスは、これらのルータ間の転送隣接（仮想リンク）としてアドバタイズすることができます。したがって、ビューのデータ・プレーン・ポイントから、光パスは、エッジルータ間の仮想オーバーレイをもたらします。そのような光パスを作成する必要がある場合のように決定し、これらの光パスの帯域幅管理は、ドメインサービスモデルと統一されたサービスモデルの両方で同じです。統一されたサービスのためのルーティングおよびシグナリングモデルはセクション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.
上記サービスモデルの相対的なメリットは、長さで議論することができるが、この枠組みの中で推奨されるアプローチは、両方のモデルをサポートするルーティングおよびシグナリングメカニズムを定義することです。上述したように、サービス要求のためのシグナリングの両方のモデルをカバーするために統一することができます。統一されたサービスモデルとUNIのために採用シグナリングのためのシグナリングGMPLSの開発[4] [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ルータ間のデータプレーンのリンクは、光ファイバ・ネットワーク上のオーバーレイである仮想トポロジーになることを考えると、それは光パスの仮想プライベートネットワークを想定することは容易であること、相互接続ルータ（またはクライアントのいずれかの他のセット）単一のエンティティまたは公衆の光ネットワークを介して関連するエンティティのグループに属します。実際、光ネットワークは、外部クライアント・ネットワークの複数のセットの接続を提供する場合には、クライアントネットワークの異なるセット（すなわち、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制御プレーンの組織により実質的に定義されます。この枠組みの中で仮定[1] IPベースの制御プレーンは、例えばGMPLSとして、使用されることです。サービス・モデル（セクション4）に応じて、しかし、IPと光ネットワークにおける制御プレーンは、緩く又は密結合することができます。このカップリングは、以下の特性を決定します。
o The details of the topology and routing information advertised by the optical network across the client interface;
トポロジーとクライアント・インターフェースを介して光ネットワークによってアドバタイズされたルーティング情報の詳細は、O。
o The level of control that IP routers can exercise in selecting explicit paths for connections across the optical network;
O IPルータは、光ネットワークを介して接続するための明示的なパスを選択する際に行使することができるコントロールのレベル。
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と光学ドメインは、その後、同じエンティティに属する共通IGP OSPFなどまたはIS-IS、適切な拡張子を持つ場合、トポロジー情報を配信するために使用することができる[7]、統合IP上 - 光学ネットワーク。 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と光ネットワークは、適切な「光」の拡張子を持つIPルーティングプロトコル、例えば、OSPFの同一のインスタンスを実行すると仮定されます。これらの拡張機能は、光リンク・パラメータ、および光ネットワークに固有の制約をキャプチャする必要があります。すべてのノード（のOXCとルータ）によって維持トポロジーおよびリンク状態情報は必ずしも必要ではないが、同一であってもよいです。このアプローチは、光ネットワークを介して他のルータへのエンドツーエンドパスを計算するためにルータを可能にします。経路計算は、経路の必要性によってトリガされると仮定したラベルは、GMPLS環境においてパス（LSP）を切り替えます。そのようなLSPは、適切な拡張子を持つ例えば、RSVP-TEやCR-LDP、GMPLSシグナリングを用いて確立することができます。この場合、シグナリング・プロトコルは、2つのエッジルータ間の光パスを確立します。この光路は、本質的に光ネットワークを横断トンネルであり、第1のLSPをサポートするために必要な帯域幅よりもはるかに大きい容量を有していてもよいです。これにより、ルータ間の後続のLSPはむしろ新しい光パスをインスタンス化するよりもそれを使用できるように、ネットワーク内の他のルータは、光路内に過剰容量の可用性を実現することが不可欠です。光パスは、したがって、この問題に対処するための手段として、トポロジ内の仮想リンクとして広告することができます。
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.
記載された「転送隣接」（FA）の概念は、[3]他のルータに既存の光パス情報を伝播に必須です。 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に接続されているルータと仮定する。統合されたルーティングの下で、二つのポート上R1とO1との間の接続は、ネットワークのリンク状態表現に捕捉されたであろう。さて、フルポートの帯域幅でのFAは、ポートP1を介して別のルータR1からR2に作成されたとします。このFAは、R1とR2との間の仮想リンクとして宣伝されているが、そのポートがもはや光パスを作成するために利用可能であるので、リンク状態表現からリンク（P1上）R1-O1を除去しないことも必要です。 FAが作成されるとこのように、仮想リンクのオーバーレイセットは、以前IP-光インタフェースで宣伝リンクを交換し、リンク状態表現に導入されます。最後に、リンク状態の表現でキャプチャ光ネットワークの詳細は、Fasのネットワークによって置き換えられます。上記のスキームは、問題に取り組むための一つの方法です。別のアプローチは、接続の特定のタイプを確立するために使用することができないリンクが適切にタグ付けされるように、リンク状態情報を用いて適切な動的属性を関連付けることです。しかし、一般に、統合されたルーティングおよび（次に説明する）ドメイン固有のルーティングの間の類似性の多大があります。どちらも最終的には、特定のトラフィックエンジニアリング目標を達成するために（光ネットワーク上にオーバーレイされる）仮想光パスのトポロジの作成を扱います。
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アドレスの知識を持っているので、明示的に光パスのための出口の光ポートを指定せずに、その宛先への直接光パスを要求することができます。同じエッジルータは異なる外部の宛先に別のLSPを確立することであった場合は、その後、効率上の理由から、それが最初のターゲット宛先に（十分な残容量を持つ）既存の光パスが存在するかどうかを決定する必要があるかもしれません。エッジルータは、外部の宛先への光インターリードにおける出口ポートを追跡するために、この目的のために、それが必要であってもよいです。したがって、EBGPを介してエッジルータから外部のIPプレフィックスを受信する境界OXCは、他の境界のOXC又はエッジルータにこれらのプレフィックスを伝播する前に出口ポイントとして自身のIPアドレスを含まなければなりません。この情報を受信するエッジルータは、さらに出口アドレスを伝播する必要はありませんが、それは外部のIPアドレスと、出口OXCアドレス間の関連付けを維持する必要があります。光のVPNが実装されている場合、境界のOXCによって通知アドレスプレフィックスは、いくつかの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のために使用されるアドレス解決メカニズムと概念的に類似しています。このアプローチでは、光ネットワークは、エッジルータは、IPアドレスとVPN識別子を登録することができますレジストリを実装することができます。エッジルータは、それが属するVPNの同じセットに属する外部アドレスを照会できるようにしてもよいです。成功したクエリは、外部の宛先に到達することができ、それを通して出力光ポートのアドレスを返します。
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-光インタフェース接続が制限されているため、確立されなければならないどのように多くの光パスの端点は、トラフィックエンジニアリングの意思決定が何であるかを決意。このような光パスの初期セットが確立された後さらに、これらは、VPN全体のルーティング方式、例えば、OSPF用のVPN内の隣接として使用することができます。このアプローチでは、エッジルータは、最初のレジストリに問い合わせることによって関心のある他のエッジルータを決定することができます。それが適切なアドレスを取得した後、最初のオーバーレイ・光パスのトポロジを形成することができます。ルーティング隣接関係は、その後、光パスを横切って確立することができ、さらにルーティング情報が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チャネルをモデル化することが可能です。この概念は、これを実現するためのメカニズムは、[4]に記載されている[1]で提案されている、および「一般」MPLS（GMPLS）しました。このようRSVP-TEなどのトラフィックエンジニアリングの拡張、とのシグナリングプロトコルMPLSは、適切に拡張され、光パスのシグナリング要求のために使用することができます。これらのプロトコルは、クライアント/サーバがドメインサービスモデルの場合には、シグナリングのために適合され、統一されたサービスモデルの場合、エンド・ツー・エンドの統合されたシグナリングのためにすることができます。
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.
統一サービスモデルとGMPLSシグナリングは適切増強RSVPを使用して、IPと光学ドメインにおいて実現されることが理解され、アドレス指定は、IPネットワークで一般的であり、図4に示すように、光インター各シグナリング制御が、関連しています-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に示すようにこのように、統一サービスの場合におけるシグナリングは、実際には多層です。レイヤーは、テクノロジーと機能性に基づいています。一例として、GMPLSの特定の適応は、（その機能性輸送である）[10]に記載されているSONET層のシグナリング。
Suppose an LSP is established from an ingress IP router to an egress router across an ingress IP network, a transit optical internetwork and an egress IP network. If this LSP is to be afforded protection in the IP layer, how is the service coordinated between the IP and optical layers?
LSPは、入口IPネットワークを介して出口ルータ、中継光学インターネットおよび出口IPネットワークへの入口IPルータから確立されると仮定する。このLSPは、IP層に保護を与えしようとする場合、どのようにサービスがIPと光学層との間で調整されますか？
Under this scenario, there are two approaches to end-to-end protection:
このシナリオでは、エンドツーエンドの保護の2つのアプローチがあります。
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セグメントの光学層保護サービスを利用することができます。入口IPネットワークにおけるセグメント、光学インターネットワークにおけるセグメントおよび出口IPネットワーク内のセグメント：したがって、エンドツーエンドのLSPは、ビューの保護の点からの3つのLSPセグメントの連結として扱われることになります。エンドツーエンドのLSPのためのIPレイヤで保護サービスは、光学インターネットワークによって提供される適切な保護サービスにマッピングされなければなりません。 1つのコンフィギュレーション：1つの+ 1保護、すなわちIP層でのLSPに提供されていると、それぞれの保護されたLSPは、1 + 1または1で事前に確立されたホットスタンバイを有しています。一次LSPの故障の場合に、トラフィックは、直ちにスタンバイに切り替えることができます。次のようにこのタイプの保護は、エンドツーエンドを実現することができます。図5を参照すると、LSPは、（入口）ルータインターフェイスAで発生と、LSPのための主要な経路は、最初に確立されなければならない第1の保護オプションで（出口）ルータインターフェイスF.で終了しましょう。図5に示すように、この経路は、とする、入口ネットワーク内のルータインターフェイスBを横断する、光ポートC（入力）及びD（出力）、および出力ネットワークのルータインターフェイスE。次に、1 + 1保護が点AとB、CとDとEとFのさらに間の予備パスを確立することによって、各ネットワークに別々に実現され、セグメントBCおよびDE自体がドロップサイドを使用して、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を参照して、2 SRLGディスジョイントLSPは、光学インターネットワークに対応するセグメントが光インターにおいて独立光パスとして扱われるA及びFの間に確立されています。これらの光パスは、光学インターネットワークで保護されていないかもしれません。
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番目の選択肢の下で、光学インターネットワークで提供される任意の保護サービスは、クライアントのIPネットワークによって直接利用されていないのに対し、最初の選択の下では、光学インターネットワークは、エンドツーエンドの保護に積極的に関与しています。また、最初の選択肢の下で、光学インターネットワーク内の保護は、IP LSPの数に一括して適用される場合があります。すなわち、図5を参照して、であり、多くのLSPは、光インター保護は、その後一度スケーラビリティにおけるいくつかの利得をもたらすそれらの全てに適用されてもよいCとDの間の単一の光パスに集約することができます。 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ネットワーク間でプロトコルと光サブネットワーク内シグナリングのサポート、及びINNIとENNI横切っを必要とします。この点で、区別がサブネットワーク間で、およびネットワーク間で、光サブネットワーク（図1）内の制御手順の間に行われます。一般的なガイドラインは、この枠組みの中で続いてこれらのケースを分離し、および手順の共通セットをサブネットワークとネットワーク間続いている間に別の制御手順は、異なるサブネットワークの内部に従っているという可能性を可能にすることです。
The control plane procedures within a single vendor sub-network need not be defined since these can be proprietary. Clearly, it is possible to follow the same control procedures inside a sub-network and across sub-networks. But this is simply a recommendation within this framework document, rather than an imperative requirement. Thus, in the following, signaling and routing across sub-networks is considered first, followed by a discussion of similar issues across networks.
これらはプロプライエタリであることができるので、単一のベンダーのサブネットワーク内の制御プレーン手順を定義する必要はありません。明らかに、サブネットワークの内部とサブネットワークにわたって同じ制御手順を実行することが可能です。しかし、これは単に、このフレームワークドキュメント内の推奨ではなく、必要不可欠な要件です。したがって、以下では、シグナリングおよびサブネットワーク間ルーティングは、ネットワークを介し同様の問題についての議論に続いて、最初に考えられています。
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中心の制御プレーンを用いた光学サブネットワーク間の相互運用性のために、基本的な問題の一つは、アドレッシングのことです。ビューのシグナリングとルーティングポイントから識別できる何エンティティをすべきですか？彼らはどのように対処すべきか？このセクションでは、この問題に関するいくつかの高レベルのガイドラインを示します。
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、光リンク、光チャネルおよびサブチャネル、共有リスクリンクグループ（SRLGs）を含みます。光トレイルを確立するときに識別するためのスキームが適切粒度で光ネットワーク内の終端点の仕様に適合しなければなりません。例えば、OXCは、すべてのサブチャネルまたはチャネルの終端と仮定することは、おそらく合理的ではない多くのサブチャネルを含むそれぞれが順番に多くの光チャネルを終了することができ、それぞれが多数のポート、などを有している、あるいはOXCができポートは、固有のIPアドレスを割り当てることができます。また、ネットワーク内の光跡のルーティングは、正確な終了点の情報に依存せず、むしろ終端OXCに。したがって、終端点のより細かい粒度の識別は、終端OXCに関連性があるとしない中間のOXCに（もちろん、それぞれの中間点におけるリソース割り当てが要求されたリソースの粒度に依存するであろう）。これは、のOXCは、固有のIPアドレスと「セレクタ」によって識別される識別スキームを示唆しているOXCに関連性のさらなる微粒子情報を識別する。これは、当然のことながら、（ヌルセレクタと）直接IPアドレスを持つこれらの終端点の識別を排除するものではありません。セレクタは、適切なビットの数と、ポート、チャネル、サブチャネルを発現する構造など、識別を有するようにフォーマットすることができます。
Within the optical network, the establishment of trail segments between adjacent OXCs require the identification of specific port, channel, sub-channel, etc. With a GMPLS control plane, a label serves this function. The structure of the label must be such that it can encode the required information [10].
光ネットワーク内で、隣接の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つのリンクを個別に他の二つのSRLGsに属することができるということです。これは、ここでは、図6に示され、リンク1,2,3及び4は、1 SRLGに属していてもよい、1,2及び3は、2 SRLGに属することができ、リンク4は、同様に3をSRLGに属する可能性がリンク5及び6リンク1 SRLGに属し、7及び8は4のSRLGに属する可能性がリンク（この例では、同一のSRLGを、すなわち、図1に示すように、二つの異なる隣接からのリンクを含む）の可能性があります。
While the classification of physical resources into SRLGs is a manual operation, the assignment of unique identifiers to these SRLGs within an optical network is essential to ensure correct SRLG-disjoint path computation for protection. SRLGs could be identified with a flat identifier (e.g., 32 bit integer).
SRLGsへの物理リソースの分類は手動操作であるが、光ネットワーク内のこれらSRLGsに一意の識別子の割り当ては、保護のための正しいSRLGディスジョイント経路計算を確保することが不可欠です。 SRLGsは平坦識別子（例えば、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は、各光リンクのアップ/ダウン状態、帯域幅、リンクの他のパラメータ、およびリンク（例えば、リモートポート番号）のリモートエンドの身元を決定しなければなりません。情報の最後の部分は、光パスのプロビジョニングのためのシグナリング時に適切なラベルを指定するために使用されます。これらのパラメータの決意は、手動設定と隣接の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終端、近隣探索プロトコルの1つのインスタンスを持つ、不透明のOXCの場合（例えば、LMP [2]）は、隣接するOXCに対応するプロトコルインスタンスと通信する、各OXCポート上で実行されます。 SONETオーバヘッドを利用するであろうプロトコルは、ネイバーに定期的（構成）ローカル属性を送信するバイト。このように、隣接する二つのスイッチが自動的に互いにローカル接続のアイデンティティを決定することができ、また、ローカルリンクのアップ/ダウンステータスを追跡します。透明の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：SRLGsとメッシュ光ネットワーク
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、IS-IS）の一部として実行されてもよく、またはそれは、（集中型経路計算の場合）管理プレーンを経由して行うことができます。 （すなわち、サブネットワーク境界を越えて）ネットワーク内のリンク状態プロトコルの実装は、同じプロトコルは、すべてのサブネットワーク内の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]に含まれる光リンクのタイプを含むことができます。また、バンドル内の各光リンクに対応SRLGsパラメータとして含まれていてもよいです。
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.
光パスの自動復旧は、光ネットワークが提供するサービスです。ローカルおよび（INNI横切って）ネットワーク内の光パスの回復のためのエンドツーエンドのメカニズムが存在し得ます。局所的なメカニズムは、障害が（保護された）光パスがルーティングされた上、一次リンク（またはプライマリネットワークセグメント）に影響を与える場合INNI横切る2つのOXC間の代替リンク（又はネットワーク・セグメント）を選択するために使用されます。ローカル修復は、光パスのエンド・ツー・エンドのルートには影響を与えません。ローカル修復（例えば、何の代替リンクが問題の隣接のOXC間利用可能ではない）ことができない場合、エンド・ツー・エンドの復元を行ってもよいです。本このシナリオでは、影響を受けた光パスが失敗したリソースを回避するために、代替の多様な経路を介して再ルーティングされてもよいです。エンドツーエンドの復元のために、代替パスは、回復時間を促進するために事前に計算することができます。最後の復元に終わりはまた、ネットワークリソースおよび回復時間の利用との間に許容可能なトレードオフに応じて様々な方法で地元の回復と混合することができます。
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].
光ネットワーク内の光パスのための主要なルートの計算は、本質的に制約ベースのルーティングの問題です。制約は、おそらく管理とポリシー制約と一緒に、一般的に光パスのために必要な帯域幅です。経路計算の目的は、ルーティング光パス[13]に必要な総容量を最小化することができました。
Route computation with constraints may be accomplished using a number of algorithms [14]. When 1+1 protection is used, a back-up path that does not traverse on any link which is part of the same SRLG as links in the primary path must be computed. Thus, it is essential that the SRLGs in the primary path be known during alternate path computation, along with the availability of resources in links that belong to other SRLGs. This requirement has certain implications on optical link bundling. Specifically, a bundled LSA must include adequate information such that a remote OXC can determine the resource availability under each SRLG that the bundled link refers to, and the relationship between links belonging to different SRLGs in the bundle. For example, considering Figure 3, if links 1,2,3 and 4 are bundled together in an LSA, the bundled LSA must indicate that there are three SRLGs which are part of the bundle (i.e., 1, 2 and 3), and that links in SRLGs 2 and 3 are also part of SRLG 1.
制約のある経路計算は、アルゴリズムの番号[14]を用いて達成することができます。 1 + 1保護を使用する場合、プライマリパスのリンクと同じSRLGの一部である任意のリンクをトラバースしないバックアップ経路を計算しなければなりません。これにより、プライマリパスにおけるSRLGsが他SRLGsに属するリンクにおけるリソースの可用性と共に、代替経路計算中に知ることが不可欠です。この要件は、光リンクバンドル上の特定の意味を持ちます。具体的には、バンドルされたLSAは、リモートOXCバンドルリンクが参照する各SRLG下にリソース可用性を決定し、バンドル内の異なるSRLGsに属するリンクの関係ができるよう十分な情報を含まなければなりません。リンク1,2,3及び4をLSAに一緒に束ねられている場合、例えば、図3を考慮すると、束ねLSAは、バンドル（すなわち、1、2及び3）の一部である3つのSRLGsがあることを示す必要があり、そして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:
リンクバンドルのLSAでSRLG関係を符号化するために、SRLGsのまったく同じセットに属しているリンクのみを束ねなければなりません。図3を参照して、例えば、2つのバンドルは、次の情報と、OXC1とOXC2間のリンクのためにアドバタイズすることができます。
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.プライマリパスを最初に計算することができ、（排他的または共有）バックアップは、プライマリパスのために選択されたSRLGsに基づいて次の計算されます。この点について、
o The primary path computation procedure can output a series of bundles the path is routed over. Since a bundle is uniquely identified with a set of SRLGs, the alternate path can be computed right away based on this knowledge. In this case, if the primary path set up does not succeed for lack of resources in a chosen bundle, the primary and backup paths must be recomputed.
主要経路計算手順Oバンドル一連の経路は、出力を介してルーティングされることができます。バンドルを一意SRLGsのセットで識別されているので、代替パスは、この知見に基づいてすぐに計算することができます。設定されたプライマリパスが選ばれたバンドル内のリソースの不足のため成功しない場合は、この場合には、プライマリおよびバックアップのパスを再計算する必要があります。
o It might be desirable to compute primary paths without choosing a specific bundle apriori. That is, resource availability over all bundles between a node pair is taken into account rather than specific bundle information. In this case, the primary path computation procedure would output a series of nodes the path traverses. Each OXC in the path would have the freedom to choose the particular bundle to route that segment of the primary path. This procedure would increase the chances of successfully setting up the primary path when link state information is not up to date everywhere. But the specific bundle chosen, and hence the SRLGs in the primary path, must be captured during primary path set-up, for example, using the RSVP-TE Route Record Object [15]. This SRLG information is then used for computing the back-up path. The back-up path may also be established specifying only which SRLGs to avoid in a given segment, rather than which bundles to use. This would maximize the chances of establishing the back-up path.
O特定のバンドルのアプリオリを選択せずにプライマリパスを計算することが望ましいかもしれません。すなわち、ノード対の間のすべてのバンドル上のリソース可用性はアカウントではなく、特定のバンドル情報に取り込まれています。この場合、一次経路計算手順の出力経路が横断する一連のノードをあろう。パス内の各OXCは、プライマリパスのセグメントというルートに特定のバンドルを選択する自由を持っているでしょう。この手順は、リンク状態情報はどこでも最新のものでない場合、正常プライマリパスを設定する可能性を高めるでしょう。しかし、特定のバンドルが選択され、ひいてはプライマリパスにおけるSRLGsは、[15] RSVP-TEルートレコードオブジェクトを使用して、例えば、一次パスのセットアップ中に取得されなければなりません。このSRLG情報は、バックアップ経路を計算するために使用されます。バックアップパスも使用するバンドルむしろそのより、所与のセグメントに回避するためにどのSRLGsのみ指定確立することができます。これは、バックアップパスを確立するチャンスを最大にします。
2. The primary path and the back-up path are computed together in one step, for example, using Suurbaale's algorithm [16]. In this case, the paths must be computed using specific bundle information.
2.プライマリパスとバックアップパスはSuurbaaleのアルゴリズム[16]を用いて、例えば、一の段階で一緒に計算されます。この場合、パスは、特定のバンドル情報を使用して計算されなければなりません。
To summarize, it is essential to capture sufficient information in link bundle LSAs to accommodate different path computation procedures and to maximize the chances of successful path establishment. Depending on the path computation procedure used, the type of support 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ディスジョイントプライマリパスに対応したバックアップパスが同じリンクを割り当てることができます。ここでの仮定は、プライマリパスが同じSRLGを持っているリンクを介してルーティングされていないので、与えられた障害はそれらの一つだけに影響するということです。さらに、複数のSRLGに属するリンクに影響を与える複数の障害イベントが同時に発生しないことが想定されます。 1つの+ 1保護の場合とは異なり、バックアップ経路が先験的に確立されていません。むしろ、障害イベントは、影響を受けたプライマリパスに対応する単一のバックアップパスの確立をトリガします。
The distributed implementation of route computation for shared back-up paths require knowledge about the routing of all primary and back-up paths at every node. This raises scalability concerns. For this reason, it may be practical to consider the centralization of the route computation algorithm in a route server that has complete knowledge of the link state and path routes. Heuristics for fully distributed route computation without complete knowledge of path routes are to be determined. Path computation for restoration is further described in [11].
共有バックアップパスの経路計算の分散型の実装は、すべてのノードですべてのプライマリとバックアップパスの経路についての知識を必要とします。これは、スケーラビリティの問題を提起します。このため、リンク状態とパスルートの完全な知識を持っているルートサーバにルート計算アルゴリズムの一元化を検討するために実用的かもしれません。パス経路の完全な知識がなくても完全に分散ルート計算のためのヒューリスティックが決定されます。復元のために経路計算をさらに[11]に記載されています。
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.
標準的な手順は、すべてのサブネットワーク内に実装されている場合ライトパスのプロビジョニングのために光ネットワーク内のシグナリングは、比較的簡単な操作です。そうでない場合は、独自のシグナリングは、サブネットワーク内に実装されてもよいが、INNI横切っ標準信号に変換しました。これは、6.7節で説明したように、ENNIを横切ってシグナルに類似しています。後者の場合には経路情報が緩んであるべきである前者の場合では、シグナリングメッセージは、サブネットワークの抽象化のレベルでは、厳密な明示的な経路情報を運ぶことができます。ルートが光パスのために決定されると、パスに沿った各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.
光パスは通常、双方向です。すなわち、順方向ためOXCで選択された出力ポートは、また、パスの逆方向の入力ポートです。光路のためにシグナル通知は自律的に異なるノードによって開始することができるので、2つのパスのセットアップの試みが同時に進行している可能性があります。光路を設定しながら具体的には、OXC Aが同時に「次」OXC B.の入力ポートjに接続されるI出力ポートを選択することができる、OXC Bは、ここで異なる光路を設定するための出力ポートjを選択することができます。 「次」OXCは、これが「衝突」になりA.あります。 WDM機能がのOXCに組み込まれたときに隣接の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で説明したように共有ルールは、次のとおりバックアップパスは、物理的に多様な一次パスが同一のネットワークリソースを共有することに対応します。シグナリングメッセージは、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.
故障の点からソースOXCに障害情報の伝播、及びバックアップ経路の活性化：1 + 1と共有保護の両方の下で、活性化段階は、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:
光学インターネットワーク内では、動的にプロビジョニングすることが可能でなければならず、光ネットワークを横切って光パスを復元します。したがって：
o A standard scheme for uniquely identifying lightpath end-points in different networks is required.
O一意に異なるネットワークに光パスのエンドポイントを識別するための標準方式が必要です。
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標準のシグナリングプロトコルは、ネットワークを介して光パスをプロビジョニングするために必要とされます。
o A standard procedure is required for the restoration of lightpaths across networks.
O標準的な手順は、ネットワーク上で光パスの回復のために必要とされます。
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.
複数のネットワークを介してエンド・ツー・エンドの光パスをプロビジョニングする各ネットワーク順次パスセグメントの確立を含みます。これにより、経路セグメントは、ソースネットワークにおけるボーダー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越えたものと同様です。ネットワーク上でエンドツーエンドの回復は1 + 1のタイプのいずれかである可能性が高い、またはセクション6.4に記載されているように、各ネットワーク内のセグメント化。
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）ラムダ（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とのハイブリッドネットワークを取らなければなりません。 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ルーティング要素に、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.
光チャネルの歩道や光パスの動的な確立は、そのようなインスタンスが安定したトラフィックエンジニアリング制御システムによって、またはクライアントからの認証および承認の要求に応じて駆動されている場合は特に、光ネットワーク上で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の展開に関する同様の議論のかなり連想させます。可能なCPUオーバーヘッドコアネットワーク要素において、提案された解決策、安定性の問題、およびこのタイプの真の経済ドライバの欠如の複雑：コアネットワーク内のショートカットを駆動高度に動的なデータの展開が広く、多くの理由により担体および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上の理由や負荷分散のためのいずれか、ネットワークのパフォーマンスを向上させるために光パスの接続を設計するために）。
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.
光学領域の縁におけるリソース使用量の周りにコア中心内の動的接続のセットアップを取り巻く他の問題。一つの潜在的問題は、総帯域幅の制限のため、または同時に処理することができるフロー（例えば、光パス）の数に対する制限のいずれかの入力または出力ネットワーク要素によって処理可能なフローの数に関係します。
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.
ダイナミックショートカット光パス設定のための別の可能な短期の理由は、（例えば、企業経営者は、高帯域幅の信頼性の高い接続、などを望んでいる）、いくつかの基準に基づいて迅速に事前プロビジョニングパスになります。このシナリオでは、パスのセットが事前にプロビジョニングすることができるが、顧客がプロバイダと顧客との間の既存の契約と一致して認証され、許可設定要求を開始するまで、実際にインスタンス化されません。ある意味では、プロバイダーは、すでにこのサービスを提供することに合意したことが、唯一の顧客が明示的な要求を提出する光パスを設定することにより、それをインスタンス化します。
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.
この文書は、主に、すべてのノードが同期トポロジデータベースを維持し、維持し、データベースを更新するトポロジ状態情報をアドバタイズするライトパスのプロビジョニングのための分散モデルを扱っています。各ノードにおける制約ベースのルーティングエンティティは、光ドメインを介して適切な経路を計算するために、トポロジ・データベースおよび他の関連する詳細の情報を使用します。経路が計算されると、シグナリングプロトコル（例えば、[9]）は光パスをインスタンス化するために使用されます。
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.
対応クライアントは、光パスをソースまたはシンクすることができ、各ネットワーク要素に存在するであろう。ソースクライアントは、ソースから宛先に光パスを設定するためにサーバーを照会します。その後、サーバは、このような光パスは、一般的な条件に基づいて確立することができるかどうかを確認します。さらに、モデルの仕様に応じて、サーバがクライアントに代わって設定光パスをどちらか光パスをインスタンス化することを可能にするために、クライアントにまたはいくつかの他のエンティティに必要な情報を提供することができます。
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再生を可能にするという追加の利点を有しています。 3R再電力、信号のリタイミングと整形を参照します。残念ながら、この再生は、下にある光学機器は、ビットレートと搬送される信号のフレームフォーマットの両方を認識することを必要とします。これらのトランスポンダは、非常に高価であり、透明性の欠如は、新しいサービス[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光相互作用の進化における次のステップは、二つのドメインの間で到達可能性情報交換の導入です。これは、潜在的に光パスをエンド・ツー・エンドのLSPセットアップの一部として確立することが可能となります。最終段階は、IPと光学ドメイン間のより高度なルーティング相互作用に完全ピアモデルのサポートです。
Using a common signaling framework (based on GMPLS) from the beginning facilitates this type of evolution. In this evolution, the signaling capability and semantics at the IP-optical boundary would become more sophisticated, but the basic structure of signaling would remain. This would allow incremental developments as the interconnection model becomes more sophisticated, rather than complete re-development of signaling capabilities.
最初から（GMPLSに基づく）共通シグナリング・フレームワークを使用すると、進化のこのタイプを容易にします。この進化では、IP-光学境界でシグナリング機能とセマンティクスは、より高度になるだろうが、シグナリングの基本的な構造が残ります。相互接続モデルは、シグナリング機能のより洗練された、というよりも完全な再開発となり、これは、増分の展開を可能にします。
From a routing point of view, the use of Network Management Systems (NMS) for static connection management is prevalent in legacy optical networks. Going forward, it can be expected that connection routing using the control plane will be gradually introduced and integrated into operational infrastructures. The introduction of routing capabilities can be expected to occur in a phased approach.
ビューのルーティングの観点から、静的接続管理のためのネットワーク管理システム（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).
第一段階では、サービスプロバイダは、既存のローカル要素管理（EMS）追加の制御プレーン機能を持つソフトウェア（そしておそらくハードウェアだけでなく）をアップグレードするか、または内の自動化をある程度導入するために、NMSソフトウェアをアップグレードする可能性があります各光学サブネットワーク。このため、サブネットワークにネットワークを分割し、（I-NNIレベルで、すなわち、）各サブネットワーク内のIGPの相互運用性を導入し、そして使用する静的またはサブネットワーク間の相互運用性を合図することが望ましい場合があります。これにより、光ネットワーク上でIPでネットワークレベルの制御プレーンの相互運用に向けて進化の最初のフェーズは、（シグナリング設定または動的に）静的に相互接続された光学サブシステムの周りに編成されることを想定することができます。 （5.2.3項に記載されているように）このフェーズでは、オーバーレイ配線モデルは、光ネットワーク自体と外部IPとMPLSルータの間で使用されるであろう。
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.
シングルキャリアがサブネットワーク間のドメイン間の動的光学ルーティングの相互運用性を提供する場合interoperabibility進化ルーティングIPOには、この段階的なアプローチを進め、統合の次のレベルが達成されるであろう。サブネットワーク内およびドメイン間の機能を切り替えるネットワークから完全に独立させるために、情報交換をルーティングするUNIレベルで有効にする必要があるかもしれません。これは重要な進化を構成するであろう：ルーティングインスタンスが別個の独立した保たれている場合でも、まだ動的に到達可能とルーティング情報を、他の種類を交換することが可能であろう。この段階の間、別のより洗練されたステップは、E-NNIレベルで動的ルーティングを導入することです。これは、E-NNI横切ってピアとルーティング情報を交換することができるであろう任意の隣接ネットワーク（内部スイッチング能力とは無関係）ことを意味します。
Another alternative would be for private networks to bypass these intermediate steps and directly consider an integrated routing model from the onset. This direct evolution strategy is realistic, but is more likely to occur in operational contexts where both the IP (or MPLS) and optical networks are built simultaneously, using equipment from a single source or from multiple sources that are closely affiliated. In any case, due to the current lack of operational experience in managing this degree of control plane interaction in a heterogeneous network (these issues may exist even if the hardware and software originate from the same vendor), an augmented model is likely to be the most viable initial option. Alternatively, a very modular or hierarchical peer model may be contemplated. There may be other challenges (not just of a technical, but also administrative and even political issues) that may need to be resolved in order to achieve full a peer model at the routing level in a multi-technology and multi-vendor environment. Ultimately, the main technical improvement would likely arise from efficiencies derived from the integration of traffic-engineering capabilities in the dynamic inter-domain routing environments.
別の方法としては、これらの中間のステップをバイパスして、直接、発症から統合されたルーティングモデルを検討するプライベートネットワークのためになります。この直接進化戦略は現実的ではなく、単一のソースからまたは密接に提携している複数のソースからの機器を使用して、IP（またはMPLS）と光ネットワークの両方を同時に構築されている操作の状況で発生する可能性が高いです。いずれの場合も、異種ネットワークにおける制御プレーンの相互作用のこの程度の管理に運用経験の現在の不足による（ハードウェアとソフトウェアが同じベンダーから発信しても、これらの問題が存在してもよい）、増補モデルがあると思われます最も実行可能な最初のオプション。あるいは、非常にモジュラーまたは階層ピアモデルが考えられます。マルチテクノロジー、マルチベンダー環境でのルーティングレベルでの完全なピア・モデルを実現するために解決する必要があるかもしれないこと（だけでなく、技術的でなく、行政、さらには政治問題の）他の課題があるかもしれません。最終的に、主な技術的改善はおそらくダイナミックドメイン間ルーティング環境におけるトラフィック・エンジニアリング機能の統合から得られる効率性から生じるであろう。
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クライアント・ノードには見えないかもしれないという事実に関係します。これは、トレースルートなどの伝統的な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を参照して、メッセージ認証は、UNIインターフェイスを横切って接続作成要求の過剰な数を呼び出すことによって、光ネットワークに対するサービス拒否攻撃を実装悪意のあるIPクライアントを防止することができます。もう一つの重要なセキュリティ上の考慮事項は、リプレイ制御パケットを拒否することが必要です。この機能は、サービス拒否攻撃のいくつかの形態に対抗するのを助けることができます。リプレイ保護は部分配列の完全性のフォームを提供し、認証機構に関連して実施することができます。
Confidentiality of signaling messages is also desirable, especially in scenarios where message attributes between communicating entities include sensitive or private information. Examples of such attributes include account numbers, contract identification information, and similar types of private data.
シグナリングメッセージの機密性は、特にメッセージは、エンティティが機密またはプライベート情報を含む通信の間に属性のシナリオでも望ましいです。このような属性の例としては、口座番号、契約識別情報、および個人データの類似したタイプがあります。
The case of equipment that are not co-located presents increased security threats. In such scenarios, the communicating entities engaged in protocol message transactions may be connected over an external network. Generally, the external network may be outside the span of control of the optical network (or client IP network) administrators. As a result, the protocol messages may be subject to increased security threats, such as address spoofing, eavesdropping, and intrusion. To mitigate such threats, appropriate security mechanisms must be employed to protect the control channels and associated signaling and routing messages.
プレゼントを同じ場所に配置されていない機器の場合は、セキュリティ上の脅威が増加しました。そのようなシナリオでは、プロトコル・メッセージトランザクションに従事する通信エンティティは、外部ネットワークを介して接続されてもよいです。一般に、外部ネットワークは、光ネットワーク（またはクライアントIPネットワーク）管理者の制御のスパンの外側にあってもよいです。結果として、プロトコル・メッセージは、アドレススプーフィング、盗聴、侵入などのセキュリティ強化の脅威を受けることができます。このような脅威を軽減するために、適切なセキュリティメカニズムは、制御チャネルおよび関連するシグナリングおよびルーティングメッセージを保護するために使用されなければなりません。
Requests for optical connections from client networks must also be filtered using appropriate policies to protect against security infringements and excess resource consumption. Additionally, there may be a need for confidentiality of SRLGs in some circumstances.
クライアントネットワークからの光接続の要求は、セキュリティ侵害や過剰リソース消費から保護するために、適切なポリシーを使用してフィルタリングされなければなりません。さらに、いくつかの状況でSRLGsの機密保持のために必要があるかもしれません。
Optical networks may also be subject to subtle forms of denial of service attacks. An example of this would be requests for optical connections with explicit routes that induce a high degree of blocking for subsequent requests. This aspect might require some global coordination of resource allocation.
光ネットワークは、サービス拒否攻撃の微妙なフォームを受ける可能性があります。この例は、後続の要求のためのブロッキングの高度を誘導明示的経路と光学的に接続するための要求であろう。この局面は、資源配分のいくつかのグローバル連携が必要になる場合があります。
Another related form of subtle denial of service attack could occur when improbable optical paths are requested (i.e., paths within the network for which resources are insufficiently provisioned). Such requests for improbable paths may consume ports on optical switching elements within the network resulting in denial of service for subsequent connection requests.
そう光路が要求される場合、サービス攻撃の微妙拒否の他の関連形態は、発生する可能性があり（すなわち、リソースが不十分プロビジョニングされるネットワーク内の経路）。そうパスのような要求は、後続の接続要求に対してサービス拒否をもたらすネットワーク内の光スイッチング素子のポートを消費することができます。
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-光制御相互接続、サービスモデル、およびプロトコルメカニズムのための選択肢の多様性があります。本書で提唱アプローチは、将来の拡張を可能にする異なるサービスモデルをサポートし、これらの機能を有効にするために相補的なシグナリングおよびルーティングメカニズムを定義することでした。共通シグナリング・フレームワークに基づく進化のシナリオは、（例えば、GMPLSに基づいて）要求が高度化などの機能をインターワーキングの複雑さを増加させる能力を有する、示唆されました。この進化の原則の重要な側面は、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コミュニケーションズ・マガジン、2001年3月。
[2] Lang, J., et al., "Link Management Protocol", Work in progress.
[2]ラング、J.ら、 "リンク管理プロトコル"、進行中の作業。
[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]バーガー、L.、エド。、RFC 3471、2003年1月 "一般化マルチプロトコルラベルは（GMPLS）機能説明シグナリングを切り替えます"。
[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）のためのIANAの割り当てのドキュメントを、リソース羽田製茶HadaSeicha.comプロトコル（RSVP）、およびリソース羽田製茶HadaSeicha.comプロトコル - トラフィックエンジニアリング（RSVP-TE）を光UNIシグナリングのための拡張機能"、RFC 3476、 2003年3月。
[6] The Optical Interworking Forum, "UNI 1.0 Signaling Specification", December 2001.
[6]光インターワーキングフォーラム、 "UNI 1.0シグナリング仕様"、2001年12月。
[7] Kompella, K., et al., "OSPF Extensions in Support of Generalized MPLS," Work in Progress.
[7] Kompella、K.、ら。、 "一般化MPLSのサポートにOSPF拡張、" 進行中の作業。
[8] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP4)", RFC 1771, March 1995.
[8] Rekhter、Y.、およびT.李、 "ボーダーゲートウェイプロトコル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]バーガーは、L.、エド。は、RFC 3473、2003年1月 "一般化マルチプロトコルラベルは（GMPLS）シグナリング資源羽田製茶HadaSeicha.comプロトコル - トラフィックエンジニアリング（RSVP-TE）拡張機能を切り替えます"。
[10] Mannie, E., "GMPLS Extensions for SONET/SDH Control", Work in Progress.
[10]マニー、E.、進行中の作業 "SONET / SDH制御のGMPLS拡張"。
[11] Doshi, B., Dravida, S., Harshavardhana, P., et. al, "Optical Network Design and Restoration," Bell Labs Technical Journal, Jan-March, 1999.
[11]有罪、B。、ドラヴィダ、S。、ハーシュ・バーダン、フィル。、ら。ウェーブ、「光ネットワークの設計と復元、」ベル研究所テクニカルジャーナル、月 - 1999年3月。
[12] Kompella, K., et al., "Link Bundling in MPLS Traffic Engineering", Work in Progress.
[12] Kompella、K.、ら。、 "MPLSトラフィックエンジニアリングのリンクバンドル"、ProgressのWork。
[13] Ramamurthy, S., Bogdanowicz, Z., Samieian, S., et al., "Capacity Performance of Dynamic Provisioning in Optical Networks", Journal of Lightwave Technology, January 2001.
[13] Ramamurthy、S.、Bogdanowicz、Z.、Samieian、S.、ら、 "光ネットワークにおける動的なプロビジョニングの容量パフォーマンス"、光波テクノロジー、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]クローリー、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.、バーガー、L.、ガン、D.、李、T.、ツバメ、G.およびV.スリニバサン、 "RSVP-TE：LSPトンネルの拡張のためのRSVPする"、RFC 3209、2001年12月。
[16] Suurballe, J., "Disjoint Paths in a Network", Networks, vol. 4, 1974.
[16] Suurballe、J.、 "ネットワークにおける不整合パス"、ネットワーク、巻。 4、1974。
[17] Chiu, A., et al., "Impairments and Other Constraints On Optical Layer Routing", Work in Progress.
[17]チウ、A.、ら。、「減損および光学層ルーティング上の他の制約」、ProgressのWork。
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ネットワーク）、イアン・ダンカン（ノーテルネットワークス）、ディミトリPapadimitriou（アルカテル）、およびディミトリオスPendarakis（Tellium）を感謝したいと思います。 Security Considerations部は、スコット・ブラッドナーとスティーブBellovin氏からの入力を反映するために改訂されました。
Contributors are listed alphabetically.
寄稿者は、アルファベット順に表示されます。
Brad Cain Cereva Networks 3 Network Dr. Marlborough, MA 01752
ブラッドカインCerevaネットワーク3ネットワーク博士マールボロ、MA 01752
EMail: bcain@cereva.com
メールアドレス：bcain@cereva.com
Bilel Jamoussi Nortel Networks 600 Tech Park Billerica, MA 01821
Bilel Jamoussi Nortel Networksの600ハイテクパークビレリカ、MA 01821
Phone: 978-288-4734 EMail: jamoussi@nortelnetworks.com
電話：978-288-4734 Eメール：jamoussi@nortelnetworks.com
Debanjan Saha
Debanjanサハ
EMail: debanjan@acm.org
メールアドレス：debanjan@acm.org
Bala Rajagopalan Tellium, Inc. 2 Crescent Place P.O. Box 901 Oceanport, NJ 07757-0901
バラRajagopalan Tellium、Inc.の2クレセント置き私書箱ボックス901 Oceanport、NJ 07757から0901
EMail: braja@tellium.com
メールアドレス：braja@tellium.com
James V. Luciani Marconi Communications 2000 Marconi Dr. Warrendale, PA 15086
ジェームズ・V.ルチアーニマルコーニコミュニケーションズ2000マルコーニ氏Warrendale、PA 15086
EMail: james_luciani@mindspring.com
メールアドレス：james_luciani@mindspring.com
Daniel O. Awduche MCI 22001 Loudoun County Parkway Ashburn, VA 20147
ダニエルO. Awduche MCI 22001ラウドン郡パークウェイアッシュバーン、VA 20147
Phone: 703-886-1753 EMail: awduche@awduche.com
電話：703-886-1753 Eメール：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）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。