[要約] RFC 4842は、パケット上での回線エミュレーションを可能にするSONET/SDHの標準であり、CEPの目的は、既存のSONET/SDHネットワークをパケットベースのネットワークに統合することです。
Network Working Group A. Malis
Request for Comments: 4842 Verizon Communications
Category: Standards Track P. Pate
Overture Networks
R. Cohen, Ed.
Resolute Networks
D. Zelig
Corrigent Systems
April 2007
Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet (CEP)
同期光ネットワーク/同期デジタル階層（SONET/SDH）パケット上の回路エミュレーション（CEP）
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
Abstract
概要
This document provides encapsulation formats and semantics for emulating Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) circuits and services over MPLS.
このドキュメントは、同期光ネットワーク/同期デジタル階層（SONET/SDH）回路とMPLSを超えるサービスをエミュレートするためのカプセル化形式とセマンティクスを提供します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
4. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. CEP Encapsulation Format . . . . . . . . . . . . . . . . . . . 5
5.1. SONET/SDH Fragment . . . . . . . . . . . . . . . . . . . . 6
5.2. CEP Header . . . . . . . . . . . . . . . . . . . . . . . . 7
5.3. RTP Header . . . . . . . . . . . . . . . . . . . . . . . . 9
5.4. PSN Encapsulation . . . . . . . . . . . . . . . . . . . . 11
6. CEP Operation . . . . . . . . . . . . . . . . . . . . . . . . 11
6.1. CEP Packetizer and De-Packetizer . . . . . . . . . . . . . 11
6.2. Packet Synchronization . . . . . . . . . . . . . . . . . . 12
6.2.1. Acquisition of Packet Synchronization . . . . . . . . 13
6.2.2. Loss of Packet Synchronization . . . . . . . . . . . . 13
7. SONET/SDH Maintenance Signals . . . . . . . . . . . . . . . . 13
7.1. SONET/SDH to PSN . . . . . . . . . . . . . . . . . . . . . 13
7.1.1. CEP-AIS: AIS-P/V Indication . . . . . . . . . . . . . 13
7.1.2. Unequipped Indication . . . . . . . . . . . . . . . . 14
7.1.3. CEP-RDI: Remote Defect Indication . . . . . . . . . . 15
7.2. PSN to SONET/SDH . . . . . . . . . . . . . . . . . . . . . 15
7.2.1. CEP-AIS: AIS-P/V Indication . . . . . . . . . . . . . 15
7.2.2. Unequipped Indication . . . . . . . . . . . . . . . . 16
8. SONET/SDH Transport Timing . . . . . . . . . . . . . . . . . . 16
9. SONET/SDH Pointer Management . . . . . . . . . . . . . . . . . 17
9.1. Explicit Pointer Adjustment Relay (EPAR) . . . . . . . . . 17
9.2. Adaptive Pointer Management (APM) . . . . . . . . . . . . 19
10. CEP Performance Monitors . . . . . . . . . . . . . . . . . . . 19
10.1. Near-End Performance Monitors . . . . . . . . . . . . . . 19
10.2. Far-End Performance Monitors . . . . . . . . . . . . . . . 20
11. Payload Compression Options . . . . . . . . . . . . . . . . . 20
11.1. Dynamic Bandwidth Allocation . . . . . . . . . . . . . . . 21
11.2. Service-Specific Payload Formats . . . . . . . . . . . . . 21
11.2.1. Fractional STS-1 (VC-3) Encapsulation . . . . . . . . 21
11.2.1.1. Fractional STS-1 CEP Header . . . . . . . . . . . 23
11.2.1.2. B3 Compensation . . . . . . . . . . . . . . . . . 24
11.2.1.3. Actual Payload Size . . . . . . . . . . . . . . . 24
11.2.2. Asynchronous T3/E3 STS-1 (VC-3) Encapsulation . . . . 25
11.2.2.1. T3 Payload Compression . . . . . . . . . . . . . 25
11.2.2.2. E3 Payload Compression . . . . . . . . . . . . . 26
11.2.3. Fractional VC-4 Encapsulation . . . . . . . . . . . . 26
11.2.3.1. Fractional VC-4 Mapping . . . . . . . . . . . . . 27
11.2.3.2. Fractional VC-4 CEP Header . . . . . . . . . . . 28
11.2.3.3. B3 Compensation . . . . . . . . . . . . . . . . . 29
11.2.3.4. Actual Payload Sizes . . . . . . . . . . . . . . 30
12. Signaling of CEP Pseudowires . . . . . . . . . . . . . . . . . 30
12.1. CEP/TDM Payload Bytes . . . . . . . . . . . . . . . . . . 31
12.2. CEP/TDM Bit Rate . . . . . . . . . . . . . . . . . . . . . 31
12.3. CEP Options . . . . . . . . . . . . . . . . . . . . . . . 32
13. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 34
14. Security Considerations . . . . . . . . . . . . . . . . . . . 34
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35
17. Co-Authors . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Appendix A. SONET/SDH Rates and Formats . . . . . . . . . . . . . 36
Appendix B. Example Network Diagrams . . . . . . . . . . . . . . 37
18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40
18.1. Normative References . . . . . . . . . . . . . . . . . . . 40
18.2. Informative References . . . . . . . . . . . . . . . . . . 41
This document provides encapsulation formats and semantics for emulating SONET/SDH circuits and services over MPLS.
このドキュメントは、MPLSを介したSONET/SDH回路とサービスをエミュレートするためのカプセル化形式とセマンティクスを提供します。
The generic requirements and architecture for Pseudowire Emulation Edge-to-Edge (PWE3) are described in [PWE3-REQ] and [PWE3-ARCH]. Additional requirements for emulation of SONET/SDH and lower-rate TDM circuits are described in [PWE3-TDM-REQ].
Pseudowireエミュレーションエッジとエッジ（PWE3）の一般的な要件とアーキテクチャは、[PWE3-REQ]および[PWE3-ARCH]で説明されています。SONET/SDHおよび低レートのTDM回路のエミュレーションのための追加要件は、[PWE3-TDM-REQ]で説明されています。
This document provides encapsulation formats and semantics for emulating SONET/SDH circuits and services over MPLS packet-switched networks (PSNs). Emulation of the following digital signals are defined:
このドキュメントは、MPLSパケットスイッチネットワーク（PSNS）を介したSONET/SDH回路とサービスをエミュレートするためのカプセル化形式とセマンティクスを提供します。次のデジタル信号のエミュレーションが定義されています。
1. Synchronous Payload Envelope (SPE)/Virtual Container (VC-n): STS-1/VC-3, STS-3c/VC-4, STS-12c/VC-4-4c, STS-48c/VC-4-16c, STS-192c/ VC-4-64c, etc.
1. 同期ペイロードエンベロープ（SPE）/仮想コンテナ（VC-N）：STS-1/VC-3、STS-3C/VC-4、STS-12C/VC-4-4C、STS-48C/VC-4-16C、STS-192C/ VC-4-64Cなど
2. Virtual Tributary (VT)/Virtual Container (VC-n): VT1.5/VC-11, VT2/VC-12, VT3, VT6/VC-2
2. 仮想支流（VT）/仮想コンテナ（VC-N）：VT1.5/VC-11、VT2/VC-12、VT3、VT6/VC-2
For the remainder of this document, these constructs are referred to as SONET/SDH channels.
このドキュメントの残りの部分では、これらのコンストラクトはSONET/SDHチャネルと呼ばれます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[RFC2119]に記載されているように解釈される。
ADM Add Drop Multiplexer AIS Alarm Indication Signal APM Adaptive Pointer Management AU-n Administrative Unit-n (SDH) AUG Administrative Unit Group (SDH) BIP Bit Interleaved Parity BITS Building Integrated Timing Supply CEP Circuit Emulation over Packet DBA Dynamic Bandwidth Allocation EBM Equipped Bit Mask EPAR Explicit Pointer Adjustment Relay LOF Loss of Frame LOS Loss of Signal LTE Line Terminating Equipment POH Path Overhead PSN Packet Switched Network PTE Path Terminating Equipment PW Pseudowire RDI Remote Defect Indication SDH Synchronous Digital Hierarchy SONET Synchronous Optical Network SPE Synchronous Payload Envelope STM-n Synchronous Transport Module-n (SDH) STS-n Synchronous Transport Signal-n (SONET) TDM Time Division Multiplexing TOH Transport Overhead TU-n Tributary Unit-n (SDH) TUG-n Tributary Unit Group-n (SDH) UNEQ Unequipped VC-n Virtual Container-n (SDH) VT Virtual Tributary (SONET) VTG Virtual Tributary Group (SONET)
ADDドロップマルチプレクサーAISアラーム表示信号APM適応ポインター管理AU-N管理ユニット-N（SDH）8月管理ユニットグループ（SDH）BIPインターリーブパリティビット統合タイミング供給CEPサーキットエミュレーションマスクEPAR明示的なポインター調整リレーフレームフレームの損失信号LTEラインの損失機器ポーパスPSNパケットスイッチスイッチスイッチスイッチドットパス終端機器PW PSEUDOWIRE RDIリモート欠陥適応同期輸送モジュール-N（SDH）STS-N同期トランスポートシグナル-N（SONET）TDMタイムディビジョン多重化TOHトランスポートオーバーヘッドTU-Nトリビタリユニット-N（SDH）TUG-N支流ユニットグループ-N（SDH）UNEQ UNEQ UNSAIPIPT VC-n仮想コンテナ-N（SDH）VT仮想支流（SONET）VTG仮想支流グループ（SONET）
In order to transport SONET/SDH circuits through a packet-oriented network, the SPE (or VT) is broken into fragments, and a CEP header and optionally an RTP header are prepended to each fragment.
SONET/SDH回路をパケット指向のネットワークを介して輸送するために、SPE（またはVT）がフラグメントに分割され、CEPヘッダーとオプションでRTPヘッダーが各フラグメントに加えられます。
The basic CEP packet appears in Figure 1.
基本的なCEPパケットが図1に表示されます。
+-----------------------------------+
| PSN and Multiplexing Layer |
| Headers |
+-----------------------------------+
| CEP Header |
+-----------------------------------+
| RTP Header |
| (RFC 3550) |
+-----------------------------------+
| |
| |
| SONET/SDH |
| Fragment |
| |
| |
+-----------------------------------+
Figure 1: Basic CEP Packet
図1：基本的なCEPパケット
The SONET/SDH fragments MUST be byte aligned with the SONET/SDH SPE or VT. The first bit received from each byte of the SONET/SDH MUST be the Most Significant Bit of each byte in the SONET/SDH fragment.
SONET/SDHフラグメントは、SONET/SDH SPEまたはVTに沿ってバイトを合わせる必要があります。SONET/SDHの各バイトから受信した最初のビットは、SONET/SDHフラグメントの各バイトの最も重要なビットでなければなりません。
SONET/SDH bytes are placed into the SONET/SDH fragment in the same order in which they are received.
SONET/SDHバイトは、受信したのと同じ順序でSONET/SDHフラグメントに配置されます。
SONET/SDH optical interfaces use binary coding and therefore are scrambled prior to transmission to ensure an adequate number of transitions. For clarity, this scrambling is referred to as physical layer scrambling/descrambling.
SONET/SDH光インターフェイスはバイナリコーディングを使用するため、伝送の前にスクランブルされて、適切な数の遷移を確保します。明確にするために、このスクランブルは、物理的な層のスクランブル/説明と呼ばれます。
In addition, many payload formats (such as for Asynchronous Transfer Mode (ATM) and High-Level Data Link Control (HDLC)) include an additional layer of scrambling to provide protection against transition density violations within the SPEs. This function is referred to as payload scrambling/unscrambling.
さらに、多くのペイロード形式（非同期転送モード（ATM）および高レベルのデータリンク制御（HDLC）など）には、SPE内の遷移密度違反に対する保護を提供するための追加のスクランブル層が含まれています。この関数は、ペイロードスクランブル/スクランブルと呼ばれます。
CEP assumes that physical layer scrambling/unscrambling occurs as part of the SONET/SDH section/line termination Native Service Processing (NSP) functions.
CEPは、SONET/SDHセクション/ライン終端ネイティブサービス処理（NSP）関数の一部として、物理層のスクランブル/スクランブルが発生すると想定しています。
However, CEP makes no assumption about payload scrambling. The SONET/SDH fragments MUST be constructed without knowledge or processing of any incidental payload scrambling.
ただし、CEPはペイロードスクランブルについて仮定しません。SONET/SDHフラグメントは、偶発的なペイロードスクランブルの知識や処理なしに構築する必要があります。
CEP implementations MUST include the H3 (or V3) byte in the SONET/SDH fragment during negative pointer adjustment events, and MUST remove the stuff byte from the SONET/SDH fragment during positive pointer adjustment events.
CEP実装には、ネガティブポインター調整イベント中にSONET/SDHフラグメントにH3（またはV3）バイトを含める必要があり、ポジティブポインター調整イベント中にSONET/SDHフラグメントからバイトを削除する必要があります。
VT emulation implementations MUST NOT carry the VT pointer bytes V1, V2, V3, and V4 as part of the CEP payload. The only exception is the carriage of V3 during negative pointer adjustment as described above.
VTエミュレーションの実装は、CEPペイロードの一部として、VTポインターバイトV1、V2、V3、およびV4を搭載してはなりません。唯一の例外は、上記のように負のポインター調整中のV3のキャリッジです。
All CEP SPE implementations MUST support a packet size of 783 bytes and MAY support other packet sizes.
すべてのCEP SPE実装は、783バイトのパケットサイズをサポートする必要があり、他のパケットサイズをサポートする場合があります。
VT emulation implementations MUST support payload size of full VT super-frame, and MAY support 1/2 and 1/4 VT super-frame payload sizes.
VTエミュレーションの実装は、完全なVTスーパーフレームのペイロードサイズをサポートする必要があり、1/2および1/4 VTスーパーフレームペイロードサイズをサポートする場合があります。
Table 1 below describes single super-frame payload size per VT type.
以下の表1は、VTタイプごとの単一のスーパーフレームペイロードサイズを示しています。
+-------------+--------------+
| VT type | Size (Bytes) |
+-------------+--------------+
| VT1.5/VC-11 | 104 |
| VT2/VC-12 | 140 |
| VT3 | 212 |
| VT6/VC-2 | 428 |
+-------------+--------------+
Table 1: VT Super-Frame Payload Sizes
表1：VTスーパーフレームペイロードサイズ
OPTIONAL SONET/SDH Fragment formats have been defined to reduce the bandwidth requirements of the emulated SONET/SDH circuits under certain conditions. These OPTIONAL formats are included in Section 11.
オプションのSONET/SDHフラグメント形式は、特定の条件下でエミュレートされたSONET/SDH回路の帯域幅要件を削減するために定義されています。これらのオプションの形式はセクション11に含まれています。
The CEP header supports both a basic and extended mode. The Basic CEP header provides the minimum functionality necessary to accurately emulate a SONET/SDH circuit over a PSN. Extended headers are utilized for some of the OPTIONAL SONET/SDH fragment formats described in Section 11.
CEPヘッダーは、基本モードと拡張モードの両方をサポートします。基本的なCEPヘッダーは、PSNを介してSONET/SDH回路を正確にエミュレートするために必要な最小機能を提供します。拡張ヘッダーは、セクション11で説明されているオプションのSONET/SDHフラグメント形式の一部に使用されます。
Enhanced functionality and commonality with other real-time Internet applications is provided by RTP encapsulation.
他のリアルタイムインターネットアプリケーションとの機能と共通性の強化は、RTPカプセル化によって提供されます。
The CEP header has the following format:
CEPヘッダーには次の形式があります。
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|N|P|FRG|Length[0:5]| Sequence Number[0:15] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |Structure Pointer[0:11]|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: CEP Header Format
図2：CEPヘッダー形式
L bit: CEP-AIS. This bit MUST be set to 1 to signal to the downstream PE that a failure condition has been detected on the attachment circuit. Failure conditions leading to generation of CEP-AIS and the mapping of CEP-AIS signal on the downstream attachment circuit are described in Section 7.
Lビット：CEP-AIS。このビットは、アタッチメント回路で故障条件が検出されたことを下流のPEに信号するために1に設定する必要があります。CEP-AIの生成につながる障害条件と、下流のアタッチメント回路でのCEP-AIS信号のマッピングについては、セクション7で説明します。
R bit: CEP-RDI. This bit MUST be set to 1 to signal to the upstream PE that a loss of packet synchronization has occurred. This bit MUST be set to 0 once packet synchronization is acquired. See Section 6.2 for details.
Rビット：CEP-RDI。このビットは、上流のPEにパケットの同期の損失が発生したことを信号するために1に設定する必要があります。このビットは、パケットの同期が取得されると、0に設定する必要があります。詳細については、セクション6.2を参照してください。
N and P bits: These bits are used to explicitly relay negative and positive pointer adjustments events across the PSN. The use of N and P bits is OPTIONAL. If not used, N and P bits MUST be set to 0. See Section 9 for details.
NおよびPビット：これらのビットは、PSN全体でネガティブおよびポジティブポインター調整イベントを明示的に中継するために使用されます。NおよびPビットの使用はオプションです。使用していない場合は、NおよびPビットを0に設定する必要があります。詳細については、セクション9を参照してください。
Table 2 describes the interpretation of N and P bits settings.
表2に、NおよびP BITS設定の解釈を示しています。
+---+---+-----------------------------+
| N | P | Interpretation |
+---+---+-----------------------------+
| 0 | 0 | No Pointer Adjustments |
| 0 | 1 | Positive Pointer Adjustment |
| 1 | 0 | Negative Pointer Adjustment |
| 1 | 1 | Loss of Pointer Alarm |
+---+---+-----------------------------+
Table 2: Interpretation of N and P Bits
表2：NおよびPビットの解釈
FRG bits: FRG bits MUST be set to 0 by sender and ignored by receiver.
FRGビット：FRGビットは、送信者によって0に設定され、レシーバーによって無視される必要があります。
SONET data is continuously fragmented into packets. The structure pointer field designates the offset between the SONET SPE or VT structure and the packet boundary.
SONETデータは、パケットに継続的に断片化されています。構造ポインターフィールドは、SONET SPEまたはVT構造とパケット境界の間のオフセットを示します。
Length [0:5]: The Length field, if other than zero, indicates the length of the CEP header, plus the length of the RTP header if used, plus the length of the payload. The Length field MUST be set if the length of CEP header plus RTP header if used, plus payload is less than or equal to 64 bytes and MUST be set to 0 otherwise. In particular, if the payload is suppressed (e.g., DBA) the Length field MUST be set to the CEP header length plus the RTP header length if used.
長さ[0：5]：ゼロ以外の長さフィールドは、CEPヘッダーの長さと、使用する場合はRTPヘッダーの長さとペイロードの長さを示します。CEPヘッダーの長さが使用されている場合はRTPヘッダーの長さと、ペイロードが64バイト以下であり、それ以外の場合は0に設定する必要がある場合は、長さフィールドを設定する必要があります。特に、ペイロードが抑制された場合（例：DBA）、長さフィールドは、使用する場合はCEPヘッダー長とRTPヘッダー長に設定する必要があります。
Sequence Number [0:15]: The packet sequence number MUST continuously cycle from 0 to 0xFFFF. It is generated and processed in accordance with the rules established in [RTP].
シーケンス番号[0:15]：パケットシーケンス番号は、0から0xffffまで継続的にサイクリングする必要があります。[RTP]で確立されたルールに従って生成および処理されます。
Structure Pointer [0:11]: The structure pointer MUST contain the offset of the first byte of the SONET structure within the packet payload. For SPE emulation, the structure pointer locates the J1 byte within the CEP packet. For VT emulation, the structure pointer locates the V5 byte within the packet. The structure pointer value ranges between 0 to 0xFFE, where 0 represents the first byte after the CEP header. The structure pointer MUST be set to 0xFFF if a packet does not carry the J1 (or V5) byte. An arbitrary pointer change (New Data Flag (NDF) event) in the attachment circuit changes the offset of the SONET structure within the CEP packet and therefore changes the structure pointer value.
構造ポインター[0:11]：構造ポインターには、パケットペイロード内のソネット構造の最初のバイトのオフセットを含める必要があります。SPEエミュレーションの場合、構造ポインターはCEPパケット内のJ1バイトを見つけます。VTエミュレーションの場合、構造ポインターはパケット内のV5バイトを見つけます。構造ポインター値の範囲は0〜0xffeで、0はCEPヘッダーの後の最初のバイトを表します。パケットがJ1（またはV5）バイトを運ばない場合、構造ポインターを0xFFFに設定する必要があります。アタッチメント回路の任意のポインター変更（新しいデータフラグ（NDF）イベント）がCEPパケット内のソネット構造のオフセットを変更するため、構造ポインター値を変更します。
Reserved field: The reserved field MUST be set to 0 by the sender and ignored by receiver.
予約済みフィールド：予約済みフィールドは、送信者によって0に設定され、レシーバーによって無視されなければなりません。
Usage of the RTP header is OPTIONAL. Although CEP MAY employ an RTP header when explicit transfer of timing information is required, this is purely a formal reuse of the header format. RTP mechanisms, such as header extensions, contributing source (CSRC) list, padding, RTP Control Protocol (RTCP), RTP header compression, Secure Realtime Transport Protocol (SRTP), etc., are not applicable to pseudowires. CEP uses the RTP Header as shown below.
RTPヘッダーの使用はオプションです。CEPは、タイミング情報の明示的な転送が必要な場合にRTPヘッダーを使用する場合がありますが、これは純粋にヘッダー形式の正式な再利用です。ヘッダーエクステンション、寄与源（CSRC）リスト、パディング、RTPコントロールプロトコル（RTCP）、RTPヘッダー圧縮、安全なリアルタイム輸送プロトコル（SRTP）などのRTPメカニズムは、擬似に適用されません。CEPは、以下に示すようにRTPヘッダーを使用します。
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 3: RTP Header
図3：RTPヘッダー
V: Version. The Version field MUST be set to 2.
V：バージョン。バージョンフィールドは2に設定する必要があります。
P: Padding. No padding is required. The P bit MUST be set to 0 by sender and ignored by receiver.
P：パディング。パディングは必要ありません。Pビットは、送信者によって0に設定され、受信機によって無視される必要があります。
X: Header extension. No extensions are defined. The X bit MUST be set to 0 by sender and ignored by receiver.
X：ヘッダー拡張機能。拡張機能は定義されていません。xビットは、送信者によって0に設定され、受信機によって無視される必要があります。
CC: CSRC count. The CC field MUST be set to 0 by sender and ignored by receiver.
CC：CSRCカウント。CCフィールドは、送信者によって0に設定され、受信機によって無視される必要があります。
M: Marker. The M bit MUST be set to 0 by sender and ignored by receiver.
M：マーカー。Mビットは、送信者によって0に設定され、受信機によって無視される必要があります。
PT [0:6]: Payload type. A PT value SHOULD be allocated from the range of dynamic values for each direction of the PW. The same PT value MAY be reused both for direction and between different CEP PWs.
PT [0：6]：ペイロードタイプ。PT値は、PWの各方向の動的値の範囲から割り当てる必要があります。同じPT値は、方向と異なるCEP PW間の両方で再利用できます。
Sequence Number [0:15]: The packet sequence number MUST continuously cycle from 0 to 0xFFFF. It is generated and processed in accordance with the rules established in [RTP]. The CEP receiver MUST sequence packets according to the Sequence Number field of the CEP header and MAY verify correct sequencing using RTP Sequence Number field.
シーケンス番号[0:15]：パケットシーケンス番号は、0から0xffffまで継続的にサイクリングする必要があります。[RTP]で確立されたルールに従って生成および処理されます。CEPレシーバーは、CEPヘッダーのシーケンス番号フィールドに従ってパケットをシーケンスし、RTPシーケンス番号フィールドを使用して正しいシーケンスを検証する必要があります。
Timestamp [0:31]: Timestamp values are used in accordance with the rules established in [RTP]. Frequency of the clock used for generating timestamps MUST be 19.44 MHz based on a local reference.
タイムスタンプ[0:31]：タイムスタンプの値は、[RTP]で確立されたルールに従って使用されます。タイムスタンプの生成に使用されるクロックの頻度は、ローカル参照に基づいて19.44 MHzでなければなりません。
SSRC [0:31]: Synchronization source. The SSRC field MAY be used for detection of misconnections.
SSRC [0:31]：同期ソース。SSRCフィールドは、誤った接続の検出に使用できます。
This document defines the transport of CEP over MPLS PSNs. The bottom label in the MPLS label stack MUST be used to de-multiplex individual CEP channels. In keeping with the conventions used in [PWE3-CONTROL], this de-multiplexing label is referred to as the PW Label and the upper labels are referred to as Tunnel Labels. The CEP header follows the generic PWE3 Control Word format specified in [PWE3-MPLSCW] for use over an MPLS PSN.
このドキュメントでは、MPLS PSNS上のCEPの輸送を定義しています。MPLSラベルスタックのボトムラベルは、個々のCEPチャネルをマルチプレックスするために使用する必要があります。[PWE3-Control]で使用されている規則に合わせて、この脱マルチプレックスラベルはPWラベルと呼ばれ、アッパーラベルはトンネルラベルと呼ばれます。CEPヘッダーは、MPLS PSNで使用するために[PWE3-MPLSCW]で指定された一般的なPWE3コントロールワード形式に従います。
Transport of CEP over other PSN technologies is out of scope of this document.
他のPSNテクノロジーを介したCEPの輸送は、このドキュメントの範囲外です。
A CEP implementation MUST support a normal mode of operation and MAY support additional bandwidth conserving modes as described in Section 11. During normal operation, SONET/SDH payloads are fragmented, prepended with the appropriate headers, and then transmitted into the packet network.
CEPの実装は、通常の動作モードをサポートする必要があり、セクション11で説明されているように追加の帯域幅保存モードをサポートする場合があります。通常の動作中に、SONET/SDHペイロードは断片化され、適切なヘッダーで準備され、パケットネットワークに送信されます。
As with all adaptation functions, CEP has two distinct components: adapting TDM SONET/SDH into a CEP packet stream, and converting the CEP packet stream back into a TDM SONET/SDH. The first function is referred to as CEP packetizer or sender and the second as CEP de-packetizer or receiver. This terminology is illustrated below.
すべての適応関数と同様に、CEPには2つの異なるコンポーネントがあります。TDMSONET/SDHをCEPパケットストリームに適応させ、CEPパケットストリームをTDM SONET/SDHに戻すことです。最初の関数はCEPパッケージ剤または送信者と呼ばれ、2番目はCEP de-packetizerまたは受信機と呼ばれます。この用語を以下に示します。
+------------+ +---------------+
| | | |
SONET --> | CEP | --> PSN --> | CEP | --> SONET
SDH | Packetizer | | De-Packetizer | SDH
| | | |
+------------+ +---------------+
(sender) (receiver)
Figure 4: CEP Terminology
図4：CEP用語
The CEP de-packetizer requires a buffering mechanism to account for delay variation in the CEP packet stream. This buffering mechanism is generically referred to as the CEP jitter buffer.
CEP De-Packetizerは、CEPパケットストリームの遅延変動を説明するためにバッファリングメカニズムを必要とします。このバッファリングメカニズムは、一般的にCEPジッターバッファーと呼ばれます。
During normal operation, the CEP packetizer receives a fixed-rate byte stream from a SONET/SDH interface. When a packet worth of data is received from a SONET/SDH channel, the necessary headers are prepended to the SPE fragment and the resulting CEP packet is transmitted into the packet network. Because all CEP packets associated with a specific SONET/SDH channel have the same length, the transmission of CEP packets for that channel SHOULD occur at regular intervals.
通常の操作中、CEPパケットはSONET/SDHインターフェイスから固定レートバイトストリームを受け取ります。SONET/SDHチャネルからパケット相当のデータが受信されると、必要なヘッダーがSPEフラグメントに加えられ、結果のCEPパケットがパケットネットワークに送信されます。特定のSONET/SDHチャネルに関連付けられたすべてのCEPパケットの長さは同じであるため、そのチャネルのCEPパケットの送信は定期的に発生するはずです。
At the far end of the packet network, the CEP de-packetizer receives packets into a jitter buffer and then plays out the received byte stream at a fixed rate onto the corresponding SONET/SDH channel. The jitter buffer SHOULD be adjustable in length to account for varying network delay behavior. On average, the receive packet rate from the packet network should be balanced by the transmission rate onto the SONET/SDH channel.
パケットネットワークの遠端で、CEP de-Packetizerはパケットをジッターバッファーに受け取り、対応するSONET/SDHチャネルに固定速度で受信したバイトストリームを再生します。ジッターバッファーは、さまざまなネットワーク遅延動作を考慮して、長さが調整可能である必要があります。平均して、パケットネットワークからの受信パケットレートは、送信レートのバランスをSONET/SDHチャネルにバランスさせる必要があります。
The CEP sequence numbers provide a mechanism to detect lost and/or misordered packets. The sequence number in the CEP header MUST be used when transmission of the RTP header is suppressed. The CEP de-packetizer MUST detect lost or misordered packets. The CEP de-packetizer SHOULD play out an all-ones pattern (AIS) in place of any dropped packets. The CEP de-packetizer SHOULD re-order packets received out of order. If the CEP de-packetizer does not support re-ordering, it MUST drop misordered packets.
CEPシーケンス番号は、紛失および/または誤ったパケットを検出するメカニズムを提供します。RTPヘッダーの送信が抑制される場合、CEPヘッダーのシーケンス番号を使用する必要があります。CEP de-packetizerは、紛失または誤ったパケットを検出する必要があります。CEP de-Packetizerは、ドロップされたパケットの代わりにオールオーンパターン（AI）を再生する必要があります。CEP de-packetizerは、受信したパケットを順番に再注文する必要があります。CEP de-packetizerが再注文をサポートしていない場合、誤った順序パケットを削除する必要があります。
A key component in declaring the state of a CEP service is whether or not the CEP de-packetizer is in or out of packet synchronization. The following paragraphs describe how that determination is made.
CEPサービスの状態を宣言する重要なコンポーネントは、CEP de-Packetizerがパケットの同期内外であるかどうかです。次の段落では、その決定がどのように行われるかを説明しています。
As packets are received from the PSN, they are placed into a jitter buffer prior to play out on the SONET/SDH interface. If a CEP de-packetizer supports re-ordering, any packet received before its play out time will still be considered valid.
PSNからパケットが受信されると、SONET/SDHインターフェイスで再生される前にジッターバッファーに配置されます。CEP de-Packetizerが再注文をサポートしている場合、プレイアウト時間の前に受け取ったパケットはまだ有効と見なされます。
The determination of acquisition or loss of packet synchronization is always made at SONET/SDH play out time. During SONET/SDH play out, the CEP de-packetizer will play received CEP packets onto the SONET/ SDH interface. However, if the jitter buffer is empty or the packet to be played out has not been received, the CEP de-packetizer will play out an 'empty packet' composed of an all-ones AIS pattern onto the SONET/SDH interface in place of the unavailable packet.
SONET/SDHプレイアウト時間では、取得またはパケットの同期の喪失の決定が常に行われます。SONET/ SDHプレイ中に、CEP De-Packetizerは、SONET/ SDHインターフェイスに受信したCEPパケットを再生します。ただし、ジッターバッファーが空の場合、または再生されるパケットが受信されていない場合、CEPデパックタイザーは、SONET/SDHインターフェイスの代わりにAISパターンで構成される「空のパケット」を再生します。利用できないパケット。
The acquisition of packet synchronization is based on the number of sequential CEP packets that are played onto the SONET/SDH interface. Loss of packet synchronization is based on the number of sequential 'empty' packets that are played onto the SONET/SDH interface. Specific details of these two cases are described below.
パケット同期の取得は、SONET/SDHインターフェイスで再生されるシーケンシャルCEPパケットの数に基づいています。パケットの同期の損失は、SONET/SDHインターフェイスで再生されるシーケンシャルの「空の」パケットの数に基づいています。これら2つのケースの具体的な詳細については、以下に説明します。
At startup, a CEP de-packetizer will be out of packet synchronization by default. To declare packet synchronization at startup or after a loss of packet synchronization, the CEP de-packetizer must play out a configurable number of CEP packets with sequential sequence numbers towards the SONET/SDH interface.
スタートアップでは、CEP de-Packetizerはデフォルトでパケット同期外になります。スタートアップ時またはパケットの同期を失った後、パケットの同期を宣言するには、CEP de-Packetizerは、SONET/SDHインターフェイスに向けてシーケンシャルシーケンス番号を備えた構成可能な数のCEPパケットを再生する必要があります。
Once a CEP de-packetizer is in packet synchronization state, it may encounter a set of events that will cause it to lose packet synchronization.
CEP de-Packetizerがパケット同期状態になると、パケットの同期を失う原因となる一連のイベントに遭遇する可能性があります。
If the CEP de-packetizer encounters more than a configurable number of sequential empty packets, the CEP de-packetizer MUST declare a Loss of Packet Synchronization (LOPS) defect.
CEP de-Packetizerが構成可能な数のシーケンシャル空のパケット以上の遭遇に遭遇した場合、CEP de-Packetizerはパケット同期（LOPS）の欠陥の損失を宣言する必要があります。
LOPS failure is declared after 2.5 +/- 0.5 seconds of LOPS defect, and cleared after 10 seconds free of LOPS defect state. The circuit is considered down as long as LOPS failure is declared.
LOPS障害は、2.5 /-0.5秒のLOPS欠陥の後に宣言され、LOPS欠陥状態がない10秒後にクリアされます。LOPSの障害が宣言されている限り、回路はダウンと見なされます。
This section describes the mapping of maintenance and alarm signals between the SONET/SDH network and the CEP pseudowire. For clarity, the mappings are split into two groups: SONET/SDH to PSN, and PSN to SONET/SDH.
このセクションでは、SONET/SDHネットワークとCEP Pseudowireの間のメンテナンスとアラーム信号のマッピングについて説明します。明確にするために、マッピングはSONET/SDHからPSN、PSNからSONET/SDHの2つのグループに分割されます。
For coherent failure detection, isolation, monitoring, and troubleshooting, SONET/SDH failure indications MUST be transferred correctly over the CEP pseudowire, and CEP connection failures MUST be mapped to SONET/SDH SPE/VT failure indications. Failure detection capabilities and performance monitoring capabilities are dependent on the NSP functionality, e.g., LTE, PTE, Tandem Connection Monitoring [G.707], or Non-intrusive Monitoring (intermediate connection monitoring).
コヒーレントの故障検出、分離、監視、およびトラブルシューティングの場合、SONET/SDHの故障指示はCEP擬似ワイヤを介して正しく転送する必要があり、CEP接続の障害はSONET/SDH SPE/VT障害兆候にマッピングする必要があります。障害検出機能とパフォーマンス監視機能は、NSP機能、例えばLTE、PTE、タンデム接続モニタリング[G.707]、または非侵入モニタリング（中間接続モニタリング）に依存します。
The following sections describe the mapping of SONET/SDH Maintenance Signals and Alarm conditions into CEP pseudowire indications.
次のセクションでは、SONET/SDHメンテナンスシグナルのマッピングとCEP疑似条件へのアラーム条件について説明します。
SONET/SDH Path outages are signaled by using maintenance alarms such as Path AIS (AIS-P). AIS-P, in particular, indicates that the SONET/ SDH Path is not currently transmitting valid end-user data, and the SPE contains all ones. Similarly, AIS-V indicates that the VT is not currently transmitting valid end-user data, and the VT contains all ones.
SONET/SDHパスの停止は、Path AIS（AIS-P）などのメンテナンスアラームを使用して通知されます。特に、AIS-Pは、SONET/ SDHパスが現在有効なエンドユーザーデータを送信していないことを示しており、SPEにはすべてのデータが含まれています。同様に、AIS-Vは、VTが現在有効なエンドユーザーデータを送信しておらず、VTにすべてのデータが含まれていることを示しています。
It should be noted that nearly every type of service-affecting section or line defect would result in an AIS-P/V condition.
ほとんどすべてのタイプのサービスに影響を与えるセクションまたはラインの欠陥がAIS-P/V状態になることに注意する必要があります。
The mapping of SONET/SDH failures into the SPE/VT layer is considered part of the NSP function and is based on the principles specified in [GR253], [SONET], [G.707], [G.806], and [G.783]. For example, should the SONET Section Layer detect a Loss of Signal (LOS) or Loss of Frame (LOF) or Section Trace Mismatch (TIM) conditions, an AIS-L is sent up to the Line Layer. If the Line Layer detects AIS-L or Loss of Pointer (LOP), an AIS-P is sent to the Path Layer. If the Path is terminated at the PE (i.e., a PTE) and the Path Layer detects AIS-P or UNEQ-P or TIM-P or PLM-P an AIS-V is sent to the VT Layer.
SONET/SDH障害のSPE/VT層へのマッピングは、NSP関数の一部と見なされ、[GR253]、[SONET]、[G.707]、[G.806]、および[[]で指定された原理に基づいています。G.783]。たとえば、SONETセクション層が信号の損失（LOS）またはフレームの損失（LOF）またはセクショントレースミスマッチ（TIM）条件を検出した場合、AIS-Lがラインレイヤーに送信されます。ライン層がAIS-Lまたはポインターの損失（LOP）を検出すると、AIS-Pがパス層に送信されます。パスがPE（つまり、PTE）で終了し、パス層がAIS-PまたはUNEQ-PまたはTIM-PまたはPLM-Pを検出すると、AIS-VがVTレイヤーに送信されます。
The AIS-P/V indication is transferred to the CEP packetizer. During AIS-P/V, CEP packets are generated as usual. The L bit in the CEP header MUST be set to 1 to signal AIS-P/V explicitly through the packet network. The N and P bits SHOULD be set to 1 to indicate loss of pointer indication.
AIS-P/Vの適応症は、CEPパッケージ剤に転送されます。AIS-P/Vの間、CEPパケットは通常どおり生成されます。CEPヘッダーのLビットは、パケットネットワークを介してAIS-P/Vを明示的に信号するために1に設定する必要があります。NおよびPビットを1に設定して、ポインター表示の喪失を示す必要があります。
If DBA has been enabled for AIS-P/V, only the necessary headers and optional padding are transmitted into the packet network. The Length field MUST be set to the size of the CEP header plus the size of the RTP header if used.
AIS-P/VでDBAが有効になっている場合、必要なヘッダーとオプションのパディングのみがパケットネットワークに送信されます。長さフィールドは、CEPヘッダーのサイズに加えて、使用する場合はRTPヘッダーのサイズに設定する必要があります。
Unequipped indication is used for bandwidth conserving modes defined in Section 11 as a trigger for payload removal.
装備されていない表示は、ペイロード除去のトリガーとしてセクション11で定義された帯域幅保存モードに使用されます。
The declaration of the SPE/VT channel as Unequipped MUST conform to [GR253], [SONET], [G.806], and [G.783]. Unequipped circuits do not carry valid end-user data, but MAY be used for transporting valid information in the SPE/VT overhead bytes. Supervisory Unequipped signals and Tandem Connection transport are two such applications:
装備されていないSPE/VTチャネルの宣言は、[GR253]、[SONET]、[G.806]、および[G.783]に適合する必要があります。装備されていない回路は、有効なエンドユーザーデータを搭載していませんが、SPE/VTオーバーヘッドバイトで有効な情報を輸送するために使用される場合があります。監督の未装備の信号とタンデム接続トランスポートは、次の2つのアプリケーションです。
Supervisory Unequipped signal (called TEST-P in [SONET]) is used to provide a test signal for pre-service testing or in-service supervision of a path connection to a remote PTE from a PTE or an intermediate non-terminating path network element. Both Unequipped and Supervisory Unequipped signals carry Unequipped Signal Label defined to be zero. To distinguish between Unequipped and Supervisory Unequipped signals, [G.806] recommends that the SPE/VT Trace bytes J1/J2 be set to a non-zero value in Supervisory Unequipped signals.
監督の未装備信号（[SONET]のTest-Pと呼ばれる）を使用して、PTEまたは中間の非終了パスネットワーク要素からのリモートPTEへのパス接続の事前サービステストまたはサービス内監督のテスト信号を提供するために使用されます。装備されていない監督者と監視の両方の信号の両方が、ゼロと定義されている未装備の信号ラベルを搭載しています。装備されていない監督の非装備の信号を区別するために、[G.806]は、SPE/VTトレースバイトJ1/J2を監督の未装備信号の非ゼロ値に設定することを推奨します。
The SPE/VT overhead bytes N1/Z6 (SDH refers to Z6 as N2) optionally transport Tandem Connection signals between intermediate network elements. Unequipped signals transporting Tandem Connection would have non-zero N1 or N2/Z6 bytes.
SPE/VTオーバーヘッドバイトN1/Z6（SDHはZ6をN2と呼びます）は、オプションで中間ネットワーク要素間でタンデム接続信号を輸送します。タンデム接続を輸送する未装備の信号には、ゼロ以外のN1またはN2/Z6バイトが含まれます。
Therefore, the CEP packetizer MUST declare a circuit unequipped only if the Signal Label, Trace (J1/J2), and Tandem Connection (N1/N2/Z6) bytes all have zero value.
したがって、CEPパケットは、信号ラベル、Trace（J1/J2）、およびタンデム接続（N1/N2/Z6）バイトがすべてゼロ値を持っている場合にのみ、装備されていない回路を宣言する必要があります。
During SPE/VT Unequipped, the N and P bits MUST be interpreted as usual. The SPE/VT MUST be transmitted into the packet network along with the appropriate headers.
spe/vt装備中に、nおよびpビットは通常どおり解釈する必要があります。SPE/VTは、適切なヘッダーとともにパケットネットワークに送信する必要があります。
If DBA has been enabled for Unequipped SPE/VT, only the necessary headers and optional padding are transmitted into the packet network. The Length field MUST be set to the size of the CEP header plus the size of the RTP header if used. The N and P bits MAY be used to signal pointer adjustments as normal.
装備されていないSPE/VTでDBAが有効になっている場合、必要なヘッダーとオプションのパディングのみがパケットネットワークに送信されます。長さフィールドは、CEPヘッダーのサイズに加えて、使用する場合はRTPヘッダーのサイズに設定する必要があります。NおよびPビットは、通常どおりポインター調整を信号するために使用できます。
The CEP function MUST send CEP-RDI indication towards the packet network during loss of packet synchronization by setting the R bit to one in the CEP header. The CEP function SHOULD clear the R bit once packet synchronization is restored.
CEP関数は、RビットをCEPヘッダーの1に設定することにより、パケットの同期を失ったときにパケットネットワークに向けてCEP-RDIの表示を送信する必要があります。CEP関数は、パケットの同期が復元されると、Rビットをクリアする必要があります。
The following sections describe the mapping of pseudowire indications to SONET/SDH Maintenance Signals and Alarm conditions.
次のセクションでは、SONET/SDHのメンテナンス信号とアラーム条件への擬似ワイヤの適応症のマッピングについて説明します。
There are several conditions in the packet network that cause the CEP de-packetization function to play out an AIS-P/V indication towards a SONET/SDH channel. The CEP de-packetizer MUST play out one packet's worth of all ones for each packet received, and MUST set the SONET/ SDH Overhead to signal AIS-P/V as defined in [SONET], [GR253], and [G.707].
パケットネットワークには、CEP脱パケット化関数がSONET/SDHチャネルに向けてAIS-P/Vの適応を再生するようにするいくつかの条件があります。CEP de-Packetizerは、受信した各パケットに対して1つのパケットのすべてのパケットを再生する必要があり、[SONET]、[GR253]、および[G.707で定義されているようにAIS-P/ Vを信号にするようにSONET/ SDHオーバーヘッドを設定する必要があります。]。
The first of these is the receipt of CEP packets with the L bit set to one indicating that the far end has detected an error leading to declaration of AIS-P/V alarm. In addition to the play out of AIS-P/V, the CEP de-packetizer SHOULD set the pointer value to all-ones value.
これらの最初のものは、lビットが1つに設定されたCEPパケットの受領で、遠端がAIS-P/Vアラームの宣言につながるエラーが検出されたことを示しています。AIS-P/Vのプレイに加えて、CEP de-Packetizerはポインター値をすべての値に設定する必要があります。
The second case that will cause a CEP de-packetization function to play out an AIS-P/V indication onto a SONET/SDH channel is during loss of packet synchronization.
CEP脱パケット化関数がSonet/SDHチャネルにAIS-P/Vの表示を再生するようにする2番目のケースは、パケット同期の喪失中です。
The third case is the receipt of CEP packets with both the N and P bits set to 1. This is an explicit indication of Loss of Pointer LOP-P/V received at the far-end of the packet network. In addition to play out of AIS-P/V, the CEP de-packetizer SHOULD set the pointer value to all-ones value.
3番目のケースは、NとPビットの両方を1に設定したCEPパケットの受領です。これは、パケットネットワークの遠端で受け取ったポインターLOP-P/Vの損失の明示的な指標です。AIS-P/Vのプレイに加えて、CEP de-Packetizerはポインター値をすべての値に設定する必要があります。
There are several conditions in the packet network that cause the CEP function to transmit Unequipped indications onto the SONET/SDH channel.
パケットネットワークには、CEP関数がSONET/SDHチャネルに未装備の適応症を送信する条件がいくつかあります。
The first, which is transparent to CEP, is the receipt of regular CEP packets that happen to carry an SPE/VT containing the appropriate Path overhead or VT overhead set to Unequipped. This case does not require any special processing on the part of the CEP de-packetizer.
CEPに対して透明な最初のものは、適切なパスオーバーヘッドまたは未装備に設定されたVTオーバーヘッドを含むSPE/VTを搭載した通常のCEPパケットの受領です。このケースでは、CEP De-Packetizerの側で特別な処理は必要ありません。
The second case is the receipt of CEP packets with the Length field indicating that the payload was removed by DBA, while the L bit is set to 0, indicating that the DBA was triggered by an Unequipped indication and not by an AIS-P/V indication. The CEP de-packetizer MUST use this information to transmit a packet of all zeros onto the SONET/SDH interface.
2番目のケースは、ペイロードがDBAによって削除されたことを示す長さフィールドを持つCEPパケットの受領であり、Lビットは0に設定されていることを示しています。表示。CEP De-Packetizerは、この情報を使用して、すべてのゼロのパケットをSONET/SDHインターフェイスに送信する必要があります。
The third case when a CEP de-packetizer MUST play out an SPE/VT Unequipped indication towards the SONET/SDH interface is when the circuit has been de-provisioned.
CEP de-PacketizerがSONET/SDHインターフェイスに向けてSPE/VT未装備の適応症を再生しなければならない場合の3番目のケースは、回路が解除されたときです。
It is assumed that the distribution of SONET/SDH transport timing information is addressed either through external mechanisms such as Building Integrated Timing Supply (BITS), Stand Alone Synchronization Equipment (SASE), Global Positioning System (GPS), or other such methods, or is obtained through an adaptive timing recovery mechanism.
SONET/SDH輸送タイミング情報の分布は、統合タイミング供給の構築（BITS）、スタンドアロン同期機器（SASE）、グローバルポジショニングシステム（GPS）、またはその他の方法などの外部メカニズムを通じて対処されていると想定されています。適応タイミング回復メカニズムを通じて得られます。
Details about specific adaptive algorithms for recovery of SONET/SDH transport timing are not considered to be within scope for this document. The wander and jitter limits for networks based on the SDH hierarchy are defined in [G.825] and for the SONET hierarchy in [GR253]. The wander and jitter limits specified in these standards must be maintained when CEP PWs are used.
SONET/SDH輸送タイミングの回復のための特定の適応アルゴリズムの詳細は、このドキュメントの範囲内であるとは見なされません。SDH階層に基づくネットワークの放浪とジッターの制限は、[G.825]および[GR253]のソネット階層で定義されています。これらの標準で指定された放浪とジッターの制限は、CEP PWSを使用する場合に維持する必要があります。
A pointer management system is defined as part of the definition of SONET/SDH. Details on SONET/SDH pointer management can be found in [SONET], [GR253], [G.707], and [G.783]. If there is a frequency offset between the frame rate of the transport overhead and that of the SONET/SDH SPE, the alignment of the SPE will periodically slip back or advance in time through positive or negative stuffing. Similarly, if there is a frequency offset between the SPE rate and the VT rate it carries, the alignment of the VT will periodically slip back or advance in time through positive or negative stuffing within the SPE.
ポインター管理システムは、SONET/SDHの定義の一部として定義されます。SONET/SDHポインター管理の詳細は、[SONET]、[GR253]、[G.707]、および[G.783]にあります。輸送オーバーヘッドのフレームレートとSONET/SDH SPEのフレームレートの間に周波数オフセットがある場合、SPEのアライメントは、正または負の詰め物を通じて定期的に滑り込むか、時間内に前進します。同様に、SPEレートとそれが運ぶVTレートの間に周波数オフセットがある場合、VTのアラインメントは、SPE内の肯定的または負の詰め物を通じて定期的に滑り込むか、時間内に前進します。
The emulation of this aspect of SONET/SDH networks may be accomplished using a variety of techniques including Explicit Pointer Adjustment Relay (EPAR) and Adaptive Pointer Management (APM).
SONET/SDHネットワークのこの側面のエミュレーションは、明示的なポインター調整リレー（EPAR）や適応ポインター管理（APM）を含むさまざまな手法を使用して達成できます。
In any case, the handling of the SPE or VT data by the CEP packetizer is the same.
いずれにせよ、CEPパッケージ剤によるSPEまたはVTデータの取り扱いは同じです。
During a negative pointer adjustment event, the CEP packetizer MUST incorporate the H3 (or V3) byte from the SONET/SDH stream into the CEP packet payload in order with the rest of the SPE (or VT). During a positive pointer adjustment event, the CEP packetizer MUST strip the stuff byte from the CEP packet payload.
ネガティブポインター調整イベント中、CEPパケットは、SONET/SDHストリームのH3（またはV3）バイトを、SPE（またはVT）の残りの部分でCEPパケットペイロードに順番に組み込む必要があります。正のポインター調整イベント中に、CEPパケットはCEPパケットペイロードからバイトを剥がす必要があります。
When playing out a negative pointer adjustment event, the appropriate byte of the CEP payload MUST be placed into the H3 (or V3) byte of the SONET/SDH stream. When playing out a positive pointer adjustment, the CEP de-packetizer MUST insert a stuff byte into the appropriate position within the SONET/SDH stream.
負のポインター調整イベントを再生する場合、CEPペイロードの適切なバイトをSONET/SDHストリームのH3（またはV3）バイトに配置する必要があります。正のポインター調整を行うとき、CEP de-Packetizerは、SONET/SDHストリーム内の適切な位置に材料バイトを挿入する必要があります。
The details regarding the use of the H3 (and V3) byte and stuff byte during positive and negative pointer adjustments can be found in [SONET], [GR253], and [G.707].
[SONET]、[GR253]、および[G.707]には、正と負のポインター調整中のH3（およびV3）バイトおよびスタッフバイトの使用に関する詳細があります。
CEP provides an OPTIONAL mechanism to explicitly relay pointer adjustment events from one side of the PSN to the other. This technique is referred to as Explicit Pointer Adjustment Relay (EPAR). EPAR is only effective when both ends of the PW have access to a common timing reference.
CEPは、PSNの片側からもう一方の側にポインター調整イベントを明示的にリレーするオプションのメカニズムを提供します。この手法は、明示的なポインター調整リレー（EPAR）と呼ばれます。EPARは、PWの両端が一般的なタイミングリファレンスにアクセスできる場合にのみ効果的です。
The following text only applies to CEP implementations that choose to implement EPAR. Any CEP implementation that does not support EPAR MUST set the N and P bits to 0.
次のテキストは、EPARを実装することを選択したCEP実装にのみ適用されます。EPARをサポートしないCEP実装は、NおよびPビットを0に設定する必要があります。
The pointer adjustment event MUST be transmitted in three consecutive packets by the packetizer. The de-packetizer MUST play out the pointer adjustment event when any one packet with N/P bit set is received. The CEP de-packetizer MUST utilize the CEP sequence numbers to ensure that SONET/SDH pointer adjustment events are not played any more frequently than once per every three CEP packets transmitted by the remote CEP packetizer.
ポインター調整イベントは、パケットの3つの連続したパケットに送信する必要があります。de-packetizerは、n/pビットセットを備えた1つのパケットが受信された場合、ポインター調整イベントを再生する必要があります。CEP de-Packetizerは、CEPシーケンス番号を利用して、SONET/SDHポインター調整イベントが、リモートCEPパケット装置によって送信される3つのCEPパケットごとに1回以上プレイされないようにする必要があります。
The VT EPAR packetizer MUST relay pointer adjustment indications received at the SPE level in addition to relaying VT pointer adjustment indications. Because of the rate differences between VT and SPE, the magnitude of a VT pointer adjustment is much larger than that of an SPE adjustment. Therefore, the VT EPAR packetizer has to convert multiple SPE pointer adjustments to fewer VT pointer adjustment indications signaled over the PSN using the N and P CEP header bits. A simple algorithm can be used for this purpose using an accumulator (counter):
VT EPARパケットは、VTポインター調整指示を中継することに加えて、SPEレベルで受け取ったポインター調整指示を中継する必要があります。VTとSPEのレートの違いのため、VTポインター調整の大きさはSPE調整の大きさよりもはるかに大きいです。したがって、VT EPARパケットは、複数のSPEポインター調整をNおよびP CEPヘッダービットを使用してPSNを介してシグナルを通知するVTポインター調整適応度を減らす必要があります。アキュムレータ（カウンター）を使用して、この目的には簡単なアルゴリズムを使用できます。
The accumulator value is reset to 0 when the circuit is in Loss of Packet Synchronization (LOPS) state.
回路がパケット同期（LOPS）状態を失っている場合、アキュムレータ値は0にリセットされます。
A positive pointer adjustment indication increases the accumulator value by a fixed quota, while negative pointer adjustment subtracts the same quota from the accumulator. A VT pointer adjustment changes the accumulator value by 783 units (one STS-1 SPE size). An SPE pointer adjustment changes the accumulator value by quota that depends on the VT emulation type. The quota is 1/4 of the VT size as defined in Table 1, e.g., 26 bytes for VT1.5 emulation and 35 bytes for VT2 emulation.
正のポインター調整指標は、固定クォータによってアキュムレータ値を増加させますが、負のポインター調整はアキュムレータから同じクォータを減算します。VTポインター調整により、アキュムレータ値が783ユニット（1つのSTS-1 SPEサイズ）を変更します。SPEポインター調整により、VTエミュレーションタイプに依存する割り当てによってアキュムレータ値が変更されます。クォータは、表1で定義されているVTサイズの1/4で、たとえばVT1.5エミュレーションで26バイト、VT2エミュレーションで35バイトです。
When the accumulator value is larger than or equal to 783 units, a positive pointer adjustment is signaled towards the PSN using the CEP header P bit and 783 units are subtracted from the accumulator.
アキュムレータ値が783ユニット以下の場合、CEPヘッダーPビットを使用してPSNに対して正のポインター調整が示され、アキュムレータから783ユニットが差し引かれます。
When the accumulator value is smaller than or equal to minus 783 units, a negative pointer adjustment is signaled towards the PSN using the CEP header N bit and 783 units are added to the accumulator.
アキュムレータ値がマイナス783ユニット以下の場合、CEPヘッダーNビットを使用してPSNに負のポインター調整が通知され、783ユニットがアキュムレータに追加されます。
The same algorithm is applicable for SDH Virtual Container carried in VC-4, i.e., positive VC-4 pointer adjustment adds 35 units to a VC-12 accumulator, while positive VC-12 pointer adjustment adds 783 units to the accumulator.
同じアルゴリズムは、VC-4で運ばれるSDH仮想コンテナに適用できます。つまり、VC-4ポインター調整が正のVC-12アキュムレータに35ユニットを追加しますが、正のVC-12ポインター調整により783ユニットがアキュムレータに追加されます。
If both N and P bits are set, then a Loss of Pointer event has been detected at the PW ingress, making the pointer invalid. The de-packetizer MUST play out an AIS-P/V indication and SHOULD set the pointer value to all-ones value.
NとPビットの両方が設定されている場合、PW侵入でポインターイベントの損失が検出され、ポインターが無効になります。パケット装置はAIS-P/Vの表示を再生する必要があり、ポインター値をすべての値に設定する必要があります。
Another OPTIONAL method that may be used to emulate SONET/SDH pointer management is Adaptive Pointer Management (APM). In basic terms, APM uses information about the depth of the CEP jitter buffers to introduce pointer adjustments in the reassembled SONET/SDH SPE.
SONET/SDHポインター管理をエミュレートするために使用できるもう1つのオプションの方法は、適応ポインター管理（APM）です。基本的に、APMはCEPジッターバッファーの深さに関する情報を使用して、再組み立てされたSONET/SDH SPEにポインター調整を導入します。
Details about specific APM algorithms are not considered to be within scope for this document.
特定のAPMアルゴリズムの詳細は、このドキュメントの範囲内であるとは見なされません。
SONET/SDH as defined in [SONET], [GR253], [G.707], and [G.784] includes a definition of several counters used to monitor the performance of SONET/SDH services. These counters are referred to as Performance Monitors.
[SONET]、[GR253]、[G.707]、および[G.784]で定義されているSONET/SDHには、SONET/SDHサービスのパフォーマンスを監視するために使用されるいくつかのカウンターの定義が含まれています。これらのカウンターは、パフォーマンスモニターと呼ばれます。
In order for CEP to be utilized by traditional SONET/SDH network operators, CEP SHOULD provide similar functionality. The following sections describe a number of counters that are collectively referred to as CEP Performance Monitors.
CEPを従来のSONET/SDHネットワークオペレーターによって利用するためには、CEPは同様の機能を提供する必要があります。次のセクションでは、CEPパフォーマンスモニターと総称される多くのカウンターについて説明します。
These performance monitors are maintained by the CEP de-packetizer during reassembly of the SONET/SDH stream.
これらのパフォーマンスモニターは、SONET/SDHストリームの再組み立て時にCEP de-Packetizerによって維持されます。
The performance monitors are based on two types of defects.
パフォーマンスモニターは、2種類の欠陥に基づいています。
Type 1: missing or dropped packet.
タイプ1：パケットの欠落またはドロップ。
Type 2: buffer underrun, buffer overrun, LOPS, missing packets above predefined configurable threshold.
タイプ2：バッファアンダーラン、バッファオーバーラン、ロップ、事前定義された構成可能なしきい値の上にあるパケットがありません。
The specific performance monitors defined for CEP are as follows:
CEPに対して定義された特定のパフォーマンスモニターは次のとおりです。
ES-CEP - CEP Errored Seconds SES-CEP - CEP Severely Errored Seconds UAS-CEP - CEP Unavailable Seconds
ES -CEP -CEPエラー秒SES -CEP -CEP重度のエラー秒UAS -CEP -CEPが利用できない秒
Each second that contains at least one type 1 defect SHALL be declared as ES-CEP. Each second that contains at least one type 2 defect SHALL be declared as SES-CEP.
少なくとも1つのタイプ1の欠陥を含む各秒は、ES-CEPとして宣言されるものとします。少なくとも1つのタイプ2の欠陥を含む各秒は、SES-CEPとして宣言されます。
UAS-CEP SHALL be declared after configurable number of consecutive SES-CEP, and cleared after a configurable number of consecutive seconds without SES-CEP. Default value for each is 10 seconds.
UAS-CEPは、構成可能な数の連続SES-CEPの後に宣言され、SES-CEPなしで構成可能な数の連続秒の後にクリアされるものとします。それぞれのデフォルト値は10秒です。
Once unavailability is declared, ES and SES counts SHALL be inhibited up to the point where the unavailability was started. Once unavailability is removed, ES and SES that occurred along the clearing period SHALL be added to the ES and SES counts.
利用不能が宣言されると、ESとSESカウントは、利用不能が開始された時点まで抑制されます。利用不能が削除されると、クリアリング期間に沿って発生したESとSESをESおよびSESカウントに追加するものとします。
CEP-NE failure is declared after 2.5 +/- 0.5 seconds of CEP-NE type 2 defect, and cleared after 10 seconds free of CEP-NE defect state. Sending notification to the OS for CEP-NE failure is local policy.
CEP-NE障害は、2.5 /-0.5秒のCEP-NEタイプ2の欠陥の後に宣言され、CEP-NE欠陥状態が10秒自由にクリアされます。CEP-NE障害のためにOSに通知を送信することは、ローカルポリシーです。
Far-end performance monitors provide insight into the CEP de-packetizer at the far end of the PSN.
ファーエンドのパフォーマンスモニターは、PSNの遠端でのCEP de-packetizerへの洞察を提供します。
Far-end statistics are based on the CEP-RDI indication carried in the CEP header R bit. CEP-FE defect is declared when CEP-RDI is set in the incoming CEP packets.
ファーエンド統計は、CEPヘッダーRビットで運ばれるCEP-RDI表示に基づいています。CEP-FE欠陥は、CEP-RDIが着信CEPパケットに設定されたときに宣言されます。
CEP-FE failure is declared after 2.5 +/- 0.5 seconds of CEP-FE defect, and cleared after 10 seconds free of CEP-FE defect state. Sending notification to the OS for CEP-FE failure is local policy.
CEP-FE障害は、2.5 /-0.5秒のCEP-FE欠陥の後に宣言され、CEP-FE欠陥状態がない10秒後にクリアされます。CEP-FE障害のためにOSに通知を送信することはローカルポリシーです。
In addition to pure emulation, CEP also offers a number of options for reducing the total bandwidth utilized by the emulated circuit. These options fall into two categories: Dynamic Bandwidth Allocation (DBA) and Service-Specific Payload Formats.
純粋なエミュレーションに加えて、CEPは、エミュレートされた回路で使用される帯域幅の総幅を減らすための多くのオプションも提供しています。これらのオプションは、動的帯域幅割り当て（DBA）とサービス固有のペイロード形式の2つのカテゴリに分類されます。
DBA suppresses transmission of the CEP payload altogether under certain circumstances such as AIS-P/V and SPE/VT Unequipped. The use of DBA is dependent on network architectures, e.g., support of Tandem Connection Monitoring, test signals (TEST-P) [SONET], or Supervisory Unequipped [G.806] signals.
DBAは、AIS-P/VやSPE/VTの装備などの特定の状況下で、CEPペイロードの伝達を完全に抑制します。DBAの使用は、タンデム接続モニタリングのサポート、テスト信号（TEST-P）[SONET]、または装備されていない[G.806]シグナルなど、ネットワークアーキテクチャ、たとえばネットワークアーキテクチャに依存します。
Service-Specific Payload Formats reduce bandwidth by suppressing transmission of portions of the SPE based on specific knowledge of the SPE payload.
SPEペイロードの特定の知識に基づいて、SPEの一部の送信を抑制することにより、サービス固有のペイロードフォーマットが帯域幅を減らします。
Details on these payload compression options are described in the following subsections.
これらのペイロード圧縮オプションの詳細は、次のサブセクションで説明されています。
Dynamic Bandwidth Allocation (DBA) is an OPTIONAL mechanism for suppressing the transmission of the SPE (or VT) fragment when one of two trigger conditions are met, AIS-P/V or SPE/VT Unequipped.
動的帯域幅割り当て（DBA）は、2つのトリガー条件のいずれかがAIS-P/VまたはSPE/VTを装備している場合、SPE（またはVT）フラグメントの透過を抑制するためのオプションのメカニズムです。
Implementations that support DBA MUST include a mechanism for disabling DBA on a channel-by-channel basis to allow for interoperability with implementations that do not support DBA.
DBAをサポートする実装には、DBAをサポートしていない実装との相互運用性を可能にするために、チャンネルごとのチャンネルベースでDBAを無効にするメカニズムを含める必要があります。
When a DBA trigger is recognized at PW ingress, the CEP payload will be suppressed. The CEP Length field MUST be set to the CEP header length plus the RTP header length if used, and padding bytes SHOULD be added if the intervening packet network has a minimum packet size that is larger than the payload-suppressed DBA packet.
PW IngressでDBAトリガーが認識されると、CEPペイロードが抑制されます。CEPの長さフィールドは、使用する場合はCEPヘッダー長に加えてRTPヘッダー長に設定する必要があります。また、介在するパケットネットワークにペイロード抑制DBAパケットよりも大きい最小パケットサイズがある場合は、パディングバイトを追加する必要があります。
Other than the suppression of the CEP payload, the CEP behavior during DBA should be equivalent to normal CEP behavior. In particular, the packet transmission rate during DBA should be equivalent to the normal packet transmission rate.
CEPペイロードの抑制以外に、DBA中のCEP挙動は通常のCEP挙動に相当する必要があります。特に、DBA中のパケット送信速度は、通常のパケット伝送速度に相当する必要があります。
In addition to the standard payload encapsulations for SPE and VT transport, several OPTIONAL payload formats have been defined to provide varying amounts of payload compression depending on the type and amount of user traffic present within the SPE. These are described below.
SPEおよびVTトランスポートの標準ペイロードカプセルに加えて、SPE内に存在するユーザートラフィックの種類と量に応じて、さまざまな量のペイロード圧縮を提供するために、いくつかのオプションのペイロード形式が定義されています。これらを以下に説明します。
Fractional STS-1 (VC-3) encapsulation carries only a selected set of VTs within an STS-1 container. This mode is applicable for STS-1 with POH signal label byte C2=2 (VT-structured SPE) and for C2=3 (Locked VT mode).
分数STS-1（VC-3）カプセル化は、STS-1コンテナ内の選択したVTSのセットのみを保持します。このモードは、POH信号ラベルバイトC2 = 2（VT構造SPE）を備えたSTS-1およびC2 = 3（ロックされたVTモード）に適用できます。
Implementations of fractional STS-1 (VC-3) encapsulation MUST support payload length of one SPE and MAY support payload length of 1/3 SPE.
分数STS-1（VC-3）カプセル化の実装は、1つのSPEのペイロード長さをサポートする必要があり、1/3 SPEのペイロード長さをサポートする場合があります。
The mapping of VTs into an STS-1 container is described in Section 3.2.4 of [GR253], and the mapping into VC-3 is defined in Section 7.2.4 in [G.707]. The CEP packetizer removes all fixed column bytes (columns 30 and 59) and all bytes belonging to the removed VTs. Only STS-1 POH bytes and bytes that belong to the selected VTs are carried within the payload. The CEP de-packetizer adds the fixed stuff bytes and generates unequipped VT data replacing the removed VT bytes.
STS-1容器へのVTSのマッピングは[GR253]のセクション3.2.4で説明されており、VC-3へのマッピングは[G.707]のセクション7.2.4で定義されています。CEPパケットは、固定されたすべての列バイト（列30および59）と除去されたVTSに属するすべてのバイトを削除します。選択したVTSに属するSTS-1 POHバイトとバイトのみがペイロード内で運ばれます。CEP de-Packetizerは、固定されたスタッフバイトを追加し、削除されたVTバイトを置き換える装備のないVTデータを生成します。
The figure below illustrates VT1.5 mapping into an STS-1 SPE.
以下の図は、STS-1 SPEへのVT1.5マッピングを示しています。
1 2 3 * * * 29 30 31 32 * * * 58 59 60 61 * * * 87
+--+------------------+-+------------------+-+------------------+
1 |J1| Byte 1 (V1-V4) |R| | | | |R| | | | |
+--+---+---+------+---+-+------------------+-+------------------+
2 |B3|VT | | | |R| | | | |R| | | | |
+--+1.5| | | +-+---+---+------+---+-+------------------+
3 |C2| | | | |R| | | | |R| | | | |
+--+ | | | +-+---+---+------+---+-+------------------+
4 |G1| | | | |R| | | | |R| | | | |
+--+ | | | +-+---+---+------+---+-+------------------+
5 |F2| | | | |R| | | | |R| | | | |
+--|1-1|2-1| * * *|7-4|-|1-1|2-1| * * *|7-4|-|1-1|2-1| * * *|7-4|
6 |H4| | | | |R| | | | |R| | | | |
+--+ | | | +-+---+---+------+---+-+------------------+
7 |Z3| | | | |R| | | | |R| | | | |
+--+ | | | +-+---+---+------+---+-+------------------+
8 |Z4| | | | |R| | | | |R| | | | |
+--+ | | | +-+---+---+------+---+-+------------------+
9 |Z5| | | | |R| | | | |R| | | | |
+--+---+---+------+---+-+---+---+------+---+-+------------------+
| | |
+-- Path Overhead +--------------------+-- Fixed Stuffs
Figure 5: SONET SPE Mapping of VT1.5
図5：VT1.5のSONET SPEマッピング
The SPE always contains seven interleaved VT groups (VTGs). Each VTG contains a single type of VT, and each VTG occupies 12 columns (108 bytes) within each SPE. A VTG can contain 4 VT1.5s (T1s), 3 VT2s (E1s), 2 VT3s, or a single VT6. Altogether, the SPE can carry 28 T1s or carry 21 E1s.
SPEには、常に7つのインターリーブVTグループ（VTG）が含まれています。各VTGには単一のタイプのVTが含まれており、各VTGは各SPE内で12列（108バイト）を占有します。VTGには、4つのVT1.5S（T1S）、3つのVT2（E1S）、2つのVT3、または単一のVT6を含めることができます。全体として、SPEは28のT1を運ぶか、21のE1を運ぶことができます。
The fractional STS-1 encapsulation can optionally carry a bit mask that specifies which VTs are carried within the STS-1 payload and which VTs have been removed. This optional bit mask attribute allows the ingress circuit emulation node to remove an unequipped VT on the fly, providing the egress circuit emulation node enough information for reconstructing the VTs in the right order. The use of bit mask enables on-the-fly compression, whereby only equipped VTs (carrying actual data) are sent.
分数STS-1カプセル化は、STS-1ペイロード内でどのVTが運ばれ、どのVTが除去されているかを指定するビットマスクをオプションで運ぶことができます。このオプションのビットマスク属性により、Ingress回路エミュレーションノードは、装備されていないVTをその場で削除できるようになり、出力回路エミュレーションノードに適切な順序でVTを再構築するのに十分な情報を提供します。ビットマスクを使用すると、オンザフライ圧縮が可能になり、装備されたVTのみ（実際のデータを運ぶ）が送信されます。
The fractional STS-1 CEP header uses the STS-1 CEP header encapsulation as defined in this document. Optionally, an additional 4-byte header extension word is added.
分数STS-1 CEPヘッダーは、このドキュメントで定義されているSTS-1 CEPヘッダーカプセル化を使用します。オプションで、追加の4バイトヘッダー拡張ワードが追加されています。
The extended header has the following format:
拡張ヘッダーには次の形式があります。
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|N|P|FRG|Length[0:5]| Sequence Number[0:15] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |Structure Pointer[0:11]|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|0|0| Equipped Bit Mask (EBM) [0:27] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Extended Fractional STS-1 Header
図6：拡張された分数STS-1ヘッダー
The L, R, N, P, FRG, Length, Sequence Number, and Structured Pointer fields are used as defined in this document for STS-1 encapsulation.
L、R、N、P、FRG、長さ、シーケンス番号、および構造化されたポインターフィールドは、STS-1カプセル化のこのドキュメントで定義されているように使用されます。
Each bit within the Equipped Bit Mask (EBM) field refers to a different VT within the STS-1 container. A bit set to 1 indicates that the corresponding VT is equipped, hence carried within the fractional STS-1 payload.
装備されたビットマスク（EBM）フィールド内の各ビットは、STS-1コンテナ内の異なるVTを指します。1に少し設定されていると、対応するVTが装備されているため、分数STS-1ペイロード内に搭載されていることを示します。
The STS-1 EBM has the following format:
STS-1 EBMには次の形式があります。
0 1 2
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VTG7 | VTG6 | VTG5 | VTG4 | VTG3 | VTG2 | VTG1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Equipped Bit Mask (EBM) for Fractional STS-1
図7：分数STS-1用の装備ビットマスク（EBM）
The 28 bits of the EBM are divided into groups of 4 bits, each corresponding to a different VTG within the STS container. All 4 bits are used to indicate whether VT1.5 (T1) tributaries are carried within a VTG. The first 3 bits read from right to left are used to indicate whether VT2 (E1) tributaries are carried within a VTG. The first 2 bits are used to indicate whether VT3 (DS1C) tributaries are carried within a VTG. The rightmost bit is used to indicate whether a VT6 (DS2) is carried within the VTG. The VTs within the VTG are numbered from right to left, starting from the first VT as the first bit on the right. For example, the EBM of a fully occupied STS-1 with VT1.5 tributaries is all ones, while that of an STS-1 fully occupied with VT2 (E1) tributaries has the binary value 0111011101110111011101110111.
EBMの28ビットは、STSコンテナ内の異なるVTGに対応する4ビットのグループに分割されます。4ビットはすべて、VT1.5（T1）支流がVTG内で運ばれるかどうかを示すために使用されます。右から左に読み取られた最初の3ビットは、VT2（E1）支流がVTG内で運ばれるかどうかを示すために使用されます。最初の2ビットは、VT3（DS1C）支流がVTG内で運ばれるかどうかを示すために使用されます。右端のビットは、VTG（DS2）がVTG内で運ばれるかどうかを示すために使用されます。VTG内のVTSには、右から左から左に番号が付けられています。最初のVTから右側の最初のビットとして開始されます。たとえば、VT1.5支流を備えた完全に占有されたSTS-1のEBMはすべてですが、VT2（E1）支流で完全に占有されているSTS-1のEBMには、バイナリ値011101110111011101110111011111があります。
Fractional STS-1 encapsulation can be implemented in Line Terminating Equipment (LTE) or in Path Terminating Equipment (PTE). PTE implementations terminate the path layer at the ingress PE and generate a new path layer at the egress PE.
分数STS-1カプセル化は、ライン終了機器（LTE）またはパス終端機器（PTE）で実装できます。PTEの実装は、Ingress PEのパス層を終了し、出口PEで新しいパスレイヤーを生成します。
LTE implementations do not terminate the path layer, and therefore need to keep the content and integrity of the POH bytes across the PSN. In LTE implementations, special care must be taken to maintain the B3 bit-wise parity POH byte. The B3 compensation algorithm is defined below.
LTEの実装はパス層を終了するわけではないため、PSN全体のPOHバイトのコンテンツと整合性を維持する必要があります。LTEの実装では、B3ビットワイズパリティPOHバイトを維持するために特別な注意を払う必要があります。B3補償アルゴリズムを以下に定義します。
Since the BIP-8 value in a given frame reflects the parity check over the previous frame, the changes made to BIP-8 bits in the previous frame shall also be considered in the compensation of BIP-8 in the current frame. Therefore, the following equation shall be used for compensation of the individual bits of the BIP-8:
特定のフレームのBIP-8値は前のフレームのパリティチェックを反映しているため、前のフレームのBIP-8ビットに加えられた変更は、現在のフレームのBIP-8の補償でも考慮されます。したがって、BIP-8の個々のビットの補償には、次の方程式を使用するものとします。
B3[i]'(t) = B3[i](t-1) || B3[i]'(t-1) || B3[i](t) || B*3[i](t-1)
Where:
ただし：
B3[i] = the existing B3[i] value in the incoming signal B3[i]' = the new (compensated) B3[i] value B3*[i] = the B3[i] value of the unequipped VTs in the incoming signal || = exclusive OR operator t = the time of the current frame t-1 = the time of the previous frame
b3 [i] =着信信号の既存のb3 [i]値b3 [i] '= new（補償）b3 [i] value b3*[i] = b3 [i] b3 [i] falue in fidipted vts in in着信信号||=排他的または演算子t =現在のフレームの時間t-1 =前のフレームの時間
The egress PE MUST reconstruct the unequipped VTs and modify the B3 parity value in the same manner to accommodate the additional VTs added. In this way, the end-to-end BIP is preserved.
出力PEは、装備されていないVTSを再構築し、追加のVTSに対応するために同じ方法でB3パリティ値を変更する必要があります。このようにして、エンドツーエンドのBIPが保持されます。
The actual CEP payload size depends on the number of virtual tributaries carried within the fractional SPE. The contributions of each tributary to the fractional STS-1 payload size as well as the path overhead contribution are described below.
実際のCEPペイロードサイズは、分数SPE内で運ばれる仮想支流の数に依存します。小数のSTS-1ペイロードサイズへの各支流とパスオーバーヘッドの寄与については、以下に説明します。
Each VT1.5 contributes 27 bytes Each VT2 contributes 36 bytes
各VT1.5は27バイトを寄付します各VT2は36バイトに寄与します
Each VT3 contributes 54 bytes
各VT3は54バイトに寄与します
Each VT6 contributes 108 bytes
各VT6は108バイトに寄与します
STS-1 POH contributes 9 bytes
STS-1 POHは9バイトを提供します
For example, a fractional STS-1 carrying 7 VT2 circuit in full-SPE encapsulation would have an actual size of 261=36*7+9 bytes. Divide by 3 to calculate the third-SPE encapsulation actual payload sizes.
たとえば、フルSPEカプセル化で7つのVT2回路を運ぶ分数STS-1は、実際のサイズは261 = 36*7 9バイトです。3で除算して、3番目のSPEカプセル化の実際のペイロードサイズを計算します。
Asynchronous T3/E3 STS-1 (VC-3) encapsulation is applicable for signals with POH signal label byte C2=4, carrying asynchronously mapped T3 or E3 signals.
非同期T3/E3 STS-1（VC-3）カプセル化は、非同期マッピングT3またはE3シグナルを運ぶPOH信号ラベルBYTE C2 = 4の信号に適用できます。
Implementations of asynchronous T3/E3 STS-1 (VC-3) encapsulation MUST support payload length of one SPE and MAY support payload length of 1/3 SPE.
非同期T3/E3 STS-1（VC-3）の実装カプセル化は、1つのSPEのペイロード長さをサポートする必要があり、1/3 SPEのペイロード長さをサポートする場合があります。
A T3 is encapsulated asynchronously into an STS-1 SPE using the format defined in Section 3.4.2.1 of [GR253]. The STS-1 SPE is then encapsulated as defined in this document.
T3は、[GR253]のセクション3.4.2.1で定義されている形式を使用して、STS-1 SPEに非同期にカプセル化されます。STS-1 SPEは、このドキュメントで定義されているようにカプセル化されます。
Optionally, the STS-1 SPE can be compressed by removing the fixed columns leaving only data columns. STS-1 columns are numbered 1 to 87, starting from the POH column numbered 1. The following columns have fixed values and are removed: 2, 3, 30, 31, 59, and 60.
オプションで、STS-1 SPEは、固定列を削除してデータ列のみを削除することで圧縮できます。STS-1列には、1から87の番号が付けられており、1からのPOH列から始まります。次の列には固定値があり、2、3、30、31、59、および60が削除されます。
Bandwidth saving is approximately 7% (6 columns out of 87). The B3 parity byte need not be modified as the parity of the fixed columns amounts to 0. The actual payload size for full-SPE encapsulation would be 729 bytes and 243 bytes for third-SPE encapsulation.
帯域幅の保存は約7％です（87のうち6列）。固定列のパリティが0になるため、B3パリティバイトを変更する必要はありません。フルSPEカプセル化の実際のペイロードサイズは、サードスペースカプセル化の場合は729バイト、243バイトです。
A T3 is encapsulated asynchronously into a VC-3 container as described in Section 10.1.2.1 of [G.707]. VC-3 container has only 85 data columns, which is identical to the STS-1 container with the two fixed stuff columns 30 and 59 removed. Other than that, the mapping is identical.
T3は、[G.707]のセクション10.1.2.1で説明されているように、非同期にVC-3容器にカプセル化されます。VC-3コンテナには85個のデータ列しかありません。これは、STS-1コンテナと同一の列と同じです。それ以外は、マッピングは同一です。
An E3 is encapsulated asynchronously into a VC-3 SPE using the format defined in Section 10.1.2.2 of [G.707]. The VC-3 SPE is then encapsulated as defined in this document.
E3は、[G.707]のセクション10.1.2.2で定義されている形式を使用して、VC-3 SPEに非同期にカプセル化されます。VC-3 SPEは、このドキュメントで定義されているようにカプセル化されます。
Optionally, the VC-3 SPE can be compressed by removing the fixed columns leaving only data columns. VC-3 columns are numbered 1 to 85 (and not 87), starting from the POH column numbered 1. The following columns have fixed values and are removed: 2, 6, 10, 14, 18, 19, 23, 27, 31, 35, 39, 44, 48, 52, 56, 60, 61, 65, 69, 73, 77, and 81.
オプションで、VC-3 SPEは、固定列を削除してデータ列のみを削除することで圧縮できます。VC-3列には、番号が付けられたPOH列から始まる1から85（87ではなく）に番号が付けられています。次の列には固定値があり、削除されます：2、6、10、14、18、19、23、27、31、35、39、44、48、52、56、60、61、65、69、73、77、および81。
Bandwidth saving is approximately 28% (24 columns out of 85). The B3 parity byte need not be modified as the parity of the fixed columns amounts to 0. The actual payload size for full-SPE encapsulation would be 567 bytes and 189 bytes for third-SPE encapsulation.
帯域幅の保存は約28％です（85のうち24列）。固定列のパリティが0になるため、B3パリティバイトを変更する必要はありません。フルSPEカプセル化の実際のペイロードサイズは567バイト、サードスペースカプセル化の場合は189バイトです。
SDH defines a mapping of VC-11, VC-12, VC-2, and VC-3 directly into VC-4. This mapping does not have an equivalent within the SONET hierarchy. The VC-4 mapping is common in SDH implementations.
SDHは、VC-11、VC-12、VC-2、およびVC-3のマッピングをVC-4に直接定義します。このマッピングには、SONET階層内に相当するものはありません。VC-4マッピングは、SDHの実装で一般的です。
VC-4 <--x3-- TUG-3 <--------x1-------- TU-3 <-- VC-3 <---- E3/T3
|
+--x7-- TUG-2 <--x1-- TU-2 <-- VC-2 <---- DS2
|
+----x3---- TU-12 <-- VC-12<---- E1
|
+----x4---- TU-11 <-- VC-11<---- T1
Figure 8: Mapping of VCs into VC-4
図8：VC-4へのVCのマッピング
Figure 8 describes the mapping options of VCs into VC-4. A VC-4 contains three TUG-3s. Each TUG-3 is composed of either a single TU-3 or 7 TUG-2s. A TU-3 contains a single VC-3. A TUG-2 contains either 4 VC-11s (T1s), 3 VC-12s (E1s), or one VC-2. Therefore, a VC-4 may contain 3 VC-3s, 1 VC-3 and 42 VC-12s, 63 VC-12s, etc.
図8は、VCのマッピングオプションをVC-4に示しています。VC-4には3つのTUG-3が含まれています。各TUG-3は、単一のTU-3または7 TUG-2で構成されています。TU-3には、単一のVC-3が含まれています。TUG-2には、4つのVC-11（T1S）、3つのVC-12（E1S）、または1つのVC-2が含まれています。したがって、VC-4には、3つのVC-3、1つのVC-3および42 VC-12、63 VC-12などが含まれている場合があります。
Fractional VC-4 encapsulation carries only a selected set of VCs within a VC-4 container. This mode is applicable for VC-4 with POH signal label byte C2=2 (TUG structure) and for C2=3 (Locked TU-n). The mapping of VCs into a VC-4 container is described in Section 7.2 of [G.707]. The CEP packetizer removes all fixed column bytes and all bytes that belong to the removed VCs. Only VC-4 POH bytes and bytes that belong to the selected VCs are carried within the payload. The CEP de-packetizer adds the fixed stuff bytes and generates unequipped VC data replacing the removed VC bytes.
分数VC-4カプセル化は、VC-4コンテナ内の選択したVCのみのセットのみを保有します。このモードは、POH信号ラベルBYTE C2 = 2（タグ構造）を備えたVC-4およびC2 = 3（ロックされたTU-N）に適用されます。VCSのVC-4容器へのマッピングは、[G.707]のセクション7.2で説明されています。CEPパケットは、固定されたすべての列バイトと除去されたVCに属するすべてのバイトを削除します。選択したVCに属するVC-4 POHバイトとバイトのみがペイロード内で運ばれます。CEP de-Packetizerは、固定されたスタッフバイトを追加し、削除されたVCバイトを置き換える未装備のVCデータを生成します。
The fractional VC-4 encapsulation can optionally carry a bit mask that specifies which VCs are carried within the VC-4 payload and which VCs have been removed. This optional bit mask attribute allows the ingress circuit emulation node to remove unequipped VCs on the fly, providing the egress circuit emulation node enough information for reconstructing the VCs in the right order. The use of bit mask enables on-the-fly compression, whereby only equipped VCs (carrying actual data) are sent.
分数VC-4カプセル化は、VC-4ペイロード内でどのVCが運ばれ、どのVCが除去されているかを指定するビットマスクをオプションで運ぶことができます。このオプションのビットマスク属性により、Ingress回路エミュレーションノードは、装備されていないVCSをその場で削除できます。つまり、VCSを適切な順序で再構築するためのEgress回路エミュレーションノードに十分な情報を提供できます。ビットマスクを使用すると、オンザフライ圧縮が可能になり、装備されたVCのみ（実際のデータを運ぶ）が送信されます。
VC-3 carrying asynchronous T3/E3 signals within the VC-4 container can optionally be compressed by removing the fixed column bytes as described in Section 11.2.2, providing additional bandwidth saving.
VC-4コンテナ内の非同期T3/E3信号を運ぶVC-3セクション11.2.2で説明されているように固定列バイトを削除して、追加の帯域幅を節約することにより、オプションで圧縮できます。
Implementations of fractional VC-4 encapsulation MUST support payload length of 1/3 SPE and MAY support payload lengths of 4/9, 5/9, 6/9, 7/9, 8/9, and full SPE. The actual payload size of fractional VC-4 encapsulation depends on the number of VCs carried within the payload.
分数VC-4カプセル化の実装は、1/3 SPEのペイロード長をサポートする必要があり、4/9、5/9、6/9、7/9、8/9のペイロード長さをサポートする場合があります。分数VC-4カプセル化の実際のペイロードサイズは、ペイロード内で運ばれるVCの数に依存します。
[G.707] defines the mapping of TUG-3 to a VC-4 in Section 7.2.1. Each TUG-3 includes 86 columns. TUG-3#1, TUG-3#2, and TUG-3#3 are byte multiplexed, starting from column 4. Column 1 is the VC-4 POH, while columns 2 and 3 are fixed and therefore removed in the fractional VC-4 encapsulation.
[G.707]は、セクション7.2.1でTUG-3のVC-4へのマッピングを定義しています。各TUG-3には86列が含まれています。TUG-3＃1、TUG-3＃2、およびTUG-3＃3はバイトが多重化されており、列1から1列1がVC-4 POHで、列2と3は固定されているため、分数VCで除去されます。-4カプセル化。
The mapping of TU-3 into TUG-3 is defined in Section 7.2.2 of [G.707]. The TU-3 consists of the VC-3 with a 9-byte VC-3 POH and the TU-3 pointer. The first column of the 9-row-by-86-column TUG-3 is allocated to the TU-3 pointer (bytes H1, H2, H3) and fixed stuff. The phase of the VC-3 with respect to the TUG-3 is indicated by the TU-3 pointer.
TU-3のTUG-3へのマッピングは、[G.707]のセクション7.2.2で定義されています。TU-3は、9バイトのVC-3 POHとTU-3ポインターを備えたVC-3で構成されています。9列ごとの86列のTUG-3の最初の列は、TU-3ポインター（バイトH1、H2、H3）および固定されたものに割り当てられます。TUG-3に対するVC-3の位相は、TU-3ポインターで示されています。
The mapping of TUG-2 into TUG-3 is defined in Section 7.2.3 of [G.707]. The first two columns of the TUG-3 are fixed and therefore removed in the fractional VC-4 encapsulation. The 7 TUG-2s, each 12 columns wide, are byte multiplexed starting from column 3 of the TUG-3. This is the equivalent of multiplexing 7 VTGs within STS-1 container in SONET terminology, except for the location of the fixed columns.
TUG-2のTUG-3へのマッピングは、[G.707]のセクション7.2.3で定義されています。TUG-3の最初の2つの列が固定されているため、分数VC-4カプセル化で削除されます。幅12列、それぞれ12列の7つのTUG-2は、TUG-3の列3からバイトが多重化されています。これは、固定列の位置を除き、SONET用語のSTS-1コンテナ内のマルチプレックス7 VTGに相当します。
The static fractional VC-4 mapping assumes that both the ingress and egress nodes are preconfigured with the set of equipped VCs carried within the fractional VC-4 encapsulation. The ingress emulation edge removes the fixed columns as well as columns of the VCs agreed upon by the two edges, and updates the B3 VC-4 byte. The egress side adds the fixed columns and the unequipped VCs and updates B3.
静的分数VC-4マッピングは、侵入ノードと出口ノードの両方が、分数VC-4カプセル化内で運ばれる装備されたVCのセットで事前に設定されていることを前提としています。Ingress Emulation Edgeは、2つのエッジによって合意されたVCの固定列と列を削除し、B3 VC-4バイトを更新します。出口側は、固定列と未装備のVCと更新B3を追加します。
The fractional VC-4 CEP header uses the VC-4 CEP header defined in this document. Optionally, an additional 12-byte header extension word is added.
分数VC-4 CEPヘッダーは、このドキュメントで定義されているVC-4 CEPヘッダーを使用します。オプションで、追加の12バイトヘッダー拡張ワードが追加されています。
The extended header has the following format:
拡張ヘッダーには次の形式があります。
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|N|P|FRG|Length[0:5]| Sequence Number[0:15] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |Structure Pointer[0:11]|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Equipped Bit Mask #1 (EBM) [0:29] TUG-3#1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Equipped Bit Mask #2 (EBM) [0:29] TUG-3#2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Equipped Bit Mask #3 (EBM) [0:29] TUG-3#3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Extended Fractional VC-4 Header
図9：拡張された分数VC-4ヘッダー
The L, R, N, P, FRG, Length, Sequence Number, and Structured Pointer fields are used as defined in this document for STS-1 encapsulation.
L、R、N、P、FRG、長さ、シーケンス番号、および構造化されたポインターフィールドは、STS-1カプセル化のこのドキュメントで定義されているように使用されます。
Each bit within the Equipped Bit Mask (EBM) field refers to a different tributary within the VC-4 container. A bit set to 1 indicates that the corresponding tributary is equipped, hence carried within the fractional VC-4 payload.
装備されたビットマスク（EBM）フィールド内の各ビットは、VC-4コンテナ内の異なる支流を指します。1に少し設定されていると、対応する支流が装備されているため、分数VC-4ペイロード内に搭載されていることが示されます。
Three EBM fields are used. Each EBM field corresponds to a different TUG-3 within the VC-4. The EBM includes 7 groups of 4 bits per TUG-2. A bit set to 1 indicates that the corresponding VC is equipped, hence carried within the fractional VC-4 payload. An additional 2 bits within the EBM indicate whether VC-3 carried within the TUG-3 is equipped and whether it is in AIS mode.
3つのEBMフィールドが使用されます。各EBMフィールドは、VC-4内の異なるTUG-3に対応しています。EBMには、Tug-2あたり4ビットの7つのグループが含まれます。1に少し設定されていると、対応するVCが装備されているため、分数VC-4ペイロード内に搭載されていることを示します。EBM内の追加の2ビットは、TUG-3内に搭載されているVC-3が装備されているかどうか、およびAISモードにあるかどうかを示します。
The VC-4 EBM has the following format:
VC-4 EBMには次の形式があります。
0 1 2
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|T|TUG2#7 |TUG2#6 |TUG2#5 |TUG2#4 |TUG2#3 |TUG2#2 |TUG2#1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Equipped Bit Mask (EBM) for Fractional VC-4
図10：分数VC-4用の装備ビットマスク（EBM）
The 30 bits of the EBM are divided into 2 bits that control the VC-3 within the TUG-3 and 7 groups of 4 bits, each corresponding to a different TUG-2 within the TUG-3 container.
EBMの30ビットは、TUG-3内のVC-3と4ビットの7つのグループを制御する2ビットに分割され、それぞれがTUG-3容器内の異なるTUG-2に対応しています。
For a TUG-3 containing TUG-2, the first two A and T bits MUST be set to 0. The TUG-2 bits indicate whether the VCs within the TUG-2 are equipped. All 4 bits are used to indicate whether VC-11 (T1) tributaries are carried within a TUG-2. The first 3 bits read right to left are used to indicate whether VC-12 (E1) tributaries are carried within a TUG-2. The first bit is used to indicate that a VC-2 is carried within a TUG-2. The VCs within the TUG-2 are numbered from right to left, starting from the first VC as the first bit on the right. For example, 28 bits of the EBM of a fully occupied TUG-3 with VC-11 tributaries are all ones, while that of a TUG-3 fully occupied with VC-12 tributaries has the binary value 000111011101110111011101110111.
TUG-2を含むTUG-3の場合、最初の2つのAとTビットを0に設定する必要があります。TUG-2ビットは、TUG-2内のVCが装備されているかどうかを示します。4ビットはすべて、VC-11（T1）支流がTUG-2内で運ばれるかどうかを示すために使用されます。右から左に読まれる最初の3ビットは、VC-12（E1）支流がTUG-2内で運ばれるかどうかを示すために使用されます。最初のビットは、VC-2がTUG-2内で運ばれていることを示すために使用されます。TUG-2内のVCは右から左に番号が付けられており、最初のVCから右側の最初のビットとして開始されます。たとえば、VC-11支流を備えた完全に占有されたTUG-3のEBMの28ビットはすべて1つですが、VC-12支流で完全に占有されているTUG-3のビットには、バイナリ値000111011101110111011101110111011111があります。
For a TUG-3 containing VC-3, all TUG-2 bits MUST be set to 0. The A and T bits are defined as follows:
VC-3を含むTUG-3の場合、すべてのTUG-2ビットを0に設定する必要があります。AおよびTビットは次のように定義されています。
T: TUG-3 carried bit. If set to 1, the VC-3 payload is carried within the TUG-3 container. If set to 0, all the TUG-3 columns are not carried within the fractional VC-4 encapsulation. The TUG-3 columns are removed either because the VC-3 is unequipped or in AIS mode.
T：Tug-3キャリービット。1に設定すると、VC-3ペイロードはTUG-3コンテナ内に運ばれます。0に設定した場合、すべてのタグ3列は、分数VC-4カプセル化内で運ばれません。TUG-3カラムは、VC-3が装備されていないか、AISモードであるため、削除されます。
A: VC-3 AIS bit. The A bit MUST be set to 0 when the T bit is 1 (i.e., when the TUG-3 columns are carried within the fractional VC-4 encapsulation). The A bit indicate the reason for removal of the entire TUG-3 columns. If set to 0, the TUG-3 columns were removed because the VC-3 is unequipped. If set to 1, the TUG-3 columns were removed because the VC-3 is in AIS mode.
A：VC-3 AISビット。Tビットが1の場合（つまり、TUG-3列が分数VC-4カプセル化内で運ばれる場合）の場合、ビットを0に設定する必要があります。TUG-3列全体を除去する理由を少し示しています。0に設定すると、VC-3が装備されていないため、TUG-3カラムが削除されました。1に設定すると、VC-3がAISモードにあるため、TUG-3カラムが削除されました。
Fractional VC-4 encapsulation can be implemented in Line Terminating Equipment (LTE) or in Path Terminating Equipment (PTE). PTE implementations terminate the path layer at the ingress PE and generate a new path layer at the egress PE. LTE implementations do not terminate the path layer, and therefore need to keep the content and integrity of the POH bytes across the PSN. In LTE implementations, special care must be taken to maintain the B3 bit-wise parity POH byte. The same procedures for B3 compensation as described in Section 11.2.1.2 for fractional STS-1 encapsulation are used.
分数VC-4カプセル化は、ライン終端機器（LTE）またはパス終端機器（PTE）で実装できます。PTEの実装は、Ingress PEのパス層を終了し、出口PEで新しいパスレイヤーを生成します。LTEの実装はパス層を終了するわけではないため、PSN全体のPOHバイトのコンテンツと整合性を維持する必要があります。LTEの実装では、B3ビットワイズパリティPOHバイトを維持するために特別な注意を払う必要があります。分数STS-1カプセル化のセクション11.2.1.2で説明されているように、B3補償の同じ手順が使用されます。
The actual CEP payload size depends on the number of virtual tributaries carried within the fractional SPE. The contributions of each tributary to the fractional VC-4 payload length as well as the path overhead contribution are described below.
実際のCEPペイロードサイズは、分数SPE内で運ばれる仮想支流の数に依存します。小数のVC-4ペイロード長の各支流とパスオーバーヘッドの寄与を以下に説明します。
Each VC-11 contributes 27 bytes
各VC-11は27バイトに寄与します
Each VC-12 contributes 36 bytes
各VC-12は36バイトに寄与します
Each VC-2 contributes 108 bytes
各VC-2は108バイトに寄与します
Each VC-3(T3) contributes 738 bytes
各VC-3（T3）は738バイトに寄与します
Each VC-3(E3) contributes 576 bytes
各VC-3（E3）は576バイトに寄与します
Each VC-3(uncompressed) contributes 774 bytes
各VC-3（非圧縮）は774バイトに寄与します
VC-4 POH contributes 9 bytes
VC-4 POHは9バイトを寄付します
The VC-3 contribution includes the AU-3 pointer. For example, the payload size of a fractional VC-4 configured to third-SPE encapsulation that carries a single compressed T3 VC-3 and 6 VC-12s would be: 321=(9 + 6*36 + 738) / 3 bytes payload per each packet.
VC-3の貢献には、AU-3ポインターが含まれます。たとえば、単一の圧縮されたT3 VC-3および6 VC-12を搭載した3つのSPEカプセル化に構成された分数VC-4のペイロードサイズは、321 =（9 6*36 738） / 3バイトのペイロードごとに、パケット。
[PWE3-CONTROL] specifies the use of the MPLS Label Distribution Protocol, LDP, as a protocol for setting up and maintaining pseudowires. In particular, it provides a way to bind a de-multiplexer field value to a pseudo-wire, specifying procedures for reporting pseudowire status changes and for releasing the bindings. [PWE3-CONTROL] assumes that the pseudowire de-multiplexer field is an MPLS label; however, the PSN tunnel itself can be either an IP or MPLS PSN.
[PWE3-Control]は、擬似動物を設定および維持するためのプロトコルとして、MPLSラベル分布プロトコルLDPの使用を指定します。特に、擬似ワイヤーの状態の変更を報告し、バインディングを解放するための手順を指定する手順を指定して、マルチプレクサーのフィールド値を擬似ワイヤーに結合する方法を提供します。[PWE3-CONTROL]は、擬似ワイヤーde-MultiplexerフィールドがMPLSラベルであると想定しています。ただし、PSNトンネル自体は、IPまたはMPLS PSNのいずれかです。
The use of LDP for setting up and maintaining CEP pseudowires is OPTIONAL. This section describes the use of the CEP-specific fields and error codes.
CEP Pseudowiresのセットアップと維持にLDPを使用することはオプションです。このセクションでは、CEP固有のフィールドとエラーコードの使用について説明します。
The PW Type field in PWid Forwarding Equivalence Class (FEC) and PW generalized ID FEC elements MUST be set to SONET/SDH Circuit Emulation over Packet (CEP) [PWE3-IANA].
PWID転送等価クラス（FEC）およびPWの一般化ID FEC要素のPWタイプフィールドは、パケット（CEP）[PWE3-AINA]を介したSONET/SDH回路エミュレーションに設定する必要があります。
The control word is REQUIRED for CEP pseudowires. Therefore, the C bit in PWid FEC and PW generalized ID FEC elements MUST be set. If the C bit is not set, the pseudowire MUST not be established and a Label Release MUST be sent with an Illegal C bit status code [PWE3-IANA].
CEP Pseudowiresにはコントロールワードが必要です。したがって、PWID FECおよびPW一般化ID FEC要素のCビットを設定する必要があります。cビットが設定されていない場合、擬似ワイヤを確立する必要はなく、違法なCビットステータスコード[PWE3-IANA]でラベルのリリースを送信する必要があります。
The PWid FEC and PW generalized ID FEC elements can include one or more Interface Parameters fields. The Interface Parameters fields are used to validate that the two ends of the pseudowire have the necessary capabilities to interoperate with each other. The CEP-specific Interface Parameters fields are the CEP/TDM Payload Bytes, the CEP/TDM Bit Rate, and the CEP Options parameters.
PWID FECおよびPW一般化ID FEC要素には、1つ以上のインターフェイスパラメーターフィールドを含めることができます。インターフェイスパラメーターフィールドは、擬似ワイヤの両端が互いに相互運用するために必要な機能を持っていることを検証するために使用されます。CEP固有のインターフェイスパラメーターフィールドは、CEP/TDMペイロードバイト、CEP/TDMビットレート、およびCEPオプションパラメーターです。
This parameter MUST contain the expected CEP payload size in bytes. The payload size does not include network headers, CEP header or padding. If payload compression is used, the CEP/TDM Payload Bytes parameter MUST be set to the uncompressed payload size as if payload compression was disabled. In particular, when Fractional SPE (STS-1/ VC-3 or VC-4) payload compression is used, the Payload Bytes parameter MUST be set to the payload size before removal of the unequipped VT containers and fixed value columns. Therefore, when fractional SPE mode is used, the actual (i.e., on the wire) packet length would normally be less than advertised, and in dynamic fractional SPE, even change while the connection is active. Similarly, when DBA payload compression is used, the CEP/TDM Payload Bytes parameter MUST be set to the payload size prior to compression.
このパラメーターには、予想されるCEPペイロードサイズをバイト単位に含める必要があります。ペイロードサイズには、ネットワークヘッダー、CEPヘッダー、またはパディングは含まれません。ペイロード圧縮を使用する場合、CEP/TDMペイロードバイトパラメーターは、ペイロード圧縮が無効になっているかのように、圧縮されていないペイロードサイズに設定する必要があります。特に、分数SPE（STS-1/ VC-3またはVC-4）のペイロード圧縮を使用する場合、装備されていないVTコンテナと固定値列を取り外す前に、ペイロードバイトパラメーターをペイロードサイズに設定する必要があります。したがって、分数SPEモードを使用すると、実際の（つまり、ワイヤー上の）パケットの長さは通常広告よりも小さくなり、動的な分数SPEでは、接続がアクティブになっている間に変更されます。同様に、DBAペイロード圧縮を使用する場合、CEP/TDMペイロードバイトパラメーターは、圧縮前にペイロードサイズに設定する必要があります。
The CEP/TDM Payload Bytes parameter is OPTIONAL. Default payload sizes are assumed if this parameter is not included as part of the Interface Parameters fields. The default payload size for VT is a single super frame. The default payload size for SPE is 783 bytes.
CEP/TDMペイロードバイトパラメーターはオプションです。このパラメーターがインターフェイスパラメーターフィールドの一部として含まれていない場合、デフォルトのペイロードサイズが想定されます。VTのデフォルトのペイロードサイズは、単一のスーパーフレームです。SPEのデフォルトのペイロードサイズは783バイトです。
A PE that receives a label-mapping request with request for a CEP/TDM Payload Bytes value that is not locally supported MUST return CEP/TDM misconfiguration status error code [PWE3-IANA], and the pseudowire MUST not be established.
局所的にサポートされていないCEP/TDMペイロードバイト値のリクエストを使用してラベルマッピングリクエストを受信するPEは、CEP/TDMのミスコンフィギュレーションステータスエラーコード[PWE3-AINA]を返す必要があり、擬似ワイヤを確立する必要はありません。
The CEP/TDM Bit Rate parameter MUST be set to the data rate in 64- Kbps units of the CEP payload. If payload compression is used, the CEP/TDM Bit Rate parameter MUST be set to the uncompressed payload data rate as if payload compression was disabled. Table 3 specifies the CEP/TDM Bit Rate parameters that MUST be set for each of the pseudowire circuits.
CEP/TDMビットレートパラメーターは、CEPペイロードの64-kbps単位のデータレートに設定する必要があります。ペイロード圧縮を使用する場合、CEP/TDMビットレートパラメーターは、ペイロード圧縮が無効になっているかのように、圧縮されていないペイロードデータレートに設定する必要があります。表3は、それぞれの擬似ワイヤ回路に設定する必要があるCEP/TDMビットレートパラメーターを指定します。
+-------------+-----------------------+
| Circuit | Bit Rate Parameter |
+-------------+-----------------------+
| VT1.5/VC-11 | 26 |
| VT2/VC-12 | 35 |
| VT3 | 53 |
| VT6/VC-2 | 107 |
| STS-Nc | 783*N N=1,3,12,48,192 |
+-------------+-----------------------+
Table 3: CEP/TDM Bit Rates
表3：CEP/TDMビットレート
The CEP/TDM Bit Rate parameter is REQUIRED. Attempts to establish a pseudowire between two peers with different bit rates MUST be rejected with incompatible bit rate status error code [PWE3-IANA], and the pseudowire MUST not be established.
CEP/TDMビットレートパラメーターが必要です。異なるビットレートの2人のピア間で擬似ワイヤを確立しようとする試みは、互換性のないビットレートステータスエラーコード[PWE3-IANA]で拒否されなければならず、擬似ワイヤーを確立してはなりません。
The CEP Options parameter is REQUIRED. The format of the CEP Options parameter is described below:
CEPオプションパラメーターが必要です。CEPオプションパラメーターの形式については、以下に説明します。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|AIS|UNE|RTP|EBM| Reserved [0:6] | CEP Type | Async |
| | | | | | [0:2] |T3 |E3 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 11: CEP Options
図11：CEPオプション
AIS: When set, indicates that the PE sending the label-mapping request is configured to send DBA packets when AIS indication is detected.
AIS：設定すると、AISの表示が検出されたときに、ラベルマッピング要求を送信するPEがDBAパケットを送信するように構成されていることを示します。
UNE: When set, indicates that the PE sending the label-mapping request is configured to send DBA packets when unequipped circuit indication is detected.
UNE：設定すると、装備されていない回路指標が検出されたときに、ラベルマッピング要求を送信するPEがDBAパケットを送信するように構成されていることを示します。
RTP: When set, indicates that the PE sending the label-mapping request is configured to send packets with RTP header.
RTP：設定すると、RTPヘッダーでパケットを送信するようにラベルマッピングリクエストを送信するPEが構成されていることを示します。
EBM: When set, indicates that the PE sending the label-mapping request is configured to send packets with EBM extension header.
EBM：設定すると、PEがラベルマッピングリクエストを送信するPEが、EBM拡張ヘッダーでパケットを送信するように構成されていることを示します。
CEP Type: indicates the CEP connection type:
CEPタイプ：CEP接続タイプを示します。
0x0 SPE mode (STS-1/STS-Mc)
0x0 SPEモード（STS-1/STS-MC）
0x1 VT mode (VT1.5/VT2/VT3/VT6)
0x1 VTモード（VT1.5/VT2/VT3/VT6）
0x2 Fractional SPE (STS-1/VC-3/VC-4)
0x2分数SPE（STS-1/VC-3/VC-4）
Async Type: indicates the Async E3/T3 bandwidth reduction configuration. Relevant only when CEP type is set to fractional SPE, and fractional SPE is expected to carry Asynchronous T3/E3 payload:
非同期タイプ：非同期E3/T3帯域幅削減構成を示します。CEPタイプが分数SPEに設定されている場合にのみ関連性があり、分数SPEは非同期T3/E3ペイロードを運ぶと予想されます。
T3: When set, indicates that the PE sending the label-mapping request is configured to send Fractional SPE packets with T3 bandwidth reduction.
T3：設定すると、PEがラベルマッピングリクエストを送信するPEが、T3帯域幅削減で分数SPEパケットを送信するように構成されていることを示します。
E3: When set, indicates that the PE sending the label-mapping request is configured to send Fractional SPE packets with E3 bandwidth reduction.
E3：設定すると、PEの送信ラベルマッピングリクエストの送信が、E3帯域幅削減で分数SPEパケットを送信するように構成されていることを示します。
Reserved field: MUST be set to 0 by the PE sending the label-mapping request and ignored by the receiver.
予約済みフィールド：PEがラベルマッピングリクエストを送信してPEで0に設定し、受信機によって無視する必要があります。
A PE that does not support one of the CEP options set in the label-mapping request MUST send a label-release message with status code of CEP/TDM misconfiguration [PWE3-IANA], report to the operator, and wait for a new consistent label-mapping. A PE MUST send a new label-mapping request once it is reconfigured or when it receives a label-mapping request from its peer with consistent configuration.
ラベルマッピングリクエストで設定されたCEPオプションのいずれかをサポートしていないPEは、CEP/TDM MISSONFIGURARS [PWE3-IANA]のステータスコードを使用してラベルリリースメッセージを送信し、オペレーターに報告し、新しい一貫性を待つ必要があります。ラベルマッピング。PEは、再構成された場合、または一貫した構成でピアからラベルマッピングリクエストを受信したら、新しいラベルマッピングリクエストを送信する必要があります。
A pseudowire can be configured asymmetrically. One PE can be configured to use bandwidth reduction modes, while the other PE can be configured to send the entire circuit unmodified. A PE can compare the CEP Options settings received in the label-mapping request with its own configuration and detect an asymmetric pseudowire configuration. A PE that identifies an asymmetric configuration MAY report it to the operator.
擬似ワイヤーは非対称的に構成できます。1つのPEは帯域幅削減モードを使用するように構成できますが、もう1つのPEは、回路全体を変更していないように構成できます。PEは、ラベルマッピングリクエストで受信したCEPオプション設定を独自の構成と比較し、非対称の擬似ワイヤ構成を検出できます。非対称構成を識別するPEは、それをオペレーターに報告する場合があります。
The PSN carrying the CEP PW may be subject to congestion. Congestion considerations for PWs are described in Section 6.5 of [PWE3-ARCH]. CEP PWs represent inelastic constant bit rate (CBR) flows and cannot respond to congestion in a TCP-friendly manner prescribed by [CONG]. CEP PWs SHOULD be carried across traffic-engineered PSNs that provide either bandwidth reservation and admission control or forwarding prioritization and boundary traffic conditioning mechanisms. Intserv-enabled domains [INTSERV] supporting Guaranteed Service [GS] and Diffserv-enabled domains [DIFFSERV] supporting Expedited Forwarding [EF] provide examples of such PSNs. It is expected that PWs emulating high-rate SONET STS-Nc or SDH virtual circuits will be tunneled over traffic-engineered MPLS PSN.
CEP PWを運ぶPSNには、混雑の対象となる場合があります。PWSの混雑の考慮事項は、[PWE3-ARCH]のセクション6.5で説明されています。CEP PWは、非弾性一定のビットレート（CBR）フローを表し、[cong]によって規定されたTCPに優しい方法で輻輳に応答することはできません。CEP PWは、帯域幅の予約と入学制御または転送の優先順位付けと境界トラフィックコンディショニングメカニズムのいずれかを提供するトラフィック設計のPSNを介して実施する必要があります。保証されたサービス[GS]およびDIFFSERV対応ドメイン[DIFFSERV]をサポートするINTSERV対応ドメイン[INTSERV]は、そのようなPSNの例を提供します。高級SONET STS-NCまたはSDH仮想回路をエミュレートするPWSが、トラフィックエンジニアのMPLS PSN上にトンネル化されることが予想されます。
CEP PWs SHOULD monitor packet loss in order to detect "severe congestion". If such a condition is detected, a CEP PW SHOULD shut down bi-directionally. This specification does not define the exact criteria for detecting "severe congestion" using the CEP packet loss rate and the consequent restart criteria after a suitable delay. This is left for further study.
CEP PWSは、「重度の輻輳」を検出するためにパケットの損失を監視する必要があります。そのような状態が検出された場合、CEP PWは双方向にシャットダウンする必要があります。この仕様では、CEPパケット損失率を使用して「重度の輻輳」を検出するための正確な基準と、適切な遅延後の結果の再起動基準を定義するものではありません。これはさらなる研究のために残されています。
If the CEP PW has been set up using the PWE3 control protocol [PWE3-CONTROL], the regular PW teardown procedures SHOULD be used upon detection of "severe congestion".
CEP PWがPWE3コントロールプロトコル[PWE3-Control]を使用してセットアップされている場合、「重度の混雑」を検出すると、通常のPW分解手順を使用する必要があります。
The SONET/SDH services emulated by CEP PWs have high availability objectives that MUST be taken into account when deciding on temporary shutdown of CEP PWs. CEP performance monitoring provides entry and exit criteria for the CEP PW unavailable state (UAS-CEP). Detection of "severe congestion" MAY be based on unavailability criteria of the CEP PW.
CEP PWSによってエミュレートされたSONET/SDHサービスには、CEP PWSの一時的なシャットダウンを決定する際に考慮する必要がある高可用性の目標があります。CEPパフォーマンスモニタリングは、CEP PWの利用可能な状態（UAS-CEP）のエントリおよび出口基準を提供します。「重度の輻輳」の検出は、CEP PWの利用不可能基準に基づいている場合があります。
The CEP encapsulation is subject to all of the general security considerations discussed in [PWE3-ARCH]. In addition, this document specifies only encapsulations, and not the protocols used to carry the encapsulated packets across the PSN. Each such protocol may have its own set of security issues, but those issues are not affected by the encapsulations specified herein. Note that the security of the transported CEP service will only be as good as the security of the PSN. This level of security may be less rigorous than that available from a native TDM service due to the inherent differences between circuit-switched and packet-switched public networks.
CEPカプセル化は、[PWE3-ARCH]で議論されているすべての一般的なセキュリティ上の考慮事項の対象となります。さらに、このドキュメントは、カプセル化されたパケットをPSN全体に運ぶために使用されるプロトコルではなく、カプセルのみを指定します。このようなプロトコルには、独自のセキュリティ問題がある場合がありますが、これらの問題は本明細書に指定されているカプセルの影響を受けません。輸送されたCEPサービスのセキュリティは、PSNのセキュリティと同じくらい優れていることに注意してください。このレベルのセキュリティは、サーキットスイッチとパケットスイッチのパブリックネットワークの固有の違いにより、ネイティブTDMサービスから利用可能なセキュリティよりも厳密ではない場合があります。
Although CEP MAY employ an RTP header when explicit transfer of timing information is required, SRTP [RFC3711] mechanisms are not a substitute for securing the PW and underlying MPLS network.
CEPはタイミング情報の明示的な転送が必要な場合にRTPヘッダーを採用する場合がありますが、SRTP [RFC3711]メカニズムは、PWおよび基礎となるMPLSネットワークの保護に代わるものではありません。
IANA considerations for pseudowires are covered in [PWE3-IANA]. CEP does not introduce additional requirements from IANA.
擬似動物のIANAの考慮事項は、[PWE3-AINA]でカバーされています。CEPはIANAから追加の要件を導入しません。
The authors would like to thank the members of the PWE3 Working Group for their assistance on this document. We thank Sasha Vainshtein, Deborah Brungard, Juergen Heiles, and Nick Weeds for their review and valuable feedback.
著者は、この文書での支援についてPWE3ワーキンググループのメンバーに感謝したいと思います。Sasha Vainshtein、Deborah Brungard、Juergen Heiles、Nick Weedsのレビューと貴重なフィードバックに感謝します。
The individuals listed below are co-authors of this document. Tom Johnson from Litchfield Communications was the editor of this document from the pre-WG versions of the SONET SPE work through version 01 of this document.
以下にリストされている個人は、この文書の共著者です。Litchfield CommunicationsのTom Johnsonは、このドキュメントのバージョン01を使用して、SONET SPEのPre-WGバージョンの作品のこのドキュメントの編集者でした。
Craig White Level3 Communications
Ed Hallman Litchfield Communications
Jeremy Brayley Laurel Networks
Jim Boyle Juniper Networks
John Shirron Laurel Networks
Luca Martini Cisco Systems
Marlene Drost Litchfield Communications
Steve Vogelsang Laurel Networks
Tom Johnson Litchfield Communications
Ken Hsu Tellabs
Appendix A. SONET/SDH Rates and Formats
付録A. SONET/SDHレートとフォーマット
For simplicity, the discussion in this section uses SONET terminology, but it applies equally to SDH as well. SDH-equivalent terminology is shown in the tables.
簡単にするために、このセクションの議論ではSonet用語を使用していますが、SDHにも同様に適用されます。SDH等価用語が表に示されています。
The basic SONET modular signal is the synchronous transport signal-level 1 (STS-1). A number of STS-1s may be multiplexed into higher-level signals denoted as STS-N, with N synchronous payload envelopes (SPEs). The optical counterpart of the STS-N is the Optical Carrier-level N, or OC-N. Table 4 lists standard SONET line rates discussed in this document.
基本的なSONETモジュラー信号は、同期輸送信号レベル1（STS-1）です。多くのSTS-1は、n同期ペイロードエンベロープ（SPE）を使用して、STS-Nとして示される高レベルの信号に多重化される場合があります。STS-Nの光学的対応物は、光学キャリアレベルn、またはOC-Nです。表4に、このドキュメントで説明されている標準のソネットラインレートを示します。
+-------------+--------+---------+----------+-----------+-----------+
| OC Level | OC-1 | OC-3 | OC-12 | OC-48 | OC-192 |
+-------------+--------+---------+----------+-----------+-----------+
| SDH Term | - | STM-1 | STM-4 | STM-16 | STM-64 |
| Line | 51.840 | 155.520 | 622.080 | 2,488.320 | 9,953.280 |
| Rate(Mb/s) | | | | | |
+-------------+--------+---------+----------+-----------+-----------+
Table 4: Standard SONET Line Rates
表4：標準のソネットラインレート
Each SONET frame is 125us and consists of nine rows. An STS-N frame has nine rows and N*90 columns. Of the N*90 columns, the first N*3 columns are transport overhead and the other N*87 columns are SPEs. A number of STS-1s may also be linked together to form a super-rate signal with only one SPE. The optical super-rate signal is denoted as OC-Nc, which has a higher payload capacity than OC-N.
各ソネットフレームは125USで、9列で構成されています。STS-Nフレームには9列とn*90の列があります。n*90列のうち、最初のn*3列は輸送オーバーヘッドであり、他のn*87列はSPEです。また、多くのSTS-1をリンクして、1つのSPEのみで超レート信号を形成することもできます。光学的スーパーレート信号は、OC-Nよりもペイロード容量が高いOC-NCとして示されます。
The first 9-byte column of each SPE is the path overhead (POH) and the remaining columns form the payload capacity with fixed stuff (STS-Nc only). The fixed stuff, which is purely overhead, is N/3-1 columns for STS-Nc. Thus, STS-1 and STS-3c do not have any fixed stuff, STS-12c has three columns of fixed stuff, and so on.
各SPEの最初の9バイト列は、パスオーバーヘッド（POH）であり、残りの列は固定されたもの（STS-NCのみ）を使用してペイロード容量を形成します。純粋に頭上の固定されたものは、STS-NCのn/3-1列です。したがって、STS-1とSTS-3Cには固定されたものがなく、STS-12Cには固定されたものの3つの列などがあります。
The POH of an STS-1 or STS-Nc is always 9 bytes in nine rows. The payload capacity of an STS-1 is 86 columns (774 bytes) per frame. The payload capacity of an STS-Nc is (N*87)-(N/3) columns per frame. Thus, the payload capacity of an STS-3c is (3*87 - 1)*9 = 2,340 bytes per frame. As another example, the payload capacity of an STS-192c is 149,760 bytes, which is 64 times the capacity of an STS-3c.
STS-1またはSTS-NCのPOHは、常に9列の9バイトです。STS-1のペイロード容量は、フレームあたり86列（774バイト）です。STS-NCのペイロード容量は（n*87） - （n/3）フレームあたりの列です。したがって、STS -3Cのペイロード容量は（3*87-1）*9 = 2,340バイトあたり2,340バイトです。別の例として、STS-192Cのペイロード容量は149,760バイトで、STS-3Cの容量の64倍です。
There are 8,000 SONET frames per second. Therefore, the SPE size, (POH plus payload capacity) of an STS-1 is 783*8*8,000 = 50.112 Mb/s. The SPE size of a concatenated STS-3c is 2,349 bytes per frame or 150.336 Mb/s. The payload capacity of an STS-192c is 149,760 bytes per frame, which is equivalent to 9,584.640 Mb/s. Table 5 lists the SPE and payload rates supported.
1秒あたり8,000個のソネットフレームがあります。したがって、STS-1のSPEサイズ（POHとペイロード容量）は783*8*8,000 = 50.112 MB/sです。連結されたSTS-3CのSPEサイズは、フレームあたり2,349バイトまたは150.336 MB/sです。STS-192Cのペイロード容量は、フレームあたり149,760バイトで、これは9,584.640 MB/sに相当します。表5に、サポートされているSPEおよびペイロードレートを示します。
+-------------+--------+---------+----------+-----------+-----------+
| SONET STS | STS-1 | STS-3c | OC-12c | OC-48c | OC-192c |
| Level | | | | | |
+-------------+--------+---------+----------+-----------+-----------+
| SDH VC | VC-3 | VC-4 | VC-4-4c | VC-4-16c | VC-4-64c |
| Level | | | | | |
| Payload | 774 | 2,340 | 9,360 | 37,440 | 149,760 |
| Size(Bytes) | | | | | |
| Payload | 49.536 | 149.760 | 599.040 | 2,396.160 | 9,584.640 |
| Rate(Mb/s) | | | | | |
| SPE | 783 | 2,349 | 9,396 | 37,584 | 150,336 |
| Size(Bytes) | | | | | |
| SPE | 50.112 | 150.336 | 601.344 | 2,405.376 | 9,621.504 |
| Rate(Mb/s) | | | | | |
+-------------+--------+---------+----------+-----------+-----------+
Table 5: Payload Size and Rate
表5：ペイロードサイズとレート
To support circuit emulation, the entire SPE of a SONET STS or SDH VC level is encapsulated into packets, using the encapsulation defined in Section 5, for carriage across packet-switched networks.
回路エミュレーションをサポートするために、SONET STSまたはSDH VCレベルのSPE全体がパケットにカプセル化され、セクション5で定義されているカプセル化を使用して、パケット交換ネットワークを横切るキャリッジを使用します。
VTs are organized in SONET super-frames, where a SONET super-frame is a sequence of four SONET SPEs. The SPE path overhead byte H4 indicates the SPE number within the super-frame. The VT data can float relative to the SPE position. The overhead bytes V1, V2, and V3 are used as pointer and stuffing byte similar to the use of the H1, H2, and H3 TOH bytes.
VTSはSonet Super-Framesで編成されており、Sonet Super-Frameは4つのSonet Spesのシーケンスです。SPEパスオーバーヘッドバイトH4は、スーパーフレーム内のSPE数を示します。VTデータは、SPE位置に対して浮くことができます。オーバーヘッドバイトV1、V2、およびV3は、H1、H2、およびH3 TOHバイトの使用と同様のポインターおよび詰めバイトとして使用されます。
Figure 12 below illustrates a SONET interconnect example. Site A and Site B are connected back to a Hub Site, Site C by means of a SONET infrastructure. The OC-12 from Site A and the OC-12 from Site B are partially equipped. Each of them is transported through a SONET network back to a hub site C. Equipped SPEs (or VTs) are then groomed onto the OC-12 towards site C.
以下の図12は、ソネットの相互接続の例を示しています。サイトAとサイトBは、ソネットインフラストラクチャを使用してハブサイト、サイトCに接続されています。サイトAのOC-12とサイトBのOC-12は部分的に装備されています。それらのそれぞれは、ソネットネットワークを介してハブサイトCに輸送されます。装備されたSPE（またはVTS）は、サイトCに向かってOC-12に手入れされます。
SONET Network
____ ___ ____
/ \___/ \ _/ \__
+------+ Physical / \__/ \
|Site A| OC-12 / +---+ OC-12 \ Hub Site
| |=================|\S/|-------------+-----+ \ +------+
| | \ |/ \|=============|\ /| \ | |
+------+ /\ +---+-------------| \ / | / OC-12| |
/ | S |=========|Site C|
+------+ Physical/ +---+-------------| / \ | \ | |
|Site B| OC-12 \ |\S/|=============|/ \| \ | |
| |=================|/ \|-------------+-----+ / +------+
| | \ +---+ OC-12 __ /
+------+ \ __/ \ /
\ ___ ___ / \_/
\_/ \____/ \___/
Figure 12: SONET Interconnect Example Diagram
図12：SONET相互接続の例図
Figure 13 below illustrates the same pair of OC-12s being emulated over a PSN. This configuration frees up bandwidth in the grooming network, since only equipped SPEs (or VTs) are sent through the PSN. Additional bandwidth savings can be realized by taking advantage of the various payload compression options described in Section 11.
以下の図13は、PSNでエミュレートされているOC-12の同じペアを示しています。装備されたSPE（またはVTS）のみがPSNを介して送信されるため、この構成はグルーミングネットワークの帯域幅を解放します。セクション11で説明されているさまざまなペイロード圧縮オプションを利用することで、追加の帯域幅の節約を実現できます。
SONET/TDM/Packet Network
____ ___ ____
/ \___/ \ / \__
+------+ Physical /+-+ \__/ \_
|Site A| OC-12 / | | +---+ \ Hub Site
| |=============|P|=| R | +---+ +-+ +-----+ \ +------+
| | \ |E| | |===| | | |=|\ /| \ | |
+------+ /\+-+ +---+ | | | | | \ / | / OC-12| |
/ | R |=|P| | S |=========|Site C|
+------+ Physical/ +-+ +---+ | | |E| | / \ | \ | |
|Site B| OC-12 \ |P| | R |===| | | |=|/ \| \ | |
| |=============|E|=| | +---+ +-+ +-----+ / +------+
| | \ | | +---+ __ /
+------+ \ +-+ __/ \ /
\ ___ ___ / \_/
\_/ \____/ \___/
Figure 13: SONET Interconnect Emulation Example Diagram
図13：SONET Interconnect Emulation Example Diagram
Figure 14 below shows an example of T1 grooming into OC-12 in access networks. The VT encapsulation is used to transport the T1s from the Hub site to customer sites, maintaining SONET/SDH Operations and Management (OAM).
以下の図14は、アクセスネットワークのOC-12にT1のグルーミングをしている例を示しています。VTカプセル化は、T1Sをハブサイトから顧客サイトに輸送するために使用され、SONET/SDHの運用と管理（OAM）を維持します。
SONET/TDM/Packet Network
____ ___ ____
/ \___/ \ / \__
+------+ Physical /+-+ \__/ \_
|Site A| T1 / | | +---+ \ Hub Site
| |=============|P|=| R | +---+ +-+ +-----+ \ +------+
| | \ |E| | |===| | | |=|\ /| \ | |
+------+ /\+-+ +---+ | | | | | \ / | / OC-12| |
/ | R |=|P| | S |=========|Site C|
+------+ Physical/ +-+ +---+ | | |E| | / \ | \ | |
|Site B| T1 \ |P| | R |===| | | |=|/ \| \ | |
| |=============|E|=| | +---+ +-+ +-----+ / +------+
| | \ | | +---+ __ /
+------+ \ +-+ __/ \ /
\ ___ ___ / \_/
\_/ \____/ \___/
Figure 14: T1 to OC-12 Grooming Emulation Example Diagram
図14：T1からOC-12グルーミングエミュレーションの例図
[G.707] "Network Node Interface For The Synchronous Digital Hierarchy", ITU-T Recommendation G.707, December 2003.
[G.707]「同期デジタル階層のネットワークノードインターフェイス」、ITU-T推奨G.707、2003年12月。
[G.783] "Characteristics of synchronous digital hierarchy (SDH) equipment functional blocks", ITU-T Recommendation G.783, February 2004.
[G.783]「同期デジタル階層（SDH）機器機能ブロックの特性」、ITU-T推奨G.783、2004年2月。
[G.784] "Synchronous Digital Hierarchy (SDH) management", ITU-T Recommendation G.784, July 1999.
[G.784]「同期デジタル階層（SDH）管理」、ITU-T推奨G.784、1999年7月。
[G.806] "Characteristics of transport equipment-Description methodology and generic functionality", ITU-T Recommendation G.806, February 2004.
[G.806]「輸送機器と一般的な機能の特性」、ITU-T推奨G.806、2004年2月。
[G.825] "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.
[G.825]「同期デジタル階層（SDH）に基づいたデジタルネットワーク内でのジッターとさまよう」、ITU-T推奨G.825、2000年3月。
[GR253] "Synchronous Optical Network (SONET) Transport Systems: Common Generic Criteria", Telcordia GR-253- CORE Issue 3, September 2000.
[GR253]「同期光ネットワーク（SONET）輸送システム：共通の汎用基準」、Telcordia GR-253-コア号3、2000年9月。
[MPLS] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[MPLS] Rosen、E.、Tappan、D.、Fedorkow、G.、Rekhter、Y.、Farinacci、D.、Li、T。、およびA. conta、「MPLSラベルスタックエンコーディング」、RFC 3032、2001年1月。
[PWE3-CONTROL] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006.
[PWE3-Control] Martini、L.、Rosen、E.、El-Aawar、N.、Smith、T.、およびG. Heron、「Pseudowire Setup and Maintenance fut Label Distribution Protocol（LDP）」、RFC 4447、2006年4月。
[PWE3-IANA] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
[PWE3-IANA] MARTINI、L。、「Pseudowire to Edge Emulation（PWE3）へのIANAの割り当て」、BCP 116、RFC 4446、2006年4月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RTP] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3005, July 2003.
[RTP] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、STD 64、RFC 3005、2003年7月。
[SONET] "Synchronous Optical Network (SONET) - Basic Description including Multiplex Structure, Rates and Formats", ANSI T1.105-2001, October 2001.
[SONET]「同期光ネットワーク（SONET） - 多重構造、レート、フォーマットを含む基本的な説明」、ANSI T1.105-2001、2001年10月。
[CONG] Floyd, S., "Congestion Control Principles", RFC 2914, September 2000.
[Cong]フロイド、S。、「混雑制御原則」、RFC 2914、2000年9月。
[DIFFSERV] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[Diffserv、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z。、およびW. Weiss、「差別化されたサービスのアーキテクチャ」、RFC 2475、1998年12月。
[EF] Davie, B., Charny, A., Bennett, J., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002.
[EF] Davie、B.、Charny、A.、Bennett、J.、Benson、K.、Le Boudec、J.、Courtney、W.、Davari、S.、Firoiu、V。、およびD. Stiliadis」迅速な転送PHB（ホップごとの動作）」、RFC 3246、2002年3月。
[GS] Shenker, S., Partridge, C., and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997.
[GS] Shenker、S.、Partridge、C。、およびR. Guerin、「保証されたサービス品質の仕様」、RFC 2212、1997年9月。
[INTSERV] Braden, R., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.
[Intserv] Braden、R.、Clark、D。、およびS. Shenker、「インターネットアーキテクチャにおける統合サービス：概要」、RFC 1633、1994年6月。
[PWE3-ARCH] Bryant, S. and P. Pate, "PWE3 Architecture", RFC 3985, March 2005.
[PWE3-ARCH] Bryant、S。およびP. Pate、「PWE3 Architecture」、RFC 3985、2005年3月。
[PWE3-MPLSCW] Bryant, S., Swallow, G., and D. McPherson, "Control Word for Use over an MPLS PSN", RFC 4385, February 2006.
[PWE3-MPLSCW] Bryant、S.、Swallow、G。、およびD. McPherson、「MPLS PSNを介した使用に関するコントロールワード」、RFC 4385、2006年2月。
[PWE3-REQ] Xiao, X., McPherson, D., and P. Pate, "Requirements for Pseudo Wire Emulation Edge-to-Edge (PWE3)", RFC 3916, September 2004.
[PWE3-REQ] Xiao、X.、McPherson、D。、およびP. Pate、「Pseudo Wire Emulation Edge-to-Edge（PWE3）の要件」、RFC 3916、2004年9月。
[PWE3-TDM-REQ] Riegel, M., "Requirements for Edge-to-Edge Emulation of TDM Circuits over Packet Switching Networks (PSN)", RFC 4197, October 2005.
[PWE3-TDM-REQ] Riegel、M。、「パケットスイッチングネットワーク（PSN）上のTDM回路のエッジツーエッジエミュレーションの要件」、RFC 4197、2005年10月。
[RFC3711] Baugher, M., McGrew, D., Naslund, N., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711] Baugher、M.、McGrew、D.、Naslund、N.、Carrara、E。、およびK. Norrman、「セキュアリアルタイム輸送プロトコル（SRTP）」、RFC 3711、2004年3月。
Authors' Addresses
著者のアドレス
Andrew G. Malis Verizon Communications 40 Sylvan Road Waltham, MA 02451 USA
Andrew G. Malis Verizon Communications 40 Sylvan Road Waltham、MA 02451 USA
EMail: andrew.g.malis@verizon.com
Prayson Pate Overture Networks 507 Airport Blvd, Suite 111 Morrisville, NC 27560 USA
Prayson Pate Overtuer Networks 507 Airport Blvd、Suite 111 Morrisville、NC 27560 USA
EMail: prayson.pate@overturenetworks.com
Ron Cohen (editor) Resolute Networks 15 Central Avenue Modiin, 71700 Israel
Ron Cohen（編集者）Resolute Networks 15 Central Avenue Modiin、71700イスラエル
EMail: ronc@resolutenetworks.com
David Zelig Corrigent Systems 126 Yigal Alon st. Tel Aviv, Israel
David Zelig Corrigent Systems 126 Yigal Alon St。テルアビブ、イスラエル
EMail: davidz@corrigent.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。