Welcome to Scribd. Sign in or start your free trial to enjoy unlimited e-books, audiobooks & documents.Find out more
Download
Standard view
Full view
of .
Look up keyword
Like this
1Activity
0 of .
Results for:
No results containing your search query
P. 1
Combining MPLS Traffic Engineering Control With Optical Crossconnects

Combining MPLS Traffic Engineering Control With Optical Crossconnects

Ratings: (0)|Views: 13|Likes:
Published by ivsvarun

More info:

Categories:Types, Research, Science
Published by: ivsvarun on Aug 20, 2012
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

11/05/2013

pdf

text

original

 
111
IEEE Communications Magazine • March 2001
Multiprotocol Lambda Switching:Combining MPLS Traffic EngineeringControl with Optical Crossconnects
0163-6804/01/$10.00 © 2001 IEEE
 A 
BSTRACT
This article describes an approach to thedesign of control planes for optical crosscon-nects which leverages existing control planetechniques developed for MPLS traffic engineer-ing. The proposed approach combines recentadvances in MPLS traffic engineering controlplane constructs with OXC technology to pro- vide a framework for real-time provisioning of optical channels, foster development and deploy-ment of a new class of OXCs, and allow the useof uniform semantics for network managementand operations control in hybrid networks con-sisting of OXCs and label switching routers. Theproposed approach is particularly advantageousfor OXCs intended for data-centric optical inter-networking systems.
I
NTRODUCTION
This article describes an approach to the designof control planes for optical crossconnects(OXCs), which is based on the multiprotocollabel switching (MPLS) traffic engineering con-trol plane. The main idea is to leverage recentadvances in control plane technology developedfor MPLS traffic engineering [1–6]. Thisapproach is driven by pragmatic considerations,since it exploits an existing technology base tofoster rapid development and deployment of anew class of OXCs that address the optical trans-port needs of the Internet. This approach willassist in optical channel layer bandwidth man-agement, dynamic provisioning of optical chan-nels, and network survivability through enhancedprotection and restoration capabilities. As used in this article, an OXC is a pathswitching element in an optical transport networkthat establishes routed paths for optical channelsby locally connecting an optical channel from aninput port (fiber) to an output port (fiber) on theswitch element. Additional characteristics of OXCs, as used in this article, are discussed later.The proposed OXC control plane uses theInternal Gateway Protocol (IGP) extensions forMPLS traffic engineering (with additionalenhancements) to distribute relevant opticaltransport network state information, includingtopology state information. This state informationis subsequently used by a constraint-based routingsystem to compute paths for point-to-point opti-cal channels. The proposed OXC control planealso uses an MPLS signaling protocol [3,4] toinstantiate point-to-point optical channels.This article does not specify the details of theextensions and domain-specific adaptationsrequired to map the MPLS traffic engineeringcontrol plane onto the optical domain. However, we provide a high-level overview of the architec-tural issues involved in making such adaptationsin a later section.
 A 
DVANTAGES
The advantages of the proposed approach arenumerous:It offers a framework for optical bandwidthmanagement and the real-time provisioningof optical channels.It exploits recent advances in MPLS controlplane technology and also leverages accu-mulated operational experience with IP dis-tributed routing control.It obviates the need to reinvent a new classof control protocols for optical transportnetworks and allows reuse of software arti-facts originally developed for the MPLStraffic engineering application. Consequent-ly, it fosters the rapid development anddeployment of a new class of OXCs.It facilitates the introduction of control coor-dination concepts between data network ele-ments and optical network elements.It simplifies network administration in facil-ities-based service provider networks byproviding uniform semantics for networkmanagement and control in both the dataand optical domains.It paves the way for the eventual introduc-tion of DWDM multiplexing capabilities onIP routers.
Daniel Awduche, Movaz NetworksYakov Rekhter, Juniper Networks
O
PTICAL
P
ACKET
S
WITCHING
N
ETWORKS
 
112
IEEE Communications Magazine • March 2001
Lastly, it establishes a preliminary frame- work for the notion of an optical Internet.
B
 ACKGROUND
