xorp.tex

xorp源码hg

% -*- mode: latex; tex-main-file: "pospaper.tex" -*-

\section{XORP Overview}

XORP divides into two subsystems. 
The higher-level (so-called ``user-level'') subsystem
consists of the routing protocols themselves, along with routing
information bases
and support processes. 
The lower-level subsystem, which initially runs inside an OS kernel, manages the
forwarding path---anything that needs to touch every packet---and provides
APIs for the higher level to access.
The goal is for almost all of
the higher-level code to be agnostic as to the details of the
forwarding path.

For user-level XORP, we've developed a multi-process architecture with
one process per routing protocol, plus extra processes for management,
configuration, and coordination.  To enable extensibility we designed
a novel inter-process communication mechanism for communication
between these modules.  This mechanism is called XORP Resource
Locators (XRLs), and is conceptually similar to URLs.  URL mechanisms
such as redirection aid reliability and extensibility, and their
human-readable nature makes them easy to understand and embed in
scripting languages.

The lower level uses the Click modular router~\cite{click}, a
modular, extensible toolkit for packet processing on conventional PCs.
Further work will help this architecture span a
large range of hardware forwarding platforms, from commodity
PC hardware, through mid-range PC-based platforms
enhanced with intelligent network interfaces (such as Intel's
IXP1200~\cite{ixp1200,scoutixp}), to high-end hardware-based forwarding engines.
We may also support alternative forwarding paths, such as the
FreeBSD forwarding path with AltQ queuing extensions~\cite{altq}
or an alternative extensible forwarding path such as
Scout~\cite{pathrouter}.
Some forwarding path choices may influence the functionality available
for end users to extend or change.  But for many aspects of research, such
as routing protocol experiments that don't
require access to the forwarding path, a conventional FreeBSD
lower level would suffice.

\begin{figure}[h]
\centerline{\psfig{figure=processes3.ps,width=3.0in}}
\caption{XORP High-level Processes}
\label{fig:processes}
\vspace{-0.1in}
\end{figure}

Figure~\ref{fig:processes} shows how a XORP router's user-level processes
and Click forwarding path fit together.
The shared user-level processes are the XORP architecture's most innovative
feature. Four core processes are particularly worthy of comment: the
\emph{router manager},
the \emph{finder}, the \emph{routing information base}, and the 
\emph{forwarding engine abstraction}.  

The \emph{router manager}
process manages the router as a whole.  It maintains
configuration information; starts other processes, such as routing
protocols, as required by the configuration; and restarts failed
processes as necessary.

The \emph{finder} process stores mappings between abstracted application
requests, such as ``How many interfaces does this router have?'', and the
particular IPC calls necessary to answer those requests.
Think of it as an IPC redirector:
when an application wishes to make an IPC
call, it consults the finder to discover how to do it.  The
application typically caches this information so future calls
circumvent the finder.  Furthermore, the finder can instruct
applications to update contact information.  Thus it is easy to change
how application requests are handled at run-time.  We
can trace XORP's communication pattern by asking the finder to map
abstract requests to sequences of IPCs, some for tracing and some for
doing the work.  XORP processes can communicate without
bootstrapping using the finder, but since XRLs are relatively low cost we
have not found this necessary to date.

%% XXX This is duptext from Eddie and Orion editing at the same time.
%% Either this or the next paragraph should go.

%The \emph{forwarding engine abstraction} process, or FEA, abstracts the
%details of how the router's forwarding path is implemented.
%Routing protocols talk to the FEA to install routes and discover properties
%of interfaces, for example. 
%Interfaces to the FEA remain the same regardless of whether the forwarding
%path is implemented in Click, in a conventional kernel, or even in external
%hardware.
%Again, XORP processes can bypass the FEA when required.

The \emph{routing information base} process (RIB) receives routes from
the routing processes, and arbitrates which routes should be
propagated into the forwarding path, or redistributed to other routing
processes.  The forwarding path is managed
by the \emph{forwarding engine abstraction} process (FEA).  The FEA
abstracts the details of how the forwarding path of the router is
implemented and as a result, the routing processes are agnostic to
whether the forwarding plane is Click based, a conventional UNIX
kernel, or an alternative method.  The FEA manages the networking
interfaces and forwarding table in the router, and provides information to routing processes
about the interface properties and events occurring on interfaces, such as an
interface being taken down.  As with the finder, XORP processes can bypass the
FEA when required.


\section{Solving Design Challenges}

This section shows how we address the four design challenges of traditional
router features, extensibility, robustness, and performance.
Space constraints prevent inclusion of much detail, but we do
describe our IPC mechanism, XORP Resource Locators (XRLs), at length.

%Routing protocol processes speak with the router manager to get their configurations, with the finder to redirect XRL-based
%IPCs, and with the FEA (via the finder) to query interface state and
%to open routing connections.  The unicast and multicast routing
%information bases are stored in still other processes.  Thus, the
%routing tables themselves survive protocol crashes---only those routes
%added by a protocol will be affected.  The RIB processes speak with
%the FEA to install and uninstall particular routes.

\subsection{Features}

To be successful, a router platform needs to be have good support
for the routing and management protocols that are in widespread use
today.  The minimal list of routing and routing-support protocols is:
\begin{itemize}\addtolength{\itemsep}{-0.5\baselineskip}
\item{\bf BGP4+}
%(Multi-protocol BGP) 
%for 
inter-domain routing.
% of IPv4 and IPv6 unicast and multicast RIBs.
\item{\bf OSPF}
intra-domain routing.
\item{\bf RIPv2/RIPng}
intra-domain routing.
\item{\bf Integrated IS-IS}
intra-domain routing.
\item{\bf PIM-SM/SSM}
multicast routing.
\item{\bf IGMPv3/MLD}
local multicast membership.
\item{\bf PPP}
for point-to-point links (as per RFC 1812).
\end{itemize}

With the exception of IS-IS, all of these are currently being worked
upon within XORP.  The aim is for both IPv4 and
IPv6 support.  MPLS is deliberately omitted at
this stage.  The multi-process architecture helps us to leverage 
existing code where
appropriate;  our OSPF and RIP implementations are derived from John
Moy's {\it OSPFd}~\cite{ospfd} and BSD's {\it routed} respectively.

For management interfaces, we are pursuing a command line interface
resembling that of Juniper and intend to support SNMP.


\subsection{Extensibility}

Open interfaces are the key to extensibility.
Interfaces must exist at any point where an extension might plug in,
and those interfaces must be relatively easy to use.
XORP's design encourages the construction of useful
interfaces through multi-process design.
A routing protocol process, for example, must communicate with other
processes to install routes and discover information about the router
itself.
Open inter-process interfaces, built in to the system from the beginning,
form the basic source of user-level XORP's extensibility.

\subsubsection{XRLs}
\def\xrl#1{\textsf{\small #1}}

Most inter-process communication within XORP takes place via XORP
Resource Locators, or XRLs.  XRLs resemble the Web's URLs. They specify in
human-readable form the type of IPC transport desired (the
``protocol''), the abstract name for the entity being communicated
with, the method being invoked, and a list of named arguments.  Unlike
URLs, they can also specify the nature of the response expected.

As an example, the general form of one of the XRLs for the forwarding
engine abstraction (FEA) process might be rendered in human readable
form as:
%
\begin{figure}[h]
\vspace{-0.05in}
\centerline{\psfig{figure=xrl.ps,width=3.5in}}
\vspace{-0.1in}
\end{figure}

\noindent The initial `\xrl{finder:}' portion specifies the protocol;
in this case the actual protocol has not yet been resolved.
The first time this XRL is called, the client XRL library
contacts the finder, which responds with a redirection to a new XRL
containing the actual protocol to be used, together with all the
parameters needed to contact the current FEA.
Subsequent communication then goes
directly between the client and the FEA process.
If the FEA restarts, the client's XRL calls to the old FEA will fail, and
it can consult the finder to update the redirection.

The XRL library, which all of our processes link against, takes an XRL
and performs argument marshaling, then it invokes the specified transport
mechanism, and handles the response or any
failure that might occur.  Unlike many RPC or remote method invocation
mechanisms, XRLs don't try and hide from the programmer that
off-process communication is taking place.  While this makes the