A few comments motivated by the format draft, and to some extent the
problem draft, follow.
The format draft specifies packet formats for a protocol that presumably
behaves something like IPv6, but is clearly not IPv6. I think the
following diagram may provide a useful model:
----------- ---------- ----------
| 6lowpan | ------\ | Magic | ------\ | IPv6 |
| packet | ------/ | Xform1 | ------/ | Packet |
----------- ---------- ----------
I assume that "Magic Xform1" [Magic Transformation 1] really exists.
Of course, I think it is pretty easy to conclude that "Magic Xform2"
does not exist such that IPv6 Packet1 is identical to IPv6 Packet2.
----------- ---------- ----------- ---------- -----------
| IPv6 | ---\ | Magic | ---\ | 6lowpan | ---\ | Magic | ---\ | IPv6 |
| Packet1 | ---/ | Xform2 | ---/ | Packet | ---/ | Xform1 | ---/ | Packet2 |
----------- ---------- ----------- ---------- -----------
This may suggest that we want to be explicit about how Magic Xform1
actually works in detail, such as when an IPv6 packet is received that
can't be transformed into a 6lowpan packet without loss of information.
Presumably, this is the gateway specification document.
------
I assume that people want use the 6lowpan technologies to build real-world
products. Assuming that these products are going to be introduced in
this decade, (or, even in our lifetimes), a majority of these products
will be connected to an IPv4 Internet. As far as I can tell, the
implicit 6lowpan strategy for the real, (i.e., IPv4), world, is the
following, (although I don't think this has been written down):
----------- ---------- ---------- --------- ----------
| 6lowpan | ---\ | Magic | ---\ | IPv6 | ---\ | v4/v6 | ---\ | IPv4 |
| Packet | ---/ | Xform1 | ---/ | Packet | ---/ | Xform | ---/ | Packet |
----------- ---------- ---------- --------- ----------
I think we explicitly decided to ignore the following architecture:
----------- ---------- ----------
| 6lowpan | ------\ | Magic | ------\ | IPv4 |
| packet | ------/ | Xform3 | ------/ | Packet |
----------- ---------- ----------
It seems to me that it would be useful to:
o Convince ourselves that the first diagram will actually work, and
o Determine whether the second diagram can work or can be made
to work.
These diagrams may also suggest that we really want to specify in detail
how both 6lowpan/IPv6 and 6lowpan/IPv4 gateways ought to work. It is
not obvious to me that 6lowpan gateways will all operate the same
way, in the absence of a gateway specification.
------
As I have hinted, I think it may be useful to think of the 6lowpan
network protocol as a protocol that acts a bit like IPv6 and that
has a packet format that can be transformed to and from IPv6 without
too much difficulty, (or state). Another advantage of thinking that
6lowpan is something other than IPv6 is that it would speed, (or would
have sped), the thought process on the 6lowpan discovery document. Once
we consider 6lowpan to be something other than a compressed IPv6,
we can ask the question directly: what information, (e.g., provided by
the IPv6 discovery processes), do 6lowpan nodes need? But, it is true
that we may be arriving at the same answer by asking: how much of
the IPv6 discovery processes do we really need? With our current
approach, however, we may miss opportunities to reuse procedures that
already exist in this environment, and instead simply simulate the IPv6
solution to the same problem.
------
In toto, these comments may suggest the need for a systems-level
architecture document. Developing this document would, I believe,
help increase the probability that our solution is complete.
------
By the way, I didn't seen any explicit congestion notification (ECN)
bit in the format document. Did I miss it, or is it not there.
It seems like this might be something we really want. (Again, a
system architecture document might provide a forum for us to discuss
why ECN is or isn't important.)
------
I would have to reread the problem draft, but I don't think that we
were as emphatic as we might be that an important motivation for
this work is to enable the interconnection of lowpan networks to
the Internet.
------
I don't think we explicitly excluded 6lowpan networks as transit networks.
------
-tjs
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
