fea.tex

xorp源码hg

for one entity to manipulate an interface configuration tree and pass
it to another entity which can immediately determine the changes from
the state labels.

The interface management functionality of the FEA is represented by
three interacting classes: {\tt IfConfig}, {\tt InterfaceManager},
{\tt InterfaceTransactionManager}.  The interaction of these classes
is managed by the {\tt XrlInterfaceManager}, which takes external XRL
requests and maps them onto the appropriate operations.  The
interactions between these classes and related classes are shown in
Figure~\ref{fig:ifi}. The {\tt XrlInterfaceManager} is sufficiently
aware of the semantics of the operations to pass back human parseable
error messages when operations fail.

The {\tt IfConfig} class is an interface configurator, and contains
plug-ins for each supported forwarding plane architecture to
access, set, or monitor the interface-related information.
The functionality of the {\tt IfConfig} is conceptually simple: it can
push-down an {\tt IfTree} to the forwarding plane or pull-up the live
configuration state from the forwarding plane as an {\tt IfTree}.

The {\tt InterfaceManager} class contains the {\tt IfTree}
representing the live configuration, and a reference to the {\tt
IfConfig} that should be used to perform the configuration.  The {\tt
InterfaceTransactionManager} class holds and dispatches transactions.
Each operation within a transaction operates on an item within a {\tt
IfTree} structure.  Each transaction operates on a copy of the live
{\tt IfTree} and when the commit is made, this structure is pushed
down into the {\tt IfConfig}.

The process of configuration is asynchronous, and two phase.  Errors
can occur whilst a transaction is being committed and operating on an
{\tt Iftree} (\eg because of a bad operation within a transaction), and
errors can occur when the configuration is pushed down to the
forwarding plane (\eg the configuration has an inconsistent number of
interfaces).  Errors in the first phase are reported by the {\tt
InterfaceTransactionManager}.  Errors in the second phase are reported
by the {\tt IfConfig} through a helper class derived from {\tt
IfConfigErrorReporterBase}.

The interface management role of the FEA is expected to report
configuration changes to other XORP processes.  Hence,
the {\tt IfConfig} class uses the {\tt XrlIfConfigUpdateReporter}
class to report configuration changes.

\clearpage
\begin{figure}[htbp]
  \begin{center}
    \includegraphics[angle=90,height=0.90\textheight]{figs/ifi}
    \caption{FEA Interface Management classes and their interactions}
    \label{fig:ifi}
  \end{center}
\end{figure}
\clearpage


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Forwarding Table Management}

The Forwarding Table Management role propagates routes into the
forwarding plane.  The Forwarding Table Management role does not
shadow the forwarding information outside of the forwarding plane
itself; rather, it relies on the RIB to do this.  As a result, it is
considerably simpler than the Interface Management role.

The classes interacting to provide the Forward Table Management role
are: the {\tt XrlFtiTransactionManager} class, a class that adapts
requests and responses from the subset of {\tt XrlFeaTarget} methods
that represent the forwarding table management externally; the {\tt
FtiTransactionManager} that builds and executes transactions to
configure the forwarding table; and class {\tt Fti} that understands
how to program the forwarding plane.

The {\tt Fti} class provides the interface for accessing the
forwarding plane.  It includes methods for adding and
removing routes, as well as resolving routes in the forwarding table.
Modifications to the {\tt Fti} state are only permitted during a
configuration interval.  The configuration interval is started and
stopped using {\tt Fti::start\_configuration} and {\tt
Fti:end\_configuration}.  The particular access to the forwarding
plane is performed by plug-ins that are specific to that
plane. For example, to read the forwarding table currently there are
plug-ins that utilize the sysctl(3) mechanism (\eg in case of FreeBSD)
or the netlink mechanism (\eg in case of Linux). There are
plug-ins to read, set or monitor the forwarding table information
at the granularity of one entry, or the whole table.

The {\tt FtiTransactionManager} presents a transactional interface for
configuring the {\tt Fti} instance.  Command classes exist for each
possible modifier operation on the {\tt Fti} instance.  The {\tt Fti}
methods {\tt start\_configuration} and {\tt end\_configuration} are
called at the start and end of the transaction.

Note that the XRL interface for adding/deleting routes is
{\tt redist\_transaction\{4,6\}} which is a generic XRL interface
used by the RIB to redistribute routes to interested parties.

The Forwarding Table Management also provides interface for
processes to register interest in receiving updates whenever
the Forwarding Information Base changes. The FEA is observing
all FIB changes within the underlying system (including those triggered
by the FIB manipulation by the FEA itself). Those changes are propagated
to all instances of the {\tt FibClient} class (implemented within the
{\tt XrlFtiTransactionManager} class).

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Raw Packet I/O}
\label{sec:design:raw_packet_io}

The Raw Packet I/O role of the FEA provides a means for
XORP processes to send and receive raw packets on particular interfaces.
This is an essential function since in a XORP router the forwarding
plane may reside on a different machine to the routing processes, it
may be distributed across several machines, or may have custom network
interfaces that require special programming.

The FEA supports both IPv4 and IPv6 raw packets.
The text below describes the IPv4 implementation and the IPv4-specific
classes; the IPv6 implementation is similar except the class names
contain {\tt 6} instead of {\tt 4}.

The raw packet interface is managed by the {\tt XrlRawSocket4Manager}
class.  This manages a single instance of a {\tt
FilterRawSocket4}\footnote{The current implementation only works on
single machine XORP forwarding planes}.  The {\tt FilterRawSocket4}
encapsulates a raw socket and allows raw IPv4 packets to be written
and filters attached to parse raw packets as they are received.  The
{\tt XrlRawSocket4Manager} allows an arbitrary number of filters to be
associated with the active raw socket.  The filters are each notified
when a raw packet is received on the raw socket.  The
XrlRawSocket4Manager allows other XORP processes to receive packets
via XRL on the basis on filter conditions.  Currently (August 2006),
the only implemented filter is the {\tt XrlVifInputFilter} which
allows processes to receive raw packets on the basis of the receiving
VIF.  In principle, filters could be written to match on any field
within a packet and perform an action.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{TCP/UDP Socket I/O}

Similar to the Raw Packet I/O (see
Section~\ref{sec:design:raw_packet_io}), the FEA provides a means for
XORP processes to perform TCP or UDP socket operations and to send and
receive TCP/UDP packets.
This is an essential function since in a XORP router the forwarding
plane may reside on a different machine to the routing processes, it
may be distributed across several machines, or may have custom network
interfaces that require special programming.

The TCP/UDP socket interface is managed by the {\tt XrlSocketServer}
class.  This manages TCP and UDP IPv4 and IPv6 sockets\footnote{The
current implementation only works on
single machine XORP forwarding planes}.  The {\tt XrlSocketServer}
performs the particular TCP/UDP socket operations on the underlying
system (opening and closing a socket, bind, send and receive, etc),
and provides the XRL front-end interface. Note that for simplicity
some of the socket XRL interface combines several system socket
operations in one atomic FEA operation. For example, the {\tt
  socket4/0.0/tcp\_open\_bind} XRL interface creates a TCP socket that
binds it to a specific local address.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Status}
\label{sec:status}

There are two versions of the FEA: {\tt fea} and {\tt fea\_dummy}.
The {\tt fea} is a version
of the FEA that contains plug-ins to access the forwarding plane by
using the following mechanisms:

\begin{itemize}

  \item {\it getifaddrs(3)}, {\it sysctl(3)}, {\it ioctl(3)}, {\it Linux
  netlink(7) sockets}, {\it Linux /proc} and {\it Windows IP Helper
  API} to obtain interface-specific information.

  \item {\it ioctl(3)}, {\it Linux netlink(7) sockets} and {\it Windows
  IP Helper API} to set interface-specific information.

  \item {\it BSD routing sockets} and {\it Linux netlink(7) sockets} for
  observing changes in the interface-specific information.

  \item {\it BSD routing sockets}, {\it Linux netlink(7) sockets} and
  {\it Windows IP Helper API} to lookup a single forwarding entry in
  the forwarding plane.

  \item {\it sysctl(3)}, {\it Linux netlink(7) sockets} and {\it Windows
  IP Helper API} to obtain the whole forwarding table from the
  forwarding plane.

  \item {\it BSD routing sockets}, {\it Linux netlink(7) sockets} and
  {\it Windows IP Helper API} to set a single forwarding entry or the
  whole table in the forwarding plane.

  \item {\it BSD routing sockets} and {\it Linux netlink(7) sockets} to
  observe changes in the forwarding table.

\end{itemize}

In other words, currently (March 2007) the {\tt fea} supports DragonFlyBSD,
FreeBSD, NetBSD, OpenBSD, MacOS X, Linux, and Windows Server 2003 (see file
{\tt  \$XORP/BUILD\_NOTES} about the specific OS versions the FEA has
been tested on).
In addition, there is also support for the Click forwarding plane
(both kernel-space and user-space). The Click support utilizes the
above plug-in based architecture by providing the appropriate support
to add or delete routes for example to kernel or user-level Click.

The {\tt fea\_dummy} is a substitute FEA and may be
used for development testing purposes.  The {\tt fea\_dummy}
represents an idealized form of FEA, other FEA's may differ in their
responses due to architectural differences.  Therefore processes that
interact with the FEA should regard {\tt fea\_dummy} interactions as
indicative, but not definitive.

The FEA's are still a work in progress and no doubt have some bugs.
Any contributions or bug fixes are welcome.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%     APPENDIX
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\appendix
\section{Modification History}

\begin{itemize}

  \item December 11, 2002: Initial version 0.1 completed.

  \item March 10, 2003: Minor changes.
  Updated the version to 0.2, and the date.

  \item June 9, 2003: Updated to match XORP release 0.3: changes related
  to the MFEA->FEA merging.

  \item August 28, 2003: Updated to match XORP release 0.4: added ``Linux
  /proc'' to the list of implemented mechanisms for reading network interface
  information.

  \item November 6, 2003: Updated to match XORP release 0.5: updated the FEA
  status.

  \item July 8, 2004: Updated to match XORP release 1.0: now there is
  support for TCP/UDP socket I/O interface, support for libfeaclient XRL
  interface, and support for FIB observer interface.

  \item April 13, 2005: Updated to match XORP release 1.1: updated the status
  for the raw sockets interface and for Click.

  \item March 8, 2006: Updated to match XORP release 1.2: now the FEA supports
  Windows Server 2003, and the raw sockets interface is in use.

  \item August 2, 2006: Updated to match XORP release 1.3: added DragonFlyBSD
  to the list of supported OS-es.
  Added ``Modification History'' appendix.

  \item March 20, 2007: Updated the version to 1.4, and the date.

\end{itemize}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%     BIBLIOGRAPHY
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\bibliography{../tex/xorp}
\bibliographystyle{plain}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\end{document}