Re: [6tsch] Mobility in 6TSCH
Qin Wang <qinwang@berkeley.edu> Sat, 27 July 2013 14:52 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 BEDF421F99AE for <6tsch@ietfa.amsl.com>;
Sat, 27 Jul 2013 07:52:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.814
X-Spam-Level:
X-Spam-Status: No, score=-2.814 tagged_above=-999 required=5 tests=[AWL=0.162,
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 mWbvG0eN0zge for
<6tsch@ietfa.amsl.com>; Sat, 27 Jul 2013 07:52:20 -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 CAF9A21F99B7 for
<6tsch@ietf.org>; Sat, 27 Jul 2013 07:52:05 -0700 (PDT)
Received: by mail-ob0-f176.google.com with SMTP id v19so6503423obq.35 for
<6tsch@ietf.org>; Sat, 27 Jul 2013 07:52:04 -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=9x1ohdKqz0WT/BzBHuYSnVePbO60ZuTB1B3avDsASwo=;
b=J0z9lXfNOzpl4opxk7l9fum4BrtQp1b+NGgZRsiNaAqDUmIMBZhhN32LgDglIB/fAJ
UMqLaW8atDOAvJ4LpHrn8KmG7WlnKeGfNoSwpZ4ctkxb40mLKESfUUK+ox3Yv+OCPU+m
uy6fQgoZCFA9uDqsX33Hoz51u81ZQ5xrGw1j4egWFCotZRLqBZCiOD/G6lDMnOavdYCA
onkYyQFVTcTYH1i3Zf7GxCcklGaD9QeH7yk9rRS8M1UZi5NbSRAKzMjRLb5tHRgq8V/M
40AwzMRQMwoGoE1xIafzGvAPBKgxW9nq8uQxXGBH+17m3t7gpBNZLZtkE1PZ6G675kx7 4IOA==
MIME-Version: 1.0
X-Received: by 10.50.97.40 with SMTP id dx8mr310603igb.30.1374936724254;
Sat, 27 Jul 2013 07:52:04 -0700 (PDT)
Received: by 10.64.171.82 with HTTP; Sat, 27 Jul 2013 07:52:04 -0700 (PDT)
In-Reply-To: <CALEMV4aNi7=gedgAQz39Mu+Cq04LEXV-aNSWEH-vELq_1DtUeQ@mail.gmail.com>
References: <E045AECD98228444A58C61C200AE1BD8413ABB1B@xmb-rcd-x01.cisco.com>
<CAAzoce4v=7m18FhJij8-H+2Di3EFcEyEY=1c18__HgVLTkf1tQ@mail.gmail.com>
<CADJ9OA8aCJwcipo6CdMQL_n_ru+QCqPTDqYXTVxKE2x5pZBqJg@mail.gmail.com>
<CAM4EQiPSAPrftt6AM30r4YENA_vJ1huQzvVeOMnBnmKne0ea9w@mail.gmail.com>
<E045AECD98228444A58C61C200AE1BD8413AC97F@xmb-rcd-x01.cisco.com>
<CALEMV4aNi7=gedgAQz39Mu+Cq04LEXV-aNSWEH-vELq_1DtUeQ@mail.gmail.com>
Date: Sat, 27 Jul 2013 22:52:04 +0800
Message-ID: <CAAzoce6eW8AnhMfSm4Gfd4Ke6p4PpyUneGH+xDkrGjheBfUZ7g@mail.gmail.com>
From: Qin Wang <qinwang@berkeley.edu>
To: Xavier Vilajosana Guillen <xvilajosana@eecs.berkeley.edu>
Content-Type: multipart/alternative; boundary=047d7b111a2909bfb204e27f6749
X-Gm-Message-State: ALoCoQkDryNCUVA+ERir3bAzJtKcApYM7frm/Y07M5qa0nMOzPEdyoaBQgAHlzDKGYx9ZaZrHu5N
Cc: Thomas Watteyne <watteyne@eecs.berkeley.edu>,
"Pascal Thubert \(pthubert\)" <pthubert@cisco.com>,
Alfredo Grieco <alfredo.grieco@gmail.com>, "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: Sat, 27 Jul 2013 14:52:24 -0000
+1 on "relocation" Qin On Sat, Jul 27, 2013 at 7:42 PM, Xavier Vilajosana Guillen < xvilajosana@eecs.berkeley.edu> wrote: > +1 for relocation, > > "node relocation" > > IMHO is the most suitable candidate. > > :-) > X > > > On Sat, Jul 27, 2013 at 11:41 AM, Pascal Thubert (pthubert) < > pthubert@cisco.com> wrote: > >> Dear all;**** >> >> ** ** >> >> I love the term “relocation”. **** >> >> We probably want a relocation that is transparent to the upper layers.*** >> * >> >> The topology can also be qualified as relatively stable.**** >> >> ** ** >> >> What do others think?**** >> >> ** ** >> >> Cheers,**** >> >> ** ** >> >> Pascal**** >> >> ** ** >> >> *From:* 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] *On >> Behalf Of *Alfredo Grieco >> *Sent:* samedi 27 juillet 2013 10:04 >> *To:* Thomas Watteyne >> *Cc:* 6tsch@ietf.org >> *Subject:* Re: [6tsch] Mobility in 6TSCH**** >> >> ** ** >> >> Almost static topologies ?**** >> >> ** ** >> >> Alfredo >> >> On Saturday, July 27, 2013, Thomas Watteyne wrote:**** >> >> Pascal,**** >> >> ** ** >> >> I understand you are looking for the right term.**** >> >> ** ** >> >> Terms I can think of:**** >> >> - roaming**** >> >> - node relocation**** >> >> - occasional mobility**** >> >> - intermittent relocation**** >> >> ** ** >> >> Thomas**** >> >> ** ** >> >> On Fri, Jul 26, 2013 at 7:50 PM, Qin Wang <qinwang@berkeley.edu> wrote:** >> ** >> >> 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**** >> >> ** ** >> >> >> _______________________________________________ >> 6tsch mailing list >> 6tsch@ietf.org >> https://www.ietf.org/mailman/listinfo/6tsch**** >> >> ** ** >> >> _______________________________________________ >> 6tsch mailing list >> 6tsch@ietf.org >> https://www.ietf.org/mailman/listinfo/6tsch >> >> > > _______________________________________________ > 6tsch mailing list > 6tsch@ietf.org > https://www.ietf.org/mailman/listinfo/6tsch > >
- [6tsch] Mobility in 6TSCH Pascal Thubert (pthubert)
- Re: [6tsch] Mobility in 6TSCH Qin Wang
- Re: [6tsch] Mobility in 6TSCH Thomas Watteyne
- Re: [6tsch] Mobility in 6TSCH Alfredo Grieco
- Re: [6tsch] Mobility in 6TSCH Pascal Thubert (pthubert)
- Re: [6tsch] Mobility in 6TSCH Xavier Vilajosana Guillen
- Re: [6tsch] Mobility in 6TSCH Qin Wang