advances on software defined sensor, mobile, and fixed...

International Journal of Distributed Sensor Networks

Advances on Software Defined Sensor, Mobile, and Fixed Networks

Guest Editors: Luis Javier García Villalba, Jun Bi, Anura P. Jayasumana, and Ana Lucila Sandoval Orozco

Advances on Software Defined Sensor, Mobile,and Fixed Networks

International Journal of Distributed Sensor Networks

Advances on Software Defined Sensor, Mobile,and Fixed Networks

Guest Editors: Luis Javier García Villalba, Jun Bi,Anura P. Jayasumana, and Ana Lucila Sandoval Orozco

Copyright © 2016 Hindawi Publishing Corporation. All rights reserved.

This is a special issue published in “International Journal of Distributed Sensor Networks.” All articles are open access articles distributedunder the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, pro-vided the original work is properly cited.

Editorial Board

Jemal H. Abawajy, AustraliaMiguel Acevedo, USACristina Alcaraz, SpainAna Alejos, SpainMohammod Ali, USAGiuseppe Amato, ItalyHabib M. Ammari, USAMichele Amoretti, ItalyC. Anagnostopoulos, UKLi-Minn Ang, AustraliaNabil Aouf, UKFrancesco Archetti, ItalyMasoud Ardakani, CanadaMiguel Ardid, SpainMuhammad Asim, UKStefano Avallone, ItalyJose L. Ayala, SpainN. Balakrishnan, IndiaPrabir Barooah, USAFederico Barrero, SpainPaolo Barsocchi, ItalyPaolo Bellavista, ItalyOlivier Berder, FranceRoc Berenguer, SpainJuan A. Besada, SpainGennaro Boggia, ItalyAlessandro Bogliolo, ItalyEleonora Borgia, ItalyJanos Botzheim, JapanFarid Boussaid, AustraliaArnold K. Bregt, NetherlandsRichard R. Brooks, USATed Brown, USADavide Brunelli, ItalyJames Brusey, UKCarlos T. Calafate, SpainTiziana Calamoneri, ItalyJosé Camacho, SpainJuan C. Cano, SpainXianghui Cao, USAJ. Paulo Carmo, BrazilRoberto Casas, SpainLuca Catarinucci, ItalyMichelangelo Ceci, ItalyYao-Jen Chang, Taiwan

Naveen Chilamkurti, AustraliaWook Choi, Republic of KoreaH. Choo, Republic of KoreaKim-Kwang R. Choo, AustraliaChengfu Chou, TaiwanMashrur A. Chowdhury, USATae-Sun Chung, Republic of KoreaMarcello Cinque, ItalySesh Commuri, USAMauro Conti, ItalyAlfredo Cuzzocrea, ItalyDonatella Darsena, ItalyDinesh Datla, USAAmitava Datta, AustraliaIyad Dayoub, FranceDanilo De Donno, ItalyLuca De Nardis, ItalyFloriano De Rango, ItalyPaula de Toledo, SpainMarco Di Felice, ItalySalvatore Distefano, ItalyLongjun Dong, ChinaNicola Dragoni, DenmarkG. P. Efthymoglou, GreeceFrank Ehlers, ItalyM. Erol-Kantarci, CanadaFarid Farahmand, USAMichael Farmer, USAF. Fdez-Riverola, SpainGianluigi Ferrari, ItalySilvia Ferrari, USAGiancarlo Fortino, ItalyLuca Foschini, ItalyJean Y. Fourniols, FranceDavid Galindo, SpainEnnio Gambi, ItalyWeihua Gao, USAA. García-Sánchez, SpainPreetam Ghosh, USAAthanasios Gkelias, UKIqbal Gondal, AustraliaFrancesco Grimaccia, ItalyJayavardhana Gubbi, AustraliaSong Guo, JapanAndrei Gurtov, Finland

Mohamed A. Haleem, USAKijun Han, Republic of KoreaQi Han, USAZdenek Hanzalek, Czech RepublicShinsuke Hara, JapanWenbo He, CanadaPaul Honeine, FranceFeng Hong, ChinaChin-Tser Huang, USAHaiping Huang, ChinaXinming Huang, USAJose I. Moreno, SpainMohamed Ibnkahla, CanadaSyed K. Islam, USALillykutty Jacob, IndiaWon-Suk Jang, Republic of KoreaAntonio J. Jara, SwitzerlandShengming Jiang, ChinaYingtao Jiang, USANing Jin, ChinaRaja Jurdak, AustraliaKonstantinos Kalpakis, USAIbrahim Kamel, UAEJoarder Kamruzzaman, AustraliaRajgopal Kannan, USAJohannes M. Karlsson, SwedenGour C. Karmakar, AustraliaMarcos D. Katz, FinlandSherif Khattab, EgyptHyungshin Kim, Republic of KoreaSungsuk Kim, Republic of KoreaAndreas König, GermanyG. Küçük, TurkeySandeep S. Kumar, NetherlandsJuan A. L. Riquelme, SpainYee Wei Law, AustraliaAntonio Lazaro, SpainDidier Le Ruyet, FranceJoo-Ho Lee, JapanSeokcheon Lee, USAYong Lee, USAStefano Lenzi, ItalyPierre Leone, SwitzerlandShancang Li, UKShuai Li, USA

Qilian Liang, USAWeifa Liang, AustraliaYao Liang, USAI-En Liao, TaiwanJiun-Jian Liaw, TaiwanAlvin S. Lim, USAAntonio Liotta, NetherlandsDonggang Liu, USAHai Liu, Hong KongYonghe Liu, USALeonardo Lizzi, FranceJaime Lloret, SpainKenneth J. Loh, USAFrancesco Longo, ItalyJuan Carlos López, SpainManel López, SpainPascal Lorenz, FranceJun Luo, SingaporeMichele Magno, ItalySabato Manfredi, ItalyAthanassios Manikas, UKPietro Manzoni, SpainÁlvaro Marco, SpainJ. R. Martinez-de Dios, SpainAhmed Mehaoua, FranceNirvana Meratnia, NetherlandsChristian Micheloni, ItalyLyudmila Mihaylova, UKPaul Mitchell, UKMihael Mohorcic, SloveniaJosé Molina, SpainAntonella Molinaro, ItalySalvatore Morgera, USAKazuo Mori, JapanLeonardo Mostarda, ItalyV. Muthukkumarasamy, AustraliaAmiya Nayak, CanadaGeorge Nikolakopoulos, SwedenAlessandro Nordio, ItalyMichael J. O’Grady, Ireland

Gregory O’Hare, IrelandGiacomo Oliveri, ItalySaeed Olyaee, IranLuis Orozco-Barbosa, SpainSuat Ozdemir, TurkeyVincenzo Paciello, ItalySangheon Pack, Republic of KoreaMarimuthu Palaniswami, AustraliaMeng-Shiuan Pan, TaiwanSeung-Jong Park, USAMiguel A. Patricio, SpainLuigi Patrono, ItalyRosa A. Perez-Herrera, SpainPedro Peris-Lopez, SpainJanez Perš, SloveniaDirk Pesch, IrelandShashi Phoha, USARobert Plana, FranceC. Pomalaza-Ráez, FinlandNeeli R. Prasad, DenmarkAntonio Puliafito, ItalyHairong Qi, USAMeikang Qiu, USAVeselin Rakocevic, UKNageswara S.V. Rao, USALuca Reggiani, ItalyEric Renault, FranceJ. J. P. C. Rodrigues, PortugalPedro P. Rodrigues, PortugalLuis Ruiz-Garcia, SpainMohamed Saad, UAEStefano Savazzi, ItalyMarco Scarpa, ItalyArunabha Sen, USAOlivier Sentieys, FranceSalvatore Serrano, ItalyZhong Shen, ChinaChin-Shiuh Shieh, TaiwanMinho Shin, Republic of KoreaPietro Siciliano, Italy

Olli Silven, FinlandHichem Snoussi, FranceGuangming Song, ChinaAntonino Staiano, ItalyMuhammad A. Tahir, PakistanJindong Tan, USAShaojie Tang, USALuciano Tarricone, ItalyKerry Taylor, AustraliaSameer S. Tilak, USAChuan-Kang Ting, TaiwanSergio Toral, SpainVicente Traver, SpainIoan Tudosa, ItalyAnthony Tzes, GreeceBernard Uguen, FranceF. Vasques, PortugalKhan A. Wahid, CanadaA. B. Waluyo, AustraliaHonggang Wang, USAJianxin Wang, ChinaJu Wang, USAThomas Wettergren, USARan Wolff, IsraelChase Wu, USANa Xia, ChinaQin Xin, Faroe IslandsChun J. Xue, Hong KongYuan Xue, USAGeng Yang, ChinaT. Zahariadis, GreeceMiguel A. Zamora, SpainHongke Zhang, ChinaXing Zhang, ChinaJiliang Zhou, ChinaTing L. Zhu, USAXiaojun Zhu, ChinaYifeng Zhu, USADaniele Zonta, Italy

Contents

Advances on Software Defined Sensor, Mobile, and Fixed NetworksLuis Javier García Villalba, Jun Bi, Anura P. Jayasumana, and Ana Lucila Sandoval OrozcoVolume 2016, Article ID 5153718, 2 pages

A Security Authentication Protocol for Trusted Domains in an Autonomous Decentralized SystemRuikang Zhou, Yingxu Lai, Zenghui Liu, Yinong Chen, Xiangzhen Yao, and Jiezhong GongVolume 2016, Article ID 5327949, 13 pages

OpenFlow-Based Mobility Management Scheme and Data Structure for the Mobility Service at SoftwareDefined NetworkingPill-Won Park, Seong-Mun Kim, and Sung-Gi MinVolume 2016, Article ID 3674192, 9 pages

SALMA: An Efficient State-Based Hybrid Routing Protocol for Mobile Nodes in Wireless SensorNetworksMuhammad Muneer Umar, Nabil Alrajeh, and Amjad MehmoodVolume 2016, Article ID 2909618, 11 pages

The SELFNET Approach for Autonomic Management in an NFV/SDN Networking ParadigmPedro Neves, Rui Calé, Mário Rui Costa, Carlos Parada, Bruno Parreira, Jose Alcaraz-Calero, Qi Wang,James Nightingale, Enrique Chirivella-Perez, Wei Jiang, Hans Dieter Schotten, Konstantinos Koutsopoulos,Anastasius Gavras, and Maria João BarrosVolume 2016, Article ID 2897479, 17 pages

SDN-Based Active Content NetworkingTai-Won Um, Gyu Myoung Lee, and Jinsul KimVolume 2016, Article ID 1603239, 6 pages

QoE-Driven, Energy-Aware Video Adaptation in 5G Networks:The SELFNET Self-Optimisation UseCaseJames Nightingale, Qi Wang, Jose M. Alcaraz Calero, Enrique Chirivella-Perez, Marian Ulbricht,Jesús A. Alonso-López, Ricardo Preto, Tiago Batista, Tiago Teixeira, Maria Joao Barros,and Christiane ReinschVolume 2016, Article ID 7829305, 15 pages

Energy-Efficient Monitoring in Software Defined Wireless Sensor Networks Using ReinforcementLearning: A PrototypeRu Huang, Xiaoli Chu, Jie Zhang, and Yu Hen HuVolume 2015, Article ID 360428, 12 pages

EditorialAdvances on Software Defined Sensor,Mobile, and Fixed Networks

Luis Javier García Villalba,1 Jun Bi,2 Anura P. Jayasumana,3

and Ana Lucila Sandoval Orozco1

1The Complutense University, 28040 Madrid, Spain2Tsinghua University, Beijing 100084, China3Colorado State University, Fort Collins, CO 80523-1373, USA

Correspondence should be addressed to Luis Javier Garćıa Villalba; [email protected]

Received 13 March 2016; Accepted 14 March 2016

Copyright © 2016 Luis Javier Garćıa Villalba et al. This is an open access article distributed under the Creative CommonsAttribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work isproperly cited.

1. Introduction

The continued development of microelectromechanical sys-tems (MEMS) that continually record, process, and sendinformation has brought about a considerable increase inthe data traffic. In order to cover the increasing connectivityneeds, the new sensor and mobile devices use multiplenetwork infrastructures to send information (WiFi, 5G, LTE,WSN, and Bluetooth, among others). This new intercon-nected environment has led the origin of a new growingmarket scenario based on services and applications. However,the rigidity of actual network architectures, the dependencyon a specific manufacturer or service provider, and theclosed union between data and control planes in networkinfrastructures have limited the development applications interms of scalability, mobility, security, energy efficiency, andquality of service (QoS).

In this context, the novel concept of Software DefinedNetworking (SDN) can help solve these limitations. SDNallows the centralized control of the network behaviorthrough external software, separating the data and thecontrol plane in network devices. This new paradigm canbe extended to other network infrastructures, decouplingthe transmission and control plane in base stations, accesspoints, andwireless sensor agents.This new vision of softwaredefined heterogeneous network opens new opportunities toshare infrastructures and standardize interfaces, on-demandservices, network programmability, and optimization of

resources, novel services, and enhanced mechanisms fordynamic resource management. The present special issuereflects the last advances on research in the followingfields: Software Defined Sensor Networks (SDSN), SoftwareDefinedMobileNetworks (SDMN),Novel 5G, SDN andNFVarchitectures, and integration of software defined technolo-gies with traditional network architectures.

2. Related Works

M. M. Umar et al. presented a new hybrid routing pro-tocol, named as State-Aware Link Maintenance Approach(SALMA). SALMA is based on Dynamic Source Routing(DSR) and Optimized Link State Routing (OLSR) protocols.The work also focuses on the activeness of nodes in thenetwork operations and defines three states of nodes, that is,white, gray, and black.The work concludes that the proposedprotocol gives improvements in some quality of servicemetrics like lower delay than DSR, lower routing overheadthan OLSR, and lesser energy consumption by the networknodes.

P. Neves et al. proposed a novel EU H2020 SELFNETmanagement framework upon the Software Defined andVirtualized Network paradigms. The SELFNET referencearchitecture is divided into Infrastructure Layer, VirtualizedNetwork Layer, SON Control Layer, SON Autonomic Layer,NFV Orchestration and Management Layer, and Access

Hindawi Publishing CorporationInternational Journal of Distributed Sensor NetworksVolume 2016, Article ID 5153718, 2 pageshttp://dx.doi.org/10.1155/2016/5153718

http://dx.doi.org/10.1155/2016/5153718

2 International Journal of Distributed Sensor Networks

Layer. The present architecture is advancing in following thechallenging key performance indicator of the fifth generation(5G) system, where the network infrastructure becomesmore heterogeneous and complex. The framework will assistnetwork operators to simplify the key management tasksand save the man power. For example, SDN/NFV sensorsthat can monitor the network and SDN/NFV actuators thatcan perform corrective and preventive actions to mitigateexisting or potential network problems can be automaticallydeployed. SELFNET aims to address three major networkmanagement concerns, that is, providing self-protectioncapabilities against distributed cyber-attacks, self-healingcapabilities against network failures, and self-optimizationfeatures to dynamically improve the performance of thenetwork and the QoE of the end users.

T.-W. Um et al. proposed Software Defined Networking-(SDN-) based active content networking architecture forfuture media environments. The proposed architecture aimsto provide customized delivery of various types of mediacontent in order to satisfy users’ demand and service require-ments. To this end, the authors have developed an activecontent processingmodel which provides in-network contentprocessing through service objects that are integral parts ofactive content. The main benefits provided by the proposedmodel are high flexibility and creativity to meet the evolvingfuture media environments.

J. Nightingale et al. introduce the SELFNET 5G projectand describe the video streaming use case that will be usedto demonstrate the self-optimizing capabilities of SELFNET’sautonomic network management framework. SELFNET’sframework will provide an advanced self-organizing network(SON) underpinned by seamless integration of SoftwareDefined Networking (SDN), Network Function Virtualiza-tion (NFV), and network intelligence. The self-optimizationvideo streaming use case is going beyond traditional qualityof service approaches to network management. A set ofmonitoring and analysis components will facilitate a user-oriented, quality of experience (QoE), and energy-awareapproach. Firstly, novel SON Sensors will monitor bothtraditional network state metrics and new video and energyrelated metrics. The combination of these low level met-rics provides highly innovative health of network (HoN)composite metrics. HoN composite metrics are processedvia autonomous decisions not only maintaining but alsoproactively optimizing users’ video QoE while minimizingthe end-to-end energy consumption of the 5G network. Thiscontribution provided a detailed technical overview of thisambitious use case.

R. Huang et al. presented a software defined WSN(SDWSN) prototype to improve the energy efficiency andadaptability of WSNs for environmental monitoring applica-tions, taking into account the constraints ofWSNs in terms ofenergy, radio resources, and computational capabilities andthe value redundancy and distributed nature of data flowsin periodic transmissions for monitoring applications. Thedesign enables a reinforcement learning based mechanismto perform value redundancy filtering and load-balancingrouting according to the values and distribution of data flows,respectively, in order to improve the energy efficiency and

self-adaptability to environmental changes for WSNs. Theoptimal matching rules in flow table are designed to curbthe control signaling overhead and balance the distribution ofdata flows for achieving in-network fusion in data plane withguaranteed quality of service (QoS). Experiment results showthat the proposed SDWSN prototype can effectively improvethe energy efficiency and self-adaptability of environmentalmonitoring WSNs with QoS.

Luis Javier Garćıa VillalbaJun Bi

Anura P. JayasumanaAna Lucila Sandoval Orozco

Research ArticleA Security Authentication Protocol for Trusted Domains inan Autonomous Decentralized System

Ruikang Zhou,1,2,3,4 Yingxu Lai,2,3,4 Zenghui Liu,5 Yinong Chen,6

Xiangzhen Yao,1 and Jiezhong Gong1

1China Electronics Standardization Institute, Beijing 100007, China2College of Computer Science, Beijing University of Technology, Beijing 100124, China3Beijing Key Laboratory of Trusted Computing, Beijing 100124, China4National Engineering Laboratory for Critical Technologies of Information Security Classified Protection, Beijing 100124, China5Automation Engineering Institute, Beijing Polytechnic, Beijing 100176, China6School of Computing, Informatics, and Decision Systems Engineering, Arizona State University, Tempe, AZ 85287, USA

Correspondence should be addressed to Yingxu Lai; [email protected]

Received 8 October 2015; Revised 24 December 2015; Accepted 30 December 2015

Academic Editor: Luis Javier Garcia Villalba

Copyright © 2016 Ruikang Zhou et al. This is an open access article distributed under the Creative Commons Attribution License,which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.

Software Defined Network (SDN) architecture has been widely used in various application domains. Aiming at the authenticationand security issues of SDN architecture in autonomous decentralized system (ADS) applications, securing the mutual trust amongthe autonomous controllers, we combine trusted technology and SDN architecture, and we introduce an authentication protocolbased on SDN architecture without any trusted third party between trusted domains in autonomous systems. By applying BANpredicate logic and AVISPA security analysis tool of network interaction protocol, we can guarantee protocol security and providecomplete safety tests. Our work fills the gap of mutual trust between different trusted domains and provides security foundationfor interaction between different trusted domains.

1. Introduction

Autonomous decentralized systems (ADS) have beenextended and applied to a variety of domains [1–6].Themainextension in ADS is to implement the dynamic manage-ment and to optimize the allocation of virtualized computing,storage, device controllers, and cyber resources. The currentmajor platforms aremature inmanagement and optimizationof traditional computing and storage resources. However,the dynamic management and the allocation of ADSdevices as cyber resources are a new problem which has notbeen studied thoroughly. The problem is mainly from net-work architecture design.The traditional TCP/IP architecturecannot meet the increasing demands, especially the virtua-lized network and ADS services. Thus, ADS needs new net-work architecture and techniques with flexibility, robustness,security, and credibility to solve the problem.

In the next generation network architecture design, manyexperts and scholars have completed a series of remarkable

research work. Specifically, OpenFlow [7], introduced byNick McKeown, gave researchers a way to run experimen-tal protocols in the networks. Based on Software DefinedNetwork (SDN) and OpenFlow protocol, researchers imple-mented network management and security functions mainlyin the aspects of control, traffic forwarding, and load bal-ancing. But the security issue in OpenFlow design shouldbe thoroughly concerned, especially the security interactionfunction between different controllers’ nodes. The problemof security certification issues between the different singlecontrollers limits the interaction range of a SDN architecture,which is only used in a single domain with a single controller,such as the Data Center.

In order to solve secure interaction issues, experts andscholars have completed a series of research work. Reference[7] proposed the SANE network architecture in which logiccontrollers could provide secure authentication for deviceaccess and loading strategy. Moreover, [8] further extendedSANE network architecture with data forwarding strategy


http://dx.doi.org/10.1155/2016/5327949


by using core controller method. The improved architectureimplemented with data forwarding function, in a certainextent, could solve the security threats between controllerlayer and data forwarding layer.

Reference [9] implemented a new network architectureGENI and recognized that a large number of maliciousattacks and flood attacks can be easily spread throughlogic control layers and data forwarding layers and lead tocorresponding secure issues, for instance, DDoS attack.

Reference [10] evaluated the weakness of OpenFlowprotocol. The author thought OpenFlow had an accuratesecure certificationmethodbetween controllers and switches,but this method did not provide security mechanisms undertransport layer.

Based on SDN architecture, [11] did a comprehensiveanalysis for evaluating NOX, POX, Ryu, and Beacon [12–15]controllers in compatibility, reliability, security, and process-ing capacity. Focusing on the aspect of security, the authorspointed out that the reason tomost controllers’ security prob-lems was forged stream message length, protocol version, orwrong type of message flow.

Besides, in [16], the authors analyzed the entire SDN secu-rity issues and pointed out that the new network architecturewith a rapid response and antithreatening security mecha-nism was needed to be reestablished, especially in the differ-ences of security threats between controllers and traditionalnetwork.

Based on the above issues, one of the key features ofADS is to allow content-basedmessage broadcasting. In orderto ensure the real-time system, message package could notbe encrypted. The receiver node does not check whetherthe source address is valid or not, and whether the messagepackage has been tampered or not. It means that an attackercan set up the entire attack in essentially one operation.Whilethe security for ADS is drawing attention, it is an indisputablefact that there is a lack of effective methods to supportthose frameworks. The contributions of our paper are as fol-lows:

(1) Our paper introduces a new architecture to increasethe probability of guaranteeing the credibility forfuture network architecture by applying the ideas oftrusted network to ADS. The new architecture withtrusted functionmodules canmeasure sensitive infor-mation and provide a security interaction functionbetween different SDN domains.

(2) Based on the new architecture with trusted functionmodules, we propose a trusted domain authenticationprotocol that protects controllers’ credibility amongentire network architecture when communicatingwith a nontrusted third party. Trusted function mod-ules, such as Trusted Measurement Module (TMM)and TCG Software Stack (TSS), could provide a setof services to ensure authentication protocol’s secu-rity, for example, encryption, decryption, digital sign,or key management. The protocol gets trust certifica-tions among different trusted domains and providessecure base in domain session.

(3) We demonstrate security of our trusted domainauthentication protocol by BAN logic and AVISPAsecurity analysis system and perform a comparativeanalysis of our trusted domain authentication proto-col against some prevalent protocols, namely, IKEv2[17], IDAKE-MA, and SKAP [18], in performanceanalysis. We believe that the protocol performance,including calculating consumption and storage con-sumption, is an index which can give us obviouslyevidence to prove advantage of our protocol.

This paper is organized as follows. Section 2 introducesa SDN trusted domain network architecture and describesour trusted domain authentication protocol. In Section 3, wedemonstrate security of our protocol by the BAN logic [19]. InSection 4, we analyze security of our protocol with differentmalicious test scenarios by AVISPA security analysis system[20]. Section 5 performs an analysis between our protocoland some authentication protocols.

2. Security Authentication Protocol forADS Applications

As shown in Figure 1, we propose a SDN trusted domainnetwork architecture which combines SDN and trusted com-puting. This architecture contains a single controller and anumber of network devices. For solving the trust certificationproblem among trusted domains, we design somemodules inSDN controller. TMM, based on TSS [21], is used to measurethe sensitive information of SDN controller and connectnetwork devices. Sensitive information includes controllerplatform hardware information, controller platform OSinformation, controller software information, and trustedfunction modules information. Controller Flow Rule (CFR)is trusted policy, including SDN data forwarding strategyand trusted measurement strategy, which was measured byTMM. Controller Communication Module (CCM) ensurescontroller authentication process between individual trusteddomains.

In SDN trusted domain network architecture, we proposea domain secure certificated protocol between SDN trusteddomains, and, in particular, our protocol can be utilized onnontrusted third party circumstance. From the viewpoint ofthe trusted chain [22], we can implement a consistency test ofmeasuring information integrity about controller hardware,operating system, controller software, and CCM for trustednegotiation. After finishing trusted negotiation, we can adoptthemethod ofmultilevel authentication to guarantee security.More specific, controller authentication can be divided intotwo parts, controller platform authentication and controllersoftware authentication, which protects the release of sen-sitive information and prevents unauthorized users fromcapturing sensitive information.The combination of sensitiveinformation and random numbers, based on the strongprotection of sensitive information, ensures that sensitiveinformation is not being hijacked and not subject to replayattacks by unauthorized users, thereby avoiding the securityof sensitive information by refusing the connection of thoseillegal or security risks.

International Journal of Distributed Sensor Networks 3

CCM CCMCFR

Networkcontrollersoftware

TMM

TSS

Control and management

Data layer

Data plane physical/logical connectionsOpenFlow protocol

SDN controller details

CFR

Networkcontrollersoftware

TMM

TSS

SDN controller details

Trusted measurement

Controller authentication process1

SDN controller

SDNdevice

SDNdevice

SDNdevice

SDNdevice

SDNdevice

SDNdevice

SDN controller

1

Figure 1: SDN trusted domain network architecture.

2.1. Protocol Certification Process Overview. Before we designour security certification protocol, we present the threemajoraspects of our protocol certification process.

First, in accordance with the trust chain transfer rulesin trusted computing, the TMM is based on TSS and willfollow the orders by measuring sensitive information of SDNcontroller hardware, operating system, CCM, and storingmeasurement results into RTS (Root Trusted Storage) of thePCR register.

Second, the controller platform certification: when imple-menting different trusted domain controller authentication,authentication requester sends the HMAC calculation resultsof hardware information, operating system, and randomnumbers to the receiver, respectively, and expects the iden-tical HMAC result with the receivers. If the controllerplatform’s HMAC result of the receiver is consistent with thatof the requester, then we complete the certification process ofcontroller platform.

Finally, the controller software certification: in terms ofimplementing the trusted authentication of sensitive infor-mation in controller software, the requester sends HMACcalculation results, including controller software metrics,core controller module metrics, and random numbers, to thereceiver. As shown in the controller platform certification inFigure 1, the receiver will compare the controller softwareHMAC results with that of the requester. If their resultsare consistent, we complete the certification of the controllersoftware.

2.2. Specific Certification Process. First, we define the relatedsymbols used in the certification process:

(1) 𝑅: authentication requester,(2) 𝑁: authentication receiver,(3) 𝑁PUB: authentication requester public key,(4) 𝑅PUB: authentication receiver public key,(5) 𝑁−1: authentication requester private key,(6) 𝑅−1: authentication receiver private key,(7) Plat ID

𝑅

: authentication requester platform ID,(8) Plat ID

𝑁

: authentication receiver platform ID,(9) Nonce

𝑅

: random number of authentication requester,used to measure HMAC and prevent replay attack,

(10) Nonce𝑁

: random number of authentication receiver,used to measure HMAC and prevent replay attack,

(11) AK𝑅

: random number of authentication requester,used to make a session key by authentication receiver,

(12) AK: session key,(13) ACK: authentication successful symbol,(14) CS ID

𝑅

: controller software ID of authenticationrequester,

(15) CS ID𝑁

: controller software ID of authenticationreceiver,


(16) 𝑅 PCR: controller platform hardware/controller plat-form OS/controller software/controller applicationmodule measurement of authentication requester,

(17) 𝑁 PCR: controller platform hardware/controllerplatform OS/controller software/controller applica-tion module measurement of authentication receiver,

(18) HMAC(): hash function based on HMAC SHA-1 ofTPM.

Figure 2 shows the specific certification process. Moredetails will be introduced in following two subsections.

2.2.1. Controller Platform Certification Process. Controllerplatform certification process consists of the following steps.

Step 1 (𝑅 (the requesting controller) sends an authenticationrequest to 𝑁 (the receiving controller)). First, 𝑅 creates adigital signature for its own controller platform identity infor-mation Plat ID

𝑅

, random numbers Nonce𝑅

, and hardwaresensitive information 𝑅 PCR

1

by its own private key. Then,the public key of𝑁 is expected to encrypt the HMAC value,and finally 𝑅 sends the encrypted message to𝑁:

𝑅 → 𝑁 : {{HMAC (𝑅 PCR1

,Nonce𝑅

) ‖ Nonce𝑅

‖ Plat ID𝑅

} 𝑅−1

}𝑁PUB. (1)

Step 2 (𝑁 receives the authorized information from 𝑅).First, 𝑁 receives the encrypted message including 𝑅’s IDand 𝑁PUB from Step 1. Then, 𝑁 will implement a negotiatedregistration by using 𝑅’s platform identity information. Andthen, aiming at the hardware sensitive information in the 𝑅’splatform, 𝑁 implements a credible verification which usesPCR values of 𝑁’s hardware sensitive information to make

HMAC with Nonce𝑅

. If the HMAC result is consistent with𝑁 received information in Step 1, 𝑅’s hardware is trusted.Finally, if the verification is completed,𝑁 will create a digitalsignature for signing controller platform identity informationPlat ID

𝑁

, random numbers Nonce𝑁

, and hardware sensitiveinformation𝑁 PCR

1

and correspondingly use the public keyof𝑅 to encrypt themand send the result to𝑅. On the contrary,the negotiation fails:

𝑁 → 𝑅 : {{HMAC (𝑁 PCR1

,Nonce𝑁

) ‖ Nonce𝑁

‖ Plat ID𝑁

}𝑁−1

} 𝑅PUB. (2)

Step 3 (𝑅 receives the authorized information from 𝑁).First, 𝑅 receives the verification feedback from 𝑁, which isencrypted by the public key of 𝑅, indicating that there isa trusted negotiation between 𝑅 and 𝑁. Second, Plat ID

𝑁

could similarly implement its negotiated registration. Third,as shown in Step 2, 𝑅 begins the credible verification with thehardware sensitive information of𝑁; if the results are consis-tent,𝑁 can be trusted in hardware. Finally, if the verificationpasses, 𝑅 will generate trust negotiation session randomnumbers; meanwhile 𝑁 creates the negotiated private keyand implements the next round trust negotiation. 𝑅 willsign sensitive information of controller platform operatingsystem HMAC value and encrypt the sensitive informationby session key. The negotiation fails when the verification isnot successfully passed:


,Nonce𝑅

) ‖ AK𝑅

} 𝑅−1

}𝑁PUB. (3)

Step 4 (𝑁 receives the HMAC sensitive information ofthe controller platform operating system 𝑅 PCR

2

and keyrandom numbers of 𝑅, AKR). First, 𝑁 receives 𝑅 PCR2and implements a credible verification, as shown in Step 2,with the operating system measurement result 𝑁 PCR

2

ofits own controller. Second, if the verification passes, 𝑁 willproduce a negotiated private key random number AK

𝑁

.Then, using AK

𝑅

, AK𝑁

, the pseudo random numbers, andfunctionPRGF,𝑁will create a controller software verificationsession private key AK, which is bound with the platforminformation of 𝑅. Finally, 𝑁’s platform sends the sensitiveinformation HMAC value of 𝑁 to 𝑅. The negotiation fails ifthe credible verification is not successfully passed:


,Nonce𝑁

) ‖ ACK ‖ AK}𝑁−1} 𝑅PUB. (4)

2.2.2. Controller Software Certification Process. In this sub-section, we continue to explain the steps in certificationprocess. These steps are related to the controller softwarecertification process.

Step 5 (𝑅 receives the sensitive information HMAC valuefrom the receiving controller platform operating system).First, 𝑅 receives the operating system sensitive informationfrom the receiving controller platform and implements a


Controllerplatform

Controllerplatform

RequesterR

Controllersoftware

Controllersoftware

ReceiverN

(1) {{(2) {{

(4) {{

(5)

(3) {{

Hash(R_PCR1 R R R}R−1}NPUB

Hash(N_PCR1 N }RPUB

Hash(R_PCR2 R R}R−1}NPUB) ‖ AK

Hash(N_PCR2 N) ‖ ACK ‖ AK}N−1}RPUB

Controller software authentication{{

(6) {{

(8) {{

(7)

Hash(R_PCR3 R) ‖ CS_ IDR}AK}R−1

Hash(N_PCR3 N N}AK}N−1

{{Hash(R_PCR4 R)}AK}R−1

Hash(N_PCR4 N) ‖ ACK}AK}N−1

Controller platform authentication, Nonce ) ‖ Nonce ‖ Plat_ID

N N}R−1) ‖ Nonce ‖ Plat_ID, Nonce

, Nonce

, Nonce

, Nonce

, Nonce, Nonce

, Nonce

) ‖ CS_ ID

Figure 2: Trusted domain authentication process.

credible verification, as shown in Step 2, with the operatingsystem measurement result 𝑅 PCR

2

of its own controllerplatform. Then, if the credible verification passes, the trustnegotiation will enter into the controller software verificationprocess, and, therefore, session private key AK will bind theinformation of 𝑁 and also sign the encrypted informationthrough 𝑅’s private key. Finally, 𝑅 returns the signed infor-mation to𝑁. The negotiation fails if the credible verificationfails:


,Nonce𝑅

) ‖ CS ID𝑅

}AK} 𝑅−1. (5)

Step 6 (𝑁 receives the controller software verification requestfrom 𝑅). First,𝑁 decrypts the information by 𝑅’s public key,proving the existing base of the trust negotiation between 𝑅and 𝑁. Then, using the decryption of the sensitive informa-tion HMAC value of the controller software, 𝑁 implementsa credible verification as shown in Step 2. If the credibleverification passes, 𝑁 will proceed a negotiated registrationusing the controller software information CS ID

𝑅

of 𝑅,encrypt the sensitive information HMAC value of controllersoftware and the controller software ID through sessionprivate key AK, and sign the encrypted information through𝑅’s private key. Finally, 𝑁 returns the signed informationto 𝑅. The negotiation fails if the credible verification is notsuccessfully passed:


,Nonce𝑁

) ‖ CS ID𝑁

}AK}𝑁−1. (6)

Step 7 (𝑅 receives the verification information from𝑁). First,as shown in Step 6, using the sensitive information HMACvalue of the controller software, the receiving controllerimplements a credible verification as shown in Step 2.Then, ifthe credible verification passes,𝑅will implement a negotiatedregistration using the controller software information of𝑁.𝑅encrypts the sensitive information HMAC value of 𝑅 PCR

4

and Nonce𝑅

through session private key AK and signs theencrypted information by 𝑅’s private key. Finally, 𝑁 returnsthe signed information to 𝑅. The negotiation fails if thecredible verification is not successfully passed:


,Nonce𝑅

)}AK} 𝑅−1. (7)

Step 8. First, receiving controller software application mod-ules HMAC value of 𝑅,𝑁 implements a credible verificationas shown in Step 2. Then, if the credible verification passes,𝑁 will encrypt the sensitive information HMAC value of𝑁 PCR

4

and Nonce𝑁

by session private key AK and signthe encrypted information by 𝑅’s private key. Finally, 𝑅implements a credible verification on application modulesensitive information of𝑁, shown in Step 2. If the verificationpasses, the verification of the controller software will be com-pleted and the controller verificationwill pass. Otherwise, thenegotiation fails:


,Nonce𝑁

) ‖ ACK}AK}𝑁−1. (8)

3. BAN Logic Security Analysis

According to the BAN logic security analysis, this sectionanalyzes whether our authentication protocol is secure or not.

3.1. BAN Logic Security Analysis. BAN predicate logic iscomposed of 10 basic syntax and semantic clauses:

(1) 𝑄 |≡ 𝐴 𝑄 believes that 𝐴 is credible.(2) 𝑄 ⊲ 𝐴 𝑄 receives message 𝐴.(3) 𝑄 |∼ 𝐴 𝑄 has sent message 𝐴.(4) 𝑄 |⇒ 𝐴 𝑄 has jurisdiction for message 𝐴.(5) #(𝐴): message 𝐴 is fresh, which means that 𝐴 is

temporary value and not the first to be sent as theinformation.

(6) 𝑃Key←→ 𝑄: the key is shared key between 𝑃 and 𝑄.

(7)Key→ 𝑄 or |

Key→ 𝑄: key is 𝑄’s public key.

(8) 𝑃𝑋

𝑄 𝑋 events are shared secrets between 𝑃 and𝑄.(9) {𝑋}Key: message𝑋 is encrypted by key.(10) ⟨𝑋⟩

𝑌

is the cascade of information of𝑋 and 𝑌.


3.2. BAN Logic Inference Rules. This section describes thefour main specific rules of BAN logic to provide a theoreticalbasis for SDN trusted domains security authentication proto-col. ⊢ is primitive symbol, such as 𝑃 ⊢ 𝑄 representing that 𝑃derives conclusions 𝑄.

(1) Message Meaning Rule

Theorem 1. Consider

𝑃 |≡𝐾

→ 𝑄,

𝑃


3.4. BAN Logic Security Goals. For security requirements ofSDN trusted domains security authentication protocol, thispaper sets up multiple security goals:

(1) 𝑁 |≡ 𝑅 |≡ 𝑅 PCR: 𝑁 believes that 𝑅 is credible tobelieve 𝑅 PCR.

(2) 𝑅 |≡ 𝑁 |≡ 𝑁 PCR: 𝑅 believes that 𝑁 is credible tobelieve𝑁 PCR.

(3) 𝑁 |≡ 𝑅 |≡ Nonce𝑅

: 𝑁 believes that 𝑅 is credible tobelieve Nonce

𝑅

.

(4) 𝑅 |≡ 𝑁 |≡ Nonce𝑁

: 𝑅 believes that 𝑁 is credible tobelieve Nonce

𝑁

.

(5) 𝑁 |≡ 𝑅 |≡ Plat ID𝑅

: 𝑁 believes that 𝑅 is credible tobelieve Plat ID

𝑅

.

(6) 𝑅 |≡ 𝑁 |≡ Plat ID𝑁

: 𝑅 believes that 𝑁 is credible tobelieve Plat ID

𝑁

.

(7) 𝑁 |≡ AK𝑅

: 𝑁 believes that AK𝑅

is credible.

(8) 𝑅 |≡ AK: 𝑅 believes that AK is credible.

(9) 𝑁 |≡ 𝑅 |≡ CS ID𝑅

: 𝑁 believes that 𝑅 is credible tobelieve CS ID

𝑅

.

(10) 𝑅 |≡ 𝑁 |≡ CS ID𝑁

, 𝑅 |≡ 𝑁 |≡ ACK: 𝑅 believes that𝑁 is credible to believe CS ID

𝑁

.

(11) 𝑅 believes that𝑁 is credible to believe ACK.

3.5. BAN Logic Initialization Assumptions. In order to verifythe authentication protocol compliance with BAN logic, wemake the initialization assumptions of BAN logic:

𝑅 |≡𝑁PUB→ 𝑁,

𝑁 |≡𝑅PUB→ 𝑅,

𝑁 |≡ 𝑅 |⇒ AK𝑅

,

𝑁 |≡ # (𝑅 PCR) ,

𝑁 |≡ # (Nonce𝑅

) ,

𝑁 |≡ # (AK𝑅

) ,

𝑅 |≡ # (𝑁 PCR) ,

𝑅 |≡ # (Nonce𝑁

) .

(17)

3.6. BAN Logic Secure Analysis. This section will use theBAN predicate logic inference to verify the authenticationprotocol’s security goals, which is based on the BAN logicinitialization assumptions of Section 3.5.

(1) Inference 1: From Step 1


,Nonce𝑅

) ‖ Nonce𝑅

‖ Plat ID𝑅

} 𝑅−1

}𝑁PUB. (18)

⟨1⟩ ∵ 𝑁 |≡𝑅PUB→ 𝑅,

𝑁


⟨1⟩ Same as inference 1, we can get the conclusions

𝑅 |≡ 𝑁 |≡ 𝑁 PCR,

𝑅 |≡ 𝑁 |≡ Nonce𝑁

,

𝑅 |≡ 𝑁 |≡ Plat ID𝑁

.

(24)

(3) Inference 3: From Step 3


,Nonce𝑅

) ‖ AK𝑅

} 𝑅−1

}𝑁PUB. (25)

⟨1⟩ ∵ 𝑁 |≡𝑅PUB→ 𝑅,

𝑁


(2) Random number, Nonce𝑅

/Nonce𝑁

, is confidentialduring transmission.

(3) AK𝑅

is confidential during transmission.(4) Controller platform ID/controller software ID is con-

fidential during transmission.(5) Controller software authentication session key is con-

fidential.(6) Successful certification logo (ACK) is completed.

4.1.1. Security Goals Formalization. In response to these secu-rity goals, this paper will test the safety of the authenticationprotocol using AVISPA network analysis tool. For testingprotocol security, the AVISPA network interaction protocolsecurity analysis system makes a formalized definition abouttest method of protocol security goals. Description is shownbelow.

(1) Information Confidential Test

Secret (E, id, S).This is a statement whichmeans that subject Sshares information E, and this secret is named an unchangedid which will be used in the goals definition.

(2) Information Verification Test

