Modelling and Verification of CoAP over Routing ... - Science Direct

Available online at www.sciencedirect.com

ScienceDirect Procedia Computer Science 93 (2016) 299 – 308

6th International Conference On Advances In Computing & Communications, ICACC 2016, 6-8 September 2016, Cochin, India

Modelling and Verification of CoAP over Routing Layer using SPIN Model Checker Anchal J Vattakunnel, Suresh Kumar N∗, G Santhosh Kumar Department of Computer Science,Cochin University of Science and Technology, Cochin-682022, India

Abstract Many of the communication protocols developed for the resource constrained devices are rarely subjected to protocol verification. Design flaws like deadlocks, livelocks, non-progressive cycles etc. may come into view during the realization and can cause catastrophic effects in safety-critical applications. Formal specification of the protocol represented as a model helps to describe and analyse the conformability of the implementation to its specification and subsequently reveal design flaws, if any in the system. The formal model is subject to verification by inserting correctness and safety properties of the protocol and validating logical correctness using a model checking tool. All model checkers suffer from state explosion problem due to enormous states of the model being created. The key contribution of the present work is the introduction of a method to develop a compact verification model which is amenable to full state space search by abstracting the key elements of a protocol. Moreover, many protocol verification works presented in the existing literature consider only a single layer of a communication protocol. To correctly model the overall behaviour of a protocol, interactions between the layers have to be incorporated. The proposed method has been proven useful by considering verification of an application protocol, CoAP for constrained devices by abstracting out the aspects of the underlying routing protocol RPL. Reliable message exchanges among various entities are modeled and its safety and correctness properties were analysed and verified. The results obtained show that the model performs the full state space search by considering all possible routing paths and are free from design flaws. The method described has been implemented by building a validation model in PROMELA and the model is verified by using SPIN model checker. The methodology used in this paper can be used to verify any application layer protocol for constrained devices in IoT scenario that run on top of routing layer. c 2016  2016The TheAuthors. Authors.Published Published Elsevier © by by Elsevier B.V.B.V. This is an open access article under the CC BY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/4.0/). Peer-review under responsibility of the Organizing Committee of ICACC 2016. Peer-review under responsibility of the Organizing Committee of ICACC 2016

Keywords: COAP; SPIN; PROMELA; Model checking; Model Verification; IoT

1. Introduction Internet of Things (IoT) consists of millions of IP connected smart devices interacting and communicating with each other over the web. The exponential increase in the sensor assisted applications put new demands on continuous sharing of information at global scale. It is expected that by 2020 there will be 50 billion of connected things 1 and ∗

Corresponding author. E-mail address: [email protected], [email protected],[email protected]

1877-0509 © 2016 The Authors. Published by Elsevier B.V. This is an open access article under the CC BY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/4.0/). Peer-review under responsibility of the Organizing Committee of ICACC 2016 doi:10.1016/j.procs.2016.07.214

300

Anchal J. Vattakunnel et al. / Procedia Computer Science 93 (2016) 299 – 308

communication protocols play a major role. The development of communication protocols are usually start from the RFC documents where the specifications given in these are mapped into implementation directly using a suitable programming language. Such protocols deployed on devices may result in failure during later stages of execution due to the design flaws. These flaws can only be identified and addressed by performing formal verification during the development. Formal verification of protocols include building models from its specifications followed by inserting properties that are to be verified into the model in the form of temporal claims, assertions and monitors. This is then fed to a model checker that performs an exhaustive search of all possible sequence of execution paths that matches with the negation of the specification properties. For any execution path that matches with the negated property specification, model checker generates a violating trace showing execution path that leads to property violation. Every execution path generated by the model checker is maintained as a sequence of execution states in system memory. The number of states generated by the model checker grows exponentially with respect to the size of the model. This may lead to state explosion problem resulting memory overflow. Hence, the size of the model should be minimized without losing core properties of the protocol. The constrained devices used in IoT applications make use of Routing Protocol for Low Power and Lossy Networks (RPL) 2 proposed by IETF at the routing layer for multi hop communication. RPL protocol constructs a direct acyclic graph(DAG) based on some objective function. Formal verification of application layer protocol for constrained devices requires interaction with routing layer. Modeling RPL for verification of application layer protocol leads to increase in the size of the model which results in state explosion.

Fig. 1. Proposed Verification System

This paper proposes a method to abstract out routing characteristics for the verification of application layer protocols for constrained devices in IoT. The overall outline of the proposed concept is depicted in Figure 1. By using this proposed method, verification of an application layer protocol namely Constrained Application Protocol (CoAP) for constrained devices is attempted. Protocol is modeled using PROMELA 3 and is verified by SPIN 5 model checker. The paper is organized as follows. Section II describes related works. Proposed design methodology for formal verification of CoAP is presented in Section III. The design elements of CoAP are discussed in Section IV. The Modeling and formal verification of CoAP incorporating proposed routing strategy is presented in Section V. Conclusion and future works are discussed in section VI. 2. Related Works Various software tools, methods and proposals designed to improve quality of routing protocols using formal verification techniques are presented in 6 . The work also present various types of formal verification techniques, the

Anchal J. Vattakunnel et al. / Procedia Computer Science 93 (2016) 299 – 308

problem of state explosion and its solution, an algorithm for formal verification and its illustration by modeling the various protocols using PROMELA. Various techniques involved in the verification of correctness properties for communication protocols based on finite state machines are depicted in 7,8 . The work also suggest different types of design flaws that are identified and addressed by formal verification. A systematic framework used for choosing modeling languages for cyber physical systems is presented in 9 . The framework describes the selection of modeling tool based on stakeholders view, type of formalism used. It also suggests language tools like SPIN, UPPAAL 10 and NuSMV for the verification of models based on finite state machine and hybrid automaton. The key concepts involved in model checking, description of SPIN model checker, tools used for demonstrating concurrency, nondeterminism are described in 11 . Classification of model checkers consisting of explicit state model checkers, bounded model checkers, constraint satisfaction model checkers and symbolic model checkers are presented in 12 . It also describes various temporal languages like LTL,CTL etc for property specification. The various ways in which the design flaws of a protocol can be identified and addressed are explained using a simple protocol for distributed systems presented in 13 . An attempt to compare the performance of bitstate hashing method with other hashing techniques for efficient state space search is presented in 14 . A method to derive UIO sequence from PROMELA specification for the solution of conformance test problem was presented in 15 . A method to integrate timing elapsed between events was suggested in 16 . The effectiveness of the above method was analysed and compared by incorporating timing features in PAR and BRP protocols. An algorithm for building an abstract model for protocols related to mobile ad-hoc networks was described in 17 . The algorithm described was validated for LAR, DREAM and OLSR ad-hoc routing protocols. A technique used for the verification of Wireless Adaptive Routing Protocol(W.A.R.P) using SPIN was described in 18 . Modeling and verification of DVR protocol using SPIN was depicted in 19 . Verification of DHCP protocol starting from abstracting of design elements and its behavior was described and safety properties were analyzed using SPIN in 20 . The messaging frame work for EAP protocol was modeled and the basic safety properties of the protocol were analyzed in 21 . Collision avoidance protocol was modeled and verified using SPIN and UPPAAL model checkers in 22 and its safety properties were analyzed. FTSP (Flooding Time Synchronization Protocol) was modeled using PROMELA and verified using SPIN in 23 . The Safety properties pertaining to time synchronization of FTSP were verified and analyzed using LTL. The Evolution and standardization of various protocols with a view to support IoT were described in 24 . It also propose a standardized protocol stack for constrained devices using IEEE 802.15.4 25 PHY layer and MAC layer , 6LOWPAN 26 , RPL/ROLL 27 for network layer, UDP for transport layer and CoAP 28 for application layer. An overview about CoAP and its standardization by CoRE (Constrained RESTful Environment) is discussed in 29 . This work describes the interoperability between a constrained environment with the traditional internet environment using HTTP and CoAP protocol stacks. The performance of CoAP and HTTP in terms of energy consumption, response time and bytes transferred per transaction was analyzed in 30 . The literature review shows that only few works were focusing on verification of IoT protocols. Many works related with protocol verification was done by considering message exchanges within the same layer. Modeling the protocol behavior for cross layer communication is vital for IoT protocols. Hence a verification method for application layer protocol (CoAP) by abstracting its interaction with routing layer for constrained devices communicating through multiple hops is proposed. This paper focuses mainly on a method to abstract out routing layer for the verification of CoAP. 3. Proposed design Methodology Multi hop communications are inevitable for smart devices due to their limited range. It is required to incorporate the characteristics of multi hop routing for performing formal verification of application layer protocols. In this paper routing concepts are embedded into the application layer protocol by constructing all the possible routing paths that exist among nodes. A seperate verification covering all possible paths has been performed for destination nodes containing multiple paths. The proposed derivation of routing information and verification of CoAP protocol are based on the extracting the design elements of protocols as suggested in 4 . Consider the topology described in Figure 2 . For the verification of CoAP node 0 is considered as source node. The possible paths between source (nodes 0) and the node with the highest level (node 8) are as shown below. Path 1 ->0-1-5-8 (3 hops), Path 2 ->0-1-5-7-8 (4 hops),

301

302

Anchal J. Vattakunnel et al. / Procedia Computer Science 93 (2016) 299 – 308

Fig. 2. Multihop Topology

path 3 ->0-3-5-8 (3 hops), path 4 ->0-3-5-7-8 (4 hops) and Path 5 ->0-4-6-7-8 (4 hops). Separate routing information are constructed for each path. Here five routing matrices are required to store the routing information along the five different paths. The routing information is maintained as a MxM matrix for topology consisting of M nodes. The algorithm for updating routing matrices are depicted in Algorithm 1. Applying algorithm on the multi hop topology Algorithm 1 Routing Table Construction Algorithm 1.For each destination node j , 1 = n,compute the path P j = r1 ,r2 ,...rk that exist from source node 0 to j. 2. For each path in set P j repeat the following steps 2.1.Let r1 be a path consisting of q11 ,q12 , q13 ...ql be the set of nodes contained in one of the path of destination node j. 2.1.1. Set Routing matrix[q11 ,q12 ]=q12 , and Routing matrix[q12 ,q11 ]=q11 . Set Routing matrix[q12 ,q13 ]=q13 , and Routing matrix[q13 ,q12 ]=q12 , .. Set Routing matrix[qk−1 ,qk ]=qk , and Set Routing matrix[qk ,qk−1 ]=qk−1 . 3. If there exists one path in P j update all the routing matrices. 4. If there are ’m’ multiple paths then update ’m’ routing matrices with each element in P j along ’m’ paths.

shown in Figure 2 result in the path obtained from each destination nodes and are as follows. P1={0 ↔ 1}, P2={0 ↔ 2}, P3={0 ↔ 3}, P4={0 ↔ 4}, P5={q1 = 0 ↔ 1 ↔ 5, q2 = 0 ↔ 3 ↔ 5}, P6={0 ↔ 4 ↔ 6}, P7={q1 = 0 ↔ 1 ↔ 5 ↔ 7, q2 = 0 ↔ 3 ↔ 5 ↔ 7, q3 = 0 ↔ 4 ↔ 6 ↔ 7}, P8={q1 = 0 ↔ 1 ↔ 5 ↔ 8, q2 = 0 ↔ 3 ↔ 5 ↔ 8, q3 = 0 ↔ 4 ↔ 6 ↔ 7 ↔ 8, q4 = 0 ↔ 1 ↔ 5 ↔ 7 ↔ 8, q5 = 0 ↔ 3 ↔ 5 ↔ 7 ↔ 8} The routing paths constructed as per Algorithm 1 by considering two paths from node at lowest level (node 0) to highest level (node 8) are shown in Table 1-2. The routing information for the other three paths from node 0 to node 8 can be constructed in the same way. 4. Design Elements of CoAP The design elements of CoAP are evolved from RFC 7252 28 and are based on the concepts described in 4 a) SERVICE Specification It is a protocol used for web transfer among constrained devices and connected via internet. CoAP implements a RESTful environment for constrained devices. RESTful nature of this protocol is realized by using Request/Response

303

Anchal J. Vattakunnel et al. / Procedia Computer Science 93 (2016) 299 – 308 Table 1. Routing Table 1

PP

PPDest PP

Src 0 1 2 3 4 5 6 7 8

0

1

2

3

4

5

6

7

8

-1 0 0 0 0 1 4 5 5

1 -1 0 0 0 1 4 5 5

2 0 -1 0 0 1 4 5 5

3 0 0 -1 0 3 4 5 5

4 0 0 0 -1 1 4 6 7

1 5 0 5 0 -1 7 5 5

4 0 0 0 6 7 -1 6 7

1 5 0 5 6 7 7 -1 7

1 5 0 5 6 8 7 8 -1

0

1

2

3

4

5

6

7

8

-1 0 0 0 0 1 4 5 7

1 -1 0 0 0 1 4 5 5

2 0 -1 0 0 1 4 5 5

3 0 0 -1 0 3 4 5 5

4 0 0 0 -1 1 4 6 7

1 5 0 5 0 -1 7 5 5

4 5 0 0 6 7 -1 6 7

1 5 0 5 6 7 7 -1 7

1 5 0 5 6 7 7 8 -1

Table 2. Routing Table 2

PP Src 0 1 2 3 4 5 6 7 8

PPDest PP

architecture. CoAP assumes every smart objects used in IoT as a list of URIs. Here a client request a particular service from a RESTfull server by specifying the URI. The services include sensing and actuation. The server responds to the client via replay message. A particular server can handle several requests and services. The protocol should provide reliable service that can withstand link failures. b) ASSUMPTION about environment i).The components involved are CoAP Clients that request the service to the CoAP server by specifying its URI followed by service specification. The request can be cached through intermediate nodes that act as proxy. ii). The transmission channels are full duplex, wireless and lossy. iii). Transport layer protocol used is UDP. iv). Network and MAC layer used are 6LOWPAN and IEEE 802.15.4. c) VOCABULARY CoAP supports the following messages. i). GET : Used to retrieve the resource specified by the URI-path ii). PUT : Used to Update or actuate specific bits / devices identified by URI-path. iii).DELETE : Used to remove a specific service from the device identified by URI-path. iv). POST : Used to create a specific URI path for later use. v). ACK : It is the message issued from the server side in response to a confirmable message. vi). RST: If the message is unable to process by the server it will responds with a RST message indication that message can’t be processed. d) FORMAT Format of CoAP frame is shown in Figure 3 Version (Ver): 2-bit unsigned integer, the CoAP version number it is set to 1 (01 binary).

304

Anchal J. Vattakunnel et al. / Procedia Computer Science 93 (2016) 299 – 308

Fig. 3. CoAP Frame 28

Type (T): 2-bit unsigned integer indicating message types. Code: 8-bit unsigned integer. indicating the type of message request and response. e) PROCEDURE RULES 1. A CoAP client can sent any one of the following message types which may be either a confirmable (CON) or Non-Confirmable (NON) 1.1 GET, POST, PUT & DELETE. Client will retransmit the same message if it doesn’t receive the ACK within the ACK timeout interval for CON message.Client will also perform retransmission if it doesn’t receive any response for NON messages. 1.2 Number of retransmission from the client side will be limited to maximum retransmission limit specified by the protocol. 2. When a server receives a confirmable message described in rule 1.1 it can respond either by sending a piggybacked response with ACK , response code, payload and message-ID or as a separate response with ACK, response code and message-id without payload. 2.1 In case of separate response server initially sends ACK with response code 0.00 indicting that the response will be send at later time. When the server is free it will send a CON message with payload and code 2.05 and its token specified in CON request received earlier. 2.1.1 If the server do not receive a client response in lieu of the ACK message with code 0.00 send in rule 2.1 within a stipulated time the server retransmits the same message. 3. When a server receives a NON message it responds with a response code followed by payload if response is positive. 4. When a client receives a separate response for a CON message, the client sends an ACK with response code 0.00. 5. Modelling and Formal verification of CoAP 5.1. Validation Model for CoAP A validation model for CoAP was built by using PROMELA. The model abstract out the procedural rules with emphasis given to the CON message sequence associated with GET. This is due to similarity of external behavior that exists among other confirmable messages. The model follows the topology described in Figure 2. The routing behavior was incorporated in accordance with the routing path construction algorithm described in section III. The external message sequence interaction among various nodes of the model generated by using SPIN model checker is depicted in Figure 4 Which describes the message sequence interaction Here a CON GET message is sent from node 0 to node 8 and its corresponding piggybacked ACK from node 8 to node 0. The process id ( pid) assigned by the model checker for node 0, node 1, node 5, node 7 and node 8 involved in message exchanges are 1,2,6,8 and 9 respectively. The path chosen by the model in accordance with Table 2.

5.2. Formal Verification of CoAP The formal verification was done for a set of nine nodes as per the topology described in Figure 2. Here node 0 was considered as client node and all other nodes treated as server nodes. The properties are inserted in the validation

Anchal J. Vattakunnel et al. / Procedia Computer Science 93 (2016) 299 – 308

Fig. 4. Scenario/Sequence Diagram

model and are verified for message interaction between client node and other server nodes separately. The verification was done using bit state hashing and maximum search depth was limited up to 252. The properties that are verified in the model have full state space coverage. Various properties inserted in the model are described below. Property 1:When a CON GET message is send to any of the destination node it will eventually reach the server node. The LTL corresponding to this property is described as follows. ltl p1 ( []S ->[]C ) S is a boolean variable that will be set to true in the model whenever a message is received from client. Another boolean variable C is set to true in the model whenever a client sent a message to any destination node. The equivalent nevr claim for the LTL is given in Listing1 ( []S ->[]C ) is Listing 1. Never Claim for Property 1

never { T0 init : do :: :: :: :: od ; accept S10 : do :: od ; accept S26 : do :: od ; T0 S10 : do :: :: od ; T0 S23 : do ::

/ ∗ ( [] ( S ) −> [] (C ) ) ∗ / ( ( C ) ) −> g o t o a c c e p t S 1 0 ( 1 ) −> g o t o T0 S10 ( ! ( ( S ) ) ) −> g o t o a c c e p t S 2 6 ( 1 ) −> g o t o T0 S23

( 1 ) −> g o t o T0 S10

( ! ( ( S ) ) ) −> g o t o a c c e p t S 2 6

( ( C ) ) −> g o t o a c c e p t S 1 0 ( 1 ) −> g o t o T0 S10

( ! ( ( S ) ) ) −> g o t o a c c e p t S 2 6

305

306

Anchal J. Vattakunnel et al. / Procedia Computer Science 93 (2016) 299 – 308

: : ( 1 ) −> g o t o T0 S23 od ; } The results obtained after verifying this property using Table 2 was described in Table 3. The results suggest that the Table 3. Verification Result: Property 1 Destination

Depth Searched

Hash Factor

State Stored

Memory Usage (MB) for States

Pan:Rate States/ Second

1 2 3 4 5 6 7 8

192 192 192 192 212 212 232 252

657930 657930 657930 657930 559241 559241 486296 430185

204 204 204 204 240 240 276 312

318 318 318 318 376 376 434 492

4.359 4.359 4.359 4.359 5.128 5.128 5.897 6.666

2266.667 2127 2150 2181.85 1800 2160 2266.667 2080

model checker performs full state space searched and the property is satisfied. The verification was repeated using all the remaining routing paths and results show that this property is satisfied. Property 2:Absence of Non-Progressive cycle The never claim used for checking non-progress cycles is shown in Listing 2. Listing 2. Never Claim for Property 2

never { T0 init :

/ ∗ [] n p

∗/

do : : ( ( n p ) ) −> g o t o a c c e p t S 9 : : ( 1 ) −> g o t o T 0 i n i t od ; accept S9 : do : : ( 1 ) −> g o t o T 0 i n i t od ; } SPIN model checker maintains a reserved in variable named ’np ’ . The value of the variable will be set to true by the model checker if there are any execution sequence that cycles through unmarked states. Any occurrence of non-progress cycle causes never claim to cycle through state marked as ’accept S4’. This will violate the property of absence of non-progress cycles. The verification results showing the absence of non-progress cycle for a CON GET message is as shown in the Table 4. Table 4. Verification Result: Property 2 Destination

Depth Searched

Hash Factor

State Stored

Memory Usage (MB) for States

Pan:Rate States/ Second

1 2 3 4 5 6 7 8

192 192 192 192 212 212 232 252

1.24276e+06 1.24276e+06 1.24276e+06 1.24276e+06 1.04858e+06 1.04858e+06 906877 798915

108 108 108 108 128 128 148 168

127 127 127 127 153 153 179 205

2.308 2.308 2.308 2.308 2.735 2.735 3.162 3.59

Property: 3: Absence of deadlock

2340 2127 2150 2135 1600 2560 2466.667 1866.667

Anchal J. Vattakunnel et al. / Procedia Computer Science 93 (2016) 299 – 308

This can be verified by running the PROMELA model without inserting any claims in the analyzer mode. The model checker flags error if any deadlock occurs. The verification result shows that the presence of zero errors and hence absence of deadlock. 5.3. Results and discussion The verification was carried after exploring full state space search for all the properties. The maximum search depth reached was 252 and was attained in the communication scenario between nodes belonging to lowest and highest level in the topology described in Figure 2. Specification of CoAP limits the number of communication for facilitating energy efficiency.Hence the number of state transitions occurred in the verification was limited. For the verification of application layer protocols that require continuous message exchanges, the number of state transitions will grow exponentially. 6. Conclusion and Future works A verification model for application layer protocols in IoT considering its interaction with routing layer was proposed. The proposed concept was illustrated by conducting formal verification of CoAP running on top of a compact form of RPL. A validation model for CoAP was built using PROMELA for a multi hop topology. The external behavior of the model was analyzed by generating a message sequence chart depicting the message flow between nodes. This model was verified by using SPIN model checker covering safety,liveness and correctness properties. The verification results were analysed in terms of memory usage,number of state transitions and maximum search depth attained for all the inserted properties. The proposed routing path construction can be applied for the verification of any application layer protocol for constrained devices. The basic correctness properties described for CoAP can be extended to include other message types by incorporating sufficient CoAP protocol abstractions. The routing path construction can also be extended to support dynamic topology changes. References 1. L. Ericsson, “More than 50 billion connected devices,” Ericsson White Paper, 2011. 2. N. Accettura, L. Grieco, G. Boggia, and P. Camarda, “Performance analysis of the rpl routing protocol,” in Mechatronics (ICM), 2011 IEEE International Conference on, pp. 767–772, IEEE, 2011. 3. R. Gerth, “A concise language reference for promela,” hnp://spinroot. comJspin/Man/Quick. html, 1997. 4. G. J. Holzmann, “Design and Validation of Computer Protocols Prentice Hall,” New Jersey, 1991. 5. G. J. Holzmann, “The model checker spin,” IEEE Transactions on software engineering, vol. 23, no. 5, p. 279, 1997. 6. D. Cˆamara, A. A. Loureiro, and F. Filali, “Formal verification of routing protocols for wireless ad hoc networks,” in Guide to Wireless Ad Hoc Networks, pp. 189–210, Springer, 2009. 7. M. C. Yuang, “Survey of protocol verification techniques based on finite state machine models,” in Computer Networking Symposium, 1988., Proceedings of the, pp. 164–172, IEEE, 1988. 8. M. V. Bharti and S. Kumar, “Survey of network protocol verification techniques,” International Journal of Scientific and Research Publications, vol. 2, 2012. 9. D. Broman, E. A. Lee, S. Tripakis, and M. T¨orngren, “Viewpoints, formalisms, languages, and tools for cyber-physical systems,” in Proceedings of the 6th International Workshop on Multi-Paradigm Modeling, pp. 49–54, ACM, 2012. 10. K. G. Larsen, P. Pettersson, and W. Yi, “Uppaal in a nutshell,” International Journal on Software Tools for Technology Transfer (STTT), vol. 1, no. 1, pp. 134–152, 1997. 11. M. M. Ben-Ari, “A primer on model checking,” ACM Inroads, vol. 1, no. 1, pp. 40–47, 2010. 12. M. Frappier, B. Fraikin, R. Chossart, R. Chane-Yack-Fa, and M. Ouenzar, “Comparison of model checking tools for information systems,” in Formal Methods and Software Engineering, pp. 581–596, Springer, 2010. 13. G. J. Holzmann, “Designing bug-free protocols with spin,” Computer Communications, vol. 20, no. 2, pp. 97–105, 1997. 14. G. J. Holzmann, “An analysis of bitstate hashing,” Formal methods in system design, vol. 13, no. 3, pp. 289–307, 1998. 15. R. G. de Vries and J. Tretmans, “On-the-fly conformance testing using spin,” International Journal on Software Tools for Technology Transfer, vol. 2, no. 4, pp. 382–393, 2000. 16. D. Boˇsnaˇcki and D. Dams, “Integrating real time into spin: A prototype implementation,” in Formal Description Techniques and Protocol Specification, Testing and Verification, pp. 423–438, Springer, 1998. 17. D. Cˆamara, A. A. F. Loureiro, and F. Filali, “Methodology for formal verification of routing protocols for ad hoc wireless networks,” in Global Telecommunications Conference, 2007. GLOBECOM’07. IEEE, pp. 705–709, IEEE, 2007.

