SoftwareDefinedNetworkingfornextgenerationconvergedmetro-accessnetworksM.Ruffini,F.Slyne,C.Bluemm,N.Kitsuwan,S.McGettrick.CONNECT/TheCentreforFutureNetworksandCommunications,UniversityofDublin,TrinityCollege,Ireland.

AbstractWhile the concept of Software Defined Networking (SDN) has seen a rapiddeployment within the data centre community, its adoption intelecommunications network has progressed slowly, although the concept hasbeen swiftly adopted by all major telecoms vendors. This paper presents acontrol plane architecture for SDN-driven converged Metro-Access networks,developedthroughtheDISCUSEuropeanFP7project.TheSDN-basedcontrollerarchitecture was developed in a testbed implementation targeting two mainscenarios:fastfeederfibreprotectionoverdual-homedPassiveOpticalNetworks(PONs) and dynamic service provisioning over a multi-wavelength PON.Implementation details and results of the experiment carried out over thesecond scenario are reported in the paper, showing the potential of SDN inprovidingassuredon-demandservicestoend-users.

IntroductionTheconceptofSoftwareDefinedNetworkinghas,afteronlyafewyearsfromitsfirst appearance [1], brought considerable changes in the technical andeconomicaloutlookofcomputernetworkingandtelecommunicationsnetworks.The concept was swiftly adopted in data centres, whose private networkoperationsconstitutedthe ideal incubator forsuchtechnology,withmanynewstartupcompaniescomingtolifeinthepastfiveyears.WhiletheacceptanceofSDN by operators and the wider telecommunications industry should not betaken for granted, SDN remains very popular among the networking researchcommunityandalmosteveryswitchandroutervendorhastodayimplementedsome sort of SDN interface, with many also providing an OpenFlow (OF)interface. IndeedsomeWideAreaNetworkSDNimplementationsalreadyexist,most notably the two intercontinental backbone networks interconnectingGoogle’s data centres [2]. While it could be argued that Google’s backbone,althoughintercontinental,isstillaprivatenetwork,withoutthecomplexityofanoperatorpublicInternetnetwork,itprovesthesuitabilityoftheSDNframeworkto operate as network controller for one of the largest revenue generatingServiceProviders(SPs)intheworld,handlingover100PBofdailydata[3].WhiletheSDNconcepthasnotyetreceivedfullattentioninaccessnetworks,anumberofpublicationshaveshownthesignificantadvantage theycouldbring.Recent work has targeted for example, problems such as video distributionoptimization [4], and the application of flexi-grid transmission in access andaggregation networks [5]. In addition, operators have recently started torecognise SDN’s potential as an enabler of new added-value services in theaccess.Verizon[6]forexamplehasdrawnupanumberofusecaseswhereSDN

couldhelpgeneratenewrevenue: from increasingqualityof service (QoS)anddevelopmentofnewaddedservicestobroadbandusers,todynamicprovisioningofleasedlineservicesandprotectionagainstfailureforenterpriseusers.Following from this trend, in this paper we argue that SDN could indeedrevolutionizeaccessnetworks,byenablingmuchfasterprovisioningofservicesandcapacitymanagement.AsSDNblurstheconventionallinebetweenfunctionscarriedoutbythecontrolplaneandthosecarriedoutbythemanagementplane,we believe that much benefit can be gained by moving some managementfunctionstoadynamicSDN-basedcontrolplane.Inaddition,webelievethatSDNwillhelpadvancenetworkconvergenceintwocomplementary domains: the service domain, allowing multiple and diverseservice type to converge into the same physical access infrastructure; and theownershipdomain, creating amulti-tenancy environment that allowsdifferentnetworkoperatorsandserviceprovidertooperateoverthesamenetwork,withdifferent degrees of access control, thus enabling sharing of capital andoperationalexpenditures.Serviceconvergencehasalreadybeenwidelydiscussed[7],andtypicallyfocusedonfixed-mobileconvergence.Whilethisisnotoverlychallengingforbackhaulingcurrentmobilenetworks (e.g.,3GandLomgTermEvolution -LTE), challengesstart to appearwhen considering specific featuresof LTE-Advanced,withone-way delay requirements between eNodeB and Gateway of around 1 ms (e.g,implementingtechniquessuchasInter-CellInterferenceCoordination(ICIC)andCoordinated MultiPoint (CoMP)) [8]. The challenge becomes even moreproblematic when considering front-hauling which requires one-way delaybelow250μs[9]: theultra tight latencyconstraintandtheultra largecapacitydemandsoftenrequiressubstantialalterationstoaccessnetworkarchitectures,although some reliefs, at least on the capacity requirements, has recentlyappearedwiththeproposalofsplitprocessingofthephysicallayer[10].Fromanetworkownershipperspective, sharingnetwork infrastructureamongmultiple operators and service providers enables cost sharing, as theinfrastructure owner can chargemultiple operators for its usage. Studies [11]have shown that the cost per home connected through Fiber-to-the-home(FTTH) can decrease by 65% when three operators share the PONinfrastructure. In addition, the ability to share network resources on demandand dynamically is important to increase the efficiency of resource usage, andthe overall number of services delivered through the same physicalinfrastructure, leading to increased overall revenue. This activity has recentlybeen taken up in a study group by the Broadband Forum (BBF), which iscurrentlyconsideringoptionsforaccesssharingandvirtualization.Moredetailscanbefoundin[12].In summary, we believe that implementing SDN in the access will bringadvantage to any operator, as the improved programmatic control and theadoptionofopeninterfaceswillfosterthecreationofnewaddedvalueservices,as well as reduction in complexity of network operation. We also argue thatdeveloping open-access interfaces will allow further exploitation of the ultrahigh capacity of the fibre access network, creating the possibility for more

operators and providers to develop their own services on top of the sharedinfrastructure. Indeed open-access networking is a concept that is perfectly inline with the SDN philosophy, as it provides a natural framework for thedevelopmentofopeninterfaces.In the remainderof thepaperwe firstdescribe relatedworkand the researchroadmapthathasconductedtodevelopmentofSDNnetworkcontrolplanes.Wethen describe a possible SDN access network architecture, developed throughthe FP7DISCUS project [13],[14].We then present testbed results of dynamicservice provisioning on converged metro/access nodes using next generationPONs.Finallyweconcludethepaper.

StateoftheartWhilethetermSDNwasonlycoinedfollowingthedevelopmentofOpenFlowin2008,someoftheconceptsitpromoteshadbeenaroundformuchlongerwithinthe research community. The idea of separating control and data planes hadbeen alreadyproposed in the literature, for examplewith the Forwarding andControlElementSeparation(ForCES)concept[15],theRoutingControlPlatform(RCP) [16] and the 4D architecture [17] (for a comprehensive overview ofroadmaptoSDNthereadercanreferto[18]).ThereasonbehindthesuccessofOpenFlowoverthepreviousincarnationswasthe idea of designing the architecture around a set of standardized openinterfaces [19] operating via OpenFlow instructions that are compatible withexistinghardwareswitchingchips.Thus,acompanycouldlaunchanOpenFlow-enabled switch in themarket bywritingnew firmware to an existingproduct,i.e.,withoutrequiringdevelopmentofnewhardware.Inaddition,SDNbringsarchitecturalnoveltybydevelopingopeninterfacesthathavefosterednetworkprogrammability,asthecontrolplaneisnowhostedonacommodity PC, is typically open source and is developed using well-knownprogramming languages. Instead of relying on specific vendor interfaces, oftentoo restrictive to allow operators to develop significantmodificationswithoutassistance form the vendor, OpenFlow makes control plane programmabilityhighlyaccessible.Suchaccessibilitywasfurtherendorsedbythedevelopmentofanumberofnowwell-establishedOpenFlowcontrollers,suchasONOS,Beacon,Floodlight and Opendaylight, developed in Java; Ryu and POX, developed inpython;NOX,inC++,Trema,developedinruby,andmanymore.InadditionthedevelopmentofOpenFlow-enabledsoftwareswitcheshasgiventheopportunityto any researcher around theworldwith a commodity PC to develop and testapplicationsforcontrollersevenformediumcomplexitynetworksusingvirtualmachinesandnetworkemulators (e.g.,Mininet),while thesamecodecan thenbereusedtooperateonhardwareswitches.In addition, we should remark that the idea of centralizing the networkintelligencehasalreadybeenwidelydeployedbyoperators.Indeed,inordertogaincontroloftheirnetworkandcarryoutoperationssuchastrafficengineeringor offering bandwidth transport services, operators make ample use of MultiProtocol Label Switching / Generalised Multiprotocol Label Switching(MPLS/GMPLS) tunnels.WhileMPLS/GMPLSusesdisseminationprotocols that

can be distributed, the routing decision is oftenmade centrally by a networkmanagementlayer.Besides currentlybeingwell accepted indata centreenvironments, in thepastcoupleofyearstheresearchcommunityhasstartedconsideringSDNasaviableoption for metro [20], and core telecommunications networks [21],[22]. Mostpopular solutions have seen SDN taking up the role of network orchestrator[23],[24],coordinatingexistingprotocolsatdifferentlayersofthenetwork.Forexample recent scenarios have seen the integration of an extended OpenFlowcontrollerforpacketswitcheddatawithaGMPLScontrollerforopticalswitchingandtransmission[25].Inaddition,thelogicallycentralizedstructureofSDNhasbeenlikenedtotheoperatingsystemofapersonalcomputer,fosteringtheideaofNetworkOperatingSystem(NOS)[26],[27].Although theconceptofSDNandnetworkvirtualizationare independent, theyareinpracticehighlycorrelated,astheprogrammableSDNframeworkwellsuitsthe dynamic creation and control of virtual slices of a given networkarchitecture. TheEuropeanTelecommunicationsStandardsInstitute(ETSI)forexample,hasdefinedanumberofusecasesforNetworkFunctionVirtualisation(NFV)services[28].TheseusecasesrelatetotheprovisionofvirtualCustomerPremises Equpment (vCPE), Fixed Access Network Function Virtualisation,virtualProviderEdge(vPE)andvirtualBasestation(vBS).Inadditiontheyhavedevelopeda framework for themanagementandorchestrationofall resourcesin theNFVenvironment, dubbedMANO [29], covering computing, networking,storage,andvirtualmachine(VM)resources.

ArchitectureThe architecturewehave chosen for our SDN control plane implementation isshowninFigure1,anditisbasedonahierarchicalstructureofcontrollers.Thenotionofhierarchicalcontrollerarchitecturehasrecentlybecomeestablishedinthe research community: besides having made its appearance in the OpenNetworkingFoundation (ONF)SDNarchitecturedocument [30], theconceptofnetworkorchestrationappearsfrequentlyinliterature[31],[32],[33].The main benefit of the hierarchical architecture with respect to a federatedarchitecture (see [34] for an example of a virtualization-capable federatedarchitecture)isthatitisinlinetothetypicalcentralizedstructureofSDN,asthenetwork orchestrator can act as the central reference controller. However,wheremultiplenetworkdomainsareinvolved,acompletehierarchicalapproachmight not be feasible and a hybrid hierarchical/federated solution might berequired.It should benoted that this architecturalmodelwas developed specifically fortheDISCUSarchitecture[13],summarizedinFigure2.InthisviewwedevelopedtheconceptofaMetro-Core(MC)node,whichconnectsononesidedirectly toend users, through a Long-Reach PON access that bypasses the metrotransmissionnetwork;andon theotherside toa transparentcorenetwork,oroptical island, linking all MC nodes to each other. Although this enables asimplifiedviewofthecontrolarchitecture,wecanseethatahierarchicalcontrol

plane structures similar to that shown in Figure 1 has been employed for anumberofdifferentnetworkscenarios[35].

Figure1Overallhierarchicalcontrolpanearchitecture

Figure2DISCUSarchitecture,basedonlong-reachpassiveopticalnetworkaccessandaflatopticalcore.

Looking at Figure 1, we can identify three main logical components for thenetworkcontrolplane:theaccessnetworkcontroller,inchargeofcontrollingtheaccessnetwork elements; the corenetwork controller, in chargeof controllingtheelementscarryingoutcoretransmission;thenetworkorchestrator,inchargeoftakingrequestsfromtheServiceProvider(SP)andtranslatingthemintohigh-

level commands for the access and core network controllers. In addition, itshouldbenotedthattheorchestratorisalsothemaininterfacetotheNetworkManagement System (NMS) and the Operation Support System (OSS), all withdifferentaccessrightstotheOrchestratorAPIs.Followingthishierarchicalarchitecture,anyservicerequest issentbyanSPtothe orchestrator, which calculates a high-level path in the network and thenconvertstheservicerequestiterativelyintosubrequeststowardsthesourceanddestinationaccessnetworkcontrollersandthecorenetworkcontroller.While Figure 1 only shows a high level view of the Metro-Core node, a moredetailed view is reported in Figure 3. In orangewe show the access elementscontrolled by the access network controller, while in green the elementscontrolledbythecorecontroller.InlightbrownareinsteadtheIP/MPLSservicenodesthatmightbecontrolledbyindividualServiceProviders.ThesemightnotbephysicallylocatedwithintheMCnodehousing,andareconnectedtothroughthe optical switch. Their interface is then terminated to the access switch thatwill appropriately break the incoming flows into those directed towards theaccess served by this MC node and those directed towards other MC nodes,whichareforwardedtotheMPLS-TP(TransportProfile)coreswitch.Theopticalswitchistheelementthatprovidesflexibilitytothearchitecture,constitutingthecore element of the node that enables flexible any-to-any connectivity of thecomponents1. Due to the large port number,which can be of the order of tenthousandforthelargestnodes,theswitchisdevelopedasa2-stagearchitecturebuiltusingsingle-sidedswitchingcomponents.The switch is virtualized into two sides, one connecting access equipment andtheotherthecoreequipment,eachmanagedbytherespectivecontroller.

1While any-to-any connectivity provides the highest flexibility it is envisaged that such highdegreeoffreedommightnotberequiredandconstraintscouldbeincludedinordertoreducetheoverallnumberofswitchingelementsrequiredtooperatethemulti-stagearchitecture.

Figure3DetailedviewoftheMetro-Corenodearchitecture

From a transport network switching and routing perspective, the data planeoperatesontwosetsofstackedMPLSlabels.Thefirstset,thePseudoWire(PW)identifies an end-to-end path, and is assigned to a specific service type (e.g.,videoondemand, Internet,VoIP,BandwidthonDemand)andit isuniqueforagiven SP and destination OLT. The SP then aggregates multiple PWs, fortransport purposewithin the core network, into a Label Switched Path (LSP),which is used to route the packet through the network core. An SP can havemultiple LSPs, at least one per source-destinationMCnode pair, butmore arepossible in order to operate service level distinction. An example of serviceimplementation throughLSPandPW is shown inFigure4.Foragivenserviceflow, theSP installsaPW label into thepacketsheader. It thenaggregates thisflow together with other flows going towards the same destination using acommonLSP label.Packetsare then forwarded to theMCnodewhere theLSPlabelisexaminedtodeterminewhethertheaggregateflowistobeprocessedatthis node or forwarded through the core towards a different MC node. Onceforwarded to the correctMC node, the LSP label is stripped off by the accessswitch, which uses the PW label to determine QoS behavior of individual PWflowsandreachthecorrectOLT.TheOLTthenstripsoffthePWlabelforwardingthepackettotheONU.

Figure4ExamplesofserviceimplementationthroughLSPandPWMPLSlinks

AccessnetworkcontrollerThissectionprovidesanoverviewoftheaccessnetworkcontrollerarchitectureandsummarisesthemaintaskscarriedoutbytheaccesscontroller.Itshouldbenoted that our work so far has covered the use of SDN-based controller fordynamicserviceprovisioning,while thedevelopmentofanSDNframeworkforopen access and virtualisation-enabled access network architecture will betargetedinfuturework2.Thedifferentiationbetween thenetworkorchestrator and the access and corecontrollersisonlylogical,meaningthatfromaphysicalpointofviewallsoftwarecomponentsmightbeco-located(i.e.,inthesamedatacentre,servers,machine,etc.) or reside somewhere in the cloud. An access network controller isassociatedtoeveryMCnode,whereitcontrolstheopticalswitch,accessswitch,andOLTs/ONUs.Figure 5 shows a schematic of the node controller architecture and itsinteractionwith thenetworkorchestrator.A JavaScriptObjectNotation (JSON)interface forwarding RESTful (i.e., using Representational State Transfer) API(ApplicationProgram Interface) isused to communicatewith theorchestrator,which,where required, calculates end-to-endpaths and then requests them tothedestinationnodecontrollers.

2ThisworkwillbetargetedthroughtheScienceFoundationIrelandfundedproject“O’SHARE:Anopen-accessSDN-drivenarchitectureenablingmulti-operatorandmulti-serviceconvergenceinsharedopticalaccessnetworks”(projectID:14/IA/2527).

Figure5Accessnetworkcontrollerarchitecture

After receiving a request from the orchestrator, the JSON interface passes theinformationtothemaincontrollerprocessingblock,whichchecksthedatabaseforavailablecapacityandports.Topologyinformation,togetherwithbandwidthreservationinformationisstoredinthedatabase.Iftherequestcanbesatisfied,the controller sends a confirmation to the SP/orchestrator and instructs theprovisioning manager to carry out the appropriate actions to create theconnection on the access side. The provisioningmanagement block translatesthe incoming actions into messages for the appropriate protocol that can behandled by the physical devices. Our architecture uses OpenFlow as DeviceController Plane Interface (D-CPI, also known as southbound interface). Theaccess switch uses the embedded OpenFlow interface, while for the opticalswitch and OLTwe have developed an OpenFlow agent based on the OF v1.4standard.Thegreyblocksincludeprotocolsandmodulesusedtomaintainandmanageamap of the network topology, and includes both NETCONF and SNMP forbackwardcompatibility.Themaintaskscarriedoutbytheaccessnetworkcontrollercanbesummarisedasfollows:

• Maintain communication with the network orchestrator. The accesscontroller receives provisioning requests from the orchestrator andreportstheservicesetupstatus.

• Export abstracted network view to the controllers. The accesscontroller sends abstracted topological information about the resourcesavailablewithin itsdomain.Todoso, thephysicaldomaindetailshavetobemappedintheabstractedinformationrequiredbytheorchestrator.

• Operate QoS of individual or aggregate flows. The access controlleroperates connection Admission Control (CAC) mechanisms and capacityreservation.

• Handlenetworkcapacitymanagementwithintheaccess-aggregationnetwork. The access controller maintains information on bandwidthavailabilitywithin the access switch and eachOLT. Each new connectionrequestisassessedagainstthebookedCommittedInformationRate(CIR)ateachoutputportoftheswitch,andattheOLTs(althoughmanagingOLTdownstreamcapacity isnot requiredwhere the switchport ratematchesthe downstreamOLT rate). It alsomaintains connectivity information onthe optical switch and on the number of OLTs and point-to-pointtransceiversavailable.

• Translate the abstract link parameters into appropriate commandsfortheD-CPI(southbound)interface.Asummaryofthemainparametersinclude:

o Fortheaccessswitch:settingup,modifyinganddeletingflowentries,setupmeter tables for QoS (priority tagging), MPLS and VLAN flowtagging,forwardingactions.

o FortheOLT:GPONEncapsulationMethod(GEM)portsandVLAN/PWmapping/translation,DBAalgorithmconfiguration(e.g.,fixed,assuredandbesteffortrates),downstreamwavelengthselection3.

o For theoptical switch: connect/disconnectports, incoming/outgoingportpowermeasurement.

o For theONU/ONT:Messages fromtheOLT to theONUaregenerallysupported through the ONT Management and Control Interface(OMCI). Our implementations requires exchange of information onTraffic Container (T-CONT)/GEM ports and C-VLANmapping/translation, downstream/upstream wavelength selection,OLTregistrationandONUconfigurationparameters.

• Access network protection. Where access protection is required, thecontrollerhandlesincomingfailuremessagesfromtheOLTtooperatefastprotection. While our implementation targets specifically feeder fibreprotectionandthusisbasedonLossOfSignal(LOS)alarmsfromtheOLT,more sophisticated failure detection systems can be implemented in thesystem.

ControllerimplementationandtestingTheaccessnetworkcontrollerarchitecturedescribedabovewasimplementedasacontrolmechanismfortheDISCUSMetro-Corenode.Whileacompletecontrolplaneimplementationwasoutofthescopeoftheproject,wehaveimplementedanumberoffunctionalitiestoaddresstwomainscenarios:

3Itisassumedthereceiverfilterisoperatedbythewavelengthdemultiplexer.

1) Thesetupofaservicewithguaranteedcapacity(e.g.,forVideoOnDemandormoregeneralBandwidthonDemandservices).

2) AfastfeederfibreprotectionmechanismwithN:1sharingofbackupOLTs.

Our access SDN controller was implemented on the RYU OpenFlow platform,which provides software components with well-defined APIs to enable thedevelopmentofnewnetworkmanagementandcontrolapplications.Itsupportsseveralprotocolsformanagingnetworkdevices,suchasOpenFlow(versions1.0,1.2,1.3,and1.4),NetConf,andOF-config.Figure 6 shows the interaction of the control plane components implementingthefirstscenario.Whileourimplementationhasfocusedontheaccessnetworkcontroller,wehaveimplementeda lightweightnetworkorchestrator, tohandlecommunication to/from the SP (shown in the figure as a Web Portal) andto/from the access controller.We have also implemented a simple OpenFlow-based core controller to enable testing of scenarios through Openflow corenetworks (for example scenario 2 was tested through the core Europe-wideGEANTOpenFlownetwork).Forthefirstscenarioweassumethataportalexistswheretheusercansubmit(step 1) a service request indicating the service type (committed and peakcapacity, wavelength range and channel allocation type – e.g., shared vs.dedicated),anddestination.TherequesttotheportalispassedtotheSP,whichforwardstherequesttothenetworkorchestrator(step2).Theorchestratorfindstheaccessnodecontrollerwhere the user is located and forwards the request (step 3). The accesscontroller needs to assess how the capacity can be provided to the user,consideringthepreferencesandabilitiesexpressedbytheuser.Forexampletheusermightrequirecapacityonasharedchannel,butthecurrentchannelmightnot have enough capacity to satisfy the request. The user’s ONU can thus bemovedtoadifferentchannel,providedit isabletotunetooneof theavailablechannels.Ifthecapacityisavailabletheaccesscontrollerproceedstoconfiguretheaccess switch,OLTandONU to carryout the connection (step5) and thenconfirms the service request to the orchestrator (step 6). The orchestratorconfirmstherequesttotheSP,whichwillpasstheinformationtothewebportaltogivefeedbacktotheuser(step7).Themain scopeof this scenario is to show thedynamicprovisioningof anewend-to-endpathacross thenode, thuscreatinganewflowentry(comprisedofPseudowire (PW) and Label-Switched Path (LSP) tags, as required) and alsousingmulti-wavelengthsallocationinthePON.ThisscenarioassumesthatusertrafficisterminatedattheMCnode,i.e.doesnotcrosstransparentlythenode4.FurtherdetailsontheenvisagedAPIinterfacescanbefoundin[36].

4Due to the high loss of the PON section, the signal is regenerated and then groomed intoappropriatecoretransmissionchannels.

Figure6Scenario1:dynamicprovisioningofbandwidth-on-demandservices

ThesecondscenariodemonstratesfastPONprotectionagainstcutsofthefeederfibre. The PON is protected by a backupOLT that is located at a differentMCnodeinordertoprovidediversityoffibrepathandOLTlocation.N:1protectionisachievedbyconnectingthefeederfibresandOLTstotheopticalswitch(asinFigure3),sothatanystandbyOLTcanprotect forany feeder fibre failure.TheN:1 value determines the ratio of active to standby OLTs, obtained byoversubscribingthenumberofstandbyOLTsoverthenumberoffeederfibrestobeprotected.Thisconceptwastheoreticallyinvestigatedin[37].While it is debatable whether fast feeder protection is required for an accessnetworkmainlyservicingresidentialcustomers,wearguethatthecurrenttrendtowardsserviceconvergenceinaccessnetworkswillposestrictrequirementsontheoverallnetworkavailability.Forexample,thesamePONfibrecouldprovideboth residential and business services (such as private lines or back-hauling/front-hauling of mobile stations), which might require Service LevelAgreements (SLA) with high network availability. In addition, fast feederprotectioncanenableprotectionsharingmechanismsthusloweringtheoverallcostforprotection[38],[39].Thelogicalviewofthecontrolplaneinteractionforscenario2isshowninFigure7. The fibre cut is identified by a LOS alarm5from the OLT to the accesscontroller(step1).Uponfailuredetection,thecontrolplaneoperatesasfollows.TheaccesscontrollerinMCnode1informsthenetworkorchestratoraboutthefailure (step2). Theorchestrator informs the core controller to setup thepre-calculated core backup paths corresponding to the failure (step 3). TheorchestratorthencommunicatestotheaccesscontrollerintheMCnodehostingthestandbyOLT,passingtheinformationrequiredtoactivatetheOLTaswellas

5TheLOSalarmisactivatedwhetherthereisafailureoftheupstreampathorthedownstreampath.DetectionofdownstreampathfailurerestsuponthefactthatONUsstopanytransmissionassoonasitloosescontactwiththeOLT,(e.g.,followingthefibrecut).

theappropriateprotectionpathsthatneedtobeactivatedinthenode(step4).Inthemeantimethecorecontrollerwillconfigurethecorenodes(step5)whiletheaccesscontrollerofthestandbyMCnodewillconfiguretheaccesselements(step6).Thecorecontrollerwillthenprovidefeedbacktotheorchestrator(step7)ontheoutcomeofthecoretrafficredirection,andtheaccesscontrollerofthestandbynodeontheaccessprotection(step8).Itshouldbenoticedthatinordertospeeduptheprotectionprocessanumberofoperationsareoperatedasynchronouslyandinparallel(e.g.,withoutwaitingforconfirmationfromtheaccessandcorecontrollers).Finally, this scenario assumes that anetworkmanagement systemhas alreadypre-calculated standby PWs, that are associated to existing or other standbyLSPs, during protection configuration. Protection setup schemes for PWredundancyhavealreadybeenstandardized[40].

Figure7Scenario2:fastPONfeederfibreprotection

DemonstrationofdynamicbandwidthprovisioningWhilethenetworkprotectionscenariohasbeendemonstratedin1+1[41],[42],1:1 [43] and N:1 OLT sharing [44], here we report a demonstration of thedynamic Bandwidth-on-demand service provisioning with dynamic channelselection.ThetestbedexperimentwereportshowsthedynamicprovisioningofaserviceusinganSDNcontrollerwithOpenFlowassouthbound interface. It isassumedthatwhileanONU isreceivingaservicewithagivenreservedcapacity (whichwerefertoasservice-A)byanOLT(whichwerefertoasOLT-1),italsorequestscapacityforanadditionalservice,forexampleBandwidth-on-demand(whichwerefertoasservice-B).Thescenarioissetupsothatthewavelengthchannelused

bytheONUdoesnothaveenoughcapacitytosupporttherequestedBandwidth-on-Demand (BoD) service. The controller needs thus to activate a secondOLT(whichwerefertoasOLT-2), inordertodeliverserviceB.SincetheONUonlyhasone(tunable) transceiver,bothservicesAandBneed tobedeliveredoverthe same wavelength, by OLT-2. This implies redirecting service A to OLT-2,whichrequirescommunicationwiththeSPtomoveserviceAintoadifferentPWwhichcanberoutedtoOLT-2.TheaimoftheexperimentistodemonstratetheabilityofOpenFlowandSDNtohandlesuchend-to-endserviceprovisioningandto measure the time required to provision service-B and the impairmentgeneratedforreroutingservice-A.Itshouldbenoticedthatthisexperimentfocusesonthecontrolplaneactivitiesrather than on the physical layer. Thus for example the tunable lasers aretunableDWDMSmallForm-factorPluggabletransceivers(SFP+)withfasttuningtimeandprecisewavelengthlocking,whileontheotherhandwehaveusedslowWavelength Selective Switches (WSS) as tunable filters. While this might notrepresent the standard for current low-cost ONU devices, we argue that ourresults remain valid from a control plane timing perspective and additionaldelayscouldbeaccountedfor inestimatingoverallprovisioningtimeof lower-costtransceivers.The experiments are run on our Optical Network Architecture access testbedwithproprietaryONUandOLTsimplementedinField-ProgrammableGateArray(FPGA)hardware[43],[44],aproprietarynetworkorchestratorimplementedinpythonandanaccessnetworkcontrollerbuiltontopoftheRYUSDNplatform.A logicalviewof the testbedcomponentsandoperations is shown inFigure8,showingthedifferentstepsrequiredtoprovisiontheservice6.Followingtheuserrequest foranewBoDservice-B, theOrchestrator forwardsa JSONmessagetothe OF controller (step 1) indicating the capacity requested and the range ofwavelengthstheONUcansupport.Oncethecontrollerhasverifiedthecapacityavailability itacknowledges theorchestrator,whichcommunicateswithSP2 toactivatethenewservice-BandwithSP1torerouteservice-AintoadifferentPW(Step 2). The orchestrator then informs the core controller to add a new LSPpathforroutingserviceBtothecorrectMCnode(step3).InparalleltheMetro-Access controller communicates with OLT-2 through the OpenFlow agenttranslating OF commands into proprietary control messages sent through theUARTinterface,indicatingtoactivateitsserviceonthedesiredwavelength.TheMetroAccesscontrollerpreparesthephysicalandlinklayerbetweenOLT-2andtheONU.OLT-2isinstructedtosetthefrequencyofitsdownstreamtunablelaserandisgiventheexplicitparametersusedtobindthePWtothealloc_idforeachofbothservice-Aandservice-B(step4).TheOLT’sandONU’sdonotpresentnativeOpenflowinterfaces,butinsteadarecontrolled over a high-speed serial Universal SsynchronousReceiver/Transmitter(UART)interfacerunningat406kbps.TheMicroblaze(i.e.,asimplegeneralpurposeprocessorimplementedintheFPGAhardware)onthehost FGPA boards presents an interface for directly programming andinterrogating PON control registers, which are then accessible over the high-speed UART interface. Run-time control of the PON is executed through the

6Althoughwedescribedtheprocessinsequentialsteps,someoftheactionsdescribedareactuallycarriedinparallelinordertospeeduptheprovisioningprocess.

interfaces onOLT-1 andOLT-2which in turn relay control instructions to theremoteONUusingPhysicalLayerOperations,AdministrationandMaintenance(PLOAM) messages. The run-time functionality includes configuration of thelaser frequencies of the OLT and ONU tunable lasers, the configuration ofalloc_id’s at the ONU for appropriate XG-PON encapsulationMethod (XGEM)packetsandthere-homingofONUfromOLT1toOLT2.AnOpenflowagentwrapperaroundbothOLT-1andOLT-2wasdevelopedsoastopresentanOpenflowv1.4compatibleinterfacetotheMetro-AccessController.Openflow v1.4 facilitates the control of optical parameters of OpenFlowcompatibleswitchesanddevicesthroughthe‘OFPPortModPropOptical’method.These parameters include the transmission centre frequency orwavelength, afrequency offset from the centre frequency and the transmission power level(dB)andareasubsetofthosewhichwearelookingtocontrolwithinthePON.Because we need runtime control of additional non-standard parameters, weenhanced both the v1.4 protocol and the agent to allow configuration of theXGEM, Alloc_ID and PseudoWire tags associated to a given flow through theMetro-AccessController.ThecontrollertheninstallsthenewentryforthePW,includingmetertablesforQoSandcapacityreservationintheswitchflowtable(step5).Inparallel,TheMetroAccesscontroller,throughaPLOAMmessagefromOLT-1,instructstheONUtotunethefiltertothenewwavelength(step6).AseriallinkbetweenasecondaryUARTontheONUandthetunablefilter,tunesthefiltertothenewwavelengththerebydirectingthesignaltoOLT2.(step7).

Figure8(a)OperationofSDNcontrolplanetoprovisionserviceBwhileoperatingserviceA;(b)networkstateafterprovisioningofserviceBandre-directionofserviceAtoOLT2.

ThetimingresultsofthetestbedexperimentarereportedinFigure9,averagedovertentestbedruns.Fromthetimetheserviceisrequestedtotheorchestrator

(step0), theorchestratorandaccess controller introducea444msprocessingdelay(steps1to3asalsoreportedinFigure8),afterwhichtheOLTreceivesthecommand toactivateanewchannel (step4)and theaccessswitch, inparallel,receives the OpenFlow commands for updating the PW tags in the flow table(step5).ThePLOAMmessagecontainingtheinformationonthenewwavelengthchannel isthenreceivedandacknowledgedbytheONUwithin1.5ms(step6),triggering it to activate the tunable filter and laser to the correct wavelengthchannelandcausingtheOLT-1tode-registertheONU.InourtestbedthetunablefilterwasoperatedbyaWSSdevice,whichintroducedasizablelatencyofabout2 seconds.Once the filter is tuned to thenewchannel (step7), theONU is re-registeredonthenewOLTwithin7ms(step8).

Figure9Timingdiagramoftheserviceactivationexperiment

Theresultsshowthatabout2.45secondsarerequiredinordertomovetheONUtoanewchannel,withadisruptiontimeonexistingservicesofabout2seconds.It should be noticed however that most of the latency was due to the slowswitching time of the WSS. This could be reduced to about 50 ms by usingcommercially available tunable filters, which would reduce the downtime onexistingservicestoabout60ms,whileactivatingthenewservice inabout500ms.Inadditionwebelievethatbetteroptimizationoftheorchestratorandcontrollercouldbeoperatedtofurtherreducetheactivationtimeofthenewservice.

ConclusionsThis paper has presented a hierarchical control plane architecture for nextgenerationbroadbandnetworks, focusingon thedetailsofanOpenFlow-basedcontrollerforaconvergedMetro-Accessnetwork.Besidesgivingadescriptionofthe main component and interfaces, the paper has provided implementationdetailsbasedontwomainscenarios,fastprotectionofadual-homedPONsystemanddynamicserviceprovisioningoveramulti-wavelengthPON.

Atestbedexperimentwascarriedoutforthesecondscenario,emulatingauserrequest through Service Provider portal, operating through a networkorchestratorandanOpenFlow-basedMetro-AccessSDNcontroller.The latencyofourexperimentwasstronglydominatedbytheslowtuningtimeof theWSSweusedas tunable filter, showingwavelengthservicesetuptimesofabout2.5seconds,whileintroducinga2secondsdisruptiononexistingservices.However,we recognize that the use of appropriate tunable filters could reduce servicedisruption times toabout60msandserviceactivation time to less thanhalfasecond.While more work is required to assess the viability of a fully SDN-basedcontroller for a telecommunications metro-access network, we believe thedemonstrationshowninthispaper,togetherwithotherrecentimplementations,are creating an important roadmap for the programmability of the networkcontrol andmanagement planes. Thesewill be essential tomaintain a healthybalance between the constant increase in link capacity and the need formoredynamicandautomatednetworkcontrolandmanagement.

AcknowledgmentsThe research leading to this article has received funding from the EuropeanUnion Seventh Framework Programme (FP7/2007-2013) under grantagreementn.318137(Collaborativeproject“DISCUS”),andScienceFoundationIrelandundergrantsno.12/IA/1270and10/CE/I1853.Theauthorswouldalsolike to acknowledge Victor Lopez, Andrea Di Giglio, Marco Schiano and LauraSerraforthefruitfuldiscussionsoncontrolplanearchitectureanddatalabellingmodels.

References[1] N.McKeownetal.,OpenFlow:EnablingInnovationinCampusNetworks.ACM

SIGCOMMComputerCommunicationReview,38(2),April2008.[2] U.Holze,“Openflow@Google”,OpenNetworkingSummit2012,availableat:

http://opennetsummit.org/archives/apr12/hoelzle-tue-openflow.pdf[3] K.Amin,KMStechnologies.Availableform:

http://www.slideshare.net/kmstechnology/big-data-overview-2013-2014[4] X.Li,etal.,JointBandwidthProvisioningandCacheManagementforVideo

DistributioninSoftware-DefinedPassiveOpticalNetworks.PaperTu3F.5,OFC2014.

[5] N.Cvijetic,etal.,SDNandOpenFlowforDynamicFlex-GridOpticalAccessandAggregationNetworks.IEEEJournalofLightweightTechnology,32(4),2014.

[6] N.Bitar,SDNandPotentialApplicabilitytoAccessNetworks.PaperTh1G.4,OFC2014.

[7] T.Pfeiffer,APhysicalLayerPerspectiveonAccessNetworkSharing.ElsevierOFTspecialissueonaccessnetworks,November2015.

[8] Stokewhitepaper,LatencyConsiderationsinLTE,September2014.Availableathttp://www.mavenir.com/files/doc_downloads/Stoke_Documents/130-0029-001_LTELatencyConsiderations_Final.pdf

[9] NGMNAlliance,FronthaulrequirementsforC-RAN,March2015.Availableat:https://www.ngmn.org/uploads/media/NGMN_RANEV_D1_C-RAN_Fronthaul_Requirements_v1.0.pdf

[10] U.Doetsch,etal.,QuantitativeAnalysisofSplitBaseStationProcessingandDeterminationofAdvantageousArchitecturesforLTE,BellLabsTechnicalJournal18(1),January2013.

[11] J.Rendon,NetworksharingwithFTTH/PONarchitectures.HuaweyCommnunicate,No68,Jan.2013.Availableat:http://www.huawei.com/en/static/HW-201348.pdf

[12] B.Cornagliaetal.,FixedAccessNetworkSharing.ElsevierOFTspecialissueonaccessnetworks,November2015.

[13] M.Ruffini,etal.,DISCUS:Anend-to-endsolutionforubiquitousbroadbandopticalaccess.IEEECom.Mag.,vol.52,no.2,February2014

[14] M.Ruffini,etal.,DISCUS:End-to-endnetworkdesignforubiquitoushighspeedbroadbandservices(Invited).ICTONconference,2013.

[15] L.Yang,etal.ForwardingandControlElementSeparation(ForCES)Framework.InternetEngineeringTaskForce,RFC3746,2004.

[16] N.Feamster,etal..Thecaseforseparatingroutingfromrouters.ACMSIGCOMMWorkshoponFutureDirectionsinNetworkArchitecture,Sept.2004

[17] A.Greenberg,etal.Acleanslate4Dapproachtonetworkcontrolandmanagement.ACMSIGCOMMComputerCommunicationsReview,35(5),2005.

[18] N.Femster,et.Al.“TheRoadtoSDN:Anintellectualhistoryofprogrammablenetworks”,ACMSIGCOMMComputerCommunicationReview,Vol.44,No.2,2014.

[19] Z.Wangetal.,IETFInternetdraft“AnalysisofComparisonsbetweenOpenFlowandForCESdraft-wang-forces-compare-openflow-forces-01”,March2012

[20] S.Hubbard,Software-DefinedMetroNetworks:VirtualizingtheNetwork&ServicesEdge.LightReadingWhitePaper,December2012,availableat:http://www.overturenetworks.com/sites/default/files/white_paper/HeavyReading_WP_MetroSDN_EdgeVirtualization_12-18-12.pdf

[21] P.Iovanna,etal.,E2ETrafficEngineeringRoutingforTransportSDN.PaperW1K.3,OFC2014.

[22] R.Casellas,etal.,SDNbasedProvisioningOrchestrationofOpenFlow/GMPLSFlexi-gridNetworkswithaStatefulHierarchicalPCE.PaperTh3I.2,OFC2014.

[23] A.Aguado,etal.,ABNO:afeasibleSDNapproachformulti-vendorIPandopticalnetworks.PaperTh3I.5,OFC2014.

[24] A.Autenrieth,etal.,IntroducingOFELIAandOpenFlowextensionstosupportOpticalNetworkingEquipment.ONTCMeeting,OFC2012.Presentationavailableat:http://www.fp7-ofelia.eu/assets/Publications-and-Presentations/2012-03-08-ONTC-Autenrieth-OFELIA-final.pdf

[25] S.Azodolmolkyetal.,IntegratedOpenFlow–GMPLScontrolplane:anoverlaymodelforsoftwaredefinedpacketoveropticalnetworks.Opticsexpress,19(26),2011

[26] N.Gude,etal.NOX:TowardsanOperatingSystemforNetworks.ACMSIGCOMMComputerCommunicationReview,38(3),2008.

[27] V.Lópezetal.,TowardsaNetworkOperatingSystem.PaperTh3I.6,OFC2014.

[28] ETSIstandardGSNFV001,NetworkFunctionsVirtualisation(NFV):UseCases.October2013.

[29] ETSIstandardGSNFV-MAN001,NetworkFunctionsVirtualisation(NFV):ManagementandOrchestration.December2014.

[30] ONF.SDNArchitecture,Issue1,June2014.www.opennetworking.org[31] F.Francois,etal.,ExperimentalAssessmentofABNO-basedNetwork

Orchestrationofend-to-endMulti-layer(OPS/OCS)ProvisioningacrossSDN/OpenFlowandGMPLS/PCEControlDomains.PaperWe.3.2.4,ECOC2014.

[32] R.Casellas,et.Al.,SDNOrchestrationofOpenFlowandGMPLSFlexi-gridNetworkswithaStatefulHierarchicalPCE,JournalofOpticalCommunicationsandNetworking,Vol.7,No.1,January2015.

[33] R.Munoz,etal.,TransportNetworkOrchestrationforend-to-endMulti-layerProvisioningAcrossheterogeneousSDN/OpenFlowandGMPLS/PCEControlDomains.JournalofLightwaveTechnology,Vol.33,No.8,April2015.

[34] P.Szegedi,etal.,Enablingfutureinternetresearch:theFEDERICAcase.IEEECommunicationsMagazine,vol.49,no.7,July2011.

[35] R.Vilalta,etal.TheNeedforaControlOrchestrationProtocolinResearchProjectsonOpticalNetworking.ToappearinproceedingsofEuCNC2015.

[36] M.Ruffini,atal.,DISCUSFP7projectDeliverableD6.3:“Reportonthedesignoftheinterfacesofthecontrolplane”,August2014.

[37] A.Nag,etal.,N:1ProtectionDesignforMinimisingOLTsinResilientDual-HomedLong-ReachPassiveOpticalNetwork.PaperTu2F.7,OFC2014

[38] M.Ruffini,etal.,DeploymentcasestudiesofanenergyefficientprotectedLR-PON architecture. Proceedings of IEEE Optical Network Design andModelling,2012

[39] M.Ruffini,etsl.,ProtectionStrategiesforLong-ReachPON.ECOC2010.[40] Muleyatal.,IETFRFC6718,PseudowireRedundancy,2012.[41] S.McGettrick,etal.,Ultra-fast1+1Protectionin10Gb/sSymmetricLong

ReachPON.ECOC2013.[42] S.McGettrick,etal.,ImprovingHardwareProtectionSwitchingin10Gb/s

Symmetric Long Reach PONs,OpticalFibreCopnference(OFC),Anaheim,CA,2013

[43] F.Slyne,etal.,Designandexperimentaltestof1:1End-to-EndProtectionforLR-PONusinganSDNmulti-tierControlPlane.PaperMo.3.2.4,ECOC2014

[44] S.McGettrick, et al., Experimental End-to-End Demonstration of SharedN:1 Dual Homed Protection in Long Reach PON and SDN-Controlled Core.PaperTu2E.5,OFC2015.