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 protected]> 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 : [email protected] [mailto:[email protected]] 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 protected]> 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: [email protected] >> 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 protected] [mailto:[email protected]] 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/roll >> > _______________________________________________ > Roll mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/roll > > > _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
