Computer Networks 2002/2003

1. Computer Networks2002/2003 Layering & protocol stacks Johan Lukkien Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Computer Science, System Architecture and Networking

2. 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 Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Computer Science, System Architecture and Networking

3. 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 Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Computer Science, System Architecture and Networking

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

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

6. 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 Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Computer Science, System Architecture and Networking

7. 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” Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Computer Science, System Architecture and Networking

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

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

10. Remarks • TCP/IP ‘model’ • 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 Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Computer Science, System Architecture and Networking

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

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

13. 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 Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Computer Science, System Architecture and Networking

14. Communication modes • Connections • 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 Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Computer Science, System Architecture and Networking

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

16. 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 Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Computer Science, System Architecture and Networking

17. 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 Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Computer Science, System Architecture and Networking

18. 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. Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Computer Science, System Architecture and Networking

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

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

21. 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 Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Computer Science, System Architecture and Networking

22. 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. Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Computer Science, System Architecture and Networking

23. 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 Johan J. Lukkien, j.j.lukkien@tue.nl TU/e Computer Science, System Architecture and Networking