MTVV 2009 Modeling, Validation, and Verification of PCEP using the IF Language June 30, 2009 Iksoon...

MTVV 2009

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

Modeling, Validation, and Verification of PCEPMTVV 20092/29

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


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.


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


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.


PCE Communication Protocol (PCEP) PCE-based architecture• PCE is an entity that computes a network path based on a netwo

rk graph and computational constraints.• Path Computation Client (PCC) is any kind of client application re

questing a path computation.• PCEP is a communication protocol between a PCC and a PCE, o

r between two PCEs. PCEP has been standardized by IETF as RFC 5440 in March 20

09


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


PCE Communication Protocol (PCEP) Finite state machine


PCE Communication Protocol (PCEP) An example scenario: session establishment after negotiation

PCCPCE

Open Open

TCP ConnectionEstablished

Error Keepalive

Keepalive

Open

PCEP SessionEstablished

Session parametersnot acceptable

Prepare new session parameters


IF (Intermediate Format) Developed by Verimag IF model• A system is expressed by a set of parallel processes communicat

ing asynchronously through a set of buffers.• An IF process is described as a timed automaton extended with d

iscrete 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 inp

ut message where an urgency attribute (eager, delayable or lazy) defines the priority of the transition over time progress.


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.


Formal description of PCEP The functionalities of PCEP are divided into application and pr

otocol.• 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, c

ollision 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.


Formal description of PCEP Overall architecture

Environment (PCEP application)

TCP_Open_req, TCP_Data_req,TCP_Close_req, TCP_Abort_req

System PCEP

Environment (TCP)

TCP_Open_cfm,TCP_Data_ind,TCP_Close_ind,TCP_Abort_ind,TCP_connection_fail_ind

PCEP_Open_req,PCEP_Keepalive_req,PCEP_PCReq_req,PCEP_PCRep_req,PCEP_Noti_req, PCEP_Error_req,PCEP_Close_req

PCEPMain

PCEP_Open_ind,PCEP_Keepalive_ind,PCEP_PCReq_ind,PCEP_PCRep_ind,PCEP_Noti_ind,PCEP_Error_ind.PCEP_Close_ind

TCP_Open_indTCP_Open_resp

Invoke PCEPChild

PCEP_Open_init_req


Formal description of PCEP Processes• PCEPMain to handle session initiation requests and multiple inst

ances of PCEPChild process to handle PCEP sessions. Service primitives• Service primitives are based on PCEP messages and TCP functi

on 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 f

low, e.g. TCPPending_TCP_Open_cfm_decision.


Formal description of PCEPstate 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, child

InfoTable Timers• tcpConnectTimer, pcepOpenWaitTimer, pcepKeepWaitTimer, pc

epKeepaliveTimer, and pcepDeadTimer, internalKeepWaitTimer, internalOpenWaitTimer


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.


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.


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 a

nd a PCEPChild process which was used for clearing internal resources.

Process

Buffer(FIFO)

env

signalroute_1 (FIFO or Multiset)

signalroute_n-1(FIFO or Multiset)

peer process_1

peer process_n-1

peer process_n


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.


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.

index condition output next state

56KeepWait timer active

No error in msgRemoteOK = 0

PCEP_Keepalive_ind OpenWaitTCP_Data_PCEP_Keepalive_ind

State Input

KeepWait


Validation of PCEP using observerExample) 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;


Validation of PCEP using observer Configurations• The timer values, retry numbers, and the range of parameter valu

es 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 number

s, 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.


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.


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.

Properties # of states # of transitionsTime

(hh:mm:ss)Results

Prop. G1 85514 2855179 12:26:09 Interrupted (No failure)Prop. G2 1568 54981 6 ValidatedProp. G3 51923 1050744 3:47 ValidatedProp. 18 2516 55929 9 Failed (No success)Prop. 29 108111 2629793 9:58:28 Interrupted (Success, No failure)Others < 33500 < 867000 < 2:25 Validated


Validation of PCEP using observer

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.

Property 18Property 18


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.


Test generation for PCEP Testgen-IF• Generates timed test cases from an IF specification and a set of t

est purposes.• Partial state space exploration guided by test purposes (the Hit-o

r-Jump algorithm) is used.• A test purpose is a set of (ordered) conditions where a condition i

s a conjunction of constraints.Example) Test purpose for requirement 56tp56 = {cond1}

cond1 = constraint1 ^ constraint2 ^ … ^ constraint7constraint1 = “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.


Test generation for PCEP Configurations• The timer values, retry numbers, and parameter values are limite

d during state space exploration for most test purposes.• If it is necessary to have other parameter values, the ranges of th

ose parameters are changed appropriately. Test generation results• Test sequences are generated successfully for all 98 test purpos

es.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).


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.


Errors and Ambiguities found Errors• In the OpenWait State, what should be the next state if an Open message is recei

ved, without errors, without collision problem, but that is unacceptable? • In addition to the problem A, when the system in OpenWait state receives an Ope

n 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 pa

ragraph.• In the OpenWait State, the meaning of error is not clear. There are three example

s 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, ...),"


Errors and Ambiguities found• In the OpenWait State, when an an Open message is received, without errors, wit

hout 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.

MTVV 2009 Modeling, Validation, and Verification of PCEP using the IF Language June 30, 2009 Iksoon...

Documents

Transcript of MTVV 2009 Modeling, Validation, and Verification of PCEP using the IF Language June 30, 2009 Iksoon...