Modeling, Validation, and Verification of PCEP using the IF Language

1. Modeling, Validation, and Verification of PCEPusing the IF Language June 30, 2009 Iksoon HWANG, Mounir LALLALI, Ana CAVALLI TELECOM & Management SudParis Dominique VERCHERE Alcatel-Lucent R&I

2. Contents • Formal methods • CARRIOCAS project • PCE Communication Protocol (PCEP) • Intermediate Format (IF) • Formal description of PCEP • Validation and verification of PCEP • Test generation for PCEP • Conclusions Modeling, Validation, and Verification of PCEP

3. Formal methods • What is formal methods? • Mathematically rigorous techniques that can be used to describe and analyze the behavior of systems • Less ambiguous specifications can be provided. • Formal specification can be used in model checking and model-based testing. • What is validation? • The process of evaluating software during or at the end of the development process to determine whether it satisfies specified requirements. Modeling, Validation, and Verification of PCEP

4. CARRIOCAS project • Objectives • Providing a distributed pilot network for industrial applications with high complexity, scope, and scale • Applications • Car design with crash simulations for safety analysis • Energy production with atomic reactor models for central problem simulations • Partners Modeling, Validation, and Verification of PCEP

5. CARRIOCAS project • Design and development activities • A common service management component based on the Scheduling, Reconfiguration, and Virtualization (SRV) is under development. • Path Computation Element (PCE)-based architecture is used in order to provide connection services above different types of infrastructures. • Validation activities • As a part of the validation activities, Path Computation Element Communication Protocol (PCEP) is chosen for validation and verification. Modeling, Validation, and Verification of PCEP

6. PCE Communication Protocol (PCEP) • PCE-based architecture • PCE is an entity that computes a network path based on a network graph and computational constraints. • Path Computation Client (PCC) is any kind of client application requesting a path computation. • PCEP is a communication protocol between a PCC and a PCE, or between two PCEs. • PCEP has been standardized by IETF as RFC 5440 in March 2009 Modeling, Validation, and Verification of PCEP

7. PCE Communication Protocol (PCEP) • Messages • Open: to initiate and negotiate a PCEP session. • Keepalive: to establish and maintain a PCEP session. • PCReq: to request a path computation. • PCRep: to reply to a path computation request. • PCNtf: to notify a specific event. • PCErr: to notify the occurrence of a protocol error condition. • Close: to close a PCEP session. • States • Idle, TCPPending, OpenWait, KeepWait, SessionUP Modeling, Validation, and Verification of PCEP

8. PCE Communication Protocol (PCEP) • Finite state machine Modeling, Validation, and Verification of PCEP

9. PCE Communication Protocol (PCEP) • An example scenario: session establishment after negotiation PCE PCC TCP Connection Established Open Open Session parameters not acceptable Error Keepalive Prepare new session parameters Open Keepalive PCEP Session Established Modeling, Validation, and Verification of PCEP

10. IF (Intermediate Format) • Developed by Verimag • IF model • A system is expressed by a set of parallel processes communicating asynchronously through a set of buffers. • An IF process is described as a timed automaton extended with discrete data variables. • Two types of control states: stable states and unstable states • A unstable state is a temporary state where no interleaving between processes is possible. • Transitions describe the behavior of a process on stimuli. • A transition can be triggered either by (timed) guards or by an input message where an urgency attribute (eager, delayable or lazy) defines the priority of the transition over time progress. Modeling, Validation, and Verification of PCEP

11. IF (Intermediate Format) • IF Toolset • Provides an environment for modeling and validation of an IF specification. • Core components: IF static analyzer and IF exploration platform • IF static analyzer transforms an IF specification into an abstract syntax tree. • IF exploration platform performs the simulation of process executions by using the abstract syntax trees. • A set of open APIs is provided. • Observers • Observer process is executed in parallel with the target system and monitors events in the target system. • We can check if given properties hold for an IF specification. Modeling, Validation, and Verification of PCEP

12. Formal description of PCEP • The functionalities of PCEP are divided into application and protocol. • The functionalities of the application part include • session initiation, session parameter negotiation, request/reply of path computation, notification of specific events, closing the session, etc. • The functionalities of the protocol part include • handling of finite state machines including local variables and timers, collision resolution procedure, keeping the current session by exchanging Keepalive messages, etc. • The protocol part is modeled by a system. • PCEP applications and the lower layer (TCP) are considered to be an environment. Modeling, Validation, and Verification of PCEP

13. Environment (PCEP application) System PCEP PCEP_Open_ind, PCEP_Keepalive_ind, PCEP_PCReq_ind, PCEP_PCRep_ind, PCEP_Noti_ind, PCEP_Error_ind. PCEP_Close_ind PCEP_Open_req, PCEP_Keepalive_req, PCEP_PCReq_req, PCEP_PCRep_req, PCEP_Noti_req, PCEP_Error_req, PCEP_Close_req PCEP_Open_init_req PCEPMain PCEPChild Invoke TCP_Open_cfm, TCP_Data_ind, TCP_Close_ind, TCP_Abort_ind, TCP_connection_fail_ind TCP_Open_resp TCP_Open_ind TCP_Open_req, TCP_Data_req, TCP_Close_req, TCP_Abort_req Environment (TCP) Formal description of PCEP • Overall architecture Modeling, Validation, and Verification of PCEP

14. Formal description of PCEP • Processes • PCEPMain to handle session initiation requests and multiple instances of PCEPChild process to handle PCEP sessions. • Service primitives • Service primitives are based on PCEP messages and TCP function interfaces. • A number of service primitives are newly introduced, e.g. PCEP_Open_init_req and TCP_Data_PCEP_xxxx_req/ind. • States • Stable states: Idle (in PCEPMain), idle, TCPPending, OpenWait, KeepWait, and SessionUP (in PCEPChild) • A number of unstable states are introduced to branch off control flow, e.g. TCPPending_TCP_Open_cfm_decision. Modeling, Validation, and Verification of PCEP

15. Formal description of PCEP state TCPPending; deadline lazy; input TCP_Open_cfm(tcpConnectResult); nextstate TCPPending_TCP_Open_cfm_decision; ... endstate; state TCPPending_TCP_Open_cfm_decision #unstable ; provided (tcpConnectResult = ConnectSuccess); ... nextstate OpenWait; ... endstate; • Internal variables • tcpConnectRetry, pcepOpenRetry, remoteOK, and localOK, childInfoTable • Timers • tcpConnectTimer, pcepOpenWaitTimer, pcepKeepWaitTimer, pcepKeepaliveTimer, and pcepDeadTimer, internalKeepWaitTimer, internalOpenWaitTimer Modeling, Validation, and Verification of PCEP

16. Formal description of PCEP • Abstraction of Information • Each PCEP message has a common header and may have a number of PCEP objects. • The number of parameters is minimized in our service primitives. Modeling, Validation, and Verification of PCEP

17. Formal description of PCEP • Remarks • A number of errors and ambiguities were found during modeling phase, e.g. • a wrong sentence that misleads the behavior of the protocol; • unclear descriptions (when a timer should be started?). • Two issues related to IF • How to make time progress in a system? • Time can progress only in stable configurations as long as there is no executable eager transition. • There is always at least one executable transition enabled by an input message from environment at any stable state in our model. • lazy deadline is used for all transitions enabled by an input message from environment. Modeling, Validation, and Verification of PCEP

18. Formal description of PCEP • Is the first incoming message served first in a process? • Communication between two processes in a system is asynchronous. • Communication between a process and environment is synchronous. • We removed an internal communication between the PCEPMain process and a PCEPChild process which was used for clearing internal resources. signalroute_1 (FIFO or Multiset) peer process_1 Buffer (FIFO) Process peer process_n-1 signalroute_n-1 (FIFO or Multiset) peer process_n env Modeling, Validation, and Verification of PCEP

19. Validation of PCEP using observer • Checking properties • Properties are based on observable actions such as input and output messages, and also include checking variable values and clock values. • Properties are described in IF including counterexamples. • The observer process checks if it can observe the expected behavior during an exhaustive state space exploration. • General properties • Property G1: The specification must be deadlock-free. • Property G2: In any state, there must be at least one active timer. • Property G3: In any state, the value of any active timer must be no greater than its maximum. Modeling, Validation, and Verification of PCEP

20. Validation of PCEP using observer • Properties specific to PCEP • The behavior of the system for a given set of state, input, and conditions is described in a state transition table. • Each behavior is considered to be a requirement. • 101 requirements are identified from a complete state transition table and 66 requirements are described as properties. • It is considered that the formal specification holds the property if the system sends the expected output messages and moves to the expected next state for the given set of state, input, and conditions. Modeling, Validation, and Verification of PCEP

21. Validation of PCEP using observer Example) observer process for checking property 56 cut observer ob; /* Variable definitions and initializations of variables */ state idle ; match input TCP_Data_PCEP_Keepalive_ind(errorInPCEPMessage_obs) in p1; task previousState := ({PCEPMain}0).childInfoTable[0].previousState; task currentState := ({PCEPMain}0).childInfoTable[0].currentState; nextstate input_matched; endstate; state input_matched; provided (previousState = KeepWait) and (errorInPCEPMessage_obs = false) and (currentState <> Idle) and (({PCEPChild}0).remoteOK = false); nextstate check_output_nextstate; endstate; state check_output_nextstate; match output (so) from p1; if (so instanceof PCEP_Keepalive_ind) and (currentState = OpenWait) then informal "--Validation Success!"; else informal "--Validation Fail!"; cut; endif nextstate idle; endstate; endobserver; Modeling, Validation, and Verification of PCEP

22. Validation of PCEP using observer • Configurations • The timer values, retry numbers, and the range of parameter values are be limited, e.g. • tcpConnectTimer timer: 60 seconds → 2 seconds • tcpConnectMaxRetry variable: 5 times → 2 times • errorType parameter: 1~10 → 1 • errorValue parameter: 1~8 → 1~6 • One instance of a child process can be completely explored with • 410 states and 12,010 transitions when the timer values, retry numbers, and the range of parameter values are limited; • 3,095 states and 55,355,305 transitions when the timer values and retry numbers are limited; • 85,750 states and 3,945,670 transitions when the range of parameter values are limited. Modeling, Validation, and Verification of PCEP

23. Validation of PCEP using observer • Two instances of a child process can be completely explored with 74,476 states and 4,294,788 transitions when the timer values, retry numbers, and range of parameter values are limited. • For most properties, validation is carried out with • one instance of PCEPChild; and • the timer values, retry numbers, and range of parameter values are limited. • If it is necessary to have other parameter values, the ranges of those parameters are changed appropriately, e.g. • for the property 29, the validation is carried out with two instances of a child process since it checks if the current PCEP connection is released by the collision resolution procedure. Modeling, Validation, and Verification of PCEP

24. Validation of PCEP using observer • Validation results • Remarks • For two properties (property G1 and property 29), the simulations were interrupted after around 10 hours because of state space explosion problem. • The property 18 does not hold for our formal specification. A problem was found in the original PCEP specification such that there exists a case that never happens. Modeling, Validation, and Verification of PCEP

25. Validation of PCEP using observer Property 18 When a system is in OpenWait state and receives an Open message from its peer where no errors are detected in the message, OpenRetry is 0, the session characteristics are unacceptable but negotiable, and LocalOK=1, the system should restart the OpenWait timer and stays in OpenWait state. Modeling, Validation, and Verification of PCEP

26. Validation of PCEP using observer • The size of the state space decreased significantly (30,329 states and 941,313 transitions → 410 states and 12,010 transitions) by initializing redundant internal variables by the end of each transition. state TCPPending; deadline lazy; input TCP_Open_cfm(tcpConnectResult); nextstate TCPPending_TCP_Open_cfm_decision; ... endstate; state TCPPending_TCP_Open_cfm_decision #unstable ; provided (tcpConnectResult = ConnectSuccess); ... task tcpConnectResult := ConnectFail; nextstate OpenWait; ... endstate; • Variable values or parameter values cannot be checked by observer if these values are initialized after the execution of the transition. Modeling, Validation, and Verification of PCEP

27. Test generation for PCEP • Testgen-IF • Generates timed test cases from an IF specification and a set of test purposes. • Partial state space exploration guided by test purposes (the Hit-or-Jump algorithm) is used. • A test purpose is a set of (ordered) conditions where a condition is a conjunction of constraints. Example) Test purpose for requirement 56 tp56 = {cond1} cond1 = constraint1 ^ constraint2 ^ … ^ constraint7 constraint1 = “process : instance = {PCEPChild}0" constraint2 = “state : source = KeepWait" constraint3 = “state : target = OpenWait" constraint4 = “action : input TCP_Data_PCEP_Keepalive_ind(f)" constraint5 = “action : output PCEP_Keepalive_ind()" constraint6 = “variable : remoteOK = false" constraint7 = “clock : pcepKeepWaitTimer is active“ • Among 101 requirements, 98 requirements are described as test purposes. Modeling, Validation, and Verification of PCEP

28. Test generation for PCEP • Configurations • The timer values, retry numbers, and parameter values are limited during state space exploration for most test purposes. • If it is necessary to have other parameter values, the ranges of those parameters are changed appropriately. • Test generation results • Test sequences are generated successfully for all 98 test purposes. Example) Test sequence for test purpose 56 ?TCP_Open_ind{1,ConnectSuccess} !TCP_Open_resp{ConnectSuccess} !TCP_Data_PCEP_Open_req{{{2,8}}} ?TCP_Data_PCEP_Open_ind{f,{{2,8}}} !PCEP_Open_ind{{{2,8}}} ?PCEP_Error_req{{1,{{1,4},}}} !TCP_Data_PCEP_Error_req{{1,{{1,4},}}} ?TCP_Data_PCEP_Keepalive_ind{f} !PCEP_Keepalive_ind{} • After deleting redundant test sequences, we finally obtain 90 test sequences (the total number of test inputs is 353). Modeling, Validation, and Verification of PCEP

29. Conclusions • A formal method is successfully applied in validation and verification of PCEP which was newly designed communication protocol. • Most ambiguities and errors were found during modeling phase. • We can provide higher quality of specifications when we describe specifications using formal methods even before validation phase. • The generated test cases will be used for testing implementations of one of the partners of the CARRIOCAS project. • A solution for the one of the issue related to IF should be addressed. Modeling, Validation, and Verification of PCEP

30. Errors and Ambiguities found • Errors • In the OpenWait State, what should be the next state if an Open message is received, without errors, without collision problem, but that is unacceptable? • In addition to the problem A, when the system in OpenWait state receives an Open message from its peer and If no errors are detected, and OpenRetry is 0, and the session characteristics are unacceptable but negotiable, and LocalOK=1, the system restarts the OpenWait timer and stays in the OpenWait state. • The Keepalive timer is supposed to be set when the PCEP sends a Keepalive message in OpenWait state. However, this does not conform to the purpose of the Keepalive timer. • Ambiguities • The explanation of TCPRetry is missing. • The variable 'Connect' is also called as ' TCPConnect' timer - both in the same paragraph. • In the OpenWait State, the meaning of error is not clear. There are three examples for error cases but still can have other possibilities. “If an error is detected (e.g. malformed Open message, reception of a message that is not an Open essage, presence of two Open objects, ...)," Modeling, Validation, and Verification of PCEP

31. Errors and Ambiguities found • In the OpenWait State, when an an Open message is received, without errors, without collision problem, and that is acceptable, description of the next state is ambiguous. In the specification, LocalOK are described in separate sentences in the specification. • In the OpenWait State, when an an Open message is received, without errors, without collision problem, and that is acceptable, description of the next state is ambiguous. In the specification, LocalOK are described in separate sentences in the specification. • It is mentioned that in SessionUP state “If the system detects that the PCEP peer tries to setup a second TCP connection, it stops the TCP connection establishment and sends a PCErr with Error-Type=9.” However, it is not clear through which TCP connection the PCErr message should be sent. • During the session establishment, i.e. in OpenWait and KeepWait states, it is not clearly defined when a PCEP receives PCErr message with other Error-types and Error-values than those described in the specification. For example, when the PCEP in KeepWait state receives a PCErr message from its peer PCEP where Error-type and Error-value are 1 and 4 respectively, no explanation is given in the specification whether to continue the session establishment or to close the session. • Once the session is established, i.e. in SessionUP state, it is not clear what should be done when the PCEP receives PCErr messages from its peer PCEP where the Error-type = 1. This is definitely abnormal case but whether to continue the session or not is not explained in the specification. Modeling, Validation, and Verification of PCEP