IETF Logo Mail Archive

Re: [6lo] Possible 6LoWPAN dispatch type deprecation and re-use for route over purposes

Carsten Bormann <cabo@tzi.org> Sun, 03 May 2015 07:33 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: 6lo@ietfa.amsl.com
Delivered-To: 6lo@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31EDA1A01D5; Sun, 3 May 2015 00:33:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.55
X-Spam-Level:
X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=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 9wDmf8PASUuh; Sun, 3 May 2015 00:33:02 -0700 (PDT)
Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 ECAF91A01AE; Sun, 3 May 2015 00:33:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t437Wu3s027226; Sun, 3 May 2015 09:32:56 +0200 (CEST)
Received: from alma.local (p5DCCC91B.dip0.t-ipconnect.de [93.204.201.27]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3lffDS4JMmzDZk7; Sun, 3 May 2015 09:32:56 +0200 (CEST)
Message-ID: <5545CF26.2000205@tzi.org>
Date: Sun, 03 May 2015 09:32:54 +0200
From: Carsten Bormann <cabo@tzi.org>
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: Ralph Droms <rdroms.ietf@gmail.com>
References: <OFC08E0E98.68CBE425-ONC1257E35.002F1A61-C1257E35.003225DE@notes.edfgdf.fr> <2589.1430421685@sandelman.ca> <CADhXe532Pcee5U5C7iDW3FCOFtOWUrtUTuLFm-jRf_W4Pj2U3Q@mail.gmail.com> <5543F1E9.20800@tzi.org> <36E6266C-7293-41C7-9B92-8DDEC1F60B75@gmail.com> <554403ED.1050603@tzi.org> <9C7B4A2C-EDE2-4F78-9DD7-D4F8D9DB73E7@gmail.com>
In-Reply-To: <9C7B4A2C-EDE2-4F78-9DD7-D4F8D9DB73E7@gmail.com>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/6lo/FfcaXblOC4ZBy1-DwTbmDaR3W0o>
Cc: "6lo@ietf.org" <6lo@ietf.org>, Thierry LYS <thierry.lys@erdf.fr>, cedric.chauvenet@erdf.fr, IETF discussion list <ietf@ietf.org>
Subject: Re: [6lo] Possible 6LoWPAN dispatch type deprecation and re-use for route over purposes
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 03 May 2015 07:33:04 -0000


Ralph Droms wrote:
>> On May 1, 2015, at 6:53 PM 5/1/15, Carsten Bormann <cabo@tzi.org> wrote:
>>
>> Ralph Droms wrote:
>>> ITU-T G.9903
>> Thanks for bringing this discussion to a technical level.  So this
>> document has allocated the dispatch code ESC (RFC 6282's value of
>> 01_000000) for the specific purposes of G.9903 ("command frames").
> 
> In my opinion, G.9903 defines the values 0x01-0x1f in the byte following the ESC Dispatch Type.  The other values are still available for use in other protocols.

That's one way to read it, but not quite the way that I get from a
literal read.
It says (9.4.2.3.1):
»As shown in Figure 9-12, the ADP sublayer command frames are identified
using the ESC header type (see clause 5.1 of [IETF RFC 4944]), followed
by an 8-bit dispatch field indicating the type of ADP command.«
So all 256 values are meant to indicate a specific type of ADP command
frame.  Table 9-35 then goes ahead and allocates 31 values of those;
with a gap, so it identifies some as "Reserved by ITU-T".

(I'm not sure I understand the way G.9905 uses this command frame
concept for source routing; it says the command frame carrying the
source route header is "attached to the packet", but it doesn't quite
tell how both the command frame and the packet are transported, given
that "This header" (the command frame header) "shall be in the last
position if more than one header is present in the 6LowPAN frame."
according to 9.4.2.3.1 of G.9903.  I also don't understand how mesh
headers and those source routes mix, or how a forwarding node knows
where in that source route it is.  Oh well, there is probably nothing
there that 6lo would want to steal, anyway.)

However we read this, I agree that it does make a lot of sense to get
the protocol codes used by ITU-T into the IANA registries, and that we
should work with SG-15 to get this done.

(We do indeed disagree about the usefulness of being able to interpret
protocol syntax when there is no way to act on the semantics required
for handling the packet at all.  Self-describing syntax is certainly
good for wireshark etc., and it helps with hardware implementations.  It
is not a categorical imperative, however.)

Grüße, Carsten

v2.23.0 | Report a Bug | By Email