The growth, performance, and survivabilityrequirements of the Internet are mandating IP-centric networks to be cost effective, survivable,and scalable, and to provide control capabilitiesthat facilitate network performance optimiza-tion. Some of these requirements are beingaddressed by the multiprotocol label switching(MPLS) traffic engineering capabilities underdevelopment by the Internet Engineering TaskForce (IETF) [1–4].The underlying optical transport network alsoneeds to be versatile, reconfigurable, and costeffective, and to support a variety of protectionand restoration capabilities due to the rapidlychanging requirements of the Internet. A result of these trends, therefore, is the evo-lution of optical transport networks from simplelinear and ring topologies to (partial) meshtopologies.Underscoring the importance of versatile net- working capabilities in the optical domain, anumber of standardization organizations haveinitiated work items to study the requirementsand architectures for reconfigurable optical net- works. For example, International Telecommuni-cation Union — TelecommunicationStandardization Sector (ITU-T) Recommenda-tion G.872 [7] speaks of an optical transport net- work (OTN) as “a transport network boundedby optical channel access points.” The ITU-TG.872 OTN architecture is based on a layeredstructure, which includes:An optical channel (OCh) layer networkAn optical multiplex section layer networkAn optical transmission section layer net- workThe OCh layer is the most relevant to thediscussions in this article. The OCh layer net- work supports end-to-end networking of opticalchannel trails between access points. The OChlayer network provides the following functions:routing, monitoring, grooming, and protectionand restoration of optical channels. In this situa-tion, programmable OXCs will be critical to therealization of the OCh layer functions, especiallyin mesh optical networks.Other standards organizations and interoper-ability forums actively pursuing projects relatedto dynamically reconfigurable optical networksinclude the American National Standards Insti-tute (ANSI) T1X1.5 committee, the OpticalInternetworking Forum (OIF), and the IETF.In all these cases, the successful realization of the vision of versatile optical networking depends very much on the synthesis of appropriate con-trol plane technologies with programmable andreconfigurable OXCs.
OXC
S
, LSR
S
, O
PTICAL
T
RAILS
,
 AND
E
XPLICIT
LSP
S
Consider a hybrid IP-centric optical internet- working environment consisting of both labelswitching routers (LSRs) and OXCs, where theOXCs are programmable and support wave-length conversion/translation. At a level of abstraction, an LSR and anOXC exhibit a number of isomorphic relations.Enumerating these relations exposes thereusable software artifacts from the MPLS traf-fic engineering control plane model. Architec-turally, both LSRs and OXCs emphasizeproblem decomposition by decoupling the con-trol plane from the data plane.The data plane of an LSR uses the labelswapping paradigm to transfer a labeled packetfrom an input port to an output port [8]. Thedata plane of an OXC uses a switching matrix toconnect an OCh trail from an input port to anoutput port. An LSR performs label switching by firstestablishing a relation between an <input port,input label> tuple and an <output port, outputlabel> tuple. Likewise, an OXC provisions OChtrails by first establishing a relation between an<input port, input optical channel> tuple andan <output port, output optical channel> tuple.These relations are determined by the controlplane of the respective network elements, andare locally instantiated on the device through aswitch controller.The functions of the control plane (for bothLSRs and OXCs) include resource discovery,distributed routing control, and connection man-agement. In particular, the control plane of theLSR is used to discover, distribute, and maintainrelevant state information associated with theMPLS network, and to instantiate and maintainlabel switched paths (LSPs) under various MPLStraffic engineering rules and policies. An LSP isthe path through one or more LSRs followed bya specific forwarding equivalence class [8]. Anexplicit LSP is one whose route is defined at itsorigination node.The control plane of the OXC, on the otherhand, is used to discover, distribute, and main-tain relevant state information associated withthe OTN, and to establish and maintain OChtrails under various optical traffic engineeringrules and policies. An OCh trail provides apoint-to-point optical connection between twoaccess points. At each intermediate OXC alongthe route of an OCh trail, the OXC switch fabricconnects the trail from an input port to an out-put port. A distinction between OXCs and LSRs isthat the former do not perform packet-levelprocessing in the data plane, while the latterare datagram devices which may perform cer-tain packet-level operations in the data plane. A significant conceptual difference is that withLSRs the forwarding information is carriedexplicitly as part of the labels appended to datapackets, while with OXCs the switching infor-mation is implied from the wavelength or opti-cal channel.In this article we use the generic term OXCto refer to all categories of programmable andreconfigurable crossconnects for OTNs, irrespec-tive of the technologies that underlie them.The OXC control plane design approachdescribed in this article is independent of theunderlying OXC switch technologies. It is alsoindependent of specific OXC implementation
The requirementsof the Internetare mandatingIP-centricnetworks to becost effective, survivable,and scalable, and to provide control capabilities thatfacilitate network performanceoptimization.
 
