Catching up with this comment... Nandu, sorry for loooong delay.
Route Cost is one of important elements in LOAD and 6lowpan node decides more good link quality than before accordingly. Also it is applied to DYMO-low. Still...I am not sure why Cost Type would be embedded into header. Upon checking the Route Cost field of header, 6lowpan node will decide its own decision regardless of Cost Type. On the other hand, even if there are lots of bits available to use, I think *Reserved* MUST come after *specific bits - R/D/O...* for further extension regardless of a new fields such as Cost Type... Regards, Daniel (Soohong Daniel Park) Mobile Platform Laboratory, SAMSUNG Electronics. ----- Original Message ----- From: Kushalnagar, Nandakishore To: [email protected] Sent: Thursday, August 04, 2005 8:49 AM Subject: [6lowpan] comments on the load document Daniel, I think it seems to be a pretty comprehensive document to tailor AODV for 6lowpan. I have 1 major comment and 1 suggestion. The accumulation routing metric tbd in this document is interesting as I see the reason you want to do this is to give a holistic picture of bidirectional routing. But just accumulation of the routing cost as is has these problems: 1. the route reply cost will always be worser than the request cost and hence the underlying operation would change for route comparison with forward and reverse metrics. (section 2. as far as I see this is an option that vendors MAY choose to implement and hence must be an option. I would like to propose an idea of having routing metric type: If we think of sensor networks, the path chosen depends on what kind of metric you choose. In 6lowpans, these metrics can be dynamic. For example imagine when all nodes are running on full power, the nodes may choose routing metric to be end to end delay, lqi, hop count, etc. When nodes start loosing battery, the nodes may want to choose a different metric based on remaining life time. Thus a routing metric type within the routing header is extremely important to lowpans more than other kinds of network. Here we can say how we plan to accomplish this within the LOAD scope as there are a lot of bits available to use. Here is my suggestion: The current format for route request is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |R|D|O|Reserved | RREQ ID | Route cost | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Layer Destination Address / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Layer Originator Address / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <Fig. 1. RREQ message format> Suggested format change for route request could be: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |R|D|O|B| Cost Type | RREQ ID | Route cost | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Layer Destination Address / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Layer Originator Address / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <Fig. 1. RREQ message format> B: Bidirectional cost when accumulation happens in a bidirectional manner Cost Type: This is a cost type that dictates the type of routing cost present in the header. The following are the current cost types known: 0: Hop count(All routing implementations must support this type) 1: End to end delay 2: lqi 3: Battery lifetime 4-127: TBD 128-255: Vendor dependent The current format for route response is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |R|D|O|Reserved | RREQ ID | Route cost | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link layer Destination Address / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link layer Originator Address / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <Fig. 2. RREP message format> Suggested format change is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |R|D|O|B| Cost Type | RREQ ID | Route cost | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link layer Destination Address / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link layer Originator Address / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <Fig. 2. RREP message format> B: Bidirectional cost when accumulation happens in a bidirectional manner Cost Type: This is a cost type that dictates the type of routing cost present in the header. The following are the current cost types known: 0: Hop count (All routing implementations must support this type) 1: End to end delay 2: lqi 3: Battery lifetime 4-127: TBD 128-255: Vendor dependent Current RERR message error codes Numeric value for describing error. 0x00 = No available route 0x01 = Low battery 0x02 - 0xff = reserved (TBD) Suggested changes in error codes: 0x00 = No available route 0x01 = routing cost not supported 0x02 - 0xff = reserved (TBD) Nandu _______________________________________________ 6lowpan mailing list [email protected] https://www1.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list [email protected] https://www1.ietf.org/mailman/listinfo/6lowpan
