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 Structure

3. Topics (Ch. 2—4) • Elements of a protocol • Service and environment • Vocabulary and format • Procedure rules • Structured protocol design • Error control techniques • Flow control techniques • A case study of Protocol Engineering 2-1-3

4. Protocol Design: Modularity and Structure • Need a set of rules for its proper use • How messages are encoded • How transmission is initiated • How it is terminated • Etc. • Two types of errors are hard to avoid: • Designing an incomplete set of rules • Designing rules that are contradictory • How to make a set of rules complete and consistent: • Requires precise specification of all relevant pieces of a protocol • Separate orthogonal issues using modularity and structure 2-1-4

5. Services Provided by a Protocol- An Example - • Example: file server and print server • A and B are two computers • A is connected to file server d and B is connected to a printer p • Requirement: send a text file from file stored at A to printer at B • What is needed for A and B to communicate: • Connected through same physical wires • Compatible character encoding • Same speed of transmitting and scanning signals • However, these are not the only issues… 2-1-5

6. Example (Cont’d) • Requirements for A and B to communicate: • A must be able to check whether the printer is available • A must be able to adapt its sending rate wrt printer speed • Transmission should be suspended when printer is out of paper or switched off • Agreement between A and B is needed for the control flow • Two-way channel instead of one way: • Data flows from A to B • Control information may flow from A to B or B to A • Prior agreement on meaning of control information and procedures used • How to start, suspend, resume, and conclude transmission • Prior agreement on how to handle errors • Positive or negative acknowledgements • Sender is notified whether data is received correctly or not • All rules, formats, and procedures agreed upon between A and B are collectively called a protocol 2-1-6

7. Interaction Agreements through Protocols • A protocol formalizes the interaction by standardizing the use of a communication channel • Protocol can contain agreements on methods used for: • Initiation and termination of data exchanges • Synchronization of senders and receivers • Detection and correction of transmission errors • Formatting and encoding data • These agreements can be defined at multiple levels of abstraction • Example: Format definition - Electrical signals, bits, symbols, messages, frames, packets, etc. 2-1-7

8. Role of Protocol Designer • Achieving synchronization at multiple levels of abstraction • Clock synchronization at lowest level of signals • Synchronization of rate/flow of messages at higher level • Coordination of main protocol phases at a still higher level • Format definition of protocol rules at different levels • Method for encoding bits with analog signals at lowest level • Methods for encoding characters into bit patterns at a level up • Grouping of character codes into message fields at a higher level • Grouping of message fields into frames or packets with specific meaning and structure at the highest level • Designer can devise error control based on properties of transmission medium • Medium may insert, delete, distort, duplicate, or reorder messages • Designer needs to devise an error control strategy depending on that • A reliable protocol design needs a formal and structured description of a protocol requirements and assumptions 2-1-8

9. Elements of a Protocol Specification • A complete protocol specification should explicitly include: • Service to be provided by the protocol • Assumptions about the environment • Vocabulary of messages used • Encoding (format) of each message • Procedure rules for consistency of message exchanges • Procedure rules are the most difficult to design and the hardest to verify • Main objective of this course on protocol engineering • Design and validation of unambiguous sets of procedure rules 2-1-9

10. Protocol Specification (Cont’d) • Each part of protocol specification can define a hierarchy of elements • Example: how higher-level messages are constructed from lower-level ones • Protocol specification = language definition • Protocol format = syntax and vocabulary • Procedure rules = grammar • Service specifications = semantics • Some special requirements to impose on this language: • Protocol language must be unambiguous • Protocol language must be able to express concurrency • Need to deal with concurrency related issues: timing, race conditions, and possible deadlocks • Need automatic techniques for analysis • Precise sequence of events is unpredictable • Many possible event orderings result in an overwhelming number of cases to be analyzed 2-1-10

11. Protocol Specification: An Example • Identification of basic building blocks in Lynch’s protocol (1968) • Taken from a manufacturer’s manual • Service specification: • Transfer of text files as sequences of characters across a telephone line • Protection against transmission errors • Assume all errors can be detected • Protocol is defined for full duplex file transfer • Positive and negative acks for traffic from A to B are sent on the channel from B to A, and vice versa • Every message contains two parts: • Message part • Control part: applies to the traffic on the reverse channel 2-1-11

12. Example (Cont’d) • Assumptions about the environment: • Environment: two users of the file transfer service and a transmission channel • Users can be assumed to submit a request for file transfer and wait for its completion • Transmission channel is assumed to cause arbitrary message distortions but it does not lose, duplicate, insert, or reorder messages • We assume that a lower-level module is used to catch all distortions and change them into undistorted messages of type err 2-1-12

13. Example (Cont’d) • Protocol vocabulary: • Three types of messages: • ack for a message combined with positive acknowledgement • nak for a message combined with negative acknowledgement • err for a message with a transmission error • Vocabulary can be expressed as a set: V = {ack, err, nak} 2-1-13

14. Example (Cont’d) • Message format • Each message consists of: • A data field with the character code • A control field identifying the message type • We assume that control and data fields are of fixed size • Symbolic representation of a message: • As a structure of two fields: {control tag, data} • In a C-like language: enum control {ack, nak, err};struct message { enum control tag; unsigned char data;}; 2-1-14

15. Example (Cont’d) • Procedure rules: • Informally described as: • “If the previous reception was error-free, the next message on the reverse channel will carry a positive acknowledgement; if the reception was in error it will carry a negative acknowledgement” • “If the previous reception carried a negative acknowledgement, or the previous reception was in error, retransmit the old message; otherwise fetch a new message for transmission” • To formalize these rules, we can use: • State transition diagrams • Flow charts • Algebraic expressions • Program-form descriptions 2-1-15

16. Example (Cont’d) • Specification of Lynch’s protocol using a flow chart • receive state symbolizes reception of a new message from channel awaited • Three execution paths depending on the type of message received (e.g., ack:i [i: input]) • Incoming data is temporarily stored in variable i • next:o internal retrieval of data item o from internal database [o: output] • ack:o  transmission of data item o with an ack of the last received message • This description is not free of design flaws 2-1-16

17. Example (Cont’d) • Design flaws: • Data transfer in one direction continues only if data transfer in the other direction takes place • Processes can use filler messages when no real data are to be transferred • How data transmission can be initiated or concluded as the protocol does not specify procedure rules for setup and termination • We can use fake error messages to initiate communication • If both sides are allowed to initiate, it may be hard to synchronize both sides • Termination will also require extra control messages • What to do with correctly received duplicates of previously received messages • This problem has no solution if the two procedure rules are to be maintained Consider an execution sequence to understand the problem due to duplicate messages 2-1-17

18. Example (Cont’d) • What happens if every correctly received message is accepted: • Data with ack or nak messaged is accepted • Data with err message is not • Consider this sequence: • A sends a deliberate err to B (Initiation) • A attempts to transmit “a….z” • B sends nak and data (‘z’) to A • B responds with “z….a” • A accepts data (‘z’) sent by B • A sends positive ack and data (‘a’) to B • Message gets distorted • B resends nak and data (‘z’) to A • Message also gets distorted • A resends data (‘a’) with nak to B • B accepts (‘a’) and sends ack with data (‘z’) • A accepts (‘z’) and sends ack with data (‘b’) • Problem: A has erroneously accepted ‘z’ twice 2-1-18

19. Duplicate Message Problem • If we accept all correctly transmitted messages, we cannot tell whether a message is new or duplicate • Error is hard to discover even for simple Lynch’s protocol • Error occurs only in rare event that two transmission errors occur in sequence • Error may never occur during testing phase after protocol has been designed • An inadequate scheme may work almost all the time! 2-1-19

20. Lesson Learned from Lynch’s Protocol • Simple does not imply correct • Protocol is simple • Informal specification looks convincing that protocol should work correctly • However, specification is incomplete • Subtle errors can occur during data exchange • Careful design process is inevitable even for simplest of protocols • A good design discipline • Effective analytical tools 2-1-20

21. Service and Environment • To accomplish a higher-level service (e.g., file transfer) , protocol must perform a range of lower-level functions: • Synchronization • Error recovery, etc. • Realization of a service depends on assumptions made about the environment (e.g., Error recovery should correct for the assumed behavior of the transmission medium) • Layered structure • Breaks up large problem to more manageable sub-problems • More abstract functions are defined and implemented in terms of lower-level constructs • Each layer hides undesirable properties of the communication channel and transforms it to an idealized medium • Example: a data transmission protocol • Each character is encoded into 7 bits • An error detection scheme e.g., a parity bit appended to each 7 bit symbol • Assume full-duplex transmission • Protocol services: encoding and error detection • Implementation using two sub-modules: an encoder/decoder module and a parity encoder/checker module 2-1-21

22. Service and Environment: An Example • Two-layer end-to-end service • Layer 1: parity encoder/checker module (P1 protocol implementation) • Layer 2: encoder/decoder module (P2 protocol implementation) • Data formats: • P1 protocol: 8-bit byte • P2 protocol: 7-bit byte • P1 protocol provides a virtual channel for P2 protocol • P1 is transparent to P2 • P2 does not know about the 8th bit added by P1 • P1 provides a more reliable channel to P2 (than raw channel) 2-1-22

23. Example (Cont’d) • There may be other higher or lower layers • A layer does not know the format imposed by a higher layer • Data can even be divided up differently at a lower layer in larger or smaller portions as long as it can be retrieved in original format by the receiving protocol module • Advantages of a layered protocol design: • Provides a logical structure by separating higher-level tasks from lower-level details • Easier extensibility • Extend or replace a module rather than re-write the entire protocol 2-1-23

24. ISO Standard for Protocol Hierarchy • International Standards Organization (ISO) standardized a hierarchy of protocol services in 1980 • This is a reference model for protocol designers • ISO reference model for Open System Interconnection (OSI) recommended and defined 7 layers • Each layer defines a distinct service 2-1-24

25. Relative Function of Three Layers • Data link layer uses services provided by physical layer • Transforms a raw data link into a reliable one by adding error handling • It connects two nodes and does not deal with end-to-end communication (hop-by-hop) • May provide services such as hop-by-hop flow control • Network layer cares about addressing and routing functions • Potentially spans multiple data links • End-to-end protocol • Transport protocol connects user level processes, p and q • May provide services such as end-to-end flow control 2-1-25

26. Some Protocols at Various Layer Levels • CCITT standardized a layer 1 protocol as Recommendation X.21 • Second layer is defined by high level data link control (HDLC) • First three layers of OSI model are defined in CCITT Recommendation X.25 • It does not deal with computer to computer interaction, which is part of transport layer • Computer to computer interaction uses transmission control protocol (TCP) • Standardized by US Department of Defense • Corresponding network layer protocol is internet protocol (IP) 2-1-26

27. Protocol Layering: A Design Principle • A layer defines a level of abstraction in the protocol that: • groups closely related functions • separates orthogonal functions from each other • makes it possible to change one layer without affecting the design of other layers • An interface separates distinct levels of abstraction • A correctly placed interface is small and well defined 2-1-27

28. Protocol Layering (Cont.) • Protocols on Nth layer form peer entities • Vertical boundary between two layers is called an interface • Horizontal boundary between two entities is called a peer protocol • Only peer protocols need to be standardized • Local implementation details of layer interfaces can easily be hidden from the environment • Interface between two adjacent layers is defined as a collection of service access points (SAPs) 2-1-28

29. Protocol Hierarchy and Design Discipline • For a given protocol layer: • Service is provided to the upper layer protocols (or user at top layer) • Assumptions made are about services provided by the lower layer protocols • Design issues are: • separated from one another, and • solved independently • Examples: • Error control • Error recovery • Addressing and routing • Flow control • Data encryption 2-1-29

30. Vocabulary and Format • Formatting methods should be defined at fairly low level of abstraction • They should be capable of describing higher-level message formats • Three main formatting methods: • Bit oriented • Character oriented • Byte-count oriented 2-1-30

31. Bit Oriented Protocol Format • A bit oriented protocol transmits data as a stream of bits • Message boundaries indicated by flags • These are special bit patterns • These patterns can be part of user data • Correct interpretation of a “flag” in a bit stream is crucial • Example: • A framing flag is defined as a series of six 1’s enclosed by two zeros as 01111110 • User data may also have a series of six ones • User data can be interpreted correctly by inserting an extra zero after every series of 5 ones • Receiver inspects the first bit after detecting a series of 5 ones; if it is a zero it is deleted; otherwise continues to recognize delimiter (i.e., flag) • Above technique is known as bit stuffing 2-1-31

32. Bit Stuffing • Receiver can correctly detect the structure enforced by the flags • Bit stuffing technique is used in ISO’s layer 2 protocol (HDLC) • HDLC is based on IBM’s synchronous data link control protocol (SDLC) • Using this basic low-level flag structure, it is possible to support higher-level structures 2-1-32

33. Character Oriented Format • Character oriented protocols enforce some minimal structure on the bit stream • If number of bits per character is fixed at n, all communication takes place as multiples of n • Usually, n is 7 or 8 bits • User and control data is encoded through these data units • Examples of control codes • ASCII start of text (STX) and end of text (ETX) messages that can serve as delimiters to enclose user data • What if these control characters occur in user data? • Use character stuffing technique 2-1-33

34. Character Stuffing: Example • Example: IBM’s Bisync Protocol • If control characters (such as, STX or ETX) happen to occur within user data, they are preceded by an extra code called data link escape (DLE) character • Delimiters will not be preceded with the escape sequence • Receiver deletes the first DLE code that it sees in the character stream 2-1-34

35. Byte-Count Oriented Format • Byte-count can be used instead of a precise delimiter flag or character • Example: • In a known place after the STX control message, the sender includes the precise number of bytes (i.e., characters) that the message contains • An ETX message is not needed • Bit stuffing or character stuffing techniques are not needed • Most currently used protocols are of this type 2-1-35

36. Headers and Trailers • Basic structuring methods can be used to build more systematic higher-level data formatting methods • So far, we have assumed an absence of transmission errors • Byte-count field may be distorted • DLE character may get lost • Bit, character, or count oriented techniques will fail with errors • Error detection and recovery are needed for formatting to work • Error detection requires transmission of redundant information • Example: checksum • Other information: message type, sequence number (if flow control is used), sender ID, priority, etc. • A separate structure to hold this redundant information encapsulates the user data: header and trailer • Byte-counts are typically placed in headers while checksums in trailers • Message format may be defined as an ordered set of 3 elements: • format = {header, data, trailer} • header = {type, destination, sequence number, count} • Type identifies the messages that make up the protocol vocabulary • trailer = {checksum, return address} 2-1-36

37. Protocol Rules • Procedure rules distinguish protocol design from normal software development • Procedure rules are interpreted concurrently by a number of interacting processes • Impact of adding a new rule to the set is often underestimated resulting in unforeseeable consequences • Behavior of a protocol is not reproducible due to concurrency • Most popular tool for reasoning about protocols: time sequence diagram • Inadequate for reasoning about the working of a protocol in general • We need to be able to express behavior unambiguously in a formal notation • Transition tables or finite state machines can be used for this purpose • We need to be able to express arbitrary correctness requirements on the specified behaviors • No general methodology guarantees the design of unambiguous rules • Tools exist for the verification of the logical consistency of rules and the observance of correctness requirements • Use common sense and good practice to keep rules manageable 2-1-37

38. Structured Protocol Design • Beware of the “gray area” of protocol design • Issues at lower (physical) layer are well understood • High-level “network view” is concerned with the problems of designing network, routing, congestion control, and flow control • Between these two views, is the unknown protocol design territory that requires: • Devising unambiguous, consistent and complete set of rules for the description of protocols (i.e., exchange of information in a distributed system) • Design discipline: tools to use, rules to follow, and mistakes to avoid 2-1-38

39. Structured Protocol Design (Cont.) • General set of principles of sound protocol design: • Simplicity: light-weight protocols • a well structured protocol is built from a small number of well-designed and well-understood pieces • Modularity: a hierarchy of functions • smaller pieces that interact in well-defined and simple way • Orthogonal functions are designed as independent entities unaware of each other (e.g., error control and flow control) • Protocol structure is open, extendible, and rearrangeable • Well-formed protocols: • Neither over-specified nor under-specified • Bounded, self-stabilizing, and self-adapting • Robustness against “unexpected events” • Protocol can deal with every possible sequence of actions under all possible conditions • Minimal design that removes non-essential assumptions (easier to adapt) • Consistency • Observation of these criteria cannot be verified manually • Tools are needed to prevent and detect errors 2-1-39

40. Important Failure Modes of Protocols • Deadlocks • Characterized by states in which no further protocol execution is possible • This is because all protocol processes are waiting for conditions that can never be fulfilled • Livelocks • Execution sequences that can be repeated indefinitely often without ever making effective progress • Improper terminations • Characterized by the completion of a protocol execution without satisfying the proper termination conditions 2-1-40

41. Ten Rules of Protocol Design • Problem should be well-defined • Define services to be performed at every level of abstraction (What) • Define external functionality before internal • Keep it simple – less bugs and easier to implement and verify (break down complex problems into simpler ones) • Do not connect what is independent (i.e., orthogonal functions) • Keep design extendible – It solves a class (not instance) of problems • Build a high-level prototype and verify design criteria before full implementation • Implement design, measure performance, and optimize • Check that optimized implementation is equivalent to the high-level design that was verified • Don’t skip rules 1—7 • This is most frequently violated rule! 2-1-41