draft-ietf-roll-turnon-rfc8138-00.txt | draft-ietf-roll-turnon-rfc8138-01.txt | |||
---|---|---|---|---|
ROLL P. Thubert, Ed. | ROLL P. Thubert, Ed. | |||
Internet-Draft L. Zhao | Internet-Draft L. Zhao | |||
Updates: 6550,8138 (if approved) Cisco Systems | Updates: 6550,8138 (if approved) Cisco Systems | |||
Intended status: Standards Track December 12, 2019 | Intended status: Standards Track December 12, 2019 | |||
Expires: June 14, 2020 | Expires: June 14, 2020 | |||
Configuration option for RFC 8138 | Configuration option for RFC 8138 | |||
draft-ietf-roll-turnon-rfc8138-00 | draft-ietf-roll-turnon-rfc8138-01 | |||
Abstract | Abstract | |||
This document complements RFC 8138 and dedicates a bit in the RPL | This document complements RFC 8138 and dedicates a bit in the RPL | |||
configuration option defined in RFC 6550 to indicate whether RFC 8138 | configuration option defined in RFC 6550 to indicate whether RFC 8138 | |||
compression is used within the RPL instance. | compression is used within the RPL instance. | |||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
skipping to change at page 3, line 5 ¶ | skipping to change at page 3, line 5 ¶ | |||
capitals, as shown here. | capitals, as shown here. | |||
3. Updating RFC 6550 | 3. Updating RFC 6550 | |||
RPL defines a configuration option that is registered to IANA in | RPL defines a configuration option that is registered to IANA in | |||
section 20.14. of [RFC6550]. This specification defines a new flag | section 20.14. of [RFC6550]. This specification defines a new flag | |||
"Enable RFC8138 Compression" (T) that is encoded in one of the | "Enable RFC8138 Compression" (T) that is encoded in one of the | |||
reserved control bits in the option. The new flag is set to turn on | reserved control bits in the option. The new flag is set to turn on | |||
the use of the compression of RPL artifacts with RFC 8138. | the use of the compression of RPL artifacts with RFC 8138. | |||
Section 6.3.1. of [RFC6550] defines a 3-bit Mode of Operation (MOP) | ||||
in the DIO Base Object. The new "T" flag is defined only for MOP | ||||
value between 0 to 6. For a MOP value of 7 or above, the flag MAY | ||||
indicate something different and MUST NOT be interpreted as "Enable | ||||
RFC8138 Compression" unless the specification of the MOP indicates to | ||||
do so. | ||||
4. Updating RFC 8138 | 4. Updating RFC 8138 | |||
This document specifies controls that enable and disable the use of | This document specifies controls that enable and disable the use of | |||
the [RFC8138] compression in a RPL Instance. Arguably, this could | the [RFC8138] compression in a RPL Instance. Arguably, this could | |||
have been done in [RFC8138] itself. | have been done in [RFC8138] itself. | |||
A node that supports this specification SHOULD source packets in the | A node that supports this specification SHOULD source packets in the | |||
compressed form using [RFC8138] if the new "T" flag is set in the RPL | compressed form using [RFC8138] if the new "T" flag is set in the RPL | |||
configuration option from its parents. Failure to do so will result | configuration option from its parents. Failure to do so will result | |||
in larger packets, yields higher risks of loss and may cause a | in larger packets, yields higher risks of loss and may cause a | |||
fragmentation. | fragmentation. | |||
A node that supports this specification SHOULD refrain from sourcing | A node that supports this specification SHOULD refrain from sourcing | |||
packets in the compressed form using [RFC8138] if the "T" flag is | packets in the compressed form using [RFC8138] if the "T" flag is | |||
reset. This behavior can be overridden by a configuration of the | reset. This behaviour can be overridden by a configuration of the | |||
node in order to cope with intermediate implementations of the root | node in order to cope with intermediate implementations of the root | |||
that support [RFC8138] but not this specification and cannot set the | that support [RFC8138] but not this specification and cannot set the | |||
"T" flag. | "T" flag. | |||
The decision of using RFC 8138 to compress a packet is made at the | The decision of using RFC 8138 to compress a packet is made at the | |||
source depending on its capabilities and its knowledge of the state | source depending on its capabilities and its knowledge of the state | |||
of the "T" flag. A router MUST forward the packet in the form that | of the "T" flag. A router MUST forward the packet in the form that | |||
the source used, either compressed or uncompressed. A router that | the source used, either compressed or uncompressed. A router that | |||
encapsulates a packet is the source of the resulting packet and the | encapsulates a packet is the source of the resulting packet and the | |||
rules above apply to it in that case. | rules above apply to it in that case. | |||
5. Transition Scenarios | 5. Transition Scenarios | |||
It is RECOMMENDED to only deploy nodes that support [RFC8138] in a | A node that supports [RFC8138] but not this specification can only be | |||
network where the compression is turned on. A node that does not | used in an homogeneous network and an upgrade requires a "flag day" | |||
support [RFC8138] MUST only be used as a leaf in that network. | where all nodes are updated and then the network is rebooted with | |||
implicitely RFC 8138 compression turned on with the "T" flag set on. | ||||
A node that supports this specification can work in a network with | ||||
RFC 8138 compression turned on or off with the "T" flag set | ||||
accordingly and in a network in transition from off to on or on to | ||||
off (see Section 5.1). | ||||
A node that does not support [RFC8138] can interoperate with a node | ||||
that supports this specification in a network with RFC 8138 | ||||
compression turned off. But it cannot forward compressed packets and | ||||
therefore it cannot act as a router in a network with RFC 8138 | ||||
compression turned on. It may remain connected to that network as a | ||||
leaf and generate uncompressed packets as long as imcoming packets | ||||
are decapsulated by the parent and delivered in uncompressed form. | ||||
[RFC6550] states that "Nodes other than the DODAG root MUST NOT | [RFC6550] states that "Nodes other than the DODAG root MUST NOT | |||
modify this information when propagating the DODAG Configuration | modify this information when propagating the DODAG Configuration | |||
option". In other words, the configuration option is a way for the | option". In other words, the configuration option is a way for the | |||
root to configure the LLN nodes but it cannot be used by a parent to | root to configure the LLN nodes but it cannot be used by a parent to | |||
advertise its capabilities down the DODAG. It results whether a | advertise its capabilities down the DODAG. It results whether a | |||
parent supports RFC 8138 is not known by the child with the current | parent supports RFC 8138 is not known by the child with the current | |||
level of specifications, and a child cannot favor a parent based on a | level of specifications, and a child cannot favor a parent based on a | |||
particular support. | particular support. | |||
skipping to change at page 4, line 12 ¶ | skipping to change at page 4, line 33 ¶ | |||
free to refrain from joining an Instance when a parameter is not | free to refrain from joining an Instance when a parameter is not | |||
suitable. This means that changing the OCP in a DODAG can be used to | suitable. This means that changing the OCP in a DODAG can be used to | |||
force nodes that do not support a particular feature to join as leaf | force nodes that do not support a particular feature to join as leaf | |||
only. This specification reiterates that a node that is configured | only. This specification reiterates that a node that is configured | |||
to operate in an Instance but does not support a value for a known | to operate in an Instance but does not support a value for a known | |||
parameter that is mandatory for routing MUST NOT operate as a router | parameter that is mandatory for routing MUST NOT operate as a router | |||
but MAY still joins as a leaf. Note that a legacy node will not | but MAY still joins as a leaf. Note that a legacy node will not | |||
recognize when a reserved field is now used and will not turn to a | recognize when a reserved field is now used and will not turn to a | |||
leaf when that happens. | leaf when that happens. | |||
A node that supports [RFC8138] but not this specification can only be | ||||
used in an homogeneous network and an upgrade requires a "flag day" | ||||
where all nodes are updated and then the network is rebooted with | ||||
implicitely RFC 8138 compression turned on with the "T" flag set on. | ||||
A node that supports this specification can work in a network with | ||||
RFC 8138 compression turned on or off with the "T" flag set | ||||
accordingly and in a network in transition from off to on or on to | ||||
off (see Section 5.1). | ||||
A node that does not support [RFC8138] can interoperate with a node | ||||
that supports this specification in a network with RFC 8138 | ||||
compression turned off. But it cannot forward compressed packets and | ||||
therefore it cannot act as a router in a network with RFC 8138 | ||||
compression turned on. It may remain connected to that network as a | ||||
leaf and generate uncompressed packets as long as imcoming packets | ||||
are decapsulated by the parent and delivered in uncompressed form. | ||||
The intent for this specification is to perform a migration once and | The intent for this specification is to perform a migration once and | |||
for all without the need for a flag day. In particular it is not the | for all without the need for a flag day. In particular it is not the | |||
intention to undo the setting of the "T" flag, and though it is | intention to undo the setting of the "T" flag, and though it is | |||
possible to roll back (see Section 5.4), adding nodes that do not | possible to roll back (see Section 5.4), adding nodes that do not | |||
support [RFC8138] after a roll back may be problematic if the roll | support [RFC8138] after a roll back may be problematic if the roll | |||
back is not fully complete (see caveats in Section 5.2). | back is not fully complete (see caveats in Section 5.2). | |||
5.1. Inconsistent State While Migrating | 5.1. Inconsistent State While Migrating | |||
When the "T" flag is turned on in the configuration option by the | When the "T" flag is turned on in the configuration option by the | |||
skipping to change at page 5, line 23 ¶ | skipping to change at page 5, line 27 ¶ | |||
In a single instance scenario, nodes that support RFC 8138 are | In a single instance scenario, nodes that support RFC 8138 are | |||
configured with a new OCP, that may use the same OF operation or a | configured with a new OCP, that may use the same OF operation or a | |||
variation of it. when it finally sets the "T" flag, the root also | variation of it. when it finally sets the "T" flag, the root also | |||
migrates to the new OCP. As a result, nodes that do not support RFC | migrates to the new OCP. As a result, nodes that do not support RFC | |||
8138 join as leaves and do not forward packets anymore. The leaves | 8138 join as leaves and do not forward packets anymore. The leaves | |||
generate packets without compression. The parents - which supports | generate packets without compression. The parents - which supports | |||
RFC 8138 - may encapsulate the packets using RFC 8138 if needed. The | RFC 8138 - may encapsulate the packets using RFC 8138 if needed. The | |||
other way around, the root encapsulates packets to the leaves all the | other way around, the root encapsulates packets to the leaves all the | |||
way to the parent, which decapsulates and distribute the uncompresses | way to the parent, which decapsulates and distribute the uncompresses | |||
inner packet to the leaf, as illustrated in Section 4.3 of | inner packet to the leaf. | |||
[I-D.ietf-roll-useofrplinfo] | ||||
This scenario presents a number of caveats: | This scenario presents a number of caveats: | |||
o The method consumes an extra OCP. It also requires a means to | o The method consumes an extra OCP. It also requires a means to | |||
signal the capabilities of the leaf, e.g., using "RPL Mode of | signal the capabilities of the leaf, e.g., using "RPL Mode of | |||
Operation extension" [I-D.rahul-roll-mop-ext]. | Operation extension" [I-D.rahul-roll-mop-ext]. | |||
o If an implementation does not move to a leaf mode when the OCP is | o If an implementation does not move to a leaf mode when the OCP is | |||
changed to an unknown one, then the node may be stalled. | changed to an unknown one, then the node may be stalled. | |||
skipping to change at page 6, line 5 ¶ | skipping to change at page 6, line 7 ¶ | |||
5.3. Double Instance Scenario | 5.3. Double Instance Scenario | |||
An alternate to the Single Instance Scenario is to deploy an | An alternate to the Single Instance Scenario is to deploy an | |||
additional Instance for the nodes that support [RFC8138]. The two | additional Instance for the nodes that support [RFC8138]. The two | |||
instances operate as ships-in-the-night as specified in [RFC6550]. | instances operate as ships-in-the-night as specified in [RFC6550]. | |||
The preexisting Instance that does not use [RFC8138], whereas the new | The preexisting Instance that does not use [RFC8138], whereas the new | |||
Instance does. This is signaled by the "T" flag which is only set in | Instance does. This is signaled by the "T" flag which is only set in | |||
the configuration option in DIO messages in the new Instance. | the configuration option in DIO messages in the new Instance. | |||
The legacy nodes would not be configured to participate to the second | ||||
instance, and islands that are only connected via legacy nodes would | ||||
not be reachable over the second instance. | ||||
Nodes that support RFC 8138 participate to both Instances but favor | Nodes that support RFC 8138 participate to both Instances but favor | |||
the new Instance for the traffic that they source. On the other | the new Instance for the traffic that they source. On the other | |||
hand, nodes that only support the uncompressed format would either | hand, nodes that only support the uncompressed format would either | |||
not be configured for the new instance, or would be configured to | not be configured for the new instance, or would be configured to | |||
join it as leaves only. | join it as leaves only. | |||
This method eliminates the risks of nodes being stalled that are | This method eliminates the risks of nodes being stalled that are | |||
described in Section 5.2 but requires implementations to support at | described in Section 5.2 but requires implementations to support at | |||
least two RPL Instances and demands management capabilities to | least two RPL Instances and demands management capabilities to | |||
introduce new Instances and deprecate old ones. | introduce new Instances and deprecate old ones. | |||
5.4. Rolling Back | 5.4. Rolling Back | |||
After downgrading a network to turn the [RFC8138] compression off, | After downgrading a network to turn the [RFC8138] compression off, | |||
the administrator SHOULD make sure that all nodes have converged to | the administrator SHOULD make sure that all nodes have converged to | |||
the "T" flag reset before allowing nodes that do not support the | the "T" flag reset before allowing nodes that do not support the | |||
compression in the network (see caveats in Section 5.2). This also | compression in the network (see caveats in Section 5.2). | |||
requires a means to signal the current state of the setting of the | ||||
logic that controls the compression in the node, also using | It is RECOMMENDED to only deploy nodes that support [RFC8138] in a | |||
[I-D.rahul-roll-mop-ext]. | network where the compression is turned on. A node that does not | |||
support [RFC8138] MUST only be used as a leaf. | ||||
6. IANA Considerations | 6. IANA Considerations | |||
This specification updates the "Registry for the DODAG Configuration | This specification updates the "Registry for the DODAG Configuration | |||
Option Flags" that was created for [RFC6550] as follows: | Option Flags" that was created for [RFC6550] as follows: | |||
+---------------+---------------------------------+-----------------+ | +---------------+---------------------------------+-----------------+ | |||
| Bit Number | Meaning | Defining Spec | | | Bit Number | Meaning | Defining Spec | | |||
+---------------+---------------------------------+-----------------+ | +---------------+---------------------------------+-----------------+ | |||
| 2 (suggested) | Turn on RFC8138 Compression | This | | | 2 (suggested) | Turn on RFC8138 Compression | This | | |||
skipping to change at page 7, line 8 ¶ | skipping to change at page 7, line 8 ¶ | |||
7. Security Considerations | 7. Security Considerations | |||
No specific threat was identified with this specification. | No specific threat was identified with this specification. | |||
8. Acknowledgments | 8. Acknowledgments | |||
9. References | 9. References | |||
9.1. Normative References | 9.1. Normative References | |||
[I-D.ietf-roll-useofrplinfo] | ||||
Robles, I., Richardson, M., and P. Thubert, "Using RPL | ||||
Option Type, Routing Header for Source Routes and IPv6-in- | ||||
IPv6 encapsulation in the RPL Data Plane", draft-ietf- | ||||
roll-useofrplinfo-32 (work in progress), November 2019. | ||||
[I-D.rahul-roll-mop-ext] | ||||
Jadhav, R. and P. Thubert, "RPL Mode of Operation | ||||
extension", draft-rahul-roll-mop-ext-01 (work in | ||||
progress), June 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, | |||
<https://www.rfc-editor.org/info/rfc6550>. | <https://www.rfc-editor.org/info/rfc6550>. | |||
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | |||
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | |||
May 2017, <https://www.rfc-editor.org/info/rfc8174>. | May 2017, <https://www.rfc-editor.org/info/rfc8174>. | |||
9.2. Informative References | 9.2. Informative References | |||
[I-D.rahul-roll-mop-ext] | ||||
Jadhav, R. and P. Thubert, "RPL Mode of Operation | ||||
extension", draft-rahul-roll-mop-ext-01 (work in | ||||
progress), June 2019. | ||||
[RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, | [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, | |||
"IPv6 over Low-Power Wireless Personal Area Network | "IPv6 over Low-Power Wireless Personal Area Network | |||
(6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, | (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, | |||
April 2017, <https://www.rfc-editor.org/info/rfc8138>. | April 2017, <https://www.rfc-editor.org/info/rfc8138>. | |||
Authors' Addresses | Authors' Addresses | |||
Pascal Thubert (editor) | Pascal Thubert (editor) | |||
Cisco Systems, Inc | Cisco Systems, Inc | |||
Building D | Building D | |||
45 Allee des Ormes - BP1200 | 45 Allee des Ormes - BP1200 | |||
MOUGINS - Sophia Antipolis 06254 | MOUGINS - Sophia Antipolis 06254 | |||
FRANCE | FRANCE | |||
Phone: +33 497 23 26 34 | Phone: +33 497 23 26 34 | |||
Email: pthubert@cisco.com | Email: pthubert@cisco.com | |||
Li Zhao | Li Zhao | |||
Cisco Systems, Inc | Cisco Systems, Inc | |||
Xinsi Building | Xinsi Building | |||
No. 926 Yi Shan Rd | No. 926 Yi Shan Rd | |||
SHANGHAI 200233 | SHANGHAI 200233 | |||
CHINA | CHINA | |||
Email: liz3@cisco.com | Email: liz3@cisco.com | |||
End of changes. 12 change blocks. | ||||
45 lines changed or deleted | 38 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/ |