WHITE PAPER WHITE PAPER OVERVIEW

Transcription

1 OpenFlw OpenFlw is an element in SDN slutins. Testing the perfrmance f OpenFlw switches is essential t ensure the quality f the SDN slutins. OVERVIEW Cmmunicatin netwrks have traditinally been built with dedicated devices like ruters, switches and firewalls, each being designed fr a specific task. The result is ttally distributed netwrk cntrl, where decisins n data frwarding are dne in the netwrk devices based n varius algrithms and prtcls. Once set up and cnfigured the netwrk wuld wrk fine, but changing the behavir f the netwrk can be cstly and time cnsuming if pssible at all. A new cncept Sftware-Defined Netwrking (SDN) is generating huge interest because it prmises t add higher flexibility and faster cnfiguratin f netwrks. Fr SDN devices it is imprtant that they meet the Open Netwrking Fundatin (ONF) OpenFlw specificatins when OpenFlw is included in the SDN slutin. T ensure SDN/OpenFlw prducts meet specificatins ONF has defined cnfrmance test specificatins. Furthermre ONF has authrized test labs t perfrm the cnfrmance testing. In additin t cnfrmance testing it is als imprtant t knw the perfrmance f the SDN devices like switches t get infrmatin n hw well an OpenFlw enabled switch perfrms OpenFlw message prcessing and data packet frwarding. This White Paper describes relevant OpenFlw perfrmance tests and explains hw L2-3 test platfrms ValkyrieBay and ValkyrieCmpact equipped with apprpriate test mdules prvide the features needed t quickly and cst-effectively test and verify the OpenFlw perfrmance f switches in the SDN. SDN with OpenFlw switches prmises flexibility and fast cnfiguratin f cmmunicatin netwrks. Hwever test and verificatin f OpenFlw switch perfrmance is essential. 1

2 OpenFlw Perfrmance Testing Cntents OVERVIEW... 1 INTRODUCTION... 3 OpenFlw Specificatins... 6 Other Prtcls fr the SDN Open Suthbund API... 6 OpenFlw Perfrmance Testing... 6 OpenFlw Message Prcessing Perfrmance... 7 OpenFlw Data Packet Frwarding Perfrmance... 9 OpenFlw Vendrs Xena Netwrks OpenFlw Perfrmance Test Slutins Testing up t Layer CONCLUSION

3 INTRODUCTION Cmmunicatin has always been essential and mdern technlgy has prvided increasing numbers f applicatins and slutins. Cmmunicatin netwrks have been expanded and updated t supprt the new applicatins and slutins, which hwever have caused an increasing cmplexity f the netwrks. Traditinally netwrks have been built with dedicated, autnmus netwrk devices like ruters, switches, and firewalls, each being designed fr a specific task. Decisins n data frwarding are dne in the netwrk devices based n varius algrithms and prtcls. The devices cmmunicate with each ther, but there is n centralized device that has the verall cntrl. Once set up and cnfigured the netwrk wuld wrk fine, but changing the behavir f the netwrk can be cstly, cumbersme and time cnsuming if pssible at all. A new cncept Sftware-Defined Netwrking (SDN) is generating huge interest because it prmises t add higher flexibility and faster cnfiguratin f netwrks. SDN is split int a cntrl plane (which decides where the traffic is sent) and a data plane (r frwarding plane), which frwards traffic in the directin f the destinatin accrding t cntrl plane decisins. Figure 1: SDN architecture SDN netwrk applicatins are lcated n tp f the cntrl plane. The netwrk applicatins will have requirements fr the behavir f the netwrk, which they will cmmunicate t the cntrller(s) in the cntrl plane thrugh the pen nrthbund API. The Open Netwrking Fundatin (ONF) has defined the OpenFlw switch specificatin. It defines the functining f a Data frwarding device in the Data plane (see figure 1). It als defines the OpenFlw prtcl fr cmmunicatin ver the Open suthbund API between an OpenFlw switch and a cntrller in the Cntrl plane. OpenFlw switches in the Data plane frward data based n flw tables, which are prgrammed by the cntrller in the Cntrl plane using the OpenFlw prtcl. The cntents f the flw 3

4 table have develped ver the years. In the first versin f the OpenFlw switch specificatin each table entry was defined as shwn in figure 2. Header Fields Cunters Actins Figure 2: OpenFlw switch specificatins flw table entry Header fields t match against received packets Cunters t be updated fr packet matching the header fields e.g.: Number f packets and bytes fr each flw Time since the last packet matched the flw The specificatins include a list f mandatry cunters that the OpenFlw switches must supprt and a number f ptinal cunters that may be supprted by the OpenFlw switches Actins t apply t packets matching the header fields e.g.: Ingres s prt Send the packet t a specific utput prt Mdify a header field in the packet Drp the packet Eth. SA Eth. DA Eth. typ e VLA N ID VLA N pri IP S A IP D A IP prt IP TO S TCP/UD P surce TCP/UDP destinati n Figure 3: Header fields defined in OpenFlw switch specificatins (the 12 tuple ) Up t OpenFlw switch specificatin the flw table entry was extended as shwn in figure 4. Als the Match Fields (Header Fields) were extended frm versin t versin t als cver mre prtcls like MPLS, PBB, IPv6 and ptinally metadata specified by a previus table. Match Fields Pririty Cunters Instructins Timeuts Ckie Figure 4: OpenFlw switch specificatins flw table entry A flw is ne r mre data packets that match the cntents f the Match Fields ( Header Fields ) part f a flw table entry. When a data packet is received, the OpenFlw switch will cmpare header fields in packet with the flw table entries. If there is a match, cunters will be updated and the actins/instructins specified in the flw table entry will be executed. A packet that des nt match any flw table entry can be sent t the OpenFlw cntrller, which may drp the packet r add a new flw table entry that can handle the new packet flw. In OpenFlw switch specificatin it was described that an OpenFlw switch must have at least ne and ptinally mre flw tables. When a data packet is received it must be matched 4

5 with all flw tables in an OpenFlw pipeline as illustrated in figure 5. Fr each table that the data packet passes the fllwing must be dne: Find the matching flw entry with highest pririty Apply instructins: Mdify packet and update match fields Update actin set Update metadata Send match data and actin set t the next table Figure 5: Packets are matched against multiple flw tables in the OpenFlw pipeline Table entry actins may direct data packets t a grup. The grup will define additinal actins e.g. fr flding, fast rerute and link aggregatin. This is defined in grup tables, which cntains grup entries with a list f actin buckets. An actin bucket is a set f actins and parameters fr the grup. The cntrller can add, mdify r delete flw table entries using FlwMd messages. When the flw table entry is updated the switch will prcess data packets in the flw matching the updated flw table entry at line rate. A cncept related t SDN is Netwrk Functin Virtualizatin (NFV). NFV is the verall principle f implementing netwrk functins (like ruting, intrusin detectin and intrusin preventin) as sftware running Cmmercial Off-The-Shelf (COTS) hardware. Functins implemented this way are called Virtual Netwrk Functins (VNF). OpenFlw switches culd be created as VNFs. Alternatively the OpenFlw switches are dedicated prducts, which typically use Ternary Cntent Addressable Memry (TCAM) and prprietary sftware t supprt the handling f the flw table and the OpenFlw prtcl. TCAM is a specialized type f high-speed memry that searches its entire cntents fr sme data in a single peratin and returns the address where the data is stred. A TCAM can stre and lk up data using 0, 1 and dn t care, which makes it very efficient fr handling flw tables. 5

6 OpenFlw Specificatins The Open Netwrking Fundatin (ONF) is a nn-prfit, user-driven rganizatin dedicated t accelerating the adptin f SDN & NFV. ONF members include mre than 100 cmpanies e.g. equipment manufacturers and peratrs please refer t the ONF member list. Since December 2009 ONF has published OpenFlw switch specificatins (see table 1). OpenFlw Specificatin Versin Released December February December June September Octber December March 2015 Table 1: A selectin f the OpenFlw switch specificatins published by ONF OpenFlw prducts will in mst cases cmply with specificatin versin and/r Other Prtcls fr the SDN Open Suthbund API The OpenFlw prtcl is the mst cmmnly used prtcl fr the SDN Open Suthbund API. Hwever SDN des nt require that the OpenFlw prtcl is used, and there are ther prtcls that may be used fr the SDN Open Suthbund API, including: Frwarding and Cntrl Element Separatin (FrCES), which is standardized by IETF Lcatr/ID Separatin Prtcl (LISP), defined by the IETF NetCnf/YANG, defined by the IETF Path Cmputatin Element Prtcl (PCEP) OpenFlw Perfrmance Testing Several types f testing are relevant fr OpenFlw switches: OpenFlw perfrmance testing will prvide infrmatin n an OpenFlw capable switch. With this it can be verified that the switch behaves as expected. Furthermre the tests will 6

7 prvide infrmatin with which different switches can be cmpared. OpenFlw perfrmance testing cvers: OpenFlw message prcessing Data packet frwarding In bth cases it will be necessary t send OpenFlw messages frm a cntrller t the OpenFlw switches thrugh the pen suthbund API as a part f the test. OpenFlw cnfrmance testing will verify that a prduct cmplies with the OpenFlw specificatins. ONF has defined cnfrmance test specificatins and have als authrized a number f cnfrmance testing labs (see Authrized Test Labs n the ONF web page). OpenFlw cnfrmance testing is utside the scpe f this White Paper. OpenFlw Message Prcessing Perfrmance Several tests can be perfrmed t verify OpenFlw message perfrmance, including: Flw-Md respnse time Flw table capacity Packet-In/Packet-Out capacity Timeut verificatin OpenFlw pipeline latency Figure 6: Test setup fr OpenFlw perfrmance testing OpenFlw message prcessing 7

8 Flw-Md respnse time is the time it takes frm a flw table entry is sent frm a cntrller until the actins/instructins in the entry is implemented in the OpenFlw switch. This can be tested by adding (r changing) a flw table entry specifying that a flw f data packet shuld be frwarded frm prt A t prt B. If yu capture the OpenFlw messages t the switch under test n the pen suthbund API and data packets frm an Ethernet tester generating traffic frm prt A t B yu can use Wireshark t see the time stamp f the Flw-Md message setting up the table entry and the time stamp f the first data packet that is sent n prt B. With the tw time stamps yu can calculate the time it tk t implement the flw table entry. A similar test can be cnducted fr flw table entries that are deleted. Flw table capacity can be tested by first deleting all entries in a flw table and then inserting entries in that table until errr messages indicate that the table is full. As a part f the test it shuld be verified with an Ethernet tester that at least sme f the entries have actually been installed: If the entry specifies that a flw f data packet shuld be frwarded frm prt A t prt B, an Ethernet tester can be cnnected t the tw prts, set up t generate data packets matching the flw and verify that the packets actually g frm prt A t prt B. Numerus streams f data packets shuld be generated emulating different flws t see that all flws are handled in accrdance with the cntents f the flw tables. Packet-in/packet-ut capacity: Packet-in is a facility in the OpenFlw prtcl that transfers the cntrl f a data packet t the OpenFlw cntrller. The data packet is embedded in an OpenFlw packet-in message, which als cntains the reasn fr sending the packet t the cntrller: N matching flw ( table-miss ) An actin explicitly defines that the packet must be sent t cntrller Packet has an invalid TTL The cntrller can send the packets received in the packet-in message back t the data plane in a packet-ut message. The packet-in/packet-ut facility can be used fr applicatins like MAC learning and tplgy discvery. The capacity fr sending packet-in/packet-ut is typically limited and shuld be checked. Packet-in capacity can be checked by making an entry in the flw table defining that packets must be utput t the cntrller. Then the Ethernet tester in figure 6 is used t send that type f packets starting with very few per secnd and increasing number f packets until the system is saturated. Packet-ut capacity is checked in a similar way, with the cntrller sending packet-ut messages. The cmmunicatin between the switch under test and the cntrller shuld be captured and presented in Wireshark fr detailed analysis. Timeut verificatin: Newer versins f the OpenFlw specificatin include a Timeut sectin in the table flw entries. Tw types f timeuts are supprted: Hard timeuts the maximum amunt f time an entry is active in the flw table regardless f the activity in the flw. 8

9 Idle timeuts the time withut activity in the flw befre the related table entry expires T verify hard timeuts yu can capture the FlwMd message creating a flw table entry directing a flw f data packets frm prt A t prt B. If yu send packets frm prt A t prt B and als capture these packets, yu can use Wireshark t cmpare the timestamp f the FlwMd message and the last received data package n prt B t verify the hard timeut. Idle timeuts fr a flw table entry that defines data packets t be sent frm prt A t prt B can be verified by first sending traffic frm prt A t B, then stpping and then send ne data packet int prt A after the idle timeut has expired. N data packets shuld appear n prt B. Instead a packet-in message may appear sent frm the switch under test t the cntrller t infrm abut the packet that dn t fit with the flw table entries (table-miss). This can be seen by capturing the OpenFlw messages sent between the switch and the cntrller. OpenFlw pipeline latency measurements will shw the implicatin f having multiple tables in a switch with many matches and actin set updates cmpared with simple tables with nly ne r tw matches. This is measured by creating flw table entries that emulates the tw situatins and measure the latency thrugh the switch in the setup shwn in figure 6. OpenFlw Data Packet Frwarding Perfrmance Figure 7: Test setup fr OpenFlw perfrmance testing Data packet frwarding When an SDN is cnfigured the Data packet frwarding perfrmance f the data plane can be tested. This includes verificatin f: Thrughput maximum data rate that can be transferred thrugh the device/path Latency time it takes t transfer data thrugh the device/path Frame lss data frames lst during the transfer f data thrugh the device/path 9

10 Back-t-back frames identifies the lngest burst f frames with minimum inter-frame gaps that can be sent thrugh the device/path withut frame lss Jitter variatin in delay f transferred data packets (als knwn as Frame Delay Variatin) Testing is in typically dne in accrdance with the RFC 2544 Benchmarking Methdlgy fr Netwrk Intercnnect Devices tests. RFC 2544 specifies thrughput, latency, frame lss and backt-back testing mst Ethernet testers als include jitter testing in their RFC 2544 test suite. The test setup in figure 7 shuld be used fr end-t-end RFC 2544 testing f a path thrugh a number f OpenFlw switches. If a single OpenFlw switch is tested in accrdance with RFC 2544 the test setup in figure 6 will be relevant. Enterprise custmers typically sign Service Level Agreements (SLAs) with a netwrk peratr fr their cmmunicatin path thrugh a netwrk. This will als apply fr paths thrugh a SDN with OpenFlw switches in the data plane. Therefre it will be relevant t verify that the requirements in the SLA are fulfilled when flw tables are set up t supprt the custmers requirements. ITU-T has defined the Y.1564 standard fr turning up, installing and truble-shting Ethernet-based services. Y.1564 allws a cmplete validatin f Ethernet SLAs in a single test. Y.1564 fcuses n the fllwing service level parameters: Infrmatin rate (IR) r Bandwidth Frame transfer delay (FTD) r latency Frame delay variatin (FDV) r packet jitter Frame lss rati (FLR) Availability (AVAIL) The test setup in figure 7 is relevant fr the Y.1564 test. It will measure the parameters fr the tw directins f a cnnectin separately with tw testers ne at each end f the cnnectin. T identify FTD fr each directin it is hwever necessary the synchrnize time stamps in the tw testers, typically using Precisin Time Prtcl (PTP), Netwrk Time Prtcl (NTP) r Glbal Psitining System (GPS). A SLA will guarantee Service Acceptance Criteria (SAC), which are wrst case values fr FTD, FDV, FLR and AVAIL at a Cmmitted Infrmatin Rate (CIR) the maximum bandwidth guaranteed by the netwrk peratr t the custmer. The SLA can als include a cmmitment n hw large bursts the netwrk will accept - the Cmmitted Burst Size (CBS). The netwrk peratr may allw that bth CIR and CBS are exceeded t sme extend: Excess Infrmatin Rate (EIR) and Excess Burst Size (EBS). Hwever when CIR r CBS are exceeded it is nt expected that the SACs are met. 10

11 OpenFlw Vendrs A number f vendrs are nw ffering OpenFlw slutins, including: Cisc Ericssn FiberHme Telecmmunicatin Technlgies Hangzhu DPtech Technlgies Hewlett Packard Enterprise Huawei Technlgies NEC Crpratin ZTE Crpratin ONF maintains a list f ONF OpenFlw Cnfrmant/Certified Prducts. Xena Netwrks OpenFlw Perfrmance Test Slutins Figure 8: The versatile and pwerful Xena Netwrks Layer 2-3 testers ValkyrieBay and ValkyrieCmpact The versatile and pwerful Xena Netwrks Valkyrie Layer 2-3 testers ValkyrieBay and ValkyrieCmpact are the bvius chice fr OpenFlw perfrmance testing. When the Xena testers are equipped with the ValkyrieTimeSynch their clcks can be synchrnized. Testing up t Layer 3 Based n Xena s advanced architecture, ValkyrieBay and ValkyrieCmpact equipped with relevant test mdules are prven slutins fr Ethernet testing at layers 2 and 3. Advanced test scenaris can be perfrmed with ValkyrieBay and ValkyrieCmpact equipped with relevant test mdules using the free test applicatins fr the mdules: ValkyrieManager test sftware is used t cnfigure and generate streams f Ethernet traffic between Xena test equipment and Devices Under Test (DUTs)/Systems Under Test (SUTs) and analyze the results. ValkyrieManager features include: Multistream traffic generatin at line rate Generatin f traffic streams with different rates and packet sizes Generatin f IPv4 and IPv6 traffic Generatin f traffic streams with UDP and TCP headers Generatin f frames with VLAN tags, MPLS labels and PBB tags 11

12 A Prt-t-Prt mde where frames received n ne prt are sent ut n anther prt. This can be used fr capturing OpenFlw messages between the cntrller and the switch under test in figure 6. The captured messages can be analyzed in Wireshark A Stream Scheduler, which can be used t build a sequence f actins like sending traffic, stpping after sme time and resuming sending traffic (which culd be just a single data packet) after anther perid f time One ValkyrieManager can cntrl multiple ValkyrieCmpact and ValkyrieBay test chassis, which can be lcated far away frm each ther, e.g. at the ends f cnnectins-t-be-tested supprting ne-way measurements. Valkyrie2544 ffers full supprt fr the 4 test types specified in RFC 2544: Thrughput Latency Frame lss Back-t-back frames Jitter (Frame Delay Variatin) is als supprted Valkyrie2544 supprts flw-based learning, which will emit a brief traffic preamble befre starting the actual test. This can be used t ensure that the flw-based switch has learned all necessary addresses, preventing a latency spike. Valkyrie1564 prvides full supprt fr bth the cnfiguratin and perfrmance test types described in Y.1564 fr cmplete validatin f Ethernet Service Level Agreements (SLAs) in a single test. ValkyrieTimeSynch enables multiple ValkyrieCmpact r ValkyrieBay test chassis t synchrnize their lcal time t each ther. This can be used fr One-Way Latency (OWL) measurements between tw test chassis, synchrnized traffic start between multiple chassis and accurate timestamping f captured packets in exprted PCAP files. ValkyrieTimeSynch is cmpatible with Valkyrie1564 test methdlgy and can be used fr Y.1564 OWL measurements. 12

13 Figure 9: ValkyrieTimeSynch synchrnizes reference time fr the Xena Valkyrie Layer 2-3 testers. Valkyrie2889 is an applicatin fr benchmarking the perfrmance f Layer 2 LAN switches. The fllwing RFC 2889 test types are supprted: All Thrughput and Frwarding rate tests (bth Fully and Partially meshed) Cngestin Cntrl Address Caching Capacity Address Learning Rate Bradcast Frame Frwarding and Latency Frward Pressure and Maximum Frwarding Rate Valkyrie3918 makes it easy t create, edit and execute all test types specified in RFC RFC 3918 describes tests fr measuring and reprting the thrughput, frwarding, latency and Internet Grup Management Prtcl (IGMP) grup membership characteristics f devices that supprt IP multicast prtcls. ValkyrieCLI is anther free applicatin fr ValkyrieBay and ValkyrieCmpact. It is a pwerful and easy-t-use cmmand-line-interface (CLI) scripting API that makes test autmatin easier fr test engineers: Ideal fr test autmatin f e.g. prductin envirnments Cntrls ValkyrieBay and ValkyrieCmpact chassis with installed test mdules Pwerful CLI apprach frm any TCP/IP capable tl envirnment Unified syntax fr CLI- and GUI-generated test prt cnfiguratins makes it easy t learn Script examples f Tcl, Perl, Java, Ruby, BASH and Pythn available Intelligent cnsle tl bundled free with ValkyrieManager CONCLUSION Traditinal cmmunicatin netwrks have been built with dedicated, autnmus devices like ruters, switches, and firewalls, each being designed fr a specific task. The result is ttally distributed netwrk cntrl, where decisins n data frwarding are dne in the netwrk devices based n varius algrithms and prtcls. Once set up and cnfigured the netwrk wuld wrk fine, but changing the behavir f the netwrk can be cstly, cumbersme and time cnsuming if pssible at all. Sftware-Defined Netwrking (SDN) is generating huge interest because it prmises t add higher flexibility and faster cnfiguratin f netwrks. 13

14 It is imprtant t knw the perfrmance f SDN devices like OpenFlw switches. This can prvide infrmatin n hw well the switch perfrms OpenFlw message prcessing and data packet frwarding. The Valkyrie L2-3 test platfrms ValkyrieBay and ValkyrieCmpact equipped with apprpriate test mdules prvide the features needed t quickly and csteffectively test and verify the OpenFlw perfrmance f switches in the SDN. 14