CSE 555 Protocol Engineering - PowerPoint PPT Presentation

About This Presentation
Title:

CSE 555 Protocol Engineering

Description:

Fire signals and torch telegraph (458 BC) ... Any train passing a green signal automatically sets that signal to red ... Marconi build first radio telegraph (1897) ... – PowerPoint PPT presentation

Number of Views:45
Avg rating:3.0/5.0
Slides: 39
Provided by: Sqa6
Category:

less

Transcript and Presenter's Notes

Title: 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
Course Objectives
  • This course covers the following topics
  • Overview of structured protocol design and
    testing techniques
  • Formulation of desirable properties of a protocol
  • Formal description techniques and languages
  • Protocol synthesis and validation
  • Conformance testing
  • Study of some protocol design and validation
    tools
  • What is expected from the students
  • Study all details of at least one protocol
  • Application of at least one analysis and testing
    tool/language to selected protocol for its
    modeling and validation

3
Introduction to Protocol Engineering
4
Topics (Ch. 1)
  • Motivation
  • Computer networks
  • Protocols as languages
  • Examples of some of the well-known protocols
  • Overview of structured protocol design and
    testing techniques

5
Motivation for Protocol Engineering
  • What is a protocol?
  • A set of rules for interactions among concurrent
    processes
  • Processes typically run on distributed systems
  • Protocol design spans a number of established
    fields
  • Operating systems computer networks data
    communication
  • Provides some standard solutions
  • Designing a logically consistent protocol that
    can be proven correct is a challenging task
  • Establishing validity of even a sequential
    program is hard
  • In distributed systems, we must reason about
    concurrently executed, interacting programs
  • Lets consider one example

6
Example Clock Synchronization Problem
  • Problem statement
  • Distributed systems have asynchronous clocks
  • Due to clock skew, a message may be received
    before it was sent
  • Observing concurrent events on a distributed
    system is non-trivial
  • Local clocks ensure that local events are
    observed in correct order
  • However, correct global event order may not be
    observed accurately
  • A send event has to happen before corresponding
    receive event
  • Global event order may not show this causal
    relationship due to clock skew
  • One solution (Lamports law)
  • Ensure sequential consistency of individual
    clocks (partial event order)
  • When two processes interact, ensure that receive
    occurs after send event (global event ordering)
  • An implementation Network Time Protocol (NTP)
  • Servers provide reference network time
  • All clients synchronize their clocks with respect
    to the reference clock
  • Synchronized time is accurate within a few msec
    range

7
Communication Protocols Early Beginnings
  • Problem of designing efficient and unambiguous
    communication protocols existed even before the
    advent of computers
  • Number of systems for communication over long
    distances
  • Fire signals and torch telegraph (458 BC)
  • Chappes semaphore/optical telegraph (Claude
    Chappe 1793)
  • Electric telegraph (William Cooke 1837)
  • Problems with early communication systems
  • Number of messages that can be communicated by
    fire signals is limited (and previously
    determined) - Unforeseen things cant be
    communicated
  • Synchronization problems
  • What happens if two messages arrive
    simultaneously to a semaphore from opposite
    directions (relay messages)?
  • Electric telegraphs could not prevent some
    railway crashes due to misunderstandings among
    signalmen
  • Common problem unexpected occurrences, which
    require immediate attention lead to protocol
    failures ? expect the unexpected

8
Incomplete Protocol Specifications
  • This is the primary problem that results in
    communication protocol failures
  • Examples
  • Example 1 A railway signaling protocol
  • Example 2 Deadly Embrace

9
Example 1 Railway Signaling Protocol
  • One of the first applications of electric
    telegraph was railway signaling to protect
    notoriously dangerous stretches of railroads
  • Single-track lines
  • Tunnels
  • Crashes did take place due to unexpected
    combination of events
  • Crashes are always investigated in minute details
  • Lots of information is available on early
    protocol design problems
  • Consider the example of Clayton Tunnel accident
    that occurred in England in August 1861

10
Example 1 (Contd)
  • Protocol
  • Using semaphore signals, signalmen on each end
    were required to make certain that a train that
    entered the tunnel had emerged from the other end
    before allowing next train into the tunnel
  • Any train passing a green signal automatically
    sets that signal to red
  • Separate tracks for trains moving in each
    direction
  • Small number of pre-defined messages can be
    exchanged among signalmen
  • (train in tunnel, tunnel is free)
  • Signalmen reset signal to green after tunnel is
    free
  • Unexpected sequence of events
  • First train passes signal A but fails to reset
    the green signal to red signalman A manually
    fetches the red flag and indicates to B that
    there is a train in the tunnel
  • Second train is too fast and passes green signal
    but the driver catches glimpse of red flag and
    stops the train inside the tunnel
  • A third train stops outside the tunnel
  • Signalman A indicates that a second train is also
    in the tunnel (protocol did not allow this
    situation) only message that signalman A could
    transmit was has the train left the tunnel?
  • Signalman B is not aware of the second train in
    tunnel responds when the first train leaves the
    tunnel that tunnel is clear
  • Signalman A decides that both trains must have
    left the tunnel. The third train is allowed to
    move on. The driver of the second train (who had
    seen the red flag) decides to play it safe and
    back out of the tunnel.
  • Both trains collided, 21 people died and 176
    injured.

11
Example 2 Deadly Embrace
  • A call requires exclusive access to at least 2
    shared resources in the telephone system
  • The line of the calling party
  • The line of the called party
  • Access is always first granted to the calling
    partys line, then to the called partys line
  • When two subscribers A and B simultaneously
    attempt to establish a connection to each other,
    the access rules will prevent this
  • If A and B repeatedly pick up the receiver
    simultaneously to dial the connection, they will
    repeatedly fail (until one fives up!).

12
Early Computer Communication Systems
  • Computer communication has its roots in
    modifications made to early telegraphs
  • Use of Morse signaling code instead of needle
    instruments (1851)
  • Elisha Gray and Alexander Graham Bell invent
    telephone (1876)
  • Marconi build first radio telegraph (1897)
  • Use of paper tape instead of manual operation to
    increase the transmission speeds
  • Complete telegraph exchange (telex) networks by
    1925
  • Automated communication protocol execution on
    mainframe computers (1950)
  • Demand for thoroughness of communication
    protocols increased
  • Early communication protocols
  • Master-slave protocols
  • Peer protocols

13
Master-Slave Protocols
  • ENIAC was the first computer built in 1946 at
    Univ. of Pennsylvania
  • Computer needed to communicate with peripheral
    devices, such as paper tape readers and keyboards
  • One large and expensive mainframe computer
  • Several dumb peripherals
  • Protocol
  • If no data to transfer to peripherals, mainframe
    would poll the peripherals to see if any of
    them had data to return or a status
  • All peripherals were within a room connected by
    multidrop lines

14
Master-Slave Protocols (Contd)
  • First experiments of long distance computer to
    computer communication over telephone lines took
    place in 1956
  • Fundamentally different types of control problems
  • Data transmission via a satellite (1962)
  • First data communication protocols
  • Simple encodings of manual operations
  • Procedures were used to solve traditional
    master-slave interaction problem
  • At all times, one data transmission entity would
    control
  • Connection management
  • Data transfer
  • Synchronization and recovery
  • Example IBMs Bisync protocol

15
Peer Protocols
  • By 1960s, mainframes were connected directly via
    data networks
  • Mainframes talking directly to each other as
    peers
  • Lack of any master-slave relationship (and
    related convenience)
  • Higher data speeds and larger traffic loads
  • Packet switching started with ARPANet in 1969
  • Internet is a successor of ARPANet
  • It grew from 25,000 nodes in 1987 to more than a
    billion nodes now
  • Protocol design problem
  • Establish agreement to use shared resources in a
    network of peers
  • If more than one process erroneously assumes
    responsibility of a task, havoc can result

16
Lessons Learned by Early Protocol Designers
  • Unlikely sequence of events do happen and can
    ruin the design
  • Faulty or incomplete protocols can paralyze
    entire networks
  • Collision of two data streams on a satellite
    channel may seem harmless compared to head-on
    collision of two trains
  • In reality, damage can be substantial in both
    cases

17
Protocol Design and Analysis
  • Fundamental design problem
  • How to design large sets of rules for information
    exchange that are
  • Minimal
  • Logically consistent
  • Complete
  • How to implement those rules efficiently
  • Two approaches
  • Given a problem, how can a designer solve it
    systematically so that design requirements are
    realized?
  • Given a protocol, how can an analyzer demonstrate
    convincingly that it conforms to the correctness
    requirements?
  • Design discipline
  • A set of self-imposed constraints that can help
    us avoid trouble
  • Every protocol should be considered incorrect
    until proven otherwise

