Re: [6tisch] [6lo] Format inside of an RPL domain

Thomas Watteyne <thomas.watteyne@inria.fr> Mon, 08 February 2016 13:20 UTC

Return-Path: <thomas.watteyne@inria.fr>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F72C1B2AAF; Mon, 8 Feb 2016 05:20:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.928
X-Spam-Level:
X-Spam-Status: No, score=-5.928 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tC_bzOstvbR0; Mon, 8 Feb 2016 05:20:11 -0800 (PST)
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7AA91B2AA4; Mon, 8 Feb 2016 05:20:10 -0800 (PST)
X-IronPort-AV: E=Sophos;i="5.22,416,1449529200"; d="scan'208,217";a="202063322"
Received: from mail-wm0-f44.google.com ([74.125.82.44]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 08 Feb 2016 14:20:09 +0100
Received: by mail-wm0-f44.google.com with SMTP id 128so154693156wmz.1; Mon, 08 Feb 2016 05:20:09 -0800 (PST)
X-Gm-Message-State: AG10YOTQjdq2ZzxFh4qh2tZIPIqP2eytluIEleSjZ+6EQ9rlpyItMQw8RTnj1U437enXGxLAYZbUYTvBDbyr0A==
X-Received: by 10.28.224.84 with SMTP id x81mr49357481wmg.62.1454937609011; Mon, 08 Feb 2016 05:20:09 -0800 (PST)
MIME-Version: 1.0
Received: by 10.27.103.14 with HTTP; Mon, 8 Feb 2016 05:19:49 -0800 (PST)
In-Reply-To: <CADJ9OA9Nwn5-CQyR7nD0mJ0jGw=Sm2Uwtu7Z0yuZv+QFeEDB-w@mail.gmail.com>
References: <CAAdgstQRYJJFJLWbCJNJ93V0=SNz3GLxFawK=s6S2L4304-8MQ@mail.gmail.com> <c9bede2e2e2c4e2ca1fc69ecf47ce289@XCH-RCD-001.cisco.com> <CAAdgstQ66ZRfhahxZJvcRuB8gGV7fbEuzjxx6xdQs--vH2Xg=g@mail.gmail.com> <7c82388e5ccd437fad8dab52e5e1541d@XCH-RCD-001.cisco.com> <CADJ9OA9Nwn5-CQyR7nD0mJ0jGw=Sm2Uwtu7Z0yuZv+QFeEDB-w@mail.gmail.com>
From: Thomas Watteyne <thomas.watteyne@inria.fr>
Date: Mon, 8 Feb 2016 14:19:49 +0100
X-Gmail-Original-Message-ID: <CADJ9OA_W_3NXw3hcZjqR-murKtGutD2eNVCK2O6O-5ogDMzB6w@mail.gmail.com>
Message-ID: <CADJ9OA_W_3NXw3hcZjqR-murKtGutD2eNVCK2O6O-5ogDMzB6w@mail.gmail.com>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
Content-Type: multipart/alternative; boundary=001a114c18465b1216052b420fb6
Archived-At: <http://mailarchive.ietf.org/arch/msg/6tisch/PMOtDcZymm0IbMbUTBxjKnwz6w8>
Cc: Simon Duquennoy <simonduq@sics.se>, "6tisch@ietf.org" <6tisch@ietf.org>, Tengfei Chang <tengfei.chang@gmail.com>, "6lo@ietf.org" <6lo@ietf.org>
Subject: Re: [6tisch] [6lo] Format inside of an RPL domain
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:6tisch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6tisch/>
List-Post: <mailto:6tisch@ietf.org>
List-Help: <mailto:6tisch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:6tisch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Feb 2016 13:20:16 -0000

[resending from the right e-mail address]

On Mon, Feb 8, 2016 at 2:16 PM, Thomas Watteyne <twatteyne@gmail.com> wrote:

> Pascal,
>
> I hope my comments don't come too late. Please find below some edits of
> your suggested text.
>
> My biggest comment is about naming, as I think we are using "nicknames"
> for things, which makes things very hard to follow.
>
> Thomas
>
> ## DODAG Root Address {#impl-comp-ref}
>
>
>
> With this specification, an optimal compression
>
> TW> I would drop the word "optimal", which implies you can prove it.
> Replace by "efficient"?
>
> of IP-in-IP encapsulation can be
>
> achieved if an endpoint of the packet is the root of the RPL DODAG
> associated to
>
> the Instance
>
> TW> please make sure that you use the capital "I" on purpose
>
> that is used to forward the packet, and the root address is known
>
> implicitly as opposed to signaled explicitly in the data packets.
>
>
>
> With RPL {{RFC6550}}, the address of
>
> TW> add "the"
>
> DODAG root is known from the DODAGID field
>
> of the DIO messages. For a Global Instance, the RPLInstanceID that is
> present in
>
> the RPI
>
> TW> where does the term RPI come from? According to RFC6553, the full name
> is "RPL Option", no?
>
> is enough information to identify the DODAG that this node participates
>
> to and its associated root. But for a Local Instance, the address of the
> root
>
> MUST be explicit, either in some device configuration or signaled in the
> packet,
>
> as the source or the destination address, respectively.
>
>
>
> When implicit, the address of the DODAG root MUST be determined as follows:
>
>
>
> If the whole network is a single DODAG then the root can be well-known and
> does
>
> not need to be signaled in the packets. But
>
> TW> "if" missing?
>
> RPL does not expose that property
>
> and it can only be known by a configuration applied to all nodes.
>
>
>
> Else, the router that encapsulates the packet and compresses it with this
>
> specification MUST also place an RPI in the packet as prescribed by
> {{RFC6550}}
>
> to enable the identification of the DODAG. The RPI must be present even in
> the
>
> case when the router also places an RH3 header in the packet.
>
>
>
> It is expected that the RPL implementation provides an abstract context
> table,
>
> indexed by Global RPLInstanceID, that provides the address of the root of
> the
>
> DODAG that this nodes participates to for that particular Instance.
>
>
>
>
>
> ## Compression Reference {#sig-comp-ref}
>
>
>
> 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
>
> > In the same vain as my comment about RPI, we should really force
> ourselves to use the same terminology, or else it gets really really
> confusing.
>
> > I understand that RH3 stands for
> the-Routing-header-with-IPv6-routing-type-3, but according to RFC6554, this
> is called "RPL Source Route Header". Let's please use that name...
>
>
> 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.
>
>
>
> (note that this means that the specification does not expect
> IP-in-IP-in-IP and
>
> does not enforce any order in 6LoRH ... should it???).
>
> On Wed, Jan 20, 2016 at 4:14 PM, Pascal Thubert (pthubert) <
> pthubert@cisco.com> wrote:
>
>> Hello Tengfei and Simon (and all):
>>
>>
>>
>> I’ll need some more help from you.
>>
>>
>>
>> I’m in the process of refining the text that indicates how the root
>> address is obtained and how to compute the Compression Reference for the
>> RH3.
>>
>>
>>
>> I came up with the following, which indicates that the source of the
>> packet (which should always be the root for now but who knows) is the
>> reference for RH3 compression.
>>
>>
>>
>> Is that what we want? Is it clear enough?
>>
>>
>>
>>
>>
>> ## DODAG Root Address {#impl-comp-ref}
>>
>>
>>
>> With this specification, an optimal compression of IP-in-IP encapsulation
>> can be
>>
>> achieved if an endpoint of the packet is the root of the RPL DODAG
>> associated to
>>
>> the Instance that is used to forward the packet, and the root address is
>> known
>>
>> implicitly as opposed to signaled explicitly in the data packets.
>>
>>
>>
>> With RPL {{RFC6550}}, the address of DODAG root is known from the DODAGID
>> field
>>
>> of the DIO messages. For a Global Instance, the RPLInstanceID that is
>> present in
>>
>> the RPI is enough information to identify the DODAG that this node
>> participates
>>
>> to and its associated root. But for a Local Instance, the address of the
>> root
>>
>> MUST be explicit, either in some device configuration or signaled in the
>> packet,
>>
>> as the source or the destination address, respectively.
>>
>>
>>
>> When implicit, the address of the DODAG root MUST be determined as
>> follows:
>>
>>
>>
>> If the whole network is a single DODAG then the root can be well-known
>> and does
>>
>> not need to be signaled in the packets. But RPL does not expose that
>> property
>>
>> and it can only be known by a configuration applied to all nodes.
>>
>>
>>
>> Else, the router that encapsulates the packet and compresses it with this
>>
>> specification MUST also place an RPI in the packet as prescribed by
>> {{RFC6550}}
>>
>> to enable the identification of the DODAG. The RPI must be present even
>> in the
>>
>> case when the router also places an RH3 header in the packet.
>>
>>
>>
>> It is expected that the RPL implementation provides an abstract context
>> table,
>>
>> indexed by Global RPLInstanceID, that provides the address of the root of
>> the
>>
>> DODAG that this nodes participates to for that particular Instance.
>>
>>
>>
>>
>>
>> ## Compression Reference {#sig-comp-ref}
>>
>>
>>
>> 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.
>>
>>
>>
>> (note that this means that the specification does not expect
>> IP-in-IP-in-IP and
>>
>> does not enforce any order in 6LoRH ... should it???).
>>
>>
>>
>>
>>
>> Cheers,
>>
>>
>>
>> Pascal
>>
>>
>>
>> *From:* Tengfei Chang [mailto:tengfei.chang@gmail.com]
>> *Sent:* lundi 18 janvier 2016 14:26
>> *To:* Pascal Thubert (pthubert) <pthubert@cisco.com>
>> *Cc:* 6lo@ietf.org; 6tisch@ietf.org
>> *Subject:* Re: [6lo] Format inside of an RPL domain
>>
>>
>>
>> I agree with this format! +1
>>
>>
>>
>> Tengfei
>>
>>
>>
>> On Mon, Jan 18, 2016 at 9:41 AM, Pascal Thubert (pthubert) <
>> pthubert@cisco.com> wrote:
>>
>> Dear TengFei:
>>
>>
>>
>> I agree that the draft is lacking description when there is no IP in IP.
>> I’ll create a ticket.
>>
>>
>>
>> When there is no IP in IP present in the 6LoRH, then the headers
>> compressed by 6LoRH are considered placed right after the IP header
>> compressed by IPHC, and considered as compressed. It results that the NH
>> bit in the IPHC really indicates how the compression is done for the header
>> that is after the headers compressed by 6LoRH.
>>
>>
>>
>> For an ICMP message I’d think that you’ll be using:
>>
>>
>>
>>    +- ...  -+- ...  -+-+-+- ... -+-+-+-+-+ ... -+-+-+-+-+-+-+-+-+-+-+...
>>
>>    |11110001|  RPI   |  NH = 0       | NH = 58  |  ICMP message
>>
>>    |Page 1  | 6LoRH  | 6LOWPAN-IPHC  | (ICMP)   |  (no compression)
>>
>>    +- ...  -+- ... +-+-+-+- ... -+-+-+-+-+ ... -+-+-+-+-+-+-+-+-+-+-+...
>>
>>                       <-        RFC 6282       ->
>>
>>                             No RPL artifact
>>
>>
>>
>> Does that make sense?
>>
>>
>>
>> Pascal
>>
>>
>>
>> *From:* 6lo [mailto:6lo-bounces@ietf.org] *On Behalf Of *Tengfei Chang
>> *Sent:* lundi 18 janvier 2016 09:18
>> *To:* 6lo@ietf.org
>> *Subject:* [6lo] Format inside of an RPL domain
>>
>>
>>
>> Dear All,
>>
>>
>>
>> Currently I have a question about the format of packet inside of an RPL
>> domain when using 6LoRH.
>>
>>
>>
>> For example when ping a mote inside an RPL domain, will the format of
>> echo request and reply look like this?
>>
>>
>>
>> PAGE DISPATCH (page 1) + IPHC + 6LoRH RH3 + ICMPv6
>>
>> PAGE DISPATCH (page 1) + IPHC + 6LoRH RPI + ICMPv6
>>
>>
>>
>> If so, there is no next header field in 6LoRH to indicate the following
>> field is ICMP.
>>
>> What's the right format for this case?
>>
>>
>>
>> Thanks a lot!
>>
>> Tengfei
>>
>>
>>
>> _______________________________________________
>> 6lo mailing list
>> 6lo@ietf.org
>> https://www.ietf.org/mailman/listinfo/6lo
>>
>>
>