From nobody Sat Nov 1 10:20:15 2014 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0D1E1A897D; Sat, 1 Nov 2014 10:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.609 X-Spam-Level: X-Spam-Status: No, score=-7.609 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_IS_IT_OUR_ACCOUNT=4.2, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VbXyL4Z6AeWw; Sat, 1 Nov 2014 10:20:05 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1600F1A89EF; Sat, 1 Nov 2014 10:20:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11898; q=dns/txt; s=iport; t=1414862405; x=1416072005; h=from:to:cc:subject:date:message-id:mime-version; bh=J+lVp2xwUiieJi35k45DIQCblwDRZyZJDX941EGl2Yw=; b=Vq13oRuI638xvKfJ9MklpKetbG4boZ2q4ELRZxhq5mP4ei8T8lSN58uZ VMxhw26uKtNaoqn4VXGsU0FHIiDz6/vg45SWbPMMA5jcf2R6ZkegbhLQr 2tbxJ1J04a/tEyUIRJha1wkjxXMIMeRXgaM84pmiSqI8nAwowjD/gx+qP o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEFAFsVVVStJA2H/2dsb2JhbABCFwOCSEZUWATNQodJAoEVFgEBAQEBcguEBAEELRsNERMSARoQCgEDDDwXDQIBAQMODYg5DTi6FBGOWwEBAQEBAQEBAQEBAQEBAQEBAQEBAReQTBMhDAQQAQcHgxWBHgWGNYtlhE+IST2DEIdyhVeECYMlU2wBgQ45eQoBAQE X-IronPort-AV: E=Sophos;i="5.07,295,1413244800"; d="scan'208,217";a="368439584" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-7.cisco.com with ESMTP; 01 Nov 2014 17:20:04 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id sA1HK3bb004563 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 1 Nov 2014 17:20:03 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.207]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Sat, 1 Nov 2014 12:20:03 -0500 From: "Pascal Thubert (pthubert)" To: "6tisch@ietf.org" <6tisch@ietf.org> Thread-Topic: 6TiSCH Working Group Virtual Interim Meeting, November 7, 2014 Thread-Index: Ac/1+AzBb+Wx66zcS5CGRy1rr7GmKQ== Date: Sat, 1 Nov 2014 17:20:02 +0000 Deferred-Delivery: Sat, 1 Nov 2014 17:20: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.82.125] Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD848A398CExmbrcdx01ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch/LCxtfKSq6DKhk-xU-PDLJjNf5rs Cc: "iesg-secretary@ietf.org" Subject: [6tisch] 6TiSCH Working Group Virtual Interim Meeting, November 7, 2014 X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Nov 2014 17:20:09 -0000 --_000_E045AECD98228444A58C61C200AE1BD848A398CExmbrcdx01ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all: The interim was announced in advance by Amy from the IESG secretary, follow= ing IETF procedures. This Friday, we'll prepare for the Hawaii meeting and go rapidly through th= e meeting draft slides. The agenda of the interim is thus aligned to that of the WG: - Administrivia _[2min]_ * Approval agenda * Approval minutes last call * overview new I-Ds _[3min]_ * IETF91 admin _[5min]_ * meetecho remote presentation * final agenda * run through draft-ietf-6tisch-minimal-03 _[5min]_ (Xavi Vilajosana) * run through draft-ietf-6tisch-6top-interface-02 _[5min]_ (Thomas Watteyne= ) * run through draft-finn-detnet-problem-statement-01 _[5min]_ (Norm Finn) * run through 6TiSCH ETSI Plugtest slides _[5min]_ (TBD) * run through draft-richardson-6tisch--security-6top-03 _[5min]_ (Michael R= ichardson) * run through draft-struik-6tisch-security-architecture-elements-01 _[5min]= _ (Rene Stuik) * RFC7322: RFC Style Guide _[5min]_ (Pascal Thubert) * AOB _[5min]_ You will find a detailed agenda at https://bitbucket.org/6tisch/meetings/. Propose any changes to the agenda by replying in this e-mail, or at the beg= inning of the call. Remember that this call will be recorded. Pascal & Thomas ---- Topic: 6TiSCH Weekly Time: 8:00 am, Pacific Daylight Time (San Francisco, GMT-07:00) Meeting Number: 206 802 913 Meeting Password: sixtus ------------------------------------------------------- To start the online meeting ------------------------------------------------------- 1. Go to https://ciscosales.webex.com/ciscosales/j.php?ED=3D219615007&UID= =3D481905242&PW=3DNZTRkNDAwOTE1&RT=3DMiMyMw%3D%3D 2. Log in to your account. 3. Click "Start Now". 4. Follow the instructions that appear on your screen. ---------------------------------------------------------------- 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 To check whether you have the appropriate players installed for UCF (Univer= sal Communications Format) rich media files, go to https://ciscosales.webex= .com/ciscosales/systemdiagnosis.php http://www.webex.com CCM:+14085256800x206802913 --_000_E045AECD98228444A58C61C200AE1BD848A398CExmbrcdx01ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all:

 

The interim was announced in advance by Amy from the= IESG secretary, following IETF procedures.

This Friday, we’ll prepare for the Hawaii meet= ing and go rapidly through the meeting draft slides.

The agenda of the interim is thus aligned to that of= the WG:

 

- Administrivia _[2min]_

    * Approval agenda

    * Approval minutes last call=

* overview new I-Ds _[3min]_

* IETF91 admin _[5min]_

    * meetecho remote presentation

    * final agenda

* run through draft-ietf-6tisch-minimal-03 _[5min]_ = (Xavi Vilajosana)

* run through draft-ietf-6tisch-6top-interface-02 _[= 5min]_ (Thomas Watteyne)

* run through draft-finn-detnet-problem-statement-01= _[5min]_ (Norm Finn)

* run through 6TiSCH ETSI Plugtest slides _[5min]_ (= TBD)

* run through draft-richardson-6tisch--security-6top= -03 _[5min]_ (Michael Richardson)

* run through draft-struik-6tisch-security-architect= ure-elements-01 _[5min]_ (Rene Stuik)

* RFC7322: RFC Style Guide _[5min]_ (Pascal Thubert)=

* AOB _[5min]_

 

You will find a detailed agenda at https://bitbucket= .org/6tisch/meetings/.

Propose any changes to the agenda by replying in thi= s e-mail, or at the beginning of the call.

 

Remember that this call will be recorded.=

 

Pascal & Thomas

 

----

 

Topic: 6TiSCH Weekly

 

Time: 8:00 am, Pacific Daylight Time (San Francisco,= GMT-07:00)

Meeting Number: 206 802 913

Meeting Password: sixtus

 

----------------------------------------------------= ---

To start the online meeting

----------------------------------------------------= ---

 

1. Go to https://ciscosales.webex.com/ciscosales/j.p= hp?ED=3D219615007&UID=3D481905242&PW=3DNZTRkNDAwOTE1&RT=3DMiMyM= w%3D%3D

2. Log in to your account.

3. Click "Start Now".

4. Follow the instructions that appear on your scree= n.

 

----------------------------------------------------= ------------

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

----------------------------------------------------= ------------

 

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

 

Please dial the local access number for your area fr= om the list below:

- San Jose/Milpitas (408) area: 525-6800<= /p>

- RTP (919) area: 392-3330

 

----------------------------------------------------= ---

To join the teleconference only

----------------------------------------------------= ---

 

1. Dial into Cisco WebEx (view all Global Access Num= bers at

http://cisco.com/en/US/about/doing_business/conferen= cing/index.html

2. Follow the prompts to enter the Meeting Number (l= isted above) or Access Code followed by the # sign.

 

San Jose, CA: +1.408.525.6800 RTP: +1.919.39= 2.3330

US/Canada: +1.866.432.9903 United Kingdom: += 44.20.8824.0117

India: +91.80.4350.1111 Germany: +49.619.677= 3.9002

Japan: +81.3.5763.9394 China: +86.10.8515.56= 66

 

To check whether you have the appropriate players in= stalled for UCF (Universal Communications Format) rich media files, go to htt= ps://ciscosales.webex.com/ciscosales/systemdiagnosis.php

 

http://www.webex.co= m

 

CCM:+14085256800x206802913

--_000_E045AECD98228444A58C61C200AE1BD848A398CExmbrcdx01ciscoc_-- From nobody Mon Nov 3 17:46:36 2014 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E83081A1B55 for <6tisch@ietfa.amsl.com>; Mon, 3 Nov 2014 17:46:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.016 X-Spam-Level: X-Spam-Status: No, score=-1.016 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pp3h0gVTyArX for <6tisch@ietfa.amsl.com>; Mon, 3 Nov 2014 17:46:29 -0800 (PST) Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B8221A1B69 for <6tisch@ietf.org>; Mon, 3 Nov 2014 17:46:29 -0800 (PST) Received: by mail-pd0-f179.google.com with SMTP id g10so12680600pdj.10 for <6tisch@ietf.org>; Mon, 03 Nov 2014 17:46:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:content-type; bh=s3mvDLvYZQxjWiUyOz4VHYUJjV8bf6MtNojyrUCpgOY=; b=CmMpeyPDY+RMNQFBdaFMuNMewzYESCgd+XrgsWpMFm5mRHqUOMk4vrn+oS+GEU2lR5 xKkWbIQU1CaK28Dap4GMlTIUHA8MO+txUBKyenG6Jdogxs2jmRka0aQo2hQoaX/prw4g Cb06Mat4S7dj9Sym+0rnGIw2yWC5J1gfwOk051TMDNwesHAKtK1KN9ghSXNQa4jBVMr9 eKSWb5e7bairY7V06Suz4NnMtAAzYTglpYw/Xc49bzXt3lK8xL4fgk8h8MwlTnQKq5dk 72MIa5pQVp672gn4HRS+tok/M3/8O0pAivfO5Jpt9KvfwDV8P5gYTXnjL7vL1MIZnc8L 7tYQ== X-Received: by 10.70.45.40 with SMTP id j8mr6882932pdm.130.1415065589207; Mon, 03 Nov 2014 17:46:29 -0800 (PST) MIME-Version: 1.0 Sender: twatteyne@gmail.com Received: by 10.66.88.42 with HTTP; Mon, 3 Nov 2014 17:46:08 -0800 (PST) From: Thomas Watteyne Date: Mon, 3 Nov 2014 17:46:08 -0800 X-Google-Sender-Auth: G7qqqKyEbpyhvvzu7yDbVA7dk3A Message-ID: To: "6tisch@ietf.org" <6tisch@ietf.org> Content-Type: multipart/alternative; boundary=047d7bf18b76c75a910506fea1d6 Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch/VOtwcEbP066fOA58LOzwZ1cyC6c Subject: [6tisch] Minutes Webex 24 October 2014 X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 01:46:35 -0000 --047d7bf18b76c75a910506fea1d6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable All, You will find the minutes of the last 6TiSCH interim call below (also at https://bitbucket.org/6tisch/meetings/ and https://www.ietf.org/meeting/interim/proceedings.html). Reply with comments/suggestions. We will approve these minutes at the next 6TiSCH interim call. Thomas --- Minutes Webex 24 October 2014, 6TiSCH WG Note: timestamps in PDT. Connection details - Webex: https://ciscosales.webex.com/ciscosales/j.php?ED=3D219615007&UID=3D48190= 5242&PW=3DNZTRkNDAwOTE1&RT=3DMiMyMw%3D%3D - Etherpad: http://etherpad.tools.ietf.org:9000/p/6tisch?useMonospaceFont=3Dtrue - Topic: 6TiSCH Weekly - Time: 8:00 am, Pacific Daylight Time (San Francisco, GMT-07:00) - Meeting Number: 206 802 913 - Meeting Password: sixtus - CCM: +14085256800x206802913 Resources - Webex recording: https://cisco.webex.com/ciscosales/lsr.php?RCID=3Db4029b074a00492fa13449= 29ac3cf8fd - Wiki: https://bitbucket.org/6tisch/meetings/wiki/141024_webex - Slides: https://bitbucket.org/6tisch/meetings/src/master/141024_webex/slides_141= 024_webex.ppt Taking notes *(using Etherpad)* 1. Pascal Thubert 2. Xavi Vilajosana 3. Thomas Watteyne Present *(template)* 1. Ariton Xhafa 2. Diego Dujovne 3. Guillaume Gaillard 4. Giuseppe Piro 5. Ines Robles 6. Maria Rita Palattella 7. Michael Richardson 8. Nicola Accettura 9. Pascal Thubert 10. Pat Kinney 11. Raghuram Sudhaakar 12. Thomas Watteyne 13. Xavi Vilajosana Action Items - *Thomas* to update draft-ietf-6tisch-tsch by cut-off date. - *Pascal* and *Thomas* to talk to Ted about whether to push for 6TiSCH-specific CoAP draft, or wait for generic constrained management solution. - *Xavi* to cite draft-thubert-6lo-rpl-nhc-02 in next revision of draft-ietf-6tisch-minimal - *Michael* to publish a revision of the security draft with a clear text describing the needs in terms of data representation elements so th= e 6top data model can be updated. - *Michael* to publish a revision of the security draft with a clear text describing the needs in terms of data representation elements so th= e 6top data model can be updated. Agenda - Administrivia *[2min]* - Approval agenda - Approval minutes last call - IETF91 *[5min]* - meetecho remote presentation - draft agenda - draft-ietf-6tisch-tsch-02 publication *[2min]* - please review - wrapping up draft-ietf-6tisch-minimal *[15min]* - presentation draft-richardson-6tisch--security-6top-02 *[15min]* - RPL option status and update 6lo *[10min]* - RFC7322: RFC Style Guide *[5min]* - AOB *[5min]* Minutes - *[08.05]* Meeting starts *[Chairs]* - *Pascal* starts recording - *Thomas* presents agenda - update on IETF91 and draft agenda - present 2 draft and its status/evolution - *Michael* will present security draft status - *Pascal* will present status of RPL option at 6lo - if time permits, RF7322 will be introduced. - *[08.08]* Administrivia *[Chairs]* - Approval agenda No issues raised. Agenda approved. - Approval minutes last call - No issues raised. Minutes last call approved. - *Thomas* There was a security call on Tuesday. Went through draft-richardson-6tisch--security-6top-03. It will be presented today= . - *[08.12]* IETF91 *[Thomas]* - IETF91 agenda is final. Meeting is 9am in Hawaii, i.e. 8pm CET time same day. - Meetecho available. Remote presentations and remote attendance. - Recording and minutes will reflect remote participation. - *Michael* Visa's from 104 attendees from China have not been approved yet. - *Thomas* First time that every session is in meetecho. - For remote presenters, there will be tests to make sure everything works well. - This Monday is the cut-off date for draft submission. Authors are called to submit their drafts before Monday. - Monday is also cutoff for draft agenda. - Initial agenda for 6TiSCH WG meeting. - present latest changes on drafts - TSCH draft, 6top interface draft, and minimal - introduction to plugtest at 93rd IETF meeting, with help of ETSI. Renamed from plugfest to plugtest as it related to verificat= ion. - Rechartering discussion to define next steps (include dynamic scheduling, etc.) - Security: Michael will present a revision of his draft and then Ren=C3=A9 has remarks Action: *Thomas* to update draft-ietf-6tisch-tsch by cut-off date. - Maria Rita volunteers to present TSCH draft - Xavi volunteers to present minimal and 6top interface drafts, if necessary - Both presenters will do it remotely. - *[08.19]* draft-ietf-6tisch-tsch-02 publication *[Thomas]* - version 02 published - follows the rewording proposed during the call - 3 issues still open: - http://tools.ietf.org/wg/6tisch/trac/ticket/25. Rewording proposal. Rene did not agree. There is a follow up at the ML. - an issue is opened to change mote to node as node is what we agreed. - *Pascal* what about term "LLN nodes"? - *Thomas* suggests to use term "LLN node" in first occurrence and follow with "node". - *Pascal* several draft are going to be sent to the IESG in November. The last call will be announced at IETF91 and then we will = have an evaluation/call for consensus for 2 weeks before submitting. - List of drafts considered: TSCH, Minimal, 6top-interface, CoAP. We need to decide what we do with them. - *Thomas* what about architecture draft? What is the current status and what is the timeline for this draft. - *Thomas* Would there be a problem if we recharter without having finalized the architecture draft? - *Pascal* I do not see any specific problem. - *Thomas* what about the CoAP draft? what should we do? Wait for the COMAN activity with constrained RESTCOnf draft? or push for our CoAP draft. - *Pascal* we have milestones with the IESG. We can delay the CoAP draft after recharter to see what is the progress of the RESTConf, et= c. - *Raghuram* Agrees to wait. Action: *Pascal* and *Thomas* to talk to Ted about whether to push for 6TiSCH-specific CoAP draft, or wait for generic constrained management solution. - *Michael* asks if there is a date for the ETSI event. - *Thomas* there is no specific date but it might be a couple of days before (or Monday) talking to IETF to see if this is possible. Target= is July 2015 in Prague right before IETF93 is the target. - *Michael* the Contiki people planned to have a conference, hack fest right before. This might be a conflict. - *Thomas* the ETSI test event is not a long thing it is just a set of schedules of tests and people attend to their specific tests. - *Ariton* Regarding the interop. Are there going to be a set of scenarios? - *Thomas* yes. The plan is to develop the test scenarios and come out with a set of tests (end March) - *Ariton* there will not be certification on that event. - *Thomas* not sure. We need to check with ETSI. - The point is to make standard better. the outcome is to validate to our documents are correct and we are "optimal" in their design. - *[08.xx]* wrapping up draft-ietf-6tisch-minimal *[Xavi]* - change in the CCA option. Reflected in the drawing at the beginning of TX slot, timing before CCA. This is a clarification to follow exac= tly the standard - added the missing timing - open questions, need opinion - HbH header compression. Agreed last time to go to 6lo. Should not limit further extensions even at cost of additional byte? - what should minimal specify for security? - asking implementors if IE we are sending are enough? - *Pascal*: published draft-thubert-6lo-rpl-nhc-02 - offers 3 possibilities: - (greedy) the one from NHC: consume 1/4 of NHC space (64 possibilities used) - (conservative) don't change layout at all, enumeration in 6LoWPAN NHC already, consume new header (but then need full byte after it) (1 possibilities used, but extra byte) - (middle) idea from Carsten: limit the same to something the same as greedy, but add a byte when "error". Consumes 4 bits (~20 possibilities used, 1 extra byte when error) - *Thomas* what is an "error"? - *Pascal* forwarding error (O,F bits) - *Pascal* problem is that you might need to change packet length during forwarding - *Thomas* agreed that this is the draft to cite in minimal? Action: *Xavi* to cite draft-thubert-6lo-rpl-nhc-02 in next revision of draft-ietf-6tisch-minimal. - *[Xavi]* what should draft-ietf-6tisch-minimal contain in terms of security? - *Pascal* I do not see the need to say anything, RPL has its own security, any security that applies to other protocols apply to minim= al. - *Michael* similarly, there must be L2 security, which we just inherit. - *[08.57]* presentation draft-richardson-6tisch--security-6top-02 *[Michael]* - Missing text for security pieces in 6top - join controller provides a certificate for the node (500 bytes), node may issue a cert request. - OR (red line at the bottom) 802.15.9 key exchange, per peer keying using group key. Large shared secret like 32 bytes. Are the= y mutually exclusive? - security pieces for the 6top model. What do we need to configure specifically? - the join controller provides the certificate. - the security for the DTLS connection needs to be able to identify the used certificate and its location. - the certificate will be used by p2p exchange. Also there can be a group key shared by all nodes. Action: *Michael* to publish a revision of the security draft with a clear text describing the needs in terms of data representation elements so the 6top data model can be updated. - With a PCE each node needs to have a secure relation with the PCE. - with P2P negotiation and minimal where IEs are exchanged, security is more complex as requires to secure this relation. - *Ariton* 15.4e includes several security fields that have a particular meaning. Would those fields have a different meaning when = used in the context of 6TiSCH? What would be the impact of using or not us= ing the MAC header. - *Thomas* the fields have the same meaning. What 6tisch defines is a key management protocol so certificates can be exchanged. This is a complement to the architecture and later the use of this security certificates is fully aligned with 15.4e std. Action: *Ariton* to send a mail to the ML asking clarification about whether IEEE802.15.4e fields have a different meaning when used in th= e context of 6TiSCH. - *[09.11]* RPL option status and update 6lo - Done at the previous minimal draft discussion. - RFC7322: RFC Style Guide - No time. Pushed to later call. - *[09.13]* Meeting ends - Next 6TiSCH call on 11/7, purpose is to go through material for IETF91 WG meeting. --047d7bf18b76c75a910506fea1d6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All,

You will find the minut= es of the last 6TiSCH interim call below (also at https://bitbucket.org/6tisch/meetings/ and https://www= .ietf.org/meeting/interim/proceedings.html).

R= eply with comments/suggestions. We will approve these minutes at the next 6= TiSCH interim call.

Thomas

---

Minutes Webex 24 October 2014, 6TiSCH WG

Note: timestamps i= n PDT.

Connection details

Resources

  • Webex recordi= ng:=C2=A0https://cisco.webex.com/ciscosales/lsr.php?RCID=3Db= 4029b074a00492fa1344929ac3cf8fd
  • = Wiki:=C2=A0h= ttps://bitbucket.org/6tisch/meetings/wiki/141024_webex
  • Slides:=C2=A0https://bitbucket.org= /6tisch/meetings/src/master/141024_webex/slides_141024_webex.ppt
  • Taking notes=C2=A0(usi= ng Etherpad)

    1. Pascal Thubert
    2. Xavi Vilajosana
    3. Thomas Watteyne

    Present=C2=A0(template)
    1. Ariton Xhafa
    2. Diego Dujovne
    3. Guillaume Gaillard
    4. Giuseppe Piro
    5. Ines R= obles
    6. Maria Rita Palattella
    7. Michael Richardson
    8. Nicola Accettura
    9. Pasca= l Thubert
    10. Pat Kinney
    11. Raghuram Sudhaakar
    12. Thomas Watteyne
    13. Xavi Vilajo= sana

    Action Items

    • Thoma= s=C2=A0to update draft-ietf-6tisch-tsch by cut-off date.
    • Pascal=C2=A0and=C2=A0Thomas=C2=A0to talk to Ted about whether to push for 6TiSCH-speci= fic CoAP draft, or wait for generic constrained management solution.
    • Xavi=C2=A0to cite draft-t= hubert-6lo-rpl-nhc-02 in next revision of draft-ietf-6tisch-minimalMichael=C2=A0to publish a = revision of the security draft with a clear text describing the needs in te= rms of data representation elements so the 6top data model can be updated.<= /li>
    • Michael=C2=A0to pub= lish a revision of the security draft with a clear text describing the need= s in terms of data representation elements so the 6top data model can be up= dated.

    Agenda

    • Administrivia=C2=A0= [2min]
      • Approval agenda
      • Approval minute= s last call
    • IETF91=C2=A0[5min]
      • meetecho remote presentation
      • = draft agenda
    • draft-ietf-6t= isch-tsch-02 publication=C2=A0[2min]
      • please review
    • wrapping up draft-ietf-6tisch-minimal=C2=A0[= 15min]
    • presentation draft-richa= rdson-6tisch--security-6top-02=C2=A0[15min]
      • RPL option status and update = 6lo=C2=A0[10min]
    • = RFC7322: RFC Style Guide=C2=A0[5min]
    • AOB=C2=A0[5min]

    Minut= es

    • [08.05]=C2=A0Meeting starts=C2=A0[Chairs]<= ul style=3D"margin:10px 0px 0px">
    • Pascal=C2=A0starts recording
    • Thomas=C2=A0presents agenda
      • update on IETF91 and draft agenda<= /li>
      • present 2 draft and its status/evolu= tion
      • Michael=C2=A0w= ill present security draft status
      • Pascal=C2=A0will present status of RPL option at 6lo
      • if time permits, RF7322 will be introduced.=
  • [08.08]=C2=A0Administrivia=C2=A0[Chairs]
    • Approval agenda

      No issues raise= d. Agenda approved.

    • Approval minutes last call
    • No issue= s raised. Minutes last call approved.
    • Thomas=C2=A0There was a security call on Tuesday. Went t= hrough draft-richardson-6tisch--security-6top-03. It will be presented toda= y.
  • [08.12]=C2=A0I= ETF91=C2=A0[Thomas]
    • IETF91 agenda is final. Meeting is 9am in Haw= aii, i.e. 8pm CET time same day.
    • Mee= techo available. Remote presentations and remote attendance.
    • Recording and minutes will reflect remote partici= pation.
    • Michael=C2= =A0Visa's from 104 attendees from China have not been approved yet.
    • Thomas=C2=A0First time= that every session is in meetecho.
    • = For remote presenters, there will be tests to make sure everything works we= ll.
    • This Monday is the cut-off date = for draft submission. Authors are called to submit their drafts before Mond= ay.
    • Monday is also cutoff for draft = agenda.
    • Initial agenda for 6TiSCH WG= meeting.
      • presen= t latest changes on drafts
      • TSCH draf= t, 6top interface draft, and minimal
      • introduction to plugtest at 93rd IETF meeting, with help of ETSI. Renamed = from plugfest to plugtest as it related to verification.
      • Rechartering discussion to define next steps (include = dynamic scheduling, etc.)
      • Security: = Michael will present a revision of his draft and then Ren=C3=A9 has remarks=

        = Action:=C2=A0Thomas=C2=A0to update draft-ietf-6tisch-tsch = by cut-off date.

      • Ma= ria Rita volunteers to present TSCH draft
      • Xavi volunteers to present minimal and 6top interface drafts, if nece= ssary
      • Both presenters will do it rem= otely.
  • [08.1= 9]=C2=A0draft-ietf-6tisch-tsch-02 publication=C2=A0[Thomas]
    • = version 02 published
    • follows the rew= ording proposed during the call
    • 3 is= sues still open:
      • http://tools.ietf.or= g/wg/6tisch/trac/ticket/25. Rewording proposal. Rene did not agree. The= re is a follow up at the ML.
      • an issu= e is opened to change mote to node as node is what we agreed.
      • Pascal=C2=A0what about term &quo= t;LLN nodes"?
      • Thomas=C2=A0suggests to use term "LLN node" in first occurrence a= nd follow with "node".
    • Pascal=C2=A0several draft are going to be sent to t= he IESG in November. The last call will be announced at IETF91 and then we = will have an evaluation/call for consensus for 2 weeks before submitting.
    • List of drafts considered: TSCH, Mini= mal, 6top-interface, CoAP. We need to decide what we do with them.
    • Thomas=C2=A0what about arch= itecture draft? What is the current status and what is the timeline for thi= s draft.
    • Thomas=C2= =A0Would there be a problem if we recharter without having finalized the ar= chitecture draft?
    • Pascal=C2=A0I do not see any specific problem.
    • Thomas=C2=A0what about the CoAP draft? what shou= ld we do? Wait for the COMAN activity with constrained RESTCOnf draft? or p= ush for our CoAP draft.
    • Pasc= al=C2=A0we have milestones with the IESG. We can delay the CoAP dr= aft after recharter to see what is the progress of the RESTConf, etc.
    • <= li style=3D"word-wrap:break-word">Raghuram=C2=A0Agrees to = wait.

      Action:=C2=A0Pascal=C2=A0and=C2=A0Thomas=C2=A0to talk to Ted about whether to push for 6TiSCH-specific CoAP dr= aft, or wait for generic constrained management solution.

      <= /li>
    • Michael=C2=A0asks i= f there is a date for the ETSI event.
    • Thomas=C2=A0there is no specific date but it might be a = couple of days before (or Monday) talking to IETF to see if this is possibl= e. Target is July 2015 in Prague right before IETF93 is the target.
    • Michael=C2=A0the Contiki p= eople planned to have a conference, hack fest right before. This might be a= conflict.
    • Thomas= =C2=A0the ETSI test event is not a long thing it is just a set of schedules= of tests and people attend to their specific tests.
    • Ariton=C2=A0Regarding the interop. Are th= ere going to be a set of scenarios?
    • = Thomas=C2=A0yes. The plan is to develop the test scenarios= and come out with a set of tests (end March)
    • Ariton=C2=A0there will not be certification on t= hat event.
    • Thomas= =C2=A0not sure. We need to check with ETSI.
    • The point is to make standard better. the outcome is to validate to= our documents are correct and we are "optimal" in their design.<= /li>
  • [08.xx]=C2=A0wrap= ping up draft-ietf-6tisch-minimal=C2=A0[Xavi]
    • change in the CCA o= ption. Reflected in the drawing at the beginning of TX slot, timing before = CCA. This is a clarification to follow exactly the standard
    • added the missing timing
    • open questions, need opinion
      • HbH header compression. Agreed last time to go = to 6lo. Should not limit further extensions even at cost of additional byte= ?
      • what should minimal specify for se= curity?
      • asking implementors if IE we= are sending are enough?
    • <= strong>Pascal: published draft-thubert-6lo-rpl-nhc-02
    • offers 3 possibilities:
        =
      • (greedy) the one from NHC: consume 1/4 o= f NHC space (64 possibilities used)
      • = (conservative) don't change layout at all, enumeration in 6LoWPAN NHC a= lready, consume new header (but then need full byte after it) (1 possibilit= ies used, but extra byte)
      • (middle) i= dea from Carsten: limit the same to something the same as greedy, but add a= byte when "error". Consumes 4 bits (~20 possibilities used, 1 ex= tra byte when error)
    • Thomas=C2=A0what is an "error"?
    • Pascal=C2=A0forwarding error (O,F bits)<= /li>
    • Pascal=C2=A0problem= is that you might need to change packet length during forwarding
    • Thomas=C2=A0agreed that this= is the draft to cite in minimal?

      Action:=C2=A0Xavi=C2=A0t= o cite draft-thubert-6lo-rpl-nhc-02 in next revision of draft-ietf-6tisch-m= inimal.

    • [Xa= vi]=C2=A0what should draft-ietf-6tisch-minimal contain in terms of= security?
    • Pascal= =C2=A0I do not see the need to say anything, RPL has its own security, any = security that applies to other protocols apply to minimal.
    • Michael=C2=A0similarly, there must = be L2 security, which we just inherit.
  • [08.57]=C2=A0presentation draft-richardson-6tisch--se= curity-6top-02=C2=A0[Michael]
    • Missing text for security pieces in= 6top
      • join contr= oller provides a certificate for the node (500 bytes), node may issue a cer= t request.
      • OR (red line at the botto= m) 802.15.9 key exchange, per peer keying using group key. Large shared sec= ret like 32 bytes. Are they mutually exclusive?
    • security pieces for the 6top model. What do we need t= o configure specifically?
    • the join c= ontroller provides the certificate.
    • = the security for the DTLS connection needs to be able to identify the used = certificate and its location.
    • the ce= rtificate will be used by p2p exchange. Also there can be a group key share= d by all nodes.

      Action:=C2=A0Michael=C2=A0to publish a revi= sion of the security draft with a clear text describing the needs in terms = of data representation elements so the 6top data model can be updated.

      <= /blockquote>
    • With a PCE each node ne= eds to have a secure relation with the PCE.
    • with P2P negotiation and minimal where IEs are exchanged, security = is more complex as requires to secure this relation.
    • Ariton=C2=A015.4e includes several securi= ty fields that have a particular meaning. Would those fields have a differe= nt meaning when used in the context of 6TiSCH? What would be the impact of = using or not using the MAC header.
    • <= strong>Thomas=C2=A0the fields have the same meaning. What 6tisch d= efines is a key management protocol so certificates can be exchanged. This = is a complement to the architecture and later the use of this security cert= ificates is fully aligned with 15.4e std.

      Action:=C2=A0Ariton=C2=A0to send a mail to the ML asking clarification about whether IEEE80= 2.15.4e fields have a different meaning when used in the context of 6TiSCH.=

  • [09.= 11]=C2=A0RPL option status and update 6lo
    • Done at the previous minimal draft = discussion.
  • RFC7322: RFC S= tyle Guide
    • No ti= me. Pushed to later call.
  • = [09.13]=C2=A0Meeting ends
    • Next 6TiSCH call on 11/7, purpose is to go thro= ugh material for IETF91 WG meeting.
--047d7bf18b76c75a910506fea1d6-- From nobody Mon Nov 3 18:10:16 2014 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE7181A1B8A; Mon, 3 Nov 2014 18:10:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_28=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nw2NXXhURyqb; Mon, 3 Nov 2014 18:09:59 -0800 (PST) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 741E61A1B84; Mon, 3 Nov 2014 18:09:59 -0800 (PST) Received: by mail-ie0-f175.google.com with SMTP id y20so6698751ier.34 for ; Mon, 03 Nov 2014 18:09:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=7ej15vUEG12PHLr08IPFRnZdFQFXW+aWNqTn6pZSMak=; b=WFX09iRpahhoROu3hX0vkVSiCEE55T/dqBvHsjuUIocsNMITS7hYzlkhiDfr4SnuJD yiUkRYvP7RK2GWqHBaLwe48WXJSSw8OS3rydJU4xvSFW3byBcKWGz/rmv3KV1VVdMZ70 9XDsup/CO0ud0JXn2pWIhbDVIyPUp7cnwWY00V0bE0XXRzWQwz9fSyA2iC3ZF+FwPiJY 66MfHmW1rXF9gs7gUEMmwpVeiiu2W7MTz4uHVDbjQG3BxvVm1hUXAqFjIrlncaPEAW6x fSw5Jz1CDlBy1PVA3wCh7ZDYRd+Rr82VvqFQMm77qE62rlIFucdLQsczKzlfeuxs2PHn NBEg== X-Received: by 10.42.230.15 with SMTP id jk15mr10978298icb.55.1415066998855; Mon, 03 Nov 2014 18:09:58 -0800 (PST) Received: from [192.168.0.10] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. [99.231.49.38]) by mx.google.com with ESMTPSA id nu1sm4326747igb.0.2014.11.03.18.09.57 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Nov 2014 18:09:58 -0800 (PST) Message-ID: <54583572.6020502@gmail.com> Date: Mon, 03 Nov 2014 21:09:54 -0500 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Jonathan Simon , "Pascal Thubert (pthubert)" References: <3C90505D-AF81-493B-A29A-86F2A1A5A207@linear.com> <5453B837.5040305@gmail.com> In-Reply-To: <5453B837.5040305@gmail.com> Content-Type: multipart/alternative; boundary="------------040700030201080200050008" Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch/mZ03nH0k9-g7b2Ix7jOLfhvVbZE Cc: "6tisch@ietf.org" <6tisch@ietf.org>, "6tisch-security@ietf.org" <6tisch-security@ietf.org> Subject: Re: [6tisch] [6tisch-security] X.509 Cert sizes and joining flows X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 02:10:04 -0000 This is a multi-part message in MIME format. --------------040700030201080200050008 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Jonathan: Do you have some ballpark numbers for the size of configuration info to play around with? Please see below (my Que to you of Fri Oct 31, 2014). Best regards, Rene On 10/31/2014 12:26 PM, Rene Struik wrote: > Hi Jonathan: > > The join protocol includes (1) authentication; (2) authorization; (3) > configuration steps. > Without hands tied behind the back with protocol design, I anticipate > the main communication overhead of the join protocol to be with the > configuration step (#3) and *not* with the underlying authenticated > key agreement scheme (#1). Here, configuration relates both to > security manager to joining node info and vice-verse. > > See also item #a of my May 20, 2014 email -- _which is still > outstanding BTW._ > Que - Would you like to take this one on? {as first step, what about > providing a rough number, say, 1500 bytes [fill in correct number here]}. > > Some brief feedback on certificate sizes: > a) certificates should definitely have policy fields, including key > validity period. > b) certificate compression is of course possible, including that of > certificate issuer (whether the latter would be prudent remains to be > seen). > c) some of your figures are too pessimistic, e.g., P-256 keys are 65 > bytes in uncompressed format; ECDSA signatures are 64-bytes. EUI-64 > could be used as SubjectPublicKey field, but depends on naming issues > (see item #b of my May 20, 2014 message). > d) there is no absolute need to use X509 certs, which would add > considerable freedom to cut down overhead. > > I estimate one can implement the authentication scheme (#1) with one > or two 802.15.4e frames in each protocol flow (assuming cert chains of > length one). > > Email of May 20, 2014 with outstanding issues: > http://www.ietf.org/mail-archive/web/6tisch-security/current/msg00086.html > a) Packet sizes: > get more info on packet sizes configuration parms, as w/HART uses. > Note RS: during call, Tom Phinney suggested contacting Wally Bratt > from HART Comm. Foundation for this). Note RS: Shouldn't, e.g., Dust > Networks have info on packet sizes/structure?; ISA SP100.11a metrics > would also help, as would ZigBee 2.0 config parms. Does, e.g., Cisco > have useful data points here? > b) Device Ids: > With industrial control, network manager would look up "tag name" > device in pre-configured database. Details on tag name syntax, how > assigned, and how bound to, e.g., EUI-64 are missing. Note RS: > Perhaps, Tom Phinney could point at tag name syntax and lifecycle > aspects here? > > On 10/31/2014 11:48 AM, Jonathan Simon wrote: >> Pascal - >> >> Yes - I donít know where the effort belongs though. I think we need >> a standard way of compressing an X.509 cert with the goal of fitting >> it in under 200 bytes. Maybe this compressed cert is only used at >> joining in 6TiSCH, or maybe border routers can compress/decompress >> along with the 6LoWPAN header so we can use it end-to-end. >> >> ó >> >> Jonathan >> >> On Oct 31, 2014, at 3:17 AM, Pascal Thubert (pthubert) >> > wrote: >> >>> Hello Jonathan: >>> Are you suggesting that we define a ď6LoWPAN compressionĒ for a >>> certificate? >>> Cheers, >>> Pascal >>> *From:*6tisch-security [mailto:6tisch-security-bounces@ietf.org]*On >>> Behalf Of*Jonathan Simon >>> *Sent:*vendredi 31 octobre 2014 00:31 >>> *To:*6tisch-security@ietf.org >>> *Subject:*[6tisch-security] X.509 Cert sizes and joining flows >>> I voiced my concern a while back about certificate exchanges making >>> joining really slow: >>> http://www.ietf.org/mail-archive/web/6tisch-security/current/msg00023.html >>> >>> There I assumed a 300-byte compressed cert. Obviously, a 1500-byte >>> cert is going to be 5x worse. >>> One reason the certs are big is that there is a lot of stuff we >>> don't need, or may not need, or could compress a la 6lo. >>> Version: could be elided? >>> Serial number: Maybe this is the EUI of the device (elidable). >>> Signature: ~80 bytes for secp256r1 (128-bits protection). Needs to >>> cover the full expanded X.509 fields. >>> Issuer: may be compressible? >>> Validity: 26 bytes - do we need to be able to revoke certs, or could >>> this be handled on an app level. >>> Subject: can be empty >>> SubjectPublicKeyInfo: contains an algorithm definition (which can be >>> elided if we only use one) or compressed (if we support a few), and >>> the public key (32 bytes) >>> IssuerUniqueIdentifier: optional >>> SubjectUniqueIdentifier: optional >>> Extensions: optional, but if we don't include a subject we might >>> want to support subjectAltName, again probably in compressed form. >>> SignatureAlgorithm: can be elided if we only use one or compressed >>> if we support a few >>> Other fields? >>> Point is, I think we can get this to fit into 2 packets and I think >>> that should be our target unless thereís a really a compelling >>> reason to include fields. >>> -- >>> Jonathan Simon >> >> >> >> This body part will be downloaded on demand. > > > -- > email:rstruik.ext@gmail.com | Skype: rstruik > cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 --------------040700030201080200050008 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Hi Jonathan:

Do you have some ballpark numbers for the size of configuration info to play around with? Please see below (my Que to you of Fri Oct 31, 2014).

Best regards, Rene

On 10/31/2014 12:26 PM, Rene Struik wrote:
Hi Jonathan:

The join protocol includes (1) authentication; (2) authorization; (3) configuration steps.
Without hands tied behind the back with protocol design, I anticipate the main communication overhead of the join protocol to be with the configuration step (#3) and *not* with the underlying authenticated key agreement scheme (#1). Here, configuration relates both to security manager to joining node info and vice-verse.

See also item #a of my May 20, 2014 email -- which is still outstanding BTW.
Que - Would you like to take this one on? {as first step, what about providing a rough number, say, 1500 bytes [fill in correct number here]}.

Some brief feedback on certificate sizes:
a) certificates should definitely have policy fields, including key validity period.
b) certificate compression is of course possible, including that of certificate issuer (whether the latter would be prudent remains to be seen).
c) some of your figures are too pessimistic, e.g., P-256 keys are 65 bytes in uncompressed format; ECDSA signatures are 64-bytes. EUI-64 could be used as SubjectPublicKey field, but depends on naming issues (see item #b of my May 20, 2014 message).
d) there is no absolute need to use X509 certs, which would add considerable freedom to cut down overhead.

I estimate one can implement the authentication scheme (#1) with one or two 802.15.4e frames in each protocol flow (assuming cert chains of length one).

Email of May 20, 2014 with outstanding issues:
http://www.ietf.org/mail-archive/web/6tisch-security/current/msg00086.html
a) Packet sizes:
get more info on packet sizes configuration parms, as w/HART uses. Note RS: during call, Tom Phinney suggested contacting Wally Bratt from HART Comm. Foundation for this).† Note RS: Shouldn't, e.g., Dust Networks have info on packet sizes/structure?; ISA SP100.11a metrics would also help, as would ZigBee 2.0 config parms. Does, e.g., Cisco have useful data points here?
b) Device Ids:
With industrial control, network manager would look up "tag name" device in pre-configured database. Details on tag name syntax, how assigned, and how bound to, e.g., EUI-64 are missing. Note RS: Perhaps, Tom Phinney could point at tag name syntax and lifecycle aspects here?

On 10/31/2014 11:48 AM, Jonathan Simon wrote:
Pascal -

Yes - I donít know where the effort belongs though. †I think we need a standard way of compressing an X.509 cert with the goal of fitting it in under 200 bytes. Maybe this compressed cert is only used at joining in 6TiSCH, or maybe border routers can compress/decompress along with the 6LoWPAN header so we can use it end-to-end.

ó†

Jonathan†

On Oct 31, 2014, at 3:17 AM, Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:

Hello Jonathan:
Are you suggesting that we define a ď6LoWPAN compressionĒ for a certificate?
Cheers,
Pascal
From:6tisch-security [mailto:6tisch-security-bounces@ietf.org]On Behalf OfJonathan Simon
Sent:vendredi 31 octobre 2014 00:31
To:6tisch-security@ietf.org
Subject:[6tisch-security] X.509 Cert sizes and joining flows
I voiced my concern a while back about certificate exchanges making joining really slow:
There I assumed a 300-byte compressed cert. Obviously, a 1500-byte cert is going to be 5x worse.
One reason the certs are big is that there is a lot of stuff we don't need, or may not need, or could compress a la 6lo.
Version: could be elided?
Serial number: Maybe this is the EUI of the device (elidable).
Signature: †~80 bytes for secp256r1 (128-bits protection). †Needs to cover the full expanded X.509 fields.
Issuer: may be compressible?
Validity: 26 bytes - do we need to be able to revoke certs, or could this be handled on an app level.
Subject: can be empty
SubjectPublicKeyInfo: contains an algorithm definition (which can be elided if we only use one) or compressed (if we support a few), and the public key (32 bytes)
IssuerUniqueIdentifier: optional
SubjectUniqueIdentifier: optional
Extensions: optional, but if we don't include a subject we might want to support†subjectAltName, again probably in compressed form.
SignatureAlgorithm:†can be elided if we only use one or compressed if we support a few
Other fields?
Point is, I think we can get this to fit into 2 packets and I think that should be our target unless thereís a really a compelling reason to include fields.
--†
Jonathan Simon



This body part will be downloaded on demand.


-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363


-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
--------------040700030201080200050008-- From nobody Mon Nov 3 20:27:17 2014 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6222F1A6EF9; Mon, 3 Nov 2014 20:27:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SF8H98hP3afk; Mon, 3 Nov 2014 20:27:10 -0800 (PST) Received: from p01c11o147.mxlogic.net (p01c11o147.mxlogic.net [208.65.144.70]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4752C1A1C03; Mon, 3 Nov 2014 20:27:09 -0800 (PST) Received: from unknown [12.218.215.72] (EHLO smtpauth1.linear.com) by p01c11o147.mxlogic.net(mxl_mta-8.2.0-0) with ESMTP id c9558545.0.87062.00-345.214316.p01c11o147.mxlogic.net (envelope-from ); Mon, 03 Nov 2014 21:27:09 -0700 (MST) X-MXL-Hash: 5458559d4ac8df2f-2bd25e51f53ffd51bf7ad1763bfa6e67b47ad9f0 Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) by smtpauth1.linear.com (Postfix) with ESMTPSA id 5B95C741EB; Mon, 3 Nov 2014 20:27:08 -0800 (PST) Received: by mail-ie0-f179.google.com with SMTP id rl12so6574734iec.24 for ; Mon, 03 Nov 2014 20:27:07 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.107.40.141 with SMTP id o135mr12267478ioo.26.1415075227895; Mon, 03 Nov 2014 20:27:07 -0800 (PST) Received: by 10.107.15.151 with HTTP; Mon, 3 Nov 2014 20:27:07 -0800 (PST) In-Reply-To: <54583572.6020502@gmail.com> References: <3C90505D-AF81-493B-A29A-86F2A1A5A207@linear.com> <5453B837.5040305@gmail.com> <54583572.6020502@gmail.com> Date: Mon, 3 Nov 2014 20:27:07 -0800 Message-ID: From: Jonathan Simon To: Rene Struik Content-Type: multipart/alternative; boundary=001a1141f0104a105f050700e0c8 X-AnalysisOut: [v=2.1 cv=U/WGDIbu c=1 sm=1 tr=0 a=glloKNylpeYNumXQcclYyA==] X-AnalysisOut: [:117 a=glloKNylpeYNumXQcclYyA==:17 a=BLceEmwcHowA:10 a=MqD] X-AnalysisOut: [INYqSAAAA:8 a=pGLkceISAAAA:8 a=YlVTAMxIAAAA:8 a=1XWaLZrsAA] X-AnalysisOut: [AA:8 a=48vgC7mUAAAA:8 a=SyYMxH9GAAAA:8 a=AUd_NHdVAAAA:8 a=] X-AnalysisOut: [xNjghb5tWkwzJ54BojIA:9 a=LuZtJmNiMv6PlYp_:21 a=PepowG6E4-t] X-AnalysisOut: [p0P4j:21 a=QEXdDO2ut3YA:10 a=wUAfXdCGL-oA:10 a=G1HyQLfxkfk] X-AnalysisOut: [A:10 a=19wCD08tTksA:10 a=vsVyj9psLt0A:10 a=yRLhjdVT-pYA:10] X-AnalysisOut: [ a=uztyEWA5df8A:10 a=qVizmW-ZYBIA:10 a=p-HxVa_ds0YA:10 a=A] X-AnalysisOut: [eFSex2-gKoA:10 a=QxAq9r8ObNgA:10 a=B6niZy2Ubl4A:10 a=nJULN] X-AnalysisOut: [bPdoQ66ZcHodqAA:9 a=FP_DtNxTU6GU4ckT:21 a=E9H_5z5ZNP6pEb0u] X-AnalysisOut: [:21 a=zXgT6hFItCxjYJJd:21] X-Spam: [F=0.6941747573; CM=0.500; MH=0.694(2014110326); S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [12.218.215.72] Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch/lBJ7t8nFs55wIxC1JWCFaGYYsbw Cc: "Pascal Thubert \(pthubert\)" , Jonathan Simon , "6tisch@ietf.org" <6tisch@ietf.org>, "6tisch-security@ietf.org" <6tisch-security@ietf.org> Subject: Re: [6tisch] [6tisch-security] X.509 Cert sizes and joining flows X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: jsimon@linear.com List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 04:27:14 -0000 --001a1141f0104a105f050700e0c8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable For minimal, there's a link key and a DTLS session to establish. Maybe something else I'm missing. In a typical WirelessHART network, there are multiple end-to-end CCM* security sessions, run-time slotframes and links, mesh-under routing information, set one or more timing parents, a bunch of timers (e.g. for statistics collection) - somewhere ~ 5-600 bytes, but it isn't necessarily as compact as CoAP could be. Jonathan On Mon, Nov 3, 2014 at 6:09 PM, Rene Struik wrote: > Hi Jonathan: > > Do you have some ballpark numbers for the size of configuration info to > play around with? Please see below (my Que to you of Fri Oct 31, 2014). > > Best regards, Rene > > On 10/31/2014 12:26 PM, Rene Struik wrote: > > Hi Jonathan: > > The join protocol includes (1) authentication; (2) authorization; (3) > configuration steps. > Without hands tied behind the back with protocol design, I anticipate the > main communication overhead of the join protocol to be with the > configuration step (#3) and *not* with the underlying authenticated key > agreement scheme (#1). Here, configuration relates both to security manag= er > to joining node info and vice-verse. > > See also item #a of my May 20, 2014 email -- *which is still outstanding > BTW.* > Que - Would you like to take this one on? {as first step, what about > providing a rough number, say, 1500 bytes [fill in correct number here]}. > > Some brief feedback on certificate sizes: > a) certificates should definitely have policy fields, including key > validity period. > b) certificate compression is of course possible, including that of > certificate issuer (whether the latter would be prudent remains to be see= n). > c) some of your figures are too pessimistic, e.g., P-256 keys are 65 byte= s > in uncompressed format; ECDSA signatures are 64-bytes. EUI-64 could be us= ed > as SubjectPublicKey field, but depends on naming issues (see item #b of m= y > May 20, 2014 message). > d) there is no absolute need to use X509 certs, which would add > considerable freedom to cut down overhead. > > I estimate one can implement the authentication scheme (#1) with one or > two 802.15.4e frames in each protocol flow (assuming cert chains of lengt= h > one). > > Email of May 20, 2014 with outstanding issues: > http://www.ietf.org/mail-archive/web/6tisch-security/current/msg00086.htm= l > > a) Packet sizes: > get more info on packet sizes configuration parms, as w/HART uses. Note > RS: during call, Tom Phinney suggested contacting Wally Bratt from HART > Comm. Foundation for this). Note RS: Shouldn't, e.g., Dust Networks have > info on packet sizes/structure?; ISA SP100.11a metrics would also help, a= s > would ZigBee 2.0 config parms. Does, e.g., Cisco have useful data points > here? > b) Device Ids: > With industrial control, network manager would look up "tag name" device > in pre-configured database. Details on tag name syntax, how assigned, and > how bound to, e.g., EUI-64 are missing. Note RS: Perhaps, Tom Phinney cou= ld > point at tag name syntax and lifecycle aspects here? > > On 10/31/2014 11:48 AM, Jonathan Simon wrote: > > Pascal - > > Yes - I don=E2=80=99t know where the effort belongs though. I think we = need a > standard way of compressing an X.509 cert with the goal of fitting it in > under 200 bytes. Maybe this compressed cert is only used at joining in > 6TiSCH, or maybe border routers can compress/decompress along with the > 6LoWPAN header so we can use it end-to-end. > > =E2=80=94 > > Jonathan > > On Oct 31, 2014, at 3:17 AM, Pascal Thubert (pthubert) < > pthubert@cisco.com> wrote: > > Hello Jonathan: > > Are you suggesting that we define a =E2=80=9C6LoWPAN compression=E2=80=9D= for a > certificate? > > Cheers, > > Pascal > > *From:* 6tisch-security [mailto:6tisch-security-bounces@ietf.org > <6tisch-security-bounces@ietf.org>] *On Behalf Of *Jonathan Simon > *Sent:* vendredi 31 octobre 2014 00:31 > *To:* 6tisch-security@ietf.org > *Subject:* [6tisch-security] X.509 Cert sizes and joining flows > > I voiced my concern a while back about certificate exchanges making > joining really slow: > > > http://www.ietf.org/mail-archive/web/6tisch-security/current/msg00023.htm= l > > > There I assumed a 300-byte compressed cert. Obviously, a 1500-byte cert > is going to be 5x worse. > > One reason the certs are big is that there is a lot of stuff we don't > need, or may not need, or could compress a la 6lo. > > Version: could be elided? > Serial number: Maybe this is the EUI of the device (elidable). > Signature: ~80 bytes for secp256r1 (128-bits protection). Needs to > cover the full expanded X.509 fields. > Issuer: may be compressible? > Validity: 26 bytes - do we need to be able to revoke certs, or could > this be handled on an app level. > Subject: can be empty > SubjectPublicKeyInfo: contains an algorithm definition (which can be > elided if we only use one) or compressed (if we support a few), and the > public key (32 bytes) > IssuerUniqueIdentifier: optional > SubjectUniqueIdentifier: optional > Extensions: optional, but if we don't include a subject we might want to > support subjectAltName, again probably in compressed form. > SignatureAlgorithm: can be elided if we only use one or compressed if we > support a few > Other fields? > > Point is, I think we can get this to fit into 2 packets and I think that > should be our target unless there=E2=80=99s a really a compelling reason = to include > fields. > > -- > Jonathan Simon > > > > > This body part will be downloaded on demand. > > > > -- > email: rstruik.ext@gmail.com | Skype: rstruik > cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 > > > > -- > email: rstruik.ext@gmail.com | Skype: rstruik > cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 > > --=20 Jonathan Simon, Ph. D Director of Systems Engineering Linear Technology, Dust Networks product group 32990 Alvarado-Niles Road, Suite 910 Union City, CA 94587 (510) 400-2936 (510) 489-3799 FAX jsimon@linear.com **LINEAR TECHNOLOGY CORPORATION** *****Internet Email Confidentiality Notice***** This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify me by reply e-mail, or by telephone at (510) 400-2936, and destroy the original transmission and its attachments without reading or saving in any manner. Thank you. --001a1141f0104a105f050700e0c8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
For minimal, there's a link key and a DTLS sessio= n to establish. Maybe something else I'm missing.

In a typ= ical WirelessHART network, there are multiple end-to-end CCM* security sess= ions,=C2=A0 run-time slotframes and links, mesh-under routing information, = set one or more timing parents, a bunch of timers (e.g. for statistics coll= ection)=C2=A0 -=C2=A0 somewhere ~ 5-600 bytes, but it isn't necessarily= as compact as CoAP could be.

Jonathan

On Mon, Nov 3, 2014 at 6:09 PM, Rene = Struik <rstruik.ext@gmail.com> wrote:
=20 =20 =20
Hi Jonathan:

Do you have some ballpark numbers for the size of configuration info to play around with? Please see below (my Que to you of Fri Oct 31, 2014).

Best regards, Rene

On 10/31/2014 12:26 PM, Rene Struik wrote:
=20
Hi Jonathan:

The join protocol includes (1) authentication; (2) authorization; (3) configuration steps.
Without hands tied behind the back with protocol design, I anticipate the main communication overhead of the join protocol to be with the configuration step (#3) and *not* with the underlying authenticated key agreement scheme (#1). Here, configuration relates both to security manager to joining node info and vice-verse.

See also item #a of my May 20, 2014 email -- which is still outstanding BTW.
Que - Would you like to take this one on? {as first step, what about providing a rough number, say, 1500 bytes [fill in correct number here]}.

Some brief feedback on certificate sizes:
a) certificates should definitely have policy fields, including key validity period.
b) certificate compression is of course possible, including that of certificate issuer (whether the latter would be prudent remains to be seen).
c) some of your figures are too pessimistic, e.g., P-256 keys are 65 bytes in uncompressed format; ECDSA signatures are 64-bytes. EUI-64 could be used as SubjectPublicKey field, but depends on naming issues (see item #b of my May 20, 2014 message).
d) there is no absolute need to use X509 certs, which would add considerable freedom to cut down overhead.

I estimate one can implement the authentication scheme (#1) with one or two 802.15.4e frames in each protocol flow (assuming cert chains of length one).

Email of May 20, 2014 with outstanding issues:
http://w= ww.ietf.org/mail-archive/web/6tisch-security/current/msg00086.html
a) Packet sizes:=C2=A0
get more info on packet sizes configuration parms, as w/HART uses. Note RS: during call, Tom Phinney suggested contacting Wally Bratt from HART Comm. Foundation for this).=C2=A0 Note RS: Shouldn't, e.g., D= ust Networks have info on packet sizes/structure?; ISA SP100.11a metrics would also help, as would ZigBee 2.0 config parms. Does, e.g., Cisco have useful data points here?
b) Device Ids:
With industrial control, network manager would look up "tag name" devic= e in pre-configured database. Details on tag name syntax, how assigned, and how bound to, e.g., EUI-64 are missing. Note RS: Perhaps, Tom Phinney could point at tag name syntax and lifecycle aspects here?

On 10/31/2014 11:48 AM, Jonathan Simon wrote:
=20 Pascal -

Yes - I don=E2=80=99t know where the effort belongs though.=C2= =A0 I think we need a standard way of compressing an X.509 cert with the goal of fitting it in under 200 bytes. Maybe this compressed cert is only used at joining in 6TiSCH, or maybe border routers can compress/decompress along with the 6LoWPAN header so we can use it end-to-end.

=E2=80=94=C2=A0=

Jonathan=C2=A0

On Oct 31, 2014, at 3:17 AM, Pascal Thubert (pthubert) <p= thubert@cisco.com> wrote:

Hello Jonathan:
=C2=A0
Are you suggesting that we define a =E2=80=9C6LoWPAN compress= ion=E2=80=9D for a certificate?
=C2=A0
Cheers,
=C2=A0
Pascal
=C2=A0
From:=C2=A06tisch-security [ma= ilto:6tisch-security-bounces@ietf.org]=C2=A0On Behalf Of=C2=A0Jonathan Simon
Sent:=C2=A0vendredi 31 octobre 2014 00:31
To:=C2=A06tisch-security@ietf.org
Subject:=C2=A0[6tisch-secur= ity] X.509 Cert sizes and joining flows
=C2=A0
I voiced my concern a while back about certificate exchanges making joining really slow:
=C2=A0
=C2=A0
There I assumed a 300-byte compressed cert. Obviously, a 1500-byte cert is going to be 5x worse.
=C2=A0
One reason the certs are big is that there is a lot of stuff we don't need, or may not need, or could compress a la 6lo.
=C2=A0
Version: could be elided?
Serial number: Maybe this is the EUI of the device (elidable).<= /u>
Signature: =C2=A0~80 bytes for secp256r1 (128-bits protection). =C2=A0Needs to cover the full expanded X.509 fields.
Issuer: may be compressible?
Validity: 26 bytes - do we need to be able to revoke certs, or could this be handled on an app level.=
Subject: can be empty
SubjectPublicKeyInfo: contains an algorithm definition (which can be elided if we only use one) or compressed (if we support a few), and the public key (32 bytes)
IssuerUniqueIdentifier: optional
SubjectUniqueIdentifier: optional
Extensions: optional, but if we don't include a subject we might want to support=C2=A0subjectAltName, again probably i= n compressed form.
SignatureAlgorithm:=C2=A0can be elided if we only use one or compressed if we support a few
Other fields?
=C2=A0
Point is, I think we can get this to fit into 2 packets and I think that should be our target unless there=E2=80=99s a really a compelling reason = to include fields.
=C2=A0
--=C2=A0
Jonathan Simon



This body part will be downloaded on demand.


--=20
email: rstruik.e=
xt@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363=


--=20
email: rstruik.e=
xt@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363=



--
--001a1141f0104a105f050700e0c8-- From nobody Tue Nov 4 09:16:35 2014 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8CD71A9149; Tue, 4 Nov 2014 09:16:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.276 X-Spam-Level: X-Spam-Status: No, score=-1.276 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LRgXrQ3oNbNJ; Tue, 4 Nov 2014 09:16:31 -0800 (PST) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41A801A90DF; Tue, 4 Nov 2014 09:16:31 -0800 (PST) Received: by mail-pd0-f171.google.com with SMTP id r10so14054313pdi.30 for ; Tue, 04 Nov 2014 09:16:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=G2rQyfOC9IP8fi+L6hWLate4i7MHvtlPrE2M6s8k4b0=; b=u5IQbZHKy2L0HkwFb3CAKgPi3KSBRWPikaHSIDsrszO7l7A6kF/njtqKYSjkFB/WgG A7779T4MjCGLSanbtNgw4HWOQXNhNT6RMUwJcIDBBXqCLUDAvN0GySidL3gYD/0pyQOi qr47kL1YMQsSJnTXD7hPPMcQiLvfn2Ao5MvuzGKAphv45PCkTK20GXcu9bgQxMhHu8fO MHoGWtXM5fJWbZ90ea5pguCZZrTXIJFL3bYJ7/3astaZhoaaHIxKchsefeLELN9cT9tx S4omjNQIpotoqKDXIimYgr+XLtAH67C/rmNuPP0FObGNYHRq6+uxV26EW3dD5ib2zihw Pysw== X-Received: by 10.70.45.40 with SMTP id j8mr11591897pdm.130.1415121390357; Tue, 04 Nov 2014 09:16:30 -0800 (PST) MIME-Version: 1.0 Sender: twatteyne@gmail.com Received: by 10.66.88.42 with HTTP; Tue, 4 Nov 2014 09:16:10 -0800 (PST) In-Reply-To: <7180.1415115028@sandelman.ca> References: <7180.1415115028@sandelman.ca> From: Thomas Watteyne Date: Tue, 4 Nov 2014 09:16:10 -0800 X-Google-Sender-Auth: Vh5aEJJxu9mBSvhT6utJsJheqwk Message-ID: To: "6tisch@ietf.org" <6tisch@ietf.org>, tisch-security <6tisch-security@ietf.org> Content-Type: multipart/alternative; boundary=047d7bf18b76c9549005070b9f83 Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch/r6xhQvuNU4m_uFZ8AnIi1c8o-GU Subject: Re: [6tisch] [6tisch-security] minutes from call 2014-10-28 X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 17:16:34 -0000 --047d7bf18b76c9549005070b9f83 Content-Type: text/plain; charset=UTF-8 [adding the 6TiSCH ML] On Tue, Nov 4, 2014 at 7:30 AM, Michael Richardson wrote: > > My appologies for taking so long to get these out. > The call this week is in 30 minutes at: > > Meeting number: 645 146 419 Meeting password: timeslot Audio > > connection: 1-877-668-4493 Call-in toll free number (US/Canada) > > 1-650-479-3208 Call-in toll number (US/Canada) > > > > https://ietf.webex.com/ietf/j.php?MTID=m026b87ec5a630ca1ec44f2e79329ba02 > > > etherpad for meeting: > > http://etherpad.tools.ietf.org:9000/p/6tisch-security-6top-xml.txt > > > please note that google/browser-using-google-data might complain > about it > > being a phising site, it is likely a false positive, and I've let > > ietf-action know about it. > > > 2014-10-28 call started 11am EST. > > Attending > - Thomas Watteyne > - Michael Richardson > - Jonathan Simon > - Kris Pister > - Mike Seewald > - Nancy Cam-Winget > > We started the meeting by attempting to recap the discussion in the Mailing > List. Michael asks Kris to do the recap. The thread starts at: > > http://www.ietf.org/mail-archive/web/6tisch-security/current/msg00212.html > > The result of the discussion is that we have some terminology problems with > the use of "join key" --- we agreed that we would use the following terms: > > join network - A 802.15.4e network whose well known global > encryption and authentication key is "JOIN6TISCH". > unique join key - a symmetric key shared between a newly joining node, > and > the JCE. This key supports smaller installations for > which > asymmetric methods are considered too large > well known beacon key - this is the key "JOIN6TISCH" > > MR discussed that while the unique join key might in some situations not be > unique (we can not prevent use of pin "0000" a la Bluetooth headsets), we > should never make a protocol that depends upon the key being known by more > than one node. > > We then had a discussion about the term "trust anchors". > MCR said that the use of this term will cause some security people to > assume > that this is related to the set of trust anchors present in web browsers; > that some interaction with the Verisign/Komodo/etc. is intended, when it > really is about connection to some industry consortia, or perhaps only to > the > vendor's CA. > > We covered the problem of the node knowing if it is joining the right > network, that "this is the JCE you are looking for" (Star Wars droids > reference). The oil refinery situation was raised; where competitors have > equipment within radio distance of each other, and often sell/lease it > among > themselves. > > MR: suggestion: certificate given by JCE to node, contains authorization > with > "I am your owner". there is a set of delegation in supply chain. node > can > authenticatie that. node need to go to its vendor > > KP: so go out to the Internet and contact the vendor? > MR: don't suggest node or JCE do this online. Michael Belinger raised > fraud and > reselling. issue is that, when you purchase a node, you have to > install. vendor could veto a resell market if was involved online. > example > with lightbulbs > > MR: opinion is that the way you get that certificate is out of scope. Here > is > your MAC id and certificate of who owns you > > We had a discussion about possible ways that this introduces a > vendor-lockin > DRM, and the negative press that might result. This is the reason for the > 802.1AR installation of a LDevID after the join process, as this > permits/supports resell and further econonic activity without permission of > the vendor. > > We agreed that there would never be a requirement to go out to the > Internet. > > MCR explained purpose of draft-richardson-6tisch-idevid-cert... tried to > explain relative to SIDR, but SIDR work was not known. > > We discussed why we have a well-known-beacon key at all: mixing traffic > from > other sources users of that spectrum, and also concern that some MACs may > be > unable to deal with unencrypted and encrypted traffic being received at the > same time. > > We had a discussion about the 10/11 flows which are summarized as follows: > > MR: DTLS session bnetwee JCE and join assistant, doubly encryped (L2 hop > by hop and e2e DTLC/6top) > MR: TLS session setup consists of 2 exchanges: > . client hello (client presents his capabilities) > . server helo (new node) responds his capabilities) > . those packets re 100-150 bytes. possibly 60-70 bytes. suspect will > be 2 frames > . allow to agree on cipher, need crypto agility > . would be ideal is JCE presents 2 options, AES-TCM and other > . second exchange involves client certification, and response with > server certificate and DH > . packet ~1-2kB size. can be in smaller pieces > . biggest pieces in this is supplier chain of certificate that proves > own this node > . upper part of chain COULD be cached by join assistant. but, most of > statements will be mote-specific > > Agenda for next, second DODAG, how do we get that mode online: > text in section 3 starting with: > "The specific mechanism to enable end to end connectivity with the JCE" > > > > > > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > _______________________________________________ > 6tisch-security mailing list > 6tisch-security@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch-security > > --047d7bf18b76c9549005070b9f83 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
[adding the 6TiSCH ML]
On Tue, Nov 4, 2014 at 7:30 AM, Michael Richard= son <mcr+ietf@sandelman.ca> wrote:

My appologies for taking so long to get these out.
The call this week is in 30 minutes at:
=C2=A0 =C2=A0 > Meeting number: 645 146 419 Meeting password: timeslot A= udio
=C2=A0 =C2=A0 > connection: 1-877-668-4493 Call-in toll free number (US/Canada)
=C2=A0 =C2=A0 > 1-= 650-479-3208 Call-in toll number (US/Canada)

=C2=A0 =C2=A0 > https://ietf.webex.com/iet= f/j.php?MTID=3Dm026b87ec5a630ca1ec44f2e79329ba02

=C2=A0 =C2=A0 > etherpad for meeting:
=C2=A0 =C2=A0 > http://etherpad.tools.ietf.org:900= 0/p/6tisch-security-6top-xml.txt

=C2=A0 =C2=A0 > please note that google/browser-using-google-data might = complain about it
=C2=A0 =C2=A0 > being a phising site, it is likely a false positive, and= I've let
=C2=A0 =C2=A0 > ietf-action know about it.


2014-10-28 call started 11am EST.

Attending
- Thomas Watteyne
- Michael Richardson
- Jonathan Simon
- Kris Pister
- Mike Seewald
- Nancy Cam-Winget

We started the meeting by attempting to recap the discussion in the Mailing=
List.=C2=A0 Michael asks Kris to do the recap.=C2=A0 The thread starts at:<= br> =C2=A0 http://www.ietf.org/mail-archive/web/6= tisch-security/current/msg00212.html

The result of the discussion is that we have some terminology problems with=
the use of "join key" --- we agreed that we would use the followi= ng terms:

=C2=A0 join network - A 802.15.4e network whose well known global
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0encryption an= d authentication key is "JOIN6TISCH".
=C2=A0 unique join key - a symmetric key shared between a newly joining nod= e, and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the JCE.=C2= =A0 This key supports smaller installations for which
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0asymmetric me= thods are considered too large
=C2=A0 well known beacon key - this is the key "JOIN6TISCH"

MR discussed that while the unique join key might in some situations not be=
unique (we can not prevent use of pin "0000" a la Bluetooth heads= ets), we
should never make a protocol that depends upon the key being known by more<= br> than one node.

We then had a discussion about the term "trust anchors".
MCR said that the use of this term will cause some security people to assum= e
that this is related to the set of trust anchors present in web browsers; that some interaction with the Verisign/Komodo/etc. is intended, when it really is about connection to some industry consortia, or perhaps only to t= he
vendor's CA.

We covered the problem of the node knowing if it is joining the right
network, that "this is the JCE you are looking for" (Star Wars dr= oids
reference).=C2=A0 The oil refinery situation was raised; where competitors = have
equipment within radio distance of each other, and often sell/lease it amon= g
themselves.

MR: suggestion: certificate given by JCE to node, contains authorization wi= th
=C2=A0 =C2=A0 "I am your owner". there is a set of delegation in = supply chain. node can
=C2=A0 =C2=A0 authenticatie that. node need to go to its vendor

KP: so go out to the Internet and contact the vendor?
MR: don't suggest node or JCE do this online. Michael Belinger raised f= raud and
=C2=A0 =C2=A0 reselling. issue is that, when you purchase a node, you have = to
=C2=A0 =C2=A0 install. vendor could veto a resell market if was involved on= line. example
=C2=A0 =C2=A0 with lightbulbs

MR: opinion is that the way you get that certificate is out of scope. Here = is
=C2=A0 =C2=A0 your MAC id and certificate of who owns you

We had a discussion about possible ways that this introduces a vendor-locki= n
DRM, and the negative press that might result.=C2=A0 This is the reason for= the
802.1AR installation of a LDevID after the join process, as this
permits/supports resell and further econonic activity without permission of=
the vendor.

We agreed that there would never be a requirement to go out to the Internet= .

MCR explained purpose of draft-richardson-6tisch-idevid-cert... tried to explain relative to SIDR, but SIDR work was not known.

We discussed why we have a well-known-beacon key at all: mixing traffic fro= m
other sources users of that spectrum, and also concern that some MACs may b= e
unable to deal with unencrypted and encrypted traffic being received at the=
same time.

We had a discussion about the 10/11 flows which are summarized as follows:<= br>
MR: DTLS session bnetwee JCE and join assistant, doubly encryped (L2 hop by= hop and e2e DTLC/6top)
MR: TLS session setup consists of 2 exchanges:
=C2=A0 =C2=A0 . client hello (client presents his capabilities)
=C2=A0 =C2=A0 . server helo (new node) responds his capabilities)
=C2=A0 =C2=A0 . those packets re 100-150 bytes. possibly 60-70 bytes. suspe= ct will be 2 frames
=C2=A0 =C2=A0 . allow to agree on cipher, need crypto agility
=C2=A0 =C2=A0 . would be ideal is JCE presents 2 options, AES-TCM and other=
=C2=A0 =C2=A0 . second exchange involves client certification, and response= with server certificate and DH
=C2=A0 =C2=A0 . packet ~1-2kB size. can be in smaller pieces
=C2=A0 =C2=A0 . biggest pieces in this is supplier chain of certificate tha= t proves own this node
=C2=A0 =C2=A0 . upper part of chain COULD be cached by join assistant. but,= most of
=C2=A0 =C2=A0 statements will be mote-specific

Agenda for next, second DODAG, how do we get that mode online:
text in section 3 starting with:
=C2=A0 =C2=A0"The specific mechanism to enable end to end connectivity= with the JCE"







--
Michael Richardson <mcr+IETF@= sandelman.ca>, Sandelman Software Works
=C2=A0-=3D IPv6 IoT consulting =3D-




_______________________________________________
6tisch-security mailing list
6tisch-security@ietf.org https://www.ietf.org/mailman/listinfo/6tisch-security


--047d7bf18b76c9549005070b9f83-- From nobody Fri Nov 7 01:28:42 2014 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF271AC42F for <6tisch@ietfa.amsl.com>; Fri, 7 Nov 2014 01:28:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.919 X-Spam-Level: X-Spam-Status: No, score=0.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1Kc_49A-SN2 for <6tisch@ietfa.amsl.com>; Fri, 7 Nov 2014 01:28:39 -0800 (PST) Received: from jan.eatserver.nl (jan.eatserver.nl [IPv6:2001:67c:28fc:195:20:9:89:0]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3BCD1AC42C for <6tisch@ietf.org>; Fri, 7 Nov 2014 01:28:38 -0800 (PST) Received: from [195.242.97.150] (qore.networks.above.net [195.242.97.150] (may be forged)) (authenticated bits=0) by jan.eatserver.nl (8.13.8/8.13.8) with ESMTP id sA79SalM009969 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <6tisch@ietf.org>; Fri, 7 Nov 2014 10:28:36 +0100 Received: from localhost (localhost.localhost [127.0.0.1]) by router38.aimvalley.nl (Postfix) with ESMTP id 6C2F481810C for <6tisch@ietf.org>; Fri, 7 Nov 2014 10:28:36 +0100 (CET) X-Virus-Scanned: by Endian Firewall X-Spam-CTCH-RefID: Received: from mail3.aimsys.nl (mail.aimsys.nl [10.10.0.114]) by router38.aimvalley.nl (Postfix) with ESMTP id 9CB3A818103 for <6tisch@ietf.org>; Fri, 7 Nov 2014 10:28:32 +0100 (CET) Received: from linpc176.aimsys.nl (linpc176.aimsys.nl [10.10.8.76]) by mail3.aimsys.nl (8.14.2/8.14.2) with ESMTP id sA79SWn6018625 for <6tisch@ietf.org>; Fri, 7 Nov 2014 10:28:32 +0100 Message-ID: <545C90C0.7010806@aimvalley.nl> Date: Fri, 07 Nov 2014 10:28:32 +0100 From: Kees Trommel User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: 6tisch@ietf.org In-Reply-To: CAMsDxWTWX6eCVtMXVwZPPT9VwQvLw_vxCc6DcyOB0_vEXEQPfg@mail.gmail.com Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch/LhHo0t-cSxkYkF1QmCFDJQ7oX-M Subject: Re: [6tisch] Fwd: I-D Action: draft-ietf-6tisch-minimal-03.txt X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 09:28:41 -0000 Hi,

This draft specifies that the enhanced beacon should include a Channel Hopping IE with a Hopping Sequence ID equal to 0. Hopping Sequence ID 0 is the default hopping sequence ID. So the actual hopping sequence will not be included in the enhanced beacon.

Section 5.1.1a of the IEE802.25.4e standard defines an algorithm to calculate a default hopping sequence ID.

I have the following questions regarding the default hopping sequence:

1. Is it the intention that a minimal configuration uses the default hopping sequence as defined in the IEE802.25.4e standard?
2. If the answer on 1. is yes:  The definition of the IEE802.25.4e hopping sequence (in my opinion) is not unambiguous, so can you add the actual default hopping sequence to this draft?

Regards,

Kees.

On Oct 27, 2014, at 12:20 AM, Xavier Vilajosana <xvilajosana at eecs.berkeley.edu> wrote:

All, I just published the new version of minimal. It includes a security section as discussed last call and some changes to the default timing to be according to 15.4 tsch default values.

regards,
Xavi

---------- Forwarded message ----------
From: <internet-drafts at ietf.org>
Date: 2014-10-27 5:17 GMT+01:00
Subject: [6tisch] I-D Action: draft-ietf-6tisch-minimal-03.txt
To: i-d-announce at ietf.org
Cc: 6tisch at ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the IPv6 over the TSCH mode of IEEE 802.15.4e Working Group of the IETF.

        Title           : Minimal 6TiSCH Configuration
        Authors         : Xavier Vilajosana
                          Kris Pister
        Filename        : draft-ietf-6tisch-minimal-03.txt
        Pages           : 22
        Date            : 2014-10-26

Abstract:
   This document describes the minimal set of rules to operate a
   [IEEE802154e] Timeslotted Channel Hopping (TSCH) network.  This
   minimal mode of operation can be used during network bootstrap, as a
   fall-back mode of operation when no dynamic scheduling solution is
   available or functioning, or during early interoperability testing
   and development.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-6tisch-minimal-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-6tisch-minimal-03


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
6tisch mailing list
6tisch at ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

_______________________________________________
6tisch mailing list
6tisch at ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

From nobody Fri Nov 7 01:28:50 2014 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CF861ACF63 for <6tisch@ietfa.amsl.com>; Fri, 7 Nov 2014 01:28:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.919 X-Spam-Level: X-Spam-Status: No, score=0.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gcz0ZyPA9CHk for <6tisch@ietfa.amsl.com>; Fri, 7 Nov 2014 01:28:47 -0800 (PST) Received: from jan.eatserver.nl (jan.eatserver.nl [IPv6:2001:67c:28fc:195:20:9:89:0]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E4DD1ACF62 for <6tisch@ietf.org>; Fri, 7 Nov 2014 01:28:46 -0800 (PST) Received: from [195.242.97.150] (qore.networks.above.net [195.242.97.150] (may be forged)) (authenticated bits=0) by jan.eatserver.nl (8.13.8/8.13.8) with ESMTP id sA79Si8g010002 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <6tisch@ietf.org>; Fri, 7 Nov 2014 10:28:45 +0100 Received: from localhost (localhost.localhost [127.0.0.1]) by router38.aimvalley.nl (Postfix) with ESMTP id 2EFFE818106 for <6tisch@ietf.org>; Fri, 7 Nov 2014 09:57:51 +0100 (CET) X-Virus-Scanned: by Endian Firewall X-Spam-CTCH-RefID: Received: from mail3.aimsys.nl (mail.aimsys.nl [10.10.0.114]) by router38.aimvalley.nl (Postfix) with ESMTP id 5150D818103 for <6tisch@ietf.org>; Fri, 7 Nov 2014 09:57:47 +0100 (CET) Received: from linpc176.aimsys.nl (linpc176.aimsys.nl [10.10.8.76]) by mail3.aimsys.nl (8.14.2/8.14.2) with ESMTP id sA78vk8r017719 for <6tisch@ietf.org>; Fri, 7 Nov 2014 09:57:47 +0100 Message-ID: <545C898A.8060300@aimvalley.nl> Date: Fri, 07 Nov 2014 09:57:46 +0100 From: Kees Trommel User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: 6tisch@ietf.org Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch/Gvfn7-1GvKB3J1mGs1eLL4CG7dM Subject: Re: [6tisch] Fwd: I-D Action: draft-ietf-6tisch-minimal-03.txt X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 09:28:48 -0000 Hi,

This draft specifies that the enhanced beacon should include a Channel Hopping IE with a Hopping Sequence ID equal to 0. Hopping Sequence ID 0 is the default hopping sequence ID. So the actual hopping sequence will not be included in the enhanced beacon.

Section 5.1.1a of the IEE802.25.4e standard defines an algorithm to calculate a default hopping sequence ID.

I have the following questions regarding the default hopping sequence:

1. Is it the intention that a minimal configuration uses the default hopping sequence as defined in the IEE802.25.4e standard?
2. If the answer on 1. is yes:  The definition of the IEE802.25.4e hopping sequence (in my opinion) is not unambiguous, so can you add the actual default hopping sequence to this draft?

Regards,

Kees.

On Oct 27, 2014, at 12:20 AM, Xavier Vilajosana <xvilajosana at eecs.berkeley.edu> wrote:

All, I just published the new version of minimal. It includes a security section as discussed last call and some changes to the default timing to be according to 15.4 tsch default values.

regards,
Xavi

---------- Forwarded message ----------
From: <internet-drafts at ietf.org>
Date: 2014-10-27 5:17 GMT+01:00
Subject: [6tisch] I-D Action: draft-ietf-6tisch-minimal-03.txt
To: i-d-announce at ietf.org
Cc: 6tisch at ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the IPv6 over the TSCH mode of IEEE 802.15.4e Working Group of the IETF.

        Title           : Minimal 6TiSCH Configuration
        Authors         : Xavier Vilajosana
                          Kris Pister
        Filename        : draft-ietf-6tisch-minimal-03.txt
        Pages           : 22
        Date            : 2014-10-26

Abstract:
   This document describes the minimal set of rules to operate a
   [IEEE802154e] Timeslotted Channel Hopping (TSCH) network.  This
   minimal mode of operation can be used during network bootstrap, as a
   fall-back mode of operation when no dynamic scheduling solution is
   available or functioning, or during early interoperability testing
   and development.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-6tisch-minimal-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-6tisch-minimal-03


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
6tisch mailing list
6tisch at ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

_______________________________________________
6tisch mailing list
6tisch at ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

From nobody Fri Nov 7 11:51:48 2014 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2704E1A1A1C for <6tisch@ietfa.amsl.com>; Fri, 7 Nov 2014 11:51:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.223 X-Spam-Level: * X-Spam-Status: No, score=1.223 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dEzpLQb2iMgj for <6tisch@ietfa.amsl.com>; Fri, 7 Nov 2014 11:51:43 -0800 (PST) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 836F41A1A1B for <6tisch@ietf.org>; Fri, 7 Nov 2014 11:51:42 -0800 (PST) Received: by mail-pd0-f173.google.com with SMTP id v10so3901411pde.32 for <6tisch@ietf.org>; Fri, 07 Nov 2014 11:51:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:content-type; bh=w8LVI7CJelk0KdbVht9qj4eHMOphAdFaXe8uRcFcOT4=; b=f7nbaiZOUJmI6tBt1DC/RzhjVWw26jIbj7YFrc7ZYZZyeq2Y6ZSyTJ7Df22fU+0D6X vT9lIhPMR4DNPYsZmeksFh/CBdPsxxM2Kpo6FyiykGcd/UZFRH5HoNnf390frkF05Jq4 wP5A1EL1KdYG4CDJbp+YWXbKCZKRcNgCDc5O6O+h0hFFh4VcC0/uy0Cpp4qSC5TxQOaD NiaT255+Lhk53mwv+BoKknj0bz/3vM0c/z/re4XZLf43TuQkwlStpOPUm/6vigT951cr 3uMA0LKlmlMK9CDFWrlYgaQcn39oIPGmp3e+kE4wZLCVfCAWG6hrNHg+Wmq+DQgAuFef IywA== X-Received: by 10.70.37.164 with SMTP id z4mr4560051pdj.3.1415389901784; Fri, 07 Nov 2014 11:51:41 -0800 (PST) MIME-Version: 1.0 Sender: twatteyne@gmail.com Received: by 10.66.88.42 with HTTP; Fri, 7 Nov 2014 11:51:21 -0800 (PST) From: Thomas Watteyne Date: Fri, 7 Nov 2014 11:51:21 -0800 X-Google-Sender-Auth: nfd9MvWcqyHdEd-qQ4DabkqSSpQ Message-ID: To: "6tisch@ietf.org" <6tisch@ietf.org> Content-Type: multipart/alternative; boundary=089e0103e0f2508cb405074a246f Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch/B33bzvJ2iWHjjFXi5XrBdlPHXt0 Subject: [6tisch] Minutes Webex 7 November 2014 X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 19:51:46 -0000 --089e0103e0f2508cb405074a246f Content-Type: text/plain; charset=UTF-8 All, You will find the minutes of the last 6TiSCH interim call below (also at https://bitbucket.org/6tisch/meetings/ and https://www.ietf.org/meeting/interim/proceedings.html). Reply with comments/suggestions. We will approve these minutes at the next 6TiSCH interim call. Thomas --- Minutes Webex 07 November 2014, 6TiSCH WG Note: timestamps in PDT. Connection details - Webex: https://ciscosales.webex.com/ciscosales/j.php?ED=219615007&UID=481905242&PW=NZTRkNDAwOTE1&RT=MiMyMw%3D%3D - Etherpad: http://etherpad.tools.ietf.org:9000/p/6tisch?useMonospaceFont=true - Topic: 6TiSCH Weekly - Time: 8:00 am, Pacific Daylight Time (San Francisco, GMT-07:00) - Meeting Number: 206 802 913 - Meeting Password: sixtus - CCM: +14085256800x206802913 Resources - Webex recording: https://cisco.webex.com/ciscosales/lsr.php?RCID=5dc727523f4a4b7ca02f2a8aef479f66 - Wiki: https://bitbucket.org/6tisch/meetings/wiki/141107_webex - Slides: https://bitbucket.org/6tisch/meetings/src/master/141107_webex/slides_141107_webex.ppt Taking notes *(using Etherpad)* 1. Xavi Vilajosana 2. Thomas Watteyne Present 1. Giuseppe Piro 2. Maria Rita Palattella 3. Martin Turon 4. Michel Veillette 5. Nicola Accettura 6. Pascal Thubert 7. Raghuram Sudhaakar 8. Sedat Gormus 9. Shitanshu Shah 10. Subir Das 11. Thomas Watteyne 12. Xavi Vilajosana Action Items - *Pascal* to add when draft-ietf-6tisch-tsch was adopted by WG - *Pascal* to remove "outline" slide from draft-ietf-6tisch-minimal presentation - *Xavi* to discuss with Pat Kinney about TsTxOffset. Renamed? - *Pascal* to start discussion in 6TiSCH ML about whether we make recommendation about a RPL instance to be used. Agenda - Administrivia *[2min]* - Approval agenda - Approval minutes last call - overview new I-Ds *[3min]* - IETF91 admin *[5min]* - meetecho remote presentation - final agenda - run through draft-ietf-6tisch-minimal-03 *[5min]* (Xavi Vilajosana) - run through draft-ietf-6tisch-6top-interface-02 *[5min]* (Thomas Watteyne) - run through draft-finn-detnet-problem-statement-01 *[5min]* (Norm Finn) - run through 6TiSCH ETSI Plugtest slides *[5min]* (TBD) - run through draft-richardson-6tisch--security-6top-03 *[5min]* (Michael Richardson) - run through draft-struik-6tisch-security-architecture-elements-01 *[5min]* (Rene Stuik) - RFC7322: RFC Style Guide *[5min]* (Pascal Thubert) - AOB *[5min]* Minutes - *[08.05]* Meeting starts - *Pascal* starts recording - *Pascal* reminds note well - Objective of this call: prepare for IETF91 6TiSCH WG meeting, going through slides - *Thomas* indicates security design team met on Tuesday, minutes to be published - minutes will be published. - architecture is being developed. - Michael Richardson is going to present it at the next IETF meeting - *[08.07]* Administrivia *[2min]* - Approval agenda? - *[Thomas]* canceled agenda items: - Michael and Rene in the plane, they will send the slides as soon as they arrive in Hawaii. - Miguel will send slides on Monday - *[Thomas]* proposed additional agenda item: - discuss what we want to achieve during IETF91 - *[Martin]* what is the 6TiSCH outcome about RPL compression? - *[Pascal]* discussions will be carried out during 6lo WG meeting - https://datatracker.ietf.org/meeting/91/agenda/6lo/ - *[Thomas]* we agreed that the minimal draft published last week contains a link to the RPL compression mechanism that we are planning to use at 6TiSCH http://www.ietf.org/internet-drafts/draft-thubert-6lo-rpl-nhc-02.txt - *[Pascal]* status: suggestion that we should work on compression of RFC6553 and RFC6554. Have a new dispatch type. - *[Pascal]* we started with Flow Label approach that was compressing using the flow label space. Moving to 6top we make explicit that we carry the Routing information compressed. The cost is that we use more bytes. Can we get back to the space defined in RFC4944 (dispatch) and create a routing dispatch? - *[Xavi]* Would we have 2 dispatch options? - *[Pascal]* the packet will have a routing dispatch inside there will be some TLVs. After this particular dispatch there might me other dispatch (including the original packet, IPv6 dispatch). In terms of space this is similar to having Extension headers. Yes but it solves the IP in IP problem (encapsulating IP in IP). Could mean deprecation of the Mesh header. - *[Thomas]* I strongly oppose that idea. - *[Martin]* It seems like you are trying to propose a Mesh under RPL. Mesh header is well designed. Discourage the deprecation of the Mesh header. - *[Thomas]* We agreed to use draft-thubert-6lo-rpl-nhc; now part of minimal draft. I believe we should stick to that plan. 6lo meeting will dedicate 30min to this draft. - *[Thomas]* This discussion is very important and we need to have it in a open forum, well beyond this call. - *[Thomas]* What do we want to achieve during IETF91? *Thomas* pastes list in chat and presents it line by line - agreeing on http://www.ietf.org/internet-drafts/draft-thubert-6lo-rpl-nhc-02.txt - 30min in 6lo ( https://datatracker.ietf.org/meeting/91/agenda/6lo/) - it looks like 4 drafts are almost WGLC'able - draft-ietf-6tisch-tsch - draft-ietf-6tisch-minimal - draft-ietf-6tisch-6top-interface - draft-ietf-6tisch-coap (see discussion below) - Chairs to discuss plugtest with AD - ETSI and 6TiSCH committed for IETF93 - need to explore possibilities for rooms, etc with Ted - agree on strategy for draft-ietf-6tisch-coap - *[Thomas]* question is: should we push draft-ietf-6tisch-coap or wait for generic solution from COMAN? - *[Thomas]* opinions? - *[Xavi]* if COMAN's solution does not take ages, would prefer to go for a more general approach - *[Pascal]* suggest to publish a version of draft-ietf-6tisch-coap which clearly contains some versioning mechanism, so we can (quickly) ship what we have and allow it to evolve. - *[Thomas]* Agree that would be better to have a generic solution, but we waited for 1 year now. We should speed up things. Push for the current draft and have a back door so we can change in case there is a more general solution. - *[Xavi]* Would add one point: discuss about the 6top interface and whether it should cover all the 15.4PIB or not. If not, where is the boundary? what are the items that should be tackled by 6top YANG model? - Approval minutes last call [editorial note by Thomas: we got carried away by previous discussion and did NOT explicitly cover this point, oops. I will send an e-mail to the ML to ask for approval of the minutes of last call. This is an additional action item NOT discussed during the call.] - overview new I-Ds *[3min]* - the following drafts were published for IETF91: - draft-ietf-6tisch-6top-interface-02 - draft-ietf-6tisch-architecture-04 - draft-ietf-6tisch-minimal-03 - draft-ietf-6tisch-tsch-03 - draft-richardson-6tisch--security-6top-03 - draft-struik-6tisch-security-architecture-elements-01 - *[08.39]* IETF91 admin *[5min]* - final agenda at https://datatracker.ietf.org/meeting/91/agenda/6tisch/ - run-through draft-ietf-6tisch-tsch-03 *[Maria Rita Palattella]* - *Maria Rita* presents slides Action item: *Pascal* to add when draft-ietf-6tisch-tsch was adopted by WG - run-through draft-ietf-6tisch-minimal-03 *[Xavi Vilajosana]* - Xavi presents slides Action item: *Pascal* to remove "outline" slide from draft-ietf-6tisch-minimal presentation - *[Xavi]* we need to discuss with Pat Kinney about TsTxOffset. Renamed? Action item: *Xavi* to discuss with Pat Kinney about TsTxOffset. Renamed? - *[Pascal]* in architecture, indicate we use rank from one RPL distribution - *[Xavi]* for minimal, we could use the lowest/highest Action item: *Pascal* to start discussion in 6TiSCH ML about whether we make recommendation about a RPL instance to be used - run-through draft-ietf-6tisch-6top-interface-02 *[Thomas Watteyne]* - We need to raise question about authorship. Pat Kinney will probably join authors, mostly for English. - run-through draft-finn-detnet-problem-statement-01 *[Pascal Thubert]* - *Pascal* presents slides, can present slides during WG meeting, or Norm - run-through 6TiSCH ETSI Plugtest slides not covered (see comment Thomas at beginning of call) - run through draft-richardson-6tisch--security-6top-03 not covered (see comment Thomas at beginning of call) - run through draft-struik-6tisch-security-architecture-elements-01 not covered (see comment Thomas at beginning of call) - RFC7322: RFC Style Guide not covered. *Pascal* recommends to go through slides. - AOB *[5min]* - *[Thomas]* Meetecho team will contact remote presenters to schedule some testing. This will be during IETF week, but before the WG meeting. Not sure when. - *[Martin]* Suggests to spend more time on security, and have a clear presentation discussion on what is proposed. - *[Martin]* Have fun in HI! - *[09.15]* Meeting ends --089e0103e0f2508cb405074a246f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All,

You will find the minut= es of the last 6TiSCH interim call below (also at https://bitbucket.org/6tisch/meetings/ and https://www= .ietf.org/meeting/interim/proceedings.html).

R= eply with comments/suggestions. We will approve these minutes at the next 6= TiSCH interim call.

Thomas

---

Minutes Webex 07 November 2014, 6TiSCH WG

Note: timestamps= in PDT.

Connection details

  • Web= ex:=C2=A0https://= ciscosales.webex.com/ciscosales/j.php?ED=3D219615007&UID=3D481905242&am= p;PW=3DNZTRkNDAwOTE1&RT=3DMiMyMw%3D%3D
  • Etherpad:=C2=A0http://etherpad.tools.ietf.org:9000/p/6tisch?use= MonospaceFont=3Dtrue
  • Topic: 6TiS= CH Weekly
  • Time: 8:00 am, Pacific Day= light Time (San Francisco, GMT-07:00)
  • Meeting Number: 206 802 913
  • Meetin= g Password: sixtus
  • CCM: +14085256800= x206802913
  • Resources

    • Webex recordi= ng:=C2=A0https://cisco.webex.com/ciscosales/lsr.php?RCID=3D5= dc727523f4a4b7ca02f2a8aef479f66
    • = Wiki:=C2=A0h= ttps://bitbucket.org/6tisch/meetings/wiki/141107_webex
    • Slides:=C2=A0https://bitbucket.org= /6tisch/meetings/src/master/141107_webex/slides_141107_webex.ppt
    • Taking notes=C2=A0(usi= ng Etherpad)

      1. Xavi Vilajosana
      2. Thomas Watteyne

      Present

      1. Giuseppe = Piro
      2. Maria Rita Palattella
      3. Martin Turon
      4. Michel Veillette
      5. Nicola Accet= tura
      6. Pascal Thubert
      7. Raghuram Sudhaakar
      8. Sedat Gormus
      9. Shitanshu Shah
      10. Subir Das
      11. Thomas Watteyne
      12. Xavi Vila= josana

      Action Items

      • P= ascal=C2=A0to add when draft-ietf-6tisch-tsch was adopted by WG
      • Pascal=C2=A0to remove= "outline" slide from draft-ietf-6tisch-minimal presentation
      • =
      • Xavi=C2=A0to discuss wi= th Pat Kinney about TsTxOffset. Renamed?
      • Pascal=C2=A0to start discussion in 6TiSCH ML about wh= ether we make recommendation about a RPL instance to be used.

      Agenda

        Administrivia=C2=A0[2min]
        • Approval agenda=
        • Approval minutes last call
        • overview new I-Ds=C2=A0[3min]<= /em>
        • IETF91 admin=C2=A0[5min]
          • meet= echo remote presentation
          • final agend= a
        • run through draft-ietf-6= tisch-minimal-03=C2=A0[5min]=C2=A0(Xavi Vilajosana)
        • run through draft-ietf-6tisch-6top-interface-02= =C2=A0[5min]=C2=A0(Thomas Watteyne)
        • run through draft-finn-detnet-problem-statement-01=C2=A0[5min]= =C2=A0(Norm Finn)
        • run through 6= TiSCH ETSI Plugtest slides=C2=A0[5min]=C2=A0(TBD)
        • run through draft-richardson-6tisch--security-6top-0= 3=C2=A0[5min]=C2=A0(Michael Richardson)
        • run through draft-struik-6tisch-security-architecture-elements= -01=C2=A0[5min]=C2=A0(Rene Stuik)
        • RFC7322: RFC Style Guide=C2=A0[5min]=C2=A0(Pascal Thubert)<= /li>
        • AOB=C2=A0[5min]
        Minutes
        • [08.05]=C2=A0Meeting starts
        • P= ascal=C2=A0starts recording
        • Pascal=C2=A0reminds note well
        • Objective of this call: prepare for IETF91 6TiSCH WG meeting, g= oing through slides
        • Thomas=C2=A0indicates security design team met on Tuesday, minutes to be p= ublished
          • minutes will be published.
          • archite= cture is being developed.
          • Michael Ri= chardson is going to present it at the next IETF meeting
        • [08.07]=C2=A0Administrivi= a=C2=A0[2min]
          • Approval agenda?
          • [Thomas]=C2=A0canceled agenda items:
            • Michael and Rene in the plane, = they will send the slides as soon as they arrive in Hawaii.
            • Miguel will send slides on Monday
          • <= li style=3D"word-wrap:break-word">[Thomas]=C2=A0proposed a= dditional agenda item:
            • discuss what we want to achieve during IETF91
          • [Martin]=C2=A0what is = the 6TiSCH outcome about RPL compression?
              =
            • [Pascal]=C2=A0discussio= ns will be carried out during 6lo WG meeting
            • [Thomas]=C2=A0we agreed that the minimal draft published last week contains a lin= k to the RPL compression mechanism that we are planning to use at 6TiSCH

              h= ttp://www.ietf.org/internet-drafts/draft-thubert-6lo-rpl-nhc-02.txt

              =
            • [Pascal]=C2=A0status: suggestion that we should work on compression of RFC6553 a= nd RFC6554. Have a new dispatch type.
            • [Pascal]=C2=A0we started with Flow Label approach that w= as compressing using the flow label space. Moving to 6top we make explicit = that we carry the Routing information compressed. The cost is that we use m= ore bytes. Can we get back to the space defined in RFC4944 (dispatch) and c= reate a routing dispatch?
            • [X= avi]=C2=A0Would we have 2 dispatch options?
            • [Pascal]=C2=A0the packet will have a rout= ing dispatch inside there will be some TLVs. After this particular dispatch= there might me other dispatch (including the original packet, IPv6 dispatc= h). In terms of space this is similar to having Extension headers. Yes but = it solves the IP in IP problem (encapsulating IP in IP). Could mean depreca= tion of the Mesh header.
            • [Th= omas]=C2=A0I strongly oppose that idea.
            • [Martin]=C2=A0It seems like you are trying to= propose a Mesh under RPL. Mesh header is well designed. Discourage the dep= recation of the Mesh header.
            • [Thomas]=C2=A0We agreed to use draft-thubert-6lo-rpl-nhc; now par= t of minimal draft. I believe we should stick to that plan. 6lo meeting wil= l dedicate 30min to this draft.
            • [Thomas]=C2=A0This discussion is very important and we need to= have it in a open forum, well beyond this call.
          • [Thomas]=C2=A0What do we want to ac= hieve during IETF91?

            Thomas=C2=A0pastes list in chat and p= resents it line by line

              <= li style=3D"word-wrap:break-word">agreeing on=C2=A0http://www.ietf.org/int= ernet-drafts/draft-thubert-6lo-rpl-nhc-02.txt
            • it = looks like 4 drafts are almost WGLC'able
              • draft-ietf-6tisch-tsch
              • draft-ietf-6tisch-minimal
              • draft-ietf-6tisch-6top-interface
              • draft-ietf-6tisch-coap (see discussion below)
            • Chairs to discuss plugtest with AD
              • ETSI and 6TiSCH committed for IET= F93
              • need to explore possibilities fo= r rooms, etc with Ted
            • agre= e on strategy for draft-ietf-6tisch-coap
              • [Thomas]=C2=A0question is: shoul= d we push draft-ietf-6tisch-coap or wait for generic solution from COMAN?
              • [Thomas]=C2=A0opinio= ns?
              • [Xavi]=C2=A0if = COMAN's solution does not take ages, would prefer to go for a more gene= ral approach
              • [Pascal]=C2=A0suggest to publish a version of draft-ietf-6tisch-coap which clearl= y contains some versioning mechanism, so we can (quickly) ship what we have= and allow it to evolve.
              • [Th= omas]=C2=A0Agree that would be better to have a generic solution, = but we waited for 1 year now. We should speed up things. Push for the curre= nt draft and have a back door so we can change in case there is a more gene= ral solution.
            • [Xav= i]=C2=A0Would add one point: discuss about the 6top interface and = whether it should cover all the 15.4PIB or not. If not, where is the bounda= ry? what are the items that should be tackled by 6top YANG model?
            =
          • Approval minutes last call

            [editoria= l note by Thomas: we got carried away by previous discussion and did NOT ex= plicitly cover this point, oops. I will send an e-mail to the ML to ask for= approval of the minutes of last call. This is an additional action item NO= T discussed during the call.]

        • overview new I-Ds=C2=A0[3min]
          • the following drafts w= ere published for IETF91:
            • draft-ietf-6tisch-6top-interface-02
            • draft-ietf-6tisch-architecture-04
            • draft-ietf-6tisch-minimal-03
            • draft-ietf-6tisch-tsch-03
            • draft-ric= hardson-6tisch--security-6top-03
            • dra= ft-struik-6tisch-security-architecture-elements-01
        • =
        • [08.39]=C2=A0IETF91 admin=C2=A0= [5min]
        • run-through draft-ietf-6t= isch-tsch-03=C2=A0[Maria Rita Palattella]
          • Maria Rita=C2=A0presents slides

            Action item:=C2=A0Pascal=C2=A0to= add when draft-ietf-6tisch-tsch was adopted by WG

          • run-through draft-ietf-6tisch-min= imal-03=C2=A0[Xavi Vilajosana]
            • Xavi presents slides

              Action item:= =C2=A0Pascal=C2=A0to remove "outline" slide from= draft-ietf-6tisch-minimal presentation

            • [Xavi]=C2=A0we need to discuss with P= at Kinney about TsTxOffset. Renamed?

              Action item:=C2=A0Xavi=C2=A0to discuss with Pat Kinney about TsTxOffset. Renamed?

            • [Pascal]=C2=A0in= architecture, indicate we use rank from one RPL distribution
            • [Xavi]=C2=A0for minimal, we coul= d use the lowest/highest

              Action item:=C2=A0Pascal=C2=A0to = start discussion in 6TiSCH ML about whether we make recommendation about a = RPL instance to be used

          • run-through draft-ietf-6tisch-6top-interface-02=C2=A0[Thomas Watteyne]
            • We need to raise question about authorship. Pat Kinney= will probably join authors, mostly for English.
          • run-through draft-finn-detnet-problem-statement-01= =C2=A0[Pascal Thubert]
              Pascal=C2=A0presents slid= es, can present slides during WG meeting, or Norm
          • run-through 6TiSCH ETSI Plugtest slides

            not covere= d (see comment Thomas at beginning of call)

          • run through draft-richardson-6tisch--security-6to= p-03

            not covered (see comment Thomas at beginning of call)

            <= /li>
          • run through draft-struik-6tisch-secu= rity-architecture-elements-01

            not covered (see comment Thomas at beginning o= f call)

          • RFC7322: RF= C Style Guide

            not covered.=C2=A0Pascal=C2=A0recommends to g= o through slides.

          • A= OB=C2=A0[5min]
            • [Thomas]=C2=A0Meetecho team will contact = remote presenters to schedule some testing. This will be during IETF week, = but before the WG meeting. Not sure when.
            • [Martin]=C2=A0Suggests to spend more time on securit= y, and have a clear presentation discussion on what is proposed.
            • [Martin]=C2=A0Have fun in HI!=
          • [09.15]=C2=A0Mee= ting ends
    --089e0103e0f2508cb405074a246f-- From nobody Fri Nov 7 11:55:55 2014 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB4CD1A1A1C for <6tisch@ietfa.amsl.com>; Fri, 7 Nov 2014 11:55:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7JLkdYNIx1J1 for <6tisch@ietfa.amsl.com>; Fri, 7 Nov 2014 11:55:52 -0800 (PST) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AD901A1A14 for <6tisch@ietf.org>; Fri, 7 Nov 2014 11:55:52 -0800 (PST) Received: by mail-pa0-f49.google.com with SMTP id lj1so4090558pab.8 for <6tisch@ietf.org>; Fri, 07 Nov 2014 11:55:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:content-type; bh=zG+OgFIZnb8nI3yz/Yhy9M3yUq8cXzc5qZHgNbHJUf4=; b=l/UtU+hzRBa+3ZI3sr6+3hDgE4b+5MtApPFkGPi5usmQetKsIuDLYOu3U3jvbyGtV4 YOVMvRKxBDLI+s+LPyp7fBs80MgV7rhURZYofkpSxEggUAtAUbUu2FUBHaSMI3L0egpv Z33cDT/OK14eH/H/A7d/2Q48jLSccRoIHm9/8Qis7sMSrK6mmbcCllAlXtPZj8XFIquB /gC7ERorfz9EKfjUQ3YoaQc2pHYDaQfhI9AM4oT3U6MQUgg+d10uVlowHMWvUTIBa2GS A03wu3h/KEvuGuxFNOl82V+oONPgSMA0myW+84QFvTUenP8yWbH0K0lfvyl0/HNR/cly 9qvg== X-Received: by 10.68.217.197 with SMTP id pa5mr12202528pbc.3.1415390151830; Fri, 07 Nov 2014 11:55:51 -0800 (PST) MIME-Version: 1.0 Sender: twatteyne@gmail.com Received: by 10.66.88.42 with HTTP; Fri, 7 Nov 2014 11:55:31 -0800 (PST) From: Thomas Watteyne Date: Fri, 7 Nov 2014 11:55:31 -0800 X-Google-Sender-Auth: ELKkbocNmtmvsGUKZg4p4Dqhomo Message-ID: To: "6tisch@ietf.org" <6tisch@ietf.org> Content-Type: multipart/alternative; boundary=047d7b10cba537f27805074a3304 Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch/OfyJkbeZC1nmLKB5NmHbHdOkANY Subject: [6tisch] approval Minutes Webex 24 October 2014 X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 19:55:53 -0000 --047d7b10cba537f27805074a3304 Content-Type: text/plain; charset=UTF-8 All, While writing up the minutes of today's 6TiSCH webex, I realize we got carries away in the discussions and did not formally approve the minutes of the last webex. There minutes are published at: - http://www.ietf.org/mail-archive/web/6tisch/current/msg02655.html - https://bitbucket.org/6tisch/meetings/wiki/141024_webex - http://www.ietf.org/proceedings/interim/2014/10/24/6tisch/minutes/minutes-interim-2014-6tisch-2 This e-mail is a call for approval of those minutes. If no issues are raised by next Monday midnight HST, we will consider the minutes approved. Thomas --047d7b10cba537f27805074a3304 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    All,

    While writing up the minutes of to= day's 6TiSCH webex, I realize we got carries away in the discussions an= d did not formally approve the minutes of the last webex. There minutes are= published at:

    Thomas
    --047d7b10cba537f27805074a3304-- From nobody Fri Nov 7 21:27:16 2014 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C55241A0372 for <6tisch@ietfa.amsl.com>; Fri, 7 Nov 2014 21:27:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tdUquIaitJWy for <6tisch@ietfa.amsl.com>; Fri, 7 Nov 2014 21:27:11 -0800 (PST) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 342BC1A0369 for <6tisch@ietf.org>; Fri, 7 Nov 2014 21:27:11 -0800 (PST) Received: by mail-ie0-f178.google.com with SMTP id rp18so6583913iec.9 for <6tisch@ietf.org>; Fri, 07 Nov 2014 21:27:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=6aCCuo5x7UyKHXwODfQX/NJxa4+ef0V6ndCCawxjNQw=; b=CmUUibfXfP227Y1nBxtWmbpi4lCMXqxOs9QX43HtJ5rXcH3HmeXUBTNE73nXecyQpN leDRMhHW50SgyyXK0KD44ymofliERXP7TCi1zTRtHR2ydo3BDXRYMnIrHFh16xIlwQl7 tbBdLMPA3U6Veft/Fvb0SW5C1HFEVqxHA+ysoFJ3JMXt3Emq6ohFi4MfuAPlLTd5oe7G ZK6ocKXVvHArieZycU26lE3G6xPyA72u3EhzTSkKB2tEctAQxoAaid0HkFIvA7LeTEE1 SHdsFuXR0dNyrZ4iXg4DSHq5zG3fNTr7uRPj+qgRbfULIqY7nF35bHsZesfK4JaBmPO3 G7Ag== MIME-Version: 1.0 X-Received: by 10.107.165.19 with SMTP id o19mr18119095ioe.1.1415424430492; Fri, 07 Nov 2014 21:27:10 -0800 (PST) Sender: xvilajosana@gmail.com Received: by 10.64.125.162 with HTTP; Fri, 7 Nov 2014 21:27:10 -0800 (PST) In-Reply-To: <545C898A.8060300@aimvalley.nl> References: <545C898A.8060300@aimvalley.nl> Date: Sat, 8 Nov 2014 06:27:10 +0100 X-Google-Sender-Auth: Nc0HpsZy4zZZ_mrPUugri7NTxVE Message-ID: From: Xavier Vilajosana To: Kees Trommel Content-Type: multipart/alternative; boundary=001a1141f1d262d1360507522ef2 Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch/4ZLzwXJ62LuSmIwIi0tMjkfA4iY Cc: "6tisch@ietf.org" <6tisch@ietf.org> Subject: Re: [6tisch] Fwd: I-D Action: draft-ietf-6tisch-minimal-03.txt X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Nov 2014 05:27:14 -0000 --001a1141f1d262d1360507522ef2 Content-Type: text/plain; charset=UTF-8 Dear Kees, thanks for your comments. answering 1) IMHO the fact that if default ch. hopping sequence is being used *may not be* advertised in the EB it is not clear in the standard. And therefore I opted to make the EB explicit (even only an ID and this being the default) Page 11 of the 15.4e amendment indicates that: *All hopping sequences are referred to by an ID, macHoppingSequenceID, with ID = 0 denoting the default* *sequence for a particular PHY (or PHY configuration if the PHY supports more than one channel list).* then page 92 *The full Hopping Sequence may be omitted to ensure that the frame does not exceed aMaxPHYPacketSize.* *In this case only the Hopping Sequence ID is carried, and the length of the IE is 1 octet. When the length is* *not equal to one, the additional fields are present. The element varies in length depending upon the* *numberOfChannels in use by the PHY. The channelPage and numberOfChannels attributes can be used to* *determine the size of the extendedBitmap, and the macHoppingSequenceLength can be used to determine* *the size of the macHoppingSequenceList.* *The Channel Hopping IE may be used by any channel hopping PAN to synchronize devices.* My last point here is that this *may* might indicate optionality but the case for the default id is not mentioned so I am not sure it can be elided if default id (0) answering 2) it seems a good point. Let us think about it. regards, Xavi 2014-11-07 9:57 GMT+01:00 Kees Trommel : > Hi, > > This draft specifies that the enhanced beacon should include a Channel > Hopping IE with a Hopping Sequence ID equal to 0. Hopping Sequence ID 0 is > the default hopping sequence ID. So the actual hopping sequence will not be > included in the enhanced beacon. > > Section 5.1.1a of the IEE802.25.4e standard defines an algorithm to > calculate a default hopping sequence ID. > > I have the following questions regarding the default hopping sequence: > > 1. Is it the intention that a minimal configuration uses the default > hopping sequence as defined in the IEE802.25.4e standard? > 2. If the answer on 1. is yes: The definition of the IEE802.25.4e hopping > sequence (in my opinion) is not unambiguous, so can you add the actual > default hopping sequence to this draft? > > Regards, > > Kees. > > On Oct 27, 2014, at 12:20 AM, Xavier Vilajosana eecs.berkeley.edu > wrote: > > All, I just published the new version of minimal. It includes a security > section as discussed last call and some changes to the default timing to be > according to 15.4 tsch default values. > > regards, > Xavi > > ---------- Forwarded message ---------- > From: > > Date: 2014-10-27 5:17 GMT+01:00 > Subject: [6tisch] I-D Action: draft-ietf-6tisch-minimal-03.txt > To: i-d-announce at ietf.org > Cc: 6tisch at ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IPv6 over the TSCH mode of IEEE > 802.15.4e Working Group of the IETF. > > Title : Minimal 6TiSCH Configuration > Authors : Xavier Vilajosana > Kris Pister > Filename : draft-ietf-6tisch-minimal-03.txt > Pages : 22 > Date : 2014-10-26 > > Abstract: > This document describes the minimal set of rules to operate a > [IEEE802154e] Timeslotted Channel Hopping (TSCH) network. This > minimal mode of operation can be used during network bootstrap, as a > fall-back mode of operation when no dynamic scheduling solution is > available or functioning, or during early interoperability testing > and development. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-6tisch-minimal-03 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-6tisch-minimal-03 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > 6tisch mailing list > 6tisch at ietf.org <6tisch%20at%20ietf.org> > https://www.ietf.org/mailman/listinfo/6tisch > > _______________________________________________ > 6tisch mailing list > 6tisch at ietf.org <6tisch%20at%20ietf.org> > https://www.ietf.org/mailman/listinfo/6tisch > > > > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > > --001a1141f1d262d1360507522ef2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Dear Kees,
    thanks for your comments.=C2=A0
    <= br>
    answering 1)
    IMHO the fact that if default ch.= hopping sequence is being used may not be advertised in the EB it i= s not clear in the standard. And therefore I opted to make the EB explicit = (even only an ID and this being the default)
    Page 11 of the 15.4e= amendment indicates that:

    All hopping sequence= s are referred to by an ID, macHoppingSequenceID, with ID =3D 0 denoting th= e default
    sequence for a particular PHY (or PHY configurat= ion if the PHY supports more than one channel list).

    then page 92
    The full Hopping Sequence may be omitted t= o ensure that the frame does not exceed aMaxPHYPacketSize.
    In this case only the Hopping Sequence ID is carried, and the length of th= e IE is 1 octet. When the length is
    not equal to one, the = additional fields are present. The element varies in length depending upon = the
    numberOfChannels in use by the PHY. The channelPage an= d numberOfChannels attributes can be used to
    determine the= size of the extendedBitmap, and the macHoppingSequenceLength can be used t= o determine
    the size of the macHoppingSequenceList.
    The Channel Hopping IE may be used by any channel hopping= PAN to synchronize devices.

    My l= ast point here is that this may=C2=A0might indicate optionality but = the case for the default id is not mentioned so I am not sure it can be eli= ded if default id (0)

    answering 2) it seems a good= point. Let us think about it.

    regards,
    = Xavi

    2= 014-11-07 9:57 GMT+01:00 Kees Trommel <ctrommel@aimvalley.nl>:
    =20 =20 =20
    Hi,

    This draft specifies that the enhanced beacon should include a Channel Hopping IE with a Hopping Sequence ID equal to 0. Hopping Sequence ID 0 is the default hopping sequence ID. So the actual hopping sequence will not be included in the enhanced beacon.

    Section 5.1.1a of the IEE802.25.4e standard defines an algorithm to calculate a default hopping sequence ID.

    I have the following questions regarding the default hopping sequence:

    1. Is it the intention that a minimal configuration uses the default hopping sequence as defined in the IEE802.25.4e standard?
    2. If the answer on 1. is yes:=C2=A0 The definition of the IEE802.25.4e hopping sequence (in my opinion) is not unambiguous, so can you add the actual default hopping sequence to this draft?

    Regards,

    Kees.

    On Oct 27, 2014, at 12:20 AM, Xavier Vilajosana <xvi= lajosana at eecs.berkeley.edu> wrote:

    All, I just published the new version of minimal. It includes a security section as discussed last call and some changes to the default timing to be according to 15.4 tsch default values.

    regards,
    Xavi

    ---------- Forwarded message ----------
    From: <internet-drafts at ietf.org>
    Date: 2014-10-27 5:17 GMT+01:00
    Subject: [6tisch] I-D Action: draft-ietf-6tisch-minimal-03.txt
    To: i-d-announce at ietf.org
    Cc: 6tisch at ietf.org



    A New Internet-Draft is available from the on-line Internet-Drafts directories.
    =C2=A0This draft is a work item of the IPv6 over the TSCH mod= e of IEEE 802.15.4e Working Group of the IETF.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0: Minimal 6TiSCH Configuration
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: Xavier Vilajosana
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Kris Pister
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2= =A0 : draft-ietf-6tisch-minimal-03.txt
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0: 22
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 : 2014-10-26

    Abstract:
    =C2=A0 =C2=A0This document describes the minimal set of rules= to operate a
    =C2=A0 =C2=A0[IEEE802154e] Timeslotted Channel Hopping (TSCH) network.=C2=A0 This
    =C2=A0 =C2=A0minimal mode of operation can be used during net= work bootstrap, as a
    =C2=A0 =C2=A0fall-back mode of operation when no dynamic sche= duling solution is
    =C2=A0 =C2=A0available or functioning, or during early interoperability testing
    =C2=A0 =C2=A0and development.


    The IETF datatracker status page for this draft is:
    https://datatracker.ietf.org/= doc/draft-ietf-6tisch-minimal/

    There's also a htmlized version available at:
    http://tools.ietf.org/html/draft-= ietf-6tisch-minimal-03

    A diff from the previous version is available at:
    http://www.ietf.org/rfcd= iff?url2=3Ddraft-ietf-6tisch-minimal-03


    Please note that it may take a couple of minutes from the time of submission
    until the htmlized version and diff are available at tools.ietf.= org.

    Internet-Drafts are also available by anonymous FTP at:
    ftp://ftp.ietf.org/internet-drafts/

    _______________________________________________
    6tisch mailing list
    6tisch at ietf.org
    https://www.ietf.org/mailman/listinfo/6tisch=

    _______________________________________________
    6tisch mailing list
    6tisch at ietf.org
    https://www.ietf.org/mailman/listinfo/6tisch=


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


    --001a1141f1d262d1360507522ef2-- From nobody Sat Nov 8 07:18:30 2014 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98DBF1A1BC5 for <6tisch@ietfa.amsl.com>; Sat, 8 Nov 2014 07:18:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.581 X-Spam-Level: X-Spam-Status: No, score=-13.581 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wnCjsgl5aMx0 for <6tisch@ietfa.amsl.com>; Sat, 8 Nov 2014 07:18:27 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 513F71A1BAE for <6tisch@ietf.org>; Sat, 8 Nov 2014 07:18:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=859; q=dns/txt; s=iport; t=1415459907; x=1416669507; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=fwYcSU5Tr3t7iVy71bqtuBBf1S9XRQ0z90ah1D1TmOc=; b=lJJTa1AcPZmohmvA/q0SNnLYAPjexirYKSxNQG/r6GKiBllxY1/2ULZt NBbdfcY3lBRbpyYY2t9AbQsg/xYB3NBBQswYMSIW/TERUFWvCV0StOZvy osCPhJD3AO2kJ2Mg9Sau6i9YMnkgadtt5wvamSz6fGf/5lGHbIPyWO9Ki Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAIkzXlStJA2F/2dsb2JhbABbgw5UWQTLWoZ6VQKBGxYBAQEBAXILhAQBBDpRASoUQiYBBBsBiDgNqG+keQEBAQcBAQEBAR2QOgYBAR4zgzKBHgWSJ4RUnXuDeWwBgQYIFyKBAwEBAQ X-IronPort-AV: E=Sophos;i="5.07,340,1413244800"; d="scan'208";a="94743624" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-7.cisco.com with ESMTP; 08 Nov 2014 15:18:27 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id sA8FIQN2022316 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <6tisch@ietf.org>; Sat, 8 Nov 2014 15:18:26 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.165]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Sat, 8 Nov 2014 09:18:26 -0600 From: "Pascal Thubert (pthubert)" To: "6tisch@ietf.org" <6tisch@ietf.org> Thread-Topic: RPL instance in Minimal Thread-Index: Ac/7Zymq8u4yhF8mTe2wljGqon6lVw== Date: Sat, 8 Nov 2014 15:18:25 +0000 Deferred-Delivery: Sat, 8 Nov 2014 15:18: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.75.228] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch/0VIG3PbxrQtb7cP3IHwIDg4FXi8 Subject: [6tisch] RPL instance in Minimal X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Nov 2014 15:18:28 -0000 Dear all: At the last interim call (http://www.ietf.org/mail-archive/web/6tisch/curre= nt/msg02661.html) the question of the RPL instance came up for the minimal = draft. Should we recommend to use a particular instance or not? Arguments on the table are:=20 - We wish to limit interop issues so suggesting an instance by default coul= d be a good idea - Using a different instance requires signaling or config - https://tools.ietf.org/html/draft-thubert-6lo-rpl-nhc-02 can elide instan= ce 0=20 - Some implementations do not support multi instance routing=20 - We need an instance for time distribution All in all, it appears that instance 0 will be used a lot and if we associa= te it with minimal, then we must make sure that non minimal time slots can = also be associated to that same instance. What do you think? Pascal=20 From nobody Sat Nov 8 18:18:59 2014 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56B2A1A00F2 for <6tisch@ietfa.amsl.com>; Sat, 8 Nov 2014 18:18:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R1y-6v_kytfj for <6tisch@ietfa.amsl.com>; Sat, 8 Nov 2014 18:18:56 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DECCE1A00EA for <6tisch@ietf.org>; Sat, 8 Nov 2014 18:18:55 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 958A22002A; Sat, 8 Nov 2014 21:20:48 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id CD996637F4; Sat, 8 Nov 2014 21:18:53 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id B81F063740; Sat, 8 Nov 2014 21:18:53 -0500 (EST) From: Michael Richardson To: "Pascal Thubert \(pthubert\)" In-Reply-To: References: X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch/e90DsJEhZ2SFQEYoOJlHlMqUV38 Cc: "6tisch@ietf.org" <6tisch@ietf.org> Subject: Re: [6tisch] RPL instance in Minimal X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Nov 2014 02:18:57 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Pascal Thubert (pthubert) wrote: > All in all, it appears that instance 0 will be used a lot and if we > associate it with minimal, then we must make sure that non minimal ti= me > slots can also be associated to that same instance. > What do you think? yes. 6tisch MUST suppport Instance 0 for the initial process. Once you have connectivity to PCE, the PCE can provision other things as required ... =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVF7PBYCLcPvd0N1lAQKrlAf/bB97YBdgUdX7FSnvdH4kGQnHAfPO52zv ROu78g4DJaSuOyK7WgLZztl9Qns+wMObPjbXiCq2G7Dh6MCoSgd0MWJb4DyBUbed DlBnwRd9CdLlAqMghxZcqBnho/lDCK/06ZrbaC4ecEC3YpxkP0AsSjbvRC8smGWF 0grUCd45o1qIpVuzP5ilvvzIKORwxVJvKloxpM9BwjoMpCfPtaze7gTz2dV74Xe/ 3owVlIGmrC8aYqCkyHiis6ZFIZw4rCLwN4Dy23KCeXMLxNLaYvVDC5IcLURqgIu+ Vfdm48xgZfviy6sLDLNqyXXrA+6Akfh8XTHrhOkhsuu/LBZPHjOdqw== =Rw4A -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Nov 8 18:30:01 2014 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D39B1A0217 for <6tisch@ietfa.amsl.com>; Sat, 8 Nov 2014 18:30:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MrPLIThV6lkh for <6tisch@ietfa.amsl.com>; Sat, 8 Nov 2014 18:29:59 -0800 (PST) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF7201A017E for <6tisch@ietf.org>; Sat, 8 Nov 2014 18:29:58 -0800 (PST) Received: by mail-pa0-f43.google.com with SMTP id eu11so5969206pac.30 for <6tisch@ietf.org>; Sat, 08 Nov 2014 18:29:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=GCT4TGqR4ERrgPiU4SmV8+3NlFUfb2KtDD2gRjuE2bo=; b=O60/Arzs+O6rafr4N/lOQ2JgEqFPxdmfEjpPzE59ydimFJTPHlYj9rX5Gr38MOhlgU 5ZK5XrQgQ9+Kn60OIzB6Isglb3S+CUvo2dwvPSBprw4ahpzdZh0BzSWQTruZu4/Jl8id s5cBix4fqqyR36AwtHO9qukgU2wJgijFkZ7Kf0G+XZCZwj/3zitxMQ2JaV0CLZ2rcvwT 0SYkatubmt+9vfhe6gxFV2ZEsnMgOrt8PhTTXZTQ1aLd2cTKdCabmgJylGdYBhDd8zgE EEEYa9nXWNHMnE2zKrcaU8Icf6Y/bB7YVbPf9bm5Rn//rCoJnZbMdI61iQ7mONntmT78 V7DA== MIME-Version: 1.0 X-Received: by 10.70.34.206 with SMTP id b14mr22880332pdj.10.1415500198156; Sat, 08 Nov 2014 18:29:58 -0800 (PST) Sender: twatteyne@gmail.com Received: by 10.66.88.42 with HTTP; Sat, 8 Nov 2014 18:29:58 -0800 (PST) In-Reply-To: <5632.1415499533@sandelman.ca> References: <5632.1415499533@sandelman.ca> Date: Sat, 8 Nov 2014 18:29:58 -0800 X-Google-Sender-Auth: S0LjOaA1PUCbVXOJ_A2UKZi1q48 Message-ID: From: Thomas Watteyne To: Michael Richardson Content-Type: multipart/alternative; boundary=089e0103e3e07da150050763d227 Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch/O2161fUKPphXLOQKctpysy4Bztw Cc: "Pascal Thubert \(pthubert\)" , "6tisch@ietf.org" <6tisch@ietf.org> Subject: Re: [6tisch] RPL instance in Minimal X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Nov 2014 02:30:00 -0000 --089e0103e3e07da150050763d227 Content-Type: text/plain; charset=UTF-8 Pascal, Instance 0 seems like a good idea, and your list of discussion point hint at the same. What are the cons? Thomas On Saturday, November 8, 2014, Michael Richardson wrote: > > Pascal Thubert (pthubert) > wrote: > > All in all, it appears that instance 0 will be used a lot and if we > > associate it with minimal, then we must make sure that non minimal > time > > slots can also be associated to that same instance. > > > What do you think? > > yes. > 6tisch MUST suppport Instance 0 for the initial process. > Once you have connectivity to PCE, the PCE can provision other things as > required ... > > -- > Michael Richardson >, Sandelman > Software Works > -= IPv6 IoT consulting =- > > > > --089e0103e3e07da150050763d227 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Pascal,
    Instance 0 seems like a good idea, and your list of discussion = point hint at the same. What are the cons?
    Thomas
    On Saturday, November 8, 2014, Michael Richardson <mcr+ietf@sandelman.ca> wrote:

    Pascal Thubert (pthubert) <pthubert@cisco.com> = wrote:
    =C2=A0 =C2=A0 > All in all, it appears that instance 0 will be used a lo= t and if we
    =C2=A0 =C2=A0 > associate it with minimal, then we must make sure that n= on minimal time
    =C2=A0 =C2=A0 > slots can also be associated to that same instance.

    =C2=A0 =C2=A0 > What do you think?

    yes.
    6tisch MUST suppport Instance 0 for the initial process.
    Once you have connectivity to PCE, the PCE can provision other things as required ...

    --
    Michael Richardson <mcr+IETF@sandelman.ca>, = Sandelman Software Works
    =C2=A0-=3D IPv6 IoT consulting =3D-



    --089e0103e3e07da150050763d227-- From nobody Sun Nov 9 15:30:24 2014 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DCE51A8781 for <6tisch@ietfa.amsl.com>; Sun, 9 Nov 2014 15:30:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6wl4UNJK1UJS for <6tisch@ietfa.amsl.com>; Sun, 9 Nov 2014 15:30:19 -0800 (PST) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E6671A8787 for <6tisch@ietf.org>; Sun, 9 Nov 2014 15:30:19 -0800 (PST) Received: by mail-pd0-f174.google.com with SMTP id p10so6603618pdj.19 for <6tisch@ietf.org>; Sun, 09 Nov 2014 15:30:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=NGHlXwhtXyX02jclLD0tF2l0jXbcpavpJu4WyZnIoGw=; b=HRc2Ht1Qkmssx02cIn5+mTuIYwX7cTj0hGGJ7PvFAiIhFunVTjEeU+qhu7nH5VvOxl +LXo6xfAZKTLhjXp3Op33a+DS3GhPj9R4YgyrJdxNrt9qh3vZCzNA35c/CVksmZFte9S TLfB9AGfZ7hnk4Q43hgcFfmGcRkBU2QJ7Sy9ZtGfq+Ti020QlBntcBFAxOuBtRMNIO+p y6zFgHno2aWXpyKtpI3+akICU/ZkQTLbnxGIfm++ohGbXuE4nHzR+Qp/TSCWlZ8RVw9y EmptBMvjc/0CQWWgxCbcOESjzzYcQj5PaC3+G77Hu4oAtpge5QBEPm670sQ2D8tqM7NI +j6w== X-Received: by 10.66.139.134 with SMTP id qy6mr111915pab.128.1415575818533; Sun, 09 Nov 2014 15:30:18 -0800 (PST) MIME-Version: 1.0 Sender: twatteyne@gmail.com Received: by 10.66.88.42 with HTTP; Sun, 9 Nov 2014 15:29:57 -0800 (PST) In-Reply-To: References: <545C898A.8060300@aimvalley.nl> From: Thomas Watteyne Date: Sun, 9 Nov 2014 13:29:57 -1000 X-Google-Sender-Auth: Hnxp8FsPH4EUCExFY4oVljETWQ4 Message-ID: To: Xavier Vilajosana Content-Type: multipart/alternative; boundary=047d7b5d5942d103c80507756da4 Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch/zNgCbdoBfw7uYTdepmpF8jWDIrY Cc: Kees Trommel , "6tisch@ietf.org" <6tisch@ietf.org> Subject: Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-03.txt X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Nov 2014 23:30:22 -0000 --047d7b5d5942d103c80507756da4 Content-Type: text/plain; charset=UTF-8 Kees, Xavi, If the default hopping sequence isn't clear in IEEE802.15.4e-2012, this is important information to the fed back to the IEEE802.15.4 TG. *@PatKinney*, maybe you can chime in on whether the related text will be changed in IEEE802.15.4-2015? In any case, let's disambiguate the hopping sequence on this thread. We could add an example in draft-ietf-6tisch-minimal, and maybe ask IEEE802.15.4 to do the same. I have created some quick Python code which I believe calculates the default hopping sequence, see https://gist.github.com/twatteyne/2e22ee3c1a802b685695. Could someone (*Pat*? *Jonathan*?) double-check that it computes the right sequence. I'm copy-pasting the output below. Thomas --- This script calculates the default channel hopping sequence for the IEEE802.15.4e-2012 TSCH mode. \author Thomas Watteyne \date November 2014 \license http://opensource.org/licenses/BSD-3-Clause === Step a. SHUFFLE is a macHoppingSequenceLength-sized array. The contents of this array ar e equivalent to the first macHoppingSequenceLength outputs of a 9-bit linear fee dback shift register (LFSR) with polynomial x9 + x5 + 1 and a starting seed of 2 55. Each LFSR output is modulo macHoppingSequenceLength, so that each entry of S HUFFLE is between 0 and (macHoppingSequenceLength - 1), inclusive. 5 9 1 1 1 1 1 1 1 1 0 ( 255==0x0ff==b011111111) 1 1 1 1 1 1 1 1 1 ( 511==0x1ff==b111111111) --> 15 0 1 1 1 1 1 1 1 1 ( 510==0x1fe==b111111110) --> 14 0 0 1 1 1 1 1 1 1 ( 508==0x1fc==b111111100) --> 12 0 0 0 1 1 1 1 1 1 ( 504==0x1f8==b111111000) --> 8 0 0 0 0 1 1 1 1 1 ( 496==0x1f0==b111110000) --> 0 0 0 0 0 0 1 1 1 1 ( 480==0x1e0==b111100000) --> 0 1 0 0 0 0 0 1 1 1 ( 449==0x1c1==b111000001) --> 1 1 1 0 0 0 0 0 1 1 ( 387==0x183==b110000011) --> 3 1 1 1 0 0 0 0 0 1 ( 263==0x107==b100000111) --> 7 1 1 1 1 0 0 0 0 0 ( 15==0x00f==b000001111) --> 15 0 1 1 1 1 0 0 0 0 ( 30==0x01e==b000011110) --> 14 1 0 1 1 1 1 0 0 0 ( 61==0x03d==b000111101) --> 13 1 1 0 1 1 1 1 0 0 ( 123==0x07b==b001111011) --> 11 1 1 1 0 1 1 1 1 0 ( 247==0x0f7==b011110111) --> 7 1 1 1 1 0 1 1 1 1 ( 495==0x1ef==b111101111) --> 15 1 1 1 1 1 0 1 1 1 ( 479==0x1df==b111011111) --> 15 SHUFFLE: [15, 14, 12, 8, 0, 0, 1, 3, 7, 15, 14, 13, 11, 7, 15, 15] === Step b. CHANNELS is a macHoppingSequenceLength-sized array that is initially populated w ith the monotonically increasing list of channels available to the PHY. CHANNELS: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15] === Step c. CHANNELS is shuffled as per Figure 7a. Elements may wind up being swapped multip le times in this process. macHoppingSequenceList: *[5, 6, 12, 7, 15, 4, 14, 11, 8, 0, 1, 2, 13, 3, 9, 10]* Script ended normally, press Enter to close. On Friday, November 7, 2014, Xavier Vilajosana < xvilajosana@eecs.berkeley.edu> wrote: > Dear Kees, > thanks for your comments. > > answering 1) > IMHO the fact that if default ch. hopping sequence is being used *may not > be* advertised in the EB it is not clear in the standard. And therefore I > opted to make the EB explicit (even only an ID and this being the default) > Page 11 of the 15.4e amendment indicates that: > > *All hopping sequences are referred to by an ID, macHoppingSequenceID, > with ID = 0 denoting the default* > *sequence for a particular PHY (or PHY configuration if the PHY supports > more than one channel list).* > > then page 92 > *The full Hopping Sequence may be omitted to ensure that the frame does > not exceed aMaxPHYPacketSize.* > *In this case only the Hopping Sequence ID is carried, and the length of > the IE is 1 octet. When the length is* > *not equal to one, the additional fields are present. The element varies > in length depending upon the* > *numberOfChannels in use by the PHY. The channelPage and numberOfChannels > attributes can be used to* > *determine the size of the extendedBitmap, and the > macHoppingSequenceLength can be used to determine* > *the size of the macHoppingSequenceList.* > *The Channel Hopping IE may be used by any channel hopping PAN to > synchronize devices.* > > My last point here is that this *may* might indicate optionality but the > case for the default id is not mentioned so I am not sure it can be elided > if default id (0) > > answering 2) it seems a good point. Let us think about it. > > regards, > Xavi > > 2014-11-07 9:57 GMT+01:00 Kees Trommel : > >> Hi, >> >> This draft specifies that the enhanced beacon should include a Channel >> Hopping IE with a Hopping Sequence ID equal to 0. Hopping Sequence ID 0 is >> the default hopping sequence ID. So the actual hopping sequence will not be >> included in the enhanced beacon. >> >> Section 5.1.1a of the IEE802.25.4e standard defines an algorithm to >> calculate a default hopping sequence ID. >> >> I have the following questions regarding the default hopping sequence: >> >> 1. Is it the intention that a minimal configuration uses the default >> hopping sequence as defined in the IEE802.25.4e standard? >> 2. If the answer on 1. is yes: The definition of the IEE802.25.4e >> hopping sequence (in my opinion) is not unambiguous, so can you add the >> actual default hopping sequence to this draft? >> >> Regards, >> >> Kees. >> >> On Oct 27, 2014, at 12:20 AM, Xavier Vilajosana > eecs.berkeley.edu> wrote: >> >> All, I just published the new version of minimal. It includes a >> security section as discussed last call and some changes to the default >> timing to be according to 15.4 tsch default values. >> >> regards, >> Xavi >> >> ---------- Forwarded message ---------- >> From: >> Date: 2014-10-27 5:17 GMT+01:00 >> Subject: [6tisch] I-D Action: draft-ietf-6tisch-minimal-03.txt >> To: i-d-announce at ietf.org >> Cc: 6tisch at ietf.org >> >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the IPv6 over the TSCH mode of IEEE >> 802.15.4e Working Group of the IETF. >> >> Title : Minimal 6TiSCH Configuration >> Authors : Xavier Vilajosana >> Kris Pister >> Filename : draft-ietf-6tisch-minimal-03.txt >> Pages : 22 >> Date : 2014-10-26 >> >> Abstract: >> This document describes the minimal set of rules to operate a >> [IEEE802154e] Timeslotted Channel Hopping (TSCH) network. This >> minimal mode of operation can be used during network bootstrap, as a >> fall-back mode of operation when no dynamic scheduling solution is >> available or functioning, or during early interoperability testing >> and development. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-6tisch-minimal-03 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-6tisch-minimal-03 >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> 6tisch mailing list >> 6tisch at ietf.org >> https://www.ietf.org/mailman/listinfo/6tisch >> >> _______________________________________________ >> 6tisch mailing list >> 6tisch at ietf.org >> https://www.ietf.org/mailman/listinfo/6tisch >> >> >> >> _______________________________________________ >> 6tisch mailing list >> 6tisch@ietf.org >> https://www.ietf.org/mailman/listinfo/6tisch >> >> > --047d7b5d5942d103c80507756da4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Kees, Xavi,

    If the default hopping sequ= ence isn't clear in IEEE802.15.4e-2012, this is important information t= o the fed back to the IEEE802.15.4 TG. @PatKinney, maybe you can chi= me in on whether the related text will be changed in IEEE802.15.4-2015?

    In any case, let's disambiguate the hopping seque= nce on this thread. We could add an example in draft-ietf-6tisch-minimal, a= nd maybe ask IEEE802.15.4 to do the same.

    I have c= reated some quick Python code which I believe calculates the default hoppin= g sequence, see https://gist.github.com/twatteyne/2e22ee3c1a802b685695.

    Could someone (Pat? Jonathan?) double-check= that it computes the right sequence. I'm copy-pasting the output below.<= /div>

    Thomas

    ---

    This script calculate= s the default channel hopping sequence for the
    IEEE802.15.4e-2012 TSCH mode.
    =
    \author Thomas Watteyne
    \date November 2014
    \license http://opensource.org/licenses/BSD-3-Clause


    =3D=3D=3D Step a.

    S= HUFFLE is a macHoppingSequenceLength-sized array. The contents of this arra= y ar
    e equivalent to= the first macHoppingSequenceLength outputs of a 9-bit linear fee
    dback shift register (LFSR) w= ith polynomial x9 + x5 + 1 and a starting seed of 2
    55. Each LFSR output is modulo macHoppingSe= quenceLength, so that each entry of S
    HUFFLE is between 0 and (macHoppingSequenceLength - 1), i= nclusive.

    =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A05 =C2=A0 =C2=A0 =C2=A0 9
    =C2=A0 =C2=A01 1 1 1 1 1 1 1 0 ( 255=3D=3D0x0ff=3D=3D= b011111111)
    =C2=A0 = =C2=A01 1 1 1 1 1 1 1 1 ( 511=3D=3D0x1ff=3D=3Db111111111) --> 15<= /div>
    =C2=A0 =C2=A00 1 1 1 1 1 1 = 1 1 ( 510=3D=3D0x1fe=3D=3Db111111110) --> 14
    =C2=A0 =C2=A00 0 1 1 1 1 1 1 1 ( 508=3D=3D0x1fc= =3D=3Db111111100) --> 12
    =C2=A0 =C2=A00 0 0 1 1 1 1 1 1 ( 504=3D=3D0x1f8=3D=3Db111111000) --= > 8
    =C2=A0 =C2=A0= 0 0 0 0 1 1 1 1 1 ( 496=3D=3D0x1f0=3D=3Db111110000) --> 0
    =C2=A0 =C2=A00 0 0 0 0 1 1 1 1 ( 4= 80=3D=3D0x1e0=3D=3Db111100000) --> 0
    =C2=A0 =C2=A01 0 0 0 0 0 1 1 1 ( 449=3D=3D0x1c1=3D=3Db1= 11000001) --> 1
    = =C2=A0 =C2=A01 1 0 0 0 0 0 1 1 ( 387=3D=3D0x183=3D=3Db110000011) --> 3
    =C2=A0 =C2=A01 1 1 0 = 0 0 0 0 1 ( 263=3D=3D0x107=3D=3Db100000111) --> 7
    =C2=A0 =C2=A01 1 1 1 0 0 0 0 0 ( =C2=A015= =3D=3D0x00f=3D=3Db000001111) --> 15
    =C2=A0 =C2=A00 1 1 1 1 0 0 0 0 ( =C2=A030=3D=3D0x01e=3D= =3Db000011110) --> 14
    =C2=A0 =C2=A01 0 1 1 1 1 0 0 0 ( =C2=A061=3D=3D0x03d=3D=3Db000111101) = --> 13
    =C2=A0 =C2= =A01 1 0 1 1 1 1 0 0 ( 123=3D=3D0x07b=3D=3Db001111011) --> 11
    =C2=A0 =C2=A01 1 1 0 1 1 1 1 0= ( 247=3D=3D0x0f7=3D=3Db011110111) --> 7
    =C2=A0 =C2=A01 1 1 1 0 1 1 1 1 ( 495=3D=3D0x1ef=3D= =3Db111101111) --> 15
    =C2=A0 =C2=A01 1 1 1 1 0 1 1 1 ( 479=3D=3D0x1df=3D=3Db111011111) -->= ; 15

    SHUFFLE: =C2=A0[15, 14, 12, 8,= 0, 0, 1, 3, 7, 15, 14, 13, 11, 7, 15, 15]

    =3D=3D=3D Step b.

    CHANNELS = is a macHoppingSequenceLength-sized array that is initially populated w
    ith the monotonically i= ncreasing list of channels available to the PHY.

    CHANNELS: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, = 15]

    =3D=3D=3D Step c.
    <= div>
    CHANNELS is shuffled as per Figure 7a. Elements= may wind up being swapped multip
    le times in this process.

    macHoppingSequenceList: [5, 6, 12, 7, 15, 4, 14, 11, 8, 0, 1, 2, 13, 3, 9, 1= 0]


    Script ended normally, press Enter t= o close.

    On Friday, November 7, 2014, Xavier Vil= ajosana <xvilajosana@eecs.berkeley.edu> wrote:
    Dear Kees,
    thanks for your comments.=C2=A0

    answering 1)
    IMHO the fact that if default ch. hoppi= ng sequence is being used may not be advertised in the EB it is not = clear in the standard. And therefore I opted to make the EB explicit (even = only an ID and this being the default)
    Page 11 of the 15.4e amend= ment indicates that:

    All hopping sequences are = referred to by an ID, macHoppingSequenceID, with ID =3D 0 denoting the defa= ult
    sequence for a particular PHY (or PHY configuration if= the PHY supports more than one channel list).

    then page 92
    The full Hopping Sequence may be omitted to ensu= re that the frame does not exceed aMaxPHYPacketSize.
    In th= is case only the Hopping Sequence ID is carried, and the length of the IE i= s 1 octet. When the length is
    not equal to one, the additi= onal fields are present. The element varies in length depending upon the
    numberOfChannels in use by the PHY. The channelPage and numb= erOfChannels attributes can be used to
    determine the size = of the extendedBitmap, and the macHoppingSequenceLength can be used to dete= rmine
    the size of the macHoppingSequenceList.
    The Channel Hopping IE may be used by any channel hopping PAN t= o synchronize devices.

    My last po= int here is that this may=C2=A0might indicate optionality but the ca= se for the default id is not mentioned so I am not sure it can be elided if= default id (0)

    answering 2) it seems a good point= . Let us think about it.

    regards,
    Xavi

    2014-11= -07 9:57 GMT+01:00 Kees Trommel <ctrommel@aimvalley= .nl>:
    =20 =20 =20
    Hi,

    This draft specifies that the enhanced beacon should include a Channel Hopping IE with a Hopping Sequence ID equal to 0. Hopping Sequence ID 0 is the default hopping sequence ID. So the actual hopping sequence will not be included in the enhanced beacon.

    Section 5.1.1a of the IEE802.25.4e standard defines an algorithm to calculate a default hopping sequence ID.

    I have the following questions regarding the default hopping sequence:

    1. Is it the intention that a minimal configuration uses the default hopping sequence as defined in the IEE802.25.4e standard?
    2. If the answer on 1. is yes:=C2=A0 The definition of the IEE802.25.4e hopping sequence (in my opinion) is not unambiguous, so can you add the actual default hopping sequence to this draft?

    Regards,

    Kees.

    On Oct 27, 2014, at 12:20 AM, Xavier Vilajosana <xvilajosana at eecs.berkeley.edu> wrote:

    All, I just published the new version of minimal. It includes a security section as discussed last call and some changes to the default timing to be according to 15.4 tsch default values.

    regards,
    Xavi

    ---------- Forwarded message ----------
    From: <internet-draf= ts at ietf.org>
    Date: 2014-10-27 5:17 GMT+01:00
    Subject: [6tisch] I-D Action: draft-ietf-6tisch-minimal-03.txt
    To: i-d-announce at ietf.org
    Cc: 6tisch at ietf.org



    A New Internet-Draft is available from the on-line Internet-Drafts directories.
    =C2=A0This draft is a work item of the IPv6 over the TSCH mod= e of IEEE 802.15.4e Working Group of the IETF.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0: Minimal 6TiSCH Configuration
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: Xavier Vilajosana
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Kris Pister
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2= =A0 : draft-ietf-6tisch-minimal-03.txt
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0: 22
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 : 2014-10-26

    Abstract:
    =C2=A0 =C2=A0This document describes the minimal set of rules= to operate a
    =C2=A0 =C2=A0[IEEE802154e] Timeslotted Channel Hopping (TSCH) network.=C2=A0 This
    =C2=A0 =C2=A0minimal mode of operation can be used during net= work bootstrap, as a
    =C2=A0 =C2=A0fall-back mode of operation when no dynamic sche= duling solution is
    =C2=A0 =C2=A0available or functioning, or during early interoperability testing
    =C2=A0 =C2=A0and development.


    The IETF datatracker status page for this draft is:
    https://datatracker.ietf.org/= doc/draft-ietf-6tisch-minimal/

    There's also a htmlized version available at:
    http://tools.ietf.org/html/draft-= ietf-6tisch-minimal-03

    A diff from the previous version is available at:
    http://www.ietf.org/rfcd= iff?url2=3Ddraft-ietf-6tisch-minimal-03


    Please note that it may take a couple of minutes from the time of submission
    until the htmlized version and diff are available at tools.ietf.= org.

    Internet-Drafts are also available by anonymous FTP at:
    ftp://ftp.ietf.org/internet-drafts/

    _______________________________________________
    6tisch mailing list
    6tisch at ietf.org
    https://www.ietf.org/mailman/listinfo/6tisch=

    _______________________________________________
    6tisch mailing list
    6tisch at ietf.org
    https://www.ietf.org/mailman/listinfo/6tisch=


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


    --047d7b5d5942d103c80507756da4-- From nobody Mon Nov 10 02:11:15 2014 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE781A899A for <6tisch@ietfa.amsl.com>; Mon, 10 Nov 2014 02:11:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.919 X-Spam-Level: X-Spam-Status: No, score=0.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rGAkSbfkCIRf for <6tisch@ietfa.amsl.com>; Mon, 10 Nov 2014 02:11:04 -0800 (PST) Received: from jan.eatserver.nl (jan.eatserver.nl [IPv6:2001:67c:28fc:195:20:9:89:0]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 356531A886A for <6tisch@ietf.org>; Mon, 10 Nov 2014 02:11:03 -0800 (PST) Received: from [195.242.97.150] (qore.networks.above.net [195.242.97.150] (may be forged)) (authenticated bits=0) by jan.eatserver.nl (8.13.8/8.13.8) with ESMTP id sAAAAsbt023721 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 10 Nov 2014 11:10:55 +0100 Received: from localhost (localhost.localhost [127.0.0.1]) by router38.aimvalley.nl (Postfix) with ESMTP id DF3EE818102; Mon, 10 Nov 2014 11:10:54 +0100 (CET) X-Virus-Scanned: by Endian Firewall X-Spam-CTCH-RefID: Received: from mail3.aimsys.nl (mail.aimsys.nl [10.10.0.114]) by router38.aimvalley.nl (Postfix) with ESMTP id 3AC1F818103; Mon, 10 Nov 2014 11:10:51 +0100 (CET) Received: from linpc176.aimsys.nl (linpc176.aimsys.nl [10.10.8.76]) by mail3.aimsys.nl (8.14.2/8.14.2) with ESMTP id sAAAAorO027304; Mon, 10 Nov 2014 11:10:51 +0100 Message-ID: <54608F2A.7090708@aimvalley.nl> Date: Mon, 10 Nov 2014 11:10:50 +0100 From: Kees Trommel User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Thomas Watteyne , Xavier Vilajosana References: <545C898A.8060300@aimvalley.nl> In-Reply-To: Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch/ZgHvt9x_Cu5mMCctN2JBDNf2U3Y Cc: "6tisch@ietf.org" <6tisch@ietf.org> Subject: Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-03.txt X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 10:11:13 -0000
    Thomas, Xavi,

    Thanks, I cannot find anything in this script that would violate the IEEE802.15.4e standard.

    In this script you made the assumption that the hopping sequence length is equal to the number of channels. I think this is reasonable assumption but it is not defined in the IEEE802.15.4e standard, so it would be good idea to put this assumption in the draft too.

    You are using channel numbers 0 - 15 and I assume that these are the 16 2.5GHz channels. The IEEE802.15.4e standard define these as channel numbers 11 - 26 of page 0. It is fine for me to keep the 0 - 15 channel numbering scheme but it would good to mention this too. What about (future) support of other channels and pages defined in the IEEE802.15.4e standard?

    Kees.

    On 11/10/14 00:29, Thomas Watteyne wrote:
    Kees, Xavi,

    If the default hopping sequence isn't clear in IEEE802.15.4e-2012, this is important information to the fed back to the IEEE802.15.4 TG. @PatKinney, maybe you can chime in on whether the related text will be changed in IEEE802.15.4-2015?

    In any case, let's disambiguate the hopping sequence on this thread. We could add an example in draft-ietf-6tisch-minimal, and maybe ask IEEE802.15.4 to do the same.

    I have created some quick Python code which I believe calculates the default hopping sequence, see https://gist.github.com/twatteyne/2e22ee3c1a802b685695.

    Could someone (Pat? Jonathan?) double-check that it computes the right sequence. I'm copy-pasting the output below.

    Thomas

    ---

    This script calculates the default channel hopping sequence for the
    IEEE802.15.4e-2012 TSCH mode.

    \author Thomas Watteyne
    \date November 2014


    === Step a.

    SHUFFLE is a macHoppingSequenceLength-sized array. The contents of this array ar
    e equivalent to the first macHoppingSequenceLength outputs of a 9-bit linear fee
    dback shift register (LFSR) with polynomial x9 + x5 + 1 and a starting seed of 2
    55. Each LFSR output is modulo macHoppingSequenceLength, so that each entry of S
    HUFFLE is between 0 and (macHoppingSequenceLength - 1), inclusive.

               5       9
       1 1 1 1 1 1 1 1 0 ( 255==0x0ff==b011111111)
       1 1 1 1 1 1 1 1 1 ( 511==0x1ff==b111111111) --> 15
       0 1 1 1 1 1 1 1 1 ( 510==0x1fe==b111111110) --> 14
       0 0 1 1 1 1 1 1 1 ( 508==0x1fc==b111111100) --> 12
       0 0 0 1 1 1 1 1 1 ( 504==0x1f8==b111111000) --> 8
       0 0 0 0 1 1 1 1 1 ( 496==0x1f0==b111110000) --> 0
       0 0 0 0 0 1 1 1 1 ( 480==0x1e0==b111100000) --> 0
       1 0 0 0 0 0 1 1 1 ( 449==0x1c1==b111000001) --> 1
       1 1 0 0 0 0 0 1 1 ( 387==0x183==b110000011) --> 3
       1 1 1 0 0 0 0 0 1 ( 263==0x107==b100000111) --> 7
       1 1 1 1 0 0 0 0 0 (  15==0x00f==b000001111) --> 15
       0 1 1 1 1 0 0 0 0 (  30==0x01e==b000011110) --> 14
       1 0 1 1 1 1 0 0 0 (  61==0x03d==b000111101) --> 13
       1 1 0 1 1 1 1 0 0 ( 123==0x07b==b001111011) --> 11
       1 1 1 0 1 1 1 1 0 ( 247==0x0f7==b011110111) --> 7
       1 1 1 1 0 1 1 1 1 ( 495==0x1ef==b111101111) --> 15
       1 1 1 1 1 0 1 1 1 ( 479==0x1df==b111011111) --> 15

    SHUFFLE:  [15, 14, 12, 8, 0, 0, 1, 3, 7, 15, 14, 13, 11, 7, 15, 15]

    === Step b.

    CHANNELS is a macHoppingSequenceLength-sized array that is initially populated w
    ith the monotonically increasing list of channels available to the PHY.

    CHANNELS: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15]

    === Step c.

    CHANNELS is shuffled as per Figure 7a. Elements may wind up being swapped multip
    le times in this process.

    macHoppingSequenceList: [5, 6, 12, 7, 15, 4, 14, 11, 8, 0, 1, 2, 13, 3, 9, 10]


    Script ended normally, press Enter to close.

    On Friday, November 7, 2014, Xavier Vilajosana <xvilajosana@eecs.berkeley.edu> wrote:
    Dear Kees,
    thanks for your comments. 

    answering 1)
    IMHO the fact that if default ch. hopping sequence is being used may not be advertised in the EB it is not clear in the standard. And therefore I opted to make the EB explicit (even only an ID and this being the default)
    Page 11 of the 15.4e amendment indicates that:

    All hopping sequences are referred to by an ID, macHoppingSequenceID, with ID = 0 denoting the default
    sequence for a particular PHY (or PHY configuration if the PHY supports more than one channel list).

    then page 92
    The full Hopping Sequence may be omitted to ensure that the frame does not exceed aMaxPHYPacketSize.
    In this case only the Hopping Sequence ID is carried, and the length of the IE is 1 octet. When the length is
    not equal to one, the additional fields are present. The element varies in length depending upon the
    numberOfChannels in use by the PHY. The channelPage and numberOfChannels attributes can be used to
    determine the size of the extendedBitmap, and the macHoppingSequenceLength can be used to determine
    the size of the macHoppingSequenceList.
    The Channel Hopping IE may be used by any channel hopping PAN to synchronize devices.

    My last point here is that this may might indicate optionality but the case for the default id is not mentioned so I am not sure it can be elided if default id (0)

    answering 2) it seems a good point. Let us think about it.

    regards,
    Xavi

    2014-11-07 9:57 GMT+01:00 Kees Trommel <ctrommel@aimvalley.nl>:
    Hi,

    This draft specifies that the enhanced beacon should include a Channel Hopping IE with a Hopping Sequence ID equal to 0. Hopping Sequence ID 0 is the default hopping sequence ID. So the actual hopping sequence will not be included in the enhanced beacon.

    Section 5.1.1a of the IEE802.25.4e standard defines an algorithm to calculate a default hopping sequence ID.

    I have the following questions regarding the default hopping sequence:

    1. Is it the intention that a minimal configuration uses the default hopping sequence as defined in the IEE802.25.4e standard?
    2. If the answer on 1. is yes:  The definition of the IEE802.25.4e hopping sequence (in my opinion) is not unambiguous, so can you add the actual default hopping sequence to this draft?

    Regards,

    Kees.

    On Oct 27, 2014, at 12:20 AM, Xavier Vilajosana <xvilajosana at eecs.berkeley.edu> wrote:

    All, I just published the new version of minimal. It includes a security section as discussed last call and some changes to the default timing to be according to 15.4 tsch default values.

    regards,
    Xavi

    ---------- Forwarded message ----------
    From: <internet-drafts at ietf.org>
    Date: 2014-10-27 5:17 GMT+01:00
    Subject: [6tisch] I-D Action: draft-ietf-6tisch-minimal-03.txt
    To: i-d-announce at ietf.org
    Cc: 6tisch at ietf.org



    A New Internet-Draft is available from the on-line Internet-Drafts directories.
     This draft is a work item of the IPv6 over the TSCH mode of IEEE 802.15.4e Working Group of the IETF.

            Title           : Minimal 6TiSCH Configuration
            Authors         : Xavier Vilajosana
                              Kris Pister
            Filename        : draft-ietf-6tisch-minimal-03.txt
            Pages           : 22
            Date            : 2014-10-26

    Abstract:
       This document describes the minimal set of rules to operate a
       [IEEE802154e] Timeslotted Channel Hopping (TSCH) network.  This
       minimal mode of operation can be used during network bootstrap, as a
       fall-back mode of operation when no dynamic scheduling solution is
       available or functioning, or during early interoperability testing
       and development.


    The IETF datatracker status page for this draft is:
    https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal/

    There's also a htmlized version available at:
    http://tools.ietf.org/html/draft-ietf-6tisch-minimal-03

    A diff from the previous version is available at:
    http://www.ietf.org/rfcdiff?url2=draft-ietf-6tisch-minimal-03


    Please note that it may take a couple of minutes from the time of submission
    until the htmlized version and diff are available at tools.ietf.org.

    Internet-Drafts are also available by anonymous FTP at:
    ftp://ftp.ietf.org/internet-drafts/

    _______________________________________________
    6tisch mailing list
    6tisch at ietf.org
    https://www.ietf.org/mailman/listinfo/6tisch

    _______________________________________________
    6tisch mailing list
    6tisch at ietf.org
    https://www.ietf.org/mailman/listinfo/6tisch


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



    From nobody Mon Nov 10 10:42:15 2014 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7A9D1A7028 for <6tisch@ietfa.amsl.com>; Mon, 10 Nov 2014 10:42:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4A93eAYi0B5D for <6tisch@ietfa.amsl.com>; Mon, 10 Nov 2014 10:42:10 -0800 (PST) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E3451A86E0 for <6tisch@ietf.org>; Mon, 10 Nov 2014 10:42:09 -0800 (PST) Received: by mail-pa0-f53.google.com with SMTP id kx10so8802222pab.12 for <6tisch@ietf.org>; Mon, 10 Nov 2014 10:42:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=BnMdKPMcO4vOHMP0XJ4+Rm2Vcj8DCvdzxz/lC+4Yh4E=; b=L933TO0+jnaollF6HewTV4rMr3SYc78SvxPzqCnUgzx1/MRhdxR9I3SCXpXij1Pd2t 5F9aUtUZI5Tmc2O8dlJ7pJaxUr7FCq6tIEMcqDRcRsq4W6bvzDtIFwNQdPmKk6wxhhpa nved4viwh36/YLzXq3Lrt2RmYbpOM3OAy04rCAPAsxl1RBYt15RaFtor3XfwAdFsD8DB UjtU7pu+eTBI7O92tT/5bTysHhvgHGvkwRbppgVvvvppVcKHcOZfeNuiLX1IREq4HQ2s iz5uq6Mzpsc4TFZnPawK3u0RJ0hdH0+ScAqsMiV0SyaIAwYpqbpx8aqBAJxGiwoVzZOP xsXg== X-Received: by 10.70.43.78 with SMTP id u14mr3688568pdl.166.1415644928218; Mon, 10 Nov 2014 10:42:08 -0800 (PST) MIME-Version: 1.0 Sender: twatteyne@gmail.com Received: by 10.66.88.42 with HTTP; Mon, 10 Nov 2014 10:41:48 -0800 (PST) In-Reply-To: <54608F2A.7090708@aimvalley.nl> References: <545C898A.8060300@aimvalley.nl> <54608F2A.7090708@aimvalley.nl> From: Thomas Watteyne Date: Mon, 10 Nov 2014 08:41:48 -1000 X-Google-Sender-Auth: 6kXVdbvnWNkhpnHUhab-RQwi6UU Message-ID: To: Kees Trommel Content-Type: multipart/alternative; boundary=047d7bfe9792131cd8050785851e Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch/8IeU8MmoaLEbu_ys5cRwWZ-CR0E Cc: "6tisch@ietf.org" <6tisch@ietf.org>, Xavier Vilajosana Subject: Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-03.txt X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 18:42:14 -0000 --047d7bfe9792131cd8050785851e Content-Type: text/plain; charset=UTF-8 Kees, In this script you made the assumption that the hopping sequence length is > equal to the number of channels. I think this is reasonable assumption but > it is not defined in the IEEE802.15.4e standard, so it would be good idea > to put this assumption in the draft too. Yes, that was my assumption in this code. You are using channel numbers 0 - 15 and I assume that these are the 16 > 2.5GHz channels. The IEEE802.15.4e standard define these as channel numbers > 11 - 26 of page 0. It is fine for me to keep the 0 - 15 channel numbering > scheme but it would good to mention this too. What about (future) support > of other channels and pages defined in the IEEE802.15.4e standard? Correct, you should add 11 to the channel numbers in the code to use channel numbers 11-26 in IEEE notation (2.405GHz-2.480GHz). AFAICT, there is nothing in the hopping sequence of IEEE802.15.4e-TSCH which prevents the use of (future) sets of channels. *@all*, what do others think? Are details about the hopping sequence something we need to add to draft-ietf-6tisch-minimal? Thomas On Mon, Nov 10, 2014 at 12:10 AM, Kees Trommel wrote: > Thomas, Xavi, > > Thanks, I cannot find anything in this script that would violate the > IEEE802.15.4e standard. > > In this script you made the assumption that the hopping sequence length is > equal to the number of channels. I think this is reasonable assumption but > it is not defined in the IEEE802.15.4e standard, so it would be good idea > to put this assumption in the draft too. > > You are using channel numbers 0 - 15 and I assume that these are the 16 > 2.5GHz channels. The IEEE802.15.4e standard define these as channel numbers > 11 - 26 of page 0. It is fine for me to keep the 0 - 15 channel numbering > scheme but it would good to mention this too. What about (future) support > of other channels and pages defined in the IEEE802.15.4e standard? > > Kees. > > > On 11/10/14 00:29, Thomas Watteyne wrote: > > Kees, Xavi, > > If the default hopping sequence isn't clear in IEEE802.15.4e-2012, this > is important information to the fed back to the IEEE802.15.4 TG. > *@PatKinney*, maybe you can chime in on whether the related text will be > changed in IEEE802.15.4-2015? > > In any case, let's disambiguate the hopping sequence on this thread. We > could add an example in draft-ietf-6tisch-minimal, and maybe ask > IEEE802.15.4 to do the same. > > I have created some quick Python code which I believe calculates the > default hopping sequence, see > https://gist.github.com/twatteyne/2e22ee3c1a802b685695. > > Could someone (*Pat*? *Jonathan*?) double-check that it computes the > right sequence. I'm copy-pasting the output below. > > Thomas > > --- > > This script calculates the default channel hopping sequence for the > IEEE802.15.4e-2012 TSCH mode. > > \author Thomas Watteyne > \date November 2014 > \license http://opensource.org/licenses/BSD-3-Clause > > > === Step a. > > SHUFFLE is a macHoppingSequenceLength-sized array. The contents of this > array ar > e equivalent to the first macHoppingSequenceLength outputs of a 9-bit > linear fee > dback shift register (LFSR) with polynomial x9 + x5 + 1 and a starting > seed of 2 > 55. Each LFSR output is modulo macHoppingSequenceLength, so that each > entry of S > HUFFLE is between 0 and (macHoppingSequenceLength - 1), inclusive. > > 5 9 > 1 1 1 1 1 1 1 1 0 ( 255==0x0ff==b011111111) > 1 1 1 1 1 1 1 1 1 ( 511==0x1ff==b111111111) --> 15 > 0 1 1 1 1 1 1 1 1 ( 510==0x1fe==b111111110) --> 14 > 0 0 1 1 1 1 1 1 1 ( 508==0x1fc==b111111100) --> 12 > 0 0 0 1 1 1 1 1 1 ( 504==0x1f8==b111111000) --> 8 > 0 0 0 0 1 1 1 1 1 ( 496==0x1f0==b111110000) --> 0 > 0 0 0 0 0 1 1 1 1 ( 480==0x1e0==b111100000) --> 0 > 1 0 0 0 0 0 1 1 1 ( 449==0x1c1==b111000001) --> 1 > 1 1 0 0 0 0 0 1 1 ( 387==0x183==b110000011) --> 3 > 1 1 1 0 0 0 0 0 1 ( 263==0x107==b100000111) --> 7 > 1 1 1 1 0 0 0 0 0 ( 15==0x00f==b000001111) --> 15 > 0 1 1 1 1 0 0 0 0 ( 30==0x01e==b000011110) --> 14 > 1 0 1 1 1 1 0 0 0 ( 61==0x03d==b000111101) --> 13 > 1 1 0 1 1 1 1 0 0 ( 123==0x07b==b001111011) --> 11 > 1 1 1 0 1 1 1 1 0 ( 247==0x0f7==b011110111) --> 7 > 1 1 1 1 0 1 1 1 1 ( 495==0x1ef==b111101111) --> 15 > 1 1 1 1 1 0 1 1 1 ( 479==0x1df==b111011111) --> 15 > > SHUFFLE: [15, 14, 12, 8, 0, 0, 1, 3, 7, 15, 14, 13, 11, 7, 15, 15] > > === Step b. > > CHANNELS is a macHoppingSequenceLength-sized array that is initially > populated w > ith the monotonically increasing list of channels available to the PHY. > > CHANNELS: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15] > > === Step c. > > CHANNELS is shuffled as per Figure 7a. Elements may wind up being > swapped multip > le times in this process. > > macHoppingSequenceList: *[5, 6, 12, 7, 15, 4, 14, 11, 8, 0, 1, 2, 13, 3, > 9, 10]* > > > Script ended normally, press Enter to close. > > On Friday, November 7, 2014, Xavier Vilajosana < > xvilajosana@eecs.berkeley.edu> wrote: > >> Dear Kees, >> thanks for your comments. >> >> answering 1) >> IMHO the fact that if default ch. hopping sequence is being used *may >> not be* advertised in the EB it is not clear in the standard. And >> therefore I opted to make the EB explicit (even only an ID and this being >> the default) >> Page 11 of the 15.4e amendment indicates that: >> >> *All hopping sequences are referred to by an ID, macHoppingSequenceID, >> with ID = 0 denoting the default* >> *sequence for a particular PHY (or PHY configuration if the PHY supports >> more than one channel list).* >> >> then page 92 >> *The full Hopping Sequence may be omitted to ensure that the frame does >> not exceed aMaxPHYPacketSize.* >> *In this case only the Hopping Sequence ID is carried, and the length of >> the IE is 1 octet. When the length is* >> *not equal to one, the additional fields are present. The element varies >> in length depending upon the* >> *numberOfChannels in use by the PHY. The channelPage and numberOfChannels >> attributes can be used to* >> *determine the size of the extendedBitmap, and the >> macHoppingSequenceLength can be used to determine* >> *the size of the macHoppingSequenceList.* >> *The Channel Hopping IE may be used by any channel hopping PAN to >> synchronize devices.* >> >> My last point here is that this *may* might indicate optionality but >> the case for the default id is not mentioned so I am not sure it can be >> elided if default id (0) >> >> answering 2) it seems a good point. Let us think about it. >> >> regards, >> Xavi >> >> 2014-11-07 9:57 GMT+01:00 Kees Trommel : >> >>> Hi, >>> >>> This draft specifies that the enhanced beacon should include a Channel >>> Hopping IE with a Hopping Sequence ID equal to 0. Hopping Sequence ID 0 is >>> the default hopping sequence ID. So the actual hopping sequence will not be >>> included in the enhanced beacon. >>> >>> Section 5.1.1a of the IEE802.25.4e standard defines an algorithm to >>> calculate a default hopping sequence ID. >>> >>> I have the following questions regarding the default hopping sequence: >>> >>> 1. Is it the intention that a minimal configuration uses the default >>> hopping sequence as defined in the IEE802.25.4e standard? >>> 2. If the answer on 1. is yes: The definition of the IEE802.25.4e >>> hopping sequence (in my opinion) is not unambiguous, so can you add the >>> actual default hopping sequence to this draft? >>> >>> Regards, >>> >>> Kees. >>> >>> On Oct 27, 2014, at 12:20 AM, Xavier Vilajosana >> eecs.berkeley.edu> wrote: >>> >>> All, I just published the new version of minimal. It includes a >>> security section as discussed last call and some changes to the default >>> timing to be according to 15.4 tsch default values. >>> >>> regards, >>> Xavi >>> >>> ---------- Forwarded message ---------- >>> From: >>> Date: 2014-10-27 5:17 GMT+01:00 >>> Subject: [6tisch] I-D Action: draft-ietf-6tisch-minimal-03.txt >>> To: i-d-announce at ietf.org >>> Cc: 6tisch at ietf.org >>> >>> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the IPv6 over the TSCH mode of IEEE >>> 802.15.4e Working Group of the IETF. >>> >>> Title : Minimal 6TiSCH Configuration >>> Authors : Xavier Vilajosana >>> Kris Pister >>> Filename : draft-ietf-6tisch-minimal-03.txt >>> Pages : 22 >>> Date : 2014-10-26 >>> >>> Abstract: >>> This document describes the minimal set of rules to operate a >>> [IEEE802154e] Timeslotted Channel Hopping (TSCH) network. This >>> minimal mode of operation can be used during network bootstrap, as a >>> fall-back mode of operation when no dynamic scheduling solution is >>> available or functioning, or during early interoperability testing >>> and development. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal/ >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-6tisch-minimal-03 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=draft-ietf-6tisch-minimal-03 >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> 6tisch mailing list >>> 6tisch at ietf.org >>> https://www.ietf.org/mailman/listinfo/6tisch >>> >>> _______________________________________________ >>> 6tisch mailing list >>> 6tisch at ietf.org >>> https://www.ietf.org/mailman/listinfo/6tisch >>> >>> >>> >>> _______________________________________________ >>> 6tisch mailing list >>> 6tisch@ietf.org >>> https://www.ietf.org/mailman/listinfo/6tisch >>> >>> >> > --047d7bfe9792131cd8050785851e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Kees,

    In this script you ma= de the assumption that the hopping sequence length is equal to the number o= f channels. I think this is reasonable assumption but it is not defined in = the IEEE802.15.4e standard, so it would be good idea to put this assumption= in the draft too.

    Yes, that was my assumpt= ion in this code.

    You are using channe= l numbers 0 - 15 and I assume that these are the 16 2.5GHz channels. The IE= EE802.15.4e standard define these as channel numbers 11 - 26 of page 0. It = is fine for me to keep the 0 - 15 channel numbering scheme but it would goo= d to mention this too. What about (future) support of other channels and pa= ges defined in the IEEE802.15.4e standard?

    = Correct, you should add 11 to the channel numbers in the code to use channe= l numbers 11-26 in IEEE notation (2.405GHz-2.480GHz). AFAICT, there is noth= ing in the hopping sequence of IEEE802.15.4e-TSCH which prevents the use of= (future) sets of channels.

    @all, what do o= thers think? Are details about the hopping sequence something we need to ad= d to draft-ietf-6tisch-minimal?

    Thomas
    <= br>
    On Mon, Nov = 10, 2014 at 12:10 AM, Kees Trommel <ctrommel@aimvalley.nl> wrote:
    =20 =20 =20
    Thomas, Xavi,

    Thanks, I cannot find anything in this script that would violate the IEEE802.15.4e standard.

    In this script you made the assumption that the hopping sequence length is equal to the number of channels. I think this is reasonable assumption but it is not defined in the IEEE802.15.4e standard, so it would be good idea to put this assumption in the draft too.

    You are using channel numbers 0 - 15 and I assume that these are the 16 2.5GHz channels. The IEEE802.15.4e standard define these as channel numbers 11 - 26 of page 0. It is fine for me to keep the 0 - 15 channel numbering scheme but it would good to mention this too. What about (future) support of other channels and pages defined in the IEEE802.15.4e standard?

    Kees.


    On 11/10/14 00:29, Thomas Watteyne wrote:
    Kees, Xavi,

    If the default hopping sequence isn't clear in IEEE802.15.4e-2012, this is important information to the fed back to the IEEE802.15.4 TG. @PatKinney, maybe you can chime in on whether the related text will be changed in IEEE802.15.4-2015?

    In any case, let's disambiguate the hopping sequence on this thread. We could add an example in draft-ietf-6tisch-minimal, and maybe ask IEEE802.15.4 to do the same.

    I have created some quick Python code which I believe calculates the default hopping sequence, see https://gi= st.github.com/twatteyne/2e22ee3c1a802b685695.

    Could someone (Pat? Jonathan?) double-check that it computes the right sequence. I'm copy-pasting the output below.

    Thomas

    ---

    This script calculates the default channel hopping sequence for the
    IEEE802.15.4e-2012 TSCH mode.

    \author Thomas Watteyne
    \date November 2014


    =3D=3D=3D Step a.

    SHUFFLE is a macHoppingSequenceLength-sized array. The contents of this array ar
    e equivalent to the first macHoppingSequenceLength outputs of a 9-bit linear fee
    dback shift register (LFSR) with polynomial x9 + x5 + 1 and a starting seed of 2
    55. Each LFSR output is modulo macHoppingSequenceLength, so that each entry of S
    HUFFLE is between 0 and (macHoppingSequenceLength - 1), inclusive.

    =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A05 =C2=A0 =C2=A0 =C2=A0 9
    =C2=A0 =C2=A01 1 1 1 1= 1 1 1 0 ( 255=3D=3D0x0ff=3D=3Db011111111)
    =C2=A0 =C2=A01 1 1 1 1= 1 1 1 1 ( 511=3D=3D0x1ff=3D=3Db111111111) --> 15
    =C2=A0 =C2=A00 1 1 1 1= 1 1 1 1 ( 510=3D=3D0x1fe=3D=3Db111111110) --> 14
    =C2=A0 =C2=A00 0 1 1 1= 1 1 1 1 ( 508=3D=3D0x1fc=3D=3Db111111100) --> 12
    =C2=A0 =C2=A00 0 0 1 1= 1 1 1 1 ( 504=3D=3D0x1f8=3D=3Db111111000) --> 8
    =C2=A0 =C2=A00 0 0 0 1= 1 1 1 1 ( 496=3D=3D0x1f0=3D=3Db111110000) --> 0
    =C2=A0 =C2=A00 0 0 0 0= 1 1 1 1 ( 480=3D=3D0x1e0=3D=3Db111100000) --> 0
    =C2=A0 =C2=A01 0 0 0 0= 0 1 1 1 ( 449=3D=3D0x1c1=3D=3Db111000001) --> 1
    =C2=A0 =C2=A01 1 0 0 0= 0 0 1 1 ( 387=3D=3D0x183=3D=3Db110000011) --> 3
    =C2=A0 =C2=A01 1 1 0 0= 0 0 0 1 ( 263=3D=3D0x107=3D=3Db100000111) --> 7
    =C2=A0 =C2=A01 1 1 1 0= 0 0 0 0 ( =C2=A015=3D=3D0x00f=3D=3Db000001111) --> 15
    =C2=A0 =C2=A00 1 1 1 1= 0 0 0 0 ( =C2=A030=3D=3D0x01e=3D=3Db000011110) --> 14
    =C2=A0 =C2=A01 0 1 1 1= 1 0 0 0 ( =C2=A061=3D=3D0x03d=3D=3Db000111101) --> 13
    =C2=A0 =C2=A01 1 0 1 1= 1 1 0 0 ( 123=3D=3D0x07b=3D=3Db001111011) --> 11
    =C2=A0 =C2=A01 1 1 0 1= 1 1 1 0 ( 247=3D=3D0x0f7=3D=3Db011110111) --> 7
    =C2=A0 =C2=A01 1 1 1 0= 1 1 1 1 ( 495=3D=3D0x1ef=3D=3Db111101111) --> 15
    =C2=A0 =C2=A01 1 1 1 1= 0 1 1 1 ( 479=3D=3D0x1df=3D=3Db111011111) --> 15

    SHUFFLE: =C2=A0[15, 14= , 12, 8, 0, 0, 1, 3, 7, 15, 14, 13, 11, 7, 15, 15]

    =3D=3D=3D Step b.

    CHANNELS is a macHoppingSequenceLength-sized array that is initially populated w
    ith the monotonically increasing list of channels available to the PHY.

    CHANNELS: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15]

    =3D=3D=3D Step c.

    CHANNELS is shuffled as per Figure 7a. Elements may wind up being swapped multip
    le times in this process.

    macHoppingSequenceList= : [5, 6, 12, 7, 15, 4, 14, 11, 8, 0, 1, 2, 13, 3, 9, 10]


    Script ended normally, press Enter to close.

    On Friday, November 7, 2014, Xavier Vilajosana <xvilajosana@eecs.berke= ley.edu> wrote:
    Dear Kees,
    thanks for your comments.=C2=A0

    answering 1)
    IMHO the fact that if default ch. hopping sequence is being used may not be advertised in the EB it is not clear in the standard. And therefore I opted to make the EB explicit (even only an ID and this being the default)
    Page 11 of the 15.4e amendment indicates that:

    All hopping sequences are referred to by an ID, macHoppingSequenceID, with ID =3D 0 denoting the default
    sequence for a particular PHY (or PHY configuration if the PHY supports more than one channel list).

    then page 92
    The full Hopping Sequence may be omitted to ensure that the frame does not exceed aMaxPHYPacketSize.
    In this case only the Hopping Sequence ID is carried, and the length of the IE is 1 octet. When the length is
    not equal to one, the additional fields are present. The element varies in length depending upon the
    numberOfChannels in use by the PHY. The channelPage and numberOfChannels attributes can be used to
    determine the size of the extendedBitmap, and the macHoppingSequenceLength can be used to determine
    the size of the macHoppingSequenceList.
    The Channel Hopping IE may be used by any channel hopping PAN to synchronize devices.

    My last point here is that this may=C2=A0might indicate optionality but the case for the default id is not mentioned so I am not sure it can be elided if default id (0)

    answering 2) it seems a good point. Let us think about it.

    regards,
    Xavi

    2014-11-07 9:57 GMT+01:00 Kees Trommel <ctrommel@aimvalley.nl&= gt;:
    Hi,

    This draft specifies that the enhanced beacon should include a Channel Hopping IE with a Hopping Sequence ID equal to 0. Hopping Sequence ID 0 is the default hopping sequence ID. So the actual hopping sequence will not be included in the enhanced beacon.

    Section 5.1.1a of the IEE802.25.4e standard defines an algorithm to calculate a default hopping sequence ID.

    I have the following questions regarding the default hopping sequence:

    1. Is it the intention that a minimal configuration uses the default hopping sequence as defined in the IEE802.25.4e standard?
    2. If the answer on 1. is yes:=C2=A0 The definition of the IEE802.25.4e hopping sequence (in my opinion) is not unambiguous, so can you add the actual default hopping sequence to this draft?

    Regards,

    Kees.

    On Oct 27, 2014, at 12:20 AM, Xavier Vilajosana <xvilajosana at eecs.berkeley.edu> wrote:

    All, I just published the new version of minimal. It includes a security section as discussed last call and some changes to the default timing to be according to 15.4 tsch default values.

    regards,
    Xavi

    ---------- Forwarded message ----------
    From: <internet-drafts at ietf.org>
    Date: 2014-10-27 5:17 GMT+01:00
    Subject: [6tisch] I-D Action: draft-ietf-6tisch-minimal-03.txt
    To: i-d-announce at ietf.org
    Cc: 6tisch at ietf.or= g



    A New Internet-Draft is available from the on-line Internet-Drafts directories.
    =C2=A0This draft is a work item of the IP= v6 over the TSCH mode of IEEE 802.15.4e Working Group of the IETF.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Minimal 6TiSCH Configuration
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0: Xavier Vilajosana
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Kris Pister
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2= =A0 =C2=A0 =C2=A0 =C2=A0 : draft-ietf-6tisch-minimal-03.txt
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: 22
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 2014-10-26

    Abstract:
    =C2=A0 =C2=A0This document describes the = minimal set of rules to operate a
    =C2=A0 =C2=A0[IEEE802154e] Timeslotted Ch= annel Hopping (TSCH) network.=C2=A0 This
    =C2=A0 =C2=A0minimal mode of operation ca= n be used during network bootstrap, as a
    =C2=A0 =C2=A0fall-back mode of operation = when no dynamic scheduling solution is
    =C2=A0 =C2=A0available or functioning, or= during early interoperability testing
    =C2=A0 =C2=A0and development.


    The IETF datatracker status page for this draft is:
    https://d= atatracker.ietf.org/doc/draft-ietf-6tisch-minimal/

    There's also a htmlized version available at:
    http://tools.= ietf.org/html/draft-ietf-6tisch-minimal-03

    A diff from the previous version is available at:
    http:= //www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6tisch-minimal-03


    Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

    Internet-Drafts are also available by anonymous FTP at:
    ftp://ftp.ietf.org/internet-draft= s/

    _______________________________________________
    6tisch mailing list
    6tisch at ietf.org
    https://www.ietf.org/mai= lman/listinfo/6tisch

    ______________________________________= _________
    6tisch mailing list
    6tisch at ietf.org
    https://www.ietf.org/mai= lman/listinfo/6tisch


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




    --047d7bfe9792131cd8050785851e-- From nobody Mon Nov 10 12:15:35 2014 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFF4E1ACDB1 for <6tisch@ietfa.amsl.com>; Mon, 10 Nov 2014 12:15:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RRsePaPS5Y-8 for <6tisch@ietfa.amsl.com>; Mon, 10 Nov 2014 12:15:30 -0800 (PST) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC6001ACDE8 for <6tisch@ietf.org>; Mon, 10 Nov 2014 12:15:29 -0800 (PST) Received: by mail-ig0-f175.google.com with SMTP id h3so17285229igd.2 for <6tisch@ietf.org>; Mon, 10 Nov 2014 12:15:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=hxb+WlV8xitEyH/MvZQfbueia9eMJOhrXrer5WWd+AQ=; b=WTX/cmNlHJbP+MqAeYhjqnR4CeeH/TtEw7ZVo5e8Z6FYZazNAVdR6R4xs7p8ytCq4w OLR6yueR6dcOjn42Bd2PpP9sq/uFatqG7KpLu3Z+jwdEj3l1bjNI1EoWUex2O8Br2aI3 VuOWmX/1ujGH4F2VlUNUrBmMxxBjziEYyaQmkbeh8V+I1tJpiAqm3y4u6C7iuIMtLd32 3kb43K4pAZ6M9+vUxuccMD5Zi7pHKEhIaT/sHBVcfpbiCCGxwJ+YfI2M+s4I6j1XqGMH Vq6iF+8UdmyMtyNqoHWHba4ZnZ/32zyl5V5DLbwePcX/h90WlFa4AbH7bzf3ldj5Z7YA dqVA== MIME-Version: 1.0 X-Received: by 10.43.76.67 with SMTP id zd3mr39050480icb.42.1415650529026; Mon, 10 Nov 2014 12:15:29 -0800 (PST) Sender: xvilajosana@gmail.com Received: by 10.64.125.162 with HTTP; Mon, 10 Nov 2014 12:15:28 -0800 (PST) In-Reply-To: References: <545C898A.8060300@aimvalley.nl> <54608F2A.7090708@aimvalley.nl> Date: Mon, 10 Nov 2014 21:15:28 +0100 X-Google-Sender-Auth: CRziNZaOwemHLZPieGDGMMtt_OA Message-ID: From: Xavier Vilajosana To: Thomas Watteyne Content-Type: multipart/alternative; boundary=001a11c31e0ce8aa4e050786d206 Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch/SgGmH7ARSTZHsXy1iW1mrTKKq9g Cc: Kees Trommel , "6tisch@ietf.org" <6tisch@ietf.org> Subject: Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-03.txt X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 20:15:34 -0000 --001a11c31e0ce8aa4e050786d206 Content-Type: text/plain; charset=UTF-8 Hi, my 5 cents. After thinking about it I am in favour of adding the example as the draft will be more self-contained and will facilitate the understanding of how ch. hopping sequence is caluclated. (analogously to the OF0 example). regards, Xavi 2014-11-10 19:41 GMT+01:00 Thomas Watteyne : > Kees, > > In this script you made the assumption that the hopping sequence length is >> equal to the number of channels. I think this is reasonable assumption but >> it is not defined in the IEEE802.15.4e standard, so it would be good idea >> to put this assumption in the draft too. > > > Yes, that was my assumption in this code. > > You are using channel numbers 0 - 15 and I assume that these are the 16 >> 2.5GHz channels. The IEEE802.15.4e standard define these as channel numbers >> 11 - 26 of page 0. It is fine for me to keep the 0 - 15 channel numbering >> scheme but it would good to mention this too. What about (future) support >> of other channels and pages defined in the IEEE802.15.4e standard? > > > Correct, you should add 11 to the channel numbers in the code to use > channel numbers 11-26 in IEEE notation (2.405GHz-2.480GHz). AFAICT, there > is nothing in the hopping sequence of IEEE802.15.4e-TSCH which prevents the > use of (future) sets of channels. > > *@all*, what do others think? Are details about the hopping sequence > something we need to add to draft-ietf-6tisch-minimal? > > Thomas > > On Mon, Nov 10, 2014 at 12:10 AM, Kees Trommel > wrote: > >> Thomas, Xavi, >> >> Thanks, I cannot find anything in this script that would violate the >> IEEE802.15.4e standard. >> >> In this script you made the assumption that the hopping sequence length >> is equal to the number of channels. I think this is reasonable assumption >> but it is not defined in the IEEE802.15.4e standard, so it would be good >> idea to put this assumption in the draft too. >> >> You are using channel numbers 0 - 15 and I assume that these are the 16 >> 2.5GHz channels. The IEEE802.15.4e standard define these as channel numbers >> 11 - 26 of page 0. It is fine for me to keep the 0 - 15 channel numbering >> scheme but it would good to mention this too. What about (future) support >> of other channels and pages defined in the IEEE802.15.4e standard? >> >> Kees. >> >> >> On 11/10/14 00:29, Thomas Watteyne wrote: >> >> Kees, Xavi, >> >> If the default hopping sequence isn't clear in IEEE802.15.4e-2012, this >> is important information to the fed back to the IEEE802.15.4 TG. >> *@PatKinney*, maybe you can chime in on whether the related text will be >> changed in IEEE802.15.4-2015? >> >> In any case, let's disambiguate the hopping sequence on this thread. We >> could add an example in draft-ietf-6tisch-minimal, and maybe ask >> IEEE802.15.4 to do the same. >> >> I have created some quick Python code which I believe calculates the >> default hopping sequence, see >> https://gist.github.com/twatteyne/2e22ee3c1a802b685695. >> >> Could someone (*Pat*? *Jonathan*?) double-check that it computes the >> right sequence. I'm copy-pasting the output below. >> >> Thomas >> >> --- >> >> This script calculates the default channel hopping sequence for the >> IEEE802.15.4e-2012 TSCH mode. >> >> \author Thomas Watteyne >> \date November 2014 >> \license http://opensource.org/licenses/BSD-3-Clause >> >> >> === Step a. >> >> SHUFFLE is a macHoppingSequenceLength-sized array. The contents of this >> array ar >> e equivalent to the first macHoppingSequenceLength outputs of a 9-bit >> linear fee >> dback shift register (LFSR) with polynomial x9 + x5 + 1 and a starting >> seed of 2 >> 55. Each LFSR output is modulo macHoppingSequenceLength, so that each >> entry of S >> HUFFLE is between 0 and (macHoppingSequenceLength - 1), inclusive. >> >> 5 9 >> 1 1 1 1 1 1 1 1 0 ( 255==0x0ff==b011111111) >> 1 1 1 1 1 1 1 1 1 ( 511==0x1ff==b111111111) --> 15 >> 0 1 1 1 1 1 1 1 1 ( 510==0x1fe==b111111110) --> 14 >> 0 0 1 1 1 1 1 1 1 ( 508==0x1fc==b111111100) --> 12 >> 0 0 0 1 1 1 1 1 1 ( 504==0x1f8==b111111000) --> 8 >> 0 0 0 0 1 1 1 1 1 ( 496==0x1f0==b111110000) --> 0 >> 0 0 0 0 0 1 1 1 1 ( 480==0x1e0==b111100000) --> 0 >> 1 0 0 0 0 0 1 1 1 ( 449==0x1c1==b111000001) --> 1 >> 1 1 0 0 0 0 0 1 1 ( 387==0x183==b110000011) --> 3 >> 1 1 1 0 0 0 0 0 1 ( 263==0x107==b100000111) --> 7 >> 1 1 1 1 0 0 0 0 0 ( 15==0x00f==b000001111) --> 15 >> 0 1 1 1 1 0 0 0 0 ( 30==0x01e==b000011110) --> 14 >> 1 0 1 1 1 1 0 0 0 ( 61==0x03d==b000111101) --> 13 >> 1 1 0 1 1 1 1 0 0 ( 123==0x07b==b001111011) --> 11 >> 1 1 1 0 1 1 1 1 0 ( 247==0x0f7==b011110111) --> 7 >> 1 1 1 1 0 1 1 1 1 ( 495==0x1ef==b111101111) --> 15 >> 1 1 1 1 1 0 1 1 1 ( 479==0x1df==b111011111) --> 15 >> >> SHUFFLE: [15, 14, 12, 8, 0, 0, 1, 3, 7, 15, 14, 13, 11, 7, 15, 15] >> >> === Step b. >> >> CHANNELS is a macHoppingSequenceLength-sized array that is initially >> populated w >> ith the monotonically increasing list of channels available to the PHY. >> >> CHANNELS: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15] >> >> === Step c. >> >> CHANNELS is shuffled as per Figure 7a. Elements may wind up being >> swapped multip >> le times in this process. >> >> macHoppingSequenceList: *[5, 6, 12, 7, 15, 4, 14, 11, 8, 0, 1, 2, 13, >> 3, 9, 10]* >> >> >> Script ended normally, press Enter to close. >> >> On Friday, November 7, 2014, Xavier Vilajosana < >> xvilajosana@eecs.berkeley.edu> wrote: >> >>> Dear Kees, >>> thanks for your comments. >>> >>> answering 1) >>> IMHO the fact that if default ch. hopping sequence is being used *may >>> not be* advertised in the EB it is not clear in the standard. And >>> therefore I opted to make the EB explicit (even only an ID and this being >>> the default) >>> Page 11 of the 15.4e amendment indicates that: >>> >>> *All hopping sequences are referred to by an ID, macHoppingSequenceID, >>> with ID = 0 denoting the default* >>> *sequence for a particular PHY (or PHY configuration if the PHY supports >>> more than one channel list).* >>> >>> then page 92 >>> *The full Hopping Sequence may be omitted to ensure that the frame does >>> not exceed aMaxPHYPacketSize.* >>> *In this case only the Hopping Sequence ID is carried, and the length of >>> the IE is 1 octet. When the length is* >>> *not equal to one, the additional fields are present. The element varies >>> in length depending upon the* >>> *numberOfChannels in use by the PHY. The channelPage and >>> numberOfChannels attributes can be used to* >>> *determine the size of the extendedBitmap, and the >>> macHoppingSequenceLength can be used to determine* >>> *the size of the macHoppingSequenceList.* >>> *The Channel Hopping IE may be used by any channel hopping PAN to >>> synchronize devices.* >>> >>> My last point here is that this *may* might indicate optionality but >>> the case for the default id is not mentioned so I am not sure it can be >>> elided if default id (0) >>> >>> answering 2) it seems a good point. Let us think about it. >>> >>> regards, >>> Xavi >>> >>> 2014-11-07 9:57 GMT+01:00 Kees Trommel : >>> >>>> Hi, >>>> >>>> This draft specifies that the enhanced beacon should include a Channel >>>> Hopping IE with a Hopping Sequence ID equal to 0. Hopping Sequence ID 0 is >>>> the default hopping sequence ID. So the actual hopping sequence will not be >>>> included in the enhanced beacon. >>>> >>>> Section 5.1.1a of the IEE802.25.4e standard defines an algorithm to >>>> calculate a default hopping sequence ID. >>>> >>>> I have the following questions regarding the default hopping sequence: >>>> >>>> 1. Is it the intention that a minimal configuration uses the default >>>> hopping sequence as defined in the IEE802.25.4e standard? >>>> 2. If the answer on 1. is yes: The definition of the IEE802.25.4e >>>> hopping sequence (in my opinion) is not unambiguous, so can you add the >>>> actual default hopping sequence to this draft? >>>> >>>> Regards, >>>> >>>> Kees. >>>> >>>> On Oct 27, 2014, at 12:20 AM, Xavier Vilajosana >>> eecs.berkeley.edu> wrote: >>>> >>>> All, I just published the new version of minimal. It includes a >>>> security section as discussed last call and some changes to the default >>>> timing to be according to 15.4 tsch default values. >>>> >>>> regards, >>>> Xavi >>>> >>>> ---------- Forwarded message ---------- >>>> From: >>>> Date: 2014-10-27 5:17 GMT+01:00 >>>> Subject: [6tisch] I-D Action: draft-ietf-6tisch-minimal-03.txt >>>> To: i-d-announce at ietf.org >>>> Cc: 6tisch at ietf.org >>>> >>>> >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> This draft is a work item of the IPv6 over the TSCH mode of IEEE >>>> 802.15.4e Working Group of the IETF. >>>> >>>> Title : Minimal 6TiSCH Configuration >>>> Authors : Xavier Vilajosana >>>> Kris Pister >>>> Filename : draft-ietf-6tisch-minimal-03.txt >>>> Pages : 22 >>>> Date : 2014-10-26 >>>> >>>> Abstract: >>>> This document describes the minimal set of rules to operate a >>>> [IEEE802154e] Timeslotted Channel Hopping (TSCH) network. This >>>> minimal mode of operation can be used during network bootstrap, as a >>>> fall-back mode of operation when no dynamic scheduling solution is >>>> available or functioning, or during early interoperability testing >>>> and development. >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal/ >>>> >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-ietf-6tisch-minimal-03 >>>> >>>> A diff from the previous version is available at: >>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-6tisch-minimal-03 >>>> >>>> >>>> Please note that it may take a couple of minutes from the time of >>>> submission >>>> until the htmlized version and diff are available at tools.ietf.org. >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> _______________________________________________ >>>> 6tisch mailing list >>>> 6tisch at ietf.org >>>> https://www.ietf.org/mailman/listinfo/6tisch >>>> >>>> _______________________________________________ >>>> 6tisch mailing list >>>> 6tisch at ietf.org >>>> https://www.ietf.org/mailman/listinfo/6tisch >>>> >>>> >>>> >>>> _______________________________________________ >>>> 6tisch mailing list >>>> 6tisch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/6tisch >>>> >>>> >>> >> > --001a11c31e0ce8aa4e050786d206 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Hi,=C2=A0

    my 5 cents. After thinking ab= out it I am in favour of adding the example as the draft will be more self-= contained and will facilitate the understanding of how ch. hopping sequence= is caluclated. (analogously to the OF0 example).=C2=A0

    regards,
    Xavi

    2014-11-10 19:41 GMT+01:00 Thomas Watteyne <watteyne@eecs.berkeley.edu>:
    Kees,

    In this script you made the assumption that the hopping sequence length is= equal to the number of channels. I think this is reasonable assumption but= it is not defined in the IEEE802.15.4e standard, so it would be good idea = to put this assumption in the draft too.

    =
    Yes, that was my assumption in this code.
    <= br>
    You are using channel numbers 0 - 15 and I assume= that these are the 16 2.5GHz channels. The IEEE802.15.4e standard define t= hese as channel numbers 11 - 26 of page 0. It is fine for me to keep the 0 = - 15 channel numbering scheme but it would good to mention this too. What a= bout (future) support of other channels and pages defined in the IEEE802.15= .4e standard?

    Correct, you should ad= d 11 to the channel numbers in the code to use channel numbers 11-26 in IEE= E notation (2.405GHz-2.480GHz). AFAICT, there is nothing in the hopping seq= uence of IEEE802.15.4e-TSCH which prevents the use of (future) sets of chan= nels.

    @all, what do others think? Are detai= ls about the hopping sequence something we need to add to draft-ietf-6tisch= -minimal?

    Thomas

    On Mon, Nov 10, 2014 at 1= 2:10 AM, Kees Trommel <ctrommel@aimvalley.nl> wrote:
    =
    =20 =20 =20
    Thomas, Xavi,

    Thanks, I cannot find anything in this script that would violate the IEEE802.15.4e standard.

    In this script you made the assumption that the hopping sequence length is equal to the number of channels. I think this is reasonable assumption but it is not defined in the IEEE802.15.4e standard, so it would be good idea to put this assumption in the draft too.

    You are using channel numbers 0 - 15 and I assume that these are the 16 2.5GHz channels. The IEEE802.15.4e standard define these as channel numbers 11 - 26 of page 0. It is fine for me to keep the 0 - 15 channel numbering scheme but it would good to mention this too. What about (future) support of other channels and pages defined in the IEEE802.15.4e standard?<= br>
    Kees.


    On 11/10/14 00:29, Thomas Watteyne wrote:
    Kees, Xavi,

    If the default hopping sequence isn't clear in IEEE802.15.4e-2012, this is important information to the fed back to the IEEE802.15.4 TG. @PatKinney, maybe you can chime in on whether the related text will be changed in IEEE802.15.4-2015?

    In any case, let's disambiguate the hopping sequence on this thread. We could add an example in draft-ietf-6tisch-minimal, and maybe ask IEEE802.15.4 to do the same.

    I have created some quick Python code which I believe calculates the default hopping sequence, see https://gi= st.github.com/twatteyne/2e22ee3c1a802b685695.

    Could someone (Pat? Jonathan?) double-check that it computes the right sequence. I'm copy-pasting the output below.

    Thomas

    ---

    This script calculates the default channel hopping sequence for the
    IEEE802.15.4e-2012 TSCH mode.

    \author Thomas Watteyne
    \date November 2014


    =3D=3D=3D Step a.

    SHUFFLE is a macHoppingSequenceLength-sized array. The contents of this array ar
    e equivalent to the first macHoppingSequenceLength outputs of a 9-bit linear fee
    dback shift register (LFSR) with polynomial x9 + x5 + 1 and a starting seed of 2
    55. Each LFSR output is modulo macHoppingSequenceLength, so that each entry of S
    HUFFLE is between 0 and (macHoppingSequenceLength - 1), inclusive.

    =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A05 =C2=A0 =C2=A0 =C2=A0 9
    =C2=A0 =C2=A01 1 1 1 1= 1 1 1 0 ( 255=3D=3D0x0ff=3D=3Db011111111)
    =C2=A0 =C2=A01 1 1 1 1= 1 1 1 1 ( 511=3D=3D0x1ff=3D=3Db111111111) --> 15
    =C2=A0 =C2=A00 1 1 1 1= 1 1 1 1 ( 510=3D=3D0x1fe=3D=3Db111111110) --> 14
    =C2=A0 =C2=A00 0 1 1 1= 1 1 1 1 ( 508=3D=3D0x1fc=3D=3Db111111100) --> 12
    =C2=A0 =C2=A00 0 0 1 1= 1 1 1 1 ( 504=3D=3D0x1f8=3D=3Db111111000) --> 8
    =C2=A0 =C2=A00 0 0 0 1= 1 1 1 1 ( 496=3D=3D0x1f0=3D=3Db111110000) --> 0
    =C2=A0 =C2=A00 0 0 0 0= 1 1 1 1 ( 480=3D=3D0x1e0=3D=3Db111100000) --> 0
    =C2=A0 =C2=A01 0 0 0 0= 0 1 1 1 ( 449=3D=3D0x1c1=3D=3Db111000001) --> 1
    =C2=A0 =C2=A01 1 0 0 0= 0 0 1 1 ( 387=3D=3D0x183=3D=3Db110000011) --> 3
    =C2=A0 =C2=A01 1 1 0 0= 0 0 0 1 ( 263=3D=3D0x107=3D=3Db100000111) --> 7
    =C2=A0 =C2=A01 1 1 1 0= 0 0 0 0 ( =C2=A015=3D=3D0x00f=3D=3Db000001111) --> 15
    =C2=A0 =C2=A00 1 1 1 1= 0 0 0 0 ( =C2=A030=3D=3D0x01e=3D=3Db000011110) --> 14
    =C2=A0 =C2=A01 0 1 1 1= 1 0 0 0 ( =C2=A061=3D=3D0x03d=3D=3Db000111101) --> 13
    =C2=A0 =C2=A01 1 0 1 1= 1 1 0 0 ( 123=3D=3D0x07b=3D=3Db001111011) --> 11
    =C2=A0 =C2=A01 1 1 0 1= 1 1 1 0 ( 247=3D=3D0x0f7=3D=3Db011110111) --> 7
    =C2=A0 =C2=A01 1 1 1 0= 1 1 1 1 ( 495=3D=3D0x1ef=3D=3Db111101111) --> 15
    =C2=A0 =C2=A01 1 1 1 1= 0 1 1 1 ( 479=3D=3D0x1df=3D=3Db111011111) --> 15

    SHUFFLE: =C2=A0[15, 14= , 12, 8, 0, 0, 1, 3, 7, 15, 14, 13, 11, 7, 15, 15]

    =3D=3D=3D Step b.

    CHANNELS is a macHoppingSequenceLength-sized array that is initially populated w
    ith the monotonically increasing list of channels available to the PHY.

    CHANNELS: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15]

    =3D=3D=3D Step c.

    CHANNELS is shuffled as per Figure 7a. Elements may wind up being swapped multip
    le times in this process.

    macHoppingSequenceList= : [5, 6, 12, 7, 15, 4, 14, 11, 8, 0, 1, 2, 13, 3, 9, 10]


    Script ended normally, press Enter to close.

    On Friday, November 7, 2014, Xavier Vilajosana <xvilajosana@eecs.berke= ley.edu> wrote:
    Dear Kees,
    thanks for your comments.=C2=A0

    answering 1)
    IMHO the fact that if default ch. hopping sequence is being used may not be advertised in the EB it is not clear in the standard. And therefore I opted to make the EB explicit (even only an ID and this being the default)
    Page 11 of the 15.4e amendment indicates that:

    All hopping sequences are referred to by an ID, macHoppingSequenceID, with ID =3D 0 denoting the default
    sequence for a particular PHY (or PHY configuration if the PHY supports more than one channel list).

    then page 92
    The full Hopping Sequence may be omitted to ensure that the frame does not exceed aMaxPHYPacketSize.
    In this case only the Hopping Sequence ID is carried, and the length of the IE is 1 octet. When the length is
    not equal to one, the additional fields are present. The element varies in length depending upon the
    numberOfChannels in use by the PHY. The channelPage and numberOfChannels attributes can be used to
    determine the size of the extendedBitmap, and the macHoppingSequenceLength can be used to determine
    the size of the macHoppingSequenceList.
    The Channel Hopping IE may be used by any channel hopping PAN to synchronize devices.

    My last point here is that this may=C2=A0might indicate optionality but the case for the default id is not mentioned so I am not sure it can be elided if default id (0)

    answering 2) it seems a good point. Let us think about it.

    regards,
    Xavi

    2014-11-07 9:57 GMT+01:00 Kees Trommel <ctrommel@aimvalley.nl&= gt;:
    Hi,

    This draft specifies that the enhanced beacon should include a Channel Hopping IE with a Hopping Sequence ID equal to 0. Hopping Sequence ID 0 is the default hopping sequence ID. So the actual hopping sequence will not be included in the enhanced beacon.

    Section 5.1.1a of the IEE802.25.4e standard defines an algorithm to calculate a default hopping sequence ID.

    I have the following questions regarding the default hopping sequence:

    1. Is it the intention that a minimal configuration uses the default hopping sequence as defined in the IEE802.25.4e standard?
    2. If the answer on 1. is yes:=C2=A0 The definition of the IEE802.25.4e hopping sequence (in my opinion) is not unambiguous, so can you add the actual default hopping sequence to this draft?

    Regards,

    Kees.

    On Oct 27, 2014, at 12:20 AM, Xavier Vilajosana <xvilajosana at eecs.berkeley.edu> wrote:

    All, I just published the new version of minimal. It includes a security section as discussed last call and some changes to the default timing to be according to 15.4 tsch default values.

    regards,
    Xavi

    ---------- Forwarded message ----------
    From: <internet-drafts at ietf.org>
    Date: 2014-10-27 5:17 GMT+01:00
    Subject: [6tisch] I-D Action: draft-ietf-6tisch-minimal-03.txt
    To: i-d-announce at ietf.org
    Cc: 6tisch at ietf.or= g



    A New Internet-Draft is available from the on-line Internet-Drafts directories.
    =C2=A0This draft is a work item of the IP= v6 over the TSCH mode of IEEE 802.15.4e Working Group of the IETF.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Minimal 6TiSCH Configuration
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0: Xavier Vilajosana
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Kris Pister
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2= =A0 =C2=A0 =C2=A0 =C2=A0 : draft-ietf-6tisch-minimal-03.txt
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: 22
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 2014-10-26

    Abstract:
    =C2=A0 =C2=A0This document describes the = minimal set of rules to operate a
    =C2=A0 =C2=A0[IEEE802154e] Timeslotted Ch= annel Hopping (TSCH) network.=C2=A0 This
    =C2=A0 =C2=A0minimal mode of operation ca= n be used during network bootstrap, as a
    =C2=A0 =C2=A0fall-back mode of operation = when no dynamic scheduling solution is
    =C2=A0 =C2=A0available or functioning, or= during early interoperability testing
    =C2=A0 =C2=A0and development.


    The IETF datatracker status page for this draft is:
    https://d= atatracker.ietf.org/doc/draft-ietf-6tisch-minimal/

    There's also a htmlized version available at:
    http://tools.= ietf.org/html/draft-ietf-6tisch-minimal-03

    A diff from the previous version is available at:
    http:= //www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6tisch-minimal-03


    Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

    Internet-Drafts are also available by anonymous FTP at:
    ftp://ftp.ietf.org/internet-draft= s/

    _______________________________________________
    6tisch mailing list
    6tisch at ietf.org
    https://www.ietf.org/mai= lman/listinfo/6tisch

    ______________________________________= _________
    6tisch mailing list
    6tisch at ietf.org
    https://www.ietf.org/mai= lman/listinfo/6tisch


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





    --001a11c31e0ce8aa4e050786d206-- From nobody Mon Nov 10 12:17:56 2014 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76DEF1ACDF3 for <6tisch@ietfa.amsl.com>; Mon, 10 Nov 2014 12:17:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wR99Z9Qwdtcn for <6tisch@ietfa.amsl.com>; Mon, 10 Nov 2014 12:17:51 -0800 (PST) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9ABC1ACDEE for <6tisch@ietf.org>; Mon, 10 Nov 2014 12:17:50 -0800 (PST) Received: by mail-pa0-f47.google.com with SMTP id kx10so8972571pab.20 for <6tisch@ietf.org>; Mon, 10 Nov 2014 12:17:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=YvwSw37zNrdzIMgT8b64h9vKA+Min8PXAmxKkvP8wkU=; b=aBWN5uKIPR5Yq3IL3bJ1/6bI8JAlacnMtVDLfL0rlPF5D32U8JL2eQCM1n7pdQVu2p 109UJLh0QriFzZXNONxcUsWI3Mqi2XUH5xMoZ8CUk6TqIuGpGTjv3IMkMeaAyVEEhDIB tdBqGma4mxc/khq1K6gtVTyjGzHFJRtgs3hlfdPFfZMIplHQdbLeBKu6zUCz7Es8+gD6 K+r7xSvgA9hqhj6wb19M8wACatVWiPDy9z7qHl0xyBrUzjQb01RTSqqPdlW2c6FhojVR UnhrI7Cnvi9ZMBrRZuN8m/AXFmEJY/v01Hlm5oid2jPNAA+POvsGwuDg2kV3bayYj9Tc Vpyg== X-Received: by 10.70.45.40 with SMTP id j8mr7289408pdm.130.1415650670057; Mon, 10 Nov 2014 12:17:50 -0800 (PST) MIME-Version: 1.0 Sender: twatteyne@gmail.com Received: by 10.66.88.42 with HTTP; Mon, 10 Nov 2014 12:17:29 -0800 (PST) In-Reply-To: References: <545C898A.8060300@aimvalley.nl> <54608F2A.7090708@aimvalley.nl> From: Thomas Watteyne Date: Mon, 10 Nov 2014 10:17:29 -1000 X-Google-Sender-Auth: 2SIE9H8Prwtyc8IXTq56jYKeJmI Message-ID: To: Xavier Vilajosana Content-Type: multipart/alternative; boundary=047d7bf18b7650a089050786db34 Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch/2MIV0mWeBGu1vwF31NnCWmfP_WM Cc: Kees Trommel , "6tisch@ietf.org" <6tisch@ietf.org> Subject: Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-03.txt X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 20:17:55 -0000 --047d7bf18b7650a089050786db34 Content-Type: text/plain; charset=UTF-8 Quick thought: does this discussion fit in draft-ietf-6tisch-minimal or draft-ietf-6tisch-tsch? Both make sense to me. On Mon, Nov 10, 2014 at 10:15 AM, Xavier Vilajosana < xvilajosana@eecs.berkeley.edu> wrote: > Hi, > > my 5 cents. After thinking about it I am in favour of adding the example > as the draft will be more self-contained and will facilitate the > understanding of how ch. hopping sequence is caluclated. (analogously to > the OF0 example). > > regards, > Xavi > > 2014-11-10 19:41 GMT+01:00 Thomas Watteyne : > >> Kees, >> >> In this script you made the assumption that the hopping sequence length >>> is equal to the number of channels. I think this is reasonable assumption >>> but it is not defined in the IEEE802.15.4e standard, so it would be good >>> idea to put this assumption in the draft too. >> >> >> Yes, that was my assumption in this code. >> >> You are using channel numbers 0 - 15 and I assume that these are the 16 >>> 2.5GHz channels. The IEEE802.15.4e standard define these as channel numbers >>> 11 - 26 of page 0. It is fine for me to keep the 0 - 15 channel numbering >>> scheme but it would good to mention this too. What about (future) support >>> of other channels and pages defined in the IEEE802.15.4e standard? >> >> >> Correct, you should add 11 to the channel numbers in the code to use >> channel numbers 11-26 in IEEE notation (2.405GHz-2.480GHz). AFAICT, there >> is nothing in the hopping sequence of IEEE802.15.4e-TSCH which prevents the >> use of (future) sets of channels. >> >> *@all*, what do others think? Are details about the hopping sequence >> something we need to add to draft-ietf-6tisch-minimal? >> >> Thomas >> >> On Mon, Nov 10, 2014 at 12:10 AM, Kees Trommel >> wrote: >> >>> Thomas, Xavi, >>> >>> Thanks, I cannot find anything in this script that would violate the >>> IEEE802.15.4e standard. >>> >>> In this script you made the assumption that the hopping sequence length >>> is equal to the number of channels. I think this is reasonable assumption >>> but it is not defined in the IEEE802.15.4e standard, so it would be good >>> idea to put this assumption in the draft too. >>> >>> You are using channel numbers 0 - 15 and I assume that these are the 16 >>> 2.5GHz channels. The IEEE802.15.4e standard define these as channel numbers >>> 11 - 26 of page 0. It is fine for me to keep the 0 - 15 channel numbering >>> scheme but it would good to mention this too. What about (future) support >>> of other channels and pages defined in the IEEE802.15.4e standard? >>> >>> Kees. >>> >>> >>> On 11/10/14 00:29, Thomas Watteyne wrote: >>> >>> Kees, Xavi, >>> >>> If the default hopping sequence isn't clear in IEEE802.15.4e-2012, >>> this is important information to the fed back to the IEEE802.15.4 TG. >>> *@PatKinney*, maybe you can chime in on whether the related text will >>> be changed in IEEE802.15.4-2015? >>> >>> In any case, let's disambiguate the hopping sequence on this thread. >>> We could add an example in draft-ietf-6tisch-minimal, and maybe ask >>> IEEE802.15.4 to do the same. >>> >>> I have created some quick Python code which I believe calculates the >>> default hopping sequence, see >>> https://gist.github.com/twatteyne/2e22ee3c1a802b685695. >>> >>> Could someone (*Pat*? *Jonathan*?) double-check that it computes the >>> right sequence. I'm copy-pasting the output below. >>> >>> Thomas >>> >>> --- >>> >>> This script calculates the default channel hopping sequence for the >>> IEEE802.15.4e-2012 TSCH mode. >>> >>> \author Thomas Watteyne >>> \date November 2014 >>> \license http://opensource.org/licenses/BSD-3-Clause >>> >>> >>> === Step a. >>> >>> SHUFFLE is a macHoppingSequenceLength-sized array. The contents of >>> this array ar >>> e equivalent to the first macHoppingSequenceLength outputs of a 9-bit >>> linear fee >>> dback shift register (LFSR) with polynomial x9 + x5 + 1 and a starting >>> seed of 2 >>> 55. Each LFSR output is modulo macHoppingSequenceLength, so that each >>> entry of S >>> HUFFLE is between 0 and (macHoppingSequenceLength - 1), inclusive. >>> >>> 5 9 >>> 1 1 1 1 1 1 1 1 0 ( 255==0x0ff==b011111111) >>> 1 1 1 1 1 1 1 1 1 ( 511==0x1ff==b111111111) --> 15 >>> 0 1 1 1 1 1 1 1 1 ( 510==0x1fe==b111111110) --> 14 >>> 0 0 1 1 1 1 1 1 1 ( 508==0x1fc==b111111100) --> 12 >>> 0 0 0 1 1 1 1 1 1 ( 504==0x1f8==b111111000) --> 8 >>> 0 0 0 0 1 1 1 1 1 ( 496==0x1f0==b111110000) --> 0 >>> 0 0 0 0 0 1 1 1 1 ( 480==0x1e0==b111100000) --> 0 >>> 1 0 0 0 0 0 1 1 1 ( 449==0x1c1==b111000001) --> 1 >>> 1 1 0 0 0 0 0 1 1 ( 387==0x183==b110000011) --> 3 >>> 1 1 1 0 0 0 0 0 1 ( 263==0x107==b100000111) --> 7 >>> 1 1 1 1 0 0 0 0 0 ( 15==0x00f==b000001111) --> 15 >>> 0 1 1 1 1 0 0 0 0 ( 30==0x01e==b000011110) --> 14 >>> 1 0 1 1 1 1 0 0 0 ( 61==0x03d==b000111101) --> 13 >>> 1 1 0 1 1 1 1 0 0 ( 123==0x07b==b001111011) --> 11 >>> 1 1 1 0 1 1 1 1 0 ( 247==0x0f7==b011110111) --> 7 >>> 1 1 1 1 0 1 1 1 1 ( 495==0x1ef==b111101111) --> 15 >>> 1 1 1 1 1 0 1 1 1 ( 479==0x1df==b111011111) --> 15 >>> >>> SHUFFLE: [15, 14, 12, 8, 0, 0, 1, 3, 7, 15, 14, 13, 11, 7, 15, 15] >>> >>> === Step b. >>> >>> CHANNELS is a macHoppingSequenceLength-sized array that is initially >>> populated w >>> ith the monotonically increasing list of channels available to the PHY. >>> >>> CHANNELS: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15] >>> >>> === Step c. >>> >>> CHANNELS is shuffled as per Figure 7a. Elements may wind up being >>> swapped multip >>> le times in this process. >>> >>> macHoppingSequenceList: *[5, 6, 12, 7, 15, 4, 14, 11, 8, 0, 1, 2, 13, >>> 3, 9, 10]* >>> >>> >>> Script ended normally, press Enter to close. >>> >>> On Friday, November 7, 2014, Xavier Vilajosana < >>> xvilajosana@eecs.berkeley.edu> wrote: >>> >>>> Dear Kees, >>>> thanks for your comments. >>>> >>>> answering 1) >>>> IMHO the fact that if default ch. hopping sequence is being used *may >>>> not be* advertised in the EB it is not clear in the standard. And >>>> therefore I opted to make the EB explicit (even only an ID and this being >>>> the default) >>>> Page 11 of the 15.4e amendment indicates that: >>>> >>>> *All hopping sequences are referred to by an ID, >>>> macHoppingSequenceID, with ID = 0 denoting the default* >>>> *sequence for a particular PHY (or PHY configuration if the PHY >>>> supports more than one channel list).* >>>> >>>> then page 92 >>>> *The full Hopping Sequence may be omitted to ensure that the frame does >>>> not exceed aMaxPHYPacketSize.* >>>> *In this case only the Hopping Sequence ID is carried, and the length >>>> of the IE is 1 octet. When the length is* >>>> *not equal to one, the additional fields are present. The element >>>> varies in length depending upon the* >>>> *numberOfChannels in use by the PHY. The channelPage and >>>> numberOfChannels attributes can be used to* >>>> *determine the size of the extendedBitmap, and the >>>> macHoppingSequenceLength can be used to determine* >>>> *the size of the macHoppingSequenceList.* >>>> *The Channel Hopping IE may be used by any channel hopping PAN to >>>> synchronize devices.* >>>> >>>> My last point here is that this *may* might indicate optionality but >>>> the case for the default id is not mentioned so I am not sure it can be >>>> elided if default id (0) >>>> >>>> answering 2) it seems a good point. Let us think about it. >>>> >>>> regards, >>>> Xavi >>>> >>>> 2014-11-07 9:57 GMT+01:00 Kees Trommel : >>>> >>>>> Hi, >>>>> >>>>> This draft specifies that the enhanced beacon should include a Channel >>>>> Hopping IE with a Hopping Sequence ID equal to 0. Hopping Sequence ID 0 is >>>>> the default hopping sequence ID. So the actual hopping sequence will not be >>>>> included in the enhanced beacon. >>>>> >>>>> Section 5.1.1a of the IEE802.25.4e standard defines an algorithm to >>>>> calculate a default hopping sequence ID. >>>>> >>>>> I have the following questions regarding the default hopping sequence: >>>>> >>>>> 1. Is it the intention that a minimal configuration uses the default >>>>> hopping sequence as defined in the IEE802.25.4e standard? >>>>> 2. If the answer on 1. is yes: The definition of the IEE802.25.4e >>>>> hopping sequence (in my opinion) is not unambiguous, so can you add the >>>>> actual default hopping sequence to this draft? >>>>> >>>>> Regards, >>>>> >>>>> Kees. >>>>> >>>>> On Oct 27, 2014, at 12:20 AM, Xavier Vilajosana >>>> eecs.berkeley.edu> wrote: >>>>> >>>>> All, I just published the new version of minimal. It includes a >>>>> security section as discussed last call and some changes to the default >>>>> timing to be according to 15.4 tsch default values. >>>>> >>>>> regards, >>>>> Xavi >>>>> >>>>> ---------- Forwarded message ---------- >>>>> From: >>>>> Date: 2014-10-27 5:17 GMT+01:00 >>>>> Subject: [6tisch] I-D Action: draft-ietf-6tisch-minimal-03.txt >>>>> To: i-d-announce at ietf.org >>>>> Cc: 6tisch at ietf.org >>>>> >>>>> >>>>> >>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>> directories. >>>>> This draft is a work item of the IPv6 over the TSCH mode of IEEE >>>>> 802.15.4e Working Group of the IETF. >>>>> >>>>> Title : Minimal 6TiSCH Configuration >>>>> Authors : Xavier Vilajosana >>>>> Kris Pister >>>>> Filename : draft-ietf-6tisch-minimal-03.txt >>>>> Pages : 22 >>>>> Date : 2014-10-26 >>>>> >>>>> Abstract: >>>>> This document describes the minimal set of rules to operate a >>>>> [IEEE802154e] Timeslotted Channel Hopping (TSCH) network. This >>>>> minimal mode of operation can be used during network bootstrap, as a >>>>> fall-back mode of operation when no dynamic scheduling solution is >>>>> available or functioning, or during early interoperability testing >>>>> and development. >>>>> >>>>> >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal/ >>>>> >>>>> There's also a htmlized version available at: >>>>> http://tools.ietf.org/html/draft-ietf-6tisch-minimal-03 >>>>> >>>>> A diff from the previous version is available at: >>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-6tisch-minimal-03 >>>>> >>>>> >>>>> Please note that it may take a couple of minutes from the time of >>>>> submission >>>>> until the htmlized version and diff are available at tools.ietf.org. >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>> >>>>> _______________________________________________ >>>>> 6tisch mailing list >>>>> 6tisch at ietf.org >>>>> https://www.ietf.org/mailman/listinfo/6tisch >>>>> >>>>> _______________________________________________ >>>>> 6tisch mailing list >>>>> 6tisch at ietf.org >>>>> https://www.ietf.org/mailman/listinfo/6tisch >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 6tisch mailing list >>>>> 6tisch@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/6tisch >>>>> >>>>> >>>> >>> >> > --047d7bf18b7650a089050786db34 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Quick thought: does this discussion fit in=C2=A0draft-ietf= -6tisch-minimal or draft-ietf-6tisch-tsch? Both make sense to me.

    On Mon, Nov 10, 2014 = at 10:15 AM, Xavier Vilajosana <xvilajosana@eecs.berkeley.edu<= /a>> wrote:
    Hi= ,=C2=A0

    my 5 cents. After thinking about it I am in favo= ur of adding the example as the draft will be more self-contained and will = facilitate the understanding of how ch. hopping sequence is caluclated. (an= alogously to the OF0 example).=C2=A0

    regards,
    Xavi

    2014-11-10 19:41 GMT+01:00 Tho= mas Watteyne <watteyne@eecs.berkeley.edu>:
    Kees,

    In this script you made the assumption that the hopping sequence= length is equal to the number of channels. I think this is reasonable assu= mption but it is not defined in the IEEE802.15.4e standard, so it would be = good idea to put this assumption in the draft too.

    Yes, that was my assumption in this code.
    You are using channel numbers 0 - 15 and I assume = that these are the 16 2.5GHz channels. The IEEE802.15.4e standard define th= ese as channel numbers 11 - 26 of page 0. It is fine for me to keep the 0 -= 15 channel numbering scheme but it would good to mention this too. What ab= out (future) support of other channels and pages defined in the IEEE802.15.= 4e standard?

    Correct, you should add= 11 to the channel numbers in the code to use channel numbers 11-26 in IEEE= notation (2.405GHz-2.480GHz). AFAICT, there is nothing in the hopping sequ= ence of IEEE802.15.4e-TSCH which prevents the use of (future) sets of chann= els.

    @all, what do others think? Are detail= s about the hopping sequence something we need to add to draft-ietf-6tisch-= minimal?

    Thomas

    On Mon, Nov 10, 2014 at 12:10 AM, Kees Trommel <ctr= ommel@aimvalley.nl> wrote:
    =20 =20 =20
    Thomas, Xavi,

    Thanks, I cannot find anything in this script that would violate the IEEE802.15.4e standard.

    In this script you made the assumption that the hopping sequence length is equal to the number of channels. I think this is reasonable assumption but it is not defined in the IEEE802.15.4e standard, so it would be good idea to put this assumption in the draft too.

    You are using channel numbers 0 - 15 and I assume that these are the 16 2.5GHz channels. The IEEE802.15.4e standard define these as channel numbers 11 - 26 of page 0. It is fine for me to keep the 0 - 15 channel numbering scheme but it would good to mention this too. What about (future) support of other channels and pages defined in the IEEE802.15.4e standard?<= br>
    Kees.


    On 11/10/14 00:29, Thomas Watteyne wrote:
    Kees, Xavi,

    If the default hopping sequence isn't clear in IEEE802.15.4e-2012, this is important information to the fed back to the IEEE802.15.4 TG. @PatKinney, maybe you can chime in on whether the related text will be changed in IEEE802.15.4-2015?

    In any case, let's disambiguate the hopping sequence on this thread. We could add an example in draft-ietf-6tisch-minimal, and maybe ask IEEE802.15.4 to do the same.

    I have created some quick Python code which I believe calculates the default hopping sequence, see https://gi= st.github.com/twatteyne/2e22ee3c1a802b685695.

    Could someone (Pat? Jonathan?) double-check that it computes the right sequence. I'm copy-pasting the output below.

    Thomas

    ---

    This script calculates the default channel hopping sequence for the
    IEEE802.15.4e-2012 TSCH mode.

    \author Thomas Watteyne
    \date November 2014


    =3D=3D=3D Step a.

    SHUFFLE is a macHoppingSequenceLength-sized array. The contents of this array ar
    e equivalent to the first macHoppingSequenceLength outputs of a 9-bit linear fee
    dback shift register (LFSR) with polynomial x9 + x5 + 1 and a starting seed of 2
    55. Each LFSR output is modulo macHoppingSequenceLength, so that each entry of S
    HUFFLE is between 0 and (macHoppingSequenceLength - 1), inclusive.

    =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A05 =C2=A0 =C2=A0 =C2=A0 9
    =C2=A0 =C2=A01 1 1 1 1= 1 1 1 0 ( 255=3D=3D0x0ff=3D=3Db011111111)
    =C2=A0 =C2=A01 1 1 1 1= 1 1 1 1 ( 511=3D=3D0x1ff=3D=3Db111111111) --> 15
    =C2=A0 =C2=A00 1 1 1 1= 1 1 1 1 ( 510=3D=3D0x1fe=3D=3Db111111110) --> 14
    =C2=A0 =C2=A00 0 1 1 1= 1 1 1 1 ( 508=3D=3D0x1fc=3D=3Db111111100) --> 12
    =C2=A0 =C2=A00 0 0 1 1= 1 1 1 1 ( 504=3D=3D0x1f8=3D=3Db111111000) --> 8
    =C2=A0 =C2=A00 0 0 0 1= 1 1 1 1 ( 496=3D=3D0x1f0=3D=3Db111110000) --> 0
    =C2=A0 =C2=A00 0 0 0 0= 1 1 1 1 ( 480=3D=3D0x1e0=3D=3Db111100000) --> 0
    =C2=A0 =C2=A01 0 0 0 0= 0 1 1 1 ( 449=3D=3D0x1c1=3D=3Db111000001) --> 1
    =C2=A0 =C2=A01 1 0 0 0= 0 0 1 1 ( 387=3D=3D0x183=3D=3Db110000011) --> 3
    =C2=A0 =C2=A01 1 1 0 0= 0 0 0 1 ( 263=3D=3D0x107=3D=3Db100000111) --> 7
    =C2=A0 =C2=A01 1 1 1 0= 0 0 0 0 ( =C2=A015=3D=3D0x00f=3D=3Db000001111) --> 15
    =C2=A0 =C2=A00 1 1 1 1= 0 0 0 0 ( =C2=A030=3D=3D0x01e=3D=3Db000011110) --> 14
    =C2=A0 =C2=A01 0 1 1 1= 1 0 0 0 ( =C2=A061=3D=3D0x03d=3D=3Db000111101) --> 13
    =C2=A0 =C2=A01 1 0 1 1= 1 1 0 0 ( 123=3D=3D0x07b=3D=3Db001111011) --> 11
    =C2=A0 =C2=A01 1 1 0 1= 1 1 1 0 ( 247=3D=3D0x0f7=3D=3Db011110111) --> 7
    =C2=A0 =C2=A01 1 1 1 0= 1 1 1 1 ( 495=3D=3D0x1ef=3D=3Db111101111) --> 15
    =C2=A0 =C2=A01 1 1 1 1= 0 1 1 1 ( 479=3D=3D0x1df=3D=3Db111011111) --> 15

    SHUFFLE: =C2=A0[15, 14= , 12, 8, 0, 0, 1, 3, 7, 15, 14, 13, 11, 7, 15, 15]

    =3D=3D=3D Step b.

    CHANNELS is a macHoppingSequenceLength-sized array that is initially populated w
    ith the monotonically increasing list of channels available to the PHY.

    CHANNELS: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15]

    =3D=3D=3D Step c.

    CHANNELS is shuffled as per Figure 7a. Elements may wind up being swapped multip
    le times in this process.

    macHoppingSequenceList= : [5, 6, 12, 7, 15, 4, 14, 11, 8, 0, 1, 2, 13, 3, 9, 10]


    Script ended normally, press Enter to close.

    On Friday, November 7, 2014, Xavier Vilajosana <xvilajosana@eecs.berke= ley.edu> wrote:
    Dear Kees,
    thanks for your comments.=C2=A0

    answering 1)
    IMHO the fact that if default ch. hopping sequence is being used may not be advertised in the EB it is not clear in the standard. And therefore I opted to make the EB explicit (even only an ID and this being the default)
    Page 11 of the 15.4e amendment indicates that:

    All hopping sequences are referred to by an ID, macHoppingSequenceID, with ID =3D 0 denoting the default
    sequence for a particular PHY (or PHY configuration if the PHY supports more than one channel list).

    then page 92
    The full Hopping Sequence may be omitted to ensure that the frame does not exceed aMaxPHYPacketSize.
    In this case only the Hopping Sequence ID is carried, and the length of the IE is 1 octet. When the length is
    not equal to one, the additional fields are present. The element varies in length depending upon the
    numberOfChannels in use by the PHY. The channelPage and numberOfChannels attributes can be used to
    determine the size of the extendedBitmap, and the macHoppingSequenceLength can be used to determine
    the size of the macHoppingSequenceList.
    The Channel Hopping IE may be used by any channel hopping PAN to synchronize devices.

    My last point here is that this may=C2=A0might indicate optionality but the case for the default id is not mentioned so I am not sure it can be elided if default id (0)

    answering 2) it seems a good point. Let us think about it.

    regards,
    Xavi

    2014-11-07 9:57 GMT+01:00 Kees Trommel <ctrommel@aimvalley.nl&= gt;:
    Hi,

    This draft specifies that the enhanced beacon should include a Channel Hopping IE with a Hopping Sequence ID equal to 0. Hopping Sequence ID 0 is the default hopping sequence ID. So the actual hopping sequence will not be included in the enhanced beacon.

    Section 5.1.1a of the IEE802.25.4e standard defines an algorithm to calculate a default hopping sequence ID.

    I have the following questions regarding the default hopping sequence:

    1. Is it the intention that a minimal configuration uses the default hopping sequence as defined in the IEE802.25.4e standard?
    2. If the answer on 1. is yes:=C2=A0 The definition of the IEE802.25.4e hopping sequence (in my opinion) is not unambiguous, so can you add the actual default hopping sequence to this draft?

    Regards,

    Kees.

    On Oct 27, 2014, at 12:20 AM, Xavier Vilajosana <xvilajosana at eecs.berkeley.edu> wrote:

    All, I just published the new version of minimal. It includes a security section as discussed last call and some changes to the default timing to be according to 15.4 tsch default values.

    regards,
    Xavi

    ---------- Forwarded message ----------
    From: <internet-drafts at ietf.org>
    Date: 2014-10-27 5:17 GMT+01:00
    Subject: [6tisch] I-D Action: draft-ietf-6tisch-minimal-03.txt
    To: i-d-announce at ietf.org
    Cc: 6tisch at ietf.or= g



    A New Internet-Draft is available from the on-line Internet-Drafts directories.
    =C2=A0This draft is a work item of the IP= v6 over the TSCH mode of IEEE 802.15.4e Working Group of the IETF.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Minimal 6TiSCH Configuration
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0: Xavier Vilajosana
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Kris Pister
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2= =A0 =C2=A0 =C2=A0 =C2=A0 : draft-ietf-6tisch-minimal-03.txt
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: 22
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 2014-10-26

    Abstract:
    =C2=A0 =C2=A0This document describes the = minimal set of rules to operate a
    =C2=A0 =C2=A0[IEEE802154e] Timeslotted Ch= annel Hopping (TSCH) network.=C2=A0 This
    =C2=A0 =C2=A0minimal mode of operation ca= n be used during network bootstrap, as a
    =C2=A0 =C2=A0fall-back mode of operation = when no dynamic scheduling solution is
    =C2=A0 =C2=A0available or functioning, or= during early interoperability testing
    =C2=A0 =C2=A0and development.


    The IETF datatracker status page for this draft is:
    https://d= atatracker.ietf.org/doc/draft-ietf-6tisch-minimal/

    There's also a htmlized version available at:
    http://tools.= ietf.org/html/draft-ietf-6tisch-minimal-03

    A diff from the previous version is available at:
    http:= //www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6tisch-minimal-03


    Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

    Internet-Drafts are also available by anonymous FTP at:
    ftp://ftp.ietf.org/internet-draft= s/

    _______________________________________________
    6tisch mailing list
    6tisch at ietf.org
    https://www.ietf.org/mai= lman/listinfo/6tisch

    ______________________________________= _________
    6tisch mailing list
    6tisch at ietf.org
    https://www.ietf.org/mai= lman/listinfo/6tisch


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






    --047d7bf18b7650a089050786db34-- From nobody Mon Nov 10 12:58:05 2014 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 615481ACE1E for <6tisch@ietfa.amsl.com>; Mon, 10 Nov 2014 12:57:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.094 X-Spam-Level: X-Spam-Status: No, score=-15.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yKgYJc_k272r for <6tisch@ietfa.amsl.com>; Mon, 10 Nov 2014 12:57:44 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DD8E1AC3DE for <6tisch@ietf.org>; Mon, 10 Nov 2014 12:57:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=52662; q=dns/txt; s=iport; t=1415653065; x=1416862665; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=71sZHT7c9O4I1tA6dId69Vq5hnesXQwD1jgCF3lcd6M=; b=TiHVjSXQHR53OkdLppf/p6UrJRDOCXwKWDf+Driv4MH/p2nYHyGKieb4 TT8vaAji6+21LyVqOdZkNDn1faWO2nWk1pZvQEKfdMytQYh7mGcQZeKbI cGj/sTNMbbOVLWZoXTxjdMATesO09lfdLvZZPxO87cQcapPl4jNvhj9T7 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmgIAGsmYVStJA2B/2dsb2JhbABcDoI6RlRUBQSDArhVjjiBZAEJhnpVAhyBCBYBAQEBAX2EAgEBAQQBAQEXCQQGOgcLEAIBCBEDAQEBCxYBBgMCAgIlCxQJCAIEAQ0FCAESiCYIBbcnlhIBAQEBAQEBAQEBAQEBAQEBAQEBAQEXkCg8DwcKDQQGAQYDgm42gR4FhjqJVIIjhFOIVT2DEo1ThAqDOkBsgUiBAwEBAQ X-IronPort-AV: E=Sophos;i="5.07,355,1413244800"; d="scan'208,217";a="370991154" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-6.cisco.com with ESMTP; 10 Nov 2014 20:57:23 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id sAAKvM4N014149 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Nov 2014 20:57:22 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.165]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Mon, 10 Nov 2014 14:57:22 -0600 From: "Pascal Thubert (pthubert)" To: Thomas Watteyne , Xavier Vilajosana Thread-Topic: [6tisch] I-D Action: draft-ietf-6tisch-minimal-03.txt Thread-Index: AQHP/SN8VAz0lm3wqEGDLk8RtdIOA5xaVjrg Date: Mon, 10 Nov 2014 20:57:21 +0000 Deferred-Delivery: Mon, 10 Nov 2014 20:57:00 +0000 Message-ID: References: <545C898A.8060300@aimvalley.nl> <54608F2A.7090708@aimvalley.nl> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.209.159] Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD848A48886xmbrcdx01ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch/VB4J0GcX8CBA713nflXElY7zdok Cc: Kees Trommel , "6tisch@ietf.org" <6tisch@ietf.org> Subject: Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-03.txt X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 20:57:58 -0000 --_000_E045AECD98228444A58C61C200AE1BD848A48886xmbrcdx01ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgVGhvbWFzOg0KDQpJIHRoaW5rOg0KLSB0aGF0IHRoZSBUU0NIIGRyYWZ0IGNvdWxkIGRpc2N1 c3Mgd2hhdCBpcyBzdWItZGVmaW5lZCBpbiBUU0NILCBpbmRpY2F0ZSB0aGF0IHdlIHVzZSB0aGUg cmFuZ2UgMC0xNSwgdG8gYWRkcmVzcyBLZWVz4oCZIHBvaW50cw0KLSBidXQgdGhlbiwgdGhlIHNl dHRpbmcgdG8gYmUgdXNlZCBpbiBtaW5pbWFsLCBhbmQgcHNldWRvIGNvZGUgYWxvbmcgdGhlIGxp bmVzIHlvdSBwcm9kdWNlZCBzaG91bGQgZ28gaW4gbWluaW1hbCB0byBlbnN1cmUgaW50ZXJvcC4g VGhlIHBzZXVkbyBjb2RlIHdvdWxkIGJlIGFuIGFwcGVuZGl4Lg0KDQpNYWtlcyBzZW5zZT8NCg0K UGFzY2FsDQoNCkZyb206IDZ0aXNjaCBbbWFpbHRvOjZ0aXNjaC1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgVGhvbWFzIFdhdHRleW5lDQpTZW50OiBsdW5kaSAxMCBub3ZlbWJyZSAyMDE0 IDEyOjE3DQpUbzogWGF2aWVyIFZpbGFqb3NhbmENCkNjOiBLZWVzIFRyb21tZWw7IDZ0aXNjaEBp ZXRmLm9yZw0KU3ViamVjdDogUmU6IFs2dGlzY2hdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtNnRp c2NoLW1pbmltYWwtMDMudHh0DQoNClF1aWNrIHRob3VnaHQ6IGRvZXMgdGhpcyBkaXNjdXNzaW9u IGZpdCBpbiBkcmFmdC1pZXRmLTZ0aXNjaC1taW5pbWFsIG9yIGRyYWZ0LWlldGYtNnRpc2NoLXRz Y2g/IEJvdGggbWFrZSBzZW5zZSB0byBtZS4NCg0KT24gTW9uLCBOb3YgMTAsIDIwMTQgYXQgMTA6 MTUgQU0sIFhhdmllciBWaWxham9zYW5hIDx4dmlsYWpvc2FuYUBlZWNzLmJlcmtlbGV5LmVkdTxt YWlsdG86eHZpbGFqb3NhbmFAZWVjcy5iZXJrZWxleS5lZHU+PiB3cm90ZToNCkhpLA0KDQpteSA1 IGNlbnRzLiBBZnRlciB0aGlua2luZyBhYm91dCBpdCBJIGFtIGluIGZhdm91ciBvZiBhZGRpbmcg dGhlIGV4YW1wbGUgYXMgdGhlIGRyYWZ0IHdpbGwgYmUgbW9yZSBzZWxmLWNvbnRhaW5lZCBhbmQg d2lsbCBmYWNpbGl0YXRlIHRoZSB1bmRlcnN0YW5kaW5nIG9mIGhvdyBjaC4gaG9wcGluZyBzZXF1 ZW5jZSBpcyBjYWx1Y2xhdGVkLiAoYW5hbG9nb3VzbHkgdG8gdGhlIE9GMCBleGFtcGxlKS4NCg0K cmVnYXJkcywNClhhdmkNCg0KMjAxNC0xMS0xMCAxOTo0MSBHTVQrMDE6MDAgVGhvbWFzIFdhdHRl eW5lIDx3YXR0ZXluZUBlZWNzLmJlcmtlbGV5LmVkdTxtYWlsdG86d2F0dGV5bmVAZWVjcy5iZXJr ZWxleS5lZHU+PjoNCktlZXMsDQoNCkluIHRoaXMgc2NyaXB0IHlvdSBtYWRlIHRoZSBhc3N1bXB0 aW9uIHRoYXQgdGhlIGhvcHBpbmcgc2VxdWVuY2UgbGVuZ3RoIGlzIGVxdWFsIHRvIHRoZSBudW1i ZXIgb2YgY2hhbm5lbHMuIEkgdGhpbmsgdGhpcyBpcyByZWFzb25hYmxlIGFzc3VtcHRpb24gYnV0 IGl0IGlzIG5vdCBkZWZpbmVkIGluIHRoZSBJRUVFODAyLjE1LjRlIHN0YW5kYXJkLCBzbyBpdCB3 b3VsZCBiZSBnb29kIGlkZWEgdG8gcHV0IHRoaXMgYXNzdW1wdGlvbiBpbiB0aGUgZHJhZnQgdG9v Lg0KDQpZZXMsIHRoYXQgd2FzIG15IGFzc3VtcHRpb24gaW4gdGhpcyBjb2RlLg0KDQpZb3UgYXJl IHVzaW5nIGNoYW5uZWwgbnVtYmVycyAwIC0gMTUgYW5kIEkgYXNzdW1lIHRoYXQgdGhlc2UgYXJl IHRoZSAxNiAyLjVHSHogY2hhbm5lbHMuIFRoZSBJRUVFODAyLjE1LjRlIHN0YW5kYXJkIGRlZmlu ZSB0aGVzZSBhcyBjaGFubmVsIG51bWJlcnMgMTEgLSAyNiBvZiBwYWdlIDAuIEl0IGlzIGZpbmUg Zm9yIG1lIHRvIGtlZXAgdGhlIDAgLSAxNSBjaGFubmVsIG51bWJlcmluZyBzY2hlbWUgYnV0IGl0 IHdvdWxkIGdvb2QgdG8gbWVudGlvbiB0aGlzIHRvby4gV2hhdCBhYm91dCAoZnV0dXJlKSBzdXBw b3J0IG9mIG90aGVyIGNoYW5uZWxzIGFuZCBwYWdlcyBkZWZpbmVkIGluIHRoZSBJRUVFODAyLjE1 LjRlIHN0YW5kYXJkPw0KDQpDb3JyZWN0LCB5b3Ugc2hvdWxkIGFkZCAxMSB0byB0aGUgY2hhbm5l bCBudW1iZXJzIGluIHRoZSBjb2RlIHRvIHVzZSBjaGFubmVsIG51bWJlcnMgMTEtMjYgaW4gSUVF RSBub3RhdGlvbiAoMi40MDVHSHotMi40ODBHSHopLiBBRkFJQ1QsIHRoZXJlIGlzIG5vdGhpbmcg aW4gdGhlIGhvcHBpbmcgc2VxdWVuY2Ugb2YgSUVFRTgwMi4xNS40ZS1UU0NIIHdoaWNoIHByZXZl bnRzIHRoZSB1c2Ugb2YgKGZ1dHVyZSkgc2V0cyBvZiBjaGFubmVscy4NCg0KQGFsbCwgd2hhdCBk byBvdGhlcnMgdGhpbms/IEFyZSBkZXRhaWxzIGFib3V0IHRoZSBob3BwaW5nIHNlcXVlbmNlIHNv bWV0aGluZyB3ZSBuZWVkIHRvIGFkZCB0byBkcmFmdC1pZXRmLTZ0aXNjaC1taW5pbWFsPw0KDQpU aG9tYXMNCg0KT24gTW9uLCBOb3YgMTAsIDIwMTQgYXQgMTI6MTAgQU0sIEtlZXMgVHJvbW1lbCA8 Y3Ryb21tZWxAYWltdmFsbGV5Lm5sPG1haWx0bzpjdHJvbW1lbEBhaW12YWxsZXkubmw+PiB3cm90 ZToNClRob21hcywgWGF2aSwNCg0KVGhhbmtzLCBJIGNhbm5vdCBmaW5kIGFueXRoaW5nIGluIHRo aXMgc2NyaXB0IHRoYXQgd291bGQgdmlvbGF0ZSB0aGUgSUVFRTgwMi4xNS40ZSBzdGFuZGFyZC4N Cg0KSW4gdGhpcyBzY3JpcHQgeW91IG1hZGUgdGhlIGFzc3VtcHRpb24gdGhhdCB0aGUgaG9wcGlu ZyBzZXF1ZW5jZSBsZW5ndGggaXMgZXF1YWwgdG8gdGhlIG51bWJlciBvZiBjaGFubmVscy4gSSB0 aGluayB0aGlzIGlzIHJlYXNvbmFibGUgYXNzdW1wdGlvbiBidXQgaXQgaXMgbm90IGRlZmluZWQg aW4gdGhlIElFRUU4MDIuMTUuNGUgc3RhbmRhcmQsIHNvIGl0IHdvdWxkIGJlIGdvb2QgaWRlYSB0 byBwdXQgdGhpcyBhc3N1bXB0aW9uIGluIHRoZSBkcmFmdCB0b28uDQoNCllvdSBhcmUgdXNpbmcg Y2hhbm5lbCBudW1iZXJzIDAgLSAxNSBhbmQgSSBhc3N1bWUgdGhhdCB0aGVzZSBhcmUgdGhlIDE2 IDIuNUdIeiBjaGFubmVscy4gVGhlIElFRUU4MDIuMTUuNGUgc3RhbmRhcmQgZGVmaW5lIHRoZXNl IGFzIGNoYW5uZWwgbnVtYmVycyAxMSAtIDI2IG9mIHBhZ2UgMC4gSXQgaXMgZmluZSBmb3IgbWUg dG8ga2VlcCB0aGUgMCAtIDE1IGNoYW5uZWwgbnVtYmVyaW5nIHNjaGVtZSBidXQgaXQgd291bGQg Z29vZCB0byBtZW50aW9uIHRoaXMgdG9vLiBXaGF0IGFib3V0IChmdXR1cmUpIHN1cHBvcnQgb2Yg b3RoZXIgY2hhbm5lbHMgYW5kIHBhZ2VzIGRlZmluZWQgaW4gdGhlIElFRUU4MDIuMTUuNGUgc3Rh bmRhcmQ/DQoNCktlZXMuDQoNCg0KT24gMTEvMTAvMTQgMDA6MjksIFRob21hcyBXYXR0ZXluZSB3 cm90ZToNCktlZXMsIFhhdmksDQoNCklmIHRoZSBkZWZhdWx0IGhvcHBpbmcgc2VxdWVuY2UgaXNu J3QgY2xlYXIgaW4gSUVFRTgwMi4xNS40ZS0yMDEyLCB0aGlzIGlzIGltcG9ydGFudCBpbmZvcm1h dGlvbiB0byB0aGUgZmVkIGJhY2sgdG8gdGhlIElFRUU4MDIuMTUuNCBURy4gQFBhdEtpbm5leSwg bWF5YmUgeW91IGNhbiBjaGltZSBpbiBvbiB3aGV0aGVyIHRoZSByZWxhdGVkIHRleHQgd2lsbCBi ZSBjaGFuZ2VkIGluIElFRUU4MDIuMTUuNC0yMDE1Pw0KDQpJbiBhbnkgY2FzZSwgbGV0J3MgZGlz YW1iaWd1YXRlIHRoZSBob3BwaW5nIHNlcXVlbmNlIG9uIHRoaXMgdGhyZWFkLiBXZSBjb3VsZCBh ZGQgYW4gZXhhbXBsZSBpbiBkcmFmdC1pZXRmLTZ0aXNjaC1taW5pbWFsLCBhbmQgbWF5YmUgYXNr IElFRUU4MDIuMTUuNCB0byBkbyB0aGUgc2FtZS4NCg0KSSBoYXZlIGNyZWF0ZWQgc29tZSBxdWlj ayBQeXRob24gY29kZSB3aGljaCBJIGJlbGlldmUgY2FsY3VsYXRlcyB0aGUgZGVmYXVsdCBob3Bw aW5nIHNlcXVlbmNlLCBzZWUgaHR0cHM6Ly9naXN0LmdpdGh1Yi5jb20vdHdhdHRleW5lLzJlMjJl ZTNjMWE4MDJiNjg1Njk1Lg0KDQpDb3VsZCBzb21lb25lIChQYXQ/IEpvbmF0aGFuPykgZG91Ymxl LWNoZWNrIHRoYXQgaXQgY29tcHV0ZXMgdGhlIHJpZ2h0IHNlcXVlbmNlLiBJJ20gY29weS1wYXN0 aW5nIHRoZSBvdXRwdXQgYmVsb3cuDQoNClRob21hcw0KDQotLS0NCg0KVGhpcyBzY3JpcHQgY2Fs Y3VsYXRlcyB0aGUgZGVmYXVsdCBjaGFubmVsIGhvcHBpbmcgc2VxdWVuY2UgZm9yIHRoZQ0KSUVF RTgwMi4xNS40ZS0yMDEyIFRTQ0ggbW9kZS4NCg0KXGF1dGhvciBUaG9tYXMgV2F0dGV5bmUNClxk YXRlIE5vdmVtYmVyIDIwMTQNClxsaWNlbnNlIGh0dHA6Ly9vcGVuc291cmNlLm9yZy9saWNlbnNl cy9CU0QtMy1DbGF1c2UNCg0KDQo9PT0gU3RlcCBhLg0KDQpTSFVGRkxFIGlzIGEgbWFjSG9wcGlu Z1NlcXVlbmNlTGVuZ3RoLXNpemVkIGFycmF5LiBUaGUgY29udGVudHMgb2YgdGhpcyBhcnJheSBh cg0KZSBlcXVpdmFsZW50IHRvIHRoZSBmaXJzdCBtYWNIb3BwaW5nU2VxdWVuY2VMZW5ndGggb3V0 cHV0cyBvZiBhIDktYml0IGxpbmVhciBmZWUNCmRiYWNrIHNoaWZ0IHJlZ2lzdGVyIChMRlNSKSB3 aXRoIHBvbHlub21pYWwgeDkgKyB4NSArIDEgYW5kIGEgc3RhcnRpbmcgc2VlZCBvZiAyDQo1NS4g RWFjaCBMRlNSIG91dHB1dCBpcyBtb2R1bG8gbWFjSG9wcGluZ1NlcXVlbmNlTGVuZ3RoLCBzbyB0 aGF0IGVhY2ggZW50cnkgb2YgUw0KSFVGRkxFIGlzIGJldHdlZW4gMCBhbmQgKG1hY0hvcHBpbmdT ZXF1ZW5jZUxlbmd0aCAtIDEpLCBpbmNsdXNpdmUuDQoNCiAgICAgICAgICAgNSAgICAgICA5DQog ICAxIDEgMSAxIDEgMSAxIDEgMCAoIDI1NT09MHgwZmY9PWIwMTExMTExMTEpDQogICAxIDEgMSAx IDEgMSAxIDEgMSAoIDUxMT09MHgxZmY9PWIxMTExMTExMTEpIC0tPiAxNQ0KICAgMCAxIDEgMSAx IDEgMSAxIDEgKCA1MTA9PTB4MWZlPT1iMTExMTExMTEwKSAtLT4gMTQNCiAgIDAgMCAxIDEgMSAx IDEgMSAxICggNTA4PT0weDFmYz09YjExMTExMTEwMCkgLS0+IDEyDQogICAwIDAgMCAxIDEgMSAx IDEgMSAoIDUwND09MHgxZjg9PWIxMTExMTEwMDApIC0tPiA4DQogICAwIDAgMCAwIDEgMSAxIDEg MSAoIDQ5Nj09MHgxZjA9PWIxMTExMTAwMDApIC0tPiAwDQogICAwIDAgMCAwIDAgMSAxIDEgMSAo IDQ4MD09MHgxZTA9PWIxMTExMDAwMDApIC0tPiAwDQogICAxIDAgMCAwIDAgMCAxIDEgMSAoIDQ0 OT09MHgxYzE9PWIxMTEwMDAwMDEpIC0tPiAxDQogICAxIDEgMCAwIDAgMCAwIDEgMSAoIDM4Nz09 MHgxODM9PWIxMTAwMDAwMTEpIC0tPiAzDQogICAxIDEgMSAwIDAgMCAwIDAgMSAoIDI2Mz09MHgx MDc9PWIxMDAwMDAxMTEpIC0tPiA3DQogICAxIDEgMSAxIDAgMCAwIDAgMCAoICAxNT09MHgwMGY9 PWIwMDAwMDExMTEpIC0tPiAxNQ0KICAgMCAxIDEgMSAxIDAgMCAwIDAgKCAgMzA9PTB4MDFlPT1i MDAwMDExMTEwKSAtLT4gMTQNCiAgIDEgMCAxIDEgMSAxIDAgMCAwICggIDYxPT0weDAzZD09YjAw MDExMTEwMSkgLS0+IDEzDQogICAxIDEgMCAxIDEgMSAxIDAgMCAoIDEyMz09MHgwN2I9PWIwMDEx MTEwMTEpIC0tPiAxMQ0KICAgMSAxIDEgMCAxIDEgMSAxIDAgKCAyNDc9PTB4MGY3PT1iMDExMTEw MTExKSAtLT4gNw0KICAgMSAxIDEgMSAwIDEgMSAxIDEgKCA0OTU9PTB4MWVmPT1iMTExMTAxMTEx KSAtLT4gMTUNCiAgIDEgMSAxIDEgMSAwIDEgMSAxICggNDc5PT0weDFkZj09YjExMTAxMTExMSkg LS0+IDE1DQoNClNIVUZGTEU6ICBbMTUsIDE0LCAxMiwgOCwgMCwgMCwgMSwgMywgNywgMTUsIDE0 LCAxMywgMTEsIDcsIDE1LCAxNV0NCg0KPT09IFN0ZXAgYi4NCg0KQ0hBTk5FTFMgaXMgYSBtYWNI b3BwaW5nU2VxdWVuY2VMZW5ndGgtc2l6ZWQgYXJyYXkgdGhhdCBpcyBpbml0aWFsbHkgcG9wdWxh dGVkIHcNCml0aCB0aGUgbW9ub3RvbmljYWxseSBpbmNyZWFzaW5nIGxpc3Qgb2YgY2hhbm5lbHMg YXZhaWxhYmxlIHRvIHRoZSBQSFkuDQoNCkNIQU5ORUxTOiBbMCwgMSwgMiwgMywgNCwgNSwgNiwg NywgOCwgOSwgMTAsIDExLCAxMiwgMTMsIDE0LCAxNV0NCg0KPT09IFN0ZXAgYy4NCg0KQ0hBTk5F TFMgaXMgc2h1ZmZsZWQgYXMgcGVyIEZpZ3VyZSA3YS4gRWxlbWVudHMgbWF5IHdpbmQgdXAgYmVp bmcgc3dhcHBlZCBtdWx0aXANCmxlIHRpbWVzIGluIHRoaXMgcHJvY2Vzcy4NCg0KbWFjSG9wcGlu Z1NlcXVlbmNlTGlzdDogWzUsIDYsIDEyLCA3LCAxNSwgNCwgMTQsIDExLCA4LCAwLCAxLCAyLCAx MywgMywgOSwgMTBdDQoNCg0KU2NyaXB0IGVuZGVkIG5vcm1hbGx5LCBwcmVzcyBFbnRlciB0byBj bG9zZS4NCg0KT24gRnJpZGF5LCBOb3ZlbWJlciA3LCAyMDE0LCBYYXZpZXIgVmlsYWpvc2FuYSA8 eHZpbGFqb3NhbmFAZWVjcy5iZXJrZWxleS5lZHU8bWFpbHRvOnh2aWxham9zYW5hQGVlY3MuYmVy a2VsZXkuZWR1Pj4gd3JvdGU6DQpEZWFyIEtlZXMsDQp0aGFua3MgZm9yIHlvdXIgY29tbWVudHMu DQoNCmFuc3dlcmluZyAxKQ0KSU1ITyB0aGUgZmFjdCB0aGF0IGlmIGRlZmF1bHQgY2guIGhvcHBp bmcgc2VxdWVuY2UgaXMgYmVpbmcgdXNlZCBtYXkgbm90IGJlIGFkdmVydGlzZWQgaW4gdGhlIEVC IGl0IGlzIG5vdCBjbGVhciBpbiB0aGUgc3RhbmRhcmQuIEFuZCB0aGVyZWZvcmUgSSBvcHRlZCB0 byBtYWtlIHRoZSBFQiBleHBsaWNpdCAoZXZlbiBvbmx5IGFuIElEIGFuZCB0aGlzIGJlaW5nIHRo ZSBkZWZhdWx0KQ0KUGFnZSAxMSBvZiB0aGUgMTUuNGUgYW1lbmRtZW50IGluZGljYXRlcyB0aGF0 Og0KDQpBbGwgaG9wcGluZyBzZXF1ZW5jZXMgYXJlIHJlZmVycmVkIHRvIGJ5IGFuIElELCBtYWNI b3BwaW5nU2VxdWVuY2VJRCwgd2l0aCBJRCA9IDAgZGVub3RpbmcgdGhlIGRlZmF1bHQNCnNlcXVl bmNlIGZvciBhIHBhcnRpY3VsYXIgUEhZIChvciBQSFkgY29uZmlndXJhdGlvbiBpZiB0aGUgUEhZ IHN1cHBvcnRzIG1vcmUgdGhhbiBvbmUgY2hhbm5lbCBsaXN0KS4NCg0KdGhlbiBwYWdlIDkyDQpU aGUgZnVsbCBIb3BwaW5nIFNlcXVlbmNlIG1heSBiZSBvbWl0dGVkIHRvIGVuc3VyZSB0aGF0IHRo ZSBmcmFtZSBkb2VzIG5vdCBleGNlZWQgYU1heFBIWVBhY2tldFNpemUuDQpJbiB0aGlzIGNhc2Ug b25seSB0aGUgSG9wcGluZyBTZXF1ZW5jZSBJRCBpcyBjYXJyaWVkLCBhbmQgdGhlIGxlbmd0aCBv ZiB0aGUgSUUgaXMgMSBvY3RldC4gV2hlbiB0aGUgbGVuZ3RoIGlzDQpub3QgZXF1YWwgdG8gb25l LCB0aGUgYWRkaXRpb25hbCBmaWVsZHMgYXJlIHByZXNlbnQuIFRoZSBlbGVtZW50IHZhcmllcyBp biBsZW5ndGggZGVwZW5kaW5nIHVwb24gdGhlDQpudW1iZXJPZkNoYW5uZWxzIGluIHVzZSBieSB0 aGUgUEhZLiBUaGUgY2hhbm5lbFBhZ2UgYW5kIG51bWJlck9mQ2hhbm5lbHMgYXR0cmlidXRlcyBj YW4gYmUgdXNlZCB0bw0KZGV0ZXJtaW5lIHRoZSBzaXplIG9mIHRoZSBleHRlbmRlZEJpdG1hcCwg YW5kIHRoZSBtYWNIb3BwaW5nU2VxdWVuY2VMZW5ndGggY2FuIGJlIHVzZWQgdG8gZGV0ZXJtaW5l DQp0aGUgc2l6ZSBvZiB0aGUgbWFjSG9wcGluZ1NlcXVlbmNlTGlzdC4NClRoZSBDaGFubmVsIEhv cHBpbmcgSUUgbWF5IGJlIHVzZWQgYnkgYW55IGNoYW5uZWwgaG9wcGluZyBQQU4gdG8gc3luY2hy b25pemUgZGV2aWNlcy4NCg0KTXkgbGFzdCBwb2ludCBoZXJlIGlzIHRoYXQgdGhpcyBtYXkgbWln aHQgaW5kaWNhdGUgb3B0aW9uYWxpdHkgYnV0IHRoZSBjYXNlIGZvciB0aGUgZGVmYXVsdCBpZCBp cyBub3QgbWVudGlvbmVkIHNvIEkgYW0gbm90IHN1cmUgaXQgY2FuIGJlIGVsaWRlZCBpZiBkZWZh dWx0IGlkICgwKQ0KDQphbnN3ZXJpbmcgMikgaXQgc2VlbXMgYSBnb29kIHBvaW50LiBMZXQgdXMg dGhpbmsgYWJvdXQgaXQuDQoNCnJlZ2FyZHMsDQpYYXZpDQoNCjIwMTQtMTEtMDcgOTo1NyBHTVQr MDE6MDAgS2VlcyBUcm9tbWVsIDxjdHJvbW1lbEBhaW12YWxsZXkubmw8bWFpbHRvOmN0cm9tbWVs QGFpbXZhbGxleS5ubD4+Og0KSGksDQoNClRoaXMgZHJhZnQgc3BlY2lmaWVzIHRoYXQgdGhlIGVu aGFuY2VkIGJlYWNvbiBzaG91bGQgaW5jbHVkZSBhIENoYW5uZWwgSG9wcGluZyBJRSB3aXRoIGEg SG9wcGluZyBTZXF1ZW5jZSBJRCBlcXVhbCB0byAwLiBIb3BwaW5nIFNlcXVlbmNlIElEIDAgaXMg dGhlIGRlZmF1bHQgaG9wcGluZyBzZXF1ZW5jZSBJRC4gU28gdGhlIGFjdHVhbCBob3BwaW5nIHNl cXVlbmNlIHdpbGwgbm90IGJlIGluY2x1ZGVkIGluIHRoZSBlbmhhbmNlZCBiZWFjb24uDQoNClNl Y3Rpb24gNS4xLjFhIG9mIHRoZSBJRUU4MDIuMjUuNGUgc3RhbmRhcmQgZGVmaW5lcyBhbiBhbGdv cml0aG0gdG8gY2FsY3VsYXRlIGEgZGVmYXVsdCBob3BwaW5nIHNlcXVlbmNlIElELg0KDQpJIGhh dmUgdGhlIGZvbGxvd2luZyBxdWVzdGlvbnMgcmVnYXJkaW5nIHRoZSBkZWZhdWx0IGhvcHBpbmcg c2VxdWVuY2U6DQoNCjEuIElzIGl0IHRoZSBpbnRlbnRpb24gdGhhdCBhIG1pbmltYWwgY29uZmln dXJhdGlvbiB1c2VzIHRoZSBkZWZhdWx0IGhvcHBpbmcgc2VxdWVuY2UgYXMgZGVmaW5lZCBpbiB0 aGUgSUVFODAyLjI1LjRlIHN0YW5kYXJkPw0KMi4gSWYgdGhlIGFuc3dlciBvbiAxLiBpcyB5ZXM6 ICBUaGUgZGVmaW5pdGlvbiBvZiB0aGUgSUVFODAyLjI1LjRlIGhvcHBpbmcgc2VxdWVuY2UgKGlu IG15IG9waW5pb24pIGlzIG5vdCB1bmFtYmlndW91cywgc28gY2FuIHlvdSBhZGQgdGhlIGFjdHVh bCBkZWZhdWx0IGhvcHBpbmcgc2VxdWVuY2UgdG8gdGhpcyBkcmFmdD8NCg0KUmVnYXJkcywNCg0K S2Vlcy4NCg0KT24gT2N0IDI3LCAyMDE0LCBhdCAxMjoyMCBBTSwgWGF2aWVyIFZpbGFqb3NhbmEg PHh2aWxham9zYW5hIGF0IGVlY3MuYmVya2VsZXkuZWR1PiB3cm90ZToNCg0KDQpBbGwsIEkganVz dCBwdWJsaXNoZWQgdGhlIG5ldyB2ZXJzaW9uIG9mIG1pbmltYWwuIEl0IGluY2x1ZGVzIGEgc2Vj dXJpdHkgc2VjdGlvbiBhcyBkaXNjdXNzZWQgbGFzdCBjYWxsIGFuZCBzb21lIGNoYW5nZXMgdG8g dGhlIGRlZmF1bHQgdGltaW5nIHRvIGJlIGFjY29yZGluZyB0byAxNS40IHRzY2ggZGVmYXVsdCB2 YWx1ZXMuDQoNCnJlZ2FyZHMsDQpYYXZpDQoNCi0tLS0tLS0tLS0gRm9yd2FyZGVkIG1lc3NhZ2Ug LS0tLS0tLS0tLQ0KRnJvbTogPGludGVybmV0LWRyYWZ0cyBhdCBpZXRmLm9yZz4NCkRhdGU6IDIw MTQtMTAtMjcgNToxNyBHTVQrMDE6MDANClN1YmplY3Q6IFs2dGlzY2hdIEktRCBBY3Rpb246IGRy YWZ0LWlldGYtNnRpc2NoLW1pbmltYWwtMDMudHh0DQpUbzogaS1kLWFubm91bmNlIGF0IGlldGYu b3JnDQpDYzogNnRpc2NoIGF0IGlldGYub3JnDQoNCg0KDQpBIE5ldyBJbnRlcm5ldC1EcmFmdCBp cyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMu DQogVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgSVB2NiBvdmVyIHRoZSBUU0NIIG1v ZGUgb2YgSUVFRSA4MDIuMTUuNGUgV29ya2luZyBHcm91cCBvZiB0aGUgSUVURi4NCg0KICAgICAg ICBUaXRsZSAgICAgICAgICAgOiBNaW5pbWFsIDZUaVNDSCBDb25maWd1cmF0aW9uDQogICAgICAg IEF1dGhvcnMgICAgICAgICA6IFhhdmllciBWaWxham9zYW5hDQogICAgICAgICAgICAgICAgICAg ICAgICAgIEtyaXMgUGlzdGVyDQogICAgICAgIEZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYt NnRpc2NoLW1pbmltYWwtMDMudHh0DQogICAgICAgIFBhZ2VzICAgICAgICAgICA6IDIyDQogICAg ICAgIERhdGUgICAgICAgICAgICA6IDIwMTQtMTAtMjYNCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRv Y3VtZW50IGRlc2NyaWJlcyB0aGUgbWluaW1hbCBzZXQgb2YgcnVsZXMgdG8gb3BlcmF0ZSBhDQog ICBbSUVFRTgwMjE1NGVdIFRpbWVzbG90dGVkIENoYW5uZWwgSG9wcGluZyAoVFNDSCkgbmV0d29y ay4gIFRoaXMNCiAgIG1pbmltYWwgbW9kZSBvZiBvcGVyYXRpb24gY2FuIGJlIHVzZWQgZHVyaW5n IG5ldHdvcmsgYm9vdHN0cmFwLCBhcyBhDQogICBmYWxsLWJhY2sgbW9kZSBvZiBvcGVyYXRpb24g d2hlbiBubyBkeW5hbWljIHNjaGVkdWxpbmcgc29sdXRpb24gaXMNCiAgIGF2YWlsYWJsZSBvciBm dW5jdGlvbmluZywgb3IgZHVyaW5nIGVhcmx5IGludGVyb3BlcmFiaWxpdHkgdGVzdGluZw0KICAg YW5kIGRldmVsb3BtZW50Lg0KDQoNClRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZv ciB0aGlzIGRyYWZ0IGlzOg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt aWV0Zi02dGlzY2gtbWluaW1hbC8NCg0KVGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBh dmFpbGFibGUgYXQ6DQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLTZ0aXNj aC1taW5pbWFsLTAzDQoNCkEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWls YWJsZSBhdDoNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtNnRp c2NoLW1pbmltYWwtMDMNCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxl IG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQp1bnRpbCB0aGUgaHRtbGl6 ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnPGh0dHA6 Ly90b29scy5pZXRmLm9yZz4uDQoNCkludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUg YnkgYW5vbnltb3VzIEZUUCBhdDoNCmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMv DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo2dGlz Y2ggbWFpbGluZyBsaXN0DQo2dGlzY2ggYXQgaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vNnRpc2NoDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo2dGlzY2ggbWFpbGluZyBsaXN0DQo2dGlzY2ggYXQgaWV0Zi5v cmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vNnRpc2NoDQoNCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCjZ0aXNjaCBtYWls aW5nIGxpc3QNCjZ0aXNjaEBpZXRmLm9yZzxtYWlsdG86NnRpc2NoQGlldGYub3JnPg0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby82dGlzY2gNCg0KDQoNCg0KDQo= --_000_E045AECD98228444A58C61C200AE1BD848A48886xmbrcdx01ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3 RDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0 IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v biBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5 Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAy NiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+ DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5n PSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkhpIFRob21hczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgdGhpbms6DQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+LSB0aGF0IHRoZSBUU0NIIGRyYWZ0IGNvdWxkIGRpc2N1c3Mg d2hhdCBpcyBzdWItZGVmaW5lZCBpbiBUU0NILCBpbmRpY2F0ZSB0aGF0IHdlIHVzZSB0aGUgcmFu Z2UgMC0xNSwgdG8gYWRkcmVzcyBLZWVz4oCZIHBvaW50czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj4tIGJ1dCB0aGVuLCB0aGUgc2V0dGluZyB0byBiZSB1c2VkIGluIG1pbmltYWwsIGFu ZCBwc2V1ZG8gY29kZSBhbG9uZyB0aGUgbGluZXMgeW91IHByb2R1Y2VkIHNob3VsZCBnbyBpbiBt aW5pbWFsIHRvIGVuc3VyZSBpbnRlcm9wLiBUaGUgcHNldWRvIGNvZGUgd291bGQgYmUNCiBhbiBh cHBlbmRpeC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPk1ha2VzIHNlbnNlPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UGFzY2FsPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzow Y20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IDZ0aXNjaCBbbWFpbHRvOjZ0aXNj aC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5UaG9tYXMgV2F0dGV5bmU8 YnI+DQo8Yj5TZW50OjwvYj4gbHVuZGkgMTAgbm92ZW1icmUgMjAxNCAxMjoxNzxicj4NCjxiPlRv OjwvYj4gWGF2aWVyIFZpbGFqb3NhbmE8YnI+DQo8Yj5DYzo8L2I+IEtlZXMgVHJvbW1lbDsgNnRp c2NoQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbNnRpc2NoXSBJLUQgQWN0aW9u OiBkcmFmdC1pZXRmLTZ0aXNjaC1taW5pbWFsLTAzLnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5RdWljayB0aG91Z2h0OiBkb2VzIHRoaXMg ZGlzY3Vzc2lvbiBmaXQgaW4mbmJzcDtkcmFmdC1pZXRmLTZ0aXNjaC1taW5pbWFsIG9yIGRyYWZ0 LWlldGYtNnRpc2NoLXRzY2g/IEJvdGggbWFrZSBzZW5zZSB0byBtZS48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwgTm92IDEwLCAyMDE0IGF0IDEw OjE1IEFNLCBYYXZpZXIgVmlsYWpvc2FuYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnh2aWxham9zYW5h QGVlY3MuYmVya2VsZXkuZWR1IiB0YXJnZXQ9Il9ibGFuayI+eHZpbGFqb3NhbmFAZWVjcy5iZXJr ZWxleS5lZHU8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5IaSwmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPm15IDUgY2VudHMuIEFmdGVyIHRoaW5raW5nIGFib3V0IGl0IEkgYW0gaW4gZmF2 b3VyIG9mIGFkZGluZyB0aGUgZXhhbXBsZSBhcyB0aGUgZHJhZnQgd2lsbCBiZSBtb3JlIHNlbGYt Y29udGFpbmVkIGFuZCB3aWxsIGZhY2lsaXRhdGUgdGhlIHVuZGVyc3RhbmRpbmcgb2YgaG93IGNo LiBob3BwaW5nIHNlcXVlbmNlIGlzIGNhbHVjbGF0ZWQuIChhbmFsb2dvdXNseSB0byB0aGUgT0Yw IGV4YW1wbGUpLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5yZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+WGF2aTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIwMTQtMTEtMTAgMTk6NDEgR01UJiM0 MzswMTowMCBUaG9tYXMgV2F0dGV5bmUgJmx0OzxhIGhyZWY9Im1haWx0bzp3YXR0ZXluZUBlZWNz LmJlcmtlbGV5LmVkdSIgdGFyZ2V0PSJfYmxhbmsiPndhdHRleW5lQGVlY3MuYmVya2VsZXkuZWR1 PC9hPiZndDs6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+S2Vl cyw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklu IHRoaXMgc2NyaXB0IHlvdSBtYWRlIHRoZSBhc3N1bXB0aW9uIHRoYXQgdGhlIGhvcHBpbmcgc2Vx dWVuY2UgbGVuZ3RoIGlzIGVxdWFsIHRvIHRoZSBudW1iZXIgb2YgY2hhbm5lbHMuIEkgdGhpbmsg dGhpcyBpcyByZWFzb25hYmxlIGFzc3VtcHRpb24gYnV0IGl0IGlzIG5vdCBkZWZpbmVkIGluIHRo ZSBJRUVFODAyLjE1LjRlIHN0YW5kYXJkLCBzbyBpdCB3b3VsZCBiZSBnb29kIGlkZWEgdG8gcHV0 IHRoaXMNCiBhc3N1bXB0aW9uIGluIHRoZSBkcmFmdCB0b28uPG86cD48L286cD48L3A+DQo8L2Js b2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ZZXMsIHRoYXQgd2FzIG15 IGFzc3VtcHRpb24gaW4gdGhpcyBjb2RlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0 OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Zb3UgYXJlIHVzaW5nIGNoYW5uZWwgbnVtYmVy cyAwIC0gMTUgYW5kIEkgYXNzdW1lIHRoYXQgdGhlc2UgYXJlIHRoZSAxNiAyLjVHSHogY2hhbm5l bHMuIFRoZSBJRUVFODAyLjE1LjRlIHN0YW5kYXJkIGRlZmluZSB0aGVzZSBhcyBjaGFubmVsIG51 bWJlcnMgMTEgLSAyNiBvZiBwYWdlIDAuIEl0IGlzIGZpbmUgZm9yIG1lIHRvIGtlZXAgdGhlIDAg LSAxNSBjaGFubmVsIG51bWJlcmluZyBzY2hlbWUgYnV0IGl0DQogd291bGQgZ29vZCB0byBtZW50 aW9uIHRoaXMgdG9vLiBXaGF0IGFib3V0IChmdXR1cmUpIHN1cHBvcnQgb2Ygb3RoZXIgY2hhbm5l bHMgYW5kIHBhZ2VzIGRlZmluZWQgaW4gdGhlIElFRUU4MDIuMTUuNGUgc3RhbmRhcmQ/PG86cD48 L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5D b3JyZWN0LCB5b3Ugc2hvdWxkIGFkZCAxMSB0byB0aGUgY2hhbm5lbCBudW1iZXJzIGluIHRoZSBj b2RlIHRvIHVzZSBjaGFubmVsIG51bWJlcnMgMTEtMjYgaW4gSUVFRSBub3RhdGlvbiAoMi40MDVH SHotMi40ODBHSHopLiBBRkFJQ1QsIHRoZXJlIGlzIG5vdGhpbmcgaW4gdGhlIGhvcHBpbmcgc2Vx dWVuY2Ugb2YgSUVFRTgwMi4xNS40ZS1UU0NIIHdoaWNoIHByZXZlbnRzIHRoZSB1c2Ugb2YgKGZ1 dHVyZSkgc2V0cw0KIG9mIGNoYW5uZWxzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5AYWxsPC9iPiwgd2hhdCBkbyBvdGhlcnMgdGhpbms/ IEFyZSBkZXRhaWxzIGFib3V0IHRoZSBob3BwaW5nIHNlcXVlbmNlIHNvbWV0aGluZyB3ZSBuZWVk IHRvIGFkZCB0byBkcmFmdC1pZXRmLTZ0aXNjaC1taW5pbWFsPzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4 ODgiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij5UaG9tYXM8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwgTm92IDEwLCAyMDE0IGF0IDEyOjEwIEFNLCBLZWVzIFRy b21tZWwgJmx0OzxhIGhyZWY9Im1haWx0bzpjdHJvbW1lbEBhaW12YWxsZXkubmwiIHRhcmdldD0i X2JsYW5rIj5jdHJvbW1lbEBhaW12YWxsZXkubmw8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhvbWFzLCBYYXZpLDxicj4N Cjxicj4NClRoYW5rcywgSSBjYW5ub3QgZmluZCBhbnl0aGluZyBpbiB0aGlzIHNjcmlwdCB0aGF0 IHdvdWxkIHZpb2xhdGUgdGhlIElFRUU4MDIuMTUuNGUgc3RhbmRhcmQuPGJyPg0KPGJyPg0KSW4g dGhpcyBzY3JpcHQgeW91IG1hZGUgdGhlIGFzc3VtcHRpb24gdGhhdCB0aGUgaG9wcGluZyBzZXF1 ZW5jZSBsZW5ndGggaXMgZXF1YWwgdG8gdGhlIG51bWJlciBvZiBjaGFubmVscy4gSSB0aGluayB0 aGlzIGlzIHJlYXNvbmFibGUgYXNzdW1wdGlvbiBidXQgaXQgaXMgbm90IGRlZmluZWQgaW4gdGhl IElFRUU4MDIuMTUuNGUgc3RhbmRhcmQsIHNvIGl0IHdvdWxkIGJlIGdvb2QgaWRlYSB0byBwdXQg dGhpcyBhc3N1bXB0aW9uIGluIHRoZSBkcmFmdA0KIHRvby48YnI+DQo8YnI+DQpZb3UgYXJlIHVz aW5nIGNoYW5uZWwgbnVtYmVycyAwIC0gMTUgYW5kIEkgYXNzdW1lIHRoYXQgdGhlc2UgYXJlIHRo ZSAxNiAyLjVHSHogY2hhbm5lbHMuIFRoZSBJRUVFODAyLjE1LjRlIHN0YW5kYXJkIGRlZmluZSB0 aGVzZSBhcyBjaGFubmVsIG51bWJlcnMgMTEgLSAyNiBvZiBwYWdlIDAuIEl0IGlzIGZpbmUgZm9y IG1lIHRvIGtlZXAgdGhlIDAgLSAxNSBjaGFubmVsIG51bWJlcmluZyBzY2hlbWUgYnV0IGl0IHdv dWxkIGdvb2QgdG8gbWVudGlvbg0KIHRoaXMgdG9vLiBXaGF0IGFib3V0IChmdXR1cmUpIHN1cHBv cnQgb2Ygb3RoZXIgY2hhbm5lbHMgYW5kIHBhZ2VzIGRlZmluZWQgaW4gdGhlIElFRUU4MDIuMTUu NGUgc3RhbmRhcmQ/PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxicj4NCjxicj4NCktlZXMu PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48YnI+DQo8YnI+DQpPbiAxMS8xMC8xNCAwMDoyOSwgVGhvbWFzIFdhdHRleW5lIHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5LZWVzLCBYYXZpLCA8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHRoZSBkZWZhdWx0IGhvcHBpbmcgc2VxdWVu Y2UgaXNuJ3QgY2xlYXIgaW4gSUVFRTgwMi4xNS40ZS0yMDEyLCB0aGlzIGlzIGltcG9ydGFudCBp bmZvcm1hdGlvbiB0byB0aGUgZmVkIGJhY2sgdG8gdGhlIElFRUU4MDIuMTUuNCBURy4NCjxiPkBQ YXRLaW5uZXk8L2I+LCBtYXliZSB5b3UgY2FuIGNoaW1lIGluIG9uIHdoZXRoZXIgdGhlIHJlbGF0 ZWQgdGV4dCB3aWxsIGJlIGNoYW5nZWQgaW4gSUVFRTgwMi4xNS40LTIwMTU/PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIGFueSBjYXNlLCBs ZXQncyBkaXNhbWJpZ3VhdGUgdGhlIGhvcHBpbmcgc2VxdWVuY2Ugb24gdGhpcyB0aHJlYWQuIFdl IGNvdWxkIGFkZCBhbiBleGFtcGxlIGluIGRyYWZ0LWlldGYtNnRpc2NoLW1pbmltYWwsIGFuZCBt YXliZSBhc2sgSUVFRTgwMi4xNS40IHRvIGRvIHRoZSBzYW1lLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGhhdmUgY3JlYXRlZCBzb21lIHF1 aWNrIFB5dGhvbiBjb2RlIHdoaWNoIEkgYmVsaWV2ZSBjYWxjdWxhdGVzIHRoZSBkZWZhdWx0IGhv cHBpbmcgc2VxdWVuY2UsIHNlZQ0KPGEgaHJlZj0iaHR0cHM6Ly9naXN0LmdpdGh1Yi5jb20vdHdh dHRleW5lLzJlMjJlZTNjMWE4MDJiNjg1Njk1IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL2dp c3QuZ2l0aHViLmNvbS90d2F0dGV5bmUvMmUyMmVlM2MxYTgwMmI2ODU2OTU8L2E+LjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Db3VsZCBzb21l b25lICg8Yj5QYXQ8L2I+PyA8Yj5Kb25hdGhhbjwvYj4/KSBkb3VibGUtY2hlY2sgdGhhdCBpdCBj b21wdXRlcyB0aGUgcmlnaHQNCjxzcGFuIHN0eWxlPSJjb2xvcjpibHVlO2JhY2tncm91bmQ6eWVs bG93Ij5zZXF1ZW5jZTwvc3Bhbj4uIEknbSBjb3B5LXBhc3RpbmcgdGhlIG91dHB1dCBiZWxvdy48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhv bWFzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pi0tLTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij5UaGlzIHNjcmlwdCBjYWxjdWxhdGVzIHRoZSBkZWZhdWx0IGNoYW5uZWwgaG9wcGluZyBzZXF1 ZW5jZSBmb3IgdGhlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij5JRUVFODAyLjE1LjRlLTIwMTIgVFNDSCBtb2RlLjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5cYXV0aG9yIFRob21hcyBXYXR0ZXlu ZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+XGRh dGUgTm92ZW1iZXIgMjAxNDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+XGxpY2Vuc2UgPGEgaHJlZj0iaHR0cDovL29wZW5zb3VyY2Uub3JnL2xpY2Vu c2VzL0JTRC0zLUNsYXVzZSIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cDovL29wZW5zb3VyY2Uub3Jn L2xpY2Vuc2VzL0JTRC0zLUNsYXVzZTwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij49PT0gU3RlcCBhLjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5TSFVGRkxFIGlzIGEgbWFjSG9wcGlu Z1NlcXVlbmNlTGVuZ3RoLXNpemVkIGFycmF5LiBUaGUgY29udGVudHMgb2YgdGhpcyBhcnJheSBh cjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ZSBl cXVpdmFsZW50IHRvIHRoZSBmaXJzdCBtYWNIb3BwaW5nU2VxdWVuY2VMZW5ndGggb3V0cHV0cyBv ZiBhIDktYml0IGxpbmVhciBmZWU8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPmRiYWNrIHNoaWZ0IHJlZ2lzdGVyIChMRlNSKSB3aXRoIHBvbHlub21p YWwgeDkgJiM0MzsgeDUgJiM0MzsgMSBhbmQgYSBzdGFydGluZyBzZWVkIG9mIDI8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjU1LiBFYWNoIExGU1Ig b3V0cHV0IGlzIG1vZHVsbyBtYWNIb3BwaW5nU2VxdWVuY2VMZW5ndGgsIHNvIHRoYXQgZWFjaCBl bnRyeSBvZiBTPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij5IVUZGTEUgaXMgYmV0d2VlbiAwIGFuZCAobWFjSG9wcGluZ1NlcXVlbmNlTGVuZ3RoIC0g MSksIGluY2x1c2l2ZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs1ICZu YnNwOyAmbmJzcDsgJm5ic3A7IDk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPiZuYnNwOyAmbmJzcDsxIDEgMSAxIDEgMSAxIDEgMCAoIDI1NT09MHgw ZmY9PWIwMTExMTExMTEpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4mbmJzcDsgJm5ic3A7MSAxIDEgMSAxIDEgMSAxIDEgKCA1MTE9PTB4MWZmPT1i MTExMTExMTExKSAtLSZndDsgMTU8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPiZuYnNwOyAmbmJzcDswIDEgMSAxIDEgMSAxIDEgMSAoIDUxMD09MHgx ZmU9PWIxMTExMTExMTApIC0tJmd0OyAxNDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7ICZuYnNwOzAgMCAxIDEgMSAxIDEgMSAxICggNTA4 PT0weDFmYz09YjExMTExMTEwMCkgLS0mZ3Q7IDEyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgJm5ic3A7MCAwIDAgMSAxIDEgMSAxIDEg KCA1MDQ9PTB4MWY4PT1iMTExMTExMDAwKSAtLSZndDsgODwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7ICZuYnNwOzAgMCAwIDAgMSAxIDEg MSAxICggNDk2PT0weDFmMD09YjExMTExMDAwMCkgLS0mZ3Q7IDA8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyAmbmJzcDswIDAgMCAwIDAg MSAxIDEgMSAoIDQ4MD09MHgxZTA9PWIxMTExMDAwMDApIC0tJmd0OyAwPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgJm5ic3A7MSAwIDAg MCAwIDAgMSAxIDEgKCA0NDk9PTB4MWMxPT1iMTExMDAwMDAxKSAtLSZndDsgMTwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7ICZuYnNwOzEg MSAwIDAgMCAwIDAgMSAxICggMzg3PT0weDE4Mz09YjExMDAwMDAxMSkgLS0mZ3Q7IDM8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyAmbmJz cDsxIDEgMSAwIDAgMCAwIDAgMSAoIDI2Mz09MHgxMDc9PWIxMDAwMDAxMTEpIC0tJmd0OyA3PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsg Jm5ic3A7MSAxIDEgMSAwIDAgMCAwIDAgKCAmbmJzcDsxNT09MHgwMGY9PWIwMDAwMDExMTEpIC0t Jmd0OyAxNTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Jm5ic3A7ICZuYnNwOzAgMSAxIDEgMSAwIDAgMCAwICggJm5ic3A7MzA9PTB4MDFlPT1iMDAw MDExMTEwKSAtLSZndDsgMTQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPiZuYnNwOyAmbmJzcDsxIDAgMSAxIDEgMSAwIDAgMCAoICZuYnNwOzYxPT0w eDAzZD09YjAwMDExMTEwMSkgLS0mZ3Q7IDEzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgJm5ic3A7MSAxIDAgMSAxIDEgMSAwIDAgKCAx MjM9PTB4MDdiPT1iMDAxMTExMDExKSAtLSZndDsgMTE8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyAmbmJzcDsxIDEgMSAwIDEgMSAxIDEg MCAoIDI0Nz09MHgwZjc9PWIwMTExMTAxMTEpIC0tJmd0OyA3PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgJm5ic3A7MSAxIDEgMSAwIDEg MSAxIDEgKCA0OTU9PTB4MWVmPT1iMTExMTAxMTExKSAtLSZndDsgMTU8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyAmbmJzcDsxIDEgMSAx IDEgMCAxIDEgMSAoIDQ3OT09MHgxZGY9PWIxMTEwMTExMTEpIC0tJmd0OyAxNTwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5TSFVGRkxFOiAmbmJz cDtbMTUsIDE0LCAxMiwgOCwgMCwgMCwgMSwgMywgNywgMTUsIDE0LCAxMywgMTEsIDcsIDE1LCAx NV08L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ PT09IFN0ZXAgYi48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+Q0hBTk5FTFMgaXMgYSBtYWNIb3BwaW5nU2VxdWVuY2VMZW5ndGgtc2l6ZWQgYXJy YXkgdGhhdCBpcyBpbml0aWFsbHkgcG9wdWxhdGVkIHc8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPml0aCB0aGUgbW9ub3RvbmljYWxseSBpbmNyZWFz aW5nIGxpc3Qgb2YgY2hhbm5lbHMgYXZhaWxhYmxlIHRvIHRoZSBQSFkuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkNIQU5ORUxTOiBbMCwgMSwg MiwgMywgNCwgNSwgNiwgNywgOCwgOSwgMTAsIDExLCAxMiwgMTMsIDE0LCAxNV08L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PT09IFN0ZXAgYy48 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Q0hB Tk5FTFMgaXMgc2h1ZmZsZWQgYXMgcGVyIEZpZ3VyZSA3YS4gRWxlbWVudHMgbWF5IHdpbmQgdXAg YmVpbmcgc3dhcHBlZCBtdWx0aXA8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPmxlIHRpbWVzIGluIHRoaXMgcHJvY2Vzcy48L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+bWFjSG9wcGluZ1NlcXVlbmNl TGlzdDoNCjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpibHVlO2JhY2tncm91bmQ6eWVsbG93Ij5bNSwg NiwgMTIsIDcsIDE1LCA0LCAxNCwgMTEsIDgsIDAsIDEsIDIsIDEzLCAzLCA5LCAxMF08L3NwYW4+ PC9iPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPlNjcmlwdCBlbmRlZCBub3JtYWxseSwgcHJlc3MgRW50ZXIgdG8gY2xvc2UuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48YnI+DQpPbiBGcmlkYXksIE5vdmVtYmVyIDcsIDIwMTQsIFhhdmllciBWaWxham9zYW5hICZs dDs8YSBocmVmPSJtYWlsdG86eHZpbGFqb3NhbmFAZWVjcy5iZXJrZWxleS5lZHUiIHRhcmdldD0i X2JsYW5rIj54dmlsYWpvc2FuYUBlZWNzLmJlcmtlbGV5LmVkdTwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRlYXIgS2VlcywgPG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dGhhbmtzIGZvciB5b3VyIGNv bW1lbnRzLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5hbnN3ZXJpbmcgMSk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JTUhPIHRoZSBmYWN0IHRoYXQgaWYgZGVmYXVsdCBj aC4gaG9wcGluZyBzZXF1ZW5jZSBpcyBiZWluZyB1c2VkDQo8Yj5tYXkgbm90IGJlPC9iPiBhZHZl cnRpc2VkIGluIHRoZSBFQiBpdCBpcyBub3QgY2xlYXIgaW4gdGhlIHN0YW5kYXJkLiBBbmQgdGhl cmVmb3JlIEkgb3B0ZWQgdG8gbWFrZSB0aGUgRUIgZXhwbGljaXQgKGV2ZW4gb25seSBhbiBJRCBh bmQgdGhpcyBiZWluZyB0aGUgZGVmYXVsdCk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBhZ2UgMTEgb2YgdGhlIDE1LjRlIGFtZW5kbWVudCBpbmRp Y2F0ZXMgdGhhdDo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGk+QWxsIGhvcHBpbmcgc2VxdWVuY2VzIGFyZSByZWZlcnJlZCB0byBieSBhbiBJ RCwgbWFjSG9wcGluZ1NlcXVlbmNlSUQsIHdpdGggSUQgPSAwIGRlbm90aW5nIHRoZSBkZWZhdWx0 PC9pPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGk+c2VxdWVuY2UgZm9yIGEgcGFydGljdWxhciBQSFkgKG9yIFBIWSBjb25maWd1cmF0aW9uIGlm IHRoZSBQSFkgc3VwcG9ydHMgbW9yZSB0aGFuIG9uZSBjaGFubmVsIGxpc3QpLjwvaT48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dGhlbiBwYWdl IDkyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 aT5UaGUgZnVsbCBIb3BwaW5nIFNlcXVlbmNlIG1heSBiZSBvbWl0dGVkIHRvIGVuc3VyZSB0aGF0 IHRoZSBmcmFtZSBkb2VzIG5vdCBleGNlZWQgYU1heFBIWVBhY2tldFNpemUuPC9pPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGk+SW4gdGhpcyBj YXNlIG9ubHkgdGhlIEhvcHBpbmcgU2VxdWVuY2UgSUQgaXMgY2FycmllZCwgYW5kIHRoZSBsZW5n dGggb2YgdGhlIElFIGlzIDEgb2N0ZXQuIFdoZW4gdGhlIGxlbmd0aCBpczwvaT48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxpPm5vdCBlcXVhbCB0 byBvbmUsIHRoZSBhZGRpdGlvbmFsIGZpZWxkcyBhcmUgcHJlc2VudC4gVGhlIGVsZW1lbnQgdmFy aWVzIGluIGxlbmd0aCBkZXBlbmRpbmcgdXBvbiB0aGU8L2k+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT5udW1iZXJPZkNoYW5uZWxzIGluIHVz ZSBieSB0aGUgUEhZLiBUaGUgY2hhbm5lbFBhZ2UgYW5kIG51bWJlck9mQ2hhbm5lbHMgYXR0cmli dXRlcyBjYW4gYmUgdXNlZCB0bzwvaT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxpPmRldGVybWluZSB0aGUgc2l6ZSBvZiB0aGUgZXh0ZW5kZWRC aXRtYXAsIGFuZCB0aGUgbWFjSG9wcGluZ1NlcXVlbmNlTGVuZ3RoIGNhbiBiZSB1c2VkIHRvIGRl dGVybWluZTwvaT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxpPnRoZSBzaXplIG9mIHRoZSBtYWNIb3BwaW5nU2VxdWVuY2VMaXN0LjwvaT48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxpPlRoZSBD aGFubmVsIEhvcHBpbmcgSUUgPGI+bWF5PC9iPiBiZSB1c2VkIGJ5IGFueSBjaGFubmVsIGhvcHBp bmcgUEFOIHRvIHN5bmNocm9uaXplIGRldmljZXMuPC9pPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk15IGxhc3QgcG9pbnQgaGVy ZSBpcyB0aGF0IHRoaXMgPGI+bWF5PC9iPiZuYnNwO21pZ2h0IGluZGljYXRlIG9wdGlvbmFsaXR5 IGJ1dCB0aGUgY2FzZSBmb3IgdGhlIGRlZmF1bHQgaWQgaXMgbm90IG1lbnRpb25lZCBzbyBJIGFt IG5vdCBzdXJlIGl0IGNhbiBiZSBlbGlkZWQgaWYgZGVmYXVsdCBpZCAoMCk8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YW5zd2VyaW5nIDIpIGl0 IHNlZW1zIGEgZ29vZCBwb2ludC4gTGV0IHVzIHRoaW5rIGFib3V0IGl0LjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5yZWdhcmRzLDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WGF2aTxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yMDE0LTExLTA3 IDk6NTcgR01UJiM0MzswMTowMCBLZWVzIFRyb21tZWwgJmx0OzxhIGhyZWY9Im1haWx0bzpjdHJv bW1lbEBhaW12YWxsZXkubmwiPmN0cm9tbWVsQGFpbXZhbGxleS5ubDwvYT4mZ3Q7OjxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGksPGJy Pg0KPGJyPg0KVGhpcyBkcmFmdCBzcGVjaWZpZXMgdGhhdCB0aGUgZW5oYW5jZWQgYmVhY29uIHNo b3VsZCBpbmNsdWRlIGEgQ2hhbm5lbCBIb3BwaW5nIElFIHdpdGggYSBIb3BwaW5nIFNlcXVlbmNl IElEIGVxdWFsIHRvIDAuIEhvcHBpbmcgU2VxdWVuY2UgSUQgMCBpcyB0aGUgZGVmYXVsdCBob3Bw aW5nIHNlcXVlbmNlIElELiBTbyB0aGUgYWN0dWFsIGhvcHBpbmcgc2VxdWVuY2Ugd2lsbCBub3Qg YmUgaW5jbHVkZWQgaW4gdGhlIGVuaGFuY2VkIGJlYWNvbi48YnI+DQo8YnI+DQpTZWN0aW9uIDUu MS4xYSBvZiB0aGUgSUVFODAyLjI1LjRlIHN0YW5kYXJkIGRlZmluZXMgYW4gYWxnb3JpdGhtIHRv IGNhbGN1bGF0ZSBhIGRlZmF1bHQgaG9wcGluZyBzZXF1ZW5jZSBJRC4NCjxicj4NCjxicj4NCkkg aGF2ZSB0aGUgZm9sbG93aW5nIHF1ZXN0aW9ucyByZWdhcmRpbmcgdGhlIGRlZmF1bHQgaG9wcGlu ZyBzZXF1ZW5jZTo8YnI+DQo8YnI+DQoxLiBJcyBpdCB0aGUgaW50ZW50aW9uIHRoYXQgYSBtaW5p bWFsIGNvbmZpZ3VyYXRpb24gdXNlcyB0aGUgZGVmYXVsdCBob3BwaW5nIHNlcXVlbmNlIGFzIGRl ZmluZWQgaW4gdGhlIElFRTgwMi4yNS40ZSBzdGFuZGFyZD88YnI+DQoyLiBJZiB0aGUgYW5zd2Vy IG9uIDEuIGlzIHllczombmJzcDsgVGhlIGRlZmluaXRpb24gb2YgdGhlIElFRTgwMi4yNS40ZSBo b3BwaW5nIHNlcXVlbmNlIChpbiBteSBvcGluaW9uKSBpcyBub3QgdW5hbWJpZ3VvdXMsIHNvIGNh biB5b3UgYWRkIHRoZSBhY3R1YWwgZGVmYXVsdCBob3BwaW5nIHNlcXVlbmNlIHRvIHRoaXMgZHJh ZnQ/PGJyPg0KPGJyPg0KUmVnYXJkcyw8YnI+DQo8YnI+DQpLZWVzLjxicj4NCjxicj4NCk9uIE9j dCAyNywgMjAxNCwgYXQgMTI6MjAgQU0sIFhhdmllciBWaWxham9zYW5hICZsdDt4dmlsYWpvc2Fu YSBhdCBlZWNzLmJlcmtlbGV5LmVkdSZndDsgd3JvdGU6PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFsbCwgSSBqdXN0 IHB1Ymxpc2hlZCB0aGUgbmV3IHZlcnNpb24gb2YgbWluaW1hbC4gSXQgaW5jbHVkZXMgYSBzZWN1 cml0eSBzZWN0aW9uIGFzIGRpc2N1c3NlZCBsYXN0IGNhbGwgYW5kIHNvbWUgY2hhbmdlcyB0byB0 aGUgZGVmYXVsdCB0aW1pbmcgdG8gYmUgYWNjb3JkaW5nIHRvIDE1LjQgdHNjaCBkZWZhdWx0IHZh bHVlcy4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+cmVn YXJkcyw8YnI+DQpYYXZpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4tLS0tLS0tLS0tIEZvcndhcmRlZCBtZXNzYWdlIC0tLS0tLS0tLS08YnI+DQpGcm9tOiAm bHQ7aW50ZXJuZXQtZHJhZnRzIGF0IGlldGYub3JnJmd0Ozxicj4NCkRhdGU6IDIwMTQtMTAtMjcg NToxNyBHTVQmIzQzOzAxOjAwPGJyPg0KU3ViamVjdDogWzZ0aXNjaF0gSS1EIEFjdGlvbjogZHJh ZnQtaWV0Zi02dGlzY2gtbWluaW1hbC0wMy50eHQ8YnI+DQpUbzogaS1kLWFubm91bmNlIGF0IGll dGYub3JnPGJyPg0KQ2M6IDZ0aXNjaCBhdCBpZXRmLm9yZzxicj4NCjxicj4NCjxicj4NCjxicj4N CkEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVy bmV0LURyYWZ0cyBkaXJlY3Rvcmllcy48YnI+DQombmJzcDtUaGlzIGRyYWZ0IGlzIGEgd29yayBp dGVtIG9mIHRoZSBJUHY2IG92ZXIgdGhlIFRTQ0ggbW9kZSBvZiBJRUVFIDgwMi4xNS40ZSBXb3Jr aW5nIEdyb3VwIG9mIHRoZSBJRVRGLjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyBUaXRsZSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7OiBNaW5p bWFsIDZUaVNDSCBDb25maWd1cmF0aW9uPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IEF1dGhvcnMmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7OiBYYXZpZXIgVmlsYWpv c2FuYTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBLcmlzIFBpc3Rlcjxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBGaWxlbmFtZSZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyA6IGRyYWZ0LWlldGYtNnRpc2NoLW1pbmltYWwtMDMudHh0PGJyPg0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFBhZ2VzJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDs6IDIyPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IERhdGUmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA6IDIwMTQtMTAtMjY8YnI+DQo8 YnI+DQpBYnN0cmFjdDo8YnI+DQombmJzcDsgJm5ic3A7VGhpcyBkb2N1bWVudCBkZXNjcmliZXMg dGhlIG1pbmltYWwgc2V0IG9mIHJ1bGVzIHRvIG9wZXJhdGUgYTxicj4NCiZuYnNwOyAmbmJzcDtb SUVFRTgwMjE1NGVdIFRpbWVzbG90dGVkIENoYW5uZWwgSG9wcGluZyAoVFNDSCkgbmV0d29yay4m bmJzcDsgVGhpczxicj4NCiZuYnNwOyAmbmJzcDttaW5pbWFsIG1vZGUgb2Ygb3BlcmF0aW9uIGNh biBiZSB1c2VkIGR1cmluZyBuZXR3b3JrIGJvb3RzdHJhcCwgYXMgYTxicj4NCiZuYnNwOyAmbmJz cDtmYWxsLWJhY2sgbW9kZSBvZiBvcGVyYXRpb24gd2hlbiBubyBkeW5hbWljIHNjaGVkdWxpbmcg c29sdXRpb24gaXM8YnI+DQombmJzcDsgJm5ic3A7YXZhaWxhYmxlIG9yIGZ1bmN0aW9uaW5nLCBv ciBkdXJpbmcgZWFybHkgaW50ZXJvcGVyYWJpbGl0eSB0ZXN0aW5nPGJyPg0KJm5ic3A7ICZuYnNw O2FuZCBkZXZlbG9wbWVudC48YnI+DQo8YnI+DQo8YnI+DQpUaGUgSUVURiBkYXRhdHJhY2tlciBz dGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczo8YnI+DQo8YSBocmVmPSJodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLTZ0aXNjaC1taW5pbWFsLyIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtNnRpc2No LW1pbmltYWwvPC9hPjxicj4NCjxicj4NClRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24g YXZhaWxhYmxlIGF0Ojxicj4NCjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtNnRpc2NoLW1pbmltYWwtMDMiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLTZ0aXNjaC1taW5pbWFsLTAzPC9hPjxicj4NCjxicj4N CkEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDo8YnI+DQo8 YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLTZ0aXNj aC1taW5pbWFsLTAzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZm P3VybDI9ZHJhZnQtaWV0Zi02dGlzY2gtbWluaW1hbC0wMzwvYT48YnI+DQo8YnI+DQo8YnI+DQpQ bGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUg dGltZSBvZiBzdWJtaXNzaW9uPGJyPg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRp ZmYgYXJlIGF2YWlsYWJsZSBhdCA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj4NCnRvb2xzLmlldGYub3JnPC9hPi48YnI+DQo8YnI+DQpJbnRlcm5ldC1EcmFm dHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6PGJyPg0KPGEgaHJlZj0i ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8iIHRhcmdldD0iX2JsYW5rIj5mdHA6 Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLzwvYT48YnI+DQo8YnI+DQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCjZ0aXNjaCBtYWlsaW5n IGxpc3Q8YnI+DQo2dGlzY2ggYXQgaWV0Zi5vcmc8YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvLzZ0aXNjaCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vNnRpc2NoPC9hPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KNnRpc2NoIG1haWxp bmcgbGlzdDxicj4NCjZ0aXNjaCBhdCBpZXRmLm9yZzxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vNnRpc2NoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby82dGlzY2g8L2E+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCjZ0aXNjaCBtYWlsaW5nIGxpc3Q8YnI+DQo8 YSBocmVmPSJtYWlsdG86NnRpc2NoQGlldGYub3JnIj42dGlzY2hAaWV0Zi5vcmc8L2E+PGJyPg0K PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby82dGlzY2giIHRh cmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvLzZ0aXNj aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_E045AECD98228444A58C61C200AE1BD848A48886xmbrcdx01ciscoc_-- From nobody Mon Nov 10 16:54:05 2014 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC1FB1AD384 for <6tisch@ietfa.amsl.com>; Mon, 10 Nov 2014 16:54:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0EdZaK1UPk0i for <6tisch@ietfa.amsl.com>; Mon, 10 Nov 2014 16:53:56 -0800 (PST) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D3571AD37F for <6tisch@ietf.org>; Mon, 10 Nov 2014 16:53:56 -0800 (PST) Received: by mail-pa0-f47.google.com with SMTP id kx10so9342299pab.6 for <6tisch@ietf.org>; Mon, 10 Nov 2014 16:53:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=tbdQqm7EXIqoAp0JGUZJXEm5flmS2U4k0VFZ1HGLScQ=; b=lYNy5EyLxBsspN2bnqNbITJc/TeuNfJHUtczkmiHfZuLWzqBsLTyCYgoFHbj+2SrfI yPlsSdr8SDvgi4UrDOzShCdmBY5opry4mYc+h8/bRtsudiF+DN9g19bCgfGmJyU7N5o2 SId+vfK9oEtARV4o+gG1RFpwWcylHi795Qua5MEOBm+RwrbnEkJKIKg7gpvx2T+6TDSl NAg/0/KLAebffpixQQ7hLR/aufOZL2GOOUvGjekLJDKOrYupWpSU1orJM4iiD964mLxM 4akgl/qwMg9FvVnOknhoVCPcsy4M75DD4fyUjSOwcTJ70fm8gGPWZxisYVcdu+W+lrUb nToA== X-Received: by 10.66.233.98 with SMTP id tv2mr33901813pac.94.1415667235815; Mon, 10 Nov 2014 16:53:55 -0800 (PST) MIME-Version: 1.0 Sender: twatteyne@gmail.com Received: by 10.66.88.42 with HTTP; Mon, 10 Nov 2014 16:53:35 -0800 (PST) In-Reply-To: References: <545C898A.8060300@aimvalley.nl> <54608F2A.7090708@aimvalley.nl> From: Thomas Watteyne Date: Mon, 10 Nov 2014 14:53:35 -1000 X-Google-Sender-Auth: sgw0VBO-b18LZHZ3JRnVX8hs3hs Message-ID: To: "Pascal Thubert (pthubert)" Content-Type: multipart/alternative; boundary=047d7b15a453b60c2205078ab6c0 Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch/1Xw9eB61mZvQo3FIRdv6cnagBs8 Cc: Kees Trommel , "6tisch@ietf.org" <6tisch@ietf.org>, Xavier Vilajosana Subject: Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-03.txt X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 00:54:01 -0000 --047d7b15a453b60c2205078ab6c0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Pascal, draft-ietf-6tisch-minimal should contain that it requires the default channel hopping pattern. I think we agree on that. The description of what the default channel hopping pattern is (this is just a discussion about IEEE802.15.4e-2012, nothing 6TiSCH specific), might end up in 6tisch/draft-ietf-6tisch-tsch. What do others think? Thomas On Mon, Nov 10, 2014 at 10:57 AM, Pascal Thubert (pthubert) < pthubert@cisco.com> wrote: > Hi Thomas: > > > > I think: > > - that the TSCH draft could discuss what is sub-defined in TSCH, indicate > that we use the range 0-15, to address Kees=E2=80=99 points > > - but then, the setting to be used in minimal, and pseudo code along the > lines you produced should go in minimal to ensure interop. The pseudo cod= e > would be an appendix. > > > > Makes sense? > > > > Pascal > > > > *From:* 6tisch [mailto:6tisch-bounces@ietf.org] *On Behalf Of *Thomas > Watteyne > *Sent:* lundi 10 novembre 2014 12:17 > *To:* Xavier Vilajosana > *Cc:* Kees Trommel; 6tisch@ietf.org > *Subject:* Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-03.txt > > > > Quick thought: does this discussion fit in draft-ietf-6tisch-minimal or > draft-ietf-6tisch-tsch? Both make sense to me. > > > > On Mon, Nov 10, 2014 at 10:15 AM, Xavier Vilajosana < > xvilajosana@eecs.berkeley.edu> wrote: > > Hi, > > > > my 5 cents. After thinking about it I am in favour of adding the example > as the draft will be more self-contained and will facilitate the > understanding of how ch. hopping sequence is caluclated. (analogously to > the OF0 example). > > > > regards, > > Xavi > > > > 2014-11-10 19:41 GMT+01:00 Thomas Watteyne : > > Kees, > > > > In this script you made the assumption that the hopping sequence length i= s > equal to the number of channels. I think this is reasonable assumption bu= t > it is not defined in the IEEE802.15.4e standard, so it would be good idea > to put this assumption in the draft too. > > > > Yes, that was my assumption in this code. > > > > You are using channel numbers 0 - 15 and I assume that these are the 16 > 2.5GHz channels. The IEEE802.15.4e standard define these as channel numbe= rs > 11 - 26 of page 0. It is fine for me to keep the 0 - 15 channel numbering > scheme but it would good to mention this too. What about (future) support > of other channels and pages defined in the IEEE802.15.4e standard? > > > > Correct, you should add 11 to the channel numbers in the code to use > channel numbers 11-26 in IEEE notation (2.405GHz-2.480GHz). AFAICT, there > is nothing in the hopping sequence of IEEE802.15.4e-TSCH which prevents t= he > use of (future) sets of channels. > > > > *@all*, what do others think? Are details about the hopping sequence > something we need to add to draft-ietf-6tisch-minimal? > > > > Thomas > > > > On Mon, Nov 10, 2014 at 12:10 AM, Kees Trommel > wrote: > > Thomas, Xavi, > > Thanks, I cannot find anything in this script that would violate the > IEEE802.15.4e standard. > > In this script you made the assumption that the hopping sequence length i= s > equal to the number of channels. I think this is reasonable assumption bu= t > it is not defined in the IEEE802.15.4e standard, so it would be good idea > to put this assumption in the draft too. > > You are using channel numbers 0 - 15 and I assume that these are the 16 > 2.5GHz channels. The IEEE802.15.4e standard define these as channel numbe= rs > 11 - 26 of page 0. It is fine for me to keep the 0 - 15 channel numbering > scheme but it would good to mention this too. What about (future) support > of other channels and pages defined in the IEEE802.15.4e standard? > > Kees. > > > > On 11/10/14 00:29, Thomas Watteyne wrote: > > Kees, Xavi, > > > > If the default hopping sequence isn't clear in IEEE802.15.4e-2012, this i= s > important information to the fed back to the IEEE802.15.4 TG. *@PatKinney= *, > maybe you can chime in on whether the related text will be changed in > IEEE802.15.4-2015? > > > > In any case, let's disambiguate the hopping sequence on this thread. We > could add an example in draft-ietf-6tisch-minimal, and maybe ask > IEEE802.15.4 to do the same. > > > > I have created some quick Python code which I believe calculates the > default hopping sequence, see > https://gist.github.com/twatteyne/2e22ee3c1a802b685695. > > > > Could someone (*Pat*? *Jonathan*?) double-check that it computes the > right sequence. I'm copy-pasting the output below. > > > > Thomas > > > > --- > > > > This script calculates the default channel hopping sequence for the > > IEEE802.15.4e-2012 TSCH mode. > > > > \author Thomas Watteyne > > \date November 2014 > > \license http://opensource.org/licenses/BSD-3-Clause > > > > > > =3D=3D=3D Step a. > > > > SHUFFLE is a macHoppingSequenceLength-sized array. The contents of this > array ar > > e equivalent to the first macHoppingSequenceLength outputs of a 9-bit > linear fee > > dback shift register (LFSR) with polynomial x9 + x5 + 1 and a starting > seed of 2 > > 55. Each LFSR output is modulo macHoppingSequenceLength, so that each > entry of S > > HUFFLE is between 0 and (macHoppingSequenceLength - 1), inclusive. > > > > 5 9 > > 1 1 1 1 1 1 1 1 0 ( 255=3D=3D0x0ff=3D=3Db011111111) > > 1 1 1 1 1 1 1 1 1 ( 511=3D=3D0x1ff=3D=3Db111111111) --> 15 > > 0 1 1 1 1 1 1 1 1 ( 510=3D=3D0x1fe=3D=3Db111111110) --> 14 > > 0 0 1 1 1 1 1 1 1 ( 508=3D=3D0x1fc=3D=3Db111111100) --> 12 > > 0 0 0 1 1 1 1 1 1 ( 504=3D=3D0x1f8=3D=3Db111111000) --> 8 > > 0 0 0 0 1 1 1 1 1 ( 496=3D=3D0x1f0=3D=3Db111110000) --> 0 > > 0 0 0 0 0 1 1 1 1 ( 480=3D=3D0x1e0=3D=3Db111100000) --> 0 > > 1 0 0 0 0 0 1 1 1 ( 449=3D=3D0x1c1=3D=3Db111000001) --> 1 > > 1 1 0 0 0 0 0 1 1 ( 387=3D=3D0x183=3D=3Db110000011) --> 3 > > 1 1 1 0 0 0 0 0 1 ( 263=3D=3D0x107=3D=3Db100000111) --> 7 > > 1 1 1 1 0 0 0 0 0 ( 15=3D=3D0x00f=3D=3Db000001111) --> 15 > > 0 1 1 1 1 0 0 0 0 ( 30=3D=3D0x01e=3D=3Db000011110) --> 14 > > 1 0 1 1 1 1 0 0 0 ( 61=3D=3D0x03d=3D=3Db000111101) --> 13 > > 1 1 0 1 1 1 1 0 0 ( 123=3D=3D0x07b=3D=3Db001111011) --> 11 > > 1 1 1 0 1 1 1 1 0 ( 247=3D=3D0x0f7=3D=3Db011110111) --> 7 > > 1 1 1 1 0 1 1 1 1 ( 495=3D=3D0x1ef=3D=3Db111101111) --> 15 > > 1 1 1 1 1 0 1 1 1 ( 479=3D=3D0x1df=3D=3Db111011111) --> 15 > > > > SHUFFLE: [15, 14, 12, 8, 0, 0, 1, 3, 7, 15, 14, 13, 11, 7, 15, 15] > > > > =3D=3D=3D Step b. > > > > CHANNELS is a macHoppingSequenceLength-sized array that is initially > populated w > > ith the monotonically increasing list of channels available to the PHY. > > > > CHANNELS: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15] > > > > =3D=3D=3D Step c. > > > > CHANNELS is shuffled as per Figure 7a. Elements may wind up being swapped > multip > > le times in this process. > > > > macHoppingSequenceList: *[5, 6, 12, 7, 15, 4, 14, 11, 8, 0, 1, 2, 13, 3, > 9, 10]* > > > > > > Script ended normally, press Enter to close. > > > On Friday, November 7, 2014, Xavier Vilajosana < > xvilajosana@eecs.berkeley.edu> wrote: > > Dear Kees, > > thanks for your comments. > > > > answering 1) > > IMHO the fact that if default ch. hopping sequence is being used *may not > be* advertised in the EB it is not clear in the standard. And therefore I > opted to make the EB explicit (even only an ID and this being the default= ) > > Page 11 of the 15.4e amendment indicates that: > > > > *All hopping sequences are referred to by an ID, macHoppingSequenceID, > with ID =3D 0 denoting the default* > > *sequence for a particular PHY (or PHY configuration if the PHY supports > more than one channel list).* > > > > then page 92 > > *The full Hopping Sequence may be omitted to ensure that the frame does > not exceed aMaxPHYPacketSize.* > > *In this case only the Hopping Sequence ID is carried, and the length of > the IE is 1 octet. When the length is* > > *not equal to one, the additional fields are present. The element varies > in length depending upon the* > > *numberOfChannels in use by the PHY. The channelPage and numberOfChannels > attributes can be used to* > > *determine the size of the extendedBitmap, and the > macHoppingSequenceLength can be used to determine* > > *the size of the macHoppingSequenceList.* > > *The Channel Hopping IE may be used by any channel hopping PAN to > synchronize devices.* > > > > My last point here is that this *may* might indicate optionality but the > case for the default id is not mentioned so I am not sure it can be elide= d > if default id (0) > > > > answering 2) it seems a good point. Let us think about it. > > > > regards, > > Xavi > > > > 2014-11-07 9:57 GMT+01:00 Kees Trommel : > > Hi, > > This draft specifies that the enhanced beacon should include a Channel > Hopping IE with a Hopping Sequence ID equal to 0. Hopping Sequence ID 0 i= s > the default hopping sequence ID. So the actual hopping sequence will not = be > included in the enhanced beacon. > > Section 5.1.1a of the IEE802.25.4e standard defines an algorithm to > calculate a default hopping sequence ID. > > I have the following questions regarding the default hopping sequence: > > 1. Is it the intention that a minimal configuration uses the default > hopping sequence as defined in the IEE802.25.4e standard? > 2. If the answer on 1. is yes: The definition of the IEE802.25.4e hoppin= g > sequence (in my opinion) is not unambiguous, so can you add the actual > default hopping sequence to this draft? > > Regards, > > Kees. > > On Oct 27, 2014, at 12:20 AM, Xavier Vilajosana eecs.berkeley.edu> wrote: > > > All, I just published the new version of minimal. It includes a > security section as discussed last call and some changes to the default > timing to be according to 15.4 tsch default values. > > > > regards, > Xavi > > > > ---------- Forwarded message ---------- > From: > Date: 2014-10-27 5:17 GMT+01:00 > Subject: [6tisch] I-D Action: draft-ietf-6tisch-minimal-03.txt > To: i-d-announce at ietf.org > Cc: 6tisch at ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IPv6 over the TSCH mode of IEEE > 802.15.4e Working Group of the IETF. > > Title : Minimal 6TiSCH Configuration > Authors : Xavier Vilajosana > Kris Pister > Filename : draft-ietf-6tisch-minimal-03.txt > Pages : 22 > Date : 2014-10-26 > > Abstract: > This document describes the minimal set of rules to operate a > [IEEE802154e] Timeslotted Channel Hopping (TSCH) network. This > minimal mode of operation can be used during network bootstrap, as a > fall-back mode of operation when no dynamic scheduling solution is > available or functioning, or during early interoperability testing > and development. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-6tisch-minimal-03 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6tisch-minimal-03 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > 6tisch mailing list > 6tisch at ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > > > > _______________________________________________ > 6tisch mailing list > 6tisch at ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > > > > > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > > > > > > > > > > > --047d7b15a453b60c2205078ab6c0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Pascal,

    draft-ietf-6tisch-minimal shoul= d contain that it requires the default channel hopping pattern. I think we = agree on that.

    The description of what the default= channel hopping pattern is (this is just a discussion about IEEE802.15.4e-= 2012, nothing 6TiSCH specific), might end up in=C2=A06tisch/draft-ietf-6tis= ch-tsch.

    What do others think?

    Thomas



    On Mon, Nov 10, 2014 at 10:57 AM, Pasc= al Thubert (pthubert) <pthubert@cisco.com> wrote:

    Hi Thomas:<= /span>

    =C2=A0

    I think:

    - that the TSCH draft cou= ld discuss what is sub-defined in TSCH, indicate that we use the range 0-15= , to address Kees=E2=80=99 points

    - but then, the setting t= o be used in minimal, and pseudo code along the lines you produced should g= o in minimal to ensure interop. The pseudo code would be an appendix.

    =C2=A0

    Makes sense?

    =C2=A0

    Pascal

    =C2=A0

    From: 6tisch [= mailto:6tisch-= bounces@ietf.org] On Behalf Of Thomas Watteyne
    Sent: lundi 10 novembre 2014 12:17
    To: Xavier Vilajosana
    Cc: Kees Trommel; 6tisch@ietf.org
    Subject: Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-03.txt

    =C2=A0

    Quick thought: does this discussion fit in=C2=A0draf= t-ietf-6tisch-minimal or draft-ietf-6tisch-tsch? Both make sense to me.<= /u>

    =C2=A0

    On Mon, Nov 10, 2014 at 10:15 AM, Xavier Vilajosana = <xvil= ajosana@eecs.berkeley.edu> wrote:

    Hi,=C2=A0

    =C2=A0

    my 5 cents. After thinking about it I am in favour o= f adding the example as the draft will be more self-contained and will faci= litate the understanding of how ch. hopping sequence is caluclated. (analog= ously to the OF0 example).=C2=A0

    =C2=A0

    regards,

    Xavi

    =C2=A0

    2014-11-10 19:41 GMT+01:00 Thomas Watteyne <watteyne@eecs.be= rkeley.edu>:

    Kees,

    =C2=A0

    In this script you made the assumption that the hopp= ing sequence length is equal to the number of channels. I think this is rea= sonable assumption but it is not defined in the IEEE802.15.4e standard, so = it would be good idea to put this assumption in the draft too.

    =C2=A0

    Yes, that was my assumption in this code.<= /u>

    =C2=A0

    You are using channel numbers 0 - 15 and I assume th= at these are the 16 2.5GHz channels. The IEEE802.15.4e standard define thes= e as channel numbers 11 - 26 of page 0. It is fine for me to keep the 0 - 1= 5 channel numbering scheme but it would good to mention this too. What about (future) support of other chann= els and pages defined in the IEEE802.15.4e standard?

    =C2=A0

    Correct, you should add 11 to the channel numbers in= the code to use channel numbers 11-26 in IEEE notation (2.405GHz-2.480GHz)= . AFAICT, there is nothing in the hopping sequence of IEEE802.15.4e-TSCH wh= ich prevents the use of (future) sets of channels.

    =C2=A0

    @all, what do others think? Are details about= the hopping sequence something we need to add to draft-ietf-6tisch-minimal= ?

    =C2=A0

    Thomas

    =C2=A0

    On Mon, Nov 10, 2014 at 12:10 AM, Kees Trommel <<= a href=3D"mailto:ctrommel@aimvalley.nl" target=3D"_blank">ctrommel@aimvalle= y.nl> wrote:

    Thomas, Xavi,

    Thanks, I cannot find anything in this script that would violate the IEEE80= 2.15.4e standard.

    In this script you made the assumption that the hopping sequence length is = equal to the number of channels. I think this is reasonable assumption but = it is not defined in the IEEE802.15.4e standard, so it would be good idea t= o put this assumption in the draft too.

    You are using channel numbers 0 - 15 and I assume that these are the 16 2.5= GHz channels. The IEEE802.15.4e standard define these as channel numbers 11= - 26 of page 0. It is fine for me to keep the 0 - 15 channel numbering sch= eme but it would good to mention this too. What about (future) support of other channels and pages defined = in the IEEE802.15.4e standard?

    Kees.



    On 11/10/14 00:29, Thomas Watteyne wrote:

    Kees, Xavi,

    =C2=A0

    If the default hopping sequence isn't clear in I= EEE802.15.4e-2012, this is important information to the fed back to the IEE= E802.15.4 TG. @PatKinney, maybe you can chime in on whether the related text will = be changed in IEEE802.15.4-2015?

    =C2=A0

    In any case, let's disambiguate the hopping sequ= ence on this thread. We could add an example in draft-ietf-6tisch-minimal, = and maybe ask IEEE802.15.4 to do the same.

    =C2=A0

    I have created some quick Python code which I believ= e calculates the default hopping sequence, see https://gist.github.com/twatteyne/2e22ee3c1a802b685695.

    =C2=A0

    Could someone (Pat? Jonathan?) double-= check that it computes the right sequence. I'm copy-= pasting the output below.

    =C2=A0

    Thomas

    =C2=A0

    ---

    =C2=A0

    = This script calculates the default channel hopping sequence for the<= u>

    = IEEE802.15.4e-2012 TSCH mode.

    =C2=A0

    = \author Thomas Watteyne

    = \date November 2014

    =C2=A0

    =C2=A0

    = =3D=3D=3D Step a.

    =C2=A0

    = SHUFFLE is a macHoppingSequenceLength-sized array. The contents of this arr= ay ar

    = e equivalent to the first macHoppingSequenceLength outputs of a 9-bit linea= r fee

    = dback shift register (LFSR) with polynomial x9 + x5 + 1 and a starting seed= of 2

    = 55. Each LFSR output is modulo macHoppingSequenceLength, so that each entry= of S

    = HUFFLE is between 0 and (macHoppingSequenceLength - 1), inclusive.

    =C2=A0

    = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A05 =C2=A0 =C2=A0 =C2=A0 9=

    = =C2=A0 =C2=A01 1 1 1 1 1 1 1 0 ( 255=3D=3D0x0ff=3D=3Db011111111)<= /u>

    = =C2=A0 =C2=A01 1 1 1 1 1 1 1 1 ( 511=3D=3D0x1ff=3D=3Db111111111) --> 15<= /span>

    = =C2=A0 =C2=A00 1 1 1 1 1 1 1 1 ( 510=3D=3D0x1fe=3D=3Db111111110) --> 14<= /span>

    = =C2=A0 =C2=A00 0 1 1 1 1 1 1 1 ( 508=3D=3D0x1fc=3D=3Db111111100) --> 12<= /span>

    = =C2=A0 =C2=A00 0 0 1 1 1 1 1 1 ( 504=3D=3D0x1f8=3D=3Db111111000) --> 8

    = =C2=A0 =C2=A00 0 0 0 1 1 1 1 1 ( 496=3D=3D0x1f0=3D=3Db111110000) --> 0

    = =C2=A0 =C2=A00 0 0 0 0 1 1 1 1 ( 480=3D=3D0x1e0=3D=3Db111100000) --> 0

    = =C2=A0 =C2=A01 0 0 0 0 0 1 1 1 ( 449=3D=3D0x1c1=3D=3Db111000001) --> 1

    = =C2=A0 =C2=A01 1 0 0 0 0 0 1 1 ( 387=3D=3D0x183=3D=3Db110000011) --> 3

    = =C2=A0 =C2=A01 1 1 0 0 0 0 0 1 ( 263=3D=3D0x107=3D=3Db100000111) --> 7

    = =C2=A0 =C2=A01 1 1 1 0 0 0 0 0 ( =C2=A015=3D=3D0x00f=3D=3Db000001111) -->= ; 15

    = =C2=A0 =C2=A00 1 1 1 1 0 0 0 0 ( =C2=A030=3D=3D0x01e=3D=3Db000011110) -->= ; 14

    = =C2=A0 =C2=A01 0 1 1 1 1 0 0 0 ( =C2=A061=3D=3D0x03d=3D=3Db000111101) -->= ; 13

    = =C2=A0 =C2=A01 1 0 1 1 1 1 0 0 ( 123=3D=3D0x07b=3D=3Db001111011) --> 11<= /span>

    = =C2=A0 =C2=A01 1 1 0 1 1 1 1 0 ( 247=3D=3D0x0f7=3D=3Db011110111) --> 7

    = =C2=A0 =C2=A01 1 1 1 0 1 1 1 1 ( 495=3D=3D0x1ef=3D=3Db111101111) --> 15<= /span>

    = =C2=A0 =C2=A01 1 1 1 1 0 1 1 1 ( 479=3D=3D0x1df=3D=3Db111011111) --> 15<= /span>

    =C2=A0

    = SHUFFLE: =C2=A0[15, 14, 12, 8, 0, 0, 1, 3, 7, 15, 14, 13, 11, 7, 15, 15]

    =C2=A0

    = =3D=3D=3D Step b.

    =C2=A0

    = CHANNELS is a macHoppingSequenceLength-sized array that is initially popula= ted w

    = ith the monotonically increasing list of channels available to the PHY.

    =C2=A0

    = CHANNELS: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15]<= /u>

    =C2=A0

    = =3D=3D=3D Step c.

    =C2=A0

    = CHANNELS is shuffled as per Figure 7a. Elements may wind up being swapped m= ultip

    = le times in this process.

    =C2=A0

    = macHoppingSequenceList: [5, 6, 12, 7, 15, 4, 14, 11= , 8, 0, 1, 2, 13, 3, 9, 10]

    =C2=A0

    =C2=A0

    = Script ended normally, press Enter to close.


    On Friday, November 7, 2014, Xavier Vilajosana <xvilajosana@eecs.berkeley.edu> wrote:

    Dear Kees,

    thanks for your comments.=C2=A0

    =C2=A0

    answering 1)

    IMHO the fact that if default ch. hopping sequence i= s being used may not be advertised in the EB it is not clear in the standard. And= therefore I opted to make the EB explicit (even only an ID and this being = the default)

    Page 11 of the 15.4e amendment indicates that:

    =C2=A0

    All hopping sequences are referred to by an ID, m= acHoppingSequenceID, with ID =3D 0 denoting the default

    sequence for a particular PHY (or PHY configurati= on if the PHY supports more than one channel list).

    =C2=A0

    then page 92

    The full Hopping Sequence may be omitted to ensur= e that the frame does not exceed aMaxPHYPacketSize.

    In this case only the Hopping Sequence ID is carr= ied, and the length of the IE is 1 octet. When the length is<= /u>

    not equal to one, the additional fields are prese= nt. The element varies in length depending upon the

    numberOfChannels in use by the PHY. The channelPa= ge and numberOfChannels attributes can be used to

    determine the size of the extendedBitmap, and the= macHoppingSequenceLength can be used to determine

    the size of the macHoppingSequenceList.

    The Channel Hopping IE may be used by any = channel hopping PAN to synchronize devices.

    =C2=A0

    My last point here is that this may=C2=A0migh= t indicate optionality but the case for the default id is not mentioned so = I am not sure it can be elided if default id (0)

    =C2=A0

    answering 2) it seems a good point. Let us think abo= ut it.

    =C2=A0

    regards,

    Xavi

    =C2=A0

    2014-11-07 9:57 GMT+01:00 Kees Trommel <ctrommel@aimvalley.nl>:

    Hi,

    This draft specifies that the enhanced beacon should include a Channel Hopp= ing IE with a Hopping Sequence ID equal to 0. Hopping Sequence ID 0 is the = default hopping sequence ID. So the actual hopping sequence will not be inc= luded in the enhanced beacon.

    Section 5.1.1a of the IEE802.25.4e standard defines an algorithm to calcula= te a default hopping sequence ID.

    I have the following questions regarding the default hopping sequence:

    1. Is it the intention that a minimal configuration uses the default hoppin= g sequence as defined in the IEE802.25.4e standard?
    2. If the answer on 1. is yes:=C2=A0 The definition of the IEE802.25.4e hop= ping sequence (in my opinion) is not unambiguous, so can you add the actual= default hopping sequence to this draft?

    Regards,

    Kees.

    On Oct 27, 2014, at 12:20 AM, Xavier Vilajosana <xvilajosana at
    eecs.berkeley.edu> w= rote:


    All, I just published the new version of minimal. It= includes a security section as discussed last call and some changes to the= default timing to be according to 15.4 tsch default values.

    =C2=A0

    regards,
    Xavi

    =C2=A0

    ---------- Forwarded message ----------
    From: <internet-drafts at = ietf.org>
    Date: 2014-10-27 5:17 GMT+01:00
    Subject: [6tisch] I-D Action: draft-ietf-6tisch-minimal-03.txt
    To: i-d-announce at ietf.org<= /a>
    Cc: 6tisch at
    ietf.org


    A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
    =C2=A0This draft is a work item of the IPv6 over the TSCH mode of IEEE 802.= 15.4e Working Group of the IETF.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Minimal 6TiSCH Configuration
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Xavi= er Vilajosana
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Kris Pister
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-6tisch-minimal-03.txt
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 22
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2014-10-26

    Abstract:
    =C2=A0 =C2=A0This document describes the minimal set of rules to operate a<= br> =C2=A0 =C2=A0[IEEE802154e] Timeslotted Channel Hopping (TSCH) network.=C2= =A0 This
    =C2=A0 =C2=A0minimal mode of operation can be used during network bootstrap= , as a
    =C2=A0 =C2=A0fall-back mode of operation when no dynamic scheduling solutio= n is
    =C2=A0 =C2=A0available or functioning, or during early interoperability tes= ting
    =C2=A0 =C2=A0and development.


    The IETF datatracker status page for this draft is:
    https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal/<= /a>

    There's also a htmlized version available at:
    http://tools.ietf.org/html/draft-ietf-6tisch-minimal-03

    A diff from the previous version is available at:
    http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6tisch-min= imal-03


    Please note that it may take a couple of minutes from the time of submissio= n
    until the htmlized version and diff are available at tools.ietf.org.

    Internet-Drafts are also available by anonymous FTP at:
    ftp://ftp= .ietf.org/internet-drafts/

    _______________________________________________
    6tisch mailing list
    6tisch at ietf.org
    = https://www.ietf.org/mailman/listinfo/6tisch

    =C2=A0

    _______________________________________________
    6tisch mailing list
    6tisch at ietf.org
    = https://www.ietf.org/mailman/listinfo/6tisch

    =C2=A0


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

    =C2=A0

    =C2=A0

    =C2=A0

    =C2=A0

    =C2=A0


    --047d7b15a453b60c2205078ab6c0-- From nobody Mon Nov 10 19:07:22 2014 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC7FC1A8843 for <6tisch@ietfa.amsl.com>; Mon, 10 Nov 2014 19:07:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.276 X-Spam-Level: X-Spam-Status: No, score=-1.276 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGMJWio05rwx for <6tisch@ietfa.amsl.com>; Mon, 10 Nov 2014 19:07:18 -0800 (PST) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F2A31A888C for <6tisch@ietf.org>; Mon, 10 Nov 2014 19:07:18 -0800 (PST) Received: by mail-pa0-f53.google.com with SMTP id kx10so9511285pab.26 for <6tisch@ietf.org>; Mon, 10 Nov 2014 19:07:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:content-type; bh=S/WYemhmY3z1eu2aUjRJN1TpuqnI7XZHmgWGEyfUUdo=; b=hrIRM53K0eot8ww6wH9l7HcZQrqd2taACjMT06K7pl1Y0rKXXsZxY9Jw0kfVHkmes5 NSmWxqKNWpmk/7VY0wd9D1iNGtKCgfh49IRWtiPvllkS2MEgSqr7QnGSR39E7qV5eSav RLblyA2mn3x+1hCJRFf6fAKB6zrvUKS9LqgHT0IERGv+Ok5Giu4C0JS8JzZkViPvw9fb IDZ23lUPwIq2k/jB2lxnoZBtEhVatRs0lvg0mAy/CtLMuY0LtgHhAcFlz0sEzmzWfhOe jKehQcUkFpS07VGwj3OC3UpBhPTP3ubOJYTnxjlvplm4hLib7RwucL2nJAR/Zsj+mx1o 95Tg== X-Received: by 10.68.220.169 with SMTP id px9mr8522055pbc.146.1415675237602; Mon, 10 Nov 2014 19:07:17 -0800 (PST) MIME-Version: 1.0 Sender: twatteyne@gmail.com Received: by 10.66.88.42 with HTTP; Mon, 10 Nov 2014 19:06:57 -0800 (PST) From: Thomas Watteyne Date: Mon, 10 Nov 2014 17:06:57 -1000 X-Google-Sender-Auth: ZWurQJ0h0d-Dtw8kRA6wPRt44sA Message-ID: To: "6tisch@ietf.org" <6tisch@ietf.org> Content-Type: multipart/alternative; boundary=047d7b10cc4fa79d1605078c934c Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch/p_Hwo3BdI32isUT1kS_-PcG0axo Subject: [6tisch] volunteers minute taker and jabber scribe for 6TiSCH WG meeting? X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 03:07:19 -0000 --047d7b10cc4fa79d1605078c934c Content-Type: text/plain; charset=UTF-8 All, For the 6TiSCH WG on Thursday ( https://datatracker.ietf.org/meeting/91/agenda/6tisch/), we would need volunteers for: - Jabber Scribe (room: 6tisch@jabber.ietf.org) - at least 2 minute takers (Etherpad: http://etherpad.tools.ietf.org:9000/p/notes-ietf-91-6tisch) Please answer directly to this thread, or unicast me. Thanks! Thomas --047d7b10cc4fa79d1605078c934c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    All,

    For the 6TiSCH WG on Thursday (https://dat= atracker.ietf.org/meeting/91/agenda/6tisch/), we would need volunteers = for:
    - Jabber Scribe (room: 6tisch@jabber.ietf.org)=C2=A0
    - at least 2 minute takers= (Etherpad: http://etherpad.tools.ietf.org:9000/p/notes-ietf-91-6tisch)

    Please answer directly to this thread, or unicast me.=

    Thanks!
    Thomas
    --047d7b10cc4fa79d1605078c934c-- From nobody Mon Nov 10 20:19:06 2014 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68D5B1AD003 for <6tisch@ietfa.amsl.com>; Mon, 10 Nov 2014 20:19:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yW_S0uQIYreo for <6tisch@ietfa.amsl.com>; Mon, 10 Nov 2014 20:19:00 -0800 (PST) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 510001ACFF2 for <6tisch@ietf.org>; Mon, 10 Nov 2014 20:18:59 -0800 (PST) Received: by mail-wi0-f170.google.com with SMTP id r20so619047wiv.1 for <6tisch@ietf.org>; Mon, 10 Nov 2014 20:18:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=SvqYfBORAK8tEdkZecAe9ROhyeueKybgQMfBZslMn78=; b=TjTDQxEgs1/YNbUlN4dDv3Gi1ABXl3R59PX2YBr/xAqd20+hzWSwHKPiaiyp4UdTV3 G4kzcpaUE6uCO4eb4fFf0sGFgK/v8TLnTkdw+to+BdJlDv7BsSoz2uSZtssI1595TB8H kdYpyOy1TZ5onH/lqbCczsQ/4Eyvej/fd6bnmKuhvAn2v5pijb5atGU9ukhNAPoa+pyE X8eVdYi1AmUKdGmr+DNB4u1Lewes+yuI7eIKYbE14pJnxClV5KtDeQC62MhO9D2mPzl7 PwfjouqAcjBH2jyB56t9E3OtuqzwDkWn10hOgDt/4Nuprqu54tSR/qJYF79rAq8G7fnc snRA== MIME-Version: 1.0 X-Received: by 10.180.109.194 with SMTP id hu2mr36485794wib.24.1415679538072; Mon, 10 Nov 2014 20:18:58 -0800 (PST) Sender: xvilajosana@gmail.com Received: by 10.27.130.193 with HTTP; Mon, 10 Nov 2014 20:18:57 -0800 (PST) In-Reply-To: References: <545C898A.8060300@aimvalley.nl> <54608F2A.7090708@aimvalley.nl> Date: Tue, 11 Nov 2014 05:18:57 +0100 X-Google-Sender-Auth: K0G4Xhw7SfxmWyjI-kGDQjrU4bo Message-ID: From: Xavier Vilajosana To: Thomas Watteyne Content-Type: multipart/alternative; boundary=e89a8f3ba8effb940a05078d9318 Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch/Kt_38MdMz5wGecxeoLEBwKOzs70 Cc: Kees Trommel , "Pascal Thubert \(pthubert\)" , "6tisch@ietf.org" <6tisch@ietf.org> Subject: Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-03.txt X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 04:19:04 -0000 --e89a8f3ba8effb940a05078d9318 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Thomas convinced me. As it is something 15.4 TSCH specific it seems reasonable to have it at the tsch draft and indicate the use of the default channel hopping sequence in minimal. Minimal won't be self-contained but it is not alreday. regards, Xavi 2014-11-11 1:53 GMT+01:00 Thomas Watteyne : > Pascal, > > draft-ietf-6tisch-minimal should contain that it requires the default > channel hopping pattern. I think we agree on that. > > The description of what the default channel hopping pattern is (this is > just a discussion about IEEE802.15.4e-2012, nothing 6TiSCH specific), mig= ht > end up in 6tisch/draft-ietf-6tisch-tsch. > > What do others think? > > Thomas > > > > On Mon, Nov 10, 2014 at 10:57 AM, Pascal Thubert (pthubert) < > pthubert@cisco.com> wrote: > >> Hi Thomas: >> >> >> >> I think: >> >> - that the TSCH draft could discuss what is sub-defined in TSCH, indicat= e >> that we use the range 0-15, to address Kees=E2=80=99 points >> >> - but then, the setting to be used in minimal, and pseudo code along the >> lines you produced should go in minimal to ensure interop. The pseudo co= de >> would be an appendix. >> >> >> >> Makes sense? >> >> >> >> Pascal >> >> >> >> *From:* 6tisch [mailto:6tisch-bounces@ietf.org] *On Behalf Of *Thomas >> Watteyne >> *Sent:* lundi 10 novembre 2014 12:17 >> *To:* Xavier Vilajosana >> *Cc:* Kees Trommel; 6tisch@ietf.org >> *Subject:* Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-03.txt >> >> >> >> Quick thought: does this discussion fit in draft-ietf-6tisch-minimal or >> draft-ietf-6tisch-tsch? Both make sense to me. >> >> >> >> On Mon, Nov 10, 2014 at 10:15 AM, Xavier Vilajosana < >> xvilajosana@eecs.berkeley.edu> wrote: >> >> Hi, >> >> >> >> my 5 cents. After thinking about it I am in favour of adding the example >> as the draft will be more self-contained and will facilitate the >> understanding of how ch. hopping sequence is caluclated. (analogously to >> the OF0 example). >> >> >> >> regards, >> >> Xavi >> >> >> >> 2014-11-10 19:41 GMT+01:00 Thomas Watteyne : >> >> Kees, >> >> >> >> In this script you made the assumption that the hopping sequence length >> is equal to the number of channels. I think this is reasonable assumptio= n >> but it is not defined in the IEEE802.15.4e standard, so it would be good >> idea to put this assumption in the draft too. >> >> >> >> Yes, that was my assumption in this code. >> >> >> >> You are using channel numbers 0 - 15 and I assume that these are the 16 >> 2.5GHz channels. The IEEE802.15.4e standard define these as channel numb= ers >> 11 - 26 of page 0. It is fine for me to keep the 0 - 15 channel numberin= g >> scheme but it would good to mention this too. What about (future) suppor= t >> of other channels and pages defined in the IEEE802.15.4e standard? >> >> >> >> Correct, you should add 11 to the channel numbers in the code to use >> channel numbers 11-26 in IEEE notation (2.405GHz-2.480GHz). AFAICT, ther= e >> is nothing in the hopping sequence of IEEE802.15.4e-TSCH which prevents = the >> use of (future) sets of channels. >> >> >> >> *@all*, what do others think? Are details about the hopping sequence >> something we need to add to draft-ietf-6tisch-minimal? >> >> >> >> Thomas >> >> >> >> On Mon, Nov 10, 2014 at 12:10 AM, Kees Trommel >> wrote: >> >> Thomas, Xavi, >> >> Thanks, I cannot find anything in this script that would violate the >> IEEE802.15.4e standard. >> >> In this script you made the assumption that the hopping sequence length >> is equal to the number of channels. I think this is reasonable assumptio= n >> but it is not defined in the IEEE802.15.4e standard, so it would be good >> idea to put this assumption in the draft too. >> >> You are using channel numbers 0 - 15 and I assume that these are the 16 >> 2.5GHz channels. The IEEE802.15.4e standard define these as channel numb= ers >> 11 - 26 of page 0. It is fine for me to keep the 0 - 15 channel numberin= g >> scheme but it would good to mention this too. What about (future) suppor= t >> of other channels and pages defined in the IEEE802.15.4e standard? >> >> Kees. >> >> >> >> On 11/10/14 00:29, Thomas Watteyne wrote: >> >> Kees, Xavi, >> >> >> >> If the default hopping sequence isn't clear in IEEE802.15.4e-2012, this >> is important information to the fed back to the IEEE802.15.4 TG. >> *@PatKinney*, maybe you can chime in on whether the related text will be >> changed in IEEE802.15.4-2015? >> >> >> >> In any case, let's disambiguate the hopping sequence on this thread. We >> could add an example in draft-ietf-6tisch-minimal, and maybe ask >> IEEE802.15.4 to do the same. >> >> >> >> I have created some quick Python code which I believe calculates the >> default hopping sequence, see >> https://gist.github.com/twatteyne/2e22ee3c1a802b685695. >> >> >> >> Could someone (*Pat*? *Jonathan*?) double-check that it computes the >> right sequence. I'm copy-pasting the output below. >> >> >> >> Thomas >> >> >> >> --- >> >> >> >> This script calculates the default channel hopping sequence for the >> >> IEEE802.15.4e-2012 TSCH mode. >> >> >> >> \author Thomas Watteyne >> >> \date November 2014 >> >> \license http://opensource.org/licenses/BSD-3-Clause >> >> >> >> >> >> =3D=3D=3D Step a. >> >> >> >> SHUFFLE is a macHoppingSequenceLength-sized array. The contents of this >> array ar >> >> e equivalent to the first macHoppingSequenceLength outputs of a 9-bit >> linear fee >> >> dback shift register (LFSR) with polynomial x9 + x5 + 1 and a starting >> seed of 2 >> >> 55. Each LFSR output is modulo macHoppingSequenceLength, so that each >> entry of S >> >> HUFFLE is between 0 and (macHoppingSequenceLength - 1), inclusive. >> >> >> >> 5 9 >> >> 1 1 1 1 1 1 1 1 0 ( 255=3D=3D0x0ff=3D=3Db011111111) >> >> 1 1 1 1 1 1 1 1 1 ( 511=3D=3D0x1ff=3D=3Db111111111) --> 15 >> >> 0 1 1 1 1 1 1 1 1 ( 510=3D=3D0x1fe=3D=3Db111111110) --> 14 >> >> 0 0 1 1 1 1 1 1 1 ( 508=3D=3D0x1fc=3D=3Db111111100) --> 12 >> >> 0 0 0 1 1 1 1 1 1 ( 504=3D=3D0x1f8=3D=3Db111111000) --> 8 >> >> 0 0 0 0 1 1 1 1 1 ( 496=3D=3D0x1f0=3D=3Db111110000) --> 0 >> >> 0 0 0 0 0 1 1 1 1 ( 480=3D=3D0x1e0=3D=3Db111100000) --> 0 >> >> 1 0 0 0 0 0 1 1 1 ( 449=3D=3D0x1c1=3D=3Db111000001) --> 1 >> >> 1 1 0 0 0 0 0 1 1 ( 387=3D=3D0x183=3D=3Db110000011) --> 3 >> >> 1 1 1 0 0 0 0 0 1 ( 263=3D=3D0x107=3D=3Db100000111) --> 7 >> >> 1 1 1 1 0 0 0 0 0 ( 15=3D=3D0x00f=3D=3Db000001111) --> 15 >> >> 0 1 1 1 1 0 0 0 0 ( 30=3D=3D0x01e=3D=3Db000011110) --> 14 >> >> 1 0 1 1 1 1 0 0 0 ( 61=3D=3D0x03d=3D=3Db000111101) --> 13 >> >> 1 1 0 1 1 1 1 0 0 ( 123=3D=3D0x07b=3D=3Db001111011) --> 11 >> >> 1 1 1 0 1 1 1 1 0 ( 247=3D=3D0x0f7=3D=3Db011110111) --> 7 >> >> 1 1 1 1 0 1 1 1 1 ( 495=3D=3D0x1ef=3D=3Db111101111) --> 15 >> >> 1 1 1 1 1 0 1 1 1 ( 479=3D=3D0x1df=3D=3Db111011111) --> 15 >> >> >> >> SHUFFLE: [15, 14, 12, 8, 0, 0, 1, 3, 7, 15, 14, 13, 11, 7, 15, 15] >> >> >> >> =3D=3D=3D Step b. >> >> >> >> CHANNELS is a macHoppingSequenceLength-sized array that is initially >> populated w >> >> ith the monotonically increasing list of channels available to the PHY. >> >> >> >> CHANNELS: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15] >> >> >> >> =3D=3D=3D Step c. >> >> >> >> CHANNELS is shuffled as per Figure 7a. Elements may wind up being swappe= d >> multip >> >> le times in this process. >> >> >> >> macHoppingSequenceList: *[5, 6, 12, 7, 15, 4, 14, 11, 8, 0, 1, 2, 13, 3, >> 9, 10]* >> >> >> >> >> >> Script ended normally, press Enter to close. >> >> >> On Friday, November 7, 2014, Xavier Vilajosana < >> xvilajosana@eecs.berkeley.edu> wrote: >> >> Dear Kees, >> >> thanks for your comments. >> >> >> >> answering 1) >> >> IMHO the fact that if default ch. hopping sequence is being used *may >> not be* advertised in the EB it is not clear in the standard. And >> therefore I opted to make the EB explicit (even only an ID and this bein= g >> the default) >> >> Page 11 of the 15.4e amendment indicates that: >> >> >> >> *All hopping sequences are referred to by an ID, macHoppingSequenceID, >> with ID =3D 0 denoting the default* >> >> *sequence for a particular PHY (or PHY configuration if the PHY supports >> more than one channel list).* >> >> >> >> then page 92 >> >> *The full Hopping Sequence may be omitted to ensure that the frame does >> not exceed aMaxPHYPacketSize.* >> >> *In this case only the Hopping Sequence ID is carried, and the length of >> the IE is 1 octet. When the length is* >> >> *not equal to one, the additional fields are present. The element varies >> in length depending upon the* >> >> *numberOfChannels in use by the PHY. The channelPage and numberOfChannel= s >> attributes can be used to* >> >> *determine the size of the extendedBitmap, and the >> macHoppingSequenceLength can be used to determine* >> >> *the size of the macHoppingSequenceList.* >> >> *The Channel Hopping IE may be used by any channel hopping PAN to >> synchronize devices.* >> >> >> >> My last point here is that this *may* might indicate optionality but the >> case for the default id is not mentioned so I am not sure it can be elid= ed >> if default id (0) >> >> >> >> answering 2) it seems a good point. Let us think about it. >> >> >> >> regards, >> >> Xavi >> >> >> >> 2014-11-07 9:57 GMT+01:00 Kees Trommel : >> >> Hi, >> >> This draft specifies that the enhanced beacon should include a Channel >> Hopping IE with a Hopping Sequence ID equal to 0. Hopping Sequence ID 0 = is >> the default hopping sequence ID. So the actual hopping sequence will not= be >> included in the enhanced beacon. >> >> Section 5.1.1a of the IEE802.25.4e standard defines an algorithm to >> calculate a default hopping sequence ID. >> >> I have the following questions regarding the default hopping sequence: >> >> 1. Is it the intention that a minimal configuration uses the default >> hopping sequence as defined in the IEE802.25.4e standard? >> 2. If the answer on 1. is yes: The definition of the IEE802.25.4e >> hopping sequence (in my opinion) is not unambiguous, so can you add the >> actual default hopping sequence to this draft? >> >> Regards, >> >> Kees. >> >> On Oct 27, 2014, at 12:20 AM, Xavier Vilajosana > eecs.berkeley.edu> wrote: >> >> >> All, I just published the new version of minimal. It includes a >> security section as discussed last call and some changes to the default >> timing to be according to 15.4 tsch default values. >> >> >> >> regards, >> Xavi >> >> >> >> ---------- Forwarded message ---------- >> From: >> Date: 2014-10-27 5:17 GMT+01:00 >> Subject: [6tisch] I-D Action: draft-ietf-6tisch-minimal-03.txt >> To: i-d-announce at ietf.org >> Cc: 6tisch at ietf.org >> >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the IPv6 over the TSCH mode of IEEE >> 802.15.4e Working Group of the IETF. >> >> Title : Minimal 6TiSCH Configuration >> Authors : Xavier Vilajosana >> Kris Pister >> Filename : draft-ietf-6tisch-minimal-03.txt >> Pages : 22 >> Date : 2014-10-26 >> >> Abstract: >> This document describes the minimal set of rules to operate a >> [IEEE802154e] Timeslotted Channel Hopping (TSCH) network. This >> minimal mode of operation can be used during network bootstrap, as a >> fall-back mode of operation when no dynamic scheduling solution is >> available or functioning, or during early interoperability testing >> and development. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-6tisch-minimal-03 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6tisch-minimal-03 >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> 6tisch mailing list >> 6tisch at ietf.org >> https://www.ietf.org/mailman/listinfo/6tisch >> >> >> >> _______________________________________________ >> 6tisch mailing list >> 6tisch at ietf.org >> https://www.ietf.org/mailman/listinfo/6tisch >> >> >> >> >> _______________________________________________ >> 6tisch mailing list >> 6tisch@ietf.org >> https://www.ietf.org/mailman/listinfo/6tisch >> >> >> >> >> >> >> >> >> >> >> > > --e89a8f3ba8effb940a05078d9318 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Hi,=C2=A0

    Thomas convinced m= e. As it is something 15.4 TSCH specific it seems reasonable to have it at = the tsch draft and indicate the use of the default channel hopping sequence= in minimal. Minimal won't be self-contained but it is not alreday.

    regards,
    Xavi

    2014-11-11 1:53 GMT+01:00 Thomas Watteyne = <watteyne@eecs.berkeley.edu>:
    Pascal,

    draft-ietf-6tisch= -minimal should contain that it requires the default channel hopping patter= n. I think we agree on that.

    The description of wh= at the default channel hopping pattern is (this is just a discussion about = IEEE802.15.4e-2012, nothing 6TiSCH specific), might end up in=C2=A06tisch/d= raft-ietf-6tisch-tsch.

    What do others think?
    =

    Thomas



    On Mon, Nov 10, 2014 at 10:57 AM, Pascal Thubert (pthubert) <pthubert@c= isco.com> wrote:

    Hi Thomas:<= /span>

    =C2=A0

    I think:

    - that the TSCH draft cou= ld discuss what is sub-defined in TSCH, indicate that we use the range 0-15= , to address Kees=E2=80=99 points

    - but then, the setting t= o be used in minimal, and pseudo code along the lines you produced should g= o in minimal to ensure interop. The pseudo code would be an appendix.

    =C2=A0

    Makes sense?

    =C2=A0

    Pascal

    =C2=A0

    From: 6tisch [= mailto:6tisch-= bounces@ietf.org] On Behalf Of Thomas Watteyne
    Sent: lundi 10 novembre 2014 12:17
    To: Xavier Vilajosana
    Cc: Kees Trommel; 6tisch@ietf.org
    Subject: Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-03.txt

    =C2=A0

    Quick thought: does this discussion fit in=C2=A0draf= t-ietf-6tisch-minimal or draft-ietf-6tisch-tsch? Both make sense to me.<= /u>

    =C2=A0

    On Mon, Nov 10, 2014 at 10:15 AM, Xavier Vilajosana = <xvil= ajosana@eecs.berkeley.edu> wrote:

    Hi,=C2=A0

    =C2=A0

    my 5 cents. After thinking about it I am in favour o= f adding the example as the draft will be more self-contained and will faci= litate the understanding of how ch. hopping sequence is caluclated. (analog= ously to the OF0 example).=C2=A0

    =C2=A0

    regards,

    Xavi

    =C2=A0

    2014-11-10 19:41 GMT+01:00 Thomas Watteyne <watteyne@eecs.be= rkeley.edu>:

    Kees,

    =C2=A0

    In this script you made the assumption that the hopp= ing sequence length is equal to the number of channels. I think this is rea= sonable assumption but it is not defined in the IEEE802.15.4e standard, so = it would be good idea to put this assumption in the draft too.

    =C2=A0

    Yes, that was my assumption in this code.<= /u>

    =C2=A0

    You are using channel numbers 0 - 15 and I assume th= at these are the 16 2.5GHz channels. The IEEE802.15.4e standard define thes= e as channel numbers 11 - 26 of page 0. It is fine for me to keep the 0 - 1= 5 channel numbering scheme but it would good to mention this too. What about (future) support of other chann= els and pages defined in the IEEE802.15.4e standard?

    =C2=A0

    Correct, you should add 11 to the channel numbers in= the code to use channel numbers 11-26 in IEEE notation (2.405GHz-2.480GHz)= . AFAICT, there is nothing in the hopping sequence of IEEE802.15.4e-TSCH wh= ich prevents the use of (future) sets of channels.

    =C2=A0

    @all, what do others think? Are details about= the hopping sequence something we need to add to draft-ietf-6tisch-minimal= ?

    =C2=A0

    Thomas

    =C2=A0

    On Mon, Nov 10, 2014 at 12:10 AM, Kees Trommel <<= a href=3D"mailto:ctrommel@aimvalley.nl" target=3D"_blank">ctrommel@aimvalle= y.nl> wrote:

    Thomas, Xavi,

    Thanks, I cannot find anything in this script that would violate the IEEE80= 2.15.4e standard.

    In this script you made the assumption that the hopping sequence length is = equal to the number of channels. I think this is reasonable assumption but = it is not defined in the IEEE802.15.4e standard, so it would be good idea t= o put this assumption in the draft too.

    You are using channel numbers 0 - 15 and I assume that these are the 16 2.5= GHz channels. The IEEE802.15.4e standard define these as channel numbers 11= - 26 of page 0. It is fine for me to keep the 0 - 15 channel numbering sch= eme but it would good to mention this too. What about (future) support of other channels and pages defined = in the IEEE802.15.4e standard?

    Kees.



    On 11/10/14 00:29, Thomas Watteyne wrote:

    Kees, Xavi,

    =C2=A0

    If the default hopping sequence isn't clear in I= EEE802.15.4e-2012, this is important information to the fed back to the IEE= E802.15.4 TG. @PatKinney, maybe you can chime in on whether the related text will = be changed in IEEE802.15.4-2015?

    =C2=A0

    In any case, let's disambiguate the hopping sequ= ence on this thread. We could add an example in draft-ietf-6tisch-minimal, = and maybe ask IEEE802.15.4 to do the same.

    =C2=A0

    I have created some quick Python code which I believ= e calculates the default hopping sequence, see https://gist.github.com/twatteyne/2e22ee3c1a802b685695.

    =C2=A0

    Could someone (Pat? Jonathan?) double-= check that it computes the right sequence. I'm copy-= pasting the output below.

    =C2=A0

    Thomas

    =C2=A0

    ---

    =C2=A0

    = This script calculates the default channel hopping sequence for the<= u>

    = IEEE802.15.4e-2012 TSCH mode.

    =C2=A0

    = \author Thomas Watteyne

    = \date November 2014

    =C2=A0

    =C2=A0

    = =3D=3D=3D Step a.

    =C2=A0

    = SHUFFLE is a macHoppingSequenceLength-sized array. The contents of this arr= ay ar

    = e equivalent to the first macHoppingSequenceLength outputs of a 9-bit linea= r fee

    = dback shift register (LFSR) with polynomial x9 + x5 + 1 and a starting seed= of 2

    = 55. Each LFSR output is modulo macHoppingSequenceLength, so that each entry= of S

    = HUFFLE is between 0 and (macHoppingSequenceLength - 1), inclusive.

    =C2=A0

    = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A05 =C2=A0 =C2=A0 =C2=A0 9=

    = =C2=A0 =C2=A01 1 1 1 1 1 1 1 0 ( 255=3D=3D0x0ff=3D=3Db011111111)<= /u>

    = =C2=A0 =C2=A01 1 1 1 1 1 1 1 1 ( 511=3D=3D0x1ff=3D=3Db111111111) --> 15<= /span>

    = =C2=A0 =C2=A00 1 1 1 1 1 1 1 1 ( 510=3D=3D0x1fe=3D=3Db111111110) --> 14<= /span>

    = =C2=A0 =C2=A00 0 1 1 1 1 1 1 1 ( 508=3D=3D0x1fc=3D=3Db111111100) --> 12<= /span>

    = =C2=A0 =C2=A00 0 0 1 1 1 1 1 1 ( 504=3D=3D0x1f8=3D=3Db111111000) --> 8

    = =C2=A0 =C2=A00 0 0 0 1 1 1 1 1 ( 496=3D=3D0x1f0=3D=3Db111110000) --> 0

    = =C2=A0 =C2=A00 0 0 0 0 1 1 1 1 ( 480=3D=3D0x1e0=3D=3Db111100000) --> 0

    = =C2=A0 =C2=A01 0 0 0 0 0 1 1 1 ( 449=3D=3D0x1c1=3D=3Db111000001) --> 1

    = =C2=A0 =C2=A01 1 0 0 0 0 0 1 1 ( 387=3D=3D0x183=3D=3Db110000011) --> 3

    = =C2=A0 =C2=A01 1 1 0 0 0 0 0 1 ( 263=3D=3D0x107=3D=3Db100000111) --> 7

    = =C2=A0 =C2=A01 1 1 1 0 0 0 0 0 ( =C2=A015=3D=3D0x00f=3D=3Db000001111) -->= ; 15

    = =C2=A0 =C2=A00 1 1 1 1 0 0 0 0 ( =C2=A030=3D=3D0x01e=3D=3Db000011110) -->= ; 14

    = =C2=A0 =C2=A01 0 1 1 1 1 0 0 0 ( =C2=A061=3D=3D0x03d=3D=3Db000111101) -->= ; 13

    = =C2=A0 =C2=A01 1 0 1 1 1 1 0 0 ( 123=3D=3D0x07b=3D=3Db001111011) --> 11<= /span>

    = =C2=A0 =C2=A01 1 1 0 1 1 1 1 0 ( 247=3D=3D0x0f7=3D=3Db011110111) --> 7

    = =C2=A0 =C2=A01 1 1 1 0 1 1 1 1 ( 495=3D=3D0x1ef=3D=3Db111101111) --> 15<= /span>

    = =C2=A0 =C2=A01 1 1 1 1 0 1 1 1 ( 479=3D=3D0x1df=3D=3Db111011111) --> 15<= /span>

    =C2=A0

    = SHUFFLE: =C2=A0[15, 14, 12, 8, 0, 0, 1, 3, 7, 15, 14, 13, 11, 7, 15, 15]

    =C2=A0

    = =3D=3D=3D Step b.

    =C2=A0

    = CHANNELS is a macHoppingSequenceLength-sized array that is initially popula= ted w

    = ith the monotonically increasing list of channels available to the PHY.

    =C2=A0

    = CHANNELS: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15]<= /u>

    =C2=A0

    = =3D=3D=3D Step c.

    =C2=A0

    = CHANNELS is shuffled as per Figure 7a. Elements may wind up being swapped m= ultip

    = le times in this process.

    =C2=A0

    = macHoppingSequenceList: [5, 6, 12, 7, 15, 4, 14, 11= , 8, 0, 1, 2, 13, 3, 9, 10]

    =C2=A0

    =C2=A0

    = Script ended normally, press Enter to close.


    On Friday, November 7, 2014, Xavier Vilajosana <xvilajosana@eecs.berkeley.edu> wrote:

    Dear Kees,

    thanks for your comments.=C2=A0

    =C2=A0

    answering 1)

    IMHO the fact that if default ch. hopping sequence i= s being used may not be advertised in the EB it is not clear in the standard. And= therefore I opted to make the EB explicit (even only an ID and this being = the default)

    Page 11 of the 15.4e amendment indicates that:

    =C2=A0

    All hopping sequences are referred to by an ID, m= acHoppingSequenceID, with ID =3D 0 denoting the default

    sequence for a particular PHY (or PHY configurati= on if the PHY supports more than one channel list).

    =C2=A0

    then page 92

    The full Hopping Sequence may be omitted to ensur= e that the frame does not exceed aMaxPHYPacketSize.

    In this case only the Hopping Sequence ID is carr= ied, and the length of the IE is 1 octet. When the length is<= /u>

    not equal to one, the additional fields are prese= nt. The element varies in length depending upon the

    numberOfChannels in use by the PHY. The channelPa= ge and numberOfChannels attributes can be used to

    determine the size of the extendedBitmap, and the= macHoppingSequenceLength can be used to determine

    the size of the macHoppingSequenceList.

    The Channel Hopping IE may be used by any = channel hopping PAN to synchronize devices.

    =C2=A0

    My last point here is that this may=C2=A0migh= t indicate optionality but the case for the default id is not mentioned so = I am not sure it can be elided if default id (0)

    =C2=A0

    answering 2) it seems a good point. Let us think abo= ut it.

    =C2=A0

    regards,

    Xavi

    =C2=A0

    2014-11-07 9:57 GMT+01:00 Kees Trommel <ctrommel@aimvalley.nl>:

    Hi,

    This draft specifies that the enhanced beacon should include a Channel Hopp= ing IE with a Hopping Sequence ID equal to 0. Hopping Sequence ID 0 is the = default hopping sequence ID. So the actual hopping sequence will not be inc= luded in the enhanced beacon.

    Section 5.1.1a of the IEE802.25.4e standard defines an algorithm to calcula= te a default hopping sequence ID.

    I have the following questions regarding the default hopping sequence:

    1. Is it the intention that a minimal configuration uses the default hoppin= g sequence as defined in the IEE802.25.4e standard?
    2. If the answer on 1. is yes:=C2=A0 The definition of the IEE802.25.4e hop= ping sequence (in my opinion) is not unambiguous, so can you add the actual= default hopping sequence to this draft?

    Regards,

    Kees.

    On Oct 27, 2014, at 12:20 AM, Xavier Vilajosana <xvilajosana at
    eecs.berkeley.edu> w= rote:


    All, I just published the new version of minimal. It= includes a security section as discussed last call and some changes to the= default timing to be according to 15.4 tsch default values.

    =C2=A0

    regards,
    Xavi

    =C2=A0

    ---------- Forwarded message ----------
    From: <internet-drafts at = ietf.org>
    Date: 2014-10-27 5:17 GMT+01:00
    Subject: [6tisch] I-D Action: draft-ietf-6tisch-minimal-03.txt
    To: i-d-announce at ietf.org<= /a>
    Cc: 6tisch at
    ietf.org


    A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
    =C2=A0This draft is a work item of the IPv6 over the TSCH mode of IEEE 802.= 15.4e Working Group of the IETF.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Minimal 6TiSCH Configuration
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Xavi= er Vilajosana
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Kris Pister
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-6tisch-minimal-03.txt
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 22
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2014-10-26

    Abstract:
    =C2=A0 =C2=A0This document describes the minimal set of rules to operate a<= br> =C2=A0 =C2=A0[IEEE802154e] Timeslotted Channel Hopping (TSCH) network.=C2= =A0 This
    =C2=A0 =C2=A0minimal mode of operation can be used during network bootstrap= , as a
    =C2=A0 =C2=A0fall-back mode of operation when no dynamic scheduling solutio= n is
    =C2=A0 =C2=A0available or functioning, or during early interoperability tes= ting
    =C2=A0 =C2=A0and development.


    The IETF datatracker status page for this draft is:
    https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal/<= /a>

    There's also a htmlized version available at:
    http://tools.ietf.org/html/draft-ietf-6tisch-minimal-03

    A diff from the previous version is available at:
    http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6tisch-min= imal-03


    Please note that it may take a couple of minutes from the time of submissio= n
    until the htmlized version and diff are available at tools.ietf.org.

    Internet-Drafts are also available by anonymous FTP at:
    ftp://ftp= .ietf.org/internet-drafts/

    _______________________________________________
    6tisch mailing list
    6tisch at ietf.org
    = https://www.ietf.org/mailman/listinfo/6tisch

    =C2=A0

    _______________________________________________
    6tisch mailing list
    6tisch at ietf.org
    = https://www.ietf.org/mailman/listinfo/6tisch

    =C2=A0


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

    =C2=A0

    =C2=A0

    =C2=A0

    =C2=A0

    =C2=A0



    --e89a8f3ba8effb940a05078d9318-- From nobody Mon Nov 10 20:24:36 2014 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6CD21AD41B for <6tisch@ietfa.amsl.com>; Mon, 10 Nov 2014 20:24:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RASV1xcFTU78 for <6tisch@ietfa.amsl.com>; Mon, 10 Nov 2014 20:24:28 -0800 (PST) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E70F1AD4B3 for <6tisch@ietf.org>; Mon, 10 Nov 2014 20:24:28 -0800 (PST) Received: by mail-pa0-f51.google.com with SMTP id kq14so9700160pab.24 for <6tisch@ietf.org>; Mon, 10 Nov 2014 20:24:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=ffn4ALSxeAf9mvcW1uouzMM6wiCehaGS+aaQiXDusqs=; b=kEeFp7oam7MaWIjNEGSmOvX+AF+vUB0Aeh8ZzrOFaj0JWW7aFZvmh7HhrcLGRDHhf/ xKeyOZkJbghshfgewubuUKBpP7b5CcnRdrg5PwQiRFX0ovT/0piHgKVJjYjnuDmneppR URDpfCqPO7lQr9jXLF/VUm1IhsWW+55RNFgVqDOIcrvffYPr7XVtRkEKVXwIsku6Lrgv NpBNzBUju3zVFyowzCd0K8i2kGFspmrOBY7gthruGrnibya1CdO9/4mYusFVQIiixGB9 vh3lq8/9C9Yxm1oiVKCEmt4/mzAFRRscZAIRmWXmiOVKHpx8xDzPexpXJX3jWwCBzsvu hJHg== X-Received: by 10.66.233.98 with SMTP id tv2mr34984094pac.94.1415679867124; Mon, 10 Nov 2014 20:24:27 -0800 (PST) MIME-Version: 1.0 Sender: twatteyne@gmail.com Received: by 10.66.88.42 with HTTP; Mon, 10 Nov 2014 20:24:06 -0800 (PST) In-Reply-To: References: <545C898A.8060300@aimvalley.nl> <54608F2A.7090708@aimvalley.nl> From: Thomas Watteyne Date: Mon, 10 Nov 2014 18:24:06 -1000 X-Google-Sender-Auth: kLbRRgXBV7ONhGo9xPRtNDMwBxs Message-ID: To: Xavier Vilajosana Content-Type: multipart/alternative; boundary=047d7b15a45398839505078da7b1 Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch/zhEI2QLaLCItu1ddrTGc9lZYr_U Cc: Kees Trommel , "Pascal Thubert \(pthubert\)" , "6tisch@ietf.org" <6tisch@ietf.org> Subject: Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-03.txt X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 04:24:33 -0000 --047d7b15a45398839505078da7b1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Xavi, thanks for your comments. What do others think? On Mon, Nov 10, 2014 at 6:18 PM, Xavier Vilajosana < xvilajosana@eecs.berkeley.edu> wrote: > Hi, > > Thomas convinced me. As it is something 15.4 TSCH specific it seems > reasonable to have it at the tsch draft and indicate the use of the defau= lt > channel hopping sequence in minimal. Minimal won't be self-contained but = it > is not alreday. > > regards, > Xavi > > 2014-11-11 1:53 GMT+01:00 Thomas Watteyne : > >> Pascal, >> >> draft-ietf-6tisch-minimal should contain that it requires the default >> channel hopping pattern. I think we agree on that. >> >> The description of what the default channel hopping pattern is (this is >> just a discussion about IEEE802.15.4e-2012, nothing 6TiSCH specific), mi= ght >> end up in 6tisch/draft-ietf-6tisch-tsch. >> >> What do others think? >> >> Thomas >> >> >> >> On Mon, Nov 10, 2014 at 10:57 AM, Pascal Thubert (pthubert) < >> pthubert@cisco.com> wrote: >> >>> Hi Thomas: >>> >>> >>> >>> I think: >>> >>> - that the TSCH draft could discuss what is sub-defined in TSCH, >>> indicate that we use the range 0-15, to address Kees=E2=80=99 points >>> >>> - but then, the setting to be used in minimal, and pseudo code along th= e >>> lines you produced should go in minimal to ensure interop. The pseudo c= ode >>> would be an appendix. >>> >>> >>> >>> Makes sense? >>> >>> >>> >>> Pascal >>> >>> >>> >>> *From:* 6tisch [mailto:6tisch-bounces@ietf.org] *On Behalf Of *Thomas >>> Watteyne >>> *Sent:* lundi 10 novembre 2014 12:17 >>> *To:* Xavier Vilajosana >>> *Cc:* Kees Trommel; 6tisch@ietf.org >>> *Subject:* Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-03.txt >>> >>> >>> >>> Quick thought: does this discussion fit in draft-ietf-6tisch-minimal or >>> draft-ietf-6tisch-tsch? Both make sense to me. >>> >>> >>> >>> On Mon, Nov 10, 2014 at 10:15 AM, Xavier Vilajosana < >>> xvilajosana@eecs.berkeley.edu> wrote: >>> >>> Hi, >>> >>> >>> >>> my 5 cents. After thinking about it I am in favour of adding the exampl= e >>> as the draft will be more self-contained and will facilitate the >>> understanding of how ch. hopping sequence is caluclated. (analogously t= o >>> the OF0 example). >>> >>> >>> >>> regards, >>> >>> Xavi >>> >>> >>> >>> 2014-11-10 19:41 GMT+01:00 Thomas Watteyne = : >>> >>> Kees, >>> >>> >>> >>> In this script you made the assumption that the hopping sequence length >>> is equal to the number of channels. I think this is reasonable assumpti= on >>> but it is not defined in the IEEE802.15.4e standard, so it would be goo= d >>> idea to put this assumption in the draft too. >>> >>> >>> >>> Yes, that was my assumption in this code. >>> >>> >>> >>> You are using channel numbers 0 - 15 and I assume that these are the 16 >>> 2.5GHz channels. The IEEE802.15.4e standard define these as channel num= bers >>> 11 - 26 of page 0. It is fine for me to keep the 0 - 15 channel numberi= ng >>> scheme but it would good to mention this too. What about (future) suppo= rt >>> of other channels and pages defined in the IEEE802.15.4e standard? >>> >>> >>> >>> Correct, you should add 11 to the channel numbers in the code to use >>> channel numbers 11-26 in IEEE notation (2.405GHz-2.480GHz). AFAICT, the= re >>> is nothing in the hopping sequence of IEEE802.15.4e-TSCH which prevents= the >>> use of (future) sets of channels. >>> >>> >>> >>> *@all*, what do others think? Are details about the hopping sequence >>> something we need to add to draft-ietf-6tisch-minimal? >>> >>> >>> >>> Thomas >>> >>> >>> >>> On Mon, Nov 10, 2014 at 12:10 AM, Kees Trommel >>> wrote: >>> >>> Thomas, Xavi, >>> >>> Thanks, I cannot find anything in this script that would violate the >>> IEEE802.15.4e standard. >>> >>> In this script you made the assumption that the hopping sequence length >>> is equal to the number of channels. I think this is reasonable assumpti= on >>> but it is not defined in the IEEE802.15.4e standard, so it would be goo= d >>> idea to put this assumption in the draft too. >>> >>> You are using channel numbers 0 - 15 and I assume that these are the 16 >>> 2.5GHz channels. The IEEE802.15.4e standard define these as channel num= bers >>> 11 - 26 of page 0. It is fine for me to keep the 0 - 15 channel numberi= ng >>> scheme but it would good to mention this too. What about (future) suppo= rt >>> of other channels and pages defined in the IEEE802.15.4e standard? >>> >>> Kees. >>> >>> >>> >>> On 11/10/14 00:29, Thomas Watteyne wrote: >>> >>> Kees, Xavi, >>> >>> >>> >>> If the default hopping sequence isn't clear in IEEE802.15.4e-2012, this >>> is important information to the fed back to the IEEE802.15.4 TG. >>> *@PatKinney*, maybe you can chime in on whether the related text will >>> be changed in IEEE802.15.4-2015? >>> >>> >>> >>> In any case, let's disambiguate the hopping sequence on this thread. We >>> could add an example in draft-ietf-6tisch-minimal, and maybe ask >>> IEEE802.15.4 to do the same. >>> >>> >>> >>> I have created some quick Python code which I believe calculates the >>> default hopping sequence, see >>> https://gist.github.com/twatteyne/2e22ee3c1a802b685695. >>> >>> >>> >>> Could someone (*Pat*? *Jonathan*?) double-check that it computes the >>> right sequence. I'm copy-pasting the output below. >>> >>> >>> >>> Thomas >>> >>> >>> >>> --- >>> >>> >>> >>> This script calculates the default channel hopping sequence for the >>> >>> IEEE802.15.4e-2012 TSCH mode. >>> >>> >>> >>> \author Thomas Watteyne >>> >>> \date November 2014 >>> >>> \license http://opensource.org/licenses/BSD-3-Clause >>> >>> >>> >>> >>> >>> =3D=3D=3D Step a. >>> >>> >>> >>> SHUFFLE is a macHoppingSequenceLength-sized array. The contents of this >>> array ar >>> >>> e equivalent to the first macHoppingSequenceLength outputs of a 9-bit >>> linear fee >>> >>> dback shift register (LFSR) with polynomial x9 + x5 + 1 and a starting >>> seed of 2 >>> >>> 55. Each LFSR output is modulo macHoppingSequenceLength, so that each >>> entry of S >>> >>> HUFFLE is between 0 and (macHoppingSequenceLength - 1), inclusive. >>> >>> >>> >>> 5 9 >>> >>> 1 1 1 1 1 1 1 1 0 ( 255=3D=3D0x0ff=3D=3Db011111111) >>> >>> 1 1 1 1 1 1 1 1 1 ( 511=3D=3D0x1ff=3D=3Db111111111) --> 15 >>> >>> 0 1 1 1 1 1 1 1 1 ( 510=3D=3D0x1fe=3D=3Db111111110) --> 14 >>> >>> 0 0 1 1 1 1 1 1 1 ( 508=3D=3D0x1fc=3D=3Db111111100) --> 12 >>> >>> 0 0 0 1 1 1 1 1 1 ( 504=3D=3D0x1f8=3D=3Db111111000) --> 8 >>> >>> 0 0 0 0 1 1 1 1 1 ( 496=3D=3D0x1f0=3D=3Db111110000) --> 0 >>> >>> 0 0 0 0 0 1 1 1 1 ( 480=3D=3D0x1e0=3D=3Db111100000) --> 0 >>> >>> 1 0 0 0 0 0 1 1 1 ( 449=3D=3D0x1c1=3D=3Db111000001) --> 1 >>> >>> 1 1 0 0 0 0 0 1 1 ( 387=3D=3D0x183=3D=3Db110000011) --> 3 >>> >>> 1 1 1 0 0 0 0 0 1 ( 263=3D=3D0x107=3D=3Db100000111) --> 7 >>> >>> 1 1 1 1 0 0 0 0 0 ( 15=3D=3D0x00f=3D=3Db000001111) --> 15 >>> >>> 0 1 1 1 1 0 0 0 0 ( 30=3D=3D0x01e=3D=3Db000011110) --> 14 >>> >>> 1 0 1 1 1 1 0 0 0 ( 61=3D=3D0x03d=3D=3Db000111101) --> 13 >>> >>> 1 1 0 1 1 1 1 0 0 ( 123=3D=3D0x07b=3D=3Db001111011) --> 11 >>> >>> 1 1 1 0 1 1 1 1 0 ( 247=3D=3D0x0f7=3D=3Db011110111) --> 7 >>> >>> 1 1 1 1 0 1 1 1 1 ( 495=3D=3D0x1ef=3D=3Db111101111) --> 15 >>> >>> 1 1 1 1 1 0 1 1 1 ( 479=3D=3D0x1df=3D=3Db111011111) --> 15 >>> >>> >>> >>> SHUFFLE: [15, 14, 12, 8, 0, 0, 1, 3, 7, 15, 14, 13, 11, 7, 15, 15] >>> >>> >>> >>> =3D=3D=3D Step b. >>> >>> >>> >>> CHANNELS is a macHoppingSequenceLength-sized array that is initially >>> populated w >>> >>> ith the monotonically increasing list of channels available to the PHY. >>> >>> >>> >>> CHANNELS: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15] >>> >>> >>> >>> =3D=3D=3D Step c. >>> >>> >>> >>> CHANNELS is shuffled as per Figure 7a. Elements may wind up being >>> swapped multip >>> >>> le times in this process. >>> >>> >>> >>> macHoppingSequenceList: *[5, 6, 12, 7, 15, 4, 14, 11, 8, 0, 1, 2, 13, >>> 3, 9, 10]* >>> >>> >>> >>> >>> >>> Script ended normally, press Enter to close. >>> >>> >>> On Friday, November 7, 2014, Xavier Vilajosana < >>> xvilajosana@eecs.berkeley.edu> wrote: >>> >>> Dear Kees, >>> >>> thanks for your comments. >>> >>> >>> >>> answering 1) >>> >>> IMHO the fact that if default ch. hopping sequence is being used *may >>> not be* advertised in the EB it is not clear in the standard. And >>> therefore I opted to make the EB explicit (even only an ID and this bei= ng >>> the default) >>> >>> Page 11 of the 15.4e amendment indicates that: >>> >>> >>> >>> *All hopping sequences are referred to by an ID, macHoppingSequenceID, >>> with ID =3D 0 denoting the default* >>> >>> *sequence for a particular PHY (or PHY configuration if the PHY support= s >>> more than one channel list).* >>> >>> >>> >>> then page 92 >>> >>> *The full Hopping Sequence may be omitted to ensure that the frame does >>> not exceed aMaxPHYPacketSize.* >>> >>> *In this case only the Hopping Sequence ID is carried, and the length o= f >>> the IE is 1 octet. When the length is* >>> >>> *not equal to one, the additional fields are present. The element varie= s >>> in length depending upon the* >>> >>> *numberOfChannels in use by the PHY. The channelPage and >>> numberOfChannels attributes can be used to* >>> >>> *determine the size of the extendedBitmap, and the >>> macHoppingSequenceLength can be used to determine* >>> >>> *the size of the macHoppingSequenceList.* >>> >>> *The Channel Hopping IE may be used by any channel hopping PAN to >>> synchronize devices.* >>> >>> >>> >>> My last point here is that this *may* might indicate optionality but >>> the case for the default id is not mentioned so I am not sure it can be >>> elided if default id (0) >>> >>> >>> >>> answering 2) it seems a good point. Let us think about it. >>> >>> >>> >>> regards, >>> >>> Xavi >>> >>> >>> >>> 2014-11-07 9:57 GMT+01:00 Kees Trommel : >>> >>> Hi, >>> >>> This draft specifies that the enhanced beacon should include a Channel >>> Hopping IE with a Hopping Sequence ID equal to 0. Hopping Sequence ID 0= is >>> the default hopping sequence ID. So the actual hopping sequence will no= t be >>> included in the enhanced beacon. >>> >>> Section 5.1.1a of the IEE802.25.4e standard defines an algorithm to >>> calculate a default hopping sequence ID. >>> >>> I have the following questions regarding the default hopping sequence: >>> >>> 1. Is it the intention that a minimal configuration uses the default >>> hopping sequence as defined in the IEE802.25.4e standard? >>> 2. If the answer on 1. is yes: The definition of the IEE802.25.4e >>> hopping sequence (in my opinion) is not unambiguous, so can you add the >>> actual default hopping sequence to this draft? >>> >>> Regards, >>> >>> Kees. >>> >>> On Oct 27, 2014, at 12:20 AM, Xavier Vilajosana >> eecs.berkeley.edu> wrote: >>> >>> >>> All, I just published the new version of minimal. It includes a >>> security section as discussed last call and some changes to the default >>> timing to be according to 15.4 tsch default values. >>> >>> >>> >>> regards, >>> Xavi >>> >>> >>> >>> ---------- Forwarded message ---------- >>> From: >>> Date: 2014-10-27 5:17 GMT+01:00 >>> Subject: [6tisch] I-D Action: draft-ietf-6tisch-minimal-03.txt >>> To: i-d-announce at ietf.org >>> Cc: 6tisch at ietf.org >>> >>> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the IPv6 over the TSCH mode of IEEE >>> 802.15.4e Working Group of the IETF. >>> >>> Title : Minimal 6TiSCH Configuration >>> Authors : Xavier Vilajosana >>> Kris Pister >>> Filename : draft-ietf-6tisch-minimal-03.txt >>> Pages : 22 >>> Date : 2014-10-26 >>> >>> Abstract: >>> This document describes the minimal set of rules to operate a >>> [IEEE802154e] Timeslotted Channel Hopping (TSCH) network. This >>> minimal mode of operation can be used during network bootstrap, as a >>> fall-back mode of operation when no dynamic scheduling solution is >>> available or functioning, or during early interoperability testing >>> and development. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal/ >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-6tisch-minimal-03 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6tisch-minimal-03 >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> 6tisch mailing list >>> 6tisch at ietf.org >>> https://www.ietf.org/mailman/listinfo/6tisch >>> >>> >>> >>> _______________________________________________ >>> 6tisch mailing list >>> 6tisch at ietf.org >>> https://www.ietf.org/mailman/listinfo/6tisch >>> >>> >>> >>> >>> _______________________________________________ >>> 6tisch mailing list >>> 6tisch@ietf.org >>> https://www.ietf.org/mailman/listinfo/6tisch >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >> >> > --047d7b15a45398839505078da7b1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Xavi, thanks for your comments. What do others think?

    On Mon, Nov 10, = 2014 at 6:18 PM, Xavier Vilajosana <xvilajosana@eecs.berkeley.= edu> wrote:
    Hi,=C2=A0

    Thomas convinced me. As it is som= ething 15.4 TSCH specific it seems reasonable to have it at the tsch draft = and indicate the use of the default channel hopping sequence in minimal. Mi= nimal won't be self-contained but it is not alreday.

    regards,
    Xavi
    =

    2014-11-11 1:53 G= MT+01:00 Thomas Watteyne <watteyne@eecs.berkeley.edu>:
    Pascal,

    draft-ietf-6tisch-minimal should contain that it requires the defaul= t channel hopping pattern. I think we agree on that.

    The description of what the default channel hopping pattern is (this is = just a discussion about IEEE802.15.4e-2012, nothing 6TiSCH specific), might= end up in=C2=A06tisch/draft-ietf-6tisch-tsch.

    Wha= t do others think?

    T= homas



    On Mon, Nov 10, 2014 = at 10:57 AM, Pascal Thubert (pthubert) <pthubert@cisco.com>= wrote:

    Hi Thomas:<= /span>

    =C2=A0

    I think:

    - that the TSCH draft cou= ld discuss what is sub-defined in TSCH, indicate that we use the range 0-15= , to address Kees=E2=80=99 points

    - but then, the setting t= o be used in minimal, and pseudo code along the lines you produced should g= o in minimal to ensure interop. The pseudo code would be an appendix.

    =C2=A0

    Makes sense?

    =C2=A0

    Pascal

    =C2=A0

    From: 6tisch [= mailto:6tisch-= bounces@ietf.org] On Behalf Of Thomas Watteyne
    Sent: lundi 10 novembre 2014 12:17
    To: Xavier Vilajosana
    Cc: Kees Trommel; 6tisch@ietf.org
    Subject: Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-03.txt

    =C2=A0

    Quick thought: does this discussion fit in=C2=A0draf= t-ietf-6tisch-minimal or draft-ietf-6tisch-tsch? Both make sense to me.<= /u>

    =C2=A0

    On Mon, Nov 10, 2014 at 10:15 AM, Xavier Vilajosana = <xvil= ajosana@eecs.berkeley.edu> wrote:

    Hi,=C2=A0

    =C2=A0

    my 5 cents. After thinking about it I am in favour o= f adding the example as the draft will be more self-contained and will faci= litate the understanding of how ch. hopping sequence is caluclated. (analog= ously to the OF0 example).=C2=A0

    =C2=A0

    regards,

    Xavi

    =C2=A0

    2014-11-10 19:41 GMT+01:00 Thomas Watteyne <watteyne@eecs.be= rkeley.edu>:

    Kees,

    =C2=A0

    In this script you made the assumption that the hopp= ing sequence length is equal to the number of channels. I think this is rea= sonable assumption but it is not defined in the IEEE802.15.4e standard, so = it would be good idea to put this assumption in the draft too.

    =C2=A0

    Yes, that was my assumption in this code.<= /u>

    =C2=A0

    You are using channel numbers 0 - 15 and I assume th= at these are the 16 2.5GHz channels. The IEEE802.15.4e standard define thes= e as channel numbers 11 - 26 of page 0. It is fine for me to keep the 0 - 1= 5 channel numbering scheme but it would good to mention this too. What about (future) support of other chann= els and pages defined in the IEEE802.15.4e standard?

    =C2=A0

    Correct, you should add 11 to the channel numbers in= the code to use channel numbers 11-26 in IEEE notation (2.405GHz-2.480GHz)= . AFAICT, there is nothing in the hopping sequence of IEEE802.15.4e-TSCH wh= ich prevents the use of (future) sets of channels.

    =C2=A0

    @all, what do others think? Are details about= the hopping sequence something we need to add to draft-ietf-6tisch-minimal= ?

    =C2=A0

    Thomas

    =C2=A0

    On Mon, Nov 10, 2014 at 12:10 AM, Kees Trommel <<= a href=3D"mailto:ctrommel@aimvalley.nl" target=3D"_blank">ctrommel@aimvalle= y.nl> wrote:

    Thomas, Xavi,

    Thanks, I cannot find anything in this script that would violate the IEEE80= 2.15.4e standard.

    In this script you made the assumption that the hopping sequence length is = equal to the number of channels. I think this is reasonable assumption but = it is not defined in the IEEE802.15.4e standard, so it would be good idea t= o put this assumption in the draft too.

    You are using channel numbers 0 - 15 and I assume that these are the 16 2.5= GHz channels. The IEEE802.15.4e standard define these as channel numbers 11= - 26 of page 0. It is fine for me to keep the 0 - 15 channel numbering sch= eme but it would good to mention this too. What about (future) support of other channels and pages defined = in the IEEE802.15.4e standard?

    Kees.



    On 11/10/14 00:29, Thomas Watteyne wrote:

    Kees, Xavi,

    =C2=A0

    If the default hopping sequence isn't clear in I= EEE802.15.4e-2012, this is important information to the fed back to the IEE= E802.15.4 TG. @PatKinney, maybe you can chime in on whether the related text will = be changed in IEEE802.15.4-2015?

    =C2=A0

    In any case, let's disambiguate the hopping sequ= ence on this thread. We could add an example in draft-ietf-6tisch-minimal, = and maybe ask IEEE802.15.4 to do the same.

    =C2=A0

    I have created some quick Python code which I believ= e calculates the default hopping sequence, see https://gist.github.com/twatteyne/2e22ee3c1a802b685695.

    =C2=A0

    Could someone (Pat? Jonathan?) double-= check that it computes the right sequence. I'm copy-= pasting the output below.

    =C2=A0

    Thomas

    =C2=A0

    ---

    =C2=A0

    = This script calculates the default channel hopping sequence for the<= u>

    = IEEE802.15.4e-2012 TSCH mode.

    =C2=A0

    = \author Thomas Watteyne

    = \date November 2014

    =C2=A0

    =C2=A0

    = =3D=3D=3D Step a.

    =C2=A0

    = SHUFFLE is a macHoppingSequenceLength-sized array. The contents of this arr= ay ar

    = e equivalent to the first macHoppingSequenceLength outputs of a 9-bit linea= r fee

    = dback shift register (LFSR) with polynomial x9 + x5 + 1 and a starting seed= of 2

    = 55. Each LFSR output is modulo macHoppingSequenceLength, so that each entry= of S

    = HUFFLE is between 0 and (macHoppingSequenceLength - 1), inclusive.

    =C2=A0

    = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A05 =C2=A0 =C2=A0 =C2=A0 9=

    = =C2=A0 =C2=A01 1 1 1 1 1 1 1 0 ( 255=3D=3D0x0ff=3D=3Db011111111)<= /u>

    = =C2=A0 =C2=A01 1 1 1 1 1 1 1 1 ( 511=3D=3D0x1ff=3D=3Db111111111) --> 15<= /span>

    = =C2=A0 =C2=A00 1 1 1 1 1 1 1 1 ( 510=3D=3D0x1fe=3D=3Db111111110) --> 14<= /span>

    = =C2=A0 =C2=A00 0 1 1 1 1 1 1 1 ( 508=3D=3D0x1fc=3D=3Db111111100) --> 12<= /span>

    = =C2=A0 =C2=A00 0 0 1 1 1 1 1 1 ( 504=3D=3D0x1f8=3D=3Db111111000) --> 8

    = =C2=A0 =C2=A00 0 0 0 1 1 1 1 1 ( 496=3D=3D0x1f0=3D=3Db111110000) --> 0

    = =C2=A0 =C2=A00 0 0 0 0 1 1 1 1 ( 480=3D=3D0x1e0=3D=3Db111100000) --> 0

    = =C2=A0 =C2=A01 0 0 0 0 0 1 1 1 ( 449=3D=3D0x1c1=3D=3Db111000001) --> 1

    = =C2=A0 =C2=A01 1 0 0 0 0 0 1 1 ( 387=3D=3D0x183=3D=3Db110000011) --> 3

    = =C2=A0 =C2=A01 1 1 0 0 0 0 0 1 ( 263=3D=3D0x107=3D=3Db100000111) --> 7

    = =C2=A0 =C2=A01 1 1 1 0 0 0 0 0 ( =C2=A015=3D=3D0x00f=3D=3Db000001111) -->= ; 15

    = =C2=A0 =C2=A00 1 1 1 1 0 0 0 0 ( =C2=A030=3D=3D0x01e=3D=3Db000011110) -->= ; 14

    = =C2=A0 =C2=A01 0 1 1 1 1 0 0 0 ( =C2=A061=3D=3D0x03d=3D=3Db000111101) -->= ; 13

    = =C2=A0 =C2=A01 1 0 1 1 1 1 0 0 ( 123=3D=3D0x07b=3D=3Db001111011) --> 11<= /span>

    = =C2=A0 =C2=A01 1 1 0 1 1 1 1 0 ( 247=3D=3D0x0f7=3D=3Db011110111) --> 7

    = =C2=A0 =C2=A01 1 1 1 0 1 1 1 1 ( 495=3D=3D0x1ef=3D=3Db111101111) --> 15<= /span>

    = =C2=A0 =C2=A01 1 1 1 1 0 1 1 1 ( 479=3D=3D0x1df=3D=3Db111011111) --> 15<= /span>

    =C2=A0

    = SHUFFLE: =C2=A0[15, 14, 12, 8, 0, 0, 1, 3, 7, 15, 14, 13, 11, 7, 15, 15]

    =C2=A0

    = =3D=3D=3D Step b.

    =C2=A0

    = CHANNELS is a macHoppingSequenceLength-sized array that is initially popula= ted w

    = ith the monotonically increasing list of channels available to the PHY.

    =C2=A0

    = CHANNELS: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15]<= /u>

    =C2=A0

    = =3D=3D=3D Step c.

    =C2=A0

    = CHANNELS is shuffled as per Figure 7a. Elements may wind up being swapped m= ultip

    = le times in this process.

    =C2=A0

    = macHoppingSequenceList: [5, 6, 12, 7, 15, 4, 14, 11= , 8, 0, 1, 2, 13, 3, 9, 10]

    =C2=A0

    =C2=A0

    = Script ended normally, press Enter to close.


    On Friday, November 7, 2014, Xavier Vilajosana <xvilajosana@eecs.berkeley.edu> wrote:

    Dear Kees,

    thanks for your comments.=C2=A0

    =C2=A0

    answering 1)

    IMHO the fact that if default ch. hopping sequence i= s being used may not be advertised in the EB it is not clear in the standard. And= therefore I opted to make the EB explicit (even only an ID and this being = the default)

    Page 11 of the 15.4e amendment indicates that:

    =C2=A0

    All hopping sequences are referred to by an ID, m= acHoppingSequenceID, with ID =3D 0 denoting the default

    sequence for a particular PHY (or PHY configurati= on if the PHY supports more than one channel list).

    =C2=A0

    then page 92

    The full Hopping Sequence may be omitted to ensur= e that the frame does not exceed aMaxPHYPacketSize.

    In this case only the Hopping Sequence ID is carr= ied, and the length of the IE is 1 octet. When the length is<= /u>

    not equal to one, the additional fields are prese= nt. The element varies in length depending upon the

    numberOfChannels in use by the PHY. The channelPa= ge and numberOfChannels attributes can be used to

    determine the size of the extendedBitmap, and the= macHoppingSequenceLength can be used to determine

    the size of the macHoppingSequenceList.

    The Channel Hopping IE may be used by any = channel hopping PAN to synchronize devices.

    =C2=A0

    My last point here is that this may=C2=A0migh= t indicate optionality but the case for the default id is not mentioned so = I am not sure it can be elided if default id (0)

    =C2=A0

    answering 2) it seems a good point. Let us think abo= ut it.

    =C2=A0

    regards,

    Xavi

    =C2=A0

    2014-11-07 9:57 GMT+01:00 Kees Trommel <ctrommel@aimvalley.nl>:

    Hi,

    This draft specifies that the enhanced beacon should include a Channel Hopp= ing IE with a Hopping Sequence ID equal to 0. Hopping Sequence ID 0 is the = default hopping sequence ID. So the actual hopping sequence will not be inc= luded in the enhanced beacon.

    Section 5.1.1a of the IEE802.25.4e standard defines an algorithm to calcula= te a default hopping sequence ID.

    I have the following questions regarding the default hopping sequence:

    1. Is it the intention that a minimal configuration uses the default hoppin= g sequence as defined in the IEE802.25.4e standard?
    2. If the answer on 1. is yes:=C2=A0 The definition of the IEE802.25.4e hop= ping sequence (in my opinion) is not unambiguous, so can you add the actual= default hopping sequence to this draft?

    Regards,

    Kees.

    On Oct 27, 2014, at 12:20 AM, Xavier Vilajosana <xvilajosana at
    eecs.berkeley.edu> w= rote:


    All, I just published the new version of minimal. It= includes a security section as discussed last call and some changes to the= default timing to be according to 15.4 tsch default values.

    =C2=A0

    regards,
    Xavi

    =C2=A0

    ---------- Forwarded message ----------
    From: <internet-drafts at = ietf.org>
    Date: 2014-10-27 5:17 GMT+01:00
    Subject: [6tisch] I-D Action: draft-ietf-6tisch-minimal-03.txt
    To: i-d-announce at ietf.org<= /a>
    Cc: 6tisch at
    ietf.org


    A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
    =C2=A0This draft is a work item of the IPv6 over the TSCH mode of IEEE 802.= 15.4e Working Group of the IETF.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Minimal 6TiSCH Configuration
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Xavi= er Vilajosana
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Kris Pister
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-6tisch-minimal-03.txt
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 22
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2014-10-26

    Abstract:
    =C2=A0 =C2=A0This document describes the minimal set of rules to operate a<= br> =C2=A0 =C2=A0[IEEE802154e] Timeslotted Channel Hopping (TSCH) network.=C2= =A0 This
    =C2=A0 =C2=A0minimal mode of operation can be used during network bootstrap= , as a
    =C2=A0 =C2=A0fall-back mode of operation when no dynamic scheduling solutio= n is
    =C2=A0 =C2=A0available or functioning, or during early interoperability tes= ting
    =C2=A0 =C2=A0and development.


    The IETF datatracker status page for this draft is:
    https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal/<= /a>

    There's also a htmlized version available at:
    http://tools.ietf.org/html/draft-ietf-6tisch-minimal-03

    A diff from the previous version is available at:
    http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6tisch-min= imal-03


    Please note that it may take a couple of minutes from the time of submissio= n
    until the htmlized version and diff are available at tools.ietf.org.

    Internet-Drafts are also available by anonymous FTP at:
    ftp://ftp= .ietf.org/internet-drafts/

    _______________________________________________
    6tisch mailing list
    6tisch at ietf.org
    = https://www.ietf.org/mailman/listinfo/6tisch

    =C2=A0

    _______________________________________________
    6tisch mailing list
    6tisch at ietf.org
    = https://www.ietf.org/mailman/listinfo/6tisch

    =C2=A0


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

    =C2=A0

    =C2=A0

    =C2=A0

    =C2=A0

    =C2=A0




    --047d7b15a45398839505078da7b1-- From nobody Tue Nov 11 07:37:01 2014 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C1041A8A5A for <6tisch@ietfa.amsl.com>; Tue, 11 Nov 2014 07:37:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.494 X-Spam-Level: X-Spam-Status: No, score=-14.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S2w2qehWy0aQ for <6tisch@ietfa.amsl.com>; Tue, 11 Nov 2014 07:36:56 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB3571A8AAF for <6tisch@ietf.org>; Tue, 11 Nov 2014 07:36:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26687; q=dns/txt; s=iport; t=1415720216; x=1416929816; h=from:to:subject:date:message-id:mime-version; bh=AOElM9X4nbTmONCP66BVkyZ2JyGGdeV1VJivSNfagTI=; b=Do6odCz6ZAty7bMy2pWKYSYYPwNvO9z3WicEQaTYel858pnxOExmmY8b 9Xw2jN/pk6VIR3u+Idt3cZaOJu705ydaWJlnEfH67SCuBHS2kDpXmxVGI X/WIBD/OWnHokUjzxLnZx2Md4avzOctu5j9cntciME2c672ziTpzojIlV s=; X-Files: Changetouri.txt, versioning.txt : 11489, 4280 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAAgsYlStJV2Q/2dsb2JhbABSCoJIRlRdzCGHT4EZFgEBAQEBfYQJJ2QBDEQwJwQhiDMNqEWlYwEBAQEBAQQBAQEBAQEBARYEjViCUBBBF4RWBYY6i3eCGIFSaYJHhFqBNIcBhniHM4N6gXs5gQMBAQE X-IronPort-AV: E=Sophos;i="5.07,362,1413244800"; d="txt'?scan'208,217";a="371193373" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-7.cisco.com with ESMTP; 11 Nov 2014 15:36:52 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id sABFaq0u000885 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <6tisch@ietf.org>; Tue, 11 Nov 2014 15:36:52 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.91]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0195.001; Tue, 11 Nov 2014 09:36:52 -0600 From: "Raghuram Sudhaakar (rsudhaak)" To: "6tisch@ietf.org" <6tisch@ietf.org> Thread-Topic: CoAP resource management - draft-ietf-6tisch-coap-02 Thread-Index: AQHP/cVQc+aUxQBFuUqRL08yJHRHSQ== Date: Tue, 11 Nov 2014 15:36:51 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [10.21.86.174] Content-Type: multipart/mixed; boundary="_005_D0876D12C03Crsudhaakciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch/KP78NaV0V8EANQKMYxlDwDPbc0A Subject: [6tisch] CoAP resource management - draft-ietf-6tisch-coap-02 X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 15:37:00 -0000 --_005_D0876D12C03Crsudhaakciscocom_ Content-Type: multipart/alternative; boundary="_000_D0876D12C03Crsudhaakciscocom_" --_000_D0876D12C03Crsudhaakciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable All, The chairs and the authors discussed the CoAP draft recently. We agreed tha= t we need to push the CoAP draft since CoMAN may take a long time to conver= ge and become usable. We also agreed that some changes were required to the= CoAP draft to make any future transition to CoMAN easy. The changes discus= sed are as follows - 1. Add versioning info =96 This will allow heterogenous 6top nodes to co= mmunicate in the same network and PCE (or peer nodes) to take advantages of= resources available in future versions. Also allows easier transition to C= oMAN. * Added text to RFC. attached changes in versioning.txt (this is a g= it diff for easy review) 2. Shorten resource names =96 to reduce overhead * Added text to RFC. Attached changes in changetouri.txt The third and most important discussion was - 3. How do nodes exchange the version data (with PCE and other nodes) of nod= es so a network of heterogenous nodes (w.r.t version) can interoperate. 1. Proposal - use the joining flows defined in draft-richardson-6tisch--sec= urity-6top-03 Comments and suggestions on this proposal are requested. The updated draft is available on bitbucket - https://bitbucket.org/6tisch/= draft-ietf-6tisch-coap/overview -raghuram --_000_D0876D12C03Crsudhaakciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
    All,

    The chairs and the authors discussed the CoAP draft recently. We agree= d that we need to push the CoAP draft since CoMAN may take a long time to c= onverge and become usable. We also agreed that some changes were required t= o the CoAP draft to make any future transition to CoMAN easy. The changes discussed are as follows -
    1. Add versioning info =96 This will allow heterogenous 6top nodes to comm= unicate in the same network and PCE (or peer nodes) to take advantages of r= esources available in future versions. Also allows easier transition to CoM= AN.
      1. Added text to RFC. attached changes in versioning.txt (this is a git di= ff for easy review)
    2. Shorten resource names =96 to reduce overhead
      1. Added text to RFC. Attached changes in changetouri.txt
    The third and most important discussion was -
    3. How= do nodes exchange the version data (with PCE and other nodes) of nodes so = a network of heterogenous nodes (w.r.t version) can interoperate.
    1. P= roposal - use the joining flows defined in draft-rich= ardson-6tisch--security-6top-03

    Comments and suggestions on this proposal are requested.

    The updated draft is available on bitbucket - https://bitbucket.org= /6tisch/draft-ietf-6tisch-coap/overview

    -raghuram
    <= /span>
    --_000_D0876D12C03Crsudhaakciscocom_-- --_005_D0876D12C03Crsudhaakciscocom_ Content-Type: text/plain; name="Changetouri.txt" Content-Description: Changetouri.txt Content-Disposition: attachment; filename="Changetouri.txt"; size=11489; creation-date="Tue, 11 Nov 2014 15:36:51 GMT"; modification-date="Tue, 11 Nov 2014 15:36:51 GMT" Content-ID: Content-Transfer-Encoding: base64 ZGlmZiAtLWdpdCBhL2RyYWZ0LWlldGYtNnRpc2NoLWNvYXAtMDIueG1sIGIvZHJhZnQtaWV0Zi02 dGlzY2gtY29hcC0wMi54bWwKaW5kZXggNTdkODZhNi4uZjhmZGU4NCAxMDA2NDQKLS0tIGEvZHJh ZnQtaWV0Zi02dGlzY2gtY29hcC0wMi54bWwKKysrIGIvZHJhZnQtaWV0Zi02dGlzY2gtY29hcC0w Mi54bWwKQEAgLTE3NywyOCArMTc3LDI4IEBACiB8IE5hbWUgICAgICAgIHwgQWNjZXNzaWJpbGl0 eSAgIHwgVVJJIHBhdGggICAgICB8CiB8ICAgICAgICAgICAgIHwgNnRvcCBDb21tYW5kcyAgIHwg ICAgICAgICAgICAgICB8CiArLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0t LS0tLS0tLS0rCi18IE5laWdoYm9yICAgIHwgQ1JFQVRFL1JFQUQvICAgIHwgNnQvTmVpZ2hib3Ig ICB8Cit8IE5laWdoYm9yICAgIHwgQ1JFQVRFL1JFQUQvICAgIHwgNnQvbmIgICAgICAgICB8CiB8 IExpc3QgICAgICAgIHwgREVMRVRFL1VQREFURSAgIHwgICAgICAgICAgICAgICB8CiArLS0tLS0t LS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rCi18IHNsb3RmcmFtZSAg IHwgQ1JFQVRFL1JFQUQvICAgIHwgNnQvc2xvdGZyYW1lICB8Cit8IHNsb3RmcmFtZSAgIHwgQ1JF QVRFL1JFQUQvICAgIHwgNnQvc2YgICAgICAgICB8CiB8IExpc3QgICAgICAgIHwgREVMRVRFL1VQ REFURSAgIHwgICAgICAgICAgICAgICB8CiArLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0t LSstLS0tLS0tLS0tLS0tLS0rCi18IENlbGwgICAgICAgIHwgQ1JFQVRFL1JFQUQvICAgIHwgNnQv Q2VsbCAgICAgICB8Cit8IENlbGwgICAgICAgIHwgQ1JFQVRFL1JFQUQvICAgIHwgNnQvY2wgICAg ICAgICB8CiB8IExpc3QgICAgICAgIHwgREVMRVRFL1VQREFURSAgIHwgICAgICAgICAgICAgICB8 CiArLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rCi18IFRp bWUgICAgICAgIHwgQ1JFQVRFL1JFQUQvICAgIHwgNnQvVGltZVNvdXJjZSB8Cit8IFRpbWUgICAg ICAgIHwgQ1JFQVRFL1JFQUQvICAgIHwgNnQvdHMgICAgICAgICB8CiB8IFNvdXJjZSAgICAgIHwg REVMRVRFL1VQREFURSAgIHwgICAgICAgICAgICAgICB8CiArLS0tLS0tLS0tLS0tLSstLS0tLS0t LS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rCi18IExhYmVsU3dpdGNoIHwgQ1JFQVRFL1JFQUQv ICAgIHwgNnQvTGJsU3dpdGNoICB8Cit8IExhYmVsU3dpdGNoIHwgQ1JFQVRFL1JFQUQvICAgIHwg NnQvbHMgICAgICAgICB8CiB8IExpc3QgICAgICAgIHwgREVMRVRFL1VQREFURSAgIHwgICAgICAg ICAgICAgICB8CiArLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0t LS0rCi18IFRyYWNrICAgICAgIHwgQ1JFQVRFL1JFQUQvICAgIHwgNnQvVHJhY2sgICAgICB8Cit8 IFRyYWNrICAgICAgIHwgQ1JFQVRFL1JFQUQvICAgIHwgNnQvdHIgICAgICAgICB8CiB8IExpc3Qg ICAgICAgIHwgREVMRVRFL1VQREFURSAgIHwgICAgICAgICAgICAgICB8CiArLS0tLS0tLS0tLS0t LSstLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rCi18IEVCICAgICAgICAgIHwgQ1JF QVRFL1JFQUQvICAgIHwgNnQvRUIgICAgICAgICB8Cit8IEVCICAgICAgICAgIHwgQ1JFQVRFL1JF QUQvICAgIHwgNnQvZWIgICAgICAgICB8CiB8IExpc3QgICAgICAgIHwgREVMRVRFL1VQREFURSAg IHwgICAgICAgICAgICAgICB8CiArLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLSstLS0t LS0tLS0tLS0tLS0rCi18IENodW5rICAgICAgIHwgQ1JFQVRFL1JFQUQvICAgIHwgNnQvQ2h1bmsg ICAgICB8Cit8IENodW5rICAgICAgIHwgQ1JFQVRFL1JFQUQvICAgIHwgNnQvY2ggICAgICAgICB8 CiB8IExpc3QgICAgICAgIHwgREVMRVRFL1VQREFURSAgIHwgICAgICAgICAgICAgICB8CiArLS0t LS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rCiBdXT48L2FydHdv cms+CkBAIC0yMTEsMTQgKzIxMSwxNCBAQAogKy0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tKwogfCBGaWVsZCBuYW1lICB8IFVSSSBwYXRoICAgICAgICAgICAgICAgICAg fAogKy0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwotfCBOZWlnaGJv ciAgICB8IDZ0L05laWdoYm9yL1RhcmdldE5vZGVBZGRyfAorfCBOZWlnaGJvciAgICB8IDZ0L25i L3RuYSAJCSAJCSAgfAogfCBBZGRyICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAg fAogKy0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwotfCBBU04gICAg ICAgICB8IDZ0L05laWdoYm9yL0FTTiAgICAgICAgICAgfAorfCBBU04gICAgICAgICB8IDZ0L25i L2FzbiAgICAgICAgICAgCSAgfAogKy0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tKwotfCBSU1NJICAgICAgICB8IDZ0L05laWdoYm9yL1JTU0kgICAgICAgICAgfAorfCBS U1NJICAgICAgICB8IDZ0L25iL3Jzc2kgICAgICAgICAgCSAgfAogKy0tLS0tLS0tLS0tLS0rLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwotfCBMaW5rUXVhbGl0eSB8IDZ0L05laWdoYm9yL0xp bmtRdWFsaXR5ICAgfAorfCBMaW5rUXVhbGl0eSB8IDZ0L25iL2xxIAkJIAkJICB8CiArLS0tLS0t LS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCiBdXT48L2FydHdvcms+CiAgICAg ICAgICAgICAgICA8L2ZpZ3VyZT4gICAgICAgIApAQCAtMjMzLDEyICsyMzMsMTIgQEAKIHwgTmFt ZSAgICAgICAgfCBBY2Nlc3NpYmlsaXR5ICAgfCAgICBVUkkgcGF0aCAgICAgICAgICAgfAogfCAg ICAgICAgICAgICB8IDZ0b3AgQ29tbWFuZHMgICB8ICAgICAgICAgICAgICAgICAgICAgICB8CiAr LS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsK LXwgUXVldWUgICAgICAgfCBSRUFEL0NPTkZJR1VSRSAgfCA2dC9RdWV1ZSAgICAgICAgICAgICAg fAorfCBRdWV1ZSAgICAgICB8IFJFQUQvQ09ORklHVVJFICB8IDZ0L3F1IAkJCQl8CiArLS0tLS0t LS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKLXwgTW9u aXRvcmluZyAgfCBSRUFEL0NPTkZJR1VSRSAgfCA2dC9Nb25pdG9yaW5nU3RhdHVzICAgfAorfCBN b25pdG9yaW5nICB8IFJFQUQvQ09ORklHVVJFICB8IDZ0L21zIAkJCQl8CiB8IHN0YXR1cyAgICAg IHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgIHwKICstLS0tLS0tLS0t LS0tKy0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwotfCBTdGF0aXN0 aWNzICB8IFJFQUQvQ09ORklHVVJFICB8IDZ0L1N0YXRpc3RpY3NNZXRyaWNzICB8Cit8IFN0YXRp c3RpY3MgIHwgUkVBRC9DT05GSUdVUkUgIHwgNnQvc20gCQkJCXwKIHwgbWV0cmljcyAgICAgfCAg ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgfAogKy0tLS0tLS0tLS0tLS0r LS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCiBdXT48L2FydHdvcms+ CkBAIC0yNTQsNyArMjU0LDcgQEAKICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLSsKIEhlYWRlciAgfCBHRVQgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwKICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSsKLVVyaS1QYXRofCAvNnQvTmVpZ2hib3IgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHwKK1VyaS1QYXRofCAvNnQvbmIgCQkJCSAgIAkJCQkgICB8CiAgICAgICAgICstLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCiBPcHRpb25zIHwgQWNjZXB0 OiBhcHBsaWNhdGlvbi9jYm9yICAgICAgICAgICAgICAgICB8CiAgICAgICAgIHwgVXJpLVF1ZXJ5 OiBBQk5GKFRhcmdldE5vZGVBZGRyPT0weDEyMzQpICB8CkBAIC0yNjUsNyArMjY1LDcgQEAgT3B0 aW9ucyB8IEFjY2VwdDogYXBwbGljYXRpb24vY2JvciAgICAgICAgICAgICAgICAgfAogICAgICAg ICAgICAgICAgICAgU2luY2UgdGhpcyByZXNvdXJjZXMgcG9pbnRzIHRvIHRoZSBlbnRpcmUgbmVp Z2hib3IgbGlzdCwgdGhlIHJlc3BvbnNlIHJldHVybnMgYWxsIHRoZSBlbnRyaWVzICh0aGUgbGlz dCBvZiBuZWlnaGJvcnMgb2YgdGhhdCBub2RlKSBhbmQgYWxsIGZpZWxkcyBpbiBlYWNoIGVudHJ5 IChpLmUuIGVudHJ5IGZvciBhIG5laWdoYm9yKSBvZiB0aGUgbGlzdCBpbiBDQk9SIGZvcm1hdC4g QSByZXF1ZXN0IHdpdGggYSBVcmktUXVlcnkgb3B0aW9uIG1heSBiZSB1c2VkIHRvIHJldHJpZXZl IG9ubHkgc3BlY2lmaWMgZW50cmllcyBpbiB0aGUgbGlzdC4gVGhlIHZhbHVlIG9mIFVyaS1RdWVy eSBNVVNUIGJlIGluIHRoZSBBQk5GIGZvcm1hdCBhcyBkZXNjcmliZWQgaW4gPHhyZWYgdGFyZ2V0 ID0iUkZDNTIzNCIvPi4KICAgICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICAgIDx0Pgot ICAgICAgICAgICAgICAgICAgUmVzb3VyY2VzIHRoYXQgcG9pbnQgdG8gY29sbGVjdGlvbiB3aXRo aW4gYSBsaXN0LCBzdWNoIGFzICcvNnQvTmVpZ2hib3IvVGFyZ2V0Tm9kZUFkZHInLAorICAgICAg ICAgICAgICAgICAgUmVzb3VyY2VzIHRoYXQgcG9pbnQgdG8gY29sbGVjdGlvbiB3aXRoaW4gYSBs aXN0LCBzdWNoIGFzICcvNnQvbmIvdG5hJywKICAgICAgICAgICAgICAgICAgIHJldHVybnMgb25s eSB0aGUgdmFsdWVzIGluIHRoZSBUYXJnZXROb2RlQWRkciBlbnRyeSBvZiB0aGUgTmVpZ2hib3Ig bGlzdC4gVGhlIHVzYWdlCiAgICAgICAgICAgICAgICAgICBvZiB0aGUgVXJpLVF1ZXJ5IG9wdGlv biBoYXMgdGhlIHNhbWUgZWZmZWN0IG9mIGZpbHRlcmluZyBvbiB0aGUgcmVzdWx0LgogICAgICAg ICAgICAgICAgPC90PgpAQCAtMjgyLDE0ICsyODIsMTQgQEAgT3B0aW9ucyB8IEFjY2VwdDogYXBw bGljYXRpb24vY2JvciAgICAgICAgICAgICAgICAgfAogICAgICAgICArLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKIEhlYWRlciAgfCBQT1NUICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB8CiAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tKwotVXJpLVBhdGh8IC82dC9OZWlnaGJvciAgICAgICAgICAgICAgICAgICAgICAgIHwK K1VyaS1QYXRofCAvNnQvbmIgCQkJICAgICAgCQkJICB8CiAgICAgICAgICstLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwogUGF5bG9hZCB8IENCT1IoIHtUYXJnZXROb2RlQWRk cjogMHgxMjM0fSApICAgIHwKICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0rCiBdXT48L2FydHdvcms+CiAgICAgICAgICAgICAgICA8L2ZpZ3VyZT4KICAgICAg ICAgICAgICAgIDx0PgotICAgICAgICAgICAgICAgICAgVGhlIFBPU1QgbWV0aG9kIG1heSBub3Qg YmUgdXNlZCBvbiByZXNvdXJjZXMgdGhhdCBhcmUgY29sbGVjdGlvbiB3aXRoaW4gYSBsaXN0LCBz dWNoIGFzICcvNnQvTmVpZ2hib3IvVGFyZ2V0Tm9kZUFkZHInLgorICAgICAgICAgICAgICAgICAg VGhlIFBPU1QgbWV0aG9kIG1heSBub3QgYmUgdXNlZCBvbiByZXNvdXJjZXMgdGhhdCBhcmUgY29s bGVjdGlvbiB3aXRoaW4gYSBsaXN0LCBzdWNoIGFzICcvNnQvbmIvdG5hJy4KICAgICAgICAgICAg ICAgIDwvdD4KICAgICAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgICAgICAgVG8gZGVsZXRl IGEgTmVpZ2hib3IsIHRoZSBDb0FQIGNsaWVudCBNVVNUIHNlbmQgYSBERUxFVEUgbWVzc2FnZSBh cyBzaG93biBpbiA8eHJlZiB0YXJnZXQ9ImZpZzpkZWxtc2ciLz4uCkBAIC0yOTksNyArMjk5LDcg QEAgUGF5bG9hZCB8IENCT1IoIHtUYXJnZXROb2RlQWRkcjogMHgxMjM0fSApICAgIHwKICAgICAg ICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCiBIZWFkZXIgIHwgREVM RVRFICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgICAgICArLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKLVVyaS1QYXRofCAvNnQvTmVpZ2hib3IgICAgICAg ICAgICAgICAgICAgICAgICB8CitVcmktUGF0aHwgLzZ0L25iIAkJCSAgICAgIAkJCSAgfAogICAg ICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKIE9wdGlvbnMgfCBV cmktUXVlcnk6IEFCTkYoVGFyZ2V0Tm9kZUFkZHIgICAgICB8CiAgICAgICAgIHwgICAgICAgICAg ICAgICAgICAgICAgPT0gMHgxMjM0KSAgICAgfApAQCAtMzA3LDcgKzMwNyw3IEBAIE9wdGlvbnMg fCBVcmktUXVlcnk6IEFCTkYoVGFyZ2V0Tm9kZUFkZHIgICAgICB8CiBdXT48L2FydHdvcms+CiAg ICAgICAgICAgICAgICA8L2ZpZ3VyZT4KICAgICAgICAgICAgICAgIDx0PgotICAgICAgICAgICAg ICAgICAgQSBERUxFVEUgbWVzc2FnZSBTSE9VTEQgYWx3YXlzIGNvbnRhaW4gYSBVcmktUXVlcnkg b3B0aW9uIGluIG9yZGVyIHRvIGNsZWFybHkgc3BlY2lmeSB3aGljaCBlbnRyeShzKSB3aXRoaW4g dGhlIGxpc3QgbXVzdCBiZSBkZWxldGVkLiBJZGVhbGx5LCB0aGUgQ29BUCBjbGllbnQgU0hPVUxE IG1ha2Ugb25lIGNhbGwgcGVyIGVudHJ5IHRoYXQgbXVzdCBiZSBkZWxldGVkLiBBbiBpbXBsZW1l bnRhdGlvbiBtYXkgZGVjaWRlIHdoZXRoZXIgb3Igbm90IGEgREVMRVRFIG1ldGhvZCBvbiAnLzZ0 L05laWdoYm9yJyBtYXkgYmUgYWxsb3dlZC4KKyAgICAgICAgICAgICAgICAgIEEgREVMRVRFIG1l c3NhZ2UgU0hPVUxEIGFsd2F5cyBjb250YWluIGEgVXJpLVF1ZXJ5IG9wdGlvbiBpbiBvcmRlciB0 byBjbGVhcmx5IHNwZWNpZnkgd2hpY2ggZW50cnkocykgd2l0aGluIHRoZSBsaXN0IG11c3QgYmUg ZGVsZXRlZC4gSWRlYWxseSwgdGhlIENvQVAgY2xpZW50IFNIT1VMRCBtYWtlIG9uZSBjYWxsIHBl ciBlbnRyeSB0aGF0IG11c3QgYmUgZGVsZXRlZC4gQW4gaW1wbGVtZW50YXRpb24gbWF5IGRlY2lk ZSB3aGV0aGVyIG9yIG5vdCBhIERFTEVURSBtZXRob2Qgb24gJy82dC9uYicgbWF5IGJlIGFsbG93 ZWQuCiAgICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgICAgICA8dD4KICAgICAgICAgICAg ICAgICAgIFRoZSBlbmRwb2ludCBNVVNUIGFwcHJvcHJpYXRlbHkgcmVzcG9uZCB3aXRoIGEgMi4w MiAoRGVsZXRlZCkgbWVzc2FnZS4KQEAgLTMyMCwyNiArMzIwLDI2IEBAIE9wdGlvbnMgfCBVcmkt UXVlcnk6IEFCTkYoVGFyZ2V0Tm9kZUFkZHIgICAgICB8CiArLS0tLS0tLS0tLS0tLS0tLS0tLS0r LS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLSsKIHwgICBDb0FQ IG1ldGhvZCAgICAgIHwgIDZ0b3AgY29tbWFuZCAgfDZ0b3AgYmVoYXZpb3VyIHxDb0FQIFJlc3Bv bnNlfAogKy0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0t LS0tKy0tLS0tLS0tLS0tLS0rCi18IFBPU1QgLzZ0L05laWdoYm9yICB8IENyZWF0ZS5uZWlnaGJv cnwgQWRkcyBhICAgICAgICB8IDIuMDEgQ3JlYXRlZHwKK3wgUE9TVCAvNnQvbmIgCSAgICAgfCBD cmVhdGUubmVpZ2hib3J8IEFkZHMgYSAgICAgICAgfCAyLjAxIENyZWF0ZWR8CiB8IENCT1IoICAg ICAgICAgICAgICB8ICAgICAgICAgICAgICAgIHwgbmVpZ2hib3IgICAgICB8ICAgICAgICAgICAg IHwKIHwge1RhcmdldE5vZGVBZGRyOiAgIHwgKGFkZHJlc3Msc3RhdHMpfCAgICAgICAgICAgICAg IHwgICAgICAgICAgICAgfAogfCAgICAgICAgICAgICAxMjM0fSkgfCAgICAgICAgICAgICAgICB8 ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICB8CiArLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0t LS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLSsKLXwgR0VUIC82dC9O ZWlnaGJvciAgIHwgUmVhZC5hbGwuICAgICAgfCBSZWFkcyAgICAgICAgIHwgMi4wNSBDb250ZW50 fAorfCBHRVQgLzZ0L25iICAgICAgICAgfCBSZWFkLmFsbC4gICAgICB8IFJlYWRzICAgICAgICAg fCAyLjA1IENvbnRlbnR8CiB8ICAgICAgICAgICAgICAgICAgICB8IG5laWdoYm9yKCkgICAgIHwg YWxsICAgICAgICAgICB8IENCT1IoTmVpZ2gtIHwKIHwgICAgICAgICAgICAgICAgICAgIHwgICAg ICAgICAgICAgICAgfCBuZWlnaGJvcnMgICAgIHwgYm9yIExpc3QpICAgfAogKy0tLS0tLS0tLS0t LS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0r Ci18IEdFVCAvNnQvTmVpZ2hib3IgICB8IFJlYWQubmVpZ2hib3IgIHwgUmVhZHMgbmVpZ2hib3J8 IDIuMDUgQ29udGVudHwKK3wgR0VUIC82dC9uYiAgICAgICAgIHwgUmVhZC5uZWlnaGJvciAgfCBS ZWFkcyBuZWlnaGJvcnwgMi4wNSBDb250ZW50fAogfCBVcmktUXVlcnkgLSAgICAgICAgfCAgKGFk ZHJlc3MpICAgICB8IGluZm9ybWF0aW9uICAgfCBDQk9SKE5laWdoLSB8CiB8IFRhcmdldE5vZGVB ZGRyOiAgICB8ICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICB8IGJvciBMaXN0KSAgIHwK IHwgICAgICAgICAgICAgMTIzNH0pIHwgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgIHwg ICAgICAgICAgICAgfAogKy0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0rLS0t LS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0rCi18IFBPU1QgLzZ0L05laWdoYm9yICB8IFVwZGF0 ZS5uZWlnaGJvcnwgVXBkYXRlcyBhbiAgICB8IDIuMDQgQ2hhbmdlZHwKK3wgUE9TVCAvNnQvbmIg ICAgICAgIHwgVXBkYXRlLm5laWdoYm9yfCBVcGRhdGVzIGFuICAgIHwgMi4wNCBDaGFuZ2VkfAog fCBDQk9SKCAgICAgICAgICAgICAgfCAoYWRkcmVzcyxzdGF0cyl8IGVudHJ5ICAgICAgICAgfCAg ICAgICAgICAgICB8CiB8IHtUYXJnZXROb2RlQWRkcjogICB8ICAgICAgICAgICAgICAgIHwgICAg ICAgICAgICAgICB8ICAgICAgICAgICAgIHwKIHwgICAgICAgICAgICAgMTIzNH0pIHwgICAgICAg ICAgICAgICAgfCAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgfAogKy0tLS0tLS0tLS0tLS0t LS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0rCi18 IERFTEVURSAvNnQvTmVpZ2hib3J8RGVsZXRlLm5laWdoYm9yIHwgUmVtb3ZlcyAgICAgICB8IDIu MDIgRGVsZXRlZHwgCit8IERFTEVURSAvNnQvbmIgICAgICB8RGVsZXRlLm5laWdoYm9yIHwgUmVt b3ZlcyAgICAgICB8IDIuMDIgRGVsZXRlZHwgCiB8IFVyaS1RdWVyeSAtICAgICAgICB8IChhZGRy ZXNzKSAgICAgIHwgdGhlIG5laWdoYm9yICB8ICAgICAgICAgICAgIHwKIHwgVGFyZ2V0Tm9kZUFk ZHIgICAgIHwgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgfAog fCAgICAgICAgICA9PSAxMjM0fSkgfCAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgfCAg ICAgICAgICAgICB8CkBAIC0zODgsMTAgKzM4OCwxMCBAQCBDb0FQIENsaWVudCAgICAgICAgICAg ICAgICBOb2RlIEEgICAgICAgICAgICAgICAgICAgTm9kZSBBCiAgICAgICAgICAgICAgICAgICAg ICAgKENvQVAtZW5kcG9pbnQpICAgICAgICAgKDZ0b3Agc3VibGF5ZXIpCiAgICAgfCAgICAgQ29B UCBSZXF1ZXN0ICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAgfC0gLSAtIC0g LSAtIC0gLSAtIC0gLSAtPnwgNnRvcCBSZXF1ZXN0ICAgICAgICAgICB8Ci0gICAgfCBQT1NUIC82 dC9OZWlnaGJvciAgICAgIHwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLT58CisgICAgfCBQT1NUIC82 dC9uYiAgICAgICAgICAgIHwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLT58CiAgICAgfCBwYXlsb2Fk OiAgICAgICAgICAgICAgIHwgQ3JlYXRlLm5laWdoYm9yICAgICAgICB8IEFkZHMgYQogICAgIHwg Q0JPUih7VGFyZ2VydE5vZGVBZGRyOiB8IChhZGRyZXNzLHN0YXRzKSAgICAgICAgfCBuZWlnaGJv cgotCXwgICAgICAgICAgICAgMTIzNH0pICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgfCB3 aXRoIGFkZHJlc3MKKyAgICB8ICAgICAgICAgICAgIDEyMzR9KSAgICAgfCAgICAgICAgICAgICAg ICAgICAgICAgIHwgd2l0aCBhZGRyZXNzCiAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgIHwg ICAgICAgICAgICAgICAgICAgICAgICB8IDEyMzQKICAgICB8ICAgICAgICAgICAgICAgICAgICAg ICAgfCA2dG9wIENvbmZpcm0gICAgICAgICAgIHwKICAgICB8ICAgQ29BUCBSZXNwb25zZSAgICAg ICAgfDwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLXwKQEAgLTQwOSw3ICs0MDksNyBAQCBDb0FQIENs aWVudCAgICAgICAgICAgICAgICBOb2RlIEEgICAgICAgICAgICAgICAgICAgTm9kZSBBCiAgICAg ICAgICAgICAgICAgICAgICAgKENvQVAtZW5kcG9pbnQpICAgICAgICAgICg2dG9wIHN1YmxheWVy KQogICAgIHwgICAgIENvQVAgUmVxdWVzdCAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAg fAogICAgIHwtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLT58IDZ0b3AgUmVxdWVzdCAgICAgICAgICAg fAotICAgIHwgR0VUIC82dC9OZWlnaGJvciAgICAgICB8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+ fAorICAgIHwgR0VUIC82dC9uYiAgICAgICAgICAgICB8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+ fAogICAgIHwgVXJpLVF1ZXJ5IC0gICAgICAgICAgICB8IFJlYWQubmVpZ2hib3IoYWRkcmVzcykg fFJlYWRzIG5laWdoYm9yCiAgICAgfCBUYXJnZXROb2RlQWRkciAgICAgICAgIHwgICAgICAgICAg ICAgICAgICAgICAgICB8aW5mb3JtYXRpb24KICAgICB8ICAgICAgID09IDB4MTIzNCAgICAgICAg fCAgICAgICAgICAgICAgICAgICAgICAgIHwKQEAgLTQzMiw3ICs0MzIsNyBAQCBDb0FQIENsaWVu dCAgICAgICAgICAgICAgICAgTm9kZSBBICAgICAgICAgICAgICAgICAgIE5vZGUgQQogICAgICAg ICAgICAgICAgICAgICAgICAoQ29BUC1lbmRwb2ludCkgICAgICAgICAgKDZ0b3Agc3VibGF5ZXIp CiAgICAgfCAgICAgQ29BUCBSZWdpc3RlciAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAg fAogICAgIHwtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSA+fCA2dG9wIFJlcXVlc3QgICAgICAgICAg IHwKLSAgICB8IEdFVCAvNnQvTW9uaXRvcmluZ1N0YXR1c3wtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LT58CisgICAgfCBHRVQgLzZ0L21zIAkgICAgICAJICB8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+ fAogICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgfCBSZWFkLk1vbml0b3JpbmcuU3RhdHVz IHxSZWFkcwogICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAg ICAgICAgIHx0aGUgY3VycmVudAogICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAg ICAgICAgICAgICAgICAgICAgIHxNb25pdG9yaW5nIAo= --_005_D0876D12C03Crsudhaakciscocom_ Content-Type: text/plain; name="versioning.txt" Content-Description: versioning.txt Content-Disposition: attachment; filename="versioning.txt"; size=4280; creation-date="Tue, 11 Nov 2014 15:36:51 GMT"; modification-date="Tue, 11 Nov 2014 15:36:51 GMT" Content-ID: <4FE5AA687A2E504B8BC56B6002800187@emea.cisco.com> Content-Transfer-Encoding: base64 ZGlmZiAtLWdpdCBhL2RyYWZ0LWlldGYtNnRpc2NoLWNvYXAtMDIueG1sIGIvZHJhZnQtaWV0Zi02 dGlzY2gtY29hcC0wMi54bWwKaW5kZXggZjhmZGU4NC4uZWNkMzBiNiAxMDA2NDQKLS0tIGEvZHJh ZnQtaWV0Zi02dGlzY2gtY29hcC0wMi54bWwKKysrIGIvZHJhZnQtaWV0Zi02dGlzY2gtY29hcC0w Mi54bWwKQEAgLTE2MSwxMiArMTYxLDI1IEBACiAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICA8 L3NlY3Rpb24+CiAgICAgICAgICA8c2VjdGlvbiB0aXRsZT0iNlRpU0NIIFJlc291cmNlcyAiPgor CQkJCSA8dD4KKwkJCQkJCSBUaGUgNlRpU0NIIHJlc291cmNlcyBwcmVzZW50ZWQgaW4gdGhpcyBt ZW1vIG9mZmVyIGEgY29tcHJlaGVuc2l2ZSB3YXkgdG8gbWFuYWdlIDZ0b3Agbm9kZXMgYmFzZWQg b24gdGhlIHJlcXVpcmVtZW50IGtub3duIHRvIHVzIGFzIG9mIHRoaXMgd3JpdGluZy4gVGhlc2Ug cmVzb3VyY2VzIGFyZSBib3VuZCB0byBldm9sdmUgYW5kIHdpbGwgYmUgaWRlbnRpZmllZCBieSBh cHByb3ByaWF0ZSB2ZXJzaW9uIG51bWJlcnMgdGhhdCB3aWxsIGJlIHRpZWQgdG8gcmV2aXNpb25z IG9mIHRoaXMgUkZDLgorCQkJCSA8L3Q+CiAgICAgICAgICAgICA8dD4KICAgICAgICAgICAgICAg IE1hbmFnZW1lbnQgcmVzb3VyY2VzIGFyZSBjbGFzc2lmaWVkIGFzIHJlc291cmNlcyB0byB3aGlj aCBhIGhpZ2hlciBsYXllciBlbnRpdHkgbWF5IGNyZWF0ZSwgdXBkYXRlIG9yIGRlbGV0ZS4gVGhl eSBhcmUgdHlwaWNhbGx5IHVzZWQgdG8gY3JlYXRlIHNjaGVkdWxlcywgaWRlbnRpZnkgdGltZSBz b3VyY2VzIHRoYXQgVFNDSCBuZWVkcy4gVGhleSBhcmUgdGhlIG1lYW5zIHRvIGNsb3NlIHRoZSBj b250cm9sIGxvb3AgYmV0d2VlbiBUU0NIIGFuZCBoaWdoZXIgbGF5ZXJzLgogICAgICAgICAgICAg PC90PgogICAgICAgICAgICAgPHQ+CiAgICAgICAgICAgICAgICBJbmZvcm1hdGlvbmFsIHJlc291 cmNlcyBhcmUgY2xhc3NpZmllZCBhcyByZXNvdXJjZXMgdG8gd2hpY2ggYSBoaWdoZXIgbGF5ZXIg ZW50aXR5IHR5cGljYWxseSBoYXMgb25seSBSRUFEIGFjY2Vzcy4gVGhleSBhcmUgdHlwaWNhbGx5 IHVzZWQgdG8gbW9uaXRvciBvcGVyYXRpb25hbCBwYXJhbWV0ZXJzIG9mIFRTQ0ggYW5kIHRoZSB2 YWx1ZXMgdXNlZCBhcyBpbnB1dCB0byByb3V0aW5nIGFsZ29yaXRobXMgYW5kIG90aGVyIG1lY2hh bmlzbXMuCiAgICAgICAgICAgICA8L3Q+CisJCQkgICA8c2VjdGlvbiB0aXRsZT0iVmVyc2lvbmlu ZyI+CisJCQkJCSAgIDx0PgorCQkJCQkgICBUaGUgdmVyc2lvbiBudW1iZXIgZGVzY3JpYmVzIHRo ZSBzZXQgb2YgcmVzb3VyY2VzIHRoYXQgY2FuIGJlIGFjY2Vzc2VkIG9uIGEgbm9kZSB0aGF0IGlt cGxlbWVudHMgdGhlIHJlY29tbWVuZGF0aW9ucyBpbiB0aGlzIFJGQy4gVGhlIHZlcnNpb24gbnVt YmVyIGNvbnNpc3RzIG9mIGFuIGFzY2lpIGZvcm1hdHRlZCBzdHJpbmcgY29uc2l0aW5nIG9mIG1h am9yIHZlcnNpb24gbnVtYmVyIGFuZCBtaW5vciB2ZXJzaW9uIG51bWJlciBzZXBhcmF0ZWQgYnkg YSBwZXJpb2QgKGUuZy4gJ21ham9yJy4nbWlub3InKS4gVGhlIG1ham9yIGFuZCBtaW5vciB2ZXJz aW9uIG51bWJlcnMgcnVuIGZyb20gMSB0aHJvdWdoIDI1NSAoYm90aCBpbmNsdXNpdmUpLiAKKwkJ CSAgIDwvdD4KKwkJCSAgIDx0PiBFYWNoIHJldmlzaW9uIG9mIHRoaXMgUkZDIHdpbGwgZGVmaW5l IGEgdmVyc2lvbiBudW1iZXIgd2hpY2ggd2lsbCB1bmlxdWVseSBpZGVudGlmeSB0aGUgc2V0IG9m IHJlc291cmNlcyBkZWZpbmVkIGluIHRoYXQgcGFydGljdWxhciByZXZpc2lvbiBvZiB0aGUgUkZD LiBOb3RlIHRoYXQgdmVyc2lvbiBudW1iZXIgbWF5IG9yIG1heSBub3QgY2hhbmdlIGJldHdlZW4g cmV2aXNpb25zIG9mIHRoaXMgUkZDLiBBIGNoYW5nZSBpbmRpY2F0ZXMgdGhhdCB0aGUgcmVzb3Vy Y2VzIG9yIHRoZWlyIG1lc3NhZ2UgZm9ybWF0IGhhdmUgY2hhbmdlZC4KKwkJCSAgIDwvdD4KKwkJ CQkgPHQ+CisJCQkJCQkgVGhlIDZUaVNDSCByZXNvdXJjZSB2ZXJzaW9uIGluZm9ybWF0aW9uIGlz IGF2YWlsYWJsZSB0aHJvdWdoIHR3byBzb3VyY2VzLiBUaGUgZmlyc3QgaXMgYnkgZXhlY3V0aW5n IGEgR0VUIG1ldGhvZCBvbiB0aGUgcmVzb3VyY2UgJy82dC92ZScgb2YgYSA2dG9wIG5vZGUuIFRo aXMgbWV0aG9kLCBob3dldmVyLCBjYXVzZXMgYSBzaWduaWZpY2FudCBpbmNyZWFzZSBpbiBjb250 cm9sIHRyYWZmaWMgZHVlIHRvIHVuaWNhc3QgbmF0dXJlIG9mIHRoZSByZXF1ZXN0LiBUaGUgc2Vj b25kIG1ldGhvZCwgaXMgYnkgYWNjZXNzaW5nIHRoZSA2dG9wIElFJ3MuIDx4cmVmIHRhcmdldD0i SS1ELmlldGYtNnRpc2NoLTZ0b3AtaW50ZXJmYWNlIi8+IGRlc2NyaWJlcyB0aGUgWUFORyBtb2Rl bCBmb3IgdGhlIHZlcnNpb24gbnVtYmVyLiBBIDZ0b3Agbm9kZSBNVVNUIHJlc3BvbmQgd2l0aCB0 aGUgc2FtZSB2ZXJzaW9uIG51bWJlciBpcnJlc3BlY3RpdmUgb2YgdGhlIG1ldGhvZCB1c2VkLgor CQkJCSA8L3Q+CisJCQkgICA8L3NlY3Rpb24+CiAgICAgICAgICAgICA8c2VjdGlvbiB0aXRsZT0i TWFuYWdlbWVudCBSZXNvdXJjZXMiPgogICAgICAgICAgICAgICAgPHQ+CiAgICAgICAgICAgICAg ICAgICBBbGwgdGhlIGF0dHJpYnV0ZXMgaW4gdGhlIG1hbmFnZW1lbnQgcmVzb3VyY2VzIGhhdmUg dGhlIFJlYWQvV3JpdGUgYWNjZXNzaWJpbGl0eS4gVGhlIGZvbGxvd2luZyB0YWJsZSBsaXN0cyB0 aGUgNnRvcCBtYW5hZ2VtZW50IHJlc291cmNlcyBhbmQgdGhlIHJlbGF0ZWQgVVJJIHBhdGhzLgpA QCAtMjMzLDYgKzI0Niw4IEBACiB8IE5hbWUgICAgICAgIHwgQWNjZXNzaWJpbGl0eSAgIHwgICAg VVJJIHBhdGggICAgICAgICAgIHwKIHwgICAgICAgICAgICAgfCA2dG9wIENvbW1hbmRzICAgfCAg ICAgICAgICAgICAgICAgICAgICAgfAogKy0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0r LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCit8IFZlcnNpb24gCSAgfCBSRUFEICAJCQl8IDZ0L3Zl IAkJCQl8CisrLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0t LS0tLS0tLSsKIHwgUXVldWUgICAgICAgfCBSRUFEL0NPTkZJR1VSRSAgfCA2dC9xdSAJCQkJfAog Ky0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0r CiB8IE1vbml0b3JpbmcgIHwgUkVBRC9DT05GSUdVUkUgIHwgNnQvbXMgCQkJCXwKQEAgLTI0Myw2 ICsyNTgsMTYgQEAKICstLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tKwogXV0+PC9hcnR3b3JrPgogICAgICAgICAgICAgICAgPC9maWd1cmU+CisJ CQkgICA8c2VjdGlvbiB0aXRsZT0iVmVyc2lvbiI+CisJCQkJCQkJCSA8dD4KKwkJCQkJICAgVGhl IHZlcnNpb24gcmVzb3VyY2UgaXMgYSByZWFkLW9ubHkgcmVzb3VyY2UgdGhhdCBwcm92aWRlcyBp bmZvcm1hdGlvbiBvbiB0aGUgbWV0aG9kcywgcmVzb3VyY2VzLCBtZXNzYWdlIGZvcm1hdHMgdGhh dCBpcyBzdXBwb3J0ZWQgYnkgdGhlIG5vZGUuCisJCQkJCSAgIFRoZSB2ZXJzaW9uIHJlc291cmNl IGRvZXMgbm90IGRpcmVjdGx5IG1hcCB0byBhIDZ0b3AgcmVzb3VyY2UgZGVmaW5lZCBpbiA8eHJl ZiB0YXJnZXQ9IkktRC5pZXRmLTZ0aXNjaC02dG9wLWludGVyZmFjZSIvPi4KKwkJCQkJICAgVXBv biBleGVjdXRpbmcgYSBHRVQgb24gdGhlICcvNnQvdmUnIHJlc291cmNlLCB0aGUgbm9kZSByZXNw b25kcyB3aXRoIGEgdmVyc2lvbiBudW1iZXIgdGhhdCBpcyBkZXNjcmliZWQgYnkgYSBtYWpvciBh bmQgbWlub3IgbnVtYmVyIGV4cHJlc3NlZCBhcyBhbiBhc2NpaSBzdHJpbmcgaW4gdGhlIGZvbGxv d2luZyBmb3JtYXQgLSAnbWFqb3IubWlub3InLiBUaGUgbWFqb3IgYW5kIG1pbm9yIHZlcnNpb25z IGFyZSBudW1iZXJzIHJ1bm5pbmcgZnJvbSAxIHRocm91Z2ggMjU1IChib3RoIGluY2x1c2l2ZSku CisJCQkJCQkgPC90PgorCQkJCQkJIDx0PgorIEEgNnRvcCBub2RlIGltcGxtZW50aW5nIHRoZSBy ZWNvbW1lbmRhdGlvbnMgaW4gdGhpcyBSRkMgd2lsbCByZXNwb25kIHdpdGggYSB2ZXJzaW9uIG51 bWJlciBvZiAnMS4wJyAobWFqb3IgdmVyc2lvbiA9IDEsIG1pbm9yIHZlcnNpb24gPSAwKS4gCisg CQkJCQk8L3Q+CisJCQkgICA8L3NlY3Rpb24+CiAgICAgICAgICAgICA8L3NlY3Rpb24+CiAgICAg ICAgICAgICA8c2VjdGlvbiB0aXRsZT0iTWVzc2FnZSBGb3JtYXRzIj4KICAgICAgICAgICAgICAg IDx0Pgo= --_005_D0876D12C03Crsudhaakciscocom_-- From nobody Tue Nov 11 07:51:11 2014 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88A1F1A8AAB for <6tisch@ietfa.amsl.com>; Tue, 11 Nov 2014 07:51:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f_gOYHQgApa9 for <6tisch@ietfa.amsl.com>; Tue, 11 Nov 2014 07:51:03 -0800 (PST) Received: from hercules.uni.lu (hercules.uni.lu [158.64.76.33]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A9791A8AB0 for <6tisch@ietf.org>; Tue, 11 Nov 2014 07:51:02 -0800 (PST) X-IronPort-AV: E=Sophos; i="5.07,362,1413237600"; d="scan'208,217"; a="52859940" From: Maria Rita PALATTELLA To: Thomas Watteyne , Xavier Vilajosana Thread-Topic: [6tisch] I-D Action: draft-ietf-6tisch-minimal-03.txt Thread-Index: AQHP/HUmAsumb2j5UUyeWYX2bHAKRZxZk4YAgACOxACAABorAIAAAJCAgAALJICAAEIBgIAAOWGAgAABcACAANAVgA== Date: Tue, 11 Nov 2014 15:50:59 +0000 Message-ID: References: <545C898A.8060300@aimvalley.nl> <54608F2A.7090708@aimvalley.nl> 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_F085911F642A6847987ADA23E611780D1D0D3299hoshiunilux_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch/o4EaL1UmDqIUVhdcq1x9ppdzHng Cc: Kees Trommel , "Pascal Thubert \(pthubert\)" , "6tisch@ietf.org" <6tisch@ietf.org> Subject: Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-03.txt X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 15:51:09 -0000 --_000_F085911F642A6847987ADA23E611780D1D0D3299hoshiunilux_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhvbWFzLCBYYXZpLA0KSSBkbyBhZ3JlZSB3ZSBzaG91bGQgYWRkIHRoZSBjb25jZXB0dWFsIGV4 cGxhbmF0aW9uIG9mIHRoZSBkZWZhdWx0IGNoYW5uZWwgaG9wcGluZyBzZXF1ZW5jZSBpbiB0aGUg dHNjaCBkcmFmdCwgZ2l2ZW4gdGhhdCB0aGUgZHJhZnQgaXMgYSBzb3J0IG9mIGd1aWRlbGluZXMg YWJvdXQgaG93IHRzY2ggd29ya3MuDQphbmQgYXQgdGhlIHNhbWUgdGltZSB3ZSBzaG91bGQgIG1l bnRpb24gaXQgaW4gbWluaW1hbCBkcmFmdCBhbmQgcHJvdmlkZSBhbiBleGFtcGxlLg0KTWFyaWEg Uml0YQ0KDQpGcm9tOiA2dGlzY2ggW21haWx0bzo2dGlzY2gtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIFRob21hcyBXYXR0ZXluZQ0KU2VudDogVHVlc2RheSwgTm92ZW1iZXIgMTEsIDIw MTQgNToyNCBBTQ0KVG86IFhhdmllciBWaWxham9zYW5hDQpDYzogS2VlcyBUcm9tbWVsOyBQYXNj YWwgVGh1YmVydCAocHRodWJlcnQpOyA2dGlzY2hAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbNnRp c2NoXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLTZ0aXNjaC1taW5pbWFsLTAzLnR4dA0KDQpYYXZp LCB0aGFua3MgZm9yIHlvdXIgY29tbWVudHMuIFdoYXQgZG8gb3RoZXJzIHRoaW5rPw0KDQpPbiBN b24sIE5vdiAxMCwgMjAxNCBhdCA2OjE4IFBNLCBYYXZpZXIgVmlsYWpvc2FuYSA8eHZpbGFqb3Nh bmFAZWVjcy5iZXJrZWxleS5lZHU8bWFpbHRvOnh2aWxham9zYW5hQGVlY3MuYmVya2VsZXkuZWR1 Pj4gd3JvdGU6DQpIaSwNCg0KVGhvbWFzIGNvbnZpbmNlZCBtZS4gQXMgaXQgaXMgc29tZXRoaW5n IDE1LjQgVFNDSCBzcGVjaWZpYyBpdCBzZWVtcyByZWFzb25hYmxlIHRvIGhhdmUgaXQgYXQgdGhl IHRzY2ggZHJhZnQgYW5kIGluZGljYXRlIHRoZSB1c2Ugb2YgdGhlIGRlZmF1bHQgY2hhbm5lbCBo b3BwaW5nIHNlcXVlbmNlIGluIG1pbmltYWwuIE1pbmltYWwgd29uJ3QgYmUgc2VsZi1jb250YWlu ZWQgYnV0IGl0IGlzIG5vdCBhbHJlZGF5Lg0KDQpyZWdhcmRzLA0KWGF2aQ0KDQoyMDE0LTExLTEx IDE6NTMgR01UKzAxOjAwIFRob21hcyBXYXR0ZXluZSA8d2F0dGV5bmVAZWVjcy5iZXJrZWxleS5l ZHU8bWFpbHRvOndhdHRleW5lQGVlY3MuYmVya2VsZXkuZWR1Pj46DQpQYXNjYWwsDQoNCmRyYWZ0 LWlldGYtNnRpc2NoLW1pbmltYWwgc2hvdWxkIGNvbnRhaW4gdGhhdCBpdCByZXF1aXJlcyB0aGUg ZGVmYXVsdCBjaGFubmVsIGhvcHBpbmcgcGF0dGVybi4gSSB0aGluayB3ZSBhZ3JlZSBvbiB0aGF0 Lg0KDQpUaGUgZGVzY3JpcHRpb24gb2Ygd2hhdCB0aGUgZGVmYXVsdCBjaGFubmVsIGhvcHBpbmcg cGF0dGVybiBpcyAodGhpcyBpcyBqdXN0IGEgZGlzY3Vzc2lvbiBhYm91dCBJRUVFODAyLjE1LjRl LTIwMTIsIG5vdGhpbmcgNlRpU0NIIHNwZWNpZmljKSwgbWlnaHQgZW5kIHVwIGluIDZ0aXNjaC9k cmFmdC1pZXRmLTZ0aXNjaC10c2NoLg0KDQpXaGF0IGRvIG90aGVycyB0aGluaz8NCg0KVGhvbWFz DQoNCg0KDQpPbiBNb24sIE5vdiAxMCwgMjAxNCBhdCAxMDo1NyBBTSwgUGFzY2FsIFRodWJlcnQg KHB0aHViZXJ0KSA8cHRodWJlcnRAY2lzY28uY29tPG1haWx0bzpwdGh1YmVydEBjaXNjby5jb20+ PiB3cm90ZToNCkhpIFRob21hczoNCg0KSSB0aGluazoNCi0gdGhhdCB0aGUgVFNDSCBkcmFmdCBj b3VsZCBkaXNjdXNzIHdoYXQgaXMgc3ViLWRlZmluZWQgaW4gVFNDSCwgaW5kaWNhdGUgdGhhdCB3 ZSB1c2UgdGhlIHJhbmdlIDAtMTUsIHRvIGFkZHJlc3MgS2Vlc+KAmSBwb2ludHMNCi0gYnV0IHRo ZW4sIHRoZSBzZXR0aW5nIHRvIGJlIHVzZWQgaW4gbWluaW1hbCwgYW5kIHBzZXVkbyBjb2RlIGFs b25nIHRoZSBsaW5lcyB5b3UgcHJvZHVjZWQgc2hvdWxkIGdvIGluIG1pbmltYWwgdG8gZW5zdXJl IGludGVyb3AuIFRoZSBwc2V1ZG8gY29kZSB3b3VsZCBiZSBhbiBhcHBlbmRpeC4NCg0KTWFrZXMg c2Vuc2U/DQoNClBhc2NhbA0KDQpGcm9tOiA2dGlzY2ggW21haWx0bzo2dGlzY2gtYm91bmNlc0Bp ZXRmLm9yZzxtYWlsdG86NnRpc2NoLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgVGhv bWFzIFdhdHRleW5lDQpTZW50OiBsdW5kaSAxMCBub3ZlbWJyZSAyMDE0IDEyOjE3DQpUbzogWGF2 aWVyIFZpbGFqb3NhbmENCkNjOiBLZWVzIFRyb21tZWw7IDZ0aXNjaEBpZXRmLm9yZzxtYWlsdG86 NnRpc2NoQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFs2dGlzY2hdIEktRCBBY3Rpb246IGRyYWZ0 LWlldGYtNnRpc2NoLW1pbmltYWwtMDMudHh0DQoNClF1aWNrIHRob3VnaHQ6IGRvZXMgdGhpcyBk aXNjdXNzaW9uIGZpdCBpbiBkcmFmdC1pZXRmLTZ0aXNjaC1taW5pbWFsIG9yIGRyYWZ0LWlldGYt NnRpc2NoLXRzY2g/IEJvdGggbWFrZSBzZW5zZSB0byBtZS4NCg0KT24gTW9uLCBOb3YgMTAsIDIw MTQgYXQgMTA6MTUgQU0sIFhhdmllciBWaWxham9zYW5hIDx4dmlsYWpvc2FuYUBlZWNzLmJlcmtl bGV5LmVkdTxtYWlsdG86eHZpbGFqb3NhbmFAZWVjcy5iZXJrZWxleS5lZHU+PiB3cm90ZToNCkhp LA0KDQpteSA1IGNlbnRzLiBBZnRlciB0aGlua2luZyBhYm91dCBpdCBJIGFtIGluIGZhdm91ciBv ZiBhZGRpbmcgdGhlIGV4YW1wbGUgYXMgdGhlIGRyYWZ0IHdpbGwgYmUgbW9yZSBzZWxmLWNvbnRh aW5lZCBhbmQgd2lsbCBmYWNpbGl0YXRlIHRoZSB1bmRlcnN0YW5kaW5nIG9mIGhvdyBjaC4gaG9w cGluZyBzZXF1ZW5jZSBpcyBjYWx1Y2xhdGVkLiAoYW5hbG9nb3VzbHkgdG8gdGhlIE9GMCBleGFt cGxlKS4NCg0KcmVnYXJkcywNClhhdmkNCg0KMjAxNC0xMS0xMCAxOTo0MSBHTVQrMDE6MDAgVGhv bWFzIFdhdHRleW5lIDx3YXR0ZXluZUBlZWNzLmJlcmtlbGV5LmVkdTxtYWlsdG86d2F0dGV5bmVA ZWVjcy5iZXJrZWxleS5lZHU+PjoNCktlZXMsDQoNCkluIHRoaXMgc2NyaXB0IHlvdSBtYWRlIHRo ZSBhc3N1bXB0aW9uIHRoYXQgdGhlIGhvcHBpbmcgc2VxdWVuY2UgbGVuZ3RoIGlzIGVxdWFsIHRv IHRoZSBudW1iZXIgb2YgY2hhbm5lbHMuIEkgdGhpbmsgdGhpcyBpcyByZWFzb25hYmxlIGFzc3Vt cHRpb24gYnV0IGl0IGlzIG5vdCBkZWZpbmVkIGluIHRoZSBJRUVFODAyLjE1LjRlIHN0YW5kYXJk LCBzbyBpdCB3b3VsZCBiZSBnb29kIGlkZWEgdG8gcHV0IHRoaXMgYXNzdW1wdGlvbiBpbiB0aGUg ZHJhZnQgdG9vLg0KDQpZZXMsIHRoYXQgd2FzIG15IGFzc3VtcHRpb24gaW4gdGhpcyBjb2RlLg0K DQpZb3UgYXJlIHVzaW5nIGNoYW5uZWwgbnVtYmVycyAwIC0gMTUgYW5kIEkgYXNzdW1lIHRoYXQg dGhlc2UgYXJlIHRoZSAxNiAyLjVHSHogY2hhbm5lbHMuIFRoZSBJRUVFODAyLjE1LjRlIHN0YW5k YXJkIGRlZmluZSB0aGVzZSBhcyBjaGFubmVsIG51bWJlcnMgMTEgLSAyNiBvZiBwYWdlIDAuIEl0 IGlzIGZpbmUgZm9yIG1lIHRvIGtlZXAgdGhlIDAgLSAxNSBjaGFubmVsIG51bWJlcmluZyBzY2hl bWUgYnV0IGl0IHdvdWxkIGdvb2QgdG8gbWVudGlvbiB0aGlzIHRvby4gV2hhdCBhYm91dCAoZnV0 dXJlKSBzdXBwb3J0IG9mIG90aGVyIGNoYW5uZWxzIGFuZCBwYWdlcyBkZWZpbmVkIGluIHRoZSBJ RUVFODAyLjE1LjRlIHN0YW5kYXJkPw0KDQpDb3JyZWN0LCB5b3Ugc2hvdWxkIGFkZCAxMSB0byB0 aGUgY2hhbm5lbCBudW1iZXJzIGluIHRoZSBjb2RlIHRvIHVzZSBjaGFubmVsIG51bWJlcnMgMTEt MjYgaW4gSUVFRSBub3RhdGlvbiAoMi40MDVHSHotMi40ODBHSHopLiBBRkFJQ1QsIHRoZXJlIGlz IG5vdGhpbmcgaW4gdGhlIGhvcHBpbmcgc2VxdWVuY2Ugb2YgSUVFRTgwMi4xNS40ZS1UU0NIIHdo aWNoIHByZXZlbnRzIHRoZSB1c2Ugb2YgKGZ1dHVyZSkgc2V0cyBvZiBjaGFubmVscy4NCg0KQGFs bCwgd2hhdCBkbyBvdGhlcnMgdGhpbms/IEFyZSBkZXRhaWxzIGFib3V0IHRoZSBob3BwaW5nIHNl cXVlbmNlIHNvbWV0aGluZyB3ZSBuZWVkIHRvIGFkZCB0byBkcmFmdC1pZXRmLTZ0aXNjaC1taW5p bWFsPw0KDQpUaG9tYXMNCg0KT24gTW9uLCBOb3YgMTAsIDIwMTQgYXQgMTI6MTAgQU0sIEtlZXMg VHJvbW1lbCA8Y3Ryb21tZWxAYWltdmFsbGV5Lm5sPG1haWx0bzpjdHJvbW1lbEBhaW12YWxsZXku bmw+PiB3cm90ZToNClRob21hcywgWGF2aSwNCg0KVGhhbmtzLCBJIGNhbm5vdCBmaW5kIGFueXRo aW5nIGluIHRoaXMgc2NyaXB0IHRoYXQgd291bGQgdmlvbGF0ZSB0aGUgSUVFRTgwMi4xNS40ZSBz dGFuZGFyZC4NCg0KSW4gdGhpcyBzY3JpcHQgeW91IG1hZGUgdGhlIGFzc3VtcHRpb24gdGhhdCB0 aGUgaG9wcGluZyBzZXF1ZW5jZSBsZW5ndGggaXMgZXF1YWwgdG8gdGhlIG51bWJlciBvZiBjaGFu bmVscy4gSSB0aGluayB0aGlzIGlzIHJlYXNvbmFibGUgYXNzdW1wdGlvbiBidXQgaXQgaXMgbm90 IGRlZmluZWQgaW4gdGhlIElFRUU4MDIuMTUuNGUgc3RhbmRhcmQsIHNvIGl0IHdvdWxkIGJlIGdv b2QgaWRlYSB0byBwdXQgdGhpcyBhc3N1bXB0aW9uIGluIHRoZSBkcmFmdCB0b28uDQoNCllvdSBh cmUgdXNpbmcgY2hhbm5lbCBudW1iZXJzIDAgLSAxNSBhbmQgSSBhc3N1bWUgdGhhdCB0aGVzZSBh cmUgdGhlIDE2IDIuNUdIeiBjaGFubmVscy4gVGhlIElFRUU4MDIuMTUuNGUgc3RhbmRhcmQgZGVm aW5lIHRoZXNlIGFzIGNoYW5uZWwgbnVtYmVycyAxMSAtIDI2IG9mIHBhZ2UgMC4gSXQgaXMgZmlu ZSBmb3IgbWUgdG8ga2VlcCB0aGUgMCAtIDE1IGNoYW5uZWwgbnVtYmVyaW5nIHNjaGVtZSBidXQg aXQgd291bGQgZ29vZCB0byBtZW50aW9uIHRoaXMgdG9vLiBXaGF0IGFib3V0IChmdXR1cmUpIHN1 cHBvcnQgb2Ygb3RoZXIgY2hhbm5lbHMgYW5kIHBhZ2VzIGRlZmluZWQgaW4gdGhlIElFRUU4MDIu MTUuNGUgc3RhbmRhcmQ/DQoNCktlZXMuDQoNCg0KT24gMTEvMTAvMTQgMDA6MjksIFRob21hcyBX YXR0ZXluZSB3cm90ZToNCktlZXMsIFhhdmksDQoNCklmIHRoZSBkZWZhdWx0IGhvcHBpbmcgc2Vx dWVuY2UgaXNuJ3QgY2xlYXIgaW4gSUVFRTgwMi4xNS40ZS0yMDEyLCB0aGlzIGlzIGltcG9ydGFu dCBpbmZvcm1hdGlvbiB0byB0aGUgZmVkIGJhY2sgdG8gdGhlIElFRUU4MDIuMTUuNCBURy4gQFBh dEtpbm5leSwgbWF5YmUgeW91IGNhbiBjaGltZSBpbiBvbiB3aGV0aGVyIHRoZSByZWxhdGVkIHRl eHQgd2lsbCBiZSBjaGFuZ2VkIGluIElFRUU4MDIuMTUuNC0yMDE1Pw0KDQpJbiBhbnkgY2FzZSwg bGV0J3MgZGlzYW1iaWd1YXRlIHRoZSBob3BwaW5nIHNlcXVlbmNlIG9uIHRoaXMgdGhyZWFkLiBX ZSBjb3VsZCBhZGQgYW4gZXhhbXBsZSBpbiBkcmFmdC1pZXRmLTZ0aXNjaC1taW5pbWFsLCBhbmQg bWF5YmUgYXNrIElFRUU4MDIuMTUuNCB0byBkbyB0aGUgc2FtZS4NCg0KSSBoYXZlIGNyZWF0ZWQg c29tZSBxdWljayBQeXRob24gY29kZSB3aGljaCBJIGJlbGlldmUgY2FsY3VsYXRlcyB0aGUgZGVm YXVsdCBob3BwaW5nIHNlcXVlbmNlLCBzZWUgaHR0cHM6Ly9naXN0LmdpdGh1Yi5jb20vdHdhdHRl eW5lLzJlMjJlZTNjMWE4MDJiNjg1Njk1Lg0KDQpDb3VsZCBzb21lb25lIChQYXQ/IEpvbmF0aGFu PykgZG91YmxlLWNoZWNrIHRoYXQgaXQgY29tcHV0ZXMgdGhlIHJpZ2h0IHNlcXVlbmNlLiBJJ20g Y29weS1wYXN0aW5nIHRoZSBvdXRwdXQgYmVsb3cuDQoNClRob21hcw0KDQotLS0NCg0KVGhpcyBz Y3JpcHQgY2FsY3VsYXRlcyB0aGUgZGVmYXVsdCBjaGFubmVsIGhvcHBpbmcgc2VxdWVuY2UgZm9y IHRoZQ0KSUVFRTgwMi4xNS40ZS0yMDEyIFRTQ0ggbW9kZS4NCg0KXGF1dGhvciBUaG9tYXMgV2F0 dGV5bmUNClxkYXRlIE5vdmVtYmVyIDIwMTQNClxsaWNlbnNlIGh0dHA6Ly9vcGVuc291cmNlLm9y Zy9saWNlbnNlcy9CU0QtMy1DbGF1c2UNCg0KDQo9PT0gU3RlcCBhLg0KDQpTSFVGRkxFIGlzIGEg bWFjSG9wcGluZ1NlcXVlbmNlTGVuZ3RoLXNpemVkIGFycmF5LiBUaGUgY29udGVudHMgb2YgdGhp cyBhcnJheSBhcg0KZSBlcXVpdmFsZW50IHRvIHRoZSBmaXJzdCBtYWNIb3BwaW5nU2VxdWVuY2VM ZW5ndGggb3V0cHV0cyBvZiBhIDktYml0IGxpbmVhciBmZWUNCmRiYWNrIHNoaWZ0IHJlZ2lzdGVy IChMRlNSKSB3aXRoIHBvbHlub21pYWwgeDkgKyB4NSArIDEgYW5kIGEgc3RhcnRpbmcgc2VlZCBv ZiAyDQo1NS4gRWFjaCBMRlNSIG91dHB1dCBpcyBtb2R1bG8gbWFjSG9wcGluZ1NlcXVlbmNlTGVu Z3RoLCBzbyB0aGF0IGVhY2ggZW50cnkgb2YgUw0KSFVGRkxFIGlzIGJldHdlZW4gMCBhbmQgKG1h Y0hvcHBpbmdTZXF1ZW5jZUxlbmd0aCAtIDEpLCBpbmNsdXNpdmUuDQoNCiAgICAgICAgICAgNSAg ICAgICA5DQogICAxIDEgMSAxIDEgMSAxIDEgMCAoIDI1NT09MHgwZmY9PWIwMTExMTExMTEpDQog ICAxIDEgMSAxIDEgMSAxIDEgMSAoIDUxMT09MHgxZmY9PWIxMTExMTExMTEpIC0tPiAxNQ0KICAg MCAxIDEgMSAxIDEgMSAxIDEgKCA1MTA9PTB4MWZlPT1iMTExMTExMTEwKSAtLT4gMTQNCiAgIDAg MCAxIDEgMSAxIDEgMSAxICggNTA4PT0weDFmYz09YjExMTExMTEwMCkgLS0+IDEyDQogICAwIDAg MCAxIDEgMSAxIDEgMSAoIDUwND09MHgxZjg9PWIxMTExMTEwMDApIC0tPiA4DQogICAwIDAgMCAw IDEgMSAxIDEgMSAoIDQ5Nj09MHgxZjA9PWIxMTExMTAwMDApIC0tPiAwDQogICAwIDAgMCAwIDAg MSAxIDEgMSAoIDQ4MD09MHgxZTA9PWIxMTExMDAwMDApIC0tPiAwDQogICAxIDAgMCAwIDAgMCAx IDEgMSAoIDQ0OT09MHgxYzE9PWIxMTEwMDAwMDEpIC0tPiAxDQogICAxIDEgMCAwIDAgMCAwIDEg MSAoIDM4Nz09MHgxODM9PWIxMTAwMDAwMTEpIC0tPiAzDQogICAxIDEgMSAwIDAgMCAwIDAgMSAo IDI2Mz09MHgxMDc9PWIxMDAwMDAxMTEpIC0tPiA3DQogICAxIDEgMSAxIDAgMCAwIDAgMCAoICAx NT09MHgwMGY9PWIwMDAwMDExMTEpIC0tPiAxNQ0KICAgMCAxIDEgMSAxIDAgMCAwIDAgKCAgMzA9 PTB4MDFlPT1iMDAwMDExMTEwKSAtLT4gMTQNCiAgIDEgMCAxIDEgMSAxIDAgMCAwICggIDYxPT0w eDAzZD09YjAwMDExMTEwMSkgLS0+IDEzDQogICAxIDEgMCAxIDEgMSAxIDAgMCAoIDEyMz09MHgw N2I9PWIwMDExMTEwMTEpIC0tPiAxMQ0KICAgMSAxIDEgMCAxIDEgMSAxIDAgKCAyNDc9PTB4MGY3 PT1iMDExMTEwMTExKSAtLT4gNw0KICAgMSAxIDEgMSAwIDEgMSAxIDEgKCA0OTU9PTB4MWVmPT1i MTExMTAxMTExKSAtLT4gMTUNCiAgIDEgMSAxIDEgMSAwIDEgMSAxICggNDc5PT0weDFkZj09YjEx MTAxMTExMSkgLS0+IDE1DQoNClNIVUZGTEU6ICBbMTUsIDE0LCAxMiwgOCwgMCwgMCwgMSwgMywg NywgMTUsIDE0LCAxMywgMTEsIDcsIDE1LCAxNV0NCg0KPT09IFN0ZXAgYi4NCg0KQ0hBTk5FTFMg aXMgYSBtYWNIb3BwaW5nU2VxdWVuY2VMZW5ndGgtc2l6ZWQgYXJyYXkgdGhhdCBpcyBpbml0aWFs bHkgcG9wdWxhdGVkIHcNCml0aCB0aGUgbW9ub3RvbmljYWxseSBpbmNyZWFzaW5nIGxpc3Qgb2Yg Y2hhbm5lbHMgYXZhaWxhYmxlIHRvIHRoZSBQSFkuDQoNCkNIQU5ORUxTOiBbMCwgMSwgMiwgMywg NCwgNSwgNiwgNywgOCwgOSwgMTAsIDExLCAxMiwgMTMsIDE0LCAxNV0NCg0KPT09IFN0ZXAgYy4N Cg0KQ0hBTk5FTFMgaXMgc2h1ZmZsZWQgYXMgcGVyIEZpZ3VyZSA3YS4gRWxlbWVudHMgbWF5IHdp bmQgdXAgYmVpbmcgc3dhcHBlZCBtdWx0aXANCmxlIHRpbWVzIGluIHRoaXMgcHJvY2Vzcy4NCg0K bWFjSG9wcGluZ1NlcXVlbmNlTGlzdDogWzUsIDYsIDEyLCA3LCAxNSwgNCwgMTQsIDExLCA4LCAw LCAxLCAyLCAxMywgMywgOSwgMTBdDQoNCg0KU2NyaXB0IGVuZGVkIG5vcm1hbGx5LCBwcmVzcyBF bnRlciB0byBjbG9zZS4NCg0KT24gRnJpZGF5LCBOb3ZlbWJlciA3LCAyMDE0LCBYYXZpZXIgVmls YWpvc2FuYSA8eHZpbGFqb3NhbmFAZWVjcy5iZXJrZWxleS5lZHU8bWFpbHRvOnh2aWxham9zYW5h QGVlY3MuYmVya2VsZXkuZWR1Pj4gd3JvdGU6DQpEZWFyIEtlZXMsDQp0aGFua3MgZm9yIHlvdXIg Y29tbWVudHMuDQoNCmFuc3dlcmluZyAxKQ0KSU1ITyB0aGUgZmFjdCB0aGF0IGlmIGRlZmF1bHQg Y2guIGhvcHBpbmcgc2VxdWVuY2UgaXMgYmVpbmcgdXNlZCBtYXkgbm90IGJlIGFkdmVydGlzZWQg aW4gdGhlIEVCIGl0IGlzIG5vdCBjbGVhciBpbiB0aGUgc3RhbmRhcmQuIEFuZCB0aGVyZWZvcmUg SSBvcHRlZCB0byBtYWtlIHRoZSBFQiBleHBsaWNpdCAoZXZlbiBvbmx5IGFuIElEIGFuZCB0aGlz IGJlaW5nIHRoZSBkZWZhdWx0KQ0KUGFnZSAxMSBvZiB0aGUgMTUuNGUgYW1lbmRtZW50IGluZGlj YXRlcyB0aGF0Og0KDQpBbGwgaG9wcGluZyBzZXF1ZW5jZXMgYXJlIHJlZmVycmVkIHRvIGJ5IGFu IElELCBtYWNIb3BwaW5nU2VxdWVuY2VJRCwgd2l0aCBJRCA9IDAgZGVub3RpbmcgdGhlIGRlZmF1 bHQNCnNlcXVlbmNlIGZvciBhIHBhcnRpY3VsYXIgUEhZIChvciBQSFkgY29uZmlndXJhdGlvbiBp ZiB0aGUgUEhZIHN1cHBvcnRzIG1vcmUgdGhhbiBvbmUgY2hhbm5lbCBsaXN0KS4NCg0KdGhlbiBw YWdlIDkyDQpUaGUgZnVsbCBIb3BwaW5nIFNlcXVlbmNlIG1heSBiZSBvbWl0dGVkIHRvIGVuc3Vy ZSB0aGF0IHRoZSBmcmFtZSBkb2VzIG5vdCBleGNlZWQgYU1heFBIWVBhY2tldFNpemUuDQpJbiB0 aGlzIGNhc2Ugb25seSB0aGUgSG9wcGluZyBTZXF1ZW5jZSBJRCBpcyBjYXJyaWVkLCBhbmQgdGhl IGxlbmd0aCBvZiB0aGUgSUUgaXMgMSBvY3RldC4gV2hlbiB0aGUgbGVuZ3RoIGlzDQpub3QgZXF1 YWwgdG8gb25lLCB0aGUgYWRkaXRpb25hbCBmaWVsZHMgYXJlIHByZXNlbnQuIFRoZSBlbGVtZW50 IHZhcmllcyBpbiBsZW5ndGggZGVwZW5kaW5nIHVwb24gdGhlDQpudW1iZXJPZkNoYW5uZWxzIGlu IHVzZSBieSB0aGUgUEhZLiBUaGUgY2hhbm5lbFBhZ2UgYW5kIG51bWJlck9mQ2hhbm5lbHMgYXR0 cmlidXRlcyBjYW4gYmUgdXNlZCB0bw0KZGV0ZXJtaW5lIHRoZSBzaXplIG9mIHRoZSBleHRlbmRl ZEJpdG1hcCwgYW5kIHRoZSBtYWNIb3BwaW5nU2VxdWVuY2VMZW5ndGggY2FuIGJlIHVzZWQgdG8g ZGV0ZXJtaW5lDQp0aGUgc2l6ZSBvZiB0aGUgbWFjSG9wcGluZ1NlcXVlbmNlTGlzdC4NClRoZSBD aGFubmVsIEhvcHBpbmcgSUUgbWF5IGJlIHVzZWQgYnkgYW55IGNoYW5uZWwgaG9wcGluZyBQQU4g dG8gc3luY2hyb25pemUgZGV2aWNlcy4NCg0KTXkgbGFzdCBwb2ludCBoZXJlIGlzIHRoYXQgdGhp cyBtYXkgbWlnaHQgaW5kaWNhdGUgb3B0aW9uYWxpdHkgYnV0IHRoZSBjYXNlIGZvciB0aGUgZGVm YXVsdCBpZCBpcyBub3QgbWVudGlvbmVkIHNvIEkgYW0gbm90IHN1cmUgaXQgY2FuIGJlIGVsaWRl ZCBpZiBkZWZhdWx0IGlkICgwKQ0KDQphbnN3ZXJpbmcgMikgaXQgc2VlbXMgYSBnb29kIHBvaW50 LiBMZXQgdXMgdGhpbmsgYWJvdXQgaXQuDQoNCnJlZ2FyZHMsDQpYYXZpDQoNCjIwMTQtMTEtMDcg OTo1NyBHTVQrMDE6MDAgS2VlcyBUcm9tbWVsIDxjdHJvbW1lbEBhaW12YWxsZXkubmw8bWFpbHRv OmN0cm9tbWVsQGFpbXZhbGxleS5ubD4+Og0KSGksDQoNClRoaXMgZHJhZnQgc3BlY2lmaWVzIHRo YXQgdGhlIGVuaGFuY2VkIGJlYWNvbiBzaG91bGQgaW5jbHVkZSBhIENoYW5uZWwgSG9wcGluZyBJ RSB3aXRoIGEgSG9wcGluZyBTZXF1ZW5jZSBJRCBlcXVhbCB0byAwLiBIb3BwaW5nIFNlcXVlbmNl IElEIDAgaXMgdGhlIGRlZmF1bHQgaG9wcGluZyBzZXF1ZW5jZSBJRC4gU28gdGhlIGFjdHVhbCBo b3BwaW5nIHNlcXVlbmNlIHdpbGwgbm90IGJlIGluY2x1ZGVkIGluIHRoZSBlbmhhbmNlZCBiZWFj b24uDQoNClNlY3Rpb24gNS4xLjFhIG9mIHRoZSBJRUU4MDIuMjUuNGUgc3RhbmRhcmQgZGVmaW5l cyBhbiBhbGdvcml0aG0gdG8gY2FsY3VsYXRlIGEgZGVmYXVsdCBob3BwaW5nIHNlcXVlbmNlIElE Lg0KDQpJIGhhdmUgdGhlIGZvbGxvd2luZyBxdWVzdGlvbnMgcmVnYXJkaW5nIHRoZSBkZWZhdWx0 IGhvcHBpbmcgc2VxdWVuY2U6DQoNCjEuIElzIGl0IHRoZSBpbnRlbnRpb24gdGhhdCBhIG1pbmlt YWwgY29uZmlndXJhdGlvbiB1c2VzIHRoZSBkZWZhdWx0IGhvcHBpbmcgc2VxdWVuY2UgYXMgZGVm aW5lZCBpbiB0aGUgSUVFODAyLjI1LjRlIHN0YW5kYXJkPw0KMi4gSWYgdGhlIGFuc3dlciBvbiAx LiBpcyB5ZXM6ICBUaGUgZGVmaW5pdGlvbiBvZiB0aGUgSUVFODAyLjI1LjRlIGhvcHBpbmcgc2Vx dWVuY2UgKGluIG15IG9waW5pb24pIGlzIG5vdCB1bmFtYmlndW91cywgc28gY2FuIHlvdSBhZGQg dGhlIGFjdHVhbCBkZWZhdWx0IGhvcHBpbmcgc2VxdWVuY2UgdG8gdGhpcyBkcmFmdD8NCg0KUmVn YXJkcywNCg0KS2Vlcy4NCg0KT24gT2N0IDI3LCAyMDE0LCBhdCAxMjoyMCBBTSwgWGF2aWVyIFZp bGFqb3NhbmEgPHh2aWxham9zYW5hIGF0IGVlY3MuYmVya2VsZXkuZWR1PGh0dHA6Ly9lZWNzLmJl cmtlbGV5LmVkdT4+IHdyb3RlOg0KDQpBbGwsIEkganVzdCBwdWJsaXNoZWQgdGhlIG5ldyB2ZXJz aW9uIG9mIG1pbmltYWwuIEl0IGluY2x1ZGVzIGEgc2VjdXJpdHkgc2VjdGlvbiBhcyBkaXNjdXNz ZWQgbGFzdCBjYWxsIGFuZCBzb21lIGNoYW5nZXMgdG8gdGhlIGRlZmF1bHQgdGltaW5nIHRvIGJl IGFjY29yZGluZyB0byAxNS40IHRzY2ggZGVmYXVsdCB2YWx1ZXMuDQoNCnJlZ2FyZHMsDQpYYXZp DQoNCi0tLS0tLS0tLS0gRm9yd2FyZGVkIG1lc3NhZ2UgLS0tLS0tLS0tLQ0KRnJvbTogPGludGVy bmV0LWRyYWZ0cyBhdCBpZXRmLm9yZzxodHRwOi8vaWV0Zi5vcmc+Pg0KRGF0ZTogMjAxNC0xMC0y NyA1OjE3IEdNVCswMTowMA0KU3ViamVjdDogWzZ0aXNjaF0gSS1EIEFjdGlvbjogZHJhZnQtaWV0 Zi02dGlzY2gtbWluaW1hbC0wMy50eHQNClRvOiBpLWQtYW5ub3VuY2UgYXQgaWV0Zi5vcmc8aHR0 cDovL2lldGYub3JnPg0KQ2M6IDZ0aXNjaCBhdCBpZXRmLm9yZzxodHRwOi8vaWV0Zi5vcmc+DQoN Cg0KDQpBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJ bnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQogVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBv ZiB0aGUgSVB2NiBvdmVyIHRoZSBUU0NIIG1vZGUgb2YgSUVFRSA4MDIuMTUuNGUgV29ya2luZyBH cm91cCBvZiB0aGUgSUVURi4NCg0KICAgICAgICBUaXRsZSAgICAgICAgICAgOiBNaW5pbWFsIDZU aVNDSCBDb25maWd1cmF0aW9uDQogICAgICAgIEF1dGhvcnMgICAgICAgICA6IFhhdmllciBWaWxh am9zYW5hDQogICAgICAgICAgICAgICAgICAgICAgICAgIEtyaXMgUGlzdGVyDQogICAgICAgIEZp bGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtNnRpc2NoLW1pbmltYWwtMDMudHh0DQogICAgICAg IFBhZ2VzICAgICAgICAgICA6IDIyDQogICAgICAgIERhdGUgICAgICAgICAgICA6IDIwMTQtMTAt MjYNCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyB0aGUgbWluaW1hbCBz ZXQgb2YgcnVsZXMgdG8gb3BlcmF0ZSBhDQogICBbSUVFRTgwMjE1NGVdIFRpbWVzbG90dGVkIENo YW5uZWwgSG9wcGluZyAoVFNDSCkgbmV0d29yay4gIFRoaXMNCiAgIG1pbmltYWwgbW9kZSBvZiBv cGVyYXRpb24gY2FuIGJlIHVzZWQgZHVyaW5nIG5ldHdvcmsgYm9vdHN0cmFwLCBhcyBhDQogICBm YWxsLWJhY2sgbW9kZSBvZiBvcGVyYXRpb24gd2hlbiBubyBkeW5hbWljIHNjaGVkdWxpbmcgc29s dXRpb24gaXMNCiAgIGF2YWlsYWJsZSBvciBmdW5jdGlvbmluZywgb3IgZHVyaW5nIGVhcmx5IGlu dGVyb3BlcmFiaWxpdHkgdGVzdGluZw0KICAgYW5kIGRldmVsb3BtZW50Lg0KDQoNClRoZSBJRVRG IGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi02dGlzY2gtbWluaW1hbC8NCg0KVGhlcmUn cyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6DQpodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLTZ0aXNjaC1taW5pbWFsLTAzDQoNCkEgZGlmZiBmcm9tIHRo ZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCmh0dHA6Ly93d3cuaWV0Zi5vcmcv cmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtNnRpc2NoLW1pbmltYWwtMDMNCg0KDQpQbGVhc2Ugbm90 ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBz dWJtaXNzaW9uDQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxh YmxlIGF0IHRvb2xzLmlldGYub3JnPGh0dHA6Ly90b29scy5pZXRmLm9yZz4uDQoNCkludGVybmV0 LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCmZ0cDovL2Z0 cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo2dGlzY2ggbWFpbGluZyBsaXN0DQo2dGlzY2ggYXQgaWV0 Zi5vcmc8aHR0cDovL2lldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby82dGlzY2gNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCjZ0aXNjaCBtYWlsaW5nIGxpc3QNCjZ0aXNjaCBhdCBpZXRmLm9yZzxodHRwOi8vaWV0 Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvLzZ0aXNjaA0KDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo2dGlzY2gg bWFpbGluZyBsaXN0DQo2dGlzY2hAaWV0Zi5vcmc8bWFpbHRvOjZ0aXNjaEBpZXRmLm9yZz4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vNnRpc2NoDQoNCg0KDQoNCg0KDQoN Cg0K --_000_F085911F642A6847987ADA23E611780D1D0D3299hoshiunilux_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29u IFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJC YWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFu LkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5UaG9tYXMsIFhhdmksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgZG8gYWdy ZWUgd2Ugc2hvdWxkIGFkZCB0aGUgY29uY2VwdHVhbCBleHBsYW5hdGlvbiBvZiB0aGUgZGVmYXVs dCBjaGFubmVsIGhvcHBpbmcgc2VxdWVuY2UgaW4gdGhlIHRzY2ggZHJhZnQsIGdpdmVuIHRoYXQg dGhlIGRyYWZ0IGlzIGEgc29ydCBvZiBndWlkZWxpbmVzDQogYWJvdXQgaG93IHRzY2ggd29ya3Mu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPmFuZCBhdCB0aGUgc2FtZSB0aW1lIHdlIHNo b3VsZCAmbmJzcDttZW50aW9uIGl0IGluIG1pbmltYWwgZHJhZnQgYW5kIHByb3ZpZGUgYW4gZXhh bXBsZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TWFyaWEgUml0YTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gNnRpc2NoIFttYWlsdG86NnRpc2NoLWJv dW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlRob21hcyBXYXR0ZXluZTxicj4N CjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBOb3ZlbWJlciAxMSwgMjAxNCA1OjI0IEFNPGJyPg0KPGI+ VG86PC9iPiBYYXZpZXIgVmlsYWpvc2FuYTxicj4NCjxiPkNjOjwvYj4gS2VlcyBUcm9tbWVsOyBQ YXNjYWwgVGh1YmVydCAocHRodWJlcnQpOyA2dGlzY2hAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUmU6IFs2dGlzY2hdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtNnRpc2NoLW1pbmltYWwt MDMudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WGF2aSwgdGhhbmtz IGZvciB5b3VyIGNvbW1lbnRzLiBXaGF0IGRvIG90aGVycyB0aGluaz88bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwgTm92IDEwLCAyMDE0IGF0IDY6 MTggUE0sIFhhdmllciBWaWxham9zYW5hICZsdDs8YSBocmVmPSJtYWlsdG86eHZpbGFqb3NhbmFA ZWVjcy5iZXJrZWxleS5lZHUiIHRhcmdldD0iX2JsYW5rIj54dmlsYWpvc2FuYUBlZWNzLmJlcmtl bGV5LmVkdTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5IaSwmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhvbWFzIGNvbnZpbmNlZCBtZS4gQXMgaXQgaXMgc29t ZXRoaW5nIDE1LjQgVFNDSCBzcGVjaWZpYyBpdCBzZWVtcyByZWFzb25hYmxlIHRvIGhhdmUgaXQg YXQgdGhlIHRzY2ggZHJhZnQgYW5kIGluZGljYXRlIHRoZSB1c2Ugb2YgdGhlIGRlZmF1bHQgY2hh bm5lbCBob3BwaW5nIHNlcXVlbmNlIGluIG1pbmltYWwuIE1pbmltYWwgd29uJ3QgYmUgc2VsZi1j b250YWluZWQgYnV0IGl0IGlzIG5vdCBhbHJlZGF5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5yZWdhcmRzLDxicj4NClhhdmk8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4yMDE0LTExLTExIDE6NTMgR01UJiM0MzswMTowMCBUaG9tYXMgV2F0dGV5bmUgJmx0OzxhIGhy ZWY9Im1haWx0bzp3YXR0ZXluZUBlZWNzLmJlcmtlbGV5LmVkdSIgdGFyZ2V0PSJfYmxhbmsiPndh dHRleW5lQGVlY3MuYmVya2VsZXkuZWR1PC9hPiZndDs6PG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+UGFzY2FsLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+ZHJhZnQtaWV0Zi02dGlzY2gtbWluaW1hbCBzaG91bGQgY29udGFp biB0aGF0IGl0IHJlcXVpcmVzIHRoZSBkZWZhdWx0IGNoYW5uZWwgaG9wcGluZyBwYXR0ZXJuLiBJ IHRoaW5rIHdlIGFncmVlIG9uIHRoYXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBkZXNjcmlwdGlvbiBvZiB3aGF0IHRoZSBkZWZhdWx0 IGNoYW5uZWwgaG9wcGluZyBwYXR0ZXJuIGlzICh0aGlzIGlzIGp1c3QgYSBkaXNjdXNzaW9uIGFi b3V0IElFRUU4MDIuMTUuNGUtMjAxMiwgbm90aGluZyA2VGlTQ0ggc3BlY2lmaWMpLCBtaWdodCBl bmQgdXAgaW4mbmJzcDs2dGlzY2gvZHJhZnQtaWV0Zi02dGlzY2gtdHNjaC48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hhdCBkbyBvdGhlcnMg dGhpbms/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OiM4ODg4ODgiPlRob21hczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1v biwgTm92IDEwLCAyMDE0IGF0IDEwOjU3IEFNLCBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpICZs dDs8YSBocmVmPSJtYWlsdG86cHRodWJlcnRAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+cHRo dWJlcnRAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkhpIFRob21hczo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHRoaW5rOg0KPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LSB0aGF0IHRoZSBUU0NIIGRyYWZ0IGNvdWxkIGRpc2N1 c3Mgd2hhdCBpcyBzdWItZGVmaW5lZCBpbiBUU0NILCBpbmRpY2F0ZSB0aGF0IHdlIHVzZSB0aGUg cmFuZ2UgMC0xNSwNCiB0byBhZGRyZXNzIEtlZXPigJkgcG9pbnRzPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+LSBidXQgdGhlbiwgdGhlIHNldHRpbmcgdG8gYmUgdXNlZCBpbiBtaW5p bWFsLCBhbmQgcHNldWRvIGNvZGUgYWxvbmcgdGhlIGxpbmVzIHlvdSBwcm9kdWNlZCBzaG91bGQN CiBnbyBpbiBtaW5pbWFsIHRvIGVuc3VyZSBpbnRlcm9wLiBUaGUgcHNldWRvIGNvZGUgd291bGQg YmUgYW4gYXBwZW5kaXguPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TWFrZXMgc2Vuc2U/PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ UGFzY2FsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1 ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAw aW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiA2 dGlzY2ggW21haWx0bzo8YSBocmVmPSJtYWlsdG86NnRpc2NoLWJvdW5jZXNAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj42dGlzY2gtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYg T2YgPC9iPlRob21hcyBXYXR0ZXluZTxicj4NCjxiPlNlbnQ6PC9iPiBsdW5kaSAxMCBub3ZlbWJy ZSAyMDE0IDEyOjE3PGJyPg0KPGI+VG86PC9iPiBYYXZpZXIgVmlsYWpvc2FuYTxicj4NCjxiPkNj OjwvYj4gS2VlcyBUcm9tbWVsOyA8YSBocmVmPSJtYWlsdG86NnRpc2NoQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+NnRpc2NoQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog WzZ0aXNjaF0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi02dGlzY2gtbWluaW1hbC0wMy50eHQ8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+UXVpY2sgdGhvdWdodDogZG9lcyB0aGlzIGRpc2N1c3Npb24gZml0IGluJm5i c3A7ZHJhZnQtaWV0Zi02dGlzY2gtbWluaW1hbCBvciBkcmFmdC1pZXRmLTZ0aXNjaC10c2NoPyBC b3RoIG1ha2Ugc2Vuc2UgdG8gbWUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+T24gTW9uLCBOb3YgMTAsIDIwMTQgYXQgMTA6MTUgQU0sIFhhdmllciBW aWxham9zYW5hICZsdDs8YSBocmVmPSJtYWlsdG86eHZpbGFqb3NhbmFAZWVjcy5iZXJrZWxleS5l ZHUiIHRhcmdldD0iX2JsYW5rIj54dmlsYWpvc2FuYUBlZWNzLmJlcmtlbGV5LmVkdTwvYT4mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SGks Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ bXkgNSBjZW50cy4gQWZ0ZXIgdGhpbmtpbmcgYWJvdXQgaXQgSSBhbSBpbiBmYXZvdXIgb2YgYWRk aW5nIHRoZSBleGFtcGxlIGFzIHRoZSBkcmFmdCB3aWxsIGJlIG1vcmUgc2VsZi1jb250YWluZWQg YW5kIHdpbGwgZmFjaWxpdGF0ZSB0aGUgdW5kZXJzdGFuZGluZyBvZiBob3cgY2guIGhvcHBpbmcg c2VxdWVuY2UNCiBpcyBjYWx1Y2xhdGVkLiAoYW5hbG9nb3VzbHkgdG8gdGhlIE9GMCBleGFtcGxl KS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPnJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPlhhdmk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+MjAxNC0xMS0xMCAxOTo0MSBHTVQm IzQzOzAxOjAwIFRob21hcyBXYXR0ZXluZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOndhdHRleW5lQGVl Y3MuYmVya2VsZXkuZWR1IiB0YXJnZXQ9Il9ibGFuayI+d2F0dGV5bmVAZWVjcy5iZXJrZWxleS5l ZHU8L2E+Jmd0Ozo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PktlZXMsPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkluIHRoaXMgc2NyaXB0 IHlvdSBtYWRlIHRoZSBhc3N1bXB0aW9uIHRoYXQgdGhlIGhvcHBpbmcgc2VxdWVuY2UgbGVuZ3Ro IGlzIGVxdWFsIHRvIHRoZSBudW1iZXIgb2YgY2hhbm5lbHMuIEkgdGhpbmsgdGhpcyBpcyByZWFz b25hYmxlIGFzc3VtcHRpb24gYnV0IGl0IGlzIG5vdCBkZWZpbmVkIGluIHRoZSBJRUVFODAyLjE1 LjRlDQogc3RhbmRhcmQsIHNvIGl0IHdvdWxkIGJlIGdvb2QgaWRlYSB0byBwdXQgdGhpcyBhc3N1 bXB0aW9uIGluIHRoZSBkcmFmdCB0b28uPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+WWVzLCB0aGF0IHdhcyBteSBhc3N1bXB0 aW9uIGluIHRoaXMgY29kZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5Zb3UgYXJlIHVzaW5nIGNoYW5uZWwgbnVtYmVycyAwIC0gMTUgYW5kIEkgYXNzdW1lIHRo YXQgdGhlc2UgYXJlIHRoZSAxNiAyLjVHSHogY2hhbm5lbHMuIFRoZSBJRUVFODAyLjE1LjRlIHN0 YW5kYXJkIGRlZmluZSB0aGVzZSBhcyBjaGFubmVsIG51bWJlcnMgMTEgLSAyNiBvZiBwYWdlIDAu IEl0IGlzIGZpbmUNCiBmb3IgbWUgdG8ga2VlcCB0aGUgMCAtIDE1IGNoYW5uZWwgbnVtYmVyaW5n IHNjaGVtZSBidXQgaXQgd291bGQgZ29vZCB0byBtZW50aW9uIHRoaXMgdG9vLiBXaGF0IGFib3V0 IChmdXR1cmUpIHN1cHBvcnQgb2Ygb3RoZXIgY2hhbm5lbHMgYW5kIHBhZ2VzIGRlZmluZWQgaW4g dGhlIElFRUU4MDIuMTUuNGUgc3RhbmRhcmQ/PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Q29ycmVjdCwgeW91IHNob3VsZCBh ZGQgMTEgdG8gdGhlIGNoYW5uZWwgbnVtYmVycyBpbiB0aGUgY29kZSB0byB1c2UgY2hhbm5lbCBu dW1iZXJzIDExLTI2IGluIElFRUUgbm90YXRpb24gKDIuNDA1R0h6LTIuNDgwR0h6KS4gQUZBSUNU LCB0aGVyZSBpcyBub3RoaW5nIGluIHRoZSBob3BwaW5nIHNlcXVlbmNlDQogb2YgSUVFRTgwMi4x NS40ZS1UU0NIIHdoaWNoIHByZXZlbnRzIHRoZSB1c2Ugb2YgKGZ1dHVyZSkgc2V0cyBvZiBjaGFu bmVscy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxiPkBhbGw8L2I+LCB3aGF0IGRvIG90aGVycyB0aGluaz8gQXJlIGRldGFpbHMgYWJv dXQgdGhlIGhvcHBpbmcgc2VxdWVuY2Ugc29tZXRoaW5nIHdlIG5lZWQgdG8gYWRkIHRvIGRyYWZ0 LWlldGYtNnRpc2NoLW1pbmltYWw/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij5UaG9tYXM8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5PbiBNb24sIE5vdiAxMCwgMjAxNCBhdCAxMjoxMCBBTSwgS2VlcyBUcm9tbWVsICZs dDs8YSBocmVmPSJtYWlsdG86Y3Ryb21tZWxAYWltdmFsbGV5Lm5sIiB0YXJnZXQ9Il9ibGFuayI+ Y3Ryb21tZWxAYWltdmFsbGV5Lm5sPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhvbWFzLCBYYXZpLDxicj4NCjxicj4N ClRoYW5rcywgSSBjYW5ub3QgZmluZCBhbnl0aGluZyBpbiB0aGlzIHNjcmlwdCB0aGF0IHdvdWxk IHZpb2xhdGUgdGhlIElFRUU4MDIuMTUuNGUgc3RhbmRhcmQuPGJyPg0KPGJyPg0KSW4gdGhpcyBz Y3JpcHQgeW91IG1hZGUgdGhlIGFzc3VtcHRpb24gdGhhdCB0aGUgaG9wcGluZyBzZXF1ZW5jZSBs ZW5ndGggaXMgZXF1YWwgdG8gdGhlIG51bWJlciBvZiBjaGFubmVscy4gSSB0aGluayB0aGlzIGlz IHJlYXNvbmFibGUgYXNzdW1wdGlvbiBidXQgaXQgaXMgbm90IGRlZmluZWQgaW4gdGhlIElFRUU4 MDIuMTUuNGUgc3RhbmRhcmQsIHNvIGl0IHdvdWxkIGJlIGdvb2QgaWRlYSB0byBwdXQgdGhpcyBh c3N1bXB0aW9uIGluIHRoZSBkcmFmdA0KIHRvby48YnI+DQo8YnI+DQpZb3UgYXJlIHVzaW5nIGNo YW5uZWwgbnVtYmVycyAwIC0gMTUgYW5kIEkgYXNzdW1lIHRoYXQgdGhlc2UgYXJlIHRoZSAxNiAy LjVHSHogY2hhbm5lbHMuIFRoZSBJRUVFODAyLjE1LjRlIHN0YW5kYXJkIGRlZmluZSB0aGVzZSBh cyBjaGFubmVsIG51bWJlcnMgMTEgLSAyNiBvZiBwYWdlIDAuIEl0IGlzIGZpbmUgZm9yIG1lIHRv IGtlZXAgdGhlIDAgLSAxNSBjaGFubmVsIG51bWJlcmluZyBzY2hlbWUgYnV0IGl0IHdvdWxkIGdv b2QgdG8gbWVudGlvbg0KIHRoaXMgdG9vLiBXaGF0IGFib3V0IChmdXR1cmUpIHN1cHBvcnQgb2Yg b3RoZXIgY2hhbm5lbHMgYW5kIHBhZ2VzIGRlZmluZWQgaW4gdGhlIElFRUU4MDIuMTUuNGUgc3Rh bmRhcmQ/PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxicj4NCjxicj4NCktlZXMuPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxi cj4NCjxicj4NCk9uIDExLzEwLzE0IDAwOjI5LCBUaG9tYXMgV2F0dGV5bmUgd3JvdGU6PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+S2VlcywgWGF2aSwNCjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPklmIHRoZSBkZWZhdWx0IGhvcHBpbmcgc2Vx dWVuY2UgaXNuJ3QgY2xlYXIgaW4gSUVFRTgwMi4xNS40ZS0yMDEyLCB0aGlzIGlzIGltcG9ydGFu dCBpbmZvcm1hdGlvbiB0byB0aGUgZmVkIGJhY2sgdG8gdGhlIElFRUU4MDIuMTUuNCBURy4NCjxi PkBQYXRLaW5uZXk8L2I+LCBtYXliZSB5b3UgY2FuIGNoaW1lIGluIG9uIHdoZXRoZXIgdGhlIHJl bGF0ZWQgdGV4dCB3aWxsIGJlIGNoYW5nZWQgaW4gSUVFRTgwMi4xNS40LTIwMTU/PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JbiBhbnkg Y2FzZSwgbGV0J3MgZGlzYW1iaWd1YXRlIHRoZSBob3BwaW5nIHNlcXVlbmNlIG9uIHRoaXMgdGhy ZWFkLiBXZSBjb3VsZCBhZGQgYW4gZXhhbXBsZSBpbiBkcmFmdC1pZXRmLTZ0aXNjaC1taW5pbWFs LCBhbmQgbWF5YmUgYXNrIElFRUU4MDIuMTUuNCB0byBkbyB0aGUgc2FtZS48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgaGF2ZSBjcmVh dGVkIHNvbWUgcXVpY2sgUHl0aG9uIGNvZGUgd2hpY2ggSSBiZWxpZXZlIGNhbGN1bGF0ZXMgdGhl IGRlZmF1bHQgaG9wcGluZyBzZXF1ZW5jZSwgc2VlDQo8YSBocmVmPSJodHRwczovL2dpc3QuZ2l0 aHViLmNvbS90d2F0dGV5bmUvMmUyMmVlM2MxYTgwMmI2ODU2OTUiIHRhcmdldD0iX2JsYW5rIj4N Cmh0dHBzOi8vZ2lzdC5naXRodWIuY29tL3R3YXR0ZXluZS8yZTIyZWUzYzFhODAyYjY4NTY5NTwv YT4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5Db3VsZCBzb21lb25lICg8Yj5QYXQ8L2I+Pw0KPGI+Sm9uYXRoYW48L2I+PykgZG91Ymxl LWNoZWNrIHRoYXQgaXQgY29tcHV0ZXMgdGhlIHJpZ2h0IDxzcGFuIHN0eWxlPSJjb2xvcjpibHVl O2JhY2tncm91bmQ6eWVsbG93Ij4NCnNlcXVlbmNlPC9zcGFuPi4gSSdtIGNvcHktcGFzdGluZyB0 aGUgb3V0cHV0IGJlbG93LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+VGhvbWFzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4tLS08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlRoaXMgc2NyaXB0IGNhbGN1bGF0ZXMgdGhl IGRlZmF1bHQgY2hhbm5lbCBob3BwaW5nIHNlcXVlbmNlIGZvciB0aGU8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SUVFRTgwMi4xNS40ZS0yMDEy IFRTQ0ggbW9kZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPlxhdXRob3IgVGhvbWFzIFdhdHRleW5lPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlxkYXRlIE5vdmVtYmVyIDIwMTQ8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+XGxpY2Vu c2UNCjxhIGhyZWY9Imh0dHA6Ly9vcGVuc291cmNlLm9yZy9saWNlbnNlcy9CU0QtMy1DbGF1c2Ui IHRhcmdldD0iX2JsYW5rIj5odHRwOi8vb3BlbnNvdXJjZS5vcmcvbGljZW5zZXMvQlNELTMtQ2xh dXNlPC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPj09PSBTdGVwIGEuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5TSFVGRkxFIGlzIGEgbWFjSG9wcGluZ1NlcXVlbmNl TGVuZ3RoLXNpemVkIGFycmF5LiBUaGUgY29udGVudHMgb2YgdGhpcyBhcnJheSBhcjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5lIGVxdWl2YWxl bnQgdG8gdGhlIGZpcnN0IG1hY0hvcHBpbmdTZXF1ZW5jZUxlbmd0aCBvdXRwdXRzIG9mIGEgOS1i aXQgbGluZWFyIGZlZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij5kYmFjayBzaGlmdCByZWdpc3RlciAoTEZTUikgd2l0aCBwb2x5bm9taWFsIHg5 ICYjNDM7IHg1ICYjNDM7IDEgYW5kIGEgc3RhcnRpbmcgc2VlZCBvZiAyPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjU1LiBFYWNoIExGU1Igb3V0 cHV0IGlzIG1vZHVsbyBtYWNIb3BwaW5nU2VxdWVuY2VMZW5ndGgsIHNvIHRoYXQgZWFjaCBlbnRy eSBvZiBTPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPkhVRkZMRSBpcyBiZXR3ZWVuIDAgYW5kIChtYWNIb3BwaW5nU2VxdWVuY2VMZW5ndGggLSAx KSwgaW5jbHVzaXZlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs1 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7ICZuYnNwOzEgMSAxIDEgMSAxIDEgMSAwICggMjU1 PT0weDBmZj09YjAxMTExMTExMSk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7ICZuYnNwOzEgMSAxIDEgMSAxIDEgMSAxICggNTExPT0w eDFmZj09YjExMTExMTExMSkgLS0mZ3Q7IDE1PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyAmbmJzcDswIDEgMSAxIDEgMSAxIDEgMSAo IDUxMD09MHgxZmU9PWIxMTExMTExMTApIC0tJmd0OyAxNDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgJm5ic3A7MCAwIDEgMSAxIDEg MSAxIDEgKCA1MDg9PTB4MWZjPT1iMTExMTExMTAwKSAtLSZndDsgMTI8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7ICZuYnNwOzAgMCAw IDEgMSAxIDEgMSAxICggNTA0PT0weDFmOD09YjExMTExMTAwMCkgLS0mZ3Q7IDg8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7ICZuYnNw OzAgMCAwIDAgMSAxIDEgMSAxICggNDk2PT0weDFmMD09YjExMTExMDAwMCkgLS0mZ3Q7IDA8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7 ICZuYnNwOzAgMCAwIDAgMCAxIDEgMSAxICggNDgwPT0weDFlMD09YjExMTEwMDAwMCkgLS0mZ3Q7 IDA8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ Jm5ic3A7ICZuYnNwOzEgMCAwIDAgMCAwIDEgMSAxICggNDQ5PT0weDFjMT09YjExMTAwMDAwMSkg LS0mZ3Q7IDE8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Jm5ic3A7ICZuYnNwOzEgMSAwIDAgMCAwIDAgMSAxICggMzg3PT0weDE4Mz09YjExMDAw MDAxMSkgLS0mZ3Q7IDM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+Jm5ic3A7ICZuYnNwOzEgMSAxIDAgMCAwIDAgMCAxICggMjYzPT0weDEwNz09 YjEwMDAwMDExMSkgLS0mZ3Q7IDc8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7ICZuYnNwOzEgMSAxIDEgMCAwIDAgMCAwICggJm5ic3A7 MTU9PTB4MDBmPT1iMDAwMDAxMTExKSAtLSZndDsgMTU8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7ICZuYnNwOzAgMSAxIDEgMSAwIDAg MCAwICggJm5ic3A7MzA9PTB4MDFlPT1iMDAwMDExMTEwKSAtLSZndDsgMTQ8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7ICZuYnNwOzEg MCAxIDEgMSAxIDAgMCAwICggJm5ic3A7NjE9PTB4MDNkPT1iMDAwMTExMTAxKSAtLSZndDsgMTM8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i c3A7ICZuYnNwOzEgMSAwIDEgMSAxIDEgMCAwICggMTIzPT0weDA3Yj09YjAwMTExMTAxMSkgLS0m Z3Q7IDExPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPiZuYnNwOyAmbmJzcDsxIDEgMSAwIDEgMSAxIDEgMCAoIDI0Nz09MHgwZjc9PWIwMTExMTAx MTEpIC0tJmd0OyA3PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiZuYnNwOyAmbmJzcDsxIDEgMSAxIDAgMSAxIDEgMSAoIDQ5NT09MHgxZWY9PWIx MTExMDExMTEpIC0tJmd0OyAxNTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgJm5ic3A7MSAxIDEgMSAxIDAgMSAxIDEgKCA0Nzk9PTB4 MWRmPT1iMTExMDExMTExKSAtLSZndDsgMTU8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlNIVUZGTEU6ICZuYnNwO1sxNSwgMTQsIDEyLCA4 LCAwLCAwLCAxLCAzLCA3LCAxNSwgMTQsIDEzLCAxMSwgNywgMTUsIDE1XTwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PT09IFN0ZXAgYi48 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PkNIQU5ORUxTIGlzIGEgbWFjSG9wcGluZ1NlcXVlbmNlTGVuZ3RoLXNpemVkIGFycmF5IHRoYXQg aXMgaW5pdGlhbGx5IHBvcHVsYXRlZCB3PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPml0aCB0aGUgbW9ub3RvbmljYWxseSBpbmNyZWFzaW5nIGxp c3Qgb2YgY2hhbm5lbHMgYXZhaWxhYmxlIHRvIHRoZSBQSFkuPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5DSEFOTkVMUzogWzAsIDEsIDIs IDMsIDQsIDUsIDYsIDcsIDgsIDksIDEwLCAxMSwgMTIsIDEzLCAxNCwgMTVdPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij49PT0gU3RlcCBj Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Q0hBTk5FTFMgaXMgc2h1ZmZsZWQgYXMgcGVyIEZpZ3VyZSA3YS4gRWxlbWVudHMgbWF5IHdp bmQgdXAgYmVpbmcgc3dhcHBlZCBtdWx0aXA8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+bGUgdGltZXMgaW4gdGhpcyBwcm9jZXNzLjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+bWFjSG9w cGluZ1NlcXVlbmNlTGlzdDoNCjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpibHVlO2JhY2tncm91bmQ6 eWVsbG93Ij5bNSwgNiwgMTIsIDcsIDE1LCA0LCAxNCwgMTEsIDgsIDAsIDEsIDIsIDEzLCAzLCA5 LCAxMF08L3NwYW4+PC9iPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPlNjcmlwdCBlbmRlZCBub3JtYWxseSwgcHJlc3MgRW50ZXIg dG8gY2xvc2UuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxicj4NCk9uIEZyaWRheSwgTm92ZW1iZXIgNywgMjAxNCwg WGF2aWVyIFZpbGFqb3NhbmEgJmx0OzxhIGhyZWY9Im1haWx0bzp4dmlsYWpvc2FuYUBlZWNzLmJl cmtlbGV5LmVkdSIgdGFyZ2V0PSJfYmxhbmsiPnh2aWxham9zYW5hQGVlY3MuYmVya2VsZXkuZWR1 PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5EZWFyIEtlZXMsDQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPnRoYW5rcyBmb3IgeW91ciBjb21tZW50cy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPmFuc3dlcmluZyAxKTxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ SU1ITyB0aGUgZmFjdCB0aGF0IGlmIGRlZmF1bHQgY2guIGhvcHBpbmcgc2VxdWVuY2UgaXMgYmVp bmcgdXNlZA0KPGI+bWF5IG5vdCBiZTwvYj4gYWR2ZXJ0aXNlZCBpbiB0aGUgRUIgaXQgaXMgbm90 IGNsZWFyIGluIHRoZSBzdGFuZGFyZC4gQW5kIHRoZXJlZm9yZSBJIG9wdGVkIHRvIG1ha2UgdGhl IEVCIGV4cGxpY2l0IChldmVuIG9ubHkgYW4gSUQgYW5kIHRoaXMgYmVpbmcgdGhlIGRlZmF1bHQp PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlBh Z2UgMTEgb2YgdGhlIDE1LjRlIGFtZW5kbWVudCBpbmRpY2F0ZXMgdGhhdDo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxpPkFsbCBob3Bw aW5nIHNlcXVlbmNlcyBhcmUgcmVmZXJyZWQgdG8gYnkgYW4gSUQsIG1hY0hvcHBpbmdTZXF1ZW5j ZUlELCB3aXRoIElEID0gMCBkZW5vdGluZyB0aGUgZGVmYXVsdDwvaT48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGk+c2VxdWVuY2UgZm9yIGEg cGFydGljdWxhciBQSFkgKG9yIFBIWSBjb25maWd1cmF0aW9uIGlmIHRoZSBQSFkgc3VwcG9ydHMg bW9yZSB0aGFuIG9uZSBjaGFubmVsIGxpc3QpLjwvaT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPnRoZW4gcGFnZSA5MjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48aT5UaGUgZnVsbCBI b3BwaW5nIFNlcXVlbmNlIG1heSBiZSBvbWl0dGVkIHRvIGVuc3VyZSB0aGF0IHRoZSBmcmFtZSBk b2VzIG5vdCBleGNlZWQgYU1heFBIWVBhY2tldFNpemUuPC9pPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48aT5JbiB0aGlzIGNhc2Ugb25seSB0 aGUgSG9wcGluZyBTZXF1ZW5jZSBJRCBpcyBjYXJyaWVkLCBhbmQgdGhlIGxlbmd0aCBvZiB0aGUg SUUgaXMgMSBvY3RldC4gV2hlbiB0aGUgbGVuZ3RoIGlzPC9pPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48aT5ub3QgZXF1YWwgdG8gb25lLCB0 aGUgYWRkaXRpb25hbCBmaWVsZHMgYXJlIHByZXNlbnQuIFRoZSBlbGVtZW50IHZhcmllcyBpbiBs ZW5ndGggZGVwZW5kaW5nIHVwb24gdGhlPC9pPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48aT5udW1iZXJPZkNoYW5uZWxzIGluIHVzZSBieSB0 aGUgUEhZLiBUaGUgY2hhbm5lbFBhZ2UgYW5kIG51bWJlck9mQ2hhbm5lbHMgYXR0cmlidXRlcyBj YW4gYmUgdXNlZCB0bzwvaT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PGk+ZGV0ZXJtaW5lIHRoZSBzaXplIG9mIHRoZSBleHRlbmRlZEJpdG1h cCwgYW5kIHRoZSBtYWNIb3BwaW5nU2VxdWVuY2VMZW5ndGggY2FuIGJlIHVzZWQgdG8gZGV0ZXJt aW5lPC9pPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48aT50aGUgc2l6ZSBvZiB0aGUgbWFjSG9wcGluZ1NlcXVlbmNlTGlzdC48L2k+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxpPlRoZSBD aGFubmVsIEhvcHBpbmcgSUUNCjxiPm1heTwvYj4gYmUgdXNlZCBieSBhbnkgY2hhbm5lbCBob3Bw aW5nIFBBTiB0byBzeW5jaHJvbml6ZSBkZXZpY2VzLjwvaT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+TXkgbGFzdCBwb2lu dCBoZXJlIGlzIHRoYXQgdGhpcw0KPGI+bWF5PC9iPiZuYnNwO21pZ2h0IGluZGljYXRlIG9wdGlv bmFsaXR5IGJ1dCB0aGUgY2FzZSBmb3IgdGhlIGRlZmF1bHQgaWQgaXMgbm90IG1lbnRpb25lZCBz byBJIGFtIG5vdCBzdXJlIGl0IGNhbiBiZSBlbGlkZWQgaWYgZGVmYXVsdCBpZCAoMCk8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPmFuc3dl cmluZyAyKSBpdCBzZWVtcyBhIGdvb2QgcG9pbnQuIExldCB1cyB0aGluayBhYm91dCBpdC48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPnJl Z2FyZHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPlhhdmk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjIwMTQtMTEtMDcgOTo1NyBHTVQmIzQzOzAxOjAwIEtlZXMgVHJvbW1lbCAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmN0cm9tbWVsQGFpbXZhbGxleS5ubCIgdGFyZ2V0PSJfYmxhbmsiPmN0 cm9tbWVsQGFpbXZhbGxleS5ubDwvYT4mZ3Q7OjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij5IaSw8YnI+DQo8YnI+DQpUaGlzIGRyYWZ0IHNwZWNp ZmllcyB0aGF0IHRoZSBlbmhhbmNlZCBiZWFjb24gc2hvdWxkIGluY2x1ZGUgYSBDaGFubmVsIEhv cHBpbmcgSUUgd2l0aCBhIEhvcHBpbmcgU2VxdWVuY2UgSUQgZXF1YWwgdG8gMC4gSG9wcGluZyBT ZXF1ZW5jZSBJRCAwIGlzIHRoZSBkZWZhdWx0IGhvcHBpbmcgc2VxdWVuY2UgSUQuIFNvIHRoZSBh Y3R1YWwgaG9wcGluZyBzZXF1ZW5jZSB3aWxsIG5vdCBiZSBpbmNsdWRlZCBpbiB0aGUgZW5oYW5j ZWQgYmVhY29uLjxicj4NCjxicj4NClNlY3Rpb24gNS4xLjFhIG9mIHRoZSBJRUU4MDIuMjUuNGUg c3RhbmRhcmQgZGVmaW5lcyBhbiBhbGdvcml0aG0gdG8gY2FsY3VsYXRlIGEgZGVmYXVsdCBob3Bw aW5nIHNlcXVlbmNlIElELg0KPGJyPg0KPGJyPg0KSSBoYXZlIHRoZSBmb2xsb3dpbmcgcXVlc3Rp b25zIHJlZ2FyZGluZyB0aGUgZGVmYXVsdCBob3BwaW5nIHNlcXVlbmNlOjxicj4NCjxicj4NCjEu IElzIGl0IHRoZSBpbnRlbnRpb24gdGhhdCBhIG1pbmltYWwgY29uZmlndXJhdGlvbiB1c2VzIHRo ZSBkZWZhdWx0IGhvcHBpbmcgc2VxdWVuY2UgYXMgZGVmaW5lZCBpbiB0aGUgSUVFODAyLjI1LjRl IHN0YW5kYXJkPzxicj4NCjIuIElmIHRoZSBhbnN3ZXIgb24gMS4gaXMgeWVzOiZuYnNwOyBUaGUg ZGVmaW5pdGlvbiBvZiB0aGUgSUVFODAyLjI1LjRlIGhvcHBpbmcgc2VxdWVuY2UgKGluIG15IG9w aW5pb24pIGlzIG5vdCB1bmFtYmlndW91cywgc28gY2FuIHlvdSBhZGQgdGhlIGFjdHVhbCBkZWZh dWx0IGhvcHBpbmcgc2VxdWVuY2UgdG8gdGhpcyBkcmFmdD88YnI+DQo8YnI+DQpSZWdhcmRzLDxi cj4NCjxicj4NCktlZXMuPGJyPg0KPGJyPg0KT24gT2N0IDI3LCAyMDE0LCBhdCAxMjoyMCBBTSwg WGF2aWVyIFZpbGFqb3NhbmEgJmx0O3h2aWxham9zYW5hIGF0IDxhIGhyZWY9Imh0dHA6Ly9lZWNz LmJlcmtlbGV5LmVkdSIgdGFyZ2V0PSJfYmxhbmsiPg0KZWVjcy5iZXJrZWxleS5lZHU8L2E+Jmd0 OyB3cm90ZTo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5BbGwsIEkganVzdCBwdWJsaXNoZWQgdGhlIG5ldyB2ZXJzaW9uIG9m IG1pbmltYWwuIEl0IGluY2x1ZGVzIGEgc2VjdXJpdHkgc2VjdGlvbiBhcyBkaXNjdXNzZWQgbGFz dCBjYWxsIGFuZCBzb21lIGNoYW5nZXMgdG8gdGhlIGRlZmF1bHQgdGltaW5nIHRvIGJlIGFjY29y ZGluZyB0byAxNS40IHRzY2ggZGVmYXVsdA0KIHZhbHVlcy4gPG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+cmVnYXJkcyw8YnI+DQpYYXZpPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LS0tLS0tLS0tLSBGb3J3 YXJkZWQgbWVzc2FnZSAtLS0tLS0tLS0tPGJyPg0KRnJvbTogJmx0O2ludGVybmV0LWRyYWZ0cyBh dCA8YSBocmVmPSJodHRwOi8vaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pZXRmLm9yZzwvYT4m Z3Q7PGJyPg0KRGF0ZTogMjAxNC0xMC0yNyA1OjE3IEdNVCYjNDM7MDE6MDA8YnI+DQpTdWJqZWN0 OiBbNnRpc2NoXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLTZ0aXNjaC1taW5pbWFsLTAzLnR4dDxi cj4NClRvOiBpLWQtYW5ub3VuY2UgYXQgPGEgaHJlZj0iaHR0cDovL2lldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+aWV0Zi5vcmc8L2E+PGJyPg0KQ2M6IDZ0aXNjaCBhdCA8YSBocmVmPSJodHRwOi8v aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pZXRmLm9yZzwvYT48YnI+DQo8YnI+DQo8YnI+DQo8 YnI+DQpBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJ bnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuPGJyPg0KJm5ic3A7VGhpcyBkcmFmdCBpcyBhIHdv cmsgaXRlbSBvZiB0aGUgSVB2NiBvdmVyIHRoZSBUU0NIIG1vZGUgb2YgSUVFRSA4MDIuMTUuNGUg V29ya2luZyBHcm91cCBvZiB0aGUgSUVURi48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgVGl0bGUmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzog TWluaW1hbCA2VGlTQ0ggQ29uZmlndXJhdGlvbjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyBBdXRob3JzJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzogWGF2aWVyIFZp bGFqb3NhbmE8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgS3JpcyBQaXN0 ZXI8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgRmlsZW5hbWUmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgOiBkcmFmdC1pZXRmLTZ0aXNjaC1taW5pbWFsLTAzLnR4dDxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBQYWdlcyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7OiAyMjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBEYXRl Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgOiAyMDE0LTEwLTI2PGJy Pg0KPGJyPg0KQWJzdHJhY3Q6PGJyPg0KJm5ic3A7ICZuYnNwO1RoaXMgZG9jdW1lbnQgZGVzY3Jp YmVzIHRoZSBtaW5pbWFsIHNldCBvZiBydWxlcyB0byBvcGVyYXRlIGE8YnI+DQombmJzcDsgJm5i c3A7W0lFRUU4MDIxNTRlXSBUaW1lc2xvdHRlZCBDaGFubmVsIEhvcHBpbmcgKFRTQ0gpIG5ldHdv cmsuJm5ic3A7IFRoaXM8YnI+DQombmJzcDsgJm5ic3A7bWluaW1hbCBtb2RlIG9mIG9wZXJhdGlv biBjYW4gYmUgdXNlZCBkdXJpbmcgbmV0d29yayBib290c3RyYXAsIGFzIGE8YnI+DQombmJzcDsg Jm5ic3A7ZmFsbC1iYWNrIG1vZGUgb2Ygb3BlcmF0aW9uIHdoZW4gbm8gZHluYW1pYyBzY2hlZHVs aW5nIHNvbHV0aW9uIGlzPGJyPg0KJm5ic3A7ICZuYnNwO2F2YWlsYWJsZSBvciBmdW5jdGlvbmlu Zywgb3IgZHVyaW5nIGVhcmx5IGludGVyb3BlcmFiaWxpdHkgdGVzdGluZzxicj4NCiZuYnNwOyAm bmJzcDthbmQgZGV2ZWxvcG1lbnQuPGJyPg0KPGJyPg0KPGJyPg0KVGhlIElFVEYgZGF0YXRyYWNr ZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi02dGlzY2gtbWluaW1hbC8iIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLTZ0 aXNjaC1taW5pbWFsLzwvYT48YnI+DQo8YnI+DQpUaGVyZSdzIGFsc28gYSBodG1saXplZCB2ZXJz aW9uIGF2YWlsYWJsZSBhdDo8YnI+DQo8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLTZ0aXNjaC1taW5pbWFsLTAzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi02dGlzY2gtbWluaW1hbC0wMzwvYT48YnI+DQo8 YnI+DQpBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6PGJy Pg0KPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi02 dGlzY2gtbWluaW1hbC0wMyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZj ZGlmZj91cmwyPWRyYWZ0LWlldGYtNnRpc2NoLW1pbmltYWwtMDM8L2E+PGJyPg0KPGJyPg0KPGJy Pg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20g dGhlIHRpbWUgb2Ygc3VibWlzc2lvbjxicj4NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFu ZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+DQp0b29scy5pZXRmLm9yZzwvYT4uPGJyPg0KPGJyPg0KSW50ZXJuZXQt RHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Ojxicj4NCjxhIGhy ZWY9ImZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvIiB0YXJnZXQ9Il9ibGFuayI+ ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy88L2E+PGJyPg0KPGJyPg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQo2dGlzY2ggbWFp bGluZyBsaXN0PGJyPg0KNnRpc2NoIGF0IDxhIGhyZWY9Imh0dHA6Ly9pZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPmlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vNnRpc2NoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby82dGlzY2g8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KNnRpc2NoIG1haWxpbmcg bGlzdDxicj4NCjZ0aXNjaCBhdCA8YSBocmVmPSJodHRwOi8vaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5pZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvLzZ0aXNjaCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vNnRpc2NoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCjZ0aXNjaCBtYWlsaW5n IGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86NnRpc2NoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+NnRpc2NoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vNnRpc2NoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby82dGlzY2g8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_F085911F642A6847987ADA23E611780D1D0D3299hoshiunilux_-- From nobody Tue Nov 11 08:31:31 2014 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90EEC1A9044 for <6tisch@ietfa.amsl.com>; Tue, 11 Nov 2014 08:31:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g_xtOjZ2tilq for <6tisch@ietfa.amsl.com>; Tue, 11 Nov 2014 08:31:21 -0800 (PST) Received: from mail-pa0-f43.google.com (mail-pa0-f43.google.com [209.85.220.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3A2F1A1AD7 for <6tisch@ietf.org>; Tue, 11 Nov 2014 08:31:20 -0800 (PST) Received: by mail-pa0-f43.google.com with SMTP id eu11so10914246pac.16 for <6tisch@ietf.org>; Tue, 11 Nov 2014 08:31:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=Rd9xnZmmT2YJ+5tGMch78VOAEFGVIhBy5wnqrQ/S63o=; b=LkBcIfT3hEwbmYoxS2eAYjX+Ltjz6CCxVFi54yg3R8Wc3Lk/xMnBTSyc+oLO5D3xMg wyGQ+753sdit37pa5eibaW7GgVd38Yg/6wQbxWa0LceSXF+Mq6GFXf3+nqX6gRxnjR4l qJbm5Cs6otvxVX5/HqG86IMsHhzhFkFH9sCdcLm33NI9CuRMeJLvFdjaNCzwyVyjrG5l pMRiaqRlOtkjlutWx6fiTUHS7Mogzqi7Z9bi4c7bp+5BOad1YTNEAe5C2kQkZKAJg1bv IYjyz28JFQqIlddMMSTUHqEOiIbKv2CnD9W+YJgOTT+tH5VtGRmw3NEaOj/AIX2pA6Oo 5i0w== X-Gm-Message-State: ALoCoQmIAdkAlU0I/2NteWamypyOpyN2Ktio/4lLpNmL+OqIH+SEg1AC1mVPVR8y66AhGFpi+1a2 X-Received: by 10.66.218.42 with SMTP id pd10mr3377758pac.151.1415723480483; Tue, 11 Nov 2014 08:31:20 -0800 (PST) Received: from [10.70.48.53] ([207.140.31.138]) by mx.google.com with ESMTPSA id c9sm19739708pdn.81.2014.11.11.08.31.19 for <6tisch@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 11 Nov 2014 08:31:19 -0800 (PST) Message-ID: <546239D7.7090403@berkeley.edu> Date: Tue, 11 Nov 2014 08:31:19 -0800 From: Kris Pister User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: 6tisch@ietf.org References: <545C898A.8060300@aimvalley.nl> <54608F2A.7090708@aimvalley.nl> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030108020906040506060707" Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch/MspUf0Ae_M0Xz2_hlHnkLGoLxZI Subject: Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-03.txt X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 16:31:29 -0000 This is a multi-part message in MIME format. --------------030108020906040506060707 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Given the rather obscure way that the default sequence is calculated, and the readability of IEEE standards, it seems like a good idea to explicitly include the default hop sequence in the minimal draft. How about the following modification to section 4.3.2 of the draft: After the line "Channel Hopping Template ID (b0-b7) = 0x00" add The default sequence for the 2.4GHz OQPSK PHY is [5, 6, 12, 7, 15, 4, 14, 11, 8, 0, 1, 2, 13, 3, 9, 10] per section 5.1.1a of [IEEE802154e]. ksjp p.s. Thomas, I'm trusting that your python code is correct - I didn't check. On 11/11/2014 7:50 AM, Maria Rita PALATTELLA wrote: > > Thomas, Xavi, > > I do agree we should add the conceptual explanation of the default > channel hopping sequence in the tsch draft, given that the draft is a > sort of guidelines about how tsch works. > > and at the same time we should mention it in minimal draft and > provide an example. > > Maria Rita > > *From:*6tisch [mailto:6tisch-bounces@ietf.org] *On Behalf Of *Thomas > Watteyne > *Sent:* Tuesday, November 11, 2014 5:24 AM > *To:* Xavier Vilajosana > *Cc:* Kees Trommel; Pascal Thubert (pthubert); 6tisch@ietf.org > *Subject:* Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-03.txt > > Xavi, thanks for your comments. What do others think? > > On Mon, Nov 10, 2014 at 6:18 PM, Xavier Vilajosana > > > wrote: > > Hi, > > Thomas convinced me. As it is something 15.4 TSCH specific it seems > reasonable to have it at the tsch draft and indicate the use of the > default channel hopping sequence in minimal. Minimal won't be > self-contained but it is not alreday. > > regards, > Xavi > > 2014-11-11 1:53 GMT+01:00 Thomas Watteyne >: > > Pascal, > > draft-ietf-6tisch-minimal should contain that it requires the default > channel hopping pattern. I think we agree on that. > > The description of what the default channel hopping pattern is (this > is just a discussion about IEEE802.15.4e-2012, nothing 6TiSCH > specific), might end up in 6tisch/draft-ietf-6tisch-tsch. > > What do others think? > > Thomas > > On Mon, Nov 10, 2014 at 10:57 AM, Pascal Thubert (pthubert) > > wrote: > > Hi Thomas: > > I think: > > - that the TSCH draft could discuss what is sub-defined in TSCH, > indicate that we use the range 0-15, to address Kees' points > > - but then, the setting to be used in minimal, and pseudo code along > the lines you produced should go in minimal to ensure interop. The > pseudo code would be an appendix. > > Makes sense? > > Pascal > > *From:*6tisch [mailto:6tisch-bounces@ietf.org > ] *On Behalf Of *Thomas Watteyne > *Sent:* lundi 10 novembre 2014 12:17 > *To:* Xavier Vilajosana > *Cc:* Kees Trommel; 6tisch@ietf.org > *Subject:* Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-03.txt > > Quick thought: does this discussion fit in draft-ietf-6tisch-minimal > or draft-ietf-6tisch-tsch? Both make sense to me. > > On Mon, Nov 10, 2014 at 10:15 AM, Xavier Vilajosana > > > wrote: > > Hi, > > my 5 cents. After thinking about it I am in favour of adding the > example as the draft will be more self-contained and will facilitate > the understanding of how ch. hopping sequence is caluclated. > (analogously to the OF0 example). > > regards, > > Xavi > > 2014-11-10 19:41 GMT+01:00 Thomas Watteyne >: > > Kees, > > In this script you made the assumption that the hopping sequence > length is equal to the number of channels. I think this is > reasonable assumption but it is not defined in the IEEE802.15.4e > standard, so it would be good idea to put this assumption in the > draft too. > > Yes, that was my assumption in this code. > > You are using channel numbers 0 - 15 and I assume that these are > the 16 2.5GHz channels. The IEEE802.15.4e standard define these as > channel numbers 11 - 26 of page 0. It is fine for me to keep the 0 > - 15 channel numbering scheme but it would good to mention this > too. What about (future) support of other channels and pages > defined in the IEEE802.15.4e standard? > > Correct, you should add 11 to the channel numbers in the code to use > channel numbers 11-26 in IEEE notation (2.405GHz-2.480GHz). AFAICT, > there is nothing in the hopping sequence of IEEE802.15.4e-TSCH which > prevents the use of (future) sets of channels. > > *@all*, what do others think? Are details about the hopping sequence > something we need to add to draft-ietf-6tisch-minimal? > > Thomas > > On Mon, Nov 10, 2014 at 12:10 AM, Kees Trommel > wrote: > > Thomas, Xavi, > > Thanks, I cannot find anything in this script that would violate the > IEEE802.15.4e standard. > > In this script you made the assumption that the hopping sequence > length is equal to the number of channels. I think this is reasonable > assumption but it is not defined in the IEEE802.15.4e standard, so it > would be good idea to put this assumption in the draft too. > > You are using channel numbers 0 - 15 and I assume that these are the > 16 2.5GHz channels. The IEEE802.15.4e standard define these as channel > numbers 11 - 26 of page 0. It is fine for me to keep the 0 - 15 > channel numbering scheme but it would good to mention this too. What > about (future) support of other channels and pages defined in the > IEEE802.15.4e standard? > > Kees. > > > > On 11/10/14 00:29, Thomas Watteyne wrote: > > Kees, Xavi, > > If the default hopping sequence isn't clear in IEEE802.15.4e-2012, > this is important information to the fed back to the IEEE802.15.4 > TG. *@PatKinney*, maybe you can chime in on whether the related > text will be changed in IEEE802.15.4-2015? > > In any case, let's disambiguate the hopping sequence on this > thread. We could add an example in draft-ietf-6tisch-minimal, and > maybe ask IEEE802.15.4 to do the same. > > I have created some quick Python code which I believe calculates > the default hopping sequence, see > https://gist.github.com/twatteyne/2e22ee3c1a802b685695. > > Could someone (*Pat*? *Jonathan*?) double-check that it computes > the right sequence. I'm copy-pasting the output below. > > Thomas > > --- > > This script calculates the default channel hopping sequence for the > > IEEE802.15.4e-2012 TSCH mode. > > \author Thomas Watteyne > > \date November 2014 > > \license http://opensource.org/licenses/BSD-3-Clause > > === Step a. > > SHUFFLE is a macHoppingSequenceLength-sized array. The contents of > this array ar > > e equivalent to the first macHoppingSequenceLength outputs of a > 9-bit linear fee > > dback shift register (LFSR) with polynomial x9 + x5 + 1 and a > starting seed of 2 > > 55. Each LFSR output is modulo macHoppingSequenceLength, so that > each entry of S > > HUFFLE is between 0 and (macHoppingSequenceLength - 1), inclusive. > > 5 9 > > 1 1 1 1 1 1 1 1 0 ( 255==0x0ff==b011111111) > > 1 1 1 1 1 1 1 1 1 ( 511==0x1ff==b111111111) --> 15 > > 0 1 1 1 1 1 1 1 1 ( 510==0x1fe==b111111110) --> 14 > > 0 0 1 1 1 1 1 1 1 ( 508==0x1fc==b111111100) --> 12 > > 0 0 0 1 1 1 1 1 1 ( 504==0x1f8==b111111000) --> 8 > > 0 0 0 0 1 1 1 1 1 ( 496==0x1f0==b111110000) --> 0 > > 0 0 0 0 0 1 1 1 1 ( 480==0x1e0==b111100000) --> 0 > > 1 0 0 0 0 0 1 1 1 ( 449==0x1c1==b111000001) --> 1 > > 1 1 0 0 0 0 0 1 1 ( 387==0x183==b110000011) --> 3 > > 1 1 1 0 0 0 0 0 1 ( 263==0x107==b100000111) --> 7 > > 1 1 1 1 0 0 0 0 0 ( 15==0x00f==b000001111) --> 15 > > 0 1 1 1 1 0 0 0 0 ( 30==0x01e==b000011110) --> 14 > > 1 0 1 1 1 1 0 0 0 ( 61==0x03d==b000111101) --> 13 > > 1 1 0 1 1 1 1 0 0 ( 123==0x07b==b001111011) --> 11 > > 1 1 1 0 1 1 1 1 0 ( 247==0x0f7==b011110111) --> 7 > > 1 1 1 1 0 1 1 1 1 ( 495==0x1ef==b111101111) --> 15 > > 1 1 1 1 1 0 1 1 1 ( 479==0x1df==b111011111) --> 15 > > SHUFFLE: [15, 14, 12, 8, 0, 0, 1, 3, 7, 15, 14, 13, 11, 7, 15, 15] > > === Step b. > > CHANNELS is a macHoppingSequenceLength-sized array that is > initially populated w > > ith the monotonically increasing list of channels available to the > PHY. > > CHANNELS: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15] > > === Step c. > > CHANNELS is shuffled as per Figure 7a. Elements may wind up being > swapped multip > > le times in this process. > > macHoppingSequenceList: *[5, 6, 12, 7, 15, 4, 14, 11, 8, 0, 1, 2, > 13, 3, 9, 10]* > > Script ended normally, press Enter to close. > > > On Friday, November 7, 2014, Xavier Vilajosana > > wrote: > > Dear Kees, > > thanks for your comments. > > answering 1) > > IMHO the fact that if default ch. hopping sequence is being used > *may not be* advertised in the EB it is not clear in the standard. > And therefore I opted to make the EB explicit (even only an ID and > this being the default) > > Page 11 of the 15.4e amendment indicates that: > > /All hopping sequences are referred to by an ID, > macHoppingSequenceID, with ID = 0 denoting the default/ > > /sequence for a particular PHY (or PHY configuration if the PHY > supports more than one channel list)./ > > then page 92 > > /The full Hopping Sequence may be omitted to ensure that the frame > does not exceed aMaxPHYPacketSize./ > > /In this case only the Hopping Sequence ID is carried, and the > length of the IE is 1 octet. When the length is/ > > /not equal to one, the additional fields are present. The element > varies in length depending upon the/ > > /numberOfChannels in use by the PHY. The channelPage and > numberOfChannels attributes can be used to/ > > /determine the size of the extendedBitmap, and the > macHoppingSequenceLength can be used to determine/ > > /the size of the macHoppingSequenceList./ > > /The Channel Hopping IE *may* be used by any channel hopping PAN > to synchronize devices./ > > My last point here is that this *may* might indicate optionality > but the case for the default id is not mentioned so I am not sure > it can be elided if default id (0) > > answering 2) it seems a good point. Let us think about it. > > regards, > > Xavi > > 2014-11-07 9:57 GMT+01:00 Kees Trommel >: > > Hi, > > This draft specifies that the enhanced beacon should include a > Channel Hopping IE with a Hopping Sequence ID equal to 0. Hopping > Sequence ID 0 is the default hopping sequence ID. So the actual > hopping sequence will not be included in the enhanced beacon. > > Section 5.1.1a of the IEE802.25.4e standard defines an algorithm > to calculate a default hopping sequence ID. > > I have the following questions regarding the default hopping sequence: > > 1. Is it the intention that a minimal configuration uses the > default hopping sequence as defined in the IEE802.25.4e standard? > 2. If the answer on 1. is yes: The definition of the IEE802.25.4e > hopping sequence (in my opinion) is not unambiguous, so can you > add the actual default hopping sequence to this draft? > > Regards, > > Kees. > > On Oct 27, 2014, at 12:20 AM, Xavier Vilajosana eecs.berkeley.edu > wrote: > > All, I just published the new version of minimal. It includes a > security section as discussed last call and some changes to the > default timing to be according to 15.4 tsch default values. > > regards, > Xavi > > ---------- Forwarded message ---------- > From: > > Date: 2014-10-27 5:17 GMT+01:00 > Subject: [6tisch] I-D Action: draft-ietf-6tisch-minimal-03.txt > To: i-d-announce at ietf.org > Cc: 6tisch at ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IPv6 over the TSCH mode of IEEE > 802.15.4e Working Group of the IETF. > > Title : Minimal 6TiSCH Configuration > Authors : Xavier Vilajosana > Kris Pister > Filename : draft-ietf-6tisch-minimal-03.txt > Pages : 22 > Date : 2014-10-26 > > Abstract: > This document describes the minimal set of rules to operate a > [IEEE802154e] Timeslotted Channel Hopping (TSCH) network. This > minimal mode of operation can be used during network bootstrap, > as a > fall-back mode of operation when no dynamic scheduling solution is > available or functioning, or during early interoperability testing > and development. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-6tisch-minimal-03 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-6tisch-minimal-03 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at > tools.ietf.org . > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > 6tisch mailing list > 6tisch at ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > > _______________________________________________ > 6tisch mailing list > 6tisch at ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > > > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > > > > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch --------------030108020906040506060707 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Given the rather obscure way that the default sequence is calculated, and
    the readability of IEEE standards, it seems like a good idea to explicitly include
    the default hop sequence in the minimal draft.  How about the following modification
    to section 4.3.2 of the draft:
    After the line "Channel Hopping Template ID (b0-b7) = 0x00" add

    The default sequence for the 2.4GHz OQPSK PHY is
    [5, 6, 12, 7, 15, 4, 14, 11, 8, 0, 1, 2, 13, 3, 9, 10]
    per section 5.1.1a of [IEEE802154e].

    ksjp

    p.s. Thomas, I'm trusting that your python code is correct - I didn't check.

    On 11/11/2014 7:50 AM, Maria Rita PALATTELLA wrote:

    Thomas, Xavi,

    I do agree we should add the conceptual explanation of the default channel hopping sequence in the tsch draft, given that the draft is a sort of guidelines about how tsch works.

    and at the same time we should  mention it in minimal draft and provide an example.

    Maria Rita

     

    From: 6tisch [mailto:6tisch-bounces@ietf.org] On Behalf Of Thomas Watteyne
    Sent: Tuesday, November 11, 2014 5:24 AM
    To: Xavier Vilajosana
    Cc: Kees Trommel; Pascal Thubert (pthubert); 6tisch@ietf.org
    Subject: Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-03.txt

     

    Xavi, thanks for your comments. What do others think?

     

    On Mon, Nov 10, 2014 at 6:18 PM, Xavier Vilajosana <xvilajosana@eecs.berkeley.edu> wrote:

    Hi, 

     

    Thomas convinced me. As it is something 15.4 TSCH specific it seems reasonable to have it at the tsch draft and indicate the use of the default channel hopping sequence in minimal. Minimal won't be self-contained but it is not alreday.

     

    regards,
    Xavi

     

    2014-11-11 1:53 GMT+01:00 Thomas Watteyne <watteyne@eecs.berkeley.edu>:

    Pascal,

     

    draft-ietf-6tisch-minimal should contain that it requires the default channel hopping pattern. I think we agree on that.

     

    The description of what the default channel hopping pattern is (this is just a discussion about IEEE802.15.4e-2012, nothing 6TiSCH specific), might end up in 6tisch/draft-ietf-6tisch-tsch.

     

    What do others think?

     

    Thomas

     

     

     

    On Mon, Nov 10, 2014 at 10:57 AM, Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:

    Hi Thomas:

     

    I think:

    - that the TSCH draft could discuss what is sub-defined in TSCH, indicate that we use the range 0-15, to address Kees’ points

    - but then, the setting to be used in minimal, and pseudo code along the lines you produced should go in minimal to ensure interop. The pseudo code would be an appendix.

     

    Makes sense?

     

    Pascal

     

    From: 6tisch [mailto:6tisch-bounces@ietf.org] On Behalf Of Thomas Watteyne
    Sent: lundi 10 novembre 2014 12:17
    To: Xavier Vilajosana
    Cc: Kees Trommel; 6tisch@ietf.org
    Subject: Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-03.txt

     

    Quick thought: does this discussion fit in draft-ietf-6tisch-minimal or draft-ietf-6tisch-tsch? Both make sense to me.

     

    On Mon, Nov 10, 2014 at 10:15 AM, Xavier Vilajosana <xvilajosana@eecs.berkeley.edu> wrote:

    Hi, 

     

    my 5 cents. After thinking about it I am in favour of adding the example as the draft will be more self-contained and will facilitate the understanding of how ch. hopping sequence is caluclated. (analogously to the OF0 example). 

     

    regards,

    Xavi

     

    2014-11-10 19:41 GMT+01:00 Thomas Watteyne <watteyne@eecs.berkeley.edu>:

    Kees,

     

    In this script you made the assumption that the hopping sequence length is equal to the number of channels. I think this is reasonable assumption but it is not defined in the IEEE802.15.4e standard, so it would be good idea to put this assumption in the draft too.

     

    Yes, that was my assumption in this code.

     

    You are using channel numbers 0 - 15 and I assume that these are the 16 2.5GHz channels. The IEEE802.15.4e standard define these as channel numbers 11 - 26 of page 0. It is fine for me to keep the 0 - 15 channel numbering scheme but it would good to mention this too. What about (future) support of other channels and pages defined in the IEEE802.15.4e standard?

     

    Correct, you should add 11 to the channel numbers in the code to use channel numbers 11-26 in IEEE notation (2.405GHz-2.480GHz). AFAICT, there is nothing in the hopping sequence of IEEE802.15.4e-TSCH which prevents the use of (future) sets of channels.

     

    @all, what do others think? Are details about the hopping sequence something we need to add to draft-ietf-6tisch-minimal?

     

    Thomas

     

    On Mon, Nov 10, 2014 at 12:10 AM, Kees Trommel <ctrommel@aimvalley.nl> wrote:

    Thomas, Xavi,

    Thanks, I cannot find anything in this script that would violate the IEEE802.15.4e standard.

    In this script you made the assumption that the hopping sequence length is equal to the number of channels. I think this is reasonable assumption but it is not defined in the IEEE802.15.4e standard, so it would be good idea to put this assumption in the draft too.

    You are using channel numbers 0 - 15 and I assume that these are the 16 2.5GHz channels. The IEEE802.15.4e standard define these as channel numbers 11 - 26 of page 0. It is fine for me to keep the 0 - 15 channel numbering scheme but it would good to mention this too. What about (future) support of other channels and pages defined in the IEEE802.15.4e standard?

    Kees.



    On 11/10/14 00:29, Thomas Watteyne wrote:

    Kees, Xavi,

     

    If the default hopping sequence isn't clear in IEEE802.15.4e-2012, this is important information to the fed back to the IEEE802.15.4 TG. @PatKinney, maybe you can chime in on whether the related text will be changed in IEEE802.15.4-2015?

     

    In any case, let's disambiguate the hopping sequence on this thread. We could add an example in draft-ietf-6tisch-minimal, and maybe ask IEEE802.15.4 to do the same.

     

    I have created some quick Python code which I believe calculates the default hopping sequence, see https://gist.github.com/twatteyne/2e22ee3c1a802b685695.

     

    Could someone (Pat? Jonathan?) double-check that it computes the right sequence. I'm copy-pasting the output below.

     

    Thomas

     

    ---

     

    This script calculates the default channel hopping sequence for the

    IEEE802.15.4e-2012 TSCH mode.

     

    \author Thomas Watteyne

    \date November 2014

     

     

    === Step a.

     

    SHUFFLE is a macHoppingSequenceLength-sized array. The contents of this array ar

    e equivalent to the first macHoppingSequenceLength outputs of a 9-bit linear fee

    dback shift register (LFSR) with polynomial x9 + x5 + 1 and a starting seed of 2

    55. Each LFSR output is modulo macHoppingSequenceLength, so that each entry of S

    HUFFLE is between 0 and (macHoppingSequenceLength - 1), inclusive.

     

               5       9

       1 1 1 1 1 1 1 1 0 ( 255==0x0ff==b011111111)

       1 1 1 1 1 1 1 1 1 ( 511==0x1ff==b111111111) --> 15

       0 1 1 1 1 1 1 1 1 ( 510==0x1fe==b111111110) --> 14

       0 0 1 1 1 1 1 1 1 ( 508==0x1fc==b111111100) --> 12

       0 0 0 1 1 1 1 1 1 ( 504==0x1f8==b111111000) --> 8

       0 0 0 0 1 1 1 1 1 ( 496==0x1f0==b111110000) --> 0

       0 0 0 0 0 1 1 1 1 ( 480==0x1e0==b111100000) --> 0

       1 0 0 0 0 0 1 1 1 ( 449==0x1c1==b111000001) --> 1

       1 1 0 0 0 0 0 1 1 ( 387==0x183==b110000011) --> 3

       1 1 1 0 0 0 0 0 1 ( 263==0x107==b100000111) --> 7

       1 1 1 1 0 0 0 0 0 (  15==0x00f==b000001111) --> 15

       0 1 1 1 1 0 0 0 0 (  30==0x01e==b000011110) --> 14

       1 0 1 1 1 1 0 0 0 (  61==0x03d==b000111101) --> 13

       1 1 0 1 1 1 1 0 0 ( 123==0x07b==b001111011) --> 11

       1 1 1 0 1 1 1 1 0 ( 247==0x0f7==b011110111) --> 7

       1 1 1 1 0 1 1 1 1 ( 495==0x1ef==b111101111) --> 15

       1 1 1 1 1 0 1 1 1 ( 479==0x1df==b111011111) --> 15

     

    SHUFFLE:  [15, 14, 12, 8, 0, 0, 1, 3, 7, 15, 14, 13, 11, 7, 15, 15]

     

    === Step b.

     

    CHANNELS is a macHoppingSequenceLength-sized array that is initially populated w

    ith the monotonically increasing list of channels available to the PHY.

     

    CHANNELS: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15]

     

    === Step c.

     

    CHANNELS is shuffled as per Figure 7a. Elements may wind up being swapped multip

    le times in this process.

     

    macHoppingSequenceList: [5, 6, 12, 7, 15, 4, 14, 11, 8, 0, 1, 2, 13, 3, 9, 10]

     

     

    Script ended normally, press Enter to close.


    On Friday, November 7, 2014, Xavier Vilajosana <xvilajosana@eecs.berkeley.edu> wrote:

    Dear Kees,

    thanks for your comments. 

     

    answering 1)

    IMHO the fact that if default ch. hopping sequence is being used may not be advertised in the EB it is not clear in the standard. And therefore I opted to make the EB explicit (even only an ID and this being the default)

    Page 11 of the 15.4e amendment indicates that:

     

    All hopping sequences are referred to by an ID, macHoppingSequenceID, with ID = 0 denoting the default

    sequence for a particular PHY (or PHY configuration if the PHY supports more than one channel list).

     

    then page 92

    The full Hopping Sequence may be omitted to ensure that the frame does not exceed aMaxPHYPacketSize.

    In this case only the Hopping Sequence ID is carried, and the length of the IE is 1 octet. When the length is

    not equal to one, the additional fields are present. The element varies in length depending upon the

    numberOfChannels in use by the PHY. The channelPage and numberOfChannels attributes can be used to

    determine the size of the extendedBitmap, and the macHoppingSequenceLength can be used to determine

    the size of the macHoppingSequenceList.

    The Channel Hopping IE may be used by any channel hopping PAN to synchronize devices.

     

    My last point here is that this may might indicate optionality but the case for the default id is not mentioned so I am not sure it can be elided if default id (0)

     

    answering 2) it seems a good point. Let us think about it.

     

    regards,

    Xavi

     

    2014-11-07 9:57 GMT+01:00 Kees Trommel <ctrommel@aimvalley.nl>:

    Hi,

    This draft specifies that the enhanced beacon should include a Channel Hopping IE with a Hopping Sequence ID equal to 0. Hopping Sequence ID 0 is the default hopping sequence ID. So the actual hopping sequence will not be included in the enhanced beacon.

    Section 5.1.1a of the IEE802.25.4e standard defines an algorithm to calculate a default hopping sequence ID.

    I have the following questions regarding the default hopping sequence:

    1. Is it the intention that a minimal configuration uses the default hopping sequence as defined in the IEE802.25.4e standard?
    2. If the answer on 1. is yes:  The definition of the IEE802.25.4e hopping sequence (in my opinion) is not unambiguous, so can you add the actual default hopping sequence to this draft?

    Regards,

    Kees.

    On Oct 27, 2014, at 12:20 AM, Xavier Vilajosana <xvilajosana at eecs.berkeley.edu> wrote:

    All, I just published the new version of minimal. It includes a security section as discussed last call and some changes to the default timing to be according to 15.4 tsch default values.

     

    regards,
    Xavi

     

    ---------- Forwarded message ----------
    From: <internet-drafts at ietf.org>
    Date: 2014-10-27 5:17 GMT+01:00
    Subject: [6tisch] I-D Action: draft-ietf-6tisch-minimal-03.txt
    To: i-d-announce at ietf.org
    Cc: 6tisch at ietf.org



    A New Internet-Draft is available from the on-line Internet-Drafts directories.
     This draft is a work item of the IPv6 over the TSCH mode of IEEE 802.15.4e Working Group of the IETF.

            Title           : Minimal 6TiSCH Configuration
            Authors         : Xavier Vilajosana
                              Kris Pister
            Filename        : draft-ietf-6tisch-minimal-03.txt
            Pages           : 22
            Date            : 2014-10-26

    Abstract:
       This document describes the minimal set of rules to operate a
       [IEEE802154e] Timeslotted Channel Hopping (TSCH) network.  This
       minimal mode of operation can be used during network bootstrap, as a
       fall-back mode of operation when no dynamic scheduling solution is
       available or functioning, or during early interoperability testing
       and development.


    The IETF datatracker status page for this draft is:
    https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal/

    There's also a htmlized version available at:
    http://tools.ietf.org/html/draft-ietf-6tisch-minimal-03

    A diff from the previous version is available at:
    http://www.ietf.org/rfcdiff?url2=draft-ietf-6tisch-minimal-03


    Please note that it may take a couple of minutes from the time of submission
    until the htmlized version and diff are available at tools.ietf.org.

    Internet-Drafts are also available by anonymous FTP at:
    ftp://ftp.ietf.org/internet-drafts/

    _______________________________________________
    6tisch mailing list
    6tisch at ietf.org
    https://www.ietf.org/mailman/listinfo/6tisch

     

    _______________________________________________
    6tisch mailing list
    6tisch at ietf.org
    https://www.ietf.org/mailman/listinfo/6tisch

     


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

     

     

     

     

     

     

     

     



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

    --------------030108020906040506060707-- From nobody Tue Nov 11 10:21:44 2014 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05CBD1A1A0F for <6tisch@ietfa.amsl.com>; Tue, 11 Nov 2014 10:21:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.094 X-Spam-Level: X-Spam-Status: No, score=-15.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hyz8jpBzK7KQ for <6tisch@ietfa.amsl.com>; Tue, 11 Nov 2014 10:21:31 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 718E91A0395 for <6tisch@ietf.org>; Tue, 11 Nov 2014 10:21:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=62442; q=dns/txt; s=iport; t=1415730091; x=1416939691; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=WIJT17oZYDXRF/p3hHL6T4uiLYtLUaXd4sqKAjZj1ec=; b=iCoOcRcRSWk87ITm/C2aPG53EEkW3l4Eo+ghQPY5Qo8deo4YXsvE+nQ0 06WsIjOvdthOVbc3BxvGu87zrnYRvZSU0UwaHNAr0a2ZGe6Pq4VKSEmwF 3e8sYB4LfNNmpYJeXSrcIGtq0J0Pyju+d8d1WVo8pGDXIg37qTlFVMhzd M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsFAKZSYlStJA2G/2dsb2JhbABcDoI6RlRUBQS7fI45gWQBCYZ6VQKBGBYBAQEBAX2EAgEBAQQBAQEXDQY6BxsCAQgOAwMBAQELFgEGBycLFAkIAgQBEggBEogmCAXPAwEBAQEBAQEBAQEBAQEBAQEBAQEBAReQJzwPEQ0KAQaDJ4EeBYY6iVSCI4RTiFU9gxKNU4QKgzpAbIFIgQMBAQE X-IronPort-AV: E=Sophos;i="5.07,362,1413244800"; d="scan'208,217";a="371352818" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-4.cisco.com with ESMTP; 11 Nov 2014 18:21:28 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id sABILSoV026290 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Nov 2014 18:21:28 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.165]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Tue, 11 Nov 2014 12:21:28 -0600 From: "Pascal Thubert (pthubert)" To: Kris Pister , "6tisch@ietf.org" <6tisch@ietf.org> Thread-Topic: [6tisch] I-D Action: draft-ietf-6tisch-minimal-03.txt Thread-Index: AQHP/HUmAsumb2j5UUyeWYX2bHAKRZxZk4YAgACOxACAABorAIAAAJCAgAALJICAAEIBgIAAOWGAgAABcACAANAVgIAAcHKA//+50MA= Date: Tue, 11 Nov 2014 18:21:27 +0000 Deferred-Delivery: Tue, 11 Nov 2014 18:21:00 +0000 Message-ID: References: <545C898A.8060300@aimvalley.nl> <54608F2A.7090708@aimvalley.nl> <546239D7.7090403@berkeley.edu> In-Reply-To: <546239D7.7090403@berkeley.edu> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.166.83] Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD848A4AB5Fxmbrcdx01ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch/gdVtCG01hRLEe4zy678C_FL2fdg Subject: Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-03.txt X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 18:21:41 -0000 --_000_E045AECD98228444A58C61C200AE1BD848A4AB5Fxmbrcdx01ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm all for it : ) Cheers, Pascal From: 6tisch [mailto:6tisch-bounces@ietf.org] On Behalf Of Kris Pister Sent: mardi 11 novembre 2014 08:31 To: 6tisch@ietf.org Subject: Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-03.txt Given the rather obscure way that the default sequence is calculated, and the readability of IEEE standards, it seems like a good idea to explicitly = include the default hop sequence in the minimal draft. How about the following mod= ification to section 4.3.2 of the draft: After the line "Channel Hopping Template ID (b0-b7) =3D 0x00" add The default sequence for the 2.4GHz OQPSK PHY is [5, 6, 12, 7, 15, 4, 14, 11, 8, 0, 1, 2, 13, 3, 9, 10] per section 5.1.1a of [IEEE802154e]. ksjp p.s. Thomas, I'm trusting that your python code is correct - I didn't check= . On 11/11/2014 7:50 AM, Maria Rita PALATTELLA wrote: Thomas, Xavi, I do agree we should add the conceptual explanation of the default channel = hopping sequence in the tsch draft, given that the draft is a sort of guide= lines about how tsch works. and at the same time we should mention it in minimal draft and provide an = example. Maria Rita From: 6tisch [mailto:6tisch-bounces@ietf.org] On Behalf Of Thomas Watteyne Sent: Tuesday, November 11, 2014 5:24 AM To: Xavier Vilajosana Cc: Kees Trommel; Pascal Thubert (pthubert); 6tisch@ietf.org Subject: Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-03.txt Xavi, thanks for your comments. What do others think? On Mon, Nov 10, 2014 at 6:18 PM, Xavier Vilajosana > wrote: Hi, Thomas convinced me. As it is something 15.4 TSCH specific it seems reasona= ble to have it at the tsch draft and indicate the use of the default channe= l hopping sequence in minimal. Minimal won't be self-contained but it is no= t alreday. regards, Xavi 2014-11-11 1:53 GMT+01:00 Thomas Watteyne >: Pascal, draft-ietf-6tisch-minimal should contain that it requires the default chann= el hopping pattern. I think we agree on that. The description of what the default channel hopping pattern is (this is jus= t a discussion about IEEE802.15.4e-2012, nothing 6TiSCH specific), might en= d up in 6tisch/draft-ietf-6tisch-tsch. What do others think? Thomas On Mon, Nov 10, 2014 at 10:57 AM, Pascal Thubert (pthubert) > wrote: Hi Thomas: I think: - that the TSCH draft could discuss what is sub-defined in TSCH, indicate t= hat we use the range 0-15, to address Kees' points - but then, the setting to be used in minimal, and pseudo code along the li= nes you produced should go in minimal to ensure interop. The pseudo code wo= uld be an appendix. Makes sense? Pascal From: 6tisch [mailto:6tisch-bounces@ietf.org] On Behalf Of Thomas Watteyne Sent: lundi 10 novembre 2014 12:17 To: Xavier Vilajosana Cc: Kees Trommel; 6tisch@ietf.org Subject: Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-03.txt Quick thought: does this discussion fit in draft-ietf-6tisch-minimal or dra= ft-ietf-6tisch-tsch? Both make sense to me. On Mon, Nov 10, 2014 at 10:15 AM, Xavier Vilajosana > wrote: Hi, my 5 cents. After thinking about it I am in favour of adding the example as= the draft will be more self-contained and will facilitate the understandin= g of how ch. hopping sequence is caluclated. (analogously to the OF0 exampl= e). regards, Xavi 2014-11-10 19:41 GMT+01:00 Thomas Watteyne >: Kees, In this script you made the assumption that the hopping sequence length is = equal to the number of channels. I think this is reasonable assumption but = it is not defined in the IEEE802.15.4e standard, so it would be good idea t= o put this assumption in the draft too. Yes, that was my assumption in this code. You are using channel numbers 0 - 15 and I assume that these are the 16 2.5= GHz channels. The IEEE802.15.4e standard define these as channel numbers 11= - 26 of page 0. It is fine for me to keep the 0 - 15 channel numbering sch= eme but it would good to mention this too. What about (future) support of o= ther channels and pages defined in the IEEE802.15.4e standard? Correct, you should add 11 to the channel numbers in the code to use channe= l numbers 11-26 in IEEE notation (2.405GHz-2.480GHz). AFAICT, there is noth= ing in the hopping sequence of IEEE802.15.4e-TSCH which prevents the use of= (future) sets of channels. @all, what do others think? Are details about the hopping sequence somethin= g we need to add to draft-ietf-6tisch-minimal? Thomas On Mon, Nov 10, 2014 at 12:10 AM, Kees Trommel > wrote: Thomas, Xavi, Thanks, I cannot find anything in this script that would violate the IEEE80= 2.15.4e standard. In this script you made the assumption that the hopping sequence length is = equal to the number of channels. I think this is reasonable assumption but = it is not defined in the IEEE802.15.4e standard, so it would be good idea t= o put this assumption in the draft too. You are using channel numbers 0 - 15 and I assume that these are the 16 2.5= GHz channels. The IEEE802.15.4e standard define these as channel numbers 11= - 26 of page 0. It is fine for me to keep the 0 - 15 channel numbering sch= eme but it would good to mention this too. What about (future) support of o= ther channels and pages defined in the IEEE802.15.4e standard? Kees. On 11/10/14 00:29, Thomas Watteyne wrote: Kees, Xavi, If the default hopping sequence isn't clear in IEEE802.15.4e-2012, this is = important information to the fed back to the IEEE802.15.4 TG. @PatKinney, m= aybe you can chime in on whether the related text will be changed in IEEE80= 2.15.4-2015? In any case, let's disambiguate the hopping sequence on this thread. We cou= ld add an example in draft-ietf-6tisch-minimal, and maybe ask IEEE802.15.4 = to do the same. I have created some quick Python code which I believe calculates the defaul= t hopping sequence, see https://gist.github.com/twatteyne/2e22ee3c1a802b685= 695. Could someone (Pat? Jonathan?) double-check that it computes the right sequ= ence. I'm copy-pasting the output below. Thomas --- This script calculates the default channel hopping sequence for the IEEE802.15.4e-2012 TSCH mode. \author Thomas Watteyne \date November 2014 \license http://opensource.org/licenses/BSD-3-Clause =3D=3D=3D Step a. SHUFFLE is a macHoppingSequenceLength-sized array. The contents of this arr= ay ar e equivalent to the first macHoppingSequenceLength outputs of a 9-bit linea= r fee dback shift register (LFSR) with polynomial x9 + x5 + 1 and a starting seed= of 2 55. Each LFSR output is modulo macHoppingSequenceLength, so that each entry= of S HUFFLE is between 0 and (macHoppingSequenceLength - 1), inclusive. 5 9 1 1 1 1 1 1 1 1 0 ( 255=3D=3D0x0ff=3D=3Db011111111) 1 1 1 1 1 1 1 1 1 ( 511=3D=3D0x1ff=3D=3Db111111111) --> 15 0 1 1 1 1 1 1 1 1 ( 510=3D=3D0x1fe=3D=3Db111111110) --> 14 0 0 1 1 1 1 1 1 1 ( 508=3D=3D0x1fc=3D=3Db111111100) --> 12 0 0 0 1 1 1 1 1 1 ( 504=3D=3D0x1f8=3D=3Db111111000) --> 8 0 0 0 0 1 1 1 1 1 ( 496=3D=3D0x1f0=3D=3Db111110000) --> 0 0 0 0 0 0 1 1 1 1 ( 480=3D=3D0x1e0=3D=3Db111100000) --> 0 1 0 0 0 0 0 1 1 1 ( 449=3D=3D0x1c1=3D=3Db111000001) --> 1 1 1 0 0 0 0 0 1 1 ( 387=3D=3D0x183=3D=3Db110000011) --> 3 1 1 1 0 0 0 0 0 1 ( 263=3D=3D0x107=3D=3Db100000111) --> 7 1 1 1 1 0 0 0 0 0 ( 15=3D=3D0x00f=3D=3Db000001111) --> 15 0 1 1 1 1 0 0 0 0 ( 30=3D=3D0x01e=3D=3Db000011110) --> 14 1 0 1 1 1 1 0 0 0 ( 61=3D=3D0x03d=3D=3Db000111101) --> 13 1 1 0 1 1 1 1 0 0 ( 123=3D=3D0x07b=3D=3Db001111011) --> 11 1 1 1 0 1 1 1 1 0 ( 247=3D=3D0x0f7=3D=3Db011110111) --> 7 1 1 1 1 0 1 1 1 1 ( 495=3D=3D0x1ef=3D=3Db111101111) --> 15 1 1 1 1 1 0 1 1 1 ( 479=3D=3D0x1df=3D=3Db111011111) --> 15 SHUFFLE: [15, 14, 12, 8, 0, 0, 1, 3, 7, 15, 14, 13, 11, 7, 15, 15] =3D=3D=3D Step b. CHANNELS is a macHoppingSequenceLength-sized array that is initially popula= ted w ith the monotonically increasing list of channels available to the PHY. CHANNELS: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15] =3D=3D=3D Step c. CHANNELS is shuffled as per Figure 7a. Elements may wind up being swapped m= ultip le times in this process. macHoppingSequenceList: [5, 6, 12, 7, 15, 4, 14, 11, 8, 0, 1, 2, 13, 3, 9, = 10] Script ended normally, press Enter to close. On Friday, November 7, 2014, Xavier Vilajosana > wrote: Dear Kees, thanks for your comments. answering 1) IMHO the fact that if default ch. hopping sequence is being used may not be= advertised in the EB it is not clear in the standard. And therefore I opte= d to make the EB explicit (even only an ID and this being the default) Page 11 of the 15.4e amendment indicates that: All hopping sequences are referred to by an ID, macHoppingSequenceID, with = ID =3D 0 denoting the default sequence for a particular PHY (or PHY configuration if the PHY supports mor= e than one channel list). then page 92 The full Hopping Sequence may be omitted to ensure that the frame does not = exceed aMaxPHYPacketSize. In this case only the Hopping Sequence ID is carried, and the length of the= IE is 1 octet. When the length is not equal to one, the additional fields are present. The element varies in = length depending upon the numberOfChannels in use by the PHY. The channelPage and numberOfChannels at= tributes can be used to determine the size of the extendedBitmap, and the macHoppingSequenceLength = can be used to determine the size of the macHoppingSequenceList. The Channel Hopping IE may be used by any channel hopping PAN to synchroniz= e devices. My last point here is that this may might indicate optionality but the case= for the default id is not mentioned so I am not sure it can be elided if d= efault id (0) answering 2) it seems a good point. Let us think about it. regards, Xavi 2014-11-07 9:57 GMT+01:00 Kees Trommel >: Hi, This draft specifies that the enhanced beacon should include a Channel Hopp= ing IE with a Hopping Sequence ID equal to 0. Hopping Sequence ID 0 is the = default hopping sequence ID. So the actual hopping sequence will not be inc= luded in the enhanced beacon. Section 5.1.1a of the IEE802.25.4e standard defines an algorithm to calcula= te a default hopping sequence ID. I have the following questions regarding the default hopping sequence: 1. Is it the intention that a minimal configuration uses the default hoppin= g sequence as defined in the IEE802.25.4e standard? 2. If the answer on 1. is yes: The definition of the IEE802.25.4e hopping = sequence (in my opinion) is not unambiguous, so can you add the actual defa= ult hopping sequence to this draft? Regards, Kees. On Oct 27, 2014, at 12:20 AM, Xavier Vilajosana > wrote: All, I just published the new version of minimal. It includes a security se= ction as discussed last call and some changes to the default timing to be a= ccording to 15.4 tsch default values. regards, Xavi ---------- Forwarded message ---------- From: > Date: 2014-10-27 5:17 GMT+01:00 Subject: [6tisch] I-D Action: draft-ietf-6tisch-minimal-03.txt To: i-d-announce at ietf.org Cc: 6tisch at ietf.org A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 over the TSCH mode of IEEE 802.15.4e= Working Group of the IETF. Title : Minimal 6TiSCH Configuration Authors : Xavier Vilajosana Kris Pister Filename : draft-ietf-6tisch-minimal-03.txt Pages : 22 Date : 2014-10-26 Abstract: This document describes the minimal set of rules to operate a [IEEE802154e] Timeslotted Channel Hopping (TSCH) network. This minimal mode of operation can be used during network bootstrap, as a fall-back mode of operation when no dynamic scheduling solution is available or functioning, or during early interoperability testing and development. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6tisch-minimal-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6tisch-minimal-03 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ 6tisch mailing list 6tisch at ietf.org https://www.ietf.org/mailman/listinfo/6tisch _______________________________________________ 6tisch mailing list 6tisch at ietf.org https://www.ietf.org/mailman/listinfo/6tisch _______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch _______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch --_000_E045AECD98228444A58C61C200AE1BD848A4AB5Fxmbrcdx01ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    I’m all for it : )<= o:p>

     <= /p>

    Cheers,<= /o:p>

     

    Pascal

     <= /p>

    From: 6tisch [mailto:6tisch-bounces@ietf.org] On Behalf Of Kris Pister
    Sent: mardi 11 novembre 2014 08:31
    To: 6tisch@ietf.org
    Subject: Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-03.txt

     

    Given the rather obsc= ure way that the default sequence is calculated, and
    the readability of IEEE standards, it seems like a good idea to explicitly = include
    the default hop sequence in the minimal draft.  How about the followin= g modification
    to section 4.3.2 of the draft:
    After the line "Channel Hopping Template ID (b0-b7) =3D 0x00" add=

    The default sequence for the 2.4GHz OQPSK PHY is
    [5, 6, 12, 7, 15, 4, 14, 11, 8, 0, 1, 2, 13, 3, 9, 10]
    per section 5.1.1a of [IEEE802154e].

    ksjp

    p.s. Thomas, I'm trusting that your python code is correct - I didn't check= .

    On 11/11/2014 7:50 AM, Maria Rita PALATTELLA wrote:<= o:p>

    Thomas, Xavi,=

    I do agree we should add = the conceptual explanation of the default channel hopping sequence in the t= sch draft, given that the draft is a sort of guidelines about how tsch works.

    and at the same time we s= hould  mention it in minimal draft and provide an example.=

    Maria Rita

     <= /p>

    From: 6tisch [= mailto:6tisch-bounces@ietf.org] On Behalf Of Thomas Watteyne
    Sent: Tuesday, November 11, 2014 5:24 AM
    To: Xavier Vilajosana
    Cc: Kees Trommel; Pascal Thubert (pthubert);
    6tisch@ietf.org
    Subject: Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-03.txt

     

    Xavi, thanks for your comments. What do others think= ?

     

    On Mon, Nov 10, 2014 at 6:18 PM, Xavier Vilajosana &= lt;xvila= josana@eecs.berkeley.edu> wrote:

    Hi, 

     

    Thomas convinced me. As it is something 15.4 TSCH sp= ecific it seems reasonable to have it at the tsch draft and indicate the us= e of the default channel hopping sequence in minimal. Minimal won't be self= -contained but it is not alreday.

     

    regards,
    Xavi

     

    2014-11-11 1:53 GMT+01:00 Thomas Watteyne <watteyne@eecs= .berkeley.edu>:

    Pascal,

     

    draft-ietf-6tisch-minimal should contain that it req= uires the default channel hopping pattern. I think we agree on that.

     

    The description of what the default channel hopping = pattern is (this is just a discussion about IEEE802.15.4e-2012, nothing 6Ti= SCH specific), might end up in 6tisch/draft-ietf-6tisch-tsch.

     

    What do others think?

     

    Thomas

     

     

     

    On Mon, Nov 10, 2014 at 10:57 AM, Pascal Thubert (pt= hubert) <pthuber= t@cisco.com> wrote:

    Hi Thomas:

     

    I think:

    - that the TSCH draft could discuss wha= t is sub-defined in TSCH, indicate that we use the range 0-15, to address Kees’ points

    - but then, the setting to be used in m= inimal, and pseudo code along the lines you produced should go in minimal to ensure interop. The pseudo code would be an appendix.

     

    Makes sense?

     

    Pascal

     

    From: 6tisch [mailto:6tisch-bounces@ietf.o= rg] On Behalf Of Thomas Watteyne
    Sent: lundi 10 novembre 2014 12:17
    To: Xavier Vilajosana
    Cc: Kees Trommel; 6tisch@ietf.org
    Subject: Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-03.txt

     

    Quick thought: does this discussion fit in draft-ietf-6tisch-= minimal or draft-ietf-6tisch-tsch? Both make sense to me.

     

    On Mon, Nov 10, 2014 at 10:15 AM, Xavier Vilajosana <xvilajosana@eecs.b= erkeley.edu> wrote:

    Hi, 

     

    my 5 cents. After thinking about it I am in favour of adding the e= xample as the draft will be more self-contained and will facilitate the und= erstanding of how ch. hopping sequence is caluclated. (analogously to the OF0 example). 

     

    regards,

    Xavi

     

    2014-11-10 19:41 GMT+01:00 Thomas Watteyne <watteyne@eecs.berkeley.edu= >:

    Kees,

     

    In this script you made the assumption that the hopping sequence l= ength is equal to the number of channels. I think this is reasonable assump= tion but it is not defined in the IEEE802.15.4e standard, so it would be good idea to put this assumption in the draft too= .

     

    Yes, that was my assumption in this code.

     

    You are using channel numbers 0 - 15 and I assume that these are t= he 16 2.5GHz channels. The IEEE802.15.4e standard define these as channel n= umbers 11 - 26 of page 0. It is fine for me to keep the 0 - 15 channel numbering scheme but it would good to me= ntion this too. What about (future) support of other channels and pages def= ined in the IEEE802.15.4e standard?

     

    Correct, you should add 11 to the channel numbers in the code to u= se channel numbers 11-26 in IEEE notation (2.405GHz-2.480GHz). AFAICT, ther= e is nothing in the hopping sequence of IEEE802.15.4e-TSCH which prevents the use of (future) sets of channels.=

     

    @all, what do others think? Are details about the hopping s= equence something we need to add to draft-ietf-6tisch-minimal?

     

    Thomas

     

    On Mon, Nov 10, 2014 at 12:10 AM, Kees Trommel <ctrommel@aimvalley.nl> w= rote:

    Thomas, Xavi,

    Thanks, I cannot find anything in this script that would violate the IEEE80= 2.15.4e standard.

    In this script you made the assumption that the hopping sequence length is = equal to the number of channels. I think this is reasonable assumption but = it is not defined in the IEEE802.15.4e standard, so it would be good idea t= o put this assumption in the draft too.

    You are using channel numbers 0 - 15 and I assume that these are the 16 2.5= GHz channels. The IEEE802.15.4e standard define these as channel numbers 11= - 26 of page 0. It is fine for me to keep the 0 - 15 channel numbering sch= eme but it would good to mention this too. What about (future) support of other channels and pages defined = in the IEEE802.15.4e standard?

    Kees.



    On 11/10/14 00:29, Thomas Watteyne wrote:

    Kees, Xavi,

     

    If the default hopping sequence isn't clear in IEEE802.15.4e-2012,= this is important information to the fed back to the IEEE802.15.4 TG. @PatKinney, maybe you can chime in on whether the related text will = be changed in IEEE802.15.4-2015?

     

    In any case, let's disambiguate the hopping sequence on this threa= d. We could add an example in draft-ietf-6tisch-minimal, and maybe ask IEEE= 802.15.4 to do the same.

     

    I have created some quick Python code which I believe calculates t= he default hopping sequence, see https://gist.github.com/twatteyne/2e22ee3c1a802b685695.

     

    Could someone (Pat? Jonathan?) double-check that it computes the right sequence. I'm copy-pasting the output below.

     

    Thomas

     

    ---

     

    This script calculates the default channel hopping sequence for the

    IEEE802.15.4e-2012 TSCH mode.

     

    \author Thomas Watteyne

    \date November 2014

     

     

    =3D=3D=3D Step a.

     

    SHUFFLE is a macHoppingSequenceLength-sized array. The contents of this= array ar

    e equivalent to the first macHoppingSequenceLength outputs of a 9-bit l= inear fee

    dback shift register (LFSR) with polynomial x9 + x5 + 1 and a s= tarting seed of 2

    55. Each LFSR output is modulo macHoppingSequenceLength, so that each e= ntry of S

    HUFFLE is between 0 and (macHoppingSequenceLength - 1), inclusive.

     

               5       9

       1 1 1 1 1 1 1 1 0 ( 255=3D=3D0x0ff=3D=3Db011111111)=

       1 1 1 1 1 1 1 1 1 ( 511=3D=3D0x1ff=3D=3Db111111111) -->= 15

       0 1 1 1 1 1 1 1 1 ( 510=3D=3D0x1fe=3D=3Db111111110) -->= 14

       0 0 1 1 1 1 1 1 1 ( 508=3D=3D0x1fc=3D=3Db111111100) -->= 12

       0 0 0 1 1 1 1 1 1 ( 504=3D=3D0x1f8=3D=3Db111111000) -->= 8

       0 0 0 0 1 1 1 1 1 ( 496=3D=3D0x1f0=3D=3Db111110000) -->= 0

       0 0 0 0 0 1 1 1 1 ( 480=3D=3D0x1e0=3D=3Db111100000) -->= 0

       1 0 0 0 0 0 1 1 1 ( 449=3D=3D0x1c1=3D=3Db111000001) -->= 1

       1 1 0 0 0 0 0 1 1 ( 387=3D=3D0x183=3D=3Db110000011) -->= 3

       1 1 1 0 0 0 0 0 1 ( 263=3D=3D0x107=3D=3Db100000111) -->= 7

       1 1 1 1 0 0 0 0 0 (  15=3D=3D0x00f=3D=3Db000001111) -= -> 15

       0 1 1 1 1 0 0 0 0 (  30=3D=3D0x01e=3D=3Db000011110) -= -> 14

       1 0 1 1 1 1 0 0 0 (  61=3D=3D0x03d=3D=3Db000111101) -= -> 13

       1 1 0 1 1 1 1 0 0 ( 123=3D=3D0x07b=3D=3Db001111011) -->= 11

       1 1 1 0 1 1 1 1 0 ( 247=3D=3D0x0f7=3D=3Db011110111) -->= 7

       1 1 1 1 0 1 1 1 1 ( 495=3D=3D0x1ef=3D=3Db111101111) -->= 15

       1 1 1 1 1 0 1 1 1 ( 479=3D=3D0x1df=3D=3Db111011111) -->= 15

     

    SHUFFLE:  [15, 14, 12, 8, 0, 0, 1, 3, 7, 15, 14, 13, 11, 7, 15, 15= ]

     

    =3D=3D=3D Step b.

     

    CHANNELS is a macHoppingSequenceLength-sized array that is initially po= pulated w

    ith the monotonically increasing list of channels available to the PHY.=

     

    CHANNELS: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15]=

     

    =3D=3D=3D Step c.

     

    CHANNELS is shuffled as per Figure 7a. Elements may wind up being swapp= ed multip

    le times in this process.

     

    macHoppingSequenceList: [5, 6, 12, 7, 15, 4, 14, 11, 8, 0, 1, 2, = 13, 3, 9, 10]

     

     

    Script ended normally, press Enter to close.


    On Friday, November 7, 2014, Xavier Vilajosana <xvilajosana@eecs.berkeley.edu> wrote:

    Dear Kees,

    thanks for your comments. 

     

    answering 1)

    IMHO the fact that if default ch. hopping sequence is being used may not be advertised in the EB it is not clear in the standard. And= therefore I opted to make the EB explicit (even only an ID and this being = the default)

    Page 11 of the 15.4e amendment indicates that:

     

    All hopping sequences are referred to by an ID, macHoppingSeque= nceID, with ID =3D 0 denoting the default

    sequence for a particular PHY (or PHY configuration if the PHY = supports more than one channel list).

     

    then page 92

    The full Hopping Sequence may be omitted to ensure that the fra= me does not exceed aMaxPHYPacketSize.

    In this case only the Hopping Sequence ID is carried, and the l= ength of the IE is 1 octet. When the length is

    not equal to one, the additional fields are present. The elemen= t varies in length depending upon the

    numberOfChannels in use by the PHY. The channelPage and numberO= fChannels attributes can be used to

    determine the size of the extendedBitmap, and the macHoppingSeq= uenceLength can be used to determine

    the size of the macHoppingSequenceList.

    The Channel Hopping IE may be used by any channel hopping PAN to synchronize devices.

     

    My last point here is that this may might indicate optionality but the case for the default id = is not mentioned so I am not sure it can be elided if default id (0)

     

    answering 2) it seems a good point. Let us think about it.

     

    regards,

    Xavi

     

    2014-11-07 9:57 GMT+01:00 Kees Trommel <ctrommel@aimvalley.nl>:=

    Hi,

    This draft specifies that the enhanced beacon should include a Channel Hopp= ing IE with a Hopping Sequence ID equal to 0. Hopping Sequence ID 0 is the = default hopping sequence ID. So the actual hopping sequence will not be inc= luded in the enhanced beacon.

    Section 5.1.1a of the IEE802.25.4e standard defines an algorithm to calcula= te a default hopping sequence ID.

    I have the following questions regarding the default hopping sequence:

    1. Is it the intention that a minimal configuration uses the default hoppin= g sequence as defined in the IEE802.25.4e standard?
    2. If the answer on 1. is yes:  The definition of the IEE802.25.4e hop= ping sequence (in my opinion) is not unambiguous, so can you add the actual= default hopping sequence to this draft?

    Regards,

    Kees.

    On Oct 27, 2014, at 12:20 AM, Xavier Vilajosana <xvilajosana at eecs.berkeley.edu> wrote:


    All, I just published the new version of minimal. It includes a se= curity section as discussed last call and some changes to the default timin= g to be according to 15.4 tsch default values.

     

    regards,
    Xavi

     

    ---------- Forwarded message ----------
    From: <internet-drafts at = ietf.org>
    Date: 2014-10-27 5:17 GMT+01:00
    Subject: [6tisch] I-D Action: draft-ietf-6tisch-minimal-03.txt
    To: i-d-announce at ietf.org<= /a>
    Cc: 6tisch at
    ietf.org


    A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
     This draft is a work item of the IPv6 over the TSCH mode of IEEE 802.= 15.4e Working Group of the IETF.

            Title           := Minimal 6TiSCH Configuration
            Authors         : Xavi= er Vilajosana
                         = ;     Kris Pister
            Filename        : draft-iet= f-6tisch-minimal-03.txt
            Pages           := 22
            Date            := 2014-10-26

    Abstract:
       This document describes the minimal set of rules to operate a<= br>    [IEEE802154e] Timeslotted Channel Hopping (TSCH) network. = ; This
       minimal mode of operation can be used during network bootstrap= , as a
       fall-back mode of operation when no dynamic scheduling solutio= n is
       available or functioning, or during early interoperability tes= ting
       and development.


    The IETF datatracker status page for this draft is:
    https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal/<= /a>

    There's also a htmlized version available at:
    http://tools.ietf.org/html/draft-ietf-6tisch-minimal-03

    A diff from the previous version is available at:
    http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6tisch-min= imal-03


    Please note that it may take a couple of minutes from the time of submissio= n
    until the htmlized version and diff are available at tools.ietf.org.

    Internet-Drafts are also available by anonymous FTP at:
    ftp://ftp= .ietf.org/internet-drafts/

    _______________________________________________
    6tisch mailing list
    6tisch at ietf.org
    = https://www.ietf.org/mailman/listinfo/6tisch

     

    _______________________________________________
    6tisch mailing list
    6tisch at ietf.org
    = https://www.ietf.org/mailman/listinfo/6tisch

     


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

     

     

     

     

     

     

     

     




    _______________________________________________
    6tisch mailing list
    6tisch@ietf.org
    
    https://www.i=
    etf.org/mailman/listinfo/6tisch

     

    --_000_E045AECD98228444A58C61C200AE1BD848A4AB5Fxmbrcdx01ciscoc_-- From nobody Tue Nov 11 11:46:52 2014 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24B021A88FF for <6tisch@ietfa.amsl.com>; Tue, 11 Nov 2014 11:46:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xm3Jo5pqDI2V for <6tisch@ietfa.amsl.com>; Tue, 11 Nov 2014 11:46:39 -0800 (PST) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83F191A88F3 for <6tisch@ietf.org>; Tue, 11 Nov 2014 11:46:36 -0800 (PST) Received: by mail-wg0-f48.google.com with SMTP id y19so1621181wgg.35 for <6tisch@ietf.org>; Tue, 11 Nov 2014 11:46:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=oUwPnqWt2PYV9fseDrENAG7l6SpAyqHv1QnpdHFvvk0=; b=lTkbVTPnMZEu8Vj2ikpVvL9x8i+73/LKAA6nOWV3IQXihvU5FD0zlA7NZ6dD4RWJ7V f6zxqGtM13QduCW5FKNUoT8VJh3YMNfnbC2TxQXHA+ntVPxnW2uloy95SKlUszM89EdW UNew8Ai5qYs10v4KGyUXIyC6JkJ4QgdhTWRarREcdiS2Y86CFJGyVJ7Q1YmWwRMXyjD3 e6bZut0bIxLSxDjYpMGHUNFe7jbAQXRztPKC0NSodRpxDDpVPn4JU6MtmxdWOfRXWlDE JiymWzqI8oL+kp2/gMUCeyovQYR+n3amNC3UaYHA6JyBHYsfsYpfgUDEIgDxcfCXH38S 1cWg== MIME-Version: 1.0 X-Received: by 10.180.99.105 with SMTP id ep9mr44193491wib.82.1415735195246; Tue, 11 Nov 2014 11:46:35 -0800 (PST) Sender: xvilajosana@gmail.com Received: by 10.27.130.193 with HTTP; Tue, 11 Nov 2014 11:46:35 -0800 (PST) In-Reply-To: References: <545C898A.8060300@aimvalley.nl> <54608F2A.7090708@aimvalley.nl> <546239D7.7090403@berkeley.edu> Date: Tue, 11 Nov 2014 20:46:35 +0100 X-Google-Sender-Auth: MZA-yMGyD_zRUsA7D3RHDPUv-jM Message-ID: From: Xavier Vilajosana To: "Pascal Thubert (pthubert)" Content-Type: multipart/alternative; boundary=f46d04428f5668a69605079a893a Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch/W_TeE1GMhoWI-MBzoMLaTZkaebk Cc: Kris Pister , "6tisch@ietf.org" <6tisch@ietf.org> Subject: Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-03.txt X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 19:46:44 -0000 --f46d04428f5668a69605079a893a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I'll wait for others opinion and I'll add it to the draft. regards, Xavi 2014-11-11 19:21 GMT+01:00 Pascal Thubert (pthubert) : > I=E2=80=99m all for it : ) > > > > Cheers, > > > > Pascal > > > > *From:* 6tisch [mailto:6tisch-bounces@ietf.org] *On Behalf Of *Kris Piste= r > *Sent:* mardi 11 novembre 2014 08:31 > *To:* 6tisch@ietf.org > > *Subject:* Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-03.txt > > > > Given the rather obscure way that the default sequence is calculated, and > the readability of IEEE standards, it seems like a good idea to explicitl= y > include > the default hop sequence in the minimal draft. How about the following > modification > to section 4.3.2 of the draft: > After the line "Channel Hopping Template ID (b0-b7) =3D 0x00" add > > The default sequence for the 2.4GHz OQPSK PHY is > [5, 6, 12, 7, 15, 4, 14, 11, 8, 0, 1, 2, 13, 3, 9, 10] > per section 5.1.1a of [IEEE802154e]. > > ksjp > > p.s. Thomas, I'm trusting that your python code is correct - I didn't > check. > > On 11/11/2014 7:50 AM, Maria Rita PALATTELLA wrote: > > Thomas, Xavi, > > I do agree we should add the conceptual explanation of the default channe= l > hopping sequence in the tsch draft, given that the draft is a sort of > guidelines about how tsch works. > > and at the same time we should mention it in minimal draft and provide a= n > example. > > Maria Rita > > > > *From:* 6tisch [mailto:6tisch-bounces@ietf.org <6tisch-bounces@ietf.org>]= *On > Behalf Of *Thomas Watteyne > *Sent:* Tuesday, November 11, 2014 5:24 AM > *To:* Xavier Vilajosana > *Cc:* Kees Trommel; Pascal Thubert (pthubert); 6tisch@ietf.org > *Subject:* Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-03.txt > > > > Xavi, thanks for your comments. What do others think? > > > > On Mon, Nov 10, 2014 at 6:18 PM, Xavier Vilajosana < > xvilajosana@eecs.berkeley.edu> wrote: > > Hi, > > > > Thomas convinced me. As it is something 15.4 TSCH specific it seems > reasonable to have it at the tsch draft and indicate the use of the defau= lt > channel hopping sequence in minimal. Minimal won't be self-contained but = it > is not alreday. > > > > regards, > Xavi > > > > 2014-11-11 1:53 GMT+01:00 Thomas Watteyne : > > Pascal, > > > > draft-ietf-6tisch-minimal should contain that it requires the default > channel hopping pattern. I think we agree on that. > > > > The description of what the default channel hopping pattern is (this is > just a discussion about IEEE802.15.4e-2012, nothing 6TiSCH specific), mig= ht > end up in 6tisch/draft-ietf-6tisch-tsch. > > > > What do others think? > > > > Thomas > > > > > > > > On Mon, Nov 10, 2014 at 10:57 AM, Pascal Thubert (pthubert) < > pthubert@cisco.com> wrote: > > Hi Thomas: > > > > I think: > > - that the TSCH draft could discuss what is sub-defined in TSCH, indicate > that we use the range 0-15, to address Kees=E2=80=99 points > > - but then, the setting to be used in minimal, and pseudo code along the > lines you produced should go in minimal to ensure interop. The pseudo cod= e > would be an appendix. > > > > Makes sense? > > > > Pascal > > > > *From:* 6tisch [mailto:6tisch-bounces@ietf.org] *On Behalf Of *Thomas > Watteyne > *Sent:* lundi 10 novembre 2014 12:17 > *To:* Xavier Vilajosana > *Cc:* Kees Trommel; 6tisch@ietf.org > *Subject:* Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-03.txt > > > > Quick thought: does this discussion fit in draft-ietf-6tisch-minimal or > draft-ietf-6tisch-tsch? Both make sense to me. > > > > On Mon, Nov 10, 2014 at 10:15 AM, Xavier Vilajosana < > xvilajosana@eecs.berkeley.edu> wrote: > > Hi, > > > > my 5 cents. After thinking about it I am in favour of adding the example > as the draft will be more self-contained and will facilitate the > understanding of how ch. hopping sequence is caluclated. (analogously to > the OF0 example). > > > > regards, > > Xavi > > > > 2014-11-10 19:41 GMT+01:00 Thomas Watteyne : > > Kees, > > > > In this script you made the assumption that the hopping sequence length i= s > equal to the number of channels. I think this is reasonable assumption bu= t > it is not defined in the IEEE802.15.4e standard, so it would be good idea > to put this assumption in the draft too. > > > > Yes, that was my assumption in this code. > > > > You are using channel numbers 0 - 15 and I assume that these are the 16 > 2.5GHz channels. The IEEE802.15.4e standard define these as channel numbe= rs > 11 - 26 of page 0. It is fine for me to keep the 0 - 15 channel numbering > scheme but it would good to mention this too. What about (future) support > of other channels and pages defined in the IEEE802.15.4e standard? > > > > Correct, you should add 11 to the channel numbers in the code to use > channel numbers 11-26 in IEEE notation (2.405GHz-2.480GHz). AFAICT, there > is nothing in the hopping sequence of IEEE802.15.4e-TSCH which prevents t= he > use of (future) sets of channels. > > > > *@all*, what do others think? Are details about the hopping sequence > something we need to add to draft-ietf-6tisch-minimal? > > > > Thomas > > > > On Mon, Nov 10, 2014 at 12:10 AM, Kees Trommel > wrote: > > Thomas, Xavi, > > Thanks, I cannot find anything in this script that would violate the > IEEE802.15.4e standard. > > In this script you made the assumption that the hopping sequence length i= s > equal to the number of channels. I think this is reasonable assumption bu= t > it is not defined in the IEEE802.15.4e standard, so it would be good idea > to put this assumption in the draft too. > > You are using channel numbers 0 - 15 and I assume that these are the 16 > 2.5GHz channels. The IEEE802.15.4e standard define these as channel numbe= rs > 11 - 26 of page 0. It is fine for me to keep the 0 - 15 channel numbering > scheme but it would good to mention this too. What about (future) support > of other channels and pages defined in the IEEE802.15.4e standard? > > Kees. > > > > On 11/10/14 00:29, Thomas Watteyne wrote: > > Kees, Xavi, > > > > If the default hopping sequence isn't clear in IEEE802.15.4e-2012, this i= s > important information to the fed back to the IEEE802.15.4 TG. *@PatKinney= *, > maybe you can chime in on whether the related text will be changed in > IEEE802.15.4-2015? > > > > In any case, let's disambiguate the hopping sequence on this thread. We > could add an example in draft-ietf-6tisch-minimal, and maybe ask > IEEE802.15.4 to do the same. > > > > I have created some quick Python code which I believe calculates the > default hopping sequence, see > https://gist.github.com/twatteyne/2e22ee3c1a802b685695. > > > > Could someone (*Pat*? *Jonathan*?) double-check that it computes the > right sequence. I'm copy-pasting the output below. > > > > Thomas > > > > --- > > > > This script calculates the default channel hopping sequence for the > > IEEE802.15.4e-2012 TSCH mode. > > > > \author Thomas Watteyne > > \date November 2014 > > \license http://opensource.org/licenses/BSD-3-Clause > > > > > > =3D=3D=3D Step a. > > > > SHUFFLE is a macHoppingSequenceLength-sized array. The contents of this > array ar > > e equivalent to the first macHoppingSequenceLength outputs of a 9-bit > linear fee > > dback shift register (LFSR) with polynomial x9 + x5 + 1 and a starting > seed of 2 > > 55. Each LFSR output is modulo macHoppingSequenceLength, so that each > entry of S > > HUFFLE is between 0 and (macHoppingSequenceLength - 1), inclusive. > > > > 5 9 > > 1 1 1 1 1 1 1 1 0 ( 255=3D=3D0x0ff=3D=3Db011111111) > > 1 1 1 1 1 1 1 1 1 ( 511=3D=3D0x1ff=3D=3Db111111111) --> 15 > > 0 1 1 1 1 1 1 1 1 ( 510=3D=3D0x1fe=3D=3Db111111110) --> 14 > > 0 0 1 1 1 1 1 1 1 ( 508=3D=3D0x1fc=3D=3Db111111100) --> 12 > > 0 0 0 1 1 1 1 1 1 ( 504=3D=3D0x1f8=3D=3Db111111000) --> 8 > > 0 0 0 0 1 1 1 1 1 ( 496=3D=3D0x1f0=3D=3Db111110000) --> 0 > > 0 0 0 0 0 1 1 1 1 ( 480=3D=3D0x1e0=3D=3Db111100000) --> 0 > > 1 0 0 0 0 0 1 1 1 ( 449=3D=3D0x1c1=3D=3Db111000001) --> 1 > > 1 1 0 0 0 0 0 1 1 ( 387=3D=3D0x183=3D=3Db110000011) --> 3 > > 1 1 1 0 0 0 0 0 1 ( 263=3D=3D0x107=3D=3Db100000111) --> 7 > > 1 1 1 1 0 0 0 0 0 ( 15=3D=3D0x00f=3D=3Db000001111) --> 15 > > 0 1 1 1 1 0 0 0 0 ( 30=3D=3D0x01e=3D=3Db000011110) --> 14 > > 1 0 1 1 1 1 0 0 0 ( 61=3D=3D0x03d=3D=3Db000111101) --> 13 > > 1 1 0 1 1 1 1 0 0 ( 123=3D=3D0x07b=3D=3Db001111011) --> 11 > > 1 1 1 0 1 1 1 1 0 ( 247=3D=3D0x0f7=3D=3Db011110111) --> 7 > > 1 1 1 1 0 1 1 1 1 ( 495=3D=3D0x1ef=3D=3Db111101111) --> 15 > > 1 1 1 1 1 0 1 1 1 ( 479=3D=3D0x1df=3D=3Db111011111) --> 15 > > > > SHUFFLE: [15, 14, 12, 8, 0, 0, 1, 3, 7, 15, 14, 13, 11, 7, 15, 15] > > > > =3D=3D=3D Step b. > > > > CHANNELS is a macHoppingSequenceLength-sized array that is initially > populated w > > ith the monotonically increasing list of channels available to the PHY. > > > > CHANNELS: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15] > > > > =3D=3D=3D Step c. > > > > CHANNELS is shuffled as per Figure 7a. Elements may wind up being swapped > multip > > le times in this process. > > > > macHoppingSequenceList: *[5, 6, 12, 7, 15, 4, 14, 11, 8, 0, 1, 2, 13, 3, > 9, 10]* > > > > > > Script ended normally, press Enter to close. > > > On Friday, November 7, 2014, Xavier Vilajosana < > xvilajosana@eecs.berkeley.edu> wrote: > > Dear Kees, > > thanks for your comments. > > > > answering 1) > > IMHO the fact that if default ch. hopping sequence is being used *may not > be* advertised in the EB it is not clear in the standard. And therefore I > opted to make the EB explicit (even only an ID and this being the default= ) > > Page 11 of the 15.4e amendment indicates that: > > > > *All hopping sequences are referred to by an ID, macHoppingSequenceID, > with ID =3D 0 denoting the default* > > *sequence for a particular PHY (or PHY configuration if the PHY supports > more than one channel list).* > > > > then page 92 > > *The full Hopping Sequence may be omitted to ensure that the frame does > not exceed aMaxPHYPacketSize.* > > *In this case only the Hopping Sequence ID is carried, and the length of > the IE is 1 octet. When the length is* > > *not equal to one, the additional fields are present. The element varies > in length depending upon the* > > *numberOfChannels in use by the PHY. The channelPage and numberOfChannels > attributes can be used to* > > *determine the size of the extendedBitmap, and the > macHoppingSequenceLength can be used to determine* > > *the size of the macHoppingSequenceList.* > > *The Channel Hopping IE may be used by any channel hopping PAN to > synchronize devices.* > > > > My last point here is that this *may* might indicate optionality but the > case for the default id is not mentioned so I am not sure it can be elide= d > if default id (0) > > > > answering 2) it seems a good point. Let us think about it. > > > > regards, > > Xavi > > > > 2014-11-07 9:57 GMT+01:00 Kees Trommel : > > Hi, > > This draft specifies that the enhanced beacon should include a Channel > Hopping IE with a Hopping Sequence ID equal to 0. Hopping Sequence ID 0 i= s > the default hopping sequence ID. So the actual hopping sequence will not = be > included in the enhanced beacon. > > Section 5.1.1a of the IEE802.25.4e standard defines an algorithm to > calculate a default hopping sequence ID. > > I have the following questions regarding the default hopping sequence: > > 1. Is it the intention that a minimal configuration uses the default > hopping sequence as defined in the IEE802.25.4e standard? > 2. If the answer on 1. is yes: The definition of the IEE802.25.4e hoppin= g > sequence (in my opinion) is not unambiguous, so can you add the actual > default hopping sequence to this draft? > > Regards, > > Kees. > > On Oct 27, 2014, at 12:20 AM, Xavier Vilajosana eecs.berkeley.edu> wrote: > > > All, I just published the new version of minimal. It includes a > security section as discussed last call and some changes to the default > timing to be according to 15.4 tsch default values. > > > > regards, > Xavi > > > > ---------- Forwarded message ---------- > From: > Date: 2014-10-27 5:17 GMT+01:00 > Subject: [6tisch] I-D Action: draft-ietf-6tisch-minimal-03.txt > To: i-d-announce at ietf.org > Cc: 6tisch at ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IPv6 over the TSCH mode of IEEE > 802.15.4e Working Group of the IETF. > > Title : Minimal 6TiSCH Configuration > Authors : Xavier Vilajosana > Kris Pister > Filename : draft-ietf-6tisch-minimal-03.txt > Pages : 22 > Date : 2014-10-26 > > Abstract: > This document describes the minimal set of rules to operate a > [IEEE802154e] Timeslotted Channel Hopping (TSCH) network. This > minimal mode of operation can be used during network bootstrap, as a > fall-back mode of operation when no dynamic scheduling solution is > available or functioning, or during early interoperability testing > and development. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-6tisch-minimal-03 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6tisch-minimal-03 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > 6tisch mailing list > 6tisch at ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > > > > _______________________________________________ > 6tisch mailing list > 6tisch at ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > > > > > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > 6tisch mailing list > > 6tisch@ietf.org > > https://www.ietf.org/mailman/listinfo/6tisch > > > > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > > --f46d04428f5668a69605079a893a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Hi,

    I'll wait for others opinion an= d I'll add it to the draft.

    regards,
    Xavi

    2014-11= -11 19:21 GMT+01:00 Pascal Thubert (pthubert) <pthubert@cisco.com>= :

    I=E2=80=99m all for it : = )

    =C2=A0

    Cheers,

    =C2=A0=

    Pascal=

    =C2=A0

    From: 6tisch [mailto:6tisch-bounces@ietf.org] On Behalf Of Kris Pister
    Sent: mardi 11 novembre 2014 08:31
    To: 6tisch@ietf= .org


    Subject: Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-03.txt

    =C2=A0

    Given the rather obsc= ure way that the default sequence is calculated, and
    the readability of IEEE standards, it seems like a good idea to explicitly = include
    the default hop sequence in the minimal draft.=C2=A0 How about the followin= g modification
    to section 4.3.2 of the draft:
    After the line "Channel Hopping Template ID (b0-b7) =3D 0x00" add=

    The default sequence for the 2.4GHz OQPSK PHY is
    [5, 6, 12, 7, 15, 4, 14, 11, 8, 0, 1, 2, 13, 3, 9, 10]
    per section 5.1.1a of [IEEE802154e].

    ksjp

    p.s. Thomas, I'm trusting that your python code is correct - I didn'= ;t check.

    On 11/11/2014 7:50 AM, Maria Rita PALATTELLA wrote:<= u>

    Thomas, Xavi,

    I do agree we should add = the conceptual explanation of the default channel hopping sequence in the t= sch draft, given that the draft is a sort of guidelines about how tsch works.

    and at the same time we s= hould =C2=A0mention it in minimal draft and provide an example.

    Maria Rita<= u>

    =C2=A0

    From: 6tisch [= mailto:6tisch-= bounces@ietf.org] On Behalf Of Thomas Watteyne
    Sent: Tuesday, November 11, 2014 5:24 AM
    To: Xavier Vilajosana
    Cc: Kees Trommel; Pascal Thubert (pthubert); 6tisch@ietf.org
    Subject: Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-03.txt

    =C2=A0

    Xavi, thanks for your comments. What do others think= ?

    =C2=A0

    On Mon, Nov 10, 2014 at 6:18 PM, Xavier Vilajosana &= lt;xvila= josana@eecs.berkeley.edu> wrote:

    Hi,=C2=A0

    =C2=A0

    Thomas convinced me. As it is something 15.4 TSCH sp= ecific it seems reasonable to have it at the tsch draft and indicate the us= e of the default channel hopping sequence in minimal. Minimal won't be = self-contained but it is not alreday.

    =C2=A0

    regards,
    Xavi

    =C2=A0

    2014-11-11 1:53 GMT+01:00 Thomas Watteyne <watteyne@eecs.ber= keley.edu>:

    Pascal,

    =C2=A0

    draft-ietf-6tisch-minimal should contain that it req= uires the default channel hopping pattern. I think we agree on that.=

    =C2=A0

    The description of what the default channel hopping = pattern is (this is just a discussion about IEEE802.15.4e-2012, nothing 6Ti= SCH specific), might end up in=C2=A06tisch/draft-ietf-6tisch-tsch.

    =C2=A0

    What do others think?

    =C2=A0

    Thomas

    =C2=A0

    =C2=A0

    =C2=A0

    On Mon, Nov 10, 2014 at 10:57 AM, Pascal Thubert (pt= hubert) <pthuber= t@cisco.com> wrote:

    Hi Thomas:<= u>

    =C2=A0

    I think:

    - that the TSCH draft cou= ld discuss what is sub-defined in TSCH, indicate that we use the range 0-15= , to address Kees=E2=80=99 points

    - but then, the setting t= o be used in minimal, and pseudo code along the lines you produced should go in minimal to ensure interop. The pseudo code would be an appendix.

    =C2=A0

    Makes sense?

    =C2=A0

    Pascal

    =C2=A0

    From: 6tisch [= mailto:6tisch-= bounces@ietf.org] On Behalf Of Thomas Watteyne
    Sent: lundi 10 novembre 2014 12:17
    To: Xavier Vilajosana
    Cc: Kees Trommel; 6tisch@ietf.org
    Subject: Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-03.txt

    =C2=A0

    Quick thought: does this discussion fit in=C2=A0draf= t-ietf-6tisch-minimal or draft-ietf-6tisch-tsch? Both make sense to me.<= /u>

    =C2=A0

    On Mon, Nov 10, 2014 at 10:15 AM, Xavier Vilajosana = <xvil= ajosana@eecs.berkeley.edu> wrote:

    Hi,=C2=A0

    =C2=A0

    my 5 cents. After thinking about it I am in favour o= f adding the example as the draft will be more self-contained and will faci= litate the understanding of how ch. hopping sequence is caluclated. (analogously to the OF0 example).=C2=A0

    =C2=A0

    regards,

    Xavi

    =C2=A0

    2014-11-10 19:41 GMT+01:00 Thomas Watteyne <watteyne@eecs.be= rkeley.edu>:

    Kees,

    =C2=A0

    In this script you made the assumption that the hopp= ing sequence length is equal to the number of channels. I think this is rea= sonable assumption but it is not defined in the IEEE802.15.4e standard, so it would be good idea to put this assumption in the draft too= .

    =C2=A0

    Yes, that was my assumption in this code.<= /u>

    =C2=A0

    You are using channel numbers 0 - 15 and I assume th= at these are the 16 2.5GHz channels. The IEEE802.15.4e standard define thes= e as channel numbers 11 - 26 of page 0. It is fine for me to keep the 0 - 15 channel numbering scheme but it would good to me= ntion this too. What about (future) support of other channels and pages def= ined in the IEEE802.15.4e standard?

    =C2=A0

    Correct, you should add 11 to the channel numbers in= the code to use channel numbers 11-26 in IEEE notation (2.405GHz-2.480GHz)= . AFAICT, there is nothing in the hopping sequence of IEEE802.15.4e-TSCH which prevents the use of (future) sets of channels.=

    =C2=A0

    @all, what do others think? Are details about= the hopping sequence something we need to add to draft-ietf-6tisch-minimal= ?

    =C2=A0

    Thomas

    =C2=A0

    On Mon, Nov 10, 2014 at 12:10 AM, Kees Trommel <<= a href=3D"mailto:ctrommel@aimvalley.nl" target=3D"_blank">ctrommel@aimvalle= y.nl> wrote:

    Thomas, Xavi,

    Thanks, I cannot find anything in this script that would violate the IEEE80= 2.15.4e standard.

    In this script you made the assumption that the hopping sequence length is = equal to the number of channels. I think this is reasonable assumption but = it is not defined in the IEEE802.15.4e standard, so it would be good idea t= o put this assumption in the draft too.

    You are using channel numbers 0 - 15 and I assume that these are the 16 2.5= GHz channels. The IEEE802.15.4e standard define these as channel numbers 11= - 26 of page 0. It is fine for me to keep the 0 - 15 channel numbering sch= eme but it would good to mention this too. What about (future) support of other channels and pages defined = in the IEEE802.15.4e standard?

    Kees.



    On 11/10/14 00:29, Thomas Watteyne wrote:

    Kees, Xavi,

    =C2=A0

    If the default hopping sequence isn't clear in I= EEE802.15.4e-2012, this is important information to the fed back to the IEE= E802.15.4 TG. @PatKinney, maybe you can chime in on whether the related text will = be changed in IEEE802.15.4-2015?

    =C2=A0

    In any case, let's disambiguate the hopping sequ= ence on this thread. We could add an example in draft-ietf-6tisch-minimal, = and maybe ask IEEE802.15.4 to do the same.

    =C2=A0

    I have created some quick Python code which I believ= e calculates the default hopping sequence, see https://gist.github.com/twatteyne/2e22ee3c1a802b685695.

    =C2=A0

    Could someone (Pat? Jonathan?) double-check that it computes the right sequence. I'm copy-pasting the output below.

    =C2=A0

    Thomas

    =C2=A0

    ---

    =C2=A0

    This script calculates the default channel hopping sequen= ce for the

    IEEE802.15.4e-2012 TSCH mode.

    =C2=A0

    \author Thomas Watteyne

    \date November 2014

    =C2=A0

    =C2=A0

    =3D=3D=3D Step a.

    =C2=A0

    SHUFFLE is a macHoppingSequenceLength-sized array. The co= ntents of this array ar

    e equivalent to the first macHoppingSequenceLength output= s of a 9-bit linear fee

    dback shift register (LFSR) with polynomial x9 + x5 + 1 a= nd a starting seed of 2

    55. Each LFSR output is modulo macHoppingSequenceLength, = so that each entry of S

    HUFFLE is between 0 and (macHoppingSequenceLength - 1), i= nclusive.

    =C2=A0

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A05 =C2=A0 =C2=A0 = =C2=A0 9

    =C2=A0 =C2=A01 1 1 1 1 1 1 1 0 ( 255=3D=3D0x0ff=3D=3Db011= 111111)

    =C2=A0 =C2=A01 1 1 1 1 1 1 1 1 ( 511=3D=3D0x1ff=3D=3Db111= 111111) --> 15

    =C2=A0 =C2=A00 1 1 1 1 1 1 1 1 ( 510=3D=3D0x1fe=3D=3Db111= 111110) --> 14

    =C2=A0 =C2=A00 0 1 1 1 1 1 1 1 ( 508=3D=3D0x1fc=3D=3Db111= 111100) --> 12

    =C2=A0 =C2=A00 0 0 1 1 1 1 1 1 ( 504=3D=3D0x1f8=3D=3Db111= 111000) --> 8

    =C2=A0 =C2=A00 0 0 0 1 1 1 1 1 ( 496=3D=3D0x1f0=3D=3Db111= 110000) --> 0

    =C2=A0 =C2=A00 0 0 0 0 1 1 1 1 ( 480=3D=3D0x1e0=3D=3Db111= 100000) --> 0

    =C2=A0 =C2=A01 0 0 0 0 0 1 1 1 ( 449=3D=3D0x1c1=3D=3Db111= 000001) --> 1

    =C2=A0 =C2=A01 1 0 0 0 0 0 1 1 ( 387=3D=3D0x183=3D=3Db110= 000011) --> 3

    =C2=A0 =C2=A01 1 1 0 0 0 0 0 1 ( 263=3D=3D0x107=3D=3Db100= 000111) --> 7

    =C2=A0 =C2=A01 1 1 1 0 0 0 0 0 ( =C2=A015=3D=3D0x00f=3D= =3Db000001111) --> 15

    =C2=A0 =C2=A00 1 1 1 1 0 0 0 0 ( =C2=A030=3D=3D0x01e=3D= =3Db000011110) --> 14

    =C2=A0 =C2=A01 0 1 1 1 1 0 0 0 ( =C2=A061=3D=3D0x03d=3D= =3Db000111101) --> 13

    =C2=A0 =C2=A01 1 0 1 1 1 1 0 0 ( 123=3D=3D0x07b=3D=3Db001= 111011) --> 11

    =C2=A0 =C2=A01 1 1 0 1 1 1 1 0 ( 247=3D=3D0x0f7=3D=3Db011= 110111) --> 7

    =C2=A0 =C2=A01 1 1 1 0 1 1 1 1 ( 495=3D=3D0x1ef=3D=3Db111= 101111) --> 15

    =C2=A0 =C2=A01 1 1 1 1 0 1 1 1 ( 479=3D=3D0x1df=3D=3Db111= 011111) --> 15

    =C2=A0

    SHUFFLE: =C2=A0[15, 14, 12, 8, 0, 0, 1, 3, 7, 15, 14, 13,= 11, 7, 15, 15]

    =C2=A0

    =3D=3D=3D Step b.

    =C2=A0

    CHANNELS is a macHoppingSequenceLength-sized array that i= s initially populated w

    ith the monotonically increasing list of channels availab= le to the PHY.

    =C2=A0

    CHANNELS: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, = 14, 15]

    =C2=A0

    =3D=3D=3D Step c.

    =C2=A0

    CHANNELS is shuffled as per Figure 7a. Elements may wind = up being swapped multip

    le times in this process.

    =C2=A0

    macHoppingSequenceList: [5, 6, 12, 7, 15, 4, 14, 11, 8, 0, 1, 2, = 13, 3, 9, 10]

    =C2=A0

    =C2=A0

    Script ended normally, press Enter to close.


    On Friday, November 7, 2014, Xavier Vilajosana <xvilajosana@eecs.berkeley.edu> wrote:

    Dear Kees,

    thanks for your comments.=C2=A0

    =C2=A0

    answering 1)

    IMHO the fact that if default ch. hopping sequence i= s being used may not be advertised in the EB it is not clear in the standard. And= therefore I opted to make the EB explicit (even only an ID and this being = the default)

    Page 11 of the 15.4e amendment indicates that:

    =C2=A0

    All hopping sequences are referred to by an ID, m= acHoppingSequenceID, with ID =3D 0 denoting the default

    sequence for a particular PHY (or PHY configurati= on if the PHY supports more than one channel list).

    =C2=A0

    then page 92

    The full Hopping Sequence may be omitted to ensur= e that the frame does not exceed aMaxPHYPacketSize.

    In this case only the Hopping Sequence ID is carr= ied, and the length of the IE is 1 octet. When the length is<= /u>

    not equal to one, the additional fields are prese= nt. The element varies in length depending upon the

    numberOfChannels in use by the PHY. The channelPa= ge and numberOfChannels attributes can be used to

    determine the size of the extendedBitmap, and the= macHoppingSequenceLength can be used to determine

    the size of the macHoppingSequenceList.

    The Channel Hopping IE may be used by any channel hopping PAN to synchronize devices.

    =C2=A0

    My last point here is that this may=C2=A0might indicate optionality but the case for the default id = is not mentioned so I am not sure it can be elided if default id (0)=

    =C2=A0

    answering 2) it seems a good point. Let us think abo= ut it.

    =C2=A0

    regards,

    Xavi

    =C2=A0

    Hi,

    All, I just published the new version of minimal. It= includes a security section as discussed last call and some changes to the= default timing to be according to 15.4 tsch default values.

    =C2=A0

    regards,
    Xavi

    =C2=A0

    ---------- Forwarded message ----------
    From: <internet-drafts at = ietf.org>
    Date: 2014-10-27 5:17 GMT+01:00
    Subject: [6tisch] I-D Action: draft-ietf-6tisch-minimal-03.txt
    To: i-d-announce at ietf.org<= /a>
    Cc: 6tisch at
    ietf.org


    A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
    =C2=A0This draft is a work item of the IPv6 over the TSCH mode of IEEE 802.= 15.4e Working Group of the IETF.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Minimal 6TiSCH Configuration
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Xavi= er Vilajosana
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Kris Pister
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-6tisch-minimal-03.txt
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 22
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2014-10-26

    Abstract:
    =C2=A0 =C2=A0This document describes the minimal set of rules to operate a<= br> =C2=A0 =C2=A0[IEEE802154e] Timeslotted Channel Hopping (TSCH) network.=C2= =A0 This
    =C2=A0 =C2=A0minimal mode of operation can be used during network bootstrap= , as a
    =C2=A0 =C2=A0fall-back mode of operation when no dynamic scheduling solutio= n is
    =C2=A0 =C2=A0available or functioning, or during early interoperability tes= ting
    =C2=A0 =C2=A0and development.


    The IETF datatracker status page for this draft is:
    https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal/<= /a>

    There's also a htmlized version available at:
    http://tools.ietf.org/html/draft-ietf-6tisch-minimal-03

    A diff from the previous version is available at:
    http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6tisch-min= imal-03


    Please note that it may take a couple of minutes from the time of submissio= n
    until the htmlized version and diff are available at tools.ietf.org.

    Internet-Drafts are also available by anonymous FTP at:
    ftp://ftp= .ietf.org/internet-drafts/

    _______________________________________________
    6tisch mailing list
    6tisch at ietf.org
    = https://www.ietf.org/mailman/listinfo/6tisch

    =C2=A0

    _______________________________________________
    6tisch mailing list
    6tisch at ietf.org
    = https://www.ietf.org/mailman/listinfo/6tisch

    =C2=A0


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

    =C2=A0

    =C2=A0

    =C2=A0

    =C2=A0

    =C2=A0

    =C2=A0

    =C2=A0

    =C2=A0




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

    =C2=A0


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


    --f46d04428f5668a69605079a893a-- From nobody Tue Nov 11 11:49:05 2014 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C70A41A8911 for <6tisch@ietfa.amsl.com>; Tue, 11 Nov 2014 11:49:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7jdtDH1CfV4n for <6tisch@ietfa.amsl.com>; Tue, 11 Nov 2014 11:48:56 -0800 (PST) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE4E51A8903 for <6tisch@ietf.org>; Tue, 11 Nov 2014 11:48:47 -0800 (PST) Received: by mail-wg0-f47.google.com with SMTP id a1so12250288wgh.6 for <6tisch@ietf.org>; Tue, 11 Nov 2014 11:48:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mhYEK2vbMKZ6zgHgU0CD7PfbdinHmhW7LLs9MDHKw8E=; b=FbXGd6QVR8KHkAlhPah3OhvmTJ70B0FRd17aPdGdWU8hSj+R0ztEiWXIxb/Stp/nYC /nF7PAR0R68cUQgcnC+SvM9URHuXq3ISZ9Oj203lN/W/t55OQvTuTYU252tTpGFN0JDT YBS4/6yU4HborV90/ylsFRViUpW7gsyxqvhb5F1iXUxUYfYl1s9gM9yBo4HouUzBCAWY fRrevOeNS+8JiYOlqtwBFMNwizu01am2s3VhtnDZgJxG+bqRAVHj1zWrtMzTNcuxQCSU 7DrwrOKNvAaUD0TZSTblEAyk7Uzmlpuhb5QU7EOSHkrXIepZjZRH3kTwkQhNUZyJw+Xd glhQ== X-Received: by 10.180.85.6 with SMTP id d6mr44175897wiz.82.1415735326550; Tue, 11 Nov 2014 11:48:46 -0800 (PST) Received: from mbp-di-luigi.homenet.telecomitalia.it ([95.235.74.231]) by mx.google.com with ESMTPSA id a8sm18745993wiz.21.2014.11.11.11.48.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 11 Nov 2014 11:48:45 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alfredo Grieco In-Reply-To: Date: Tue, 11 Nov 2014 20:48:12 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <545C898A.8060300@aimvalley.nl> <54608F2A.7090708@aimvalley.nl> <546239D7.7090403@berkeley.edu> To: Xavier Vilajosana X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch/ajhSs-JLDKc33tsZLHLjl6Fgho4 Cc: Kris Pister , "Pascal Thubert \(pthubert\)" , "6tisch@ietf.org" <6tisch@ietf.org> Subject: Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-03.txt X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 19:49:03 -0000 +1. cheers. Al Il giorno 11/nov/2014, alle ore 20:46, Xavier Vilajosana = ha scritto: > Hi, >=20 > I'll wait for others opinion and I'll add it to the draft. >=20 > regards, > Xavi >=20 > 2014-11-11 19:21 GMT+01:00 Pascal Thubert (pthubert) = : > I=92m all for it : ) >=20 > =20 >=20 > Cheers, >=20 > =20 >=20 > Pascal >=20 > =20 >=20 > From: 6tisch [mailto:6tisch-bounces@ietf.org] On Behalf Of Kris Pister > Sent: mardi 11 novembre 2014 08:31 > To: 6tisch@ietf.org >=20 >=20 > Subject: Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-03.txt >=20 > =20 >=20 > Given the rather obscure way that the default sequence is calculated, = and=20 > the readability of IEEE standards, it seems like a good idea to = explicitly include > the default hop sequence in the minimal draft. How about the = following modification > to section 4.3.2 of the draft: > After the line "Channel Hopping Template ID (b0-b7) =3D 0x00" add >=20 > The default sequence for the 2.4GHz OQPSK PHY is=20 > [5, 6, 12, 7, 15, 4, 14, 11, 8, 0, 1, 2, 13, 3, 9, 10]=20 > per section 5.1.1a of [IEEE802154e]. >=20 > ksjp >=20 > p.s. Thomas, I'm trusting that your python code is correct - I didn't = check. >=20 > On 11/11/2014 7:50 AM, Maria Rita PALATTELLA wrote: >=20 > Thomas, Xavi, >=20 > I do agree we should add the conceptual explanation of the default = channel hopping sequence in the tsch draft, given that the draft is a = sort of guidelines about how tsch works. >=20 > and at the same time we should mention it in minimal draft and = provide an example. >=20 > Maria Rita >=20 > =20 >=20 > From: 6tisch [mailto:6tisch-bounces@ietf.org] On Behalf Of Thomas = Watteyne > Sent: Tuesday, November 11, 2014 5:24 AM > To: Xavier Vilajosana > Cc: Kees Trommel; Pascal Thubert (pthubert); 6tisch@ietf.org > Subject: Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-03.txt >=20 > =20 >=20 > Xavi, thanks for your comments. What do others think? >=20 > =20 >=20 > On Mon, Nov 10, 2014 at 6:18 PM, Xavier Vilajosana = wrote: >=20 > Hi,=20 >=20 > =20 >=20 > Thomas convinced me. As it is something 15.4 TSCH specific it seems = reasonable to have it at the tsch draft and indicate the use of the = default channel hopping sequence in minimal. Minimal won't be = self-contained but it is not alreday. >=20 > =20 >=20 > regards, > Xavi >=20 > =20 >=20 > 2014-11-11 1:53 GMT+01:00 Thomas Watteyne = : >=20 > Pascal, >=20 > =20 >=20 > draft-ietf-6tisch-minimal should contain that it requires the default = channel hopping pattern. I think we agree on that. >=20 > =20 >=20 > The description of what the default channel hopping pattern is (this = is just a discussion about IEEE802.15.4e-2012, nothing 6TiSCH specific), = might end up in 6tisch/draft-ietf-6tisch-tsch. >=20 > =20 >=20 > What do others think? >=20 > =20 >=20 > Thomas >=20 > =20 >=20 > =20 >=20 > =20 >=20 > On Mon, Nov 10, 2014 at 10:57 AM, Pascal Thubert (pthubert) = wrote: >=20 > Hi Thomas: >=20 > =20 >=20 > I think: >=20 > - that the TSCH draft could discuss what is sub-defined in TSCH, = indicate that we use the range 0-15, to address Kees=92 points >=20 > - but then, the setting to be used in minimal, and pseudo code along = the lines you produced should go in minimal to ensure interop. The = pseudo code would be an appendix. >=20 > =20 >=20 > Makes sense? >=20 > =20 >=20 > Pascal >=20 > =20 >=20 > From: 6tisch [mailto:6tisch-bounces@ietf.org] On Behalf Of Thomas = Watteyne > Sent: lundi 10 novembre 2014 12:17 > To: Xavier Vilajosana > Cc: Kees Trommel; 6tisch@ietf.org > Subject: Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-03.txt >=20 > =20 >=20 > Quick thought: does this discussion fit in draft-ietf-6tisch-minimal = or draft-ietf-6tisch-tsch? Both make sense to me. >=20 > =20 >=20 > On Mon, Nov 10, 2014 at 10:15 AM, Xavier Vilajosana = wrote: >=20 > Hi,=20 >=20 > =20 >=20 > my 5 cents. After thinking about it I am in favour of adding the = example as the draft will be more self-contained and will facilitate the = understanding of how ch. hopping sequence is caluclated. (analogously to = the OF0 example).=20 >=20 > =20 >=20 > regards, >=20 > Xavi >=20 > =20 >=20 > 2014-11-10 19:41 GMT+01:00 Thomas Watteyne = : >=20 > Kees, >=20 > =20 >=20 > In this script you made the assumption that the hopping sequence = length is equal to the number of channels. I think this is reasonable = assumption but it is not defined in the IEEE802.15.4e standard, so it = would be good idea to put this assumption in the draft too. >=20 > =20 >=20 > Yes, that was my assumption in this code. >=20 > =20 >=20 > You are using channel numbers 0 - 15 and I assume that these are the = 16 2.5GHz channels. The IEEE802.15.4e standard define these as channel = numbers 11 - 26 of page 0. It is fine for me to keep the 0 - 15 channel = numbering scheme but it would good to mention this too. What about = (future) support of other channels and pages defined in the = IEEE802.15.4e standard? >=20 > =20 >=20 > Correct, you should add 11 to the channel numbers in the code to use = channel numbers 11-26 in IEEE notation (2.405GHz-2.480GHz). AFAICT, = there is nothing in the hopping sequence of IEEE802.15.4e-TSCH which = prevents the use of (future) sets of channels. >=20 > =20 >=20 > @all, what do others think? Are details about the hopping sequence = something we need to add to draft-ietf-6tisch-minimal? >=20 > =20 >=20 > Thomas >=20 > =20 >=20 > On Mon, Nov 10, 2014 at 12:10 AM, Kees Trommel = wrote: >=20 > Thomas, Xavi, >=20 > Thanks, I cannot find anything in this script that would violate the = IEEE802.15.4e standard. >=20 > In this script you made the assumption that the hopping sequence = length is equal to the number of channels. I think this is reasonable = assumption but it is not defined in the IEEE802.15.4e standard, so it = would be good idea to put this assumption in the draft too. >=20 > You are using channel numbers 0 - 15 and I assume that these are the = 16 2.5GHz channels. The IEEE802.15.4e standard define these as channel = numbers 11 - 26 of page 0. It is fine for me to keep the 0 - 15 channel = numbering scheme but it would good to mention this too. What about = (future) support of other channels and pages defined in the = IEEE802.15.4e standard? >=20 > Kees. >=20 >=20 >=20 > On 11/10/14 00:29, Thomas Watteyne wrote: >=20 > Kees, Xavi, >=20 > =20 >=20 > If the default hopping sequence isn't clear in IEEE802.15.4e-2012, = this is important information to the fed back to the IEEE802.15.4 TG. = @PatKinney, maybe you can chime in on whether the related text will be = changed in IEEE802.15.4-2015? >=20 > =20 >=20 > In any case, let's disambiguate the hopping sequence on this thread. = We could add an example in draft-ietf-6tisch-minimal, and maybe ask = IEEE802.15.4 to do the same. >=20 > =20 >=20 > I have created some quick Python code which I believe calculates the = default hopping sequence, see = https://gist.github.com/twatteyne/2e22ee3c1a802b685695. >=20 > =20 >=20 > Could someone (Pat? Jonathan?) double-check that it computes the right = sequence. I'm copy-pasting the output below. >=20 > =20 >=20 > Thomas >=20 > =20 >=20 > --- >=20 > =20 >=20 > This script calculates the default channel hopping sequence for the >=20 > IEEE802.15.4e-2012 TSCH mode. >=20 > =20 >=20 > \author Thomas Watteyne >=20 > \date November 2014 >=20 > \license http://opensource.org/licenses/BSD-3-Clause >=20 > =20 >=20 > =20 >=20 > =3D=3D=3D Step a. >=20 > =20 >=20 > SHUFFLE is a macHoppingSequenceLength-sized array. The contents of = this array ar >=20 > e equivalent to the first macHoppingSequenceLength outputs of a 9-bit = linear fee >=20 > dback shift register (LFSR) with polynomial x9 + x5 + 1 and a starting = seed of 2 >=20 > 55. Each LFSR output is modulo macHoppingSequenceLength, so that each = entry of S >=20 > HUFFLE is between 0 and (macHoppingSequenceLength - 1), inclusive. >=20 > =20 >=20 > 5 9 >=20 > 1 1 1 1 1 1 1 1 0 ( 255=3D=3D0x0ff=3D=3Db011111111) >=20 > 1 1 1 1 1 1 1 1 1 ( 511=3D=3D0x1ff=3D=3Db111111111) --> 15 >=20 > 0 1 1 1 1 1 1 1 1 ( 510=3D=3D0x1fe=3D=3Db111111110) --> 14 >=20 > 0 0 1 1 1 1 1 1 1 ( 508=3D=3D0x1fc=3D=3Db111111100) --> 12 >=20 > 0 0 0 1 1 1 1 1 1 ( 504=3D=3D0x1f8=3D=3Db111111000) --> 8 >=20 > 0 0 0 0 1 1 1 1 1 ( 496=3D=3D0x1f0=3D=3Db111110000) --> 0 >=20 > 0 0 0 0 0 1 1 1 1 ( 480=3D=3D0x1e0=3D=3Db111100000) --> 0 >=20 > 1 0 0 0 0 0 1 1 1 ( 449=3D=3D0x1c1=3D=3Db111000001) --> 1 >=20 > 1 1 0 0 0 0 0 1 1 ( 387=3D=3D0x183=3D=3Db110000011) --> 3 >=20 > 1 1 1 0 0 0 0 0 1 ( 263=3D=3D0x107=3D=3Db100000111) --> 7 >=20 > 1 1 1 1 0 0 0 0 0 ( 15=3D=3D0x00f=3D=3Db000001111) --> 15 >=20 > 0 1 1 1 1 0 0 0 0 ( 30=3D=3D0x01e=3D=3Db000011110) --> 14 >=20 > 1 0 1 1 1 1 0 0 0 ( 61=3D=3D0x03d=3D=3Db000111101) --> 13 >=20 > 1 1 0 1 1 1 1 0 0 ( 123=3D=3D0x07b=3D=3Db001111011) --> 11 >=20 > 1 1 1 0 1 1 1 1 0 ( 247=3D=3D0x0f7=3D=3Db011110111) --> 7 >=20 > 1 1 1 1 0 1 1 1 1 ( 495=3D=3D0x1ef=3D=3Db111101111) --> 15 >=20 > 1 1 1 1 1 0 1 1 1 ( 479=3D=3D0x1df=3D=3Db111011111) --> 15 >=20 > =20 >=20 > SHUFFLE: [15, 14, 12, 8, 0, 0, 1, 3, 7, 15, 14, 13, 11, 7, 15, 15] >=20 > =20 >=20 > =3D=3D=3D Step b. >=20 > =20 >=20 > CHANNELS is a macHoppingSequenceLength-sized array that is initially = populated w >=20 > ith the monotonically increasing list of channels available to the = PHY. >=20 > =20 >=20 > CHANNELS: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15] >=20 > =20 >=20 > =3D=3D=3D Step c. >=20 > =20 >=20 > CHANNELS is shuffled as per Figure 7a. Elements may wind up being = swapped multip >=20 > le times in this process. >=20 > =20 >=20 > macHoppingSequenceList: [5, 6, 12, 7, 15, 4, 14, 11, 8, 0, 1, 2, 13, = 3, 9, 10] >=20 > =20 >=20 > =20 >=20 > Script ended normally, press Enter to close. >=20 >=20 > On Friday, November 7, 2014, Xavier Vilajosana = wrote: >=20 > Dear Kees, >=20 > thanks for your comments.=20 >=20 > =20 >=20 > answering 1) >=20 > IMHO the fact that if default ch. hopping sequence is being used may = not be advertised in the EB it is not clear in the standard. And = therefore I opted to make the EB explicit (even only an ID and this = being the default) >=20 > Page 11 of the 15.4e amendment indicates that: >=20 > =20 >=20 > All hopping sequences are referred to by an ID, macHoppingSequenceID, = with ID =3D 0 denoting the default >=20 > sequence for a particular PHY (or PHY configuration if the PHY = supports more than one channel list). >=20 > =20 >=20 > then page 92 >=20 > The full Hopping Sequence may be omitted to ensure that the frame does = not exceed aMaxPHYPacketSize. >=20 > In this case only the Hopping Sequence ID is carried, and the length = of the IE is 1 octet. When the length is >=20 > not equal to one, the additional fields are present. The element = varies in length depending upon the >=20 > numberOfChannels in use by the PHY. The channelPage and = numberOfChannels attributes can be used to >=20 > determine the size of the extendedBitmap, and the = macHoppingSequenceLength can be used to determine >=20 > the size of the macHoppingSequenceList. >=20 > The Channel Hopping IE may be used by any channel hopping PAN to = synchronize devices. >=20 > =20 >=20 > My last point here is that this may might indicate optionality but the = case for the default id is not mentioned so I am not sure it can be = elided if default id (0) >=20 > =20 >=20 > answering 2) it seems a good point. Let us think about it. >=20 > =20 >=20 > regards, >=20 > Xavi >=20 > =20 >=20 > 2014-11-07 9:57 GMT+01:00 Kees Trommel : >=20 > Hi, >=20 >=20 > This draft specifies that the enhanced beacon should include a Channel = Hopping IE with a Hopping Sequence ID equal to 0. Hopping Sequence ID 0 = is the default hopping sequence ID. So the actual hopping sequence will = not be included in the enhanced beacon. >=20 > Section 5.1.1a of the IEE802.25.4e standard defines an algorithm to = calculate a default hopping sequence ID.=20 >=20 > I have the following questions regarding the default hopping sequence: >=20 > 1. Is it the intention that a minimal configuration uses the default = hopping sequence as defined in the IEE802.25.4e standard? > 2. If the answer on 1. is yes: The definition of the IEE802.25.4e = hopping sequence (in my opinion) is not unambiguous, so can you add the = actual default hopping sequence to this draft? >=20 > Regards, >=20 > Kees. >=20 > On Oct 27, 2014, at 12:20 AM, Xavier Vilajosana wrote: >=20 >=20 >=20 > All, I just published the new version of minimal. It includes a = security section as discussed last call and some changes to the default = timing to be according to 15.4 tsch default values. >=20 > =20 >=20 > regards, > Xavi >=20 > =20 >=20 > ---------- Forwarded message ---------- > From: > Date: 2014-10-27 5:17 GMT+01:00 > Subject: [6tisch] I-D Action: draft-ietf-6tisch-minimal-03.txt > To: i-d-announce at ietf.org > Cc: 6tisch at ietf.org >=20 >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the IPv6 over the TSCH mode of IEEE = 802.15.4e Working Group of the IETF. >=20 > Title : Minimal 6TiSCH Configuration > Authors : Xavier Vilajosana > Kris Pister > Filename : draft-ietf-6tisch-minimal-03.txt > Pages : 22 > Date : 2014-10-26 >=20 > Abstract: > This document describes the minimal set of rules to operate a > [IEEE802154e] Timeslotted Channel Hopping (TSCH) network. This > minimal mode of operation can be used during network bootstrap, as = a > fall-back mode of operation when no dynamic scheduling solution is > available or functioning, or during early interoperability testing > and development. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-6tisch-minimal-03 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6tisch-minimal-03 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > 6tisch mailing list > 6tisch at ietf.org > https://www.ietf.org/mailman/listinfo/6tisch >=20 > =20 >=20 > _______________________________________________ > 6tisch mailing list > 6tisch at ietf.org > https://www.ietf.org/mailman/listinfo/6tisch >=20 > =20 >=20 >=20 > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch >=20 > =20 >=20 > =20 >=20 > =20 >=20 > =20 >=20 > =20 >=20 > =20 >=20 > =20 >=20 > =20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > =20 >=20 >=20 > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch >=20 >=20 > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch --=20 Luigi Alfredo Grieco, PhD=20 Associate Professor Dep. of Electrical and Information Engineering (DEI) Politecnico di Bari Via Orabona, 4 70125 - Bari - Italy Phone: +39 080 5963 911 url: telematics.poliba.it mail: alfredo.grieco@poliba.it From nobody Tue Nov 11 12:31:12 2014 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 460771A2119 for <6tisch@ietfa.amsl.com>; Tue, 11 Nov 2014 12:31:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5rOhUpZDXnyG for <6tisch@ietfa.amsl.com>; Tue, 11 Nov 2014 12:31:09 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF4271A1AB7 for <6tisch@ietf.org>; Tue, 11 Nov 2014 12:31:08 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 94A6120098; Tue, 11 Nov 2014 15:33:12 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 44AD9637F4; Tue, 11 Nov 2014 15:31:08 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 2C857637EA; Tue, 11 Nov 2014 15:31:08 -0500 (EST) From: Michael Richardson To: "Raghuram Sudhaakar \(rsudhaak\)" , "6tisch\@ietf.org" <6tisch@ietf.org> In-Reply-To: References: X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch/MnJyjm8AFhafQkDLLn86GizbU1M Subject: Re: [6tisch] CoAP resource management - draft-ietf-6tisch-coap-02 X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 20:31:10 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Raghuram Sudhaakar (rsudhaak) wrote: > The third and most important discussion was - 3. How do nodes exchange > the version data (with PCE and other nodes) of nodes so a network of > heterogenous nodes (w.r.t version) can interoperate. 1. Proposal - u= se > the joining flows defined in draft-richardson-6tisch--security-6top-03 > Comments and suggestions on this proposal are requested. I don't understand why you talk about "version data"? How are the nodes heterogenous? I suspect that I might be suffering from unshared terminology here. =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVGJyCYCLcPvd0N1lAQLdMwgAhGikQt/+KCjfIh57iKjL+tislTiGdO3B 872QbGpVaMS9iS+drnbzjKW3N2AfFB43LPkqef1fNjqQSxNZT3rPfV86E30t7yRY 4LnyaLab9rdlm2bkjcWMFx8YST4tM2zxJj1m/G06UbSjsWu9LxE23QEXjxRB4xqN lUSs8TgdGTkKMyiIyIzEDXzjJU7yMiQi2hAnosdxj/z/yM3sXVuhHOss/zSpHuaU RHADs+kJE1L8MmuZ2w9HqAm5KzQXClg2+TieJYgBpalzuR+sp90LmCZKaZygS8Nj hvaXtk1B8wWjwmSQ8B6ogubb/QxovBlVSgd4tLPMWiYIHqu7h3zQnQ== =HHLu -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Nov 11 13:04:10 2014 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1BBE1ACC89 for <6tisch@ietfa.amsl.com>; Tue, 11 Nov 2014 13:04:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.095 X-Spam-Level: X-Spam-Status: No, score=-15.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RiEq5cL39cz9 for <6tisch@ietfa.amsl.com>; Tue, 11 Nov 2014 13:04:07 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EBC51ACC88 for <6tisch@ietf.org>; Tue, 11 Nov 2014 13:03:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1543; q=dns/txt; s=iport; t=1415739805; x=1416949405; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=FmD6WmF8rHv5Rl1qqsHrEd6qTWhmk4FowEJ4CBWW2Us=; b=EBprFVBwxbM7KsVDrL2rotZW8dK/G1YyQL7j6RyJS0th0AkwK1u/HeAn rNlrl+9CjFWTE9acYhQduNnjbHo1DI64911efGU8KyMDLlUmrCVcOfnuh I9qp3W/8yE1Zd8Ejn7Md0T1CLfYRkuW289/fjZw4pKlT/7OMQKjo9TN8d 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAGp4YlStJA2E/2dsb2JhbABSCoMOgS0E03ICgRoWAQEBAQF9hAMBAQSBCQIBCBguMiUCBAESiEHPUQEBAQEBAQEBAgEBAQEBAQEbjViCWgYLAR06hEsFi0aGa4t0lmCDemyBDzmBAwEBAQ X-IronPort-AV: E=Sophos;i="5.07,362,1413244800"; d="scan'208";a="371319230" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-5.cisco.com with ESMTP; 11 Nov 2014 21:03:25 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id sABL3OQV023038 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Nov 2014 21:03:24 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.91]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0195.001; Tue, 11 Nov 2014 15:03:24 -0600 From: "Raghuram Sudhaakar (rsudhaak)" To: Michael Richardson , "6tisch@ietf.org" <6tisch@ietf.org> Thread-Topic: [6tisch] CoAP resource management - draft-ietf-6tisch-coap-02 Thread-Index: AQHP/cVQc+aUxQBFuUqRL08yJHRHSZxcReMA//+C4wA= Date: Tue, 11 Nov 2014 21:03:23 +0000 Message-ID: References: <32412.1415737868@sandelman.ca> In-Reply-To: <32412.1415737868@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [10.154.177.64] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <06CB98A922420C4A9DCA3529ED9BFD64@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch/A22JpIaeu9smagT1ZLHbBfYNoto Subject: Re: [6tisch] CoAP resource management - draft-ietf-6tisch-coap-02 X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 21:04:08 -0000 Michael I believe =B3version data=B2 may be a misleading word I used in the previou= s email. What I meant is the version number. The version number uniquely identifies the set of 6top resources that can be accessed on a node. Version number is bumped up when a resource is added, renamed or deleted. Heterogenity may arise when new nodes (running an updated implementation which may have added a new resources) are added to existing deployments. Heterogenity is entirely w.r.t the version number (and consequently the set of 6top resources that can be accessed on the nodes). This is important for both the PCE as well as peer nodes to identify what information they access on a 6top node. -raghuram On 11/11/14, 12:31 PM, "Michael Richardson" wrote: > >Raghuram Sudhaakar (rsudhaak) wrote: > > The third and most important discussion was - 3. How do nodes >exchange > > the version data (with PCE and other nodes) of nodes so a network of > > heterogenous nodes (w.r.t version) can interoperate. 1. Proposal - >use > > the joining flows defined in >draft-richardson-6tisch--security-6top-03 > > > Comments and suggestions on this proposal are requested. > >I don't understand why you talk about "version data"? >How are the nodes heterogenous? I suspect that I might be suffering from >unshared terminology here. > >--=20 >Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- > > > From nobody Tue Nov 11 13:14:45 2014 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53C221ACDD8 for <6tisch@ietfa.amsl.com>; Tue, 11 Nov 2014 13:14:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kKMj4jocXvg2 for <6tisch@ietfa.amsl.com>; Tue, 11 Nov 2014 13:14:42 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9A971ACDD7 for <6tisch@ietf.org>; Tue, 11 Nov 2014 13:14:37 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id sABLEU1o020212; Tue, 11 Nov 2014 22:14:30 +0100 (CET) Received: from dhcp-9bf8.meeting.ietf.org (dhcp-9bf8.meeting.ietf.org [31.133.155.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 7536D8D1; Tue, 11 Nov 2014 22:14:29 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Carsten Bormann In-Reply-To: Date: Tue, 11 Nov 2014 11:14:26 -1000 X-Mao-Original-Outgoing-Id: 437433266.429945-b39c959477a4b1c84e40f49cd5c00009 Content-Transfer-Encoding: quoted-printable Message-Id: <27A37719-A535-494C-A3BF-CC8509D35B05@tzi.org> References: <32412.1415737868@sandelman.ca> To: "Raghuram Sudhaakar (rsudhaak)" X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch/UGbMqGJ4mXwPBmkl0wMpkxAleKA Cc: Michael Richardson , "6tisch@ietf.org" <6tisch@ietf.org> Subject: Re: [6tisch] CoAP resource management - draft-ietf-6tisch-coap-02 X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 21:14:43 -0000 Version numbers often don=92t work very well. They may look like cheap insurance, but in the end they don=92t buy = much. E.g. simply incrementing them suddenly makes you incommunicado with = older devices. Not having looked at the details, I cannot recommend something specific, = but maybe e.g. look at the capability indication in draft-ietf-6lo-ghc = as a very soft alternative to version numbers. Gr=FC=DFe, Carsten > On 11 Nov 2014, at 11:03, Raghuram Sudhaakar (rsudhaak) = wrote: >=20 > Michael > I believe =B3version data=B2 may be a misleading word I used in the = previous > email. What I meant is the version number. >=20 > The version number uniquely identifies the set of 6top resources that = can > be accessed on a node. Version number is bumped up when a resource is > added, renamed or deleted. >=20 > Heterogenity may arise when new nodes (running an updated = implementation > which may have added a new resources) are added to existing = deployments. > Heterogenity is entirely w.r.t the version number (and consequently = the > set of 6top resources that can be accessed on the nodes). >=20 > This is important for both the PCE as well as peer nodes to identify = what > information they access on a 6top node. >=20 > -raghuram >=20 > On 11/11/14, 12:31 PM, "Michael Richardson" = wrote: >=20 >>=20 >> Raghuram Sudhaakar (rsudhaak) wrote: >>> The third and most important discussion was - 3. How do nodes >> exchange >>> the version data (with PCE and other nodes) of nodes so a network of >>> heterogenous nodes (w.r.t version) can interoperate. 1. Proposal - >> use >>> the joining flows defined in >> draft-richardson-6tisch--security-6top-03 >>=20 >>> Comments and suggestions on this proposal are requested. >>=20 >> I don't understand why you talk about "version data"? >> How are the nodes heterogenous? I suspect that I might be suffering = from >> unshared terminology here. >>=20 >> --=20 >> Michael Richardson , Sandelman Software Works >> -=3D IPv6 IoT consulting =3D- >>=20 >>=20 >>=20 >=20 > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch >=20 >=20 From nobody Tue Nov 11 13:20:26 2014 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 359571ACE1A for <6tisch@ietfa.amsl.com>; Tue, 11 Nov 2014 13:20:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mEn2OJ7NakDv for <6tisch@ietfa.amsl.com>; Tue, 11 Nov 2014 13:20:22 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99A0E1ACDC5 for <6tisch@ietf.org>; Tue, 11 Nov 2014 13:20:22 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id CC16C20098; Tue, 11 Nov 2014 16:22:25 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 4BEED637F4; Tue, 11 Nov 2014 16:20:21 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 36A58637EA; Tue, 11 Nov 2014 16:20:21 -0500 (EST) From: Michael Richardson To: "Raghuram Sudhaakar \(rsudhaak\)" In-Reply-To: References: <32412.1415737868@sandelman.ca> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch/EG4_k3fcjfNYqE49YhA_OSMnZ4s Cc: "6tisch@ietf.org" <6tisch@ietf.org> Subject: Re: [6tisch] CoAP resource management - draft-ietf-6tisch-coap-02 X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 21:20:24 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Raghuram Sudhaakar (rsudhaak) wrote: > Michael I believe =C2=B3version data=C2=B2 may be a misleading word I= used in the > previous email. What I meant is the version number. > The version number uniquely identifies the set of 6top resources that > can be accessed on a node. Version number is bumped up when a resource > is added, renamed or deleted. okay, you mean the version of the 6top API; versions are created by standar= ds action... > Heterogenity may arise when new nodes (running an updated > implementation which may have added a new resources) are added to > existing deployments. Heterogenity is entirely w.r.t the version > number (and consequently the set of 6top resources that can be access= ed > on the nodes). Yes, I agree this is an interesting issue. The problem is what do you do when a v2 node tries to talk to a v1 node... = we need to think about this now, I agree. I think this is most acute in the minimal case, as otherwise the PCE can have a notion about what the range of versions available are, and can cope... The PCE can speak all versions, so this means that the nodes do not have to support more than one version. But, in the minimal case, they have to talk to each other, so there has to = be a discovery process and some adaptation. =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVGJ9koCLcPvd0N1lAQJN2QgAkN7MQjMo+FycAkctV+/zGHdMV2jiRFjl h4nL3mvRmkym6cSBQ8XjpF4foMlhls1PEuPUA2NYTfqNfvIEvacKSC/4Hl8bFArm eplPhpRellHEgFq/QUnH7t5Zg6vopIDFQaChHmXpOX10DwG7PHGbldXqrSXrIsXS f4mGLLXk1jhkTKgLDnVbJlA9VIK0bxj2FdcJfVK6Vp79yUgd+j35tPXBSPeT3fPP zldMgvnOt/kMY/J1SmFMi1qZSRx6+Bak5EpK6msWxTZ/7XJ+3OlxCmMVQZD87H+R pDc6p4nv088VhduvqCXWijXBRAMiaNqxVK3c2S0MyYKuo0zMFORqrA== =I74B -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Nov 11 16:23:21 2014 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 307791A8AAF for <6tisch@ietfa.amsl.com>; Tue, 11 Nov 2014 16:23:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J0XNDmgQUJNh for <6tisch@ietfa.amsl.com>; Tue, 11 Nov 2014 16:23:10 -0800 (PST) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEFE81A8A41 for <6tisch@ietf.org>; Tue, 11 Nov 2014 16:23:09 -0800 (PST) Received: by mail-pd0-f175.google.com with SMTP id y13so11115046pdi.20 for <6tisch@ietf.org>; Tue, 11 Nov 2014 16:23:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=DqTtz6AIjw4GhhYCV4S8MNXEzlCsYjI91chINdTA3u4=; b=L7Ml8tAXLISOAW+CXM0QSyiwDxPX6y29tPvBH/pF2+0BBDENJcd3dM59PAvfnRVKal /FS1beHlyRxYRBPdNBdAFfrjEsXoDERw84obqMbczOwXfXJjWeGsO7sPymKhKYaBdpvP D5Ty38962p+NFEkYhEthxUfmLGgKbJcrggZYszL5lwT93lATHYkib2H4vc0dIi184900 0dshpOakHkkoBLj5caKFAP05RCfpTGqw6lagfcYdcgdTqyYila8aTYnsSsYp1l0McNse XLo5AgAqWign+VQ4xzJVzNXQlmXoTSbgRdSOyNPJaaG/ejVgpZ21WRHXFugNveMgxPN5 mX9g== X-Received: by 10.70.35.236 with SMTP id l12mr5211801pdj.63.1415751789018; Tue, 11 Nov 2014 16:23:09 -0800 (PST) MIME-Version: 1.0 Sender: twatteyne@gmail.com Received: by 10.66.88.42 with HTTP; Tue, 11 Nov 2014 16:22:48 -0800 (PST) In-Reply-To: <10653.1415740821@sandelman.ca> References: <32412.1415737868@sandelman.ca> <10653.1415740821@sandelman.ca> From: Thomas Watteyne Date: Tue, 11 Nov 2014 14:22:48 -1000 X-Google-Sender-Auth: SP3NOkFI0bLS-oUIpZzF7G99eFU Message-ID: To: Michael Richardson Content-Type: multipart/alternative; boundary=047d7bfe9e0879863e05079e668f Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch/FOCVIiHFgzUgE4H2C-8Qy7SwKXk Cc: "Raghuram Sudhaakar \(rsudhaak\)" , "6tisch@ietf.org" <6tisch@ietf.org> Subject: Re: [6tisch] CoAP resource management - draft-ietf-6tisch-coap-02 X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 00:23:12 -0000 --047d7bfe9e0879863e05079e668f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Michael, Your description captures what I had in mind. In the centralized case, as part of the joining process (e.g. defined in draft-richardson-6tisch--security-6top-03), the PCE GETs the CoAP API version implemented by the newly joining node. The PCE speaks all versions, and chooses the commands it sends to the node depending on the set of commands the node understands. Similarly, in a purely distributed cases, a node GETs the version of the CoAP interface of its neighbor. In my mind, the version is just a mechanism the CoAP interface offers, and is generally a "healthy" feature to have, especially if the version of the interface can change. The initial idea for this discussion is also to be able to possibly switch to a more generic solution (COMAN? COMI?). Another versioning option would be to: - associate a version number to the YANG data model - have all associated CoAP URIs be prefixed with that version, e.g. /6t/1, /6t/2, etc. This is the approach used by Google ( https://developers.google.com/gmail/api/v1/reference/) and Xively ( https://xively.com/dev/docs/api/data/read/single_feed/). It allows for multiple a node to implement multiple versions, at the cost of an extra Uri-Path. Thoughts? Thomas On Tue, Nov 11, 2014 at 11:20 AM, Michael Richardson wrote: > > Raghuram Sudhaakar (rsudhaak) wrote: > > Michael I believe =C2=B3version data=C2=B2 may be a misleading word= I used in > the > > previous email. What I meant is the version number. > > > The version number uniquely identifies the set of 6top resources th= at > > can be accessed on a node. Version number is bumped up when a > resource > > is added, renamed or deleted. > > okay, you mean the version of the 6top API; versions are created by > standards > action... > > > Heterogenity may arise when new nodes (running an updated > > implementation which may have added a new resources) are added to > > existing deployments. Heterogenity is entirely w.r.t the version > > number (and consequently the set of 6top resources that can be > accessed > > on the nodes). > > Yes, I agree this is an interesting issue. > The problem is what do you do when a v2 node tries to talk to a v1 node..= . > we > need to think about this now, I agree. I think this is most acute in the > minimal case, as otherwise the PCE can have a notion about what the range > of > versions available are, and can cope... The PCE can speak all versions, = so > this means that the nodes do not have to support more than one version. > But, in the minimal case, they have to talk to each other, so there has t= o > be > a discovery process and some adaptation. > > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- > > > > > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > > --047d7bfe9e0879863e05079e668f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Michael,

    Your description captures what= I had in mind. In the centralized case, as part of the joining process (e.= g. defined in=C2=A0draft-richardson-6tisch--security-6top-03), the PCE GETs= the CoAP API version implemented by the newly joining node. The PCE speaks= all versions, and chooses the commands it sends to the node depending on t= he set of commands the node understands. Similarly, in a purely distributed= cases, a node GETs the version of the CoAP interface of its neighbor.

    In my mind, the version is just a mechanism the CoAP i= nterface offers, and is generally a "healthy" feature to have, es= pecially if the version of the interface can change. The initial idea for t= his discussion is also to be able to possibly switch to a more generic solu= tion (COMAN? COMI?).

    Another versioning option wou= ld be to:
    - associate a version number to the YANG data model
    - have all associated CoAP URIs be prefixed with that version, e.g.= =C2=A0/6t/1, /6t/2, etc.

    This is the approach used= by Google (https://developers.google.com/gmail/api/v1/reference/<= /a>) and Xively=C2=A0(https://xively.com/dev/docs/api/data/read/s= ingle_feed/). It allows for multiple a node to implement multiple versi= ons, at the cost of an extra Uri-Path.

    Thoughts?

    Thomas

    On Tue, Nov 11, 2014 at 11:20 AM, Michael Richards= on <mcr+ietf@sandelman.ca> wrote:

    Raghuram Sudhaakar (rsudhaak) <rsu= dhaak@cisco.com> wrote:
    =C2=A0 =C2=A0 > Michael I believe =C2=B3version = data=C2=B2 may be a misleading word I used in the
    =C2=A0 =C2=A0 > previous email. What I meant is the version number.

    =C2=A0 =C2=A0 > The version number uniquely identifies the set of 6top r= esources that
    =C2=A0 =C2=A0 > can be accessed on a node. Version number is bumped up w= hen a resource
    =C2=A0 =C2=A0 > is added, renamed or deleted.

    okay, you mean the version of the 6top API; versions are created by = standards
    action...

    =C2=A0 =C2=A0 > Heterogenity may arise when new nodes (running an update= d
    =C2=A0 =C2=A0 > implementation which may have added a new resources) are= added to
    =C2=A0 =C2=A0 > existing deployments.=C2=A0 Heterogenity is entirely w.r= .t the version
    =C2=A0 =C2=A0 > number (and consequently the set of 6top resources that = can be accessed
    =C2=A0 =C2=A0 > on the nodes).

    Yes, I agree this is an interesting issue.
    The problem is what do you do when a v2 node tries to talk to a v1 node... = we
    need to think about this now, I agree.=C2=A0 I think this is most acute in = the
    minimal case, as otherwise the PCE can have a notion about what the range o= f
    versions available are, and can cope...=C2=A0 The PCE can speak all version= s, so
    this means that the nodes do not have to support more than one version.
    But, in the minimal case, they have to talk to each other, so there has to = be
    a discovery process and some adaptation.

    --
    Michael Richardson <mcr+IETF@= sandelman.ca>, Sandelman Software Works
    =C2=A0-=3D IPv6 IoT consulting =3D-




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


    --047d7bfe9e0879863e05079e668f-- From nobody Tue Nov 11 19:04:27 2014 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E208A1A892E for <6tisch@ietfa.amsl.com>; Tue, 11 Nov 2014 19:04:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ENyLtubDbHzb for <6tisch@ietfa.amsl.com>; Tue, 11 Nov 2014 19:04:24 -0800 (PST) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B22CA1A8A69 for <6tisch@ietf.org>; Tue, 11 Nov 2014 19:04:23 -0800 (PST) Received: by mail-lb0-f176.google.com with SMTP id 10so8472413lbg.7 for <6tisch@ietf.org>; Tue, 11 Nov 2014 19:04:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Gd4s9yl2Q7a7anyBfWUdIY7kgHfgIla6AxT+vFwFxhY=; b=fT0ZtKdurnlea9+Ml6jjP+kpI/sg5/ADEtr2LQwEcd3OVQcDb3NK+herem67viwogd HhYYMAqDybHE196QdaEE24JR/18BUp6sNXU7Q6siODAkBNtaYEWaKo8WW9l0HWv1zRNI M5OgBfon+hGIJa7iI67OszaxEXP5CQ30ZBJpTrlVrA9kxuyq+H0ui8MojWEl2w67Bt/0 6txw/kg1Ut7FdONIaPmtgsytHC2iSOUCy533yyQzdHzXpW1BKI1V2jSc8/erJD4dwiEd 11shFfm6w9wd8qgwDF9JQQaJ5OfF01YAC4PhNKAN9io+kVBJ7xmS5rRi8fi1VtZoDaMy WGAw== MIME-Version: 1.0 X-Received: by 10.112.173.39 with SMTP id bh7mr22965010lbc.53.1415761462119; Tue, 11 Nov 2014 19:04:22 -0800 (PST) Received: by 10.25.24.169 with HTTP; Tue, 11 Nov 2014 19:04:22 -0800 (PST) Received: by 10.25.24.169 with HTTP; Tue, 11 Nov 2014 19:04:22 -0800 (PST) Date: Tue, 11 Nov 2014 17:04:22 -1000 Message-ID: From: Ines Robles To: 6tisch@ietf.org Content-Type: multipart/alternative; boundary=001a11c264140953340507a0a743 Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch/Uc0wnDiUKVFCQTKkrsS4HfyDG_U Subject: Re: [6tisch] volunteers for mibute taker and Jabber scribe for 6tisch WG meeting X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 03:04:25 -0000 --001a11c264140953340507a0a743 Content-Type: text/plain; charset=UTF-8 Hi, I would like to be the Jabber scribe person please. Thanks, Ines --001a11c264140953340507a0a743 Content-Type: text/html; charset=UTF-8

    Hi,
    I would like to be the Jabber scribe person please.
    Thanks,
    Ines

    --001a11c264140953340507a0a743-- From nobody Tue Nov 11 23:55:40 2014 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0CC91A6F68 for <6tisch@ietfa.amsl.com>; Tue, 11 Nov 2014 23:55:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.095 X-Spam-Level: X-Spam-Status: No, score=-15.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJPdFaTucNeV for <6tisch@ietfa.amsl.com>; Tue, 11 Nov 2014 23:55:38 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4959F1A871C for <6tisch@ietf.org>; Tue, 11 Nov 2014 23:55:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1968; q=dns/txt; s=iport; t=1415778940; x=1416988540; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=OISNmvUc9OtcSeojIHFpHyf6fR4I1+MUtDYHeF3Eeo8=; b=OSMlDBW3xSNLyNh9YAmTJOcoFsZOkIQw1P4rZtGTuuK1CgETpjv0ZW9G Hzs158whZvqBnSwW/Xc9or3H5jpgvH4fKtmPFcUAx3AsuQqzPjagLbG0/ vN/2/QcYKxHQ/9nUYcuWgb9967Sbvje7frWBTC5wZxODBmsYvXI+4JgmB U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoYIABwSY1StJA2E/2dsb2JhbABcgw6BLQSDAtBwAhx/FgEBAQEBfYQCAQEBAwEjEUUQAgEIGAICBiACAgIwFRACBAENBQiIMAm3OpZKAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4EtjCuCWhEBHzEHgnc2gR4FkjqiXoN8bYEPOYEDAQEB X-IronPort-AV: E=Sophos;i="5.07,367,1413244800"; d="scan'208";a="368349778" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-9.cisco.com with ESMTP; 12 Nov 2014 07:55:39 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id sAC7tbHI008898 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Nov 2014 07:55:37 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.165]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0195.001; Wed, 12 Nov 2014 01:55:37 -0600 From: "Pascal Thubert (pthubert)" To: Michael Richardson , "Raghuram Sudhaakar (rsudhaak)" Thread-Topic: [6tisch] CoAP resource management - draft-ietf-6tisch-coap-02 Thread-Index: AQHP/cVQc+aUxQBFuUqRL08yJHRHSZxcReMA//+C4wCAAIrdgIAATJTQ Date: Wed, 12 Nov 2014 07:55:36 +0000 Deferred-Delivery: Wed, 12 Nov 2014 07:55:00 +0000 Message-ID: References: <32412.1415737868@sandelman.ca> <10653.1415740821@sandelman.ca> In-Reply-To: <10653.1415740821@sandelman.ca> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.210.230] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch/-MUPWfa3G5ZA6FstK6jEb3pnsKc Cc: "6tisch@ietf.org" <6tisch@ietf.org> Subject: Re: [6tisch] CoAP resource management - draft-ietf-6tisch-coap-02 X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 07:55:39 -0000 PiANCj4gUmFnaHVyYW0gU3VkaGFha2FyIChyc3VkaGFhaykgPHJzdWRoYWFrQGNpc2NvLmNvbT4g d3JvdGU6DQo+ICAgICA+IE1pY2hhZWwgSSBiZWxpZXZlIMKzdmVyc2lvbiBkYXRhwrIgbWF5IGJl IGEgbWlzbGVhZGluZyB3b3JkIEkgdXNlZCBpbiB0aGUNCj4gICAgID4gcHJldmlvdXMgZW1haWwu IFdoYXQgSSBtZWFudCBpcyB0aGUgdmVyc2lvbiBudW1iZXIuDQo+IA0KPiAgICAgPiBUaGUgdmVy c2lvbiBudW1iZXIgdW5pcXVlbHkgaWRlbnRpZmllcyB0aGUgc2V0IG9mIDZ0b3AgcmVzb3VyY2Vz IHRoYXQNCj4gICAgID4gY2FuIGJlIGFjY2Vzc2VkIG9uIGEgbm9kZS4gVmVyc2lvbiBudW1iZXIg aXMgYnVtcGVkIHVwIHdoZW4gYSByZXNvdXJjZQ0KPiAgICAgPiBpcyBhZGRlZCwgcmVuYW1lZCBv ciBkZWxldGVkLg0KPiANCj4gb2theSwgeW91IG1lYW4gdGhlIHZlcnNpb24gb2YgdGhlIDZ0b3Ag QVBJOyB2ZXJzaW9ucyBhcmUgY3JlYXRlZCBieSBzdGFuZGFyZHMNCj4gYWN0aW9uLi4uDQo+IA0K PiAgICAgPiBIZXRlcm9nZW5pdHkgbWF5IGFyaXNlIHdoZW4gbmV3IG5vZGVzIChydW5uaW5nIGFu IHVwZGF0ZWQNCj4gICAgID4gaW1wbGVtZW50YXRpb24gd2hpY2ggbWF5IGhhdmUgYWRkZWQgYSBu ZXcgcmVzb3VyY2VzKSBhcmUgYWRkZWQgdG8NCj4gICAgID4gZXhpc3RpbmcgZGVwbG95bWVudHMu ICBIZXRlcm9nZW5pdHkgaXMgZW50aXJlbHkgdy5yLnQgdGhlIHZlcnNpb24NCj4gICAgID4gbnVt YmVyIChhbmQgY29uc2VxdWVudGx5IHRoZSBzZXQgb2YgNnRvcCByZXNvdXJjZXMgdGhhdCBjYW4g YmUgYWNjZXNzZWQNCj4gICAgID4gb24gdGhlIG5vZGVzKS4NCj4gDQo+IFllcywgSSBhZ3JlZSB0 aGlzIGlzIGFuIGludGVyZXN0aW5nIGlzc3VlLg0KPiBUaGUgcHJvYmxlbSBpcyB3aGF0IGRvIHlv dSBkbyB3aGVuIGEgdjIgbm9kZSB0cmllcyB0byB0YWxrIHRvIGEgdjEgbm9kZS4uLiB3ZQ0KPiBu ZWVkIHRvIHRoaW5rIGFib3V0IHRoaXMgbm93LCBJIGFncmVlLiAgSSB0aGluayB0aGlzIGlzIG1v c3QgYWN1dGUgaW4gdGhlIG1pbmltYWwNCj4gY2FzZSwgYXMgb3RoZXJ3aXNlIHRoZSBQQ0UgY2Fu IGhhdmUgYSBub3Rpb24gYWJvdXQgd2hhdCB0aGUgcmFuZ2Ugb2YgdmVyc2lvbnMNCj4gYXZhaWxh YmxlIGFyZSwgYW5kIGNhbiBjb3BlLi4uICBUaGUgUENFIGNhbiBzcGVhayBhbGwgdmVyc2lvbnMs IHNvIHRoaXMgbWVhbnMgdGhhdA0KPiB0aGUgbm9kZXMgZG8gbm90IGhhdmUgdG8gc3VwcG9ydCBt b3JlIHRoYW4gb25lIHZlcnNpb24uDQo+IEJ1dCwgaW4gdGhlIG1pbmltYWwgY2FzZSwgdGhleSBo YXZlIHRvIHRhbGsgdG8gZWFjaCBvdGhlciwgc28gdGhlcmUgaGFzIHRvIGJlIGENCj4gZGlzY292 ZXJ5IHByb2Nlc3MgYW5kIHNvbWUgYWRhcHRhdGlvbi4NCj4gDQpbUFRdIA0KRXhhY3RseQ0KDQpb UFRdIFBhc2NhbA0K From nobody Wed Nov 12 08:50:55 2014 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA6E31A8AC8; Wed, 12 Nov 2014 08:50:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.498 X-Spam-Level: X-Spam-Status: No, score=-0.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_NO_TEXT=1.997, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eNcWk_nxUDC4; Wed, 12 Nov 2014 08:50:48 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 535671A895E; Wed, 12 Nov 2014 08:50:47 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id B472D20098; Wed, 12 Nov 2014 11:52:52 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 549EA637F4; Wed, 12 Nov 2014 11:50:45 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 333F6637F2; Wed, 12 Nov 2014 11:50:45 -0500 (EST) From: Michael Richardson To: 6tisch-security@ietf.org, 6tisch@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 210B.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch/54qPW82vyQ41-8xs3wWj2WZaWAs Subject: [6tisch] proposed security text for architecture draft X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 16:50:52 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable This text is the architecture results of the secure (zero-touch) design tea= m. The realization that we should use loose source routes is due to Pascal. I believe this goes into a new section between 10. Centralized vs. and 11. IANA Considerations. Interspersed is some text that I think goes i= n to section 12. Security Considerations.=20 If you are interested in the history of this text, or some additional more = implementation side ideas, then I recommend reviewing the diff http://www.ietf.org/rfcdiff?url1=3Ddraft-richardson-6tisch--security-6= top-03&difftype=3D--html&submit=3DGo%21&url2=3Ddraft-richardson-6tisch--sec= urity-6top-04 10B. Architectural requirements of join protocol 10B.1. Entities involves in the join process The following actors are involved: there is a new joining node. It is (radio) adjacent to the join assistant. The join assistant is part of the production network, and participates in one or more DODAGs, such that it is reachable from the 6LBR, and the JCE. 10B.2. Join Protocol deliverables This section works from the ultimate goal, and goes backwards to prerequisite actions. (Section 6 presents t