idnits 2.17.1 draft-hushe-roll-dodag-metric-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC6551]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (18 December 2020) is 1196 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 7102 Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ROLL H. She 3 Internet-Draft L. Zhao 4 Intended status: Standards Track P. Thubert 5 Expires: 21 June 2021 Cisco Systems 6 18 December 2020 8 A DODAG Metric Used for DODAG Selection in Low-Power and Lossy Networks 9 draft-hushe-roll-dodag-metric-00 11 Abstract 13 This document extends [RFC6551] by defining a new DODAG metric called 14 DODAG size, which can be used for DODAG selection in Low-Power and 15 Lossy Networks (LLNs). DODAG size is an important metric for nodes 16 to decide which DODAG to join, or which DODAG to migrate. This 17 document proposes methods to disseminate DODAG size from the Root to 18 all nodes in the DODAG, so that the DODAG size can be advertised to 19 new joining nodes. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on 21 June 2021. 38 Copyright Notice 40 Copyright (c) 2020 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Simplified BSD License text 49 as described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.1. References . . . . . . . . . . . . . . . . . . . . . . . 3 57 2.2. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2.3. Requirements Language . . . . . . . . . . . . . . . . . . 4 59 3. Disseminating DODAG size . . . . . . . . . . . . . . . . . . 4 60 3.1. DODAG Size Object . . . . . . . . . . . . . . . . . . . . 4 61 3.2. Disserminating DODAG size through DIO . . . . . . . . . . 5 62 3.3. Disserminating DODAG size through DAO-ACK . . . . . . . . 5 63 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 65 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 66 7. Normative References . . . . . . . . . . . . . . . . . . . . 6 67 8. Informative References . . . . . . . . . . . . . . . . . . . 7 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 70 1. Introduction 72 Low-power and Lossy Networks (LLNs) typically consist of large number 73 of nodes connected by lossy and unstable links. Such networks are 74 typically compised of nodes that are constrained in CPU power, 75 memory, and energy. 77 RPL, the "Routing Protocol for LLNs" [RFC6550], is an IPv6 routing 78 procotol with specific optimizations for such networks. RPL builds 79 routes proactively but maintains them on-demand based on their 80 utilization. Point-to-multipoint (P2MP) and multipoint-to-point 81 (MP2P) routes to and from the Root are optimized, but other point-to- 82 point (P2P) routes are stretched to minimize the control traffic and 83 the state in every node. 85 When used in conjunction with IEEE Std. 802.15.4 [IEEE802154], RPL 86 can be used to form a Personal Area Network (PAN) composed by a 87 6LoWPAN Border Router (6LBR) that is typically collocated with the 88 DODAG Root, and multiple 6LoWPAN Nodes (6LN), that can be RPL routers 89 of leaves. 91 The PAN formation process starts from a DODAG Root. Before a node 92 joins a PAN, it has no information regarding available neighbors or 93 PANs. To discover available PANs, a joining node transmits PAN 94 Advertisement Solicits and listens for PAN Advertisements from either 95 the Root or other joined nodes. 97 The PAN Advertisements contain minimum information (such as network 98 name, DODAG size, etc.) for a node to select an appropriate PAN to 99 join or migrate. The DODAG size is the number of nodes in the DODAG 100 and communicating through the Root. The DODAG size thus is an 101 important metric for a node to decide which PAN to join. Therefore, 102 it is essential to ensure the value of DODAG size advertised is up- 103 to-date. 105 At this early stage, this document propose two methods to 106 disserminates the DODAG size to the PAN. 108 2. Terminology 110 2.1. References 112 The terminology used in this document is consistent with and 113 incorporates that described in "Terms Used in Routing for Low-Power 114 and Lossy Networks (LLNs)" [RFC7102]. Other terms in use in LLNs are 115 found in "Terminology for Constrained-Node Networks" [RFC7228]. 117 "RPL", the "RPL Packet Information" (RPI), and "RPL Instance" 118 (indexed by a RPLInstanceID) are defined in "RPL: IPv6 Routing 119 Protocol for Low-Power and Lossy Networks" [RFC6550]. The RPI is the 120 abstract information that RPL defines to be placed in data packets, 121 e.g., as the RPL Option [RFC6551] within the IPv6 Hop-By-Hop Header. 122 By extension the term "RPI" is often used to refer to the RPL Option 123 itself. The DODAG Information Solicitation (DIS), Destination 124 Advertisement Object (DAO) and DODAG Information Object (DIO) 125 messages are also specified in [RFC6550]. 127 2.2. Glossary 129 This document often uses the following acronyms: 131 6LoWPAN: IPv6 over Low-Power Wireless Personal Area Network 132 6LoRH: 6LoWPAN Routing Header 133 DIO: DODAG Information Object (a RPL message) 134 DODAG: Directed Acyclic Graph 135 DODAG: Destination-Oriented Directed Acyclic Graph 136 LLN: Low-Power and Lossy Network 137 PAN: Personal Area Network 138 RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks 140 2.3. Requirements Language 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 144 "OPTIONAL" in this document are to be interpreted as described in BCP 145 14 [RFC2119][RFC8174] when, and only when, they appear in all 146 capitals, as shown here. 148 3. Disseminating DODAG size 150 The value of DODAG size is collected by the Root, and disseminated to 151 all nodes in the PAN. To ensure timely delivering of DODAG size, it 152 has to be contained in periodic PAN-wide messages that can reach 153 every node in the PAN. 155 The DODAG size is defined by the DODAG Size Object and MAY be present 156 in the DODAG Metric Container option [RFC6551]. 158 3.1. DODAG Size Object 160 [RFC6551] specifies a set of link and node routing metrics and 161 constraints suitable to LLNs. This document extends [RFC6551] by 162 defining a new DODAG metric called DODAG size. 164 The DODAG size object MAY be present in the DODAG Metric Container. 165 There MUST NOT be more than one DODAG size object as a metric per 166 DODAG Metric Container. 168 The DODAG size object is made of DODAG size fields and MUST at least 169 comprise one DODAG size field. Each DODAG size field has a fixed 170 length of 16 bits. 172 The DODAG size object does not contain any additional TLVs. 174 The DODAG size object Type has been assigned value TBD by IANA. 176 The format of the ETX object body is as follows: 178 0 1 179 0 1 2 3 4 5 6 7 8 9 0 1 2 3 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | (field) ..... | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 Figure 1: DODAG Size Object Body Format 185 0 1 186 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | DODAG Size | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 Figure 2: DODAG Size field Format 193 DODAG Size: 16 bits. It is encoded using 16 bits in unsigned integer 194 format. 196 3.2. Disserminating DODAG size through DIO 198 According to [RFC6550], the DIO message is periodically sent to the 199 PAN, and it MAY carry an option called DODAG Metric Container. The 200 DODAG size object can be present in this option. Through the DIO 201 message, the DODAG size is gradually disseminated to nodes in the PAN 203 3.3. Disserminating DODAG size through DAO-ACK 205 The DAO-ACK message [RFC6550] is sent as unicast packet by the DODAG 206 Root in response to a unicast DAO message. 208 It MAY carry the DODAG Metric Container option [RFC6550]. The DODAG 209 size MAY be present in the DODAG Metric Container option. 211 The nodes in a PAN might be able to get the DODAG size timely through 212 the DAO-ACK messsage.. Compared with the DIO message, the DAO-ACK 213 message is tyipcally sent more frequently. Moreover, nodes deep in 214 the DODAG can get the DODAG size more quickly since the DAO-ACK is 215 directly sent by the Root in unicast. 217 4. IANA Considerations 219 This specification updates the "Routing Metric/Constraint Type" 220 subregistry of the "Routing Protocol for Low Power and Lossy Networks 221 (RPL) Routing Metric/Constraint" Registry that was created for 222 [RFC6551]. 224 IANA is thereby requested to allocate one new value as follows: 226 +---------------+-------------+---------------+ 227 | Value | Description | Reference | 228 +---------------+-------------+---------------+ 229 | 9 (suggested) | DODAG size | This document | 230 +---------------+-------------+---------------+ 232 Table 1: New DODAG Metric Object Type 234 5. Security Considerations 236 It is worth noting that in RPL [RFC6550], every node in the LLN that 237 is RPL-aware and has access to the RPL domain can inject any RPL- 238 based attack in the network, more in [RFC7416]. This document 239 applies typically to an existing deployment and does not change its 240 security requirements and operations. It is assumed that the 241 security mechanisms as defined for RPL are followed. 243 6. Acknowledgments 245 The authors wish to thank TBD. 247 7. Normative References 249 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 250 Requirement Levels", BCP 14, RFC 2119, 251 DOI 10.17487/RFC2119, March 1997, 252 . 254 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 255 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 256 May 2017, . 258 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 259 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 260 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 261 Low-Power and Lossy Networks", RFC 6550, 262 DOI 10.17487/RFC6550, March 2012, 263 . 265 [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., 266 and D. Barthel, "Routing Metrics Used for Path Calculation 267 in Low-Power and Lossy Networks", RFC 6551, 268 DOI 10.17487/RFC6551, March 2012, 269 . 271 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 272 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 273 2014, . 275 8. Informative References 277 [IEEE802154] 278 IEEE standard for Information Technology, "IEEE Std. 279 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 280 and Physical Layer (PHY) Specifications for Low-Rate 281 Wireless Personal Area Networks". 283 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 284 Constrained-Node Networks", RFC 7228, 285 DOI 10.17487/RFC7228, May 2014, 286 . 288 [RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A., 289 and M. Richardson, Ed., "A Security Threat Analysis for 290 the Routing Protocol for Low-Power and Lossy Networks 291 (RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015, 292 . 294 Authors' Addresses 296 Huimin She 297 Cisco Systems, Inc 298 Xinsi Building 299 No. 926 Yishan Road, Xuhui District 300 SHANGHAI 301 200233 302 China 304 Email: hushe@cisco.com 306 Li Zhao 307 Cisco Systems, Inc 308 Xinsi Building 309 No. 926 Yishan Road, Xuhui District 310 SHANGHAI 311 200233 312 China 314 Email: liz3@cisco.com 315 Pascal Thubert 316 Cisco Systems, Inc 317 Building D 318 45 Allee des Ormes - BP1200 319 06254 MOUGINS - Sophia Antipolis 320 France 322 Phone: +33 497 23 26 34 323 Email: pthubert@cisco.com