Network Working Group                                     B. Rajagopalan
Request for Comments: 3717                                    Consultant
Category: Informational                                       J. Luciani
                                                  Marconi Communications
                                                              D. Awduche
                                                                     MCI
                                                              March 2004
        
Network Working Group                                     B. Rajagopalan
Request for Comments: 3717                                    Consultant
Category: Informational                                       J. Luciani
                                                  Marconi Communications
                                                              D. Awduche
                                                                     MCI
                                                              March 2004
        

IP over Optical Networks: A Framework

光网络IP:一个框架

Status of this Memo

本备忘录的状况

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。

Copyright Notice

版权公告

Copyright (C) The Internet Society (2004). All Rights Reserved.

版权所有(C)互联网协会(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
        
   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology and Concepts . . . . . . . . . . . . . . . . . . .  4
   3.  The Network Model. . . . . . . . . . . . . . . . . . . . . . .  8
       3.1.  Network Interconnection. . . . . . . . . . . . . . . . .  8
       3.2.  Control Structure. . . . . . . . . . . . . . . . . . . . 11
   4.  IP over Optical Service Models and Requirements. . . . . . . . 13
       4.1.  Domain Services Model. . . . . . . . . . . . . . . . . . 13
       4.2.  Unified Service Model. . . . . . . . . . . . . . . . . . 14
       4.3.  Which Service Model? . . . . . . . . . . . . . . . . . . 15
       4.4.  What are the Possible Services?. . . . . . . . . . . . . 16
   5.  IP transport over Optical Networks . . . . . . . . . . . . . . 16
       5.1.  Interconnection Models . . . . . . . . . . . . . . . . . 17
       5.2.  Routing Approaches . . . . . . . . . . . . . . . . . . . 18
       5.3.  Signaling-Related. . . . . . . . . . . . . . . . . . . . 21
       5.4.  End-to-End Protection Models . . . . . . . . . . . . . . 23
   6.  IP-based Optical Control Plane Issues. . . . . . . . . . . . . 25
       6.1.  Addressing . . . . . . . . . . . . . . . . . . . . . . . 25
       6.2.  Neighbor Discovery . . . . . . . . . . . . . . . . . . . 27
       6.3.  Topology Discovery . . . . . . . . . . . . . . . . . . . 28
       6.4.  Protection and Restoration Models. . . . . . . . . . . . 29
       6.5.  Route Computation. . . . . . . . . . . . . . . . . . . . 30
       6.6.  Signaling Issues . . . . . . . . . . . . . . . . . . . . 32
       6.7.  Optical Internetworking. . . . . . . . . . . . . . . . . 34
   7.  Other Issues . . . . . . . . . . . . . . . . . . . . . . . . . 35
       7.1.  WDM and TDM in the Same Network. . . . . . . . . . . . . 35
       7.2.  Wavelength Conversion. . . . . . . . . . . . . . . . . . 36
       7.3.  Service Provider Peering Points. . . . . . . . . . . . . 36
       7.4.  Rate of Lightpath Set-Up . . . . . . . . . . . . . . . . 36
       7.5.  Distributed vs. Centralized Provisioning . . . . . . . . 37
       7.6.  Optical Networks with Additional Configurable
             Components . . . . . . . . . . . . . . . . . . . . . . . 38
       7.7.  Optical Networks with Limited Wavelength Conversion
             Capability . . . . . . . . . . . . . . . . . . . . . . . 38
   8.  Evolution Path for IP over Optical Architecture. . . . . . . . 39
   9.  Security Considerations. . . . . . . . . . . . . . . . . . . . 41
       9.1.  General Security Aspects . . . . . . . . . . . . . . . . 42
       9.2.  Security Considerations for Protocol Mechanisms. . . . . 43
   10. Summary and Conclusions. . . . . . . . . . . . . . . . . . . . 44
   11. Informative References . . . . . . . . . . . . . . . . . . . . 44
   12. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 45
   13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 46
   14. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 47
   15. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 48
        
1. Introduction
1. 介绍

Optical network technologies are evolving rapidly in terms of functions and capabilities. The increasing importance of optical networks is evidenced by the copious amount of attention focused on IP over optical networks and related photonic and electronic interworking issues by all major network service providers, telecommunications equipment vendors, and standards organizations. In this regard, the term "optical network" is used generically in practice to refer to both SONET/SDH-based transport networks, as well as switched optical networks (including all-optical networks).

光网络技术在功能和能力方面正在迅速发展。所有主要网络服务提供商、电信设备供应商和标准组织对光网络上的IP以及相关光子和电子互通问题的大量关注证明了光网络的日益重要性。在这方面,“光网络”一词在实践中通常用于指基于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

因此,有两个与光网络IP相关的基本问题。第一个是在光网络控制平面内自适应和重用IP控制平面协议,而不管使用光网络的数字客户端的类型如何。这个

second is the transport of IP traffic through an optical network together with the control and coordination issues that arise therefrom.

第二是通过光网络传输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 over optical networks所需的特定能力将取决于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节描述了与该框架相关的网络模型。第4节描述了IP光纤和多供应商光纤互连的服务模型和要求。本节还考虑了一些一般要求。第5节考虑了IP光互通的架构模型,描述了每个模型的相对优点。应注意的是,本文件的目的不是推广任何特定型号。然而,描述了在某些情况下可能使一种方法比另一种方法更合适的模型的特定方面。第6节描述了用于光网络的以IP为中心的控制平面机制,涵盖了支持供应和恢复的信令和路由问题。第5节和第6节中描述的方法从相对简单到复杂不等。第7节描述了与光网络IP相关的一些专门问题。第8节描述了IP over optical networking能力的一种可能的演进路径,即随着需要可能支持的日益复杂的功能。第9节考虑与此框架相关的安全问题。最后,总结和结论见第10节。

2. Terminology and Concepts
2. 术语和概念

This section introduces terminology pertinent to this framework and some related concepts. The definitions are specific to this framework and may have other interpretations elsewhere.

本节介绍与此框架相关的术语和一些相关概念。这些定义特定于本框架,在其他地方可能有其他解释。

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等)承载数字客户端有效载荷。例如,目前存在许多商用WDM网络,它们支持在单个光纤上以OC-48c(约2.5 Gbps)和OC-192(约10 Gbps)的速度运行的SONET信号的混合。具有WDM功能的光学系统可以在保持高系统性能和可靠性的同时,优雅地实现多波长并行传输。在不久的将来,商用密集波分复用系统预计将以OC-192c及以上的数据速率同时传输超过160个波长,总传输速率为1.6 TB或以上。本文件中将使用术语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 over optical Network开发基于标准的解决方案时,应考虑这些特性。

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.

光信道跟踪是光网络中两个接入点之间的点对点光层连接。在本文件中,术语“光路”可与光信道跟踪互换使用。

Optical mesh sub-network

光网状子网

An optical sub-network, as used in this framework, is a network of OXCs that supports end-to-end networking of optical channel trails providing functionality like routing, monitoring, grooming, and protection and restoration of optical channels. The interconnection of OXCs in this network can be based on a general mesh topology. The following sub-layers may be associated with this network:

本框架中使用的光子网是一个OXCs网络,它支持光通道路径的端到端网络,提供路由、监视、梳理、保护和恢复光通道等功能。该网络中的OXCs互连可基于一般网状拓扑。以下子层可能与该网络相关联:

(a) An optical multiplex section (OMS) layer network: The optical multiplex section layer provides transport for the optical channels. The information contained in this layer is a data stream comprising a set of optical channels, which may have a defined aggregate bandwidth.

(a) 光复用部分(OMS)层网络:光复用部分层为光信道提供传输。该层中包含的信息是包含一组光信道的数据流,这些光信道可以具有定义的聚合带宽。

(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).

另一方面,在不透明光网络中,传输节点可以操纵穿过它们的光信号。这种操作的一个例子是OEO转换,它可能涉及3R操作(重塑、重定时、再生,可能还有放大)。

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.

交通干线是穿越两个接入点之间相同路径的交通流的抽象,允许对交通的某些特征和属性进行参数化。

3. The Network Model
3. 网络模型
3.1. Network Interconnection
3.1. 网络互连

The network model considered in this memo consists of IP routers attached to an optical core internetwork, and connected to their peers over dynamically established switched optical channels. The optical core itself is assumed to be incapable of processing individual IP packets in the data plane.

本备忘录中考虑的网络模型由IP路由器组成,这些路由器连接到一个光核心互联网络,并通过动态建立的交换光信道连接到它们的对等方。假定光核本身不能处理数据平面中的单个IP分组。

The optical internetwork is assumed to consist of multiple optical networks, each of which may be administered by a different entity. Each optical network consists of sub-networks interconnected by optical fiber links in a general topology (referred to as an optical mesh network). This network may contain re-configurable optical equipment from a single vendor or from multiple vendors. In the near term, it may be expected that each sub-network will consist of switches from a single vendor. In the future, as standardization efforts mature, each optical sub-network may in fact contain optical switches from different vendors. In any case, each sub-network itself is assumed to be mesh-connected internally. In general, it can be expected that topologically adjacent OXCs in an optical mesh network will be connected via multiple, parallel (bi-directional) optical links. This network model is shown in Figure 1.

假定光互连网络由多个光网络组成,每个光网络可由不同实体管理。每个光网络由在一般拓扑中通过光纤链路互连的子网络组成(称为光网状网络)。该网络可能包含来自单个供应商或多个供应商的可重新配置的光学设备。在短期内,预计每个子网将由单个供应商提供的交换机组成。将来,随着标准化工作的成熟,每个光子网实际上可能包含来自不同供应商的光交换机。在任何情况下,假设每个子网络本身内部是网状连接的。通常,可以预期光网状网络中拓扑上相邻的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

在这种环境中,光子网可以完全由全光OXC或具有光电(OEO)转换的OXC组成。假设子网之间的互连通过兼容的物理接口实现,并具有适当的

optical-electrical conversions where necessary. The routers that have direct physical connectivity with the optical network are referred to as "edge routers" with respect to the optical network. As shown in Figure 1, other client networks (e.g., ATM) may also connect to the optical network.

必要时进行光电转换。与光网络具有直接物理连接的路由器相对于光网络被称为“边缘路由器”。如图1所示,其他客户端网络(例如ATM)也可以连接到光网络。

The switching function in an OXC is controlled by appropriately configuring the cross-connect fabric. Conceptually, this may be viewed as setting up a cross-connect table whose entries are of the form <input port i, output port j>, indicating that the data stream entering input port i will be switched to output port j. In the context of a wavelength selective cross-connect (generally referred to as a WXC), the cross-connect tables may also indicate the input and output wavelengths along with the input and output ports. A lightpath from an ingress port in an OXC to an egress port in a remote OXC is established by setting up suitable cross-connects in the ingress, the egress and a set of intermediate OXCs such that a continuous physical path exists from the ingress to the egress port. Optical paths tend to be bi-directional, i.e., the return path from the egress port to the ingress port is typically routed along the same set of intermediate interface cards as the forward path, but this may not be the case under all circumstances.

OXC中的切换功能通过适当配置交叉连接结构来控制。从概念上讲,这可被视为建立交叉连接表,其条目的形式为<input port i,output port 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)  |        |            |
                     +- ------------+        +------------+
        
                           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
        
   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.

通过输入端口i在波长λ(j)上接收的数据流被切换到λ(l)上的输出端口k。光路的自动建立涉及以协调的方式在适当的OXCs中设置交叉连接表条目,以便实现所需的物理路径。

Under this network model, a switched lightpath must be established between a pair of IP routers before the routers can transfer user traffic among themselves. A lightpath between IP routers may traverse multiple optical networks and be subject to different provisioning and restoration procedures in each network.

在这种网络模型下,必须在一对IP路由器之间建立交换光路,路由器才能在它们之间传输用户流量。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端点到另一个IP端点的转发路径。

3.2. Control Structure
3.2. 控制结构

There are three logical control interfaces identified in Figure 1. These are the client-optical internetwork interface, the internal node-to-node interface within an optical network (between OXCs in different sub-networks), and the external node-to-node interface between nodes in different optical networks. These interfaces are also referred to as the User-Network Interface (UNI), the internal NNI (INNI), and the external NNI (ENNI), respectively.

图1中标识了三个逻辑控制接口。它们是客户端光网络互连接口、光网络内的内部节点到节点接口(不同子网络中的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路由器)和光网络之间的服务边界。客户端和服务器(光网络)本质上是两个不同的角色:客户端角色从服务器请求服务连接;服务器角色建立连接以满足服务请求——前提是满足所有相关的准入控制条件。

Thus, the control flow across the client-optical internetwork interface is dependent on the set of services defined across it and the manner in which the services may be accessed. The service models are described in Section 4. The NNIs represent vendor-independent standardized interfaces for control flow between nodes. The distinction between the INNI and the ENNI is that the former is an interface within a given network under a single technical administration, while the later indicates an interface at the administrative boundary between networks. The INNI and ENNI may thus differ in the policies that restrict control flow between nodes.

因此,通过客户端光互连接口的控制流取决于在其上定义的服务集以及服务可被访问的方式。第4节介绍了服务模型。NNI代表节点之间控制流的独立于供应商的标准化接口。INNI和ENNI之间的区别在于前者是单一技术管理下给定网络内的接口,而后者表示网络之间管理边界处的接口。因此,INNI和ENNI在限制节点之间控制流的策略上可能有所不同。

Security, scalability, stability, and information hiding are important considerations in the specification of the ENNI. It is possible in principle to harmonize the control flow across the UNI and the NNI and eliminate the distinction between them. On the other hand, it may be required to minimize flow of control information, especially routing-related information, over the UNI; and even over the ENNI. In this case, UNI and NNIs may look different in some respects. In this document, these interfaces are treated as distinct.

安全性、可伸缩性、稳定性和信息隐藏是ENNI规范中的重要考虑因素。原则上可以协调UNI和NNI之间的控制流,并消除它们之间的区别。另一方面,可能需要最小化UNI上的控制信息流,尤其是路由相关信息流;甚至在埃尼河上。在这种情况下,UNI和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或ISIS(通过流量工程扩展和附加增强来处理光网络的特殊特性)或BGP,或其他一些协议。也可以进行其他基于目录的路由信息交换。一些信令协议选择是RSVP-TE或CR-LDP的改编。如何实现IP控制通道的详细信息不在本文档范围内。

2. Indirect interface: An out-of-band IP control channel may be implemented between the client and a device in the optical network to signal service requests and responses. For instance, a management system or a server in the optical network may receive service requests from clients. Similarly, out-of-band signaling

2. 间接接口:客户端和光网络中的设备之间可以实现带外IP控制通道,以向服务请求和响应发送信号。例如,光网络中的管理系统或服务器可以接收来自客户端的服务请求。类似地,带外信令

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.

可在客户端和光网络中的管理系统之间使用,以发出服务请求信号。在这些情况下,客户端和相应的OXC之间没有直接的控制交互。使用间接接口的一个原因是OXCs和/或客户端不支持直接信令接口。

   +---------------------------+    +---------------------------+
   |                           |    |                           |
   | +---------+   +---------+ |    | +---------+   +---------+ |
   | |         |   |         | |    | |         |   |         | |
   | | Routing |   |Signaling| |    | | Routing |   |Signaling| |
   | | Protocol|   |Protocol | |    | | Protocol|   |Protocol | |
   | |         |   |         | |    | |         |   |         | |
   | +-----+---+   +---+-----+ |    | +-----+---+   +---+-----+ |
   |       |           |       |    |       |           |       |
   |       |           |       |    |       |           |       |
   |    +--+-----------+---+   |    |    +--+-----------+---+   |
   |    |                  |   |    |    |                  |   |
   |    |     IP Layer     +....IPCC.....+     IP Layer     |   |
   |    |                  |   |    |    |                  |   |
   |    +------------------+   |    |    +------------------+   |
   |                           |    |                           |
   |        Edge Router        |    |            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光和光子网控制交互的直接接口。

4. IP over Optical Service Models and Requirements
4. IP over Optical服务模型和要求

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的服务模式和要求。UNI的服务出现了两种通用模型(也可应用于NNI)。这些模型如下。

4.1. Domain Services Model
4.1. 域服务模型

Under the domain services model, the optical network primarily offers high bandwidth connectivity in the form of lightpaths. Standardized signaling across the UNI (Figure 1) is used to invoke the following services:

在域服务模型下,光网络主要以光路的形式提供高带宽连接。跨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]).

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]).translate error, please retry

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.

光域服务模型将导致在光网络边缘的路由器之间建立光路拓扑。第5节讨论了IP over光网络的覆盖模型。

4.2. Unified Service Model
4.2. 统一服务模型

Under this model, the IP and optical networks are treated together as a single integrated network from a control plane point of view. In this regard, the OXCs are treated just like any other router as far as the control plane is considered. Thus, in principle, there is no distinction between the UNI, NNIs and any other router-to-router

在此模型下,从控制平面的角度将IP和光网络视为一个单一的集成网络。在这方面,就控制平面而言,OXCs被视为与任何其他路由器一样。因此,原则上,UNI、NNI和任何其他路由器到路由器之间没有区别

interface from a routing and signaling point of view. It is assumed that this control plane is IP-based, for example leveraging the traffic engineering extensions for MPLS or GMPLS, as described in [1]. The unified service model has so far been discussed only in the context of a single administrative domain. A unified control plane is possible even when there are administrative boundaries within an optical internetwork, but some of the integrated routing capabilities may not be practically attractive or even feasible in this case (see Section 5).

从路由和信令的角度来看接口。假设该控制平面基于IP,例如利用MPLS或GMPLS的流量工程扩展,如[1]中所述。到目前为止,只在单个管理域的上下文中讨论了统一服务模型。即使在光互连网络中存在管理边界,也可以使用统一的控制平面,但在这种情况下,某些集成路由功能可能不具有实际吸引力,甚至不可行(见第5节)。

Under the unified service model and within the context of a GMPLS network, optical network services are obtained implicitly during end-to-end GMPLS signaling. Specifically, an edge router can create a lightpath with specified attributes, or delete and modify lightpaths as it creates GMPLS label-switched paths (LSPs). In this regard, the services obtained from the optical network are similar to the domain services model. These services, however, may be invoked in a more seamless manner as compared to the domain services model. For instance, when routers are attached to a single optical network (i.e., there are no ENNIs), a remote router could compute an end-to-end path across the optical internetwork. It can then establish an LSP across the optical internetwork. But the edge routers must still recognize that an LSP across the optical internetwork is a lightpath, or a conduit for multiple packet-based LSPs.

在统一服务模型下,在GMPLS网络的上下文中,光网络服务在端到端GMPLS信令期间隐式获得。具体而言,边缘路由器可以创建具有指定属性的光路径,或者在创建GMPLS标签交换路径(LSP)时删除和修改光路径。在这方面,从光网络获得的服务类似于域服务模型。然而,与域服务模型相比,可以以更无缝的方式调用这些服务。例如,当路由器连接到单个光网络(即没有ENNIs)时,远程路由器可以计算穿过光互连网络的端到端路径。然后,它可以在光互连网络上建立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节中描述。

4.3. Which Service Model?
4.3. 哪种服务模式?

The relative merits of the above service models can be debated at length, but the approach recommended in this framework is to define routing and signaling mechanisms in support of both models. As noted above, signaling for service requests can be unified to cover both models. The developments in GMPLS signaling [4] for the unified service model and its adoption for UNI signaling [5, 6] under the domain services model essentially supports this view. The significant difference between the service models, however, is in routing protocols, as described in Sections 5 and 6.

上述服务模型的相对优点可以详细讨论,但本框架中推荐的方法是定义支持这两种模型的路由和信令机制。如上所述,服务请求的信令可以统一以覆盖这两种模型。GMPLS信令[4]在统一服务模型中的发展及其在域服务模型下对UNI信令[5,6]的采用基本上支持了这一观点。然而,服务模型之间的显著差异在于路由协议,如第5节和第6节所述。

4.4. What are the Possible Services?
4.4. 可能的服务是什么?

Specialized services may be built atop the point-to-point connectivity service offered by the optical network. For example, optical virtual private networks and bandwidth on demand are some of the services that can be envisioned.

可以在光网络提供的点到点连接服务之上构建专门的服务。例如,光虚拟专用网络和按需带宽是可以设想的一些服务。

4.4.1. Optical Virtual Private Networks (OVPNs)
4.4.1. 光虚拟专用网(OVPN)

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服务)之间的路由分离。

5. IP transport over Optical Networks
5. 光网络上的IP传输

To examine the architectural alternatives for IP over optical networks, it is important to distinguish between the data and control planes. The optical network provides a service to external entities in the form of fixed bandwidth transport pipes (optical paths). IP routers at the edge of the optical networks must necessarily have such paths established between them before communication at the IP layer can commence. Thus, the IP data plane over optical networks is realized over a virtual topology of optical paths. On the other hand, IP routers and OXCs can have a peer relation with respect to the control plane, especially for routing protocols that permit the dynamic discovery of IP endpoints attached to the optical network.

为了研究IP over光纤网络的体系结构备选方案,区分数据平面和控制平面非常重要。光网络以固定带宽传输管道(光路径)的形式向外部实体提供服务。光网络边缘的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 over optical network体系结构基本上由控制平面的组织来定义。该框架中的假设是使用基于IP的控制平面[1],例如GMPLS。然而,根据服务模型(第4节),IP和光网络中的控制平面可以是松散耦合的,也可以是紧密耦合的。该耦合决定了以下特性:

o The details of the topology and routing information advertised by the optical network across the client interface;

o 光网络通过客户端接口公布的拓扑和路由信息的详细信息;

o The level of control that IP routers can exercise in selecting explicit paths for connections across the optical network;

o IP路由器在选择光网络连接的显式路径时可以执行的控制级别;

o Policies regarding the dynamic provisioning of optical paths between routers. These include access control, accounting, and security issues.

o 有关在路由器之间动态提供光路径的策略。这些问题包括访问控制、记帐和安全问题。

The following interconnection models are then possible:

因此,以下互连模型是可能的:

5.1. Interconnection Models
5.1. 互连模型
5.1.1. The Peer Model
5.1.1. 对等模型

