[要約] RFC 9441 は、SCHC Compound Acknowledgement (ACK) メッセージ形式と手順を定義し、SCHC ACKの回数を減らすことを目的としています。これは、複数のウィンドウのビットマップを1つのSCHCメッセージに蓄積することで、ACK-on-Errorモードでの応答送信回数を削減します。
Internet Engineering Task Force (IETF) JC. Zúñiga
Request for Comments: 9441 Cisco
Updates: 8724, 9363 C. Gomez
Category: Standards Track S. Aguilar
ISSN: 2070-1721 Universitat Politècnica de Catalunya
L. Toutain
IMT-Atlantique
S. Céspedes
Concordia University
D. Wistuba
NIC Labs, Universidad de Chile
July 2023
This document updates the Static Context Header Compression (SCHC) and fragmentation protocol (RFC 8724) and the corresponding YANG module (RFC 9363). It defines a SCHC Compound Acknowledgement (ACK) message format and procedure, which are intended to reduce the number of response transmissions (i.e., SCHC ACKs) in the ACK-on-Error Mode, by accumulating bitmaps of several windows in a single SCHC message (i.e., the SCHC Compound ACK).
このドキュメントでは、静的コンテキストヘッダー圧縮（SCHC）および断片化プロトコル（RFC 8724）と対応するYangモジュール（RFC 9363）を更新します。SCHC化合物（ACK）メッセージ形式と手順を定義します。これは、ACKオンエラーモードでの応答トランスミッションの数（つまり、SCHC ACK）を1つのSCHCメッセージに複数のウィンドウのビットマップを蓄積することにより減少させることを目的としています。（つまり、SCHC化合物ACK）。
Both the message format and procedure are generic, so they can be used, for instance, by any of the four Low-Power Wide Area Network (LPWAN) technologies defined in RFC 8376, which are Sigfox, Long Range Wide Area Network (LoRaWAN), Narrowband Internet of Things (NB-IoT), and IEEE 802.15.4w.
メッセージ形式と手順の両方が一般的なものであるため、たとえば、RFC 8376で定義された4つの低電力ワイドエリアネットワーク（LPWAN）テクノロジーのいずれかが使用できます。、狭帯域インターネットのインターネット（NB-OIT）、およびIEEE 802.15.4W。
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/rfc9441.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9441で取得できます。
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2023 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
2. Terminology
3. SCHC Compound ACK
3.1. SCHC Compound ACK Message Format
3.2. SCHC Compound ACK Behavior
3.2.1. ACK-on-Error Mode (Replaces Section 8.4.3, RFC 8724)
4. SCHC Compound ACK Example
5. SCHC Compound ACK YANG Data Model
5.1. SCHC YANG Data Model Extension
5.2. SCHC YANG Tree Extension
6. SCHC Compound ACK Parameters
7. Security Considerations
8. IANA Considerations
8.1. URI Registration
8.2. YANG Module Name Registration
9. References
9.1. Normative References
9.2. Informative References
Acknowledgements
Authors' Addresses
The Generic Framework for Static Context Header Compression (SCHC) and Fragmentation specification [RFC8724] describes two mechanisms: i) a protocol header compression scheme and ii) a frame fragmentation and loss recovery functionality. Either can be used on top of radio technologies, such as the four Low-Power Wide Area Networks (LPWANs) listed in [RFC8376], which are Sigfox, LoRaWAN, NB-IoT, and IEEE 802.15.4w. These LPWANs have similar characteristics, such as star-oriented topologies, network architecture, and connected devices with built-in applications.
静的コンテキストヘッダー圧縮（SCHC）およびフラグメンテーション仕様[RFC8724]の一般的なフレームワークは、2つのメカニズムを説明しています。I）プロトコルヘッダー圧縮スキームとii）フレームフラグメンテーションおよび損失回収機能。どちらも、[RFC8376]にリストされている4つの低電力幅広エリアネットワーク（LPWAN）など、Sigfox、Lorawan、NB-iot、およびIEEE 802.15.4Wなどのラジオテクノロジーの上に使用できます。これらのLPWANには、星指向のトポロジ、ネットワークアーキテクチャ、組み込みのアプリケーションを備えた接続されたデバイスなど、同様の特性があります。
SCHC offers a great level of flexibility to accommodate all these LPWAN technologies. Even though there are a number of similarities between them, some differences exist with respect to the transmission characteristics, payload sizes, etc. Hence, there are optimal parameters and modes of operation that can be used when SCHC is used on top of a specific LPWAN technology.
SCHCは、これらすべてのLPWANテクノロジーに対応するための優れたレベルの柔軟性を提供します。それらの間には多くの類似点がありますが、伝送特性、ペイロードサイズなどに関していくつかの違いがあります。したがって、特定のLPWANの上でSCHCを使用するときに使用できる最適なパラメーターと動作モードがあります。テクノロジー。
In ACK-on-Error mode in [RFC8724], the SCHC Packet is fragmented into pieces called tiles, where all tiles are the same size except for the last one, which can be smaller. Successive tiles are grouped in windows of fixed size. A SCHC Fragment carries one or several contiguous tiles, which may span multiple windows. When sending all tiles from all windows, the last tile is sent in an All-1 SCHC Fragment. The SCHC receiver will send a SCHC ACK reporting on the reception of exactly one window of tiles after receiving the All-1 SCHC Fragment. In case of SCHC Fragment losses, a bitmap is added to the failure SCHC ACK, where each bit in the bitmap corresponds to a tile in the window. If SCHC Fragment losses span multiple windows, the SCHC receiver will send one failure SCHC ACK per window with losses.
[RFC8724]のACKオンエラーモードでは、SCHCパケットはタイルと呼ばれる断片に断片化されています。ここでは、すべてのタイルは最後のタイルを除いて同じサイズで、小さくなります。連続したタイルは、固定サイズの窓にグループ化されています。SCHCフラグメントには、複数のウィンドウにまたがる1つまたは複数の連続したタイルが搭載されています。すべてのウィンドウからすべてのタイルを送信するとき、最後のタイルはAll-1 SCHCフラグメントで送信されます。SCHCレシーバーは、ALL-1 SCHCフラグメントを受け取った後、タイルの1つのウィンドウの受信に関するSCHC ACKの報告を送信します。SCHCフラグメントの損失の場合、ビットマップが故障SCHC ACKに追加され、ビットマップ内の各ビットはウィンドウのタイルに対応します。SCHCフラグメントの損失が複数のウィンドウに及ぶ場合、SCHCレシーバーは損失を伴うウィンドウごとに1つの障害SCHC ACKを送信します。
This document updates the SCHC protocol for frame fragmentation and loss recovery. It defines a SCHC Compound ACK format and procedure, which are intended to reduce the number of response transmissions (i.e., SCHC ACKs) in the ACK-on-Error mode of SCHC. The SCHC Compound ACK extends the failure SCHC ACK message format so that it can contain several bitmaps, with each bitmap being identified by its corresponding window number. The SCHC Compound ACK is backwards compatible with the SCHC ACK as defined in [RFC8724], and introduces flexibility, as the receiver has the capability to respond to the All-0 SCHC Fragment, providing more Downlink opportunities and therefore adjusting to the delay requirements of the application.
このドキュメントは、フレームの断片化と損失回復のためのSCHCプロトコルを更新します。SCHC化合物のACK形式と手順を定義します。これは、SCHCのACKオンエラーモードでの応答伝達（SCHC ACK）の数を減らすことを目的としています。SCHCコンパウンドACKは、障害SCHC ACKメッセージ形式を拡張して、いくつかのビットマップを含めることができ、各ビットマップは対応するウィンドウ番号によって識別されます。SCHC化合物ACKは、[RFC8724]で定義されているSCHC ACKと逆方向に互換性があり、受信機にはALL-0 SCHCフラグメントに応答し、ダウンリンクの機会を提供し、したがって、遅延要件を提供する能力があるため、柔軟性が導入されます。アプリケーション。
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]で説明されているように、すべて大文字の場合にのみ解釈されます。
It is assumed that the reader is familiar with the terms and mechanisms defined in [RFC8376] and [RFC8724].
読者は[RFC8376]および[RFC8724]で定義されている用語とメカニズムに精通していると想定されています。
The SCHC Compound ACK is a failure SCHC ACK message that can contain several bitmaps, with each bitmap being identified by its corresponding window number. In [RFC8724], the failure SCHC ACK message only contains one bitmap corresponding to one window. The SCHC Compound ACK extends this format, allowing more windows to be acknowledged in a single ACK and reducing the total number of failure SCHC ACK messages, especially when fragment losses are present in intermediate windows.
SCHCコンパウンドACKは、いくつかのビットマップを含めることができる障害SCHC ACKメッセージであり、各ビットマップは対応するウィンドウ番号によって識別されます。[RFC8724]では、障害SCHC ACKメッセージには、1つのウィンドウに対応する1つのビットマップのみが含まれています。SCHCコンパウンドACKはこの形式を拡張し、単一のACKでより多くのウィンドウを認識できるようにし、特に中間ウィンドウにフラグメント損失が存在する場合、障害ACKメッセージの総数を減らします。
The SCHC Compound ACK MAY be used in fragmentation modes that use windows and that allow reporting the bitmaps of multiple windows at the same time; otherwise, the SCHC Compound ACK MUST NOT be used.
SCHC化合物ACKは、Windowsを使用し、複数のWindowsのビットマップを同時に報告できる断片化モードで使用できます。それ以外の場合、SCHC化合物ACKを使用してはなりません。
The SCHC Compound ACK:
SCHC化合物ACK：
* provides feedback only for windows with fragment losses,
* フラグメント損失のあるWindowsのみにフィードバックを提供します、
* has a variable size that depends on the number of windows with fragment losses being reported in the single SCHC Compound ACK,
* 単一のSCHC化合物ACKでフラグメント損失が報告されているウィンドウの数に依存する可変サイズがあります。
* includes the window number (i.e., W) of each bitmap,
* 各ビットマップのウィンドウ番号（つまり、w）が含まれています。
* might not cover all windows with fragment losses of a SCHC Packet, and
* SCHCパケットのフラグメント損失ですべてのウィンドウをカバーするわけではありません。
* is distinguishable from the SCHC Receiver-Abort.
* SCHCレシーバーアボートと区別できます。
Figure 1 shows the success SCHC ACK format, i.e., when all fragments have been correctly received (C=1), as defined in [RFC8724].
図1は、[RFC8724]で定義されているように、すべてのフラグメントが正しく受信された場合（C = 1）、SCHC ACK形式の成功を示しています。
|--- SCHC ACK Header ---|
| |--T-|--M--| 1 |
+--------+----+-----+---+~~~~~~~~~~~~~~~~~~
| RuleID |DTag| W |C=1| padding as needed
+--------+----+-----+---+~~~~~~~~~~~~~~~~~~
Figure 1: SCHC Success ACK Message Format, as Defined in RFC 8724
図1：RFC 8724で定義されているSCHC成功ACKメッセージ形式
In case SCHC Fragment losses are found in any of the windows of the SCHC Packet, the SCHC Compound ACK MAY be used. The SCHC Compound ACK message format is shown in Figures 2 and 3.
SCHCパケットのいずれかのウィンドウにSCHCフラグメント損失が見つかった場合、SCHC化合物ACKを使用できます。SCHC化合物ACKメッセージ形式を図2および3に示します。
|--- SCHC ACK Header --|- W=w1 -|...|---- W=wi -----|
|--T-|---M--|-1-| |...|---M--| |---M--|
+------+----+------+---+--------+...+------+--------+------+~~~~~+
|RuleID|DTag| W=w1 |C=0| Bitmap |...| W=wi | Bitmap |00..00| pad |
+------+----+------+---+--------+...+------+--------+------+~~~~~+
next L2 Word boundary ->|<-- L2 Word ->|
Figure 2: SCHC Compound ACK Message Format. Losses are found in windows W = w1,...,wi, where w1 < w2 <...< wi.
図2：SCHCコンパウンドACKメッセージ形式。損失はWindows w = w1、...、wi、w1 <w2 <... <wiで見つかります。
The SCHC Compound ACK groups the window number (W) with its corresponding bitmap. Window numbers do not need to be contiguous. However, the window numbers and their corresponding bitmaps included in the SCHC Compound ACK message MUST be ordered from the lowest-numbered to the highest-numbered window. Hence, if the bitmap of window number zero is present in the SCHC Compound ACK message, it MUST always be the first one in order and its window number MUST be placed in the SCHC ACK Header.
SCHC化合物ACKは、対応するビットマップでウィンドウ番号（W）をグループ化します。ウィンドウ番号は隣接する必要はありません。ただし、SCHCコンパウンドACKメッセージに含まれるウィンドウ番号と対応するビットマップは、最も低い数字のウィンドウから最高の数のウィンドウから注文する必要があります。したがって、ウィンドウ番号ゼロのビットマップがSCHCコンパウンドACKメッセージに存在する場合、それは常に最初の順序である必要があり、そのウィンドウ番号はSCHC ACKヘッダーに配置する必要があります。
If M or more padding bits would be needed after the last bitmap in the message to fill the last layer two (L2) Word, M bits at 0 MUST be appended after the last bitmap, and then padding is applied as needed (see Figure 2). Since window number 0 (if present in the message) is placed as w1, the M bits set to zero can't be confused with window number 0; therefore, they signal the end of the SCHC Compound ACK message.
メッセージの最後のビットマップの後にM以上のパディングビットが必要になる場合、最後のレイヤー2（L2）ワードを埋めるために、0のMビットは最後のビットマップの後に追加する必要があり、必要に応じてパディングを適用する必要があります（図2を参照してください。）。ウィンドウ番号0（メッセージに存在する場合）はW1として配置されるため、ゼロに設定されたMビットをウィンドウ番号0と混同することはできません。したがって、それらはSCHC化合物ACKメッセージの終わりを通知します。
Figure 3 shows the case when the required padding bits are strictly less than M bits. In this case, the L2 Maximum Transmission Unit (MTU) does not leave room for any extra window value, let alone any bitmap, thereby signaling the end of the SCHC Compound ACK message.
図3は、必要なパディングビットがMビットより厳密に少ない場合の場合を示しています。この場合、L2 Maximum Transmission Unit（MTU）は、ビットマップはもちろんのこと、追加のウィンドウ値の余地を残すことはありません。
|--- SCHC ACK Header --|- W=w1 -|...|---- W=wi -----|
|--T-|---M--|-1-| |...|---M--| |---M--|
+------+----+------+---+--------+...+------+--------+~~~+
|RuleID|DTag| W=w1 |C=0| Bitmap |...| W=wi | Bitmap |pad|
+------+----+------+---+--------+...+------+--------+~~~+
next L2 Word boundary ->|
Figure 3: SCHC Compound ACK Message Format with Less than M Padding Bits. Losses are found in windows W = w1,...,wi, where w1 < w2 <...< wi.
図3：M未満のパディングビットを持つSCHCコンパウンドACKメッセージ形式。損失はWindows w = w1、...、wi、w1 <w2 <... <wiで見つかります。
The SCHC Compound ACK MUST NOT use the Compressed Bitmap format for intermediate windows/bitmaps (i.e., bitmaps that are not the last one of the SCHC Compound ACK message); therefore, intermediate bitmap fields MUST be of size WINDOW_SIZE. Hence, the SCHC Compound ACK MAY use a Compressed Bitmap format only for the last bitmap in the message. The optional usage of this Compressed Bitmap for the last bitmap MUST be specified by the technology-specific SCHC Profile.
SCHCコンパウンドACKは、中間Windows/ビットマップ（つまり、SCHCコンパウンドACKメッセージの最後の1つではないビットマップ）に圧縮ビットマップ形式を使用してはなりません。したがって、中間ビットマップフィールドはサイズのwindow_sizeでなければなりません。したがって、SCHCコンパウンドACKは、メッセージの最後のビットマップに対してのみ圧縮ビットマップ形式を使用できます。最後のビットマップのこの圧縮ビットマップのオプションの使用は、テクノロジー固有のSCHCプロファイルによって指定する必要があります。
The case where the last bitmap is effectively compressed corresponds to Figure 3, with the last bitmap ending (by construction) on an L2 Word boundary, therefore resulting in no padding at all.
最後のビットマップが効果的に圧縮されている場合は、図3に対応し、最後のビットマップはL2ワード境界で終了するため、パディングはまったくありません。
Figure 4 illustrates a bitmap compression example of a SCHC Compound ACK, where the bitmap of the last window (wi) indicates that the first tile has not been correctly received. Because the compression algorithm resulted in effective compression, no padding is needed.
図4は、SCHC化合物ACKのビットマップ圧縮の例を示しています。最後のウィンドウ（WI）のビットマップは、最初のタイルが正しく受信されていないことを示しています。圧縮アルゴリズムは効果的な圧縮をもたらしたため、パディングは必要ありません。
|--- SCHC ACK Header --|- W=w1 -|...|-------- W=wi -------|
|--T-|---M--|-1-| |...|---M--|
+------+----+------+---+--------+...+------+--------------+
|RuleID|DTag| W=w1 |C=0| Bitmap |...| W=wi |0 1 1 1 1 1 1 |
+------+----+------+---+--------+...+------+--------------+
next L2 Word boundary ->|
SCHC Compound ACK with Uncompressed Bitmap
|--- SCHC ACK Header --|- W=w1 -|...|-- W=wi --|
|--T-|---M--|-1-| |...|---M--|
+------+----+------+---+--------+...+------+---+
|RuleID|DTag| W=w1 |C=0| Bitmap |...| W=wi |0 1|
+------+----+------+---+--------+...+------+---+
next L2 Word boundary ->|
Transmitted SCHC Compound ACK with Compressed Bitmap
Figure 4: SCHC Compound ACK Message Format with Compressed Bitmap and No Padding Added. Losses are found in windows W = w1,...,wi, where w1 < w2 <...< wi.
図4：圧縮ビットマップを備えたSCHCコンパウンドACKメッセージ形式とパディングが追加されていません。損失はWindows w = w1、...、wi、w1 <w2 <... <wiで見つかります。
Figure 5 illustrates another bitmap compression example of a SCHC Compound ACK, where the bitmap of the last window (wi) indicates that the second and the fourth tiles have not been correctly received. In this example, the compression algorithm does not result in effective compression of the last bitmap. Besides, because more than M bits of padding would be needed to fill the last L2 Word, M bits at 0 are appended to the message before padding is applied.
図5は、SCHC化合物ACKの別のビットマップ圧縮の例を示しています。最後のウィンドウ（WI）のビットマップは、2番目と4番目のタイルが正しく受信されていないことを示しています。この例では、圧縮アルゴリズムは最後のビットマップの効果的な圧縮をもたらさない。また、最後のL2ワードを埋めるには、Mビット以上のパディングが必要になるため、パディングが適用される前に、0のMビットがメッセージに追加されます。
|--- SCHC ACK Header --|-W=w1-|...|-------- W=wi -------|
|--T-|---M--|-1-| |...|---M--|
+------+----+------+---+------+...+------+--------------+
|RuleID|DTag| W=w1 |C=0|Bitmap|...| W=wi |1 0 1 0 1 1 1 |
+------+----+------+---+------+...+------+--------------+
next L2 Word boundary ->|
SCHC Compound ACK with Uncompressed Bitmap
|--- SCHC ACK Header --|-W=w1-|...|-------- W=wi -------|
|--T-|---M--|-1-| |...|---M--| |---M--|
+------+----+------+---+------+...+------+--------------+------+~~~+
|RuleID|DTag| W=w1 |C=0|Bitmap|...| W=wi |1 0 1 0 1 1 1 |00..00|pad|
+------+----+------+---+------+...+------+--------------+------+~~~+
next L2 Word boundary ->|<------ L2 Word ------>|
Transmitted SCHC Compound ACK
Figure 5: SCHC Compound ACK Message Format with Compressed Bitmap and Padding Added to Reach the L2 Boundary. Losses are found in windows W = w1,...,wi, where w1 < w2 <...<wi.
図5：L2境界に到達するために、圧縮ビットマップとパディングが追加されたSCHCコンパウンドACKメッセージ形式。損失はWindows w = w1、...、wi、w1 <w2 <... <wiで見つかります。
If a SCHC sender gets a SCHC Compound ACK with invalid window numbers, such as duplicate W values or W values not sent yet, it MUST discard the whole SCHC Compound ACK message.
SCHC送信者が、まだ送信されていない重複したW値やW値などの無効なウィンドウ番号を持つSCHCコンパウンドACKを取得した場合、SCHCコンパウンドACKメッセージ全体を破棄する必要があります。
Note that SCHC Compound ACKs are distinguishable from the Receiver-Abort message in the same way that regular SCHC ACKs are distinguishable, since the Receiver-Abort pattern never occurs in a legitimate SCHC Compound ACK [RFC8724].
SCHC化合物ACKは、正当なSCHC化合物ACK [RFC8724]でレシーバーアボートパターンが発生しないため、通常のSCHC ACKが区別できるのと同じように、レシーバーアボートメッセージと区別できることに注意してください。
The SCHC ACK-on-Error behavior is described in Section 8.4.3 of [RFC8724]. The present document slightly modifies this behavior. In the baseline SCHC specification, a SCHC ACK reports only one bitmap for the reception of exactly one window of tiles. The present SCHC Compound ACK specification extends the SCHC ACK message format so that it can contain several bitmaps, with each bitmap being identified by its corresponding window number.
SCHC ACKオンエラーの動作は、[RFC8724]のセクション8.4.3で説明されています。現在のドキュメントは、この動作をわずかに変更します。ベースラインSCHC仕様では、SCHC ACKは、タイルのちょうど1つのウィンドウを受信するために1つのビットマップのみを報告します。現在のSCHCコンパウンドACK仕様は、SCHC ACKメッセージ形式を拡張して、いくつかのビットマップを含めることができ、各ビットマップは対応するウィンドウ番号によって識別されます。
As presented in [RFC8724], the SCHC ACK format can be considered a special SCHC Compound ACK case in which it reports only the tiles of one window. Therefore, the SCHC Compound ACK is backwards compatible with the SCHC ACK format presented in [RFC8724]. The receiver can assume that the sender does not support the SCHC Compound ACK if, although the SCHC Compound ACK sent by the receiver reports losses in more than one window, the sender does not resend any tiles from windows other than the first window reported in the SCHC Compound ACK. In that case, the receiver can send SCHC Compound ACKs with only one window of tiles.
[RFC8724]で提示されているように、SCHC ACK形式は、1つのウィンドウのタイルのみを報告する特別なSCHC化合物ACKケースと見なすことができます。したがって、SCHC化合物ACKは、[RFC8724]で提示されたSCHC ACK形式と後方互換性があります。受信者は、受信者によって送信されたSCHC化合物ACKが複数のウィンドウで損失を報告している場合、送信者がSCHC化合物ACKをサポートしないと仮定できます。SCHCコンパウンドACK。その場合、受信機はタイルのウィンドウのみでSCHCコンパウンドACKを送信できます。
Also, some flexibility is introduced with respect to [RFC8724] in that the receiver has the capability to respond (or not) to the All-0 with a SCHC Compound ACK, depending on certain parameters, like network conditions, sender buffer/cache size, and supported application delay. Note that even though the protocol allows for such flexibility, the actual decision criteria is not specified in this document. The application MUST set expiration timer values according to when the feedback is expected to be received, e.g., after the All-0 or after the All-1.
また、[RFC8724]に関しては、ネットワーク条件、送信者バッファー/キャッシュサイズなどの特定のパラメーターに応じて、受信者がSCHC化合物ACKを使用してALL-0に応答する（または対応しない）能力があるという点で、ある程度の柔軟性が導入されています。、およびサポートされたアプリケーションの遅延。プロトコルはこのような柔軟性を可能にしていても、実際の決定基準はこのドキュメントでは指定されていないことに注意してください。アプリケーションは、フィードバックが受信されると予想される場合、たとえばAll-0の後またはALL-1の後に有効期限タイマーの値を設定する必要があります。
Section 3.2.1 (and its subsections) replaces the complete Section 8.4.3 (and its subsections) of [RFC8724].
セクション3.2.1（およびそのサブセクション）は、[RFC8724]の完全なセクション8.4.3（およびそのサブセクション）を置き換えます。
The ACK-on-Error mode supports L2 technologies that have variable MTU and out-of-order delivery. It requires an L2 that provides a feedback path from the reassembler to the fragmenter. See Appendix F for a discussion on using ACK-on-Error mode on quasi-bidirectional links.
ACKオンエラーモードは、可変MTUおよび秩序外の配信を持つL2テクノロジーをサポートします。再組み立て装置からフラグメンテナーへのフィードバックパスを提供するL2が必要です。準双方向リンクでACKオンエラーモードを使用することについての議論については、付録Fを参照してください。
In ACK-on-Error mode, windows are used.
ACKオンエラーモードでは、Windowsが使用されます。
All tiles except the last one and the penultimate one MUST be of equal size, hereafter called "regular". The size of the last tile MUST be smaller than or equal to the regular tile size. Regarding the penultimate tile, a Profile MUST pick one of the following two options:
最後のタイルと最後から2番目のタイルを除くすべてのタイルは、以下「レギュラー」と呼ばれる同じサイズでなければなりません。最後のタイルのサイズは、通常のタイルサイズ以下でなければなりません。最後から2番目のタイルについては、プロファイルは次の2つのオプションのいずれかを選択する必要があります。
* The penultimate tile size MUST be the regular tile size, or
* 最後から2番目のタイルのサイズは、通常のタイルサイズでなければなりません、または
* the penultimate tile size MUST be either the regular tile size or the regular tile size minus one L2 Word.
* 最後から2番目のタイルサイズは、通常のタイルサイズまたは通常のタイルサイズから1つのL2ワードを差し引いている必要があります。
A SCHC Fragment message carries one or several contiguous tiles, which may span multiple windows. A SCHC Compound ACK reports on the reception of one window of tiles or several windows of tiles, each one identified by its window number.
SCHCフラグメントメッセージには、複数のウィンドウにまたがる1つまたは複数の連続したタイルが含まれます。SCHCコンパウンドACKは、タイルの1つのウィンドウまたはタイルのいくつかの窓の受信について報告しています。それぞれがウィンドウ番号で識別されます。
See Figure 6 (see Figure 23 of RFC 8724 (https://www.rfc-editor.org/rfc/rfc8724.html#figure-23)) for an example.
例については、図6（rfc 8724の図23（https://www.rfc-editor.org/rfc/rfc8724.html#figure-23）を参照してください）を参照してください。
+---------------------------------------------...-----------+
| SCHC Packet |
+---------------------------------------------...-----------+
Tile# | 4 | 3 | 2 | 1 | 0 | 4 | 3 | 2 | 1 | 0 | 4 | | 0 | 4 |3|
Window# |-------- 0 --------|-------- 1 --------|- 2 ... 27 -|- 28-|
SCHC Fragment msg |-----------|
Figure 6: SCHC Packet Fragmented in Tiles, ACK-on-Error Mode (Figure 23 in RFC 8724)
図6：タイルで断片化されたSCHCパケット、ACKオンエラーモード（RFC 8724の図23）
The W field is wide enough that it unambiguously represents an absolute window number. The fragment receiver sends SCHC Compound ACKs to the fragment sender about windows for which tiles are missing. No SCHC Compound ACK is sent by the fragment receiver for windows that it knows have been fully received.
Wフィールドは十分に広く、絶対的なウィンドウ数を明確に表すことができます。フラグメントレシーバーは、タイルが欠落しているWindowsについてSCHCコンパウンドアックをフラグメント送信者に送信します。完全に受信されたことがわかっているWindowsのフラグメントレシーバーによってSCHC化合物ACKは送信されません。
The fragment sender retransmits SCHC Fragments for tiles that are reported missing. It can advance to next windows even before it has ascertained that all tiles belonging to previous windows have been correctly received, and it can still later retransmit SCHC Fragments with tiles belonging to previous windows. Therefore, the sender and the receiver may operate in a decoupled fashion. The fragmented SCHC Packet transmission concludes when:
Fragment Senderは、欠落していると報告されているタイルのSchc Fragmentsを再送信します。以前のウィンドウに属するすべてのタイルが正しく受信されていることを確認する前であっても、次のウィンドウに進むことができ、後で以前のウィンドウに属するタイルを持つSCHCフラグメントを後で再送信することができます。したがって、送信者と受信機は分離された方法で動作する場合があります。断片化されたSCHCパケット伝送は次のことを終了します。
* integrity checking shows that the fragmented SCHC Packet has been correctly reassembled at the receive end, and this information has been conveyed back to the sender,
* 整合性チェックは、断片化されたSCHCパケットが受信終了時に正しく再組み立てされており、この情報が送信者に伝えられていることを示しています。
* too many retransmission attempts have been made, or
* あまりにも多くの再送信の試みがなされています
* the receiver determines that the transmission of this fragmented SCHC Packet has been inactive for too long.
* 受信機は、この断片化されたSCHCパケットの送信が長すぎると非アクティブであると判断します。
Each Profile MUST specify which RuleID value(s) corresponds to SCHC F/R messages operating in this mode.
各プロファイルは、このモードで動作するSCHC F/Rメッセージに対応するRuleID値を指定する必要があります。
The W field MUST be present in the SCHC F/R messages.
Wフィールドは、SCHC F/Rメッセージに存在する必要があります。
Each Profile, for each RuleID value, MUST define:
各プロファイルは、各RuleID値について、次のように定義する必要があります。
* the tile size (a tile does not need to be a duplicate of an L2 Word, but it MUST be at least the size of an L2 Word),
* タイルサイズ（タイルはL2ワードの複製は必要ありませんが、少なくともL2ワードのサイズでなければなりません）、
* the value of M,
* mの値、
* the value of N,
* nの値、
* the value of WINDOW_SIZE, which MUST be strictly less than 2^N,
* window_sizeの値。これは厳密に2^n未満でなければなりません。
* the size and algorithm for the RCS field,
* RCSフィールドのサイズとアルゴリズム、
* the value of T,
* tの値、
* the value of MAX_ACK_REQUESTS,
* max_ack_requestsの値、
* the expiration time of the Retransmission Timer,
* 再送信タイマーの有効期限、
* the expiration time of the Inactivity Timer,
* 非アクティブタイマーの有効期限、
* if the last tile is carried in a Regular SCHC Fragment or an All-1 SCHC Fragment (see Section 3.2.1.1 (Section 8.4.3.1 in [RFC8724]),
* 最後のタイルが通常のSCHCフラグメントまたはALL-1 SCHCフラグメントで運ばれている場合（セクション3.2.1.1（[RFC8724]のセクション8.4.3.1を参照）、
* if the penultimate tile MAY be one L2 Word smaller than the regular tile size (in this case, the regular tile size MUST be at least twice the L2 Word size),
* 最後から2番目のタイルが通常のタイルサイズよりも1つのL2ワードが1つである場合（この場合、通常のタイルサイズは少なくとも2倍のL2ワードサイズでなければなりません）、
* usage or not of the SCHC Compound ACK message, and
* SCHCコンパウンドACKメッセージの使用法かどうか、および
* usage or not of the Compressed Bitmap format in the last window of the SCHC Compound ACK message.
* SCHCコンパウンドACKメッセージの最後のウィンドウでの圧縮ビットマップ形式の使用法かどうか。
For each active pair of RuleID and DTag values, the sender MUST maintain:
Roolid値とDTAG値のアクティブなペアごとに、送信者は次のことを維持する必要があります。
* one Attempts counter and
* カウンターを試みます
* one Retransmission Timer.
* 1つの再送信タイマー。
For each active pair of RuleID and DTag values, the receiver MUST maintain:
Roolid値とDTAG値のアクティブなペアごとに、受信者は次のことを維持する必要があります。
* one Attempts counter and
* カウンターを試みます
* one Inactivity Timer.
* 1つの非アクティブタイマー。
At the beginning of the fragmentation of a new SCHC Packet:
新しいSCHCパケットの断片化の開始時に：
* the fragment sender MUST select a RuleID and DTag value pair for this SCHC Packet. A Rule MUST NOT be selected if the values of M and WINDOW_SIZE for that Rule are such that the SCHC Packet cannot be fragmented in (2^M) * WINDOW_SIZE tiles or less.
* フラグメント送信者は、このSCHCパケットのRuleIDおよびDTAG値ペアを選択する必要があります。そのルールのmとwindow_sizeの値が、（2^m） * window_sizeタイル以下で断片化できないようなものである場合、ルールを選択しないでください。
* the fragment sender MUST initialize the Attempts counter to 0 for that RuleID and DTag value pair.
* フラグメント送信者は、そのRoolIDおよびDTAG値ペアに対して、試行カウンターを0に初期化する必要があります。
A Regular SCHC Fragment message carries in its payload one or more tiles. If more than one tile is carried in one Regular SCHC Fragment:
通常のSCHCフラグメントメッセージは、1つ以上のタイルをペイロードします。複数のタイルが1つの通常のSCHCフラグメントで運ばれている場合：
* the selected tiles MUST be contiguous in the original SCHC Packet, and
* 選択したタイルは、元のSCHCパケットで隣接する必要があり、
* they MUST be placed in the SCHC Fragment Payload adjacent to one another, in the order they appear in the SCHC Packet, from the start of the SCHC Packet toward its end.
* それらは、SCHCパケットの開始からその端に向かって、SCHCパケットに表示される順に、互いに隣接するSCHCフラグメントペイロードに配置する必要があります。
Tiles that are not the last one MUST be sent in Regular SCHC Fragments as specified in Section 8.3.1.1. The FCN field MUST contain the tile index of the first tile sent in that SCHC Fragment.
最後のタイルではないタイルは、セクション8.3.1.1で指定されているように、通常のSCHCフラグメントで送信する必要があります。FCNフィールドには、そのSCHCフラグメントに送信された最初のタイルのタイルインデックスを含める必要があります。
In a Regular SCHC Fragment message, the sender MUST fill the W field with the window number of the first tile sent in that SCHC Fragment.
通常のSCHCフラグメントメッセージでは、送信者はそのSCHCフラグメントに送信された最初のタイルのウィンドウ番号でWフィールドを埋める必要があります。
A Profile MUST define if the last tile of a SCHC Packet is sent:
SCHCパケットの最後のタイルが送信されるかどうかをプロファイルに定義する必要があります。
* in a Regular SCHC Fragment, alone or as part of a multi-tiles Payload,
* 単独またはマルチタイルのペイロードの一部として、通常のSCHCフラグメントで、
* alone in an All-1 SCHC Fragment, or
* All-1 Schcフラグメントでのみ、または
* with either one of the above two methods.
* 上記の2つの方法のいずれかを使用します。
In an All-1 SCHC Fragment message, the sender MUST fill the W field with the window number of the last tile of the SCHC Packet.
ALL-1 SCHCフラグメントメッセージでは、送信者はSCHCパケットの最後のタイルのウィンドウ番号でWフィールドを埋める必要があります。
The fragment sender MUST send SCHC Fragments such that, all together, they contain all the tiles of the fragmented SCHC Packet.
フラグメント送信者は、すべてが一緒になって、断片化されたSCHCパケットのすべてのタイルが含まれるようにSCHCフラグメントを送信する必要があります。
The fragment sender MUST send at least one All-1 SCHC Fragment.
フラグメント送信者は、少なくとも1つのすべてのSCHCフラグメントを送信する必要があります。
In doing the two items above, the sender MUST ascertain that the receiver will not receive the last tile through both a Regular SCHC Fragment and an All-1 SCHC Fragment.
上記の2つの項目を実行する際、送信者は、レシーバーが通常のSCHCフラグメントとALL-1 SCHCフラグメントの両方を介して最後のタイルを受け取らないことを確認する必要があります。
The fragment sender MUST listen for SCHC Compound ACK messages after having sent:
フラグメント送信者は、送信した後、SCHCコンパウンドACKメッセージを聞く必要があります。
* an All-1 SCHC Fragment or
* ALL-1 SCHCフラグメントまたは
* a SCHC ACK REQ.
* schc ack req。
A Profile MAY specify other times at which the fragment sender MUST listen for SCHC Compound ACK messages. For example, this could be after sending a complete window of tiles.
プロファイルは、フラグメント送信者がSCHCコンパウンドACKメッセージを聞く必要がある他の時間を指定する場合があります。たとえば、これはタイルの完全なウィンドウを送信した後の可能性があります。
Each time a fragment sender sends an All-1 SCHC Fragment or a SCHC ACK REQ:
フラグメント送信者がALL-1 SCHCフラグメントまたはSCHC ACK REQを送信するたびに：
* it MUST increment the Attempts counter, and
* Tirams Counterを増やす必要があります
* it MUST reset the Retransmission Timer.
* 再送信タイマーをリセットする必要があります。
On Retransmission Timer expiration:
再送信タイマーの有効期限：
* if the Attempts counter is strictly less than MAX_ACK_REQUESTS, the fragment sender MUST send either the All-1 SCHC Fragment or a SCHC ACK REQ with the W field corresponding to the last window,
* 試行カウンターがMAX_ACK_REQUESTSよりも厳密に少ない場合、フラグメント送信者は、最後のウィンドウに対応するWフィールドでALL-1 SCHCフラグメントまたはSCHC ACK REQを送信する必要があります。
* otherwise, the fragment sender MUST send a SCHC Sender-Abort, and it MAY exit with an error condition.
* それ以外の場合、フラグメント送信者はSCHC Sender-Abortを送信する必要があり、エラー条件で終了する場合があります。
All message receptions being discussed in the rest of this section are to be understood as "matching the RuleID and DTag pair being processed", even if not spelled out, for brevity.
このセクションの残りの部分で議論されているすべてのメッセージ受信は、「処理されているRuleIDとDTAGペアを一致させる」と理解されます。
On receiving a SCHC Compound ACK:
SCHCコンパウンドACKを受信すると：
* if one of the W fields in the SCHC Compound ACK corresponds to the last window of the SCHC Packet:
* SCHC化合物ACKのWフィールドの1つが、SCHCパケットの最後のウィンドウに対応する場合：
- if the C bit is set, the sender MAY exit successfully.
- Cビットが設定されている場合、送信者は正常に終了する場合があります。
- otherwise:
- さもないと：
o if the Profile mandates that the last tile be sent in an All-1 SCHC Fragment:
o プロファイルが最後のタイルをAll-1 SCHCフラグメントに送信することを義務付けている場合：
+ if the SCHC Compound ACK shows no missing tile at the receiver, the sender:
+ SCHC化合物ACKにレシーバーに欠落しているタイルが表示されない場合、送信者：
* MUST send a SCHC Sender-Abort and
* Schc Sender-Abortを送信する必要があります
* MAY exit with an error condition.
* エラー状態で終了する場合があります。
+ otherwise:
+ さもないと：
* the fragment sender MUST send SCHC Fragment messages containing all the tiles of all the windows that are reported missing in the SCHC Compound ACK.
* フラグメント送信者は、SCHC化合物ACKに欠落していると報告されているすべてのウィンドウのすべてのタイルを含むSCHCフラグメントメッセージを送信する必要があります。
* if the last of these SCHC Fragment messages is not an All-1 SCHC Fragment, then the fragment sender MAY either send, in addition, a SCHC ACK REQ with the W field corresponding to the last window or repeat the All-1 SCHC Fragment to ask the receiver to confirm that all tiles have been correctly received.
* これらのSCHCフラグメントメッセージの最後のメッセージがAll-1 SCHCフラグメントではない場合、フラグメント送信者は、最後のウィンドウに対応するWフィールドを持つSCHC ACK REQを送信するか、ALL-1 SCHCフラグメントを繰り返すことができます。すべてのタイルが正しく受信されていることを確認するように受信者に依頼します。
* in doing the two items above, the sender MUST ascertain that the receiver will not receive the last tile through both a Regular SCHC Fragment and an All-1 SCHC Fragment.
* 上記の2つの項目を実行する際、送信者は、レシーバーが通常のSCHCフラグメントとALL-1 SCHCフラグメントの両方を介して最後のタイルを受け取らないことを確認する必要があります。
o otherwise:
o さもないと：
+ if the SCHC Compound ACK shows no missing tile at the receiver, the sender MUST send the All-1 SCHC Fragment
+ SCHC化合物ACKが受信機に欠落しているタイルを表示しない場合、送信者はAll-1 SCHCフラグメントを送信する必要があります
+ otherwise:
+ さもないと：
* the fragment sender MUST send SCHC Fragment messages containing all the tiles that are reported missing in the SCHC Compound ACK.
* フラグメント送信者は、SCHC化合物ACKに欠落していると報告されているすべてのタイルを含むSCHCフラグメントメッセージを送信する必要があります。
* the fragment sender MUST then send either the All-1 SCHC Fragment or a SCHC ACK REQ with the W field corresponding to the last window.
* フラグメント送信者は、最後のウィンドウに対応するWフィールドを使用して、All-1 SCHCフラグメントまたはSCHC ACK REQを送信する必要があります。
* otherwise, the fragment sender:
* それ以外の場合、フラグメント送信者：
- MUST send SCHC Fragment messages containing the tiles that are reported missing in the SCHC Compound ACK.
- SCHC化合物ACKに欠落していると報告されているタイルを含むSCHCフラグメントメッセージを送信する必要があります。
- then, it MAY send a SCHC ACK REQ with the W field corresponding to the last window.
- 次に、最後のウィンドウに対応するWフィールドでSCHC ACK REQを送信する場合があります。
See Figure 43 (https://www.rfc-editor.org/rfc/rfc8724.html#figure-43) for one among several possible examples of a Finite State Machine implementing a sender behavior obeying this specification.
図43（https://www.rfc-editor.org/rfc/rfc8724.html#figure-43）を参照してください。
On receiving a SCHC Fragment with a RuleID and DTag pair not being processed at that time:
その時点で処理されていないRureIDとDTAGペアを使用してSCHCフラグメントを受信すると：
* the receiver SHOULD check that the DTag value has not recently been used for that RuleID value, thereby ensuring that the received SCHC Fragment is not a remnant of a prior fragmented SCHC Packet transmission. The initial value of the Inactivity Timer is the RECOMMENDED lifetime for the DTag value at the receiver. If the SCHC Fragment is determined to be such a remnant, the receiver MAY silently ignore it and discard it.
* 受信者は、DTAG値が最近そのRuleID値に使用されていないことを確認する必要があります。これにより、受信したSCHCフラグメントが以前の断片化されたSCHCパケット伝送の残りではないことを確認する必要があります。非アクティブタイマーの初期値は、レシーバーのDTAG値に推奨される寿命です。SCHCフラグメントがそのような残骸であると判断された場合、受信者は静かにそれを無視して廃棄することがあります。
* the receiver MUST start a process to assemble a new SCHC Packet with that RuleID and DTag value pair. The receiver MUST start an Inactivity Timer for that RuleID and DTag value pair. It MUST initialize an Attempts counter to 0 for that RuleID and DTag value pair. If the receiver is under-resourced to do this, it MUST respond to the sender with a SCHC Receiver-Abort.
* 受信者は、そのRuleIDおよびDTAG値ペアで新しいSCHCパケットを組み立てるプロセスを開始する必要があります。受信者は、そのRoolIDおよびDTAG値ペアの非アクティブタイマーを起動する必要があります。RureIDおよびDTAG値ペアの試行カウンターを0に初期化する必要があります。受信者がこれを行うためにリソース不足になっている場合、SCHCレシーバー - アボートで送信者に応答する必要があります。
On reception of any SCHC F/R message for the RuleID and DTag pair being processed, the receiver MUST reset the Inactivity Timer pertaining to that RuleID and DTag pair.
処理中のRuleIDおよびDTAGペアのSCHC F/Rメッセージを受信すると、受信者はそのRuleIDとDTAGペアに関連する非アクティブタイマーをリセットする必要があります。
All message receptions being discussed in the rest of this section are to be understood as "matching the RuleID and DTag pair being processed", even if not spelled out, for brevity.
このセクションの残りの部分で議論されているすべてのメッセージ受信は、「処理されているRuleIDとDTAGペアを一致させる」と理解されます。
On receiving a SCHC Fragment message, the receiver determines what tiles were received, based on the payload length and on the W and FCN fields of the SCHC Fragment.
SCHCフラグメントメッセージを受信すると、受信機は、ペイロード長とSCHCフラグメントのWおよびFCNフィールドに基づいて、受信したタイルを決定します。
* if the FCN is All-1 and if a Payload is present, the full SCHC Fragment Payload MUST be assembled including the padding bits. This is because the size of the last tile is not known by the receiver; therefore, padding bits are indistinguishable from the tile data bits, at this stage. They will be removed by the SCHC C/D sublayer. If the size of the SCHC Fragment Payload exceeds or equals the size of one regular tile plus the size of an L2 Word, this SHOULD raise an error flag.
* FCNがAll-1の場合、ペイロードが存在する場合、パディングビットを含む完全なSCHCフラグメントペイロードを組み立てる必要があります。これは、最後のタイルのサイズがレシーバーによって知られていないためです。したがって、この段階では、パディングビットはタイルデータビットと区別できません。それらはSCHC C/Dサブレイヤーによって削除されます。SCHCフラグメントペイロードのサイズが1つの通常のタイルのサイズとL2ワードのサイズを超えたり等しい場合、これによりエラーフラグが上昇します。
* otherwise, tiles MUST be assembled based on the a priori known tile size.
* それ以外の場合、タイルは、先験的に既知のタイルサイズに基づいて組み立てる必要があります。
- If allowed by the Profile, the end of the payload MAY contain the last tile, which may be shorter. Padding bits are indistinguishable from the tile data bits, at this stage.
- プロファイルで許可されている場合、ペイロードの端に最後のタイルが含まれている場合があり、短くなる場合があります。この段階では、パディングビットはタイルデータビットと区別できません。
- The payload may contain the penultimate tile that, if allowed by the Profile, MAY be exactly one L2 Word shorter than the regular tile size.
- ペイロードには、プロファイルによって許可されている場合、通常のタイルサイズよりも1つのL2ワードが1つ短い場合がある2番目のタイルが含まれている場合があります。
- Otherwise, padding bits MUST be discarded. This is possible because:
- それ以外の場合、パディングビットを破棄する必要があります。これは可能です：
o the size of the tiles is known a priori,
o タイルのサイズは先験的に知られています、
o tiles are larger than an L2 Word, and
o タイルはL2ワードよりも大きい
o padding bits are always strictly less than an L2 Word.
o パディングビットは、常にL2ワードよりも厳密に少ないです。
On receiving a SCHC All-0 SCHC Fragment:
SCHC ALL-0 SCHCフラグメントを受信すると：
* if the receiver knows of any windows with missing tiles for the packet being reassembled (and depending on certain parameters, like network conditions, sender buffer/cache size, and supported application delay, among others), it MAY return a SCHC Compound ACK for the missing tiles, starting from the lowest-numbered window.
* 受信者が、パケットのタイルが不足しているウィンドウを再構築していることを知っている場合（そして、ネットワーク条件、送信者バッファ/キャッシュサイズ、サポートされているアプリケーションの遅延など、特定のパラメーターに応じて、最も低い数のウィンドウから始まるタイルがありません。
On receiving a SCHC ACK REQ or an All-1 SCHC Fragment:
SCHC ACK REQまたはALL-1 SCHCフラグメントを受信すると：
* if the receiver knows of any windows with missing tiles for the packet being reassembled, it MUST return a SCHC Compound ACK for the missing tiles, starting from the lowest-numbered window.
* 受信者が、パケットが再組み立てされているタイルが不足しているウィンドウを知っている場合、不足しているタイルのSCHCコンパウンドACKを返す必要があります。
* otherwise:
* さもないと：
- if it has received at least one tile, it MUST return a SCHC Compound ACK for the highest-numbered window it currently has tiles for,
- 少なくとも1つのタイルを受け取った場合、現在タイルがある最高の数のウィンドウのSCHCコンパウンドACKを返す必要があります。
- otherwise, it MUST return a SCHC Compound ACK for window number 0.
- それ以外の場合は、ウィンドウ番号0にSCHCコンパウンドACKを返す必要があります。
A Profile MAY specify other times and circumstances at which a receiver sends a SCHC Compound ACK and which window the SCHC Compound ACK reports about in these circumstances.
プロファイルは、レシーバーがSCHC化合物ACKを送信する他の時間と状況を指定し、これらの状況でSCHC化合物ACKが報告するウィンドウを指定する場合があります。
Upon sending a SCHC Compound ACK, the receiver MUST increase the Attempts counter.
SCHC化合物ACKを送信すると、受信者は試行カウンターを増やす必要があります。
After receiving an All-1 SCHC Fragment, a receiver MUST check the integrity of the reassembled SCHC Packet at least every time it prepares to send a SCHC Compound ACK for the last window.
ALL-1 SCHCフラグメントを受信した後、受信者は、少なくとも最後のウィンドウにSCHCコンパウンドACKを送信する準備をするたびに、再組み立てされたSCHCパケットの完全性を確認する必要があります。
Upon receiving a SCHC Sender-Abort, the receiver MAY exit with an error condition.
SCHC Sender-Abortを受信すると、レシーバーはエラー条件で終了する場合があります。
Upon expiration of the Inactivity Timer, the receiver MUST send a SCHC Receiver-Abort, and it MAY exit with an error condition.
非アクティブタイマーの有効期限が切れると、受信者はSCHCレシーバーアボートを送信する必要があり、エラー条件で終了する場合があります。
On the Attempts counter exceeding MAX_ACK_REQUESTS, the receiver MUST send a SCHC Receiver-Abort, and it MAY exit with an error condition.
MAX_ACK_REQUESTSを超える試行カウンターでは、受信者はSCHCレシーバーアボートを送信する必要があり、エラー条件で終了する場合があります。
Reassembly of the SCHC Packet concludes when:
SCHCパケットの再組み立ては次のことを締めくくります。
* a Sender-Abort has been received,
* 送信者 - アボートが受け取られました、
* the Inactivity Timer has expired,
* 非アクティブタイマーが期限切れになりました、
* the Attempts counter has exceeded MAX_ACK_REQUESTS, or
* Tirams CounterはMAX_ACK_REQUESTSを超えています
* at least an All-1 SCHC Fragment has been received and integrity checking of the reassembled SCHC Packet is successful.
* 少なくともALL-1 SCHCフラグメントが受信され、再組み立てされたSCHCパケットの整合性チェックが成功しました。
See Figure 44 (https://www.rfc-editor.org/rfc/rfc8724.html#figure-44) for one among several possible examples of a Finite State Machine implementing a receiver behavior obeying this specification. The example provided is meant to match the sender Finite State Machine of Figure 43 (https://www.rfc-editor.org/rfc/rfc8724.html#figure-43).
図44（https://www.rfc-editor.org/rfc/rfc8724.html#figure-44）を参照してください。提供されている例は、図43（https://www.rfc-editor.org/rfc/rfc8724.html#figure-43）の送信者有限状態マシンと一致することを目的としています。
Figure 7 shows an example transmission of a SCHC Packet in ACK-on-Error mode using the SCHC Compound ACK. In the example, the SCHC Packet is fragmented in 14 tiles, with N=3, WINDOW_SIZE=7, M=2, and two lost SCHC fragments. Only 1 SCHC Compound ACK is generated.
図7は、SCHC化合物ACKを使用したACKオンエラーモードでのSCHCパケットの透過例を示しています。この例では、SCHCパケットは14タイルで断片化されており、n = 3、window_size = 7、m = 2、および2つの失われたSCHCフラグメントがあります。1つのSCHC化合物ACKのみが生成されます。
Sender Receiver
|-----W=0, FCN=6 ----->|
|-----W=0, FCN=5 ----->|
|-----W=0, FCN=4 ----->|
|-----W=0, FCN=3 ----->|
|-----W=0, FCN=2 --X |
|-----W=0, FCN=1 ----->|
|-----W=0, FCN=0 ----->| Bitmap: 1111011
(no ACK)
|-----W=1, FCN=6 ----->|
|-----W=1, FCN=5 ----->|
|-----W=1, FCN=4 ----->|
|-----W=1, FCN=3 ----->|
|-----W=1, FCN=2 ----->|
|-----W=1, FCN=1 --X |
|-- W=1, FCN=7 + RCS ->| Integrity check: failure
|<--- Compound ACK ----| [C=0, W=0 - Bitmap:1111011,
|-----W=0, FCN=2 ----->| W=1 - Bitmap:1111101]
|-----W=1, FCN=1 ----->| Integrity check: success
|<--- ACK, W=1, C=1 ---| C=1
(End)
Figure 7: SCHC Compound ACK Message Sequence Example
図7：SCHC化合物ACKメッセージシーケンスの例
|--- SCHC ACK Header --|- W=00 --|----- W=01 -----|
|--T-|---M--|-1-| |---M--| |---M--|
+------+----+------+---+---------+------+---------+------+-----+
|RuleID|DTag| W=00 |C=0| 1111011 | W=01 | 1111101 | 00 | pad |
+------+----+------+---+---------+------+---------+------+-----+
next L2 Word boundary ->|<-- L2 Word ->|
Figure 8: SCHC Compound ACK Message Format Example: Losses are Found in Windows 00 and 01
図8：SCHC化合物ACKメッセージ形式の例：損失はWindows 00および01にあります
This document also extends the SCHC YANG data model defined in [RFC9363] by including a new leaf in the Ack-on-Error fragmentation mode to describe both the option to use the SCHC Compound ACK, as well as its bitmap format.
また、このドキュメントは、[RFC9363]で定義されたSCHC Yangデータモデルを拡張し、ACKオンエラーフラグメンテーションモードに新しい葉を含めて、SCHC化合物ACKを使用するオプションとそのビットマップ形式の両方を説明します。
<CODE BEGINS> file "ietf-schc-compound-ack@2023-07-26.yang"
module ietf-schc-compound-ack {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-schc-compound-ack";
prefix schc-compound-ack;
import ietf-schc {
prefix schc;
}
organization
"IETF IPv6 over Low Power Wide-Area Networks (lpwan)
Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/lpwan/about/>
WG List: <mailto:lp-wan@ietf.org>
Editor: Laurent Toutain
<mailto:laurent.toutain@imt-atlantique.fr>
Editor: Juan Carlos Zuniga
<mailto:j.c.zuniga@ieee.org>
Editor: Sergio Aguilar
<mailto:sergio.aguilar.romero@upc.edu>";
description
"Copyright (c) 2023 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to
the license terms contained in, the Revised BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC 9363
(https://www.rfc-editor.org/info/rfc9363); see the RFC itself
for full legal notices.
***************************************************************
Generic data model for the Static Context Header Compression
Rule for SCHC, based on RFCs 8724 and 8824. Including
compression, no-compression, and fragmentation Rules.";
revision 2023-07-26 {
description
"Initial version for RFC 9441.";
reference
"RFC 9441 Static Context Header Compression (SCHC) Compound
Acknowledgement (ACK)";
}
identity bitmap-format-base-type {
description
"Define how the bitmap is formed in ACK messages.";
}
identity bitmap-RFC8724 {
base bitmap-format-base-type;
description
"Bitmap by default as defined in RFC 8724.";
reference
"RFC 8724 SCHC: Generic Framework for Static Context Header
Compression and Fragmentation";
}
identity bitmap-compound-ack {
base bitmap-format-base-type;
description
"Compound ACK allows several bitmaps in an ACK message.";
}
typedef bitmap-format-type {
type identityref {
base bitmap-format-base-type;
}
description
"Type of bitmap used in Rules.";
}
augment "/schc:schc/schc:rule/schc:nature/"
+ "schc:fragmentation/schc:mode/schc:ack-on-error" {
leaf bitmap-format {
when "derived-from-or-self(../schc:fragmentation-mode,
'schc:fragmentation-mode-ack-on-error')";
type schc-compound-ack:bitmap-format-type;
default "schc-compound-ack:bitmap-RFC8724";
description
"How the bitmaps are included in the SCHC ACK message.";
}
leaf last-bitmap-compression {
when "derived-from-or-self(../schc:fragmentation-mode,
'schc:fragmentation-mode-ack-on-error')";
type boolean;
default "true";
description
"When true, the ultimate bitmap in the SCHC ACK message
can be compressed. Default behavior from RFC 8724.";
reference
"RFC 8724 SCHC: Generic Framework for Static Context Header
Compression and Fragmentation";
}
description
"Augment the SCHC Rules to manage Compound ACK.";
}
}
<CODE ENDS>
Figure 9: SCHC YANG Data Model - Compound ACK Extension
図9：SCHC YANGデータモデル - 複合ACK拡張
module: ietf-schc-compound-ack
augment /schc:schc/schc:rule/schc:nature/schc:fragmentation/
schc:mode/schc:ack-on-error:
+--rw bitmap-format? schc-compound-ack:bitmap-format-type
+--rw last-bitmap-compression? boolean
Figure 10: Tree Diagram - Compound ACK Extension
図10：ツリー図 - 複合ACK拡張
This section lists the parameters related to the SCHC Compound ACK usage that need to be defined in the Profile. This list MUST be appended to the list of SCHC parameters under "Decision to use SCHC fragmentation mechanism or not. If yes, the document must describe:" as defined in Appendix D of [RFC8724].
このセクションには、プロファイルで定義する必要があるSCHC化合物ACK使用量に関連するパラメーターをリストします。このリストは、「SCHC断片化メカニズムを使用するかどうか決定するかどうか」に基づいてSCHCパラメーターのリストに追加する必要があります。はいの場合、ドキュメントは[RFC8724]の付録Dで定義されているように説明する必要があります。
* whether the SCHC Compound ACK message is used or not, and
* SCHC化合物ACKメッセージが使用されているかどうか、そして
* whether the compressed bitmap format in the last window of the SCHC Compound ACK message is used or not.
* SCHCコンパウンドACKメッセージの最後のウィンドウの圧縮ビットマップ形式が使用されているかどうか。
This document specifies a message format extension for SCHC. Hence, the same security considerations defined in [RFC8724] and [RFC9363] apply.
このドキュメントは、SCHCのメッセージ形式拡張子を指定します。したがって、[RFC8724]および[RFC9363]で定義されている同じセキュリティ上の考慮事項が適用されます。
The YANG module specified in this document defines a schema for data that is designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC8446].
このドキュメントで指定されたYangモジュールは、NetConf [RFC6241]やRestConf [RFC8040]などのネットワーク管理プロトコルを介してアクセスするように設計されたデータのスキーマを定義しています。最低のネットコン層は安全な輸送層であり、実装から実装の安全な輸送は安全なシェル（SSH）[RFC6242]です。最も低いRESTCONF層はHTTPSであり、実装対象の安全な輸送はTLS [RFC8446]です。
The Network Configuration Access Control Model (NACM) [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content.
ネットワーク構成アクセス制御モデル（NACM）[RFC8341]は、利用可能なすべてのNetConfまたはRestConfプロトコル操作とコンテンツの事前に設定されたサブセットに特定のNetConfまたはRestConfユーザーのアクセスを制限する手段を提供します。
There are a number of data nodes defined in this YANG module that are writable/creatable/deletable (i.e., config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations. These are the subtrees and data nodes and their sensitivity/vulnerability:
このYangモジュールには、書き込み可能/クリエーション/削除可能な（つまり、デフォルトである構成真実）と定義されている多くのデータノードがあります。これらのデータノードは、一部のネットワーク環境で敏感または脆弱と見なされる場合があります。適切な保護なしにこれらのデータノードに操作を書き込む（例：編集config）は、ネットワーク操作に悪影響を与える可能性があります。これらは、サブツリーとデータノードとその感度/脆弱性です。
/schc:schc/schc:rule/schc:nature/schc:fragmentation/schc:mode/ schc:ack-on-error:
/schc：schc/schc：rule/schc：nature/schc：fragmentation/schc：mode/schc：ack-on-error：
All the data nodes may be modified. The Rule contains sensitive information, such as the SCHC F/R mode configuration and usage and SCHC Compound ACK configuration. An attacker may try to modify other devices' Rules by changing the F/R mode or the usage of the SCHC Compound ACK and may block communication or create extra ACKs. Therefore, a device must be allowed to modify only its own Rules on the remote SCHC instance. The identity of the requester must be validated. This can be done through certificates or access lists.
すべてのデータノードが変更される場合があります。このルールには、SCHC F/Rモードの構成と使用状況、SCHC化合物ACK構成などの機密情報が含まれています。攻撃者は、F/RモードまたはSCHCコンパウンドACKの使用法を変更して、他のデバイスのルールを変更しようとする場合があり、通信をブロックしたり、追加のACKを作成したりする場合があります。したがって、デバイスは、リモートSCHCインスタンスに関する独自のルールのみを変更することを許可する必要があります。要求者の身元を検証する必要があります。これは、証明書またはアクセスリストを介して実行できます。
Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. These are the subtrees and data nodes and their sensitivity/vulnerability:
このYangモジュールの読み取り可能なデータノードの一部は、一部のネットワーク環境で敏感または脆弱と見なされる場合があります。したがって、これらのデータノードへの読み取りアクセス（GET、GetConfig、または通知を介して）を制御することが重要です。これらは、サブツリーとデータノードとその感度/脆弱性です。
/schc:schc/schc:rule/schc:nature/schc:fragmentation/schc:mode/ schc:ack-on-error:
/schc：schc/schc：rule/schc：nature/schc：fragmentation/schc：mode/schc：ack-on-error：
By reading this module, an attacker may learn the F/R mode used by the device, how the device manages the bitmap creation, the buffer sizes, and when the device will request an ACK.
このモジュールを読み取ることにより、攻撃者は、デバイスで使用されるF/Rモード、デバイスがビットマップ作成の管理方法、バッファサイズ、およびデバイスがACKを要求するときに学習できます。
This document registers one URI and one YANG data model.
このドキュメントは、1つのURIと1つのYangデータモデルを登録します。
IANA registered the following URI in the "IETF XML Registry" [RFC3688]:
IANAは、「IETF XMLレジストリ」[RFC3688]に次のURIを登録しました。
URI:
URI：
urn:ietf:params:xml:ns:yang:ietf-schc-compound-ack
urn：ietf：params：xml：ns：yang：ietf-schc-compound-ack
Registrant Contact:
登録者の連絡先：
The IESG.
IESG。
XML:
XML：
N/A; the requested URI is an XML namespace.
n/a;要求されたURIはXMLネームスペースです。
IANA has registered the following YANG data model in the "YANG Module Names" registry [RFC6020].
IANAは、「Yangモジュール名」レジストリ[RFC6020]に次のYangデータモデルを登録しています。
name:
名前：
ietf-schc-compound-ack
IETF-SCHC-COMPOUND-ACK
namespace:
名前空間：
urn:ietf:params:xml:ns:yang:ietf-schc-compound-ack
urn：ietf：params：xml：ns：yang：ietf-schc-compound-ack
prefix:
プレフィックス：
schc-compound-ack
Schc-Compound-cack
reference:
参照：
RFC 9441
RFC 9441
[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>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
<https://www.rfc-editor.org/info/rfc6242>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.
[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>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/info/rfc8341>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC.
Zuniga, "SCHC: Generic Framework for Static Context Header
Compression and Fragmentation", RFC 8724,
DOI 10.17487/RFC8724, April 2020,
<https://www.rfc-editor.org/info/rfc8724>.
[RFC9363] Minaburo, A. and L. Toutain, "A YANG Data Model for Static
Context Header Compression (SCHC)", RFC 9363,
DOI 10.17487/RFC9363, March 2023,
<https://www.rfc-editor.org/info/rfc9363>.
[RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN)
Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018,
<https://www.rfc-editor.org/info/rfc8376>.
Carles Gomez has been funded in part by the Spanish Government through the TEC2016-79988-P grant and the PID2019-106808RA-I00 grant (funded by MCIN / AEI / 10.13039/501100011033) and by Secretaria d'Universitats i Recerca del Departament d'Empresa i Coneixement de la Generalitat de Catalunya through 2017 grant SGR 376 and 2021 grant SGR 00330.
Carles Gomezは、TEC2016-79988-P GrantとPID2019-106808RA-I00助成金（MCIN / AEI / 10.13039 / 501100011033によって資金提供）およびSecrecearia D'Universitats I Recerca del Departament D 'd'によるスペイン政府によって部分的に資金提供を受けています。Empresa I Coneixement de la generalitat de catalunyaから2017年の助成金Sgr 376および2021 Grant Sgr 00330。
Sergio Aguilar has been funded by the ERDF and the Spanish Government through project TEC2016-79988-P and project PID2019-106808RA-I00, AEI/FEDER, EU (funded by MCIN / AEI / 10.13039/501100011033).
Sergio Aguilarは、プロジェクトTEC2016-79988-PおよびProject PID2019-106808ra-I00、AEI / Feder、EU（MCIN / AEI / 10.13039 / 501100011033によって資金提供）を通じてERDFとスペイン政府によって資金提供されています。
Sandra Cespedes has been funded in part by the ANID Chile Project FONDECYT Regular 1201893 and Basal Project FB0008.
サンドラ・セスペデスは、Anid Chile Project Fondecyt Regular 1201893およびBasal Project FB0008によって部分的に資金提供されています。
Diego Wistuba has been funded by the ANID Chile Project FONDECYT Regular 1201893.
ディエゴ・ウィスバは、アニッド・チリ・プロジェクトFondecyt Regular 1201893によって資金提供されています。
The authors would like to thank Rafael Vidal, Julien Boite, Renaud Marty, Antonis Platis, Dominique Barthel, and Pascal Thubert for their very useful comments, reviews, and implementation design considerations.
著者は、Rafael Vidal、Julien Boite、Renaud Marty、Antonis Platis、Dominique Barthel、Pascal Thubertに、非常に有用なコメント、レビュー、実装の設計上の考慮事項に感謝します。
Juan Carlos Zúñiga
Cisco
Montreal QC
Canada
Email: juzuniga@cisco.com
Carles Gomez
Universitat Politècnica de Catalunya
C/Esteve Terradas, 7
08860 Castelldefels
Spain
Email: carles.gomez@upc.edu
Sergio Aguilar
Universitat Politècnica de Catalunya
C/Esteve Terradas, 7
08860 Castelldefels
Spain
Email: sergio.aguilar.romero@upc.edu
Laurent Toutain
IMT-Atlantique
2 rue de la Chataigneraie
CS 17607
35576 Cesson-Sevigne Cedex
France
Email: Laurent.Toutain@imt-atlantique.fr
Sandra Céspedes
Concordia University
1455 De Maisonneuve Blvd. W.
Montreal QC, H3G 1M8
Canada
Email: sandra.cespedes@concordia.ca
Diego Wistuba
NIC Labs, Universidad de Chile
Av. Almte. Blanco Encalada 1975
Santiago
Chile
Email: research@witu.cl