Subject: [6lowpan] format document issues

From: "Kushalnagar, Nandakishore" <[email-masked]>
Date: Thu, 6 Oct 2005 13:15:44 -0700

All,

I took a first stab in addressing some of the issues in the current
specifications of the 6lowpan format document. Please send suggestions
on the list.

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?

Issue 2

Technical work required on encapsulation/format specification: 

Some discussion ensued about the M-bit and the compression of source
addresses in a multi-hop environment. As this discussion could not be
completed on-line, KiHyungKim <http://6lowpan.tzi.org/KiHyungKim>  will
send an example scenario where this matters to the mailing list.
[6lowpan at IETF 63 <http://6lowpan.tzi.org/6lowpan_20at_20IETF_2063> ] 

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.

I would suggest the following change for the current format when M bit
is 1:

       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 2
3 4 5 6 7 8 9 0

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+

      | LF|prot_type|M|    Multihop source address | Multihop
Destination Address|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+

Where multihop source and destination addresses correspond to source and
final destination address.

Regards,

Nandu

_______________________________________________
6lowpan mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/6lowpan

---

From: Samita Chakrabarti <[email-masked]>
Date: Tue, 11 Oct 2005 14:50:16 -0700 (PDT)

> 
> Issue 2
> ---Technical work required on encapsulation/format specification: -----
> 
> NK: 
> 
> ---------------------------------
> 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.
> 

After going back to the old mails in the alias, I think I understood 
now what KiHyungKim was trying to point at. 

------------email excerpt from KiHyungKim in Aug 10----------------
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.

--------------------------------------------------------------------

So, the main concern is how to report the error back.
He also mentioned LOAD as a routing protocol.  I think we should not
add originator source address in the LowPan header - we are already
short in payload length. The use of 'final destination' is needed,
but not the 'originator source MAC address'. For example, when AODV
RREQ is received at each intermediate node, it can extract the originator
MAC address from the AODV packet and build a reverse route towards
the orginator node. In the above example, node C will keep a reverse-route
table ( in order to go to A next hop is B). When link between C and D
breaks, during multihop data transfer, C can propagate that error back
to the originator node by using multihop in the reverse direction.

Thus, when M bit is set, we assume that intermediate nodes between 
two end-nodes will also use multi-hop routing (and discovery if needed)
to propagate the error back to the originator. 

The format document, may explain the above situation and recommend that
the underlying multihop routing protocol should be such that it should
optimize multihopping in the reverse direction as well - Thus we can
save 8 valuable bytes from the lowpan header.

The lowpan M bit and forwarding concept is perhaps quite similar to
draft-perlman-rbridge-03.txt where the shim-header contains the egress
rbridge's address for unicast routing.

Thanks,
-Samita

---

From: Samita Chakrabarti <[email-masked]>
Date: Wed, 12 Oct 2005 18:21:23 -0700 (PDT)

>I *think* we're repeating each other. From my post:

Sorry, if I am repeating myself. I agree with you on the following
item.  All I said, that there's no need to add extra field for
originator address and we can change the source MAC address at each
lowpan-hop as well. 
> 
> > 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.
> 
> So we don't even have to require "the routing protocol to provide information
> on originator address so that the intermediate node can setup reverse route."
> The required info is already in the RREQ, right? 

Sure, the required info is within the RREQ.  But that assumes we use
AODV, LOAD, DYMO etc. which already use RREQ. Since Lowpan layer is not
tying up with any particular routing protocol, hence someone in future
can try to develop a new routing protocol that might be different than
what we expect today at RREQ. Thus, clarifying that requirement will
help the implementors today as to how to setup the reverse lowpan-route and 
lowpan-routing protocol developers in the future. That's all.

Thanks,
-Samita