Re: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-00 absence of addressing the multi-channel service of 802.11 OCB

François Simon <fygsimon@gmail.com> Mon, 13 February 2017 15:53 UTC

Return-Path: <fygsimon@gmail.com>
X-Original-To: its@ietfa.amsl.com
Delivered-To: its@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B258B12966C for <its@ietfa.amsl.com>; Mon, 13 Feb 2017 07:53:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 6yvuOww7UKQ7 for <its@ietfa.amsl.com>; Mon, 13 Feb 2017 07:53:11 -0800 (PST)
Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B15981296D3 for <its@ietf.org>; Mon, 13 Feb 2017 07:53:09 -0800 (PST)
Received: by mail-qk0-x236.google.com with SMTP id u25so97117517qki.2 for <its@ietf.org>; Mon, 13 Feb 2017 07:53:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=mfL6Ux3jAUcP4xBZ91LovoeqF6ljoFOL8gf4pSatLn4=; b=CdtI2Xz2bcRonYThfqv4S4gomYELsxuvTGSlCT1Wy3iFHdOfbzUgHZCqlIZxP1WnnI 2n03bpmJ+/jsJQCwYtR3ReHfuCZmeU8JIHaPebAjSGV7C8xlNdrhwo90LtNHEd3jd65d ri0uzY0zOWtOrejadXuvpzEfn5Q9N0SR8DjY0LoouHvwlXSoT1QP25NpoZj/y/o1bD0u d9um3EAEo3vw6D+SelRnzMH8XBxgsueTWkTsJ0SZMDLMPQaiaw+p5tcmetWrWKMFWs2V Wq+DpVppICG8srbyHCvpawyRy+b3F8zWtDKuYL7OouyOY0PxGBV/IUR4u1qjKdns3dyY AF4A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=mfL6Ux3jAUcP4xBZ91LovoeqF6ljoFOL8gf4pSatLn4=; b=HQThoC4mAC2EI0oUP703RKdr1ErrBAUhgveg+CEj4hA1MZBgktRKpu7T7C9PXiZ2Rc KuccgeRx4Q3vbtjQ4KxZrusD8FrJwVxHLs3zGc6Uf/4zbvlA7pb1eQ2Pea05Ym4Odl4U uz05vsTVTHS6VLXEUn4nhmJZRtsv8cJ+8IjhLZs0s+DGdEfvQhJOjdRkWx4F1M+3CmcO a/Xi03UslZpQAgjhbPLd0u0SpV6tDu5dNDeg8P7NVwMtT1g2Stea3Rk9Bv//Zhvw0IRm f1OwGF14sT4Vo0vFjIA4762br0ot4E0RMKa1KgyGvuX0ESQsDkGcxuYnkL4MvydsbfRx x4LA==
X-Gm-Message-State: AMke39nHIAjqCFhZ7WJ67oArsLOpU4n/UnnbzBzbvKut4gngMFso5+YpadQpX++k3uSJlQ==
X-Received: by 10.55.66.68 with SMTP id p65mr21073841qka.187.1487001187218; Mon, 13 Feb 2017 07:53:07 -0800 (PST)
Received: from FrancoisPC (pool-173-66-69-120.washdc.fios.verizon.net. [173.66.69.120]) by smtp.gmail.com with ESMTPSA id 43sm7746951qty.26.2017.02.13.07.53.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Feb 2017 07:53:06 -0800 (PST)
From: François Simon <fygsimon@gmail.com>
To: 'Jérôme Härri' <jerome.haerri@eurecom.fr>
References: <148052970170.9607.12043916621198119260.idtracker@ietfa.amsl.com> <3046d8b9-0079-99f0-9e9a-f5f88c9c8f5a@cea.fr> <012301d28394$4c0a7d40$e41f77c0$@eurecom.fr> <02bc01d283d8$c7a5eb80$56f1c280$@gmail.com> <00ab01d28469$48d35e50$da7a1af0$@eurecom.fr>
In-Reply-To: <00ab01d28469$48d35e50$da7a1af0$@eurecom.fr>
Date: Mon, 13 Feb 2017 10:53:05 -0500
Message-ID: <008f01d28611$442ad730$cc808590$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQJOjypQjcVLCnmBW2ydKpCtKDvNtwGpzVvTAW+TjdkBYR2VCgGr4eiDoD3MEdA=
Content-Language: en-us
Archived-At: <https://mailarchive.ietf.org/arch/msg/its/JB1TVPIBHtSUzDxWfEF9_cxjpIA>
Cc: fygsimon@gmail.com, 'Alexandre Petrescu' <alexandre.petrescu@gmail.com>, its@ietf.org
Subject: Re: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-00 absence of addressing the multi-channel service of 802.11 OCB
X-BeenThere: its@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF <its.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/its>, <mailto:its-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/its/>
List-Post: <mailto:its@ietf.org>
List-Help: <mailto:its-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/its>, <mailto:its-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Feb 2017 15:53:13 -0000

