Re: [6tsch] Mobility in 6TSCH

Qin Wang <qinwang@berkeley.edu> Fri, 26 July 2013 17:50 UTC

Return-Path: <qinwang@berkeley.edu>
X-Original-To: 6tsch@ietfa.amsl.com
Delivered-To: 6tsch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB9F421F8756 for <6tsch@ietfa.amsl.com>; Fri, 26 Jul 2013 10:50:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.79
X-Spam-Level:
X-Spam-Status: No, score=-2.79 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ynxh+6Ovp2Ql for <6tsch@ietfa.amsl.com>; Fri, 26 Jul 2013 10:50:17 -0700 (PDT)
Received: from mail-ob0-f176.google.com (mail-ob0-f176.google.com [209.85.214.176]) by ietfa.amsl.com (Postfix) with ESMTP id A274C21F9633 for <6tsch@ietf.org>; Fri, 26 Jul 2013 10:50:17 -0700 (PDT)
Received: by mail-ob0-f176.google.com with SMTP id v19so4940982obq.35 for <6tsch@ietf.org>; Fri, 26 Jul 2013 10:50:17 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=AX+Fy9ihci4jycEgpbodVOtKGHeszb9vn7FnKtbI3lU=; b=ZYPmAkAyoUUkAGOPcFlCtE9QxPRZEquJKi0wfw/dMc0cRK/I6mPAF+QbK6IiCecus2 qtY853BX3AyussBBNp7lOQzHWVlVfOPgtzzR4xBS0Yp1dAMpFT4sf3Wf4SHsEwSDZjEi 5JE8IK9ePvp3vNeg1liSL8/O0rADX3QwKK416j9fhIQKm63yuxQhB+tgp3OMDanj9c6z 8vY3jdPi2l1NoRR5tgCivRR87cv79mX83FphTuv0bleM4dxP9+aOFgXc2kjSRKe47rf7 2Js2tkzffCS/2dapcqx37QG+R7GgSjwDd8wATVIwxCuCVlRYHBY93kvPULZ1M6bFBnfO i37Q==
MIME-Version: 1.0
X-Received: by 10.42.11.211 with SMTP id v19mr19996041icv.29.1374861015989; Fri, 26 Jul 2013 10:50:15 -0700 (PDT)
Received: by 10.64.171.82 with HTTP; Fri, 26 Jul 2013 10:50:15 -0700 (PDT)
In-Reply-To: <E045AECD98228444A58C61C200AE1BD8413ABB1B@xmb-rcd-x01.cisco.com>
References: <E045AECD98228444A58C61C200AE1BD8413ABB1B@xmb-rcd-x01.cisco.com>
Date: Sat, 27 Jul 2013 01:50:15 +0800
Message-ID: <CAAzoce4v=7m18FhJij8-H+2Di3EFcEyEY=1c18__HgVLTkf1tQ@mail.gmail.com>
From: Qin Wang <qinwang@berkeley.edu>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
Content-Type: multipart/alternative; boundary=20cf301d3e60794c1204e26dc68c
X-Gm-Message-State: ALoCoQnw2eLckXxYEwXUM7mhGvQ8Zb3a9Tqvu8cFA0BbuENhvVoL9Zrwrvo+1GzmyGcqgs2ENiFA
Cc: "6tsch@ietf.org" <6tsch@ietf.org>
Subject: Re: [6tsch] Mobility in 6TSCH
X-BeenThere: 6tsch@ietf.org
X-Mailman-Version: 2.1.12
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" <6tsch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tsch>, <mailto:6tsch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/6tsch>
List-Post: <mailto:6tsch@ietf.org>
List-Help: <mailto:6tsch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tsch>, <mailto:6tsch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Jul 2013 17:50:22 -0000

Hi Pascal and All,

How about "dynamic adjustment". Because,

In steady network (fixed location and predictable traffic load),  the
features of deterministic and low energy consumption have definitely been
provided. What we want to do is, with distributed reservation and RPL, the
deterministic and low energy consumption features can be extended to the
dynamic network (some degree of location change and/or some degree of
traffic load change).

Thought?

Qin




On Sat, Jul 27, 2013 at 12:20 AM, Pascal Thubert (pthubert) <
pthubert@cisco.com> wrote:

> Dear all;
>
> As you know, determinism and fast mobility are quite antagonistic in
> nature.
>
> Even with distributed routing, there are a number of issues like timeslot
> allocation and security context transfer or (re)establishment that will
> delay the mobility.
> In 6TSCH, we have use cases that we want to serve like the crane and the
> mobile handset, which require a certain degree of mobility but probably not
> make before break or sub-second reconnection. So we want to express that we
> aim at supporting this limited mobility but we do not want to raise the
> expectation higher than we can actually serve.
>
> The mobility term is so overloaded that it might be misleading. Would you
> have a suggestion for term that would be more appropriate?
>
> (I heard the terms soft, limited, and constrained so far)
>
> Cheers,
>
> Pascal
>
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch
>