=============
SimGrid can compute automatically the paths between all pair of hosts in a zone. You just need to provide the one-hop routes to connect all hosts.
-Two algorithms are provided:
+Several algorithms are provided:
- ``routing=Floyd``: use the number of hops to build shortest path. It is calculated only once at the beginning of the
simulation.
- - ``routing=Dijksta``: shortest-path calculated considering the path's latency. As the latency of links can change
+ - ``routing=Dijkstra``: shortest-path calculated considering the path's latency. As the latency of links can change
during simulation, it is recomputed each time a route is necessary.
- ``routing=DijkstraCache``: Just like the regular Dijkstra, but with a cache of previously computed paths for performance.
The documentation of each cluster kinds is given as :ref:`platform_examples`.
+.. _pf_rm_vivaldi:
+
Vivaldi
=======
Such Network Coordinate systems were shown to provide rather good latency estimations in a compact way. Other systems,
such as `Phoenix network coordinates <https://en.wikipedia.org/wiki/Phoenix_network_coordinates>`_ were shown
superior to the Vivaldi system and could be also implemented in SimGrid.
-
+
Here is a small platform example:
.. code-block:: XML
Wi-Fi
=====
-TODO
+Please see :ref:`models_wifi`.
ns-3
====
-When using :ref:`model_ns3`, SimGrid does not uses its own platform or routing models. Your platform must be limited to one
-zone only, and any routing model will be ignored. Since ns-3 uses a shortest path algorithm on its side, all routes must be
-of length 1.
+When using :ref:`models_ns3`, SimGrid configures the ns-3 simulator according to the configured platform.
+Since ns-3 uses a shortest path algorithm on its side, all routes must be of length 1.
.. _pf_routes:
``gw_src`` (source gateway) and ``gw_dst`` (destination gateway) along with the list of links. Afterward, the path from
``src_host`` in zone ``src`` to ``dst_host`` in zone ``dst`` is composed of 3 segments. First, move within zone ``src`` from
``src_host`` to the specified gateway ``gw_src``. Then, traverse all links specified by the zoneRoute (purportedly within
-the common ancestor) and finally, move within zone ``dst`` from ``gw_dst`` to ``dst_host``.
+the common ancestor) and finally, move within zone ``dst`` from ``gw_dst`` to ``dst_host``.
SimGrid enforces that each gateway is within its zone, either directly or in a sub-zone to ensure that the algorithm
described in the next section actually works.
.. code-block:: XML
- <zoneRoute src="AS2" dst="AS5" gw_src="Host1" gw_dst"="gw1">
- <link_ctn id="Link1">
- </zoneRoute>
+ <zoneRoute src="AS2" dst="AS5" gw_src="Host1" gw_dst="gw1">
+ <link_ctn id="Link1"/>
+ </zoneRoute>
2. **Add the route up to the ancestor**, i.e. from ``src`` to the ``gw_src`` in the route between ancestor zones. This is a recursive call to the current algorithm.
.. code-block:: XML
- <zoneRoute src="AS5-4" dst="AS5-3" gw_src="gw2" gw_dst"="gw1">
- <link_ctn id="Link3">
- </zoneRoute>
+ <zoneRoute src="AS5-4" dst="AS5-3" gw_src="gw2" gw_dst="gw1">
+ <link_ctn id="Link3"/>
+ </zoneRoute>
So to compute the route from *gw1* to *Host2*, we need to add:
<link_ctn id="Link2">
</route>
-In the end, our communication from *Host1@AS2* to *Host2@AS5-4* follows this path: ``{Link1, Link3, Link2}``
+In the end, our communication from *Host1@AS2* to *Host2@AS5-4* follows this path: ``{Link1, Link3, Link2}``
It is possbile to use :ref:`pf_tag_bypassZoneRoute` to provide a path between two zones that are not necessarily sibilings.
If such routes exist, SimGrid will try to match each of the ancestor zones of the source with each of the ancestor zone of
the destination, looking for such a bypass to use intead of the common ancestor.
+.. _pf_loopback:
+
Loopback links
**************
</route>
Some zones such as :ref:`pf_tag_cluster` provide ways to describe the characteristics of
-the loopback nodes inside the zone.
+the loopback nodes inside the zone.
.. |br| raw:: html