18
Communication Architectures
  • ISO established a subcommittee to develop an
    architecture that defines communication tasks
    (1977)
  • Result was the Open System Interconnection (OSI)
    reference model
  • Provided common basis for development of
    standards for systems interconnection
  • Layered architecture
  • Layer n provides a service that can be used by
    the layer n1
  • Each layer performs specific functions that
    distinguish it from the other layers
  • Each layer can access services from the layer
    below it by accessing specific service access
    points (SAPs)

19
Data Transfer Through Protocol Hierarchies
20
Network Protocols
  • Specify any function that requires cooperation
    between two or more network entities
  • specify the format of the information that is
    sent/received among routers and end-systems
  • specify timings and the actions that a node has
    to take when it receives special messages or
    special events occur

21
Formal Languages
  • Components of a formal language
  • An alphabet
  • Strings and
  • Operations
  • An alphabet is a finite collection of symbols
  • Symbols in alphabet cannot be decomposed
  • Example symbols a, b, left, right,
    move_robot_arm, etc
  • A string (or word) is a finite sequence of zero
    or more symbols taken from an alphabet
  • A string containing no symbol is called an empty
    string
  • Some useful operations of strings
  • Examples length of a string, join of two
    strings, index of a symbol in a string, etc.

22
Formal Languages (Contd)
  • A formal language is any set of strings that can
    be formed using symbols of an alphabet
  • A language whose strings are formed from symbols
    in an alphabet A is said to be a language over A
  • The strings in a language are called the
    sentences of that language
  • The symbol A is used to represent all possible
    strings over the alphabet A. So any language L
    over A is a subset of A

23
Protocols as Languages
  • An informal definition of a communication
    protocol
  • An agreement for exchange of information in a
    distributed system
  • A more careful definition looks like a language
    definition
  • Defines a precise format of valid messages
    (syntax)
  • Example dots and dashes in Morse code
  • Defines procedure rules for data exchange
    (grammar)
  • Example transmission initiator and responder
    follow different procedures
  • Defines a vocabulary of valid messages that can
    be exchanged, with their meaning (semantics)
  • Example control messages, acknowledgements, etc.
  • Grammar of a protocol must be logically
    consistent and complete
  • Rules should specify clearly (unambiguously) what
    is allowed and what is forbidden
  • This is a difficult requirement to meet, in
    practice

24
Requirements of Designing a Protocol
  • Hidden requirement
  • Rules for exchange of information is an obvious
    requirement
  • There should be agreement between sender and
    receiver about those rules
  • Protocol design results in more than one
    implementation
  • Different implementations leave room for
    short-cuts or improvements
  • Such differing implementations may not work
    together
  • Example many implementations of IBMs Bisync
    protocol rule out any hopes of communicating
    among different implementations
  • Solution to multiple implementations
  • Institution of international standardization
    bodies
  • Other possibility could have been more strict
    guidelines for the design, specification, and
    implementation of protocols

25
Protocol Standardization
  • Two most important standardization bodies in the
    are of communication
  • ISO and
  • CCITT

26
International Standards Organization (ISO)
  • Included many national standards organizations,
    such as ANSI
  • Organized into technical committees, each of
    which is divided into
  • Subcommittees and
  • Working groups
  • It is not a treaty organization
  • Membership is voluntary
  • Best known protocol recommendations ASCII and
    RS232

27
CCITT
  • CCITT is part of the International
    Telecommunication Union
  • It is a treaty organization formed by UN in 1956
  • It is a union of two separate entities
  • CCIT (telegraph systems) and
  • CCIF (telephone systems)
  • Organized into study groups and working parties
  • Best know protocols recommended by CCITT X.21
    and X.25

28
But Design Problem Is Not Solved
  • Standardization does not necessarily solve
    protocol design problem
  • Standards could be incomplete
  • They can even be faulty

29
How Design Problem Can be Solved
  • We need effective methods for
  • Designing and describing protocols
  • Checking that a protocol submitted for
    standardization is correct
  • In other words, we need to be able to
  • Express a design criteria of a protocol
  • Examples (Holzmann 91)
  • Absence of any unwanted behaviors of a system,
    such as the infinite repetition of actions that
    do no meet a progress criterion defined by the
    user
  • Guaranteed observance of a specific
    functionality, e.g., within finite time after
    lifting the receiver the telephone subscriber
    must receive a dial-tone
  • Check that its design criteria are met
  • Protocol specification languages have been
    developed
  • Referred to as Formal Description Techniques
    (FDTs)
  • Used for specifying protocols for standardization

30
Formal Description Techniques
  • Three FDTs have been standardized
  • SDL
  • LOTOS
  • Estelle

31
Specification and Description Language (SDL)
  • SDL was developed by a CCITT study group
  • Work started in 1968
  • A final stable version was approved in 1987
  • Meant specifically for the specification and
    design of telecommunication systems, e.g.,
    telephone switches
  • Two variants of SDL
  • Graphical form
  • Program form

32
Language Of Temporal Ordering Specification
(LOTOS)
  • It is being developed within ISO
  • Issued as international standard in 1989
  • LOTOS is also called a process algebra
  • Based on the calculus of communicating systems
    (CCS) developed by Robin Milner at University of
    Edinburgh
  • Main goal of process algebra
  • Formal specification of process behaviors on a
    high level of abstraction
  • Algebra defines
  • a rigorous set of transformations rules, and
  • equivalence relations
  • Allows a designer to reason formally about
    behaviors

33
Estelle
  • Being developed under another ISO subgroup
  • Issued as international ISO standard in 1989
  • Based on an extended finite state machine concept

34
Limitations of FDTs
  • LOTOS is the only language that also addresses
    the design issues, in addition to specification
  • None of the FDTs addresses the problem that
    complete designs must be verifiable at the
    protocol specification level
  • We must be able to check with automated tools
    that a design meets its requirements
  • Verifiability is not guaranteed by any of the FDTs

35
Selected Model Checking Tools
  • Spin
  • Model checking tool where models are expressed in
    PROMELA (PROcess MEta LAnguage)
  • Available with source code on Windows and Unix
    platforms
  • http//spinroot.com/spin/whatispin.html
  • VeriSoft
  • Model checking tool where models are expressed in
    C/C
  • Available on Linux or Solaris platforms
  • http//cm.bell-labs.com/who/god/verisoft/
  • PV The Protocol Verifier
  • Model checking using PROMELA
  • Available on Linux or Solaris platforms
  • http//www.cs.utah.edu/formal_verification/softwar
    e/pv/
  • Murphi
  • Custom description language
  • Available on Linux, Solaris, Irix, and HP-UX
  • http//sprout.stanford.edu/dill/murphi.html

36
Application Example Flow Control
  • Go-back-N flow control protocol
  • Protocol translated into PROMELA specification
  • From informal description given in Computer
    Networks by Tanenbaum
  • Using Spin, its correctness properties can be
    proven in few minutes
  • Absence of deadlocks
  • No unreachable code
  • No unspecified receptions
  • Need to verify two properties
  • Message can be lost
  • No message arrives out of order

37
Example Model of A Sliding Window Protocol in
Spin
38
Applications of Verification Tools
  • Verification of part of SCI ("Scalable Coherent
    Interface"), IEEE Std 1596-1992.
  • Some bugs were discovered
  • http//sprout.stanford.edu/dill/PAPERS/verificatio
    n/SD95.ps
  • Verification of memory consistency models in
    shared memory multiprocessors
  • http//verify.stanford.edu/spark/sis.ps
  • Verification of SSL protocol
  • Finite state analysis
  • http//sprout.stanford.edu/dill/PAPERS/verificatio
    n/MSS98.ps
  • Bottleneck analysis of a Gigabit Network
    Interface Card
  • Uses PROMELA
  • http//netlib.bell-labs.com/netlib/spin/ws02/jin.p
    df
  • Verification Experiments on the MASCARA Protocol
  • Uses SDL
  • http//www-verimag.imag.fr/graf/PAPERS/GrafJia01.
    pdf
  • Database of PROMELA Models
  • http//www.informatik.uni-freiburg.de/lafuente/mo
    dels/models.html
Write a Comment
User Comments (0)
About PowerShow.com