--- 1/draft-ietf-roll-capabilities-03.txt 2020-05-16 02:13:11.417331366 -0700 +++ 2/draft-ietf-roll-capabilities-04.txt 2020-05-16 02:13:11.445332078 -0700 @@ -1,22 +1,23 @@ ROLL R. Jadhav, Ed. -Internet-Draft Huawei Tech +Internet-Draft Huawei Intended status: Standards Track P. Thubert -Expires: October 18, 2020 Cisco +Expires: November 17, 2020 Cisco M. Richardson Sandelman Software Works - R. Sahoo, Ed. - April 16, 2020 + R. Sahoo + Juniper + May 16, 2020 RPL Capabilities - draft-ietf-roll-capabilities-03 + draft-ietf-roll-capabilities-04 Abstract This draft enables the discovery, advertisement and query of capabilities for RPL nodes. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. @@ -24,21 +25,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on October 18, 2020. + This Internet-Draft will expire on November 17, 2020. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -50,42 +51,41 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language and Terminology . . . . . . . . . . 3 1.2. What are Capabilities? . . . . . . . . . . . . . . . . . 3 2. Requirements for this document . . . . . . . . . . . . . . . 4 2.1. How are Capabilities different from MOP or DIO Configuration Option? . . . . . . . . . . . . . . . . . . 4 3. Capabilities . . . . . . . . . . . . . . . . . . . . . . . . 4 - 3.1. Capability Categories . . . . . . . . . . . . . . . . . . 5 - 3.2. Capability Control Message Option . . . . . . . . . . . . 5 - 3.3. Capabilities Handshake . . . . . . . . . . . . . . . . . 6 + 3.1. Capability Control Message Option . . . . . . . . . . . . 5 + 3.2. Capabilities Handshake . . . . . . . . . . . . . . . . . 5 4. Guidelines for defining new capabilities . . . . . . . . . . 6 - 4.1. Handling Capability flags . . . . . . . . . . . . . . . . 7 - 4.1.1. Rules to handle capabilities flag . . . . . . . . . . 7 - 5. ROLL Capabilities . . . . . . . . . . . . . . . . . . . . . . 7 + 4.1. Handling Capability flags . . . . . . . . . . . . . . . . 6 + 4.1.1. Rules to handle capabilities flag . . . . . . . . . . 6 + 5. Node Capabilities . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Capability Indicators . . . . . . . . . . . . . . . . . . 7 5.1.1. Format of Capability Indicators . . . . . . . . . . . 7 - 5.2. Routing Resource Capability . . . . . . . . . . . . . . . 8 - 5.2.1. Format of Routing Resource Capability . . . . . . . . 9 - 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 - 7.1. New option: Capabilities . . . . . . . . . . . . . . . . 9 - 7.2. New Registry for Capabilities Flags . . . . . . . . . . . 10 - 7.3. New Registry for Capabilities Indicators . . . . . . . . 10 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 - 9.2. Informative References . . . . . . . . . . . . . . . . . 11 - Appendix A. Capability Handshake Example . . . . . . . . . . . . 12 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 + 5.2. Routing Resource Capability . . . . . . . . . . . . . . . 7 + 5.2.1. Format of Routing Resource Capability . . . . . . . . 8 + 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 + 7.1. New option: Capabilities . . . . . . . . . . . . . . . . 8 + 7.2. New Registry for Capabilities Flags . . . . . . . . . . . 9 + 7.3. New Registry for Capabilities Indicators . . . . . . . . 9 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 + 9.2. Informative References . . . . . . . . . . . . . . . . . 10 + Appendix A. Capability Handshake Example . . . . . . . . . . . . 11 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction RPL [RFC6550] specifies a proactive distance-vector based routing scheme. The protocol creates a DAG-like structure which operates with a given "Mode of Operation" (MOP) determining the minimal and mandatory set of primitives to be supported by all the participating nodes. This document adds a notion of capabilities using which the nodes in @@ -184,119 +184,84 @@ 3. Capabilities Handling of Capabilities MUST be supported if the network uses MOPex [I-D.ietf-roll-mopex]. Note that capabilities and MOPex are mutually exclusive and it is possible for an implementation to support either or both of the options. -3.1. Capability Categories - - Capabilities can be divided into two broad categories: - - Global Capabilities: These include the capabilities supported across - an RPL instance and are advertised by the Root of the DODAG. If a - node in the LLN doesn't support a particular global capability it may - have to join the RPL instance as a leaf node, as indicated by that - individual capability option. Example of such capabilities are - Compression Methods Supported, Support for TE paths (P-DAO). - - Local Capabilities: It will include the capabilities very specific to - a node in the LLN. Example of such capabilities are NBR Cache - information, Routing table information. - -3.2. Capability Control Message Option +3.1. Capability Control Message Option 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 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = TODO | Option Length | Capabilities TLVs +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Capabilities Option Multiple capabilities could be sent in the same message. The length field allows the message parser to skip the capability TLV parsing. 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 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | CAPType |J|I|G|C|.|.|.|.| CAPInfo(Opt) + | CapType | Len |J|I|C| Flags | ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Capabilities TLV Every capability is identified by its type and it may have an optional Capability Info. Note that a given capability may or may not be diseminated with additional information depending on the scope of the capability indicated by the I bit. - J = Join only as leaf if capability not understood - - I = Capability Info present - - C = Flag indicating that the capability MUST be copied in the - downstream messages - G = If set indicates a Global Capability else its a local. For a - capability if it's mandatory and global bit is set then node those - either doesn't understand the capability or doesn't have this - capability should not join the DODAG as a router. All the global - capablities MUST be diseminated across the network. 6LRs in the - network MUST copy the global capabilities in their DIOs. + Len: 8-bit unsigned integer, representing the length in octets of the + TLV, not including the CapType, Length and Flags fields. - 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 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | CAPLen | Cap Info(format decided by individual cap spec) - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + J = Join only as leaf if capability not understood. - Figure 3: Capabilities Info + I = Ignore the message if this capability is not understood. - Capability Information provides additional information for the given - capability. The format of this field should be defined as part the - individual capability specification and is beyond the scope of this - document. This document provides a container format for carrying the - capability and its context information. + C = Flag indicating that the capability MUST be copied in the + downstream message. -3.3. Capabilities Handshake +3.2. Capabilities Handshake The root node could advertise the set of capabilities it supports in the DIO message. A node could take advantage of the knowledge that the root supports a particular capability. Similarly a node could advertise its capabilities in the DAO message using the capability control message option defined in this document. Capabilities advertised by non-root nodes are strictly a subset of the capabilities advertised by the root. In storing MOP, the DAO message from the 6LR could contain multiple target options because of the DAO-Aggregation. The targets of the capabilities option are indicated by one or more Target options that - precede the Capabilties Option. This handling is similar to the + precede the Capabilities Option. This handling is similar to the Transit Information Option as supported in Section 6.7.8. of [RFC6550]. 4. Guidelines for defining new capabilities This section provides guidelines/recommendations towards defining new capabilities. Note that the capabilities might be carried as part of the multicast messaging such as DIO and hence the set should be used in restrictive manner as far as possible. 4.1. Handling Capability flags - The 'G' (global) flag indicating global capability should be set only - by the root. However, it is not mandatory for the root to set this - flag for all capabilities it indicates. It should set this flag only - for those capabilities which the 6LRs downstream must propagate - further downstream. + A node MUST drop or discard the message silently having an unknown + capability with 'D' (discard) flag set. The 'I' (information) flag is set only when there is additional information to be set in context to the capability. The 'J' (join) flag can be set in context to a capability either by a 6LR or the root. The 'J' flag indicates that if the capability is not supported by a node then it can join the instance only as a 6LN (or do not join as 6LR). The 'C' (copy) flag is set by the node indicating that the @@ -308,45 +273,41 @@ 'J' flag is set then it can only join as a 6LN. If the node is operating as 6LR and subsequently it receives a capability which it doesn't understand with 'J' flag set, then the node has to switch itself to 6LN mode. During switching the node needs to inform its downstream peers of its changed status by sending a DIO with infinite rank as mentioned in [RFC6550]. Capabilities are used to indicate a feature that is supported by the node. Capabilities are not meant for configuration management for e.g., setting a threshold./>. -5. ROLL Capabilities - +5. Node Capabilities 5.1. Capability Indicators Capability Indicators indicates the capabilities supported by the node in the form of simple flags. Capabilities who do not have additional information to be specified could make use of these flags to indicate their support. 5.1.1. Format of Capability Indicators + 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 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Type=0x01 |J|I|G|C|. . . .| Len=3 |. . . . . Indic| + | CapType=0x01 | Len |J|I|C| Flags |T|..Indicators.. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |ators . . . . . . . . . . . .|T| - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Figure 4: Capability Indicators TLV + Figure 3: Capability Indicators TLV Flags: LRs MUST set it to 0. I bit will always be set to 0. - 24-bit Indicators: Currently right most bit is used to indicate 'T' - bit indicating support for 6LoRH. All the unused Indicator bits MUST - be set to zero. + T flag (Bit 1): Indicates whether the node supports 6LoRH [RFC8138]. 5.2. Routing Resource Capability Storing mode of operation requires each intermediate router in the LLN to maintain routing states' information in the routing table. LLN routers typically operate with constraints on processing power, memory, and energy (battery power). Memory limits the number of routing states an LR and BR can maintain. When the routing table of an LR or BR is full, it will either reject the new DAO messages received or will use some replacement policy to remove a routing @@ -355,76 +316,69 @@ network convergence time. Routing state replacement leads to downward path downtime. One possible way to solve problems due to routing table size constraint is to use this information to add neighbors to the DAO parent set.Routing resource capability can be used by LR and BR to advertise their current routing table usage details in the network. LR or LNs in LLN can use this information in the selection of the DAO parent set. PCE can use this information to select intermediate routers for the projected routes. Routing Resource is an optional - local capability. - - Routing reource capability TLV can occur multiple times in the - capability control message option to advertise below possible routing - table information. - - I: Master Routing Table Storing - - II: Storing mode P-DAO Table + capability. - III: Non-Storing mode P-DAO Routing resource capabablity sent in DIO message has link local scope - and it MUST not be forwarded. + and it MUST not be forwarded. The 'C' bit of this capability MUST be + set to 0. 5.2.1. Format of Routing Resource Capability 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 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Type=0x03 |J|I|G|C|. . . .| CAPLen | Reserved | + | CapType=0x02 | Len=3 |J|I|C| Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Total Capacity | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Figure 5: Routing Resource Capability TLV + Figure 4: Routing Resource Capability TLV - Type: 0x03. + Type: 0x02. - Flags: G bit MUST be set to 0. I bit will always be set to 1. + Flags: I bit MUST be set to 0. C bit MUST be set to 0. - CAPLen: 8-bit unsigned integer, representing the length in octets of - the option, not including the Option Type and Length fields. + Len: 8-bit unsigned integer, representing the length in octets of the + option, not including the Option Type and Length/flags fields. Resvd: 8-bit unused field. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. - Total Capacity: 16 bit unsigned integer representing the the routing + Total Capacity: 16 bit unsigned integer representing the routing table size. 6. Acknowledgements Thanks to Georgios Papadopoulos, Li Zhao for early review and feedback. 7. IANA Considerations 7.1. New option: Capabilities New entry is required for supporting new Capabilities option in the "RPL Control Message Options" space [RFC6550]. - +-------+--------------+---------------+ + +-------+-----------------------------+---------------+ | Value | Meaning | Reference | - +-------+--------------+---------------+ - | TBD1 | Capabilities | This document | - +-------+--------------+---------------+ + +-------+-----------------------------+---------------+ + | 0x01 | Capability Indicators | This document | + | 0x02 | Routing Resource Capability | This document | + +-------+-----------------------------+---------------+ New options 7.2. New Registry for Capabilities Flags IANA is requested to create a registry for the Capabilities flags as described in Section 2.1 of this document. This registry should be located in TODO. New Capabilities flags may be allocated only by an IETF review. Currently no flags are defined by this document. Each value is tracked with the following qualities: @@ -462,22 +416,22 @@ mechanisms and thus are not visible to a malicious node. [TODO] implications of malicious attack involving setting the capability flags. 9. References 9.1. Normative References [I-D.ietf-roll-dao-projection] Thubert, P., Jadhav, R., and M. Gillmore, "Root initiated - routing state in RPL", draft-ietf-roll-dao-projection-09 - (work in progress), November 2019. + routing state in RPL", draft-ietf-roll-dao-projection-10 + (work in progress), May 2020. [I-D.thubert-roll-turnon-rfc8138] Thubert, P. and L. Zhao, "Configuration option for RFC 8138", draft-thubert-roll-turnon-rfc8138-03 (work in progress), July 2019. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . @@ -522,26 +476,26 @@ | | | | | DAO(CS2) | | |<-----------| | DAO(CS2) | | |<------------| | | | | CS: Capabilities Set CS1: Capabilities set advertised by root CS2: Capabilities set advertised by node. CS2 is a subset of CS1. - Figure 6: Capabilities Option + Figure 5: Capabilities Option Authors' Addresses Rahul Arvind Jadhav (editor) - Huawei Tech + Huawei Kundalahalli Village, Whitefield, Bangalore, Karnataka 560037 India Phone: +91-080-49160700 Email: rahul.ietf@gmail.com Pascal Thubert Cisco Systems, Inc Building D @@ -549,13 +503,14 @@ MOUGINS - Sophia Antipolis 06254 France Phone: +33 497 23 26 34 Email: pthubert@cisco.com Michael Richardson Sandelman Software Works Email: mcr+ietf@sandelman.ca - Rabi Narayan Sahoo (editor) + Rabi Narayan Sahoo + Juniper Email: rabinarayans0828@gmail.com