+\note
+ Even if the syntax is the same, the semantic of bandwidth and latency
+ trace files differs from that of host availability files. For bandwidth and
+ latency, the corresponding files do not
+ express availability as a fraction of the available capacity but directly in
+ bytes per seconds for the bandwidth and in seconds for the latency. This is
+ because most tools allowing to capture traces on real platforms (such as NWS)
+ express their results this way.
+
+##### Example of "link1.bw" file #####
+
+~~~{.py}
+PERIODICITY 12.0
+4.0 40000000
+8.0 60000000
+~~~
+
+In this example, the bandwidth changes repeatedly, with all changes
+being repeated every 12 seconds.
+
+At the beginning of the the simulation, the link's bandwidth is 80,000,000
+B/s (i.e., 80 Mb/s); this value was defined in the XML snippet above.
+After four seconds, it drops to 40 Mb/s (line 2), and climbs
+back to 60 Mb/s after another 4 seconds (line 3). The value does not change any
+more until the end of the period, that is, after 12 seconds have been simulated).
+At this point, periodicity kicks in and this behavior is repeated: Seconds
+12-16 will experience 80 Mb/s, 16-20 40 Mb/s etc.).
+
+##### Example of "link1.lat" file #####
+
+~~~{.py}
+PERIODICITY 5.0
+1.0 0.001
+2.0 0.01
+3.0 0.001
+~~~
+
+In this example, the latency varies with a period of 5 seconds.
+In the xml snippet above, the latency is initialized to be 0.0001s (100µs). This
+value will be kept during the first second, since the latency_file contains
+changes to this value at second one, two and three.
+At second one, the value will be 0.001, i.e., 1ms. One second later it will
+be adjusted to 0.01 (or 10ms) and one second later it will be set again to 1ms. The
+value will not change until second 5, when the periodicity defined in line 1
+kicks in. It then loops back, starting at 100µs (the initial value) for one second.
+
+
+#### The ``<prop/>`` tag ####
+
+Similar to the ``<host>`` tag, a link may also contain the ``<prop/>`` tag; see the host
+documentation (Section \ref pf_host) for an example.
+
+
+\subsubsection pf_backbone <backbone/>
+
+\note
+ This tag is <b>only available</b> when the containing AS uses the "Cluster" routing mode!
+
+Using this tag, you can designate an already existing link to be a backbone.
+
+Attribute name | Mandatory | Values | Description
+--------------- | --------- | ------ | -----------
+id | yes | string | Name of the link that is supposed to act as a backbone.
+
+\subsection pf_storage Storage
+
+\note
+ This is a prototype version that should evolve quickly, hence this
+ is just some doc valuable only at the time of writing.
+ This section describes the storage management under SimGrid ; nowadays
+ it's only usable with MSG. It relies basically on linux-like concepts.
+ You also may want to have a look to its corresponding section in \ref
+ msg_file_management ; access functions are organized as a POSIX-like
+ interface.
+
+\subsubsection pf_sto_conc Storage - Main Concepts
+
+The storage facilities implemented in SimGrid help to model (and account for)
+storage devices, such as tapes, hard-drives, CD or DVD devices etc.
+A typical situation is depicted in the figure below:
+
+\image html ./webcruft/storage_sample_scenario.png
+\image latex ./webcruft/storage_sample_scenario.png "storage_sample_scenario" width=\textwidth
+
+In this figure, two hosts called Bob and Alice are interconnected via a network
+and each host is physically attached to a disk; it is not only possible for each host to
+mount the disk they are attached to directly, but they can also mount disks
+that are in a remote location. In this example, Bob mounts Alice's disk remotely
+and accesses the storage via the network.
+
+SimGrid provides 3 different entities that can be used to model setups
+that include storage facilities:
+
+Entity name | Description
+--------------- | -----------
+\ref pf_storage_entity_storage_type "storage_type" | Defines a template for a particular kind of storage (such as a hard-drive) and specifies important features of the storage, such as capacity, performance (read/write), contents, ... Different models of hard-drives use different storage_types (because the difference between an SSD and an HDD does matter), as they differ in some specifications (e.g., different sizes or read/write performance).
+\ref pf_storage_entity_storage "storage" | Defines an actual instance of a storage type (disk, RAM, ...); uses a ``storage_type`` template (see line above) so that you don't need to re-specify the same details over and over again.
+\ref pf_storage_entity_mount "mount" | Must be wrapped by a \ref pf_host tag; declares which storage(s) this host has mounted and where (i.e., the mountpoint).
+
+
+\anchor pf_storage_content_file
+### %Storage Content File ###
+
+In order to assess exactly how much time is spent reading from the storage,
+SimGrid needs to know what is stored on the storage device (identified by distinct (file-)name, like in a file system)
+and what size this content has.
+
+\note
+ The content file is never changed by the simulation; it is parsed once
+ per simulation and kept in memory afterwards. When the content of the
+ storage changes, only the internal SimGrid data structures change.
+
+\anchor pf_storage_content_file_structure
+#### Structure of a %Storage Content File ####
+
+Here is an excerpt from two storage content file; if you want to see the whole file, check
+the file ``examples/platforms/content/storage_content.txt`` that comes with the
+SimGrid source code.
+
+SimGrid essentially supports two different formats: UNIX-style filepaths should
+follow the well known format: