connects host @c host_1 to host @c host_2. Additionally, as the @c symmetrical
attribute was not given, this route is presumed to be symmetrical.
-@subsection pb_baroex Basic Routing Example
-
-Let's say you have a zone named zone_Big that contains two other zones, zone_1
-and zone_2. If you want to make a host (h1) from zone_1 with another one
-(h2) from zone_2 then you'll have to proceed as follows:
-@li First, you have to ensure that a route is defined from h1 to the
- zone_1's exit gateway and from h2 to zone_2's exit gateway.
-@li Then, you'll have to define a route between zone_1 to zone_2. As those
- zone are both resources belonging to zone_Big, then it has to be done
- at zone_big level. To define such a route, you have to give the
- source zone (zone_1), the destination zone (zone_2), and their respective
- gateway (as the route is effectively defined between those two
- entry/exit points). Elements of this route can only be elements
- belonging to zone_Big, so links and routers in this route should be
- defined inside zone_Big. If you choose some shortest-path model,
- this route will be computed automatically.
-
-As said before, there are mainly 2 tags for routing:
-@li <b>zoneroute</b>: to define routes between two <b>zone</b>
-@li <b>route</b>: to define routes between two <b>host/router</b>
-
-As we are dealing with routes between zone, it means that those we'll
-have some definition at zone_Big level. Let consider zone_1 contains 1
-host, 1 link and one router and zone_2 3 hosts, 4 links and one router.
-There will be a central router, and a cross-like topology. At the end
-of the crosses arms, you'll find the 3 hosts and the router that will
-act as a gateway. We have to define routes inside those two zone. Let
-say that zone_1 contains full routes, and zone_2 contains some Floyd
-routing (as we don't want to bother with defining all routes). As
-we're using some shortest path algorithms to route into zone_2, we'll
-then have to define some <b>route</b> to gives some topological
-information to SimGrid. Here is a file doing it all:
-
-@verbatim
-<zone id="zone_Big" routing="Dijkstra">
- <zone id="zone_1" routing="Full">
- <host id="zone_1_host1" speed="1000000000"/>
- <link id="zone_1_link" bandwidth="1250000000" latency="5E-4"/>
- <router id="zone_1_gateway"/>
- <route src="zone_1_host1" dst="zone_1_gateway">
- <link_ctn id="zone_1_link"/>
- </route>
- </zone>
- <zone id="zone_2" routing="Floyd">
- <host id="zone_2_host1" speed="1000000000"/>
- <host id="zone_2_host2" speed="1000000000"/>
- <host id="zone_2_host3" speed="1000000000"/>
- <link id="zone_2_link1" bandwidth="1250000000" latency="5E-4"/>
- <link id="zone_2_link2" bandwidth="1250000000" latency="5E-4"/>
- <link id="zone_2_link3" bandwidth="1250000000" latency="5E-4"/>
- <link id="zone_2_link4" bandwidth="1250000000" latency="5E-4"/>
- <router id="central_router"/>
- <router id="zone_2_gateway"/>
- <!-- routes providing topological information -->
- <route src="central_router" dst="zone_2_host1"><link_ctn id="zone_2_link1"/></route>
- <route src="central_router" dst="zone_2_host2"><link_ctn id="zone_2_link2"/></route>
- <route src="central_router" dst="zone_2_host3"><link_ctn id="zone_2_link3"/></route>
- <route src="central_router" dst="zone_2_gateway"><link_ctn id="zone_2_link4"/></route>
- </zone>
- <link id="backbone" bandwidth="1250000000" latency="5E-4"/>
-
- <zoneroute src="zone_1" dst="zone_2"
- gw_src="zone_1_gateway"
- gw_dst="zone_2_gateway">
- <link_ctn id="backbone"/>
- </zoneroute>
-</zone>
-@endverbatim
-
@section pf_other Other tags
The following tags can be used inside a @<platform@> tag even if they are not
enclose your gateway, when you have zone included in your zone, within a
zone to define routes to it.
-@subsection pf_P2P_tags P2P or how to use coordinates
-SimGrid allows you to use some coordinated-based system, like vivaldi,
-to describe a platform. The main concept is that you have some peers
-that are located somewhere: this is the function of the
-<b>coordinates</b> of the @<peer@> or @<host@> tag. There's nothing
-complicated in using it, here is an example:
-
-@verbatim
-<?xml version='1.0'?>
-<!DOCTYPE platform SYSTEM "https://simgrid.org/simgrid.dtd">
-<platform version="4">
-
- <zone id="zone0" routing="Vivaldi">
- <host id="100030591" coordinates="25.5 9.4 1.4" speed="1.5Gf" />
- <host id="100036570" coordinates="-12.7 -9.9 2.1" speed="7.3Gf" />
- ...
- <host id="100429957" coordinates="17.5 6.7 18.8" speed="8.3Gf" />
- </zone>
-</platform>
-@endverbatim
-
-Coordinates are then used to calculate latency (in microseconds)
-between two hosts by calculating the distance between the two hosts
-coordinates with the following formula: distance( (x1, y1, z1), (x2,
-y2, z2) ) = euclidian( (x1,y1), (x2,y2) ) + abs(z1) + abs(z2)
-
-In other words, we take the euclidian distance on the two first
-dimensions, and then add the absolute values found on the third
-dimension. This may seem strange, but it was found to allow better
-approximations of the latency matrices (see the paper describing
-Vivaldi).
-
-Note that the previous example defines a routing directly between hosts but it could be also used to define a routing between zone.
-That is for example what is commonly done when using peers (see Section @ref pf_peer).
-@verbatim
-<?xml version='1.0'?>
-<!DOCTYPE platform SYSTEM "https://simgrid.org/simgrid.dtd">
-<platform version="4">
-
- <zone id="zone0" routing="Vivaldi">
- <peer id="peer-0" coordinates="173.0 96.8 0.1" speed="730Mf" bw_in="13.38MBps" bw_out="1.024MBps" lat="500us"/>
- <peer id="peer-1" coordinates="247.0 57.3 0.6" speed="730Mf" bw_in="13.38MBps" bw_out="1.024MBps" lat="500us" />
- <peer id="peer-2" coordinates="243.4 58.8 1.4" speed="730Mf" bw_in="13.38MBps" bw_out="1.024MBps" lat="500us" />
-</zone>
-</platform>
-@endverbatim
-In such a case though, we connect the zone created by the <b>peer</b> tag with the Vivaldi routing mechanism.
-This means that to route between zone1 and zone2, it will use the coordinates of router_zone1 and router_zone2.
-This is currently a convention and we may offer to change this convention in the DTD later if needed.
-You may have noted that conveniently, a peer named FOO defines a zone named FOO and a router named router_FOO, which is why it works seamlessly with the <b>peer</b> tag.
-
-
@subsection pf_routing_howto_choose_wisely Choosing wisely the routing model to use
