[Roll] Node Ability to Participate (NAP)

Abdussalam Baryun <abdussalambaryun@gmail.com> Thu, 07 June 2012 09:00 UTC

Return-Path: <abdussalambaryun@gmail.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 3254821F85C7; Thu, 7 Jun 2012 02:00:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.507
X-Spam-Status: No, score=-3.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id UuaucO8ELrSB; Thu, 7 Jun 2012 02:00:24 -0700 (PDT)
Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com []) by ietfa.amsl.com (Postfix) with ESMTP id 05E6921F84EC; Thu, 7 Jun 2012 02:00:23 -0700 (PDT)
Received: by vcqp1 with SMTP id p1so216930vcq.31 for <multiple recipients>; Thu, 07 Jun 2012 02:00:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sK3qMWCUEhfZkWthTeHumBBxlNjtY9YtxJGeqJVyfuY=; b=seaf4W4TAni6AlzmObScmRglowmAtMsMKFDq8H2k/Uc2GwLJZvXexS20FkKV8aGkFQ O1h0+NhSMUklSBz1C0HA01bku6x6CxczQFXff+fiobJjOWvmj/v2ewwlF8lkBfJTmY0X O+pHxb83XI8cE6mrkWGVTv92dKM3Q+ciuAKcdAZMNNsLbnjTZaD+nhTIMSZN2xlVJa+4 WtLNgtUeUdWSsBtOStatP95ED3EGw7L/h+TLxtCogvpmL+2PAuq4BRumDFqa+TFZyTG6 Ppt1aYDkU7xspc6fLSzovmej3dFgponSHqSNZztyMQe/RKKgcYgkgBTKF6hfcz0J6vpf 9iKw==
MIME-Version: 1.0
Received: by with SMTP id o5mr1058750vdi.86.1339059622651; Thu, 07 Jun 2012 02:00:22 -0700 (PDT)
Received: by with HTTP; Thu, 7 Jun 2012 02:00:22 -0700 (PDT)
In-Reply-To: <17448.1339014690@marajade.sandelman.ca>
References: <CADnDZ893+npCLZxStpOQtm=gNfyShh6o6q-pNxSQC5b7EsM0+A@mail.gmail.com> <CADnDZ8-EirrhjXvx1-iZBtKrVEZUbvP6MUhGBs=Jhbw0cYC=uA@mail.gmail.com> <1FFD6787-3529-462B-B59A-115ADC99B842@cisco.com> <13731.1338814785@marajade.sandelman.ca> <CADnDZ88prkVhco73YrHgnQ=8R9JH2GWnFTUj_GMouiQPWbkPyg@mail.gmail.com> <4787.1338995178@marajade.sandelman.ca> <CADnDZ8_3T-07UQ3h7MTLRU52qq6fhAv216vPdV4Wke-bFNyZYA@mail.gmail.com> <17448.1339014690@marajade.sandelman.ca>
Date: Thu, 07 Jun 2012 11:00:22 +0200
Message-ID: <CADnDZ89OYhXM=9BuAxfjo9xF8_oe+F_Cpfr1mN+f4_GXeFzVHA@mail.gmail.com>
From: Abdussalam Baryun <abdussalambaryun@gmail.com>
To: roll <roll@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: roll-owner <roll-owner@ietf.org>
Subject: [Roll] Node Ability to Participate (NAP)
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Jun 2012 09:00:25 -0000

+++++++++++++++++  Possible Duplication +++++++++++++++++++++++
Hi All,

I want to discuss is there a need to consider the node ability to
participate (NAP) in LLN functions?

I think that the node ability (considering; energy consumption issue,
routing issue, and environment-event issue), it is good for some
node-originators to know neighbor nodes/sinks ability ( NAP to-route,
or NAP continue-to-route, or NAP to-survive, NAP to-store, NAP
to-manage, or other abilities), but not sure if it is available in
some of the ROLL or 6lowpan protocols, nor sure if it can make side
effects to LLN performance. The node-ability can be useful if we have
different devices capabilities and conditions. This knowledge-factor
can be useful and may be included in some technique, or forwarding
table in the protocol specification.

I want to know your advises and opinion, thanking you,

Best regards

Abdussalam Baryun,
University of Glamorgan, UK.
<  One may be wrong, or may be right, but it does not matter if we work together
as a group to discuss and resolve all issues. IETF WGs are always right >
This email and any attachments are confidential to the intended recipient
and may also be privileged. If you are not the intended recipient please
delete it from your system and notify the sender. The contents are comply
to the IETF regulations, and WG procedures. You should not copy the
email nor use it for any purpose other than IETF procedures' purposes.