1. Computer Networks Group Universität Paderborn Konzepte und Methoden der Systemsoftware Kapitel 9: Rechnernetze Holger Karl

2. SS 06, v 1.1KMS - Kap. 9: Rechnernetze2 Goals of this chapter  Previous chapter has introduced the notion of “channel objects” to abstract away how data is exchanged between two processes  This abstraction is OK for two processes on the same machine – but what about communication across machine boundaries?  This chapter treats this problem – it starts from the simple case of two directly connected devices and generalizes to larger networks  Goal is to provide a rough understanding on  Which typical problems in computer networks exist,  Why they occur,  How a solution could look like.  Details on solutions will be treated in a separate lecture

3. SS 06, v 1.1KMS - Kap. 9: Rechnernetze3 Overview  Examples  Direct connection between two devices  Multiple devices  Errors

4. SS 06, v 1.1KMS - Kap. 9: Rechnernetze4 How to bridge across devices with a channel object?  Channel objects used as a “bridge”  Need some functionality on “both sides” of such a bridge – stubs  How to organize these stubs?

5. SS 06, v 1.1KMS - Kap. 9: Rechnernetze5 Basic example 1: World Wide Web  What happens when you enter http://www.uni-paderborn.de into a Web browser? http://www.uni-paderborn.de ??

6. SS 06, v 1.1KMS - Kap. 9: Rechnernetze6 Basic example 2: Telephony  What happens when picking up a telephone and making a phone call?  How to find the peer’s phone? How to transmit speech?  What are the crucial differences between transferring a Web page and a phone call?  Web: Bunch of data that has to be transmitted correctly  Phone: Continuous flow of information, must arrive in time, limited amount of errors acceptable ?

7. SS 06, v 1.1KMS - Kap. 9: Rechnernetze7 What to communicate: Information, data  Data  A formalized representation of facts, concepts, ideas, descriptions, …  Example: text, speech  Information  A human interpretation of data, conferring meaning to data  In this sense, a human-oriented term  Only data can be communicated, information is restored by the human receiver  Human to human, machine to machine, human to machine Information Facts, concepts, ideas, … Data Formalized representation of information Conventions for representation Abstract world

8. SS 06, v 1.1KMS - Kap. 9: Rechnernetze8 Overview  Examples  Direct connection between two devices  Signals  Low-level communication properties  Duplex  Multiple devices  Errors

9. SS 06, v 1.1KMS - Kap. 9: Rechnernetze9 Simplest communication: Direct physical connection  Web example: Browser (i.e. client) and server  Simplest case: directly connect them by a (pair of) cable  Server provides data, client consumes it  Telephony: Connect two telephones via a (pair of) cable Client Server

10. SS 06, v 1.1KMS - Kap. 9: Rechnernetze10 Conventions for representation What good is a physical connection? – Signals  Data has to be represented by signals  Signal: Representation of data by characteristic changes (in time and/or space) of physical variables  Material example: Letters on paper  Immaterial example:  Acoustic waves when speaking  Current or voltage in a wire  Immaterial signals in physical media enable data communication between remote senders and receivers Information Data Conventions for representation Abstract world Signals Physical world

11. SS 06, v 1.1KMS - Kap. 9: Rechnernetze11 Bits and signals  What should be communicated: Data, represented as bits  What can be communicated between remote entities: Signals  Needed: a means to transform bits into signals  And: from signals back into bits at the receiver  A simple convention for a copper wire:  A “1” is represented by current  A “0” is represented by no current  (Not practical, more sophisticated conversions necessary)  Questions: How to detect bits, decide on their length, handle errors?

12. SS 06, v 1.1KMS - Kap. 9: Rechnernetze12 Low-level properties of communication  Transmitting signals on a physical carrier results in some low-level properties  Propagation delay d: How long does it take for a signal to reach receiver?  Propagation speed v: How fast does a signal travel in the medium?  Electromagnetic waves in vacuum speed of light v=c, in copper v¼ 2/3 c  d = distance / v  Data rate r: With which data rate (in bits/second) can a sender transmit?  (EOT – SOT) = Data size / data rate  Error rate: What is the rate of incorrect bits arriving at the receiver?  Also: what error patterns? Message Sequence Charts (MSC) Start of transmission End of transmission Delay d Time Distance

13. SS 06, v 1.1KMS - Kap. 9: Rechnernetze13 How can a wire store data – bandwidth-delay product  What happens in the first d seconds after transmission starts?  Bits are transmitted and propagate towards the receiver  Sender keeps sending bits  First bit arrives after d seconds  In this time, sender has transmitted d*r bits  Where are they? Stored in the wire!  d*r is the product of delay and data rate  Commonly called bandwidth/delay product  Crucial property of high-performance networks Start of transmission Time Delay d Example (transcontinental):  Data rate 100 Mbit/s  Delay 6000km/(2/3c) ¼ 0.03 s  d*r ¼ 3 Mbit (in the wire)

14. SS 06, v 1.1KMS - Kap. 9: Rechnernetze14 Two physical connections for two-way communication?  Two-way communication  Telephony: Both parties want to say something  WWW: Server needs to know which webpage shall be delivered  Different cases possible:  Simplex: Only one party transmits  Example: Radio broadcast; many recipients at the same time  Half duplex: Parties alternatively send data  Example: Conversation  Full duplex: Both parties send all the time A B

15. SS 06, v 1.1KMS - Kap. 9: Rechnernetze15 How to realize duplexing  Simplex operation: trivial  Half duplex  Two pairs of cables, one for each direction – wasteful  Use one cable intelligently – participants alternatively transmit, wait their time until it is their turn  Both sending at the same time would not work, signals interfere  Problem: How can one node decide that the other is done sending? Time A ! B B ! AA ! B B ! A  Time division duplex – TDD

16. SS 06, v 1.1KMS - Kap. 9: Rechnernetze16 How to realize duplexing  Full duplex  Two pairs of cables would work, but still overhead (installation, maintenance, …) – does it work with one cable also?  Exploit some properties of the physical medium  Here: transmissions in different frequencies do not interfere  Idea: use different frequencies for transmission in different directions Time A ! B B ! A Frequency  Frequency Division Duplex – FDD

17. SS 06, v 1.1KMS - Kap. 9: Rechnernetze17 How to realize duplexing A ! B AB B ! A AB Data to be transmitted  TDD can realize full duplex if transmission over medium is at least twice as fast as data is to be transmitted  Full duplex by time division duplexing?  Sounds like a contradiction: both A and B always have data to send, but have to take turns?  “Having data to send” corresponds to a certain data rate – bits per second  How about intermediately storing data when the other station is currently sending? Then quickly send all stored & new data

18. SS 06, v 1.1KMS - Kap. 9: Rechnernetze18 Lessons learned from duplexing  It is useful to distinguish between  Requirements on what should be possible  Rules and methods how to implement such requirements  Example: Implement a “full duplex” requirement using TDD  This distinction will become very important  Formalized later as service versus protocol  Buffering is an important means to decouple different dynamics in time  Questions of buffer overflow have to be considered

19. SS 06, v 1.1KMS - Kap. 9: Rechnernetze19 Overview  Examples  Direct connection between two devices  Multiple devices  Multi-hop connections  Switching  Forwarding  Multiplexing  Multiple access  Routing  Errors

20. SS 06, v 1.1KMS - Kap. 9: Rechnernetze20 But there are more than two computers/telephones  Connect each telephone/computer with each other one? With four computers: With eleven computers: …

21. SS 06, v 1.1KMS - Kap. 9: Rechnernetze21 Beirut connections  Connecting many phones in real life

22. SS 06, v 1.1KMS - Kap. 9: Rechnernetze22 Beirut connections

23. SS 06, v 1.1KMS - Kap. 9: Rechnernetze23 Put some structure into a network  Pair wise connecting all entities does not work  Need some structure  Distinguish between “end systems/terminals/user devices” on one hand, “switching elements/routers” on the other hand

24. SS 06, v 1.1KMS - Kap. 9: Rechnernetze24 Typical network structures for local installations  “Busses”  All nodes connected to a single wireline  Cheap, but relatively inefficient, error-prone  “Rings”  Nodes connected to a ring- shape network  Can compensate for a single break of pairwise connection  “Star”  All nodes directly connected to a central cabling “hub”  Again error-prone, but easy to administer, manage

25. SS 06, v 1.1KMS - Kap. 9: Rechnernetze25 How to communicate over a switching element  Using switching elements, there is no longer a direct physical connection between two terminals – How to send signals nonetheless?  Option 1: Have the switching element dynamically, on demand configure an electrical circuit between terminals  Act as a real switch – compare “Fräulein vom Amt”  Resulting circuit lasts for duration of communication  Circuit switching http://www.wdrcobg.com/switchboard.html

26. SS 06, v 1.1KMS - Kap. 9: Rechnernetze26 Circuit switching – evaluation  Advantages of circuit switching  Simple  Once circuit is established, resources are guaranteed to participating terminals  Once circuit is established, data only has to follow the circuit  Disadvantages  Resources are dedicated – what if there is a pause in the communication?  Circuit has to be set up before communication can commence  Alternatives?

27. SS 06, v 1.1KMS - Kap. 9: Rechnernetze27 Packet switching  Avoid setting up a circuit for a complete communication  Instead: chop up data into packets  Packets contain some actual data that is to be delivered to the recipient (can have different size)  Also need administrative information, e.g., who the recipient is  Sender then occasionally sends out a packet, instead of a continuous flow of data  Problems: How to detect start and end of a packet, which information to put into a packet, … Packet 1 Packet 2 Packet 3

28. SS 06, v 1.1KMS - Kap. 9: Rechnernetze28 Packet switching II  Switches take on additional tasks  Receive a complete packet  Store the packet in a buffer  Find out the packet’s destination  Decide where the packet should be sent next to reach its destination  Information about the network graph necessary  Forward the packet to this next hop of its journey  Also called “store-and- forward” network To X Buffer To Y To Z To Y To Z Pick next hop To Y To X To Z

29. SS 06, v 1.1KMS - Kap. 9: Rechnernetze29 Multiplexing  Previous example had two packets at the head of the queue destined for terminal Z  Similar situation: a switching element has only a single outgoing connection  Such a special case is called a multiplexer  Organizing the forwarding of packets over such a single, shared connection is called multiplexing  Multiplexers in general need buffer space as well

30. SS 06, v 1.1KMS - Kap. 9: Rechnernetze30 Multiplexing II  Obvious option: Time Division Multiplexing (TDM)  Serve one packet after the other; divide the use of the connection in time  Alternative: Frequency Division Multiplexing (FDM)  Use different frequencies to transmit several packets at the same time To Z (in frequency 1) (in frequency 2)

31. SS 06, v 1.1KMS - Kap. 9: Rechnernetze31 Multiplexing III  Some other alternatives exist  Code Division Multiplexing (CDM), Space Division Multiplexing (SDM)  Mostly relevant in wireless communication only, not covered here  Obvious parallels/relations to duplex operation!  Multiplexing describes how to operate several pairs of communicating entities  Duplexing describes how a given pair of communicating entities can exchange data Question: How to combine different duplex and multiplexing schemes?

32. SS 06, v 1.1KMS - Kap. 9: Rechnernetze32 Mutliplexing & virtualization  In essence, mutiplexing serves one particular purpose:  It abstracts away that a physical connection has to be shared with other contending entities, each sending a logical flow  It allows the entities connected to the switch to “imagine” that they alone are using the physical connection  At somewhat lesser properties  Multiplexing virtualizes the actual, physical connection  It needs a peer entity, a demultiplexer, to restore the original flows  This concept of virtualizing and enriching the properties of a simpler subsystem is a pivotal technique for communication networks  As it is in software engineering, operating systems, etc.  It allows us to think in terms of increasingly more complex communication systems, build one atop the other

33. SS 06, v 1.1KMS - Kap. 9: Rechnernetze33 Multiplexing & shared resources  Multiplexing can be viewed as a means to regulate the access to a resource that is shared by multiple users  The switching element/its outgoing line  With the switching element as the controller  Are there other examples of “shared resources”?  Classroom, with “air” as physical medium  A shared copper wire, as opposed to direct connection  Characteristic: a broadcast medium! Virtually shared, but exclusively controlled! Shared!

34. SS 06, v 1.1KMS - Kap. 9: Rechnernetze34 Broadcast medium and multiple access  Common characteristic of a broadcast medium: Only a single sender at a time!  Exclusive access is necessary  There are some exceptions using CDMA, but that’s advanced material  Exclusive access is simple to achieve with a multiplexer  What if no multiplexer is available?  Exclusive access has to be ensured by all participants working together  The problem of multiple access to a shared medium  Medium access for short  Rules have to be agreed upon  Classroom approach: only speak when asked to, central instance

35. SS 06, v 1.1KMS - Kap. 9: Rechnernetze35 An intermediate summary  So far, we have a rough idea about  Converting bits to signals and back again  Duplexing, switching, multiplexing  Packets as unit of data transport  Multiple access of several entities to a shared medium  In essence, we know how to connect several entities into a flat or hierarchical network  Missing piece for hierarchical networks: How to know where to send a packet  For circuit switching: how to setup the circuit

36. SS 06, v 1.1KMS - Kap. 9: Rechnernetze36 Forwarding and next hop selection  Recall: A switching element/a router forwards a packet onto the next hop towards its destination  How does a router know which of its neighbors is the best possible one towards a given destination?  What is a “good” neighbor, anyway? A Z ? ? ? ? U V W X Y P M

37. SS 06, v 1.1KMS - Kap. 9: Rechnernetze37 Options for next hop selection  Some simple options:  Flooding – send to all neighbors  Hot potato routing – send to a randomly chosen neighbor  Simple options not convincing  Try to find good, i.e., short routes – few hops  Try to learn about the structure of the network, interpreted as a graph  Construct routing tables  For each switching element separately  Separate entry for each destination  Contains information about the (conjectured) shortest distance to a given destination via each neighbor MPZ U234 V323 X432 Y443 Destination Neighbor Routing table of W

38. SS 06, v 1.1KMS - Kap. 9: Rechnernetze38 Routing tables  Criteria  Good/perfect estimate of real distances, absence of loops, …  Constructing routing tables  Initially, typically empty – how should a new node know anything?  Passive: observe ongoing traffic (e.g., from hot potato routing) and try to extract information, successively improve table correctness  Actively exchange information between routers to try to learn network structure – routing protocols  Problem: Size!  In large networks, maintaining routing entries for all possible destinations quickly becomes infeasible  Solution: hierarchy – treat “similar” nodes identically (divide et impera) ! internetworking

39. SS 06, v 1.1KMS - Kap. 9: Rechnernetze39 Overview  Examples  Direct connection between two devices  Multiple devices  Errors

40. SS 06, v 1.1KMS - Kap. 9: Rechnernetze40 Handling errors, overload, …  So we are done building a network – unless something goes wrong!  Source of errors/abnormal situations  Conversion from signals to bits can fail  Access to a shared medium might not work  Packets can be lost, e.g., because buffers overflow  Packets can be misrouted (because of incorrect routing tables), delayed, reordered  Receiver might not be able to keep up with incoming stream of packets  Routers can fail, resulting in incorrect routing tables  … and many more

