Internet Engineering Task Force (IETF) S. Gringeri
Request for Comments: 9801 J. Whittaker
Category: Standards Track Verizon
ISSN: 2070-1721 N. Leymann
Deutsche Telekom
C. Schmutzer, Ed.
Cisco Systems, Inc.
C. Brown
Ciena Corporation
July 2025
This document expands the applicability of Virtual Private Wire Service (VPWS) bit-stream payloads beyond Time Division Multiplexing (TDM) signals and provides pseudowire transport with complete signal transparency over Packet Switched Networks (PSNs).
このドキュメントは、仮想プライベートワイヤサービス（VPWS）のビットストリームペイロードの適用性を拡張し、時代分割マルチプレックス（TDM）信号を超えてビットストリームペイロードを提供し、パケットスイッチ付きネットワーク（PSNS）を介した完全な信号透明度を擬似された輸送を提供します。
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/rfc9801.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9801で取得できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2025 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 and Motivation
2. Requirements Notation
3. Terminology and Reference Models
3.1. Abbreviations
3.2. Reference Models
4. Emulated Services
4.1. Generic PLE Service
4.2. Ethernet Services
4.2.1. 1000BASE-X
4.2.2. 10GBASE-R and 25GBASE-R
4.2.3. 40GBASE-R, 50GBASE-R, and 100GBASE-R
4.2.4. 200GBASE-R and 400GBASE-R
4.2.5. Energy Efficient Ethernet (EEE)
4.3. SONET/SDH Services
4.4. Fibre Channel Services
4.4.1. 1GFC, 2GFC, 4GFC, and 8GFC
4.4.2. 16GFC
4.4.3. 32GFC and 4-Lane 128GFC
4.4.4. 64GFC
4.5. OTN Services
5. PLE Encapsulation Layer
5.1. PSN and VPWS Demultiplexing Headers
5.1.1. New SRv6 Behaviors
5.2. PLE Header
5.2.1. PLE Control Word
5.2.2. RTP Header
6. PLE Payload Layer
6.1. Basic Payload
6.2. Byte-Aligned Payload
7. PLE Operation
7.1. Common Considerations
7.2. PLE IWF Operation
7.2.1. PSN-Bound Encapsulation Behavior
7.2.2. CE-Bound Decapsulation Behavior
7.3. PLE Performance Monitoring
7.4. PLE Fault Management
8. QoS and Congestion Control
9. Security Considerations
10. IANA Considerations
10.1. Bit-Stream Next Header Type
10.2. SRv6 Endpoint Behaviors
11. References
11.1. Normative References
11.2. Informative References
Acknowledgements
Contributors
Authors' Addresses
This document describes a method called Private Line Emulation (PLE) for encapsulating not only Time Division Multiplexing (TDM) signals as bit-stream Virtual Private Wire Service (VPWS) over Packet Switched Networks (PSN). In this regard, it complements methods described in [RFC4553].
このドキュメントでは、パケットスイッチネットワーク（PSN）を介したビットストリーム仮想プライベートワイヤサービス（VPWS）として、時分割多重化（TDM）信号をカプセル化するためのプライベートラインエミュレーション（PLE）と呼ばれる方法について説明します。この点で、[RFC4553]で説明されている方法を補完します。
This emulation suits applications, where carrying Protocol Data Units (PDUs) as defined in [RFC4906] or [RFC4448] is not enough, physical layer signal transparency is required and data or framing structure interpretation of the Provider Edge (PE) would be counterproductive.
このエミュレーションは、[RFC4906]または[RFC4448]で定義されているプロトコルデータユニット（PDU）をキャリングするアプリケーションに適しています。
One example of such case is two Ethernet-connected Customer Edge (CE) devices and the need for Synchronous Ethernet operation (see [G.8261]) between them without the intermediate PE devices interfering or addressing concerns about Ethernet control protocol transparency for PDU-based carrier Ethernet services, beyond the behavior definitions of MEF Forum (MEF) specifications.
このような場合の1つの例は、2つのイーサネット接続された顧客エッジ（CE）デバイスと、MEF forum（MEF）の特定のforum（MEF）の特定の定義を超えて、PDUベースのキャリアイーサネットサービスのイーサネット制御プロトコル透明性に関する懸念を干渉または対処することなく、それらの間の同期イーサネット操作の必要性（[g.8261]を参照）の必要性（[g.8261]を参照）です。
Another example would be a Storage Area Networking (SAN) extension between two data centers. Operating at a bit-stream level allows for a connection between Fibre Channel switches without interfering with any of the Fibre Channel protocol mechanisms defined by [T11].
別の例は、2つのデータセンター間のストレージエリアネットワーキング（SAN）拡張です。ビットストリームレベルで動作すると、[T11]によって定義されたファイバーチャネルプロトコルメカニズムを妨げることなく、ファイバーチャネルスイッチ間の接続が可能になります。
Also, SONET/SDH (Synchronous Optical Network (SONET) / Synchronous Digital Hierarchy (SDH)) add/drop multiplexers or cross-connects can be interconnected without interfering with the multiplexing structures and networks mechanisms. This is a key distinction to Circuit Emulation over Packet (CEP) defined in [RFC4842] where multiplexing and demultiplexing is desired in order to operate per SONET Synchronous Payload Envelope (SPE) and Virtual Tributary (VT) or SDH Virtual Container (VC). In other words, PLE provides an independent layer network underneath the SONET/SDH layer network, whereas CEP operates at the same level and peer with the SONET/SDH layer network.
また、SONET/SDH（同期光学ネットワーク（SONET）/同期デジタル階層（SDH））の追加/ドロップマルチプレクサまたはクロスコネクトは、マルチプレックス構造やネットワークメカニズムを妨げることなく相互接続できます。これは、SONET同期ペイロードエンベロープ（SPE）および仮想支流（VT）またはSDH仮想コンテナ（VC）ごとに動作するために、[RFC4842]で定義されているパケット（CEP）上の回路エミュレーション（CEP）の重要な区別です。言い換えれば、PLEはSONET/SDHレイヤーネットワークの下に独立したレイヤーネットワークを提供しますが、CEPは同じレベルで動作し、SONET/SDHレイヤーネットワークでピアを操作します。
The mechanisms described in this document follow principles similar to Structure-Agnostic TDM over Packet (SAToP) (defined in [RFC4553]). The applicability is expanded beyond the narrow set of Plesiochronous Digital Hierarchy (PDH) interfaces (T1, E1, T3, and E3) to allow the transport of signals from many different technologies such as Ethernet, Fibre Channel, SONET/SDH ([GR253] / [G.707]), and Optical Transport Network (OTN) [G.709] at gigabit speeds. The signals are treated as bit-stream payload, which was defined in the Pseudo Wire Emulation Edge-to-Edge (PWE3) architecture in Sections 3.3.3 and 3.3.4 of [RFC3985].
このドキュメントで説明されているメカニズムは、パケット（SATOP）（[RFC4553]で定義されている）上の構造に依存しないTDMに類似した原則に従います。適用性は、狭いプレシオクロナスデジタル階層（PDH）インターフェイス（T1、E1、T3、およびE3）の狭いセットを超えて拡張され、イーサネット、ファイバーチャネル、SONET / SDHなどの多くの異なる技術からの信号の輸送を可能にします（[GR253] / [G.707]）、および眼輸送ネットワーク（OTN）信号はビットストリームペイロードとして扱われ、[RFC3985]のセクション3.3.3および3.3.4の擬似ワイヤエミュレーションエッジからエッジ（PWE3）アーキテクチャで定義されました。
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」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
ACH:
ACH:
Associated Channel Header [RFC7212]
関連するチャネルヘッダー[RFC7212]
AIS:
AIS:
Alarm Indication Signal
アラーム表示信号
AIS-L:
AIS-L：
Line AIS
ラインais
MS-AIS:
MS-AIS：
Multiplex Section AIS
マルチプレックスセクションAIS
BITS:
ビット：
Building Integrated Timing Supply [ATIS-0900105.09.2013]
統合タイミング供給の構築[ATIS-0900105.09.2013]
CBR:
CBR:
Constant Bit Rate
一定のビットレート
CE:
CE:
Customer Edge
顧客のエッジ
CEP:
CEP:
Circuit Emulation over Packet [RFC4842]
パケット上の回路エミュレーション[RFC4842]
CSID:
CSID：
Compressed SID
圧縮されたsid
CSRC:
CSRC：
Contributing Source [RFC3550]
寄稿ソース[RFC3550]
DEG:
DEG:
Degradation
劣化
ES:
ES:
Errored Second
エラー秒
FEC:
FEC:
Forward Error Correction
フォワードエラー修正
ICMP:
ICMP：
Internet Control Message Protocol [RFC4443]
インターネット制御メッセージプロトコル[RFC4443]
IEEE:
IEEE：
Institute of Electrical and Electronics Engineers
電気およびエレクトロニクスエンジニア研究所
INCITS:
インセット：
INternational Committee for Information Technology Standards
情報技術基準の国際委員会
IWF:
IWF:
Interworking Function
インターワーキング関数
LDP:
LDP:
Label Distribution Protocol [RFC5036], [RFC8077]
ラベル分布プロトコル[RFC5036]、[RFC8077]
LF:
LF:
Local Fault
局所的な過失
LOF:
LOF:
Loss Of Frame
フレームの損失
LOM:
LOM:
Loss Of Multiframe
マルチフレームの喪失
LOS:
LOS:
Loss Of Signal
信号の喪失
LPI:
LPI:
Low Power Idle
低電力アイドル
LSP:
LSP:
Label Switched Path
ラベルスイッチ付きパス
MEF:
MEF:
MEF Forum
MEFフォーラム
MPLS:
MPLS：
Multiprotocol Label Switching [RFC3031]
マルチプロトコルラベルスイッチング[RFC3031]
NOS:
NOS:
Not Operational
動作していません
NSP:
NSP:
Native Service Processing [RFC3985]
ネイティブサービス処理[RFC3985]
ODUk:
Oduk：
Optical Data Unit k
光データユニットk
OOF:
OOF:
Out Of Frame
フレームから
OTN:
OTN:
Optical Transport Network
光学輸送ネットワーク
OTUk:
otuk：
Optical Transport Unit k
光学輸送ユニットk
PCS:
PCS:
Physical Coding Sublayer
物理的なコーディングサブレイヤー
PDV:
PDV:
Packet Delay Variation
パケット遅延バリエーション
PE:
PE:
Provider Edge
プロバイダーエッジ
PLE:
PLE:
Private Line Emulation
プライベートラインエミュレーション
PLOS:
PLOS：
Packet Loss Of Signal
信号のパケット損失
PLR:
PLR:
Packet Loss Rate
パケット損失率
PMA:
PMA:
Physical Medium Attachment
物理的な媒体アタッチメント
PMD:
PMD:
Physical Medium Dependent
物理的な媒体依存
PSN:
PSN:
Packet Switched Network
パケットスイッチネットワーク
PTP:
PTP:
Precision Time Protocol
精密時間プロトコル
PW:
PW:
Pseudowire [RFC4664]
pseudowire [rfc4664]
PWE3:
PWE3：
Pseudo Wire Emulation Edge-to-Edge [RFC3985]
擬似ワイヤーエミュレーションエッジとエッジ[RFC3985]
RDI:
RDI:
Remote Defect Indication
リモート欠陥の表示
RSVP-TE:
RSVP-TE：
Resource Reservation Protocol Traffic Engineering [RFC4875]
リソース予約プロトコルトラフィックエンジニアリング[RFC4875]
RTCP:
RTCP：
RTP Control Protocol [RFC3550]
RTPコントロールプロトコル[RFC3550]
RTP:
RTP:
Real-time Transport Protocol [RFC3550]
リアルタイムトランスポートプロトコル[RFC3550]
SD:
SD:
Signal Degrade
信号分解
SES:
SES:
Severely Errored Seconds
ひどくエラーされた秒
SDH:
SDH:
Synchronous Digital Hierarchy
同期デジタル階層
SID:
SID:
Segment Identifier [RFC8402]
セグメント識別子[RFC8402]
SR:
SR:
Segment Routing [RFC8402]
セグメントルーティング[RFC8402]
SRH:
SRH:
Segment Routing Header [RFC8754]
セグメントルーティングヘッダー[RFC8754]
SRTP:
SRTP：
Secure Real-time Transport Protocol [RFC3711]
安全なリアルタイム輸送プロトコル[RFC3711]
SRv6:
SRV6：
Segment Routing over IPv6 [RFC8986]
IPv6のセグメントルーティング[RFC8986]
SSRC:
SSRC：
Synchronization Source [RFC3550]
同期ソース[RFC3550]
SONET:
ソネット：
Synchronous Optical Network
同期光ネットワーク
TCP:
TCP:
Transmission Control Protocol [RFC9293]
トランスミッションコントロールプロトコル[RFC9293]
TDM:
TDM:
Time Division Multiplexing
時分割多重化
TTS:
TTS:
Transmitter Training Signal
トランスミッタートレーニング信号
UAS:
UAS:
Unavailable Seconds
利用できない秒
VPWS:
VPWS：
Virtual Private Wire Service [RFC3985]
仮想プライベートワイヤーサービス[RFC3985]
Note: The term Interworking Function (IWF) is used to describe the functional block that encapsulates bit-streams into PLE packets and in the reverse direction decapsulates PLE packets and reconstructs bit-streams.
注：インターワーキング関数（IWF）という用語は、ビットストリームをPLEパケットにカプセル化する機能ブロックを記述し、逆方向にPLEパケットを脱カプセル化し、ビットストリームを再構築します。
The reference model for PLE is illustrated in Figure 1 and is inline with the reference model defined in Section 4.1 of [RFC3985]. PLE relies on PWE3 preprocessing, in particular the concept of an NSP function defined in Section 4.2.2 of [RFC3985].
PLEの参照モデルは図1に示されており、[RFC3985]のセクション4.1で定義されている参照モデルとインラインです。PLEは、PWE3前処理、特に[RFC3985]のセクション4.2.2で定義されているNSP関数の概念に依存しています。
|<--- p2p L2VPN service -->|
| |
| |<-PSN tunnel->| |
v v v v
+---------+ +---------+
| PE1 |==============| PE2 |
+---+-----+ +-----+---+
+-----+ | N | | | | N | +-----+
| CE1 |-----| S | IWF |.....VPWS.....| IWF | S |-----| CE2 |
+-----+ ^ | P | | | | P | ^ +-----+
| +---+-----+ +-----+---+ |
CE1 physical ^ ^ CE2 physical
interface | | interface
|<--- emulated service --->|
| |
attachment attachment
circuit circuit
Figure 1: PLE Reference Model
図1：PLE参照モデル
PLE embraces the minimum intervention principle outlined in Section 3.3.5 of [RFC3985], which means the data is flowing through the PLE encapsulation layer as received without modifications.
PLEは、[RFC3985]のセクション3.3.5で概説されている最小介入原理を採用しています。つまり、データは、修正なしで受信されたPLEカプセル化層を介して流れています。
For some service types, the NSP function is responsible for performing operations on the data received from the CE. Examples are terminating FEC, terminating the OTUk layer for OTN, or dealing with multi-lane processing. After the NSP, the IWF is generating the payload of the VPWS, which is carried via a PSN tunnel.
一部のサービスタイプの場合、NSP関数は、CEから受信したデータの操作を実行する責任があります。例には、FECの終了、OTNのOTUK層の終了、またはマルチレーン処理の処理があります。NSPの後、IWFはVPWSのペイロードを生成し、PSNトンネルを介して運ばれます。
To allow the clock of the transported signal to be carried across the PLE domain in a transparent way, the relative network synchronization reference model and deployment scenario outlined in Section 4.3.2 of [RFC4197] are applicable and are shown in Figure 2.
輸送された信号のクロックを透明な方法でPLEドメイン全体に運ぶことができるようにするために、[RFC4197]のセクション4.3.2で概説されている相対的なネットワーク同期参照モデルと展開シナリオが適用可能であり、図2に示されています。
J
| G
| |
| +-----+ +-----+ v
+-----+ v |- - -|=================|- - -| +-----+
| |<---------|.............................|<---------| |
| CE1 | | PE1 | VPWS | PE2 | | CE2 |
| |--------->|.............................|--------->| |
+-----+ |- - -|=================|- - -| ^ +-----+
^ +-----+ +-----+ |
| ^ C D ^ |
A | | |
+-----------+-----------+ E
|
+-+
|I|
+-+
Figure 2: Relative Network Scenario Timing
図2：相対的なネットワークシナリオタイミング
The local oscillators C of PE1 and D of PE2 are locked to a common clock I.
PE1の局所発振器CおよびPE2のDは、一般的な時計Iにロックされています。
The attachment circuit clock E is generated by PE2 via a differential clock recovery method in reference to the common clock I. For this to work, the difference between clock A and clock C (locked to I) MUST be explicitly transferred from PE1 to PE2 using the timestamp inside the RTP header.
アタッチメント回路クロックEは、共通のクロックIを参照して、微分クロック回復法を介してPE2によって生成されます。これは、クロックAとクロックC（Iにロックされた）の違いを、RTPヘッダー内のタイムスタンプを使用してPE1からPE2に明示的に転送する必要があります。
For the reverse direction, PE1 generates the attachment circuit clock J and the clock difference between G and D (locked to I) is transferred from PE2 to PE1.
逆方向の場合、PE1はアタッチメント回路クロックJを生成し、GとDのクロック差（Iにロックされた）がPE2からPE1に転送されます。
The method used to lock clocks C and D to the common clock I is out of scope of this document; however, there are already several well-established concepts for achieving clock synchronization (commonly also referred to as "frequency synchronization") available.
クロックCとDを共通のクロックIにロックするために使用される方法は、このドキュメントの範囲外です。ただし、クロック同期を達成するためのいくつかの確立された概念（一般的には「周波数同期」とも呼ばれます）が利用可能です。
While using external timing inputs (aka BITS [ATIS-0900105.09.2013]) or synchronous Ethernet (as defined in [G.8261]), the characteristics and limits defined in [G.8262] have to be considered.
外部タイミング入力（別名BITS [ATIS-0900105.09.2013]）または同期イーサネット（[G.8261]で定義）を使用している間、[G.8262]で定義されている特性と制限を考慮する必要があります。
While relying on PTP (as defined in [G.8265.1]), the network limits defined in [G.8261.1] have to be considered.
[G.8265.1]で定義されているように）PTPに依存している間、[G.8261.1]で定義されているネットワーク制限を考慮する必要があります。
This specification describes the emulation of services from a wide range of technologies, such as TDM, Ethernet, Fibre Channel, or OTN, as bit-streams or structured bit-streams, as defined in Sections 3.3.3 and 3.3.4 of [RFC3985].
この仕様では、[RFC3985]のセクション3.3.3および3.3.4で定義されているように、ビットストリームまたは構造化ビットストリームとして、TDM、イーサネット、ファイバーチャネル、OTNなどの幅広いテクノロジーからのサービスのエミュレーションを説明します。
The generic PLE service is an example of the bit-stream defined in Section 3.3.3 of [RFC3985].
一般的なPLEサービスは、[RFC3985]のセクション3.3.3で定義されているビットストリームの例です。
Under the assumption that the CE-bound IWF is not responsible for any service-specific operation, a bit-stream of any rate can be carried using the generic PLE payload.
CEバウンドIWFがサービス固有の操作に対して責任を負わないという仮定の下では、一般的なPLEペイロードを使用して、とにかく少しストリームを運ぶことができます。
There is no NSP function present for this service.
このサービスにはNSP機能が存在しません。
Ethernet services are special cases of the structured bit-stream defined in Section 3.3.4 of [RFC3985].
イーサネットサービスは、[RFC3985]のセクション3.3.4で定義されている構造化ビットストリームの特別なケースです。
The IEEE has defined several layers for Ethernet in [IEEE802.3]. Emulation is operating at the physical (PHY) layer, more precisely at the PCS.
IEEEは、[IEEE802.3]でイーサネットのいくつかのレイヤーを定義しています。エミュレーションは物理的（PHY）層で動作し、より正確にはPCで動作します。
Over time, many different Ethernet interface types have been specified in [IEEE802.3] with a varying set of characteristics, such as optional versus mandatory FEC and single-lane versus multi-lane transmission.
時間が経つにつれて、オプションと必須のFECと単一車線とマルチレーン伝送など、さまざまな特性セットを使用して、多くの異なるイーサネットインターフェイスタイプが[IEEE802.3]で指定されています。
Ethernet interface types with backplane PMD variants and Ethernet interface types mandating auto-negotiation (except 1000Base-X) are out of scope for this document.
バックプレーンPMDバリアントと自動交帯を義務付けているイーサネットインターフェイスタイプを備えたイーサネットインターフェイスタイプ（1000Base-Xを除く）は、このドキュメントの範囲外です。
All Ethernet services are leveraging the basic PLE payload and interface-specific mechanisms are confined to the respective service specific NSP functions.
すべてのイーサネットサービスが基本的なPLEペイロードを活用しており、インターフェイス固有のメカニズムは、それぞれのサービス固有のNSP関数に限定されています。
The PCS layer of 1000BASE-X (defined in Section 36 of [IEEE802.3]) is based on 8B/10B code.
1000Base-XのPCSレイヤー（[IEEE802.3]のセクション36で定義）は、8B/10Bコードに基づいています。
The PSN-bound NSP function does not modify the received data and is transparent to auto-negotiation; however, it is responsible for detecting attachment circuit faults specific to 1000BASE-X such as LOS and sync loss.
PSNに結合したNSP関数は、受信したデータを変更せず、自動ネゴシエーションに対して透過的です。ただし、LOSや同期損失などの1000Base-Xに固有のアタッチメント回路障害を検出する責任があります。
When the CE-bound IWF is in PLOS state or when PLE packets are received with the L bit set, the CE-bound NSP function MAY disable its transmitter as no appropriate maintenance signal was defined for 1000BASE-X by the IEEE.
CEバウンドIWFがPLOS状態にある場合、またはLビットセットでPLEパケットを受信した場合、CEバウンドNSP関数は、IEEEによって1000Base-Xに対して適切なメンテナンス信号が定義されていないため、送信機を無効にする場合があります。
The PCS layers of 10GBASE-R (defined in Section 49 and 25GBASE-R defined in Section 107 of [IEEE802.3]) are based on a 64B/66B code.
10gBase-RのPCSレイヤー（[IEEE802.3]のセクション107で定義されたセクション49および25GBase-Rで定義）は、64B/66Bコードに基づいています。
Sections 74 and 108 of [IEEE802.3] define an optional FEC layer; if present, the PSN-bound NSP function MUST terminate the FEC and the CE-bound NSP function MUST generate the FEC.
[IEEE 802.3]のセクション74および108は、オプションのFECレイヤーを定義します。存在すると、PSNに結合したNSP関数がFECを終了する必要があり、CEバウンドNSP関数はFECを生成する必要があります。
The PSN-bound NSP function is also responsible for detecting attachment circuit faults specific to 10GBASE-R and 25GBASE-R such as LOS and sync loss.
PSNに結合したNSP関数は、LOSや同期損失などの10GBase-Rおよび25GBase-Rに固有のアタッチメント回路障害の検出を担当します。
The PSN-bound IWF maps the scrambled 64B/66B code stream into the basic PLE payload.
PSNバインドIWFは、スクランブル64B/66Bコードストリームを基本的なPLEペイロードにマップします。
The CE-bound NSP function MUST perform:
CEバウンドNSP関数を実行する必要があります。
* PCS code sync (Section 49.2.9 of [IEEE802.3]) and
* PCSコード同期（[IEEE802.3]のセクション49.2.9）および
* descrambling (Section 49.2.10 of [IEEE802.3])
* デスクランブル（[IEEE802.3]のセクション49.2.10）
in order to properly:
適切に：
* transform invalid 66B code blocks into proper error control characters /E/ (Section 49.2.4.11 of [IEEE802.3]) and
* 無効な66Bコードブロックを適切なエラー制御文字 / e /（[IEEE802.3]のセクション49.2.4.11）に変換し、
* insert LF ordered sets (Section 46.3.4 of [IEEE802.3]) when the CE-bound IWF is in PLOS state or when PLE packets are received with the L bit set.
* CEバウンドIWFがPLOS状態にある場合、またはLビットセットでPLEパケットを受信した場合、LF順序付きセット（[IEEE802.3]のセクション46.3.4）を挿入します。
Note: Invalid 66B code blocks typically are a consequence of the CE-bound IWF inserting replacement data in case of lost PLE packets or the far-end PSN-bound NSP function setting sync headers to 11 due to uncorrectable FEC errors.
注：無効な66Bコードブロックは、通常、PLEパケットの紛失またはファーエンドPSNバインドNSP関数設定ヘッダーが修正不可能なFECエラーのためにヘッダーを同期する場合に、CEバウンドIWFが交換データを挿入したことの結果です。
Before sending the bit-stream to the CE, the CE-bound NSP function MUST also scramble the 64B/66B code stream (Section 49.2.6 [IEEE802.3]).
ビットストリームをCEに送信する前に、CEに縛られたNSP関数も64B/66Bコードストリームをスクランブルする必要があります（セクション49.2.6 [IEEE802.3]）。
The PCS layers of 40GBASE-R and 100GBASE-R (defined in Section 82 of [IEEE802.3]) and of 50GBASE-R (defined in Section 133 of [IEEE802.3]) are based on a 64B/66B code transmitted over multiple lanes.
40gBase-Rおよび100GBase-R（[IEEE802.3]のセクション82で定義）および50GBase-R（[IEEE802.3]のセクション133で定義）のPCS層は、複数レーンに送信される64B/66Bコードに基づいています。
Sections 74 and 91 of [IEEE802.3] define an optional FEC layer; if present, the PSN-bound NSP function MUST terminate the FEC and the CE-bound NSP function MUST generate the FEC.
[IEEE 802.3]のセクション74および91は、オプションのFECレイヤーを定義します。存在すると、PSNに結合したNSP関数がFECを終了する必要があり、CEバウンドNSP関数はFECを生成する必要があります。
To gain access to the scrambled 64B/66B code stream, the PSN-bound NSP further MUST perform:
スクランブル64B/66Bコードストリームにアクセスするには、PSNバインドNSPがさらに実行する必要があります。
* block synchronization (Section 82.2.12 of [IEEE802.3]),
* ブロック同期（[IEEE802.3]のセクション82.2.12）、
* PCS lane de-skew (Section 82.2.13 of [IEEE802.3]), and
* PCS Lane DeSkew（[IEEE802.3]のセクション82.2.13）、および
* PCS lane reordering (Section 82.2.14 of [IEEE802.3]).
* PCSレーンの並べ替え（[IEEE802.3]のセクション82.2.14）。
The PSN-bound NSP function is also responsible for detecting attachment circuit faults specific to 40GBASE-R, 50GBASE-R, and 100GBASE-R such as LOS and loss of alignment.
PSNに結合したNSP関数は、LOSやアライメントの損失など、40GBase-R、50GBase-R、および100GBase-Rに固有のアタッチメント回路障害の検出も担当します。
The PSN-bound IWF maps the serialized and scrambled 64B/66B code stream including the alignment markers into the basic PLE payload.
PSNバウンドIWFは、アライメントマーカーを含む64B/66Bコードストリームを基本的なPLEペイロードに含む、シリアル化およびスクランブル64B/66Bコードストリームをマップします。
The CE-bound NSP function MUST perform:
CEバウンドNSP関数を実行する必要があります。
* PCS code sync (Section 82.2.12 of [IEEE802.3]),
* PCSコード同期（[IEEE802.3]のセクション82.2.12）、
* alignment-marker removal (Section 82.2.15 of [IEEE802.3]), and
* Alignment-Marker除去（[IEEE802.3]のセクション82.2.15）、および
* descrambling (Section 49.2.10 of [IEEE802.3])
* デスクランブル（[IEEE802.3]のセクション49.2.10）
in order to properly:
適切に：
* transform invalid 66B code blocks into proper error control characters /E/ (Section 82.2.3.10 of [IEEE802.3]) and
* 無効な66Bコードブロックを適切なエラー制御文字 / e /（[IEEE802.3]のセクション82.2.3.10）に変換し、
* insert LF ordered sets (Section 81.3.4 of [IEEE802.3]) when the CE-bound IWF is in PLOS state or when PLE packets are received with the L bit set.
* CEバウンドIWFがPLOS状態にある場合、またはLビットセットでPLEパケットを受信した場合、LF順序付きセット（[IEEE802.3]のセクション81.3.4）を挿入します。
Note: Invalid 66B code blocks typically are a consequence of the CE-bound IWF inserting replacement data in case of lost PLE packets or the far-end PSN-bound NSP function not setting sync headers to 11 due to uncorrectable FEC errors.
注：無効な66Bコードブロックは、通常、PLEパケットの紛失またはファーエンドPSNバインドNSP機能が修正不可能なFECエラーのために同期ヘッダーを設定しない場合に、CEバウンドIWFが交換データを挿入することの結果です。
When sending the bit-stream to the CE, the CE-bound NSP function MUST also perform:
ビットストリームをCEに送信する場合、CEに結合したNSP関数も実行する必要があります。
* scrambling of the 64B/66B code (Section 49.2.6 of [IEEE802.3]),
* 64B/66Bコードのスクランブル（[IEEE802.3]のセクション49.2.6）、
* block distribution (Section 82.2.6 of [IEEE802.3]), and
* ブロック分布（[IEEE802.3]のセクション82.2.6）、および
* alignment-marker insertion (Sections 82.2.7 and 133.2.2 of [IEEE802.3]).
* Alignment-Marker挿入（[IEEE802.3]のセクション82.2.7および133.2.2）。
The PCS layers of 200GBASE-R and 400GBASE-R (defined in Section 119 of [IEEE802.3]) are based on a 64B/66B code transcoded to a 256B/257B code to reduce the overhead and make room for a mandatory FEC.
200GBase-Rおよび400GBase-RのPCS層（[IEEE802.3]のセクション119で定義）は、256B/257Bコードにトランスコードされた64B/66Bコードに基づいて、オーバーヘッドを削減し、必須のFECのスペースを確保します。
To gain access to the 64B/66B code stream, the PSN-bound NSP further MUST perform:
64B/66Bコードストリームにアクセスするには、PSNバインドNSPをさらに実行する必要があります。
* alignment lock and de-skew (Section 119.2.5.1 of [IEEE802.3]),
* アライメントロックとデスキュー（[IEEE802.3]のセクション119.2.5.1）、
* PCS lane reordering and de-interleaving (Section 119.2.5.2 of [IEEE802.3]),
* PCSレーンの並べ替えとinterLeaving（[IEEE802.3]のセクション119.2.5.2）、
* FEC decoding (Section 119.2.5.3 of [IEEE802.3]),
* FECデコード（[IEEE802.3]のセクション119.2.5.3）、
* post-FEC interleaving (Section 119.2.5.4 of [IEEE802.3]),
* FECポストインターリーブ（[IEEE802.3]のセクション119.2.5.4）、
* alignment-marker removal (Section 119.2.5.5 of [IEEE802.3]),
* Alignment-Marker除去（[IEEE802.3]のセクション119.2.5.5）、
* descrambling (Section 119.2.5.6 of [IEEE802.3]), and
* 説明（[IEEE802.3]のセクション119.2.5.6）、および
* reverse transcoding from 256B/257B to 64B/66B (Section 119.2.5.7 of [IEEE802.3]).
* 256B/257Bから64B/66Bへの逆トランスコーディング（[IEEE802.3]のセクション119.2.5.7）。
Further, the PSN-bound NSP MUST perform rate compensation and scrambling (Section 49.2.6 of [IEEE802.3]) before the PSN-bound IWF maps the same into the basic PLE payload.
さらに、PSNに結合したIWFが基本的なPLEペイロードに同じものをマップする前に、PSNバインドNSPはレート補正とスクランブル（[IEEE802.3]のセクション49.2.6）を実行する必要があります。
Rate compensation is applied so that the rate of the 66B encoded bit-stream carried by PLE is 528/544 times the nominal bitrate of the 200GBASE-R or 400GBASE-R at the PMA service interface. X number of 66-byte-long rate compensation blocks are inserted every X*20479 number of 66B client blocks. For 200GBASE-R, the value of X is 16; for 400GBASE-R, the value of X is 32. Rate compensation blocks are special 66B control characters of type 0x00 that can easily be searched for by the CE-bound IWF in order to remove them.
PLEによって運ばれる66Bエンコードビットストリームのレートが、PMAサービスインターフェイスで200GBase-Rまたは400GBase-Rの公称ビットレートの528/544倍になるように、レート補償が適用されます。X 66バイトの長さのレート補償ブロックの数は、66Bクライアントブロックの数ごとに挿入されます。200gBase-Rの場合、xの値は16です。400gBase-Rの場合、xの値は32です。レート補正ブロックは、除去するためにCEバウンドIWFによって簡単に検索できるタイプ0x00の特別な66B制御文字です。
The PSN-bound NSP function is also responsible for detecting attachment circuit faults specific to 200GBASE-R and 400GBASE-R such as LOS and loss of alignment.
PSNに結合したNSP関数は、LOSやアライメントの喪失など、200GBase-Rおよび400GBase-Rに固有のアタッチメント回路障害の検出を担当します。
The CE-bound NSP function MUST perform:
CEバウンドNSP関数を実行する必要があります。
* PCS code sync (Section 49.2.13 of [IEEE802.3]),
* PCSコード同期（[IEEE802.3]のセクション49.2.13）、
* descrambling (Section 49.2.10 of [IEEE802.3]), and
* 説明（[IEEE802.3]のセクション49.2.10）、および
* rate compensation block removal
* レート補償ブロックの削除
in order to properly:
適切に：
* transform invalid 66B code blocks into proper error control characters /E/ (Section 119.2.3.9 of [IEEE802.3]) and
* 無効な66Bコードブロックを適切なエラー制御文字 / e /（[IEEE802.3]のセクション119.2.3.9）に変換し、
* insert LF ordered sets (Section 81.3.4 of [IEEE802.3]) when the CE-bound IWF is in PLOS state or when PLE packets are received with the L bit set.
* CEバウンドIWFがPLOS状態にある場合、またはLビットセットでPLEパケットを受信した場合、LF順序付きセット（[IEEE802.3]のセクション81.3.4）を挿入します。
Note: Invalid 66B code blocks typically are a consequence of the CE-bound IWF inserting replacement data in case of lost PLE packets or the far-end PSN-bound NSP function not setting sync headers to 11 due to uncorrectable FEC errors.
注：無効な66Bコードブロックは、通常、PLEパケットの紛失またはファーエンドPSNバインドNSP機能が修正不可能なFECエラーのために同期ヘッダーを設定しない場合に、CEバウンドIWFが交換データを挿入することの結果です。
When sending the bit-stream to the CE, the CE-bound NSP function MUST also perform:
ビットストリームをCEに送信する場合、CEに結合したNSP関数も実行する必要があります。
* transcoding from 64B/66B to 256B/257B (Section 119.2.4.2 of [IEEE802.3]),
* 64B/66Bから256B/257Bへのトランスコーディング（[IEEE802.3]のセクション119.2.4.2）、
* scrambling (Section 119.2.4.3 of [IEEE802.3]),
* スクランブル（[IEEE802.3]のセクション119.2.4.3）、
* alignment-marker insertion (Section 119.2.4.4 of [IEEE802.3]),
* Alignment-Marker挿入（[IEEE802.3]のセクション119.2.4.4）、
* pre-FEC distribution (Section 119.2.4.5 of [IEEE802.3]),
* プレFEC分布（[IEEE802.3]のセクション119.2.4.5）、
* FEC encoding (Section 119.2.4.6 of [IEEE802.3]), and
* FECエンコーディング（[IEEE802.3]のセクション119.2.4.6）、および
* PCS lane distribution (Section 119.2.4.8 of [IEEE802.3]).
* PCSレーン分布（[IEEE802.3]のセクション119.2.4.8）。
Section 78 of [IEEE802.3] defines the optional LPI capability for Ethernet. Two modes are defined:
[IEEE802.3]のセクション78は、イーサネットのオプションのLPI機能を定義しています。2つのモードが定義されています。
* deep sleep
* 深い眠り
* fast wake
* 速いウェイク
Deep sleep mode is not compatible with PLE due to the CE ceasing transmission. Hence, there is no support for LPI for 10GBASE-R services across PLE.
深い睡眠モードは、伝送が停止しているため、PLEと互換性がありません。したがって、PLE全体で10GBase-RサービスのLPIのサポートはありません。
In fast wake mode, the CE transmits /LI/ control code blocks instead of /I/ control code blocks and, therefore, PLE is agnostic to it. For 25GBASE-R and higher services across PLE, LPI is supported as only fast wake mode is applicable.
高速ウェイクモードでは、CEは / I /コントロールコードブロックの代わりに / LI /コントロールコードブロックを送信するため、PLEはそれに対して不可知論されます。PLE全体で25GBase-R以下のサービスの場合、LPIは高速ウェイクモードのみが適用できるためサポートされています。
SONET/SDH services are special cases of the structured bit-stream defined in Section 3.3.4 of [RFC3985].
SONET/SDHサービスは、[RFC3985]のセクション3.3.4で定義されている構造化ビットストリームの特別なケースです。
SDH interfaces are defined in [G.707]; SONET interfaces are defined in [GR253].
SDHインターフェイスは[G.707]で定義されています。SONETインターフェイスは[GR253]で定義されています。
The PSN-bound NSP function does not modify the received data but is responsible for detecting attachment circuit faults specific to SONET/SDH such as LOS, LOF, and OOF.
PSNに結合したNSP関数は、受信したデータを変更しませんが、LOS、LOF、OOFなどのSONET/SDHに固有のアタッチメント回路障害の検出を担当します。
Data received by the PSN-bound IWF is mapped into the basic PLE payload without any awareness of SONET/SDH frames.
PSNバインドIWFが受け取ったデータは、SONET/SDHフレームを認識することなく、基本的なPLEペイロードにマッピングされます。
When the CE-bound IWF is in PLOS state or when PLE packets are received with the L bit set, the CE-bound NSP function is responsible for generating the:
CEバウンドIWFがPLOS状態にある場合、またはLビットセットでPLEパケットを受信した場合、CEバウンドNSP関数は以下を生成する責任があります。
* MS-AIS maintenance signal (defined in Section 6.2.4.1.1 of [G.707]) for SDH services and
* SDHサービスのMS-AISメンテナンス信号（[G.707]のセクション6.2.4.1.1で定義）および
* AIS-L maintenance signal (defined in Section 6.2.1.2 of [GR253]) for SONET services
* SONETサービスのAIS-Lメンテナンス信号（[GR253]のセクション6.2.1.2で定義）
at client-frame boundaries.
クライアントフレームの境界で。
Fibre Channel services are special cases of the structured bit-stream defined in Section 3.3.4 of [RFC3985].
ファイバーチャネルサービスは、[RFC3985]のセクション3.3.4で定義されている構造化ビットストリームの特別なケースです。
The T11 technical committee of INCITS has defined several layers for Fibre Channel. PLE operates at the FC-1 layer that leverages mechanisms defined by [IEEE802.3].
INCITSのT11技術委員会は、ファイバーチャネル用のいくつかのレイヤーを定義しています。PLEは、[IEEE802.3]で定義されたメカニズムを活用するFC-1層で動作します。
Over time, many different Fibre Channel interface types have been specified with a varying set of characteristics such as optional versus mandatory FEC and single-lane versus multi-lane transmission.
時間が経つにつれて、オプションと必須のFECおよび単一車線伝送とマルチレーン伝送など、さまざまな特性セットで多くの異なるファイバーチャネルインターフェイスタイプが指定されています。
Speed negotiation is not supported by PLE.
速度交渉はPLEによってサポートされていません。
All Fibre Channel services leverage the basic PLE payload, and interface-specific mechanisms are confined to the respective service-specific NSP functions.
すべてのファイバーチャネルサービスは、基本的なPLEペイロードを活用し、インターフェイス固有のメカニズムは、それぞれのサービス固有のNSP関数に限定されます。
[FC-PI-2] specifies 1GFC and 2GFC. [FC-PI-5] and [FC-PI-5am1] define 4GFC and 8GFC.
[FC-PI-2]は、1GFCと2GFCを指定します。[FC-PI-5]および[FC-PI-5AM1]は4GFCと8GFCを定義します。
The PSN-bound NSP function is responsible for detecting attachment circuit faults specific to the Fibre Channel such as LOS and sync loss.
PSNに結合したNSP関数は、LOSや同期損失などのファイバーチャネルに固有のアタッチメント回路障害の検出に関与します。
The PSN-bound IWF maps the received 8B/10B code stream as is directly into the basic PLE payload.
PSNバインドIWFは、受信した8B/10Bコードストリームを基本的なPLEペイロードに直接マップします。
The CE-bound NSP function MUST perform transmission word sync in order to properly:
CEバウンドNSP関数は、適切に次のために伝送ワード同期を実行する必要があります。
* replace invalid transmission words with the special character K30.7 and
* 無効な伝送語を特殊文字K30.7に置き換え、
* insert NOS ordered sets when the CE-bound IWF is in PLOS state or when PLE packets are received with the L bit set.
* CEバウンドIWFがPLOS状態にあるとき、またはLビットセットでPLEパケットを受信したときに、NOSの注文セットを挿入します。
Note: Invalid transmission words typically are a consequence of the CE-bound IWF inserting replacement data in case of lost PLE packets.
注：無効な伝送ワードは、通常、PLEパケットが失われた場合に交換データを挿入するCEバウンドIWFの結果です。
[FC-PI-5am1] defines the use of scrambling for 8GFC; in this case, the CE-bound NSP MUST also perform descrambling before replacing invalid transmission words or inserting NOS ordered sets. Before sending the bit-stream to the CE, the CE-bound NSP function MUST scramble the 8B/10B code stream.
[FC-PI-5AM1]は、8GFCのスクランブルの使用を定義しています。この場合、CEに縛られたNSPは、無効な伝送ワードを交換したり、NOS順序付けられたセットを挿入したりする前に、デスクランブルを実行する必要があります。ビットストリームをCEに送信する前に、CEに縛られたNSP関数は8B/10Bコードストリームをスクランブルする必要があります。
[FC-PI-5] and [FC-PI-5am1] specify 16GFC and define an optional FEC layer.
[FC-PI-5]および[FC-PI-5AM1]は16GFCを指定し、オプションのFECレイヤーを定義します。
If FEC is present, it must be indicated via TTS when the attachment circuit is brought up. Further, the PSN-bound NSP function MUST terminate the FEC and the CE-bound NSP function must generate the FEC.
FECが存在する場合、アタッチメント回路が育てられたときにTTSを介して示される必要があります。さらに、PSNに結合したNSP関数はFECを終了する必要があり、CEバウンドNSP関数はFECを生成する必要があります。
The PSN-bound NSP function is responsible for detecting attachment circuit faults specific to the Fibre Channel such as LOS and sync loss.
PSNに結合したNSP関数は、LOSや同期損失などのファイバーチャネルに固有のアタッチメント回路障害の検出に関与します。
The PSN-bound IWF maps the received scrambled 64B/66B code stream as is into the basic PLE payload.
PSNバインドIWFは、受信したスクランブル64B/66Bコードストリームを基本的なPLEペイロードにマップします。
The CE-bound NSP function MUST perform:
CEバウンドNSP関数を実行する必要があります。
* transmission word sync (Section 49.2.13 of [IEEE802.3]) and
* 送信ワード同期（[IEEE802.3]のセクション49.2.13）および
* descrambling (Section 49.2.10 of [IEEE802.3])
* デスクランブル（[IEEE802.3]のセクション49.2.10）
in order to properly:
適切に：
* replace invalid transmission words with the error transmission word 1Eh and
* 無効な伝送語をエラー伝送ワード1EHに置き換えて
* insert NOS ordered sets when the CE-bound IWF is in PLOS state or when PLE packets are received with the L bit set.
* CEバウンドIWFがPLOS状態にあるとき、またはLビットセットでPLEパケットを受信したときに、NOSの注文セットを挿入します。
Note: Invalid transmission words typically are a consequence of the CE-bound IWF inserting replacement data in case of lost PLE packets or the far-end PSN-bound NSP function not setting sync headers to 11 due to uncorrectable FEC errors.
注：無効な伝送ワードは、通常、PLEパケットの紛失またはファーエンドPSNバインドNSP機能の場合に交換データを挿入するCEバウンドIWFが、修正不可能なFECエラーのために11に同期ヘッダーを設定しないことの結果です。
Before sending the bit-stream to the CE, the CE-bound NSP function MUST also scramble the 64B/66B code stream (Section 49.2.6 of [IEEE802.3]).
ビットストリームをCEに送信する前に、CEに縛られたNSP関数は、64B/66Bコードストリーム（[IEEE802.3]のセクション49.2.6）もスクランブルする必要があります。
[FC-PI-6] specifies 32GFC and [FC-PI-6P] specifies 4-lane 128GFC, both with FEC layer and TTS support being mandatory.
[FC-PI-6]は、32GFCと[FC-PI-6P]を指定し、4レーン128GFCを指定します。
To gain access to the 64B/66B code stream the PSN-bound NSP further MUST perform:
64B/66Bコードストリームにアクセスするには、PSNバウンドNSPをさらに実行する必要があります。
* descrambling (Section of 49.2.10 of [IEEE802.3]),
* デスクランブル（[IEEE802.3]の49.2.10のセクション）、
* FEC decoding (Section 91.5.3.3 of [IEEE802.3]), and
* FECデコード（[IEEE802.3]のセクション91.5.3.3）、および
* reverse transcoding from 256B/257B to 64B/66B (Section 119.2.5.7 of [IEEE802.3]).
* 256B/257Bから64B/66Bへの逆トランスコーディング（[IEEE802.3]のセクション119.2.5.7）。
Further, the PSN-bound NSP MUST perform scrambling (Section 49.2.6 of [IEEE802.3]) before the PSN-bound IWF maps the same into the basic PLE payload.
さらに、PSNに結合したIWFが基本的なPLEペイロードに同じものをマッピングする前に、PSNバインドNSPはスクランブル（[IEEE802.3]のセクション49.2.6）を実行する必要があります。
The PSN-bound NSP function is also responsible for detecting attachment circuit faults specific to the Fibre Channel such as LOS and sync loss.
PSNに結合したNSP関数は、LOSや同期損失などのファイバーチャネルに固有のアタッチメント回路障害の検出にも関与しています。
The CE-bound NSP function MUST perform:
CEバウンドNSP関数を実行する必要があります。
* transmission word sync (Section 119.2.6.3 of [IEEE802.3]) and
* 送信語同期（[IEEE802.3]のセクション119.2.6.3）および
* descrambling (Section 49.2.10 of [IEEE802.3])
* デスクランブル（[IEEE802.3]のセクション49.2.10）
in order to properly:
適切に：
* replace invalid transmission words with the error transmission word 1Eh and
* 無効な伝送語をエラー伝送ワード1EHに置き換えて
* insert NOS ordered sets when the CE-bound IWF is in PLOS state or when PLE packets are received with the L bit set.
* CEバウンドIWFがPLOS状態にあるとき、またはLビットセットでPLEパケットを受信したときに、NOSの注文セットを挿入します。
Note: Invalid transmission words typically are a consequence of the CE-bound IWF inserting replacement data in case of lost PLE packets or the far-end PSN-bound NSP function not setting sync headers to 11 due to uncorrectable FEC errors.
注：無効な伝送ワードは、通常、PLEパケットの紛失またはファーエンドPSNバインドNSP機能の場合に交換データを挿入するCEバウンドIWFが、修正不可能なFECエラーのために11に同期ヘッダーを設定しないことの結果です。
When sending the bit-stream to the CE, the CE-bound NSP function MUST also perform:
ビットストリームをCEに送信する場合、CEに結合したNSP関数も実行する必要があります。
* transcoding from 64B/66B to 256B/257B (Section 119.2.4.2 of [IEEE802.3]),
* 64B/66Bから256B/257Bへのトランスコーディング（[IEEE802.3]のセクション119.2.4.2）、
* FEC encoding (Section 91.5.2.7 of [IEEE802.3]), and
* FECエンコーディング（[IEEE802.3]のセクション91.5.2.7）、および
* scrambling (Section 49.2.6 of [IEEE802.3]).
* スクランブル（[IEEE802.3]のセクション49.2.6）。
[FC-PI-7] specifies 64GFC with a mandatory FEC layer.
[FC-PI-7]は、必須のFECレイヤーで64GFCを指定します。
To gain access to the 64B/66B code stream, the PSN-bound NSP further MUST perform:
64B/66Bコードストリームにアクセスするには、PSNバインドNSPをさらに実行する必要があります。
* alignment lock (Section 134.5.4 of [IEEE802.3] modified to single FEC lane operation),
* アライメントロック（[IEEE802.3]のセクション134.5.4]が単一のFECレーン操作に変更された）、
* FEC decoding (Section 134.5.3.3 of [IEEE802.3]),
* FECデコード（[IEEE802.3]のセクション134.5.3.3）、
* alignment-marker removal (Section 134.5.3.4 of [IEEE802.3]), and
* Alignment-Marker除去（[IEEE802.3]のセクション134.5.3.4）、および
* reverse transcoding from 256B/257B to 64B/66B (Section 91.5.3.5 of [IEEE802.3]).
* 256B/257Bから64B/66Bへの逆トランスコーディング（[IEEE802.3]のセクション91.5.3.5）。
Further, the PSN-bound NSP MUST perform scrambling (Section 49.2.6 of [IEEE802.3]) before the PSN-bound IWF maps the same into the basic PLE payload.
さらに、PSNに結合したIWFが基本的なPLEペイロードに同じものをマッピングする前に、PSNバインドNSPはスクランブル（[IEEE802.3]のセクション49.2.6）を実行する必要があります。
The PSN-bound NSP function is also responsible for detecting attachment circuit faults specific to the Fibre Channel such as LOS and sync loss.
PSNに結合したNSP関数は、LOSや同期損失などのファイバーチャネルに固有のアタッチメント回路障害の検出にも関与しています。
The CE-bound NSP function MUST perform:
CEバウンドNSP関数を実行する必要があります。
* transmission word sync (Section 49.2.13 of [IEEE802.3]) and
* 送信ワード同期（[IEEE802.3]のセクション49.2.13）および
* descrambling (Section 49.2.10 of [IEEE802.3])
* デスクランブル（[IEEE802.3]のセクション49.2.10）
in order to properly:
適切に：
* replace invalid transmission words with the error transmission word 1Eh and
* 無効な伝送語をエラー伝送ワード1EHに置き換えて
* insert NOS ordered sets when the CE-bound IWF is in PLOS state or when PLE packets are received with the L bit set.
* CEバウンドIWFがPLOS状態にあるとき、またはLビットセットでPLEパケットを受信したときに、NOSの注文セットを挿入します。
Note: Invalid transmission words typically are a consequence of the CE-bound IWF inserting replacement data in case of lost PLE packets or the far-end PSN-bound NSP function not setting sync headers to 11 due to uncorrectable FEC errors.
注：無効な伝送ワードは、通常、PLEパケットの紛失またはファーエンドPSNバインドNSP機能の場合に交換データを挿入するCEバウンドIWFが、修正不可能なFECエラーのために11に同期ヘッダーを設定しないことの結果です。
When sending the bit-stream to the CE, the CE-bound NSP function MUST also perform:
ビットストリームをCEに送信する場合、CEに結合したNSP関数も実行する必要があります。
* transcoding from 64B/66B to 256B/257B (Section 91.5.2.5 of [IEEE802.3]),
* 64b/66bから256b/257bへのトランスコーディング（[IEEE802.3]のセクション91.5.2.5）、
* alignment-marker insertion (Section 134.5.2.6 of [IEEE802.3]), and
* Alignment-Marker挿入（[IEEE802.3]のセクション134.5.2.6）、および
* FEC encoding (Section 134.5.2.7 of [IEEE802.3]).
* FECエンコーディング（[IEEE802.3]のセクション134.5.2.7）。
OTN services are special cases of the structured bit-stream defined in Section 3.3.4 of [RFC3985].
OTNサービスは、[RFC3985]のセクション3.3.4で定義されている構造化ビットストリームの特別なケースです。
OTN interfaces are defined in [G.709].
OTNインターフェイスは[G.709]で定義されています。
The PSN-bound NSP function MUST terminate the FEC and replace the OTUk overhead in row 1, columns 8-14 with an all-zeros pattern; this results in an extended ODUk frame as illustrated in Figure 3. The frame alignment overhead (FA OH) in row 1, columns 1-7 is kept as it is.
PSNに結合したNSP関数は、FECを終了し、行1のOTUKオーバーヘッド、列8〜14を全ゼロパターンに置き換える必要があります。これにより、図3に示すように拡張されたODUKフレームが作成されます。列1〜7の列1〜7のフレームアライメントオーバーヘッド（FA OH）がそのまま保持されます。
column #
1 7 8 14 15 3824
+--------+--------+------------------- .. --------------------+
1| FA OH | All-0s | |
+--------+--------+ |
r 2| | |
o | | |
w 3| ODUk overhead | |
# | | |
4| | |
+-----------------+------------------- .. --------------------+
Figure 3: Extended ODUk Frame
図3：拡張Odukフレーム
The PSN-bound NSP function is also responsible for detecting attachment circuit faults specific to OTUk such as LOS, LOF, LOM, and AIS.
PSNに結合したNSP関数は、LOS、LOF、LOM、AISなどのOTUKに固有のアタッチメント回路障害の検出にも関与しています。
The PSN-bound IWF maps the extended ODUk frame into the byte-aligned PLE payload.
PSNバインドIWFは、拡張されたODUKフレームをバイトアリードPLEペイロードにマッピングします。
The CE-bound NSP function will recover the ODUk by searching for the frame alignment overhead in the extended ODUk received from the CE-bound IWF and generating the FEC.
CEバウンドNSP関数は、CEバウンドIWFから受け取った拡張ODUKでフレームアライメントオーバーヘッドを検索し、FECを生成することにより、ODUKを回復します。
When the CE-bound IWF is in PLOS state or when PLE packets are received with the L bit set, the CE-bound NSP function is responsible for generating the ODUk-AIS maintenance signal defined in Section 16.5.1 of [G.709] at client-frame boundaries.
CEバウンドIWFがPLOS状態にある場合、またはLビットセットでPLEパケットを受信した場合、CEバウンドNSP関数は、クライアントフレーム境界の[G.709]のセクション16.5.1で定義されているODUK-AISメンテナンス信号を生成する責任があります。
The basic packet format used by PLE is shown in Figure 4.
PLEで使用される基本的なパケット形式を図4に示します。
+-------------------------------+ -+
| PSN and VPWS Demux | \
| (MPLS/SRv6) | > PSN and VPWS
| | / Demux Headers
+-------------------------------+ -+
| PLE Control Word | \
+-------------------------------+ > PLE Header
| RTP Header | /
+-------------------------------+ --+
| Bit-Stream | \
| Payload | > Payload
| | /
+-------------------------------+ --+
Figure 4: PLE Encapsulation Layer
図4：PLEカプセル化層
This document does not suggest any specific technology be used for implementing the VPWS demultiplexing and PSN layers.
このドキュメントでは、VPWSの非gultiplexingおよびPSNレイヤーを実装するために特定のテクノロジーを使用することは示唆されていません。
The total size of a PLE packet for a specific PW MUST NOT exceed the path MTU between the pair of PEs terminating this PW.
特定のPWのPLEパケットの合計サイズは、このPWを終了するPEのペア間のパスMTUを超えてはなりません。
When an MPLS PSN layer is used, a VPWS label provides the demultiplexing mechanism (as described in Section 5.4.2 of [RFC3985]). The PSN tunnel can be a simple best-path LSP established using LDP (see [RFC5036]) or Segment Routing (SR) (see [RFC8402]); or it can be a traffic-engineered LSP established using RSVP-TE (see [RFC3209]) or SR policies (see [RFC9256]).
MPLS PSNレイヤーを使用すると、VPWSラベルは、[RFC3985]のセクション5.4.2で説明されているように）非拡張メカニズムを提供します。PSNトンネルは、LDP（[RFC5036]を参照）またはセグメントルーティング（SR）（[RFC8402]を参照）を使用して確立されたシンプルなベストパスLSPにすることができます。または、RSVP-TE（[RFC3209]を参照）またはSRポリシー（[RFC9256]を参照）を使用して確立されたトラフィックエンジニアリングLSPである場合があります。
When an SRv6 PSN layer is used, an SRv6 service SID (as defined in [RFC8402]) provides the demultiplexing mechanism and definitions of Section 6 of [RFC9252] apply. Both SRv6 service SIDs with the full IPv6 address format defined in [RFC8986] and CSIDs with the format defined in [RFC9800] can be used.
SRV6 PSNレイヤーを使用すると、SRV6サービスSID（[RFC8402]で定義されている）は、[RFC9252]のセクション6の非複数形成メカニズムと定義を適用します。[RFC8986]で定義されている完全なIPv6アドレス形式を備えたSRV6サービスSIDと[RFC9800]で定義された形式を使用したCSIDの両方を使用できます。
Two new encapsulation behaviors, H.Encaps.L1 and H.Encaps.L1.Red, are defined in this document. The behavior procedures are applicable to both SIDs and CSIDs.
このドキュメントでは、2つの新しいカプセル化動作、h.encaps.l1とh.encaps.l1.redが定義されています。動作手順は、SIDとCSIDの両方に適用されます。
The H.Encaps.L1 behavior encapsulates a frame received from an IWF in an IPv6 packet with a segment routing header (SRH). The received frame becomes the payload of the new IPv6 packet.
H.encaps.l1の動作は、セグメントルーティングヘッダー（SRH）を備えたIPv6パケットのIWFから受信したフレームをカプセル化します。受信したフレームは、新しいIPv6パケットのペイロードになります。
* The next header field of the SRH or the last extension header present MUST be set to 147.
* SRHの次のヘッダーフィールドまたは存在する最後の拡張ヘッダーは、147に設定する必要があります。
* The insertion of the SRH MAY be omitted per [RFC8986] when the SRv6 policy only contains one segment and there is no need to use any flag, tag, or TLV.
* SRV6ポリシーに1つのセグメントのみが含まれており、フラグ、タグ、またはTLVを使用する必要がない場合、SRHの挿入は[RFC8986]ごとに省略できます。
The H.Encaps.L1.Red behavior is an optimization of the H.Encaps.L1 behavior.
h.encaps.l1.redの動作は、H.encaps.l1の動作の最適化です。
* H.Encaps.L1.Red reduces the length of the SRH by excluding the first SID in the SRH. The first SID is only placed in the Destination Address field of the IPv6 header.
* H.ENCAPS.L1.RED SRHの最初のSIDを除外することにより、SRHの長さを減らします。最初のSIDは、IPv6ヘッダーの宛先アドレスフィールドにのみ配置されます。
* The insertion of the SRH MAY be omitted per [RFC8986] when the SRv6 policy only contains one segment and there is no need to use any flag, tag, or TLV.
* SRV6ポリシーに1つのセグメントのみが含まれており、フラグ、タグ、またはTLVを使用する必要がない場合、SRHの挿入は[RFC8986]ごとに省略できます。
Three new "Endpoint with decapsulation and bit-stream cross-connect" behaviors called "End.DX1", "End.DX1 with NEXT-CSID", and "End.DX1 with REPLACE-CSID" are defined in this document. These new behaviors are variants of End.DX2 defined in [RFC8986], and they all have the following procedures in common:
「end.dx1」、「end.dx1 with next-csid」、「end.dx1」と呼ばれる脱カプセル化とビットストリームのクロスコネクト「動作を備えた3つの新しい「エンドポイント」、およびこのドキュメントでは「end.dx1 with appleas-csid」が定義されています。これらの新しい動作は、[rfc8986]で定義されているend.dx2のバリアントであり、すべて共通の手順があります。
The End.DX1 SID MUST be the last segment in an SR Policy, and it is associated with a CE-bound IWF I. When N receives a packet destined to S and S is a local End.DX1 SID, N does the following:
end.dx1 sidはSRポリシーの最後のセグメントでなければならず、それはCEバウンドIWF Iに関連付けられています。Nがsに運命づけられたパケットを受け取った場合、sはローカルend.dx1 sidである場合、nは次のことを行います。
S01. When an SRH is processed {
S02. If (Segments Left != 0) {
S03. Send an ICMP Parameter Problem to the Source Address
with Code 0 (Erroneous header field encountered)
and Pointer set to the Segments Left field,
interrupt packet processing, and discard the packet.
S04. }
S05. Proceed to process the next header in the packet
S06. }
When processing the next (Upper-Layer) header of a packet matching a FIB entry locally instantiated as an End.DX1 SID, N does the following:
end.dx1 sidとしてローカルにインスタンス化されたFIBエントリに一致するパケットの次の（上層層）ヘッダーを処理するとき、nは次のことを行います。
S01. If (Upper-Layer header type == 147 (bit-stream) ) {
S02. Remove the outer IPv6 header with all its extension headers
S03. Forward the remaining frame to the IWF I
S04. } Else {
S05. Process as per {{Section 4.1.1 of RFC 8986}}
S06. }
The PLE header MUST contain the PLE control word (4 bytes) and MUST include a fixed-size RTP header [RFC3550]. The RTP header MUST immediately follow the PLE control word.
PLEヘッダーには、PLEコントロールワード（4バイト）が含まれている必要があり、固定サイズのRTPヘッダー[RFC3550]を含める必要があります。RTPヘッダーは、直後にPLEコントロールワードに従う必要があります。
The format of the PLE control word is in line with the guidance in [RFC4385] and is shown in Figure 5.
PLEコントロールワードの形式は、[RFC4385]のガイダンスと一致しており、図5に示されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0|L|R|RSV|FRG| LEN | Sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: PLE Control Word
図5：PLEコントロールワード
The bits 0..3 of the first nibble are set to 0 to differentiate a control word or ACH from an IP packet or Ethernet frame. The first nibble MUST be set to 0000b to indicate that this header is a control word as defined in Section 3 of [RFC4385].
最初のニブルのビット0..3は0に設定されており、IPパケットまたはイーサネットフレームからコントロールワードまたはACHを区別します。このヘッダーが[RFC4385]のセクション3で定義されているように、このヘッダーがコントロールワードであることを示すために、最初のニブルを0000Bに設定する必要があります。
The other fields in the control word are used as defined below:
コントロールワードの他のフィールドは、以下に定義されているように使用されます。
L:
L:
Set by the PE to indicate that data carried in the payload is invalid due to an attachment circuit fault. The downstream PE MUST send appropriate replacement data. The NSP MAY inject an appropriate downstream fault-indication signal.
PEによって設定されて、ペイロードに含まれるデータがアタッチメント回路障害のために無効であることを示します。下流のPEは、適切な交換データを送信する必要があります。NSPは、適切な下流の断層指示信号を注入する場合があります。
R:
R:
Set by the downstream PE to indicate that the IWF experiences packet loss from the PSN or a server layer backward fault indication is present in the NSP. The R bit MUST be cleared by the PE once the packet loss state or fault indication has cleared.
下流のPEによって設定されて、IWFがPSNからのパケット損失またはサーバー層の逆方向障害表示がNSPに存在することを示します。パケット損失状態または障害の表示がクリアされたら、RビットはPEによってクリアする必要があります。
RSV:
RSV:
These bits are reserved for future use. This field MUST be set to zero by the sender and ignored by the receiver.
これらのビットは、将来の使用のために予約されています。このフィールドは、送信者によってゼロに設定され、受信機によって無視される必要があります。
FRG:
FRG:
These bits MUST be set to zero by the sender and ignored by the receiver as PLE does not use payload fragmentation.
これらのビットは、送信者によってゼロに設定され、PLEがペイロード断片化を使用しないため、受信機によって無視される必要があります。
LEN:
LEN:
In accordance with Section 3 of [RFC4385], the length field MUST always be set to zero as there is no padding added to the PLE packet. The size of the PLE payload MUST be assumed to be as described in Section 6; if the actual packet size is inconsistent with this, the packet MUST be considered malformed.
[RFC4385]のセクション3に従って、PLEパケットにパディングが追加されていないため、長さフィールドは常にゼロに設定する必要があります。PLEペイロードのサイズは、セクション6で説明されていると仮定する必要があります。実際のパケットサイズがこれと矛盾している場合、パケットは奇形と見なされる必要があります。
Sequence number:
シーケンス番号：
The sequence number field is used to provide a common PW sequencing function as well as detection of lost packets. It MUST be generated in accordance with the rules defined in Section 5.1 of [RFC3550] and MUST be incremented with every PLE packet being sent.
シーケンス番号フィールドは、共通のPWシーケンス関数と失われたパケットの検出を提供するために使用されます。[RFC3550]のセクション5.1で定義されているルールに従って生成する必要があり、送信されるすべてのPLEパケットをすべて増加させる必要があります。
The RTP header MUST be included to explicitly convey timing information.
タイミング情報を明示的に伝えるために、RTPヘッダーを含める必要があります。
The RTP header (as defined in [RFC3550]) is reused to align with other bit-stream emulation pseudowires defined by [RFC4553], [RFC5086], and [RFC4842] and to allow PLE implementations to reuse preexisting work.
RTPヘッダー（[RFC3550]で定義されている）は、[RFC4553]、[RFC5086]、および[RFC4842]によって定義された他のビットストリームエミュレーション擬似ワイヤと整列し、PLE実装が事前に存在する仕事を再利用できるように再利用します。
There is no intention to support full RTP topologies and protocol mechanisms, such as header extensions, contributing source (CSRC) list, padding, RTCP, RTP header compression, SRTP, etc., as these are not applicable to PLE VPWS.
ヘッダーエクステンション、寄与源（CSRC）リスト、パディング、RTCP、RTPヘッダー圧縮、SRTPなどの完全なRTPトポロジとプロトコルメカニズムをサポートするつもりはありません。
The format of the RTP header is as shown in Figure 6.
RTPヘッダーの形式は、図6に示すとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Synchronization Source (SSRC) Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: RTP Header
図6：RTPヘッダー
V:
V:
Version
バージョン
The version field MUST be set to 2.
バージョンフィールドは2に設定する必要があります。
P:
P:
Padding
パディング
The padding flag MUST be set to zero by the sender and ignored by the receiver.
パディングフラグは、送信者によってゼロに設定され、受信機によって無視される必要があります。
X:
X:
Header extension
ヘッダー拡張機能
The X bit MUST be set to zero by sender and ignored by receiver.
xビットは、送信者によってゼロに設定され、レシーバーによって無視される必要があります。
CC:
CC:
CSRC count
CSRCカウント
The CC field MUST be set to zero by the sender and ignored by the receiver.
CCフィールドは、送信者によってゼロに設定され、受信機によって無視される必要があります。
M:
M:
Marker
マーカー
The M bit MUST be set to zero by the sender and ignored by the receiver.
Mビットは、送信者によってゼロに設定され、受信機によって無視される必要があります。
PT:
PT:
Payload type
ペイロードタイプ
A PT value MUST be allocated from the range of dynamic values defined in Section 6 of [RFC3551] for each direction of the VPWS. The same PT value MAY be reused for both for directions and between different PLE VPWSs.
VPWSの各方向について、[RFC3551]のセクション6で定義されている動的値の範囲からPT値を割り当てる必要があります。同じPT値が、方向と異なるPLE VPWSの両方で再利用される場合があります。
The PT field MAY be used for detection of misconnections.
PTフィールドは、誤接続の検出に使用できます。
Sequence number:
シーケンス番号：
When using a 16-bit sequence number space, the sequence number in the RTP header MUST be equal to the sequence number in the PLE control word. When using a sequence number space of 32 bits, the initial value of the RTP sequence number MUST be 0 and incremented whenever the PLE control word sequence number cycles through from 0xFFFF to 0x0000.
16ビットシーケンス番号スペースを使用する場合、RTPヘッダーのシーケンス番号は、PLEコントロールワードのシーケンス番号に等しくなければなりません。32ビットのシーケンス番号スペースを使用する場合、RTPシーケンス番号の初期値は0であり、PLEコントロールワードシーケンス番号が0xffffから0x0000までのサイクルを繰り返すたびに増分する必要があります。
Timestamp:
タイムスタンプ：
Timestamp values are used in accordance with the rules established in [RFC3550]. For bit-streams up to 200 Gbps, the frequency of the clock used for generating timestamps MUST be 125 MHz based on a the common clock I. For bit-streams above 200 Gbps, the frequency MUST be 250 MHz.
タイムスタンプの値は、[RFC3550]で確立されたルールに従って使用されます。最大200 Gbpsのビットストリームの場合、タイムスタンプの生成に使用されるクロックの周波数は、一般的なクロックIに基づいて125 MHzでなければなりません。200gbpsを超えるビットストリームの場合、周波数は250 MHzでなければなりません。
SSRC:
SSRC：
Synchronization source
同期ソース
The SSRC field MAY be used for detection of misconnections.
SSRCフィールドは、誤った接続の検出に使用できます。
A bit-stream is mapped into a PLE packet with a fixed payload size, which MUST be defined during VPWS setup, MUST be the same in both directions of the VPWS, and MUST remain unchanged for the lifetime of the VPWS.
ビットストリームは、固定ペイロードサイズのPLEパケットにマッピングされます。これは、VPWSセットアップ中に定義する必要があり、VPWSの両方向で同じでなければならず、VPWSの寿命は変わらない必要があります。
All PLE implementations MUST be capable of supporting the default payload size of 1024 bytes. The payload size SHOULD be configurable to be able to address specific packetization delay and overhead expectations. The smallest supported payload size is 64 bytes.
すべてのPLE実装は、1024バイトのデフォルトのペイロードサイズをサポートできる必要があります。ペイロードサイズは、特定のパケット化遅延とオーバーヘッドの期待に対処できるように構成可能である必要があります。サポートされている最小のペイロードサイズは64バイトです。
The PLE payload is filled with incoming bits of the bit-stream starting from the most significant to the least significant bit without considering any structure of the bit-stream.
PLEペイロードは、ビットストリームの構造を考慮せずに、最も重要なものから最も重要なビットまで始まるビットストリームの入ったビットで満たされています。
The PLE payload is filled in a byte-aligned manner, where the order of the payload bytes corresponds to their order on the attachment circuit. Consecutive bits coming from the attachment circuit fill each payload byte starting from most significant bit to least significant. The PLE payload size MUST be an integer number of bytes.
PLEペイロードは、ペイロードバイトの順序がアタッチメント回路での順序に対応するバイトアライメント方法で埋められます。アタッチメント回路から来る連続したビットは、最も重要なビットから最も重要なものまでの各ペイロードバイトを埋めます。PLEペイロードサイズは、整数数のバイトでなければなりません。
A PLE VPWS can be established using manual configuration or leveraging mechanisms of a signaling protocol.
PLE VPWは、シグナル伝達プロトコルの手動構成またはレバレッジメカニズムを使用して確立できます。
Furthermore, emulation of bit-stream signals using PLE is only possible when the two attachment circuits of the VPWS are of the same service type (OC192, 10GBASE-R, ODU2, etc.) and are using the same PLE payload type and payload size. This can be ensured via manual configuration or via the mechanisms of a signaling protocol.
さらに、PLEを使用したビットストリーム信号のエミュレーションは、VPWの2つのアタッチメント回路が同じサービスタイプ（OC192、10GBase-R、ODU2など）であり、同じPLEペイロードタイプとペイロードサイズを使用している場合にのみ可能です。これは、手動構成またはシグナル伝達プロトコルのメカニズムを介して保証できます。
PLE-related control protocol extensions to LDP [RFC8077] or EVPN-VPWS [RFC8214] are out of scope for this document.
LDP [RFC8077]またはEVPN-VPWS [RFC8214]へのPLE関連制御プロトコル拡張は、このドキュメントの範囲外です。
Extensions for EVPN-VPWS are proposed in [EVPN-VPWS] and for LDP in [LDP-PLE].
EVPN-VPWの拡張は[EVPN-VPWS]および[LDP-PLE]のLDPで提案されています。
After the VPWS is set up, the PSN-bound IWF performs the following steps:
VPWSがセットアップされた後、PSNバインドIWFは次の手順を実行します。
* Packetize the data received from the CE into PLE payloads, all of the same configured size,
* CEから受信したデータをPLEペイロードにパケット化します。すべての構成されたサイズのすべてです。
* Add PLE control word and RTP header with sequence numbers, flags, and timestamps properly set,
* シーケンス番号、フラグ、タイムスタンプを適切に設定したPLEコントロールワードとRTPヘッダーを追加します。
* Add the VPWS demultiplexer and PSN headers,
* VPWS DemultiplexerとPSNヘッダーを追加します。
* Transmit the resulting packets over the PSN,
* 結果のパケットをPSNに送信します。
* Set the L bit in the PLE control word whenever the attachment circuit detects a fault, and
* アタッチメント回路が障害を検出するたびに、PLEコントロールワードにLビットを設定し、
* Set the R bit in the PLE control word whenever the local CE-bound IWF is in packet loss state.
* ローカルCEバウンドIWFがパケット損失状態にあるときはいつでも、PLEコントロールワードにRビットを設定します。
The CE-bound IWF is responsible for removing the PSN and VPWS demultiplexing headers, PLE control word, and RTP header from the received packet stream and sending the bit-stream out via the local attachment circuit.
CEバウンドIWFは、受信したパケットストリームからPSNおよびVPWS Demultiplexingヘッダー、PLEコントロールワード、RTPヘッダーを削除し、ローカルアタッチメント回路を介してビットストリームを送信する責任があります。
A de-jitter buffer MUST be implemented where the PLE packets are stored upon arrival. The size of this buffer SHOULD be locally configurable to allow accommodation of specific PSN PDV expected.
PLEパケットが到着時に保存される場合、デジターバッファーを実装する必要があります。このバッファーのサイズは、特定のPSN PDVを期待するようにローカルで構成できるようにする必要があります。
The CE-bound IWF SHOULD use the sequence number in the control word to detect lost and misordered packets. It MAY use the sequence number in the RTP header for the same purpose. The CE-bound IWF MAY support reordering of packets received out of order. If the CE-bound IWF does not support reordering, it MUST drop the misordered packets.
CEバウンドIWFは、コントロールワードのシーケンス番号を使用して、失われた誤ったパケットを検出する必要があります。同じ目的でRTPヘッダーのシーケンス番号を使用する場合があります。CEバウンドIWFは、故障したパケットの並べ替えをサポートする場合があります。CEバウンドIWFが並べ替えをサポートしていない場合、誤ったパケットをドロップする必要があります。
The payload of a lost or dropped packet MUST be replaced with an equivalent amount of replacement data. The contents of the replacement data MAY be locally configurable. By default, all PLE implementations MUST support generation of "0xAA" as replacement data. The alternating sequence of 0s and 1s of the "0xAA" pattern ensures clock synchronization is maintained and, for 64B/66B code-based services, ensures no invalid sync headers are generated. While sending out the replacement data, the IWF will apply a holdover mechanism to maintain the clock.
紛失またはドロップされたパケットのペイロードは、同等の量の交換データに置き換える必要があります。交換データの内容は、ローカルで構成可能である場合があります。デフォルトでは、すべてのPLE実装は、交換データとして「0xaa」の生成をサポートする必要があります。「0XAA」パターンの0Sおよび1Sの交互のシーケンスにより、クロックの同期が維持され、64B/66Bコードベースのサービスの場合、無効な同期ヘッダーが生成されないようにします。交換データを送信している間、IWFはクロックを維持するためにホールドオーバーメカニズムを適用します。
Whenever the VPWS is not operationally up, the CE-bound NSP function MUST inject the appropriate downstream fault-indication signal.
VPWSが動作的に上昇していない場合はいつでも、CEに結合したNSP関数が適切な下流断層誘導信号を注入する必要があります。
Whenever a VPWS comes up, the CE-bound IWF will enter the intermediate state, will start receiving PLE packets, and will store them in the jitter buffer. The CE-bound NSP function will continue to inject the appropriate downstream fault-indication signal until a preconfigured number of payload s stored in the jitter buffer.
VPWが発生するたびに、CEに縛られたIWFが中間状態に入り、PLEパケットの受信を開始し、ジッターバッファーに保存します。CEに縛られたNSP関数は、ジッターバッファに保存されているPRECOUNTUREDのペイロードSが蓄積されるまで、適切な下流の断層誘導信号を注入し続けます。
After the preconfigured amount of payload is present in the jitter buffer, the CE-bound IWF transitions to the normal operation state, and the content of the jitter buffer is streamed out to the CE in accordance with the required clock. In this state, the CE-bound IWF MUST perform egress clock recovery.
事前に設定された量のペイロードがジッターバッファーに存在すると、CEバウンドIWFが通常の動作状態に遷移し、ジッターバッファーの内容が必要なクロックに従ってCEにストリーミングされます。この状態では、CEに縛られたIWFは出力時計回復を実行する必要があります。
Considerations for choosing the preconfigured amount of payload required to be present for transitioning into the normal state:
通常の状態に移行するために存在するために必要な、事前に設定された量のペイロードを選択するための考慮事項：
* Typically set to 50% of the de-jitter buffer size to equally allow compensating for increasing and decreasing delay
* 通常、脱ジャッタバッファサイズの50％に設定して、遅延の増加を補償することを等しく許可します
* A compromise between the maximum amount of tolerable PDV and delay introduced to the emulated service
* 許容容認可能なPDVの最大量とエミュレートサービスに導入された遅延の間の妥協
The recovered clock MUST comply with the jitter and wander requirements applicable to the type of attachment circuit, specified in:
回収されたクロックは、次のように指定されたアタッチメント回路のタイプに適用されるジッターおよびワンダー要件に準拠する必要があります。
* [G.825], [G.783], and [G.823] for SDH
* [G.825]、[G.783]、および[G.823]のSDH
* [GR253] and [GR499] for SONET
* ソネットの[GR253]および[GR499]
* [G.8261] for synchronous Ethernet
* [G.8261]同期イーサネット用
* [G.8251] for OTN
* [G.8251] OTNの場合
Whenever the L bit is set in the PLE control word of a received PLE packet, the CE-bound NSP function SHOULD inject the appropriate downstream fault-indication signal instead of streaming out the payload.
受信したPLEパケットのPLEコントロールワードにLビットが設定されるたびに、CEバウンドNSP関数は、ペイロードをストリーミングするのではなく、適切な下流断層誘導信号を注入する必要があります。
If the CE-bound IWF detects loss of consecutive packets for a preconfigured amount of time (default is 1 millisecond), it enters PLOS state and a corresponding defect is declared.
CEバウンドIWFが事前に設定された時間（デフォルトは1ミリ秒）の連続パケットの損失を検出すると、PLOS状態に入り、対応する欠陥が宣言されます。
If the CE-bound IWF detects a PLR above a configurable SD threshold for a configurable amount of consecutive 1-second intervals, it enters the DEG state and a corresponding defect is declared. The SD-PLR threshold can be defined as a percentage with the default being 15% or absolute packet count for finer granularity for higher rate interfaces. Possible values for consecutive intervals are 2..10 with the default 7.
CEバウンドIWFが、構成可能な量の連続1秒間隔に対して構成可能なSDしきい値を超えるPLRを検出すると、DEG状態に入り、対応する欠陥が宣言されます。SD-PLRのしきい値は、デフォルトが15％またはより高いレートインターフェイスのより細かい粒度の絶対パケットカウントである割合として定義できます。連続間隔で考えられる値は2..10で、デフォルト7です。
While the PLOS defect is declared, the CE-bound NSP function MUST inject the appropriate downstream fault-indication signal. If the emulated service does not have an appropriate maintenance signal defined, the CE-bound NSP function MAY disable its transmitter instead. Also, the PSN-bound IWF SHOULD set the R bit in the PLE control word of every packet transmitted.
PLOS欠陥が宣言されていますが、CEに結合したNSP関数は、適切な下流断層誘導信号を注入する必要があります。エミュレートされたサービスに適切なメンテナンス信号が定義されていない場合、CEバウンドNSP関数は代わりにその送信機を無効にする可能性があります。また、PSNバインドIWFは、送信されたすべてのパケットのPLEコントロールワードにRビットを設定する必要があります。
The CE-bound IWF changes from the PLOS to normal state after the preconfigured amount of payload has been received similar to the transition from intermediate to normal state.
PROSから正常状態へのCEバウンドIWFの変化は、事前に設定された量のペイロードが中間から正常状態への移行と同様に受信された後に受信されました。
Whenever the R bit is set in the PLE control word of a received PLE packet, the PLE performance monitoring statistics SHOULD get updated.
受信したPLEパケットのPLEコントロールワードでRビットが設定されるたびに、PLEパフォーマンス監視統計が更新されるはずです。
Attachment circuit performance monitoring SHOULD be provided by the NSP. The performance monitors are service specific, documented in related specifications, and beyond the scope of this document.
アタッチメント回路パフォーマンス監視は、NSPによって提供される必要があります。パフォーマンスモニターはサービス固有であり、関連する仕様で文書化され、このドキュメントの範囲を超えています。
The PLE IWF SHOULD provide functions to monitor the network performance to be inline with expectations of transport network operators.
PLE IWFは、輸送ネットワークオペレーターの期待に合わせてネットワークパフォーマンスを監視する機能を提供する必要があります。
The near-end performance monitors defined for PLE are as follows:
PLE用に定義されているニアエンドのパフォーマンスモニターは次のとおりです。
* ES-PLE : PLE Errored Seconds
* ES-PLE：PLEエラー秒
* SES-PLE : PLE Severely Errored Seconds
* SES-PLE：PLE SeveLy Errored Seconds
* UAS-PLE : PLE Unavailable Seconds
* UAS-PLE：PLEは利用できません
Each second with at least one packet lost or a PLOS or DEG defect SHALL be counted as an ES-PLE. Each second with a PLR greater than 15% or a PLOS or DEG defect SHALL be counted as an SES-PLE.
少なくとも1つのパケットが紛失したか、PLOまたはdegの欠陥を持つ各秒は、ES-PLESとしてカウントされます。15％を超えるPLRまたはPLOSまたはDEG欠陥を持つ各秒は、SES-PLEとしてカウントされます。
UAS-PLE SHALL be counted after a configurable number of consecutive SES-PLEs have been observed, and no longer counted after a configurable number of consecutive seconds without an SES-PLE have been observed. The default value for each is 10 seconds.
UAS-PLEは、構成可能な数の連続SES-PLEが観察された後にカウントされ、SES-PLEが観察されない構成可能な数の連続した数秒後にカウントされなくなります。それぞれのデフォルト値は10秒です。
Once unavailability is detected, ES-PLE and SES-PLE counts SHALL be inhibited up to the point where the unavailability was started. Once unavailability is removed, ES-PLE and SES-PLE that occurred along the clearing period SHALL be added to the ES-PLE and SES-PLE counts.
利用不能が検出されると、ES-PLESおよびSES-FLEカウントは、利用不能が開始された時点まで抑制されます。利用不能が削除されると、クリアリング期間に沿って発生したes-fleおよびses-pleは、espleおよびses-fleカウントに追加されます。
A PLE far-end performance monitor provides insight into the CE-bound IWF at the far end of the PSN. The statistics are based on the PLE-RDI indication carried in the PLE control word via the R bit.
PLEファーエンドパフォーマンスモニターは、PSNの遠端にあるCEに縛られたIWFについての洞察を提供します。統計は、Rビットを介してPLEコントロールワードに掲載されたPLE-RDI表示に基づいています。
The PLE VPWS performance monitors are derived from the definitions in accordance with [G.826].
PLE VPWSパフォーマンスモニターは、[G.826]に従って定義から派生しています。
Performance monitoring data MUST be provided by the management interface and SHOULD be provided by a YANG data model. The YANG data model specification is out of scope for this document.
パフォーマンス監視データは、管理インターフェイスによって提供される必要があり、Yangデータモデルで提供する必要があります。Yangデータモデルの仕様は、このドキュメントの範囲外です。
Attachment circuit faults applicable to PLE are detected by the NSP, are service specific, and are documented in Section 4.
PLEに適用可能なアタッチメント回路障害は、NSPによって検出され、サービス固有であり、セクション4に文書化されています。
The two PLE faults, PLOS and DEG, are detected by the IWF.
PLOSとDEGの2つのPLE障害は、IWFによって検出されます。
Faults MUST be timestamped as they are declared and cleared; fault-related information MUST be provided by the management interface and SHOULD be provided by a YANG data model. The YANG data model specification is out of scope for this document.
障害は、宣言されクリアされているため、タイムスタンプで締められなければなりません。障害関連の情報は、管理インターフェイスによって提供される必要があり、Yangデータモデルで提供する必要があります。Yangデータモデルの仕様は、このドキュメントの範囲外です。
The PSN carrying PLE VPWS may be subject to congestion. Congestion considerations for PWs are described in Section 6.5 of [RFC3985].
PLE VPWを運ぶPSNには混雑の対象となる場合があります。PWSの混雑の考慮事項は、[RFC3985]のセクション6.5で説明されています。
PLE VPWS represent inelastic CBR flows that cannot respond to congestion in a TCP-friendly manner (as described in [RFC2914]) and are sensitive to jitter, packet loss, and packets received out of order.
PLE VPWは、TCPに優しい方法で混雑に応答できない非弾性CBRフローを表し（[RFC2914]）、順不同で受け取ったジッター、パケット損失、およびパケットに敏感です。
The PSN providing connectivity between PE devices of a PLE VPWS has to ensure low jitter and low loss. The exact mechanisms used are beyond the scope of this document and may evolve over time. Possible options, but not exhaustively, are as follows:
PLE VPWSのPEデバイス間の接続を提供するPSNは、ジッターの低下と低損失を確保する必要があります。使用される正確なメカニズムは、このドキュメントの範囲を超えており、時間とともに進化する可能性があります。可能なオプションは、網羅的ではありませんが、次のとおりです。
* a Diffserv-enabled [RFC2475] PSN with a per-domain behavior (see [RFC3086]) supporting Expedited Forwarding (see [RFC3246]),
* domevedervederabled [rfc2475] psn domain persed befauce（[rfc3086]を参照）の迅速な転送（[rfc3246]を参照）をサポートするpsn、
* traffic-engineered paths through the PSN with bandwidth reservation and admission control applied, or
* 帯域幅の予約と入場制御が適用されたPSNを通るトラフィックエンジニアリングパス、または
* capacity over-provisioning.
* 容量の過剰プロビジョニング。
As PLE is leveraging VPWS as transport mechanism, the security considerations described in [RFC3985] are applicable.
PLEは輸送メカニズムとしてVPWを活用しているため、[RFC3985]で説明されているセキュリティ上の考慮事項が適用されます。
PLE does not enhance or detract from the security performance of the underlying PSN. It relies upon the PSN mechanisms for encryption, integrity, and authentication whenever required.
PLEは、基礎となるPSNのセキュリティパフォーマンスを強化したり、損なったりしません。暗号化、整合性、および認証のためのPSNメカニズムに依存しています。
The PSN (MPLS or SRv6) is assumed to be trusted and secure. Attackers who manage to send spoofed packets into the PSN could easily disrupt the PLE service. This MUST be prevented by following best practices for the isolation of the PSN. These protections are described in Section 3.4 of [RFC4381], Section 4.2 of [RFC5920], Section 8 of [RFC8402], and Section 9.3 of [RFC9252].
PSN（MPLSまたはSRV6）は、信頼され安全であると想定されています。PSNにスプーフィングされたパケットを送信できた攻撃者は、PLEサービスを簡単に混乱させる可能性があります。これは、PSNの分離のためのベストプラクティスに従うことで防ぐ必要があります。これらの保護は、[RFC4381]のセクション3.4、[RFC5920]のセクション4.2、[RFC8402]のセクション8、および[RFC9252]のセクション9.3で説明されています。
PLE PWs share susceptibility to a number of pseudowire-layer attacks and will use whatever mechanisms for confidentiality, integrity, and authentication that are developed for general PWs. These methods are beyond the scope of this document.
PLE PWは、多くの擬似層層攻撃に対する感受性を共有し、一般的なPWS向けに開発された機密性、完全性、認証のためにあらゆるメカニズムを使用します。これらの方法は、このドキュメントの範囲を超えています。
Random initialization of sequence numbers, in both the control word and the RTP header, makes known-plaintext attacks more difficult.
コントロールワードとRTPヘッダーの両方で、シーケンス番号のランダムな初期化により、既知のプレーンテキスト攻撃がより困難になります。
Misconnection detection using the SSRC and/or PT field of the RTP header can increase the resilience to misconfiguration and some types of denial-of-service (DoS) attacks. Randomly chosen expected values decrease the chance of a spoofing attack being successful.
RTPヘッダーのSSRCおよび/またはPTフィールドを使用した誤接合検出は、誤った構成の回復力と、一部の種類のサービス拒否（DOS）攻撃を増加させる可能性があります。ランダムに選択された期待値は、スプーフィング攻撃が成功する可能性を減らします。
A data plane attack may force PLE packets to be dropped, reordered, or delayed beyond the limit of the CE-bound IWF's dejitter buffer leading to either degradation or service disruption. Considerations outlined in [RFC9055] are a good reference.
データプレーン攻撃により、PLEパケットは、CEバウンドIWFのデジッターバッファーの制限を超えて、劣化またはサービスの中断につながるCEバウンドIWFのdejitterバッファーを超えて、パケットをドロップ、並べ替え、または遅延させることがあります。[RFC9055]で概説されている考慮事項は、良い参照です。
Clock synchronization leveraging PTP is sensitive to PDV and vulnerable to various threats and attack vectors. Considerations outlined in [RFC7384] should be taken into account.
PTPを活用するクロック同期は、PDVに敏感であり、さまざまな脅威や攻撃ベクターに対して脆弱です。[RFC7384]で概説されている考慮事項を考慮する必要があります。
This document introduces a new value to be used in the next header field of an IPv6 header or any extension header indicating that the payload is an emulated bit-stream. IANA has assigned the following from the "Assigned Internet Protocol Numbers" registry [IANA-Proto].
このドキュメントでは、IPv6ヘッダーの次のヘッダーフィールドまたはペイロードがエミュレートされたビットストリームであることを示す任意の拡張ヘッダーで使用する新しい値を導入します。IANAは、「割り当てられたインターネットプロトコル番号」レジストリ[IANA-Proto]から以下を割り当てました。
+=========+=========+============+================+===========+
| Decimal | Keyword | Protocol | IPv6 Extension | Reference |
| | | | Header | |
+=========+=========+============+================+===========+
| 147 | BIT-EMU | Bit-stream | Y | RFC 9801 |
| | | Emulation | | |
+---------+---------+------------+----------------+-----------+
Table 1
This document introduces three new SRv6 Endpoint behaviors. IANA has assigned identifier values in the "SRv6 Endpoint Behaviors" registry under the "Segment Routing" registry group [IANA-SRv6-End].
このドキュメントでは、3つの新しいSRV6エンドポイントの動作を紹介します。IANAは、「セグメントルーティング」レジストリグループ[IANA-SRV6-END]の下にある「SRV6エンドポイント動作」レジストリに識別子値を割り当てました。
+=======+========+===========================+===========+
| Value | Hex | Endpoint Behavior | Reference |
+=======+========+===========================+===========+
| 158 | 0x009E | End.DX1 | RFC 9801 |
+-------+--------+---------------------------+-----------+
| 159 | 0x009F | End.DX1 with NEXT-CSID | RFC 9801 |
+-------+--------+---------------------------+-----------+
| 160 | 0x00A0 | End.DX1 with REPLACE-CSID | RFC 9801 |
+-------+--------+---------------------------+-----------+
Table 2
[G.707] ITU-T, "Network node interface for the synchronous digital
hierarchy (SDH)", ITU-T Recommendation G.707, January
2007, <https://www.itu.int/rec/T-REC-G.707>.
[G.709] ITU-T, "Interfaces for the optical transport network",
ITU-T Recommendation G.709, June 2020,
<https://www.itu.int/rec/T-REC-G.709>.
[G.783] ITU-T, "Characteristics of synchronous digital hierarchy
(SDH) equipment functional blocks", ITU-T
Recommendation G.783, March 2006,
<https://www.itu.int/rec/T-REC-G.783>.
[G.823] ITU-T, "The control of jitter and wander within digital
networks which are based on the 2048 kbit/s hierarchy",
ITU-T Recommendation G.823, March 2000,
<https://www.itu.int/rec/T-REC-G.823>.
[G.825] ITU-T, "The control of jitter and wander within digital
networks which are based on the synchronous digital
hierarchy (SDH)", ITU-T Recommendation G.825, March 2000,
<https://www.itu.int/rec/T-REC-G.825>.
[G.8251] ITU-T, "The control of jitter and wander within the
optical transport network (OTN)", ITU-T
Recommendation G.8251, November 2022,
<https://www.itu.int/rec/T-REC-G.8251>.
[G.8261] ITU-T, "Timing and synchronization aspects in packet
networks", ITU-T Recommendation G.8261, August 2019,
<https://www.itu.int/rec/T-REC-G.8261>.
[G.8261.1] ITU-T, "Packet delay variation network limits applicable
to packet-based methods (Frequency synchronization)",
ITU-T Recommendation G.8261.1, February 2012,
<https://www.itu.int/rec/T-REC-G.8261.1>.
[G.8262] ITU-T, "Timing characteristics of synchronous equipment
clocks", ITU-T Recommendation G.8262, October 2024,
<https://www.itu.int/rec/T-REC-G.8262>.
[G.8265.1] ITU-T, "Precision time protocol telecom profile for
frequency synchronization", ITU-T Recommendation G.8265.1,
November 2022, <https://www.itu.int/rec/T-REC-G.8265.1>.
[GR253] Telcordia, "Synchronous Optical Network (SONET) Transport
Systems: Common Generic Criteria", GR-253, October 2009,
<https://telecom-info.njdepot.ericsson.net/site-cgi/ido/
docs.cgi?ID=2111701336SEARCH&DOCUMENT=GR-253>.
[GR499] Telcordia, "Transport Systems Generic Requirements (TSGR)
- Common Requirements", GR-499, November 2009,
<https://telecom-info.njdepot.ericsson.net/site-cgi/ido/
docs.cgi?ID=2111701336SEARCH&DOCUMENT=GR-499>.
[IANA-Proto]
IANA, "Assigned Internet Protocol Numbers",
<https://www.iana.org/assignments/protocol-numbers>.
[IANA-SRv6-End]
IANA, "SRv6 Endpoint Behaviors",
<https://www.iana.org/assignments/segment-routing>.
[IEEE802.3]
IEEE, "IEEE Standard for Ethernet", IEEE Std 802.3-2022,
DOI 10.1109/IEEESTD.2022.9844436, July 2022,
<https://ieeexplore.ieee.org/document/9844436>.
[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>.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <https://www.rfc-editor.org/info/rfc3550>.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", STD 65, RFC 3551,
DOI 10.17487/RFC3551, July 2003,
<https://www.rfc-editor.org/info/rfc3551>.
[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>.
[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>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
(SRv6) Network Programming", RFC 8986,
DOI 10.17487/RFC8986, February 2021,
<https://www.rfc-editor.org/info/rfc8986>.
[RFC9252] Dawra, G., Ed., Talaulikar, K., Ed., Raszuk, R., Decraene,
B., Zhuang, S., and J. Rabadan, "BGP Overlay Services
Based on Segment Routing over IPv6 (SRv6)", RFC 9252,
DOI 10.17487/RFC9252, July 2022,
<https://www.rfc-editor.org/info/rfc9252>.
[RFC9800] Cheng, W., Ed., Filsfils, C., Li, Z., Decraene, B., and F.
Clad, Ed., "Compressed SRv6 Segment List Encoding",
RFC 9800, DOI 10.17487/RFC9800, June 2025,
<https://www.rfc-editor.org/info/rfc9800>.
[ATIS-0900105.09.2013]
ATIS, "Synchronous Optical Network (SONET) - Network
Element Timing and Synchronization", ATIS-
0900105.09.2013(S2023), 2023,
<https://webstore.ansi.org/standards/atis/
atis0900105092013s2023>.
[EVPN-VPWS]
Gringeri, S., Whittaker, J., Schmutzer, C., Ed.,
Vasudevan, B., and P. Brissette, "Ethernet VPN Signalling
Extensions for Bit-stream VPWS", Work in Progress,
Internet-Draft, draft-schmutzer-bess-bitstream-vpws-
signalling-02, 18 October 2024,
<https://datatracker.ietf.org/doc/html/draft-schmutzer-
bess-bitstream-vpws-signalling-02>.
[FC-PI-2] INCITS, "Information Technology - Fibre Channel Physical
Interfaces - 2 (FC-PI-2)", INCITS 404-2006 (S2016), 2016,
<https://webstore.ansi.org/standards/incits/
incits4042006s2016>.
[FC-PI-5] INCITS, "Information Technology - Fibre Channel - Physical
Interface-5 (FC-PI-5)", INCITS 479-2011 (S2021), 2021,
<https://webstore.ansi.org/standards/incits/
incits4792011s2021>.
[FC-PI-5am1]
INCITS, "Information Technology - Fibre Channel - Physical
Interface - 5/Amendment 1 (FC-PI-5/AM1)",
INCITS 479-2011/AM1-2016 (R2021), 2021,
<https://webstore.ansi.org/standards/incits/
incits4792011am2016r2021>.
[FC-PI-6] INCITS, "Information Technology - Fibre Channel - Physical
Interface - 6 (FC-PI-6)", INCITS 512-2015 (R2020), 2020,
<https://webstore.ansi.org/standards/incits/
incits5122015r2020>.
[FC-PI-6P] INCITS, "Information Technology - Fibre Channel - Physical
Interface - 6P (FC-PI-6P)", INCITS 533-2016 (R2021), 2021,
<https://webstore.ansi.org/standards/incits/
incits5332016r2021>.
[FC-PI-7] ISO/IEC, "Information technology - Fibre channel - Part
147: Physical interfaces - 7 (FC-PI-7)", ISO/
IEC 14165-147:2021, 2021,
<https://www.iso.org/standard/80933.html>.
[G.826] ITU-T, "End-to-end error performance parameters and
objectives for international, constant bit-rate digital
paths and connections", ITU-T Recommendation G.826,
December 2002, <https://www.itu.int/rec/T-REC-G.826>.
[LDP-PLE] Schmutzer, C., Ed., "LDP Extensions to Support Private
Line Emulation (PLE)", Work in Progress, Internet-Draft,
draft-schmutzer-pals-ple-signaling-02, 20 October 2024,
<https://datatracker.ietf.org/doc/html/draft-schmutzer-
pals-ple-signaling-02>.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, DOI 10.17487/RFC2475, December 1998,
<https://www.rfc-editor.org/info/rfc2475>.
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41,
RFC 2914, DOI 10.17487/RFC2914, September 2000,
<https://www.rfc-editor.org/info/rfc2914>.
[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>.
[RFC3086] Nichols, K. and B. Carpenter, "Definition of
Differentiated Services Per Domain Behaviors and Rules for
their Specification", RFC 3086, DOI 10.17487/RFC3086,
April 2001, <https://www.rfc-editor.org/info/rfc3086>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<https://www.rfc-editor.org/info/rfc3209>.
[RFC3246] Davie, B., Charny, A., Bennet, J.C.R., Benson, K., Le
Boudec, J.Y., Courtney, W., Davari, S., Firoiu, V., and D.
Stiliadis, "An Expedited Forwarding PHB (Per-Hop
Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002,
<https://www.rfc-editor.org/info/rfc3246>.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, DOI 10.17487/RFC3711, March 2004,
<https://www.rfc-editor.org/info/rfc3711>.
[RFC4197] Riegel, M., Ed., "Requirements for Edge-to-Edge Emulation
of Time Division Multiplexed (TDM) Circuits over Packet
Switching Networks", RFC 4197, DOI 10.17487/RFC4197,
October 2005, <https://www.rfc-editor.org/info/rfc4197>.
[RFC4381] Behringer, M., "Analysis of the Security of BGP/MPLS IP
Virtual Private Networks (VPNs)", RFC 4381,
DOI 10.17487/RFC4381, February 2006,
<https://www.rfc-editor.org/info/rfc4381>.
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385,
February 2006, <https://www.rfc-editor.org/info/rfc4385>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", STD 89,
RFC 4443, DOI 10.17487/RFC4443, March 2006,
<https://www.rfc-editor.org/info/rfc4443>.
[RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron,
"Encapsulation Methods for Transport of Ethernet over MPLS
Networks", RFC 4448, DOI 10.17487/RFC4448, April 2006,
<https://www.rfc-editor.org/info/rfc4448>.
[RFC4553] Vainshtein, A., Ed. and YJ. Stein, Ed., "Structure-
Agnostic Time Division Multiplexing (TDM) over Packet
(SAToP)", RFC 4553, DOI 10.17487/RFC4553, June 2006,
<https://www.rfc-editor.org/info/rfc4553>.
[RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer
2 Virtual Private Networks (L2VPNs)", RFC 4664,
DOI 10.17487/RFC4664, September 2006,
<https://www.rfc-editor.org/info/rfc4664>.
[RFC4842] Malis, A., Pate, P., Cohen, R., Ed., and D. Zelig,
"Synchronous Optical Network/Synchronous Digital Hierarchy
(SONET/SDH) Circuit Emulation over Packet (CEP)",
RFC 4842, DOI 10.17487/RFC4842, April 2007,
<https://www.rfc-editor.org/info/rfc4842>.
[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.
Yasukawa, Ed., "Extensions to Resource Reservation
Protocol - Traffic Engineering (RSVP-TE) for Point-to-
Multipoint TE Label Switched Paths (LSPs)", RFC 4875,
DOI 10.17487/RFC4875, May 2007,
<https://www.rfc-editor.org/info/rfc4875>.
[RFC4906] Martini, L., Ed., Rosen, E., Ed., and N. El-Aawar, Ed.,
"Transport of Layer 2 Frames Over MPLS", RFC 4906,
DOI 10.17487/RFC4906, June 2007,
<https://www.rfc-editor.org/info/rfc4906>.
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
"LDP Specification", RFC 5036, DOI 10.17487/RFC5036,
October 2007, <https://www.rfc-editor.org/info/rfc5036>.
[RFC5086] Vainshtein, A., Ed., Sasson, I., Metz, E., Frost, T., and
P. Pate, "Structure-Aware Time Division Multiplexed (TDM)
Circuit Emulation Service over Packet Switched Network
(CESoPSN)", RFC 5086, DOI 10.17487/RFC5086, December 2007,
<https://www.rfc-editor.org/info/rfc5086>.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
<https://www.rfc-editor.org/info/rfc5920>.
[RFC7212] Frost, D., Bryant, S., and M. Bocci, "MPLS Generic
Associated Channel (G-ACh) Advertisement Protocol",
RFC 7212, DOI 10.17487/RFC7212, June 2014,
<https://www.rfc-editor.org/info/rfc7212>.
[RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in
Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384,
October 2014, <https://www.rfc-editor.org/info/rfc7384>.
[RFC8077] Martini, L., Ed. and G. Heron, Ed., "Pseudowire Setup and
Maintenance Using the Label Distribution Protocol (LDP)",
STD 84, RFC 8077, DOI 10.17487/RFC8077, February 2017,
<https://www.rfc-editor.org/info/rfc8077>.
[RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J.
Rabadan, "Virtual Private Wire Service Support in Ethernet
VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017,
<https://www.rfc-editor.org/info/rfc8214>.
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
<https://www.rfc-editor.org/info/rfc8754>.
[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>.
[RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov,
A., and P. Mattes, "Segment Routing Policy Architecture",
RFC 9256, DOI 10.17487/RFC9256, July 2022,
<https://www.rfc-editor.org/info/rfc9256>.
[RFC9293] Eddy, W., Ed., "Transmission Control Protocol (TCP)",
STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022,
<https://www.rfc-editor.org/info/rfc9293>.
[T11] INCITS, "T11 - Fibre Channel",
<https://www.incits.org/committees/t11>.
The authors would like to thank Alexander Vainshtein, Yaakov Stein, Erik van Veelen, Faisal Dada, Giles Heron, Luca Della Chiesa, and Ashwin Gumaste for their early contributions, review, comments, and suggestions.
著者は、Alexander Vainshtein、Yaakov Stein、Erik Van Veelen、Faisal Dada、Giles Heron、Luca Della Chiesa、Ashwin Gumasteの初期の貢献、レビュー、コメント、提案に感謝します。
Special thank you to:
特別に感謝します：
* Carlos Pignataro and Nagendra Kumar Nainar for giving the authors new-to-the-IETF guidance on how to get started
* カルロス・ピグナタロとナゲンドラ・クマール・ナイナーは、著者に始める方法について新たなガイダンスを提供してくれた
* Stewart Bryant for being our shepherd
* 私たちの羊飼いであるスチュワート・ブライアント
* Tal Mizahi, Joel Halpern, Christian Huitema, Tony Li, and Tommy Pauly for their reviews and suggestions during Last Call
* タル・ミザヒ、ジョエル・ハルパーン、クリスチャン・フイテマ、トニー・リー、トミー・ポーリーの最後の電話でのレビューと提案について
* Andrew Malis and Gunter van de Velde for their guidance through the process
* アンドリュー・マリスとガンター・ヴァン・デ・ヴェルデは、プロセスを通じて彼らのガイダンスについて
Andreas Burk
1&1 Versatel
Email: andreas.burk@magenta.de
Faisal Dada
AMD
Email: faisal.dada@amd.com
Gerald Smallegange
Ciena Corporation
Email: gsmalleg@ciena.com
Erik van Veelen
Aimvalley
Email: erik.vanveelen@aimvalley.com
Luca Della Chiesa
Cisco Systems, Inc.
Email: ldellach@cisco.com
Nagendra Kumar Nainar
Cisco Systems, Inc.
Email: naikumar@cisco.com
Carlos Pignataro
Blue Fern Consulting
Email: Carlos@Bluefern.consulting
Steven Gringeri
Verizon
Email: steven.gringeri@verizon.com
Jeremy Whittaker
Verizon
Email: jeremy.whittaker@verizon.com
Nicolai Leymann
Deutsche Telekom
Email: N.Leymann@telekom.de
Christian Schmutzer (editor)
Cisco Systems, Inc.
Email: cschmutz@cisco.com
Chris Brown
Ciena Corporation
Email: cbrown@ciena.com