Re: [6tisch] tagging join traffic wih DSCP: why inside IP header?

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Wed, 15 November 2017 09:42 UTC

Return-Path: <pthubert@cisco.com>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 574EC128DF3 for <6tisch@ietfa.amsl.com>; Wed, 15 Nov 2017 01:42:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.509
X-Spam-Level:
X-Spam-Status: No, score=-14.509 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 khgvqfcYSeqK for <6tisch@ietfa.amsl.com>; Wed, 15 Nov 2017 01:42:40 -0800 (PST)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8D42127337 for <6tisch@ietf.org>; Wed, 15 Nov 2017 01:42:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=42834; q=dns/txt; s=iport; t=1510738959; x=1511948559; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=XGTreTq2uCKB//N9wpb9EsNtbdqKJqrunsoKe3ynjII=; b=ED4MhCn8jEocSH0vQ/h/ugxwYXVZHaNRbQbDS8mnmStKF02myQ27ofqN cYDK+tK/5QOvfuok7hPvmxFLzLOrWSQb76HGm5bP+P6CIqBRNmI23lH9b U8QrzUAasQknhANcY1y4zSGpuYwECmaWzTKUYa2zQlg1CI33WCtuRA1rF o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CpAABuCwxa/40NJK1TChkBAQEBAQEBAQEBAQEHAQEBAQGCRHJkbicHg3iKH48igX2WWoIOAwoYAQyBXIJrTwIahG0/GAEBAQEBAQEBAWsohR4BAQEBAgEBASEEBjoHCwUHBAIBCBEEAQEhAQYDAgICJQsUCQgCBA4FCBKJJlwIEKpWgW06ixcBAQEBAQEBAQEBAQEBAQEBAQEBAQEdgzSCB4FVgWmDKoRhDGEIgleCYwWiNwKHa40Qgh6GCoQEhyGMbokSAhEZAYE4AR84gXR6FUmCZAmEVncBAYYbgTOBEQEBAQ
X-IronPort-AV: E=Sophos; i="5.44,398,1505779200"; d="scan'208,217"; a="31700482"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Nov 2017 09:42:38 +0000
Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id vAF9gc8k011712 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 15 Nov 2017 09:42:38 GMT
Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 15 Nov 2017 03:42:38 -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.1320.000; Wed, 15 Nov 2017 03:42:38 -0600
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Thomas Watteyne <thomas.watteyne@inria.fr>
CC: Michael Richardson <mcr+ietf@sandelman.ca>, "6tisch@ietf.org" <6tisch@ietf.org>
Thread-Topic: [6tisch] tagging join traffic wih DSCP: why inside IP header?
Thread-Index: AQHTXX7XkXA3VPJ770+1uJQzOJ8GOaMUpmAwgADiMID//5+aMA==
Date: Wed, 15 Nov 2017 09:42:35 +0000
Deferred-Delivery: Wed, 15 Nov 2017 09:42:30 +0000
Message-ID: <361109c852ca4d8e983f19899648c811@XCH-RCD-001.cisco.com>
References: <CADJ9OA_cKxWZLvfpNXhjNgL1HurfdK-Oqj1M-wU9pK5t+1kU4g@mail.gmail.com> <20396.1510678103@obiwan.sandelman.ca> <32033.1510687749@obiwan.sandelman.ca> <92bca0456cb746c995733131edad10a2@XCH-RCD-001.cisco.com> <CADJ9OA_b2fHUg=3utnCv8iTMZcwL-n3J_H2N6uU=v8SjenjmFA@mail.gmail.com>
In-Reply-To: <CADJ9OA_b2fHUg=3utnCv8iTMZcwL-n3J_H2N6uU=v8SjenjmFA@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.68.210.141]
Content-Type: multipart/alternative; boundary="_000_361109c852ca4d8e983f19899648c811XCHRCD001ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/kayuwLP18nNRj5CPEe0Cq4qJ1iE>
Subject: Re: [6tisch] tagging join traffic wih DSCP: why inside IP header?
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.22
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, 15 Nov 2017 09:42:42 -0000

Hey, not so Thomas.

The 6MAN rules have been bended in more than one way since the times when the IP in IP discussions took place.


1)      RFC8200 allows routers to ignore HbH options so sending the RPI outside the RPL domain is OK. We actually made it ignorable in https://datatracker.ietf.org/doc/html/draft-ietf-roll-useofrplinfo-19#section-3.2



2)      Header insertion is not as Tabu as it was, with segment routing inserting them anyway. So I expect that removing the RPI is OK. Good news, with 6LoRH, it just means ignore the 6LoRH headers, start by decompressing the IPHC and forward just that. It was a design goal for 6LoRH to make the header insertion/deletion, the routing header operations easy to code and debug. The packet starting at the IPHC is exactly what should be decompressed and forwarded, and there is no RPL artifact to it.


DPI means a layer violation. Looking at the IPHC is not. So conceptually, yes that was very far off ☺


Take care,

Pascal

From: Thomas Watteyne [mailto:thomas.watteyne@inria.fr]
Sent: mercredi 15 novembre 2017 16:55
To: Pascal Thubert (pthubert) <pthubert@cisco.com>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>; 6tisch@ietf.org
Subject: Re: [6tisch] tagging join traffic wih DSCP: why inside IP header?

