Subject: Re: [Roll] Roll Digest, Vol 46, Issue 21

From: "Reddy, Joseph" <[email-masked]>
Date: Wed, 16 Nov 2011 19:15:30 +0000

Hi Mukul,

Note that IP-in-IP tunnelling may be necessary even for data packets orginated on the RPL router itself. This is because the destination may be a non-RPL Host and so the RPL Option header has to be removed before sending the packet on the final hop. 

Essentially,  a standard IPv6 Host would not necessarily be able to send/receive IPv6 packets through a RPL router unless the RPL router has the additional logic to add the necessary headers ( and also remove the same for packets destinted to the Host ) and perform tunnelling. This behaviour on part of the RPL router is not mandatory per the RPL spec. I think it should be.

-Regards, Joseph

----- Original Message -----
From: "Mukul Goyal" <mukul at uwm.edu>

I guess the desired behavior would be:

A host sends out a message to its RPL router. The router adds RPL SRH or RPL option to the IPv6 header and forwards the message further. No need for IP-in-IP tunneling. Any error message comes back to the router and the router handles the message. The host just sends and receives messages.

Thanks
Mukul

----- Original Message -----
From: "Mukul Goyal" <mukul at uwm.edu>
To: "Don Sturek" <d.sturek at att.net>
Cc: roll at ietf.org
Sent: Wednesday, November 16, 2011 12:29:59 PM
Subject: Re: [Roll] definition of "RPL Domain"

Hi Don

I dont want hosts to know about RPL. I just want the RPL routers to consider the hosts as part of the RPL instance so that the RPL router does not have to do IP-in-IP tunneling to forward packets generated by a host.

Thanks
Mukul

----- Original Message -----
From: "Don Sturek" <d.sturek at att.net>
To: "Mukul Goyal" <mukul at uwm.edu>, "SÃbastien Dawans" <sebastien.dawans at cetic.be>
Cc: roll at ietf.org
Sent: Wednesday, November 16, 2011 12:22:55 PM
Subject: Re: [Roll] definition of "RPL Domain"

Hi Mukul,

I guess my view on this is the opposite of yours.  I would like to see
host-only devices not need to know anything about RPL.  Here is why:
1)  Code savings.   Removing RPL from these host only devices would allow
for deployment on smaller footprint devices
2)  Battery operated devices.   Some host only devices are deployed on
non-mains powered devices.  It would be nice for these devices to not have
to listen for any RPL control messages yet still support transmission into
a RPL routing domain.

Don

---

From: Mukul Goyal <[email-masked]>
Date: Wed, 16 Nov 2011 13:58:35 -0600 (CST)

Hi Joseph

I was wondering if you know the overhead (in terms of bytes) for the extra IPv6 header required for IP-in-IP tunneling? Also, what would be the processing overhead of encapsulation/decapsulation at every hop as a packet (originated by a host) travels to its destination (another host; hence outside the RPL instance)

I would like two hosts in an LLN to be able to communicate without requiring IP-in-IP tunneling. To achieve this goal, it seems that both hosts need to be considered part of the RPL instance of their RPL routers. Also, it should be possible for the routers to add/remove SRH and RPL options on behalf of their hosts.

I understand that IP-in-IP tunneling is required when source/destination is not in RPL instance.

Thanks
Mukul

----- Original Message -----
From: "Joseph Reddy" <[email-masked]>
To: [email-masked]
Sent: Wednesday, November 16, 2011 1:15:30 PM
Subject: Re: [Roll] Roll Digest, Vol 46, Issue 21

Hi Mukul,

-Regards, Joseph

----- Original Message -----

Thanks
Mukul

----- Original Message -----
From: "Mukul Goyal" <mukul at uwm.edu>
To: "Don Sturek" <d.sturek at att.net>
Cc: roll at ietf.org
Sent: Wednesday, November 16, 2011 12:29:59 PM
Subject: Re: [Roll] definition of "RPL Domain"

Hi Don

Thanks
Mukul

----- Original Message -----
From: "Don Sturek" <d.sturek at att.net>
To: "Mukul Goyal" <mukul at uwm.edu>, "SÃbastien Dawans" <sebastien.dawans at cetic.be>
Cc: roll at ietf.org
Sent: Wednesday, November 16, 2011 12:22:55 PM
Subject: Re: [Roll] definition of "RPL Domain"

Hi Mukul,

Don

_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: Richard Kelsey <[email-masked]>
Date: Wed, 16 Nov 2011 16:40:39 -0500

> Date: Wed, 16 Nov 2011 13:58:35 -0600
> From: Mukul Goyal <[email-masked]>
> 
> I was wondering if you know the overhead (in terms of bytes) for the
> extra IPv6 header required for IP-in-IP tunneling?

The added header is 40 bytes uncompressed.  For a one-hop
tunnel, 6LoWPAN HC compression squishes the added header
down to 2 bytes.  In other cases the compressed length
depends on how well the source and destination addresses
can be compressed.

> Also, what would be
> the processing overhead of encapsulation/decapsulation at every hop as
> a packet (originated by a host) travels to its destination (another
> host; hence outside the RPL instance)

That depends entirely on how it is implemented.  Using
6LoWPAN HC compression the tunnel header always compresses
to the same two bytes.  The overhead for adding or removing
two fixed bytes from the head of a packet can be quite
small.

> I would like two hosts in an LLN to be able to communicate without
> requiring IP-in-IP tunneling. To achieve this goal, it seems that both
> hosts need to be considered part of the RPL instance of their RPL
> routers. Also, it should be possible for the routers to add/remove SRH
> and RPL options on behalf of their hosts.

There were strong objections in the 6man group to having a
router add or remove option headers from a packet being
forwarded.  From their point of view, the only way to avoid
tunnelling is if the source adds the RPL option and it
travels intact to the destination.  This requires that the
sender, destination, and all intermediate routers implement
RPL.
                               -Richard Kelsey

---

From: Mukul Goyal <[email-masked]>
Date: Wed, 16 Nov 2011 21:47:09 -0600 (CST)

Hi Richard

I was wondering if you could summarize what were the main objections to having a router add/remove optional headers in a packet generated by a host attached to the router.

Thanks
Mukul

---

From: Thomas Heide Clausen <[email-masked]>
Date: Thu, 17 Nov 2011 15:37:45 +0800

Mukul,

+1 to your question. 

The crux for me here is, that a non-routing-protocol-aware, non-LLN-aware host can be "hung off an LLN router", and be reachable and reach across the LLN. If there's a need for "LLN magic" headers etc., then only the LLN routers should need to be aware of and do that, while the hosts and host apps should be able to remain ignorant. 

If we agree on the above, and if that becomes true, then I think we reached a position on getting rid of "RPL leaf router" and "RPL Host" and "RPL Traffic" as concepts and terms, also?

Best,

Thomas

-- 
Thomas Heide Clausen
http://www.thomasclausen.org

"Today's scientists have substituted mathematics for 
  experiments, and they wander off through equation 
  after equation, and eventually  build a structure 
  which has no relation to reality."
 - Nikola Tesla, 
    Modern Mechanics and Inventions, July, 1934

---

From: Richard Kelsey <[email-masked]>
Date: Thu, 17 Nov 2011 09:56:27 -0500

> Date: Wed, 16 Nov 2011 21:47:09 -0600
> I was wondering if you could summarize what were the main objections
> to having a router add/remove optional headers in a packet generated
> by a host attached to the router.

Mukul,

Disclaimer: I am not an expert on this stuff and did not
participate in the discussion within the 6man group.

The main concern is MTU issues.  If the source sends a
message that fits within the path MTU, but an intermediate
router adds an optional header that makes the packet too
large to fit, things may fall apart.

This message:
http://www.ietf.org/mail-archive/web/ipv6/current/msg14805.html
contains the discussion on this between Jari Arkko, the AD
who reviewed the RPL option and routing header drafts, and
Jonathan Hui, one of the authors.

Jari Arkko did acknowledge that there may be circumstances
where the tunnelling is not needed and the RPL option could
be added by a forwarding router, but that would require a
another draft that explained in detail how it would all work.

Personally, I am happy with the one-hop tunnels.  They
introduce no new routing complications, only some packet
overhead.  When using 6LoWPAN HC compression they add just
two bytes to the packet.  Even those two bytes could be
removed by getting a new 6LoWPAN dispatch byte that
indicated that the packet began with a one-hop tunnel header
followed by a RPL option.  I believe that would make the
compressed packet the same size as if the router had added
the RPL option after the existing header.

                              -Richard Kelsey