NETW 703
Network Protocols
Introduction
Dr. Eng. Amr T. Abdel-Hamid
Spring 2017
Amr Talaat
How to develop protocols?
(How to develop software?)
?
From the first idea ... to the final solution
•A development process that can be structured
Amr Talaat
Build and Fix
Build first
version
Simple process model
‣used for small projects
Modify until
client is satisfied
Development
Operations
Mode
Maintenance
Retirement
Problems
• no specification phase
• begin coding, think about requirements, design etc. later
• higher effort for fixing errors in later phases
Amr Talaat
Stages of the Development Process
‣
Basic activities (which appear in many process models)
• Requirements analysis
• Design specification
• Validation
• Implementation
• Test and evaluation
• Deployment
• Maintenance
4/38
Amr Talaat
Waterfall Model
Requirements
Design specification
and validation
Implementation
Test and evaluation
Deployment and
maintenance
Amr Talaat
Waterfall Model (Problems)
Requirements
Design specification
and validation
requirements may
change at any stage
Implementation
Test and evaluation
tests may reveal design flaws
and programming errors
fixes and patches
Deployment and
maintenance
Amr Talaat
Modified Waterfall model
Requirements
Design specification
and validation
Implementation
feedback loops
Test and evaluation
Deployment and
maintenance
Amr Talaat
V Model
Acceptance
test
Requirements
System design
System test
Architecture
design
Integration test
Module design
Implementation
Unit test
Amr Talaat
Process Models
The bottom line:
 Choice of a process models depends on the
type and complexity of the project
 Network protocols often need revisions and
extensions due to changing requirements or
problems
 Protocol design is an iterative process
Amr Talaat
Requirements

Requirements
 describe
desired behaviour of a protocol
 independent of the later design and
implementation
(describe what the protocol does, not how)
 Requirements Analysis/Engineering
has its own process

Amr Talaat
Requirements engineering
Customer or user
requirements
Requirements
elicitation
Requirements
analysis and
negotiation
Requirements
documentation
and specification
Negotiated and
validated
requirements
Requirements
validation
Amr Talaat
Types of Requirements

Functional requirements or use cases
 System
behaviour and data format
 Here: procedure rules and message format

Non-functional or quality requirements
 e.g.

reliability, performance
Design constraints
 environment,
interfaces
Amr Talaat
Requirements documents

Requirements definition
 abstract
description of the system’s services
and functions (external behaviour)
 mostly written in natural language
 for developers and users

Requirements specification
 precise
description of the system’s functions
 may be written in a formal language
Amr Talaat
Requirement documents
Contents of a Software Requirements Specification (SRS)
(according to IEEE Standard 830-1998)



Introduction (Purpose, Scope, Acronyms, References, Outline)
General Description (Context, Functions, Constraints, Assumptions)
Specific Requirements







External Interface Requirements
Functional Requirements
Performance Requirements
Design Constraints
Quality Requirements
Other Requirements
Appendices
Amr Talaat
Characteristics of Requirements
Requirements should be ...








correct (developer’s understanding = stakeholder’s
needs)
consistent (no conflicting goals)
unambiguous (formal specification)
complete (no under-specification)
relevant, design-independent (no over-specification)
feasible (possibility to meet all requirements)
verifiable/testable (quantifiable statements)
traceable (references to the specification)
Amr Talaat
Requirements validation


In general: checking that the specification
matches the user’s requirements
Ambiguity - Natural language or formal
notation?
 easily

understandable vs. precise and unambiguous
Making requirements consistent
 Resolving
conflicts, e.g. prioritization into essential,
desirable and optional goals (quality requirements)
Amr Talaat
Requirements validation

Testability: Requirements should be
quantified (holds also for the specification)
 the server is expected to respond immediately

better: the server has to respond within 5ms.
 the
packet is dropped after some
unsuccessful retries

better: the packet is dropped after 3 unsuccessful retries.
Each retry is triggered after a timeout of 2 x RTT.
Amr Talaat
Validation and Verification
Requirements
Validation
Design specification
and validation
Verification
Abstract
model
Implementation
Implemented
software
Test and evaluation
Deployment and
maintenance
Amr Talaat
Modeling: My Car Hates Vanilla Ice Cream