Pascal, Michael,

If there is no IPIP, then everything is easy. But, AFAICT, we want the JRC to be able to live on the Internet, i.e. not per se co-located with the DAGroot. In that case, the Join Request looks like any data packet sent by the JP to an IPv6 address outside the mesh, which triggers IPIP because the outer IP header contains the RPI.

So AFAICT, IPIP is needed unless we mandate that JRC and DAGroot are collocated.

So with IPIP, if we want to play by the rules, forwarding routers (nodes in the mesh) only look at the outer IP header, and treat the inner IP header as opaque. So if we use RFC6282 for that header with TF=b10 so ECN+DSCP are carried inline, it doesn't matter. AFAICT, you recommend to "dig down to IPHC". Looks more and more like my initial recommendation of using DPI wasn't that far off :-)

Thomas

On Wed, Nov 15, 2017 at 2:37 AM, Pascal Thubert (pthubert) <pthubert@cisco.com<mailto:pthubert@cisco.com>> wrote:

Hello Michael:



> I thought that in 8138, that if we didn't need an outer IPIP, that we just used 6loHC (rfc6282... https://tools.ietf.org/html/rfc6282#section-3.2.1)



This is correct. The RPL artifact for the join request is only the RPI, and the packet (going up) looks as follows in both storing and non-storing, assuming the join is a UDP/CoAP packet.



  The format in Figure 16 is logically equivalent to the uncompressed

   format illustrated in Figure 17:



   +-+-+-+- ... -+-+-+-+ ... -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...

   |  IPv6 Header  | Hop-by-Hop |  RPI in       |  ICMP message ...

   |  NH = 58      | Header     |  RPL Option   |

   +-+-+-+- ... -+-+-+-+ ... -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...



               Figure 17: Uncompressed ICMP Packet with RPI



   For a UDP packet, the transport header can be compressed with 6LoWPAN

   HC [RFC6282<https://tools.ietf.org/html/rfc6282>] as illustrated in Figure 18:



   +-+ ... -+-+-...-+-+- ... -+-+-+-+ ... -+-+-+ ... -+-+-+-+-+...

   |11110001| RPI-  | NH=1        |11110CPP| Compressed | UDP

   |Page 1  | 6LoRH | LOWPAN_IPHC | UDP    | UDP header | Payload

   +-+ ... -+-+-...-+-+- ... -+-+-+-+ ... -+-+-+ ... -+-+-+-+-+...

                     <-         RFC 6282<https://tools.ietf.org/html/rfc6282>              ->

                                No RPL artifact



               Figure 18: Uncompressed ICMP Packet with RPI



RFC 8138 places the artifact in front so it is easy to manipulate. After that, you find the IPHC, which encodes the traffic class. Nothing really complex.



A simpler side question is whether the rest of the join flow (response etc…) should trigger allocation of timeslots by the SF or not. If the response only comes for valid requests then I supposed it should.



Take care,



Pascal





-----Original Message-----
From: 6tisch [mailto:6tisch-bounces@ietf.org<mailto:6tisch-bounces@ietf.org>] On Behalf Of Michael Richardson
Sent: mercredi 15 novembre 2017 03:29
To: 6tisch@ietf.org<mailto:6tisch@ietf.org>
Subject: Re: [6tisch] tagging join traffic wih DSCP: why inside IP header?





Michael Richardson <mcr+ietf@sandelman.ca<mailto:mcr+ietf@sandelman.ca>> wrote:

    >> During the WG meeting yesterday, we discussed using DSCP bits as a way

    >> to identify join request/reply messages. We talked about mapping, in

    >> the minimal-security spec, the different DSCP values to scheduling

    >> behavior.



    >> But you indicated the DSCP bits would be in the inside IPv6 header.

    >> That doesn't make sense to me, can you please provide more info? The

    >> outside IPv6 header looks to me like the right place to put the bits.



    > I thought it was a typo, and I passed it by.



    > Why in this non-storing, RPL-aware situation is there even an IPIP outer

    > header for traffic from the proxy to the DODAG root?



Since I re-read Pascal's answer (in the light of my "day"), I now see why it can not go into to the outer IP header, because we didn't not plan for it.

I thought that in 8138, that if we didn't need an outer IPIP, that we just used 6loHC (rfc6282... <https://tools.ietf.org/html/rfc6282#section-3.2.1>    )



If we can agree that this is the way, then I think we also need to agree that certain AFxx would be assigned to available bandwidth, and not cause 6top to allocate any additional bandwidth.  This does not really fit "AF" Diffserv in some ways (which in some ways to buffer/delay rather than drop...).



--

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







_______________________________________________
6tisch mailing list
6tisch@ietf.org<mailto:6tisch@ietf.org>
https://www.ietf.org/mailman/listinfo/6tisch



--
_______________________________________

Thomas Watteyne, PhD
Research Scientist & Innovator, Inria
Sr Networking Design Eng, Linear Tech
Founder & co-lead, UC Berkeley OpenWSN
Co-chair, IETF 6TiSCH

www.thomaswatteyne.com<http://www.thomaswatteyne.com>
_______________________________________