[要約] RFC 4553は、パケット上での構造に依存しない時分割多重（TDM）を実現するための仕様です。目的は、TDM信号をパケットネットワーク上で効率的に転送することです。
Network Working Group A. Vainshtein, Ed.
Request for Comments: 4553 Axerra Networks
Category: Standards Track YJ. Stein, Ed.
RAD Data Communications
June 2006
Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP)
パケット上の構造に依存しない時刻分割多重化（TDM）（SATOP）
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 Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
This document describes a pseudowire encapsulation for Time Division Multiplexing (TDM) bit-streams (T1, E1, T3, E3) that disregards any structure that may be imposed on these streams, in particular the structure imposed by the standard TDM framing.
このドキュメントでは、これらのストリームに課される構造、特に標準のTDMフレーミングによって課される構造を無視する、時分割多重化（TDM）ビットストリーム（T1、E1、T3、E3）の擬似ワイヤカプセル化について説明します。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology and Reference Models ................................3
2.1. Terminology ................................................3
2.2. Reference Models ...........................................4
3. Emulated Services ...............................................4
4. SAToP Encapsulation Layer .......................................5
4.1. SAToP Packet Format ........................................5
4.2. PSN and PW Demultiplexing Layer Headers ....................5
4.3. SAToP Header ...............................................6
4.3.1. Usage and Structure of the Control Word .............8
4.3.2. Usage of RTP Header .................................9
5. SAToP Payload Layer ............................................10
5.1. General Payloads ..........................................10
5.2. Octet-Aligned T1 ..........................................11
6. SAToP Operation ................................................12
6.1. Common Considerations .....................................12
6.2. IWF Operation .............................................12
6.2.1. PSN-Bound Direction ................................12
6.2.2. CE-Bound Direction .................................13
6.3. SAToP Defects .............................................14
6.4. SAToP PW Performance Monitoring ...........................15
7. Quality of Service (QoS) Issues ................................16
8. Congestion Control .............................................16
9. Security Considerations ........................................18
10. Applicability Statement .......................................18
11. IANA Considerations ...........................................20
12. Acknowledgements ..............................................20
13. Co-Authors ....................................................20
14. Normative References ..........................................21
15. Informative References ........................................22
Appendix A: Old Mode of SAToP Encapsulation over L2TPv3 ...........24
Appendix B: Parameters That MUST Be Agreed upon during the PW
Setup .................................................24
This document describes a method for encapsulating Time Division Multiplexing (TDM) bit-streams (T1, E1, T3, E3) as pseudowires over packet-switching networks (PSN). It addresses only structure-agnostic transport, i.e., the protocol completely disregards any structure that may possibly be imposed on these signals, in particular the structure imposed by standard TDM framing [G.704]. This emulation is referred to as "emulation of unstructured TDM circuits" in [RFC4197] and suits applications where the PEs have no need to interpret TDM data or to participate in the TDM signaling.
このドキュメントでは、パケットスイッチングネットワーク（PSN）を介した擬似動物として、時分割多重化（TDM）ビットストリーム（T1、E1、T3、E3）をカプセル化する方法について説明します。構造と存在する輸送のみに対処します。つまり、プロトコルは、これらの信号に課される可能性のある構造、特に標準のTDMフレーミングによって課される構造[G.704]に対処します。このエミュレーションは、[RFC4197]の「非構造化されたTDM回路のエミュレーション」と呼ばれ、PESがTDMデータを解釈したり、TDMシグナルに参加する必要がないアプリケーションに適しています。
The SAToP solution presented in this document conforms to the PWE3 architecture described in [RFC3985] and satisfies both the relevant general requirements put forward in [RFC3916] and specific requirements for unstructured TDM signals presented in [RFC4197].
このドキュメントに示されているSATOPソリューションは、[RFC3985]に記載されているPWE3アーキテクチャに適合し、[RFC3916]で提案された関連する一般的な要件と、[RFC4197]で提示された非構造化TDM信号の特定の要件の両方を満たします。
As with all PWs, SAToP PWs may be manually configured or set up using the PWE3 control protocol [RFC4447]. Extensions to the PWE3 control protocol required for setup and maintenance of SAToP pseudowires and allocations of code points used for this purpose are described in separate documents ([TDM-CONTROL] and [RFC4446], respectively).
すべてのPWSと同様に、SATOP PWSは、PWE3コントロールプロトコル[RFC4447]を使用して手動で構成またはセットアップできます。SATOP疑似ワイヤのセットアップとメンテナンスに必要なPWE3制御プロトコルの拡張、およびこの目的に使用されるコードポイントの割り当ては、それぞれ別々のドキュメント（[TDM-Control]と[RFC4446]で説明されています。
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
The following acronyms used in this document are defined in [RFC3985] and [RFC4197]:
このドキュメントで使用される以下の頭字語は、[RFC3985]および[RFC4197]で定義されています。
ATM Asynchronous Transfer Mode
CE Customer Edge
CES Circuit Emulation Service
NSP Native Service Processing
PE Provider Edge
PDH Plesiochronous Digital Hierarchy
PW Pseudowire
SDH Synchronous Digital Hierarchy
SONET Synchronous Optical Network
TDM Time Division Multiplexing
In addition, the following TDM-specific terms are needed:
o Loss of Signal (LOS) - a condition of the TDM attachment circuit wherein the incoming signal cannot be detected. Criteria for entering and leaving the LOS condition can be found in [G.775].
o 信号の損失（LOS） - 着信信号を検出できないTDMアタッチメント回路の条件。LOS状態に入って出発するための基準は、[G.775]にあります。
o Alarm Indication Signal (AIS) - a special bit pattern (e.g., as described in [G.775]) in the TDM bit stream that indicates presence of an upstream circuit outage. For E1, T1, and E3 circuits, the AIS pattern is a sequence of binary "1" values of appropriate duration (the "all ones" pattern), and hence it can be detected and generated by structure-agnostic means. The T3 AIS pattern requires T3 framing (see [G.704], Section 2.5.3.6.1) and hence can only be handled by a structure-aware NSP.
o アラーム表示信号（AIS） - 上流の回路停止の存在を示すTDMビットストリームの特別なビットパターン（[G.775]で説明されているように）。E1、T1、およびE3回路の場合、AISパターンは、適切な期間（「すべてのもの」パターン）のバイナリ「1」値のシーケンスであるため、構造と存在する手段で検出および生成できます。T3 AISパターンには、T3フレーミングが必要であり（[G.704]、セクション2.5.3.6.1を参照）、したがって、構造認識NSPによってのみ処理できます。
We also use the term Interworking Function (IWF) to describe the functional block that segments and encapsulates TDM into SAToP packets and that in the reverse direction decapsulates SAToP packets and reconstitutes TDM.
また、インターワーキング関数（IWF）という用語を使用して、TDMをSATOPパケットにセグメント化およびカプセル化する機能ブロックを記述し、逆方向にSATOPパケットを脱カプセル化し、TDMを再構成します。
The generic models defined in Sections 4.1, 4.2, and 4.4 of [RFC3985] fully apply to SAToP.
[RFC3985]のセクション4.1、4.2、および4.4で定義されている一般的なモデルは、SATOPに完全に適用されます。
The native service addressed in this document is a special case of the bit stream payload type defined in Section 3.3.3 of [RFC3985].
このドキュメントで扱われているネイティブサービスは、[RFC3985]のセクション3.3.3で定義されているビットストリームペイロードタイプの特別なケースです。
The Network Synchronization reference model and deployment scenarios for emulation of TDM services are described in [RFC4197], Section 4.3.
TDMサービスのエミュレーションのためのネットワーク同期リファレンスモデルと展開シナリオは、[RFC4197]、セクション4.3で説明されています。
This specification describes edge-to-edge emulation of the following TDM services described in [G.702]:
この仕様では、[G.702]で説明されている次のTDMサービスのエッジツーエッジエミュレーションについて説明します。
1. E1 (2048 kbit/s) 2. T1 (1544 kbit/s); this service is also known as DS1 3. E3 (34368 kbit/s) 4. T3 (44736 kbit/s); this service is also known as DS3
1. E1（2048 kbit/s）2。T1（1544 kbit/s）;このサービスはDS1 3としても知られています。E3（34368 kbit/s）4。T3（44736 kbit/s）;このサービスはDS3としても知られています
The protocol used for emulation of these services does not depend on the method in which attachment circuits are delivered to the PEs. For example, a T1 attachment circuit is treated in the same way regardless of whether it is delivered to the PE on copper [G.703], multiplexed in a T3 circuit [T1.107], mapped into a virtual tributary of a SONET/SDH circuit [G.707], or carried over an ATM network using unstructured ATM Circuit Emulation Service (CES) [ATM-CES]. Termination of any specific "carrier layers" used between the PE and CE is performed by an appropriate NSP.
これらのサービスのエミュレーションに使用されるプロトコルは、アタッチメント回路がPESに配信される方法に依存しません。たとえば、T1アタッチメント回路は、T3回路[T1.107]で多重化された銅のPEに送達されるかどうかに関係なく、同じ方法で処理され、SONET/の仮想支流にマッピングされます。SDH回路[G.707]、または非構造化ATM回路エミュレーションサービス（CES）[ATM-CES]を使用してATMネットワークを介して運ばれました。PEとCEの間で使用される特定の「キャリア層」の終了は、適切なNSPによって実行されます。
The basic format of SAToP packets is shown in Figure 1 below.
SATOPパケットの基本形式を以下の図1に示します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
| PSN and PW demultiplexing layer headers |
| ... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| ... |
+-- --+
| SAToP Encapsulation Header |
+-- --+
| ... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| ... |
| TDM data (Payload) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. Basic SAToP Packet Format
図1.基本的なSATOPパケット形式
Both UDP and L2TPv3 [RFC3931] can provide the PW demultiplexing mechanisms for SAToP PWs over an IPv4/IPv6 PSN. The PW label provides the demultiplexing function for an MPLS PSN as described in Section 5.4.2 of [RFC3985].
UDPとL2TPV3 [RFC3931]はどちらも、IPv4/IPv6 PSNを介したSATOP PWSのPW脱臼メカニズムを提供できます。PWラベルは、[RFC3985]のセクション5.4.2で説明されているように、MPLS PSNの非gultiplexing関数を提供します。
The total size of a SAToP packet for a specific PW MUST NOT exceed path MTU between the pair of PEs terminating this PW. SAToP implementations using IPv4 PSN MUST mark the IPv4 datagrams they generate as "Don't Fragment" [RFC791] (see also [PWE3-FRAG]).
特定のPWのSATOPパケットの合計サイズは、このPWを終了するPEのペア間のパスMTUを超えてはなりません。IPv4 PSNを使用したSATOP実装では、生成するIPv4データグラムを「Do n't Fragment」[RFC791]としてマークする必要があります（[PWE3-FRAG]も参照）。
The SAToP header MUST contain the SAToP Control Word (4 bytes) and MAY also contain a fixed RTP header [RFC3550]. If the RTP header is included in the SAToP header, it MUST immediately follow the SAToP control word in all cases except UDP multiplexing, where it MUST precede it (see Figures 2a, 2b, and 2c below).
SATOPヘッダーには、SATOPコントロールワード（4バイト）が含まれている必要があり、固定RTPヘッダー[RFC3550]も含まれている場合があります。RTPヘッダーがSATOPヘッダーに含まれている場合、UDPマルチプレックスを除くすべての場合、SATOPコントロールワードをすぐに実行する必要があります。
Note: Such an arrangement complies with the traditional usage of RTP for the IPv4/IPv6 PSN with UDP multiplexing while making SAToP PWs Equal Cost Multi-Path (ECMP)-safe for the MPLS PSN by providing for PW-IP packet discrimination (see [RFC3985], Section 5.4.3). Furthermore, it facilitates seamless stitching of L2TPv3-based and MPLS-based segments of SAToP PWs (see [PWE3-MS]).
注：このような配置は、UDPマルチプレックスを伴うIPv4/IPv6 PSNのRTPの従来の使用に準拠しています。RFC3985]、セクション5.4.3）。さらに、SATOP PWSのL2TPV3ベースのセグメントとMPLSベースのセグメントのシームレスなステッチを容易にします（[PWE3-MS]を参照）。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
| IPv4/IPv6 and UDP (PW demultiplexing layer) headers |
| ... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| |
+-- OPTIONAL --+
| |
+-- Fixed RTP Header (see [RFC3550]) --+
| |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SAToP Control Word |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| ... |
| TDM data (Payload) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2a. SAToP Packet Format for an IPv4/IPv6 PSN with UDP PW Demultiplexing
図2a。UDP PW Demultiplexingを備えたIPv4/IPv6 PSNのSATOPパケット形式
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
| IPv4/IPv6 and L2TPv3 (PW demultiplexing layer) headers |
| ... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SAToP Control Word |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| |
+-- OPTIONAL --+
| |
+-- Fixed RTP Header (see [RFC3550]) --+
| |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| ... |
| TDM data (Payload) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2b. SAToP Packet Format for an IPv4/IPv6 PSN with L2TPv3 PW Demultiplexing
図2b。L2TPV3 PW DEMULTIPLEXINGを使用したIPv4/IPv6 PSNのSATOPパケット形式
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
| MPLS Label Stack |
| ... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SAToP Control Word |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| |
+-- OPTIONAL --+
| |
+-- Fixed RTP Header (see [RFC3550]) --+
| |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| ... |
| TDM data (Payload) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2c. SAToP Packet Format for an MPLS PSN
図2c。MPLS PSNのSATOPパケット形式
Usage of the SAToP control word allows:
SATOPコントロールワードの使用は、次のことを許可します。
1. Detection of packet loss or misordering 2. Differentiation between the PSN and attachment circuit problems as causes for the outage of the emulated service 3. PSN bandwidth conservation by not transferring invalid data (AIS) 4. Signaling of faults detected at the PW egress to the PW ingress.
1. パケットの損失または誤った順序の検出2.エミュレートサービスの停止の原因としてのPSNとアタッチメント回路の問題の区別3. PSN無効なデータ（AIS）を転送しないことによる帯域幅保存（AIS）4。PWエグレスで検出された障害のシグナル伝達PWイングレス。
The structure of the SAToP Control Word is shown in Figure 3 below.
SATOPコントロールワードの構造を以下の図3に示します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0|L|R|RSV|FRG| LEN | Sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3. Structure of the SAToP Control Word
図3. SATOPコントロールワードの構造
The use of Bits 0 to 3 is described in [RFC4385]. These bits MUST be set to zero unless they are being used to indicate the start of an Associated Channel Header (ACH). An ACH is needed if the state of the SAToP PW is being monitored using Virtual Circuit Connectivity Verification [PWE3-VCCV].
0〜3のビットの使用は[RFC4385]で説明されています。これらのビットは、関連するチャネルヘッダー（ACH）の開始を示すために使用されない限り、ゼロに設定する必要があります。SATOP PWの状態が仮想回路接続検証[PWE3-VCCV]を使用して監視されている場合、AChが必要です。
L - If set, indicates that TDM data carried in the payload is invalid due to an attachment circuit fault. When the L bit is set the payload MAY be omitted in order to conserve bandwidth. The CE-bound IWF MUST play out an appropriate amount of filler data regardless of the payload size. Once set, if the fault is rectified, the L bit MUST be cleared.
L-設定されている場合、ペイロードに携帯されているTDMデータがアタッチメント回路障害のために無効であることを示します。Lビットが設定されると、帯域幅を保存するためにペイロードが省略される場合があります。CEバウンドIWFは、ペイロードサイズに関係なく、適切な量のフィラーデータを再生する必要があります。設定したら、障害が修正されている場合、Lビットをクリアする必要があります。
Note: This document does not specify which TDM fault conditions are treated as invalidating the data carried in the SAToP packets. Possible examples include, but are not limited to LOS and AIS.
注：このドキュメントでは、どのTDM障害条件がSATOPパケットに掲載されているデータを無効にするものとして扱われるかを指定していません。考えられる例には、LOSとAISが含まれますが、これらに限定されません。
R - If set by the PSN-bound IWF, indicates that its local CE-bound IWF is in the packet loss state, i.e., has lost a preconfigured number of consecutive packets. The R bit MUST be cleared by the PSN-bound IWF once its local CE-bound IWF has exited the packet loss state, i.e., has received a preconfigured number of consecutive packets.
R- PSNバウンドIWFによって設定された場合、そのローカルCEに縛られたIWFがパケット損失状態にあることを示します。つまり、事前に構成された数の連続したパケットを失いました。ローカルCEバウンドIWFがパケット損失状態を終了すると、PSNバインドIWFによってRビットをクリアする必要があります。つまり、事前に設定された数の連続したパケットを受け取りました。
RSV and FRG (bits 6 to 9) - MUST be set to 0 by the PSN-bound IWF and MUST be ignored by the CE-bound IWF. RSV is reserved. FRG is fragmentation; see [PWE3-FRAG].
RSVおよびFRG（ビット6〜9） - PSNバウンドIWFによって0に設定する必要があり、CEバウンドIWFで無視する必要があります。RSVは予約されています。FRGは断片化です。[pwe3-frag]を参照してください。
LEN (bits 10 to 15) - MAY be used to carry the length of the SAToP packet (defined as the size of the SAToP header + the payload size) if it is less than 64 bytes, and MUST be set to zero otherwise. When the LEN field is set to 0, the preconfigured size of the SAToP packet payload MUST be assumed to be as described in Section 5.1, and if the actual packet size is inconsistent with this length, the packet MUST be considered malformed.
LEN（ビット10〜15） - SATOPパケットの長さ（SATOPヘッダーのサイズとして定義されます）を64バイト未満の場合は、それ以外の場合はゼロに設定する必要があります。LENフィールドが0に設定されている場合、SATOPパケットペイロードの事前に設定されたサイズは、セクション5.1で説明されていると仮定する必要があり、実際のパケットサイズがこの長さと矛盾している場合、パケットは奇形と見なされなければなりません。
Sequence number - used to provide the common PW sequencing function as well as detection of lost packets. It MUST be generated in accordance with the rules defined in Section 5.1 of [RFC3550] for the RTP sequence number:
シーケンス番号 - 共通のPWシーケンス関数と失われたパケットの検出を提供するために使用されます。RTPシーケンス番号の[RFC3550]のセクション5.1で定義されているルールに従って生成する必要があります。
o Its space is a 16-bit unsigned circular space o Its initial value SHOULD be random (unpredictable).
o そのスペースは、16ビットの署名されていない円形スペースです。その初期値はランダムでなければなりません（予測不可能）。
It MUST be incremented with each SAToP data packet sent in the specific PW.
特定のPWで送信される各SATOPデータパケットでインクリメントする必要があります。
When RTP is used, the following fields of the fixed RTP header (see [RFC3550], Section 5.1) MUST be set to zero: P (padding), X (header extension), CC (CSRC count), and M (marker).
RTPを使用する場合、固定RTPヘッダーの次のフィールド（[RFC3550]を参照、セクション5.1）はゼロに設定する必要があります：P（パディング）、X（ヘッダー拡張）、CC（CSRCカウント）、およびM（マーカー）。
The PT (payload type) field is used as follows:
PT（ペイロードタイプ）フィールドは次のように使用されます。
1. One PT value MUST be allocated from the range of dynamic values (see [RTP-TYPES]) for each direction of the PW. The same PT value MAY be reused for both directions of the PW and also reused between different PWs.
1. PWの各方向に対して、1つのPT値を動的値の範囲（[RTPタイプ]を参照）から割り当てる必要があります。同じPT値がPWの両方向に再利用され、異なるPW間で再利用される場合があります。
2. The PSN-bound IWF MUST set the PT field in the RTP header to the allocated value.
2. PSNバウンドIWFは、RTPヘッダーにPTフィールドを割り当てられた値に設定する必要があります。
3. The CE-bound IWF MAY use the received value to detect malformed packets.
3. CEバウンドIWFは、受信された値を使用して不正なパケットを検出する場合があります。
The sequence number MUST be the same as the sequence number in the SAToP control word.
シーケンス番号は、SATOPコントロールワードのシーケンス番号と同じでなければなりません。
The RTP timestamps are used for carrying timing information over the network. Their values are generated in accordance with the rules established in [RFC3550].
RTPタイムスタンプは、ネットワーク上でタイミング情報を運ぶために使用されます。それらの値は、[RFC3550]で確立されたルールに従って生成されます。
The frequency of the clock used for generating timestamps MUST be an integer multiple of 8 kHz. All implementations of SAToP MUST support the 8 kHz clock. Other multiples of 8 kHz MAY be used.
タイムスタンプの生成に使用されるクロックの頻度は、8 kHzの整数倍でなければなりません。SATOPのすべての実装は、8 kHzクロックをサポートする必要があります。8 kHzの他の倍数を使用できます。
The SSRC (synchronization source) value in the RTP header MAY be used for detection of misconnections, i.e., incorrect interconnection of attachment circuits.
RTPヘッダーのSSRC（同期ソース）値は、誤った接続の検出に使用できます。つまり、アタッチメント回路の誤った相互接続です。
Timestamp generation MAY be used in the following modes:
タイムスタンプの生成は、次のモードで使用できます。
1. Absolute mode: The PSN-bound IWF sets timestamps using the clock recovered from the incoming TDM attachment circuit. As a consequence, the timestamps are closely correlated with the sequence numbers. All SAToP implementations that support usage of the RTP header MUST support this mode. 2. Differential mode: Both IWFs have access to a common high-quality timing source, and this source is used for timestamp generation. Support of this mode is OPTIONAL.
1. 絶対モード：PSNバウンドIWFは、着信TDMアタッチメント回路から回復したクロックを使用してタイムスタンプを設定します。結果として、タイムスタンプはシーケンス番号と密接に相関しています。RTPヘッダーの使用をサポートするすべてのSATOP実装は、このモードをサポートする必要があります。2.差動モード：両方のIWFは、共通の高品質のタイミングソースにアクセスでき、このソースはタイムスタンプの生成に使用されます。このモードのサポートはオプションです。
Usage of the fixed RTP header in a SAToP PW and all the options associated with its usage (the timestamping clock frequency, the timestamping mode, selected PT and SSRC values) MUST be agreed upon between the two SAToP IWFs during PW setup as described in [TDM-CONTROL]. Other, RTP-specific methods (e.g., see [RFC3551]) MUST NOT be used.
SATOP PWでの固定RTPヘッダーの使用およびその使用に関連するすべてのオプション（タイムスタンプクロック周波数、タイムスタンプモード、選択されたPTおよびSSRC値）は、[PWセットアップ中に2つのSATOP IWFの間で[）]で説明されています。TDMコントロール]。その他のRTP固有の方法（例：[RFC3551]を参照）を使用しないでください。
In order to facilitate handling of packet loss in the PSN, all packets belonging to a given SAToP PW are REQUIRED to carry a fixed number of bytes filled with TDM data received from the attachment circuit. The packet payload size MUST be defined during the PW setup, MUST be the same for both directions of the PW, and MUST remain unchanged for the lifetime of the PW.
PSNでのパケット損失の処理を容易にするために、特定のSATOP PWに属するすべてのパケットは、アタッチメント回路から受信したTDMデータで満たされた固定数のバイトを運ぶために必要です。パケットペイロードサイズは、PWのセットアップ中に定義する必要があり、PWの両方向について同じでなければならず、PWの寿命は変わらない必要があります。
The CE-bound and PSN-bound IWFs MUST agree on SAToP packet payload size during PW setup (default payload size values defined below guarantee that such an agreement is always possible). The SAToP packet payload size can be exchanged over the PWE3 control protocol ([TDM-CONTROL]) by using the Circuit Emulation over Packet (CEP)/TDM Payload Bytes sub-TLV of the Interface Parameters TLV ([RFC4446]).
CEバウンドおよびPSNバウンドIWFSは、PWセットアップ中のSATOPパケットペイロードサイズに同意する必要があります（以下に定義されているデフォルトのペイロードサイズ値は、そのような契約が常に可能であることを保証します）。SATOPパケットペイロードサイズは、インターフェイスパラメーターTLV（[RFC4446]）の回路エミュレーション（CEP）/TDMペイロードバイトサブTLVを使用することにより、PWE3コントロールプロトコル（[TDM-Control]）を介して交換できます。
SAToP uses the following ordering for packetization of the TDM data:
SATOPは、TDMデータのパケット化のために次の注文を使用します。
o The order of the payload bytes corresponds to their order on the attachment circuit.
o ペイロードバイトの順序は、アタッチメント回路での順序に対応します。
o Consecutive bits coming from the attachment circuit fill each payload byte starting from most significant bit to least significant.
o アタッチメント回路から来る連続したビットは、最も重要なビットから最も重要なものまでの各ペイロードバイトを埋めます。
All SAToP implementations MUST be capable of supporting the following payload sizes:
すべてのSATOP実装は、次のペイロードサイズをサポートできる必要があります。
o E1 - 256 bytes o T1 - 192 bytes o E3 and T3 - 1024 bytes.
o E1-256バイトO T1-192バイトO E3およびT3-1024バイト。
Notes:
ノート：
1. Whatever the selected payload size, SAToP does not assume alignment to any underlying structure imposed by TDM framing (byte, frame, or multiframe alignment). 2. When the L bit in the SAToP control word is set, SAToP packets MAY omit invalid TDM data in order to conserve PSN bandwidth. 3. Payload sizes that are multiples of 47 bytes MAY be used in conjunction with unstructured ATM-CES [ATM-CES].
1. 選択したペイロードサイズが何であれ、SATOPは、TDMフレーミング（バイト、フレーム、またはマルチフレームアライメント）によって課される基礎となる構造へのアラインメントを想定していません。2. SATOPコントロールワードのLビットが設定されている場合、SATOPパケットは、PSN帯域幅を保存するために無効なTDMデータを省略する場合があります。3. 47バイトの倍数のペイロードサイズは、非構造化ATM-CES [ATM-CES]と組み合わせて使用できます。
An unstructured T1 attachment circuit is sometimes provided already padded to an integer number of bytes, as described in Annex B of [G.802]. This occurs when the T1 is de-mapped from a SONET/SDH virtual tributary/container, or when it is de-framed by a dual-mode E1/T1 framer.
[G.802]の付録Bで説明されているように、非構造化されたT1アタッチメント回路は、整数数のバイトにすでにパッドで提供されることがあります。これは、T1がSONET/SDH仮想支流/コンテナからマッピングされている場合、またはデュアルモードE1/T1フレーマーによってフレーム化されている場合に発生します。
In order to facilitate operation in such cases, SAToP defines a special "octet-aligned T1" transport mode. In this mode, the SAToP payload consists of a number of 25-byte subframes, each subframe carrying 193 bits of TDM data and 7 bits of padding. This mode is depicted in Figure 4 below.
そのような場合の操作を容易にするために、SATOPは特別な「オクテットアライメントT1」輸送モードを定義します。このモードでは、SATOPペイロードは多くの25バイトのサブフレームで構成され、各サブフレームは193ビットのTDMデータと7ビットのパディングを搭載しています。このモードは、以下の図4に示されています。
| 1 | 2 | ... | 25 |
|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| ... |0 1 2 3 4 5 6 7|
|=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| TDM Data | padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ................................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TDM Data | padding |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Figure 4. SAToP Payload Format for Octet-Aligned T1 Transport
図4.オクテットに配置されたT1輸送のSATOPペイロード形式
Notes:
ノート：
1. No alignment with the framing structure that may be imposed on the T1 bit-stream is implied. 2. An additional advantage of the octet-aligned T1 transport mode is the ability to select the SAToP packetization latency as an arbitrary integer multiple of 125 microseconds.
1. T1ビットストリームに課される可能性のあるフレーミング構造とのアライメントは暗示されていません。2.オクテットに配置されたT1トランスポートモードの追加の利点は、125マイクロ秒の任意の整数倍としてSATOPパケット化レイテンシを選択する機能です。
Support of the octet-aligned T1 transport mode is OPTIONAL. An octet-aligned T1 SAToP PW is not interoperable with a T1 SAToP PW that carries a non-aligned bit-stream, as described in the previous section.
Octetに並べられたT1トランスポートモードのサポートはオプションです。Octetに並べられたT1 SATOP PWは、前のセクションで説明したように、非彩られたビットストリームを搭載したT1 SATOP PWと相互運用できません。
Implementations supporting octet-aligned T1 transport mode MUST be capable of supporting a payload size of 200 bytes (i.e., a payload of eight 25-byte subframes) corresponding to precisely 1 millisecond of TDM data.
Octetに並べられたT1トランスポートモードをサポートする実装は、正確に1ミリ秒のTDMデータに対応する200バイトのペイロードサイズ（つまり、8つの25バイトサブフレームのペイロード）をサポートできる必要があります。
Edge-to-edge emulation of a TDM service using SAToP is only possible when the two PW attachment circuits are of the same type (T1, E1, T3, E3). The service type is exchanged at PW setup as described in [RFC4447].
SATOPを使用したTDMサービスのエッジツーエッジエミュレーションは、2つのPWアタッチメント回路が同じタイプ（T1、E1、T3、E3）の場合にのみ可能です。[RFC4447]で説明されているように、サービスタイプはPWセットアップで交換されます。
Once the PW is set up, the PSN-bound SAToP IWF operates as follows:
PWがセットアップされると、PSNバウンドSATOP IWFは次のように動作します。
TDM data is packetized using the configured number of payload bytes per packet.
TDMデータは、パケットあたりのペイロードバイトの構成数を使用してパケット化されます。
Sequence numbers, flags, and timestamps (if the RTP header is used) are inserted in the SAToP headers.
シーケンス番号、フラグ、およびタイムスタンプ（RTPヘッダーが使用されている場合）がSATOPヘッダーに挿入されます。
SAToP, PW demultiplexing layer, and PSN headers are prepended to the packetized service data.
SATOP、PW Demultiplexingレイヤー、およびPSNヘッダーは、パケット化されたサービスデータに加えられます。
The resulting packets are transmitted over the PSN.
結果のパケットはPSNを介して送信されます。
The CE-bound SAToP IWF SHOULD include a jitter buffer where the payload of the received SAToP packets is stored prior to play-out to the local TDM attachment circuit. The size of this buffer SHOULD be locally configurable to allow accommodation to the PSN-specific packet delay variation.
CEバウンドSATOP IWFには、受信したSATOPパケットのペイロードがローカルTDMアタッチメント回路に再生前に保存されるジッターバッファーを含める必要があります。このバッファーのサイズは、PSN固有のパケット遅延変動への調節を可能にするためにローカルで構成可能でなければなりません。
The CE-bound SAToP IWF SHOULD use the sequence number in the control word for detection of lost and misordered packets. If the RTP header is used, the RTP sequence numbers MAY be used for the same purposes.
CEバウンドSATOP IWFは、紛失および誤ったパケットを検出するために、コントロールワードでシーケンス番号を使用する必要があります。RTPヘッダーを使用する場合、RTPシーケンス番号を同じ目的に使用できます。
Note: With SAToP, a valid sequence number can be always found in bits 16 - 31 of the first 32-bit word immediately following the PW demultiplexing header regardless of the specific PSN type, multiplexing method, usage or non-usage of the RTP header, etc. This approach simplifies implementations supporting multiple encapsulation types as well as implementation of multi-segment (MS) PWs using different encapsulation types in different segments.
注：SATOPを使用すると、特定のPSNタイプ、多重化方法、使用法または非使用量に関係なく、PW Degultiplexingヘッダーの直後の最初の32ビット単語のビット16〜31で有効なシーケンス番号を常に見つけることができます。など。このアプローチは、複数のカプセル化タイプをサポートする実装と、さまざまなセグメントの異なるカプセル化タイプを使用してマルチセグメント（MS）PWの実装を簡素化します。
The CE-bound SAToP IWF MAY reorder misordered packets. Misordered packets that cannot be reordered MUST be discarded and treated as lost.
CEバウンドSATOP IWFは、誤ったパケットを再注文する場合があります。並べ替えられない誤ったパケットは、廃棄され、失われたものとして扱わなければなりません。
The payload of the received SAToP packets marked with the L bit set SHOULD be replaced by the equivalent amount of the "all ones" pattern even if it has not been omitted.
Lビットセットでマークされた受信したSATOPパケットのペイロードは、省略されていなくても、「すべてのもの」パターンの同等の量に置き換える必要があります。
The payload of each lost SAToP packet MUST be replaced with the equivalent amount of the replacement data. The contents of the replacement data are implementation-specific and MAY be locally configurable. By default, all SAToP implementations MUST support generation of the "all ones" pattern as the replacement data. Before a PW has been set up and after a PW has been torn down, the IWF MUST play out the "all ones" pattern to its TDM attachment circuit.
紛失した各SATOPパケットのペイロードは、交換データの同等の量に置き換える必要があります。交換データの内容は実装固有であり、ローカルで構成可能な場合があります。デフォルトでは、すべてのSATOP実装は、「すべてのもの」パターンの生成を交換データとしてサポートする必要があります。PWがセットアップされ、PWが取り壊された後、IWFはTDMアタッチメント回路の「すべてのもの」パターンを再生する必要があります。
Once the PW has been set up, the CE-bound IWF begins to receive SAToP packets and to store their payload in the jitter buffer but continues to play out the "all ones" pattern to its TDM attachment circuit. This intermediate state persists until a preconfigured amount of TDM data (usually half of the jitter buffer) has been received in consecutive SAToP packets or until a preconfigured intermediate state timer (started when the PW setup is completed) expires.
PWがセットアップされると、CEバウンドIWFはSATOPパケットを受け取り、ペイロードをジッターバッファーに保存し始めますが、TDMアタッチメント回路に「すべてのもの」パターンを再生し続けます。この中間状態は、事前に設定された量のTDMデータ（通常はジッターバッファの半分）が連続したSATOPパケットで受信されるか、事前に設定された中間状態タイマー（PWセットアップが完了したときに開始）が有効になるまで持続します。
Once the preconfigured amount of the TDM data has been received, the CE-bound SAToP IWF enters its normal operation state where it continues to receive SAToP packets and to store their payload in the jitter buffer while playing out the contents of the jitter buffer in accordance with the required clock. In this state, the CE-bound IWF performs clock recovery, MAY monitor PW defects, and MAY collect PW performance monitoring data.
TDMデータの事前に設定された量を受信すると、CEバウンドSATOP IWFは通常の動作状態に入り、SATOPパケットを受け取り続け、ジッターバッファーのコンテンツを再生しながらペイロードをジッターバッファーに保存し続けます。必要なクロック付き。この状態では、CEバウンドIWFはクロック回復を実行し、PWの欠陥を監視し、PWパフォーマンス監視データを収集する場合があります。
If the CE-bound SAToP IWF detects loss of a preconfigured number of consecutive packets or if the intermediate state timer expires before the required amount of TDM data has been received, it enters its packet loss state. While in this state, the local PSN-bound SAToP IWF SHOULD mark every packet it transmits with the R bit set. The CE-bound SAToP IWF leaves this state and transitions to the normal one once a preconfigured number of consecutive valid SAToP packets have been received. (Successfully reordered packets contribute to the count of consecutive packets.)
CEに縛られたSATOP IWFが、事前に設定された数の連続したパケットの損失を検出した場合、または中間状態タイマーが必要な量のTDMデータを受信する前に期限切れになった場合、パケット損失状態に入ります。この状態では、ローカルPSNバインドSATOP IWFは、Rビットセットで送信するすべてのパケットをマークする必要があります。CEバウンドSATOP IWFはこの状態を離れ、通常の状態に移行します。（並べ替えられたパケットは、連続したパケットの数に貢献します。）
The CE-bound SAToP IWF MUST provide an indication of TDM data validity to the CE. This can be done by transporting or by generating the native AIS indication. As mentioned above, T3 AIS cannot be detected or generated by structure-agnostic means, and hence a structure-aware NSP MUST be used when generating a valid AIS pattern.
CEバウンドSATOP IWFは、CEにTDMデータの有効性を示している必要があります。これは、輸送またはネイティブAISの表示を生成することによって行うことができます。上記のように、T3 AIは構造と存在する手段で検出または生成することはできないため、有効なAISパターンを生成するときは構造認識NSPを使用する必要があります。
In addition to the packet loss state of the CE-bound SAToP IWF defined above, it MAY detect the following defects:
上記で定義されたCEバウンドSATOP IWFのパケット損失状態に加えて、次の欠陥を検出する場合があります。
o Stray packets o Malformed packets o Excessive packet loss rate o Buffer overrun o Remote packet loss
o 迷ったパケットo奇形パケットo過剰なパケット損失率oバッファーオーバーランoリモートパケット損失
Corresponding to each defect is a defect state of the IWF, a detection criterion that triggers transition from the normal operation state to the appropriate defect state, and an alarm that MAY be reported to the management system and thereafter cleared. Alarms are only reported when the defect state persists for a preconfigured amount of time (typically 2.5 seconds) and MUST be cleared after the corresponding defect is undetected for a second preconfigured amount of time (typically 10 seconds). The trigger and release times for the various alarms may be independent.
各欠陥に対応するのは、IWFの欠陥状態、通常の動作状態から適切な欠陥状態への移行をトリガーする検出基準、および管理システムに報告され、その後クリアされる可能性のあるアラームです。アラームは、欠陥状態が事前に設定された時間（通常は2.5秒）の持続した場合にのみ報告され、対応する欠陥が2秒前に設定された時間（通常は10秒）で検出されない後にクリアする必要があります。さまざまなアラームのトリガーとリリース時間は独立している場合があります。
Stray packets MAY be detected by the PSN and PW demultiplexing layers. When RTP is used, the SSRC field in the RTP header MAY be used for this purpose as well. Stray packets MUST be discarded by the CE-bound IWF, and their detection MUST NOT affect mechanisms for detection of packet loss.
迷ったパケットは、PSNおよびPWの非拡張層によって検出される場合があります。RTPを使用すると、RTPヘッダーのSSRCフィールドもこの目的に使用できます。迷ったパケットは、CEに縛られたIWFによって破棄する必要があり、それらの検出はパケット損失の検出のためのメカニズムに影響を与えてはなりません。
Malformed packets are detected by mismatch between the expected packet size (taking the value of the L bit into account) and the actual packet size inferred from the PSN and PW demultiplexing layers. When RTP is used, lack of correspondence between the PT value and that allocated for this direction of the PW MAY also be used for this purpose. Malformed in-order packets MUST be discarded by the CE-bound IWF and replacement data generated as with lost packets.
不正なパケットは、予想されるパケットサイズ（Lビットの値を考慮に入れる）とPSNおよびPWの非脱重レイヤーから推測される実際のパケットサイズの間の不一致によって検出されます。RTPを使用すると、PT値とPWのこの方向に割り当てられたものとの対応の欠如も、この目的に使用される場合があります。奇形の順序パケットは、失われたパケットと同様に生成されたCEバウンドIWFおよび交換データによって破棄する必要があります。
Excessive packet loss rate is detected by computing the average packet loss rate over a configurable amount of times and comparing it with a preconfigured threshold.
過度のパケット損失率は、構成可能な回数にわたって平均パケット損失率を計算し、それを事前に構成されたしきい値と比較することにより検出されます。
Buffer overrun is detected in the normal operation state when the jitter buffer of the CE-bound IWF cannot accommodate newly arrived SAToP packets.
CEバウンドIWFのジッターバッファーが新しく到着したSATOPパケットに対応できない場合、通常の動作状態でバッファオーバーランが検出されます。
Remote packet loss is indicated by reception of packets with their R bit set.
リモートパケットの損失は、Rビットセットでパケットを受信することによって示されます。
Performance monitoring (PM) parameters are routinely collected for TDM services and provide an important maintenance mechanism in TDM networks. The ability to collect compatible PM parameters for SAToP PWs enhances their maintenance capabilities.
パフォーマンス監視（PM）パラメーターは、TDMサービス用に日常的に収集され、TDMネットワークで重要なメンテナンスメカニズムを提供します。SATOP PWSの互換性のあるPMパラメーターを収集する機能により、メンテナンス機能が向上します。
Collection of the SAToP PW performance monitoring parameters is OPTIONAL and, if implemented, is only performed after the CE-bound IWF has exited its intermediate state.
SATOP PWパフォーマンス監視パラメーターのコレクションはオプションであり、実装されている場合、CEバウンドIWFが中間状態を終了した後にのみ実行されます。
SAToP defines error events, errored blocks, and defects as follows:
SATOPは、次のようにエラーイベント、エラーブロック、および欠陥を定義します。
o A SAToP error event is defined as insertion of a single replacement packet into the jitter buffer (replacement of payload of SAToP packets with the L bit set is not considered insertion of a replacement packet).
o SATOPエラーイベントは、1つの交換用パケットをジッターバッファーに挿入することとして定義されます（LビットセットでSATOPパケットのペイロードの交換は、交換パケットの挿入とは見なされません）。
o A SAToP errored data block is defined as a block of data played out to the TDM attachment circuit and of a size defined in accordance with the [G.826] rules for the corresponding TDM service that has experienced at least one SAToP error event.
o SATOPエラーされたデータブロックは、TDMアタッチメント回路に実行されるデータのブロックとして定義され、少なくとも1つのSATOPエラーイベントを経験した対応するTDMサービスの[G.826]ルールに従って定義されたサイズとして定義されます。
o A SAToP defect is defined as the packet loss state of the CE-bound SAToP IWF.
o SATOP欠陥は、CEバウンドSATOP IWFのパケット損失状態として定義されます。
The SAToP PW PM parameters (Errored, Severely Errored, and Unavailable Seconds) are derived from these definitions in accordance with [G.826].
SATOP PW PMパラメーター（エラー、重度のエラー、および利用できない秒）は、[G.826]に従ってこれらの定義から派生しています。
SAToP SHOULD employ existing QoS capabilities of the underlying PSN.
SATOPは、基礎となるPSNの既存のQoS機能を使用する必要があります。
If the PSN providing connectivity between PE devices is Diffserv-enabled and provides a PDB [RFC3086] that guarantees low jitter and low loss, the SAToP PW SHOULD use this PDB in compliance with the admission and allocation rules the PSN has put in place for that PDB (e.g., marking packets as directed by the PSN).
PEデバイス間で接続を提供するPSNがDiffServ対応であり、低ジッターと低損失を保証するPDB [RFC3086]を提供する場合、SATOP PWは、PSNがそのために設定した入学および割り当て規則に準拠してこのPDBを使用する必要があります。PDB（例：PSNが指示したマークパケット）。
If the PSN is Intserv-enabled, then GS (Guaranteed Service) [RFC2212] with the appropriate bandwidth reservation SHOULD be used in order to provide a bandwidth guarantee equal or greater than that of the aggregate TDM traffic.
PSNがIntServ対応の場合、適切な帯域幅予約を備えたGS（保証サービス）[RFC2212]を使用して、合計TDMトラフィックの帯域幅保証を提供するために使用する必要があります。
As explained in [RFC3985], the PSN carrying the PW may be subject to congestion. SAToP PWs represent inelastic constant bit-rate (CBR) flows and cannot respond to congestion in a TCP-friendly manner prescribed by [RFC2914], although the percentage of total bandwidth they consume remains constant.
[RFC3985]で説明されているように、PWを運ぶPSNにはうっ血の影響を受ける可能性があります。SATOP PWSは、非弾性一定のビットレート（CBR）フローを表し、[RFC2914]で規定されたTCPに優しい方法で輻輳に応答することはできませんが、消費する総帯域幅の割合は一定のままです。
Unless appropriate precautions are taken, undiminished demand of bandwidth by SAToP PWs can contribute to network congestion that may impact network control protocols.
適切な予防措置が講じられない限り、SATOP PWSによる帯域幅の縮小された需要は、ネットワーク制御プロトコルに影響を与える可能性のあるネットワーク渋滞に寄与する可能性があります。
Whenever possible, SAToP 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 supporting Guaranteed Service (GS) [RFC2212] and DiffServ-enabled domains [RFC2475] supporting Expedited Forwarding (EF) [RFC3246] provide examples of such PSNs. Such mechanisms will negate, to some degree, the effect of the SAToP PWs on the neighboring streams. In order to facilitate boundary traffic conditioning of SAToP traffic over IP PSNs, the SAToP IP packets SHOULD NOT use the DiffServ Code Point (DSCP) value reserved for the Default Per-Hop Behavior (PHB) [RFC2474].
可能な場合はいつでも、帯域幅の予約と入学制御または転送の優先順位付けと境界トラフィックコンディショニングメカニズムを提供するトラフィック設計のPSNを介して、SATOP PWを運ぶ必要があります。保証されたサービス（GS）[RFC2212]およびDiffServ対応ドメイン[RFC2475]をサポートするIntServ対応ドメイン（EF）[RFC3246]をサポートするPSNの例を提供します。このようなメカニズムは、隣接するストリームに対するSATOP PWSの効果をある程度無効にします。IP PSNS上のSATOPトラフィックの境界トラフィックコンディショニングを容易にするために、SATOP IPパケットは、デフォルトのHOP PERホップ動作（PHB）[RFC2474]に予約されたDiffServコードポイント（DSCP）値を使用しないでください。
If SAToP PWs run over a PSN providing best-effort service, they SHOULD monitor packet loss in order to detect "severe congestion". If such a condition is detected, a SAToP PW SHOULD shut down bi-directionally for some period of time as described in Section 6.5 of [RFC3985].
SATOP PWSがPSNを介して最良のエフォルトサービスを提供する場合、「重度の混雑」を検出するためにパケット損失を監視する必要があります。そのような条件が検出された場合、SATOP PWは[RFC3985]のセクション6.5で説明されているように、しばらくの間双方向にシャットダウンする必要があります。
Note that:
ご了承ください：
1. The SAToP IWF can inherently provide packet loss measurement since the expected rate of arrival of SAToP packets is fixed and known
1. SATOP IWFは、SATOPパケットの到着の予想速度が固定されており、既知であるため、本質的にパケット損失測定を提供できます。
2. The results of the SAToP packet loss measurement may not be a reliable indication of presence or absence of severe congestion if the PSN provides enhanced delivery. For example:
2. SATOPパケット損失測定の結果は、PSNが送達を強化した場合、重度の混雑の有無の信頼できる兆候ではない場合があります。例えば：
a) If SAToP traffic takes precedence over non-SAToP traffic, severe congestion can develop without significant SAToP packet loss.
a) SATOPのトラフィックが非座のトラフィックよりも優先される場合、SATOPパケットの大幅な損失なしに深刻な混雑が発生する可能性があります。
b) If non-SAToP traffic takes precedence over SAToP traffic, SAToP may experience substantial packet loss due to a short-term burst of high-priority traffic.
b) SATOPトラフィックよりも非ソップトラフィックが優先される場合、SATOPは、短期的な優先順位のトラフィックのバーストにより、かなりのパケット損失を経験する可能性があります。
3. The TDM services emulated by the SAToP PWs have high availability objectives (see [G.826]) that MUST be taken into account when deciding on temporary shutdown of SAToP PWs.
3. SATOP PWSによってエミュレートされたTDMサービスには、SATOP PWSの一時的なシャットダウンを決定する際に考慮する必要がある高可用性の目標があります（[G.826]を参照）。
This specification does not define the exact criteria for detecting "severe congestion" using the SAToP packet loss rate or the specific methods for bi-directional shutdown the SAToP PWs (when such severe congestion has been detected) and their subsequent re-start after a suitable delay. This is left for further study. However, the following considerations may be used as guidelines for implementing the SAToP severe congestion shutdown mechanism:
この仕様は、SATOPパケット損失率を使用して「重度の輻輳」を検出するための正確な基準や、SATOP PWS（そのような重度の輻輳が検出された場合）とその後の再起動後のSATOP PWSの特定の方法を定義するものではありません遅れ。これはさらなる研究のために残されています。ただし、SATOPの重度の混雑シャットダウンメカニズムを実装するためのガイドラインとして、次の考慮事項を使用できます。
1. SAToP Performance Monitoring techniques (see Section 6.4) provide entry and exit criteria for the SAToP PW "Unavailable" state that make it closely correlated with the "Unavailable" state of the emulated TDM circuit as specified in [G.826]. Using the same criteria for "severe congestion" detection may decrease the risk of shutting down the SAToP PW while the emulated TDM circuit is still considered available by the CE.
1. SATOPパフォーマンス監視手法（セクション6.4を参照）は、[G.826]で指定されているように、エミュレートされたTDM回路の「利用できない」状態と密接に相関するSATOP PWの「利用できない」状態のエントリおよび出口基準を提供します。「重度の輻輳」検出のために同じ基準を使用すると、SATOP PWをシャットダウンするリスクが低下する可能性がありますが、エミュレートされたTDM回路はまだCEが利用できると見なされます。
2. If the SAToP PW has been set up using either PWE3 control protocol [RFC4447] or L2TPv3 [RFC3931], the regular PW teardown procedures of these protocols SHOULD be used.
2. SATOP PWがPWE3コントロールプロトコル[RFC447]またはL2TPV3 [RFC3931]のいずれかを使用してセットアップされている場合、これらのプロトコルの通常のPW分解手順を使用する必要があります。
3. If one of the SAToP PW end points stops transmission of packets for a sufficiently long period, its peer (observing 100% packet loss) will necessarily detect "severe congestion" and also stop transmission, thus achieving bi-directional PW shutdown.
3. SATOP PWエンドポイントの1つが十分に長い間パケットの送信を停止する場合、そのピア（100％のパケット損失を観察）は必然的に「重度の混雑」を検出し、伝送を停止し、したがって双方向PWシャットダウンを達成します。
SAToP does not enhance or detract from the security performance of the underlying PSN; rather, it relies upon the PSN mechanisms for encryption, integrity, and authentication whenever required.
SATOPは、基礎となるPSNのセキュリティパフォーマンスを強化したり、損なったりしません。むしろ、暗号化、完全性、および認証のためのPSNメカニズムに依存しています。
SAToP PWs share susceptibility to a number of pseudowire-layer attacks and will use whatever mechanisms for confidentiality, integrity, and authentication are developed for general PWs. These methods are beyond the scope of this document.
SATOP PWSは、多くの擬似層層攻撃に対する感受性を共有し、機密性、完全性、および認証のためにあらゆるメカニズムを一般的なPWSに対して開発します。これらの方法は、このドキュメントの範囲を超えています。
Although SAToP PWs MAY employ an RTP header when explicit transfer of timing information is required, SRTP (see [RFC3711]) mechanisms are NOT RECOMMENDED as a substitute for PW layer security.
SATOP PWSは、タイミング情報の明示的な転送が必要な場合にRTPヘッダーを採用する場合がありますが、SRTP（[RFC3711]を参照）メカニズムは、PW層セキュリティの代替として推奨されません。
Misconnection detection capabilities of SAToP increase its resilience to misconfiguration and some types of denial-of-service (DoS) attacks.
SATOPの誤接合検出機能は、誤った構成といくつかの種類のサービス拒否（DOS）攻撃に対する回復力を高めます。
Random initialization of sequence numbers, in both the control word and the optional RTP header, makes known-plaintext attacks on encrypted SAToP PWs more difficult. Encryption of PWs is beyond the scope of this document.
コントロールワードとオプションのRTPヘッダーの両方で、シーケンス番号のランダムな初期化により、暗号化されたSATOP PWSに対する既知のプレーンテキスト攻撃がより困難になります。PWSの暗号化は、このドキュメントの範囲を超えています。
SAToP is an encapsulation layer intended for carrying TDM circuits (E1/T1/E3/T3) over PSN in a structure-agnostic fashion.
SATOPは、PSNを使用してTDM回路（E1/T1/E3/T3）を構造に依存しない方法で運ぶことを目的としたカプセル化層です。
SAToP fully complies with the principle of minimal intervention, thus minimizing overhead and computational power required for encapsulation.
SATOPは、最小限の介入の原則に完全に準拠しているため、カプセル化に必要なオーバーヘッドと計算能力が最小限に抑えられます。
SAToP provides sequencing and synchronization functions needed for emulation of TDM bit-streams, including detection of lost or misordered packets and appropriate compensation.
SATOPは、紛失または誤ったパケットの検出や適切な補償など、TDMビットストリームのエミュレーションに必要なシーケンスおよび同期関数を提供します。
TDM bit-streams carried over SAToP PWs may experience delays exceeding those typical of native TDM networks. These delays include the SAToP packetization delay, edge-to-edge delay of the underlying PSN, and the delay added by the jitter buffer. It is recommended to estimate both delay and delay variation prior to setup of a SAToP PW.
SATOP PWSに搭載されたTDMビットストリームは、ネイティブTDMネットワークの典型的なものを超える遅延が発生する可能性があります。これらの遅延には、SATOPパケット化遅延、基礎となるPSNのエッジからエッジの遅延、およびジッターバッファーによって追加される遅延が含まれます。SATOP PWのセットアップ前に、遅延と遅延の変動の両方を推定することをお勧めします。
SAToP carries TDM streams over PSN in their entirety, including any TDM signaling contained within the data. Consequently, the emulated TDM services are sensitive to the PSN packet loss. Appropriate generation of replacement data can be used to prevent shutting down the CE TDM interface due to occasional packet loss. Other effects of packet loss on this interface (e.g., errored blocks) cannot be prevented.
SATOPは、データ内に含まれるTDMシグナル伝達を含む、PSN全体でTDMストリームを搭載しています。その結果、エミュレートされたTDMサービスは、PSNパケット損失に敏感です。適切な生成の交換データを使用して、時折パケット損失のためにCE TDMインターフェイスのシャットダウンを防ぐことができます。このインターフェイスに対するパケット損失の他の効果（たとえば、エラーブロック）を防ぐことはできません。
Note: Structure-aware TDM emulation (see [CESoPSN] or [TDMoIP]) completely hides effects of the PSN packet loss on the CE TDM interface (because framing and Cyclic Redundancy Checks (CRCs) are generated locally) and allows usage of application-specific packet loss concealment methods to minimize effects on the applications using the emulated TDM service.
注：構造対応TDMエミュレーション（[CESOPSN]または[TDMOIP]を参照）をCE TDMインターフェイスに対するPSNパケット損失の効果を完全に隠します（フレーミングおよび周期的冗長チェック（CRC）が局所的に生成されるため）。エミュレートされたTDMサービスを使用してアプリケーションへの影響を最小限に抑えるための特定のパケット損失隠蔽方法。
SAToP can be used in conjunction with various network synchronization scenarios (see [RFC4197]) and clock recovery techniques. The quality of the TDM clock recovered by the SAToP IWF may be implementation-specific. The quality may be improved by using RTP if a common clock is available at both ends of the SAToP PW.
SATOPは、さまざまなネットワーク同期シナリオ（[RFC4197]を参照）およびクロック回復技術と組み合わせて使用できます。SATOP IWFによって回収されたTDMクロックの品質は、実装固有の場合があります。SATOP PWの両端で一般的なクロックが利用可能である場合、RTPを使用することで品質を改善することができます。
SAToP provides for effective fault isolation by carrying the local attachment circuit failure indications.
SATOPは、ローカルアタッチメント回路の故障指示を運ぶことにより、効果的な障害分離を提供します。
The option not to carry invalid TDM data enables PSN bandwidth conservation.
無効なTDMデータを運ばないオプションにより、PSN帯域幅の保存が可能になります。
SAToP allows collection of TDM-like faults and performance monitoring parameters and hence emulates 'classic' carrier services of TDM.
SATOPは、TDMのような断層とパフォーマンス監視パラメーターの収集を可能にするため、TDMの「クラシック」キャリアサービスをエミュレートします。
SAToP provides for a carrier-independent ability to detect misconnections and malformed packets. This feature increases resilience of the emulated service to misconfiguration and DoS attacks.
SATOPは、誤った接続と不正なパケットを検出するキャリアに依存しない機能を提供します。この機能により、エミュレートされたサービスの誤りが誤って構成され、DOS攻撃が復活します。
Being a constant bit rate (CBR) service, SAToP cannot provide TCP-friendly behavior under network congestion.
SATOPは、一定のビットレート（CBR）サービスであるため、ネットワーク輻輳の下でTCPに優しい動作を提供できません。
Faithfulness of a SAToP PW may be increased by exploiting QoS features of the underlying PSN.
SATOP PWの忠実さは、基礎となるPSNのQoS機能を活用することにより、増加する可能性があります。
SAToP does not provide any mechanisms for protection against PSN outages, and hence its resilience to such outages is limited. However, lost-packet replacement and packet reordering mechanisms increase resilience of the emulated service to fast PSN rerouting events.
SATOPは、PSN停止に対する保護のメカニズムを提供していないため、そのような停止に対する回復力は限られています。ただし、失われたパケットの交換とパケットの並べ替えメカニズムは、高速PSNルーティングイベントへのエミュレートサービスの回復力を高めます。
Allocation of PW Types for the corresponding SAToP PWs is defined in [RFC4446].
対応するSATOP PWSのPWタイプの割り当ては、[RFC4446]で定義されています。
We acknowledge the work of Gil Biran and Hugo Silberman who implemented TDM transport over IP in 1998.
1998年にIPよりもTDMトランスポートを実装したGil BiranとHugo Silbermanの仕事を認めています。
We would like to thank Alik Shimelmits for many productive discussions and Ron Insler for his assistance in deploying TDM over PSN.
Alik Shimelmitsに多くの生産的な議論をしてくれたことに感謝し、Ron InslerがPSNにTDMを展開するのを支援してくれたことに感謝します。
We express deep gratitude to Stephen Casner who has reviewed in detail one of the predecessors of this document and provided valuable feedback regarding various aspects of RTP usage, and to Kathleen Nichols who has provided the current text of the QoS section considering Diffserv-enabled PSN.
この文書の前任者の1つを詳細にレビューし、RTP使用のさまざまな側面に関する貴重なフィードバックを提供したStephen Casnerに、Diffserv対応PSNを考慮したQoSセクションの現在のテキストを提供しているKathleen Nicholsに深い感謝を表明します。
We thank William Bartholomay, Robert Biksner, Stewart Bryant, Rao Cherukuri, Ron Cohen, Alex Conta, Shahram Davari, Tom Johnson, Sim Narasimha, Yaron Raz, and Maximilian Riegel for their valuable feedback.
ウィリアム・バーソロマイ、ロバート・ビークナー、スチュワート・ブライアント、ラオ・チェルクリ、ロン・コーエン、アレックス・コンタ、シャラム・ダヴァリ、トム・ジョンソン、シム・ナラシンハ、ヤロン・ラズ、マクシミリアン・リーゲルの貴重なフィードバックに感謝します。
The following are co-authors of this document:
以下は、このドキュメントの共著者です。
Motty Anavi RAD Data Communications
Tim Frost Zarlink Semiconductors
Eduard Metz TNO Telecom
Prayson Pate Overture Networks
Akiva Sadovski
Israel Sasson Axerra Networks
Ronen Shashoua RAD Data Communications
[G.702] ITU-T Recommendation G.702 (11/88) - Digital Hierarchy Bit Rates.
[G.702] ITU -T推奨G.702（11/88） - デジタル階層ビットレート。
[G.703] ITU-T Recommendation G.703 (10/98) - Physical/Electrical Characteristics of Hierarchical Digital Interfaces.
[G.703] ITU -T推奨G.703（10/98） - 階層デジタルインターフェイスの物理的/電気的特性。
[G.704] ITU-T Recommendation G.704 (10/98) - Synchronous frame structures used at 1544, 6312, 2048, 8448 and 44 736 Kbit/s hierarchical levels.
[G.704] ITU -T推奨G.704（10/98） - 1544、6312、2048、8448および44 736 Kbit/s階層レベルで使用される同期フレーム構造。
[G.707] ITU-T Recommendation G.707 (03/96) - Network Node Interface for the Synchronous Digital Hierarchy (SDH).
[G.707] ITU -T推奨G.707（03/96） - 同期デジタル階層（SDH）のネットワークノードインターフェイス。
[G.775] ITU-T Recommendation G.775 (10/98) - Loss of Signal (LOS), Alarm Indication Signal (AIS) and Remote Defect Indication (RDI) Defect Detection and Clearance Criteria for PDH Signals.
[G.775] ITU -T推奨G.775（10/98） - 信号の損失（LOS）、アラーム表示信号（AIS）、およびPDH信号の欠陥検出およびクリアランス基準。
[G.802] ITU-T Recommendation G.802 (11/88) - Interworking between Networks Based on Different Digital Hierarchies and Speech Encoding Laws.
[G.802] ITU -T推奨G.802（11/88） - さまざまなデジタル階層と音声エンコーディング法に基づくネットワーク間のインターワーキング。
[G.826] ITU-T Recommendation G.826 (02/99) - Error performance parameters and objectives for international, constant bit rate digital paths at or above the primary rate.
[G.826] ITU -Tの推奨G.826（02/99） - エラーパフォーマンスパラメーターと国際的な一定のビットレートデジタルパスのプライマリレート以上の目的。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「IPv4およびIPv6ヘッダーの差別化されたサービスフィールド（DSフィールド）の定義」、RFC 2474、1998年12月。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Service", RFC 2475, December 1998.
[RFC2475] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z。、およびW. Weiss、「Distementiated Serviceの建築」、RFC 2475、1998年12月。
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.
[RFC2914]フロイド、S。、「混雑制御原則」、BCP 41、RFC 2914、2000年9月。
[RFC3086] Nichols, K. and B. Carpenter, "Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification", RFC 3086, April 2001.
[RFC3086] Nichols、K。およびB. Carpenter、「ドメインの動作ごとの差別化されたサービスの定義とその仕様の規則」、RFC 3086、2001年4月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、STD 64、RFC 3550、2003年7月。
[RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
[RFC3931] Lau、J.、Townsley、M。、およびI. Goyret、「レイヤー2つのトンネルプロトコル - バージョン3（L2TPV3）」、RFC 3931、2005年3月。
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN", RFC 4385, February 2006.
[RFC4385] Bryant、S.、Swallow、G.、Martini、L。、およびD. McPherson、「Pseudowire Emulation Edge-to-Edge（PWE3）MPLS PSNを介して使用するコントロールワード」、RFC 4385、2006年2月。
[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
[RFC4446] Martini、L。、「Pseudowire Edge to Edge Emulation（PWE3）へのIANAの割り当て」、BCP 116、RFC 4446、2006年4月。
[RFC4447] 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.
[RFC4447] Martini、L.、Rosen、E.、El-Aawar、N.、Smith、T.、およびG. Heron、「ラベル分布プロトコル（LDP）を使用した擬似ワイヤーのセットアップとメンテナンス」、RFC 4447、2006年4月。
[RTP-TYPES] RTP PARAMETERS, <http://www.iana.org/assignments/rtp-parameters>.
[rtp-types] rtpパラメーター、<http://www.iana.org/assignments/rtp-parameters>。
[T1.107] American National Standard for Telecommunications - Digital Hierarchy - Format Specifications, ANSI T1.107-1988.
[T1.107]電気通信のためのアメリカ国家標準 - デジタル階層 - 形式仕様、ANSI T1.107-1988。
[ATM-CES] ATM forum specification af-vtoa-0078 (CES 2.0) Circuit Emulation Service Interoperability Specification Ver. 2.0.
[ATM-CES] ATMフォーラム仕様AF-VTOA-0078（CES 2.0）回路エミュレーションサービス相互運用性仕様Ver。2.0。
[CESoPSN] Vainshtein, A., Ed., Sasson, I., Metz, E., Frost, T., and P. Pate, "TDM Circuit Emulation Service over Packet Switched Network (CESoPSN)", Work in Progress, November 2005.
[Cesopsn] Vainshtein、A.、ed。、Sasson、I.、Metz、E.、Frost、T.、およびP. Pate、「Packet Switched Network（CESOPSN）を介したTDM回路エミュレーションサービス」、進行中の作業、11月、2005年。
[PWE3-MS] Martini, L., Metz, C., Nadeau, T., Duckett, M., and F. Balus, "Segmented Pseudo Wire", Work in Progress, March 2006.
[PWE3-MS] Martini、L.、Metz、C.、Nadeau、T.、Duckett、M。、およびF. Balus、「セグメント化された擬似ワイヤー」、2006年3月、進行中の作業。
[PWE3-FRAG] Malis, A. and M. Townsley, "PWE3 Fragmentation and Reassembly", Work in Progress, November 2005.
[PWE3-FRAG] Malis、A。およびM. Townsley、「PWE3の断片化と再組み立て」、2005年11月、Work in Progress。
[PWE3-VCCV] Nadeau, T. and R. Aggarwal, "Pseudo Wire Virtual Circuit Connectivity", Work in Progress, August 2005.
[PWE3-VCCV] Nadeau、T。およびR. Aggarwal、「擬似ワイヤ仮想回路接続」、2005年8月、進行中の作業。
[RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997.
[RFC2212] Shenker、S.、Partridge、C。、およびR. Guerin、「保証されたサービス品質の仕様」、RFC 2212、1997年9月。
[RFC3246] Davie, B., Charny, A., Bennet, J.C., 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.
[RFC3246] Davie、B.、Charny、A.、Bennet、J.C.、Benson、K.、Le Boudec、J.、Courtney、W.、Davari、S.、Firoiu、V。、およびD. Stiliadis」迅速な転送PHB（ホップごとの動作）」、RFC 3246、2002年3月。
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[RFC3551] Schulzrinne、H。およびS. Casner、「最小限のコントロールを備えたオーディオおよびビデオ会議のRTPプロファイル」、STD 65、RFC 3551、2003年7月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711] Baugher、M.、McGrew、D.、Naslund、M.、Carrara、E。、およびK. Norrman、「安全なリアルタイム輸送プロトコル（SRTP）」、RFC 3711、2004年3月。
[RFC3916] Xiao, X., McPherson, D., and P. Pate, "Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3)", RFC 3916, September 2004.
[RFC3916] Xiao、X.、McPherson、D。、およびP. Pate、「擬似ワイヤーエミュレーションエッジとエッジ（PWE3）の要件」、RFC 3916、2004年9月。
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC3985] Bryant、S。およびP. Pate、「Pseudo Wire Emulation Edge-to-Edge（PWE3）アーキテクチャ」、RFC 3985、2005年3月。
[RFC4197] Riegel, M., "Requirements for Edge-to-Edge Emulation of Time Division Multiplexed (TDM) Circuits over Packet Switching Networks", RFC 4197, October 2005.
[RFC4197] Riegel、M。、「パケットスイッチングネットワーク上のマルチプレックス（TDM）回路のエッジツーエッジエミュレーションの要件」、RFC 4197、2005年10月。
[TDM-CONTROL] Vainshtein, A. and Y. Stein, "Control Protocol Extensions for Setup of TDM Pseudowires", Work in Progress, July 2005.
[TDM-Control] Vainshtein、A。およびY. Stein、「TDM Pseudowiresのセットアップの制御プロトコル拡張」、2005年7月、進行中の作業。
[TDMoIP] Stein, Y., "TDMoIP", Work in Progress, February 2005.
[TDMOIP] Stein、Y。、「TDMOIP」、2005年2月に進行中の作業。
Appendix A: Old Mode of SAToP Encapsulation over L2TPv3
付録A：L2TPV3を介したSATOPカプセル化の古いモード
Previous versions of this specification defined a SAToP PW encapsulation over L2TPv3, which differs from that described in Section 4.3 and Figure 2b. In these versions, the RTP header, if used, precedes the SAToP control word.
この仕様の以前のバージョンでは、L2TPV3を介したSATOP PWカプセル化を定義しました。これは、セクション4.3および図2Bで説明されているものとは異なります。これらのバージョンでは、RTPヘッダーが使用すると、SATOPコントロールワードの前にあります。
Existing implementations of the old encapsulation mode MUST be distinguished from the encapsulations conforming to this specification via the SAToP PW setup.
古いカプセル化モードの既存の実装は、SATOP PWセットアップを介してこの仕様に準拠するカプセル化と区別する必要があります。
Appendix B: Parameters That MUST Be Agreed upon during the PW Setup
付録B：PWセットアップ中に合意する必要があるパラメーター
The following parameters of the SAToP IWF MUST be agreed upon between the peer IWFs during the PW setup. Such an agreement can be reached via manual configuration or via one of the PW setup protocols:
SATOP IWFの次のパラメーターは、PWセットアップ中にピアIWFの間で合意する必要があります。このような契約は、手動構成またはPWセットアッププロトコルのいずれかを介して到達できます。
1. Type of the Attachment Circuit (AC)
1. アタッチメント回路のタイプ（AC）
As mentioned in Section 3, SAToP supports the following AC types: i) E1 (2048 kbit/s) ii) T1 (1544 kbit/s); this service is also known as DS1 iii) E3 (34368 kbit/s) iv) T3 (44736 kbit/s); this service is also known as DS3
セクション3で述べたように、SATOPは次のACタイプをサポートしています。i）E1（2048 kbit/s）ii）T1（1544 kbit/s）;このサービスは、DS1 III）e3（34368 kbit/s）iv）t3（44736 kbit/s）としても知られています。このサービスはDS3としても知られています
SAToP PWs cannot be established between ACs of different types.
SATOP PWSは、さまざまなタイプのACS間に確立することはできません。
2. Usage of octet-aligned mode for T1
2. T1のOctet-Alignedモードの使用
a) This OPTIONAL mode of emulating T1 bit-streams with SAToP PWs is described in Section 5.2.
a) T1ビットストリームをSATOP PWSでエミュレートするこのオプションモードは、セクション5.2で説明されています。
b) Both sides MUST agree on using this mode for a SAToP PW to be operational.
b) 双方は、SATOP PWが動作するようにこのモードを使用することに同意する必要があります。
3. Payload size, i.e., the amount of valid TDM data in a SAToP packet
3. ペイロードサイズ、つまりSATOPパケット内の有効なTDMデータの量
a) As mentioned in Section 5.1: i) The same payload size MUST be used in both directions of the SAToP PW. ii) The payload size cannot be changed once the PW has been set up.
a) セクション5.1で述べたように、i）SATOP PWの両方向で同じペイロードサイズを使用する必要があります。ii）PWがセットアップされると、ペイロードサイズを変更できません。
b) In most cases, any mutually agreed upon value can be used. However, if octet-aligned T1 encapsulation mode is used, the payload size MUST be an integral multiple of 25, and it expresses the amount of valid TDM data including padding.
b) ほとんどの場合、相互に合意された価値を使用できます。ただし、Octet-Aligned T1カプセル化モードを使用する場合、ペイロードサイズは25の積分倍でなければならず、パディングを含む有効なTDMデータの量を表します。
4. Usage of the RTP header in the encapsulation
4. カプセル化におけるRTPヘッダーの使用
a) Both sides MUST agree on using RTP header in the SAToP PW.
a) 双方は、SATOP PWでRTPヘッダーの使用に同意する必要があります。
b) In the case of a SAToP PW over L2TPv3 using the RTP header, both sides MUST agree on usage of the "old mode" described in Appendix A.
b) RTPヘッダーを使用してL2TPV3を介したSATOP PWの場合、双方は付録Aで説明した「古いモード」の使用に同意する必要があります。
5. RTP-dependent parameters. The following parameters MUST be agreed upon if usage of the RTP header for the SAToP PW has been agreed upon.
5. RTP依存パラメーター。SATOP PWのRTPヘッダーの使用が合意されている場合、次のパラメーターを合意する必要があります。
a) Timestamping mode (absolute or differential); this mode MAY be different for the two directions of the PW, but the receiver and transmitter MUST agree on the timestamping mode for each direction of the PW
a) タイムスタンプモード（絶対または微分）;このモードはPWの2つの方向で異なる場合がありますが、受信機と送信機はPWの各方向のタイムスタンプモードに同意する必要があります
b) Timestamping clock frequency: i) The timestamping frequency MUST be a integral multiple of 8 kHz. ii) The timestamping frequency MAY be different for the two directions of the PW, but the receiver and transmitter MUST agree on the timestamping mode for each direction of the PW.
b) タイムスタンプのクロック周波数：i）タイムスタンプの周波数は、8 kHzの積分倍でなければなりません。ii）PWの2つの方向では、タイムスタンプの周波数が異なる場合がありますが、受信機と送信機はPWの各方向のタイムスタンプモードに同意する必要があります。
c) RTP Payload Type (PT) value; any dynamically assigned value can be used with SAToP PWs.
c) RTPペイロードタイプ（PT）値。動的に割り当てられた値は、SATOP PWSで使用できます。
d) Synchronization Source (SSRC) value; the transmitter MUST agree to send the SSRC value requested by the receiver.
d) 同期ソース（SSRC）値。送信機は、受信者から要求されたSSRC値を送信することに同意する必要があります。
Editors' Addresses
編集者のアドレス
Alexander ("Sasha") Vainshtein Axerra Networks 24 Raoul Wallenberg St., Tel Aviv 69719, Israel
アレクサンダー（ "sasha"）Vainshtein Axerra Networks 24 Raoul Wallenberg St.、Tel Aviv 69719、イスラエル
EMail: sasha@axerra.com
Yaakov (Jonathan) Stein RAD Data Communications 24 Raoul Wallenberg St., Bldg C Tel Aviv 69719, Israel
Yaakov（Jonathan）Stein Rad Data Communications 24 Raoul Wallenberg St.、Bldg C Tel Aviv 69719、イスラエル
EMail: yaakov_s@rad.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
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 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。