mfea_arch.tex

xorp源码hg

  \item Interface to inform the multicast-related modules about the
  available virtual interfaces (\eg network interfaces, tunnels, etc.) on
  the system, and to inform them about any changes on those interfaces
  (\eg interface going DOWN, network address change, etc.).

  \item Interface to join or leave a multicast group.

  \item Interface to add/delete MFC entries, \ie entries to the
  multicast forwarding engine.

\end{itemize}

MfeaNode itself does not implement the mechanisms to communicate with
the multicast-related modules (\eg to send or receive control packets
to/from the PIM module). Those mechanisms are outside the scope of
MfeaNode, and must be implemented separately.

MfeaNode contains several pure virtual methods (\eg
\verb=dataflow_signal_send()= is used to send multicast dataflow-related
signals to a multicast-related module that is interested in tracking
dataflow-related conditions)
that must be implemented by a class that inherits MfeaNode.
For example, XrlMfeaNode is a class that uses MfeaNode as a base class;
XrlMfeaNode uses XRL-based communication mechanisms between MfeaNode
and other XORP components such as the PIM and MLD/IGMP modules.

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

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{MfeaVif Description}

MfeaVif is a MFEA-specific virtual (network) interface that is used to keep
various state per interface. Typically, there would be one
MfeaVif per network interface such as physical
interface, tunnel, or the loopback interface. In addition, there is
one special MfeaVif: the PIM Register virtual
interface that is used for sending and receiving PIM Register
packets~\footnote{In the future, the PIM
Register MfeaVif interface may not be part of the MFEA anymore, because
it is strictly PIM-specific.}.

One of the purposes of MfeaVif is to keep various information about each
network interface available on the system: network and subnet address,
is the interface up or multicast-capable, and so on. This information is
obtained from the FEA (the only exception is the PIM Register vif which
is created internally by the MFEA), and is used by the MFEA to keep
track of any changes to an interface (\eg an alias address has been
added/deleted, etc). If there is a change to an interface, those changes
are saved locally by the MFEA, and then the MFEA informs all protocol
modules that are registered by the MFEA.

Another purpose of MfeaVif is to keep track of the multicast groups that
have been joined per interface. For example, if a multicast-related
module that uses the MFEA joins a multicast group on an interface, the
MFEA uses the appropriate system call to join the group on the
specified interface, and at the same time it would keep the appropriate
state on the corresponding MfeaVif. Thus, if another module joins
exactly same multicast group on that interface, but later one of
those modules leaves that group, the MFEA would modify only the appropriate
state in MfeaVif, but will not use a system call to leave the multicast
group on the interface.

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

The public interface for MfeaVif 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:

\begin{itemize}
  \item \verb=mfea/mfea_vif.hh=
  \item \verb=libxorp/vif.hh=
  \item \verb=libproto/proto_unit.hh=
\end{itemize}

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

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{MfeaConfig Description}

MfeaConfig handles the MFEA-specific configuration~\footnote{Currently
(March 2007), MfeaConfig is not implemented; rather, all state is
kept inside MfeaNode instead.}. This configuration is used to configure the
following units:

\begin{itemize}

  \item MfeaNode: how often to read the unicast forwarding table,
  default routing metrics and metric preferences to assign to each
  route, etc.

\end{itemize}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{MfeaDft Description}

Some protocols such as PIM-SM need the bandwidth of multicast data flows
to be monitored: if the bandwidth of a specific data flow (defined by
a source and a group address) is above or below a pre-defined threshold
(defined per data flow), the protocol should be informed. For example, if the
bandwidth of a data flow is zero for some predefined amount of time, the
corresponding multicast routing entry in the multicast routing protocol
module might be deleted (as well as the corresponding multicast
forwarding entry in the multicast forwarding engine). Another example is
the Shortest-Path Tree switch in case of PIM-SM: the SPT switch is
triggered if the bandwidth from a specific source is above a
pre-configured threshold.

If the multicast forwarding engine in the underlying system does
support bandwidth dataflow monitoring, then any addition or
deletion of a dataflow monitor to the MFEA translates to a system call
to the underlying system, and the MFEA itself does not need to keep any
state. However, if the underlying system does not support bandwidth
dataflow monitoring, then the MFEA needs to implement that on its own.
In case of UNIX kernel for example, the kernel supports an ioctl()
system call to obtain the number of octets and packets forwarded so far on
an existing MFC entry. Thus, if the MFEA reads this information twice,
it can compute the data bandwidth between the two readings.

The purpose of the MfeaDft table is to keep state about the dataflows the
MFEA is monitoring (only in the case the underlying
system does not support bandwidth dataflow monitoring). For each entry
in MfeaDft, the MFEA periodically reads the bandwidth forwarding
statistics from the underlying system. If the forwarded bandwidth
satisfies the pre-defined condition for that dataflow, the MFEA
originates a dataflow signal to the module that has installed that
dataflow monitoring entry. This signal is delivered every time the
pre-defined condition is true (until the entry is explicitly deleted by
the module that installed it).

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{ProtoComm Description}

ProtoComm is a per-protocol unit for communication with the
underlying system.

ProtoComm implements various methods that use the appropriate system
calls to open or close a socket per protocol, to send or receive
protocol packets, to join or leave a multicast group (per protocol per
interface), and so on. Typically, there is a single ProtoComm entry per
protocol; \eg one ProtoComm for PIM, another one for IGMP (or MLD in
case of IPv6), etc. When a protocol module registers a network protocol
with MFEA, the corresponding ProtoComm for that protocol is created (if
it did not exist).

Each ProtoComm entry is also used to keep information about various
protocol preferences: \eg whether a protocol module instance is interested in
receiving various kernel upcall signals, etc.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{MfeaMrouter Description}

MfeaMrouter is an unit used for multicast-related communication with the
underlying system. For example, MfeaMrouter is used for the following
tasks (this list may not be complete):

\begin{itemize}

  \item Start/stop the multicast forwarding engine.

  \item Add/delete an interface used for multicast forwarding by the
  underlying system.

  \item Add/delete a MFC entry within the multicast forwarding engine.

  \item Install dataflow monitors (only if the underlying system supports
  that feature).

  \item Read data bandwidth forwarding statistics per dataflow (only if
  the underlying system does not support bandwidth dataflow monitoring
  and upcall).

\end{itemize}

MfeaMrouter is started when MfeaNode is started, and usually stops
operation when MfeaNode is stopped.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%     APPENDIX
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\appendix
\section{Modification History}

\begin{itemize}

  \item December 11, 2002: Initial version 0.1 completed.

  \item March 10, 2003: Updated to match XORP release 0.2.

  \item June 9, 2003: Updated to match XORP release 0.3:
  changes related to the MFEA--FEA merging, and refactoring of
  some of the MFEA internals.

  \item August 28, 2003: Updated the version to 0.4, and the date.

  \item November 6, 2003: Updated the version to 0.5, and the date.

  \item July 8, 2004: Updated to match XORP release 1.0.

  \item January 27, 2005: Removed MRIB-related text, because the MFEA
  does not deal with the MRIB information anymore.

  \item April 13, 2005: Updated to match XORP release 1.1.

  \item March 8, 2006: Updated the version to 1.2, and the date.

  \item August 2, 2006: Updated the version to 1.3, and the date.

  \item March 20, 2007: Updated the version to 1.4, and the date.

\end{itemize}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%     BIBLIOGRAPHY
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\bibliography{../tex/xorp}
\bibliographystyle{plain}

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