Re: [Roll] [6tisch] [6lo] call for consensus for the RPL RPI / RH3 compression

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 06 January 2015 17:01 UTC

Return-Path: <mcr@sandelman.ca>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D40B1A1A25; Tue, 6 Jan 2015 09:01:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 EOtdsv0dgEEu; Tue, 6 Jan 2015 09:01:56 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E66D1A1A09; Tue, 6 Jan 2015 09:01:56 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id CB97D20098; Tue, 6 Jan 2015 12:07:14 -0500 (EST)
Received: by sandelman.ca (Postfix, from userid 179) id E92BB637FE; Tue, 6 Jan 2015 12:01:54 -0500 (EST)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id D7802637EA; Tue, 6 Jan 2015 12:01:54 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
In-Reply-To: <97A18603-2934-481E-8859-711B00FB359F@gmail.com>
References: <E045AECD98228444A58C61C200AE1BD848AC2314@xmb-rcd-x01.cisco.com>, <CE9445B8-BA8E-4112-B892-6BCDED74D8DC@gmail.com> <23FC8FE6-C41D-4627-99FC-DA51FE5777B8@cisco.com> <97A18603-2934-481E-8859-711B00FB359F@gmail.com>
X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Tue, 06 Jan 2015 12:01:54 -0500
Message-ID: <29592.1420563714@sandelman.ca>
Sender: mcr@sandelman.ca
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/N1wkeHxd1uruE1N_bXt21ofXyDU
Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, "6lo-chairs@tools.ietf.org" <6lo-chairs@tools.ietf.org>, 6man WG <ipv6@ietf.org>, "6lo@ietf.org WG" <6lo@ietf.org>, "int-ads@tools.ietf.org" <int-ads@tools.ietf.org>, "6tisch@ietf.org" <6tisch@ietf.org>
Subject: Re: [Roll] [6tisch] [6lo] call for consensus for the RPL RPI / RH3 compression
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Routing Over Low power and Lossy networks <roll@ietf.org>
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: <http://www.ietf.org/mail-archive/web/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: Tue, 06 Jan 2015 17:01:58 -0000

Ralph Droms <rdroms.ietf@gmail.com> wrote:
    > But ... in my opinion, moving the LLN artifacts to the header/dispatch
    > in the way defined in draft-thubert-6lo-routing-dispatch raises,
    > implicitly, an important architectural issue: is the information in the
    > dispatch header compressed IPv6 headers or headers for an independent,
    > sub-IP protocol?

My answer is that a sub-IP protocol can encapsulate arbitrary layer-3 packets.
In particular, one can have overlapping IP addressing contexts, and there is
no implicit l3-routing assumed between sub-IP protocols.
In the LLN case, the l3-layer is constrained; the additional "tag" (the RPL
Instance ID) is used to select a particular QoS much like the DSCP can do.
Routing between instanceIDs is assumed; but potentially not every node has
the specific routes that permits it to do that.

    > My understanding is that the IETF has made an architectural decision to
    > do all the mesh network forwarding and routing in IPv6, so as to reuse
    > as much as possible existing technology and associated infrastructure
    > such as OAM.  If the dispatch header does not contain compressed IPv6
    > headers, per se, then this architectural question would lead me to
    > investigate the completeness of the new protocol and the impacts of the
    > new protocol on IPv6 and network operations.

I think that all of the HC methods *can* be implemented as Bump-in-the-Stack
activities; and in particular the loop LLN->ethernet->LLN should be
lossless(%). (ethernet->LLN->ethernet is both out of scope [the LLN is never
a transit network], and also potentially lossy as some generality of 6553 and
6554 may sacrificed.

(%)-lossless definition assumes flow label is always zero.

A think that concerns me is that I think that most constrained devices will
not implement HC as a bump in the stack, but will uncompress the headers
directly into internal control structures, and may have loose the ability to
process uncompressed 6553/6554 headers.

One could view this as a vestigal appendix-like thing that evolved away.
This could be regarded as good: less unused/untested code that will get
exploited.   This could be regarded as bad: as frame sizes in LLN radios grow
(802.15.4g, I'm told, has much larger frames) some systems might have no
6lowpan layer, and interoperation opportunities might become difficult.

(I picked the appendix on purpose: some say that it was used to digest
grasses/cellulose. If we had a useful appendix, humans might never starve...)

--
Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-