Hi Daniel, Thank you for the reply. I gave it some thought after sending the e-mail and I think I solved my problem.
I am referring to the stacked 6lopwan header and not to the stacked IPv6 header. The 6lowpan headers are supposed to be stacked but there is no apparent sentinel or stopping condition header type. As I understand some of the different combinations of headers are the following (M->mesh, F->fragment, D->dispatch, B->broadcast): 1) D | Payload -> described in draft 2) M | D | payload -> described in draft 3) F | D | payload -> described in draft 4) M | F | D | payload -> described in draft 5) M | B | D | payload -> described in draft But there are other possible combinations e.g. 6) M | F | payload -> for 2nd,3rd,... framgents of an IPv6 packet. These fragments don't contain any compressed header to necessitate a Dispatch (LOWPAN_HC1) header following the F header. One would ask "how does the processing code distinguish between cases (4) and (6)" ? The fragmentation header in case (4) is different from case (6) (the former is the first packet fragmentation header, the latter is a subsequent packet) so the processing code knows when to stop. I think that maybe a stopping header (like the No Next Header value in IPv6) is not entirely necessary because the different header combinations are not a lot but shouldn't there be a remark in the draft about this? Thank you! vlasios >-----Original Message----- >From: Daniel Park [mailto:[EMAIL PROTECTED] >Sent: 13 February 2007 06:52 >To: Vlasios Tsiatsis XV (KI/EAB); [email protected] >Subject: Re: [6lowpan] Question about header stack processing > >Question about header stack processingHeader (Section 5.1) is >an actual 6lowpan header. It appears while 6lowpan >communications. Major aim of 6lowpan header is not to carry >IPv6 header itself due to restricted low-layer capacity. >Hence, IPv6 header does not appear over 6lowpan communication >(over the air). IPv6 processing, however, takes place in IPv6 >stack of each 6lowpan node upon decompression of 6lowpan >packets through 6lowpan adaptation layer. So, your concern can >be dealt with IPv6 stack in 6lowpan node as usual. All 6lowpan >header such as fragment and mesh aim to provide 6lowpan >communication underneath IPv6 layer only. >Otherwise, there is no difference between 6lowpan node and >legacy IPv6 node. > >That's my understanding. > >Daniel (Soohong Daniel Park) >Mobile Convergence Laboratory, SAMSUNG Electronics. > >----- Original Message ----- >From: Vlasios Tsiatsis XV (KI/EAB) >To: [email protected] >Sent: Tuesday, February 13, 2007 3:52 AM >Subject: [6lowpan] Question about header stack processing > > >Hi everyone, >I have been going through an example of transmission of one >1280-byte packet from one node to another in a LowPAN. This >transmission involves a mesh header, fragmentation header and >a header compression header on the first packet. Subsequent >packet don't have header compression headers. >On the sender side the situation is easy but on the receiver >side I don't see any stopping condition for the processing >code of the the stacked headers. >For example how does the receiver processing code knows that >the next byte after the current header is actually another >header or the payload ? >Does the last header in the stack have to be a dispatch header >? If so what is the dispatch value (from figure 8 in the draft >) for fragment that carries only payload data ? >Am I missing something ? >Thank you in advance. >vlasios > > > >_______________________________________________ >6lowpan mailing list >[email protected] >https://www1.ietf.org/mailman/listinfo/6lowpan > _______________________________________________ 6lowpan mailing list [email protected] https://www1.ietf.org/mailman/listinfo/6lowpan
