CSE 555 Protocol Engineering

1
CSE 555Protocol Engineering

• Dr. Mohammed H. Sqalli
• Computer Engineering Department
• King Fahd University of Petroleum Minerals
• Credits Dr. Abdul Waheed (KFUPM)
• Spring 2004 (Term 032)

2
Protocol Design
3
Topics (Ch. 7)

• Service specification
• Assumptions about the channel
• Protocol vocabulary
• Message format
• Procedure rules
• We use an example protocol as a running case
  study to explain the above protocol design steps

4
Protocol Design

• So far, we have focused on
• Protocol specification
• Validation against a set of standard correctness
  problems
• How can we apply this knowledge to a real design
  problem?
• Use an example for a file transfer protocol
• Use systematic protocol specification
• Procedure rules with explicit correctness
  criteria
• Important design rule
• Before implementing, build a high level prototype
• A validation model is going to be our prototype
• Verify that the design criteria are met

5
Main Focus

• We make two crucial assumptions about the design
  process
• Protocol design is an iterative process
• Each time a design phase is completed, we, the
  designers, will be convinced that it is
  error-free
• Our concern is design and correctness
• Important to keep in mind that we are building a
  validation model, not an implementation
• The model is an abstraction, and as such it is a
  design tool in itself

6
File Transfer Protocol

• One sender and one receiver
• It is a point-to-point protocol
• Protocols with multiple receivers are called
  multi-point or broadcast protocols
• Provides end-to-end service
• Two users on two different machines
• Communicating through possibly many intermediate
  machines
• Procedure rules
• Will be specified through validation models
• Models can be checked on their correctness
  properties individually or in combination
• Models can be refined and adjusted with the help
  of verification tools
• Other protocol specifications
• Service specifications
• Assumptions about environment (i.e., transmission
  channel)
• Protocol vocabulary
• Message format

7
Service Specifications

• Reliable end-to-end file transfer service is
  needed
• Connection establishment
• Connection termination
• Recovery from transmission errors
• Flow control strategy (to prevent overflowing the
  receiver)
• Transmission characteristics of the protocol
• Must be able to transfer ASCII text files
• One at a time
• Probability of undetected bit error lt 1 in 108
  bits transmitted
• User should be able to abort a file transfer in
  progress
• Protocol should be able to recover from message
  loss

8
Assumptions About the Channel

• Full-duplex channel using a voice-grade switched
  telephone line
• Dedicated line does not require routing,
  congestion control, etc.
• This assumption allows us to focus on concurrency
  control
• Assume that transfers take place over a distance
  of 4500 Km
• Propagation time of a signal in a cable 30,000
  Km/sec
• Minimum time for a message to propagate 0.15
  sec
• Signaling speed 1200 bps (using a standard
  modem)
• Assume that transmission is character-oriented
• Using ASCII character encoding
• Error characteristics of the channel
• Most errors are caused by
• Noise spikes
• Echoes
• Cross-talk

9
Assumptions About the Channel (Contd)

• Bit error rates are not uniformly distributed
• Errors occur in bursts
• Assuming Poisson distribution of errors, the
  error-free interval (EFI) is given as
• where 1/f is the average duration of the
  error-free interval
• We use f 8x10-6, which corresponds to
• An average error-free interval of 125,000 bit
  transmissions or
• An EFI of about 100 sec

10
Assumptions About the Channel (Contd)

• Error bursts
• We need to predict the probability that a given
  burst lasts at least n bit transmissions
• Using Mandelbrots function
• where a and g are parameters
• Precise values of these parameters should be
  derived from measurements on the telephone
  channel used
• Values determine the type of error control method
  to be used
• We assume a 0.9 and g 0.009

11
Assumptions About the Channel (Contd)
Probability of a burst Depends on its length

• Average duration of burst error
• 12 bit transmission time
• About 10 msec
• At error rate of no more than 1 in 108
  transmitted bits, at 1200 bps
• Expected EFI 23 hours

12
Protocol Vocabulary

• Protocol environment
• A data link to communicate with the remote system
• Internal message channels to communicate with
• Local user and
• Local file server

13
Protocol Vocabulary (Contd)

• Four phases of a file transfer, in a specific
  order
