Close
About
FAQ
Home
Collections
Login
USC Login
Register
0
Selected
Invert selection
Deselect all
Deselect all
Click here to refresh results
Click here to refresh results
USC
/
Digital Library
/
Computer Science Technical Report Archive
/
USC Computer Science Technical Reports, no. 777 (2002)
(USC DC Other)
USC Computer Science Technical Reports, no. 777 (2002)
PDF
Download
Share
Open document
Flip pages
Contact Us
Contact Us
Copy asset link
Request this asset
Transcript (if available)
Content
1
An Analysis of The Internal Structure of Large
Autonomous Systems
Ramesh Govindan
University of Southern California
Los Angeles, CA, USA
Email: ramesh@usc.edu
Pavlin Radoslavov
International Computer Science Institute
Berkeley, CA, USA
Email: pavlin@icsi.berkeley.edu
Abstract—This study examines the topological and
geographical structure of eight large Autonomous Sys-
tem (AS) topologies. We use a large collection of
traceroutes obtained from multiple vantage points,
and a set of heuristics designed to infer, from those
traceroutes, the topology of individual ASs. We care-
fully validate some aspects of these topologies using
publicly available information. Our analyses uncover
several interesting common features of these topolo-
gies. We find high variability both in the degree
distribution of individual ASs and in the size of AS
points-of-presence. These ASs seem to be engineered
to match small-world properties: good overall path
lengths with significant local clustering. There is an
interesting locality in the geographic extent of ASs;
there exists a small number of metropolitan areas in
which all ASs have points of presence. Finally, the
density of city-level connectivity of these ASs suggests
some differences in the way these ASs are engineered.
Keywords— Network Topology Measurement, Net-
work Topology Analysis, AS Internal Structure
I. INTRODUCTION
Little is known in the research literature about
the internal structure of very large Autonomous Sys-
tems (ASs). Indeed, there is little public information
about the connectivity characteristics of these sys-
tems at the IP level; circuit-level maps are available
for some ASs [1], but their veracity and their cur-
rency are unknown.
To some extent, curiosity drives the need to un-
derstand AS structure. All wide-area communica-
tions traverse this infrastructure, and it is surpris-
ing that little is known about the characteristics of
these topologies. What is generally known is that
these topologies can be well described by a back-
bone structure comprised of inter-city links. Within
each city, customers connect to the AS at points of
presence (POPs). But beyond that, little exists in the
published literature about AS structure.
There are two more reasons to understand the
structure of large ASs. AS structure, particularly
the geographical structure, affects the performance
of the routing system. Moreover, ASs are dis-
tinct structural units of the Internet topology, and
as such they will form important components of
future router-level topology generators; earlier ap-
proaches to router-level topology generation incor-
porated “transit” networks that were essentially ran-
dom graphs [12]. With the discovery of power laws
in the degree distribution of Internet graphs [17],
there is renewed interest in topology generation [20],
[22], [5], [25], [4]. Our work can provide input to,
or validate, router-level generators that emerge from
this activity.
Our paper represents a first look at the topological
and geographic structure of ASs. It combines the re-
sults of nearly four million traceroutes from six dif-
ferent vantage points (all part of the NIMI [2] mea-
surement infrastructure) to obtain an approximate
router-level representation of the Internet topology
(Section II-A). In this representation, the Internet
topology is represented as a graph in which nodes
are routers and edges connect routers that are one IP
hop from each other. In principle, the technique we
use is similar to other proposed approaches in the lit-
erature [11], [15], [19], but with some modifications
to minimize abuse complaints. We also use a com-
bination of heuristics to determine whether routers
2
belong to two different ASs; this is an improvement
over previous approaches [19].
A key contribution of this paper is a method
for inferring the topology of a specific AS from a
traceroute-derived router-level map (Section II-B).
Previous approaches for doing this have relied upon
inferring the AS to which a router belongs from the
origin AS information in BGP tables [29], [14]. As
we show, the BGP-derived AS information can sig-
nificantly overestimate (sometimes by a factor of 10
or more) the number of routers in a large AS. In
this paper, we describe an approach to extracting AS
topology that leverages some current practices in In-
ternet address assignment and routing.
In our study we select the topologies of eight large
ASs. Due to lack of published information about
the router-level structure of ASs, to validate these
topologies we resort to simple sanity checks, pub-
lished information about the geographical presence
of large ASs, and some anecdotal evidence. As an
approximate indication of the fidelity of our maps
we find that we capture upwards of 70% (and in
some cases all) of the cities that our selected ASs
have POPs in. While this is far from perfect, it in-
dicates that we can at least draw qualitative conclu-
sions from the data we have.
The main contribution of this paper is an analy-
sis of the graph-theoretic properties (Section IV), as
well as the geographic structure (Section V) of these
ASs (for determining the geo-location of routers, we
use GeoTrack [24]). Our analyses uncover some
commonalities and differences between these ASs.
Specifically, our main findings are:
There exists high variability in the degree distri-
butions of individual ASs, as well as in the over-
all distributions of POP sizes (in term of num-
ber of routers). Contrary to previous work [32],
we find some, but not remarkable, correlation
between a city population and POP size.
All AS topologies we studied seem engineered
to have small-world properties: good local clus-
tering and relatively low path lengths. Previous
work [10] has shown that the AS-level graph
has small-world properties. Other engineered
structures, such as the electrical power distri-
bution network have previously been shown to
have such properties as well [30].
There is significant geographic locality in
where POPs are located. There exist ten
metropolitan areas in which almost all of the
selected ASs were present. This indicates that
a new entrant to the Internet backbone mar-
ket need only establish presence at a relatively
small number of sites in order to obtain sig-
nificant connectivity. Furthermore, there were
some surprises in the list of those ten metropoli-
tan areas.
Finally, there were quantifiable structural dif-
ferences between ASs that were evident from
the city-level connectivity structures of these
ASs. In particular, our study was able to plau-
sibly identify ASs that use virtual circuit based
technologies in their backbone.
There exist several aspects of Internet connectivity
that we could have studied, such as the role of ex-
change points in inter-AS connectivity, or a careful
analysis of POP structure. We defer these to future
work.
In addition to the tangentially related work men-
tioned above, there exist two other large measure-
ment studies of the Internet router-level topology.
The first [9] uses a substantially larger collection of
traceroutes, and focuses on analyzing the combina-
torial and graph theoretical properties of the over-
all Internet router-level topologies. In contrast, our
work focuses on the internals of AS structure. A
more recent study [21] uses a substantially larger
collection of traceroute sources than ours and ana-
lyzes various aspects of AS topology. However, our
approach uses more sophisticated heuristics for ex-
tracting AS topology, and our study is focused on
large backbones and has arguably a more represen-
tative collection of the largest ASs in the Internet.
Furthermore, as we show in Section VI, our choice
of a small number of sources suffices for the topol-
ogy properties we study in this paper.
II. METHODOLOGY
In this section, we present our measurement
methodology in two steps: map collection and AS
extraction. In the first step, map collection, we de-
scribe the strategy we use to collect the data. In the
second step, AS extraction, we describe how we pro-
cess the data to extract information about each AS.
3
A. Map Collection
In order to infer the internal structure of the ASs,
we first obtained a router-level map of the Internet.
There are two separable issues in collecting such
map: traceroute-based probing of Internet destina-
tions, and determining which interfaces belong to
the same router (resolving aliases in the terminology
of [19]). We describe these in the following subsec-
tions.
Traceroute-based Probing: Our map collection
strategy is most similar to that described in [11].
Our custom traceroute implementation randomly
selects target addresses from within each address
prefix in a list of address prefixes that is pro-
vided as input to the program. The list is se-
quentially traversed, and is derived from BGP
tables obtained from the Route Views archive
(http://www.routeviews.org). To increase
the rate of coverage of the address space, our soft-
ware can concurrently probe a number of destina-
tions.
The work reported here is different from prior
work in one respect; we use more than one vantage
point.
1
In particular, we combine traceroutes from
six different locations in order to infer our router-
level map of the Internet. In our experiments, all
our measurement points used a BGP table extracted
from the Route Views archive, which itself obtains
BGP feeds from several vantage points. These six
measurement points are all part of the NIMI [2] in-
frastructure. Two of these measurement points were
attached to university networks, two to research lab-
oratories, one to a residential DSL service provider,
and one to a large backbone. Furthermore, with
the exception of one pair, all of the measurement
points had different upstream providers. Thus, our
measurement points represent a reasonable diversity
of connectivity. However, these six measurement
points are all based in North America. This intro-
duces an important bias in our results; although we
do include a large European AS in our analyses, we
are aware that our map of that particular backbone
may be less accurate than the maps of the other ASs.
Caveats about the map resulting from traceroute
The work described in [9] uses data from an infrastructure
deployed at multiple locations, but their analysis is based on the
view from a single location [8].
based topology discovery have been discussed else-
where [19], but they bear repeating in this context.
The accuracy of the whole map is, to a large extent
unquantifiable. Traceroute-based probing does not
uncover all the interfaces of a router. Finally, robust
heuristics for differentiating between shared media
and point-to-point links are yet to be found. Many of
these caveats hold, perhaps to a lesser extent, even
when maps are derived from several measurement
points.
The logistical problems of collecting Internet
maps using traceroute based probing have been well
documented elsewhere [11], [19]. Attempting to col-
lect maps from multiple locations only increases the
exposure to abuse complaints from organizations. To
minimize and centralize such complaints we used
a simple mechanism that is interesting in its own
right. All traceroutes emanating from our six mea-
surement points use the same IP source address. This
is the address of a central measurement collector
box. Thus, all responses to the traceroute requests go
to the collector. This is convenient because it simpli-
fies the collection of the results. More importantly,
it centralizes the handling of abuse complaints; all
of our traceroutes appear to be emanating from the
site at which the collector is situated! This tech-
nique doesn’t affect our results, since we are only
interested in inferring router adjacencies (neighbor
relationships), and we do not use any timing-related
information. However, this technique is only appli-
cable as long as ingress filtering [18] is not widely
deployed; it clearly wasn’t deployed at our six sites,
otherwise we would not have discovered any topol-
ogy information at all.
All the maps reported in this paper were inferred
from nearly 4 million traceroutes collected between
November 30, 2001 and December 12, 2001.
Resolving Router Aliases: Traceroutes can dis-
cover different interfaces belonging to a router. This
is particularly true for traceroutes sent from multi-
ple vantage points. Traceroutes themselves do not
contain enough information information to resolve
interfaces belonging to a router. In order to do this
(a task necessary to determine the internal structure
of an AS), a separate probing technique is necessary.
One technique (which we shall call UDP-based
alias resolution), first proposed by [26] and later
4
used by [19], relies on a common feature of most
IP stacks. That feature is best described by exam-
ple. Suppose we wish to determine whether inter-
faces
and are attached to the same router. To
do this, we send two UDP packets
2
with a high des-
tination port number, one each to
and . If we
have guessed an unused port number correctly, then
each of these probes elicits an ICMP Port Unreach-
able message. However, when sending the ICMP
response, many implementations use the IP address
of the interface on which the packet was sent out
as the source address of the responses. Thus, if the
ICMP responses to both our probes have the same
source address
, we know that interfaces
and must belong to the same router.
UDP-based alias resolution has one nice property.
Assuming that there is one dominant return route
from the responder, the probes to
and need not
be sent simultaneously. If routing doesn’t change,
the probes can actually be separated in time and still
return the correct result. (Note that even if the probes
are sent back-to-back, there is a chance, however
small, of getting a false negative). This property can
be used to reduce the alias resolution overhead, since
the overhead of determining aliases grows linearly
with the number of interfaces to be tested.
However, recent experimentation (by us and oth-
ers) suggests that this technique is not perfect. In
some cases (less than 1 in 1000), this technique re-
ports that two successive hops in a traceroute belong
to the same router. This could be a flaw in the tech-
nique, but could equally likely be an implementation
artifact in which some routers decrement TTL twice,
causing one router to appear as two hops in a tracer-
oute. More seriously, however, this technique has
a non-trivial rate of false negatives;
3
up to 30% (in
some cases) of interface-router equivalences are not
reported as such.
Accordingly, in this paper, we use another alias
resolution technique that we call identifier-based
alias resolution.
4
Identifier-based alias resolution
leverages on the fact that most implementations use
Those packets don’t have to use UDP. Any packet designed
to trigger an ICMP response at a layer higher than IP would
works. An example is an IP packet with an unused protocol
number. We have verified this by experimentation.
Ratul Mahajan and Neil Spring get credit for this discovery.
We first heard of this technique from Vern Paxson.
sequentially increasing IP identifiers. To determine
if
and are interfaces that belong to the same
router, identifier-based alias resolution would send
an ICMP Echo packet to each of
and . If
the ICMP Echo Replies had IP identifiers that were
within of each other, for some small integer ,
then one might suspect that
and belong to the
same router. Of course, since the IP identifier field is
small, this test is prone to false positives; a small
number of retries are usually sufficient to resolve
these.
This technique is not without its drawbacks. It re-
quires that interfaces be tested pairwise; the probes
to
and must be sent almost simultaneously.
5
Second, we have found in our experimentation that
this test too has a somewhat non-trivial rate (about
5% from one sample) of false negatives.
Accordingly, in our paper, we use a combination
of these two approaches.
B. ASs Extraction Methodology
After generating the router-level map by combin-
ing traceroutes and resolving router aliases, the next
step in our analysis was to extract the topologies of
individual ASs, and to determine their geographic
extent. Extracting the topologies of individual ASs
turned out to be a non-trivial exercise. In particular,
determining which router belongs to an AS required
referring to a variety of sources of information, and
carefully analyzing our traceroute information. We
discuss these techniques below.
Why AS Extraction is Hard: Recall that we
start with a router-level map, and would like to ex-
tract the router-level topology of, say, AS
. In our
analyses, we assume that AS boundaries intersect
at links, not at routers. That is, a router is entirely
owned by a single AS. Then, the problem of extract-
ing AS
reduces to determining whether a given
router belongs to
or not.
We first consider the simpler step of determining
whether a given IP address belongs to
or not.
To do this, previous work [29], [14] has used in-
formation from the BGP routing table[3] and from
the RADB database[23]. The BGP table indicates
which set of IP addresses have AS
as their origin.
More precisely, a little bit more than 1 second apart to avoid
being subject to ICMP rate-limiting.
5
However, it is well known that many Internet Ser-
vice Providers (ISPs) aggregate AS path information
in the BGP tables and, in doing so, may strip-out the
AS numbers that belong to their customers. Thus, an
IP address belonging to a customer might be incor-
rectly labeled as belonging to AS
.
An obvious next step is to filter out these false
positives (i.e., customer IP addresses being labeled
as belonging to
) using routing registries such as
the RADB. These registries contain route objects
which are administered by designated maintainers.
If the route object associated with a particular IP ad-
dress does not have AS
as its maintainer, we can
safely assume that the IP address does not belong
to AS
. However, this technique cannot eliminate
all false positives. The RADB is known to be in-
complete and out of date. Furthermore, in current
practice, providers might actually insert and main-
tain route objects on behalf of their customers.
An alternative approach would have been to use
DNS. This approach relies on resolving the host
name associated with the IP address, and inferring
whether it belongs to AS
from cues in the host
name. This works well, modulo a problem we de-
scribe later, when the inverse DNS resolution ex-
ists. However, we discarded this approach when we
found that of the IP addresses that the BGP tables in-
dicated belonged to an AS, about 20% (but, in some
cases, up to 50%) of the IP addresses were not re-
solvable. We did use DNS cues, as we describe be-
low, to inform our final heuristic.
The address registries (operated by ARIN, AP-
NIC and RIPE) offer another, potentially more reli-
able source of information for determining whether
an IP address belongs to AS
. The address reg-
istries collectively maintain the tree of address dele-
gations. The interface to these registries is the pop-
ular whois software. Address registries contain a va-
riety of information, but most relevant to our work is
the inetnum object. This object essentially maps
an IP address range to a “NIC handle”. The latter
is an unique identifier for the entity to which the
address block has been delegated. We found that
address registries are better maintained than routing
registries, presumably because the data in them is
actually used (e.g., to determine the sources of abuse
activity and to direct abuse complaints). For this rea-
son, we suspect that at least the top tier providers we
study are careful to require that their customers reg-
ister address delegations in the address registry.
The “NIC handle” associated with an inetnum
object is the key to using the address registry for de-
termining whether an IP address belongs to AS
or not. It turned out that most of the ASs that we
wanted to study use an easily identifiable set of NIC
handles for IP addresses that are part of their infras-
tructure (i.e., not delegated to anyone else). This set
either contains one or two NIC handles (for example,
most of AS 1’s infrastructure uses the NIC handle
“GNTY-4-0”), or the NIC handles are named using a
consistent pattern (for example, most of AS 701’s
NIC handles start with “UUNET”). Thus, given a
NIC handle associated with an IP address, we can
easily determine whether the IP address belongs to
. Determining this set takes some manual work
and uses DNS cues, which we explain later.
However, we haven’t solved the problem com-
pletely. The most pernicious problem of all is the one
we now describe. Consider the link between an AS’s
router and its customer’s router. Both ends of that
link have to belong to the same subnet (an IP require-
ment). The IP addresses for the subnet have to come
either from the AS’s address space, or from that del-
egated to the customer. In most cases, this link is
addressed from the AS’s address space. Thus, an in-
terface that belongs to a customer router may actu-
ally be labeled from the AS’s address space. If we
know all interface addresses of the customer router,
then we can disambiguate this situation; presumably
not all of the interfaces of that router would be la-
beled from that AS’s address space. However, recall
that one of the limitations of traceroute based map-
ping is that it often does not reveal all the interfaces
of a router.
Extracting an AS: To overcome these obsta-
cles, we came up with the following set of heuristics
that attempt to successively refine the collection of
routers that belong to AS
. These heuristics err on
the side of caution when not enough data is available
to mark a router as conclusively belonging to the AS.
In this sense, our heuristics probably underestimate
the ASs we include in this study. As we shall see,
these heuristics leverage properties of current prac-
tice in IP address assignment and routing.
6
Step 1. Like previous work, we start by using the
origin AS in the BGP table to determine if an IP ad-
dress in our map belongs to AS
or not.
Step 2. We examine the routing registries (the
RADB) to refine the set of interfaces marked by step
1 as belonging to AS
. If the routing registry data
tells us that an interface does not belong to the AS,
we unmark the interface. Strictly speaking, step 2 is
not necessary, but step 3 is time consuming, and us-
ing the RADB for refinement helps to speed up the
AS extraction.
Step 3. We determine the NIC handles of all
IP addresses that are still thought to belong to AS
. We discard all interfaces whose NIC handles
do not belong to the set of NIC handles known to
be in use by the AS. We manually determined this
set, using cues from AS DNS labeling conventions.
For example, we found that what were clearly DNS
entries for AS 1’s routers (e.g., DNS names end-
ing in ...-cr3.bbnplanet.net had the asso-
ciated NIC handle GNTY-4-0), and used these to
obtain the set of NIC handles.
Step 4. If a router has multiple interfaces, and
a majority of its NIC handles belong to AS
, we
mark the router as belonging to AS
. The majority
rule
6
is necessary because some routers that belong
to an AS have interfaces attached to an exchange
point, and those interface addresses sometimes have
different NIC handles. If the only interfaces we dis-
cover for the router are of this type, we are not able
to determine whether the router belongs to AS
, so
we mark the router as belonging to a customer.
Step 5. For a router with a single interface, if that
interface address appears in any traceroute between
two routers that have already been marked as belong-
ing to AS
, we mark that router as belonging to AS
. This step relies on the fact that a path between
two routers in an AS stays within the AS (a property
of the current routing system).
7
In some cases, this rule will incorrectly mark a router. For
example, many customer routers have two circuits to their
providers, so they have multiple interfaces whose NIC handles
belong to AS
’s space. We were careful to flag and handle
these cases, often using DNS cues.
This property holds in the steady state, but may be violated
by routing transients. We have observed at least one traceroute
that exited and re-entered an AS. To avoid this, we are careful to
mark the router only if two traceroutes satisfy the property. The
Step 6. Our final rule for marking routers with a
single interface can be explained by considering a 3-
hop traceroute fragmentA--B--C. Assume thatB is
the interface address on a router with a single known
interface, andB has not been marked in Step 5. If by
our previous rules, A is marked as belonging to AS
, andC is marked as not belonging to AS
, then
we conservatively markB as not belonging to AS
.
That is, we assume that B belongs to a customer of
AS
even though the address of B may belong to
’s address space. But, if A is marked as not be-
longing to AS
, andC as belonging to AS
, then
we mark B as belonging to AS
(all our previous
heuristics would have pruned other interfaces) for a
similar reason.
Assigning Router Geographic Locations: After
we identified the routers that belong to an AS, we
used GeoTrack [24] to determine the geographic lo-
cation of each of the routers. GeoTrack is a tool
for determining the geographic location of Internet
hosts. To do this, GeoTrack uses heuristics based on
the DNS names to find the locations of the routers
topologically close to hosts. We use these heuristics
in our study; these heuristics and their shortcomings
are well-documented in [24], so we do not repeat
them here.
Interestingly, almost all of the largest providers
used DNS naming schemes for their routers that
were based on some variation of the city name where
a router is located. However, this technique is not
without its flaws. Occasionally, either because of
DNS misconfiguration or because of inaccuracies in
GeoTrack’s original configuration, there are conflict-
ing locations for interfaces belonging to the same
router. We manually resolved these conflicts by vi-
sual inspection of the traceroutes, or by using con-
text information. In some cases, by examining the
traceroute, it was clear that a router’s DNS name had
been misconfigured; we found, for example, a tracer-
oute within a large provider where one router’s DNS
name indicated that it was located in Newark, while
both the previous hop and the next hop were in Hous-
ton, as was the customer that the traceroute eventu-
ally led to. In other cases, it was clear that GeoTrack
property may also be violated by practical provider-customer
BGP configurations (RFC 2270), but can be expected to hold
for the ASs studied in this paper.
7
didn’t have the right context to determine router lo-
cations. It placed a European ISP’s in Stockton, CA,
while the correct location should have been Stock-
holm, Sweden.
Our analyses in Section V depend on these loca-
tion assignments.
The Results of Our AS Extraction: Having de-
termined a reasonable AS extraction strategy (in
Section III we discuss why we think our strategy
is reasonable), we were faced with the question of
which ASs to study. Clearly, of most interest from a
topology modeling and routing perspective are large
national or international backbones. We chose eight,
largely from those we had suspected to be large ASs
(Figure 1(a)). As it turns out, all of the companies
that own one of those eight ASs are in at least one
list of top 10 ISPs.
8
In this sense, our collection of
eight ASs probably represents a large chunk of the
wide-area connectivity of the Internet.
We had intended to include two more ASs: Verio
(AS2914) and ChinaNet (AS4134). Recall that our
labeling heuristic depends on being able to identify
consistent usage of NIC handles. Verio did not have
such a consistent usage, therefore we could not ap-
ply some of our heuristics. For ChinaNet, we found
that less than 200 IP addresses (out of 2799 potential
addresses) have inverse DNS entries, and we could
not reliably use DNS cues to inform our heuristics.
III. TOPOLOGY VALIDATION
While there have been various pieces of work on
router-level topology discovery, very few have at-
tempted to validate the resulting topologies in a rig-
orous manner. Obtaining router-level maps of ASs,
certainly the most direct way of validating the map,
is difficult. Other work has attempted to validate
such maps indirectly [19]. We resort to this kind of
indirect validation as well. This does not provide
us rigorous estimates for the inaccuracies, but only
loose bounds.
Our first indirect validation uses the approach pro-
posed by Barford et al. [7]. Consider our collection
of measurement points. Suppose that is the
largest fraction of nodes (or links) in all our eight ex-
tracted ASs discovered only using traceroutes from
http://www.nwfusion.com/newsletters/
isp/2001/00846039.html
of our measurement points. Figure 1(c) plots
as a function of . Intuitively, if with each suc-
cessive up to , increases significantly, then we
might consider our set of six measurement points to
have been insufficient. That is, this test does not
quantify the completeness of the discovered topol-
ogy, but can indicate whether the set of measure-
ment points was insufficient. We note from the figure
that three sources were sufficient to discover more
than 80% of the nodes and links discovered by all
six measurement points. We are thus reassured that
our measurement methodology is at least in the right
ballpark.
Our second set of validations tests whether we ac-
curately capture the geographic extent of our ASs.
Since a significant piece of our analysis deals with
AS geography, this is an important step. To do this,
we rely on publicly available maps of the AS topolo-
gies, available at the Web sites of each of the ASs’
backbone providers. These maps are not router-
level maps. Rather, they represent city-to-city circuit
level connectivity. Therefore, from our router-level
maps, we extracted the city-level interconnectivity
and compared these against the published maps. Be-
cause those maps are in image form, most of this
validation required manual effort. Figure 1(b) sum-
marizes the results of this effort. In most cases, we
discovered upwards of 75% of the cities that were
listed on the ISPs’ Web pages.
There are reasons to believe that the fraction of
cities we have found may actually be higher. ISPs
often put up maps with projected buildout, and often
these projections are optimistic. Moreover, in sev-
eral cases our extracted maps discovered few cities
that were not listed in the published maps (Fig-
ure 1(b) omits these).
Because the published maps are usually at the cir-
cuit level and it is unclear how this corresponds to
connectivity observed at the IP-level (e.g., if an AS
uses a virtual circuit based technology), we could
not validate the number of links, except for one
AS (AS209, where we assumed that the circuit-level
connectivity correlates with city-level connectivity).
Overall, of the links between the cities in AS209 that
we actually discovered, we found 75% of them (we
found a smaller fraction, 50%, of all the links in the
published map). We stress, however, that this num-
8
AS Name Nodes Links
AS1 BBN-Genuity 143 169
AS1239 Sprintlink 633 1499
AS209 Qwest 235 344
AS3549 Global Crossing 370 1084
AS3561 Cable and Wireless 560 1090
AS701 UUNet 1005 2754
AS7018 ATT Worldnet 177 315
AS702 UUNet Europe 527 861
(a) AS Table
AS Found Cities Total Cities Fraction
AS1 23 35 0.66
AS1239 14 18 0.78
AS209 19 26 0.73
AS3549 20 26 0.77
AS3561 38 42 0.90
AS701 49 63 0.78
AS7018 17 18 0.94
AS702 17 17 1.00
(b) AS Validation
0
0.2
0.4
0.6
0.8
1
1 2 3 4 5 6
Fraction found
Number of traceroute sources
Fraction of incrementally found nodes and links : best source first
Nodes
Links
(c) Map Validation
Fig. 1. AS Extraction and Validation
ber is subject to the same caveat above—that this
map may represent the projected buildout of the AS
and so we may have discovered a higher percentage
of the existing links.
Our final set of validations targets our careful ex-
traction heuristics (Section II-B). We have heard
anecdotally
9
that Sprintlink has about 720 routers.
Our heuristics discovered 633 routers. More impor-
tantly, there is a well-known technological limitation
on AS sizes. We are told
10
that in current implemen-
tations of IS-IS (the IGP of choice for top ISPs), SPF
computation overhead on networks with more than
1000 routers is unacceptable. For this reason, most
ISPs engineer their networks to have fewer routers
than this limit. We are encouraged that our ASs
sizes conform to this limit (the largest, AS701 is just
above a thousand routers).
Given this discussion, it should be clear that our
topology discovery provides only approximate indi-
cations of AS topology. Therefore, we are careful
to draw only qualitative conclusions about AS struc-
ture. For this reason, we believe that our conclusions
will not be invalidated by more accurate topology
discovery methods.
IV. RESULTS: ASS GRAPH-THEORETICAL
PROPERTIES
We are now ready to discuss our analyses of the
ASs listed in Figure 1. The starting point of our anal-
ysis is the generally known fact that ASs with na-
tional or international extent have a number of POPs
Tim Roscoe in a message sent to the SAHARA research
group.
Thanks to Cengiz Alaettinoglu for this information.
situated in metropolitan areas to which their cus-
tomers connect, and these POPs are interconnected
by a backbone that spans a large geographic extent.
Accordingly, two aspects of AS structure are rele-
vant to our analysis:
ASs graph theoretic properties. By this we
mean standard graph measures for node degree
and path lengths. We study these properties of
AS graphs in this section.
ASs geographic extent. Unique to AS topolo-
gies is the fact that their overall structure is
heavily determined by geography. We analyze
the geographic properties of AS graphs in the
next section.
In some of what follows, we depict graphical rep-
resentations of AS topology. These representations
were obtained using the graph visualization software
graphviz [27]. This software includes a tool called
neato for laying-out undirected graphs using an iter-
ative layout optimization technique.
A. Aggregate Topological Properties
Our first set of analyses looks at standard graph-
theoretic characterizations of path length and con-
nectivity in these graphs (Figure 2). In this section
we discuss these metrics.
Figure 2(a) shows the diameter and the average
path length (the average shortest path, in terms of IP-
level hops, between any two nodes) for each of our
ASs. Interestingly, the diameter of most ASs is be-
tween 12 and 16 hops, with two outliers. AS702 has
a larger diameter; recall that AS702 is a European
backbone and our measurement points are in the US,
therefore our map may be overestimating the diam-
eter. AS3549 has a remarkably small diameter of
9
! ! ! ! ! ! ! ! ! ! " " " " " " " " " " ## ## ## ## ## ## ## ## ## ## $$ $$ $$ $$ $$ $$ $$ $$ $$ $$ % % % % % % % & & & & & & & ’ ’ ’ ’ ’ ’ ’ ’ ’ ( ( ( ( ( ( ( ( ( ) ) ) ) ) ) * * * * * * + + + + + + + , , , , , , , -- -- -- -- -- -- -- -- .. .. .. .. .. .. .. .. // // // // // // // // // 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 Diameter
2
4
6
8
10
12
14
16
18
Number of hops
Autonomous System
AS1 AS1239 AS209 AS3549 AS3561 AS701 AS7018 AS702
Average path length
0
(a) Average Path Length
and Diameter
33 44 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 66 66 66 66 66 66 66 66 66 66 66 66 66 66 66 66 66 66 66 66 66 66 66 66 66 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 : : : : : : : : : : : : : : : : : : : : ;; ;; ;; ;; ;; ;; ;; ;; ;; ;; ;; ;; ;; ;; ;; < < < < < < < < < < < < < < < == == == == == == == == == == == == == == == == > > > > > > > > > > > > > > > > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD Random graph characteristic path length
1
2
3
4
5
6
7
Number of hops
Autonomous System
AS1 AS1239 AS209 AS3549 AS3561 AS701 AS7018 AS702
Characteristic path length
0
(b) Characteristic Path
Length
EE FF GG GG GG GG GG H H H H H II II II II II II II II II II II II II II II II II II II II II II II II II JJ JJ JJ JJ JJ JJ JJ JJ JJ JJ JJ JJ JJ JJ JJ JJ JJ JJ JJ JJ JJ JJ JJ JJ JJ K K K K K K K K K K K K K K L L L L L L L L L L L L L L M M M M M M M M M M M M M M M M N N N N N N N N N N N N N N N N O O O O O O O O O O P P P P P P P P P P Q Q Q Q Q R R R R R S S S S S S S S S S S S S S S S S S S S S S S S T T T T T T T T T T T T T T T T T T T T T T T T U UV V Random graph clustering coefficient
0.1
0.2
0.3
0.4
0.5
0.6
Clustering coefficient
Autonomous System
AS1 AS1239 AS209 AS3549 AS3561 AS701 AS7018 AS702
Small world clustering coefficient
0
(c) Clustering Coefficient
0.0001
0.001
0.01
0.1
1
1 10 100
Complementary Cumulative Fraction
Degree
AS1
AS701
(d) Degree Distribution
Fig. 2. Graph Metrics
only eight hops; we shall see an explanation for this
in Section V. The average path length of each AS
lies between 4 and 7. In other words, the diameter
and average path length of all the ASs are compara-
ble, in spite of the AS sizes are so vastly different.
This indicates that there is a fair amount of careful
engineering that results in keeping hop limits across
an AS low since each IP-level hop incurs router pro-
cessing and possibly queueing latency.
Another way to look at this is to study the
small-world properties of AS-level topologies [30].
A small-world graph is characterized by low path
lengths (comparable to a random graph), but high
local connectivity (comparable to a lattice). In par-
ticular, two metrics are used to study small-world
graphs. The characteristic path length measures the
median (across all vertices) of the average shortest
path from a vertex to all other vertices. The clus-
tering coefficient measures the average clustering at
a node, which is defined as the ratio of direct links
between neighbors of that node, to the number of
links in a complete graph connecting neighbors of
the node. One test for a small-world graph is if its
characteristic path length is comparable to a random
graph of the same size and average degree, but its
clustering coefficient is significantly higher.
Figure 2(b)-(c) plots the characteristic path length
and clustering coefficient for each of our AS graphs,
together with the corresponding quantities
11
for a
comparable random graph. We find, with perhaps
the exception of AS702, that while all graphs ex-
Given a graph with
W nodes and average degree
X , the
characteristic path length of a comparable random graph is
Y[Z]\
W]^‘_
Y[Z]\aX
^ , and the clustering coefficient of the correspond-
ing random graph is
X _bW
.
hibit characteristic path lengths that are comparable
to random graphs, they all exhibit much higher clus-
tering than random graphs.
12
Thus, we conclude that
AS structures exhibit small-world properties. Many
social networks have been shown to have emergent
small-world properties [30]. Some engineered net-
works, such as the electrical power grid, have also
been shown to have such properties. Our finding fits
into the latter category, and has a plausible explana-
tion; there is significant engineering within an AS to
ensure that local traffic stays local, while wide-area
traffic encounters few IP-level hops. Here we should
note that inter-AS topology also has been shown to
have small-world characteristics [10].
Finally, this finding implies that random graphs
may not be good models for the transit portion of
a network [12].
B. Analysis of Degree Distributions
Topology degree distributions have received a fair
amount of recent attention following the work of
Faloutsos et al. [17]. In this section, we examine
the node degree distributions of our AS topologies.
Before we do this, recall that the degree of a router in
our topologies is a measure of how many neighbors
it has within one IP hop. This number may be dif-
ferent from the number of interfaces that that router
has, in the event that some of the router’s interfaces
are attached to shared media.
We find that all our AS topologies show a highly-
variable degree distribution. By this we mean that
Note that in particular, the clustering coefficient is sensitive
to missing links. Our values probably underestimate the actual
clustering in AS graphs.
10
the empirically observed degrees vary by almost two
orders of magnitude. Figure 2(d) shows the degree
distributions of our smallest and largest ASs. Cer-
tainly, especially for AS 701, it cannot be said that
the degree distribution follows a power-law, but that
does not detract from the result that there is a wide
range of observed degrees. Furthermore, the drop-
off in the tail of the degree distribution for AS701
is expected; technological limitations limit the num-
ber of router interfaces, and traffic volume consider-
ations limit the number of neighbors. We should note
that the degree distribution of the inter-AS topology
varies across 3 orders of magnitude [13]. It is quite
possible for an AS as whole (i.e., a node in the inter-
AS topology) to have an order of magnitude more
neighbors than a single router within that AS has.
AS core edge
AS1 2 8
AS209 3 7
AS1239 7 3
AS3549 8 2
AS3561 10 0
AS701 0 10
AS7018 5 5
AS702 8 2
Fig. 3. Where are the high degree nodes?
We also examined where the ten highest degree
nodes for each AS are to be found; i.e., whether in
the “core” or at the “edge”. In our maps, there is
a fairly clean distinction between edge and core; a
router at the edge has more neighbors that do not
belong to the AS, than those that do. Using this def-
inition, we find a surprising pattern (Figure 3): that,
barring AS 7018, for most of the ASs the ten high-
est degree nodes are either predominantly in the core
(AS 1239, AS 3549, AS 3561, AS 702) or predom-
inantly in the edge (AS1, AS209, AS701). We re-
visit this in Section V-B in connection with analyz-
ing the geographical structure of the ASs. It is im-
portant to understand where the high-degree nodes
are for the following reason. At least one study has
concluded that networks with high degree variability
are susceptible to deliberate attack by removal of a
few high degree nodes[6]. For the router-level graph,
however, if many of the high degree nodes are at the
edge of large ISPs, removal of these nodes will still
preserves significant transit connectivity.
V. RESULTS: ASS GEOGRAPHIC EXTENT
The results discussed so far ignore geographic lo-
cations of routers in an AS. However, particularly for
the large national and international ASs, their topol-
ogy is heavily influenced by geographic considera-
tions. In this section, we examine several aspects
of AS geography. Our unit of geography usually
corresponds to a city, the granularity at which Geo-
Track [24] reports router locations.
A. Visualizing Geographic Connectivity
In this section, we explore the visualization of an
abstracted version of AS topology that attempts to
capture the inter-city connectivity of an AS. We call
this abstracted representation of an AS a geo-graph.
Nodes in a geo-graph are distinct geographic loca-
tions. Thus, if there exists at least one router in the
AS topology in a city
, the AS’s geo-graph contains
a node corresponding to
. Links in a geo-graph
represent inter-city links in the AS topology. Thus,
if there exists at least one link in the AS router-level
topology connecting a router in city
to a router
in city , we draw a link between
and in the
AS’s geo-graph. Geo-graphs are undirected and un-
weighted. It is possible to consider weighted ver-
sions of these graphs, either weighted by the actual
number of links between the cities, or by the geo-
graphic distance between them. This extension is left
for future work.
We computed the geo-graphs for all of our ASs,
and applied neato to layout the graphs. In many
cases, the geo-graph of an AS reveals interesting
structural features; some of these we discuss in this
section.
The geo-graphs of our smaller ASs (AS1, AS209
and AS7018) are relatively sparse. At the city-level,
AS7018’s geo-graph (omitted for brevity) appears
almost planar by our layout. However, it doesn’t cor-
respond to a canonical graph structure like a ring, or
a star, for example. The same is true for the other
smaller ASs (those figures are omitted for brevity).
We next consider the slightly larger AS3549 (Fig-
ure 4(a)). This AS’s geo-graph has a qualitatively
different structure compared to the smaller ASs; a
densely meshed core indicating a very high level of
connectivity between cities.
11
(a) AS3549 (b) AS701 (c) Geographic layout of AS701
Fig. 4. Geographs of some ASs
Our largest AS, AS701, exhibits a slightly differ-
ent structural characteristic (Figure 4(b)). It appears
to consist of a relatively densely connected core set
of cities, to which several “satellite” cities are at-
tached.
We should emphasize that the geo-graphs we de-
pict in this picture are not geographically laid out;
that is, we did not place cities at their correspond-
ing geographic locations. Such a layout actually ob-
scures some features of AS structure, as Figure 4(c)
shows for AS701.
B. Geo-Graph properties
Care must be taken in drawing hard conclusions
from visualizations. Our experience has been that
too often layout artifacts can lead us astray. In this
section, we try to quantify at least one structural dis-
tinction that we discovered in Section V-A.
As a first step, Figure 5(a) shows the number of
nodes and links in the geo-graph of each of our
AS’s.
13
At a quick glance, one startling feature of
this table is that some ASs have a large number of
inter-city links.
To understand this better, we plot the average de-
gree of each of the geo-graphs (Figure 5(b)). The
interpretation of this metric is the average number
of inter-city links emanating from a city. Three
ASs stand out in the figure from the rest: AS3549,
There is a discrepancy between the number of cities re-
ported here for each AS, and the number of cities reported in
Figure 1(b). In the latter, we only count the number of cities
that were found in our map among the ones listed on the AS’s
Web page.
AS3561, AS701. They appear to have very dense
geo-graphs; all the others have sparse graphs.
Clearly, there is a qualitative difference between
these two sets of ASs. To understand this difference,
recall that our AS topology maps (from which the
geo-graphs are derived) depict router-level connec-
tivity (i.e., two routers are adjacent if they are one IP
hop away from each other). In this representation,
the details of the link layer connectivity are hidden.
Therein, we believe lies the explanation for the dif-
ference in graph degrees; these three ASs use virtual
circuit technologies in all or part of their core. That
is, they fashion IP-level links using either MPLS tun-
nels, ATM PVCs, or WDM lightpaths. This explana-
tion also makes economic sense to us. Since physical
inter-city circuits are expensive, it is unlikely that all
of the inter-city links in dense ASs represent physi-
cal circuits.
This also partially explains a few of the earlier
findings in this paper. In Section IV, we found that
AS3549 had a remarkably low diameter. We also
found that in AS3549 and AS3561, most of the high
degree nodes are in the core of the network. Both of
these findings can be attributed to their structure, the
dense core. Note however, that having a dense core
does not necessarily imply that high degree nodes are
at the core. AS701 is a good counter-example, and
this may be because only part of its backbone seems
to be densely connected (Figure 4(b)).
There seems to be some correlation between
sparseness and size. All of our small ASs are sparse.
AS1239, which is a relatively large AS, is also
sparse. We are unsure if there is a causality here.
12
AS Number of cities Intercity links
AS1 25 28
AS1239 28 45
AS209 23 32
AS3549 45 239
AS3561 48 141
AS701 53 124
AS7018 33 44
AS702 93 134
(a) Graph Size
AS702
2
4
6
8
10
12
Average degree
Autonomous System
AS1 AS1239 AS209 AS3549 AS3561 AS701 AS7018
0
(b) Average Degree
Count of ASs City
8 Washington, DC
8 New York, NY
7 Seattle, WA
7 Chicago, IL
7 Atlanta, GA
6 San Jose, CA
6 Palo Alto, CA
6 Kansas City, MO
6 Houston, TX
6 Dallas, TX
(c) Locality of Pres-
ence
Fig. 5. Geograph Properties
There is also some correlation between the number
of cities at which an AS is present and its sparse-
ness. Dense ASs are present in many cities (the one
exception is AS702). There may be some causality
between denseness and geographic extent. Our ob-
servation (Section IV) is that ISPs appear to engineer
for lower hop-lengths; if an AS is present in a large
number of cities, a densely meshed IP-level connec-
tivity built on top of a virtual circuit core seems to be
one way to achieve this.
Finally, we point out that many router-level topol-
ogy generators assume that link costs are determined
by geographic distance between nodes [31], [16].
Our findings suggest that the cost structure for links
might be a bit more complicated than that. Router-
level links may be built out of virtual circuits, and the
cost for these is actually determined by amortizing
the cost required to set up the underlying link-layer
connectivity over all the inter-router virtual links.
C. Locality of Presence and Connectivity
So far we have focused on the large-scale structure
of inter-city connectivity, and on the properties of the
resulting geo-graph. We now turn our attention to
commonalities in geographic presence of our eight
ASs.
Figure 5(c) shows the cities in which at least 6 of
our ASs had presence. Of the 195 cities in which our
ASs collectively had presence, at least six of them
touched down at 10 cities. This indicates significant
geographic locality of connectivity. In a colloquial
sense, Washington and New York represent the cen-
ter of the Internet. There are not too many surprises
in this list; most of the cities listed here have large
population and are financial centers. The one possi-
ble exception is Kansas City. We conjecture that its
geographic centrality influences its presence on this
list.
This locality finding has an important implication.
Services that build high-performance routing over-
lays (such as Internap
14
) need only be present at a
relatively small number of places in order to get good
coverage among the large ASs.
The next obvious question to examine is pair-
wise geographic commonality. Figure 6(a) shows
the pairwise presence of the ASs. Each element in
this table has two entries. The first one depicts how
many cities were common to the corresponding ASs.
Looking pairwise at the common presences, we find
a similar story. Most AS pairs share a common pres-
ence in more than ten cities, and many in substan-
tially more. The one exception is AS702, our Euro-
pean AS. It shares only two cities (Washington and
New York) with some of the ASs in our study. These
ASs do not have any European presence. This high
degree of pairwise locality among North American
ASs indicates a fairly healthy competition for cus-
tomers, but also has implications for routing. If two
ASs have a high degree of pairwise geographic lo-
cality, each can efficiently handoff traffic (using hot-
potato routing, i.e., earliest exit) to the other’s cus-
tomers very close to the origin of the traffic.
For this to happen, however, the two ASs must
actually connect at these cities. The second entry
in each element of Figure 6(a) shows the number of
cities in which the corresponding ASs actually had
a router-to-router link. This number is surprisingly
http://www.internap.net/
13
AS AS1 AS1239 AS209 AS3549 AS3561 AS701 AS7018 AS702
AS1 - 6/4 11/5 16/0 11/1 17/3 15/0 2/0
AS1239 6/4 - 8/4 13/2 16/8 11/11 9/3 11/0
AS209 11/5 8/4 - 19/1 14/7 17/4 16/1 2/0
AS3549 16/0 13/2 19/1 - 27/6 24/8 18/2 11/0
AS3561 11/1 16/8 14/7 27/6 - 22/4 13/1 13/0
AS701 17/3 11/11 17/4 24/8 22/4 - 23/1 3/2
AS7018 15/0 9/3 16/1 18/2 13/1 23/1 - 2/0
AS702 2/0 11/0 2/0 11/0 13/0 3/2 2/0 -
(a) Presence Table
X
Y
A
B
g
h
(b) Measurement
Artifact
Fig. 6. Pairwise Presence
low! We first thought that this indicated that ISPs
were not taking advantage of local traffic handoff op-
portunities, but later realized that this data was an in-
teresting artifact of our measurement methodology.
Figure 6(b) explains this artifact. Suppose that our
measurement point at
attaches to AS
, and
connects with another AS at two cities and .
Now, suppose that
sends a traceroute to ; the
forward path from
to will always be handed off
(using hot-potato) at , and the traceroutes from
will never see the connection in city , even though
it may be used to handle the traffic from to
for
example. To capture all such connections between
and , one would need measurement points in every
city the two are co-located.
D. Points-of-Presence Statistics
Our final set of statistics concerns AS POPs. Re-
call that by using GeoTrack we were able to ap-
proximately assign geographic locations to individ-
ual routers. In order to study the characteristics of
POPs we assume that all the routers in a city belong-
ing to the same AS are located at the same POP.
This is only approximately true; within a city or
a metropolitan region, ASs may have “distributed
POPs”. These connect clusters of routers located at
different facilities within a city.
The first statistic we look at is the distribution of
POP sizes across all ASs (Figure 7). This distribu-
tion is highly variable, varying over two orders of
magnitude. The tail of the distribution drops off no-
ticeably, probably reflecting the fact that there are
physical limitations to large POPs (e.g., electrical
power supply or physical space).
One possible explanation for this high variability
in POP size is that POP sizes (and more precisely
0.001
0.01
0.1
1
1 10 100 1000
Complementary Cumulative Fraction
Number of Routers in POP
Fig. 7. POP size distributions
the number of routers in a city) reflect the amount
of infrastructure needed to support a given popula-
tion. City sizes are known to have a highly variable
distribution [28], so if there was some correlation be-
tween city size and the number of routers in the city,
one might suspect causality.
Figure 8 is a scatter plot of population size
15
against the number of routers in a city. We find that
there is some correlation, but we also find some large
cities with few routers, and vice versa. The coeffi-
cient of correlation for this data, 0.64, does not indi-
cate significant correlation. One plausible reason for
this is that some chunk of the routing infrastructure
is present near fiber facilities or large data centers
that are sometimes situated away from large cities.
Our findings contradict those of Yook et al. [32] who
did find significant correlation between population
and router infrastructure. This difference may be
methodological; they use NetGeo
16
which reports
all routers belonging to an AS to be in one location.
GeoTrack, the tool we use, has finer granularity.
VI. SENSITIVITY ANALYSIS
To study the sensitivity of our conclusions to our
choice of vantage points, we re-computed our topol-
http://eire.census.gov/popest/
http://netgeo.caida.org/
14
10000
100000
1e+06
1e+07
1 10 100 1000
City population
Number of routers
Number of routers vs city population
Fig. 8. Correlation between number of routers and population
ogy properties (number of links and nodes, degree
distribution, average, distance, diameter, clustering
coefficient) using topologies derived from a subset
of our six sources. We found (but do not present for
lack of space) that three sources are sufficient to ob-
tain 99% of the nodes and 95% of the links for all
our geo-graphs, and the values of the topology prop-
erties derived from three sources are within 10% of
the value obtained from six sources. This gives us
some confidence in our conclusions: although a few
vantage points are demonstrably insufficient to cap-
ture all the nodes and links in the router-level graph,
they are sufficient to estimate aggregate properties of
the topology of backbone ASs.
VII. CONCLUSIONS
In this paper, we have looked at aggregate prop-
erties of the structure of large Autonomous Sys-
tems. We believe our findings provide information
that can be helpful for structural generation of Inter-
net router-level topologies. We expect that any such
generation methodology would incorporate the AS
as a structural element, since the AS is the largest
coherently engineered unit in the Internet topology.
To this end, knowing the distribution of POP sizes,
the inter-city connectivity and locality, and the re-
sulting path length characteristics of today’s ASs is
important.
REFERENCES
[1] ISPworld Web Site. http://www.ispworld.com/.
[2] National Internet Measurement Infrastructure.
http://www.ncne.nlanr.net/nimi/.
[3] University of Oregon Advanced Network
Technology Center. Route Views Project.
http://www.routeviews.org/.
[4] W. Aiello, F. Chung, and L. Lu. A Random Graph Model
for Massive Graphs. In Proc. of the 32nd Annual Sympo-
sium on Theory of Computing, 2000.
[5] R. Albert and A.-L. Barabasi. Topology of Evolving Net-
works: Local Events and Universality . Physical Review
Letters, 85:5234–5237, 2000.
[6] R. Albert, H. Jeong, and A.-L. Barabasi. Attack and Error
Tolerance of Complex Networks. Nature, 406, 2000.
[7] P. Barford, A. Bestavros, J. Byers, and M. Crovella. On the
Marginal Utility of Network Topology Measurements. In
Proceedings of the ACM SIGCOMM Measurement Work-
shop, San Francisco, CA, 2001.
[8] A. Broido. personal communication.
[9] A. Broido and K. C. Claffy. Internet Topology: Local
Properties. In Proceedings of SPIE ITCom 2001, Denver,
CO, August 2001.
[10] T. Bu and D. Towsley. On Distinguishing Between Internet
Power-Law Generators. In Proc. of IEEE Infocom, 2002.
[11] Hal Burch and Bill Cheswick. Mapping the Internet. IEEE
Computer, 32(4):97–98, April 1999.
[12] K. Calvert, M. Doar, and E.W. Zegura. Modelling Internet
Topology. IEEE Communications Magazine, June 1997.
[13] H. Chang, R. Govindan, S. Jamin, W. Willinger, and
S. Shenker. On Inferring AS-Level Connectivity from
BGP Routing Tables. In Proc. of IEEE Infocom, 2002.
[14] H. Chang, S. Jamin, and W. Willinger. Inferring AS-Level
Internet Topology from Router-Level Path Traces. In Pro-
ceedings of SPIE ITCom 2001, Denver, CO, August 2001.
[15] K. C. Claffy and D. McRobb. Measurement and Vi-
sualization of Internet Connectivity and Performance.
http://www.caida.org/Tools/Skitter/.
[16] A. Fabrikant, E. Koutsoupias, and C. Papadim-
itriou. Heuristically Optimized Trade-offs.
http://www.cs.berkeley.edu/ christos/.
[17] C. Faloutsos, P. Faloutsos, and M. Faloutsos. On Power-
Law Relationships of the Internet Topology. In Proceed-
ings of the ACM SIGCOMM, September 1999.
[18] P. Ferguson and D. Senie. Network Ingress Filtering: De-
feating Denial of Service Attacks which Employ Source
Address Spoofing. Request for Comments 2267, Internic
Directory Services, January 1998.
[19] R. Govindan and H. Tangmunarunkit. Heuristics for Inter-
net Map Discovery. In Proceedings of the IEEE Infocom,
Tel-Aviv, Israel, March 2000.
[20] C. Jin, Q. Chen, and S. Jamin. Inet: Internet Topology
Generator. Technical Report CSE-TR-433-00, EECS De-
partment, University of Michigan, 2000.
[21] R. Mahajan, N. Spring, and D. Wetherall. Measuring isp
topologies with rocketfuel. In To appear, Proceedings of
ACM SIGCOMM 2002, Pittsburgh, PA, 2002.
[22] A. Medina and I. Matta. BRITE: A Flexible Generator of
Internet Topologies. Technical Report BU-CS-TR-2000-
005, Boston University, 2000.
[23] Merit Network and Routing Arbiter Project. RADB Rout-
ing Registry. http://www.radb.net/.
[24] V . Padmanabhan and L. Subramanian. An Investigation
of Geographic Mapping Techniques for Internet Hosts. In
Proc. ACM SIGCOMM 2001, San Diego, CA, Auh 2001.
[25] D. Palmer and G. Steffen. On Power-Laws In Network
Topologies. In Proceedings of IEEE Globecom, 2000.
15
[26] J.-J. Pansiot and D. Grad. On routes and multicast trees in
the Internet. ACM SIGCOMM Computer Communication
Review, 28(1):41–50, January 1998.
[27] AT&T Labs Research. Graphviz -
open source graph drawing software.
http://www.research.att.com/sw/tools/graphviz/.
[28] H. Simon. On a Class of Skew Distribution Functions.
Biometrika, 1953.
[29] H. Tangmunarunkit, R. Govindan, S. Shenker, and D. Es-
trin. The Impact of Policy on Internet Paths. In Proceed-
ings of the IEEE Infocom, Anchorage, AK, April 2001.
[30] D. J. Watts and S. H. Strogatz. Collective Dynamics of
Small-World Networks. Nature, 363:202–204, 1998.
[31] B. M. Waxman. Routing of Multipoint Connections. IEEE
Journal of Selected Areas in Communication, 6(9):1617–
1622, December 1988.
[32] S.-H. Yook, H. Jeong, and A.-L. Barabasi. Modeling
the Internet’s Large-Scale Topology. Condensed Matter
Archives, http://xxx.lanl.gov/abs/cond-mat, July 2001.
Abstract (if available)
Linked assets
Computer Science Technical Report Archive
Conceptually similar
PDF
USC Computer Science Technical Reports, no. 731 (2000)
PDF
USC Computer Science Technical Reports, no. 697 (1999)
PDF
USC Computer Science Technical Reports, no. 751 (2001)
PDF
USC Computer Science Technical Reports, no. 706 (1999)
PDF
USC Computer Science Technical Reports, no. 961 (2015)
PDF
USC Computer Science Technical Reports, no. 941 (2014)
PDF
USC Computer Science Technical Reports, no. 786 (2003)
PDF
USC Computer Science Technical Reports, no. 760 (2002)
PDF
USC Computer Science Technical Reports, no. 771 (2002)
PDF
USC Computer Science Technical Reports, no. 872 (2005)
PDF
USC Computer Science Technical Reports, no. 817 (2004)
PDF
USC Computer Science Technical Reports, no. 692 (1999)
PDF
USC Computer Science Technical Reports, no. 642 (1996)
PDF
USC Computer Science Technical Reports, no. 669 (1998)
PDF
USC Computer Science Technical Reports, no. 866 (2005)
PDF
USC Computer Science Technical Reports, no. 773 (2002)
PDF
USC Computer Science Technical Reports, no. 774 (2002)
PDF
USC Computer Science Technical Reports, no. 900 (2008)
PDF
USC Computer Science Technical Reports, no. 931 (2012)
PDF
USC Computer Science Technical Reports, no. 746 (2001)
Description
Ramesh Govindan, Pavlin Radoslavov. "An analysis of the internal structure of large autonomous systems." Computer Science Technical Reports (Los Angeles, California, USA: University of Southern California. Department of Computer Science) no. 777 (2002).
Asset Metadata
Creator
Govindan, Ramesh
(author),
Radoslavov, Pavlin
(author)
Core Title
USC Computer Science Technical Reports, no. 777 (2002)
Alternative Title
An analysis of the internal structure of large autonomous systems (
title
)
Publisher
Department of Computer Science,USC Viterbi School of Engineering, University of Southern California, 3650 McClintock Avenue, Los Angeles, California, 90089, USA
(publisher)
Tag
OAI-PMH Harvest
Format
15 pages
(extent),
technical reports
(aat)
Language
English
Unique identifier
UC16270114
Identifier
02-777 An Analysis of The Internal Structure of Large Autonomous Systems (filename)
Legacy Identifier
usc-cstr-02-777
Format
15 pages (extent),technical reports (aat)
Rights
Department of Computer Science (University of Southern California) and the author(s).
Internet Media Type
application/pdf
Copyright
In copyright - Non-commercial use permitted (https://rightsstatements.org/vocab/InC-NC/1.0/
Source
20180426-rozan-cstechreports-shoaf
(batch),
Computer Science Technical Report Archive
(collection),
University of Southern California. Department of Computer Science. Technical Reports
(series)
Access Conditions
The author(s) retain rights to their work according to U.S. copyright law. Electronic access is being provided by the USC Libraries, but does not grant the reader permission to use the work if the desired use is covered by copyright. It is the author, as rights holder, who must provide use permission if such use is covered by copyright.
Repository Name
USC Viterbi School of Engineering Department of Computer Science
Repository Location
Department of Computer Science. USC Viterbi School of Engineering. Los Angeles\, CA\, 90089
Repository Email
csdept@usc.edu
Inherited Values
Title
Computer Science Technical Report Archive
Description
Archive of computer science technical reports published by the USC Department of Computer Science from 1991 - 2017.
Coverage Temporal
1991/2017
Repository Email
csdept@usc.edu
Repository Name
USC Viterbi School of Engineering Department of Computer Science
Repository Location
Department of Computer Science. USC Viterbi School of Engineering. Los Angeles\, CA\, 90089
Publisher
Department of Computer Science,USC Viterbi School of Engineering, University of Southern California, 3650 McClintock Avenue, Los Angeles, California, 90089, USA
(publisher)
Copyright
In copyright - Non-commercial use permitted (https://rightsstatements.org/vocab/InC-NC/1.0/