| rfc9914v8.txt | rfc9914.txt | |||
|---|---|---|---|---|
| skipping to change at line 420 ¶ | skipping to change at line 420 ¶ | |||
| the Point-to-Point (P2P) traffic has to follow the same DODAG. | the Point-to-Point (P2P) traffic has to follow the same DODAG. | |||
| Following the DODAG, the RPL datapath passes via a common parent in | Following the DODAG, the RPL datapath passes via a common parent in | |||
| Storing Mode and via the Root in Non-Storing Mode. This typically | Storing Mode and via the Root in Non-Storing Mode. This typically | |||
| involves more hops and more latency than the minimum possible for a | involves more hops and more latency than the minimum possible for a | |||
| directional (i.e., forward) P2P path that an isotropic protocol would | directional (i.e., forward) P2P path that an isotropic protocol would | |||
| compute. We refer to this elongated path as stretched. | compute. We refer to this elongated path as stretched. | |||
| 2.4.5. Track | 2.4.5. Track | |||
| The concept of Track is inherited from the 6TiSCH architecture | The concept of Track is inherited from the 6TiSCH architecture | |||
| [RFC9030] and matches that of a protection path in the RAW | [RFC9030] and equals that of a recovery graph in the RAW architecture | |||
| architecture [RAW-ARCH]. A Track is a networking graph that can be | [RAW-ARCH]. A Track is a networking graph that can be followed to | |||
| followed to transport packets with equivalent treatment; as opposed | transport packets with equivalent treatment; as opposed to other | |||
| to other definitions of a path (see Section 1.3.3 of [INT-ARCH] and | definitions of a path (see Section 1.3.3 of [INT-ARCH] and | |||
| Section 3.1.1 of [RAW-ARCH], a Track is not necessarily linear. It | Section 3.1.1 of [RAW-ARCH], a Track is not necessarily linear. It | |||
| may contain multiple paths that may fork and rejoin and that may | may contain multiple paths that may fork and rejoin and that may | |||
| enable RAW Packet ARQ, Replication, Elimination, and Overhearing | enable RAW Packet ARQ, Replication, Elimination, and Overhearing | |||
| (PAREO) operations. | (PAREO) operations. | |||
| Figure 1 illustrates the mapping of the DODAG with the generic | Figure 1 illustrates the mapping of the DODAG with the generic | |||
| concept of a Track, with the DODAG Root acting as the ingress for the | concept of a Track, with the DODAG Root acting as the ingress for the | |||
| Track, and the mapping of protection paths and segments, i.e., only | Track, and the mapping of protection paths and segments, i.e., only | |||
| forward segments, meaning that they are directional and progressing | forward segments, meaning that they are directional and progressing | |||
| towards the destination. Note that East is represented on the left | towards the destination. Note that East is represented on the left | |||
| skipping to change at line 897 ¶ | skipping to change at line 897 ¶ | |||
| The requirement is to install additional routes in the RPL routers, | The requirement is to install additional routes in the RPL routers, | |||
| to reduce the stretch of some P2P routes and maintain the | to reduce the stretch of some P2P routes and maintain the | |||
| characteristics within a given Service Level Objective (SLO), e.g., | characteristics within a given Service Level Objective (SLO), e.g., | |||
| in terms of latency and/or reliability. | in terms of latency and/or reliability. | |||
| 3.4. On Tracks | 3.4. On Tracks | |||
| 3.4.1. Building Tracks with RPL | 3.4.1. Building Tracks with RPL | |||
| The concept of a Track was introduced in the 6TiSCH architecture | The concept of a Track was introduced in the 6TiSCH architecture | |||
| [RFC9030] as a collection of potential paths that leverage redundant | [RFC9030] as a collection of potential protection paths that leverage | |||
| forwarding solutions along the way. This can be a DODAG or a more | redundant forwarding solutions along the way. This can be a DODAG or | |||
| complex structure that is only partially acyclic (e.g., per packet). | a more complex structure that is only partially acyclic (e.g., per | |||
| packet). | ||||
| With this specification, a Track is shaped as a DODAG, and following | With this specification, a Track is shaped as a DODAG, and following | |||
| the directed edges leads to a Track ingress. Storing Mode P-DAO | the directed edges leads to a Track ingress. Storing Mode P-DAO | |||
| messages follow the direction of the edges to set up routes for | messages follow the direction of the edges to set up routes for | |||
| traffic that flows the other way, towards the Track egress(es). If | traffic that flows the other way, towards the Track egress(es). If | |||
| there is a single Track egress, then the Track is reversible so that | there is a single Track egress, then the Track is reversible so that | |||
| another DODAG may be formed by reversing the direction of each edge. | another DODAG may be formed by reversing the direction of each edge. | |||
| A node at the ingress of more than one segment in a Track may use one | A node at the ingress of more than one segment in a Track may use one | |||
| or more of these segments to forward a packet inside the Track. | or more of these segments to forward a packet inside the Track. | |||
| End of changes. 2 change blocks. | ||||
| 7 lines changed or deleted | 8 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. | ||||