1 Dr. Eng. Amr T. Abdel-HamidNETW 703 Network Protocols Introduction Dr. Eng. Amr T. Abdel-Hamid Spring 2017
2 Administrative DetailsInstructor: Dr. Eng. Amr T. Abdel-Hamid Office: C3-320 Course TA: Ahmed Badr Junior TAs: 3 Students (1 10th semester, 2 8th Semester)
3 (Get your Group Ready by next week)Grading Scheme: Assignments: 0% Quizzes: 2/3 (during lectures/tutorial) 10% Midterm: 25% + Final: 40% Project: 25% (Groups of 3) (Get your Group Ready by next week)
4 In time & It is too LATE PolicyIn phases 0, & 1: 5% of project grade penalty per day for being late In phase 2, & 3: No late presentation is possible. Honor code 100% penalty for both copier and copy-giver
5 Administrative Details (CONT.)Text Book: Design and Validation of Computer Protocols, by Gerard J. Holzmann. References: Alberto Leon-Garcia, Indra Widjaja: Communication Networks: Fundamental Concepts and Key Architectures (2nd edition), Publisher: McGraw-Hill College, ISBN: S. Tanenbaum Computer Networks, Pearson Education, Inc., 2003, ISBN Data communications, Computer Networks and Open Systems, by F. Halsall, published by Addison Wesley, 1999.
6 What is a Protocol? Computer network protocol Human protocol Hi 9:30Got the time? 9:30 time TCP connection request response HTTP GET File
7 Communications ProtocolA 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
8 History of Protocols Fire Messages Torch Telegram 1 8/38
9 History of Protocols G. Huth “telephone” C. Chappe “semaphore”W. Cooke “NeedleTelegram” Morse Code 9/38
10 Clayton Tunnel Stop Is Train out train in tunnel Worker A Train 1Worker B train in Clear train in Clear 10/38
11 Clayton Tunnel (2) 21 died and 176 were injured. Stop train in tunnelIs 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 11/38
12 Who is to blame? The driver of the second train? ...but he followed the signal. Signalman A, who misinterpreted the “tunnel clear” message? ... but how could he know which train was meant? Signalman B, who did not react on two “train in tunnel” msgs.?
13 Coclusion The signalmen did not have the appropriate set of messagesAn unexpected case occurred that could not be handled by the protocol. The protocol could not recover from an error, it was incomplete in this sense
14 Quiz 0 Write down 5 changes in the protocol that would have prevented the tragic accident?!! … 14/38
15 Quiz 0 How do we know that there will not be any other accidents?15/38
16 What is protocol design?It’s more than just implementation A development process: Requirements Specification and validation Implementation Test and evaluation ...a challenging task, even for simple protocols
17 THE FIVE ELEMENTS OF A PROTOCOLA protocol specification consists of five distinct parts: The service to be provided by the protocol The assumptions about the environment in which the protocol is executed The vocabulary of messages used to implement the protocol The encoding (format) of each message in the vocabulary The procedure rules guarding the consistency of message exchanges 17/38
18 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. 18/38
19 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. 19/38
20 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 } 20/38
21 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). 21/38
22 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.’’ 22/38
23 PROCEDURE RULES NACK ERR get next char ACK start 23/38 receive sendfunction call state 23/38
24 Protocol Problems 24/38
25 Quiz 0’: Protocol ExamplesClayton Tunnel Protocol Service: Assumptions Vocabulary: Encoding: Procedure rules: 25/38
26 Design Aspects What are the properties of a good protocol? SimplicityModularity Well-formedness neither over- nor under-specified bounded, self-stabilizing, self-adapting Robustness Consistency avoidance of deadlocks, livelocks, or improper terminations
27 Simplicity Lean design Think about the next steps...A protocol should be built from a small number of elements Each element focuses on one function Think about the next steps... A lean design makes it easier to implement, verify and maintain
28 Modularity Complex functions should be built from independent and individual light-weight modules Decoupling of orthogonal functions No assumptions about other modules Main structuring techniques: protocol layering structuring of data
29 Modularity - Protocol LayeringModularity by layering separating higher level tasks from lower level details example: OSI model Protocol layers define levels of abstraction should integrate related functions should have small and well-defined interfaces
30 ISO-OSI Reference ModelPhysical 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 30/38
31 Protocol Layering - Service ModelLayer n Layer n-1 Layer n+1 interface protocol services offered services used host A host B
32 Protocol Layering ExampleA protocol for secure data transmission over a raw physical data link: handling of transmission errors flow control key exchange encoding/decoding Decoupling of methods for reliable data transmission and security functions Link layer and security layer provide independent services Link Secure PHY PHY
33 Protocol Layering Advantages ProblemsLayering allows to break complex problems into smaller pieces Implementation as light-weight modules Modules are exchangeable (interface specification is independent from the implementation) Modules are reusable Problems Information hiding can lead to performance loss
34 Modularity - Data structuringLow level data formatting: Bit-oriented, character-oriented, or byte-count oriented frame delimiters: bit sequence, character, or indicated by a counter Higher level formatting Structured headers and trailers sequence numbers, checksums sender, receiver, priorities, ... Levels of abstraction
35 Modularity - Data structuringEncapsulation Each layer adds its meta-data (header and trailer) Frame trailer Data header UDP payload Application Transport Network Link IP Frame pa yload
36 Well-formedness A well-formed protocol isneither over- nor under-specified (redundancy or incompleteness) bounded: it attends to system limits (memory limits) self-stabilizing: it returns to a defined state after a transient error occurred self-adapting: it adapts to environmental changes (e.g. flow control)
37 Robustness proper execution under all possible conditionsthe protocol should adhere to a minimal design minimal assumptions about the environment avoidance of dependencies on other protocol elements, system parameters, etc.
38 Consistency Avoidance of: inconsistent states (deadlocks)loops in protocol execution without progress (livelocks) improper protocol termination
39 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. 39/38
40 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. 40/38
41 Stages of the Development ProcessBasic activities (which appear in many process models) Requirements analysis Design specification Validation Implementation Test and evaluation Deployment Maintenance 41/38
42 Waterfall Model Requirements Design specification and validationImplementation Deployment and maintenance Test and evaluation
43 Waterfall Model (Problems)Requirements Design specification and validation Implementation Deployment and maintenance Test and evaluation requirements may change at any stage tests may reveal design flaws and programming errors fixes and patches
44 Modified Waterfall modelRequirements Design specification and validation Implementation Deployment and maintenance Test and evaluation feedback loops
45 V Model Requirements System design Architecture design ImplementationModule design Acceptance test System test Integration test Unit test