--- 1/draft-ietf-roll-capabilities-01.txt 2020-03-11 09:13:17.840671506 -0700 +++ 2/draft-ietf-roll-capabilities-02.txt 2020-03-11 09:13:17.876672419 -0700 @@ -1,22 +1,22 @@ ROLL R. Jadhav, Ed. Internet-Draft Huawei Tech Intended status: Standards Track P. Thubert -Expires: September 10, 2020 Cisco +Expires: September 12, 2020 Cisco M. Richardson Sandelman Software Works R. Sahoo, Ed. - March 9, 2020 + March 11, 2020 RPL Capabilities - draft-ietf-roll-capabilities-01 + draft-ietf-roll-capabilities-02 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 +24,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 September 10, 2020. + This Internet-Draft will expire on September 12, 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 @@ -56,23 +56,23 @@ 2. Requirements for this document . . . . . . . . . . . . . . . 4 2.1. How are Capabilities different from MOP or DIO Configuration Option? . . . . . . . . . . . . . . . . . . 4 3. Capabilities . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Capability Catagories . . . . . . . . . . . . . . . . . . 5 3.2. Capability Control Message Option . . . . . . . . . . . . 5 3.3. Capabilities Handshake . . . . . . . . . . . . . . . . . 6 4. Guidelines for defining new capabilities . . . . . . . . . . 7 4.1. Handling Capability flags . . . . . . . . . . . . . . . . 7 4.1.1. Rules to handle capabilities flag . . . . . . . . . . 7 - 5. ROLL Capabilities . . . . . . . . . . . . . . . . . . . . . . 7 + 5. ROLL Capabilities . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Projected Route Capability (PRC) . . . . . . . . . . . . 8 - 5.1.1. Format of Projected Route Capability . . . . . . . . 8 + 5.1.1. Format of Projected Route Capability . . . . . . . . 9 5.2. 6LoRH Capability . . . . . . . . . . . . . . . . . . . . 9 5.2.1. Format of 6LoRH Capability . . . . . . . . . . . . . 10 5.3. Routing Resource Capability . . . . . . . . . . . . . . . 11 5.3.1. Format of Routing Resource Capability . . . . . . . . 11 5.4. Neighbor Cache Capability . . . . . . . . . . . . . . . . 12 5.4.1. Format of Neighbor Cache Capability . . . . . . . . . 13 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7.1. New option: Capabilities . . . . . . . . . . . . . . . . 13 7.2. New Registry for Capabilities Flags . . . . . . . . . . . 13 @@ -222,34 +222,37 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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|.|.|.|.|.| CAPInfo(Opt) + | CAPType |J|I|G|C|.|.|.|.| CAPInfo(Opt) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -354,24 +358,25 @@ I: Supports projected route for both storing and non-storing mode. II: List of supported path metrics that can be used to compute projected routes. III: [To Decide] Can we add the PCE address information to this? 5.1.1. Format of Projected Route 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=0x01 |J|I|G|. . . . .| CAPLen | MOP | Resvd | + | Type=0x01 |J|I|G|C|. . . .| CAPLen | MOP | Resvd | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Routing Metric 1 | Routing Metric 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Routing Metric n-1 | Routing Metric n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Projected Route Capability TLV Type: 0x01. @@ -380,21 +385,21 @@ CAPLen: 8-bit unsigned integer, representing the length in octets of the option, not including the Option Type and Length fields. MOP: 3-bit field indicating the mode of operation of projected route capability. Resvd: 5-bit unused fields.They MUST be initialized to zero by the sender and MUST be ignored by the receiver. - Routing Metric: 16 bit unsigned integer represetning the routing + Routing Metric: 16 bit unsigned integer representing the routing metric to be used for TE path calculation. There can be n number of such routing metric fields. These fileds are alowed with the PRC sent by the DODAG ROOT. LRs MUST not send routing metric information with PRC. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=0x01 | Resvd | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -434,21 +439,21 @@ 6LoRH capability is an optional capability any node that doesn't understand or support the 6LoRH can join the DODAG if the "T" flag in the RPL Configuration option is not set otherwise it MUST join the network as a leaf node. 5.2.1. Format of 6LoRH 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=0x02 |J|I|G|. . . . .| Reserved | + | Type=0x02 |J|I|G|C|. . . .| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: 6LoRH Capability TLV Type: 0x02. Flags: LRs MUST set it to 0. I bit will always be set to 0. Reserved: 16-bit unsigned integer, they MUST be initialized to zero by the sender and MUST be ignored by the receiver.. @@ -487,21 +492,21 @@ III: Non-Storing mode P-DAO Routing resource capabablity sent in DIO message has link local scope and it MUST not be forwarded. 5.3.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|. . . . .| CAPLen | RT | Resvd | + | Type=0x03 |J|I|G|C|. . . .| CAPLen | RT | Resvd | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Total Capacity | Used Per | Threshold | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: Routing Resource Capability TLV Type: 0x03. Flags: G bit MUST be set to 0. I bit will always be set to 1. @@ -608,25 +613,20 @@ messages that carry these options are protected by RPL security 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-lwig-nbr-mgmt-policy] - Jadhav, R., Sahoo, R., Duquennoy, S., and J. Eriksson, - "Neighbor Management Policy for 6LoWPAN", draft-ietf-lwig- - nbr-mgmt-policy-03 (work in progress), February 2019. - [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. [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. @@ -642,20 +642,25 @@ DOI 10.17487/RFC6550, March 2012, . [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, "IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, April 2017, . 9.2. Informative References + [I-D.ietf-lwig-nbr-mgmt-policy] + Jadhav, R., Sahoo, R., Duquennoy, S., and J. Eriksson, + "Neighbor Management Policy for 6LoWPAN", draft-ietf-lwig- + nbr-mgmt-policy-03 (work in progress), February 2019. + [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., and D. Barthel, "Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks", RFC 6551, DOI 10.17487/RFC6551, March 2012, . Appendix A. Capability Handshake Example Root 6LR 6LN | | |