Cse 555 protocol engineering
1 / 41

CSE 555 Protocol Engineering - PowerPoint PPT Presentation

  • Uploaded on

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 Structure. Topics (Ch. 2—4). Elements of a protocol Service and environment

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'CSE 555 Protocol Engineering' - oro

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Cse 555 protocol engineering

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)

Topics ch 2 4
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


Protocol design modularity and structure
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


Services provided by a protocol an example
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…


Example cont d
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


Interaction agreements through protocols
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.


Role of protocol designer
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


Elements of a protocol specification
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


Protocol specification cont d
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


Protocol specification an example
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


Example cont d1
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


Example cont d2
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}


Example cont d3
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;};


Example cont d4
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


Example cont d5
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


Example cont d6
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


Example cont d7
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


Duplicate message problem
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!


Lesson learned from lynch s protocol
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


Service and environment
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


Service and environment an example
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)


Example cont d8
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


Iso standard for protocol hierarchy
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


Relative function of three layers
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


Some protocols at various layer levels
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)


Protocol layering a design principle
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


Protocol layering cont
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)


Protocol hierarchy and design discipline
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


Vocabulary and format
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


Bit oriented protocol format
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


Bit stuffing
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


Character oriented format
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


Character stuffing example
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


Byte count oriented format
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


Headers and trailers
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}


Protocol rules
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


Structured protocol design
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


Structured protocol design cont
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


Important failure modes of protocols
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


Ten rules of protocol design
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!