For more information on SimGrid's deployment features, please refer to the \ref deployment section.
-The platform description may be intricate. This documentation is all about how to write this file. First, the basic
-concepts are introduced. Then, advanced options are explained. Finally, some hints and tips on how to write a better
-platform description are given.
+The platform description may be intricate. This documentation is all
+about how to write this file. You should read about the
+@ref routing_basics "routing basic concepts" before proceeding. This page
+first contain a reference guide of the XML. Finally, it gives some hints and tips on how to write a better
+platform description.
\section pf_overview Some words about XML and DTD
provide backward compatibility.
\li The DTD contains definitions for both the platform description and deployment files used by SimGrid.
-\section pf_basics Basic concepts
-
-Nowadays, the Internet is composed of a bunch of independently managed
-networks. Within each of those networks, there are entry and exit
-points (most of the time, you can both enter and exit through the same
-point); this allows to leave the current network and reach other
-networks, possibly even in other locations. At the upper level, such a
-network is called <b>Autonomous System (AS)</b>, while at the lower
-level it is named sub-network, or LAN (local area network). They are
-indeed autonomous: routing is defined (within the limits of his
-network) by the administrator, and so, those networks can operate
-without a connection to other networks. So-called gateways allow you
-to go from one network to another, if such a (physical) connection
-exists. Every node in one network that can be directly reached (i.e.,
-without traversing other nodes) from another network is called a
-gateway. Each autonomous system consists of equipment such as cables
-(network links), routers and switches as well as computers.
-
-The structure of the SimGrid platform description relies exactly on
-the same concept as a real-life platform (see above). Every resource
-(computers, network equipment etc.) belongs to an AS, which can be
-defined by using the \<AS\> tag. Within an AS, the routing between its
-elements can be defined abitrarily. There are several modes for
-routing, and exactly one mode must be selected by specifying the
-routing attribute in the AS tag:
+\section pf_netzones Defining a netzone
+
+Here is a simplistic example, describing a netzone using the Full
+routing. Other supported values for the routing attribute can be
+found below, Section \ref pf_raf.
+
\verbatim
-<AS id="AS0" routing="Full">
+<AS id="netzone0" routing="Full">
\endverbatim
-\remark
- Other supported values for the routing attribute can be found below, Section
- \ref pf_raf.
-
There is also the ``<route>`` tag; this tag takes two attributes,
``src`` (source) and ``dst`` (destination). Both source and
destination must be valid identifiers for routers (these will be
\remark
More information and (code-)examples can be found in Section \ref pf_rm.
-An AS can also contain itself one or more AS; this allows you to model
+A netzone can also contain itself one or more netzone; this allows you to model
the hierarchy of your platform.
### Within each AS, the following types of resources exist:
java line of code:
@verbatim
-router_name = prefix + clusterId + _router + suffix;
+router_name = prefix + clusterId + "_router" + suffix;
@endverbatim
