DOC PREVIEW
Berkeley ELENG 122 - Internet Design Principles

This preview shows page 1-2 out of 7 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 7 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 7 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 7 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

1 1 EE 122: Internet Design Principles Ion Stoica TAs: Junda Liu, DK Moon, David Zats http://inst.eecs.berkeley.edu/~ee122/ (Materials with thanks to Vern Paxson, Jennifer Rexford, and colleagues at UC Berkeley) 2 Overview  Standardization of protocols  Roles played by end systems  Clients, servers, peer-to-peer  Architecture & layering  The End-to-End Principle & Fate Sharing 3 Protocol Standardization  Ensure communicating hosts speak the same protocol  Standardization to enable multiple implementations  Or, the same folks have to write all the software  Standardization: Internet Engineering Task Force  Based on working groups that focus on specific issues  Produces “Request For Comments” (RFCs)  Promoted to standards via rough consensus and running code  IETF Web site is http://www.ietf.org  RFCs archived at http://www.rfc-editor.org  De facto standards: same folks writing the code  P2P file sharing, Skype, <your protocol here>… 4 End System: Computer on the ‘Net Internet Also known as a “host”… 5 Clients and Servers  Client program  Running on end host  Requests service  E.g., Web browser GET /index.html 6 Clients and Servers  Client program  Running on end host  Requests service  E.g., Web browser  Server program  Running on end host  Provides service  E.g., Web server GET /index.html “Site under construction”2 7 Client-Server Communication  Client “sometimes on”  Initiates a request to the server when interested  E.g., Web browser on your laptop or cell phone  Doesn’t communicate directly with other clients  Needs to know the server’s address  Server is “always on”  Services requests from many client hosts  E.g., Web server for the www.cnn.com Web site  Doesn’t initiate contact with the clients  Needs a fixed, well-known address 8 Peer-to-Peer Communication  Not always-on server at the center of it all  Hosts can come and go, and change addresses  Hosts may have a different address each time  Example: peer-to-peer file sharing  Any host can request files, send files, query to find where a file is located, respond to queries, and forward queries  Scalability by harnessing millions of peers  Each peer acting as both a client and server 9 The Problem  Many different applications  email, web, P2P, etc.  Many different network styles and technologies  Circuit-switched vs packet-switched, etc.  Wireless vs wired vs optical, etc.  How do we organize this mess? 10 The Problem (cont’d)  Re-implement every application for every technology?  No! But how does the Internet design avoid this? Skype SSH NFS Radio Coaxial cable Fiber optic Application Transmission Media HTTP 11 Solution: Intermediate Layers  Introduce intermediate layers that provide set of abstractions for various network functionality & technologies  A new app/media implemented only once  Variation on “add another level of indirection” Skype SSH NFS Packet radio Coaxial cable Fiber optic Application Transmission Media HTTP Intermediate layers 12 Network Architecture  Architecture is not the implementation itself  Architecture is how to organize/structure the elements of the system & their implementation  What interfaces are supported  Using what sort of abstractions  Where functionality is implemented  The modular design of the network3 13 Software System Modularity Partition system into modules & abstractions:  Well-defined interfaces give flexibility  Hides implementation - thus, it can be freely changed  Extend functionality of system by adding new modules  E.g., libraries encapsulating set of functionality  E.g., programming language + compiler abstracts away not only how the particular CPU works …  … but also the basic computational model  Well-defined interfaces hide information  Isolate assumptions  Present high-level abstractions  But can impair performance 14 Network System Modularity Like software modularity, but:  Implementation distributed across many machines (routers and hosts)  Must decide:  How to break system into modules  Layering  What functionality does each module implement  End-to-End Principle  Where state is stored  Fate-sharing  We will address these choices in turn 15 Layering: A Modular Approach  Partition the system  Each layer solely relies on services from layer below  Each layer solely exports services to layer above  Interface between layers defines interaction  Hides implementation details  Layers can change without disturbing other layers 16 Properties of Layers (OSI Model)  Service: what a layer does  Service interface: how to access the service  Interface for layer above  Protocol (peer interface): how peers communicate to achieve the service  Set of rules and formats that specify the communication between network elements  Does not specify the implementation on a single machine, but how the layer is implemented between machines 17 Physical Layer (1)  Service: move information between two systems connected by a physical link  Interface: specifies how to send and receive bits  Protocol: coding scheme used to represent a bit, voltage levels, duration of a bit  Examples: coaxial cable, optical fiber links; transmitters, receivers Transport Network Datalink Physical Session Present. Application 18 (Data) Link Layer (2)  Service:  Enable end hosts to exchange atomic messages with one another  Using abstract addresses (i.e., not just direct physical connections)  Perhaps over multiple physical links  But using the same framing (headers/trailers)  Possible other services:  arbitrate access to common physical media  reliable transmission, flow control  Interface: send messages (frames) to other end hosts; receive messages addressed to end host  Protocols: addressing, routing, Media Access Control (MAC) (e.g., CSMA/CD - Carrier Sense Multiple Access / Collision Detection) Transport Network Datalink


View Full Document

Berkeley ELENG 122 - Internet Design Principles

Documents in this Course
Lecture 6

Lecture 6

22 pages

Wireless

Wireless

16 pages

Links

Links

21 pages

Ethernet

Ethernet

10 pages

routing

routing

11 pages

Links

Links

7 pages

Switches

Switches

30 pages

Multicast

Multicast

36 pages

Switches

Switches

18 pages

Security

Security

16 pages

Switches

Switches

18 pages

Lecture 1

Lecture 1

56 pages

OPNET

OPNET

5 pages

Lecture 4

Lecture 4

16 pages

Ethernet

Ethernet

65 pages

Models

Models

30 pages

TCP

TCP

16 pages

Wireless

Wireless

48 pages

Load more
Download Internet Design Principles
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Internet Design Principles and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Internet Design Principles 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?