The following complaint was received by the Pontiac
Division of General Motors:
Dear Sir;
'This is the second time I have written to you, and I don't blame you
for not answering me, because I sounded crazy, but it is a fact that we
have a tradition in our family of Ice-Cream for dessert after dinner each
night, but the kind of ice cream varies so, every night, after we've eaten,
the whole family votes on which kind of ice cream we should have and I
drive down to the store to get it. It's also a fact that I recently purchased a
new Pontiac and since then my trips to the store have created a problem.
You see, every time I buy a vanilla ice-cream, when I start back from the
store my car won't start. If I get any other kind of ice cream, the car starts
just fine. I want you to know I'm serious about this question, no matter how
silly it sounds "What is there about a Pontiac that makes it not start when I
get vanilla ice cream, and easy to start whenever I get any other kind?"
Amr Talaat
Modeling: My Car Hates Vanilla Ice Cream

The Pontiac President was understandably skeptical about the letter,
but sent an Engineer to check it out anyway.

The Engineer did the following:
 Arranged to meet the man just after dinner time, so the two hopped
into the car and drove to the ice cream store. It was vanilla ice
cream that night and, sure enough, after they came back to the car,
it wouldn't start.

The Engineer returned for three more nights. (Give enough time
to know the system)

The first night, they got chocolate. The car started.
The second night, he got strawberry. The car started.

The third night he ordered vanilla. The car failed to start.

Amr Talaat
Modeling: My Car Hates Vanilla Ice Cream

Now the engineer, using logic, arranged to continue his visits for as
long as it took to solve the problem. And toward this end he began to
take notes: (Note All system Behavior)
 He
jotted down all sorts of data: time of day, type of
gas uses, time to drive back and forth etc.
 In a short time, he had a clue:




the man took less time to buy vanilla than any other flavor.
The answer was in the layout of the store.
Vanilla, being the most popular flavor, was in a separate case at the
front of the store for quick pickup.
All the other flavors were kept in the back of the store at a different
counter where it took considerably longer to check out the flavor.
We see the problem, as we MODEL it
Amr Talaat
From Requirements to the Design

Requirements analysis leads to a specification

Specification states which requirements should be fulfilled
 Modeling languages and tools are used to validate
specifications.
Formal notation and languages:


State machines (today)
 Unified Modeling Language (UML), e.g.






UML state charts
UML protocol state machines
UML sequence charts
UML use case diagrams
Specification and Description Language (SDL) [ITU-T Z.100]
Message Sequence Charts [ITU-T Z.120]
2
3
/
3
1
Amr Talaat
FSM Overview




Finite State Machine is a tool to model the desired behavior of a
sequential system.
The designer has to develop a finite state model of the system
behavior and then designs a circuit that implements this model
A FSM consists of several states. Inputs into the machine are
combined with the current state of the machine to determine the
new state or next state of the machine.
Depending on the state of the machine, outputs are generated
based on either the state or the state and inputs of the machine.
2
4
/
3
1
Amr Talaat
FSMs States
Current State: State which determines
the current behavior of the machine
 Next State: State which machine will have
after processing an input event. Next State
can be the same as current state
 Start State: State in which machine will be
when created (power on)
 End State: State in which no transition
rule is executable

2
5
/
3
1
Amr Talaat
Transitions
Triggered by input events the FSM moves
from one state to other based on the
Transition Function
 Transition Function produces the Output
and Next State depending on Current
State and Input Event
 While in particular state FSM is not active,
it is waiting for an input to perform next
activity

2
6
/
3
1
Amr Talaat
State Transition Diagrams


Used to visually represent an FSM
Emphasis is on identifying states and possible transitions
Transitio
 Circles represent States
ns
 Arrows represent Transitions
01/11
Initial
State
Input/Outp
ut
State
S0
S1
01/01
11/10
S3
1-/11
01/10
S2
011/00
/
3
1
Amr Talaat
Finite State Machines (FSMs)

Finite state machines consist of:
 States
 Input
Events (or Signals, or Messages)
 Transition Functions
 Output Events
States
Input
Events
Transition Functions
Output
Events
2
8
/
3
1
Amr Talaat
Kiss2 Format


STG and Tables are only ways to represent FSMs
Other techniques are available, Example: Keep it simple stupid
trails.kiss2
.i 2
.o 1
.p 11
.s 4
-0 st0
st0
11 st1
st3
……….
0
0
2
9
/
3
1
Amr Talaat
FSM Example
 General Machine Description:
 deliver package of gum after 15 cents deposited
 single coin slot for dimes, nickels
 no change
N
Coin
Sensor D
Reset
Clk
Vending
Machine
FSM
Open
Gum
Release
Mechanism
3
0
/
3
1
Amr Talaat
Vending Machine Example
Present
State
Reset
0¢
0¢
N
5¢
D
5¢
N
10¢
D
10¢
N, D
15¢
[open]
15¢
Inputs
D N
0
0
1
1
0
0
1
1
0
0
1
1
X
0
1
0
1
0
1
0
1
0
1
0
1
X
Next
State
Output
Open
0¢
5¢
10¢
X
5¢
10¢
15¢
X
10¢
15¢
15¢
X
15¢
0
0
0
X
0
0
0
X
0
0
0
X
1
3
1
/
3
1
Amr Talaat
Mealy FSM

