1 / 31

CSE 555 Protocol Engineering

CSE 555 Protocol Engineering. Dr. Mohammed H. Sqalli Computer Engineering Department King Fahd University of Petroleum & Minerals Credits: Dr. Abdul Waheed (KFUPM) Spring 2004 (Term 032). Protocol Design. Topics (Ch. 7). Service specification Assumptions about the channel

tamera
Download Presentation

CSE 555 Protocol Engineering

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 5-1-3

  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-1-4

  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 5-1-5

  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 5-1-6

  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 < 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 5-1-7

  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 5-1-8

  9. Assumptions About the Channel (Cont’d) • 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 5-1-9

  10. Assumptions About the Channel (Cont’d) • Error bursts: • We need to predict the probability that a given burst lasts at least n bit transmissions • Using Mandelbrot’s 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 5-1-10

  11. Assumptions About the Channel (Cont’d) • 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 Probability of a burst Depends on its length 5-1-11

  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 5-1-12

  13. Protocol Vocabulary (Cont’d) • 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 5-1-13

  14. Protocol Vocabulary (Cont’d) • 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 5-1-14

  15. Protocol Vocabulary (Cont’d) • 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 5-1-15

  16. Protocol Vocabulary (Cont’d) • 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 5-1-16

  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 5-1-17

  18. Message Format (Cont’d) • 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 h2=2, 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 5-1-18

  19. Message Format (Cont’d) • 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 < D < 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 data[376]; unsigned char checksum[2]; } message; 5-1-19

  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 5-1-20

  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 5-1-21

  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 5-1-22

  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 5-1-23

  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… 5-1-24

  25. Assumptions: User Behavior (Cont’d) • We model assumptions using following process: proctype userprc(bit n){ use_to_pres[n]!transfer; if :: pres_to_use[n]?accept  goto Done :: pres_to_use[n]?reject  goto Done :: use_to_pres[n]!abort  goto Aborted fi;Aborted: if :: pres_to_use[n]?accept  goto Done :: pres_to_use[n]?reject  goto Done fi;Done: skip} • Binary argument n identifies the user and the channels it accesses • Message transfer will carry a file descriptor • Not important for validation model 5-1-25

  26. Assumptions: Message Channels • Channels are defined globally, and represent communication between layers chan use_to_pres[2] = [QSZ] of { byte };chan pres_to_use[2] = [QSZ] of { byte };chan pres_to_ses[2] = [QSZ] of { byte };chan ses_to_pres[2] = [QSZ] of { byte, byte };chan ses_to_flow[2] = [QSZ] of { byte, byte };chan flow_to_ses[2] = [QSZ] of { byte, byte };chan dll_to_flow[2] = [QSZ] of { byte, byte };chan flow_to_dll[2] = [QSZ] of { byte, byte }; • Channels for synchronous communication between session layer and file server chan ses_to_fsrv[2] = [0] of { byte };chan fsrv_to_ses[2] = [0] of { byte }; 5-1-26

  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 5-1-27

  28. Assumptions: File Server Behavior (Cont’d) • A better way to model file server: proctype fserver (bit n){ do :: ses_to_fsrv[n]?create -> /* incoming */ if :: fsrv_to_ses[n] !reject :: fsrv_to_ses[n] !accept -> do :: ses_to_fsrv[n]?data :: ses_to_fsrv[n]?eof -> break :: ses_to_fsrv[n]?close -> break od fi :: ses_to_fsrv[n] ?open -> /* outgoing */ …} 5-1-28

  29. Assumptions: File Server Behavior (Cont’d) • Model for outgoing data: :: ses_to_fsrv[n]?open -> /* outgoing */if:: fsrv_to_ses[n]!reject:: fsrv_to_ses[n]!accept -> do :: fsrv_to_ses[n]!data :: fsrv_to_ses[n]!eof -> break :: ses_to_fsrv[n]?close -> break od fi 5-1-29

  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 5-1-30

  31. Assumptions: Data Link Behavior (Cont’d) Proctype data_link(){ byte type, seq; do :: flow_to_dll[0]?type,seq -> if :: dll_to_flow[1]!type,seq :: skip /* lose */ fi :: flow_to_dll[1]?type,seq -> if :: dll_to_flow[0]!type,seq :: skip /* lose */ fi od} 5-1-31

More Related