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, 08 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 >> >> >
- Re: [6tisch] [6lo] Format inside of an RPL domain Pascal Thubert (pthubert)
- Re: [6tisch] [6lo] Format inside of an RPL domain Thomas Watteyne
- Re: [6tisch] [6lo] Format inside of an RPL domain Thomas Watteyne
- Re: [6tisch] [6lo] Format inside of an RPL domain Pascal Thubert (pthubert)
- Re: [6tisch] [6lo] Format inside of an RPL domain Tengfei Chang
- Re: [6tisch] [6lo] Format inside of an RPL domain Pascal Thubert (pthubert)
- Re: [6tisch] [6lo] Format inside of an RPL domain Pascal Thubert (pthubert)