rfc9914v9.txt		rfc9914.txt
	skipping to change at line 426 ¶		skipping to change at line 426 ¶
	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 equals that of a recovery graph in the RAW architecture		[RFC9030] and equals that of a recovery graph in the RAW architecture
	[RAW-ARCH]. A Track is a networking graph that can be followed to		[RAW-ARCH]. A Track is a networking graph that can be followed to
	transport packets with equivalent treatment; as opposed to other		transport packets with equivalent treatment; as opposed 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 Replication, Elimination, and Ordering Functions
	(PAREO) operations.		(PREOF).
	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
	since the packets are forwarded East-West.		since the packets are forwarded East-West.
	North East North West		North East North West
	skipping to change at line 1845 ¶		skipping to change at line 1845 ¶
	the metrics and link statistics involved in the computation are also		the metrics and link statistics involved in the computation are also
	out of scope. The effectiveness of the route computation by the PCE		out of scope. The effectiveness of the route computation by the PCE
	depends on the quality of the metrics that are reported from the RPL		depends on the quality of the metrics that are reported from the RPL
	network. Which metrics are used and how they are reported are out of		network. Which metrics are used and how they are reported are out of
	scope, but the expectation is that they are mostly of a long-term,		scope, but the expectation is that they are mostly of a long-term,
	statistical nature and provide visibility on link throughput,		statistical nature and provide visibility on link throughput,
	latency, stability, and availability over relatively long periods.		latency, stability, and availability over relatively long periods.
	3.7.2.4. Providing for RAW		3.7.2.4. Providing for RAW
	The RAW architecture [RAW-ARCH] extends the definition of Track as		A recovery graph as in the RAW architecture [RAW-ARCH] can be
	being composed of forward directional segments and North-South		composed of forward East-West directional segments and North-South
	bidirectional segments to enable additional path diversity using		bidirectional segments to enable additional path diversity using
	Packet Replication, Elimination, and Ordering Functions (PREOF) over		PREOF to select the protection paths to be used for a given datagram.
	the available paths. This provides a dynamic balance between the		This provides a dynamic balance between the reliability and
	reliability and availability requirements of the flows and the need		availability requirements of the flows and the need to conserve
	to conserve energy and spectrum. This specification prepares for RAW		energy and spectrum. This specification prepares for RAW by setting
	by setting up the Tracks, but it only forms DODAGs, which are		up the Tracks, but it only forms DODAGs, which are composed of
	composed of aggregated end-to-end loose source-routed protection		aggregated end-to-end loose source-routed protection paths, joined by
	paths, joined by strict routed segments, all oriented forward.		strict routed segments, all oriented forward.
	The RAW architecture defines a data plane extension of the PCE called		The RAW architecture defines a data plane extension of the PCE called
	the Point of Local Repair (PLR) that adapts the use of the path		the Point of Local Repair (PLR) that adapts the use of the path
	redundancy within a Track to defeat the diverse causes of packet		redundancy within a Track to defeat the diverse causes of packet
	loss. The PLR controls the forwarding operation of the packets		loss. The PLR controls the forwarding operation of the packets
	within a Track. This specification can use but does not impose a PLR		within a Track. This specification can use but does not impose a PLR
	and does not provide the policies that would select which packets are		and does not provide the policies that would select which packets are
	routed through which path within a Track (in other words, how the PLR		routed through which path within a Track (in other words, how the PLR
	may use the path redundancy within the Track). By default, the use		may use the path redundancy within the Track). By default, the use
	of the available redundancy is limited to simple load balancing, and		of the available redundancy is limited to simple load balancing, and
	skipping to change at line 3049 ¶		skipping to change at line 3049 ¶
	The No-Path P-DAO is forwarded normally along the reverse list, even		The No-Path P-DAO is forwarded normally along the reverse list, even
	if the intermediate node does not find a segment state to clean up.		if the intermediate node does not find a segment state to clean up.
	This results in cleaning up the existing segment state, if any, as		This results in cleaning up the existing segment state, if any, as
	opposed to refreshing an existing one or installing a new one.		opposed to refreshing an existing one or installing a new one.
	6.6. Maintaining a Track		6.6. Maintaining a Track
	Repathing a Track segment or protection path may cause jitter and		Repathing a Track segment or protection path may cause jitter and
	packet misordering. For critical flows that require timely and/or		packet misordering. For critical flows that require timely and/or
	in-order delivery, it might be necessary to deploy the PAREO		in-order delivery, it might be necessary to deploy PREOF [RAW-ARCH]
	functions [RAW-ARCH] over a highly redundant Track. This		over a highly redundant Track. This specification allows the use of
	specification allows the use of more than one protection path for a		more than one protection path for a Track and 1+N packet redundancy.
	Track and 1+N packet redundancy.
	This section provides the steps to ensure that no packet is lost due		This section provides the steps to ensure that no packet is lost due
	to the operation itself. This is ensured by installing the new		to the operation itself. This is ensured by installing the new
	section from its last node to the first, so when an intermediate node		section from its last node to the first, so when an intermediate node
	installs a route along the new section, all the downstream nodes in		installs a route along the new section, all the downstream nodes in
	the section have already installed their own. The disabled section		the section have already installed their own. The disabled section
	is removed as well when the in-flight packets are forwarded along the		is removed as well when the in-flight packets are forwarded along the
	new section.		new section.
	6.6.1. Maintaining a Track Segment		6.6.1. Maintaining a Track Segment
	skipping to change at line 3866 ¶		skipping to change at line 3865 ¶
	The possible values are expressed as a 6-bit unsigned integer		The possible values are expressed as a 6-bit unsigned integer
	(0..63). The registration procedure is Standards Action [RFC8126].		(0..63). The registration procedure is Standards Action [RFC8126].
	The initial allocation is as indicated in Table 29:		The initial allocation is as indicated in Table 29:
	+=======+=======================+===========+		+=======+=======================+===========+
	| Value | Meaning | Reference |		| Value | Meaning | Reference |
	+=======+=======================+===========+		+=======+=======================+===========+
	| 0 | Unqualified Rejection | RFC 9914 |		| 0 | Unqualified Rejection | RFC 9914 |
	+-------+-----------------------+-----------+		+-------+-----------------------+-----------+
	| 1 | Transient Failure | RFC 9914 |		| 1 | Reserved | RFC 9914 |
	+-------+-----------------------+-----------+		+-------+-----------------------+-----------+
	| 2..63 | Unassigned | |		| 2..63 | Unassigned | |
	+-------+-----------------------+-----------+		+-------+-----------------------+-----------+
	Table 29: PDR-ACK Rejection Status Values		Table 29: PDR-ACK Rejection Status Values
	11.11. Registry for Via Information Options Flags		11.11. Registry for Via Information Options Flags
	IANA has created the "Via Information Options (VIO) Flags" registry		IANA has created the "Via Information Options (VIO) Flags" registry
	under the "Routing Protocol for Low Power and Lossy Networks (RPL)"		under the "Routing Protocol for Low Power and Lossy Networks (RPL)"
	skipping to change at line 3912 ¶		skipping to change at line 3911 ¶
	The registration procedure is Standards Action [RFC8126]. The		The registration procedure is Standards Action [RFC8126]. The
	initial allocation is as indicated in Table 30 (see more in		initial allocation is as indicated in Table 30 (see more in
	Figure 17):		Figure 17):
	+============+=========================================+===========+		+============+=========================================+===========+
	| Bit Number | Capability Description | Reference |		| Bit Number | Capability Description | Reference |
	+============+=========================================+===========+		+============+=========================================+===========+
	| 0 | 'S' flag: Sibling in same DODAG as self | RFC 9914 |		| 0 | 'S' flag: Sibling in same DODAG as self | RFC 9914 |
	+------------+-----------------------------------------+-----------+		+------------+-----------------------------------------+-----------+
			| 1 | 'B' flag: Connectivity to the sibling | RFC 9914 |
			| | is roughly symmetrical | |
			+------------+-----------------------------------------+-----------+
	| 1..4 | Unassigned | |		| 1..4 | Unassigned | |
	+------------+-----------------------------------------+-----------+		+------------+-----------------------------------------+-----------+
	Table 30: Initial SIO Flags		Table 30: Initial SIO Flags
	11.13. Destination Advertisement Object Flag		11.13. Destination Advertisement Object Flag
	IANA has updated the "Destination Advertisement Object (DAO) Flags"		IANA has updated the "Destination Advertisement Object (DAO) Flags"
	registry, created in Section 20.11 of [RPL], under the "Routing		registry, created in Section 20.11 of [RPL], under the "Routing
	Protocol for Low Power and Lossy Networks (RPL)" registry group		Protocol for Low Power and Lossy Networks (RPL)" registry group
End of changes. 6 change blocks.
	16 lines changed or deleted		18 lines changed or added
This html diff was produced by rfcdiff 1.48.