[要約] RFC 9034は、低消費電力無線パーソナルエリアネットワーク（6LoWPAN）上のIPv6のためのルーティングヘッダー内のパケット配送期限時間に関するものです。この文書の目的は、データパケットが指定された期限内に目的地に到達することを保証するためのメカニズムを提供することです。主に、時間に敏感なアプリケーションや、信頼性と効率性が求められるネットワーク環境で利用されます。
Internet Engineering Task Force (IETF) L. Thomas
Request for Comments: 9034 C-DAC
Category: Standards Track S. Anamalamudi
ISSN: 2070-1721 SRM University-AP
S.V.R. Anand
M. Hegde
Indian Institute of Science
C. Perkins
Lupin Lodge
June 2021
Packet Delivery Deadline Time in the Routing Header for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)
低電力無線パーソナルエリアネットワークにおけるIPv6のルーティングヘッダにおけるパケット配信期限時間（6lowpans）
Abstract
概要
This document specifies a new type for the 6LoWPAN routing header containing the deadline time for data packets, designed for use over constrained networks. The deadline time enables forwarding and scheduling decisions for time-critical machine-to-machine (M2M) applications running on Internet-enabled devices that operate within time-synchronized networks. This document also specifies a representation for the deadline time values in such networks.
このドキュメントでは、制約付きネットワークで使用するように設計された、データパケットの期限時間を含む6LOWPANルーティングヘッダーの新しいタイプを指定します。期限時刻は、時間同期ネットワーク内で動作するインターネット対応デバイス上で実行されているTime-Critical Machine-To-Machine（M2M）アプリケーションの転送とスケジューリングの決定を可能にします。この文書は、そのようなネットワーク内の期限時間の表現も指定します。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これはインターネット規格のトラック文書です。
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). Further information on Internet Standards is available in Section 2 of RFC 7841.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（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/rfc9034.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/frofc9034で入手できます。
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
3. 6LoRHE Generic Format
4. Deadline-6LoRHE
5. Deadline-6LoRHE Format
6. Deadline-6LoRHE in Three Network Scenarios
6.1. Scenario 1: Endpoints in the Same DODAG (N1)
6.2. Scenario 2: Endpoints in Networks with Dissimilar L2
Technologies
6.3. Scenario 3: Packet Transmission across Different DODAGs (N1
to N2)
7. IANA Considerations
8. Synchronization Aspects
9. Security Considerations
10. References
10.1. Normative References
10.2. Informative References
Appendix A. Modular Arithmetic Considerations
Acknowledgments
Authors' Addresses
Low-Power and Lossy Networks (LLNs) are likely to be deployed for real-time industrial applications requiring end-to-end delay guarantees [RFC8578]. A Deterministic Network ("DetNet") typically requires some data packets to reach their receivers within strict time bounds. Intermediate nodes use the deadline information to make appropriate packet forwarding and scheduling decisions to meet the time bounds.
低電力および非損失ネットワーク（LLN）は、エンドツーエンド遅延保証を必要とするリアルタイムの産業用アプリケーションのために展開される可能性があります[RFC8578]。決定論的ネットワーク（「DETNETENT」）は通常、厳密な時間範囲内でそれらの受信機に到達するためにいくつかのデータパケットを必要とする。中間ノードは期限情報を使用して適切なパケット転送およびスケジューリング決定を達成するための決定決定を行います。
This document specifies a new type for the Elective 6LoWPAN Routing Header (6LoRHE), Deadline-6LoRHE, so that the deadline time (i.e., the time of latest acceptable delivery) of data packets can be included within the 6LoRHE. [RFC8138] specifies the 6LoWPAN Routing Header (6LoRH), compression schemes for RPL (Routing Protocol for Low-Power and Lossy Networks) source routing [RFC6554], header compression of RPL packet information [RFC6553], and IP-in-IP encapsulation. This document also specifies the handling of the deadline time when packets traverse time-synchronized networks operating in different time zones or distinct reference clocks. Time-synchronization techniques are outside the scope of this document. There are a number of standards available for this purpose, including IEEE 1588 [IEEE.1588.2008], IEEE 802.1AS [IEEE.802.1AS.2011], IEEE 802.15.4-2015 Time-Slotted Channel Hopping (TSCH) [IEEE.802.15.4], and more.
この文書は、選択可能な6LOWPANルーティングヘッダー（6lllhe）、締切時6llheの新しいタイプを指定して、データパケットの期限時間（すなわち最新の許容配信の時間）を6llheに含めることができる。[RFC8138] 6lowpanルーティングヘッダー（6lllh）、RPLの圧縮方式（低電力および非損失ネットワークのためのルーティングプロトコル）ソースルーティング[RFC6554]、RPLパケット情報のヘッダー圧縮[RFC6553]、およびIP-In-IPカプセル化。このドキュメントはまた、パケットが異なるタイムゾーンで動作している時間同期ネットワークまたは異なる基準クロックをトラバースしたときの期限時間の処理を指定します。時期同期技術はこの文書の範囲外です。IEEE 1588 [IEEE.1588.2008]、IEEE 802.1AS [IEEE.802.1AS.2011]、IEEE 802.15.4-2015タイムスロットチャネルホッピング（TSCH）[IEEE.802.15）を含むこの目的のために利用可能な標準がいくつかあります。.4]など。
The Deadline-6LoRHE can be used in any time-synchronized 6LoWPAN network. A 6TiSCH (IPv6 over the TSCH mode of IEEE 802.15.4) network is used to describe the implementation of the Deadline-6LoRHE, but this does not preclude its use in scenarios other than 6TiSCH. For instance, there is a growing interest in using 6LoWPAN over a Bluetooth Low Energy (BLE) mesh network [6LO-BLEMESH] in industrial IoT (Internet of Things) [IEEE-BLE-MESH]. BLE mesh time synchronization is being explored by the Bluetooth community. There are also cases under consideration in Wi-SUN [PHY-SPEC] [Wi-SUN].
締め切り6LOWPANネットワークでは、締め切り6LOWPANネットワークで使用できます。IEEE 802.15.4のTSCHモードでのIPv6（IEEE 802.15.4）ネットワークは、締め切り-6llheの実装を説明するために使用されますが、これは6tisch以外のシナリオでの使用を妨げません。例えば、工業用IoT（インターネットのインターネット）でのBluetooth低エネルギー（BLE）メッシュネットワーク[6LO-BLEMESH]を介して6LOWPANを使用する際の関心が高まっています[IEEE-BLE-MESH]。BLEメッシュ時間同期は、Bluetoothコミュニティによって検索されています。Wi-Sun [Phy-Spec] [Wi-Sun]で検討中のケースもあります。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
This document uses the terminology defined in [RFC6550] and [RFC9030].
この資料は[RFC6550]と[RFC9030]で定義されている用語を使用しています。
Note: this section is not normative and is included for convenience. The generic header format of the 6LoRHE is specified in [RFC8138]. Figure 1 illustrates the 6LoRHE generic format.
注：このセクションは規範的ではなく、便宜上に含まれています。6llheの汎用ヘッダーフォーマットは[RFC8138]に指定されています。図1は6llhe汎用フォーマットを示しています。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+
|1|0|1| Length | Type | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+
<--- length --->
Figure 1: 6LoRHE Format
図1：6llheフォーマット
Length: Length of the 6LoRHE expressed in bytes, excluding the first 2 bytes. This enables a node to skip a 6LoRHE if the Type is not recognized or supported.
長さ：最初の2バイトを除く、バイト数で表される6llheの長さ。これにより、タイプが認識されていないかサポートされていない場合、ノードは6llheをスキップすることができます。
Type (variable length): Type of the 6LoRHE (see Section 7).
型（可変長）：6llheのタイプ（セクション7を参照）。
The Deadline-6LoRHE (see Figure 3) is a 6LoRHE [RFC8138] that provides the Deadline Time (DT) for an IPv6 datagram in a compressed form. Along with the DT, the header can include the Origination Time Delta (OTD) packet, which contains the time when the packet was enqueued for transmission (expressed as a value to be subtracted from DT); this enables a close estimate of the total delay incurred by a packet. The OTD field is initialized by the sender based on the current time at the outgoing network interface through which the packet is forwarded. Since the OTD is a delta, the length of the OTD field (i.e., OTL) will require fewer bits than the length of the DT field (i.e., DTL).
Deadline-6llhe（図3参照）は、IPv6データグラムの期限時間（DT）を圧縮形式で提供する6llhe [RFC8138]です。DTと共に、ヘッダは、パケットが送信のためにエンキューされた時刻を含む発信時間デルタ（OTD）パケットを含むことができる（DTから差し引く値として表す）。これにより、パケットによって発生した合計遅延の密接な推定値が可能になります。OTDフィールドは、パケットが転送される発信ネットワークインタフェースでの現在時刻に基づいて送信者によって初期化されます。OTDはデルタであるので、OTDフィールドの長さ（すなわち、OTL）は、DTフィールドの長さよりも少ないビット（すなわちDTL）を必要とするであろう。
The DT field contains the value of the deadline time for the packet -- in other words, the time by which the application expects the packet to be delivered to the receiver.
DTフィールドは、パケットの期限時間の値を含み、言い換えれば、アプリケーションがパケットが受信機に配信されることを期待する時間。
packet_deadline_time = packet_origination_time + max_delay
packet_deadline_time = packet_origination_time max_delay
In order to support delay-sensitive, deterministic applications, all nodes within the network should process the Deadline-6LoRHE. The DT and OTD packets are represented in time units determined by a scaling parameter in the Routing Header. The Network ASN (Absolute Slot Number) can be used as a time unit in a time-slotted synchronized network (for instance, a 6TiSCH network, where global time is maintained in the units of slot lengths of a certain resolution).
遅延に敏感な決定論的アプリケーションをサポートするために、ネットワーク内のすべてのノードは締め切り-6LLOREを処理する必要があります。DTパケットとOTDパケットは、ルーティングヘッダーのスケーリングパラメータによって決定された時間単位で表されます。ネットワークASN（絶対スロット番号）は、タイムスロット付き同期ネットワーク（例えば、一部の解像度のスロット長の単位で維持される6Tischネットワーク）内の時間単位として使用することができる。
The delay experienced by packets in the network is a useful metric for network diagnostics and performance monitoring. Whenever a packet crosses into a network using a different reference clock, the DT field is updated to represent the same deadline time, but expressed using the reference clock of the interface into the new network. Then the origination time is the same as the current time when the packet is transmitted into the new network, minus the delay already experienced by the packet, say 'current_dly'. In this way, within the newly entered network, the packet will appear to have originated 'current_dly' time units earlier with respect to the reference clock of the new network.
ネットワーク内のパケットが経験する遅延は、ネットワーク診断とパフォーマンス監視のための便利なメトリックです。パケットが異なる基準クロックを使用してネットワーク内に交差するときはいつでも、DTフィールドは同じ期限時間を表すが、新しいネットワークへのインタフェースの基準クロックを使用して表現される。その場合、発信時刻は、パケットが新しいネットワークに送信されたときの現在時刻と同じで、既にパケットが経験している遅延を引いた場合、「current_dly」と同じです。このようにして、新たに入力されたネットワーク内で、パケットは、新しいネットワークの基準クロックに関して早く「Current_Dly」時間単位を発信したように見える。
new_network_origin_time = time_now_in_new_network - current_dly
The following example illustrates these calculations when a packet travels between three networks, each in a different time zone (TZ). 'x' can be 1, 2, or 3. Suppose that the deadline time as measured in TZ1 is 1050, and the origination time is 50. Suppose that the difference between TZ2 and TZ1 is 900, and the difference between TZ2 and TZ3 is 3600. In the figure, OT is the origination time as measured in the current time zone, and is equal to DT - OTD, that is, DT - 1000. Figure 2 uses the following abbreviations:
次の例は、パケットが3つのネットワーク間で各ネットワーク間を移動するときのこれらの計算を示しています。'x'は1,2、または3であり得る.Tz1で測定された期限時間が1050であり、そして起源時間は50であると仮定する.Tz2とTz1の差が900であり、Tz2とTz3の差は図中、OTは現在のタイムゾーンで測定されたときの発信時刻であり、DT - OTD、すなわちDT - 1000に等しい。図2は、以下の略語を使用しています。
TxA: Time of arrival of packet in the network 'x'
TXA：ネットワーク内のパケットの到着時
TxD: Departure time of packet from the network 'x'
TXD：ネットワーク「X」からのパケットの出発時刻
dlyx: Delay experienced by the packet in the previous network(s)
DLYX：前のネットワークでパケットが経験する遅延
TZx: The time zone of network 'x'
TZX：ネットワークのタイムゾーン 'X'
TZ1 TZ2 TZ3
T1A=50| | |
|---- dly1=50 | |
| \ | |
| \ | |
| \ T1D=100 |T2A=1000 |
| -------->|----- dly2=450 |
| | \ |
| | \ |
| | \ T2D=1400 | T3A=5000
| | ------------------->|---------->
| | |
v v v
dly0 = 0 dly1 = T1D-OT1 dly2 = T2D-OT2
= 100-50 = 1400 - 950
= 50 = 450
OT1 = T1A-dly0 OT2 = T2A-dly1 OT3 = T3A-dly2
= 50 = 1000-50 = 5000 - 450
= 950 = 4550
Figure 2: Deadline Time Update Example
図2：締め切り時間更新例
There are multiple ways that a packet can be delayed, including queuing delay, Media Access Control (MAC) layer contention delay, serialization delay, and propagation delay. Sometimes there are processing delays as well. For the purpose of determining whether or not the deadline has already passed, these various delays are not distinguished.
キューイング遅延、メディアアクセス制御（MAC）レイヤの競合遅延、シリアル化遅延、および伝播遅延など、パケットを遅延させることができる方法が複数ある。時には処理遅延もあります。締め切りがすでに経過しているかどうかを判断する目的で、これらのさまざまな遅延は区別されていません。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0|1| Length | 6LoRH Type |D| TU| DTL | OTL | BinaryPt |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DT (variable length) | OTD(variable length)(optional)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Deadline-6LoRHE Format
図3：締め切り-6llheフォーマット
Length (5 bits): Length represents the total length of the Deadline-6LoRHE Type measured in octets.
長さ（5ビット）：長さは、オクテットで測定された締め切り-6llhe型の全長を表します。
6LoRH Type: 7 (See Section 7.)
6lllhタイプ：7（セクション7を参照）
D flag (1 bit): The 'D' flag, set by the sender, qualifies the action to be taken when a 6LoWPAN Router (6LR) detects that the deadline time has elapsed.
Dフラグ（1ビット）：送信者によって設定された「D」フラグは、6LOWPANルーター（6LR）が期限が経過したことを検出したときに取られるアクションを修飾します。
If 'D' bit is 1, then the 6LR MUST drop the packet if the deadline time is elapsed.
'd'ビットが1の場合、締め切り時間が経過した場合、6LRはパケットをドロップする必要があります。
If 'D' bit is 0, the packet MAY be forwarded on an exception basis, if the forwarding node is NOT in a situation of constrained resource, and if there are reasons to suspect that downstream nodes might find it useful (delay measurements, interpolations, etc.).
「D」ビットが0の場合、転送ノードが制約されたリソースの状況にない場合、およびその下流ノードがそれを有用であると思うかもしれないと思われる場合（遅延測定、内挿（遅延測定、補間）の理由がある場合は、パケットを例外的に転送することができる。など）。
TU (2 bits): Indicates the time units for DT and OTD fields. The encodings for the DT and OTD fields use the same time units and precision.
TU（2ビット）：DTフィールドとOTDフィールドの時間単位を示します。DTフィールドとOTDフィールドのエンコーディングは、同じ時間単位と精度を使用します。
00 Time represented in seconds and fractional seconds 01 Reserved 10 Network ASN 11 Reserved
00時間秒数秒で表される00時間01予約10ネットワークASN 11予約
DTL (4 bits): Length of the DT field as an unsigned 4-bit integer, encoding the length of the field in hex digits, minus one.
DTL（4ビット）：DTフィールドの長さは、符号なし4ビット整数としての長さ、16進数のフィールドの長さを符号化します。
OTL (3 bits): Length of the OTD field as an unsigned 3-bit integer, encoding the length of the field in hex digits. If OTL == 0, the OTD field is not present. The value of OTL MUST NOT exceed the value of DTL plus one.
OTL（3ビット）：OTDフィールドの長さは、符号の符号の長さを符号化している符号なし3ビット整数としての長さ。OTL == 0の場合、OTDフィールドは存在しません。OTLの値はDTL Plus 1を超えてはいけません。
For example, DTL = 0b0000 means the DT field in the 6LoRHE is 1 hex digit (4 bits) long. OTL = 0b111 means the OTD field is 7 hex digits (28 bits) long.
たとえば、DTL = 0B0000は6llheのDTフィールドを意味します（4ビット）長い1桁の数字（4ビット）です。OTL = 0B111は、OTDフィールドが7桁の数字（28ビット）であることを意味します。
BinaryPt (6 bits): If zero, the number of bits of the integer part the DT is equal to the number of bits of the fractional part of the DT. If nonzero, the BinaryPt is a (2's complement) signed integer determining the position of the binary point within the value for the DT. This allows BinaryPt to be within the range [-32,31].
BINALINALPT（6ビット）：ゼロの場合、DTはDTの小数部分のビット数に等しい。ゼロ以外の場合、BINARYPTは（2の補数）符号付き整数で、DTの値内の2進数の位置を決定します。これにより、BINAINALPTは[-32,31]の範囲内になることができます。
* If BinaryPt value is positive, then the number of bits for the integer part of the DT is increased by the value of BinaryPt, and the number of bits for the fractional part of the DT is correspondingly reduced. This increases the range of DT.
* BINALINALPT値が正の場合、DTの整数部分のビット数はBINALINALPTの値だけ増加し、DTの小数部分のビット数が対応して減少します。これによりDTの範囲が増加します。
* If BinaryPt value is negative, then the number of bits for the integer part of the DT is decreased by the value of BinaryPt, and the number of bits for the fractional part of the DT is correspondingly increased. This increases the precision of the fractional seconds part of DT.
* BINALINALPT値が負の場合、DTの整数部分のビット数はBINALINALPTの値だけ減少し、DTの小数部分のビット数が対応して増加します。これにより、DTの分数秒部分の精度が向上します。
DT Value (4..64 bits): An unsigned integer of DTL+1 hex digits giving the DT value.
DT値（4..64ビット）：DTL 1の16進数の符号なし整数DT値を与える。
OTD Value (4..28 bits): If present, an unsigned integer of OTL hex digits giving the origination time as a negative offset from the DT value.
OTD値（4..28ビット）：存在する場合、OTL 16進数の符号なし整数はDT値からのマイナスオフセットとしての発信時刻を与えます。
Whenever a sender initiates the IP datagram, it includes the Deadline-6LoRHE along with other 6LoRH information. For information about the time-synchronization requirements between sender and receiver, see Section 8.
送信者がIPデータグラムを開始するたびに、それは他の6llh情報と共に締め切り-6llheを含む。送信者と受信者の間の時刻同期要件については、セクション8を参照してください。
For the chosen time unit, a compressed time representation is available as follows. First, the application on the originating node determines how many time bits are needed to represent the difference between the time at which the packet is launched and the deadline time, including the representation of fractional time units. That number of bits (say, N_bits) determines DTL as follows:
選択された時間単位については、圧縮された時間表現が次のように利用可能である。第1に、発信元ノード上のアプリケーションは、パケットが起動されている時刻と分数時間単位の表現を含む期限時間との間の差を表すために必要なタイムビット数を決定する。そのビット数（SAI）（n_bits）は、次のようにDTLを決定します。
DTL = ((N_bits - 1) / 4)
The number of bits determined by DTL allows the counting of any number of fractional time units in the range of interest determined by DT and the OT. Denote this number of fractional time units to be Epoch_Range(DTL) (i.e., Epoch_Range is a function of DTL):
DTLによって決定されたビット数は、DTおよびOTによって決定される関心のある範囲内の任意の数の分数時間単位のカウントを可能にする。この数の分数時間単位は、Epoch_Range（DTL）である（すなわち、Epoch_RangeはDTLの関数）。
Epoch_Range(DTL) = 2^(4*(DTL+1))
Each point of time between OT and DT is represented by a time unit and a fractional time unit; in this section, this combined representation is called a rational time unit (RTU). 1 RTU measures the smallest fractional time that can be represented between two points of time in the epoch (i.e., within the range of interest).
OTとDT間の各時間点は、時間単位と分数時間単位で表されます。このセクションでは、この組み合わせ表現は有理タイムユニット（RTU）と呼ばれます。1 RTUは、エポック内の2つの時点（すなわち、関心のある範囲内）の間で表すことができる最小の分数時間を測定する。
DT - OT cannot exceed 2^(4*(DTL+1)) == 16^(DTL+1). A low value of DTL leads to a small Epoch_Range; if DTL = 0, there will only be 16 RTUs within the Epoch_Range (i.e., Epoch_Range(DTL) = 16^1) for any TU. The values that can be represented in the current epoch are in the range [0, (Epoch_Range(DTL) - 1)].
DT - OTは2 ^（4 *（DTL 1））== 16 ^（DTL 1）を超えることはできません。低価値のDTLは小さなePoch_rangeにつながります。DTL = 0の場合、任意のTUについては、ePoch_range（すなわち、ePoch_range（DTL）= 16 ^ 1）内に16 RTUがあるであろう。現在のEPOCHで表すことができる値は、[0、（EPOCH_RANGE（DTL） - 1）の範囲内にあります。
Assuming wraparound does not occur, OT is represented by the value (OT mod Epoch_Range), and DT is represented by the value (DT mod Epoch_Range). All arithmetic is to be performed modulo (Epoch_Range(DTL)), yielding only positive values for DT - OT.
ラップアラウンドが発生しないと仮定すると、OTは値（OT MOD ePoch_range）で表され、DTは値（DT MOD epoch_range）で表されます。すべての算術演算は、Modulo（Epoch_Range（DTL））を実行し、DT-OTの正の値のみをもたらします。
In order to allow fine-grained control over the setting of the deadline time, the fields for DT and OTD use fractional seconds. This is done by specifying a binary point, which allocates some of the bits for fractional times. Thus, all such fractions are restricted to be negative powers of 2. Each point of time between OT and DT is then represented by a time unit (either seconds or ASNs) and a fractional time unit.
締め切り時間の設定に対するきめ細かい制御を可能にするために、DTとOTDのフィールドは分数秒を使用します。これは2進数を指定することによって行われ、これは部分的な時間のいくつかのビットを割り当てる。したがって、すべてのそのような画分は2の負のべき乗に制限されている.OTとDTの間の各時間点は、時間単位（秒またはASN）および分数時間単位によって表される。
Let OT_abs, DT_abs, and CT_abs denote the true (absolute) values (on the synchronized timelines) for OT, DT, and current time. Let N be the number of bits to be used to represent the integer parts of OT_abs, DT_abs, and CT_abs:
ot_abs、dt_abs、およびct_absを、OT、DT、および現在時刻のTRUE（絶対）値（同期タイムライン）を示します。ot_abs、dt_abs、およびct_absの整数部分を表すために使用されるビット数をnとします。
N = {4*(DTL+1)/2} + BinaryPt
The originating node has to pick a segment size (2^N) so that DT_abs - OT_abs < 2^N, and so that intermediate network nodes can detect whether or not CT_abs > DT_abs.
発信側ノードは、DT_ABS_ABS <2 ^ N、および中間ネットワークノードがCT_ABS> DT_ABSかどうかを検出できるように、セグメントサイズ（2 ^ N）を選択する必要があります。
Given a value for N, the value for DT is represented in the deadline-
time format by DT = (DT_abs mod 2^N). DT is typically represented as
a positive value (even though negative modular values make sense).
Also, let OT = OT_abs mod 2^N and CT = CT_abs mod 2^N, where both OT
and CT are also considered as non-negative values.
When the packet is launched by the originating node, CT_abs == OT_abs and CT == OT. Given a particular value for N, then in order for downstream nodes to detect whether or not the deadline has expired (i.e., whether DT_abs > CT_abs), the following is required:
発信元ノードによってパケットが起動されると、CT_ABS == OT_ABSとCT == OTが停止します。nの特定の値を考えると、下流ノードが期限切れが期限切れかどうかを検出するために（すなわち、DT_AB> CT_ABS）が必要であるかどうかを検出するためには、以下のことが必要である。
Assumption 1: DT_abs - OT_abs < 2^N.
仮定1：DT_ABS - OT_ABS <2 ^ n。
Otherwise the ambiguity inherent in the modulus arithmetic yielding OT and DT will cause failure: one cannot measure time differences greater than 2^N using numbers in a time segment of length less than 2^N.
さもなければ、otとdtを生成するモジュラス算術演算に固有のあいまいさは失敗を引き起こすでしょう.1つは2 ^ n未満の長さの時間セグメントで数字を使用して2 ^ nを超える時間差を測定することはできません。
Under Assumption 1, downstream nodes must effectively check whether or not their current time is later than the DT -- but the value of the DT has to be inferred from the value of DT in the 6LoRHE, which is a number less than 2^N. This inference cannot be expected to reliably succeed unless Assumption 1 is valid, which means that the originating node has to be careful to pick proper values for DTL and for BinaryPt.
仮定1では、下流のノードは、現在の時間がDTより遅いかどうかを効果的にチェックする必要がありますが、DTの値は6llheのDTの値から推測されなければなりません。。この推論は、仮定1が有効でない限り確実に成功することが期待できません。つまり、発信側ノードはDTLの適切な値とBINALINALPTを選択するように注意しなければならないことを意味します。
Since OT is not necessarily provided in the 6loRHE, there may be a danger of ambiguity. Surely, when DT = CT, the deadline time is expiring and the packet should be dropped. However, what if an intermediate node measures that CT = DT+1? Was the packet launched a short time before arrival at the intermediate node, or has the current time wrapped around so that CT_abs - OT_abs > 2^N?
OTは必ずしも6llheで提供されるわけではないので、あいまいさの危険性があるかもしれません。確かに、DT = CTのとき、期限時間は期限切れであり、パケットをドロップする必要があります。ただし、中間ノードがCT = DT 1を測定した場合はどうなりますか？パケットは中間ノードに到着する前に短時間で起動されたか、CT_ABS - OT_ABS> 2 ^ nに折り返されたときに現在の時刻が包まれていましたか？
In order to solve this problem, a safety margin has to be provided, in addition to requiring that DT_abs - OT_abs < 2^N. The value of this safety margin is proportional to 2^N and is determined by a new parameter, called the "SAFETY_FACTOR". Then, for safety the originating node MUST further ensure that (DT_abs - OT_abs) < 2^N*(1-SAFETY_FACTOR).
この問題を解決するために、DT_ABS - OT_ABS <2 ^ nを必要とすることに加えて、安全マージンを提供する必要があります。この安全マージンの値は2 ^ nに比例し、「Safety_Factor」と呼ばれる新しいパラメータによって決まります。その場合、安全のために、発信側ノードはさらに（dt_abs - ot_abs）<2 ^ n *（1-safety_factor）を確実にする必要があります。
Each intermediate node that receives the packet with the Deadline-6LoRHE must determine whether ((CT - DT) mod 2^N) > SAFETY_FACTOR*2^N. If this test condition is not satisfied, the deadline time has expired. See Appendix A for more explanation about the test condition. All nodes that receive a packet with a Deadline-6LoRHE included MUST use the same value for the SAFETY_FACTOR. The SAFETY_FACTOR is to be chosen so that a packet with the Deadline-6LoRHE included will be tested against the current time at least once during every subinterval of length SAFETY_FACTOR*2^N. In this way, it can be guaranteed that the packet will be tested often enough to make sure it can be dropped whenever CT_abs > DT_abs. The value of SAFETY_FACTOR is specified in this document to be 20%.
締め切り6llheでパケットを受信する各中間ノードは、（（（CT - DT）MOD 2 ^ n）> Safety_Factor * 2 ^ Nであるかを判断しなければならない。このテスト条件が満たされていない場合、締め切り時間は期限切れです。テスト条件についての詳細については、付録Aを参照してください。締め切り6llheに含まれているパケットを受信するすべてのノードは、Safety_Factorに同じ値を使用する必要があります。Safety_Factorは、締め切り-6llheを持つパケットが、長さのSafety_Factor * 2 ^ nのすべての部分的な準備が一度少なくとも1回、現在の時間に対してテストされるように選択されるべきです。このようにして、ct_abs> dt_absではいつでもそれが削除できることを確認するのに十分なことが多いことが保証されることができます。Safety_Factorの値は、この文書に20％に指定されています。
Example: Consider a 6TiSCH network with time-slot length of 10 ms.
Let the time units be ASNs (TU == (binary)0b10). Let the current
ASN when the packet is originated be 54400, and the maximum
allowable delay (max_delay) for the packet delivery be 1 second
from the packet origination, then:
deadline_time = packet_origination_time + max_delay
deadline_time = packet_origination_time max_delay.
= 0xD480 + 0x64 (Network ASNs)
= 0xD480 0x64（ネットワークASN）
= 0xD4E4 (Network ASNs)
= 0xD4E4（ネットワークASN）
Then, the Deadline-6LoRHE encoding with nonzero OTL is:
その後、ゼロ以外のOTLを使用したaddline-6llheエンコーディングは次のとおりです。
DTL = 3, OTL = 2, TU = 0b10, BinaryPt = 8, DT = 0xD4E4,
OTD = 0x64
In this section, the Deadline-6LoRHE operation is described for three network scenarios. Figure 4 depicts a constrained time-synchronized LLN that has two subnets, N1 and N2, connected through 6LoWPAN Border Routers (6LBRs) [RFC8929] with different reference clock times, T1 and T2.
このセクションでは、デッドライン-6llheの動作は3つのネットワークシナリオについて説明されています。図4は、6LOWPAN境界ルータ（6LBR）[RFC8929]を、異なる基準クロック時間、T1およびT2を介して接続された2つのサブネットN1およびN2を有する制約付き時期同期LLNを示す。
+-------------------+
| Time-Synchronized |
| Network |
+---------+---------+
|
|
|
+--------------+--------------+
| |
+-----+ +-----+
| | Backbone | | Backbone
o | | router | | router
+-----+ +-----+
o o o
o o o o o o o o o
o LLN o o LLN o o
o o o o o o o o o
6LoWPAN Network (subnet N1) 6LoWPAN Network (subnet N2)
Figure 4: Intra-Network Time Zone Scenario
図4：ネットワーク内タイムゾーンシナリオ
In Scenario 1, shown in Figure 5, the Sender 'S' has an IP datagram to be routed to a Receiver 'R' within the same Destination-Oriented Directed Acyclic Graph (DODAG). For the route segment from the sender to the 6LBR, the sender includes a Deadline-6LoRHE by encoding the deadline time contained in the packet. Subsequently, each 6LR will perform hop-by-hop routing to forward the packet towards the 6LBR. Once the 6LBR receives the IP datagram, it sends the packet downstream towards 'R'.
図5に示すシナリオ1では、送信者の「S」は、同じ宛先指向の指向性非晶系グラフ（DODAG）内で受信機 'R'にルーティングされるIPデータグラムを有する。送信側から6LBRへのルートセグメントの場合、送信者はパケットに含まれる期限時間を符号化することによって締め切り6llheを含む。続いて、各6LRは、パケットを6LBRに向かって転送するためのホップバイホップルーティングを実行する。6LBRがIPデータグラムを受信すると、パケットを下流に送信します。
In the case of a network running in RPL non-storing mode, the 6LBR generates an IPv6-in-IPv6 encapsulated packet when sending the packet downwards to the receiver [RFC9008]. The 6LBR copies the Deadline-6LoRHE from the sender-originated IP header to the outer IP header. The Deadline-6LoRHE contained in the inner IP header is removed.
RPL非格納モードで実行されているネットワークの場合、6LBRは、パケットを受信側[RFC9008]に送信するときにIPv6-IN-IPv6カプセル化パケットを生成します。6LBRは、送信者発信IPヘッダーからDeadline-6llheを外部IPヘッダーにコピーします。内部IPヘッダーに含まれる締切日6llheが削除されます。
+-------+
^ | 6LBR | |
| | | |
| +-------+ |
Upward | / /| \ | Downward
routing | (F) / | \ | routing
| / \ (C) | (D) |
| / \ | | / |\ |
| (A) (B) : (E) : R |
| /|\ | \ / \ |
| S : : : : : : v
Figure 5: Endpoints within the Same DODAG (Subnet N1)
図5：同じDODAG内のエンドポイント（サブネットN1）
At the tunnel endpoint of the encapsulation, the Deadline-6LoRHE is copied back from the outer header to inner header, and the inner IP packet is delivered to 'R'.
カプセル化のトンネルエンドポイントでは、デッドライン-6llheが外側のヘッダから内側のヘッダにコピーされ、内部IPパケットが 'R'に配信されます。
In Scenario 2, shown in Figure 6, the Sender 'S' (belonging to DODAG 1) has an IP datagram to be routed to a Receiver 'R' over a time-synchronized IPv6 network. For the route segment from 'S' to 6LBR, 'S' includes a Deadline-6LoRHE. Subsequently, each 6LR will perform hop-by-hop routing to forward the packet towards the 6LBR. Once the deadline time information reaches the 6LBR, the packet will be encoded according to the mechanism prescribed in the other time-synchronized network depicted as "Time-Synchronized Network" in Figure 6. The specific data encapsulation mechanisms followed in the new network are beyond the scope of this document.
図6に示すシナリオ2では、送信者のS '（DoDag 1に属する）は、時期同期IPv6ネットワークを介して受信機' R 'にルーティングされるIPデータグラムを有する。ルートセグメントから6LBRの場合、 'S'は締め切り-6llheを含みます。続いて、各6LRは、パケットを6LBRに向かって転送するためのホップバイホップルーティングを実行する。締め切り時刻情報が6LBRに達すると、パケットは「時刻同期ネットワーク」として規定されているメカニズムに従って符号化され、図6に続く特定のデータカプセル化メカニズムが超えている。この文書の範囲。
+----------------+
| Time- |
| Synchronized |------R
| Network |
+----------------+
|
|
----------+-----------
^ |
| +---+---+
| | 6LBR |
Upward | | |
routing | +------++
| (F)/ /| \
| / \ / | \
| / \ (C) | (D)
| (A) (B) | | / |\
| /|\ |\ : (E) : :
| S : : : : / \
: :
Figure 6: Packet Transmission in Dissimilar L2 Technologies or Internet
図6：異なるL2技術またはインターネットにおけるパケット送信
For instance, the IP datagram could be routed to another time-synchronized, deterministic network using the mechanism specified in In-situ Operations, Administration, and Maintenance (IOAM) [IOAM-DATA], and then the deadline time would be updated according to the measurement of the current time in the new network.
たとえば、IPデータグラムは、その場操作、管理、およびメンテナンス（IOAM）[IOAM-DATA]で指定されたメカニズムを使用して、別の時期同期、決定論的ネットワークにルーティングでき、次に締め切り時間が更新されます。新しいネットワークにおける現在時刻の測定
Consider the scenario depicted in Figure 7, in which the Sender 'S' (belonging to DODAG 1) has an IP datagram to be sent to Receiver 'R' belonging to another DODAG (DODAG 2). The operation of this scenario can be decomposed into a combination of Scenarios 1 and 2. For the route segment from 'S' to 6LBR1, 'S' includes the Deadline-6LoRHE. Subsequently, each 6LR will perform hop-by-hop operations to forward the packet towards 6LBR1. Once the IP datagram reaches 6LBR1 of DODAG1, 6LBR1 applies the same rule as described in Scenario 2 while routing the packet to 6LBR2 over a (likely) time-synchronized wired backhaul. The wired side of 6LBR2 can be mapped to the receiver of Scenario 2. Once the packet reaches 6LBR2, it updates the Deadline-6LoRHE by adding or subtracting the difference of time of DODAG2 and sends the packet downstream towards 'R'.
図7に示すシナリオを考慮し、そこでは送信者のS '（DoDag 1に属する）が、他のDoDag（DoDag 2）に属する受信機' R 'に送信されるIPデータグラムを有する。このシナリオの動作は、シナリオ1と2の組み合わせに分解することができます。ルートセグメントの場合は、 'S'から6lbr1の場合、 's'は締め切り-6llheを含みます。続いて、各6LRは、パケットを6LBR1に向けて転送するためのホップバイホップ動作を実行する。IPデータグラムがDoDAG1の6LBR1に達すると、6LBR1はシナリオ2に記載されているのと同じ規則を適用しながら、パケットを（おそらく（おそらく）時間同期する有線バックホールを介して6LBR2にルーティングします。6LBR2の有線側はシナリオの受信機にマッピングすることができる。
Time-Synchronized Network
-+---------------------------+-
| |
DODAG1 +---+---+ +---+---+ DODAG2
| 6LBR1 | | 6LBR2 |
| | | |
+-------+ +-------+
(F)/ /| \ (F)/ /| \
/ \ / | \ / \ / | \
/ \ (C) | (D) / \ (C) | (D)
(A) (B) | | / |\ (A) (B) | | |\
/|\ |\ : (E) : : /|\ |\ : (E) : :
S : : : : / \ : : : : : / \
: : : R
Network N1, time zone T1 Network N2, time zone T2
Figure 7: Packet Transmission in Different DODAGs (N1 to N2)
図7：異なるDODAGにおけるパケット送信（N1~N2）
Consider an example of a 6TiSCH network in which S in DODAG1 generates the packet at ASN 20000 to R in DODAG2. Let the maximum allowable delay be 1 second. The time-slot length in DODAG1 and DODAG2 is assumed to be 10 ms. Once the deadline time is encoded in Deadline-6LoRHE, the packet is forwarded to 6LBR1 of DODAG1. Suppose the packet reaches 6LBR1 of DODAG1 at ASN 20030.
DODAG1のSのSがDoDAG2のASN 20000からRでパケットを生成する6Tischネットワークの例を考えてみましょう。最大許容遅延を1秒間にする。DODAG1およびDODAG2のタイムスロット長は10msとしていると仮定されている。締め切り時間が締め切り - 6LLORHEで符号化されると、パケットはDoDAG1の6LBR1に転送される。パケットがASN 20030でDODAG1の6LBR1に達するとします。
current_time = ASN at 6LBR * slot_length_value
current_time = 6LBR * slot_length_valueでASN
remaining_time = deadline_time - current_time
= ((packet_origination_time + max_delay) - current time)
= (20000 + 100) - 20030
= 30 (in Network ASNs)
= 30（ネットワークASNS）
= 30 * 10^3 milliseconds
Once the deadline time information reaches 6LBR2, the packet will be encoded according to the mechanism prescribed in the other time-synchronized network.
期限情報が6LBR2に達すると、パケットは他の時間同期ネットワークに規定されているメカニズムに従って符号化される。
This document defines a new Elective 6LoWPAN Routing Header Type, and IANA has assigned the value 7 from the 6LoWPAN Dispatch Page 1 number space for this purpose.
この文書は新しい選択可能な6lowpanルーティングヘッダータイプを定義し、IANAはこの目的のために6lowpan Dispatchページ1の数値スペースから値7を割り当てました。
+=======+=================+===========+
| Value | Description | Reference |
+=======+=================+===========+
| 7 | Deadline-6LoRHE | RFC 9034 |
+-------+-----------------+-----------+
Table 1: Entry in the "Elective 6LoWPAN Routing Header Type" Registry
表1：「選択的6LOWPANルーティングヘッダータイプ」レジストリのエントリ
The document supports time representation of the deadline and origination times carried in the packets traversing networks of different time zones having different time-synchronization mechanisms. For instance, in a 6TiSCH network where the time is maintained as ASN time slots, the time synchronization is achieved through beaconing among the nodes as described in [RFC7554]. There could be 6lo networks that employ NTP where the nodes are synchronized with an external reference clock from an NTP server. The specification of the time-synchronization method that needs to be followed by a network is beyond the scope of the document.
文書は、異なる時間同期メカニズムを有する異なるタイムゾーンのネットワークを通過するパケット内で運ばれる期限および発信時間の時間表現をサポートする。例えば、時刻がASNタイムスロットとして維持される6Tischネットワークでは、[RFC7554]に記載されているようにノード間のビーコンを通して時間同期が達成される。ノードがNTPサーバから外部基準クロックと同期されているNTPを使用する6LOネットワークがある可能性があります。ネットワークが続く必要がある時刻同期方法の仕様は、文書の範囲を超えています。
The number of hex digits chosen to represent DT, and the portion of that field allocated to represent the integer number of seconds, determines the meaning of t_0, i.e., the meaning of DT == 0 in the chosen representation. If DTL == 0, then there are only 4 bits that can be used to count the time units, so that DT == 0 can never be more than 16 time units (or fractional time units) in the past. This then requires that the time synchronization between sender and receiver has to be tighter than 16 units. If the binary point were moved so that all the bits were used for fractional time units (e.g., fractional seconds or fractional ASNs), the time-synchronization requirement would be correspondingly tighter.
DTを表すために選択された16進数の数、およびその整数秒数を表すために割り当てられたそのフィールドの部分は、選択された表現におけるT_0、すなわちDT == 0の意味を決定する。DTL == 0の場合、時間単位をカウントするために使用できる4ビットしかないので、DT == 0が過去に16の時間単位（または小数時間単位）になることはできません。これにより、送信者と受信機との間の時間同期が16単位よりきつく必要があることを必要とする。二値点を移動させて全てのビットを分数時間単位（例えば、分数秒または分数ASN）に使用された場合、時間同期要件はそれに対応して厳しくなる。
A 4-bit field for DT allows up to 16 hex digits, which is 64 bits. That is enough to represent the NTP 64-bit timestamp format [RFC5905], which is more than enough for the purposes of establishing deadline times. Unless the binary point is moved, this is enough to represent time since year 1900.
DTの4ビットフィールドは、64ビットの最大16桁の数字を許可します。これは、NTP 64ビットタイムスタンプフォーマット[RFC5905]を表すのに十分です。これは、期限時間を確立する目的で十分です。バイナリポイントが移動しない限り、これは1900年以来の時間を表すのに十分です。
For example, suppose that DTL = 0b0000 and the DT bits are split evenly; then we can count up to 3.75 seconds by quarter-seconds.
たとえば、DTL = 0B0000とDTビットが均等に分割されているとします。それから私たちは4分の3.75秒秒秒数秒まで数えることができます。
If DTL = 3 and the DT bits are again split evenly, then we can count up to 256 seconds (in steps of 1/256 of a second).
DTL = 3でDTビットが再び均等に分割されている場合は、最大256秒（1/256秒のステップで）カウントできます。
In all cases, t_0 is defined as specified in Section 5.
すべての場合において、T_0はセクション5で指定されているように定義されます。
t_0 = [current_time - (current_time mod (2^(4*(DTL+1))))]
regardless of the choice of TU.
TUの選択にかかわらず。
For TU = 0b00, the time units are seconds. With DTL == 15, and BinaryPt == 0, the epoch is (by default) January 1, 1900, at 00:00 UTC. The resolution is then 2^-32 seconds, which is the maximum possible. This time format wraps around every 2^32 seconds, which is roughly 136 years.
TU = 0B00の場合、時間単位は秒です。DTL == 15とBINALINGPT == 0では、エポックは（デフォルトで）1900年1月1日、00:00 UTCです。解像度は2 ^ ~32秒です。これは可能な限り最大です。この時期フォーマットは2秒ごとにラップします。これはおよそ136年です。
For TU = 0b10, the time units are ASNs. The start time is relative, and updated by a mechanism that is out of scope for this document. With 10 ms slots, DTL = 15, and BinaryPt == 0, it would take over a year for the ASN to wrap around. Typically, the number of hex digits allocated for TU = 0b10 would be less than 15.
TU = 0B10の場合、時間単位はASNです。開始時刻は相対的で、この文書の範囲外のメカニズムによって更新されます。10 msのスロット、DTL = 15、およびBinarypt == 0では、ASNが折り返すために1年以上かかります。通常、TU = 0B10に割り当てられた16進数の数は15未満になります。
The security considerations of [RFC4944] (Section 13), [RFC6282] (Section 6), and [RFC6553] (Section 5) apply. Using a compressed format as opposed to the full inline format is logically equivalent and does not create an opening for a new threat when compared to [RFC6550], [RFC6553], and [RFC6554].
[RFC4944]のセキュリティ上の考慮事項（第13節）、[RFC6282]（第6章）、[RFC6553]（セクション5）が適用されます。全インライン形式とは対照的に圧縮形式を使用することは論理的に同等であり、[RFC6550]、[RFC6553]、[RFC6554]と比較した場合に新しい脅威のための開口部を作成しません。
The protocol elements specified in this document are designed to work in controlled operational environments (e.g., industrial process control and automation). In order to avoid misuse of the deadline information that could potentially result in a Denial of Service (DoS) attack, proper functioning of this deadline time mechanism requires the provisioning and management of network resources for supporting traffic flows with deadlines, performance monitoring, and admission control policy enforcement. The network provisioning can be done either centrally or in a distributed fashion. For example, tracks in a 6TiSCH network could be established by a centralized Path Computation Element (PCE), as described in the 6TiSCH architecture [RFC9030].
この文書で指定されているプロトコル要素は、制御された運用環境で機能するように設計されています（例えば、産業プロセス制御と自動化）。潜在的にサービス拒否（DOS）攻撃をもたらす可能性がある期限情報の誤用を避けるためには、この期限タイムメカニズムの適切な機能には、期限、パフォーマンス監視、および入場料を含むトラフィックフローをサポートするためのネットワークリソースのプロビジョニングおよび管理が必要です。制御ポリシーの執行ネットワークプロビジョニングは、中央または分散的な方法で行うことができます。例えば、6Tischネットワーク内のトラックは、6tischアーキテクチャ[RFC9030]で説明されているように、集中型経路計算要素（PCE）によって確立することができる。
The security considerations of DetNet architecture [RFC8655] (Section 5) mostly apply to this document as well, as follows. To secure the request and control of resources allocated for tracks, authentication and authorization can be used for each device and network controller devices. In the case of distributed control protocols, security is expected to be provided by the security properties of the protocols in use.
Detnet Architecture [RFC8655]（セクション5）のセキュリティ上の考慮事項は、次のようにこの文書にも同様に適用されます。トラックに割り当てられたリソースの要求と制御を確保するために、認証と許可を各デバイスおよびネットワークコントローラデバイスに使用できます。分散制御プロトコルの場合、セキュリティは使用中のプロトコルのセキュリティプロパティによって提供されると予想されます。
The identification of deadline-bearing flows on a per-flow basis may provide attackers with additional information about the data flows compared to networks that do not include per-flow identification. The security implications of disclosing that additional information deserve consideration when implementing this deadline specification.
一流動基準での締め切り流動の識別は、フロー識別は含まれないネットワークと比較して、データフローに関する追加の情報を攻撃者に提供することができる。この付加情報がこの締め切り仕様を実施するときに、追加情報を考慮に値するという証券の意味。
Because of the requirement of precise time synchronization, the accuracy, availability, and integrity of time synchronization is of critical importance. Extensive discussion of this topic can be found in [RFC7384].
正確な時間同期の要件のために、時間同期の正確さ、可用性、および完全性は極めて重要である。このトピックについては、[RFC7384]に記載されています。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[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>。
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, <https://www.rfc-editor.org/info/rfc5905>.
[RFC5905]ミルズ、D.、Martin、J.、Ed。、Burbank、J.、およびW. Kasch、「ネットワークタイムプロトコルバージョン4：プロトコルおよびアルゴリズム仕様」、RFC 5905、DOI 10.17487 / RFC5905、2010年6月<https://www.rfc-editor.org/info/rfc5905>。
[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>。
[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>。
[RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, October 2014, <https://www.rfc-editor.org/info/rfc7384>.
[RFC7384] Mizrahi、T.、「パケット交換ネットワークにおける時間プロトコルのセキュリティ要件」、RFC 7384、DOI 10.17487 / RFC7384、2014年10月、<https：//www.rfc-editor.org/info/rfc7384>。
[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>。
[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>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[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>。
[RFC9030] Thubert, P., Ed., "An Architecture for IPv6 over the Time-Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)", RFC 9030, DOI 10.17487/RFC9030, May 2021, <https://www.rfc-editor.org/info/rfc9030>.
[RFC9030]「IEEE 802.15.4（6tisch）のタイムスロットチャネルホッピングモード（6Tisch）」、RFC 9030、DOI 10.17487 / RFC9030、<https：//のタイムスロットチャネルホッピングモードでのIPv6のアーキテクチャー。www.rfc-editor.org/info/rfc9030>。
[6LO-BLEMESH] Gomez, C., Darroudi, S. M., Savolainen, T., and M. Spoerk, "IPv6 Mesh over BLUETOOTH(R) Low Energy using IPSP", Work in Progress, Internet-Draft, draft-ietf-6lo-blemesh-10, 22 April 2021, <https://tools.ietf.org/html/draft-ietf-6lo-blemesh-10>.
[6LO-BLEMESH] Gomez、C.、Darroudi、SM、Savolainen、T.、およびM.スポット、「Bluetoothを使用したIPv6メッシュ」、「IPSPを使用したBluetooth（R）低エネルギー上」、進行中、インターネットドラフト、ドラフトIETF-6LO-BLEMESH-10,24月22日、<https://tools.ietf.org/html/draft-ietf-6lo-blemesh-10>。
[IEEE-BLE-MESH] Leonardi, L., Patti, G., and L. Lo Bello, "Multi-Hop Real-Time Communications Over Bluetooth Low Energy Industrial Wireless Mesh Networks", IEEE Access, Vol 6, pp. 26505-26519, DOI 10.1109/ACCESS.2018.2834479, May 2018, <https://doi.org/10.1109/ACCESS.2018.2834479>.
[IEEE-BLE-MESH]レオナルディ、L.、Patti、G.、L. Lo Belro、「Bluetooth低エネルギー産業用無線メッシュネットワーク上のマルチホップリアルタイム通信」、IEEEアクセス、Vol 6、PP。265052018年5月、DOI 10.1109 / Access.2018.2834479、<https：//doi.org/10.1109/access.2018.2834479>。
[IEEE.1588.2008] IEEE, "IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems", DOI 10.1109/IEEESTD.2008.4579760, July 2008, <https://doi.org/10.1109/IEEESTD.2008.4579760>.
[IEEE.1588.2008] 2008年7月、<https://doi.org/10.1109/ieeetd.2008.4579760 / 10.1109/ieeEstd.2008.4579760,2008.4579760,2008.4579760,2008.4579760 / 10.1109/ieeeStd.2008.4579760,2008.4579760を参照してください。
[IEEE.802.15.4] 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>.
[IEEE.802.15.4] IEEE、「低速ワイヤレスネットワークのためのIEEE規格」、IEEEスタンダード802.15.4-2015、DOI 10.1109 / IEEESTD.2016.7460875、<https：//ieeexplore.ieee.org/document/ 7460875>。
[IEEE.802.1AS.2011] IEEE, "IEEE Standard for Local and Metropolitan Area Networks - Timing and Synchronization for Time-Sensitive Applications in Bridged Local Area Networks", IEEE Std 802.1AS-2011, DOI 10.1109/IEEESTD.2011.5741898, March 2011, <https://doi.org/10.1109/IEEESTD.2011.5741898>.
[IEEE.802.1AS.2011] IEEE、「地元および首都圏のネットワークのIEEE規格 - 橋渡しローカルエリアネットワークにおける時間的なアプリケーションのためのタイミングと同期」、IEEE STD 802.1AS-2011、DOI 10.1109 / IEEESTD.2011.5741898、3月2011年、<https://doi.org/10.1109/ieeeestd.2011.5741898>。
[IOAM-DATA] Brockners, F., Ed., Bhandari, S., Ed., and T. Mizrahi, Ed., "Data Fields for In-situ OAM", Work in Progress, Internet-Draft, draft-ietf-ippm-ioam-data-12, 21 February 2021, <https://tools.ietf.org/html/draft-ietf-ippm-ioam-data-12>.
[IOAM-DATA]ブロック、F、ED。、BHANDARI、S、ED。、およびT.Mizrahi、ED。、「インサイチオのデータフィールド」、進行中の作業、インターネットドラフト、ドラフトIETF-ippm-ioam-data-12,2021、<https://tools.ietf.org/html/draft-ietf-ippm-ioam-data-12>。
[PHY-SPEC] Wi-SUN Alliance, "Wi-SUN PHY Specification V1.0", March 2016, <http://wi-sun.org>.
[PHY-SPEC] Wi-Sun Alliance、「Wi-Sun Phy Specification V1.0」、2016年3月、<http://wi-sun.org>。
[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>。
[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>。
[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>。
[Wi-SUN] Harada, H., Mizutani, K., Fujiwara, J., Mochizuki, K., Obata, K., and R. Okumura, "IEEE 802.15.4g Based Wi-SUN Communication Systems", IEICE Transactions on Communications, Volume E100.B, Issue 7, pp. 1032-1043, DOI 10.1587/transcom.2016SCI0002, January 2017, <https://doi.org/10.1587/transcom.2016SCI0002>.
[Wi-Sun]ハラダ、H.、Mizutani、K.、Fujiwara、J.、Mochizuki、K.、Obata、K.、R. Okumura、「IEEE 802.15.4GベースのWi-Sun Communication Systems」、電子情報通信取引コミュニケーション、ボリュームE100.B、Issue 7、PP。1032-1043、DOI 10.1587 / Transcom.2016SCI0002、2017年1月、<https：//doi.org/10.1587/transcom.2016sci0002>。
Graphically, one might visualize the timeline as follows:
グラフィカルには、次のようにタイムラインを視覚化することができます。
OT_abs CT_abs DT_abs
-------|-------------|-------------|------------------>
Figure 8: Absolute Timeline Representation
図8：絶対タイムライン表現
In Figure 8, the value of CT_abs is envisioned as traveling to the
right as time progresses, getting farther away from OT_abs and
getting closer to DT_abs. The timeline is considered to be
subdivided into time subintervals [i,j] starting and ending at
absolute times equal to k*(2^N), for integer values of k. Let I_k =
k*(2^N) and I_(k+1) = (k+1)*2^N. Intervals starting at I_k and
I_(k+1) may occur at various placements in the above timeline. Even
though OT_abs is _always_ less than DT_abs, it could be that DT < OT
because of the way that DT and OT are represented within the range
[0, 2^N) and similarly for CT_abs and CT compared to OT and DT.
Representing the above situation in time segments of length 2^N (and values OT, CT, DT) results in several cases where the deadline time has not elapsed:
長さ2 ^ nの時間セグメント（および値OT、CT、DT）の時間セグメントにおける上記の状況を表すと、期限が経過していない場合のいくつかのケースが得られます。
1) OT < CT < DT (e.g., I_k < OT_abs < CT_abs < DT_abs < I_(k+1) )
2) DT < OT < CT (e.g., I_k < OT_abs < CT_abs < I_(k+1) < DT_abs )
3) CT < DT < OT (e.g., I_k < OT_abs < I_(k+1) < CT_abs < DT_abs )
In the following cases, the deadline time has elapsed and the packet should be dropped.
次の場合、期限時間が経過し、パケットをドロップする必要があります。
4) DT < CT < OT
4) DT <CT <OT
5) OT < DT < CT
5) OT <DT <CT
6) CT < OT < DT
6) CT <OT <DT
Again in Figure 8, consider CT_abs as time moving away from OT_abs and towards DT_abs. For times CT_abs before the expiration of the deadline time, we also have CT_abs - OT_abs == CT - OT mod 2^N and similarly for DT_abs - CT_abs.
繰り返しますが、図8では、ot_absから離れてdt_absに向かって移動する時間としてCT_ABSを検討してください。締め切り時間の満了前にCT_ABSの場合、DT_ABS - CT_ABSの場合もCT_ABS - OT_ABS == CT - OT MOD 2 ^ nを有する。
As time proceeds, DT_abs - CT_abs gets smaller. When the deadline time expires, DT_abs - CT_abs begins to grow negative. A proper selection for SAFETY_FACTOR allows it to go _slightly negative_ but for an intermediate point to _detect_ that it has gone negative. Note that in modular arithmetic, "slightly negative" means _exactly_ the same as "almost as large as the modulus (i.e., 2^N)". Now consider the test condition ((CT - DT) mod 2^N) > SAFETY_FACTOR*2^N.
時間が進むにつれて、DT_ABS - CT_ABSは小さくなります。期限が切れると、DT_ABS - CT_ABSはマイナスに成長し始めます。Safety_Factorの適切な選択は、それが_ ylightly magy_で、中間点のために_detect_を否定的に行くことができます。モジュール式演算では、「わずかに否定的な」とは、_exactly_を「弾性率（すなわち、2 ^ n）」と同じであることを意味する。ここで、テスト条件（（CT - DT）MOD 2 ^ N）> SAFICTER_FACTOR * 2 ^ nを検討してください。
(DT_abs - OT_abs) < 2^N*(1-SAFETY_FACTOR) satisfies the test condition when CT_abs == OT_abs (i.e., when the packet is launched). In modular arithmetic, 2^N*(1-SAFETY_FACTOR) == 2^N - 2^N*SAFETY_FACTOR == -2^N*(SAFETY_FACTOR). Then DT_abs - OT_abs < -2^N*(1-SAFETY_FACTOR). Inverting the inequality, OT_abs - DT_abs > 2^N*(1-SAFETY_FACTOR), and thus at launch CT_abs - DT_abs > 2^N*(1-SAFETY_FACTOR).
（DT_ABS - OT_ABS）<2 ^ n *（1-safety_factor）ct_abs == ot_abs（すなわち、パケットが起動されたとき）のときのテスト条件を満たします。モジュラー算術演算では、2 ^ n *（1-safety_factor）== 2 ^ n - 2 ^ n * safety_factor == -2 ^ n *（Safety_Factor）。その後、dt_abs - ot_abs <-2 ^ n *（1-safety_factor）。不等式、OT_ABS - DT_ABS> 2 ^ n *（1-Safety_Factor）、したがってCT_ABS - DT_ABS> 2 ^ n *（1-safety_factor）で反応します。
As CT_abs grows larger, CT_abs - DT_abs gets LARGER in (non-negative) modular arithmetic until the time at which CT_ABS == DT_ABS, and suddenly CT_ABS - DT_abs becomes zero. Also suddenly, the test condition is no longer fulfilled.
CT_ABSが大きくなるにつれて、CT_ABS - DT_ABSはCT_ABS == DT_ABS、および突然CT_ABS - DT_ABSがゼロになるまで、（ノンマイナス）モジュラ演算で大きくなります。突然、テスト条件はもはや満たされません。
As CT_abs grows still larger, CT_abs > DT_abs, and we need to detect this condition as soon as possible. Requiring the SAFETY_FACTOR enables this detection until CT_abs exceeds DT_abs by an amount equal to SAFETY_FACTOR*2^N.
CT_ABSが依然として大きくなるにつれて、CT_ABS> DT_ABSが増加し、できるだけ早くこの状態を検出する必要があります。Safety_Factorを必要とすると、CT_ABSがSafety_Factor * 2 ^ Nに等しい量だけDT_ABSを超えるまでこの検出を可能にします。
A note about "inverting the inequality". Observe that a < b implies that -a > -b on the real number line. Also, (a - b) == -(b - a). These facts hold also for modular arithmetic.
「不等式を反転する」に関するメモ。A <Bが実数行の-A> -Bを意味することを確認します。また、（a - b）== - （b - a）。これらの事実はモジュラー算術演算にも保持されています。
During the times prior to the expiration of the deadline, for Safe = 2^N*SAFETY_FACTOR we have:
締め切りの期限切れの期間中、安全= 2 ^ n *安全_factor私たちは持っています：
(DT_abs - 2^N) < OT_abs < CT_abs < DT_abs < DT_abs+Safe
Naturally, DT_abs - 2^N == DT_abs mod 2^N == DT.
当然、DT_ABS - 2 ^ n == DT_ABS MOD 2 ^ n == DT。
Again considering Figure 8, it is easy to see that {CT_abs - (DT_abs - 2^N)} gets larger and larger until the time at which CT_abs = DT_abs, which is the first time at which CT - DT == 0 mod 2^N. As CT_abs increases past the deadline time, 0 < CT_abs - DT_abs < Safe. In this range, any intermediate node can detect that the deadline has expired. As CT_abs increases past DT_abs+Safe, it is no longer possible for an intermediate node to determine with certainty whether or not the deadline time has expired. These statements also apply when reduced to modular arithmetic in the modulus 2^N.
再び図8を考慮すると、CT_ABS = DT_ABSがCT-DT == 0 MOD 2の最初の時刻である時間が、{CT_ABS - （DT_ABS - 2 ^ N）}が大きくて大きくなるのは簡単です。^ n。CT_ABSが締め切り時間を超えて増加するにつれて、0 <ct_abs - dt_abs <safe。この範囲では、任意の中間ノードは期限が満了したことを検出できます。CT_ABSがDT_ABSを越えて増加するにつれて、締め切り時間が期限切れになったかどうかを確実に決定することはもはや確実に決定することはもはや不可能である。これらのステートメントは、モジュラス2 ^ nのモジュラ演算に縮小するときにも適用されます。
In particular, the test condition no longer allows detection of deadline expiration when the current time becomes later than (DT_abs+Safe). In order to maintain correctness even for packets that are forwarded after expiration (i.e., the 'D' flag), N has to be chosen to be so large that the test condition will not fail -- i.e., that in all scenarios of interest, the packet will be dropped before the current time becomes equal to DT_abs+2^N*SAFETY_FACTOR.
特に、テスト条件は、現在時刻が遅くなったときの期限の有効期限の検出を（DT_ABS SAFE）の検出を可能にしない。満了後に転送されたパケット（すなわち、 'D'フラグ）でさえも正確さを維持するためには、Nは非常に大きくなるように選択されなければならず、テスト条件は失敗しない - すなわち、それはすべての対象のシナリオで、現在時刻がDT_ABS 2 ^ n * Safety_Factorに等しくなる前にパケットがドロップされます。
Acknowledgments
謝辞
The authors thank Pascal Thubert for suggesting the idea and encouraging the work. Thanks to Shwetha Bhandari's suggestions, which were instrumental in extending the timing information to heterogeneous networks. The authors acknowledge the 6TiSCH WG members for their inputs on the mailing list. Special thanks to Jerry Daniel, Dan Frost (Routing Directorate), Charlie Kaufman (Security Directorate), Seema Kumar, Tal Mizrahi, Avinash Mohan, Shalu Rajendran, Anita Varghese, and Dale Worley (General Area Review Team (Gen-ART) review) for their support and valuable feedback.
著者らはPascal Thubertに感謝し、そのアイデアを提案し、その仕事を奨励しています。Shwetha Bhandariの提案に感謝し、これはタイミング情報を異種ネットワークに拡張するのに役立ちました。著者らは、メーリングリスト上の入力のために6tisch WGメンバーを確認します。Jerry Daniel、Dan Frost（Routing Distrantate）、Charlie Kaufman（セキュリティディレクトリ）、シャルミズラヒ、Avinash Mohan、Shalu Rajendran、Anita Varghese、Dale Worgey（General Area Review Team（Gen-Art）レビュー）彼らの支持と貴重なフィードバックのために。
Authors' Addresses
著者の住所
Lijo Thomas Centre for Development of Advanced Computing Vellayambalam Trivandrum 695033 India
Lijo Thomas Advanced Computing Vellayambalam Trivandrum 695033 India
Email: lijo@cdac.in
Satish Anamalamudi SRM University-AP Amaravati Campus Amaravati, Andhra Pradesh 522 502 India
Satish Anamalamudi SRM University-AP Amaravati Campus Amaravati、Andhra Pradesh 522 502 India
Email: satishnaidu80@gmail.com
S.V.R. Anand Indian Institute of Science Bangalore 560012 India
S.v.r.インドの科学研究所バンガロール560012インド
Email: anandsvr@iisc.ac.in
Malati Hegde Indian Institute of Science Bangalore 560012 India
マラティヘッツインド科学研究所バンガロール560012インド
Email: malati@iisc.ac.in
Charles E. Perkins Lupin Lodge 20600 Aldercroft Heights Rd. Los Gatos, CA 95033 United States of America
Charles E. Perkins Lupine Lodge 20600 Aldercroft Heights RD。ロスガトス、CA 95033アメリカ合衆国
Email: charliep@computer.org