Witness (A, B, id, E). This is a weak authentication attribute,whichmeans that A declares that A has sent a message E to B,and this statement is named an unchanged id which will beused in the goals definition.

Request (B, A, id, E). This is a strong authentication attribute,which means that B declares that B has received a message Efrom A, and this statement is named an unchanged id whichwill be used in the goals definition.

WRequest (B, A, id, E).This is aweak authentication attribute,which is similar to Request (B, A, id, E), but it does not verifyreplay attacks.

4.1.2. Modeling and Simulating Security Goals. In this sectionwe will use HLPSL to build security goals modeling, which isbased on formal definition of security objectives.

(1) For testing the security goals in Section 4.1.1, theauthentication requesting platform needs to verifyPCR, random numbers, and platform id of theauthentication received platform. The HLPSL codeappears as shown in Box 1.

(2) Obviously, the authentication receiving platform alsoneeds to verify PCR, random numbers, and platformid of the authentication requesting platform. TheHLPSL code appears as shown in Box 2.

4.2. Security Test

4.2.1. Test Scenarios. For the security goals, this paper setsup three test scenarios to verify whether the protocol satisfiesthe security goals or not. As shown in Table 1, in Scenario 1,

Role sdnTNap Init(A,B : agent,Kab :symmetric key,H :hash func,Ap Start, Ap Init, Ap aSuccess : text,

SND,RCV: channel(dy))played by Ainit State :=0transition∧request(A,B,b a K1ab,K1ab')∧request(A,B,b a SIGKpubKb,SIGKpubKb')∧secret(K1ab',k1ab,{A,B})∧request(A,B,b a bNonce,BNonce')∧request(A,B,bpcr1,H(BPcr1'.BNonce'))∧request(A,B,bpcr2,H(BPcr2'.BNonce'))∧request(A,B,bpcr3,H(BPcr3'.BNonce'))∧request(A,B,bpcr4,H(BPcr4'.BNonce'))end role

Box 1

role sdnTNap reply(A,B : agent,Kab : symmetric key,H : hash func,

Ap Start,Ap Init,Ap aSuccess,Ap bSuccess :text,

SND,RCV:channel(dy))played by Binit State :=1transition∧request(B,A,a b SIGKpubKa,SIGKpubKa')∧request(B,A,a b aNonce,ANonce')∧request(B,A,apcr1,H(APcr1'.ANonce'))∧request(B,A,apcr2,H(APcr2'.ANonce'))∧request(B,A,apcr3,H(APcr3'.ANonce'))∧request(B,A,apcr4,H(APcr4'.ANonce'))15.State = 15∧RCV(Ap aSuccess') = |>State':=17∧SND(Ap bSuccess)end role

Box 2

we implemented a single session with all the roles played bylegitimate agents. In Scenario 2 and Scenario 3 we tested thesituations, in which the intruder would impersonate each ofthe legitimate agents: the authentication requesting controllerplatform (Scenario 2) and the authentication receiving con-troller platform (Scenario 3).

4.2.2. Test Results. As shown in Boxes 3 and 4, the authentica-tion protocol passed OFMC security test and ATSE securitytest, and the authentication protocol is not attacked by DYmodel, so we can conclude that the authentication protocol issecure.

From the summary details of Boxes 3 and 4, we cansee that our authentication protocol is tested by CL-AtSe


Table 1: Scenario description of security test.

Scenario Scenario description(1) session(a,b,kab,h, ap start,ap init,ap Asuccess,ap Bsuccess)(2) session(a,i,kai,h, ap start,ap init,ap Asuccess,ap Bsuccess)(3) session(i,b,kib,h, ap start,ap init,ap Asuccess,ap Bsuccess)

% OFMC% Version of 2006/02/13SUMMARYSAFE

DETAILSBOUNDED NUMBER OF SESSIONS

PROTOCOLD:\...\NPLAB\temp\130476350162500000.if

GOALas specified

BACKENDOFMC

COMMENTSSTATISTICSparseTime: 0.00ssearchTime: 0.04svisitedNodes: 1 nodesdepth: 0 plies

Box 3: Security test result of OFMC system.

model and OFMC system, based on constraint logic, and ourprotocol was analyzed by 4 states. So, the conclusion of ourtest is quite convincing.

5. Performance Analysis

5.1. Calculation Consumption. This section uses the authen-tication response time defined in [25] to evaluate thecalculation overhead of the protocol. The authenticationresponse time (𝑇) is mainly composed of three parts: theauthentication requesting platform computing time (𝑇

𝑅

), theauthentication receiving platform computing time (𝑇

𝑁

), andthe protocol transmission time (𝑇

𝑇

). The following relation-ship can be obtained through the above three variables:

𝑇 = 𝑇𝑅

+ 𝑇𝑁

+ 𝑇𝑇

. (35)

Thus, we define the authentication requesting platformcomputing time including operation overhead of HMAC,digital sign, and encryption and decryption.

Similarly, we define the authentication receiving platformcomputing time including operation overhead of HMAC,digital sign, and encryption and decryption.

In particular, we consider that the ideal transport networkexcludes the impact of network latency.

TYPED MODELPROTOCOLD:\...\NPLAB\temp\130476352862187500.if

GOALAs Specified

BACKENDCL-AtSe

STATISTICSAnalysed : 4 statesReachable : 0 statesTranslation: 0.14 secondsComputation: 0.00 seconds

Box 4: Security test result of ATSE system.

According to the above definition, the calculation over-head of authentication protocol is mainly composed ofHMAC, digital sign,message encryption and decryption, andthe network transmission. As shown in Table 2, we make adetailed comparison between IKEv2, IDAKE-MA [26], andSKAP in this paper.

It can be seen in Table 2 that the authentication protocolof this paper has higher calculation consumption comparedwith other domain protocols. In particular, we propose ano third party certification method. So our approach hasadvantages in communication frequency, which effectivelyreduces the total number of communications and networkoverhead. Furthermore, the authentication protocol is basedon trusted computing, which effectively protects the cred-ibility of network domains, and the trusted authenticationprotocol could make more advantages in security. Last butnot the least, the authentication protocol does not haveindex calculation. Compared with other protocols in Table 2,our approach could significantly improve computationalefficiency and reduce the cost of computing.

5.2. Storage Consumption. For the authentication protocolof this paper, we assume that the average frequency of therequester connecting to the receiver under random condi-tions is 1/𝑇access, and the process of receiving request can bemodeled as a Poisson process, where the average frequency is1/𝑇access. Using the receiver as an example, when the receiverreceives a request message, the receiver needs to store thepublic key of the requester (𝑅public), the random number ofthe requester (Nonce

𝑅

), and the session key (AK) until thesession is completed or the timer is over. We assumed the


Table 2: Comparison in the performance of protocols.

Protocol Communication Communicationbetween domains Encryption/decryptionDigitalsign Hash/index calculation

IKEv2 12 5 0 14 0/0IDAKE-MA 14 6 6 5 0/2SKAP 10 4 4 3 0/2Our method 8 8 8 8 8/0

00.2

0.40.6

0.81

0

0.5

10

20

40

60

80

100

120

The s

tora

ge co

nsum

ptio

n

TaccessTlifetim

e

Figure 3: The storage consumption of our method.

time of wait timer is 𝑇lifetime, the response time of receivingthe message is 𝑇req, and the packet loss rate of experimentnetwork is 𝑃loss, and we derived that the storage averageamount of the receiver is

2 × [1

𝑇access× 𝑇lifetime × 𝑃loss +

1

𝑇access× 𝑇req

× (1 − 𝑃loss)] .

(36)

Assuming the time of the latency timer is two times thatof the response message time, we can further simplify thatthe storage average amount of the receiver is 𝑇lifetime/𝑇access ×(𝑃loss + 1).

According to the above formula, on the one hand, if𝑇lifetime and 𝑇access remain unchanged, the storage consump-tion is proportional to the network packet loss rate. Ifthe network is stable and packet loss rate is not high, theauthentication protocol of proposed in this paper does notrequire a low storage space to store data, and the storageconsumption is in the ideal range.

On the other hand, as shown in Figure 3, if 𝑃loss remainsunchanged, the storage consumption is proportional to𝑇lifetime and 𝑇access. It means that if controllers’ processingtime is too long, the controller will continue to receiverequest, and thus the storage consumption will increasesharply.

So far we assumed that the 𝑃loss rate remains unchanged.We further perform a comparative analysis with IKEv2,IDAKE-MA, and SKAP. The results are shown in Figures 4,

00.2

0.40.6

0.81

0

0.5

10

50

100

150

The s

tora

ge co

nsum

ptio

n

TaccessTlifetim

e

Figure 4: The storage consumption of SKAP.

00.2

0.40.6

0.81

0

0.5

1

TaccessTlifetim

e

0

50

100

150

200

The s

tora

ge co

nsum

ptio

n

Figure 5: The storage consumption of IDAKE-MA.

5, and 6; our method has more advantages in terms of storageconsumption.

6. Conclusion

In this paper, we introduced and demonstrated a securityauthentication protocol of SDN trusted domain in ADSapplications and designed the trusted domain network archi-tecture to solve the credential problem of SDN architecture.The trust negotiation concept with nontrusted third partyis a prerequisite for communication between different SDNtrusted domains in ADS applications.


0.20.4

0.60.8

10.5

1

TaccessTlifetim

e

0

0

50

100

150

200

The s

tora

ge co

nsum

ptio

n

Figure 6: The storage consumption of IKEv2.

The main contributions are as follows: (1) Our protocoldoes not contain any unnecessary information. We analyzedthe redundant information by BAN logical system.The resultsshow that the protocol is a concise protocol. (2)The protocolis secure in theory. The BAN logic security analysis hasproved that our protocol is secure. (3)The protocol is securein experiment. We demonstrate the security of our trusteddomain authentication protocol by BAN logic and AVISPAsecurity analysis tool, and we compared our trusted domainauthentication protocolwith other prevalent protocols in per-formance analysis. Our work fills the gap of mutual trustbetweendifferent trusted domains andprovides security foun-dation for interaction between different trusted domains.

In the paper we considered replay attacks and intermedi-ator attacks. In the future, we plan to consider other attackerbehavior models including opportunistic collusion attacks,random attacks, and insidious attacks to further demonstratesuperiority of our protocol.

Competing Interests

The authors declare that they have no competing interests.

Acknowledgments

This research was supported by Funding Project for BeijingKey Laboratory of Trusted Computing, National EngineeringLaboratory for Critical Technologies of Information SecurityClassified Protection, Open Research Fund of Beijing KeyLaboratory of Trusted Computing, and 2015 Intelligent Man-ufacturing Special Project: The Comprehensive StandardizedTest.The paper is also supported by a Beijing Natural ScienceFoundation project (no. 4162006).

References

[1] K. Mori, “Assured service-oriented system engineering tech-nologies and applications,” in Proceedings of the Fifth Interna-tional Symposiumon ServiceOriented SystemEngineering (SOSE’10), 4 pages, Nanjing, China, June 2010.

[2] H. Takahashi, K.Mori, andH. F.Ahmad, “Efficient I/O intensivemulti tenant SaaS system using L4 level cache,” in Proceedings

of the 5th IEEE International Symposium on Service OrientedSystem Engineering (SOSE ’10), pp. 222–228, IEEE, Nanjing,China, June 2010.

[3] H. Takahashi, K. Mori, and H. F. Ahmad, “Autonomous shortlatency system for web application layer firewall,” in Proceedingsof the 6th World Congress on Services (SERVICES ’10), pp. 447–452, Miami, Fla, USA, July 2010.

[4] Q. Zuo, M. Xie, and W.-T. Tsai, “Autonomous decentralizedtenant access control model for sub-tenancy architecture insoftware-as-a-service (SaaS),” in Proceedings of the 12th IEEEInternational Symposium on Autonomous Decentralized Systems(ISADS ’15), pp. 211–216, IEEE, Taichung, Taiwan, March 2015.

[5] Y. Chen and Y. Kakuda, “Autonomous decentralised systems inweb computing environment,” International Journal of CriticalComputer-Based Systems, vol. 2, no. 1, pp. 1–5, 2011.

[6] Y. Chen and W. T. Tsai, Service-Oriented Computing and WebSoftware Integration, Kendall Hunt, 5th edition, 2015.

[7] M. Casado, T. Garfinkel, A. Akella et al., “SANE: a protectionarchitecture for enterprise networks,” in Proceedings of the 15thUSENIX Security Symposium, Vancouver, Canada, July-August2006.

[8] M. Casado, M. J. Freedman, J. Pettit et al., “Ethane: taking con-trol of the enterprise,”ACMSIGCOMMComputer Communica-tion Review, vol. 37, no. 4, pp. 1–12, 2007.

[9] D. Li, X. Hong, and J. Bowman, “Evaluation of security vulner-abilities by using ProtoGENI as a launchpad,” in Proceedings ofthe IEEE Global Telecommunications Conference (GLOBECOM’11), pp. 1–6, IEEE, Houston, Tex, USA, December 2011.

[10] K. Benton, L. J. Camp, and C. Small, “OpenFlow vulnerabilityassessment,” in Proceedings of the 2nd ACM SIGCOMM Work-shop on Hot Topics in Software Defined Networking (HotSDN’13), pp. 151–152, ACM, Hong Kong, China, August 2013.

[11] A. Shalimov, D. Zuikov, D. Zimarina, V. Pashkov, and R.Smeliansky, “Advanced study of SDN/OpenFlow controllers,”in Proceedings of the 9th Central & Eastern European SoftwareEngineering Conference in Russia (CEE-SECR ’13), vol. 1, ACM,Moscow, Russia, October 2013.

[12] N. Gude, T. Koponen, J. Pettit et al., “NOX: towards an operat-ing system for networks,” ACM SIGCOMM Computer Commu-nication Review, vol. 38, no. 3, pp. 105–110, 2008.

[13] L. Rodrigues Prete, C. M. Schweitzer, A. A. Shinoda, and R. L.Santos de Oliveira, “Simulation in an SDN network scenariousing the POX controller,” in Proceedings of the IEEE ColombianConference on Communications and Computing (COLCOM ’14),pp. 1–6, IEEE, Bogotá, Colombia, June 2014.

[14] Ryu documentation, http://osrg.github.com/ryu/.[15] D. Erickson, “The beacon openflow controller,” in Proceedings

of the 2nd ACM SIGCOMMWorkshop on Hot Topics in SoftwareDefined Networking (HotSDN ’13), pp. 13–18, ACM,Hong Kong,August 2013.

[16] D. Kreutz, F. Ramos, and P. Verissimo, “Towards secure anddependable software-defined networks,” in Proceedings of the2nd ACM SIGCOMM Workshop on Hot Topics in SoftwareDefined Networking (HotSDN ’13), pp. 55–60, Hong Kong,China, August 2013.

[17] C. Kaufman, “Internet key exchange (IKEv2) protocol,” RFC4306, 2005, http://tools.ietf.org/html/rfc4306.

[18] L. Chen and M. Ryan, “Attack, solution and verification forshared authorisation data in TCG TPM,” in Formal Aspectsin Security and Trust, vol. 5983 of Lecture Notes in ComputerScience, pp. 201–216, Springer, Berlin, Germany, 2010.


[19] K. Fan, H. Li, and Y. Wang, “Security analysis of the kerberosprotocol using BAN logic,” in Proceedings of the 5th Interna-tional Conference on Information Assurance and Security (IAS’09), pp. 467–470, Xi’an, China, September 2009.

[20] F. Dadeau, P.-C. Héam, and R. Kheddam, “Mutation-based testgeneration from security protocols in HLPSL,” in Proceedingsof the 4th IEEE International Conference on Software Testing,Verification, and Validation (ICST ’11), pp. 240–248, IEEE,Berlin, Germany, March 2011.

[21] Y. Yang, H. Zhang, M. Pan, J. Yang, F. He, and Z. Li, “A model-based fuzz framework to the security testing of TCG softwarestack implementations,” in Proceedings of the 1st InternationalConference onMultimedia Information Networking and Security(MINES ’09), pp. 149–152, IEEE, Hubei, China, November 2009.

[22] TCG TPM, Main Part 1: Design Principles, Specification Ver-sion, 1, 2003.

[23] P. N. Mahalle, B. Anggorojati, N. R. Prasad, and R. Prasad,“Identity establishment and capability based access control(IECAC) scheme for internet of things,” in Proceedings of the15th International Symposium on Wireless Personal MultimediaCommunications (WPMC ’12), pp. 187–191, IEEE, Taipei, Tai-wan, September 2012.

[24] N. Toledo,M.Higuero, J. Astorga,M.Aguado, and J.M. Bonnin,“Design and formal security evaluation of NeMHIP: a newsecure and efficient network mobility management protocolbased on theHost Identity Protocol,”Computers & Security, vol.32, pp. 1–18, 2013.

[25] J. Liu, J. Liao, X. Zhu et al., “Password authentication scheme formobile computing environment,” Journal on Communications,vol. 5, article 005, 2007.

[26] P. Huaxi, “An identity-based authentication model for multi-domain,” Journal of Computers, vol. 29, no. 8, pp. 1271–1281,2006.

Research ArticleOpenFlow-Based Mobility ManagementScheme and Data Structure for the Mobility Service atSoftware Defined Networking

Pill-Won Park, Seong-Mun Kim, and Sung-Gi Min

Department of Computer and Radio Communication Engineering, Korea University, Seoul 136-713, Republic of Korea

Correspondence should be addressed to Sung-Gi Min; [email protected]

Received 18 November 2015; Revised 5 February 2016; Accepted 10 February 2016

Academic Editor: Luis Javier Garcia Villalba

Copyright © 2016 Pill-Won Park et al. This is an open access article distributed under the Creative Commons Attribution License,which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.

The network-based mobility management is adapted to the OpenFlow architecture for mobility service at Software DefinedNetworking (SDN), and data structure for mobility service is proposed. SDN is a newly proposed Internet architecture whichdecouples the data and control planes, and mobility management is one of the most important issues in SDN. In order to providemobilitymanagement service by utilizing themobility scheme proposed earlier in a newnetwork environment, the existingmobilityschemes need to be modified. Particularly, the characters of the network environment need to be considered when designing thefunction of the network entities and data structure. Our proposed mobility management scheme is focused on the centralizedcontrol mechanism of SDN.We referred to ProxyMobile IPv6 (PMIPv6) andOpenFlow-based PMIPv6 with a centralizedmobilitymanagement controller (OPMIPv6-C). It has a merged data structure for the mobility service on SDN controller and minimizesthe number of switches which need flow table modification at handover. At the performance analysis chapter, we compare thesignaling cost at the registration and handover phase, packet delivery cost, and handover latency between the proposed schemeand OPMIPv6-C.

1. Introduction

Software Defined Networking (SDN) is newly proposednetwork architecture for the programable network [1]. SDNseparates the control plane and the data plane by the roleof the network functions. The data plane is responsible forthe packet forwarding and the control plane performs otherfunctions. The control functions which were located on thedistributed devices are gathered to the centralized controller.Due to the separation, standard interface is needed for theinteraction between the control plane and data plane. TheOpenFlow is one of the standard interfaces between thecontrol and data plane, and it is proposed by the OpenNetworking Foundation (ONF).

The OpenFlow architecture consists of the OpenFlow-enabled switch, secure channel, and OpenFlow protocol.The OpenFlow-enabled switch is the switch which satisfiesthe OpenFlow specification. The secure channel is the pathfor transmission of the OpenFlow messages between the

controller and switches.TheOpenFlow protocol is the formatof OpenFlow messages for the control, notification, andpacket transfer.

The mobility management scheme is able to be cate-gorized into two types: the network-based and host-basedmobility management or micro and macro mobility manage-ment protocol.The difference of the network-based and host-based mobility management is the subject of the mobility-related signaling. The network entities are the subject ofmobility-related signaling in the network-based mobilitymanagement.TheMN is subject of the mobility managementsignaling in the host-based management scheme. The differ-ence of the micro and macro mobility management is themobility management area for handover control. The macromobility management protocol handles the interdomainmobility and micro mobility management protocol controlsthe intradomain mobility, respectively. PMIPv6 is one ofthe network-based micro mobility management protocolsand it is standardized by IETF. The network entities, LMA


http://dx.doi.org/10.1155/2016/3674192


and MAG, are responsible for the mobility control signalinginstead of the MN, and PMIPv6 performs the intradomainmobility management service.

Several mobility management schemes for mobility ser-vice in SDNhave been suggested [2–5]. Reference [2] suggestsa brief idea for mobility service in SDN, but it does notdescribe any detailed mobility management procedures ordata structure. References [4, 5] apply PMIPv6 to SDN.Theyfocused on the adaptation of ProxyMobile IPv6 (PMIPv6) toOpenFlow architecture over SDN. They keep PMIPv6 archi-tecture and relocate the mobility control functions into SDNcontroller. Reference [4] proposes locating the distributed net-work entities, local mobility anchor (LMA), and the MobileAccess Gateway (MAG), into SDN controller. Reference [5]is similar to [4]. However they still use PMIPv6 signaling anddistributed data structure. Reference [3] suggests PMIPv6-based mobility management scheme on SDN. It gathers themobility management function into SDN controller and usesthe packet rewriting mechanism instead of the tunnelingmechanism. However, due to the packet rewriting mecha-nism, the access switch cannot handle more than one MN.

In this paper, we proposed the OpenFlow-Based Mobil-ity Management (OMM) scheme and an integrated datastructure for mobility service in SDN. The proposed schemeintegrates the mobility management functions into a singlemobility management entity (MME) and organizes the newdata structure which is based on the LMA and MAG datastructure. It eliminates all entries related to mobility manage-ment control messages and data tunnels and integrates theduplicated entries in MAG and LMA. OMM has the FlowMatrix which records the flow paths for mobile node (MN).And it adapts the path flow setup mechanism of [5, 6].

The rest of this paper is organized as follows. Section 2summarizes the related works. In Section 3, the architectureof the proposed scheme is introduced in terms of the datastructure and mobility management entity. In Section 4, thesignaling flow of the proposed scheme is introduced in termsof the registration phase and handover phase. A performanceevaluation is performed in Section 5. Finally, Section 6 con-cludes this paper.

2. Related Works

Mobility Support in Software Defined Networking [2] sug-gests the basic structure for the mobility management inSDN. But it proposes only the idea and does not suggest anyspecific method.

Mobility Management Framework in Software DefinedNetworks [4] and an adaptation of Proxy Mobile IPv6 toOpenFlow architecture over Software Defined Networking[5] suggest adaptation of PMIPv6 into SDN.

Reference [4] is focused on location of the mobilitymanagement entities for mobility service in SDN. It movesthe LMAandMAGs to SDNcontroller as the applications andall mobility management follows PMIPv6. It keeps LMA andMAG functions and uses tunneling to forward data packets.Reference [5] suggests two mobility management schemes:OpenFlow-based PMIPv6 (OPMIPv6) and OPMIPv6 with

a centralized mobility management controller (OPMIPv6-C). OPMIPv6 has LMA control function on SDN controllerand MAGs are located at the access switches. OPMIPV6-Csuggests centralized MAG at SDN controller as well as theLMA control function, but the two modules are not unified.Both schemes use the same mobility control mechanism inPMIPv6, but these two schemes eliminate packet tunneling.They use two flow entries on the OpenFlow-enabled switcheson the path between the access switch and the gateway switch.One entry handles the downstream traffic and the otherupstream traffic.There is no packet modification at the accessand gateway switches.

A solution for IP Mobility Support in Software DefinedNetworks [3] also proposes the centralized mobility manage-ment function at the SDNcontroller.The schemedoes not usetunneling to forward data packets fromaCN to theMNdirec-tion. The GW of the SDN domain rewrites the destinationaddress of packet to IP address of the AS, and the AS revertsits IP address to the original destination address when itreceives the forwarded packet.Due to the rewriting policy, theAS cannot handlemore than oneMN.TheAS cannot identifywhich destination address should be used to replace thedestination address of the incoming packet as the incomingpacket does not have any such indicator in the packet. Inaddition, the scheme uses the triangular packet forwardingbut the ingress filtering problem is not considered at all.

3. An OpenFlow-Based Mobility Management

The OpenFlow-Based Mobility Management (OMM) refersto PMIPv6 to identify the requirements of the mobility man-agement. In this paper, we assumed two things. First, theMNattachment is notified by layer-2 notification which containstheMN’s identifier. Second, the IPv6 address ofMN is createdby using the home network prefix (HNP).These are the sameassumptions in PMIPv6.

3.1. Architecture. The proposed scheme consists of anMME on the centralized SDN controller, OpenFlow-enabledswitches, and anAuthentication,Authorization, andAccount-ing (AAA) server. SDN controller is the basement of controlapplications and it supports them using internal functions,such as the topology manager, database, and link discovery[7].TheOpenFlow-enabled switches provide packet forward-ing within SDN domain. The AAA server authenticates MNsfor themobility service. If anMNhas the right of themobilityservice, the AAA provides the MN’s profile to the MME.Thesolid lines and dotted lines in Figure 1 indicate the controlflow and the data flow.

3.1.1. OpenFlow-Enabled Switch. An OpenFlow-enabledswitch is a switch which satisfies the OpenFlow specification[8]. According to their role in OMM, the switches are catego-rized into access switches (ASs), intermediate switches (ISs),and gateway switches (GWs). An AS provides the networkaccess service to MNs. A GW connects the access networkwith the Internet. ISs are located on a flow path between theAS and the GW. A Crossing Switch (CS) is one of the ISs, andit is located at the branch point of old and new flow paths of


SDN domain

Controller(MME) AAA

CS

GWOpenFlow-enabled

switchAS

MN

CN

Figure 1: System architecture.

Mobile node identifierLink-layer identifier of the MN

List of IPv6 MN-home network prefix


List of IPv6 MN-home network prefixes

Access technology typeTunnel interface identifier

Link-local address of the MAG

MN

MN

Path

Path

LMABCEMAG

BUL

Local mobility anchor addressInterface identifier

Tunnel interface identifierLink-local address of the MAG


List of IPv6 MN-home network prefixesAccess technology type

Gateway switchi (GWi)Interface identifier to the MN

Access switchj (ASj)

MNinfo

FlowMatrix

info

MME

BCE

List of flow paths(upstream flow path, downstream flow path)

Pairs of the previous AS and CSHNP list

ASj

GWi

GWiRange of the HNP

::{IPv6 address}/64 ::{IPv6 address}/64

(a) Binding cache entry

(b) GW-HNP mapping table (c) Flow path matrix

Figure 2: The mobility-related information tables in the mobility management entity.

an MN when a handover occurs. The CS is used to reducethe number of flow table updates on switches affected by thehandover.

3.1.2. Mobility Management Entity. An MME is a controlapplication for the mobility management and it runs overSDN controller. The MME detects the attachment of an MNand provides the mobility service for MN. After authentica-tion of MN, it allocates the HNP for the MN and establishesdownstream and upstream flow paths for the MN. It alsoperforms the handover procedure when the MN moves intoanother AS.

3.2. Data Structures in the MME. The MME maintains theattached MN’s information at the binding cache. To performthe HNP allocation and flow path establishment, the MMEhas two additional data structures: a GW-HNP mappingtable and a Flow Matrix. These additional data structures arecreated before the MME provides the mobility service.

3.2.1. Binding Cache. The Binding Cache is a list of BindingCache Entries (BCEs) for each MN. A BCE is created whena new MN is attached to SDN domain and is updatedwhen the network state or the attachment point of MN ischanged. Each BCE contains MN’s information and FlowMatrix information. The format and the acquisition process

of each field follow these in PMIPv6 specification. The MNinformation includes an MN’s identifier (MN-ID), a link-layer identifier (LL-ID), a list of MN’s home network prefixes(MN-HNPs), and an Access Technology Type (ATT), asshown in Figure 2(a). The Flow Matrix information includesthe gateway index (GW

𝑖), the AS index (AS

𝑗), and an

interface identifier of the AS towhich theMN is attached.TheGW𝑖and AS

𝑗signify two end points of the flow path for MN,

like the LMA and MAG in PMIPv6. They are used to accessthe specific cell at the Flow Matrix, as follows 𝐶(GW

𝑖,AS𝑗).

3.2.2. GW-HNPMapping Table. When a newMN attaches toSDN domain, the MME must allocate an HNP for the MN.If the MME may obtain the HNP from the MN’s profile, theMME must know which GW handles the HNP for the MN.If not, the MME randomly assigns a corresponding GW forthe MN and allocates one of HNPs handled by the GW. TheMMEcan knowwhichGWmanages the assignedHNPbasedon the GW-HNP mapping table, as depicted in Figure 2(b).

3.2.3. Flow Matrix. The Flow Matrix has the flow-relatedinformation for providing mobility service in SDN domain.It contains three pieces of information: a list of flow paths,the pairs of a previous AS (pAS) and CS, and a list ofHNPs, as shown in Figure 2(c). An element in the list of


flow paths is described as a pair of an upstream flow pathand a downstream flow path, which is a Switch-ID (portindex for upstream, port index for downstream). For example,GW1(2, 1) means that the upstream and downstream are

forwarded throughport 2 andport 1 ofGW1, respectively.The

pairs of pAS and CS P(pAS,CS) are composed of each pASand the CS related to it. The MN is able to come from everyother pAS to the new AS (nAS) in SDN domain, and the CSneeds to calculate per each pAS.Thus, the FlowMatrix keepsthe P(pAS,CS) per each pAS. Only the flow table of switchesbetween the nAS and the CS is updated, not every switch onthe whole flow path. A list of HNPs consists of the allocatedHNPs for MN.

After the GW is selected, the MME has to find the flowpaths between the AS to which the MN is attached andthe selected GW. Each MN needs two flow paths: one forupstream traffic and the other for downstream traffic. Thetwo flow paths use the same switches, but their in/out portsare reversed. As the wired network topology is pretty stable,these flow paths can be calculated proactively. SDN topologyinformation for the flow path calculation can be takenfrom the underlying SDN controller and can be detecteddynamically using the Link-Layer Discovery Protocol [9].Based on the network topology, the MME can calculate thebest flow path between each AS and GW. The precalculatedflow paths are recorded in the Flow Matrix. Each cell of theFlow Matrix is accessed by using GW

𝑖and AS

𝑗.

When anMN ismoving into a nAS, the information of thenew flow path can be found with the nAS index in the FlowMatrix. Then, the flow table entries of switches on the newflow paths must be updated. However, the switches includedin both the old and new flow paths except the CS should beexcluded for the flow table entry update. Therefore, each cellof the FlowMatrix includes CS information for all other flowpaths. Only flow table entries on switches between the CS andthe AS on the new flow paths need to be updated.

A cell in the Flow Matrix also includes a list of HNPs.These HNPs share the flow paths between the AS and theGW. When the flow paths in the cell are changed due to theunderlying network topology change, all flow table entries ofswitches affected by the topology change must be updated.TheMMEuses theHNP list to update these flow table entries.

Figure 3 shows an example of the Flow Matrix. C(GW1,

AS1) indicates the flow paths between GW

1and AS

1, pairs of

pAS and CS, and the HNP list for the flow path between GW1

and AS1. The downstream and upstream flow path based

on the example topology are listed, as follows: [GW1(1, 2),

IS1(1, 2), IS

3(1, 2),AS

1(1, null)]; null is replaced with the

interface identifier of the Flow Matrix information of thecorresponding BCE.

If theMNmoves from the AS1to AS2, theMMEwill look

up a corresponding cell in Flow Matrix for GW1and AS

2.

The MME can find C(GW1,AS2) and update the flow table

of switch on the new flow paths. Before updating, the MMEdecides which switches to update based on P(AS

2,GW1) of

C(GW1,AS2). In this case, the CS is GW

1. Thus, the MME

updates the flow tables of switches between GW1and AS

1.

The Flow Matrix provides several advantages. Firstly,it prevents the duplicate computation about flow paths.

GW1

AS1

AS2,GW1 AS3,GW1Null Null Null

AS2 AS3

AS1,GW1 AS3, IS2 AS1,GW1 AS2, IS2

GW1

IS1 IS2

IS3 IS4 IS5

AS1 AS2 AS3

1

1

1

1

1

1

1

1

1

2

2

22

2 2

3

3

GW1(1, 2), IS1(1, 2)IS3(1, 2), AS1(1, null)

GW1(1, 3), IS2(1, 2),IS4(1, 2), AS2(1, null)

GW1(1, 3), IS2(1, 3),IS5(1, 2), AS3(1, null)

Figure 3: An example of the Flow Matrix.

The MME already maintains the precalculated flow paths inthe Flow Matrix. Thus, when a new MN attaches to one ofASs, the MME does not calculate flow paths and just uses thecorresponding cell of the FlowMatrix. Secondly, the numberof the flow paths managed by the MME can be reduced. Aflow path is configured per MN in SDN. However, the flowpath can be shared in the proposed scheme if MNs belongto the same cell of Flow Matrix. Thirdly, the MME can easilyhandle the topology change. Flow table entries affected by theunderlying network topology change must be reestablished.The MME can detect the flow paths affected by the topologychange by recalculating the Flow Matrix. If any flow pathsare updated after recalculation, the MME must update thecorresponding flow table entries on switches on the affectedflow paths with the HNP list. For each HNP in the HNP list,two flow table entries on each switch on the affected flowpaths are modified by the MME.

4. Procedures of OpenFlow-BasedMobility Management

In this section, the registration procedure and intradomainhandover procedure are described in detail.

4.1. Before Mobility Service. The MME creates the FlowMatrix and the GW-HNP mapping table. If SDN controllersupports the flow path setup, the MME requests the flowpath to SDN controller for an MN between each GW andAS. If not, the MME requests the network topology to SDNcontroller and computes the flow paths between each GWand AS. The MME records it on the Flow Matrix.

4.2. Registration to MME. The registration procedure isshown in Figure 4 and is as follows.

4.2.1. Mobile Node Attachment. When an MN is attached toSDN domain, the AS is notified by the 𝐿2 notification andforwards it to theMME.The𝐿2 notification contains theMN-ID, LL-ID, and ATT.

4.2.2. Authentication. The MME sends the MN-ID to theAAA server for authority of the mobility service. If the MNhas the right of the mobility service, the AAA authorizes


MN AS GW

MNattachment

ISs betweenAS and GW

MME(controller)

Detect MNattachment

Flow tableupdate

Flow table update

Register andaddress allocation

RA Packet-out (RA)

(1)

(2)

(3)

(4)

(5)

MN-IDProfile AAA

FMOD

Figure 4: The mobile node registration signaling flow.

MN

MNattachment

Detect MNattachment

Compare theattached MN-IDwith MN-ID in

BCESelect flow pathbetween new ASand GW using

Flow matrix

MNdetached

Pre-AS New AS ISs between CSand new AS CS GWMME

(controller)

Flow modification

RA

Flow table update

(1)

(2)

(3)

(4) Packet-out (RA)

Figure 5: The signaling call flow for intradomain handover.

and replies the profile of the attached MN. The MN’s profileincludes the GW information which will be allocated to MNand the HNP assigned to the connected interface. If MN’sprofile does not include HNP, theMME allocates an HNP fortheMNbased on the LL-ID and theGW-HNPmapping table.

4.2.3. Select the Flow Path in the Flow Matrix. At this time,the MME recognizes the indexes of the GW (GW

𝑖) and AS

(AS𝑗) for the MN. The MME looks up 𝐶(GW

𝑖,AS𝑗) in the

Flow Matrix. The MME chooses the cell in the Flow Matrixand gets the flow path for MN. Finally, the MME adds theassigned HNP for the MN to the HNP list of the cells.

4.2.4. Send the FMOD and Update the Flow Table in Switches.After selecting the flow path, the MME can know the ISsbetween the AS and the GW for the MN. The MME sendsa FlowModification (FMOD) message to the switches on thepath as soon as possible. Then, the switches update their flowtable for the MN’s upstream and downstream flows.

4.2.5. Router Advertisement. TheMME sends a unicast Rout-ing Advertisement (RA) message to the MN via the AS usingPOUT.The RA conveys the HNP and the other configurationparameters. The AS forwards the RA to the MN via the port

to which the MN is attached. After receiving the RA, the MNconfigures an IP address.

4.3. Intradomain Handover. The handover procedure isshown in Figure 5 and is as follows.

4.3.1. Mobile Node Detachment and Attachment. When theMN attaches to a nAS, the 𝐿2 notification is sent from nASto the MME.

4.3.2. Select the New Flow Path in the FlowMatrix. TheMMElooks up thematchingBCEbased on the𝐿2 notification. If theBCE is found, a handover is performed. The MME looks upthe cell C(GW

𝑖,AS𝑛) in the FlowMatrix by using the indexes

of the GW (GW𝑖) and nAS (AS

𝑛) in the BCE and checks the

P(AS𝑗,CS) field to find the CS.Thus, the MME can know the

switch list between the CS and nAS. It adds the HNP for theMN to the HNP list of C(GW

𝑖,AS𝑛) and removes the HNP

from that of C(GW𝑖,AS𝑗).

4.3.3. Send the FMOD to Switches and Update the Flow Table.TheMME sends the FMOD to the switches on the flow pathbetween the nAS and CS in order to update the flow tableentries. If not, the downstream packets will be forwarded to


Controller

ISIS

ISCS

· · ·

· · ·

· · ·

· · ·

hG-AShAS-M

hCS-AS

h C-S

hC-S

hC-ShCN-G

ASnMovement MN

CN1GW

AS1

Figure 6: The network topology.

the previous AS. The switches between CS and nAS updatetheir flow table.

4.3.4. Router Advertisement. TheMME sends a unicast RA tothe MN via the nAS, like the registration phase.

5. Performance Evaluation

This section describes the topology and the messages whichare used by OPMIPv6-C and OMM protocol for evaluation.The topology consists of a single GW and several switches torepresent a SDN administrative domain. We developed theanalytical cost model to evaluate the performance of OMMand the OPMIPv6-C based on [10]. The following notationsare used to develop the cost models [5, 10–13].

5.1. Network Model. We exploited the similar network modeland the concept of [5] for evaluations. The topology shownin Figure 6 is used to represent provisioning entities inOMM and OPMIPv6-C. We assumed that the controlleris connected by the wired line directly to all switches inthe domain. That means that the hop count between thecontroller and the switches is one. The CN is placed on theoutside of a given administrative domain, and the movementof MN is limited within the domain.

The ℎ𝑎-𝑏 means the average hop count between 𝑎 and 𝑏:

(i) ℎC-S: hop count between the controller and theswitches.

(ii) ℎCN-G: hop count between the CN and the GW.(iii) ℎG-AS: hop count between the GW and the access

switch.(iv) ℎCS-AS: hop count between the CS and the AS.(v) ℎAS-M: hop count between the AS and the MN.

5.2. Mobility Model. Both OPMIPv6 and OMM are localmobility management protocols. Thus, we only considerintradomain mobility based on that presented in [5, 14]. Inorder to evaluate the mobility model, we assume that allaccess points (AP) in the given domain have a circular cover-age of the same size 𝑆. The coverage of the AP is calculated as𝑆 = 𝜋𝑅

2, where𝑅 is the radius of theAP coverage.𝜇𝑎is theAP

Table 1: OpenFlow protocol message.

Notification Message Size (byte)𝐿exPS Extended Port Status (exPS) 103𝐿exSC Extended Switch Configuration (exSC) 103𝐿FMOD Flow Modification (FMOD) 116𝐿TCPA TCP Acknowledgment (TCPA) 60𝐿POUTRA Packet-out with RA 83𝐿RS Router Solicitation (RS) 52

crossing rate of theMN, and it is expressed as 2V/√𝜋𝑆, whereV is the average velocity of the MN [15]. Thus, the signalingcost applied to the mobility model is expressed as 𝜇

𝑎𝐶(⋅)

𝑆.

5.3. Messages Size of the OPMIPv6-C and OMM. OpenFlowmessages are carried on Transmission Control Protocol(TCP). The sizes of the messages that are used in OMMand OPMIPv6-C are shown in Table 1. We will follow theassumed attachment method of MN that is suggested in[5]. For comparison, we assumed that the 𝐿2 notificationis substituted by the Extended Switch Configuration (exSC)message in extendedOpenFlowmessage format, which sendsthe MN attachment event through AS to SDN controller.However, OMM uses RA instead of the Extended Port Status(exPS) message. The message sizes (bytes) used in OMMand OPMIPv6-C and the OpenFlow protocol are shown inTable 1.

Their size includes an IPv6 header and a TCP header, andwe consider the TCP Acknowledgment (TCPA) generated byeach OpenFlow message.

5.4. Cost Modeling. We developed the cost model whichevaluates the performance of the OPMIP-C and OMM basedon those presented in [10]. The following notation was usedto develop the cost model [11–13, 15, 16]. 𝛼 and 𝛽 each meanthe weighting factor of the wired and wireless link in orderto emphasize the link characteristic. 𝜆

𝑠indicates the average

session arrival rate at the MN, and 𝑁(𝑝) is the number ofpackets of a session. AnMNmoves fromAS

1to AS𝑛while the

MN communicates with CN. The signaling cost is calculatedbased on this scenario.

5.4.1. OPMIPv6-C. The signaling cost of OPMIPv6-C𝐶(OPMIPv6-C)𝑆

consists of the binding update cost 𝐶(OPMIPv6-C)BUand the flow modification cost 𝐶(OPMIPv6-C)FMOD .𝐶(OPMIPv6-C)BU is expressed as follows:

𝐶(OPMIPv6-C)BU = ℎC-S (𝐿exSC + 𝐿exPS + 2𝐿TCPA) . (1)

And the flow modification cost per each switch isexpressed as follows:

𝐶FMOD = ℎC-S (𝐿FMOD

advances on software defined sensor, mobile, and fixed...

Documents