manipulated by all of the the interface management classes.  The {\ttIfTree} class is a container of interface state information organizedin a hierarchy:%% This needs re-presenting - it looks crufty\begin{description}\item [\tt IfTree] contains:  \begin{description}  \item [\tt IfTreeInterface] physical interface representation, contains:    \begin{description}    \item [\tt IfTreeVif] virtual (logical) interface representation, contains:      \begin{description}      \item [\tt IfTreeAddr4] Interface IPv4 address and related attributes.      \item [\tt IfTreeAddr6] Interface IPv6 address and related attributes.      \end{description}    \end{description}  \end{description}\end{description}Each item in the IfTree hierarchy is derived from {\tt IfTreeItem}.{\tt IfTreeItem} is a base class to track the state of a configurableitem. Items may be in one of four states: {\tt CREATED}, {\ttDELETED}, {\tt CHANGED}, {\tt NO\_CHANGE}.  For example, if anitem is added to the tree it will be in the {\tt CREATED} state.  The{IfTreeItem::finalize\_state()} method places the item in the {\ttNO\_CHANGE} state and items marked as {\tt DELETED} are actuallyremoved at this time.  The state labeling associated with {\tt IfTreeItem} adds a smalldegree of complexity to the {\tt IfTree} classes. However, it allowsfor one entity to manipulate an interface configuration tree and passit to another entity which can immediately determine the changes fromthe state labels.The interface management functionality of the FEA is represented bythree interacting classes: {\tt IfConfig}, {\tt InterfaceManager},{\tt InterfaceTransactionManager}.  The interaction of these classesis managed by the {\tt XrlInterfaceManager}, which takes external XRLrequests and maps them onto the appropriate operations.  Theinteractions between these classes and related classes are shown inFigure~\ref{fig:ifi}. The {\tt XrlInterfaceManager} is sufficientlyaware of the semantics of the operations to pass back human parseableerror messages when operations fail.The {\tt IfConfig} class is an interface configurator, and containsplug-ins for each supported forwarding plane architecture toaccess, set, or monitor the interface-related information.The functionality of the {\tt IfConfig} is conceptually simple: it canpush-down an {\tt IfTree} to the forwarding plane or pull-up the liveconfiguration 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 {\ttIfConfig} that should be used to perform the configuration.  The {\ttInterfaceTransactionManager} class holds and dispatches transactions.Each operation within a transaction operates on an item within a {\ttIfTree} structure.  Each transaction operates on a copy of the live{\tt IfTree} and when the commit is made, this structure is pusheddown into the {\tt IfConfig}.The process of configuration is asynchronous, and two phase.  Errorscan occur whilst a transaction is being committed and operating on an{\tt Iftree} (\eg because of a bad operation within a transaction), anderrors can occur when the configuration is pushed down to theforwarding plane (\eg the configuration has an inconsistent number ofinterfaces).  Errors in the first phase are reported by the {\ttInterfaceTransactionManager}.  Errors in the second phase are reportedby the {\tt IfConfig} through a helper class derived from {\ttIfConfigErrorReporterBase}.The interface management role of the FEA is expected to reportconfiguration 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 theforwarding plane.  The Forwarding Table Management role does notshadow the forwarding information outside of the forwarding planeitself; rather, it relies on the RIB to do this.  As a result, it isconsiderably simpler than the Interface Management role.The classes interacting to provide the Forward Table Management roleare: the {\tt XrlFtiTransactionManager} class, a class that adaptsrequests and responses from the subset of {\tt XrlFeaTarget} methodsthat represent the forwarding table management externally; the {\ttFtiTransactionManager} that builds and executes transactions toconfigure the forwarding table; and class {\tt Fti} that understandshow to program the forwarding plane.The {\tt Fti} class provides the interface for accessing theforwarding plane.  It includes methods for adding andremoving routes, as well as resolving routes in the forwarding table.Modifications to the {\tt Fti} state are only permitted during aconfiguration interval.  The configuration interval is started andstopped using {\tt Fti::start\_configuration} and {\ttFti:end\_configuration}.  The particular access to the forwardingplane is performed by plug-ins that are specific to thatplane. For example, to read the forwarding table currently there areplug-ins that utilize the sysctl(3) mechanism (\eg in case of FreeBSD)or the netlink mechanism (\eg in case of Linux). There areplug-ins to read, set or monitor the forwarding table informationat the granularity of one entry, or the whole table.The {\tt FtiTransactionManager} presents a transactional interface forconfiguring the {\tt Fti} instance.  Command classes exist for eachpossible modifier operation on the {\tt Fti} instance.  The {\tt Fti}methods {\tt start\_configuration} and {\tt end\_configuration} arecalled at the start and end of the transaction.%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%\subsection{Interface Specific Packet I/O}The Interface Specific Packet I/O role of the FEA provides a means forXORP processes to send and receive packets on particular interfaces.This is an essential function since in a XORP router the forwardingplane may reside on a different machine to the routing processes, itmay be distributed across several machines, or may have custom networkinterfaces that require special programming.  Currently (November 2003),only the sending and receiving of raw IPv4 packets is implemented.Support for UDP and IPv6 will follow in future and should follow asimilar design pattern to the raw IPv4 packet handling.The raw packet interface is managed by the {\tt XrlRawSocket4Manager}class.  This manages a single instance of a {\ttFilterRawSocket4}\footnote{The current implementation only works onsingle machine XORP forwarding planes}.  The {\tt FilterRawSocket4}encapsulates a raw socket and allows raw IPv4 packets to be writtenand filters attached to parse raw packets as they are received.  The{\tt XrlRawSocket4Manager} allows an arbitrary number of filters to beassociated with the active raw socket.  The filters are each notifiedwhen a raw packet is received on the raw socket.  TheXrlRawSocket4Manager allows other XORP processes to receive packetsvia XRL on the basis on filter conditions.  Currently (November 2003),the only implemented filter is the {\tt XrlVifInputFilter} whichallows processes to receive raw packets on the basis of the receivingVIF.  In principle, filters could be written to match on any fieldwithin a packet and perform an action.%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%\section{Status}\label{sec:status}Currently (November 2003), two versions of the FEA are supported: {\ttfea} and {\tt fea\_dummy}.  The {\tt fea} is a versionof the FEA that contains plug-ins to access the forwarding plane byusing the following mechanisms:\begin{itemize}  \item {\it getifaddrs(3)}, {\it sysctl(3)}, {\it ioctl(3)},   {\it Linux netlink(7) sockets} and {\it Linux /proc} to obtain   interface-specific information.  \item {\it ioctl(3)} and {\it Linux netlink(7) sockets} 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} and {\it Linux netlink(7) sockets} to lookup  a single forwarding entry in the forwarding plane.  \item {\it sysctl(3)} and {\it Linux netlink(7) sockets} to obtain the whole  forwarding table from the forwarding plane.  \item {\it BSD routing sockets} and {\it Linux netlink(7) sockets} 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 (November 2003) the {\tt fea} supports FreeBSD,NetBSD, OpenBSD, and Linux (see file {\tt \$XORP/BUILD\_NOTES}about the specific OS versions the FEA has been tested on).The {\tt fea\_dummy} is a substitute FEA and may beused for development testing purposes.  The {\tt fea\_dummy}represents an idealized form of FEA, other FEA's may differ in theirresponses due to architectural differences.  Therefore processes thatinteract with the FEA should regard {\tt fea\_dummy} interactions asindicative, 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. FEA support for Click isyet to be written, and FEA's for any other architecture wouldbe welcomed.  There is a now defunct Click FEA in the {\tt \$XORP/fea}directory that should be possible to resurrect.%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%     BIBLIOGRAPHY%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%\bibliography{../tex/xorp}\bibliographystyle{plain}%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%\end{document}