Under the peer model, the IP control plane acts as a peer of the optical transport network control plane. This implies that a single instance of the control plane is deployed over the IP and optical domains. When there is a single optical network involved and the IP and optical domains belong to the same entity, then a common IGP such as OSPF or IS-IS, with appropriate extensions, can be used to distribute topology information [7] over the integrated IP-optical network. In the case of OSPF, opaque LSAs can be used to advertise topology state information. In the case of IS-IS, extended TLVs will have to be defined to propagate topology state information. Many of these extensions are occurring within the context of GMPLS.

在对等模型下,IP控制平面充当光传输网络控制平面的对等。这意味着控制平面的单个实例部署在IP和光域上。当涉及单个光网络且IP和光域属于同一实体时,可以使用诸如OSPF或is-is等具有适当扩展的通用IGP在集成IP光网络上分发拓扑信息[7]。在OSPF的情况下,不透明LSA可用于公布拓扑状态信息。对于IS-IS,必须定义扩展TLV以传播拓扑状态信息。其中许多扩展都发生在GMPLS的上下文中。

When an optical internetwork with multiple optical networks is involved (e.g., spanning different administrative domains), a single instance of an intra-domain routing protocol is not attractive or even realistic. In this case, inter-domain routing and signaling protocols are needed. In either case, a tacit assumption is that a common addressing scheme will be used for the optical and IP networks. A common address space can be trivially realized by using IP addresses in both IP and optical domains. Thus, the optical network elements become IP addressable entities as noted in [1].

当涉及具有多个光网络的光因特网时(例如,跨越不同的管理域),域内路由协议的单个实例是不吸引人的,甚至是不现实的。在这种情况下,需要域间路由和信令协议。在这两种情况下,默认的假设是,光网络和IP网络将使用一种通用的寻址方案。通过在IP和光域中同时使用IP地址,可以很容易地实现公共地址空间。因此,如[1]中所述,光网络元件成为IP可寻址实体。

5.1.2. The Overlay Model
5.1.2. 叠加模型

Under the overlay model, the IP layer routing, topology distribution, and signaling protocols are independent of the routing, topology distribution, and signaling protocols within the optical domain. This model is conceptually similar to the classical IP over ATM or MPOA models, but applied to an optical internetwork instead. In the overlay model, a separate instance of the control plane (especially the routing and signaling protocols) would have to be deployed in the optical domain, independent of what exists in the IP domain. In certain circumstances, it may also be feasible to statically configure the optical channels that provide connectivity for the IP domain in the overlay model. Static configuration can be effected through network management functions. Static configuration, however,

在覆盖模型下,IP层路由、拓扑分布和信令协议独立于光域内的路由、拓扑分布和信令协议。该模型在概念上类似于经典的IP over ATM或MPOA模型,但适用于光互联网。在覆盖模型中,控制平面的单独实例(尤其是路由和信令协议)必须部署在光域中,与IP域中存在的内容无关。在某些情况下,在覆盖模型中静态配置为IP域提供连接的光信道也是可行的。静态配置可以通过网络管理功能实现。但是,静态配置,

is unlikely to scale in very large networks, and may not support the rapid connection provisioning requirements of future highly competitive networking environments.

不太可能在非常大的网络中扩展,并且可能不支持未来高度竞争的网络环境的快速连接供应需求。

5.1.3. The Augmented Model
5.1.3. 增广模型

Under the augmented model, there are separate routing instances in the IP and optical domains, but certain types of information from one routing instance can be passed through to the other routing instance. For example, external IP addresses could be carried within the optical routing protocols to allow reachability information to be passed to IP clients.

在扩展模型下,在IP和光域中有单独的路由实例,但是来自一个路由实例的某些类型的信息可以传递到另一个路由实例。例如,可以在光路由协议中携带外部IP地址,以允许将可达性信息传递给IP客户端。

The routing approaches corresponding to these interconnection models are described below.

与这些互连模型对应的路由方法如下所述。

5.2. Routing Approaches
5.2. 路由方法
5.2.1. Integrated Routing
5.2.1. 综合布线

This routing approach supports the peer model within a single administrative domain. Under this approach, the IP and optical networks are assumed to run the same instance of an IP routing protocol, e.g., OSPF with suitable "optical" extensions. These extensions must capture optical link parameters, and any constraints that are specific to optical networks. The topology and link state information maintained by all nodes (OXCs and routers) may be identical, but not necessarily. This approach permits a router to compute an end-to-end path to another router across the optical network. Suppose the path computation is triggered by the need to route a label switched path (LSP) in a GMPLS environment. Such an LSP can be established using GMPLS signaling, e.g., RSVP-TE or CR-LDP with appropriate extensions. In this case, the signaling protocol will establish a lightpath between two edge routers. This lightpath is in essence a tunnel across the optical network, and may have capacity much larger than the bandwidth required to support the first LSP. Thus, it is essential that other routers in the network realize the availability of excess capacity within the lightpath so that subsequent LSPs between the routers can use it rather than instantiating a new lightpath. The lightpath may therefore be advertised as a virtual link in the topology as a means to address this issue.

这种路由方法支持单个管理域中的对等模型。在该方法下,假设IP和光网络运行IP路由协议的相同实例,例如具有合适的“光”扩展的OSPF。这些扩展必须捕获光链路参数以及光网络特有的任何约束。所有节点(oxc和路由器)维护的拓扑和链路状态信息可能相同,但不一定相同。这种方法允许路由器计算通过光网络到另一个路由器的端到端路径。假设路径计算是由在GMPLS环境中路由标签交换路径(LSP)的需要触发的。这种LSP可以使用GMPLS信令来建立,例如,具有适当扩展的RSVP-TE或CR-LDP。在这种情况下,信令协议将在两个边缘路由器之间建立光路径。该光路本质上是一条穿越光网络的隧道,其容量可能远远大于支持第一个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

[3]中描述的“转发邻接”(FA)的概念对于将现有光路信息传播到其他路由器至关重要。FA本质上是一个广告到链路状态路由协议中的虚拟链路。因此,FA可以用定义任何常规链路中的资源的相同参数来描述。尽管如此

necessary to specify the mechanism for creating an FA, it is not necessary to specify how an FA is used by the routing scheme. Once an FA is advertised in a link state protocol, its usage for routing LSPs is defined by the route computation and traffic engineering algorithms implemented.

需要指定创建FA的机制时,不需要指定路由方案如何使用FA。一旦FA在链路状态协议中公布,其用于路由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通过两个端口P1和P2连接到OXC O1。在集成路由下,两个端口上R1和O1之间的连接将在网络的链路状态表示中捕获。现在,假设通过端口P1从R1到另一个路由器R2创建了一个全端口带宽的FA。虽然此FA被公布为R1和R2之间的虚拟链路,但也有必要从链路状态表示中删除链路R1-O1(通过P1),因为该端口不再可用于创建光路。因此,在创建FAs时,将虚拟链路的覆盖集引入链路状态表示,以替换先前在IP光接口上公布的链路。最后,将链路状态表示中捕获的光网络细节替换为FAs网络。上述计划是解决这个问题的一种方法。另一种方法是将适当的动态属性与链接状态信息相关联,以便对无法用于建立特定类型连接的链接进行适当标记。但是,一般来说,集成路由和特定于域的路由之间有很大的相似性(下面将介绍)。两者最终都涉及创建虚拟光路拓扑(覆盖在光网络上),以满足某些流量工程目标。

5.2.2. Domain-Specific Routing
5.2.2. 域特定路由

The domain-specific routing approach supports the augmented interconnection model. Under this approach, routing within the optical and IP domains are separated, with a standard routing protocol running between domains. This is similar to the IP inter-domain routing model. A specific approach for this is considered next. It is to be noted that other approaches are equally possible.

特定于域的路由方法支持增强互连模型。在这种方法下,光域和IP域内的路由是分开的,在域之间运行标准路由协议。这类似于IP域间路由模型。下一步将考虑这方面的具体方法。需要指出的是,其他方法也是同样可能的。

5.2.2.1. Domain-Specific Routing using BGP
5.2.2.1. 使用BGP的特定于域的路由

The inter-domain IP routing protocol, BGP [8], may be adapted for exchanging routing information between IP and optical domains. This would allow routers to advertise IP address prefixes within their network to the optical internetwork and to receive external IP address prefixes from the optical internetwork. The optical internetwork transports the reachability information from one IP

域间IP路由协议BGP[8]可适于在IP和光域之间交换路由信息。这将允许路由器将其网络内的IP地址前缀播发到光互联网,并从光互联网接收外部IP地址前缀。光网络从一个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).

与他人建立联系。例如,边缘路由器和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 光网络控制平面的稳定性将不再仅仅取决于光网络内发出的动态,而是可能受到来自外部路由域(从中接收外部可达性信息)的动态的影响。

5.2.3. Overlay Routing
5.2.3. 覆盖路由

The overlay routing approach supports the overlay interconnection model. Under this approach, an overlay mechanism that allows edge routers to register and query for external addresses is implemented. This is conceptually similar to the address resolution mechanism used for IP over ATM. Under this approach, the optical network could

覆盖路由方法支持覆盖互连模型。在这种方法下,实现了一种覆盖机制,允许边缘路由器注册和查询外部地址。这在概念上类似于用于IP over ATM的地址解析机制。在这种方法下,光网络可以

implement a registry that allows edge routers to register IP addresses and VPN identifiers. An edge router may be allowed to query for external addresses belonging to the same set of VPNs it belongs to. A successful query would return the address of the egress optical port through which the external destination can be reached.

实现一个注册表,允许边缘路由器注册IP地址和VPN标识符。可以允许边缘路由器查询属于它所属的同一组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内的邻接,用于VPN范围的路由方案,例如OSPF。使用这种方法,边缘路由器可以首先通过查询注册表来确定感兴趣的其他边缘路由器。在获得适当的地址后,可以形成初始叠加光路拓扑。然后可以跨光路建立路由邻接,并且可以交换进一步的路由信息以建立VPN范围的路由。

5.3. Signaling-Related
5.3. 信号相关
5.3.1. The Role of MPLS
5.3.1. MPLS的作用

It is possible to model wavelengths, and potentially TDM channels within a wavelength as "labels". This concept was proposed in [1], and "generalized" MPLS (GMPLS) mechanisms for realizing this are described in [4]. MPLS signaling protocols with traffic engineering extensions, such as RSVP-TE, can be appropriately extended and used for signaling lightpath requests. These protocols can be adapted for client/server signaling in the case of the domain services model, and for end-to-end integrated signaling in the case of the unified services model.

可以将波长和一个波长内的潜在TDM信道建模为“标签”。这一概念在[1]中提出,实现这一点的“广义”MPLS(GMPLS)机制在[4]中进行了描述。具有流量工程扩展的MPLS信令协议,例如RSVP-TE,可以适当扩展并用于信令光路请求。这些协议可以适用于域服务模型中的客户端/服务器信令,以及统一服务模型中的端到端集成信令。

5.3.2. Signaling Models
5.3.2. 信号模型

With the domain-services model, the signaling control plane in the IP and optical network are completely separate as shown in Figure 3 below. This separation also implies the separation of IP and optical address spaces (even though the optical network would be using internal IP addressing). While RSVP-TE and LDP can be adapted for UNI signaling, the full functionality of these protocols will not be used. For example, UNI signaling does not require the specification of explicit routes. On the other hand, based on the service attributes, new objects need to be signaled using these protocols as described in [5, 6].

在域服务模型中,IP和光网络中的信令控制平面完全分开,如下图3所示。这种分离还意味着IP和光地址空间的分离(即使光网络将使用内部IP寻址)。虽然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
        
   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.

在统一服务模型中,寻址在IP网络和光互连中是常见的,并且相应的信令控制是相关的,如图4所示。可以理解,GMPLS信令使用适当增强的RSVP-TE或CR-LDP协议在IP和光域中实现。但是光互连网络中的服务语义可能与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  | |  |        |
      +-----+--+  +---+----+  |  +-----+-+  +---+---+ |  +--------+
        
                        Service Boundary         Service Boundary
                              |                       |
   IP Layer GMPLS Signaling   | Optical Layer GMPLS   | IP Layer GMPLS
                              |                       |
      +--------+  +--------+  |  +-------+  +-------+ |  +--------+
      |        |  |        |  |  |       |  |       | |  |        |
      | IP LSR +--+ IP LSR +--+--+Optical+--+Optical+-+--+ IP LSR +---
      |        |  |        |  |  |  LSR  |  |  LSR  | |  |        |
      +-----+--+  +---+----+  |  +-----+-+  +---+---+ |  +--------+
        

Common Address Space, Service Translation

公共地址空间、服务转换

Figure 4: Unified Services Signaling Model

图4:统一服务信令模型

Thus, as illustrated in Figure 4, the signaling in the case of unified services is actually multi-layered. The layering is based on the technology and functionality. As an example, the specific adaptations of GMPLS signaling for SONET layer (whose functionality is transport) are described in [10].

因此,如图4所示,在统一服务的情况下,信令实际上是多层的。分层基于技术和功能。例如,SONET层(其功能为传输)的GMPLS信令的具体适配在[10]中描述。

5.4. End-to-End Protection Models
5.4. 端到端保护模型

Suppose an LSP is established from an ingress IP router to an egress router across an ingress IP network, a transit optical internetwork and an egress IP network. If this LSP is to be afforded protection in the IP layer, how is the service coordinated between the IP and optical layers?

假设在入口IP网络、传输光互连网络和出口IP网络之间建立从入口IP路由器到出口路由器的LSP。如果要在IP层为该LSP提供保护,IP层和光学层之间的服务如何协调?

Under this scenario, there are two approaches to end-to-end protection:

在这种情况下,有两种端到端保护方法:

5.4.1. Segment-Wise Protection
5.4.1. 分段保护

The protection services in the IP layer could utilize optical layer protection services for the LSP segment that traverses the optical internetwork. Thus, the end-to-end LSP would be treated as a concatenation of three LSP segments from the protection point of view: a segment in the ingress IP network, a segment in the optical internetwork and a segment in the egress IP network. The protection services at the IP layer for an end-to-end LSP must be mapped onto suitable protection services offered by the optical internetwork. Suppose that 1+1 protection is offered to LSPs at the IP layer, i.e., each protected LSP has a pre-established hot stand-by in a 1+1 or 1:1 configuration. In case of a failure of the primary LSP, traffic can be immediately switched to the stand-by. This type of protection can be realized end-to-end as follows. With reference to Figure 5, let an LSP originate at (ingress) router interface A and terminate at (egress) router interface F. Under the first protection option, a

IP层中的保护服务可以为穿越光互联网的LSP段利用光层保护服务。因此,从保护的角度来看,端到端LSP将被视为三个LSP段的串联:入口IP网络中的段、光互连网络中的段和出口IP网络中的段。端到端LSP的IP层保护服务必须映射到光互联网提供的适当保护服务。假设在IP层向LSP提供1+1保护,即每个受保护LSP都有一个1+1或1:1配置的预先建立的热备用。如果主LSP出现故障,可以立即将通信量切换到备用。这种类型的保护可以通过以下方式实现端到端。参考图5,让LSP起源于(入口)路由器接口A,终止于(出口)路由器接口F。在第一个保护选项下,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.

必须首先建立LSP的主路径。让该路径如图5所示,穿过入口网络中的路由器接口B、光学端口C(入口)和D(出口)以及出口网络中的路由器接口E。接下来,通过在a点和B点、C点和D点以及E点和F点之间建立保护路径,在每个网络中分别实现1+1保护。此外,B-C段和D-E段本身必须使用下降侧保护进行1+1保护。对于C和D之间的网段,光互联网必须提供与IP网络中提供的服务类似的1+1服务。

   +----------------+    +------------------+    +---------------+
   |                |    |                  |    |               |
   A Ingress IP Net B----C Optical Internet D----E Egress IP Net F
   |                |    |                  |    |               |
   +----------------+    +------------------+    +---------------+
        
   +----------------+    +------------------+    +---------------+
   |                |    |                  |    |               |
   A Ingress IP Net B----C Optical Internet D----E Egress IP Net F
   |                |    |                  |    |               |
   +----------------+    +------------------+    +---------------+
        

Figure 5: End-to-End Protection Example

图5:端到端保护示例

5.4.2. Single-Layer Protection
5.4.2. 单层保护

Under this model, the protection services in the IP layer do not rely on any protection services offered in the optical internetwork. Thus, with reference to Figure 5, two SRLG-disjoint LSPs are established between A and F. The corresponding segments in the optical internetwork are treated as independent lightpaths in the optical internetwork. These lightpaths may be unprotected in the optical internetwork.

在此模型下,IP层中的保护服务不依赖于光互联网中提供的任何保护服务。因此,参考图5,在A和F之间建立了两个SRLG不相交LSP。光网络中的相应段被视为光网络中的独立光路。这些光路在光网络中可能不受保护。

5.4.3. Differences
5.4.3. 分歧

A distinction between these two choices is as follows. Under the first choice, the optical internetwork is actively involved in end-to-end protection, whereas under the second choice, any protection service offered in the optical internetwork is not utilized directly by client IP network. Also, under the first choice, the protection in the optical internetwork may apply collectively to a number of IP LSPs. That is, with reference to Figure 5, many LSPs may be aggregated into a single lightpath between C and D. The optical internetwork protection may then be applied to all of them at once leading to some gain in scalability. Under the second choice, each IP LSP must be separately protected. Finally, the first choice allows different restoration signaling to be implemented in the IP and optical internetwork. These restoration protocols are "patched up" at the service boundaries to realize end-to-end protection. A further advantage of this is that restoration is entirely contained within the network where the failure occurs, thereby improving the restoration latency, and perhaps network stability as a fault within

这两种选择的区别如下。在第一种选择中,光互连积极参与端到端保护,而在第二种选择中,光互连中提供的任何保护服务都不会直接由客户端IP网络使用。此外,在第一选择下,光因特网中的保护可共同应用于多个IP lsp。也就是说,参考图5,许多LSP可以聚合到C和D之间的单个光路中。然后,光网络间保护可以一次应用于所有LSP,从而在可伸缩性方面获得一些收益。根据第二种选择,每个IP LSP必须单独保护。最后,第一种选择允许在IP和光互连网络中实现不同的恢复信令。这些恢复协议在服务边界“修补”,以实现端到端保护。这样做的另一个优点是,恢复完全包含在发生故障的网络中,从而提高了恢复延迟,并且可能提高了网络作为故障的稳定性

an optical domain is contained and corrected within the domain. For instance, if there is a failure in the optical internetwork, optical network protocols restore the affected internal segments. Under the second choice, restoration signaling is always end-to-end between IP routers, essentially by-passing the optical internetwork. A result of this is that restoration latency could be higher. In addition, restoration protocols in the IP layer must run transparently over the optical internetwork in the overlay mode. IP based recovery techniques may however be more resource efficient, as it may be possible to convey traffic through the redundant capacity under fault-free scenarios. In particular, it may be possible to utilize classification, scheduling, and concepts of forwarding equivalence class to route lower class traffic over protect facilities and then possibly preempt them to make way for high priority traffic when faults occur.

光域包含在域内并在域内进行校正。例如,如果光网络中出现故障,光网络协议将恢复受影响的内部段。在第二种选择下,恢复信令始终是IP路由器之间的端到端信令,基本上是通过光互连。其结果是恢复延迟可能更高。此外,IP层中的恢复协议必须以覆盖模式在光互联网上透明运行。然而,基于IP的恢复技术可能更具资源效率,因为在无故障情况下,可以通过冗余容量传输流量。特别地,可以利用分类、调度和转发等价类的概念来路由保护设施上的低级通信,然后可能抢占它们,以便在发生故障时为高优先级通信让路。

6. IP-based Optical Control Plane Issues
6. 基于IP的光控制平面问题

Provisioning and restoring lightpaths end-to-end between IP networks requires protocol and signaling support within optical sub-networks, and across the INNI and ENNI. In this regard, a distinction is made between control procedures within an optical sub-network (Figure 1), between sub-networks, and between networks. The general guideline followed in this framework is to separate these cases, and allow the possibility that different control procedures are followed inside different sub-networks, while a common set of procedures are followed across sub-networks and networks.

在IP网络之间端到端供应和恢复光路径需要在光子网内以及在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.

单个供应商子网络内的控制平面程序无需定义,因为这些程序可能是专有的。显然,在子网内部和子网之间可以遵循相同的控制程序。但这只是本框架文件中的一项建议,而不是一项强制性要求。因此,在下文中,首先考虑子网间的信令和路由,然后讨论网络间的类似问题。

6.1. Addressing
6.1. 寻址

For interoperability across optical sub-networks using an IP-centric control plane, one of the fundamental issues is that of addressing. What entities should be identifiable from a signaling and routing point of view? How should they be addressed? This section presents some high level guidelines on this issue.

对于使用以IP为中心的控制平面跨光纤子网的互操作性,一个基本问题是寻址。从信令和路由的角度来看,应该识别哪些实体?应该如何解决这些问题?本节介绍了有关此问题的一些高级指导原则。

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。SRLG的显著特征是,给定链路可能属于多个SRLG,而属于给定SRLG的两个链路可能分别属于两个其他SRLG。如图6所示。这里,链路1、2、3和4可能属于SRLG 1,链路1、2和3可能属于SRLG 2,链路4可能属于SRLG 3。同样,链路5和6可以属于SRLG 1,链路7和8可以属于SRLG 4。(在本例中,相同的SRLG,即1,包含来自两个不同邻接的链接)。

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识别一致,该信息对于正确的路径计算是必要的。

6.2. Neighbor Discovery
6.2. 邻居发现

Routing within the optical network relies on knowledge of network topology and resource availability. This information may be gathered and used by a centralized system, or by a distributed link state routing protocol. In either case, the first step towards network-wide link state determination is the discovery of the status of local links to all neighbors by each OXC. Specifically, each OXC must determine the up/down status of each optical link, the bandwidth and other parameters of the link, and the identity of the remote end of the link (e.g., remote port number). The last piece of information is used to specify an appropriate label when signaling for lightpath provisioning. The determination of these parameters could be based on a combination of manual configuration and an automated protocol running between adjacent OXCs. The characteristics of such a protocol would depend on the type of OXCs that are adjacent (e.g., transparent or opaque).

光网络中的路由依赖于网络拓扑和资源可用性的知识。该信息可由集中式系统或分布式链路状态路由协议收集和使用。在这两种情况下,确定网络范围链路状态的第一步是由每个OXC发现到所有邻居的本地链路的状态。具体而言,每个OXC必须确定每个光链路的上/下状态、链路的带宽和其他参数以及链路远端的标识(例如,远程端口号)。最后一条信息用于在为光通路供应发送信号时指定适当的标签。这些参数的确定可以基于手动配置和在相邻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终止的不透明OXC的情况下,邻居发现协议的一个实例(例如,LMP[2])将在每个OXC端口上运行,与相邻OXC处的相应协议实例通信。该协议将利用SONET开销字节周期性地向邻居发送(配置的)本地属性。因此,两个相邻的交换机可以自动确定彼此的身份和本地连接,还可以跟踪本地链路的上行/下行状态。[2]中描述了使用透明OXCs的邻居发现。

   +--------------+          +------------+         +------------+
   |              +-1:OC48---+            +-5:OC192-+            |
   |              +-2:OC48---+            +-6:OC192-+            |
   |    OXC1      +-3:OC48---+     OXC2   +-7:OC48--+     OXC3   |
   |              +-4:OC192--+            +-8:OC48--+            |
   |              |          |            |  +------+            |
   +--------------+          +----+-+-----+  | +----+------+-----+
                                  | |        | |          |
                                  | |        | |          |
   +--------------+               | |        | |          |
   |              |          +----+-+-----+  | |   +------+-----+
   |              +----------+            +--+ |   |            |
   |     OXC4     +----------+            +----+   |            |
   |              +----------+    OXC5    +--------+     OXC6   |
   |              |          |            +--------+            |
   +--------------+          |            |        |            |
                             +------+-----+        +------+-----+
        
   +--------------+          +------------+         +------------+
   |              +-1:OC48---+            +-5:OC192-+            |
   |              +-2:OC48---+            +-6:OC192-+            |
   |    OXC1      +-3:OC48---+     OXC2   +-7:OC48--+     OXC3   |
   |              +-4:OC192--+            +-8:OC48--+            |
   |              |          |            |  +------+            |
   +--------------+          +----+-+-----+  | +----+------+-----+
                                  | |        | |          |
                                  | |        | |          |
   +--------------+               | |        | |          |
   |              |          +----+-+-----+  | |   +------+-----+
   |              +----------+            +--+ |   |            |
   |     OXC4     +----------+            +----+   |            |
   |              +----------+    OXC5    +--------+     OXC6   |
   |              |          |            +--------+            |
   +--------------+          |            |        |            |
                             +------+-----+        +------+-----+
        

Figure 6: Mesh Optical Network with SRLGs

图6:带SRLGs的网状光网络

6.3. Topology Discovery
6.3. 拓扑发现

Topology discovery is the procedure by which the topology and resource state of all the links in a network are determined. This procedure may be done as part of a link state routing protocol (e.g., OSPF, ISIS), or it can be done via the management plane (in the case of centralized path computation). The implementation of a link state protocol within a network (i.e., across sub-network boundaries) means that the same protocol runs in OXCs in every sub-network. If this assumption does not hold then interworking of routing between sub-networks is required. This is similar to inter-network routing discussed in Section 6.7. The focus in the following is therefore on standardized link state routing.

拓扑发现是确定网络中所有链路的拓扑和资源状态的过程。该过程可以作为链路状态路由协议(例如,OSPF、ISIS)的一部分完成,也可以通过管理平面完成(在集中式路径计算的情况下)。网络内链路状态协议的实现(即,跨越子网边界)意味着相同的协议在每个子网的OXCs中运行。如果此假设不成立,则需要子网之间的路由互通。这类似于第6.7节中讨论的网络间路由。因此,下文的重点是标准化链路状态路由。

In general, most of the link state routing functionality is maintained when applied to optical networks. However, the representation of optical links, as well as some link parameters, are changed in this setting. Specifically,

通常,当应用于光网络时,大多数链路状态路由功能都会得到维护。但是,在此设置中,光链路的表示以及某些链路参数会发生更改。明确地

o The link state information may consist of link bundles [12]. Each link bundle is represented as an abstract link in the network topology. Different bundling representations are possible. For instance, the parameters of the abstract link may include the number, bandwidth and the type of optical links contained in the underlying link bundle [12]. Also, the SRLGs corresponding to each optical link in the bundle may be included as a parameter.

o 链路状态信息可能由链路束组成[12]。每个链路束在网络拓扑中表示为一个抽象链路。可以使用不同的捆绑表示。例如,抽象链路的参数可以包括基本链路束中包含的光链路的数量、带宽和类型[12]。此外,对应于束中的每个光链路的srlg可以被包括为参数。

o The link state information should capture restoration-related parameters for optical links. Specifically, with shared protection (Section 6.5), the link state updates must have information that allows the computation of shared protection paths.

o 链路状态信息应捕获光链路的恢复相关参数。具体而言,对于共享保护(第6.5节),链路状态更新必须具有允许计算共享保护路径的信息。

o A single routing adjacency could be maintained between neighbors which may have multiple optical links (or even multiple link bundles) between them. This reduces the protocol messaging overhead.

o 可以在邻居之间保持单个路由邻接,邻居之间可能有多个光链路(甚至多个链路束)。这减少了协议消息传递开销。

o Since link availability information changes dynamically, a flexible policy for triggering link state updates based on availability thresholds may be implemented. For instance, changes in availability of links of a given bandwidth (e.g., OC-48) may trigger updates only after the availability figure changes by a certain percentage.

o 由于链路可用性信息是动态变化的,因此可以实施基于可用性阈值触发链路状态更新的灵活策略。例如,给定带宽(例如,OC-48)的链路的可用性的改变可能仅在可用性数字改变一定百分比后触发更新。

These concepts are relatively well-understood. On the other hand, the resource representation models and the topology discovery process for hierarchical routing (e.g., OSPF with multiple areas) are areas that need further work.

这些概念相对来说已经被很好地理解了。另一方面,用于分层路由的资源表示模型和拓扑发现过程(例如,具有多个区域的OSPF)是需要进一步工作的领域。

6.4. Protection and Restoration Models
6.4. 保护和恢复模式

Automatic restoration of lightpaths is a service offered by optical networks. There could be local and end-to-end mechanisms for restoration of lightpaths within a network (across the INNI). Local mechanisms are used to select an alternate link (or network segment) between two OXCs across the INNI when a failure affects the primary link (or primary network segment) over which the (protected) lightpath is routed. Local restoration does not affect the end-to-end route of the lightpath. When local restoration is not possible (e.g., no alternate link is available between the adjacent OXCs in question), end-to-end restoration may be performed. Under this scenario this, the affected lightpath may be rerouted over an alternate diverse path to circumvent failed resources. For end-to-end restoration, alternate paths may be pre-computed to expedite the recovery time. End to end restoration may also be mixed with local recovery in various ways depending on acceptable tradeoffs between utilization of network resources and recovery times.

光路自动恢复是光网络提供的一项服务。可以有本地和端到端机制来恢复网络内的光路(通过INNI)。当故障影响(受保护的)光路路由的主链路(或主网段)时,本地机制用于在INNI上的两个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

端到端保护可基于两种类型的保护方案;“1+1”保护或共享保护。在1+1保护下,沿物理多样性路由为受保护的主路径建立备份路径。两条路径都处于活动状态,主路径上的故障会导致立即切换到备用路径。在共享保护下,备份路径

corresponding to physically diverse primary paths may share the same network resources. When a failure affects a primary path, it is assumed that the same failure will not affect the other primary paths whose back-ups share resources.

对应于物理上不同的主路径可以共享相同的网络资源。当故障影响主路径时,假定相同的故障不会影响备份共享资源的其他主路径。

It is possible that different restoration schemes may be implemented within optical sub-networks. It is therefore necessary to consider a two-level restoration mechanism. Path failures within an optical sub-network could be handled using procedures specific to the sub-network. If this fails, end-to-end restoration across sub-networks could be invoked. The border OXC that is the ingress to a sub-network can act as the source for restoration procedures within a sub-network. The signaling for invoking end-to-end restoration across the INNI is described in Section 6.6.3. The computation of the back-up path for end-to-end restoration may be based on various criteria. It is assumed that the back-up path is computed by the source OXC, and signaled using standard methods.

可以在光子网内实现不同的恢复方案。因此,有必要考虑两级恢复机制。光子网内的路径故障可以使用特定于该子网的程序来处理。如果失败,可以调用跨子网络的端到端恢复。作为子网入口的边界OXC可以作为子网内恢复过程的源。第6.6.3节描述了在INNI中调用端到端恢复的信令。用于端到端恢复的备份路径的计算可以基于各种标准。假设备份路径由源OXC计算,并使用标准方法发送信号。

6.5. Route Computation
6.5. 路由计算

The computation of a primary route for a lightpath within an optical network is essentially a constraint-based routing problem. The constraint is typically the bandwidth required for the lightpath, perhaps along with administrative and policy constraints. The objective of path computation could be to minimize the total capacity required for routing lightpaths [13].

光网络中光路主路由的计算本质上是一个基于约束的路由问题。该约束通常是光路所需的带宽,可能还有管理和策略约束。路径计算的目标可能是最小化路由光路所需的总容量[13]。

Route computation with constraints may be accomplished using a number of algorithms [14]. When 1+1 protection is used, a back-up path that does not traverse on any link which is part of the same SRLG as links in the primary path must be computed. Thus, it is essential that the SRLGs in the primary path be known during alternate path computation, along with the availability of resources in links that belong to other SRLGs. This requirement has certain implications on optical link bundling. Specifically, a bundled LSA must include adequate information such that a remote OXC can determine the resource availability under each SRLG that the bundled link refers to, and the relationship between links belonging to different SRLGs in the bundle. For example, considering Figure 3, if links 1,2,3 and 4 are bundled together in an LSA, the bundled LSA must indicate that there are three SRLGs which are part of the bundle (i.e., 1, 2 and 3), and that links in SRLGs 2 and 3 are also part of SRLG 1.

可使用多种算法完成带约束的路线计算[14]。当使用1+1保护时,必须计算一条备份路径,该路径不在与主路径中的链路属于同一SRLG的任何链路上穿过。因此,在备用路径计算期间,必须知道主路径中的srlg以及属于其他srlg的链路中资源的可用性。这一要求对光纤链路捆绑有一定的影响。具体而言,捆绑LSA必须包含足够的信息,以便远程OXC能够确定捆绑链路所指的每个SRLG下的资源可用性,以及属于捆绑中不同SRLG的链路之间的关系。例如,考虑图3,如果链路1、2、3和4在LSA中捆绑在一起,则捆绑的LSA必须指示有三个SRLGs是捆绑的一部分(即1、2和3),并且SRLGs 2和3中的链路也是SRLG1的一部分。

To encode the SRLG relationships in a link bundle LSA, only links which belong to exactly the same set of SRLGs must be bundled together. With reference to Figure 3, for example, two bundles can be advertised for links between OXC1 and OXC2, with the following information:

要在链接束LSA中对SRLG关系进行编码,必须仅将完全属于同一组SRLG的链接绑定在一起。例如,参考图3,可以为OXC1和OXC2之间的链接播发两个捆绑包,并提供以下信息:

   Bundle No.     SRLGs    Link Type   Number   Other Info
   -------------------------------------------------------
     1             1,2       OC-48       3          ---
     2             1,3       OC-192      1          ---
        
   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,例如,使用RSVP-TE路由记录对象[15]。然后,该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

总之,必须在链路束LSA中捕获足够的信息,以适应不同的路径计算过程,并最大限度地提高成功建立路径的机会。根据使用的路径计算程序,支撑类型

needed during path establishment (e.g., the recording of link group or SRLG information during path establishment) may differ.

路径建立期间所需的信息(例如,在路径建立期间记录链路组或SRLG信息)可能不同。

When shared protection is used, the route computation algorithm must take into account the possibility of sharing links among multiple back-up paths. Under shared protection, the back-up paths corresponding to SRLG-disjoint primary paths can be assigned the same links. The assumption here is that since the primary paths are not routed over links that have the same SRLG, a given failure will affect only one of them. Furthermore, it is assumed that multiple failure events affecting links belonging to more than one SRLG will not occur concurrently. Unlike the case of 1+1 protection, the back-up paths are not established apriori. Rather, a failure event triggers the establishment of a single back-up path corresponding to the affected primary path.

当使用共享保护时,路由计算算法必须考虑在多个备用路径之间共享链路的可能性。在共享保护下,与SRLG不相交主路径对应的备份路径可以分配相同的链路。这里的假设是,由于主路径不是在具有相同SRLG的链路上路由的,因此给定的故障将只影响其中一个。此外,假设影响属于多个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]中进一步描述了用于恢复的路径计算。

6.6. Signaling Issues
6.6. 信号问题

Signaling within an optical network for lightpath provisioning is a relatively simple operation if a standard procedure is implemented within all sub-networks. Otherwise, proprietary signaling may be implemented within sub-networks, but converted back to standard signaling across the INNI. This is similar to signaling across the ENNI, as described in Section 6.7. In the former case, signaling messages may carry strict explicit route information, while in the latter case the route information should be loose, at the level of abstraction of sub-networks. Once a route is determined for a lightpath, each OXC along the path must appropriately configure their cross-connects in a coordinated fashion. This coordination is conceptually analogous to selecting incoming and outgoing labels in a label-switched environment. Thus, protocols like RSVP-TE [9] may be adapted and used across the INNI for this purpose. The adaptation of IP-based signaling protocols must take into account a number of peculiar attributes of optical networks.

如果在所有子网内实施标准过程,则光网络内用于光路径供应的信令是相对简单的操作。否则,专有信令可在子网内实现,但在整个INNI内转换回标准信令。这类似于第6.7节所述的通过ENNI的信令。在前一种情况下,信令消息可能携带严格的显式路由信息,而在后一种情况下,在子网的抽象级别上,路由信息应该是松散的。一旦为光路确定了路由,路径上的每个OXC必须以协调的方式适当配置其交叉连接。这种协调在概念上类似于在标签交换环境中选择传入和传出标签。因此,类似于RSVP-TE[9]的协议可以在整个INNI中进行调整并用于此目的。基于IP的信令协议的适应必须考虑光网络的一些特殊属性。

6.6.1. Bi-Directional Lightpath Establishment
6.6.1. 双向光路建立

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上为正向选择的输出端口也是路径反向的输入端口。由于光路径的信令可以由不同的节点自主发起,因此有可能同时进行两次路径设置尝试。具体地,在设置光路径时,OXC A可以选择连接到“下一个”OXC B的输入端口j的输出端口i。同时,OXC B可以选择用于设置不同光路径的输出端口j,其中“下一个”OXC是A。这导致“碰撞”。类似地,当WDM功能内置到OXC中时,当相邻OXC为两个不同的光路选择直接连接的输出端口和相同的波长时,会发生冲突。有两种方法来处理这种碰撞。首先,可以检测到碰撞,并且可以拆除并重新建立涉及的路径。或者,可以完全避免碰撞。

6.6.2. Failure Recovery
6.6.2. 故障恢复

The impact of transient partial failures must be minimized in an optical network. Specifically, optical paths that are not directly affected by a failure must not be torn down due to the failure. For example, the control processor in an OXC may fail, affecting signaling and other internodal control communication. Similarly, the control channel between OXCs may be affected temporarily by a failure. These failure may not affect already established optical paths passing through the OXC fabric. The detection of such failures by adjacent nodes, for example, through a keepalive mechanism between signaling peers, must not result in these optical paths being torn down.

在光网络中,必须尽量减少瞬态部分故障的影响。具体而言,不受故障直接影响的光路不得因故障而被拆除。例如,OXC中的控制处理器可能发生故障,影响信令和其他节点间控制通信。类似地,OXCs之间的控制信道可能会暂时受到故障的影响。这些故障可能不会影响通过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处的局部状态。

6.6.3. Restoration
6.6.3. 恢复

Signaling for restoration has two distinct phases. There is a reservation phase in which capacity for the protection path is established. Then, there is an activation phase in which the back-up path is actually put in service. The former phase typically is not subject to strict time constraints, while the latter is.

恢复信号有两个不同的阶段。有一个预留阶段,在此阶段建立保护路径的容量。然后,有一个激活阶段,在该阶段中备份路径实际投入使用。前一阶段通常不受严格的时间限制,而后一阶段则受到严格的时间限制。

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.

在1+1和共享保护下,激活阶段有两个部分:从故障点向源OXC传播故障信息,以及激活备份路径。为了实现几十毫秒的响应时间,这两个阶段的信号必须非常快。当光链路基于SONET时,可以使用带内信号,从而加快响应速度。带外控制,可能需要考虑使用非常短的IP分组和优先级处理的控制信道上的快速信令。虽然可以使用RSVP或CR-LDP来激活保护路径,但这些协议不提供任何方法来优先考虑恢复信令,而不是用于供应的信令。例如,与恢复相关的RSVP消息可能排队在多个供应消息之后,从而延迟恢复。因此,可能有必要发展恢复信令优先级的概念,并将适当的机制纳入现有信令协议以实现这一点。或者,可以专门开发一种新的信令机制,用于在恢复期间激活保护路径。

6.7. Optical Internetworking
6.7. 光互连

Within an optical internetwork, it must be possible to dynamically provision and restore lightpaths across optical networks. Therefore:

在光互连网络中,必须能够动态地提供和恢复光网络中的光路。因此:

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提供的功能如下所示。

6.7.1. Neighbor Discovery
6.7.1. 邻居发现

Neighbor discovery procedure, as described in Section 6.2, can be used for this. Indeed, a single protocol should be standardized for neighbor discovery within and across networks.

如第6.2节所述,邻居发现程序可用于此目的。事实上,对于网络内和网络间的邻居发现,应该对单个协议进行标准化。

6.7.2. Addressing and Routing Model
6.7.2. 寻址和路由模型

The addressing mechanisms described in Section 6.1 can be used to identify OXCs, ports, channels and sub-channels in each network. It is essential that the OXC IP addresses are unique within the internetwork.

第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等协议在这方面的使用。

6.7.3. Restoration
6.7.3. 恢复

Local restoration across the ENNI is similar to that across INNI described in Section 6.6.3. End-to-end restoration across networks is likely to be either of the 1+1 type, or segmented within each network, as described in Section 6.4.

ENNI的局部恢复与第6.6.3节所述的INNI的局部恢复类似。如第6.4节所述,跨网络的端到端恢复可能是1+1类型,或在每个网络内分段。

7. Other Issues
7. 其他问题
7.1. WDM and TDM in the Same Network
7.1. 同一网络中的WDM和TDM

A practical assumption would be that if SONET (or some other TDM mechanism that is capable partitioning the bandwidth of a wavelength) is used, then TDM is leveraged as an additional method to differentiate between "flows". In such cases, wavelengths and time intervals (sub-channels) within a wavelength become analogous to labels (as noted in [1]) which can be used to make switching decisions. This would be somewhat akin to using VPI (e.g., wavelength) and VCI (e.g., TDM sub-channel) in ATM networks. More generally, this will be akin to label stacking and to LSP nesting within the context of Multi-Protocol Lambda Switching [1]. GMPLS signaling [4] supports this type of multiplexing.

一个实际的假设是,如果使用SONET(或能够划分波长带宽的某种其他TDM机制),则TDM被用作区分“流”的附加方法。在这种情况下,波长内的波长和时间间隔(子信道)类似于可用于做出切换决策的标签(如[1]中所述)。这在某种程度上类似于在ATM网络中使用VPI(例如波长)和VCI(例如TDM子信道)。更一般地说,这类似于多协议Lambda交换上下文中的标签堆叠和LSP嵌套[1]。GMPLS信令[4]支持这种类型的多路复用。

7.2. Wavelength Conversion
7.2. 波长转换

Some form of wavelength conversion may exist at some switching elements. This however may not be the case in some pure optical switching elements. A switching element is essentially anything more sophisticated than a simple repeater, that is capable of switching and converting a wavelength Lambda(k) from an input port to a wavelength Lambda(l) on an output port. In this display, it is not necessarily the case that Lambda(k) = Lambda(l), nor is it necessarily the case that the data carried on Lambda(k) is switched through the device without being examined or modified.

在某些开关元件处可能存在某种形式的波长转换。然而,在一些纯光开关元件中可能并非如此。交换元件本质上比简单的中继器更复杂,它能够将波长λ(k)从输入端口切换并转换为输出端口上的波长λ(l)。在该显示中,不一定是Lambda(k)=Lambda(l)的情况,也不一定是Lambda(k)上携带的数据在未经检查或修改的情况下通过设备切换的情况。

It is not necessary to have a wavelength converter at every switching element. A number of studies have attempted to address the issue of the value of wavelength conversion in an optical network. Such studies typically use the blocking probability (the probability that a lightpath cannot be established because the requisite wavelengths are not available) as a metric to adjudicate the effectiveness of wavelength conversion. The IP over optical architecture must take into account hybrid networks with some OXCs capable of wavelength conversion and others incapable of this. The GMPLS "label set" mechanism [4] supports the selection of the same label (i.e., wavelength) across an NNI.

没有必要在每个开关元件上都安装波长转换器。许多研究试图解决光网络中波长转换的价值问题。此类研究通常使用阻塞概率(由于所需波长不可用而无法建立光路的概率)作为衡量波长转换有效性的指标。IP over optical架构必须考虑混合网络,其中一些OXC能够进行波长转换,而另一些则不能进行波长转换。GMPLS“标签集”机制[4]支持跨NNI选择相同的标签(即波长)。

7.3. Service Provider Peering Points
7.3. 服务提供商对等点

There are proposed inter-network interconnect models which allow certain types of peering relationships to occur at the optical layer. This is consistent with the need to support optical layer services independent of higher layers payloads. In the context of IP over optical networks, peering relationships between different trust domains will eventually have to occur at the IP layer, on IP routing

有一些建议的网络间互连模型允许在光学层发生某些类型的对等关系。这与支持独立于更高层有效载荷的光学层服务的需求是一致的。在IP over optical Network的环境中,不同信任域之间的对等关系最终必须发生在IP层的IP路由上

elements, even though non-IP paths may exist between the peering routers.

元素,即使对等路由器之间可能存在非IP路径。

7.4. Rate of Lightpath Set-Up
7.4. 光路设置速率

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 over optical Network中,动态建立光信道路径和光路径是非常理想的,尤其是当这种实例化由稳定的流量工程控制系统驱动,或者响应来自客户端的经过身份验证和授权的请求时。

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 over光纤网络中使用动态、数据驱动的快捷光路设置。这些提案中提出的论点让人想起关于在IP网络核心部署ATM的类似讨论。运营商和ISP并未广泛采用在核心网络中部署高度动态的数据驱动快捷方式,原因有很多:核心网络元件中可能存在CPU开销、拟议解决方案的复杂性、稳定性问题,以及此类服务缺乏真正的经济驱动力。本文档假设这种模式不会改变,高度动态、数据驱动的快捷光路设置将用于未来的研究。相反,在IP over optical Network演进的初始阶段,预计将广泛使用的光信道轨迹和光路径将包括以下内容:

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.

启动经过身份验证和授权的安装请求,这与提供商和客户之间的现有协议一致。从某种意义上说,提供商可能已经同意提供此服务,但只有在客户提交明确请求时,才会通过设置光路来实例化此服务。

7.5. Distributed vs. Centralized Provisioning
7.5. 分布式资源调配与集中式资源调配

This document has mainly dealt with a distributed model for lightpath provisioning, in which all nodes maintain a synchronized topology database, and advertise topology state information to maintain and refresh the database. A constraint-based routing entity in each node then uses the information in the topology database and other relevant details to compute appropriate paths through the optical domain. Once a path is computed, a signaling protocol (e.g., [9]) is used to instantiate the lightpath.

