xorp.tex

BCAST Implementation for NS2

programmer's job harder at first, it is essential for robustness that
the programmer is made aware that the failure modes of IPC are different from those of
a local procedure call.  
To help the programmer and improve performance, an IDL and a stub
generator exist, so most XRL clients never need to parse the human
readable form.

The original motivation for XRLs was to encapsulate existing
protocols within our consistent IPC framework.   For example, we
might wish to run third-party software that uses SNMPv3 for
configuration. 
To integrate this software into our XRL-based management framework, we
might write an SNMP `protocol family' for the XRL client library.
Then XORP processes could transparently interoperate with the third-party
software via XRLs that start with `\xrl{snmp:}'.
XRLs are general enough to encompass simple
communication with the kernel via \texttt{ioctl}s, and even signaling
via \texttt{kill()}.  At the present time, we have not had a need to
add this functionality, but should the need arise, our architecture
would support it.  The current XRL library supports
XORP-specific protocols for remote procedure call, one layered over
TCP and the other over UDP, and a local procedure call mechanism for
intra-process communication.

\subsubsection{XRL Example: Command-line Interface}

One of the biggest issues faced by an {extensible} router is 
the integration of separately maintained components into a coherent
system.  Consider the interaction between management mechanisms such
as a command-line interface (CLI) and a new routing protocol.  The
author of each of the management processes has no knowledge of future
routing protocols.  At the same time, the author of each routing
protocol has no knowledge of future management mechanisms. Our
solution is for all management, including initial configuration, to
take place using XRLs.  To add support for a specific management
mechanism, such as SNMP or a command-line interface, the protocol
implementor writes simple text files that map management requests to
XRL calls.  These thin mapping files are easy enough to write that
third parties might add them as new management interfaces become
available.

To get more concrete, our configuration manager has a strict hierarchy
of configuration parameters, which is directly reflected in our
default CLI.  A fragment of a router configuration file might look
like:

\begin{quotation}
\noindent \sf \small protocols ospf \{\\
\parindent 10pt 
\indent     router-id: 128.16.64.1\\
\indent     area 128.16.0.1 \{\\\
\parindent 20pt 
\indent       interface xl0 \{\\
\parindent 30pt 
\indent         hello-interval: 30\\
\parindent 20pt 
\indent       \}\\
\parindent 10pt 
\indent     \}\\
\}
\end{quotation}

The configuration manager takes a directory of template files, which
define the possible configurable parameters for each XORP routing
protocol, and generates mappings of configuration parameters to XRL
dispatches.  The designer of a new routing protocol can simply add a
template file specifying the new functionality provided.  Thus, the
template entry for OSPF might contain the fragment:

\begin{quotation}
\noindent \sf \small hello-interval: uint \{ \\
\parindent 10pt 
\indent \%set: xrl ``ospf/ospf/1.0/set\_hello\_interval?\\
\parindent 60pt 
\indent if:txt=\$(IFNAME)\&interval:i32=\$(VALUE)'';\\
\parindent 10pt 
\indent \%get: xrl ``ospf/ospf/1.0/hello\_interval?if:txt\\
\parindent 60pt 
\indent -$>$ interval:i32'';\\
\}
\end{quotation}

The configuration manager can read the template file, discover the new
functionality, and know how to communicate with the process to use it.
The new functionality is then immediately available through the CLI.

\subsection{Performance}

Simultaneouly satisfying the three goals of extensibility,
performance, and robustness without compromise is probably not
possible. Different parts of XORP have different priorities.
User-level XORP does not need particularly performance-conscious
design.  Route updates can arrive at high rates, but nowhere near the
rates of packet arrival.  It is well within the capabilities of a
desktop PC to handle the volume of data and computation required for
unicast routing. (The main issues here are of the computational
complexity of the protocol implementations.)  At user-level, our
priorities are extensibility and robustness.

The forwarding path, however, must touch every packet and performance
is paramount.  Initially we have focused on a PC-based hardware
platform as this allows for easy testing and early deployment, but
great care is being taken to design a modular forwarding path
architecture which can support some or all of the forwarding functions
happening in hardware.  For our own work, the preferred forwarding
path is based on the Click modular router~\cite{click}.  Click
provides a high-performance forwarding path in the kernel, 
running on commodity hardware, and
allows for run-time extensions and reconfiguration.  Click's
modularity allows for many divisions of work between software and
hardware.  If researchers or developers decide they want to augment
XORP with network processors\footnote{Network processors~\cite{ixp1200} are interface
cards containing a number of high-speed network interfaces, typically
together with a processor and some specialized programmable hardware
for performing forwarding.  Typically the network processor can
perform simple forwarding very well, but more complex functionality
needs to be off-loaded to be handled by software running on the host
processor~\cite{scoutixp}.} or 
special-purpose hardware~\cite{fpx}, this will
be an advantage.

Click forwarding paths are extensible in two key ways:
\begin{itemize}
\vspace{-0.07in}
\item Existing defined elements can by interposed into a forwarding
path to add new functionality.
\vspace{-0.07in}
\item New Click elements can be created, loaded as kernel modules, and
then plumbed in to the forwarding path.
\vspace{-0.07in}
\end{itemize}
In the context of XORP, this extensibility can aid performance.
For example, a network administrator can ensure that only a small subset of
traffic goes through a possibly-slow extension, by defining
a new special-purpose classifier that matches extension traffic and 
inserting it into
the relevant place in the forwarding path.

% When we need to use hardware assistance to improve performance, Click
% should aid the integration of such hardware.  It is a fairly natural
% process whereby some parts of the forwarding path are performed in
% what to other Click elements look like just another element, but in
% fact are a shim to special purpose hardware.  However our initial
% implementation does not target advanced platforms due to our limited
% resources.

\subsection{Robustness}

The routing and coordination processes in XORP run in user space on a
traditional UNIX operating system.  Routing processes are protected
from each other and can have their resources constrained according to
administrative preference.  Furthermore, routing processes can crash
without affecting the kernel, forwarding plane, or each other.  And if
a routing protocol does crash, the RIB will remove its routes
from the forwarding engine, and optionally inform the re-starting
routing process of the routes it previously held.

Multiple processes are used in Zebra~\cite{zebra} and Cisco's proposed ENA
router operating system, but not by some of the larger
commercial vendors today.

A significant aspect of robustness is security.  One benefit of
being forwarding-path agnostic is that we can abstract
privileged operations, such as sending on a raw socket, into
the FEA via XRLs.  This allows us to run many routing protocols
in a sandbox. They have no interaction with the outside world except
through XRLs and packets, and so an exploitable vulnerability in a routing
protocol is far more difficult to escalate into full control of the
router.

Robustness in the forwarding path is also important, but solutions
such as memory protection that work well in user-space are not
acceptable.  In the Click forwarding path robustness comes from the
granularity and simplicity of Click's components.  Each element is
small enough to be well understood and tested in isolation.  And since
many of Click's components can be run and debugged in user-space,
confidence about their robustness can be attained before being used in
the kernel.

% \subsection{Leftover Crud}

% The routing protocol needs to be able to send routes to the routing
% information base (RIB), which coordinates route updates from different
% routing protocols.  But it also may need access to routes from other
% routing protocols.  For example BGP needs to know when an IGP route
% changes, and PIM-SM needs to know how to get to the multicast source
% or PIM RP router.  Most likely it needs this information to be
% supplied to it asynchronously, as changes occur. To do this
% efficiently in a multi-process environment requires careful design of
% this API, so that the RIB client can register interest in an
% appropriate granularity of information.

% But perhaps most important factor is the design of the IPC mechanism
% used.  This is illustrated by considering how a management process
% such a command-line interface (CLI), embedded web server, or SNMP
% might interact with the new routing protocol.  The author of each of
% the management processes has no knowledge of future routing protocols.
% At the same time, the author of each routing protocol has no knowledge
% of future management mechanisms.  Thus it is not viable to build CLI,
% web or SNMP support directly into a routing protocol.  The only really
% viable solution is for the routing protocol to interact with the rest
% of the router through the IPC mechanism, providing a control interface
% that is relatively independent of who is doing the control.  How then
% does the introduction of the new routing protocol cause the management
% protocols to increase the functionality available to the user?  Our
% solution to this problem is an IPC mechanism we call XORP Resource
% Locations or XRLs.