multicast_arch.tex

xorp源码hg

  \item RIB--PIM: for PIM to obtain MRIB information.

  \item FEA--FIB2MRIB: to propagate the FIB updates to the FIB2MRIB module.

  \item FIB2MRIB--RIB: to add/delete FIB-derived MRIB entries.

  \item StaticRoutes--RIB: to add/delete MRIB-specific static routes.

\end{itemize}

In the next subsections we describe those interactions.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Interaction between the FEA and MFEA modules}

The MFEA module needs to interact with the FEA module to obtain the
vif-related information, and to keep track if there is any change.
If there is any change in the vif information, the MFEA saves that
information locally and propagates it to the modules that have
registered interest with the MFEA (\eg MLD/IGMP and PIM-SM).

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Interaction between the MFEA and PIM modules}

PIM-SM needs to interact with the MFEA module for the following:

\begin{itemize}

  \item Send PIM control packets to other PIM routers, and receive PIM
  control packets from them.

  \item Start/stop the multicast forwarding engine.

  \item Add/delete multicast interface in the multicast forwarding
  engine.

  \item Add/delete multicast forwarding entry in the multicast
  forwarding engine.

  \item Receive PIM-related signals from the multicast forwarding engine
  (when applicable). 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 Receive bandwidth-related information about multicast data
  flows: \eg whether a data flow is idle, or whether the bandwidth of a
  data flow is above a pre-defined threshold (needed by PIM-SM to perform
  bandwidth-based Shortest-Path switch toward a source).

  \item Join/leave a multicast group.

  \item Obtain information about existing interfaces on a router.

\end{itemize}

On startup, the PIM module registers with the MFEA. As part of this
registration, the MFEA sends information about existing
interfaces on the system, and the current unicast forwarding
information. If any of this information changes later, the MFEA sends
the appropriate update to PIM. In addition, the MFEA creates the
appropriate state to send and receive PIM control packets. After the
PIM module receives the network interface information, it instructs the
MFEA to start PIM operation on selected interfaces. After that the PIM
module can send and receive PIM control packets on those interfaces.
Also, it can send requests to the MFEA to add, delete or modify multicast
forwarding entries in the kernel.

Note that the default solution in case of UNIX PIM kernel
uses one more signal from the kernel to the user-level daemon:
{\emph WHOLEPKT} messages. Those messages are multicast packets that are
suppose to be encapsulated in a PIM-SM Register message and sent to the
RP. The encapsulation mechanism must know the RP address (in general,
per multicast group address), threfore to avoid putting the RP addresses in
the kernel (which would also change the traditional UNIX multicast API), the
default solution is to use user-level encapsulation.  To improve
performance, the PIM encapsulation should be done in the kernel, and
then we need a signaling mechanism between the kernel and the user
process managing the kernel multicast forwarding entries. That mechanism
would deal with installing the appropriate information needed by kernel-level
Register encapsulation. Currently (March 2007), only recent releases
of DragonFlyBSD, FreeBSD, NetBSD, and OpenBSD do support such
kernel-level encapsulation.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Interaction between the MFEA and MLD/IGMP modules}

MLD/IGMP needs to interact with the MFEA module for the following:

\begin{itemize}

  \item Send and receive MLD/IGMP control messages.

  \item Join/leave a multicast group.

  \item Obtain information about existing interfaces on a router.

\end{itemize}

On startup, the MLD/IGMP module registers with the MFEA. As part of this
registration, the MFEA sends information about existing
interfaces on the system. If
any of this information changes later, the MFEA sends the appropriate update
to MLD/IGMP. In addition, the MFEA creates the appropriate state to send and
receive MLD/IGMP control packets. After the MLD/IGMP module receives the
network interface information, it instructs the MFEA to start MLD/IGMP
operation on selected interfaces. After that the MLD/IGMP module can send and
receive MLD/IGMP control packets on those interfaces.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Interaction between the MLD/IGMP and PIM modules}

PIM-SM needs to interact with the MLD/IGMP module to receive multicast
membership information about local members. On startup, the PIM module
registers with the MLD/IGMP module by expressing interest in tracking
multicast membership on selected network interfaces. After that, if
the multicast membership on any of the selected interfaces changes, the
MLD/IGMP module informs the PIM module about the change: \eg ``add
membership for group 224.0.1.20 on interface vif0''.

Note that control packets used for multicast debugging such as MRINFO or
multicast traceroute use IGMP as the network protocol. Hence, if such
messages are received by the MLD/IGMP module, the appropriate
information should be sent to the PIM module. Currently (March 2007),
the handling of such messages is not implemented yet.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Interaction between the RIB and PIM modules}

The PIM module needs to interact with the RIB module to obtain the MRIB
information, and to keep track if there is any change.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Interaction between the FEA and FIB2MRIB modules}
\label{sec:fea-to-fib2mrib-interaction}

Typically, the MRIB information inside the RIB module will be populated by
entries from the unicast routing protocols running as part of a XORP
router. For example, if Multiprotocol BGP is running on the system, it can be
used to supply routes that are multicast-only; those routes then will be
stored in the MRIB. However, if a XORP router is used only for multicast
routing, and if there are no XORP unicast routing protocols to supply the MRIB
routes, then by default we would use the existing unicast forwarding
entries from the FIB in the underlying system. Those entries may have been
statically installed on system startup, or may be managed by a non-XORP
unicast routing implementation.

The FIB2MRIB module is used to receive the FIB updates from the FEA.
It also receives network interface related information from the FEA.
The FIB information is updated by the network interface related information,
(e.g., FIB entries that use disabled interfaces are withdrawn),
and the result is propagated as MRIB entries to the RIB module.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Interaction between the FIB2MRIB and the RIB modules}

See Section~\ref{sec:fea-to-fib2mrib-interaction}.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Interaction between the StaticRoutes and the RIB modules}

The StaticRoutes module is used to store and manipulate the static unicast and
multicast routes. A configured static route is added directly to the
StaticRoutes module. This information is updated by the network interface
related information obtained from the FEA (not shown on
Figure~\ref{fig:mcast_modules_interaction}). For example, static routes
that use disabled interfaces are withdrawn. The result is propagated
as URIB or MRIB entries to the RIB module.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%     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.

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

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

  \item July 8, 2004: Updated to match XORP release 1.0: added information
  about the FIB2MRIB and StaticRoutes modules.

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

  \item April 13, 2005: Updated the list of the OS-es that support
  kernel-level PIM Register encapsulation.
  Updated the version to 1.1, and the date.

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