multicast_arch.tex

xorp源码hg

%
% $XORP: xorp/docs/multicast/multicast_arch.tex,v 1.22 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 Multicast Routing Design Architecture \\
\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 routing
architecture.  It is intended to provide a starting point for software
developers who wish to modify the multicast-related software.

The XORP multicast architecture consists of user-level software
implementation of multicast routing protocols such as PIM-SM and IGMP.
This document provides an overview of the interaction among them,
as well as the interaction with the underlying multicast forwarding
engine and other parts of the system.

As with the other parts of the XORP architecture, the multicast
architecture is based on modularity and abstraction.
In particular, there is one process per protocol, and each process
typically communicates with other processes by using XRLs, the XORP
inter-process communication mechanism~\cite{xorp:xrl}.

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

Acronyms used in this document:

\begin{itemize}

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

  \item {\bf FIB}: {\bf F}orwarding {\bf I}nformation {\bf B}ase

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


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Protocol Abstraction}

As with the rest of the XORP architecture, the XORP multicast routing
architecture is designed such that each of the implemented protocols
can be used for both real-world routing and for network simulations.  A
simulation can be composed of several (UNIX) processes, one per
protocol entity controlled by a single process, or all protocol entities
running within a single process. For debugging purpose the latter may be
simpler to use and control. Further, the all-in-one model might be more
scalable. The implication of this is that a protocol implementation
must not keep any global state.

In routing, the concept of a network port or interface is essential in a
sense that a routing protocol entity communicates with the rest of the
world through such ports/interfaces (think of this as a protocol entity
having several virtual interfaces and each virtual interface corresponds
to a physical interface, and those interfaces are used for
sending/receiving control messages to/from other routers). In case of
PIM for example, the routing entity has several virtual interfaces one
per each physical interface it controls.  In case of BGP,
the routing entity has several ports, one per each BGP peering.

In term of C++ implementation, each virtual interface is a class; each
protocol entity is a separate class: a single protocol object has several
virtual interfaces (see Figure~\ref{fig:mcast_proto_abstraction}).

\begin{figure}[htbp]
  \begin{center}
    \includegraphics[width=5.0in]{figs/mcast_proto_abstraction}
    \caption{Multicast protocol abstraction}
    \label{fig:mcast_proto_abstraction}
  \end{center}
\end{figure}

At the protocol level implementation, the virtual interfaces do not
posses knowledge about the particular communication method used to send
or receive packets. To achieve this, the implementation uses pure
virtual C++ class methods (\eg methods declared such as:
{\it virtual int send() = 0;}).
The declaration of such methods requires that each class must be
inherited by a ``wrapper'' class that implements all pure virtual
methods. Then, all the details about the particular mechanism
that is used to send or receive packets are in this wrapper class.
For example, that class might use XRLs, but it could be any other
mechanism that the developer provides (\eg a third-party simulation
testbed environment).

Such abstraction makes it very easy to reuse the protocol-specific code
for any other purpose, or to create several virtual ``nodes'' each of
them running the particular protocol. Those nodes can be either within
the same (UNIX) process or each of them running as a separate process,
as long as we have the right mechanism that allows them to communicate
with each other.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{MLD/IGMP Daemon/Library}

A physical interface is owned by a single multicast routing
protocol, therefore we can have MLD/IGMP running as a library linked with
a multicast routing protocol on each of the
interfaces owned by that protocol. This solution may not work only if
there is more than one protocol that needs multicast group membership
information on an interface.

The alternative solution is to have a separate MLD/IGMP daemon that
takes care of multicast group membership for all interfaces, and then
reports that information to all interested parties. Thus, more than one
protocol may receive multicast group membership information per
interface.

Separating MLD/IGMP from the routing code has the advantage of reducing
dependency and improving robustness; \eg if the MLD/IGMP code crashes, the
routing protocol can continue running. Further, if we want to upgrade
the software, and if we are running MLD/IGMP as a
separate process, then the upgrade can be performed by starting a new
MLD/IGMP daemon in place of the old one. Therefore, the upgrade does
not require to stop the PIM daemon for example, which is very important
for routers in real-world operation.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Multicast Modules Interaction}

\begin{figure}[htbp]
  \begin{center}
    \includegraphics[scale=0.5]{figs/mcast_modules_interaction}
    \caption{Multicast Modules Interaction}
    \label{fig:mcast_modules_interaction}
  \end{center}
\end{figure}

Figure~\ref{fig:mcast_modules_interaction} shows the interactions between
the multicast-related modules. Those interactions are:

\begin{itemize}

  \item FEA--MFEA: to propagate vif-related information updates from the
   FEA to the MFEA.

  \item MFEA--PIM: to send or receive PIM control packets, to forward
   PIM-related signals from the multicast forwarding engine to PIM, to
   establish the communication between PIM and the multicast-forwarding
   engine, for the MFEA to join or leave a multicast group on behalf of
   PIM, etc.

  \item MFEA--MLD/IGMP: to send or receive MLD/IGMP control
  packets, and to join or leave a multicast group on behalf of
  MLD/IGMP.

  \item MLD/IGMP--PIM: for PIM to monitor multicast membership about
  local members.