Hi Samita, Please see my comments below. > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of Samita Chakrabarti > Sent: Thursday, October 13, 2005 5:23 AM > To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED] > Cc: [email protected] > Subject: Re: [6lowpan] format document issues > > 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
I want to clarify about reporting RERR to the originator in AODV. AODV does not rely on the reverse route path for reporting RERR to the originator even though it could. Moreover, the reverse route path in the routing table could not be used for unicasting back a RERR in 6lowpan because a data packet does not contain the originator address. That is, even though a routing table contains a reverse route to the originator, the route could not be found by just looking at a data packet. Instead of the reverse route, AODV uses a precursor list attached on the routing entry for the unreachable destination. The list contains neighbor nodes in previous hop. Also, AODV could even utilize a reverse route path to the originator instead. The precursor list was set up when a node processing a RREQ and a RREP. If the list contains a neighbor, the upstream node just unicasts a RERR to the neighbor (that is, previous hop node). Otherwise, if the list has multiple neighbors, the node may broadcast a RERR or unicast a RERR one-by-one to each neighbor. The precursor list might be utilized in 6lowpan also for the RERR reporting, but have to pay some expense for maintaining it. That is one of the reasons why we are trying to find alternate lightweight solutions in 6lowpan. _______________________________________________ 6lowpan mailing list [email protected] https://www1.ietf.org/mailman/listinfo/6lowpan
