Cse 555 protocol engineering
This presentation is the property of its rightful owner.
Sponsored Links
1 / 41

CSE 555 Protocol Engineering PowerPoint PPT Presentation


  • 79 Views
  • Uploaded on
  • Presentation posted in: General

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

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.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)


Protocol structure

Protocol Structure


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

2-1-3


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

2-1-4


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…

2-1-5


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

2-1-6


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.

2-1-7


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

2-1-8


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

2-1-9


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

2-1-10


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

2-1-11


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

2-1-12


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}

2-1-13


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;};

2-1-14


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

2-1-15


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

2-1-16


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

2-1-17


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

2-1-18


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!

2-1-19


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

2-1-20


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

2-1-21


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)

2-1-22


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

2-1-23


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

2-1-24


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

2-1-25


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)

2-1-26


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

2-1-27


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)

2-1-28


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

2-1-29


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

2-1-30


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

2-1-31


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

2-1-32


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

2-1-33


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

2-1-34


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

2-1-35


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}

2-1-36


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

2-1-37


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

2-1-38


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

2-1-39


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

2-1-40


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!

2-1-41


  • Login