pim_arch.tex

xorp源码hg

%
% $XORP: xorp/docs/pim/pim_arch.tex,v 1.25 2007/03/15 00:43:14 pavlin Exp $
%

\documentclass[11pt]{article}

%\usepackage[dvips]{changebar}

\usepackage{subfigure}
\usepackage{fullpage}
\usepackage{setspace}
\usepackage{times}
\usepackage{latexsym}
\usepackage{epsfig}
\usepackage{graphicx}
\usepackage{xspace}
\usepackage{color}
\usepackage{amsmath}
\usepackage{rotating}
\usepackage{moreverb}
\usepackage{listings}
\usepackage{alltt}
\usepackage{stmaryrd}
%\usepackage[dvipdf]{graphics}
%\usepackage[dvips]{graphicx}
%\usepackage{xorp}

\definecolor{gray}{rgb}{0.5,0.5,0.5}
\newcommand{\etc}{\emph{etc.}\xspace}
\newcommand{\ie}{\emph{i.e.,}\xspace}
\newcommand{\eg}{\emph{e.g.,}\xspace}
%\newcommand{\comment}[1]{{\color{gray}[\textsf{#1}]}}
%\newcommand{\comment}[1]{}

% Changebar stuff
% \newenvironment{colorcode}{\color{blue}}{}
% \renewcommand{\cbstart}{\begin{colorcode}}
% \renewcommand{\cbend}{\end{colorcode}}

% \pagestyle{empty}

\begin{document}

\title{XORP PIM-SM Routing Daemon \\
\vspace{1ex}
Version 1.4}
\author{ XORP Project					\\
	 International Computer Science Institute	\\
	 Berkeley, CA 94704, USA			\\
         {\it http://www.xorp.org/}			\\
	 {\it [e-mail]}
}
\date{March 20, 2007}

\maketitle


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Introduction}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Overview}

This document provides an overview of the XORP PIM-SM~\cite{PIM-SM}
Routing Daemon. It is intended to provide a starting point for software
developers who wish to modify this software.

A router running PIM-SM interacts with other PIM-SM routers and
multicast group members, computes the multicast routing state, and installs
the corresponding multicast forwarding state in the multicast forwarding
engine.

The chosen architecture for the XORP PIM-SM implementation emphasizes on
correctness and extensibility rather than high performance or minimal
memory footprint. PIM-SM is a fairly complicated protocol, therefore it
is very important that the implementation follows closely the protocol
specification. Otherwise, premature optimization or ``cutting corners''
might introduce problems that are difficult to find. Only after the
implementation is well tested, we would
try to optimize those parts of the implementation that should prove
to be a bottleneck.

Currently (March 2007), the PIM-SM implementation is based
on the specification in the following documents:

\begin{itemize}
  \item \verb=draft-ietf-pim-sm-v2-new-11.{ps,txt}= (The core PIM-SM
  specification).
  \item \verb=draft-ietf-pim-sm-bsr-03.{ps,txt}= (The Bootstrap mechanism
  specification).
\end{itemize}

The only major feature not implemented yet is security.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Acronyms}

Acronyms used in this document:

\begin{itemize}

  \item {\bf MFC}: {\bf M}ulticast {\bf F}orwarding {\bf C}ache: another
  name for an entry in the multicast forwarding engine (typically used
  on UNIX systems).

  \item {\bf MFEA}: {\bf M}ulticast {\bf F}orwarding {\bf E}ngine
  {\bf A}bstraction

  \item {\bf MLD/IGMP}: {\bf M}ulticast {\bf L}istener {\bf D}iscovery/{\bf
  I}nternet {\bf G}roup {\bf M}anagement {\bf P}rotocol

  \item {\bf MRIB}: {\bf M}ulticast {\bf R}outing {\bf I}nformation
  {\bf B}ase

  \item {\bf PIM-SM}: {\bf P}rotocol {\bf I}ndependent {\bf M}ulticast--{\bf
  S}parse {\bf M}ode

  \item {\bf RIB}: {\bf R}outing {\bf I}nformation {\bf B}ase

\end{itemize}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{PIM-SM Design Architecture Overview}

\begin{figure}[htbp]
  \begin{center}
    \includegraphics[width=6.0in]{figs/pim_design_overview}
    \caption{PIM-SM design overview}
    \label{fig:pim_design_overview}
  \end{center}
\end{figure}

Figure~\ref{fig:pim_design_overview} provides a general overview of the
PIM-SM components. For each component there is a C++ class with exactly
the same name. The main components are briefly described below:

\begin{itemize}

  \item {\bf PimNode:} a representation of a single PIM-SM routing unit
  (\eg a virtual PIM-SM router).
  Typically, there would be a single PimNode per PIM-SM router.

  \item {\bf PimVif:} PIM-specific virtual (network) interface that is used for
  sending and receiving PIM control packets.

  \item {\bf PimScopeZoneTable:} the table that contains information about
  scoped zones.

  \item {\bf PimMrt:} PIM-specific multicast routing table.

  \item {\bf PimBsr:} the PIM-Bootstrap mechanism unit.

  \item {\bf RpTable:} the table with the PIM-SM RP information.

  \item {\bf PimMribTable:} the table with the MRIB information.

  \item {\bf PimConfig:} contains PIM-specific configuration.

\end{itemize}

Those components are described in details in
Section~\ref{sec:components_description}.
For information about the interaction between the PIM-SM and other modules
see \cite{xorp:multicast_arch}.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Components Description}
\label{sec:components_description}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{PimNode Description}

PimNode is a representation of a single PIM-SM routing unit (\eg a
virtual PIM-SM router).
Typically, there would be a single PimNode per PIM-SM router.
However, in some cases a PIM-SM router may have more than one
routing unit. For example, it could have one PimNode for IPv4, and
another one for IPv6 multicast routing. Further, if we want to
run PIM-SM in a simulation environment, each PIM-SM router within that
simulation will be represented by a single PimNode.

From a developer's point of view, PimNode contains all the state related to
the PIM-SM routing unit, and exports the front-end interface to interact with
that unit.
For example, PimNode contains the methods to
start/stop or configure PIM-SM, to send/receive PIM control packets
to/from the routing unit, or to get protocol-related statistics.
Those methods are described in the following files:

\begin{itemize}
  \item \verb=pim/pim_node.hh=
  \item \verb=libproto/proto_node.hh=
  \item \verb=libproto/proto_unit.hh=
\end{itemize}

PimNode itself does not implement the mechanisms to communicate with
other routing units (\eg to send or receive control packets to/from the
network), or to perform other PIM-independent operations such as
installing multicast forwarding entries in the multicast forwarding
engine. Those mechanisms are outside the scope of PimNode, and must be
implemented separately.

PimNode contains several pure virtual methods (\eg
\verb=join_multicast_group()= is used to join a multicast group on
an interface) that must be implemented by a class that inherits PimNode.
For example, XrlPimNode is a class that uses PimNode as a base class;
XrlPimNode uses XRL-based communication mechanisms between PimNode
and other XORP components such as the MFEA and MLD/IGMP modules.

By default, PimNode is disabled; therefore, on startup it must be enabled
explicitly.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{PimVif Description}

PimVif is a PIM-specific virtual (network) interface that is used for sending
and receiving PIM control packets. It includes the methods for processing and
composing PIM control messages, as well as various state per interface
(\eg the information about PIM-SM neighbors).

Typically, there would be one PimVif per network interface such as
physical interface, tunnel, or the loopback
interface. In addition, there would be one special PimVif virtual
interface: the PIM Register virtual interface that is used for sending
and receiving PIM Register messages. Not all virtual interfaces are
used by PIM; for example, all interfaces that are not multicast
capable, and the loopback interface are ignored for multicast
routing.

Typically, from developer's point of view, all interaction with PimVif
would be through PimNode~\footnote{For simplicity, currently (March 2007)
there are few occasions when XrlPimNode uses direct access to PimVif.}.

The public interface for PimVif contains the methods to manipulate a
virtual (network) interface. Those methods are to start/stop/enable/disable a
virtual interface, and to configure it. The methods are described in
the following files: