[要約] RFC 9030は、IEEE 802.15.4のTime-Slotted Channel Hopping (TSCH) モード上でIPv6を効率的に動作させるためのアーキテクチャを定義します。この文書の目的は、低電力かつ信頼性の高い無線通信環境を提供することにあり、特に産業オートメーションやスマートビルディングなどの用途で利用されます。
Internet Engineering Task Force (IETF) P. Thubert, Ed.
Request for Comments: 9030 Cisco Systems
Category: Informational May 2021
ISSN: 2070-1721
An Architecture for IPv6 over the Time-Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)
IEEE 802.15.4（6tisch）のタイムスロットチャネルホッピングモードに対するIPv6のアーキテクチャ
Abstract
概要
This document describes a network architecture that provides low-latency, low-jitter, and high-reliability packet delivery. It combines a high-speed powered backbone and subnetworks using IEEE 802.15.4 time-slotted channel hopping (TSCH) to meet the requirements of low-power wireless deterministic applications.
このドキュメントでは、低遅延、低ジッタ、および信頼性の高いパケット配信を提供するネットワークアーキテクチャについて説明します。IEEE 802.15.4タイムスロットチャネルホッピング（TSCH）を使用して、高速パワーバックボーンとサブネットワークを組み合わせて、低電力無線決定論的アプリケーションの要件を満たしています。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
この文書はインターネット標準のトラック仕様ではありません。情報提供のために公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。IESGによって承認されたすべての文書がすべてのレベルのインターネット規格の候補者ではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9030.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法については、https://www.rfc-editor.org/info/rfc9030で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2021 IETF信頼と文書著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、このドキュメントの発行日に有効なBCP 78およびIETFドキュメントに関連するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。 これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
2. Terminology
2.1. New Terms
2.2. Abbreviations
2.3. Related Documents
3. High-Level Architecture
3.1. A Non-broadcast Multi-access Radio Mesh Network
3.2. A Multi-Link Subnet Model
3.3. TSCH: a Deterministic MAC Layer
3.4. Scheduling TSCH
3.5. Distributed vs. Centralized Routing
3.6. Forwarding over TSCH
3.7. 6TiSCH Stack
3.8. Communication Paradigms and Interaction Models
4. Architecture Components
4.1. 6LoWPAN (and RPL)
4.1.1. RPL-Unaware Leaves and 6LoWPAN ND
4.1.2. 6LBR and RPL Root
4.2. Network Access and Addressing
4.2.1. Join Process
4.2.2. Registration
4.3. TSCH and 6top
4.3.1. 6top
4.3.2. Scheduling Functions and the 6top Protocol
4.3.3. 6top and RPL Objective Function Operations
4.3.4. Network Synchronization
4.3.5. Slotframes and CDU Matrix
4.3.6. Distributing the Reservation of Cells
4.4. Schedule Management Mechanisms
4.4.1. Static Scheduling
4.4.2. Neighbor-to-Neighbor Scheduling
4.4.3. Remote Monitoring and Schedule Management
4.4.4. Hop-by-Hop Scheduling
4.5. On Tracks
4.5.1. General Behavior of Tracks
4.5.2. Serial Track
4.5.3. Complex Track with Replication and Elimination
4.5.4. DetNet End-to-End Path
4.5.5. Cell Reuse
4.6. Forwarding Models
4.6.1. Track Forwarding
4.6.2. IPv6 Forwarding
4.6.3. Fragment Forwarding
4.7. Advanced 6TiSCH Routing
4.7.1. Packet Marking and Handling
4.7.2. Replication, Retries, and Elimination
5. IANA Considerations
6. Security Considerations
6.1. Availability of Remote Services
6.2. Selective Jamming
6.3. MAC-Layer Security
6.4. Time Synchronization
6.5. Validating ASN
6.6. Network Keying and Rekeying
7. References
7.1. Normative References
7.2. Informative References
Appendix A. Related Work in Progress
A.1. Unchartered IETF Work Items
A.1.1. 6TiSCH Zero-Touch Security
A.1.2. 6TiSCH Track Setup
A.1.3. Using BIER in a 6TiSCH Network
A.2. External (Non-IETF) Work Items
Acknowledgments
Contributors
Author's Address
Wireless networks enable a wide variety of devices of any size to get interconnected, often at a very low marginal cost per device, at any range, and in circumstances where wiring may be impractical, for instance, on fast-moving or rotating devices.
ワイヤレスネットワークは、任意の範囲で、任意の範囲内、および配線が実用的でない可能性がある状況において、任意の範囲内の非常に低い限界コストで、任意のサイズの多種多様な装置を任意の範囲で、例えば速い動きまたは回転装置でも実用的であることを可能にする。
On the other hand, Deterministic Networking maximizes the packet delivery ratio within a bounded latency so as to enable mission-critical machine-to-machine (M2M) operations. Applications that need such networks are presented in [RFC8578] and [RAW-USE-CASES], which presents a number of additional use cases for Reliable and Available Wireless networks (RAW). The considered applications include professional media, Industrial Automation and Control Systems (IACS), building automation, in-vehicle command and control, commercial automation and asset tracking with mobile scenarios, as well as gaming, drones and edge robotic control, and home automation applications.
一方、決定論的ネットワークは、ミッションクリティカルマシン（M2M）操作を可能にするために、境界待ち時間内のパケット配信率を最大化する。そのようなネットワークを必要とするアプリケーションは、[RFC8578]と[Raw-Use-Sepose]に表示されます。これは、信頼性が高く利用可能な無線ネットワーク（RAW）のためのいくつかの追加のユースケースを示しています。検討されたアプリケーションには、プロのメディア、産業自動化、制御システム（IACS）、ビルの自動化、車載コマンド、および制御、商業自動化、および携帯シナリオを備えた資産の追跡、ゲーム、ドローン、およびエッジロボット制御、およびホームオートメーションアプリケーションが含まれます。。
The Time-Slotted Channel Hopping (TSCH) [RFC7554] mode of the IEEE Std 802.15.4 [IEEE802154] Medium Access Control (MAC) was introduced with the IEEE Std 802.15.4e [IEEE802154e] amendment and is now retrofitted in the main standard. For all practical purposes, this document is expected to be insensitive to the revisions of that standard, which is thus referenced without a date. TSCH is both a Time-Division Multiplexing (TDM) and a Frequency-Division Multiplexing (FDM) technique, whereby a different channel can be used for each transmission. TSCH allows the scheduling of transmissions for deterministic operations and applies to the slower and most energy-constrained wireless use cases.
IEEE STD 802.15.4 [IEEE802154]のタイムスロットチャンネルホッピング（TSCH）[RFC7554]ミディアムアクセス制御（MAC）は、IEEE STD 802.15.4E [IEEE802154E]の修正で導入され、現在主標準で後付けされました。。すべての実用的な目的のために、この文書はその標準の改訂に対して鈍感であると予想されています。これは日付なしで参照されます。TSCHは、時分割多重（TDM）と周波数分割多重化（FDM）技術の両方であり、それによって異なるチャネルを各送信に使用することができる。TSCHは、決定論的演算のための送信のスケジューリングを可能にし、より遅いほとんどのエネルギー制約の無線ユースケースに適用されます。
The scheduled operation provides for a more reliable experience, which can be used to monitor and manage resources, e.g., energy and water, in a more efficient fashion.
スケジュールされた操作は、より信頼性の高い経験を提供し、それはより効率的な方法で、リソース、例えばエネルギーおよび水を監視および管理するために使用することができる。
Proven deterministic networking standards for use in process control, including ISA100.11a [ISA100.11a] and WirelessHART [WirelessHART], have demonstrated the capabilities of the IEEE Std 802.15.4 TSCH MAC for high reliability against interference, low-power consumption on well-known flows, and its applicability for Traffic Engineering (TE) from a central controller.
ISA100.11A [ISA100.11A]およびWirelessHART [WirelessHart]を含むプロセス制御で使用するための実証済みの決定論的ネットワーキング基準は、干渉、低消費電力に対する高信頼性のためのIEEE STD 802.15.4 TSCH MACの機能を実証しました。 - 知文の流れ、そして中央制御装置からの交通技術（TE）への適用性
To enable the convergence of information technology (IT) and operational technology (OT) in Low-Power and Lossy Networks (LLNs), the 6TiSCH architecture supports an IETF suite of protocols over the IEEE Std 802.15.4 TSCH MAC to provide IP connectivity for energy and otherwise constrained wireless devices.
低電力および非損失ネットワーク（LLN）における情報技術（IT）および業務技術（OT）の収束を可能にするために、6TischアーキテクチャはIEEE STD 802.15.4 TSCH MACを介したIETFスイートのプロトコルをサポートしてIP接続を提供する。エネルギーとその他の方法で制約のある無線装置。
The 6TiSCH architecture relies on IPv6 [RFC8200] and the use of routing to provide large scaling capabilities. The addition of a high-speed federating backbone adds yet another degree of scalability to the design. The backbone is typically a Layer 2 transit link such as an Ethernet bridged network, but it can also be a more complex routed structure.
6Tischアーキテクチャは、IPv6 [RFC8200]に依存し、大きなスケーリング機能を提供するためのルーティングの使用。高速連合骨格を追加すると、設計にさらに別の程度のスケーラビリティが追加されています。バックボーンは通常、イーサネットブリッジネットワークなどのレイヤ2トランジットリンクですが、より複雑なルーティング構造でもあります。
The 6TiSCH architecture introduces an IPv6 multi-link subnet model that is composed of a federating backbone and a number of IEEE Std 802.15.4 TSCH low-power wireless networks federated and synchronized by Backbone Routers. If the backbone is a Layer 2 transit link, then the Backbone Routers can operate as an IPv6 Neighbor Discovery (IPv6 ND) proxy [RFC4861].
6Tischアーキテクチャでは、連合バックボーンと、バックボーンルータによって連携して同期された、連携バックボーンと、数のIEEE STD 802.15.4 TSCH低電力無線ネットワークで構成されているIPv6マルチリンクサブネットモデルが導入されています。バックボーンがレイヤ2トランジットリンクの場合、バックボーンルータはIPv6ネイバーディスカバリ（IPv6 ND）プロキシ[RFC4861]として動作できます。
The 6TiSCH architecture leverages 6LoWPAN [RFC4944] to adapt IPv6 to the constrained media and the Routing Protocol for Low-Power and Lossy Networks (RPL) [RFC6550] for the distributed routing operations.
6tischアーキテクチャは、6lowpan [RFC4944]を活用して、IPv6を制約メディアに適応させ、分散ルーティング操作のための低電力および非損失ネットワーク（RPL）[RFC6550]のルーティングプロトコルを調整します。
Centralized routing refers to a model where routes are computed and resources are allocated from a central controller. This is particularly helpful to schedule deterministic multihop transmissions. In contrast, distributed routing refers to a model that relies on concurrent peer-to-peer protocol exchanges for TSCH resource allocation and routing operations.
集中ルーティングは、ルートが計算され、リソースが中央コントローラから割り当てられているモデルを指します。これは、決定論的マルチホップ送信をスケジュールすることに特に役立ちます。対照的に、分散ルーティングは、TSCHリソース割り当ておよびルーティング操作のための同時ピアツーピアプロトコル交換に依存するモデルを指します。
The architecture defines mechanisms to establish and maintain routing and scheduling in a centralized, distributed, or mixed fashion, for use in multiple OT environments. It is applicable in particular to highly scalable solutions such as those used in Advanced Metering Infrastructure [AMI] solutions that leverage distributed routing to enable multipath forwarding over large LLN meshes.
アーキテクチャは、複数のOT環境で使用するための、集中型、分散型、または混合的な方法でルーティングとスケジューリングを確立して維持するためのメカニズムを定義します。特に、分散ルーティングを活用した高度な計量インフラストラクチャ[AMI]ソリューションで使用される高度にスケーラブルなソリューションには、大きなLLNメッシュを超えるマルチパス転送を可能にします。
The document does not reuse terms from the IEEE Std 802.15.4 [IEEE802154] standard such as "path" or "link", which bear a meaning that is quite different from classical IETF parlance.
この文書は、「PATH」または「リンク」などのIEEE STD 802.15.4 [IEEE802154]の規格からの用語を再利用しません。
This document adds the following terms:
この文書は次の条件を追加します。
6TiSCH (IPv6 over the TSCH mode of IEEE 802.15.4): 6TiSCH defines an adaptation sublayer for IPv6 over TSCH called 6top, a set of protocols for setting up a TSCH schedule in distributed approach, and a security solution. 6TiSCH may be extended in the future for other MAC/Physical Layer (PHY) pairs providing a service similar to TSCH.
6Tisch（IEEE 802.15.4のTSCHモードでのIPv6）：6tisch 6tisch 6topと呼ばれるTSCH毎のIPv6のための適応サブレイヤ、分散アプローチでTSCHスケジュールを設定するためのプロトコルのセット、およびセキュリティソリューションを定義します。6tischは、TSCHと同様のサービスを提供する他のMAC /物理層（PHY）ペアについて将来延長されることがあります。
6top (6TiSCH Operation Sublayer): The next higher layer of the IEEE Std 802.15.4 TSCH MAC layer. 6top provides the abstraction of an IP link over a TSCH MAC, schedules packets over TSCH cells, and exposes a management interface to schedule TSCH cells.
6top（6tisch操作サブレイヤ）：IEEE STD 802.15.4 TSCH MAC層の次の上位層。6topは、TSCH MACを介したIPリンクの抽象化を提供し、TSCHセルを介してパケットをスケジュールし、TSCHセルをスケジュールするための管理インターフェースを公開します。
6P (6top Protocol): The protocol defined in [RFC8480]. 6P enables Layer 2 peers to allocate, move, or de-allocate cells in their respective schedules to communicate. 6P operates at the 6top sublayer.
6p（6topプロトコル）：[RFC8480]で定義されているプロトコル。6pレイヤ2ピアは、通信するためにそれぞれのスケジュール内のセルを割り当て、移動、または割り当て解除することができます。6Pは6社のサブレイヤで動作します。
6P transaction: A 2-way or 3-way sequence of 6P messages used by Layer 2 peers to modify their communication schedule.
6Pトランザクション：それらの通信スケジュールを変更するためにレイヤ2ピアによって使用される6Pメッセージの2方向または3方向シーケンス。
ASN (Absolute Slot Number): Defined in [IEEE802154], the ASN is the total number of timeslots that have elapsed since the Epoch time when the TSCH network started. Incremented by one at each timeslot. It is wide enough to not roll over in practice.
ASN（Absolute Slot Number）：[IEEE802154]で定義されている場合、ASNはTSCHネットワークが開始された時期以降経過したタイムスロットの総数です。各タイムスロットに1つずつ増分。実際にロールオーバーしないほど広い。
bundle: A group of equivalent scheduled cells, i.e., cells identified by different slotOffset/channelOffset, which are scheduled for a same purpose, with the same neighbor, with the same flags, and the same slotframe. The size of the bundle refers to the number of cells it contains. For a given slotframe length, the size of the bundle translates directly into bandwidth. A bundle is a local abstraction that represents a half-duplex link for either sending or receiving, with bandwidth that amounts to the sum of the cells in the bundle.
バンドル：同等のスケジュールされたセルのグループ、すなわち、同じ目的で同じ目的でスケジュールされ、同じフラグ、および同じスロットフレームで同じ目的でスケジュールされているセル。バンドルのサイズとは、それが含むセルの数を表します。与えられたスロットフレーム長の場合、バンドルのサイズは直接帯域幅に変換されます。バンドルは、バンドル内のセルの合計になる帯域幅を持つ、送信または受信のための半二重リンクを表すローカルの抽象化です。
Layer 2 vs. Layer 3 bundle: Bundles are associated with either Layer 2 (switching) or Layer 3 (routing) forwarding operations. A pair of Layer 3 bundles (one for each direction) maps to an IP link with a neighbor, whereas a set of Layer 2 bundles (of an "arbitrary" cardinality and direction) corresponds to the relation of one or more incoming bundle(s) from the previous-hop neighbor(s) with one or more outgoing bundle(s) to the next-hop neighbor(s) along a Track as part of the switching role, which may include replication and elimination.
レイヤ2 VS.レイヤ3バンドル：バンドルは、レイヤ2（スイッチング）またはレイヤ3（ルーティング）転送操作のいずれかに関連付けられています。一対のレイヤ3バンドル（各方向の1つ）は、隣接とのIPリンクにマッピングされ、一方、一組のレイヤ2バンドル（「任意の「カーディナリティーおよび方向の」）は、1つまたは複数の入り込みバンドルの関係に対応する（Sスイッチングロールの一部として、1つまたは複数の発信バンドル（S）をスイッチングロールの一部として、1つまたは複数の発信バンドルをトラックに沿った前回ホップ隣接（S）から、レプリケーションおよび除去を含むことができる。
CCA (Clear Channel Assessment): A mechanism defined in [IEEE802154] whereby nodes listen to the channel before sending to detect ongoing transmissions from other parties. Because the network is synchronized, CCA cannot be used to detect colliding transmissions within the same network, but it can be used to detect other radio networks in the vicinity.
CCA（クリアチャネルアセスメント）：[IEEE802154]で定義されているメカニズムは、ノードが他の当事者からの進行中の送信を検出するために送信する前にチャネルを待機します。ネットワークは同期されているので、CCAを使用して同じネットワーク内の衝突伝送を検出することはできませんが、近くの他の無線ネットワークを検出するために使用できます。
cell: A unit of transmission resource in the CDU matrix, a cell is identified by a slotOffset and a channelOffset. A cell can be scheduled or unscheduled.
セル：CDUマトリックス内の送信リソースの単位、セルはSlotOffsetとチャネルオフセットによって識別されます。セルはスケジュールされていないか、または予定解除されます。
Channel Distribution/Usage (CDU) matrix: : A matrix of cells (i,j) representing the spectrum (channel) distribution among the different nodes in the 6TiSCH network. The CDU matrix has width in timeslots equal to the period of the network scheduling operation, and height equal to the number of available channels. Every cell (i,j) in the CDU, identified by slotOffset/ channelOffset, belongs to a specific chunk.
チャネル配信/使用法（CDU）行列：：6Tischネットワーク内の異なるノード間のスペクトル（チャネル）分布を表すセル（I、J）の行列。CDUマトリックスは、ネットワークスケジューリング動作の期間に等しいタイムスロットの幅、および利用可能なチャンネルの数に等しい高さを有する。SlotOffSet / ChannelOffsetによって識別されるCDU内のすべてのセル（I、J）は、特定のチャンクに属します。
channelOffset: Identifies a row in the TSCH schedule. The number of channelOffset values is bounded by the number of available frequencies. The channelOffset translates into a frequency with a function that depends on the absolute time when the communication takes place, resulting in a channel-hopping operation.
ChannelOffSet：TSCHスケジュール内の行を識別します。チャネルオフセット値の数は、利用可能な周波数の数によってバラされています。ChannelOffSetは、通信が行われたときの絶対時間に依存する関数を持つ周波数に変換され、その結果チャネルホッピング動作が得られます。
chunk: A well-known list of cells, distributed in time and frequency, within a CDU matrix. A chunk represents a portion of a CDU matrix. The partition of the CDU matrix in chunks is globally known by all the nodes in the network to support the appropriation process, which is a negotiation between nodes within an interference domain. A node that manages to appropriate a chunk gets to decide which transmissions will occur over the cells in the chunk within its interference domain, i.e., a parent node will decide when the cells within the appropriated chunk are used and by which node among its children.
チャンク：CDUマトリックス内で、時間と周波数で分配された、よく知られているセルのリスト。チャンクはCDU行列の一部を表します。チャンク内のCDUマトリックスのパーティションは、干渉ドメイン内のノード間の交渉である、ネットワーク内のすべてのノードによってグローバルに知られています。適切なチャンクを管理するノードは、その干渉ドメイン内のチャンク内のセルを介してどの送信が行われるか、すなわち、親ノードが、割り当てられたチャンク内のセルが使用され、どのノードがその子の間でどのノードを使用するかを決定する。
CoJP (Constrained Join Protocol): The Constrained Join Protocol (CoJP) enables a pledge to securely join a 6TiSCH network and obtain network parameters over a secure channel. "Constrained Join Protocol (CoJP) for 6TiSCH" [RFC9031] defines the minimal CoJP setup with pre-shared keys defined. In that mode, CoJP can operate with a single round-trip exchange.
COJP（制約付き結合プロトコル）：制約付き結合プロトコル（COJP）は、誓約が6Tischネットワークを安全に接合し、安全なチャネルを介してネットワークパラメータを取得することを可能にします。"6tischのClancied Join Protocol（COJP）" [RFC9031]が定義された事前共有キーを使用して最小COJP設定を定義します。そのモードでは、COJPは単一の往復交換で動作することができます。
dedicated cell: A cell that is reserved for a given node to transmit to a specific neighbor.
専用セル：特定のネイバーに送信するために特定のノード用に予約されているセル。
deterministic network: The generic concept of a deterministic network is defined in the "Deterministic Networking Architecture" [RFC8655] document. When applied to 6TiSCH, it refers to the reservation of Tracks, which guarantees an end-to-end latency and optimizes the Packet Delivery Ratio (PDR) for well-characterized flows.
決定論的ネットワーク：決定論的ネットワークの一般的な概念は、「決定論的ネットワーキングアーキテクチャ」[RFC8655]文書で定義されています。6tischに適用すると、それはトラックの予約を参照し、それはエンドツーエンドの待ち時間を保証し、そして十分に特徴付けられたフローのためのパケット配信比（PDR）を最適化する。
distributed cell reservation: A reservation of a cell done by one or more in-network entities.
分散セル予約：1つ以上のネットワークエンティティによって完了したセルの予約。
distributed Track reservation: A reservation of a Track done by one or more in-network entities.
分散型トラック予約：1つ以上のネットワークエンティティによって行われたトラックの予約。
EB (Enhanced Beacon): A special frame defined in [IEEE802154] used by a node, including the Join Proxy (JP), to announce the presence of the network. It contains enough information for a pledge to synchronize to the network.
EB（Enhanced Beacon）：ネットワークの存在を発表するための、結合プロキシ（JP）を含むノードで使用される[IEEE802154]で定義されている特別なフレーム。それはネットワークと同期するための誓約のための十分な情報を含みます。
hard cell: A scheduled cell that the 6top sublayer may not relocate.
ハードセル：6社のサブレイヤが移行しないようなスケジュールセル。
hopping sequence: Ordered sequence of frequencies, identified by a Hopping_Sequence_ID, used for channel hopping when translating the channelOffset value into a frequency.
ホッピングシーケンス：チャネルオフセット値を周波数に変換するときにチャネルホッピングに使用される、hopping_sequence_idによって識別される周波数の順序順序。
IE (Information Element): Type-Length-Value containers placed at the end of the MAC header and used to pass data between layers or devices. Some IE identifiers are managed by the IEEE [IEEE802154]. Some IE identifiers are managed by the IETF [RFC8137]. [RFC9032] uses one subtype to support the selection of the Join Proxy.
IE（情報要素）：Type-Length-Valueコンテナは、MACヘッダーの末尾に配置され、レイヤーまたはデバイス間でデータを渡すために使用されます。いくつかのIE識別子はIEEE [IEEE802154]によって管理されています。一部のIE識別子はIETF [RFC8137]によって管理されています。[RFC9032]結合プロキシの選択をサポートするために1つのサブタイプを使用します。
join process: The overall process that includes the discovery of the network by pledge(s) and the execution of the join protocol.
結合プロセス：ネットワークの検出を含む全体的なプロセス（S）と結合プロトコルの実行。
join protocol: The protocol that allows the pledge to join the network. The join protocol encompasses authentication, authorization, and parameter distribution. The join protocol is executed between the pledge and the JRC.
Protocol：Predgeがネットワークに参加できるプロトコル。結合プロトコルは、認証、許可、およびパラメータ配布を網羅しています。結合プロトコルは、PREDGEとJRCの間で実行されます。
joined node: The new device after having completed the join process, often just called a node.
結合されたノード：結合プロセスを完了した後の新しいデバイスは、しばしばノードと呼ばれます。
JP (Join Proxy): A node already part of the 6TiSCH network that serves as a relay to provide connectivity between the pledge and the JRC. The JP announces the presence of the network by regularly sending EB frames.
JP（結合プロキシ）：既にPLEDDEとJRCの間の接続性を提供するためのリレーとして機能する6Tischネットワークのノード。JPは、EBフレームを定期的に送信することによってネットワークの存在を発表する。
JRC (Join Registrar/Coordinator): Central entity responsible for the authentication, authorization, and configuration of the pledge.
JRC（登録レジストラ/コーディネータ）：誓約書の認証、承認、および構成を担当する中央エンティティ。
link: A communication facility or medium over which nodes can communicate at the link layer, which is the layer immediately below IP. In 6TiSCH, the concept is implemented as a collection of Layer 3 bundles. Note: the IETF parlance for the term "link" is adopted, as opposed to the IEEE Std 802.15.4 terminology.
リンク：ノードがIPのすぐ下のレイヤであるリンク層でノードが通信できる通信機能または媒体。6Tischでは、概念はレイヤ3バンドルの集合として実装されています。注：IEEE STD 802.15.4用語とは対照的に、「リンク」という用語のIETFパラランスが採用されています。
operational technology: OT refers to technology used in automation, for instance in industrial control networks. The convergence of IT and OT is the main object of the Industrial Internet of Things (IIOT).
オペレーショナル技術：OTとは、自動化、例えば産業用制御ネットワークで使用される技術を指します。ITとOTの収束は、物の産業インターネットの主な目的（IIOT）です。
pledge: A new device that attempts to join a 6TiSCH network.
pledge：6tischネットワークに参加しようとする新しいデバイス。
(to) relocate a cell: The action operated by the 6top sublayer of changing the slotOffset and/or channelOffset of a soft cell.
（へ）セルを移動させる：6社のサブレイヤによって操作されるアクションは、SlotOffsetを変更することの6つの副層および/またはソフトセルのチャネルオフセットを変更する。
(to) schedule a cell: The action of turning an unscheduled cell into a scheduled cell.
（へ）セルをスケジュールする：予定外のセルをスケジュールされたセルに変える動作。
scheduled cell: A cell that is assigned a neighbor MAC address (broadcast address is also possible) and one or more of the following flags: TX, RX, Shared, and Timekeeping. A scheduled cell can be used by the IEEE Std 802.15.4 TSCH implementation to communicate. A scheduled cell can either be a hard or a soft cell.
スケジュールセル：ネイバーMACアドレス（ブロードキャストアドレスも可能）および以下のフラグのうちの1つ以上が割り当てられているセル：Tx、Rx、Shared、およびTimekeeping。スケジュールされたセルは、通信するためにIEEE STD 802.15.4 TSCH実装によって使用され得る。スケジュールされたセルは、硬いセルまたは柔らかいセルのいずれかであり得る。
SF (6top Scheduling Function): The cell management entity that adds or deletes cells dynamically based on application networking requirements. The cell negotiation with a neighbor is done using 6P.
SF（6topスケジューリング機能）：アプリケーションネットワーク要件に基づいて細胞を動的に追加または削除するセル管理エンティティ。隣人とのセル交渉は6Pを使用して行われます。
SFID (6top Scheduling Function Identifier): A 4-bit field identifying an SF.
SFID（6topスケジューリング機能識別子）：SFを識別する4ビットフィールド。
shared cell: A cell marked with both the TX and Shared flags. This cell can be used by more than one transmitter node. A back-off algorithm is used to resolve contention.
共有セル：TXフラグと共有フラグの両方でマークされたセル。このセルは、複数の送信機ノードで使用できます。競合を解決するためにバックオフアルゴリズムが使用されます。
slotframe: A collection of timeslots repeating in time, analogous to a superframe in that it defines periods of communication opportunities. It is characterized by a slotframe_ID and a slotframe_size. Multiple slotframes can coexist in a node's schedule, i.e., a node can have multiple activities scheduled in different slotframes based on the priority of its packets/traffic flows. The timeslots in the slotframe are indexed by the slotOffset; the first timeslot is at slotOffset 0.
SlotFrame：通信機会の期間を定義するという点でスーパーフレームに類似して、時間的に繰り返すタイムスロットの集まり。これはslotframe_idとslotframe_sizeによって特徴付けられます。複数のスロットフレームは、ノードのスケジュールで共存させることができます。すなわち、ノードは、パケット/トラフィックフローの優先順位に基づいて異なるスロットフレームでスケジュールされた複数のアクティビティを持つことができます。スロットフレーム内のタイムスロットはSlotOffsetによって索引付けされます。最初のタイムスロットはスロットオフセット0です。
slotOffset: A column in the TSCH schedule, i.e., the number of timeslots since the beginning of the current iteration of the slotframe.
SlotOffSet：TSCHスケジュールの列、すなわちスロットフレームの現在の反復の開始以降のタイムスロットの数。
soft cell: A scheduled cell that the 6top sublayer can relocate.
ソフトセル：6件のサブレイヤが移動できるスケジュールセル。
time source neighbor: A neighbor that a node uses as its time reference, and to which it needs to keep its clock synchronized.
タイムソースネイバー：ノードがその時間リファレンスとして使用するネイバー、およびそのクロックを同期させ続ける必要があるか。
timeslot: A basic communication unit in TSCH that allows a transmitter node to send a frame to a receiver neighbor and that allows the receiver neighbor to optionally send back an acknowledgment.
Timeslot：TSCHの基本的な通信ユニットは、送信機ノードが受信側の隣接にフレームを送信することを可能にし、受信側ネイバーがオプションで確認応答を送信することを可能にする。
Track: A Track is a Directed Acyclic Graph (DAG) that is used as a complex multihop path to the destination(s) of the path. In the case of unicast traffic, the Track is a Destination-Oriented DAG (DODAG) where the Root of the DODAG is the destination of the unicast traffic. A Track enables replication, elimination, and reordering functions on the way (more on those functions in [RFC8655]). A Track reservation locks physical resources such as cells and buffers in every node along the DODAG. A Track is associated with an owner, which can be for instance the destination of the Track.
トラック：トラックは、パスの宛先への複素マルチホップパスとして使用される有向の非環式グラフ（DAG）です。ユニキャストトラフィックの場合、トラックはDoDagのルートがユニキャストトラフィックの宛先である宛先指向のDAG（DODAG）です。トラックは、途中での関数、除去、および並べ替え機能を可能にします（[RFC8655]の機能について）。トラック予約は、DODAGに沿ってすべてのノードにセルやバッファなどの物理的なリソースをロックします。トラックは所有者に関連付けられています。これは、例えばトラックの宛先です。
TrackID: A TrackID is either globally unique or locally unique to the Track owner, in which case the identification of the owner must be provided together with the TrackID to provide a full reference to the Track. Typically, the Track owner is the ingress of the Track, the IPv6 source address of packets along the Track can be used as identification of the owner, and a local InstanceID [RFC6550] in the namespace of that owner can be used as TrackID. If the Track is reversible, then the owner is found in the IPv6 destination address of a packet coming back along the Track. In that case, a RPL Packet Information [RFC6550] in an IPv6 packet can unambiguously identify the Track and can be expressed in a compressed form using [RFC8138].
TRACKID：TRACKIDは、トラックの所有者にとってグローバルに固有またはローカルに固有のものです。その場合、所有者の識別はトラックへの完全な参照を提供するためにTRACKIDと一緒に提供されなければなりません。通常、トラック所有者はトラックの入力であり、トラックに沿ったパケットのIPv6ソースアドレスは所有者の識別として使用でき、その所有者のネームスペースのローカルInstanceID [RFC6550]はTRACKIDとして使用できます。トラックがリバーシブルである場合、所有者はトラックに沿って戻ってくるパケットのIPv6宛先アドレスにあります。その場合、IPv6パケット内のRPLパケット情報[RFC6550]は、トラックを明確に識別することができ、[RFC8138]を使用して圧縮された形式で表すことができます。
TSCH: A medium access mode of the IEEE Std 802.15.4 [IEEE802154] standard that uses time synchronization to achieve ultra-low-power operation and channel hopping to enable high reliability.
TSCH：IEEE STD 802.15.4 [IEEE802154]の中アクセスモードは、高電力動作とチャネルホッピングを実現するための時間同期を使用し、チャネルホッピングを実現するための標準です。
TSCH Schedule: A matrix of cells, with each cell indexed by a slotOffset and a channelOffset. The TSCH schedule contains all the scheduled cells from all slotframes and is sufficient to qualify the communication in the TSCH network. The number of channelOffset values (the "height" of the matrix) is equal to the number of available frequencies.
TSCHスケジュール：各セルはスロットオフセットとチャネルオフセットによって索引付けされたセルのマトリックス。TSCHスケジュールは、すべてのスロットフレームからのすべてのスケジュールされたセルを含み、TSCHネットワーク内の通信を修飾するのに十分です。チャンネルオフセット値の数（行列の「高さ」）は、利用可能な周波数の数に等しい。
Unscheduled Cell: A cell that is not used by the IEEE Std 802.15.4 TSCH implementation.
予定外セル：IEEE STD 802.15.4 TSCH実装で使用されていないセル。
This document uses the following abbreviations:
この文書は次の略語を使用します。
6BBR: 6LoWPAN Backbone Router (router with a proxy ND function)
6BBR：6ローパンバックボーンルータ（プロキシと機能を持つルーター）
6LBR: 6LoWPAN Border Router (authoritative on Duplicate Address Detection (DAD))
6LBR：6 Lowpan Border Router（重複アドレス検出（DAD）に関する信頼性）
6LN: 6LoWPAN Node
6LN：6lowpanノード
6LR: 6LoWPAN Router (relay to the registration process)
6LR：6LOWPANルーター（登録プロセスへのリレー）
6CIO: Capability Indication Option
6cio：能力指示オプション
(E)ARO: (Extended) Address Registration Option
（e）ARO :(拡張）アドレス登録オプション
(E)DAR: (Extended) Duplicate Address Request
（e）DAR :(拡張）重複アドレス要求
(E)DAC: (Extended) Duplicate Address Confirmation
（e）DAC :(拡張）二重アドレス確認
DAD: Duplicate Address Detection
DAD：重複アドレス検出
DODAG: Destination-Oriented Directed Acyclic Graph
DODAG：宛先指向特異的非巡回グラフ
LLN: Low-Power and Lossy Network (a typical IoT network)
LLN：低消費電力および非損失ネットワーク（典型的なIOTネットワーク）
NA: Neighbor Advertisement
NA：近隣広告
NCE: Neighbor Cache Entry
NCE：ネイバーキャッシュエントリ
ND: Neighbor Discovery
ND：ネイバーディスカバリー
NDP: Neighbor Discovery Protocol
NDP：ネイバーディスカバリープロトコル
PCE: Path Computation Element
PCE：パス計算要素
NME: Network Management Entity
NME：ネットワーク管理エンティティ
ROVR: Registration Ownership Verifier (pronounced rover)
ROVR：登録所有権検証者（宣伝されたローバー）
RPL: IPv6 Routing Protocol for LLNs (pronounced ripple)
RPL：LLNSのIPv6ルーティングプロトコル（発音したリップル）
RA: Router Advertisement
RA：ルーター広告
RS: Router Solicitation
RS：ルーターの勧誘
TSCH: Time-Slotted Channel Hopping
TSCH：タイムスロットチャンネルホッピング
TID: Transaction ID (a sequence counter in the EARO)
TID：トランザクションID（EAROのシーケンスカウンタ）
The document conforms to the terms and models described in [RFC3444] and [RFC5889], uses the vocabulary and the concepts defined in [RFC4291] for the IPv6 architecture, and refers to [RFC4080] for reservation.
この文書は[RFC3444]と[RFC5889]に記載されている用語とモデルに準拠しており、IPv6アーキテクチャの[RFC4291]で定義されている語彙と概念を使用し、予約のための[RFC4080]を参照してください。
The document uses domain-specific terminology defined or referenced in the following:
この文書は、次のように定義または参照されているドメイン固有の用語を使用します。
* 6LoWPAN ND: "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)" [RFC6775] and "Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery" [RFC8505],
* 6LOWPAN ND：「低電力無線パーソナルエリアネットワーク（6LOWPANS）」[RFC6775]および「低電力無線パーソナルエリアネットワークにおけるIPv6の登録拡張（6LOWPAN）近隣探索」[RFC8505]
* "Terms Used in Routing for Low-Power and Lossy Networks" [RFC7102], and
* 「低電力および非損失ネットワークのためのルーティングに使用される用語」[RFC7102]
* RPL: "Objective Function Zero for the Routing Protocol for Low-Power and Lossy Networks (RPL)" [RFC6552] and "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks" [RFC6550].
* RPL： "低電力および非損失ネットワーク（RPL）" [RFC6552]および「RPL：Low：Low-PowerネットワークのためのRPL：IPv6ルーティングプロトコル」[RFC6550]。
Other terms in use in LLNs are found in "Terminology for Constrained-Node Networks" [RFC7228].
LLNで使用されている他の用語は、「制約ノードネットワークの用語」[RFC7228]にあります。
Readers are expected to be familiar with all the terms and concepts that are discussed in the following:
読者は、次のように議論されるすべての条項と概念に精通していると予想されます。
* "Neighbor Discovery for IP version 6 (IPv6)" [RFC4861] and
* "IPバージョン6（IPv6）の隣接発見）[RFC4861]
* "IPv6 Stateless Address Autoconfiguration" [RFC4862].
* "IPv6ステートレスアドレス自動設定" [RFC4862]。
In addition, readers would benefit from reading the following prior to this specification for a clear understanding of the art in ND-proxying and binding:
さらに、リーダーは、NDプロキシとバインディングでの技術を明確に理解するために、この仕様の前に次のようになることから利益を得るでしょう。
* "Problem Statement and Requirements for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing" [RFC6606],
* "低電力無線パーソナルエリアネットワーク（6lowpan）ルーティングにおけるIPv6の問題報告と要件" [RFC6606]、
* "Multi-Link Subnet Issues" [RFC4903], and
* 「マルチリンクサブネットの問題」[RFC4903]、および
* "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals" [RFC4919].
* 「低電力無線パーソナルエリアネットワーク（6lowpans）上のIPv6：概要、仮定、問題ステートメント、および目標 "[RFC4919]。
A 6TiSCH network is an IPv6 [RFC8200] subnet that, in its basic configuration illustrated in Figure 1, is a single Low-Power and Lossy Network (LLN) operating over a synchronized TSCH-based mesh.
6Tischネットワークは、図1に示す基本構成では、同期TSCHベースのメッシュを介して動作する単一の低電力および非損失ネットワーク（LLN）であるIPv6 [RFC8200]サブネットです。
---+-------- ............ ------------
| External Network |
| +-----+
+-----+ | NME |
| | LLN Border | PCE |
| | router (6LBR) +-----+
+-----+
o o o
o o o o o
o o 6LoWPAN + RPL o o
o o o o
Figure 1: Basic Configuration of a 6TiSCH Network
図1：6Tischネットワークの基本構成
Inside a 6TiSCH LLN, nodes rely on 6LoWPAN header compression (6LoWPAN HC) [RFC6282] to encode IPv6 packets. From the perspective of the network layer, a single LLN interface (typically an IEEE Std 802.15.4-compliant radio) may be seen as a collection of links with different capabilities for unicast or multicast services.
6Tisch LLNの内側には、ノードが6LOWPANヘッダ圧縮（6LOWPAN HC）[RFC6282]に依存してIPv6パケットをエンコードします。ネットワーク層の観点から、単一のLLNインターフェース（通常はIEEE STD 802.15.4準拠の無線）は、ユニキャストまたはマルチキャストサービスに対するさまざまな機能を持つリンクの集まりとして見られます。
6TiSCH nodes join a mesh network by attaching to nodes that are already members of the mesh (see Section 4.2.1). The security aspects of the join process are further detailed in Section 6. In a mesh network, 6TiSCH nodes are not necessarily reachable from one another at Layer 2, and an LLN may span over multiple links.
6tischノードは、既にメッシュのメンバーのノードに接続することによってメッシュネットワークに参加します（セクション4.2.1を参照）。結合プロセスのセキュリティの態様は、セクション6においてさらに詳細に詳細に詳細に詳細に示されている。メッシュネットワークでは、6Tischノードは、レイヤ2で互いに必ずしも到達可能ではなく、LLNは複数のリンクにまたがることがある。
This forms a homogeneous non-broadcast multi-access (NBMA) subnet, which is beyond the scope of IPv6 Neighbor Discovery (IPv6 ND) [RFC4861] [RFC4862]. 6LoWPAN Neighbor Discovery (6LoWPAN ND) [RFC6775] [RFC8505] specifies extensions to IPv6 ND that enable ND operations in this type of subnet that can be protected against address theft and impersonation with [RFC8928].
これは、IPv6隣接発見の範囲を超えている均一な非放送マルチアクセス（NBMA）サブネットを形成します（IPv6 ND）[RFC4861] [RFC4862]。6lowpan隣接ディスカバリ（6lowpan ND）[RFC6775] [RFC8505]は、このタイプのサブネットでND操作を有効にするExtensionsを、[RFC8928]でアドレスの盗難や偽装に保護できるようにすることができます。
Once it has joined the 6TiSCH network, a node acquires IPv6 addresses and registers them using 6LoWPAN ND. This guarantees that the addresses are unique and protects the address ownership over the subnet, more in Section 4.2.2.
6Tischネットワークに参加したら、ノードはIPv6アドレスを取得し、それらを6lowpan NDを使用して登録する。これにより、アドレスが一意であり、サブネットを介してアドレスの所有権を保護し、セクション4.2.2で保証されます。
Within the NBMA subnet, RPL [RFC6550] enables routing in the so-called "route-over" fashion, either in storing (stateful) or non-storing (stateless, with routing headers) mode. From there, some nodes can act as routers for 6LoWPAN ND and RPL operations, as detailed in Section 4.1.
NBMAサブネット内では、RPL [RFC6550]では、いわゆる「ルートオーバー」ファッションで、（ステートフル）または非記憶（ステートレス、ルーティングヘッダー）モードをルーティングできます。そこから、セクション4.1に詳述されているように、いくつかのノードは6lowpan NDおよびRPL操作のためのルーターとして機能することができます。
With TSCH, devices are time synchronized at the MAC level. The use of a particular RPL Instance for time synchronization is discussed in Section 4.3.4. With this mechanism, the time synchronization starts at the RPL Root and follows the RPL loopless routing topology.
TSCHでは、デバイスはMACレベルで時間同期しています。時刻同期のための特定のRPLインスタンスの使用は、4.3.4項で説明されています。このメカニズムを使用すると、時間同期はRPLルートから始まり、RPLループレスルーティングトポロジに従います。
RPL forms Destination-Oriented Directed Acyclic Graphs (DODAGs) within Instances of the protocol, each Instance being associated with an Objective Function (OF) to form a routing topology. A particular 6TiSCH node, the LLN Border Router (6LBR), acts as RPL Root, 6LoWPAN HC terminator, and Border Router for the LLN to the outside. The 6LBR is usually powered. More on RPL Instances can be found in Section 3.1 of RPL [RFC6550], in particular "3.1.2 RPL Identifiers" and "3.1.3 Instances, DODAGs, and DODAG Versions". RPL adds artifacts in the data packets that are compressed with a 6LoWPAN Routing Header (6LoRH) [RFC8138]. In a preexisting network, the compression can be globally turned on in a DODAG once all nodes are migrated to support [RFC8138] using [RFC9035].
RPLは、プロトコルのインスタンス内の宛先指向の有向非巡回グラフ（DODAG）、各インスタンスはルーティングトポロジを形成するための客観的関数（）に関連付けられています。特定の6Tischノード、LLNボーダールータ（6LBR）は、RPLルート、6LOWPAN HCターミネータ、および外部へのLLNの境界ルータとして機能します。6LBRは通常電力を供給されます。RPLインスタンスの詳細は、RPL [RFC6550]のセクション3.1、特に「3.1.2 RPL識別子」および「3.1.3インスタンス、DODAGS、およびDODAGバージョン」にあります。RPLは、6LOWPANルーティングヘッダー（6lllh）[RFC8138]で圧縮されているデータパケットにアーティファクトを追加します。既存のネットワークでは、[RFC9035]を使用して[RFC8138]を使用して、すべてのノードがサポートされるようにマイグレーションされたら、圧縮をドダグでグローバルにオンにすることができます。
Additional routing and scheduling protocols may be deployed to establish on-demand, peer-to-peer routes with particular characteristics inside the 6TiSCH network. This may be achieved in a centralized fashion by a Path Computation Element (PCE) [PCE] that programs both the routes and the schedules inside the 6TiSCH nodes or in a distributed fashion by using a reactive routing protocol and a hop-by-hop scheduling protocol.
追加のルーティングおよびスケジューリングプロトコルは、6Tischネットワーク内の特定の特性を持つオンデマンド、ピアツーピアルートを確立するように展開されます。これは、6Tischノード内のルートとスケジュールの両方をプログラムする経路計算要素（PCE）によって、またはリアクティブルーティングプロトコルとホップバイホップスケジューリングを使用することによって分散型で集中的に達成することができる。プロトコル。
This architecture expects that a 6LoWPAN node can connect as a leaf to a RPL network, where the leaf support is the minimal functionality to connect as a host to a RPL network without the need to participate in the full routing protocol. The architecture also expects that a 6LoWPAN node that is unaware of RPL may also connect as described in [RFC9010].
このアーキテクチャは、6LOWPANノードがRPLネットワークへのリーフとして接続できることを期待しています。ここで、リーフのサポートは、フルルーティングプロトコルに参加する必要なしにRPLネットワークへのホストとして接続する最小限の機能です。アーキテクチャはまた、RPLの認識されていない6LOWPANノードも[RFC9010]に記載されているように接続することもあります。
An extended configuration of the subnet comprises multiple LLNs as illustrated in Figure 2. In the extended configuration, a Routing Registrar [RFC8505] may be connected to the node that acts as the RPL Root and/or 6LoWPAN 6LBR and provides connectivity to the larger campus or factory plant network over a high-speed backbone or a back-haul link. The Routing Registrar may perform IPv6 ND proxy operations; redistribute the registration in a routing protocol such as OSPF [RFC5340] or BGP [RFC2545]; or inject a route in a mobility protocol such as Mobile IPv6 (MIPv6) [RFC6275], Network Mobility (NEMO) [RFC3963], or Locator/ID Separation Protocol (LISP) [RFC6830].
サブネットの拡張構成は、図2に示すように複数のLLNを備えています。拡張構成では、RPLルートとして機能するノードに接続されているノードに接続されており、より大きなキャンパスに接続することができます。高速バックボーンまたはバックハウルリンクの上の工場プラントネットワーク。ルーティングレジストラはIPv6 NDプロキシ操作を実行することができます。OSPF [RFC5340]またはBGP [RFC2545]などのルーティングプロトコルで登録を再配布します。モバイルIPv6（MIPv6）[RFC6275]、ネットワークモビリティ（NEMO）[RFC3963]、またはLOCATOR / ID分離プロトコル（LISP）[RFC6830]などのモビリティプロトコル内のルートを注入する。
Multiple LLNs can be interconnected and possibly synchronized over a backbone, which can be wired or wireless. The backbone can operate with IPv6 ND procedures [RFC4861] [RFC4862] or a hybrid of IPv6 ND and 6LoWPAN ND [RFC6775] [RFC8505] [RFC8928].
複数のLLNを相互接続し、バックボーンを介して同期させることができます。バックボーンは、IPv6 ND手順[RFC4861] [RFC4862] [RFC4862]または6LOWPAN ND [RFC6775] [RFC8505] [RFC8928]で操作できます。
|
+-----+ +-----+ +-----+
(default) | | (Optional) | | | | IPv6
Router | | 6LBR | | | | Node
+-----+ +-----+ +-----+
| Backbone side | |
--------+---+--------------------+-+---------------+------+---
| | |
+-----------+ +-----------+ +-----------+
| Routing | | Routing | | Routing |
| Registrar | | Registrar | | Registrar |
+-----------+ +-----------+ +-----------+
o Wireless side o o o o
o o o o o o o o o o o o o o
o 6TiSCH o 6TiSCH o o o o 6TiSCH o
o o LLN o o o o LLN o o LLN o
o o o o o o o o o o o o o o
Figure 2: Extended Configuration of a 6TiSCH Network
図2：6Tischネットワークの拡張構成
A Routing Registrar that performs proxy IPv6 ND operations over the backbone on behalf of the 6TiSCH nodes is called a Backbone Router (6BBR) [RFC8929]. The 6BBRs are placed along the wireless edge of a backbone and federate multiple wireless links to form a single multi-link subnet. The 6BBRs synchronize with one another over the backbone, so as to ensure that the multiple LLNs that form the IPv6 subnet stay tightly synchronized.
6tischノードに代わってバックボーンを介してプロキシIPv6 ND操作を実行するルーティングレジストラは、バックボーンルータ（6BBR）[RFC8929]と呼ばれます。6BBRはバックボーンの無線エッジに沿って配置され、複数の無線リンクを連携して単一のマルチリンクサブネットを形成する。IPv6サブネットを形成する複数のLLNが確実に同期されていることを確認するために、6BBRSはバックボーンの上で互いに同期します。
The use of multicast can also be reduced on the backbone with a registrar that would contribute to Duplicate Address Detection as well as address lookup using only unicast request/response exchanges. [ND-UNICAST-LOOKUP] is a proposed method that presents an example of how this could be achieved with an extension of [RFC8505], using an optional 6LBR as a subnet-level registrar, as illustrated in Figure 2.
マルチキャストの使用は、UniCast Request / Response Extractsのみを使用しているアドレス検索とともに、重複アドレス検出に寄与するレジストラを使用してバックボーン上で縮小することもできます。[ND-unicast-lookup]は、図2に示すように、オプションの6LBRを使用して、[RFC8505]の拡張方法でどのように達成できるかの例を示す提案方法です。
As detailed in Section 4.1, the 6LBR that serves the LLN and the Root of the RPL network need to share information about the devices that are learned through either 6LoWPAN ND or RPL, but not both. The preferred way of achieving this is to co-locate or combine them. The combined RPL Root and 6LBR may be co-located with the 6BBR, or directly attached to the 6BBR. In the latter case, it leverages the extended registration process defined in [RFC8505] to proxy the 6LoWPAN ND registration to the 6BBR on behalf of the LLN nodes, so that the 6BBR may in turn perform classical ND operations over the backbone as a proxy.
セクション4.1に詳述されているように、RPLネットワークのLLNとRPのルートを処理する6LBRは、6LOWPAN NDまたはRPLを通じて学習されるデバイスに関する情報を共有する必要がありますが、両方ではありません。これを達成するための好ましい方法はそれらを共存または組み合わせることである。RPLルートと6LBRを組み合わせることで、6BBR、または6BBRに直接接続されていてもよい。後者の場合、[RFC8505]で定義されている拡張登録プロセスをLLNノードに代わって6BBRに6BBRにプロキシすることで、6BBRがバックボーンを介して古典的なND操作をプロキシとして実行します。
The "Deterministic Networking Architecture" [RFC8655] studies Layer 3 aspects of Deterministic Networks and covers networks that span multiple Layer 2 domains. If the backbone is deterministic (such as defined by the Time-Sensitive Networking (TSN) Task Group at IEEE), then the Backbone Router ensures that the end-to-end deterministic behavior is maintained between the LLN and the backbone.
「決定論的ネットワーキングアーキテクチャ」[RFC8655]は、決定論的ネットワークの層3の側面を研究し、複数のレイヤ2ドメインにまたがるネットワークをカバーする。バックボーンがIEEEで決定論的（Time-Senvience Networking（TSN）タスクグループによって定義されているように）決定的な場合、バックボーンルータは、最終間の決定論的な動作がLLNとバックボーンの間で維持されることを保証します。
Though at a different time scale (several orders of magnitude), both IEEE Std 802.1 TSN and IEEE Std 802.15.4 TSCH standards provide deterministic capabilities to the point that a packet pertaining to a certain flow may traverse a network from node to node following a precise schedule, as a train that enters and then leaves intermediate stations at precise times along its path.
異なる時間スケール（数桁）では、IEEE STD 802.1 TSNとIEEE STD 802.15.4の両方のTSCH規格は、特定のフローに関するパケットがノードからノードへのネットワークを横断することができるという点に対して確定的な機能を提供します。正確なスケジュールは、そのパスに沿って正確な時期に中間局を残してから、中間局を残します。
With TSCH, time is formatted into timeslots, and individual communication cells are allocated to unicast or broadcast communication at the MAC level. The time-slotted operation reduces collisions, saves energy, and enables more closely engineering the network for deterministic properties. The channel-hopping aspect is a simple and efficient technique to combat multipath fading and co-channel interference.
TSCHでは、時間がタイムスロットにフォーマットされ、個々の通信セルはMACレベルでユニキャストまたはブロードキャスト通信に割り当てられます。タイムスロットの操作は衝突を減らし、エネルギーを節約し、そして決定論的性質のためにネットワークをより厳密にエンジニアリングすることを可能にします。チャネルホッピングの態様は、マルチパスフェージングとコチャネル干渉を妨げるための簡単で効率的な技術です。
6TiSCH builds on the IEEE Std 802.15.4 TSCH MAC and inherits its advanced capabilities to enable them in multiple environments where they can be leveraged to improve automated operations. The 6TiSCH architecture also inherits the capability to perform a centralized route computation to achieve deterministic properties, though it relies on the IETF DetNet architecture [RFC8655] and IETF components such as the PCE [PCE] for the protocol aspects.
6tischはIEEE STD 802.15.4 TSCH Mac上でビルドし、その高度な機能を継承して、自動操作を改善するために活用できる複数の環境でそれらを有効にします。6Tischアーキテクチャはまた、プロトコルの側面のためのIETF Detnetアーキテクチャ[RFC8655]とPCE [PCE]などのIETFコンポーネントに依存して、決定論的プロパティを実現するための集中ルート計算を実行する機能を継承します。
On top of this inheritance, 6TiSCH adds capabilities for distributed routing and scheduling operations based on RPL and capabilities for negotiating schedule adjustments between peers. These distributed routing and scheduling operations simplify the deployment of TSCH networks and enable wireless solutions in a larger variety of use cases from operational technology in general. Examples of such use cases in industrial environments include plant setup and decommissioning, as well as monitoring a multiplicity of minor notifications such as corrosion measurements, events, and access of local devices by mobile workers.
この継承の上で、6tischは、ピア間のスケジュール調整を交渉するためのRPLと機能に基づいて分散ルーティングおよびスケジューリング操作の機能を追加します。これらの分散ルーティングおよびスケジューリング操作は、TSCHネットワークの展開を簡素化し、一般的に稼働技術からさまざまな使用例で無線ソリューションを可能にします。産業環境におけるそのようなユースケースの例には、プラントのセットアップと廃止措置、およびモバイルワーカーによって腐食測定、イベント、およびローカルデバイスのアクセスなどの多数のマイナーな通知を監視することが含まれます。
A scheduling operation allocates cells in a TDM/FDM matrix called a CDU either to individual transmissions or as multi-access shared resources. The CDU matrix can be formatted in chunks that can be allocated exclusively to particular nodes to enable distributed scheduling without collision. More in Section 4.3.5.
スケジューリング動作は、CDUと呼ばれるTDM / FDM行列内のセルを個々の送信またはマルチアクセス共有リソースとして割り当てる。CDU行列は、分散スケジューリングを衝突させずに特定のノードに割り当てることができるチャンクでフォーマットできます。セクション4.3.5では。
At the MAC layer, the schedule of a 6TiSCH node is the collection of the timeslots at which it must wake up for transmission, and the channels to which it should either send or listen at those times. The schedule is expressed as one or more repeating slotframes. Slotframes may collide and require a device to wake up at a same time, in which case the slotframe with the highest priority is actionable.
MAC層では、6tischノードのスケジュールは、送信用に起動しなければならないタイムスロットのコレクション、およびそれがそれらの時に送信または聴取する必要があるチャネルです。スケジュールは1つ以上の繰り返しスロットフレームとして表されます。スロットフレームは衝突してデバイスを同時に起動する必要があります。その場合、最も優先順位の高いスロットフレームは実用的です。
The 6top sublayer (see Section 4.3 for more) hides the complexity of the schedule from the upper layers. The link abstraction that IP traffic utilizes is composed of a pair of Layer 3 cell bundles, one to receive and one to transmit. Some of the cells may be shared, in which case the 6top sublayer must perform some arbitration.
6社のサブレイヤー（詳細はセクション4.3を参照）は、スケジュールの複雑さを上位層から隠します。IPトラフィックを利用するリンク抽象化は、1対のレイヤ3セルバンドル、受信するものと送信するもので構成されています。いくつかのセルを共有することができ、その場合、6TOPサブレイヤはいくつかの調停を実行しなければならない。
Scheduling enables multiple simultaneous communications in a same interference domain using different channels; but a node equipped with a single radio can only either transmit or receive on one channel at any point of time. Scheduled cells that fulfill the same role, e.g., receive IP packets from a peer, are grouped in bundles.
スケジューリングは、異なるチャネルを使用して同じ干渉ドメイン内で複数の同時通信を可能にします。しかし、単一の無線を備えたノードは、任意の時点で1つのチャンネルで送信または受信することができます。同じ役割を果たしているスケジュールされたセルは、ピアからIPパケットを受信し、バンドルにまとめられています。
The 6TiSCH architecture identifies four ways a schedule can be managed and CDU cells can be allocated: Static Scheduling, Neighbor-to-Neighbor Scheduling, Centralized (or Remote) Monitoring and Schedule Management, and Hop-by-Hop Scheduling.
6Tischアーキテクチャは、スケジュールを管理することができ、CDUセルを静的スケジューリング、隣接スケジューリング、集中型（またはリモート）の監視とスケジュール管理、およびホップバイホップスケジュールの4つの方法を識別します。
Static Scheduling: This refers to the minimal 6TiSCH operation whereby a static schedule is configured for the whole network for use in a Slotted ALOHA [S-ALOHA] fashion. The static schedule is distributed through the native methods in the TSCH MAC layer and does not preclude other scheduling operations coexisting on a same 6TiSCH network. A static schedule is necessary for basic operations such as the join process and for interoperability during the network formation, which is specified as part of the Minimal 6TiSCH Configuration [RFC8180].
静的スケジューリング：これは、スロット付きアロハ[S-アロハ]ファッションで使用するためのネットワーク全体に対して静的スケジュールが構成されている最小6Tisch操作を指します。静的スケジュールは、TSCH MAC層のネイティブメソッドを介して分散され、同じ6Tischネットワーク上で共存する他のスケジューリング操作を排除しません。結合プロセスやネットワーク形成中の相互運用性などの基本的な操作は、最小6Tisch設定[RFC8180]の一部として指定されている基本的な実行に必要です。
Neighbor-to-Neighbor Scheduling: This refers to the dynamic adaptation of the bandwidth of the links that are used for IPv6 traffic between adjacent peers. Scheduling Functions such as the "6TiSCH Minimal Scheduling Function (MSF)" [RFC9033] influence the operation of the MAC layer to add, update, and remove cells in its own and its peer's schedules using 6P [RFC8480] for the negotiation of the MAC resources.
近隣スケジューリング：これは、隣接するピア間のIPv6トラフィックに使用されるリンクの帯域幅の動的適応を指します。「6tisch最小スケジューリング関数（MSF）」[RFC9033]などのスケジューリング機能は、MACレイヤの操作に、Macのネゴシエーションのために6P [RFC8480]を使用して、独自のセルとそのピアのスケジュールを追加、更新、および削除するように影響します。リソース
Centralized (or Remote) Monitoring and Schedule Management: This refers to the central computation of a schedule and the capability to forward a frame based on the cell of arrival. In that case, the related portion of the device schedule as well as other device resources are managed by an abstract Network Management Entity (NME), which may cooperate with the PCE to minimize the interaction with, and the load on, the constrained device. This model is the TSCH adaption of the DetNet architecture [RFC8655], and it enables Traffic Engineering with deterministic properties.
集中型（またはリモート）の監視とスケジュール管理：これは、スケジュールの中心的な計算と、到着のセルに基づいてフレームを転送する機能を指します。その場合、デバイススケジュールの関連部分と他のデバイスリソースは、PCEと協働して拘束されたデバイスとの対話を最小限に抑えることができる抽象ネットワーク管理エンティティ（NME）によって管理されます。このモデルはDetnet Architecture [RFC8655]のTSCH適応性であり、決定論的プロパティを使用してトラフィックエンジニアリングを可能にします。
Hop-by-Hop Scheduling: This refers to the possibility of reserving cells along a path for a particular flow using a distributed mechanism.
ホップバイホップスケジューリング：これは、分散メカニズムを使用して特定のフローのための経路に沿ってセルを予約する可能性を指します。
It is not expected that all use cases will require all those mechanisms. Static Scheduling with minimal configuration is the only one that is expected in all implementations, since it provides a simple and solid basis for convergecast routing and time distribution.
すべてのユースケースがすべてのメカニズムを必要とすると予想されません。最小限の構成を持つ静的スケジューリングは、ConvergeCastルーティングと時間配布のための単純でしっかりした基本を提供するため、すべての実装で予想される唯一のものです。
A deeper dive into those mechanisms can be found in Section 4.4.
これらのメカニズムへのダイビングはセクション4.4にあります。
6TiSCH enables a mixed model of centralized routes and distributed routes. Centralized routes can, for example, be computed by an entity such as a PCE. 6TiSCH leverages RPL [RFC6550] for interoperable, distributed routing operations.
6tischは集中ルートと分散ルートの混合モデルを有効にします。集中経路は、例えば、PCEなどのエンティティによって計算することができる。6Tischは、相互運用可能な配布ルーティング操作のためのRPL [RFC6550]を活用しています。
Both methods may inject routes into the routing tables of the 6TiSCH routers. In either case, each route is associated with a 6TiSCH topology that can be a RPL Instance topology or a Track. The 6TiSCH topology is indexed by a RPLInstanceID, in a format that reuses the RPLInstanceID as defined in RPL.
両方の方法は、6Tischルータのルーティングテーブルにルートを挿入することができます。いずれの場合も、各ルートはRPLインスタンストポロジまたはトラックになることができる6tischトポロジに関連付けられています。6tischトポロジは、RPLで定義されているRPLINSTANCEIDを再利用する形式でRPLINSTANCEIDによって索引付けされています。
RPL [RFC6550] is applicable to Static Scheduling and Neighbor-to-Neighbor Scheduling. The architecture also supports a centralized routing model for Remote Monitoring and Schedule Management. It is expected that a routing protocol that is more optimized for point-to-point routing than RPL [RFC6550], such as the "Asymmetric AODV-P2P-RPL in Low-Power and Lossy Networks" (AODV-RPL) [AODV-RPL], which derives from the "Ad Hoc On-demand Distance Vector (AODVv2) Routing" [AODVv2], will be selected for Hop-by-Hop Scheduling.
RPL [RFC6550]は、静的スケジューリングおよび隣接スケジューリングに適用されます。このアーキテクチャは、リモート監視とスケジュール管理の集中ルーティングモデルもサポートしています。「低電力および非損失ネットワークにおける非対称AODV-P2P-RPL」（AODV-RPL）など、RPL [RFC6550]よりもポイントツーポイントルーティングのために最適化されたルーティングプロトコルが予想されます。「AD HOCオンデマンド距離ベクトル（AODVV2）ルーティング」から派生するRPL]は、ホップバイホップスケジューリングに選択されます。
Both RPL and PCE rely on shared sources such as policies to define global and local RPLInstanceIDs that can be used by either method. It is possible for centralized and distributed routing to share the same topology. Generally they will operate in different slotframes, and centralized routes will be used for scheduled traffic and will have precedence over distributed routes in case of conflict between the slotframes.
RPLとPCEの両方が、どちらの方法で使用できるグローバルおよびローカルRPLINSTANCEIDIDを定義するためのポリシーなどの共有ソースに依存しています。集中型および分散ルーティングが同じトポロジを共有することが可能です。一般的にそれらは異なるスロットフレームで動作し、集中ルートはスケジュールされたトラフィックに使用され、スロットフレーム間の競合の場合には分散ルートよりも優先されます。
The 6TiSCH architecture supports three different forwarding models. One is the classical IPv6 Forwarding, where the node selects a feasible successor at Layer 3 on a per-packet basis and based on its routing table. The second derives from Generalized MPLS (GMPLS) for so-called Track Forwarding, whereby a frame received at a particular timeslot can be switched into another timeslot at Layer 2 without regard to the upper-layer protocol. The third model is the 6LoWPAN Fragment Forwarding, which allows the forwarding individual 6LoWPAN fragments along a route that is set up by the first fragment.
6tischアーキテクチャは3つの異なる転送モデルをサポートしています。1つは古典的なIPv6転送であり、ノードはパケットごとにレイヤ3で実行可能な後継者を選択し、そのルーティングテーブルに基づいています。2番目は、いわゆるトラック転送のために一般化されたMPLS（GMPLS）から派生し、それによって特定のタイムスロットで受信されたフレームを上層プロトコルに関係なくレイヤ2で別のタイムスロットに切り替えることができる。3番目のモデルは6lowpanフラグメント転送で、最初のフラグメントによって設定されている経路に沿って個々の6LOWPANフラグメントを転送することができます。
In more detail:
さらに詳細に：
IPv6 Forwarding: This is the classical IP forwarding model, with a Routing Information Base (RIB) that is installed by RPL and used to select a feasible successor per packet. The packet is placed on an outgoing link, which the 6top sublayer maps into a (Layer 3) bundle of cells, and scheduled for transmission based on QoS parameters. Besides RPL, this model also applies to any routing protocol that may be operated in the 6TiSCH network and corresponds to all the distributed scheduling models: Static, Neighbor-to-Neighbor, and Hop-by-Hop Scheduling.
IPv6転送：これは、RPLによってインストールされ、パケットごとに実行可能な後継者を選択するために使用されるルーティング情報ベース（RIB）を持つ、古典的なIP転送モデルです。パケットは発信リンク上に配置され、6社のサブレイヤはセルの（レイヤ3）バンドルにマッピングされ、QoSパラメータに基づいて送信予定されている。RPLの他に、このモデルは6Tischネットワークで動作することがあり、静的、隣接スケジューリングモデル、およびホップバイホップスケジューリングのすべての分散スケジューリングモデルに対応する任意のルーティングプロトコルにも適用されます。
GMPLS Track Forwarding: This model corresponds to the Remote Monitoring and Schedule Management. In this model, a central controller (hosting a PCE) computes and installs the schedules in the devices per flow. The incoming (Layer 2) bundle of cells from the previous node along the path determines the outgoing (Layer 2) bundle towards the next hop for that flow as determined by the PCE. The programmed sequence for bundles is called a Track and can assume DAG shapes that are more complex than a simple direct sequence of nodes.
GMPLSトラック転送：このモデルは、リモート監視とスケジュール管理に対応しています。このモデルでは、中央コントローラ（PCEをホストする）は、フローごとにデバイスにスケジュールを計算してインストールします。経路に沿った前のノードからのセルの着信（レイヤ2）バンドルは、PCEによって決定されるようにそのフローについて次のホップに向かって発信（レイヤ2）バンドルを決定する。バンドルのプログラムされたシーケンスはトラックと呼ばれ、ノードの単純な直接シーケンスよりも複雑なDAG形状を仮定することができます。
6LoWPAN Fragment Forwarding: This is a hybrid model that derives from IPv6 forwarding for the case where packets must be fragmented at the 6LoWPAN sublayer. The first fragment is forwarded like any IPv6 packet and leaves a state in the intermediate hops to enable forwarding of the next fragments that do not have an IP header without the need to recompose the packet at every hop.
6lowpanフラグメント転送：これは、パケットを6LOWPANサブレイヤで断片化する必要がある場合のIPv6転送から派生するハイブリッドモデルです。最初のフラグメントは任意のIPv6パケットのように転送され、すべてのホップでパケットを再構成する必要なしにIPヘッダーを持たない次のフラグメントの転送を可能にするために中間ホップに状態が残ります。
A deeper dive into these operations can be found in Section 4.6.
これらの操作へのより深いダイビングはセクション4.6にあります。
Table 1 summarizes how the forwarding models apply to the various routing and scheduling possibilities:
表1は、転送モデルがさまざまなルーティングおよびスケジューリングの可能性に適用される方法を示しています。
+==================+==========+======================+
| Forwarding Model | Routing | Scheduling |
+==================+==========+======================+
| classical IPv6 / | RPL | Static (Minimal |
| 6LoWPAN Fragment | | Configuration) |
| | +----------------------+
| | | Neighbor-to-Neighbor |
| | | (SF+6P) |
| +----------+----------------------+
| | Reactive | Hop-by-Hop (AODV- |
| | | RPL) |
+------------------+----------+----------------------+
| GMPLS Track | PCE | Remote Monitoring |
| Forwarding | | and Schedule Mgt |
+------------------+----------+----------------------+
Table 1
表1
The IETF proposes multiple techniques for implementing functions related to routing, transport, or security.
IETFは、ルーティング、トランスポート、またはセキュリティに関連する機能を実装するための複数のテクニックを提案しています。
The 6TiSCH architecture limits the possible variations of the stack and recommends a number of base elements for LLN applications to control the complexity of possible deployments and device interactions and to limit the size of the resulting object code. In particular, UDP [RFC0768], IPv6 [RFC8200], and the Constrained Application Protocol (CoAP) [RFC7252] are used as the transport/ binding of choice for applications and management as opposed to TCP and HTTP.
6tischアーキテクチャは、スタックの可能なバリエーションを制限し、可能な展開とデバイスの対話の複雑さを制御し、結果として得られるオブジェクトコードのサイズを制限するためのLLNアプリケーションのための多くのベース要素を推奨します。特に、UDP [RFC0768]、IPv6 [RFC8200]、および制約付きアプリケーションプロトコル（COAAP）[RFC7252]は、TCPおよびHTTPとは対照的に、アプリケーションおよび管理のための選択の転送/バインディングとして使用されます。
The resulting protocol stack is represented in Figure 3:
結果のプロトコルスタックを図3に示します。
+--------+--------+
| Applis | CoJP |
+--------+--------+--------------+-----+
| CoAP / OSCORE | 6LoWPAN ND | RPL |
+-----------------+--------------+-----+
| UDP | ICMPv6 |
+-----------------+--------------------+
| IPv6 |
+--------------------------------------+----------------------+
| 6LoWPAN HC / 6LoRH HC | Scheduling Functions |
+--------------------------------------+----------------------+
| 6top inc. 6top Protocol |
+-------------------------------------------------------------+
| IEEE Std 802.15.4 TSCH |
+-------------------------------------------------------------+
Figure 3: 6TiSCH Protocol Stack
図3：6tischプロトコルスタック
RPL is the routing protocol of choice for LLNs. So far, there is no identified need to define a 6TiSCH-specific Objective Function. The Minimal 6TiSCH Configuration [RFC8180] describes the operation of RPL over a static schedule used in a Slotted ALOHA fashion [S-ALOHA], whereby all active slots may be used for emission or reception of both unicast and multicast frames.
RPLはLLNの選択のルーティングプロトコルです。これまでのところ、6tisch固有の目的関数を定義する必要性が識別されない。最小6Tisch構成[RFC8180]は、スロット付きアロハファッション[S-アロハ]で使用される静的スケジュールを介したRPLの動作を説明しています。これにより、すべてのアクティブスロットをユニキャストフレームとマルチキャストフレームの両方の排出量または受信に使用できます。
6LoWPAN header compression [RFC6282] is used to compress the IPv6 and UDP headers, whereas the 6LoWPAN Routing Header (6LoRH) [RFC8138] is used to compress the RPL artifacts in the IPv6 data packets, including the RPL Packet Information (RPI), the IP-in-IP encapsulation to/from the RPL Root, and the Source Routing Header (SRH) in non-storing mode. "Using RPI Option Type, Routing Header for Source Routes, and IPv6-in-IPv6 Encapsulation in the RPL Data Plane" [RFC9008] provides the details on when headers or encapsulation are needed.
6LOWPANヘッダ圧縮[RFC6282]は、IPv6およびUDPヘッダーを圧縮するために使用され、6LOWPAN Routing Header（6lllh）[RFC8138]を使用して、RPRパケット情報（RPI）を含むIPv6データパケット内のRPLアーティファクトを圧縮します。RPLルートへの/からのIP IN-IPカプセル化、および非格納モードのソースルーティングヘッダー（SRH）。「RPIオプションタイプの使用、ソースルートのルーティングヘッダー、RPLデータプレーンのIPv6-in-IPv6カプセル化」[RFC9008]は、ヘッダーまたはカプセル化が必要な場合に詳細を提供します。
The Object Security for Constrained RESTful Environments (OSCORE) [RFC8613] is leveraged by the Constrained Join Protocol (CoJP) and is expected to be the primary protocol for the protection of the application payload as well. The application payload may also be protected by the Datagram Transport Layer Security (DTLS) [RFC6347] sitting either under CoAP or over CoAP so it can traverse proxies.
制約付きRESTFUL環境（OSCCORE）[RFC8613]のオブジェクトセキュリティは、制約付き結合プロトコル（COJP）によって活用され、アプリケーションペイロードの保護のための主なプロトコルであると予想されます。アプリケーションペイロードは、CoApまたはCoApの下に座っているか、プロキシを通過できるように、データグラムトランスポート層セキュリティ（DTLS）[RFC6347]によって保護されている可能性があります。
The 6TiSCH Operation Sublayer (6top) is a sublayer of a Logical Link Control (LLC) that provides the abstraction of an IP link over a TSCH MAC and schedules packets over TSCH cells, as further discussed in the next sections, providing in particular dynamic cell allocation with the 6top Protocol (6P) [RFC8480].
6Tisch操作サブレイヤ（6top）は、特定のセクションでさらに説明したように、TSCH MACを介してIPリンクの抽象化を提供する論理リンク制御（LLC）の副層である。6TOPプロトコル（6P）[RFC8480]による割り当て。
The reference stack presented in this document was implemented and interoperability-tested by a combination of open source, IETF, and ETSI efforts. One goal is to help other bodies to adopt the stack as a whole, making the effort to move to an IPv6-based IoT stack easier.
この文書に記載されている参照スタックは、オープンソース、IETF、およびETSIの取り組みの組み合わせによって実装され、相互運用性がテストされました。1つの目標は、他の機関がスタック全体を採用するのを助けることであり、IPv6ベースのIoTスタックに移動するための努力を容易にすることです。
For a particular environment, some of the choices that are available in this architecture may not be relevant. For instance, RPL is not required for star topologies and mesh-under Layer 2 routed networks, and the 6LoWPAN compression may not be sufficient for ultra-constrained cases such as some Low-Power Wide Area (LPWA) networks. In such cases, it is perfectly doable to adopt a subset of the selection that is presented hereafter and then select alternate components to complete the solution wherever needed.
特定の環境のために、このアーキテクチャで利用可能ないくつかの選択は関連性がないかもしれません。たとえば、RPLはスタートポロジとメッシュ下のレイヤ2ルーティングネットワークには必要ありません.6LOWPAN圧縮は、一部の低電力ワイドエリア（LPWA）ネットワークなどの超拘束ケースには十分ではない場合があります。そのような場合、以下に提示された選択のサブセットを採用することは完全に行われ、それから必要に応じて解決策を完成させるために代替構成要素を選択することは完全に行われます。
Section 2.1 provides the terms of Communication Paradigms and Interaction Models in combination with "On the Difference between Information Models and Data Models" [RFC3444]. A Communication Paradigm is an abstract view of a protocol exchange and has an Information Model for the information that is being exchanged. In contrast, an Interaction Model is more refined and points to standard operation such as a Representational State Transfer (REST) "GET" operation and matches a Data Model for the data that is provided over the protocol exchange.
セクション2.1は、「情報モデルとデータモデルの差について」と組み合わせた通信パラダイムとインタラクションモデルの条項[RFC3444]を示しています。通信パラダイムは、プロトコル交換の抽象図であり、交換中の情報のための情報モデルを有する。対照的に、相互作用モデルはより洗練されており、表現状態転送（REST）「GET」操作などの標準操作を指し、プロトコル交換を介して提供されるデータのデータモデルと一致します。
Section 2.1.3 of [RPL-APPLICABILITY] and its following sections discuss application-layer paradigms such as source-sink, which is a multipeer-to-multipeer model primarily used for alarms and alerts, publish-subscribe, which is typically used for sensor data, as well as peer-to-peer and peer-to-multipeer communications.
[RPLアプリケーション性]のセクション2.1.3およびその以下のセクションでは、ソース・シンクなどのアプリケーションレイヤ・パラダイムについて説明します。これは、主に警告および警告、Publish-Subscribe、Publish-Subscribeで使用されているマルチペア・トゥ・マルチベーション・サブスクライブです。センサーデータ、およびピアツーピアおよびピアツー・マルチペア通信。
Additional considerations on duocast -- one sender, two receivers for redundancy -- and its N-cast generalization are also provided. Those paradigms are frequently used in industrial automation, which is a major use case for IEEE Std 802.15.4 TSCH wireless networks with [ISA100.11a] and [WirelessHART], which provides a wireless access to [HART] applications and devices.
DuoCast - 1つの送信者、冗長性のための2つの受信者に関するさらなる考慮事項もまた提供されています。これらのパラダイムは、[ISA100.11A]と[WirelessHart]を搭載したIEEE STD 802.15.4 TSCH無線ネットワークの大規模なユースケースであり、[HART]アプリケーションとデバイスへの無線アクセスを提供します。
This document focuses on Communication Paradigms and Interaction Models for packet forwarding and TSCH resources (cells) management. Management mechanisms for the TSCH schedule at the link layer (one hop), network layer (multihop along a Track), and application layer (remote control) are discussed in Section 4.4. Link-layer frame forwarding interactions are discussed in Section 4.6, and network-layer packet routing is addressed in Section 4.7.
この文書は、パケット転送およびTSCHリソース（セル）管理のための通信パラダイムおよびインタラクションモデルに焦点を当てています。リンク層（ワンホップ）、ネットワーク層（トラックに沿ったマルチホップ）、およびアプリケーション層（リモートコントロール）のTSCHスケジュールの管理メカニズムについては、4.4節で説明しています。リンク層フレーム転送相互作用は4.6項で論じられ、ネットワーク層パケットルーティングはセクション4.7でアドレス指定されています。
A RPL DODAG is formed of a Root, a collection of routers, and leaves that are hosts. Hosts are nodes that do not forward packets that they did not generate. RPL-aware leaves will participate in RPL to advertise their own addresses, whereas RPL-unaware leaves depend on a connected RPL router to do so. RPL interacts with 6LoWPAN ND at multiple levels, in particular at the Root and in the RPL-unaware leaves.
RPDAGは、ルート、ルータの集まり、およびホストである葉で構成されています。ホストは、それらが生成しなかったパケットを転送しないノードです。RPL対応の葉はRPLに参加して自分のアドレスをアドレス指定しますが、RPL-NAWAREのリーダーは、接続されているRPLルーターによって異なります。RPLは、特に根およびRPL対行の葉で複数のレベルで6LOWPAN NDと相互作用する。
RPL needs a set of information to advertise a leaf node through a Destination Advertisement Object (DAO) message and establish reachability.
RPLは、宛先アドバタイズメントオブジェクト（DAO）メッセージを介してリーフノードをアドバタイズするための一連の情報を必要とし、到達可能性を確立する。
"Routing for RPL Leaves" [RFC9010] details the basic interaction of 6LoWPAN ND and RPL and enables a plain 6LN that supports [RFC8505] to obtain return connectivity via the RPL network as a RPL-unaware leaf. The leaf indicates that it requires reachability services for the Registered Address from a Routing Registrar by setting an 'R' flag in the Extended Address Registration Option [RFC8505], and it provides a TID that maps to the "Path Sequence" defined in Section 6.7.8 of [RFC6550], and its operation is defined in Section 7.2 of [RFC6550].
「RPLの葉のルーティング」[RFC9010]は、6LOWPAN NDとRPLの基本的な対話を詳しく説明し、[RFC8505]をサポートする平野6LNを使用してRPLネットワークを介してRPL-NAWARAREの葉としてRETURN接続を取得できます。リーフは、拡張アドレス登録オプション[RFC8505]で 'R'フラグを設定することによってルーティングレジストラから登録されたアドレスの到達可能性サービスを必要とし、セクション6.7で定義されている「パスシーケンス」にマッピングするTIDを提供します。[RFC6550]の.8、その動作は[RFC6550]のセクション7.2で定義されています。
[RFC9010] also enables the leaf to signal with the RPLInstanceID that it wants to participate by using the Opaque field of the EARO. On the backbone, the RPLInstanceID is expected to be mapped to an overlay that matches the RPL Instance, e.g., a Virtual LAN (VLAN) or a virtual routing and forwarding (VRF) instance.
[RFC9010]イヤーの不透明フィールドを使用して、参加したいRPLINSTANCEIDを使用して板を信号にすることもできます。バックボーン上では、RPLINSTANCEIDは、RPLインスタンス、例えば仮想LAN（VLAN）または仮想ルーティングおよび転送（VRF）インスタンスと一致するオーバーレイにマッピングされると予想されます。
Though, at the time of this writing, the above specification enables a model where the separation is possible, this architecture recommends co-locating the functions of 6LBR and RPL Root.
この書き込み時には、上記の仕様では分離が可能なモデルを実現することができ、このアーキテクチャでは6LBRとRPLルートの機能を共有することをお勧めします。
With the 6LoWPAN ND [RFC6775], information on the 6LBR is disseminated via an Authoritative Border Router Option (ABRO) in RA messages. [RFC8505] extends [RFC6775] to enable a registration for routing and proxy ND. The capability to support [RFC8505] is indicated in the 6LoWPAN Capability Indication Option (6CIO). The discovery and liveliness of the RPL Root are obtained through RPL [RFC6550] itself.
6LOWPAN ND [RFC6775]では、6LBRの情報はRAメッセージの正式な国境ルーターオプション（ABRO）を介して普及しています。[RFC8505]ルーティングとプロキシNDの登録を有効にするには、[RFC6775]を拡張します。[RFC8505]をサポートする機能は、6lowpan Capability Indicationオプション（6CIO）に示されています。RPL根の発見と活気はRPL [RFC6550]自体を通して得られます。
When 6LoWPAN ND is coupled with RPL, the 6LBR and RPL Root functionalities are co-located in order that the address of the 6LBR is indicated by RPL DODAG Information Object (DIO) messages and to associate the ROVR from the Extended Duplicate Address Request/ Confirmation (EDAR/EDAC) exchange [RFC8505] with the state that is maintained by RPL.
6LOWPAN NDがRPLと結合されている場合、6LBRとRPLのroot機能は、6LBRのアドレスがRPL DoDag Information Object（DIO）メッセージによって示され、ROVRを拡張された重複アドレス要求/確認から関連付けるために同じ場所に配置されます。（EDAR / EDAC）RPLによって維持される状態で[RFC8505]。
Section 7 of [RFC9010] specifies how the DAO messages are used to reconfirm the registration, thus eliminating a duplication of functionality between DAO and EDAR/EDAC messages, as illustrated in Figure 6. [RFC9010] also provides the protocol elements that are needed when the 6LBR and RPL Root functionalities are not co-located.
[RFC9010]のセクション7 DAOメッセージを使用して登録を再確認する方法を指定します。したがって、図6に示すように、DAOとEDACメッセージ間の機能の重複を排除します。[RFC9010]も必要なプロトコル要素を提供します。6LBRとRPLの根元機能は同じ場所にありません。
Even though the Root of the RPL network is integrated with the 6LBR, it is logically separated from the Backbone Router (6BBR) that is used to connect the 6TiSCH LLN to the backbone. This way, the Root has all information from 6LoWPAN ND and RPL about the LLN devices attached to it.
RPLネットワークのルートが6LBRと統合されていても、6Tisch LLNをバックボーンに接続するために使用されるバックボーンルータ（6BBR）から論理的に分離されます。このようにして、ルートは6lowpan NDからのすべての情報とそれに接続されているLLNデバイスに関するRPLです。
This architecture also expects that the Root of the RPL network (proxy-)registers the 6TiSCH nodes on their behalf to the 6BBR, for whatever operation the 6BBR performs on the backbone, such as ND proxy or redistribution in a routing protocol. This relies on an extension of the 6LoWPAN ND registration described in [RFC8929].
このアーキテクチャはまた、RPLネットワーク（Proxy-）のルートが、NDプロキシやルーティングプロトコルの再配布などのバックボーンで実行されている操作で、6BBRがバックボーンで実行されているため、6BBRに6BBRに6Tischノードを登録することを期待しています。これは[RFC8929]に記載されている6LOWPAN ND登録の拡張に依存しています。
This model supports the movement of a 6TiSCH device across the multi-link subnet and allows the proxy registration of 6TiSCH nodes deep into the 6TiSCH LLN by the 6LBR / RPL Root. This is why in [RFC8505] the Registered Address is signaled in the Target Address field of the Neighbor Solicitation (NS) message as opposed to the IPv6 Source Address, which, in the case of a proxy registration, is that of the 6LBR / RPL Root itself.
このモデルは、マルチリンクサブネット全体の6Tischデバイスの動きをサポートし、6LBR / RPLルートによって6Tisch LLNに6Tisch LLNのプロキシ登録を可能にします。これが、[RFC8505]では、IPv6ソースアドレスの場合、登録アドレスが隣接勧誘（NS）メッセージでシグナリングされているため、プロキシ登録の場合は6LBR / RPLのものです。ルート自体。
A new device, called the pledge, undergoes the join protocol to become a node in a 6TiSCH network. This usually occurs only once when the device is first powered on. The pledge communicates with the Join Registrar/Coordinator (JRC) of the network through a Join Proxy (JP), a radio neighbor of the pledge.
PLEDDEと呼ばれる新しい装置は、6Tischネットワーク内のノードになるために結合プロトコルを受ける。これは通常、デバイスが最初に電源投入されたときに一度だけ発生します。PREDCKは、誓約プロキシ（JP）、誓約プロキシ（JP）を介してネットワークの結合レジストラ/コーディネータ（JRC）と通信します。
The JP is discovered though MAC-layer beacons. When multiple JPs from possibly multiple networks are visible, using trial and error until an acceptable position in the right network is obtained becomes inefficient. [RFC9032] adds a new subtype in the Information Element that was delegated to the IETF [RFC8137] and provides visibility into the network that can be joined and the willingness of the JP and the Root to be used by the pledge.
MACレイヤービーコンにはJPが発見されました。複数のネットワークから複数のJPSが表示されている場合、正しいネットワーク内の許容位置が得られるまで試行錯誤を使用すると非効率的になる。[RFC9032] IETF [RFC8137]に委任された情報要素に新しいサブタイプを追加し、結合することができるネットワークとJPの意欲と誓約書によって使用されるルートへの可視性を提供します。
The join protocol provides the following functionality:
結合プロトコルには、次の機能があります。
* Mutual authentication
* 相互認証
* Authorization
* 承認
* Parameter distribution to the pledge over a secure channel
* 安全なチャネル上の誓約へのパラメータ分布
The Minimal Security Framework for 6TiSCH [RFC9031] defines the minimal mechanisms required for this join process to occur in a secure manner. The specification defines the Constrained Join Protocol (CoJP), which is used to distribute the parameters to the pledge over a secure session established through OSCORE [RFC8613] and which describes the secure configuration of the network stack. In the minimal setting with pre-shared keys (PSKs), CoJP allows the pledge to join after a single round-trip exchange with the JRC. The provisioning of the PSK to the pledge and the JRC needs to be done out of band, through a 'one-touch' bootstrapping process, which effectively enrolls the pledge into the domain managed by the JRC.
6Tisch [RFC9031]の最小セキュリティフレームワークは、この結合プロセスに必要な最小メカニズムを安全な方法で定義します。仕様は、OSCRO [RFC8613]を介して確立された安全なセッションを介して、ネットワークスタックの安全な構成を記述するSecureセッションを介してパラメータをPREDDEに配布するために使用される制約付き結合プロトコル（COJP）を定義しています。事前共有キー（PSK）を使用した最小設定では、COJPでは、JRCとの1回の往復交換後に誓約が参加することができます。PSKへのPSKのプロビジョニングとJRCは、「ワンタッチ」ブートストラッププロセスを通じて、帯域外で、JRCによって管理されているドメインに効果的に登録する必要があります。
In certain use cases, the 'one-touch' bootstrapping is not feasible due to the operational constraints, and the enrollment of the pledge into the domain needs to occur in-band. This is handled through a 'zero-touch' extension of the Minimal Security Framework for 6TiSCH. The zero-touch extension [ZEROTOUCH-JOIN] leverages the "Bootstrapping Remote Secure Key Infrastructure (BRSKI)" [RFC8995] work to establish a shared secret between a pledge and the JRC without necessarily having them belong to a common (security) domain at join time. This happens through inter-domain communication occurring between the JRC of the network and the domain of the pledge, represented by a fourth entity, Manufacturer Authorized Signing Authority (MASA). Once the zero-touch exchange completes, the CoJP exchange defined in [RFC9031] is carried over the secure session established between the pledge and the JRC.
特定のユースケースでは、「ワンタッチ」ブートストラップが動作上の制約のために実行可能ではなく、ドメインへの誓約の登録は帯域内で発生する必要があります。これは6tischのための最小限のセキュリティフレームワークの「ゼロタッチ」拡張を通して処理されます。ゼロタッチエクステンション[ZEROTOCH-JOIN]は、「Bootstrapp Remote Secure Secure Infrastructure（Brski）」[RFC8995]を活用して、必ずしも共通の（セキュリティ）ドメインに属するものを持たない）時間に参加します。これは、第4のエンティティで表される、ネットワークのJRCとPREDDERのドメイン間で発生したドメイン間コミュニケーションを通じて発生します。メーカー認定署名権限（MASA）。ゼロタッチExchangeが完了すると、[RFC9031]で定義されているCOJP交換は、PREDGEとJRC間で確立されたセキュアセッションを介して運ばれます。
Figure 4 depicts the join process and where a Link-Local Address (LLA) is used, versus a Global Unicast Address (GUA).
図4は、結合プロセスを示し、リンクローカルアドレス（LLA）がグローバルユニキャストアドレス（GUA）である場合を示しています。
6LoWPAN Node 6LR 6LBR Join Registrar MASA
(pledge) (Join Proxy) (Root) /Coordinator (JRC)
| | | | |
| 6LoWPAN ND |6LoWPAN ND+RPL | IPv6 network |IPv6 network |
| LLN link |Route-Over mesh|(the Internet)|(the Internet)|
| | | | |
| Layer 2 | | | |
|Enhanced Beacon| | | |
|<--------------| | | |
| | | | |
| NS (EARO) | | | |
| (for the LLA) | | | |
|-------------->| | | |
| NA (EARO) | | | |
|<--------------| | | |
| | | | |
| (Zero-touch | | | |
| handshake) | (Zero-touch handshake) | (Zero-touch |
| using LLA | using GUA | handshake) |
|<------------->|<---------------------------->|<------------>|
| | | | |
| CoJP Join Req | | | | \
| using LLA | | | | |
|-------------->| | | | |
| | CoJP Join Request | | |
| | using GUA | | |
| |----------------------------->| | | C
| | | | | | o
| | CoJP Join Response | | | J
| | using GUA | | | P
| |<-----------------------------| | |
|CoJP Join Resp | | | | |
| using LLA | | | | |
|<--------------| | | | /
| | | | |
Figure 4: Join Process in a Multi-Link Subnet. Parentheses () denote optional exchanges.
図4：マルチリンクサブネット内の結合プロセス。括弧（）はオプションの交換を表します。
Once the pledge successfully completes the CoJP exchange and becomes a network node, it obtains the network prefix from neighboring routers and registers its IPv6 addresses. As detailed in Section 4.1, the combined 6LoWPAN ND 6LBR and Root of the RPL network learn information such as an identifier (device EUI-64 [RFC6775] or a ROVR [RFC8505] (from 6LoWPAN ND)) and the updated Sequence Number (from RPL), and perform 6LoWPAN ND proxy registration to the 6BBR on behalf of the LLN nodes.
PREDGEがCOJP Exchangeを正常に完了し、ネットワークノードになると、隣接ルータからネットワークプレフィックスを取得し、そのIPv6アドレスを登録します。セクション4.1に詳述されているように、RPLネットワークのコンバイント6LBRとルートは、識別子（デバイスEUI-64 [RFC6775]またはROVR [RFC8505]（6LOWPAN ND））および更新されたシーケンス番号などの情報を学びます。RPL）、LLNノードに代わって6BBRに6LOWPAN NDプロキシ登録を実行します。
Figure 5 illustrates the initial IPv6 signaling that enables a 6LN to form a global address and register it to a 6LBR using 6LoWPAN ND [RFC8505]. It is then carried over RPL to the RPL Root and then to the 6BBR. This flow happens just once when the address is created and first registered.
図5は、6LNがグローバルアドレスを形成することを可能にし、6Lowpan ND [RFC8505]を使用して6LBRに登録することを可能にする初期IPv6シグナリングを示しています。それは次にRPLをRPLに渡され、次に6BBRに伝送されます。このフローは、アドレスが作成されて最初に登録されているときに一度だけ発生します。
6LoWPAN Node 6LR 6LBR 6BBR
(RPL leaf) (router) (Root)
| | | |
| 6LoWPAN ND |6LoWPAN ND+RPL | 6LoWPAN ND | IPv6 ND
| LLN link |Route-Over mesh|Ethernet/serial| Backbone
| | | |
| RS (mcast) | | |
|-------------->| | |
|-----------> | | |
|------------------> | |
| RA (unicast) | | |
|<--------------| | |
| | | |
| NS(EARO) | | |
|-------------->| | |
| 6LoWPAN ND | Extended DAR | |
| |-------------->| |
| | | NS(EARO) |
| | |-------------->|
| | | | NS-DAD
| | | |------>
| | | | (EARO)
| | | |
| | | NA(EARO) |<timeout>
| | |<--------------|
| | Extended DAC | |
| |<--------------| |
| NA(EARO) | | |
|<--------------| | |
| | | |
Figure 5: Initial Registration Flow over Multi-Link Subnet
図5：マルチリンクサブネットの上の初期登録フロー
Figure 6 illustrates the repeating IPv6 signaling that enables a 6LN to keep a global address alive and registered with its 6LBR using 6LoWPAN ND to the 6LR, RPL to the RPL Root, and then 6LoWPAN ND again to the 6BBR, which avoids repeating the Extended DAR/DAC flow across the network when RPL can suffice as a keep-alive mechanism.
図6は、6LNを6LRに6LR、RPLへのRPLを使用して6LN、RPLルートへの6LR、RPLを使用して6LB、次に6BBRに6LBBRを再び6LBBRに保存することを可能にし、6LBBRを6LBに登録することを可能にするIPv6シグナリングを繰り返すことを示しています。/ DACは、維持存在メカニズムとして十分な場合にネットワークを横切ってネットワークを横切って流れます。
6LoWPAN Node 6LR 6LBR 6BBR
(RPL leaf) (router) (Root)
| | | |
| 6LoWPAN ND |6LoWPAN ND+RPL | 6LoWPAN ND | IPv6 ND
| LLN link |Route-Over mesh| ant IPv6 link | Backbone
| | |
| | | |
| NS(EARO) | | |
|-------------->| | |
| NA(EARO) | | |
|<--------------| | |
| | DAO | |
| |-------------->| |
| | DAO-ACK | |
| |<--------------| |
| | | NS(EARO) |
| | |-------------->|
| | | NA(EARO) |
| | |<--------------|
| | | |
| | | |
Figure 6: Next Registration Flow over Multi-Link Subnet
図6：マルチリンクサブネットの上の次の登録フロー
As the network builds up, a node should start as a leaf to join the RPL network and may later turn into both a RPL-capable router and a 6LR, so as to accept leaf nodes recursively joining the network.
ネットワークが構築されると、ノードはRPLネットワークに参加するためのリーフとして始まり、後でRPL対応ルータと6LRの両方に回転することができ、ネットワークに再帰的に結合するリーフノードを受け入れることができます。
6TiSCH expects a high degree of scalability together with a distributed routing functionality based on RPL. To achieve this goal, the spectrum must be allocated in a way that allows for spatial reuse between zones that will not interfere with one another. In a large and spatially distributed network, a 6TiSCH node is often in a good position to determine usage of the spectrum in its vicinity.
6tischは、RPLに基づく分散ルーティング機能と共に高度なスケーラビリティを期待しています。この目標を達成するためには、互いに干渉しないゾーン間の空間的な再利用を可能にするようにスペクトルを割り当てる必要があります。大規模で空間的に分散されたネットワークでは、6Tischノードは、その周辺のスペクトルの使用を決定するためによく良い位置にある。
With 6TiSCH, the abstraction of an IPv6 link is implemented as a pair of bundles of cells, one in each direction. IP links are only enabled between RPL parents and children. The 6TiSCH operation is optimal when the size of a bundle minimizes both the energy wasted in idle listening and the packet drops due to congestion loss, while packets are forwarded within an acceptable latency.
6Tischでは、IPv6リンクの抽象化は、各方向の一方のセルの一体のバンドルとして実装されています。IPリンクは、RPLの親と子の間でのみ有効になります。6Tisch操作は、バンドルのサイズがアイドルリスニングで無駄に浪費されたエネルギーと輻輳損失によるパケットの両方を最小にすると最適ですが、パケットは許容可能な待ち時間内に転送されます。
Use cases for distributed routing are often associated with a statistical distribution of best-effort traffic with variable needs for bandwidth on each individual link. The 6TiSCH operation can remain optimal if RPL parents can adjust, dynamically and with enough reactivity to match the variations of best-effort traffic, the amount of bandwidth that is used to communicate between themselves and their children, in both directions. In turn, the agility to fulfill the needs for additional cells improves when the number of interactions with other devices and the protocol latencies are minimized.
分散ルーティングの使用例は、各個々のリンクの帯域幅の可変ニーズを持つベストエフォートトラフィックの統計的配布に関連しています。RPLの両親がベストエフォートトラフィックのバリエーションに合わせて動的に、そして十分な反応性で、双方向で使用される帯域幅の量を両方向に合わせることができる場合、6Tisch操作は最適なままであり得る。次に、追加のセルのニーズを満たすための敏捷性は、他の装置との相互作用の数とプロトコル待ち時間が最小になると改善されます。
6top is a logical link control sitting between the IP layer and the TSCH MAC layer, which provides the link abstraction that is required for IP operations. The 6top Protocol, 6P, which is specified in [RFC8480], is one of the services provided by 6top. In particular, the 6top services are available over a management API that enables an external management entity to schedule cells and slotframes, and allows the addition of complementary functionality, for instance, a Scheduling Function that manages a dynamic schedule based on observed resource usage as discussed in Section 4.4.2. For this purpose, the 6TiSCH architecture differentiates "soft" cells and "hard" cells.
IP層とTSCH MAC層の間に座っている論理リンク制御があり、IP操作に必要なリンク抽象化を提供します。[RFC8480]で指定されている6TOPプロトコル6Pは、6TOPによって提供されるサービスの1つです。特に、外部の管理エンティティがセルとスロットフレームをスケジュールすることを可能にする管理APIを介して、6TOPサービスは管理APIを介して利用可能であり、議論されたように観測されたリソース使用量に基づいて動的スケジュールを管理するスケジューリング機能を追加することができます。4.4.2節で。この目的のために、6Tischアーキテクチャは「柔らかい」セルと「ハード」セルを区別します。
"Hard" cells are cells that are owned and managed by a separate scheduling entity (e.g., a PCE) that specifies the slotOffset/ channelOffset of the cells to be added/moved/deleted, in which case 6top can only act as instructed and may not move hard cells in the TSCH schedule on its own.
「ハード」セルは、追加/移動/削除されるセルのSlotOffset / ChannelOffsetを指定する別のスケジューリングエンティティ（例えばPCE）によって所有および管理されるセルであり、その場合、6Topは指示されたように行動することができるTSCHスケジュールにハードセルを独自に移動しないでください。
In contrast, "soft" cells are cells that 6top can manage locally. 6top contains a monitoring process that monitors the performance of cells and that can add and remove soft cells in the TSCH schedule to adapt to the traffic needs, or move one when it performs poorly. To reserve a soft cell, the higher layer does not indicate the exact slotOffset/channelOffset of the cell to add, but rather the resulting bandwidth and QoS requirements. When the monitoring process triggers a cell reallocation, the two neighbor devices communicating over this cell negotiate its new position in the TSCH schedule.
対照的に、「柔らかい」セルは6社がローカルに管理できるセルです。6topは、セルの性能を監視し、TSCHスケジュール内のソフトセルを追加および削除してトラフィックのニーズに適応するか、またはそれが不十分なときに移動することができる監視プロセスが含まれています。ソフトセルを予約するために、上位レイヤーは、追加するセルの正確なSlotOffset / ChannelOffsetを指定しませんが、むしろ結果の帯域幅とQoSの要件を示していません。監視プロセスがセルの再割り当てをトリガすると、このセルを介して通信する2つの隣接デバイスはTSCHスケジュール内の新しい位置を交渉します。
In the case of soft cells, the cell management entity that controls the dynamic attribution of cells to adapt to the dynamics of variable rate flows is called a Scheduling Function (SF).
ソフトセルの場合、可変レートフローのダイナミクスに適応するためのセルの動的帰属を制御するセル管理エンティティは、スケジューリング関数（SF）と呼ばれます。
There may be multiple SFs that react more or less aggressively to the dynamics of the network.
ネットワークのダイナミクスに多かれ少なかれ反応する複数のSFSがあります。
An SF may be seen as divided between an upper bandwidth-adaptation logic that is unaware of the particular technology used to obtain and release bandwidth and an underlying service that maps those needs in the actual technology. In the case of TSCH using the 6top Protocol as illustrated in Figure 7, this means mapping the bandwidth onto cells.
SFは、実際の技術でそれらのニーズをマッピングするために使用される特定の技術と、帯域幅と解放するために使用されている特定の技術と、根底にあるサービスとの間で分割されていると見なすことができる。図7に示すように6TTOPプロトコルを使用したTSCHの場合、これは帯域幅をセルにマッピングすることを意味します。
+------------------------+ +------------------------+
| Scheduling Function | | Scheduling Function |
| Bandwidth adaptation | | Bandwidth adaptation |
+------------------------+ +------------------------+
| Scheduling Function | | Scheduling Function |
| TSCH mapping to cells | | TSCH mapping to cells |
+------------------------+ +------------------------+
| 6top cells negotiation | <- 6P -> | 6top cells negotiation |
+------------------------+ +------------------------+
Device A Device B
Figure 7: SF/6P Stack in 6top
図7：6社のSF / 6Pスタック
The SF relies on 6top services that implement the 6top Protocol (6P) [RFC8480] to negotiate the precise cells that will be allocated or freed based on the schedule of the peer. For instance, it may be that a peer wants to use a particular timeslot that is free in its schedule, but that timeslot is already in use by the other peer to communicate with a third party on a different cell. 6P enables the peers to find an agreement in a transactional manner that ensures the final consistency of the nodes' state.
SFは、ピアのスケジュールに基づいて割り当てられるか解放される正確なセルをネゴシエートするために、6TOPプロトコル（6p）[RFC8480]を実装する6TTOPサービスに依存しています。たとえば、ピアがスケジュール内で自由な特定のタイムスロットを使用することを望んでいるが、そのタイムスロットはすでに他のピアが別のセル上の第三者と通信することによって既に使用されている。6Pは、ピアがノードの最終的な一貫性を確保するトランザクション態度で合意を見つけることができます。
MSF [RFC9033] is one of the possible Scheduling Functions. MSF uses the rendezvous slot from [RFC8180] for network discovery, neighbor discovery, and any other broadcast.
MSF [RFC9033]は、可能なスケジューリング機能の1つです。MSFは、ネットワーク発見、ネイバーディスカバリ、およびその他のブロードキャストのためにRFC8180からのランデブースロットを使用します。
For basic unicast communication with any neighbor, each node uses a receive cell at a well-known slotOffset/channelOffset, which is derived from a hash of their own MAC address. Nodes can reach any neighbor by installing a transmit (shared) cell with slotOffset/ channelOffset derived from the neighbor's MAC address.
任意の隣接との基本的なユニキャスト通信のために、各ノードは、それ自身のMACアドレスのハッシュから派生したよく知られているスロットオフセット/チャネルオフセットで受信セルを使用する。ノードは、ネイバーのMACアドレスから派生したSlotOffSet / ChannelOffsetを使用して送信（共有）セルをインストールすることによって、任意の隣接に達することができます。
For child-parent links, MSF continuously monitors the load between parents and children. It then uses 6P to install or remove unicast cells whenever the current schedule appears to be under-provisioned or over-provisioned.
子親リンクの場合、MSFは両親と子供の間の負荷を継続的に監視します。その後、現在のスケジュールがアンダープロビジョニングまたはオーバープロビジョニングされているように見えるたびに、6Pを使用してユニキャストセルをインストールまたは削除します。
An implementation of a RPL [RFC6550] Objective Function (OF), such as the RPL Objective Function Zero (OF0) [RFC6552] that is used in the Minimal 6TiSCH Configuration [RFC8180] to support RPL over a static schedule, may leverage for its internal computation the information maintained by 6top.
RPL [RFC6550]の実装（OF0）静止スケジュールでRPLをサポートするために、最小6Tisch設定[RFC8180]のRPL目標関数ゼロ（OF0）[RFC6552]の実装は、静的スケジュールでRPLをサポートすることができます。内部計算6TOPによって維持されている情報。
An OF may require metrics about reachability, such as the Expected Transmission Count (ETX) metric [RFC6551]. 6top creates and maintains an abstract neighbor table, and this state may be leveraged to feed an OF and/or store OF information as well. A neighbor table entry may contain a set of statistics with respect to that specific neighbor.
OFは、予想される送信数（ETX）メトリック[RFC6551]などの到達可能性に関する測定基準を必要とする場合があります。6TOPは抽象的な隣接テーブルを作成して維持し、この状態をレバレッジして情報の保存および/または情報を格納することもできます。隣接テーブルエントリは、その特定のネイバーに関して一連の統計を含み得る。
The neighbor information may include the time when the last packet has been received from that neighbor, a set of cell quality metrics, e.g., received signal strength indication (RSSI) or link quality indicator (LQI), the number of packets sent to the neighbor, or the number of packets received from it. This information can be made available through 6top management APIs and used, for instance, to compute a Rank Increment that will determine the selection of the preferred parent.
隣接情報は、最後のパケットがその隣接から受信された時刻、例えば、セル品質メトリックのセット、例えば受信信号強度指標（RSSI）またはリンク品質インジケータ（LQI）、隣接に送信されるパケットの数。、またはそれから受信したパケットの数。この情報は、6top Management APIを介して利用可能になり、例えば、優先親の選択を決定するランクインクリメントを計算することができます。
6top provides statistics about the underlying layer so the OF can be tuned to the nature of the TSCH MAC layer. 6top also enables the RPL OF to influence the MAC behavior, for instance, by configuring the periodicity of IEEE Std 802.15.4 Extended Beacons (EBs). By augmenting the EB periodicity, it is possible to change the network dynamics so as to improve the support of devices that may change their point of attachment in the 6TiSCH network.
6社は基礎となるレイヤに関する統計を提供しているので、TSCH MAC層の性質に調整することができます。6社はまた、例えばIEEE STD 802.15.4拡張ビーコン（EBS）の周期性を設定することによって、RPLのRPLがMAC動作に影響を与えることを可能にします。EB周期性を高めることによって、6Tischネットワークにおけるそれらの添付点を変更することができる装置の支持を改善するためにネットワークダイナミクスを変更することが可能である。
Some RPL control messages, such as the DODAG Information Object (DIO), are ICMPv6 messages that are broadcast to all neighbor nodes. With 6TiSCH, the broadcast channel requirement is addressed by 6top by configuring TSCH to provide a broadcast channel, as opposed to, for instance, piggybacking the DIO messages in Layer 2 Enhanced Beacons (EBs), which would produce undue timer coupling among layers and packet size issues, and could conflict with the policy of production networks where EBs are mostly eliminated to conserve energy.
DoDag Information Object（DIO）などのRPL制御メッセージは、すべての隣接ノードにブロードキャストされているICMPv6メッセージです。6tischでは、ブロードキャストチャネル要件は、例えばレイヤ2の強化ビーコン（EBS）のPiggyBackingとは対照的に、TSCHを設定して、レイヤーとパケット間の過度のタイマ結合を生成するであろうサイズの問題、そしてEBSがエネルギーを節約するためにほとんど排除されるプロダクションネットワークのポリシーと競合する可能性があります。
Nodes in a TSCH network must be time synchronized. A node keeps synchronized to its time source neighbor through a combination of frame-based and acknowledgment-based synchronization. To maximize battery life and network throughput, it is advisable that RPL ICMP discovery and maintenance traffic (governed by the Trickle timer) be somehow coordinated with the transmission of time synchronization packets (especially with Enhanced Beacons).
TSCHネットワーク内のノードは時間同期されている必要があります。ノードは、フレームベースおよび確認応答ベースの同期の組み合わせを通して、そのタイムソース隣接に同期し続ける。バッテリ寿命とネットワークスループットを最大化するために、RPL ICMPの発見とメンテナンストラフィック（トリクルタイマーによって管理されている）は、時間同期パケットの送信とともに（特に強化されたビーコンで）協調していることが推奨されます。
This could be achieved through an interaction of the 6top sublayer and the RPL Objective Function, or could be controlled by a management entity.
これは、6つのサブレイヤとRPLの目的関数との相互作用を通して達成することも、管理エンティティによって制御することもできます。
Time distribution requires a loop-free structure. Nodes caught in a synchronization loop will rapidly desynchronize from the network and become isolated. 6TiSCH uses a RPL DAG with a dedicated global Instance for the purpose of time synchronization. That Instance is referred to as the Time Synchronization Global Instance (TSGI). The TSGI can be operated in either of the three modes that are detailed in Section 3.1.3 of RPL [RFC6550], "Instances, DODAGs, and DODAG Versions". Multiple uncoordinated DODAGs with independent Roots may be used if all the Roots share a common time source such as the Global Positioning System (GPS).
時間分布はループフリー構造を必要とします。同期ループで捕捉されたノードは、ネットワークから迅速に非同期化され、分離されます。6tischは、時間同期を目的として専用のグローバルインスタンスを持つRPL DAGを使用します。そのインスタンスはTime Synchronization Global Instance（TSGI）と呼ばれます。TSGIは、RPL [RFC6550]、「インスタンス、DoDags、DoDagバージョン」の3.1.3項に詳述されている3つのモードのいずれかで操作できます。独立したルートを備えた複数の非従順なドダグを使用すると、全てのルーツが全地球測位システム（GPS）などの共通の時間源を共有する場合に使用することができる。
In the absence of a common time source, the TSGI should form a single DODAG with a virtual Root. A backbone network is then used to synchronize and coordinate RPL operations between the Backbone Routers that act as sinks for the LLN. Optionally, RPL's periodic operations may be used to transport the network synchronization. This may mean that 6top would need to trigger (override) the Trickle timer if no other traffic has occurred for such a time that nodes may get out of synchronization.
一般的な時間源がない場合、TSGIは仮想ルートを持つ単一のDoDagを形成する必要があります。その後、LLNのシンクとして機能するバックボーンルータ間のRPL動作を同期させて座標を変更するためにバックボーンネットワークが使用されます。任意選択で、RPLの周期的な操作を使用してネットワーク同期を転送することができる。これは、ノードが同期しなくなる可能性があるように、他のトラフィックが発生していない場合は、トリックルタイマーをトリガー（オーバーライド）する必要があることを意味します。
A node that has not joined the TSGI advertises a MAC-level Join Priority of 0xFF to notify its neighbors that is not capable of serving as time parent. A node that has joined the TSGI advertises a MAC-level Join Priority set to its DAGRank() in that Instance, where DAGRank() is the operation specified in Section 3.5.1 of [RFC6550], "Rank Comparison".
TSGIに参加していないノードは、時間親として機能することができないネイバーのMACレベル結合優先順位をアドバタイズします。TSGIに参加したノードは、そのインスタンスでDagrank（）にMACレベルの結合優先順位が設定されています。ここで、dagrank（）は[RFC6550]のセクション3.5.1で指定された操作、「ランク比較」です。
The provisioning of a RPL Root is out of scope for both RPL and this architecture, whereas RPL enables the propagation of configuration information down the DODAG. This applies to the TSGI as well; a Root is configured, or obtains by unspecified means, the knowledge of the RPLInstanceID for the TSGI. The Root advertises its DagRank in the TSGI, which must be less than 0xFF, as its Join Priority in its IEEE Std 802.15.4 EBs.
RPLルートのプロビジョニングはRPLとこのアーキテクチャの両方に対して範囲外ですが、RPLはDODAGの設定情報の伝播を可能にします。これはTSGIにも当てはまります。ルートは、TSGIのRPLINSTANCEIDの知識である不特定の手段で構成されているか、または取得されます。ルートはTSGI内のDagrankを宣伝しています。これは、そのIEEE STD 802.15.4 EBSの結合優先順位として、0xFF未満でなければなりません。
A node that reads a Join Priority of less than 0xFF should join the neighbor with the lesser Join Priority and use it as time parent. If the node is configured to serve as time parent, then the node should join the TSGI, obtain a Rank in that Instance, and start advertising its own DagRank in the TSGI as its Join Priority in its EBs.
結合優先順位が0xFF未満の結合優先順位を読み取るノードは、近隣に結合された結合優先順位で結合し、それを時間親として使用する必要があります。ノードが時間親として機能するように構成されている場合、ノードはTSGIに参加し、そのインスタンスのランクを取得し、そのEBSの結合優先順位としてTSGI内の独自のDagrankをアドバタイズし始めます。
6TiSCH enables IPv6 best-effort (stochastic) transmissions over a MAC layer that is also capable of scheduled (deterministic) transmissions. A window of time is defined around the scheduled transmission where the medium must, as much as practically feasible, be free of contending energy to ensure that the medium is free of contending packets when the time comes for a scheduled transmission. One simple way to obtain such a window is to format time and frequencies in cells of transmission of equal duration. This is the method that is adopted in IEEE Std 802.15.4 TSCH as well as the Long Term Evolution (LTE) of cellular networks.
6Tischは、スケジュールされた（決定論的）送信が可能なMAC層上のIPv6のベストエフォート（確率的）送信を可能にします。時間が実用的に実行可能である限り、媒体が予定された送信のために困難なパケットがないことを確実にするために、媒体が実質的に実現可能であることを確実にする予定の送信の周りに定義される。そのようなウィンドウを得るための簡単な方法は、等間期間の送信のセル内の時間および周波数をフォーマットすることである。これは、IEEE STD 802.15.4 TSCHとセルラーネットワークの長期進化（LTE）で採用されている方法です。
The 6TiSCH architecture defines a global concept that is called a Channel Distribution and Usage (CDU) matrix to describe that formatting of time and frequencies.
6Tischアーキテクチャは、時間と周波数のフォーマットを説明するためのチャネル配信と使用法（CDU）行列と呼ばれるグローバルコンセプトを定義します。
A CDU matrix is defined centrally as part of the network definition. It is a matrix of cells with a height equal to the number of available channels (indexed by channelOffsets) and a width (in timeslots) that is the period of the network scheduling operation (indexed by slotOffsets) for that CDU matrix. There are different models for scheduling the usage of the cells, which place the responsibility of avoiding collisions either on a central controller or on the devices themselves, at an extra cost in terms of energy to scan for free cells (more in Section 4.4).
CDU行列は、ネットワーク定義の一部として一元的に定義されます。これは、そのCDU行列のネットワークスケジューリング動作（スロットオフセットでインデックス化された）の期間である、利用可能なチャンネルの数（チャネルオフセットによってインデックスされた）と幅（スロットオフセットによってインデックスされた）に等しい高さを持つセルのマトリックスです。セルの使用をスケジュールするためのさまざまなモデルがあります。これにより、中央コントローラ上またはデバイス自体のいずれかで衝突を回避する責任を配置して、自由セルをスキャンするエネルギーの観点から追加のコストで（セクション4.4）。
The size of a cell is a timeslot duration, and values of 10 to 15 milliseconds are typical in 802.15.4 TSCH to accommodate for the transmission of a frame and an ack, including the security validation on the receive side, which may take up to a few milliseconds on some device architecture.
セルのサイズはタイムスロット期間であり、10~15ミリ秒の値は802.15.4 TSCHでは典型的なもので、受信側のセキュリティ検証を含むACKの送信に対応することができます。いくつかのデバイスアーキテクチャで数ミリ秒。
A CDU matrix iterates over a well-known channel rotation called the hopping sequence. In a given network, there might be multiple CDU matrices that operate with different widths, so they have different durations and represent different periodic operations. It is recommended that all CDU matrices in a 6TiSCH domain operate with the same cell duration and are aligned so as to reduce the chances of interferences from the Slotted ALOHA operations. The knowledge of the CDU matrices is shared between all the nodes and used in particular to define slotframes.
CDU行列は、ホッピングシーケンスと呼ばれる周知のチャネル回転を繰り返す。特定のネットワークでは、異なる幅で動作する複数のCDU行列がある可能性があるため、それらは異なる期間を持ち、異なる周期的な操作を表します。6tischドメイン内のすべてのCDU行列は、同じセル期間で動作し、スロット付きALOHA操作からの干渉の可能性を減らすように整列されることをお勧めします。CDU行列の知識は、すべてのノード間で共有され、特にスロットフレームを定義するために使用されます。
A slotframe is a MAC-level abstraction that is common to all nodes and contains a series of timeslots of equal length and precedence. It is characterized by a slotframe_ID and a slotframe_size. A slotframe aligns to a CDU matrix for its parameters, such as number and duration of timeslots.
スロットフレームは、すべてのノードに共通のMACレベルの抽象化で、長さと優先順位の一連のタイムスロットを含みます。これはslotframe_idとslotframe_sizeによって特徴付けられます。スロットフレームは、タイムスロットの数および期間などのパラメータのCDU行列に整列します。
Multiple slotframes can coexist in a node schedule, i.e., a node can have multiple activities scheduled in different slotframes. A slotframe is associated with a priority that may be related to the precedence of different 6TiSCH topologies. The slotframes may be aligned to different CDU matrices and thus have different widths. There is typically one slotframe for scheduled traffic that has the highest precedence and one or more slotframe(s) for RPL traffic. The timeslots in the slotframe are indexed by the slotOffset; the first cell is at slotOffset 0.
複数のスロットフレームはノードスケジュールで共存することができます。すなわち、ノードは、異なるスロットフレームでスケジュールされた複数のアクティビティを持つことができます。スロットフレームは、異なる6tischトポロジの優先順位に関連している可能性がある優先順位に関連付けられています。スロットフレームは、異なるCDU行列に整列させることができ、したがって異なる幅を有する。標準的なトラフィックとRPLトラフィックの1つ以上のスロットフレームを持つスケジュールされたトラフィックのスロットフレームが1つあります。スロットフレーム内のタイムスロットはSlotOffsetによって索引付けされます。第1のセルはスロットオフセット0にある。
When a packet is received from a higher layer for transmission, 6top inserts that packet in the outgoing queue that matches the packet best (Differentiated Services [RFC2474] can therefore be used). At each scheduled transmit slot, 6top looks for the frame in all the outgoing queues that best matches the cells. If a frame is found, it is given to the TSCH MAC for transmission.
送信のために上位レイヤからパケットを受信すると、パケットの最良のパケット（微分サービス[RFC2474]を使用することができる）の発信キューにそのパケットを挿入します。各スケジュールされた送信スロットで、6社はセルに最も適したすべての発信キュー内のフレームを探します。フレームが見つかった場合は、送信用のTSCH MACに表示されます。
The 6TiSCH architecture introduces the concept of chunks (Section 2.1) to distribute the allocation of the spectrum for a whole group of cells at a time. The CDU matrix is formatted into a set of chunks, possibly as illustrated in Figure 8, each of the chunks identified uniquely by a chunk-ID. The knowledge of this formatting is shared between all the nodes in a 6TiSCH network. It could be conveyed during the join process, codified into a profile document, or obtained using some other mechanism. This is as opposed to Static Scheduling, which refers to the preprogrammed mechanism specified in [RFC8180] and which existed before the distribution of the chunk formatting.
6Tischアーキテクチャでは、一度にセルのグループ全体のスペクトルの割り当てを分散させるために、チャンクの概念（セクション2.1）を紹介します。CDU行列は、おそらく図8に示すように、チャンクIDによって一意に識別された各チャンクのセットにフォーマットされています。このフォーマットの知識は、6Tischネットワーク内のすべてのノード間で共有されています。それは、結合プロセス中に伝達され、プロファイル文書に文化されているか、または他のいくつかのメカニズムを使用して取得することができます。これは静的スケジューリングとは対照的です。
+-----+-----+-----+-----+-----+-----+-----+ +-----+
chan.Off. 0 |chnkA|chnkP|chnk7|chnkO|chnk2|chnkK|chnk1| ... |chnkZ|
+-----+-----+-----+-----+-----+-----+-----+ +-----+
chan.Off. 1 |chnkB|chnkQ|chnkA|chnkP|chnk3|chnkL|chnk2| ... |chnk1|
+-----+-----+-----+-----+-----+-----+-----+ +-----+
...
+-----+-----+-----+-----+-----+-----+-----+ +-----+
chan.Off. 15 |chnkO|chnk6|chnkN|chnk1|chnkJ|chnkZ|chnkI| ... |chnkG|
+-----+-----+-----+-----+-----+-----+-----+ +-----+
0 1 2 3 4 5 6 M
Figure 8: CDU Matrix Partitioning in Chunks
図8：チャンクにおけるCDU行列分割
The 6TiSCH architecture envisions a protocol that enables chunk ownership appropriation whereby a RPL parent discovers a chunk that is not used in its interference domain, claims the chunk, and then defends it in case another RPL parent would attempt to appropriate it while it is in use. The chunk is the basic unit of ownership that is used in that process.
6Tischアーキテクチャは、RPL親がその干渉ドメインで使用されていないチャンクを検出し、チャンクをクレームし、それを使用中に適切に試みる場合に備えて、それを防御します。。チャンクは、そのプロセスで使用されている所有権の基本単位です。
As a result of the process of chunk ownership appropriation, the RPL parent has exclusive authority to decide which cell in the appropriated chunk can be used by which node in its interference domain. In other words, it is implicitly delegated the right to manage the portion of the CDU matrix that is represented by the chunk.
チャンクの所有権の計上のプロセスの結果として、RPL親は、その干渉ドメイン内のどのノードにどのセルを使用するかを決定できるかを決定するための排他的な権限を有する。言い換えれば、チャンクによって表されるCDU行列の部分を管理する権利を暗黙的に委任します。
Initially, those cells are added to the heap of free cells, then dynamically placed into existing bundles, into new bundles, or allocated opportunistically for one transmission.
最初に、それらの細胞は遊離細胞のヒープに追加され、次いで動的に既存のバンドルに新しいバンドル内に配置されるか、または1つの送信に対して日和見的に割り当てられる。
Note that a PCE is expected to have precedence in the allocation, so that a RPL parent would only be able to obtain portions that are not in use by the PCE.
PCEが割り当てに優先されると予想されているので、RPL親がPCEによって使用されていない部分を取得できるだけであることに注意してください。
6TiSCH uses four paradigms to manage the TSCH schedule of the LLN nodes: Static Scheduling, Neighbor-to-Neighbor Scheduling, Remote Monitoring and Scheduling Management, and Hop-by-Hop Scheduling. Multiple mechanisms are defined that implement the associated Interaction Models, and they can be combined and used in the same LLN. Which mechanism(s) to use depends on application requirements.
6Tischは4つのパラダイムを使用して、静的スケジューリング、隣接スケジューリング、リモート監視、スケジューリング管理、およびホップバイホップスケジューリングのTSCHスケジュールを管理します。関連するインタラクションモデルを実装する複数のメカニズムが定義されており、それらは同じLLNで組み合わされて使用されます。使用するメカニズムはアプリケーションの要件によって異なります。
In the simplest instantiation of a 6TiSCH network, a common fixed schedule may be shared by all nodes in the network. Cells are shared, and nodes contend for slot access in a Slotted ALOHA manner.
6tischネットワークの最も単純なインスタンス化では、共通の固定スケジュールはネットワーク内のすべてのノードによって共有されてもよい。セルが共有され、ノードはスロット付きアロハ方式でスロットアクセスを競合します。
A static TSCH schedule can be used to bootstrap a network, as an initial phase during implementation or as a fall-back mechanism in case of network malfunction. This schedule is preestablished, for instance, decided by a network administrator based on operational needs. It can be preconfigured into the nodes, or, more commonly, learned by a node when joining the network using standard IEEE Std 802.15.4 Information Elements (IE). Regardless, the schedule remains unchanged after the node has joined a network. RPL is used on the resulting network. This "minimal" scheduling mechanism that implements this paradigm is detailed in [RFC8180].
静的TSCHスケジュールを使用して、ネットワークを実装中またはネットワークの誤動作の場合のフォールバックメカニズムとして、ネットワークを初期フェーズとしてブートストラップすることができます。このスケジュールは、例えば、操作上のニーズに基づいてネットワーク管理者によって決定されたものです。ノードに事前設定することも、標準のIEEE STD 802.15.4情報要素（IE）を使用してネットワークに参加するときにノードによって学習することもできます。とにかく、ノードがネットワークに参加した後、スケジュールは変更されません。結果のネットワークではRPLが使用されます。このパラダイムを実装するこの「最小」スケジューリングメカニズムは[RFC8180]に詳述されています。
In the simplest instantiation of a 6TiSCH network described in Section 4.4.1, nodes may expect a packet at any cell in the schedule and will waste energy idle listening. In a more complex instantiation of a 6TiSCH network, a matching portion of the schedule is established between peers to reflect the observed amount of transmissions between those nodes. The aggregation of the cells between a node and a peer forms a bundle that the 6top sublayer uses to implement the abstraction of a link for IP. The bandwidth on that link is proportional to the number of cells in the bundle.
セクション4.4.1で説明されている6Tischネットワークの最も簡単なインスタンス化では、ノードはスケジュール内のどのセルでのパケットを期待しており、エネルギーアイドルリスニングを無駄にすることができます。6tischネットワークのより複雑なインスタンス化では、それらのノード間の送信量を反映するために、スケジュールの整合部分がピア間で確立される。ノードとピア間のセルの集約は、6tto SublayerがIPのリンクの抽象化を実装するために使用するバンドルを形成します。そのリンクの帯域幅は、バンドル内のセル数に比例します。
If the size of a bundle is configured to fit an average amount of bandwidth, peak traffic is dropped. If the size is configured to allow for peak emissions, energy is wasted idle listening.
バンドルのサイズが平均帯域幅の量に合うように設定されている場合、ピークトラフィックはドロップされます。サイズがピーク排出量を可能にするように構成されている場合、エネルギーはアイドル聴取されます。
As discussed in more detail in Section 4.3, the 6top Protocol [RFC8480] specifies the exchanges between neighbor nodes to reserve soft cells to transmit to one another, possibly under the control of a Scheduling Function (SF). Because this reservation is done without global knowledge of the schedule of the other nodes in the LLN, scheduling collisions are possible.
セクション4.3でより詳細に説明したように、6TOPプロトコル[RFC8480]は、隣接ノード間の交換を特定して互いに送信してスケジューリング機能の制御下にある。この予約は、LLN内の他のノードのスケジュールに関するグローバルな知識なしに行われるため、スケジューリング衝突が可能です。
And as discussed in Section 4.3.2, an optional SF is used to monitor bandwidth usage and to perform requests for dynamic allocation by the 6top sublayer. The SF component is not part of the 6top sublayer. It may be co-located on the same device or may be partially or fully offloaded to an external system. The "6TiSCH Minimal Scheduling Function (MSF)" [RFC9033] provides a simple SF that can be used by default by devices that support dynamic scheduling of soft cells.
また、セクション4.3.2で説明したように、オプションのSFは帯域幅の使用を監視し、6社のサブレイヤによる動的割り当ての要求を実行するために使用されます。SFコンポーネントは6社のサブレイヤの一部ではありません。それは同じ装置上に配置されてもよく、または外部システムに部分的にまたは完全にオフロードされてもよい。「6tisch最小スケジューリング関数（MSF）」[RFC9033]は、ソフトセルの動的スケジューリングをサポートするデバイスによってデフォルトで使用できる単純なSFを提供します。
Monitoring and relocation is done in the 6top sublayer. For the upper layer, the connection between two neighbor nodes appears as a number of cells. Depending on traffic requirements, the upper layer can request 6top to add or delete a number of cells scheduled to a particular neighbor, without being responsible for choosing the exact slotOffset/channelOffset of those cells.
監視と再配置は、6つのサブレイヤで行われます。上位層の場合、2つの隣接ノード間の接続は数のセルとして表示されます。トラフィック要件に応じて、上位層は、それらのセルの正確なSlotOffset / ChannelOffsetを選択することなく、特定のネイバーにスケジュールされた数のセルを追加または削除することができます。
Remote Monitoring and Schedule Management refers to a DetNet/SDN model whereby an NME and a scheduling entity, associated with a PCE, reside in a central controller and interact with the 6top sublayer to control IPv6 links and Tracks (Section 4.5) in a 6TiSCH network. The composite centralized controller can assign physical resources (e.g., buffers and hard cells) to a particular Track to optimize the reliability within a bounded latency for a well-specified flow.
リモート監視とスケジュール管理とは、PCEに関連付けられたNMEとスケジューリングエンティティがセントラルコントローラに存在し、6TischネットワークでIPv6リンクとトラックを制御するために6社のサブレイヤーと対話するためのDetnet / SDNモデルを指します。。コンポジット集中制御コントローラは、特定のトラックに物理リソース（例えば、バッファおよびハードセル）を割り当てることができ、特定のトラックには、指定されたフローの境界待ち時間内の信頼性を最適化することができる。
The work in the 6TiSCH Working Group focused on nondeterministic traffic and did not provide the generic data model necessary for the controller to monitor and manage resources of the 6top sublayer. This is deferred to future work, see Appendix A.1.2.
6Tischワーキンググループの作業は、不定的なトラフィックに焦点を当て、コントローラが6社のサブレイヤのリソースを監視および管理するために必要な一般的なデータモデルを提供しませんでした。これは将来の作業に延期されている、付録A.1.2を参照してください。
With respect to centralized routing and scheduling, it is envisioned that the related component of the 6TiSCH architecture would be an extension of the DetNet architecture [RFC8655], which studies Layer 3 aspects of Deterministic Networks and covers networks that span multiple Layer 2 domains.
集中ルーティングおよびスケジューリングに関して、6Tischアーキテクチャの関連コンポーネントはDetnet Architecture [RFC8655]の拡張であり、これは決定論的ネットワークのレイヤ3の側面を研究し、複数のレイヤ2ドメインにまたがるネットワークをカバーすることが想定される。
The DetNet architecture is a form of Software-Defined Networking (SDN) architecture and is composed of three planes: a (User) Application Plane, a Controller Plane (where the PCE operates), and a Network Plane, which can represent a 6TiSCH LLN.
DetNetアーキテクチャは、ソフトウェア定義ネットワーク（SDN）アーキテクチャの一種であり、3つの平面で構成されており、A（ユーザ）アプリケーションプレーン、コントローラプレーン（PCEが動作させる）、および6Tisch LLNを表すことができるネットワークプレーン。
"Software-Defined Networking (SDN): Layers and Architecture Terminology" [RFC7426] proposes a generic representation of the SDN architecture that is reproduced in Figure 9.
「ソフトウェア定義ネットワーク（SDN）：レイヤーおよびアーキテクチャの用語」[RFC7426]は、図9で再現されるSDNアーキテクチャの一般的な表現を提案しています。
o--------------------------------o
| |
| +-------------+ +----------+ |
| | Application | | Service | |
| +-------------+ +----------+ |
| Application Plane |
o---------------Y----------------o
|
*-----------------------------Y---------------------------------*
| Network Services Abstraction Layer (NSAL) |
*------Y------------------------------------------------Y-------*
| |
| Service Interface |
| |
o------Y------------------o o---------------------Y------o
| | Control Plane | | Management Plane | |
| +----Y----+ +-----+ | | +-----+ +----Y----+ |
| | Service | | App | | | | App | | Service | |
| +----Y----+ +--Y--+ | | +--Y--+ +----Y----+ |
| | | | | | | |
| *----Y-----------Y----* | | *---Y---------------Y----* |
| | Control Abstraction | | | | Management Abstraction | |
| | Layer (CAL) | | | | Layer (MAL) | |
| *----------Y----------* | | *----------Y-------------* |
| | | | | |
o------------|------------o o------------|---------------o
| |
| CP | MP
| Southbound | Southbound
| Interface | Interface
| |
*------------Y---------------------------------Y----------------*
| Device and resource Abstraction Layer (DAL) |
*------------Y---------------------------------Y----------------*
| | | |
| o-------Y----------o +-----+ o--------Y----------o |
| | Forwarding Plane | | App | | Operational Plane | |
| o------------------o +-----+ o-------------------o |
| Network Device |
+---------------------------------------------------------------+
Figure 9: SDN Layers and Architecture Terminology per RFC 7426
図9：RFCごとのSDNレイヤーおよびアーキテクチャの用語
The PCE establishes end-to-end Tracks of hard cells, which are described in more detail in Section 4.6.1.
PCEはハードセルのエンドツーエンドトラックを確立します。これはセクション4.6.1でより詳細に説明されています。
The DetNet work is expected to enable end-to-end deterministic paths across heterogeneous networks. This can be, for instance, a 6TiSCH LLN and an Ethernet backbone.
DetNet Workは、異種ネットワークを介したエンドツーエンドの決定論的パスを有効にすると予想されます。これは、例えば6tisch LLNとイーサネットバックボーンとすることができる。
This model fits the 6TiSCH extended configuration, whereby a 6BBR federates multiple 6TiSCH LLNs in a single subnet over a backbone that can be, for instance, Ethernet or Wi-Fi. In that model, 6TiSCH 6BBRs synchronize with one another over the backbone, so as to ensure that the multiple LLNs that form the IPv6 subnet stay tightly synchronized.
このモデルは6tisch拡張構成に適合します。これにより、6BBRは、例えばイーサネットまたはWi-Fiなどのバックボーンを介して単一のサブネット内に複数の6Tisch LLNを連携します。そのモデルでは、IPv6サブネットを形成する複数のLLNが確実に同期されていることを確認するために、6tisch 6bbrがバックボーンを介して互いに同期します。
If the backbone is deterministic, then the Backbone Router ensures that the end-to-end deterministic behavior is maintained between the LLN and the backbone. It is the responsibility of the PCE to compute a deterministic path end to end across the TSCH network and an IEEE Std 802.1 TSN Ethernet backbone, and it is the responsibility of DetNet to enable end-to-end deterministic forwarding.
バックボーンが決定論的である場合、バックボーンルータは、最終終了の決定論的動作がLLNとバックボーンの間で維持されることを保証します。TSCHネットワークを介して終わる決定論的パス終了を計算するPCEの責任であり、IEEE STD 802.1 TSNイーサネットバックボーンであり、エンドツーエンドの決定論的転送を可能にするためのDetNetの責任です。
A node can reserve a Track (Section 4.5) to one or more destination(s) that are multiple hops away by installing soft cells at each intermediate node. This forms a Track of soft cells. A Track SF above the 6top sublayer of each node on the Track is needed to monitor these soft cells and trigger relocation when needed.
ノードは、各中間ノードでソフトセルをインストールすることによって、複数のホップである1つまたは複数の宛先にトラック（セクション4.5）を予約できます。これは柔らかい細胞の軌跡を形成する。トラック上の各ノードの6台の副層の上のトラックSFは、これらのソフトセルを監視し、必要に応じて再配置をトリガーするために必要です。
This hop-by-hop reservation mechanism is expected to be similar in essence to [RFC3209] and/or [RFC4080] and [RFC5974]. The protocol for a node to trigger hop-by-hop scheduling is not yet defined.
このホップバイホップ予約メカニズムは、[RFC3209]および/または[RFC4080]および[RFC5974]に本質的に類似すると予想される。ホップバイホップスケジューリングをトリガーするノードのプロトコルはまだ定義されていません。
The architecture introduces the concept of a Track, which is a directed path from a source 6TiSCH node to one or more destination 6TiSCH node(s) across a 6TiSCH LLN.
アーキテクチャは、6Tisch LLNを介してソース6Tischノードから1つまたは複数の宛先6tischノードへの指向経路であるトラックの概念を導入する。
A Track is the 6TiSCH instantiation of the concept of a deterministic path as described in [RFC8655]. Constrained resources such as memory buffers are reserved for that Track in intermediate 6TiSCH nodes to avoid loss related to limited capacity. A 6TiSCH node along a Track not only knows which bundles of cells it should use to receive packets from a previous hop but also knows which bundle(s) it should use to send packets to its next hop along the Track.
トラックは、[RFC8655]に記載されているように、決定論的パスの概念の6Tischインスタンス化です。メモリバッファなどの制約されたリソースは、限られた容量に関連する損失を回避するために、中間6Tischノード内のそのトラックのために予約されています。トラックに沿った6Tischノードは、前のホップからパケットを受信するために使用するセルのどのバンドルを知っているだけでなく、トラックに沿って次のホップにパケットを送信するのに使用するかを知っています。
A Track is associated with Layer 2 bundles of cells with related schedules and logical relationships that ensure that a packet that is injected in a Track will progress in due time all the way to destination.
トラックは、関連するスケジュールを持つセルのレイヤ2バンドルと、トラック内に注入されたパケットが宛先までのすべての方法で実行されることを保証する論理的な関係と関連付けられています。
Multiple cells may be scheduled in a Track for the transmission of a single packet, in which case the normal operation of IEEE Std 802.15.4 Automatic Repeat-reQuest (ARQ) can take place; the acknowledgment may be omitted in some cases, for instance, if there is no scheduled cell for a possible retry.
1つのパケットの送信のために複数のセルをトラック内でスケジュールすることができ、その場合、IEEE STD 802.15.4の自動繰り返し要求（ARQ）の通常動作が行われることができる。たとえば、可能なリトライのためのスケジュールセルがない場合、確認応答は省略される可能性があります。
There are several benefits for using a Track to forward a packet from a source node to the destination node:
トラックを使用してパケットをソースノードから宛先ノードに転送するためのいくつかの利点があります。
1. Track Forwarding, as further described in Section 4.6.1, is a Layer 2 forwarding scheme, which introduces less process delay and overhead than a Layer 3 forwarding scheme. Therefore, LLN devices can save more energy and resources, which is critical for resource-constrained devices.
1. 4.6.1項でさらに説明されているように、トラック転送はレイヤ2転送方式であり、これはレイヤ3転送方式よりも少ないプロセス遅延およびオーバーヘッドを導入する。したがって、LLNデバイスは、より多くのエネルギーとリソースを節約でき、これはリソース制約付きデバイスにとって重要です。
2. Since channel resources, i.e., bundles of cells, have been reserved for communications between 6TiSCH nodes of each hop on the Track, the throughput and the maximum latency of the traffic along a Track are guaranteed, and the jitter is minimized.
2. チャネルリソース、すなわちセルのバンドルは、トラック上の各ホップの6Tischノード間の通信のために予約されており、トラックに沿ったトラックのスループットおよび最大待ち時間は保証され、ジッタは最小化される。
3. By knowing the scheduled timeslots of incoming bundle(s) and outgoing bundle(s), 6TiSCH nodes on a Track could save more energy by staying in sleep state during inactive slots.
3. 着信バンドルのスケジュールされたタイムスロットと発信バンドル（S）を知ることで、トラック上の6Tischノードは、非アクティブスロットの間、スリープ状態に留まることによってより多くのエネルギーを節約することができます。
4. Tracks are protected from interfering with one another if a cell is scheduled to belong to at most one Track, and congestion loss is avoided if at most one packet can be presented to the MAC to use that cell. Tracks enhance the reliability of transmissions and thus further improve the energy consumption in LLN devices by reducing the chances of retransmission.
4. セルがほとんどのトラックに属するようにスケジュールされている場合、トラックは互いに干渉され、そのセルを使用するためにMACに提示できる場合、輻輳損失が回避されます。トラックは送信の信頼性を高め、再送の可能性を減らすことによってLLNデバイスのエネルギー消費をさらに向上させる。
A Serial (or simple) Track is the 6TiSCH version of a circuit: a bundle of cells that are programmed to receive (RX-cells) is uniquely paired with a bundle of cells that are set to transmit (TX-cells), representing a Layer 2 forwarding state that can be used regardless of the network-layer protocol. A Serial Track is thus formed end-to-end as a succession of paired bundles: a receive bundle from the previous hop and a transmit bundle to the next hop along the Track.
シリアル（または単純な）トラックは、6Tischバージョンの回路です。受信するようにプログラムされたセルのバンドル（RX-セル）は、送信（TXセル）に設定されているセルのバンドルと一意に対応します。ネットワーク層プロトコルに関係なく使用できるレイヤ2転送状態。したがって、シリアルトラックは、一連の一連のバンドルとしてのエンドツーエンドで、前のホップからの受信バンドルとトラックに沿った次のホップへの送信バンドルとを受信します。
For a given iteration of the device schedule, the effective channel of the cell is obtained by looping through a well-known hopping sequence beginning at Epoch time and starting at the cell's channelOffset, which results in a rotation of the frequency that is used for transmission. The bundles may be computed so as to accommodate both variable rates and retransmissions, so they might not be fully used in the iteration of the schedule.
デバイススケジュールの許容された反復のために、セルの有効チャネルは、エポック時間から始まり、セルのチャネルオフセットから始まる周知のホッピングシーケンスを介してループすることによって得られ、それは送信に使用される周波数の回転をもたらす。。バンドルは、可変レートと再送信の両方に対応するように計算されてもよいので、スケジュールの反復では十分に使用されない可能性があります。
The art of Deterministic Networks already includes packet replication and elimination techniques. Example standards include the Parallel Redundancy Protocol (PRP) and the High-availability Seamless Redundancy (HSR) [IEC62439]. Similarly, and as opposed to a Serial Track that is a sequence of nodes and links, a Complex Track is shaped as a directed acyclic graph towards one or more destination(s) to support multipath forwarding and route around failures.
決定論的ネットワークの技術はすでにパケット複製および排除技術を含む。例示的な規格には、並列冗長プロトコル（PRP）と高可用性のシームレスな冗長性（HSR）[IEC62439]が含まれます。同様に、そして一連のノードおよびリンクであるシリアルトラックとは対照的に、複雑なトラックは、故障の周りのマルチパス転送およびルートをサポートするために、1つまたは複数の目的地への指向性非巡回グラフとして形作られている。
A Complex Track may branch off over noncongruent branches for the purpose of multicasting and/or redundancy, in which case, it reconverges later down the path. This enables the Packet Replication, Elimination, and Ordering Functions (PREOF) defined by DetNet. Packet ARQ, Replication, Elimination, and Overhearing (PAREO) adds radio-specific capabilities of Layer 2 ARQ and promiscuous listening to redundant transmissions to compensate for the lossiness of the medium and meet industrial expectations of a RAW network. Combining PAREO and PREOF, a Track may extend beyond the 6TiSCH network into a larger DetNet network.
複雑なトラックは、マルチキャストおよび/または冗長性の目的のために非一貫性の分岐を介して分岐することができ、その場合、その後経路の後に再延びる。これにより、Detnetによって定義されたパケット複製、消去、および順序付け機能（PREOF）が可能になります。パケットARQ、レプリケーション、除去、およびオーバーハーディング（Pareo）は、媒体の損失度を補償し、生ネットワークの産業上の期待を満たすために、レイヤ2 ARQの無線固有の機能と冗長送信を聴いています。PareoとPREOFを組み合わせると、トラックは6tischネットワークを超えて大規模なDetnetネットワークに延びることがあります。
In the art of TSCH, a path does not necessarily support PRE, but it is almost systematically multipath. This means that a Track is scheduled so as to ensure that each hop has at least two forwarding solutions, and the forwarding decision is to try the preferred one and use the other in case of Layer 2 transmission failure as detected by ARQ. Similarly, at each 6TiSCH hop along the Track, the PCE may schedule more than one timeslot for a packet, so as to support Layer 2 retries (ARQ). It is also possible that the field device only uses the second branch if sending over the first branch fails.
TSCHの技術では、パスは必ずしもPREをサポートするわけではありませんが、それはほとんど体系的にマルチパスです。これは、各ホップが少なくとも2つの転送ソリューションを有することを確実にするようにトラックがスケジュールされ、転送決定は、ARQによって検出されたようにレイヤ2送信失敗の場合には他方を使用することであることである。同様に、トラックに沿った各6Tischホップで、PCEはパケットに対して複数のタイムスロットをスケジュールすることができ、レイヤ2の再試行（ARQ）をサポートする。最初のブランチを介して送信された場合、フィールドデバイスが2番目のブランチを使用するだけでも可能です。
Ultimately, DetNet should enable extending a Track beyond the 6TiSCH LLN as illustrated in Figure 10. In that example, a Track is laid out from a field device in a 6TiSCH network to an IoT gateway that is located on an 802.1 Time-Sensitive Networking (TSN) backbone. A 6TiSCH-aware DetNet service layer handles the Packet Replication, Elimination, and Ordering Functions over the DODAG that forms a Track.
最終的に、DetNetは図10に示すように6tisch LLNを超えてトラックを拡張することを可能にするはずである。その例では、トラックが6tischネットワーク内のフィールドデバイスから802.1の時間依存ネットワーキング上にあるIoTゲートウェイにレイアウトされる（TSN）バックボーン。6tisch対応Detnetサービス層は、トラックを形成するDoDagを介してパケットの複製、除去、および順序付け機能を処理します。
The Replication function in the 6TiSCH Node sends a copy of each packet over two different branches, and the PCE schedules each hop of both branches so that the two copies arrive in due time at the gateway. In case of a loss on one branch, hopefully the other copy of the packet still makes it in due time. If two copies make it to the IoT gateway, the Elimination function in the gateway ignores the extra packet and presents only one copy to upper layers.
6tischノードのレプリケーション関数は、各パケットのコピーを2つの異なるブランチに送信し、PCEスケジュールは両方の分岐をスケジュールし、ゲートウェイで2つのコピーが到着する。1つの分岐を損失の場合、うまくいけば、パケットの他のコピーはまだ期限切れになります。2つのコピーがIoTゲートウェイに接続されている場合、ゲートウェイ内の除去機能は追加のパケットを無視し、上位層に1つのコピーだけを提示します。
+-=-=-+
| IoT |
| G/W |
+-=-=-+
^ <=== Elimination
Track branch | |
+-=-=-=-+ +-=-=-=-=+ Subnet backbone
| |
+-=|-=+ +-=|-=+
| | | Backbone | | | Backbone
o | | | Router | | | Router
+-=/-=+ +-=|-=+
o / o o-=-o-=-=/ o
o o-=-o-=/ o o o o o
o \ / o o LLN o
o v <=== Replication
o
Figure 10: Example End-to-End DetNet Track
図10：エンドツーエンドのDetnet Trackの例
The 6TiSCH architecture provides the means to avoid waste of cells as well as overflows in the transmit bundle of a Track, as follows:
6tischアーキテクチャは、次のように、トラックの送信束内のオーバーフローを回避するための手段を提供する。
A TX-cell that is not needed for the current iteration may be reused opportunistically on a per-hop basis for routed packets. When all of the frames that were received for a given Track are effectively transmitted, any available TX-cell for that Track can be reused for upper-layer traffic for which the next-hop router matches the next hop along the Track. In that case, the cell that is being used is effectively a TX-cell from the Track, but the short address for the destination is that of the next-hop router.
現在の反復に必要ではないTXセルは、経路指定されたパケットのホップごとに機会的に再利用されてもよい。所与のトラックに対して受信された全てのフレームが効果的に送信されると、そのトラックのための利用可能なTXセルは、次のホップルータがトラックに沿った次のホップと一致する上位レイヤトラフィックに対して再利用され得る。その場合、使用されているセルは実質的にトラックからのTxセルですが、宛先の短いアドレスはネクストホップルータの短いアドレスです。
It results in a frame that is received in an RX-cell of a Track with a destination MAC address set to this node, as opposed to the broadcast MAC address that must be extracted from the Track and delivered to the upper layer. Note that a frame with an unrecognized destination MAC address is dropped at the lower MAC layer and thus is not received at the 6top sublayer.
トラックから抽出されて上位層に配信されなければならないブロードキャストMACアドレスとは対照的に、このノードに設定された宛先MACアドレスを持つトラックのRXセルで受信されたフレームをもたらす。認識されていない宛先MACアドレスを有するフレームは、下位MAC層でドロップされ、6TTOPサブレイヤでは受信されないことに留意されたい。
On the other hand, it might happen that there are not enough TX-cells in the transmit bundle to accommodate the Track traffic, for instance, if more retransmissions are needed than provisioned. In that case, and if the frame transports an IPv6 packet, then it can be placed for transmission in the bundle that is used for Layer 3 traffic towards the next hop along the Track. The MAC address should be set to the next-hop MAC address to avoid confusion.
一方、例えばプロビジョニングされているよりも多くの再送信が必要な場合は、トラックトラフィックに対応するのに十分なTXセルがないことが起こる可能性があります。その場合、およびフレームがIPv6パケットを搬送する場合、それはトラックに沿った次のホップに向かってレイヤ3トラフィックに使用されるバンドル内の送信のために配置することができる。混乱を避けるために、MACアドレスをネクストホップMACアドレスに設定する必要があります。
It results in a frame that is received over a Layer 3 bundle that may be in fact associated with a Track. In a classical IP link such as an Ethernet, off-Track traffic is typically in excess over reservation to be routed along the non-reserved path based on its QoS setting. But with 6TiSCH, since the use of the Layer 3 bundle may be due to transmission failures, it makes sense for the receiver to recognize a frame that should be re-Tracked and to place it back on the appropriate bundle if possible. A frame is re-Tracked by scheduling it for transmission over the transmit bundle associated with the Track, with the destination MAC address set to broadcast.
それは、実際にトラックに関連する可能性がある層3バンドルを介して受信されるフレームをもたらす。イーサネット（イーサネットなど）の古典的なIPリンクでは、QoS設定に基づいて、通常はオフトラフィックは通常、予約以外の予約を介してルーティングされます。しかし、6tischでは、レイヤ3バンドルの使用は送信失敗によるものである可能性があるため、受信機が再追跡されるべきフレームを認識し、可能であれば適切なバンドルに戻すことを意味します。宛先MACアドレスがブロードキャストに設定された状態で、トラックに関連付けられた送信バンドルを介して送信するためにフレームが再追跡される。
By forwarding, this document means the per-packet operation that allows delivery of a packet to a next hop or an upper layer in this node. Forwarding is based on preexisting state that was installed as a result of a routing computation, see Section 4.7. 6TiSCH supports three different forwarding models: (GMPLS) Track Forwarding, (classical) IPv6 Forwarding, and (6LoWPAN) Fragment Forwarding.
転送により、この文書とは、このノード内のネクストホップまたは上位層へのパケットの配信を可能にするパケットごとの操作を意味する。転送は、ルーティング計算の結果としてインストールされた既存の既存の状態に基づいています。セクション4.7を参照してください。6Tischは、3つの異なる転送モデルをサポートしています。（GMPLS）トラック転送、（クラシック）IPv6転送、および（6lowpan）フラグメント転送。
Forwarding along a Track can be seen as a Generalized Multiprotocol Label Switching (GMPLS) operation in that the information used to switch a frame is not an explicit label but is rather related to other properties of the way the packet was received, a particular cell in the case of 6TiSCH. As a result, as long as the TSCH MAC (and Layer 2 security) accepts a frame, that frame can be switched regardless of the protocol, whether this is an IPv6 packet, a 6LoWPAN fragment, or a frame from an alternate protocol such as WirelessHART or ISA100.11a.
トラックに沿った転送は、フレームを切り替えるために使用される情報が明示的なラベルではなく、パケットが受信された方法の他のプロパティとはかなり関連するという点で、一般化されたマルチプロトコルラベルスイッチング（GMPLS）操作として見ることができます。6tischの場合その結果、TSCH MAC（およびレイヤ2セキュリティ）がフレームを受け入れる限り、そのフレームはプロトコルに関係なく、これがIPv6パケット、6LOWPANフラグメント、またはそのような代替プロトコルからのフレームを切り替えることができる。WirelessHartまたはISA100.11a。
A data frame that is forwarded along a Track normally has a destination MAC address that is set to broadcast or a multicast address depending on MAC support. This way, the MAC layer in the intermediate nodes accepts the incoming frame and 6top switches it without incurring a change in the MAC header. In the case of IEEE Std 802.15.4, this means effectively to broadcast, so that along the Track the short address for the destination of the frame is set to 0xFFFF.
トラックに沿って転送されるデータフレームは、通常、Macサポートに応じてブロードキャストまたはマルチキャストアドレスに設定されている宛先MACアドレスを持ちます。このようにして、中間ノード内のMAC層は着信フレームを受け入れ、6社はMACヘッダーの変更を招くことなくそれを切り替えます。IEEE STD 802.15.4の場合、これはブロードキャストを効果的に放送することを意味し、トラックに沿ってフレームの宛先の短いアドレスが0xFFFFに設定される。
There are two modes for a Track: an IPv6 native mode and a protocol-independent tunnel mode.
トラックには2つのモードがあります：IPv6ネイティブモードとプロトコルに依存しないトンネルモードです。
In native mode, the Protocol Data Unit (PDU) is associated with flow-dependent metadata that refers uniquely to the Track, so the 6top sublayer can place the frame in the appropriate cell without ambiguity. In the case of IPv6 traffic, this flow may be identified using a 6-tuple as discussed in [RFC8939]. In particular, implementations of this document should support identification of DetNet flows based on the IPv6 Flow Label field.
ネイティブモードでは、プロトコルデータユニット（PDU）はトラックに対する一意に指すフロー依存メタデータに関連付けられているので、6tpサブライヤはあいまいさなしに適切なセルにフレームを配置することができる。IPv6トラフィックの場合、このフローは[RFC8939]で説明したように6タプルを使用して識別することができます。特に、この文書の実装は、IPv6 Flow Labelフィールドに基づくDetNetフローの識別をサポートする必要があります。
The flow follows a Track that is identified using a RPL Instance (see Section 3.1.3 of [RFC6550]), signaled in a RPL Packet Information (more in Section 11.2.2.1 of [RFC6550]) and the source address of a packet going down the DODAG formed by a local instance. One or more flows may be placed in a same Track and the Track identification (TrackID plus owner) may be placed in an IP-in-IP encapsulation. The forwarding operation is based on the Track and does not depend on the flow therein.
フローはRPLインスタンスを使用して識別されたトラックに従います（[RFC6550]のセクション3.1.3）、RPLパケット情報（[RFC6550]のセクション11.2.2.1）およびパケットの送信元アドレスを参照してください。ローカルインスタンスによって形成されたDODAGをダウンします。1つ以上のフローを同じトラックに配置し、トラック識別（TRACKIDプラス所有者）をIP IN-IPカプセル化に配置することができます。転送動作はトラックに基づいており、その中の流れには依存しない。
The Track identification is validated at egress before restoring the destination MAC address (DMAC) and punting to the upper layer.
トラック識別は、宛先MACアドレス（DMAC）を復元して上位層への句読点を復元する前に、出力時に検証されます。
Figure 11 illustrates the Track Forwarding operation that happens at the 6top sublayer, below IP.
図11は、IP以下の6倍の副層で発生するトラック転送操作を示しています。
| Packet flowing across the network ^
+--------------+ | |
| IPv6 | | |
+--------------+ | |
| 6LoWPAN HC | | |
+--------------+ ingress egress
| 6top | sets +----+ +----+ restores
+--------------+ DMAC to | | | | DMAC to
| TSCH MAC | brdcst | | | | dest
+--------------+ | | | | | |
| LLN PHY | +-------+ +--...-----+ +-------+
+--------------+
Ingress Relay Relay Egress
Stack Layer Node Node Node Node
Figure 11: Track Forwarding, Native Mode
図11：トラック転送、ネイティブモード
In tunnel mode, the frames originate from an arbitrary protocol over a compatible MAC that may or may not be synchronized with the 6TiSCH network. An example of this would be a router with a dual radio that is capable of receiving and sending WirelessHART or ISA100.11a frames with the second radio by presenting itself as an access point or a Backbone Router, respectively. In that mode, some entity (e.g., PCE) can coordinate with a WirelessHART Network Manager or an ISA100.11a System Manager to specify the flows that are transported.
トンネルモードでは、フレームは、6Tischネットワークと同期しても同期されていてもいなくてもよい互換性のあるMACを介して任意のプロトコルから発生します。この例は、それ自身をアクセスポイントまたはバックボーンルータとして表示することによって、2番目のラジオを持つ無線ハートまたはISA100.11aフレームを受信して送信することができるデュアルラジオを持つルーターです。そのモードでは、いくつかのエンティティ（例えば、PCE）は、転送されたフローを指定するために、WirelessHartネットワークマネージャまたはISA100.11aシステムマネージャと調整することができる。
+--------------+
| IPv6 |
+--------------+
| 6LoWPAN HC |
+--------------+ set restore
| 6top | +DMAC+ +DMAC+
+--------------+ to|brdcst to|nexthop
| TSCH MAC | | | | |
+--------------+ | | | |
| LLN PHY | +-------+ +--...-----+ +-------+
+--------------+ | ingress egress |
| |
+--------------+ | |
| LLN PHY | | |
+--------------+ | Packet flowing across the network |
| TSCH MAC | | |
+--------------+ | DMAC = | DMAC =
|ISA100/WiHART | | nexthop v nexthop
+--------------+
Source Ingress Egress Destination
Stack Layer Node Node Node Node
Figure 12: Track Forwarding, Tunnel Mode
図12：トラック転送、トンネルモード
In that case, the TrackID that identifies the Track at the ingress 6TiSCH router is derived from the RX-cell. The DMAC is set to this node, but the TrackID indicates that the frame must be tunneled over a particular Track, so the frame is not passed to the upper layer. Instead, the DMAC is forced to broadcast, and the frame is passed to the 6top sublayer for switching.
その場合、Ingress 6tischルータでトラックを識別するTRACSIDはRXセルから導出されます。DMACはこのノードに設定されていますが、TRACKIDはフレームが特定のトラックを介してトンネリングされなければならないことを示しているため、フレームは上位層に渡されません。代わりに、DMACはブロードキャストされ、フレームは切り替えのために6台のサブレイヤに渡されます。
At the egress 6TiSCH router, the reverse operation occurs. Based on tunneling information of the Track, which may for instance indicate that the tunneled datagram is an IP packet, the datagram is passed to the appropriate link-layer with the destination MAC restored.
出口6Tischルータでは、逆動作が発生します。例えば、トンネルデータグラムがIPパケットであることを示すトラックのトンネリング情報に基づいて、データグラムは復元された宛先MACで適切なリンク層に渡されます。
Tunneling information coming with the Track configuration provides the destination MAC address of the egress endpoint as well as the tunnel mode and specific data depending on the mode, for instance, a service access point for frame delivery at egress.
トンネリング情報トラック設定に到達すると、出力時のフレーム配信のためのサービスアクセスポイントがモードに応じて、出力エンドポイントの宛先MACアドレスと、モードに応じてトンネルモードと特定のデータを提供します。
If the tunnel egress point does not have a MAC address that matches the configuration, the Track installation fails.
トンネル出力ポイントに構成と一致するMACアドレスがない場合、トラックのインストールは失敗します。
If the Layer 3 destination address belongs to the tunnel termination, then it is possible that the IPv6 address of the destination is compressed at the 6LoWPAN sublayer based on the MAC address. Restoring the wrong MAC address at the egress would then also result in the wrong IP address in the packet after decompression. For that reason, a packet can be injected in a Track only if the destination MAC address is effectively that of the tunnel egress point. It is thus mandatory for the ingress router to validate that the MAC address used at the 6LoWPAN sublayer for compression matches that of the tunnel egress point before it overwrites it to broadcast. The 6top sublayer at the tunnel egress point reverts that operation to the MAC address obtained from the tunnel information.
レイヤ3の宛先アドレスがトンネル終了に属する場合、宛先のIPv6アドレスがMACアドレスに基づいて6LOWPANサブレイヤで圧縮される可能性があります。吐出時に間違ったMACアドレスを復元すると、解凍後のパケット内の間違ったIPアドレスも発生します。そのため、宛先MACアドレスがトンネル出力ポイントの効果的にインストールされている場合にのみ、パケットをトラックに注入することができる。したがって、入力ルータでは、6LOWPANサブレイヤで使用されるMACアドレスが、ブロードキャストに上書きされる前に、6LOWPANサブレイヤで使用されるMACアドレスがトンネル出力ポイントのそれと一致することを検証します。トンネル出力ポイントの6TTOPサブレイヤは、トンネル情報から取得したMACアドレスへの動作を元に戻します。
As the packets are routed at Layer 3, traditional QoS and Active Queue Management (AQM) operations are expected to prioritize flows.
パケットがレイヤ3でルーティングされると、従来のQoSとアクティブキュー管理（AQM）操作がフローに優先順位を付けられます。
| Packet flowing across the network ^
+--------------+ | |
| IPv6 | | +-QoS+ +-QoS+ |
+--------------+ | | | | | |
| 6LoWPAN HC | | | | | | |
+--------------+ | | | | | |
| 6top | | | | | | |
+--------------+ | | | | | |
| TSCH MAC | | | | | | |
+--------------+ | | | | | |
| LLN PHY | +-------+ +--...-----+ +-------+
+--------------+
Source Ingress Egress Destination
Stack Layer Node Router Router Node
Figure 13: IP Forwarding
図13：IP転送
Considering that, per Section 4 of [RFC4944], 6LoWPAN packets can be as large as 1280 bytes (the IPv6 minimum MTU) and that the non-storing mode of RPL implies source routing, which requires space for routing headers, and that an IEEE Std 802.15.4 frame with security may carry in the order of 80 bytes of effective payload, an IPv6 packet might be fragmented into more than 16 fragments at the 6LoWPAN sublayer.
[RFC4944]のセクション4によると、6lowpanパケットは1280バイト（IPv6最小MTU）と同じくらい大きく、RPLの非記憶モードはソースルーティングを意味します。STD 802.15.4セキュリティを持つフレームが80バイトの効果的なペイロードの順に持ち運ぶことができ、IPv6パケットは6LOWPANサブレイヤで16以上のフラグメントに断片化される可能性があります。
This level of fragmentation is much higher than that traditionally experienced over the Internet with IPv4 fragments, where fragmentation is already known as harmful.
このレベルのフラグメンテーションは、伝統的にIPv4フラグメントを介して経験したものよりもはるかに高く、断片化はすでに有害なものとして知られています。
In the case of a multihop route within a 6TiSCH network, hop-by-hop recomposition occurs at each hop to reform the packet and route it. This creates additional latency and forces intermediate nodes to store a portion of a packet for an undetermined time, thus impacting critical resources such as memory and battery.
6Tischネットワーク内のマルチホップルートの場合、ホップバイホップ再構成は各ホップでパケットを改善してルーティングする。これにより、追加の待ち時間が作成され、中間ノードがパケットの一部を未確定の時間の間に保存することを強制し、メモリやバッテリなどの重要なリソースに影響を与えます。
[RFC8930] describes a framework for forwarding fragments end-to-end across a 6TiSCH route-over mesh. Within that framework, [VIRTUAL-REASSEMBLY] details a virtual reassembly buffer mechanism whereby the datagram tag in the 6LoWPAN fragment is used as a label for switching at the 6LoWPAN sublayer.
[RFC8930]は、6Tischルートオーバーメッシュを介してフラグメントを終了するためのフレームワークを説明しています。そのフレームワーク内では、[Virtual-Reassembly]では、6LOWPANフラグメント内のデータグラムタグが6LOWPANサブレイヤで切り替えるためのラベルとして使用される仮想再構成バッファメカニズムを詳述します。
Building on this technique, [RFC8931] introduces a new format for 6LoWPAN fragments that enables the selective recovery of individual fragments and allows for a degree of flow control based on an Explicit Congestion Notification (ECN).
このテクニックの構築[RFC8931]は、個々のフラグメントの選択的回復を可能にし、明示的な輻輳通知（ECN）に基づく一度のフロー制御を可能にする6LOWPANフラグメントのための新しいフォーマットを紹介します。
| Packet flowing across the network ^
+--------------+ | |
| IPv6 | | +----+ +----+ |
+--------------+ | | | | | |
| 6LoWPAN HC | | learn learn |
+--------------+ | | | | | |
| 6top | | | | | | |
+--------------+ | | | | | |
| TSCH MAC | | | | | | |
+--------------+ | | | | | |
| LLN PHY | +-------+ +--...-----+ +-------+
+--------------+
Source Ingress Egress Destination
Stack Layer Node Router Router Node
Figure 14: Forwarding First Fragment
図14：最初のフラグメントの転送
In that model, the first fragment is routed based on the IPv6 header that is present in that fragment. The 6LoWPAN sublayer learns the next-hop selection, generates a new datagram tag for transmission to the next hop, and stores that information indexed by the incoming MAC address and datagram tag. The next fragments are then switched based on that stored state.
そのモデルでは、最初のフラグメントはそのフラグメント内に存在するIPv6ヘッダーに基づいてルーティングされます。6LOWPANサブレイヤはネクストホップ選択を学習し、次のホップへの送信のための新しいデータグラムタグを生成し、着信MACアドレスとデータグラムタグによって索引付けされた情報を格納します。次に、次のフラグメントはその記憶状態に基づいて切り替えられる。
| Packet flowing across the network ^
+--------------+ | |
| IPv6 | | |
+--------------+ | |
| 6LoWPAN HC | | replay replay |
+--------------+ | | | | | |
| 6top | | | | | | |
+--------------+ | | | | | |
| TSCH MAC | | | | | | |
+--------------+ | | | | | |
| LLN PHY | +-------+ +--...-----+ +-------+
+--------------+
Source Ingress Egress Destination
Stack Layer Node Router Router Node
Figure 15: Forwarding Next Fragment
図15：次のフラグメントの転送
A bitmap and an ECN echo in the end-to-end acknowledgment enable the source to resend the missing fragments selectively. The first fragment may be resent to carve a new path in case of a path failure. The ECN echo set indicates that the number of outstanding fragments should be reduced.
エンドツーエンドの確認応答のビットマップとECNエコーは、ソースが見つからないフラグメントを選択的に再送信できます。第1のフラグメントは、経路障害の場合に新しいパスを彫るために憤慨することがある。ECNエコーセットは、未解決のフラグメントの数を減らす必要があることを示します。
All packets inside a 6TiSCH domain must carry the RPLInstanceID that identifies the 6TiSCH topology (e.g., a Track) that is to be used for routing and forwarding that packet. The location of that information must be the same for all packets forwarded inside the domain.
6tischドメイン内のすべてのパケットは、そのパケットのルーティングと転送に使用される6tischトポロジ（たとえば、トラック）を識別するRPLINSTANCEIDを持ちます。その情報の場所は、ドメイン内で転送されたすべてのパケットで同じでなければなりません。
For packets that are routed by a PCE along a Track, the tuple formed by 1) (typically) the IPv6 source or (possibly) destination address in the IPv6 header and 2) a local RPLInstanceID in the RPI that serves as TrackID, identify uniquely the Track and associated transmit bundle.
トラックに沿ってPCEによってルーティングされたパケットの場合、IPv6ヘッダーのIPv6ソースまたは（おそらく）宛先アドレスが1）、2）TRACKIDとして機能するRPI内のローカルRPLINSTANCEIDを一意に識別します。トラックと関連送信バンドル。
For packets that are routed by RPL, that information is the RPLInstanceID that is carried in the RPL Packet Information (RPI), as discussed in Section 11.2 of [RFC6550], "Loop Avoidance and Detection". The RPI is transported by a RPL Option in the IPv6 Hop-By-Hop Options header [RFC6553].
RPLによってルーティングされたパケットの場合、その情報は[RFC6550]のセクション11.2で説明されているように、RPLパケット情報（RPI）で搭載されているRPLINSTANCEIDです。RPIは、IPv6ホップバイホップオプションヘッダ[RFC6553]のRPLオプションによって転送されます。
A compression mechanism for the RPL packet artifacts that integrates the compression of IP-in-IP encapsulation and the Routing Header type 3 [RFC6554] with that of the RPI in a 6LoWPAN dispatch/header type is specified in [RFC8025] and [RFC8138].
IP-In-IPカプセル化の圧縮を統合し、ルーティングヘッダータイプ3 [RFC6554]の圧縮機構は、[RFC8025]と[RFC8138]で指定されています。。
Either way, the method and format used for encoding the RPLInstanceID is generalized to all 6TiSCH topological Instances, which include both RPL Instances and Tracks.
どちらの方法でも、RPLINStanceIDをエンコードするために使用される方法とフォーマットは、RPLインスタンスとトラックの両方を含む6Tischトポロジインスタンスすべてに一般化されています。
6TiSCH supports the PREOF operations of elimination and reordering of packets along a complex Track, but has no requirement about tagging a sequence number in the packet for that purpose. With 6TiSCH, the schedule can tell when multiple receive timeslots correspond to copies of a same packet, in which case the receiver may avoid listening to the extra copies once it has received one instance of the packet.
6Tischは、複雑なトラックに沿ったパケットの除去および並べ替えの演算の動作をサポートしていますが、その目的のためにパケット内のシーケンス番号をタグ付けする必要はありません。6Tischでは、複数の受信タイムスロットが同じパケットのコピーに対応するときにスケジュールがわかります。その場合、受信側はパケットのインスタンスを1つ受け取った後に追加のコピーを聴くことを回避できます。
The semantics of the configuration enable correlated timeslots to be grouped for transmit (and receive, respectively) with 'OR' relations, and then an 'AND' relation can be configurable between groups. The semantics are such that if the transmit (and receive, respectively) operation succeeded in one timeslot in an 'OR' group, then all the other timeslots in the group are ignored. Now, if there are at least two groups, the 'AND' relation between the groups indicates that one operation must succeed in each of the groups.
構成のセマンティクスは、相関タイムスロットを、送信（それぞれ受信）または '関係を使用してグループ化され、次に'および '関係をグループ間で設定できるようにすることができます。セマンティクスは、送信（および受信）が 'または'グループの1タイムスロットに成功した場合、グループ内のすべての他のタイムスロットは無視されるようなものです。現在、少なくとも2つのグループがある場合、グループ間の 'および'の関係は、1つの操作が各グループで成功しなければならないことを示します。
On the transmit side, timeslots provisioned for retries along a same branch of a Track are placed in the same 'OR' group. The 'OR' relation indicates that if a transmission is acknowledged, then retransmissions of that packet should not be attempted for the remaining timeslots in that group. There are as many 'OR' groups as there are branches of the Track departing from this node. Different 'OR' groups are programmed for the purpose of replication, each group corresponding to one branch of the Track. The 'AND' relation between the groups indicates that transmission over any of branches must be attempted regardless of whether a transmission succeeded in another branch. It is also possible to place cells to different next-hop routers in the same 'OR' group. This allows routing along multipath Tracks, trying one next hop and then another only if sending to the first fails.
送信側では、トラックの同じ分岐に沿った再試行のためにプロビジョニングされたタイムスロットが同じ 'または'グループに配置されます。'または'関係は、伝送が確認された場合、そのパケットの再送信がそのグループ内の残りのタイムスロットに対して試行されるべきではありません。このノードから逸脱するトラックの枝があるので、多くのグループまたは 'グループがあります。異なる 'または'グループはレプリケーションの目的でプログラムされ、各グループはトラックの1つの分岐に対応しています。グループ間の 'および'の関係は、送信が別のブランチで成功したかどうかにかかわらず、任意のブランチに対する送信を試みる必要があることを示します。同じ 'または'グループ内の異なるネクストホップルータにセルを配置することも可能です。これにより、マルチパストラックに沿ってルーティングし、1つのネクストホップを試してから別の失敗に送信する場合にのみ、もう1つの場合は別のホップを実行できます。
On the receive side, all timeslots are programmed in the same 'OR' group. Retries of the same copy as well as converging branches for elimination are converged, meaning that the first successful reception is enough and that all the other timeslots can be ignored. An 'AND' group denotes different packets that must all be received and transmitted over the associated transmit groups within their respected 'AND' or 'OR' rules.
受信側では、すべてのタイムスロットは同じ 'または'グループにプログラムされています。同じコピーの再試行と除去のための収束分岐の再試行は収束します。つまり、最初の受信は十分であり、他のすべてのタイムスロットを無視できることを意味します。'および'グループは、すべてのルール内の関連する送信グループを介してすべての受信され、関連する送信グループを介して送信されなければならないさまざまなパケットを表します。
As an example, say that we have a simple network as represented in Figure 16, and we want to enable PREOF between an ingress node I and an egress node E.
一例として、図16に表されるように単純なネットワークを持っており、入口ノードiと出口ノードEの間にプリオフを有効にしたいとします。
+-+ +-+
-- |A| ------ |C| --
/ +-+ +-+ \
/ \
+-+ +-+
|I| |E|
+-+ +-+
\ /
\ +-+ +-+ /
-- |B| ------- |D| --
+-+ +-+
Figure 16: Scheduling PREOF on a Simple Network
図16：単純なネットワーク上のプリオフのスケジューリング
The assumption for this particular problem is that a 6TiSCH node has a single radio, so it cannot perform two receive and/or transmit operations at the same time, even on two different channels.
この特定の問題に対する仮定は、6Tischノードが単一の無線を有するので、2つの異なるチャネルでさえも、同時に2つの受信および/または送信動作を実行することができないことである。
Say we have six possible channels, and at least ten timeslots per slotframe. Figure 17 shows a possible schedule whereby each transmission is retried two or three times, and redundant copies are forwarded in parallel via A and C on the one hand, and B and D on the other, providing time diversity, spatial diversity though different physical paths, and frequency diversity.
私たちは6つの可能なチャンネル、そしてスロットフレームごとに少なくとも10タイムスロットを持っているとします。図17は、各送信が2~3回再試行され、冗長コピーがAおよびCを介して並行して並行して並行しており、他方ではBおよびDは、異なる物理的経路であるが時間多様性、空間ダイバーシティを提供する。、周波数ダイバーシティ。
slotOffset 0 1 2 3 4 5 6 7 9
+----+----+----+----+----+----+----+----+----+
channelOffset 0 | | | | | | |B->D| | | ...
+----+----+----+----+----+----+----+----+----+
channelOffset 1 | |I->A| |A->C|B->D| | | | | ...
+----+----+----+----+----+----+----+----+----+
channelOffset 2 |I->A| | |I->B| |C->E| |D->E| | ...
+----+----+----+----+----+----+----+----+----+
channelOffset 3 | | | | |A->C| | | | | ...
+----+----+----+----+----+----+----+----+----+
channelOffset 4 | | |I->B| | |B->D| | |D->E| ...
+----+----+----+----+----+----+----+----+----+
channelOffset 5 | | |A->C| | | |C->E| | | ...
+----+----+----+----+----+----+----+----+----+
Figure 17: Example Global Schedule
図17：グローバルスケジュールの例
This translates into a different slotframe that provides the waking and sleeping times for every node, and the channelOffset to be used when awake. Figure 18 shows the corresponding slotframe for node A.
これは、すべてのノードに対して目覚めと睡眠時間を提供する別のスロットフレームと、起動時に使用されるチャネルオフセットに変換されます。図18は、ノードAの対応するスロットフレームを示しています。
slotOffset 0 1 2 3 4 5 6 7 9
+----+----+----+----+----+----+----+----+----+
operation |rcv |rcv |xmit|xmit|xmit|none|none|none|none| ...
+----+----+----+----+----+----+----+----+----+
channelOffset | 2 | 1 | 5 | 1 | 3 |N/A |N/A |N/A |N/A | ...
+----+----+----+----+----+----+----+----+----+
Figure 18: Example Slotframe for Node A
図18：ノードAのスロットフレームの例
The logical relationship between the timeslots is given by Table 2:
タイムスロット間の論理的な関係は表2で与えられます。
+======+====================+=======================+
| Node | rcv slotOffset | xmit slotOffset |
+======+====================+=======================+
| I | N/A | (0 OR 1) AND (2 OR 3) |
+------+--------------------+-----------------------+
| A | (0 OR 1) | (2 OR 3 OR 4) |
+------+--------------------+-----------------------+
| B | (2 OR 3) | (4 OR 5 OR 6) |
+------+--------------------+-----------------------+
| C | (2 OR 3 OR 4) | (5 OR 6) |
+------+--------------------+-----------------------+
| D | (4 OR 5 OR 6) | (7 OR 8) |
+------+--------------------+-----------------------+
| E | (5 OR 6 OR 7 OR 8) | N/A |
+------+--------------------+-----------------------+
Table 2
表2.
This document has no IANA actions.
この文書にはIANAの行動がありません。
The "Minimal Security Framework for 6TiSCH" [RFC9031] was optimized for Low-Power and TSCH operations. The reader is encouraged to review the Security Considerations section of that document (Section 9), which discusses 6TiSCH security issues in more details.
「6Tischの最小セキュリティフレームワーク」[RFC9031]は、低電力およびTSCH操作のために最適化されました。読者はその文書のセキュリティ上の考察セクションを見直すことをお勧めします（セクション9）。
The operation of 6TiSCH Tracks inherits its high-level operation from DetNet and is subject to the observations in Section 5 of [RFC8655]. The installation and the maintenance of the 6TiSCH Tracks depend on the availability of a controller with a PCE to compute and push them in the network. When that connectivity is lost, existing Tracks may continue to operate until the end of their lifetime, but cannot be removed or updated, and new Tracks cannot be installed.
6tischトラックの動作はDetnetからの高レベル動作を継承し、[RFC8655]のセクション5の観測の対象となります。6tischトラックのインストールとメンテナンスは、ネットワーク内でそれらを計算してプッシュするためのPCEを備えたコントローラの可用性によって異なります。その接続が失われると、既存のトラックは存続期間が終了するまで動作し続けることができますが、削除または更新できず、新しいトラックをインストールできません。
In an LLN, the communication with a remote PCE may be slow and unreactive to rapid changes in the condition of the wireless communication. An attacker may introduce extra delay by selectively jamming some packets or some flows. The expectation is that the 6TiSCH Tracks enable enough redundancy to maintain the critical traffic in operation while new routes are calculated and programmed into the network.
LLNでは、リモートPCEとの通信は、無線通信の状態の急激な変化に対して遅くかつ未確実であり得る。攻撃者は、いくつかのパケットまたはフローを選択的に妨害することによって余分な遅延を導入することができる。期待は、6Tischトラックが、新しいルートが計算され、ネットワークにプログラムされている間に、稼働中の重要なトラフィックを維持するのに十分な冗長性を有効にすることです。
As with DetNet in general, the communication with the PCE must be secured and should be protected against DoS attacks, including delay injection and blackholing attacks, and secured as discussed in the security considerations defined for Abstraction and Control of Traffic Engineered Networks (ACTN) in Section 9 of [RFC8453], which applies equally to DetNet and 6TiSCH. In a similar manner, the communication with the JRC must be secured and should be protected against DoS attacks when possible.
Detnet一般に、PCEとの通信は保護されなければならず、遅延注入とブラックホール攻撃を含むDOS攻撃から保護されるべきであり、トラフィック計画ネットワーク（ACTN）の抽象化と制御に定義されたセキュリティ上の考慮事項で説明されているとおりに保護されるべきである。[RFC8453]の第9章で、Detnetと6tischに等しく適用されます。同様に、JRCとの通信は確保されなければならず、可能であればDOS攻撃に対して保護されるべきです。
The hopping sequence of a TSCH network is well known, meaning that if a rogue manages to identify a cell of a particular flow, then it may selectively jam that cell without impacting any other traffic. This attack can be performed at the PHY layer without any knowledge of the Layer 2 keys, and it is very hard to detect and diagnose because only one flow is impacted.
TSCHネットワークのホッピングシーケンスはよく知られており、不正が特定のフローのセルを識別するために管理されている場合、それは他のトラフィックに影響を与えることなくそのセルを選択的にジャムすることができることを意味する。この攻撃は、レイヤ2のキーの知識なしにPHYレイヤで実行でき、1つのフローのみが影響を受けるため、検出および診断が非常に困難です。
[ROBUST-SCHEDULING] proposes a method to obfuscate the hopping sequence and make it harder to perpetrate that particular attack.
[ロバストスケジューリング]ホッピングシーケンスを難読化し、その特定の攻撃を困難にする方法を提案しています。
This architecture operates on IEEE Std 802.15.4 and expects the link-layer security to be enabled at all times between connected devices, except for the very first step of the device join process, where a joining device may need some initial, unsecured exchanges so as to obtain its initial key material. In a typical deployment, all joined nodes use the same keys, and rekeying needs to be global.
このアーキテクチャはIEEE STD 802.15.4で動作し、接続デバイスの最初のステップを除いて、接続されているデバイス間のリンクレイヤセキュリティを常に有効にすることを期待しています。その初期鍵素材を入手する方法。一般的な展開では、すべての参加ノードは同じキーを使用し、Rekingingはグローバルになる必要があります。
The 6TISCH architecture relies on the join process to deny authorization of invalid nodes and to preserve the integrity of the network keys. A rogue that managed to access the network can perform a large variety of attacks from DoS to injecting forged packets and routing information. "Zero-trust" properties would be highly desirable but are mostly not available at the time of this writing. [RFC8928] is a notable exception that protects the ownership of IPv6 addresses and prevents a rogue node with L2 access from stealing and injecting traffic on behalf of a legitimate node.
6Tischアーキテクチャは、無効なノードの許可を拒否し、ネットワークキーの整合性を保つために結合プロセスに依存しています。ネットワークにアクセスすることができた不正なローグは、DOSから求められたパケットとルーティング情報を提供するために、さまざまな攻撃を実行できます。「ゼロ - 信頼」のプロパティは非常に望ましいであろうが、この書き込み時にはほとんど利用できない。[RFC8928] IPv6アドレスの所有権を保護し、R2アクセスを持つ不正なノードが正当なノードに代わって盗んで注入される不適切な例外です。
Time synchronization in TSCH induces another event horizon whereby a node will only communicate with another node if they are synchronized within a guard time. The pledge discovers the synchronization of the network based on the time of reception of the beacon. If an attacker synchronizes a pledge outside of the guard time of the legitimate nodes, then the pledge will never see a legitimate beacon and may not discover the attack.
TSCHの時間同期は、ノードが保護時間内に同期されている場合にのみ、ノードが別のノードと通信するだけである。誓約は、ビーコンの受信時に基づいてネットワークの同期を発見します。攻撃者が正当なノードのガードタイムの外側の誓約を同期させた場合、誓約は正当なビーコンを見ることはなく、攻撃を発見しない可能性があります。
As discussed in [RFC8655], measures must be taken to protect the time synchronization, and for 6TiSCH this includes ensuring that the Absolute Slot Number (ASN), which is the node's sense of time, is not compromised. Once installed and as long as the node is synchronized to the network, ASN is implicit in the transmissions.
[RFC8655]で説明したように、時間同期を保護するための対策を講じる必要があります。これは、ノードの時間感覚である絶対スロット数（ASN）が危険にさらされていないことを確認します。ノードがネットワークに同期されている限り、インストールされたら、ASNは送信に暗黙的です。
IEEE Std 802.15.4 [IEEE802154] specifies that in a TSCH network, the nonce that is used for the computation of the Message Integrity Code (MIC) to secure link-layer frames is composed of the address of the source of the frame and of the ASN. The standard assumes that the ASN is distributed securely by other means. The ASN is not passed explicitly in the data frames and does not constitute a complete anti-replay protection. As a result, upper-layer protocols must provide a way to detect duplicates and cope with them.
IEEE STD 802.15.4 [IEEE802154] TSCHネットワークでは、セキュアリンクレイヤフレームへのメッセージ整合性コード（MIC）の計算に使用されるノンスがフレームのソースのアドレスで構成されていることを指定します。ASN。規格は、ASNが他の手段によって安全に分散されていると仮定しています。ASNはデータフレームで明示的に渡されず、完全な再生防止保護を構成しません。その結果、上層プロトコルは、重複を検出してそれらに対処する方法を提供する必要があります。
If the receiver and the sender have a different sense of ASN, the MIC will not validate and the frame will be dropped. In that sense, TSCH induces an event horizon whereby only nodes that have a common sense of ASN can talk to one another in an authenticated manner. With 6TiSCH, the pledge discovers a tentative ASN in beacons from nodes that have already joined the network. But even if the beacon can be authenticated, the ASN cannot be trusted as it could be a replay by an attacker, announcing an ASN that represents a time in the past. If the pledge uses an ASN that is learned from a replayed beacon for an encrypted transmission, a nonce-reuse attack becomes possible, and the network keys may be compromised.
受信側と送信者がASNの意味が異なる場合、マイクは検証されず、フレームはドロップされます。その意味で、TSCHはイベント地平線を誘導し、それによって、ASNの共通の意味を持つノードだけが認証された方法で互いに話すことができます。6tischでは、誓約はすでにネットワークに参加しているノードからビーコン内の暫定的なASNを検出します。しかし、ビーコンを認証できる場合でも、過去の時間を表すASNを発表するASNを攻撃者によるリプレイである可能性があるため、ASNは信頼できません。誓約が、暗号化された送信のために再生されたビーコンから学習されたASNを使用している場合、非絶縁攻撃が可能になり、ネットワークキーが損なわれる可能性があります。
After obtaining the tentative ASN, a pledge that wishes to join the 6TiSCH network must use a join protocol to obtain its security keys. The join protocol used in 6TiSCH is the Constrained Join Protocol (CoJP). In the minimal setting defined in [RFC9031], the authentication requires a pre-shared key, based on which a secure session is derived. The CoJP exchange may also be preceded by a zero-touch handshake [ZEROTOUCH-JOIN] in order to enable pledge joining based on certificates and/or inter-domain communication.
暫定的なASNを取得した後、6Tischネットワークに参加したい誓約は、セキュリティキーを取得するために結合プロトコルを使用する必要があります。6tischで使用される結合プロトコルは、制約付き結合プロトコル（COJP）です。[RFC9031]で定義されている最小設定では、認証には事前共有キーが必要です。これに基づいて、セキュア・セッションが導出されます。COJP交換は、証明書および/またはドメイン間通信に基づいて誓約をすることを可能にするために、ゼロタッチハンドシェイク[ZEROTOCH-JOIN]を前提としている可能性があります。
As detailed in Section 4.2.1, a Join Proxy (JP) helps the pledge with the join procedure by relaying the link-scope Join Request over the IP network to a Join Registrar/Coordinator (JRC) that can authenticate the pledge and validate that it is attached to the appropriate network. As a result of the CoJP exchange, the pledge is in possession of link-layer material including keys and a short address, and if the ASN is known to be correct, all traffic can now be secured using CCM* [CCMstar] at the link layer.
セクション4.2.1で詳述されているように、結合プロキシ（JP）は、IPネットワークを介したリンクスコープ結合要求をIPネットワークを介して誓約レジストラ/コーディネータ（JRC）に中継することで、結合プロシージャーの誓約を支援し、誓約を認証して検証できる。適切なネットワークに接続されています。COJP交換の結果として、誓約はキーや短いアドレスを含むリンク層材料を所有しており、ASNが正しいことがわかっている場合は、リンクでCCM * [CCMSTAR]を使用してすべてのトラフィックを確保できるようになりました。層。
The authentication steps must be such that they cannot be replayed by an attacker, and they must not depend on the tentative ASN being valid. During the authentication, the keying material that the pledge obtains from the JRC does not provide protection against spoofed ASN. Once the pledge has obtained the keys to use in the network, it may still need to verify the ASN. If the nonce used in the Layer 2 security derives from the extended (MAC-64) address, then replaying the ASN alone cannot enable a nonce-reuse attack unless the same node has lost its state with a previous ASN. But if the nonce derives from the short address (e.g., assigned by the JRC), then the JRC must ensure that it never assigns short addresses that were already given to this or other nodes with the same keys. In other words, the network must be rekeyed before the JRC runs out of short addresses.
認証ステップは、攻撃者によって再生できないようなものでなければならず、それらは有効である暫定的なASNに依存してはいけません。認証中、誓約がJRCから取得するキーイングマテリアルは、偽装されたASNに対する保護を提供しません。PLEDDEがネットワークで使用するキーを取得したら、ASNを検証する必要がある可能性があります。レイヤ2のセキュリティで使用されていたNonceが拡張（MAC-64）アドレスから派生した場合、同じノードが前のASNでその状態を失っていない限り、ASNだけでは非再使用攻撃を有効にできません。しかし、Nonceが短いアドレス（例えばJRCによって割り当てられた）から派生した場合、JRCは、これが既にこのノードまたは他のノードに同じキーを持つ短いアドレスを割り当てないようにする必要があります。言い換えれば、JRCが短いアドレスを実行する前にネットワークを再認識する必要があります。
Section 4.2.1 provides an overview of the CoJP process described in [RFC9031] by which an LLN can be assembled in the field, having been provisioned in a lab. [ZEROTOUCH-JOIN] is future work that precedes and then leverages CoJP using the [CONSTRAINED-VOUCHER] constrained profile of [RFC8995]. This later work requires a yet-to-be standardized Lightweight Authenticated Key Exchange protocol.
セクション4.2.1には、LLNをフィールドに組み立てることができる[RFC9031]で説明されているCOJPプロセスの概要を示します。[Zerotouch-Join]は、[RFC8995]の[制約付きバウチャー]制約プロファイルを使用してCOJPの前後の将来の作業です。この後の作業には、まだ標準化された軽量認証鍵交換プロトコルが必要です。
CoJP results in distribution of a network-wide key that is to be used with [IEEE802154] security. The details of use are described in [RFC9031], Sections 9.2 and 9.3.2.
COJPの結果、[IEEE802154]セキュリティで使用されるネットワーク全体のキーが配布されます。使用の詳細は[RFC9031]、セクション9.2および9.3.2に記載されています。
The BRSKI mechanism may lead to the use of CoJP, in which case it also results in distribution of a network-wide key. Alternatively the BRSKI mechanism may be followed by use of [EST-COAPS] to enroll certificates for each device. In that case, the certificates may be used with an [IEEE802154] key agreement protocol. The description of this mechanism, while conceptually straightforward, still has significant standardization hurdles to pass.
BRSKIメカニズムはCOJPの使用につながる可能性があります。その場合、ネットワークワイドキーの分布も発生します。あるいは、各装置の証明書を登録するために、BRSKIメカニズムの後に[EST-COAP）を使用することができます。その場合、証明書は[IEEE802154]キー契約プロトコルと共に使用されます。このメカニズムの説明は、概念的に簡単に言えば、まだ合格にかなりの標準化ハードルを持っています。
Section 8.2 of [RFC9031] describes a mechanism to change (rekey) the network. There are a number of reasons to initiate a network rekey: to remove unwanted (corrupt/malicious) nodes, to recover unused 2-byte short addresses, or due to limits in encryption algorithms. For all of the mechanisms that distribute a network-wide key, rekeying is also needed on a periodic basis. In more detail:
[RFC9031]のセクション8.2では、ネットワークを変更（再確認）するメカニズムを示します。ネットワークリリースを開始するためのいくつかの理由がいくつかあります。不要な（破損/悪意のある）ノードを削除し、未使用の2バイトの短いアドレスを回復するため、または暗号化アルゴリズムの制限のためにリコードします。ネットワーク全体のキーを配布するすべてのメカニズムには、Rekingが定期的に必要です。さらに詳細に：
* The mechanism described in Section 8.2 of [RFC9031] requires advance communication between the JRC and every one of the nodes before the key change. Given that many nodes may be sleepy, this operation may take a significant amount of time and may consume a significant portion of the available bandwidth. As such, network-wide rekeys to exclude nodes that have become malicious will not be particularly quick. If a rekey is already in progress, but the unwanted node has not yet been updated, then it is possible to just continue the operation. If the unwanted node has already received the update, then the rekey operation will need to be restarted.
* [RFC9031]のセクション8.2に記載されているメカニズムには、鍵の変更前のJRCとすべてのノード間の前進通信が必要です。多くのノードが眠くてもよいことを考えると、この操作はかなりの時間をかけて利用可能な帯域幅のかなりの部分を消費する可能性があります。そのため、悪意のあるものになったノードを除外するためのネットワーク全体の再ロッシュは特に速くはありません。再生成がすでに進行中であるが、不要なノードがまだ更新されていない場合は、操作を継続することができます。不要なノードがすでに更新を受信している場合は、再起動操作を再起動する必要があります。
* The cryptographic mechanisms used by IEEE Std 802.15.4 include the 2-byte short address in the calculation of the context. A nonce-reuse attack may become feasible if a short address is reassigned to another node while the same network-wide keys are in operation. A network that gains and loses nodes on a regular basis is likely to reach the 65536 limit of the 2-byte (16-bit) short addresses, even if the network has only a few thousand nodes. Network planners should consider the need to rekey the network on a periodic basis in order to recover 2-byte addresses. The rekey can update the short addresses for active nodes if desired, but there is actually no need to do this as long as the key has been changed.
* IEEE STD 802.15.4によって使用される暗号化メカニズムには、コンテキストの計算における2バイトの短いアドレスが含まれています。同じネットワーク全体のキーが動作している間に、短いアドレスが別のノードに再割り当てされている場合、非リユース攻撃が実行可能になる可能性があります。ネットワークに数千ノードしかない場合でも、通常の基準でノードを増減するネットワークは、2バイト（16ビット）の短いアドレスの65536の制限に達する可能性があります。ネットワークプランナは、2バイトのアドレスを回復するために、ネットワークを定期的に再稼働させる必要があることを考慮する必要があります。必要に応じてアクティブノードの短いアドレスを更新できますが、キーが変更されている限り、実際にはこれを行う必要はありません。
* With TSCH as it stands at the time of this writing, the ASN will wrap after 2^40 timeslot durations, meaning around 350 years with the default values. Wrapping ASN is not expected to happen within the lifetime of most LLNs. Yet, should the ASN wrap, the network must be rekeyed to avoid a nonce-reuse attack.
* TSCHがこの書き込み時に立っているとおりに、ASNは2 ^ 40タイムスロットの期間の後にラップします。これはデフォルト値で350年前後です。ASNをラッピングすることは、ほとんどのLLNの存続期間内に起こるとは予想されません。それでも、ASNラップでは、ネットワークは、無使用攻撃を回避するために再確認されなければなりません。
* Many cipher algorithms have some suggested limits on how many bytes should be encrypted with that algorithm before a new key is used. These numbers are typically in the many to hundreds of gigabytes of data. On very fast backbone networks, this becomes an important concern. On LLNs with typical data rates in the kilobits/second, this concern is significantly less. With IEEE Std 802.15.4 as it stands at the time of this writing, the ASN will wrap before the limits of the current L2 crypto (AES-CCM-128) are reached, so the problem should never occur.
* 多くの暗号アルゴリズムには、新しいキーが使用される前にそのアルゴリズムで何バイトを暗号化するかについてのいくつかの推奨される制限があります。これらの数値は通常、数百のギガバイトのデータに含まれています。非常に高速バックボーンネットワークでは、これは重要な懸念になります。キロビットの典型的なデータレートを持つLLNでは、この懸念はかなり少ないです。この書き込み時に待機するにつれて、IEEE STD 802.15.4では、現在のL2 Crypto（AES-CCM-128）の制限が達成される前にASNがラップされるため、問題は発生しないはずです。
* In any fashion, if the LLN is expected to operate continuously for decades, then the operators are advised to plan for the need to rekey.
* いかなる方法でも、LLNが何十年もの間継続的に動作すると予想される場合、オペレータは再生成する必要性を計画するように勧告される。
Except for urgent rekeys caused by malicious nodes, the rekey operation described in [RFC9031] can be done as a background task and can be done incrementally. It is a make-before-break mechanism. The switch over to the new key is not signaled by time, but rather by observation that the new key is in use. As such, the update can take as long as needed, or occur in as short a time as practical.
悪意のあるノードによって引き起こされた緊急の再ロケを除いて、[RFC9031]で説明されているリリーキー操作は背景タスクとして行うことができ、徐々に行うことができます。それは行動前のメカニズムです。新しいキーへのスイッチオーバーは時間ごとにシグナリングされませんが、むしろ新しいキーが使用中の観察によって。このように、更新は必要に応じてかかるか、または実用的な時間的に短時間で行うことができる。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, <https://www.rfc-editor.org/info/rfc768>.
[RFC0768] Postel、J.、 "User Datagram Protocol"、STD 6、RFC 768、DOI 10.17487 / RFC0768、1980年8月、<https://www.rfc-editor.org/info/rfc768>。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, <https://www.rfc-editor.org/info/rfc4861>.
[RFC4861] Narten、T.、Nordmark、E.、Simpson、W.、およびH. Soliman、「IPバージョン6（IPv6）の隣接発見（IPv6）」、RFC 4861、DOI 10.17487 / RFC4861、2007年9月、<https：//www.rfc-editor.org/info/rfc4861>。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, <https://www.rfc-editor.org/info/rfc4862>.
[RFC4862] Thomson、S.、Narten、T.、T. Jinmei、「IPv6ステートレスアドレス自動設定」、RFC 4862、DOI 10.17487 / RFC4862、2007年9月、<https：//www.rfc-editor.org/info/ RFC4862>。
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, <https://www.rfc-editor.org/info/rfc4944>.
[RFC4944]モンテネグロ、G.、Kushalnagar、N.、Hui、J.、およびD.Culler、「IEEE 802.15.4ネットワーク上のIPv6パケットの送信」、RFC 4944、DOI 10.17487 / RFC4944、2007年9月、<https：//www.rfc-editor.org/info/rfc4944>。
[RFC5889] Baccelli, E., Ed. and M. Townsley, Ed., "IP Addressing Model in Ad Hoc Networks", RFC 5889, DOI 10.17487/RFC5889, September 2010, <https://www.rfc-editor.org/info/rfc5889>.
[RFC5889] Baccelli、E.、ED。M. Townsley、Ed。、「アドホックネットワークのIPアドレス指定モデル」、RFC 5889、DOI 10.17487 / RFC5889、2010年9月、<https://www.rfc-editor.org/info/rfc5889>。
[RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, DOI 10.17487/RFC6282, September 2011, <https://www.rfc-editor.org/info/rfc6282>.
[RFC6282] HUI、J.、ED。2011年9月、2011年9月、2011年9月、<https：//www.rfc-editor.org/info/rfc6282、<https：//www.rfc-editor.org/info/rfc6282>。
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, DOI 10.17487/RFC6550, March 2012, <https://www.rfc-editor.org/info/rfc6550>.
[RFC6550]冬、T.、ED。、Thubert、P.、Ed。、Brandt、A.、Hui、J.、Kelsey、R.、Levis、P.、Pister、K.、Struik、R.、Vasseur、JP。、およびR.RPL：低消費電力ネットワークの「RPL：IPv6ルーティングプロトコル」、RFC 6550、DOI 10.17487 / RFC6550、2012年3月、<https：//www.rfc-editor.org/info/RFC6550>。
[RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., and D. Barthel, "Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks", RFC 6551, DOI 10.17487/RFC6551, March 2012, <https://www.rfc-editor.org/info/rfc6551>.
[RFC6551] Vasseur、JP、Ed。、Kim、M.、Ed。、Pister、K.、Dejean、N.、D. Barthel、「低消費電力および非損失ネットワークにおける経路計算に使用されるルーティングメトリック」RFC 6551、DOI 10.17487 / RFC6551、2012年3月、<https：//www.rfc-editor.org/info/rfc6551>。
[RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing Protocol for Low-Power and Lossy Networks (RPL)", RFC 6552, DOI 10.17487/RFC6552, March 2012, <https://www.rfc-editor.org/info/rfc6552>.
[RFC6552] Thubert、P.、ED。、「低消費電力および非損失ネットワーク（RPL）」、RFC 6552、DOI 10.17487 / RFC6552、2012年3月、<https：///www.rfcのための客観的関数ゼロ-editor.org/info/rfc6552>。
[RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low-Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams", RFC 6553, DOI 10.17487/RFC6553, March 2012, <https://www.rfc-editor.org/info/rfc6553>.
[RFC6553] HUI、J.およびJP。「データプレーンデータグラム」、RFC 6553、DOI 10.17487 / RFC6553、2012年3月、<https：///www.rfc-editorのvasseur、 "RPL情報のためのルーティングプロトコル）。ORG / INFO / RFC6553>。
[RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL)", RFC 6554, DOI 10.17487/RFC6554, March 2012, <https://www.rfc-editor.org/info/rfc6554>.
[RFC6554] HUI、J.、Vasseur、JP、Culler、D.、およびV. Manral、「低電力および非損失ネットワーク（RPL）」（RPL） "、RFC 6554を備えたソースルート用のIPv6ルーティングヘッダー。DOI 10.17487 / RFC6554、2012年3月、<https：//www.rfc-editor.org/info/rfc6554>。
[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. Bormann, "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 6775, DOI 10.17487/RFC6775, November 2012, <https://www.rfc-editor.org/info/rfc6775>.
[RFC6775] Shelby、Z.、ED。、Chakrabarti、S.、Nordmark、E.、およびC. Bormann、「低電力無線パーソナルエリアネットワークにおけるIPv6の近隣探索最適化（6lowpans）」、RFC 6775、DOI 10.17487/ RFC6775、2012年11月、<https：//www.rfc-editor.org/info/rfc6775>。
[RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 2014, <https://www.rfc-editor.org/info/rfc7102>.
[RFC7102] Vasseur、JP。、「低電力および非損失ネットワークのためのルーティングで使用される用語」、RFC 7102、DOI 10.17487 / RFC7102、2014年1月、<https：//www.rfc-editor.org/info/rfc7102>。
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014, <https://www.rfc-editor.org/info/rfc7228>.
[RFC7228] Bormann、C.、Eresut、M.およびA.ケラネン、「拘束ノードネットワークのための用語」、RFC 7228、DOI 10.17487 / RFC 7228、2014年5月、<https：//www.rfc-editor.org/ info / rfc7228>。
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, <https://www.rfc-editor.org/info/rfc7252>.
[RFC7252] Shelby、Z.、Hartke、K.、C. Bormann、「制約付きアプリケーションプロトコル（CoAP）」、RFC 7252、DOI 10.17487 / RFC7252、2014年6月、<https：//www.rfc-編集者。ORG / INFO / RFC7252>。
[RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the Internet of Things (IoT): Problem Statement", RFC 7554, DOI 10.17487/RFC7554, May 2015, <https://www.rfc-editor.org/info/rfc7554>.
[RFC7554] Watteyne、T.、ED。、Palattella、M.、およびL.Grieco、「IEEE 802.15.4Eタイムスロットチャンネルホッピング（TSCH）（IoT）：問題声明 "、RFC 7554、DOI 10.17487 / RFC7554、2015年5月、<https://www.rfc-editor.org/info/rfc7554>。
[RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Paging Dispatch", RFC 8025, DOI 10.17487/RFC8025, November 2016, <https://www.rfc-editor.org/info/rfc8025>.
[RFC8025] Thubert、P.、ED。そしてR. Cragie、「低電力無線パーソナルエリアネットワーク（6lowpan）ページングディスパッチ」、RFC 8025、DOI 10.17487 / RFC8025、2016年11月、<https：//www.rfc-editor.org/info/rfc8025>。
[RFC8137] Kivinen, T. and P. Kinney, "IEEE 802.15.4 Information Element for the IETF", RFC 8137, DOI 10.17487/RFC8137, May 2017, <https://www.rfc-editor.org/info/rfc8137>.
[RFC8137] Kivinen、T.およびP. Kinney、「IEEE 802.15.4 IETFのIEEE 802.15.4情報要素」、RFC 8137、DOI 10.17487 / RFC8137、2017年5月、<https：//www.rfc-editor.org/info/RFC8137>。
[RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, "IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, April 2017, <https://www.rfc-editor.org/info/rfc8138>.
[RFC8138] Thubert、P.、ED。、Bormann、C、Toutain、L.、R. Cragie、R.Cragie、「低電力無線パーソナルエリアネットワーク（6LOWPAN）ルーティングヘッダ」、RFC 8138、DOI 10.17487 / RFC8138、2017年4月、<https://www.rfc-editor.org/info/rfc8138>。
[RFC8180] Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180, May 2017, <https://www.rfc-editor.org/info/rfc8180>.
[RFC8180] Vilajosana、X.、ED。、Pister、K.、およびT.Watteyne、「IEEE 802.15.4EのTSCHモードでの最小IPv6（6tisch）構成」、BCP 210、RFC 8180、DOI 10.17487 / RFC8180、2017年5月、<https：//www.rfc-editor.org/info/rfc8180>。
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>.
[RFC8200] The'th、S.およびR.hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、STD 86、RFC 8200、DOI 10.17487 / RFC8200、2017年7月、<https：//www.rfc-editor.org/ info / rfc8200>。
[RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for Abstraction and Control of TE Networks (ACTN)", RFC 8453, DOI 10.17487/RFC8453, August 2018, <https://www.rfc-editor.org/info/rfc8453>.
[RFC8453] Ceccarelli、D.、ED。そして、「TEネットワーク（ACTN）の抽象化と管理のためのフレームワーク（ACTN）」、RFC 8453、DOI 10.17487 / RFC8453、2018年8月、<https：//www.rfc-editor.org/info/rfc8453>。
[RFC8480] Wang, Q., Ed., Vilajosana, X., and T. Watteyne, "6TiSCH Operation Sublayer (6top) Protocol (6P)", RFC 8480, DOI 10.17487/RFC8480, November 2018, <https://www.rfc-editor.org/info/rfc8480>.
[RFC8480] Wang、Q.、ED。、Vilajosana、X.、およびT.Watteyne、 "6tisch操作サブレイヤ（6P）プロトコル（6P）"、RFC 8480、DOI 10.17487 / RFC8480、2018年11月、<https：//www.rfc-editor.org/info/rfc8480>。
[RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. Perkins, "Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, <https://www.rfc-editor.org/info/rfc8505>.
[RFC8505] Thubert、P.、Ed。、Nordmark、E.、Chakrabarti、S.およびPerkins、「低電力無線パーソナルエリアネットワーク（6lowpan）隣接ディスカバリーに関するIPv6の登録拡張」、RFC 8505、DOI10.17487 / RFC8505、2018年11月、<https：//www.rfc-editor.org/info/rfc8505>。
[RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, "Deterministic Networking Architecture", RFC 8655, DOI 10.17487/RFC8655, October 2019, <https://www.rfc-editor.org/info/rfc8655>.
[RFC8655] Finn、N.、Thubert、P.、Varga、B.、およびJ. Farkas、「決定論的ネットワーキングアーキテクチャ」、RFC 8655、DOI 10.17487 / RFC8655、2019年10月、<https：//www.rfc-編集者.org / info / rfc8655>。
[RFC8928] Thubert, P., Ed., Sarikaya, B., Sethi, M., and R. Struik, "Address-Protected Neighbor Discovery for Low-Power and Lossy Networks", RFC 8928, DOI 10.17487/RFC8928, November 2020, <https://www.rfc-editor.org/info/rfc8928>.
[RFC8928] Thubert、P.、Ed。、Sarikaya、B.、Sethi、M.、R. Struik、「低消費電力損失ネットワークのためのアドレス保護隣接発見」、RFC 8928、DOI 10.17487 / RFC8928、11月2020、<https://www.rfc-editor.org/info/rfc8928>。
[RFC8929] Thubert, P., Ed., Perkins, C.E., and E. Levy-Abegnoli, "IPv6 Backbone Router", RFC 8929, DOI 10.17487/RFC8929, November 2020, <https://www.rfc-editor.org/info/rfc8929>.
[RFC8929] Thubert、P.、Ed。、Perkins、CE、E. Levy-Abngingoli、「IPv6 Backbone Router」、RFC 8929、DOI 10.17487 / RFC8929、2020年11月、<https：//www.rfc-編集者。ORG / INFO / RFC8929>。
[RFC8930] Watteyne, T., Ed., Thubert, P., Ed., and C. Bormann, "On Forwarding 6LoWPAN Fragments over a Multi-Hop IPv6 Network", RFC 8930, DOI 10.17487/RFC8930, November 2020, <https://www.rfc-editor.org/info/rfc8930>.
[RFC8930] Watteyne、T.、Ed。、Thubert、P.、Ed。、およびC. Bormann、「マルチホップIPv6ネットワーク上の6lowpanフラグメントの際の6lowpanフラグメント」、RFC 8930、DOI 10.17487 / RFC8930、2020年11月、<https://www.rfc-editor.org/info/rfc8930>。
[RFC8931] Thubert, P., Ed., "IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Selective Fragment Recovery", RFC 8931, DOI 10.17487/RFC8931, November 2020, <https://www.rfc-editor.org/info/rfc8931>.
[RFC8931] Thubert、P.、ED。、「低消費電力無線パーソナルエリアネットワーク（6lowpan）選択フラグメントリカバリの「IPv6」、RFC 8931、DOI 10.17487 / RFC8931、2020年11月、<https：///www.rfc-編集者.ORG / INFO / RFC8931>。
[RFC9008] Robles, M.I., Richardson, M., and P. Thubert, "Using RPI Option Type, Routing Header for Source Routes, and IPv6- in-IPv6 Encapsulation in the RPL Data Plane", RFC 9008, DOI 10.17487/RFC9008, April 2021, <https://www.rfc-editor.org/info/rfc9008>.
[RFC9008] ROBLES、MI、Richardson、M.、およびP.Thubert、「RPIオプションタイプの使用、ソースルートのルーティングヘッダー、RPLデータプレーンにおけるIPv6-in-IPv6カプセル化」、RFC 9008、DOI 10.17487 / RFC9008、2021年4月、<https：//www.rfc-editor.org/info/rfc9008>。
[RFC9010] Thubert, P., Ed. and M. Richardson, "Routing for RPL (Routing Protocol for Low-Power and Lossy Networks) Leaves", RFC 9010, DOI 10.17487/RFC9010, April 2021, <https://www.rfc-editor.org/info/rfc9010>.
[RFC9010] Thubert、P、ED。M. RiChardson「RPLのルーティング（低消費電力ネットワークのためのルーティングプロトコル）葉」、RFC 9010、DOI 10.17487 / RFC9010、2021年4月、<https://www.rfc-editor.org/info/rfc9010>。
[RFC9031] Vučinić, M., Ed., Simon, J., Pister, K., and M. Richardson, "Constrained Join Protocol (CoJP) for 6TiSCH", RFC 9031, DOI 10.17487/RFC9031, May 2021, <https://www.rfc-editor.org/info/rfc9031>.
[RFC9031]Vužinić、M.、Ed。、Simon、J.、Pister、K.、およびM.リチャードソン、「6Tischの拘束結合プロトコル（COJP）」、RFC 9031、DOI 10.17487 / RFC9031、2021年5月、<HTTPS//www.rfc-editor.org/info/rfc9031>。
[RFC9032] Dujovne, D., Ed. and M. Richardson, "Encapsulation of 6TiSCH Join and Enrollment Information Elements", RFC 9032, DOI 10.17487/RFC9032, May 2021, <https://www.rfc-editor.org/info/rfc9032>.
[RFC9032] Dujovne、D.、ED。M.リチャードソン、「6tisch結合と登録情報要素のカプセル化」、RFC 9032、DOI 10.17487 / RFC9032、2021年5月、<https://www.rfc-editor.org/info/rfc9032>。
[RFC9033] Chang, T., Ed., Vučinić, M., Vilajosana, X., Duquennoy, S., and D. Dujovne, "6TiSCH Minimal Scheduling Function (MSF)", RFC 9033, DOI 10.17487/RFC9033, May 2021, <https://www.rfc-editor.org/info/rfc9033>.
[RFC9033] Chang、T.、Ed。、Vužinić、M.、Vilajosana、X.、Duquennoy、S.、D.Dujovne、 "6tisch最小スケジューリング機能（MSF）"、RFC 9033、DOI 10.17487 / RFC9033、2021、<https://www.rfc-editor.org/info/rfc9033>。
[AMI] U.S. Department of Energy, "Advanced Metering Infrastructure and Customer Systems", 2006, <https://www.energy.gov/sites/prod/files/2016/12/f34/ AMI%20Summary%20Report_09-26-16.pdf>.
[AMI]米国エネルギー省「高度計量インフラストラクチャーおよびカスタマーシステム」、2006年、<https://www.energy.gov/sits/prod/files/2016/12/F34/ AMI％20Summary％20report_09-26-16.pdf>。
[ANIMA] IETF, "Autonomic Networking Integrated Model and Approach (anima)", <https://datatracker.ietf.org/doc/charter-ietf-anima/>.
[ANIMA] IETF、「自律ネットワーキング統合モデルとアプローチ（anima）」、<https://datatracker.ietf.org/doc/charter-ietf-anima/>。
[AODV-RPL] Anamalamudi, S., Zhang, M., Perkins, C. E., Anand, S., and B. Liu, "Supporting Asymmetric Links in Low Power Networks: AODV-RPL", Work in Progress, Internet-Draft, draft-ietf-roll-aodv-rpl-10, 4 April 2021, <https://tools.ietf.org/html/draft-ietf-roll-aodv-rpl-10>.
[AODV-RPL]アナマラムディ、S、Zhang、M.、Perkins、CE、ANAND、S.、B。LIU、「低電力ネットワークにおける非対称リンク：AODV-RPL」、進行中の作業、インターネットドラフト、ドラフト-IETF-ROLL-AODV-RPL-10,4 4月4日、<https://tools.ietf.org/html/draft-ietf-roll-aodv-rpl-10>。
[AODVv2] Perkins, C. E., Ratliff, S., Dowdell, J., Steenbrink, L., and V. Mercieca, "Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing", Work in Progress, Internet-Draft, draft-ietf-manet-aodvv2-16, 4 May 2016, <https://tools.ietf.org/html/draft-ietf-manet-aodvv2-16>.
[AODVV2] Perkins、CE、Ratliff、S.、Dowdell、J.、Steenbrink、L.、およびV.Mercieca、「アドホックオンデマンド距離ベクトルバージョン2（AODVV2）ルーティング」、進行中の作業、インターネットドラフト、ドラフトIETF-MANET-AODVV2-16,2016、<https：//tools.ietf.org/html/draft-ietf-manet-aodvv2-16>。
[BITSTRINGS-6LORH] Thubert, P., Ed., Brodard, Z., Jiang, H., and G. Texier, "A 6loRH for BitStrings", Work in Progress, Internet-Draft, draft-thubert-6lo-bier-dispatch-06, 28 January 2019, <https://tools.ietf.org/html/draft-thubert-6lo-bier-dispatch-06>.
[Bitstrings-6lllh] Thubert、P.、ED、Brodard、Z.、Jiang、H.、およびG. Texier、「Bitstrings for Bitstrings for Bitstrings」、進行中の作業、インターネットドラフト、ドラフトThubert-6lo-Bier-dispatch-06,2019、<https：//tools.ietf.org/html/draft-thubert-6lo-bier-dispatch-06>
[CCAMP] IETF, "Common Control and Measurement Plane (ccamp)", <https://datatracker.ietf.org/doc/charter-ietf-ccamp/>.
[CCAMP] IETF、「共通制御と測定プレーン（CCAMP）」、<https://datatracker.ietf.org/doc/charter-ietf-ccamp/>。
[CCMstar] Struik, R., "Formal Specification of the CCM* Mode of Operation", September 2004, <http://www.ieee802.org/15/ pub/2004/15-04-0537-00-004b-formal-specification-ccm-star-mode-operation.doc>.
[CCMSTAR] Struik、R.、「CCM *操作モードの正式な仕様」、2004年9月、<http://www.ieee802.org/15/ pub / 2004/05-04-0537-00-00-004B-正式仕様-CCM-STAR-MODE-OPERY.DOC>。
[CONSTRAINED-VOUCHER] Richardson, M., van der Stok, P., and P. Kampanakis, "Constrained Voucher Artifacts for Bootstrapping Protocols", Work in Progress, Internet-Draft, draft-ietf-anima-constrained-voucher-10, 21 February 2021, <https://tools.ietf.org/html/draft-ietf-anima-constrained-voucher-10>.
[制約付きバウチャー] Richardson、M.、Van Der Stok、P.、およびP. Kampanakis、「ブートストラッププロトコルのための制約付きバウチャーアーティファクト」、進行中の作業、インターネットドラフト、ドラフト-IETF-ANIMA制約付きバウチャー-10、2021年2月21日、<https://tools.ietf.org/html/draft-ietf-anima-constrained-voucher-10>。
[DAO-PROJECTION] Thubert, P., Jadhav, R. A., and M. Gillmore, "Root initiated routing state in RPL", Work in Progress, Internet-Draft, draft-ietf-roll-dao-projection-16, 15 January 2021, <https://tools.ietf.org/html/draft-ietf-roll-dao-projection-16>.
[Dao-Projection] Thubert、P.、Jadhav、RA、およびM.ギルモア、「RPLのルート開始ルーティング状態」、進行中の作業、インターネットドラフト、ドラフト - IETF-ROLL-DAO-PROOGEN-PROJECT-16,152021、<https://tools.ietf.org/html/draft-ietf-roll-dao-projection-16>。
[EDHOC] Selander, G., Mattsson, J., and F. Palombini, "Ephemeral Diffie-Hellman Over COSE (EDHOC)", Work in Progress, Internet-Draft, draft-selander-ace-cose-ecdhe-14, 11 September 2019, <https://tools.ietf.org/html/draft-selander-ace-cose-ecdhe-14>.
[EDHOC] Selander、G.、Mattsson、J.、およびF. Palombini、 "Ephemeral Diffie-Hellman over cose（eshoc）"、進行中、インターネットドラフト、ドラフトセラルダーエース - COSE-ECDHE-14、2019年9月11日、<https://tools.ietf.org/html/draft-selander-acose-cose-ecdhe--14>。
[EST-COAPS] van der Stok, P., Kampanakis, P., Richardson, M., and S. Raza, "EST over secure CoAP (EST-coaps)", Work in Progress, Internet-Draft, draft-ietf-ace-coap-est-18, 6 January 2020, <https://tools.ietf.org/html/draft-ietf-ace-coap-est-18>.
[Est-Coaps]ファンデルストーク、P.、カンパナキス、P.、Richardson、M.、およびS. Raza、「安全なCOAAS（EST-COAPS）」、進行中の作業、インターネットドラフト、ドラフトIETF-ACE-COAP-EST-18,2020年1月6日、<https://tools.ietf.org/html/draft-ietf-ace-coap-est-18>。
[HART] FieldComm Group, "HART", <https://fieldcommgroup.org/technologies/hart>.
[HART] FieldCommグループ、 "HART"、<https://fieldcommgroup.org/technologies/hart>。
[IEC62439] IEC, "Industrial communication networks - High availability automation networks - Part 3: Parallel Redundancy Protocol (PRP) and High-availability Seamless Redundancy (HSR)", IEC 62439-3:2016, 2016, <https://webstore.iec.ch/publication/24438>.
[IEC62439] IEC、「産業通信ネットワーク - 高可用性自動化ネットワーク - 第3部：並列冗長プロトコル（PRP）と高可用性のシームレスな冗長性（HSR）」、IEC 62439-3：2016,2016、<https：// webstore.iec.ch / publication / 24438>。
[IEEE802154] IEEE, "IEEE Standard for Low-Rate Wireless Networks", IEEE Standard 802.15.4-2015, DOI 10.1109/IEEESTD.2016.7460875, April 2016, <https://ieeexplore.ieee.org/document/7460875>.
[IEEE802154] IEEE、「低速無線ネットワークのためのIEEE規格」、IEEE規格802.15.4-2015、DOI 10.1109 / IEEESTD.2016.7460875、<https：//ieeexplore.ieee.org/document/7460875>。
[IEEE802154e] IEEE, "IEEE Standard for Local and metropolitan area networks -- Part. 15.4: Low-Rate Wireless Personal Area Networks (LR-WPANs) Amendment 1: MAC sublayer", IEEE Standard 802.15.4e-2012, DOI 10.1109/IEEESTD.2012.6185525, April 2012, <https://ieeexplore.ieee.org/document/6185525>.
[IEEE802154E] IEEE、「地域と首都圏の地域ネットワークのIEEE規格」。IEEESTD.2012.6185525、2012年4月、<https：//ieeexplore.ieee.org/document/6185525>。
[ISA100] ISA/ANSI, "ISA100, Wireless Systems for Automation", <https://www.isa.org/isa100/>.
【ISA100】ISA / ANSI、「ISA100、オートメーション用無線システム」、<https：//www.isa.org/isa100/>。
[ISA100.11a] ISA/ANSI, "Wireless Systems for Industrial Automation: Process Control and Related Applications - ISA100.11a-2011", IEC 62734:2014, 2011, <https://webstore.iec.ch/publication/65581>.
[ISA100.11A] ISA / ANSI、「産業用オートメーション用無線システム：プロセス制御および関連アプリケーション - ISA100.11A-2011」、IEC 62734：2014,2011、<https://webstore.iec.ch/publication/65581>。
[ND-UNICAST-LOOKUP] Thubert, P., Ed. and E. Levy-Abegnoli, "IPv6 Neighbor Discovery Unicast Lookup", Work in Progress, Internet-Draft, draft-thubert-6man-unicast-lookup-00, 29 July 2019, <https://tools.ietf.org/html/draft-thubert-6man-unicast-lookup-00>.
[ND-Unicast-Lookup] Thubert、P.、ED。そしてE. Levy-Abngholi、「IPv6隣接ディスカバリーユニキャストルックアップ」、進行中の作業、インターネットドラフト、ドラフトThubert-6man-unicast-lookup-00,29、<https：//tools.ietf.org/html / draft-thubert-6man-unicast-lookup-00>。
[PCE] IETF, "Path Computation Element (pce)", <https://datatracker.ietf.org/doc/charter-ietf-pce/>.
[PCE] IETF、「パス計算要素（PCE）」、<https://datatracker.ietf.org/doc/charter-ietf-pce/>。
[RAW-ARCHITECTURE] Thubert, P., Ed. and G. Z. Papadopoulos, "Reliable and Available Wireless Problem Statement", Work in Progress, Internet-Draft, draft-pthubert-raw-architecture-05, 15 November 2020, <https://tools.ietf.org/html/draft-pthubert-raw-architecture-05>.
[Raw-Architecture] Thubert、P.、ED。そしてGZ Papadopoulos、「信頼できる無線問題声明」、進行中の作業、インターネットドラフト、ドラフト - Pthubert-Raw-Architecture-05,15、<https：//tools.ietf.org/html/draft-Pthubert-Raw-Architecture-05>。
[RAW-USE-CASES] Papadopoulos, G. Z., Thubert, P., Theoleyre, F., and C. J. Bernardos, "RAW use cases", Work in Progress, Internet-Draft, draft-ietf-raw-use-cases-01, 21 February 2021, <https://tools.ietf.org/html/draft-ietf-raw-use-cases-01>.
[生のユースケース] Papadopoulos、GZ、Thubert、P.、Theoleyre、F.、およびCJ Bernardos、「生のユースケース」、進行中の作業、インターネットドラフト、ドラフト-IETF-RAW-USE-JPE-01、2021年2月21日、<https://tools.ietf.org/html/draft-ietf-raw-use-cases-01>。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, <https://www.rfc-editor.org/info/rfc2474>.
[RFC2474] Nichols、K.、Blake、S.、Baker、F.、およびD.黒、「IPv4およびIPv6ヘッダーのDSフィールドの定義」、RFC 2474、DOI 10.17487 / RFC2474、1998年12月、<https：//www.rfc-editor.org/info/rfc2474>。
[RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing", RFC 2545, DOI 10.17487/RFC2545, March 1999, <https://www.rfc-editor.org/info/rfc2545>.
[RFC2545] Marques、P.およびF.Dupont、「IPv6ドメイン間ルーティング用のBGP-4マルチプロトコル拡張の使用」、RFC 2545、DOI 10.17487 / RFC2545、1999年3月、<https：//www.rfc-編集者。ORG / INFO / RFC2545>。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, <https://www.rfc-editor.org/info/rfc3209>.
[RFC3209] awduche、D.、Berger、L.、GaN、D.、Li、T.、Srinivasan、V.、G.Svp-Te：LSPトンネルのRSVPへの拡張機能、RFC 3209、DOI10.17487 / RFC3209、2001年12月、<https：//www.rfc-editor.org/info/rfc3209>。
[RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between Information Models and Data Models", RFC 3444, DOI 10.17487/RFC3444, January 2003, <https://www.rfc-editor.org/info/rfc3444>.
[RFC3444] PRAS、A.およびJ.Schoenwaelder、「情報モデルとデータモデルの違い」、RFC 3444、DOI 10.17487 / RFC3444、2003年1月、<https：//www.rfc-editor.org/info/RFC3444>。
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, DOI 10.17487/RFC3963, January 2005, <https://www.rfc-editor.org/info/rfc3963>.
[RFC3963] Devarapalli、V.、Wakikawa、R.、Petrescu、A.、およびP.Thubert、 "ネットワークモビリティ（NEMO）基本サポートプロトコル"、RFC 3963、DOI 10.17487 / RFC3963、2005年1月、<https：//www.rfc-editor.org/info/rfc3963>。
[RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080, DOI 10.17487/RFC4080, June 2005, <https://www.rfc-editor.org/info/rfc4080>.
[RFC4080]ハンコック、R.、Karagiannis、G.、Loughney、J.、およびS. van Den Bosch、「シグナリング（NSIS（NSIS）：Framework」、RFC 4080、DOI 10.17487 / RFC4080、2005年6月、<HTTPS///www.rfc-editor.org/info/rfc4080>。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC4291] Hinden、R.およびS.Theering、 "IPバージョン6アドレッシングアーキテクチャ"、RFC 4291、DOI 10.17487 / RFC4291、2006年2月、<https：//www.rfc-editor.org/info/rfc4291>。
[RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, DOI 10.17487/RFC4903, June 2007, <https://www.rfc-editor.org/info/rfc4903>.
[RFC4903] Thaler、D.、「マルチリンクサブネットの問題」、RFC 4903、DOI 10.17487 / RFC4903、2007年6月、<https：//www.rfc-editor.org/info/rfc4903>。
[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals", RFC 4919, DOI 10.17487/RFC4919, August 2007, <https://www.rfc-editor.org/info/rfc4919>.
[RFC4919] Kushalnagar、N.、Montenegro、G.、Schumacher、C. Schumacher、「低電力無線パーソナルエリアネットワーク（6lowpans）：概要、仮定、問題ステートメント、および目標、RFC 4919、DOI 10.17487 / RFC49192007年8月、<https：//www.rfc-editor.org/info/rfc4919>。
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, <https://www.rfc-editor.org/info/rfc5340>.
[RFC5340] Coltun、R.、Ferguson、D.、Moy、J.、およびA. Lindem、RFC 5340、DOI 10.17487 / RFC5340、2008年7月、<https：///www.rfc-編集者.org / info / rfc5340>。
[RFC5974] Manner, J., Karagiannis, G., and A. McDonald, "NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling", RFC 5974, DOI 10.17487/RFC5974, October 2010, <https://www.rfc-editor.org/info/rfc5974>.
[RFC5974] MAY、J.、Karagiannis、G.、およびA.McDonald、「サービス品質シグナリング用NSIシグナリング層プロトコル（NSLP）」、RFC 5974、DOI 10.17487 / RFC5974、2010年10月、<https：//www.rfc-editor.org/info/rfc5974>。
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 2011, <https://www.rfc-editor.org/info/rfc6275>.
[RFC6275] Perkins、C、Ed。、Johnson、D.、およびJ.Arkko、「IPv6のモビリティサポート」、RFC 6275、DOI 10.17487 / RFC6275、2011年7月、<https：///www.rfc-編集者。ORG / INFO / RFC6275>。
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6347] RESCORLA、E.およびN. MODADUGU、「データグラムトランスポートレイヤセキュリティバージョン1.2」、RFC 6347、DOI 10.17487 / RFC6347、2012年1月、<https：//www.rfc-editor.org/info/rfc6347>。
[RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem Statement and Requirements for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing", RFC 6606, DOI 10.17487/RFC6606, May 2012, <https://www.rfc-editor.org/info/rfc6606>.
[RFC6606] KIM、E.、KASPAR、D.、Gomez、C、およびC. Bormann、「低電力無線パーソナルエリアネットワーク（6LOWPAN）ルーティングにおけるIPv6の要件」、RFC 6606、DOI 10.17487 /rfc6606、2012年5月、<https://www.rfc-editor.org/info/rfc6606>。
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, DOI 10.17487/RFC6830, January 2013, <https://www.rfc-editor.org/info/rfc6830>.
[RFC6830] Farinacci、D.、Fuller、V.、Meyer、D.、およびD.Lewis、「Locator / ID分離プロトコル（Lisp）」、RFC 6830、DOI 10.17487 / RFC6830、2013年1月、<https：//www.rfc-editor.org/info/rfc6830>。
[RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software-Defined Networking (SDN): Layers and Architecture Terminology", RFC 7426, DOI 10.17487/RFC7426, January 2015, <https://www.rfc-editor.org/info/rfc7426>.
[RFC7426] Haleplidis、E.、Ed。、Pentikisis、K.、Ed。、Denazis、S.、Hadi Salim、J.、Meyer、D.、およびO.Koufopavlouou、「ソフトウェア定義ネットワーキング（SDN）：レイヤー2015年1月、<https://www.rfc-editor.org/info/rfc7426>を記録しています、および2015年1月、アーキテクチャの用語、RFC 7426 / RFC7426、RFC7426。
[RFC8578] Grossman, E., Ed., "Deterministic Networking Use Cases", RFC 8578, DOI 10.17487/RFC8578, May 2019, <https://www.rfc-editor.org/info/rfc8578>.
[RFC8578]グロスマン、E。、「決定論的ネットワーキングユースケース」、RFC 8578、DOI 10.17487 / RFC8578、2019年5月、<https://www.rfc-editor.org/info/rfc8578>。
[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, "Object Security for Constrained RESTful Environments (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, <https://www.rfc-editor.org/info/rfc8613>.
[RFC8613] Selander、G.、Mattsson、J.、Palombini、F.、およびL.Seitz、「制約のあるRESTFUL環境のためのオブジェクトセキュリティ（OSCORE）」、RFC 8613、DOI 10.17487 / RFC8613、2019年7月、<https：//www.rfc-editor.org/info/rfc8613>。
[RFC8939] Varga, B., Ed., Farkas, J., Berger, L., Fedyk, D., and S. Bryant, "Deterministic Networking (DetNet) Data Plane: IP", RFC 8939, DOI 10.17487/RFC8939, November 2020, <https://www.rfc-editor.org/info/rfc8939>.
[RFC8939]バラジャ、B、ED。、Farkas、J.、Berger、L.、Fedyk、D.、およびS.Bryant、「決定論的ネットワーキング（DECTINAL）データプレーン：IP」、RFC 8939、DOI 10.17487 / RFC8939、2020年11月、<https：//www.rfc-editor.org/info/rfc8939>。
[RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M., and K. Watsen, "Bootstrapping Remote Secure Key Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995, May 2021, <https://www.rfc-editor.org/info/rfc8995>.
[RFC8995] Pritikin、M.、Richardson、M.、Eckert、T.、Behringer、M.、およびK. Watsen、「ブートストラップリモートセキュリティキーインフラストラクチャ（Brski）」、RFC 8995、DOI 10.17487 / RFC8995、2021年5月<https://www.rfc-editor.org/info/rfc8995>。
[RFC9035] Thubert, P., Ed. and L. Zhao, "A Routing Protocol for Low-Power and Lossy Networks (RPL) Destination-Oriented Directed Acyclic Graph (DODAG) Configuration Option for the 6LoWPAN Routing Header", RFC 9035, DOI 10.17487/RFC9035, April 2021, <https://www.rfc-editor.org/info/rfc9035>.
[RFC9035] Thubert、P.、ED。6lowpanルーティングヘッダのための低電力および非損失ネットワーク（RPL）宛先指向非巡回グラフ（DODAG）構成オプション、RFC 9035、DOI 10.17487 / RFC9035、<HTTPSのためのL. Zhao。//www.rfc-editor.org/info/rfc9035>。
[ROBUST-SCHEDULING] Tiloca, M., Duquennoy, S., and G. Dini, "Robust Scheduling against Selective Jamming in 6TiSCH Networks", Work in Progress, Internet-Draft, draft-tiloca-6tisch-robust-scheduling-02, 10 June 2019, <https://tools.ietf.org/html/ draft-tiloca-6tisch-robust-scheduling-02>.
[ロバストスケジューリング] Tiloca、M.、Duquennoy、S.、G. Dini、「6Tischネットワークにおける選択的ジャミングに対するロバストスケジューリング」、進行中の作業、インターネットドラフト、ドラフト - TILOCA-6Tisch-Robust-Scheduling-02、2019年6月10日、<https://tools.ietf.org/html/ romft-tiloca-6tisch-robust-scheduling-02>。
[RPL-APPLICABILITY] Phinney, T., Ed., Thubert, P., and R. Assimiti, "RPL applicability in industrial networks", Work in Progress, Internet-Draft, draft-ietf-roll-rpl-industrial-applicability-02, 21 October 2013, <https://tools.ietf.org/html/draft-ietf-roll-rpl-industrial-applicability-02>.
[RPL適用性] Phinney、T.、ED。、Thubert、P.、およびR. Assimiti、「産業ネットワークにおけるRPL適用性」、進行中、インターネットドラフト、ドラフトIETFロールRPL-産業適用性-02,2012、<https://tools.ietf.org/html/draft-ietf-roll-rpl-inustrial-applicability-02>。
[RPL-BIER] Thubert, P., Ed., "RPL-BIER", Work in Progress, Internet-Draft, draft-thubert-roll-bier-02, 24 July 2018, <https://tools.ietf.org/html/draft-thubert-roll-bier-02>.
[RPL-Bier] Thubert、P.、ED。、「RPL-Bier」、進行中の作業、インターネットドラフト、ドラフトThubert-Roll-Bier-02,202,24 <https：//tools.ietf。org / html / draft-thubert-roll-bier-02>。
[RPL-MOP] Jadhav, R., Ed., Thubert, P., Richardson, M., and R. Sahoo, "RPL Capabilities", Work in Progress, Internet-Draft, draft-ietf-roll-capabilities-08, 17 March 2021, <https://tools.ietf.org/html/draft-ietf-roll-capabilities-08>.
[RPL-MOP] Jadhav、R.、Ed。、Thubert、P.、Richardson、M.、R. Sahoo、「RPL機能」、進行中の作業、インターネットドラフト、ドラフト - IETFロール機能-08、2021年3月17日、<https://tools.ietf.org/html/draft-ietf-roll-capabilities-08>。
[S-ALOHA] Roberts, L. G., "ALOHA packet system with and without slots and capture", ACM SIGCOMM Computer Communication Review, DOI 10.1145/1024916.1024920, April 1975, <https://dl.acm.org/citation.cfm?id=1024920>.
[S-Aloha]ロバート、LG、「スロットとキャプチャの有無にかかわらずAlohaパケットシステム」、ACM SIGCOMM Computer Communication Review、DOI 10.1145 / 1024916.1024920、<https：//dl.acm.org/catute.cfm？ID = 1024920>。
[TE-PREF] Thubert, P., Ed., Eckert, T., Brodard, Z., and H. Jiang, "BIER-TE extensions for Packet Replication and Elimination Function (PREF) and OAM", Work in Progress, Internet-Draft, draft-thubert-bier-replication-elimination-03, 3 March 2018, <https://tools.ietf.org/html/draft-thubert-bier-replication-elimination-03>.
[TE-PREF] Thubert、P.、Ed。、Eckert、T.、Brodard、Z.、H。Jiang、「パケット複製と排除機能（Pref）とOAMのためのBier-Te拡張」、進行中の作業、インターネットドラフト、Draft-Thubert-Bier-Replication-Elimination-03,3月3日、<https：//tools.ietf.org/html/draft-thubert-bier-replication-eLimination-03>。
[TEAS] IETF, "Traffic Engineering Architecture and Signaling (teas)", <https://datatracker.ietf.org/doc/charter-ietf-teas/>.
[TEAS] IETF、「トラフィックエンジニアリングアーキテクチャとシグナリング（TEAS）」、<https://datatracker.ietf.org/doc/charter-ietf-teas/>。
[VIRTUAL-REASSEMBLY] Bormann, C. and T. Watteyne, "Virtual reassembly buffers in 6LoWPAN", Work in Progress, Internet-Draft, draft-ietf-lwig-6lowpan-virtual-reassembly-02, 9 March 2020, <https://tools.ietf.org/html/draft-ietf-lwig-6lowpan-virtual-reassembly-02>.
[仮想再構成] Bormann、C.およびT.Watteyne、「6lowpanでの仮想再構成バッファ」、進行中の作業、インターネットドラフト、Draft-IETF-LWIG-6lowpan-virtual-realsembly-02,200月9日、<HTTPS：//tools.ietf.org/html/draft-ietf-lwig-6lowpan-virtual-reassembly-02>。
[WirelessHART] International Electrotechnical Commission, "Industrial networks - Wireless communication network and communication profiles - WirelessHART(TM)", IEC 62591:2016, March 2016, <https://webstore.iec.ch/publication/24433>.
[WirelessHart]国際電気技術委員会、「ワイヤレス通信ネットワークと通信プロファイル - WirelessHart（TM）」、IEC 62591：2016、2016年3月、<https://webstore.iec.ch/publication/24433>
[ZEROTOUCH-JOIN] Richardson, M., "6tisch Zero-Touch Secure Join protocol", Work in Progress, Internet-Draft, draft-ietf-6tisch-dtsecurity-zerotouch-join-04, 8 July 2019, <https://tools.ietf.org/html/draft-ietf-6tisch-dtsecurity-zerotouch-join-04>.
[ZEROTOCH-JOIN] Richardson、M。、「6Tischゼロタッチセキュア参加プロトコル」、進行中の作業、インターネットドラフト、ドラフト - IETF-6Tisch-DTSecurity-Zerotouch-Join-04,2019,77月8,20 <HTTPS：//tools.ietf.org/html/draft-ietf-6tisch-dtsecurity-zerotouch-join-04>。
This document has been incremented as the work progressed following the evolution of the WG charter and the availability of dependent work. The intent was to publish when the WG concluded on the covered items. At the time of publishing, the following specifications are still in progress and may affect the evolution of the stack in a 6TiSCH-aware node.
この文書は、WG憲章の進化と依存作業の利用可能性に続く作業が進むにつれてインクリメントされました。Intentは、WGがカバーされた項目で締めくくったときに発行することでした。公開時には、以下の仕様が進行中であり、6Tisch対応ノード内のスタックの進化に影響を与える可能性があります。
The security model and in particular the zero-touch join process [ZEROTOUCH-JOIN] depend on the ANIMA (Autonomic Networking Integrated Model and Approach) [ANIMA] "Bootstrapping Remote Secure Key Infrastructure (BRSKI)" [RFC8995] to enable zero-touch security provisioning; for highly constrained nodes, a minimal model based on pre-shared keys (PSK) is also available. As currently written, it also depends on a number of documents in progress in the CORE (Constrained RESTful Environments) WG and on "Ephemeral Diffie-Hellman Over COSE (EDHOC)" [EDHOC], which is being considered for adoption by the LAKE (Lightweight Authenticated Key Exchange) WG.
セキュリティモデルと特にゼロタッチ結合プロセス[ZEROTOCH-JOIN]は、ANIMA（Autonomic Networking Integrated Model and Approach）[ANIMA]「ブートストラップリモートセキュアキーインフラストラクチャ（BRSKI）」[RFC8995]を有効にするための[RFC8995]セキュリティプロビジョニング高密度なノードの場合、事前共有キー（PSK）に基づく最小モデルもあります。現在書かれているように、それはまた、コア（制約されたRESTFUL環境）WGおよび「Ephemeral Diffie-Hellmanを超えて、COS（EDHOC）」（EDHOC）の中の多くの文書にも依存しています。軽量認証鍵交換）WG。
ROLL (Routing Over Low power and Lossy networks) is now standardizing a reactive routing protocol based on RPL [AODV-RPL]. The need of a reactive routing protocol to establish on-demand, constraint-optimized routes and a reservation protocol to establish Layer 3 Tracks is being discussed in 6TiSCH but not yet chartered.
ロール（低電力と損失のあるネットワーク上でのルーティング）は、RPL [AODV-RPL]に基づく無効ルーティングプロトコルを標準化しています。レイヤ3トラックを確立するためのオンデマンド、制約最適化ルート、および予約プロトコルを確立するための無効なルーティングプロトコルの必要性は6tischで議論されていますが、まだチャーターされていません。
At the time of this writing, there is new work planned in the IETF to provide limited deterministic networking capabilities for wireless networks with a focus on forwarding behaviors to react quickly and locally to the changes as described in [RAW-ARCHITECTURE].
この書き込み時には、「RAW - Architecture」で説明されているように、転送動作に焦点を当てて、ワイヤレスネットワークに限られた確定的なネットワーク機能を提供するために、IETFで計画された新しい作業があります。
ROLL is also standardizing an extension to RPL to set up centrally computed routes [DAO-PROJECTION].
ロールはまた、中心に計算されたルート[DAO-PROATION]を設定するためのRPLの拡張を標準化しています。
The 6TiSCH architecture should thus inherit from the DetNet architecture [RFC8655] and thus depends on it. The PCE should be a core component of that architecture. An extension to RPL or to TEAS (Traffic Engineering Architecture and Signaling) [TEAS] will be required to expose the 6TiSCH node capabilities and the network peers to the PCE, possibly in combination with [RPL-MOP]. A protocol such as a lightweight Path Computation Element Communication Protocol (PCEP) or an adaptation of Common Control and Measurement Plane (CCAMP) [CCAMP] GMPLS formats and procedures could be used in combination to [DAO-PROJECTION] to install the Tracks, as computed by the PCE, to the 6TiSCH nodes.
したがって、6TischアーキテクチャはDetnet Architecture [RFC8655]から継承する必要があります。PCEはそのアーキテクチャのコアコンポーネントであるべきです。RPLまたはTEAS（トラフィックエンジニアリングアーキテクチャとシグナリング）の拡張は、おそらく[RPL-MOP]と組み合わせて6tischノード機能とネットワークピアをPCEに公開するために必要です。軽量経路計算要素通信プロトコル（PCEP）や共通制御面（CCAMP] GMPLSフォーマットおよび手順などのプロトコルを、トラックをインストールするために[DAO投影]と組み合わせて使用することができる。6tischノードにPCEによって計算されます。
ROLL is actively working on Bit Index Explicit Replication (BIER) as a method to compress both the data-plane packets and the routing tables in storing mode [RPL-BIER].
ロールは、データプレーンパケットと保存モード[RPL-Bier]の両方のデータプレーンパケットとルーティングテーブルを圧縮する方法として、ビットインデックスの明示的レプリケーション（Bier）を積極的に取り扱っています。
BIER could also be used in the context of the DetNet service layer. "BIER-TE extensions for Packet Replication and Elimination Function (PREF) and OAM" [TE-PREF] leverages BIER Traffic Engineering (TE) to control the DetNet Replication and Elimination activities in the data plane, and to provide traceability on links where replication and loss happen, in a manner that is abstract to the forwarding information.
DETNETサービス層のコンテキストでは、Bierも使用できます。「パケット複製および排除機能（Pref）およびOAMのBier-TE拡張[TE-PREF] [TE-PREF]データプレーン内のDetnetレプリケーションと除去活動を制御し、レプリケーションがリンクにトレーサビリティを提供するためのBier Traffic Engineering（TE）を活用します。転送情報に要約されている方法で、損失が発生する。
"A 6loRH for BitStrings" [BITSTRINGS-6LORH] proposes a 6LoWPAN compression for the BIER BitString based on 6LoWPAN Routing Header [RFC8138].
「ビットストリングのための6lllh」[Bitstrings-6llorh]は、6lowpanルーティングヘッダー[RFC8138]に基づくビールビットストリングの6LOWPAN圧縮を提案しています。
The current charter positions 6TiSCH on IEEE Std 802.15.4 only. Though most of the design should be portable to other link types, 6TiSCH has a strong dependency on IEEE Std 802.15.4 and its evolution. The impact of changes to TSCH on this architecture should be minimal to nonexistent, but deeper work such as 6top and security may be impacted. A 6TiSCH Interest Group at the IEEE maintains the synchronization and helps foster work at the IEEE should 6TiSCH demand it.
IEEE STD 802.15.4上の現在のチャーター位置6Tisch。設計の大部分は他のリンクタイプに移植可能であるべきであるが、6tischはIEEE STD 802.15.4およびその進化に強い依存関係を有する。このアーキテクチャに対するTSCHへの変更の影響は存在しないことが最小限に抑えられている必要がありますが、6社やセキュリティなどのより深い作業を影響を受ける可能性があります。IEEEの6Tischの関心グループは同期を維持し、IEEEでの育成を促進するのに役立ち、6tischはそれを要求する必要があります。
Work is being proposed at IEEE (802.15.12 PAR) for an LLC that would logically include the 6top sublayer. The interaction with the 6top sublayer and the Scheduling Functions described in this document are yet to be defined.
6社のサブレイヤーを論理的に含めるLLCについては、IEEE（802.15.12 PAR）で作業が提案されています。この文書に記載されている6社のサブレイヤとの対話とスケジューリング機能はまだ定義されていません。
ISA100 [ISA100] Common Network Management (CNM) is another external work of interest for 6TiSCH. The group, referred to as ISA100.20, defines a Common Network Management framework that should enable the management of resources that are controlled by heterogeneous protocols such as ISA100.11a [ISA100.11a], WirelessHART [WirelessHART], and 6TiSCH. Interestingly, the establishment of 6TiSCH deterministic paths, called Tracks, are also in scope, and ISA100.20 is working on requirements for DetNet.
ISA100 [ISA100]共通ネットワーク管理（CNM）は、6Tischのための興味のある別の外部作業です。ISA100.20と呼ばれるグループは、ISA100.11A [ISA100.11A]、WirelessHART [WirelessHART]、および6Tischなどの異種プロトコルによって制御されるリソースの管理を可能にする一般的なネットワーク管理フレームワークを定義します。興味深いことに、トラックと呼ばれる6tischの決定論的パスの確立も範囲内であり、ISA100.20はDetnetの要件に取り組んでいます。
Acknowledgments
謝辞
Special Thanks
特別な感謝
Special thanks to Jonathan Simon, Giuseppe Piro, Subir Das, and Yoshihiro Ohba for their deep contributions to the initial security work, to Yasuyuki Tanaka for his work on implementation and simulation that tremendously helped build a robust system, to Diego Dujovne for starting and leading the SF0 effort, and to Tengfei Chang for evolving it in the MSF.
Jonathan Simon、Giuseppe Piro、Subir Das、および初めてのセキュリティ作品への深い貢献のために、初めてのセキュリティ作品への彼らの深さの貢献のために、田中康之への、堅調なシステムを構築するための彼の仕事とシミュレーションのために、開始とリーディングのためのDiego DujovneにSF0の取り組み、そしてMSFで進化するためのTengfei Chang。
Special thanks also to Pat Kinney, Charlie Perkins, and Bob Heile for their support in maintaining the connection active and the design in line with work happening at IEEE 802.15.
IEEE 802.15で起こっている作業に沿った接続を維持するのに役立ちます。
Special thanks to Ted Lemon, who was the INT Area Director while this document was initiated, for his great support and help throughout, and to Suresh Krishnan, who took over with that kind efficiency of his till publication.
この文書が開始されている間、TEDレモンのおかげで、この文書が開始され、彼の偉大な支援と助け、そして刊行物のそのような効率性を引き継いだったKrishnanのために開始されました。
Also special thanks to Ralph Droms, who performed the first INT Area Directorate review, which was very deep and thorough and radically changed the orientations of this document, and then to Eliot Lear and Carlos Pignataro, who helped finalize this document in preparation for the IESG reviews, and to Gorry Fairhurst, David Mandelberg, Qin Wu, Francis Dupont, Éric Vyncke, Mirja Kühlewind, Roman Danyliw, Benjamin Kaduk, and Andrew Malis, who contributed to the final shaping of this document through the IESG review procedure.
また、最初のint area distraateレビューを演奏したRalph Dromsのおかげで、非常に深くて徹底的で根本的にこの文書の向きを根本的に変更した後、IESGのための準備でこの文書を完成させるのを手伝ったエリオットリアとCarlos Pignataroへレビュー、そしてGorry Fairhurst、David Mandelberg、Qin Wu、Francis Dupont、Xyncke、MirjaKühlewind、Roman Danyylw、Benjamin Kaduk、およびAndrew Malis、Andrew Malis。
And Do Not Forget
そして忘れないでください
This document is the result of multiple interactions, in particular during the 6TiSCH (bi)Weekly Interim call, relayed through the 6TiSCH mailing list at the IETF, over the course of more than 5 years.
この文書は、特に6Tisch（BI）毎週の暫定通話中の複数の対話の結果です.IETFの6Tischメーリングリストを介して、5年以上経過しました。
The authors wish to thank in arbitrary order: Alaeddine Weslati, Chonggang Wang, Georgios Exarchakos, Zhuo Chen, Georgios Papadopoulos, Eric Levy-Abegnoli, Alfredo Grieco, Bert Greevenbosch, Cedric Adjih, Deji Chen, Martin Turon, Dominique Barthel, Elvis Vogli, Geraldine Texier, Guillaume Gaillard, Herman Storey, Kazushi Muraoka, Ken Bannister, Kuor Hsin Chang, Laurent Toutain, Maik Seewald, Michael Behringer, Nancy Cam Winget, Nicola Accettura, Nicolas Montavont, Oleg Hahm, Patrick Wetterwald, Paul Duffy, Peter van der Stok, Rahul Sen, Pieter de Mil, Pouria Zand, Rouhollah Nabati, Rafa Marin-Lopez, Raghuram Sudhaakar, Sedat Gormus, Shitanshu Shah, Steve Simlo, Tina Tsou, Tom Phinney, Xavier Lagrange, Ines Robles, and Samita Chakrabarti for their participation and various contributions.
著者らは任意の順序で感謝しています：Alaideine Weslati、Chonggang Wang、Georgios Exarchakos、Zhuo Chen、Georgios Papadopoulos、Eric Levy-Abngeli、Alfredo Greco、Bert Greevenbosch、Cedric Adjih、Deji Chen、Martin Turon、Dominique Barthel、Elvis Vogli、Geraldine Texier、Guillaume Gaillard、Herman Storey、Kazushi Muraoka、Kenbannister、Kuor Hsin Chang、Laurent Toutain、マイコン・ブリューラー、マイケル・ブランティー・マイケル・ブランティー・モンターワール、ニコラス・モンターワルド、Patrick WetterWald、Patreg Dufy、Peter Van DerStok、Rahul Sen、Pieter de Mil、Pria Zand、Rouhollah Nabati、Rafa Marin-Lopez、Raghuram Sudhaakar、Sedat Gormus、Shitanshu Shah、Steve Simlo、Tina Tsou、Tom Phinney、Xavier Lagrange、Ines Robles、Samita Chakrabartiそして様々な貢献。
Contributors
貢献者
The co-authors of this document are listed below:
この文書の共著者たちは以下のとおりです。
Thomas Watteyne for his contributions to the whole design, in particular on TSCH and security, and to the open source community that he created with openWSN;
Thomas Watteyneは、デザイン全体、特にTSCHとセキュリティ、およびOpenWSNで作成したオープンソースコミュニティへの貢献を目指します。
Xavier Vilajosana, who led the design of the minimal support with RPL and contributed deeply to the 6top design and the GMPLS operation of Track switching;
Xavier Vilajosanaは、RPLで最小限のサポートの設計を導いて、6社のデザインとTrackスイッチングのGMPLS操作に深く貢献しました。
Kris Pister for creating TSCH and his continuing guidance through the elaboration of this design;
このデザインの詳細を通してTSCHを作成するためのKris Pisterと彼の継続的なガイダンス。
Mališa Vučinić for the work on the one-touch join process and his contribution to the Security Design Team;
ワンタッチ参加プロセスに関する作業とセキュリティ設計チームへの彼の貢献のためのMalićaVušinić。
Michael Richardson for his leadership role in the Security Design Team and his contribution throughout this document;
セキュリティ設計チームにおける彼のリーダーシップの役割とこの文書全体の彼の貢献のためのMichael Richardson。
Tero Kivinen for his contribution to the security work in general and the security section in particular;
セキュリティ作業に貢献するためのTero Kivinenは一般的なセキュリティ作品と特にセキュリティ部門です。
Maria Rita Palattella for managing the Terminology document that was merged into this document through the work of 6TiSCH;
6Tischの作業を通じてこの文書にマージされた用語文書を管理するためのマリアリタパレッタ。
Simon Duquennoy for his contribution to the open source community with the 6TiSCH implementation of contiki, and for his contribution to MSF and autonomous unicast cells;
Contikiの6tisch実装と、MSFと自律ユニキャストセルへの彼の貢献のためのオープンソースコミュニティへの彼の貢献のためのSimon Duquennoy。
Qin Wang, who led the design of the 6top sublayer and contributed related text that was moved and/or adapted into this document;
Qin Wangは、6社のサブレイヤーの設計を導いて、そしてこの文書に移動および/または適合された関連テキストを拠出しました。
Rene Struik for the security section and his contribution to the Security Design Team;
セキュリティセクションのためのRene Struikとセキュリティ設計チームへの彼の貢献。
Robert Assimiti for his breakthrough work on RPL over TSCH and initial text and guidance.
Robert Assimitiは、TSCHと初期のテキストとガイダンスの上のRPLでのブレークスルー作品のためのRobert Assimiti。
Author's Address
著者の住所
Pascal Thubert (editor) Cisco Systems, Inc Building D 45 Allee des Ormes - BP1200 06254 Mougins - Sophia Antipolis France
Pascal Thubert（編集）Cisco Systems、IncビルディングD 45 Allee Des Ormes - BP1200 06254 Mougins - Sophia Antipolis France
Phone: +33 497 23 26 34
Email: pthubert@cisco.com