Telecom. White Paper. An Abstraction of Failure-free Software Defined Network. Enhancing network performance and ensuring connectivity

Transcription

1 Telecom White Paper A Abstractio of Failure-free Software Defied Network Ehacig etwork performace ad esurig coectivity

2 About the Authors Sumit Kapoor Sumit Kapoor is a Lead Solutios Egieer i TCS Techology Busiess Uit focussig o Software Defied Networkig (SDN) protocols, SDN cotrollers ad SDN applicatios. With aroud eight years of experiece, Sumit plays a key role i ideatig ad implemetig SDN applicatios ad solutio accelerators. He is also a active cotributor to the ope-source commuity (OpeDayLight SDN Cotroller). Divya Chaudhary Divya Chaudhary is a Egieer i TCS Telecom idustry services uit, focusig o techologies such as SDN ad virtualizatio. She actively cotributes to the implemetatio of solutio accelerators i ext geeratio techologies. Partha Datta Partha Datta is the Associate Head of TCS Techology Busiess Uit resposible for ext geeratio R&D iitiatives (Telco cloud Virtualizatio, Software Defied Networkig) with focus o telecom equipmet vedors. He has 16 years of experiece egagig with leadig telecom equipmet vedors across the US ad EMEA. Partha advocates a holistic view of solutios from a busiess as well as a techical perspective to eable value added trasformatios drive by ext-geeratio techologies.

3 Abstract With the advet of always-o, always-coected, user-cetric applicatios, the eed for greater badwidth has icreased expoetially. Software Defied Networkig (SDN) is fast gaiig tractio as the etworkig ecosystem of choice i this cotext. Deliverig a cotrol plae with a programmable iterface to maage the etwork, SDN has tremedous potetial to help deliver uiterrupted coectivity ad ehaced etwork performace. Oe of the fudametal requiremets of SDN is recoverig from etwork failure which curretly depeds o software recovery logic implemeted by developers o a per module basis. To eable seamless recovery from etwork failure, this paper discusses the use of a shadow SDN cotroller (OpeDayLight) ad a SDN applicatio (SDN App). Upo failure of oe istace of the etwork, the SDN app leverages the shadow SDN cotroller to emulate the etwork without the failed compoet ad compute the applicable ew flows/paths.¹ The result is a abstractio of a failure-free etwork, based o the teets of the SDN cotroller, Northboud APIs, ad SDN applicatio. This paper presets the performace bechmarkig results for a typical etwork with 400 SDN odes (scope of scalig to 5000 odes) ad 10,000 flows per secod, usig this approach. [1] SIGCOMM, Automatic Failure Recovery for Software-Defied Networks (Aug 2013), accessed 23 May 2015,

4 Cotets Esurig Uiterrupted Network Coectivity 5 Recoverig from Network Failure i SDN: The Curret Shortcomigs 5 Implemetig Network Abstractio: A Techical Perspective 6 Challeges of Network Abstractio 8 Uderstadig the Desig Cosideratios 8 Puttig the Cocept to Test: Implemetatio ad Test Aalysis 10 Improvig the Proof-of-cocept: Future Scope of Work 14 Augmetig Network without Failure 14

5 Esurig Uiterrupted Network Coectivity Failure recovery is a critical focus area for ay etwork, be it legacy or Software Defied Networks (SDN). To this ed, i curret SDN cotrollers, every time a SDN applicatio is implemeted, it icludes its ow failure recovery logic. However, this approach is error proe ad time cosumig, resultig i icremetal work for the developer every time a ew applicatio is desiged. To address this limitatio, we recommed a viable approach leveragig the SDN cotroller (OpeDayLight) to recover from etwork failures at ru-time ad esure cotiuous ad hassle-free etwork coectivity. A SDN applicatio (SDN app) is implemeted to provide failure-free etwork abstractio o a SDN cotroller maaged SDN ecosystem. Typically the SDN app will help: Detect etwork failure Facilitate services to record key evets O etwork failure trigger, replay key evets to the emulated etwork cosistig of a shadow SDN cotroller Re-compute cotroller state ad trasfer it to the primary SDN cotroller This paper presets the desig ad approach for a SDN app that ca abstract a failure free software defied etwork. Recoverig from Network Failure i SDN: The Curret Shortcomigs For every SDN app, failure recovery requires the presece of additioal software logic at the cotroller. I curret approaches, developers implemet redudat failure recovery for every applicatio ad cotroller module, which icreases the probability of bugs. The easiest approach is to fid rules/flows pertaiig to the failed ode ad deletig them. However, this may result i etwork discrepacy (traffic disruptio, quality of service degradatio, forwardig loops, ad so o.) The existig failure recovery i SDN icludes the followig steps: Whe failure (lik/ode up/dow/out-of-service) occurs i the etwork, a PortStatus message is set to the cotroller idicatig that a error has occurred The cotroller re-looks at the topology ad istalls ew forwardig rules o the basis of the modified topology Oce ew rules are cofigured successfully, the traffic starts flowig accordig to the ew rules 5

6 These are the drawbacks of the curret recovery ad post-recovery process: Failure recovery is performed by specific software logic ruig at the cotroller, which meas that each cotroller applicatio must iclude its ow recovery logic. Failure recovery is depedet o the cotroller i the absece of failure recovery logic i the SDN applicatio. This ofte results i droppig of applicatio related packets (traffic disruptio for a delayed time) by the cotroller. Pre-computed backup paths are ot eough to improve failure resiliece i SDN. They typically provide a immediate workaroud to failure, but might shift traffic to follow suboptimal paths. Traffic that is redirected to aother backup path leads to cogestio, as the path might have existig traffic. Failure recovery has typically bee left out of the desig of SDN cotroller platforms, compellig developers to implemet idepedet algorithms or customized approaches to eable recovery. Implemetig Network Abstractio: A Techical Perspective A abstractio of failure free etwork² is a approach where the cotroller is completely uaware of ay failures, yet operates efficietly over the modified etwork. The SDN app for failure abstractio is maaged by a statefull workflow maager ad works broadly i three modes Record, Recovery, ad Recofiguratio (RRR). Record mode: Records the key evets (for example, PacketIN comig from the edge odes) resposible for the primary SDN cotroller s rule istallatios i the etwork ad stores them i a database i real-time. The record mode exteds additioal fuctioalities of Filter (prues ad records oly ecessary evets) ad Expire (deletes evets whose correspodig rules have expired). Replay mode: Upo detectio of a etwork failure, the SDN app triggers a emulated etwork without the failed etwork compoet that works with a clea copy (shadow) of the SDN cotroller. It the replays key evets to the emulated etwork. Recofigure: Trasitios the real etwork to the ewly derived emulated etwork state. The SDN app starts i the record mode, where the moitorig script moitors the etwork for ay failures, while a shadow OpeDayLight Cotroller rus parallely i the etwork. The shadow SDN cotroller is a clea copy of the primary cotroller with the same set of features. [2] SIGCOMM, Automatic Failure Recovery for Software-Defied Networks (Aug 2013), accessed 23 May 2015, 6

7 Let s cosider a sceario where a fault (ode out-of-service) occurs o oe of the SDN odes (Figure 1). Fault - Node OOS Figure 1: Fault detected i Software Defied Network Upo detectio of ay failure i the primary etwork, the SDN app triggers a shadow etwork for the shadow SDN cotroller. This emulates the primary etwork without the failed ode. Oce the shadow etwork is up ad ruig, the packet iformatio recorded i the database durig the record mode is used to recreate ad replay the packet over the shadow etwork usig APIs of the OpeDayLight Cotroller. This replay leads to computatio of ew forwardig rules by the shadow SDN cotroller o the basis of the shadow etwork. Oce the shadow SDN cotroller istalls the flows o the shadow etwork, the delta flows of the shadow ad primary etwork flows are used to recofigure the primary etwork. This helps recover the etwork from failure. Figure 2 showcases the logical code flow of the applicatio. Primary etwork 1 Network Moitorig Topology chages detected 8 2 NO YES Record mode Recovery mode Record all Packet I messages Record all flows Workflow maager 14 5 Filter primary ad implied evets SDN App - Primary Cotroller SDN App Shadow Cotroller 10 Rebuild the etwork topology 11 without the affected ode 6 12 Retrieve PacketI messages Associate the flow message with the PacketI messages 7 Database 13 Batch process clea up expired flow Replay Capture flows Shadow etwork Figure 2: Logical Code Flow of the SDN App 7

8 After the recovery, the shadow SDN cotroller is cleaed up ad the moitorig script starts moitorig the primary etwork agai for ay subsequet failures. Challeges of Network Abstractio While etwork abstractio is a viable optio, there are some challeges i its implemetatio that call for further research ad refiemet. Some of the mai challeges are: Fast ad efficiet emulated etwork creatio Whe a failure is detected i the primary etwork, the time take for creatig the shadow etwork should be as low as possible to esure effective applicatio performace For a 5 ode topology, it merely takes a few secods to brig up the shadow etwork, but as the size of the primary etwork grows, so does the time take for creatig the shadow etwork Quick ad efficiet replay For the SDN cotroller to compute forwardig rules for primary as well as implied evets, the packet eeds to be recreated from packets captured before failure These recreated packets are the replayed over the shadow etwork by trasmittig them to the correspodig switches The replay mechaism should be fast ad efficiet to esure it does ot impact the performace of the SDN app Uderstadig the Desig Cosideratios The SDN app architecture (Figure 3) cosists of the core fuctioal modules that process, iter-work ad eable the failure-free abstractio. Network Moitor Tolopogy Service Workflow Maager Packet/Flow Mod Logger Database Packet Replay Flow Capture Recovery SDN Cotroller Iterface Northboud API Iterface Northboud API Capture flows (script) Software Defied Network (Live Network) Emulated Network (Miiet) Host Host Figure 3: Architecture of the SDN App 8

9 The fuctioality ad the techical details of the modules are as follows: Network evets loggig: The packet/flow mod logger module of the SDN app leverages IDataPacketService of the service abstractio layer (SAL) (Iterface: IListeDataPacket) to capture the PacketIN message streamig ito the primary etwork. The SDN app writes the PacketI message ito the database ad captures Flow-Mod message usig Flow Logger ForwardigRulesMaager Service of SAL (Iterface: IForwardigRulesMaager). The flow messages are associated with the PacketIN messages ad stored i the database. This module is also resposible for distiguishig betwee primary ad implied evets i the etwork. It logs oly the primary evets ad lets the shadow cotroller propagate ad cause all related implied evets. While primary evets are packets received at the igress ports, which are resposible for computatio of forwardig rules by the primary SDN cotroller, implied evets are all other evets caused by the same packet through the etwork. Failure detectio ad moitorig: The etwork moitorig module moitors the primary etwork for ay failure scearios. It detects etwork failures based o port status message or chage i umber of edges i the primary etwork usig Topology Northboud REST API of OpeDayLight. The module the iforms the workflow maager module about the failure. This module ot oly raises the required trigger upo failure but also creates the shadow etwork without the failed ode oce the shadow cotroller is up ad ruig. The workflow maager is a statefull module that maages the etire applicatio workflow from record mode ad replay to recofiguratio alog with other itermediate states. Copyig cotroller state ad activatig emulated etwork without the failed ode: The Topology Northboud REST API is used for creatig the shadow etwork over miiet. A key challege faced durig this process is disparities betwee the ode coector idetificatio (IDs) ad ports i the primary ad shadow cotroller. To solve this issue, the ode coector IDs ad ports of primary ad secodary etworks eed to be mapped. This ca be doe usig module accessig OpeDayLight's HostTracker Northboud REST API to get iformatio about active hosts preset i the primary etwork. Network moitorig triggers the workflow maager to start recovery mode wheever failure is detected i the etwork. Oce the shadow etwork is created o miiet ad the shadow cotroller is activated, the workflow maager iitiates the replay mode. After all the packets have bee replayed ad flows writte o the shadow etwork, the workflow maager accesses these flows usig Flowprogrammer Northboud REST API of OpeDayLight. It also cofigures delta of primary ad shadow etwork flows oto the primary etwork to esure successful recovery from failure. Network evets replay ad flow capture: The mai aim of recovery is to compute the etwork state as if o failure has occurred ad the failed ode was ot a part of the topology from the begiig. It also aims at trasitioig the primary etwork to the ewly derived state. The packet replay module feeds the shadow cotroller with the primary evets such as PacketIN recorded by the primary cotroller before the failure. The packet data stored i byte form i the database is used to recreate a raw packet usig DataPacketService of OpeDayLight cotroller. Oce a raw packet is created, it is trasmitted to the igress port of the switch, ad is replayed oto the shadow etwork. Sice the shadow etwork is 9

10 differet from the primary etwork, the decisios made by the cotroller are also differet. Hece, the replay of packets causes implied evets ad the cotroller computes ew forwardig rules to be istalled o the switches of the modified etwork. These forwardig rules are captured by flow capture recovery module usig OpeDayLight's Flowprogrammer API ad are forwarded to workflow maager. Network recofiguratio: The workflow maager compares these ewly istalled rules with the old rules writte o the primary etwork. The differeces i these flows are istalled o the primary etwork elemets usig Opedaylight's Flowprogrammer API. Ehacig quality: The SDN app icludes the followig features to eable optimizatio of evet recordig ad purgig: Filter evets: Loggig oly primary evets (ad ot implied evets), ot oly saves database space but also reduces the replay time as the SDN app replays oly primary evets. Also primary evets whe replayed cause implied evets, which is the best way to regeerate implied evets. Removig expired evets: A large umber of packets are received i a real etwork. Therefore, to avoid database etries growig extesively, the SDN app supports batch processes to filter out PacketINs with correspodig expired FlowMod messages. Parallel replay of idepedet evets: The SDN app replays idepedet evets i parallel batches, optimizig performace ad substatially reducig the replay time. Re-moitorig the etwork oce recofiguratio is successful: The SDN app cleas up the shadow cotroller after recovery ad restarts the moitorig module, eablig it to hadle ay follow-up failures. It also facilitates plaed maiteace of etworks. Puttig the Cocept to Test: Implemetatio ad Test Aalysis For the proof-of-cocept of the failure-free SDN etwork, 4 GB, Itel dual-core, Ubutu 14.04, virtual machies were used. Co-residet OpeDaylight SDN cotrollers (primary ad shadow) alog with co-residet etworks (primary ad shadow) were the core compoets of the setup. The proof-of-cocept was tested with 5 odes, ad scaled up up to 400 odes. The primary etwork ad the cotroller start with a combied clea state, which is modified i respose to opeflow messages. The SDN app works i the record mode till ay failures are ecoutered by the target etwork. 10

11 A shadow cotroller rus parallel to the primary cotroller. As depicted i figure 4, the traffic status is emulated by etwork pig to showcase the operatios of the SDN app i extedig the abstractio of a failure free software defied etwork. Figure 4: SDN App Workig i Record ad Moitorig mode 11

12 As show i figure 5, upo failure, a shadow etwork is created replicatig the primary etwork without the failed ode. The SDN app eters the recovery mode. Post shadow etwork creatio, recorded packets are recreated ad replayed o the etwork. Shadow SDN cotroller discovers the revised etwork ad computes ew forwardig rules. Delta flows are the recofigured o the primary SDN cotroller ad etwork. Figure 5: SDN App Workig i Replay ad Recovery mode 12

13 Oce the primary etwork is recovered, the shadow cotroller is cleaed ad the moitorig script starts moitorig the etwork agai to hadle ay follow-up failures as show i figure 6. Figure 6: SDN App Restartig i Moitorig Mode Proof of Cocept Setup ad results POC setup Ubutu 14.04, 4GB, Itel Dual Core Co-residet OpeDaylight cotroller (primary ad shadow) Co-residet SDN etwork (primary ad shadow etwork) Scalability setup The applicatio scaled for odes 100 Nodes 4100 Nodes Captured packet replay scaled from 10K - 40K flows 10 K 20 K 30 K 40 K Figure 7: Performace Bechmarkig 13

14 Over 40K packets were stored i the database ad replayed over the shadow etwork. Figure 7 shows the efficiecy iduced by the SDN app abstractig a failure free software-defied etwork, eablig complete recovery i secods. Improvig the Proof-of-cocept: Future Scope of Work The ext steps with referece to ehacig the efficiecy ad scalability of the SDN app are as follows: Ehace SDN App: Migrate the curret desig based o OpeDaylight API-Drive Service Abstractio Layer (AD-SAL) to Model-Drive Service Abstractio Layer (AD-SAL). Maage repeated failures: Ehace SDN app to deal with sequetial failures takig place before the completio of recovery for first failure. Facilitate distributed setup of primary ad shadow cotrollers: Optimize system performace ad recovery time through distributed setup of SDN cotrollers. Optimize pre-set shadow etwork: For large etworks, creatig the shadow etwork from scratch is time cosumig. The idea is to pre-create the shadow etwork with the same topology as the primary etwork. Upo primary etwork failure, the SDN app should be able to update the failed compoet i the shadow etwork to save etwork creatio time ad accelerate the recovery process. Augmetig Network without Failure Failure recovery ca be ehaced by creatig a abstractio of a failure-free software defied etwork that hides ay failures occurrig i the etwork. This approach helps reduce repetitive/error-proe cotroller logic. Network operators ca draw upo SDN cotroller capabilities ad SDN applicatios to provide better quality service through effective failure recovery. This implemetatio, coupled with other viable optios like clusterig, high availability, backup recovery, ad master slave operatio, ca provide a scalable ad versatile methodology to esure miimum etwork dowtime ad aligmet with etwork reliability madates. 14

15 About TCS' Telecom Busiess Uit For over three decades, TCS has worked with compaies i the Commuicatios idustry, helpig them develop world class solutios ad systems, simplify operatios, augmet etwork services, diversify ito ew markets, ad stay ahead of the competitio. Our solutios address the etire ladscape of telecom busiesses, ragig from greefield start-ups to large cable ad satellite compaies ad equipmet vedors. Our partership model leverages ready-to-deploy platform solutios, proprietary frameworks, ad solutio accelerators to eable our cliets to lauch ew products ad services quickly. TCS' ivestmets i ext geeratio platforms, mobility solutios, capabilities, ad lab ifrastructure are aliged to address our cliets' key busiess imperatives of operatioal excellece, customer experiece, ad reveue ehacemet. We have helped eterprises ulock busiess value i the areas of Digital Chael ad Commerce, Customer Isights, Mobility Solutios, Hosted OSS/BSS (HOBS), IOT & M2M Platforms, Coected Device Maagemet, B2B Platform Ecosystem ad Services ad Network Abstractio layers. Cotact For more iformatio about TCS Telecom Busiess Uit, visit: global.telecom@tcs.com Subscribe to TCS White Papers TCS.com RSS: Feedburer: About Tata Cosultacy Services (TCS) Tata Cosultacy Services is a IT services, cosultig ad busiess solutios orgaizatio that delivers real results to global busiess, esurig a level of certaity o other firm ca match. TCS offers a cosultig-led, itegrated portfolio of IT ad IT-eabled ifrastructure, egieerig ad TM assurace services. This is delivered through its uique Global Network Delivery Model, recogized as the bechmark of excellece i software developmet. A part of the Tata Group, Idia s largest idustrial coglomerate, TCS has a global footprit ad is listed o the Natioal Stock Exchage ad Bombay Stock Exchage i Idia. For more iformatio, visit us at IT Services Busiess Solutios Cosultig All cotet / iformatio preset here is the exclusive property of Tata Cosultacy Services Limited (TCS). The cotet / iformatio cotaied here is correct at the time of publishig. No material from here may be copied, modified, reproduced, republished, uploaded, trasmitted, posted or distributed i ay form without prior writte permissio from TCS. Uauthorized use of the cotet / iformatio appearig here may violate copyright, trademark ad other applicable laws, ad could result i crimial or civil pealties. Copyright 2015 Tata Cosultacy Services Limited TCS Desig Services I M I 07 I 15