rib.tex

来自「BCAST Implementation for NS2」· TEX 代码 · 共 402 行 · 第 1/2 页

about these.

\subsection{RedistTable}

{\it Note, August 2003: RedistTable is unfinished.}

A RedistTable can by dynamically plumbed into the tree of tables at
any point, but it is most likely to be inserted immediately after an
OriginTable.  The purpose of a RedistTable is to allow the configured
(and possibly filtered) redistribution of routes from one routing
protocol to another.  For example, routes from within an AS might be
propagated from OSPF to BGP for external advertisement.

There may be many RedistTables in each RIB.

\section{XRL Interface}

The RIB supports the following XRLs.
\subsection{Routing Protocol Registration}
\begin{verbatim}
add_igp_table4 ? protocol:txt & unicast:bool & multicast:bool
add_igp_table6 ? protocol:txt & unicast:bool & multicast:bool
add_egp_table4 ? protocol:txt & unicast:bool & multicast:bool
add_egp_table6 ? protocol:txt & unicast:bool & multicast:bool
delete_igp_table4 ? protocol:txt & unicast:bool & multicast:bool
delete_igp_table6 ? protocol:txt & unicast:bool & multicast:bool
delete_egp_table4 ? protocol:txt & unicast:bool & multicast:bool
delete_egp_table6 ? protocol: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 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

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

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

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

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

delete_route6 ? protocol:txt & unicast:bool & multicast:bool & 
        network:ipv6net
\end{verbatim}
These XRLs are used to communicate new routes, changed routes, or the
deletion of routes to the RIB.

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_route4 ? addr:ipv4 & unicast:bool & multicast:bool 
        -> nexthop:ipv4
lookup_route6 ? 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 ? from:txt & to:txt & unicast:bool & multicast:bool
redist_enable6  ? from:txt & to:txt & unicast:bool & multicast:bool
redist_disable4 ? from:txt & to:txt & unicast:bool & multicast:bool
redist_disable6 ? from:txt & to:txt & unicast:bool & multicast:bool
\end{verbatim}
These XRLs are intended to be used to enable route redistribution
between routing protocols.  However, this interface is currently
(August 2003) incomplete and should not be used.

\subsection{Registration of Interest in Routes}
\label{reg}
\begin{verbatim}
register_interest4 ? target:txt & addr:ipv4 
        -> resolves:bool & base_addr:ipv4 & prefix:u32 & 
           realprefix:u32 & nexthop:ipv4 & metric:u32

deregister_interest4 ?  target:txt & addr:ipv4 & prefix:u32

register_interest6 ? target:txt & addr:ipv6 
        -> resolves:bool & base_addr:ipv6 & prefix:u32 & 
           realprefix:u32 & nexthop:ipv6 & metric:u32

deregister_interest6 ?  target:txt & addr:ipv6 & prefix: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 realprefix} returns the prefix length of the routing
entry that matches the address in the request.  {\tt prefix} returns
the prefix length of the largest subnet that covers the address and is
not overlayed by a more specific route.  Thus ${\tt prefix} <= {\tt
realprefix}$ and {\tt addr} is an address within the subnet {\tt
base\_addr/prefix} which itself is a subset of the subnet {\tt
base\_addr/realprefix}.  

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

\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.


\subsection{Adding and deleting RIB clients}

\begin{verbatim}
add_rib_client4	? target_name:txt & unicast:bool & multicast:bool
add_rib_client6	? target_name:txt & unicast:bool & multicast:bool

delete_rib_client4 ? target_name:txt & unicast:bool & multicast:bool
delete_rib_client6 ? target_name:txt & unicast:bool & multicast:bool

enable_rib_client4 ? target_name:txt & unicast:bool & multicast:bool
enable_rib_client6 ? target_name:txt & unicast:bool & multicast:bool

disable_rib_client4 ? target_name:txt & unicast:bool & multicast:bool
disable_rib_client6 ? target_name:txt & unicast:bool & multicast:bool
\end{verbatim}

The RIB's ExportTable is responsible for exporting all the winning
unicast routes and any changes of those routes to the FEA.  However
from the RIB's point of view the FEA is just a RibClient, and other
processes may also register to be RibClients and to receive all the
routing information.  By default the FEA is a RibClient for unicast
routes only (it doesn't need to register).  Processes may use the {\tt
add\_rib\_client} XRLs above to become a RibClient for unicast routes,
for multicast routes, or both.  They may also enable and disable the
propagation of this routing information, or deregister completely
using {\tt delete\_rib\_client}.

\end{document}