Re: [6tisch] [6lo] The "BEFORE" and "AFTER"

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Michael:



The non RPL source leaf sends a packet IPHC source = self dest = other leaf.

The 6LR adds the RPI but the IPHC and whatever comes after it stay untouched and the packet flies to the root.

The root adds IP in IP 6LoRH, the updated RPI and the RH3 6LoRH(s) but still  the IPHC and whatever comes after it stay untouched.

Packet goes down, RPI is updated, RH3-LoRH get popped out.

The last router is the one that removes the last RH3-6LoRH and ideally all of the 6LoRH is the leaf is not a RPL node.

So the leaves would not need to know the root. But as you know the support of non RPL leaves has to be fully defined.



I maintain the txt based on our discussion here: https://bitbucket.org/6lo/rpi/src/master/draft-ietf-6lo-routing-dispatch-04.txt



It has grown considerably though the meaning is hopefully unchanged from 03 apart from taking the source (that’s the root, normally) as reference for RH3 compression by default and indicating more clearly that the RPI is useful even if there is a RH3.



Early review would be appreciated and if you think that your question above is insufficiently answered please let me know ( and provide text suggestions if possible ☺)



Thanks in advance!





5.  The Routing Header Type 3 (RH3) 6LoRH Header



   ## Encoding {#RH3-6LoRH-encoding}



   The Routing Header type 3 (RH3) 6LoRH (RH3-6LoRH) header is a

   Critical 6LoWPAN Routing Header that provides a compressed form for

   the RH3, as defined in [RFC6554] for use by RPL routers.  Routers

   that need to forward a packet with a RH3-6LoRH are expected to be RPL

   routers and are expected to support this specification.  If a non-RPL

   router receives a packet with a RH3-6LoRH, this means that there was

   a routing error and the packet should be dropped so the Type cannot

   be ignored.



      0                   1

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-    -+-    -+ ... +-    -+

      |1|0|0|  Size   |6LoRH Type 0..4| Hop1 | Hop2 |     | HopN |

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-    -+-    -+ ... +-    -+



            Size indicates the number of compressed addresses



                         Figure 5: The RH3-6LoRH.



   The 6LoRH Type indicates the compression level used in a given

   RH3-6LoRH header.



   One or more 6LoRH header(s) MAY be placed in a 6LoWPAN packet.



   It results that all addresses in a given RH3-6LoRH header MUST be

   compressed in an identical fashion, down to using the identical

   number of bytes per address.  In order to get different degrees of

   compression, multiple consecutive RH3-6LoRH headers MUST be used.



   Type 0 means that the address is compressed down to one byte, whereas

   Type 4 means that the address is provided in full in the RH3-6LoRH

   with no compression.  The complete list of Types of RH3-6LoRH and the

   corresponding compression level are provided in Figure 6:



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

     |   6LoRH   | Length of compressed |

     |   Type    | IPv6 address (bytes) |

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

     |    0      |       1              |

     |    1      |       2              |

     |    2      |       4              |

     |    3      |       8              |

     |    4      |      16              |

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



                      Figure 6: The RH3-6LoRH Types.



   In the case of a RH3-6LoRH header, the TSE field is used as a Size,

   which encodes the number of hops minus 1; so a Size of 0 means one

   hop, and the maximum that can be encoded is 32 hops.  (If more than

   32 hops need to be expressed, a sequence of RH3-6LoRH elements can be

   employed.)  It results that the Length in bytes of a RH3-6LoRH header

   is:



   2 + Length_of_compressed_IPv6_address * (Size + 1)







5.1.  RH3-6LoRH General Operation



   In the non-compressed form, when the root generates or forwards a

   packet in non-Storing Mode, it needs to include a Routing Header type

   3 (RH3) [RFC6554] to signal a strict source-route path to a final

   destination down the DODAG.  All the hops along the path, but the

   first one, are encoded in order in the RH3.  The last entry in the

   RH3 is the final destination and the destination in the IPv6 header

   is the first hop along the source-route path.  The intermediate hops

   perform a swap and the Segment-Left field indicates the active entry

   in the Routing Header [RFC2460].  The current destination of the

   packet, which is the termination of the current segment, is indicated

   at all times by the destination address of the IPv6 header.



   The handling of the RH3-6LoRH is different: there is no swap, and a

   forwarding router that corresponds to the first entry in the first

   RH3-6LoRH upon reception of a packet effectively consumes that entry

   when forwarding.  This means that the size of a compressed source-

   routed packet decreases as the packet progresses along its path and

   that the routing information is lost along the way.  This also means

   that an RH3 encoded with 6LoRH is not recoverable and cannot be

   protected.



   When compressed with this specification, all the remaining hops MUST

   be encoded in order in one or more consecutive RH3-6LoRH headers.

   Whether or not there is a RH3-6LoRH header present, the address of

   the final destination is indicated in the LoWPAN_IPHC at all times

  along the path.  Examples of this are provided in Appendix A.



   The current destination (termination of the current segment) for a

   compressed source-routed packet is indicated in the first entry of

   the first RH3-6LoRH.  In strict source-routing, that entry MUST match

   an address of the router that receives the packet.



   The last entry in the last RH3-6LoRH is the last router on the way to

   the final destination in the LLN.  It is typically a RPL parent of

   the final destination, but it can also be a router acting at 6LR

   [RFC6775] for the destination host.



5.2.  Compression Reference



   In order to optimize the compression of IP addresses present in the

   RH3 headers, this specification requires that the 6LoWPAN layer

   identifies an address that is used as reference for the compression.

   With this specification, the Compression Reference for addresses

   found in an RH3 header is the source of the IPv6 packet.



   With RPL [RFC6550], an RH3 header may only be present in Non-Storing

   mode, and it may only be placed in the packet by the root of the

   DODAG, which must be the source of the resulting IPv6 packet

   [RFC2460].  In this case, the address used as Compression Reference

   is that the address of the root, and it can be implicit when the

   address of the root is.



   The Compression Reference MUST be determined as follows:



   The reference address may be obtained by configuration.  The

   configuration may indicate either the address in full, or the

   identifier of a 6LoWPAN Context that carries the address [RFC6775],

   for instance one of the 16 Context Identifiers used in LOWPAN-IPHC

   [RFC6282].



   Else, and if there is no IP-in-IP encapsulation, the source address

   in the IPv6 header that is compressed with LOWPAN-IPHC is the

   reference for the compression.



   Else, and if the IP-in-IP compression specified in this document is

   used and the Encapsulator Address is provided, then the Encapsulator

   Address is the reference.



5.3.  Coalescence



   An IPv6 compressed address is coalesced with a reference address by

   overriding the N rightmost bytes of the reference address with the

   compressed address, where N is the length of the compressed address,

   as indicated by the Type of the RH3-6LoRH header in Figure 6.



   The reference address MAY be a compressed address as well, in which

   case it MUST be compressed in a form that is of an equal or greater

   length than the address that is being coalesced.



   A compressed address is expanded by coalescing it with a reference

   address.  In the particular case of a Type 4 RH3-6LoRH, the address

   is expressed in full and the coalescence is a complete override as

   illustrated in Figure 7.





   RRRRRRRRRRRRRRRRRRRR reference address, may be compressed or not



                CCCCCCC compressed address, shorter or same as reference



   RRRRRRRRRRRRRCCCCCCC Coalesced address, same compression as reference



                      Figure 7: Coalescing addresses.



5.4.  Popping Headers



   Upon reception, the router checks whether the address in the first

   entry of the first RH3-6LoRH one of its own addresses.  In that case,

   router MUST consume that entry before forwarding, which is an action

   of popping from a stack, where the stack is effectively the sequence

   of entries in consecutive RH3-6LoRH headers.



   Popping an entry of an RH3-6LoRH header is a recursive action

   performed as follows:



   If the Size of the RH3-6LoRH header is 1 or more, indicating that

   there are at least 2 entries in the header, the router removes the

   first entry and decrements the Size (by 1).



   Else (meaning that this is the last entry in the RH3-6LoRH header),

   and if there is no next RH3-6LoRH header after this then the

   RH3-6LoRH is removed.



   Else, if there is a next RH3-6LoRH of a Type with a larger or equal

   value, meaning a same or lesser compression yielding same or larger

   compressed forms, then the RH3-6LoRH is removed.



   Else, the first entry of the next RH3-6LoRH is popped from the next

   RH3-6LoRH and coalesced with the first entry of this RH3-6LoRH.



   At the end of the process, if there is no more RH3-6LoRH in the

   packet, then the processing node is the last router along the source

   route path.



5.5.  Forwarding



   When receiving a packet with a RH3-6LoRH, a router determines the

   IPv6 address of the current segment endpoint.



   If strict source routing is enforced and thus router is not the

   segment endpoint for the packet then this router MUST drop the

   packet.



   If this router is the current segment endpoint, then the router pops

   its address as described in Section 5.4 and continues processing the

   packet.



   If there is still a RH3-6LoRH, then the router determines the new

   segment endpoint and routes the packet towards that endpoint.



   Otherwise the router uses the destination in the inner IP header to

   forward or accept the packet.



   The segment endpoint of a packet MUST be determined as follows:



   The router first determines the Compression Reference as discussed in

   Section 5.3.



   The router then coalesces the Compression Reference with the first

   entry of the first RH3-6LoRH header as discussed in Section 5.2.  If

   the type of the RH3-6LoRH header is type 4 then the coalescence is a

   full override.



   Since the Compression Reference is an uncompressed address, the

   coalesced IPv6 address is also expressed in the full 128bits.



   Packet as received by node A

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

     Type 3 RH3-6LoRH Size = 0   AAAA AAAA AAAA AAAA

     Type 1 RH3-6LoRH Size = 0                  BBBB

     Type 2 RH3-6LoRH Size = 1             CCCC CCCC

                                           DDDD DDDD



    Step 1 popping BBBB the first entry of the next RH3-6LoRH

    Step 2 next is if larger value (2 vs. 1) the RH3-6LoRH is removed



     Type 3 RH3-6LoRH Size = 0   AAAA AAAA AAAA AAAA

     Type 2 RH3-6LoRH Size = 1             CCCC CCCC

                                           DDDD DDDD



    Step 3: recursion ended, coalescing BBBB with the first entry

    Step 4: routing based on next segment endpoint to B



   Packet as received by node B

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

     Type 3 RH3-6LoRH Size = 0   AAAA AAAA AAAA BBBB

     Type 2 RH3-6LoRH Size = 1             CCCC CCCC

                                           DDDD DDDD



    Step 1 popping CCCC CCCC, the first entry of the next RH3-6LoRH

    Step 2 removing the first entry and decrementing the Size (by 1)



     Type 3 RH3-6LoRH Size = 0   AAAA AAAA AAAA BBBB

     Type 2 RH3-6LoRH Size = 0             DDDD DDDD



    Step 3: recursion ended, coalescing CCCC CCCC with the first entry

    Step 4: routing based on next segment endpoint to C



   Packet as received by node C

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



     Type 3 RH3-6LoRH Size = 0   AAAA AAAA CCCC CCCC

     Type 2 RH3-6LoRH Size = 0             DDDD DDDD



    Step 1 popping DDDD DDDD, the first entry of the next RH3-6LoRH

    Step 2 the RH3-6LoRH is removed



     Type 3 RH3-6LoRH Size = 0   AAAA AAAA CCCC CCCC



    Step 3: recursion ended, coalescing DDDD DDDDD with the first entry

    Step 4: routing based on next segment endpoint to D



   Packet as received by node D

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

     Type 3 RH3-6LoRH Size = 0   AAAA AAAA DDDD DDDD



    Step 1 the RH3-6LoRH is removed.

    Step 2 no more header, routing based on inner IP header.





               Figure 8: Forwarding packets with RH3-6LoRH.











Cheers,



Pascal



> -----Original Message-----

> From: 6lo [mailto:[e-mail]] On Behalf Of Michael Richardson

> Sent: jeudi 21 janvier 2016 16:32

> To: [e-mail]; [e-mail]

> Subject: Re: [6lo] [6tisch] The "BEFORE" and "AFTER"

>

>

> Pascal Thubert (pthubert) <[e-mail]> wrote:

>     > OK, let us see.

>

>     > With the new text I just proposed, the source (normally that’s the root)

>     > address of the packet with a RH3 is the reference for compression. So

> Ideally

>     > we’d parse that before we parse the RH3 so we can decompress the first

>     > address in the RH3. This is a change from the original text where I

> expected

>     > the first address in the RH3 to be mostly in the full. So in 6LoRH form, IP

>     > in IP would come before the RH3.

>

> So, in the case of traffic that flows from one leaf to another leaf, would

> either end actually know the IP of the root?  I think that the RPL daemon

> would have to program them.

>

> --

> Michael Richardson <[e-mail]>, Sandelman Software Works

> -= IPv6 IoT consulting =-

>

>