Hi Gabe, Please see my comments below.
> There is no mention of the link-layer source address changing on a hop-by-hop > basis, only the destination address does so. So at each intermediate node, as well > as at the final destination, what is known is the link-layer source address. > What is not known is the link-layer address of the preceding hop, so a node > knows who originated the packet it just received, but it does not know which > node finally delivered it to it. In AODV/LOAD this is the "reverse route address". > But of course, routing protocols like AODV or LOAD don't use the M bit, they have > originator and destination address fields within the RREQ. This usage of only one > extra address field is something I saw in 802.11 (although they do have the > capability of using two extra fields). > > Hopefully, this clarifies the handling rules. Perhaps it's a good idea to state clearly > that > the source address does not change hop-by-hop. The main question is: are > there any > issues with this? It saves one address field, but are there any issues? Normally, in IP-routing, the ethernet (link-layer) source address is changed at each hop and the link-layer destination address is set according to the next-hop IP address. Thus, the link-layer chooses its source interface MAC address at each hop while the IP-packet contains the orginal source address. Since we are now doing something new here - i,e. route at the link-layer, we still need to somehow know where the packet came from, i.e. the last sender or forwarder's link-layer address. IEEE802.15.4 has ACK frames, during data transfer, it may require a ACK from the next hop - how does the nexthop know where data packet came from ? How does it inform any error to the immediate sender if it does not know its link-layer address? Moreover, the previous hop may depend on receiving ACK to determine if a forward link is broken. Thus the link-layer frame _should_ have the correct src and dst address. That's why I mentioned in my last mail about a solution that maps the 'reverse route' mentioned in RFC3561. RFC3561 mentions: The intermediate node also updates its route table entry for the node originating the RREQ by placing the next hop towards the destination in the precursor list for the reverse route entry -- i.e., the entry for the Originator IP Address field of the RREQ message data. In our case, the AODV packet in the data section will have the originator link-layer address, thus at each intermediate node, upon RREQ, it sets a reverse route as following ( addresses are link-layer addresses): DEST next hop SEq# Originator previous-node originator's seq# This way, we can use reverse route *towards* the originator link-layer address. It is the same way one does at the IP-layer. The only difference here is that we must know our last link-layer sender's address. BTW, reverse routes are better explained in RFC3561 than in aodvbis. Thus, the format document can save one address field (for originator source link-layer addr) by requiring the routing protocol to provide information on originator address so that the intermediate node can setup reverse route. Alternately, the intermediate node will have to do route-discovery for the originator - that is certainly not effecient. Hope this clarifies the point. Thanks, -Samita _______________________________________________ 6lowpan mailing list [email protected] https://www1.ietf.org/mailman/listinfo/6lowpan
