IETF MANET Working Group A. Baryun Internet-Draft July 30, 2012 Expires: January 31, 2013 Intended status: Standard The Node Ability of Participation (NAP) draft-baryun-roll-nap-00.txt Abstract Some Wireless Ad hoc Networks (WANETs) like LLNs often have different devices capabilities, with large scale deployment at different regions or environment conditions. In that network context, nodes may not be able to participate in certain time periods because of determined conditions. The Node Ability of Participation (NAP) protocol enhances the network use of its activities and capabilities. Routers and actuators in such networks can be adaptive and efficient for different unpredicted situations. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 http://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 January 31, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. Baryun Expires January 31, 2013 [Page 1] Internet-Draft NAP July 2012 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 1. Introduction Wireless Ad hoc NETwork (WANET) has advantages and flexibility to be used in many applications [RFC5548][RFC5673],but also because of its constraints they need more requirements than infrastructure networks. The Low power and Lossy Network (LLN) has three main node elements; sensor, router, and actuator. LLN node can have sleep mode operation periods for energy conservation, or trickle communication algorithm, but in the same time LLN has a high possibility of node loss. The routers should be able to accommodate such node sleep periods with adaptability to devices constraints and consideration of such loss situations. Therefore, LLN is a network with limited capabilities and high possibility of link/node failure. However, in some unpredicted situations (i.e. events or conditions at some/all regions) the network nodes MAY become able/unable to: (a) transmit or receive messages, (b) discover or maintain routes, (c) forward or schedule, (d) store information or energy, (e) survive, (f) secure transmitted information, (g) manage, and (h) other constraint activity. The Node Ability of Participation (NAP) can be used in LLN to enable adaptable, stable, and scalable routing and/or actuating activities. Baryun Expires January 31, 2013 [Page 2] Internet-Draft NAP July 2012 2. Terminology This section provides definitions for the terminology used throughout this document. 2.1 Requirement Level Language This specification uses capitalized words defined in [RFC2119] to signify requirements. In this document these words are printed in small if not related to requirement level language. The document uses some defined terms from other RFCs which will be noted with each used term. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL", in this document are to be interpreted as described in the RFC 2119. In addition, this document describes other key words: IF x THEN y: the possibility that the condition of x occur, but when it does the function y MUST occur. ELSE IF v THEN w: the condition v is tested only when x does not occur, but when v occurs, the function w MUST occur. ELSE z: the function(s) MUST occur only when all the conditions above, e.g. as x and v conditions do not occur 2.2 The Specification Terminology Additionally, this document uses terminology from [ROLL], [RFC6550], and [RFC5548]. This specification also defines the following terminology: Node Capability: a technique/facility of accomplishment of function(s) without considering node's function(s) conditions. Node Ability: a capability of completing function(s) at determined condition(s), and with the consideration of node or/and network constraints. Baryun Expires January 31, 2013 [Page 3] Internet-Draft NAP July 2012 Capacity: a measure of ability of functioning per unit of time or/and per unit of distance/area/volume. Node Participation: the node service or information reply to neighbors/nodes and/or the network. Participating in network functions it is able of performing. Node Inability: a node not able to participate for certain condition(s). It may be capable to participate. Group Ability: (TBD) Some cooperating nodes in functions/activities that forms the group ability of participating for the group or for the network. LLN Functions: sensing, communicating, routing, actuating, storing, securing, or managing, etc. Functions can be total or partialy operating. Partial Function: a function that has been optimized or minimized in its common activities. This function type is useful within devices of limited capabilities or abilities. NAP Metric: (TBD) a measure of the node's ability capacity. It can be a route metric. 3. Applicability and use case In networks neighbor discovery protocols focuses on the neighbor existence and the route metrics that is related to the neighbor. NAP is a technique that discovers node ability to participate in determined function(s), or discovering the ability to participate in some situations. NAP protocol is intended to be used in LLN and WANET scenarios. Nodes in regions with low probability to continue participation, to survive, or to be secure, SHOULD be in a status to decide which Baryun Expires January 31, 2013 [Page 4] Internet-Draft NAP July 2012 activity that it is able/unable to participate with the network. If a node is able to move (mobile) in the network, it SHOULD be in status to advertise its participation time so the network adapts. Routers in LLN SHOULD be able to dynamically adapt to changes in conditions of communication, SHOULD be able to dynamically compute, select, and possibly optimize the single/multiple path(s) that will be used by the participating nodes (i.e. devices), and SHOULD be able to detect neighbor's function failures and neighbor's NAP change. If the DODAG root is not able to forward the packet using connectivity to the outside of the DODAG then the DODAG root has to drop it as specified in [RFC6550], but in some conditions it is recommended to advertise its NAP change information to the DAG root or neighbors. Any change in node ability will affect its capacity of the participate in the network activities and functions. Within LLNs, devices MAY have different criticality. Therefore, some routers and actuators SHOULD be able to adapt to important changes that affect their network domain performance and report NAP to the LBR. 4. NAP Considerations for LLNs (TBD) The NAP protocol considers two types of node abilities: functioning constraint (FC) and resource constraint (RC). The FCs are related to activities as; communicating, sensing, actuating, routing (e.g. source or/and hop-by-hop), scheduling, data-aggregation, node-mobile, etc. On the other hand the RCs are related to resources issues as; energy consumption, battery capacity, link range and connectivity, processing, memory, environment-event issue, etc. Furthermore as FCs of communication (one way or two ways) the LLN nodes may be able to support one or some of packet transceivers; unicast, multicast, anycast, or broadcast. It was stated in RFC5548 the following RCs that influence some FCs: a) some batteries consumption in some nodes is higher than in others (i.e. battery is a RC that affects many FCs). b) the location of one node to function a path routing maintenance may not be as important as of another node. c) the energy-scavenging methods may recharge the battery at regular or irregular intervals. d) some nodes may have a constant power source. e) some nodes may have a larger memory and are hence be able to store more neighborhood information. f) some nodes may have a stronger CPU and are hence able to perform more sophisticated data aggregation methods. g) other consraints etc. The above resource or capability constraints differ in terms of constraints and describe devices' capabilities and functions' capacities. In [RFC5548] U-LLN requirements and routing Baryun Expires January 31, 2013 [Page 5] Internet-Draft NAP July 2012 capabilities recommendations were described. However, the knowledge of node-ability can be useful if we have different devices' capabilities/capacities or/and different region conditions. This knowledge discovered can be useful to nodes in its routing, actuating or sensing activity. The NAP general idea is that each node may get to a situation that it needs to advertise its *ability* limits for the network benefit, on the other hand, one node in some situation may request information about such nodes' *ability* for its benefit. 5. NAP Protocol Operation and Messages (TBD) The NAP enhances the node's functions and participation activity. In particular in routing, the RPL Objective Function (OF) [RFC5660] defines rules of using routing metrics, optimization objectives, and related functions that can be used to compute Rank and select paths. The OF also rules how parents in the DODAG are selected and their DODAG formation. RPL requires that all routings in a network use a common OF. However, [RFC5661] specifies a set of supported link/node constraints and metrics, so that RPL support the set of route metrics and resource constraints, then nodes by using OF can select their parents in the DODAG according to the route metrics and constraints advertised in the DIO messages. The RFC5661 specifies for routing functions and does not account for node ability conditions and capacity, which may be an advantage for its approach in some scenarios, and an advantage of using NAP in similar or other situations. It may be recommended to include some NAP information in DIO or DIS messages depending on routings request. The NAP protocol approach discovers/advertises the ability information for one or some/all network's elements' (i.e. sensor, router, actuator, host, etc) function(s) related to capability and ability constraints, including the NAP metric. The NAP protocol can be used for one/some network element(s') functions depending on the application scenarios and requirements. NAP is designed with the objective to meet the requirements in all LLNs, and to meet the highest network's functions performance and expectations. The NAP protocol provides nodes with the NAP metrics to assist in neighbor or/and remote node decisions. 5.1. NAP Message Types (TBD) NAP messages are either used as an ICMPv6 information message [RFC4443] or as a RPL control message [RFC6550]. If for routers it is preferred to use RPL control message structure (but actuators and sensors can use either messages). The NAP messages types are as follows: a) Node Ability of Participation Request Message (NPRQ). b) Node Ability of Participation Reply Message (NPRP). Baryun Expires January 31, 2013 [Page 6] Internet-Draft NAP July 2012 c) Node Ability of Participation Advertise Message (NPAD). d) Node Participation Error (NPER). The above messages TLVs will be specified in next version. 5.2. NAP Metric TLV (TBD) A NAP Metric object TLV can be represented in DAG metric container with same common header and structure similar to Routing Metric/Constraint specified in RFC6551: a) Type: 1 byte, b) Length: 1 byte, c) Value: variable (0-255). 5.3. NAP Information Base (TBD) In some nodes that are able to store information related to destinations' ability functions and NAP metrics, can use the NAP Information Base. 5.4. NAP Protocol Operation (TBD) - NAP protocol initiates discovery only IF a known and determined condition occurs. NAP metric can be based in the information carried within the DAG container as route metrics are. In other cases ability metric is based in the NAP Information Base. - Nodes MAY advertise their ability functions and metrics by sending NPAD messages for when it is not able to continue participation for the benefit neighbors or of the network domain. - Nodes may send a request to a node or group of nodes to discover ability status or ability metric by sending NPRQ message. - Nodes listen to NPRP and NPAD messages only when they initiate discovery or when participation with DAG nodes. Nodes listen to NPRQ when they participate in a DODAG. - The Routing metric/constraints and NAP metric can be together or separately used to determine the "best" path by an OF. 6. Security Considerations (TBD) 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. Baryun Expires January 31, 2013 [Page 7] Internet-Draft NAP July 2012 7. IANA Considerations (TBD) NAP messages and TLV to be considered. 8. Acknowledgments (TBD) 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006. [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, March 2012. [RFC6551] Vasseur, J., et al.,"Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks", RFC6551, March 2012. 9.2. Informative References [ROLL] Vasseur, J., "Terminology in Low power And Lossy Networks", Work in Progress, September 2011. [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., Culler, D., Transmission of IPv6 Packets over IEEE 802.15.4 Networks, RFC4944, Sep. 2007. [RFC5548] Dohler, M., et al., Routing Requirements for Urban Low-Power and Lossy Networks, RFC5548, May, 2008. [RFC5673] Pister, K., et al. "Industrial Routing Requirements in Low-Power and Lossy Networks", RFC5673, October, 2009. Author's Address Abdussalam Nuri Baryun Email: abdussalambaryun@gmail.com Baryun Expires January 31, 2013 [Page 8]