computer networks group universität paderborn konzepte und methoden der systemsoftware kapitel 9:...

Computer Networks GroupUniversität Paderborn

Konzepte und Methoden der Systemsoftware Kapitel 9: Rechnernetze

Holger Karl

SS 06, v 1.1 KMS - Kap. 9: Rechnernetze 2

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


Overview

Examples Direct connection between two devices Multiple devices Errors


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?

A BKSenden Empfangen

Rechnergrenze

A BKSenden Empfangen

Rechnergrenze

A B

Rechnergrenze

Kanalobjekt-Schnittstelle


Datentransport Ersatzinstanzen (stubs)Kanalobjekt

als „Brücke“

A B

Rechnergrenze



Datentransport Ersatzinstanzen (stubs)

Ersatzinstanzen (stubs)Kanalobjekt

als „Brücke“


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/


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

?


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

InformationFacts, concepts,

ideas, …

DataFormalized

representation of information

Conventionsfor

representation

Abstractworld


Overview

Examples Direct connection between two devices

Signals Low-level communication properties Duplex

Multiple devices Errors


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


Conventionsfor

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

Conventionsfor

representation

Abstractworld

Signals

Physicalworld


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?


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 oftransmission

End oftransmission

Delay d

Tim

e

Distance


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 oftransmission

Tim

e

Delay d

Example (transcontinental): Data rate 100 Mbit/s Delay 6000km/(2/3c) ¼

0.03 s d*r ¼ 3 Mbit (in the wire)


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


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 ! A A ! BA ! B B ! AB ! A B ! A

Time division duplex – TDD



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

Freq

uen

cy

Frequency Division Duplex – FDD



A ! B

A B

B ! A

A B

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


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


Overview

Examples Direct connection between two devices Multiple devices

Multi-hop connections Switching Forwarding Multiplexing Multiple access Routing

Errors


But there are more than two computers/telephones

Connect each telephone/computer with each other one?

With four computers:

With eleven computers:

…


Beirut connections

Connecting many phones in real life


Beirut connections


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


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


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


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?


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


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 XBuffer

To Y

To Z

To Y To ZTo Z

Pick next hop

To Y To X To Z


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


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 ZTo Z

To Z

To Z

(in frequency 1)

(in frequency 2)


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?


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


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!

Shared!


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


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


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


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

M P Z

U 2 3 4

V 3 2 3

X 4 3 2

Y 4 4 3

Destination

Neig

hb

or

Routing table of W


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


Overview

Examples Direct connection between two devices Multiple devices Errors


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


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


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!


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)

MOI = Million Object Code Instructions

1960 1970 1980 1990 2000

60 MOI

50 MOI

40 MOI

30 MOI

20 MOI

10 MOIMercury

Gemini

Apollo

LunarMissionControl

SpaceShuttle

EWSD-APSDBP-14

EWSD-APSWM

EWSD-APS USA(Docu: 750.000 DIN-A4)

B-ISDN(S9) geschätzt


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


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


Overview

Structuring communication systems into layers Services

Service primitives Properties of service primitives Example: sockets

Protocols Reference models Standardization


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


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


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


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


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!


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!


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


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


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


Overview

Structuring communication systems into layers Services Protocols Reference models Standardization


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 Bits

SAP of Layer 1

“Stubs” for channel objects


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 Bits

SAP of Layer 1

Identical rules of

operation

Matching rules of

operation


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 Use

Protocol

Use Use Protocol is

implementation of the service

Not visible to service user


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


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


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


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 1L1 protocol

Layer 2 Layer 2L2 protocol



Layer 1

Physical medium (layer 0)

L1 protocol

Layer 2L2 protocol

Layer 3L3 protocol

Layer 4L4 protocol

Layer 1

Layer 2

Layer 3

Layer 4Cross-layer communication

Object of current research

Not considered here


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


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

Verticalcomm.


Overview

Structuring communication systems into layers Services Protocols Reference models

ISO/OSI TCP/IP

Standardization


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)


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


ISO/OSI 7-layer reference model (two entities)

Network protocol

Data link protocol

Physical layer protocol

PDU:Protocol Data Unit


ISO/OSI 7-layer reference model (complete network)En

d-to

-en

dC

hain

ed

, local la

yers


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


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


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


TCP/IP protocol stack

Nothing statedby TCP/IP model


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


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

http://www.google.de/


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, …


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


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


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


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)


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…


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


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


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


IP packet format

IP packet header:

Payload follows

32 Bit


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


Overview

Structuring communication systems into layers Services Protocols Reference models Standardization


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


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


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

ISOISO

Technical Committee(TC)

Technical Committee(TC)

SubCommittee(SC)

SubCommittee(SC)

Working Group(WG)

Working Group(WG)

. . . . . . . .

. . . . . . . .

. . . . . . . .


IETF – http://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, draftProposal, draft

Proposed StandardProposed Standard

Draft StandardDraft Standard

Full StandardFull Standard

ExperimentalExperimental

InformalInformal

http://www.ietf.org/


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


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


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 nodeYellow: 1 hop to root Green: 1 hops to rootCyan: 3 hops to rootPurple: 4 hops or more


Lehrveranstaltungen FG RechnernetzeP

roje

ktgru

ppe

KMSIV

RechnernetzeV

Mobil-kommunikation

Leistungs-bewertung/Simulation

SeminarVII

VI Proseminar

Ad hoc/Sensor-netze

SeminarVIIIAdvancedInternet

AdvancedWireless

Analyse-methoden für Netze

Festnetz Drahtlos/mobil MethodikLegende:


Combinations of duplexing & multiplexing

computer networks group universität paderborn konzepte und methoden der systemsoftware kapitel 9:...

Documents