10/24/2014 Webex IPv 6 over the TSCH mode of IEEE 802. 15. 4 e Chairs: Pascal Thubert Thomas Watteyne Etherpad for minutes: http: //etherpad. tools. ietf. org: 9000/p/6 tisch
Note Well This summary is only meant to point you in the right direction, and doesn't have all the nuances. The IETF's IPR Policy is set forth in BCP 79; please read it carefully. The brief summary: • By participating with the IETF, you agree to follow IETF processes. • If you are aware that a contribution of yours (something you write, say, or discuss in any IETF context) is covered by patents or patent applications, you need to disclose that fact. • You understand that meetings might be recorded, broadcast, and publicly archived. For further information, talk to a chair, ask an Area Director, or review the following: • BCP 9 (on the Internet Standards Process) • BCP 25 (on the Working Group processes) • BCP 78 (on the IETF Trust) • BCP 79 (on Intellectual Property Rights in the IETF) 2
Reminder: Minutes are taken * This meeting is recorded ** Presence is logged *** * Scribe; please contribute online to the minutes at http: //etherpad. tools. ietf. org: 9000/p/6 tisch? use. Monospace. Font=true ** Recordings and Minutes are public and may be subject to discovery in the event of litigation. *** From the Webex login 3
![Agenda • Administrivia [3 min] – Approval agenda – Approval minutes last call •](https://present5.com/presentation/a1eb2541a964b235562c0efb6e29211a/image-4.jpg "Agenda • Administrivia [3 min] – Approval agenda – Approval minutes last call •")
Agenda • Administrivia [3 min] – Approval agenda – Approval minutes last call • IETF 91 [5 min] – meetecho remote presentation – draft agenda • draft-ietf-6 tisch-tsch-02 publication [2 min] – please review • • • wrapping up draft-ietf-6 tisch-minimal draft-richardson-6 tisch--security-6 top-02 RPL option status and update 6 lo RFC 7322: RFC Style Guide AOB [15 min] [10 min] [5 min] [1 min] 4
Administrivia
Admin is trivia • Approval Agenda • Approval minutes last call • Call security DT on Tuesday – 6 participants – Goal: review draft-richardson-6 tisch--security -6 top – Minutes at https: //bitbucket. org/6 tisch/meetings/wiki/141 021_webex_security – Next call next Tuesday 6
IETF 91
IETF 91 admin • 0900 -1030 HST Thursday Morning Session I (90 min) • Remote participation and presentation possible – Minutes will include remote participants • Important dates: – http: //www. ietf. org/meeting/important-dates-2014. html#IETF 91 – 2014 -10 -27 (Monday): Internet Draft submission cut-off (for all drafts, including -00) by UTC 23: 59, upload using IETF ID Submission Tool. – 2014 -10 -27 (Monday): Draft Working Group agendas due by UTC 23: 59, upload using IETF Meeting Materials Management Tool. – 2014 -11 -03 (Monday): Revised Working Group agendas due by UTC 23: 59, upload using IETF Meeting Materials Management Tool. – 2014 -11 -06 send list of remote presenters to Meetecho team.
![Intro and Status [5 min] (Chairs) Note-Well, Blue Sheets, Scribes, Agenda Bashing 6 Ti.](https://present5.com/presentation/a1eb2541a964b235562c0efb6e29211a/image-9.jpg "Intro and Status [5 min] (Chairs) Note-Well, Blue Sheets, Scribes, Agenda Bashing 6 Ti.")
Intro and Status [5 min] (Chairs) Note-Well, Blue Sheets, Scribes, Agenda Bashing 6 Ti. SCH milestones recap Chartered Drafts [40 min] Goal: present latest changes and decide whether ready for WGLC. * <draft-ietf-6 tisch-tsch-02> * <draft-ietf-6 tisch-minimal-XX> * <draft-ietf-6 tisch-6 top-interface-XX> Liaison and Announcements * <draft-finn-detnet-problem-statement-XX> * 6 Ti. SCH ETSI Plugtest at IETF 93 (10 min) (15 min) (TBD) [25 min] (15 min) (10 min) (TBD) Rechartering First Glance [10 min] (Chairs) 6 Ti. SCH Security Discussion [20 min] * <draft-richardson-6 tisch--security-6 top-XX> (10 min) * TBD (10 min) Any Other Business [5 min] (Michael Richardson) (Rene Struik)
Next steps • Thomas to create slide skeleton • Slides to chairs by 11/03 midnight PDT for integration • Review slides next call 11/07
draft-ietf-6 tisch-tsch-02
Status • https: //tools. ietf. org/html/draft-ietf-6 tischtsch-02 published 17 October • Diff at https: //tools. ietf. org/rfcdiff? url 2=draft -ietf-6 tisch-tsch-02. txt • Following rewording proposed • Closes all issues, but 2 (see later)
1. 2. 3. 4. Introduction. . . Requirements Language. . TSCH in the LLN Context. . Problems and Goals. . . 4. 1. Network Formation. . 4. 2. Network Maintenance. . 4. 3. Multi-Hop Topology. . 4. 4. Routing and Timing Parents. . . 4. 5. Resource Management. . 4. 6. Dataflow Control. . 4. 7. Deterministic Behavior. . . . 4. 8. Scheduling Mechanisms. . . . 4. 9. Secure Communication. . . . 5. IANA Considerations. . . 6. Security Considerations. . 7. Acknowledgments. . . 8. References. . . . 8. 1. Normative References. . . . 8. 2. Informative References. . . . 8. 3. External Informative References. . . Appendix A. TSCH Protocol Highlights. . A. 1. Timeslots. . . A. 2. Slotframes. . . A. 3. Node TSCH Schedule. . A. 4. Cells and Bundles. . A. 5. Dedicated vs. Shared Cells. . . A. 6. Absolute Slot Number. . . . A. 7. Channel Hopping. . . A. 8. Time Synchronization. . . . A. 9. Power Consumption. . A. 10. Network TSCH Schedule. . . . A. 11. Join Process. . . A. 12. Information Elements. . . . A. 13. Extensibility. . . Appendix B. TSCH Gotchas. . B. 1. Collision Free Communication. . B. 2. Multi-Channel vs. Channel Hopping. . B. 3. Cost of (continuous) Synchronization B. 4. Topology Stability. . B. 5. Multiple Concurrent Slotframes. . . Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4 4 6 6 7 7 7 8 8 9 9 10 10 10 13 15 15 16 16 16 17 17 18 18 19 19 20 20 20 21 21 21 22 22
http: //tools. ietf. org/wg/6 tisch/trac/ticket/25 Several people have pointed out the need to be more specific about the use of the MLME -TSCH-MODE. request primitive during joining. That is, when does a node issue this command. This discussion was ongoing in the thread http: //www. ietf. org/mailarchive/web/6 tisch/current/msg 02528. html We need to reach consensus how much of this discussion belongs in the 6 tisch-tsch draft, and update the draft accordingly OLD A mote wishing to join the network listens for EBs. Since EBs are sent on all frequencies, the joining node can listen on any frequency until it hears an EB. What frequency it listens on, and whether it slowly changes frequency during this joining period is implementation-specific. Using the ASN and the other timing information of the EB, the new mote synchronizes to the network. Using the slotframe and cell information from the EB, it knows how to contact other nodes in the network. NEW A mote wishing to join the network listens for EBs. Since EBs are sent on all frequencies, the joining node can listen on any frequency until it hears an EB. What frequency it listens on is implementation-specific. Once it has received one or more EBs, the new node enables the TSCH mode and uses the ASN and the other timing information of the EB to synchronize to the network. Using the slotframe and cell information from the EB, it knows how to contact other nodes in the network.
http: //tools. ietf. org/wg/6 tisch/trac/ticket/24 Several people have pointed out the need to be more specific about the join priority, including the discussion started at http: //www. ietf. org/mailarchive/web/6 tisch/current/msg 02528. html We need to reach consensus how much of this discussion belongs in the 6 tisch-tsch draft, and update the draft accordingly. OLD Motes already part of the network can periodically send Enhanced Beacon (EB) frames to announce the presence of the network. These contain information about the size of the timeslot used in the network, the current ASN, information about the slotframes and timeslots the beaconing mote is listening on, and a 1 -byte join priority. Even if a node is configured to send all EB frames on the same channel offset, because of the channel hopping nature of TSCH described in <xref target="sec_channel_hopping" />, this channel offset translates into a different frequency at different slotframe cycles. As a result, EB frames are sent on all frequencies. NEW Motes already part of the network can periodically send Enhanced Beacon (EB) frames to announce the presence of the network. These contain information about the size of the timeslot used in the network, the current ASN, information about the slotframes and timeslots the beaconing mote is listening on, and a 1 -byte join priority. The join priority field gives information to make a better decision of which node to join. Even if a node is configured to send all EB frames on the same channel offset, because of the channel hopping nature of TSCH described in <xref target="sec_channel_hopping" />, this channel offset translates into a different frequency at different slotframe cycles. As a result, EB frames are sent on all frequencies.
Final steps • Reach rough consensus • Decide whether read for WGLC
draft-ietf-6 tisch-minimal
Minimal status • Update default timing according to 15. 4 e TSCH • Updated name of timing fields • Pending external review and clarifications
Proposed Changes OLD The figure below shows an active timeslot in which a packet is sent from the transmitter node (TX) to the receiver node (RX). A link-layer acknowledgement is sent by the RX node to the TX node when the packet is to be acknowledged. The Ts. Tx. Offset duration defines the instant in the timeslot when the first byte of the transmitted packet leaves the radio of the TX node. The radio of the RX node is turned on Ts. Long. GT/2 before that instant, and listens for at least Ts. Long. GT. This allows for a de-synchronization between the two node of at most Ts. Long. GT. The RX node needs to send the first byte of the MAC acknowledgement exactly Ts. Tx. Ack. Delay after the end of the last byte of the received packet. TX's radio has to be turned on Ts. Short. GT/2 before that time, and keep listening for at least Ts. Short. GT. NEW The figure below shows an active timeslot in which a packet is sent from the transmitter node (TX) to the receiver node (RX). A link-layer acknowledgement is sent by the RX node to the TX node when the packet is to be acknowledged. The Ts. Tx. Offset duration defines the instant in the timeslot when the first byte of the transmitted packet leaves the radio of the TX node. The radio of the RX node is turned on ts. Rx. Wait/2 before that instant, and listens for at least ts. Rx. Wait. This allows for a de-synchronization between the two node of at most ts. Rx. Wait. The RX node needs to send the first byte of the MAC acknowledgement exactly Ts. Tx. Ack. Delay after the end of the last byte of the received packet. TX's radio has to be turned on ts. Ack. Wait/2 before that time, and keep listening for at least ts. Ack. Wait. The TX node can perform a Clear Channel Assessment (CCA) if required, this does not interfere with the scope of this draft. As for a minimal configuration CCA is not mandatory.
Time slot internal timing diagram /---------- Time Slot duration ----------/ | /ts. Short. GT/ | | | |------------+----------+------| TX | | TX-Packet | |RX Ack| | |------------+----------+------| |/ts. Tx. Offset/| | | |------------+----------+------| RX | | RX-Packet | |TX Ack| | |-----+--+--+--------------+------| | | | | /ts. Long. GT/ |/Ts. Tx. Ack. Delay/| | | Start End of of Slot NEW OLD /-------------- Time Slot duration -----------/ | /ts. Ack. Wait/ | | | /ts. Rx. Ack. Delay/| | |-----------+---------+--------+------| TX | /1/ /3/ /2/ | TX-Packet | |RX Ack| | |-----+--------+---------------+------| |/ ts. Tx. Offset /| | | |-----------+---------+--------+------| RX | | RX-Packet | |TX Ack| | |---------+--+--+---------------+------| | | | | /ts. Rx. Wait/ |/ts. Tx. Ack. Delay/ | | | Start End of of Slot /1/ ts. CCAOffset /2/ ts. Rx. Tx /3/ ts. CCA
+----------------+------+ | IEEE 802. 15. 4 e TSCH parameter | Value | +----------------+------+ | Ts. Tx. Offset | 2120 us | +----------------+------+ | Ts. Long. GT | 2000 us | +----------------+------+ | Ts. Tx. Ack. Delay | 1000 us | +----------------+------+ | Ts. Short. GT | 400 us | +----------------+------+ | Time Slot duration | 10000 us | +----------------+------+ NEW OLD +----------------+------+ | IEEE 802. 15. 4 e TSCH parameter | Value (us) | +----------------+------+ | ts. CCAOffset | 1800 | +----------------+------+ | ts. CCA | 128 | +----------------+------+ | ts. Tx. Offset | 2120 | +----------------+------+ | ts. Rx. Offset | 1120 | +----------------+------+ |ts. Rx. Ack. Delay | 800 | +----------------+------+ | ts. Tx. Ack. Delay | 1000 | +----------------+------+ | ts. Rx. Wait | 2200 | +----------------+------+ | ts. Ack. Wait | 400 | +----------------+------+ | ts. Rx. Tx | 192 | +----------------+------+ | ts. Max. Ack | 2400 | +----------------+------+ | ts. Max. Tx | 4256 | +----------------+------+ | Time Slot duration | 10000 | +----------------+------+
Open Questions • Hb. H header compression. Indicate direction – +1 for 6 lo approach – +1 for not limiting possible future extensions with other routing protocols • Security – What should we say at the minimal draft? No security at all? • Review of IEs in the EBs and other Frames. Is everything covered? – Need review and approval from 15. 4 e experts/implementors
ML Questions • Routing Header Compression 23
Final steps • What to do with possible compression of RPL option? • Reach rough consensus • Decide whether ready for WGLC
draft-richardson-6 tisch-security-6 top-02
Join Coordination Entity Akin to PCE 6 top/NS/ARO join protocl (“wireless. HART”-like) JCE Joining Node Join Assistant (proxy) 6 LBR BEACON (1) Could be part of 6 LBR Or co-located in PCE Router Solicitation Router Advertisement ? ? (6) ? ? (7) NS (DAR) (5) Certificate 6 tisch Request (2) Certificate Reply (3) mesh Join Request (4) (NS w/(E)ARO) NS (DAC) (8) DAO Mesh DAOACK node DAOACK (2) and (3) May have limited Utility, kept for now OUI field of EARO Contains 802. 11 AR IDev. ID NS / Join ACK (9) 6 top (Co. AP/DTLS) draft-richardson-6 tisch--security-6 top DTLS connection Has client and server Autonomic certificates 26
RPL option status and update 6 lo
draft-thubert-6 lo-rpl-nhc-02 • Mostly converged with Carsten • Intent to have a common draft • Isolated debate greedy vs. conservative 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+ | NHC: I=1, K=1 | Sender. Rank | +-+-+-+-+-+-+-+-+ 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NHC: I=0, K=0 | RPLInstance. ID | Sender. Rank | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The RFC Style Guide RFC 7322 http: //www. rfceditor. org/styleguide. html
RFC 7322: "RFC Style Guide" The RPC is manually fixing these items, while the tools do not yet provide this functionality: Section 4: Unnumbered sections (related ticket for xml 2 rfc v 2) Section 4. 8. 6. 3: Referencing STDs and BCPs (related ticket for xml 2 rfc v 2) Section 4. 8. 6. 4: Referencing Internet-Drafts "Authors' Addresses" will appear in the Table of Contents (related ticket for xml 2 rfc v 2) Note that some of these fixes occur in the final stages of the publication process; i. e. , the changes are applied to 30 the. nroff file to get the required. txt output.
Web Portion of the Style Guide – detailed hereafter Status of This Memo Boilerplate - "Status of This Memo" text as defined by RFC 5741 Abbreviations List - Expansions of abbreviations (and acronyms) in RFCs Terms List - Table of decisions on consistent usage in RFCs IAB Format - IAB-specific format for RFCs in the IAB stream. Old materials (replaced by the documents above): RFC Editorial Policies - A collection of policies on RFC editorial issues. "Instructions to RFC Authors" - A draft replacement for RFC 2223. 31
No expansion This list includes some terms that look like abbreviations but are actually fixed names for things, and hence cannot and should not be expanded. These are noted as "No expansion". ----------------------------------- • … • 6 CO - 6 Lo. WPAN Context Option (6 CO) (RFC 6775) • 6 LBR - 6 Lo. WPAN Border Router (6 LBR) (RFC 6345) • 6 LN - 6 Lo. WPAN Node (6 LN) (RFC 6775) • 6 Lo. WPANs - IPv 6 over Low-Power Wireless Personal Area Networks (6 Lo. WPANs) (RFC 4919) • 6 LR - 6 Lo. WPAN Router (6 LR) (RFC 6606) • …
MUSTs • RFC numbers may be used as modifiers in running text, but they must appear as follows: no hyphens between "RFC" and the number (e. g. , RFC-5011 style rollover); a space should appear between the RFC and the number (e. g. , RFC 5011 style rollover) • avoid hyphenating citations with text (e. g. , don't use [RFC 5011]-style rollover) • if the sentence is unclear or potentially confusing, the sentence will be rewritten when possible. Otherwise, the issue will be raised with the authors for discussion.
RECOMMENDED Length of Sections All RFCs are naturally divided in to sections. We recommend that the length of a section or subsection be limited to allow for easily referenced objects. Avoid using abbreviations as verbs when possible. If Abbreviations unavoidable, suffixes should be affixed without punctuation, as Verbs for example, "XORed" (not XOR'ed) and "NATed" (not NATed). Expanding Abbreviations should be expanded upon first use. The abbreviations abbreviated form should be used thereafter. upon first use Use of didactic capitalization is not needed. For example: Extensible Markup Language (XML) (not Didactic Capitalization EXtensible Markup Language (XML) or e. Xtensible Markup Language (XML))
RECOMMENDED (con’t) In-text Citations (bracketed citation) An in-text citation may a) be read as part of the text or b) follow the subject for which it is being cited. For example: a)As part of the transition to IPv 6, NAT 64 [RFC 6146] and DNS 64 [RFC 6147] technologies will be utilized by some access networks to provide IPv 4 connectivity for IPv 6 -only nodes [RFC 6144]. or b) Note that SAVI raises a number of important privacy considerations that are discussed more fully in [RFC 6959]. We recommend using a) and strongly recommend consistent use of one style throughout. • This is mostly left to author preference. However, note the following: Referring to Instances of "[RFCXXXX] section N. N" will be updated as "[RFCXXXX], specific Section N. N" in most cases. sections within • If that format may be unclear, the text will be updated as "Section N. N another of [RFCXXXX]". document • If neither option works for some reason, a question will be sent to the authors.
AOB ?
Next meetings and deadlines • Monday 10/27 I-D cutoff – – • • • draft-ietf-6 tisch-minimal? draft-ietf-6 tisch-tsch? draft-ietf-6 tisch-6 top-interface ( reviews!) Others? Monday 10/27: draft WG meeting agenda Tuesday 10/28: security DT webex Monday 11/03: final WG meeting agenda Monday 11/03: slides IETF 91 Friday 11/07: 6 Ti. SCH webex – Goal: review slides
Thank you!
Скачать презентацию 10 24 2014 Webex IPv 6 over the TSCH mode
a1eb2541a964b235562c0efb6e29211a.ppt