Internet DRAFT - draft-baryun-roll-nap
draft-baryun-roll-nap
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]
