RFC4553 日本語訳
4553 Structure-Agnostic Time Division Multiplexing (TDM) over Packet(SAToP). A. Vainshtein, Ed., YJ. Stein, Ed.. June 2006. (Format: TXT=58141 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group A. Vainshtein, Ed.
Request for Comments: 4553 Axerra Networks
Category: Standards Track YJ. Stein, Ed.
RAD Data Communications
June 2006
ワーキンググループA.Vainshtein、エドをネットワークでつないでください。コメントのために以下を要求してください。 4553Axerraはカテゴリをネットワークでつなぎます: 規格はYJを追跡します。 エドradデータ通信2006年6月のシタイン
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(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縁どりで課された構造も無視するTime事業部Multiplexing(TDM)ビットストリーム(T1、T3、3EのE1)のためにpseudowireカプセル化について説明します。
Vainshtein & Stein Standards Track [Page 1] RFC 4553 Structure-Agnostic TDM over Packet June 2006
VainshteinとシタインStandardsはパケット2006年6月の間、RFC4553構造不可知論者TDMを追跡します[1ページ]。
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
1. 序論…3 2. 用語と参照はモデル化されます…3 2.1. 用語…3 2.2. 参照はモデル化されます…4 3. サービスを見習います…4 4. SAToPカプセル化層…5 4.1. SAToPパケット・フォーマット…5 4.2. PSNとPW逆多重化はヘッダーを層にします…5 4.3. SAToPヘッダー…6 4.3.1. コントロールWordの用法と構造…8 4.3.2. RTPヘッダーの使用法…9 5. SAToP有効搭載量層…10 5.1. 一般有効搭載量…10 5.2. 八重奏で並べられたT1…11 6. SAToP操作…12 6.1. 一般的な問題…12 6.2. IWF操作…12 6.2.1. PSN行きの指示…12 6.2.2. Ce行きの指示…13 6.3. SAToPは亡命します…14 6.4. SAToP PWパフォーマンスモニター…15 7. サービスの質(QoS)問題…16 8. 混雑コントロール…16 9. セキュリティ問題…18 10. 適用性声明…18 11. IANA問題…20 12. 承認…20 13. 共同執筆します。20 14. 標準の参照…21 15. 有益な参照…22 付録A: L2TPv3の上のSAToPカプセル化の古いモード…24 付録B: 同意しなければならないパラメタはPWの間、セットアップされます…24
Vainshtein & Stein Standards Track [Page 2] RFC 4553 Structure-Agnostic TDM over Packet June 2006
VainshteinとシタインStandardsはパケット2006年6月の間、RFC4553構造不可知論者TDMを追跡します[2ページ]。
1. Introduction
1. 序論
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.
このドキュメントはpseudowiresとしてTime事業部Multiplexing(TDM)ビットストリーム(T1、T3、3EのE1)をパケット交換網(PSN)の上に要約するための方法を説明します。 それは構造の不可知論者の輸送だけを記述して、すなわち、プロトコルは完全にいずれも構造化することによるとこれらの信号、特に標準の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]を使用することで手動で構成されるか、またはセットアップするかもしれません。 PWE3制御プロトコルへの拡大がセットアップに必要であり、このために使用されるSAToP pseudowiresの維持とコード・ポイントの配分は別々のドキュメント(それぞれ[TDM-CONTROL]と[RFC4446])で説明されます。
2. Terminology and Reference Models
2. 用語と規範モデル
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
2.1. Terminology
2.1. 用語
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
ネイティブのデジタル気圧のPW Pseudowire SDH同期デジタルハイアラーキSonetの同期式光通信網TDM非同期通信モードCe顧客縁のCESサーキットエミュレーションサービスNSPサービス処理PEプロバイダー縁のPDH Plesiochronous階層構造時分割多重化
Vainshtein & Stein Standards Track [Page 3] RFC 4553 Structure-Agnostic TDM over Packet June 2006
VainshteinとシタインStandardsはパケット2006年6月の間、RFC4553構造不可知論者TDMを追跡します[3ページ]。
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].
o Signal(LOS)の損失--入って来る信号を検出できないTDM付属サーキットの状態。 [G.775]でLOS状態を入力して、残す評価基準を見つけることができます。
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 Indication Signal(AIS)を驚かせてください--上流のサーキット供給停止の存在を示すTDMビットストリームの特別なビット・パターン(例えば、[G.775]で説明されるように)。 1ユーロ、T1、および3ユーロのサーキットに、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.
私たちは、また、機能的について説明するInterworking Function(IWF)がそのセグメントを妨げる用語を使用して、逆の指示decapsulates SAToPパケットでSAToPパケットとそれにTDMを要約して、TDMを再編成します。
2.2. Reference Models
2.2. 規範モデル
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].
本書では記述されたネイティブのサービスは.3セクション3.3[RFC3985]で定義されたビットストリームペイロードタイプの特別なケースです。
The Network Synchronization reference model and deployment scenarios for emulation of TDM services are described in [RFC4197], Section 4.3.
TDMサービスのエミュレーションのためのNetwork Synchronization規範モデルと展開シナリオは[RFC4197]、セクション4.3で説明されます。
3. Emulated Services
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. 1(2048kbit/s)2E。 T1(1544kbit/s)。 また、このサービスはDS1 3として知られています。 3(34368kbit/s)4E。 T3(44736kbit/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
これらのサービスのエミュレーションに使用されるプロトコルは付属サーキットがPEsに渡される方法によりません。 例えば、同様に、T1付属サーキットは扱われます。
Vainshtein & Stein Standards Track [Page 4] RFC 4553 Structure-Agnostic TDM over Packet June 2006
VainshteinとシタインStandardsはパケット2006年6月の間、RFC4553構造不可知論者TDMを追跡します[4ページ]。
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.
不統一なATM Circuit Emulation Service(CES)[ATM-CES]を使用するATMネットワークの上までそれをT3サーキット[T1.107]で多重送信された[G.703]がSonet/SDHサーキット[G.707]の仮想の支流の中に写像した銅の上のPEに渡すか、または運ぶことにかかわらず。 PEとCEの間で使用されるどんな特定の「キャリヤー層」の終了も適切なNSPによって実行されます。
4. SAToP Encapsulation Layer
4. SAToPカプセル化層
4.1. SAToP Packet Format
4.1. SAToPパケット・フォーマット
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) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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とPW逆多重化層のヘッダー| | ... | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | ... | +-- --+ | SAToPカプセル化ヘッダー| +-- --+ | ... | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | ... | | TDMデータ(有効搭載量)| | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. Basic SAToP Packet Format
図1。 基本的なSAToPパケット・フォーマット
4.2. PSN and PW Demultiplexing Layer Headers
4.2. PSNとPW逆多重化層のヘッダー
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]がPW逆多重化メカニズムをIPv4/IPv6 PSNの上のSAToP PWsに供給できます。 PWラベルは.2セクション5.4[RFC3985]で説明されるように逆多重化機能を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 MUST NOTのためのSAToPパケットの総サイズはこのPWを終えるPEsの組の間の経路MTUを超えています。 IPv4 PSNを使用するSAToP実現はそれらが「断片化しないでください」という[RFC791](また[PWE3-FRAG]、見る)として発生させるIPv4データグラムをマークしなければなりません。
Vainshtein & Stein Standards Track [Page 5] RFC 4553 Structure-Agnostic TDM over Packet June 2006
VainshteinとシタインStandardsはパケット2006年6月の間、RFC4553構造不可知論者TDMを追跡します[5ページ]。
4.3. SAToP Header
4.3. SAToPヘッダー
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 Control Word(4バイト)を含まなければならなくて、また、固定RTPヘッダー[RFC3550]を含むかもしれません。 RTPヘッダーがSAToPヘッダーに含まれているなら、それはすぐに、それに先行しなければならないところで(図の2a、2b、および以下の2cを見てください)多重送信する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のためにSAToP PWs Equal Cost Multi-経路(ECMP)をMPLS PSNに、PW-IPに備えることによって安全なパケット区別にしている間、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) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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とUDP(PW逆多重化層)ヘッダー| | ... | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | 任意の+、+| | +--固定RTPヘッダー([RFC3550]を見る)--+| | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | SAToPコントロールWord| +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | ... | | TDMデータ(有効搭載量)| | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2a. SAToP Packet Format for an IPv4/IPv6 PSN with
UDP PW Demultiplexing
図2a。 UDP PW逆多重化があるIPv4/IPv6 PSNのためのSAToPパケット・フォーマット
Vainshtein & Stein Standards Track [Page 6] RFC 4553 Structure-Agnostic TDM over Packet June 2006
VainshteinとシタインStandardsはパケット2006年6月の間、RFC4553構造不可知論者TDMを追跡します[6ページ]。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
| IPv4/IPv6 and L2TPv3 (PW demultiplexing layer) headers |
| ... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SAToP Control Word |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| |
+-- OPTIONAL --+
| |
+-- Fixed RTP Header (see [RFC3550]) --+
| |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| ... |
| TDM data (Payload) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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とL2TPv3(PW逆多重化層)ヘッダー| | ... | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | SAToPコントロールWord| +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | 任意の+、+| | +--固定RTPヘッダー([RFC3550]を見る)--+| | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | ... | | TDMデータ(有効搭載量)| | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2b. SAToP Packet Format for an IPv4/IPv6 PSN with
L2TPv3 PW Demultiplexing
図2b。 L2TPv3 PW逆多重化がある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) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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ラベルスタック| | ... | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | SAToPコントロールWord| +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | 任意の+、+| | +--固定RTPヘッダー([RFC3550]を見る)--+| | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | ... | | TDMデータ(有効搭載量)| | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2c. SAToP Packet Format for an MPLS PSN
図2c。 MPLS PSNのためのSAToPパケット・フォーマット
Vainshtein & Stein Standards Track [Page 7] RFC 4553 Structure-Agnostic TDM over Packet June 2006
VainshteinとシタインStandardsはパケット2006年6月の間、RFC4553構造不可知論者TDMを追跡します[7ページ]。
4.3.1. Usage and Structure of the Control Word
4.3.1. コントロールWordの用法と構造
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をmisorderingする検出。 見習われたサービス3の供給停止の原因としてのPSNと付属サーキット問題の間の分化。 無効のデータ(AIS)4を移さないのによるPSN帯域幅保護。 PW出口にPWイングレスに検出された欠点のシグナリング。
The structure of the SAToP Control Word is shown in Figure 3 below.
SAToP Control Wordの構造は以下の図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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| レン| 一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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].
Bits0〜3の使用は[RFC4385]で説明されます。 それらがAssociated Channel Header(ACH)の始まりを示すのに使用されていない場合、これらのビットをゼロに設定しなければなりません。 SAToP PWの州がVirtual Circuit Connectivity Verification[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 MUSTはペイロードサイズにかかわらず適切な量のフィラーデータを展開します。 欠点が正されるならいったん設定されると、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がパケット損失状態にあるのを示す、あらかじめ設定された数の連続したパケットを失いました。 RビットはPSN行きによってクリアされて、すなわち、地方のCE行きのIWFがいったんパケット損失状態を出るとIWFがあらかじめ設定された数の連続したパケットを受けたということであるに違いありません。
Vainshtein & Stein Standards Track [Page 8] RFC 4553 Structure-Agnostic TDM over Packet June 2006
VainshteinとシタインStandardsはパケット2006年6月の間、RFC4553構造不可知論者TDMを追跡します[8ページ]。
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.
SAToPパケット(+ ペイロードサイズをSAToPヘッダーのサイズと定義する)の長さを運ぶために、それが64バイト未満であるなら使用されます。LEN(ビット10〜15)--別の方法で、5月をゼロに決めなければなりません。 LEN分野が0に設定されるとき、セクション5.1で説明されるようにあるとSAToPパケットペイロードのあらかじめ設定されたサイズを思わなければなりません、そして、実際のパケットサイズがこの長さに反するなら、奇形であるとパケットを考えなければなりません。
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ビットの無記名の円形のスペースoのItsの初期の値のSHOULDです。無作為であってください(予測できない)。
It MUST be incremented with each SAToP data packet sent in the
specific PW.
特定のPWでそれぞれのSAToPデータ・パケットを送ってそれを増加しなければなりません。
4.3.2. Usage of RTP Header
4.3.2. RTPヘッダーの使用法
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:
(ペイロードタイプ)がさばく太平洋標準時は以下の通り使用されます:
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の各指示のためにダイナミックな値([RTP-TYPES]を見る)の範囲から割り当てなければなりません太平洋標準時の人時が、評価する。 同じPT値は、PWの両方の指示のために再利用されて、また、異なったPWsの間で再利用されるかもしれません。
2. The PSN-bound IWF MUST set the PT field in the RTP header to
the allocated value.
2. 太平洋標準時がRTPヘッダーで割り当てられた値としてさばくPSN行きのIWF MUSTセット。
3. The CE-bound IWF MAY use the received value to detect malformed
packets.
3. CE行きのIWF MAYは、誤った形式のパケットを検出するのに容認された値を使用します。
The sequence number MUST be the same as the sequence number in the SAToP control word.
一連番号はSAToP規制単語による一連番号と同じであるに違いありません。
Vainshtein & Stein Standards Track [Page 9] RFC 4553 Structure-Agnostic TDM over Packet June 2006
VainshteinとシタインStandardsはパケット2006年6月の間、RFC4553構造不可知論者TDMを追跡します[9ページ]。
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のすべての実現が8kHzの時計を支えなければなりません。 8kHzの他の倍数は使用されるかもしれません。
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. 差動モード: 両方のIWFsは高値の一般的な品質タイミングソースに近づく手段を持っています、そして、このソースはタイムスタンプ世代に使用されます。 このモードのサポートはOPTIONALです。
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.
[TDM-CONTROL]で説明されるPWセットアップの間、2SAToP IWFsの間でSAToP PWの固定RTPヘッダーの使用法と用法に関連しているすべてのオプション(timestampingクロック周波数(timestampingモード)は太平洋標準時とSSRC値を選択した)に同意しなければなりません。 他の、そして、RTP特有の方法(例えば、[RFC3551]を見る)を使用してはいけません。
5. SAToP Payload Layer
5. SAToP有効搭載量層
5.1. General Payloads
5.1. 一般有効搭載量
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データで満たされたバイトの定数を運ぶREQUIREDです。 パケットペイロードサイズは、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パケットペイロードサイズに同意しなければなりません。 Interface Parameters TLV([RFC4446])のPacket TDM有効搭載量Bytesサブ(CEP)/TLVの上でCircuit Emulationを使用することによって、PWE3制御プロトコル([TDM-CONTROL])の上とSAToPパケットペイロードサイズを交換できます。
Vainshtein & Stein Standards Track [Page 10] RFC 4553 Structure-Agnostic TDM over Packet June 2006
VainshteinとシタインStandardsはパケット2006年6月の間、RFC4553構造不可知論者TDMを追跡します[10ページ]。
SAToP uses the following ordering for packetization of the TDM data:
SAToPはTDMデータのpacketizationのために注文しながら、以下を使用します:
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 1--256Eのバイトo T1--192バイトoの3Eと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]に関連して使用されるかもしれません。
5.2. Octet-Aligned T1
5.2. 八重奏で並べられたT1
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]のAnnex 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バイトの「副-フレーム」、193ビットのTDMデータを運ぶ各「副-フレーム」、および詰め物の7ビットから成ります。 このモードは以下の図4に表現されます。
Vainshtein & Stein Standards Track [Page 11] RFC 4553 Structure-Agnostic TDM over Packet June 2006
VainshteinとシタインStandardsはパケット2006年6月の間、RFC4553構造不可知論者TDMを追跡します[11ページ]。
| 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 |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| 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データ| 詰め物| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ................................. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TDMデータ| 詰め物| +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
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 packetization潜在を選定する能力です。
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交通機関のサポートはOPTIONALです。 八重奏で並べられた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交通機関を支持する実現は正確に1ミリセカンドのTDMデータに対応する200バイト(すなわち、8の25バイトの「副-フレーム」のペイロード)のペイロードサイズを支持できなければなりません。
6. SAToP Operation
6. SAToP操作
6.1. Common Considerations
6.1. 一般的な問題
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].
同じタイプ(T1、T3、3EのE1)には2個のPW付属サーキットがあるときだけ、縁から縁へのSAToPを使用するTDMサービスのエミュレーションは可能です。 [RFC4447]で説明されるようにPWセットアップでサービスタイプを交換します。
6.2. IWF Operation
6.2. IWF操作
6.2.1. PSN-Bound Direction
6.2.1. PSN行きの指示
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データは、1パケットあたりのペイロードバイトの構成された数を使用することでpacketizedされます。
Vainshtein & Stein Standards Track [Page 12] RFC 4553 Structure-Agnostic TDM over Packet June 2006
VainshteinとシタインStandardsはパケット2006年6月の間、RFC4553構造不可知論者TDMを追跡します[12ページ]。
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ヘッダーはpacketizedサービスデータにprependedされます。
The resulting packets are transmitted over the PSN.
結果として起こるパケットはPSNの上に伝えられます。
6.2.2. CE-Bound Direction
6.2.2. Ce行きの指示
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 SHOULDは容認されたSAToPパケットのペイロードが外でプレーする前に地方のTDM付属サーキットに格納されるジターバッファを含んでいます。 このバッファSHOULDのサイズは局所的にそうです。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 SHOULDは無くなっていて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.
以下に注意してください。 すぐに特定のPSNタイプにかかわらずPW逆多重化ヘッダーに続いて、SAToPと共に、最初の32ビットの単語のビット16--31で有効な一連番号をいつも見つけることができます、方法や用法やRTPヘッダーの非使用法などを多重送信して このアプローチは異なったセグメントに異なったカプセル化タイプを使用することでマルチセグメント(MS)PWsの実現と同様に複数のカプセル化タイプを支持する実現を簡素化します。
The CE-bound SAToP IWF MAY reorder misordered packets. Misordered packets that cannot be reordered MUST be discarded and treated as lost.
CE行きのSAToP IWF5月の追加注文はパケットを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ビットセットSHOULDでパケットが達する容認された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 MUSTが終える、「すべてのもの」は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
PWがいったんセットアップされると、CE行きのIWFが、SAToPパケットを受けて、ジターバッファにそれらのペイロードを格納し始めますが、終え続けている、「すべてのもの」はTDM付属サーキットに型に基づいて作ります。 この中間的状態はTDMのあらかじめ設定された量まで持続しています。
Vainshtein & Stein Standards Track [Page 13] RFC 4553 Structure-Agnostic TDM over Packet June 2006
VainshteinとシタインStandardsはパケット2006年6月の間、RFC4553構造不可知論者TDMを追跡します[13ページ]。
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.
連続した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 SHOULDはこの状態でRビットがセットした状態でそれが伝えるあらゆるパケットをマークしますが。 いったんあらかじめ設定された数の連続した有効なSAToPパケットを受け取ると、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はTDMデータの正当性のしるしをCEに供給しなければなりません。 輸送するか、またはネイティブのAIS指示を発生させることによって、これができます。 上、T3 AISがそうであるはずがないと言及するように、構造不可知論者手段が検出されるか、または発生して、したがって、構造意識しているNSP MUSTが発生して、有効なAISパターンを作るときには使用されてください。
6.3. SAToP Defects
6.3. SAToP欠陥
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 Buffer超過o Remote o Malformedパケットo Excessiveパケット損失レートパケット損失
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
各欠陥に対応するのは、IWFの欠陥州と、通常操作状態から適切な欠陥状態までの変遷の引き金となる検出評価基準と、マネージメントシステムに報告されて、その後きれいにされるかもしれないアラームです。 アラームは、欠陥状態があらかじめ設定された時間(通常2.5秒)持続するときだけ、報告されて、あるに違いありません。
Vainshtein & Stein Standards Track [Page 14] RFC 4553 Structure-Agnostic TDM over Packet June 2006
VainshteinとシタインStandardsはパケット2006年6月の間、RFC4553構造不可知論者TDMを追跡します[14ページ]。
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.
対応する欠陥の後にクリアされているのは、非検出された一瞬あらかじめ設定された時間(通常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 MAYのこの指示のために割り当てられたそれとの通信に欠けてください、そして、また、このために使用されてください。 無くなっているパケットのように発生する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ビットがセットした状態で、リモートパケット損失はパケットのレセプションによって示されます。
6.4. SAToP PW Performance Monitoring
6.4. SAToP PWパフォーマンスモニター
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性能監視パラメータの収集は、OPTIONALであり、実行される場合にだけ、CE行きのIWFが中間的状態を出た後に実行されます。
SAToP defines error events, errored blocks, and defects as follows:
SAToPは誤り出来事を定義して、ブロックをerroredして、以下の通り亡命します:
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パケットのペイロードの交換は交換パケットの挿入であると考えられません)。
Vainshtein & Stein Standards Track [Page 15] RFC 4553 Structure-Agnostic TDM over Packet June 2006
VainshteinとシタインStandardsはパケット2006年6月の間、RFC4553構造不可知論者TDMを追跡します[15ページ]。
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 erroredデータ・ブロックは1ブロックのデータが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].
[G.826]に応じて、これらの定義からSAToP PW PMパラメタ(Errored、Severely Errored、およびUnavailable Seconds)を得ます。
7. Quality of Service (QoS) Issues
7. サービスの質(QoS)問題
SAToP SHOULD employ existing QoS capabilities of the underlying PSN.
SAToP SHOULDは基礎となる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).
PSNがPE装置の間の接続性がDiffservであるなら低いジターと低い損失を保証するPDB[RFC3086]を有効にして、提供するなら、SAToP PW SHOULDはPSNがそのPDB(例えば、指示されるとしてのPSNによるパケットをマークする)のために適所に置いた入場と配分規則に従ってこのPDBを使用します。
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が適切な帯域幅の予約SHOULDがあるIntservによって可能にされた当時のGS(アフターサービスを保証する)[RFC2212]であるなら、集合TDMのものより等しいか大きい交通を帯域幅保証に供給するには、使用されてください。
8. Congestion Control
8. 輻輳制御
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の向こう側に運ばれるか、または優先順位づけを進めることであるSAToP PWs SHOULDとExpedited Forwarding(EF)[RFC3246]を支持しながらメカニズムGuaranteed Service(GS)を支持するIntServによって可能にされたドメイン[RFC2212]とDiffServによって可能にされたドメイン[RFC2475]を条件とさせる境界交通がそのようなPSNsに関する例を提供します。 そのようなメカニズムは隣接している流れへのSAToP PWsの効果をある程度否定するでしょう。境界交通調節を容易にするには、SAToPでは、IPの上で取引してください。
Vainshtein & Stein Standards Track [Page 16] RFC 4553 Structure-Agnostic TDM over Packet June 2006
VainshteinとシタインStandardsはパケット2006年6月の間、RFC4553構造不可知論者TDMを追跡します[16ページ]。
PSNs, the SAToP IP packets SHOULD NOT use the DiffServ Code Point (DSCP) value reserved for the Default Per-Hop Behavior (PHB) [RFC2474].
PSNs、SAToP IPパケットSHOULD NOTはDefault Per-ホップBehavior(PHB)[RFC2474]のために予約されたDiffServ Code Point(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をひいて、彼らはSHOULDです。「厳しい混雑」を検出するためにパケット損失をモニターしてください。 そのような状態が検出されるなら、SAToP PW SHOULDはいつかの期間の間、[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パケットの到着の予想された速度が固定されていて、知られているので、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:
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交通の上で優先するなら、厳しい混雑は重要な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交通の上で優先するなら、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の厳しい混雑閉鎖メカニズムを実行するのにガイドラインとして使用されるかもしれません:
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パフォーマンスMonitoringのテクニック(セクション6.4を見る)はエントリーを提供します、そして、密接にそれを作るSAToP PWの「入手できません、な」状態の出口評価基準が[G.826]の指定されるとしての見習われたTDMサーキットの「入手できません、な」状態と互いに関連しました。 「厳しい混雑」検出の同じ評価基準を使用すると、見習われたTDMサーキットがCEによって利用可能であるとまだ考えられている間、SAToP PWを止めるという危険は減少するかもしれません。
Vainshtein & Stein Standards Track [Page 17] RFC 4553 Structure-Agnostic TDM over Packet June 2006
VainshteinとシタインStandardsはパケット2006年6月の間、RFC4553構造不可知論者TDMを追跡します[17ページ]。
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分解手順のどちらかを用いるのがセットアップされて、これらのプロトコルSHOULDに、使用されてください。
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閉鎖を達成します。
9. Security Considerations
9. セキュリティ問題
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は多くのpseudowire-層の攻撃と敏感さを共有して、秘密性にどんなメカニズムも使用するでしょう、保全、そして、認証は一般的な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層のセキュリティの代用品としてNOT RECOMMENDEDです。
Misconnection detection capabilities of SAToP increase its resilience to misconfiguration and some types of denial-of-service (DoS) attacks.
SAToPの付け違い検出能力はmisconfigurationと何人かのタイプのサービスの否定(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の暗号化はこのドキュメントの範囲を超えています。
10. Applicability Statement
10. 適用性証明
SAToP is an encapsulation layer intended for carrying TDM circuits (E1/T1/E3/T3) over PSN in a structure-agnostic fashion.
SAToPは構造不可知論者ファッションでTDMサーキット(3/T3 1/T1/E E)をPSNの上まで運ぶために意図するカプセル化層です。
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ビットストリームのエミュレーションに必要である機能を配列と同期に提供します、無くなっているかmisorderedされたパケットと適切な補償の検出を含んでいて。
Vainshtein & Stein Standards Track [Page 18] RFC 4553 Structure-Agnostic TDM over Packet June 2006
VainshteinとシタインStandardsはパケット2006年6月の間、RFC4553構造不可知論者TDMを追跡します[18ページ]。
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 packetization遅れ、縁から縁への基本的な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.
データの中に含まれたどんなTDMシグナリングも含んでいて、SAToPはPSNの上までTDMの流れを全体として運びます。 その結果、見習われたTDMサービスはPSNパケット損失に敏感です。 時々のパケット損失のためCE TDMインタフェースを止めるのを防ぐために交換データの適切な世代を費やすことができます。 このインタフェース(例えば、ブロックをerroredした)へのパケット損失の他の影響を防ぐことができません。
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]を見る)は、見習われたTDMサービスを利用することでCE TDMインタフェース(縁どりとCyclic Redundancy Checks(CRCs)が局所的に発生するので)にPSNパケット損失の影響を完全に隠して、アプリケーションのときに効果を最小にするアプリケーション特有のパケット損失隠ぺい手段の用法を許容します。
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.
様々なネットワーク同期シナリオ([RFC4197]を見る)と時計リカバリ技術に関連してSAToPを使用できます。 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は付け違いと誤った形式のパケットを検出するキャリヤーから独立している能力に備えます。 この特徴はmisconfigurationに対する見習われたサービスと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の特徴を利用することによって、増加するかもしれません。
Vainshtein & Stein Standards Track [Page 19] RFC 4553 Structure-Agnostic TDM over Packet June 2006
VainshteinとシタインStandardsはパケット2006年6月の間、RFC4553構造不可知論者TDMを追跡します[19ページ]。
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に対する見習われたサービスの弾力を増加させます。
11. IANA Considerations
11. IANA問題
Allocation of PW Types for the corresponding SAToP PWs is defined in [RFC4446].
対応するSAToP PWsのためのPW Typesの配分は[RFC4446]で定義されます。
12. Acknowledgements
12. 承認
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を配備する際に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.
私たちは詳細にこのドキュメントの前任者のひとりを見直して、RTP用法の種々相に関する有益なフィードバックを提供したスティーブンCasnerと、そして、Diffservによって可能にされたPSNを考える場合QoS部の現在のテキストを提供したキャサリーン・ニコルズに深い感謝を言い表します。
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.
私たちはそれらの有益なフィードバックについてウィリアムBartholomay、ロバートBiksner、スチュワートブライアント、ラオCherukuri、ロンコーエン、アレックス・コンタ、Shahram Davari、トム・ジョンソン、シム・ナラシマ、ヤロンRaz、およびマクシミリアン・リーゲルに感謝します。
13. Co-Authors
13. 共著者
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 Data Communicationsティム・フロスト・Zarlink半導体エドゥアルド・メスTNO電子通信Prayson頭の序曲ネットワークアキバ・SadovskiイスラエルサソンAxerraがローネンShashoua RADをネットワークでつなぐ、データ通信
Vainshtein & Stein Standards Track [Page 20] RFC 4553 Structure-Agnostic TDM over Packet June 2006
VainshteinとシタインStandardsはパケット2006年6月の間、RFC4553構造不可知論者TDMを追跡します[20ページ]。
14. Normative References
14. 引用規格
[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 Recommendation G.704(10/98)--同期枠組構造は1544、6312、2048、8448、および44歳のときに736のキロビット/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)、PDH信号の指示信号(AIS)とリモート欠陥指示(RDI)欠陥検出とクリアランス評価基準を驚かせてください。
[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 Recommendation G.826(02/99)--予備選挙における、または、予備選挙を超えた国際的で、一定のビット伝送速度デジタル経路への誤り性能パラメタと目的は評価します。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC791] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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分野)の定義」、RFC2474(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.ウィス、「微分されたサービスのための構造」RFC2475、1998年12月。
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41,
RFC 2914, September 2000.
[RFC2914]フロイド、S.、「輻輳制御プリンシプルズ」、BCP41、RFC2914、2000年9月。
Vainshtein & Stein Standards Track [Page 21] RFC 4553 Structure-Agnostic TDM over Packet June 2006
VainshteinとシタインStandardsはパケット2006年6月の間、RFC4553構造不可知論者TDMを追跡します[21ページ]。
[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.Carpenter、「彼らのSpecificationのためのDifferentiated Services Per Domain BehaviorsとRulesの定義」RFC3086(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:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、STD64、RFC3550、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)」、RFC3931、3月2005日
[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.は飲み込まれます、マティーニ、L.とD.マクファーソン、「縁から縁(PWE3)へのコントロールがMPLS PSNの上の使用のために言い表すPseudowireエミュレーション」RFC4385、G.、2006年2月。
[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to
Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
[RFC4446] マティーニ、L.、「PseudowireのためのIANA配分はエミュレーション(PWE3)を斜めに進ませるために斜めに進む」BCP116、RFC4446、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] マティーニ、L.、ローゼン、E.、高架鉄道-Aawar、N.、スミス、T.、およびG.サギ、「ラベル分配を使用するPseudowireセットアップと維持が(自由民主党)について議定書の中で述べます」、RFC4447、2006年4月。
[RTP-TYPES] RTP PARAMETERS, <http://www.iana.org/assignments/rtp-
parameters>.
[RTP-TYPES]RTP PARAMETERS、<http://www.iana.org/課題/rtpパラメタ>。
[T1.107] American National Standard for Telecommunications -
Digital Hierarchy - Format Specifications, ANSI
T1.107-1988.
テレコミュニケーション--デジタル階層構造--書式仕様のための[T1.107]米国標準規格、ANSI T1.107-1988。
15. Informative References
15. 有益な参照
[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(CES2.0)サーキットEmulation Service Interoperability Specification Ver2.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.(エド)、サソン、I.、メス、E.、フロスト、T.、およびP.頭、「TDMサーキットエミュレーションサービスオーバーパケット交換網(CESoPSN)」は進行中(2005年11月)で働いています。
[PWE3-MS] Martini, L., Metz, C., Nadeau, T., Duckett, M., and F.
Balus, "Segmented Pseudo Wire", Work in Progress,
March 2006.
マティーニ、L.、メス、C.、ナドー、T.、ダケット、[PWE3-MS]M.、F.Balus、「疑似ワイヤを区分し」て、進歩、行進2006で働いています。
Vainshtein & Stein Standards Track [Page 22] RFC 4553 Structure-Agnostic TDM over Packet June 2006
VainshteinとシタインStandardsはパケット2006年6月の間、RFC4553構造不可知論者TDMを追跡します[22ページ]。
[PWE3-FRAG] Malis, A. and M. Townsley, "PWE3 Fragmentation and
Reassembly", Work in Progress, November 2005.
[PWE3破片手榴弾で殺傷します] A.、M.Townsley、および「PWE3断片化とReassembly」というMalisは進歩、2005年11月に働いています。
[PWE3-VCCV] Nadeau, T. and R. Aggarwal, "Pseudo Wire Virtual
Circuit Connectivity", Work in Progress, August 2005.
[PWE3-VCCV] 「疑似ワイヤの仮想のサーキットの接続性」というナドー、T.、およびR.Aggarwalは進歩、2005年8月に働いています。
[RFC2212] Shenker, S., Partridge, C., and R. Guerin,
"Specification of Guaranteed Quality of Service", RFC
2212, September 1997.
1997年9月の[RFC2212]ShenkerとS.とヤマウズラ、C.とR.ゲラン、「保証されたサービスの質の仕様」RFC2212。
[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.、シャルニー、A.、アメリカダイコンソウ、J.C.、ベンソン、K.、Le Boudec、J.、コートニー、W.、Davari、S.、Firoiu、V.、および2002年のD.Stiliadis、「完全優先転送PHB(1ホップあたりの振舞い)」、RFC3246行進。
[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プロフィールと最小量があるテレビ会議システムは制御します」、STD65、RFC3551、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] 2004年のBaugher、M.、マグリュー、D.、ジーター、M.、カラーラ、E.、およびK.Norrman、「安全なリアルタイムのトランスポート・プロトコル(SRTP)」、RFC3711行進。
[RFC3916] Xiao, X., McPherson, D., and P. Pate, "Requirements
for Pseudo-Wire Emulation Edge-to-Edge (PWE3)", RFC
3916, September 2004.
[RFC3916] Xiao、X.、マクファーソン、D.、およびP.頭、「疑似ワイヤエミュレーション縁から縁への(PWE3)のための要件」、RFC3916、2004年9月。
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-
to-Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC3985] ブライアントとS.とP.頭、「疑似ワイヤエミュレーション縁縁への(PWE3)構造」、RFC3985、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.、「縁から縁への時間事業部のエミュレーションのための要件は(TDM)サーキットをパケット交換網の上に多重送信しました」、RFC4197、2005年10月。
[TDM-CONTROL] Vainshtein, A. and Y. Stein, "Control Protocol
Extensions for Setup of TDM Pseudowires", Work in
Progress, July 2005.
[TDM-コントロール] 「TDM Pseudowiresのセットアップのための制御プロトコル拡大」というVainshtein、A.、およびY.シタインは進歩、2005年7月に働いています。
[TDMoIP] Stein, Y., "TDMoIP", Work in Progress, February 2005.
[TDMoIP] シタイン、Y.、"TDMoIP"が進歩、2005年2月に働いています。
Vainshtein & Stein Standards Track [Page 23] RFC 4553 Structure-Agnostic TDM over Packet June 2006
VainshteinとシタインStandardsはパケット2006年6月の間、RFC4553構造不可知論者TDMを追跡します[23ページ]。
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カプセル化を定義しました。L2TPv3はセクション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:
PWセットアップの間、同輩IWFsの間でSAToP IWFの以下のパラメタに同意しなければなりません。 そのような合意に手動の構成の近く、または、PWセットアッププロトコルの1つを通して達することができます:
1. Type of the Attachment Circuit (AC)
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は以下の交流タイプを支持します: i) 1E(2048kbit/s)のii) T1(1544kbit/s)。 また、このサービスはDS1iii)として知られています。 3E(34368kbit/s)のiv) T3(44736kbit/s)。 また、このサービスはDS3として知られています。
SAToP PWs cannot be established between ACs of different types.
異なったタイプのACsの間にSAToP PWsを設立できません。
2. Usage of octet-aligned mode for T1
2. T1のための八重奏で並べられたモードの用法
a) This OPTIONAL mode of emulating T1 bit-streams with SAToP PWs
is described in Section 5.2.
a) SAToP PWsと共にT1ビットストリームを見習うこのOPTIONALモードはセクション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) 多くの場合、値で相談ずくのいずれも使用できます。 しかしながら、八重奏で並べられたT1カプセル化モードが使用されているなら、ペイロードサイズは25の不可欠の倍数であるに違いありません、そして、それはそっと歩くのを含む有効なTDMデータの量を表します。
Vainshtein & Stein Standards Track [Page 24] RFC 4553 Structure-Agnostic TDM over Packet June 2006
VainshteinとシタインStandardsはパケット2006年6月の間、RFC4553構造不可知論者TDMを追跡します[24ページ]。
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の場合では、両側はAppendix 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) モード(絶対の、または、特異な)をTimestampingします。 PWの2つの方向において、このモードは異なるかもしれませんが、受信機と送信機はPWの各指示のためにtimestampingモードに同意しなければなりません。
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) クロック周波数をTimestampingします: i) timestamping頻度は8kHz ii)の不可欠の倍数であるに違いありません。 PWの2つの方向において、timestamping頻度は異なるかもしれませんが、受信機と送信機はPWの各指示のためにtimestampingモードに同意しなければなりません。
c) RTP Payload Type (PT) value; any dynamically assigned value can
be used with SAToP PWs.
c) RTP有効搭載量Type(太平洋標準時の)値。 SAToP PWsと共にどんなダイナミックに割り当てられた値も使用できます。
d) Synchronization Source (SSRC) value; the transmitter MUST agree
to send the SSRC value requested by the receiver.
d) 同期Source(SSRC)価値。 送信機は、受信機によって要求されたSSRC値を送るのに同意しなければなりません。
Vainshtein & Stein Standards Track [Page 25] RFC 4553 Structure-Agnostic TDM over Packet June 2006
VainshteinとシタインStandardsはパケット2006年6月の間、RFC4553構造不可知論者TDMを追跡します[25ページ]。
Editors' Addresses
エディタのアドレス
Alexander ("Sasha") Vainshtein
Axerra Networks
24 Raoul Wallenberg St.,
Tel Aviv 69719, Israel
アレクサンダー(「サシャ」)Vainshtein Axerraは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
データ通信24ラウルワレンバーグ通り、Bldg Cテルアビブ69719、Yaakov(ジョナサン)シタインRADイスラエル
EMail: yaakov_s@rad.com
メール: yaakov_s@rad.com
Vainshtein & Stein Standards Track [Page 26] RFC 4553 Structure-Agnostic TDM over Packet June 2006
VainshteinとシタインStandardsはパケット2006年6月の間、RFC4553構造不可知論者TDMを追跡します[26ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Vainshtein & Stein Standards Track [Page 27]
Vainshteinとシタイン標準化過程[27ページ]
一覧
スポンサーリンク
