error_handling.tex

xorp源码hg

%perform this retransmission, however, unless it can guarantee that the
%request was not acted on by any instance. (This rules out most
%unreliable transports.) If it cannot guarantee this, or if
%retransmission fails, the XRL will get an error -- either
% REPLY\_TIMED\_OUT, SEND\_FAILED, NO\_FINDER, or RESOLVE\_FAILED.
%
% XXX This is very MIT a la Gabriel's Worse-is-Better :-)  I like it,
% but would rather not commit to this just now
%

The XRL errors of NO\_FINDER, RESOLVE\_FAILED, and to some extent
NO\_SUCH\_METHOD generally represent serious problems with the router.
SEND\_FAILED represents a serious problem with the target, such as
that an instance of the target has died; this problem may or may not
be transient. The SEND\_FAILED\_TRANSIENT and REPLY\_TIMED\_OUT errors
are
potentially common errors, and should be handled by the
application. However, the likelihood of SEND\_FAILED\_TRANSIENT can
often be reduced, making it a ``fatal'' error from the application's
point of view, by limiting the rate at which requests are sent.

NO\_FINDER, RESOLVE\_FAILED, NO\_SUCH\_METHOD, and
SEND\_FAILED\_TRANSIENT, are all indications that the XRL was not
communicated to its target. They are therefore called \emph{send
failures}.  The other two errors, REPLY\_TIMED\_OUT and SEND\_FAILED,
may be generated even if the target received the request. They are
therefore called \emph{receive failures}.

If a peer dies, we will receive notification of this explicitly and
will deal with it as specified in section \ref{pfailure}. Thus most
XRL transport errors SHOULD NOT be taken as an indication that the
peer is definitely dead. If an application cares that the peer has
died or restarted, it SHOULD register with the finder to receive
notifications of process restarts. Thus, a process SHOULD assume that
an XRL transport problem will be transient until it receives an
explicit confirmation that the destination has failed, particularly
when the XRL interface is unreliable.

In addition to an XRL interface being reliable or unreliable, the way
the application uses an XRL interface can by pipelined or
non-pipelined.  In the pipelined case, multiple requests can be
outstanding simultaneously; in the non-pipelined case at most one
request can be outstanding at a time.

It is useful for us to categorize XRL interfaces along these two axes:
reliable/unreliable and pipelined/non-pipelined. 

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection*{Unreliable, Non-pipelined}

If an XRL send failure occurs, the sending application MAY choose to
retransmit the XRL, or ignore the failure as it sees fit.  

In an XRL receive failure occurs, the sending application MAY also choose
to retransmit the XRL, or ignore the failure as it sees fit. However, if
the application chooses to re-send the XRL, the interface MUST be written
in such a way that the receipt of a duplicate request will not damage the
system. (XXX Isn't this true anyway? Network duplicates?)

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection*{Reliable, Non-pipelined}

If a SEND\_FAILED\_TRANSIENT error occurs, the sending application MAY
retransmit the XRL.

SEND\_FAILED, NO\_FINDER, and most RESOLVE\_FAILED and
NO\_SUCH\_METHOD errors are unrecoverable.  The application should
cause this XRL interface to go dormant, in the expectation that it
will authoritatively discover from the finder that the target has
died.

REPLY\_TIMED\_OUT cannot happen on reliable interfaces.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection*{Unreliable, Pipelined}

The same issues apply as with unreliable, non-pipelined, but the
situation is more complicated.  An interface that uses unreliable
transport and pipelining is one that explicitly permits loss \emph{and
re-ordering} of requests.  It is up to the application to choose
whether to retransmit XRLs that return SEND\_FAILED\_TRANSIENT or
REPLY\_TIMED\_OUT, but the application must only do so if it is
certain that the re-ordering caused by retransmission will not be a
problem.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection*{Reliable, Pipelined}

The XRL library ensures that pipelined messages sent to a reliable target
are delivered in order. In particular, if a request $R$ to a given target
gets an error, then no \emph{outstanding} requests to that target
\emph{registered later than $R$} will successfully complete -- they will
all get the same error, and none of them will be delivered to the receiving
application. Once the error is delivered, this error state is wiped out,
and later requests to the target may succeed -- perhaps because the target
was restarted.

Again, SEND\_FAILED, NO\_FINDER, and most RESOLVE\_FAILED and
NO\_SUCH\_METHOD errors are unrecoverable.
The application SHOULD cause this XRL interface to go dormant, in the
expectation that it will authoritatively discover from the finder that
the target has died.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Execution Error}

A XORP router is partitioned into many processes; most of the operating
system specific interactions are performed by the FEA. In a router the
most frequent operation will be the adding and deleting of routes.
Consider BGP adding a route. First the BGP process will send the route
to the RIB, then the route may be sent to the FEA. If the addition of the
route from the RIB to the FEA fails, then there is no way of
propagating this failure back to the BGP process due to the
asynchronous nature of XRLs. If adding/deleting a route fails a very
drastic way of propagating this failure back to the BGP process would
be for either or both the FEA and RIB processes to exit, in which case
the process failure responses already described would be used and BGP
would exit. Process exit is an extreme response to failing
to add a route, but at least the error handling code for process exit
exists already. It is important though not
to mask over implementation problems by ignoring errors. In the rest
of this section we will outline how to deal with a number of common
errors.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Adding/Deleting route failures}

As stated above, a highly likely error is failures when adding or
deleting routes. Typically the interaction will occur between the RIB
and FEA. When an error occurs it should be logged by the FEA and the
cause returned to the RIB. The RIB can be configured with policy on
how to react to different errors.

Adding a route will typically fail because a route already exists.
Firstly, if a route already exists it is either the same or different
to the one that we attempted to add. Secondly, either the FEA
installed the route or a third party installed it. Therefore when
adding a route fails the FEA should return if the current route is the
same or different to the one we attempted to add, as well as who
installed the route originally. The RIB on receiving the error state
from the FEA can decide as a matter of policy how to proceed. If an
attempt to add a route fails because a different route exists the RIB
could choose to delete the old route and add the new route.

The most common reason for a route deletion to fail would be that the
route is no longer present. The FEA should log that it has been asked
to delete a route that doesn't exist. The RIB should decide if this
problem should be considered fatal.

%%%%%%%%%%%%%%%%%%%%%%
\subsubsection{Route Add Failure due to Resource Starvation}

When a routing process sends a route to the RIB, the asynchronous
nature of XRL handling means that the RIB will typically accept the
route before it has finished processing the addition, and certainly
before it attempts to pass the route to the FEA, and hence on into the
forwarding engine.  It is possible for the route addition to fail due
to memory exhaustion in either the RIB or in the forwarding engine
itself.  Should this occur, it is important for the routing protocol
to be made aware of the event, because the routing information will
now be out of synchronization with the forwarding information.

If the forwarding engine refuses the route due to resource starvation,
the FEA will receive the failure.  The FEA will then indicate
asynchronously to the RIB that the failure occurred.  The RIB will in
turn delete all state from all routing protocols that contributed
versions of this route, and asynchronously pass the failure up to
those routing protocols.  Each of those routing protocols will then
handle the failure in a protocol specific manner.

If the failure occurs due to resource starvation in the RIB, a similar
process will be initiated.  It is not currently clear how to reliably
notify a routing protocol in the case when the router is running out
of memory for user-space processes.

In the case of BGP, if a route fails to be added due to resource
starvation, the simplest mechanism is to take down the peering that
originated the route.  The normal peer reinitialization mechanism
(after some time delay) will ensure that all the routes are
re-instantiated after the resource starvation problem goes away.

In the case of RIP, if a route fails to be added due to resource
starvation, the simplest mechanism is to send our peers an infinite
metric route for this particular prefix and to delete the state for
this prefix.  The normal RIP periodic update will ensure that the
route is re-instantiated after the resource starvation problem goes
away.

In the case of link-state protocols such as OSPF and IS-IS, there is
no good way to deal with this situation.  A reasonable solution might
be to take down all adjacencies to avoid causing a blackhole, then to
bring up the adjacencies again but not propagate any link-state
advertisements to our neighbors (so they won't route via us) until all
the link-state advertisements have been received and we've
successfully installed all the routes in the kernel.

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

\begin{itemize}

  \item June 9, 2003: Initial version 0.3 completed.

  \item August 28, 2003: Updated the version to 0.4, and the date.

  \item November 6, 2003: Updated the version to 0.5, and the date.

  \item July 8, 2004: Updated the version to 1.0, and the date.

  \item April 13, 2005: Updated the version to 1.1, and the date.

  \item March 8, 2006: Added a footnote about the policy manager process.
  Updated the version to 1.2, and the date.

  \item August 2, 2006: Added ``Modification History'' appendix.
  Updated the version to 1.3, and the date.

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

\end{itemize}

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

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