+#### Expressing dynamism and failures ####
+
+Similar to hosts, it is possible to declare links whose state, bandwidth
+or latency changes over time (see Section \ref pf_host_dynamism for details).
+
+In the case of network links, the ``bandwidth`` and ``latency`` attributes are
+replaced by the ``bandwidth_file`` and ``latency_file`` attributes.
+The following XML snippet demonstrates how to use this feature in the platform
+file. The structure of the files "link1.bw" and "link1.lat" is shown below.
+
+\verbatim
+<link id="LINK1" state_file="link1.fail" bandwidth="80000000" latency=".0001" bandwidth_file="link1.bw" latency_file="link1.lat" />
+\endverbatim
+
+\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 ; 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: