design_arch.tex

xorp源码hg

%
% $XORP: xorp/docs/design_arch/design_arch.tex,v 1.26 2007/03/15 00:43:12 pavlin Exp $
%

\documentclass[11pt]{article}

%\usepackage[dvips]{changebar}

\usepackage{subfigure}
\usepackage{fullpage}
\usepackage{setspace}
\usepackage{times}
\usepackage{latexsym}
\usepackage{epsfig}
\usepackage{graphicx}
\usepackage{xspace}
\usepackage{color}
\usepackage{amsmath}
\usepackage{rotating}
\usepackage{moreverb}
\usepackage{listings}
\usepackage{alltt}
\usepackage{stmaryrd}
%\usepackage[dvipdf]{graphics}
%\usepackage[dvips]{graphicx}
%\usepackage{xorp}

\definecolor{gray}{rgb}{0.5,0.5,0.5}
\newcommand{\etc}{\emph{etc.}\xspace}
\newcommand{\ie}{\emph{i.e.,}\xspace}
\newcommand{\eg}{\emph{e.g.,}\xspace}
%\newcommand{\comment}[1]{{\color{gray}[\textsf{#1}]}}
%\newcommand{\comment}[1]{}

% Changebar stuff
% \newenvironment{colorcode}{\color{blue}}{}
% \renewcommand{\cbstart}{\begin{colorcode}}
% \renewcommand{\cbend}{\end{colorcode}}

% \pagestyle{empty}

\begin{document}

\title{XORP Design Overview \\
\vspace{1ex}
Version 1.4}
\author{ XORP Project					\\
	 International Computer Science Institute	\\
	 Berkeley, CA 94704, USA			\\
         {\it http://www.xorp.org/}			\\
	 {\it [e-mail]}
}
\date{March 20, 2007}

\maketitle


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Introduction}

This document provides a brief overview of the XORP (eXtensible Open
Router Platform) architecture. It is intended both for people who are
interested in the architecture itself, and as a starting point for developers
who wish to modify the software.  People who are interested in the XORP
multicast routing architecture should read also
\cite{xorp:multicast_arch}.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{XORP Motivation}

A gap exists between network research and Internet practice due to the
nature of the Internet router software business.  It is really hard
for researchers to introduce new protocols and mechanisms into
operational networks, and to study existing protocols in the wild.
The primary goal of XORP is to fill this gap.  To succeed it must be both
a research tool and a stable deployment platform that can be used in
production networks.  It must also place a strong emphasis on
extensibility, while coping with the impact of this on robustness,
security and performance.

For more details about the XORP design {\it philosophy}, see
\cite{handley:hotnets2002:xorp}.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Target}

The goal for XORP is to become a suitable software platform that can
be used as the core of practically any router. However, the {\it
initial} focus is on an edge router running on commodity PC hardware
with relatively low port density and moderate size routing
tables~\footnote{A comparable production router might be a Cisco
7206VXR (or pretty much anything smaller than this).}.

However, given the flexibility of the XORP architecture, in the future
we should not be limited to edge-router scenarios or PC hardware.  For
example:
\begin{itemize}

  \item We can easily imagine using multiple PCs as forwarding engines,
  with a single control element. This would allow greater port density.

  \item Another useful target would be a PC with a number of network
  processors (\eg Intel IXP1200) doing the bulk of the forwarding.

  \item Finally, in the long run, the code base might be run the
  control processor of high-performance ASIC-based routers.

\end{itemize}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Functionality}

XORP is designed to support both IPv4 and IPv6.
Below is our initial target list of protocols and features to be
supported by XORP. Those in bold are already implemented or supported
to some degree. Not all of the implemented features have been tested
yet.

%%%%%%%%%%%%%%%%%%%%%
\subsubsection*{Unicast Routing Protocols}

\begin{itemize}
  \item {\bf BGP4+} ({\bf IPv4} and {\bf IPv6})
  \item {\bf OSPFv2 (IPv4)}, {\bf OSPFv3 (IPv6)}
  \item {\bf RIPv2 (IPv4)}, {\bf RIPng (IPv6)}
  \item IS-IS
\end{itemize}

%%%%%%%%%%%%%%%%%%%%%
\subsubsection*{Multicast Routing Protocols}

\begin{itemize}
  \item {\bf PIM-SM, PIM-SSM}, Bidir-PIM ({\bf IPv4} and {\bf IPv6})
  \item {\bf IGMPv1, v2, v3} ({\bf IPv4})
  \item {\bf MLDv1, v2} ({\bf IPv6})
\end{itemize}

%%%%%%%%%%%%%%%%%%%%%
\subsubsection*{Network Management}

\begin{itemize}
  \item {\bf Command Line Interface} (similar to Juniper)
  \item {\bf SNMP}
  \item WWW
\end{itemize}

%%%%%%%%%%%%%%%%%%%%%
\subsubsection*{Forwarding Path}

\begin{itemize}
  \item {\bf Traditional UNIX forwarding path}
  \item {\bf Click forwarding path}
  \item {\bf Windows Server 2003 forwarding path}
  \item User-level simulation-like environment
\end{itemize}

%%%%%%%%%%%%%%%%%%%%%
\subsubsection*{Miscellaneous}

\begin{itemize}
  \item {\bf Routing policies} ({\bf unicast} and multicast)
\end{itemize}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Architecture}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Design Philosophy}

The XORP design philosophy stresses {\em extensibility},
{\em performance} and {\em robustness}.

For routing and management modules, the primary goals are
extensibility and robustness.  These goals are achieved by carefully
separating functionality into independent modules, running in separate
UNIX processes, with well-defined APIs between them.  Clearly, there
are performance penalties to pay for such an architecture, but we
believe that so long as careful attention is paid to computational
complexity, the costs associated with inter-process communication will
be acceptable given the obvious extensibility and robustness benefits.

For the forwarding path, the primary goals are extensibility and
performance.  Robustness here is primarily achieved through
simplicity and a modular design that encourages re-use of well-tested
components.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Design Overview}

XORP can be divided into two subsystems. The higher-level
(``user-space'') subsystem consists of the routing protocols and
management mechanisms. The lower-level (``kernel'') provides the
forwarding path, and provides APIs for the higher-level to access.

User-level XORP uses a multi-process architecture with one process per
routing protocol, and a novel inter-process communication mechanism
known as XORP Resource Locators (XRLs)~\cite{xorp:xrl}. XRL
communication is not limited to a single host, and so XORP can in
principle run in a distributed fashion. For example, we can have a
distributed router, with the forwarding engine running on one machine,
and each of the routing protocols that update that forwarding engine
running on a separate control processor system.

The lower-level subsystem can use traditional UNIX kernel forwarding,
the Click modular router~\cite{CLICK-PROJECT} or Windows kernel
forwarding (Windows Server 2003). The modularity and minimal
dependencies between the lower-level and user-level subsystems allow for
many future possibilities for forwarding engines.  As standards such as
those being developed in the IETF ForCES Working Group emerge, we expect
to support them to provide true forwarding engine interchangeability.

\begin{figure}[htbp]
  \begin{center}
    \includegraphics[width=0.7\textwidth]{figs/processes3.ps}
    % \vspace{.05in}
    \caption{XORP Process Model}
    \label{fig:process_model}
  \end{center}
\end{figure}

Figure~\ref{fig:process_model} shows the processes in XORP, although
it should be noted that some of these modules use separate processes
to handle IPv4 and IPv6. For simplicity, the arrows show only the
main communication flows used for routing information.  Control flows
are not shown - for example, the FEA may need to inform the routing
processes when an interface goes down. These processes are further
described in Section~\ref{sec:xorp_processes_description}.