[要約] RFC 9024は、Deterministic Networking (DetNet) Data Planeの実装に関する文書であり、IEEE 802.1 Time-Sensitive Networking (TSN) をMPLS (Multiprotocol Label Switching) 上で動作させる方法を定義しています。この技術は、遅延が厳しく制御されたネットワーク環境を必要とするアプリケーション、例えば産業オートメーション、音声・映像のリアルタイム配信、および車載ネットワークなどでの利用を目的としています。

Internet Engineering Task Force (IETF)                     B. Varga, Ed.
Request for Comments: 9024                                     J. Farkas
Category: Standards Track                                       Ericsson
ISSN: 2070-1721                                                 A. Malis
                                                        Malis Consulting
                                                               S. Bryant
                                                  Futurewei Technologies
                                                                D. Fedyk
                                                 LabN Consulting, L.L.C.
                                                               June 2021
        

Deterministic Networking (DetNet) Data Plane: IEEE 802.1 Time-Sensitive Networking over MPLS

決定論的ネットワーキング(DETNET)データプレーン:IEEE 802.1 MPLS上の時間依存ネットワーキング

Abstract

概要

This document specifies the Deterministic Networking data plane when Time-Sensitive Networking (TSN) networks are interconnected over a DetNet MPLS network.

このドキュメントは、時間依存ネットワーキング(TSN)ネットワークがDetNet MPLSネットワークを介して相互接続されている場合の決定論的ネットワーキングデータプレーンを指定します。

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/rfc9024.

この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc9024で入手できます。

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.  IEEE 802.1 TSN over DetNet MPLS Data Plane Scenario
   4.  DetNet MPLS Data Plane
     4.1.  Overview
     4.2.  TSN over DetNet MPLS Encapsulation
   5.  TSN over MPLS Data Plane Procedures
     5.1.  Edge Node TSN Procedures
     5.2.  Edge Node DetNet Service Proxy Procedures
     5.3.  Edge Node DetNet Service and Forwarding Sub-Layer
           Procedures
   6.  Controller Plane (Management and Control) Considerations
   7.  Security Considerations
   8.  IANA Considerations
   9.  References
     9.1.  Normative References
     9.2.  Informative References
   Acknowledgements
   Authors' Addresses
        
1. Introduction
1. はじめに

The Time-Sensitive Networking Task Group (TSN TG) within the IEEE 802.1 Working Group deals with deterministic services through IEEE 802 networks. Deterministic Networking (DetNet) defined by the IETF is a service that can be offered by an L3 network to DetNet flows. General background and concepts of DetNet can be found in [RFC8655].

IEEE 802.1ワーキンググループ内の時間依存ネットワーキングタスクグループ(TSN TG)は、IEEE 802ネットワークを介して決定論的サービスを扱います。IETFによって定義された決定論的ネットワーキング(Detnet)は、DetnetフローにL3ネットワークによって提供され得るサービスです。Detnetの一般的な背景と概念は[RFC8655]にあります。

This document specifies the use of a DetNet MPLS network to interconnect TSN nodes/network segments. The DetNet MPLS data plane is defined in [RFC8964].

このドキュメントは、TSNノード/ネットワークセグメントを相互接続するためのDetNet MPLSネットワークの使用を指定します。Detnet MPLSデータプレーンは[RFC8964]で定義されています。

2. Terminology
2. 用語
2.1. Terms Used in This Document
2.1. この文書で使用される用語

This document uses the terminology and concepts established in the DetNet architecture [RFC8655] [RFC8938] [RFC8964]. TSN-specific terms are defined in the TSN TG of the IEEE 802.1 Working Group. The reader is assumed to be familiar with these documents and their terminology.

この文書では、DetNet Architecture [RFC8655] [RFC8938] [RFC8964]で定められている用語と概念を使用しています。TSN固有の用語は、IEEE 802.1ワーキンググループのTSN TGで定義されています。リーダーはこれらの文書とその用語に精通していると見なされます。

2.2. Abbreviations
2.2. 略語

The following abbreviations are used in this document:

この文書では、次の略語が使用されています。

AC Attachment Circuit

ACアタッチメント回路

CE Customer Edge equipment

CEカスタマーエッジ装置

d-CW DetNet Control Word

D-CW Detnet Control Word.

DetNet Deterministic Networking

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

DF DetNet Flow

DF DetNetフロー

FRER Frame Replication and Elimination for Redundancy (TSN function)

フレームの複製と冗長性(TSN機能)の除去

L2 Layer 2

L2層2

L2VPN Layer 2 Virtual Private Network

L2VPNレイヤ2仮想プライベートネットワーク

L3 Layer 3

L3層3

LSP Label Switched Path

LSPラベルスイッチパス

LSR Label Switching Router

LSRラベルスイッチングルータ

MPLS Multiprotocol Label Switching

MPLSマルチプロトコルラベルスイッチング

MPLS-TE Multiprotocol Label Switching - Traffic Engineering

MPLS-TEマルチプロトコルラベルスイッチング - トラフィックエンジニアリング

NSP Native Service Processing

NSPネイティブサービス処理

OAM Operations, Administration, and Maintenance

OAMの操作、管理、および保守

PE Provider Edge

PEプロバイダのエッジ

PREOF Packet Replication, Elimination and Ordering Functions

パケットのレプリケーション、除去および順序付け機能

PW Pseudowire

PW擬似ワイヤー

S-PE Switching Provider Edge

S-PEスイッチングプロバイダエッジ

T-PE Terminating Provider Edge

T-PE終端プロバイダーエッジ

TSN Time-Sensitive Network

TSNの時間依存ネットワーク

2.3. Requirements Language
2.3. 要件言語

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]で説明されているように、すべて大文字の場合にのみ解釈されます。

3. IEEE 802.1 TSN over DetNet MPLS Data Plane Scenario
3. IEEE 802.1 TSN上のDetnet MPLSデータプレーンシナリオ

Figure 1 shows IEEE 802.1 TSN end stations operating over a TSN-aware DetNet service running over an MPLS network. DetNet edge nodes sit at the boundary of a DetNet domain. They are responsible for mapping non-DetNet-aware L2 traffic to DetNet services. They also support the imposition and disposition of the required DetNet encapsulation. These are functionally similar to PW T-PE nodes, which use MPLS-TE LSPs. In this example, TSN Streams are simple applications over DetNet flows. The specifics of this operation are discussed later in this document.

図1は、MPLSネットワークを介して実行されているTSN認識Detnetサービスを介して動作するIEEE 802.1 TSNエンドステーションを示しています。Detnet EdgeノードはDetnetドメインの境界に座ります。これらは、Detnet ServicesへのDetnet対応のL2トラフィックをマッピングする責任があります。彼らはまた、必要なDetnetカプセル化の面付けおよび配置をサポートする。これらは、MPLS-TE LSPを使用するPW T-PEノードと機能的に似ています。この例では、TSNストリームはDetNetフローを介した単純なアプリケーションです。この操作の詳細については、この文書の後半で説明します。

TSN Edge Transit Edge TSN End System Node Node Node End System (T-PE) (LSR) (T-PE)

TSNエッジトランジットエッジTSNエンドシステムノードノードノードエンドシステム(T-PE)(LSR)(T-PE)

   +----------+                                             +----------+
   |   TSN    | <-------- End-to-End TSN Service ---------> |   TSN    |
   |  Applic. |                                             |  Applic. |
   +----------+  +.........+                   +.........+  +----------+
   |          |  | \S-Proxy:                   :S-Proxy/ |  |          |
   |   TSN    |  |   +.+---+<-- DetNet flow -->+---+ |   |  |   TSN    |
   |          |  |TSN| |Svc|                   |Svc| |TSN|  |          |
   +----------+  +---+ +---+    +----------+   +---+ +---+  +----------+
   |   L2     |  | L2| |Fwd|    |Forwarding|   |Fwd| |L2 |  |   L2     |
   +------.---+  +-.-+ +-.-+    +---.----.-+   +--.+ +-.-+  +---.------+
          :  Link  :     /  ,-----.  \   :  Link  :   /  ,-----. \
          +........+     +-[  Sub- ]-+   +........+   +-[  TSN  ]-+
                           [Network]                    [Network]
                            `-----'                      `-----'
        
                       |<------ DetNet MPLS ------>|
           |<---------------------- TSN   --------------------->|
        

Figure 1: A TSN over DetNet MPLS-Enabled Network

図1:Detnet MPLS対応ネットワーク上のTSN

In this example, edge nodes provide a service proxy function that "associates" the DetNet flows and native flows (i.e., TSN Streams) at the edge of the DetNet domain. TSN Streams are treated as App-flows for DetNet. The whole DetNet domain behaves as a TSN relay node for the TSN Streams. The service proxy behaves as a port of that TSN relay node.

この例では、エッジノードは、DetNetドメインのエッジでDetNetフローおよびネイティブフロー(すなわち、TSNストリーム)を「関連付ける」サービスプロキシ関数を提供する。TSNストリームはDetnet用のアプリフローとして扱われます。Detnetドメイン全体はTSNストリームのTSNリレーノードとして動作します。サービスプロキシは、そのTSNリレーノードのポートとして動作します。

Figure 2 illustrates how DetNet can provide services for IEEE 802.1 TSN end systems, CE1 and CE2, over a DetNet-enabled MPLS network. Edge nodes E1 and E2 insert and remove the required DetNet data plane encapsulation. The 'X' in the edge nodes and relay node, R1, represent a potential DetNet compound flow packet replication and elimination point. This conceptually parallels L2VPN services and could leverage existing related solutions as discussed below.

Detnetは、Detnet対応MPLSネットワークを介して、IEEE 802.1 TSNエンドシステム、CE1、CE2のサービスを提供できる方法を示しています。エッジノードE1とE2必要なDetNetデータプレーンカプセル化を挿入して削除します。エッジノードおよび中継ノードR1内の「x」は、潜在的なDetnet Complect Flowパケットの複製と除去点を表します。これは概念的にL2VPNサービスを並べ替え、以下に説明するように既存の関連解決策を活用することができます。

        TSN    |<------- End-to-End DetNet Service ------>|  TSN
       Service |         Transit          Transit         | Service
   TSN  (AC)   |        |<-Tnl->|        |<-Tnl->|        |  (AC)  TSN
   End    |    V        V    1  V        V   2   V        V   |    End
   System |    +--------+       +--------+       +--------+   |  System
   +---+  |    |   E1   |=======|   R1   |=======|   E2   |   |   +---+
   |   |--|----|._X_....|..DF1..|.._ _...|..DF3..|...._X_.|---|---|   |
   |CE1|  |    |    \   |       |   X    |       |   /    |   |   |CE2|
   |   |       |     \_.|..DF2..|._/ \_..|..DF4..|._/     |       |   |
   +---+       |        |=======|        |=======|        |       +---+
       ^       +--------+       +--------+       +--------+       ^
       |        Edge Node       Relay Node        Edge Node       |
       |          (T-PE)           (S-PE)          (T-PE)         |
       |                                                          |
       |<- TSN -> <------- TSN over DetNet MPLS -------> <- TSN ->|
       |                                                          |
       |<-------- Time-Sensitive Networking (TSN) Service ------->|
        

X = Service protection DFx = DetNet member flow x over a TE LSP AC = Attachment Circuit Tnl = Tunnel

X =サービス保護DFX = DETNETメンバーフローX TE LSP AC =添付回路回路TNL =トンネル

Figure 2: IEEE 802.1TSN over DetNet

図2:Detnetの上のIEEE 802.1TS

4. DetNet MPLS Data Plane
4. Detnet MPLSデータプレーン
4.1. Overview
4.1. 概要

The basic approach defined in [RFC8964] supports the DetNet service sub-layer based on existing PW encapsulations and mechanisms and supports the DetNet forwarding sub-layer based on existing MPLS Traffic Engineering encapsulations and mechanisms.

[RFC8964]で定義されている基本的なアプローチは、既存のPWカプセル化とメカニズムに基づいてDetNet Serviceサブレイヤをサポートし、既存のMPLSトラフィックエンジニアリングカプセル化とメカニズムに基づいてDetNet転送サブレイヤをサポートします。

A node operating on a DetNet flow in the DetNet service sub-layer, i.e., a node processing a DetNet packet that has the S-Label as top of stack, uses the local context associated with that S-Label. For example, a received F-Label can be used to determine what local DetNet operation(s) is applied to that packet. An S-Label may be unique when taken from the platform label space [RFC3031], which would enable correct DetNet flow identification regardless of which input interface or LSP the packet arrives on. The service sub-layer functions (i.e., PREOF) use a DetNet control word (d-CW).

DetNetサービスサブレイヤのDetNetフローで動作するノード、すなわち、Sラベルを有するDetNetパケットをスタックの上にあるノード処理は、そのSラベルに関連付けられているローカルコンテキストを使用する。たとえば、受信されたFラベルを使用して、そのパケットにローカルDetnet操作が適用されているものを決定できます。Sラベルは、プラットフォームラベルスペース[RFC3031]から取られたときに固有である場合があります。これは、パケットがどの入力インターフェイスまたはLSPに到着するかに関係なく、正しいDetnet Flow IDを有効にします。サービスサブレイヤ関数(すなわち、PREOF)はDetNet制御ワード(D - CW)を使用する。

The DetNet MPLS data plane builds on MPLS Traffic Engineering encapsulations and mechanisms to provide a forwarding sub-layer that is responsible for providing resource allocation and explicit routes. The forwarding sub-layer is supported by one or more forwarding labels (F-Labels).

Detnet MPLSデータプレーンは、リソース割り当てと明示的なルートの提供を担当する転送サブレイヤーを提供するために、MPLSトラフィックエンジニアリングカプセル化とメカニズムに基づいています。転送サブレイヤは、1つ以上の転送ラベル(Fラベル)によってサポートされています。

DetNet edge/relay nodes are DetNet service sub-layer aware, understand the particular needs of DetNet flows, and provide both DetNet service and forwarding sub-layer functions. They add, remove, and process d-CWs, S-Labels, and F-Labels as needed. MPLS DetNet nodes and transit nodes include DetNet forwarding sub-layer functions -- notably, support for explicit routes and resource allocation to eliminate (or reduce) congestion loss and jitter. Unlike other DetNet node types, transit nodes provide no service sub-layer processing.

Detnet Edge / RelayノードはDetnet Service Sub-Layer認識で、Detnet Flowsの特定のニーズを理解し、Detnetサービスと転送サブレイヤ機能の両方を提供します。必要に応じて、D-CWS、Sラベル、およびFラベルを追加、削除、および処理します。MPLS Detnetノードおよびトランジットノードには、Detnet Forwardingサブレイヤー機能が含まれます。他のDetnetノードタイプとは異なり、トランジットノードはサービスサブレイヤ処理を提供しません。

4.2. TSN over DetNet MPLS Encapsulation
4.2. TSN over Detnet MPLSカプセル化

The basic encapsulation approach is to treat a TSN Stream as an App-flow from the DetNet MPLS perspective. The corresponding example is shown in Figure 3. Note that three example flows are shown in the figure.

基本的なカプセル化アプローチは、Detnet MPLSの観点からTSNストリームをアプリフローとして扱うことです。対応する例を図3に示します。なお、図示の例示的なフローの例を示します。

                /->     +------+  +------+  +------+   TSN      ^ ^
       MPLS     |       |  X   |  |  X   |  |  X   |<- Appli    : :
     App-Flow <-+       +------+  +------+  +------+   cation   : :(1)
                |       |TSN-L2|  |TSN-L2|  |TSN-L2|            : v
                \-> +---+======+--+======+--+======+-----+      :
                        | d-CW |  | d-CW |  | d-CW |            :
     DetNet-MPLS        +------+  +------+  +------+            :(2)
                        |Labels|  |Labels|  |Labels|            v
                    +---+======+--+======+--+======+-----+
     Link/Sub-Network   |  L2  |  | TSN  |  | UDP  |
                        +------+  +------+  +------+
                                            |  IP  |
                                            +------+
                                            |  L2  |
                                            +------+
         (1) TSN Stream
         (2) DetNet MPLS Flow
        

Figure 3: Examples of TSN over MPLS Encapsulation Formats

図3:MPLSカプセル化フォーマット上のTSNの例

In the figure, "Application" indicates the application payload carried by the TSN network. "MPLS App-Flow" indicates that the TSN Stream is the payload from the perspective of the DetNet MPLS data plane defined in [RFC8964]. A single DetNet MPLS flow can aggregate multiple TSN Streams.

図中、「アプリケーション」は、TSNネットワークによって運ばれるアプリケーションペイロードを示す。"MPLS APP-FLOW"は、TSNストリームが[RFC8964]で定義されているDetnet MPLSデータプレーンの観点からのペイロードであることを示します。単一のDetnet MPLSフローが複数のTSNストリームを集約できます。

      |  Note: Network fragmentation for DetNet is not supported and
      |  MUST be avoided.  The reason for this is that network
      |  fragmentation is not consistent with the packet delivery times
      |  needed for DetNet.  Therefore, when IP is used as the sub-
      |  network, IPv6 fragmentation MUST NOT be used, and IPv4 packets
      |  MUST be sent with the DF bit set.  This means that the network
      |  operator MUST ensure that all the DetNet encapsulation overhead
      |  plus the maximum TSN App-flow frame size does not exceed the
      |  DetNet network's MTU.
        
5. TSN over MPLS Data Plane Procedures
5. MPLSデータプレーン手順を介してTSN

The description of edge node procedures and functions for TSN over DetNet MPLS scenarios follows the concepts from [RFC3985] and covers the edge node components shown in Figure 1. In this section, the following procedures of DetNet edge nodes are described:

Detnet MPLSシナリオのエッジノード手順と関数の説明は、[RFC3985]からの概念に従います。図1に示すエッジノードコンポーネントをカバーします。このセクションでは、Detnet Edgeノードの次の手順について説明します。

* TSN related (Section 5.1)

* TSN関連(セクション5.1)

* DetNet Service Proxy (Section 5.2)

* Detnet Service Proxy(セクション5.2)

* DetNet service and forwarding sub-layer (Section 5.3)

* Detnetサービスと転送サブレイヤー(セクション5.3)

The subsections describe procedures for forwarding packets by DetNet edge nodes, where such packets are received from either directly connected CEs (TSN nodes) or some other DetNet edge nodes.

サブセクションは、DetNet Edgeノードによってパケットを転送するための手順を説明し、そこでそのようなパケットは直接接続されたCES(TSNノード)または他のいくつかのDetNetエッジノードのいずれかから受信される。

5.1. Edge Node TSN Procedures
5.1. エッジノードTSNプロシージャ

The TSN TG of the IEEE 802.1 Working Group has defined (and is defining) a number of amendments to [IEEE8021Q] that provide zero congestion loss and bounded latency in bridged networks. [IEEE8021CB] defines packet replication and elimination functions for a TSN network.

IEEE 802.1ワーキンググループのTSN TGは、ブリッジネットワークで輻輳損失ゼロの輻輳損失と境界待ち時間を提供する[IEEE8021Q]の修正を定義しています)を定義しています。[IEEE8021CB] TSNネットワークのパケットレプリケーションと除去機能を定義します。

The implementation of a TSN entity (i.e., TSN packet processing functions) must be compliant with the relevant IEEE 802.1 standards.

TSNエンティティの実装(すなわち、TSNパケット処理機能)は、関連するIEEE 802.1規格に準拠している必要があります。

TSN-specific functions are executed on the data received by the DetNet edge node from the connected CE before being forwarded to connected CE(s) or presented to the DetNet service proxy function for transmission across the DetNet domain. TSN-specific functions are also executed on the data received from a DetNet PW by a PE before the data is output on the AC(s).

TSN固有の関数は、接続されているCEからDetNet Edgeノードによって受信されたデータに対して、接続されているCE(S)に転送されるか、DetNetドメイン全体にわたって送信するためにDetNetサービスプロキシ関数に提示されます。AC(S)にデータが出力される前に、DetNet PWからDETNET PWから受信したデータに対してTSN特有の機能も実行される。

The TSN packet processing function(s) of edge nodes (T-PE) belongs to the NSP [RFC3985] block. This is similar to other functionalities being defined by standards bodies other than the IETF (for example, in the case of Ethernet, stripping, overwriting, or adding VLAN tags, etc.). Depending on the TSN role of the edge node in the end-to-end TSN service, selected TSN functions are supported.

エッジノード(T - PE)のTSNパケット処理機能は、NSP [RFC3985]ブロックに属する。これは、IETF以外の標準ボディによって定義されている他の機能と似ています(たとえば、イーサネット、ストリッピング、上書き、またはVLANタグなどの追加など)。エンドツーエンドTSNサービスのエッジノードのTSNロールによっては、選択したTSN機能がサポートされています。

When a PE receives a packet from a CE on a given AC with DetNet service, it first checks via Stream identification (see Clause 6 of [IEEE8021CB] and [IEEEP8021CBdb]) whether the packet belongs to a configured TSN Stream (i.e., App-flow from the DetNet perspective). If no Stream ID is matched and no other (VPN) service is configured for the AC, then the packet MUST be dropped. If there is a matching TSN Stream, then the Stream-ID-specific TSN functions are executed (e.g., ingress policing, header field manipulation in the case of active Stream identification, FRER, etc.). Source Media Access Control (MAC) lookup may also be used for local MAC address learning.

PEがDetNetサービスを使用して特定のACのCEからパケットを受信すると、最初にストリーム識別を介してチェックします([IEEE8021CB]、[IEEEEP8021CBDB]の順序6)。Detnetの観点からの流れ)。AC用にストリームIDが一致しない場合、他の(VPN)サービスが設定されていない場合は、パケットをドロップする必要があります。一致するTSNストリームがある場合、ストリームID固有のTSN関数が実行される(例えば、アクティブストリーム識別の場合は、ヘッダフィールド操作、フレアなど)。ソースメディアアクセス制御(MAC)ルックアップは、ローカルMACアドレス学習にも使用できます。

If the PE decides to forward the packet, the packet MUST be forwarded according to the TSN-Stream-specific configuration to connected CE(s) (in case of local bridging) and/or to the DetNet service proxy (in case of forwarding to remote CE(s)). If there are no TSN-Stream-specific forwarding configurations, the PE MUST flood the packet to other locally attached CE(s) and to the DetNet service proxy. If the administrative policy on the PE does not allow flooding, the PE MUST drop the packet.

PEがパケットを転送することを決定した場合、パケットは、(ローカルブリッジングの場合)および/またはDetNetサービスプロキシへのTSNストリーム固有の設定に従って転送されなければならない(転送の場合)。リモートCE(S)。TSNストリーム固有の転送構成がない場合、PEはパケットを他のローカル接続されたCEとDetnetサービスプロキシにフラッドフラッドしなければなりません。PEの管理ポリシーがフラッディングを許可しない場合、PEはパケットをドロップする必要があります。

When a TSN entity of the PE receives a packet from the DetNet service proxy, it first checks via Stream identification (see Clause 6 of [IEEE8021CB] and [IEEEP8021CBdb]) whether the packet belongs to a configured TSN Stream. If no Stream ID is matched, then the packet is dropped. If there is a matching TSN Stream, then the Stream-ID-specific TSN functions are executed (e.g., header field manipulation in case of active Stream identification, FRER, etc.). Source MAC lookup may also be used for local MAC address learning.

PEのTSNエンティティがDetnetサービスプロキシからパケットを受信すると、最初にストリーム識別経由でチェックします([IEEE8021CB]、[IEEEEP8021CBDB]の順序6)。パケットが設定されたTSNストリームに属するかどうか。ストリームIDが一致しない場合、パケットはドロップされます。一致するTSNストリームがある場合、ストリームID固有のTSN関数が実行される(例えば、アクティブストリーム識別、フレーサーなどの場合はヘッダフィールド操作)。ソースMACルックアップは、ローカルMACアドレス学習にも使用できます。

If the PE decides to forward the packet, the packet is forwarded according to the TSN-Stream-specific configuration to connected CE(s). If there are no TSN-Stream-specific forwarding configurations, the PE floods the packet to locally attached CE(s). If the administrative policy on the PE does not allow flooding, the PE drops the packet.

PEがパケットを転送することを決定した場合、パケットはTSNストリーム固有の設定に従って接続されているCEに従って転送されます。TSNストリーム固有の転送構成がない場合、PEはパケットをローカルに接続されているCEにフラッドします。PE上の管理ポリシーがフラッディングを許可しない場合、PEはパケットをドロップします。

Implementations of this document SHALL use management and control information to ensure TSN-specific functions of the edge node according to the expectations of the connected TSN network.

この文書の実装は、接続されているTSNネットワークの期待に応じてエッジノードのTSN固有の機能を確保するために管理および制御情報を使用するものとします。

5.2. Edge Node DetNet Service Proxy Procedures
5.2. エッジノードDetnetサービスプロキシプロシージャ

The service proxy function maps between App-flows and DetNet flows. The DetNet edge node TSN entity MUST support the TSN Stream identification functions (as defined in Clause 6 of [IEEE8021CB] and [IEEEP8021CBdb]) and the related managed objects (as defined in Clause 9 of [IEEE8021CB] and [IEEEP8021CBdb]) to recognize the packets related to App-flow. The service proxy presents TSN Streams as an App-flow to a DetNet flow.

サービスプロキシ関数は、アプリフローとDetnet Flowsの間のマップです。DetNet Edge Node TSNエンティティは、(IEEE8021CBの[IEEE8021CB]、[IEEEEP8021CBDB]の句6で定義されているように)および関連する管理対象オブジェクト([IEEE8021CB]および[IEEEEP8021CBDB])を認識するようにサポートされている必要があります。アプリフローに関連するパケット。サービスプロキシはTSNストリームをDetnetフローへのアプリフローとして提示します。

When a DetNet service proxy receives a packet from the TSN entity, it MUST check whether such an App-flow is present in its mapping table. If present, it associates the internal DetNet flow ID to the packet and MUST forward it to the DetNet service and forwarding sub-layers. If no match is found, it MUST drop the packet.

Detnet Service ProxyがTSNエンティティからパケットを受信すると、そのようなアプリフローがそのマッピングテーブルに存在するかどうかを確認する必要があります。存在する場合は、内部Detnet Flow IDをパケットに関連付け、それをDetnetサービスと転送サブレイヤーに転送する必要があります。一致しない場合は、パケットを削除する必要があります。

