Layering & protocol stacks Johan Lukkien Computer Networks 2002/2003 Layering & protocol stacks Johan Lukkien 14-Jan-19 Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Computer Science, System Architecture and Networking

Architectural pattern: layers “The Layers architectural pattern helps to structure applications” that can be decomposed into groups of subtasks in which each group of subtask is at a particular level of abstraction” from “Pattern-oriented software architecture”, Buschmann et.al Layering supports stable interfaces re-use mastering complexity: separation of concerns 14-Jan-19 Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Computer Science, System Architecture and Networking

Layering Packets impose additional structure onto signals... ...Several packets can form again a higher level structure... Network software is organized in layers of protocols, services and interfaces separation of concerns separation of what is provided (the service) from how it is accessed (the interface) and internally realized (the protocol) different layers have different concerns ease of design 14-Jan-19 Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Computer Science, System Architecture and Networking

Layering in communication provided service 14-Jan-19 Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Computer Science, System Architecture and Networking

Protocol stacks 14-Jan-19 Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Computer Science, System Architecture and Networking

Protocol stacks Level k message is payload of level k-1 add headers and trailers of level k-1 Binding: exact description of A: mapping one protocol onto another messages, communication behavior B: mapping abstract functions onto a service interface connecting layers at the interface Tunneling: level k-1 tunnels level k transport without interpretation of payload term ‘tunneling’ usually reserved for a stack in which a service occurs twice 14-Jan-19 Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Computer Science, System Architecture and Networking

OSI reference model Open Systems Interconnection Abstract architecture of communicating systems Names and identifies relevant concepts services, protocols and interfaces service data units (xSDU) and protocol data units (xPDU), x is the layer Introduces layer semantics issues solved by a layer; layer services Description of “how it should be done” 14-Jan-19 Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Computer Science, System Architecture and Networking

The OSI model 14-Jan-19 PSDU SSDU TSDU NSDU DSDU PhSDU Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Computer Science, System Architecture and Networking

TCP/IP model 14-Jan-19 Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Computer Science, System Architecture and Networking

Remarks TCP/IP ‘model’ OSI model OSI protocol stack named after the dominating protocols model constructed after the fact host-to-network not really a layer; just get IP packets across OSI model well-discussed, before designing protocols OSI protocol stack not widely used 14-Jan-19 Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Computer Science, System Architecture and Networking

Some stacks and the OSI model 14-Jan-19 Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Computer Science, System Architecture and Networking

Model in the book... 14-Jan-19 Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Computer Science, System Architecture and Networking

Communication modes Sender and receiver One to one One to many un-addressed: broadcast collection of destinations: multicast Many to one messages appear at receiver in undetermined order Fragmentation & synchronization send and receive of message combined fixed units (packets, frames, cells) streaming synchronization on availability of data and buffers 14-Jan-19 Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Computer Science, System Architecture and Networking

Communication modes Connections Message existence Timing Connection oriented: Setup connection, communicate, destroy connection control: reliability, flow, congestion Connection less: Single shot: just send a message/packet Message existence Persistent: subsystem will deliver messages Transient: message life depends on life of sender, receiver, subsystem Timing Time-independent Time-dependent (real-time) soft real-time, hard real-time 14-Jan-19 Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Computer Science, System Architecture and Networking

Issues, to be resolved by the layers Error correction Flow control Addressing Multiplexing Naming Congestion control Mobility Routing Fragmentation Security .... 14-Jan-19 Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Computer Science, System Architecture and Networking

Layer semantics trade-off’s Important design decision: the choice in which level to solve a particular issue too high: inefficient error correction at the application layer broadcasting at the transport layer too low: issue may re-occur multiplexing at the link layer connection orientation below the network layer Transparency: hiding lower layer details good for portability, generality etc. but must be considered carefully e.g. mobility, location, multi-casting 14-Jan-19 Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Computer Science, System Architecture and Networking

Layer generality & re-usability Layer k cooperates with many different types layers k-1 moderate required service pitfall: layer becomes complex and large Layer k provides useful services to many different types k+1 powerful provided service must be possible to indicate several next layers pitfall: layer becomes complex and large Hence, work towards standardization as quickly as possible Service required by layer k 14-Jan-19 Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Computer Science, System Architecture and Networking

Definition: service Service: an overall functionality (semantics) of an object. Service quality: non-functional properties of a service (e.g. speed, reliability, ...). Service interface: actions (“primitives”) and responses that make the service available; these responses can be autonomous (“events”). In addition, a specification that describes their effect on state variables and parameters, as well as their results; describes rules as how and in what sequence to call them; describes the functional and non-functional properties of sequences of calls. 14-Jan-19 Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Computer Science, System Architecture and Networking

Service examples (cnt’d) Typically, the communication modes Quality dimensions reliable, acknowledged, guaranteed bandwidth, low latency 14-Jan-19 Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Computer Science, System Architecture and Networking

Example: primitives for connection oriented service 14-Jan-19 Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Computer Science, System Architecture and Networking

Service examples (cnt’d) Frame relay: connection oriented no error or flow control typically, for connecting LANs X.25: connection oriented, typically across phone lines still supported in e.g. GPRS 14-Jan-19 Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Computer Science, System Architecture and Networking

Definition: protocol Protocol: A formal set of rules that dictates how information exchange as well as interaction between objects (can be devices, execution threads, etc.) should take place. The rules specify the format of the messages exchanged; a number of different protocol states and what messages are allowed to be sent in each state; these states determine, among others, the order of the messages. timing constraints and other non-functional properties, if any. 14-Jan-19 Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Computer Science, System Architecture and Networking

Exercises Exercises 11, 12, 13, 19, 20 on p82 Discuss the transmission of a letter through the postal system. Describe service, interface and protocol. Discuss the trade-offs of providing reliable versus datagram service at the data link layer when the transport layer must provide reliable connection oriented service. Take into account the probability of packet loss per link the number of hops the delay needed to judge when a retransmission is needed the resulting throughput at the transport layer 14-Jan-19 Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Computer Science, System Architecture and Networking