[要約] RFC 9056は、IPネットワーク上でMPLS技術を使用して決定論的ネットワーキング（DetNet）データプレーンを実現する方法について説明しています。この文書の目的は、高い信頼性と低遅延を必要とするアプリケーションのために、予測可能なサービス品質（QoS）を提供することです。利用場面には、産業オートメーション、車載ネットワーク、およびオーディオ/ビデオストリーミングが含まれます。
Internet Engineering Task Force (IETF) B. Varga, Ed.
Request for Comments: 9056 Ericsson
Category: Standards Track L. Berger
ISSN: 2070-1721 D. Fedyk
LabN Consulting, L.L.C.
S. Bryant
Futurewei Technologies
J. Korhonen
October 2021
Deterministic Networking (DetNet) Data Plane: IP over MPLS
決定論的ネットワーキング（DETNET）データプレーン：MPLS以上のIP
Abstract
概要
This document specifies the Deterministic Networking data plane when encapsulating IP over an MPLS packet-switched network.
このドキュメントは、MPLSパケット交換ネットワークを介してIPをカプセル化するときの決定論的ネットワーキングデータプレーンを指定します。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これはインターネット規格のトラック文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。インターネット規格に関する詳細情報は、RFC 7841のセクション2で利用できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9056.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc9056で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2021 IETF信頼と文書著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、このドキュメントの発行日に有効なBCP 78およびIETFドキュメントに関連するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。 これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
2. Terminology
2.1. Terms Used in This Document
2.2. Abbreviations
2.3. Requirements Language
3. DetNet IP Data Plane Overview
4. DetNet IP over DetNet MPLS
4.1. DetNet IP over DetNet MPLS Data Plane Scenarios
4.2. DetNet IP over DetNet MPLS Encapsulation
5. DetNet IP over DetNet MPLS Procedures
5.1. DetNet IP over DetNet MPLS Flow Identification and
Aggregation Procedures
5.2. DetNet IP over DetNet MPLS Traffic Treatment Procedures
6. Management and Control Information Summary
7. Security Considerations
8. IANA Considerations
9. References
9.1. Normative References
9.2. Informative References
Acknowledgements
Contributors
Authors' Addresses
Deterministic Networking (DetNet) is a service that can be offered by a network to DetNet flows. DetNet provides a capability for the delivery of data flows with extremely low packet loss rates and bounded end-to-end delivery latency. General background and concepts of DetNet can be found in the DetNet architecture [RFC8655].
決定論的ネットワーキング（DetNet）は、ネットワークによってDetnet Flowsに提供できるサービスです。DetNetは、極めて低いパケット損失率と最終的な終了配信待ち時間を持つデータフローの配信機能を提供します。Detnetの一般的な背景と概念は、DetNet Architecture [RFC8655]にあります。
This document specifies use of the IP DetNet encapsulation over an MPLS network. It maps the IP data plane encapsulation described in [RFC8939] to the DetNet MPLS data plane defined in [RFC8964].
このドキュメントは、MPLSネットワーク上でのIP Detnetカプセル化の使用を指定します。[RFC8939]に記載されているIPデータプレーンカプセル化を[RFC8964]で定義されているDetNet MPLSデータプレーンにマッピングします。
This document uses the terminology and concepts established in the DetNet architecture [RFC8655] and in [RFC8938]. The reader is assumed to be familiar with these documents and their terminology.
この文書では、Detnetアーキテクチャ[RFC8655]と[RFC8938]で確立された用語と概念を使用しています。リーダーはこれらの文書とその用語に精通していると見なされます。
This document uses the abbreviations defined in the DetNet architecture [RFC8655] and in [RFC8938]. This document uses the following abbreviations:
この文書では、Detnetアーキテクチャ[RFC8655]および[RFC8938]で定義されている略語を使用します。この文書は次の略語を使用します。
CE Customer Edge (equipment)
CEカスタマーエッジ（機器）
d-CW DetNet Control Word
D-CW Detnet Control Word.
DetNet Deterministic Networking
Detnet決定論的ネットワーキング
DF DetNet Flow
DF DetNetフロー
DN DetNet
DN Detnet
L2 Layer 2
L2層2
LSP Label-Switched Path
LSPラベルスイッチパス
MPLS Multiprotocol Label Switching
MPLSマルチプロトコルラベルスイッチング
PEF Packet Elimination Function
PEFパケット除去機能
PRF Packet Replication Function
PRFパケットレプリケーション機能
PREOF Packet Replication, Elimination, and Ordering Functions
パケットのレプリケーション、除去、および注文機能
POF Packet Ordering Function
POFパケット順序機能
PW Pseudowire
PW擬似ワイヤー
S-Label DetNet "service" Label
SラベルDETNETNET「サービス」ラベル
S-PE Switching Provider Edge
S-PEスイッチングプロバイダエッジ
T-PE Terminating Provider Edge
T-PE終端プロバイダーエッジ
TE Traffic Engineering
TEトラフィック工学
TSN Time-Sensitive Networking; TSN is a Task Group of the IEEE 802.1 Working Group
TSNの時間依存ネットワーキング。TSNはIEEE 802.1ワーキンググループのタスクグループです。
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]で説明されているように、すべて大文字の場合にのみ解釈されます。
Figure 1 illustrates an IP DetNet with an MPLS-based DetNet network as a sub-network between the relay nodes. An IP flow is mapped to one or more PWs and MPLS (TE) LSPs. The end systems still originate IP-encapsulated traffic, identified as DetNet flows. The relay nodes follow procedures defined in Section 4 to map each DetNet flow to MPLS LSPs. While not shown, relay nodes can provide service sub-layer functions such as PREOF using DetNet over MPLS, and this is indicated by the solid line for the MPLS-facing portion of the Service component. Note that the Transit node is MPLS (TE) LSP aware and performs switching based on MPLS labels; it need not have any specific knowledge of the DetNet service or the corresponding DetNet flow identification. See Section 4 for details on the mapping of IP flows to MPLS, and [RFC8964] for general support of DetNet services using MPLS.
図1は、中継ノード間のサブネットワークとしてMPLSベースのDetNetネットワークを備えたIP Detnetを示しています。IPフローは、1つ以上のPWSおよびMPLS（TE）LSPにマッピングされます。エンドシステムは依然としてDetnet Flowsとして識別されたIPカプセル化されたトラフィックを依然として起因しています。リレーノードは、各DetNetフローをMPLS LSPにマッピングするためにセクション4で定義された手順に従います。図示されていないが、中継ノードはMPLSを介してDETNETを使用してPREOFなどのサービスサブレイヤ関数を提供することができ、これはサービスコンポーネントのMPLS対向部分の実線によって示される。トランジットノードはMPLS（TE）LSP認識であり、MPLSラベルに基づいてスイッチングを実行します。Detnetサービスまたは対応するDetNet Flow Identsの具体的な知識が必要です。MPLSへのIPフローのマッピング、および[RFC8964]の詳細については、MPLSを使用したDetnet Servicesの一般的なサポートの詳細については、セクション4を参照してください。
DetNet IP Relay Transit Relay DetNet IP End System Node Node Node End System
Detnet IPリレートランジットリレーDETNET IPエンドシステムノードノードノードエンドシステム
+----------+ +----------+
| Appl. |<------------- End to End Service ---------->| Appl. |
+----------+ .....-----+ +-----..... +----------+
| Service |<--: Service |--DetNet flow ---| Service :-->| Service |
| | : |<-DN MPLS flow ->| : | |
+----------+ +---------+ +----------+ +---------+ +----------+
|Forwarding| |Fwd| |Fwd| |Forwarding| |Fwd| |Fwd| |Forwarding|
+-------.--+ +-.-+ +-.-+ +----.---.-+ +-.-+ +-.-+ +---.------+
: Link : / ,-----. \ : Link : / ,-----. \
+........+ +-[ Sub ]-+ +......+ +-[ Sub ]-+
[Network] [Network]
`-----' `-----'
|<---- DetNet MPLS ---->|
|<--------------------- DetNet IP ------------------>|
Figure 1: Architecture: DetNet IP over DetNet MPLS Network
図1：アーキテクチャ：Detnet IP over Detnet MPLSネットワーク
This section defines how IP-encapsulated flows are carried over a DetNet MPLS data plane as defined in [RFC8964]. Since both non-DetNet and DetNet IP packets are identical on the wire, this section is applicable to any node that supports IP over DetNet MPLS, and this section refers to both cases as DetNet IP over DetNet MPLS.
このセクションでは、[RFC8964]で定義されているDetnet MPLSデータプレーンを介してIPカプセル化フローをどのように伝送するかを定義します。非DETNETおよびDETNET IPパケットの両方がワイヤー上で同一のものであるため、このセクションはDetnet MPLSの上のIPをサポートする任意のノードに適用されます。このセクションでは、両方の場合を参照してください。
An example use of DetNet IP over DetNet MPLS is presented here.
Detnet IPを介したDetNet IPの使用例は、ここに表示されます。
Figure 1 illustrates IP DetNet-enabled End Systems (hosts) connected to DetNet-enabled IP networks (DN IP), operating over a DetNet-aware MPLS network. In this figure, we have a case where the relay nodes act as T-PEs and sit at the boundary of the MPLS domain since the non-MPLS domain is DetNet aware. This case is very similar to the DetNet MPLS Network (Figure 2 in [RFC8964]). However, in Figure 2 of [RFC8964], the T-PEs are located at the end system and MPLS spans the whole DetNet service. The primary difference in this document is that the relay nodes are at the edges of the MPLS domain and therefore function as T-PEs, and that MPLS service sub-layer functions are not provided over the DetNet IP network. The transit node functions shown above are identical to those described in [RFC8964].
図1は、Detnet対応のIPネットワーク（DN IP）に接続されているIP Detnet対応エンドシステム（ホスト）を示しており、Detnet対応MPLSネットワークを介して操作しています。この図では、中継ノードがT-PESとして機能し、非MPLSドメインがDetNet認識であるため、MPLSドメインの境界に座る場合があります。この場合はDetnet MPLSネットワークと非常によく似ています（図2の[RFC8964]）。ただし、[RFC8964]の図2では、T-PESはエンドシステムにあり、MPLSはDetnet Service全体にスパンします。この文書の主な違いは、中継ノードがMPLSドメインのエッジにあり、したがってT-PESとして機能し、MPLSサービスのサブレイヤ機能はDetNet IPネットワークを介して提供されていないことです。上記の通過ノード機能は、[RFC8964]に記載されているものと同じです。
Figure 2 illustrates how relay nodes can provide service protection over an MPLS domain. In this case, CE1 and CE2 are IP DetNet end systems that are interconnected via an MPLS domain such as that described in [RFC8964]. Note that R1 and R3 sit at the edges of an MPLS domain and therefore are similar to T-PEs, while R2 sits in the middle of the domain and is therefore similar to an S-PE.
図2は、中継ノードがMPLSドメインを介してサービス保護を提供できる方法を示しています。この場合、CE1およびCE2は、[RFC8964]で説明されているようなMPLSドメインを介して相互接続されているIP Detnet Endシステムである。R1およびR3はMPLSドメインのエッジに座るので、R2はドメインの中央に位置し、したがってS - PEと同様である。
DetNet DetNet
IP Service Transit Transit Service IP
DetNet |<-Tnl->| |<-Tnl->| DetNet
End | V 1 V V 2 V | End
System | +--------+ +--------+ +--------+ | System
+---+ | | R1 |=======| R2 |=======| R3 | | +---+
| |-------|._X_....|..DF1..|.__ ___.|..DF3..|...._X_.|-------| |
|CE1| | | \ | | X | | / | | |CE2|
| | | | \_.|..DF2..|._/ \__.|..DF4..|._/ | | | |
+---+ | |=======| |=======| | +---+
^ +--------+ +--------+ +--------+ ^
| Relay Node Relay Node Relay Node |
| (T-PE) (S-PE) (T-PE) |
| |
|<-DN IP-> <-------- DetNet MPLS ---------------> <-DN IP->|
| |
|<-------------- End to End DetNet Service --------------->|
-------------------------- Data Flow ------------------------->
X = Service protection (PRF, PREOF, PEF/POF) DFx = DetNet member flow x over a TE LSP
X =サービス保護（PRF、PREOF、PEF / POF）DFX = TE LSP上のDETNETメンバーフローX
Figure 2: Service Protection over DetNet MPLS Network for DetNet IP
図2：DetNet IP用のDetnet MPLSネットワーク上のサービス保護
Figure 1 illustrates DetNet-enabled end systems connected to DetNet-enabled (DN) MPLS networks. A similar situation occurs when end systems are not DetNet aware. In this case, edge nodes sit at the boundary of the MPLS domain since it is also a DetNet domain boundary. The edge nodes provide DetNet service proxies for the end applications by initiating and terminating DetNet service for the application's IP flows. While the node types differ, there is essentially no difference in data plane processing between relays and edges. There are likely to be differences in Controller Plane operation, particularly when distributed control plane protocols are used.
図1は、DetNet対応（DN）MPLSネットワークに接続されているDetnet対応エンドシステムを示しています。エンドシステムがDetnet Awareでない場合も同様の状況が発生します。この場合、エッジノードはDetNetドメイン境界でもあるため、MPLSドメインの境界に座ります。エッジノードは、アプリケーションのIPフローのDetNetサービスを開始して終了することで、エンドアプリケーションのDetnetサービスプロキシを提供します。ノードタイプが異なる間、リレーとエッジ間のデータプレーン処理には本質的に差がありません。特に分散制御プレーンプロトコルが使用されている場合、コントローラ平面動作に違いがある可能性があります。
It is still possible to provide DetNet service protection for non-DetNet-aware end systems. This case is basically the same as Figure 2, with the exception that CE1 and CE2 are non-DetNet-aware end systems and R1 and R3 become edge nodes.
Detnet対応エンドシステムのDetnetサービス保護を提供することはまだ可能です。この場合は、CE1とCE2が非DETNET対応エンドシステムで、R1とR3がエッジノードになることを除いて、基本的に図2と同じです。
The basic encapsulation approach is to treat a DetNet IP flow as an App-flow from the DetNet MPLS perspective. The corresponding example DetNet Sub-network format is shown in Figure 3.
基本的なカプセル化アプローチは、DetNet MPLSの観点からのアプリフローとしてDetnet IPフローを扱うことです。対応する例示的なDetnetサブネットワークフォーマットを図3に示します。
/-> +------+ +------+ +------+ ^ ^
| | X | | X | | X |<- App-flow : :
| +------+ +------+ +------+ : :
App-flow <-+ |NProto| |NProto| |NProto| : :(1)
for MPLS | +------+ +------+ +------+ : :
| | IP | | IP | | IP | : v
\-> +---+======+--+======+--+======+-----+ :
DetNet-MPLS | d-CW | | d-CW | | d-CW | :
+------+ +------+ +------+ :(2)
|Labels| |Labels| |Labels| v
+---+======+--+======+--+======+-----+
Link/Sub-network | L2 | | TSN | | UDP |
+------+ +------+ +------+
| IP |
+------+
| L2 |
+------+
(1) DetNet IP Flow (or simply IP flow)
(2) DetNet MPLS Flow
Figure 3: Example DetNet IP over MPLS Sub-network Formats
図3：MPLSサブネットワークフォーマットを介したDetnet IPの例
In Figure 3, "App-flow" indicates the payload carried by the DetNet IP data plane. "IP" and "NProto" indicate the fields described in Sections 5.1.1 (IP Header Information) and 5.1.2 (Other Protocol Header Information) of [RFC8939], respectively. "App-flow for MPLS" indicates that an individual DetNet IP flow is the payload from the perspective of the DetNet MPLS data plane defined in [RFC8964].
図3では、「アプリフロー」はDetNet IPデータプレーンによって運ばれるペイロードを示す。「IP」と「NPROTO」は、それぞれ[RFC8939]のセクション5.1.1（IPヘッダ情報）および5.1.2（その他のプロトコルヘッダ情報）に示す項目を示す。「MPLSのアプリフロー」は、個々のDetNet IPフローが[RFC8964]で定義されているDetnet MPLSデータプレーンの観点からのペイロードであることを示します。
Per Section 5.1 of [RFC8964], the DetNet MPLS data plane uses a single S-Label to support a single App-flow. DetNet IP Flow Identification Procedures in Section 5.1 of [RFC8939] states that a single DetNet flow is identified based on IP- and next-level protocol header information. Section 4.4 of [RFC8939] (DetNet Flow Aggregation) defines the ways in which aggregation is supported through the use of prefixes, wildcards, lists, and port ranges. Collectively, this results in the fairly straightforward procedures defined in the next section.
[RFC8964]のセクション5.1あたり、Detnet MPLSデータプレーンは単一のアプリフローをサポートするために単一のSラベルを使用します。[RFC8939]のセクション5.1のDetnet IPフロー識別手順IPおよび次のプロトコルヘッダ情報に基づいて単一のDETNETフローが識別されることを示しています。[RFC8939]（DetNet Flow Aggregation）のセクション4.4は、プレフィックス、ワイルドカード、リスト、およびポート範囲を使用して集計がサポートされる方法を定義します。まとめると、これは次のセクションで定義されているかなり簡単な手順を実行します。
As shown in Figure 2, DetNet relay nodes are responsible for the mapping of a DetNet flow, at the service sub-layer, from the IP to MPLS DetNet data planes and back again. Their related DetNet IP over DetNet MPLS data plane operation is comprised of two sets of procedures: the mapping of flow identifiers and ensuring proper traffic treatment.
図2に示すように、Detnet Relayノードは、サービスサブレイヤのDetNetフローのマッピング、IPからMPLS DetNetデータプレーン、および再びバックされます。Detnet MPLSのデータプレーン操作は、2つの手順で構成されています。フロー識別子のマッピングと適切なトラフィック処理を確実にします。
Mapping of IP to DetNet MPLS is similar for DetNet IP flows and IP flows. The six-tuple of IP is mapped to the S-Label in both cases. The various fields may be mapped or ignored when going from IP to MPLS.
IPへのIPへのマッピングMPLSはDetnet IPフローとIPフローに似ています。両方の場合において、IPの6タプルがSラベルにマッピングされます。IPからMPLSに移動すると、さまざまなフィールドをマッピングまたは無視できます。
The main differences of mapping IP to DetNet MPLS (compared to plain MPLS) are that (1) there is a mandatory flow identification to make the forwarding decision (i.e., forwarding is not based on FEC), (2) the d-CW (DetNet Control Word) is mandatory for the MPLS encapsulation, and (3) during forwarding over the DetNet MPLS network, treatment specific to DetNet flows is needed.
IPへのマッピングIPの主な違い（プレーンMPLSと比較して）は、（1）転送決定を行うための必須のフロー識別があります（すなわち、転送はFECに基づいていない）、（2）D-CW（Detnet Control Word）はMPLSカプセル化に必須であり、（3）DetNet MPLSネットワークを介して転送中に、DetNet NETフローに固有の処理が必要です。
5.1. DetNet IP over DetNet MPLS Flow Identification and Aggregation Procedures
5.1. Detnet IP OVER DETNET MPLSフロー識別と集計手順
A DetNet relay node (ingress T-PE) that sends a DetNet IP flow over a DetNet MPLS network MUST map a DetNet IP flow, as identified in [RFC8939], into a single MPLS DetNet flow and MUST process it in accordance to the procedures defined in [RFC8964]. PRF MAY be supported at the MPLS level for DetNet IP flows sent over a DetNet MPLS network. Aggregation MAY be supported as defined in Section 4.4 of [RFC8964]. Aggregation considerations in [RFC8939] MAY be used to identify an individual DetNet IP flow. The provisioning of the mapping of DetNet IP flows to DetNet MPLS flows MUST be supported via configuration, e.g., via the Controller Plane.
DetNet MPLSネットワークを介してDetNet IPフローを送信するDetnet Relationノード（入力T-PE）は、[RFC8939]で識別されているDetnet IPフローを単一のMPLS Detnetフローにマッピングする必要があり、その手順に従って処理する必要があります。[RFC8964]で定義されています。DETNET MPLSネットワークを介して送信されたDetNet IPフローのMPLSレベルでPRFがサポートされることがあります。[RFC8964]のセクション4.4で定義されているように、集約はサポートされている可能性があります。[RFC8939]での集計考慮事項は、個々のDetNet IPフローを識別するために使用されます。Detnet IPフローのDetNet MPLSフローへのマッピングのプロビジョニングは、例えばコントローラプレーンを介して構成を介してサポートされなければならない。
A DetNet relay node (egress T-PE) MAY be provisioned to handle packets received via the DetNet MPLS data plane as DetNet IP flows. A single incoming DetNet MPLS flow MAY be treated as a single DetNet IP flow, without examination of IP headers. Alternatively, packets received via the DetNet MPLS data plane MAY follow the normal DetNet IP flow identification procedures defined in Section 5.1 of [RFC8939].
Detnet IPフローとしてDetNet MPLSデータプレーンを介して受信したパケットを処理するために、DetNet Netry Node（Egress T-PE）をプロビジョニングすることができる。IPヘッダを検査することなく、単一の受信Detnet MPLSフローを単一のDetNet IPフローとして扱うことができます。あるいは、DetNet MPLSデータプレーンを介して受信されたパケットは、[RFC8939]のセクション5.1で定義されている通常のDetNet IPフロー識別手順に従うことができる。
An implementation MUST support the provisioning for handling any packet flows received via the DetNet MPLS data plane as DetNet IP flows via configuration. Note that such configuration MAY include support from PREOF on the incoming DetNet MPLS flow.
実装は、Detnet MPLSデータプレーンを介して受信されたパケットフローをDetnet IPフローとして処理するためのプロビジョニングをサポートしなければなりません。そのような構成は、受信Detnet MPLSフローのPREOFからのサポートを含み得ることに注意してください。
Note: Using Layer 4 (L4) transport protocols (e.g., for multipath) are out of scope of this document both for a single flow and aggregate flows.
注：レイヤ4（L4）トランスポートプロトコル（例えば、マルチパス）を使用すると、単一のフローと集約フローの両方でこの文書の範囲外です。
The traffic treatment required for a particular DetNet IP flow is provisioned via configuration or the Controller Plane. When a DetNet IP flow is sent over DetNet MPLS, a DetNet relay node MUST ensure that the provisioned DetNet IP traffic treatment is provided at the forwarding sub-layer as described in Section 5.2 of [RFC8964]. Note that PRF MAY be utilized when sending IP over MPLS.
特定のDetNet IPフローに必要なトラフィック処理は、構成またはコントローラプレーンを介してプロビジョニングされます。Detnet IPフローがDetnet MPLSを介して送信されると、Detnet Relayノードは、[RFC8964]のセクション5.2のセクション5.2に記載されているように、プロビジョニングされたDetnet IPトラフィック処理が転送サブレイヤに提供されることを確認する必要があります。PRFはMPLSを介してIPを送信するときに利用され得ることに注意してください。
Traffic treatment for DetNet IP flows received over the DetNet MPLS data plane MUST follow Section 5.3 of [RFC8939] (DetNet IP Traffic Treatment Procedures).
Detnet MPLSデータプレーンで受信されたDetnet IPフローのトラフィック処理は、[RFC8939]（DetNet IPトラフィック処理手順）のセクション5.3に続く必要があります。
The following summarizes the set of information that is needed to support DetNet IP over DetNet MPLS at the MPLS ingress node:
以下は、MPLS入力ノードでDetnet IPを介してDetnet IPをサポートするために必要な情報のセットをまとめたものです。
* Each MPLS App-Flow is selected from the incoming IP traffic using the IP flow identification information defined in [RFC8939]. This information is summarized in Section 5.1 of that document and includes all wildcards, port ranges, and the ability to ignore specific IP fields.
* [RFC8939]で定義されているIPフロー識別情報を使用して、各MPLS APP-FLUEが着信IPトラフィックから選択されます。この情報はその文書のセクション5.1に要約されており、すべてのワイルドカード、ポート範囲、および特定のIPフィールドを無視する機能を含みます。
* The DetNet MPLS service that is to be used to send the matching IP traffic. This matching information is provided in Section 5.1 of [RFC8964] and includes both service and traffic delivery information.
* 一致するIPトラフィックを送信するために使用されるDetnet MPLSサービス。このマッチング情報は[RFC8964]のセクション5.1で提供されており、サービスとトラフィック配信情報の両方を含みます。
The following summarizes the set of information that is needed to support DetNet IP over DetNet MPLS at the MPLS egress node:
以下は、MPLS出力ノードでDetnet IPを介してDetnet IPをサポートするために必要な情報のセットをまとめたものです。
* The S-Label value that identifies the encapsulated App-flow traffic.
* カプセル化されたアプリフロートラフィックを識別するSラベル値。
* For each S-Label, how the received traffic is to be handled. The traffic may be processed as any other DetNet IP traffic as defined in this document or in [RFC8939], or the traffic may be directly treated as an MPLS App-flow for additional processing according to [RFC8964].
* 各Sラベルについて、受信したトラフィックをどのように処理するか。トラフィックは、このドキュメントまたは[RFC8939]で定義されている他のDetNet IPトラフィックとして処理されてもよいし、[RFC8964]に従って追加の処理のためのMPLSアプリフローとして直接扱うこともできます。
It is the responsibility of the DetNet Controller Plane to properly provision both flow identification information and the flow-specific resources needed to provide the traffic treatment to meet each flow's service requirements. This applies for aggregated and individual flows.
各フローのサービス要件を満たすためのトラフィック治療を提供するために必要なフロー識別情報とフロー固有のリソースの両方を適切に提供するのはDetNet Controller Planeの責任です。これは集約された個々のフローに適用されます。
General security considerations for DetNet are described in detail in [RFC9055]. DetNet MPLS and DetNet IP security considerations equally apply to this document and are described in [RFC8964] and [RFC8939].
Detnetの一般的なセキュリティ上の考慮事項は[RFC9055]に詳しく説明されています。Detnet MPLSおよびDetnet IPセキュリティ上の考慮事項は、この文書に等しく適用され、[RFC8964]と[RFC8939]に記載されています。
Security aspects that are unique to DetNet are those whose aim is to protect the support of specific quality-of-service aspects of DetNet, which are primarily to deliver data flows with extremely low packet loss rates and bounded end-to-end delivery latency.
Detnetに固有のセキュリティの面は、その目的がDetnetの特定のサービス品質の側面のサポートを保護することです。
The primary considerations for the data plane are to maintain integrity of data and delivery of the associated DetNet service traversing the DetNet network. Application flows can be protected through whatever means is provided by the underlying technology. For example, encryption may be used, such as that provided by IPsec [RFC4301] for IP flows and/or by an underlying sub-net using MACsec [IEEE802.1AE-2018] for IP-over-Ethernet (Layer 2) flows.
データプレーンに関する主な考慮事項は、データの完全性を維持し、Detnetネットワークを通過する関連するDetnetサービスの配信を維持することです。アプリケーションフローは、基礎となる技術によって提供されているものが何にもかかわらず保護できます。例えば、IPSec [RFC4301]がIPフローの場合など、および/またはIP - オーバーイーサネット（レイヤ2）の場合、MACSEC [IEEE802.1AE-2018]を使用して、IPsec [RFC4301]が提供するなど、暗号化を使用することができます。
From a data plane perspective, this document does not add or modify any header information.
データプレーンの観点から見ると、この文書はヘッダー情報を追加または変更しません。
At the management and control level, DetNet flows are identified on a per-flow basis, which may provide Controller Plane attackers with additional information about the data flows (when compared to Controller Planes that do not include per-flow identification). This is an inherent property of DetNet, which has security implications that should be considered when determining if DetNet is a suitable technology for any given use case.
管理レベルおよび制御レベルでは、DETNETフローはフローごとに識別され、これはデータフローに関する追加の情報を有するコントローラプレーン攻撃者に（フロー識別は含まないコントローラプレーンと比較した場合）。これはDetnetの固有の財産です。
To provide uninterrupted availability of the DetNet service, provisions can be made against DoS attacks and delay attacks. To protect against DoS attacks, excess traffic due to malicious or malfunctioning devices can be prevented or mitigated, for example, through the use of existing mechanisms such as policing and shaping applied at the input of a DetNet domain. To prevent DetNet packets from being delayed by an entity external to a DetNet domain, DetNet technology definitions can allow for the mitigation of man-in-the-middle attacks (for example, through use of authentication and authorization of devices within the DetNet domain).
Detnetサービスの中断のない可用性を提供するために、DOS攻撃や遅延攻撃に対して規定を行うことができます。DOS攻撃から保護するために、例えば、DetNetドメインの入力に適用されるポリシングやシェーピングなどの既存のメカニズムの使用を通じて、悪意のあるまたは故障した装置による過剰なトラフィックを防止または軽減することができる。Detnet PacketsがDetnetドメインの外部のエンティティによって遅延されないようにするために、Detnet Technologyの定義は中間攻撃の軽減を可能にします（たとえば、Detnetドメイン内のデバイスの認証と認可を通じて）。。
This document has no IANA actions.
この文書にはIANAの行動がありません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, "Deterministic Networking Architecture", RFC 8655, DOI 10.17487/RFC8655, October 2019, <https://www.rfc-editor.org/info/rfc8655>.
[RFC8655] Finn、N.、Thubert、P.、Varga、B.、およびJ. Farkas、「決定論的ネットワーキングアーキテクチャ」、RFC 8655、DOI 10.17487 / RFC8655、2019年10月、<https：//www.rfc-編集者.org / info / rfc8655>。
[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>.
[RFC8938] Varga、B.、Ed。、Farkas、J.、Berger、L.、Malis、A.、およびS.ブライアント、「決定論的ネットワーキング（DetnetInstring）データプレーンフレームワーク」、RFC 8938、DOI 10.17487 / RFC8938、2020年11月、<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>.
[RFC8939]バラジャ、B、ED。、Farkas、J.、Berger、L.、Fedyk、D.、およびS.Bryant、「決定論的ネットワーキング（DECTINAL）データプレーン：IP」、RFC 8939、DOI 10.17487 / RFC8939、2020年11月、<https：//www.rfc-editor.org/info/rfc8939>。
[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>.
[RFC8964] Varga、B.、Ed。、Farkas、J.、Berger、L.、Malis、A.、Bryant、S.、およびJ.Korhonen、「決定論的ネットワーキング（Detnetisticネットワーキング（Detnet）データプレーン：MPLS」、RFC 8964、DOI 10.17487 / RFC8964、2021年1月、<https://www.rfc-editor.org/info/rfc8964>。
[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>.
[RFC9055]グロスマン、E.、ED。、Mizrahi、T.、およびA.ハッカー、「決定論的ネットワーキング（Detnetistic Networking（Detnet）セキュリティ上の考慮事項」、RFC 9055、DOI 10.17487 / RFC9055、2021年6月、<https：//www.rfc-editor.org/info/rfc9055>。
[IEEE802.1AE-2018] IEEE, "IEEE Standard for Local and metropolitan area networks-Media Access Control (MAC) Security", IEEE 802.1AE-2018, DOI 10.1109/IEEESTD.2018.8585421, December 2018, <https://ieeexplore.ieee.org/document/8585421>.
[IEEE802.1ae-2018] IEEE、「地元の地域と首都圏のIEEE規格ネットワーク - メディアアクセス管理（Mac）セキュリティ」、IEEE 802.1ae-2018、DOI 10.1109 / IEEESTD.2018.8585421、2018年12月、<https：// ieeexplore.ieee.org / document / 8585421>。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC4301] Kent、S.およびK.SEO、「インターネットプロトコルのためのセキュリティアーキテクチャ」、RFC 4301、DOI 10.17487 / RFC4301、2005年12月、<https：//www.rfc-editor.org/info/rfc4301>。
Acknowledgements
謝辞
The authors wish to thank Pat Thaler, Norman Finn, Loa Andersson, David Black, Rodney Cummings, Ethan Grossman, Tal Mizrahi, David Mozes, Craig Gunther, George Swallow, Yuanlong Jiang, and Carlos J. Bernardos for their various contributions to this work.
著者らは、ターレ、ノーマンフィン、ロアアンダーソン、デビッドブラック、ロドニーカミングス、エタングロスマン、タイルミズラヒ、デビッドモズ、クレイグジョアン、そしてCarlos J. Bernardos、そしてCarlos J. Bernardos、そしてCarlos J. Bernardos、そしてCarlos J. Bernardos。
Contributors
貢献者
RFC 7322 limits the number of authors listed on the front page to a maximum of 5. The editor wishes to thank and acknowledge the following authors for contributing text to this document.
RFC 7322は、フロントページにリストされている作者の数を最大5に制限します。エディタは、この文書にテキストを拠出するための次の作者に感謝し、ご了承ください。
János Farkas Ericsson
JánosFarkas Ericsson.
Email: janos.farkas@ericsson.com
Andrew G. Malis Malis Consulting
Andrew G. Malis Malis Consulting.
Email: agmalis@gmail.com
János Farkas contributed substantially to the content of this document.
JánosFarkasは実質的にこの文書の内容に寄与しました。
Authors' Addresses
著者の住所
Balázs Varga (editor) Ericsson Budapest Magyar Tudosok krt. 11. 1117 Hungary
Balázsvarga（編集）エリクソンブダペストMagyar Tudosok Krt。11. 1117ハンガリー
Email: balazs.a.varga@ericsson.com
Lou Berger LabN Consulting, L.L.C.
Lou Berger Labn Consulting、L.C.
Email: lberger@labn.net
Don Fedyk LabN Consulting, L.L.C.
Don Fedyk Labn Consulting、L.L.c。
Email: dfedyk@labn.net
Stewart Bryant Futurewei Technologies
スチュワートブライアントフューチャーワイテクノロジー
Email: sb@stewartbryant.com
Jouni Korhonen
Jouni Korhonen
Email: jouni.nospam@gmail.com