Re: [6lowpan] format document issues

I've appended some comments to Samita's.

---------Issue from the previous meeting:

Issue 1:

Christian Huitema suggested looking at existing IANA registries for
protocol types to avoid having to set up another one. Specifically, he
suggested looking at IP protocol identifiers. Other people suggested
looking at link-layer registries such as Ethertype and PPP protocol IDs.
This item requires further work. [6lowpan at IETF 63
<http://6lowpan.tzi.org/6lowpan_20at_20IETF_2063> ] 

When examining a specific registry, we should make sure that it actually
is a good fit. The payloads for the 6lowpan encapsulation are somewhat
6lowpan specific. Raw IPv6 packets are just one type; we also will have
a number of rather 6lowpan specific header compression schemes. In
addition, routing and registration/management messages are quite likely
to be entirely 6lowpan specific. 

One other consideration would be whether the 6lowpan registrations would
place an undue burden on the original registry. E.g., there are only 256
IP protocol numbers, which makes them a scarce resource. 

One other way to manage the number space would be to make one or more
existing registries part of the 6lowpan number space. E.g., there could
be a selector that chooses between IP protocol numbers and PPP protocol
numbers (assuming both actually make sense in this context). 

IP protocol numbers are 8 bits. PPP protocol numbers are 14 bits
(expressed in either 8 or 16 bits depending on the low order bit of the
first byte). 

NK: 

I looked at IANA and could not find a protocol type that had the width
of 11 bits and that served the purpose of what we needed. Please let me
know if I am wrong here.

As for adding ether type may be a good solution, the document does
mention about adding a SNAP header. If we were to add the SNAP header we
could potentially remove the protocol field in the adaptation layer. But
as we discussed in the meeting, how difficult would it be to get a
packet that has ethertype for 6lowpan specific packets such as route
messages, etc. Another issue with adding 8 bytes of LLC/SNAP is that we
will loose those bytes from the header.

If there are no heart burns about this, then we could perhaps choose to
add the LLC/SNAP header and remove protocol field from the header and
instead use 6lowpan type field whose values are defined within this
document to indicate types of 6lowpan messages. (routing, discovery,
etc). This is of course assuming that 6lowpan could be made a type under
the definition of SNAP protocol type. Any suggestions?

----------------------
SC:

It'd be a mistake, IMHO to add LLC/SNAP (8 bytes) in 802.15.4 layer in order
to use only a few bits for protocol number. Even for ethernet, LLC/SNAP
only uses 2 bytes in a meaningful way and adds extra overhead of bytes
(SSAP=DSSAP always same). Protocol type needs to be looked at every
LL-hop - thus header compression at this level would not work.

Also, the Lowpan protocol type different than the IP-protocol (L3) type,
folks may want to run a lowpan specific protocol that does not run
on the IP layer.  Thus it may not be a good idea to hold space from IP-protocol
space.

I don't understand the process of protocol type assignment - but can we
ask for a different space for LowPan protocol types ?  

Also, would like to see 11 bits to shrink to a lower number say 8bits
or so.

--------------------------
gab:

I agree with Samita about LLC/SNAP encapsulation not being desirable.
This is what I wrote in the draft (removed when the draft changed from an
individual submission to an official WG document): 
(Available at 
http://www.watersprings.org/pub/id/draft-montenegro-lowpan-ipv6-over-802.15.4-02.txt)

   NOTE: In traditional IEEE 802 applications, a further 8 octets are
   taken up by LLC/SNAP encapsulation [RFC1042], which would leave only
   73 octets for upper layer protocols (e.g., IP).  SNAP encapsulation
   is not used in this specification.  Any heartburn about this? Must
   think about compatibility with other applications (what do these
   do?).  To guarantee interoperability, we might want to add the SNAP
   header.  It's just more fixed overhead, as instead of following with
   the ether_type for IPv6 (and overloading the version field as per the
   hack in RFCs 1144 and 2507), we would want to follow the SNAP header
   with a new identifier for the adaptation layer defined below.

As can be seen from the above, I did look at existing protocol type fields
like ethertype and PPP DLL. At that time, our protocol type was only 5 bits,
which allowed for only 1 octect of overhead before the IPv6 packet. No existing
protocol type was small enough. 

Besides, we need to have the flexibility of defining several more types, cuz,
as alluded to above, we need to carry not just
IPv6, but other variants of that header (for the different compression
schemes) as well as other protocols (e.g., our adaptations of routing protocols
like AODV and DyMO which populate the routing tables for later use by the
mesh delivery mechanism). It might be tough to obtain ether_types for stuff
that is specific to 6lowpan. Instead, we would probably end up obtaining only
one ether_type for 6lowpan encapsulation. And then we could still have our own
encapsulation overhead on top of that, so the minimum overhead would not be 8 octets,
but 10, by the time we're done. 

As for why have our own name space: We're doing compression specific to 6lowpan
as it integrates compression of L3 IPv6 header with L2 802.15.4 header, so
is not a general scheme. Our new registry is for our private use within 
6lowpan encapsulation headers. I don't see what the issue is with that, as
literally hundreds of protocols already define their own private name spaces.
Many protocols define more than one (e.g., MIPv6). This is so common that 
*all* RFCs are supposed to have an IANA considerations section. Perhaps the
worry is that we'd end up duplicating several of the very long protocol 
registries already in existence. Well, the idea is that most apps would use
IPv6, and for that there is an existing protocol space. Nothing new there.

The comment about our laying to much of a burden on the limited IP protocol
space of 256 total types, I don't see how this applies. We're not using the
IP protocol space. We're asking IANA for our own name space, so we don't
use anybody's name space. IP is a payload within lowpan, not the other way
around.

Incidentally, I see that the IANA considerations needs to be updated as it
still reflects the old field lengths of 5 or 7 for protocol type

Issue 2
---Technical work required on encapsulation/format specification: -----

NK: 

I think I understand what KiHyungKim was getting at here. Correct me if
I am wrong, his argument was that the source address also changes on a
link by link basis and just having a destination address and compressing
out the IP source and destination address will not work. We need to also
add another field that specifies a "multi hop" source address field when
the M bit is present.

---------------------------------
SC:

I don't quite understand the issue of header compression here for IPv6
case. We are doing header compression in IPv6 header, not on 802.15.4
MAC layer address. Since M bit signifies that this packet is routed in
LL2-multihop fashion, the final destination would be a MAC-address.
I don't see any header compression of final destination when M bit set.

Perhaps the draft is not clear about that in the area where it describes
LowPan unfragmented header format with M bit. The draft needs to clarify
 the final destination address type.
---------------------------------
gab:

Samita mentions that the draft is not clear as to the final destination
address type in the final destination header.
I do believe the draft is already clear in this respect:

Under Figure 9 in Section 9:

   Address: 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).

It's also mentioned several times throughout that section.

As for the main question of whether another field for the originator source
address is needed, I think there is a misunderstanding: the link-layer 
source address does not change on a hop-by-hop basis. The handling rules are:

   If a node wishes to use a forwarder to deliver a packet, it puts the
   forwarder's link-layer address in the link-layer destination address
   field.  It must also set the 'M' bit, and include a "Final
   Destination" field with the final destination's link-layer address.
   Similarly, if a node receives a frame with the 'M' bit set, it must
   look at the "Final Destination" field to determine the real
   destination.  Upon consulting its routing table, it determines what
   the next hop towards that destination should be.  The node then
   reduces the "Hops Left" field.  If the result is zero, the node
   discards the packet.  Otherwise, it puts the next hop's address in
   the link-layer destination address field, and transmits the packet.
   If upon examining the "Final Destination" field the node determines
   that it has direct reachability, it removes the "Final Destination"
   field, sets that final address as the link-layer destination address,
   and transmits the packet.

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?  

-gabriel

_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www1.ietf.org/mailman/listinfo/6lowpan