Output is dependent on the inputs and the current state
transition condition 1
/output 1
state 2
state 1
transition condition 2
/output 2
X(t)
Q(t)
Y(t)
CLC2
f
X(t)
Q(t)
Registers
Bank 1
CLC1
g
Clock
Q(t+1) = Q+(t)
3
2
/
3
1
Amr Talaat
Moore FSM

Output is dependent only on the current state
transition
condition 1
state 1 /
output 1
transition
condition 2
state 2 /
output 2
X(t)
Q(t)
CLC1
g
Registers
Bank 1
Clock
Q(t+1) = Q+(t)
Q+(t) = g[(X(t), Q(t)]
CLC2
f
Y(t+1)
3
3
/
3
1
Amr Talaat
Moore vs. Mealy FSM




Moore and Mealy FSMs can be functionally equivalent
 Equivalent Mealy FSM can be derived from Moore FSM and vice
versa
Mealy FSM Has Richer Description and usually requires smaller
number of states
 Smaller circuit area
Mealy FSM computes Outputs as soon as Inputs change
 Mealy FSM responds one clock cycle sooner than equivalent
Moore FSM
Moore FSM has no combinational path between Inputs and
Outputs
 Moore FSM is more likely to have a shorter critical path
3
4
/
3
1
Amr Talaat
Mealy FSM - Example

Mealy FSM that Recognizes Sequence “10”
0/0
1/0
S0
1/0
S1
0/1
Meaning of states:
 S0: No elements of the sequence observed
 S1: “1” observed
3
5
/
3
1
Amr Talaat
Moore FSM - Example

Moore FSM that Recognizes Sequence
“10”0
1
0
S0 / 0
reset
1
S1 / 0
1
S2 / 1
0
Meaning of states:
 S0: No elements of the sequence observed
 S1: “1” observed
 S2: “0” observed
3
6
/
3
1
Amr Talaat
Formal definition

An FSM is a 6-tuple F<S, I, O, F, H, s0>








S is a set of all states {s0, s1, …, sl}
I is a set of inputs {i0, i1, …, im}
O is a set of outputs {o0, o1, …, on}
F is a next-state function (S x I → S)
H is an output function (S → O)
s0 is an initial state
Moore-type: Associates outputs with states (as given
above, H maps S → O)
Mealy-type: Associates outputs with transitions (H maps
S x I → O)
3
7
/
3
1
Amr Talaat
Categories of Finite State Machines

Complete FSM (CFSM)
 Completely specified
 Specification domain

finite state machine
is on the whole space
Partial FSM (PFSM)
 Partially specified finite state machine
 Specification domain is part of the whole

space
Implementations are usually modeled by CFSM,
while specifications could be CFSM or PFSM
3
8
/
3
1
Amr Talaat
Modeling of Complex Systems




Typical telecomm system is too complex to be represented with a
single FSM. As usually when dealing with complexity we should split
a complex problem into a number of smaller components
In this case we will have number of concurrent FSMs
communicating with each other. Communicating FSM can be
 In a single process (task, thread of control)
 In separate concurrent processes on same microprocessor
 On separate microprocessors communicating to each other
Depending on how FSMs are co-located, different methods of
communications are possible
The two communication mechanisms for concurrent processes can
be categorized into Message Passing and Shared Data
Amr Talaat
Models of communication
 Shared memory
Comp-1
memory
Comp-2
Variables accessible to several tasks.
Model is useful only for local systems.
Amr Talaat
Shared memory

Potential race conditions (inconsistent results possible)
 Critical sections = sections at which exclusive access to
resource r (e.g. shared memory) must be guaranteed.
process a {
..
P(S) //obtain lock
.. // critical sectio
n
V(S) //release lock
}
process b {
..
P(S) //obtain lock
.. // critical section
V(S) //release lock
}
This model may be supported by:
 mutual exclusion for critical sections
 cache coherency protocols
Race-free access to sh
ared memory protected
by S possible
Amr Talaat
Non-blocking/asynchronous message passing

Sender does not have to wait until
message has arrived; potential problem:
buffer overflow
…
send ()
…
…
receive ()
…
Amr Talaat
Blocking/synchronous message passing rendez-vous

Sender will wait until receiver has
received message
…
send ()
…
…
receive ()
…
Amr Talaat
Extended rendez-vous
Explicit acknowledge from receiver required. Receiver can
do checking before sending acknowledgement.
…
send ()
…
…
receive ()
…
ack
…
4
4
/
3
1
Amr Talaat
Asynchronous & Synchronous Communications


Two approaches to implement message passing
Synchronous Communication



The processes involved in communication are required to
participate at the point of communication simultaneously
If Process A attempts to send a message and Process B is not
ready to receive it, Process A must wait until Process B is ready
Asynchronous Communication


The processes involved in communication are not required to
participate at the point of communication simultaneously
If Process A attempts to send a message and Process B is not
ready to receive it, Process A sends it anyway
Amr Talaat
Asynchronous Communication
using FIFOs





Asynchronous communication requires use of buffers to store
messages
The protocol specification methods studied in this course will be
mostly based upon Asynchronous Communication
In most communicating systems, a FIFO (First In First Out)
discipline is enforced on sending and receiving messages
During a send event the message is appended to the end of the
queue while a receive event removes a message from the front
It is possible to modify the communications channel to provide
additional communication constructs such as priority signals
4
6
/
3
1
Amr Talaat
Clayton Tunnel (CFSM Example)
train in tunnel
Is Train Out?
Stop
Worker
A
Train 1
Worker B
tunnel is clear
tunnel is clear
4
7
/
3
1
Amr Talaat
Communicating FSMs Model





Protocol is described as a set of Communicating FSMs (CFSMs)
Each CFSM represents a component (or process) of the network
 In OSI term, a protocol entity, e.g. sender, receiver
Each process can be defined by a set of states
 The process waits in a state for an event to occur
 Messages are received as events by the receiving FSM
 When this input event occurs, it transfers to another state, and in
doing so can send out messages and performs other tasks
Each CFSM is represented by a directed labeled graph where
 Nodes represent states (conditions) of the process
 Edges represent transitions (events) of the process
This model is the model used by the ITU Specification and
Description Language (SDL)
4
8
/
3
1
Amr Talaat
Communicating FSMs Model
Sender
Receiver
01/01
S0
01/11
00/10
S1
process
Amr Talaat
Protocol 1: get the time from a stranger



Specification: Implement a protocol that obtains the
time from a stranger when needed
Constraints: you have to be polite: a stranger will not
respond unless you precede any question by a polite
exchange of “hi's”, and thank the stranger in the end
To Draw an FSM we need to Identify:



Types of messages
States for both sender and receiver
Transitions between these states
Amr Talaat
Example on timeline
Amr Talaat
client FSM for get_time()
Amr Talaat
client FSM for get_time()
Above (What
is time?)
State 1
- Hi
State 2
Idle
+ BYE
+ Hi
State 6
State 5
Thanks
Bye
+ 12:30
State 4
- What is
Time? State 3
Amr Talaat
Server FSM for give_time()
Amr Talaat
Server FSM for give_time()
+Hi
State 1
- Hi
State 2
Idle
+ What is
Time?
- BYE
+Thanks
Bye
State 5
State 4
- 12:30
State 3
Amr Talaat
System MSC
Amr Talaat
Example 2: Distributed Traffic Light

Specification:
We need to control the traffic lights at a four-way intersection
 Each direction is equipped with a traffic light and a detector for cars waiting;
this is controlled by a computer (Cl_n)
 The four clients are connected to a server (S)


Your task: Write a protocol to ensure that (i) when a car is waiting in
front of a light, it will eventually turn green, and (ii) at any given time,
only one light is green
Amr Talaat
Protocol 2: Server FSM for Intersection
Amr Talaat
Protocol 2: client FSM for intersection
Amr Talaat
Blocked Client
Amr Talaat
Client: No Blocking
Amr Talaat
Starvation
Amr Talaat
Server: No Blocking/No Starvation
Amr Talaat
Client No Blocking/No Starvation
Amr Talaat
Lessons




Protocols are hard to get right!
Combinatorial explosion of execution paths –
or: “so many things can happen!” How to be
sure it's ALWAYS right?
How to analyze what a protocol does?
Finite State Machines:
 Natural
“language” to specify and analyze
protocols
 Mathematical theory and software tools
 Check properties such as no deadlock, starvation,
etc.
Amr Talaat
FSMs - Summary




Discrete event processes and finite state machines
are key concepts in modeling the dynamic real-time
behavior of telecommunications protocols.
FSM consist of States (Initial, Current and New),
Input Events, Output Events, Transitions
In case when “state explosion” is an issue extended
FSM (EFSM) may be used so some states are
replaced by local variables
Complex Telecommunication Systems can be
modeled as number of communicating FSMs (CFSMs)
Concurrent Program