+##### 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 ``\<host\>``, the link may also contain the ``<prop/>`` tag; see the host
+documentation (Section \ref pf_host) for an example.
+
+
+TODO
+
+\subsubsection pf_backbone <backbone/>
+
+\note
+ This tag is <b>only available</b> when the containing AS uses the "Cluster" 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
+Basically there are 3 different entities available in SimGrid that
+can be used to model storage:
+
+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: