draft-ietf-roll-mopex-01.txt   draft-ietf-roll-mopex-02.txt 
ROLL R. Jadhav, Ed. ROLL R. Jadhav, Ed.
Internet-Draft Huawei Tech Internet-Draft Huawei Tech
Intended status: Standards Track P. Thubert Intended status: Standards Track P. Thubert
Expires: December 7, 2020 Cisco Expires: April 2, 2021 Cisco
M. Richardson M. Richardson
Sandelman Software Works Sandelman Software Works
June 5, 2020 September 29, 2020
Mode of Operation extension Mode of Operation extension
draft-ietf-roll-mopex-01 draft-ietf-roll-mopex-02
Abstract Abstract
RPL allows different mode of operations which allows nodes to have a RPL allows different mode of operations which allows nodes to have a
consensus on the basic primitives that must be supported to join the consensus on the basic primitives that must be supported to join the
network. The MOP field in [RFC6550] is of 3 bits and is fast network. The MOP field in [RFC6550] is of 3 bits and is fast
depleting. This document extends the MOP for future use. depleting. This document extends the MOP for future use.
Status of This Memo Status of This Memo
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 December 7, 2020. This Internet-Draft will expire on April 2, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 2, line 22 skipping to change at page 2, line 22
3. Extended MOP Control Message Option . . . . . . . . . . . . . 4 3. Extended MOP Control Message Option . . . . . . . . . . . . . 4
3.1. Handling MOPex . . . . . . . . . . . . . . . . . . . . . 4 3.1. Handling MOPex . . . . . . . . . . . . . . . . . . . . . 4
3.2. Use of values 0-6 in the MOPex option . . . . . . . . . . 4 3.2. Use of values 0-6 in the MOPex option . . . . . . . . . . 4
4. Extending RPL Control Options . . . . . . . . . . . . . . . . 4 4. Extending RPL Control Options . . . . . . . . . . . . . . . . 4
5. Implementation Considerations . . . . . . . . . . . . . . . . 6 5. Implementation Considerations . . . . . . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7.1. Mode of operation: MOPex . . . . . . . . . . . . . . . . 6 7.1. Mode of operation: MOPex . . . . . . . . . . . . . . . . 6
7.2. New options: MOPex and Capabilities . . . . . . . . . . . 6 7.2. New options: MOPex and Capabilities . . . . . . . . . . . 6
7.3. New Registry for Extended-MOP-value . . . . . . . . . . . 7 7.3. New Registry for Extended-MOP-value . . . . . . . . . . . 7
7.4. Change in RPL Control Option field . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . 7 9.1. Normative References . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . 8 9.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
RPL [RFC6550] specifies a proactive distance-vector based routing RPL [RFC6550] specifies a proactive distance-vector based routing
scheme. The protocol creates a DAG-like structure which operates scheme. The protocol creates a DAG-like structure which operates
with a given "Mode of Operation" (MOP) determining the minimal and with a given "Mode of Operation" (MOP) determining the minimal and
mandatory set of primitives to be supported by all the participating mandatory set of primitives to be supported by all the participating
nodes. nodes.
MOP as per [RFC6550] is a 3-bit value carried in DIO messages and is MOP as per [RFC6550] is a 3-bit value carried in DIO messages and is
specific to the RPL Instance. The receipient of the DIO message can specific to the RPL Instance. The recipient of the DIO message can
join the specified network as a router only when it can support the join the specified network as a router only when it can support the
primitives as required by the mode of operation value. For example, primitives as required by the mode of operation value. For example,
in case of MOP=3 (Storing MOP with multicast support) the nodes can in case of MOP=3 (Storing MOP with multicast support) the nodes can
join the network as routers only when they can handle the DAO join the network as routers only when they can handle the DAO
advertisements from the peers and manage routing tables. The 3-bit advertisements from the peers and manage routing tables. The 3-bit
value is already exhausted and requires replenishment. This document value is already exhausted and requires replenishment. This document
introduces a mechanism to extend mode of operation values. introduces a mechanism to extend mode of operation values.
This document further extends the RPL Control Option syntax to handle This document further extends the RPL Control Option syntax to handle
generic flags. The primary aim of these flags is to define the generic flags. The primary aim of these flags is to define the
behaviour of a node not supporting the given control type. If a node behaviour of a node not supporting the given control type. If a node
does not support a given RPL Control Option, there are three does not support a given RPL Control Option, there are following
possibilities: possibilities:
REQ1: Strip off the option Strip off the option
REQ2: Copy the option as-is Copy the option as-is
REQ3: Ignore the message containing this option Ignore the message containing this option
REQ4: Let the node join in only as a 6LN to this parent Let the node join in only as a 6LN to this parent
1.1. Requirements Language and Terminology 1.1. Requirements Language and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
MOP: Mode of Operation. Identifies the mode of operation of the RPL MOP: Mode of Operation. Identifies the mode of operation of the RPL
Instance as administratively provisioned at and distributed by the Instance as administratively provisioned at and distributed by the
DODAG root. DODAG root.
MOPex: Extended MOP: This document extends the MOP values over a MOPex: Extended MOP: This document extends the MOP values over a
bigger range. This extension of MOP is called MOPex. bigger range. This extension of MOP is called MOPex.
DAO: DODAG Advertisement Object. An RPL message used to advertise DAO: DODAG Advertisement Object. An RPL message used to advertise
the target information in order to establish routing adjacencies. the target information in order to establish routing adjacencies.
DIO: DODAG Information Object. An RPL message initiated by the root DIO: DODAG Information Object. An RPL message initiated by the root
and is used to advertise the network configuration information. and used to advertise the network configuration information.
Current parent: Parent 6LR node before switching to the new path. Current parent: Parent 6LR node before switching to the new path.
This document uses terminology described in [RFC6550]. For the sake This document uses terminology described in [RFC6550]. For the sake
of readability all the known relevant terms are repeated in this of readability all the known relevant terms are repeated in this
section. section.
2. Requirements for this document 2. Requirements for this document
Following are the requirements considered for this documents: Following are the requirements considered for this documents:
REQ1: MOP extension. Current MOP of 3-bit is fast depleting. An REQ1: MOP extension. Current MOP of 3-bit is fast depleting. An
MOP extension needs to extend the possibility of adding new MOP extension needs to extend the possibility of adding new
MOPs in the future. MOPs in the future.
REQ2: Backwards compatibility. The new options and new fields in REQ2: Backwards compatibility. The new options and new fields in
the DIO message should be backward compatible i.e. if there the DIO message should be backward compatible i.e. if there
are nodes which support old MOPs they could still operate in are nodes which support old MOPs they could still operate in
their own instances. their own RPL Instances.
3. Extended MOP Control Message Option 3. Extended MOP Control Message Option
This document reserves existing MOP value 7 to be used as an This document reserves existing MOP value 7 to be used as an
extender. DIO messages with MOP value of 7 may refer to the Extended extender. DIO messages with MOP value of 7 may refer to the Extended
MOP (MOPex) option in the DIO message. MOP (MOPex) option in the DIO message.
0 1 2 0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--------------- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------
skipping to change at page 4, line 32 skipping to change at page 4, line 32
3.1. Handling MOPex 3.1. Handling MOPex
The MOPex option MUST be used only if the base DIO MOP is 7. If the The MOPex option MUST be used only if the base DIO MOP is 7. If the
base DIO MOP is 7 and if the MOPex option is not present then the DIO base DIO MOP is 7 and if the MOPex option is not present then the DIO
MUST be silently ignored. If the base DIO MOP is less than 7 then MUST be silently ignored. If the base DIO MOP is less than 7 then
MOPex MUST NOT be used. In case the base MOP is 7 and if the MOPex MOPex MUST NOT be used. In case the base MOP is 7 and if the MOPex
option is present, then the implementation MUST use the final MOP option is present, then the implementation MUST use the final MOP
value from the MOPex. value from the MOPex.
Note that [RFC6550] allows the node who does not support the received Note that [RFC6550] allows a node that does not support the received
MOP to still join the network as a leaf node. This semantic MOP to still join the network as a leaf node. This semantics
continues to be true even in case of MOPex. continues to be true even in case of MOPex.
3.2. Use of values 0-6 in the MOPex option 3.2. Use of values 0-6 in the MOPex option
The MOPex option could also be allowed to re-use the values 0-6, The MOPex option could also be allowed to re-use the values 0-6,
which have been used for MOP so far. The use of current MOPs in which have been used for MOP so far. The use of current MOPs in
MOPex indicates that the MOP is supported with extended set of MOPex indicates that the MOP is supported with extended set of
semantics for e.g., the capability options semantics for e.g., the capability options
[I-D.ietf-roll-capabilities]. [I-D.ietf-roll-capabilities].
4. Extending RPL Control Options 4. Extending RPL Control Options
Section 6.7.1 of RFC6550 explains the RPL Control Message Option Section 6.7.1 of RFC6550 explains the RPL Control Message Option
Generic Format. This document extends this format to following: Generic Format. This document extends this format to following:
0 1 2 0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+----------- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-----------
| |X| OptionType| Option Length |Opt Flags|J|I|C| Option Data |X| OptionType| Option Length |Opt Flags|J|I|C| Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+----------- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-----------
Figure 2: Extended RPL Option Format Figure 2: Extended RPL Option Format
New fields in extended RPL Control Message Option Format: New fields in extended RPL Control Message Option Format:
'X' bit in Option Type: Value 1 indicates that this is an extended 'X' bit in Option Type: Value 1 indicates that this is an extended
option. If the 'X' flag is set, a 1 byte Option Flags follows the option. If the 'X' flag is set, a 1 byte Option Flags follows the
Option Length field. Option Length field.
Option Length: 8-bit unsigned integer, representing the length in Option Length: 8-bit unsigned integer, representing the length in
octets of the option, not including the Option Type and Length octets of the option, not including the Option Type and Length
fields. Option Flags and variable length Option Data fields are fields. Option Flags and variable length Option Data fields are
included in the length. included in the length.
'J' (Join) bit in Option Flags: A node MUST join only as a 6LN if 'J' (Join) bit in Option Flags: A node MUST join only as a 6LN if
the Option Type is not understood. the Option Type is not understood.
'C' (Copy) bit in Option Flags: A node which does not understand 'C' (Copy) bit in Option Flags: A node that does not understand
the Option Type MUST copy the Option while generating the the Option Type MUST copy the Option while generating the
corresponding message. For e.g., if a 6LR receives a DIO message corresponding message. For e.g., if a 6LR receives a DIO message
with an unknown Option with 'C' bit set and if the 6LR choses to with an unknown Option with 'C' bit set and if the 6LR choses to
accept this node as the preferred parent then the node MUST copy accept this node as the preferred parent then the node MUST copy
this option in the subsequent DIO message it generates. this option in the subsequent DIO message it generates.
Alternatively, if the 'C' flag is unset the node MUST strip off Alternatively, if the 'C' flag is unset the node MUST strip off
the option and process the message. the option and process the message.
'I' (Ignore) bit in Option Flags: A node which does not understand 'I' (Ignore) bit in Option Flags: A node that does not understand
the Option Type MUST ignore this whole message if the 'I' bit is the Option Type MUST ignore this whole message if the 'I' bit is
set. If 'I' bit is set than the value of 'J' and 'C' bits are set. If 'I' bit is set than the value of 'J' and 'C' bits are
irrelevant and the message MUST be ignored. irrelevant and the message MUST be ignored.
Note that this format does not deprecate the previous format, it Note that this format does not deprecate the previous format, it
simply extends it and the new format is applicable only when 2nd bit simply extends it and the new format is applicable only when 2nd bit
('X' flag) of the Option Type is set. Option Type 0x40 to 0x7F are ('X' flag) of the Option Type is set. Option Type 0x80 to 0xFF are
thus applicable only as extended options. thus applicable only as extended options.
+---------+---------+-----------------------------------------------+ +---------+---------+-----------------------------------------------+
| 'J' bit | 'C' bit | Handling | | 'J' bit | 'C' bit | Handling |
+---------+---------+-----------------------------------------------+ +---------+---------+-----------------------------------------------+
| 0 | 0 | Strip off the option, and the node can join | | 0 | 0 | Strip off the option, and the node can join |
| | | as 6LR | | | | as 6LR |
| 0 | 1 | Copy the option, and the node can join as 6LR | | 0 | 1 | Copy the option, and the node can join as 6LR |
| 1 | NA | Join as 6LN | | 1 | NA | Join as 6LN |
+---------+---------+-----------------------------------------------+ +---------+---------+-----------------------------------------------+
Table 1: Option Flags handling Table 1: Option Flags handling
If a node receives an unknown Option without 'X' flag set then the If a node receives an unknown Option without 'X' flag set then the
node MUST ignore the option and process the message. The option MUST node MUST ignore the option and process the message. The option MUST
be treated as if J=0, C=0, I=0. be treated as if J=0, C=0, I=0.
5. Implementation Considerations 5. Implementation Considerations
[RFC6550], it was possible to discard an unsupported DIO-MOP just by In [RFC6550], it was possible to discard an unsupported DIO-MOP just
inspecting the base message. With this document, the MOPex is a by inspecting the base message. With this document, the MOPex is a
different control message option and thus the discarding of the DIO different control message option and thus the discarding of the DIO
message could happen after inspecting the message options. message can only happen after inspecting the message options.
6. Acknowledgements 6. Acknowledgements
Using 'I' bit was Pascal Thubert's idea. Thank you Dominique Barthel for important review/feedback on
extending Control Options.
7. IANA Considerations 7. IANA Considerations
7.1. Mode of operation: MOPex 7.1. Mode of operation: MOPex
IANA is requested to assign a new Mode of Operation, named "MOPex" IANA is requested to assign a new Mode of Operation, named "MOPex"
for MOP extension under the RPL registry. The value of 7 is to be for MOP extension under the RPL registry. The value of 7 is to be
assigned from the "Mode of Operation" space [RFC6550] assigned from the "Mode of Operation" space [RFC6550]
+-------+-------------+---------------+ +-------+-------------+---------------+
skipping to change at page 7, line 27 skipping to change at page 7, line 27
may be allocated only by an IETF review. Currently no values are may be allocated only by an IETF review. Currently no values are
defined by this document. Each value is tracked with the following defined by this document. Each value is tracked with the following
qualities: qualities:
o MOPex value o MOPex value
o Description o Description
o Defining RFC o Defining RFC
7.4. Change in RPL Control Option field
Section 4 of this document specifies MSB of the RPL Control Option to
be used as a bit to indicate RPL Extended Control Options.
IANA is requested to reduce the unassigned values range from 0x10 to
0x7f for RPL Control Options.
IANA is requested to create a new registry for RPL Extended Control
Options indicating values 0x80 to 0xff. New values may be allocated
only by an IETF Review. Each value is tracked with the following
qualities:
o Value
o Meaning
o Defining RFC
The value could be in the range of 0x80 to 0xff.
8. Security Considerations 8. Security Considerations
The options defined in this document are carried in the base message The options defined in this document are carried in the base message
objects as defined in [RFC6550]. The RPL control message options are objects as defined in [RFC6550]. The RPL control message options are
protected by the same security mechanisms that protect the base protected by the same security mechanisms that protect the base
messages. messages.
Capabilities flag can reveal that the node has been upgraded or is Capabilities flag can reveal that the node has been upgraded or is
running a old feature set. This document assumes that the base running a old feature set. This document assumes that the base
messages that carry these options are protected by RPL security messages that carry these options are protected by RPL security
skipping to change at page 8, line 16 skipping to change at page 8, line 32
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,
<https://www.rfc-editor.org/info/rfc6550>. <https://www.rfc-editor.org/info/rfc6550>.
9.2. Informative References 9.2. Informative References
[I-D.ietf-roll-capabilities] [I-D.ietf-roll-capabilities]
Jadhav, R., Thubert, P., Richardson, M., and R. Sahoo, Jadhav, R., Thubert, P., Richardson, M., and R. Sahoo,
"RPL Capabilities", draft-ietf-roll-capabilities-06 (work "RPL Capabilities", draft-ietf-roll-capabilities-07 (work
in progress), June 2020. in progress), September 2020.
Authors' Addresses Authors' Addresses
Rahul Arvind Jadhav (editor) Rahul Arvind Jadhav (editor)
Huawei Tech Huawei Tech
Kundalahalli Village, Whitefield, Kundalahalli Village, Whitefield,
Bangalore, Karnataka 560037 Bangalore, Karnataka 560037
India India
Phone: +91-080-49160700 Phone: +91-080-49160700
 End of changes. 24 change blocks. 
26 lines changed or deleted 49 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/