=============
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.
-Several 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.
=======
This routing model is particularly well adapted to Peer-to-Peer and Clouds platforms: each component is connected to the
-cloud through a private link of which the upload and download rate may be asymmetric.
+cloud through a private link whose upload and download rates may be asymmetric.
-The network core (between the private links) is assumed to be over-sized so only the latency is taken into account.
-Instead of a matrix of latencies that would become too large when the amount of peers grows, Vivaldi netzones give a
-coordinate to each peer and compute the latency between host A=(xA,yA,zA) and host B=(xB,yB,zB) as follows:
+The network core (between the private links) is assumed to be over-provisioned so that only the latency has to be
+taken into account. Instead of a matrix of latencies that would become too large when the amount of peers grows,
+Vivaldi netzones give a coordinate to each peer and compute the latency between host A=(xA,yA,zA) and host B=(xB,yB,zB)
+as follows:
latency = sqrt( (xA-xB)² + (yA-yB)² ) + zA + zB
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">
+ <zoneRoute src="AS2" dst="AS5" gw_src="Host1" gw_dst="gw1">
<link_ctn id="Link1"/>
</zoneRoute>
Here, we need the route from *gw1* and *host2*. The common ancestor is *AS5*, and the relative ancestors are *AS5-4* and *AS5-3*. This route is defined as follows (routes are symmetrical by default).
.. code-block:: XML
-
- <zoneRoute src="AS5-4" dst="AS5-3" gw_src="gw2" gw_dst"="gw1">
+
+ <zoneRoute src="AS5-4" dst="AS5-3" gw_src="gw2" gw_dst="gw1">
<link_ctn id="Link3"/>
</zoneRoute>
<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
