Hi Daniel, Yes, we will have an update of the ND-OPT draft as it has currently in expired state.
If you have any specific comment/contribution on ND-OPT, let's discuss off-line. The following information on ND tuning for 802.16 network is useful. Thanks, -Samita On Mon, Jun 16, 2008 at 7:36 PM, Daniel Park <[EMAIL PROTECTED]> wrote: > I am repeating my comments: > > Samita, are you working for ND-Opt revision ? That's very welcome to me and > I am willing to contribute on this deliverable if any chances...:-) > > [cut and paste from the previous thread] > > This is a tip for understanding and referring how we can fat down NDP for > 6lowpan networks. In 16ng working group, we tried to live up with IEEE > 802.16 Idle/Sleep mode in conjunction with IPv6 NDP. Here is a RA > optimization results... > > > > Hope those efforts help... > > > > Daniel Park > > Co-chair, 16ng working group. > > > > > > 8.2. Router Advertisement > > The AR SHOULD send a number (configurable value) of router > advertisements as soon as the IPv6 link is established, to the MS. > The AR sends unsolicited router advertisements periodically as per > [RFC4861]. The interval between periodic router advertisements is > however greater than the specification in Neighbor discovery for > IPv6, and is discussed in the following section. > > 8.3. Router lifetime and periodic router advertisements > > The router lifetime SHOULD be set to a large value, preferably in > hours. This document over-rides the specification for the value of > the router lifetime in Neighbor Discovery for IP Version 6 (IPv6) > [RFC4861]. The AdvDefaultLifetime in the router advertisement MUST > be either zero or between MaxRtrAdvInterval and 43200 seconds. The > default value is 2 * MaxRtrAdvInterval. > > 802.16 hosts have the capability to transition to an idle mode in > which case the radio link between the BS and MS is torn down. Paging > is required in case the network needs to deliver packets to the MS. > In order to avoid waking a mobile which is in idle mode and consuming > resources on the air interface, the interval between periodic router > advertisements SHOULD be set quite high. The MaxRtrAdvInterval value > specified in this document over-rides the recommendation in Neighbor > Discovery for IP Version 6 (IPv6) [ RFC4861]. The MaxRtrAdvInterval > MUST be no less than 4 seconds and no greater than 21600 seconds. > The default value for MaxRtrAdvInterval is 10800 seconds. > > > On 6/17/08, Samita Chakrabarti <[EMAIL PROTECTED]> wrote: >> >> Hi Pascal, >> >> On 6/16/08, Pascal Thubert (pthubert) <[EMAIL PROTECTED]> wrote: >> > Hi Geoff: >> > >> > This part: >> > " >> > such as reusing the structure of the 802.15.4 network >> > (e.g., by using the coordinators), and reduce the need for multicast >> > by having devices talk to coordinators (without creating a single >> > point-of-failure, or changing the semantics of the IPv6 ND >> > multicasts) >> > " >> > >> > Might be unwelcome. Seems to dictate solutions, which solutions might be >> > hard to achieve at IETF. >> > Note that I am in favor of using L2 beacons as opposed to uniquely data >> > frames to carry RAs. >> > Can we just remove this text for the time being, and just say that we >> > want to >> > " reduce the need for multicast ", "limit the need to wake up sleeping >> > devices", that type of things? >> >> I respectfully disagree with you on that. The solution that reduce >> the need of multicast in IPv6 already exists and it has been discussed >> in the working group many times in the past. Please refer to: >> draft-chakrabarti-6lowpan-ipv6-nd-04.txt >> >> There is a need for reducing multicast and broadcast in the >> reduced-power and low-processing ability devices that require to save >> power and do not want to wake up on multicast/broadcast messages - it >> is pretty clear in 802.15.4 network. >> The charter talks about the context of IPv6 where multicast is >> primarily used for solicitation and advertisement and that will have >> to be reduced since 802.15.4 is a shared network. >> >> I'll re-submit a revised draft before this IETF. >> >> -Samita >> _______________________________________________ >> 6lowpan mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/6lowpan > > > > -- > Soohong Daniel Park [at] Samsung Electronics > Standard Architect, http://blog.naver.com/natpt _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
