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

From: Abdussalam Baryun <[email-masked]>
Date: Sun, 3 Jun 2012 10:37:13 +0200

================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. 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 other purpose, nor disclose, nor distribute its
contents to any other person.
*****************************************************************************************

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 4 Jun 2012 08:06:35 +0200

=============== Possible Duplication ====================
Hi All,

Best regards

Abdussalam Baryun,

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 4 Jun 2012 08:09:53 +0200

================== Possible Duplication ===================
Hi All,

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. 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 other purpose, nor disclose, nor distribute its
contents to any other person.
*****************************************************************************************

---

From: Abdussalam Baryun <[email-masked]>
Date: Sat, 2 Jun 2012 11:36:42 +0200

Hi All,

Best regards

Abdussalam Baryun,

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 5 Jun 2012 17:36:58 +0200

++++++++++++++++++  Possible Duplication ++++++++++++++++++++

Hi All,

Best regards

Abdussalam Baryun,

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 7 Jun 2012 11:00:22 +0200

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

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 7 Jun 2012 21:04:06 +0000

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: [email-masked]
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: [email-masked] [mailto:[email-masked]] On Behalf Of Abdussalam Baryun
Sent: jeudi 7 juin 2012 11:00
To: roll
Cc: roll-owner
Subject: [Roll] Node Ability to Participate (NAP)

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.

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
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 8 Jun 2012 05:48:23 +0200

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) <[email-masked]> 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.
> Tthe COMA mailing list is starting about network management, and I'd have
> thought that your discussion could begin there.
>
> What do you think?
>
>
> "
> 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
>
>
> 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.
>
> <  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 >
> 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.

---

From: C Chauvenet <[email-masked]>
Date: Fri, 22 Jun 2012 10:13:03 +0000

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 : [email-masked] [mailto:[email-masked]] 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) <[email-masked]> 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.
> Tthe COMA mailing list is starting about network management, and I'd 
> have thought that your discussion could begin there.
>
> What do you think?
>
>
> "
> 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
>
>
> can be useful and may be included in some technique, or forwarding table in the protocol specification.
>
> <  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
> [email-masked]

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 22 Jun 2012 22:54:55 +0200

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 <[email-masked]> wrote:
> however, I agree it is an iteresting issue as well, you gave me a new point,
> thanks,
>
> Abdussalam Baryun
> =======================