idnits 2.17.1 draft-baryun-roll-nap-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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 2 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 208 has weird spacing: '... energy consu...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Most LLN nodes MUST not participate with any node that has not been authenticated to DODAG root or the LLN. An intruder or attacker SHOULD be prevented from manipulating or disabling the routing functions (partial function or total). IF a node was able to detect an attacker which it cannot prevent, THEN it can compromise use of control information with integrity or may disable some participations. The node under attack SHOULD be able of limiting its participation in support of an external network so it will not be vulnerable to DoS. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 30, 2012) is 4250 days in the past. Is this intentional? Checking references for intended status: Full Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC5660' is mentioned on line 244, but not defined == Missing Reference: 'RFC5661' is mentioned on line 249, but not defined ** Obsolete undefined reference: RFC 5661 (Obsoleted by RFC 8881) == Unused Reference: 'RFC6551' is defined on line 356, but no explicit reference was found in the text == Unused Reference: 'RFC4944' is defined on line 365, but no explicit reference was found in the text ** Downref: Normative reference to an Proposed Standard RFC: RFC 6550 ** Downref: Normative reference to an Proposed Standard RFC: RFC 6551 Summary: 5 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF MANET Working Group A. Baryun 3 Internet-Draft July 30, 2012 4 Expires: January 31, 2013 5 Intended status: Standard 7 The Node Ability of Participation (NAP) 8 draft-baryun-roll-nap-00.txt 10 Abstract 12 Some Wireless Ad hoc Networks (WANETs) like LLNs often have 13 different devices capabilities, with large scale deployment at 14 different regions or environment conditions. In that network 15 context, nodes may not be able to participate in certain time 16 periods because of determined conditions. The Node Ability of 17 Participation (NAP) protocol enhances the network use of its 18 activities and capabilities. Routers and actuators in such 19 networks can be adaptive and efficient for different unpredicted 20 situations. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 31, 2013. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with 49 respect to this document. Code Components extracted from this 50 document must include Simplified BSD License text as described in 51 Section 4.e of the Trust Legal Provisions and are provided without 52 warranty as described in the Simplified BSD License. 54 This document may contain material from IETF Documents or IETF 55 Contributions published or made publicly available before November 56 10, 2008. The person(s) controlling the copyright in some of this 57 material may not have granted the IETF Trust the right to allow 58 modifications of such material outside the IETF Standards Process. 59 Without obtaining an adequate license from the person(s) controlling 60 the copyright in such materials, this document may not be modified 61 outside the IETF Standards Process, and derivative works of it may 62 not be created outside the IETF Standards Process, except to format 63 it for publication as an RFC or to translate it into languages other 64 than English. 66 1. Introduction 68 Wireless Ad hoc NETwork (WANET) has advantages and flexibility to be 69 used in many applications [RFC5548][RFC5673],but also because of its 70 constraints they need more requirements than infrastructure networks. 71 The Low power and Lossy Network (LLN) has three main node elements; 72 sensor, router, and actuator. LLN node can have sleep mode operation 73 periods for energy conservation, or trickle communication algorithm, 74 but in the same time LLN has a high possibility of node loss. The 75 routers should be able to accommodate such node sleep periods with 76 adaptability to devices constraints and consideration of such loss 77 situations. Therefore, LLN is a network with limited capabilities 78 and high possibility of link/node failure. 80 However, in some unpredicted situations (i.e. events or conditions 81 at some/all regions) the network nodes MAY become able/unable to: 82 (a) transmit or receive messages, (b) discover or maintain routes, 83 (c) forward or schedule, (d) store information or energy, 84 (e) survive, (f) secure transmitted information, (g) manage, and 85 (h) other constraint activity. The Node Ability of Participation 86 (NAP) can be used in LLN to enable adaptable, stable, and scalable 87 routing and/or actuating activities. 89 2. Terminology 91 This section provides definitions for the terminology used 92 throughout this document. 94 2.1 Requirement Level Language 96 This specification uses capitalized words defined in [RFC2119] to 97 signify requirements. In this document these words are printed in 98 small if not related to requirement level language. The document 99 uses some defined terms from other RFCs which will be noted with 100 each used term. 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL", in 104 this document are to be interpreted as described in the RFC 2119. 105 In addition, this document describes other key words: 107 IF x THEN y: 108 the possibility that the condition of x occur, but when it does the 109 function y MUST occur. 111 ELSE IF v THEN w: 112 the condition v is tested only when x does not occur, but when v 113 occurs, the function w MUST occur. 115 ELSE z: 116 the function(s) MUST occur only when all the conditions above, 117 e.g. as x and v conditions do not occur 119 2.2 The Specification Terminology 121 Additionally, this document uses terminology from [ROLL], [RFC6550], 122 and [RFC5548]. This specification also defines the following 123 terminology: 125 Node Capability: 127 a technique/facility of accomplishment of function(s) without 128 considering node's function(s) conditions. 130 Node Ability: 132 a capability of completing function(s) at determined condition(s), 133 and with the consideration of node or/and network constraints. 135 Capacity: 137 a measure of ability of functioning per unit of time or/and per unit 138 of distance/area/volume. 140 Node Participation: 142 the node service or information reply to neighbors/nodes and/or the 143 network. Participating in network functions it is able of performing. 145 Node Inability: 147 a node not able to participate for certain condition(s). It may be 148 capable to participate. 150 Group Ability: (TBD) 152 Some cooperating nodes in functions/activities that forms the group 153 ability of participating for the group or for the network. 155 LLN Functions: 157 sensing, communicating, routing, actuating, storing, securing, or 158 managing, etc. Functions can be total or partialy operating. 160 Partial Function: 162 a function that has been optimized or minimized in its common 163 activities. This function type is useful within devices of limited 164 capabilities or abilities. 166 NAP Metric: (TBD) 168 a measure of the node's ability capacity. It can be a route metric. 170 3. Applicability and use case 172 In networks neighbor discovery protocols focuses on the neighbor 173 existence and the route metrics that is related to the neighbor. NAP 174 is a technique that discovers node ability to participate in 175 determined function(s), or discovering the ability to participate in 176 some situations. 178 NAP protocol is intended to be used in LLN and WANET scenarios. 179 Nodes in regions with low probability to continue participation, 180 to survive, or to be secure, SHOULD be in a status to decide which 181 activity that it is able/unable to participate with the network. 182 If a node is able to move (mobile) in the network, it SHOULD be 183 in status to advertise its participation time so the network 184 adapts. Routers in LLN SHOULD be able to dynamically adapt to 185 changes in conditions of communication, SHOULD be able to 186 dynamically compute, select, and possibly optimize the 187 single/multiple path(s) that will be used by the participating nodes 188 (i.e. devices), and SHOULD be able to detect neighbor's function 189 failures and neighbor's NAP change. If the DODAG root is not able to 190 forward the packet using connectivity to the outside of the DODAG 191 then the DODAG root has to drop it as specified in [RFC6550], but in 192 some conditions it is recommended to advertise its NAP change 193 information to the DAG root or neighbors. 195 Any change in node ability will affect its capacity of the 196 participate in the network activities and functions. Within LLNs, 197 devices MAY have different criticality. Therefore, some routers and 198 actuators SHOULD be able to adapt to important changes that affect 199 their network domain performance and report NAP to the LBR. 201 4. NAP Considerations for LLNs (TBD) 203 The NAP protocol considers two types of node abilities: functioning 204 constraint (FC) and resource constraint (RC). The FCs are related to 205 activities as; communicating, sensing, actuating, routing (e.g. 206 source or/and hop-by-hop), scheduling, data-aggregation, 207 node-mobile, etc. On the other hand the RCs are related to resources 208 issues as; energy consumption, battery capacity, link range and 209 connectivity, processing, memory, environment-event issue, etc. 210 Furthermore as FCs of communication (one way or two ways) the LLN 211 nodes may be able to support one or some of packet transceivers; 212 unicast, multicast, anycast, or broadcast. 214 It was stated in RFC5548 the following RCs that influence some FCs: 215 a) some batteries consumption in some nodes is higher than in 216 others (i.e. battery is a RC that affects many FCs). 217 b) the location of one node to function a path routing maintenance 218 may not be as important as of another node. 219 c) the energy-scavenging methods may recharge the battery at regular 220 or irregular intervals. 221 d) some nodes may have a constant power source. 222 e) some nodes may have a larger memory and are hence be able to 223 store more neighborhood information. 224 f) some nodes may have a stronger CPU and are hence able to perform 225 more sophisticated data aggregation methods. 226 g) other consraints etc. 228 The above resource or capability constraints differ in terms of 229 constraints and describe devices' capabilities and functions' 230 capacities. In [RFC5548] U-LLN requirements and routing 231 capabilities recommendations were described. However, the knowledge 232 of node-ability can be useful if we have different devices' 233 capabilities/capacities or/and different region conditions. 234 This knowledge discovered can be useful to nodes in its routing, 235 actuating or sensing activity. The NAP general idea is that each 236 node may get to a situation that it needs to advertise its *ability* 237 limits for the network benefit, on the other hand, one node in some 238 situation may request information about such nodes' *ability* for 239 its benefit. 241 5. NAP Protocol Operation and Messages (TBD) 243 The NAP enhances the node's functions and participation activity. 244 In particular in routing, the RPL Objective Function (OF) [RFC5660] 245 defines rules of using routing metrics, optimization objectives, and 246 related functions that can be used to compute Rank and select paths. 247 The OF also rules how parents in the DODAG are selected and their 248 DODAG formation. RPL requires that all routings in a network use a 249 common OF. However, [RFC5661] specifies a set of supported link/node 250 constraints and metrics, so that RPL support the set of route 251 metrics and resource constraints, then nodes by using OF can select 252 their parents in the DODAG according to the route metrics and 253 constraints advertised in the DIO messages. The RFC5661 specifies 254 for routing functions and does not account for node ability 255 conditions and capacity, which may be an advantage for its approach 256 in some scenarios, and an advantage of using NAP in similar or other 257 situations. It may be recommended to include some NAP information in 258 DIO or DIS messages depending on routings request. 260 The NAP protocol approach discovers/advertises the ability 261 information for one or some/all network's elements' (i.e. sensor, 262 router, actuator, host, etc) function(s) related to capability and 263 ability constraints, including the NAP metric. The NAP protocol 264 can be used for one/some network element(s') functions depending 265 on the application scenarios and requirements. NAP is designed with 266 the objective to meet the requirements in all LLNs, and to meet the 267 highest network's functions performance and expectations. The NAP 268 protocol provides nodes with the NAP metrics to assist in neighbor 269 or/and remote node decisions. 271 5.1. NAP Message Types (TBD) 273 NAP messages are either used as an ICMPv6 information message 274 [RFC4443] or as a RPL control message [RFC6550]. If for routers it 275 is preferred to use RPL control message structure (but actuators and 276 sensors can use either messages). The NAP messages types are as 277 follows: 279 a) Node Ability of Participation Request Message (NPRQ). 280 b) Node Ability of Participation Reply Message (NPRP). 282 c) Node Ability of Participation Advertise Message (NPAD). 284 d) Node Participation Error (NPER). 285 The above messages TLVs will be specified in next version. 287 5.2. NAP Metric TLV (TBD) 289 A NAP Metric object TLV can be represented in DAG metric container 290 with same common header and structure similar to Routing 291 Metric/Constraint specified in RFC6551: a) Type: 1 byte, 292 b) Length: 1 byte, c) Value: variable (0-255). 294 5.3. NAP Information Base (TBD) 296 In some nodes that are able to store information related to 297 destinations' ability functions and NAP metrics, can use the 298 NAP Information Base. 300 5.4. NAP Protocol Operation (TBD) 302 - NAP protocol initiates discovery only IF a known and determined 303 condition occurs. NAP metric can be based in the information 304 carried within the DAG container as route metrics are. In other 305 cases ability metric is based in the NAP Information Base. 307 - Nodes MAY advertise their ability functions and metrics by 308 sending NPAD messages for when it is not able to continue 309 participation for the benefit neighbors or of the network domain. 311 - Nodes may send a request to a node or group of nodes to discover 312 ability status or ability metric by sending NPRQ message. 314 - Nodes listen to NPRP and NPAD messages only when they initiate 315 discovery or when participation with DAG nodes. Nodes listen to 316 NPRQ when they participate in a DODAG. 318 - The Routing metric/constraints and NAP metric can be together 319 or separately used to determine the "best" path by an OF. 321 6. Security Considerations (TBD) 323 Most LLN nodes MUST not participate with any node that 324 has not been authenticated to DODAG root or the LLN. An intruder 325 or attacker SHOULD be prevented from manipulating or disabling 326 the routing functions (partial function or total). IF a node was 327 able to detect an attacker which it cannot prevent, THEN it can 328 compromise use of control information with integrity or may 329 disable some participations. The node under attack SHOULD be able 330 of limiting its participation in support of an external network 331 so it will not be vulnerable to DoS. 333 7. IANA Considerations (TBD) 335 NAP messages and TLV to be considered. 337 8. Acknowledgments (TBD) 339 9. References 341 9.1. Normative References 343 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 344 Requirement Levels", BCP 14, RFC 2119, March 1997. 346 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 347 Message Protocol (ICMPv6) for the Internet Protocol 348 Version 6 (IPv6) Specification", RFC 4443, March 2006. 350 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., 351 Hui, J., Kelsey, R., Levis, P., Pister, K., 352 Struik, R., Vasseur, JP., and R. Alexander, 353 "RPL: IPv6 Routing Protocol for Low-Power and Lossy 354 Networks", RFC 6550, March 2012. 356 [RFC6551] Vasseur, J., et al.,"Routing Metrics Used for Path 357 Calculation in Low-Power and Lossy Networks", RFC6551, 358 March 2012. 360 9.2. Informative References 362 [ROLL] Vasseur, J., "Terminology in Low power And Lossy 363 Networks", Work in Progress, September 2011. 365 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., Culler, D., 366 Transmission of IPv6 Packets over IEEE 802.15.4 Networks, 367 RFC4944, Sep. 2007. 369 [RFC5548] Dohler, M., et al., Routing Requirements for Urban Low-Power 370 and Lossy Networks, RFC5548, May, 2008. 372 [RFC5673] Pister, K., et al. "Industrial Routing Requirements in 373 Low-Power and Lossy Networks", RFC5673, October, 2009. 375 Author's Address 377 Abdussalam Nuri Baryun 378 Email: abdussalambaryun@gmail.com