Internet Engineering Task Force (IETF) B. Varga
Request for Comments: 9566 J. Farkas
Category: Informational Ericsson
ISSN: 2070-1721 A. Malis
Malis Consulting
April 2024
This document describes how the DetNet IP data plane can support the Packet Replication, Elimination, and Ordering Functions (PREOF) built on the existing MPLS PREOF solution defined for the DetNet MPLS data plane and the mechanisms defined by MPLS-over-UDP technology.
このドキュメントでは、DETNET IPデータプレーンが、Detnet MPLSデータプレーン用に定義された既存のMPLS PREOFソリューションとMPLS-Over-UDPテクノロジーによって定義されたメカニズムに基づいて構築されたパケットレプリケーション、排除、および順序機能（PREOF）をどのようにサポートできるかについて説明します。
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/rfc9566.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9566で取得できます。
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ライセンステキストを含める必要があります。
1. Introduction
2. Terminology
2.1. Terms Used in This Document
2.2. Abbreviations
3. Requirements for Adding PREOF to DetNet IP
4. Adding PREOF to DetNet IP
4.1. Solution Basics
4.2. Encapsulation
4.3. Packet Processing
4.4. Flow Aggregation
4.5. PREOF Processing
4.6. PREOF-Capable DetNet IP Domain
5. Control and Management Plane Parameters
6. Security Considerations
7. IANA Considerations
8. References
8.1. Normative References
8.2. Informative References
Acknowledgements
Authors' Addresses
The DetNet Working Group has defined Packet Replication (PRF), Packet Elimination (PEF), and Packet Ordering (POF) Functions (represented as PREOF) to provide service protection by the DetNet service sub-layer [RFC8655]. The PREOF 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 PRF and PEF is described in [IEEE8021CB], and the related YANG data model is defined in [IEEE8021CBcv]. A possible implementation of POF is described in [RFC9550]. Figure 1 shows a DetNet flow on which PREOF are applied during forwarding from the source to the destination.
Detnet Working Groupは、Packet Replication（PRF）、Packet Elimination（PEF）、およびPacket Ordering（POF）関数（PREOFとして表される）を定義して、DetNet Service Sub-Layer [RFC8655]によるサービス保護を提供します。PREOFサービス保護法は、複数の最大の分離パスに及ぼす同じパケットのコピーに依存しており、シーケンス情報を使用して重複を排除します。PRFとPEFの可能な実装は[IEEE8021CB]で説明されており、関連するYangデータモデルは[IEEE8021CBCV]で定義されています。POFの可能な実装は[RFC9550]で説明されています。図1は、ソースから宛先への転送中にPREOFが適用されるディットネットフローを示しています。
+------------+
+---------------E1---+ | |
+---+ | | +---R3---+ | +---+
|src|------R1 +---+ | E3----O----+dst|
+---+ | | E2-------+ +---+
+----------R2 |
+-----------------+
R: Replication Function (PRF)
E: Elimination Function (PEF)
O: Ordering Function (POF)
Figure 1: PREOF Scenario in a DetNet Network
図1：Detnet NetworkのPreofシナリオ
In general, the use of PREOF require sequencing information to be included in the packets of a DetNet compound flow. This can be done by adding a sequence number or timestamp as part of DetNet encapsulation. Sequencing information is typically added once, at or close to the source.
一般に、PREOFを使用すると、シーケンス情報がデットネット化合物フローのパケットに含まれる必要があります。これは、デットネットカプセル化の一部としてシーケンス番号またはタイムスタンプを追加することで実行できます。通常、シーケンス情報は、ソースの1回、または近くに追加されます。
The DetNet MPLS data plane [RFC8964] specifies how sequencing information is encoded in the MPLS header. However, the DetNet IP data plane described in [RFC8939] does not specify how sequencing information can be encoded in the IP packet. This document provides sequencing information to DetNet IP nodes, so it results in an improved version of the DetNet IP data plane. As suggested by [RFC8938], the solution uses existing standardized headers and encapsulations. The improvement is achieved by reusing the DetNet MPLS-over-UDP/IP data plane [RFC9025] with the restriction of using zero F-Labels.
Detnet MPLSデータプレーン[RFC8964]は、MPLSヘッダーでのシーケンス情報がエンコードされる方法を指定します。ただし、[RFC8939]に記載されているDETNET IPデータプレーンは、IPパケットで情報をエンコードする方法を指定していません。このドキュメントは、IPノードをDetNetにシーケンス情報を提供するため、Detnet IPデータプレーンのバージョンが改善されます。[RFC8938]で示唆されているように、ソリューションは既存の標準化されたヘッダーとカプセルを使用します。この改善は、ゼロFラベルを使用することを制限して、MPLS-Over-UDP/IPデータプレーン[RFC9025]を再利用することで達成されます。
This document uses the terminology established in the DetNet architecture [RFC8655], and it is assumed that the reader is familiar with that document and its terminology.
このドキュメントでは、Detnet Architecture [RFC8655]で確立された用語を使用しており、読者がその文書とその用語に精通していると想定されています。
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
パケットレプリケーション機能
The requirements for adding PREOF to DetNet IP are:
PreofをDetnet IPに追加するための要件は次のとおりです。
* to reuse existing DetNet data plane solutions (e.g., [RFC8964], [RFC9025]), and
* 既存のデットネットデータプレーンソリューション（例：[RFC8964]、[RFC9025]）、および
* to allow the DetNet service sub-layer for IP packet-switched networks with minimal implementation effort.
* IPパケットスイッチネットワークのDetnet Service Sub-Layerが最小限の実装の努力を許可します。
The described solution leverages MPLS header fields without requiring the support of the MPLS forwarding plane.
記載されているソリューションは、MPLS転送面のサポートを必要とせずにMPLSヘッダーフィールドを活用します。
The DetNet IP encapsulation supporting the DetNet service sub-layer is based on the "UDP tunneling" concept. The solution creates a set of underlay UDP/IP tunnels between an overlay set of DetNet relay nodes.
Detnet ServiceサブレイヤーをサポートするDETNET IPカプセル化は、「UDPトンネル」の概念に基づいています。このソリューションは、デットネットリレーノードのオーバーレイセットの間にアンダーレイUDP/IPトンネルのセットを作成します。
At the edge of a PREOF-capable DetNet IP domain, the DetNet flow is encapsulated in a UDP packet containing the sequence number used by PREOF within the domain. This solution maintains the 6-tuple-based DetNet flow identification in DetNet transit nodes, which operate at the DetNet forwarding sub-layer between the DetNet service sub-layer nodes; therefore, it is compatible with [RFC8939]. Figure 2 shows how the PREOF-capable DetNet IP data plane fits into the DetNet sub-layers.
preof-capable Detnet IPドメインの端で、DETNETフローは、ドメイン内でPREOFで使用されるシーケンス番号を含むUDPパケットにカプセル化されています。このソリューションは、デットネットサービスサブレイヤーノードの間のサブレイヤーで動作するデットネットトランジットノードの6タプルベースのディットネットフロー識別を維持します。したがって、[RFC8939]と互換性があります。図2は、Preof-Capable Detnet IPデータプレーンがDetnetサブレイヤーにどのように適合するかを示しています。
DetNet IP
.
.
+------------+
| Service | d-CW, Service-ID (S-Label)
+------------+
| Forwarding | UDP/IP Header
+------------+
*d-CW: DetNet Control Word
Figure 2: PREOF-Capable DetNet IP Data Plane
図2：PREOF対応DETNET IPデータプレーン
The PREOF-capable DetNet IP encapsulation builds on encapsulating DetNet pseudowire (PW) directly over UDP. That is, it combines DetNet MPLS [RFC8964] with DetNet MPLS-in-UDP [RFC9025], without using any F-Labels, as shown in Figure 3. DetNet flows are identified at the receiving DetNet service sub-layer processing node via the S-Label and/or the UDP/IP header information. Sequencing information for PREOF is provided by the DetNet Control Word (d-CW) per [RFC8964]. The S-Label is used to identify both the DetNet flow and the DetNet App-flow type. The UDP tunnel is used to direct the packet across the DetNet domain to the next DetNet service sub-layer processing node.
Preof-Capable Detnet IPカプセル化は、UDPを介したカプセル化Detnet Pseudowire（PW）に直接構築されます。つまり、図3に示すように、Fラベルを使用せずに、Detnet MPLS [RFC8964]とDetNet MPLS-in-UUDP [RFC9025]を組み合わせています。S-Labelおよび/またはUDP/IPヘッダー情報。PREOFのシーケンス情報は、[RFC8964]ごとにDetnet Control Word（D-CW）によって提供されます。S-Labelは、Detnet FlowとDetnet App-Flowタイプの両方を識別するために使用されます。UDPトンネルは、デットネットドメインを介してパケットを次のDetnet Serviceサブレイヤー処理ノードに向けるために使用されます。
+---------------------------------+
| |
| DetNet App-Flow |
| (Original IP) Packet |
| |
+---------------------------------+ <--\
| DetNet Control Word | |
+---------------------------------+ +--> PREOF-capable
| Service-ID (S-Label) | | DetNet IP data
+---------------------------------+ | plane encapsulation
| UDP Header | |
+---------------------------------+ |
| IP Header | |
+---------------------------------+ <--/
| Data-Link |
+---------------------------------+
| Physical |
+---------------------------------+
Figure 3: PREOF-Capable DetNet IP Encapsulation
図3：PREOF対応DETNET IPカプセル化
IP ingress and egress nodes of the PREOF-capable DetNet IP domain add and remove a DetNet service-specific d-CW and Service-ID (i.e., S-Label). Relay nodes can change Service-ID values when processing a DetNet flow, i.e., incoming and outgoing Service-IDs of a DetNet flow can be different. Service-ID values are provisioned per DetNet service via configuration, e.g., via the Controller Plane described in [RFC8938]. In some PREOF topologies, the node performing replication sends the packets to multiple nodes performing, e.g., PEF or POF, and the replication node can use different Service-ID values for the different member flows for the same DetNet service.
PREOF対応DETNET IPドメインのIPイングレスノードと出口ノードは、Detnet Service固有のD-CWおよびService-ID（つまり、S-Label）を追加および削除します。リレーノードは、Detnet Flowを処理するときにService-ID値を変更できます。つまり、Detnet Flowの着信および発信サービスIDは異なる場合があります。[RFC8938]に記載されているコントローラー平面など、Service-ID値は、たとえば、構成を介して、構成を介してプロビジョニングされます。いくつかのPreofトポロジでは、ノードを実行するレプリケーションを実行すると、パケットがPEFまたはPOFなどを実行する複数のノードに送信し、レプリケーションノードは同じデットネットサービスの異なるメンバーフローに異なるService-ID値を使用できます。
Note that the Service-ID is a local ID on the receiver side that identifies the DetNet flow at the downstream DetNet service sub-layer receiver.
Service-IDは、下流のDetnet Serviceサブレイヤーレシーバーでのデットネットフローを識別するレシーバー側のローカルIDであることに注意してください。
Two methods can be used for flow aggregation:
フロー集計には2つの方法を使用できます。
* aggregation using same UDP tunnel, and
* 同じUDPトンネルを使用した集合体、および
* aggregation of DetNet flows as a new DetNet flow.
* デットネットの集約は、新しいデットネットフローとして流れます。
In the first method, the different DetNet pseudowires use the same UDP tunnel, so they are treated as a single (aggregated) flow at the forwarding sub-layer. At the service sub-layer, each flow uses a different Service-ID (see Figure 3).
最初の方法では、異なるDetnet Pseudowiresは同じUDPトンネルを使用しているため、転送サブレイヤーで単一の（集約された）フローとして扱われます。サービスサブレイヤーでは、各フローは異なるサービスIDを使用します（図3を参照）。
For the second method, an additional hierarchy is created by adding an additional Service-ID and d-CW tuple to the encapsulation. The Aggregate-ID is a special case of a Service-ID, whose properties are known only at the aggregation and deaggregation end points. It is a property of the Aggregate-ID that it is followed by a d-CW followed by a Service-ID/d-CW tuple. Figure 4 shows the encapsulation in the case of aggregation.
2番目の方法では、カプセル化に追加のService-IDとD-CWタプルを追加することにより、追加の階層が作成されます。Aggregate-IDは、Service-IDの特別なケースであり、そのプロパティは集約および拡張エンドポイントでのみ知られています。それは、D-CWが続いてService-ID/D-CW Tupleが続くと、Aggregate-IDの特性です。図4は、集約の場合のカプセル化を示しています。
+---------------------------------+
| |
| DetNet App-Flow |
| Payload Packet |
| |
+---------------------------------+ <--\
| DetNet Control Word | |
+---------------------------------+ +--> PREOF-capable
| Service-ID (S-Label) | | DetNet IP data
+---------------------------------+ | plane encapsulation
| DetNet Control Word | |
+---------------------------------+ |
| Aggregate-ID (A-Label) | |
+---------------------------------+ |
| UDP Header | |
+---------------------------------+ |
| IP Header | |
+---------------------------------+ <--/
| Data-Link |
+---------------------------------+
| Physical |
+---------------------------------+
Figure 4: Aggregating DetNet Flows as a New DetNet Flow
図4：新しいデットネットフローとしてのデットネットフローの集約
The aggregation method is configured in the aggregation/deaggregation nodes.
集約法は、集約/掘削ノードで構成されています。
If several DetNet flows are aggregated in a single UDP tunnel, they all need to follow the same path in the network.
単一のUDPトンネルにいくつかのDetnetフローが集約されている場合、それらはすべてネットワーク内の同じパスをたどる必要があります。
A node operating on a received DetNet flow at the DetNet service sub-layer uses the local context associated with a received Service-ID to determine which local DetNet operation(s) are applied to the received packet. A unique Service-ID can be allocated and can be used to identify a DetNet flow regardless of which input interface or UDP tunnel receives the packet. It is important to note that Service-ID values are driven by the receiver, not the sender.
Detnet Serviceサブレイヤーで受信したデットネットフローで動作するノードは、受信したサービスIDに関連付けられたローカルコンテキストを使用して、受信したパケットに適用されるローカルデットネット操作を決定します。ユニークなService-IDを割り当てることができ、どの入力インターフェイスまたはUDPトンネルがパケットを受信するかに関係なく、デットネットフローを識別するために使用できます。Service-IDの値は、送信者ではなく受信機によって駆動されることに注意することが重要です。
The DetNet forwarding sub-layer is supported by the UDP tunnel and is responsible for providing resource allocation and explicit routes.
デットネット転送サブレイヤーは、UDPトンネルによってサポートされており、リソースの割り当てと明示的なルートを提供する責任があります。
The outgoing PREOF encapsulation and processing can be implemented via the provisioning of UDP and IP header information. Note, when PRF is performed at the DetNet service sub-layer, there are multiple member flows, and each member flow requires its own Service-ID, UDP header information, and IP header information. The headers for each outgoing packet are formatted according to the configuration information, and the UDP Source Port value is set to uniquely identify the DetNet flow. The packet is then handled as a PREOF-capable DetNet IP packet.
発信前のカプセル化と処理は、UDPおよびIPヘッダー情報のプロビジョニングを介して実装できます。注意してください、Detnet ServiceサブレイヤーでPRFが実行されると、複数のメンバーフローがあり、各メンバーフローには独自のサービスID、UDPヘッダー情報、IPヘッダー情報が必要です。各発信パケットのヘッダーは、構成情報に従ってフォーマットされ、UDPソースポート値は、デットネットフローを一意に識別するように設定されています。パケットは、Preof-Capable Detnet IPパケットとして処理されます。
The incoming PREOF processing can be implemented by assigning a Service-ID to the received DetNet flow and processing the information in the UDP and IP headers. The provisioned information is used to identify incoming App-flows based on the combination of Service-ID and/or incoming encapsulation header information.
入ってくるPREOF処理は、受信したデットネットフローにサービス-IDを割り当て、UDPおよびIPヘッダーの情報を処理することにより実装できます。プロビジョニングされた情報は、Service-IDおよび/または着信カプセル化ヘッダー情報の組み合わせに基づいて、着信アプリフローを識別するために使用されます。
Figure 5 shows using PREOF in a PREOF-capable DetNet IP network, where service protection is provided end to end, and not only within sub-networks, as is depicted in Figure 4 <https://www.rfc-editor.org/rfc/rfc8939#figure-4> of [RFC8939].
図5は、図4 <https://www.rfc-editor.org/に示すように、サービス保護がサブネットワーク内だけでなく、サービス保護がエンドツーエンドであるだけでなく、エンドツーエンドで提供されるPREOFを使用しています。[RFC8939]のRFC/RFC8939＃図-4>。
<---------- PREOF-capable DetNet IP --------------->
______
____ / \__
____ / \__/ \____________
+----+ __/ \____/ \ +----+
|src |_____/ \___| dst|
+----+ \_______ DetNet network __________/ +----+
\_______ _/
\ __ __/
\_______/ \___/
+------------+
+---------------E1---+ | |
+----+ | | +---R3---+ | +----+
|src |------R1 +---+ | E3----O----+ dst|
+----+ | | E2-------+ +----+
+----------R2 |
+-----------------+
Figure 5: PREOF-Capable DetNet IP Domain
図5：PREOF対応DETNET IPドメイン
The information needed to identify individual and aggregated DetNet flows is summarized as follows:
個別および集約されたデットネットフローを識別するために必要な情報は、次のように要約されています。
* Service-ID information to be mapped to UDP/IP flows. Note that, for example, a single Service-ID can map to multiple sets of UDP/ IP information when PREOF is used.
* UDP/IPフローにマッピングされるサービス-ID情報。たとえば、PREOFを使用すると、単一のService-IDがUDP/ IP情報の複数のセットにマッピングできることに注意してください。
* IPv4 or IPv6 Source Address field.
* IPv4またはIPv6ソースアドレスフィールド。
* IPv4 or IPv6 source address prefix length, where a zero (0) value effectively means that the address field is ignored.
* IPv4またはIPv6ソースアドレスのプレフィックス長さ。ゼロ（0）値は、アドレスフィールドが無視されることを効果的に意味します。
* IPv4 or IPv6 Destination Address field.
* IPv4またはIPv6宛先アドレスフィールド。
* IPv4 or IPv6 destination address prefix length, where a zero (0) effectively means that the address field is ignored.
* IPv4またはIPv6宛先アドレスのプレフィックス長さ。ゼロ（0）は、アドレスフィールドが無視されることを効果的に意味します。
* IPv6 Flow Label field.
* IPv6フローラベルフィールド。
* IPv4 Protocol field being equal to "UDP".
* IPv4プロトコルフィールドは「UDP」に等しい。
* IPv6 (last) Next Header field being equal to "UDP".
* IPv6（最後）次のヘッダーフィールドは「UDP」に等しくなります。
* For the IPv4 Type of Service and IPv6 Traffic Class fields:
* IPv4のサービスのタイプとIPv6トラフィッククラスフィールド：
- Whether or not the Differentiated Services Code Point (DSCP) field is used in flow identification, as the use of the DSCP field for flow identification is optional.
- フロー識別のためのDSCPフィールドの使用がオプションであるため、差別化されたサービスコードポイント（DSCP）フィールドがフロー識別に使用されるかどうかです。
- If the DSCP field is used to identify a flow, then the flow identification information (for that flow) includes a list of DSCPs used by the given DetNet flow.
- DSCPフィールドがフローを識別するために使用される場合、フロー識別情報（そのフローの）には、指定されたDetnet Flowで使用されるDSCPのリストが含まれています。
* UDP Source Port. Support for both exact and wildcard matching is required. Port ranges can optionally be used.
* UDPソースポート。正確なマッチングとワイルドカードの両方のサポートが必要です。オプションでポートレンジを使用できます。
* UDP Destination Port. Support for both exact and wildcard matching is required. Port ranges can optionally be used.
* UDP宛先ポート。正確なマッチングとワイルドカードの両方のサポートが必要です。オプションでポートレンジを使用できます。
* For end systems, an optional maximum IP packet size that should be used for that outgoing DetNet IP flow.
* エンドシステムの場合、その発信デットネットIPフローに使用する必要があるオプションの最大IPパケットサイズ。
This information is provisioned per DetNet flow via configuration, e.g., via the Controller Plane.
この情報は、たとえば、コントローラー平面を介して、構成を介してデットネットフローごとにプロビジョニングされます。
Ordering of the set of information used to identify an individual DetNet flow can, for example, be used to provide a DetNet service for a specific UDP flow, with unique Source and Destination Port field values, while providing a different service for the aggregate of all other flows with that same UDP Destination Port value.
たとえば、個々のデットネットフローを識別するために使用される情報セットの順序付けは、一意のソースと宛先ポートフィールドの値を持つ特定のUDPフローのデットネットサービスを提供するために使用でき、すべての集合体に異なるサービスを提供します。同じUDP宛先ポート値を持つその他のフロー。
The minimum set of information for the configuration of the DetNet service sub-layer is summarized as follows:
Detnet Serviceサブレイヤーの構成に関する最小情報セットは、次のように要約されています。
* App-flow identification information
* アプリフロー識別情報
* Sequence number length
* シーケンス数の長さ
* Type of PREOF to be executed on the DetNet flow
* Detnet Flowで実行されるPREOFのタイプ
* Service-ID(s) used by the member flows
* メンバーフローが使用するService-ID
* Associated forwarding sub-layer information
* 関連する転送サブ層情報
* Service aggregation information
* サービス集約情報
The minimum set of information for the configuration of the DetNet forwarding sub-layer is summarized as follows:
デットネット転送サブレイヤーの構成に関する最小情報セットは、次のように要約されています。
* UDP tunnel-specific information
* UDPトンネル固有の情報
* Traffic parameters
* トラフィックパラメーター
These parameters are defined in the DetNet flow and service information model [RFC9016] and the DetNet YANG model.
これらのパラメーターは、Detnet Flow and Service Information Model [RFC9016]およびDetnet Yangモデルで定義されています。
Note: this document focuses on the use of MPLS-over-UDP/IP encapsulation throughout an entire DetNet IP network, making MPLS-based DetNet Operations, Administration, and Maintenance (OAM) techniques applicable [RFC9546]. Using the described encapsulation only for a portion of a DetNet IP network that handles PREOF would complicate OAM.
注：このドキュメントは、DETNET IPネットワーク全体でMPLS-Over-UDP/IPカプセル化の使用に焦点を当てており、MPLSベースのDetNet操作、管理、およびメンテナンス（OAM）技術を適用可能にします[RFC9546]。Preofを処理するDetnet IPネットワークの一部に対してのみ説明されたカプセル化を使用すると、OAMが複雑になります。
There are no new DetNet-related security considerations introduced by this solution. Security considerations of DetNet MPLS [RFC8964] and DetNet MPLS over UDP/IP [RFC9025] apply.
このソリューションによって導入された新しいDetnet関連のセキュリティ上の考慮事項はありません。Detnet MPLS [RFC8964]およびUDP/IP [RFC9025]を超えるMPLのセキュリティ上の考慮事項が適用されます。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
[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>.
[RFC8938] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S.
Bryant, "Deterministic Networking (DetNet) Data Plane
Framework", RFC 8938, DOI 10.17487/RFC8938, November 2020,
<https://www.rfc-editor.org/info/rfc8938>.
[RFC8939] Varga, B., Ed., Farkas, J., Berger, L., Fedyk, D., and S.
Bryant, "Deterministic Networking (DetNet) Data Plane:
IP", RFC 8939, DOI 10.17487/RFC8939, November 2020,
<https://www.rfc-editor.org/info/rfc8939>.
[RFC8964] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., Bryant,
S., and J. Korhonen, "Deterministic Networking (DetNet)
Data Plane: MPLS", RFC 8964, DOI 10.17487/RFC8964, January
2021, <https://www.rfc-editor.org/info/rfc8964>.
[RFC9016] Varga, B., Farkas, J., Cummings, R., Jiang, Y., and D.
Fedyk, "Flow and Service Information Model for
Deterministic Networking (DetNet)", RFC 9016,
DOI 10.17487/RFC9016, March 2021,
<https://www.rfc-editor.org/info/rfc9016>.
[RFC9025] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S.
Bryant, "Deterministic Networking (DetNet) Data Plane:
MPLS over UDP/IP", RFC 9025, DOI 10.17487/RFC9025, April
2021, <https://www.rfc-editor.org/info/rfc9025>.
[RFC9546] Mirsky, G., Chen, M., and B. Varga, "Operations,
Administration, and Maintenance (OAM) for Deterministic
Networking (DetNet) with the MPLS Data Plane", RFC 9546,
DOI 10.17487/RFC9546, February 2024,
<https://www.rfc-editor.org/info/rfc9546>.
[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://doi.org/10.1109/IEEESTD.2017.8091139>.
[IEEE8021CBcv]
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", Amendment
to IEEE Std 802.1CB-2017, IEEE Std 802.1CBcv-2021,
DOI 10.1109/IEEESTD.2022.9715061, February 2022,
<https://doi.org/10.1109/IEEESTD.2022.9715061>.
[RFC9550] Varga, B., Ed., Farkas, J., Kehrer, S., and T. Heer,
"Deterministic Networking (DetNet): Packet Ordering
Function", RFC 9550, DOI 10.17487/RFC9550, March 2024,
<https://www.rfc-editor.org/info/rfc9550>.
Authors extend their appreciation to Stewart Bryant, Pascal Thubert, David Black, Shirley Yangfan, and Greg Mirsky for their insightful comments and productive discussion that helped to improve the document.
著者は、ドキュメントの改善に役立った洞察に富んだコメントと生産的な議論について、スチュワート・ブライアント、パスカル・ザールバート、デイビッド・ブラック、シャーリー・ヤンファン、グレッグ・ミルスキーに感謝を広げました。
Balazs Varga
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
Andrew G. Malis
Malis Consulting
Email: agmalis@gmail.com