IEEE Communications Magazine • March 2001
113
details. Local adaptation mechanisms can beused to tailor the control plane onto variousOXC implementations with different hardwarecapabilities. As an example, a local adaptationfunction can map a channel/port input/outputrelation into specialized low-level instructions toactuate a rearrangement of the crossconnectswitch fabric such that the required input/outputrelation is realized.
E
XPLICIT
LSP
S AND
O
PTICAL
C
HANNEL
T
RAILS
 At a conceptual level, explicit LSPs and opticalchannel trails exhibit certain commonalities.Essentially, they are both fundamentally unidi-rectional point-to-point path connection abstrac-tions. An explicit LSP provides a parameterizedpacket forwarding path (traffic trunk) betweenan ingress LSR and an egress LSR. Correspond-ingly, an OCh trail provides a (possibly parame-terized) OCh between two endpoints for thetransport of client digital signals.The payload carried by both LSPs and opticaltrails are transparent to intermediate nodesalong their respective paths. Both LSPs and opti-cal trails can be parameterized to stipulate theirperformance, behavioral, and survivabilityrequirements from the network. A constraint-based routing scheme can beused to select appropriate paths for both LSPsand optical trails. Generally, such paths may sat-isfy some demands and policy requirements sub- ject to some constraints imposed by theoperational environment.
G
ENERIC
R
EQUIREMENTS FOR THE
OXC C
ONTROL
P
LANE
This section contains the requirements for theOXC control plane, with emphasis on the rout-ing components of these requirements. Thereare three key aspects to these requirements:The capability to establish OCh trails expe-ditiously (in seconds or even millisecondsrather than days or months).The capability to support traffic engineeringfunctions — the introduction of dense wavelength-division multiplexing (DWDM)and automatically switched optical networksis unlikely to eliminate the need for trafficengineering. Instead, it will simply mandateOXCs to also support some traffic engi-neering capabilities.The capability to support various protectionand restoration schemes.Historically, the “control plane” of OTNs hasbeen implemented via network management.This approach has the following drawbacks:It leads to relatively slow convergence fol-lowing failure events (typical restorationtimes are measured in minutes, or evendays and weeks, especially in systems thatrequire explicit manual intervention). Theonly way to expedite service recovery insuch environments is to preprovision dedi-cated protection channels.It complicates the task of interworkingequipment from different manufacturers,especially at the management level (gener-ally, a custom umbrella network manage-ment system, NMS, or operations supportsystem, OSS, is required to integrate other- wise incompatible element managementsystems from different vendors).It precludes the use of distributed dynamicrouting control capabilities in such environ-ments.It complicates the task of internetwork pro- visioning (due to the lack of EDI betweenoperator NMSs).Thus, another important motivation for theapproach described in this article is to improvethe responsiveness of the optical transport net- work, and to increase the level of interoperabili-ty within and between service provider networks.
MPLS T
RAFFIC
E
NGINEERING AS A 
G
ENERIC
C
ONTROL
P
LANE FOR
OXC
S
The requirements for the OXC control planedescribed in the previous section have already beenaddressed by the MPLS traffic engineering controlplane, under development by the IETF [1–6].
 A 
N
O
VERVIEW OF THE
MPLS T
RAFFIC
E
NGINEERING
C
ONTROL
P
LANE
The MPLS traffic engineering control plane is asynthesis of new concepts in IP traffic engineer-ing (enabled by MPLS) and the conventional IPnetwork layer control plane. The high-levelrequirements for traffic engineering over MPLS were articulated in [1]. It is the combination of the notions defined in [1] with the conventionalIP control plane constructs that effectively estab-lishes a framework for the MPLS traffic engi-neering control plane model [1; see also 2]).The MPLS traffic engineering control planeincludes the following components:Resource discovery.State information dissemination, which isused to distribute relevant information con-cerning the state of the network, includingtopology and resource availability informa-tion. In the MPLS context, this is accom-plished by extending conventional IP linkstate routing protocols to carry additionalinformation in their link state advertise-ments [5–6].Path selection, which is used to select anappropriate route through the MPLS net- work for explicit routing. It is implementedby introducing the concept of constraint-based routing, which is used to computepaths that satisfy certain specifications sub- ject to certain constraints, including con-straints imposed by the operationalenvironment [1].Path management, which includes label dis-tribution, path placement, path mainte-nance, and path revocation. These are usedto establish, maintain, and tear down LSPsin the MPLS context. The label distribu-tion, path placement, and path revocationfunctions are implemented through a sig-naling protocol, such as the ResourceReservation Protocol (RSVP) extensions[3] or constraint routed label distributionprotocol (CR-LDP) [4].These components of the MPLS traffic engi-
 A constraint-based routing scheme can beused to selectappropriate pathsfor both LSPs and optical trails.Generally such paths may satisfy  some demandsand policy requirements subject to someconstraintsimposed by theoperational environment.

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->