Networking essentials

316 views

Published on

Brief history of the Internet

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
316
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
11
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Networking essentials

  1. 1. CS144  An Introduc/on to Computer Networks   What the Internet is   4 Layer Model   Nick McKeown  Professor of Electrical Engineering   and Computer Science, Stanford University CS144, Stanford University  1 
  2. 2. The 4 Layer Internet Model   Applica/on  Transport  Network  Link CS144, Stanford University  2 
  3. 3. Peer layers communicate  A  B  Applica/on  Applica/on  Transport  Transport  Network  Network  Network  Network  Link  Link  Link  Link CS144, Stanford University  3 
  4. 4. Encapsula/on  A  Applica/on  Transport  Network  Network  Link  Link CS144, Stanford University  4 
  5. 5. Peer layers communicate  B  Applica/on  Transport  Network  Network  Link  Link CS144, Stanford University  5 
  6. 6. A few last words… CS144, Stanford University  6 
  7. 7. Where do the different layers run?  Applica/on  Transport  Network  Link CS144, Stanford University  7 
  8. 8. Why is the Network Layer oPen  called “Layer 3”?  h-p  Applica/on  Applica/on  ASCII  Presenta/on  Session  Transport  TCP  Transport  Network  IP  Network  Link  Ethernet  Link  Physical  The 4‐layer Internet model  The 7‐layer OSI Model CS144, Stanford University 
  9. 9. <The End> CS144, Stanford University  9 
  10. 10. CS144  An Introduc/on to Computer Networks  What the Internet is  A very brief history of networking   and the Internet  Nick McKeown  Professor of Electrical Engineering   and Computer Science, Stanford University CS144, Stanford University  1 
  11. 11. Outline  Brief history of networking  Brief history of the Internet CS144, Stanford University  2 
  12. 12. Fire Beacons  Flags  Carrier Pigeons  Semaphore telegraphs  Telephone  Heliographs: sun’s   Human Messengers    Chappe (France)  rays & reflector  Horse Relays …    Edelcrantz (Sweden)  Internet  Telescopes  1,000 BC  0  1800 AD  Today CS144, Stanford University  3 
  13. 13. The Telegraph CS144, Stanford University  4 
  14. 14. Four steps of inven/on  (2,000 BC) Systems to signal a small set of pre‐defined  messages, e.g. beacons.  (1600s) Systems to transmit arbitrary messages, e.g. by  encoding the alphabet.  (1700s) Numeric codes for common words and phrases.  “Compression”.  (1700s) Codes for control signals. “Protocols”. CS144, Stanford University  5 
  15. 15. Protocol Signals by 1800  1.  Ini/aliza/on  2.  Error control: erase, resend.  3.  Rate control: “faster/slower”.  4.  Flow control: stop/wait, selec/ve‐repeat.  CS144, Stanford University  6 
  16. 16. Telephone networks in 1900  1.  (1897) Alexander Graeme Bell made the first  telephone call CS144, Stanford University  7 
  17. 17. Outline  Brief history of Networking  Brief history of the Internet CS144, Stanford University  8 
  18. 18. Parallel beginnings  J.C.R. Licklider describes an  Four nodes  Intergalac/c Network connec/ng  interconnected  everyone on the globe.   (UCLA, SRI, UCSB,  Utah)  RAND (Paul Baran)  Packet switching for  survivable networks.  DARPA (Roberts)  MIT (Kleinrock) First  plans for  paper on packet  “ARPANET”.  switching theory.  WAN connects two /me‐ NPL, UK (Davies)   sharing computers  First “IMPs” (BBN).  Packet network.  1960  1965  1966  1968 CS144, Stanford University  9 
  19. 19. TCP/IP  deployed   NSFNET, etc.   New networks appear:  IBM SNA, ALOHAnet,  Cisco and IETF  Cyclades (France).  started  “Internehng” and TCP  born (DARPA), led by  Vint Cerf and Bob Kahn.  1st Web browser  200 hosts on  100,000 hosts  ARPAnet   on Internet   1970  1980  1990 CS144, Stanford University  10 
  20. 20. Useful References  1.  The Early History of Data Networks  G. J. Holzmann, B. Pehrson, IEEE Press 1994.  2.  The Design Philosophy of the   DARPA Internet Protocols.  D. Clark, ACM Sigcomm 1988  3.  Brief History of the Internet  B. M. Leiner, V. Cerf, D. D. Clark et al.  hjp://www.internetsociety.org/internet/internet‐51/history‐internet/brief‐history‐internet CS144, Stanford University  11 
  21. 21. <The End> CS144, Stanford University  12 
  22. 22. Principle: LayeringCS144, Stanford University 1
  23. 23. File Transfer • Data format • Packetization • Reliability, error checking • Congestion and flow control • Packet delivery and routing • Link delivery • Signal modulation and framingCS144, Stanford University 2
  24. 24. Layering • Decompose communication into a set of smaller, well-defined components • Components build on top of one another: they layer • Each layer has a well-defined interface and clear responsibilities ▶ Routing layer does not worry about application ▶ Application layer does not worry about how signals represented • Each layer can evolve independentlyCS144, Stanford University 3
  25. 25. Layering Transport Network LinkCS144, Stanford University 4
  26. 26. OSI Model 7. Application 6. Presentation 5. Session 4. Transport segments 3. Network packets 2. Link frames 1. Physical bits/bytesCS144, Stanford University 5
  27. 27. Layering Principle • Decompose communication into layers of abstraction • Separation of concerns • Each layer can evolve independentlyCS144, Stanford University 6
  28. 28. Principle: Encapsulation
  29. 29. Layering ApplicationPresentation • Separation of concerns and responsibilities Session • Allows each service to evolve independently Transport • Examples: Network ▶ Transport: inter-application communication ▶ Link: inter-host communication on a shared link Link Physical
  30. 30. Encapsulation ApplicationPresentation • How layering manifests in data representation • Layer N data is payload to layer N-1 Session • Example: Transport ▶ HTTP (web) application payload in Network ▶ a TCP transport segment in ▶ an IP network packet in Link ▶ an Ethernet link frame. Physical application data Network Transport Link
  31. 31. Encapsulation Flexibility • Encapsulation allows you to layer recursively • Example: Virtual Private Network (VPN): ▶ HTTP (web) application payload in ▶ a TCP transport segment in ▶ an IP network packet in ▶ a secured TLS presentation message in ▶ a TCP transport segment in ▶ an IP network packet in ▶ an Ethernet link frame.
  32. 32. EncapsulationLayer 7Layer 6 • How layering manifests in data representationLayer 5 • Encapsulated payloadsLayer 4 ▶ Help separation of concernsLayer 3 ▶ Help enforce boundaries/layering ▶ Simplify layer implementationsLayer 2Layer 1
  33. 33. An#Introduc+on#to#Computer#Networks# Principle:*Packet*Switching*
  34. 34. What#is#packet#switching?# Packet:#A#self=contained#unit#of#data#that#carries# informa+on#necessary#for#it#to#reach#its#des+na+on.#CS144,#Stanford#University#
  35. 35. Two#consequences# 1.  No#per=flow#state#required.# 2.  Efficient#sharing#of#links.#CS144,#Stanford#University#
  36. 36. No#per=flow#state#required# Packet#switches#don’t#need#state#for#each#flow#–#each# packet#is#self=contained.# No#per=flow#state#to#be#added/removed.# No#per=flow#state#to#be#stored.# No#per=flow#state#to#be#changed#upon#failure.#CS144,#Stanford#University#
  37. 37. Efficient#sharing#of#links# Data#traffic#is#bursty# –  If#we#reserved#a#frac+on#of#the#links#for#each#flow,#the# links#would#be#used#inefficiently.# –  Packet#switching#allows#flows#to#use#all#available#link# capacity.# This#is#called#Sta$s$cal(Mul$plexing.#CS144,#Stanford#University#
  38. 38. Principle: Names and AddressesCS144, Stanford University 1
  39. 39. Name vs. Address • Name: specifies what something is ▶ Office: Philip Levis’ office ▶ Host name: market.scs.stanford.edu ▶ Memory: list_ptr • Address: specifies where something is ▶ Office: 412 Gates Hall, 353 Serra Mall, Stanford, CA 94305-9040 USA ▶ IP: 171.66.3.9 ▶ Memory: 0x0040005080 • Telephone numbers: names or addresses? • This is not a hard classification, just a conceptual modelCS144, Stanford University 2
  40. 40. Names • Structure of names affects what you can reference (easily) • Flat names ▶ Stock tickers (GOOG, MSFT), airport codes (NRT, YYZ) ▶ Services: http, ftp, https ▶ Skype IDs • Tuple pairs ▶ Gender: Female; Name: Jennifer Widom; Position: Department Chair • Hierarchical names ▶ maps.google.com ▶ Nick McKeown, Professor of Electrical Engineering and Computer Science, Stanford UniversityCS144, Stanford University 3
  41. 41. Addresses • Structure of addresses affects what you can reference (easily) • Flat addresses ▶ Memory (0x040004400) ▶ Port numbers (80, 21, 443) • Tuple pairs ▶ x=32, y=100, z=88 ▶ latitude=45.211W, longitude=48.111N • Hierarchical addresses ▶ Memory segments (0x1000 in segment 0) ▶ 412 Gates Hall, 353 Serra Mall, Stanford, CA, 94131 USACS144, Stanford University 4
  42. 42. Downloading a File • How does one refer to the file? • Address: http://csl.stanford.edu/~pal/pubs.html ▶ Refers to what host the file is on ▶ Refers to where on the host’s file system the file is • Name: take a hash of pubs.html: 0x27de2b6939d7fb4b0573dbd6dbe2c740 ▶ Request the file (using a different protocol than http) with hash ▶ If file changes, hash changes ▶ Says nothing about where the file isCS144, Stanford University 5
  43. 43. Internet Names and Addresses • Internet addresses: 32-bit IPv4, 128-bit IPv6 addresses • Internet names: domain name system (DNS), www.stanford.edu • Many more names and addresses at higher layers ▶ Service names (http) and ports (80) ▶ SIP identifiers (pal@a.com) and email addresses (pal@a.com) • Internet Corporation for Assigned Names and Numbers (ICANN) ▶ Internet Assigned Numbers Authority (IANA)CS144, Stanford University 6
  44. 44. Two Examples • http://csl.stanford.edu/~pal vs. http://171.64.73.43/~pal • A user moving between networksCS144, Stanford University 7
  45. 45. Principle • Whether you name or address something has deep implications to how your network and or protocol can be used. • The structure and design of those names and addresses also have deep implications.CS144, Stanford University 8
  46. 46. The End-to-End PrincipleCS144, Stanford University 1
  47. 47. Application View of the WorldCS144, Stanford University 2
  48. 48. Why Doesn’t the Network Help? • Compress data? • Reformat/translate/improve requests? • Serve cached data? • Add security? • Migrate connections across the network? • Or one of any of a huge number of other things?CS144, Stanford University 3
  49. 49. The End-To-End Principle The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the end points of the communication system. Therefore, providing that questioned function as a feature of the communication system itself is not possible. (Sometimes an incomplete version of the function provided by the communication system may be useful as a performance enhancement.) We call this line of reasoning. . . “the end-to-end argument.” - Saltzer, Reed, and Clark, End-to-end Arguments in System Design, 1984CS144, Stanford University 4
  50. 50. Example: File TransferCS144, Stanford University 5
  51. 51. Example: Link ReliabilityCS144, Stanford University 6
  52. 52. “Strong” End to End The network’s job is to transmit datagrams as efficiently and flexibly as possible. Everything else should be done at the fringes. . . – [RFC 1958]CS144, Stanford University 7
  53. 53. Net Neutrality “Allowing broadband carriers to control what people see and do online would fundamentally undermine the principles that have made the Internet such a success.” - Vinton Cerf in testimony before Congress February 7, 2006 "I am totally opposed to mandating that nothing interesting can happen inside the net." - Bob Kahn, speaking at the Computer History Museum, January 9, 2007CS144, Stanford University 8
  54. 54. Finite State Machines Protocol SpecificationCS144, Stanford University 1
  55. 55. Finite State Machines State State 1 2 State 3CS144, Stanford University 2
  56. 56. Finite State Machines event causing state transition actions taken on state transition State State 1 2 State 3CS144, Stanford University 3
  57. 57. Finite State Machines event causing state transition actions taken on state transition State State 1 2 event action State 3CS144, Stanford University 4
  58. 58. FSM Example: HTTP RequestCS144, Stanford University 5
  59. 59. FSM Example: TCP ConnectionCS144, Stanford University 6 http://upload.wikimedia.org/wikipedia/commons/thumb/a/a2/Tcp_state_diagram_fixed.svg/
  60. 60. The Internet (why you should take this course)CS144, Stanford University 1
  61. 61. Societal Change • Economics: Black Friday, Cyber Monday, E-Fairness legislation • Dating: okcupid, match.com • Knowledge: Google books, eBooks, wikipedia • Communication: IM,VoIP, video telephonyCS144, Stanford University 2
  62. 62. Political Change • Arab spring: SMS, Twitter, U.S. State Department • Diplomacy: Wikileaks • Occupy movement: Twitter, Facebook • By force: Stuxnet wormCS144, Stanford University 3
  63. 63. Economic Change • #24: Sergey Brin and Larry Page (tied) • #26: Jeff Bezos • #35: Mark Zuckerberg (data from Forbes top billionaires list, April 16 2012)CS144, Stanford University 4
  64. 64. Second Industrial Revolution Degrees conferred in 2008 and projected job openings/year 2008-2018 http://csl.stanford.edu/~pal/edCS144, Stanford University 5
  65. 65. Roles in the RevolutionCS144, Stanford University 6
  66. 66. This Course • How computer networks work: principles, design, and implementation • Use these principles to understand the current Internet • How to apply these principles to help build the future Internet • How forces shape the Internet: technological, economic, social, politicalCS144, Stanford University 7
  67. 67. CS144 An Introduc/on to Computer Networks   Congeson  AIMD with a single flow  Nick McKeown  Professor of Electrical Engineering   and Computer Science, Stanford University  1 
  68. 68. AIMD  Addi/ve Increase, Mul/plica/ve Decrease  1 If packet received OK: W ← W + W W If a packet is dropped: W ← 2 cwnd Drops  halved  tCS144, Stanford University  2 
  69. 69. Animation Animation at: http://guido.appenzeller.net/anims/CS144, Stanford University  3 
  70. 70. Single Flow Dynamics 4CS144, Stanford University  4 
  71. 71. Sending rate for a single flow  Round‐trip /me  Round‐trip /me  Window Size  Window Size  Window Size  A  B  ACK  ACK  ACK  ACK  ACK  (1) R x RTT > Window size, W  (2) R x RTT = Window size, W CS144, Stanford University  5 
  72. 72. Sending rate for single flow Window size RTT t Router buffer  Link rate > C  Link rate = C  A  B CS144, Stanford University  6 
  73. 73. How big should the buffer be?  Buffer size, B = RTT × C Buffer size, B < RTT × CCS144, Stanford University  7 
  74. 74. Observa/ons for single flow  1.  Window expands/contracts according to AIMD. 2.  …to probe how many bytes the pipe can hold. 3.  The sawtooth is the stable operating point. 4.  The sending rate is constant. 5.  …if we have sufficient buffers (RTT x C).CS144, Stanford University  8 
  75. 75. <end> CS144, Stanford University  9 
  76. 76. CS144 An Introduc/on to Computer Networks   Congeson  AIMD with mul-ple flows   Nick McKeown  Professor of Electrical Engineering   and Computer Science, Stanford University  1 
  77. 77. Router buffer  Link rate > C  Link rate = C  A  B CS144, Stanford University  2 
  78. 78. One flow vs mul/ple flows   One flow  W(t) R= = constant Buffer occupancy Window size RTT(t) and RTT t Mulple flows  Buffer occupancy Buffer  Occupancy  and RTT t W(t) R= ∝W(t) (Zoom in)  RTT One of the flows cwnd tCS144, Stanford University  3 
  79. 79. Simple geometric intuition Dropscwnd A 1 t 3 2 Packet drop rate, p = 1 / A, where A = Wmax 8 A 3 1 RTT Throughput, R = = ! Wmax $ 2 RTT p # & RTT " 2 % 4 
  80. 80. Interpre/ng the rate equa/on  3 1 R= 2 RTT p 1. RTT → 0 ⇒ R → ∞ ? 2. p → 0 ⇒ R → ∞ ?CS144, Stanford University  5 
  81. 81. Observa/ons for mul/ple flows   1.  Window expands/contracts according to AIMD. 2.  …to probe how many bytes the pipe can hold. 3.  Bottleneck will contain packets from many flows. 4.  The sending rate varies with window size. 5.  AIMD is very sensitive to loss rate. 6.  AIMD penalizes flows with long RTTs.CS144, Stanford University  6 
  82. 82. <end> CS144, Stanford University  7 
  83. 83. Congestion Control II RTT Estimation, self-clockingCS144, Stanford University 1
  84. 84. Three Improvements • Congestion window • Timeout estimation • Self-clockingCS144, Stanford University 2
  85. 85. Timeouts • Round trip time estimation is critical for timeouts ▶ Too short: waste capacity with restransmissions, trigger slow start ▶ Too long: waste capacity with idle time • Challenge: RTT is highly dynamic • Challenge: RTT can vary significantly with loadCS144, Stanford University 3
  86. 86. Pre-Tahoe Timeouts • r is RTT estimate, initialize to something reasonable • m, RTT measurement from most recently acked data packet • Exponentially weighted moving average: r = αr + (1-α)m • Timeout = βr, β=2 • What’s the problem?CS144, Stanford University 4
  87. 87. TCP Tahoe Timeouts • r is RTT estimate, initialize to something reasonable • g is the EWMA gain (e.g., 0.25) • m is the RTT measurement from most recently acked data packet • Error in the estimate e = m-r • r = r + g⋅e • Measure variance v = v + g(|e| - v) • Timeout = r + βv (β=4) • Exponentially increase timeout in case of tremendous congestionCS144, Stanford University 5
  88. 88. RTT Estimation Improvement Pre-Tahoe TahoeCS144, Stanford University 6
  89. 89. Three Improvements • Congestion window • Timeout estimation • Self-clockingCS144, Stanford University 7
  90. 90. Self-Clocking • In case of a bottleneck link, sender receives acks properly spaced in time sender receiverCS144, Stanford University 8
  91. 91. Self-Clocking Principle • Only put data in when data has left ▶ Want to prevent congestion -- too much data in network • Send new data in response to acknowledgments • Send acknowledgments aggressively -- important signalCS144, Stanford University 9
  92. 92. TCP Tahoe • 1987-8:Van Jacobson fixes TCP, publishes seminal TCP paper (Tahoe) ▶ Congestion window, slow start ▶ Timeout considers variance ▶ Self-clocking • TCP Tahoe solved TCP’s congestion control problem ▶ Spawned a huge area of research in TCP variants ▶ Next lecture will talk about Reno and NewReno ▶ Reading: “Congestion Avoidance and Control,” Van Jacobson and Karels.CS144, Stanford University 10
  93. 93. Congestion Control III Performance improvements: TCP Reno, TCP NewRenoCS144, Stanford University 1
  94. 94. TCP Tahoe • On timeout or triple duplicate ack (implies lost packet) ▶ Set threshold to congestion window/2 ▶ Set congestion window to 1 ▶ Enter slow start stateCS144, Stanford University 2
  95. 95. TCP Tahoe Review window size timeCS144, Stanford University 3
  96. 96. TCP Reno • Same as Tahoe on timeout • On triple duplicate ack ▶ Set threshold to congestion window/2 ▶ Set congestion window to congestion window/2 (fast recovery) ▶ Retransmit missing segment (fast retransmit) ▶ Stay in congestion avoidance stateCS144, Stanford University 4
  97. 97. TCP Reno window size timeCS144, Stanford University 5
  98. 98. TCP Reno Example receiver sender TimeCS144, Stanford University 6
  99. 99. TCP NewReno • Same as Tahoe/Reno on timeout • During fast recovery ▶ Keep track of last unacknowledged packet when entering fast recovery ▶ On every duplicate ack, inflate congestion window by maximum segment size ▶ When last packet acknowledged, return to congestion avoidance state, set cwnd back to value set when entering fast recovery ▶ Start sending out new packets while fast retransmit is in flightCS144, Stanford University 7
  100. 100. TCP NewReno Behavior TimeCS144, Stanford University 8
  101. 101. Congestion Control • One of the hardest problems in robust networked systems • Basic approach: additive increase, multiplicative decrease • Tricks to keep pipe full, improve throughput ▶ Fast retransmit (don’t wait for timeout to send lost data) ▶ Congestion window inflation (don’t wait an RTT before sending more data)CS144, Stanford University 9
  102. 102. Congestion Control IV Why AIMDCS144, Stanford University 1
  103. 103. Congestion Control • Service Provider: maximize link utilization • User: I get my fair share • Want network to converge to a state where everyone gets 1/N • Avoid congestion collapseCS144, Stanford University 2
  104. 104. Congestion Window Size San Francisco Boston Optimal congestion window size is the bandwidth-delay productCS144, Stanford University 3
  105. 105. Chiu Jain Plot Flow B rate (bps) Flow A rate (bps)CS144, Stanford University 4
  106. 106. Chiu Jain Plot Fair A=B Flow B rate (bps) Flow A rate (bps)CS144, Stanford University 5
  107. 107. Chiu Jain Plot Fair A=B Flow B rate (bps) Efficient A+B=C Flow A rate (bps)CS144, Stanford University 6
  108. 108. Chiu Jain Plot Fair A=B Flow B rate (bps) overload Efficient underload A+B=C Flow A rate (bps)CS144, Stanford University 7
  109. 109. Chiu Jain Plot Fair A=B Flow B rate (bps) overload Efficient underload A+B=C Flow A rate (bps)CS144, Stanford University 8
  110. 110. Chiu Jain Plot Fair t2 A=B t4 Flow B rate (bps) t1 t6 t3 t5 overload Efficient underload A+B=C Flow A rate (bps)CS144, Stanford University 9
  111. 111. CS144  An Introduc/on to Computer Networks   What the Internet is   4 Layer Model   Nick McKeown  Professor of Electrical Engineering   and Computer Science, Stanford University CS144, Stanford University  1 
  112. 112. The 4 Layer Internet Model   Applica/on  Transport  Network  Link CS144, Stanford University  2 
  113. 113. Peer layers communicate  A  B  Applica/on  Applica/on  Transport  Transport  Network  Network  Network  Network  Link  Link  Link  Link CS144, Stanford University  3 
  114. 114. Encapsula/on  A  Applica/on  Transport  Network  Network  Link  Link CS144, Stanford University  4 
  115. 115. Peer layers communicate  B  Applica/on  Transport  Network  Network  Link  Link CS144, Stanford University  5 
  116. 116. A few last words… CS144, Stanford University  6 
  117. 117. Where do the different layers run?  Applica/on  Transport  Network  Link CS144, Stanford University  7 
  118. 118. Why is the Network Layer oPen  called “Layer 3”?  h-p  Applica/on  Applica/on  ASCII  Presenta/on  Session  Transport  TCP  Transport  Network  IP  Network  Link  Ethernet  Link  Physical  The 4‐layer Internet model  The 7‐layer OSI Model CS144, Stanford University 
  119. 119. <The End> CS144, Stanford University  9 
  120. 120. CS144  An Introduc/on to Computer Networks   What the Internet is   The IP Service  Nick McKeown  Professor of Electrical Engineering   and Computer Science, Stanford University CS144, Stanford University  1 
  121. 121. The Internet Protocol (IP)   Applica/on  Transport  TCP  Data  Hdr   TCP Segment  Network  IP  Data  Hdr   IP Datagram  Link CS144, Stanford University  2 
  122. 122. The IP Service Model   Property  Behavior  Datagram  Individually routed packets.  Hop‐by‐hop rou/ng.  Unreliable  Packets might be dropped.  Best effort  …but only if necessary.  Connec4onless  No per‐flow state.  Packets might be mis‐sequenced. CS144, Stanford University  3 
  123. 123. The IP Service Model (Details)   •  Tries to prevent packets looping forever.  •  Will fragment packets if they are too long.  •  Uses a checksum to reduce chances of delivering  to wrong des/na/on.  •  Allows for new versions of IP  –  Currently IPv4 with 32 bit addresses  –  And IPv6 with 128 bit addresses  •  Allows for new op/ons to be added to header. CS144, Stanford University  4 
  124. 124. IPv4 Datagram  Bit 0  Bit 31  Header  Type of  Version  Length  Service  Total Packet Length  Packet ID  Flags  Fragment Offset   Time to Live  “TTL”  Protocol ID  Checksum  Source IP Address   Des/na/on IP Address   (OPTIONS)   (PAD)   Data CS144, Stanford University  5 
  125. 125. The Hourglass Model of IP  h`p  smtp  ssh  …  TCP  UDP  …  IP  Ethernet  WiFi  DSL  … CS144, Stanford University  6 
  126. 126. Summary  We use IP every /me we send and receive  Internet packets.  It provides a deliberately simple service:  –  Datagram  –  Unreliable  –  Best‐effort  –  Connec/onless CS144, Stanford University  7 
  127. 127. <The End> CS144, Stanford University  8 
  128. 128. CS144  An Introduc/on to Computer Networks   Rou$ng  Mul$cast Rou$ng  Nick McKeown  Professor of Electrical Engineering   and Computer Science, Stanford University CS144, Stanford University  1 
  129. 129. Mul/cast  A  B  C  D  R1 R2 R4 R6 R7 R5 R3 R8 E  X  2 
  130. 130. Mul/cast  A  B  C  D  R1 R2 R4 R6 R7 R5 R3 R8 E  X  3 
  131. 131. Mul/cast   Techniques and Principles  - Reverse Path Broadcast (RPB) and Pruning  - One versus mul/ple trees  Prac/ce  - IGMP – group management  - DVMRP – the first mul/cast rou/ng protocol  - PIM – protocol independent mul/cast CS144, Stanford University  4 
  132. 132. Flooding CS144, Stanford University  5 
  133. 133. Reverse Path Broadcast (RPB)     aka Reverse Path Forwarding (RPF) A  B  C  D  R1 R2 R4 R6 R7 R5 R3 R8 E  X CS144, Stanford University  6 
  134. 134. RPB + Pruning  1.  Packets delivered loop‐free to every end host.  2.  Routers with no interested hosts send prune  messages towards source.  3.  Resul/ng tree is the minimum cost spanning tree  from source to the set of interested hosts. CS144, Stanford University  7 
  135. 135. One tree versus several trees? A  B  C  D  R1  R2  R4  R6  R7  R5  R3  R8  E  X  8 
  136. 136. Mul/cast   Techniques and Principles  - Reverse Path Broadcast (RPB) and Pruning  - One versus mul/ple trees  Prac/ce  - Mul/cast addresses  - IGMP – group management  - DVMRP – the first mul/cast rou/ng protocol  - PIM – protocol independent mul/cast CS144, Stanford University  9 
  137. 137. Addresses and joining a group  IPv4: Class D addresses are set aside for mul/cast.  IGMP* (Internet group management protocol)  -  Between host and directly aaached router.  -  Hosts ask to receive packets belonging to a par/cular  mul/cast group.  -  Routers periodically poll hosts to ask which groups  they want.  -  If no reply, membership /mes out (sod‐state).  *RFC 3376 CS144, Stanford University  10 
  138. 138. Mul/cast rou/ng in the Internet DVMRP  -  Distance Vector Mul/cast Rou/ng Protocol (RFC 1075)  -  First Internet rou/ng protocol  -  Uses RPB + Prune PIM  -  Protocol Independent Mul/cast  -  Two modes: dense mode, sparse mode  -  Dense mode (RFC 3973): Similar to DVMRP  -  Sparse mode (RFC 4601): Builds rendezvous points  through which packets join small set of spanning trees.  11 
  139. 139. Mul/cast in prac/ce Mul/cast used less than originally expected  -  Most communica/on is individualized   (e.g. /me shiding)  -  Early implementa/ons were inefficient  -  Today, used for some IP TV and fast dissemina/on  -  Some applica/on‐layer mul/cast rou/ng used Some interes/ng ques/ons  -  How to make mul/cast reliable?  -  How to implement flow‐control?  -  How to support different rates for different end users?  -  How to secure a mul/cast conversa/on?  12 
  140. 140. CS144  An Introduc/on to Computer Networks   Rou$ng  Spanning Tree Protocol   Nick McKeown  Professor of Electrical Engineering   and Computer Science, Stanford University CS144, Stanford University  1 
  141. 141. Outline  Ethernet “routes” packets too. We know how addresses are learned, but how are  loops prevented? Ethernet switches build a spanning tree over which  packets are forwarded.  2 
  142. 142. Ethernet Switch 1.  Examine the header of each arriving frame. 2.  If the Ethernet DA is in the forwarding table, forward the  frame to the correct output port(s). 3.  If the Ethernet DA is not in the table, broadcast the  frame to all ports (except the one through which the  frame arrived). 4.  Entries in the table are learned by examining the  Ethernet SA of arriving packets.  3 
  143. 143. Learning could lead to loops  CS144, Stanford University  4 
  144. 144. Preven/ng loops   Spanning Tree Protocol  The topology of switches is a graph. The Spanning Tree Protocol finds a a subgraph that  spans all the ver/ces without loops.  -  Spanning: all switches are included.  -  Tree: no loops. The distributed protocol decides:  1.  Which switch is the Root of the tree, and  2.  Which ports are allowed to forward packets along the tree.   5 
  145. 145. Example Spanning Tree  S9  S8  S3  S5  S7  S2  S1  S6  S4 1: Pick a single root. 2: Only forward packets on ports on the shortest hop‐count to root.  6 
  146. 146. Resul/ng Spanning Tree  S1  S2  S4  S5  S6  S7  S3  S8  S9  7 
  147. 147. How it works  1.  Periodically, all switches broadcast a “Bridge Protocol Data Unit” (BPDU)   (ID of sender, ID of root, distance from sender to root). 2.  Ini/ally, every switch claims to be Root: sets distance field to 0. 3.  Every switch broadcasts un/l it hears a  be^er  message:  -  A root with a smaller ID  -  A root with equal ID, but with shorter distance  -  Ties broken by smaller ID of sender. 4.  If a switch hears a be^er message, retransmit message (add 1 to distance). Root port: The port on a switch that is closest to the Root. Designated port: The port neighbors agree to use to reach the Root.  All other ports are blocked from forwarding (but s/ll send/receive BPDUs). Eventually:  -  Only the root originates configura/on messages (others retransmit them).  -  Locally, switch only forwards on ports.  8 
  148. 148. A brief history  1985: STP proposed; IEEE standard in 1990.   S/ll very widely used  2004: STP replaced by RSTP which converges faster.   S/ll, RSTP uses the network inefficiently.  2012: A new standard for Ethernet switches was  introduced Shortest‐Path Bridging (SPB,  or  802.1aq). It is a link‐state protocol like OSPF. CS144, Stanford University  9 
  149. 149. Reading an RFCCS144, Stanford University 1
  150. 150. History (RFC 2555) • RFC 1: “Host Software” ▶ “Mindful that our group was informal, junior and unchartered, I wanted to emphasize these notes were the beginning of a dialog and not an assertion of control.” • Standardization of format ▶ Structure, intellectual property rights, terminology (RFC 2119) ▶ Security, IANA • Kinds of RFCs: proposed standard, standards-track, informational, experimental, best current practice (BCP)CS144, Stanford University 2
  151. 151. RFC Process (simplified) • Start with a draft: draft-levis-roll-trickle-00 • Revisions: draft-levis-roll-trickle-XX • Accepted by working group: draft-ietf-roll-trickle-00 • Revisions: draft-ietf-roll-trickle-XX • Accepted by working group chair for publication • Working group, IETF last call • IESG review • Approved as an RFCCS144, Stanford University 3
  152. 152. Terminology • MUST, REQUIRED, SHALL: absolute requirement. • SHOULD, RECOMMENDED: “mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.” • MAY, OPTIONAL: “mean that an item is truly optional.”CS144, Stanford University 4
  153. 153. Example: RFC5681CS144, Stanford University 5
  154. 154. CS144 An Introduc/on to Computer Networks   Physical Links   CSMA/CD and Ethernet   Nick McKeown  Professor of Electrical Engineering   and Computer Science, Stanford University  1 
  155. 155. The Link Layer  A  B Applica/on  Applica/on Transport  Transport Network  Network  Network  Network  Link  Link  Link  Link  2 
  156. 156. Why is Ethernet oIen  referred to as “Layer 2”?  h0p  Applica/on  Applica/on  ASCII  Presenta/on  Session  Transport  TCP  Transport  Network  IP  Network  Link  Ethernet  Link  Physical  The 4‐layer Internet model  The 7‐layer OSI Model CS144, Stanford University  3 
  157. 157. The origins of Ethernet  CS144, Stanford University  4 
  158. 158. Sharing a “medium”   -  Ethernet is an example of mul/ple hosts sharing  a common cable (“medium”).  -  To share the medium, we need to decide who  gets to send, and when.  -  There is a general class of “Medium Access  Control Protocols”, or MAC Protocols.  -  We will take a look at some examples. CS144, Stanford University  5 
  159. 159. Random  Examples of MAC Protocols  Packet‐Switched Radio Network  Simple  Aloha  Carrier Sense Mul/ple Access/Collision Detec/on  Ethernet (IEEE 802.3)  DeterminisFc  Complex   Token Passing  Token Ring (IEEE 802.5) CS144, Stanford University  6 
  160. 160. Goals of MAC Protocols   Medium Access Control protocols arbitrate access to a  common shared channel among a popula/on of users   1.  High u/liza/on of the shared channel  2.  Fair among end hosts  3.  Simple and low cost to implement  4.  Robust to errors; fault tolerant CS144, Stanford University  7 
  161. 161. Aloha Network (1968)   Kauai  Molokai  Oahu  Maui  Hawaii CS144, Stanford University  8 
  162. 162. Aloha  Frequency 0  Frequency 1  Original Aloha MAC protocol  1.  If you have data to send, transmit it.  2.  If your transmission “collides” with another, retry later. CS144, Stanford University  9 
  163. 163. Aloha Protocol   -  Aloha protocol is very simple  -  (Quite) robust against failure of a host.  -  The protocol is distributed among the hosts.  -  Under low‐load, we can expect the delay to be small.  -  Under high‐load, a lot of /me “wasted” sending packets that  collide.  Improving performance:  1. Listen for ac/vity (“carrier sense”) before sending a packet.  2. Detect collisions quickly and stop transmigng.  3. AIer collision, pick random wai/ng /me based on the load. CS144, Stanford University  10 
  164. 164. CSMA/CD Protocol   All hosts transmit & receive on one channel  Packets are of variable size.  When a host has a packet to transmit:  1.  Carrier Sense:  Check the line is quiet before transmigng.  2.  Collision Detec/on:  Detect collision as soon as possible. If a collision is  detected, stop transmigng; wait a random /me, then return to step 1.  binary exponen7al backoff CS144, Stanford University  11 
  165. 165. CSMA/CD opera/on  A  B  C  D CS144, Stanford University  12 
  166. 166. CSMA/CD Packet size requirement   A  B  C  D  L/c CS144, Stanford University  13 
  167. 167. <end> CS144, Stanford University  14 
  168. 168. Wireless NetworkingCS144, Stanford University 1
  169. 169. Access Point NetworksCS144, Stanford University 2

×