Re: [6tisch] [6lo] Format inside of an RPL domain
"Pascal Thubert (pthubert)" <pthubert@cisco.com> Wed, 10 February 2016 11:36 UTC
Return-Path: <pthubert@cisco.com>
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 B90901A1BA3; Wed, 10 Feb 2016 03:36:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 BXRzYrtDNDzP; Wed, 10 Feb 2016 03:36:09 -0800 (PST)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA0B71A1B7F; Wed, 10 Feb 2016 03:36:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=97278; q=dns/txt; s=iport; t=1455104168; x=1456313768; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=B8TznHzeln0GBChckZJKpzM3FjTdKoNZLCZd7ElkWYo=; b=KaYf1+ZKrQUoxfuTb1D+kycZDmjdif2FtYB139siSSdVyF3V4WYF/OMK Bk4tv6sijmQdeAUrwy3SNJEgFiqOnC6xlUGyOk1Vrq2MIWaoKKmlSXkla SgKFtJlLU2fW2la6O4fpVyJIDxvESWN4gaIUSHbAxr6J+fEhtypSSkU5w M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ATAgAmILtW/5FdJa1UCoJuTFJtBohWsSABDYFmFwEJhWwCHIEcOBQBAQEBAQEBgQqEQQEBAQMBAQEBFwkEBjoHBgUFCwIBCA4DBAEBIQEGAwICAh8GCxQJCAIEDgUIh34DCggOsGmKHA2BB4NNAQEBAQEBAQEBAQEBAQEBAQEBAQEBEQSGEoQ3gjeBUQ4KPwmCSoE6BYdThVSFR4QKAYg3gyaBbIFjhEOIVYZ+h0ABHgEBQoIDGYFIaodXfAEBAQ
X-IronPort-AV: E=Sophos; i="5.22,425,1449532800"; d="scan'208,217"; a="71994113"
Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Feb 2016 11:36:07 +0000
Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u1ABa7A5019011 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 10 Feb 2016 11:36:07 GMT
Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 10 Feb 2016 05:36:06 -0600
Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1104.009; Wed, 10 Feb 2016 05:36:06 -0600
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Thomas Watteyne <twatteyne@gmail.com>
Thread-Topic: [6lo] Format inside of an RPL domain
Thread-Index: AQHRYnL8E+jZf+FLt0y1OKkDJm2qfZ8j3RBw
Date: Wed, 10 Feb 2016 11:35:47 +0000
Deferred-Delivery: Wed, 10 Feb 2016 11:35:08 +0000
Message-ID: <62f293d67ac84497bdc376fb51ec8390@XCH-RCD-001.cisco.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>
In-Reply-To: <CADJ9OA9Nwn5-CQyR7nD0mJ0jGw=Sm2Uwtu7Z0yuZv+QFeEDB-w@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.61.72.84]
Content-Type: multipart/alternative; boundary="_000_62f293d67ac84497bdc376fb51ec8390XCHRCD001ciscocom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/6tisch/MCtpCmelrjI1b8J61C5fpaRg1LY>
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: Wed, 10 Feb 2016 11:36:13 -0000
Thanks Thomas!
The only thing I did not act upon much is renaming the X-6LoRH, I really need to see a consensus on that at this late stage. Couls we start a different thread?
More below:
## 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"?
PT> The text was meant to say the most optimal this spec can do. What about
The most efficient compression of an IP-in-IP encapsulation that can be
achieved with this specification is obtained when an endpoint of the packet is
the root of the RPL DODAG associated to the RPL Instance that is used to
forward the packet, and the root address is known implicitly as opposed to
signaled explicitly in the data packets. …
-----------
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
PT >It is; I added RPL in front to clarify
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"
PT > done
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?
PT > RPL option is the HbH encoding. RFC 6550 is more generic and defines the RPI independently of how it is placed in the packet.
There is already text about that in the draft
As an example, the [Routing Protocol for Low Power and Lossy Networks](#RFC6550)
(RPL) is designed to optimize the routing operations in constrained LLNs.
As part of this optimization, RPL requires the addition of RPL Packet Information
(RPI) in every packet, as defined in Section 11.2 of {{RFC6550}}.
The [RPL Option for Carrying RPL Information in Data-Plane Datagrams](#RFC6553)
specification indicates how the RPI can be placed in a RPL Option for use in an
IPv6 Hop-by-Hop header.
PT > We can change that latter sentence into
The [RPL Option for Carrying RPL Information in Data-Plane Datagrams](#RFC6553)
specification indicates how the RPI can be placed in a RPL Option (RPL-OPT) that
is placed in an IPv6 Hop-by-Hop header.
----
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?
PT > Since maybe?
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 since RPL does not expose that
property, it can only be known by a configuration applied to all nodes.
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...
PT > This is a really classical way in IPv6. Just lookup IPv6 RH0 or RH2. Also, this document defines it on first use “RPL requires a Routing Header type 3 (RH3) “ . Which abbreviation should I use for the LoRH then? SRH-6LoRH? This is effectively less specific, and may create ambiguity. RPL-SRH-6LoRH is fine but long. I’d rather have a thread and get a rough consensus on renaming before taking actions.
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<mailto: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<mailto:tengfei.chang@gmail.com>]
Sent: lundi 18 janvier 2016 14:26
To: Pascal Thubert (pthubert) <pthubert@cisco.com<mailto:pthubert@cisco.com>>
Cc: 6lo@ietf.org<mailto:6lo@ietf.org>; 6tisch@ietf.org<mailto: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<mailto: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<mailto:6lo-bounces@ietf.org>] On Behalf Of Tengfei Chang
Sent: lundi 18 janvier 2016 09:18
To: 6lo@ietf.org<mailto: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<mailto: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)