本文档主要讨论光通路供应的分布式模型,其中所有节点维护一个同步拓扑数据库,并发布拓扑状态信息以维护和刷新数据库。然后,每个节点中基于约束的路由实体使用拓扑数据库中的信息和其他相关细节来计算通过光域的适当路径。一旦计算出路径,就使用信令协议(例如,[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.

集中化有助于实施复杂的容量优化方案,并且可能是具有互连多供应商光纤子网的光纤网络中的短期供应解决方案。然而,从长远来看,集中一些控制程序(如交通工程)的分布式解决方案可能是所遵循的方法。

7.6. Optical Networks with Additional Configurable Components
7.6. 具有附加可配置组件的光网络

Thus far, this memo has focused mainly on IP over optical networks where the cross-connect is the basic dynamically re-configurable device in the optical network. Recently, as a consequence of technology evolution, various types of re-configurable optical components are now available, including tunable lasers, tunable filters, etc. Under certain circumstances, it may be necessary to

到目前为止,本备忘录主要关注光网络IP,其中交叉连接是光网络中基本的动态可重新配置设备。最近,由于技术的发展,各种类型的可重新配置光学组件现在都可用,包括可调谐激光器、可调谐滤波器等。在某些情况下,可能需要

parameterize the characteristics of these components and advertise them within the control plane. This aspect is left for further study.

参数化这些组件的特征,并在控制平面内公布它们。这方面有待进一步研究。

7.7. Optical Networks with Limited Wavelength Conversion Capability
7.7. 波长转换能力有限的光网络

At the time of the writing of this document, the majority of optical networks being deployed are "opaque". In this context the term opaque means that each link is optically isolated by transponders doing optical-electrical-optical conversions. Such conversions have the added benefit of permitting 3R regeneration. The 3Rs refer to re-power, signal retiming and reshaping. Unfortunately, this regeneration requires that the underlying optical equipment be aware of both the bit rate and frame format of the carried signal. These transponders are quite expensive and their lack of transparency constrains the rapid introduction of new services [17]. Thus there are strong motivators to introduce "domains of transparency" wherein all-optical networking equipment would transport data unfettered by these drawbacks.

在编写本文件时,正在部署的大多数光网络都是“不透明的”。在这种情况下,术语不透明意味着每个链路通过进行光电转换的转发器进行光学隔离。这种转换具有允许3R再生的额外好处。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 over optical networking问题值得特别关注。在这种网络中,由于光通信的特殊特性导致的传输损伤使路径选择过程复杂化。这些传输损伤包括损耗、噪声(主要由放大器自发辐射——ASE引起)、色散(色散和偏振模色散)、串扰和非线性效应。在这样的网络中,两个节点之间的路径的可行性不再仅仅是拓扑和资源可用性的函数,而是取决于路径上损伤的累积。如果损伤累积过大,则目的地节点处的光信噪比(OSNR)以及因此的电比特错误率(BER)可能超过规定的阈值,使得所得光信道不可用于数据通信。开发基于IP的光网络控制平面的挑战是以通用方式抽象光层的这些特殊特性[17],以便将其用于路径计算。

8. Evolution Path for IP over Optical Architecture
8. ipover光体系结构的演进路径

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 over光网络体系结构的演进路径问题。

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 over optical部署将基于域服务模型(具有重叠互连),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软件,以便在每个光子网中引入一定程度的自动化。因此,可能需要将网络划分为子网,并在每个子网内引入IGP互操作性(即,在i-NNI级别),并在子网之间采用静态或信号互操作性。因此,可以预见,IP over Optical network中向网络级控制平面互操作性演进的第一阶段将围绕静态互连(或以信号配置动态互连)的光学子网系统进行组织。在此阶段,将在光网络本身和外部IP和MPLS路由器之间使用覆盖互连模型(如第5.2.3节所述)。

Progressing with this phased approach to IPO routing interoperabibility evolution, the next level of integration will be achieved when a single carrier provides dynamic optical routing interoperability between subnetworks and between domains. In order to become completely independent of the network switching capability within subnetworks and across domains, routing information exchange may need to be enabled at the UNI level. This would constitute a significant evolution: even if the routing instances are kept separate and independent, it would still be possible to dynamically exchange reachability and other types of routing information. Another more sophisticated step during this phase is to introduce dynamic routing at the E-NNI level. This means that any neighboring networks (independent of internal switching capability) would be capable of exchanging routing information with peers across the E-NNI.

随着这一分阶段的IPO路由互操作性发展,当单个运营商提供子网之间和域之间的动态光路由互操作性时,将实现下一级集成。为了完全独立于子网内和跨域的网络交换能力,可能需要在UNI级别启用路由信息交换。这将构成一个重要的演变:即使路由实例保持独立和独立,仍然可以动态地交换可达性和其他类型的路由信息。在此阶段,另一个更复杂的步骤是在E-NNI级别引入动态路由。这意味着任何相邻网络(独立于内部交换能力)都能够通过E-NNI与对等方交换路由信息。

Another alternative would be for private networks to bypass these intermediate steps and directly consider an integrated routing model from the onset. This direct evolution strategy is realistic, but is more likely to occur in operational contexts where both the IP (or MPLS) and optical networks are built simultaneously, using equipment from a single source or from multiple sources that are closely affiliated. In any case, due to the current lack of operational experience in managing this degree of control plane interaction in a heterogeneous network (these issues may exist even if the hardware and software originate from the same vendor), an augmented model is likely to be the most viable initial option. Alternatively, a very modular or hierarchical peer model may be contemplated. There may be other challenges (not just of a technical, but also administrative and even political issues) that may need to be resolved in order to achieve full a peer model at the routing level in a multi-technology and multi-vendor environment. Ultimately, the main technical improvement would likely arise from efficiencies derived from the integration of traffic-engineering capabilities in the dynamic inter-domain routing environments.

另一种选择是私人网络绕过这些中间步骤,并从开始时直接考虑集成路由模型。这种直接演进策略是现实的,但更可能发生在同时构建IP(或MPLS)和光网络的操作环境中,使用来自单个源或来自紧密关联的多个源的设备。在任何情况下,由于目前缺乏在异构网络中管理这种程度的控制平面交互的操作经验(即使硬件和软件来自同一供应商,这些问题也可能存在),扩展模型可能是最可行的初始选择。或者,可以考虑非常模块化或层次化的对等模型。为了在多技术和多供应商环境中实现路由级别的完全对等模型,可能还需要解决其他挑战(不仅是技术问题,还有行政问题甚至政治问题)。最终,主要的技术改进可能来自于在动态域间路由环境中集成流量工程能力所产生的效率。

9. Security Considerations
9. 安全考虑

The architectural framework described in this document requires a number of different protocol mechanisms for its realization. Specifically, the role of neighbor discovery, routing, and signaling protocols were highlighted in previous sections. The general security issues that arise with these protocols include:

本文档中描述的体系结构框架需要许多不同的协议机制来实现。具体来说,邻居发现、路由和信令协议的作用在前面的章节中已经强调。这些协议产生的一般安全问题包括:

o The authentication of entities exchanging information (e.g., signaling, routing, or link management) across a control interface;

o 通过控制接口交换信息(例如,信令、路由或链路管理)的实体的认证;

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工具(如traceroute)来检测光域内的攻击。

For the aforementioned reasons, the output of the routing protocol security (RPSEC) efforts within the IETF should be considered in the design of control protocols for optical networks.

出于上述原因,在设计光网络控制协议时,应考虑IETF内路由协议安全(RPSEC)工作的输出。

In Section 2, the concept of a trust domain was defined as a network under a single technical administration in which adequate security measures are established to prevent unauthorized intrusion from outside the domain. It should be strongly noted that within a trust domain, any subverted node can send control messages which can compromise the entire network.

在第2节中,信任域的概念被定义为单一技术管理下的网络,其中建立了足够的安全措施,以防止来自域外的未经授权的入侵。应该特别注意的是,在信任域中,任何被破坏的节点都可以发送控制消息,这可能会危害整个网络。

9.1. General security aspects
9.1. 一般安全方面

Communication protocols usually require two main security mechanisms: authentication and confidentiality. Authentication mechanisms ensure data origin verification and message integrity so that intrusions and unauthorized operations can be detected and mitigated. For example, with reference to Figure 1, message authentication can prevent a malicious IP client from mounting a denial of service attack against

通信协议通常需要两种主要的安全机制:身份验证和机密性。身份验证机制确保数据源验证和消息完整性,从而可以检测并减轻入侵和未经授权的操作。例如,参考图1,消息身份验证可以防止恶意IP客户端对其发起拒绝服务攻击

the optical network by invoking an excessive number of connection creation requests across the UNI interface. Another important security consideration is the need to reject replayed control packets. This capability can assist in countering some forms of denial of service attacks. Replay protection provides a form of partial sequence integrity, and can be implemented in conjunction with an authentication mechanism.

通过调用UNI接口上过多的连接创建请求来创建光网络。另一个重要的安全考虑是需要拒绝重播的控制数据包。此功能有助于抵御某些形式的拒绝服务攻击。重播保护提供了一种形式的部分序列完整性,可以与身份验证机制结合使用。

Confidentiality of signaling messages is also desirable, especially in scenarios where message attributes between communicating entities include sensitive or private information. Examples of such attributes include account numbers, contract identification information, and similar types of private data.

信令消息的机密性也是可取的,特别是在通信实体之间的消息属性包括敏感或私有信息的情况下。此类属性的示例包括账号、合同标识信息和类似类型的私有数据。

The case of equipment that are not co-located presents increased security threats. In such scenarios, the communicating entities engaged in protocol message transactions may be connected over an external network. Generally, the external network may be outside the span of control of the optical network (or client IP network) administrators. As a result, the protocol messages may be subject to increased security threats, such as address spoofing, eavesdropping, and intrusion. To mitigate such threats, appropriate security mechanisms must be employed to protect the control channels and associated signaling and routing messages.

设备不在同一地点的情况会增加安全威胁。在这种情况下,参与协议消息事务的通信实体可以通过外部网络连接。通常,外部网络可能超出光网络(或客户端IP网络)管理员的控制范围。因此,协议消息可能受到更大的安全威胁,例如地址欺骗、窃听和入侵。为了减轻这种威胁,必须采用适当的安全机制来保护控制通道和相关的信令和路由消息。

Requests for optical connections from client networks must also be filtered using appropriate policies to protect against security infringements and excess resource consumption. Additionally, there may be a need for confidentiality of SRLGs in some circumstances.

还必须使用适当的策略过滤来自客户端网络的光纤连接请求,以防止安全侵权和过度资源消耗。此外,在某些情况下,可能需要对SRLGs进行保密。

Optical networks may also be subject to subtle forms of denial of service attacks. An example of this would be requests for optical connections with explicit routes that induce a high degree of blocking for subsequent requests. This aspect might require some global coordination of resource allocation.

光网络也可能受到微妙形式的拒绝服务攻击。这方面的一个例子是对具有显式路由的光连接的请求,这会导致对后续请求的高度阻塞。这方面可能需要对资源分配进行一些全球协调。

Another related form of subtle denial of service attack could occur when improbable optical paths are requested (i.e., paths within the network for which resources are insufficiently provisioned). Such requests for improbable paths may consume ports on optical switching elements within the network resulting in denial of service for subsequent connection requests.

当请求不可能的光路径(即,网络中资源配置不足的路径)时,可能会发生另一种相关形式的隐蔽拒绝服务攻击。这种对不可能路径的请求可能会占用网络中光交换元件上的端口,从而导致对后续连接请求的拒绝服务。

9.2. Security Considerations for Protocol Mechanisms
9.2. 协议机制的安全考虑

The security requirements for IP-centric control protocols employed in the control plane of optical networks would depend on the specific characteristics of the protocols and the security risks that exist in a particular operational context. Such details relating to particular operational contexts are beyond the scope of this document and hence are not considered further. Nevertheless, it must be stated that such control protocols must take into account the issues associated with the separation of control channels from data channels in switched optical networks, and the magnitude and extent of service interruptions within the IP domain that could result from outages emanating from the optical domain.

在光网络的控制平面中使用的以IP为中心的控制协议的安全要求将取决于协议的特定特征以及特定操作环境中存在的安全风险。与特定操作环境相关的此类细节超出了本文件的范围,因此不作进一步考虑。然而,必须说明的是,此类控制协议必须考虑到与交换光网络中的控制信道与数据信道分离相关的问题,以及可能由光域发出的中断导致的IP域内服务中断的大小和程度。

10. Summary and Conclusions
10. 摘要和结论

The objective of this document was to define a framework for IP over optical networks, considering the service models, and routing and signaling issues. There are a diversity of choices for IP-optical control interconnection, service models, and protocol mechanisms. The approach advocated in this document was to support different service models which allow for future enhancements, and define complementary signaling and routing mechanisms to enable these capabilities. An evolutionary scenario, based on a common signaling framework (e.g., based on GMPLS) was suggested, with the capability to increase the complexity of interworking functionality as the requirements become more sophisticated. A key aspect of this evolutionary principle is that the IP-optical control and service interaction is first based on the domain services model with overlay interconnection that will eventually evolve to support full peer interaction.

本文件的目的是在考虑服务模型、路由和信令问题的基础上,定义光网络IP的框架。IP光控制互连、服务模型和协议机制有多种选择。本文档中提倡的方法是支持不同的服务模型,以允许将来的增强,并定义补充的信令和路由机制来实现这些功能。提出了一种基于通用信令框架(例如,基于GMPLS)的进化方案,该方案能够随着需求变得更加复杂而增加互通功能的复杂性。这种进化原理的一个关键方面是,IP光控制和服务交互首先基于域服务模型,该模型具有覆盖互连,最终将进化为支持完全对等交互。

11. Informative References
11. 资料性引用

[1] Awduche, D. and Y. Rekhter, "Multi-Protocol Lambda Switching: Combining MPLS Traffic Engineering Control With Optical Crossconnects", IEEE Communications Magazine, March 2001.

[1] Awduche,D.和Y.Rekhter,“多协议Lambda交换:将MPLS流量工程控制与光交叉连接相结合”,IEEE通信杂志,2001年3月。

[2] Lang, J., et al., "Link Management Protocol", Work in progress.

[2] Lang,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] Berger,L.,Ed.,“通用多协议标签交换(GMPLS)信令功能描述”,RFC 3471,2003年1月。

[5] Rajagopalan, B., "Documentation of IANA Assignments for Label Distribution Protocol (LDP), Resource ReSeVation Protocol (RSVP), and Resource ReSeVation Protocol-Traffic Engineering (RSVP-TE) Extensions for Optical UNI Signaling", RFC 3476, March 2003.

[5] Rajagopalan,B.,“标签分发协议(LDP)、资源重分配协议(RSVP)和光UNI信令的资源重分配协议流量工程(RSVP-TE)扩展的IANA分配文件”,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.Li,“边境网关协议4(BGP4)”,RFC 17711995年3月。

[9] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReSeVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.

[9] Berger,L.,Ed.,“广义多协议标签交换(GMPLS)信令资源重新分配协议流量工程(RSVP-TE)扩展”,RFC 3473,2003年1月。

[10] Mannie, E., "GMPLS Extensions for SONET/SDH Control", Work in Progress.

[10] Mannie,E.“SONET/SDH控制的GMPLS扩展”,正在进行中。

[11] Doshi, B., Dravida, S., Harshavardhana, P., et. al, "Optical Network Design and Restoration," Bell Labs Technical Journal, Jan-March, 1999.

[11] Doshi,B.,Dravida,S.,Harshavardhana,P.,等,“光网络设计和恢复”,贝尔实验室技术期刊,1999年1月至3月。

[12] Kompella, K., et al., "Link Bundling in MPLS Traffic Engineering", Work in Progress.

[12] Kompella,K.等人,“MPLS流量工程中的链路捆绑”,正在进行中。

[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] Crawley,E.,Nair,R.,Rajagopalan,B.和H.Sandick,“互联网中基于QoS的路由框架”,RFC 2386,1998年8月。

[15] Awduche, D., Berger, L., Gan, D., Li, T., Swallow, G. and V. Srinivasan, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.

[15] Awduche,D.,Berger,L.,Gan,D.,Li,T.,Swallow,G.和V.Srinivasan,“RSVP-TE:LSP隧道RSVP的扩展”,RFC 3209,2001年12月。

[16] Suurballe, J., "Disjoint Paths in a Network", Networks, vol. 4, 1974.

[16] Suurballe,J.,“网络中的不相交路径”,网络,第4卷,1974年。

[17] Chiu, A., et al., "Impairments and Other Constraints On Optical Layer Routing", Work in Progress.

[17] Chiu,A.,等人,“光学层路由的损伤和其他限制”,正在进行中。

12. Acknowledgments
12. 致谢

We would like to thank Zouheir Mansourati (Movaz Networks), Ian Duncan (Nortel Networks), Dimitri Papadimitriou (Alcatel), and Dimitrios Pendarakis (Tellium) for their contributions to this document. The Security Considerations section was revised to reflect input from Scott Bradner and Steve Bellovin.

我们要感谢Zouheir Mansourati(Movaz Networks)、Ian Duncan(Nortel Networks)、Dimitri Papadimitriou(Alcatel)和Dimitrios Pendarakis(Tellium)对本文件的贡献。对安全考虑部分进行了修订,以反映Scott Bradner和Steve Bellovin的意见。

13. Contributors
13. 贡献者

Contributors are listed alphabetically.

贡献者按字母顺序列出。

Brad Cain Cereva Networks 3 Network Dr. Marlborough, MA 01752

Brad Cain Cereva Networks 3网络马萨诸塞州马尔伯勒博士01752

   EMail: bcain@cereva.com
        
   EMail: bcain@cereva.com
        

Bilel Jamoussi Nortel Networks 600 Tech Park Billerica, MA 01821

比勒贾穆西北电网络600科技园马里兰州比勒里卡01821

Phone: 978-288-4734 EMail: jamoussi@nortelnetworks.com

电话:978-288-4734电子邮件:jamoussi@nortelnetworks.com

Debanjan Saha

德班詹萨哈

   EMail: debanjan@acm.org
        
   EMail: debanjan@acm.org
        
14. Authors' Addresses
14. 作者地址

Bala Rajagopalan Tellium, Inc. 2 Crescent Place P.O. Box 901 Oceanport, NJ 07757-0901

巴拉·拉贾戈帕兰Tellium,Inc.新泽西州海洋港901号新月广场2号邮政信箱07757-0901

   EMail: braja@tellium.com
        
   EMail: braja@tellium.com
        

James V. Luciani Marconi Communications 2000 Marconi Dr. Warrendale, PA 15086

詹姆斯诉卢西亚尼·马可尼通讯2000马可尼沃伦代尔博士,宾夕法尼亚州15086

   EMail: james_luciani@mindspring.com
        
   EMail: james_luciani@mindspring.com
        

Daniel O. Awduche MCI 22001 Loudoun County Parkway Ashburn, VA 20147

Daniel O.Awduche MCI 22001 Loudoun County Parkway Ashburn,弗吉尼亚州,20147

Phone: 703-886-1753 EMail: awduche@awduche.com

电话:703-886-1753电子邮件:awduche@awduche.com

15. Full Copyright Statement
15. 完整版权声明

Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights.

版权所有(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.

本文件及其包含的信息是按“原样”提供的,贡献者、他/她所代表或赞助的组织(如有)、互联网协会和互联网工程任务组不承担任何明示或暗示的担保,包括但不限于任何保证,即使用本文中的信息不会侵犯任何权利,或对适销性或特定用途适用性的任何默示保证。

Intellectual Property

知识产权

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围,或此类权利下的任何许可可能或可能不可用的程度,不采取任何立场;它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息,请参见BCP 78和BCP 79。

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

向IETF秘书处披露的知识产权副本和任何许可证保证,或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果,可从IETF在线知识产权存储库获取,网址为http://www.ietf.org/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的IETF-ipr@ietf.org.

Acknowledgement

确认

Funding for the RFC Editor function is currently provided by the Internet Society.

RFC编辑功能的资金目前由互联网协会提供。