mfea_arch.tex

xorp源码hg

%
% $XORP: xorp/docs/mfea/mfea_arch.tex,v 1.25 2007/03/15 00:43:13 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 Multicast Forwarding Engine Abstraction \\
\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 Multicast Forwarding
Engine Abstraction (MFEA). It is intended to provide a starting point
for software developers who wish to modify this software.

The main purpose of the MFEA is to abstract the underlying system and
the multicast forwarding engine, and to provide a consistent interface
to multicast-related modules such as PIM and MLD/IGMP. Thus, if we want
to use PIM and MLD/IGMP on different OS platform or hardware, we
would have to modify the MFEA only. In addition, all the
complexity associated with network sockets, sending and receiving
packets, and so on are moved away from the protocol modules.
This eliminates code duplication, and reduces greatly the
development overhead associated with protocol-independent
issues when implementing a new protocol. Finally, if we want to use
PIM and MLD/IGMP in a simulation-like environment, it will be sufficient
to add the simulation environment support only to the MFEA.

Currently (March 2007), the MFEA supports abstraction for
the following systems:

\begin{itemize}
  \item DragonFlyBSD, FreeBSD, NetBSD, and OpenBSD
  \item Linux
\end{itemize}

In the future, the MFEA will support simulation environment, and
abstraction for Click~\cite{CLICK-PROJECT} forwarding
path~\footnote{Currently (March 2007) Click does
not support multicast yet.}. Support for other systems will be added
on-demand if there are available resources.

Note that typically the MFEA would be part of the unicast FEA
process~\cite{xorp:fea}, though logically it is a separate entity.
However, if someone wants to run the MFEA as a separate process, it
requires very small development effort to do this because of the logical
separation between the FEA and the MFEA.

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

Acronyms used in this document:

\begin{itemize}

  \item {\bf FEA}: {\bf F}orwarding {\bf E}ngine {\bf A}bstraction

  \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 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{MFEA Design Architecture Overview}

\begin{figure}[htbp]
  \begin{center}
    \includegraphics[scale=0.5]{figs/mfea_design_overview}
    \caption{MFEA design overview}
    \label{fig:mfea_design_overview}
  \end{center}
\end{figure}

Figure~\ref{fig:mfea_design_overview} provides a general overview of the
MFEA 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 MfeaNode:} a representation of a single MFEA unit
  (\eg as part of a virtual multicast router).
  Typically, there would be a single MfeaNode per multicast router.

  \item {\bf MfeaVif:} MFEA-specific virtual (network) interface that is used
  to keep state per network interface.

  \item {\bf MfeaConfig:} contains MFEA-specific configuration.

  \item {\bf MfeaDft:} table with dataflow-related information for
  estimating the bandwidth per dataflow.

  \item {\bf ProtoComm:} per-protocol UNIX-specific unit for
  communication with the underlying system.

  \item {\bf MfeaMrouter:} unit for multicast-related communication with
  the underlying system.

\end{itemize}

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

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


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{MfeaNode Description}

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

From a developer's point of view, MfeaNode contains all the state
related to the MFEA unit, and exports the front-end interface
to interact with that unit.
For example, MfeaNode contains the methods to
start/stop or configure the MFEA, or to send/receive protocol control
packets (\eg PIM or MLD/IGMP) to/from the unit. Those methods are
described in the following files:

\begin{itemize}
  \item \verb=mfea/mfea_node.hh=
  \item \verb=libproto/proto_node.hh=
  \item \verb=libproto/proto_unit.hh=
\end{itemize}

MfeaNode provides the following abstraction to the multicast-related
modules such as PIM and MLD/IGMP:

\begin{itemize}

  \item Interface to add/delete/start/stop a protocol within the MFEA
  and the underlying system.

  \item Interface to send or receive protocol packets through the
  underlying system.

  \item Interface to receive (kernel) upcalls/signals from the
  underlying system, and to forward those signals to the
  multicast-related modules that are interested in receiving those
  signals. Examples of such signals in case of UNIX kernel are NOCACHE or
  WRONGVIF/WRONGMIF: the former one is sent when the underlying multicast
  forwarding engine has no multicast forwarding entry for a multicast
  packet; the latter one is sent when a multicast data packet has
  arrived on an interface that is not the expected incoming interface to
  forward that data packet.

  \item Interface to add/delete dataflow monitors, to monitor network
  bandwidth per dataflow, and to send the appropriate signals to the
  interested multicast-related modules. For example, the PIM-SM module
  might be interested to know when the bandwidth of a given dataflow becomes
  zero, or is above a threshold.