> > Issue 2 > ---Technical work required on encapsulation/format specification: ----- > > NK: > > I think I understand what KiHyungKim was getting at here. Correct me if > I am wrong, his argument was that the source address also changes on a > link by link basis and just having a destination address and compressing > out the IP source and destination address will not work. We need to also > add another field that specifies a "multi hop" source address field when > the M bit is present. > > --------------------------------- > SC: > > I don't quite understand the issue of header compression here for IPv6 > case. We are doing header compression in IPv6 header, not on 802.15.4 > MAC layer address. Since M bit signifies that this packet is routed in > LL2-multihop fashion, the final destination would be a MAC-address. > I don't see any header compression of final destination when M bit set. >
After going back to the old mails in the alias, I think I understood now what KiHyungKim was trying to point at. ------------email excerpt from KiHyungKim in Aug 10---------------- Again, the layer 2 source address is not the originator address, but the previous hop node. Additionally, the routing at the adaptation layer could not report to the originator of route errors during data transmission . For example, A is the originator and E is the destination as follows. A --> B --> C --> D --> E In case, the link between C and D is broken, A --> B --> C -X-> D --> E C could report the broken link to the originator by utilizing Route Error message (in LOAD) if the data packet DOES have the originator address at the adaptation layer. -------------------------------------------------------------------- So, the main concern is how to report the error back. He also mentioned LOAD as a routing protocol. I think we should not add originator source address in the LowPan header - we are already short in payload length. The use of 'final destination' is needed, but not the 'originator source MAC address'. For example, when AODV RREQ is received at each intermediate node, it can extract the originator MAC address from the AODV packet and build a reverse route towards the orginator node. In the above example, node C will keep a reverse-route table ( in order to go to A next hop is B). When link between C and D breaks, during multihop data transfer, C can propagate that error back to the originator node by using multihop in the reverse direction. Thus, when M bit is set, we assume that intermediate nodes between two end-nodes will also use multi-hop routing (and discovery if needed) to propagate the error back to the originator. The format document, may explain the above situation and recommend that the underlying multihop routing protocol should be such that it should optimize multihopping in the reverse direction as well - Thus we can save 8 valuable bytes from the lowpan header. The lowpan M bit and forwarding concept is perhaps quite similar to draft-perlman-rbridge-03.txt where the shim-header contains the egress rbridge's address for unicast routing. Thanks, -Samita _______________________________________________ 6lowpan mailing list [email protected] https://www1.ietf.org/mailman/listinfo/6lowpan
