Internet Engineering Task Force (IETF)                     B. Varga, Ed.
Request for Comments: 9550                                     J. Farkas
Category: Informational                                         Ericsson
ISSN: 2070-1721                                                S. Kehrer
                                                                 T. Heer
                                                                  Belden
                                                              March 2024
        
Deterministic Networking (DetNet): Packet Ordering Function
決定論的ネットワーク(detNet):パケット順序機能
Abstract
概要

The replication and elimination functions of the Deterministic Networking (DetNet) architecture can result in out-of-order packets, which is not acceptable for some time-sensitive applications. The Packet Ordering Function (POF) algorithms described in this document enable restoration of the correct packet order when the replication and elimination functions are used in DetNet networks. The POF only provides ordering within the latency bound of a DetNet flow; it does not provide any additional reliability.

決定論的ネットワーキング(DETNET)アーキテクチャの複製および排除機能は、秩序外のパケットをもたらす可能性がありますが、これは時間に敏感なアプリケーションでは受け入れられません。このドキュメントで説明されているパケット順序関数(POF)アルゴリズムは、デットネットネットワークで複製および排除関数が使用されている場合に正しいパケット順序を復元できるようにします。POFは、ディットネットフローの潜伏境界内でのみ順序付けを提供します。追加の信頼性は提供されません。

Status of This Memo
本文書の位置付け

This document is not an Internet Standards Track specification; it is published for informational purposes.

このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.

このドキュメントは、インターネットエンジニアリングタスクフォース(IETF)の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ(IESG)からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、インターネット標準のあらゆるレベルの候補者であるわけではありません。RFC 7841のセクション2を参照してください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9550.

このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9550で取得できます。

著作権表示

Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.

著作権(c)2024 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ライセンステキストを含める必要があります。

Table of Contents
目次
   1.  Introduction
   2.  Terminology
     2.1.  Terms Used in This Document
     2.2.  Abbreviations
   3.  Requirements for POF Implementations
   4.  POF Algorithms
     4.1.  Prerequisites and Assumptions
     4.2.  POF Building Blocks
     4.3.  The Basic POF Algorithm
     4.4.  The Advanced POF Algorithm
     4.5.  Further Enhancements of the POF Algorithms
     4.6.  Selecting and Using the POF Algorithms
   5.  Control and Management Plane Parameters for POF
   6.  Security Considerations
   7.  IANA Considerations
   8.  References
     8.1.  Normative References
     8.2.  Informative References
   Acknowledgements
   Authors' Addresses
        
1. Introduction
1. はじめに

[RFC8655] defines the Packet Replication Function (PRF) and Packet Elimination Function (PEF) in DetNet for achieving extremely low packet loss. The PRF and PEF provide service protection for DetNet flows. This service protection method relies on copies of the same packet sent over multiple maximally disjoint paths and uses sequencing information to eliminate duplicates. A possible implementation of the PRF and PEF is described in [IEEE8021CB], and the related YANG model is defined in [IEEEP8021CBcv].

[RFC8655]は、非常に低いパケット損失を達成するために、ディットネットのパケット複製関数(PRF)とパケットエリミネーション関数(PEF)を定義します。PRFとPEFは、デットネットフローのサービス保護を提供します。このサービス保護方法は、複数の最大の分離パス上に送信された同じパケットのコピーに依存しており、シーケンス情報を使用して重複を排除します。PRFとPEFの可能な実装は[IEEE8021CB]で説明されており、関連するYangモデルは[IEEEP8021CBCV]で定義されています。

In general, use of per-packet replication and elimination functions can result in out-of-order delivery of packets, which is not acceptable for some deterministic applications. Correcting packet order is not a trivial task; therefore, details of a Packet Ordering Function (POF) are specified in this document. [RFC8655] defines the external observable result of a POF (i.e., that packets are reordered) but does not specify any implementation details.

一般に、パケットごとの複製と排除関数を使用すると、一部の決定論的アプリケーションでは受け入れられないパケットの配信が発生する可能性があります。パケット注文の修正は些細なタスクではありません。したがって、このドキュメントでは、パケット順序関数(POF)の詳細が指定されています。[RFC8655]は、POFの外部観測可能な結果を定義します(つまり、パケットは再注文されます)が、実装の詳細は指定されていません。

So far in packet networks, out-of-order delivery situations have been handled at higher OSI layers at the endpoints/hosts (e.g., in the TCP stack when packets are sent to the application layer) and not within a network in nodes acting at the Layer 2 or Layer 3 OSI layers.

これまでのところ、パケットネットワークでは、パケットがアプリケーションレイヤーに送信されるときに、エンドポイント/ホストの上位OSIレイヤー(たとえば、TCPスタックで)で、次のノードのネットワーク内ではなく、エンドポイント/ホストのより高いOSIレイヤーで処理されています。レイヤー2またはレイヤー3 OSIレイヤー。

Figure 1 shows a DetNet flow on which Packet Replication, Elimination, and Ordering Functions (PREOF) are applied during forwarding from source to destination.

図1は、ソースから宛先への転送中にパケットの複製、排除、および順序付け関数(PREOF)が適用されるディットネットフローを示しています。

                                        +------------+
                 +-----------E1----+    |            |
    +----+       |            |    +---R3---+        |          +----+
    |src |------R1        +---+             |        E3----O1---+ dst|
    +----+       |        |                 E2-------+          +----+
                 +-------R2                 |
                          +-----------------+

    R: replication point (PRF)
    E: elimination point (PEF)
    O: ordering function (POF)
        

Figure 1: PREOF Scenario in a DetNet Network

図1:Detnet NetworkのPreofシナリオ

In general, the use of PREOF requires sequencing information to be included in the packets of a DetNet compound flow. This can be done by adding a sequence number as part of DetNet encapsulation [RFC8655]. Sequencing information is typically added once, at or close to the source.

一般に、PREOFの使用には、シーケンス情報をDetnet化合物フローのパケットに含める必要があります。これは、デットネットカプセル化[RFC8655]の一部としてシーケンス番号を追加することで実行できます。通常、シーケンス情報は、ソースの1回、または近くに追加されます。

It is important to note that different applications can react differently to out-of-order delivery. A single out-of-order packet (e.g., packet order #1, #3, #2, #4, #5) is interpreted by some application as a single error, but other applications treat it as three errors in a row. For example, in industrial scenarios, three errors in a row is a typical error threshold and can cause the application to stop (e.g., go to a fail-safe state).

さまざまなアプリケーションが、注文外の配信とは異なる反応が可能であることに注意することが重要です。単一のオーバーアウトオブオーバーパケット(例:パケットオーダー#1、#3、#2、#4、#5)は、一部のアプリケーションによって単一のエラーとして解釈されますが、他のアプリケーションはそれを3つのエラーとして扱います。たとえば、産業シナリオでは、3つのエラーが典型的なエラーしきい値であり、アプリケーションが停止する可能性があります(たとえば、フェイルセーフ状態に移動します)。

The POF ensures in-order delivery for packets within the latency bound of the DetNet flow. The POF does not correct errors in the packet flow (e.g., duplicate packets or packets that are too late).

POFは、デットネットフローのレイテンシ境界内でパケットの順序配信を保証します。POFは、パケットフローのエラーを修正しません(たとえば、手遅れのパケットまたはパケットを重複させます)。

2. Terminology
2. 用語
2.1. Terms Used in This Document
2.1. このドキュメントで使用される用語

This document uses the terminology established in the DetNet architecture [RFC8655]; the reader is assumed to be familiar with that document and its terminology.

このドキュメントでは、Detnet Architecture [RFC8655]で確立された用語を使用しています。読者は、その文書とその用語に精通していると想定されています。

2.2. Abbreviations
2.2. 略語

The following abbreviations are used in this document:

このドキュメントでは、次の略語が使用されています。

DetNet

detnet

Deterministic Networking

決定論的ネットワーキング

PEF

pef

Packet Elimination Function

パケット除去関数

POF

pof

Packet Ordering Function

パケット順序機能

PREOF

preof

Packet Replication, Elimination, and Ordering Functions

パケットの複製、除去、および順序機能

PRF

PRF

Packet Replication Function

パケットレプリケーション機能

3. Requirements for POF Implementations
3. POF実装の要件

The requirements for POF implementations are:

POF実装の要件は次のとおりです。

* To solve the out-of-order delivery problem of the replication and elimination functions of DetNet networks.

* Detnet Networksの複製および排除関数の注文不足の配信問題を解決する。

* To consider the delay bound requirement of a DetNet flow.

* デットネットフローの遅延拘束要件を考慮する。

* To be simple and to require only a minimum set of states, configuration parameters, and resources per DetNet flow in network nodes.

* シンプルであり、ネットワークノードのデットネットフローごとの状態、構成パラメーター、およびリソースの最小セットのみを必要とするために。

* To add minimal or no delay to the forwarding process of packets.

* パケットの転送プロセスに最小限または遅延を追加するか、なし。

* To not require synchronization between PREOF nodes.

* preofノード間の同期を必要としない。

Some aspects are explicitly out of scope for a POF:

いくつかの側面は、POFの範囲外です。

* To eliminate the delay variation caused by the packet ordering. Dealing with delay variation is a DetNet forwarding sub-layer target, and it can be achieved, for example, by placing a de-jitter buffer or flow regulator (e.g., shaping) function after the POF.

* パケットの順序によって引き起こされる遅延変動を排除するため。遅延バリエーションを扱うことは、デットネットの転送サブレイヤーターゲットであり、たとえば、POFの後にデジターバッファーまたはフローレギュレーター(たとえば、シェーピング)関数を配置することで達成できます。

4. POF Algorithms
4. POFアルゴリズム
4.1. Prerequisites and Assumptions
4.1. 前提条件と仮定

The POF algorithms discussed in this document make some assumptions and trade-offs regarding the characteristics of the sequence of received packets. In particular, the algorithms assume that a PEF is performed on the incoming packets before they are handed to the POF. Hence, the sequence of incoming packets can be out-of-order or incomplete but cannot contain duplicate packets. However, the PREOF run independently without any state exchange required between the PEF and the POF or the PRF and the POF. Error cases in which duplicate packets are presented to the POF can lead to out-of-order delivery of duplicate packets and to increased delays.

このドキュメントで説明したPOFアルゴリズムは、受信パケットのシーケンスの特性に関していくつかの仮定とトレードオフを行います。特に、アルゴリズムは、POFに渡される前に、PEFが着信パケットで実行されると想定しています。したがって、着信パケットのシーケンスはオーダーや不完全になる可能性がありますが、重複したパケットを含めることはできません。ただし、PREOFは、PEFとPOFまたはPRFとPOFの間に必要な状態交換なしで独立して実行されます。POFに重複したパケットが表示されるエラーケースは、重複パケットの注文不足の配信と遅延の増加につながる可能性があります。

The algorithms further require that the delay difference between two replicated packets that arrive at the PEF before the POF is bounded and known. Error cases that violate this condition (e.g., a packet that arrives later than this bound) will result in out-of-order packets.

アルゴリズムではさらに、POFが境界が境界され既知になる前にPEFに到達する2つの複製されたパケット間の遅延差が必要です。この条件に違反するエラーケース(例:このバウンドよりも遅く到着するパケット)は、オーダーアウトパケットになります。

The algorithms also make some trade-offs. For simplicity, it is designed to allow for some out-of-order packets directly after initialization. If this is not acceptable, Section 4.5 provides an alternative initialization scheme that prevents out-of-order packets in the initialization phase.

アルゴリズムもいくつかのトレードオフを行います。簡単にするために、初期化の直後にいくつかのオーダーアウトパケットを可能にするように設計されています。これが受け入れられない場合、セクション4.5は、初期化フェーズでの順序外パケットを防ぐ代替の初期化スキームを提供します。

4.2. POF Building Blocks
4.2. POFビルディングブロック

The method described in this document provides a POF for DetNet networks. The configuration parameters of the POF can be derived when engineering the DetNet flow through the network.

このドキュメントで説明されている方法は、Detnet NetworksのPOFを提供します。POFの構成パラメーターは、ネットワークを介してデットネットが流れるようにするときに導出できます。

The POF method is provided via the following:

POFメソッドは、以下から提供されます。

Delay calculator:

遅延計算機:

Calculates buffering time for out-of-order packets. Buffering time considers (i) the delay difference of paths used for forwarding the replicated packets and (ii) the bounded delay requirement of the given DetNet flow.

注文不足パケットのバッファリング時間を計算します。バッファリング時間を考慮します(i)複製されたパケットの転送に使用されるパスの遅延差、および(ii)指定されたデットネットフローの境界遅延要件。

Conditional delay buffer:

条件遅延バッファ:

Used for buffering the out-of-order packets of a DetNet flow for a given time.

特定の時間の間、デットネットフローのオーダーアウトオブオーダーパケットをバッファリングするために使用されます。

Note: The conditional delay buffer of the POF increases the burstiness of the traffic as it only adds delay for some of the packets.

注:POFの条件付き遅延バッファーは、一部のパケットの遅延を追加するだけであるため、トラフィックの爆発を増加させます。

Figure 2 shows the building blocks of a possible POF implementation.

図2は、可能なPOF実装の構成要素を示しています。

                    +------------+        +--------------+
                    | Delay calc |        | Conditional  |
                 +--| for packet >--->>---| Delay Buffer >--+
                 |  +------------+        +--------------+  |
                 |                                          |
          +------^--------+                                 |
     ->>--| POF selector  >---------------------------------+-->>----
          | (Flow ident.) |
          +---------------+

     ->>- packet flow
        

Figure 2: POF Building Blocks

図2:POFビルディングブロック

4.3. The Basic POF Algorithm
4.3. アルゴリズムの基本

The basic POF algorithm delays all out-of-order packets until all previous packets arrive or a given time ("POFMaxDelay") elapses. The basic POF algorithm works as follows:

基本的なPOFアルゴリズムは、以前のすべてのパケットが到着するか、特定の時間(「pofmaxdelay」)が経過するまで、すべてのオーダーアウト外のパケットを遅らせます。基本的なPOFアルゴリズムは次のように機能します。

* The sequence number of the last forwarded packet ("POFLastSent") is stored for each DetNet flow.

* 最後に転送されたパケットのシーケンス番号(「poflastsent」)は、各デットネットフローに保存されます。

* The sequence number (seq_num) of a received packet is compared to that of the last forwarded one ("POFLastSent").

* 受信したパケットのシーケンス番号(seq_num)は、最後の転送されたパケットのシーケンス番号( "poflastsent")と比較されます。

* If (seq_num <= POFLastSent + 1)

* if(seq_num <= poflastsent + 1)

- Then the packet is forwarded without buffering, and "POFLastSent" is updated (POFLastSent = seq_num).

- その後、パケットはバッファリングなしで転送され、「poflastsent」が更新されます(poflastsent = seq_num)。

- Else, the received packet is buffered.

- そうでなければ、受信したパケットはバッファリングされます。

* A buffered packet is forwarded from the buffer when its seq_num becomes equal to "POFLastSent + 1" OR a predefined time ("POFMaxDelay") elapses.

* バッファーパケットは、そのSEQ_NUMが「Poflastsent + 1」または事前定義された時間(「pofmaxdelay」)に等しくなると、バッファーから転送されます。

* When a packet is forwarded from the buffer, "POFLastSent" is updated with its seq_num (POFLastSent = seq_num).

* バッファーからパケットが転送されると、「poflastsent」はそのseq_num(poflastsent = seq_num)で更新されます。

Notes:

ノート:

* The difference between sequence numbers in consecutive packets is bounded due to the history window of the elimination function before the POF. Therefore, "<=" can be evaluated despite the circular sequence number space. A possible implementation of the PEF and the impact of the history window are described in [IEEE8021CB].

* 連続したパケットのシーケンス番号の違いは、POFの前の除去関数の履歴ウィンドウのために制限されます。したがって、 "<="は、円形のシーケンス番号スペースにもかかわらず評価できます。PEFの可能な実装と履歴ウィンドウの影響については、[IEEE8021CB]で説明されています。

* The basic POF algorithm can be extended to cope with multiple failure scenarios (i.e., simultaneous packet loss and out-of-order packets) when the expiration of the timer for a packet with sequence number N triggers the release of some packets with a sequence number smaller than N.

* 基本的なPOFアルゴリズムは、シーケンス番号nを備えたパケットのタイマーの有効期限が有効期限を切ると、シーケンス番号を持つパケットのリリースをトリガーすると、複数の障害シナリオ(つまり、パケット損失と順序外パケット)に対処するように拡張できます。Nよりも小さい。

The state used by the basic POF algorithm (i.e., "POFLastSent") needs initialization and maintenance. This works as follows:

基本的なPOFアルゴリズム(つまり、「poflastsent」)で使用される状態には、初期化とメンテナンスが必要です。これは次のように機能します。

* The next received packet is forwarded and the "POFLastSent" updated when the POF is reset OR no packet is received for a predefined time ("POFTakeAnyTime").

* 次に受信したパケットは転送され、POFがリセットされているか、事前定義された時間(「poftakeanytime」)が受信されない場合に「poflastsent」が更新されます。

* The reset of the POF erases all packets from the time-based buffer used by the POF.

* POFのリセットは、POFが使用する時間ベースのバッファーからすべてのパケットを消去します。

The basic POF algorithm has two parameters to engineer:

基本的なPOFアルゴリズムには、エンジニアに2つのパラメーターがあります。

* "POFMaxDelay", which cannot be smaller than the delay difference of the paths used by the flow.

* 「Pofmaxdelay」。これは、フローで使用されるパスの遅延差よりも小さくすることはできません。

* "POFTakeAnyTime", which is calculated based on several factors, for example, the settings of the elimination function(s) relating to RECOVERY_TIMEOUT before the POF, the flow characteristics (e.g., inter-packet time), and the delay difference of the paths used by the flow.

* 「Poftakeanytime」は、いくつかの要因に基づいて計算されます。たとえば、POFの前のRecovery_timeout、フロー特性(例:パケット間時間)、およびパスの遅延差に関連する排除関数の設定に基づいて計算されます。フローによって使用されます。

Design of these parameters is out of scope for this document.

これらのパラメーターの設計は、このドキュメントの範囲外です。

Note: Multiple network failures can impact the POF (e.g., complete outage of all redundant paths).

注:複数のネットワーク障害は、POFに影響を与える可能性があります(たとえば、すべての冗長パスの完全な停止)。

The basic POF algorithm increases the delay of packets with maximum "POFMaxDelay" time. In-order packets are not delayed. This basic POF method can be applied in all network scenarios where the remaining delay budget of a flow at the POF point is larger than "POFMaxDelay" time.

基本的なPOFアルゴリズムは、最大の「pofmaxdelay」時間でパケットの遅延を増加させます。注文パケットは遅延しません。この基本的なPOFメソッドは、POFポイントでのフローの残りの遅延予算が「pofmaxdelay」時間よりも大きいすべてのネットワークシナリオに適用できます。

Figure 3 shows the delay budget situation at the POF point.

図3は、POFポイントの遅延予算の状況を示しています。

                             Path delay
                             difference
                           /-------------/
   <- path with min delay ->             /-- remaining delay budget --/

   |-----------------------|-------------|----------------------------|
   0                       t1            t2                           T

   <-------- path with max delay -------->

   /-------------------- delay budget at POF point -------------------/
        

Figure 3: Delay Budget Situation at the POF Point

図3:POFポイントでの予算の状況を遅らせる

4.4. The Advanced POF Algorithm
4.4. 高度なPOFアルゴリズム

In network scenarios where the remaining delay budget of a flow at the POF point is smaller than "POFMaxDelay" time, the basic method needs extensions.

POFポイントでのフローの残りの遅延予算が「Pofmaxdelay」時間よりも小さいネットワークシナリオでは、基本的な方法には拡張が必要です。

The issue is that packets on the longest path cannot be buffered in order to keep the delay budget of the flow. It must be noted that such a packet (i.e., forwarded over the longest path) needs no buffering as it is the last chance to deliver a packet with a given sequence number. This is because all replicas already arrived via a shorter path(s).

問題は、フローの遅延予算を維持するために、最長のパス上のパケットをバッファリングできないことです。そのようなパケット(つまり、最も長いパスに転送される)は、特定のシーケンス番号を持つパケットを配信する最後のチャンスであるため、バッファリングを必要としないことに注意する必要があります。これは、すべてのレプリカがすでに短いパスを介して到着したためです。

The advanced POF algorithm requires extensions of the basic POF algorithm:

高度なPOFアルゴリズムには、基本的なPOFアルゴリズムの拡張が必要です。

* to identify the received packet's path at the POF location and

* POFの場所で受信したパケットのパスを識別し、

* to make the value of "POFMaxDelay" for buffered packets path dependent ("POFMaxDelay_i", where "i" notes the path the packet has used).

* バッファリドパケットパス依存(「pofmaxdelay_i」の「pofmaxdelay」の値を作成するには、「pofmaxdelay_i」。

The advanced POF algorithm identifies the path of a given packet and uses this information to select the predefined time ("POFMaxDelay_i") to apply for the buffered packet. So, in the advanced POF algorithm, "POFMaxDelay" is an array that contains the predefined and path-specific buffering time for each redundant path of a flow. Values in the "POFMaxDelay" array are engineered to fulfill the delay budget requirement.

高度なPOFアルゴリズムは、特定のパケットのパスを識別し、この情報を使用して事前定義された時間( "pofmaxdelay_i")を選択してバッファーパケットを申請します。したがって、高度なPOFアルゴリズムでは、「PofMaxDelay」は、フローの冗長パスごとに定義されたパス固有のバッファリング時間を含む配列です。「pofmaxdelay」アレイの値は、遅延予算の要件を満たすように設計されています。

Design of these parameters is out of scope for this document.

これらのパラメーターの設計は、このドキュメントの範囲外です。

Note: For the advanced POF algorithm, the path-dependent delays might result in multiple packets triggering the "maximum delay reached" at exactly the same time. The transmission order of these packets should be done in their seq_num order.

注:高度なPOFアルゴリズムの場合、パス依存の遅延により、複数のパケットが「最大遅延に達した」とまったく同時にトリガーされる可能性があります。これらのパケットの送信順序は、seq_num順序で実行する必要があります。

The method for identifying the packet's path at the POF location depends on the network scenario. It can be implemented via various techniques, for example, using ingress interface information, encoding the path in the packet itself (e.g., replication functions set a different FlowID per member flow at their egress and such a FlowID is used to identify the path of a packet at the POF), or other means. Methods for identifying the packet's path are out of scope for this document.

POFの場所でパケットのパスを識別する方法は、ネットワークシナリオに依存します。たとえば、イングレスインターフェイス情報を使用して、パケット自体のパスをエンコードするなど、さまざまな手法を介して実装できます(たとえば、レプリケーション関数は、出力でメンバーのフローごとに異なるフローイドを設定します。POFでのパケット)、またはその他の手段。パケットのパスを識別する方法は、このドキュメントの範囲外です。

Note: When using the advanced POF algorithm, it might be advantageous to combine PEF and POF locations in the DetNet network, as this can simplify the method used for identifying the packet's path at the POF location.

注:高度なPOFアルゴリズムを使用する場合、POFの場所でのパケットのパスを識別するために使用される方法を簡素化できるため、Detnetネットワーク内のPEFとPOFの位置を組み合わせることが有利かもしれません。

4.5. Further Enhancements of the POF Algorithms
4.5. POFアルゴリズムのさらなる拡張

POF algorithms can be further enhanced by distinguishing the case of initialization from normal operation at the price of more states and more sophisticated implementation. Such enhancements could, for example, react better after some failure scenarios (e.g., complete outage of all paths of a DetNet flow) and can be dependent on the PEF implementation.

POFアルゴリズムは、より多くの州の価格とより洗練された実装の価格で、通常の操作と初期化のケースを区別することにより、さらに強化できます。たとえば、このような機能強化は、いくつかの故障シナリオ(たとえば、デットネットフローのすべてのパスの完全な停止)の後により良く反応し、PEF実装に依存する可能性があります。

The challenge for POF initialization is that it is not known whether the first received packet is in-order or out-of-order (for example, after a reset). The original initialization (see Section 4.3) considers the first packet as in-order, so out-of-order packet(s) during "POFMaxTime"/"POFMaxTime_path_i" time -- after the first packet is received -- cannot be corrected. The motivation behind such an initialization is simplicity of POF implementation.

POFの初期化の課題は、最初の受信したパケットがオーダーなしであるのか、それとも秩序外であるかがわからないことです(たとえば、リセット後)。元の初期化(セクション4.3を参照)では、最初のパケットを注文であると考慮しているため、最初のパケットを受信した後、「Pofmaxtime」/「pofmaxtime_path_i "時間」中に順序外のパケットを修正できません。このような初期化の背後にある動機は、POF実装の単純さです。

A possible enhancement of POF initialization works as follows:

POF初期化の可能性のある強化は、次のように機能します。

* After a reset, all received packets are buffered with their predefined timer ("POFMaxTime"/"POFMaxTime_path_i").

* リセット後、受信したすべてのパケットは、事前定義されたタイマー(「Pofmaxtime」/「Pofmaxtime_Path_i ")でバッファリングされます。

* No basic or advanced POF rules are applied until the first timer expires.

* 最初のタイマーが期限切れになるまで、基本的または高度なPOFルールは適用されません。

* When the first timer expires, the packet with lowest seq_num in the buffer is selected and forwarded, and "POFLastSent" is set with its seq_num.

* 最初のタイマーが期限切れになると、バッファ内の最低seq_numのパケットが選択され、転送され、「poflastsent」がそのseq_numで設定されます。

* The basic or advanced POF rules are applied for the packet(s) in the buffer and the subsequently received packets.

* 基本的または高度なPOFルールは、バッファーのパケットに適用され、その後受信したパケットに適用されます。

4.6. Selecting and Using the POF Algorithms
4.6. POFアルゴリズムの選択と使用

The selection of the POF algorithm depends on the network scenario and the remaining delay budget of a flow. Using the POF algorithms and calculating their parameters require proper design. Knowing the path delay difference is essential for the POF algorithms described here. Failure scenarios breaking the design assumptions can impact the result of the POF (e.g., packet received out of the expected worst-case delay window -- calculated based on the path delay difference -- can result in unwanted out-of-order delivery).

POFアルゴリズムの選択は、ネットワークシナリオとフローの残りの遅延予算に依存します。POFアルゴリズムを使用してパラメーターを計算するには、適切な設計が必要です。ここで説明するPOFアルゴリズムには、パス遅延差の違いを知ることが不可欠です。デザインの仮定を破る障害シナリオは、POFの結果に影響を与える可能性があります(たとえば、予想される最悪の遅延ウィンドウから受信したパケット - パス遅延差に基づいて計算される - は、不要な注文外配信につながる可能性があります)。

In DetNet scenarios, there is always an elimination function before the POF (therefore, duplicates are not considered by the POF). Implementing them together in the same node allows the POF to consider PEF events/states during the reordering. For example, under normal circumstances, the difference between sequence numbers in consecutive packets is bounded due to the history window of the PEF. However, in some scenarios (e.g., reset of sequence number), the difference can be much larger than the size of the history window.

Detnetシナリオでは、POFの前には常に排除関数があります(したがって、重複はPOFによって考慮されません)。同じノードでそれらを一緒に実装すると、POFは並べ替え中にPEFイベント/状態を考慮することができます。たとえば、通常の状況では、PEFの履歴ウィンドウにより、連続したパケットのシーケンス番号の違いが境界を獲得します。ただし、一部のシナリオ(シーケンス番号のリセットなど)では、違いは履歴ウィンドウのサイズよりもはるかに大きくなる場合があります。

5. Control and Management Plane Parameters for POF
5. POFの制御および管理プレーンパラメーター

POF algorithms require the following parameters to be set:

POFアルゴリズムでは、次のパラメーターを設定する必要があります。

* Basic POF

* 基本的なPOF

- "POFMaxDelay"

- 「Pofmaxdelay」

- "POFTakeAnyTime"

- 「Poftakeanytime」

* Advanced POF

* 高度なPOF

- "POFMaxDelay_i" for each possible path i

- 可能なパスごとに「pofmaxdelay_i」i

- "POFTakeAnyTime"

- 「Poftakeanytime」

- Configuration(s) related to network path identification

- ネットワークパス識別に関連する構成

Note: In a proper design, "POFTakeAnyTime" is always larger than "POFMaxDelay".

注:適切な設計では、「Poftakeanytime」は常に「Pofmaxdelay」よりも大きくなります。

6. Security Considerations
6. セキュリティに関する考慮事項

PREOF-related security considerations (including POF) are described in Section 3.3 of [RFC9055]. There are no additional POF-related security considerations originating from this document.

preaf関連のセキュリティ上の考慮事項(POFを含む)は、[RFC9055]のセクション3.3で説明されています。このドキュメントから発生する追加のPOF関連のセキュリティ上の考慮事項はありません。

7. IANA Considerations
7. IANAの考慮事項

This document has no IANA actions.

このドキュメントにはIANAアクションがありません。

8. References
8. 参考文献
8.1. Normative References
8.1. 引用文献
   [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>.
        
   [RFC9055]  Grossman, E., Ed., Mizrahi, T., and A. Hacker,
              "Deterministic Networking (DetNet) Security
              Considerations", RFC 9055, DOI 10.17487/RFC9055, June
              2021, <https://www.rfc-editor.org/info/rfc9055>.
        
8.2. Informative References
8.2. 参考引用
   [IEEE8021CB]
              IEEE, "IEEE Standard for Local and metropolitan area
              networks -- Frame Replication and Elimination for
              Reliability", IEEE Std 802.1CB-2017,
              DOI 10.1109/IEEESTD.2017.8091139, October 2017,
              <https://standards.ieee.org/standard/802_1CB-2017.html>.
        
   [IEEEP8021CBcv]
              IEEE, "IEEE Standard for Local and metropolitan area
              networks -- Frame Replication and Elimination for
              Reliability - Amendment 1: Information Model, YANG Data
              Model, and Management Information Base Module", IEEE Std 
              802.1CBcv-2001, DOI 10.1109/IEEESTD.2022.9715061, February
              2022, <https://standards.ieee.org/ieee/802.1CBcv/7285/>.
        
Acknowledgements
謝辞

Authors extend their appreciation to Gyorgy Miklos, Ehsan Mohammadpour, Ludovic Thomas, Greg Mirsky, Jeong-dong Ryoo, Fan Yang, Toerless Eckert, Norman Finn, and Ethan Grossman for their insightful comments and productive discussion that helped to improve the document.

著者は、Gyorgy Miklos、Ehsan Mohammadpour、Ludovic Thomas、Greg Mirsky、Jeong-Dong Ryoo、Fan Yang、Toerless Eckert、Norman Finn、Ethan Grossmanに、文書の改善に役立つ生産的な議論に感謝します。

Authors' Addresses
著者のアドレス
   Balazs Varga (editor)
   Ericsson
   Budapest
   Magyar Tudosok krt. 11.
   1117
   Hungary
   Email: balazs.a.varga@ericsson.com
        
   Janos Farkas
   Ericsson
   Budapest
   Magyar Tudosok krt. 11.
   1117
   Hungary
   Email: janos.farkas@ericsson.com
        
   Stephan Kehrer
   Belden Electronics GmbH
   Stuttgarter Strasse 45-51.
   72654 Neckartenzlingen
   Germany
   Email: Stephan.Kehrer@belden.com
        
   Tobias Heer
   Belden Electronics GmbH
   Stuttgarter Strasse 45-51.
   72654 Neckartenzlingen
   Germany
   Email: Tobias.Heer@belden.com