Subject: [6lowpan] Analysis of draft-singh-6lowpan-global-connectivity-00

From: Antonio Jara <[email-masked]>
Date: Tue, 29 Mar 2011 03:27:09 +0200

Dear All,

This email presents some comments regarding to the
draft-singh-6lowpan-global-connectivity-00,
I have found some issues which could be commented face to the meeting of
tomorrow and the future improvement of the draft.

First of all, this new draft presents with respect to
"6lowpan-global-connectivity-00.txt", some comments regarding to
issues,which are not addressed in the mentioned draft, for issues such as
AID size, AID mechanism, and mobility support.

First of all, in this new consideration for AID, it is considered the no
inclusion of AID for source address, since this could be determined
from stateless auto-configurability characteristics of IPv6 address, and
also because in case of mobility or multiples GWs, it could change its AID
for the source address frequently. I consider that this assumption regarding
to change of Locator (IP address for the source node) should be analyzed
deeply, since in some situations it is not so obvious to avoid the use of
source AID, for example when host ID from global IP is not being defined
with autoconfiguration based on link layer addressing, whose assumption is
not so clear for global IPs.

2- Regarding to the mobility issues, where a Mobile Node changes of GW, this
new GW has not knowledge about this mapping. This issue is not well
addressed, since in mobility one of the most important steps in "binding
transfer", where it is transfered the context information, sessions
information and pending packets from the previous GW to the new
one, therefore part of the information to be transfered is the information
presented in the Table 3, in Section 2.4, which can avoid this unknown of
the AIDs.

3- Section 4.1.3 comments that are defined messages for AID management such
as AID update message, AID request message, IPv6 update message, and IPv6
request message, in order to synchronize the knowledge between node and GW.

This is quite obvious that this signaling, presents probably more overload
that the bytes reduced in the header compression. Therefore, it should be
considered that AID is generated in an automatic way from GW and MN, for
example with a hash function. With respect to aliasing, since the table
3 considers the concrete node, this reduces considerably that possibility,
and only in case of aliasing should be considered some kind of common
mechanism such as add 1 to the value, since the node also is going to detect
the mentioned aliasing, it can be easily solved.

Remark, that or AID is automatically managed and generated, or whether it is
required AID update messages or equivalents, the performance of this
solution is highly questionable.

4-  Section 3.2.1 and 3.2.2 comment the mechanism followed when the AID is
not found etc. This discussion has not sense, since 1- such as mentioned it
needs to be automatized and 2- the mentioned des-synchronized should be
analyzed deeply, since probably several of the scenarios which requires this
message are because some problem has happened, other way it should be
syncronized with the basic mechanism, and such as mentioned for mobility it
is also synchronized.

5- Figures such as Figure 4 should be fixed, since they are not well
presented.

6- Figure 8 presents that AID size is flexible, I think this is wrong, since
this makes more complex the mechanism to determinate the AIDs in an
automatic way, in addition it can bring more discussion about how to update
previous BIT fields for the tables when the AID size
is dynamically increased etc.

7- I consider that the optimizations should focus on
draft-ietf-6lowpan-hc-15, which is in case of changes, where should be
applied, instead of RFC4944 which is going to be replaced in a short time.

8- Finally, I would like remark that AID idea could be an interesting option
for HC, but it should be deeply analyzed, and first of all, it should be
analyzed the relation between the proposed AID with the field ""Area context
site" used for Header Compression, in order to reach a higher compression,
since that context field is currently being used for Header compression and
in the 6CO option from Neighbor Discovery, and it could make more simplex
and effective the AID field.

Tomorrow in the meeting, it can be discussed some of these issues in the
minuted assigned to this draft.

Best regards,
Antonio Jara