Network Protocol Design and Evaluation
Total Page:16
File Type:pdf, Size:1020Kb
Network Protocol Design and Evaluation 04 - Protocol Specification, Part I Stefan Rührup University of Freiburg Computer Networks and Telematics Summer 2009 Overview ‣ In the last chapter: • The development process (overview) ‣ In this chapter: • Specification • State machines and modeling languages • UML state charts and sequence diagrams • SDL and MSC (Part II) Network Protocol Design and Evaluation Computer Networks and Telematics Stefan Rührup, Summer 2009 2 University of Freiburg What are we modeling? Transitional Systems Reactive Systems input-output transformation event-driven e.g. scientific computation, compilers e.g. communication protocols, operating systems, control systems correctness criteria: correctness criteria: - termination - non-termination under normal - correctness of input-output conditions transformation - correctness of event-response actions formal models describe event-response sequences, including state information [S. Leue, Design of Reactive Systems, Lecture Notes, 2002] Network Protocol Design and Evaluation Computer Networks and Telematics Stefan Rührup, Summer 2009 3 University of Freiburg Specification with State Machines ‣ A protocol interacts with the environment • triggered by events • responds by performing actions • behaviour depends on the history of past events, i.e. the state event 1 state 1 state 2 action action event 2 ‣ state machines do not model the data flow, but the flow of control Network Protocol Design and Evaluation Computer Networks and Telematics Stefan Rührup, Summer 2009 4 University of Freiburg Specification with State Machines ‣ Why state machines? ...and not programming languages? • lack of formal semantics • risk of overspecification • requirements specification should be kept implementation-independent Network Protocol Design and Evaluation Computer Networks and Telematics Stefan Rührup, Summer 2009 5 University of Freiburg Finite State Machines ‣ Acceptors (sequence detectors) • produce a binary output (yes/no) on an input sequence • accept regular languages ‣ Transducers • Mealy machines (output determined on current state and input) • Moore machines (output determined on current state) • both models are equivalent Network Protocol Design and Evaluation Computer Networks and Telematics Stefan Rührup, Summer 2009 6 University of Freiburg Mealy Machines, Example 1 / 1 0 / 1 1 / 1 State In Out Next q0 q2 state q0 0 0 q1 state 0 / 0 0 / 0 q0 1 1 q0 q1 0 0 q2 q1 transition input / output q1 1 0 q1 q2 0 1 q2 1 / 0 q2 1 1 q0 state diagram state transition table Network Protocol Design and Evaluation Computer Networks and Telematics Stefan Rührup, Summer 2009 7 University of Freiburg Definition of a Mealy machine ‣ A Mealy state machine is a tuple (Q,q0,I,O,T,G), where • Q is a finite, non-empty set of states, • q0 ∈ Q is the initial state, • I is a finite set called the input alphabet, • O is a finite set called the output alphabet, • T is a transition function, T: S × I → S, and • G is an output function, G: S × I → O. Network Protocol Design and Evaluation Computer Networks and Telematics Stefan Rührup, Summer 2009 8 University of Freiburg Limitations of FSMs ‣ No data variables variable values and changes have to be coded into the state space → exponential state space explosion lift dial 0 dial 0 receiver q0 q1 q20 q30 dial 1 q21 q31 dial 2 dial 2 Example: dialing a telephone number q22 q32 Network Protocol Design and Evaluation Computer Networks and Telematics Stefan Rührup, Summer 2009 9 University of Freiburg Limitations of FSMs ‣ Problem with finite memory: • finite variable range • problem when modeling communication channels: - size of the channel unknown - determining buffer size = overspecification Network Protocol Design and Evaluation Computer Networks and Telematics Stefan Rührup, Summer 2009 10 University of Freiburg Limitations of FSMs ‣ Problem with concurrent FSMs • no communication channels • no synchronization • composition of interacting FSMs leads to new states and an explosion of the state space ‣ Communication protocols can be seen as concurrent state machines Network Protocol Design and Evaluation Computer Networks and Telematics Stefan Rührup, Summer 2009 11 University of Freiburg Limitations of FSMs ‣ Missing abstraction, missing composition dial digit [incomplete] dialed number has to dial digit Dial Tone Dialing be coded into states! lift receiver / play dial tone dial digit [valid] / connect hang up Idle Connecting Busy busy connected here, a group transition Talking Ringing could be used callee answers Network Protocol Design and Evaluation Computer Networks and Telematics Stefan Rührup, Summer 2009 12 University of Freiburg State machines for specification ‣ Original FSMs are not suitable for modeling and specifying processes in distributed systems ‣ Extended state machine models: • Communicating Finite State Machines • Harel statecharts (superstates, concurrent states) • Extended Finite State Machines (variables, operations, conditions) • Basis for many practical modeling and specification languages such as SDL, UML. Network Protocol Design and Evaluation Computer Networks and Telematics Stefan Rührup, Summer 2009 13 University of Freiburg Description Languages: Structure vs. Behaviour ‣ Structural languages: • describe the static, structural concept (architecture) • e.g. class diagrams, component diagrams ‣ Behavioural languages: • describe behaviour, i.e. activities, interaction • e.g. state machines and sequence diagrams Network Protocol Design and Evaluation Computer Networks and Telematics Stefan Rührup, Summer 2009 14 University of Freiburg Description Languages: Constructive vs. reflective ‣ Constructive languages: • describe information for executing the model or for (executable) code generation • e.g. state machines ‣ Reflective or assertive languages: • describe views of the model, statically or during execution • e.g. sequence diagrams [D. Harel: “Some thoughts on statecharts, 13 years later”, 1996] Network Protocol Design and Evaluation Computer Networks and Telematics Stefan Rührup, Summer 2009 15 University of Freiburg starting point CLOSED appl: passive open send: <nothing> appl: send: SYNactive open timeout starting point send: RST LISTEN CLOSED passive open appl: send: SYNsend data send: SYN, ACK appl: passive open Example:cv: RST re send: <nothing> cv: SYN; appl: re recv: SYN appl: close send: SYNactive open SYN_RCVDTCP state transition timeoutSYN_SENT send: SYN, ACK send: RST or timeout LISTEN simultaneous open active open passive open send: re<nothing>diagram appl: cv: ACK send: SYNsend data send: SYN, ACK cv: SYN, ACK re send: ACK cv: RST re cv: SYN; [Wright, Stevens: “TCP/IP Illustrated, re appl: close recv: FIN Volume 2: The Implementation”,ESTABLISHED 1995] CLOSE_WAIT recv: SYN appl: close send: FIN send: ACK SYN_RCVD SYN_SENT data transfer state send: SYN, ACK or timeout simultaneous open active open send: re<nothing> close appl: close cv: ACK send: FIN appl: send: FIN cv: SYN, ACK re send: ACK simultaneous close recv: FIN recv: ACK FIN_WAIT_1 CLOSING LAST_ACKappl: close recv: FIN send: ACK send: <nothing> ESTABLISHED CLOSE_WAIT send: FIN send: ACK re data transfer state cv: FIN, ACK passive close send: ACK recv: ACK recv: ACK close send: <nothing> send: <nothing> appl: close send: FIN appl: send: FIN recv: FIN simultaneous close FIN_WAIT_2 TIME_WAIT recv: FIN recv: ACK send: ACK FIN_WAIT_1 CLOSING LAST_ACK 2MSL timeout send: ACK send: <nothing> re active close cv: FIN, ACK passive close send: ACK recv: ACK recv: ACK normal transitions for client normal transitions for server send: <nothing> send: <nothing> appl: state transitions taken when application issues operation recv: state transitions taken when segment received send: what is sent for this transition recv: FIN FIN_WAIT_2 TIME_WAIT send: ACK 2MSL timeout TCP state transition diagram. active close Network Protocol Design and Evaluation normal transitions for client Computer Networks and Telematics Stefan Rührup, Summer 2009 normal16 transitions for server University of Freiburg appl: state transitions taken when application issues operation recv: state transitions taken when segment received send: what is sent for this transition Reprinted from TCP/IP Illustrated, Volume 2: The Implementation by Gary R. Wright and W.RichardStevens, Copyright © 1995 by Addison-Wesley Publishing Company,Inc. TCP state transition diagram. Reprinted from TCP/IP Illustrated, Volume 2: The Implementation by Gary R. Wright and W.RichardStevens, Copyright © 1995 by Addison-Wesley Publishing Company,Inc. +---------+ ---------\ active OPEN | CLOSED | \ ----------- +---------+<---------\ \ create TCB | ^ \ \ snd SYN Example: passive OPEN | | CLOSE \ \ ------------ | | ---------- \ \ create TCB | | delete TCB \ \ TCP connection V | \ \ +---------+ CLOSE | \ state diagram | LISTEN | ---------- | | +---------+ delete TCB | | rcv SYN | | SEND | | ----------- | | ------- | V +---------+ snd SYN,ACK / \ snd SYN +---------+ [RFC 793] | |<----------------- ------------------>| | | SYN | rcv SYN | SYN | | RCVD |<-----------------------------------------------| SENT | | | snd ACK | | | |------------------ -------------------| | +---------+ rcv ACK of SYN \ / rcv SYN,ACK +---------+ | -------------- | | ----------- | x | | snd ACK | V V | CLOSE +---------+ | ------- | ESTAB | | snd FIN +---------+ | CLOSE | | rcv FIN V ------- | | ------- +---------+ snd FIN / \ snd ACK +---------+ | FIN |<----------------- ------------------>| CLOSE | | WAIT-1 |------------------ | WAIT | +---------+ rcv FIN \ +---------+