Subject: [6lowpan] post-IETF-last-call fix: Extending the Datagram-Tag

From: Carsten Bormann <[email-masked]>
Date: Mon, 19 Mar 2007 16:26:17 +0100

As was discussed previously on the mailing list, the datagram-tag  
size was a bit aggressively small at 10 bits, which got us another  
DISCUSS comment.

Datagram-Tags need to be unique over the time a receiver keeps  
fragments for reassembly, and Geoff has calculated a sender could  
only use half a 256 kbit/s link with 10 bits of datagram-tag, a  
situation that would become worse with the faster links in the pipeline.

So we need to add a byte.  What do we do with the 8 new bits?
Allocate them all to the datagram-tag?  This provides some future- 
proofing, but we only really need 4 or 5 bits in the immediate future.
We couldn't quite figure out what to do with any "reserved bits" so  
far, so the mailing list consensus so far was to use all 8 bits.

This leads to a somewhat awkward tag size of 18 bits.
In the meeting today, we discussed cutting back to 16, reshuffling  
the header to obtain alignment, and assigning the two "reserved bits"  
to the header type discriminator.  Simpler to implement, and future- 
proofing in a different way (by leaving bits for extensions).

The text proposal below does not attempt to fix the ambiguity of:

       The sender SHALL increment datagram_tag for successive,  
fragmented
       datagrams.

If anyone thinks this is absolutely required, they should define  
whether this is a single value per sender, incremented for every new  
datagram, or whether a sender has to keep (indefinitely!?) per- 
receiver counters.

Separate from this detail, if there are any issues with the text  
proposed below, we need to know quickly.

Gruesse, Carsten

OLD:
                            1                   2
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |1 1 0|    datagram_tag   |    datagram_size    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                          Figure 10: First Fragment

NEW:
                            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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |1 1 0 0 0|    datagram_size    |         datagram_tag          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                          Figure 10: First Fragment

OLD:
                            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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |1 1 1|    datagram_tag   |    datagram_size    |datagram_offset|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 11: Subsequent Fragments

NEW:
                            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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |1 1 1 0 0|    datagram_size    |         datagram_tag          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |datagram_offset|
       +-+-+-+-+-+-+-+-+

                       Figure 11: Subsequent Fragments

OLD:
    datagram_tag:  The value of datagram_tag (datagram tag) SHALL be the
       same for all link fragments of a payload (e.g., IPv6) datagram.
       The sender SHALL increment datagram_tag for successive,  
fragmented
       datagrams.  The incremented value of datagram_tag SHALL wrap from
       1023 back to zero.  This field is 10 bits long, and its initial
       value is not defined.

NEW:
    datagram_tag:  The value of datagram_tag (datagram tag) SHALL be the
       same for all link fragments of a payload (e.g., IPv6) datagram.
       The sender SHALL increment datagram_tag for successive,  
fragmented
       datagrams.  The incremented value of datagram_tag SHALL wrap from
       65535 back to zero.  This field is 16 bits long, and its initial
       value is not defined.

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

---

From: gabriel montenegro <[email-masked]>
Date: Mon, 19 Mar 2007 23:46:47 -0700 (PDT)

Ok, I've made this change per Carsten's original suggestion. I also moved the description of the datagram_tag 
field after that of datagram_size, to reflect their new order in the header.

-gabriel

----- Original Message ----
From: Carsten Bormann <[email-masked]>
To: David Culler <[email-masked]>
Cc: Carsten Bormann <[email-masked]>; [email-masked]
Sent: Monday, March 19, 2007 10:37:44 AM
Subject: Re: [6lowpan] post-IETF-last-call fix: Extending the Datagram-Tag

On Mar 19 2007, at 18:00, David Culler wrote:

> They should be reserved and undefined at this stage

But this is exactly what the proposed text says -- it only defines  
the 11000 and 11100 prefixes, and all other bit combinations are not  
defined.

I would not want to pre-suppose 11xNN needs to be a Fragmentation  
header -- it might be something completely different.

(Maybe I don't understand your concern.)

BTW, this also touches on the IESG comment below.

Gruesse, Carsten

#################################
* Editorial 1

 From Gen-ART review by Joel Halpern:

         I don't know that I have ever seen a document before that  
says "thou
shalt not extend this."  (Section 5, last sentence before 5.1, "All  
headers used
in LOWPAN adaptation layer SHALL be defined in this format document.")

===> INTERPRET COMMENT
My view of this is that this is indeed the intention. Of course,
evolving this spec itself should be possible.  Note that this would
require some version management, which will need to be addressed by
bootstrapping.