Re: [Roll] Hosts part of the RPL instance? Re: definition of "RPL Domain"

Ulrich Herberg <ulrich@herberg.name> Thu, 17 November 2011 00:59 UTC

Return-Path: <ulrich@herberg.name>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4272121F8ABB for <roll@ietfa.amsl.com>; Wed, 16 Nov 2011 16:59:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.203
X-Spam-Level:
X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uv6NixYFw0kZ for <roll@ietfa.amsl.com>; Wed, 16 Nov 2011 16:59:04 -0800 (PST)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3683C21F8770 for <roll@ietf.org>; Wed, 16 Nov 2011 16:59:04 -0800 (PST)
Received: by ywt34 with SMTP id 34so453252ywt.31 for <roll@ietf.org>; Wed, 16 Nov 2011 16:59:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=1843NZpivDtcU1EuIdC54GpJqFUDwPFbKvpOEi/5uoQ=; b=bVhsiTxDnNpsVtnU54QLA1Jo+wRjDu3d7cYaSP02MK2c0D3m8Njg9WcnRDCNyyrsjS m6QfOmnWMx6Gj96FULo0s94aC8sTYesugGKCF+8XKlfZ+u7rvQlWN9rF6KsMk1mODq5Z BqhtQP97mCxUoJvRvH7PVdj+qXfX93HgMlcO8=
Received: by 10.236.131.72 with SMTP id l48mr5829095yhi.90.1321491543659; Wed, 16 Nov 2011 16:59:03 -0800 (PST)
Received: from [172.20.2.97] ([203.69.99.17]) by mx.google.com with ESMTPS id h45sm2758768yhm.15.2011.11.16.16.59.00 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 16 Nov 2011 16:59:01 -0800 (PST)
References: <1373977554.319419.1321468695445.JavaMail.root@mail17.pantherlink.uwm.edu>
In-Reply-To: <1373977554.319419.1321468695445.JavaMail.root@mail17.pantherlink.uwm.edu>
Mime-Version: 1.0 (1.0)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"
Message-Id: <F497F786-38F2-4F82-8EB4-B0F1169EBB3F@herberg.name>
X-Mailer: iPad Mail (9A405)
From: Ulrich Herberg <ulrich@herberg.name>
Date: Thu, 17 Nov 2011 09:00:06 +0800
To: Mukul Goyal <mukul@uwm.edu>
Cc: "roll@ietf.org" <roll@ietf.org>
Subject: Re: [Roll] Hosts part of the RPL instance? Re: definition of "RPL Domain"
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Nov 2011 00:59:05 -0000

My 2cts on the various terminology discussions:

- An "RPL host" seems contradictory to me. Either it is a host, in which case it does not know anything about RPL, or it is an RPL router (leaf node or not, it still remains a router). We should allow for hosts (or be prepared to fight with the IAB for the next years why we think that we should break the IP architecture).

- A question that comes to my mind: Is it specified anywhere how to add the RPL IP headers for the traffic direction to a data packet from a host received by an RPL router?

- "RPL domain"; We should just stick to official terminology, i.e, "Routing Domain" in this case. I think it has been specified in RFC1136.

- RPL traffic: I don't like the term. I would stick to either control traffic or data traffic. Everyone understands these terms. No need to invent new terms.

Regards
Ulrich

On Nov 17, 2011, at 2:38, Mukul Goyal <mukul@uwm.edu> wrote:

> 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@uwm.edu>
> To: "Don Sturek" <d.sturek@att.net>
> Cc: roll@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@att.net>
> To: "Mukul Goyal" <mukul@uwm.edu>, "Sébastien Dawans" <sebastien.dawans@cetic.be>
> Cc: roll@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
> 
> 
> 
> On 11/16/11 10:07 AM, "Mukul Goyal" <mukul@uwm.edu> wrote:
> 
>> Hi Sebastien
>> 
>> First, I would like to clarify that the need to define "RPL domain" arose
>> because draft-ietf-6man-rpl-option and draft-ietf-6man-rpl-routing-header
>> were using the term. Now, these drafts use the term "RPL instance" and
>> hence there is no real need to define the term "RPL domain" any more. I
>> will change draft-ietf-roll-p2p-measurement so that all references to
>> "RPL domain" are changed to "RPL Instance".
>> 
>> Now returning to the question whether hosts should be considered part of
>> the RPL Instance, the benefit of doing so is that there is no need to use
>> IP-in-IP tunneling when a host sends out some data. If a host is not
>> considered part of the RPL Instance, its default RPL router is obliged to
>> use IP-in-IP tunneling to forward the packet further. IP-in-IP tunneling
>> means an extra IPv6 header and thus less space for payload if you want to
>> avoid fragmentation. Also, if the packet is traveling along a DAG, the
>> encapsulation/decapsulation needs to be done at every hop, which sounds
>> fairly heavy duty processing to me.
>> 
>> So, I would like to explore if there is a way we could consider hosts to
>> be a part of the RPL Instance.
>> 
>> Regards,
>> Mukul
>> 
>>> On what ground would you assume that a non-RPL aware host connected to a
>>> RPL-router (in this case I would call it a border router) is in a/the
>>> RPL Domain?
>> 
>>> From what I've seen in the drafts, the term "RPL Domain"'s primary
>>> purpose it to differentiate the limits of "RPL-aware" nodes for IP
>>> traffic that needs to transit to or from a set of RPL-aware hosts (for
>>> example, to define where to add/remove the RPL IPv6 Hop-by-Hop Option if
>>> used).
>> 
>>> To me, this interpretation of RPL Domain is thus only useful in a local
>>> context and not to meant to designate one or more bounded set of nodes.
>>> That's the role of DODAGs and Instances.
>> 
>>> Best Regards,
>> 
>>> Sébastien Dawans
>> 
>> On 11/16/2011 02:20 PM, Mukul Goyal wrote:
>>> So, the revised doubts are as follows:
>>> 
>>> 1. It is clear that RPL routers are within an RPL domain but what about
>>> the RPL-unaware IPv6 hosts attached to an RPL router? I would imagine
>>> that such hosts are also within an RPL domain.
>>> 
>>> 2. Is an RPL domain same as an RPL instance? Or is an RPL domain a set
>>> of RPL instances in the LLN? Can multiple RPL domains exist within an
>>> LLN? Or is it that an RPL domain is same as an LLN using RPL as a
>>> routing protocol?
>>> 
>>> THanks
>>> Mukul
>>> 
>>> ----- Original Message -----
>>> From: "Mukul Goyal"<mukul@uwm.edu>
>>> To: "Thomas Heide Clausen"<thomas@thomasclausen.org>
>>> Cc: "roll"<roll@ietf.org>
>>> Sent: Wednesday, November 16, 2011 7:15:59 AM
>>> Subject: Re: [Roll] definition of "RPL Domain"
>>> 
>>> 
>>>> Now that we are at it: what is an RPL host? Or rather, why is this
>>>> even a conceivable thing to define? Afaik, RPL is a routing protocol,
>>>> and as such should concern only routers - not hosts?
>>>> 
>>> My bad. By RPL host, I actually meant an RPL leaf node. I think this
>>> term "RPL host" was in use at one point in time but I cant find a
>>> reference to it in current spec.
>>> 
>>> THanks
>>> Mukul
>>> 
>>> 
>>> 
>>> ----- Original Message -----
>>> From: "Thomas Heide Clausen"<thomas@thomasclausen.org>
>>> To: "Mukul Goyal"<mukul@uwm.edu>
>>> Cc: "JP Vasseur"<jpv@cisco.com>, "roll"<roll@ietf.org>
>>> Sent: Wednesday, November 16, 2011 6:25:31 AM
>>> Subject: Re: [Roll] definition of "RPL Domain"
>>> 
>>> Now that we are at it: what is an RPL host? Or rather, why is this even
>>> a conceivable thing to define? Afaik, RPL is a routing protocol, and as
>>> such should concern only routers - not hosts?
>>> 
>>> I worry if this is inventing an entire ecosystem which "pretends to be
>>> just like the Internet, except it is not", as it needs entirely new
>>> stacks, protocols, translators/gateways everywhere, and with no real
>>> traces of IP as we know it remaining?
>>> 
>>> 
>> 
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org
>> https://www.ietf.org/mailman/listinfo/roll
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org
>> https://www.ietf.org/mailman/listinfo/roll
> 
> 
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll