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

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
>
>
>