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）IETFトラスト（2007）。
Abstract
抽象
This document provides encapsulation formats and semantics for emulating Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) circuits and services over MPLS.
この文書では、MPLS上で同期光ネットワーク/同期デジタル階層（SONET / SDH）回路やサービスをエミュレートするためのカプセル化フォーマットとセマンティクスを提供します。
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].
擬似ワイヤエミュレーションエッジ・ツー・エッジ（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パケット交換ネットワーク（PSNが）上の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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "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
ADMは、ドロップ・マルチプレクサAISアラーム表示信号APM適応ポインタ管理AU-nの行政単位-Nを追加します（SDH）8月の行政単位のグループ（SDH）BIPビット挿入パリティは、ビル内統合タイミング供給CEP回線エミュレーションは、パケットDBA動的帯域割当EBM装備ビットビット以上EPAR明示的なポインタ調整リレーマスク
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)
信号LTE回線終端機器POHパスオーバーヘッドPSNパケットがネットワークPTEパス終端装置PW擬似回線RDIリモート障害表示SDH同期デジタル階層SONET同期光ネットワークSPE同期ペイロードエンベロープSTM-nは同期転送モジュール-nに（スイッチのフレームLOS損失のLOF損失SDH）STS-nは同期転送信号-N（SONET）TDM時分割多重TOHトランスポートオーバーヘッドTU-nの支流ユニット-N（SDH）TUG-nはトリビュタリユニットグループ-N（SDH）UNEQ未実装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で説明OPTIONAL 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-AISの生成及び下流接続回線上の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ビットの設定の解釈を記載します。
+---+---+-----------------------------+
| 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に設定する必要がある場合Lengthフィールドを設定しなければなりません。ペイロードが抑制されている場合に使用される場合、特に、（例えば、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分]：構造体のポインタは、パケットペイロード内SONET構造の最初のバイトのオフセットを含まなければなりません。 SPEエミュレーションのために、構造体のポインタは、CEPパケット内のJ1バイトを検索します。 VTエミュレーションのために、構造体へのポインタは、パケット内のV5バイトの位置を特定します。構造体ポインタ値は0 CEPヘッダの後の最初のバイトを表し0xFFE、0の範囲です。パケットがJ1（またはV5）バイトを搬送しない場合に構造ポインタは0xFFFに設定しなければなりません。アタッチメント回路の任意のポインタ変化（新規データフラグ（NDF）イベント）がCEPパケット内SONET構造のオフセット、したがって構造ポインタ値を変更する変更します。
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のPSN上で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パケットストリームにTDM SONET / SDHを適応、及びバックTDM SONET / SDHにCEPパケットストリームを変換する：すべての適応機能と同様に、CEPは、2つの別個の構成要素を有しています。最初の関数はCEPパケット化または送信者およびCEPデパケット化またはレシーバとしての第2と呼ばれます。この用語は、以下に例示されています。
+------------+ +---------------+
| | | |
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脱パケタイザは、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デパケッタイザーは、ジッタバッファにパケットを受信し、対応する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のシーケンス番号は、失われたおよび/またはmisorderedパケットを検出するためのメカニズムを提供します。 RTPヘッダの送信が抑制される場合CEPヘッダ内のシーケンス番号が使用されなければなりません。 CEP脱パケタイザは、紛失またはmisorderedパケットを検出しなければなりません。デ・パケタイザは、いずれかの場所ですべてのもののパターン（AIS）のうち果たすべきCEPパケットを落としました。 CEPデパケッタイザは再オーダーパケットの順序が受信すべきです。 CEPデパケッタイザは、並べ替えをサポートしていない場合、それはmisorderedパケットを破棄しなければなりません。
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デパケット化がまたはパケット同期から外れているか否かです。次の段落では、その決意が行われている方法を説明します。
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脱パケタイザは並べ替えをサポートしている場合は、任意のパケットは、そのプレイアウト時間の前にまだ有効と見なされます受け取りました。
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脱パケタイザは、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脱パケタイザは、デフォルトではパケット同期していない状態になります。起動時またはパケット同期の損失の後にパケット同期を宣言するには、CEP脱パケタイザは、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デパケッタイザーは、パケット同期状態になると、それは、パケットの同期を失うことになります一連のイベントが発生する可能性があります。
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デパケッタイザーが順次空パケットの構成可能な数よりも多く発生した場合、CEPデパケット化、パケット同期（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の故障はLOPS欠陥の2.5 +/- 0.5秒後に宣言し、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疑似回線の間で維持し、アラーム信号のマッピングを記述する。 PSNにSONET / SDH、およびSONET / SDHへのPSN：明確にするために、マッピングは、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障害指示にマッピングされなければなりません。故障検出機能とパフォーマンス監視機能は、例えば、LTE、PTE、タンデム接続監視[G.707]、または非侵入型監視（中間接続監視）NSPの機能に依存しています。
The following sections describe the mapping of SONET/SDH Maintenance Signals and Alarm conditions into CEP pseudowire indications.
以下のセクションでは、CEPのスードワイヤ指示にSONET / SDH保守信号とアラーム条件のマッピングを記述する。
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
SONET / SDHパスの停止は、パスAIS（AIS-P）などの保守アラームを使用してシグナリングされます。 AIS-Pは、具体的には、SONET / SDHパスは、現在有効なエンドユーザーのデータを送信していないことを示し、そして
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.
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.
SPE / VT層にSONET / SDH障害のマッピングは、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.
DBAは、AIS-P / Vが有効になっている場合、唯一必要なヘッダとオプションのパディングは、パケットネットワークに送信されます。使用される場合は、長さフィールドは、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はN2としてZ6を指す）バイト任意に搬送タンデムコネクション信号の中間ネットワーク要素の間です。タンデム接続を輸送未実装信号が非ゼロ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パケット化は、信号ラベル、トレース（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.
DBAは未実装SPE / VTのために有効になっている場合にのみ、必要なヘッダとオプションのパディングは、パケットネットワークに送信されます。使用される場合は、長さフィールドは、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関数はCEPヘッダの一方にRビットを設定することによって、パケット同期の損失中のパケットネットワークに向け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].
SONET / SDHチャネルへのAIS-P / V表示を再生するためにCEPデパケット化機能を引き起こすパケットネットワークにおけるいくつかの条件があります。 CEPデパケッタイザーは、各パケットを受信するためのすべてのもののいずれかのパケットの価値を再生しなければならない、と[SONET]で定義されるようにAIS-P / VをシグナリングするSONET / SDHオーバーヘッドを設定しなければなりません、[GR253]、および[G.707 ]。
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.
これらの最初は、遠端はAIS-P / Vアラームの宣言につながるエラーを検出したことを示す1に設定LビットでCEPパケットの受信です。 AIS-P / Vのうちのプレイに加えて、CEP脱パケタイザはすべてのものの値にポインタ値を設定する必要があります。
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.
SONET / SDHチャネルにAIS-P / V指示を再生するCEPデパケット化機能の原因となる第二の場合は、パケット同期の損失の間です。
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.
第三の場合は、1本に設定し、両方のNとPビットでCEPパケットの受信であり、パケットネットワークの遠端で受信ポインタLOP-P / Vの損失の明示的な指標です。 AIS-P / Vのうちのプレーに加えて、CEP脱パケタイザはすべてのものの値にポインタ値を設定する必要があります。
There are several conditions in the packet network that cause the CEP function to transmit Unequipped indications onto the SONET/SDH channel.
SONET / SDHチャネルに未実装の適応症を送信するためにCEP機能を引き起こすパケットネットワークにおけるいくつかの条件があります。
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デパケタイザの一部に特別な処理を必要としません。
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.
第二の場合は、LビットがDBAがAIS-P / Vによって未実装指示によってトリガされなかったことを示し、0に設定されているペイロードは、DBAにより除去されたことを示す長さフィールドを持つCEPパケットの受信であります表示。 CEPデパケッタイザーは、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デパケッタイザーはSONET / SDHインタフェースに向かってSPE / VT未実装指示を果たさなければならない第三のケースです。
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]でSONET階層に対して定義されています。 CEPのPWをを使用している場合、これらの規格で指定されたワンダとジッタの制限は維持しなければなりません。
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）とAdaptiveポインタ管理（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のパケタイザは、SPE（またはVT）の残りのためにCEPパケットペイロードにSONET / SDHストリームからH3（又はV3）バイトを組み込まなければなりません。正のポインタ調整イベントの間、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デパケッタイザーは、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].
正および負のポインタ調整中H3（及びV3）バイト及びスタッフバイトの使用に関する詳細は[SONET]、[GR253]、および[G.707]に見出すことができます。
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）と呼ばれます。 PWの両端が共通タイミング基準へのアクセス権を持っている場合EPARにのみ有効です。
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実装は0にNとPビットを設定しなければなりません。
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.
ポインタ調整イベントは、パケタイザによって三つの連続するパケットで送信されなければなりません。 N / Pビットがセットされたいずれか一つのパケットを受信したとき、デパケッタイザーは、ポインタ調整イベントを果たさなければなりません。 CEPデパケッタイザーは、SONET / SDHポインタ調整イベントは、任意のより頻繁回遠隔CEPパケタイザによって送信毎に3つのCEPパケット当たりよりも再生されないことを保証するために、CEPのシーケンス番号を利用しなければなりません。
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パケット化は、より少ないVTポインタ調整指示にN及びP CEPヘッダビットを使用してPSN上シグナリング複数SPEポインタ調整を変換しなければなりません。単純なアルゴリズムは、累算器（カウンタ）を使用して、この目的のために使用することができます。
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に記載のクォータは、例えば、VT1.5エミュレーションのための26バイト、VT2エミュレーションのための35バイトのVTサイズの1/4です。
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、即ち、正のVC-4ポインタの調整で運ばSDH仮想コンテナに適用され、正のVC-12ポインタの調整がアキュムレータに783の単位を付加しながら、VC-12、アキュムレータ35個の単位を付加します。
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ポインタ管理をエミュレートするために使用することができる他の任意の方法は、適応型ポインタ管理（APM）です。基本的な用語では、APMは再組み立てSONET / SDH SPEでポインタ調整を導入するCEPジッタバッファの深さについての情報を使用しています。
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 / SDH [SONET]で定義されるように、[GR253]、[G.707]、および[G.784]は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脱パケタイザによって維持されます。
The performance monitors are based on two types of defects.
パフォーマンスモニタは、欠陥の二つのタイプに基づいています。
Type 1: missing or dropped packet.
タイプ1：存在しないか、またはドロップされたパケット。
Type 2: buffer underrun, buffer overrun, LOPS, missing packets above predefined configurable threshold.
タイプ2：バッファアンダーラン、バッファオーバーランは、予め定義された設定可能な閾値を超えるパケットの欠落、LOPS。
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 CEP SES-エラー秒 - 重大エラー秒数UAS-CEP 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欠陥はES-CEPとして宣言しなければならない含まれる各第二。少なくとも一つの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のない連続した秒の設定可能な数の後にクリアされるものとする（SHALL）。それぞれのデフォルト値は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障害がCEP-NEタイプの2.5 +/- 0.5秒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デパケッタイザへの洞察を提供しています。
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-RDIは、着信CEPパケットに設定されているときにCEP-FE欠陥が宣言されています。
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の障害は、CEP-FE欠陥の2.5 +/- 0.5秒後に宣言し、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）は1〜2のトリガ条件が満たされているSPE（またはVT）断片、AIS-P / VまたはSPE / VT未実装の送信を抑制するためのOPTIONALメカニズムです。
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.
DBAトリガがPWの入力で認識された場合、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の唯一の選択されたセットを運びます。このモードでは、STS-1 POH信号ラベルバイトC2 = 2（VT構造SPE）とのおよび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）カプセル化の実装は、一つ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容器にVTSのマッピングは[GR253]のセクション3.2.4に記載されており、VC-3へのマッピングは[G.707]に、セクション7.2.4で定義されています。 CEPパケット化は、すべての固定列のバイト（カラム30および59）と除去のVTに属するすべてのバイトを除去します。のみ
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 POHは、バイト選択のVTに属するバイトはペイロード内に運ばれます。 CEPデパケッタイザーは、固定スタッフバイトを追加し、除去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.5（のT1）、3 VT2s（のE1）、2 VT3s、又は単一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のカプセル化は、任意のVTは、のVTが除去されたペイロードとSTS-1内で実行されるかを指定するビットマスクを運ぶことができます。この任意のビットマスク属性は、入力回路エミュレーションノードが正しい順序での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.
STS-1カプセル化のため、この文書で定義されるように、L、R、N、P、FRG、長さ、シーケンス番号、および構造ポインタフィールドが使用されています。
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：フラクショナル用装備ビットマスク（EBM）STS-1
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の中で運ばれているかどうかを示すために使用されます。右から左に読み出された第1の3ビットは、VT2（E1）支流がVTGの中で運ばれているかどうかを示すために使用されます。最初の2ビットは、VT3（DS1C）支流がVTGの中で運ばれているかどうかを示すために使用されます。右端のビットはVT6（DS2）がVTGの中で運ばれているかどうかを示すために使用されます。 VTG内のVTは、右側の最初のビットとして第1のVTから出発して、右から左に番号が付けられています。完全VT2（E1）で占有STS-1支流のバイナリ値0111011101110111011101110111を有している、例えば、完全に占有STS-1 VT1.5トリビュタリとのEBMは、全てのものです。
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実装は入口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)
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入力信号B3 [I]」に[i]の値は、新しい（補償）B3を= [i]の値B3の* [I] =未実装でVTSのB3 [i]の値入力信号|| =排他的OR演算子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は未実装のVTを再構成し、追加のVTを追加収容する同様に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
各VT1.5は27バイトに貢献します
Each VT2 contributes 36 bytes
各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.
例えば、分数STS-1は、261 = 36 * 7 + 9バイトの実際のサイズを有するであろうフルSPEカプセル化7 VT2回路を担持します。サードSPEカプセル化の実際のペイロードサイズを計算するために3で割ます。
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信号ラベルバイト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）カプセル化の実装は、一つ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列はPOH列から開始して、87に1の番号が付けられ、次の列が値を修正して除去される。1.番号：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列）です。固定列のパリティフルSPEカプセル化のための実際のペイロードサイズは729のバイトと第-SPEカプセル化のために243バイトであろう0になるようにB3パリティバイトは変更する必要はありません。
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.
[G.707]のセクション10.1.2.1に記載されているようにT3は、VC-3容器に非同期でカプセル化されます。 VC-3容器を取り外した2固定スタッフ列30と59とのSTS-1容器と同一であり、唯一の85のデータ列を有しています。それ以外は、マッピングが同じです。
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列から開始して、85に1の番号を付け（およびいない87）され、次の列は、値を修正して除去される。1.番号：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列）です。固定列のパリティフルSPEカプセル化のための実際のペイロードサイズは567のバイトと第-SPEカプセル化のために189バイトであろう0になるようにB3パリティバイトは変更する必要はありません。
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-4にVC-11、VC-12、VC-2、VC-3のマッピングを定義します。このマッピングは、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-4のVCへのマッピングオプションが記載されています。 VC-4は、3 TUG-3が含まれています。各TUG-3は、単一TU-3または7 TUG-2Sで構成されています。 TU-3は、単一のVC-3が含まれています。 TUG-2は、4 VC-11S（丁）、3 VC-12S（のE1）、または1個のVC-2のいずれかを含みます。したがって、VC-4は、3 VC-3S、1 VC-3と42 VC-12S、63 VC-12S、等を含んでいてもよいです
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信号ラベルバイトC2 = 2（TUG構造）とVC-4のために適用可能であり、C2 = 3（ロックTU-N）のために。 VC-4のVC容器へのマッピングは[G.707]のセクション7.2に記載されています。 CEPパケット化は、すべての固定列のバイト除去VCに属するすべてのバイトを除去します。選択されたVCに属するVC-4 POHバイトとバイトのみがペイロード内に運ばれます。 CEPデパケッタイザーは、固定スタッフバイトを追加し、除去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がVC-4ペイロード内に担持されたのVCが除去されたかを指定するビットマスクを運ぶことができます。この任意のビットマスク属性は、入力回路エミュレーションノードが正しい順序でVCを再構成するための出力回路エミュレーションノードに十分な情報を提供し、その場で未実装のVCを除去することを可能にします。ビットマスクの使用は、（実際のデータを運ぶ）のみ装備の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、フルSPEのペイロード長をサポート月実装。分数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におけるVC-4のTUG-3のマッピングを定義します。各TUG-3は、86列が含まれます。 TUG-3＃1、TUG-3＃2、及びTUG-3＃3列から4列1を出発して、バイト多重化され、列2および3を固定し、したがって分数VCで除去しながら、VC-4 POHあります-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.
TUG-3にTU-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-3にTUG-2のマッピングは[G.707]のセクション7.2.3で定義されています。 TUG-3の最初の2列は、固定され、したがって、分数VC-4のカプセル化で除去されます。 7 TUG-2S、ワイド各12列は、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の設定された事前に構成されていることを前提としています。入口エミュレーション・エッジは、固定された列を削除し並びに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.
STS-1カプセル化のため、この文書で定義されるように、L、R、N、P、FRG、長さ、シーケンス番号、および構造ポインタフィールドが使用されています。
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.
三個のEBMのフィールドが使用されています。各EBMフィールドは、VC-4内の異なるTUG-3に相当します。 EBMはTUG-2当たり4ビットの7基を含みます。 1に設定されたビットは、対応するVCが分数VC-4ペイロード内に運ばしたがって、装備されていることを示しています。 EBM内の追加の2ビットは、VC-3はTUG-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ビットが4ビット、TUG-3容器内の異なるTUG-2に対応するそれぞれのTUG-3および7グループ内のVC-3を制御する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-3 TUG-2を含有するため、最初の2つのAとTビットはTUG-2ビットはTUG-2内のVCが装備されているかどうかを示す0に設定しなければなりません。すべての4ビットは、VC-11（T1）支流がTUG-2の中で運ばれているかどうかを示すために使用されます。右から左に読み出された第1の3ビットは、VC-12（E1）支流がTUG-2の中で運ばれているかどうかを示すために使用されます。最初のビットは、VC-2がTUG-2内で行われることを示すために使用されます。 TUG-2内のVCは、右側の最初のビットとして第VCから出発して、右から左に番号が付けられています。完全VC-12支流で占めTUG-3のバイナリ値000111011101110111011101110111を有している、例えば、VC-11支流と完全に占有TUG-3のEBMの28ビットは、すべてのものです。
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:
TUG-3 VC-3を含有するため、すべてのTUG-2ビットは次のようにAおよびTビットが定義されて0に設定しなければなりません。
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に設定すると、すべてのTUG-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のときAビットは0に設定しなければなりません（すなわち、TUG-3列は分数VC-4カプセル内に運ばれる場合）。ビット全体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実装は入口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-12Sは、あろう圧縮担持三SPEカプセル化するように構成された分数VC-4のペイロードサイズ：321 =（10 + 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]は疑似ワイヤデマルチプレクサフィールドは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の疑似回線を維持するための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 Typeフィールドは、パケットオーバーSONET / SDH回線エミュレーション（CEP）[PWE3 - IANA]に設定しなければなりません。
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の疑似回線に必要です。したがって、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ミスコンフィギュレーションのステータスエラーコード[PWE3 - IANA]を返さなければならないサポートされていないCEP / TDMペイロードバイト値の要求とラベルマッピング要求を受信したPE、および疑似回線が確立されてはいけません。
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：セットは、ラベルマッピング要求を送信PEはAIS指示が検出された場合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：セットは、ラベルマッピング要求を送信するPEは、RTPヘッダを持つパケットを送信するように構成されていることを示している場合。
EBM: When set, indicates that the PE sending the label-mapping request is configured to send packets with EBM extension header.
EBMは：設定すると、ラベルマッピング要求を送信する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.
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によって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の設定ミス[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.
スードワイヤは、非対称的に構成することができます。他のPEは、非修飾回路全体を送信するように構成することができ、一方の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を横切って実施すべきです。 IntServの対応ドメイン【のIntServ]保証サービス[GS]と支持緊急転送する[EF]そのようなのPSNの例を提供する支持のDiffserv対応ドメイン[DIFFSERV]。高速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 PWのでエミュレートSONET / SDHサービスは、CEP PWを一時的にシャットダウンを決定する際に考慮しなければならない高可用性の目標を持っています。 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 - IANA]で覆われています。 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作業部会のメンバーに感謝したいと思います。我々は彼らのレビューと貴重なフィードバックのためのサーシャVainshtein、デボラBrungard、ユルゲンハイレス、そしてニック雑草に感謝します。
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.
下記に記載された個人は、このドキュメントの共著者です。リッチフィールドコミュニケーションズからのトム・ジョンソンは、SONET SPEの前WGのバージョンから、この文書の編集者は、このドキュメントのバージョン01を介して動作しました。
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の標準的なSONET回線速度は、この文書で説明します。
+-------------+--------+---------+----------+-----------+-----------+
| 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：標準SONET回線料金
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.
各SONETフレームは125usで、9行で構成されています。 STS-Nフレームは9行とN * 90個の列があります。 N * 90列の、最初のN * 3列は、オーバーヘッド輸送され、他のN * 87列はのSPEです。 STS-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）でペイロード容量を形成します。オーバーヘッド純粋である固定スタッフは、N / STS-NC 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バイト）です。 （N / 3）フレームあたりの列 - STS-NCのペイロード容量は（N * 87）です。フレーム当たり9 = 2,340バイト* - したがって、STS-3cのペイロード容量は、（1 3 * 87）です。別の例として、STS-192Cのペイロード容量は、STS-3cの64倍の容量である149760バイトです。
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
毎秒8,000 SONETフレームがあります。したがって、STS-1 SPEのサイズ、（POHプラスペイロード容量）は783 * 8 * 8,000 = 50.112 MB / sです。連結STS-3cのSPEサイズはフレームあたり2,349バイト
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.
150.336 Mb /秒。 STS-192Cのペイロード容量は9,584.640 Mb /秒に相当するフレームあたり149760バイトです。表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.
VTは、SONETスーパーフレームは、4個のSONET SPEの配列でSONETスーパーフレームに編成されます。 H4バイトSPEパスオーバーヘッドは、スーパーフレーム内のSPEの数を示します。 VTデータは、SPE位置に対して浮くことができます。オーバーヘッドは、V1、V2、及びV3はポインタとH1、H2の使用と同様スタッフィングバイトとして使用されるバイト、H3 TOHはバイト。
Appendix B. Example Network Diagrams
付録B.サンプルネットワークダイアグラム
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は、以下SONET相互接続例を示す図です。サイトAとサイトBは、SONETインフラストラクチャによってバックハブサイト、サイトCに接続されています。サイトAとOC-12サイトBからのOC-12は、部分的に装備されています。それらの各々は、バックハブサイトC.装備のSPE（またはVTS）にSONETネットワークを介して搬送され、サイト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-12Sの同じ対を示します。のみ装備のSPE（またはのVT）が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インターコネクトエミュレーション例ダイアグラム
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のカプセル化は、SONET / SDH運用管理（OAM）を維持し、顧客サイトへのハブサイトからのT1を輸送するために使用されます。
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：OC-12グルーミングエミュレーション例図にT1
[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] ITU-T勧告G.783、2004年2月 "同期デジタル階層（SDH）機器の機能ブロックの特性"。
[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- COREの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]ローゼン、E.、タッパン、D.、Fedorkow、G.、Rekhter、Y.、ファリナッチ、D.、李、T.、およびA.コンタ、 "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.
、RFC 4447 [PWE3-CONTROL]マルティーニ、L.、ローゼン、E.、エルAawar、N.、スミス、T.、およびG.サギ、 "ラベル配布プロトコル（LDP）を使用して疑似回線の設定とメンテナンス"、 2006年4月。
[PWE3-IANA] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
[PWE3 - IANA]マティーニ、L.、BCP 116、RFC 4446、2006年4月 "エッジエミュレーション（PWE3）への擬似回線EdgeのIANAの割り当て"。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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"、STD 64、RFC 3005、2003年7月[RTP] Schulzrinneと、H.、Casner、S.、フレデリック、R.、およびV.ヤコブソン、。
[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.、ブラック、D.、カールソン、M.、デイヴィス、E.、王、Z.、およびW.ワイス、 "差別化サービスのためのアーキテクチャ"、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】デイビー、B.、Charny、A.、ベネット、J.、ベンソン、K.、ルBoudec、J.、コートニー、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.、ヤマウズラ、C.、およびR.ゲラン、 "保証されたサービスの質の仕様"、RFC 2212、1997年9月。
[INTSERV] Braden, R., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.
"インターネットアーキテクチャにおける統合サービス：概要" [イントサーブ]ブレーデン、R.、クラーク、D.、およびS. Shenker、RFC 1633、1994年6月。
[PWE3-ARCH] Bryant, S. and P. Pate, "PWE3 Architecture", RFC 3985, March 2005.
[PWE3 - ARCH]ブライアント、S.とP.パテ、 "PWE3アーキテクチャ"、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.
"MPLS PSNの上の使用のための制御ワード" [PWE3-MPLSCW]ブライアント、S.、ツバメ、G.、およびD.マクファーソン、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]シャオ、X.、マクファーソン、D.、およびP.パテ、 "疑似ワイヤーエミュレーション端から端まで（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]リーゲル、M.、RFC 4197、2005年10月、 "パケット交換ネットワーク（PSN）上のTDM回路の端から端までエミュレーションのための要件"。
[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.、マグリュー、D.、Naslund、N.、カララ、E.、およびK. Norrman、 "セキュアリアルタイム転送プロトコル（SRTP）"、RFC 3711、2004年3月。
Authors' Addresses
著者のアドレス
Andrew G. Malis Verizon Communications 40 Sylvan Road Waltham, MA 02451 USA
アンドリューG. Malisベライゾン・コミュニケーションズ40シルバンロードウォルサム、MA 02451 USA
EMail: andrew.g.malis@verizon.com
メールアドレス：andrew.g.malis@verizon.com
Prayson Pate Overture Networks 507 Airport Blvd, Suite 111 Morrisville, NC 27560 USA
Praysonパテ序曲ネットワーク507エアポートブルバード、スイート111モリスビル、NC 27560 USA
EMail: prayson.pate@overturenetworks.com
メールアドレス：prayson.pate@overturenetworks.com
Ron Cohen (editor) Resolute Networks 15 Central Avenue Modiin, 71700 Israel
ロン・コーエン（エディタ）レゾリュート・ネットワーク15の中央通りModiin、71700イスラエル
EMail: ronc@resolutenetworks.com
メールアドレス：ronc@resolutenetworks.com
David Zelig Corrigent Systems 126 Yigal Alon st. Tel Aviv, Israel
デビッド・カメレオンマンコリジェントシステムズ126イーガル・アロンST。テルアビブ、イスラエル
EMail: davidz@corrigent.com
メールアドレス：davidz@corrigent.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。