307

308

Anchal J. Vattakunnel et al. / Procedia Computer Science 93 (2016) 299 – 308 18. R. De Renesse and A. Aghvami, “Formal verification of ad-hoc routing protocols using spin model checker,” in Electrotechnical Conference, 2004. MELECON 2004. Proceedings of the 12th IEEE Mediterranean, vol. 3, pp. 1177–1182, IEEE, 2004. 19. E. Javed Kashi, Kashi Asifa, “Implementation of spin model checker for formal verification of distance vector routing protocol,” (IJCSIS) International Journal of Computer Science and Information Security, vol. 8, no. 3, 2010. 20. S. M. Islam, M. H. Sqalli, and S. Khan, “Modeling and formal verification of dhcp using spin.,” IJCSA, vol. 3, no. 2, pp. 145–159, 2006. 21. H. B. Ali, M. R. Karim, M. Ashraf, and D. M. Powers, “Modeling and verification of extensible authentication protocol for transport layer security in wireless lan environment,” in Software Technology and Engineering (ICSTE), 2010 2nd International Conference on, vol. 2, pp. V2– 41, IEEE, 2010. 22. H. E. Jensen, K. G. Larsen, and A. Skou, “Modelling and analysis of a collision avoidance protocol using spin and uppaal,” BRICS Report Series, vol. 3, no. 24, 1996. 23. B. Kusy and S. Abdelwahed, “Ftsp protocol verification using spin,” ISIS, vol. 6, p. 704, 2006. 24. M. R. Palattella, N. Accettura, X. Vilajosana, T. Watteyne, L. A. Grieco, G. Boggia, and M. Dohler, “Standardized protocol stack for the internet of (important) things,” Communications Surveys & Tutorials, IEEE, vol. 15, no. 3, pp. 1389–1406, 2013. 25. * G. Montenegro, N. Kushalnagar, J. Hui, and D. Culler, “Rfc 4944,” Transmission of IPv6 packets over IEEE, vol. 802, no. 4. 26. G. Mulligan, “The 6lowpan architecture,” in Proceedings of the 4th workshop on Embedded networked sensors, pp. 78–82, ACM, 2007. 27. T. Winter, P. Thubert, J. Vasseur, et al., “Rpl: Routing protocol for low power and lossy networks, rfc6550,” 2012. 28. Z. Shelby, K. Hartke, and C. Bormann, “The constrained application protocol (coap)(rfc 7252),” 2014. 29. C. Bormann, A. P. Castellani, and Z. Shelby, “Coap: An application protocol for billions of tiny internet nodes,” IEEE Internet Computing, vol. 16, no. 2, p. 62, 2012. 30. W. Colitti, K. Steenhaut, N. De Caro, B. Buta, and V. Dobrota, “Evaluation of constrained application protocol for wireless sensor networks,” in Local & Metropolitan Area Networks (LANMAN), 2011 18th IEEE Workshop on, pp. 1–6, IEEE, 2011.