26
1 Internet History, Architecture, and Routing ECON 425/563 & CPSC 455/555 9/25/2008 ECON 425/563 & CPSC 455/555 9/25/2008

Internet History, Architecture, and Routing

  • Upload
    hang

  • View
    37

  • Download
    1

Embed Size (px)

DESCRIPTION

Internet History, Architecture, and Routing. ECON 425/563 & CPSC 455/555 9/25/2008. ECON 425/563 & CPSC 455/555 9/25/2008. Internet History. Late 1960s and early 1970s: ARPANET US Department of Defense Connects small ARPA-sponsored data networks - PowerPoint PPT Presentation

Citation preview

Page 1: Internet History, Architecture, and Routing

1

Internet History, Architecture, and Routing

ECON 425/563 & CPSC 455/555

9/25/2008ECON 425/563 & CPSC 455/555

9/25/2008

Page 2: Internet History, Architecture, and Routing

2

Internet History• Late 1960s and early 1970s: ARPANET

– US Department of Defense– Connects small ARPA-sponsored data

networks– Ground breaking testbed for network ideas

and designs• Early 1980s: Other wide-area data networks are

established (e.g., BITNET and Usenet).• Late 1980s and early 1990s:

– “ARPANET” fades out.– US Gov’t sponsors NSFNET, which connects

large regional networks.– Commercial data networks become popular

(e.g., Prodigy, Compuserve, and AOL).

• Mid-1990s: Unified “Internet”

Page 3: Internet History, Architecture, and Routing

3

Internet Protocols Design Philosophy

• Ordered set of goals:1. multiplexed utilization of existing networks2. survivability in the face of failure3. support multiple types of communications

service4. accommodate a variety of network types5. permit distributed management of resources6. cost effective7. low effort to attach a host8. account for resources

• Not all goals have been met

Page 4: Internet History, Architecture, and Routing

4

Packets!• Basic decision: use packets not circuits

(Kleinrock)• Packet (a.k.a. datagram)

– self contained– handled independently of preceding or following

packets– contains destination and source internetwork

address– may contain processing hints (e.g., QoS tag)– no delivery guarantees

– net may drop, duplicate, or deliver out of order– reliability (where needed) done at higher levels

Dest Addr Src Addr payload

Page 5: Internet History, Architecture, and Routing

5

Telephone Network

• Connection-based• Admission control• Intelligence is

“in the network”• Traffic carried by

relatively few, “well-known” communications companies

Internet

• Packet-based• Best effort• Intelligence is

“at the endpoints”

• Traffic carried by many routers, operated by a changing set of “unknown” parties

Page 6: Internet History, Architecture, and Routing

6

Directly Connected Machines

• (a) Point-to-point: e.g., ATM• (b) Multiple-access: e.g., Ethernet• Can’t build a network by requiring all

nodes to be directly connected to each other; need scalability with respect to the number of wires or the number of nodes that can attach to a shared medium

(a)

(b)

Page 7: Internet History, Architecture, and Routing

7

Switched Network

• Circuit switching vs. packet routing• Hosts vs. “the network,” which is made

of routers• Nice property: scalable aggregate

throughput

routers

hosts

Page 8: Internet History, Architecture, and Routing

8

Interconnection of Networks

Recursively build larger networks

gateway

hosts

Page 9: Internet History, Architecture, and Routing

9

Some Hard Questions

• How do hosts share links?• How do you name and address hosts?• Routing: Given a destination address,

how do you get to it?

gateway

hosts

Page 10: Internet History, Architecture, and Routing

10

IP Addresses andHost Names

• Each machine is addressed by an integer, itsIP address, written down in a “dot notation” for “ease” of reading, such as 128.36.229.231

• IP addresses are the universal IDs that are used to name everything.

• For convenience, each host also has ahuman-friendly host name. For example, 128.36.229.231 was concave.cs.yale.edu.

• Question: How do you translate names intoIP addresses?

Page 11: Internet History, Architecture, and Routing

11

Domain Hierarchy

• Initially, name-to-address mappingwas a flat file mailed out to all the machines on the Internet.

• Now, we have a hierarchicalname space, just like a UNIXfile-system tree.

• Top-level names (historical influence): heavily US-centric, government-centric, and military-centric viewof the world

edu com gov mil org net uk fr

Yale MIT Cisco . . . Yahoo

Math CS Physics

concave cyndra netra

Page 12: Internet History, Architecture, and Routing

12

DNS Zones andName Servers

• Divide up the name hierarchy into zones.

• Each zone corresponds to one or more name servers under the same administrative control.

edu com gov mil org net uk fr

Yale MITCisco . . . Yahoo

Math CS Physics

concave cyndra netra

Page 13: Internet History, Architecture, and Routing

13

Hierarchy of Name Servers

• Clients send queries to name servers.• Name servers reply with answers or forward

requests to other name servers.• Most name servers perform “lookup

caching.”

Root name server

Yale name server

CS name server EE name server

Cisco name server. . .

Page 14: Internet History, Architecture, and Routing

14

Application-Level Abstraction

• What you have: hop-to-hop links, multiple routes, packets, can be potentially lost, can be potentially delivered out-of-order

• What you may want: application-to-application (end-to-end) channel, communication stream, reliable, in-order delivery

hostapplication host

host

host

hostapplication

Page 15: Internet History, Architecture, and Routing

15

Basic Architectural Principle: Layering

Internet Protocol

Transmission ControlProtocol

User Datagram Protocol

TelnetHTTP(Web)

SONET ATMEthernet

Simple NetworkManagement

Domain NameService

Page 16: Internet History, Architecture, and Routing

16

Interdomain RoutingEstablish routes between autonomous systems

(ASes).

Currently done with the Border Gateway Protocol (BGP).

AT&T

Qwest

Comcast

Verizon

Page 17: Internet History, Architecture, and Routing

17

Why is Interdomain Routing Hard?

• Route choices are based on local policies.

• Autonomy: Policies are uncoordinated.

• Expressiveness: Policies are complex.

AT&T

Qwest

Comcast

Verizon

My link to UUNET is forbackup purposes only.

Load-balance myoutgoing traffic.

Always chooseshortest paths.

Avoid routes through AT&T ifat all possible.

Page 18: Internet History, Architecture, and Routing

18

BGP Route Processing (1)

• The computation of a single node repeats the following:

Receive routes from neighbors

UpdateRoutin

g Table

Choose“Best”Route

Send updatesto neighbors

• Paths go through neighbors’ choices, which enforces consistency.

• Decisions are made locally, which preserves autonomy.

• Uncoordinated policies can induce protocol oscillations. (Much recent work addresses BGP convergence.)

• Recently, private information, optimization, and incentive-compatibility have also been studied.

Page 19: Internet History, Architecture, and Routing

19

Apply Policy =filter routes & tweak attributes

BGP Route Processing (2)

Routing Table

Apply Import Policies

Best Route Selection

Apply Export Policies

Install forwardingentries for best routes

ReceiveBGPupdates

Storageof routes

TransmitBGP updates

Based onattributevalues

IP Forwarding Table

Apply Policy =filter routes & tweak attributes

Open-ended programming:constrained only by vendor configuration language

Page 20: Internet History, Architecture, and Routing

20

Example: Convergence

1 2

d

Prefer routes

through 2

Prefer direct route

to d

Page 21: Internet History, Architecture, and Routing

21

Example: Oscillation

1 2

d

BGP might oscillateforever between

1d, 2dand

12d, 21d

Prefer routes

through 2

Prefer routes

through 1

Page 22: Internet History, Architecture, and Routing

22

Example: Convergence

1 2

d

Prefer routes

through 2

Prefer routes

through 1

Page 23: Internet History, Architecture, and Routing

23

Dispute Wheels

Nodes ui, hub routes Ri, and spoke routes Qi.Each ui prefers RiQi+1 to Qi.

“No dispute wheel” —>robust convergence

Page 24: Internet History, Architecture, and Routing

24

Gao-Rexford Framework (1)

Neighboring pairs of ASes have one of:– a customer-provider relationship

(One node is purchasing connectivity fromthe other node.)

– a peering relationship(Nodes have offered to carry each other’stransit traffic, often to shortcut a longer route.)

peer

providers

customerspeer

Page 25: Internet History, Architecture, and Routing

25

Gao-Rexford Framework (2)

• Global constraint: no customer-provider cycles• Local preference and scoping constraints, which are

consistent with Internet economics:

• Gao-Rexford conditions => BGP always converges [GR01]

Preference Constraints

. . . . . .

. . . . . .i

dR1

R2

k2

k1

• If k1 and k2 are both customers, peers, or providers of i, then either ik1R1 or ik2R2 can be more valued at i.

• If one is a customer, prefer the route through it. If not, prefer the peer route.

Scoping Constraints

d

k

i

j

• Export customer routes to all neighbors and export all routes to customers.

• Export peer and provider routes to all customers only.

m

. . . .. . . .

. . . .peer

customer

provider

Page 26: Internet History, Architecture, and Routing

26

Ongoing Research Challenge

Fully characterize the conditions under which BGP converges (robustly).

• “No dispute wheel” is sufficient but not necessary. Is it enforceable?

• On those instances on which BGP is guaranteed to converge, how many rounds does it take to converge?