Re: [6tisch] Question on draft-ietf-6lo-routing-dispatch-00

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Wed, 06 January 2016 14:47 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 0C9701A872F; Wed, 6 Jan 2016 06:47:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -13.91
X-Spam-Level:
X-Spam-Status: No, score=-13.91 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, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 Oa04ndt4R-YJ; Wed, 6 Jan 2016 06:47:09 -0800 (PST)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A89441A8547; Wed, 6 Jan 2016 06:47:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21654; q=dns/txt; s=iport; t=1452091628; x=1453301228; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=QDwdmkKV9DVQKa0Ul/UYplFCQsze3DbmI9Qsvhry9P4=; b=iMpHowlbSDmM+mlwPDL67Zhwh+MPiu/bkUO03n1a8sXLzKr7KNU2N5/l NBdKpjx0G0Llld5bsZyQX0/+q3Eja5VDdx56zpvuC02qMsC20UWuZcFSX k+Cx1kBKG04SgQ02BbUrjjdLxELYGBXRt0x/PBgx8JgOgYiMiHRz3JtYv A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0D8AQB5KI1W/49dJa1egm5MUm0GiFOzTQENgWQkhWsCHIEDOBQBAQEBAQEBgQqENQEBAgIjClwCAQhCAgICMCUCBAEaEYgWDrEekFkBAQEBAQEBAQEBAQEBAQEBAQEBAQEUBIZWhH+FBIJvgUkFlwoBhUGIDIFjhEOIW45GASABAUKECnIBhFiBCAEBAQ
X-IronPort-AV: E=Sophos; i="5.20,529,1444694400"; d="scan'208,217"; a="61001598"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Jan 2016 14:47:07 +0000
Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u06El7hG031437 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 6 Jan 2016 14:47:07 GMT
Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 6 Jan 2016 08:47: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, 6 Jan 2016 08:47:06 -0600
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Tengfei Chang <tengfei.chang@gmail.com>, "6tisch@ietf.org" <6tisch@ietf.org>, "6lo@ietf.org" <6lo@ietf.org>
Thread-Topic: Question on draft-ietf-6lo-routing-dispatch-00
Thread-Index: AQHRSIleB4/vXkr10Eq3VU3wc3UEKp7uiltQ
Date: Wed, 06 Jan 2016 14:46:41 +0000
Deferred-Delivery: Wed, 6 Jan 2016 14:46:24 +0000
Message-ID: <e12a3fb245fe40a9ab4d6e8ab2ff9aba@XCH-RCD-001.cisco.com>
References: <CAAdgstTyZnBNxckLX87g78b7o-_f+43vyft4LTyON1MKtMxkwQ@mail.gmail.com>
In-Reply-To: <CAAdgstTyZnBNxckLX87g78b7o-_f+43vyft4LTyON1MKtMxkwQ@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.49.80.35]
Content-Type: multipart/alternative; boundary="_000_e12a3fb245fe40a9ab4d6e8ab2ff9abaXCHRCD001ciscocom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/6tisch/QB5IAXGNPhOIie-u3xNdlIfjDdQ>
Subject: Re: [6tisch] Question on draft-ietf-6lo-routing-dispatch-00
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, 06 Jan 2016 14:47:15 -0000

Hello TengFei : )

I hope you’re doing good!

Please see below:
1. in section 4.2, second paragraph:
One or more 6LoRHs MAY be placed in a 6LoWPAN packet and MUST always
be placed before the LOWPAN_IPHC [RFC6282].

What's the situation when Ip-in-Ip encapsulation structure was used?

<pascal>
The idea is that the original IPv6 packet that may eventually fly over the internet or has come from the Internet should be encoded using RFC6282. There may be IP in IP in there but then the RPL routers would not see the inner IP.
When that packet traverses the RPL network, headers may need to be added or removed. If so, anything that needs to be added or removed in the life of the packet by a node that is not source or destination must be placed in an IP in IP using 6LoRH https://tools.ietf.org/html/draft-ietf-6lo-routing-dispatch-00#section-8, and the 6LoRH must be placed before the IPHC. There’s no a comprehensive study of that here https://tools.ietf.org/html/draft-robles-roll-useofrplinfo-02 thanks to the efforts of the RPL chairs.
</pascal>


2. section 8: IP-in-IP 6LoRH first paragraph:
The IP-in-IP 6LoRH (IPinIP-6LoRH) is an Elective 6LoWPAN Routing
Header that provides a compressed form for the encapsulating IPv6
Header in the case of an IP-in-IP encapsulation.

According to the description, it the IPinIP-6LoRH is a combination of IPHC+RH3 but in a compressed format?
<pascal>
No, TengFei. The IP in IP 6lorh encodes the outer IP header that must be placed to encapsulate. RH3 is encoded as a series of 6Lorhs as described in https://tools.ietf.org/html/draft-ietf-6lo-routing-dispatch-00#section-6
</pascal>

For example: following is the format of packet containing routing header which defined in old draft using an Ip-in-Ip encapsulation:
MACheader + IPHC + RH3 + IPv6ExT + IPHC + ICMPv6

If we are using the 6LoRH, will it turns to :
MACheader + Paging Dispatch(page 1) + IPinIP-6LoRH + IPv6ExT + IPHC + ICMPv6

Is this correct? If not, what it should be? Thanks!


<pascal>
Not really:

1)      The RH3 is expressed as a series of 6LoRH after the IP in IP, one 6LoRH per group of contiguous addresses that are compressed to the same size Please look at slide 10 in https://www.ietf.org/proceedings/94/slides/slides-94-6lo-2.pdf

2)      What is the IPv6Ext? The only header that RPL may add there is RPI in HbH, compressed by 6loRH. And Actually I’d place it before the RH. Anything that is not compressed by 6LoRH has to be compressed by RFC 6282 and must be placed after the IPHC

<pascal>

You two take care,

Pascal