Subject: [6lo] Suggestions for draft-thubert-6lo-routing-dispatch-01

From: Robert Cragie <[email-masked]>
Date: Tue, 13 Jan 2015 12:42:12 +0000

Hi Pascal,

I was looking through draft-thubert-6lo-routing-dispatch-01 again and I 
still find the 'I' bit confusing (especially in conjunction with RPI, 
where there is another 'I' bit). So I think it would make sense to 
consider two basic dispatch types. I have nominally called them 
"Elective" and "Critical" but you may think of better terms. "Elective"
is the I = 1 case, where the remaining 5 bits explicitly indicate the 
length to a parser can choose to skip it if it doesn't understand the 
type. "Critical" is the I = 0 case. I also expanded a bit on the 
placement of the 6LoRH.

Here is a suggested rewrite of Section 4:

<section>
4.  General Format

     The 6LoWPAN Routing Header (6LoRH) reuses the bit patterns that are 
defined in [RFC4944] for the Mesh Header, specifically the Dispatch 
Value Bit Pattern of 10xxxxxx.  It may contain source routing 
information such as a compressed form of RH3, or other sorts of routing 
information such as the RPL RPI, source and/or destination address, and 
is extensible for future uses, with the given example of BIER bitmap 
encoding in Section 9.

     There are two forms for 6LoRH:

     o Elective (6LoRHE)
     o Critical (6LoRHC)

4.1 Elective Format (6LoRHE)

     The 6LoRHE uses the Dispatch Value Bit Pattern of 101xxxxx.  A 
6LoRHE may be ignored and skipped in parsing.  If it is ignored, the 
6LoRHE is forwarded with no change inside the LLN.

         0                   1
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    .....   +-+
        |1|0|1| Length  |      Type     |              |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    .....   +-+
                                         <-- Length -->

                       Figure 2: Elective 6LoWPAN Routing Header

     Length
           Length of the 6LoRHE expressed in bytes, excluding the first 
2 bytes. This is done to enable a node to skip a 6LoRH that it does not 
support and/or cannot parse, for instance if the Type is unknown.

     Type
           Type of the 6LoRHE

4.2 Critical Format (6LoRHC)

     The 6LoRHC uses the Dispatch Value Bit Pattern of 100xxxxx.  A node 
which does not support the 6LoRHC Type MUST silently discard the packet 
(note that there is no provision for theexchange of error messages; such 
a situation should be avoided by judicious use of administrative control 
and/or capability indications).

         0                   1
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ......................... +-+
        |1|0|0|   TSE   |      Type |                                  |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ......................... +-+
                                         <-- Length implied by Type/TSE -->

                       Figure 3: Elective 6LoWPAN Routing Header

     TSE
           Type Specific Extension.  The meaning depends on the Type, 
which must be known in all of the nodes.  The interpretation of the TSE 
depends on the Type field that follows. For instance, it may be used to 
transport control bits, the number of elements in an array, or the 
length of the remainder of the 6LoRHC expressed in a unit other than bytes.

     Type
           Type of the 6LoRHE

4.3 Placement of 6LoRH

     One or more 6LoRHs MAY be placed in a 6LoWPAN packet and MUST 
always be placed before the LOWPAN_IPHC [RFC6282].  A 6LoRH MAY be used 
in conjunction with a Fragmentation Type and Header [RFC4944] in three ways:

     o Before the Fragmentation Type and Header
     o Before and after the Fragmentation Type and Header
     o After the Fragmentation Type and Header

     Headers are processed in order so if a 6LoRH is processed that is 
sufficient to route a packet, then there is no need for the intermediate 
node to process the packet further.

4.3.1 6LoRH before Fragmentation Type and Header

     | 6LoRH | Frag1 | IPHC | Payload Frag1 |
     | 6LoRH | FragN | Payload Frag2 |
     | 6LoRH | FragN | Payload Frag3 |...

     If a 6LoRH is placed before a Fragmentation Type and Header, the 
fragments can be routed individually.

4.3.2 6LoRH after Fragmentation Type and Header

     | Frag1 | 6LoRH | IPHC | Payload Frag1 |
     | FragN | Payload Frag2 |
     | FragN | Payload Frag3 |...

     If a 6LoRH is placed after a Fragmentation Type and Header, the 
fragments cannot be individually routed and the whole IPv6 packet needs 
to be reassembled at every LLN hop.
</section>

Comments or questions? Given some of the discussion on the mailing list, 
maybe the "Placement of 6LoRH" section could be enhanced further.

Robert