• Connection establishment with local file server
• Connection establishment with remote system
• Data transfer
• Orderly termination of the connection
• Types of messages from local user
• Initiation of file transfer transfer
  (file_descriptor)
• Must trigger a message (i.e., open) to the local
  file server to verify that the file exists and
  finds out its size
• Message from user to interrupt a transfer abort

14
Protocol Vocabulary (Contd)

• Types of message to/from the local file server
• A message to the local file server to verify that
  the file exists and get its size open
  (file_descriptor)
• An incoming connect, at remote side, triggers a
  message to file server to verify that the file
  with the given size an be storedcreate(size)
• File server response accept(size) returns the
  file size to the calling process or
  reject(status) returns a parameter indicating
  the reason
• To transfer count bytes of data from buffer ptr
  data(count, ptr)
• End of file eof

15
Protocol Vocabulary (Contd)

• Type of messages to/from remote system
• connect (size) If file can be opened, its size
  is determined, and a connection request is made
  from the local to the remote system
• Accept
• Reject
• Data
• Ack used to implement a simple flow control
  discipline that acknowledges correctly received
  data
• Sync for flow control layers to agree on initial
  seq s
• Sync_ack acknowledgement of the above
• Eof
• Close Confirms correct completion of a file
  transfer, with the eof message

16
Protocol Vocabulary (Contd)

• Assume synchronous local communication
• Use rendezvous communication between local system
  and local file server
• Six messages open, create, accept, reject,
  data, and eof
• Equivalent to local procedure calls
• Guarantees that unused data messages to/from the
  file server do not accumulate
• Data transfer
• Requires successful local open and remote create
  requests
• Use data messages to transfer data from local
  file server to remote file server using the
  protocol to be developed

17
Message Format

• Minimal message format requirements
• A type field
• An optional data field
• A sequence number to implement flow control
• A checksum field to implement error control
• Each message can be formatted as a sequence of
  bytes
• Byte oriented channel
• At the highest level, a message is encoded into a
  series of bytes
• Message length will vary depending on h1, h2, D,
  and t1
• The lowest level (physical layer) inserts
  delimiters using ASCII 8-bit patterns
• Start of text STX
• End of text ETX
• Uses byte stuffing

18
Message Format (Contd)

• Message type field
• We have 13 different types of messages
• Need 4 bits to represent them
• h1 4
• Sequence number field
• Message propagation time 0.15 sec ? 180 bits
• Time until ack arrives with no delays 0.3 sec ?
  360 bits
• So, 360 bits long message can be transmitted
  without any delay to receiver before receiving
  the acknowledgement
• Value of h2 depends on
• Round-trip propagation delay and
• Number of bytes in header, trailer, and data
  field
• Example Selective repeat continuous ARQ method ?
  2(h2-1) outstanding messages with a sequence
  number field of h2 bits. If h22, 2 messages may
  be outstanding ? sender can transmit one message
  while awaiting ack for another. If message is at
  least 360 bits long, no time is lost

19
Message Format (Contd)

• The data field
• It can have variable length
• Too long data field ? probability of errors
  increases with bits
• Average EFI was estimated at 125,000 bits
• Too small data field ? overhead due to header and
  trailer is large
• Minimum size of message that is transmitted
  without any delay 360 bits
• Optimal data length 45 lt D lt 15625 ? Doptimal
  376 bytes
• Checksum field
• Error rate is low ? no need for an error
  correcting code
• For message length well below 125Kbits, most
  messages get through without transmission errors
• Needs to catch burst errors.
• Depends on the length of the burst (in this case
  12bits) and target residual bit-error rate (in
  this case 10-8)
• Choosing 16-bit checksum ? t1 16
• Summary
• struct
• unsigned type 4
• unsigned seqno 2
• unsigned char data376
• unsigned char checksum2

20
Procedure Rules

• Need complete and consistent rules
• To be verified before implementation
• We can use PROMELA model to design and debug
  rules
• PROMELA was designed for this purpose
• Issues
• How to abstract messages
• Protocol layering and global structure
• Refine all the layers to combine into final design

21
Abstraction for Messages

• Level of representation
• We need a model and not an implementation
• We can abstract out unnecessary details
• Consider only the semantics of the protocol, not
  its precise syntax
• Many details are irrelevant for validation model
• Low level data encoding details
• Contents of transferred files
• Variable length of Data field
• Use of checksum field
• We can represent a message using only two fields
• A message type and
• A sequence number
• Both fields can be of type byte

22
Layers

• Protocol design is structured into three layers
• Presentation layer
• User interacts with this layer
• Session control layer
• Interacts with the file server
• Data link layer
• Enforces general flow control discipline
• It is physical data line with modems and
  responsible for encoding and error detection
  using checksum
• Data link can lose but not distort the messages
• Each layer is represented as a PROMELA process

23
Assumptions About Protocol Environment

• We now need to formalize all assumptions about
  the environment
• The environment consists of three entities
• User process
• File server
• Data link
• Assumptions about environment can be formalized
  in PROMELA
• User behavior
• Message channels
• File server behavior
• Data link behavior

24
Assumptions User Behavior

• We can consider two user level processes
• One at each end of the data link
• User interactions
• Submits a transfer request at any time to
  presentation layer
• Passes file descriptor to the presentation layer
• May decide to abort a transfer at any time
• Protocol response
• Successful or unsuccessful transfer
• Lower layers pass this response to the user
• Assumption
• After submitting a command user waits for the
  response
• We model this behavior with following PROMELA
  code

25
Assumptions User Behavior (Contd)

• We model assumptions using following process
• proctype userprc(bit n) use_to_presn!transfer
  if pres_to_usen?accept ? goto Done
  pres_to_usen?reject ? goto Done
  use_to_presn!abort ? goto Aborted fiAborted
  if pres_to_usen?accept ? goto Done
  pres_to_usen?reject ? goto Done fiDone skip
  
• Binary argument n identifies the user and the
  channels it accesses
• Message transfer will carry a file descriptor
• Not important for validation model

26
Assumptions Message Channels

• Channels are defined globally, and represent
  communication between layers
• chan use_to_pres2 QSZ of byte chan
  pres_to_use2 QSZ of byte chan
  pres_to_ses2 QSZ of byte chan
  ses_to_pres2 QSZ of byte, byte chan
  ses_to_flow2 QSZ of byte, byte chan
  flow_to_ses2 QSZ of byte, byte chan
  dll_to_flow2 QSZ of byte, byte chan
  flow_to_dll2 QSZ of byte, byte
• Channels for synchronous communication between
  session layer and file server
• chan ses_to_fsrv2 0 of byte chan
  fsrv_to_ses2 0 of byte

27
Assumptions File Server Behavior

• We can eliminate unnecessary details
• Parameters, such as fd, size, cnt, and ptr do not
  contribute to validation process
• Specify how these two modules interact (file
  server and session layer)
• Important to specify when data is passed rather
  than which data is passed

28
Assumptions File Server Behavior (Contd)

• A better way to model file server
• proctype fserver (bit n) do
  ses_to_fsrvn?create -gt / incoming / if
  fsrv_to_sesn !reject fsrv_to_sesn !accept
  -gt do ses_to_fsrvn?data
  ses_to_fsrvn?eof -gt break
  ses_to_fsrvn?close -gt break od fi
  ses_to_fsrvn ?open -gt / outgoing /

29
Assumptions File Server Behavior (Contd)

• Model for outgoing data
• ses_to_fsrvn?open -gt / outgoing /if
  fsrv_to_sesn!reject fsrv_to_sesn!accept
  -gt do
• fsrv_to_sesn!data fsrv_to_sesn!eof
  -gt break ses_to_fsrvn?close -gt
  break od fi

30
Assumptions Data Link Behavior

• Data link is assumed to be protected by an error
  detection protocol
• It is a calculation and does not involve any
  interaction
• Calculation of checksum is not important for
  validation model
• It is not modeled in PROMELA
• The interest is in the external behavior of the
  data link
• Data link can lose an arbitrarily selected
  message
• This loss is non-deterministic
• Modeled by the following PROMELA process

31
Assumptions Data Link Behavior (Contd)

• Proctype data_link() byte type, seq do
  flow_to_dll0?type,seq -gt if
  dll_to_flow1!type,seq skip / lose
  / fi flow_to_dll1?type,seq -gt if
  dll_to_flow0!type,seq skip / lose
  / fi od