rib.tex

xorp源码hg

The RIB supports the following XRLs.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Routing Protocol Registration}

\begin{verbatim}
add_igp_table4 ? protocol:txt & target_class:txt & target_instance:txt
               & unicast:bool & multicast:bool
add_igp_table6 ? protocol:txt & target_class:txt & target_instance:txt
               & unicast:bool & multicast:bool
add_egp_table4 ? protocol:txt & target_class:txt & target_instance:txt
               & unicast:bool & multicast:bool
add_egp_table6 ? protocol:txt & target_class:txt & target_instance:txt
               & unicast:bool & multicast:bool
delete_igp_table4 ? protocol:txt & target_class:txt & target_instance:txt
               & unicast:bool & multicast:bool
delete_igp_table6 ? protocol:txt & target_class:txt & target_instance:txt
               & unicast:bool & multicast:bool
delete_egp_table4 ? protocol:txt & target_class:txt & target_instance:txt
               & unicast:bool & multicast:bool
delete_egp_table6 ? protocol:txt & target_class:txt & target_instance:txt
               & unicast:bool & multicast:bool
\end{verbatim}

These XRLs are used by routing protocols to register with the RIB
process, and hence to create OriginTables in all the RIBs.

The {\tt \_igp\_} xrls will plumb the OriginTable on the Internal side
of the ExtIntTable.  The {\tt \_egp\_} xrls will plumb the OriginTable
on the External side of the ExtIntTable.

{\tt protocol} is a text string used to identify the routing protocol.
Currently it MUST be a protocol the RIB knows about, or an
administrative distance cannot be assigned to the routes.  Future
versions of the RIB may make this interface more extensible.

{\tt target\_class} and {\tt target\_instance} specify the
class and instance associated with the target.

{\tt unicast} and {\tt multicast} indicate whether the routing
protocol will insert routes into the unicast RIB or the multicast RIB
or both.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Adding and Deleting Routes}

\begin{verbatim}
add_route4      ? protocol:txt & unicast:bool & multicast:bool  \
                & network:ipv4net & nexthop:ipv4 & metric:u32   \
                & policytags:list

add_route6      ? protocol:txt & unicast:bool & multicast:bool  \
                & network:ipv6net & nexthop:ipv6 & metric:u32   \
                & policytags:list

replace_route4  ? protocol:txt & unicast:bool & multicast:bool  \
                & network:ipv4net & nexthop:ipv4 & metric:u32   \
                & policytags:list

replace_route6  ? protocol:txt & unicast:bool & multicast:bool  \
                & network:ipv6net & nexthop:ipv6 & metric:u32   \
                & policytags:list

delete_route4   ? protocol:txt & unicast:bool & multicast:bool  \
                & network:ipv4net

delete_route6   ? protocol:txt & unicast:bool & multicast:bool  \
                & network:ipv6net

add_interface_route4    ? protocol:txt                          \
                        & unicast:bool & multicast:bool         \
                        & network:ipv4net & nexthop:ipv4        \
                        & ifname:txt & vifname:txt & metric:u32 \
                        & policytags:list

add_interface_route6    ? protocol:txt                          \
                        & unicast:bool & multicast:bool         \
                        & network:ipv6net & nexthop:ipv6        \
                        & ifname:txt & vifname:txt & metric:u32 \
                        & policytags:list

replace_interface_route4 ? protocol:txt                         \
                        & unicast:bool & multicast:bool         \
                        & network:ipv4net & nexthop:ipv4        \
                        & ifname:txt & vifname:txt & metric:u32 \
                        & policytags:list

replace_interface_route6 ? protocol:txt                         \
                        & unicast:bool & multicast:bool         \
                        & network:ipv6net & nexthop:ipv6        \
                        & ifname:txt & vifname:txt & metric:u32 \
                        & policytags:list
\end{verbatim}

These XRLs are used to communicate new routes, changed routes, or the
deletion of routes to the RIB.
The {\tt add\_interface\_route} and {\tt replace\_interface\_route}
XRLs are similar to the {\tt add\_route} and {\tt replace\_route}
XRLs except that the origin explicitly specifies the outgoing
network interface and vif for the route.

Note that sending an {\tt add\_route} for a route that is already in
the OriginTable for that protocol is an error, as is sending a {\tt
replace\_route} or {\tt delete\_route} for a route that is not in the
OriginTable for that protocol.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Route Lookup}

\begin{verbatim}
lookup_route_by_dest4 ? addr:ipv4 & unicast:bool & multicast:bool 
        -> nexthop:ipv4
lookup_route_by_dest6 ? addr:ipv6 & unicast:bool & multicast:bool 
        -> nexthop:ipv6
\end{verbatim}

These XRLs may be used to see how the RIB would route a packet for a
specific destination.

{\tt nexthop} will return the resolved nexthop if the request is successful,
or all zeros otherwise.  It is an error for the unicast and multicast
fields to both be true or both false.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{VIF Management (test interface)}

\begin{verbatim}
new_vif ? name:txt
add_vif_addr4 ? name:txt & addr:ipv4 & subnet:ipv4net
add_vif_addr6 ? name:txt & addr:ipv6 & subnet:ipv6net
\end{verbatim}

These XRLs can be used to inform the RIB about directly connected
(virtual) interfaces.  The use of these XRLs is intended only for
testing purposes - the RIB normally learns of VIFs directly from the
FEA process.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Route Redistribution}

\begin{verbatim}
redist_enable4 ? to_xrl_target:txt & from_protocol:txt & unicast:bool
               & multicast:bool & cookie:txt
redist_enable6 ? to_xrl_target:txt & from_protocol:txt & unicast:bool
               & multicast:bool & cookie:txt
redist_disable4 ? to_xrl_target:txt & from_protocol:txt & unicast:bool
               & multicast:bool & cookie:txt
redist_disable6 ? to_xrl_target:txt & from_protocol:txt & unicast:bool
               & multicast:bool & cookie:txt
redist_transaction_enable4 ? to_xrl_target:txt & from_protocol:txt
               & unicast:bool & multicast:bool & cookie:txt
redist_transaction_enable6 ? to_xrl_target:txt & from_protocol:txt
               & unicast:bool & multicast:bool & cookie:txt
redist_transaction_disable4 ? to_xrl_target:txt & from_protocol:txt
               & unicast:bool & multicast:bool & cookie:txt
redist_transaction_disable6 ? to_xrl_target:txt & from_protocol:txt
               & unicast:bool & multicast:bool & cookie:txt
\end{verbatim}

These XRLs are intended to be used to enable and disable route
redistribution from a RIB table to an XRL target.
The {\tt *\_transaction\_*} XRLs are used for registering interest in
transaction-based route redistribution (\ie where there is
{\tt start\_transaction} and {\tt commit\_transaction} around each block
of add/delete routes).

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Registration of Interest in Routes}
\label{reg}

\begin{verbatim}
register_interest4 ? target:txt & addr:ipv4 
        -> resolves:bool & base_addr:ipv4 & prefix_len:u32 & 
           real_prefix_len:u32 & nexthop:ipv4 & metric:u32
register_interest6 ? target:txt & addr:ipv6 
        -> resolves:bool & base_addr:ipv6 & prefix_len:u32 & 
           real_prefix_len:u32 & nexthop:ipv6 & metric:u32
deregister_interest4 ?  target:txt & addr:ipv4 & prefix_len:u32
deregister_interest6 ?  target:txt & addr:ipv6 & prefix_len:u32
\end{verbatim}

These XRLs are used to register and deregister interest in routing
information related to a specific IP address. 

Target is the name of the XRL module that registered the interest.

{\tt resolves} indicates whether or not the address is routable.  If
it is not routable, the values of {\tt nexthop} and {\tt metric} are
undefined.  {\tt real\_prefix\_len} returns the prefix length of the routing
entry that matches the address in the request.  {\tt prefix\_len} returns
the prefix length of the largest subnet that covers the address and is
not overlayed by a more specific route.  Thus ${\tt prefix\_len} >= {\tt
real\_prefix\_len}$ and {\tt addr} is an address within the subnet {\tt
base\_addr/prefix\_len} which itself is a subset of the subnet {\tt
base\_addr/real\_prefix\_len}.  

The routing protocol need not ask again for any address that lies
within {\tt base\_addr/prefix\_len} but can not use this answer to determine
anything about addresses that lie outside of {\tt base\_addr/prefix\_len}
but within {\tt base\_addr/real\_prefix\_len}.

\subsection{Registration of Interest in Routes: Client Interface}
When a routing protocol has registered interest in routes, the RIB
will need to be able to asynchronously call the routing protocol to
inform it of any changes.  Thus the routing protocol must implement
the rib client interface.  This consists of the following XRLs:
\begin{verbatim}
route_info_changed4 ? addr:ipv4 & prefix_len:u32 & 
        nexthop:ipv4 & metric:u32
route_info_changed6 ? addr:ipv6 & prefix_len:u32 & 
        nexthop:ipv6 & metric:u32

route_info_invalid4 ? addr:ipv4 & prefix_len:u32
route_info_invalid6 ? addr:ipv6 & prefix_len:u32
\end{verbatim}
The {\tt route\_info\_changed} XRLs inform the routing protocol that the
nexthop or metric associated with the route with subnet {\tt
addr/prefix\_len} has changed.  The registration with the RIB is still
valid.

The {\tt route\_info\_invalid} XRLs inform the routing protocol that the
information associated with the specified subnet is no longer correct.
The registration with the RIB is no longer valid, and the routing
protocol must re-register with the RIB to find out what happened.

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

\begin{itemize}

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

  \item March 10, 2003: Updated to match XORP release 0.2.

  \item June 9, 2003: Updated to match XORP release 0.3: described the new
  RibClient registration mechanism.

  \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 to match XORP release 1.0: replaced ExportTable
  with RedistTable, and fixed the XRLs specification.

  \item April 13, 2005: Updated to match XORP release 1.1: fixed the XRL names
  and added description for the add\_interface\_route and
  replace\_interface\_route XRLs.

  \item March 8, 2006: 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}