Hi Lijo I joined the recommended group of routing, however I am looking for multi-hop communication scenarios for these low-power devices which can be connected to IPv6 network later. Can you suggest me something for this?
Kind Regards Sajjad On Mon, Nov 28, 2016 at 4:12 AM, Lijo Thomas <[email protected]> wrote: > Hi sajjad, > > > > Routing issues are discussed in roll WG I guess. > > > > The compression of routing header is done by 6loRH and that is being > discussed 6lo WG > > > > Please check the IETF main page to see the different WGs. > > > > If you can specify the exact solution looking for, maybe I would suggest > if available. > > > > > > > > *Thanks & Regards,* > > *Lijo Thomas * > > > > > > *From:* sajjad akbar [mailto:[email protected]] > *Sent:* 26 November 2016 18:05 > *To:* Lijo Thomas > *Cc:* Dale R. Worley; lo > > *Subject:* Re: [6lo] IETF 97 : Comments : draft-lijo-6lo-expiration- > time-00.txt > > > > Hi > > > > Can anyone recommend me a draft where routing issues are discussed in > 6lo? I am working on link metrics for routing in low-power networks and it > will help me to align my research according to some standard. > > > > Looking forward for the reply > > > > Regards > > Sajjad > > > > On Fri, Nov 25, 2016 at 5:17 AM, Lijo Thomas <[email protected]> wrote: > > Hi Dale, > > Thanks for your valuable suggestion !!! > > The explanation is perfect for the packets whose Source and Destination are > within the same network(For example., same 6TiSCH network).When a packet > traverses from heterogeneous networks then "Time in microseconds" is the > natural way to represent it. > > We can think of designing "slot time" approach from Leaf node to LBR and > convert it into "Time(micro-seconds)" at the gateway node. But, again the > issue is we will be having Time mismatch during the conversion from > slot-time to "microseconds". > > We will certainly work on the idea you suggested so that we can come up > with > a proposition without compromising on the generality. > > > Thanks & Regards, > Lijo Thomas > > > -----Original Message----- > From: 6lo [mailto:[email protected]] On Behalf Of Dale R. Worley > Sent: 24 November 2016 09:23 > To: [email protected]; [email protected] > Subject: Re: [6lo] IETF 97 : Comments : > draft-lijo-6lo-expiration-time-00.txt > > To me, it would be natural to specify an expiration time as the > time-to-expiration, measured in slot times. > draft-lijo-6lo-expiration-time-00 specifies expiration time as an absolute > time, measured from ASN=0 in microseconds. The latter approach seems to > require larger headers, without making processing much simpler. > > It seems to me that measuring expriation time in microseconds is no more > useful than measuring it in slot times, because there is no functional > difference between any of the 10,000 microseconds within a single 10 ms > slot > time. But counting microseconds requires an additional 13 bits (over 1.5 > octets) in the header. > > Specifying time-to-expiration means that every time the packet is > forwarded, > the expiration header must be updated. But it can make the expiration > header shorter. For instance, in the example I mentioned in my previous > message, > > Example: In a 6TiSCH network let the time-slot length be 10ms. If > the network has been operational for 2 years, the > packet_origination_time = Current ASN is 6,307,200,000, and the > max_allowable_delay is 1 second, then: > > expiration_time = packet_origination_time + max_allowable_delay > = 6,307,200,000*10 ms + 1 second > = 63,072,001,000,000 microseconds > > or > > expiration_time = ASN 6,307,200,100 > > Expressing the absolute expiration time in slot times requires 33 bits/5 > octets. But the time-to-expiration is only 100 and can be expressed in > 7 bits/1 octet. > > Dale > > _______________________________________________ > 6lo mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6lo > > ------------------------------------------------------------ > ------------------------------------------------------------------- > [ C-DAC is on Social-Media too. Kindly follow us at: > Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ] > > This e-mail is for the sole use of the intended recipient(s) and may > contain confidential and privileged information. If you are not the > intended recipient, please contact the sender by reply e-mail and destroy > all copies and the original message. Any unauthorized review, use, > disclosure, dissemination, forwarding, printing or copying of this email > is strictly prohibited and appropriate legal action will be taken. > ------------------------------------------------------------ > ------------------------------------------------------------------- > > _______________________________________________ > 6lo mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6lo > > > > ------------------------------------------------------------ > ------------------------------------------------------------------- > [ C-DAC is on Social-Media too. Kindly follow us at: > Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ] > > This e-mail is for the sole use of the intended recipient(s) and may > contain confidential and privileged information. If you are not the > intended recipient, please contact the sender by reply e-mail and destroy > all copies and the original message. Any unauthorized review, use, > disclosure, dissemination, forwarding, printing or copying of this email > is strictly prohibited and appropriate legal action will be taken. > ------------------------------------------------------------ > ------------------------------------------------------------------- >
_______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
