[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[freehaven-cvs] clean sec 2.2
Update of /home/freehaven/cvsroot/doc/routing-zones
In directory moria.mit.edu:/home2/arma/work/freehaven/doc/routing-zones
Modified Files:
routing-zones.tex
Log Message:
clean sec 2.2
Index: routing-zones.tex
===================================================================
RCS file: /home/freehaven/cvsroot/doc/routing-zones/routing-zones.tex,v
retrieving revision 1.40
retrieving revision 1.41
diff -u -d -r1.40 -r1.41
--- routing-zones.tex 28 Jan 2004 19:46:59 -0000 1.40
+++ routing-zones.tex 28 Jan 2004 20:11:52 -0000 1.41
@@ -215,8 +215,7 @@
topologies and our assumptions regarding how well this data reflects the
paths that packets actually travel.
-\subsubsection{Border Gateway Protocol}
-
+\subsubsection{Border Gateway Protocol.}
The Internet is composed of about 17,000 independently operated networks,
or autonomous systems (ASes), that exchange reachability information via
the Border Gateway Protocol (BGP)~\cite{rfc1771}. An AS could be an
@@ -227,8 +226,9 @@
a ``longest prefix match'' on that IP address to find the smallest IP prefix
in the routing table that contains that IP address. For example, a
router performing a route lookup for {\em IP address} {\tt 18.31.0.82}
-might find a route for the {\em prefix} {\tt 18.0.0.0/8}, a prefix that
-contains the destination IP address. The router then forwards packets
+might find a route for the {\em prefix} {\tt 18.0.0.0/8}. % a prefix that
+%contains the destination IP address.
+The router then forwards packets
for that destination to the next hop specified for the route to the
prefix. Routers will select the route that is the {\em smallest} prefix
that contains the IP address; for example, if a router's routing table
@@ -237,7 +237,7 @@
The Internet's routing table has over 130,000 distinct prefixes, each of
which has an associated route. An AS that originates a route
-readvertises this route to neighboring ASes via BGP and attaches its AS
+advertises this route to neighboring ASes via BGP and attaches its AS
number to the {\em AS path} of the route. When a router in a neighboring
AS learns this route, that router propagates it to all of the routers in
the AS. Some of these routers will, in turn, exchange routes with other
@@ -248,12 +248,12 @@
ASes do not blindly propagate routes to all of their neighbors; rather,
each pair of ASes has a commercial relationship, and an AS may prefer to
-send traffic via one AS other another for economic reasons. ASes form
+send traffic via one AS over another for economic reasons. ASes form
bilateral arrangements that can be broadly categorized as either (1)~a
customer-provider relationship, where the customer pays the provider to
-route traffic for it; and (2)~a peering relationship, where two ASes
+route traffic for it; or (2)~a peering relationship, where two ASes
exchange traffic between their own networks (and the networks of their
-customers), but do neither pays the other for this privilege.
+customers), but neither pays the other for this privilege.
\begin{figure}[t]
\include{policy_summary}
@@ -261,22 +261,25 @@
\label{fig:policy_summary}
\end{figure}
-BGP is a distinctive routing protocol because it is based on {\em
-policy}, rather than on shortest paths. For example, an AS will
+The BGP routing protocol is based on {\em
+policy} rather than on shortest paths. For example, the AS in
+Figure~\ref{fig:policy_summary} will
typically prefer to route traffic to a destination via one of its
customers (who pays it for connectivity) than via one of its providers
-(whom it must pay to send traffic towards) or one of its peers. In
-Figure~\ref{fig:policy_summary}, an AS will typically prefer a route to
-a destination via its customer, if one exists, over one through a peer
-or a provider. These relationships also determine which routes one AS
-will advertise to another. For example, an AS will typically not
+(whom it must pay to send traffic toward) or one of its peers.
+% In
+%Figure~\ref{fig:policy_summary}, an AS will typically prefer a route to
+%a destination via its customer, if one exists, over one through a peer
+%or a provider.
+These relationships also determine which routes one AS
+will advertise to another---an AS will typically not
advertise a route learned from one of its peers or providers to any of
its other peers or providers: doing so would constitute an implicit
agreement to forward traffic (i.e., provide ``transit'' service) between
two of its providers, two of its peers, etc. The AS in
Figure~\ref{fig:policy_summary} would advertise routes learned from its
customer to all of its neighbors, but would not readvertise routes learned
-from Peer 1 to Peer 2 (and vice versa), nor to its provider; it would
+from Peer 1 to Peer 2 (and vice versa), nor to its provider; and it would
advertise the routes learned from its provider to its customer, but not
to other peers.
@@ -292,7 +295,6 @@
\label{fig:bgp_example}
\end{figure}
-
Figure~\ref{fig:bgp_example} shows a simplified BGP routing table entry.
This router has learned two routes to the destination prefix {\tt
18.0.0.0/8} via BGP. Each route has various attributes, which include
@@ -310,16 +312,15 @@
the sequence of networks that a packet is forwarded through, but
typically the differences are minor and occur infrequently~\cite{Mao2003}.}
-\subsubsection{AS-level Internet Topology}
-
+\subsubsection{AS-level Internet Topology.}
Paths between end-hosts in the Internet cross a sequence of ASes (or
jurisdictions); to estimate the sequence of ASes that any given path
crosses, we must first have a representation of the Internet topology at
the AS-level (i.e., the ASes that each AS connects to, as well as their
-business relationships with one another). Determining a complete view
+business relationships). Determining a complete view
of the AS-level graph is notoriously difficult, because bilateral
-policies may hide edges in the graph from any one particular vantage
-point~\cite{Chang2004}. For example, in
+policies may hide edges in the graph from some
+perspectives~\cite{Chang2004}. For example, in
Figure~\ref{fig:policy_summary}, a routing table captured at Peer 1 will
not contain any routes with the $AS \leftrightarrow \mbox{Peer} 2$ link,
since the AS in the center will not readvertise routes learned from one
@@ -329,16 +330,16 @@
table data. The most prevalent is the Oregon RouteViews
Project~\cite{www-routeviews}, which maintains a route server that peers
with more than 30 ASes. Each of these ASes sends its routing tables to
-the RouteViews server, which include that AS's best route to each
+the RouteViews server, which learns that AS's best route to each
destination prefix. Each AS's routing table is slightly different,
-which means that The AS-level topology constructed from the RouteViews
-route server is likely be missing some inter-AS edges due to bilateral
-policies, but the graph is fairly representative enough for our
+which means that the AS-level topology constructed from the RouteViews
+route server is probably missing some inter-AS edges due to bilateral
+policies, but the graph is representative enough for our
purposes. In the future, we could improve our analysis by incorporating
newer techniques for capturing AS-level topologies~\cite{Chang2004}.
-Knowing the AS-level topology is not enough to determine the
-AS-level path between two arbitrary mix nodes; to determine this, we
-need to make further modeling assumptions, which we describe in
+Knowing the AS-level topology is not enough to determine the AS-level
+path between two arbitrary mix nodes, though; to determine this,
+we need to make further modeling assumptions, which we describe in
Section~\ref{sec:mix_aspath}.
\section{Threat Models}
***********************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe freehaven-cvs in the body. http://freehaven.net/