Subject: [6lowpan] comment on the format document ( about source address in the multi-hop )

From: Ki-Hyung Kim <[email-masked]>
Date: Thu, 11 Aug 2005 00:30:23 +0900

Regarding to the question at the IETF-63 6lowpan WG meeting about
M-bit and the compression of source addresses in a multi-hop
environment, here is a simple example scenario of its necessity and
the suggestion of the addition of the format.
 
Let's consider two different scenarios for the single-hop and the
multi-hop packet transmission.
In the single-hop packet transmission(i.e. the destination and the
source node are in one-hop), the destination and source IP addresses
in IPv6 header can be compressed and decompressed by utilizing the
layer 2 destination and source addresses (EUI-64).
 
In the multi-hop packet transmission, the layer 2 destination and
source addresses cannot be utilized for the compression and
decompression because they are just hop-by-hop destination and source,
not the originator and the final destination.
This is why Gabriel includes the final destination field in the
adaptation layer.
By utilizing the final destination field (which does not change
hop-by-hop manner), the destination IP address can be compressed in
the IPv6 header.
In addition, the routing could happen at the adaptation layer, not in
the IP layer.
 
Now, let's think about the originator address.
Because the current format document does not mention the originator
MAC address(EUI64) at the adaption layer, the IPv6 source address in
the IPv6 layer cannot be compressed/decompressed in the multi-hop
environment.
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.
 
It can be considered that the originator address can be retrieved from
the IPv6 source address at the IPv6 layer.  If the packet is
unfragmented, it is possible. the adaptation layer could extract the
originator address from the IPv6 source address.
However if the packet is fragmented, interior fragments does not have
the IPv6 header as a payload. the extraction of the IPv6 source
address at the IPv6 layer could not be possible.
 
One last question is as follows.
"Is the route error reporting to the originator really necessary in
the Mesh routing?"

"Yes, I think so."
If the adaptation layer does not have the originator address for
simplicity of the format, the multi-hop routing (Mesh or Hierarchical
routing) could not have the reporting capability of route errors to
the originator. This might incur some performance drops of
communication. The originator might send multiple packets through the
broken route without being notified of the error.
 
Here's my suggestion of the addition of the format document.
What about modifying the final destinatin field in section 9 of the
format document as follows.
-----------------------------------------------------
      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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |S| Hops Left   |      Address of final destination             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |O| Address of Originator                                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     Figure 9: Final Destination and Originator Field

S: This bit field SHALL be zero.  Future revisions will use this bit
      to signal the use of a short 16 bit address instead of the default
      IEEE extended 64 bit address format of the final destination
 
Hops Left: This 7 bit field SHALL be decremented by each forwarding
      node before sending this packet towards its next hop.  The packet
      is discarded if Hops Left is decremented to 0.
 
Address of final destination: This is the final destination's
link-layer address.  This
      document assumes that this field is 64 bits long, but a future
      revision may add support for short addresses (16 bits).
 
O: This bit field SHALL be zero.  Future revisions will use this bit
      to signal the use of a short 16 bit address instead of the default
      IEEE extended 64 bit address format of the originator
 
Address of originator: This is the originator's link-layer address.  This
      document assumes that this field is 64 bits long, but a future
      revision may add support for short addresses (16 bits).
------------------------------------------------------
 
 Comments are sincerely welcome.

--

Ki-Hyung Kim (김기형, 金起亨)
Associate Professor
Division of Information and Computer Eng., Ajou University
Wonchun-Dong, Yeongtong-Gu, Suwon, Korea 442-749
Tel: +82-31-219-2433, Cel: +82-17-760-2551,  Fax: +82-31-219-1811
http://ilab.ajou.ac.kr/kkim86/index.htm
_______________________________________________
6lowpan mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/6lowpan