Subject: [Roll] Use of tunnels and end point determication

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 9 Jul 2010 12:00:06 +0200

Dear WG:

It might not strike the eye going through the base spec but most packets that fly through a RPL network are encapsulated, IP in IP. The generic reason is the need to insert /  remove the Hop by hop header defined draft-hui-6man-rpl-option. There’s also the need for the root to insert a routing header in non-storing mode. This is what we can call tunnel mode.

This seems true for packets originating outside or terminating outside the RPL network. An exception to this rule could be packets that will be from and to routers or leaves of a same RPL network, because in that case, the originator can place the Hop by hop and eventually the routing header as it forms the packet, without IP in IP encapsulation. Something we could call transport mode, or native mode, or insider mode ?

Anyway it appears that the spec could be clearer in:

1.       Explaining why IP in IP is used in general

2.       Specifying the rules to determine if a destination is inside the RPL network

3.       Specifying tunnel mode operation

4.       Specifying transport mode operation and when it can be used

5.       Specifying how to determine the tunnel endpoint in tunnel mode

Proposal:

1)      RPL needs an instance ID in the flow label, and HbH header, and eventually a routing header in every packet for routing and inconsistency determination. The HbH and RH are nonsensical outside the RPL network and can only be present inside the RPL network. The only clean way to insert and remove those headers is to use a tunnel mode (IP in IP encapsulation) whereby the router places the RPL headers before the inner header, leaving the original packet untouched.

a.       A source inside the RPL network (router or leaf) places the RPL headers and flow label in the packet, either in tunnel or transport mode.

b.      For packets originated outside the RPL network, the first RPL router (called ingress router) has to place this information in the packet in tunnel mode

c.       Further RPL routers find the information and use it. They do not re-encapsulate, they do not change the flow label, they happen to modify the RPL headers.

d.      The tunnel endpoint decapsulates before forwarding the inner packet. This strips the RPL information from the packet. If the packet is reinserted into the RPL network then there is a risk of a loop. 

2)      A destination is in the same RPL network if:

a.       The destination is the root of the DODAG (all modes)

b.      The destination is in the same Subnet as the source (derived from a PIO)  (storing mode only) 

c.       The node is a router that has a DAO state indicating that the destination is a child (storing mode only)

d.      The destination has been seen as tunnel endpoint and thus is a DAO ancestor (storing mode only).

3)      A RPL router that injects a packet without the HbH option into the RPL network is an ingress router.  

a.       An ingress router MUST place the RPL information in the packet in tunnel mode

b.      An ingress router MUST place the instance ID in the flow label of the outer header

c.       An ingress router MUST use one of its global addresses from the RPL domain as source

d.      An ingress router MUST use a tunnel endpoint that is in the same RPL network (rules above).

4)      A RPL node MUST place the RPL information in every packet that is sources. It can safely use tunnel mode for all packets. It MAY use transport mode when it determines that the destination is a RPL leaf or router within the same RPL network. In transport mode, the outer headers are built as follows: 

a.       The source MUST place the instance ID in the flow label of the IPv6 header

b.      The source MUST use one of its global addresses from the RPL domain as source

c.       The destination MUST be is in the same RPL network (rules above).

5)      The tunnel endpoint is determined as follows:

a.       If the destination is in the RPL network (rules above) then the endpoint is the destination

b.      If the destination is a host attached to a RPL router then the endpoint is that RPL router

c.       Else the endpoint is the root

It appears that the b) is not supported correctly with the current spec since we do not have a way to inject a route to an external host while indicating that the host is not a leaf.

Probably the router would present itself as parent in a transit option, with a bit saying that the targets as non rpl hosts.

Opinions?

Pascal Thubert
IPv6 Engineering
Product Development
[email-masked] <mailto:[email-masked]> 
Phone: +33 4 9723 2634
Mobile: +33 6 1998 2985

Cisco Systems France
Village d'Entreprises Green Side
400 Avenue de Roumanille 
Batiment T 3 
06410 
BIOT - SOPHIA ANTIPOLIS
France
Cisco.com <http://www.cisco.com/global/FR/> 

 Think before you print.

Cisco Systems France, Société à responsabiité limitée, Rue Camille Desmoulins – Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy les Moulineaux, Au capital de 91.470 €, 349 166 561 RCS Nanterre, Directeur de la publication: Jean-Luc Michel Givone, For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html <http://www.cisco.com/web/about/doing_business/legal/cri/index.html>

---

From: Richard Kelsey <[email-masked]>
Date: Fri, 09 Jul 2010 08:10:45 -0400

> Date: Fri, 9 Jul 2010 12:00:06 +0200
> From: "Pascal Thubert (pthubert)" <[email-masked]>
> 
> 1) RPL needs an instance ID in the flow label, and HbH header, and
> eventually a routing header in every packet for routing and
> inconsistency determination. The HbH and RH are nonsensical outside
> the RPL network and can only be present inside the RPL network. The
> only clean way to insert and remove those headers is to use a tunnel
> mode (IP in IP encapsulation) whereby the router places the RPL
> headers before the inner header, leaving the original packet
> untouched.

Another clean way to do this would be to insert a non-IPv6
header in front of the IPv6 header, as MPLS does.  This
would be simple to do in a 6lowpan network and add less
overhead than using an IP in IP tunnel with the hop-by-hop
header.

The core RPL draft should allow this type of solution.

                                        -Richard

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 9 Jul 2010 14:50:26 +0200

Hi Richard:

RPL code only deals with native IP operations, so it does tunneling.
OTOH I do not wish to preclude any operation like the one you are
describing and I hope some specification will define it somewhere.
Do you see text that would bar or be problematic with this operation and
if so would you propose a modification to that text?

Cheers,

Pascal

> -----Original Message-----
> From: Richard Kelsey [mailto:[email-masked]]
> Sent: Friday, July 09, 2010 2:11 PM
> To: Pascal Thubert (pthubert)
> Cc: [email-masked]
> Subject: Re: [Roll] Use of tunnels and end point determication
>

---

From: Richard Kelsey <[email-masked]>
Date: Fri, 09 Jul 2010 09:36:45 -0400

> Date: Fri, 9 Jul 2010 14:50:26 +0200

Pascal,

Here is one example:

   A router that injects a data packet into the RPL network
   MUST tag the packet by inserting a RPL Hop-by-hop option
   as specified in [I-D.hui-6man-rpl-option].  If the
   RPLInstanceID is not present in flow label of the data
   packet, the ingress router that injects the packet into
   the RPL network MUST add a RPLInstanceID field to the RPL
   Hop-by-hop option.

I am not sure what the best way to handle this would be.

Your original email indicated that the draft would benefit
from a fair amount of additional text describing the details
of how the IP in IP tunnelling is to  be done.  On the other
hand, if the tunnelling is optional, perhaps that text should
go in another document?  The RPL draft could limit itself to
describing the RPL Packet Information and its use, without
going into the details as to how the RPL Packet Information
is carried within a packet.
                                    -Richard Kelsey

---

From: "Mathilde Durvy (mdurvy)" <[email-masked]>
Date: Fri, 9 Jul 2010 15:50:18 +0200

Hi Pascal,

This is an important issue. Some comments/questions below.

Best,

Mathilde

Proposal:

Aren’t the flow label and HbH header mutually exclusive? Shouldn’t we force the use of the HbH within the RPL network? More alternatives mean more complexity. Why would a source inside RPL use tunnel mode? (see also comments below) 

In non-storing mode, how does this scenario work?

Host – RPL ingress router (must include HbH)… RPL routers … RPL root (must include source route in addition to HbH, can it do it in the same IPv6 header?) … RPL router … RPL route (decapsulation) - Host

 

Not sure what you mean by the last point. 

Doesn’t d. contradicts “The last entry, Address[n], is exempt from the strict source route policy and may specify a destination outside the RPL domain” from the rpl-routing-header draft? I think this also impact your point 4 and 5…

Opinions?

	

Pascal Thubert
IPv6 Engineering
Product Development
 <mailto:[email-masked]> [email-masked]
Phone: +33 4 9723 2634
Mobile: +33 6 1998 2985

Cisco Systems France
Village d'Entreprises Green Side
400 Avenue de Roumanille 
Batiment T 3 
06410 
BIOT - SOPHIA ANTIPOLIS
France
 <http://www.cisco.com/global/FR/> Cisco.com

Think before you print.Think before you print.

Cisco Systems France, Société à responsabiité limitée, Rue Camille Desmoulins – Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy les Moulineaux, Au capital de 91.470 €, 349 166 561 RCS Nanterre, Directeur de la publication: Jean-Luc Michel Givone, For corporate legal information go to:
 <http://www.cisco.com/web/about/doing_business/legal/cri/index.html> http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Michael Richardson <[email-masked]>
Date: Fri, 09 Jul 2010 09:59:06 -0400

>>>>> "Pascal" == Pascal Thubert <(pthubert)" <[email-masked]>> writes:
    Pascal> It might not strike the eye going through the base spec but
    Pascal> most packets that fly through a RPL network are
    Pascal> encapsulated, IP in IP. The generic reason is the need to
    Pascal> insert / remove the Hop by hop header defined

I read the draft.
I don't understand why the RPL Hop-by-Hop option can not added by the
first RPL router.  

    Pascal> Anyway it appears that the spec could be clearer in:

    Pascal> 1.  Explaining why IP in IP is used in general

    Pascal> 2.  Specifying the rules to determine if a destination is
    Pascal> inside the RPL network

That's could be hard.

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 9 Jul 2010 16:20:00 +0200

Hi Michael
 
> I don't understand why the RPL Hop-by-Hop option can not added by the

[Pascal] Well, it is added by the first RPL router. Did you find a
contradiction? If so we must fix it.

>     Pascal> inside the RPL network

[Pascal] The point is, if you can't determine that it is, then you have
to assume that it is not and tunnel. This might cause to go to the root
and back down in a different tunnel... In the case where the RPL network
is an IPv6 subnet, it's pretty easy though, so it would be sad to miss
the optimization.

> ] [email-masked] http://www.sandelman.ottawa.on.ca/
|device
> driver[
>    Kyoto Plus: watch the video
> <http://www.youtube.com/watch?v=kzx1ycLXQSE>
> 	               then sign the petition.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 9 Jul 2010 17:42:47 +0200

Proposal:

[Pascal] -10 allows both but it seems redundant. Since the instance has to be in the flow label for an end point to indicate it, then why not let it there all the time? If the ingress router has to figure out the instance ID by some magic, in any fashion it can place the result in the flow label.

Host – RPL ingress router (must include HbH)… RPL routers … RPL root (must include source route in addition to HbH, can it do it in the same IPv6 header?) … RPL router … RPL route (decapsulation) – Host

[Pascal] In non-storing, the nodes will always tunnel to the root. The root decaps, and route the packet; if the destination is in the RPL network, the root reencaps, this time with a routing header.

 

[Pascal] trick, and actually not tunnel endpoint but transport mode endpoint. A node does not know its ancestors, so it would tunnel if they are not in the same subnet. But the ancestor knows the grand grand child, so it would use transport mode. So we end up with a triangular routing where the child tunnels to the root, the root tunnel to the ancestor, and the ancestor uses transport mode down. if someone uses transport mode with you, you can use transport mode with him… If you care to implement such optimization.

[Pascal] The texts does not apply to RPL but is apparently safe in routing headers at large. RPL cannot use transport mode to an external destination because of the use of the hop by hop option.  

[Pascal] Thanks a bunch for your comments. Let’s keep the pipe more open than ever since we are in last call now!

Opinions?

Pascal Thubert
IPv6 Engineering
Product Development

Cisco Systems France

 Think before you print.

---

From: Richard Kelsey <[email-masked]>
Date: Fri, 09 Jul 2010 12:31:43 -0400

> Date: Fri, 9 Jul 2010 17:42:47 +0200
> [Pascal] -10 allows both but it seems redundant. Since the instance
> has to be in the flow label for an end point to indicate it, then why
> not let it there all the time? If the ingress router has to figure out
> the instance ID by some magic, in any fashion it can place the result
> in the flow label.

Pascal,

I don't see how this works.  The RPL draft says:

   If the RPLInstanceID is not present in flow label of the
   data packet, the ingress router that injects the packet
   into the RPL network MUST add a RPLInstanceID field to
   the RPL Hop-by-hop option.

How does the ingress router determine whether or not the
flow label contains a RPLInstanceID?  It isn't safe to
assume that any non-zero flow label is necessarily a
RPLInstanceID.
                                   -Richard

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 12 Jul 2010 10:30:42 +0200

Hi Richard:

I agree there's no magic. The ingress router must have a policy of some
sort that indicates how the system is expected to work. 

The policy can say that the flow label in the ingress packet has the
instanceID already, or that the instanceID is derived by some specified
computation from the IP header or even deep packet inspection that would
recognize the application flows. All of those methods are already
practiced for route mapping and traffic engineering, in particular for
voice and video. I think I mentioned earlier that there is a lot in
common between sensor data and voice though the scale is different.

In the end, the result is always the same and that's where our own
specification comes into play. We remark that with the HbH and the RH,
all incoming packets are encapsulated. If so, the ingress router owns
the outer IP header, so it can safely place the instanceID in the flow
label all the time, which makes our spec simpler. 

->

    An  ingress router that injects packets into the RPL network
    has to encapsulate the packet IP in IP to add the RPL 
    Hop-by-hop option and eventually a Routing header. 
    The ingress router MUST add a RPLInstanceID field to the
    flow label of the outer header.

For short term, I expect 3 forms of policies:

- single instance (0): The all RPL network has only one instance, that
is well known by all routers, probably 0.
- flow label: The endpoints are aware of an abstraction of the instance
and place it in the flow label. The ingress router copies the flow label
from inner to outer header and route along that instance. 
- destination: When all traffic flows via a root from/to an
infrastructure. A given root has only one DODAG to its uses the
associated instance.  An ingress router at the edge of the network
matches DODAGID and RIO routes, and picks the instanceID that has the
longest match. In it not unlawful to have a RIO with default route to
indicates the highest preference DODAG for default as well.

There can be tons of other policies, like there can be numerous OCP/OF.
What's key for us is that we know which node is responsible to place the
instance ID in the packet and where it places it, so we can safely use
it through the RPL network.

Pascal

> Sent: Friday, July 09, 2010 6:32 PM
> Cc: Mathilde Durvy (mdurvy); [email-masked]
> How does the ingress router determine whether or not the flow label
contains a
> RPLInstanceID?  It isn't safe to assume that any non-zero flow label
is
> necessarily a RPLInstanceID.
>                                    -Richard

---

From: JP Vasseur <[email-masked]>
Date: Mon, 12 Jul 2010 18:42:52 +0200

Hi Pascal,

I think that you really complicated what is indeed much more simple.  
Let work on a text with illustrations that
will show the overall picture. I'll call you.

JP.

On Jul 9, 2010, at 12:00 PM, Pascal Thubert (pthubert) wrote:

> Dear WG:
>
> It might not strike the eye going through the base spec but most  
> packets that fly through a RPL network are encapsulated, IP in IP.  
> The generic reason is the need to insert /  remove the Hop by hop  
> header defined draft-hui-6man-rpl-option. There’s also the need for  
> the root to insert a routing header in non-storing mode. This is  
> what we can call tunnel mode.
> This seems true for packets originating outside or terminating  
> outside the RPL network. An exception to this rule could be packets  
> that will be from and to routers or leaves of a same RPL network,  
> because in that case, the originator can place the Hop by hop and  
> eventually the routing header as it forms the packet, without IP in  
> IP encapsulation. Something we could call transport mode, or native  
> mode, or insider mode ?
>
> 1)      RPL needs an instance ID in the flow label, and HbH header,  
> and eventually a routing header in every packet for routing and  
> a.       A source inside the RPL network (router or leaf) places the  
> RPL headers and flow label in the packet, either in tunnel or  
> transport mode.
> b.      For packets originated outside the RPL network, the first  
> RPL router (called ingress router) has to place this information in  
> the packet in tunnel mode
> c.       Further RPL routers find the information and use it. They  
> do not re-encapsulate, they do not change the flow label, they  
> happen to modify the RPL headers.
> d.      The tunnel endpoint decapsulates before forwarding the inner  
> packet. This strips the RPL information from the packet. If the  
> packet is reinserted into the RPL network then there is a risk of a  
> loop.
>
> c.       The node is a router that has a DAO state indicating that  
> the destination is a child (storing mode only)
> 3)      A RPL router that injects a packet without the HbH option  
> into the RPL network is an ingress router.
> 4)      A RPL node MUST place the RPL information in every packet  
> that is sources. It can safely use tunnel mode for all packets. It  
> MAY use transport mode when it determines that the destination is a  
> RPL leaf or router within the same RPL network. In transport mode,  
> the outer headers are built as follows:
> It appears that the b) is not supported correctly with the current  
> spec since we do not have a way to inject a route to an external  
> host while indicating that the host is not a leaf.
> Probably the router would present itself as parent in a transit  
> option, with a bit saying that the targets as non rpl hosts.
>
> Opinions?
>
>
> Pascal Thubert
> IPv6 Engineering
> Product Development
> [email-masked]
> Phone: +33 4 9723 2634
> Mobile: +33 6 1998 2985
>
>
> Cisco Systems France
> Cisco.com
> Cisco Systems France, Société à responsabiité limitée, Rue Camille  
> Desmoulins – Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy les  
> Moulineaux, Au capital de 91.470 €, 349 166 561 RCS Nanterre,  
> Directeur de la publication: Jean-Luc Michel Givone, For corporate  
> legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
>
>
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: "Mathilde Durvy (mdurvy)" <[email-masked]>
Date: Thu, 15 Jul 2010 13:31:21 +0200

Hi Pascal, All,

Let me know if this is a correct summary of the possible cases. I also put some comments to point things where I think a clarification is needed.

1)    RPL S  à BR à D                 No tunnel, the RPL source adds the HbH header, BR removes it

2)    S à RPL R à BR à D         Tunnel. R introduces new IPv6 header with HbH header, R is the IPv6 source, BR the IPv6 dest. BR removes this header. 

Comment: If BR is the end of the tunnel, its address needs to be known by R. How does that work? This would favor an approach where the DODAGID must be the global IPv6 address of the root

3)    RPL D ß BR ß S                  Tunnel. BR introduces new IPv6 header with HbH header and RH (non-storing mode only), BR is the IPv6 source, and RPL D the final dest in the RH. 

4)    D ß RPL R ß BR ß S         Tunnel. BR introduces new IPv6 header with HbH header and RH (non-storing mode only), BR is the IPv6 source, and RPL R the final dest in the RH. R decapsulates and sends to D.

Comment: This would work if R sends DAO with target D and transit “the parent of R”: I think this is a bit different than your approach in 5b. Also, I have the impression that according to “The last entry, Address[n], is exempt from the strict source route policy and may specify a destination outside the RPL domain”, D address could be the last address in the RH but I’m not sure how this would work. If this text does not apply to tunnel mode as you point below, we should say so.

5)    S à RPL R1 à BR à RPL R2 à D             Tunnel. R1 introduces new IPv6 header with HbH header, R1 is the IPv6 source, 

BR the IPv6 dest. BR removes this header. Encapsulates with new IPv6 header with HbH header and RH (non-storing mode only), BR is the IPv6 source, and RPL R2 the final dest in the RH. 

Comment: I guess this vision contradicts your point 5a. Seems simpler to me, but maybe I’m missing something.

Note that if the above is correct, the only information needed by RPL nodes is the global address of the BR (i.e. the root). So it seems that 2 below might not be needed

Best,

Mathilde

From: Pascal Thubert (pthubert) 
Sent: vendredi, 9. juillet 2010 17:43
To: Mathilde Durvy (mdurvy); 'ROLL WG'
Subject: RE: [Roll] Use of tunnels and end point determication

 

Proposal:

 

 

Opinions?

	

Pascal Thubert
IPv6 Engineering
Product Development

Cisco Systems France

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 16 Jul 2010 17:29:21 +0200

Hi Mathilde

Pascal

From: Mathilde Durvy (mdurvy) 
Sent: Thursday, July 15, 2010 1:31 PM
To: Pascal Thubert (pthubert); 'ROLL WG'
Subject: RE: [Roll] Use of tunnels and end point determication

Hi Pascal, All,

[Pascal] Surprised me quite a bit but correct. This amends my earlier mail of mine where I thought we had to tunnel there. My sentence “RPL cannot use transport mode to an external destination because of the use of the hop by hop option” was apparently wrong, and we can lawfully remove the hop by hop inside the packet.

[Pascal] Correct, though we do not really well support a host attached to the RPL network. In particular the lack of DAO sequence etc… 

Make sense to me for all nodes to be leaves.

[Pascal] Correct

[Pascal] correct

[Pascal] Hum…  “the parent of R” would look up D onlink and would not find it. R needs to set itself as transit parent and D as target. For a RPL router or leaf, and to enable a better compression we let the tunnel end at the target but for a non RPL host that cannot be. So we need R to flag in the DAO that R is the tunnel endpoint for D as opposed to D itself. You’ll note that for each of R’s addresses that are not onlink for “the parent of R”, R has to advertise self as parent, using in the transit an address that is onlink to its own parent.

[Pascal] I hope we are not in contradiction : ) This is correct in non storing. In storing, the packet doesn’t need to go to the root and even if it does, the root is just another common parent and forwards down. There is no decap reencap in that case. But to determine that you can bypass the root, you have to figure that the destination is a leaf or a router of the same RPL network, which is not obvious. If we do not have plain hosts but just RPL routers and leaves in a same subnet, then it is a lot easier. 

[Pascal] If we do the above for storing, we lose the advantage of routing via the common parent…

Best,

Mathilde

 

Proposal:

 

 

Opinions?

Pascal Thubert
IPv6 Engineering
Product Development

Cisco Systems France

 Think before you print.

---

From: "Mathilde Durvy (mdurvy)" <[email-masked]>
Date: Mon, 19 Jul 2010 09:57:02 +0200

Hi Pascal,

This looks good! It seems we are in agreement.

Some comments below.

Best,

Mathilde

Hi Pascal, All,

[Mathilde] Just one point how are we planning to distribute the address of the root to all RPL routers?

[Pascal] Correct

[Pascal] correct

[Mathilde] Agree. So what do we do with the sentence quoted above? It is kind of confusing.

[Mathilde] Agree

[Mathilde] Agree

---

From: Daniel Gavelle <[email-masked]>
Date: Mon, 19 Jul 2010 09:26:06 +0100

Mathilde / Pascal,

The summary below is good and needs to be added to one of the RPL 
drafts.  I have a few remaining questions:-

What happens in the case BR ->  RPL when non storing?   Do we just have 
HbH and RH or is tunnelling required.

Is the HbH mandatory when going from the BR->RPL when non storing?  The 
RH is all that is required to reach a destination and the packet 
arriving from a parent confirms the path from the parent is still available.

Has it been agreed that we use HbH rather than the flow label in all 
circumstances?

The case (2) below is likely to be required by Zigbee hosts that support 
ND but not RPL.  Ensuring the DODAG ID is the address of the root solves 
this problem and also allows DAO's to be sent directly to the root in a 
non storing network.

Daniel.

Mathilde Durvy (mdurvy) wrote:
> *From:* Mathilde Durvy (mdurvy)
> *Sent:* Thursday, July 15, 2010 1:31 PM
> *To:* Pascal Thubert (pthubert); 'ROLL WG'
> *Subject:* RE: [Roll] Use of tunnels and end point determication
> 
>  
> 
> Hi Pascal, All,
> 
>  
> 
> Let me know if this is a correct summary of the possible cases. I also 
> put some comments to point things where I think a clarification is needed.
> 
>  
> 
> */[Pascal] Surprised me quite a bit but correct. This amends my earlier 
> mail of mine where I thought we had to tunnel there. My sentence “RPL 
> cannot use transport mode to an external destination because of the use 
> of the hop by hop option” was apparently wrong, and we can lawfully 
> remove the hop by hop inside the packet./*
> 
>  
> 
> 2)    S à RPL R à BR à D         Tunnel. R introduces new IPv6 header 
> with HbH header, R is the IPv6 source, BR the IPv6 dest. BR removes this 
> header.
> 
> Comment: If BR is the end of the tunnel, its address needs to be known 
> by R. How does that work? This would favor an approach where the DODAGID 
> must be the global IPv6 address of the root
> 
> */[Pascal] Correct, though we do not really well support a host attached 
> to the RPL network. In particular the lack of DAO sequence etc… /*
> 
> */Make sense to me for all nodes to be leaves./*
> 
> 3)    RPL D ß BR ß S                  Tunnel. BR introduces new IPv6 
> header with HbH header and RH (non-storing mode only), BR is the IPv6 
> source, and RPL D the final dest in the RH.
> 
> */[Pascal] Correct/*
> 
>  
> 
> 4)    D ß RPL R ß BR ß S         Tunnel. BR introduces new IPv6 header 
> with HbH header and RH (non-storing mode only), BR is the IPv6 source, 
> and RPL R the final dest in the RH. R decapsulates and sends to D.
> 
> */[Pascal] correct/*
> 
> Comment: This would work if R sends DAO with target D and transit “the 
> parent of R”: I think this is a bit different than your approach in 5b. 
> Also, I have the impression that according to “The last entry, 
> Address[n], is exempt from the strict source route policy and may 
> specify a destination outside the RPL domain”, D address could be the 
> last address in the RH but I’m not sure how this would work. If this 
> text does not apply to tunnel mode as you point below, we should say so.
> 
> */[Pascal] Hum…  “the parent of R” would look up D onlink and would not 
> find it. R needs to set itself as transit parent and D as target. For a 
> RPL router or leaf, and to enable a better compression we let the tunnel 
> end at the target but for a non RPL host that cannot be. So we need R to 
> flag in the DAO that R is the tunnel endpoint for D as opposed to D 
> itself. You’ll note that for each of R’s addresses that are not onlink 
> for “the parent of R”, R has to advertise self as parent, using in the 
> transit an address that is onlink to its own parent./*
> 
> 5)    S à RPL R1 à BR à RPL R2 à D             Tunnel. R1 introduces new 
> IPv6 header with HbH header, R1 is the IPv6 source,
> 
> BR the IPv6 dest. BR removes this header. Encapsulates with new IPv6 
> header with HbH header and RH (non-storing mode only), BR is the IPv6 
> source, and RPL R2 the final dest in the RH.
> 
> */[Pascal] I hope we are not in contradiction : ) This is correct in non 
> storing. In storing, the packet doesn’t need to go to the root and even 
> if it does, the root is just another common parent and forwards down. 
> There is no decap reencap in that case. But to determine that you can 
> bypass the root, you have to figure that the destination is a leaf or a 
> router of the same RPL network, which is not obvious. If we do not have 
> plain hosts but just RPL routers and leaves in a same subnet, then it is 
> a lot easier. /*
> 
> [Mathilde] Agree
> 
>  
> 
> Note that if the above is correct, the only information needed by RPL 
> nodes is the global address of the BR (i.e. the root). So it seems that 
> 2 below might not be needed
> 
> */[Pascal] If we do the above for storing, we lose the advantage of 
> routing via the common parent…/*
> 
> [Mathilde] Agree
> 
> 
> ------------------------------------------------------------------------
> 

-- 
__________________________________________________
Daniel Gavelle, Software Engineer
Tel: +44 114 281 2655
Fax: +44 114 281 2951
Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK
Comp Reg No: 3191371  Registered In England
http://www.jennic.com
__________________________________________________