Skip to content

Commit

Permalink
Merge pull request #10 from roll-wg/mcr-editorial
Browse files Browse the repository at this point in the history 
suggested edits and typos from mcr
  • Loading branch information
@pthubert
pthubert committed Nov 18, 2021
2 parents cc892a9 + 9ef489d commit c8abd74
Showing 1 changed file with 38 additions and 30 deletions.
68 changes: 38 additions & 30 deletions draft-ietf-roll-dao-projection.xml
View file
Expand Up @@ -237,7 +237,7 @@ docName="draft-ietf-roll-dao-projection-22" >
<dt>Track:</dt><dd>
<t>A networking graph that can be followed to transport packets with
equivalent treatment; as opposed to the definition of a path above,
a Track Track is not necessarily linear. It may contain multiple paths that
a Track is not necessarily linear. It may contain multiple paths that
may fork and rejoin, and may enable the RAW Packet ARQ, Replication,
Elimination, and Overhearing (PAREO) operations.
</t>
Expand All @@ -252,7 +252,7 @@ docName="draft-ietf-roll-dao-projection-22" >
</t>
</dd>
<dt>TrackID:</dt><dd>
A RPL Local InstanceID that identifies a Track using the namespace owned ny
A RPL Local InstanceID that identifies a Track using the namespace owned by
the Track Ingress. The TrackID is associated with the IPv6 Address of the
Track Ingress that is used as DODAGID, and together they form a unique
identification of the Track
Expand Down Expand Up @@ -314,7 +314,7 @@ docName="draft-ietf-roll-dao-projection-22" >
function allows to adapt the activity of the routing protocol to the use
case, e.g., type, speed, and quality of the LLN links.
</t><t>
RPL instances operate as ships in the night, unbeknownst of one another.
RPL instances operate as ships passing in the night, unbeknownst of one another.
The RPL Root is responsible to select the RPL Instance that is used
to forward a packet coming from the Backbone into the RPL domain and set
the related RPL information in the packets. 6TiSCH leverages RPL for its
Expand Down Expand Up @@ -345,7 +345,7 @@ docName="draft-ietf-roll-dao-projection-22" >
routes together coalesce as a Directed Acyclic Graph upwards.
RPL then constructs routes to so-called Targets in the reverse direction,
down the same DODAG. So do so, a RPL Instance can be operated either in RPL
Storing or Non-Storing Mode of Operation (MOP)
Storing or Non-Storing Mode of Operation (MOP).
The default route towards the Root is maintained aggressively and may change while a packet progresses without causing loops, so the packet will still reach the Root.
</t>
<t>In Non-Storing Mode, each node advertises itself as a Target directly to the
Expand All @@ -369,7 +369,7 @@ docName="draft-ietf-roll-dao-projection-22" >
</t>

<t>
Either way, the RPL routes are injected by the Target nodes, in a distributed fashion. To complement RPL and eliminate routing stretch, this specification introduces an hybrid mode that combines Storing and Non-Storing operations to build and project routes onto the nodes where they should be installed. This specification uses the term P-Route to refer to those routes.
Either way, the RPL routes are injected by the Target nodes, in a distributed fashion. To complement RPL and eliminate routing stretch, this specification introduces an hybrid mode that combines Storing and Non-Storing operations to build and project routes onto the nodes where they should be installed. This specification uses the term Projected Route (P-Route) to refer to those routes.
</t>
<t>
A P-Route may be installed in either Storing and Non-Storing Mode,
Expand Down Expand Up @@ -426,19 +426,20 @@ docName="draft-ietf-roll-dao-projection-22" >
</t>
<t>
It results that the Root, or then some associated centralized computation
engine such as a PCE, can determine the amount of packets that reach a
destination in the
RPL domain, and thus the amount of energy and bandwidth that is wasted for
engine such as a PCE, can determine the number of packets that reach a
destination in the RPL domain.
Based upon this metric the amount of energy and bandwidth that is wasted on
transmission, between itself and the destination, as well as the risk of
fragmentation, any potential delays because of a paths longer than
necessary (shorter paths exist that would not traverse the Root).
</t>
<t>
As a network gets deep, the size of the source routing header that the
Root must add to all the downward packets becomes an issue for nodes that
are many hops away. In some use cases, a RPL network forms long lines and
a limited amount of well-targeted routing state would allow to make the
source routing operation loose as opposed to strict, and save packet size.
The RPL root must add a source routing header to all downward packets.
As a network gets deep, the size of this header becomes an issue for nodes that
are many hops away.
In some use cases, a RPL network forms long lines and
a limited amount of well-targeted routing state would allow the
source routing operation to be loose as opposed to strict, and save packet size.
Limiting the packet size is directly beneficial to the energy budget, but,
mostly, it reduces the chances of frame loss and/or packet fragmentation,
which is highly detrimental to the LLN operation. Because the capability
Expand All @@ -460,10 +461,10 @@ docName="draft-ietf-roll-dao-projection-22" >
<section><name>East-West Routes</name>

