draft-ietf-roll-efficient-npdao-16.txt   draft-ietf-roll-efficient-npdao-17.txt 
ROLL R. Jadhav, Ed. ROLL R. Jadhav, Ed.
Internet-Draft Huawei Internet-Draft Huawei
Intended status: Standards Track P. Thubert Intended status: Standards Track P. Thubert
Expires: March 8, 2020 Cisco Expires: May 1, 2020 Cisco
R. Sahoo R. Sahoo
Z. Cao Z. Cao
Huawei Huawei
September 5, 2019 October 29, 2019
Efficient Route Invalidation Efficient Route Invalidation
draft-ietf-roll-efficient-npdao-16 draft-ietf-roll-efficient-npdao-17
Abstract Abstract
This document explains the problems associated with the current use This document explains the problems associated with the current use
of NPDAO messaging and also discusses the requirements for an of NPDAO messaging and also discusses the requirements for an
optimized route invalidation messaging scheme. Further a new optimized route invalidation messaging scheme. Further a new
proactive route invalidation message called as "Destination Cleanup proactive route invalidation message called as "Destination Cleanup
Object" (DCO) is specified which fulfills requirements of an Object" (DCO) is specified which fulfills requirements of an
optimized route invalidation messaging. optimized route invalidation messaging.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 8, 2020. This Internet-Draft will expire on May 1, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 10, line 9 skipping to change at page 10, line 9
sender does not set the 'K' flag it is an indication that the sender sender does not set the 'K' flag it is an indication that the sender
does not expect a response, and the sender SHOULD NOT retry the DCO. does not expect a response, and the sender SHOULD NOT retry the DCO.
D: The 'D' flag indicates that the DODAGID field is present. This D: The 'D' flag indicates that the DODAGID field is present. This
flag MUST be set when a local RPLInstanceID is used. flag MUST be set when a local RPLInstanceID is used.
Flags: The 6 bits remaining unused in the Flags field are reserved Flags: The 6 bits remaining unused in the Flags field are reserved
for future use. These bits MUST be initialized to zero by the sender for future use. These bits MUST be initialized to zero by the sender
and MUST be ignored by the receiver. and MUST be ignored by the receiver.
RPL Status: The RPL Status as defined in section 6.5.1 of [RFC6550]. RPL Status: As defined in [RFC6550] and updated in
Indicative of the reason why the DCO happened, the RPL Status MUST [I-D.ietf-roll-unaware-leaves]. The root or common parent that
NOT be changed as the DCO is propagated down the route being generates a DCO is authoritative for setting the status information
invalidated. This value is informative and does not affect the and the information is unchanged as propagated down the DODAG. This
behavior of the receiver. In particular, unknown values are ignored document does not specify a differentiated action based on the RPL
by the receiver. Only Rejection Codes (values of 128 and above) are status.
expected in a DCO.
DCOSequence: 8-bit field incremented at each unique DCO message from DCOSequence: 8-bit field incremented at each unique DCO message from
a node and echoed in the DCO-ACK message. The initial DCOSequence a node and echoed in the DCO-ACK message. The initial DCOSequence
can be chosen randomly by the node. Section 4.4 explains the can be chosen randomly by the node. Section 4.4 explains the
handling of the DCOSequence. handling of the DCOSequence.
DODAGID (optional): 128-bit unsigned integer set by a DODAG root that DODAGID (optional): 128-bit unsigned integer set by a DODAG root that
uniquely identifies a DODAG. This field MUST be present when the 'D' uniquely identifies a DODAG. This field MUST be present when the 'D'
flag is set and MUST NOT be present if 'D' flag is not set. DODAGID flag is set and MUST NOT be present if 'D' flag is not set. DODAGID
is used when a local RPLInstanceID is in use, in order to identify is used when a local RPLInstanceID is in use, in order to identify
skipping to change at page 19, line 42 skipping to change at page 19, line 42
including DCO, DCO-ACK, do not have Security sections. Also note including DCO, DCO-ACK, do not have Security sections. Also note
that unsecured mode does not imply that all messages are sent that unsecured mode does not imply that all messages are sent
without any protection. without any protection.
2. Preinstalled: In this mode, RPL uses secure messages. Thus 2. Preinstalled: In this mode, RPL uses secure messages. Thus
secure versions of DCO, DCO-ACK MUST be used in this mode. secure versions of DCO, DCO-ACK MUST be used in this mode.
3. Authenticated: In this mode, RPL uses secure messages. Thus 3. Authenticated: In this mode, RPL uses secure messages. Thus
secure versions of DCO, DCO-ACK MUST be used in this mode. secure versions of DCO, DCO-ACK MUST be used in this mode.
8. Normative References 8. Normative References
[I-D.ietf-roll-unaware-leaves]
Thubert, P. and M. Richardson, "Routing for RPL Leaves",
draft-ietf-roll-unaware-leaves-04 (work in progress),
September 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
JP., and R. Alexander, "RPL: IPv6 Routing Protocol for JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks", RFC 6550, Low-Power and Lossy Networks", RFC 6550,
DOI 10.17487/RFC6550, March 2012, DOI 10.17487/RFC6550, March 2012,
 End of changes. 6 change blocks. 
11 lines changed or deleted 15 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/