Why OpenFlow/SDN Can Succeed Where GMPLS ... - Optics InfoBase

yuba.stanford.edu

Why OpenFlow/SDN Can Succeed Where GMPLS ... - Optics InfoBase

Tu.1.D.1.pdfECOC Technical Digest © 2012 OSAWhy OpenFlow/SDN Can Succeed Where GMPLS FailedSaurav Das (1) , Guru Parulkar (1) , Nick McKeown (1)(1) Stanford University, sd2@stanford.eduAbstract OpenFlow & Software Defined Networking (SDN) ideas offer drastically reduced complexityin the control plane, increased programmability and extensibility, and a gradual adoption path; allsignificant advantages over GMPLS for dynamic interaction between packet and circuit networks.IntroductionThe operational benefits of unified control overpacket and circuit networks have long beentouted by industry and academia alike. In fact,GMPLS was designed as a superset of theMPLS control plane protocols to “avoid reinventingthe wheel”; by using existing protocolsand merely extending them for the uniquecharacteristics of the circuit-world. It wasthought that the use of the same protocols couldlead to an intelligent, automated, unified controlplane (UCP) for a variety of technologies –packet, time-slots, wavelengths, and fibers.But GMPLS has failed in terms of actualdeployment in wide area networks. It hasundergone a lengthy standardization process atthe ITU, IETF and OIF; all transport equipmentvendors have implemented it in their switches;there have been many interoperabilitydemonstrations; and yet after a decade, therehasn’t been even one significant commercialdeployment of GMPLS as a UCP.GMPLS may have found use in a limited wayas a tool to help the NMS/EMS provision acircuit after being triggered manually by themanagement system. But we are not interestedin such use of GMPLS. Such use has a) nothingto do with IP networks; and b) nothing to doeven with the ASON view of using GMPLS asan interoperable transport control plane. Ratherthis use of GMPLS is merely a proprietaryvendor implementation of a control plane (inASON parlance - a vendor-island I-NNI).We are not interested in creating a controlplane just for Transport networks. On their own,they do not need intelligent automated control,as they do not provide services that requiredynamic circuit switching. In any case allservices are moving to IP; and it is only the IPnetwork that supports services diverse enoughto benefit from dynamic circuit switching.And so, we are solely focused on creating asimple unified control plane across both packetsand circuits, where the benefits of both switchingtechnologies can be taken advantage of from acommon service standpoint. We believe thatonly architectural change will enable true unifiedcontrol. Accordingly, we propose a controlarchitecture based on Software DefinedNetworking (SDN) ideas 1 . In this paper we offerour perspective on why GMPLS fails as a UCP;and compare it to SDN/OpenFlow to show whythe latter has significant advantages in makingpackets and circuits work together.GMPLS ArchitectureGMPLS is ultimately just a collection of controlprotocols. The IETF also defined threearchitectural-model models for GMPLS usage–peer, overlay and augmented. They differed bythe amount of state that was shared betweenthe IP and transport network: all, none andsome, respectively.The peer model has never found favor. Inprinciple, you could use a single instance ofGMPLS protocols across packet and circuitdomains, treating it as a unified-control-planewith full information sharing between routers andtransport switches (peer model). But this ignoresorganizational boundaries where informationsharing is prohibited; and it increases load on(fragile) routing protocols, which now have todistribute not just packet-switch/link information,but transport-switch/link information as well.What did find favor (at least in otherstandards bodies) is the IETF overlay model,which was formalized by the ITU into its ownarchitectural description for AutomaticallySwitched Optical Networks (ASON). The overlaymodel separates the control of IP and transportnetworks, by treating the IP network as anFig. 1: MPLS/GMPLS/ASON


Tu.1.D.1.pdfECOC Technical Digest © 2012 OSAoverlay network that runs a completely separateinstance of the control plane – i.e. the IP/MPLSnetwork runs the IP/MPLS control plane and thetransport network runs the GMPLS controlplane, and no information about the networks isshared across any boundary/interface betweenthe networks in either direction. A request forservices can be made across an interface (UNI)between the two networks (Fig.1). The transportswitches remain in vendor-islands and continueto be controlled by vendor-proprietary solutions,but those solutions are made to inter-work bylayering GMPLS protocols on top of thosesolutions, via interfaces knows an E-NNI. Arequest made across the UNI is then relayed(and satisfied) across vendor domains in thetransport network via the E-NNI interfaces.The UNI/E-NNI interfaces have not beenused commercially and IP networks today do notrequest transport services dynamically.OpenFlow and Software Defined NetworkingSDN advocates the separation of data andcontrol planes for packet and circuit networks.Packets and circuits can be commonly thoughtof as flows, and the data-plane switches areabstracted and presented to external softwarecontrollersrunning a network operating-system(Fig. 2). All network control logic (such as forrouting, TE, BoD etc.) is implemented asapplications on top of the netOS. The distributednature of the controllers is abstracted away bythe network-OS, so that control applications arewritten with a centralized viewpoint 2 .The applications make control decisions thatmanipulate (via a network-API) an annotatedmap of the network presented to them and keptconsistent by the netOS. In turn the netOStranslates the map-manipulations into dataplanerules by programming the data-planeswitch flow-tables via a switch-API (OpenFlow).The common-map abstraction allows simplerFig. 2: SDN based Unified Control Architecture 1implementation of control-functions; makes iteasier to insert new functionality into a networkwhich is more-programmable; and with a globalviewit affords joint-optimization of functions andservices across packets and circuits 1 .GMPLS vs. OF/SDNIn this section, we discuss shortcomings ofASON/GMPLS, and offer our perspective on theadvantages of the OF/SDN approach:Control Plane Complexity: GMPLS use of theMPLS control plane results in protocols overlycomplex and fragile to make sense as a UCP.Distributed link-state routing protocols likeOSPF or IS-IS have convergence and stabilityissues if network state changes too fast or toooften. This is the fundamental reason why IPnetworks today do not support dynamic links ordynamic link weights. To extend OSPF and useit in a dynamic circuit network with its effectbeing felt by the same or another instance ofOSPF in the packet network is dangerous andunwarranted (and so, no one tries it).Furthermore, the “avoid re-inventing thewheel” argument is simply not true anymore,given the amount of extensions that have goneinto the protocols. Consider RSVP – it wasoriginally intended for hosts to signal forresources from networks in the IntServarchitecture; but then extended to serve as anLSP signaling mechanism in MPLS-TE;extended again to include signaling for transportnetwork LSPs in GMPLS; and modified a thirdtime to support the UNI interface. Everyextension carried baggage from the previousextension increasing code-bloat and complexity.Finally, further increasing the complexity,ASON/GMPLS insists on retaining transportnetwork vendor-islands; layered architecturewithin the transport network; and new interfaces(UNI/E-NNI) to glue them all together. Whileretaining vendor islands and proprietaryinterfaces (and adding GMPLS on top) may helpwith backward compatibility to deployedhardware; in reality it makes the overall solutionso complex that no one tries it in production.In SDN, we eliminate protocols like OSPFand RSVP, interfaces like the UNI, and vendorproprietaryislands and interfaces. We replacethem with a common switch-API (OpenFlow)and a distributed network-OS that make use ofthe distributed-systems techniques for sharingstateamongst multiple servers. In the processwe drastically reduce control-plane complexity.Lack of the common map-abstraction: ASON/GMPLS lack the map-abstraction. As a result –a) services available to the IP network arelimited to the exact service-level definitions


Tu.1.D.1.pdfECOC Technical Digest © 2012 OSAdefined (and pre-baked into the infrastructure)by the UNI interface; and b) the distributedimplementation of network-functions acrosspackets and circuits require lots of glue-code,and patchwork to existing protocols. Togetherthese factors hamper simplicity, extensibility andkill programmability; ultimately limiting its use.The common-map abstraction and network-API (supported by a slicing plane) gives fullvisibility across packets and circuits, andisolates the implementation of network-functionsfrom the state-distribution mechanisms. Weargue that this is the right abstraction: as fullvisibilityallows joint and global optimization ofservices and networking-functions acrosspackets and circuits; and abstracting away thestate-dissemination mechanisms result innetworking-functions that can be implemented ina centralized way, making them simpler andmore extensible.We extended OpenFlow and a network-OS tobuild a prototype and UCP using our SDN basedcontrol architecture 3 . We demonstrated a fairlyinvolved network-application on our prototypeand showed that it takes two orders ofmagnitude lesser lines-of-code compared toexisting solutions.Lack of a gradual adoption path: FinallyGMPLS provides no means for flexible andgradual adoption of a new control plane.Network operators are conservative. Transportnetwork operators would like to respond fasterand provide more dynamic services to meettheir client needs. But at the same time, theyloathe giving up precise manual control over theway traffic is routed over their network to asoftware control plane; irrespective of howintelligent that control plane may be. Additionallyany new control technology has to compete withdecades of established operational procedures.So the real key is to offer a way in which anetwork operator could gradually try out a newtechnology in a slice of the network to gainconfidence in its abilities, while at the same timebeing able to flexibly choose the correct mix oftechnologies for a service.In our control architecture we provide agradual adoption path via incrementaldeployment using a slicing-plane. In slicing, anew control layer is placed between theunderlying switches and the controller-layer.This new control layer (the slicing layer)partitions the underlying data-plane into multipleslices, where each slice can then be put underthe control of different controllers. Circuits in aslice already provide data-plane isolation. Theslicing plane crucially provides control-planeisolation. The transport network operator initiallyslices only a small part of its network and handsover control to an ISP’s controller through itsslicing plane. As long as the slicing planeguarantees isolation of the slices in both thedata and control plane, the transport networkoperator retains control over the unsliced part ofthe transport network which can still be runmanually, using established procedures, as it istoday. Meanwhile the ISP is free to usewhatever automated intelligent controlalgorithms it may desire in its isolated slice ofthe transport network. Over time as moreconfidence is gained in the slicing framework,more parts of the transport network could besliced and offered as a service to other ISPs. Itis worth noting that GMPLS provides no suchmeans for flexible and gradual adoption.Crucially, slicing also enables the ISP to runthe common-map abstraction. The ISP’scontroller creates a common-map of the ISP’spacket switches together with the circuitswitching-resourcesthat are part of its own sliceof the transport network. The (transport serviceprovider’s) slicing plane ensures that this view isrestricted to only the slice that the ISP haspurchased and not the entire transport network.Today, transport networks share no informationand offer only static-bandwidth (dumb pipes).With slicing, transport networks can offer sliceswhich include bandwidth and control ofvirtualized transport-switches to ISPs, therebyoffering a new service.ConclusionsWe find that GMPLS is completely un-usable asa UCP. It is too complex; too buttoned-down, tooinflexible to be of any use from a servicestandpoint across packets and circuits. IPnetworks will not touch it. Transport networksfind little use for it. It’s no surprise that it hasnever been used commercially across packetsand circuits. This is unfortunate, as the benefitsof dynamic-circuit-switching to packet networksare real and tangible and should not beshrouded by the deficiencies of the controlmechanism.We believe that only architecturalchange will enable true interoperation betweenpacket and circuit networks. And so, we proposean SDN based architecture for a UCP as it issimple, extensible, and programmable and canbe gradually adopted.References[1] S. Das, PhD thesis, Stanford University.http://www.openflow.org/wk/index.php/PAC.C[2] S. Shenker et al., “The Future of Networkingand the Past of Protocols”, Open NetworkingSummit 2011.[3] S. Das et al., Proc. OFC/NFOEC’11, NThD3.

More magazines by this user
Similar magazines