CSE555-Lec-1-1 by wanghonghx


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

Term 032                              1-1-2                        CSE555-Sqalli
Introduction to
Protocol Engineering
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

Term 032                        1-1-4                     CSE555-Sqalli
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
 Let’s consider one example

Term 032                          1-1-5                       CSE555-Sqalli
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 (Lamport’s 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

Term 032                                    1-1-6                               CSE555-Sqalli
Communication Protocols: Early
 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)
     Chappe’s 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 can’t 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

Term 032                            1-1-7                         CSE555-Sqalli
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

Term 032                          1-1-8                 CSE555-Sqalli
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

Term 032                          1-1-9                        CSE555-Sqalli
Example 1 (Cont’d)
 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.

Term 032                                  1-1-10                                CSE555-Sqalli
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 party’s line, then to
  the called party’s 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!).

Term 032                              1-1-11               CSE555-Sqalli
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

Term 032                         1-1-12                      CSE555-Sqalli
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

Term 032                              1-1-13                           CSE555-Sqalli
Master-Slave Protocols (Cont’d)
 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
     At all times, one data transmission entity would control:
            Connection management
            Data transfer
            Synchronization and recovery
     Example: IBM’s Bisync protocol

Term 032                              1-1-14                   CSE555-Sqalli
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

Term 032                             1-1-15                             CSE555-Sqalli
Lessons Learned by Early Protocol
 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

Term 032                         1-1-16                       CSE555-Sqalli
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”

Term 032                              1-1-17                             CSE555-Sqalli
Communication Architectures
 ISO established a subcommittee to develop an architecture that
  defines communication tasks (1977)
 Result was the Open System Interconnection (OSI) reference
     Provided common basis for development of standards for systems
     Layered architecture
 Layer n provides a service that can be used by the layer n+1
     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)

Term 032                          1-1-18                       CSE555-Sqalli
Data Transfer Through Protocol

Term 032          1-1-19         CSE555-Sqalli
      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

Application                                       Application protocol                                      Application

  TCP                                                   TCP protocol                                          TCP

   IP          IP protocol              IP              IP protocol               IP          IP protocol      IP

Network         Data         Netw ork        Netw ork       Data       Netw ork        Netw ork     Data    Network
Access          Link         Access          Access         Link       Access          Access       Link    Access

   Host                             Router                                    Router                          Host

      Term 032                                                     1-1-20                                      CSE555-Sqalli
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.

Term 032                          1-1-21                        CSE555-Sqalli
Formal Languages (Cont’d)
 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
 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*

Term 032                        1-1-22                      CSE555-Sqalli
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
     This is a difficult requirement to meet, in practice

Term 032                                   1-1-23                                CSE555-Sqalli
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
     Such differing implementations may not work together
     Example: many implementations of IBM’s 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

Term 032                          1-1-24                        CSE555-Sqalli
Protocol Standardization
 Two most important standardization bodies in the are of
     ISO and
     CCITT

Term 032                      1-1-25                   CSE555-Sqalli
International Standards Organization
 Included many national standards organizations, such as ANSI
 Organized into technical committees, each of which is divided
     Subcommittees and
     Working groups
 It is not a treaty organization
     Membership is voluntary
 Best known protocol recommendations: ASCII and RS232

Term 032                        1-1-26                 CSE555-Sqalli
 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

Term 032                       1-1-27                  CSE555-Sqalli
…But Design Problem Is Not Solved
 Standardization does not necessarily solve protocol design
     Standards could be incomplete
     They can even be faulty

Term 032                        1-1-28                  CSE555-Sqalli
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
                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

Term 032                                   1-1-29                                CSE555-Sqalli
Formal Description Techniques
 Three FDTs have been standardized:
     SDL
     LOTOS
     Estelle

Term 032                    1-1-30     CSE555-Sqalli
Specification and Description Language
 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

Term 032                         1-1-31                    CSE555-Sqalli
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
     Algebra defines:
            a rigorous set of transformations rules, and
            equivalence relations
     Allows a designer to reason formally about behaviors

Term 032                                1-1-32                  CSE555-Sqalli
 Being developed under another ISO subgroup
     Issued as international ISO standard in 1989
 Based on an extended finite state machine concept

Term 032                         1-1-33               CSE555-Sqalli
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

Term 032                        1-1-34                      CSE555-Sqalli
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/software/pv/
 Murphi
     Custom description language
     Available on Linux, Solaris, Irix, and HP-UX
     http://sprout.stanford.edu/dill/murphi.html

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

Term 032                          1-1-36                    CSE555-Sqalli
Model of A
Protocol in

Term 032      1-1-37   CSE555-Sqalli
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/verification/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/verification/MSS98.ps
 Bottleneck analysis of a Gigabit Network Interface Card
      Uses PROMELA
      http://netlib.bell-labs.com/netlib/spin/ws02/jin.pdf
 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/models/models.html

Term 032                                    1-1-38                          CSE555-Sqalli

To top