design.tex

xorp源码hg

      accept;
   }
}
policy-statement out {
   term rip {
      source {
         protocol rip;
         metric 10;
      }
      action {
         accept;
      }
   }
   term default {
      action {
         reject;
      }
   }
}
protocols {
   rip {
      import in;
   }
   bgp {
      export out;
   }
}
\end{verbatim}
In this example, BGP will never advertise a route. Many advertisements from RIP
with metric 10 may have reached the router, but all RIP routes matched at
position 2 of figure~\ref{filters} will have a modified metric of 3, thus
failing the match.




\section{Policy framework support}
Various elements need to be added in order to support policy based filtering.
As figure~\ref{filters} indicates, most of the matching and filtering (positions
1,2,4) occurs within routing protocols. The RIB will only redistribute routes to
specific protocols (position 3).



\subsection{Policy tags}
In order to support policies, the concept of {\em policy tags} is introduced.
Each policy is assigned a unique identifier. The policy tag is a set of zero or
more policy identifiers. All routes will have this extra tag field which will
effectively associate them with policies.

Consider the following statement:
\begin{verbatim}
protocol bgp {
   export policy-A policy-B policy-C;
}
\end{verbatim}
For simplicity suppose these three policies were assigned identifiers A, B and C
respectively. The first phase is to match BGP routes to those policies. If a
match is successful, the appropriate id is inserted in the tag set. 


\subsection{Routing protocols}
A specific interface must be implemented by a routing protocol for it to support
policy filtering. The protocol must be able to:
\begin{description}
\item[read] Have the ability to read a value from a route. This will enable the
filter to match route attributes.
\item[write] Be able to modify attributes of the route, including protocol
specific fields. This also includes the ability to add and remove policy tags.
\end{description}


\subsection{RIB}
The RIB will support route redistribution as it is the bridge between different
routing protocols. It may be achieved by allowing protocols to register interest
on routes based on specific tag sets. All routes with a specific tags will be
forwarded to specific routing protocols. In the RIB, the tag set of a route will
reflect the source match of export policies, which is enough information to
identify the export protocols bound to those particular policies. Multiple
protocols may export based on the same policy and the RIB will forward the
routes to all those protocols.

\section{Policy framework interaction}
The policy process is the manager of all policy decision. However, most of the
work is done within routing protocols. Matching is achieved as a collaboration
between the policy filters and the protocols. Actions are entirely performed
within protocols. The policy process is the entity which manages policy filters
and enables route redistribution.

\subsection{Import policies}
Each routing protocol will have, internally, a policy filter. This generic
filter will read needed route values via a {\em reader}. All the complex
matching is achieved by the generic filter and implementing a protocol specific
reader should require little thought and skill, which allows new protocols to be
added with ease. A protocol specific {\em writer} may also be invoked by the
filter in order to accomplish possible route modification actions. The read and
write interface is currently implemented as one.


The main policy process will send protocol specific import policies to the
specific filters. These filters will have enough information to match routes and
execute the appropriate actions. Figure~\ref{infilter} illustrates a pre-decision
import filter and the main components it interacts with.

\begin{figure}
\setlength{\unitlength}{1mm}
\begin{center}
\begin{picture}(85,50)
%\put(0,0){\framebox(85,50){}}


\put(0,34){\framebox(15,10){Policy}}
\put(15,34){\line(2,-1){15}}

% incoming arrows
\multiput(20,20)(0,2){3}{\vector(1,0){10}}

% filter components
\put(30,32){\framebox(15,10){Reader}}
\put(37,27){\line(0,1){5}}
\put(30,17){\framebox(15,10){Filter}}
\put(37,17){\line(0,-1){5}}
\put(30,2){\framebox(15,10){Writer}}

% filtered routes
\multiput(45,21)(0,2){2}{\vector(1,0){15}}

% decision
\put(60,17){\framebox(15,10){Decision}}

% only 1 winner =D
\put(75,22){\vector(1,0){10}}

% routing protocol boundary
\put(25,0){\dashbox(55,45)[tr]{Routing protocol}}

\end{picture}
\caption{\label{infilter}Import policy filter}
\end{center}
\end{figure}


\subsection{Export policies}
Export policies interact with routing protocols in two stages as shown in
figure~\ref{filters}. Filters applied in those positions resemble import
filters in structure, but with some differences. 

An export policy may be split up in two parts: the source match, and the
destination match and actions. The first part is matched in position 2 of
figure~\ref{filters}. When matched, it is assigned the appropriate policy tags.
To complete the match, the next part of the policy is matched in position 4 and
the specified actions may take place.

To get from position 2 to 4, we rely on the RIB doing correct route
redistribution. This is accomplished by the policy process, which registers the
interest export protocols have in respect to specific tag sets. The RIB will
forward all routes with specific tags to interested export protocols.

Consider the following configuration:
\begin{verbatim}
policy-statement x {
   source {
      protocol rip;
      metric == 2;
   }
   dest {
      protocol bgp;
      localpref == 100;
   }
   actions {
      accept;
   }
}

protocol bgp {
   export x;
}
\end{verbatim}
Logically, this may be split up into:
\begin{verbatim}
policy-statement UNIQUEID_Z {
   source {
      protocol rip;
      metric == 2;
   }
   actions {
      modify policytags += UNIQUEID_Z;
   }
}

policy-statement x {
   source {
      policytags <= UNIQUEID_Z; /* implicit set of one element */
   }
   dest {
      protocol bgp;
      localpref == 666;
   }
   actions {
      accept;
   }
}
\end{verbatim}
After the split is done, policy UNIQUEID\_Z is sent to the filter in position 2
of RIP. The filter is just like an import filter but is post-decision.  In
reality however this is considered an export filter as it performs the source
match of exported routes.

Policy x is then sent to the filter in position 4 of BGP. This filter is
identical to the import filter. However it is not post/pre-decision but it
rather is ``post-ready'' as it is applied after the advertisement is formed and
ready.

The only step left is passing all routes which contain tag UNIQUEID\_Z to
position 4 (route redistribution). The policy process manages this as described
earlier.


\begin{figure}
\setlength{\unitlength}{1mm}
\begin{picture}(120,60)
%\put(0,0){\framebox(120,60){}}
%policy at top
\put(53,50){\framebox(15,10){Policy}}
\put(60,50){\line(-3,-1){30}}
\put(60,50){\line(1,-2){11.5}}
\put(60,50){\line(5,-1){50}}


% bottom incoming, outgoing routes
\multiput(0,4)(0,4){3}{\vector(1,0){2}}
\put(117,8){\vector(1,0){3}}
% ditto for top
\multiput(0,32)(0,2){3}{\vector(1,0){4}}
\put(115,34){\vector(1,0){4}}

% incoming rt protocols
\put(4,30){\framebox(15,10){Decision}}
\put(19,34){\vector(1,0){5}}
\put(24,30){\framebox(10,10){Filter}}
\put(2,25){\dashbox(34,20)[bl]{Routing protocol}}

\put(2,0){\framebox(34,20){Routing protocol}}

\put(34,34){\vector(1,-1){8}}
\put(36,12){\vector(1,1){6}}

% rib
\put(42,17){\framebox(15,10){Decision}}
\put(57,22){\vector(1,0){5}}
\put(62,17){\framebox(15,10)[c]{\parbox{15mm}{\begin{center}Redist\\table\end{center}}}}
\put(40,12){\dashbox(39,20)[b]{RIB}}

\put(77,22){\vector(1,1){8}}
\put(77,22){\vector(1,-1){6}}

% exporting rt protocols
\put(85,30){\framebox(15,10){Ready}}
\put(100,34){\vector(1,0){5}}
\put(105,30){\framebox(10,10){Filter}}
\put(83,25){\dashbox(34,20)[b]{Routing protocol}}


\put(83,0){\framebox(34,20){Routing protocol}}

\end{picture}
\caption{\label{outfilter}Export policy filter}
\end{figure}
Figure~\ref{outfilter} summarizes how all components interact to achieve policy
based filtering on export routes. Although the filter is spread out in various
locations it is a single logical filter, just like the import filter.

A consideration to make is that even routes which do not pass through the RIB
may be matched in export policies. For example, consider BGP communicating to
BGP directly without storing the information in the RIB for some reason
(internal protocol communication). Since the matching is done entirely inside
the protocol, filtering may be applied. The RIB is merely used for route
redistribution.


\section{Conclusion}
Routing protocols will need to implement an interface that allows attribute
reading and writing. Also, all routes must have an extra attribute for the
policy tag set. This will enable policy based filtering to be implemented. 

The policy framework may be relatively decoupled from the other components.
Keeping the interface protocols must implement simple is crucial as every single
protocol will have to re-implement it. Also, that is where most interaction
between policies and the rest of the components occur. 

The RIB will only need to support the extra tag field per route. 

\end{document}