Return-Path: 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 AD9F321F9317 for <6tsch@ietfa.amsl.com>; Fri, 29 Mar 2013 10:00:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 6lYwmfA4TwVQ for <6tsch@ietfa.amsl.com>; Fri, 29 Mar 2013 10:00:30 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 55B6921F92B5 for <6tsch@ietf.org>; Fri, 29 Mar 2013 10:00:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=42138; q=dns/txt; s=iport; t=1364576429; x=1365786029; h=from:to:subject:date:message-id:mime-version; bh=BgGRixnLWoIWFIuexehx2iUmzjK1bYUqtu4I4m4lgvM=; b=WjFhjKmiZGyaB4NHUWDaMbcDiJgrpVePQYzeOKJwFjOY7OzSdLnTlCkD bTXfjS9U3RyyqYUcnlRBPtqao1tpVjnZyTMFLKJoR4j1KLiQNfuqXA5fC tfd+hcVDCm0Ki25NZfhHLx4EUDLJJq+fJsNXvBUK08wBaatBWnJYWA1pK M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFALzHVVGtJV2a/2dsb2JhbABDgkN3vyiBChZ0giEBBC1eASoWAT8mAQQbiAyfA6EBiQ2FaYMXYQOndoMLgig X-IronPort-AV: E=Sophos;i="4.87,374,1363132800"; d="scan'208,217";a="193012269" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP; 29 Mar 2013 17:00:21 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r2TH0JFT016926 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <6tsch@ietf.org>; Fri, 29 Mar 2013 17:00:19 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.152]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0318.004; Fri, 29 Mar 2013 12:00:19 -0500 From: "Pascal Thubert (pthubert)" To: "6tsch@ietf.org" <6tsch@ietf.org> Thread-Topic: Problem Statement Thread-Index: Ac4snqmG4qAbAH7VRrO/jcsMdbDAqQ== Date: Fri, 29 Mar 2013 17:00:18 +0000 Deferred-Delivery: Fri, 29 Mar 2013 16:59:00 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.93.37] Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD835D07C7Dxmbrcdx01ciscoc_" MIME-Version: 1.0 Subject: [6tsch] Problem Statement 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 17:00:31 -0000 --_000_E045AECD98228444A58C61C200AE1BD835D07C7Dxmbrcdx01ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi : Please find a list I xrefed from the use cases we discussed at the call and= over the ML; , what did I miss? Please fire at will... P1: Optimized Multipath hard tracks * From - wireless process control; low rate control loops - Smart cities; WSN service provider - Vehicular; control IHM * Optimized =3D> PCE * Allocation may be handled by a tier * 6TUS must apply the required slots and move existing if needed P2: Distributed Routing, soft tracks < unsure which use cases?> * =3D> RSVP or similar P3 : Distributed Routing (best effort) * From - Industrial; non production phases - Industrial, Smart cities, home; monitoring - Commercial; asset tracking - Home, Commercial; security * Distributed =3D> RPL P4: Mobility (best effort) * From - Industrial; mobile worker - Commercial; asset tracking * Distributed =3D> RPL P5: Dynamic slot allocation * From - Industrial; alerts - Smart cities; Road/Street control - Smart cities; Smart Urban Parking * 6TUS must adapt to bursts * Need to be faster than transport reaction P6: Backbone * From - Industrial; large plant * Renumbering is not an option * One IPv6 subnet incorp. WSNs and backbone * Need to mark the packet for Diffserv P7: Large/Deep Mesh * From - Smart cities; city lights monitoring - Building automation; * RPL / distributed * Need different PHYs to get range P8: Coexistence with legacy * From - industrial (ISA100.11a, wiHART...) * Maybe achieved well enough by TSCH MAC already * May be achieved by channel white/black list * No goal: sync various networks and W/B list at the granularity of t= he slot Cheers, Pascal --_000_E045AECD98228444A58C61C200AE1BD835D07C7Dxmbrcdx01ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi :

 

Please find a list I xrefed from the use cases we di= scussed at the call and over the ML; , what did I miss?

Please fire at will…

 

P1: Optimized Multipath hard tracks

       From

      wireless process control; low rate control l= oops

      Smart cities; WSN service = provider

      Vehicular; control IHM

       Optimized =3D> PCE

       Allocation may be handled by a tier

       6TUS must apply the required slots and move = existing if needed

 

P2: Distributed Routing, soft trac= ks

< unsure which use cases?>

       =3D> RSVP or similar

 

P3 : Distributed Routing (best effort)

        From

      Industrial; non production= phases

      Industrial, Smart cities, = home; monitoring

      Commercial; asset tracking=

      Home, Commercial; security=

       Distributed =3D> RPL

 

P4: Mobility (best effort)

       From

      Industrial; mobile worker<= /span>

      Commercial; asset tracking=

       Distributed =3D> RPL

 

P5: Dynamic slot allocation

       From

      Industrial; alerts<= o:p>

      Smart cities; Road/Street = control

      Smart cities; Smart Urban = Parking

       6TUS must adapt to bursts<= /span>

       Need to be faster than transport reaction

 

P6: Backbone

       From

      Industrial; large plant

       Renumbering is not an opti= on

       One IPv6 subnet incorp. WSNs and backbone

       Need to mark the packet for Diffserv

 

P7: Large/Deep Mesh

       From

      Smart cities; city lights = monitoring

      Building automation;

       RPL / distributed

       Need different PHYs to get range<= /p>

 

P8: Coexistence with legacy

       From

      industrial (ISA100.11a, wiHART…)<= /o:p>

       Maybe achieved well enough by TSCH MAC alrea= dy

       May be achieved by channel white/black list<= o:p>

       No goal: sync various networks and W/B list = at the granularity of the slot

 

Cheers,

 

Pascal

 

 

 

 

--_000_E045AECD98228444A58C61C200AE1BD835D07C7Dxmbrcdx01ciscoc_-- Return-Path: 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 385D021F8B64 for <6tsch@ietfa.amsl.com>; Thu, 28 Mar 2013 11:45:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.377 X-Spam-Level: X-Spam-Status: No, score=-0.377 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, 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 8YO2-hymSh3v for <6tsch@ietfa.amsl.com>; Thu, 28 Mar 2013 11:45:27 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id C703721F88F5 for <6tsch@ietf.org>; Thu, 28 Mar 2013 11:45:23 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id hr11so7963145vcb.17 for <6tsch@ietf.org>; Thu, 28 Mar 2013 11:45:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding:x-gm-message-state; bh=1cGxO+NOdSqN2mVI/6ycen3750miX2etmvUG1y7hMfc=; b=QM/pwH8iFY/Mfhr6gSolGgOWa8CAOx+rs5icDB5L0owFvBYo5jT7VmuX3S1z1WzJmN OUo8S3r37hSVvQvSdrrQis5cS0fOuJoWr3We6NpxZhyFUEuHnoKqgNdM2NCeyNb5s7Tz eQFww7/BDHhB9dFTt3wi42GbjUqYTtqSJrOvE4I0Ca1mMtTdyXpd5Dtbi7W0QhgkUwwh B+G74tJUTKt3gtjbkMhHVCYh4PIH85mrNOfQ9ysjhy3YJaW9GnkJRkLBJRaUnikz7+fu EJgiS9fplRxdelNTVqN117xZsQjm1RTxoRyFGABq/hDHf9t9zXIB9r3C55n/wWIUQhes KWKg== MIME-Version: 1.0 X-Received: by 10.220.142.71 with SMTP id p7mr27993441vcu.3.1364496323008; Thu, 28 Mar 2013 11:45:23 -0700 (PDT) Received: by 10.52.160.104 with HTTP; Thu, 28 Mar 2013 11:45:22 -0700 (PDT) X-Originating-IP: [71.195.166.116] In-Reply-To: References: Date: Thu, 28 Mar 2013 11:45:22 -0700 Message-ID: From: "SenSys'13 Publicity" To: 6tsch@ietf.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkmUmHq6xidRs8V6MTT3uw8nRSHDtyVLQUmAHJRYb9Jt0irl7vGkB+nTncA0oIwSVSLO/2K Subject: [6tsch] CFP: SenSys 2013 -- The 11th ACM Conference on Embedded Networked Sensor Systems 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 18:45:27 -0000 [Apologies in advance for any cross-postings] Dear colleagues. There are only 2 DAYS! remaining for abstract registration. ***************************************************************************= ************************ Call For Papers SenSys 2013---The 11th ACM Conference on Embedded Networked Sensor Systems November 11-15, 2013 Rome, Italy ***************************************************************************= ************************* Sensing systems are changing the way computers interact with the physical world -- and are driving a host of new issues in computer system design, implementation, and performance. SenSys 2013 is the premier venue to discuss system issues raised by emerging trends in sensing systems =96 broadly defined to include mobile sensing, body sensing, Kinect, camera networks, RFID, and many others. We solicit technical papers describing original ideas, ground breaking results and/or quantified system experiences involving sensor systems. The conference values papers that take a broad systems perspective rather than a narrow focus on individual components. Of particular interest are technical contributions that enable new and compelling sensing applications. Topics of interest include, but are not limited to, the following: * Experience with real-world applications * Innovative sensing applications (e.g., mobile healthcare, transportation, buildings) * New models of sensor usage (e.g., mobile sensing, body sensing, RFIDs, ro= bots) * Sensor data quality, integrity, and trustworthiness * Challenges for =93Big Sensor Data=94 * Sensor data storage, retrieval, processing and management * Data reduction, inference, and signal processing * Fault-tolerance and reliability * Provable correctness and performance guarantees * Support for integrated sensing, actuation and control * Wireless communication systems and protocols * Energy management and energy harvesting * Resource management and OS support * Programming paradigms for sensing systems * Security and privacy in sensor networks * Time and location estimation and management Detailed submission instructions can be found at http://sensys.acm.org/2013/submissions/ Key Dates These are hard deadlines: No extensions will be granted. * Paper Registration: March 30, 2013, 11:59 pm EST. * Paper Submission Deadline: April 6, 2013, 11:59 pm EST. * Notification of Paper Acceptance: July 15, 2013. General Chair Chiara Petrioli (University of Rome 'La Sapienza') Program Chairs Landon Cox (Duke University) Kamin Whitehouse (University of Virginia) Poster Chair Chenyang Lu (Washington University in St. Louis) Luca Mottola (Politecnico di Milano and Swedish Institute of Computer Scien= ce) Demo Chairs Emiliano Miliuzzo (AT&T Labs) Amy Murphy (FBK) Local Arrangements Chairs Francesca Cuomo, Gaia Maselli, Andrea Vitaletti (University of Rome 'La Sapienza') Finance Chair Rasit Eskicioglu (University of Manitoba) Publicity Chairs Stefano Basagni (Northeastern University) Alberto Cerpa (University of California, Merced) Salil Kanhere (University of New South Wales) Mike Chieh-Jan Liang (Microsoft Research Asia) Publicaton Chair Wendi Heizelman (University of Rochester) Workshop Chairs Luca Benini (ETHZ & University of Bologna) Deepak Ganesan (UMASS Amherst) Industrial Liaison Chairs Jie Liu (Microsoft Research) Adam Wolisz (Technische Universitat Berlin) N2Women Chair Niki Trigoni (University of Oxford) Doctoral Colloquium Chair Cecilia Mascolo (University of Cambridge) Student Travel Award Chair Pedro Marron (University of Duisburg-Essen) Radu Stoleru (Texas A&M University) Web Site Chair David Boyle (Imperial College London) Technical Program Committee Yuvraj Agarwal (University of California, San Diego) Jan Beutel (Swiss Federal Institute of Technology, Zurich) Geoffrey Challen (University at Buffalo) Tanzeem Choudhary (Cornell University) David Chu (Microsoft Research, Redmond) Deborah Estrin (Cornell Tech) Wen Hu (CSIRO, Australia) Fred Jiang (Intel Labs, China) Nic Lane (Microsoft Research, Asia) Jie Liu (Microsoft Research, Redmond) Pedro Jose Marron (University of Duisburg Essen) Cecilia Mascolo (University of Cambridge) Luca Mottola (Politecnico di Milano and Swedish Institute of Computer Scien= ce) Lama Nachman (Intel Labs) Gian Pietro Picco (University of Trento) Raj Rajkumar (Carnegie Mellon University) Anthony Rowe (Carnegie Mellon University) Romit Roy Choudhury (Duke University) Silvia Santini (Technische Universitat Darmstadt) Mahadev Satyanarayanan (Carnegie Mellon University) Thomas Schmid (University of Utah) Junehwa Song (Korean Advanced Institute of Science and Technology) Niki Trigoni (University of Oxford) Lin Zhong (Rice University) Return-Path: 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 7F80521F918D for <6tsch@ietfa.amsl.com>; Wed, 27 Mar 2013 11:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 QFDa+-Caehtg for <6tsch@ietfa.amsl.com>; Wed, 27 Mar 2013 11:15:51 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 51E5B21F910D for <6tsch@ietf.org>; Wed, 27 Mar 2013 11:15:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3328; q=dns/txt; s=iport; t=1364408150; x=1365617750; h=from:to:subject:date:message-id:mime-version; bh=PjmQsWp3bizmy3LpwiZ3B7KYUpPiW5Mec14XIwY7hTQ=; b=VjU9bF1dLnaSI5JikZVwEUE4baldwQoMFWCU/MgXUts9VkPZwW/+e1GR 3DsA4MbCH4QKQyUUaEVzhnc65s5HJXwQc1eI6wtGWBijX8hWqY0cgvEVz XPBEo7j+T9gcGUFYrm96lYuX1dx6ZiH6apzcdYrXRM7gbOeYjJJCs2AQZ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFABA3U1GtJXHB/2dsb2JhbABDgkN3wEd/Fm0HgiEBBB0QXgEMHlYmAQQbiAyeAKELiQWFYoMXYQOnboMLgig X-IronPort-AV: E=Sophos;i="4.84,920,1355097600"; d="scan'208,217";a="192168654" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-6.cisco.com with ESMTP; 27 Mar 2013 18:15:49 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r2RIFmEl025356 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <6tsch@ietf.org>; Wed, 27 Mar 2013 18:15:48 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.152]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Wed, 27 Mar 2013 13:15:48 -0500 From: "Pascal Thubert (pthubert)" To: "6tsch@ietf.org" <6tsch@ietf.org> Thread-Topic: no Call this week Thread-Index: Ac4rFsgdWQIb6V+BSPGkf9KkoDHNPQ== Date: Wed, 27 Mar 2013 18:15:47 +0000 Deferred-Delivery: Wed, 27 Mar 2013 18:14:00 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.98.126] Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD835D05FD4xmbrcdx01ciscoc_" MIME-Version: 1.0 Subject: [6tsch] no Call this week 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 18:15:52 -0000 --_000_E045AECD98228444A58C61C200AE1BD835D05FD4xmbrcdx01ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear ML: I got feedback that many would be taking the long week end off. So let us cancel the call for this week and start fresh next week. In the meantime, let's start a thread on problem statement from which we'll= derive a gap analysis Cheers; Pascal --_000_E045AECD98228444A58C61C200AE1BD835D05FD4xmbrcdx01ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear ML:

 

I got feedback that many would be taking the long we= ek end off.

So let us cancel the call for this week and start fr= esh next week.

In the meantime, let’s start a thread on probl= em statement from which we’ll derive a gap analysis

 

Cheers;

 

Pascal

--_000_E045AECD98228444A58C61C200AE1BD835D05FD4xmbrcdx01ciscoc_-- Return-Path: 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 2EC3621F9075 for <6tsch@ietfa.amsl.com>; Mon, 25 Mar 2013 09:36:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] 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 NOPEi0qEKR2g for <6tsch@ietfa.amsl.com>; Mon, 25 Mar 2013 09:36:21 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 5A20721F9037 for <6tsch@ietf.org>; Mon, 25 Mar 2013 09:36:20 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id AE3CD2DC154; Mon, 25 Mar 2013 17:36:19 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 8F8AB23808F; Mon, 25 Mar 2013 17:36:19 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Mon, 25 Mar 2013 17:36:19 +0100 From: To: Thomas Watteyne , "6tsch@ietf.org" <6tsch@ietf.org> Thread-Topic: [6tsch] focussing on charter: use cases Thread-Index: AQHOKXZb4544fW5MRUSgOucw3DT4aZi2mrvw Date: Mon, 25 Mar 2013 16:36:18 +0000 Message-ID: <15579_1364229379_51507D03_15579_186_1_8F1D83ADCC1AC94186A867BEE9B7D91306D39889@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <6194_1364051635_514DC6B3_6194_19669_1_8F1D83ADCC1AC94186A867BEE9B7D91306D39033@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.3] Content-Type: multipart/alternative; boundary="_000_8F1D83ADCC1AC94186A867BEE9B7D91306D39889PEXCVZYM13corpo_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.3.25.85421 Subject: Re: [6tsch] focussing on charter: use cases 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 16:36:26 -0000 --_000_8F1D83ADCC1AC94186A867BEE9B7D91306D39889PEXCVZYM13corpo_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Thomas, This is exactly what I had in mind, thanks! Dominique De : 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] De la part de T= homas Watteyne Envoy=E9 : lundi 25 mars 2013 17:33 =C0 : 6tsch@ietf.org Objet : Re: [6tsch] focussing on charter: use cases Dominique, Thanks for your comments. We certainly do not want to be overly simplistic.= When identifying use cases, I believe we should focus on what makes TSCH d= ifferent, and articulate the use cases around those. As you point out, traf= fic differentiation is certainly very high on that list. An immediate use case is that of an entity operating an "umbrella" network = on which different types of traffic flow, possibly coming from customers of= this entity. When a new customer asks to be granted access to the network,= the network operator can predict with pretty good granularity the the impa= ct this new traffic on the remaining bandwidth of the network, and on the p= ower consumption of individual motes, which allows the operator to grant/de= ny, and probably charge differently. Does this use case match what you were thinking? Thomas On Sat, Mar 23, 2013 at 8:13 AM, > wrote: Hello Thomas, all, Regarding your point - because of a 6TSCH node is deeply duty cycle, remote sensing application = (e.g. agricultural applications) can rely on energy harvesting as power sou= rce. I still need to be convinced that 6tsch allows for a lower power consumptio= n than preamble sampling on very low traffic. Therefore I don't think we sh= ould say "6tsch is lower power therefore makes possible new applications therefore w= e should standardize 6tsch". This is overly simplistic. Other arguments that were stated, such as determinism, which is mandated by= industry automation, is a much better seller. To add another one, as I stated in an earlier phone conference, I believe T= SCH is of interest to build mutualized sensor networks that can support sev= eral end customers or services. This is because one can allocate bandwidth = to each supported service independently of the others (under some limits). = This can be modeled beforehand, a decision can be made to admit the new cus= tomer/service or not, and the network can be managed to allocate temporary = extra resources to maintain QoS while a technician is sent to the field to = investigate such things as node failure or severe interference. Granted, se= veral node resources such as energy and memory are still shared between cus= tomers/services but TSCH allows to model and manage these much better than = other wireless link layers. Such a mutualized managed network is much more likely to be profitable and = makes a better use of spectrum than independent, overlaid networks fighting= for the same wireless medium. To a company intending to deploy, operate and manage a sensor network infra= structure, TSCH is good starting point. Comments? Dominique De : 6tsch-bounces@ietf.org [mailto:6tsch-bo= unces@ietf.org] De la part de Thomas Watteyne Envoy=E9 : jeudi 21 mars 2013 06:16 =C0 : 6tsch@ietf.org Objet : Re: [6tsch] focussing on charter: use cases Pascal, all, Absolutely agreed. I believe we have started exploring quite a bit, enough = to have a clear understanding of what we can achieve with this technology a= s a WG. So let's spend some time on use cases and building a good case to c= onvince an AD. We could start by listing what TSCH is "good at", and what makes it differe= nt from other solutions. I see the following: - reliability: 5 9's of end-to-end reliability are commonplace. - low-power: aggressive radio duty cycling of the mote's radio yields much = longer lifetime in battery-powered devices. - traffic engineering: the clear identification of resources allows for flo= w independence and QoS. Of course, from those points, industrial applications immediately come to m= ind. Yet, we could take use cases from other areas. We could for example ta= ke the ROLL requirement drafts as a skeleton (I'm paraphrasing some of the = points Xavi and Alfredo made). - industrial automation. A 6TSCH network can allow for high reliability, an= d deterministic behavior. Link over-provisioning can efficiently combat the= unreliable nature of wireless and provide a robust communication. - building automation. A 6TSCH network can serve as an "umbrella" network f= or a large number of sensing points in the building. These sensing points c= an be owned and operated by different entities (e.g. HVAC and lighting). Th= e 6TSCH network allows for the different traffic flows to stay independent = from one another. - because of a 6TSCH node is deeply duty cycle, remote sensing application = (e.g. agricultural applications) can rely on energy harvesting as power sou= rce. - A smart urban parking application can benefit from the reliabilty of 6TS= CH network since, even though the vehicle detection sensor may be static, t= he constant movement of cars around the sensing points can cause the wirele= ss environment to quickly change. Thomas On Tue, Mar 19, 2013 at 12:08 PM, Pascal Thubert (pthubert) > wrote: Dear ML: The activity that we generate on the mailing list is a good indication we w= ill be very successful as a WG. First thing first, though, we need to creat= e the WG and need to focus a little bit on the necessary steps to get there. We need to put together a rough charter, and convince an AD, probably Adria= n from Routing Area or Ted from Internet Area, that we have real problems t= o solve and that we, as a group, can provide valuable answers. The ADs agen= das are very full all the time, but certainly peaks around the meeting time= s. So we have about 2 week in front of us to prepare a solid case. So I suggest we step back a minute from the details of time frames and prio= rities and spend some energy on the use cases, the problems we are solving,= and the work we have to do to get there. I notice a cool discussion on mob= ility and the particular case of a crane, well that's a use case. We alread= y had centralized deterministic (hard slot) routes for command and control,= distributed deterministic (soft slots) and non deterministic QoS based flo= ws. Do we have others cases? Cheers, Pascal _______________________________________________ 6tsch mailing list 6tsch@ietf.org https://www.ietf.org/mailman/listinfo/6tsch ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. --_000_8F1D83ADCC1AC94186A867BEE9B7D91306D39889PEXCVZYM13corpo_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Thomas,

 <= /p>

This is ex= actly what I had in mind, thanks!

 = ;

Dominique<= o:p>

 = ;

 = ;

De : 6tsc= h-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] De la part de Thomas Watteyne
Envoy=E9 : lundi 25 mars 2013 17:33
=C0 : 6tsch@ietf.org
Objet : Re: [6tsch] focussing on charter: use cases<= /span>

 

Dominique,

 

Thanks for your comments. We certainly do not want t= o be overly simplistic. When identifying use cases, I believe we should foc= us on what makes TSCH different, and articulate the use cases around those.= As you point out, traffic differentiation is certainly very high on that list.

 

An immediate use case is that of an entity operating= an "umbrella" network on which different types of traffic flow, = possibly coming from customers of this entity. When a new customer asks to = be granted access to the network, the network operator can predict with pretty good granularity the the impact this new = traffic on the remaining bandwidth of the network, and on the power consump= tion of individual motes, which allows the operator to grant/deny, and prob= ably charge differently.

 

Does this use case match what you were thinking?

 

Thomas

 

On Sat, Mar 23, 2013 at 8:13 AM, <dominique.barthel@orange= .com> wrote:

Hello Thomas, all,

 

Regarding your point<= /p>

- because of a 6TSCH node is deeply duty cycl= e, remote sensing application (e.g. agricultural applications) can rely on = energy harvesting as power source.

I still need to be convi= nced that 6tsch allows for a lower power consumption than preamble sampling on very low traffic. Therefore I don’t think we should say<= /span>

“6tsch is lower po= wer therefore makes possible new applications therefore we should standardize 6tsch”. This is overly simplistic.

Other arguments that wer= e stated, such as determinism, which is mandated by industry automation, is a much better seller.

 =

To add another one, as I= stated in an earlier phone conference, I believe TSCH is of interest to build mutualized sensor networks that can support several end = customers or services. This is because one can allocate bandwidth to each s= upported service independently of the others (under some limits). This can = be modeled beforehand, a decision can be made to admit the new customer/service or not, and the network can = be managed to allocate temporary extra resources to maintain QoS while a te= chnician is sent to the field to investigate such things as node failure or= severe interference. Granted, several node resources such as energy and memory are still shared between customer= s/services but TSCH allows to model and manage these much better than other= wireless link layers.

Such a mutualized manage= d network is much more likely to be profitable and makes a better use of spectrum than independent, overlaid networks fighting for the same = wireless medium.

To a company intending t= o deploy, operate and manage a sensor network infrastructure, TSCH is good starting point.

 =

Comments?

 =

Dominique

 =

De : 6tsch-bounces@i= etf.org [mailto:6tsch-bounces@ietf.org] De la part de Thomas Watteyne
Envoy=E9 : jeudi 21 mars 2013 06:16
=C0 : 6tsch= @ietf.org
Objet : Re: [6tsch] focussing on charter: use cases
=

 

Pascal, all,

 

Absolutely agreed. I believe we have started exploring quite a bit= , enough to have a clear understanding of what we can achieve with this tec= hnology as a WG. So let's spend some time on use cases and building a good case to convince an AD.

 

We could start by listing what TSCH is "good at", and wh= at makes it different from other solutions. I see the following:=

- reliability: 5 9's of end-to-end reliability are commonplace.

- low-power: aggressive radio duty cycling of the mote's= radio yields much longer lifetime in battery-powered devices.

- traffic engineering: the clear identification of resources allow= s for flow independence and QoS.

 

Of course, from those points, industrial applications immediately = come to mind. Yet, we could take use cases from other areas. We could for e= xample take the ROLL requirement drafts as a skeleton (I'm paraphrasing some of the points Xavi and Alfredo made).=

 

- industrial automation. A 6TSCH network = can allow for high reliability, and deterministic behavior. Link over-provisioning can efficiently combat the unreliable nature of wir= eless and provide a robust communication. 

- building automation. A 6TSCH network can serve as an "umbre= lla" network for a large number of sensing points in the building. The= se sensing points can be owned and operated by different entities (e.g. HVAC and lighting). The 6TSCH network allows for = the different traffic flows to stay independent from one another.

- because of a 6TSCH node is deeply duty cycle, remote sensing app= lication (e.g. agricultural applications) can rely on energy harvesting as = power source.

- A smart urban parking application can benefit from the reliabilt= y of  6TSCH network since, even though the vehicle detection sensor ma= y be static, the constant movement of cars around the sensing points can cause the wireless environment to quickly ch= ange.

 

Thomas

 

On Tue, Mar 19, 2013 at 12:08 PM, Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:

Dear ML:

 

The activity that we generate on the mailing = list is a good indication we will be very successful as a WG. First thing f= irst, though, we need to create the WG and need to focus a little bit on the necessary steps to get there.=

 

We need to put together a rough charter, and = convince an AD, probably Adrian from Routing Area or Ted from Internet Area= , that we have real problems to solve and that we, as a group, can provide valuable answers. The ADs agendas are= very full all the time, but certainly peaks around the meeting times. So w= e have about 2 week in front of us to prepare a solid case.

 

So I suggest we step back a minute from the d= etails of time frames and priorities and spend some energy on the use cases= , the problems we are solving, and the work we have to do to get there. I notice a cool discussion on mobility an= d the particular case of a crane, well that’s a use case. We already = had centralized deterministic (hard slot) routes for command and control, d= istributed deterministic (soft slots) and non deterministic QoS based flows. Do we have others cases?

Cheers,

 

Pascal

 

 


_______________________________________________
6tsch mailing list
6tsch@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/6tsch

 

______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez=
 recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messag=
es electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a e=
te altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for me=
ssages that have been modified, changed or falsified.
Thank you.

 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.
Thank you.
--_000_8F1D83ADCC1AC94186A867BEE9B7D91306D39889PEXCVZYM13corpo_-- Return-Path: 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 78DEB21F8930 for <6tsch@ietfa.amsl.com>; Mon, 25 Mar 2013 09:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[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 0lfB5uEZlJvJ for <6tsch@ietfa.amsl.com>; Mon, 25 Mar 2013 09:33:10 -0700 (PDT) Received: from mail-pb0-f52.google.com (mail-pb0-f52.google.com [209.85.160.52]) by ietfa.amsl.com (Postfix) with ESMTP id 583CA21F88FC for <6tsch@ietf.org>; Mon, 25 Mar 2013 09:33:10 -0700 (PDT) Received: by mail-pb0-f52.google.com with SMTP id ma3so4271606pbc.39 for <6tsch@ietf.org>; Mon, 25 Mar 2013 09:32:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=Wcd5821bUNxqk4TejUImK6dNQRVCDFqTnB/INaVQLmg=; b=ZojGu6ngaLOSw4k+d+hgb+9GzX0VSsFRxzwKr/XTRSTwZmdlyXLJhgk00YtNeh3rNY CaoYT1Vc5Ik6gcMBTaUo/qJ5+K1Fxqq2tOvHaEp0o5mWparwr1/GK8YgJzppNucjDnMV 0d4Lp0JYDl6gIHcH7sX7XoapUffI3lYu0eP+oDyuZaEJWh/Blkae74+myrzS1DK97/Ti UqbIoUpEOns/iV5xJ70Xnii/btR14LFU8dDdJ66/1AXmHUz7CuBtK0zMmi+wJf1J2TB3 BTW6rn9BjKYoWmrNYhvzkSvyvmyT/4SWlNSEQIYx32cs1oxpz2Nd21V01u6knOYK5L3+ ZYsg== X-Received: by 10.66.122.167 with SMTP id lt7mr9096952pab.168.1364229176639; Mon, 25 Mar 2013 09:32:56 -0700 (PDT) MIME-Version: 1.0 Sender: twatteyne@gmail.com Received: by 10.68.123.71 with HTTP; Mon, 25 Mar 2013 09:32:36 -0700 (PDT) In-Reply-To: <6194_1364051635_514DC6B3_6194_19669_1_8F1D83ADCC1AC94186A867BEE9B7D91306D39033@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <6194_1364051635_514DC6B3_6194_19669_1_8F1D83ADCC1AC94186A867BEE9B7D91306D39033@PEXCVZYM13.corporate.adroot.infra.ftgroup> From: Thomas Watteyne Date: Mon, 25 Mar 2013 09:32:36 -0700 X-Google-Sender-Auth: gtIPLseA8hcjjgXuaK6viyK1Bb4 Message-ID: To: "6tsch@ietf.org" <6tsch@ietf.org> Content-Type: multipart/alternative; boundary=047d7bf0e6f8774df704d8c25b8c Subject: Re: [6tsch] focussing on charter: use cases 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 16:33:12 -0000 --047d7bf0e6f8774df704d8c25b8c Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Dominique, Thanks for your comments. We certainly do not want to be overly simplistic. When identifying use cases, I believe we should focus on what makes TSCH different, and articulate the use cases around those. As you point out, traffic differentiation is certainly very high on that list. An immediate use case is that of an entity operating an "umbrella" network on which different types of traffic flow, possibly coming from customers of this entity. When a new customer asks to be granted access to the network, the network operator can predict with pretty good granularity the the impact this new traffic on the remaining bandwidth of the network, and on the power consumption of individual motes, which allows the operator to grant/deny, and probably charge differently. Does this use case match what you were thinking? Thomas On Sat, Mar 23, 2013 at 8:13 AM, wrote: > Hello Thomas, all,**** > > ** ** > > Regarding your point**** > > - because of a 6TSCH node is deeply duty cycle, remote sensing applicatio= n > (e.g. agricultural applications) can rely on energy harvesting as power > source.**** > > I still need to be convinced that 6tsch allows for a lower power > consumption than preamble sampling on very low traffic. Therefore I don= =92t > think we should say**** > > =936tsch is lower power therefore makes possible new applications therefo= re > we should standardize 6tsch=94. This is overly simplistic.**** > > Other arguments that were stated, such as determinism, which is mandated > by industry automation, is a much better seller.**** > > ** ** > > To add another one, as I stated in an earlier phone conference, I believe > TSCH is of interest to build mutualized sensor networks that can support > several end customers or services. This is because one can allocate > bandwidth to each supported service independently of the others (under so= me > limits). This can be modeled beforehand, a decision can be made to admit > the new customer/service or not, and the network can be managed to alloca= te > temporary extra resources to maintain QoS while a technician is sent to t= he > field to investigate such things as node failure or severe interference. > Granted, several node resources such as energy and memory are still share= d > between customers/services but TSCH allows to model and manage these much > better than other wireless link layers.**** > > Such a mutualized managed network is much more likely to be profitable an= d > makes a better use of spectrum than independent, overlaid networks fighti= ng > for the same wireless medium.**** > > To a company intending to deploy, operate and manage a sensor network > infrastructure, TSCH is good starting point.**** > > ** ** > > Comments?**** > > ** ** > > Dominique**** > > ** ** > > *De :* 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] *De la part > de* Thomas Watteyne > *Envoy=E9 :* jeudi 21 mars 2013 06:16 > *=C0 :* 6tsch@ietf.org > *Objet :* Re: [6tsch] focussing on charter: use cases**** > > ** ** > > Pascal, all,**** > > ** ** > > Absolutely agreed. I believe we have started exploring quite a bit, enoug= h > to have a clear understanding of what we can achieve with this technology > as a WG. So let's spend some time on use cases and building a good case t= o > convince an AD.**** > > ** ** > > We could start by listing what TSCH is "good at", and what makes it > different from other solutions. I see the following:**** > > - reliability: 5 9's of end-to-end reliability are commonplace.**** > > - low-power: aggressive radio duty cycling of the mote's radio yields muc= h > longer lifetime in battery-powered devices.**** > > - traffic engineering: the clear identification of resources allows for > flow independence and QoS.**** > > ** ** > > Of course, from those points, industrial applications immediately come to > mind. Yet, we could take use cases from other areas. We could for example > take the ROLL requirement drafts as a skeleton (I'm paraphrasing some of > the points Xavi and Alfredo made). **** > > ** ** > > - industrial automation. A 6TSCH network can allow for high reliability, > and deterministic behavior. Link over-provisioning can efficiently combat > the unreliable nature of wireless and provide a robust communication. ***= * > > - building automation. A 6TSCH network can serve as an "umbrella" network > for a large number of sensing points in the building. These sensing point= s > can be owned and operated by different entities (e.g. HVAC and lighting). > The 6TSCH network allows for the different traffic flows to stay > independent from one another.**** > > - because of a 6TSCH node is deeply duty cycle, remote sensing applicatio= n > (e.g. agricultural applications) can rely on energy harvesting as power > source.**** > > - A smart urban parking application can benefit from the reliabilty of > 6TSCH network since, even though the vehicle detection sensor may be > static, the constant movement of cars around the sensing points can cause > the wireless environment to quickly change.**** > > ** ** > > Thomas**** > > ** ** > > On Tue, Mar 19, 2013 at 12:08 PM, Pascal Thubert (pthubert) < > pthubert@cisco.com> wrote:**** > > Dear ML:**** > > **** > > The activity that we generate on the mailing list is a good indication we > will be very successful as a WG. First thing first, though, we need to > create the WG and need to focus a little bit on the necessary steps to ge= t > there.**** > > **** > > We need to put together a rough charter, and convince an AD, probably > Adrian from Routing Area or Ted from Internet Area, that we have real > problems to solve and that we, as a group, can provide valuable answers. > The ADs agendas are very full all the time, but certainly peaks around th= e > meeting times. So we have about 2 week in front of us to prepare a solid > case.**** > > **** > > So I suggest we step back a minute from the details of time frames and > priorities and spend some energy on the use cases, the problems we are > solving, and the work we have to do to get there. I notice a cool > discussion on mobility and the particular case of a crane, well that=92s = a > use case. We already had centralized deterministic (hard slot) routes for > command and control, distributed deterministic (soft slots) and non > deterministic QoS based flows. Do we have others cases?**** > > Cheers,**** > > **** > > Pascal**** > > **** > > **** > > > _______________________________________________ > 6tsch mailing list > 6tsch@ietf.org > https://www.ietf.org/mailman/listinfo/6tsch**** > > ** ** > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > France Telecom - Orange decline toute responsabilite si ce message a ete = altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for messa= ges that have been modified, changed or falsified. > Thank you. > > --047d7bf0e6f8774df704d8c25b8c Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Dominique,

Thanks for your comments. We certainly do not= want to be overly simplistic. When identifying use cases, I believe we sho= uld focus on what makes TSCH different, and articulate the use cases around= those. As you point out, traffic differentiation is certainly very high on= that list.

An immediate use case is that of an entity operating an= "umbrella" network on which different types of traffic flow, pos= sibly coming from customers of this entity. When a new customer asks to be = granted access to the network, the network operator can predict with pretty= good granularity the the impact this new traffic on the remaining bandwidt= h of the network, and on the power consumption of individual motes, which a= llows the operator to grant/deny, and probably charge differently.

Does this use case match what you were thinking?
<= div>
Thomas

On Sat, = Mar 23, 2013 at 8:13 AM, <dominique.barthel@orange.com>= wrote:

Hello Thomas, all,=

=A0<= /p>

Regarding your point

- because of a 6TSCH node is de= eply duty cycle, remote sensing application (e.g. agricultural applications= ) can rely on energy harvesting as power source.

I st= ill need to be convinced that 6tsch allows for a lower power consumption th= an preamble sampling on very low traffic. Therefore I don=92t think we should say

=936tsch i= s lower power therefore makes possible new applications therefore we should= standardize 6tsch=94. This is overly simplistic.

Other argu= ments that were stated, such as determinism, which is mandated by industry = automation, is a much better seller.

=A0=

To add ano= ther one, as I stated in an earlier phone conference, I believe TSCH is of = interest to build mutualized sensor networks that can support several end customers or services. This is because one can allocate bandwi= dth to each supported service independently of the others (under some limit= s). This can be modeled beforehand, a decision can be made to admit the new= customer/service or not, and the network can be managed to allocate temporary extra resources to maintain Q= oS while a technician is sent to the field to investigate such things as no= de failure or severe interference. Granted, several node resources such as = energy and memory are still shared between customers/services but TSCH allows to model and manage these much = better than other wireless link layers.

Such a mut= ualized managed network is much more likely to be profitable and makes a be= tter use of spectrum than independent, overlaid networks fighting for the same wireless medium.

To a compa= ny intending to deploy, operate and manage a sensor network infrastructure,= TSCH is good starting point.

=A0=

Comments?<= u>

=A0=

Dominique<= u>

=A0=

De=A0: 6tsch-bounces@ietf.org= [mailto:6t= sch-bounces@ietf.org] De la part de Thomas Watteyne
Envoy=E9=A0: jeudi 21 mars 2013 06:16
=C0=A0: 6tsch@ie= tf.org
Objet=A0: Re: [6tsch] focussing on charter: use cases<= /span>

=A0

Pascal, all,

=A0

Absolutely agreed. I believe we have started explori= ng quite a bit, enough to have a clear understanding of what we can achieve= with this technology as a WG. So let's spend some time on use cases an= d building a good case to convince an AD.

=A0

We could start by listing what TSCH is "good at= ", and what makes it different from other solutions. I see the followi= ng:

- reliability: 5 9's of end-to-end reliability a= re commonplace.

- low-power:=A0aggressive=A0radio duty cycling of th= e mote's radio yields much longer lifetime in battery-powered devices.<= u>

- traffic engineering: the clear identification of r= esources allows for flow independence and QoS.

=A0

Of course, from those points, industrial application= s immediately come to mind. Yet, we could take use cases from other areas. = We could for example take the ROLL requirement drafts as a skeleton (I'= m paraphrasing some of the points Xavi and Alfredo made).

=A0

- industrial automation. A = 6TSCH network can allow for high reliability, and=A0deterministic=A0behavio= r. Link over-provisioning can efficiently combat the unreliable nature of wireless and provide a robust communication.=A0=

- building automation. A 6TSCH network can serve as = an "umbrella" network for a large number of sensing points in the= building. These sensing points can be owned and operated by different enti= ties (e.g. HVAC and lighting). The 6TSCH network allows for the different traffic flows to stay independent from one anothe= r.

- because of a 6TSCH node is deeply duty cycle, remo= te sensing application (e.g. agricultural applications) can rely on energy = harvesting as power source.

- A smart urban parking application can benefit from= the reliabilty of =A06TSCH network since, even though the vehicle detectio= n sensor may be static, the constant movement of cars around the sensing po= ints can cause the wireless environment to quickly change.

=A0

Thomas

=A0

On Tue, Mar 19, 2013 at 12:08 PM, Pascal Thubert (pt= hubert) <pthuber= t@cisco.com> wrote:

Dear ML:

=A0

The activity that we generate o= n the mailing list is a good indication we will be very successful as a WG.= First thing first, though, we need to create the WG and need to focus a little bit on the necessary steps to get there.=

=A0

We need to put together a rough= charter, and convince an AD, probably Adrian from Routing Area or Ted from= Internet Area, that we have real problems to solve and that we, as a group, can provide valuable answers. The ADs agendas are= very full all the time, but certainly peaks around the meeting times. So w= e have about 2 week in front of us to prepare a solid case.

=A0

So I suggest we step back a min= ute from the details of time frames and priorities and spend some energy on= the use cases, the problems we are solving, and the work we have to do to get there. I notice a cool discussion on mobility an= d the particular case of a crane, well that=92s a use case. We already had = centralized deterministic (hard slot) routes for command and control, distr= ibuted deterministic (soft slots) and non deterministic QoS based flows. Do we have others cases?<= /u>

Cheers,

=A0<= /u>

Pascal<= u>

=A0<= /u>

=A0<= /u>


_______________________________________________
6tsch mailing list
6tsch@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/6tsch

=A0

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les message=
s electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.
Thank you.

--047d7bf0e6f8774df704d8c25b8c-- Return-Path: 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 BCC2021F84B5 for <6tsch@ietfa.amsl.com>; Sat, 23 Mar 2013 08:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 X82ehVuAeDIJ for <6tsch@ietfa.amsl.com>; Sat, 23 Mar 2013 08:32:18 -0700 (PDT) Received: from cm01fe.IST.Berkeley.EDU (cm01fe.IST.Berkeley.EDU [169.229.218.142]) by ietfa.amsl.com (Postfix) with ESMTP id 4859421F8B13 for <6tsch@ietf.org>; Sat, 23 Mar 2013 08:32:18 -0700 (PDT) Received: from c-67-188-198-243.hsd1.ca.comcast.net ([67.188.198.243] helo=[192.168.2.7]) by cm01fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:xvilajosana@eecs.berkeley.edu) (envelope-from ) id 1UJQQW-0003Tt-5z for 6tsch@ietf.org; Sat, 23 Mar 2013 08:32:17 -0700 Message-ID: <514DCAF8.7050003@eecs.berkeley.edu> Date: Sat, 23 Mar 2013 08:32:08 -0700 From: Xavier Vilajosana User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: 6tsch@ietf.org References: <1570_1364051324_514DC57C_1570_16957_1_8F1D83ADCC1AC94186A867BEE9B7D91306D38EDA@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <1570_1364051324_514DC57C_1570_16957_1_8F1D83ADCC1AC94186A867BEE9B7D91306D38EDA@PEXCVZYM13.corporate.adroot.infra.ftgroup> Content-Type: multipart/alternative; boundary="------------090202020002080509010801" Subject: Re: [6tsch] Agenda for the call March 22nd, 2013 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 15:32:24 -0000 This is a multi-part message in MIME format. --------------090202020002080509010801 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit see inline On 23/03/13 08:08, dominique.barthel@orange.com wrote: > > Hello Pascal, Wavi, Thomas, all, > > Sorry I won't be able to attend the call, on the road again. > > Some comments, though: > > *(road,street) traffic control (requires increase of bw as more > traffic in the road) > > Why does traffic control require more bandwidth as traffic increases? > Aren't we reporting data such as number of cars as opposed to each > passing car one by one? > traffic control not only counts cars, the most advanced systems classify cars according to the number of axes and even type of car. Note that some operators are paid according to the type of car (truck, motorbike,car). This requires in some systems to send more information which is send at each reading. There are several companies that do that and use TSCH networks. > > *smart urban parking (requires redundancy of routes an > over-provision as RF degrades with cars on top of the sensors) > > How is this a highlight of TSCH? > Well, the first thing is that one of the companies with more smart parkings installed uses TSCH networks. 6tsch can over-provision bandwidth on different tracks, the tracks are not defined by 6tus but 6tus deals with provisioning more bandwidth if the QoS is not meet. I guess also that 6tus may detect that if over-provisioning on a track up to a certain limit (eg required is 6cells, 6tus overprovisions 60cells because there is a high packet drop and 6 is not met although 60cells are given), the RPL should be told about that no? > > * green zones. Monitor moisture in gardens, trigger watering. > > * city lights monitoring. Requires marge scale meshes > I haven't proposed them but I can figure out that this scenarios might benefit from TSCH if the density of the deployments is high enough and the sampling rate requirement is significant. > > Again, this doesn't say why TSCH is required or better than anything > else, hence is not a selling point. > > Xavi, I think you were the one to put these scenarios forward, in > another email thead. Can you please comment? > > Thanks > > Dominique > > *De :*6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] *De la > part de* Pascal Thubert (pthubert) > *Envoy :* jeudi 21 mars 2013 17:56 > * :* Thomas Watteyne; 6tsch@ietf.org > *Objet :* [6tsch] Agenda for the call March 22nd, 2013 > > Dear all: > > The focus for tomorrow will be to agree on use cases and derive a > problem statement. Please keep in mind that the call will be recorded > and the record published. > > We already have a list that we can review: > > - Wireless Process Control (main source for us) > > * control loops (requires a global optimization of routes for > jitter an latency -- thus computed by a PCE -, flow (over) > provisioning, duocast, with static multipath hard slot allocation. > > * control loop plan B (requires self-healing -thus distributed- > routing,) > > * supervisory flows (requires determinism up to the backbone > > * management (requires a separate topology -- a RPL instance - that > does not break) > > * alerts (bursty, unexpected, dynamic slot allocation, prioritization) > > * monitoring of lots of lesser importance stuff like corrosion > (requires low cost scalability -- this distributed routing ) > > * cranes that are mobile within a range (requires dynamicity on the > last hop(s) whre the mobility happens and may be deterministic up to > that point) > > * large plants (requires thousands of devices-- thus a backbone -- > within a subnet -- to avoid renumbering) > > * non-production episodes (requires fast and autonomic behavior -- > again distributed routing) > > * coexistence with legacy devices (requires a common management above) > > -Smart cities/infrastructures > *(road,street) traffic control (requires increase of bw as more > traffic in the road) > *smart urban parking (requires redundancy of routes an > over-provision as RF degrades with cars on top of the sensors) > > * green zones. Monitor moisture in gardens, trigger watering. > > * city lights monitoring. Requires marge scale meshes > > - building automation. > > * requires redundancy as RF degrades when there are changes on the > environment, doors, moving metallic apparel, etc..) > > * can be long distance this many hops. Can use lower frequencies to > gain range. > > - vehicular automation. > > * We can save copper for most of the man to machine interfaces, > which translates in both lower price and lower gas consumption. > > - commercial automation. > > * asset tracking operations on the move (again mobility, and dynamics). > > * monitoring e.g. temperature of freezers, intrusion sensors, ... > > Please bring your own thoughts so we can converge at the call : ) > > As an appetizer, we can start with > > * summary overview Orlando meeting (10 minutes) > > o agendas two meetings > o 4 drafts presented > o TODO: 6tus, add ability for a PCE to set hard cells on one > side only (text already changed) > o TODO: typos > o TODO: terminology > > Then the entre (40 minutes) > > * charter use cases: > > o review the list above > o validate the list of derived problems to be solved > o focus on what TSCH is good at: reliability, low-power > consumption, traffic engineering > > for dessert > > * open technical discussions > > o synchronization between BBRs > > + summarize and discuss proposal > > o slotframes, cells and priorities > > + summarize and discuss proposal > > o interaction between RPL and PCE > > + summarize current state of the discussion > > ** > > Please let us know if you wish to add / amend stuff in the above : ) > > Cheers, > > Pascal > > PS, call info is as always: > > > Topic: 6TSCH Weekly > Date: Every Friday, from Friday, March 8, 2013 to Friday, March 7, 2014 > Time: 8:00 am, Pacific Standard Time (San Francisco, GMT-08:00) > Meeting Number: 206 802 913 > Meeting Password: sixtus > > > ------------------------------------------------------- > To join the online meeting (Now from mobile devices!) > ------------------------------------------------------- > 1. Go to > https://cisco.webex.com/ciscosales/j.php?ED=219615007&UID=0&PW=NZTRkNDAwOTE1&RT=MiM0 > 2. Enter your name and email address. > 3. Enter the meeting password: sixtus > 4. Click "Join Now". > > To view in other time zones or languages, please click the link: > https://cisco.webex.com/ciscosales/j.php?ED=219615007&UID=0&PW=NZTRkNDAwOTE1&ORT=MiM0 > > > ---------------------------------------------------------------- > ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes > ---------------------------------------------------------------- > > The affected toll free numbers are: (866) 432-9903 for the San > Jose/Milpitas area and (866) 349-3520 for the RTP area. > > Please dial the local access number for your area from the list below: > - San Jose/Milpitas (408) area: 525-6800 > - RTP (919) area: 392-3330 > > ------------------------------------------------------- > To join the teleconference only > ------------------------------------------------------- > 1. Dial into Cisco WebEx (view all Global Access Numbers at > http://cisco.com/en/US/about/doing_business/conferencing/index.html > 2. Follow the prompts to enter the Meeting Number (listed above) or > Access Code followed by the # sign. > > San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330 > > US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 > > India: +91.80.4350.1111 Germany: +49.619.6773.9002 > > Japan: +81.3.5763.9394 China: +86.10.8515.5666 > > ------------------------------------------------------- > For assistance > ------------------------------------------------------- > 1. Go to https://cisco.webex.com/ciscosales/mc > 2. On the left navigation bar, click "Support". > > You can contact me at: > pthubert@cisco.com > 33-49-723 2634 > > To add this meeting to your calendar program (for example Microsoft > Outlook), click this link: > https://cisco.webex.com/ciscosales/j.php?ED=219615007&UID=0&ICS=MI&LD=1&RD=2&ST=1&SHA2=AAAAAmvICIpFyZ4imE5seTb7ijZUoMuEgw1h2pXGIGSMyQEb&RT=MiM0 > > > > > > > > http://www.webex.com > > CCP:+14085256800x206802913# > > IMPORTANT NOTICE: This WebEx service includes a feature that allows > audio and any documents and other materials exchanged or viewed during > the session to be recorded. By joining this session, you automatically > consent to such recordings. If you do not consent to the recording, > discuss your concerns with the meeting host prior to the start of the > recording or do not join the session. Please note that any such > recordings may be subject to discovery in the event of litigation. > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > > > _______________________________________________ > 6tsch mailing list > 6tsch@ietf.org > https://www.ietf.org/mailman/listinfo/6tsch --------------090202020002080509010801 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
see inline

On 23/03/13 08:08, dominique.barthel@orange.com wrote:

Hello Pascal, Wavi, Thomas, all,

 

Sorry I won’t be able to attend the call, on the road again.

Some comments, though:

  *(road,street) traffic control (requires increase of bw as more traffic in the road)

Why does traffic control require more bandwidth as traffic increases? Aren’t we reporting data such as number of cars as opposed to each passing car one by one?

traffic control not only counts cars, the most advanced systems classify cars according to the number of axes and even type of car. Note that some operators are paid according to the type of car (truck, motorbike,car). This requires in some systems to send more information which is send at each reading. There are several companies that do that and use TSCH networks.

    *smart urban parking (requires redundancy of routes an over-provision as RF degrades with cars on top of the sensors)   

How is this a highlight of TSCH?

Well, the first thing is that one of the companies with more smart parkings installed uses TSCH networks. 6tsch can over-provision bandwidth on different tracks, the tracks are not defined by 6tus but 6tus deals with provisioning more bandwidth if the QoS is not meet. I guess also that 6tus may detect that if over-provisioning on a track up to a certain limit (eg required is 6cells, 6tus overprovisions 60cells because there is a high packet drop and 6 is not met although 60cells are given), the RPL should be told about that no?

    * green zones. Monitor moisture in gardens, trigger watering.

   * city lights monitoring. Requires marge scale meshes


I haven't proposed them but I can figure out that this scenarios might benefit from TSCH if the density of the deployments is high enough and the sampling rate requirement is significant.

Again, this doesn’t say why TSCH is required or better than anything else, hence is not a selling point.

Xavi, I think you were the one to put these scenarios forward, in another email thead. Can you please comment?

Thanks

 

Dominique

 

De : 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] De la part de Pascal Thubert (pthubert)
Envoyé : jeudi 21 mars 2013 17:56
À : Thomas Watteyne; 6tsch@ietf.org
Objet : [6tsch] Agenda for the call March 22nd, 2013

 

Dear all:

 

The focus for tomorrow will be to agree on use cases and derive a problem statement. Please keep in mind that the call will be recorded and the record published.

 

We already have a list that we can review:

 

- Wireless Process Control (main source for us)

   * control loops (requires a global optimization of routes for jitter an latency – thus computed by a PCE  -, flow (over) provisioning, duocast, with static multipath hard slot allocation.

   * control loop plan B (requires self-healing -thus distributed- routing,)

   * supervisory flows (requires determinism up to the backbone

   * management (requires a separate topology – a RPL instance - that does not break)

   * alerts (bursty, unexpected, dynamic slot allocation, prioritization)

   * monitoring of lots of lesser importance stuff like corrosion (requires low cost scalability – this distributed routing )

   * cranes that are mobile within a range (requires dynamicity on the last hop(s) whre the mobility happens and may be deterministic up to that point)

   * large plants (requires thousands of devices– thus a backbone – within a subnet – to avoid renumbering)

   * non-production episodes (requires fast and autonomic behavior – again distributed routing)

   * coexistence with legacy devices (requires a common management above)

 

-Smart cities/infrastructures
    *(road,street) traffic control (requires increase of bw as more traffic in the road)
    *smart urban parking (requires redundancy of routes an over-provision as RF degrades with cars on top of the sensors)   

    * green zones. Monitor moisture in gardens, trigger watering.

   * city lights monitoring. Requires marge scale meshes

 

- building automation.

  * requires redundancy as RF degrades when there are changes on the environment, doors, moving metallic apparel, etc..)

  * can be long distance this many hops. Can use lower frequencies to gain range.

 

- vehicular automation.

   * We can save copper for most of the man to machine interfaces, which translates in both lower price and lower gas consumption.

 

- commercial automation.

  *  asset tracking operations on the move (again mobility, and dynamics).

  *  monitoring e.g. temperature of freezers, intrusion sensors, …

 

 

Please bring your own thoughts so we can converge at the call : )

 

As an appetizer, we can start with

 

  • summary overview Orlando meeting (10 minutes)
    • agendas two meetings
    • 4 drafts presented
    • TODO: 6tus, add ability for a PCE to set hard cells on one side only (text already changed)
    • TODO: typos
    • TODO: terminology

 

Then the entrée (40 minutes)

 

  • charter use cases:
    • review the list above
    • validate the list of derived problems to be solved
    • focus on what TSCH is good at: reliability, low-power consumption, traffic engineering

 

for dessert

  • open technical discussions
    • synchronization between BBRs
      • summarize and discuss proposal
    • slotframes, cells and priorities
      • summarize and discuss proposal
    • interaction between RPL and PCE
      • summarize current state of the discussion

 

 

Please let us know if you wish to add / amend stuff in the above : )

 

Cheers,

 

Pascal

 

PS, call info is as always:


Topic: 6TSCH Weekly
Date: Every Friday, from Friday, March 8, 2013 to Friday, March 7, 2014
Time: 8:00 am, Pacific Standard Time (San Francisco, GMT-08:00)
Meeting Number: 206 802 913
Meeting Password: sixtus


-------------------------------------------------------
To join the online meeting (Now from mobile devices!)
-------------------------------------------------------
1. Go to
https://cisco.webex.com/ciscosales/j.php?ED=219615007&UID=0&PW=NZTRkNDAwOTE1&RT=MiM0
2.
Enter your name and email address.
3. Enter the meeting password: sixtus
4. Click "Join Now".

To view in other time zones or languages, please click the link:
https://cisco.webex.com/ciscosales/j.php?ED=219615007&UID=0&PW=NZTRkNDAwOTE1&ORT=MiM0

----------------------------------------------------------------
ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes
----------------------------------------------------------------

The affected toll free numbers are: (866) 432-9903 for the San Jose/Milpitas area and (866) 349-3520 for the RTP area.

Please dial the local access number for your area from the list below:
- San Jose/Milpitas (408) area: 525-6800
- RTP (919) area: 392-3330

-------------------------------------------------------
To join the teleconference only
-------------------------------------------------------
1. Dial into Cisco WebEx (view all Global Access Numbers at
http://cisco.com/en/US/about/doing_business/conferencing/index.html
2. Follow the prompts to enter the Meeting Number (listed above) or Access Code followed by the # sign.

San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330

US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117

India: +91.80.4350.1111 Germany: +49.619.6773.9002

Japan: +81.3.5763.9394 China: +86.10.8515.5666

-------------------------------------------------------
For assistance
-------------------------------------------------------
1. Go to https://cisco.webex.com/ciscosales/mc
2. On the left navigation bar, click "Support".

You can contact me at:
pthubert@cisco.com
33-49-723 2634

To add this meeting to your calendar program (for example Microsoft Outlook), click this link:
https://cisco.webex.com/ciscosales/j.php?ED=219615007&UID=0&ICS=MI&LD=1&RD=2&ST=1&SHA2=AAAAAmvICIpFyZ4imE5seTb7ijZUoMuEgw1h2pXGIGSMyQEb&RT=MiM0






http://www.webex.com

CCP:+14085256800x206802913#

IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation.

 

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.


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

--------------090202020002080509010801-- Return-Path: 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 2BD9421F8960 for <6tsch@ietfa.amsl.com>; Sat, 23 Mar 2013 08:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] 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 5jrKdB9z45yF for <6tsch@ietfa.amsl.com>; Sat, 23 Mar 2013 08:13:57 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 8432321F8951 for <6tsch@ietf.org>; Sat, 23 Mar 2013 08:13:56 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 7224618C399; Sat, 23 Mar 2013 16:13:55 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 547DD4C017; Sat, 23 Mar 2013 16:13:55 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Sat, 23 Mar 2013 16:13:55 +0100 From: To: Thomas Watteyne , "6tsch@ietf.org" <6tsch@ietf.org> Thread-Topic: [6tsch] focussing on charter: use cases Thread-Index: Ac4k1OmP4544fW5MRUSgOucw3DT4aQBFd8gAADhOmBA= Date: Sat, 23 Mar 2013 15:13:54 +0000 Message-ID: <6194_1364051635_514DC6B3_6194_19669_1_8F1D83ADCC1AC94186A867BEE9B7D91306D39033@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.3] Content-Type: multipart/alternative; boundary="_000_8F1D83ADCC1AC94186A867BEE9B7D91306D39033PEXCVZYM13corpo_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.3.23.140316 Subject: Re: [6tsch] focussing on charter: use cases 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 15:14:01 -0000 --_000_8F1D83ADCC1AC94186A867BEE9B7D91306D39033PEXCVZYM13corpo_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Thomas, all, Regarding your point - because of a 6TSCH node is deeply duty cycle, remote sensing application = (e.g. agricultural applications) can rely on energy harvesting as power sou= rce. I still need to be convinced that 6tsch allows for a lower power consumptio= n than preamble sampling on very low traffic. Therefore I don't think we sh= ould say "6tsch is lower power therefore makes possible new applications therefore w= e should standardize 6tsch". This is overly simplistic. Other arguments that were stated, such as determinism, which is mandated by= industry automation, is a much better seller. To add another one, as I stated in an earlier phone conference, I believe T= SCH is of interest to build mutualized sensor networks that can support sev= eral end customers or services. This is because one can allocate bandwidth = to each supported service independently of the others (under some limits). = This can be modeled beforehand, a decision can be made to admit the new cus= tomer/service or not, and the network can be managed to allocate temporary = extra resources to maintain QoS while a technician is sent to the field to = investigate such things as node failure or severe interference. Granted, se= veral node resources such as energy and memory are still shared between cus= tomers/services but TSCH allows to model and manage these much better than = other wireless link layers. Such a mutualized managed network is much more likely to be profitable and = makes a better use of spectrum than independent, overlaid networks fighting= for the same wireless medium. To a company intending to deploy, operate and manage a sensor network infra= structure, TSCH is good starting point. Comments? Dominique De : 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] De la part de T= homas Watteyne Envoy=E9 : jeudi 21 mars 2013 06:16 =C0 : 6tsch@ietf.org Objet : Re: [6tsch] focussing on charter: use cases Pascal, all, Absolutely agreed. I believe we have started exploring quite a bit, enough = to have a clear understanding of what we can achieve with this technology a= s a WG. So let's spend some time on use cases and building a good case to c= onvince an AD. We could start by listing what TSCH is "good at", and what makes it differe= nt from other solutions. I see the following: - reliability: 5 9's of end-to-end reliability are commonplace. - low-power: aggressive radio duty cycling of the mote's radio yields much = longer lifetime in battery-powered devices. - traffic engineering: the clear identification of resources allows for flo= w independence and QoS. Of course, from those points, industrial applications immediately come to m= ind. Yet, we could take use cases from other areas. We could for example ta= ke the ROLL requirement drafts as a skeleton (I'm paraphrasing some of the = points Xavi and Alfredo made). - industrial automation. A 6TSCH network can allow for high reliability, an= d deterministic behavior. Link over-provisioning can efficiently combat the= unreliable nature of wireless and provide a robust communication. - building automation. A 6TSCH network can serve as an "umbrella" network f= or a large number of sensing points in the building. These sensing points c= an be owned and operated by different entities (e.g. HVAC and lighting). Th= e 6TSCH network allows for the different traffic flows to stay independent = from one another. - because of a 6TSCH node is deeply duty cycle, remote sensing application = (e.g. agricultural applications) can rely on energy harvesting as power sou= rce. - A smart urban parking application can benefit from the reliabilty of 6TS= CH network since, even though the vehicle detection sensor may be static, t= he constant movement of cars around the sensing points can cause the wirele= ss environment to quickly change. Thomas On Tue, Mar 19, 2013 at 12:08 PM, Pascal Thubert (pthubert) > wrote: Dear ML: The activity that we generate on the mailing list is a good indication we w= ill be very successful as a WG. First thing first, though, we need to creat= e the WG and need to focus a little bit on the necessary steps to get there. We need to put together a rough charter, and convince an AD, probably Adria= n from Routing Area or Ted from Internet Area, that we have real problems t= o solve and that we, as a group, can provide valuable answers. The ADs agen= das are very full all the time, but certainly peaks around the meeting time= s. So we have about 2 week in front of us to prepare a solid case. So I suggest we step back a minute from the details of time frames and prio= rities and spend some energy on the use cases, the problems we are solving,= and the work we have to do to get there. I notice a cool discussion on mob= ility and the particular case of a crane, well that's a use case. We alread= y had centralized deterministic (hard slot) routes for command and control,= distributed deterministic (soft slots) and non deterministic QoS based flo= ws. Do we have others cases? Cheers, Pascal _______________________________________________ 6tsch mailing list 6tsch@ietf.org https://www.ietf.org/mailman/listinfo/6tsch ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. --_000_8F1D83ADCC1AC94186A867BEE9B7D91306D39033PEXCVZYM13corpo_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello Thomas, all,

 <= /p>

Regarding your point=

- because of a 6TSCH node is de= eply duty cycle, remote sensing application (e.g. agricultural applications= ) can rely on energy harvesting as power source.

I still ne= ed to be convinced that 6tsch allows for a lower power consumption than pre= amble sampling on very low traffic. Therefore I don’t think we should say

“6ts= ch is lower power therefore makes possible new applications therefore we sh= ould standardize 6tsch”. This is overly simplistic.=

Other argu= ments that were stated, such as determinism, which is mandated by industry = automation, is a much better seller.

 = ;

To add ano= ther one, as I stated in an earlier phone conference, I believe TSCH is of = interest to build mutualized sensor networks that can support several end customers or services. This is because one can allocate bandwi= dth to each supported service independently of the others (under some limit= s). This can be modeled beforehand, a decision can be made to admit the new= customer/service or not, and the network can be managed to allocate temporary extra resources to maintain Q= oS while a technician is sent to the field to investigate such things as no= de failure or severe interference. Granted, several node resources such as = energy and memory are still shared between customers/services but TSCH allows to model and manage these much = better than other wireless link layers.

Such a mut= ualized managed network is much more likely to be profitable and makes a be= tter use of spectrum than independent, overlaid networks fighting for the same wireless medium.

To a compa= ny intending to deploy, operate and manage a sensor network infrastructure,= TSCH is good starting point.

 = ;

Comments?<= o:p>

 = ;

Dominique<= o:p>

 = ;

De : 6tsc= h-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] De la part de Thomas Watteyne
Envoy=E9 : jeudi 21 mars 2013 06:16
=C0 : 6tsch@ietf.org
Objet : Re: [6tsch] focussing on charter: use cases<= /span>

 

Pascal, all,

 

Absolutely agreed. I believe we have started explori= ng quite a bit, enough to have a clear understanding of what we can achieve= with this technology as a WG. So let's spend some time on use cases and bu= ilding a good case to convince an AD.

 

We could start by listing what TSCH is "good at= ", and what makes it different from other solutions. I see the followi= ng:

- reliability: 5 9's of end-to-end reliability are c= ommonplace.

- low-power: aggressive radio duty cycling= of the mote's radio yields much longer lifetime in battery-powered devices= .

- traffic engineering: the clear identification of r= esources allows for flow independence and QoS.

 

Of course, from those points, industrial application= s immediately come to mind. Yet, we could take use cases from other areas. = We could for example take the ROLL requirement drafts as a skeleton (I'm pa= raphrasing some of the points Xavi and Alfredo made).

 

- industrial automation. A = 6TSCH network can allow for high reliability, and deterministic b= ehavior. Link over-provisioning can efficiently combat the unreliable nature of wireless and provide a robust communication. 

- building automation. A 6TSCH network can serve as = an "umbrella" network for a large number of sensing points in the= building. These sensing points can be owned and operated by different enti= ties (e.g. HVAC and lighting). The 6TSCH network allows for the different traffic flows to stay independent from one anothe= r.

- because of a 6TSCH node is deeply duty cycle, remo= te sensing application (e.g. agricultural applications) can rely on energy = harvesting as power source.

- A smart urban parking application can benefit from= the reliabilty of  6TSCH network since, even though the vehicle detec= tion sensor may be static, the constant movement of cars around the sensing= points can cause the wireless environment to quickly change.

 

Thomas

 

On Tue, Mar 19, 2013 at 12:08 PM, Pascal Thubert (pt= hubert) <pthuber= t@cisco.com> wrote:

Dear ML:

 

The activity that we generate on the mailing = list is a good indication we will be very successful as a WG. First thing f= irst, though, we need to create the WG and need to focus a little bit on the necessary steps to get there.

 

We need to put together a rough charter, and = convince an AD, probably Adrian from Routing Area or Ted from Internet Area= , that we have real problems to solve and that we, as a group, can provide valuable answers. The ADs agendas are= very full all the time, but certainly peaks around the meeting times. So w= e have about 2 week in front of us to prepare a solid case.

 

So I suggest we step back a minute from the d= etails of time frames and priorities and spend some energy on the use cases= , the problems we are solving, and the work we have to do to get there. I notice a cool discussion on mobility an= d the particular case of a crane, well that’s a use case. We already = had centralized deterministic (hard slot) routes for command and control, d= istributed deterministic (soft slots) and non deterministic QoS based flows. Do we have others cases?=

Cheers,

 

Pascal

 

 


_______________________________________________
6tsch mailing list
6tsch@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/6tsch

 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.
Thank you.
--_000_8F1D83ADCC1AC94186A867BEE9B7D91306D39033PEXCVZYM13corpo_-- Return-Path: 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 73BAD21F8895 for <6tsch@ietfa.amsl.com>; Sat, 23 Mar 2013 08:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] 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 G9WW3ObqkubC for <6tsch@ietfa.amsl.com>; Sat, 23 Mar 2013 08:08:46 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id A96C021F882F for <6tsch@ietf.org>; Sat, 23 Mar 2013 08:08:45 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 45D6A18C3AF; Sat, 23 Mar 2013 16:08:44 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 2CB1927C046; Sat, 23 Mar 2013 16:08:44 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Sat, 23 Mar 2013 16:08:43 +0100 From: To: "Pascal Thubert (pthubert)" , Thomas Watteyne , "6tsch@ietf.org" <6tsch@ietf.org> Thread-Topic: Agenda for the call March 22nd, 2013 Thread-Index: Ac4mVLDC8NseT7odSWCtQiFRnyZntgAeipSw Date: Sat, 23 Mar 2013 15:08:42 +0000 Message-ID: <1570_1364051324_514DC57C_1570_16957_1_8F1D83ADCC1AC94186A867BEE9B7D91306D38EDA@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.3] Content-Type: multipart/alternative; boundary="_000_8F1D83ADCC1AC94186A867BEE9B7D91306D38EDAPEXCVZYM13corpo_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.3.23.140316 Subject: Re: [6tsch] Agenda for the call March 22nd, 2013 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 15:08:51 -0000 --_000_8F1D83ADCC1AC94186A867BEE9B7D91306D38EDAPEXCVZYM13corpo_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Pascal, Wavi, Thomas, all, Sorry I won't be able to attend the call, on the road again. Some comments, though: *(road,street) traffic control (requires increase of bw as more traffic i= n the road) Why does traffic control require more bandwidth as traffic increases? Aren'= t we reporting data such as number of cars as opposed to each passing car o= ne by one? *smart urban parking (requires redundancy of routes an over-provision a= s RF degrades with cars on top of the sensors) How is this a highlight of TSCH? * green zones. Monitor moisture in gardens, trigger watering. * city lights monitoring. Requires marge scale meshes Again, this doesn't say why TSCH is required or better than anything else, = hence is not a selling point. Xavi, I think you were the one to put these scenarios forward, in another e= mail thead. Can you please comment? Thanks Dominique De : 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] De la part de P= ascal Thubert (pthubert) Envoy=E9 : jeudi 21 mars 2013 17:56 =C0 : Thomas Watteyne; 6tsch@ietf.org Objet : [6tsch] Agenda for the call March 22nd, 2013 Dear all: The focus for tomorrow will be to agree on use cases and derive a problem s= tatement. Please keep in mind that the call will be recorded and the record= published. We already have a list that we can review: - Wireless Process Control (main source for us) * control loops (requires a global optimization of routes for jitter an = latency - thus computed by a PCE -, flow (over) provisioning, duocast, wit= h static multipath hard slot allocation. * control loop plan B (requires self-healing -thus distributed- routing,) * supervisory flows (requires determinism up to the backbone * management (requires a separate topology - a RPL instance - that does = not break) * alerts (bursty, unexpected, dynamic slot allocation, prioritization) * monitoring of lots of lesser importance stuff like corrosion (requires= low cost scalability - this distributed routing ) * cranes that are mobile within a range (requires dynamicity on the last= hop(s) whre the mobility happens and may be deterministic up to that point) * large plants (requires thousands of devices- thus a backbone - within = a subnet - to avoid renumbering) * non-production episodes (requires fast and autonomic behavior - again = distributed routing) * coexistence with legacy devices (requires a common management above) -Smart cities/infrastructures *(road,street) traffic control (requires increase of bw as more traffic= in the road) *smart urban parking (requires redundancy of routes an over-provision a= s RF degrades with cars on top of the sensors) * green zones. Monitor moisture in gardens, trigger watering. * city lights monitoring. Requires marge scale meshes - building automation. * requires redundancy as RF degrades when there are changes on the enviro= nment, doors, moving metallic apparel, etc..) * can be long distance this many hops. Can use lower frequencies to gain = range. - vehicular automation. * We can save copper for most of the man to machine interfaces, which tr= anslates in both lower price and lower gas consumption. - commercial automation. * asset tracking operations on the move (again mobility, and dynamics). * monitoring e.g. temperature of freezers, intrusion sensors, ... Please bring your own thoughts so we can converge at the call : ) As an appetizer, we can start with * summary overview Orlando meeting (10 minutes) * agendas two meetings * 4 drafts presented * TODO: 6tus, add ability for a PCE to set hard cells on one side on= ly (text already changed) * TODO: typos * TODO: terminology Then the entr=E9e (40 minutes) * charter use cases: * review the list above * validate the list of derived problems to be solved * focus on what TSCH is good at: reliability, low-power consumption,= traffic engineering for dessert * open technical discussions * synchronization between BBRs * summarize and discuss proposal * slotframes, cells and priorities * summarize and discuss proposal * interaction between RPL and PCE * summarize current state of the discussion Please let us know if you wish to add / amend stuff in the above : ) Cheers, Pascal PS, call info is as always: Topic: 6TSCH Weekly Date: Every Friday, from Friday, March 8, 2013 to Friday, March 7, 2014 Time: 8:00 am, Pacific Standard Time (San Francisco, GMT-08:00) Meeting Number: 206 802 913 Meeting Password: sixtus ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://cisco.webex.com/ciscosales/j.php?ED=3D219615007&UID=3D0&PW= =3DNZTRkNDAwOTE1&RT=3DMiM0 2. Enter your name and email address. 3. Enter the meeting password: sixtus 4. Click "Join Now". To view in other time zones or languages, please click the link: https://cisco.webex.com/ciscosales/j.php?ED=3D219615007&UID=3D0&PW=3DNZTRkN= DAwOTE1&ORT=3DMiM0 ---------------------------------------------------------------- ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes ---------------------------------------------------------------- The affected toll free numbers are: (866) 432-9903 for the San Jose/Milpita= s area and (866) 349-3520 for the RTP area. Please dial the local access number for your area from the list below: - San Jose/Milpitas (408) area: 525-6800 - RTP (919) area: 392-3330 ------------------------------------------------------- To join the teleconference only ------------------------------------------------------- 1. Dial into Cisco WebEx (view all Global Access Numbers at http://cisco.com/en/US/about/doing_business/conferencing/index.html 2. Follow the prompts to enter the Meeting Number (listed above) or Access = Code followed by the # sign. San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330 US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 India: +91.80.4350.1111 Germany: +49.619.6773.9002 Japan: +81.3.5763.9394 China: +86.10.8515.5666 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://cisco.webex.com/ciscosales/mc 2. On the left navigation bar, click "Support". You can contact me at: pthubert@cisco.com 33-49-723 2634 To add this meeting to your calendar program (for example Microsoft Outlook= ), click this link: https://cisco.webex.com/ciscosales/j.php?ED=3D219615007&UID=3D0&ICS=3DMI&LD= =3D1&RD=3D2&ST=3D1&SHA2=3DAAAAAmvICIpFyZ4imE5seTb7ijZUoMuEgw1h2pXGIGSMyQEb&= RT=3DMiM0 http://www.webex.com CCP:+14085256800x206802913# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns = with the meeting host prior to the start of the recording or do not join th= e session. Please note that any such recordings may be subject to discovery= in the event of litigation. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. --_000_8F1D83ADCC1AC94186A867BEE9B7D91306D38EDAPEXCVZYM13corpo_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello P= ascal, Wavi, Thomas, all,

&n= bsp;

Sorry I= won’t be able to attend the call, on the road again.

Some co= mments, though:

  *(road,street) traffic c= ontrol (requires increase of bw as more traffic in the road)

Why doe= s traffic control require more bandwidth as traffic increases? Aren’t= we reporting data such as number of cars as opposed to each passing car on= e by one?

    *smart urban= parking (requires redundancy of routes an over-provision as RF degrades wi= th cars on top of the sensors)   

How is = this a highlight of TSCH?

    * gr= een zones. Monitor moisture in gardens, trigger watering.=

   * city lights m= onitoring. Requires marge scale meshes

Again, = this doesn’t say why TSCH is required or better than anything else, h= ence is not a selling point.

Xavi, I= think you were the one to put these scenarios forward, in another email th= ead. Can you please comment?

Thanks =

&n= bsp;

Dominique

 

De : 6tsc= h-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] De la part de Pascal Thubert (pthubert)
Envoy=E9 : jeudi 21 mars 2013 17:56
=C0 : Thomas Watteyne; 6tsch@ietf.org
Objet : [6tsch] Agenda for the call March 22nd, 2013=

 

Dear all:

 

The focus for tomorrow will be = to agree on use cases and derive a problem statement. Please keep in mind t= hat the call will be recorded and the record published.

 

We already have a list that we = can review:

 

- Wireless Process Control (= main source for us)

   * control loops (r= equires a global optimization of routes for jitter an latency – thus = computed by a PCE  -, flow (over) provisioning, duocast, with static m= ultipath hard slot allocation.

   * control loo= p plan B (requires self-healing -thus distributed- routing,)

   * supervisory flow= s (requires determinism up to the backbone

   * management (requ= ires a separate topology – a RPL instance - that does not break)=

   * alerts (bursty, = unexpected, dynamic slot allocation, prioritization)

   * monitoring of lo= ts of lesser importance stuff like corrosion (requires low cost scalability= – this distributed routing )

   * cranes that are = mobile within a range (requires dynamicity on the last hop(s) whre the mobi= lity happens and may be deterministic up to that point)

   * large plants (re= quires thousands of devices– thus a backbone – within a subnet = – to avoid renumbering)

   * non-production e= pisodes (requires fast and autonomic behavior – again distributed rou= ting)

   * coexistence with= legacy devices (requires a common management above)

 

-Smart cities/infrastructures <= br>     *(road,street) traffic control (requires increase of bw = as more traffic in the road)
    *smart urban parking (requires redundancy of routes an o= ver-provision as RF degrades with cars on top of the sensors)  &n= bsp;

    * gr= een zones. Monitor moisture in gardens, trigger watering.=

   * city lights m= onitoring. Requires marge scale meshes

 

- building automation. =

  * requires redun= dancy as RF degrades when there are changes on the environment, doors, movi= ng metallic apparel, etc..)

  * can be long distanc= e this many hops. Can use lower frequencies to gain range.

 

- vehicular automation.

   * We can s= ave copper for most of the man to machine interfaces, which translates in b= oth lower price and lower gas consumption.

 

- commercial automation.

  *  asset trackin= g operations on the move (again mobility, and dynamics).<= /p>

  *  monitoring e.= g. temperature of freezers, intrusion sensors, …

 

 

Please bring your own thoughts = so we can converge at the call : )

 

As an appetizer, we can start w= ith

 

  • summary overview Orlando meeting (10 minutes)
      • agendas two meetings
      • 4 drafts presented<= /o:p>
      • = TODO: 6tus, add ability for a PCE to set hard cells on= one side only (text already changed)
      • TODO: typos=
      • TODO: terminology

     

    Then the entr=E9e (40 minutes)<= o:p>

     

    • charter use cases:
      • review the list above
      • validate the list of de= rived problems to be solved
      • focus on what TSCH is= good at: reliability, low-power consumption, traffic engineering

     

    for dessert

    • open technical discussions
      • synchronization between BBRs
        • summarize and discuss proposal
      • slotframes, cells and priorities
        • summarize and discuss proposal
      • interaction between RPL and PCE
        • summarize current state of the discussion

     

     = ;

    Please let us know if you wish = to add / amend stuff in the above : )

     

    Cheers,

     

    Pascal

     

    PS, call info is as always:


    Topic: 6TSCH Weekly
    Date: Every Friday, from Friday, March 8, 2013 to Friday, March 7, 2014
    Time: 8:00 am, Pacific Standard Time (San Francisco, GMT-08:00)
    Meeting Number: 206 802 913
    Meeting Password: sixtus


    -------------------------------------------------------
    To join the online meeting (Now from mobile devices!)
    --------------------------------------------= -----------
    1. Go to
    https://cisco.webex.com/cisco= sales/j.php?ED=3D219615007&UID=3D0&PW=3DNZTRkNDAwOTE1&RT=3DMiM0=
    2.
    Enter your name and email address.
    3. Enter the meeting password: sixtus
    4. Click "Join Now".

    To view in other time zones or languages, please click the link:
    https://cisco= .webex.com/ciscosales/j.php?ED=3D219615007&UID=3D0&PW=3DNZTRkNDAwOT= E1&ORT=3DMiM0

    ----------------------------------------------------------------
    ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes
    ----------------------------------------------------------------

    The affected toll free numbers are: (866) 432-9903 for the San Jose/Milpita= s area and (866) 349-3520 for the RTP area.

    Please dial the local access number for your area from the list below:
    - San Jose/Milpitas (408) area: 525-6800
    - RTP (919) area: 392-3330

    -------------------------------------------------------
    To join the teleconference only
    -------------------------------------------------------
    1. Dial into Cisco WebEx (view all Global Access Numbers at
    http://cisco.com/en/US/about/doing_business/conferen= cing/index.html
    2. Follow the prompts to enter the Meeting Number (listed above) or Access = Code followed by the # sign.

    San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330

    US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117

    India: +91.80.4350.1111 Germany: +49.619.6773.9002

    Japan: +81.3.5763.9394 China: +86.10.8515.5666

    -------------------------------------------------------
    For assistance
    -------------------------------------------------------
    1. Go to https://cisco.webex.com/ciscosales/mc
    2. On the left navigation bar, click "Support".

    You can contact me at:
    pthubert@cisco.com
    33-49-723 2634

    To add this meeting to your calendar program (for example Microsoft Outlook= ), click this link:
    https:= //cisco.webex.com/ciscosales/j.php?ED=3D219615007&UID=3D0&ICS=3DMI&= amp;LD=3D1&RD=3D2&ST=3D1&SHA2=3DAAAAAmvICIpFyZ4imE5seTb7ijZUoMu= Egw1h2pXGIGSMyQEb&RT=3DMiM0






    http://www.webex.com=

    CCP:+14085256800x206802913#

    IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the= start of the recording or do not join the session. Please note that any su= ch recordings may be subject to discovery in the event of litigation.

     

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.
Thank you.
--_000_8F1D83ADCC1AC94186A867BEE9B7D91306D38EDAPEXCVZYM13corpo_-- Return-Path: 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 DD38921F88C1 for <6tsch@ietfa.amsl.com>; Sat, 23 Mar 2013 00:53:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[AWL=0.355, 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 HNc6ehJ6Ds6X for <6tsch@ietfa.amsl.com>; Sat, 23 Mar 2013 00:53:27 -0700 (PDT) Received: from mail-pa0-f43.google.com (mail-pa0-f43.google.com [209.85.220.43]) by ietfa.amsl.com (Postfix) with ESMTP id D27EE21F88BC for <6tsch@ietf.org>; Sat, 23 Mar 2013 00:53:26 -0700 (PDT) Received: by mail-pa0-f43.google.com with SMTP id rl6so277467pac.30 for <6tsch@ietf.org>; Sat, 23 Mar 2013 00:53:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:from:date:x-google-sender-auth :message-id:subject:to:content-type; bh=aqpmWmI16mgWFhebf3EHOMthLnOG7wyRUafcrpOY7Zg=; b=Y9dlZPTXZi+RlOYsJ+/s6iks7hYyio4nKWPdo8F7uTpyytrOdQbjL8xUR+7IpFh6LA r9t4q/fIte2RFFAWKWma19LhnfShpPbIF9kto5csCOjo3uPJwwUI8bX6x3zmFVev8nnT a0zoRkxLCzCM7xu34zy+1Hy7HQbUfbpVMHrlbbVwg8BZAcbBqYRx/jbe8pxCc7KBoMac 72Yek0pbBCBdyz7xbE5Bf/CIa2oLBYGu7TcdUIAIHVP6elScz5fdr/GK3FAd/72GMmaH IaaBpfW6pxL8iBVA72ejQ5H5sh4QZHhzxzTFxliDDVBMhaN1NNSGBkgwZJ2exe/Qtfmj 10RA== X-Received: by 10.66.233.9 with SMTP id ts9mr2962379pac.15.1364025206579; Sat, 23 Mar 2013 00:53:26 -0700 (PDT) MIME-Version: 1.0 Sender: twatteyne@gmail.com Received: by 10.68.227.71 with HTTP; Sat, 23 Mar 2013 00:53:06 -0700 (PDT) From: Thomas Watteyne Date: Sat, 23 Mar 2013 00:53:06 -0700 X-Google-Sender-Auth: zbgyoCFTk366NO_6MnYYkwIbob0 Message-ID: To: IETF 6TSCH <6tsch@ietf.org> Content-Type: multipart/mixed; boundary=047d7b111c53e7265904d892dd1e Subject: [6tsch] minutes WebEx 22 March 2013 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 07:53:29 -0000 --047d7b111c53e7265904d892dd1e Content-Type: multipart/alternative; boundary=047d7b111c53e7265504d892dd1c --047d7b111c53e7265504d892dd1c Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable All, Please find the minutes of today's meeting below. Attached are the slides presented. *Note: I understand that some of us have missed the call today because of the switch to summer time in the PST area. Apologies for not sending a clear reminder yesterday, will do next week. As an early reminder: it will be the same next week (3/29), i.e. call will be at 4pm CET. The week after that (4/5), we will be back to normal (5pm CET), since the CET region will have switched to summer time.* Thomas --- *** Timestamps in PDT *** Present: - Bogdan Pavkovic - Maria Rita Palattella - Pascal Thubert - Qin Wang - Raghuram Sudhaakar - Thomas Watteyne - Tina Tsou - Tom Phinney - Xavi Vilajosana Webex recording (audio+slides,streaming): - https://cisco.webex.com/ciscosales/lsr.php?AT=3Dpb&SP=3DMC&rID=3D66940742&r= Key=3D711b58d40cd574d9[54min] Attached slides: - 6tsch_use_cases_call03222013.pptx: slides shared during the call and edited live by Pascal Agenda: - Summary overview Orlando meeting [10min] . overview two meetings . 4 drafts presented . TODOs: . 6tus draft, add ability for a PCE to set hard cells on one side only (text already changed) . typos . match terminology draft - Charter use cases [40min] . review the following list . Wireless Process Control (main source for us) . control loops (requires a global optimization of routes for jitter and latency =96 thus computed by a PCE -, flow (over) provisioning, duocast, with static multipath hard slot allocation. . control loop plan B (requires self-healing -thus distributed- routing,) . supervisory flows (requires determinism up to the backbone . management (requires a separate topology =96 a RPL instance - that does not break) . alerts (bursty, unexpected, dynamic slot allocation, prioritization) . monitoring of lots of lesser importance stuff like corrosion (requires low cost scalability =96 this distributed routing ) . cranes that are mobile within a range (requires dynamicity on the last hop(s) whre the mobility happens and may be deterministic up to that point) . large plants (requires thousands of devices=96 thus a backbone= =96 within a subnet =96 to avoid renumbering) . non-production episodes (requires fast and autonomic behavior =96 again distributed routing) . coexistence with legacy devices (requires a common management above) - Smart cities/infrastructures .(road,street) traffic control (requires increase of bw as more traffic in the road) .smart urban parking (requires redundancy of routes an over-provision as RF degrades with cars on top of the sensors) . green zones. Monitor moisture in gardens, trigger watering. . city lights monitoring. Requires marge scale meshes - building automation. . requires redundancy as RF degrades when there are changes on the environment, doors, moving metallic apparel, etc..) . can be long distance this many hops. Can use lower frequencies to gain range. - vehicular automation. . We can save copper for most of the man to machine interfaces, which translates in both lower price and lower gas consumption. - commercial automation. . asset tracking operations on the move (again mobility, and dynamics). . monitoring e.g. temperature of freezers, intrusion sensors, . validate the list of derived problems to be solved . focus on what TSCH is good at: reliability, low-power consumption, traffic engineering - Open technical discussions [time permitting] . synchronization between BBRs . summarize and discuss proposal . slotframes, cells and priorities . summarize and discuss proposal . interaction between RPL and PCE . summarize current state of the discussion Minutes: - [08.05] Meeting starts - [08.05] Overview IETF 86 Orlando . 2 6TSCH information meetings . Tuesday: administrative and general information. . Adoption of draft-ietf-roll-rpl-industrial-applicability-00 as starting point for 6TSCH requirements . Many non-6TSCH people discovered the group. . Positive feedback. . Wednesday: technical discussion, . 4 6TSCH drafts presented . 2 non-6TSCH drafts presented . all information, including full minutes and slides are at https://bitbucket.org/6tsch/ietf86-orlando/ - [08.15] Discussion on charter use cases . Pascal shares slides from [6tsch_use_cases_call03222013.pptx] . Goal: discuss the different use cases scenarios <<< Below is only a list of the points discussed. Refer to the attached slides for contents. >>> . Duocast . [Tom] duocast applies only to single hop. . [Pascal] Edits slide. . Supervisory flows . [Pascal] Do we want the flow to be deterministic to a supervisor which sits in the backbone? This implies matching the LLN schedule to some backbone link-layer schedule? . [Tom] BB has orders of magnitude more bandwidth than LLN. Will never be constrained. We don't need to have determinism in the BB. . [Thomas] We could consider this isssue out-of-scope for 6TSCH. . [Pascal] Edits slide. . Management topology . [Pascal] do we want to separate the management traffic from data traffic to ensure availability? . [All] Agreed/ . [Pascal] Adds open issues: OF and root selection to slide. . Alerts . [Pascal] Proposal: allow for burst of traffic to generate some on-demand ("on-the-fly") distributed reservation? . [Thomas] Potentially complicates things. Why not consider a burty traffic as a problem for the scheduling entity to taken care of. . [Pascal] Edits slide. . Support for lesser important "background" traffic. . [Pascal] Allow for traffic to flow along RPL routes, using soft cell allocation, possibly alongside PCE-allocated hard cells. . [Thomas] Agreed since probably relatively easy to do (hard cell have priority over soft cells, if hard cell is installed at same timeslot/channeloffset as soft cell, soft cell needs to move). Yet, this might bring complexity, so let's separate PCE/distributed approaches. . Mobility . [Pascal] Presents idea from Alfredo, whereby data from a mobile crane would travel over a RPL "half-track" before reaching PCE "half-track"= . . [Thomas] Not is favor of mixing distributed and centralized routing in a track. . [Thomas,Tom] What we understood from Alfredo's proposal was to have same cells scheduled at several potential neighbors of the node mounted on the crane. . [Tom] Agreed. . [Pascal] Agreed. . [Pascal] Marks issue as "no goal". . [Tom] Mobility case makes sense, e.g. for large container cranes traveling along a track. Two cranes can pick up each side of a large object. One can imagine automated communication (now human operators with radio). . [Tom] Second example is pivoting crane. . [Pascal] Splits mobile case if "crane" and "mobile" worker. . [Tom] Mobile worker does not require deterministic schedules. . Large plants . [Pascal] Concept of multiple BBRs interconnected by BB to allow nodes from different LLNs to be in same IPv6 prefix. Useful? . [Raghuram] In some cases, we want to know exactly where a node is, having the same prefix might remove that information. . [Thomas] System can be built so that a network operator can know to which BBR a node is attached, yet all nodes still in same prefix. . [Pascal] Edits slide to indicate same prefix not always needed, isolation somtimes wanted. . [Thomas] Wants to stress that we also want to support a case where one big LLN with multiple BBRs. . [Pascal] Agreed, text encompasses this case. . Non-production phases . [Pascal] RPL can be needed as backup or for recovery. . [Thomas] Very well explained in draft-ietf-roll-rpl-industrial-applicability-00. Agreed. . Coexistence . [Pascal] Do we need a common management entity which could know about the different schedules of different LLNs (possible covering IEEE802.15.4e TSCH, WHART and ISA1000) to facilitate coexistence? . [Thomas] Such fine-grained (at cell level) coexistance management not needed. Several network in same radio space work fine. Coarse-grained can be easily implemented. E.g. blacklisting some frequency on which a single-channel network runs, and which does not support a different network= . <<< Time's up, we don't go through additional slides >>> - [09.00] What's next? . for the coming week: . finalize the list of use cases, with slideset as a base, on the M= L . start working on extra items (per Marc Blanchet's suggestion): . what needs to be done in IETF . milestones and deliverables. . at next meeting: finalize discussion on use cases, and move on to two points above. - [09.05] Meeting ends --047d7b111c53e7265504d892dd1c Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable All,

Please find the minutes of today's meeting belo= w. Attached are the slides presented.

Note: I u= nderstand that some of us have missed the call today because of the switch = to summer time in the PST area.=A0Apologies=A0for not sending a clear remin= der yesterday, will do next week. As an early reminder: it will be the same= next week (3/29), i.e. call will be at 4pm CET. The week after that (4/5),= we will be back to normal (5pm CET), since the CET region will have switch= ed to summer time.

Thomas

---

*** Timestamps in PDT ***<= /font>

Present:
- Bogdan Pavkovic
- Maria Rita Palattella
- Pascal Thubert
- Qin Wang
- Raghuram Sudhaakar
- Thomas Watteyne
- Tina Tsou
- Tom Phinney
<= font face=3D"courier new, monospace">- Xavi Vilajosana

Webex recording (audio+slides,streaming):
- https://cisco.webex.com/ciscosales/lsr.php?AT=3Dpb&SP= =3DMC&rID=3D66940742&rKey=3D711b58d40cd574d9 [54min]

Attached slides:
- 6tsch_use_cases_call03222013.pptx: slides shared= during the call and edited live by Pascal

Agenda:
- Summary overview Orlando meeting [10min]
=A0 =A0 . overview two meetings
=A0 =A0 . 4 drafts presented
=A0 =A0 . TODOs:=
=A0 =A0 =A0 =A0 . 6tus dra= ft, add ability for a PCE to set hard cells on one side only (text already = changed)
=A0 =A0 =A0 =A0 . typos
=A0 =A0 =A0 =A0 . match term= inology draft
- Char= ter use cases [40min]
=A0 =A0 . review the following l= ist
=A0 =A0 =A0 =A0 = . Wireless Process Control (main source for us)
=A0 =A0 =A0 =A0 =A0 =A0. control loops (require= s a global optimization of routes for jitter and latency =96 thus computed = by a PCE -, flow (over) provisioning, duocast, with static multipath hard s= lot allocation.
=A0 =A0 =A0 =A0 =A0 =A0. control= loop plan B (requires self-healing -thus distributed- routing,)
=A0 =A0 =A0 =A0 =A0 =A0. super= visory flows (requires determinism up to the backbone
=A0 =A0 =A0 =A0 =A0 =A0. managem= ent (requires a separate topology =96 a RPL instance - that does not break)=
=A0 =A0 =A0 =A0 =A0= =A0. alerts (bursty, unexpected, dynamic slot allocation, prioritization)<= /font>
=A0 =A0 =A0 =A0 =A0 =A0. monitor= ing of lots of lesser importance stuff like corrosion (requires low cost sc= alability =96 this distributed routing )
=A0 =A0 =A0 =A0 =A0 =A0. cranes that are mobile within= a range (requires dynamicity on the last hop(s) whre the mobility happens = and may be deterministic up to that point)
=A0 =A0 =A0 =A0 =A0 =A0. large p= lants (requires thousands of devices=96 thus a backbone =96 within a subnet= =96 to avoid renumbering)
=A0 =A0 =A0 =A0 =A0 =A0. non-production episodes (requires fast and = autonomic behavior =96 again distributed routing)
=A0 =A0 =A0 =A0 =A0 =A0. coexist= ence with legacy devices (requires a common management above)
<= div>=A0 =A0 =A0 =A0 - Smart cities/in= frastructures=A0
=A0 =A0 =A0 =A0 =A0 =A0 .(road,s= treet) traffic control (requires increase of bw as more traffic in the road= )
=A0 =A0 =A0 =A0 = =A0 =A0 .smart urban parking (requires redundancy of routes an over-provisi= on as RF degrades with cars on top of the sensors) =A0=A0
=A0 =A0 =A0 =A0 =A0 =A0 . green = zones. Monitor moisture in gardens, trigger watering.
=A0 =A0 =A0 =A0 =A0 =A0 . city lights mon= itoring. Requires marge scale meshes
=A0 =A0 =A0 =A0 - building autom= ation.
=A0 =A0 =A0 = =A0 =A0 =A0. requires redundancy as RF degrades when there are changes on t= he environment, doors, moving metallic apparel, etc..)
=A0 =A0 =A0 =A0 =A0 =A0. can be = long distance this many hops. Can use lower frequencies to gain range.
=A0 =A0 =A0 =A0 - vehicu= lar automation.
=A0 =A0 =A0 =A0 =A0 =A0. We can = save copper for most of the man to machine interfaces, which translates in = both lower price and lower gas consumption.
=A0 =A0 =A0 =A0 - commercial automation.
=A0 =A0 =A0 =A0 =A0 . =A0asset t= racking operations on the move (again mobility, and dynamics).
=
=A0 =A0 =A0 =A0 =A0 . =A0monitor= ing e.g. temperature of freezers, intrusion sensors,
=A0 =A0 . validate the list of d= erived problems to be solved
=A0 =A0 . focus on what TSCH is good at: reliability, low-power co= nsumption, traffic engineering
- Open technical discussions [ti= me permitting]
=A0 = =A0 . synchronization between BBRs
=A0 =A0 =A0 =A0 . summarize and discuss proposal
=A0 =A0 . slotframes, cells and = priorities
=A0 =A0 = =A0 =A0 . summarize and discuss proposal
=A0 =A0 . interaction between RPL and PCE
=A0 =A0 =A0 =A0 . summarize curr= ent state of the discussion

Minutes= :
- [08.05] Meeting starts<= /div>
- [08.05] Overview IETF 86 = Orlando
=A0 =A0 . 2 = 6TSCH information meetings
=A0 =A0 =A0 =A0 . Tuesday: admin= istrative and general information.
=A0 =A0 =A0 =A0 =A0 =A0 . Adoption of draft-ietf-roll-rpl-in= dustrial-applicability-00 as starting point for 6TSCH requirements
=A0 =A0 =A0 =A0 =A0 =A0 . Many n= on-6TSCH people discovered the group.
=A0 =A0 =A0 =A0 =A0 =A0 . Positive feedback.
=
=A0 =A0 =A0 =A0 . Wednesday: tec= hnical discussion,
=A0 =A0 =A0 =A0 =A0 =A0 . 4 6TSC= H drafts presented
= =A0 =A0 =A0 =A0 =A0 =A0 . 2 non-6TSCH drafts presented
=A0 =A0 . all information, including ful= l minutes and slides are at https://bitbucket.org/6tsch/ietf86-orlando/
- [08.15] Discussion on charter = use cases
=A0 =A0 . = Pascal shares slides from [6tsch_use_cases_call03222013.pptx]
<= div> =A0 =A0 . Goal: discuss the different= use cases scenarios
=A0 =A0 <<< Below is only a list of the points discussed. Refer t= o the attached slides for contents. >>>
=A0 =A0 . Duocast
=A0 =A0 =A0 =A0 . [Tom] duocast ap= plies only to single hop.
=A0 =A0 =A0 =A0 . [Pascal] Edits slide.
=A0 =A0 . Supervisory flows
=A0 =A0 =A0 =A0 . [Pasca= l] Do we want the flow to be deterministic to a supervisor which sits in th= e backbone? This implies matching the LLN schedule to some backbone link-la= yer schedule?
=A0 =A0 =A0 =A0 . [Tom] BB has o= rders of magnitude more bandwidth than LLN. Will never be constrained. We d= on't need to have determinism in the BB.
=A0 =A0 =A0 =A0 . [Thomas] We could consider this = isssue out-of-scope for 6TSCH.
=A0 =A0 =A0 =A0 . [Pascal] Edits= slide.
=A0 =A0 . Ma= nagement topology
= =A0 =A0 =A0 =A0 . [Pascal] do we want to separate the management traffic fr= om data traffic to ensure availability?
=A0 =A0 =A0 =A0 . [All] Agreed/<= /font>
=A0 =A0 =A0 =A0 . [P= ascal] Adds open issues: OF and root selection to slide.
<= font face=3D"courier new, monospace">=A0 =A0 . Alerts
=A0 =A0 =A0 =A0 . [Pascal] Propo= sal: allow for burst of traffic to generate some on-demand ("on-the-fl= y") distributed reservation?
=A0 =A0 =A0 =A0 . [Thomas] Potentially complicates things. Wh= y not consider a burty traffic as a problem for the scheduling entity to ta= ken care of.
=A0 =A0 =A0 =A0 . [Pascal] Edits= slide.
=A0 =A0 . Su= pport for lesser important "background" traffic.
=A0 =A0 =A0 =A0 . [Pascal] Allow for= traffic to flow along RPL routes, using soft cell allocation, possibly alo= ngside PCE-allocated hard cells.
=A0 =A0 =A0 =A0 . [Thomas] Agree= d since probably relatively easy to do (hard cell have priority over soft c= ells, if hard cell is installed at same timeslot/channeloffset as soft cell= , soft cell needs to move). Yet, this might bring complexity, so let's = separate PCE/distributed approaches.
=A0 =A0 . Mobility
<= div>=A0 =A0 =A0 =A0 . [Pascal] Presen= ts idea from Alfredo, whereby data from a mobile crane would travel over a = RPL "half-track" before reaching PCE "half-track".
=A0 =A0 =A0 =A0 . [Thomas] Not i= s favor of mixing distributed and centralized routing in a track.
=A0 =A0 =A0 =A0 . [Thomas,Tom= ] What we understood from Alfredo's proposal was to have same cells sch= eduled at several potential neighbors of the node mounted on the crane.
=A0 =A0 =A0 =A0 . [Tom] Agreed.<= /font>
=A0 =A0 =A0 =A0 . [P= ascal] Agreed.
=A0 = =A0 =A0 =A0 . [Pascal] Marks issue as "no goal".
=A0 =A0 =A0 =A0 . [Tom] Mobility= case makes sense, e.g. for large container cranes traveling along a track.= Two cranes can pick up each side of a large object. One can imagine automa= ted communication (now human operators with radio).
=A0 =A0 =A0 =A0 . [Tom] Second e= xample is pivoting crane.
=A0 =A0 =A0 =A0 . [Pascal] Splits mobile case if "crane" an= d "mobile" worker.
=A0 =A0 =A0 =A0 . [Tom] Mobile w= orker does not require deterministic schedules.
=A0 =A0 . Large plants
=A0 =A0 =A0 =A0 . [Pascal] Concept of multip= le BBRs interconnected by BB to allow nodes from different LLNs to be in sa= me IPv6 prefix. Useful?
=A0 =A0 =A0 =A0 . [Raghuram] In = some cases, we want to know exactly where a node is, having the same prefix= might remove that information.
=A0 =A0 =A0 =A0 . [Thomas] System can be built so that a networ= k operator can know to which BBR a node is attached, yet all nodes still in= same prefix.
=A0 =A0 =A0 =A0 . [Pascal] Edits= slide to indicate same prefix not always needed, isolation somtimes wanted= .
=A0 =A0 =A0 =A0 . = [Thomas] Wants to stress that we also want to support a case where one big = LLN with multiple BBRs.
=A0 =A0 =A0 =A0 . [Pascal] Agree= d, text encompasses this case.
=A0 =A0 . Non-production phases
=A0 =A0 =A0 =A0 . [Pascal] RPL can be needed as back= up or for recovery.
=A0 =A0 =A0 =A0 . [Thomas] Very = well explained in draft-ietf-roll-rpl-industrial-applicability-00. Agreed.<= /font>
=A0 =A0 . Coexistenc= e
=A0 =A0 =A0 =A0 . [Pascal] Do we= need a common management entity which could know about the different sched= ules of different LLNs (possible covering IEEE802.15.4e TSCH, WHART and ISA= 1000) to facilitate coexistence?
=A0 =A0 =A0 =A0 . [Thomas] Such = fine-grained (at cell level) coexistance management not needed. Several net= work in same radio space work fine. Coarse-grained can be easily implemente= d. E.g. blacklisting some frequency on which a single-channel network runs,= and which does not support a different network.
=A0 =A0 <<< Time's = up, we don't go through additional slides >>>
- [09.00] What's next?
=A0 =A0 . for the coming week:=
=A0 =A0 =A0 =A0 . finalize= the list of use cases, with slideset as a base, on the ML
=A0 =A0 =A0 =A0 . start working on e= xtra items (per Marc Blanchet's suggestion):
=A0 =A0 =A0 =A0 =A0 =A0 . what n= eeds to be done in IETF
=A0 =A0 =A0 =A0 =A0 =A0 . milestones and deliverables.
=A0 =A0 . at next meeting: finalize = discussion on use cases, and move on to two points above.
- [09.05] Meeting ends
--047d7b111c53e7265504d892dd1c-- --047d7b111c53e7265904d892dd1e Content-Type: application/vnd.openxmlformats-officedocument.presentationml.presentation; name="6tsch_use_cases_call03222013.pptx" Content-Disposition: attachment; filename="6tsch_use_cases_call03222013.pptx" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hemggsen0 UEsDBBQABgAIAAAAIQBi+1zGJgIAANQPAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADE l91u2jAUx+8r7R0i307EtNu6tiL0Yh9XW1tp7QO4yQG8ObZlG1bevidOiABZJTRYuSFKgs/5+Xz4 /DO5fSlFsgJjuZIZOU/HJAGZq4LLeUaeHn+OrkhiHZMFE0pCRtZgye30w9nkca3BJrha2owsnNM3 lNp8ASWzqdIg8c1MmZI5vDVzqln+j82BXozHlzRX0oF0I1fZINPJPQIYXkDywIy7YyX6oVo7agU+ tPXlS4oWSfKtXlp5zwjTWvCcOWSnK1ns+R2p2YznUKh8WaK3VBuwePV/L0XqjX+sjNJuBJfDEfxi a7V0TSTqm69RaGrbnaISYLoamuk3sw5rua6Y+uY8ClNtu1OcGppPUTiOIfg8CEHVdQ9GaXtq763h TjEIVGucePTroDinXD+mOOfeEUxNB8Xp5E7V0xBcnLqGO80gh0MVqP/tHwJvptOeAx0TZ/9HVEKA Kc65usv0HWZsKVzy4wVlS62U/mqY76kRXlYCx79ARRFYY0DYvTUHFEyjmlJc6WWLXXBtN9kLeHhb Ih3QOtv66NSFvmO7ZFxuNvGm9Auku38HbKNsZOBuukNMqCL9FKOYsd7BgaqOCihGGgcjGMehTWrI dyWFHXsW8MetBZx8kG6ZfndWhkpL+5UQKpVx70S9r1ZaqGZsxJHqnXLVEMQR5ocIVhz+R5F+reFD BH6+BkrjeqDKaE+RXBk4nmEzDqrVgbOD+m/y6SsAAAD//wMAUEsDBBQABgAIAAAAIQBo+HShBQEA AOICAAALAAgCX3JlbHMvLnJlbHMgogQCKKAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAArJLbSgMxEIbvBd8hzH032yoi0mxvROidyPoAYzK7 G90cSKbSvr2h4GFhLYK9nNM/X/LPerN3o3inlG3wCpZVDYK8Dsb6XsFz+7C4BZEZvcExeFJwoAyb 5vJi/UQjchnKg41ZFBWfFQzM8U7KrAdymKsQyZdKF5JDLmHqZUT9hj3JVV3fyPRTA5qJptgaBWlr rkC0h1g2/0dbOmI0yCh1SLSIqZAltuUtosXUEyswQT+WdD52VIUa5DzQ6rxAPOzci0c7zqB81arX SP1vQMu/A4Wus5rug9458jxjgpx2fDPFyDImymXsaPupH7o+JxDtmbwhc9o0jPGTSE4us/kAAAD/ /wMAUEsDBBQABgAIAAAAIQBL9T3svwAAADcBAAAgAAAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTMu eG1sLnJlbHOEj8EKwjAQRO+C/xD2blI9iEhTLyIInkQ/YEm2bbBNQjaK/XtzrCB4nB3mzU59eI+D eFFiF7yGtaxAkDfBOt9puN9Oqx0IzugtDsGThokYDs1yUV9pwFxC3LvIolA8a+hzjnul2PQ0IssQ yRenDWnEXGTqVETzwI7Upqq2Ks0Z0HwxxdlqSGe7BnGbYmn+zw5t6wwdg3mO5POPCsWDs3TBKTxz wWLqKGuQcn7nudjI8j6oplZfc5sPAAAA//8DAFBLAwQUAAYACAAAACEAY1wjtMEAAAA3AQAAIAAA AHBwdC9zbGlkZXMvX3JlbHMvc2xpZGUxLnhtbC5yZWxzhI/BasMwEETvhfyD2HskO4dSimVfQiCQ U3E+YJHWtogtCa0S6r+vjjYEepwd5s1O0/0us3hRYhe8hlpWIMibYJ0fNdz7y/ELBGf0FufgScNK DF17+Gh+aMZcQjy5yKJQPGuYco7fSrGZaEGWIZIvzhDSgrnINKqI5oEjqVNVfaq0ZUC7Y4qr1ZCu tgbRr7E0/88Ow+AMnYN5LuTzmwrFs7N0wzU8c8FiGilrkHJ7562oZXkfVNuo3dz2DwAA//8DAFBL AwQUAAYACAAAACEAS/U97L8AAAA3AQAAIAAAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGU0LnhtbC5y ZWxzhI/BCsIwEETvgv8Q9m5SPYhIUy8iCJ5EP2BJtm2wTUI2iv17c6wgeJwd5s1OfXiPg3hRYhe8 hrWsQJA3wTrfabjfTqsdCM7oLQ7Bk4aJGA7NclFfacBcQty7yKJQPGvoc457pdj0NCLLEMkXpw1p xFxk6lRE88CO1KaqtirNGdB8McXZakhnuwZxm2Jp/s8ObesMHYN5juTzjwrFg7N0wSk8c8Fi6ihr kHJ+57nYyPI+qKZWX3ObDwAAAP//AwBQSwMEFAAGAAgAAAAhAEv1Pey/AAAANwEAACAAAABwcHQv c2xpZGVzL19yZWxzL3NsaWRlMi54bWwucmVsc4SPwQrCMBBE74L/EPZuUj2ISFMvIgieRD9gSbZt sE1CNor9e3OsIHicHebNTn14j4N4UWIXvIa1rECQN8E632m4306rHQjO6C0OwZOGiRgOzXJRX2nA XELcu8iiUDxr6HOOe6XY9DQiyxDJF6cNacRcZOpURPPAjtSmqrYqzRnQfDHF2WpIZ7sGcZtiaf7P Dm3rDB2DeY7k848KxYOzdMEpPHPBYuooa5Byfue52MjyPqimVl9zmw8AAAD//wMAUEsDBBQABgAI AAAAIQBL9T3svwAAADcBAAAgAAAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTUueG1sLnJlbHOEj8EK wjAQRO+C/xD2blI9iEhTLyIInkQ/YEm2bbBNQjaK/XtzrCB4nB3mzU59eI+DeFFiF7yGtaxAkDfB Ot9puN9Oqx0IzugtDsGThokYDs1yUV9pwFxC3LvIolA8a+hzjnul2PQ0IssQyRenDWnEXGTqVETz wI7Upqq2Ks0Z0HwxxdlqSGe7BnGbYmn+zw5t6wwdg3mO5POPCsWDs3TBKTxzwWLqKGuQcn7nudjI 8j6oplZfc5sPAAAA//8DAFBLAwQUAAYACAAAACEAS/U97L8AAAA3AQAAIAAAAHBwdC9zbGlkZXMv X3JlbHMvc2xpZGU2LnhtbC5yZWxzhI/BCsIwEETvgv8Q9m5SPYhIUy8iCJ5EP2BJtm2wTUI2iv17 c6wgeJwd5s1OfXiPg3hRYhe8hrWsQJA3wTrfabjfTqsdCM7oLQ7Bk4aJGA7NclFfacBcQty7yKJQ PGvoc457pdj0NCLLEMkXpw1pxFxk6lRE88CO1KaqtirNGdB8McXZakhnuwZxm2Jp/s8ObesMHYN5 juTzjwrFg7N0wSk8c8Fi6ihrkHJ+57nYyPI+qKZWX3ObDwAAAP//AwBQSwMEFAAGAAgAAAAhAEv1 Pey/AAAANwEAACAAAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlNy54bWwucmVsc4SPwQrCMBBE74L/ EPZuUj2ISFMvIgieRD9gSbZtsE1CNor9e3OsIHicHebNTn14j4N4UWIXvIa1rECQN8E632m4306r HQjO6C0OwZOGiRgOzXJRX2nAXELcu8iiUDxr6HOOe6XY9DQiyxDJF6cNacRcZOpURPPAjtSmqrYq zRnQfDHF2WpIZ7sGcZtiaf7PDm3rDB2DeY7k848KxYOzdMEpPHPBYuooa5Byfue52MjyPqimVl9z mw8AAAD//wMAUEsDBBQABgAIAAAAIQBL9T3svwAAADcBAAAgAAAAcHB0L3NsaWRlcy9fcmVscy9z bGlkZTgueG1sLnJlbHOEj8EKwjAQRO+C/xD2blI9iEhTLyIInkQ/YEm2bbBNQjaK/XtzrCB4nB3m zU59eI+DeFFiF7yGtaxAkDfBOt9puN9Oqx0IzugtDsGThokYDs1yUV9pwFxC3LvIolA8a+hzjnul 2PQ0IssQyRenDWnEXGTqVETzwI7Upqq2Ks0Z0HwxxdlqSGe7BnGbYmn+zw5t6wwdg3mO5POPCsWD s3TBKTxzwWLqKGuQcn7nudjI8j6oplZfc5sPAAAA//8DAFBLAwQUAAYACAAAACEAp3Qv2U8BAAB3 BwAAHwAIAXBwdC9fcmVscy9wcmVzZW50YXRpb24ueG1sLnJlbHMgogQBKKAAAQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAC81d1OgzAUB/B7E9+B9F5K2admsBtjsgsTo/MBOjh8RGibtk55exs2 kS3L8abZDUkPcPrLn7as1t9tE+xBm1qKhLAwIgGITOa1KBPyvn26W5LAWC5y3kgBCenAkHV6e7N6 hYZb95KpamUC10WYhFTWqgdKTVZBy00oFQh3p5C65dYNdUkVzz54CTSOojnV4x4kPekZbPKE6E3u 5t92ys38f29ZFHUGjzL7bEHYC1NQ09Q5uIZcl2AT0g/NoboInZTQywg28amwfNfAm+0al+VgGRUx iVcIEkeMIRY+00AQcwzBYp8K61bsaGX0Q9pfGYbwakCSQBHMZxA94pkbC/pvcY6Kx+1yeAJlzb2z zkBHygz7QMxrOPsavl60VKN9O5QwxexKUUwxBHNnu7+jVGkwZ1EMJUwx9YlAdswEQ9xfCbH8RdCT 32X6AwAA//8DAFBLAwQUAAYACAAAACEAqnnZeXcCAAB1DQAAFAAAAHBwdC9wcmVzZW50YXRpb24u eG1s7JdRjtowEIbfK/UOkV8rNiSEJESEldoKaSUqocIewJsMEK3jRLahsKfv2DHgElXaA+Qtzu/5 PfMxdsz8+Vwz7wRCVg3PSfA0Jh7woikrvs/J63Y5SoknFeUlZQ2HnFxAkufF1y/zNmsFSOCKKgz1 0IbLjObkoFSb+b4sDlBT+dS0wFHbNaKmCodi75eC/kH7mvnheBz7Na04sfHiM/HNblcV8LMpjjUu 35kIYCYPeahaeXVrP+PmVvFvSpKeYHN8k6CWDVcS6ZAFli1Z+YtKBeKlXEn18MarypyEQZRE6SSO kJ3I9BucGxB/Mff/E+5avZSdyTR2okMdbYJvsms+6cuJEx315ZkjT3tyjG1wyzzuy4EjJ305dOS0 L08ceablDosLYfPhFeeczIIoGo8xmeKSkzidpmagLi12oiwEAI/OtnbeKJA27DZTh109DMASdvTI 1BbOaqMuDBZzmuG79VrYp99r4TGqmx/46HVjsnOnsBMLWpxTU7HKCWZG2R43DiMe2mzp2+bjuiIW qZiZAnTFv4t33UDorSpuhxh9wKVwL6yPvFBdg5nFdBYSnQIsmHjvIPTexN2CDUgz2bCqXFaMmYHe Z/CDCe9EcTV17vrsYZZZ1dPcdrRAdt9qPmJKF0czoA8C0E4o5INQyDsOzBB/N5pZHtoIH8M7mmia 6IQHPgaK5TO58+nacuBzYhqK5RPd+QSTJIiHBtK7SlOxgKYOoDRMzfEwnECaigUU3wGFYYoNNBxB 2EGaigWUOICSaDKc0ebDpalYQOkdkKaD94/hkD4xTcUCmjmA4mkyHNKmgzQVc5PtXzHxeuv+y1j8 BQAA//8DAFBLAwQUAAYACAAAACEAn3IMql0CAABXBQAAFQAAAHBwdC9zbGlkZXMvc2xpZGUxLnht bKxUbW/aMBD+Pmn/wfLnhZAQKI0IVUPLNKkvaNAfYBxDojm2ZZsUNO2/7+LE7ba2UqX1S2Kf7x7f 89z5ZhfHmqOGaVNJkeFoMMSICSqLSuwz/LBZBlOMjCWiIFwKluETM/hi/vnTTKWGFwiihUlJhktr VRqGhpasJmYgFRNwtpO6Jha2eh8WmjwCas3DeDichDWpBO7j9Xvi5W5XUXYl6aFmwnYgmnFiIXNT Vsp4NPUeNKWZARgX/VdKc2BG17xo/0ZtNGPtSjRftVqrlXbHd81Ko6oAvTASpAZZcNgf9G5uK8AN FuE/4XuPRNLjTtfzGUmBGzpmGMQ/tV8IIik7WkQ7I3220vL+FV9aXr/iHfoLIIOnS1tWHaOXdGJP Z1NZzlD0xKpzJRB6I+kPg4QEni39jh69azxYy7mFVyWyJwXKUKsdWu/anTtJfIgBWZ1e9pjL4tRy 38LfGUnKjV3bE2dOE8icpIAPH6gAJ22TMhE8rDEqKm2dTMjUdsEZgXbulbTzW6JpieJYFF9QPIxG M5DGQmV6MCaKFdHk+5uYLU2Swu2QuM8Slp2Sb+s58nquD1vrJI0/QlJz2HaSQg9Cg/gqfIC0/yOE 08O/F2jeGwMKK9fGB11l+Geen0/ixTQP8ihZBsnV+VlwuZyMg+V4lCSLfHq5GF3/whATJSnVzD3N b37EgPHFs64rqqWROzugsg67+RAq+ci0kpUbEdHwzzkDzxQ1hGd4NI3PJlESjV05IHFI19XWpw0m PwMo17dE3Teu62C0WaYXzqRgmPXt/+zSigCz4zcAAAD//wMAUEsDBBQABgAIAAAAIQDk2A9+fAMA AAkJAAAVAAAAcHB0L3NsaWRlcy9zbGlkZTgueG1stFbbbts4EH1fYP+B0EPfHPmWNFFjF7ETbwv0 EsTpBzAUFQvLG0hKsVD03/eQkuLGySJJi9qAJZMzR3PODGd0+n4rBam5daVWs2R0MEwIV0znpbqd Jd+uV4PjhDhPVU6FVnyWNNwl7+d//3VqMidyAm/lMjpLNt6bLE0d23BJ3YE2XGGv0FZSj7/2Ns0t vQOqFOl4ODxKJS1V0vnbl/jroigZP9esklz5FsRyQT0id5vSuB7NvATNWO4AE70fhDQHM7YWebg6 c205D3eq/seatbm0cftLfWlJmUOvhCgqIUuSdhudWfyrYIabdM/9tkei2bawcn5KM3Aj21kC8Zvw Cyea8a0nrF1ku1W2+fqELdtcPGGd9g9ABPcPDaxaRo/pjHs616UXnIzuWbWmFK6fNPvXEaXBM9Bv 6bEvdQ8WOAd4syG+MVDGB6jOrt2MevT2DppGsfx2ofMmEL/BNS7STDi/9o3gURCETTOA4wfyCxoq tLCD1VVC8tL6qBFx0i8Fp6jlTkY//6AlJ7TyGqWIWjmFLB5Z6bC4yi+ppVf3kFwNvq1/ggwUaYaH I+4+SNy2Kv6/lpNey6VWHpVGLgVlfKNFzi0Z/56yZY666MV/jahBPIUzeQY1itKTArGtGRXI08n4 cIj6E2pt2BXPKxa0wlOG+MT09YkJGM/mZV9Ewi0OeQw5qH+upfYl20vFXm73MWIR+Dl5Q6V5R2JW A482qyn5rFXptUWL6Sxeh/5U5aw5q2zpmwdIbTHEinhUjvshPwV6obi9bcgDzGeBOu7ow+SOelRQ 5XiGTh2hdquuMkY0hKEjVtKEDBK5k8Vrom88+i6heY1eSrC90XcE647WHG7OkwCG3qgry7g72Ivy 5vkUQZ7O6uFJfYk0H5W3VZhEv6bOOfc8li1ZN85z6TKyW9IFwfjJQTcwzLW2JAwplIuLK3Wpu1kS 9MB4qMOhLUNEOLF/Uok2t22bifq+RuXfaV+xi/UTDuPmk0NfNHHwoOxnyffF4uRovDxeDBaj6Wow PT95OzhbHR0OVoeT6XS5OD5bTi5+JPAZTTNmeWyvH/uXAiw+GsSyZFY7XfgDpmXaTvTU6DtujYbU GOqj4c9vBhispKZilkzehu/4ZHLYjRKEGztyHza49FObCfuZmq911BIvIzguy7hkkOwgM0x3JkEE TPv/AAAA//8DAFBLAwQUAAYACAAAACEAwpCwgtECAACYBgAAFQAAAHBwdC9zbGlkZXMvc2xpZGU2 LnhtbLRV3W7TMBi9R+IdLF/Tpu26bouaTmtHEdLYKrqJa89xmwjHtmw3a4V4F56FJ+PESTbKNjRA 5CI/9vcdf+f4+Mv4dFtIUgrrcq0S2u/2KBGK6zRX64TeXM87x5Q4z1TKpFYioTvh6Onk9auxiZ1M CbKVi1lCM+9NHEWOZ6JgrquNUJhbaVswj0+7jlLL7oBayGjQ642iguWKNvn2Jfl6tcq5ONd8Uwjl axArJPOo3GW5cS2aeQmascIBJmTvlTQBM76UafV05toKUb2p8p01S7OwYfqyXFiSp9CLEsUKyEKj ZqIJC58KYXiJfklft0gs3q5sMRmzGNzINqEQf1fdkcRisfWE14P8YZRnV0/E8uztE9FRuwAquF+0 YlUzekxn0NK5zr0UpH/Pqg5lSL3Q/LMjSoNnRb+mxy/LFqziXMGbjPidgTK+gmri6smgRxvvoGkQ y2+nOt1VxG/xDIMsls4v/U6KIAjKZjHAcYP8klUOFapzs6Qkza0PGhFX+JkUDF5uZPSTUmQ530hm yRiKeGxIC/N7rLCon7CN1zAxXLaXDhAUBC5t4XitlX1e34NW35lWHu4jC8m4yLRMhSWDf1M7T+GV dkP+v9CNON+/7YnSCvtH+/NJ/N3GcKaIY6UgXBsDAdFsSKGdJ3pFfCZIgXmv8eBZrgTJIbldQW/3 htzBETCoZcqhgQiHSXKrfUakvgOSseg0BE2v+V4zh0WU2xSm8kF3j3NthOAGHFqVLphlH58VALo9 55xgoLbh4PRfOHjVhD6wsXlCv0ynJ6PB7HjamfaH887w/OSoczYfHXbmhwfD4Wx6fDY7ePuVIqc/ jLkVwbPv2x6NwUd9sci51U6vfJfrIqobbGQqCYyGXOix/d7PjRp9jpRMJnRw1Ds8GVVXc7JRbjgM bdng0jZRLu0HZq7KcHLxb8AuzMKQwd+gkgOhDyGVCGi+PwAAAP//AwBQSwMEFAAGAAgAAAAhANpQ bDoZAwAAKAgAABUAAABwcHQvc2xpZGVzL3NsaWRlNS54bWy0VVtu2zAQ/C/QOyz0VyC2bMd2EyF2 EDt1USBNgjwOwFBriyhFsiTt2Ch6l56lJ+uSkpLmBSQu+mFZonZHO8Ph7sHhupSwQuuEVqOk2+4k gIrrXKjFKLm+mrX2EnCeqZxJrXCUbNAlh+P37w5M5mQOlK1cxkZJ4b3J0tTxAkvm2tqgondzbUvm 6dEu0tyyW0ItZdrrdIZpyYRK6nz7mnw9nwuOx5ovS1S+ArEomafKXSGMa9DMa9CMRUcwMftBSWNi xi9lHv6dubKI4U6tPltzac5tfH26OrcgctIrAcVKkiVJ6xd1WHxUFEY36aP0RYPEsvXcluMDlhE3 WI8SEn8TrpTEMlx74NUiv1/lxdkzsbz49Ex02nyAKrj7aGBVMXpKp9fQuRJeInTvWFWhjFJPNP/m QGniGehX9PjpqgELnAO8KcBvDCnjA1QdV72MejTxjjSNYvn1ROebQPyG/uMiy6Tzl34jMQpCZbOM wOlC8ksWHIqqdX2ZQC6sjxqBK/1UIiMv1zL68c1SyOBnYEuvyY7klwOSxtPO1Hio8nNm2cWLsIEm y6gAqr0plG4rJV/Wc7fRc6qVJ7fBuWQcCy1ztND7N3VFTt5oNuD/Cxt3wI9//3ok3Rb7YfH7UtDx g7dB1RVYzJfUjRTfAHsrBKClVhNFC/t/MduqAshxYVlOBG4LVOALtAiMfrwgT9KyjovUR1fCahW6 1Q7kWlu3A6VeBSeW6JmUggMzhjLlDqDn7faHB/VUjou228r3nKntJL5BoGa/oFMVOj9HoigclExt oNDGtWFKyEsXom7JyPOwoTQ0BFH3GhbU2MEGJR6w2YpC+xHE6w9qLdvrE56e7HjAmwFA3fjEUcsw sS8vrRglPyaT/WFvujdpTbr9Wat/vP+xdTQbDlqzwW6/P53sHU13P/1MKKfbz7jF2Hm+NDOTFp/M qVJwq52e+zbXZVoNvNQEkY0WceZ1O38PTpo7sGKSLN3pD3qDYW8wqDstlRubVVM2cWmGGpf2KzNn q3hyaVZ7tNO4ZMiZodFR6H1IEIGG4R8AAAD//wMAUEsDBBQABgAIAAAAIQCe7PFD3gIAAJ4GAAAV AAAAcHB0L3NsaWRlcy9zbGlkZTcueG1svFVRThsxEP2v1DuM/NVKJJuEAGGVBJEAVSUKUQMHMN5J 1sJrW7YTklaVepR+9SA9Sk/SWW8WSoGWqlJ/dr3jmfG855m3/YNVoWCJzkujB6zdbDFALUwm9XzA Li9OGj0GPnCdcWU0DtgaPTsYvnzRt6lXGVC09ikfsDwEmyaJFzkW3DeNRU17M+MKHujTzZPM8RvK Wqik02rtJgWXmm3i3XPizWwmBR4ZsShQhyqJQ8UDVe5zaX2dzT4nm3XoKU2MvlfSkJCJqcrKt7cX DrFc6eUbZ6d24uL22XLiQGbEFwPNC6KFJZuNjVv81ORGi+SX8HmdiaermSuGfZ4SNlgNGJG/Lp8U xFNcBRCVUdxZRX7+iK/Ijx/xTuoDqILbQ0tUFaKHcDo1nAsZFEL7FlXlyin01IhrD9oQzhJ+BU+c LetkJeYyvc0hrC0xE8pUG79qM/JR+3viNJIVViOTrUvgV/SORp4qH6ZhrTASQmXzlJLTg+hXvOxQ 1I3LKYNMunDHURgKUxTohOQK+CIY6kFqkj7xEeg6YhJ6Uj4qpT6XlhUxT9OzXdMzNjpQ88BEcYG5 URk66PwbWTKjq675/G88ce8xQHBcXNNoAk2tq+YJjIaQIxRmifCKz2lYaX0llQzrLSA5gGxNnS+F f918hNdI7nMv69sXuJfij3HgizBWyEmwNrMShoXRMhhXovi7ZLG1whCb8yYELCIDC4dgZjCj4f9A 0rgFUge3KCUSSDS8KU3fP3+9d1DVUBvgqLMJd/z97/r0qQ6MjVjrDonAqaemtVEOFk4O2MfRaH+3 M+6NGqN296TRPdrfaxye7O40Tna2u93xqHc43j7+xCim3U2Fw3ihb2upJuMDeaRrdMabWWjS3CSV zibW3KCzhpCT1LZbP+s1yR0suRqwPdrodTp7sfepbqo2zlRdNZlqKRXKveP2fBnnl/4QAd04mixd 2UZF7lxKDkiCfwAAAP//AwBQSwMEFAAGAAgAAAAhANqq2QIyBQAATRAAABUAAABwcHQvc2xpZGVz L3NsaWRlMy54bWy0V11uGzcQfi/QOxD75ABRZCmyLAuWg9iJiwKOY9QJ+jzijiTCXHJLciWrRYHc oXfowXKSfuRqk8hZp4nivGhXXHI48803f8fPbgstluy8smaS9Z7sZ4KNtLky80n29s15Z5QJH8jk pK3hSbZmnz07+fmn43LsdS5w2vgxTbJFCOW42/VywQX5J7Zkg28z6woK+Ovm3dzRClIL3e3v7w+7 BSmTbc67rzlvZzMl+YWVVcEm1EIcawrQ3C9U6Rtp5ddIKx17iEmnt1Q6gWXyWufx6cs3jjm+meUv rrwur1z6fLm8ckLlwCsThgrAknU3Hzbb0l+DbXjp3jk+byTR+HbmipNjGsM2cTvJAP46/uIQjfk2 CFkvyo+rcvG6Za9cvGzZ3W0ugAYfLo1W1RZ9bk6/MeeNCppF74NV9VbC0Qsrb7wwFnZG82vz5OWy ERZtjuLLhQjrEsiEKGqzr/6Y8Gj2e2CawAq3pzZfR8OneKZFGmsfrsNacwIEatMYwvED+DVFhrLp vL3ORK5cSBgJX4QzzQQub2AMJ78r0IS9F1fOyvg8syY4q8XeMRAKcFAj9n9kswNR4fKWOyREfqO0 FimP7ohgk1+Ro9/uNTfCT2MAA0wbAPFae/h+Pz9t/ByRQBSIK02SF1bn7ET/+7yucnC2IcY9Do84 36H+YHh4MBgk/vf6w9Hh8E4UjPr9o+E+AiTGwsHR/mB4MEysaiQls2vuNUg0VIrXGfu8CnamQg1Z zbH44Wsp5v+cZEhc0OCLZCusUcE6JDpxx5ntzG0Rm8geTuxMaBu8iE+wFp5RRWkdcrFkpOQKaUCr GxbSOmdj+hZ7jv+oQHaPgyus+yC8JE1TpVVYi/fv/hFhoTwM8MGpaRU431nJtiBwtgow/LHwdoar o/bPdr5gg8J2SNRkT4xvYvZubLQA2qardGQAlC/JmOgsckxiL9aRR2KlwgLYGiYnUPmEVE5WGn8K G4sNQKTwvXbhPoiDZzhdp4wgAZXmvLPgNiv3jBVzSxoeKeJFWgvD8HrOgV2hDIigpECVBlusQ9FP 9VBMOayYjdiA1PlRTni1AcC6G9B7j/JcRYBJ67UonV2qROtEJAH/5OukagNbOuUfidzCkcaGNtO8 itGyqAoyW+H4cEQCL+C0EuUIsbp1xzcwdEP2jwEcFrby4F4K/5yX6Hx8Hb+VB1N2vaeNI1OSN1P0 do9FUemgSjByZ/FfqJDTqfM7y22plYkKPfFDdL24uHxQVXcVtqFFdHzMSSlJ+GpqONTJ3ApaWvXA SZxNVUw5VrDH4hJRRXpFa4+kh1JDHjSJuSSoAkGnvK37b7yJFSKA8+1UgS72nhamJU3D2ocLS2NN Bykkr2RK2d/pAS5hag6LP0bojFBeY3Ug9BXGFsijU17QUiGZRofRHAPOVqndlMdthB7OYmn5Fvkc 09vuAbwhXF0AeU5yjVKRks8nlhOKRYE+RyCp0pzjNLZ7FLZENk3tEjSTlpxn9D5L1rjqBuhjYsPK nlygaLP2IqYuHWsYCjjaGRQB1FTH79/9i7w/RyKjHEUuknNu7YNQ8/M+O/WdzZiIme3CY6Io0/RW OTXJ/jo9PRr2z0anndPe4LwzeHF02Hl+PjzonB88HQzOTkfPz56+/DvDmd5gLFHlIl9/bSZrLH42 zYJqaPjQYj2BH7r1WNwt7YpdaVWajHv7n47XmE7FkvQkG4z6o8FRDz1sDLWkY/NMWmOpmXyldq+o fL1MTSsGerQLZ2mpBLD16U+2RAwwMf8HAAD//wMAUEsDBBQABgAIAAAAIQDct4MggQQAABsPAAAV AAAAcHB0L3NsaWRlcy9zbGlkZTIueG1s1FddbuM2EH4v0DsM9JQAVmwnzp8QJ4i9ybZAdmPEWfSZ pmiLDUWyJOXYWxTYO/QCe5Y9Sk/SISVlE8eLREn60BdLJjmjme+bGc4cnSxyAXNmLFeyH3W3OhEw SVXK5awffbo+jw8isI7IlAglWT9aMhudHP/805FOrEgBpaVNSD/KnNNJu21pxnJit5RmEvemyuTE 4V8za6eG3KLWXLS3O529dk64jCp58xx5NZ1yyt4pWuRMulKJYYI4tNxmXNtam36ONm2YRTVB+oFJ x+gZHYvUP62+Noz5Nzl/b/RYj0zY/jgfGeAp4hWBJDnCErWrjepY+CvxGL60V8RntSaSLKYmPz4i CfoGi36E4C/9LwqRhC0c0HKRfl+l2eWaszQ7W3O6XX8ALbj7qPeq9OixO9u1O9fcCQbdO6/KowRF LxS9sSAV+undL92jH+e1Mu+zV68zcEuNyDivqjpXbgY86vMWMQ1gucVApUvv+ASfYZEkwrqxWwoW AEGzSYLK8QfhF8RHKJPxp3EEKTcuYAQ2d0PBCMZyBaM7/o1jmDBrYWQU9c+hks4oAUcIkEN+Kq1M piNiyNUPlXtnSYJmoAe1ufha4vljVHdqVP13MeZgJAhlmRIpM7D9Oox5ihFS09AEXg+jxOw8LZya cgdTtG1MiUDG9vd3OxiJQo41vWJpQX2G9SPMWlwuMSgp8jrehKFVJp4gOUSDO6YVjUIpbWHDsD8K ZNoCgZlQEyJAacdz/jnkOKgpGFU43MeiBL9z5xB9IjGOkBO6hH++/A0uKyxQlWs8l8JkiapWYuQJ y4AZrGWBDx9ao+FZM/nKs29fIW7BVKhb2FBYnDdBGzXnvkZjBW01NWpNTqSFosR62g1Y1InZnikN G83Mrd1dl3XdXz43VLbGTCQobeptRcE6m3pvYdNmMEqqEE4voKPi+Ja7zN+sjlPIC+G4JriQEZOC FcoBEQIp8qm39RCBsgSFOvSiclinTTN2Kqt9roHG2guDexlnmZjGGSMC4YA4ZFHKrTN84hMprpFq 9sV1BLbganSxuaLn+XX75aDZQjODGajM8iEbT1JQAeeT2TYUXYfABgbeTBGRwF29W4HjiRJV2ZMy rH85l9zmUGhwCosfewP7JoTeTLBTxBbhv+ap8uTb12YArEM1J5LMmO8rG0JQ2XD/8rFMYxfhGGKq lVCz8mohPnKBS99LUwYxwk0cpArvI4nZ/noXJoaRmy24PD9pYb6hSkxKFq7uk9b/iAnsQIxrmig1 C5PCWLdsQSHZQqPzLH2Lu1LJOMWhpvFNVFm1Us1beJdzZbirGpPXM/9ydh/3saGdrYcenEAuLDbI OswiheH96M/B4HBve3gwiAfd3nnce3e4H5+e7+3G57s7vd5wcHA63Dn7K0KZbi+hGJL+Avu1nhNx 8dFslnNqlFVTt4WNV7sc8tpa3TKjFQ9zXrdzf1jEWQvmRPSjg92dve1Ob++wGi7Q2tCZ11ajK/Uc R4X5QPTlPJRGHE+x9A3DksYLC2nyR78f8Rjg/PcvAAAA//8DAFBLAwQUAAYACAAAACEAA1zFyagD AAB+CgAAFQAAAHBwdC9zbGlkZXMvc2xpZGU0LnhtbMRW224bNxB9L9B/IPYpASKtJCu+CJYCS4mK ArkYlvMBNJfaJbJLskPq1qL/km/Jl/WQq3WytVJHboHagLTicobnnBnOzOWrbVWytSSnjB4n/W4v YVILkymdj5OPt/POecKc5zrjpdFynOykS15Nfv7p0o5cmTFYazfi46Tw3o7S1IlCVtx1jZUa75aG Ku7xk/I0I76B16pMB73eaVpxpZO9Pf2IvVkulZCvjVhVUvvaCcmSeyB3hbKu8WZ/xJsl6eAmWrcg TcBMLMosfDt7S1KGJ73+hezCXlN8/X59TUxl0CthmleQJUn3L/bb4k+NbXhI/2aeN574aLukanLJ R+DGtuME4u/CJ4z4SG49E/Wi+Loqig8H9orizYHdaXMAENwfGljVjB7SGTR0bpUvJevfs6q3cpi+ NeKTY9qAZ6Bf0xPv142zwDm4twXzOwtlfHC131e/jHo0+x00jWL57dRku0D8Dt9xkY9K5xd+V8oo CGDzEZzjA/KXPGSo1J2Pi4RlinzUiLnKz0rJkct7Gf1kUXHy7BJqeASjcfHPfuKBfiKUV9KlSi+J O08r4VfIm7YveAQykGoY4LGW+PtCnzRCz4z2SEN2XXIhC1Nmktjg38muMiRNE5ljFA+KaFzYq5U3 S+VZqRdW3MgMrOvi0MNfjGQTo2Dxn4To2XHRYZJQMiLHEFQyPHuB8Ejpj/Ozj/Jz5omH6sIEwkGm ZM9I/rZSIdRKC5LcSWaW7bA3efT9VGyDvNs8CRvjjlWG5D1EpZkv5LFYDlyLoFoLUp3IMZsfJ3fA oXv6PVvRHdfMcvqEDvGN+oTsQ+vRYhf0J7PyCAl2GnSsjiWzVqFvBY1aTB6H347Nzfw4833esEzm xDNA2ihfMMHJMaDxxga0IUpoMc6Qe/7lc/hvgzxG7v2BXz4fh/NQNcxxTXQbyaNy7Y//HROA67J3 RitvCGmpXKiHuCMs55SB6wukqcpzFLEN95IQzG4L8f/EGWV89zTKpcoLH25gpBz4sJumNCDdc4RY cLTKSrpCugNcH/aF2B6auQJN/q1DW7Kx3a9IjZM/ptOL08HsfNqZ9ofzzvD1xVnnan76sjN/eTIc zqbnV7OTN38msOkPR6E4her8azOKYfHB+FMpQcaZpe8KU6X1HJVas5FkjYqjVL/37TyGcYateTlO Li4GZyenZ+d11Y8YY6drUINKMyqJkt5x+2Ed+zMmQER/FpcsREP+hK1ftwQNMGL9BQAA//8DAFBL AwQUAAYACAAAACEA1dGS8b4AAAA3AQAALAAAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVM YXlvdXQyLnhtbC5yZWxzhI/BCsIwEETvgv8Q9m7SehCRpl5E8OBF9AOWZNsG2yRko+jfm2MFwePs MG92mv1rGsWTErvgNdSyAkHeBOt8r+F2Pa62IDijtzgGTxrexLBvl4vmQiPmEuLBRRaF4lnDkHPc KcVmoAlZhki+OF1IE+YiU68imjv2pNZVtVFpzoD2iylOVkM62RrE9R1L83926Dpn6BDMYyKff1Qo Hp2lM3KmVLCYesoapJzfeS5qWd4H1Tbqa277AQAA//8DAFBLAwQUAAYACAAAACEA1dGS8b4AAAA3 AQAALAAAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQzLnhtbC5yZWxzhI/BCsIw EETvgv8Q9m7SehCRpl5E8OBF9AOWZNsG2yRko+jfm2MFwePsMG92mv1rGsWTErvgNdSyAkHeBOt8 r+F2Pa62IDijtzgGTxrexLBvl4vmQiPmEuLBRRaF4lnDkHPcKcVmoAlZhki+OF1IE+YiU68imjv2 pNZVtVFpzoD2iylOVkM62RrE9R1L83926Dpn6BDMYyKff1QoHp2lM3KmVLCYesoapJzfeS5qWd4H 1Tbqa277AQAA//8DAFBLAwQUAAYACAAAACEA1dGS8b4AAAA3AQAALAAAAHBwdC9zbGlkZUxheW91 dHMvX3JlbHMvc2xpZGVMYXlvdXQ0LnhtbC5yZWxzhI/BCsIwEETvgv8Q9m7SehCRpl5E8OBF9AOW ZNsG2yRko+jfm2MFwePsMG92mv1rGsWTErvgNdSyAkHeBOt8r+F2Pa62IDijtzgGTxrexLBvl4vm QiPmEuLBRRaF4lnDkHPcKcVmoAlZhki+OF1IE+YiU68imjv2pNZVtVFpzoD2iylOVkM62RrE9R1L 83926Dpn6BDMYyKff1QoHp2lM3KmVLCYesoapJzfeS5qWd4H1Tbqa277AQAA//8DAFBLAwQUAAYA CAAAACEA1dGS8b4AAAA3AQAALAAAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ1 LnhtbC5yZWxzhI/BCsIwEETvgv8Q9m7SehCRpl5E8OBF9AOWZNsG2yRko+jfm2MFwePsMG92mv1r GsWTErvgNdSyAkHeBOt8r+F2Pa62IDijtzgGTxrexLBvl4vmQiPmEuLBRRaF4lnDkHPcKcVmoAlZ hki+OF1IE+YiU68imjv2pNZVtVFpzoD2iylOVkM62RrE9R1L83926Dpn6BDMYyKff1QoHp2lM3Km VLCYesoapJzfeS5qWd4H1Tbqa277AQAA//8DAFBLAwQUAAYACAAAACEA1dGS8b4AAAA3AQAALAAA AHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ2LnhtbC5yZWxzhI/BCsIwEETvgv8Q 9m7SehCRpl5E8OBF9AOWZNsG2yRko+jfm2MFwePsMG92mv1rGsWTErvgNdSyAkHeBOt8r+F2Pa62 IDijtzgGTxrexLBvl4vmQiPmEuLBRRaF4lnDkHPcKcVmoAlZhki+OF1IE+YiU68imjv2pNZVtVFp zoD2iylOVkM62RrE9R1L83926Dpn6BDMYyKff1QoHp2lM3KmVLCYesoapJzfeS5qWd4H1Tbqa277 AQAA//8DAFBLAwQUAAYACAAAACEA1dGS8b4AAAA3AQAALQAAAHBwdC9zbGlkZUxheW91dHMvX3Jl bHMvc2xpZGVMYXlvdXQxMC54bWwucmVsc4SPwQrCMBBE74L/EPZu0noQkaZeRPDgRfQDlmTbBtsk ZKPo35tjBcHj7DBvdpr9axrFkxK74DXUsgJB3gTrfK/hdj2utiA4o7c4Bk8a3sSwb5eL5kIj5hLi wUUWheJZw5Bz3CnFZqAJWYZIvjhdSBPmIlOvIpo79qTWVbVRac6A9ospTlZDOtkaxPUdS/N/dug6 Z+gQzGMin39UKB6dpTNyplSwmHrKGqSc33kualneB9U26mtu+wEAAP//AwBQSwMEFAAGAAgAAAAh ANXRkvG+AAAANwEAACwAAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0OC54bWwu cmVsc4SPwQrCMBBE74L/EPZu0noQkaZeRPDgRfQDlmTbBtskZKPo35tjBcHj7DBvdpr9axrFkxK7 4DXUsgJB3gTrfK/hdj2utiA4o7c4Bk8a3sSwb5eL5kIj5hLiwUUWheJZw5Bz3CnFZqAJWYZIvjhd SBPmIlOvIpo79qTWVbVRac6A9ospTlZDOtkaxPUdS/N/dug6Z+gQzGMin39UKB6dpTNyplSwmHrK GqSc33kualneB9U26mtu+wEAAP//AwBQSwMEFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAABwcHQv c2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0OS54bWwucmVsc4SPwQrCMBBE74L/EPZu0noQ kaZeRPDgRfQDlmTbBtskZKPo35tjBcHj7DBvdpr9axrFkxK74DXUsgJB3gTrfK/hdj2utiA4o7c4 Bk8a3sSwb5eL5kIj5hLiwUUWheJZw5Bz3CnFZqAJWYZIvjhdSBPmIlOvIpo79qTWVbVRac6A9osp TlZDOtkaxPUdS/N/dug6Z+gQzGMin39UKB6dpTNyplSwmHrKGqSc33kualneB9U26mtu+wEAAP// AwBQSwMEFAAGAAgAAAAhACXzlI8HCAAA8i8AACEAAABwcHQvc2xpZGVNYXN0ZXJzL3NsaWRlTWFz dGVyMS54bWzsWl1u40YSfg+wdyC4jwuNxH9SGDmwJDMZwJkYsXOAFtmyuKZIptly7AQB5g65wd5i d99ylDlJqqqbFGVLMzIsA7ZhwJDJ7mKxur76l95/e7PMjWsu6qwsRqb1bmAavEjKNCsuR+bPF3Ev NI1asiJleVnwkXnLa/Pbo398874a1nn6A6slFwbwKOohG5kLKathv18nC75k9buy4gXszUuxZBJu xWU/FexX4L3M+/Zg4PeXLCtM/bzY5/lyPs8SPi2T1ZIXUjERPGcS5K8XWVU33Kp9uFWC18CGnt4Q 6QjOl5znKf6fXarPn/jcyNIb0NJgYJlH79mQzsknuTCuWT4yZ5eW2T9638dHgFhf4cN1dSE4x6vi +jtRnVdnAm+Sj9dnAngCS9Mo2BL0iwxoQ5PRbQFkivHG45cNJza8mYslSgTqMUBCQPEWP+EhNuQ3 0kjUYrJeTRY/bqFNFidbqPvNC+Bo7UvxVOpE949jN8e5yGTOjbOcJXxR5inYCqmITqgeAy1Wp2Vy VRtFCWdGVaijgnIaxnh+fFW1MORtBVqSyFbTqU2QrGjpa9JvI3SrFdcLwOhINXbg+k64qZ/QtiMf 91FLluU6A7hBWdaMKlHL73i5NPBiZAqeSDIEdn1aS0XakBD6SpBqKG/GZXqLYMzgP2AOHgfPL0rx m2nkH4p6ZEaW68K7Jd2QpKYhujuzjR2ZT0owOXiCFQnwGZmJFCRLAd52vJLlPNMSqVfiy/Nansvb nJNZAHhsCGqFDxAoZ+jwvOj9fA4Ov5STnDMICNqE5NEkz5IrQ5YGTzNpaL8nGCA8AEvUkiRdEUte pGdMsJ/ucNYqIt00OgHklCHtNienNSe05a412QjQY60JFWRq136MUVlgPWhgpN7G6zasyvVsL/Kd 529VaBYPMiTwOCO/Jouk4z/SsFB7ZFf1hmGBkZHZqo/mlRQxHmDL5zwpi9TI+TXP92BPNvYA9heL TOzPnYzhAdzjciXkYm/hXWWNe8MRZ/Ot3CGNHNSl3calp0xuJghSyGNdOpUQxX6DCMvyuXZtgpHS BCaTB+YL3/Hg745r25bjtAnD8T3L9p6/Z2/kC3LVJitQhrjOLXRlll9C9M9NXEv5HOM4qtPC8IZr dZlnaZzlOd1gubcug+SNqo5kVkhVGAXeOpW2NRMliw4f8G31JtqAWIKCqGudtvBd5PnzPKWq6fcw iOOTgRP1/GBy0nOnx3Ev8pxpLzqx3GlsRUE8mf4BSZWKhhQsTWZLHmeXK8F/XKnU/fXkB2KQnuSR 07dtKDktZx01QBQU67DO4TXOEZcl1tfdjEcO/Vj3mEOtQID+smIC3qBdRCUmrKT2dRHHst2mptru I2HkvWofacqu5+clh7VJv7HJc/B8bnxcLWd3LJOC32MtE5pKYL3NOMnwHxS/fc9zvmycrz2Aq47g +ZlmG8CDeGpPXW/SC8cnEMB9N+4dn0R2Lzx2w3jsRKHvDtoAXqPlFWAdGHEfErc/f/rvPz9/+t8B ojY1K00vD0UqtH3Yf2C5uhLZyPx9PI58exKOe2MLzuJOo6B3HPteL/Yc152Mw+OJc/IHHKCy3GEi OE0ePqR6AgKL96YWyywRZV3O5bukXPbV+KNflb9yUZWQYDEdDbpjFBghqKTrDCzfgg/qckFukJHK nkZqWGomHEkufmCVAfMLyPkSZhGQwkdmegVXs0sb16ChlzdwlV7BFUsSGJoAhb5oVmBfrbQ0TrMC HZzaggPqi2bFa1Yg66ktv1mBmLPIs+IKlIL/TGNe5t+rheYKCy4aRZ2y23IlP6QaEYgjzQqVCrbl Bm7o+G4EbfUQRy7iQ6pnEbtood5b0+pOcyct6Krlq0vYnbSgn5ZW5/OdtKC5llZH2J20UFS3tP49 zWzowQNtt7TBV2gBh5aWzGlD45t8gw5t9BW+MFts+VpUXH+B8QZwzZCoowoNvLyhEUeNZkHzCbrF iKFLSl3bYt42IDJesNk5VLY0fkG8pZqqcHZajAVYHuCK08VC3wLJAkYlMMI8WxUJzHD0JLBKxjjx w2lWcpboupeOBHUtrOnd2eojjFGpnOxEZZj8AN8rLnAEu2+JDUyQdbcQJ0Gp2p3DwG1k/mv5714u EQSoUNmdDc7URlLf2Uhq3NhVjm9qFUadMDy5p+IlE6cj03HtCA+WFRC2QVW9ZqHpLp5a/6BKNY65 g0FcQmeCTYFS07HIWG4aVSaTRcyWWQ7zPwd8KVkwUXMQXPd9s9UEVmh5ZH7+9B+lvw6Oqtp4ChyL XTgWvR04Fr0v4kjuYGOrp7AKACuMdy1WduhB2wYhWXeCLxurP+9hZYdP5XMHxAoB0qHLWWPVzKY7 YNkhNVmvA6z7jmU/WYA8IFiIkAbL7YClh8KvFawtnoVB90my2QHBQoQ0WN4aLHvgBWRq6zD4ijzr r//fj4IvASsESGPld7DyLJeC3qvEalt5geXMs3csREiDFXTAigKLEu4bWF8am+9V0x8wCiJCGqxw DZYq0zeKwVcUBV+sZyFCGqyoA1YY+jTkfPOs5+RZiBCN2zr9cTUs5YKLtluGzvFMQap7yO6PMNoW XJM00wvVrj1JY9bpZFWwfpGdbPMrn8P3Qi9NP9u7x2bS9aafHQ2bE+APeZ5i8vHSDGh7k2SFdki1 3JsF7ehMqFp6syBIWTu6gcBVo9I3C9pRgUNFR3OINwXtqHp9L3gL0jTEbyvNbnEJX+6uvwjDL62b 3+of/Q0AAP//AwBQSwMEFAAGAAgAAAAhANXRkvG+AAAANwEAAC0AAABwcHQvc2xpZGVMYXlvdXRz L19yZWxzL3NsaWRlTGF5b3V0MTEueG1sLnJlbHOEj8EKwjAQRO+C/xD2btJ6EJGmXkTw4EX0A5Zk 2wbbJGSj6N+bYwXB4+wwb3aa/WsaxZMSu+A11LICQd4E63yv4XY9rrYgOKO3OAZPGt7EsG+Xi+ZC I+YS4sFFFoXiWcOQc9wpxWagCVmGSL44XUgT5iJTryKaO/ak1lW1UWnOgPaLKU5WQzrZGsT1HUvz f3boOmfoEMxjIp9/VCgenaUzcqZUsJh6yhqknN95LmpZ3gfVNuprbvsBAAD//wMAUEsDBBQABgAI AAAAIQDV0ZLxvgAAADcBAAAsAAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDcu eG1sLnJlbHOEj8EKwjAQRO+C/xD2btJ6EJGmXkTw4EX0A5Zk2wbbJGSj6N+bYwXB4+wwb3aa/Wsa xZMSu+A11LICQd4E63yv4XY9rrYgOKO3OAZPGt7EsG+Xi+ZCI+YS4sFFFoXiWcOQc9wpxWagCVmG SL44XUgT5iJTryKaO/ak1lW1UWnOgPaLKU5WQzrZGsT1HUvzf3boOmfoEMxjIp9/VCgenaUzcqZU sJh6yhqknN95LmpZ3gfVNuprbvsBAAD//wMAUEsDBBQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAA cHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDEueG1sLnJlbHOEj8EKwjAQRO+C/xD2 btJ6EJGmXkTw4EX0A5Zk2wbbJGSj6N+bYwXB4+wwb3aa/WsaxZMSu+A11LICQd4E63yv4XY9rrYg OKO3OAZPGt7EsG+Xi+ZCI+YS4sFFFoXiWcOQc9wpxWagCVmGSL44XUgT5iJTryKaO/ak1lW1UWnO gPaLKU5WQzrZGsT1HUvzf3boOmfoEMxjIp9/VCgenaUzcqZUsJh6yhqknN95LmpZ3gfVNuprbvsB AAD//wMAUEsDBBQABgAIAAAAIQCslGfmpAQAACARAAAhAAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlk ZUxheW91dDEueG1szFjbbuM2EH0v0H8g1GdF9yviLHxTUSCbBHX2AxiJtoWlLqVor91igf2t9nP2 SzpDibaTTbFpYRR+sSlqODwzZ4ac0fW7XcXJlomubOqR4VzZBmF13hRlvRoZHx4zMzZIJ2ldUN7U bGTsWWe8u/nxh+s27XhxS/fNRhLQUXcpHRlrKdvUsrp8zSraXTUtq+HdshEVlfAoVlYh6CfQXXHL te3QqmhZG8N68Zb1zXJZ5mzW5JuK1bJXIhinEvB367LttLb2LdpawTpQo1Y/hyT3LVgrS8mZQZSY 2MKEY9yA5fmCF6SmFUw8ogRZ8LJg6lXXPgrGUKje/izaRfsg1Iq77YMgZYEahpWGNbwYxNRjDWIw sF4sX2lNNN0tRXVzTVNwBNmNDOBrj7+wiKZsJ0neT+bH2Xx9/4psvp6/Im3pDQDBYVOguu0t+tYc V5vTO8I5WNWLUlh62+QfO1I3YCea35uX3221MrQZ1bdr0ns9l0JpG0T798olekmn3KqxHpwRxkFs 9x5xHc/23eC5X6Iocn0UQO84fmTbvcSp1b3qNpW7SVPs0atP8K9YoSnv5ELuOVPeBp/QFJDDD3DL KWYMq80PC8iYSk45o5BRAzPyZsrL/CORDWFFKcl72kkmiFTR06HKawAhgflBJauLByrory80o/No CjuDOzRCGPb8/DNLnmZpsXnq93TPQVS3eeqJgsiGsNPcvp0wx4uccGDMi+MQzoTnjIVAl6JUMRYF Lkr3TugTQRnfx4/2x6uMIU18yx0IHFJRcasyp6wLyH41pHwFbEHkQRaDgs0dnHaK5YItgQSc7BrI 8qzkXD3gEcemXJAt5XBQ7PBkAAbLWvYzUWAfoKrzEIUVeyd6gEutH4YDPtQDQ/cI1Q8i9Ay5PLwI csDrHfEmjq/S7PLwIsgBr3/EewjDywOMKAfAwQng2I1VWlweYEQ5AA6PgF03hsy9yBBGlAPg6ARw 5HsXmnOIcgAcHwEj2gtNOkQ5AE5OAIdBpM7+y4thRKmOan3fI/ozXPdwX/5fN76vb/wZlYw8cJqz dcMLqDm8c9z8hYQi53cosSlfwr2kbv/+YsbKVXkPBwvlSKxPVAF1rFlevaOPVdUS6msslv+Ioyyb 215ihtF0bvqzcWYmgTczk7njzzInibLp7LMx1I0FmCrLimXlaiPY/UYayNv3i7MeHJZfnuW60FM4 3rEaAyio5bz1WKDZyZoG68BTfvxz8LOEQkYR9NuGCthBc/SdEg0YeDNH5/VIqD2iWilyt6meXvhF 1fLQe+nG4T+1FtCzgupXXaMqYtVlnC98o2zmzvxgasaTOYRv6GfmeJ64Zjz242ziJTHUt4fw7bCJ rAHdv43ar1/+/Onrl7/OELOqmtYNLHSTtx20JK3qKzeihHycTJLQncYTc+KALf4sicxxFgZmFni+ P53E46k3/wwGtI6f5oKpxvqXYmjwYfKbprwqc9F0zVJe5U1l9d291TafmGgbqKUxGe3TrwQjwxjq 6ySxHT/29KkDaFVXpFGDKdimI/yci/e0vd/CmU5T+C4B+QC1OEy18CUCm4lnIugD/WXj5m8AAAD/ /wMAUEsDBBQABgAIAAAAIQBpol8hHgEAAMcHAAAsAAAAcHB0L3NsaWRlTWFzdGVycy9fcmVscy9z bGlkZU1hc3RlcjEueG1sLnJlbHPE1d1qwyAUB/D7wd5Bzv1ikrbpBzW9GYPCrkb3ABJPPliionYs bz8pDBIojkLAm4CK5/z4K+Z4+hl68o3GdkoyyJIUCMpKiU42DD4vby87INZxKXivJDIY0cKpfH46 fmDPnd9k205b4qtIy6B1Th8otVWLA7eJ0ij9Sq3MwJ0fmoZqXn3xBmmepgU10xpQzmqSs2BgzsL3 v4zad/6/tqrrrsJXVV0HlO5OC2r7TuA7H9XV+bLcNOgYJMl03k4Hu8Tzgd6XrWLKViHZNqZsG5Jl +ZI0568Zzg7yNkNv3yzkWJTx6K3KQ7JsyYAelQUzK2LKimBmcUMLpraJmdommJp/6+M9rVkasq1j 0tYh2T6mbP8no7Pfb/kLAAD//wMAUEsDBBQABgAIAAAAIQCkvLrJTQMAANUIAAAhAAAAcHB0L3Ns aWRlTGF5b3V0cy9zbGlkZUxheW91dDYueG1srFbbbts4EH1fYP+B4D4rsi6+SIhd2JJVLJAmwTr9 AJaiY6EUyZK0a++iQH9r93P6JTukpCSbZoEU9YstDYeHc87McHT55thydGDaNFLMcXQxwogJKutG 3M/x+7sqmGFkLBE14VKwOT4xg98sfv3lUuWG11fkJPcWAYYwOZnjnbUqD0NDd6wl5kIqJmBtK3VL LLzq+7DW5DNgtzyMR6NJ2JJG4H6/fs1+ud02lJWS7lsmbAeiGScW4je7RpkBTb0GTWlmAMbv/m9I 9qSArW0sZzeCnzDyrvoAxggvgD3d8BoJ0oLhznkh7+ZWjLrTjLkncXir1Ubdar/h+nCrUVM7gH4j DvuF3s2/CnCDh/DZ9vsBieTHrW4XlyQHLdBxjiFlJ/cLm0jOjhbRzkgfrXR384Iv3a1f8A6HAyCC h0Mdq47R93TigU6nQ/TAqnMlsPVK0o8GCQk8Hf2OHr0+DGCOs4NXO/RE+N6vW/R6DP4GNPVi2eNK 1idH/AP8eyPJubEbe+LMCwJhkxzA4Qfk58TVNRPB+w3UdWsLzgjUfS+eXRS8oR+RlYjVjUXviLFM I18F0AUAeQnqWEhOD8lEfUs0+eMZsuNHcjgZgh4ihMdOwv8XMhmELIll6JYTynaS1xBBfA5NawuU /4S2IHyLoRChSiJP3EvrEvBTGm+hH1x1/zWbVtV6lGTBZFqsg7RcVkE2TsogW0dpWUXZtCrKL7hP dA1UbdOyqrnfa3azt/h1qeoKwCUjCeMY7oEoecwNhOJQzpuddMhOJaWriqf5Sc6Rn63VXYI+7YmG E4YcDf1yhj44ryLjQZENb2qGrvfth2e6pOfQBeYMQL8oje+LM5fvtCrjMh0XwWy1hvKdpFWwXGdx MFums2qVZLNJOnooX+OYC4juR6v229e/f/v29Z8z1Ky/WIaJA9f/lYELSvlBsNcN9ONqlU3iYrYK VhFwSctsGiyryTioxkmaFqvZskjWX4CAitKcauaH4e91P5TB+N0gbRuqpZFbe0FlG3YTOVTyM9NK Nn4oR6Onk32OMToQPsdJFo8m2Wg69v0CgUO4/tYZwgaTm6sufsr1O6JuDnAtkRw+JqAhCm9S8PnQ D5BHFyfC8Dmy+BcAAP//AwBQSwMEFAAGAAgAAAAhAOX8egjkBQAAUhwAACEAAABwcHQvc2xpZGVM YXlvdXRzL3NsaWRlTGF5b3V0NS54bWzsWdtu20YQfS/QfyDYZ0XinRQsB9aFRQHHNmrlA9bkymJD cllyJdstAuS32s/Jl3RmyJWoWywrfghQv0jUang417PD2bP3j1mqLXlZJSIf6Ma7nq7xPBJxkt8P 9I/TsOPrWiVZHrNU5HygP/FKf3/+809nRb9K40v2JBZSA4y86rOBPpey6He7VTTnGaveiYLn8N9M lBmT8LO878YlewDsLO2avZ7bzViS68395TH3i9ksifhYRIuM57IGKXnKJOhfzZOiUmjFMWhFySuA obs3VZJPBVgrH8T0cfogru/+0DUSLpewbOjnYH90m8ZazjJYGImsYGVSiZz+qYppyTnK5Mtfy+K2 uCnphqvlTaklMQI0N+rd5o9GjH7mIAYX3a3b7xUS6z/Oyuz8jPXBG9rjQIegPeEn3MT6/FFqUb0Y rVej+fUe2Wg+2SPdVQ8ADVYPhXgXtUW75pjKnGkiU64ZK6tqUQa3XoroU6XlAuxE82vzoqulAkOb Eb6Ya43rEaqRq/8kfyj5CnxKzpKPQxE/oeF38E2LrJ9W8lY+pRACuF6mBgWA9WM++712bWsZrG2L g5GsD6rABwQrZVgHPO98vIU6yOQo5QzqpHG1PB+lSfRJk0LjcSK1D6ySvNQkeaFCBc4AXUIoG0ie xzesZKDEBjJ6g/XhyWCisgcua4cfdru1cjvG/CZlEZ+LNAYNzNeIAPpTh3SFXFIBOxAI9NZWStqO BwVOeWk4lmMYFqq0zk67Z/cMH8gFc9S1As8lncENNRCZX6eE8oiKsMbyaC6ALe5qyHb0mmBrGSsv qS6SPIYCx0t8+t3iCliMFKlzQav+GuimjZreKTNbuUGXJmRPA6isOgq1t4uKUKgHqGmtUQPDJg2O QTX8XVSEalDtNapheYaLwkfBkuSmCxCrgXVasL7pkw6nwiJWA+uuYU3TBxW+Q1vEamC9FqxnW5SH p2qLWA2sv4ZFzONDtse3iNXABi1Y1/G+K2SIRVzSrgliNHwIZN2KuujppzMcEg4RXLXBcKewmK1Y bCRyCbW6QWTEGrDVqo3ihVsJVvecpbOGxmqKwW2V3IQX7f0EA3KYxkzDs33P+QaNWYFjQHGgxDE8 RjTUDtTOTrVmpxqyJQCXikzaTIYltJJVAiCrKKIlS0yyklUCIKvqvi2LWbmSVQIgq4r5oKwSAFlV oQdllQDIqrI7KKsEQFbV0kFZJQCydYGoToD8SyS5su3HqCBqBuBDFS3tvy9oS255JPJYS/mSp3sK dBue6uIF8NN5Uh6P3uz8RzNOKBalnB+tvF1X5PHwyWwvOvQmr9qdOYrXptvdGWl8OqnV/XHdnSHB /blgJbSdDceRt6lVPprjXNvpmaAudGKHejXDA+Z769UG+luvBv3yW6820K3/Y6/mKk7b16tRa3Q6 re1SGfHkyVR2qF9bU9lbv4Y+3+x/3vq1AzOdb77xbDdUb/0ajtDqt8Ft3/yo/ZqnuG3MJN94CXWx wzyd2Op+LZYwQNx8HTXqd6qD76P01O3pFyyuB5b0g97vZzCLxsny374XhpOeFXRcbzTp2OOLsBM4 1rgTTAx7HBqBF47Gn/VmyBqDqTLJeJjcL0p+vZA6oj8/FoAXE3q0PLe6pglTeMNav2aAKojyut00 TArrUXsoBM5Y29NO7zXiM5PQQe/uQcYzo8+XxOh1PRIoj9ymScy1q0V2t+UXmkR8b97CKQ9A73XN M+OUl7hmlb5eODbHtjPq+MMJpK9rh52LSWB2/AvbD4dW4Lt2b5W+FVqeg3YvzdqvX/755euXf18h Z2lOrU57YI+4rGDcX9AhzKJMoB6Hw8A1R/6wMzTAFnsceJ2L0HU6oWPZ9mjoX4ysyWcwoDDsflRy Oor6LW6OxGBx5xgrS6JSVGIm30Ui69bnYd1CPPCyEAkdiRm99rnaQNe1JYPJn+M5jm2bPvVpoDdo SycOSmtYwiMtorq0/MCK6yWQOOvDSR5U3IiWCji7g7ii6FoEfaDOAs//AwAA//8DAFBLAwQUAAYA CAAAACEASYbMqoUEAACDEgAAIQAAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQ0LnhtbOxY 227jNhB9L9B/INRnRdbVshB7EV9UFMgmwTr7AYxEx+pSokrSjr3FAvtb7efsl3RIiY7jOGu7yWNe bIk6HM6cuXDI8w+rkqIl4aJgVd9yzzoWIlXG8qK671ufb1M7tpCQuMoxZRXpW2sirA+DX385rxNB 80u8ZguJQEYlEty35lLWieOIbE5KLM5YTSr4NmO8xBJe+b2Tc/wAskvqeJ1O5JS4qKx2Pj9mPpvN ioyMWbYoSSUbIZxQLEF/MS9qYaTVx0irOREgRs9+qpJc12CtfGDXd39aSOP4EkZcawCmZ1OaowqX MHD7wNCIVRLE6E+ivuWEKFC1/J3X0/qG6xlXyxuOilxJaGdaTvuhhenXCmDw4OxMvzeScLKa8XJw jhNgAq36FjhsrX5hEk7ISqKsGcweR7P59R5sNp/sQTtmAdBgsyj4um4sem6OZ8y5LSQlyN1Y1UAx TL1k2ReBKgZ2KvMb87KrpRGmbFbi6zlqaVeiWlzzUfNh8AI41WTJ1ZDla2X4HfzrQZxQIadyTYkm BNTGCQiHH6CfYhXVpLI/TyGqSzmiBEPUt+TJwYgW2RckGSJ5IdFHLCThSGq7hBJ5DuxIcE4rklT5 Deb4045kZR9OYGVQ2mgIjw2FLxPpGyLbaEI3FGdkzmgOSnivo1V8hWzAdGZBBEJ4GB+8wK2iayfK grAL+apDzY06HfWs+TUBF3T8GMYtpMIuCL2wF/nagUaSJqBxs+Fkr9fU2nRJXZ02OMnJTNGr9Pfi ZlHgdgsAj94ebLCNNQDA+nuwnW2sAQA2eI51n+hgAIAND2ENALDRIawBALZ7CGsAgI0PYQ0AsL1D 2AaguG7TSTlGZxPMRCBhkzavzC4VQTq5xJPsajJod0kduCck9JRkrMoRJUtCjxCvs+wE8bfzgh8v XSfECdJTtuByfrTyQZORR7sjLWZ7pcMu8qZ1LfhZXdOcwH5qNoMTt4uduqb9p7cKVWn0w/aesa+u RUH8XthgR3gvbMl7Yds0Qu+F7YiGLTSFbYwledKt6VL8/6ta0wTnEnrUnb5NO+jlAndKUzyDE4w6 jvwdd9N00vF7dtQdTexgfJHavdAf272JG4xTt9dNR+NvVtuZ52CqLEqSFvcLTq4X6swDW9pOB/y8 t4bc0v2iHPiO58GxzfUf92NQRUl5220nMt5JGVNt/HY3Haqt8rX+mUneOOivBeawgumtDzTXp/jo bRnpGkamtMgJulqUdzu8RG/BC1wLgOi91BzYn0+hZhO+3XTsjYNwZMfDCYRvFKT2xaTn2fFFEKdD vxdHQWcTvkJZXoF2p0btj+///Pbj+79vELO6sJgrAmh+LwWcKGt9cl/wAvJxOOxF3ige2kMXbAnG va59kUahnYZ+EIyG8cXIn3wDA2o3SDJO9N3FH3l7hwKDz+49yiLjTLCZPMtY6TQXKE7NHgivWaHv UNzO9kVM37LQEkODH3aDbhgHYazCAvQGbc2/1hqG1EWITiXKP+L6egltF07g6gfyYaSHarjsaWZn jxDFgbk8GvwHAAD//wMAUEsDBBQABgAIAAAAIQA4BPKI9wQAAHURAAAhAAAAcHB0L3NsaWRlTGF5 b3V0cy9zbGlkZUxheW91dDMueG1szFjbbuM2EH0v0H8Q1GfHulkXI84ivqhdIJsEdfYDGImOhaUu pWiv3WKB/a32c/ZLeoaSbCebYt0kCPJiS+Rw5syZGXKo03ebXBhrLuusLEamfWKZBi+SMs2Ku5H5 8SbuhaZRK1akTJQFH5lbXpvvzn7+6bQa1iK9YNtypQzoKOohG5lLpaphv18nS56z+qSseIG5RSlz pvAq7/qpZJ+hOxd9x7L8fs6ywmzXy2PWl4tFlvBpmaxyXqhGieSCKeCvl1lVd9qqY7RVktdQo1ff h6S2FbytefIbZ6lpaEG5xpBtnsH3ZC5So2A5BuY8IeMGCXKpZ+vqRnJOcsX6V1nNq2upF12ur6WR paSkXWz224lWTL8WEMND/8Hyu04TG24WMj87ZUOwYWxGJoK2pV8sYkO+UUbSDCb70WR59Yhsspw9 It3vDADBzijiXTUefe+O07lzkynBDXvnVSPKsPSiTD7VRlHCT3K/cS+5XHfKyGdSXy2NhnpFqlq5 ZlLz0cnXmtMO6I6JwHFc29V0eJ7lR9YDUoIgcDwMGkSN7fqOFQy0kU4TjDSqq6HajMt0S5Te4h+R Y0WyLJGlilawoajVXG0F4ozntbCByGDiDmUkkAVsmPLF7xiq/xyZMAmbtzrwCQMDTIjWbLsS4b6v EWSzISjBD5QIRvXIi97HOeoxVxPBGQy13qmziciST4YqDZ5myvjAasWloSlE9QIjaVfahlbJi/Sa SUbwDjVTVNgQlsFC570mhCLz3+EH300p3FDuXQuW8GUpUAyGQ06iWro4PykTiH0TZYOc7hLnSQnh RJYfIDl08LoquZ8QA8uyw6CNTFNkxyTEbaPzsYTImbzQBZoVKXYaeqSY3q4usZ1qJAdpgi2xma5L kaVxJgTJ6t2UT4Q01kwg+za0BSGcWaGakQCwdSYgeDthHcoDPZhrLOmJXdbp1HUodRuk3iAACtB9 BFw7fEW4hJHcBnJ3DzeyUebHwvVfES5hbOF6e7i2G9iE4jh6yTOdAK+QDQSyxTs4wBs6IQX57eEl kC1ef4/XcULQ+xbxEsgWb3CAN/Dc48vtNfOBQLZ4wz1eAnt8vb0mXgLZ4o0O8PqD4G3WG4FsduKD LkKf+YQem9zucNduPb0HoINOtwD1vR7gKee8153zU6b4vXNeH6rPPedThdYGzdKSiUV33jfHGjXC mi56mGvmmjZNdxddp9L1afpU7c5i/aJ5XaBjp977rzCI45nlRj0/mMx63vQ87kUDd9qLZrY3je0o iCfTL2bbhqZwVWU5j7O7leRXK2VSlv04HACpTaszt+84uKfY7p5/QCEtL9uFDbroxGVJ3d9hH+ZR g/Lc+CyUbAL0x4pJWOhi9IOmTFs+MkYvy4jfMTJHN8WNy1V++4AX3fs/lxfcg6H6UWp0/4sO8iXT N4inztQbTHrheIb09b24dz6LnF547oXx2I1C37N26VuT5wXQ/d+s/fb171++ff3nBXJWN9DdfRi7 0UWNi0ilr6krmaEex+PIdybhuDe24Ys3jYLeeewPevHA9bzJODyfuLMvcKCyvWEiub6sv0/bjwYY /O6in2eJLOtyoU6SMu83Xwz6VfmZy6pE00zFaB1+eRiZZtNIO2HkWjgyvG7bAVx9Gepgwxe6+eta EvIDq67WenvGxw4UBFp0DFX4vIGcJ9G9CJHQfS45+xcAAP//AwBQSwMEFAAGAAgAAAAhAHAWmgfA AwAAsgsAACEAAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0Mi54bWysVttu2zgQfS+w/0Bo nxVZF9uSELuwJWtRIE2CdfoBDEVF2lKilqRdu0WB/lb3c/olO6SktLksYK/9IlvUzOHMmeHhXL7d 1QxtqZAVb2aWezGyEG0Iz6vmYWZ9uMvs0EJS4SbHjDd0Zu2ptN7Of3tz2caS5Vd4zzcKAUYjYzyz SqXa2HEkKWmN5QVvaQPfCi5qrOBVPDi5wJ8Au2aONxpNnBpXjdX7i0P8eVFUhKacbGraqA5EUIYV xC/LqpUDWnsIWiuoBBjj/TQktW8hW37/l4WMkdjCq2vNIW+yZjlqcA0Ld5ViFAE7KOGNAiRjINs7 Qak2bbZ/iHbd3grjd729FajKNU7vbzn9h97MvDZgBn+cZ+4PAxKOd4Wo55c4BjLQbmZBzfb6CU44 pjuFSLdIfq6S8uYVW1KuXrF2hg0ggsdNodxtl9HLdLwhnY4O9zGrzhSD6xUnHyVqOOSp0+/SI9fb AUznrOHbEnXMK81sb9d9NHwM9hI4NWSp3ZLne534PfyaRRwzqdZqz6ghBMLGMYDDA+hnWDc2bewP a2jsWiWMYmj8njw1T1hFPiLFEc0rhd5jqahAJhg4BgB5CewoKE4PSZv8Fgv85zNknR+OYWcIeogQ /nYU/jeR/kBk303olmFCS85yCMI7jdYqh6YYmD8Do1AAxLbskboTGdZtawiWTxjuWDRUwmPY0qRx RFHXlHA4o4xuKTsA3jB9BPxdWYnD0X1dxyPQM74Rqjw4+OBY+Kp4FR2U5Ky9HQy9nWJFnzS2IQRk dVCD/6UXuYLj/Bk0H7PCApHVzW4OtZENLS4n6UcBkq+V+0s4zbLVyI/syTRZ2UG6yOxo7Kd2tHKD NHOjaZakX61exHJIVVU1zaqHjaA3G309QOWficVLGerETQuN73geXHKu/7NtIRSNct7qjIfqZJxr xftVeExHnVqfQomuQH9vsIAdhhqdUZHOy8hkYGTNqpyi6019/4yX8WmC3N1zMEQB9KvUGBk6c/tO s9RLg3Fih8sVtO8kyOzFKvLscBGE2dKPwkkwemxfqTNvILpju/bHt++///j2zxl61lyawzQFd8SV hMu3NUPORlRwHpfLaOIl4dJeupBLkEZTe5FNxnY29oMgWYaLxF99hQRaN4iJoGbSe5f3EycsvpgS 64oILnmhLgivnW7cdFr+iYqWV2bidEe/jq0zy0JbDPegGwah70Wua84LBA7hGtUZwoYlPTrq+AkT 73F7swVZwjFMynAgErPUwmysh4cnJpqEYdae/wsAAP//AwBQSwMEFAAGAAgAAAAhAJVbP8ViBQAA 3hIAACEAAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0OC54bWzMWN1y4jYUvu9M30HjXjsg /9sT2Ak/7nQmm2QK+wDCFsFd23JlQaCdndnXah9nn6RHskWAsAskuegNGPHp0/k/x7r+sC5ytKK8 zljZM/BV10C0TFialY8949M0NgMD1YKUKclZSXvGhtbGh/7PP11XUZ2nt2TDlgIBR1lHpGcshKii TqdOFrQg9RWraAn/zRkviICf/LGTcvIE3EXesbpdr1OQrDTa/fyc/Ww+zxI6YsmyoKVoSDjNiQD5 60VW1ZqtOoet4rQGGrV7XySxqUBbNvtjujaQgvEVLGCjD5onkzxFJSlgYchKAQzoKRMLNCSVlENh 6mrKKZXocvUrrybVA1db71YPHGWppGopjE77RwtTP0uAwUPnYPujZiLRes6L/jWJwCJo3TPAcRv5 CZtIRNcCJc1i8ryaLO6PYJPF+Ai6ow8ACbaHgs+rRqOX6lhanWkmcorwVqsGSmDrLUs+16hkoKdU v1EvuVtpMqmzpK8WqDG/kFQtrvlT2UPja2VTLejWEo7rQ2wpc1i+3XUPbGJ3u4GNbQNJy2DsWS1i V+OGuYrEesDSjbToDL7BcaRMFgwCddbYOa/FRGxycDOJ8lWOQSBE8kfIpByCgEQpnf8OS/VfPQNE AplmWvEtHnwMzzs8YGESgR3gA7bmRCYiLc1PE0jEQgxzSoC+1Un0h3mWfEaCIZpmAn0ktaAcKbtB 2oJkkl2oMxQlLdMHwokUapdZuoJEcDLYV+sMj423v+9zMOJ+FjzkJKELlqcghPW2CMhSiF8dJOc7 33Z9VzpUJsMx77sYY0A03ncD18YQCo36TUIptZs41JbQ3lepteuq1uUHnrZl9DWUOwB4tNp43Y2K YBerAYC1j2CdXawGANY5gpXRtpVBAwDrnsJqAGC9U1gNAKx/CqsBgA1OYTUAsOEpbAM4lkOwEwHD NlnemFOypqqUqvdyqskblTzwoY9UgXtBGk9owsoU5XRF8zPoVW5dQD9dZPx8dpUQF7DHbMmh+50r vCMD8xL6bH6UHdrcu1YzR1ezqXT1bilTBoG2r1vVq5qZ7CBQwqEVLEg+N2AGgAKnHKmamiw56mGi Il4WX7n0o+6GHdvFTZ4/t/y99uZ4Ie56by5wqCD8Vo0YWZnCtCMfpWiz5R0MhcqbOzUN79Up2RMl FjJRlreWSvfos/j26ulBjWz5QuzIU9FZfHu18aCOtnzY9rF3LmH4g1qr+QIrkKX+LAH3+A7qcctn WQGI9xq+g5qt+XxHta3L5Tuo6y2fJDvbIXv6HtR+zee5/uv88f/oD5DZeppQA4Ycc78/V7m6Eo2I oHuVSNXOt1aiVLyoQ7iZFuTbxtFCBDn+rMHReUhVATW7zuHlSL7g/B34cTzu2qHp+cOx6YxuYjN0 7ZEZjrEzinHox8PRF6Od9VNQVWQFjbPHJaf3S6EqzOkRGGqKOlr07Y5lwQshtp8bKIgia8/79glP eydmTE7bu53Clb3trf6ZC9446M8l4XBC2yvwiWn4Eh+9r0V8bZFJnqUU3S2L2YFdvPewC1w4APVR 05zoo5eYZhu+fjyyRo47NIPBGMLXc2LzZhxaZnDjBPHADgPP6W7Dt5aalyCdjLdLovbb139++fb1 33eIWVVY9KUDjDC3Nbz4VeouYMkzyMfBIPSsYTAwBxh0cUahb97EnmvGru04w0FwM7THX0CBCjtR wqm6FfktbW9nYPHFjUqRJZzVbC6uElZ0mquZTsWeKK9Ypm5ncHf3iqdnGGhFYCK3PLeLXSvsqnwB wUFcNf5osWFJXrKoXMr5R1Ldr9QUAbdKkBBDtVTBPRI4VkKfIdII+l6q/x8AAAD//wMAUEsDBBQA BgAIAAAAIQCH9Z3HGAMAAIMHAAAhAAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDcueG1s rFVtbptAEP1fqXdA298E82EbkO3IgKkqpYlVJwfYwGKjwO52d+3arSLlWu1xcpIOCyRpkkqp6j82 DDOz896bnZmc7uvK2BEhS0anyD4ZIIPQjOUlXU/R1WVq+siQCtMcV4ySKToQiU5n799NeCir/Awf 2FYZkIPKEE/RRikeWpbMNqTG8oRxQuFbwUSNFbyKtZUL/A1y15XlDAYjq8YlRV28eEs8K4oyIwnL tjWhqk0iSIUV1C83JZd9Nv6WbFwQCWl09J8lqQMHtNcVpjfI0G5iBwYbzQB5tqpyg+IaDJH2aIyS XwpCmie6+yj4ii+F9j3fLYVR5k1sF4Os7kPnpl8puMGD9Sx83WfC4b4Q9WyCQ6DA2E8RKHVofiEI h2SvjKw1Zo/WbHPxim+2WbzibfUHQAUPhzaoWkQv4Tg9nAQrYiwrnJENq3IiDPsBYBuFIcsZy26k QRlAbphokWbnuz5vA785iW+MlvpcQeN9BxFxVSDgD8DZGqxmqHHWD328BLo1j2ofsfzQcHIN/9qI w0qqlTpURHMFiHBYgIKNKD/8cZouBm5gjsbxwvSSeWoGQzcxg4XtJakdjNM4uUV9UQBVlTVJy/VW kIutgnbAoQCBoQ3gwhBqXq2g7lrFFcFwoTp52uJwqGau5TjQtbY7AcIVgNClaAlpvsQCf3mWrGEK h1AzwO2xwWOry9/VcXt1UsYUaPJUH+cY+hRKtAJ93WIBJ/Qa9dq2gv6XRuSojHg9I6uqzIlxvq2v n/HiHoMXmIqQ+lVqNO+akeO17zhNnMQbxqYfLaB9R15qzheBY/pzz08jN/BH3uChfWWDnEJ1/9q1 93c/P9zf/TpCz+rW7QclTK0zCZeA6/m1FSXcxygKRk7sR2ZkAxYvCcbmPB0NzXToel4c+fPYXdwC AG57YSaIHt2f8m6FgPHF2K/LTDDJCnWSsdpq94fF2TciOCv1CrEHT/fQFCFjh6spcseDwB2Nxm7Q jSsoV1/DvmzA0myCpv6sEp8xv9jBWMIhrD64ELE2cVh23bB7dGlI6Jfn7DcAAAD//wMAUEsDBBQA BgAIAAAAIQD+I2hr1gMAAOgLAAAiAAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDEwLnht bKxWUY/aOBB+P+n+g5V7zoZAgCRaqCAhp5O2u6uD3rvrmMWqE+dsk0JPlfq37n5Of8mNHbzd3VIJ urwE4ow/z3wz83mu3+wqjloqFRP1xAuveh6iNRElqx8m3rtV4cceUhrXJeaiphNvT5X3ZvrrL9dN qnh5g/diqxFg1CrFE2+jdZMGgSIbWmF1JRpaw7e1kBXW8CofglLij4Bd8aDf642CCrPaO+yXp+wX 6zUjNBdkW9FadyCScqzBf7VhjXJozSlojaQKYOzu5y7pfQPRAjF6tfOQtZMtrITeFEInS16iGlew sGKaUwQEob/AmBHM0YrutDVTzUpSajbU7e+yWTb30u6+be8lYqVBO6B4weHDwcy+1mAGf4IX2x8c Ek53a1lNr3EKrKDdxIPk7c0TNuEUnECkWyTfVsnm7ogt2SyOWAfuAPDg8VDIe9NF9H04fRdOR0r4 GFVnimHrjSAfFKoFxGnC78Ijt60DMzEb+GaDuhRow+/Brvto+XD2Cji1ZOndXJR7E/h7+LWLOOVK L/WeU0sIuI1TAIcH0M+xqXBa+++WUOGVzjjF0AEH8vQ044x8QFogWjKN3mKlqUTWGegHgLwGdjQk 5wBJ6/IeS/znC2QTH07hZHDaeQh/Owp/TOTAEfmsptA9x4RuBC/Blf4lyDVUeUhIBk3QVbsHdQlF 4zJzDuNGRgCFYuO08e4Y/5AuxFv+SPQr82GK3KZDPctHx7klHh7uSBvUGSWwpERAX3PaUn4CvM3I GfCrDZOnow86Rk/mqxBbqTcnOx+dC8/WR9FBdy7aCZHrhBxr+qwBLCEgxU47fkpdSg3N/wmuCszX rvStBFiRMVL0KrVZwzVhdP6feFwUi94g8UfjbOFH+azwk+Eg95NFGOVFmIyLLP/sHSSvhFA1q2jB HraS3m3NZXKKaHVSaGRpEPT7cDeGg29lC64YlMtmZ+iyUwhh9PGpQNmKem1+1lp2Cfp7iyWc4HL0 M/r0A0W6LCMjx8iSs5Ki2231/gUvw0sIN8xeAH2UGitDFy7fcZH382iY+fF8AeU7igp/tkj6fjyL 4mI+SOJR1HssX2Uir8G7c6v265d/f/v65b8L1Ky9Yt3sBXfEjYKrurEj0VYy6Mf5PBn1s3juz0OI JcqTsT8rRkO/GA6iKJvHs2yw+AwBNGGUEkntgPhHeRhUYfG74bJiRAol1vqKiCroptSgER+pbASz g2rYezrtTjwPtRjuwVESxuNRLx6bsgC/wVv3a72GJTNtGvcJl29xc9eCKuEU5mvoh8wuNTBRd7uf mBgO3IQ+/R8AAP//AwBQSwMEFAAGAAgAAAAhAPuvLPAeBQAATRIAACEAAABwcHQvc2xpZGVMYXlv dXRzL3NsaWRlTGF5b3V0OS54bWysWNtu4zYQfS/QfyDUZ8XW/YLYi/iiokA2CersBzASHQurWyna G2+xwP5W+zn7JZ2hRNtKnMbx6iWx6eHhXM8MefnhKc/IhvE6LYuRZlwMNcKKuEzS4nGkfbqPdF8j taBFQrOyYCNty2rtw/jXXy6rsM6Sa7ot14IARlGHdKSthKjCwaCOVyyn9UVZsQJ+W5Y8pwK+8sdB wukXwM6zgTkcuoOcpoXW7uen7C+XyzRmszJe56wQDQhnGRWgf71Kq1qhVaegVZzVACN3d1US2wqs rdL4/kkjUoxvYMHQxmB5vMgSUtAcFu7SWKw5I19SsSJTWqEeUqau7jljKF1sfufVorrjcuvN5o6T NEGoFkIbtD+0YvJrAWLwYfBs+6NCouHTkufjSxqCR8jTSIPAbfEvbKIhexIkbhbj/Wq8uj0iG6/m R6QH6gDQYHcoxLxqLHppjqnMuU9Fxoixs6oRpbD1uow/16QowU40vzEvvtkoMLQZ4asVadwvEKqV a36U/lDytfSpUnTnCcMLTNOHvAXLbR+ybPjMK47tuzYsEvSN47qe5ctDFBIc0kBXoXialMkWXfoA /yFytIhXJWTqA+6gYVaLhdhmEGf4vMkM0IjQ7BFKKYMsoGHCln/CUv11pEG+w5EPyvKdPAS5iwMu piE4Av7A1oxiJbJC/7SASszFNGMU4FuTxHiapfFnIkrCklSQj7QWjBPpOKhb0AzRhTxDQrIiuaOc olKHyBgLGsLJYLuyWboB4/F60C0VdFUGdxmN2arMElDCRBdBsagAn5UCUIEalAvkskqY8xLBNUzP c5qgqero5IFtGJgspybCq9HPKb+W1ZgWCVALfsRQPqxvgD/lroOcsCAp2hPb7EFZ+GhiIjVQtuOh FDkFz9xb0IK0eNYeLzBsmfwn4aFkkxuAhyAtnr3HMyzPwBI7TUEsgh0gorSAzgGgD9V7HiCitIDu HhDYABQ8S0NEaQG9A0DPlpE7w2REaQH9PSCinR6Ujg8RpQUMDgBdxzszKIhynJP65Q5bccc91uMh cViYIT9LHMjXQJhAvCuaLVsOkZQke4i0EZvrQpqrGF+1gKPNxLGgVTS9Yt9iOyTiD6G1NIcopP9p JpINjnWQd3GI0alR7EBtOpzJIUaHkxCkxTuTQ4xOuvbAIUHPFNLB64FBOng9EEgHrwf+6OD1QB8d vNfZAxKJQBPZjS4yrc6fcJA05IBTdyacc6YYRzHRjArWYSK7DyZKxAseMpomiPxzlIgk/6k5TM2e HbqQX+SkuIS7CN4n/va9KJoPrUB3velct2dXkR441kwP5oY9i4zAi6azb1o7WidgqkhzFqWPcH25 XQsNq/ztcEAU5dFibA1ME+5fhrX3P6iCKP32CVdFJypLnG0PO4Uc6H62UywFbwL015pyOEHNm28M nO+JUb8e8ZRHFlmaMHKzzh+e+cXtI2/hfg/QR13zRh99j2t26etFM3NmO1Pdn8whfV070q/mgan7 V7YfTawA72y79K3R8gK0e2/W/vj+z28/vv/bQ87Kxq7u+MBG1zVcsyp59V7zFOpxMglcc+pP9IkB ttizwNOvItfRI8ey7enEv5pa829gQGXYYcyZfIT4I2kfQ2DxxQNGnsa8rMuluIjLfNC8hAyq8gvj VZnKxxBjePiiMtI0sqHAuJYZDC3DcQJZL6A4qCuvekptWMI3DTl1ZfwjrW43kp7hEQcKYiqXKni2 gcCi6F4EnaCegcb/AQAA//8DAFBLAwQUAAYACAAAACEARfArzSMEAADJDAAAIgAAAHBwdC9zbGlk ZUxheW91dHMvc2xpZGVMYXlvdXQxMS54bWy0V9tu4zYQfS/QfyDUZ0XW/YLYC99UFMgmQe3tO1ei Y2IpUaVor73FAvtb7efsl3RIiU7iuKjdpC+yJQ0PZ86ZGY6u3+0qhrZEtJTXQ8u9GliI1AUvaf0w tD4sczuxUCtxXWLGazK09qS13o1+/OG6yVpW3uA930gEGHWb4aG1lrLJHKct1qTC7RVvSA3vVlxU WMKteHBKgT8DdsUcbzCInArT2urXi3PW89WKFmTGi01FatmBCMKwBP/bNW1ag9acg9YI0gKMXv3c JblvIFogRi6pZGRcl8udhbS92MIb1xoBBcWClajGFTz4DUxpgRnS9ggYQ0uyk9qsbZaCELWg3v4s mkVzL/Tq2+29QLRUaD2K5fQvejN9W4MZ/HGOlj8YJJztVqIaXeMM2EG7oQUi7tUVFuEMnEBF97B4 fFqs707YFuv5CWvHbAAeHDYF/ZsuopfheCacI1LcQ3jdGgwYN7z41KKaQ8CKhy7O4nZrUFXwap9m jTpNpNLDQlxQUK6TqF/VmWqazOpWU238PxAURV4aDDqavDiI/OQ5V94gjPV7xViYhG7ohXoTgwSb dNBNJncTXu4V0x/hFwRVSTO0CFbBd7CslQu5Z0TrAazhDEKCCxgzrAqN1PaHBRRaJaeMYCjEXjs5 mjJafEKSI1JSid7jVhKBNAVQlgB5DeJIyI0ektTlPRb41yNkxSrOYGfw2/irQ1DM/rOO/ksdVTbd M1yQNWcluOKpCKEQjGD/SVJF3JGiUBaQsyYfzlc2CGNoLDr/TwkbDdw0Ue//L2Eh3xDbsoOCrxRa 0a11bp8J3YmpFYWL2VKzdUFuLUjBoU0xsiXsDHgt9QXwyzUV56P7XamczVfON0Kuz3Y+uBSerk6i Qz990xILTInNsCTPKksT8trKKiV0lS9wFGK2svqa0r1Fd0nVWfWfp+1S17NpEqap6c71so2t4PhT 59cfSZzn84Gf2lE8ndvBbJzbaejP7HTuBrPcTeN8Ovtq9R28hFAlrUhOHzaC3G3UIXlON4RE137I ke94Hpz9rv+YtuCKQnlbdUKjTs65arxPO5/OqNfqs5KiE+j3DRawg9HoXxrfJRq9LSORYWTBaEnQ 7ab6eMSLPihfywvMlgB9khrdht44feN85s2CcGonkzmkbxTk9nieenYyDpJ84qdJFAwO6duqyGvw 7tKs/f7tz5++f/vrDXJWn91mpoQz4qaFGaDRo95GUKjHySSNvGkysScuxBLM0tge51Fo56EfBNNJ Mp76868QQOMGWSGIHoB/KftBHB6+GJ4rWgje8pW8KnjldFO40/DPRDSc6kHcHTyd5oeWhbYYzkEf zuMojv3EtB1wV3cd4zbEosZoPUUw8R43d1toSziDDwgoiKl+1MAnA+S8Mn00USSYT5DR3wAAAP// AwBQSwMEFAAGAAgAAAAhALl/7nOWBgAAsBsAABQAAABwcHQvdGhlbWUvdGhlbWUxLnhtbOxZT2/b NhS/D9h3IHRvYyd2Ggd1itixm61NG8Ruhx5piZZYU6JA0kl9G9rjgAHDumGXAbvtMGwr0AK7dJ8m W4etA/oV9khKshjLSNIG27DFh0Qif3z/3+Mjdf3Go5ihQyIk5Unbq1+teYgkPg9oEra9e8P+lQ0P SYWTADOekLY3I9K7sfX+e9fxpopITBCsT+QmbnuRUunmyor0YRjLqzwlCcyNuYixglcRrgQCHwHd mK2s1mrrKzGmiYcSHAPZu+Mx9QkaapLeVk68x+A1UVIP+EwMNGnirDDYYFLXCDmTXSbQIWZtD/gE /GhIHikPMSwVTLS9mvl5K1vXV/BmtoipJWtL6/rml63LFgSTVcNThKOCab3faF3bKegbAFOLuF6v 1+3VC3oGgH0fNLWylGk2+hv1Tk6zBLKPi7S7tWat4eJL9NcWZG51Op1mK5PFEjUg+9hYwG/U1hvb qw7egCy+uYBvdLa73XUHb0AWv76A719rrTdcvAFFjCaTBbR2aL+fUS8gY852K+EbAN+oZfA5CqKh iC7NYswTtSzWYvyQiz4ANJBhRROkZikZYx+iuIsZHQmqGeBNgkszdsiXC0OaF5K+oKlqex+mGDJi Tu/Ny+/fvHyO3rx8dvz4xfHjn46fPDl+/KOl5SzcxUlYXvj628/+/Ppj9Mfzb14//aIaL8v4X3/4 5JefP68GQgbNJXr15bPfXjx79dWnv3/3tAK+LfCoDB/SmEh0hxyhAx6DbsYwruRkJM63YhhhWl6x nYQSJ1hzqaDfU5GDvjPDDFfgOsS14H0BFaQKeHP60BF4EImpylzuaHYrih3gHuesw0WlFW5pXiUz D6dJWM1cTMu4A4wPq3h3ceL4tzdNoXTSKpLdiDhi7jOcKByShCik5/iEkAp7PaDUsese9QWXfKzQ A4o6mFaaZEhHTjTNF+3SGPwyqxIQ/O3YZu8+6nBWpfUOOXSRkBWYVQg/JMwx4008VTiuIjnEMSsb /DZWUZWQg5nwy7ieVODpkDCOegGRsmrNXQH6lpx+C6pHtdv32Cx2kULRSRXN25jzMnKHT7oRjtMq 7IAmURn7gZxAiGK0z1UVfI+7GaLfwQ84Weru+5Q47j69GtyjoSPSPED0zFRU+PIm4U78DmZsjIkp NVDXnXId0+Sydp+5dm8LWpk8uycq9jLcyTrd5SKg//4yvYOnyT6BzFjcqy6r9GWV9v7zVXpZPl98 bZ6XY6jUuneyTbdpweOlHfiYMjZQM0ZuS9OES9iEgj4M6nXm9EmKE1kawaPOZGDg4EKBzRokuPqI qmgQ4RQa+LqniYQyIx1KlHIJB0czXElb4+EQoOyxs6kPJLZySKz2eGCH1/Rwfu4oyBipQnO4zRmt aQJnZbZ2LSMKur0Ns7oW6szc6kY0UxQdboXK2sTmgA4mL1SDwcKa0N0g6InAyutw/tes4eCDGQm0 3a2PcrcYL1yki2SEA5L5SOu96KO6cVIeKwuKaD1sMOhD5ClWK3FrabLvwO0sTiqzayxhl3vvXbyU R/DcS0DtZDqypJycLEFHba/VXG16yMdp2xvDmRke4xS8LnVDiVkIF0++EjbsT01mk+Vzb7Zyxdwk qMM1iLX7gsJOHUiFVDtYRjY0zFQWAizRnKz8q00w60UpUFGNzibF2gYEwz8mBdjRdS0Zj4mvys4u jWjb2deslPKpImIQBUdoxKbiAIP7daiCPgGVcPVhKoJ+gXs6bW0z5RbnLOnKt2MGZ8cxSyOclVud onkmW7gpSIUM5q0kHuhWKbtR7vyqmJS/IFXKYfw/U0XvJ3ANsRZoD/hwTSww0pnS9rhQEYcqlEbU 7wtoHEztgGiBu16YhqCCy2rzX5BD/d/mnKVh0hpOk+qAhkhQ2I9UJAjZh7Jkou8UYvVs77IkWUbI RFRJXJlasUfkkLChroHrem/3UAShbqpJVgYM7mT8ue9ZBo1C3eSU882pZMXea3Pg7+58bDKDUm4d Ng1Nbv9CxKI9mO+qdr1Znu+9ZUX0xLzNauRZAcxKW0ErS/u3FOGcW62tWAsarzZz4cCLixrDYNEQ pXCZhPQf2P+o8Jn98qE31CE/gNqK4EOGJgZhA1F9xTYeSBdIOziCxskO2mDSpKxps9ZJWy3frC+4 0y34njC2luws/j6nsYvmzGXn5OJFGjuzsGNrO7bU1ODZkykKQ+P8IGMcYz6Zlb9q8dFDcPQOfD+Y MiVNMME3K4Ghhx6YPIDktxzN0q2/AAAA//8DAFBLAwQKAAAAAAAAACEA5JRimAAYAAAAGAAAFwAA AGRvY1Byb3BzL3RodW1ibmFpbC5qcGVn/9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/ 2wBDAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQH/wAARCADAAQADASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQF BgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS 0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4 eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi 4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl 8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImK kpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP0 9fb3+Pn6/9oADAMBAAIRAxEAPwD+/iiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKK/Pv8AYU/brH7Yll8YbTxR8MbX4KeNfhV4uuRb+Ev+FhQfEFfFXwb1bxB4z8L/ AA6+M8Gqr4T8FvpGn+NPEPw0+Jvhy78N3elXE/h3xH8P/EViNZ1qwWw1e+z9rTVWVCU4wqRweIx7 5/3cPquExGBw1eSqz5aTqwq5jhpLDKbxNSh9ZxVOjPDYLG1sPlOtSp1KNGdSEauIlKNGk5L2lRxV 5OMF7zhFuEJVLckalWjSlJVK9GM/0Eor87P2O/8AgoHoX7UPh79qnx74t8G6B8D/AIX/ALOfxJl0 vRPiN4h+J1nqvhvx98CtS+E3gz43+Cf2g9dv9X8KeCNO+GWgeKfhn430rxbcaJqWpeIrPw9obpqF 94tnjeZLX6l+Hf7TH7OHxf8Ah9L8W/hN+0D8Efih8KoNdj8LTfE34d/FbwJ42+H0Piaa/wBN0uHw 5L4z8Na9qfhyPXZdT1nSNOj0h9SGoSX+q6bZrbm4vrWOV88PZzquSjTp4ajjK0pPk9hhq6i6VbEK Vnh4yclB+3VNwq3ozUasZQXXicPXwlSFPFUqlCdWrKhRVWLh7etGjHEunQbtGvL6tOniY+yc+bD1 KdeN6U4zft1FfMmr/tsfsaeH/hHpfx/179rf9mTRPgPrnia78FaJ8bNX+PXwr034R6x4ysLnV7K+ 8JaX8SL3xXD4N1DxNZ3nh/X7S70G01mbVbe50PV4JrRJdNvUg8v8fftyfCP4R/Gq60z4v/Gb4A/C v9nKT9nfwB8XNF+M3xF+InhnwP4a1TxD4++IPiXwxolna/ETxP4t03wLfaHr2iaRZX/hy3tIzfap cTTXVpqV5aSRW8WNXF0KNbA0Kk1GWY4ueBw83b2X1mOTZjn0KVWq2o054nLssxNTCxk+bETdGFJS 9rFk1aVSjGu6sJ05YelGtOjOLjXlS/tfB5FVqU6Mkpzhhcyx1HD4uUVy4aSqqq4ypyifddFee/EP xT4u0X4far4l+FXge3+Lni+W003/AIQzwmnjHRfBmh6/e63fWNjY6lrfjjUodTttB8FaTFfjxH4r 13RtD8ZeJbbwnp2q3PgrwL4/8Vf2J4O135T+G37UHx+8Wab+0J4D8TfszeErH9qP4Dap8PrAfC34 fftBx+NPg/400z4uaRZap4D8ZWHx18b/AAj+EHiXRvCWlA+Iv+FpR6h8C5fHHhiz8FeIp/h/4G+L d7e+DNM8W9EmoScJtU5qTgoVGqc5zTinTpxnyurUipOcqdJTnGlSxFaUVSw2InSUYqbwKVbCx/tH FSweE9pi8LSU60aKxDdR1K0FhqDot1I4rEujhZxp1+WtL2Fb2f3dRXxp8B/2ovE/irU/jX4E/aV8 B/Dv9n34o/AjxD8OdN8WQ+FfjXL8V/hBrWh/GDSLO/8AhprvhH4p+L/hj8B9eubvW9Xk1LwZqHhz xP8AC7wnqtl4u0o2ekf8JHpOsaBrWqes+Df2nv2aviN4Q+I3xB+Hv7Q3wN8d+Afg9f8AiLSvi343 8G/FrwD4o8IfC3U/CGmDWvFum/EbxLomv32i+CL/AML6ORq3iKz8TXumXGiaYRf6lHbWp82s/rGH 5pRWIw8pU6DxFSMK9KbpUYyjCpUqqM26So1Jxo4hVOWWHxF8PXVOvGVNRQvilF4ZSr+0xM8FT9nG U3UxcKlWlLDU0k3Ot7SjViqcU5SdObimk2e5UV8IfAv9tPwf+0Z+1F49+HXwV+IfwX+Mn7P2ifsy fB74x+Efit8IvFul/EOz17xn40+Mv7RXww8aaOnjrwn4q1zwVqmi6Avwd0i1h0/TLGLVdK8Qv4ig 1bVLoNa6fpf0p8Z/FHxh8LeFLab4F/Cbw98YPiFqutWmk2GieNvijF8HPh5oVk1pf6hqHibx94+t PBfxR8W6VoMEOnf2PYw+AvhJ8T/E194q1rw5aXPhzS/Ckvibxr4UuE1Uo0sQlJU60sVCF4yUm8Jm GKy2q3G11F4nB1nCXwypclW6jLTqq4OrRxk8DOVFV6eHwGJk3XowpKnmOT4LPcOvbVZ06ftHgcfh +am5KaxLlhoqdZKMvW6K/NW1/b58X3Xw00GxHwL0GL9rXxP+014z/Y+0P4CSfGSb/hV2ofGvwH4d 8S/EXxFq0X7QKfCxtaX4OWnwb8J6x8WD4zk+BaePTocK+HP+FRjxww8M1oaL+3N8TLb4V/Hq88af sifEfVP2mf2evifofwj8Rfs6/ALxPZfFvR/HviDx1oPhTxh8OfGPwx+M3jvw78CtFPwc1fwj410z UfGXxN+LfhP4QWPw91Xw38RND1TTNQk8NaLeeLsauKoUcKsbUqcuFqYPCY/CV1GcqeZ4PH0sDWwO IyZwjJ53TxdPMsFLDf2Qsa63tmqalKlWVPnoReImqdJwb9tiKFSdScKNHDVMJjsxy3GPG160qdHA UsHmGU5jg8ZXxtShRwmIwlSniKlKXKpfo1RXxb8L/wBpL4x/Hj9jL4CftKfBr4CeFNU+J/x6+GHw w+I1l8IvH3xul8E+AvAv/Ce+GbHxTq9l4w+M2jfCnx34in0rwzbT3GkWmreEPgh4o1bxDr0mjxv4 W0TQ73V9f8Pdb+yN+0Rrv7SXw58VeJPF3w70/wCGXjb4d/F/4pfBDxzoHhrx9a/Ff4f3XjD4T+J7 nwxr2rfDT4nQeG/BN1438GXN5A9rDqOueA/AXijSdestf8KeKfBugeIPD2o2a9+Iw1bC47H5ZXUK eOyx4pYzDe2oynCOCxeEwOLq0XCpKGLw+HxmOweHq4nCSr4eNXE0YureaIqN0aWFrVYzpwxmJjg6 PPTnGccXPDY3GQwuJpOKq4LETwuW46tGjjIUKko4WqlFyjZ/UtFFFYDCiiigAooooAKKKKACiiig AooooAKKKKACiiigAr8Ab/8AYc/az0T4W/s32Pwu8JaT4Z8d/EWD48fsi/tlXEnjvwv4b1zwd+yL 8avjN8QPirbfGLw34r0R/EDeJviN8JrVtQ0/4TeFdJk1C4stX+P3ia7uP+EeNrruq6X+/wBRXPPC 0KmLwmMqw9rLCwxVH2Mm1RxGFx9OGHzHCV+TkrKjj8B9Yy3EuhWoV/qeNxSoVqNeVKvRzVPlxCxU KlanWhhK+GpunVlT9lUni8vzHCY6Dg4y+u5VmmU5dmmWzlKVGjj8HQrVqFeMFA/HrxP+zl+0j8Of DX/BSA/AP4b6Npt18SvjR+zN4i/Z602wg+DGt6pe/C34Xfs9fss/DfxnqXwg8L/E7U2+EegfGHwS vw18c2nwDsfj7a6J8MrX4reGPBGteNbOb4cNLe3fjvh/9jj9pDxz8AP24dD+LHgv4o/EbW/2pviD +zP4jsdD/akv/wBiO4+Lni/wh4JHww8O+P8Aw98Z9L/ZM8H/AA//AGaEuNG0Dwdq+mQaXYXvxCGv +BYPD9rc+O9c1G7fwX4V/eeis8RgqWLw9WhiJVqk6sIx+tTqyliabjQjh5VKc5XpqrVjHnrVHSlK pUbk3ZRjHvq4ypP6iqUKWDp4DDYbC0aODi8PSlRwWCwOAwkKsYyblDD0cBSlSpRcaMK051I0k40P Y/nv+1D4P+LHg/8AaK/Zi/ab+GnwO8bftK+GfhD4E+PPwp1z4IfC/wAQfBTwv448Paj8YE+F+oeG /jP4O/4X58Tfgx8NbyXwnY/C7XvhnrVi/wARtE8RQeGvizfXOgWGs2kGtWDavgf4HazfftX6L8eP EXwP8LeBtJi/Yn0D4SaVCs3gTWrz4e+I9d+Jur+L/G/wp0y60Zhcw6e2nReF28R3OgWaeCNevNH0 9LfUtW/suzkj+86KrEYWOKll861So5ZXUzieDcVRpyjTz3KOIsnzGhWqQoxq4qnUpcT5niYTxU62 Ip144ShGv/ZmGhl75pTk6VWjBqjTrUcDSqxpRjBSeW5rlWbYSstG4VadXKMNhn7NwpzwtTEc9N4q VPFUvzK+Cml/tV/sm/8ABKj4LeE/Bf7Osvxk/a1+Cv7MXw08B6H+ztbfEP4XeELPUfH/AId8PaL4 Ut/D178QtX8XaV8NrDw34VjiF7qt5p3imSO70PRriy8NyX2p3Gnwy+U/AbWf2r/gd+y1+0b4t8K/ sH/tI/EL9tPXbxPiprsvx88d/sJ/DZv2sPjt4yitPDMknh+9+DP7X/xr8LfC74V/CDw3ofhrw34c 8H+OfFWlan4c+D/hjwr4W0LxL8T/AB3H4g8Saj+xdFdNfnxVXM8RiKtatis1oSoYjGTrVPrlOFTE fWsRLD4tSWIpVMXiFCtjJ+0k8VWoYOvW56+X4Cphuqti1Xr068sJhIxp5jVzJ4anTqQwtSpV0jQn RVWyw2HpSxGHw8KTp1aVDGYqHtpOpGUPwx8L/s+/F/4rfsXftE/Bv4i/sm/He0+Nnxq8e/DH4jfH jxt+07cfsTxad+1B4q1f4ieB2+IFvoXhT4B/tUftE+HfC3wz+HPww8EWHgHwh8NviFqtr/ZHwr0f wf4Rg8Q/FLxSninxFqfon7Xv7Jvxw+I/xl/aS8Z/Df4d6Rr/AIN1/wDZz/YG/sTw3Nrvg/QLH45e Lf2TP2vPjV8dfG37P+oC81exn0qLxp8Nda0rwHpuseN7ax+Gu74giy1LVDpVl4nXTf2KoqYxlRzC lmOEqTwM6McDGnhMLGjHLUstwmIwuAhLLalKrg6mGwkq1LFUMvqUZZbTxGBwEY4P6ph3hZzhcXPD YfHYd06OKjmCgq08ZSjXqRks6yrPcRUpyfLFVcdi8ppUcbUnGcq2FxOMpJwnUpVaH4tQeIfjr8Mf 2if2lP28tT/Ym1z4eXHxc/Z5/ZQ+APw2+DXif4ifBh/jr8WvjN4Z+PPxp0OPS/iLefArW/jd4F8N s2i/FLwjd+H/ABNaeP8A4laJpXw40xtX8aax4Ci0LxFonhf7j/bf+IP7Vfw/+Bdzdfsc/AvVfjf8 a/EviLQfCVrbaZrXwisz8LfDetyTJ4o+MEnh/wCM3xd+BnhP4k3fgPTIpLvw/wDDIfEzwi/jfxPc aLpGpeJPDXh2XWvEOl/YVFc1PBQp4Kngfa4j2NPF4qtaE6dDnwuNzbEZ1i8JKdClTxFN4rE4/MMJ XxeFr4fE08uqYSOAngczwtTNsXM8TUqY+pmFXlq1qmFwWGdKpTovDU5ZblGEyTA4inRp0qblVw+E wGDqyhip4nD4nF0pVMXRr0a9bDz/ABF0r4DfEjQfhF+xz8R/hn+x7+0xo3jf9iH9p/xb8Vtf+Dnx r+IX7G0n7Rn7USfGf4P/ABc+GHxt+MEHjT4X/tHeKP2dLr4j+KPFPx/134uatD45+Jnwlttc17wp 4l0LTdM8J6PqPhOC8+l/hwn7QHgfRP2rf2mvFH7MXxP1zxv+0B488EXfgb9lPwN4p/Z1l+NvhPwF 4S+HPhL4X2DePvFfi39oPw1+zlN4yn1Ww8T+N9fs/Cnxz1bQtM8HT6FpGial4m8WQahZXH6R0V1Y +EcyiqeKjD2dOjUw+DpUaVHD0cvo16eHpV6WCpUacKdKnVVLFctOcakMLHMsbRwUcNhoYChgcKcp 0qmGqQm1LD0/ZTco06ksXCOJxuMpfWqtSE69SrSxOOqVfrEKtLEV3TpQxdXEU1UhV/GT9n/wt8Ud M/4JlfA39nj9pL/gl78Q/jJN8L/Anwi+CXxZ/Zj+IviL9g/x/L8RrHwL4K0Rm+JPgPSfEf7SXiP4 AeM/COlePNK0oQaT8Vvib8KvGltBp9/4n0vwxeahpWhaT4g+oP8Agn18HfiF8IPAfxah8T+Btf8A gf8ADnxv8ZtS8Yfs9/st+I/F/hfxlefst/BxfA3gPwtZfCaxm8AeJPGvwz8HaDceMfDPjDx94d+F Pwp8a+LPhh8K9E8aWPgnwRq0Wj6TFpGl/fdFdtXG16+OzjMavs5YjO1WWL/dQUIe3xmX4+rLDxUV KE3isvhONWcqlWnTxOLw1KcMLWVGFYmrWxTpe1rT5KeLq450lGk6dTE1YYuk6jVSnN0ZRpYyVJSw ssPKdOlSjWlVTre2KKKK5CAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigD/2QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAUEsDBBQABgAIAAAAIQDSD1WHtQEAAHYDAAARAAAAcHB0L3ZpZXdQcm9wcy54 bWyMU8tu2zAQvBfoPxC8J3q4kV3BcoCi6CmHAHZ6Z0haJsAXuLQj++u7pKzYbnLIjfuanZmVlo+D 0eQgAyhnO1rdl5RIy51Qtu/oy+bP3YISiMwKpp2VHT1KoI+r79+Wvj0o+fYcCAJYaFlHdzH6tiiA 76RhcO+8tFjbumBYxDD0hQjsDYGNLuqybArDlKXn+fCVebfdKi5/O7430sYRJEjNIpKHnfIwofmv oPkgAWHy9C0lzSD+RXUdBS02u715tUzplKErFG6TpByifPQu/mJhjThoj2GDMuokRW7EBdEFKZ7k NhI4ob8PTV3SIoFMtY3zufTzR9PkUnG7IPWCVkKm9c8hhXytxVU0PskBSXCmkUSVl0MKVkvWwkDw tHM8pMBamZdg9vgxi6vPU751QfXKkqGjd1VZU3LEx6yeN4k99vELgX6P7J4gJmr5TXAWjcUbuHCi xDvoaF2N6qaWMblYTJIvIAn8SmDidCvfuihhI4d8orMjFzb/ya5G1Yn1pPkqlcBHm64F4z+Aaidm 70qx+ZPVfVBi7RnH75pwdGs+m8/wyIjBEeQ9Gl07jDf8BwAA//8DAFBLAwQUAAYACAAAACEA2wkD RFUBAACdAgAAEQAAAHBwdC9wcmVzUHJvcHMueG1stJHLasMwEEX3hf6D0V7Rw44Tm9jBjl0odNFF +wHClhOB9UBSHqX03yuctCR0k013Mwz3zrkzq/VJjtGBWye0KgCZYRBx1eleqG0B3t+e4BJEzjPV s1ErXoAP7sC6fHxYmdxY7rjyzAfpq42CkXI5K8DOe5Mj5Lodl8zNtOEqzAZtJfOhtVvUW3YMC+SI KMYpkkwocNHbe/R6GETHG93tZQA4m1g+TiRuJ4z7cTP3uF3nuEEqQ0h+8i/OX6pob0UBPttFummz pIIpjjcwIQmFddbWMG1IvMCY4IouvkDQkCTvheuY7Z8l2/K2F75hnl2ihvEfPCk6q50e/KzTEp1z IqOP3BotpqgEX9+rACA6sLEAGKByhSbeW9gmJhVOaQUX2bKCSUwzWNVNA+u6Ws7TlOI5wb+wfGD7 0U+wjRH/wUnpDemZeLpwKK8/8WrLbwAAAP//AwBQSwMEFAAGAAgAAAAhANj9jY+sAAAAtgAAABMA AABwcHQvdGFibGVTdHlsZXMueG1sDMxJDoIwGEDhvYl3aP59LUNRJBTCICt36gEqlCHpQGijEuPd Zfnyki/NP0qil1jsZDQD/+ABEro13aQHBo97g2NA1nHdcWm0YLAKC3m236U8cU95c6sUV+vQpmib cAajc3NCiG1Hobg9mFno7fVmUdxtuQykW/h705UkgecdieKTBtSJnsE3qoIgorTAp8vliGlIA1x6 NMZxVNbVuan9Kix+QLI/AAAA//8DAFBLAwQUAAYACAAAACEACt4NM3ECAACkBQAAEAAIAWRvY1By b3BzL2FwcC54bWwgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACcVMlu2zAQvRfo PxA6pUBjeQmM1KAZFA4CF6gbA1aS84QaWUQpUiBpJ+7XdyRZXmq3QeqLZ3ma5c1w+M1rodkanVfW jKNepxsxNNKmyizH0UNyd3kdMR/ApKCtwXG0QR/diI8f+NzZEl1Q6BmFMH4c5SGUozj2MscCfIfc hjyZdQUEUt0ytlmmJN5auSrQhLjf7Q5jfA1oUkwvy13AqIk4Wof/DZpaWdXnH5NNSQULntgAOlEF iuGAx3uNP1mXetEfDnnciPxrWWolIRAhYqaks95mgd3XpbO5fUE3t8oEHh8CiQ701FP92V3dsrg3 l146RMMWuX1hF1ejwScenwHyOThYOihzLwZdguxVvtAqRS+uebyV+A8byECwRuBTlaZotl4yH+l8 NptoVdb4VuQLCRonxI/IQHuk0DsDnyJUs5+Dcl7wdRitUQbrmFe/aPpXEXsGjxWr42gNToEJxG4F a5Ra1qUPTiS0BhSbfI1ei4ewQ1ldiV4NIOGfwCZW3S1LVNDo35GCWKRyTlJUxqZNyn1MQJPiPqOR hDN8fDnkoy6tYaOpcrszJ0TsKJmBkznr9036mfW7PdrMnavitInypBxSm57RRsvqf2JNcFaz96Ev JH1G+7eLu8+wKKg7JlX1mGNlMgc0v5UMK9rp81meV0pXa8JgFSw9b3orZyOvMVdypcG9BZS2KNBJ Bfot5NQW+BfM0Rz/mNzEFiWYjZgoLy1bbHzAwrNvCY9bD/+uzE//UCb2FgK2T+PYyBc5OEzpgrX+ vYFP6VU4XQWZ5GCWmLaYU0d1ZB6boyt6/U6XfvU9aW3VmWjPq/gNAAD//wMAUEsDBBQABgAIAAAA IQCyI7NsfwEAALsCAAARAAgBZG9jUHJvcHMvY29yZS54bWwgogQBKKAAAQAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAACMkktP4zAUhfdI/AfLqxmJ1HnwkpUaCRCrqYRERozYGfvSWJM4ln2h9N+P nbShaFiwi3PO/XTuseur974jb+CDGeySFoucErBq0Maul/R3c5ddUhJQWi27wcKSbiHQK3F8VCvH 1eDh3g8OPBoIJJJs4MotaYvoOGNBtdDLsIgOG8WXwfcS49GvmZPqr1wDK/P8nPWAUkuULAEzNxPp DqnVjHSvvhsBWjHooAeLgRWLgn14EXwfvhwYlQNnb3Dr4k67uIdsrSZxdr8HMxs3m81iU40xYv6C /Vn9ehhXzYxNXSmgotaKo8EOxEp61ZKytPqElHlR1WyWkkl5kDh4cS+Dkh1p2tfn2Cf54XD6+jn6 965UeycDruINvRjQ11vRtEMsmTxKRNhaqNn/ljTl4c2kSxZFPlrmcwwxFjMlAU3iqnwqZq88Vje3 zR0VKX6WV1lZNsUpP7vgxdlTivdpPq0+/eh3Ib9DrJr8nFenvDwk7gFiTPz5uYl/AAAA//8DAFBL AQItABQABgAIAAAAIQBi+1zGJgIAANQPAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBl c10ueG1sUEsBAi0AFAAGAAgAAAAhAGj4dKEFAQAA4gIAAAsAAAAAAAAAAAAAAAAAXwQAAF9yZWxz Ly5yZWxzUEsBAi0AFAAGAAgAAAAhAEv1Pey/AAAANwEAACAAAAAAAAAAAAAAAAAAlQcAAHBwdC9z bGlkZXMvX3JlbHMvc2xpZGUzLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAGNcI7TBAAAANwEAACAA AAAAAAAAAAAAAAAAkggAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGUxLnhtbC5yZWxzUEsBAi0AFAAG AAgAAAAhAEv1Pey/AAAANwEAACAAAAAAAAAAAAAAAAAAkQkAAHBwdC9zbGlkZXMvX3JlbHMvc2xp ZGU0LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAEv1Pey/AAAANwEAACAAAAAAAAAAAAAAAAAAjgoA AHBwdC9zbGlkZXMvX3JlbHMvc2xpZGUyLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAEv1Pey/AAAA NwEAACAAAAAAAAAAAAAAAAAAiwsAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGU1LnhtbC5yZWxzUEsB Ai0AFAAGAAgAAAAhAEv1Pey/AAAANwEAACAAAAAAAAAAAAAAAAAAiAwAAHBwdC9zbGlkZXMvX3Jl bHMvc2xpZGU2LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAEv1Pey/AAAANwEAACAAAAAAAAAAAAAA AAAAhQ0AAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGU3LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAEv1 Pey/AAAANwEAACAAAAAAAAAAAAAAAAAAgg4AAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGU4LnhtbC5y ZWxzUEsBAi0AFAAGAAgAAAAhAKd0L9lPAQAAdwcAAB8AAAAAAAAAAAAAAAAAfw8AAHBwdC9fcmVs cy9wcmVzZW50YXRpb24ueG1sLnJlbHNQSwECLQAUAAYACAAAACEAqnnZeXcCAAB1DQAAFAAAAAAA AAAAAAAAAAATEgAAcHB0L3ByZXNlbnRhdGlvbi54bWxQSwECLQAUAAYACAAAACEAn3IMql0CAABX BQAAFQAAAAAAAAAAAAAAAAC8FAAAcHB0L3NsaWRlcy9zbGlkZTEueG1sUEsBAi0AFAAGAAgAAAAh AOTYD358AwAACQkAABUAAAAAAAAAAAAAAAAATBcAAHBwdC9zbGlkZXMvc2xpZGU4LnhtbFBLAQIt ABQABgAIAAAAIQDCkLCC0QIAAJgGAAAVAAAAAAAAAAAAAAAAAPsaAABwcHQvc2xpZGVzL3NsaWRl Ni54bWxQSwECLQAUAAYACAAAACEA2lBsOhkDAAAoCAAAFQAAAAAAAAAAAAAAAAD/HQAAcHB0L3Ns aWRlcy9zbGlkZTUueG1sUEsBAi0AFAAGAAgAAAAhAJ7s8UPeAgAAngYAABUAAAAAAAAAAAAAAAAA SyEAAHBwdC9zbGlkZXMvc2xpZGU3LnhtbFBLAQItABQABgAIAAAAIQDaqtkCMgUAAE0QAAAVAAAA AAAAAAAAAAAAAFwkAABwcHQvc2xpZGVzL3NsaWRlMy54bWxQSwECLQAUAAYACAAAACEA3LeDIIEE AAAbDwAAFQAAAAAAAAAAAAAAAADBKQAAcHB0L3NsaWRlcy9zbGlkZTIueG1sUEsBAi0AFAAGAAgA AAAhAANcxcmoAwAAfgoAABUAAAAAAAAAAAAAAAAAdS4AAHBwdC9zbGlkZXMvc2xpZGU0LnhtbFBL AQItABQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAAAAAAAAAAAAAAFAyAABwcHQvc2xpZGVMYXlv dXRzL19yZWxzL3NsaWRlTGF5b3V0Mi54bWwucmVsc1BLAQItABQABgAIAAAAIQDV0ZLxvgAAADcB AAAsAAAAAAAAAAAAAAAAAFgzAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0My54 bWwucmVsc1BLAQItABQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAAAAAAAAAAAAAAGA0AABwcHQv c2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0NC54bWwucmVsc1BLAQItABQABgAIAAAAIQDV 0ZLxvgAAADcBAAAsAAAAAAAAAAAAAAAAAGg1AABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRl TGF5b3V0NS54bWwucmVsc1BLAQItABQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAAAAAAAAAAAAA AHA2AABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0Ni54bWwucmVsc1BLAQItABQA BgAIAAAAIQDV0ZLxvgAAADcBAAAtAAAAAAAAAAAAAAAAAHg3AABwcHQvc2xpZGVMYXlvdXRzL19y ZWxzL3NsaWRlTGF5b3V0MTAueG1sLnJlbHNQSwECLQAUAAYACAAAACEA1dGS8b4AAAA3AQAALAAA AAAAAAAAAAAAAACBOAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDgueG1sLnJl bHNQSwECLQAUAAYACAAAACEA1dGS8b4AAAA3AQAALAAAAAAAAAAAAAAAAACJOQAAcHB0L3NsaWRl TGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDkueG1sLnJlbHNQSwECLQAUAAYACAAAACEAJfOUjwcI AADyLwAAIQAAAAAAAAAAAAAAAACROgAAcHB0L3NsaWRlTWFzdGVycy9zbGlkZU1hc3RlcjEueG1s UEsBAi0AFAAGAAgAAAAhANXRkvG+AAAANwEAAC0AAAAAAAAAAAAAAAAA10IAAHBwdC9zbGlkZUxh eW91dHMvX3JlbHMvc2xpZGVMYXlvdXQxMS54bWwucmVsc1BLAQItABQABgAIAAAAIQDV0ZLxvgAA ADcBAAAsAAAAAAAAAAAAAAAAAOBDAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0 Ny54bWwucmVsc1BLAQItABQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAAAAAAAAAAAAAAOhEAABw cHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0MS54bWwucmVsc1BLAQItABQABgAIAAAA IQCslGfmpAQAACARAAAhAAAAAAAAAAAAAAAAAPBFAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5 b3V0MS54bWxQSwECLQAUAAYACAAAACEAaaJfIR4BAADHBwAALAAAAAAAAAAAAAAAAADTSgAAcHB0 L3NsaWRlTWFzdGVycy9fcmVscy9zbGlkZU1hc3RlcjEueG1sLnJlbHNQSwECLQAUAAYACAAAACEA pLy6yU0DAADVCAAAIQAAAAAAAAAAAAAAAAA7TAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91 dDYueG1sUEsBAi0AFAAGAAgAAAAhAOX8egjkBQAAUhwAACEAAAAAAAAAAAAAAAAAx08AAHBwdC9z bGlkZUxheW91dHMvc2xpZGVMYXlvdXQ1LnhtbFBLAQItABQABgAIAAAAIQBJhsyqhQQAAIMSAAAh AAAAAAAAAAAAAAAAAOpVAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0NC54bWxQSwECLQAU AAYACAAAACEAOATyiPcEAAB1EQAAIQAAAAAAAAAAAAAAAACuWgAAcHB0L3NsaWRlTGF5b3V0cy9z bGlkZUxheW91dDMueG1sUEsBAi0AFAAGAAgAAAAhAHAWmgfAAwAAsgsAACEAAAAAAAAAAAAAAAAA 5F8AAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQyLnhtbFBLAQItABQABgAIAAAAIQCVWz/F YgUAAN4SAAAhAAAAAAAAAAAAAAAAAONjAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0OC54 bWxQSwECLQAUAAYACAAAACEAh/WdxxgDAACDBwAAIQAAAAAAAAAAAAAAAACEaQAAcHB0L3NsaWRl TGF5b3V0cy9zbGlkZUxheW91dDcueG1sUEsBAi0AFAAGAAgAAAAhAP4jaGvWAwAA6AsAACIAAAAA AAAAAAAAAAAA22wAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQxMC54bWxQSwECLQAUAAYA CAAAACEA+68s8B4FAABNEgAAIQAAAAAAAAAAAAAAAADxcAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlk ZUxheW91dDkueG1sUEsBAi0AFAAGAAgAAAAhAEXwK80jBAAAyQwAACIAAAAAAAAAAAAAAAAATnYA AHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQxMS54bWxQSwECLQAUAAYACAAAACEAuX/uc5YG AACwGwAAFAAAAAAAAAAAAAAAAACxegAAcHB0L3RoZW1lL3RoZW1lMS54bWxQSwECLQAKAAAAAAAA ACEA5JRimAAYAAAAGAAAFwAAAAAAAAAAAAAAAAB5gQAAZG9jUHJvcHMvdGh1bWJuYWlsLmpwZWdQ SwECLQAUAAYACAAAACEA0g9Vh7UBAAB2AwAAEQAAAAAAAAAAAAAAAACumQAAcHB0L3ZpZXdQcm9w cy54bWxQSwECLQAUAAYACAAAACEA2wkDRFUBAACdAgAAEQAAAAAAAAAAAAAAAACSmwAAcHB0L3By ZXNQcm9wcy54bWxQSwECLQAUAAYACAAAACEA2P2Nj6wAAAC2AAAAEwAAAAAAAAAAAAAAAAAWnQAA cHB0L3RhYmxlU3R5bGVzLnhtbFBLAQItABQABgAIAAAAIQAK3g0zcQIAAKQFAAAQAAAAAAAAAAAA AAAAAPOdAABkb2NQcm9wcy9hcHAueG1sUEsBAi0AFAAGAAgAAAAhALIjs2x/AQAAuwIAABEAAAAA AAAAAAAAAAAAmqEAAGRvY1Byb3BzL2NvcmUueG1sUEsFBgAAAAAzADMARA8AAFCkAAAAAA== --047d7b111c53e7265904d892dd1e-- Return-Path: 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 594A521F843E for <6tsch@ietfa.amsl.com>; Fri, 22 Mar 2013 23:32:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.927 X-Spam-Level: X-Spam-Status: No, score=-1.927 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 1i--tfjjSvX2 for <6tsch@ietfa.amsl.com>; Fri, 22 Mar 2013 23:32:31 -0700 (PDT) Received: from mail-da0-x22f.google.com (mail-da0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 685B421F843C for <6tsch@ietf.org>; Fri, 22 Mar 2013 23:32:31 -0700 (PDT) Received: by mail-da0-f47.google.com with SMTP id s35so2523719dak.6 for <6tsch@ietf.org>; Fri, 22 Mar 2013 23:32:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=jbpEmWYFkdM+l2GOGWhVF2/tWwoWrbhpoGHv0/ex7FI=; b=gpRmv+SZp1uipDxZgXromkKTBa1FtYGkRUoLK9cZKT3BCenCCyW9pDCZQ0niAA1RRM 9yTpnegmX3mjeoHGAIHXf95lnDrOStZU7d5NXII5R360S3e5vzX9uJDA4Gm7ZQ0h1Bpl F6oTAawEkbPLuUKI5IB5M9eop/RvcvWcMAHwW0RYSQz98XnbZXcByAd7gGciViOXaNlG n+xGg4Q9jjBe6F2EQCZv4dwAJOO8ZYCuVfguowTPdWG9UEoye7bJJxsGwupmFKJ53we4 s+pI/vUbZpB+Gi8Y0CH9eFWURVQsxE8Ult/4sFNKoCMq2KDO/U5CrXq4KDiW9uReUfa7 lBKA== X-Received: by 10.66.233.9 with SMTP id ts9mr2743521pac.15.1364020351143; Fri, 22 Mar 2013 23:32:31 -0700 (PDT) MIME-Version: 1.0 Sender: twatteyne@gmail.com Received: by 10.68.227.71 with HTTP; Fri, 22 Mar 2013 23:32:11 -0700 (PDT) In-Reply-To: References: <514C86C1.9000202@eecs.berkeley.edu> <671d1cf041282cca812b4ae600b998a0.squirrel@calmail.berkeley.edu> From: Thomas Watteyne Date: Fri, 22 Mar 2013 23:32:11 -0700 X-Google-Sender-Auth: -iO70NJ1R9sYj1depKV3Ux6xFLA Message-ID: To: "6tsch@ietf.org" <6tsch@ietf.org> Content-Type: multipart/alternative; boundary=047d7b111c537f173304d891bcc8 Subject: Re: [6tsch] blacklisting support on 6tus 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 06:32:32 -0000 --047d7b111c537f173304d891bcc8 Content-Type: text/plain; charset=ISO-8859-1 +1 I agree that 6tus should not have to care about channel blacklist. Thanks for clarifying that. On Fri, Mar 22, 2013 at 1:19 PM, Maria Rita PALATTELLA < maria-rita.palattella@uni.lu> wrote: > Hi Qin, > yes, this is what I meant. From my point of view, 6tus shoudn't have much > to do related to the blacklisting. > Once the TSCH coordinator has selected the set of channels to be used in > the TSCH-LLN, the PCE should collect such information (-- how is something > still to be defined--). > Then, the PCE knows how many channels (and channel offsets) are available > for building the schedule (i.e., allocates the cells). > Maria Rita > ________________________________________ > From: Qin Wang [qinwang@berkeley.edu] > Sent: Friday, March 22, 2013 8:31 PM > To: Maria Rita PALATTELLA > Cc: Thomas Watteyne; 6tsch@ietf.org > Subject: Re: [6tsch] blacklisting support on 6tus > > Hi Maria Rita, > > I guess you mean that PCE needs to know the set of channels. I agree with > it. However, I think PCE has same knowledge as TSCH coordinator. The > blacklist is formed by TSCH coordinator without effort of 6tus by > definition of IEEE802.15.4e, thus, PCE should know the set of channels > without 6tus help. > > I'm not sure how PCE get information from TSCH coordinator. But I think > the information should not provided by 6tus. > > Does it make sense? > > Qin > > > > Xavi, all, > > 6tus allocates soft/hard cells, that are function of the channelOffset. > > The number of available channelOffset is equal to the number of available > > PHY channels. > > The blacklist affects the PHY channel (i.e., frequency) that is actually > > used for the transmission. > > Thus, in case of balcklisting, if the number of available channels (i.e., > > the size of the blacklist doesn't change), then 6tus will not need to > > reallocate the soft cells. > > The channel offset will be translated in a different PHY channel, based > on > > the list of available frequencies. > > Only if the size of the blacklist changes, then, 6tus will need to > > reallocate soft cells. > > In any case, 6tus may needs to provide a command for knowing abut the > > blacklist and thus, the set of available channels. > > Does this make sense to you? > > Maria Rita > > > > ________________________________ > > From: 6tsch-bounces@ietf.org [6tsch-bounces@ietf.org] on behalf of > Thomas > > Watteyne [watteyne@eecs.berkeley.edu] > > Sent: Friday, March 22, 2013 5:59 PM > > To: 6tsch@ietf.org > > Subject: Re: [6tsch] blacklisting support on 6tus > > > > IEEE802.15.4e supports blacklisting of one of more frequencies for the > > whole network, as per > > > http://tools.ietf.org/html/draft-watteyne-6tsch-tsch-lln-context-01#appendix-A.7 > . > > We could add a command in 6tus to drive that, but I would keep the > > blacklisting behavior of IEEE802.15.4e, i.e. LLN-wide. > > Thomas > > > > On Fri, Mar 22, 2013 at 9:54 AM, Qin Wang > > > wrote: > > Xavi and all, > > > > When we talk about blacklist, the assumption is the blacklist is LLN > wide, > > or inside of a subnet, or just pair of nodes? In WirelessHart and ISA100, > > blacklist seems LLN wide. > > > > Qin > > > > > >> From the discussion today I've detected the need to blacklist channels. > >> Does 6tus need to provide a command to do that? Specially if > >> blacklisting is dynamic, 6tus needs to reallocate softlinks from that > >> channels that have been blacklisted. > >> > >> regards, > >> X > >> _______________________________________________ > >> 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 > > > > --047d7b111c537f173304d891bcc8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1

I agree that 6tus should not have to care about chann= el blacklist. Thanks for clarifying that.

On Fri, Mar 22, 2013 at 1:19 PM, Maria Rita PALATTELLA &= lt;maria-= rita.palattella@uni.lu> wrote:
Hi Qin,
yes, this is what I meant. From my point of view, 6tus shoudn't have mu= ch to do related to the blacklisting.
Once the TSCH coordinator has selected the set of channels to be used in th= e TSCH-LLN, =A0the PCE should collect such information (-- how is something= still to be defined--).
Then, the PCE knows how many channels (and =A0channel offsets) are availabl= e for building the schedule (i.e., allocates the cells).
Maria Rita
________________________________________
From: Qin Wang [qinwang@berkeley.ed= u]
Sent: Friday, March 22, 2013 8:31 PM
To: Maria Rita PALATTELLA
Cc: Thomas Watteyne; 6tsch@ietf.org
Subject: Re: [6tsch] blacklisting s= upport on 6tus

Hi Maria Rita,

I guess you mean that PCE needs to know the set of channels. I agree with it. However, I think PCE has same knowledge as TSCH coordinator. The
blacklist is formed by TSCH coordinator without effort of 6tus by
definition of IEEE802.15.4e, thus, PCE should know the set of channels
without 6tus help.

I'm not sure how PCE get information from TSCH coordinator. But I think=
the information should not provided by 6tus.

Does it make sense?

Qin


> Xavi, all,
> 6tus allocates soft/hard cells, that are function of the channelOffset= .
> The number of available channelOffset is equal to the number of availa= ble
> PHY channels.
> The blacklist affects the PHY channel (i.e., frequency) that is actual= ly
> used for the transmission.
> Thus, in case of balcklisting, if the number of available channels (i.= e.,
> the size of the blacklist doesn't change), then 6tus will not need= to
> reallocate the soft cells.
> The channel offset will be translated in a different PHY channel, base= d on
> the list of available frequencies.
> Only if the size of the blacklist changes, then, 6tus will need to
> reallocate soft cells.
> In any case, 6tus may needs to provide a command for knowing abut the<= br> > blacklist and thus, the set of available channels.
> Does this make sense to you?
> Maria Rita
>
> ________________________________
> From: 6tsch-bounces@ietf.org= [6tsch-bounces@ietf.org]= on behalf of Thomas
> Watteyne [watteyne@eecs.= berkeley.edu]
> Sent: Friday, March 22, 2013 5:59 PM
> To: 6tsch@ietf.org
> Subject: Re: [6tsch] blacklisting support on 6tus
>
> IEEE802.15.4e supports blacklisting of one of more frequencies for the=
> whole network, as per
> http://tools.ietf.org/html/draft-w= atteyne-6tsch-tsch-lln-context-01#appendix-A.7.
> We could add a command in 6tus to drive that, but I would keep the
> blacklisting behavior of IEEE802.15.4e, i.e. LLN-wide.
> Thomas
>
> On Fri, Mar 22, 2013 at 9:54 AM, Qin Wang
> <qinwang@berkeley.edu&l= t;mailto:qinwang@berkeley.edu&g= t;> wrote:
> Xavi and all,
>
> When we talk about blacklist, the assumption is the blacklist is LLN w= ide,
> or inside of a subnet, or just pair of nodes? In WirelessHart and ISA1= 00,
> blacklist seems LLN wide.
>
> Qin
>
>
>> =A0From the discussion today I've detected the need to blackli= st channels.
>> Does 6tus need to provide a command to do that? Specially if
>> blacklisting is dynamic, 6tus needs to reallocate softlinks from t= hat
>> channels that have been blacklisted.
>>
>> regards,
>> X
>> _______________________________________________
>> 6tsch mailing list
>> 6tsch@ietf.org<mailto:6tsch@ietf.org>
>> https://www.ietf.org/mailman/listinfo/6tsch
>>
>
>
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org<mailto:6tsch@ietf.org>
> https://www.ietf.org/mailman/listinfo/6tsch
> <https://www.ietf.org/mailman/listinfo/6tsch>
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch
>


--047d7b111c537f173304d891bcc8-- Return-Path: 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 8FF5F21F925B for <6tsch@ietfa.amsl.com>; Fri, 22 Mar 2013 13:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 Gz34uFxJhIkM for <6tsch@ietfa.amsl.com>; Fri, 22 Mar 2013 13:19:19 -0700 (PDT) Received: from hercules.uni.lu (hercules.uni.lu [158.64.76.33]) by ietfa.amsl.com (Postfix) with ESMTP id 4A36F21F90B3 for <6tsch@ietf.org>; Fri, 22 Mar 2013 13:19:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,893,1355094000"; d="scan'208";a="23079998" Received: from unknown (HELO Travis.uni.lux) ([10.21.2.19]) by hercules.uni.lu with ESMTP; 22 Mar 2013 21:19:18 +0100 Received: from HOSHI.uni.lux ([fe80::499:a33:4e68:4af9]) by Travis.uni.lux ([fe80::653b:7b8e:4641:a750%10]) with mapi id 14.01.0438.000; Fri, 22 Mar 2013 21:19:18 +0100 From: Maria Rita PALATTELLA To: Qin Wang Thread-Topic: [6tsch] blacklisting support on 6tus Thread-Index: AQHOJxpqQp7UqivFCkSTT1SuiNmYwZix3OMAgAABdYCAABIMC4AAGDiAgAAbUSM= Date: Fri, 22 Mar 2013 20:19:17 +0000 Message-ID: References: <514C86C1.9000202@eecs.berkeley.edu> <671d1cf041282cca812b4ae600b998a0.squirrel@calmail.berkeley.edu>, , In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.34.0.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Thomas Watteyne , "6tsch@ietf.org" <6tsch@ietf.org> Subject: Re: [6tsch] blacklisting support on 6tus 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 20:19:20 -0000 Hi Qin,=0A= yes, this is what I meant. From my point of view, 6tus shoudn't have much t= o do related to the blacklisting.=0A= Once the TSCH coordinator has selected the set of channels to be used in th= e TSCH-LLN, the PCE should collect such information (-- how is something s= till to be defined--).=0A= Then, the PCE knows how many channels (and channel offsets) are available = for building the schedule (i.e., allocates the cells). =0A= Maria Rita=0A= ________________________________________=0A= From: Qin Wang [qinwang@berkeley.edu]=0A= Sent: Friday, March 22, 2013 8:31 PM=0A= To: Maria Rita PALATTELLA=0A= Cc: Thomas Watteyne; 6tsch@ietf.org=0A= Subject: Re: [6tsch] blacklisting support on 6tus=0A= =0A= Hi Maria Rita,=0A= =0A= I guess you mean that PCE needs to know the set of channels. I agree with= =0A= it. However, I think PCE has same knowledge as TSCH coordinator. The=0A= blacklist is formed by TSCH coordinator without effort of 6tus by=0A= definition of IEEE802.15.4e, thus, PCE should know the set of channels=0A= without 6tus help.=0A= =0A= I'm not sure how PCE get information from TSCH coordinator. But I think=0A= the information should not provided by 6tus.=0A= =0A= Does it make sense?=0A= =0A= Qin=0A= =0A= =0A= > Xavi, all,=0A= > 6tus allocates soft/hard cells, that are function of the channelOffset.= =0A= > The number of available channelOffset is equal to the number of available= =0A= > PHY channels.=0A= > The blacklist affects the PHY channel (i.e., frequency) that is actually= =0A= > used for the transmission.=0A= > Thus, in case of balcklisting, if the number of available channels (i.e.,= =0A= > the size of the blacklist doesn't change), then 6tus will not need to=0A= > reallocate the soft cells.=0A= > The channel offset will be translated in a different PHY channel, based o= n=0A= > the list of available frequencies.=0A= > Only if the size of the blacklist changes, then, 6tus will need to=0A= > reallocate soft cells.=0A= > In any case, 6tus may needs to provide a command for knowing abut the=0A= > blacklist and thus, the set of available channels.=0A= > Does this make sense to you?=0A= > Maria Rita=0A= >=0A= > ________________________________=0A= > From: 6tsch-bounces@ietf.org [6tsch-bounces@ietf.org] on behalf of Thomas= =0A= > Watteyne [watteyne@eecs.berkeley.edu]=0A= > Sent: Friday, March 22, 2013 5:59 PM=0A= > To: 6tsch@ietf.org=0A= > Subject: Re: [6tsch] blacklisting support on 6tus=0A= >=0A= > IEEE802.15.4e supports blacklisting of one of more frequencies for the=0A= > whole network, as per=0A= > http://tools.ietf.org/html/draft-watteyne-6tsch-tsch-lln-context-01#appen= dix-A.7.=0A= > We could add a command in 6tus to drive that, but I would keep the=0A= > blacklisting behavior of IEEE802.15.4e, i.e. LLN-wide.=0A= > Thomas=0A= >=0A= > On Fri, Mar 22, 2013 at 9:54 AM, Qin Wang=0A= > > wrote:=0A= > Xavi and all,=0A= >=0A= > When we talk about blacklist, the assumption is the blacklist is LLN wide= ,=0A= > or inside of a subnet, or just pair of nodes? In WirelessHart and ISA100,= =0A= > blacklist seems LLN wide.=0A= >=0A= > Qin=0A= >=0A= >=0A= >> From the discussion today I've detected the need to blacklist channels.= =0A= >> Does 6tus need to provide a command to do that? Specially if=0A= >> blacklisting is dynamic, 6tus needs to reallocate softlinks from that=0A= >> channels that have been blacklisted.=0A= >>=0A= >> regards,=0A= >> X=0A= >> _______________________________________________=0A= >> 6tsch mailing list=0A= >> 6tsch@ietf.org=0A= >> https://www.ietf.org/mailman/listinfo/6tsch=0A= >>=0A= >=0A= >=0A= > _______________________________________________=0A= > 6tsch mailing list=0A= > 6tsch@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/6tsch=0A= > =0A= > _______________________________________________=0A= > 6tsch mailing list=0A= > 6tsch@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/6tsch=0A= >=0A= =0A= Return-Path: 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 E949321F8FD3 for <6tsch@ietfa.amsl.com>; Fri, 22 Mar 2013 12:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.509 X-Spam-Level: X-Spam-Status: No, score=-6.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 vDZ5SHO1p8iu for <6tsch@ietfa.amsl.com>; Fri, 22 Mar 2013 12:34:38 -0700 (PDT) Received: from cm03fe.IST.Berkeley.EDU (cm03fe.IST.Berkeley.EDU [169.229.218.144]) by ietfa.amsl.com (Postfix) with ESMTP id C434921F8FA7 for <6tsch@ietf.org>; Fri, 22 Mar 2013 12:34:38 -0700 (PDT) Received: from cm02ws.ist.berkeley.edu ([169.229.218.164] helo=calmail.berkeley.edu) by cm03fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth login:qinwang@berkeley.edu) (envelope-from ) id 1UJ7g7-0001hs-CH; Fri, 22 Mar 2013 12:31:10 -0700 Received: from 96.227.54.17 (SquirrelMail authenticated user qinwang@berkeley.edu) by calmail.berkeley.edu with HTTP; Fri, 22 Mar 2013 12:31:03 -0700 Message-ID: In-Reply-To: References: <514C86C1.9000202@eecs.berkeley.edu> <671d1cf041282cca812b4ae600b998a0.squirrel@calmail.berkeley.edu>, Date: Fri, 22 Mar 2013 12:31:03 -0700 From: "Qin Wang" To: "Maria Rita PALATTELLA" User-Agent: SquirrelMail/1.4.21-2.berkeley MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: Thomas Watteyne , "6tsch@ietf.org" <6tsch@ietf.org> Subject: Re: [6tsch] blacklisting support on 6tus 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 19:34:39 -0000 Hi Maria Rita, I guess you mean that PCE needs to know the set of channels. I agree with it. However, I think PCE has same knowledge as TSCH coordinator. The blacklist is formed by TSCH coordinator without effort of 6tus by definition of IEEE802.15.4e, thus, PCE should know the set of channels without 6tus help. I'm not sure how PCE get information from TSCH coordinator. But I think the information should not provided by 6tus. Does it make sense? Qin > Xavi, all, > 6tus allocates soft/hard cells, that are function of the channelOffset. > The number of available channelOffset is equal to the number of available > PHY channels. > The blacklist affects the PHY channel (i.e., frequency) that is actually > used for the transmission. > Thus, in case of balcklisting, if the number of available channels (i.e., > the size of the blacklist doesn't change), then 6tus will not need to > reallocate the soft cells. > The channel offset will be translated in a different PHY channel, based on > the list of available frequencies. > Only if the size of the blacklist changes, then, 6tus will need to > reallocate soft cells. > In any case, 6tus may needs to provide a command for knowing abut the > blacklist and thus, the set of available channels. > Does this make sense to you? > Maria Rita > > ________________________________ > From: 6tsch-bounces@ietf.org [6tsch-bounces@ietf.org] on behalf of Thomas > Watteyne [watteyne@eecs.berkeley.edu] > Sent: Friday, March 22, 2013 5:59 PM > To: 6tsch@ietf.org > Subject: Re: [6tsch] blacklisting support on 6tus > > IEEE802.15.4e supports blacklisting of one of more frequencies for the > whole network, as per > http://tools.ietf.org/html/draft-watteyne-6tsch-tsch-lln-context-01#appendix-A.7. > We could add a command in 6tus to drive that, but I would keep the > blacklisting behavior of IEEE802.15.4e, i.e. LLN-wide. > Thomas > > On Fri, Mar 22, 2013 at 9:54 AM, Qin Wang > > wrote: > Xavi and all, > > When we talk about blacklist, the assumption is the blacklist is LLN wide, > or inside of a subnet, or just pair of nodes? In WirelessHart and ISA100, > blacklist seems LLN wide. > > Qin > > >> From the discussion today I've detected the need to blacklist channels. >> Does 6tus need to provide a command to do that? Specially if >> blacklisting is dynamic, 6tus needs to reallocate softlinks from that >> channels that have been blacklisted. >> >> regards, >> X >> _______________________________________________ >> 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 > Return-Path: 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 6AE4421F8F2D for <6tsch@ietfa.amsl.com>; Fri, 22 Mar 2013 12:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.509 X-Spam-Level: X-Spam-Status: No, score=-6.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 ZTyK5CK5vnu3 for <6tsch@ietfa.amsl.com>; Fri, 22 Mar 2013 12:33:41 -0700 (PDT) Received: from cm03fe.IST.Berkeley.EDU (cm03fe.IST.Berkeley.EDU [169.229.218.144]) by ietfa.amsl.com (Postfix) with ESMTP id AC1CE21F8F29 for <6tsch@ietf.org>; Fri, 22 Mar 2013 12:33:41 -0700 (PDT) Received: from cm02ws.ist.berkeley.edu ([169.229.218.164] helo=calmail.berkeley.edu) by cm03fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth login:qinwang@berkeley.edu) (envelope-from ) id 1UJ7fl-0001Qt-AX; Fri, 22 Mar 2013 12:30:46 -0700 Received: from 96.227.54.17 (SquirrelMail authenticated user qinwang@berkeley.edu) by calmail.berkeley.edu with HTTP; Fri, 22 Mar 2013 12:30:41 -0700 Message-ID: <08f77e98659a73fe682f732f142688a9.squirrel@calmail.berkeley.edu> In-Reply-To: References: <514C86C1.9000202@eecs.berkeley.edu> <671d1cf041282cca812b4ae600b998a0.squirrel@calmail.berkeley.edu>, Date: Fri, 22 Mar 2013 12:30:41 -0700 From: "Qin Wang" To: "Maria Rita PALATTELLA" User-Agent: SquirrelMail/1.4.21-2.berkeley MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: Thomas Watteyne , "6tsch@ietf.org" <6tsch@ietf.org> Subject: Re: [6tsch] blacklisting support on 6tus 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 19:33:42 -0000 Hi Maria Rita, I guess you mean that PCE needs to know the set of channels. I agree with it. However, I think PCE has same knowledge as TSCH coordinator. The blacklist is formed by TSCH coordinator without effort of 6tus by definition of IEEE802.15.4e, thus, PCE should know the set of channels without 6tus help. I'm not sure how PCE get information from TSCH coordinator. But I think the information should not provided by 6tus. Does it make sense? Qin > Xavi, all, > 6tus allocates soft/hard cells, that are function of the channelOffset. > The number of available channelOffset is equal to the number of available > PHY channels. > The blacklist affects the PHY channel (i.e., frequency) that is actually > used for the transmission. > Thus, in case of balcklisting, if the number of available channels (i.e., > the size of the blacklist doesn't change), then 6tus will not need to > reallocate the soft cells. > The channel offset will be translated in a different PHY channel, based on > the list of available frequencies. > Only if the size of the blacklist changes, then, 6tus will need to > reallocate soft cells. > In any case, 6tus may needs to provide a command for knowing abut the > blacklist and thus, the set of available channels. > Does this make sense to you? > Maria Rita > > ________________________________ > From: 6tsch-bounces@ietf.org [6tsch-bounces@ietf.org] on behalf of Thomas > Watteyne [watteyne@eecs.berkeley.edu] > Sent: Friday, March 22, 2013 5:59 PM > To: 6tsch@ietf.org > Subject: Re: [6tsch] blacklisting support on 6tus > > IEEE802.15.4e supports blacklisting of one of more frequencies for the > whole network, as per > http://tools.ietf.org/html/draft-watteyne-6tsch-tsch-lln-context-01#appendix-A.7. > We could add a command in 6tus to drive that, but I would keep the > blacklisting behavior of IEEE802.15.4e, i.e. LLN-wide. > Thomas > > On Fri, Mar 22, 2013 at 9:54 AM, Qin Wang > > wrote: > Xavi and all, > > When we talk about blacklist, the assumption is the blacklist is LLN wide, > or inside of a subnet, or just pair of nodes? In WirelessHart and ISA100, > blacklist seems LLN wide. > > Qin > > >> From the discussion today I've detected the need to blacklist channels. >> Does 6tus need to provide a command to do that? Specially if >> blacklisting is dynamic, 6tus needs to reallocate softlinks from that >> channels that have been blacklisted. >> >> regards, >> X >> _______________________________________________ >> 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 > Return-Path: 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 04A9D21F8FD1 for <6tsch@ietfa.amsl.com>; Fri, 22 Mar 2013 11:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.504 X-Spam-Level: X-Spam-Status: No, score=-6.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 4d68nX1OrTfC for <6tsch@ietfa.amsl.com>; Fri, 22 Mar 2013 11:44:25 -0700 (PDT) Received: from cm04fe.IST.Berkeley.EDU (cm04fe.IST.Berkeley.EDU [169.229.218.145]) by ietfa.amsl.com (Postfix) with ESMTP id 62D6F21F8F81 for <6tsch@ietf.org>; Fri, 22 Mar 2013 11:44:25 -0700 (PDT) Received: from cm02ws.ist.berkeley.edu ([169.229.218.164] helo=calmail.berkeley.edu) by cm04fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth login:qinwang@berkeley.edu) (envelope-from ) id 1UJ6ww-0005Rs-DG; Fri, 22 Mar 2013 11:44:23 -0700 Received: from 96.227.54.17 (SquirrelMail authenticated user qinwang@berkeley.edu) by calmail.berkeley.edu with HTTP; Fri, 22 Mar 2013 11:44:22 -0700 Message-ID: <42dbecb254249a1c138266265c0f501a.squirrel@calmail.berkeley.edu> In-Reply-To: References: <514C86C1.9000202@eecs.berkeley.edu> <514C9325.7070507@eecs.berkeley.edu> <514C9B41.9060403@eecs.berkeley.edu> Date: Fri, 22 Mar 2013 11:44:22 -0700 From: "Qin Wang" To: "Qin Wang" User-Agent: SquirrelMail/1.4.21-2.berkeley MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: "6tsch@ietf.org" <6tsch@ietf.org>, "Pascal Thubert \(pthubert\)" , Qin Wang , Xavier Vilajosana Subject: Re: [6tsch] blacklisting support on 6tus 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 18:44:26 -0000 + More. During a network running, TSCH WPAN coordinator can change its blacklist according to the link quality report from nodes in the network. And, still, the new blacklist and other information about channel hopping is carried in channel hopping IE and propagated to the entire LLN. Qin > > At the beginning, the PIB of TSCH WPAN coordinator is configured, > including channel hopping attributes. Then, for a new joining node, after > it receives EB, the channel hopping IE should be given to MAC layer, i.e. > TSCH, and TSCH will be in charge to set its channel hopping related > attributes in PIB. > > Make sense? > > Qin > > > >> so who tells to the mac layer what channels need to be blacklisted? >> >> does the mac layer decide by itself? >> >> X >> >> On 22/03/13 10:52, Qin Wang wrote: >>> Xavi and all, >>> >>> If we agree that the blacklist is LLN wide, then the Channel Hopping IE >>> (defined by IEEE802.15.4e, instead of by 6tus) in EB will propagate the >>> validate physical channels. That means it is unnecessary for 6tus to >>> provide commands to set/get physical channels in blacklist. >>> >>> Does it make sense? >>> >>> Qin >>> >>> >>> >>>> Hi all, >>>> >>>> I agree, my only concern is that if 6tus layer provides commands to >>>> the >>>> management entity, blacklisting commands might be there for >>>> completeness. >>>> >>>> regards, >>>> Xavi >>>> On 22/03/13 10:07, Pascal Thubert (pthubert) wrote: >>>>> Hello Xavi. >>>>> >>>>> There is an interface to the network management and blacklist and >>>>> whitelist are typical methods. >>>>> I'm unsure how deep we want to go in that sort of things in the 6TUS >>>>> draft. >>>>> Certainly we cannot cover everything and we want to be extensible. >>>>> >>>>> Cheers, >>>>> >>>>> Pascal >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On >>>>> Behalf >>>>> Of Xavier Vilajosana >>>>> Sent: vendredi 22 mars 2013 17:29 >>>>> To: 6tsch@ietf.org >>>>> Subject: [6tsch] blacklisting support on 6tus >>>>> >>>>> From the discussion today I've detected the need to blacklist >>>>> channels. >>>>> Does 6tus need to provide a command to do that? Specially if >>>>> blacklisting is dynamic, 6tus needs to reallocate softlinks from that >>>>> channels that have been blacklisted. >>>>> >>>>> regards, >>>>> X >>>>> _______________________________________________ >>>>> 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 >>>> >>> >> >> > > > Return-Path: 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 7577921F8FA3 for <6tsch@ietfa.amsl.com>; Fri, 22 Mar 2013 11:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 IFxJswU0M848 for <6tsch@ietfa.amsl.com>; Fri, 22 Mar 2013 11:11:29 -0700 (PDT) Received: from cm05fe.IST.Berkeley.EDU (cm05fe.IST.Berkeley.EDU [169.229.218.146]) by ietfa.amsl.com (Postfix) with ESMTP id DF95821F8B45 for <6tsch@ietf.org>; Fri, 22 Mar 2013 11:11:29 -0700 (PDT) Received: from cm02ws.ist.berkeley.edu ([169.229.218.164] helo=calmail.berkeley.edu) by cm05fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth login:qinwang@berkeley.edu) (envelope-from ) id 1UJ6R6-0000Jy-Gj; Fri, 22 Mar 2013 11:11:29 -0700 Received: from 96.227.54.17 (SquirrelMail authenticated user qinwang@berkeley.edu) by calmail.berkeley.edu with HTTP; Fri, 22 Mar 2013 11:11:28 -0700 Message-ID: In-Reply-To: <514C9B41.9060403@eecs.berkeley.edu> References: <514C86C1.9000202@eecs.berkeley.edu> <514C9325.7070507@eecs.berkeley.edu> <514C9B41.9060403@eecs.berkeley.edu> Date: Fri, 22 Mar 2013 11:11:28 -0700 From: "Qin Wang" To: "Xavier Vilajosana" User-Agent: SquirrelMail/1.4.21-2.berkeley MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: "Pascal Thubert \(pthubert\)" , "6tsch@ietf.org" <6tsch@ietf.org>, Qin Wang Subject: Re: [6tsch] blacklisting support on 6tus 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 18:11:30 -0000 At the beginning, the PIB of TSCH WPAN coordinator is configured, including channel hopping attributes. Then, for a new joining node, after it receives EB, the channel hopping IE should be given to MAC layer, i.e. TSCH, and TSCH will be in charge to set its channel hopping related attributes in PIB. Make sense? Qin > so who tells to the mac layer what channels need to be blacklisted? > > does the mac layer decide by itself? > > X > > On 22/03/13 10:52, Qin Wang wrote: >> Xavi and all, >> >> If we agree that the blacklist is LLN wide, then the Channel Hopping IE >> (defined by IEEE802.15.4e, instead of by 6tus) in EB will propagate the >> validate physical channels. That means it is unnecessary for 6tus to >> provide commands to set/get physical channels in blacklist. >> >> Does it make sense? >> >> Qin >> >> >> >>> Hi all, >>> >>> I agree, my only concern is that if 6tus layer provides commands to the >>> management entity, blacklisting commands might be there for >>> completeness. >>> >>> regards, >>> Xavi >>> On 22/03/13 10:07, Pascal Thubert (pthubert) wrote: >>>> Hello Xavi. >>>> >>>> There is an interface to the network management and blacklist and >>>> whitelist are typical methods. >>>> I'm unsure how deep we want to go in that sort of things in the 6TUS >>>> draft. >>>> Certainly we cannot cover everything and we want to be extensible. >>>> >>>> Cheers, >>>> >>>> Pascal >>>> >>>> >>>> -----Original Message----- >>>> From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf >>>> Of Xavier Vilajosana >>>> Sent: vendredi 22 mars 2013 17:29 >>>> To: 6tsch@ietf.org >>>> Subject: [6tsch] blacklisting support on 6tus >>>> >>>> From the discussion today I've detected the need to blacklist >>>> channels. >>>> Does 6tus need to provide a command to do that? Specially if >>>> blacklisting is dynamic, 6tus needs to reallocate softlinks from that >>>> channels that have been blacklisted. >>>> >>>> regards, >>>> X >>>> _______________________________________________ >>>> 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 >>> >> > > Return-Path: 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 2E80021F85A4 for <6tsch@ietfa.amsl.com>; Fri, 22 Mar 2013 10:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 4XfKNaJ63Wom for <6tsch@ietfa.amsl.com>; Fri, 22 Mar 2013 10:56:19 -0700 (PDT) Received: from cm02fe.IST.Berkeley.EDU (cm02fe.IST.Berkeley.EDU [169.229.218.143]) by ietfa.amsl.com (Postfix) with ESMTP id A2D9821F8444 for <6tsch@ietf.org>; Fri, 22 Mar 2013 10:56:19 -0700 (PDT) Received: from dhcp-33-135.eecs.berkeley.edu ([128.32.33.135]) by cm02fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:xvilajosana@eecs.berkeley.edu) (envelope-from ) id 1UJ6CQ-0003QK-7B; Fri, 22 Mar 2013 10:56:19 -0700 Message-ID: <514C9B41.9060403@eecs.berkeley.edu> Date: Fri, 22 Mar 2013 10:56:17 -0700 From: Xavier Vilajosana User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: Qin Wang References: <514C86C1.9000202@eecs.berkeley.edu> <514C9325.7070507@eecs.berkeley.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "Pascal Thubert \(pthubert\)" , "6tsch@ietf.org" <6tsch@ietf.org> Subject: Re: [6tsch] blacklisting support on 6tus 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 17:56:20 -0000 so who tells to the mac layer what channels need to be blacklisted? does the mac layer decide by itself? X On 22/03/13 10:52, Qin Wang wrote: > Xavi and all, > > If we agree that the blacklist is LLN wide, then the Channel Hopping IE > (defined by IEEE802.15.4e, instead of by 6tus) in EB will propagate the > validate physical channels. That means it is unnecessary for 6tus to > provide commands to set/get physical channels in blacklist. > > Does it make sense? > > Qin > > > >> Hi all, >> >> I agree, my only concern is that if 6tus layer provides commands to the >> management entity, blacklisting commands might be there for completeness. >> >> regards, >> Xavi >> On 22/03/13 10:07, Pascal Thubert (pthubert) wrote: >>> Hello Xavi. >>> >>> There is an interface to the network management and blacklist and >>> whitelist are typical methods. >>> I'm unsure how deep we want to go in that sort of things in the 6TUS >>> draft. >>> Certainly we cannot cover everything and we want to be extensible. >>> >>> Cheers, >>> >>> Pascal >>> >>> >>> -----Original Message----- >>> From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf >>> Of Xavier Vilajosana >>> Sent: vendredi 22 mars 2013 17:29 >>> To: 6tsch@ietf.org >>> Subject: [6tsch] blacklisting support on 6tus >>> >>> From the discussion today I've detected the need to blacklist >>> channels. >>> Does 6tus need to provide a command to do that? Specially if >>> blacklisting is dynamic, 6tus needs to reallocate softlinks from that >>> channels that have been blacklisted. >>> >>> regards, >>> X >>> _______________________________________________ >>> 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 >> > Return-Path: 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 3F7CD21F8444 for <6tsch@ietfa.amsl.com>; Fri, 22 Mar 2013 10:52:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.493 X-Spam-Level: X-Spam-Status: No, score=-6.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 76uAp0zgVb2M for <6tsch@ietfa.amsl.com>; Fri, 22 Mar 2013 10:52:49 -0700 (PDT) Received: from cm03fe.IST.Berkeley.EDU (cm03fe.IST.Berkeley.EDU [169.229.218.144]) by ietfa.amsl.com (Postfix) with ESMTP id C62D921F84B9 for <6tsch@ietf.org>; Fri, 22 Mar 2013 10:52:33 -0700 (PDT) Received: from cm02ws.ist.berkeley.edu ([169.229.218.164] helo=calmail.berkeley.edu) by cm03fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth login:qinwang@berkeley.edu) (envelope-from ) id 1UJ68k-0008Qt-C2; Fri, 22 Mar 2013 10:52:32 -0700 Received: from 96.227.54.17 (SquirrelMail authenticated user qinwang@berkeley.edu) by calmail.berkeley.edu with HTTP; Fri, 22 Mar 2013 10:52:30 -0700 Message-ID: In-Reply-To: <514C9325.7070507@eecs.berkeley.edu> References: <514C86C1.9000202@eecs.berkeley.edu> <514C9325.7070507@eecs.berkeley.edu> Date: Fri, 22 Mar 2013 10:52:30 -0700 From: "Qin Wang" To: "Xavier Vilajosana" User-Agent: SquirrelMail/1.4.21-2.berkeley MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: "Pascal Thubert \(pthubert\)" , "6tsch@ietf.org" <6tsch@ietf.org> Subject: Re: [6tsch] blacklisting support on 6tus 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 17:52:50 -0000 Xavi and all, If we agree that the blacklist is LLN wide, then the Channel Hopping IE (defined by IEEE802.15.4e, instead of by 6tus) in EB will propagate the validate physical channels. That means it is unnecessary for 6tus to provide commands to set/get physical channels in blacklist. Does it make sense? Qin > Hi all, > > I agree, my only concern is that if 6tus layer provides commands to the > management entity, blacklisting commands might be there for completeness. > > regards, > Xavi > On 22/03/13 10:07, Pascal Thubert (pthubert) wrote: >> Hello Xavi. >> >> There is an interface to the network management and blacklist and >> whitelist are typical methods. >> I'm unsure how deep we want to go in that sort of things in the 6TUS >> draft. >> Certainly we cannot cover everything and we want to be extensible. >> >> Cheers, >> >> Pascal >> >> >> -----Original Message----- >> From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf >> Of Xavier Vilajosana >> Sent: vendredi 22 mars 2013 17:29 >> To: 6tsch@ietf.org >> Subject: [6tsch] blacklisting support on 6tus >> >> From the discussion today I've detected the need to blacklist >> channels. >> Does 6tus need to provide a command to do that? Specially if >> blacklisting is dynamic, 6tus needs to reallocate softlinks from that >> channels that have been blacklisted. >> >> regards, >> X >> _______________________________________________ >> 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 > Return-Path: 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 C3F8121F8E58 for <6tsch@ietfa.amsl.com>; Fri, 22 Mar 2013 10:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.399 X-Spam-Level: X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 VPzkhdURocx4 for <6tsch@ietfa.amsl.com>; Fri, 22 Mar 2013 10:21:42 -0700 (PDT) Received: from cm06fe.IST.Berkeley.EDU (cm06fe.IST.Berkeley.EDU [169.229.218.147]) by ietfa.amsl.com (Postfix) with ESMTP id 2BA9621F8CF9 for <6tsch@ietf.org>; Fri, 22 Mar 2013 10:21:42 -0700 (PDT) Received: from dhcp-33-135.eecs.berkeley.edu ([128.32.33.135]) by cm06fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:xvilajosana@eecs.berkeley.edu) (envelope-from ) id 1UJ5ev-0001hH-Jz; Fri, 22 Mar 2013 10:21:42 -0700 Message-ID: <514C9325.7070507@eecs.berkeley.edu> Date: Fri, 22 Mar 2013 10:21:41 -0700 From: Xavier Vilajosana User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <514C86C1.9000202@eecs.berkeley.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "6tsch@ietf.org" <6tsch@ietf.org> Subject: Re: [6tsch] blacklisting support on 6tus 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 17:21:42 -0000 Hi all, I agree, my only concern is that if 6tus layer provides commands to the management entity, blacklisting commands might be there for completeness. regards, Xavi On 22/03/13 10:07, Pascal Thubert (pthubert) wrote: > Hello Xavi. > > There is an interface to the network management and blacklist and whitelist are typical methods. > I'm unsure how deep we want to go in that sort of things in the 6TUS draft. > Certainly we cannot cover everything and we want to be extensible. > > Cheers, > > Pascal > > > -----Original Message----- > From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of Xavier Vilajosana > Sent: vendredi 22 mars 2013 17:29 > To: 6tsch@ietf.org > Subject: [6tsch] blacklisting support on 6tus > > From the discussion today I've detected the need to blacklist channels. > Does 6tus need to provide a command to do that? Specially if blacklisting is dynamic, 6tus needs to reallocate softlinks from that channels that have been blacklisted. > > regards, > X > _______________________________________________ > 6tsch mailing list > 6tsch@ietf.org > https://www.ietf.org/mailman/listinfo/6tsch Return-Path: 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 D71E621F8B20 for <6tsch@ietfa.amsl.com>; Fri, 22 Mar 2013 10:07:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.513 X-Spam-Level: X-Spam-Status: No, score=-10.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 aa-irGT1RXB0 for <6tsch@ietfa.amsl.com>; Fri, 22 Mar 2013 10:07:54 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 4A35321F85B4 for <6tsch@ietf.org>; Fri, 22 Mar 2013 10:07:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=914; q=dns/txt; s=iport; t=1363972074; x=1365181674; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=cUJPmBi+NjDRf7DMgAH/vjlWjfhdP/gTBsaKyA9JUPA=; b=jZawyByRWLggy61AlEhg5XXTgHRqv6HIkidU7V6dpa/8ypjqhetgDu1L exHPH2tslHnc3S/06VLehShqIA/0qK46uEoiId8MZ/jr7DoBXvr45yk4V 2vWvmK0TkoDzdbcVSIc9czi3l3XWEp58U1xEymNVokwoHRX4TE+V/TjfW Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoYFAE2PTFGtJV2c/2dsb2JhbABDDodYvW6BZRZ0giQBAQEEAQEBNzQXBAIBCA4DBAEBCxQJBycLFAkIAgQBEgiIDAzCJQSOYTgGgllhA6dogks/gig X-IronPort-AV: E=Sophos;i="4.84,893,1355097600"; d="scan'208,223";a="187477756" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP; 22 Mar 2013 17:07:54 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r2MH7rCd009663 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Mar 2013 17:07:53 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.152]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Fri, 22 Mar 2013 12:07:53 -0500 From: "Pascal Thubert (pthubert)" To: Xavier Vilajosana , "6tsch@ietf.org" <6tsch@ietf.org> Thread-Topic: [6tsch] blacklisting support on 6tus Thread-Index: AQHOJxpyQp7UqivFCkSTT1SuiNmYwZix8GhA Date: Fri, 22 Mar 2013 17:07:53 +0000 Deferred-Delivery: Fri, 22 Mar 2013 17:07:00 +0000 Message-ID: References: <514C86C1.9000202@eecs.berkeley.edu> In-Reply-To: <514C86C1.9000202@eecs.berkeley.edu> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.85.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [6tsch] blacklisting support on 6tus 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 17:07:54 -0000 Hello Xavi. There is an interface to the network management and blacklist and whitelist= are typical methods. I'm unsure how deep we want to go in that sort of things in the 6TUS draft. Certainly we cannot cover everything and we want to be extensible. Cheers,=20 Pascal -----Original Message----- From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of X= avier Vilajosana Sent: vendredi 22 mars 2013 17:29 To: 6tsch@ietf.org Subject: [6tsch] blacklisting support on 6tus From the discussion today I've detected the need to blacklist channels.=20 Does 6tus need to provide a command to do that? Specially if blacklisting i= s dynamic, 6tus needs to reallocate softlinks from that channels that have = been blacklisted. regards, X _______________________________________________ 6tsch mailing list 6tsch@ietf.org https://www.ietf.org/mailman/listinfo/6tsch Return-Path: 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 B60BA21F858A for <6tsch@ietfa.amsl.com>; Fri, 22 Mar 2013 10:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.523 X-Spam-Level: X-Spam-Status: No, score=-6.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 11dPLMY8EhUR for <6tsch@ietfa.amsl.com>; Fri, 22 Mar 2013 10:07:20 -0700 (PDT) Received: from hercules.uni.lu (hercules.uni.lu [158.64.76.33]) by ietfa.amsl.com (Postfix) with ESMTP id C9F6D21F85B0 for <6tsch@ietf.org>; Fri, 22 Mar 2013 10:07:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,893,1355094000"; d="scan'208,217";a="23077899" Received: from unknown (HELO REED.uni.lux) ([10.21.2.9]) by hercules.uni.lu with ESMTP; 22 Mar 2013 18:07:19 +0100 Received: from HOSHI.uni.lux ([fe80::499:a33:4e68:4af9]) by REED.uni.lux ([fe80::31bb:b7a3:7abb:813e%10]) with mapi id 14.01.0438.000; Fri, 22 Mar 2013 18:07:18 +0100 From: Maria Rita PALATTELLA To: Thomas Watteyne , "6tsch@ietf.org" <6tsch@ietf.org> Thread-Topic: [6tsch] blacklisting support on 6tus Thread-Index: AQHOJxpqQp7UqivFCkSTT1SuiNmYwZix3OMAgAABdYCAABIMCw== Date: Fri, 22 Mar 2013 17:07:18 +0000 Message-ID: References: <514C86C1.9000202@eecs.berkeley.edu> <671d1cf041282cca812b4ae600b998a0.squirrel@calmail.berkeley.edu>, In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.34.0.8] Content-Type: multipart/alternative; boundary="_000_F085911F642A6847987ADA23E611780D185356FBhoshiunilux_" MIME-Version: 1.0 Subject: Re: [6tsch] blacklisting support on 6tus 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 17:07:21 -0000 --_000_F085911F642A6847987ADA23E611780D185356FBhoshiunilux_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Xavi, all, 6tus allocates soft/hard cells, that are function of the channelOffset. The number of available channelOffset is equal to the number of available P= HY channels. The blacklist affects the PHY channel (i.e., frequency) that is actually us= ed for the transmission. Thus, in case of balcklisting, if the number of available channels (i.e., t= he size of the blacklist doesn't change), then 6tus will not need to reallo= cate the soft cells. The channel offset will be translated in a different PHY channel, based on = the list of available frequencies. Only if the size of the blacklist changes, then, 6tus will need to realloca= te soft cells. In any case, 6tus may needs to provide a command for knowing abut the black= list and thus, the set of available channels. Does this make sense to you? Maria Rita ________________________________ From: 6tsch-bounces@ietf.org [6tsch-bounces@ietf.org] on behalf of Thomas W= atteyne [watteyne@eecs.berkeley.edu] Sent: Friday, March 22, 2013 5:59 PM To: 6tsch@ietf.org Subject: Re: [6tsch] blacklisting support on 6tus IEEE802.15.4e supports blacklisting of one of more frequencies for the whol= e network, as per http://tools.ietf.org/html/draft-watteyne-6tsch-tsch-lln-= context-01#appendix-A.7. We could add a command in 6tus to drive that, but I would keep the blacklis= ting behavior of IEEE802.15.4e, i.e. LLN-wide. Thomas On Fri, Mar 22, 2013 at 9:54 AM, Qin Wang > wrote: Xavi and all, When we talk about blacklist, the assumption is the blacklist is LLN wide, or inside of a subnet, or just pair of nodes? In WirelessHart and ISA100, blacklist seems LLN wide. Qin > From the discussion today I've detected the need to blacklist channels. > Does 6tus need to provide a command to do that? Specially if > blacklisting is dynamic, 6tus needs to reallocate softlinks from that > channels that have been blacklisted. > > regards, > X > _______________________________________________ > 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 --_000_F085911F642A6847987ADA23E611780D185356FBhoshiunilux_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Xavi, all,
6tus allocates soft/hard cells, that are function of the channelOffset.
The number of available channelOffset is equal to the number of available P= HY channels.
The blacklist affects the PHY channel (i.e., frequency) that is actually us= ed for the transmission. 
Thus, in case of balcklisting, if the number of available channels (i.e., t= he size of the blacklist doesn't change), then 6tus will not need to reallo= cate the soft cells.
The channel offset will be translated in a different PHY channel, based on = the list of available frequencies.
Only if the size of the blacklist changes, then, 6tus will need to realloca= te soft cells.
In any case, 6tus may needs to provide a command for knowing abut the black= list and thus, the set of available channels.
Does this make sense to you?
Maria Rita

From: 6tsch-bounces@ietf.org [6tsch-bounc= es@ietf.org] on behalf of Thomas Watteyne [watteyne@eecs.berkeley.edu]
Sent: Friday, March 22, 2013 5:59 PM
To: 6tsch@ietf.org
Subject: Re: [6tsch] blacklisting support on 6tus

IEEE802.15.4e supports blacklisting of one of more frequencies for the= whole network, as per http://tool= s.ietf.org/html/draft-watteyne-6tsch-tsch-lln-context-01#appendix-A.7.
We could add a command in 6tus to drive that, but I would keep the bla= cklisting behavior of IEEE802.15.4e, i.e. LLN-wide.
Thomas

On Fri, Mar 22, 2013 at 9:54 AM, Qin Wang <qinwang@berke= ley.edu> wrote:
Xavi and all,

When we talk about blacklist, the assumption is the blacklist is LLN wide,<= br> or inside of a subnet, or just pair of nodes? In WirelessHart and ISA100, blacklist seems LLN wide.

Qin


>  From the discussion today I've detected the need to blacklist ch= annels.
> Does 6tus need to provide a command to do that? Specially if
> blacklisting is dynamic, 6tus needs to reallocate softlinks from that<= br> > channels that have been blacklisted.
>
> regards,
> X
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org=
> https://www.ietf.org/mailman/listinfo/6tsch
>


_______________________________________________
6tsch mailing list
6tsch@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/6tsch
<= /a>
--_000_F085911F642A6847987ADA23E611780D185356FBhoshiunilux_-- Return-Path: 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 3A1FE21F8E6B for <6tsch@ietfa.amsl.com>; Fri, 22 Mar 2013 10:00:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 ksIzg9i38WjF for <6tsch@ietfa.amsl.com>; Fri, 22 Mar 2013 10:00:08 -0700 (PDT) Received: from mail-da0-x232.google.com (mail-da0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 6856621F87D9 for <6tsch@ietf.org>; Fri, 22 Mar 2013 10:00:08 -0700 (PDT) Received: by mail-da0-f50.google.com with SMTP id t1so856690dae.9 for <6tsch@ietf.org>; Fri, 22 Mar 2013 10:00:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=LHq8KvTXrzCLe0j7xzrTgvT/ERMpGKPqzVnT3UnOMGo=; b=aNFPtjiq8rR7BHUqs77iewcU94PBZVYxOFMsuXf9ssXd0u5P1uaMDe3rGSoe0dEqYz O8NV0bWPTDBWkV0N6FgGBeu+FL1NF3wqSI2g72FI4eDg30/ogAAlla9aecyrp0MlcDQa hpJ//8BiqADlWxGal0/mg64u7Mciue6GZOEHySV54TyhDGsJH6cgW15dYENdBYoqimfO m96GPxgweNeU5u5dw6W3AjjA7eoXHXB6LQ2195eIFAUYmIWts7StLH5Ekusi2HbQR6gp smCNngCe2waPYViTWr0Js1U0HIyI9xT4ITiExUvluTOVgoJqTcy80cVZSLxpT3MSpM+K BkOw== X-Received: by 10.68.248.66 with SMTP id yk2mr3775600pbc.38.1363971608098; Fri, 22 Mar 2013 10:00:08 -0700 (PDT) MIME-Version: 1.0 Sender: twatteyne@gmail.com Received: by 10.68.227.71 with HTTP; Fri, 22 Mar 2013 09:59:47 -0700 (PDT) In-Reply-To: <671d1cf041282cca812b4ae600b998a0.squirrel@calmail.berkeley.edu> References: <514C86C1.9000202@eecs.berkeley.edu> <671d1cf041282cca812b4ae600b998a0.squirrel@calmail.berkeley.edu> From: Thomas Watteyne Date: Fri, 22 Mar 2013 09:59:47 -0700 X-Google-Sender-Auth: sJy5stQHXP95dvisPhdMoSeQifE Message-ID: To: "6tsch@ietf.org" <6tsch@ietf.org> Content-Type: multipart/alternative; boundary=047d7b33919f2f3fcd04d8866347 Subject: Re: [6tsch] blacklisting support on 6tus 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 17:00:09 -0000 --047d7b33919f2f3fcd04d8866347 Content-Type: text/plain; charset=ISO-8859-1 IEEE802.15.4e supports blacklisting of one of more frequencies for the whole network, as per http://tools.ietf.org/html/draft-watteyne-6tsch-tsch-lln-context-01#appendix-A.7 . We could add a command in 6tus to drive that, but I would keep the blacklisting behavior of IEEE802.15.4e, i.e. LLN-wide. Thomas On Fri, Mar 22, 2013 at 9:54 AM, Qin Wang wrote: > Xavi and all, > > When we talk about blacklist, the assumption is the blacklist is LLN wide, > or inside of a subnet, or just pair of nodes? In WirelessHart and ISA100, > blacklist seems LLN wide. > > Qin > > > > From the discussion today I've detected the need to blacklist channels. > > Does 6tus need to provide a command to do that? Specially if > > blacklisting is dynamic, 6tus needs to reallocate softlinks from that > > channels that have been blacklisted. > > > > regards, > > X > > _______________________________________________ > > 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 > > --047d7b33919f2f3fcd04d8866347 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable IEEE802.15.4e supports blacklisting of one of more frequencies for the whol= e network, as per=A0http://tools.ietf.org/html/draft-watt= eyne-6tsch-tsch-lln-context-01#appendix-A.7.
We could add a command in 6tus to drive that, but I would keep the blacklis= ting behavior of IEEE802.15.4e, i.e. LLN-wide.
Thomas
On Fri, Mar 22, 2013 at 9:54 AM, Qin Wang <= qinwang@berkeley.edu> wrote:
Xavi and all,

When we talk about blacklist, the assumption is the blacklist is LLN wide,<= br> or inside of a subnet, or just pair of nodes? In WirelessHart and ISA100, blacklist seems LLN wide.

Qin


> =A0From the discussion today I've detected the need to blacklist c= hannels.
> Does 6tus need to provide a command to do that? Specially if
> blacklisting is dynamic, 6tus needs to reallocate softlinks from that<= br> > channels that have been blacklisted.
>
> regards,
> X
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org=
> https://www.ietf.org/mailman/listinfo/6tsch
>


_______________________________________________
6tsch mailing list
6tsch@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/6tsch
--047d7b33919f2f3fcd04d8866347-- Return-Path: 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 A9F6E21F8DCF for <6tsch@ietfa.amsl.com>; Fri, 22 Mar 2013 09:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.486 X-Spam-Level: X-Spam-Status: No, score=-6.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 vyVTo2rjeOdj for <6tsch@ietfa.amsl.com>; Fri, 22 Mar 2013 09:54:35 -0700 (PDT) Received: from cm04fe.IST.Berkeley.EDU (cm04fe.IST.Berkeley.EDU [169.229.218.145]) by ietfa.amsl.com (Postfix) with ESMTP id 34B2021F8C7D for <6tsch@ietf.org>; Fri, 22 Mar 2013 09:54:35 -0700 (PDT) Received: from cm02ws.ist.berkeley.edu ([169.229.218.164] helo=calmail.berkeley.edu) by cm04fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth login:qinwang@berkeley.edu) (envelope-from ) id 1UJ5Eg-0003PJ-DQ; Fri, 22 Mar 2013 09:54:35 -0700 Received: from 96.227.54.17 (SquirrelMail authenticated user qinwang@berkeley.edu) by calmail.berkeley.edu with HTTP; Fri, 22 Mar 2013 09:54:34 -0700 Message-ID: <671d1cf041282cca812b4ae600b998a0.squirrel@calmail.berkeley.edu> In-Reply-To: <514C86C1.9000202@eecs.berkeley.edu> References: <514C86C1.9000202@eecs.berkeley.edu> Date: Fri, 22 Mar 2013 09:54:34 -0700 From: "Qin Wang" To: "Xavier Vilajosana" User-Agent: SquirrelMail/1.4.21-2.berkeley MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: "6tsch@ietf.org" <6tsch@ietf.org> Subject: Re: [6tsch] blacklisting support on 6tus 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 16:54:35 -0000 Xavi and all, When we talk about blacklist, the assumption is the blacklist is LLN wide, or inside of a subnet, or just pair of nodes? In WirelessHart and ISA100, blacklist seems LLN wide. Qin > From the discussion today I've detected the need to blacklist channels. > Does 6tus need to provide a command to do that? Specially if > blacklisting is dynamic, 6tus needs to reallocate softlinks from that > channels that have been blacklisted. > > regards, > X > _______________________________________________ > 6tsch mailing list > 6tsch@ietf.org > https://www.ietf.org/mailman/listinfo/6tsch > Return-Path: 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 D266021F8E79 for <6tsch@ietfa.amsl.com>; Fri, 22 Mar 2013 09:29:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 eFnDwRd-Hewa for <6tsch@ietfa.amsl.com>; Fri, 22 Mar 2013 09:29:20 -0700 (PDT) Received: from cm04fe.IST.Berkeley.EDU (cm04fe.IST.Berkeley.EDU [169.229.218.145]) by ietfa.amsl.com (Postfix) with ESMTP id 6339F21F8BA1 for <6tsch@ietf.org>; Fri, 22 Mar 2013 09:29:20 -0700 (PDT) Received: from c-67-188-198-243.hsd1.ca.comcast.net ([67.188.198.243] helo=[192.168.2.4]) by cm04fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:xvilajosana@eecs.berkeley.edu) (envelope-from ) id 1UJ4pp-0007y1-Ed for 6tsch@ietf.org; Fri, 22 Mar 2013 09:28:55 -0700 Message-ID: <514C86C1.9000202@eecs.berkeley.edu> Date: Fri, 22 Mar 2013 09:28:49 -0700 From: Xavier Vilajosana User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: "6tsch@ietf.org" <6tsch@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [6tsch] blacklisting support on 6tus 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 16:29:20 -0000 From the discussion today I've detected the need to blacklist channels. Does 6tus need to provide a command to do that? Specially if blacklisting is dynamic, 6tus needs to reallocate softlinks from that channels that have been blacklisted. regards, X Return-Path: 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 3B5C721F8BA1 for <6tsch@ietfa.amsl.com>; Fri, 22 Mar 2013 09:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 ToNSvmI7q+FG for <6tsch@ietfa.amsl.com>; Fri, 22 Mar 2013 09:27:32 -0700 (PDT) Received: from cm03fe.IST.Berkeley.EDU (cm03fe.IST.Berkeley.EDU [169.229.218.144]) by ietfa.amsl.com (Postfix) with ESMTP id BDD2821F8A7E for <6tsch@ietf.org>; Fri, 22 Mar 2013 09:27:32 -0700 (PDT) Received: from c-67-188-198-243.hsd1.ca.comcast.net ([67.188.198.243] helo=[192.168.2.4]) by cm03fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:xvilajosana@eecs.berkeley.edu) (envelope-from ) id 1UJ4oQ-000757-CE for 6tsch@ietf.org; Fri, 22 Mar 2013 09:27:27 -0700 Message-ID: <514C866A.6070105@eecs.berkeley.edu> Date: Fri, 22 Mar 2013 09:27:22 -0700 From: Xavier Vilajosana User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: "6tsch@ietf.org" <6tsch@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [6tsch] workers use case 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 16:27:33 -0000 As regards to the workers case introduced today I want to point out that there is a potential impact on the energy consumption of the network depending on what solution is chosen. + if we relay on RPL to route packets from moving workers, this means that RPL control is fast enough so workers can position the worker in the routing topology, this means that DIO activity is fast incrementing the the energy consumption of the network. + if we relay on over-provisioned cells at each potential node that might be in contact with a worker, we suffer from idle-listening most of the times. the key aspect is to find the crossing point between these 2 scenarios so the energy consumption is not compromised too much. Another aspect to take into account is EBs periodicity as mobile nodes need to keep joining to new parents as they move. The period of EBs then is also compromised by mobility. just two things to be considered. regards, Xavi Return-Path: 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 2117121F85CE; Fri, 22 Mar 2013 07:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_HI=-8] 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 mqh5yibOBr62; Fri, 22 Mar 2013 07:26:15 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 490AB21F85BC; Fri, 22 Mar 2013 07:26:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16450; q=dns/txt; s=iport; t=1363962375; x=1365171975; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=A53zmXCZplOta3wNpb/gcTI0Pqh0yY1kHfGa5xfJrCQ=; b=i18C56w2oCZtr+R8DshwPbYrYFoNkSORYIqzCUqm8rYO6h+i+X4Ag5BX JGYE3s5uYiReWkDLcwY8x+bnx93aGX2XSxq96QFdTqexx790M26tnd7xO GBPnQ/Rs2jnramjBxbTUgoODOgu2csqb0mQnohTfugktgXtL3KMZ5Ec68 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAARpTFGtJV2d/2dsb2JhbABDDogdvSRzcBZ0giQBAQEDAQEBASAROgsFBwQCAQgRAQMBAQECAgYdAwICAiULFAECBggBAQQOBQgTh3MGDLABkikEgSOMJoEYJgsHBoInMmEDkx6USoJLP4Io X-IronPort-AV: E=Sophos;i="4.84,891,1355097600"; d="scan'208";a="190408866" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP; 22 Mar 2013 14:26:14 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r2MEQEIO019904 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Mar 2013 14:26:14 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.152]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0318.004; Fri, 22 Mar 2013 09:26:14 -0500 From: "Pascal Thubert (pthubert)" To: Qin Wang Thread-Topic: Interaction between NME and PCE Thread-Index: Ac4m1AAaAig2JGZERcC75DTjyWBvYAAWhQEAAAnM52A= Date: Fri, 22 Mar 2013 14:26:13 +0000 Deferred-Delivery: Fri, 22 Mar 2013 14:25:00 +0000 Message-ID: References: <923b8183e356e136c19df594200bf6f8.squirrel@calmail.berkeley.edu> In-Reply-To: <923b8183e356e136c19df594200bf6f8.squirrel@calmail.berkeley.edu> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.85.19] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Thomas Watteyne , "coman@ietf.org" , IETF 6TSCH <6tsch@ietf.org> Subject: Re: [6tsch] Interaction between NME and PCE 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 14:26:17 -0000 SGVsbG8gUWluOg0KDQpJIHVzZSBOTUUgYXMgdGhlIGNvbW1vbiBuYW1lIGZvciB0aGUgTmV0d29y ayBNYW5hZ2VtZW50IEVudGl0eS4gQ05NIGlzIG1vcmUgc3BlY2lmaWMsIGl0IGlzIGEgcGFydGlj dWxhciBncm91cCwgV0cyMCBhdCBJU0ExMDAgKHRodXMgSVNBMTAwLjIwKS4NCklTQTEwMC4yMCBD Tk0gd2lsbCBkZWZpbmUgYW4gYWJzdHJhY3QgbWFuYWdlciBvZiBtYW5hZ2Vycy4gQSBDTk0gRW50 aXR5IHNob3VsZCBiZSBhYmxlIHRvIHRhbGsgaW4gYSB1bmlmaWVkIGZhc2hpb24gdG8gTk1FcyBm cm9tIGRpZmZlcmVudCBvcmlnaW5zLCBsaWtlIElTQTEwMC4xMWEsIFdJQVBBIG9yIHdpSEFSVCAo b3IgQ09NQU4pLiBUaGUgaWRlYSBiZWluZyB0aGF0IHRoZSBhZG1pbiBjYW4gZG8gdGhpbmdzIG9u Y2UgYXQgdGhlIENOTSBsZXZlbCBhbmQgdGhlbiBnZXQgdGhlIGV4ZWN1dGlvbiBkaXN0cmlidXRl ZCB0aHJvdWdoIHRoZSBtb3JlIHNwZWNpZmljIE5NRXMgZm9yIHRoZSBwYXJ0aWN1bGFyIG5ldHdv cmtzIHRoYXQgdGhleSBjYW4gaGFuZGxlLiANCg0KTXkgZ29hbCB3aXRoIENOTSB3b3VsZCBiZSB0 aGF0IHRoZSBDTk0gZm9ybWF0cyB0cmFuc2xhdGUgZWFzaWx5IG9mIG5vdCBuYXRpdmVseSBpbnRv IHRoZSBDT01BTiBmb3JtYXRzLg0KDQpOb3csIGFzIEkgc2FpZCwgd2UgZG8gbm90IGhhdmUgYSB1 c2UgY2FzZSByaWdodCBub3cgZm9yIGEgbWFudWFsIHRyYWNrIGVuZm9yY2VtZW50ICjDoCBsYSBN UExTLVRQKSBmcm9tIHRoZSBuZXR3b3JrIG1hbmFnZW1lbnQgY29uc29sZS4NCkhvcGVmdWxseSB0 aGlzIHdpbGwgbmV2ZXIgY29tZS4gQnV0IGlmIGl0IGRvZXMsIEknbSBzYXlpbmcgdGhhdCB0aGUg Y29sbGlzaW9ucyBzaG91bGQgYmUgc29ydGVkIG91dCBieSBkaXJlY3QgY29tbXVuaWNhdGlvbiBi ZXR3ZWVuIE5NQSBhbmQgUENFLg0KDQpDaGVlcnMsDQoNClBhc2NhbA0KDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBRaW4gV2FuZyBbbWFpbHRvOnFpbndhbmdAYmVya2VsZXku ZWR1XSANClNlbnQ6IHZlbmRyZWRpIDIyIG1hcnMgMjAxMyAxNDo1MA0KVG86IFBhc2NhbCBUaHVi ZXJ0IChwdGh1YmVydCkNCkNjOiBRaW4gV2FuZzsgVGhvbWFzIFdhdHRleW5lOyBJRVRGIDZUU0NI OyBjb21hbkBpZXRmLm9yZw0KU3ViamVjdDogUmU6IEludGVyYWN0aW9uIGJldHdlZW4gTk1FIGFu ZCBQQ0UNCg0KSGkgUGFzY2FsLA0KDQpUaGFuayB5b3UgZm9yIHlvdXIgY29tbWVudHMuDQoNCkp1 c3QgYSBxdWljayBxdWVzdGlvbi4gQnkgTk1FLCBkbyB5b3UgcmVmZXIgdG8gQ29tbW9uIE5ldHdv cmsgTWFuYWdlbWVudA0KKENOTSkgaW4gdGhlIGRyYWZ0LXRodWJlcnQtNnRzY2gtYXJjaGl0ZWN0 dXJlLTAwPyBJZiB5ZXMsIG15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCBvbmx5IG9uZSBvZiB0aGVt IHNob3VsZCBiZSBlbmFibGVkIGluIGEgbmV0d29yayBzZXR0aW5nLiBJbiBhbm90aGVyIHdvcmQs IGl0IHNob3VsZCBub3QgYmUgdGhlIGNhc2UgdGhhdCBib3RoIG9mIHRoZW0gY29tcHV0ZSBUU0NI IHNjaGVkdWxlIChpLmUuIHRyYWNrcykgYXQgb25lIHRpbWUuIENvcnJlY3Q/IEkgd29uZGVyIHdo eSB3ZSBuZWVkIHRvIGNvbnNpZGVyIGJvdGggb2YgdGhlbSBmdW5jdGlvbmluZyBhdCBzYW1lIHRp bWUgaW4gdGVybXMgb2YgdHJhY2sgY29tcHV0YXRpb24uIE1heWJlIEkgbWlzc2VkIHNvbWV0aGlu Zy4NCg0KUWluDQoNCg0KPiBIZWxsbyBRaW47DQo+DQo+IFRoZXJlIGlzIHBvdGVudGlhbGx5IHNv bWUgZHVwbGljYXRpb24gYmV0d2VlbiB3aGF0IGEgNlRTQ0ggbm9kZSB3b3VsZCANCj4gZXhjaGFu Z2Ugd2l0aCBhIG5ldHdvcmsgbWFuYWdlbWVudCBlbnRpdHkgIChOTUUpIGFuZCB3aXRoIGEgcGF0 aCANCj4gY29tcHV0YXRpb24gZW50aXR5IChQQ0UpLiBCYXNpY2FsbHksIHRoZSBpbmZvcm1hdGlv biB3ZSB3YW50IHRvIHJlcG9ydCANCj4gYWJvdXQgcGVlcmluZywgbmVpZ2hib3JzLCBjZWxsIGFu ZCB0cmFjayB1dGlsaXphdGlvbiBjYW4gYmUgdXNlZnVsIG9uIA0KPiBib3RoIHNpZGVzLg0KPg0K PiBBbmQgd2UgbWF5IGV2ZW4gaGF2ZSBhIHVzZSBjYXNlIHdoZXJlIHRoZSB0cmFjayBpcyBlbnRl cmVkIG1hbnVhbGx5IMOgIA0KPiBsYSBNUExTIFRQIGFzIG9wcG9zZWQgdG8gVEUsIHRodXMgY29t aW5nIGZyb20gTk1FIHRob3VnaCwgZmluZ2VycyANCj4gY3Jvc3NlZCwgSSd2ZSBub3Qgc2VlbiB0 aGF0IG9uZSB5ZXQuIEluIHRoYXQgY2FzZSwgdGhlIHRyYWNrIA0KPiBpbmZvcm1hdGlvbiBjb3Vs ZCBiZSBpbXBvc2VkIG9uIHRoZSA2VFNDSCBub2RlIGJ5IGVpdGhlciBOTUUgYW5kIFBDRSwgDQo+ IGFuZCB0aGVyZSBjb3VsZCBwb3RlbnRpYWxseSBiZSBhIGNvbmZsaWN0IGJldHdlZW4gdGhvc2Ug dHJhY2tzLg0KPg0KPiBJZiB3ZSBwaWNrIHRoZSBkaXJlY3QgcGF0aCB3YXkgb2YgZW5oYW5jaW5n IGV4aXN0aW5nIHN0YW5kYXJkczoNCj4gMSkgIE5ldHdvcmsgTWFuYWdlbWVudCB3aWxsIGhhdmUg aXRzIG93biBtZWNoYW5pc21zLCBiYXNlZCBvbiB0aGUgd29yayANCj4gYXQgdGhlIENPTUFOIE1M Lg0KPiAyKSAgUGF0aCBDb21wdXRhdGlvbiB3aWxsIGhhdmUgaXRzIG93biBtZWNoYW5pc21zLCBw cm9iYWJseSBhIFBDRVAgDQo+IGVuaGFuY2VtZW50Lg0KPiBZZXQ6DQo+IDMpICBXZSBkbyBub3Qg d2FudCB0byByZXBvcnQgYSBsb3Qgb2YgaW5mb3JtYXRpb24gdHdpY2UgZnJvbSB0aGUgNlRTQ0gg DQo+IG5vZGVzLCBvbmNlIGZvciBOTUUgYW5kIG9uY2UgZm9yIFBDRS4NCj4gNCkgIFdlIHdhbnQg dGhlIGNvbmZsaWN0cyBiZXR3ZWVuIG1hbnVhbCAoTk1FKSBhbmQgYXV0b21hdGljIChQQ0UpIA0K PiByb3V0ZXMgdG8gYmUgc29ydGVkIGJldHdlZW4gdGhvc2UgdHdvIGJlZm9yZSB0aGUgZGV2aWNl IHNlZXMgYW55IG9mIGl0Lg0KPg0KPiBTbyBjZXJ0YWlubHksIFBDRVAgc2VlbXMgdG8gYmUgYSBt b3N0IHByb21pc2luZyB2ZW51ZSBmb3IgY2VudHJhbGl6ZWQgDQo+IHJvdXRlIGNvbXB1dGF0aW9u LiBGb3IgYWxsIEkga25vdywgUENFUCBpbiBhIGNsYXNzaWNhbCBQQ0UgYWxsb2NhdGVzIA0KPiBs YW1iZGFzIGluIERXRE0sIHNvIHdoeSB3b3VsZG4ndCB3ZSBlbmhhbmNlIGl0IHRvIGFsbG9jYXRl IGNlbGxzIGFuZCANCj4gdHJhY2tzIGluIDZUU0NIPw0KPg0KPiBCdXQgaWYgd2UgcGljayBQQ0VQ IGJldHdlZW4gdGhlIG5vZGUgYW5kIHRoZSBQQ0UgZm9yIGFsbCB0aGUgUENFIA0KPiByZWxhdGVk IGV4Y2hhbmdlcywgdGhlbiB3ZSBwcm9iYWJseSB3YW50IHRoZSBOTUUgdG8gaW50ZXJhY3Qgd2l0 aCB0aGUgDQo+IFBDRSB0byBkaWcgdGhlIHJlbGF0ZWQgaW5mb3JtYXRpb24sIGFuZCB3ZSBoYXZl IHRvIGRvY3VtZW50IGhvdyB0aGF0IA0KPiBoYXBwZW5zLiBBdCB0aGUgc2FtZSB0aW1lLCB3ZSBo YXZlIHRvIGRvY3VtZW50IGhvdyB0aGluZ3Mgd29yayB3aGVuIA0KPiB0aGVyZSBpcyBubyBQQ0Uu IExvb2tzIGxpa2UgdGhlIFBDRSB3b3VsZCBhY3QgYXMgYSBwcm94eSBvciBzb21ldGhpbmcuDQo+ DQo+IEl0IG1ha2VzIHNlbnNlIHRvIG1lIHRoYXQgdGhlIG5ldHdvcmsgbWFuYWdlbWVudCBpbmZv cm1hdGlvbiBtYXkgYmUgDQo+IGRpZ2dlZCBmcm9tIGEgZ2F0ZXdheSBhbnl3YXkgZm9yIGFsbCBz b3J0cyBvbiBub24tSVAgd29ybGQgDQo+IGNvbXBhdGliaWxpdHkuIENjJ2luZyBDT01BUA0KPg0K PiBQYXNjYWwNCj4NCj4NCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogNnRz Y2gtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOjZ0c2NoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiANCj4gT2YgUWluIFdhbmcNCj4gU2VudDogbHVuZGkgMTggbWFycyAyMDEzIDIwOjQyDQo+ IFRvOiBUaG9tYXMgV2F0dGV5bmUNCj4gQ2M6IElFVEYgNlRTQ0gNCj4gU3ViamVjdDogUmU6IFs2 dHNjaF0gSW50ZXJhY3Rpb24gYmV0d2VlbiBSUEwgYW5kIFBDRQ0KPg0KPiBUaG9tYXMsDQo+DQo+ IEknbSBub3QgdmVyeSBmYW1pbGlhciB3aXRoIFBDRSBwcm90b2NvbC4gQWNjb3JkaW5nIHRvIG15 IGtub3dsZWRnZSwgDQo+IHRoZXJlIGFyZSBleHRlbnNpb25zIG9mIFBDRSBwcm90b2NvbCBjb3Jy ZXNwb25kaW5nIHRvIGRpZmZlcmVudCANCj4gcHJvdG9jb2xzIGxpa2UgR01QTFMuIFNvLCBtYXli ZSBhIGV4dGVuc2lvbiBvZiBQQ0UgZm9yIDZ0dXMgaXMgbmVlZGVkLCANCj4gd2hpY2ggY29tcHV0 ZXMgdGhlIHRyYWNrIGZvciBnaXZlbiBtdWx0aWhvcCBwYXRoIGFuZCBiYW5kd2lkdGggDQo+IHJl cXVpcmVtZW50LCBvciB0aGUgdHJhY2sgZm9yIGdpdmVuIHRvcG9sb2d5IGFuZCBlbmQtdG8tZW5k IGJhbmR3aWR0aCByZXF1aXJlbWVudC4NCj4NCj4gSG93IGRvIHlvdSB0aGluaz8NCj4NCj4gUWlu DQo+DQo+DQo+DQo+PiBRaW4sDQo+Pg0KPj4gUGxlYXNlIHNlZSBpbmxpbmUuDQo+Pg0KPj4gT24g TW9uLCBNYXIgMTgsIDIwMTMgYXQgMTA6MjUgQU0sIFFpbiBXYW5nIDxxaW53YW5nQGJlcmtlbGV5 LmVkdT4gd3JvdGU6DQo+Pg0KPj4+IFRob21hcywNCj4+Pg0KPj4+IEkgdGhpbmsgZm9yIGEgZGF0 YSBmbG93LCB0aGVyZSBhcmUgdGhyZWUgZWxlbWVudHMgbmVlZGVkIHRvIGJlIA0KPj4+IGRlZmlu ZWQgb3Igc2NoZWR1bGVkIGV4cGxpY2l0bHkgb3IgaW1wbGljaXRseToNCj4+PiAoMSkgbXVsdGlo b3AgcGF0aCwgaS5lLiB3aG8gaXMgdGhlIG5leHQgaG9wIG5laWdoYm9yDQo+Pj4gKDIpIGJhbmR3 aWR0aCBhbmQgUW9zIHJlcXVpcmVtZW50DQo+Pj4gKDMpIGNlbGwgc2V0IChpLmUuIGJ1bmRsZSkg dG8gaW1wbGVtZW50IHRoZSBiYW5kd2lkdGgNCj4+Pg0KPj4+IEluIGNhc2UtMSwgYWxsIG9mIHRo ZSB0aHJlZSBlbGVtZW50cyBhcmUgZGV0ZXJtaW5lZCBieSBQQ0UsIGFuZCBSUEwgDQo+Pj4gaXMg anVzdCBhIGJhY2t1cCBhbmQgd29ya3Mgb24gc2xvdC1hbG9oYSBjZWxscy4gQ29ycmVjdD8NCj4+ Pg0KPj4NCj4+IEkgYmVsaWV2ZSB0aGF0J3MgY29ycmVjdC4gQlRXLCBJJ20gbm90IHBlciBzZSBh ZHZvY2F0aW5nIGZvciB0aGlzIA0KPj4gc29sdXRpb24sIGJ1dCBpdCBzZWVtcyB0byBiZSB0aGUg YXBwcm9hY2ggDQo+PiBkcmFmdC1pZXRmLXJvbGwtcnBsLWluZHVzdHJpYWwtYXBwbGljYWJpbGl0 eQ0KPj4gdGFrZXMuDQo+Pg0KPj4NCj4+PiBJbiBjYXNlMiwgZWxlbWVudCgxKSBpcyBkZXRlcm1p bmVkIGJ5IFJQTCBiYXNlZCBvbiBSYW5rLCBhbmQNCj4+PiBlbGVtZW50KDMpIGlzIGRldGVybWlu ZWQgYnkgUENFLiBCdXQsIHdobyB3aWxsIGRldGVybWluZSBlbGVtZW50KDIpPw0KPj4+IGJ5IFBD RSBvciBieSBzb21lIGVudGl0eSBsaWtlIFJTVlAvTlNJUyBvciBEU0NQPw0KPj4+DQo+Pj4NCj4+ IEFncmVlZC4gSXQgcmVsYXRpdmVseSBzdHJhaWdodGZvcndhcmQgZm9yIGEgUENFIHRvIGNvbXB1 dGUgYSBzY2hlZHVsZSANCj4+IGFuZCBkaXN0cmlidXRlIHRoYXQgaW50byB0aGUgbmV0d29yaywg YnV0IGhvdyBkb2VzIGl0IGZpZ3VyZSBvdXQgd2hhdCANCj4+IHRoZSByZXF1aXJlbWVudHMgYXJl IGZyb20gdGhlIG5vZGVzIGluIHRoZSBuZXR3b3JrLiBDb3VsZCB3ZSByZXVzZSBhIA0KPj4gIlBD RSByZXF1aXJlbWVudHMiIHByb3RvY29sIG91dCB0aGVyZT8NCj4+DQo+Pg0KPj4+IFFpbg0KPj4+ DQo+Pj4gPiBbc3ViamVjdCB3YXM6IFNjb3BlOiA2TG9XUEFOICsgMV0NCj4+PiA+DQo+Pj4gPiBN YXJpYSBSaXRhLA0KPj4+ID4NCj4+PiA+IEkgZnVsbHkgYWdyZWUgd2l0aCBQYXNjYWwncyBzdWdn ZXN0aW9uIHRvIGhhdmUgdGhlIFBDRSBvbmx5IHRhbGsgDQo+Pj4gPiB0bw0KPj4+IG9uZQ0KPj4+ IG9mDQo+Pj4gPiB0aGUgdHdvIHNpZGVzIG9uIGEgb24taG9wIGxpbmssIGFuZCBoYXZlIDZ0dXMg YmUgaW4gY2hhcmdlIHRvIA0KPj4+ID4gdGVsbGluZw0KPj4+IHRoZQ0KPj4+ID4gb3RoZXIgc2lk ZSB0byByZXNlcnZlIHRoZSBzYW1lIGNlbGwuIEkgYmVsaWV2ZSBRaW4gaGFzIGFsc28NCj4+PiBh Y2tub3dsZWRnZWQNCj4+PiA+IHRoaXMsIGFuZCBoYXMgYWdyZWVkIHRvIHB1dCB0aGlzIG1lY2hh bmlzbSBpbnRvIDZ0dXMuIFRoaXMgd291bGQNCj4+PiBwcm9iYWJseQ0KPj4+ID4gbWVhbiBhZGRp bmcgc29tZSBvcHRpb24gaW4gdGhlIDZ0dXMgbWVzc2FnZSBmb3JtYXQgc2F5aW5nICJ0aGlzIGlz IA0KPj4+ID4gbm90DQo+Pj4gYQ0KPj4+ID4gbmVnb2NpYXRpb24gZm9yIGEgc29mdCBjZWxsLCBi dXQgYW4gb3JkZXIgZm9yIHlvdSB0byBhZGQgdGhpcyBoYXJkDQo+Pj4gY2VsbCIuDQo+Pj4gPg0K Pj4+ID4gQWxsLA0KPj4+ID4NCj4+PiA+IEkgYmVsaWV2ZSBNYXJpYSBSaXRhIGlzIHRvdWNoaW5n IGEgdmVyeSBpbXBvcnRhbnQgcG9pbnQgd2UgaGF2ZW4ndCANCj4+PiA+IGhhZCB0aW1lIHRvIGRp c2N1c3MgbGFzdCB3ZWVrIGluIE9ybGFuZG8sIGJ1dCB3aGljaCBJIGJlbGlldmUgaXMNCj4+PiA+ IGVzc2VudGlhbDogaG93DQo+Pj4gZG8NCj4+PiA+IFJQTCBhbmQgdGhlIFBDRSBpbnRlcmFjdD8g VGhlIFBDRSBjYW4gaGF2ZSBjb21wbGV0ZSBrbm93bGVkZ2Ugb2YgDQo+Pj4gPiB0aGUgbmV0d29y ayB0b3BvbG9neSBhbmQgdGhlIG5ldHdvcmsgdHJhZmZpYywgc28gYmVzaWRlcyBMMiANCj4+PiA+ IHJlc291cmNlIGFsbG9jYXRpb24sIGl0IGNvdWxkIGFsc28gbWFrZSByb3V0aW5nIGRlY2lzaW9u LCBpLmUuDQo+Pj4gPiBidWlsZCB0aGUgdHJhY2sNCj4+PiBpdA0KPj4+ID4gYmVsaWV2ZSBpcyBi ZXN0IGZpdC4NCj4+PiA+DQo+Pj4gPiBkcmFmdC1pZXRmLXJvbGwtcnBsLWluZHVzdHJpYWwtYXBw bGljYWJpbGl0eS0wMCBhbHNvIHN0YXRlcyANCj4+PiA+IHNpbWlsYXINCj4+PiBpZGVhczoNCj4+ PiA+ICJUaGUgZG9tYWluIG9mIGFwcGxpY2FiaWxpdHkgZm9yIHRoZSBSUEwgcHJvdG9jb2wgbWF5 IGluY2x1ZGUgYWxsDQo+Pj4gcGhhc2VzDQo+Pj4gPiBidXQgdGhlIE5vcm1hbCBPcGVyYXRpb24g cGhhc2UsIHdoZXJlIHRoZSBiYW5kd2lkdGggYWxsb2NhdGlvbiBhbmQgDQo+Pj4gPiB0aGUgKnJv dXRlcyBhcmUgdXN1YWxseSBvcHRpbWl6ZWQgYnkgYW4gZXh0ZXJuYWwgUGF0aCBDb21wdXRpbmcg DQo+Pj4gPiBFbmdpbmUgKFBDRSkqLg0KPj4+IFsuLi5dDQo+Pj4gPiBBZGRpdGlvbmFsbHksIGl0 IGNvdWxkIGJlIGVudmlzaW9uZWQgdG8gaW5jbHVkZSBSUEwgaW4gdGhlIG5vcm1hbCANCj4+PiA+ IG9wZXJhdGlvbiBwcm92aWRlZCB0aGF0IGEgbmV3IE9iamVjdGl2ZSBGdW5jdGlvbiBpcyBkZWZp bmVkIHRoYXQgDQo+Pj4gPiBhY3R1YWxseQ0KPj4+IGludGVyYWN0cw0KPj4+ID4gd2l0aCB0aGUg UENFIGlzIG9yZGVyIHRvIGVzdGFibGlzaCB0aGUgcmVmZXJlbmNlIHRvcG9sb2d5LCBpbiANCj4+ PiA+IHdoaWNoDQo+Pj4gY2FzZQ0KPj4+ID4gKlJQTA0KPj4+ID4gb3BlcmF0aW9ucyB3b3VsZCBv bmx5IGFwcGx5IHRvIGVtZXJnZW5jeSByZXBhaXIgYWN0aW9ucyouIHdoZW4gdGhlIA0KPj4+ID4g cmVmZXJlbmNlIHRvcG9sb2d5IGJlY29tZXMgdW51c2FibGUgZm9yIHNvbWUgZmFpbHVyZSwgYW5k IGFzIGxvbmcgDQo+Pj4gPiBhcw0KPj4+IHRoZQ0KPj4+ID4gcHJvYmxlbSBwZXJzaXN0cy4iDQo+ Pj4gPg0KPj4+ID4gVGhpcyBzaG90LWNpcmN1aXRzIFJQTC4NCj4+PiA+DQo+Pj4gPiBUaGUgdHdv IHVzZSBjYXNlcyBJIGNhbiBzZWUgYXJlOg0KPj4+ID4gMS4gdGhlIFBDRSBtYWtlcyBkZWNpc2lv bnMgd2l0aG91dCBSUEwncyBpbnRlcnZlbnRpb24uIFJQTCBydW5zIGluIA0KPj4+ID4gdGhlIGJh Y2tncm91bmQgZm9yIGVtZXJnZW5jeSByZXBhaXIgYWN0aW9ucyBvbmx5Lg0KPj4+ID4gMi4gUlBM IHNldHMgdXAgbXVsdGktaG9wIHJvdXRlcyB3aGljaCB0aGUgUENFIHVzZXMgZm9yIGJ1aWxkaW5n DQo+Pj4gdHJhY2tzLg0KPj4+ID4gVGhhdCBpcywgdGhlIFBDRSBvbmx5IHBlcmZvcm1zIEwyIHJl c291cmNlIGFsbG9jYXRpb24uDQo+Pj4gPg0KPj4+ID4gRG8gd2UgYWdyZWUgdG8gdXNlIG9ubHkg dXNlIGNhc2UgMT8gSWYgd2UgZ28gZm9yIDIsIGhvdyBkb2VzIHRoZSANCj4+PiA+IFBDRQ0KPj4+ IGdldA0KPj4+ID4gaW5mb3JtYXRpb24gYWJvdXQgUlBMIHJvdXRlcyAoZXNwZWNpYWxseSBpbiBz dG9yaW5nIG1vZGUpPw0KPj4+ID4NCj4+PiA+IFRob21hcw0KPj4+ID4NCj4+PiA+IE9uIE1vbiwg TWFyIDE4LCAyMDEzIGF0IDI6MDYgQU0sIE1hcmlhIFJpdGEgUEFMQVRURUxMQSA8IA0KPj4+ID4g bWFyaWEtcml0YS5wYWxhdHRlbGxhQHVuaS5sdT4gd3JvdGU6DQo+Pj4gPg0KPj4+ID4+IEhpIFFp biwgYW5kIGFsbCwNCj4+PiA+PiBTb3JyeSBmb3IgY29taW5nIGJhY2sgdG8gdGhpcyBkaXNjdXNz aW9uIGFmdGVyIHNvbWUgdGltZSwgYnV0IEkNCj4+PiB3YW50ZWQNCj4+PiA+PiB0bw0KPj4+ID4+ IHJhaXNlIGFuZCBjbGFyaWZ5IGEgcG9pbnQuDQo+Pj4gPj4NCj4+PiA+PiBRaW4+Pj4oMikgSWYg dGhlcmUgaXMgUENFLCB0aGVyZSBtYXkgYmUgZGlmZmVyZW50IHNldHRpbmcuIEZvcg0KPj4+IGV4 YW1wbGUsDQo+Pj4gPj4gUENFIGlzIGluIGNoYXJnZSBmb3IgcmVzZXJ2aW5nIGJvdGggbXVsdGlw bGUgaG9wIHBhdGggKGkuZS4gZXZlcnkNCj4+PiBuZXh0DQo+Pj4gPj4gaG9wDQo+Pj4gPj4gUWlu Pj4+bmVpZ2hib3IpIGFuZCBjZWxsczsgb3IgUENFIGlzIGp1c3QgaW4gY2hhcmdlIGZvciByZXNl cnZpbmcgDQo+Pj4gPj4gUWluPj4+dGhlDQo+Pj4gPj4gbXVsdGlwbGUgaG9wIHBhdGggYW5kIGxl YXZpbmcgY2VsbCByZXNlcnZhdGlvbiB0byBsb2NhbCwgYW5kIHRoZSANCj4+PiA+PiBkaXN0cmli dXRlZCBjZWxsIHJlc2VydmF0aW9uIHdpbGwgbWVldCB0aGUgYmFuZHdpZHRoIHJlcXVpcmVtZW50 IA0KPj4+ID4+IGZyb20gbXVsdGlwbGUgaG9wIHBhdGggcmVzZXJ2YXRpb24uIEluIHRoZSBmaXJz dCBjYXNlLCBoYXJkIA0KPj4+ID4+IFFpbj4+PiBjZWxsICByZXNlcnZhdGlvbiB3aWxsIGJlIHVz ZWQuDQo+Pj4gPj4NCj4+PiA+PiBRaW4gPj4+KDMpSWYgdGhlcmUgaXMgbm8gUENFLCBib3RoIG11 bHRpLWhvcCBwYXRoIGFuZCBjZWxscyBhcmUNCj4+PiByZXNlcnZlZA0KPj4+ID4+IGluIGxvY2Fs Lg0KPj4+ID4+IFFpbj4+Rm9yIGV4YW1wbGUsIFJQTCArIHNvZnQgY2VsbCByZXNlcnZhdGlvbiBp biA2dHVzLg0KPj4+ID4+DQo+Pj4gPj4gRnJvbSBteSBwb2ludCBvZiB2aWV3IChhbmQgdGhpbmtp bmcgYWJvdXQgVEFTQSBpbXBsZW1lbnRhdGlvbiksIA0KPj4+ID4+IHRoZQ0KPj4+IFBDRQ0KPj4+ ID4+IHNob3VsZG4ndCBiZSBpbiBjaGFyZ2UgZm9yIHJlc2VydmluZyB0aGUgbXVsdGlwbGUgaG9w IHBhdGguIEJ1dCANCj4+PiA+PiB0aGUgcm91dGluZyBwcm90b2NvbCAoaS5lLiwgUlBMIGluIG91 ciBjYXNlKSBzaG91bGQgdGFrZSBjYXJlIG9mIA0KPj4+ID4+IHRoZSBuZXh0IGhvcCBuZWlnaGJv ciBzZWxlY3Rpb24uDQo+Pj4gPj4gV2hlbiBhIGNlbnRyYWxpemVkIGFwcHJvYWNoIGlzIGFkb3B0 ZWQsIHRoZSBQQ0Ugd2lsbCBzY2hlZHVsZSB0aGUNCj4+PiBjZWxscw0KPj4+ID4+ICAoaS5lLiwg aGFyZCBjZWxscyBhY2NvcmRpbmcgdG8gNnR1cyB0ZXJtaW5vbG9neSkuDQo+Pj4gPj4gV2hpbGUs IHdoZW4gYSBkaXN0cmlidXRlZCBzb2x1dGlvbiBpcyB1c2VkLCA2dHVzIHdpbGwgYWxsb2NhdGUg DQo+Pj4gPj4gdGhlDQo+Pj4gc29mdA0KPj4+ID4+IGNlbGxzLg0KPj4+ID4+DQo+Pj4gPj4gSW4g dGhlIGNlbnRyYWxpemVkIHNjZW5hcmlvIHdpdGggdGhlIFBDRSwgdG8gYXZvaWQgdGhlIGV4Y2hh bmdlIA0KPj4+ID4+IG9mDQo+Pj4gbWFueQ0KPj4+ID4+IHNpZ25hbGluZyBtZXNzYWdlcywgZm9y IHNldHRpbmcgdXAgdGhlIHNjaGVkdWxlLCB3ZSBtYXkgdGhpbmsgKGFzDQo+Pj4gUGFzY2FsDQo+ Pj4gPj4gd2FzIHN1Z2dlc3RpbmcgZHVyaW5nIG9uZSBvZiB0aGUgbGFzdCBjYWxsKSB0byB1c2Ug c29tZSBoeWJyaWQgDQo+Pj4gPj4gc29sdXRpb25zLg0KPj4+ID4+IEluIG90aGVyIHdvcmRzLCBp ZiBQQ0UgYWxsb2NhdGVzICh0aW1lb2Zmc2V0MSwgY2hhbm5lbG9mZnNldDMsIA0KPj4+ID4+IHNs b3RmcmFtZTEsDQo+Pj4gPj4gVFgpIHRvIG5vZGUgQSBmb3IgdHJhbnNtaXR0aW5nIHRvIG5vZGUg QiwgdGhlbiwgbm9kZSBCIGNvdWxkIGtub3cgDQo+Pj4gPj4gbG9jYWxseSBmcm9tIG5vZGUgQSwg KGFuZCBub3QgZnJvbSB0aGUgUENFKSwgdGhhdCB0aGUgY2VsbCANCj4+PiA+PiAodGltZW9mZnNl dDEsIGNoYW5uZWxvZmZzZXQzLCBzbG90ZnJhbWUxLCBSWCkgaGFzIGJlZW4gcmVzZXJ2ZWQgDQo+ Pj4gPj4gdG8gaXQsIGZvcg0KPj4+IHJlY2VpdmluZw0KPj4+ID4+IGZyb20NCj4+PiA+PiBub2Rl IEEuDQo+Pj4gPj4gV2UgbWF5IHRyeSB0byBpbmNsdWRlIHNvbWUgZnVuY3Rpb25hbGl0eSBpbiA2 dHVzIGxheWVyIGluIG9yZGVyIA0KPj4+ID4+IHRvIG1hbmFnZSBzdWNoIHNpdHVhdGlvbi4NCj4+ PiA+PiBXaGF0IGRvIHlvdSB0aGluaz8NCj4+PiA+Pg0KPj4+ID4+IE1hcmlhIFJpdGENCj4+PiA+ Pg0KPj4+ID4+DQo+Pj4gPj4NCj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+IC0NCj4+PiAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4gPj4gPiBPbiAzLzE0LzEzIDk6 MDIgUE0sIFBhdWwgQ2hpbHRvbiB3cm90ZToNCj4+PiA+PiA+Pj4tIG9wdGlvbmFsbHkgYSBQQ0Ug c2l0cyBvbiB0aGUgYmFja2JvbmUgYW5kIGRyaXZlcyB0aGUgTExOcycNCj4+PiA+PiA+Pj5UU0NI IHNjaGVkdWxlcy4NCj4+PiA+PiA+DQo+Pj4gPj4gPiBBaCwgbWF5YmUgdW5kZXJzdG9vZC4gIEl0 IGRvZXNuJ3Qgc2F5IHRoYXQgZXhpc3RlbmNlIG9mIFBDRSBpcw0KPj4+ID4+IG9wdGlvbmFsLg0K Pj4+ID4+ID4gSXQgc2F5cyB0aGF0IGl0J3Mgb3B0aW9uYWwgdG8gcHV0IFBDRSBpbiB0aGUgYmFj a2JvbmUuICBJdCANCj4+PiA+PiA+IGRvZXNuJ3QgcHJlY2x1ZGUgdG8gcHV0IGl0IG9uIEJCUi4g IENvcnJlY3QgPw0KPj4+ID4+ID4NCj4+PiA+PiA+IFNob2ljaGkNCj4+PiA+PiA+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gPj4gPiA2dHNjaCBt YWlsaW5nIGxpc3QNCj4+PiA+PiA+IDZ0c2NoQGlldGYub3JnDQo+Pj4gPj4gPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvLzZ0c2NoDQo+Pj4gPj4gPg0KPj4+ID4+DQo+Pj4g Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiA+ PiA2dHNjaCBtYWlsaW5nIGxpc3QNCj4+PiA+PiA2dHNjaEBpZXRmLm9yZw0KPj4+ID4+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vNnRzY2gNCj4+PiA+PiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+ID4+IDZ0c2NoIG1haWxp bmcgbGlzdA0KPj4+ID4+IDZ0c2NoQGlldGYub3JnDQo+Pj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby82dHNjaA0KPj4+ID4+DQo+Pj4gPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+ID4gNnRzY2ggbWFpbGluZyBsaXN0 DQo+Pj4gPiA2dHNjaEBpZXRmLm9yZw0KPj4+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby82dHNjaA0KPj4+ID4NCj4+Pg0KPj4+DQo+Pj4NCj4+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA2dHNjaCBtYWlsaW5nIGxpc3QN Cj4+IDZ0c2NoQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvLzZ0c2NoDQo+Pg0KPg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiA2dHNjaCBtYWlsaW5nIGxpc3QNCj4gNnRzY2hAaWV0Zi5vcmcNCj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby82dHNjaA0KPg0KDQo= Return-Path: 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 A7B9221F8AC1; Fri, 22 Mar 2013 06:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_MED=-4] 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 ZtZF+sVJDbRK; Fri, 22 Mar 2013 06:50:12 -0700 (PDT) Received: from cm04fe.IST.Berkeley.EDU (cm04fe.IST.Berkeley.EDU [169.229.218.145]) by ietfa.amsl.com (Postfix) with ESMTP id 9EF2721F8A47; Fri, 22 Mar 2013 06:50:12 -0700 (PDT) Received: from cm02ws.ist.berkeley.edu ([169.229.218.164] helo=calmail.berkeley.edu) by cm04fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth login:qinwang@berkeley.edu) (envelope-from ) id 1UJ2ME-00015t-Ei; Fri, 22 Mar 2013 06:50:12 -0700 Received: from 96.227.54.17 (SquirrelMail authenticated user qinwang@berkeley.edu) by calmail.berkeley.edu with HTTP; Fri, 22 Mar 2013 06:50:10 -0700 Message-ID: <923b8183e356e136c19df594200bf6f8.squirrel@calmail.berkeley.edu> In-Reply-To: References: Date: Fri, 22 Mar 2013 06:50:10 -0700 From: "Qin Wang" To: "Pascal Thubert (pthubert)" User-Agent: SquirrelMail/1.4.21-2.berkeley MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: Thomas Watteyne , "coman@ietf.org" , IETF 6TSCH <6tsch@ietf.org>, Qin Wang Subject: Re: [6tsch] Interaction between NME and PCE 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 13:50:13 -0000 Hi Pascal, Thank you for your comments. Just a quick question. By NME, do you refer to Common Network Management (CNM) in the draft-thubert-6tsch-architecture-00? If yes, my understanding is that only one of them should be enabled in a network setting. In another word, it should not be the case that both of them compute TSCH schedule (i.e. tracks) at one time. Correct? I wonder why we need to consider both of them functioning at same time in terms of track computation. Maybe I missed something. Qin > Hello Qin; > > There is potentially some duplication between what a 6TSCH node would > exchange with a network management entity (NME) and with a path > computation entity (PCE). Basically, the information we want to report > about peering, neighbors, cell and track utilization can be useful on both > sides. > > And we may even have a use case where the track is entered manually à la > MPLS TP as opposed to TE, thus coming from NME though, fingers crossed, > I've not seen that one yet. In that case, the track information could be > imposed on the 6TSCH node by either NME and PCE, and there could > potentially be a conflict between those tracks. > > If we pick the direct path way of enhancing existing standards: > 1) Network Management will have its own mechanisms, based on the work at > the COMAN ML. > 2) Path Computation will have its own mechanisms, probably a PCEP > enhancement. > Yet: > 3) We do not want to report a lot of information twice from the 6TSCH > nodes, once for NME and once for PCE. > 4) We want the conflicts between manual (NME) and automatic (PCE) routes > to be sorted between those two before the device sees any of it. > > So certainly, PCEP seems to be a most promising venue for centralized > route computation. For all I know, PCEP in a classical PCE allocates > lambdas in DWDM, so why wouldn't we enhance it to allocate cells and > tracks in 6TSCH? > > But if we pick PCEP between the node and the PCE for all the PCE related > exchanges, then we probably want the NME to interact with the PCE to dig > the related information, and we have to document how that happens. At the > same time, we have to document how things work when there is no PCE. Looks > like the PCE would act as a proxy or something. > > It makes sense to me that the network management information may be digged > from a gateway anyway for all sorts on non-IP world compatibility. Cc'ing > COMAP > > Pascal > > > -----Original Message----- > From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of > Qin Wang > Sent: lundi 18 mars 2013 20:42 > To: Thomas Watteyne > Cc: IETF 6TSCH > Subject: Re: [6tsch] Interaction between RPL and PCE > > Thomas, > > I'm not very familiar with PCE protocol. According to my knowledge, there > are extensions of PCE protocol corresponding to different protocols like > GMPLS. So, maybe a extension of PCE for 6tus is needed, which computes the > track for given multihop path and bandwidth requirement, or the track for > given topology and end-to-end bandwidth requirement. > > How do you think? > > Qin > > > >> Qin, >> >> Please see inline. >> >> On Mon, Mar 18, 2013 at 10:25 AM, Qin Wang wrote: >> >>> Thomas, >>> >>> I think for a data flow, there are three elements needed to be >>> defined or scheduled explicitly or implicitly: >>> (1) multihop path, i.e. who is the next hop neighbor >>> (2) bandwidth and Qos requirement >>> (3) cell set (i.e. bundle) to implement the bandwidth >>> >>> In case-1, all of the three elements are determined by PCE, and RPL >>> is just a backup and works on slot-aloha cells. Correct? >>> >> >> I believe that's correct. BTW, I'm not per se advocating for this >> solution, but it seems to be the approach >> draft-ietf-roll-rpl-industrial-applicability >> takes. >> >> >>> In case2, element(1) is determined by RPL based on Rank, and >>> element(3) is determined by PCE. But, who will determine element(2)? >>> by PCE or by some entity like RSVP/NSIS or DSCP? >>> >>> >> Agreed. It relatively straightforward for a PCE to compute a schedule >> and distribute that into the network, but how does it figure out what >> the requirements are from the nodes in the network. Could we reuse a >> "PCE requirements" protocol out there? >> >> >>> Qin >>> >>> > [subject was: Scope: 6LoWPAN + 1] >>> > >>> > Maria Rita, >>> > >>> > I fully agree with Pascal's suggestion to have the PCE only talk to >>> one >>> of >>> > the two sides on a on-hop link, and have 6tus be in charge to >>> > telling >>> the >>> > other side to reserve the same cell. I believe Qin has also >>> acknowledged >>> > this, and has agreed to put this mechanism into 6tus. This would >>> probably >>> > mean adding some option in the 6tus message format saying "this is >>> > not >>> a >>> > negociation for a soft cell, but an order for you to add this hard >>> cell". >>> > >>> > All, >>> > >>> > I believe Maria Rita is touching a very important point we haven't >>> > had time to discuss last week in Orlando, but which I believe is >>> > essential: how >>> do >>> > RPL and the PCE interact? The PCE can have complete knowledge of >>> > the network topology and the network traffic, so besides L2 >>> > resource allocation, it could also make routing decision, i.e. >>> > build the track >>> it >>> > believe is best fit. >>> > >>> > draft-ietf-roll-rpl-industrial-applicability-00 also states similar >>> ideas: >>> > "The domain of applicability for the RPL protocol may include all >>> phases >>> > but the Normal Operation phase, where the bandwidth allocation and >>> > the *routes are usually optimized by an external Path Computing >>> > Engine (PCE)*. >>> [...] >>> > Additionally, it could be envisioned to include RPL in the normal >>> > operation provided that a new Objective Function is defined that >>> > actually >>> interacts >>> > with the PCE is order to establish the reference topology, in which >>> case >>> > *RPL >>> > operations would only apply to emergency repair actions*. when the >>> > reference topology becomes unusable for some failure, and as long >>> > as >>> the >>> > problem persists." >>> > >>> > This shot-circuits RPL. >>> > >>> > The two use cases I can see are: >>> > 1. the PCE makes decisions without RPL's intervention. RPL runs in >>> > the background for emergency repair actions only. >>> > 2. RPL sets up multi-hop routes which the PCE uses for building >>> tracks. >>> > That is, the PCE only performs L2 resource allocation. >>> > >>> > Do we agree to use only use case 1? If we go for 2, how does the >>> > PCE >>> get >>> > information about RPL routes (especially in storing mode)? >>> > >>> > Thomas >>> > >>> > On Mon, Mar 18, 2013 at 2:06 AM, Maria Rita PALATTELLA < >>> > maria-rita.palattella@uni.lu> wrote: >>> > >>> >> Hi Qin, and all, >>> >> Sorry for coming back to this discussion after some time, but I >>> wanted >>> >> to >>> >> raise and clarify a point. >>> >> >>> >> Qin>>>(2) If there is PCE, there may be different setting. For >>> example, >>> >> PCE is in charge for reserving both multiple hop path (i.e. every >>> next >>> >> hop >>> >> Qin>>>neighbor) and cells; or PCE is just in charge for reserving >>> >> Qin>>>the >>> >> multiple hop path and leaving cell reservation to local, and the >>> >> distributed cell reservation will meet the bandwidth requirement >>> >> from multiple hop path reservation. In the first case, hard Qin>>> >>> >> cell reservation will be used. >>> >> >>> >> Qin >>>(3)If there is no PCE, both multi-hop path and cells are >>> reserved >>> >> in local. >>> >> Qin>>For example, RPL + soft cell reservation in 6tus. >>> >> >>> >> From my point of view (and thinking about TASA implementation), >>> >> the >>> PCE >>> >> shouldn't be in charge for reserving the multiple hop path. But >>> >> the routing protocol (i.e., RPL in our case) should take care of >>> >> the next hop neighbor selection. >>> >> When a centralized approach is adopted, the PCE will schedule the >>> cells >>> >> (i.e., hard cells according to 6tus terminology). >>> >> While, when a distributed solution is used, 6tus will allocate the >>> soft >>> >> cells. >>> >> >>> >> In the centralized scenario with the PCE, to avoid the exchange of >>> many >>> >> signaling messages, for setting up the schedule, we may think (as >>> Pascal >>> >> was suggesting during one of the last call) to use some hybrid >>> >> solutions. >>> >> In other words, if PCE allocates (timeoffset1, channeloffset3, >>> >> slotframe1, >>> >> TX) to node A for transmitting to node B, then, node B could know >>> >> locally from node A, (and not from the PCE), that the cell >>> >> (timeoffset1, channeloffset3, slotframe1, RX) has been reserved to >>> >> it, for >>> receiving >>> >> from >>> >> node A. >>> >> We may try to include some functionality in 6tus layer in order to >>> >> manage such situation. >>> >> What do you think? >>> >> >>> >> Maria Rita >>> >> >>> >> >>> >> >>> --------------------------------------------------------------------- >>> ------------------------------------------- >>> >> > On 3/14/13 9:02 PM, Paul Chilton wrote: >>> >> >>>- optionally a PCE sits on the backbone and drives the LLNs' >>> >> >>>TSCH schedules. >>> >> > >>> >> > Ah, maybe understood. It doesn't say that existence of PCE is >>> >> optional. >>> >> > It says that it's optional to put PCE in the backbone. It >>> >> > doesn't preclude to put it on BBR. Correct ? >>> >> > >>> >> > Shoichi >>> >> > _______________________________________________ >>> >> > 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 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 > Return-Path: 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 6041021F8959; Fri, 22 Mar 2013 01:07:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_HI=-8] 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 vf1ctLGhyXS2; Fri, 22 Mar 2013 01:07:35 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 2E8AC21F8936; Fri, 22 Mar 2013 01:07:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10033; q=dns/txt; s=iport; t=1363939655; x=1365149255; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=/+CAb+VsB1rffRMx1WwjJZnJCXDfE2E0TGvw35o1YvI=; b=KpigstES2LO2Ffcf9nYunQPsKxqw/QQunp7JAlO/i45w2WveO5bObLQE gqMyaWn91fKp72RmEPX3HHodopLRd3wNl6wiw1jD4rvh8VXmk9BAbjGhq D7Y6mii6kIlq62ly0wFZXmpN/4rvdPKCbPFbIad+trPA4JN33SsKiZnbm Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAIgQTFGtJV2c/2dsb2JhbABDDsVngV4WdIIkAQEBAwEBAQFrCwUHBgEZBAEBAQodLgsUCQkBBAENBQgTh3MGDMFWEwSNSYEYJgsNgllhA4g/il+USYJLP4Io X-IronPort-AV: E=Sophos;i="4.84,891,1355097600"; d="scan'208";a="190340602" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 22 Mar 2013 08:07:34 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r2M87YK8021292 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Mar 2013 08:07:34 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.152]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Fri, 22 Mar 2013 03:07:33 -0500 From: "Pascal Thubert (pthubert)" To: Qin Wang , Thomas Watteyne Thread-Topic: Interaction between NME and PCE Thread-Index: Ac4m1AAaAig2JGZERcC75DTjyWBvYA== Date: Fri, 22 Mar 2013 08:07:33 +0000 Deferred-Delivery: Fri, 22 Mar 2013 08:06:00 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.85.19] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "coman@ietf.org" , IETF 6TSCH <6tsch@ietf.org> Subject: [6tsch] Interaction between NME and PCE 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 08:07:36 -0000 Hello Qin; There is potentially some duplication between what a 6TSCH node would excha= nge with a network management entity (NME) and with a path computation ent= ity (PCE). Basically, the information we want to report about peering, neig= hbors, cell and track utilization can be useful on both sides. And we may even have a use case where the track is entered manually =E0 la = MPLS TP as opposed to TE, thus coming from NME though, fingers crossed, I'v= e not seen that one yet. In that case, the track information could be impos= ed on the 6TSCH node by either NME and PCE, and there could potentially be = a conflict between those tracks.=20 If we pick the direct path way of enhancing existing standards:=20 1) Network Management will have its own mechanisms, based on the work at t= he COMAN ML. 2) Path Computation will have its own mechanisms, probably a PCEP enhancem= ent. Yet: 3) We do not want to report a lot of information twice from the 6TSCH node= s, once for NME and once for PCE. 4) We want the conflicts between manual (NME) and automatic (PCE) routes t= o be sorted between those two before the device sees any of it.=20 So certainly, PCEP seems to be a most promising venue for centralized route= computation. For all I know, PCEP in a classical PCE allocates lambdas in = DWDM, so why wouldn't we enhance it to allocate cells and tracks in 6TSCH?= =20 But if we pick PCEP between the node and the PCE for all the PCE related ex= changes, then we probably want the NME to interact with the PCE to dig the = related information, and we have to document how that happens. At the same = time, we have to document how things work when there is no PCE. Looks like = the PCE would act as a proxy or something. It makes sense to me that the network management information may be digged = from a gateway anyway for all sorts on non-IP world compatibility. Cc'ing C= OMAP=20 Pascal -----Original Message----- From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of Q= in Wang Sent: lundi 18 mars 2013 20:42 To: Thomas Watteyne Cc: IETF 6TSCH Subject: Re: [6tsch] Interaction between RPL and PCE Thomas, I'm not very familiar with PCE protocol. According to my knowledge, there a= re extensions of PCE protocol corresponding to different protocols like GMP= LS. So, maybe a extension of PCE for 6tus is needed, which computes the tra= ck for given multihop path and bandwidth requirement, or the track for give= n topology and end-to-end bandwidth requirement. How do you think? Qin > Qin, > > Please see inline. > > On Mon, Mar 18, 2013 at 10:25 AM, Qin Wang wrote: > >> Thomas, >> >> I think for a data flow, there are three elements needed to be=20 >> defined or scheduled explicitly or implicitly: >> (1) multihop path, i.e. who is the next hop neighbor >> (2) bandwidth and Qos requirement >> (3) cell set (i.e. bundle) to implement the bandwidth >> >> In case-1, all of the three elements are determined by PCE, and RPL=20 >> is just a backup and works on slot-aloha cells. Correct? >> > > I believe that's correct. BTW, I'm not per se advocating for this=20 > solution, but it seems to be the approach=20 > draft-ietf-roll-rpl-industrial-applicability > takes. > > >> In case2, element(1) is determined by RPL based on Rank, and=20 >> element(3) is determined by PCE. But, who will determine element(2)?=20 >> by PCE or by some entity like RSVP/NSIS or DSCP? >> >> > Agreed. It relatively straightforward for a PCE to compute a schedule=20 > and distribute that into the network, but how does it figure out what=20 > the requirements are from the nodes in the network. Could we reuse a=20 > "PCE requirements" protocol out there? > > >> Qin >> >> > [subject was: Scope: 6LoWPAN + 1] >> > >> > Maria Rita, >> > >> > I fully agree with Pascal's suggestion to have the PCE only talk to >> one >> of >> > the two sides on a on-hop link, and have 6tus be in charge to=20 >> > telling >> the >> > other side to reserve the same cell. I believe Qin has also >> acknowledged >> > this, and has agreed to put this mechanism into 6tus. This would >> probably >> > mean adding some option in the 6tus message format saying "this is=20 >> > not >> a >> > negociation for a soft cell, but an order for you to add this hard >> cell". >> > >> > All, >> > >> > I believe Maria Rita is touching a very important point we haven't=20 >> > had time to discuss last week in Orlando, but which I believe is=20 >> > essential: how >> do >> > RPL and the PCE interact? The PCE can have complete knowledge of=20 >> > the network topology and the network traffic, so besides L2=20 >> > resource allocation, it could also make routing decision, i.e.=20 >> > build the track >> it >> > believe is best fit. >> > >> > draft-ietf-roll-rpl-industrial-applicability-00 also states similar >> ideas: >> > "The domain of applicability for the RPL protocol may include all >> phases >> > but the Normal Operation phase, where the bandwidth allocation and=20 >> > the *routes are usually optimized by an external Path Computing=20 >> > Engine (PCE)*. >> [...] >> > Additionally, it could be envisioned to include RPL in the normal=20 >> > operation provided that a new Objective Function is defined that=20 >> > actually >> interacts >> > with the PCE is order to establish the reference topology, in which >> case >> > *RPL >> > operations would only apply to emergency repair actions*. when the=20 >> > reference topology becomes unusable for some failure, and as long=20 >> > as >> the >> > problem persists." >> > >> > This shot-circuits RPL. >> > >> > The two use cases I can see are: >> > 1. the PCE makes decisions without RPL's intervention. RPL runs in=20 >> > the background for emergency repair actions only. >> > 2. RPL sets up multi-hop routes which the PCE uses for building >> tracks. >> > That is, the PCE only performs L2 resource allocation. >> > >> > Do we agree to use only use case 1? If we go for 2, how does the=20 >> > PCE >> get >> > information about RPL routes (especially in storing mode)? >> > >> > Thomas >> > >> > On Mon, Mar 18, 2013 at 2:06 AM, Maria Rita PALATTELLA <=20 >> > maria-rita.palattella@uni.lu> wrote: >> > >> >> Hi Qin, and all, >> >> Sorry for coming back to this discussion after some time, but I >> wanted >> >> to >> >> raise and clarify a point. >> >> >> >> Qin>>>(2) If there is PCE, there may be different setting. For >> example, >> >> PCE is in charge for reserving both multiple hop path (i.e. every >> next >> >> hop >> >> Qin>>>neighbor) and cells; or PCE is just in charge for reserving=20 >> >> Qin>>>the >> >> multiple hop path and leaving cell reservation to local, and the=20 >> >> distributed cell reservation will meet the bandwidth requirement=20 >> >> from multiple hop path reservation. In the first case, hard Qin>>>=20 >> >> cell reservation will be used. >> >> >> >> Qin >>>(3)If there is no PCE, both multi-hop path and cells are >> reserved >> >> in local. >> >> Qin>>For example, RPL + soft cell reservation in 6tus. >> >> >> >> From my point of view (and thinking about TASA implementation),=20 >> >> the >> PCE >> >> shouldn't be in charge for reserving the multiple hop path. But=20 >> >> the routing protocol (i.e., RPL in our case) should take care of=20 >> >> the next hop neighbor selection. >> >> When a centralized approach is adopted, the PCE will schedule the >> cells >> >> (i.e., hard cells according to 6tus terminology). >> >> While, when a distributed solution is used, 6tus will allocate the >> soft >> >> cells. >> >> >> >> In the centralized scenario with the PCE, to avoid the exchange of >> many >> >> signaling messages, for setting up the schedule, we may think (as >> Pascal >> >> was suggesting during one of the last call) to use some hybrid=20 >> >> solutions. >> >> In other words, if PCE allocates (timeoffset1, channeloffset3,=20 >> >> slotframe1, >> >> TX) to node A for transmitting to node B, then, node B could know=20 >> >> locally from node A, (and not from the PCE), that the cell=20 >> >> (timeoffset1, channeloffset3, slotframe1, RX) has been reserved to=20 >> >> it, for >> receiving >> >> from >> >> node A. >> >> We may try to include some functionality in 6tus layer in order to=20 >> >> manage such situation. >> >> What do you think? >> >> >> >> Maria Rita >> >> >> >> >> >> >> --------------------------------------------------------------------- >> ------------------------------------------- >> >> > On 3/14/13 9:02 PM, Paul Chilton wrote: >> >> >>>- optionally a PCE sits on the backbone and drives the LLNs'=20 >> >> >>>TSCH schedules. >> >> > >> >> > Ah, maybe understood. It doesn't say that existence of PCE is >> >> optional. >> >> > It says that it's optional to put PCE in the backbone. It=20 >> >> > doesn't preclude to put it on BBR. Correct ? >> >> > >> >> > Shoichi >> >> > _______________________________________________ >> >> > 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 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 Return-Path: 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 F1CC921F8F4A for <6tsch@ietfa.amsl.com>; Thu, 21 Mar 2013 16:14:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] 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 qBdOsX6rg9Gr for <6tsch@ietfa.amsl.com>; Thu, 21 Mar 2013 16:14:09 -0700 (PDT) Received: from shiva.imag.fr (mx1.imag.fr [IPv6:2001:660:5301:6::5]) by ietfa.amsl.com (Postfix) with ESMTP id 3884321F8E1C for <6tsch@ietf.org>; Thu, 21 Mar 2013 16:13:52 -0700 (PDT) Received: from globule.imag.fr (globule.imag.fr [129.88.34.238]) by shiva.imag.fr (8.13.8/8.13.8) with ESMTP id r2LNDdqX016837 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Mar 2013 00:13:39 +0100 Received: from Thassos.local (109-93-238-162.dynamic.isp.telekom.rs [109.93.238.162]) (authenticated bits=0) by globule.imag.fr (8.13.8/8.13.8) with ESMTP id r2LNDdAp012397 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Mar 2013 00:13:41 +0100 Message-ID: <514B951E.6030604@imag.fr> Date: Fri, 22 Mar 2013 00:17:50 +0100 From: =?UTF-8?B?Qm9nZGFuIFBhdmtvdmnEhw==?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------070302060009010106000401" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (shiva.imag.fr [129.88.30.5]); Fri, 22 Mar 2013 00:13:40 +0100 (CET) X-IMAG-MailScanner-Information: Please contact MI2S MIM for more information X-MailScanner-ID: r2LNDdqX016837 X-IMAG-MailScanner: Found to be clean X-IMAG-MailScanner-SpamCheck: X-IMAG-MailScanner-From: bogdan.pavkovic@imag.fr MailScanner-NULL-Check: 1364512421.42255@tGb3rSLZnyOIwG5V3J3sWA Cc: Thomas Watteyne , "6tsch@ietf.org" <6tsch@ietf.org> Subject: Re: [6tsch] Agenda for the call March 22nd, 2013 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 23:14:11 -0000 This is a multi-part message in MIME format. --------------070302060009010106000401 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Dear all, I would also like to hop on this standardization train (to re-use the example with Boris). Since Thomas introduced me to the activities of 6TSCH, I got exited about the possibility to work on this thematic. I do not have a prior active standardization experience, but I would like to learn more. Nevertheless, I am familiar with RPL and 802.15.4 (e). In fact, for my thesis I was considering the scientific and practical challenges related to cohabitation of 802.15.4 and RPL. I already had a chance to catch up on the abundant discussion on the mailing list, and I will join you for tomorrow's call (menu). Best regards, Bogdan Pavković https://sites.google.com/site/bogdanpavkovicpersonal/ http://drakkar.imag.fr/bogdan phone: +381 62 184 2 898 Skype: pavkovic_bogdan On 3/21/13 5:55 PM, Pascal Thubert (pthubert) wrote: > > Dear all: > > The focus for tomorrow will be to agree on use cases and derive a > problem statement. Please keep in mind that the call will be recorded > and the record published. > > We already have a list that we can review: > > - Wireless Process Control (main source for us) > > * control loops (requires a global optimization of routes for > jitter an latency – thus computed by a PCE -, flow (over) > provisioning, duocast, with static multipath hard slot allocation. > > * control loop plan B (requires self-healing -thus distributed- > routing,) > > * supervisory flows (requires determinism up to the backbone > > * management (requires a separate topology – a RPL instance - that > does not break) > > * alerts (bursty, unexpected, dynamic slot allocation, prioritization) > > * monitoring of lots of lesser importance stuff like corrosion > (requires low cost scalability – this distributed routing ) > > * cranes that are mobile within a range (requires dynamicity on the > last hop(s) whre the mobility happens and may be deterministic up to > that point) > > * large plants (requires thousands of devices– thus a backbone – > within a subnet – to avoid renumbering) > > * non-production episodes (requires fast and autonomic behavior – > again distributed routing) > > * coexistence with legacy devices (requires a common management above) > > -Smart cities/infrastructures > *(road,street) traffic control (requires increase of bw as more > traffic in the road) > *smart urban parking (requires redundancy of routes an > over-provision as RF degrades with cars on top of the sensors) > > * green zones. Monitor moisture in gardens, trigger watering. > > * city lights monitoring. Requires marge scale meshes > > - building automation. > > * requires redundancy as RF degrades when there are changes on the > environment, doors, moving metallic apparel, etc..) > > * can be long distance this many hops. Can use lower frequencies to > gain range. > > - vehicular automation. > > * We can save copper for most of the man to machine interfaces, > which translates in both lower price and lower gas consumption. > > - commercial automation. > > * asset tracking operations on the move (again mobility, and dynamics). > > * monitoring e.g. temperature of freezers, intrusion sensors, … > > Please bring your own thoughts so we can converge at the call : ) > > As an appetizer, we can start with > > * summary overview Orlando meeting (10 minutes) > > o agendas two meetings > o 4 drafts presented > o TODO: 6tus, add ability for a PCE to set hard cells on one > side only (text already changed) > o TODO: typos > o TODO: terminology > > Then the entrée (40 minutes) > > * charter use cases: > > o review the list above > o validate the list of derived problems to be solved > o focus on what TSCH is good at: reliability, low-power > consumption, traffic engineering > > for dessert > > * open technical discussions > > o synchronization between BBRs > > + summarize and discuss proposal > > o slotframes, cells and priorities > > + summarize and discuss proposal > > o interaction between RPL and PCE > > + summarize current state of the discussion > > ** > > Please let us know if you wish to add / amend stuff in the above : ) > > Cheers, > > Pascal > > PS, call info is as always: > > > Topic: 6TSCH Weekly > Date: Every Friday, from Friday, March 8, 2013 to Friday, March 7, 2014 > Time: 8:00 am, Pacific Standard Time (San Francisco, GMT-08:00) > Meeting Number: 206 802 913 > Meeting Password: sixtus > > > ------------------------------------------------------- > To join the online meeting (Now from mobile devices!) > ------------------------------------------------------- > 1. Go to > https://cisco.webex.com/ciscosales/j.php?ED=219615007&UID=0&PW=NZTRkNDAwOTE1&RT=MiM0 > > 2. Enter your name and email address. > 3. Enter the meeting password: sixtus > 4. Click "Join Now". > > To view in other time zones or languages, please click the link: > https://cisco.webex.com/ciscosales/j.php?ED=219615007&UID=0&PW=NZTRkNDAwOTE1&ORT=MiM0 > > > ---------------------------------------------------------------- > ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes > ---------------------------------------------------------------- > > The affected toll free numbers are: (866) 432-9903 for the San > Jose/Milpitas area and (866) 349-3520 for the RTP area. > > Please dial the local access number for your area from the list below: > - San Jose/Milpitas (408) area: 525-6800 > - RTP (919) area: 392-3330 > > ------------------------------------------------------- > To join the teleconference only > ------------------------------------------------------- > 1. Dial into Cisco WebEx (view all Global Access Numbers at > http://cisco.com/en/US/about/doing_business/conferencing/index.html > 2. Follow the prompts to enter the Meeting Number (listed above) or > Access Code followed by the # sign. > > San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330 > > US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 > > India: +91.80.4350.1111 Germany: +49.619.6773.9002 > > Japan: +81.3.5763.9394 China: +86.10.8515.5666 > > ------------------------------------------------------- > For assistance > ------------------------------------------------------- > 1. Go to https://cisco.webex.com/ciscosales/mc > 2. On the left navigation bar, click "Support". > > You can contact me at: > pthubert@cisco.com > 33-49-723 2634 > > To add this meeting to your calendar program (for example Microsoft > Outlook), click this link: > https://cisco.webex.com/ciscosales/j.php?ED=219615007&UID=0&ICS=MI&LD=1&RD=2&ST=1&SHA2=AAAAAmvICIpFyZ4imE5seTb7ijZUoMuEgw1h2pXGIGSMyQEb&RT=MiM0 > > > > > > > > http://www.webex.com > > CCP:+14085256800x206802913# > > IMPORTANT NOTICE: This WebEx service includes a feature that allows > audio and any documents and other materials exchanged or viewed during > the session to be recorded. By joining this session, you automatically > consent to such recordings. If you do not consent to the recording, > discuss your concerns with the meeting host prior to the start of the > recording or do not join the session. Please note that any such > recordings may be subject to discovery in the event of litigation. > > > > _______________________________________________ > 6tsch mailing list > 6tsch@ietf.org > https://www.ietf.org/mailman/listinfo/6tsch --------------070302060009010106000401 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Dear all,

I would also like to hop on this standardization train (to re-use the example with Boris).
Since Thomas introduced me to the activities of 6TSCH, I got exited about the possibility to work on this thematic.

I do not have a prior active standardization experience, but I would like to learn more.
Nevertheless, I am familiar with RPL and 802.15.4 (e).
In fact, for my thesis I was considering the scientific and practical challenges related to cohabitation of 802.15.4 and RPL.

I already had a chance to catch up on the abundant discussion on the mailing list,
and I will join you for tomorrow's call (menu).

Best regards,

Bogdan Pavković

https://sites.google.com/site/bogdanpavkovicpersonal/
http://drakkar.imag.fr/bogdan

phone: +381 62 184 2 898
Skype: pavkovic_bogdan
On 3/21/13 5:55 PM, Pascal Thubert (pthubert) wrote:

Dear all:

 

The focus for tomorrow will be to agree on use cases and derive a problem statement. Please keep in mind that the call will be recorded and the record published.

 

We already have a list that we can review:

- Wireless Process Control (main source for us)

   * control loops (requires a global optimization of routes for jitter an latency – thus computed by a PCE  -, flow (over) provisioning, duocast, with static multipath hard slot allocation.

   * control loop plan B (requires self-healing -thus distributed- routing,)

   * supervisory flows (requires determinism up to the backbone

   * management (requires a separate topology – a RPL instance - that does not break)

   * alerts (bursty, unexpected, dynamic slot allocation, prioritization)

   * monitoring of lots of lesser importance stuff like corrosion (requires low cost scalability – this distributed routing )

   * cranes that are mobile within a range (requires dynamicity on the last hop(s) whre the mobility happens and may be deterministic up to that point)

   * large plants (requires thousands of devices– thus a backbone – within a subnet – to avoid renumbering)

   * non-production episodes (requires fast and autonomic behavior – again distributed routing)

   * coexistence with legacy devices (requires a common management above)

 

-Smart cities/infrastructures
    *(road,street) traffic control (requires increase of bw as more traffic in the road)
    *smart urban parking (requires redundancy of routes an over-provision as RF degrades with cars on top of the sensors)   

    * green zones. Monitor moisture in gardens, trigger watering.

   * city lights monitoring. Requires marge scale meshes

 

- building automation.

  * requires redundancy as RF degrades when there are changes on the environment, doors, moving metallic apparel, etc..)

  * can be long distance this many hops. Can use lower frequencies to gain range.

 

- vehicular automation.

   * We can save copper for most of the man to machine interfaces, which translates in both lower price and lower gas consumption.

 

- commercial automation.

  *  asset tracking operations on the move (again mobility, and dynamics).

  *  monitoring e.g. temperature of freezers, intrusion sensors, …

 

 

Please bring your own thoughts so we can converge at the call : )

 

As an appetizer, we can start with

 

  • summary overview Orlando meeting (10 minutes)
    • agendas two meetings
    • 4 drafts presented
    • TODO: 6tus, add ability for a PCE to set hard cells on one side only (text already changed)
    • TODO: typos
    • TODO: terminology

 

Then the entrée (40 minutes)

 

  • charter use cases:
    • review the list above
    • validate the list of derived problems to be solved
    • focus on what TSCH is good at: reliability, low-power consumption, traffic engineering

 

for dessert

  • open technical discussions
    • synchronization between BBRs
      • summarize and discuss proposal
    • slotframes, cells and priorities
      • summarize and discuss proposal
    • interaction between RPL and PCE
      • summarize current state of the discussion

 

 

Please let us know if you wish to add / amend stuff in the above : )

 

Cheers,

 

Pascal

 

PS, call info is as always:


Topic: 6TSCH Weekly
Date: Every Friday, from Friday, March 8, 2013 to Friday, March 7, 2014
Time: 8:00 am, Pacific Standard Time (San Francisco, GMT-08:00)
Meeting Number: 206 802 913
Meeting Password: sixtus


-------------------------------------------------------
To join the online meeting (Now from mobile devices!)
-------------------------------------------------------
1. Go to https://cisco.webex.com/ciscosales/j.php?ED=219615007&UID=0&PW=NZTRkNDAwOTE1&RT=MiM0
2. Enter your name and email address.
3. Enter the meeting password: sixtus
4. Click "Join Now".

To view in other time zones or languages, please click the link:
https://cisco.webex.com/ciscosales/j.php?ED=219615007&UID=0&PW=NZTRkNDAwOTE1&ORT=MiM0

----------------------------------------------------------------
ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes
----------------------------------------------------------------

The affected toll free numbers are: (866) 432-9903 for the San Jose/Milpitas area and (866) 349-3520 for the RTP area.

Please dial the local access number for your area from the list below:
- San Jose/Milpitas (408) area: 525-6800
- RTP (919) area: 392-3330

-------------------------------------------------------
To join the teleconference only
-------------------------------------------------------
1. Dial into Cisco WebEx (view all Global Access Numbers at
http://cisco.com/en/US/about/doing_business/conferencing/index.html
2. Follow the prompts to enter the Meeting Number (listed above) or Access Code followed by the # sign.

San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330

US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117

India: +91.80.4350.1111 Germany: +49.619.6773.9002

Japan: +81.3.5763.9394 China: +86.10.8515.5666

-------------------------------------------------------
For assistance
-------------------------------------------------------
1. Go to https://cisco.webex.com/ciscosales/mc
2. On the left navigation bar, click "Support".

You can contact me at:
pthubert@cisco.com
33-49-723 2634

To add this meeting to your calendar program (for example Microsoft Outlook), click this link:
https://cisco.webex.com/ciscosales/j.php?ED=219615007&UID=0&ICS=MI&LD=1&RD=2&ST=1&SHA2=AAAAAmvICIpFyZ4imE5seTb7ijZUoMuEgw1h2pXGIGSMyQEb&RT=MiM0






http://www.webex.com

CCP:+14085256800x206802913#

IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation.

 



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

--------------070302060009010106000401-- Return-Path: 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 5D5EB21F9125 for <6tsch@ietfa.amsl.com>; Thu, 21 Mar 2013 10:09:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 Nm3HbG6xzoiV for <6tsch@ietfa.amsl.com>; Thu, 21 Mar 2013 10:09:21 -0700 (PDT) Received: from hercules.uni.lu (hercules.uni.lu [158.64.76.33]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB6F21F90C7 for <6tsch@ietf.org>; Thu, 21 Mar 2013 10:09:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,887,1355094000"; d="scan'208,217";a="23052956" Received: from unknown (HELO TPOL.uni.lux) ([10.21.2.5]) by hercules.uni.lu with ESMTP; 21 Mar 2013 18:09:16 +0100 Received: from HOSHI.uni.lux ([fe80::499:a33:4e68:4af9]) by TPOL.uni.lux ([fe80::e14d:a815:d7d8:d9a6%10]) with mapi id 14.01.0438.000; Thu, 21 Mar 2013 18:09:15 +0100 From: Maria Rita PALATTELLA To: "Pascal Thubert (pthubert)" , Thomas Watteyne , "6tsch@ietf.org" <6tsch@ietf.org> Thread-Topic: Agenda for the call March 22nd, 2013 Thread-Index: Ac4mVLDC8NseT7odSWCtQiFRnyZntgAAVkCN Date: Thu, 21 Mar 2013 17:09:15 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.34.0.8] Content-Type: multipart/alternative; boundary="_000_F085911F642A6847987ADA23E611780D18535229hoshiunilux_" MIME-Version: 1.0 Subject: Re: [6tsch] Agenda for the call March 22nd, 2013 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 17:09:22 -0000 --_000_F085911F642A6847987ADA23E611780D18535229hoshiunilux_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Pascal, thanks for the great list about use cases that you have already prepared. Here are some extra thoughts, that are in line with what we have already in= the list! Use Cases: Domotic & Home Automation/ Monitoring & Security - Energy and water use: energy and water supply consumption monitoring to o= btain advice on how to save cost and resources. - Intrusion Detection Systems: Detection of window and door openings and vi= olations to prevent intruders. Looking forward to tomorrow meeting. Best Regards, Maria Rita ________________________________ From: 6tsch-bounces@ietf.org [6tsch-bounces@ietf.org] on behalf of Pascal T= hubert (pthubert) [pthubert@cisco.com] Sent: Thursday, March 21, 2013 5:55 PM To: Thomas Watteyne; 6tsch@ietf.org Subject: [6tsch] Agenda for the call March 22nd, 2013 Dear all: The focus for tomorrow will be to agree on use cases and derive a problem s= tatement. Please keep in mind that the call will be recorded and the record= published. We already have a list that we can review: - Wireless Process Control (main source for us) * control loops (requires a global optimization of routes for jitter an = latency =96 thus computed by a PCE -, flow (over) provisioning, duocast, w= ith static multipath hard slot allocation. * control loop plan B (requires self-healing -thus distributed- routing,= ) * supervisory flows (requires determinism up to the backbone * management (requires a separate topology =96 a RPL instance - that doe= s not break) * alerts (bursty, unexpected, dynamic slot allocation, prioritization) * monitoring of lots of lesser importance stuff like corrosion (requires= low cost scalability =96 this distributed routing ) * cranes that are mobile within a range (requires dynamicity on the last= hop(s) whre the mobility happens and may be deterministic up to that point= ) * large plants (requires thousands of devices=96 thus a backbone =96 wit= hin a subnet =96 to avoid renumbering) * non-production episodes (requires fast and autonomic behavior =96 agai= n distributed routing) * coexistence with legacy devices (requires a common management above) -Smart cities/infrastructures *(road,street) traffic control (requires increase of bw as more traffic= in the road) *smart urban parking (requires redundancy of routes an over-provision a= s RF degrades with cars on top of the sensors) * green zones. Monitor moisture in gardens, trigger watering. * city lights monitoring. Requires marge scale meshes - building automation. * requires redundancy as RF degrades when there are changes on the enviro= nment, doors, moving metallic apparel, etc..) * can be long distance this many hops. Can use lower frequencies to gain = range. - vehicular automation. * We can save copper for most of the man to machine interfaces, which tr= anslates in both lower price and lower gas consumption. - commercial automation. * asset tracking operations on the move (again mobility, and dynamics). * monitoring e.g. temperature of freezers, intrusion sensors, =85 Please bring your own thoughts so we can converge at the call : ) As an appetizer, we can start with * summary overview Orlando meeting (10 minutes) * agendas two meetings * 4 drafts presented * TODO: 6tus, add ability for a PCE to set hard cells on one side on= ly (text already changed) * TODO: typos * TODO: terminology Then the entr=E9e (40 minutes) * charter use cases: * review the list above * validate the list of derived problems to be solved * focus on what TSCH is good at: reliability, low-power consumption,= traffic engineering for dessert * open technical discussions * synchronization between BBRs * summarize and discuss proposal * slotframes, cells and priorities * summarize and discuss proposal * interaction between RPL and PCE * summarize current state of the discussion Please let us know if you wish to add / amend stuff in the above : ) Cheers, Pascal PS, call info is as always: Topic: 6TSCH Weekly Date: Every Friday, from Friday, March 8, 2013 to Friday, March 7, 2014 Time: 8:00 am, Pacific Standard Time (San Francisco, GMT-08:00) Meeting Number: 206 802 913 Meeting Password: sixtus ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://cisco.webex.com/ciscosales/j.php?ED=3D219615007&UID=3D0&PW= =3DNZTRkNDAwOTE1&RT=3DMiM0 2. Enter your name and email address. 3. Enter the meeting password: sixtus 4. Click "Join Now". To view in other time zones or languages, please click the link: https://cisco.webex.com/ciscosales/j.php?ED=3D219615007&UID=3D0&PW=3DNZTRkN= DAwOTE1&ORT=3DMiM0 ---------------------------------------------------------------- ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes ---------------------------------------------------------------- The affected toll free numbers are: (866) 432-9903 for the San Jose/Milpita= s area and (866) 349-3520 for the RTP area. Please dial the local access number for your area from the list below: - San Jose/Milpitas (408) area: 525-6800 - RTP (919) area: 392-3330 ------------------------------------------------------- To join the teleconference only ------------------------------------------------------- 1. Dial into Cisco WebEx (view all Global Access Numbers at http://cisco.com/en/US/about/doing_business/conferencing/index.html 2. Follow the prompts to enter the Meeting Number (listed above) or Access = Code followed by the # sign. San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330 US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 India: +91.80.4350.1111 Germany: +49.619.6773.9002 Japan: +81.3.5763.9394 China: +86.10.8515.5666 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://cisco.webex.com/ciscosales/mc 2. On the left navigation bar, click "Support". You can contact me at: pthubert@cisco.com 33-49-723 2634 To add this meeting to your calendar program (for example Microsoft Outlook= ), click this link: https://cisco.webex.com/ciscosales/j.php?ED=3D219615007&UID=3D0&ICS=3DMI&LD= =3D1&RD=3D2&ST=3D1&SHA2=3DAAAAAmvICIpFyZ4imE5seTb7ijZUoMuEgw1h2pXGIGSMyQEb&= RT=3DMiM0 http://www.webex.com CCP:+14085256800x206802913# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns = with the meeting host prior to the start of the recording or do not join th= e session. Please note that any such recordings may be subject to discovery= in the event of litigation. --_000_F085911F642A6847987ADA23E611780D18535229hoshiunilux_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Pascal,
thanks for the great list about use cases that you have already prepared.
Here are some extra thoughts, that are in line with what we have already in= the list!
Use Cases: Domotic & Home Automation/ Monitoring & Security
- Energy and water use: energy and water supply consumption monitoring to o= btain advice on how to save cost and resources.
- Intrusion Detection Systems: Detection of window and door openings and vi= olations to prevent intruders.

Looking forward to tomorrow meeting.

Best Regards,
Maria Rita
From: 6tsch-bounces@ietf.org [6tsch-bounc= es@ietf.org] on behalf of Pascal Thubert (pthubert) [pthubert@cisco.com] Sent: Thursday, March 21, 2013 5:55 PM
To: Thomas Watteyne; 6tsch@ietf.org
Subject: [6tsch] Agenda for the call March 22nd, 2013

Dear all:

 

The focus for tomorrow will be to agree on use cases= and derive a problem statement. Please keep in mind that the call will be = recorded and the record published.

 

We already have a list that we can review:

- Wireless Process Control (main source for us)

   * control loops (requires a global opti= mization of routes for jitter an latency =96 thus computed by a PCE  -= , flow (over) provisioning, duocast, with static multipath hard slot alloca= tion.

   * control loop plan B (requires se= lf-healing -thus distributed- routing,)

   * supervisory flows (requires determini= sm up to the backbone

   * management (requires a separate topol= ogy =96 a RPL instance - that does not break)

   * alerts (bursty, unexpected, dynamic s= lot allocation, prioritization)

   * monitoring of lots of lesser importan= ce stuff like corrosion (requires low cost scalability =96 this distributed= routing )

   * cranes that are mobile within a range= (requires dynamicity on the last hop(s) whre the mobility happens and may = be deterministic up to that point)

   * large plants (requires thousands of d= evices=96 thus a backbone =96 within a subnet =96 to avoid renumbering)

   * non-production episodes (requires fas= t and autonomic behavior =96 again distributed routing)

   * coexistence with legacy devices (requ= ires a common management above)

 

-Smart cities/infrastructures
    *(road,street) traffic control (requires increase of bw = as more traffic in the road)
    *smart urban parking (requires redundancy of routes an o= ver-provision as RF degrades with cars on top of the sensors)  &n= bsp;

    * green zones. Monitor mo= isture in gardens, trigger watering.

   * city lights monitoring. Requires m= arge scale meshes

 

- building automation.

  * requires redundancy as RF degrades = when there are changes on the environment, doors, moving metallic apparel, = etc..)

  * can be long distance this many hops. Can= use lower frequencies to gain range.

 

- vehicular automation.

   * We can save copper for most o= f the man to machine interfaces, which translates in both lower price and l= ower gas consumption.

 

- commercial automation.

  *  asset tracking operations on the m= ove (again mobility, and dynamics).

  *  monitoring e.g. temperature of fre= ezers, intrusion sensors, =85

 

 

Please bring your own thoughts so we can converge at= the call : )

 

As an appetizer, we can start with

 

  • summary overview Orlando meeting (10 min= utes)
    • agendas two meetings
    • 4 drafts presented
    • TODO: 6tus, add ability for a PCE to set hard cells on one side only (te= xt already changed)
    • TODO: typos
    • =
    • TODO: terminology

 

Then the entr=E9e (40 minutes)

 

  • charter use cases:
    • review the list above
    • validate the list of derived problems to be solved
    • focus on what TSCH is good at: reliabil= ity, low-power consumption, traffic engineering

 

for dessert

  • open technical discussions
    • synchronization between BBRs
      • summarize and discuss proposal
    • slotframes, cells and priorities
        • summarize and discuss proposal
--_000_F085911F642A6847987ADA23E611780D18535229hoshiunilux_-- Return-Path: 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 DA44F21F9132 for <6tsch@ietfa.amsl.com>; Thu, 21 Mar 2013 09:55:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 hWAZUCY8oaxm for <6tsch@ietfa.amsl.com>; Thu, 21 Mar 2013 09:55:50 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id E157F21F912B for <6tsch@ietf.org>; Thu, 21 Mar 2013 09:55:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=44638; q=dns/txt; s=iport; t=1363884949; x=1365094549; h=from:to:subject:date:message-id:mime-version; bh=TJG+YYfDfwwH+VwHZIHRnJJujdfR6U1NdErsXU20Y4Y=; b=RdMUDVyVpJyOolVxCxw7g5taJTK77r6B3InIUEz8bxS5csGqDP0LQXTO xFWIfQI3zZuWONiu0Ld1436+Z0v5SLs6hqgtBo8ocklBjlZvp896+syq2 4YBlJE8B9GqqoLImiJitJWvCh3KswpksCZY4WlQR6qbTa2xTAB9WWjXQV E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAHg6S1GtJXG+/2dsb2JhbAApFwMOhAa/PYFtgV0WdIImAQQtKBEGChUBHA4KBAgBAwM5FBACAQEDARIIiAwMLrQOjjGJBIRNEQp0CxUBDAoSB4JHYQOIP49Ej2OBMYEIEj+BbAcXBhg X-IronPort-AV: E=Sophos;i="4.84,887,1355097600"; d="scan'208,217";a="190080197" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 21 Mar 2013 16:55:48 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r2LGtlTM009073 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 21 Mar 2013 16:55:47 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.152]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Thu, 21 Mar 2013 11:55:47 -0500 From: "Pascal Thubert (pthubert)" To: Thomas Watteyne , "6tsch@ietf.org" <6tsch@ietf.org> Thread-Topic: Agenda for the call March 22nd, 2013 Thread-Index: Ac4mVLDC8NseT7odSWCtQiFRnyZntg== Date: Thu, 21 Mar 2013 16:55:47 +0000 Deferred-Delivery: Thu, 21 Mar 2013 16:55:00 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.49.80.30] Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD835D015AAxmbrcdx01ciscoc_" MIME-Version: 1.0 Subject: [6tsch] Agenda for the call March 22nd, 2013 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 16:55:56 -0000 --_000_E045AECD98228444A58C61C200AE1BD835D015AAxmbrcdx01ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all: The focus for tomorrow will be to agree on use cases and derive a problem s= tatement. Please keep in mind that the call will be recorded and the record= published. We already have a list that we can review: - Wireless Process Control (main source for us) * control loops (requires a global optimization of routes for jitter an = latency - thus computed by a PCE -, flow (over) provisioning, duocast, wit= h static multipath hard slot allocation. * control loop plan B (requires self-healing -thus distributed- routing,= ) * supervisory flows (requires determinism up to the backbone * management (requires a separate topology - a RPL instance - that does = not break) * alerts (bursty, unexpected, dynamic slot allocation, prioritization) * monitoring of lots of lesser importance stuff like corrosion (requires= low cost scalability - this distributed routing ) * cranes that are mobile within a range (requires dynamicity on the last= hop(s) whre the mobility happens and may be deterministic up to that point= ) * large plants (requires thousands of devices- thus a backbone - within = a subnet - to avoid renumbering) * non-production episodes (requires fast and autonomic behavior - again = distributed routing) * coexistence with legacy devices (requires a common management above) -Smart cities/infrastructures *(road,street) traffic control (requires increase of bw as more traffic= in the road) *smart urban parking (requires redundancy of routes an over-provision a= s RF degrades with cars on top of the sensors) * green zones. Monitor moisture in gardens, trigger watering. * city lights monitoring. Requires marge scale meshes - building automation. * requires redundancy as RF degrades when there are changes on the enviro= nment, doors, moving metallic apparel, etc..) * can be long distance this many hops. Can use lower frequencies to gain = range. - vehicular automation. * We can save copper for most of the man to machine interfaces, which tr= anslates in both lower price and lower gas consumption. - commercial automation. * asset tracking operations on the move (again mobility, and dynamics). * monitoring e.g. temperature of freezers, intrusion sensors, ... Please bring your own thoughts so we can converge at the call : ) As an appetizer, we can start with * summary overview Orlando meeting (10 minutes) * agendas two meetings * 4 drafts presented * TODO: 6tus, add ability for a PCE to set hard cells on one side on= ly (text already changed) * TODO: typos * TODO: terminology Then the entr=E9e (40 minutes) * charter use cases: * review the list above * validate the list of derived problems to be solved * focus on what TSCH is good at: reliability, low-power consumption,= traffic engineering for dessert * open technical discussions * synchronization between BBRs * summarize and discuss proposal * slotframes, cells and priorities * summarize and discuss proposal * interaction between RPL and PCE * summarize current state of the discussion Please let us know if you wish to add / amend stuff in the above : ) Cheers, Pascal PS, call info is as always: Topic: 6TSCH Weekly Date: Every Friday, from Friday, March 8, 2013 to Friday, March 7, 2014 Time: 8:00 am, Pacific Standard Time (San Francisco, GMT-08:00) Meeting Number: 206 802 913 Meeting Password: sixtus ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://cisco.webex.com/ciscosales/j.php?ED=3D219615007&UID=3D0&PW= =3DNZTRkNDAwOTE1&RT=3DMiM0 2. Enter your name and email address. 3. Enter the meeting password: sixtus 4. Click "Join Now". To view in other time zones or languages, please click the link: https://cisco.webex.com/ciscosales/j.php?ED=3D219615007&UID=3D0&PW=3DNZTRkN= DAwOTE1&ORT=3DMiM0 ---------------------------------------------------------------- ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes ---------------------------------------------------------------- The affected toll free numbers are: (866) 432-9903 for the San Jose/Milpita= s area and (866) 349-3520 for the RTP area. Please dial the local access number for your area from the list below: - San Jose/Milpitas (408) area: 525-6800 - RTP (919) area: 392-3330 ------------------------------------------------------- To join the teleconference only ------------------------------------------------------- 1. Dial into Cisco WebEx (view all Global Access Numbers at http://cisco.com/en/US/about/doing_business/conferencing/index.html 2. Follow the prompts to enter the Meeting Number (listed above) or Access = Code followed by the # sign. San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330 US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 India: +91.80.4350.1111 Germany: +49.619.6773.9002 Japan: +81.3.5763.9394 China: +86.10.8515.5666 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://cisco.webex.com/ciscosales/mc 2. On the left navigation bar, click "Support". You can contact me at: pthubert@cisco.com 33-49-723 2634 To add this meeting to your calendar program (for example Microsoft Outlook= ), click this link: https://cisco.webex.com/ciscosales/j.php?ED=3D219615007&UID=3D0&ICS=3DMI&LD= =3D1&RD=3D2&ST=3D1&SHA2=3DAAAAAmvICIpFyZ4imE5seTb7ijZUoMuEgw1h2pXGIGSMyQEb&= RT=3DMiM0 http://www.webex.com CCP:+14085256800x206802913# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns = with the meeting host prior to the start of the recording or do not join th= e session. Please note that any such recordings may be subject to discovery= in the event of litigation. --_000_E045AECD98228444A58C61C200AE1BD835D015AAxmbrcdx01ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear all:

 

The focus for tomorrow will be to agree on use cases= and derive a problem statement. Please keep in mind that the call will be = recorded and the record published.

 

We already have a list that we can review:

- Wireless Process Control (main source for us)

   * control loops (requires a global opti= mization of routes for jitter an latency – thus computed by a PCE&nbs= p; -, flow (over) provisioning, duocast, with static multipath hard slot al= location.

   * control loop plan B (requires se= lf-healing -thus distributed- routing,)

   * supervisory flows (requires determini= sm up to the backbone

   * management (requires a separate topol= ogy – a RPL instance - that does not break)

   * alerts (bursty, unexpected, dynamic s= lot allocation, prioritization)

   * monitoring of lots of lesser importan= ce stuff like corrosion (requires low cost scalability – this distrib= uted routing )

   * cranes that are mobile within a range= (requires dynamicity on the last hop(s) whre the mobility happens and may = be deterministic up to that point)

   * large plants (requires thousands of d= evices– thus a backbone – within a subnet – to avoid renu= mbering)

   * non-production episodes (requires fas= t and autonomic behavior – again distributed routing)

   * coexistence with legacy devices (requ= ires a common management above)

 

-Smart cities/infrastructures
    *(road,street) traffic control (requires increase of bw = as more traffic in the road)
    *smart urban parking (requires redundancy of routes an o= ver-provision as RF degrades with cars on top of the sensors)  &n= bsp;

    * green zones. Monitor mo= isture in gardens, trigger watering.

   * city lights monitoring. Requires m= arge scale meshes

 

- building automation.

  * requires redundancy as RF degrades = when there are changes on the environment, doors, moving metallic apparel, = etc..)

  * can be long distance this many hops. Can= use lower frequencies to gain range.

 

- vehicular automation.

   * We can save copper for most o= f the man to machine interfaces, which translates in both lower price and l= ower gas consumption.

 

- commercial automation.

  *  asset tracking operations on the m= ove (again mobility, and dynamics).

  *  monitoring e.g. temperature of fre= ezers, intrusion sensors, …

 

 

Please bring your own thoughts so we can converge at= the call : )

 

As an appetizer, we can start with

 

  • summary overview = Orlando meeting (10 minutes)
    • agendas two meeti= ngs
    • TODO: 6tus, add ability for a PCE to set hard cells on o= ne side only (text already changed)
    • TODO: typos
    • TODO: terminology

 

Then the entr=E9e (40 minutes)

 

  • charter use cases= :
    • review the list a= bove
    • validate the list of derived problems to be solved
    • focus on what TSCH is g= ood at: reliability, low-power consumption, traffic engineering<= /li>

 

for dessert

  • open technical di= scussions
    • synchronization = between BBRs
      • summarize and dis= cuss proposal
    • slotframes, cells= and priorities
      • summarize and dis= cuss proposal
    • interaction betw= een RPL and PCE
      • summarize curren= t state of the discussion

 

 <= /b>

Please let us know if you wish to add / amend stuff = in the above : )

 

Cheers,

 

Pascal

 

PS, call info is as always:


Topic: 6TSCH Weekly
Date: Every Friday, from Friday, March 8, 2013 to Friday, March 7, 2014 Time: 8:00 am, Pacific Standard Time (San Francisco, GMT-08:00)
Meeting Number: 206 802 913
Meeting Password: sixtus


-------------------------------------------------------
To join the online meeting (Now from mobile devices!)
-------------------------------------------------------
1. Go to https://cisco.webex.com/ciscosales/j.php?ED=3D219615007&UID=3D0&PW= =3DNZTRkNDAwOTE1&RT=3DMiM0
2. Enter your name and email address.
3. Enter the meeting password: sixtus
4. Click "Join Now".

To view in other time zones or languages, please click the link:
https://cisco= .webex.com/ciscosales/j.php?ED=3D219615007&UID=3D0&PW=3DNZTRkNDAwOT= E1&ORT=3DMiM0

----------------------------------------------------------------
ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes
----------------------------------------------------------------

The affected toll free numbers are: (866) 432-9903 for the San Jose/Milpita= s area and (866) 349-3520 for the RTP area.

Please dial the local access number for your area from the list below:
- San Jose/Milpitas (408) area: 525-6800
- RTP (919) area: 392-3330

-------------------------------------------------------
To join the teleconference only
-------------------------------------------------------
1. Dial into Cisco WebEx (view all Global Access Numbers at
http://cisco.com/en/US/about/doing_business/conferen= cing/index.html
2. Follow the prompts to enter the Meeting Number (listed above) or Access = Code followed by the # sign.

San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330

US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117

India: +91.80.4350.1111 Germany: +49.619.6773.9002

Japan: +81.3.5763.9394 China: +86.10.8515.5666

-------------------------------------------------------
For assistance
-------------------------------------------------------
1. Go to https://cisco.webex.com/ciscosales/mc
2. On the left navigation bar, click "Support".

You can contact me at:
pthubert@cisco.com
33-49-723 2634

To add this meeting to your calendar program (for example Microsoft Outlook= ), click this link:
https:= //cisco.webex.com/ciscosales/j.php?ED=3D219615007&UID=3D0&ICS=3DMI&= amp;LD=3D1&RD=3D2&ST=3D1&SHA2=3DAAAAAmvICIpFyZ4imE5seTb7ijZUoMu= Egw1h2pXGIGSMyQEb&RT=3DMiM0






http://www.webex.com=

CCP:+14085256800x206802913#

IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the= start of the recording or do not join the session. Please note that any su= ch recordings may be subject to discovery in the event of litigation.

 

--_000_E045AECD98228444A58C61C200AE1BD835D015AAxmbrcdx01ciscoc_-- Return-Path: 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 18BC221F9129 for <6tsch@ietfa.amsl.com>; Thu, 21 Mar 2013 08:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 DG-yPv7tthjP for <6tsch@ietfa.amsl.com>; Thu, 21 Mar 2013 08:52:52 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 0CD9521F9128 for <6tsch@ietf.org>; Thu, 21 Mar 2013 08:52:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7764; q=dns/txt; s=iport; t=1363881172; x=1365090772; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=FAM0fD2MUYcjpsrPnjPI7SHlA1ui+ECtJNpopwMecQE=; b=daeL1LKARlXJVVRPQHZFKNaXilzfrif7GioEfnJuum9a7hmiThpFM0ze nO6quHS2OzWowgGPzMBt0wQTk7SS0dPFZvXMgN9GCZ+tSapNPS9SqsuHb /ovoSoC26yt4zLLoRBFXSe5b/eg57cNfwCbHpMg3KKQDHNO8QkL6YO+7M s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAAoqS1GtJV2c/2dsb2JhbABDDogRvRdrbRZ0giQBAQEDAQEBASAROgsFBwQCAQgRBAEBAQICBh0DAgICJQsUAQgIAgQBDQUIE4dzBgywTJI9BIEjjCgXfiYLBwaCJzJhA6dmgks/gig X-IronPort-AV: E=Sophos;i="4.84,887,1355097600"; d="scan'208";a="190015534" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 21 Mar 2013 15:52:51 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r2LFqpK4029741 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 21 Mar 2013 15:52:51 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.152]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Thu, 21 Mar 2013 10:52:51 -0500 From: "Pascal Thubert (pthubert)" To: Qin Wang , Thomas Watteyne Thread-Topic: [6tsch] focussing on charter: use cases Thread-Index: AQHOJkOrlF66vDjlP0Gzpg2SDIP3GpiwPG7Q Date: Thu, 21 Mar 2013 15:52:50 +0000 Deferred-Delivery: Thu, 21 Mar 2013 15:52:00 +0000 Message-ID: References: <0684a7f8d22904729c69741e6e1e44fd.squirrel@calmail.berkeley.edu> In-Reply-To: <0684a7f8d22904729c69741e6e1e44fd.squirrel@calmail.berkeley.edu> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.49.80.30] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "6tsch@ietf.org" <6tsch@ietf.org> Subject: Re: [6tsch] focussing on charter: use cases 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 15:52:53 -0000 SSBhZ3JlZSBRaW4uDQoNCkZhY3RvcnkgYXV0b21hdGlvbiBpcyBvdXQgb2Ygc2NvcGUuIFdlIGNh biByZWZlciB0byBUb20ncyBhbmFseXNpcyB0byBzaG93IHRoYXQuDQpBbmQgeWVzLCBQcm9jZXNz IGNvbnRyb2wgaXMgdGhlIHNvdXJjZSBvZiBtb3N0IG9mIG91ciB1c2UgY2FzZSwgYWdhaW4gcGVy IFRvbSdzIGRyYWZ0IGluIFJPTEwuDQoNCkkgdGhpbmsgd2UgY2FuIGZpbmQgYSBudW1iZXIgb2Yg dXNlIGNhc2VzIHRoYXQgbGV2ZXJhZ2UgdGhlIGNhcGFiaWxpdGllcyB0aGF0IFRob21hcyBwb2lu dGVkIG91dCBpbiAqLWF1dG9tYXRpb24gKGFwYXJ0IGZyb20gZmFjdG9yeTogKSkgLCB3aGV0aGVy IGl0IGlzIG9wZW4gb3IgY2xvc2VkIGxvb3AuDQotIGJ1aWxkaW5nIGF1dG9tYXRpb24uIFdlIGNh biByZXBsYWNlIGEgbnVtYmVyIG9mIGV4aXN0aW5nIHByb3ByaWV0YXJ5IHRlY2hub2xvZ2llcyB3 aXRoIDZUU0NIIHRvIGNvbnRyb2wgdGhlIGJ1aWxkaW5nIGVuZXJneSBzcGVuZGluZy4NCi0gdmVo aWN1bGFyIGF1dG9tYXRpb24uIFdlIGNhbiBzYXZlIGNvcHBlciBmb3IgbW9zdCBvZiB0aGUgbWFu IHRvIG1hY2hpbmUgaW50ZXJmYWNlcywgd2hpY2ggdHJhbnNsYXRlcyBpbiBib3RoIGxvd2VyIHBy aWNlIGFuZCBsb3dlciBnYXMgY29uc3VtcHRpb24uDQotIGNvbW1lcmNpYWwgYXV0b21hdGlvbi4g QXMgeW91IHN1Z2dlc3QsIHdlIGNhbiBkbyBhc3NldCB0cmFja2luZyBvcGVyYXRpb25zIG9uIHRo ZSBtb3ZlLCByZXBvcnQgdGVtcGVyYXR1cmUgb2YgZnJlZXplcnMuDQoNCkZvciBoZWFsdGggY2Fy ZSwgSSdkIGFncmVlIGJ1dCB3ZSBoYXZlIHRvIGJlIHZlcnkgY2F1dGlvdXMgaW4gd2hhdCB3ZSBj bGFpbS4gVGhlcmUgaXMgc28gbXVjaCByZWd1bGF0aW9uIGFyb3VuZCB0aGF0IHdlIGNhbm5vdCBj b21taXQgdGhhdCB0aGUgdGVjaG5vbG9neSBpcyBnb29kIGVub3VnaCB0byByZXBsYWNlIGEgd2ly ZSB3aGljaCBpcyBzb21ldGltZXMgaW1wb3NlZCBieSBsYXcsIGFjdHVhbGx5LiANCg0KQmFzaWNh bGx5LCBJJ2Qgc2F5IHRoYXQgNlRTQ0ggY2FuIHBsYXkgbWFueSBwbGFjZXMgd2hlcmUgcGVvcGxl IGV4cGVjdGVkIHppZ2JlZSBidXQgZGlkIG5vdCBmaW5kIGl0IHJlbGlhYmxlIGVub3VnaC4gDQoN ClBhc2NhbA0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiA2dHNjaC1ib3Vu Y2VzQGlldGYub3JnIFttYWlsdG86NnRzY2gtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IFFpbiBXYW5nDQpTZW50OiBqZXVkaSAyMSBtYXJzIDIwMTMgMTU6NTINClRvOiBUaG9tYXMgV2F0 dGV5bmUNCkNjOiA2dHNjaEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFs2dHNjaF0gZm9jdXNzaW5n IG9uIGNoYXJ0ZXI6IHVzZSBjYXNlcw0KDQpQYXNjYWwgYW5kIFRob21hcywNCg0KSSBhZ3JlZSBp dCBpcyB2ZXJ5IGltcG9ydGFudCB0byBzcGVjaWZ5IHRoZSB1c2UgY2FzZXMgd2hpY2ggNnR1cyB3 aWxsIHN1cHBvcnQuIEhlcmUgaXMgc29tZSBjb21tZW50cyBhbmQgc3VnZ2VzdGlvbnMuDQoNCigx KSBSZWdhcmRpbmcgdG8gaW5kdXN0cnkgYXV0b21hdGlvbiwgSSB0aGluayBpdCBtYXkgYmUgYmV0 dGVyIHRvIGRlc2NyaWJlIFByb2Nlc3MgQXV0b21hdGlvbiBhbmQgRmFjdG9yeSBBdXRvbWF0aW9u IHNlcGFyYXRlbHkuDQoNCigyKSBPdGhlciBwb3RlbnRpYWwgdXNlIGNhc2VzOg0KICAgLSBIZWFs dGggY2FyZQ0KICAgLSBBc3NldCB0cmFja2luZyBhbmQgbW9uaXRvcmluZw0KICAgLSBMb2NhdGlv biBiYXNlZCBzZXJ2aWNlDQoNClFpbg0KDQoNCg0KPiBQYXNjYWwsIGFsbCwNCj4NCj4gQWJzb2x1 dGVseSBhZ3JlZWQuIEkgYmVsaWV2ZSB3ZSBoYXZlIHN0YXJ0ZWQgZXhwbG9yaW5nIHF1aXRlIGEg Yml0LCANCj4gZW5vdWdoIHRvIGhhdmUgYSBjbGVhciB1bmRlcnN0YW5kaW5nIG9mIHdoYXQgd2Ug Y2FuIGFjaGlldmUgd2l0aCB0aGlzIA0KPiB0ZWNobm9sb2d5IGFzIGEgV0cuIFNvIGxldCdzIHNw ZW5kIHNvbWUgdGltZSBvbiB1c2UgY2FzZXMgYW5kIGJ1aWxkaW5nIA0KPiBhIGdvb2QgY2FzZSB0 byBjb252aW5jZSBhbiBBRC4NCj4NCj4gV2UgY291bGQgc3RhcnQgYnkgbGlzdGluZyB3aGF0IFRT Q0ggaXMgImdvb2QgYXQiLCBhbmQgd2hhdCBtYWtlcyBpdCANCj4gZGlmZmVyZW50IGZyb20gb3Ro ZXIgc29sdXRpb25zLiBJIHNlZSB0aGUgZm9sbG93aW5nOg0KPiAtIHJlbGlhYmlsaXR5OiA1IDkn cyBvZiBlbmQtdG8tZW5kIHJlbGlhYmlsaXR5IGFyZSBjb21tb25wbGFjZS4NCj4gLSBsb3ctcG93 ZXI6IGFnZ3Jlc3NpdmUgcmFkaW8gZHV0eSBjeWNsaW5nIG9mIHRoZSBtb3RlJ3MgcmFkaW8geWll bGRzIA0KPiBtdWNoIGxvbmdlciBsaWZldGltZSBpbiBiYXR0ZXJ5LXBvd2VyZWQgZGV2aWNlcy4N Cj4gLSB0cmFmZmljIGVuZ2luZWVyaW5nOiB0aGUgY2xlYXIgaWRlbnRpZmljYXRpb24gb2YgcmVz b3VyY2VzIGFsbG93cyANCj4gZm9yIGZsb3cgaW5kZXBlbmRlbmNlIGFuZCBRb1MuDQo+DQo+IE9m IGNvdXJzZSwgZnJvbSB0aG9zZSBwb2ludHMsIGluZHVzdHJpYWwgYXBwbGljYXRpb25zIGltbWVk aWF0ZWx5IGNvbWUgDQo+IHRvIG1pbmQuIFlldCwgd2UgY291bGQgdGFrZSB1c2UgY2FzZXMgZnJv bSBvdGhlciBhcmVhcy4gV2UgY291bGQgZm9yIA0KPiBleGFtcGxlIHRha2UgdGhlIFJPTEwgcmVx dWlyZW1lbnQgZHJhZnRzIGFzIGEgc2tlbGV0b24gKEknbSANCj4gcGFyYXBocmFzaW5nIHNvbWUg b2YgdGhlIHBvaW50cyBYYXZpIGFuZCBBbGZyZWRvIG1hZGUpLg0KPg0KPiAtIGluZHVzdHJpYWwg YXV0b21hdGlvbi4gQSA2VFNDSCBuZXR3b3JrIGNhbiBhbGxvdyBmb3IgaGlnaCANCj4gcmVsaWFi aWxpdHksIGFuZCBkZXRlcm1pbmlzdGljIGJlaGF2aW9yLiBMaW5rIG92ZXItcHJvdmlzaW9uaW5n IGNhbiANCj4gZWZmaWNpZW50bHkgY29tYmF0IHRoZSB1bnJlbGlhYmxlIG5hdHVyZSBvZiB3aXJl bGVzcyBhbmQgcHJvdmlkZSBhIHJvYnVzdCBjb21tdW5pY2F0aW9uLg0KPiAtIGJ1aWxkaW5nIGF1 dG9tYXRpb24uIEEgNlRTQ0ggbmV0d29yayBjYW4gc2VydmUgYXMgYW4gInVtYnJlbGxhIiANCj4g bmV0d29yayBmb3IgYSBsYXJnZSBudW1iZXIgb2Ygc2Vuc2luZyBwb2ludHMgaW4gdGhlIGJ1aWxk aW5nLiBUaGVzZSANCj4gc2Vuc2luZyBwb2ludHMgY2FuIGJlIG93bmVkIGFuZCBvcGVyYXRlZCBi eSBkaWZmZXJlbnQgZW50aXRpZXMgKGUuZy4gSFZBQyBhbmQgbGlnaHRpbmcpLg0KPiBUaGUgNlRT Q0ggbmV0d29yayBhbGxvd3MgZm9yIHRoZSBkaWZmZXJlbnQgdHJhZmZpYyBmbG93cyB0byBzdGF5 IA0KPiBpbmRlcGVuZGVudCBmcm9tIG9uZSBhbm90aGVyLg0KPiAtIGJlY2F1c2Ugb2YgYSA2VFND SCBub2RlIGlzIGRlZXBseSBkdXR5IGN5Y2xlLCByZW1vdGUgc2Vuc2luZyANCj4gYXBwbGljYXRp b24gKGUuZy4gYWdyaWN1bHR1cmFsIGFwcGxpY2F0aW9ucykgY2FuIHJlbHkgb24gZW5lcmd5IA0K PiBoYXJ2ZXN0aW5nIGFzIHBvd2VyIHNvdXJjZS4NCj4gLSBBIHNtYXJ0IHVyYmFuIHBhcmtpbmcg YXBwbGljYXRpb24gY2FuIGJlbmVmaXQgZnJvbSB0aGUgcmVsaWFiaWx0eSBvZiAgDQo+IDZUU0NI IG5ldHdvcmsgc2luY2UsIGV2ZW4gdGhvdWdoIHRoZSB2ZWhpY2xlIGRldGVjdGlvbiBzZW5zb3Ig bWF5IGJlIA0KPiBzdGF0aWMsIHRoZSBjb25zdGFudCBtb3ZlbWVudCBvZiBjYXJzIGFyb3VuZCB0 aGUgc2Vuc2luZyBwb2ludHMgY2FuIA0KPiBjYXVzZSB0aGUgd2lyZWxlc3MgZW52aXJvbm1lbnQg dG8gcXVpY2tseSBjaGFuZ2UuDQo+DQo+IFRob21hcw0KPg0KPiBPbiBUdWUsIE1hciAxOSwgMjAx MyBhdCAxMjowOCBQTSwgUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KSA8IA0KPiBwdGh1YmVydEBj aXNjby5jb20+IHdyb3RlOg0KPg0KPj4gIERlYXIgTUw6KioqKg0KPj4NCj4+ICoqICoqDQo+Pg0K Pj4gVGhlIGFjdGl2aXR5IHRoYXQgd2UgZ2VuZXJhdGUgb24gdGhlIG1haWxpbmcgbGlzdCBpcyBh IGdvb2QgDQo+PiBpbmRpY2F0aW9uIHdlIHdpbGwgYmUgdmVyeSBzdWNjZXNzZnVsIGFzIGEgV0cu IEZpcnN0IHRoaW5nIGZpcnN0LCANCj4+IHRob3VnaCwgd2UgbmVlZCB0byBjcmVhdGUgdGhlIFdH IGFuZCBuZWVkIHRvIGZvY3VzIGEgbGl0dGxlIGJpdCBvbiANCj4+IHRoZSBuZWNlc3Nhcnkgc3Rl cHMgdG8gZ2V0DQo+PiB0aGVyZS4qKioqDQo+Pg0KPj4gKiogKioNCj4+DQo+PiBXZSBuZWVkIHRv IHB1dCB0b2dldGhlciBhIHJvdWdoIGNoYXJ0ZXIsIGFuZCBjb252aW5jZSBhbiBBRCwgcHJvYmFi bHkgDQo+PiBBZHJpYW4gZnJvbSBSb3V0aW5nIEFyZWEgb3IgVGVkIGZyb20gSW50ZXJuZXQgQXJl YSwgdGhhdCB3ZSBoYXZlIHJlYWwgDQo+PiBwcm9ibGVtcyB0byBzb2x2ZSBhbmQgdGhhdCB3ZSwg YXMgYSBncm91cCwgY2FuIHByb3ZpZGUgdmFsdWFibGUgYW5zd2Vycy4NCj4+IFRoZSBBRHMgYWdl bmRhcyBhcmUgdmVyeSBmdWxsIGFsbCB0aGUgdGltZSwgYnV0IGNlcnRhaW5seSBwZWFrcyANCj4+ IGFyb3VuZCB0aGUgbWVldGluZyB0aW1lcy4gU28gd2UgaGF2ZSBhYm91dCAyIHdlZWsgaW4gZnJv bnQgb2YgdXMgdG8gDQo+PiBwcmVwYXJlIGEgc29saWQNCj4+IGNhc2UuKioqKg0KPj4NCj4+ICoq ICoqDQo+Pg0KPj4gU28gSSBzdWdnZXN0IHdlIHN0ZXAgYmFjayBhIG1pbnV0ZSBmcm9tIHRoZSBk ZXRhaWxzIG9mIHRpbWUgZnJhbWVzIA0KPj4gYW5kIHByaW9yaXRpZXMgYW5kIHNwZW5kIHNvbWUg ZW5lcmd5IG9uIHRoZSB1c2UgY2FzZXMsIHRoZSBwcm9ibGVtcyANCj4+IHdlIGFyZSBzb2x2aW5n LCBhbmQgdGhlIHdvcmsgd2UgaGF2ZSB0byBkbyB0byBnZXQgdGhlcmUuIEkgbm90aWNlIGEgDQo+ PiBjb29sIGRpc2N1c3Npb24gb24gbW9iaWxpdHkgYW5kIHRoZSBwYXJ0aWN1bGFyIGNhc2Ugb2Yg YSBjcmFuZSwgd2VsbCANCj4+IHRoYXTigJlzIGEgdXNlIGNhc2UuIFdlIGFscmVhZHkgaGFkIGNl bnRyYWxpemVkIGRldGVybWluaXN0aWMgKGhhcmQgDQo+PiBzbG90KSByb3V0ZXMgZm9yIGNvbW1h bmQgYW5kIGNvbnRyb2wsIGRpc3RyaWJ1dGVkIGRldGVybWluaXN0aWMgKHNvZnQgDQo+PiBzbG90 cykgYW5kIG5vbiBkZXRlcm1pbmlzdGljIFFvUyBiYXNlZCBmbG93cy4gRG8gd2UgaGF2ZSBvdGhl cnMgDQo+PiBjYXNlcz8qKioqDQo+Pg0KPj4gKioqKg0KPj4NCj4+IENoZWVycywqKioqDQo+Pg0K Pj4gKiogKioNCj4+DQo+PiBQYXNjYWwqKioqDQo+Pg0KPj4gKiogKioNCj4+DQo+PiAqKiAqKg0K Pj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ PiA2dHNjaCBtYWlsaW5nIGxpc3QNCj4+IDZ0c2NoQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvLzZ0c2NoDQo+Pg0KPj4NCj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gNnRzY2ggbWFpbGluZyBsaXN0DQo+ IDZ0c2NoQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v NnRzY2gNCj4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCjZ0c2NoIG1haWxpbmcgbGlzdA0KNnRzY2hAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vNnRzY2gNCg== Return-Path: 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 32D2421F913E for <6tsch@ietfa.amsl.com>; Thu, 21 Mar 2013 08:28:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.498 X-Spam-Level: X-Spam-Status: No, score=-102.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 NHNJBgfT-Cue for <6tsch@ietfa.amsl.com>; Thu, 21 Mar 2013 08:28:10 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id E76A621F9142 for <6tsch@ietf.org>; Thu, 21 Mar 2013 08:28:08 -0700 (PDT) Received: from h111.viagenie.ca (h111.viagenie.ca [206.123.31.111]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 29C7E403E9; Thu, 21 Mar 2013 11:28:08 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_F308F7A3-3910-42B5-9851-E1A7DFF937D9" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Marc Blanchet In-Reply-To: Date: Thu, 21 Mar 2013 11:28:02 -0400 Message-Id: <962FC5C7-C2AF-4809-BAC9-00CFE71E90C5@viagenie.ca> References: To: Thomas Watteyne X-Mailer: Apple Mail (2.1503) Cc: "6tsch@ietf.org" <6tsch@ietf.org> Subject: Re: [6tsch] focussing on charter: use cases 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 15:28:12 -0000 --Apple-Mail=_F308F7A3-3910-42B5-9851-E1A7DFF937D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Le 2013-03-21 =E0 01:15, Thomas Watteyne a = =E9crit : > Pascal, all, >=20 > Absolutely agreed. I believe we have started exploring quite a bit, = enough to have a clear understanding of what we can achieve with this = technology as a WG. So let's spend some time on use cases and building a = good case to convince an AD. A proposed charter should have at least the following: a) problem statement/use cases b) what needs to be done in IETF c) some milestones b) is as important as a) for an AD (and c) too). Marc. >=20 > We could start by listing what TSCH is "good at", and what makes it = different from other solutions. I see the following: > - reliability: 5 9's of end-to-end reliability are commonplace. > - low-power: aggressive radio duty cycling of the mote's radio yields = much longer lifetime in battery-powered devices. > - traffic engineering: the clear identification of resources allows = for flow independence and QoS. >=20 > Of course, from those points, industrial applications immediately come = to mind. Yet, we could take use cases from other areas. We could for = example take the ROLL requirement drafts as a skeleton (I'm paraphrasing = some of the points Xavi and Alfredo made). >=20 > - industrial automation. A 6TSCH network can allow for high = reliability, and deterministic behavior. Link over-provisioning can = efficiently combat the unreliable nature of wireless and provide a = robust communication.=20 > - building automation. A 6TSCH network can serve as an "umbrella" = network for a large number of sensing points in the building. These = sensing points can be owned and operated by different entities (e.g. = HVAC and lighting). The 6TSCH network allows for the different traffic = flows to stay independent from one another. > - because of a 6TSCH node is deeply duty cycle, remote sensing = application (e.g. agricultural applications) can rely on energy = harvesting as power source. > - A smart urban parking application can benefit from the reliabilty of = 6TSCH network since, even though the vehicle detection sensor may be = static, the constant movement of cars around the sensing points can = cause the wireless environment to quickly change. >=20 > Thomas >=20 > On Tue, Mar 19, 2013 at 12:08 PM, Pascal Thubert (pthubert) = wrote: > Dear ML: >=20 > =20 >=20 > The activity that we generate on the mailing list is a good indication = we will be very successful as a WG. First thing first, though, we need = to create the WG and need to focus a little bit on the necessary steps = to get there. >=20 > =20 >=20 > We need to put together a rough charter, and convince an AD, probably = Adrian from Routing Area or Ted from Internet Area, that we have real = problems to solve and that we, as a group, can provide valuable answers. = The ADs agendas are very full all the time, but certainly peaks around = the meeting times. So we have about 2 week in front of us to prepare a = solid case. >=20 > =20 >=20 > So I suggest we step back a minute from the details of time frames and = priorities and spend some energy on the use cases, the problems we are = solving, and the work we have to do to get there. I notice a cool = discussion on mobility and the particular case of a crane, well that=92s = a use case. We already had centralized deterministic (hard slot) routes = for command and control, distributed deterministic (soft slots) and non = deterministic QoS based flows. Do we have others cases? >=20 >=20 > Cheers, >=20 > =20 >=20 > Pascal >=20 > =20 >=20 > =20 >=20 >=20 > _______________________________________________ > 6tsch mailing list > 6tsch@ietf.org > https://www.ietf.org/mailman/listinfo/6tsch >=20 >=20 > _______________________________________________ > 6tsch mailing list > 6tsch@ietf.org > https://www.ietf.org/mailman/listinfo/6tsch --Apple-Mail=_F308F7A3-3910-42B5-9851-E1A7DFF937D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 watteyne@eecs.berkeley.edu&= gt; a =E9crit :

Pascal, all,

Absolutely agreed. I = believe we have started exploring quite a bit, enough to have a clear = understanding of what we can achieve with this technology as a WG. So = let's spend some time on use cases and building a good case to convince = an AD.

A proposed charter should = have at least the following:
a) problem statement/use = cases
b) what needs to be done in IETF
c) some = milestones

b) is as important as a) for an AD =  (and c) = too).

Marc.



We could start by listing what TSCH is "good at", = and what makes it different from other solutions. I see the = following:
- reliability: 5 9's of end-to-end reliability are = commonplace.
- low-power: aggressive radio duty cycling of the mote's = radio yields much longer lifetime in battery-powered = devices.
- traffic engineering: the clear identification of = resources allows for flow independence and QoS.

Of course, from those = points, industrial applications immediately come to mind. Yet, we could = take use cases from other areas. We could for example take the ROLL = requirement drafts as a skeleton (I'm paraphrasing some of the points = Xavi and Alfredo made).

- industrial automation. A 6TSCH network can = allow for high reliability, and deterministic behavior. Link = over-provisioning can efficiently combat the unreliable nature of = wireless and provide a robust communication. 
- building automation. A 6TSCH network can = serve as an "umbrella" network for a large number of sensing points in = the building. These sensing points can be owned and operated by = different entities (e.g. HVAC and lighting). The 6TSCH network allows = for the different traffic flows to stay independent from one = another.
- because of a 6TSCH node is deeply duty = cycle, remote sensing application (e.g. agricultural applications) can = rely on energy harvesting as power source.
- A smart urban parking application can benefit = from the reliabilty of  6TSCH network since, even though the = vehicle detection sensor may be static, the constant movement of cars = around the sensing points can cause the wireless environment to quickly = change.

Thomas

On Tue, Mar = 19, 2013 at 12:08 PM, Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:

Dear ML:

 

The = activity that we generate on the mailing list is a good indication we = will be very successful as a WG. First thing first, though, we need to = create the WG and need to focus a little bit on the necessary steps to = get there.

 

We = need to put together a rough charter, and convince an AD, probably = Adrian from Routing Area or Ted from Internet Area, that we have real = problems to solve and that we, as a group, can provide valuable answers. = The ADs agendas are very full all the time, but certainly peaks around the meeting times. So we = have about 2 week in front of us to prepare a solid = case.

 

So I suggest we step back a minute from the details = of time frames and priorities and spend some energy on the use cases, = the problems we are solving, and the work we have to do to get there. I = notice a cool discussion on mobility and the particular case of a crane, well that=92s a use case. We already had = centralized deterministic (hard slot) routes for command and control, = distributed deterministic (soft slots) and non deterministic QoS based = flows. Do we have others cases?

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

= --Apple-Mail=_F308F7A3-3910-42B5-9851-E1A7DFF937D9-- Return-Path: 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 12BD221F90BC for <6tsch@ietfa.amsl.com>; Thu, 21 Mar 2013 07:52:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.492 X-Spam-Level: X-Spam-Status: No, score=-6.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 zCdZYrcNniAd for <6tsch@ietfa.amsl.com>; Thu, 21 Mar 2013 07:52:04 -0700 (PDT) Received: from cm06fe.IST.Berkeley.EDU (cm06fe.IST.Berkeley.EDU [169.229.218.147]) by ietfa.amsl.com (Postfix) with ESMTP id CB8D121F9083 for <6tsch@ietf.org>; Thu, 21 Mar 2013 07:52:04 -0700 (PDT) Received: from cm02ws.ist.berkeley.edu ([169.229.218.164] helo=calmail.berkeley.edu) by cm06fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth login:qinwang@berkeley.edu) (envelope-from ) id 1UIgqZ-0007sh-Js; Thu, 21 Mar 2013 07:52:04 -0700 Received: from 96.227.54.17 (SquirrelMail authenticated user qinwang@berkeley.edu) by calmail.berkeley.edu with HTTP; Thu, 21 Mar 2013 07:52:03 -0700 Message-ID: <0684a7f8d22904729c69741e6e1e44fd.squirrel@calmail.berkeley.edu> In-Reply-To: References: Date: Thu, 21 Mar 2013 07:52:03 -0700 From: "Qin Wang" To: "Thomas Watteyne" User-Agent: SquirrelMail/1.4.21-2.berkeley MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: "6tsch@ietf.org" <6tsch@ietf.org> Subject: Re: [6tsch] focussing on charter: use cases 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 14:52:06 -0000 Pascal and Thomas, I agree it is very important to specify the use cases which 6tus will support. Here is some comments and suggestions. (1) Regarding to industry automation, I think it may be better to describe Process Automation and Factory Automation separately. (2) Other potential use cases: - Health care - Asset tracking and monitoring - Location based service Qin > Pascal, all, > > Absolutely agreed. I believe we have started exploring quite a bit, enough > to have a clear understanding of what we can achieve with this technology > as a WG. So let's spend some time on use cases and building a good case to > convince an AD. > > We could start by listing what TSCH is "good at", and what makes it > different from other solutions. I see the following: > - reliability: 5 9's of end-to-end reliability are commonplace. > - low-power: aggressive radio duty cycling of the mote's radio yields much > longer lifetime in battery-powered devices. > - traffic engineering: the clear identification of resources allows for > flow independence and QoS. > > Of course, from those points, industrial applications immediately come to > mind. Yet, we could take use cases from other areas. We could for example > take the ROLL requirement drafts as a skeleton (I'm paraphrasing some of > the points Xavi and Alfredo made). > > - industrial automation. A 6TSCH network can allow for high reliability, > and deterministic behavior. Link over-provisioning can efficiently combat > the unreliable nature of wireless and provide a robust communication. > - building automation. A 6TSCH network can serve as an "umbrella" network > for a large number of sensing points in the building. These sensing points > can be owned and operated by different entities (e.g. HVAC and lighting). > The 6TSCH network allows for the different traffic flows to stay > independent from one another. > - because of a 6TSCH node is deeply duty cycle, remote sensing application > (e.g. agricultural applications) can rely on energy harvesting as power > source. > - A smart urban parking application can benefit from the reliabilty of > 6TSCH network since, even though the vehicle detection sensor may be > static, the constant movement of cars around the sensing points can cause > the wireless environment to quickly change. > > Thomas > > On Tue, Mar 19, 2013 at 12:08 PM, Pascal Thubert (pthubert) < > pthubert@cisco.com> wrote: > >> Dear ML:**** >> >> ** ** >> >> The activity that we generate on the mailing list is a good indication >> we >> will be very successful as a WG. First thing first, though, we need to >> create the WG and need to focus a little bit on the necessary steps to >> get >> there.**** >> >> ** ** >> >> We need to put together a rough charter, and convince an AD, probably >> Adrian from Routing Area or Ted from Internet Area, that we have real >> problems to solve and that we, as a group, can provide valuable answers. >> The ADs agendas are very full all the time, but certainly peaks around >> the >> meeting times. So we have about 2 week in front of us to prepare a solid >> case.**** >> >> ** ** >> >> So I suggest we step back a minute from the details of time frames and >> priorities and spend some energy on the use cases, the problems we are >> solving, and the work we have to do to get there. I notice a cool >> discussion on mobility and the particular case of a crane, well that’s a >> use case. We already had centralized deterministic (hard slot) routes >> for >> command and control, distributed deterministic (soft slots) and non >> deterministic QoS based flows. Do we have others cases?**** >> >> **** >> >> 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 > Return-Path: 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 0987E21F8F2F for <6tsch@ietfa.amsl.com>; Wed, 20 Mar 2013 22:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 RFEs-XuBLZi9 for <6tsch@ietfa.amsl.com>; Wed, 20 Mar 2013 22:16:18 -0700 (PDT) Received: from mail-da0-x236.google.com (mail-da0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 036B021F8F0B for <6tsch@ietf.org>; Wed, 20 Mar 2013 22:16:17 -0700 (PDT) Received: by mail-da0-f54.google.com with SMTP id p1so1418663dad.27 for <6tsch@ietf.org>; Wed, 20 Mar 2013 22:16:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=yXx68r8LGE2DJ/OzMY4eVFprJLxyDFzQynv1JXeXOhM=; b=PFaHcCVyYwCuKzDIL79G0g25x9ELb6vRLUHvqEeP3iW2DwxMhxDBSNC1kbnUHBMAM0 rbmUAMOMyiEQ6NaD/cjp4uGvKVn8vN5n6A64m6N/OUWTeGIzob+7tgwqp62a9ES7z8UO VpjiTDD8fQ/rB6IHsa1k+bpPU2fnwn63hzTSb33pm/4WUabaqv6O1kQrUwnPE7e4YHNe 7ymy+S+2aNleYR4TKvZ9gPRjas5SKo77igAVEhC5VvgxJ3dlUuYHZPbygg4aph/UTBKp 9QN0/oVZkI+1AlccHrriLnaVUtghlVJmZHtON2rU1EY6dhB3naVk8xQkIop3Zfadndx0 jQbA== X-Received: by 10.66.163.69 with SMTP id yg5mr13072310pab.109.1363842977694; Wed, 20 Mar 2013 22:16:17 -0700 (PDT) MIME-Version: 1.0 Sender: twatteyne@gmail.com Received: by 10.68.227.71 with HTTP; Wed, 20 Mar 2013 22:15:56 -0700 (PDT) In-Reply-To: References: From: Thomas Watteyne Date: Wed, 20 Mar 2013 22:15:56 -0700 X-Google-Sender-Auth: zgSdojehmQqPzuZhCHBYhIHTyHI Message-ID: To: "6tsch@ietf.org" <6tsch@ietf.org> Content-Type: multipart/alternative; boundary=047d7b6d8186370b0404d868706a Subject: Re: [6tsch] focussing on charter: use cases 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 05:16:19 -0000 --047d7b6d8186370b0404d868706a Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Pascal, all, Absolutely agreed. I believe we have started exploring quite a bit, enough to have a clear understanding of what we can achieve with this technology as a WG. So let's spend some time on use cases and building a good case to convince an AD. We could start by listing what TSCH is "good at", and what makes it different from other solutions. I see the following: - reliability: 5 9's of end-to-end reliability are commonplace. - low-power: aggressive radio duty cycling of the mote's radio yields much longer lifetime in battery-powered devices. - traffic engineering: the clear identification of resources allows for flow independence and QoS. Of course, from those points, industrial applications immediately come to mind. Yet, we could take use cases from other areas. We could for example take the ROLL requirement drafts as a skeleton (I'm paraphrasing some of the points Xavi and Alfredo made). - industrial automation. A 6TSCH network can allow for high reliability, and deterministic behavior. Link over-provisioning can efficiently combat the unreliable nature of wireless and provide a robust communication. - building automation. A 6TSCH network can serve as an "umbrella" network for a large number of sensing points in the building. These sensing points can be owned and operated by different entities (e.g. HVAC and lighting). The 6TSCH network allows for the different traffic flows to stay independent from one another. - because of a 6TSCH node is deeply duty cycle, remote sensing application (e.g. agricultural applications) can rely on energy harvesting as power source. - A smart urban parking application can benefit from the reliabilty of 6TSCH network since, even though the vehicle detection sensor may be static, the constant movement of cars around the sensing points can cause the wireless environment to quickly change. Thomas On Tue, Mar 19, 2013 at 12:08 PM, Pascal Thubert (pthubert) < pthubert@cisco.com> wrote: > Dear ML:**** > > ** ** > > The activity that we generate on the mailing list is a good indication we > will be very successful as a WG. First thing first, though, we need to > create the WG and need to focus a little bit on the necessary steps to ge= t > there.**** > > ** ** > > We need to put together a rough charter, and convince an AD, probably > Adrian from Routing Area or Ted from Internet Area, that we have real > problems to solve and that we, as a group, can provide valuable answers. > The ADs agendas are very full all the time, but certainly peaks around th= e > meeting times. So we have about 2 week in front of us to prepare a solid > case.**** > > ** ** > > So I suggest we step back a minute from the details of time frames and > priorities and spend some energy on the use cases, the problems we are > solving, and the work we have to do to get there. I notice a cool > discussion on mobility and the particular case of a crane, well that=92s = a > use case. We already had centralized deterministic (hard slot) routes for > command and control, distributed deterministic (soft slots) and non > deterministic QoS based flows. Do we have others cases?**** > > **** > > Cheers,**** > > ** ** > > Pascal**** > > ** ** > > ** ** > > _______________________________________________ > 6tsch mailing list > 6tsch@ietf.org > https://www.ietf.org/mailman/listinfo/6tsch > > --047d7b6d8186370b0404d868706a Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Pascal, all,

Absolutely agreed. I believe we have starte= d exploring quite a bit, enough to have a clear understanding of what we ca= n achieve with this technology as a WG. So let's spend some time on use= cases and building a good case to convince an AD.

We could start by listing what TSCH is "good at&qu= ot;, and what makes it different from other solutions. I see the following:=
- reliability: 5 9's of end-to-end reliability are commonpla= ce.
- low-power:=A0aggressive=A0radio duty cycling of the mote's radio= yields much longer lifetime in battery-powered devices.
- traffi= c engineering: the clear identification of resources allows for flow indepe= ndence and QoS.

Of course, from those points= , industrial applications immediately come to mind. Yet, we could take use = cases from other areas. We could for example take the ROLL requirement draf= ts as a skeleton (I'm paraphrasing some of the points Xavi and Alfredo = made).

- industrial automation. A 6TSCH network can allow for high = reliability, and=A0deterministic=A0behavior. Link over-provisioning can eff= iciently combat the unreliable nature of wireless and provide a robust comm= unication.=A0
- building automation. A 6TSCH network can serve= as an "umbrella" network for a large number of sensing points in= the building. These sensing points can be owned and operated by different = entities (e.g. HVAC and lighting). The 6TSCH network allows for the differe= nt traffic flows to stay independent from one another.
- because of a 6TSCH node is deeply duty cycle, = remote sensing application (e.g. agricultural applications) can rely on ene= rgy harvesting as power source.
- A smart u= rban parking application can benefit from the reliabilty of =A06TSCH networ= k since, even though the vehicle detection sensor may be static, the consta= nt movement of cars around the sensing points can cause the wireless enviro= nment to quickly change.

Thomas

On Tue, Ma= r 19, 2013 at 12:08 PM, Pascal Thubert (pthubert) <pthubert@cisco.com= > wrote:

Dear ML:

=A0

The activity that we generate on the mailing list is= a good indication we will be very successful as a WG. First thing first, t= hough, we need to create the WG and need to focus a little bit on the neces= sary steps to get there.

=A0

We need to put together a rough charter, and convinc= e an AD, probably Adrian from Routing Area or Ted from Internet Area, that = we have real problems to solve and that we, as a group, can provide valuabl= e answers. The ADs agendas are very full all the time, but certainly peaks around the meeting times. So we hav= e about 2 week in front of us to prepare a solid case.

=A0

So I suggest we step back a minute from the details = of time frames and priorities and spend some energy on the use cases, the p= roblems we are solving, and the work we have to do to get there. I notice a= cool discussion on mobility and the particular case of a crane, well that=92s a use case. We already had centr= alized deterministic (hard slot) routes for command and control, distribute= d deterministic (soft slots) and non deterministic QoS based flows. Do we h= ave others cases?

Cheers,

=A0

Pascal

=A0

=A0


_______________________________________________
6tsch mailing list
6tsch@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/6tsch


--047d7b6d8186370b0404d868706a-- Return-Path: 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 8401621F8BF4 for <6tsch@ietfa.amsl.com>; Tue, 19 Mar 2013 12:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.148 X-Spam-Level: X-Spam-Status: No, score=-6.148 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_MED=-4] 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 b+hnYSPddZR4 for <6tsch@ietfa.amsl.com>; Tue, 19 Mar 2013 12:37:37 -0700 (PDT) Received: from cm06fe.IST.Berkeley.EDU (cm06fe.IST.Berkeley.EDU [169.229.218.147]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD3121F8D8E for <6tsch@ietf.org>; Tue, 19 Mar 2013 12:37:37 -0700 (PDT) Received: from dhcp-33-135.eecs.berkeley.edu ([128.32.33.135]) by cm06fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:xvilajosana@eecs.berkeley.edu) (envelope-from ) id 1UI2Li-00073y-MN for 6tsch@ietf.org; Tue, 19 Mar 2013 12:37:37 -0700 Message-ID: <5148BE7A.4050409@eecs.berkeley.edu> Date: Tue, 19 Mar 2013 12:37:30 -0700 From: Xavier Vilajosana User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: 6tsch@ietf.org References: <956BA951-CF3C-4F00-A80E-73D641634224@gmail.com> <514248DA.6090403@eecs.berkeley.edu> <6A4E9484-B0D0-4F8E-AF13-C5AC74D230CF@gmail.com> <1b28192c14eed60c7a6621f6b9b02e6a.squirrel@calmail.berkeley.edu> <0B5235F3-6E4F-46AE-B59E-DE63FC47AA95@gmail.com> <5332a47730edc8ed350124947c6d9d4f.squirrel@calmail.berkeley.edu> <2b68f317c14dc5ae864813e632d55fcd.squirrel@calmail.berkeley.edu> <51475694.85d00e0a.2654.3c21@mx.google.com> <1b952faca1b2846136ff23c6723eeb63.squirrel@calmail.berkeley.edu> <51476DC1.5070707@eecs.berkeley.edu> <775F44DA-D912-4B36-B241-E176FBD585F1@gmail.com> <299D7883-A8BB-4F88-9BDD-93E5EC9B4381@gma il.com> In-Reply-To: <299D7883-A8BB-4F88-9BDD-93E5EC9B4381@gmail.com> Content-Type: multipart/alternative; boundary="------------080905050005090404070101" Subject: Re: [6tsch] R: Schemes for resource allocation in the LLN for 6tus 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 19:37:44 -0000 This is a multi-part message in MIME format. --------------080905050005090404070101 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, more uses cases that might benefit from 6tus: -Smart cities/infrastructures/industries *(road,street) traffic control (requires increase of bw as more traffic in the road) *smart urban parking (requires redundancy of routes an over-provision as RF degrades with cars on top of the sensors) *building monitoring (requires redundancy as RF degrades when there are changes on the environment, doors, movement,etc..) *industrial automation (latency, robustnes->overprovision,etc...) *metering (can be bursty) and for sure we can find several more use cases where 6tus might be *VERY* relevant. regards, Xavi On 19/03/13 12:29, Grieco wrote: > Thomas, Pascal, > > If this can serve to point out some relevant target scenarios, use > cases with some degree of mobility include: > - robotics applications > - assembly lines > - avionic systems > - radio localization and tracking > - advanced mechatronic systems > > These are the main domains Telematics lab is involved within several > research projects at Politecnico di Bari. > > Cheers > > Alfredo > > > On 19 Mar 2013, at 17:57, Thomas Watteyne > wrote: > >> Alfredo, >> >> This is an interesting use case you bring up. Do you have a specific >> use case/problem you are trying to solve? >> >> I agree with Qin that it would be great if this were a schedule-only >> decision, i.e. we change as little as possible in the mechanism (e.g. >> 6tus), but rather have the scheduling entity build an (otherwise >> normal) schedule which allows for some motes to roam around. >> >> Thomas >> >> On Tue, Mar 19, 2013 at 1:58 AM, Grieco > > wrote: >> >> Hi Qin, >> >> It does work for me: thanks for the clarification >> >> Cheers >> >> Alfredo >> >> -- >> Luigi Alfredo Grieco, PhD >> Assistant Professor >> Department of Electrical and Information Engineering >> Politecnico di Bari >> Via Orabona 4 - 70125 - Bari - Italy >> +39 080 5963 911 >> telematics.poliba.it/grieco >> Skype id: l.alfredo.grieco >> Mobile: +39 3346715672 >> >> >> On 19 Mar 2013, at 01:09, "Qin Wang" > > wrote: >> >>> Alfredo, >>> >>> I think there are two key features in your description: (1)data >>> with high >>> priority, and (2)mobility. I would like to think the two feature >>> separately. >>> >>> Regarding to the high priority, I think the QoS mechanism like >>> DSCP can >>> handle it, no matter the data flow come from static node or >>> moving node. >>> >>> Regarding to the mobility, the 6tus can support to establish >>> tracks for >>> specific purpose. Actually, the cell reservation request comes >>> from upper >>> layer, 6tus do not know the reserved cells will be used by >>> static nodes or >>> mobile nodes. In another word, upper layer can ask 6tus to >>> reserve some >>> cells or tracks or pipes which specifically used for mobile node >>> to send >>> data as you said. >>> >>> Does it make sense? >>> >>> Qin >>> >>> >>> >>>> >>>> Hi Xavi, Thomas, all >>>> >>>> The problem I am pointing out is not related only to the >>>> neighbourhood. As >>>> a matter of fact, a node would like its data be received to the >>>> sink and >>>> not only at the next hop. If for each hop to travel, a data >>>> packet should >>>> gain a cell through some request/answer handshake this would >>>> lead to high >>>> e2e delays when the depth of the tree is high and would incur >>>> useless >>>> signalling. >>>> >>>> If we think at TASA, to do an example, the schedule exactly >>>> rules the >>>> story of each packet from its generating node to the sink. I >>>> was trying to >>>> figure out how to do the same in presence of some uncertainty >>>> on the >>>> network topology. >>>> >>>> While solving this problem is something to be afforded in some >>>> scientific >>>> paper, I believe that the functionalities of 6tus and the entire >>>> architecture we are envisaging should be ready to welcome this >>>> new wave of >>>> algorithms. >>>> >>>> In other terms, I am proposing to add a limited number of >>>> "reserved pipes" >>>> to the sink that could be used to transport "only" urgent data >>>> from mobile >>>> nodes. >>>> >>>> Thomas, this could be added as general remark to the >>>> architecture or to >>>> the draft you are editing. Of course, with more details, some >>>> primitive to >>>> the 6tus draft could be added or lead to a new draft on >>>> handling mobile >>>> 6tsch nodes. >>>> >>>> Cheers :-) >>>> >>>> >>>> -- >>>> Luigi Alfredo Grieco, PhD >>>> Assistant Professor >>>> Department of Electrical and Information Engineering >>>> Politecnico di Bari >>>> Via Orabona 4 - 70125 - Bari - Italy >>>> +39 080 5963 911 >>>> telematics.poliba.it/grieco >>>> Skype id: l.alfredo.grieco >>>> Mobile: +39 3346715672 >>>> >>>> >>>> On 18 Mar 2013, at 20:40, Xavier Vilajosana >>>> >>> > wrote: >>>> >>>>> Hi Alfredo, >>>>> >>>>> just one point on mobility. >>>>> TSCH networks may require certain time for a node to join, >>>>> this depends >>>>> on how the EBs are sent and what are the policies for the >>>>> joining node >>>>> on how to scan the different channels. Having said that, I >>>>> think that >>>>> the time required for a node to reserve some cells with its >>>>> neighbour is >>>>> extremely less than the joining time and hence if a mobile >>>>> node can join >>>>> the network for sure has time to schedule some links. So maybe >>>>> this is >>>>> not a big problem :-) >>>>> >>>>> cheers! >>>>> Xavi >>>>> >>>>> >>>>> >>>>> >>>>> On 18/03/13 12:36, Grieco wrote: >>>>>> Hi Qin, Thomas, and all >>>>>> >>>>>> Perhaps the only way to cope with (a reasonable degree of) >>>>>> mobility is >>>>>> to hardly assign a certain number of cells at each link to be >>>>>> used in >>>>>> case a mobile node arrives with urgent data to transmit. >>>>>> >>>>>> Obviously this would slightly decrease the overall efficiency >>>>>> of the >>>>>> system because such "guaranteed cells" could get unused in >>>>>> most of >>>>>> cases. >>>>>> >>>>>> If, on the other side, the mobile node is generating data >>>>>> which is not >>>>>> that urgent, soft reservation could be used as well, which >>>>>> should waste >>>>>> a smaller amount of resources. >>>>>> >>>>>> In this perspective, mobile nodes could be handled using either >>>>>> functions 1 or 2, depending on the degree of mobility, the >>>>>> priority of >>>>>> the data packets generated by mobile nodes, the desired duty >>>>>> cycle, and >>>>>> so on. >>>>>> >>>>>> Cheers >>>>>> >>>>>> Alfredo >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Luigi Alfredo Grieco, PhD >>>>>> Assistant Professor >>>>>> Department of Electrical and Information Engineering >>>>>> Politecnico di Bari >>>>>> Via Orabona 4 - 70125 - Bari - Italy >>>>>> +39 080 5963 911 >>>>>> telematics.poliba.it/grieco >>>>>> Skype id: l.alfredo.grieco >>>>>> Mobile: +39 3346715672 >>>>>> >>>>>> >>>>>> On 18 Mar 2013, at 20:20, "Qin Wang" >>>>> > wrote: >>>>>> >>>>>>> Alfredo, >>>>>>> >>>>>>> I think your remark is correct. So, if there is lots of >>>>>>> mobility, I >>>>>>> would >>>>>>> be prefer distributed approach, i.e. Soft Cell reservation >>>>>>> locally + >>>>>>> RPL + >>>>>>> DSCP for QoS. >>>>>>> >>>>>>> Qin >>>>>>> >>>>>>> >>>>>>>> Hi Qin, >>>>>>>> Your proposal is sound. >>>>>>>> Just a final remark: if my understanding is correct, the >>>>>>>> PCE should >>>>>>>> build >>>>>>>> a schedule that spans across multiple links from mobile node M >>>>>>>> towards the >>>>>>>> sink S. >>>>>>>> If a M moves after the schedule has been built, some >>>>>>>> pre-assigned >>>>>>>> resources along that path could get lost (which could be >>>>>>>> tolerated) >>>>>>>> because of the change of the topology. >>>>>>>> Is it ok ? >>>>>>>> Cheers and thanks for your answer >>>>>>>> Alfredo >>>>>>>> -----Messaggio originale----- >>>>>>>> Da: Qin Wang [mailto:qinwang@berkeley.edu] >>>>>>>> Inviato: Monday, March 18, 2013 6:48 PM >>>>>>>> A: Grieco >>>>>>>> Cc: Qin Wang; JeongGil Ko; Pascal Thubert (pthubert); >>>>>>>> 6tsch@ietf.org ; >>>>>>>> Xavier Vilajosana >>>>>>>> Oggetto: Re: [6tsch] Schemes for resource allocation in the >>>>>>>> LLN for >>>>>>>> 6tus >>>>>>>> Alfredo, >>>>>>>> Firstly, my understanding is Hard cell reservation can only >>>>>>>> be used >>>>>>>> by >>>>>>>> PCE, i.e. centralized schedule. Thus, mobile node will join in >>>>>>>> network >>>>>>>> based on the cells broadcast in EB. And, after its >>>>>>>> registration, PCE >>>>>>>> will >>>>>>>> assign some Hard cells to it. >>>>>>>> secondly, regarding to high priority of the data flow from >>>>>>>> the mobile >>>>>>>> node, DSCP may help, i.e. the packets from the mobile node can >>>>>>>> include >>>>>>>> Priority. >>>>>>>> How do you think? >>>>>>>> Qin >>>>>>>>> Hi Qin and all, >>>>>>>>> Just to challenge the two groups of functions Qin is >>>>>>>>> talking about, >>>>>>>>> what if a certain number of mobile nodes need hard >>>>>>>>> reservation ? In >>>>>>>>> this case, mobile nodes transmit Real time data to be >>>>>>>>> delivered >>>>>>>>> within >>>>>>>>> a given deadline but 6tus does not know in advance the >>>>>>>>> rank (or the >>>>>>>>> position within the topology) of such nodes. >>>>>>>>> I mean that this kind of traffic has the top priority but >>>>>>>>> nobody >>>>>>>>> knows >>>>>>>>> in advance the exact position of the nodes that is going >>>>>>>>> to generate >>>>>>>>> that data. >>>>>>>>> Do we need a further case ? Or we can leverage on 1 or 2 ? >>>>>>>>> If yes, >>>>>>>>> how ? >>>>>>>>> Thanks a lot in advance for your attention >>>>>>>>> Cheers >>>>>>>>> Alfredo >>>>>>>>> -- >>>>>>>>> Luigi Alfredo Grieco, PhD >>>>>>>>> Assistant Professor >>>>>>>>> Department of Electrical and Information Engineering >>>>>>>>> Politecnico di >>>>>>>>> Bari Via Orabona 4 - 70125 - Bari - Italy >>>>>>>>> +39 080 5963 911 >>>>>>>>> telematics.poliba.it/grieco >>>>>>>>> >>>>>>>>> Skype id: l.alfredo.grieco >>>>>>>>> Mobile: +39 3346715672 >>>>>>>>> On 17 Mar 2013, at 17:47, "Qin Wang" >>>>>>>> > wrote: >>>>>>>>>> I fully agree with Carsten that Simple is very important. >>>>>>>>>> Let's >>>>>>>>>> overlapping the following three scenarios, then we will >>>>>>>>>> find only >>>>>>>>>> two >>>>>>>>>> groups of functions 6tus should provide. >>>>>>>>>> (1) Hard cell reserve/remove, which supports the 1st >>>>>>>>>> scenario. >>>>>>>>>> (2) Soft cell reserve/remove, which supports the 2nd and 3rd >>>>>>>>>> scenario. >>>>>>>>>> Any more? >>>>>>>>>> Qin >>>>>>>>>>> Sorry for the delayed response. I was stuck on the plane >>>>>>>>>>> for too >>>>>>>>>>> long >>>>>>>>>>> :) >>>>>>>>>>> I like the discussion that Qin is going for where we >>>>>>>>>>> define the >>>>>>>>>>> scenarios. >>>>>>>>>>> At the same time, as Carsten says we need to make sure >>>>>>>>>>> overlapping >>>>>>>>>>> scenarios of any sort are simplified and aggregated as >>>>>>>>>>> much as >>>>>>>>>>> possible. >>>>>>>>>>> Let me just try to put my 2 cents in-line... >>>>>>>>>>> On Mar 17, 2013, at 8:19 AM, Qin Wang >>>>>>>>>>> > >>>>>>>>>>> wrote: >>>>>>>>>>>> Hi Pascal, >>>>>>>>>>>> It is a very good idea to establish a bundle of cells >>>>>>>>>>>> between A >>>>>>>>>>>> and >>>>>>>>>>>> B by just triggering 6tus in one side. We can design for >>>>>>>>>>>> different >>>>>>>>>>>> scenarios. >>>>>>>>>>>> (1) PCE defines the track, i.e. the multihop path, the >>>>>>>>>>>> bandwidth >>>>>>>>>>>> of >>>>>>>>>>>> each hop, and scheduling hard-cells to implement the >>>>>>>>>>>> multihop >>>>>>>>>>>> path. >>>>>>>>>>>> Assume nodeA and nodeB are one-hop neighbors along the >>>>>>>>>>>> path. In >>>>>>>>>>>> this case, PCE can send Create.hardcell command to 6tus >>>>>>>>>>>> layer in >>>>>>>>>>>> nodeA,and nodeA's 6tus sends Create.hardcell command to >>>>>>>>>>>> nodeB' >>>>>>>>>>>> 6tus, then the hard cell is reserved. This function is >>>>>>>>>>>> not in the >>>>>>>>>>>> current version of 6tus draft, but we can add it in the >>>>>>>>>>>> next >>>>>>>>>>>> version easily. >>>>>>>>>>>> (2)PCE defines the multihop path and the bandwidth of >>>>>>>>>>>> each hop, >>>>>>>>>>>> but >>>>>>>>>>>> not schedules the cells to meet the path bandwidth. In >>>>>>>>>>>> this case, >>>>>>>>>>>> soft cell reservation will be applied, which is always >>>>>>>>>>>> triggered >>>>>>>>>>>> in >>>>>>>>>>>> Transmitting side, and negotiated by the 6tus layer of both >>>>>>>>>>>> sides. >>>>>>>>>>>> (3)The cell reservation is triggered by upper layer, >>>>>>>>>>>> e.g. the >>>>>>>>>>>> RSVP/NSIS entity in nodeA. Then soft cell reservation >>>>>>>>>>>> process in >>>>>>>>>>>> 6tus layer of nodeA will by triggered, and the negotiation >>>>>>>>>>>> process >>>>>>>>>>>> is same as case (2). >>>>>>>>>>>> In summary, by adding reserve hard cell procedure into >>>>>>>>>>>> version-00 >>>>>>>>>>>> of 6tus, we can let the bundle reservation in every >>>>>>>>>>>> scenarios be >>>>>>>>>>>> triggered just in one side. >>>>>>>>>>>> How do you think? >>>>>>>>>>> Great first start in defining the scenarios. >>>>>>>>>>>> Qin >>>>>>>>>>>>> Hi Qin: >>>>>>>>>>>>> I think we are on the same line. The services that >>>>>>>>>>>>> 6TUS proposes >>>>>>>>>>>>> do not depend on which protocol the request came in >>>>>>>>>>>>> through. >>>>>>>>>>>>> Since we are defining the protocol extensions, we'll >>>>>>>>>>>>> make sure >>>>>>>>>>>>> that the new information is directly digestible by the >>>>>>>>>>>>> 6TUS >>>>>>>>>>>>> layer. >>>>>>>>>>>>> The protocol extensions will be separate specs, and >>>>>>>>>>>>> there should >>>>>>>>>>>>> be little to no dereference between those specs and yours. >>>>>>>>>>>>> What's important to me to discuss is how we establish >>>>>>>>>>>>> a bundle >>>>>>>>>>>>> of >>>>>>>>>>>>> cells between A and B. >>>>>>>>>>>>> IMHO, it would be best if that can be achieved by >>>>>>>>>>>>> triggering a >>>>>>>>>>>>> service in A - no need to trigger B as well. >>>>>>>>>>>>> That way, the volume of exchanges between PCE and >>>>>>>>>>>>> nodes can be >>>>>>>>>>>>> devided by 2. >>>>>>>>>>>>> This would mean that there must be an exchange between >>>>>>>>>>>>> 6TUS in A >>>>>>>>>>>>> and 6TUS in B. >>>>>>>>>>>>> Which also would mean that there is a protocol part >>>>>>>>>>>>> related to >>>>>>>>>>>>> 6TUS... >>>>>>>>>>> Fully agreed that this is needed. Being an independent >>>>>>>>>>> layer, I >>>>>>>>>>> don't see why not. >>>>>>>>>>>>> Cheers, >>>>>>>>>>>>> Pascal >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: 6tsch-bounces@ietf.org >>>>>>>>>>>>> >>>>>>>>>>>>> [mailto:6tsch-bounces@ietf.org] On >>>>>>>>>>>>> Behalf Of Qin Wang >>>>>>>>>>>>> Sent: vendredi 15 mars 2013 18:04 >>>>>>>>>>>>> To: JeongGil Ko >>>>>>>>>>>>> Cc: 6tsch@ietf.org ; Xavier >>>>>>>>>>>>> Vilajosana >>>>>>>>>>>>> Subject: Re: [6tsch] Schemes for resource allocation >>>>>>>>>>>>> in the LLN >>>>>>>>>>>>> for 6tus >>>>>>>>>>>>> John and Xavi, >>>>>>>>>>>>> I agree that understanding more about upper layer >>>>>>>>>>>>> protocols like >>>>>>>>>>>>> RSVP and NSIS is very helpful for designing 6tus. But, >>>>>>>>>>>>> I want to >>>>>>>>>>>>> make clearer about my understanding on the >>>>>>>>>>>>> relationship between >>>>>>>>>>>>> 6tus and existing reservation protocols like RSVP or NSIS. >>>>>>>>>>>>> (1) When we talk about reservation in the context of >>>>>>>>>>>>> 6tus, we >>>>>>>>>>>>> mainly focus on link resource (i.e. cell) >>>>>>>>>>>>> reservation, which is >>>>>>>>>>>>> required/ triggered by upper layer. Even in the pure >>>>>>>>>>>>> centralized >>>>>>>>>>>>> approach, it may happen to cross-layer reserve both L3 >>>>>>>>>>>>> and L2 >>>>>>>>>>>>> resource, but you still can separate them logically. >>>>>>>>>>>>> (2) The upper layer requirement to 6tus may come from PCE >>>>>>>>>>>>> carried >>>>>>>>>>>>> by protocol like CoAP, may come from the RSVP/NSIS >>>>>>>>>>>>> entity inside >>>>>>>>>>>>> nodes. >>>>>>>>>>>>> Thus, for 6tus, the question is what kind of function and >>>>>>>>>>>>> interface should be provided to support the upper >>>>>>>>>>>>> layer, instead >>>>>>>>>>>>> of which upper layer protocol should be used. >>>>>>>>>>>>> How do you think? >>>>>>>>>>> I agree with your arguments that the important thing is >>>>>>>>>>> defining >>>>>>>>>>> the >>>>>>>>>>> functionalities. It seems like some of these efforts are >>>>>>>>>>> on the >>>>>>>>>>> way >>>>>>>>>>> in the later emails. Me bringing in the term "RSVP" was >>>>>>>>>>> not that I >>>>>>>>>>> wanted to go an use RSVP in the way it is, but bring the >>>>>>>>>>> (modified/customized) concept in for use in 6tus. As to >>>>>>>>>>> what I >>>>>>>>>>> read >>>>>>>>>>> there may have been a misunderstanding between us but we >>>>>>>>>>> are on >>>>>>>>>>> the >>>>>>>>>>> same line. >>>>>>>>>>> Thanks! >>>>>>>>>>> -John >>>>>>>>>>>>> Qin >>>>>>>>>> _______________________________________________ >>>>>>>>>> 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 mailing list > 6tsch@ietf.org > https://www.ietf.org/mailman/listinfo/6tsch --------------080905050005090404070101 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Hi,

more uses cases that might benefit from 6tus:

-Smart cities/infrastructures/industries
    *(road,street) traffic control (requires increase of bw as more traffic in the road)
    *smart urban parking (requires redundancy of routes an over-provision as RF degrades with cars on top of the sensors)
    *building monitoring (requires redundancy as RF degrades when there are changes on the environment, doors, movement,etc..)
    *industrial automation (latency, robustnes->overprovision,etc...)
    *metering (can be bursty)

and for sure we can find several more use cases where 6tus might be *VERY* relevant.

regards,
Xavi

On 19/03/13 12:29, Grieco wrote:
Thomas, Pascal,

If this can serve to point out some relevant target scenarios, use cases with some degree of mobility include:
- robotics applications
- assembly lines
- avionic systems
- radio localization and tracking 
- advanced mechatronic systems

These are the main domains Telematics lab  is involved within several research projects at Politecnico di Bari.

Cheers

Alfredo


On 19 Mar 2013, at 17:57, Thomas Watteyne <watteyne@eecs.berkeley.edu> wrote:

Alfredo,

This is an interesting use case you bring up. Do you have a specific use case/problem you are trying to solve?

I agree with Qin that it would be great if this were a schedule-only decision, i.e. we change as little as possible in the mechanism (e.g. 6tus), but rather have the scheduling entity build an (otherwise normal) schedule which allows for some motes to roam around.

Thomas

On Tue, Mar 19, 2013 at 1:58 AM, Grieco <alfredo.grieco@gmail.com> wrote:
Hi Qin,

It does work for me: thanks for the clarification

Cheers

Alfredo

--
Luigi Alfredo Grieco, PhD
Assistant Professor
Department of Electrical and Information Engineering
Politecnico di Bari
Via Orabona 4 - 70125 - Bari - Italy
Skype id: l.alfredo.grieco


On 19 Mar 2013, at 01:09, "Qin Wang" <qinwang@berkeley.edu> wrote:

Alfredo,

I think there are two key features in your description: (1)data with high
priority, and (2)mobility. I would like to think the two feature
separately.

Regarding to the high priority, I think the QoS mechanism like DSCP can
handle it, no matter the data flow come from static node or moving node.

Regarding to the mobility, the 6tus can support to establish tracks for
specific purpose. Actually, the cell reservation request comes from upper
layer, 6tus do not know the reserved cells will be used by static nodes or
mobile nodes. In another word, upper layer can ask 6tus to reserve some
cells or tracks or pipes which specifically used for mobile node to send
data as you said.

Does it make sense?

Qin




Hi Xavi, Thomas, all

The problem I am pointing out is not related only to the neighbourhood. As
a matter of fact, a node would like its data be received to the sink and
not only at the next hop. If for each hop to travel, a data packet should
gain a cell through some request/answer handshake this would lead to high
e2e delays when the depth of the tree is high and would incur useless
signalling.

If we think at TASA, to do an example, the schedule exactly rules the
story of each packet from its generating node to the sink. I was trying to
figure out how to do the same in presence of some uncertainty on the
network topology.

While solving this problem is something to be afforded in some scientific
paper, I believe that the functionalities of 6tus and the entire
architecture we are envisaging should be ready to welcome this new wave of
algorithms.

In other terms, I am proposing to add a limited number of "reserved pipes"
to the sink that could be used to transport "only" urgent data from mobile
nodes.

Thomas, this could be added as general remark to the architecture or to
the draft you are editing. Of course, with more details, some primitive to
the 6tus draft could be added or lead to a new draft on handling mobile
6tsch nodes.

Cheers :-)


--
Luigi Alfredo Grieco, PhD
Assistant Professor
Department of Electrical and Information Engineering
Politecnico di Bari
Via Orabona 4 - 70125 - Bari - Italy
+39 080 5963 911
telematics.poliba.it/grieco
Skype id: l.alfredo.grieco
Mobile: +39 3346715672


On 18 Mar 2013, at 20:40, Xavier Vilajosana
<xvilajosana@eecs.berkeley.edu> wrote:

Hi Alfredo,

just one point on mobility.
TSCH networks may require certain time for a node to join, this depends
on how the EBs are sent and what are the policies for the joining node
on how to scan the different channels. Having said that, I think that
the time required for a node to reserve some cells with its neighbour is
extremely less than the joining time and hence if a mobile node can join
the network for sure has time to schedule some links. So maybe this is
not a big problem :-)

cheers!
Xavi




On 18/03/13 12:36, Grieco wrote:
Hi Qin, Thomas, and all

Perhaps the only way to cope with (a reasonable degree of) mobility is
to hardly assign a certain number of cells at each link to be used in
case a mobile node arrives with urgent data to transmit.

Obviously this would slightly decrease the overall efficiency of the
system because such "guaranteed cells" could get unused in most of
cases.

If, on the other side, the mobile node is generating data which is not
that urgent, soft reservation could be used as well, which should waste
a smaller amount of resources.

In this perspective, mobile nodes could be handled using either
functions 1 or 2, depending on the degree of mobility, the priority of
the data packets generated by mobile nodes, the desired duty cycle, and
so on.

Cheers

Alfredo




--
Luigi Alfredo Grieco, PhD
Assistant Professor
Department of Electrical and Information Engineering
Politecnico di Bari
Via Orabona 4 - 70125 - Bari - Italy
+39 080 5963 911
telematics.poliba.it/grieco
Skype id: l.alfredo.grieco
Mobile: +39 3346715672


On 18 Mar 2013, at 20:20, "Qin Wang" <qinwang@berkeley.edu> wrote:

Alfredo,

I think your remark is correct. So, if there is lots of mobility, I
would
be prefer distributed approach, i.e. Soft Cell reservation locally +
RPL +
DSCP for QoS.

Qin


Hi Qin,
Your proposal is sound.
Just a final remark: if my understanding is correct, the PCE should
build
a schedule that spans across multiple links from mobile node M
towards the
sink S.
If a M moves after the schedule has been built, some pre-assigned
resources along that path could get lost (which could be tolerated)
because of the change of the topology.
Is it ok ?
Cheers and thanks for your answer
Alfredo
-----Messaggio originale-----
Da: Qin Wang [mailto:qinwang@berkeley.edu]
Inviato: Monday, March 18, 2013 6:48 PM
A: Grieco
Cc: Qin Wang; JeongGil Ko; Pascal Thubert (pthubert); 6tsch@ietf.org;
Xavier Vilajosana
Oggetto: Re: [6tsch] Schemes for resource allocation in the LLN for
6tus
Alfredo,
Firstly, my understanding is Hard cell reservation can only be used
by
PCE, i.e.  centralized schedule. Thus, mobile node will join in
network
based on the cells broadcast in EB. And, after its registration, PCE
will
assign some Hard cells to it.
secondly, regarding to high priority of the data flow from the mobile
node, DSCP may help, i.e. the packets from the mobile node can
include
Priority.
How do you think?
Qin
Hi Qin and all,
Just to challenge the two groups of functions Qin is talking about,
what if a certain number of mobile nodes need hard reservation ? In
this case, mobile nodes transmit Real time data to be delivered
within
a given deadline but 6tus does not know in advance the rank (or the
position within the topology) of such nodes.
I mean that this kind of traffic has the top priority but nobody
knows
in advance the exact position of the nodes that is going to generate
that data.
Do we need a further case ? Or we can leverage on 1 or 2 ? If yes,
how ?
Thanks a lot in advance for your attention
Cheers
Alfredo
--
Luigi Alfredo Grieco, PhD
Assistant Professor
Department of Electrical and Information Engineering Politecnico di
Bari Via Orabona 4 - 70125 - Bari - Italy
+39 080 5963 911
telematics.poliba.it/grieco
Skype id: l.alfredo.grieco
Mobile: +39 3346715672
On 17 Mar 2013, at 17:47, "Qin Wang" <qinwang@berkeley.edu> wrote:
I fully agree with Carsten that Simple is very important. Let's
overlapping the following three scenarios, then we will find only
two
groups of functions 6tus should provide.
(1) Hard cell reserve/remove, which supports the 1st scenario.
(2) Soft cell reserve/remove, which supports the 2nd and 3rd
scenario.
Any more?
Qin
Sorry for the delayed response. I was stuck on the plane for too
long
:)
I like the discussion that Qin is going for where we define the
scenarios.
At the same time, as Carsten says we need to make sure overlapping
scenarios of any sort are simplified and aggregated as much as
possible.
Let me just try to put my 2 cents in-line...
On Mar 17, 2013, at 8:19 AM, Qin Wang <qinwang@berkeley.edu>
wrote:
Hi Pascal,
It is a very good idea to establish a bundle of cells between A
and
B by just triggering 6tus in one side. We can design for
different
scenarios.
(1) PCE defines the track, i.e. the multihop path, the bandwidth
of
each hop, and scheduling hard-cells to implement the multihop
path.
Assume nodeA and nodeB are one-hop neighbors along the path. In
this case, PCE can send Create.hardcell command to 6tus layer in
nodeA,and nodeA's 6tus sends Create.hardcell command to nodeB'
6tus, then the hard cell is reserved. This function is not in the
current version of 6tus draft, but we can add it in the next
version easily.
(2)PCE defines the multihop path and the bandwidth of each hop,
but
not schedules the cells to meet the path bandwidth. In this case,
soft cell reservation will be applied, which is always triggered
in
Transmitting side, and negotiated by the 6tus layer of both
sides.
(3)The cell reservation is triggered by upper layer, e.g. the
RSVP/NSIS entity in nodeA. Then soft cell reservation process in
6tus layer of nodeA will by triggered, and the negotiation
process
is same as case (2).
In summary, by adding reserve hard cell procedure into version-00
of 6tus, we can let the bundle reservation in every scenarios be
triggered just in one side.
How do you think?
Great first start in defining the scenarios.
Qin
Hi Qin:
I think we are on the same line. The services that 6TUS proposes
do not depend on which protocol the request came in through.
Since we are defining the protocol extensions, we'll make sure
that the new information is directly digestible by the 6TUS
layer.
The protocol extensions will be separate specs, and there should
be little to no dereference between those specs and yours.
What's important to me to discuss is how we establish a bundle
of
cells between A and B.
IMHO, it would be best if that can be achieved by triggering a
service in A - no need to trigger B as well.
That way, the volume of exchanges between PCE and nodes can be
devided by 2.
This would mean that there must be an exchange between 6TUS in A
and 6TUS in B.
Which  also would mean that there is a protocol part related to
6TUS…
Fully agreed that this is needed. Being an independent layer, I
don't see why not.
Cheers,
Pascal
-----Original Message-----
From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On
Behalf Of Qin Wang
Sent: vendredi 15 mars 2013 18:04
To: JeongGil Ko
Cc: 6tsch@ietf.org; Xavier Vilajosana
Subject: Re: [6tsch] Schemes for resource allocation in the LLN
for 6tus
John and Xavi,
I agree that understanding more about upper layer protocols like
RSVP and NSIS is very helpful for designing 6tus. But, I want to
make clearer about my understanding on the relationship between
6tus and existing reservation protocols like RSVP or NSIS.
(1) When we talk about reservation in the context of 6tus, we
mainly focus on  link resource (i.e. cell) reservation, which is
required/ triggered by upper layer. Even in the pure centralized
approach, it may happen to cross-layer reserve both L3 and L2
resource, but you still can separate them logically.
(2) The upper layer requirement to 6tus may come from PCE
carried
by protocol like CoAP, may come from the RSVP/NSIS entity inside
nodes.
Thus, for 6tus, the question is what kind of function and
interface should be provided to support the upper layer, instead
of which upper layer protocol should be used.
How do you think?
I agree with your arguments that the important thing is defining
the
functionalities. It seems like some of these efforts are on the
way
in the later emails. Me bringing in the term "RSVP" was not that I
wanted to go an use RSVP in the way it is, but bring the
(modified/customized) concept in for use in 6tus. As to what I
read
there may have been a misunderstanding between us but we are on
the
same line.
Thanks!
-John
Qin
_______________________________________________
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 mailing list
6tsch@ietf.org
https://www.ietf.org/mailman/listinfo/6tsch

--------------080905050005090404070101-- Return-Path: 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 7E70821F87AB for <6tsch@ietfa.amsl.com>; Tue, 19 Mar 2013 12:30:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.873 X-Spam-Level: ** X-Spam-Status: No, score=2.873 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_IP_ADDR=1.119, HTML_MESSAGE=0.001, J_CHICKENPOX_53=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_PBL=0.905, RDNS_NONE=0.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 DDL7MViB2C6q for <6tsch@ietfa.amsl.com>; Tue, 19 Mar 2013 12:30:31 -0700 (PDT) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id B26A121F8739 for <6tsch@ietf.org>; Tue, 19 Mar 2013 12:30:30 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id u3so721393wey.24 for <6tsch@ietf.org>; Tue, 19 Mar 2013 12:30:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:subject:references:from:content-type:x-mailer :in-reply-to:message-id:date:to:content-transfer-encoding :mime-version; bh=N2gYH5txyxdtTPCKngqhky8DdYNlrD1bXLY5DessrZo=; b=kwYxiXmCj1F/lgIEax+ecPBqQwbOQj4WqLmXpwqn1kQQ/4ZFYXL2tM+IbXAn4M34Nr GBtI3oe3UeTMQU6+JaYO9br4cfjBd9fwPfvA5L44WJebvhj9cTDBBcJWWdGk3J8YxQ6t ub6UaBT3Qpg1bFinKcQRlIpezlyJUtjm/1PCxm1KA3crXUNBxonVszSPVx+MWKscEHq7 UfGcBMfOvQnnf24YEek2w67Ck95dfCNxCQBx6O7bNU4LzLP0md16bf+MkxETuXzow8by 6Ftto5iJO9SV4kHOnNKWDvFWDZ7OXRoyk22LSMJZGsigdgn454qlzI43RbhpNd4ZcH1E Cwfg== X-Received: by 10.194.119.33 with SMTP id kr1mr5799986wjb.36.1363721429787; Tue, 19 Mar 2013 12:30:29 -0700 (PDT) Received: from [217.201.208.16] ([217.201.208.16]) by mx.google.com with ESMTPS id ex15sm2607814wid.5.2013.03.19.12.29.59 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Mar 2013 12:30:28 -0700 (PDT) References: <956BA951-CF3C-4F00-A80E-73D641634224@gmail.com> <514248DA.6090403@eecs.berkeley.edu> <6A4E9484-B0D0-4F8E-AF13-C5AC74D230CF@gmail.com> <1b28192c14eed60c7a6621f6b9b02e6a.squirrel@calmail.berkeley.edu> <0B5235F3-6E4F-46AE-B59E-DE63FC47AA95@gmail.com> <5332a47730edc8ed350124947c6d9d4f.squirrel@calmail.berkeley.edu> <2b68f317c14dc5ae864813e632d55fcd.squirrel@calmail.berkeley.edu> <51475694.85d00e0a.2654.3c21@mx.google.com> <1b952faca1b2846136ff23c6723eeb63.squirrel@calmail.berkeley.edu> <51476DC1.5070707@eecs.berkeley.edu> <775F44DA-D912-4B36-B241-E176FBD585F1@gmail.com> From: Grieco Content-Type: multipart/alternative; boundary=Apple-Mail-FE4549D6-6C1E-48C9-BD53-3793272C8F95 X-Mailer: iPad Mail (10B146) In-Reply-To: Message-Id: <299D7883-A8BB-4F88-9BDD-93E5EC9B4381@gmail.com> Date: Tue, 19 Mar 2013 20:29:54 +0100 To: "6tsch@ietf.org" <6tsch@ietf.org> Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Subject: Re: [6tsch] R: Schemes for resource allocation in the LLN for 6tus 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 19:30:34 -0000 --Apple-Mail-FE4549D6-6C1E-48C9-BD53-3793272C8F95 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thomas, Pascal, If this can serve to point out some relevant target scenarios, use cases wit= h some degree of mobility include: - robotics applications - assembly lines - avionic systems - radio localization and tracking=20 - advanced mechatronic systems These are the main domains Telematics lab is involved within several resear= ch projects at Politecnico di Bari. Cheers Alfredo On 19 Mar 2013, at 17:57, Thomas Watteyne wrote= : > Alfredo, >=20 > This is an interesting use case you bring up. Do you have a specific use c= ase/problem you are trying to solve? >=20 > I agree with Qin that it would be great if this were a schedule-only decis= ion, i.e. we change as little as possible in the mechanism (e.g. 6tus), but r= ather have the scheduling entity build an (otherwise normal) schedule which a= llows for some motes to roam around. >=20 > Thomas >=20 > On Tue, Mar 19, 2013 at 1:58 AM, Grieco wrote: >> Hi Qin, >>=20 >> It does work for me: thanks for the clarification >>=20 >> Cheers >>=20 >> Alfredo >>=20 >> -- >> Luigi Alfredo Grieco, PhD >> Assistant Professor >> Department of Electrical and Information Engineering >> Politecnico di Bari >> Via Orabona 4 - 70125 - Bari - Italy >> +39 080 5963 911 >> telematics.poliba.it/grieco >> Skype id: l.alfredo.grieco >> Mobile: +39 3346715672 >>=20 >>=20 >> On 19 Mar 2013, at 01:09, "Qin Wang" wrote: >>=20 >>> Alfredo, >>>=20 >>> I think there are two key features in your description: (1)data with hig= h >>> priority, and (2)mobility. I would like to think the two feature >>> separately. >>>=20 >>> Regarding to the high priority, I think the QoS mechanism like DSCP can >>> handle it, no matter the data flow come from static node or moving node.= >>>=20 >>> Regarding to the mobility, the 6tus can support to establish tracks for >>> specific purpose. Actually, the cell reservation request comes from uppe= r >>> layer, 6tus do not know the reserved cells will be used by static nodes o= r >>> mobile nodes. In another word, upper layer can ask 6tus to reserve some >>> cells or tracks or pipes which specifically used for mobile node to send= >>> data as you said. >>>=20 >>> Does it make sense? >>>=20 >>> Qin >>>=20 >>>=20 >>>=20 >>>>=20 >>>> Hi Xavi, Thomas, all >>>>=20 >>>> The problem I am pointing out is not related only to the neighbourhood.= As >>>> a matter of fact, a node would like its data be received to the sink an= d >>>> not only at the next hop. If for each hop to travel, a data packet shou= ld >>>> gain a cell through some request/answer handshake this would lead to hi= gh >>>> e2e delays when the depth of the tree is high and would incur useless >>>> signalling. >>>>=20 >>>> If we think at TASA, to do an example, the schedule exactly rules the >>>> story of each packet from its generating node to the sink. I was trying= to >>>> figure out how to do the same in presence of some uncertainty on the >>>> network topology. >>>>=20 >>>> While solving this problem is something to be afforded in some scientif= ic >>>> paper, I believe that the functionalities of 6tus and the entire >>>> architecture we are envisaging should be ready to welcome this new wave= of >>>> algorithms. >>>>=20 >>>> In other terms, I am proposing to add a limited number of "reserved pip= es" >>>> to the sink that could be used to transport "only" urgent data from mob= ile >>>> nodes. >>>>=20 >>>> Thomas, this could be added as general remark to the architecture or to= >>>> the draft you are editing. Of course, with more details, some primitive= to >>>> the 6tus draft could be added or lead to a new draft on handling mobile= >>>> 6tsch nodes. >>>>=20 >>>> Cheers :-) >>>>=20 >>>>=20 >>>> -- >>>> Luigi Alfredo Grieco, PhD >>>> Assistant Professor >>>> Department of Electrical and Information Engineering >>>> Politecnico di Bari >>>> Via Orabona 4 - 70125 - Bari - Italy >>>> +39 080 5963 911 >>>> telematics.poliba.it/grieco >>>> Skype id: l.alfredo.grieco >>>> Mobile: +39 3346715672 >>>>=20 >>>>=20 >>>> On 18 Mar 2013, at 20:40, Xavier Vilajosana >>>> wrote: >>>>=20 >>>>> Hi Alfredo, >>>>>=20 >>>>> just one point on mobility. >>>>> TSCH networks may require certain time for a node to join, this depend= s >>>>> on how the EBs are sent and what are the policies for the joining node= >>>>> on how to scan the different channels. Having said that, I think that >>>>> the time required for a node to reserve some cells with its neighbour i= s >>>>> extremely less than the joining time and hence if a mobile node can jo= in >>>>> the network for sure has time to schedule some links. So maybe this is= >>>>> not a big problem :-) >>>>>=20 >>>>> cheers! >>>>> Xavi >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 18/03/13 12:36, Grieco wrote: >>>>>> Hi Qin, Thomas, and all >>>>>>=20 >>>>>> Perhaps the only way to cope with (a reasonable degree of) mobility i= s >>>>>> to hardly assign a certain number of cells at each link to be used in= >>>>>> case a mobile node arrives with urgent data to transmit. >>>>>>=20 >>>>>> Obviously this would slightly decrease the overall efficiency of the >>>>>> system because such "guaranteed cells" could get unused in most of >>>>>> cases. >>>>>>=20 >>>>>> If, on the other side, the mobile node is generating data which is no= t >>>>>> that urgent, soft reservation could be used as well, which should was= te >>>>>> a smaller amount of resources. >>>>>>=20 >>>>>> In this perspective, mobile nodes could be handled using either >>>>>> functions 1 or 2, depending on the degree of mobility, the priority o= f >>>>>> the data packets generated by mobile nodes, the desired duty cycle, a= nd >>>>>> so on. >>>>>>=20 >>>>>> Cheers >>>>>>=20 >>>>>> Alfredo >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> -- >>>>>> Luigi Alfredo Grieco, PhD >>>>>> Assistant Professor >>>>>> Department of Electrical and Information Engineering >>>>>> Politecnico di Bari >>>>>> Via Orabona 4 - 70125 - Bari - Italy >>>>>> +39 080 5963 911 >>>>>> telematics.poliba.it/grieco >>>>>> Skype id: l.alfredo.grieco >>>>>> Mobile: +39 3346715672 >>>>>>=20 >>>>>>=20 >>>>>> On 18 Mar 2013, at 20:20, "Qin Wang" wrote: >>>>>>=20 >>>>>>> Alfredo, >>>>>>>=20 >>>>>>> I think your remark is correct. So, if there is lots of mobility, I >>>>>>> would >>>>>>> be prefer distributed approach, i.e. Soft Cell reservation locally += >>>>>>> RPL + >>>>>>> DSCP for QoS. >>>>>>>=20 >>>>>>> Qin >>>>>>>=20 >>>>>>>=20 >>>>>>>> Hi Qin, >>>>>>>> Your proposal is sound. >>>>>>>> Just a final remark: if my understanding is correct, the PCE should= >>>>>>>> build >>>>>>>> a schedule that spans across multiple links from mobile node M >>>>>>>> towards the >>>>>>>> sink S. >>>>>>>> If a M moves after the schedule has been built, some pre-assigned >>>>>>>> resources along that path could get lost (which could be tolerated)= >>>>>>>> because of the change of the topology. >>>>>>>> Is it ok ? >>>>>>>> Cheers and thanks for your answer >>>>>>>> Alfredo >>>>>>>> -----Messaggio originale----- >>>>>>>> Da: Qin Wang [mailto:qinwang@berkeley.edu] >>>>>>>> Inviato: Monday, March 18, 2013 6:48 PM >>>>>>>> A: Grieco >>>>>>>> Cc: Qin Wang; JeongGil Ko; Pascal Thubert (pthubert); 6tsch@ietf.or= g; >>>>>>>> Xavier Vilajosana >>>>>>>> Oggetto: Re: [6tsch] Schemes for resource allocation in the LLN for= >>>>>>>> 6tus >>>>>>>> Alfredo, >>>>>>>> Firstly, my understanding is Hard cell reservation can only be used= >>>>>>>> by >>>>>>>> PCE, i.e. centralized schedule. Thus, mobile node will join in >>>>>>>> network >>>>>>>> based on the cells broadcast in EB. And, after its registration, PC= E >>>>>>>> will >>>>>>>> assign some Hard cells to it. >>>>>>>> secondly, regarding to high priority of the data flow from the mobi= le >>>>>>>> node, DSCP may help, i.e. the packets from the mobile node can >>>>>>>> include >>>>>>>> Priority. >>>>>>>> How do you think? >>>>>>>> Qin >>>>>>>>> Hi Qin and all, >>>>>>>>> Just to challenge the two groups of functions Qin is talking about= , >>>>>>>>> what if a certain number of mobile nodes need hard reservation ? I= n >>>>>>>>> this case, mobile nodes transmit Real time data to be delivered >>>>>>>>> within >>>>>>>>> a given deadline but 6tus does not know in advance the rank (or th= e >>>>>>>>> position within the topology) of such nodes. >>>>>>>>> I mean that this kind of traffic has the top priority but nobody >>>>>>>>> knows >>>>>>>>> in advance the exact position of the nodes that is going to genera= te >>>>>>>>> that data. >>>>>>>>> Do we need a further case ? Or we can leverage on 1 or 2 ? If yes,= >>>>>>>>> how ? >>>>>>>>> Thanks a lot in advance for your attention >>>>>>>>> Cheers >>>>>>>>> Alfredo >>>>>>>>> -- >>>>>>>>> Luigi Alfredo Grieco, PhD >>>>>>>>> Assistant Professor >>>>>>>>> Department of Electrical and Information Engineering Politecnico d= i >>>>>>>>> Bari Via Orabona 4 - 70125 - Bari - Italy >>>>>>>>> +39 080 5963 911 >>>>>>>>> telematics.poliba.it/grieco >>>>>>>>> Skype id: l.alfredo.grieco >>>>>>>>> Mobile: +39 3346715672 >>>>>>>>> On 17 Mar 2013, at 17:47, "Qin Wang" wrote:= >>>>>>>>>> I fully agree with Carsten that Simple is very important. Let's >>>>>>>>>> overlapping the following three scenarios, then we will find only= >>>>>>>>>> two >>>>>>>>>> groups of functions 6tus should provide. >>>>>>>>>> (1) Hard cell reserve/remove, which supports the 1st scenario. >>>>>>>>>> (2) Soft cell reserve/remove, which supports the 2nd and 3rd >>>>>>>>>> scenario. >>>>>>>>>> Any more? >>>>>>>>>> Qin >>>>>>>>>>> Sorry for the delayed response. I was stuck on the plane for too= >>>>>>>>>>> long >>>>>>>>>>> :) >>>>>>>>>>> I like the discussion that Qin is going for where we define the >>>>>>>>>>> scenarios. >>>>>>>>>>> At the same time, as Carsten says we need to make sure overlappi= ng >>>>>>>>>>> scenarios of any sort are simplified and aggregated as much as >>>>>>>>>>> possible. >>>>>>>>>>> Let me just try to put my 2 cents in-line... >>>>>>>>>>> On Mar 17, 2013, at 8:19 AM, Qin Wang >>>>>>>>>>> wrote: >>>>>>>>>>>> Hi Pascal, >>>>>>>>>>>> It is a very good idea to establish a bundle of cells between A= >>>>>>>>>>>> and >>>>>>>>>>>> B by just triggering 6tus in one side. We can design for >>>>>>>>>>>> different >>>>>>>>>>>> scenarios. >>>>>>>>>>>> (1) PCE defines the track, i.e. the multihop path, the bandwidt= h >>>>>>>>>>>> of >>>>>>>>>>>> each hop, and scheduling hard-cells to implement the multihop >>>>>>>>>>>> path. >>>>>>>>>>>> Assume nodeA and nodeB are one-hop neighbors along the path. In= >>>>>>>>>>>> this case, PCE can send Create.hardcell command to 6tus layer i= n >>>>>>>>>>>> nodeA,and nodeA's 6tus sends Create.hardcell command to nodeB' >>>>>>>>>>>> 6tus, then the hard cell is reserved. This function is not in t= he >>>>>>>>>>>> current version of 6tus draft, but we can add it in the next >>>>>>>>>>>> version easily. >>>>>>>>>>>> (2)PCE defines the multihop path and the bandwidth of each hop,= >>>>>>>>>>>> but >>>>>>>>>>>> not schedules the cells to meet the path bandwidth. In this cas= e, >>>>>>>>>>>> soft cell reservation will be applied, which is always triggere= d >>>>>>>>>>>> in >>>>>>>>>>>> Transmitting side, and negotiated by the 6tus layer of both >>>>>>>>>>>> sides. >>>>>>>>>>>> (3)The cell reservation is triggered by upper layer, e.g. the >>>>>>>>>>>> RSVP/NSIS entity in nodeA. Then soft cell reservation process i= n >>>>>>>>>>>> 6tus layer of nodeA will by triggered, and the negotiation >>>>>>>>>>>> process >>>>>>>>>>>> is same as case (2). >>>>>>>>>>>> In summary, by adding reserve hard cell procedure into version-= 00 >>>>>>>>>>>> of 6tus, we can let the bundle reservation in every scenarios b= e >>>>>>>>>>>> triggered just in one side. >>>>>>>>>>>> How do you think? >>>>>>>>>>> Great first start in defining the scenarios. >>>>>>>>>>>> Qin >>>>>>>>>>>>> Hi Qin: >>>>>>>>>>>>> I think we are on the same line. The services that 6TUS propos= es >>>>>>>>>>>>> do not depend on which protocol the request came in through. >>>>>>>>>>>>> Since we are defining the protocol extensions, we'll make sure= >>>>>>>>>>>>> that the new information is directly digestible by the 6TUS >>>>>>>>>>>>> layer. >>>>>>>>>>>>> The protocol extensions will be separate specs, and there shou= ld >>>>>>>>>>>>> be little to no dereference between those specs and yours. >>>>>>>>>>>>> What's important to me to discuss is how we establish a bundle= >>>>>>>>>>>>> of >>>>>>>>>>>>> cells between A and B. >>>>>>>>>>>>> IMHO, it would be best if that can be achieved by triggering a= >>>>>>>>>>>>> service in A - no need to trigger B as well. >>>>>>>>>>>>> That way, the volume of exchanges between PCE and nodes can be= >>>>>>>>>>>>> devided by 2. >>>>>>>>>>>>> This would mean that there must be an exchange between 6TUS in= A >>>>>>>>>>>>> and 6TUS in B. >>>>>>>>>>>>> Which also would mean that there is a protocol part related t= o >>>>>>>>>>>>> 6TUS=E2=80=A6 >>>>>>>>>>> Fully agreed that this is needed. Being an independent layer, I >>>>>>>>>>> don't see why not. >>>>>>>>>>>>> Cheers, >>>>>>>>>>>>> Pascal >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] O= n >>>>>>>>>>>>> Behalf Of Qin Wang >>>>>>>>>>>>> Sent: vendredi 15 mars 2013 18:04 >>>>>>>>>>>>> To: JeongGil Ko >>>>>>>>>>>>> Cc: 6tsch@ietf.org; Xavier Vilajosana >>>>>>>>>>>>> Subject: Re: [6tsch] Schemes for resource allocation in the LL= N >>>>>>>>>>>>> for 6tus >>>>>>>>>>>>> John and Xavi, >>>>>>>>>>>>> I agree that understanding more about upper layer protocols li= ke >>>>>>>>>>>>> RSVP and NSIS is very helpful for designing 6tus. But, I want t= o >>>>>>>>>>>>> make clearer about my understanding on the relationship betwee= n >>>>>>>>>>>>> 6tus and existing reservation protocols like RSVP or NSIS. >>>>>>>>>>>>> (1) When we talk about reservation in the context of 6tus, we >>>>>>>>>>>>> mainly focus on link resource (i.e. cell) reservation, which i= s >>>>>>>>>>>>> required/ triggered by upper layer. Even in the pure centraliz= ed >>>>>>>>>>>>> approach, it may happen to cross-layer reserve both L3 and L2 >>>>>>>>>>>>> resource, but you still can separate them logically. >>>>>>>>>>>>> (2) The upper layer requirement to 6tus may come from PCE >>>>>>>>>>>>> carried >>>>>>>>>>>>> by protocol like CoAP, may come from the RSVP/NSIS entity insi= de >>>>>>>>>>>>> nodes. >>>>>>>>>>>>> Thus, for 6tus, the question is what kind of function and >>>>>>>>>>>>> interface should be provided to support the upper layer, inste= ad >>>>>>>>>>>>> of which upper layer protocol should be used. >>>>>>>>>>>>> How do you think? >>>>>>>>>>> I agree with your arguments that the important thing is defining= >>>>>>>>>>> the >>>>>>>>>>> functionalities. It seems like some of these efforts are on the >>>>>>>>>>> way >>>>>>>>>>> in the later emails. Me bringing in the term "RSVP" was not that= I >>>>>>>>>>> wanted to go an use RSVP in the way it is, but bring the >>>>>>>>>>> (modified/customized) concept in for use in 6tus. As to what I >>>>>>>>>>> read >>>>>>>>>>> there may have been a misunderstanding between us but we are on >>>>>>>>>>> the >>>>>>>>>>> same line. >>>>>>>>>>> Thanks! >>>>>>>>>>> -John >>>>>>>>>>>>> Qin >>>>>>>>>> _______________________________________________ >>>>>>>>>> 6tsch mailing list >>>>>>>>>> 6tsch@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/6tsch >>>>>=20 >>>> _______________________________________________ >>>> 6tsch mailing list >>>> 6tsch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/6tsch >>>>=20 >>>=20 >>=20 >> _______________________________________________ >> 6tsch mailing list >> 6tsch@ietf.org >> https://www.ietf.org/mailman/listinfo/6tsch >>=20 >=20 > _______________________________________________ > 6tsch mailing list > 6tsch@ietf.org > https://www.ietf.org/mailman/listinfo/6tsch --Apple-Mail-FE4549D6-6C1E-48C9-BD53-3793272C8F95 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Thomas, Pascal,

If this can serve to point out some relevant target scenarios, use cases w= ith some degree of mobility include:
- robotics applications
=
- assembly lines
- avionic systems
- radio localiza= tion and tracking 
- advanced mechatronic systems

These are the main domains Telematics lab  is involved within sev= eral research projects at Politecnico di Bari.

Cheers

Alfredo

On 19 Mar 2013, at 17:57, Thomas Watteyne <watteyne@eecs.berkeley.edu> wrote:

Alfredo,

This is an interesting use ca= se you bring up. Do you have a specific use case/problem you are trying to s= olve?

I agree with Qin that it would be great if this were a schedule-only decisio= n, i.e. we change as little as possible in the mechanism (e.g. 6tus), but ra= ther have the scheduling entity build an (otherwise normal) schedule which a= llows for some motes to roam around.

Thomas

On Tue, Mar 19, 2013 at 1:58 AM, G= rieco <alfredo.grieco@gmail.com> wrote:
Hi Qin,

It does work for me:= thanks for the clarification

Che= ers

Alfredo

--
Luigi Alfredo Grieco, PhD
Assistant Professor
Department of Electrical and Information Engineering
Politecnico di Bari
Via Orabona 4 - 70125 - Bari - Italy
telematics.poliba.it/grieco
Skype id: l.alfred= o.grieco


On 19 Mar 2013, at 01:09, "Qin Wang" <qinwang@berkeley.edu> wrote:

=
Alfredo,

I think there are two key features in your description: (1)data with h= igh
priority, and (2)mobility. I would like to think the two= feature
separately.

Regard= ing to the high priority, I think the QoS mechanism like DSCP can
= handle it, no matter the data flow come from static node or moving nod= e.

Regarding to the mobility, the 6tus can s= upport to establish tracks for
specific purpose. Actually, t= he cell reservation request comes from upper
layer, 6tus do not know the reserved cells will be used by static node= s or
mobile nodes. In another word, upper layer can ask 6tus= to reserve some
cells or tracks or pipes which specifically= used for mobile node to send
data as you said.

Does it make sense?=

Qin




Hi Xavi, Thomas, all
=

The problem I am pointing out is not related only to the neighbo= urhood. As
a matter of fact, a node would l= ike its data be received to the sink and
not only at the next hop. If for each hop to travel, a da= ta packet should
gain a cell through some reques= t/answer handshake this would lead to high
e2e delays when the depth of the tree is high and woul= d incur useless
signalling.

If we think at TASA, to do an example, the schedule exactly r= ules the
story of each packet from its g= enerating node to the sink. I was trying to
figure out how to do the same in presence of some unc= ertainty on the
network topology.

While solving this problem is something to be afforded= in some scientific
paper, I believe that the funct= ionalities of 6tus and the entire
architecture we are envisaging should be ready to welcome this n= ew wave of
algorithms.

In other terms, I am proposing to add a limited number of "r= eserved pipes"
to the sink that could be used t= o transport "only" urgent data from mobile
nodes.

Thomas, this c= ould be added as general remark to the architecture or to
the draft you are editing. Of course, w= ith more details, some primitive to
the 6tus draft could be added o= r lead to a new draft on handling mobile
6tsch nodes.

Cheers :-)

=

--
Luigi Alfred= o Grieco, PhD
Assista= nt Professor
Departme= nt of Electrical and Information Engineering
Politecnico di Bari
<= /blockquote>
Via Orabona 4 - 70125 - Bari - I= taly
+39 080 5= 963 911
telematics.poliba.it/grieco
=
Skype id: l.alfredo.grieco
Mobile: +39 3346715672

=

On 18 Mar 2013= , at 20:40, Xavier Vilajosana
<xvilajosana@eecs.berkeley.edu> wrote:

Hi Alfredo,
<= span>
just one point on mobility.
TSCH networks may requ= ire certain time for a node to join, this depends
on how the EBs are sent and what are the policies for the joining no= de
on how to scan the different channels. Having said that, I think that<= /span>
the time required for a node to reserve some cells with it= s neighbour is
extremely less than the joining time and hence if a mobile node can j= oin
the network for sure has time to schedule some links. So maybe this is=
not a big problem :-)

cheers!
Xavi




On 18/03/13 12:36, Grieco wrote:
<= blockquote type=3D"cite">
Hi Qin, Thomas, and all

Perhaps the= only way to cope with (a reasonable degree of) mobility is
to hardly assign a certain nu= mber of cells at each link to be used in
case a mobile node arrives with urgent data to transmit= .

Obviously this would slightly decreas= e the overall efficiency of the
system because such "guarante= ed cells" could get unused in most of
cases.

If, on the other side, the mo= bile node is generating data which is not
that urgent, soft reservation could be used as well, wh= ich should waste
a smaller amount o= f resources.

In this perspective, mobile n= odes could be handled using either
functions 1 or 2, depending on the degree of mobility, the priority o= f
the data packets g= enerated by mobile nodes, the desired duty cycle, and
so on.
<= /blockquote>

Cheers
<= /blockquote>

Alfredo




<= /blockquote>
--
Luigi Alfredo Grieco, PhD
Assistant Professor
Department of Electrical and Information Engineering
Politecnico di Bari
Via Orabona 4 - 70125 - Bari - Italy
+39 080 5963 911
telematics.poliba.it/grieco
=
Skype id: l.alfredo.grieco
Mobile: +39 3346715672


On 18 Mar 20= 13, at 20:20, "Qin Wang" <qinwang@berkeley.edu> wrote:

Alfredo,

I t= hink your remark is correct. So, if there is lots of mobility, I
<= /blockquote>
wou= ld
be prefer distributed approach, i.e. Soft Cell reservation locally +=
RPL +
=
DSCP for QoS.

=
Qin
=


Hi Qin,
Your proposal is sound.
Just a final remark: if my understanding is correct, t= he PCE should
build
a schedule that spans across multiple links from mobi= le node M
towards the
sink S.
If a M moves after the schedule has been built, some p= re-assigned
resources along that path c= ould get lost (which could be tolerated)
because of the change of th= e topology.
Is it ok ?
Cheers and thanks for your answer=
Alfredo
-----Messaggio originale-----
=
Da: Qin Wang [mailto:qinwang@berkeley.edu]
Inviato: Monday, March 18, 2= 013 6:48 PM
A: Grieco
Cc: Qin Wang; JeongGil Ko; Pascal Thuber= t (pthubert); 6tsch@ietf= .org;
Xavier Vilajosana
Oggetto: Re: [6tsch] Schemes for resourc= e allocation in the LLN for
6tus
Alfredo,
Firstly, my understanding is Hard cell reservation can only be use= d
by
<= /blockquote>
PCE, i.e.  centralized schedule. Thus, mobile no= de will join in
network
based on the cells broadcast in EB. And,= after its registration, PCE
will
assign some Hard cells to it.
=
secondly, regarding to high priority of the data flow= from the mobile
node, DSCP may help, i.e. t= he packets from the mobile node can
include
Priority.
How do you think?
Qin
=
Hi Qin and all,
<= /blockquote>
Just to challenge the two groups of func= tions Qin is talking about,
what if a certain number of mobile nodes need hard reservation ? In
this case, mobile nodes transmit Real time data to be delivered
within
a given deadline but 6tus does not know in advance th= e rank (or the
position within the topology) of such nodes.
I mean that this k= ind of traffic has the top priority but nobody
knows
=
in advance the e= xact position of the nodes that is going to generate
=
that data.
Do we need a further case ? Or we can leverage on 1 or 2 ? If yes,
how ?
=
Thanks a lot in advance for your attention
Cheers
Alfredo
--
<= /blockquote>
Luigi Alfredo Grieco, PhD
A= ssistant Professor
Department of Electrical and Information Engineering Politecnico di
Bari Via Orabona 4 - 70125 - Bari - Italy
+39 080 5= 963 911
telem= atics.poliba.it/grieco
=
Skype id: l.alfredo.grieco
Mobile: +39 33467= 15672
On 17 Mar 2013, at 17:47, "Qin Wang" <qinwang@berkeley.edu> wrote:
<= /blockquote>
I fully agree with Carsten t= hat Simple is very important. Let's
overlapping the following three scenarios, t= hen we will find only
two
=
groups of func= tions 6tus should provide.
(1) Hard cell reserve/remove, which supports= the 1st scenario.
(2) Soft cell re= serve/remove, which supports the 2nd and 3rd
scenario.
Any more?
Qin
Sorry for the delayed response. I was st= uck on the plane for too
long
<= /blockquote>
:)
<= /blockquote>
I like the discussion that Qin is going for w= here we define the
scenarios.
At the same time, a= s Carsten says we need to make sure overlapping
s= cenarios of any sort are simplified and aggregated as much as
possible.
Let me just try to put my 2 cents in-lin= e...
On Mar 17, 2013, at 8:19 AM, Qin Wang <qinwang@berkeley.edu>
wrote:
<= /blockquote>
Hi Pascal,
It is a very good idea to establish a bundle of cells between A
and
B by just triggering 6tus in one side. We can design for
different
scenarios.
(1) PCE defines t= he track, i.e. the multihop path, the bandwidth
of
each hop, and s= cheduling hard-cells to implement the multihop
path.
=
Assume nodeA and nodeB are one-hop neighbors along the path. In=
this case, PCE= can send Create.hardcell command to 6tus layer in
nodeA,and nodeA's 6tus sends Create.hardce= ll command to nodeB'
6tus, then the hard cell is reserved. This function is not in the
current version of 6tus draft, but we can ad= d it in the next
version easily= .
(2)PCE defines the multihop path and the b= andwidth of each hop,
but
not schedules the cells to meet the path= bandwidth. In this case,
soft cell reservation will be applied, whi= ch is always triggered
in
Transmitting side, and negotiated by the= 6tus layer of both
sides.
(3)The cell reservation is triggered by upper layer, e.g. the
RSVP/NSIS entity in nodeA. Then soft cel= l reservation process in
6tus layer of nodeA will by triggered, and= the negotiation
process
=
is same as case (2).
In summary, by adding reserve hard cell procedure into version-00
of 6tus, we can let the bundle reservation i= n every scenarios be
triggered just in one side.
How do you think?
<= /blockquote>
Great first start in defining the scenarios.
Qin
=
Hi Qin:
=
I think we are on the same line. The ser= vices that 6TUS proposes
do not depend on which protocol the request came in through.
Since we are defining the protocol extensions, we'll make sure
that the new information is directly digestible by the 6TUS=
layer.
The protocol exten= sions will be separate specs, and there should
be little to no dereference between those sp= ecs and yours.
What's important to me to discuss is how we establish a bundle<= br>
of
cells between A and B.
IMHO, it would be best if that can be achi= eved by triggering a
service in A - no need to trigger B as wel= l.
That way, the volume of exchanges between PCE and nodes can be
devided by 2.
This would mean that there must be an exchange between 6TUS in A=
and 6TUS in B.
Which  also would mean that there is a= protocol part related to
<= /blockquote>
6TUS=E2=80=A6
Fully agreed that this is needed. Being an independent layer, I<= /span>
don't see why not.
=
Cheers,
Pascal
-----Original Message-----
From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On
Behalf Of Qin Wang
Sent: vendredi 15 mars 2013 18:04
To: JeongGil Ko
Cc: 6tsch@ie= tf.org; Xavier Vilajosana
Subject: Re: [6tsch] Schemes for resource allocation in the LLN
for 6tus
John and Xavi,
I agree that understanding more about upper l= ayer protocols like
RSVP and NSIS is very helpful for designing 6= tus. But, I want to
make clearer about my understanding on the r= elationship between
6tus and existing reservation protocols like= RSVP or NSIS.
(1) When we talk about reservation in the context of 6tus, we
mainly focus on  link resource (i.e. cell) reservation, whi= ch is
required/ triggered by upper layer. Even in the pure centralized
approach, it may happen to cross-layer reserve both L3 and L2
resource, but you still can separate them logically.
(2) The upper la= yer requirement to 6tus may come from PCE
carried
by protocol like CoAP, may come from the RSV= P/NSIS entity inside
nodes.
<= /blockquote>
Thus, for 6tus= , the question is what kind of function and
interface should be provided to support the upper layer, instead
of which upper layer protocol should be used.
How do you think= ?
I agree with your arguments that the important thing is defining
the
=
functionalities. It seems like some of these efforts are on the=
way
=
in the later emails. Me bringing in the term "RSVP" was not that I
wanted to go an use RSVP in the way it i= s, but bring the
(modified/customized) concept in for use in 6tus. As to what I
read
there may have been a misunderstanding between us but we are on
the
same line.
Thanks!
-John
=
Qin
=
____________________________________________= ___
6tsch mailing li= st
6tsch@ietf.org
https://www.ietf.org/mailman/listinfo/6tsch

_______________________________________________
6tsch mailing list
6tsch@ietf.org
https://www.ietf.org/mai= lman/listinfo/6tsch

<= /span>

_________________________= ______________________
6tsch mailing list
6tsch@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/6tsch


____________________= ___________________________
6tsch mailing list
6tsch@ietf.org
https://www.ietf.org/mai= lman/listinfo/6tsch
= --Apple-Mail-FE4549D6-6C1E-48C9-BD53-3793272C8F95-- Return-Path: 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 01D9121F8CCB for <6tsch@ietfa.amsl.com>; Tue, 19 Mar 2013 12:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 pH75Yu4jsR9k for <6tsch@ietfa.amsl.com>; Tue, 19 Mar 2013 12:08:37 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 9F29921F8B20 for <6tsch@ietf.org>; Tue, 19 Mar 2013 12:08:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12527; q=dns/txt; s=iport; t=1363720117; x=1364929717; h=from:to:subject:date:message-id:mime-version; bh=HortbgAtCgYyGz3IzzHZjkojX1WhfXNWG2orHofmF4E=; b=UwZTlRc0nzvN5KIg9zfwp+Vn/wgm29tABgRdgqzztg+iCmvUSaDHuxGx VbpbjZKrWbi3XE4lJ0b3NZSWR99J3bL9EbntpKqQvt8Pbr84KwPZ0R6RV re4bS270XWI2WjCfJWfHWQxVxUm+Z3r6qqUwVnqhCj39RKlo+bkxlJM10 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAHG2SFGtJXHA/2dsb2JhbABDhBPBCIFaFm0HgiYBBC1BHQEqViYBBBuIDKBtkRWQEYkBhVyDF2EDp2GDCoIo X-IronPort-AV: E=Sophos;i="4.84,873,1355097600"; d="scan'208,217";a="189212182" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-6.cisco.com with ESMTP; 19 Mar 2013 19:08:33 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r2JJ8XWU018985 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <6tsch@ietf.org>; Tue, 19 Mar 2013 19:08:33 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.152]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0318.004; Tue, 19 Mar 2013 14:08:33 -0500 From: "Pascal Thubert (pthubert)" To: "6tsch@ietf.org" <6tsch@ietf.org> Thread-Topic: focussing on charter: use cases Thread-Index: Ac4k1OmP4544fW5MRUSgOucw3DT4aQ== Date: Tue, 19 Mar 2013 19:08:32 +0000 Deferred-Delivery: Tue, 19 Mar 2013 19:07:00 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.104.2] Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD835CFF68Bxmbrcdx01ciscoc_" MIME-Version: 1.0 Subject: [6tsch] focussing on charter: use cases 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 19:08:39 -0000 --_000_E045AECD98228444A58C61C200AE1BD835CFF68Bxmbrcdx01ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear ML: The activity that we generate on the mailing list is a good indication we w= ill be very successful as a WG. First thing first, though, we need to creat= e the WG and need to focus a little bit on the necessary steps to get there= . We need to put together a rough charter, and convince an AD, probably Adria= n from Routing Area or Ted from Internet Area, that we have real problems t= o solve and that we, as a group, can provide valuable answers. The ADs agen= das are very full all the time, but certainly peaks around the meeting time= s. So we have about 2 week in front of us to prepare a solid case. So I suggest we step back a minute from the details of time frames and prio= rities and spend some energy on the use cases, the problems we are solving,= and the work we have to do to get there. I notice a cool discussion on mob= ility and the particular case of a crane, well that's a use case. We alread= y had centralized deterministic (hard slot) routes for command and control,= distributed deterministic (soft slots) and non deterministic QoS based flo= ws. Do we have others cases? Cheers, Pascal --_000_E045AECD98228444A58C61C200AE1BD835CFF68Bxmbrcdx01ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear ML:

 

The activity that we generate on the mailing list is= a good indication we will be very successful as a WG. First thing first, t= hough, we need to create the WG and need to focus a little bit on the neces= sary steps to get there.

 

We need to put together a rough charter, and convinc= e an AD, probably Adrian from Routing Area or Ted from Internet Area, that = we have real problems to solve and that we, as a group, can provide valuabl= e answers. The ADs agendas are very full all the time, but certainly peaks around the meeting times. So we hav= e about 2 week in front of us to prepare a solid case.

 

So I suggest we step back a minute from the details = of time frames and priorities and spend some energy on the use cases, the p= roblems we are solving, and the work we have to do to get there. I notice a= cool discussion on mobility and the particular case of a crane, well that’s a use case. We already had c= entralized deterministic (hard slot) routes for command and control, distri= buted deterministic (soft slots) and non deterministic QoS based flows. Do = we have others cases?

Cheers,

 

Pascal

 

 

--_000_E045AECD98228444A58C61C200AE1BD835CFF68Bxmbrcdx01ciscoc_-- Return-Path: 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 4C1AD21F8F68 for <6tsch@ietfa.amsl.com>; Tue, 19 Mar 2013 09:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.309 X-Spam-Level: X-Spam-Status: No, score=-2.309 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_53=0.6, 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 cAH8XDjDW21P for <6tsch@ietfa.amsl.com>; Tue, 19 Mar 2013 09:57:28 -0700 (PDT) Received: from mail-pb0-f48.google.com (mail-pb0-f48.google.com [209.85.160.48]) by ietfa.amsl.com (Postfix) with ESMTP id EF57F21F85DB for <6tsch@ietf.org>; Tue, 19 Mar 2013 09:57:27 -0700 (PDT) Received: by mail-pb0-f48.google.com with SMTP id wy12so586131pbc.7 for <6tsch@ietf.org>; Tue, 19 Mar 2013 09:57:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=Ls7FHhR/P++JcG7b/KO6rJkA4JBFuvfIQAhQacVCxaQ=; b=yXTsIAJh7T+B1lzOEUz9nuq8edlchSGZsXWMhLep+kVmBOUJ6u419YffYkIsIxGTgY 4PmbIyt6wk7nT0B9WffiXufC2BfeGFG8ONXHcgdx0RMKKLVUasiin47f4nrMve1taatK vroZeb/2c4ArJQCM29jmmrz3KFwhLcMvv7LG5+3vEd8PJi+Au+EzMhJnaXchAAm1GXtv CCAF8Vh4w6cbpgbaCBH9CuZox6WOWvu8T9DXWPQsM4m8cResKkdEugp8Jd+fo21WyIzp 5tUG7N2rfG9IawQwl1/PS2zJouihk61PnDXbItUTSgncCziXBWCZz7pCsHhYpnDQplAY UjTg== MIME-Version: 1.0 X-Received: by 10.66.122.162 with SMTP id lt2mr4322331pab.168.1363712247712; Tue, 19 Mar 2013 09:57:27 -0700 (PDT) Sender: twatteyne@gmail.com Received: by 10.68.227.71 with HTTP; Tue, 19 Mar 2013 09:57:27 -0700 (PDT) In-Reply-To: <775F44DA-D912-4B36-B241-E176FBD585F1@gmail.com> References: <956BA951-CF3C-4F00-A80E-73D641634224@gmail.com> <514248DA.6090403@eecs.berkeley.edu> <6A4E9484-B0D0-4F8E-AF13-C5AC74D230CF@gmail.com> <1b28192c14eed60c7a6621f6b9b02e6a.squirrel@calmail.berkeley.edu> <0B5235F3-6E4F-46AE-B59E-DE63FC47AA95@gmail.com> <5332a47730edc8ed350124947c6d9d4f.squirrel@calmail.berkeley.edu> <2b68f317c14dc5ae864813e632d55fcd.squirrel@calmail.berkeley.edu> <51475694.85d00e0a.2654.3c21@mx.google.com> <1b952faca1b2846136ff23c6723eeb63.squirrel@calmail.berkeley.edu> <51476DC1.5070707@eecs.berkeley.edu> <775F44DA-D912-4B36-B241-E176FBD585F1@gmail.com> Date: Tue, 19 Mar 2013 09:57:27 -0700 X-Google-Sender-Auth: _6jwNEG0FplPHZsy-6kIc-AsN2I Message-ID: From: Thomas Watteyne To: "6tsch@ietf.org" <6tsch@ietf.org> Content-Type: multipart/alternative; boundary=047d7bf0e8a419d26f04d84a0077 Subject: Re: [6tsch] R: Schemes for resource allocation in the LLN for 6tus 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 16:57:30 -0000 --047d7bf0e8a419d26f04d84a0077 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Alfredo, This is an interesting use case you bring up. Do you have a specific use case/problem you are trying to solve? I agree with Qin that it would be great if this were a schedule-only decision, i.e. we change as little as possible in the mechanism (e.g. 6tus), but rather have the scheduling entity build an (otherwise normal) schedule which allows for some motes to roam around. Thomas On Tue, Mar 19, 2013 at 1:58 AM, Grieco wrote: > Hi Qin, > > It does work for me: thanks for the clarification > > Cheers > > Alfredo > > -- > Luigi Alfredo Grieco, PhD > Assistant Professor > Department of Electrical and Information Engineering > Politecnico di Bari > Via Orabona 4 - 70125 - Bari - Italy > +39 080 5963 911 > telematics.poliba.it/grieco > Skype id: l.alfredo.grieco > Mobile: +39 3346715672 > > > On 19 Mar 2013, at 01:09, "Qin Wang" wrote: > > Alfredo, > > I think there are two key features in your description: (1)data with high > priority, and (2)mobility. I would like to think the two feature > separately. > > Regarding to the high priority, I think the QoS mechanism like DSCP can > handle it, no matter the data flow come from static node or moving node. > > Regarding to the mobility, the 6tus can support to establish tracks for > specific purpose. Actually, the cell reservation request comes from upper > layer, 6tus do not know the reserved cells will be used by static nodes o= r > mobile nodes. In another word, upper layer can ask 6tus to reserve some > cells or tracks or pipes which specifically used for mobile node to send > data as you said. > > Does it make sense? > > Qin > > > > > Hi Xavi, Thomas, all > > > The problem I am pointing out is not related only to the neighbourhood. A= s > > a matter of fact, a node would like its data be received to the sink and > > not only at the next hop. If for each hop to travel, a data packet should > > gain a cell through some request/answer handshake this would lead to high > > e2e delays when the depth of the tree is high and would incur useless > > signalling. > > > If we think at TASA, to do an example, the schedule exactly rules the > > story of each packet from its generating node to the sink. I was trying t= o > > figure out how to do the same in presence of some uncertainty on the > > network topology. > > > While solving this problem is something to be afforded in some scientific > > paper, I believe that the functionalities of 6tus and the entire > > architecture we are envisaging should be ready to welcome this new wave o= f > > algorithms. > > > In other terms, I am proposing to add a limited number of "reserved pipes= " > > to the sink that could be used to transport "only" urgent data from mobil= e > > nodes. > > > Thomas, this could be added as general remark to the architecture or to > > the draft you are editing. Of course, with more details, some primitive t= o > > the 6tus draft could be added or lead to a new draft on handling mobile > > 6tsch nodes. > > > Cheers :-) > > > > -- > > Luigi Alfredo Grieco, PhD > > Assistant Professor > > Department of Electrical and Information Engineering > > Politecnico di Bari > > Via Orabona 4 - 70125 - Bari - Italy > > +39 080 5963 911 > > telematics.poliba.it/grieco > > Skype id: l.alfredo.grieco > > Mobile: +39 3346715672 > > > > On 18 Mar 2013, at 20:40, Xavier Vilajosana > > wrote: > > > Hi Alfredo, > > > just one point on mobility. > > TSCH networks may require certain time for a node to join, this depends > > on how the EBs are sent and what are the policies for the joining node > > on how to scan the different channels. Having said that, I think that > > the time required for a node to reserve some cells with its neighbour is > > extremely less than the joining time and hence if a mobile node can join > > the network for sure has time to schedule some links. So maybe this is > > not a big problem :-) > > > cheers! > > Xavi > > > > > > On 18/03/13 12:36, Grieco wrote: > > Hi Qin, Thomas, and all > > > Perhaps the only way to cope with (a reasonable degree of) mobility is > > to hardly assign a certain number of cells at each link to be used in > > case a mobile node arrives with urgent data to transmit. > > > Obviously this would slightly decrease the overall efficiency of the > > system because such "guaranteed cells" could get unused in most of > > cases. > > > If, on the other side, the mobile node is generating data which is not > > that urgent, soft reservation could be used as well, which should waste > > a smaller amount of resources. > > > In this perspective, mobile nodes could be handled using either > > functions 1 or 2, depending on the degree of mobility, the priority of > > the data packets generated by mobile nodes, the desired duty cycle, and > > so on. > > > Cheers > > > Alfredo > > > > > > -- > > Luigi Alfredo Grieco, PhD > > Assistant Professor > > Department of Electrical and Information Engineering > > Politecnico di Bari > > Via Orabona 4 - 70125 - Bari - Italy > > +39 080 5963 911 > > telematics.poliba.it/grieco > > Skype id: l.alfredo.grieco > > Mobile: +39 3346715672 > > > > On 18 Mar 2013, at 20:20, "Qin Wang" wrote: > > > Alfredo, > > > I think your remark is correct. So, if there is lots of mobility, I > > would > > be prefer distributed approach, i.e. Soft Cell reservation locally + > > RPL + > > DSCP for QoS. > > > Qin > > > > Hi Qin, > > Your proposal is sound. > > Just a final remark: if my understanding is correct, the PCE should > > build > > a schedule that spans across multiple links from mobile node M > > towards the > > sink S. > > If a M moves after the schedule has been built, some pre-assigned > > resources along that path could get lost (which could be tolerated) > > because of the change of the topology. > > Is it ok ? > > Cheers and thanks for your answer > > Alfredo > > -----Messaggio originale----- > > Da: Qin Wang [mailto:qinwang@berkeley.edu ] > > Inviato: Monday, March 18, 2013 6:48 PM > > A: Grieco > > Cc: Qin Wang; JeongGil Ko; Pascal Thubert (pthubert); 6tsch@ietf.org; > > Xavier Vilajosana > > Oggetto: Re: [6tsch] Schemes for resource allocation in the LLN for > > 6tus > > Alfredo, > > Firstly, my understanding is Hard cell reservation can only be used > > by > > PCE, i.e. centralized schedule. Thus, mobile node will join in > > network > > based on the cells broadcast in EB. And, after its registration, PCE > > will > > assign some Hard cells to it. > > secondly, regarding to high priority of the data flow from the mobile > > node, DSCP may help, i.e. the packets from the mobile node can > > include > > Priority. > > How do you think? > > Qin > > Hi Qin and all, > > Just to challenge the two groups of functions Qin is talking about, > > what if a certain number of mobile nodes need hard reservation ? In > > this case, mobile nodes transmit Real time data to be delivered > > within > > a given deadline but 6tus does not know in advance the rank (or the > > position within the topology) of such nodes. > > I mean that this kind of traffic has the top priority but nobody > > knows > > in advance the exact position of the nodes that is going to generate > > that data. > > Do we need a further case ? Or we can leverage on 1 or 2 ? If yes, > > how ? > > Thanks a lot in advance for your attention > > Cheers > > Alfredo > > -- > > Luigi Alfredo Grieco, PhD > > Assistant Professor > > Department of Electrical and Information Engineering Politecnico di > > Bari Via Orabona 4 - 70125 - Bari - Italy > > +39 080 5963 911 > > telematics.poliba.it/grieco > > Skype id: l.alfredo.grieco > > Mobile: +39 3346715672 > > On 17 Mar 2013, at 17:47, "Qin Wang" wrote: > > I fully agree with Carsten that Simple is very important. Let's > > overlapping the following three scenarios, then we will find only > > two > > groups of functions 6tus should provide. > > (1) Hard cell reserve/remove, which supports the 1st scenario. > > (2) Soft cell reserve/remove, which supports the 2nd and 3rd > > scenario. > > Any more? > > Qin > > Sorry for the delayed response. I was stuck on the plane for too > > long > > :) > > I like the discussion that Qin is going for where we define the > > scenarios. > > At the same time, as Carsten says we need to make sure overlapping > > scenarios of any sort are simplified and aggregated as much as > > possible. > > Let me just try to put my 2 cents in-line... > > On Mar 17, 2013, at 8:19 AM, Qin Wang > > wrote: > > Hi Pascal, > > It is a very good idea to establish a bundle of cells between A > > and > > B by just triggering 6tus in one side. We can design for > > different > > scenarios. > > (1) PCE defines the track, i.e. the multihop path, the bandwidth > > of > > each hop, and scheduling hard-cells to implement the multihop > > path. > > Assume nodeA and nodeB are one-hop neighbors along the path. In > > this case, PCE can send Create.hardcell command to 6tus layer in > > nodeA,and nodeA's 6tus sends Create.hardcell command to nodeB' > > 6tus, then the hard cell is reserved. This function is not in the > > current version of 6tus draft, but we can add it in the next > > version easily. > > (2)PCE defines the multihop path and the bandwidth of each hop, > > but > > not schedules the cells to meet the path bandwidth. In this case, > > soft cell reservation will be applied, which is always triggered > > in > > Transmitting side, and negotiated by the 6tus layer of both > > sides. > > (3)The cell reservation is triggered by upper layer, e.g. the > > RSVP/NSIS entity in nodeA. Then soft cell reservation process in > > 6tus layer of nodeA will by triggered, and the negotiation > > process > > is same as case (2). > > In summary, by adding reserve hard cell procedure into version-00 > > of 6tus, we can let the bundle reservation in every scenarios be > > triggered just in one side. > > How do you think? > > Great first start in defining the scenarios. > > Qin > > Hi Qin: > > I think we are on the same line. The services that 6TUS proposes > > do not depend on which protocol the request came in through. > > Since we are defining the protocol extensions, we'll make sure > > that the new information is directly digestible by the 6TUS > > layer. > > The protocol extensions will be separate specs, and there should > > be little to no dereference between those specs and yours. > > What's important to me to discuss is how we establish a bundle > > of > > cells between A and B. > > IMHO, it would be best if that can be achieved by triggering a > > service in A - no need to trigger B as well. > > That way, the volume of exchanges between PCE and nodes can be > > devided by 2. > > This would mean that there must be an exchange between 6TUS in A > > and 6TUS in B. > > Which also would mean that there is a protocol part related to > > 6TUS=85 > > Fully agreed that this is needed. Being an independent layer, I > > don't see why not. > > Cheers, > > Pascal > > -----Original Message----- > > From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org<6tsch-bounces= @ietf.org>] > On > > Behalf Of Qin Wang > > Sent: vendredi 15 mars 2013 18:04 > > To: JeongGil Ko > > Cc: 6tsch@ietf.org; Xavier Vilajosana > > Subject: Re: [6tsch] Schemes for resource allocation in the LLN > > for 6tus > > John and Xavi, > > I agree that understanding more about upper layer protocols like > > RSVP and NSIS is very helpful for designing 6tus. But, I want to > > make clearer about my understanding on the relationship between > > 6tus and existing reservation protocols like RSVP or NSIS. > > (1) When we talk about reservation in the context of 6tus, we > > mainly focus on link resource (i.e. cell) reservation, which is > > required/ triggered by upper layer. Even in the pure centralized > > approach, it may happen to cross-layer reserve both L3 and L2 > > resource, but you still can separate them logically. > > (2) The upper layer requirement to 6tus may come from PCE > > carried > > by protocol like CoAP, may come from the RSVP/NSIS entity inside > > nodes. > > Thus, for 6tus, the question is what kind of function and > > interface should be provided to support the upper layer, instead > > of which upper layer protocol should be used. > > How do you think? > > I agree with your arguments that the important thing is defining > > the > > functionalities. It seems like some of these efforts are on the > > way > > in the later emails. Me bringing in the term "RSVP" was not that I > > wanted to go an use RSVP in the way it is, but bring the > > (modified/customized) concept in for use in 6tus. As to what I > > read > > there may have been a misunderstanding between us but we are on > > the > > same line. > > Thanks! > > -John > > Qin > > _______________________________________________ > > 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 > > --047d7bf0e8a419d26f04d84a0077 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Alfredo,

This is an interesting use = case you bring up. Do you have a specific use case/problem you are trying t= o solve?

I agree with Qin that it would be great if this were a schedule-only decisi= on, i.e. we change as little as possible in the mechanism (e.g. 6tus), but = rather have the scheduling entity build an (otherwise normal) schedule whic= h allows for some motes to roam around.

Thomas

On Tue, Mar 19, 2013 at 1:58 AM,= Grieco <alfredo.grieco@gmail.com> wrote:
Hi Qin,

It does work for me= : thanks for the clarification

C= heers

Alfredo

--
Luigi Alfredo Grieco, PhD
Assistant Professor
Department of Electrical and Information Engineering
Politecnico di Bari
Via Orabona 4 - 70125 - Bari - Italy
Skype id: l.alf= redo.grieco


On 19 Mar 2013, at 01:09, "Qin Wang" <qinwang@berkeley.edu> wrote:
Alfredo,
<= /span>
I think there are two key features in your description: (1)data with = high
priority, and (2)mobility. I would like to think the t= wo feature
separately.

Reg= arding to the high priority, I think the QoS mechanism like DSCP can=
handle it, no matter the data flow come from static node or moving no= de.

Regarding to the mobility, the 6tus ca= n support to establish tracks for
specific purpose. Actuall= y, the cell reservation request comes from upper
layer, 6tus do not know the reserved cells will be used by static nod= es or
mobile nodes. In another word, upper layer can ask 6t= us to reserve some
cells or tracks or pipes which specifica= lly used for mobile node to send
data as you said.

Does it make sense= ?

Qin




Hi Xavi, Thomas, all

The problem I am pointing out is not related only to the ne= ighbourhood. As
a matter of fact, a node would= like its data be received to the sink and
not only at the next hop. If for each hop to travel,= a data packet should
gain a cell through some reque= st/answer handshake this would lead to high
e2e delays when the depth of the tree is high and w= ould incur useless
signalling.

If we think at TASA, to do an example, the schedule exact= ly rules the
story of each packet from its = generating node to the sink. I was trying to
figure out how to do the same in presence of some = uncertainty on the
network topology.

While solving this problem is something to be affor= ded in some scientific
paper, I believe that the func= tionalities of 6tus and the entire
architecture we are envisaging should be ready to welcome t= his new wave of
algorithms.

In other terms, I am proposing to add a limited number of= "reserved pipes"
to the sink that could be used= to transport "only" urgent data from mobile
nodes.

Thomas, this = could be added as general remark to the architecture or to
the draft you are editing. Of course= , with more details, some primitive to
the 6tus draft could be added = or lead to a new draft on handling mobile
6tsch nodes.

Cheers :-)


--
Luigi Alfre= do Grieco, PhD
Assis= tant Professor
Depar= tment of Electrical and Information Engineering
Politecnico di Bari
=
Via Orabona 4 - 70125 - Bari -= Italy
+39 0= 80 5963 911
telematics.poliba.it/grieco
Skype id: l.alfredo.grieco
Mobile: +39 3346715672


On 18 Mar 201= 3, at 20:40, Xavier Vilajosana
<xvilajosana@eecs.berkeley.edu> wrote:

Hi Alfredo,
<= /blockquote>

just one point on mobility.
TSCH networks may r= equire certain time for a node to join, this depends
on how the EBs are sent and what are the policies for the joining = node
on how to scan the different channels. Having said that, I think that=
the time required for a node to reserve some cells with= its neighbour is
extremely less than the joining time and hence if a mobile node ca= n join
the network for sure has time to schedule some links. So maybe this i= s
not a big problem :-)

cheers!
Xavi


<= /blockquote>


On 18/03/13 12:36, Grieco wrote:
=
Hi Qin, Thomas, and all

Perhaps= the only way to cope with (a reasonable degree of) mobility is
to hardly assign a certain = number of cells at each link to be used in
case a mobile node arrives with urgent data to transm= it.

Obviously this would slightly dec= rease the overall efficiency of the
system because such "g= uaranteed cells" could get unused in most of
cases.

If, on the other side, the = mobile node is generating data which is not
that urgent, soft reservation could be used as well, = which should waste
a smaller amount = of resources.

In this perspective, mobile= nodes could be handled using either
functions 1 or 2, depending on the degree of mobility, the priorit= y of
the data packets = generated by mobile nodes, the desired duty cycle, and
so on.
=

Cheers
=

Alfredo


=

--
Luigi Alfredo Grieco, PhD
Assistant Professor
Department of Electrical and Information Engineering
Politecnico di Bari
Via Orabona 4 - 70125 - Bari - Italy
+39 080 5963 911