Agreed.  The point is just a "caution".  IEEE 1609 does specified that the
MAC sub-layer is enhanced with Multi-Channel Operation function (IEEE
1609.4).  The protocol model shows the MAC sub-layer as "WAVE MAC (including
channel coordination )" on the data plane. However, I do not believe that
the coordination is actually performed by the MAC itself (data plane), but
rather in the SME.

Fygs

-----Original Message-----
From: Jérôme Härri [mailto:jerome.haerri@eurecom.fr] 
Sent: Saturday, February 11, 2017 8:18 AM
To: 'François Simon' <fygsimon@gmail.com>; its@ietf.org
Cc: 'Alexandre Petrescu' <alexandre.petrescu@gmail.com>
Subject: RE: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-00 absence of
addressing the multi-channel service of 802.11 OCB

Dear François,

Totally agree. But this is neither DSRC nor 802.11 OCB. This is the IEEE
WAVE stack IEEE 1609.4, which as far as I understand this IETF WG does not
assume to use (and neither the ETSI ITS stack). 

But actually, It is very simple to use different channels using OCB. As
there is no BSS (or IBSS), you can change channel simply by indicating to
the OCB a new channel...as there is no further process required to transmit
on the new channel. 

Yet, the challenge is to be sure that the 'receivers' are also on the
'other' channel, as otherwise, we will transmit and nobody will be there to
receive. That was the objective of the work done in IEEE 1609.4. But such
coordination can also be done purely on an IP(v6) stack, as both Tx and Rx
could be notified on the right channel to get the right message...
A simple indication to OCB on which channel to move would be enough. Even a
multi-channel monitoring can be done using IP(v6) stack, where a
higher-layer service would ask OCB to periodically switch between channel
and monitor  'something'. 

Well, long story short, I do not think multi-channel 'operation' should be
part of this draft. But we could describe how IPv6 can 'request' a channel
switch to OCB. That could indeed be worth mentioning this explicitly. 

BR,

Jérôme

 
-----Original Message-----
From: François Simon [mailto:fygsimon@gmail.com]
Sent: Friday 10 February 2017 21:04
To: 'Jérôme Härri'
Cc: 'Alexandre Petrescu'; fygsimon@gmail.com
Subject: RE: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-00 absence of
addressing the multi-channel service of 802.11 OCB

Multi-channel means that a single device is capable of maintaining multiple
"conversations" quasi-simultaneously.  In the US, the MAC extension (IEEE
1609.4) allows you to support multiple channels under the control of CCH (Ch
178) - TDM.  The problem with this, is you limit your actual overall
transmission rate.  The accepted practice in the US,  is that one radio is
dedicated to a permanent channel to get the maximum data rate (e.g. CH 172)
and used for high-priority applications (i.e. Safety).  Another radio, for
lower priority applications, is allowed to switch channels.  In addition,
each channel can support up to four EDCA parameter sets.  Very "nifty" but
hell to maintain all the state machines!

Fygs



-----Original Message-----
From: its [mailto:its-bounces@ietf.org] On Behalf Of Jérôme Härri
Sent: Friday, February 10, 2017 6:53 AM
To: 'Alexandre Petrescu' <alexandre.petrescu@gmail.com>; its@ietf.org
Subject: Re: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-00 absence of
addressing the multi-channel service of 802.11 OCB

Hello Alex,

What do you mean with multi-channel? OCB does not provide any multi-channel
service. Higher-layer services do (IEEE WAVE or ETSI)...OCB only assume that
the frequency to be used is 'known', so using OCB actually means knowing a
set of channels where to send OCB-related packets...I am not sure if this
could be called a multi-channel service...

However, we should mention that IPv6 would intend to offer such a
service...if this is what you meant, I agree with you.

Best Regards.

Jérôme

-----Original Message-----
From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu
Sent: Friday 10 February 2017 12:13
To: its@ietf.org
Subject: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-00 absence of
addressing the multi-channel service of 802.11 OCB

draft-ietf-ipwave-ipv6-over-80211ocb-00
absence of addressing the multi-channel service of 802.11 OCB

Hello IPWAVErs,

We received a comment stating that this document does not really address the
multi-channel service that 802.11 OCB is capable of providing.

I agree with the comment.

I have not seen other IPv6-over-foo documents addressing channel issues.

There is no IPv6-over-WiFi RFC, which could address them.

In vehicular networks implementations there is often a careful planning of
channel allocation to avoid interference.  Dynamic channel use schemes
exist.

Yours,

Alex



_______________________________________________
its mailing list
its@ietf.org
https://www.ietf.org/mailman/listinfo/its