<t>
RPL is optimized for INternet access, with Point-to-Multipoint (P2MP) and
Multipoint-to-Point (MP2P), whereby routes are always installed
North-South (aka up/down) along the RPL DODAG respectively from and
towards the Border Router that also serves as DODAG Root.
When RPL is optimized for Internet access, with Point-to-Multipoint (P2MP) and
Multipoint-to-Point (MP2P), routes are installed
North-South (aka up/down) along the RPL DODAG.
Traffic flows from and towards the Border Router that also serves as DODAG Root.
Peer to Peer (P2P) East-West routes in a RPL network will generally
suffer from some elongated (stretched) path versus a direct (optimized)
path, since routing between two nodes always happens via a common
Expand All @@ -488,7 +489,7 @@ docName="draft-ietf-roll-dao-projection-22" >
LLN
</artwork>
</figure>
<t>The amount of stretch depends on the Mode of Operation: </t>
<t>As described in <xref target="RFC9008" />, the amount of stretch depends on the Mode of Operation: </t>
<ul spacing='normal'>
<li> in Non-Storing Mode, all packets
routed within the DODAG flow all the way up to the Root of the DODAG. If
Expand Down Expand Up @@ -556,7 +557,7 @@ docName="draft-ietf-roll-dao-projection-22" >
</t>
<t>
A Serial Track comprises provides only one path between Ingress and Egress.
It comprises at most one Leg. A Stand-Alone Segment defines implicitly a
It comprises at most one Leg. A Stand-Alone Segment implicitly defines a
Serial Track from its Ingress to Egress.
</t>

Expand All @@ -570,7 +571,7 @@ docName="draft-ietf-roll-dao-projection-22" >
The concept of a Track was introduced in the <xref target='RFC9030'>
"6TiSCH Architecture"</xref>, as a collection of potential paths that
leverage redundant forwarding solutions along the way.
With this specification, a Track forms DODAG that is directed towards a Track Ingress. If there is a single Track Egress,
With this specification, a Track forms a DODAG that is directed towards a Track Ingress. If there is a single Track Egress,
then the Track is reversible to form another DODAG by reversing the
direction of each edge. A node at the Ingress of more
than one Segment in a Track may use one or more of these Segments to forward
Expand Down Expand Up @@ -610,7 +611,8 @@ docName="draft-ietf-roll-dao-projection-22" >
<t>
A P-DAO message for a Track signals the TrackID in the RPLInstanceID field.
In the case of a local RPL Instance, the address of the Track Ingress is
used as source to encapsulated packets along the Track is signaled in the
used as source to encapsulate packets along the Track.
The Track is signaled in the
DODAGID field of the Projected DAO Base Object,
see <xref target='p-dao-fmt'/>.
</t><t>
Expand Down Expand Up @@ -643,7 +645,7 @@ A ===&gt; B ===&gt; C ===&gt; D===&gt; E &lt;
<t>
Conventionally we use ==&gt; to represent a strict hop and --&gt; for a
loose hop.
We use -to- like in C==&gt;D==&gt;E-to-F to represent coma-separated
We use "-to-", such as in C==&gt;D==&gt;E-to-F to represent coma-separated
Targets, e.g., F is a Target for Segment C==&gt;D==&gt;E.
In this example, A is Track Ingress, E is Track Egress. C is a stitching
point. F and G are "external” Targets for the Track, and become reachable
Expand Down Expand Up @@ -1885,10 +1887,16 @@ C encapsulates the packet with destination of E in the Track signaled by P-DAO 1
<section anchor='concepts'><name>Complex Tracks</name>

<t>To increase the reliability of the P2P transmission, this specification
enables to build a collection of Legs between the same Ingress and Egress Nodes and combine them with the same TrackID, as shown in <xref target="FigLegs"/>. Legs may cross at loose hops edges or remain parallel.
enables to build a collection of Legs between the same Ingress and Egress
Nodes and combine them with the same TrackID, as shown in <xref
target="FigLegs"/>.
Legs may cross at the edges of loose hops or remain parallel.
</t><t>
The Segments that join the loose hops of a Leg are installed with the same TrackID as the Leg. But each individual Leg and Segment has its own
P-RouteID which allows to manage it separately. When Legs cross within
The Segments that join the loose hops of a Leg are installed with the same
TrackID as the Leg.
But each individual Leg and Segment has its own P-RouteID which allows it to
be managed separately.
When Legs cross within
respsective Segment, the next loose hop (the current destination of the
packet) indicates which Leg is being followed and a Segment that can reach
that next loose hop is selected.
Expand Down Expand Up @@ -2049,7 +2057,7 @@ Ingress Segment 5 Egress - Tgt 2
<t>
This specification extends RPL <xref target='RFC6550'/> to enable the Root
to install East-West routes inside a Main DODAG that is operated as
non-Storing Mode. A Projected DAO (P-DAO) message (see <xref target='extP-DAO'/>) contains a new Via Information Option that installs a strict
Non-Storing Mode. A Projected DAO (P-DAO) message (see <xref target='extP-DAO'/>) contains a new Via Information Option that installs a strict
or a loose sequence of hops to form respectively a Track Segment or a
Track Leg.
A new P-DAO Request (PDR) message (see <xref target='P-DAOreq'/>)
Expand Down Expand Up @@ -3128,7 +3136,7 @@ Ingress Segment 5 Egress - Tgt 2
Track Segments and Legs that compose it one by one.
</t>
<t>
Since the state about a Leg of a Track is located only the Ingress Node,
Since the state about a Leg of a Track is located only on the Ingress Node,
the Root cleans up the Leg by sending an NSM-VIO to the Ingress indicating
the TrackID and the P-RouteID of the Leg being removed, a Segment Lifetime
of 0 and a newer Segment Sequence. The SRH-6LoRH with the Via Addresses in
Expand Down Expand Up @@ -3199,7 +3207,7 @@ Ingress Segment 5 Egress - Tgt 2

<section anchor='maintainT'><name>Maintaining a Track Leg</name>

<t>This specification allows to add Legs to a Track by sending
<t>This specification allows the Root to add Legs to a Track by sending
a Non-Storing Mode P-DAO to the Ingress associated to the same TrackID,
and a new Segment ID. If the Leg is loose, then the Segments that join
the hops must be created first. It makes
Expand All @@ -3209,7 +3217,7 @@ Ingress Segment 5 Egress - Tgt 2
<t>
It is also possible to update a Track Leg by sending a Non-Storing Mode
P-DAO to the Ingress with the same Segment ID, an incremented Segment
Sequence, and the new complete listy of hops in the NSM-VIO.
Sequence, and the new complete list of hops in the NSM-VIO.
Updating a live Leg means changing one or more of the intermediate loose
hops, and involves laying out new Segments from and to the new loose hops
before the NSM-VIO for the new Leg is issued.
Expand Down Expand Up @@ -3586,7 +3594,7 @@ Ingress Segment 5 Egress - Tgt 2
<t>
But the RPL routing information headers may not be supported on all type of
routed network infrastructures, especially not in high-speed routers.
When the RPI is not be supported in the dataplane, there cannot be local RPL
When the RPI is not supported in the dataplane, there cannot be local RPL
Instances and RPL can only operate as a single topology (the Main DODAG).
The RPL Instance is that of the Main DODAG and the Ingress node that encapsulates is not the Root.
The routes along the Tracks are alternate routes to those available along
Expand Down

0 comments on commit c8abd74

Please sign in to comment.