slides.tex

xorp源码hg

\end{slide}

%%======================================================================
\begin{slide}
\slidetitle{Using XRLs: C++}

All header files are auto-generated; developer implements only XRL handlers:

\begin{verbatim}
XrlCmdError XrlPimNode::pim_0_1_enable_vif(
    // Input values, 
    const string&       vif_name, 
    // Output values, 
    bool&               fail,
    string&             reason)
{
    fail = enable_vif(vif_name, reason);
    return XrlCmdError::OKAY();
}
\end{verbatim}

\end{slide}

%%======================================================================
\begin{slide}
\slidetitle{Using XRLs: Shell Script}

Everything is ASCII text:

\begin{verbatim}
pim_enable_vif()
{
    vif_name=$1
    XRL="finder://$PIM_TARGET/pim/0.1/enable_vif"
    XRL_ARGS="?vif_name:txt=$vif_name"
    call_xrl $XRL$XRL_ARGS
}
\end{verbatim}

\end{slide}

%%======================================================================
\begin{slide}
\slidetitle{Extensibility: RIB}

\begin{center}
  \includegraphics[width=8.0in]{figs/routingtable}
\end{center}

\begin{itemize}
  \item Object-oriented routing table design
  \item Add new merged tables implementing new merging policies, \dots
\end{itemize}

\end{slide}

%%======================================================================
\begin{slide}
\slidetitle{Extensibility/performance: Click forwarding path}

\begin{center}
  \includegraphics[width=2.5in]{figs/ipr.1}
\end{center}

Fast kernel forwarding; easy to write extensions

\end{slide}

%%======================================================================
\begin{slide}
\slidetitle{Robustness}

\begin{itemize}

  \item Policy decision: Strong robustness for user-level processes
  \begin{itemize}
    \item Difficult to get performance, robustness, and extensibility
    simultaneously
  \end{itemize}

  \item Facilitated by multi-process design
  \begin{itemize}
    \item Automatically restart processes that crash
  \end{itemize}

  \item XRL sandboxes
  \begin{itemize}
    \item All interaction with router through XRLs
    \item Redirect XRLs to run new protocols in a sandbox
  \end{itemize}

\end{itemize}

\end{slide}

%%======================================================================
\begin{slide}
\slidetitle{Improving robustness and performance: distributed router}

\begin{itemize}

  \item XRLs can be sent across network

  \item Each routing process can run on a separate machine

  \item Only the FEA must run on the machine with the forwarding engine:
  \begin{itemize}
    \item The memory and the CPU are not the bottleneck
    \item Improved robustness through hot-swapping of routing modules
  \end{itemize}

\end{itemize}

\end{slide}

%%======================================================================
\begin{slide}
\slidetitle{Example of a distributed router}

\begin{center}
  \includegraphics[width=8.0in]{figs/distributed_router}
\end{center}

\end{slide}

%%======================================================================
\begin{slide}
\slidetitle{Distributed router (cont.)}

\begin{itemize}

  \item The Router Manager coordinates the modules and the interaction among
  them.

  \item A routing protocol instance doesn't care whether it is part of a
  distributed router, or whether it is running as a backup

  \item Potential issues:
  \begin{itemize}
  \item Communication latency
  \item Bandwidth overhead
  \item Synchronization
  \end{itemize}

\end{itemize}

\end{slide}

%%======================================================================
\begin{slide}
\slidetitle{What does it take to implement a routing protocol?}

PIM-SM (Protocol Independent Multicast-Sparse Mode): case-study

\begin{itemize}

  \item Fairly complicated protocol (protocol specification is 100 + 25
  pages), full of tiny details:
  \begin{itemize}
    \item Early specifications (two RFCs) easy to read, difficult to decode and
    implement
    \item Lastest spec is much more ``implementor-friendly''
  \end{itemize}

  \item Lots of routing state and state dependency

\end{itemize}

\end{slide}

%%======================================================================
\begin{slide}
\slidetitle{0. Get yourself into the right mindset}

Think \Red{SIMPLICITY} and \Red{CONSISTENCY}:

\begin{itemize}

  \item Simplicity gives you lots of space for maneuvers

  \item Consistency (\eg in variables naming): things don't get into your way
  when you shuffle them around

  \item Which one comes first would be a trade-off

  \item Don't go into extremes

\end{itemize}

\end{slide}

%%======================================================================
\begin{slide}
\slidetitle{Forget (for now) the word ``optimization''!!}

PIM-SM may have lots of routing state:

\begin{itemize}
  \item So what, by the time the implementation is ready for prime-time, the
  price of memory will fall in half!

  \item Premature optimization results in complicated design, which is a sure
  sign for disaster!

  \item Solve performance issues when you do testing and profiling (\ie after
  the implementation is completed)

\end{itemize}

\end{slide}

%%======================================================================
\begin{slide}
\slidetitle{1. Design and understand the interaction with other modules}

\begin{center}
  \includegraphics[width=6.0in]{figs/pim_other_modules_interaction}
\end{center}

% For now don't worry about the details.

\end{slide}

%%======================================================================
\begin{slide}
\slidetitle{2. Break-down the protocol into semi-independent units}

\begin{center}
  \includegraphics[width=6.0in]{figs/pim_design_overview}
\end{center}

\end{slide}

%%======================================================================
\begin{slide}
\slidetitle{Protocol units break-down}

\begin{itemize}

  \item Probably the most difficult part

  \item There is no way you will get it right the first time!

  \item Simplicity comes first!

\end{itemize}

\end{slide}

%%======================================================================
\begin{slide}
\slidetitle{3. Protocol units implementation}

\begin{itemize}

  \item If you got your design right, in this stage you need to concentrate
  only on the protocol detail

  \item Be consistent!

  \item Each unit must respond to common methods/commands. E.g.:
  start/stop/enable/disable.

  \item Try to avoid implementation-specific assumptions

\end{itemize}

\end{slide}

%%======================================================================
\begin{slide}
\slidetitle{4. Testing, testing, testing}

\begin{itemize}

  \item If you don't test it, it doesn't work!

  \item Detailed testing takes time

  \item If you can, build a testing framework that allows you to perform
  automated testing any time you change something

  \item Now you can profile and optimize

\end{itemize}

\end{slide}

%%======================================================================
\begin{slide}
\slidetitle{Dependency tracking mechanism}

\begin{itemize}

  \item For each input event, what are the operations to perform and their
  ordering

  \item If the protocol is simple, you can take care of this by hand

  \item Unfortunately, this is not the case with PIM-SM:
  total of 50 input events, and 70 output operations.   

\end{itemize}

\end{slide}

%%======================================================================
\begin{slide}
\slidetitle{PIM-SM dependency tracking mechanism}

PIM-SM spec has tens of macros like:

\begin{small}
\begin{verbatim}
pim_include(S,G) =
    { all interfaces I such that:
      ( (I_am_DR( I ) AND lost_assert(S,G,I) == FALSE )
        OR AssertWinner(S,G,I) == me )
       AND  local_receiver_include(S,G,I) }
\end{verbatim}
\end{small}

The corresponding state dependency rule is:
\begin{small}
\begin{verbatim}
void
PimMreTrackState::track_state_pim_include_sg(list<PimMreAction> action_list)
{
    track_state_i_am_dr(action_list);
    track_state_lost_assert_sg(action_list);
    track_state_assert_winner_sg(action_list);
    track_state_local_receiver_include_sg(action_list);
}
\end{verbatim}
\end{small}

\end{slide}

%%======================================================================
\begin{slide}
\slidetitle{Dependency tracking}

\begin{center}
  \includegraphics[scale=0.6]{figs/pim_state_dependency}
\end{center}

\end{slide}

%%======================================================================
\begin{slide}
\slidetitle{Dependency tracking (2)}

\begin{center}
  \includegraphics[scale=0.6]{figs/pim_state_dependency2}
\end{center}

\end{slide}

%%======================================================================
\begin{slide}
\slidetitle{Dependency tracking (3)}

\begin{center}
  \includegraphics[scale=0.6]{figs/pim_state_dependency3}
\end{center}

\end{slide}

%%======================================================================
\begin{slide}
\slidetitle{Dependency tracking (4)}

\begin{center}
  \includegraphics[scale=0.6]{figs/pim_state_dependency4}
\end{center}

\end{slide}

%%======================================================================
\begin{slide}
\slidetitle{Dependency tracking (5)}

\begin{center}
  \includegraphics[scale=0.6]{figs/pim_state_dependency5}
\end{center}

\end{slide}

%%======================================================================
\begin{slide}
\slidetitle{Dependency tracking usage}

\begin{itemize}
  \item The unidirectional ``graph'' is semi-defined by the state computation
  macros

  \item For each macro, write the corresponding state dependency rule

  \item All state dependency is pre-computed once on start-up

  \item If the spec changes, the rules are easy to update

  \item If the spec does not use macros for state computation, write your own
  macros

\end{itemize}

\end{slide}

%%======================================================================
\begin{slide}
\slidetitle{Status}

\begin{itemize}

  \item Completed: core design, IPC, RIB, BGP, PIM-SM, IGMP, FEA

  \item In progress: OSPF, RIP adaptation, IPv6, Click integration,

  \item Future work: create XORP simulation environment

  \item First preliminary release early December: \\
  {\bf http://www.xorp.org/}

\end{itemize}

\end{slide}

%%======================================================================
\begin{slide}
\slidetitle{Summary}

\begin{itemize}

  \item XORP tries to close the gap between {\bf research} and {\bf practice}

  \item Routing architecture designed for {\bf extensibility} and {\bf
  robustness}.

  \item Can be used to build distributed routers

  \item XORP simulation environment can facilitate protocol development: the
  simulation and the real-world prototype use exactly same code

\end{itemize}

\end{slide}

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