When a DetNet service proxy receives a packet from the DetNet service and forwarding sub-layers, it MUST be forwarded to the edge node TSN entity.

Detnet Service ProxyがDetnetサービスからパケットを受信してサブレイヤーを転送する場合は、エッジノードTSNエンティティに転送する必要があります。

Implementations of this document SHALL use management and control information to map a TSN Stream to a DetNet flow. N:1 mapping (aggregating multiple TSN Streams in a single DetNet flow) SHALL be supported. The management or control function that provisions flow mapping SHALL ensure that adequate resources are allocated and configured to fulfill the service requirements of the mapped flows.

この文書の実装は、TSNストリームをDetNetフローにマッピングするために管理情報と制御情報を使用しなければならない。N:1マッピング(単一のDETNETフローで複数のTSNストリームを集約する)をサポートする。プロビジョニングフローマッピングの管理機能または管理機能は、適切なリソースが割り当てられ、マッピングされたフローのサービス要件を満たすように構成されていることを確認しなければならない。

Due to the (intentional) similarities of the DetNet PREOF and TSN FRER functions, service protection function interworking is possible between the TSN and the DetNet domains. Such service protection interworking scenarios might require copying of sequence number fields from TSN (L2) to PW (MPLS) encapsulation. However, such interworking is out of scope in this document and is left for further study.

Detnet PREOFおよびTSNフレーター機能の(意図的な)類似性のために、TSNとDetNetドメインの間でサービス保護機能インターワーキングが可能です。そのようなサービス保護インターワーキングシナリオは、TSN(L2)からPW(MPLS)カプセル化へのシーケンス番号フィールドのコピーを必要とする可能性があります。しかし、そのようなインターワーキングはこの文書の範囲外であり、さらなる研究のために残されています。

5.3. Edge Node DetNet Service and Forwarding Sub-Layer Procedures
5.3. エッジノードDetnetサービスと転送サブレイヤプロシージャ

In the design presented in [RFC8964], an MPLS service label (the S-Label), similar to a PW label [RFC3985], is used to identify both the DetNet flow identity and the MPLS payload type. The DetNet sequence number is carried in the d-CW, which carries the Data/OAM discriminator as well. In [RFC8964], two sequence number sizes are supported: a 16-bit sequence number and a 28-bit sequence number.

[RFC8964]で提示されたデザインでは、PWラベル[RFC3985]と同様のMPLSサービスラベル(Sラベル)が、Detnet Flow IDとMPLSペイロードタイプの両方を識別するために使用されます。DETNETシーケンス番号はD-CWで搭載されており、データ/ OAM弁別器も搭載しています。[RFC8964]では、2つのシーケンス番号サイズがサポートされています:16ビットのシーケンス番号と28ビットのシーケンス番号。

PREOF functions and the provided service recovery are available only within the DetNet domain as the DetNet flow ID and the DetNet sequence number are not valid outside the DetNet network. MPLS (DetNet) edge nodes terminate all related information elements encoded in the MPLS labels.

FREOF FUNCTIOSおよび提供されたサービスリカバリは、DetNetフローIDとしてDetnet Flow IDとDetnet Cシーケンス番号がDetNetネットワークの外部では無効です。MPLS(DetNet)エッジノードは、MPLSラベルでエンコードされたすべての関連情報要素を終了します。

When a PE receives a packet from the service proxy function, it MUST handle the packet as defined in [RFC8964].

PEがサービスプロキシ関数からパケットを受信すると、[RFC8964]で定義されているパケットを処理する必要があります。

When a PE receives an MPLS packet from a remote PE, then, after processing the MPLS label stack, if the top MPLS label ends up being a DetNet S-Label that was advertised by this node, then the PE MUST forward the packet according to the configured DetNet service and forwarding sub-layer rules to other PE nodes or via the DetNet service proxy function towards locally connected CE(s).

PEがリモートPEからMPLSパケットを受信すると、MPLSラベルスタックを処理した後、上位MPLSラベルがこのノードによってアドバタイズされたDetnet Sラベルであると終了した場合、PEはパケットを転送する必要があります。設定されたDetnetサービスとサブレイヤーのルールを他のPEノードに、またはDetnet Service Proxy関数を介してローカルに接続されているCEに向かって。

For further details on DetNet service and forwarding sub-layers, see [RFC8964].

Detnet ServiceおよびForwarding副層の詳細については、[RFC8964]を参照してください。

6. Controller Plane (Management and Control) Considerations
6. コントローラプレーン(管理と制御)の考慮事項

Information related to TSN Stream(s) to DetNet flow mapping is required only for the service proxy function of MPLS (DetNet) edge nodes. From the data plane perspective, there is no practical difference based on the origin of flow-mapping-related information (management plane or control plane).

Detnet FlowマッピングへのTSNストリームに関する情報は、MPLS(DetNet)エッジノードのサービスプロキシ関数に対してのみ必要です。データプレーンの観点からは、フローマッピング関連情報(管理プレーンまたは制御プレーン)の原点に基づく実際の違いはない。

The following summarizes the set of information that is needed to configure TSN over DetNet MPLS:

Detnet MPLS上でTSNを設定するために必要な情報のセットを次に示します。

* TSN-related configuration information according to the TSN role of the DetNet MPLS node, as per [IEEE8021Q], [IEEE8021CB], and [IEEEP8021CBdb].

* TSN関連の設定情報Detnet MPLSノードのTSN役割に従って、[IEEE8021Q]、[IEEE8021CB]、[IEEEP8021CBDB]。

* DetNet MPLS-related configuration information according to the DetNet role of the DetNet MPLS node, as per [RFC8964].

* Detnet MPLS関連の設定情報Detnet MPLSノードのDetnetロールに従って、[RFC8964]。

* App-flow identification information to map received TSN Stream(s) to the DetNet flow. Parameters of TSN Stream identification are defined in [IEEE8021CB] and [IEEEP8021CBdb].

* 受信したTSNストリームをDetNet Flowにマッピングするためのアプリフロー識別情報。TSNストリーム識別のパラメータは[IEEE8021CB]と[IEEEP8021CBDB]で定義されています。

This information MUST be provisioned per DetNet flow.

この情報はDetnet Flowごとにプロビジョニングする必要があります。

Mappings between DetNet and TSN management and control planes are out of scope of the document. Some of the challenges are highlighted below.

DetnetとTSN管理と制御プレーンの間のマッピングは、文書の範囲外です。いくつかの課題は以下のように強調表示されています。

MPLS DetNet edge nodes are a member of both the DetNet domain and the connected TSN network. From the TSN network perspective, the MPLS (DetNet) edge node has a "TSN relay node" role, so TSN-specific management and control plane functionalities must be implemented. There are many similarities in the management plane techniques used in DetNet and TSN, but that is not the case for the control plane protocols. For example, RSVP-TE and MSRP behave differently. Therefore, management and control plane design is an important aspect of scenarios where mapping between DetNet and TSN is required.

MPLS DetNetエッジノードは、Detnetドメインと接続されているTSNネットワークの両方のメンバーです。TSNネットワークパースペクティブから、MPLS(Detnet)エッジノードには「TSNリレーノード」の役割があり、TSN固有の管理と制御プレーンの機能を実装する必要があります。DetnetおよびTSNで使用される管理プレーン技術には多くの類似点がありますが、それはコントロールプレーンプロトコルの場合ではありません。たとえば、RSVP-TEとMSRPは異なる動作をします。したがって、管理および制御プレーン設計は、DetnetとTSNの間のマッピングが必要なシナリオの重要な側面です。

Note that as the DetNet network is just a portion of the end-to-end TSN path (i.e., single hop from the Ethernet perspective), some parameters (e.g., delay) may differ significantly. Since there is no interworking function, the bandwidth of the DetNet network is assumed to be set large enough to handle all TSN flows it will support. At the egress of the DetNet domain, the MPLS headers are stripped, and the TSN flow continues on as a normal TSN flow.

DETNETネットワークがエンドツーエンドTSNパスの一部(すなわち、イーサネット視点からのシングルホップ)の一部であるので、いくつかのパラメータ(例えば、遅延)は大きく異なる可能性があることに留意されたい。インターワーキング関数がないので、DetNetネットワークの帯域幅は、それがサポートするすべてのTSNフローを処理するのに十分な大きさに設定されていると仮定されています。DetNetドメインの出口では、MPLSヘッダが剥がされ、TSNフローは通常のTSNフローとして続く。

In order to use a DetNet network to interconnect TSN segments, TSN-specific information must be converted to DetNet-domain-specific information. TSN Stream ID(s) and stream-related parameters/ requirements must be converted to a DetNet flow ID and flow-related parameters/requirements.

DetNetネットワークを使用してTSNセグメントを相互接続するには、TSN固有の情報をDetnet-Domain固有の情報に変換する必要があります。TSNストリームIDとストリーム関連のパラメータ/要件は、DetNetフローIDとフロー関連のパラメータ/要件に変換する必要があります。

In some cases, it may be challenging to determine some information related to the egress-node. For example, it may be not trivial to locate the egress point/interface of a TSN Stream with a multicast destination MAC address. Such scenarios may require interaction between control and management plane functions and between DetNet and TSN domains.

場合によっては、出力ノードに関連するいくつかの情報を決定することが困難であり得る。例えば、TSNストリームの出力点/インタフェースをマルチキャスト宛先MACアドレスと特定するのに些細ではないかもしれない。そのようなシナリオは、制御および管理プレーン機能とDetnetとTSNドメイン間の相互作用を必要とするかもしれません。

Mapping between DetNet flow identifiers and TSN Stream identifiers, if not provided explicitly, can be done by the service proxy function of an MPLS (DetNet) edge node locally based on information provided for the configuration of the TSN Stream identification functions (e.g., Mask-and-Match Stream identification).

Detnet Flow IdentifiersとTSN Stream Identifiersの間のマッピングは明示的に提供されていない場合は、TSNストリーム識別機能の構成に提供された情報に基づいてMPLS(DetNet)エッジノードのサービスプロキシ関数によって実行できます(例:マスク - アンドマッチストリーム識別)。

Triggering the setup/modification of a DetNet flow in the DetNet network is an example where management and/or control plane interactions are required between the DetNet and the TSN network.

Detnetネットワーク内のDetnetフローの設定/変更をトリガすることは、DetnetとTSNネットワークとの間に管理および/または制御プレーンの対話が必要な例です。

Configuration of TSN-specific functions (e.g., FRER) inside the TSN network is a TSN-domain-specific decision and may not be visible in the DetNet domain. Service protection interworking scenarios are left for further study.

