IETF Logo Mail Archive

Re: [Roll] Compressing the PDAO natively

Rahul Arvind Jadhav <rahul.jadhav@huawei.com> Sat, 27 July 2019 00:21 UTC

Return-Path: <rahul.jadhav@huawei.com>
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 7AF8C1201D3 for <roll@ietfa.amsl.com>; Fri, 26 Jul 2019 17:21:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 IVQn4cpqXusj for <roll@ietfa.amsl.com>; Fri, 26 Jul 2019 17:21:18 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62D391201D1 for <roll@ietf.org>; Fri, 26 Jul 2019 17:21:18 -0700 (PDT)
Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id C0062C473919CF5115AB for <roll@ietf.org>; Sat, 27 Jul 2019 01:21:15 +0100 (IST)
Received: from BLREML407-HUB.china.huawei.com (10.20.4.45) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Sat, 27 Jul 2019 01:21:15 +0100
Received: from BLREML503-MBS.china.huawei.com ([169.254.12.147]) by BLREML407-HUB.china.huawei.com ([10.20.4.45]) with mapi id 14.03.0439.000; Sat, 27 Jul 2019 05:51:03 +0530
From: Rahul Arvind Jadhav <rahul.jadhav@huawei.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Thread-Topic: [Roll] Compressing the PDAO natively
Thread-Index: AdVDr4JzZac2e1l+THeV6NrQSFMX+f//u+eA//8AyQA=
Date: Sat, 27 Jul 2019 00:21:02 +0000
Message-ID: <982B626E107E334DBE601D979F31785C5DF62117@BLREML503-MBS.china.huawei.com>
References: <MN2PR11MB3565E133DA12559F333A78B8D8C00@MN2PR11MB3565.namprd11.prod.outlook.com> <3410282B-872E-49BA-8AA8-9D99E477A5D0@imt-atlantique.fr>
In-Reply-To: <3410282B-872E-49BA-8AA8-9D99E477A5D0@imt-atlantique.fr>
Accept-Language: en-IN, zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.61.109.81]
Content-Type: multipart/alternative; boundary="_000_982B626E107E334DBE601D979F31785C5DF62117BLREML503MBSchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/KkcJYTjpMrOFvLbPhbLME0o1E1w>
Subject: Re: [Roll] Compressing the PDAO natively
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Sat, 27 Jul 2019 00:21:20 -0000

Hi,

For control plane it certainly will help if P-DAO’s address list is compressed. There are other candidates also for control plane compression, such as:

1.      Target option compression in DAO. Can 6lo CID be used? Does this result in cross-layer violation (RPL getting info from 6lo)? If we do not intend to do this, then can we use the ‘Compr’ mechanism used in P2P-RPL/AODV-RPL to elide network prefix in Target Option by using DODAGID.

2.      Is it possible to remove network prefix from the parent address information in Transit Information Option in non-storing DAO ?

3.      NSA-extensions parent set address list compression .. as mentioned by Georgios.

4.      Compressing multiple ARTs (AODV-RPL Targets).

We know that IPv6 addresses are primary source of overhead in all RPL control messages. Can we also put general recommendations for addressing fields for any new work?

Also I assume that with PDAO we intend to compress not only the SRVIO but also the VIO used for storing P-DAO and the same scheme will work.

Regards,
Rahul
On Jul 26, 2019, at 08:49, Pascal Thubert (pthubert) <pthubert@cisco.com<mailto:pthubert@cisco.com>> wrote:

Dear all

This is hopefully the last item of the list of things we discussed at the group and need to follow up on.

At the time we wrote RFC 6550 we thought that compression was out of scope, that we cared about the semantics, and that a 6LoWPAN thing would rapidly come and compress the RPL control plane packets.
We actually did RFC 8138 for the data plane, but the control plane work has not started yet. So for PDAO, the question is, should we keep the RPL tradition of uncompressed specs, or natively propose an RFC 8138 format for the PDAO.

Having a native PDAO format would allow to copy paste the source route header in non-storing PDAO. Would make the messages shorter. Would hint how to do the rest of the RPL control plane compression.
I’m willing to propose an update in that direction, would like to see feedback on the ML.

What do you all think?

Pascal
_______________________________________________
Roll mailing list
Roll@ietf.org<mailto:Roll@ietf.org>
https://www.ietf.org/mailman/listinfo/roll

v2.23.0 | Report a Bug | By Email