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)
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).
著作権（C）インターネット協会（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]によって課された特定の構造を無視し、構造のみに依存しない輸送に対処します。このエミュレーションは、PEがTDMデータを解釈するか、TDMシグナリングに参加する必要がない[RFC4197]やスーツアプリケーションにおける「非構造化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溶液はPWE3の[RFC3985]で説明アーキテクチャと満足の両方に準拠して、関連する一般的な要件は[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).
全てのPWと同様、の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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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
ATM非同期転送モードCEカスタマーエッジCES回線エミュレーションサービスNSPネイティブサービス処理PEのプロバイダーエッジPDHプレシオクロナスデジタル階層PW擬似回線SDH同期デジタル階層SONET同期光ネットワークTDM時分割多重
In addition, the following TDM-specific terms are needed:
また、以下のTDM特有の用語が必要とされています。
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].
シグナル（LOS）のO損失 - 着信信号を検出することができない、請求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」パターン）のバイナリ「1」の値の配列であるため、それが検出され、構造に依存しない手段によって生成することができます。 T3 AISパターンは、T3フレーミングが必要（セクション2.5.3.6.1、[G.704]を参照）、したがって、構造のみ対応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.
我々はまた、のSAToPパケットに、逆方向のSAToPパケットをデカプセル化及びTDMを再構成することをTDMをカプセル化セグメントおよび機能ブロックを説明するために用語のインターワーキング機能（IWF）を使用します。
The generic models defined in Sections 4.1, 4.2, and 4.4 of [RFC3985] fully apply to SAToP.
汎用セクション4.1で定義されたモデル、4.2、および[RFC3985]の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キロビット/秒）2. T1（1544キロビット/秒）。このサービスはまた、DS1 3 E3（34368キロビット/秒）4. T3（44736キロビット/秒）として知られています。このサービスは、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.
これらのサービスのエミュレーションに使用されるプロトコルは、接続回線がPEに配信される方法に依存しません。例えば、T1アタッチメント回路にかかわらず、それがSONETの仮想支流にマッピングされ、T3回路[T1.107]に多重、銅[G.703]でPEに配信されるかどうかの同じように処理され/ 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分離機構を提供することができます。 [RFC3985]のセクション5.4.2に記載したようにPWラベルは、MPLS PSNのための逆多重化機能を提供します。
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の実装は、[RFC791]（も[PWE3-FRAG]を参照）、 "フラグメント不可" として生成したIPv4データグラムをマークする必要があります。
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多重化、（図2a、図2b、及び以下2Cを参照）を除く全ての場合においての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]).
注：PW-IPパケットの識別を提供することによってMPLS PSNのためのSAToP PWsの等しいコストマルチパス（ECMP）-safeしながらこのような構成は、UDP多重化とのIPv4 / IPv6のPSNのためのRTPの伝統的な使用法に準拠して（参照[ RFC3985]、セクション5.4.3）。また、（[PWE3-MS]を参照）のSAToPのPWのL2TPv3のベースとMPLSベースのセグメントのシームレスなステッチを容易にします。
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
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
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.
パケット損失や無効なデータ（AIS）PWの出口で検出された障害の4シグナリングを転送しないことによってエミュレートサービス3. PSN帯域幅節約の停止の原因としてPSNと接続回線の問題の間に2分化を誤った順序の1検出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
SAToP制御ワードの図3の構造
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].
3ビット0の使用は、[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.
注：このドキュメントでは、のSAToPパケットで運ばれたデータを無効として扱われるTDMフォルト条件指定されていません。可能な例としては、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は、すなわち、連続するパケットの事前設定された数を受信し、パケット損失状態を出た後にRビットはPSN結合IWFによってクリアされなければなりません。
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）は、 - それが64バイト未満である場合（のSAToPヘッダ+ペイロードサイズの大きさとして定義される）のSAToPパケットの長さを運ぶために使用することができ、そうでなければゼロに設定しなければなりません。 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).
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つPT値は、PWの各方向について（[RTP-TYPES]を参照）、動的な値の範囲から割り当てられなければなりません。同じ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.
タイムスタンプを生成するために使用されるクロックの周波数は8kHzでの整数倍でなければなりません。 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及びその使用（タイムスタンプクロック周波数、タイムスタンプモードでは、選択されたPT及びSSRC値）に関連付けられているすべてのオプションで固定RTPヘッダの使用は、PWセットアップ中に2つのSAToPのIWFとの間で合意されなければなりません[ TDM-CONTROL]。その他、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結合のIWFは、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 - T1 O 256バイト - E3とT3 O 192バイト - 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フレーミング（バイト、フレームまたはマルチフレームアラインメント）によって課される任意の下地構造に配向を想定していません。 SAToP制御ワードにおけるLビットが設定されている場合2.のSAToPパケットは、PSN帯域幅を節約するために無効のTDMデータを省略することができます。 47バイトの倍数である3.ペイロードサイズは、非構造化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.
非構造化T1アタッチメント回路は、時々[G.802]の付録Bに記載されているように、バイトの整数にパディング既に設けられています。これは、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バイトのサブフレームの数、TDMデータの193ビットとパディングの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
オクテットアラインT1の輸送については、図4の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.
オクテット整列T1トランスポートモードのサポートはオプションです。オクテット整列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.
オクテット整列T1の転送モードをサポートする実装は、TDMデータの正確に1ミリ秒に対応する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].
2つのPWの接続回線が同じタイプ（T1、E1、T3、E3）である場合のSAToPを使用してTDMサービスのエッジツーエッジエミュレーションにのみ可能です。 [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逆多重化層、および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は失われたとmisorderedパケットを検出するための制御ワードのシーケンス番号を使用する必要があります。 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で、有効なシーケンス番号は、常にビットに見出すことができる16 - すぐにかかわらず、RTPヘッダの特定のPSNタイプ、多重方法、使用または不使用のPW逆多重化ヘッダに続く最初の32ビット・ワードの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はmisorderedパケットの順序を変更するかもしれません。並べ替えることができないMisorderedパケットが破棄され、失われたものとして扱わなければなりません。
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は一回の連続した有効なのSAToPパケットの事前設定された数が受信されている通常の1に、この状態遷移を残します。 （首尾よく並べ替えパケットが連続したパケットの数に貢献しています。）
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 AISを検出または構造に依存しない手段によって生成され、有効な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不正な形式のパケット〇〇ストレイパケット
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を使用する場合、PWのこの方向のために割り当てられたPT値とその対応関係の欠如は、この目的のために用いることができます。不正な形式で次のパケットが失われたパケットのように生成された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エラーイベントは、ジッタバッファに単一の置換パケットの挿入（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接続回線および少なくとも一つの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は入院に準拠して、このPDBを使用する必要があり、割り当てがPSNがそのための場所に入れているルール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 PWをすることにより、帯域幅の衰えていない需要がネットワーク制御プロトコルに影響を与える可能性が輻輳をネットワークに貢献することができます。
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
可能な限り、のSAToP PWSが帯域予約および入場制御や優先順位付けを転送境界トラフィック調整機構のいずれかを提供トラフィックエンジニアリングのPSNを横切って実施すべきです。保証型サービス（GS）をサポートするのIntServ対応ドメイン[RFC2212]及び緊急転送（EF）をサポートするのDiffServ対応ドメイン[RFC2475]、[RFC3246]は、このようなのPSNの例を提供します。そのようなメカニズムは、ある程度、隣接するストリーム上のSAToPのPWsの効果を無効にします。 IP経由のSAToP交通の境界交通調節を容易にするために
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 IPパケットは、デフォルトのホップ単位動作（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
SAToPパケットの到着の予想速度が一定と知られているので、1のSAToP IWFは、本質的にパケット損失測定を提供することができます
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:
PSNが増加送達を提供する場合2.のSAToPパケット損失測定の結果は、重度の輻輳の有無を信頼できる指標ではないかもしれません。例えば：
a) If SAToP traffic takes precedence over non-SAToP traffic, severe congestion can develop without significant SAToP packet loss.
A）のSAToPトラフィックが非の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.
非のSAToPトラフィックはのSAToPトラフィックよりも優先された場合b）に、の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 PWのでエミュレートTDMサービスは、高可用性の目標を持っている（参照[G.826]）のSAToP PWを一時的にシャットダウンを決定する際に考慮されなければならないこと。
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のPWを使用して「厳しい混雑」を検出するための正確な基準を定義し、それらのその後の再起動しませんディレイ。これは、さらなる研究のために残されています。ただし、次の考慮事項が厳しいの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のための入口および出口の基準を提供します。 「厳しい混雑」を検出するための同じ基準を使用すると、エミュレートされたTDM回路がまだCEで利用できると考えている間のSAToP PWをシャットダウンのリスクを減少させることができます。
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制御プロトコル[RFC4447]または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エンドポイントの一つが十分に長い期間のパケットの送信を停止した場合、そのピア（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 PWを共有疑似回線レイヤ攻撃の数に対する感受性と機密性、完全性、および認証のためのどんなメカニズムを使用しますが、一般的なPWのために開発されています。これらのメソッドは、このドキュメントの範囲を超えています。
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 PWの上の既知平文攻撃をより困難にします。 PW暗号化は、このドキュメントの範囲を超えています。
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は、失われたまたはmisorderedパケットの検出と適切な補償を含む、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のPWを介して搬送されるTDMビットストリームは、ネイティブTDMネットワークの代表的なものを超える遅延が発生することができます。これらの遅延は、基礎となるPSNののSAToPパケット化遅延、エッジ・ツー・エッジ遅延、およびジッタバッファによって追加された遅延を含みます。前の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パケット損失の影響を隠し、用途向けの使用を可能にしますエミュレートされた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.
固定ビットレート（CBR）のサービスなので、のSAToPはネットワークの混雑の下の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トランスポートを実装ギルBiranとヒューゴシルバーマンの仕事を認めています。
We would like to thank Alik Shimelmits for many productive discussions and Ron Insler for his assistance in deploying TDM over PSN.
私たちは、PSN上TDMを展開中の彼の援助のための多くの生産的な議論とロンInslerためAlik Shimelmitsに感謝したいと思います。
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.
私たちは詳細に、このドキュメントの前任者のいずれかを検討し、Diffservの対応のPSNを考慮したQoSセクションの現在のテキストを提供している、とキャスリーン・ニコルズへのRTPの使用状況のさまざまな側面に関する貴重なフィードバックを提供してきたスティーブンCasnerへの深い感謝の意を表し。
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.
私たちは、彼らの貴重なフィードバックのためのウィリアム・バーソロメイ、ロバートBiksner、スチュワートブライアント、ラオCherukuri、ロン・コーエン、アレックスコンタ、Shahram Davari、トム・ジョンソン、シムナラシンハ、ヤロンラズ、およびマクシミリアンリーゲルに感謝します。
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
Motty Anavi RADデータ・コミュニケーションズティム・フロストZarlink半導体エドゥアルト・メッツTNOテレコムPraysonパテ序曲ネットワークアキヴァSadovskiイスラエルSasson Axerra NetworksのRonen氏Shashoua RADデータ・コミュニケーションズ
[G.702] ITU-T Recommendation G.702 (11/88) - Digital Hierarchy Bit Rates.
[G.702] ITU-T勧告G.702（88分の11） - デジタル階層ビットレート。
[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キロビット/秒の階層レベルで使用される同期フレーム構造。
[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）とリモート障害表示（RDI）欠陥検出と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（88分の11） - 異なるデジタル階層と音声符号化法に基づいて、ネットワーク間のインターワーキング。
[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]ポステル、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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]ニコルズ、K.、ブレイク、S.、ベイカー、F.、およびD.黒、 "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]ブレイク、S.、ブラック、D.、カールソン、M.、デイヴィス、E.、王、Z.、およびW.ワイス、 "差別化サービスのためのアーキテクチャ"、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]ニコルズ、K.とB.大工、「自分仕様のための差別化サービスドメイン単位の行動とルールの定義」、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.、フレデリック、R.、およびV.ヤコブソン、 "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]ラウ、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]ブライアント、S.、ツバメ、G.、マティーニ、L.、およびD.マクファーソン、 "MPLS PSNの上の使用のための擬似回線エミュレーションエッジツーエッジ（PWE3）制御ワード"、RFC 4385、2006年2月。
[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
[RFC4446]マティーニ、L.、BCP 116、RFC 4446、2006年4月 "エッジエミュレーションに擬似回線縁（PWE3）のためのIANAの割り当て"。
[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]、L.、ローゼン、E.、エル・Aawar、N.、スミス、T.、およびG.サギ、 "ラベル配布プロトコル（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.編、Sasson、I.、メッツ、E.、フロスト、T.、およびP.パテは、プログレス、11月に作業を "TDM回線エミュレーションサービスは、パケット上のネットワーク（のCESoPSN）の交換しました" 2005。
[PWE3-MS] Martini, L., Metz, C., Nadeau, T., Duckett, M., and F. Balus, "Segmented Pseudo Wire", Work in Progress, March 2006.
[PWE3-MS]マティーニ、L.、メッツ、C.、ナドー、T.、ダケット、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月に働いています。
[PWE3-VCCV] Nadeau, T. and R. Aggarwal, "Pseudo Wire Virtual Circuit Connectivity", Work in Progress, August 2005.
[PWE3-VCCV]ナドー、T.、およびR.アガルワル、 "疑似ワイヤー仮想回線接続"、進歩、2005年8月の作業。
[RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997.
[RFC2212] Shenker、S.、ヤマウズラ、C.、およびR.ゲラン、 "保証されたサービスの質の仕様"、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]デイビー、B.、Charny、A.、ベネット、JC、ベンソン、K.、ルBoudec、J.、コートニー、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.、マグリュー、D.、Naslund、M.、カララ、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]シャオ、X.、マクファーソン、D.、およびP.パテ、 "疑似ワイヤー・エミュレーション・エッジ・ツー・エッジ（PWE3）の要件"、RFC 3916、2004年9月。
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC3985]ブライアント、S.とP.パテ、 "疑似ワイヤーエミュレーション端から端まで（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]リーゲル、M.、RFC 4197、2005年10月、「パケット交換網の上に時分割多重（TDM）回路の端から端までエミュレーションのための要件」。
[TDM-CONTROL] Vainshtein, A. and Y. Stein, "Control Protocol Extensions for Setup of TDM Pseudowires", Work in Progress, July 2005.
"TDMスードワイヤのセットアップのための制御プロトコル拡張機能" [TDM-CONTROL] Vainshtein、A.、およびY.スタイン、進歩、2005年7月での作業。
[TDMoIP] Stein, Y., "TDMoIP", Work in Progress, February 2005.
[のTDMoIP]スタイン、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.
本明細書の以前のバージョンは、4.3節と図2bで説明したものとは異なるL2TPv3の上のSAToP PWカプセル化を、定義されました。これらのバージョンでは、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つを介して到達することができます。
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キロビット/秒）ii）のT1（1544キロビット/秒）。このサービスはまた、E3（34368キロビット/秒）iv）のT3（44736キロビット/秒））DS1 IIIとして知られています。このサービスは、DS3として知られています
SAToP PWs cannot be established between ACs of different types.
SAToP PWSが、異なる種類のACの間で確立することはできません。
a) This OPTIONAL mode of emulating T1 bit-streams with SAToP PWs is described in Section 5.2.
A）のSAToPのPWとT1ビットストリームをエミュレートするこのOPTIONALモードは、セクション5.2に記載されています。
b) Both sides MUST agree on using this mode for a SAToP PW to be operational.
b）の双方は、動作するのSAToP PWのために、このモードを使用することに同意しなければなりません。
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.
セクション5.1で述べたようにA）は、i）同じペイロードサイズがのSAToP PWの両方向で使用しなければなりません。 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）は、ほとんどの場合、相互の値に合意したものを用いることができます。オクテット整列T1カプセル化モードが使用される場合は、ペイロードサイズが25の整数倍でなければならず、パディングを含む有効なTDMデータの量を表します。
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の二つの方向のために異なっていてもよいが、受信機と送信機は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）タイムスタンプ周波数は8kHzでの整数倍でなければなりません。 II）タイムスタンプ周波数がPWの二つの方向のために異なっていてもよいが、受信機と送信機はPWの各方向のためのタイムスタンプモードに同意しなければなりません。
c) RTP Payload Type (PT) value; any dynamically assigned value can be used with SAToP PWs.
C）RTPペイロードタイプ（PT）値。任意の動的に割り当てられた値は、のSAToP PWを一緒に使用することができます。
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
アレクサンダー（ "サーシャ"）Vainshtein Axerra Networksの24ラウル・ワレンバーグセント、テルアビブ69719イスラエル
EMail: sasha@axerra.com
メールアドレス：sasha@axerra.com
Yaakov (Jonathan) Stein RAD Data Communications 24 Raoul Wallenberg St., Bldg C Tel Aviv 69719, Israel
Yaakovの（ジョナサン）スタインRADデータ・コミュニケーションズ24ラウル・ワレンバーグセント、ビルCテルアビブ69719、イスラエル
EMail: yaakov_s@rad.com
メールアドレス：yaakov_s@rad.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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 provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。