Layering and the network layer CS168, Fall 2014 Sylvia Ratnasamy h?p://inst.eecs.berkeley.edu/~cs168/fa14/ Today ‣ What is a network made of? ‣ How is it shared? ‣ How do we evaluate a network? ‣ How is communicaon architected? ‣ BREAK ‣ The network layer 2 Internet Layers Applica1ons …built on… Reliable (or unreliable) transport …built on… L7 Application Best-effort global packet delivery L4 Transport …built on… L3 Network L2 Data link Best-effort local packet delivery L1 Physical …built on… Physical transfer of bits Protocols and Layers L7 Application Application L7 L4 Transport Transport L4 L3 Network Network L3 L2 Data link Data link L2 L1 Physical Physical L1 Communication between peer layers on different systems is defined by protocols Protocols at different layers L7 Application SMTP HTTP DNS NTP L4 Transport TCP UDP L3 Network IP L2 Data link Ethernet FDDI PPP L1 Physical optical copper radio PSTN There is just one network-layer protocol! L7 Application Application L7 L4 Transport Transport L4 L3 Network Network L3 L2 Data link Data link L2 L1 Physical Physical L1 What gets implemented where? What gets implemented at the end systems? l Bits arrive on wire, must make it up to applicaon l Therefore, all layers must exist at host! What gets implemented in the network? l Bits arrive on wire à physical layer (L1) l Packets must be delivered across links and local networks à datalink layer (L2) l Packets must be delivered between networks for global delivery à network layer (L3) l The network does not support reliable delivery l Transport layer (and above) not supported Simple Diagram l Lower three layers implemented everywhere l Top two layers implemented only at hosts Applica1on Applica1on Transport Transport Network Network Network Datalink Datalink Datalink Physical Physical Physical End system Switch End system A closer look: end-system l Applicaon l Web server, browser, mail, game l Transport and network layer l typically part of the operang system l Datalink and physical layer l hardware/firmware/drivers What gets implemented in the network? l Bits arrive on wire à physical layer (L1) l Packets must be delivered across links and local networks à datalink layer (L2) l Packets must be delivered between networks for global delivery à network layer (L3) l Hence: l switches: implement physical and datalink layers (L1, L2) l routers: implement physical, datalink, network layers (L1, L2, L3) A closer look: network link switch Internet Service Provider 1 2 A closer look: network link switch routers switch Internet Service Provider 1 3 Switches vs. Routers l Switches do what routers do but don’t parMcipate in global delivery, just local delivery l switches only need to support L1, L2 l routers support L1-L3 l Won’t focus on the router/switch disMncMon l when I say switch, I almost always mean router l almost all boxes support network layer these days App msg msg H Transport t msg Ht msg H H H H Network n t msg n t msg Hn Ht msg Link Hl Hn Ht msg Hl Hn Ht msg Hl Hn Ht msg Physical Alice Router Bob Logical Communicaon l Layers interacts with peer’s corresponding layer Applica1on Applica1on Transport Transport Network Network Network Datalink Datalink Datalink Physical Physical Physical Host A Router Host B Physical Communicaon l Communicaon goes down to physical network l Then up to relevant layer Applica1on Applica1on Transport Transport Network Network Network Datalink Datalink Datalink Physical Physical Physical Host A Router Host B A Protocol-Centric Diagram host host HTTP message HTTP HTTP TCP segment TCP TCP router router IP packet IP packet IP packet IP IP IP IP Ethernet Ethernet SONET SONET Ethernet Ethernet interface interface interface interface interface interface Why layers? l Reduce complexity l Improve flexibility 19 Why not? l sub-opMmal performance l cross-layer informaon oaen useful Ø several “layer viola,ons” in pracce 20 l What physical infrastructure is already available? l Reserve or on-demand? l Where’s my delay coming from? l What’s the right set of layers? 21 Backing up… L7 Application SMTP HTTP DNS NTP at ends L4 Transport TCP UDP L3 Network IP In L2 Data link Ethernet FDDI networkPPP L1 Physical optical copper radio PSTN Why is this architecture good? Architectural Wisdom l Benefits of layering l reduce complexity, increase flexibility l “narrow waist” l simple, minimal requirements for interoperability l “smart ends, dumb network” l No applicaon knowledge in network à more general l Minimal state in the network à more robust to failure Architectural Wisdom l David D. Clark (MIT) l Chief protocol architect for the Internet from 1981 l Co-authored two classics l “End-to-End Arguments in System Design” (1981) l “The Design Philosophy of the DARPA Internet Protocols” (1988) Example: Reliable File Transfer Host A Host B App App OS OK OS l SoluMon 1: make each step reliable, and string them together to make reliable end-to-end process l SoluMon 2: end-to-end check and retry Discussion l SoluMon 1 is incomplete l What happens if any network element misbehaves? l Receiver has to do the check anyway! l SoluMon 2 is complete l Full funcMonality can be enMrely implemented at applicaon layer with no need for reliability from lower layers End-to-end argument: Intuion l Some applicaon requirements can only be correctly implemented end-to-end l reliability, security, etc. l ImplemenMng these in the network is hard l every step along the way must be fail proof l End-systems l Can sasfy the requirement without network’s help l Will/must do so, since they can’t rely on the network End-to-End Arguments in Clark’s words “The funcon in ques,on can completely and correctly be implemented only with the knowledge and help of the applica,on at the end points of the communica,on system. Therefore, providing that funcon as a feature of the communica,on system itself is not possible. (Some,mes an incomplete version of the funcon provided by the communica,on system may be useful as a performance enhancement.)” Recap l ImplemenMng funcMonality (e.g., reliability) in the network l Doesn’t reduce host implementaon complexity l Does increase network complexity l Decreases generality (of the network) l However, implemenMng funcMonality in the network can improve performance in some cases l e.g., consider a very lossy link Commonly used examples l Error handling in file transfer l End-to-end, versus in-network encrypMon l The parMMon of work between TCP and IP for reliable packet delivery l What about Quality of Service (QoS)? l Communicaon throughput or delay guarantee Some consequences l In layered design, the E2E principle provides guidance on which layers are implemented where l “Dumb” network and “smart” end systems l Oaen credited as key to the Internet’s success l “Fate sharing” l Store state at the system enMMes that rely on the state l Oaen translated to keeping state out of routers Cracks in the E2E argument? l Ignores incenMves of different stakeholders l e.g., ISP looking for new revenue-generang services l e.g., users looking for a performance boost l SomeMmes we don’t trust the end-systems to do the job l e.g., firewalls, intrusion detecMon systems Recap: architectural decisions l How to break system into modules? l Classic decomposiMon into tasks l Where are modules implemented? l Hosts? Routers? Both? l Where is state stored? l Hosts? Routers? Both? Leads to three guiding principles l How to break system into modules? l Layering l Where are modules implemented? l End-to-end principle l Where is state stored? l Fate-sharing BREAK! .