1 / 39

Layering Revisited EECS 122: Lecture 27

Layering Revisited EECS 122: Lecture 27. Department of Electrical Engineering and Computer Sciences University of California Berkeley. Today. Review Layering End-to-End argument How functions are placed in layers VLANs, MPLS, Error Correction, Congestion Control

teixeira
Download Presentation

Layering Revisited EECS 122: Lecture 27

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Layering RevisitedEECS 122: Lecture 27 Department of Electrical Engineering and Computer Sciences University of California Berkeley

  2. Today • Review • Layering • End-to-End argument • How functions are placed in layers • VLANs, MPLS, Error Correction, Congestion Control • The role of Middleboxes and Layering • Firewalls, VPN Gateways Abhay K. Parekh: EECS122 Lecture 27

  3. Why Network Architecture • Most networks are extremely complicated • Multiple network builders • Evolving functionality • Like understanding the “plan” of an old city! • Yet, there are principles which have governed network evolution • Understanding these principles helps us • Make sense of network “chaos” • Identify ways to improve the network • Identify ways to build entirely new networks Abhay K. Parekh: EECS122 Lecture 27

  4. Layering • Modular design with a twist Yellow boxes “lower” level • Well defined interfaces • Information Hiding allows for multiple module implementations C B A D Abhay K. Parekh: EECS122 Lecture 27

  5. Layering: The Twist Each module is implemented distributively… Node 2 Node 1 c b b c How to address? Package messages? a a D d d Peer modules communicate and determine function jointly Abhay K. Parekh: EECS122 Lecture 27

  6. How can this be applied to a communications network? • What is the module architecture? • What are the interfaces? • How are the peer process links implemented? Node 2 Node 1 c b b c a a D d d Abhay K. Parekh: EECS122 Lecture 27

  7. FH FH PH PH TH Data TH Data TH Data Data Network Layers Application Application Data Transport Transport Asynchronous routed path Asynchronous routed path Network Network Network PH TH Data PH TH Data Asynchronous reliable bit pipe Asynchronous reliable bit pipe Data Link Control Data Link Control Data Link Control Synchronous unreliable bit pipe Synchronous unreliable bit pipe PhysicalInterface PhysicalInterface PhysicalInterface Physical Link Physical Link End Node End Node Subnet Node Each layer just looks at its own header Abhay K. Parekh: EECS122 Lecture 27

  8. The Internet • The network designed to interconnect various networks which heterogeneous in • Speed • Reliability • Cost • In connecting two hosts, one may traverse several intervening networks: most end-to-end problems are interdomain. • Designed for “best effort” delivery. • End-to-End argument: Place a function at the highest layer at which it can be correctly implemented • E.g. Flow control is at the transport layer Abhay K. Parekh: EECS122 Lecture 27

  9. BGP HTTP RTP TFTP Application TCP UDP TCP UDP IP Network IP Ethernet FDDI Token Etc. Internet Layering • Almost Any kind of application can write directly on IP • Including new transport protocols • IP cannot be avoided • As long as the routers speak IP, any application that can make do with datagram service can be written and implemented on the end devices. • No co-ordination, standards activity etc. is required!! Abhay K. Parekh: EECS122 Lecture 27

  10. The central role of encapsulation • Layer-based processing • Each layer just looks at its own header • E.g. routers forward by looking at the layer 3 (IP) header • Internetwork connection • Multiple layer n protocols operate on the same n+1 layer payload • E.g. a TCP session can run over several kinds of layer 3 networks • Overlay tunneling • Links of network at layer n+1 are paths of network at layer n Abhay K. Parekh: EECS122 Lecture 27

  11. b a Internetwork Connection Data A B Networks A and B have different layer 3 protocols Abhay K. Parekh: EECS122 Lecture 27

  12. b a Internetwork Connection A B A Data Network Layer header in Network A Abhay K. Parekh: EECS122 Lecture 27

  13. b a Internet B GA GB Internetwork Connection A A Data Abhay K. Parekh: EECS122 Lecture 27

  14. b a Internet B GA GB Internetwork Connection A Data IP Encapsulate with IP header Abhay K. Parekh: EECS122 Lecture 27

  15. b a Internet B GA GB Internetwork Connection A A Data B IP The internet protocol is network layer Abhay K. Parekh: EECS122 Lecture 27

  16. b a A Data Internet B GA GB Internetwork Connection A B B The internet protocol is network layer Network Layer header in network B Abhay K. Parekh: EECS122 Lecture 27

  17. b a Internet B GA GB Internetwork Connection Any transport layer protocol works Data A Abhay K. Parekh: EECS122 Lecture 27

  18. Overlay Tunneling C 5 7 4 8 6 11 2 10 A 3 1 13 B 12 Overlay Network Nodes Abhay K. Parekh: EECS122 Lecture 27

  19. Overlay Tunneling C 5 7 • Overlay Networks are extremely popular • MBONE, Akamai, Virtual Private Networks, Napster, Gnutella • Overlay Networks may even peer! 4 8 6 11 2 10 A 3 1 13 B 12 Abhay K. Parekh: EECS122 Lecture 27

  20. Not All Hosts are created Equal • End Hosts • PCs • Sensors • PDAs • Actuators • Network Hosts • Routers and Switches • Bridges • Directory Servers • Middle Boxes • Firewalls • Caches • Network Address Translator Devices • Application Level Multicast Gateways Abhay K. Parekh: EECS122 Lecture 27

  21. Host-Network Division Devices “in the network” may run protocols inside the network cloud at all layers! C D X Network Cloud R S B A E Each host interfaces to the “network cloud”. Abhay K. Parekh: EECS122 Lecture 27

  22. Host-Network Division Devices “in the network” may run protocols inside the network cloud at all layers! C D X Network Cloud R S B A S V E • Each host interfaces to the “network cloud”. • Similarly local network (e.g. berkeley.edu) may interface to a WAN. • The two networks do not always implement the same function at • the same layer! Abhay K. Parekh: EECS122 Lecture 27

  23. Function Placement • Two important questions • Which layer should it be implemented at • Try to use the end-to-end argument • Which kinds of hosts should it be implemented on? • Three Examples • Forwarding below level 3 • Error recovery • Congestion Control Abhay K. Parekh: EECS122 Lecture 27

  24. Bridge forwards frames • Combined network looks like one ethernet at one level • Yet three different logical networks! • All of this below layer 3! Abhay K. Parekh: EECS122 Lecture 27

  25. Why use VLANs? • E.g. why not layer 3 multicast? • Quote from leading adapter card vendor • Because “layer 3 routers are slow, complicated and expensive”. • Standard ethernet multicast is essentially broadcast (i.e. each transmission flooded to all nodes) • VLAN is a better layer 2 multicast • Everything happens in frames – no IP packets needed • Why not use VLANs in the wide area? • Lesson: The layer a function is in depends on performance requirements and scale not just correctness! Abhay K. Parekh: EECS122 Lecture 27

  26. VC3 In, VC Out, VC 1, 1 4, 1 1, 2 4, 3 2, 1 4, 2 MPLS • Virtual Circuit Forwarding is faster because it uses VCI labels • LPM not required on the table VC1 1 4 1 4 VC1 VC2 VC2 VC1 2 3 3 2 VC1 VC2 VC1 …. Abhay K. Parekh: EECS122 Lecture 27

  27. VC3 In, VC Out, VC 1, 1 4, 1 1, 2 4, 3 2, 1 4, 2 MPLS • Virtual Circuit Forwarding is faster because it uses VCI labels • LPM not required on the table • Use VC switching to make several physical links look like one to the IP layer • QoS posible as well! VC1 A 1 4 1 4 VC1 VC2 VC2 VC1 2 3 3 2 B VC1 VC2 VC1 E D …. Abhay K. Parekh: EECS122 Lecture 27

  28. MPLS • Virtual Circuit Forwarding is faster because it uses VCI labels • LPM not required on the table • Use VC switching to make several physical links look like one to the IP layer • QoS posible as well! A High Speed, Ultra Reliable Links B E D …. Abhay K. Parekh: EECS122 Lecture 27

  29. Error Recovery • Example: File Transfer • Where can errors occur? • On the communication channel • Intermediate devices such as a router • Disk access on the end-host • TCP recovers from errors of type 1 and 2. • But can’t the function be correctly implemented at the application layer? • In fact TCP misses errors of type 3 Abhay K. Parekh: EECS122 Lecture 27

  30. Error correction is implemented at almost every layer! • At the ftp level to check for errors of type 3 • At the transport layer to check for errors of type 2 and 3 • At the network layer to check for errors of type 2 in the header • At the link layer on unreliable links such as wireless • At the physical layer to alleviate the effects of clock skews and noise… Abhay K. Parekh: EECS122 Lecture 27

  31. Why at multiple layers? • Each layer introduces its own errors • E.g. packet loss due to buffer overflow is a layer 3 error • Performance • Errors can be detected and corrected much faster at the lower layers • Likelihood • A network path might include optical and wireless links. • Only check at the link level for the wireless links • Complexity • If the function is hard to implement (expensive or just difficult to get right) then it is likely to be pushed away from the application layer • E.g. TCP does most of the error recovery for FTP Abhay K. Parekh: EECS122 Lecture 27

  32. Congestion Control • The transport protocol detects lost packets • If the links are reliable then these losses are due to congestion • Should congestion control just be implemented at the transport layer? • Problem: Congestion is detected only after it has occurred • One badly behaving flow creates congestion for many flows • All of the flows detect congestion and take action by reducing their rates • Can’t communicate across flows since we are at the transport layer • Poor/unfair utilization of the network results Abhay K. Parekh: EECS122 Lecture 27

  33. The Network Layer should also be involved • Two approaches • Hop-by-Hop Flow control: Run a similar flow control protocol between adjacent routers on the path • proceeds independently of the transport protocol • Network layer communicates with the transport layer by changing bits in the header • This couples the network and transport layers • Explicit Congestion Notification (ECN) • The routers also take action • Based on ECNs marked by upstream routers • By dropping the packets intelligently • Neither approach widely deployed even though everybody agrees at least one is necessary. Why? Abhay K. Parekh: EECS122 Lecture 27

  34. Why do very few new features get implemented in Routers • The network layer is already to complicated • Forwarding • Route Computation • Performance and Policy based metrics • Peering • Backward compatibility • Cost is computed on a “bits-per-port” basis. Doesn’t matter if the feature improves user performance • No real incentive to add the kinds of functions • Two kinds of routers emerging • Edge routers: easier to get new function incorporated • Core routers: forget about it! Abhay K. Parekh: EECS122 Lecture 27

  35. Middleboxes • Hosts positioned between the end hosts and network hosts but invisible at layers 4 down. • Middleboxes often rewrite packet headers • Represent aggregation points (i.e. handle many flows from different links) just the way routers so. • Two kinds • Enhance performance • E.g. Caches • Add new functions • E.g. Firewalls, Layer 4-7 switches, Wide Area load balancers • Middleboxes may communicate via an overlay network • E.g. Virtual Private Networks, Content Distribution Networks • Middleboxes have proliferated in the network • BUT Internet protocols and layers were not designed with Middleboxes in mind… Abhay K. Parekh: EECS122 Lecture 27

  36. Middleboxes confound layering • Example #1 • Two hosts decide that they want to open port #82 to run a new protocol • The firewall blocks this communication • The two hosts decide to run their protocol over http (port 80) • The firewall lets this through since it allows http traffic • Result: The two hosts are able to run their protocol • HTTP may be a poor choice to run it on and may congest resouces • Lesson: Middleboxes can hamper the creation of efficient new protocols Abhay K. Parekh: EECS122 Lecture 27

  37. Middleboxes confound layering • Example #2: • Two VPN gateways communicate via an IPSEC tunnel • Intercept an IP packet from the sender domain • Encrypt the packet • Encapsulate it with another IP header • Send it to the appropriate VPN gateway at the receiver domain • Remove the IP header and decrypt the original IP packet • Send to the receiving host • What if a router sets the ECN bit as the packet goes between gateways • This information never gets to the receiving/sending host! Abhay K. Parekh: EECS122 Lecture 27

  38. More on Middleboxes • At what layers do they operate? • Depends on which headers read/changed. • E.g. Many firewalls include Network Address Translation (layer 3), but also keep state on TCP and HTTP • Do they compromise security? • They often exploit the possibility to engage in man-in-the-middle attacks, so yes. • Are they going away? • No way! Abhay K. Parekh: EECS122 Lecture 27

  39. Conclusions • Layers are very useful in thinking about protocols • But Network architecture is complicated and this is reflected in the layering • A function (such as multicast) may be mapped at one of several different layers depending on performance requirements and network scale • A function might be mapped to multiple layers • Each layer may perform the function independently • E.g. error correction • The layers may communicate to accomplish the function jointly • Congestion control • Middleboxes are essential parts of the network infrastructure • Layering was not designed with them in mind • This leads to numerous complications that threaten scale and innovation • The end-to-end argument is a fundamental principle of network design but it is often trumped by alternatives which offer better performance, cost and/or complexity . Abhay K. Parekh: EECS122 Lecture 27

More Related