TSNネットワーク内のTSN固有関数(例えば、FRER)の構成はTSNドメイン固有の決定であり、DetNetドメインには見えない場合があります。サービス保護インターワーキングシナリオは、さらなる研究のために残されています。

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

Security considerations for DetNet are described in detail in [DETNET-SEC]. General security considerations are described in [RFC8655].

Detnetのセキュリティ上の考慮事項は[Detnet-Sec]で詳しく説明しています。一般的なセキュリティ上の考慮事項は[RFC8655]に記載されています。

Considerations specific to the DetNet MPLS data plane are summarized and described in [RFC8964], including any application flow types. This document focuses on a scenario where TSN Streams are the application flows for DetNet, which is already covered by those DetNet MPLS data plane security considerations.

Detnet MPLSデータプレーンに固有の考慮事項は、アプリケーションフロータイプを含む[RFC8964]で要約および説明されています。この文書は、TSN StreamsがDetnet用のアプリケーションフローであるシナリオに焦点を当てており、これはすでにそれらのDetNet MPLSデータプレーンセキュリティ上の考慮事項によって既にカバーされています。

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

This document has no IANA actions.

この文書にはIANAの行動がありません。

9. References
9. 参考文献
9.1. Normative References
9.1. 引用文献

[IEEE8021CB] IEEE, "Standard for Local and metropolitan area networks -- Frame Replication and Elimination for Reliability", IEEE 802.1CB-2017, DOI 10.1109/IEEESTD.2017.8091139, October 2017, <https://ieeexplore.ieee.org/document/8091139>.

[IEEE8021CB] IEEE、「地元と首都圏のネットワーク - フレームの複製と信頼性の排除」、IEEE 802.1CB-2017、DOI 10.1109 / IEEESTD.2017.8091139、<https://ieeexplore.ieee.org/文書/ 8091139>。

[IEEEP8021CBdb] IEEE, "Draft Standard for Local and metropolitan area networks - Frame Replication and Elimination for Reliability - Amendment: Extended Stream Identification Functions", IEEE P802.1CBdb D1.3, April 2021, <https://1.ieee802.org/tsn/802-1cbdb>.

[IEEEP8021CBDB] IEEE、「ローカルおよび首都圏ネットワークの下書】 - フレームの複製と信頼性のための排除 - 拡張ストリーム識別機能」、IEEE P802.1CBDB D1.3、2021年4月、<https://1.ieee802。ORG / TSN / 802-1CBDB>。

[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>。

[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, <https://www.rfc-editor.org/info/rfc3031>.

[RFC3031]ローゼン、E.、Viswanathan、A.およびR.Callon、 "Multiprotocol Label Switche Architecture"、RFC 3031、DOI 10.17487 / RFC3031、2001年1月、<https://www.rfc-editor.org/info/ RFC3031>。

[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>。

[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>。

9.2. Informative References
9.2. 参考引用

[DETNET-SEC] Grossman, E., Ed., Mizrahi, T., and A. Hacker, "Deterministic Networking (DetNet) Security Considerations", Work in Progress, Internet-Draft, draft-ietf-detnet-security-16, 2 March 2021, <https://tools.ietf.org/html/draft-ietf-detnet-security-16>.

[Detnet-Sec]グロスマン、E.、ED。、Mizrahi、T.、およびA.ハッカー、「決定論的ネットワーキング(DetnetISTIC)セキュリティ上の考慮事項」、進行中の作業、インターネットドラフト、ドラフト - IETF-Detnet-Security-16、2021年3月2日、<https://tools.ietf.org/html/draft-ietf-detnet-security-16>。

[IEEE8021Q] IEEE, "Standard for Local and Metropolitan Area Networks-- Bridges and Bridged Networks", IEEE Std. 802.1Q-2018, DOI 10.1109/IEEESTD.2018.8403927, July 2018, <https://ieeexplore.ieee.org/document/8403927>.

[IEEE8021Q] IEEE、「地域および首都圏ネットワークの規格 - Bridges and Bridged Networks」、IEEE STD。2018年7月、<https://ieeexplore.ieee.org/document/8403927>。

[RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, DOI 10.17487/RFC3985, March 2005, <https://www.rfc-editor.org/info/rfc3985>.

[RFC3985]ブライアント、S。、ED。P. Pate、Ed。、「疑似ワイヤーエミュレーションエッジツーエッジ(PWE3)アーキテクチャ」、RFC 3985、DOI 10.17487 / RFC3985、2005年3月、<https://www.rfc-editor.org/info/rfc3985>。

Acknowledgements

謝辞

The authors wish to thank Norman Finn, Lou Berger, Craig Gunther, Christophe Mangin, and Jouni Korhonen for their various contributions to this work.

著者らは、Norman Finn、Lou Berger、Craig Gunther、Christophe Mangin、およびJouni Korhonenに感謝します。

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
        

János Farkas Ericsson Budapest Magyar Tudosok krt. 11. 1117 Hungary

JánosFarkas Ericsson Budapest Magyar Tudosok Krt。11. 1117ハンガリー

   Email: janos.farkas@ericsson.com
        

Andrew G. Malis Malis Consulting

Andrew G. Malis Malis Consulting.

   Email: agmalis@gmail.com
        

Stewart Bryant Futurewei Technologies

スチュワートブライアントフューチャーワイテクノロジー

   Email: sb@stewartbryant.com
        

Don Fedyk LabN Consulting, L.L.C.

Don Fedyk Labn Consulting、L.L.c。

   Email: dfedyk@labn.net