Gabrel, > 9.1. Alternatives for Delivery of Frames in a Mesh > > Before discussing the defined mechanism for delivery in a mesh, let's > review some options on how to accomplish this. The final destination > could be expressed either as a layer 2 or as an IP (layer 3) address. > In the latter case, there would be no need to provide any additional > header support in this document (i.e., at the sub-IP layer). The > link-layer destination address would point to the next hop > destination address while the IP destination address would point to > the final destination (IP) address (that may be multiple hops away > from the source). Thus, while forwarding data, the single-hop > destination address would change at each hop (always pointing to the > "best" next link-layer hop), while the destination IP address would > remain unchanged. Notice that if an IP packet is fragmented, the > individual fragments may arrive at any node out of order. If so, if > the initial frament (which contains the IP header) is delayed for > some reason, a node that receives a middle fragment would lack the > final destination address. It would be forced to wait until this > information arrives (in the IP header within the first fragment) > before being able to forward the fragment any further. This imposes > some additional buffering requirements on intermediate nodes. > Additionally, the above scheme would need to be adapted depending on > the layer 3 protocol, and would require this protocol to include its > own addressing information.
Additional buffering and final destination field always-on seem a bit trafoff. If all fragment packet includes final destination field, packet size is a bit increased (24bits if S is set or 72bits). Intermediate nodes, however, don't need any additional buffering. Increasd packet size above seems not too much big in my understanding. So, I think we should clarify this concern in above sentence... Regards, Daniel (Soohong Daniel Park) Mobile Platform Laboratory, SAMSUNG Electronics. _______________________________________________ 6lowpan mailing list [email protected] https://www1.ietf.org/mailman/listinfo/6lowpan
