rfc9009v8.txt | rfc9009.txt | |||
---|---|---|---|---|
skipping to change at line 324 ¶ | skipping to change at line 324 ¶ | |||
4.1. Change in RPL Route Invalidation Semantics | 4.1. Change in RPL Route Invalidation Semantics | |||
As described in Section 1.2, the NPDAO originates at the node | As described in Section 1.2, the NPDAO originates at the node | |||
changing to a new parent and traverses upstream towards the root. In | changing to a new parent and traverses upstream towards the root. In | |||
order to solve the problems discussed in Section 2, this document | order to solve the problems discussed in Section 2, this document | |||
adds a new proactive route invalidation message called the | adds a new proactive route invalidation message called the | |||
"Destination Cleanup Object" (DCO), which originates at a common | "Destination Cleanup Object" (DCO), which originates at a common | |||
ancestor node and flows downstream the old path. The common ancestor | ancestor node and flows downstream the old path. The common ancestor | |||
node generates a DCO when removing a next hop to a target -- for | node generates a DCO when removing a next hop to a target -- for | |||
instance, as a delayed response to receiving a regular DAO from | instance, as a delayed response to receiving a regular DAO from | |||
another child node with a newer Path Sequence for the target that is | another child node with a Path Sequence for the target that is the | |||
the same or newer, in which case the DCO transmission is canceled. | same or newer, in which case the DCO transmission is canceled. | |||
The 6LRs in the path for the DCO take such action as route | The 6LRs in the path for the DCO take such action as route | |||
invalidation based on the DCO information and subsequently send | invalidation based on the DCO information and subsequently send | |||
another DCO with the same information downstream to the next hop(s). | another DCO with the same information downstream to the next hop(s). | |||
This operation is similar to how the DAOs are handled on intermediate | This operation is similar to how the DAOs are handled on intermediate | |||
6LRs in the Storing MOP [RFC6550]. Just like the DAO in the Storing | 6LRs in the Storing MOP [RFC6550]. Just like the DAO in the Storing | |||
MOP, the DCO is sent using link-local unicast source and destination | MOP, the DCO is sent using link-local unicast source and destination | |||
IPv6 addresses. Unlike the DAO, which always travels upstream, the | IPv6 addresses. Unlike the DAO, which always travels upstream, the | |||
DCO always travels downstream. | DCO always travels downstream. | |||
skipping to change at line 518 ¶ | skipping to change at line 518 ¶ | |||
DCO MUST use the value of the Path Sequence as found in the newest | DCO MUST use the value of the Path Sequence as found in the newest | |||
Transit Information option that was received for that target by the | Transit Information option that was received for that target by the | |||
common parent. If a 6LR down the path receives a DCO with a Path | common parent. If a 6LR down the path receives a DCO with a Path | |||
Sequence that is not newer than the Path Sequence as known from a | Sequence that is not newer than the Path Sequence as known from a | |||
Transit Information option in a DAO message, then the 6LR MUST NOT | Transit Information option in a DAO message, then the 6LR MUST NOT | |||
remove its current routing state, and it MUST NOT forward the DCO | remove its current routing state, and it MUST NOT forward the DCO | |||
down a path where it is not newer. If the DCO is newer, the 6LR may | down a path where it is not newer. If the DCO is newer, the 6LR may | |||
retain a temporary state to ensure that a DAO that is received later | retain a temporary state to ensure that a DAO that is received later | |||
with a Transit Information option with an older sequence number is | with a Transit Information option with an older sequence number is | |||
ignored. A Transit Information option in a DAO message that is as | ignored. A Transit Information option in a DAO message that is as | |||
new or newer than that in a DCO wins, meaning that the path indicated | new as or newer than that in a DCO wins, meaning that the path | |||
in the DAO is installed and the DAO is propagated. When the DCO is | indicated in the DAO is installed and the DAO is propagated. When | |||
propagated upon a DCO from an upstream parent, the Path Sequence MUST | the DCO is propagated upon a DCO from an upstream parent, the Path | |||
be copied from the received DCO. | Sequence MUST be copied from the received DCO. | |||
4.3.4. Destination Cleanup Option Acknowledgment (DCO-ACK) | 4.3.4. Destination Cleanup Option Acknowledgment (DCO-ACK) | |||
The DCO-ACK message SHOULD be sent as a unicast packet by a DCO | The DCO-ACK message SHOULD be sent as a unicast packet by a DCO | |||
recipient in response to a unicast DCO message with the 'K' flag set. | recipient in response to a unicast DCO message with the 'K' flag set. | |||
If the 'K' flag is not set, then the receiver of the DCO message MAY | If the 'K' flag is not set, then the receiver of the DCO message MAY | |||
send a DCO-ACK, especially to report an error condition. The format | send a DCO-ACK, especially to report an error condition. The format | |||
of the DCO-ACK message is shown in Figure 4. | of the DCO-ACK message is shown in Figure 4. | |||
0 1 2 3 | 0 1 2 3 | |||
skipping to change at line 603 ¶ | skipping to change at line 603 ¶ | |||
3. A node MAY set the 'K' flag in a unicast DCO message to solicit a | 3. A node MAY set the 'K' flag in a unicast DCO message to solicit a | |||
unicast DCO-ACK in response, in order to confirm the attempt. | unicast DCO-ACK in response, in order to confirm the attempt. | |||
4. A node receiving a unicast DCO message with the 'K' flag set | 4. A node receiving a unicast DCO message with the 'K' flag set | |||
SHOULD respond with a DCO-ACK. A node receiving a DCO message | SHOULD respond with a DCO-ACK. A node receiving a DCO message | |||
without the 'K' flag set MAY respond with a DCO-ACK, especially | without the 'K' flag set MAY respond with a DCO-ACK, especially | |||
to report an error condition. | to report an error condition. | |||
5. A node receiving a unicast DCO message MUST verify the stored | 5. A node receiving a unicast DCO message MUST verify the stored | |||
Path Sequence in context to the given target. If the stored Path | Path Sequence in context to the given target. If the stored Path | |||
Sequence is more fresh, i.e., as new as or newer than the Path | Sequence is as new as or newer than the Path Sequence received in | |||
Sequence received in the DCO, then the DCO MUST be dropped. | the DCO, then the DCO MUST be dropped. | |||
6. A node that sets the 'K' flag in a unicast DCO message but does | 6. A node that sets the 'K' flag in a unicast DCO message but does | |||
not receive a DCO-ACK in response MAY reschedule the DCO message | not receive a DCO-ACK in response MAY reschedule the DCO message | |||
transmission for another attempt, up until an implementation- | transmission for another attempt, up until an implementation- | |||
specific number of retries. | specific number of retries. | |||
7. A node receiving a unicast DCO message with its own address in | 7. A node receiving a unicast DCO message with its own address in | |||
the RPL Target option MUST strip off that Target option. If this | the RPL Target option MUST strip off that Target option. If this | |||
Target option is the only one in the DCO message, then the DCO | Target option is the only one in the DCO message, then the DCO | |||
message MUST be dropped. | message MUST be dropped. | |||
End of changes. 3 change blocks. | ||||
8 lines changed or deleted | 8 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |