IP Routing
Timothy G. Griffin
Intel Research
[email protected]
http://www.cambridge.intel-research.net/~tgriffin
IMA
Minneapolis
January, 2004
Common View of the Telco Network
Brick
Common View of the IP Network (Layer 3)
What This Course Is About
Forwarding vs. Routing
• Forwarding: Use of local information (tables, data
structures) to determine treatment of data traffic
–
–
–
–
traffic classification
treatment bases on classification
can drop traffic
or decide where to send it next, and how to send it
• Routing: Use of global information to populate forwarding
data structures in multiple network nodes
– goal is normally to optimize something given state of the
network
– difficult to fully automated --- often requires intricate
configuration
– is partially automated with dynamic routing protocols
What You Should Take Away
• Heterogeneity
– Many technologies
– Many networks
– Many “routing policies”
• IP Routing is evolving
– New protocols and extensions
– New router knobs
– New ways of using existing technologies
Anthropology of Routing
Academic
Research
Protocol Standards
IEEE, IETF, …
EE
Vendors
Cisco, Juniper …
NANOG, RIPE, …
CS
Sun, Microsoft, …
Maths
Books, Training, …
Operator Forums
Could add regulation, markets, ….
Routing can happen at any level
data received
data sent
Application
Application
Presentation
Presentation
Session
Session
Transport
Transport
Network
Network
DataLink
DataLink
Physical
Physical
8
IP is a Network Layer Protocol
Application
Separate physical networks
glued together into one
Application
logical network
Router
Presentation
Presentation
Session
Session
Transport
Transport
Network
Network
Network
DataLink 1
DataLink 1 DataLink 2
DataLink 2
Physical 1
Physical 1 Physical 2
Physical 2
Medium 1
Medium 2
9
All Hail the IP Datagram!
H
E
A
D
E
R
D
A
T
A
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL | Service Type |
Total Length
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Identification
|Flags|
Fragment Offset
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live |
Protocol
|
Header Checksum
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Source Address
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Destination Address
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Options
|
Padding
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:
:
:
:
|
|
+
+
|
|
+
+
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... up to 65,515 octets of data ...
shaded fields little-used today
1981, RFC 791
10
IP Hour Glass
Networking Applications
Voice
e-stuff
Remote Access
email file transfer Multimedia
Web
VPN
TCP
IP
Minimalist network layer
Frame
SONET
X.25
ATM
DWDM
Ethernet
FDDI
Networking Technologies
11
Routers Talking to Routers
Routing info
Routing info
• Routing computation is distributed among routers within a
routing domain
• Computation of best next hop based on routing information
is the most CPU/memory intensive task on a router
• Routing messages are usually not routed, but exchanged
via layer 2 between physically adjacent routers (internal
BGP and multi-hop external BGP are exceptions)
Architecture of Dynamic Routing
OSPF
BGP
AS 1
IGP = Interior Gateway Protocol
Metric based: OSPF, IS-IS, RIP,
EIGRP (cisco)
EGP = Exterior Gateway Protocol
EIGRP
AS 2
Policy based: BGP
The Routing Domain of BGP is the entire Internet
Technology of Distributed Routing
Link State
•
•
•
•
•
•
Topology information is
flooded within the routing
domain
Best end-to-end paths are
computed locally at each
router.
Best end-to-end paths
determine next-hops.
Based on minimizing
some notion of distance
Works only if policy is
shared and uniform
Examples: OSPF, IS-IS
Vectoring
•
•
•
•
•
•
Each router knows little
about network topology
Only best next-hops are
chosen by each router for
each destination network.
Best end-to-end paths
result from composition
of all next-hop choices
Does not require any
notion of distance
Does not require uniform
policies at all routers
Examples: RIP, BGP
The Gang of Four
Link State
IGP
EGP
OSPF
IS-IS
Vectoring
RIP
BGP
Autonomous Routing Domains
(ARDs)
A collection of physical networks glued together
using IP, that have a unified administrative
routing policy.
•
•
•
•
Campus networks
Corporate networks
ISP Internal networks
…
Autonomous System (AS) Numbers
16 bit values.
64512 through 65535 are “private”
•
•
•
•
•
•
•
•
Currently over 16,000 in use.
Genuity: 1
MIT: 3
JANET: 786
UC San Diego: 7377
AT&T: 7018, 6341, 5074, …
UUNET: 701, 702, 284, 12199, …
Sprint: 1239, 1240, 6211, 6242, …
…
ASNs represent units of routing policy
Autonomous Routing Domains Don’t Always
Need BGP or an ASN
Qwest
Nail up routes 130.132.0.0/16
pointing to Yale
Nail up default routes 0.0.0.0/0
pointing to Qwest
Yale University
130.132.0.0/16
Static routing is the most common way of connecting an
autonomous routing domain to the Internet.
This helps explain why BGP is a mystery to many …
ASNs Can Be “Shared” (RFC 2270)
AS 701
UUNet
AS 7046
Crestar
Bank
AS 7046
NJIT
AS 7046
Hood
College
128.235.0.0/16
ASN 7046 is assigned to UUNet. It is used by
Customers single homed to UUNet, but needing
BGP for some reason (load balancing, etc..) [RFC 2270]
ARD != AS
• Most ARDs have no ASN
(statically routed at Internet
edge)
• Some unrelated ARDs share the
same ASN (RFC 2270)
• Some ARDs are implemented
with multiple ASNs (example:
Worldcom, AT&T, …)
ASes are an implementation detail of Interdomain routing
How Many ASNs?
15,981
Thanks to Geoff Huston. http://bgp.potaroo.net on October 24, 2003
How many prefixes?
154,894
Note: numbers
actually depends
point of view…
29%
Address space
covered
23%
Thanks to Geoff Huston. http://bgp.potaroo.net on October 24, 2003
A Bit of OGI’s AS Neighborhood
AS 7018
AT&T
AS 2914
Verio
AS 1239
Sprint
AS 3356
Level 3
AS 3356
Level 3
AS 101
U of Washington
AS 3807
U of Montana
AS 14262
AS 7774
U of Alaska
Portland Regional Education Network
AS 6366
Portland State U
AS 11964
OGI
128.223.0.0/16
AS 11995
Oregon Health
Sciences U
Sources: ARIN,
Route Views, RIPE
wiscnet.net
UW-Superior
Rice Lake
Rhinelander
UW-Stout
Marshfield
UW-River Falls
Stiles
Jct.
Wausau
UW-Eau Claire
Qwest
and Other
Provider(s)
Clintonville
er '02)
(Summ
UW-Stevens Point
UW-Green Bay
(Summer
'02)
Fox Valley TC
(Summer '03)
um
(S
UW-Oshkosh
m
'
er
)
02
UW-La Crosse
La Crosse
Portage
Dodgeville
GO BUCKY!
Genuity
UW-Madison
(Summer '03)
UW-Milwaukee
UW-Whitewater
UW-Parkside
)
(Winter '02
UW-Platteville
Gigabit Ethernet
OC-12 (622Mbps)
OC-3 (155Mbps)
DS-3 (45Mbps)
T1 (1.5Mbps)
Chicago






Internet 2
& Qwest
Peering - Public and Private
Commodity Internet Transit
Internet2
Merit and Other State Networks
National Education Network
Regional Research Peers
'02
ter
(Win
Chicago - 1
)
Chicago - 2
(Winter '02)
Partial View of cs.wisc.edu Neighborhood
AS 3549
Global
Crossing
AS 1
Genuity
AS 209
Qwest
AS 2381
WiscNet
AS 7050
UW Milwaukee
129.89.0.0/16
AS 59
UW Academic
Computing
128.105.0.0/16
AS 3136
UW Madison
130.47.0.0/16
Policy : Transit vs. Nontransit
A transit AS allows traffic with neither
source nor destination within AS to flow
across the network
AS 701
AT&T CBB
AS 701
UUnet
A nontransit AS allows
only traffic originating
from AS or traffic with
destination within AS
AS144
Bell Labs
IP traffic
26
Customers and Providers
provider
provider
customer
IP traffic
customer
Customer pays provider for access to the Internet
The “Peering” Relationship
peer
provider
peer
customer
Peers provide transit between
their respective customers
Peers do not provide transit
between peers
traffic
allowed
traffic NOT
allowed
Peers (often) do not exchange $$$
Peering Provides Shortcuts
Peering also allows connectivity between
the customers of “Tier 1” providers.
peer
provider
peer
customer
Peering Wars
Peer
• Reduces upstream
transit costs
• Can increase end-toend performance
• May be the only way to
connect your
customers to some
part of the Internet
(“Tier 1”)
Don’t Peer
• You would rather have
customers
• Peers are usually your
competition
• Peering relationships
may require periodic
renegotiation
Peering struggles are by far the most
contentious issues in the ISP world!
Peering agreements are often confidential.
Policy-Based vs. Distance-Based Routing?
Minimizing
“hop count” can
violate commercial
relationships that
constrain interdomain routing.
Host 1
Cust1
YES
ISP1
NO
ISP3
ISP2
Cust3
Host 2
Cust2
31
Why not minimize “AS hop count”?
National
ISP1
National
ISP2
YES
NO
Regional
ISP3
Cust3
Regional
ISP2
Cust2
Regional
ISP1
Cust1
32
BGP-4
• BGP = Border Gateway Protocol
• Is a Policy-Based routing protocol
• Is the de facto EGP of today’s global Internet
• Relatively simple protocol, but configuration is complex and the
entire world can see, and be impacted by, your mistakes.
•
1989 : BGP-1 [RFC 1105]
–
•
Replacement for EGP (1984, RFC 904)
1990 : BGP-2 [RFC 1163]
• 1991 : BGP-3 [RFC 1267]
•
1995 : BGP-4 [RFC 1771]
–
Support for Classless Interdomain Routing (CIDR)
33
Four Types of BGP Messages
• Open : Establish a peering session.
• Keep Alive : Handshake at regular
intervals.
• Notification : Shuts down a peering
session.
• Update : Announcing new routes or
withdrawing previously announced
routes.
announcement
=
prefix + attributes values34
BGP Attributes
Value
----1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
...
255
Code
--------------------------------ORIGIN
AS_PATH
NEXT_HOP
MULTI_EXIT_DISC
LOCAL_PREF
ATOMIC_AGGREGATE
AGGREGATOR
COMMUNITY
ORIGINATOR_ID
CLUSTER_LIST
DPA
ADVERTISER
RCID_PATH / CLUSTER_ID
MP_REACH_NLRI
MP_UNREACH_NLRI
EXTENDED COMMUNITIES
Reference
--------[RFC1771]
[RFC1771]
[RFC1771]
[RFC1771]
[RFC1771]
[RFC1771]
[RFC1771]
[RFC1997]
[RFC2796]
[RFC2796]
[Chen]
[RFC1863]
[RFC1863]
[RFC2283]
[RFC2283]
[Rosen]
Most
important
attributes
reserved for development
From IANA: http://www.iana.org/assignments/bgp-parameters
Not all attributes
need to be present in
every announcement
Attributes are Used to Select Best
Routes
192.0.2.0/24
pick me!
192.0.2.0/24
pick me!
192.0.2.0/24
pick me!
192.0.2.0/24
pick me!
Given multiple
routes to the same
prefix, a BGP speaker
must pick at most
one best route
(Note: it could reject
them all!)
BGP Route Processing
Open ended programming.
Constrained only by vendor configuration language
Receive Apply Policy =
filter routes &
BGP
Updates tweak attributes
Apply Import
Policies
Based on
Attribute
Values
Best
Routes
Best Route
Selection
Best Route
Table
Apply Policy =
filter routes &
tweak attributes
Transmit
BGP
Updates
Apply Export
Policies
Install forwarding
Entries for best
Routes.
IP Forwarding Table
37
Route Selection Summary
Highest Local Preference
Enforce relationships
Shortest ASPATH
Lowest MED
i-BGP < e-BGP
traffic engineering
Lowest IGP cost
to BGP egress
Lowest router ID
Throw up hands and
break ties
ASPATH Attribute
AS 1129
135.207.0.0/16
AS Path = 1755 1239 7018 6341
135.207.0.0/16
AS Path = 1239 7018 6341
AS 1239
Sprint
AS 1755
135.207.0.0/16
AS Path = 1129 1755 1239 7018 6341
Ebone
AS 12654
AS 6341
AT&T Research
RIPE NCC
RIS project
135.207.0.0/16
AS Path = 7018 6341
AS7018
135.207.0.0/16
AS Path = 6341
Global Access
135.207.0.0/16
AS Path = 3549 7018 6341
AT&T
135.207.0.0/16
AS Path = 7018 6341
AS 3549
Global Crossing
135.207.0.0/16
Prefix Originated
39
Shorter Doesn’t Always Mean Shorter
In fairness:
could you do
this “right” and
still scale?
Mr. BGP says that
path 4 1 is better
than path 3 2 1
Duh!
AS 4
AS 3
Exporting internal
state would
dramatically
increase global
instability and
amount of routing
state
AS 2
AS 1
BGP Routing Tables
show ip bgp
BGP table version is 111849680, local router ID is 203.62.248.4
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network
. . .
*>i192.35.25.0
*>i192.35.29.0
*>i192.35.35.0
*>i192.35.37.0
*>i192.35.39.0
*>i192.35.44.0
*>i192.35.48.0
*>i192.35.49.0
*>i192.35.50.0
*>i192.35.51.0/25
. . .
Next Hop
134.159.0.1
166.49.251.25
134.159.0.1
134.159.0.1
134.159.0.3
166.49.251.25
203.62.248.34
203.62.248.34
203.62.248.34
203.62.248.34
Metric LocPrf Weight Path
50
50
50
50
50
50
55
55
55
55
0
0
0
0
0
0
0
0
0
0
16779 1 701 703 i
5727 7018 14541 i
16779 1 701 1744 i
16779 1 3561 i
16779 1 701 80 i
5727 7018 1785 i
16779 209 7843 225 225
16779 209 7843 225 225
16779 3549 714 714 714
16779 3549 14744 14744
225 225 225 i
225 225 225 i
i
14744 14744 14744 14744 14744 14744 i
Thanks to Geoff Huston. http://www.telstra.net/ops on July 6, 2001
• Use “whois” queries to associate an ASN with “owner” (for
example, http://www.arin.net/whois/arinwhois.html)
• 7018 = AT&T Worldnet, 701 =Uunet, 3561 = Cable &
Wireless, …
AS Graphs Depend on Point of View
peer
peer
provider
customer
1
3
2
4
1
3
5
1
2
4
5
6
3
1
6
4
2
2
6
4
5
3
5
6
AS Graphs Can Be Fun
The subgraph showing all ASes that have more than 100 neighbors in full
graph of 11,158 nodes. July 6, 2001. Point of view: AT&T route-server
AS Graphs Do Not Show “Topology”!
BGP was designed to
throw away information!
The AS graph
may look like this.
Reality may be closer to this…
So Many Choices
peer
provider
peer
customer
AS 4
Frank’s
Internet Barn
AS 3
AS 2
AS 1
Which route should
Frank pick to 13.13.0.0./16?
13.13.0.0/16
45
LOCAL PREFERENCE
Local
preference
used ONLY
in iBGP
AS 4
local pref = 80
local pref = 90
AS 3
local pref = 100
AS 2
Higher Local
preference values
are more preferred
AS 1
13.13.0.0/16
46
Implementing Backup Links with Local
Preference (Outbound Traffic)
AS 1
primary link
Set Local Pref = 100
for all routes from AS 1
backup link
AS 65000
Set Local Pref = 50
for all routes from AS 1
Forces outbound traffic to take primary link, unless link is down.
We’ll talk about inbound traffic soon …
47
Multihomed Backups
(Outbound Traffic)
AS 1
AS 3
provider
provider
primary link
backup link
Set Local Pref = 100
for all routes from AS 1
Set Local Pref = 50
for all routes from AS 3
AS 2
Forces outbound traffic to take primary link, unless link is down.
48
Shedding Inbound Traffic with
ASPATH Prepending
AS 1
Prepending will (usually)
force inbound
traffic from AS 1
to take primary link
provider
192.0.2.0/24
ASPATH = 2 2 2
192.0.2.0/24
ASPATH = 2
primary
backup
customer
AS 2
192.0.2.0/24
Yes, this is a
Glorious Hack …
49
… But Padding Does Not Always Work
AS 1
AS 3
provider
provider
192.0.2.0/24
ASPATH = 2
192.0.2.0/24
ASPATH = 2 2 2 2 2 2 2 2 2 2 2 2 2 2
primary
backup
customer
AS 2
192.0.2.0/24
AS 3 will send
traffic on “backup”
link because it prefers
customer routes and local
preference is considered
before ASPATH length!
Padding in this way is often
used as a form of load
50
balancing
COMMUNITY Attribute to the Rescue!
AS 1
AS 3
provider
provider
AS 3: normal
customer local
pref is 100,
peer local pref is 90
192.0.2.0/24
ASPATH = 2
COMMUNITY = 3:70
192.0.2.0/24
ASPATH = 2
primary
backup
customer
AS 2
192.0.2.0/24
Customer import policy at AS 3:
If 3:90 in COMMUNITY then
set local preference to 90
If 3:80 in COMMUNITY then
set local preference to 80
If 3:70 in COMMUNITY then
set local preference to 70
51
Don’t celebrate just yet…
Provider A (Tier 1)
peering
Provider B (Tier 1)
provider/customer
provider/customer
Provider C (Tier 2)
customer
Now, customer wants
a backup link to C….
Customer installs a “backup link” …
Provider A (Tier 1)
Provider C (Tier 2)
backup
customer sends
“lower my preference”
Community value
Provider B (Tier 1)
primary
customer
Disaster Strikes!
Provider A (Tier 1)
Provider C (Tier 2)
backup
Provider B (Tier 1)
primary
customer
customer is happy that backup was installed …
The primary link is repaired, and
something odd occurs…
Provider A (Tier 1)
Provider C (Tier 2)
backup
Provider B (Tier 1)
primary
customer
YIKES --- routing DOES NOT return to normal!!!
WAIT! It Gets Better…
A
B
P
B
B
C
B
D
P = primary B = backup
OOOOOPS!
A
B
P
B
B
C
B
Suppose A, B, C all
D
break ties in the
same direction
(clockwise or counter-clockwise)
No solution =
Protocol Divergence
What the heck is going on?
• There is no guarantee that a BGP
configuration has a unique routing solution.
– When multiple solutions exist, the (unpredictable)
order of updates will determine which one is wins.
• There is no guarantee that a BGP
configuration has any solution!
– And checking configurations NP-Complete [GW1999]
• Complex policies (weights, communities
setting preferences, and so on) increase
chances of routing anomalies.
– … yet this is the current trend!
Are we too complacent?
If the provider/customer digraph is acyclic and
every AS obeys the commandments
• Thou shall prefer customer
routes over all others
• Thou shall use provider
routes only as a last resort
• Thou shall not provide
transit between peers or
providers
then the BGP configuration is robust.
[see Gao-Griffin-Rexford, INFOCOM 2001]
Worrisome trends…
• Some Autonomous Routing Domains (ARDs) are
implemented with multiple ASNs (example: MCI,
InterNap, AT&T)
– Such “sibling” ASes are not confined to “customer/provider,
peer/peer” relationships
– ASNs are becoming just an implementation detail.
• Some ASes participate in different roles in different parts
of the world (Sprint, for example).
– I don’t think we understand this.
• We all know abut MED…
– But MED oscillation is not a feature interaction problem
(MEDs and Route Reflection), but rather a manifestation of
BGP’s general principle --- the more complex the policies, the
more likely that bad things happen. MED just makes it easy
to write very complex policies…
• Communities are being used for clever interdomain
signaling.
– Nobody has read “Inherently Safe Backup Routing with BGP”
Gao, Griffin, Rexford. INFOCOM 2001
– “te” communities and extended communities…
Let’s look at “te” communities…
AS13129, Global Access Telecommunications, Inc (Frankfurt)
n=0
do not announce prefix
1 <= n <= 3 prepend n times to announcement
Accepted
on inbound
routes
13129:101n - do not announce/prepend to Sprint (AS1239)
13129:102n - do not announce/prepend to Cogent (AS16631)
13129:103n - do not announce/prepend to Abovenet (AS6461)
13129:111n - do not announce/prepend to DE-CIX
13129:112n - do not announce/prepend to INXS
13129:113n - do not announce/prepend to SFINX
13129:114n - do not announce/prepend to LINX
13129:115n - do not announce/prepend to AMS-IX
13129:116n - do not announce/prepend to IX-HH
13129:117n - do not announce/prepend to NYIIX
13129:191n - do not announce/prepend to DTAG (AS3320)
13129:192n - do not announce/prepend to DFN (AS680)
13129:1990 - do not announce to the RIPE RIS project (AS12654)
See A survey of the utilization of the BGP community attribute
Bruno Quoitin and Olivier Bonaventure
http://www.infonet.fundp.ac.be/doc/tr/Infonet-TR-2002-02.html
Some AS286 Communities
From KPN Eurorings Backbone:
remarks:
remarks:
remarks:
remarks:
remarks:
remarks:
remarks:
remarks:
remarks:
remarks:
remarks:
remarks:
remarks:
remarks:
remarks:
remarks:
remarks:
+---------------------------------------------------------| COMMUNITIES - ROUTE ORIGIN - NOT SETTABLE BY CUSTOMERS
|
| 286:286 European customer routes
| 286:999 US customer routes (received from Qwest)
| 286:888 European or US peer routes
|
| 286:3000 + countrycode Country where route is received
|
countrycode E.164 international dial prefix
|
| EXAMPLES
|
| 286:286 286:3031 Customer in Amsterdam
| 286:286 286:3032 Customer in Brussels
| 286:888 286:3044 Peer in London
|
+----------------------------------------------------------
Comment: Aren’t we happy that RPSL has “remarks”!
Need “Semantics of Interdomain
Routing”
• Distinct from mechanism of finding
routings (protocols).
– Don’t start with “new algorithms”!!!
• BGP policy languages/usage have
evolved organically --- lack of design.
– Too closely tied to mechanism of BGP
– RPSL doesn’t even begin to address the
issues…
• What do we want to be true?
• What do we mean by “autonomy”
• How much “expressive power” is really
required?
References
•
[VGE1996, VGE2000] Persistent Route Oscillations in Inter-Domain Routing.
Kannan Varadhan, Ramesh Govindan, and Deborah Estrin. Computer
Networks, Jan. 2000. (Also USC Tech Report, Feb. 1996)
• [GW1999] An Analysis of BGP Convergence Properties. Timothy G. Griffin,
Gordon Wilfong. SIGCOMM 1999
• [GSW1999] Policy Disputes in Path Vector Protocols. Timothy G. Griffin, F.
Bruce Shepherd, Gordon Wilfong. ICNP 1999
• [GW2001] A Safe Path Vector Protocol. Timothy G. Griffin, Gordon Wilfong.
INFOCOM 2001
• [GR2000] Stable Internet Routing without Global Coordination. Lixin Gao,
Jennifer Rexford. SIGMETRICS 2000
• [GGR2001] Inherently safe backup routing with BGP. Lixin Gao, Timothy G.
Griffin, Jennifer Rexford. INFOCOM 2001
– [GW2002a] On the Correctness of IBGP Configurations. Griffin and
Wilfong.SIGCOMM 2002.
– [GW2002b] An Analysis of the MED oscillation Problem. Griffin and Wilfong.
ICNP 2002.
Pointers
• Interdomain routing links
– http://www.cambridge.intelresearch.net/~tgriffin/interdomain/
• These slides
– http://www.cambridge.intelresearch.net/~tgriffin/talks_tutorials
Descargar

An Introduction to Interdomain Routing and the Border