Re: [Roll] Node Ability to Participate (NAP)

Abdussalam Baryun <abdussalambaryun@gmail.com> Fri, 22 June 2012 20:54 UTC

Return-Path: <abdussalambaryun@gmail.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECC1011E80C9; Fri, 22 Jun 2012 13:54:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lmwQsEosJs3E; Fri, 22 Jun 2012 13:54:57 -0700 (PDT)
Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id D7E3C11E80C7; Fri, 22 Jun 2012 13:54:56 -0700 (PDT)
Received: by vbbez10 with SMTP id ez10so1226464vbb.31 for <multiple recipients>; Fri, 22 Jun 2012 13:54:56 -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:content-transfer-encoding; bh=on0C8nVMgAfO4V31apkRbQ+9xKVa/hTXBBvz7KRc5eg=; b=pZYqV1iSYOpfVhYtLm2eYhnROZYPdNjhpymZ9DshzUYLjTemOu9dGCpMqTc6dkk8wo gzsw3aBkf1YzQDAdi8kUe+Tymb/vVEEtCa87KGm1Vhc8rbGaR4RvxRgnyaQAdzbVmWdK fyjGJkolxvbWXJzn14aRita3DsQg3tfTNDwcZdrOKOKAnhYJ0mOzFXg4lN6E6EjicwzN xcFdvbCRkGkOAfXKnx+0Tnk/oFgPBbjm6CM9JVhUWu3n/Ar33RMlGrRUXsvE0NLqPluV PqHxAHkFHU5bofnXGK5e75DP2JknbUOg1vPqa3KK4+rvuCWNmeWpO4m8pblmdIbkqtGa Vk5Q==
MIME-Version: 1.0
Received: by 10.52.65.145 with SMTP id x17mr1436385vds.117.1340398496057; Fri, 22 Jun 2012 13:54:56 -0700 (PDT)
Received: by 10.220.211.72 with HTTP; Fri, 22 Jun 2012 13:54:55 -0700 (PDT)
In-Reply-To: <97B69B30E0EF244B940B65EA541E3F2D02296E1C@DBXPRD0510MB395.eurprd05.prod.outlook.com>
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> <CADnDZ89OYhXM=9BuAxfjo9xF8_oe+F_Cpfr1mN+f4_GXeFzVHA@mail.gmail.com> <E045AECD98228444A58C61C200AE1BD806E78C95@xmb-rcd-x01.cisco.com> <CADnDZ8_sjXLvkrX6kjP1pgmXUX8y6AzQGZJ55pk_BcZrGSAMMg@mail.gmail.com> <97B69B30E0EF244B940B65EA541E3F2D02296E1C@DBXPRD0510MB395.eurprd05.prod.outlook.com>
Date: Fri, 22 Jun 2012 22:54:55 +0200
Message-ID: <CADnDZ8_o1DBVAfMgSoSgxgyHumFNtGrnzKfu2yxLxbutEERMkA@mail.gmail.com>
From: Abdussalam Baryun <abdussalambaryun@gmail.com>
To: C Chauvenet <c.chauvenet@watteco.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: manet <manet@ietf.org>, roll <roll@ietf.org>, 6lowpan <6lowpan@ietf.org>
Subject: Re: [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: Fri, 22 Jun 2012 20:54:58 -0000

Hi Cédric,

I am writing the draft for NAP, and studying different approaches. Yes
RFC6551 will help thanks, I see in may be used under the <node routing
ability>. I will try to update the ROLL WG in the coming weeks, with
my final suggestions for this idea protocol. The general idea is that
each node may get to a situation to advertise its *ability* limits for
the network benefit, on the other hand, some nodes in some situation
may request information about such *ability* for their benefit.

I think the NAP idea and protocol can be used for LLN, MANET and other
dynamic networks.

I thank you again for you comments,

Regards

Abdussalam Baryun
University of Glamorgan, UK
===========================================================

On 6/22/12, C Chauvenet <c.chauvenet@watteco.com> wrote:
> Hi,
>
> Could RFC6551 (the ex-metric draft) help ?
>
> I think the metric container option could  embed a constraint to adress the
> NAP functionality you are describing
>
> Best,
>
> Cédric.
> -----Message d'origine-----
> De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part de
> Abdussalam Baryun
> Envoyé : vendredi 8 juin 2012 05:48
> À : Pascal Thubert (pthubert)
> Cc : roll; roll-owner
> Objet : Re: [Roll] Node Ability to Participate (NAP)
>
> Hi Pascal,
>
> I was thinking of route-control enhancement, not network management,
> however, I agree it is an iteresting issue as well, you gave me a new point,
> thanks,
>
> Abdussalam Baryun
> =======================
> On 6/7/12, Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:
>> Hello Abdussalam:
>>
>> I'd say it is a great discussion that might end up impacting routing.
>> But also basic network operations (DNS, DHCP ...) and services.
>> So where is the right place to start with?
>> Tthe COMA mailing list is starting about network management, and I'd
>> have thought that your discussion could begin there.
>>
>> What do you think?
>>
>>
>> "
>> List address: coma@ietf.org
>> Archive:  http://www.ietf.org/mail-archive/web/coma/
>> To subscribe:  https://www.ietf.org/mailman/listinfo/coma
>>
>> Purpose: This list is for the discussion related to the management of
>> constrained networks and devices. The IETF so far has not developed
>> specific technologies for the management of constrained networks.
>> There is a need to understand the requirements for the management of
>> such a constrained network and its devices.
>> "
>>
>> Cheers,
>>
>> Pascal
>>
>>
>> -----Original Message-----
>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf
>> Of Abdussalam Baryun
>> Sent: jeudi 7 juin 2012 11:00
>> To: roll
>> Cc: roll-owner
>> Subject: [Roll] Node Ability to Participate (NAP)
>>
>> +++++++++++++++++  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.
>> **********************************************************************
>> ******************* _______________________________________________
>> Roll mailing list
>> Roll@ietf.org
>> https://www.ietf.org/mailman/listinfo/roll
>>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>
>
>