41. SS 06, v 1.1KMS - Kap. 9: Rechnernetze41 Handling errors, overload, …  Error control at various abstraction levels needed  Between two direct neighbors, over a given connection  Between end systems, to compensate for errors not detected locally – e.g., incorrect order of packets  Overload control  Protect the network against buffer overflows, regulate the number of packets injected into the network – Congestion control  Protect end system against too many packets coming in – Flow control  Where and how to implement error and overload control is a principal architectural decision  Main options: in the end system or in the network  Big difference between telephony system and Internet  Telephony carriers are (traditionally) interested in network-based solutions to be able to charge for it

42. SS 06, v 1.1KMS - Kap. 9: Rechnernetze42 Intermediate summary: Basic required functions  Bit-to-signal and signal-to-bit conversion  Grouping bits into packets  Accessing a shared medium  Switching, duplexing, multiplexing  Controlling errors on a connection between two systems  Forwarding incoming packets, consulting routing tables  Constructing routing tables, maintaining them  Controlling errors not detectable between two neighboring systems  Protecting the network against overload  Protecting end systems against overload  Ensuring correct order and possibly timeliness of packets  Making these functions accessible from application programs  Controlling the actual hardware that connects a wire to a computer  … and more!

43. SS 06, v 1.1KMS - Kap. 9: Rechnernetze43 System structure  Any chance to build a single, monolithic system/piece of software that realizes all these functions, from wire to application? – No way!  To give an idea: Size of telecommunication and astronautic software (Siemens telephony switches)

44. SS 06, v 1.1KMS - Kap. 9: Rechnernetze44 System structure – layers  Only feasible option: Build “virtual” subsystems of increasing capabilities and abstraction levels  Example: Multiplexing abstracted away the physical connections capability to support a single transmission into a logical link that can be used by several entities  Subsystems are called layers  Each layer uses capabilities of a “lower” subsystem, adds own rules and procedures, to provide a more useful, advanced service  Services expose a well defined interface to higher layers  Services are accessible at their Service Access Point (SAP)  A service is a promise what is going to happen to data when delivered to the SAP

45. SS 06, v 1.1KMS - Kap. 9: Rechnernetze45 Service  Service: Any act or performance that one party can offer to another that is essentially intangible and does not result in the ownership of anything. Its production may or may not be tied to a physical product. D. Jobber, Principles and Practice of Marketing  Focus is on the output, the result of the service  NOT the means to achieve it

46. SS 06, v 1.1KMS - Kap. 9: Rechnernetze46 Overview  Structuring communication systems into layers  Services  Service primitives  Properties of service primitives  Example: sockets  Protocols  Reference models  Standardization

47. SS 06, v 1.1KMS - Kap. 9: Rechnernetze47 Services and layers  Layers provide services to their users, at their interface  Convention: consecutive numbering, higher numbers for more abstract layers/services  Service can be accessed at different places by different users Layer 0 “Physical connection” Service Access Point (SAP) of Layer 0: Imperfect transmission of electromagnetic current Layer 1 “Bit ! Current/Current ! Bit conversion” Service Access Point (SAP) of Layer 1: Transmission of bit sequences (possibly erroneous) Uses

48. SS 06, v 1.1KMS - Kap. 9: Rechnernetze48 Service primitives  Service primitives: set of operations available at the interface of a service (“channel object API”)  Formal definition of the service  Example for Bit Transmission Layer  SEND_BIT – sender can ask for the delivery of a bit to the receiver  RECEIVE_BIT – receive can wait for the arrival of a bit (blocking)  INDICATE_BIT – indicate to the receiver that bit is now available (asynchronous)  Many different ways to structure service primitives conceivable  Already covered: Request, Indication, Response, Confirmation  Unit of data: individual bytes, messages

49. SS 06, v 1.1KMS - Kap. 9: Rechnernetze49 Service primitives – correctness requirements  For both message and byte stream oriented (set of) service primitives, correctness requirements are important  Completeness: All data that is sent is eventually delivered  Correctness: If data is delivered, its is correct, i.e., the data that has been actually sent  Messages are not modified, original version is delivered  Byte sequence is free of errors  In order: Byte sequence/sequence of messages is delivered in the order it has been sent  Dependable: secure, available, …  Confirmed: Reception of data is acknowledged to the sender  Not all requirements are always necessary

50. SS 06, v 1.1KMS - Kap. 9: Rechnernetze50 Connection-oriented vs. connection-less service  Recall telephony vs. postal service  Service can require a preliminary setup phase, e.g., to determine receiver ! connection-oriented service  Three phases: connect, data exchange, release connection  Alternative: Invocation of a service primitive can happen at any time, with all necessary information provided in the invocation ! connection-less service  Note: This distinction does NOT depend on circuit or packet switching – connection-oriented services can be implemented on top of packet switching (and vice versa, even though a bit awkward)  Connection-oriented services must provide primitives to handle connection  CONNECT – setup a connection to the communication partner  LISTEN – wait for incoming connection requests  INCOMING_CONN – indicate an incoming connection request  ACCEPT – accept a connection  DISCONNECT – terminate a connection

51. SS 06, v 1.1KMS - Kap. 9: Rechnernetze51 Typical examples of services  Datagram service  Unit of data are messages  Correct, but not necessarily complete or in order  Connection-less  Usually insecure/not dependable, not confirmed  Reliable byte stream  Byte stream  Correct, complete, in order, confirmed  Sometimes, but not always secure/dependable  Connection-oriented  Almost all possible combinations are conceivable!

52. SS 06, v 1.1KMS - Kap. 9: Rechnernetze52 BSD sockets as service interface for computer networks  We’ve already covered BSD sockets as one service interface for intra-device channel objects  They should also apply to inter-device channel objects – and they do!  Model the network service like the access to a file  Sending data = Writing to a file  Receiving data = Reading from a file  Opening a file = Connecting to a communication peer  Files – in UNIX – are treated via so-called file handles  By analogy, file handles will represent communication peers ! Same thing as treated already!

53. SS 06, v 1.1KMS - Kap. 9: Rechnernetze53 Datagram communication over sockets  Simplest possible service: unreliable datagrams Sender  int s = socket (…);  sendto (s, buffer, datasize, 0, to_addr, addr_length);  to_addr and addr_length specify the destination Receiver  int s = socket (…);  bind (s, local_addr, …);  recv (s, buffer, max_buff_length, 0);  Will wait until data is available on socket s and put the data into buffer

54. SS 06, v 1.1KMS - Kap. 9: Rechnernetze54 Byte streams over a connection-oriented socket  For reliable byte streams, sockets have to be connected first  Receiver has to accept connection Client  int s = socket (…);  connect (s, destination_addr, addr_length);  send (s,buffer, datasize, 0);  Arbitrary recv()/send()  close (s);  Connected sockets use a send without address information Server  int s = socket (…);  bind (s, local_addr, …);  listen (s, …);  int newsock = accept (s, *remote_addr, …);  recv (newsock, buffer, max_buff_length, 0);  Arbitrary recv()/send()  close (newsock);

55. SS 06, v 1.1KMS - Kap. 9: Rechnernetze55 Sockets – UNIX domain or cross-device?  The previous two slides looked almost identical to the sockets example in the previous chapter  How does the service (behind the interface) know what type of function is required?  Solution: socket creation function makes the difference!  UNIX domain stream: socket (AF_LOCAL, SOCK_STREAM, 0);  UNIX domain datagram: socket (AF_LOCAL, SOCK_DGRAM, 0);  Cross-device socket, stream: socket (AF_INET, SOCK_STREAM, 0);  Cross-device socket, datagram: socket (AF_INET, SOCK_DGRAM, 0);  Anything else: Identical (more or less)!

56. SS 06, v 1.1KMS - Kap. 9: Rechnernetze56 Overview  Structuring communication systems into layers  Services  Protocols  Reference models  Standardization

57. SS 06, v 1.1KMS - Kap. 9: Rechnernetze57 Layer 0 ”Physical connection” Layers are distributed  Previous example: “Bit sequence layer” has to be present at both transmitter (bit ! electrical current) and at receiver (electrical current ! bit) Pair of copper wires Layer 1 “Bit ! Current conversion” Layer 1 “Current ! Bit conversion” Sender Receiver SAP of Layer 1 Bits SAP of Layer 1 “Stubs” for channel objects

58. SS 06, v 1.1KMS - Kap. 9: Rechnernetze58 Distributed layers need to follow rules – protocols  Distributed parts of the layer 1 implementation have to follow the same set of rules – protocols  Suppose sender represented a “1” by “current there”; receiver by “no current” Layer 0 ”Physical connection” Pair of copper wires Layer 1 “Bit ! Current conversion” Layer 1 “Current ! Bit conversion” Sender Receiver SAP of Layer 1 Bits SAP of Layer 1 Identical rules of operation Matching rules of operation

59. SS 06, v 1.1KMS - Kap. 9: Rechnernetze59 Protocols  Protocols are a set of rules  Describe how two (or more) remote parts of a layer cooperate to implement the service of the given layer  Behavior, packet formats, …  These remote parts are called peer protocol entities or simply peers  Use the service of the underlying layer to exchange data with peer Layer n SAP n Layer n SAP n Layer n+1 SAP n+1 Layer n+1 SAP n+1 Use Protocol Use  Protocol is implementation of the service  Not visible to service user

60. SS 06, v 1.1KMS - Kap. 9: Rechnernetze60 Protocol specification  The formal behavior, the rules which constitute the protocol have to be precisely specified  One popular method: (Extended) Finite State Machine (FSM)  A protocol instance/protocol engine at each entity  Protocol instance has several states  E.g., for a protocol implementing a connection oriented service: IDLE, CONNECTED, RELEASING_CONNECTION  Events/transitions between states  Message arrivals  Real time / timer events  Transition can have conditions  Actions during transition are  Send new message  Set timer, delete timer, … STATE1 STATE2 Condition | Event ; Action

61. SS 06, v 1.1KMS - Kap. 9: Rechnernetze61 Protocols and FSMs  Finite state machines implement actual behavioral rules of a protocol  Have to communicate with their remote peer  Cannot do so directly, have to use service of the underlying communication layer  Via service primitives, which can also provide arriving data to the protocol  E.g., indications from lower layer are events to higher layer protocol engine Layer n Use service primitives Layer n+1

62. SS 06, v 1.1KMS - Kap. 9: Rechnernetze62 Protocols and messages  When using lower-layer services to communicate with the remote peer, administrative data is usually included in those messages  Typical example  Protocol receives data from higher layer  Adds own administrative data  Passes the extended message down to the lower layer  Receiver will receive original message plus administrative data  Encapsulating  Header or trailer Layer n Layer n+1 Packet arriving at Layer n+1’s SAP Extended packet passed to layer n Delivered by layer n Packet delivered to Layer n user

63. SS 06, v 1.1KMS - Kap. 9: Rechnernetze63 Protocol stacks  Typically, there are several layers and thus several protocols in a real system  Layers/protocols are arranged as a (protocol) stack  One atop the other, only using services from directly beneath  This is called strict layering Layer 1 Physical medium (layer 0) Layer 1 L1 protocol Layer 2 L2 protocol Layer 3 L3 protocol Layer 4 L4 protocol Layer 1 Physical medium (layer 0) L1 protocol Layer 2 L2 protocol Layer 3 L3 protocol Layer 4 L4 protocol Layer 1 Layer 2 Layer 3 Layer 4 Cross-layer communication Object of current research Not considered here

64. SS 06, v 1.1KMS - Kap. 9: Rechnernetze64 Layers do not care about distributed lower layers  A given layer n+1 does not care about that its lower layer is actually distributed, has remote FSMs, …  Layer n+1 imagines layer n as something that “just works”, has service access points where they are necessary (a “channel object”!)  In reality, layer n of course is distributed in turn, relying on yet lower layers  At the end, the physical medium (layer 0) is transporting data/signals Layer n-1 Ln-1 protocol Layer n Ln protocol Layer n+1 Ln+1 protocol SAP n SAP n-1 Layer n-1 Layer n Layer n+1 SAP n SAP n-1

65. SS 06, v 1.1KMS - Kap. 9: Rechnernetze65 Analogy: Nested layers as nested translations  Layers rely on services of lower layers  Intermediate representation of data changes  Vertical vs. horizontal communication  Vertical: always real  Horizontal: may be real or virtual Horizontal communication Horizontal (real!) communication Vertical comm.

66. SS 06, v 1.1KMS - Kap. 9: Rechnernetze66 Overview  Structuring communication systems into layers  Services  Protocols  Reference models  ISO/OSI  TCP/IP  Standardization

67. SS 06, v 1.1KMS - Kap. 9: Rechnernetze67 How to structure functions/layers in real systems?  Many functions have to be realized  How to actually group them so as to obtain a real, working communication system?  Layering structure and according protocols define the communication architecture  Two main reference models exist  ISO/OSI reference model (International Standards Organization Open Systems Interconnection)  TCP/IP reference model (by IETF – Internet Engineering Taskforce)

68. SS 06, v 1.1KMS - Kap. 9: Rechnernetze68 ISO/OSI reference model  Basic design principles  One layer per abstraction  Each layer has a well-defined function  Choose layer boundaries such that information flow across the boundary is minimized (minimize inter-layer interaction)  Enough layers to keep separate things separate, few enough to keep architecture manageable  Result: 7-layer model  Not strictly speaking an architecture, because protocol details are not specified  Only general duties of each layer are defined

69. SS 06, v 1.1KMS - Kap. 9: Rechnernetze69 ISO/OSI 7-layer reference model (two entities) Network protocol Data link protocol Physical layer protocol PDU: Protocol Data Unit

70. SS 06, v 1.1KMS - Kap. 9: Rechnernetze70 ISO/OSI 7-layer reference model (complete network) End-to-end Chained, local layers

71. SS 06, v 1.1KMS - Kap. 9: Rechnernetze71 7 layers in brief  Physical layer: Transmit raw bits over a physical medium  Data Link layer: Provide a (more or less) error-free transmission service for data frames over a shared medium  Network layer: Solve the forwarding and routing problem for a network  Transport layer: Provide (possibly reliable, in order) end- to-end communication, overload protection, fragmentation  Session layer: Group communication into sessions which can be synchronized, checkpointed, …  Presentation layer: Ensure that syntax and semantic of data is uniform between all types of terminals  Application layer: Actual application, e.g., protocols to transport Web pages

72. SS 06, v 1.1KMS - Kap. 9: Rechnernetze72 ISO/OSI reference model – Critique  The reference model as such, in its structuring of functions into layers, is very influential until today  Actual protocols developed for it are irrelevant in practice  ISO failed in gaining actual market acceptance for its model  Bad timing – competing approaches already in market, lack of industry support  Bad technology – too big, too complex; some design flaws  Bad implementations – initial implementations low quality  Bad politics – ISO/OSI conceived of as a bureaucratic thing

73. SS 06, v 1.1KMS - Kap. 9: Rechnernetze73 TCP/IP reference model  Historically based on the ARPANET, later to become the Internet  Started out as little university networks, which had to be interconnected  In effect, only really defines two layers  Internet layer: packet switching, addressing, routing & forwarding. Particularly for hierarchically organized networks (“networks of networks”) – Internet Protocol (IP) defined  Transport layer: two services & protocols defined  Reliable byte stream: Transport Control Protocol (TCP)  Unreliable datagram: User Datagram Protocol (UDP) In addition, (de)multiplexing  Lower and higher layers not really defined  “Host to host” communication assumed as a given  Applications assumed

74. SS 06, v 1.1KMS - Kap. 9: Rechnernetze74 TCP/IP protocol stack Nothing stated by TCP/IP model

75. SS 06, v 1.1KMS - Kap. 9: Rechnernetze75 TCP/IP – Suite of protocols  Over time, a suite of protocols has evolved around the core TCP/IP protocols So-called “hourglass model”: Thin waist of the protocol stack at IP, above the technological layers

76. SS 06, v 1.1KMS - Kap. 9: Rechnernetze76 Naming & addressing in the TPC/IP reference model  Names: Data to identify an entity  Exist on different levels  Alphanumerical names for machines: info-stud.uni-paderborn.de  Numeric names for a network device  Depends on standard, e.g. Ethernet: 48 bits, hexadecimal notation, example: 08:00:20:ae:fd:7e  Usually called an address (partially justifiable, but actually a bit sloppy)  Names for service access points in an end system: Name of end system plus a numerical identifier for the SAP (a port number): www.google.de:80www.google.de:80  Some of these port numbers are assigned “by convention” for standard SAPs, 80 = web server  Used to distinguish multiple processes/their sockets in a single end system

77. SS 06, v 1.1KMS - Kap. 9: Rechnernetze77 Naming & addressing in the TPC/IP reference model  Address: Data how/where to find an entity  Address of a network device in an IP network: An IP address  IPv4: 32 bits, structured into 4x8 bits  Example: 131.234.20.99 (dotted decimal notation)  Address of a network: Some of the initial bits of an IP address  Note: Other networks (notably, POTS/GSM) have very different naming/addressing architectures!  E.g., a much clearer separation between identity and location of entities, cryptographic protection, …

78. SS 06, v 1.1KMS - Kap. 9: Rechnernetze78 Mapping  Needed: Mapping from name to address  Realized by separate protocols  From alphanumerical name to IP address: Domain Name System (DNS)  From MAC name/address to IP address: Reverse Address Resolution Protocol  Often also useful: Mapping from IP address to MAC name/address: Address Resolution Protocol (ARP) wwwcs.uni-paderborn.de:80 131.234.25.27:80 08:00:20:ae:fd:7e Web server process’ service access point DNS ARP/RARP

79. SS 06, v 1.1KMS - Kap. 9: Rechnernetze79 TCP/IP reference model – Critique  No clear distinction between service, protocol, interface  Reliable byte stream is equated with TCP, although there is a clear difference  Particularly below IP  Very specialized stack, does not allow a generalization to other technologies/situations  Great void below IP  Many ad hoc, wildly hacked solutions in may places, without careful design  Mobility support is a typical area where problems result later on

80. SS 06, v 1.1KMS - Kap. 9: Rechnernetze80 ISO/OSI versus TCP/IP  ISO/OSI: Very useful model, non-existing protocols  TCP/IP: Non-existing model, very useful protocols  Hence: Use a simplified ISO/OSI model, but treat the TCP/IP protocol stack in the context of this model  With suitable add-ons especially for the lower layers

81. SS 06, v 1.1KMS - Kap. 9: Rechnernetze81 Some example protocols  A communication architectures needs standard protocols in addition to a layering structure  And: some generic rules & principles which are not really a protocol but needed nonetheless  Example principle: end-to-end  Example rule: Naming & addressing scheme  Popular protocols of the 5-layer reference model  Data link layer: Ethernet & CSMA/CD  Network layer: Internet Protocol (IP)  Transport layer: Transmission Control Protocol (TCP)

82. SS 06, v 1.1KMS - Kap. 9: Rechnernetze82 Medium Access à la Ethernet  Access to a shared medium – a resource management problem (Betriebsmittelverwaltung)  First idea: Just start transmission whenever anything to say  Problem: Collision, message is lost  Better idea: Listen first – when nobody says anything, start own transmission, else wait  Carrier Sense Multiple Access (CSMA)  Problem: What happens if two people start listening at about the same time? ! Collision!  Even better: Check whether a collision happened during transmission; if so, abort transmission  Carrier Sense Multiple Access with Collision Detection (CSMA/CD) ! Ethernet (IEEE 802.3) is CSMA/CD plus other rules…

83. SS 06, v 1.1KMS - Kap. 9: Rechnernetze83 Repairing errors: Repeat packet  What happens if a packet is lost on the way?  Idea 1: Have the receiver tell the sender that the packet was lost  But how would the receiver know that a packet was on the way in the first place? ! Doesn’t work!  Idea 2: Turn idea 1 upside down – receiver tells sender when a packet has arrived  An acknowledgement  When packet lost, acknowledgement will not arrive ! Sender can wait for acknowledgment, when it not arrives at expected time, resend the packet  A timeout is used, forming an Automated Repeat Request (ARQ) protocol Packet ACK

84. SS 06, v 1.1KMS - Kap. 9: Rechnernetze84 Problem: How can different error situations be distinguished?  How to tell apart:  Looks the same for the sender, but receiver will get different sequences  Receiver needs to know whether a packet is a new one or one that is repeated  Introduce sequence numbers to identify packets

85. SS 06, v 1.1KMS - Kap. 9: Rechnernetze85 Internet protocol (IP)  Network is structured hierarchically to assist in routing/forwarding  “autonomous networks”, “sub-networks”, …  Separate sub-protocols for routing table computation  E.g., Border Gateway Protocol (BGP) between different high-level network regions  Relatively complicated in detail  Basic idea based on e.g. Dijkstra’s all-pairs shortest-path algorithm  Forwarding  Consult routing tables  Relatively straightforward

86. SS 06, v 1.1KMS - Kap. 9: Rechnernetze86 IP packet format  IP packet header:  Payload follows 32 Bit

87. SS 06, v 1.1KMS - Kap. 9: Rechnernetze87 Transmission control protocol  Offered service: Connection-oriented, reliable byte-stream transmission, provides flow & congestion control  Essential protocol mechanisms  Connection establishment via handshaking  Reliability via acknowledgements, timer, retransmissions  Flow control: Receiver can announce how much data it can consume; sender must not send more than this amount  Congestion control: If packets are lost in the network, network is assumed to overloaded ! reduce sending rate  Basic idea: Network is dumb, only offers best-effort forwarding of packets  Added properties (e.g., reliability) have to be implemented in the end system

88. SS 06, v 1.1KMS - Kap. 9: Rechnernetze88 Overview  Structuring communication systems into layers  Services  Protocols  Reference models  Standardization

89. SS 06, v 1.1KMS - Kap. 9: Rechnernetze89 Standardization  To build large networks, standardization is necessary  Traditional organization from a telecommunication/ telephony background  Well established, world-wide, relatively slow “time to market”  Internet  Mostly centered around the Internet Engineering Task Force (IETF) with associated bodies (Internet Architectural Board IAB, Internet Research Task Force IRTF, Internet Engineering Steering Group IESG)  Consensus oriented, heavy focus on working implementations  Hope is quick time to market, but has slowed down considerably in recent years  Manufacturer bodies

90. SS 06, v 1.1KMS - Kap. 9: Rechnernetze90 Standardization – Traditional organizations  ITU – International Telecommunication Union (formerly CCITT und CCIR)  CCITT – Consultative Committee on International Telegraphy and Telephony (Comité Consultatif International Télégraphique et Téléphonique)  CCIR – Consultative Committee on International Radio  CEPT – Conférence Européenne des Administrations des Postes et des Télécommunications  ISO – International Organization for Standardization  DIN – Deutsches Institut für Normung  German partner organization of ISO

91. SS 06, v 1.1KMS - Kap. 9: Rechnernetze91 ISO standardization work  WG-Meetings:  Every 6-9 months  National organizations have time to accept proposed concepts  Then: actual standarization process  DP: Draft Proposal  DIS: Draft International Standard  IS: International Standard  Move a proposal to a higher level by incorporating all dissenting voices and international consensus  Very slow process ISO Technical Committee (TC) Technical Committee (TC) SubCommittee (SC) SubCommittee (SC) Working Group (WG) Working Group (WG)....

92. SS 06, v 1.1KMS - Kap. 9: Rechnernetze92 IETF – http://www.ietf.orghttp://www.ietf.org  IETF is organized in areas and Working Groups  Volunteers from industry, academia, government organizations participate  Drafts/proposal can be made by anybody  An „on-demand“ process  To move beyond draft status, two independent, interoperating implementations are required  Informal voting in working groups  „Humming“  Three meetings a year  Result:  RFC – request for comment, the actual standard  FYI – informal or informational  In June 2005, there are 4114 RFCs  That‘s what the Internet is build on Proposal, draft Proposed Standard Draft Standard Full Standard Experimental Informal

93. SS 06, v 1.1KMS - Kap. 9: Rechnernetze93 Conclusions  To keep complexity of communication systems tractable, division in subsystems with clearly assigned responsibilities is necessary – layering  Each layer (and the communication system as a whole) offers a particular service  Services become more abstract and more powerful the higher up in the layering hierarchy  To provide a service, a layer has to be distributed over remote devices  Remote parts of a layer use a protocol to cooperate  Make use of service of the underlying layer to exchange data  Protocol is a horizontal relationship, service a vertical relationship  Two important reference models how to group functionalities into layers, which services to offer at each layer, how to structure protocols

94. SS 06, v 1.1KMS - Kap. 9: Rechnernetze94 Conclusions  Communication networks have to solve many problems and need a lot of functionality  The most basic of these problems, and an idea about their solution, should have become clear  How to group these functions, how to solve these problems, will be the topic of the remainder of this course

95. SS 06, v 1.1KMS - Kap. 9: Rechnernetze95 An experiment: Constructing a spanning tree  Nodes communicate wirelessly with each other  Goal: Construct a spanning tree, root node attached to laptop LEDs encode level in the tree: Red: Root node Yellow: 1 hop to root Green: 1 hops to root Cyan: 3 hops to root Purple: 4 hops or more

96. SS 06, v 1.1KMS - Kap. 9: Rechnernetze96 Lehrveranstaltungen FG Rechnernetze Projektgruppe KMS IV Rechnernetze V Mobil- kommunikation Leistungs- bewertung/ Simulation Seminar VII VI Proseminar Ad hoc/ Sensor- netze Seminar VIII Advanced Internet Advanced Wireless Analyse- methoden für Netze FestnetzDrahtlos/mobil Methodik Legende:

97. SS 06, v 1.1KMS - Kap. 9: Rechnernetze97 Combinations of duplexing & multiplexing

98. SS 06, v 1.1KMS - Kap. 9: Rechnernetze98

99. SS 06, v 1.1KMS - Kap. 9: Rechnernetze99