Network Protocols

1. NETW 703 Network Protocols Introduction Dr. Eng. Amr T. Abdel-Hamid Winter 2011

2. Administrative Details • Instructor: Dr. Eng. Amr T. Abdel-Hamid • Office: C3-320 • Email:amr.talaat@guc.edu.eg • TA: Mohamed ElShaer • Time: • Lecture: Thursday, 4th Slot at H1 2/38

3. Administrative Details (CONT.) • Text Book: • Design and Validation of Computer Protocols, by Gerard J. Holzmann. http://spinroot.com/spin/Doc/Book91.html http://cm.bell-labs.com/cm/cs/who/gerard/index.html • References: • Alberto Leon-Garcia, Indra Widjaja: Communication Networks: Fundamental Concepts and Key Architectures (2nd edition), Publisher: McGraw-Hill College, ISBN: 007246352. • S. Tanenbaum Computer Networks, Pearson Education, Inc., 2003, ISBN 0-13-038488-7. • Data communications, Computer Networks and Open Systems, by F. Halsall, published by Addison Wesley, 1999. 3/38

4. Communications Protocol • A protocol is a rule which guides how an activity should be performed, especially in the field of diplomacy. • In computing, a protocol is a convention or standard that controls or enables the connection, communication, and data transfer between two computing endpoints. • Usually we do not consider protocols individually • We use a stack (or suite) of protocols • TCP/IP, GSM, etc 4/38

5. History of Protocols • Fire Messages • Torch Telegram 1 0 5/38

6. History of Protocols • G. Huth “telephone” • C. Chappe “semaphore” • W. Cooke “NeedleTelegram” • Morse Code 6/38

7. Clayton Tunnel Is Train out train in tunnel Stop Worker A Train 1 Worker B train in Clear train in Clear 7/38

8. Clayton Tunnel (2) train in tunnel train in tunnel Is Train Out? Stop Worker A Is Train Out? 21 died and 176 were injured. Train 3 Train 2 Train 1 Worker B tunnel is clear tunnel is clear tunnel is clear 8/38

9. Quiz 0 • Write down 5 changes in the protocol that would have prevented the tragic accident?!! • How do we know that there will not be any other accidents? 9/38

10. THE FIVE ELEMENTS OF A PROTOCOL • A protocol specification consists of five distinct parts: • The serviceto be provided by the protocol • The assumptionsabout the environment in which the protocol is executed • The vocabularyof messages used to implement the protocol • The encoding(format) of each message in the vocabulary • The procedure rulesguarding the consistency of message exchanges 10/38

11. Protocol Examples • Service: The purpose of the protocol is to transfer text files as sequences of characters across a telephone line while protecting against transmission errors. • Assuming that all transmission errors can in fact be detected. The protocol is defined for full-duplex file transfer, that is, it should allow for transfers in two directions simultaneously. Positive and negative acknowledgments for traffic from A to B are sent on the channel from B to A, and vice versa. Every message contains two parts: a message part, and a control part that applies to traffic on the reverse channel. 11/38

12. ASSUMPTIONS • The ‘‘environment’’ in which the protocol is to be executed consists minimally of two users of the file transfer service and a transmission channel. • The users can be assumed to simply submit a request for file transfer and await its completion. • The transmission channel is assumed to cause arbitrary message distortions, but not to lose, duplicate, insert, or reorder messages. • We will assume here that a lower-level module is used to catch all distortions and change them into undistorted messages of type err. 12/38

13. PROTOCOL VOCABULARY • The protocol vocabulary defines three distinct types of messages: • ack for a message combined with a positive acknowledgment, • nak for a message combined with a negative acknowledgment, • err for a message with a transmission error. • The vocabulary can be succinctly expressed as a set: V = { ack, err, nak } 13/38

14. MESSAGE FORMAT (SIGNALING) • Each message consists of a control field identifying the message type and a data field with the character code. • The general form of each message can now be represented symbolically as a simple structure of two fields: {tag, data } • which in a C-like specification may be specified in more detail as follows: enum control { ack, nak, err }; struct message { enum control tag; unsigned char data; }; • The message structure itself contains two fields: a tag of type control, and a data field declared as an unsigned character (one byte). 14/38

15. PROCEDURE RULES • The procedure rules for the protocol were informally described as follows: • ‘‘If the previous reception was error-free, the next message on the reverse channel will carry a positive acknowledgment; if the reception was in error it will carry a negative acknowledgment.’’ • ‘‘If the previous reception carried a negative acknowledgment, or the previous reception was in error, retransmit the old message; otherwise fetch a new message for transmission.’’ 15/38

16. PROCEDURE RULES 16/38

17. Protocol Problems 17/38

18. Protocol Examples • Clayton Tunnel Protocol • Service: • Assumptions • Vocabulary: • Encoding: • Procedure rules: 18/38

19. Services and Environment • A protocol must perform a range of lower-level functions • The specific realization of a service depends on the assumptions that are made about the environment in which the protocol is to be executed. • Error recovery, for instance, should correct for the assumed behavior of the transmission medium. • We can separate these two services into two functional submodules. 19/38

20. Services and Environment (cont.) • Each layer can enclose the data to be transmitted in a new data envelope, consisting of a header and/or trailer, before passing it to the next layer. • The original data format from the upper layers need not even be preserved by the lower layers. • The data may well be divided up differently, in larger or in smaller portions, as long as the original format can be restored by the receiving protocol module. • Advantages of such meathod are clear: • A layered design helps to indicate the logical structure of the protocol by separating higher-level tasks from lower-level details. • When the protocol must be extended or changed, it is easier to replace a module than it is to rewrite the whole protocol. 20/38

21. Services and Environment (cont.) • International Standards Organization (ISO) recognized the advantages of standardizing a hierarchy of protocol services as a reference model for protocol designers. 21/38

22. ISO-OSI Reference Model • Physical layer: transmission of bits over a physical circuit • Data link layer: error detection and recovery • Network layer: transparent data transfer and routing • Transport layer: user to user higher-level data transfer • Session layer: coordination of interactions in user sessions • Presentation layer: interpretation of user-level syntax for instance for encryption or compression of data • Application layer: entry point for application processes such as electronic mail or file transfer demons 22/38

23. Protocol Layering 23/38

24. Protocol Layering • A layer defines a level of abstraction in the protocol, grouping closely related functions and separating them from orthogonal ones. By decoupling layers, future changes made in one layer need not affect the design of the other layers. The correct choice of the required levels of abstraction necessarily depend on the specific protocol being designed. • An interface separates distinct levels of abstraction. A correctly placed interface is small and well-defined. A badly placed interface causes unnecessary complexity, it causes code duplication, and it may degrade performance. 24/38

25. PROCEDURE RULES • An important aspect of the protocol design problem is that the procedure rules are interpreted concurrently by a number of interacting processes. • The effect of each new rule we add to the set is often much larger than can be foreseen. • Many different interleaving in time of the interpretation of these rules by the various processes will be possible. • A protocol behavior is not always reproducible. • There is no general methodology that can guarantee a priori the design of an unambiguous set of procedure rules • There are tools with which we can, even automatically, verify the logical consistency of the rules. 25/38

26. STRUCTURED PROTOCOL DESIGN • Protocol design is partly an engineering problem that can be addressed by the application of well-known techniques. • To Better Design a Protocol in a structured technique, we need to insure that the protocol is: • SIMPLICITY • MODULARITY • WELL-FORMED PROTOCOLS • ROBUSTNESS • CONSISTENCY 26/38

27. SIMPLICITY • A well-structured protocol can be built from a small number of well-designed and well-understood pieces. Each piece performs one function and performs it well. To understand the working of the protocol it should suffice to understand the working of the pieces from which it is constructed and the way in which they interact. • Protocols that are designed in this way are easier to understand and easier to implement efficiently, and they are more likely to be verifiable and maintainable. • A light-weight protocol is simple, robust, and efficient. • The case for light-weight protocols directly supports the argument that efficiency and verifiability are not orthogonal, but complementary concerns. 27/38

28. MODULARITY • A protocol that performs a complex function can be built from smaller pieces that interact in a well-defined and simple way. • Each smaller piece is a light-weight protocol that can be separately developed, verified, implemented, and maintained. • Orthogonal functions are not mixed; they are designed as independent entities. • The individual modules make no assumptions about each other’s working, or even presence. • Error control and flow control, for instance, are orthogonal functions. They are best solved by separate light-weight modules that are completely unaware of each other’s existence. 28/38

29. WELL-FORMED PROTOCOLS • Not over-specified: does not contain any unreachable or unexecutable code. • Not under-specified or incomplete: An incompletely specified protocol may cause unspecified receptions during its execution. An unspecified reception occurs if a message arrives when the receiver does not expect it or cannot respond to it. • Bounded: it cannot overflow known system limits, such as the limited capacity of message queues. • Self-stabilizing: always returns to a desirable state within a finite number of transitions, and resumes normal operation. • Self-adapting: It can adapt the rate at which data are sent to the rate at which the data links can transfer them, and to the rate at which the receiver can consume them. 29/38

30. ROBUSTNESS • It is not difficult to design protocols that work under normal circumstances. It is the unexpected that challenges them. • A protocol must be prepared to deal appropriately with every feasible action and with every possible sequence of actions under all possible conditions. • The protocol should make only minimal assumptions about its environment to avoid dependencies on particular features that could change. • A robust design automatically scales up with new technology, without requiring fundamental changes. • not over-designby adding functionality for anticipated new conditions, but minimaldesign by removing non-essential assumptions that could prevent adaption to unanticipated conditions. 30/38

31. CONSISTENCY • There are some standard and dreaded ways in which protocols can fail.. • Deadlocks: states in which no further protocol execution is possible. • Livelocks: execution sequences that can be repeated indefinitely often without ever making effective progress. • Improper terminations: the completion of a protocol execution without satisfying the proper termination conditions. • In general, the observance of these criteria cannot be verified by a manual inspection of the protocol specification. 31/38

32. TEN RULES OF DESIGN • Make sure that the problem is well-defined. All design criteria, requirements and constraints, should be enumerated before a design is started. • Define the service to be performed at every level of abstraction before deciding which structures should be used to realize these services (what comes before how). • Design external functionality before internal functionality. First consider the solution as a black-box and decide how it should interact with its environment. • Then decide how the black-box can internally be organized. Likely it consists of smaller black-boxes that can be refined in a similar fashion. • Keep it simple. Fancy protocols are buggier than simple ones; they are harder to implement, harder to verify, and often less efficient. 32/38

33. TEN RULES OF DESIGN (cont.) • Do not connect what is independent. Separate orthogonal concerns. • Do not introduce what is immaterial. Do not restrict what is irrelevant. A good design is ‘‘open-ended,’’ i.e., easily extendible. A good design solves a class of problems rather than a single instance. • Before implementing a design, build a high-level prototype and verify that the design criteria are met. • Implement the design, measure its performance, and optimize it. • Check that the final optimized implementation is equivalent to the high-level • Don’t skip Rules 1 to 7. 33/38

34. Why Formal Methods? “Program testing can be a very effective way to show the presence of bugs, but it is hopelessly inadequate for showing their absence.” Edsgar W. Dijkstra • Bottom line: Not feasible to simulate all input sequences to completely verify a design. 34/38

35. Why Protocol Verification? • Time to Market: • New systems and services must be available quicker • How can we reduce testing time ? • Pressure to improve quality • SW outage average time for network elements measured in seconds per year • How can we improve testing quality ? • Formal Protocol Verification 35/38

36. Why Formal Methods ? • Formal Methods is the application of logic to the development of “correct” systems • Correctness is classically viewed as two separate problems, validation and verification • Validation: answers “are we building the right system?” • Verification: answers “are we building the system right?” • Formal methods are used today in many applications including: • Cache Coherency Protocols • Telecommunications Protocols • Rail and Track Signaling • Security Protocols • Automotive Companies 36/38

37. Course Outline: • Introduction: • Service Architecture vs. Protocol Architecture. • Definition of Protocol Functions. • Protocol Representation Techniques: • Finite State Machines. • Petri Nets • Overview of (Protocol) Formal Description Techniques: SDL. • Protocol Engineering: • Protocol specification, verification and validation, testing. • Example Classes for Network Protocols: • Alternating-bit-protocol, link protocols (HDLC class of protocols), packet layer protocol (IP), routing protocols. 37/38

38. Grading Scheme: • Assignments: 3/3 10% • Quizzes: 2/3 (during lectures/tutorial) 10% • Midterm: 25% + Final: 40% • Project: 15% (Groups of 2) (Get your Group Ready by next week) 38/38