rfc3717.IP over Optical Networks A Framework

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 FrameworkStatus of this MemoThis memo provides information for the Internet community. It doesnot specify an Internet standard of any kind. Distribution of thismemo is unlimited.Copyright NoticeCopyright (C) The Internet Society (2004). All Rights Reserved.AbstractThe Internet transport infrastructure is moving towards a model ofhigh-speed routers interconnected by optical core networks. Thearchitectural choices for the interaction between IP and opticalnetwork 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 aswell as IP-optical network interactions (together referred to as "IP over optical networks").Rajagopalan, et al. Informational [Page 1]Table of Contents1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 32. Terminology and Concepts . . . . . . . . . . . . . . . . . . . 43. The Network Model. . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Network Interconnection. . . . . . . . . . . . . . . . . 83.2. Control Structure. . . . . . . . . . . . . . . . . . . . 114. 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? . . . . . . . . . . . . . . . . . . 154.4. What are the Possible Services?. . . . . . . . . . . . . 165. IP transport over Optical Networks . . . . . . . . . . . . . . 16 5.1. Interconnection Models . . . . . . . . . . . . . . . . . 17 5.2. Routing Approaches . . . . . . . . . . . . . . . . . . . 18 5.3. Signaling-Related. . . . . . . . . . . . . . . . . . . . 215.4. End-to-End Protection Models . . . . . . . . . . . . . . 236. 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 . . . . . . . . . . . . . . . . . . . . 326.7. Optical Internetworking. . . . . . . . . . . . . . . . . 347. 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 ConfigurableComponents . . . . . . . . . . . . . . . . . . . . . . . 38 7.7. Optical Networks with Limited Wavelength ConversionCapability . . . . . . . . . . . . . . . . . . . . . . . 388. Evolution Path for IP over Optical Architecture. . . . . . . . 399. Security Considerations. . . . . . . . . . . . . . . . . . . . 41 9.1. General Security Aspects . . . . . . . . . . . . . . . . 429.2. Security Considerations for Protocol Mechanisms. . . . . 4310. Summary and Conclusions. . . . . . . . . . . . . . . . . . . . 4411. Informative References . . . . . . . . . . . . . . . . . . . . 4412. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 4513. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 4614. Authors’ Addresses . . . . . . . . . . . . . . . . . . . . . . 4715. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 48 Rajagopalan, et al. Informational [Page 2]1. IntroductionOptical network technologies are evolving rapidly in terms offunctions and capabilities. The increasing importance of opticalnetworks is evidenced by the copious amount of attention focused onIP over optical networks and related photonic and electronicinterworking issues by all major network service providers,telecommunications equipment vendors, and standards organizations. In this regard, the term "optical network" is used generically inpractice to refer to both SONET/SDH-based transport networks, as well as switched optical networks (including all-optical networks).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 tomake them more versatile [1]. An essential attribute of intelligent optical networks is the capability to instantiate and route opticallayer connections in real-time or near real-time, and to providecapabilities 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.The optical network must also be versatile because some serviceproviders may offer generic optical layer services that may not beclient-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 networkcontrol plane should utilize IP-based protocols for dynamicprovisioning and restoration of optical channels within and acrossoptical sub-networks. This is based on the practical view thatsignaling 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 andsignaling in all-optical networks. Also, there are different viewson the model for interaction between the optical network and clientnetworks, such as IP networks. Reasonable architectural alternatives in this regard must be supported, with an understanding of theirrelative merits.Thus, there are two fundamental issues related to IP over opticalnetworks. The first is the adaptation and reuse of IP control plane protocols within the optical network control plane, irrespective ofthe types of digital clients that utilize the optical network. The Rajagopalan, et al. Informational [Page 3]second is the transport of IP traffic through an optical networktogether with the control and coordination issues that arisetherefrom.This document defines a framework for IP over optical networkscovering the requirements and mechanisms for establishing an IP-centric optical control plane, and the architectural aspects of IPtransport over optical networks. In this regard, it is recognizedthat 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 thespecific operational requirements, a progression of capabilities ispossible, reflecting increasingly sophisticated interactions at these interfaces. This document therefore advocates the definition of"capability sets" that define the evolution of functionality at theinterfaces as more sophisticated operational requirements arise.This document is organized as follows. In the next section,terminology covering some basic concepts related to this frameworkare described. The definitions are specific to this framework andmay have other connotations elsewhere. In Section 3, the networkmodel pertinent to this framework is described. The service modeland requirements for IP-optical, and multi-vendor opticalinternetworking are described in Section 4. This section alsoconsiders some general requirements. Section 5 considers thearchitectural models for IP-optical interworking, describing therelative merits of each model. It should be noted that it is not the intent of this document to promote any particular model over theothers. However, particular aspects of the models that may make one approach more appropriate than another in certain circumstances aredescribed. Section 6 describes IP-centric control plane mechanismsfor optical networks, covering signaling and routing issues insupport of provisioning and restoration. The approaches described in Section 5 and 6 range from the relatively simple to thesophisticated. 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 termsof increasingly sophisticated functionality that may be supported as the need arises. Section 9 considers security issues pertinent tothis framework. Finally, the summary and conclusion are presented in Section 10.2. Terminology and ConceptsThis section introduces terminology pertinent to this framework and some related concepts. The definitions are specific to thisframework and may have other interpretations elsewhere.Rajagopalan, et al. Informational [Page 4]WDMWavelength Division Multiplexing (WDM) is a technology that allowsmultiple optical signals operating at different wavelengths to bemultiplexed onto a single optical fiber and transported in parallelthrough the fiber. In general, each optical wavelength may carrydigital 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 WDMnetworks in existence today that support a mix of SONET signalsoperating at OC-48c (approximately 2.5 Gbps) and OC-192(approximately 10 Gbps) over a single optical fiber. An opticalsystem with WDM capability can achieve parallel transmission ofmultiple wavelengths gracefully while maintaining high systemperformance and reliability. In the near future, commercial denseWDM systems are expected to concurrently carry more than 160wavelengths at data rates of OC-192c and above, for a total of 1.6Tbps or more. The term WDM will be used in this document to refer to both WDM and DWDM (Dense WDM).In general, it is worth noting that WDM links are affected by thefollowing factors, which may introduce impairments into the opticalsignal path: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.All these factors (and others not mentioned here) constitute domainspecific features of optical transport networks. As noted in [1],these features should be taken into account in developing standardsbased solutions for IP over optical networks.Optical cross-connect (OXC)An OXC is a space-division switch that can switch an optical datastream from an input port to a output port. Such a switch mayutilize optical-electrical conversion at the input port andelectrical-optical conversion at the output port, or it may be all-optical. An OXC is assumed to have a control-plane processor thatimplements the signaling and routing protocols necessary forcomputing and instantiating optical channel connectivity in theoptical domain.Rajagopalan, et al. Informational [Page 5]Optical channel trail or LightpathAn 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 channeltrail.Optical mesh sub-networkAn optical sub-network, as used in this framework, is a network ofOXCs that supports end-to-end networking of optical channel trailsproviding functionality like routing, monitoring, grooming, andprotection 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:(a) An optical multiplex section (OMS) layer network: The opticalmultiplex section layer provides transport for the opticalchannels. The information contained in this layer is a datastream comprising a set of optical channels, which may have adefined aggregate bandwidth.(b) An optical transmission section (OTS) layer network: This layerprovides functionality for transmission of optical signalsthrough different types of optical media.This framework does not address the interaction between the opticalsub-network and the OMS, or between the OMS and OTS layer networks.Mesh optical network (or simply, "optical network")A mesh optical network, as used in document, is a topologicallyconnected collection of optical sub-networks whose node degree mayexceed 2. Such an optical network is assumed to be under the purview of a single administrative entity. It is also possible to conceiveof a large scale global mesh optical network consisting of thevoluntary interconnection of autonomous optical networks, each ofwhich 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.Optical internetworkAn optical internetwork is a mesh-connected collection of opticalnetworks. Each of these networks may be under a differentadministration.Rajagopalan, et al. Informational [Page 6]Wavelength continuity propertyA lightpath is said to satisfy the wavelength continuity property if it is transported over the same wavelength end-to-end. Wavelengthcontinuity is required in optical networks with no wavelengthconversion feature.Wavelength pathA lightpath that satisfies the wavelength continuity property iscalled a wavelength path.Opaque vs. transparent optical networksA 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, intermediateswitching nodes in a transparent optical network do not have accessto the payload carried by the optical signals.Note that amplification of signals at transit nodes is permitted in transparent optical networks (e.g., using Erbium Doped FiberAmplifiers << EDFAs).On the other hand, in opaque optical networks, transit nodes maymanipulate optical signals traversing through them. An example ofsuch manipulation would be OEO conversion which may involve 3Roperations (reshaping, retiming, regeneration, and perhapsamplification).Trust domainA trust domain is a network under a single technical administrationin which adequate security measures are established to preventunauthorized intrusion from outside the domain. Hence, it may beassumed that most nodes in the domain are deemed to be secure ortrusted 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 toform an enlarged heterogeneous trust domain. However, to simplifythe discussions in this document, it will be assumed, without loss of generality, that the term trust domain applies to a singleadministrative entity with appropriate security policies. It should be noted that within a trust domain, any subverted node can sendcontrol messages which can compromise the entire network. Rajagopalan, et al. Informational [Page 7]FlowIn this document, the term flow will be used to signify the smallest non-separable stream of data, from the point of view of an endpointor termination point (source or destination node). The reader should note that the term flow is heavily overloaded in contemporarynetworking literature. In this document, we will consider awavelength to be a flow, under certain circumstances. However, ifthere is a method to partition the bandwidth of the wavelength, then each partition may be considered a flow, for example using timedivision multiplexing (TDM), it may be feasible to consider eachquanta of time within a given wavelength as a flow.Traffic TrunkA 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 Model3.1. Network InterconnectionThe network model considered in this memo consists of IP routersattached to an optical core internetwork, and connected to theirpeers over dynamically established switched optical channels. Theoptical core itself is assumed to be incapable of processingindividual IP packets in the data plane.The optical internetwork is assumed to consist of multiple opticalnetworks, each of which may be administered by a different entity.Each optical network consists of sub-networks interconnected byoptical fiber links in a general topology (referred to as an optical mesh network). This network may contain re-configurable opticalequipment from a single vendor or from multiple vendors. In the near term, it may be expected that each sub-network will consist ofswitches from a single vendor. In the future, as standardizationefforts mature, each optical sub-network may in fact contain optical switches from different vendors. In any case, each sub-networkitself is assumed to be mesh-connected internally. In general, itcan be expected that topologically adjacent OXCs in an optical meshnetwork will be connected via multiple, parallel (bi-directional)optical links. This network model is shown in Figure 1.In this environment, an optical sub-network may consist entirely ofall-optical OXCs or OXCs with optical-electrical-optical (OEO)conversion. Interconnection between sub-networks is assumed to beimplemented through compatible physical interfaces, with suitable Rajagopalan, et al. Informational [Page 8]optical-electrical conversions where necessary. The routers thathave direct physical connectivity with the optical network arereferred 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.The switching function in an OXC is controlled by appropriatelyconfiguring the cross-connect fabric. Conceptually, this may beviewed as setting up a cross-connect table whose entries are of theform <input port i, output port j>, indicating that the data streamentering input port i will be switched to output port j. In thecontext of a wavelength selective cross-connect (generally referredto as a WXC), the cross-connect tables may also indicate the inputand output wavelengths along with the input and output ports. Alightpath from an ingress port in an OXC to an egress port in aremote OXC is established by setting up suitable cross-connects inthe ingress, the egress and a set of intermediate OXCs such that acontinuous 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 thesame set of intermediate interface cards as the forward path, butthis may not be the case under all circumstances.Rajagopalan, et al. Informational [Page 9]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 ModelMultiple traffic streams exiting from an OXC may be multiplexed onto a fiber optic link using WDM technology. The WDM functionality mayexist outside of the OXC, and be transparent to the OXC. Or, thisfunction 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 Rajagopalan, et al. Informational [Page 10]the data stream received on wavelength Lambda(j) over input port i is switched to output port k on Lambda(l). Automated establishment oflightpaths involves setting up the cross-connect table entries in the appropriate OXCs in a coordinated manner such that the desiredphysical path is realized.Under this network model, a switched lightpath must be establishedbetween a pair of IP routers before the routers can transfer usertraffic among themselves. A lightpath between IP routers maytraverse multiple optical networks and be subject to differentprovisioning and restoration procedures in each network.The IP-based control plane issue for optical networks pertains to the design of standard signaling and routing protocols for provisioningand restoration of lightpaths across multiple optical networks.Similarly, IP transport over optical networks involves establishingIP reachability and seamlessly constructing forwarding paths from one IP endpoint to another over an optical network.3.2. Control StructureThere are three logical control interfaces identified in Figure 1.These are the client-optical internetwork interface, the internalnode-to-node interface within an optical network (between OXCs indifferent sub-networks), and the external node-to-node interfacebetween nodes in different optical networks. These interfaces arealso referred to as the User-Network Interface (UNI), the internalNNI (INNI), and the external NNI (ENNI), respectively.The distinction between these interfaces arises out of the type andamount of control information flow across them. The client-opticalinternetwork interface (UNI) represents a service boundary betweenthe client (e.g., IP router) and the optical network. The client and server (optical network) are essentially two different roles: theclient role requests a service connection from a server; the serverrole establishes the connection to fulfill the service request --provided all relevant admission control conditions are satisfied.Thus, the control flow across the client-optical internetworkinterface is dependent on the set of services defined across it andthe manner in which the services may be accessed. The service models are described in Section 4. The NNIs represent vendor-independentstandardized interfaces for control flow between nodes. Thedistinction between the INNI and the ENNI is that the former is aninterface within a given network under a single technicaladministration, while the later indicates an interface at theadministrative boundary between networks. The INNI and ENNI may thus differ in the policies that restrict control flow between nodes. Rajagopalan, et al. Informational [Page 11]Security, scalability, stability, and information hiding areimportant considerations in the specification of the ENNI. It ispossible in principle to harmonize the control flow across the UNIand 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 overthe ENNI. In this case, UNI and NNIs may look different in somerespects. In this document, these interfaces are treated asdistinct.The client-optical internetwork interface can be categorized aspublic or private depending upon context and service models. Routing information (i.e., topology state information) can be exchangedacross 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 orover-lay, Section 5) may occur across private and public logicalinterfaces.The physical control structure used to realize these logicalinterfaces may vary. For instance, for the client-opticalinternetwork 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 towhich it is connected. This control channel is used forexchanging signaling and routing messages between the router andthe OXC. With a direct interface, the edge router and the OXC it connects to are peers with respect to the control plane. Thissituation is shown in Figure 2. The type of routing and signaling information exchanged across the direct interface may varydepending on the service definition. This issue is addressed inthe next section. Some choices for the routing protocol are OSPF or ISIS (with traffic engineering extensions and additionalenhancements to deal with the peculiar characteristics of optical networks) or BGP, or some other protocol. Other directory-basedrouting information exchanges are also possible. Some of thesignaling protocol choices are adaptations of RSVP-TE or CR-LDP.The details of how the IP control channel is realized is outsidethe scope of this document.2. Indirect interface: An out-of-band IP control channel may beimplemented between the client and a device in the optical network to signal service requests and responses. For instance, amanagement system or a server in the optical network may receiveservice requests from clients. Similarly, out-of-band signaling Rajagopalan, et al. Informational [Page 12]may be used between management systems in client and opticalnetworks 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 OXCsand/or clients do not support a direct signaling interface.+---------------------------+ +---------------------------+| | | || +---------+ +---------+ | | +---------+ +---------+ || | | | | | | | | | | || | Routing | |Signaling| | | | Routing | |Signaling| || | Protocol| |Protocol | | | | Protocol| |Protocol | || | | | | | | | | | | || +-----+---+ +---+-----+ | | +-----+---+ +---+-----+ || | | | | | | || | | | | | | || +--+-----------+---+ | | +--+-----------+---+ || | | | | | | || | IP Layer +....IPCC.....+ IP Layer | || | | | | | | || +------------------+ | | +------------------+ || | | || Edge Router | | OXC |+---------------------------+ +---------------------------+Figure 2: Direct Interface3. Provisioned interface: In this case, the optical network services are manually provisioned and there is no control interactionsbetween the client and the optical network.Although different control structures are possible, furtherdescriptions in this framework assume direct interfaces for IP-optical and optical sub-network control interactions.4. IP over Optical Service Models and RequirementsIn this section, the service models and requirements at the UNI andthe NNIs are considered. Two general models have emerged for theservices at the UNI (which can also be applied at the NNIs). Thesemodels are as follows.4.1. Domain Services ModelUnder the domain services model, the optical network primarily offers high bandwidth connectivity in the form of lightpaths. Standardizedsignaling across the UNI (Figure 1) is used to invoke the followingservices:Rajagopalan, et al. Informational [Page 13]。