RFC4197 日本語訳
4197 Requirements for Edge-to-Edge Emulation of Time DivisionMultiplexed (TDM) Circuits over Packet Switching Networks. M. Riegel,Ed.. October 2005. (Format: TXT=47937 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Riegel Request for Comments: 4197 Siemens AG Category: Informational October 2005
コメントを求めるワーキンググループM.リーゲルの要求をネットワークでつないでください: 4197年のジーメンス株式会社カテゴリ: 情報の2005年10月
Requirements for Edge-to-Edge Emulation of
Time Division Multiplexed (TDM) Circuits over
Packet Switching Networks
縁から縁への時間事業部のエミュレーションのための要件は(TDM)サーキットをパケット交換網の上に多重送信しました。
Status of This Memo
このメモの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
Abstract
要約
This document defines the specific requirements for edge-to-edge emulation of circuits carrying Time Division Multiplexed (TDM) digital signals of the Plesiochronous Digital Hierarchy as well as the Synchronous Optical NETwork/Synchronous Digital Hierarchy over packet-switched networks. It is aligned to the common architecture for Pseudo Wire Emulation Edge-to-Edge (PWE3). It makes references to the generic requirements for PWE3 where applicable and complements them by defining requirements originating from specifics of TDM circuits.
このドキュメントは縁から縁へのサーキットのパケット交換網の上のSynchronous Optical NETwork/同期デジタルハイアラーキと同様にPlesiochronous Digital HierarchyのTime事業部Multiplexed(TDM)ディジタル信号を運ぶエミュレーションのための決められた一定の要求を定義します。 それはPseudo Wire Emulation Edgeから縁への(PWE3)のために一般的な構造に並べられます。 それは、適切であるところで一般的な要件のPWE3の参照をして、TDMサーキットの詳細から発する要件を定義することによって、それらの補足となります。
Riegel Informational [Page 1] RFC 4197 PWE3 TDM Requirements October 2005
[1ページ]RFC4197PWE3 TDM要件2005年10月の情報のリーゲル
Table of Contents
目次
1. Introduction ....................................................3
1.1. TDM Circuits Belonging to the PDH Hierarchy ................3
1.1.1. TDM Structure and Transport Modes ...................4
1.2. SONET/SDH Circuits .........................................4
2. Motivation ......................................................5
3. Terminology .....................................................6
4. Reference Models ................................................7
4.1. Generic PWE3 Models ........................................7
4.2. Clock Recovery .............................................7
4.3. Network Synchronization Reference Model ....................8
4.3.1. Synchronous Network Scenarios ......................10
4.3.2. Relative Network Scenario ..........................12
4.3.3. Adaptive Network Scenario ..........................12
5. Emulated Services ..............................................13
5.1. Structure-Agnostic Transport of Signals out of the
PDH Hierarchy .............................................13
5.2. Structure-Aware Transport of Signals out of the
PDH Hierarchy .............................................14
5.3. Structure-Aware Transport of SONET/SDH Circuits ...........14
6. Generic Requirements ...........................................14
6.1. Relevant Common PW Requirements ...........................14
6.2. Common Circuit Payload Requirements .......................15
6.3. General Design Issues .....................................16
7. Service-Specific Requirements ..................................16
7.1. Connectivity ..............................................16
7.2. Network Synchronization ...................................16
7.3. Robustness ................................................16
7.3.1. Packet loss ........................................17
7.3.2. Out-of-order delivery ..............................17
7.4. CE Signaling ..............................................17
7.5. PSN Bandwidth Utilization .................................18
7.6. Packet Delay Variation ....................................19
7.7. Compatibility with the Existing PSN Infrastructure ........19
7.8. Congestion Control ........................................19
7.9. Fault Detection and Handling ..............................20
7.10. Performance Monitoring ...................................20
8. Security Considerations ........................................20
9. References .....................................................20
9.1. Normative References ......................................20
9.2. Informative References ....................................21
10. Contributors Section ..........................................22
1. 序論…3 1.1. PDH階層構造に属すTDMサーキット…3 1.1.1. TDMはモードを構造化して、輸送します…4 1.2. Sonet/SDHサーキット…4 2. 動機…5 3. 用語…6 4. 参照はモデル化されます…7 4.1. 一般的なPWE3はモデル化します…7 4.2. 回復の時間を計ってください…7 4.3. 同期規範モデルをネットワークでつないでください…8 4.3.1. 同期ネットワークシナリオ…10 4.3.2. 相対的なネットワークシナリオ…12 4.3.3. 適応型のネットワークシナリオ…12 5. サービスを見習います…13 5.1. PDH階層構造からの信号の構造不可知論者輸送…13 5.2. PDH階層構造からの信号の構造意識している輸送…14 5.3. Sonet/SDHサーキットの構造意識している輸送…14 6. 一般的な要件…14 6.1. 関連一般的なPW要件…14 6.2. 一般的なサーキット有効搭載量要件…15 6.3. 一般デザイン問題…16 7. サービス特有の要件…16 7.1. 接続性…16 7.2. 同期をネットワークでつないでください…16 7.3. 丈夫さ…16 7.3.1. パケットの損失…17 7.3.2. 不適切な配送…17 7.4. Ceシグナリング…17 7.5. PSN帯域幅利用…18 7.6. パケット遅れ変化…19 7.7. 既存のPSNインフラストラクチャとの互換性…19 7.8. 混雑コントロール…19 7.9. 欠点検出と取り扱い…20 7.10. パフォーマンスモニター…20 8. セキュリティ問題…20 9. 参照…20 9.1. 標準の参照…20 9.2. 有益な参照…21 10. 貢献者部…22
Riegel Informational [Page 2] RFC 4197 PWE3 TDM Requirements October 2005
[2ページ]RFC4197PWE3 TDM要件2005年10月の情報のリーゲル
1. Introduction
1. 序論
This document defines the specific requirements for edge-to-edge emulation of circuits carrying Time Division Multiplexed (TDM) digital signals of the Plesiochronous Digital Hierarchy (PDH) as well as the Synchronous Optical NETwork (SONET)/Synchronous Digital Hierarchy (SDH) over Packet-Switched Networks (PSN). It is aligned to the common architecture for Pseudo Wire Emulation Edge-to-Edge (PWE3) as defined in [RFC3985]. It makes references to requirements in [RFC3916] where applicable and complements [RFC3916] by defining requirements originating from specifics of TDM circuits.
このドキュメントは縁から縁へのサーキットのPacketによって切り換えられたNetworks(PSN)の上のSynchronous Optical NETwork(Sonet)/同期デジタルハイアラーキ(SDH)と同様にPlesiochronous Digital Hierarchy(PDH)のTime事業部Multiplexed(TDM)ディジタル信号を運ぶエミュレーションのための決められた一定の要求を定義します。 それはPseudo Wire Emulation Edgeから縁への(PWE3)のために[RFC3985]で定義されるように一般的な構造に並べられます。 それは、適切であるところで[RFC3916]で要件について言及して、TDMサーキットの詳細から発する要件を定義することによって、[RFC3916]の補足となります。
The term "TDM" will be used in this documents as a general descriptor for the synchronous bit streams belonging to either the PDH or the SONET/SDH hierarchies.
シンクロナスビットのための一般的な記述子がPDHかSonet/SDH階層構造のどちらかに属しながら流れるとき、"TDM"という用語はこのドキュメントで使用されるでしょう。
1.1. TDM Circuits Belonging to the PDH Hierarchy
1.1. PDH階層構造に属すTDMサーキット
The bit rates traditionally used in various regions of the world are detailed in the normative reference [G.702]. For example, in North America, the T1 bit stream of 1.544 Mbps and the T3 bit stream of 44.736 Mbps are mandated, while in Europe, the E1 bit stream of 2.048 Mbps and the E3 bit stream of 34.368 Mbps are utilized.
世界の様々な領域で伝統的に使用されるビット伝送速度は引用規格[G.702]で詳細です。 例えば、北アメリカでは、1.544MbpsのT1ビットストリームと44.736MbpsのT3ビットストリームが強制されます、2.048Mbpsの1Eのビットストリームと34.368Mbpsの3Eのビットストリームがヨーロッパで利用されていますが。
Although TDM can be used to carry unstructured bit streams at the rates defined in [G.702], there is a standardized method of carrying bit streams in larger units called frames, each frame contains the same number of bits.
[G.702]で定義された速度で不統一なビットストリームを運ぶのにTDMを使用できますが、フレームと呼ばれるより大きい単位にはビットストリームを運ぶ標準化法があって、各フレームは同じ数のビットを含んでいます。
Related to the sampling frequency of voice traffic the bitrate is always a multiple of 8000, hence the T1 frame consists of 193 bits and the E1 frame of 256 bits. The number of bits in a frame is called the frame size.
音声トラヒックのサンプリング周波数に関係づけられて、いつもbitrateが8000年の倍数である、したがって、T1フレームは256ビットの193ビットと1Eのフレームから成ります。 フレームのビットの数はフレーム・サイズと呼ばれます。
The framing is imposed by introducing a periodic pattern into the bit stream to identify the boundaries of the frames (e.g., 1 framing bit per T1 frame, a sequence of 8 framing bits per E1 frame). The details of how these framing bits are generated and used are elucidated in [G.704], [G.706], and [G.751]. Unframed TDM has all bits available for payload.
縁どりは、フレーム(例えば、T1フレームあたり1つのフレーム指示ビット、8つのフレーム指示ビットの1Eのフレームあたり1つの系列)の境界を特定するために周期的なパターンをビットストリームに取り入れることによって、課されます。 これらのフレーム指示ビットがどう発生して、使用されるかに関する詳細は[G.704]、[G.706]、および[G.751]で解明されます。 Unframed TDMには、ペイロードに有効なすべてのビットがあります。
Framed TDM is often used to multiplex multiple channels (e.g., voice channels each consisting of 8000 8-bit-samples per second) in a sequence of "timeslots" recurring in the same position in each frame. This multiplexing is called "channelized TDM" and introduces additional structure.
縁どられたTDMは、次々にの"timeslots"の複数のチャンネル(例えば、声は1秒あたり8ビットの8000個のサンプルの各成ることにチャネルを開設する)を多重送信するのに各フレームで同じ位置で再発しながら、しばしば使用されます。 このマルチプレクシングは、"channelized TDM"と呼ばれて、追加構造を紹介します。
Riegel Informational [Page 3] RFC 4197 PWE3 TDM Requirements October 2005
[3ページ]RFC4197PWE3 TDM要件2005年10月の情報のリーゲル
In some cases, framing also defines groups of consecutive frames called multiframes. Such grouping imposes an additional level of structure on the TDM bit-stream.
いくつかの場合、また、縁どりは「マルチ-フレーム」と呼ばれる連続したフレームのグループを定義します。 そのような組分けは追加レベルの構造をTDMビットストリームに課します。
1.1.1. TDM Structure and Transport Modes
1.1.1. TDM構造と交通機関
Unstructured TDM: TDM that consists of a raw bit-stream of rate defined in [G.702], with all bits available for payload.
不統一なTDM: すべてのビットが有効な状態でペイロードのために[G.702]で定義されたレートの生のビットストリームから成るTDM。
Structured TDM: TDM with one or more levels of structure delineation, including frames, channelization, and multiframes (e.g., as defined in [G.704], [G.751], and [T1.107]).
構造化されたTDM: フレーム、チャネル化、および「マルチ-フレーム」(例えば、[G.704]、[G.751]、および[T1.107]で定義されるように)を含む1つ以上のレベルの構造輪郭描写があるTDM。
Structure-Agnostic Transport: Transport of unstructured TDM, or of structured TDM when the structure is deemed inconsequential from the transport point of view. In structure-agnostic transport, any structural overhead that may be present is transparently transported along with the payload data, and the encapsulation provides no mechanisms for its location or utilization.
構造不可知論者輸送: 構造が輸送観点から取るに足らないと考えられるときの不統一なTDM、または構造化されたTDMの輸送。 構造不可知論者輸送では、どんな存在するかもしれない構造的なオーバーヘッドもペイロードデータと共に透明に輸送されます、そして、カプセル化はその位置か利用にメカニズムを全く提供しません。
Structure-Aware Transport: Transport of structured TDM taking at least some level of the structure into account. In structure-aware transport, there is no guarantee that all bits of the TDM bit-stream will be transported over the PSN network (specifically, the synchronization bits and related overhead may be stripped at ingress and usually will be regenerated at egress) or that transported bits will be situated in the packet in their original order (but in this case, bit order is usually recovered at egress; one known exception is loss of multiframe synchronization between the TDM data and CAS bits introduced by a digital cross-connect acting as a Native Service Processing (NSP) block, see [TR-NWT-170]).
構造意識している輸送: 構造の少なくとも何らかのレベルを考慮に入れる構造化されたTDMの輸送。 構造意識している輸送で; TDMビットストリームのすべてのビットがPSNネットワークの上で輸送されるか(同期ビットと関連するオーバーヘッドは、明確に、イングレスで剥取られるかもしれなくて、通常、出口で作り直されるでしょう)、または輸送されたビットがパケットに位置するという保証が全くありません; それらのオリジナルでは、注文してください(TR-NWT-170は、この場合、通常、噛み付いているオーダーは出口で回復されます; 1つの知られている例外がネイティブのService Processing(NSP)ブロックとして機能するデジタル十字接続によって紹介されたTDMデータとCASビットの間の「マルチ-フレーム」同期の損失であることを見ます)。
1.2. SONET/SDH Circuits
1.2. Sonet/SDHサーキット
The term SONET refers to the North American Synchronous Optical NETwork as specified by [T1.105]. It is based on the concept of a Nx783 byte payload container repeated every 125us. This payload is referred to as an STS-1 SPE and may be concatenated into higher bandwidth circuits (e.g., STS-Nc) or sub-divided into lower bandwidth circuits (Virtual Tributaries). The higher bandwidth concatenated circuits can be used to carry anything from IP Packets to ATM cells to Digital Video Signals. Individual STS-1 SPEs are frequently used
Sonetという用語は指定されるとしての[T1.105]による北米のSynchronous Optical NETworkについて言及します。 Nx783バイトの概念に基づいてペイロード容器があらゆる125usを繰り返したということです。 このペイロードは、STS-1 SPEと呼ばれて、より高い帯域幅サーキット(例えば、STS-Nc)に連結されるか、または下側の帯域幅サーキット(仮想のTributaries)に細分されるかもしれません。 IP PacketsからATMセルまでの何でもDigital Video Signalsまで運ぶのにより高い帯域幅連結されたサーキットを使用できます。 個々のSTS-1 SPEsは頻繁に使用されます。
Riegel Informational [Page 4] RFC 4197 PWE3 TDM Requirements October 2005
[4ページ]RFC4197PWE3 TDM要件2005年10月の情報のリーゲル
to carry individual DS3 or E3 TDM circuits. When the 783 byte containers are sub-divided for lower rate payloads, they are frequently used to carry individual T1 or E1 TDM circuits.
個々のDS3か3EのTDMサーキットを運ぶために。 783バイトの容器が低料金ペイロードのために細分されるとき、それらは、個々のT1か1EのTDMサーキットを運ぶのに頻繁に使用されます。
The Synchronous Digital Hierarchy (SDH) is the international equivalent and enhancement of SONET and is specified by [G.707].
同期デジタルハイアラーキ(SDH)は、Sonetの国際的な同等物と増進であり、[G.707]によって指定されます。
Both SONET and SDH include a substantial amount of transport overhead that is used for performance monitoring, fault isolation, and other maintenance functions along different types of optical or electrical spans. This also includes a pointer-based mechanism for carrying payloads asynchronously. In addition, the payload area includes dedicated overhead for end-to-end performance monitoring, fault isolation, and maintenance for the service being carried. If the main payload area is sub-divided into lower rate circuits (such as T1/E1), additional overhead is included for end-to-end monitoring of the individual T1/E1 circuits.
SonetとSDHの両方が性能モニター、欠点孤立、および他の維持機能に異なったタイプの光学の、または、電気の長さに沿って使用されるかなりの量の輸送オーバーヘッドを含んでいます。 また、これはペイロードを非同期に運ぶためのポインタベースのメカニズムを含んでいます。 さらに、ペイロード領域は運ばれる終わりから終わりへの性能モニターのためのひたむきなオーバーヘッド、欠点孤立、およびサービスのための維持を含んでいます。 主なペイロード領域が低料金サーキット(1T1/Eなどの)に分筆されるなら、追加オーバーヘッドは1個々のT1/Eのサーキットの終わりから終わりへのモニターのために含まれています。
This document discusses the requirements for emulation of SONET/SDH services. These services include end-to-end emulation of the SONET payload (STS-1 SPE), emulation of concatenated payloads (STS-Nc SPE), as well as emulation of a variety of sub-STS-1 rate circuits jointly referred to as Virtual Tributaries (VT) and their SDH analogs.
このドキュメントはSonet/SDHサービスのエミュレーションのための要件について議論します。 これらのサービスはSonetペイロード(STS-1 SPE)のエミュレーション、連結されたペイロード(STS-Nc SPE)のエミュレーション、およびさまざまなサブSTS-1のレートサーキットのエミュレーションが共同でVirtual Tributaries(バーモント)と彼らのSDHアナログと呼んだ終わりから終わりを含んでいます。
2. Motivation
2. 動機
[RFC3916] specifies common requirements for edge-to-edge emulation of circuits of various types. However, these requirements, as well as references in [RFC3985], do not cover specifics of PWs carrying TDM circuits.
[RFC3916]は様々なタイプのサーキットの縁から縁へのエミュレーションのための一般的な要件を指定します。 しかしながら、[RFC3985]での参照と同様に、これらの要件はTDMサーキットを運ぶPWsの詳細をカバーしていません。
The need for a specific document to complement [RFC3916] addressing of edge-to-edge emulation of TDM circuits arises from the following:
特定のドキュメントが縁から縁へのTDMサーキットのエミュレーションの[RFC3916]アドレシングの補足となる必要性は以下から起こります:
o Specifics of the TDM circuits. For example,
o TDMサーキットの詳細。 例えば
* the need for balance between the clock of ingress and egress
attachment circuits in each direction of the Pseudo Wire (PW),
* Pseudo Wire(PW)の各方向へのイングレスの時計と出口付属サーキットの間のバランスの必要性
* the need to maintain jitter and wander of the clock of the
egress end service, within the limits imposed by the
appropriate normative documents, in the presence of the packet
delay variation produced by the PSN.
* 出口終わりのサービスの時計がパケット遅れ変化があるとき適切な標準のドキュメントによって課された限界の中をジターを維持して、歩き回る必要性はPSNによって生産されました。
o Specifics of applications using TDM circuits. For example, voice
applications,
o TDMサーキットを使用するアプリケーションの詳細。 例えば、アプリケーションを声に出してください。
* put special emphasis on minimization of one-way delay, and
* そして片道遅れの最小化に特別な強調を置いてください。
Riegel Informational [Page 5] RFC 4197 PWE3 TDM Requirements October 2005
[5ページ]RFC4197PWE3 TDM要件2005年10月の情報のリーゲル
* are relatively tolerant to errors in data.
* データにおける誤りに比較的許容性があります。
o Other applications might have different specifics. For example,
transport of signaling information
o 他のアプリケーションには、異なった詳細があるかもしれません。 例えば、シグナリング情報の輸送
* is relatively tolerant to one-way delay, and
* そして片道遅れに比較的許容性がある。
* is sensitive to errors in transmitted data.
* 伝えられたデータにおける誤りに、敏感です。
o Specifics of the customers' expectations regarding end-to-end
behavior of services that contain emulated TDM circuits. For
example, experience with carrying such services over SONET/SDH
networks increases the need for
o 終わりから終わりへの見習われたTDMサーキットを含むサービスの振舞いに関する顧客の期待の詳細。 例えば、そのようなものを運ぶのに、Sonet/SDHの上のネットワークが必要性を増加させるサービスを経験してください。
* isolation of problems introduced by the PSN from those
occurring beyond the PSN bounds,
* PSNを超えて起こることにおけるPSNによってそれらから紹介された問題の孤立はバウンドしています。
* sensitivity to misconnection,
* 付け違いへの感度
* sensitivity to unexpected connection termination, etc.
* 予期していなかった接続終了などへの感度
3. Terminology
3. 用語
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]で説明されるように本書では解釈されることであるべきですか?
The terms defined in [RFC3985], Section 1.4 are used consistently. However some terms and acronyms are used in conjunction with the TDM services. In particular:
用語が[RFC3985]で定義されて、セクション1.4は一貫して使用されます。 しかしながら、いくつかの用語と頭文字語がTDMサービスに関連して使用されます。 特に:
TDM networks employ Channel-Associated Signaling (CAS) or Common Channel Signaling (CCS) to supervise and advertise status of telephony applications, provide alerts to these applications (as to requests to connect or disconnect), and to transfer routing and addressing information. These signals must be reliably transported over the PSNs for the telephony end-systems to function properly.
電話アプリケーションの状態を監督して、広告を出すTDMネットワークの雇用のChannelが関連しているSignaling(CAS)かCommon Channel Signaling(CCS)、これらのアプリケーション(接続するか、または連絡を断つという要求に関する)と、そして、転送ルーティングとアドレス指定情報に警戒を提供してください。 電話エンドシステムが適切に機能するようにPSNsの上でこれらの信号を確かに輸送しなければなりません。
CAS (Channel-Associated Signaling)
CAS is carried in the same T1 or E1 frame as the voice signals,
but not in the speech band. Since CAS signaling may be
transferred at a rate slower than the TDM traffic in a timeslot,
one need not update all the CAS bits in every TDM frame. Hence,
CAS systems cycle through all the signaling bits only after some
number of TDM frames, which defines a new structure known as a
multiframe or superframe. Common multiframes are 12, 16, or 24
frames in length, corresponding to 1.5, 2, and 3 milliseconds in
duration.
CAS(チャンネルで関連しているSignaling)CASは声が示すように同じT1か1Eのフレームで運ばれますが、スピーチバンドで運ばれるというわけではありません。 timeslotのTDM交通より遅いレートでCASシグナリングを移すかもしれないので、1つはあらゆるTDMフレームですべてのCASビットをアップデートしなければならないというわけではありません。 したがって、CASシステムは何らかの数のTDMフレームの後にだけすべてのシグナリングビットを通して循環します。フレームは「マルチ-フレーム」か「スーパー-フレーム」として知られている新しい構造を定義します。 一般的な「マルチ-フレーム」は持続時間で1.5、2に対応する長さと3ミリセカンドと同じくらいの12、16、または24個のフレームです。
Riegel Informational [Page 6] RFC 4197 PWE3 TDM Requirements October 2005
[6ページ]RFC4197PWE3 TDM要件2005年10月の情報のリーゲル
CCS (Common Channel Signaling)
CCS signaling uses a separate digital channel to carry
asynchronous messages pertaining to the state of telephony
applications over related TDM timeslots of a TDM trunk. This
channel may be physically situated in one or more adjacent
timeslots of the same TDM trunk (trunk associated CCS) or may be
transported over an entirely separate network.
CCS(一般的なChannel Signaling)CCSシグナリングは、電話アプリケーションの状態に関係する非同期なメッセージをTDMトランクの関連するTDM timeslotsに伝えるのに別々のデジタル・チャンネルを使用します。 このチャンネルは、同じTDMトランク(トランクはCCSを関連づけた)の1隣接しているtimeslotsに物理的に位置しているか、または完全に別々のネットワークの上で輸送されるかもしれません。
CCS is typically HDLC-based, with idle codes or keep-alive
messages being sent until a signaling event (e.g., on-hook or
off-hook) occurs. Examples of HDLC-based CCS systems are SS7
[Q.700] and ISDN PRI signaling [Q.931].
シグナル伝達事象(例えば、フックかオフフックの)が起こるまで、CCSは無駄なコードで通常HDLCベースである、または送られるメッセージを生かします。 HDLCベースのCCSシステムに関する例は、SS7[Q.700]とISDN PRIシグナリング[Q.931]です。
Note: For the TDM network, we use the terms "jitter" and "wander" as defined in [G.810] to describe short- and long-term variance of the significant instants of the digital signal, while for the PSN we use the term packet delay variation (PDV) (see [RFC3393]).
以下に注意してください。 TDMネットワークのために、私たちは、ディジタル信号の重要な瞬間の短くて長期の変化について説明するために[G.810]で定義されるように「ジター」という用語を使用して、「歩き回ります」、私たちはPSNに、用語パケット遅れ変化(PDV)を使用しますが([RFC3393]を見てください)。
4. Reference Models
4. 規範モデル
4.1. Generic PWE3 Models
4.1. 一般的なPWE3モデル
Generic models that have been defined in [RFC3985] in sections
セクションの[RFC3985]で定義された一般的なモデル
- 4.1 (Network Reference Model), - 4.2 (PWE3 Pre-processing), - 4.3 (Maintenance Reference Model), - 4.4 (Protocol Stack Reference Model) and - 4.5 (Pre-processing Extension to Protocol Stack Reference Model).
- そして、4.1 (ネットワーク規範モデル)--4.2 (PWE3前処理)--4.3(メンテナンス規範モデル)--4.4(プロトコル・スタック規範モデル)、--4.5 (スタック規範モデルについて議定書の中で述べるために拡大を前処理します。)
They are fully applicable for the purposes of this document without modification.
それらはこのドキュメントの目的のために変更なしで完全に適切です。
All the services considered in this document represent special cases of the Bit-stream and Structured bit-stream payload type defined in Section 3.3 of [RFC3985].
本書では考えられたすべてのサービスが[RFC3985]のセクション3.3で定義されたBit-流れとStructuredビットストリームペイロードタイプの特別なケースを表します。
4.2. Clock Recovery
4.2. 時計回復
Clock recovery is extraction of the transmission bit timing information from the delivered packet stream. Extraction of this information from a highly jittered source, such as a packet stream, may be a complex task.
時計回復は渡されたパケットの流れからの情報を調節するトランスミッションビットの抽出です。 パケットの流れなどの非常にjitteredされた源からのこの情報の抽出は複雑なタスクであるかもしれません。
Riegel Informational [Page 7] RFC 4197 PWE3 TDM Requirements October 2005
[7ページ]RFC4197PWE3 TDM要件2005年10月の情報のリーゲル
4.3. Network Synchronization Reference Model
4.3. ネットワーク同期規範モデル
Figure 1 shows a generic network synchronization reference model.
図1は一般的なネットワーク同期規範モデルを示しています。
+---------------+ +---------------+
| PE1 | | PE2 |
K | +--+ | | +--+ | G
| | | J| | | | H| | |
v | v | | | v | | v
+---+ | +-+ +-+ +-+ | +--+ +--+ | +-+ +-+ +-+ | +---+
| | | |P| |D| |P| | | | | | | |P| |E| |P| | | |
| |<===|h|<:|e|<:|h|<:::| |<::| |<:::|h|<:|n|<=|h|<===| |
| | | |y| |c| |y| | | | | | | |y| |c| |y| | | |
| C | | +-+ +-+ +-+ | | | | | | +-+ +-+ +-+ | | C |
| E | | | |S1| |S2| | | | E |
| 1 | | +-+ +-+ +-+ | | | | | | +-+ +-+ +-+ | | 2 |
| | | |P| |E| |P| | | | | | | |P| |D| |P| | | |
| |===>|h|=>|n|:>|h|:::>| |::>| |:::>|h|:>|e|=>|h|===>| |
| | | |y| |c| |y| | | | | | | |y| |c| |y| | | |
+---+ | +-+ +-+ +-+ | +--+ +--+ | +-+ +-+ +-+ | +---+
^ ^ | | ^ | | | ^ | ^ ^
| | | |B | |<------+------>| | | | | |
| A | +--+ | | | +--+-E | F |
| +---------------+ +-+ +---------------+ |
| ^ |I| ^ |
| | +-+ | |
| C D |
+-----------------------------L-----------------------------+
+---------------+ +---------------+ | PE1| | PE2| K| +--+ | | +--+ | G| | | J| | | | H| | | v| v| | | v| | +に対して---+ | +-+ +-+ +-+ | +--+ +--+ | +-+ +-+ +-+ | +---+ | | | |P| |D| |P| | | | | | | |P| |E| |P| | | | | |<==|h|<: | e|<: | h|<:、:、:| |<:、:| |<:、:、:|h|<: | n|<=|h|<==| | | | | |y| |c| |y| | | | | | | |y| |c| |y| | | | | C| | +-+ +-+ +-+ | | | | | | +-+ +-+ +-+ | | C| | E| | | |S1| |S2| | | | E| | 1 | | +-+ +-+ +-+ | | | | | | +-+ +-+ +-+ | | 2 | | | | |P| |E| |P| | | | | | | |P| |D| |P| | | | | |===>|h|=>|n|:>| h|:::>| |::>| |:::>|h|:>| e|=>|h|===>|、|、|、|、| |y| |c| |y| | | | | | | |y| |c| |y| | | | +---+ | +-+ +-+ +-+ | +--+ +--+ | +-+ +-+ +-+ | +---+ ^ ^ | | ^ | | | ^ | ^ ^ | | | |B| | <、-、-、-、-、--+------>|、|、|、|、|、|、| A| +--+ | | | +--+E| F| | +---------------+ +-+ +---------------+ | | ^ |I| ^ | | | +-+ | | | C D| +-----------------------------L-----------------------------+
Figure 1: The Network Synchronization Reference Model
図1: ネットワーク同期規範モデル
The following notation is used in Figure 1:
以下の記法は図1で使用されます:
CE1, CE2
Customer edge devices terminating TDM circuits to be emulated.
CE1、見習われるためにTDMサーキットを終えるCE2 Customerエッジデバイス。
PE1, PE2
Provider edge devices adapting these end services to PW.
PE1、これらを適合させるPE2 ProviderエッジデバイスがPWに対するサービスを終わらせます。
S1, S2
Provider core routers.
S1、S2 Providerコアルータ。
Phy
Physical interface terminating the TDM circuit.
Phy Physicalは、TDMサーキットを終えながら、連結します。
Enc
PSN-bound interface of the PW, where the encapsulation takes
place.
PWのEnc PSN行きのインタフェース。そこでは、カプセル化が行われます。
Riegel Informational [Page 8] RFC 4197 PWE3 TDM Requirements October 2005
[8ページ]RFC4197PWE3 TDM要件2005年10月の情報のリーゲル
Dec
CE-bound interface of the PW, where the decapsulation takes place.
It contains a compensation buffer (also known as the "jitter
buffer") of limited size.
PWの12月のCE行きのインタフェース。そこでは、被膜剥離術が行われます。 それは限られたサイズに関する補償バッファ(また、「ジターバッファ」として、知られている)を含んでいます。
"==>"
TDM attachment circuits.
「=>」TDM付属サーキット。
"::>"
PW providing edge-to-edge emulation for the TDM circuit.
"::縁から縁へのエミュレーションをTDMサーキットに供給する">"PW。
The characters "A" - "L" denote various clocks:
キャラクタ「A」--「L」は様々な時計を指示します:
"A"
The clock used by CE1 for transmission of the TDM attachment
circuit towards CE1.
「時計がTDM付属サーキットのトランスミッションにCE1でCE1に向かって使用したA」。
"B"
The clock recovered by PE1 from the incoming TDM attachment
circuit. "A" and "B" always have the same frequency.
時計がPE1で入って来るTDM付属サーキットから回復した「B。」 「A」と「B」には、同じ頻度がいつもあります。
"G"
The clock used by CE2 for transmission of the TDM attachment
circuit towards CE2.
「時計がTDM付属サーキットのトランスミッションにCE2でCE2に向かって使用したG」。
"H"
The clock recovered by PE2 from the incoming TDM attachment
circuit. "G" and "H" always have the same frequency.
時計がPE2で入って来るTDM付属サーキットから回復した「H。」 「G」と「H」には、同じ頻度がいつもあります。
"C", "D"
Local oscillators available to PE1 and PE2, respectively.
「それぞれPE1とPE2に利用可能なC」、「D」局部発振器。
"E"
Clock used by PE2 to transmit the TDM attachment service circuit
to CE2 (the recovered clock).
CE2(回復している時計)にTDM付属サービスサーキットを伝えるのにPE2によって使用された「E」時計。
"F"
Clock recovered by CE2 from the incoming TDM attachment service
("E and "F" have the same frequency).
「F」時計がCE2によって入って来るTDM付属サービスから回収された、(「Eと「F」には同じ頻度がある、)、」
"I"
If the clock exists, it is the common network reference clock
available to PE1 and PE2.
「I」If、時計は存在していて、それはPE1とPE2に利用可能な一般的なネットワーク基準クロックです。
"J"
Clock used by PE1 to transmit the TDM attachment service circuit
to CE1 (the recovered clock).
CE1(回復している時計)にTDM付属サービスサーキットを伝えるのにPE1によって使用された「J」時計。
Riegel Informational [Page 9] RFC 4197 PWE3 TDM Requirements October 2005
[9ページ]RFC4197PWE3 TDM要件2005年10月の情報のリーゲル
"K"
Clock recovered by CE1 from the incoming TDM attachment service
("J" and "K" have the same frequency).
「K」ClockはCE1で入って来るTDM付属サービスから回復しました(「J」と「K」には、同じ頻度があります)。
"L"
If it exists, it is the common reference clock of CE1 and CE2.
Note that different pairs of CE devices may use different common
reference clocks.
「L」はそれであるなら存在していて、それはCE1とCE2の共通参照時計です。 異なった組のCE装置が異なった共通参照時計を使用するかもしれないことに注意してください。
A requirement of edge-to-edge emulation of a TDM circuit is that clock "B" and "E", as well as clock "H" and "J", are of the same frequency. The most appropriate method will depend on the network synchronization scheme.
縁から縁へのTDMサーキットのエミュレーションの要件はその時計「B」です、そして、時計「H」と同様に「E」と「J」は同じ頻度のものです。 最も適切な方法はネットワーク同期計画によるでしょう。
The following groups of synchronization scenarios can be considered:
同期シナリオの以下のグループを考えることができます:
4.3.1. Synchronous Network Scenarios
4.3.1. 同期ネットワークシナリオ
Depending on which part of the network is synchronized by a common clock, there are two scenarios:
ネットワークのどの部分は一般的な時計によって同期させられるかによって、2つのシナリオがあります:
o PE Synchronized Network:
o PEはネットワークを同期させました:
Figure 2 is an adapted version of the generic network reference
model, and presents the PE synchronized network scenario.
図2は、一般的なネットワーク規範モデルの適合しているバージョンであり、連動しているネットワークシナリオをPEに提示します。
The common network reference clock "I" is available to all the PE
devices, and local oscillators "C" and "D" are locked to "I":
一般的なネットワーク基準クロック「私」はすべてのPE装置に利用可能です、そして、局部発振器「C」と「D」は「私」にロックされます:
* Clocks "E" and "J" are the same as "D" and "C", respectively.
* 時計「E」と「J」は「D」と「C」とそれぞれ同じです。
* Clocks "A" and "G" are the same as "K" and "F", respectively
(i.e., CE1 and CE2 use loop timing).
* 時計「A」と「G」は「K」と「F」とそれぞれ同じです(すなわち、CE1とCE2は輪のタイミングを使用します)。
Riegel Informational [Page 10] RFC 4197 PWE3 TDM Requirements October 2005
[10ページ]RFC4197PWE3 TDM要件2005年10月の情報のリーゲル
+-----+ +-----+
+-----+ | |- - -|=================|- - -| | +-----+
| /-- |<---------|............PW1..............|<---------| <-\ |
|| CE | | | PE1 | | PE2 | | |CE2 ||
| \-> |--------->|............PW2..............|--------->| --/ |
+-----+ | |- - -|=================|- - -| | +-----+
+-----+ +-----+
^ ^
|C |D
+-----------+-----------+
|
+-+
|I|
+-+
+-----+ +-----+ +-----+ | |- - -|=================|- - -| | +-----+ | /-- | <、-、-、-、-、-、-、-、--、|............PW1…| <、-、-、-、-、-、-、-、--、| <。\ | || Ce| | | PE1| | PE2| | |CE2|| | \->。|、-、-、-、-、-、-、-、--、>|............PW2…|、-、-、-、-、-、-、-、--、>| --/ | +-----+ | |- - -|=================|- - -| | +-----+ +-----+ +-----+ ^ ^ |C|D+-----------+-----------+ | +-+ |I| +-+
Figure 2: PE Synchronized Scenario
図2: PEはシナリオを同期させました。
o CE Synchronized Network:
o Ceはネットワークを同期させました:
Figure 3 is an adapted version of the generic network reference
model, and presents the CE synchronized network scenario.
図3は、一般的なネットワーク規範モデルの適合しているバージョンであり、連動しているネットワークシナリオをCEに提示します。
The common network reference clock "L" is available to all the CE
devices, and local oscillators "A" and "G" are locked to "L":
一般的なネットワーク基準クロック「L」はすべてのCe装置に利用可能です、そして、局部発振器「A」と「G」は「L」に固定されます:
* Clocks "E" and "J" are the same as "G" and "A", respectively
(i.e., PE1 and PE2 use loop timing).
* 時計「E」と「J」は「G」と「A」とそれぞれ同じです(すなわち、PE1とPE2は輪のタイミングを使用します)。
+-----+ +-----+
+-----+ | |- - -|=================|- - -| | +-----+
| |<---------|............PW1..............|<---------| |
| CE1 | | | PE1 | | PE2 | | | CE2 |
| |--------->|............PW2..............|--------->| |
+-----+ | |- - -|=================|- - -| | +-----+
^ +-----+ +-----+ ^
|A G|
+----------------------------+------------------------------+
|
+-+
|L|
+-+
+-----+ +-----+ +-----+ | |- - -|=================|- - -| | +-----+ | | <、-、-、-、-、-、-、-、--、|............PW1…| <、-、-、-、-、-、-、-、--、|、|、| CE1| | | PE1| | PE2| | | CE2| | |、-、-、-、-、-、-、-、--、>|............PW2…|、-、-、-、-、-、-、-、--、>|、| +-----+ | |- - -|=================|- - -| | +-----+ ^ +-----+ +-----+ ^ |G| +----------------------------+------------------------------+ | +-+ |L| +-+
Figure 3: CE Synchronized Scenario
図3: Ceはシナリオを同期させました。
No timing information has to be transferred in these cases.
これらの場合でタイミング情報を全く移してはいけません。
Riegel Informational [Page 11] RFC 4197 PWE3 TDM Requirements October 2005
[11ページ]RFC4197PWE3 TDM要件2005年10月の情報のリーゲル
4.3.2. Relative Network Scenario
4.3.2. 相対的なネットワークシナリオ
In this case, each CE uses its own transmission clock source that must be carried across the PSN and recovered by the remote PE, respectively. The common PE clock "I" can be used as reference for this purpose.
この場合、各CEはPSNの向こう側に運ばれて、リモートPEがそれぞれ回復しなければならないそれ自身のトランスミッション時計ソースを使用します。 参照としてこのために一般的なPE時計「私」を使用できます。
Figure 4 shows the relative network scenario.
図4は相対的なネットワークシナリオを示しています。
The common network reference clock "I" is available to all the PE devices, and local oscillators "C" and "D" are locked to "I":
一般的なネットワーク基準クロック「私」はすべてのPE装置に利用可能です、そして、局部発振器「C」と「D」は「私」にロックされます:
o Clocks "A" and "G" are generated locally without reference to a
common clock.
o 時計「A」と「G」は一般的な時計の参照なしで局所的に発生します。
o Clocks "E" and "J" are generated in reference to a common clock
available at all PE devices.
o 時計「E」と「J」はすべてのPE装置で利用可能な一般的な時計に関して発生します。
In a slight modification of this scenario, one (but not both!) of the CE devices may use its receive clock as its transmission clock (i.e., use loop timing).
このシナリオ、CE装置の(両方だけでない!)が使用するかもしれない1のわずかな変更、それ、トランスミッション時計として時計を受けてください(すなわち、輪のタイミングを使用してください)。
|G
+-----+ +-----+ v
+-----+ | |- - -|=================|- - -| | +-----+
| |<---------|............PW1..............|<---------| |
| CE1 | | | PE1 | | PE2 | | | CE2 |
| |--------->|............PW2..............|--------->| |
+-----+ | |- - -|=================|- - -| | +-----+
^ +-----+<-------+------->+-----+
|A |
+-+
|I|
+-+
| G+-----+ +-----+ +に対して-----+ | |- - -|=================|- - -| | +-----+ | | <、-、-、-、-、-、-、-、--、|............PW1…| <、-、-、-、-、-、-、-、--、|、|、| CE1| | | PE1| | PE2| | | CE2| | |、-、-、-、-、-、-、-、--、>|............PW2…|、-、-、-、-、-、-、-、--、>|、| +-----+ | |- - -|=================|- - -| | +-----+ ^ +-----+ <。-------+------->+-----+ |A| +-+ |I| +-+
Figure 4: Relative Network Scenario Timing
図4: 相対的なネットワークシナリオタイミング
In this case, timing information (the difference between the common reference clock "I" and the incoming clock "A") MUST be explicitly transferred from the ingress PE to the egress PE.
この場合、イングレスPEから出口PEまで明らかに、タイミング情報(共通参照時計「I」と入って来る時計「A」の違い)を移さなければなりません。
4.3.3. Adaptive Network Scenario
4.3.3. 適応型のネットワークシナリオ
The adaptive scenario is characterized by:
適応型のシナリオは以下によって特徴付けられます。
o No common network reference clock "I" is available to PE1 and PE2.
o 一般的なネットワーク基準クロックでない「私」はPE1とPE2に利用可能です。
o No common reference clock "L" is available to CE1 and CE2.
o どんな共通参照時計も「L」CE1とCE2に利用可能ではありません。
Riegel Informational [Page 12] RFC 4197 PWE3 TDM Requirements October 2005
[12ページ]RFC4197PWE3 TDM要件2005年10月の情報のリーゲル
Figure 5 presents the adaptive network scenario.
図5は適応型のネットワークシナリオを提示します。
|J |G
v |
+-----+ +-----+ v
+-----+ | |- - -|=================|- - -| | +-----+
| |<---------|............PW1..............|<---------| |
| CE1 | | | PE1 | | PE2 | | | CE2 |
| |--------->|............PW2..............|--------->| |
+-----+ | |- - -|=================|- - -| | +-----+
^ +-----+ +-----+
| ^
A| E|
| J|G v| +-----+ +-----+ +に対して-----+ | |- - -|=================|- - -| | +-----+ | | <、-、-、-、-、-、-、-、--、|............PW1…| <、-、-、-、-、-、-、-、--、|、|、| CE1| | | PE1| | PE2| | | CE2| | |、-、-、-、-、-、-、-、--、>|............PW2…|、-、-、-、-、-、-、-、--、>|、| +-----+ | |- - -|=================|- - -| | +-----+ ^ +-----+ +-----+ | ^A| E|
Figure 5: Adaptive Scenario
図5: 適応型のシナリオ
Synchronizing clocks "A" and "E" in this scenario is more difficult than it is in the other scenarios.
他のシナリオではこのシナリオで時計「A」と「E」を連動させるのはそれより難しいです。
Note that the tolerance between clocks "A" and "E" must be small enough to ensure that the jitter buffer does not overflow or underflow.
時計「A」と「E」の間の寛容がジターバッファがあふれないのを保証できるくらいわずかでなければならないというメモかアンダーフロー。
In this case, timing information MAY be explicitly transferred from the ingress PE to the egress PE, e.g., by RTP.
この場合、タイミング情報はイングレスPEから出口PE、例えば、RTPによって明らかに移されるかもしれません。
5. Emulated Services
5. 見習われたサービス
This section defines requirements for the payload and encapsulation layers for edge-to-edge emulation of TDM services with bit-stream payload as well as structured bit-stream payload.
このセクションは縁から縁への構造化されたビットストリームペイロードと同様にビットストリームペイロードによるTDMサービスのエミュレーションのためにペイロードとカプセル化層のための要件を定義します。
Wherever possible, the requirements specified in this document SHOULD be satisfied by appropriate arrangements of the encapsulation layer only. The (rare) cases when the requirements apply to both the encapsulation and payload layers (or even to the payload layer only) will be explicitly noted.
どこでも、可能であるところでは、要件が本書ではSHOULDを指定しました。カプセル化層の適切なアレンジメントだけで、満たされています。 要件がカプセル化とペイロード層の両方(またはペイロード層だけにさえ)に適用されるとき、(まれ)のケースは明らかに注意されるでしょう。
The service-specific encapsulation layer for edge-to-edge emulation comprises the following services over a PSN.
縁から縁へのエミュレーションのためのサービス特有のカプセル化層はPSNの上に以下のサービスを含みます。
5.1. Structure-Agnostic Transport of Signals out of the PDH Hierarchy
5.1. PDH階層構造からの信号の構造不可知論者輸送
Structure-agnostic transport is considered for the following signals:
構造不可知論者輸送は以下の信号のために考えられます:
o E1 as described in [G.704].
o [G.704]で説明される1E。
o T1 (DS1) as described in [G.704].
o [G.704]で説明されるT1(DS1)。
Riegel Informational [Page 13] RFC 4197 PWE3 TDM Requirements October 2005
[13ページ]RFC4197PWE3 TDM要件2005年10月の情報のリーゲル
o E3 as defined in [G.751].
o [G.751]で定義される3ユーロ。
o T3 (DS3) as described in [T1.107].
o [T1.107]で説明されるT3(DS3)。
5.2. Structure-Aware Transport of Signals out of the PDH Hierarchy
5.2. PDH階層構造からの信号の構造意識している輸送
Structure-aware transport is considered for the following signals:
構造意識している輸送は以下の信号のために考えられます:
o E1/T1 with one of the structures imposed by framing as described
in [G.704].
o 構造の1つがある1/T1Eが[G.704]で説明されるように縁どりででしゃばりました。
o NxDS0 with or without CAS.
o CASのあるなしにかかわらずNxDS0。
5.3. Structure-Aware Transport of SONET/SDH Circuits
5.3. Sonet/SDHサーキットの構造意識している輸送
Structure-aware transport is considered for the following SONET/SDH circuits:
構造意識している輸送は以下のSonet/SDHサーキットと考えられます:
o SONET STS-1 synchronous payload envelope (SPE)/SDH VC-3.
o SONET STS-1の同期ペイロード封筒(SPE)/SDH VC-3。
o SONET STS-Nc SPE (N = 3, 12, 48, 192) / SDH VC-4, VC-4-4c,
VC-4-16c, VC-4-64c.
o Sonet STS-Nc SPE(N=3、12、48、192)/SDH VC-4、VC-4-4c、VC-4-16c、VC-4-64c。
o SONET VT-N (N = 1.5, 2, 3, 6) / SDH VC-11, VC-12, VC-2.
o Sonetバーモント-N(N=1.5、2、3、6)/SDH VC-11、VC-12、VC-2。
o SONET Nx VT-N / SDH Nx VC-11/VC-12/VC-2/VC-3.
o Sonet Nxバーモント-N/SDH Nx VC-11/VC-12/VC-2/VC-3。
Note: There is no requirement for the structure-agnostic transport of SONET/SDH. For this case, it would seem that structure must be taken into account.
以下に注意してください。 Sonet/SDHの構造不可知論者輸送のための要件が全くありません。 このような場合、構造を考慮に入れなければならないように思えるでしょう。
6. Generic Requirements
6. 一般的な要件
6.1. Relevant Common PW Requirements
6.1. 関連一般的なPW要件
The encapsulation and payload layers MUST conform to the common PW requirements defined in [RFC3916]:
カプセル化とペイロード層は[RFC3916]で定義された一般的なPW要件に一致しなければなりません:
1. Conveyance of Necessary Header Information:
1. 必要なヘッダー情報の運送:
A. For structure-agnostic transport, this functionality MAY be
provided by the payload layer.
A. 構造不可知論者輸送において、ペイロード層のそばでこの機能性を提供するかもしれません。
B. For structure-aware transport, the necessary information MUST
be provided by the encapsulation layer.
B. 構造意識している輸送において、カプセル化層のそばで必要事項を提供しなければなりません。
Riegel Informational [Page 14] RFC 4197 PWE3 TDM Requirements October 2005
[14ページ]RFC4197PWE3 TDM要件2005年10月の情報のリーゲル
C. Structure-aware transport of SONET/SDH circuits MUST preserve
path overhead information as part of the payload. Relevant
components of the transport overhead MAY be carried in the
encapsulation layer.
Sonet/SDHサーキットのC.の構造意識している輸送はペイロードの一部として経路オーバーヘッド情報を保存しなければなりません。 輸送オーバーヘッドの関連コンポーネントはカプセル化層の中で運ばれるかもしれません。
2. Support of Multiplexing and Demultiplexing if supported by the
native services. This is relevant for Nx DS0 circuits (with or
without signaling) and Nx VT-x in a single STS-1 SPE or VC-4.:
2. MultiplexingとDemultiplexingのサポート、ネイティブのサービスで支持されるなら。 Nx DS0サーキット(シグナリングのあるなしにかかわらず)とNxバーモント-xにおいて、これが独身のSTS-1 SPEかVC-4で関連している、:
A. For these circuits, the combination of encapsulation and
payload layers MUST provide for separate treatment of every
sub-circuit.
A. これらのサーキットに、カプセル化とペイロード層の組み合わせはあらゆるサブサーキットの別々の処理に備えなければなりません。
B. Enough information SHOULD be provided by the pseudo wire to
allow multiplexing and demultiplexing by the NSP. Reduction
of the complexity of the PW emulation by using NSP circuitry
for multiplexing and demultiplexing MAY be the preferred
solution.
B.十分な情報SHOULD、許容する疑似ワイヤマルチプレクシングと逆多重化で、NSPによって提供されてください。 マルチプレクシングと逆多重化にNSP回路を使用するのによるPWエミュレーションの複雑さの減少は都合のよい解決策であるかもしれません。
3. Intervention or transparent transfer of Maintenance Messages of
the Native Services, depending on the particular scenario.
3. 特定のシナリオによるネイティブのServicesのMaintenance Messagesの介入かわかりやすい転送。
4. Consideration of Per-PSN Packet Overhead (see also Section 7.5
below).
4. Per-PSN Packet Overhead(また、以下のセクション7.5を見る)の考慮。
5. Detection and handling of PW faults. The list of faults is given
in Section 7.9 below.
5. PW欠点の検出と取り扱い。 セクション7.9で欠点のリストを以下に与えます。
Fragmentation indications MAY be used for structure-aware transport when the structures in question either exceed desired packetization delay or exceed Path MTU between the pair of PEs.
問題の構造が必要なpacketization遅れを超えているか、またはPEsの組の間でPath MTUを超えているとき、断片化指摘は構造意識している輸送に使用されるかもしれません。
The following requirement listed in [RFC3916] is not applicable to emulation of TDM services:
[RFC3916]にリストアップされた以下の要件はTDMサービスのエミュレーションに適切ではありません:
o Support of variable length PDUs.
o 可変長PDUsのサポート。
6.2. Common Circuit Payload Requirements
6.2. 一般的なサーキット有効搭載量要件
Structure-agnostic transport treats TDM circuits as belonging to the 'Bit-stream' payload type defined in [RFC3985].
構造不可知論者輸送は[RFC3985]で定義された'ビットストリーム'ペイロードタイプに属すとしてTDMサーキットを扱います。
Structure-aware transport treats these circuits as belonging to the "Structured bit-stream" payload type defined in [RFC3985].
構造意識している輸送は[RFC3985]で定義された「構造化されたビットストリーム」ペイロードタイプに属すとしてこれらのサーキットを扱います。
Accordingly, the encapsulation layer MUST provide the common Sequencing service and SHOULD provide Timing information (Synchronization services) when required (see Section 4.3 above).
それに従って、カプセル化層は一般的なSequencingサービスを供給しなければなりません、そして、必要であると、SHOULDは情報(同期サービス)をTimingに供給します(セクション4.3が上であることを見てください)。
Riegel Informational [Page 15] RFC 4197 PWE3 TDM Requirements October 2005
[15ページ]RFC4197PWE3 TDM要件2005年10月の情報のリーゲル
Note: Length service MAY be provided by the encapsulation layer, but is not required.
以下に注意してください。 長さのサービスをカプセル化層のそばで提供するかもしれませんが、必要としません。
6.3. General Design Issues
6.3. 一般デザイン問題
The combination of payload and encapsulation layers SHOULD comply with the general design principles of the Internet protocols as presented in Section 3 of [RFC1958] and [RFC3985].
SHOULDがインターネットプロトコルの一般的な設計原理に応じるペイロードとカプセル化層の組み合わせはセクションに[RFC1958]と3[RFC3985]を提示しました。
If necessary, the payload layer MAY use some forms of adaptation of the native TDM payload in order to achieve specific, well-documented design objectives. In these cases, standard adaptation techniques SHOULD be used.
必要なら、ペイロード層は、特定の、そして、よく記録された設計目標を達成するのにいくつかの形式のネイティブのTDMペイロードの適合を使用するかもしれません。 これらのケース、標準の適合テクニックSHOULD、使用されてください。
7. Service-Specific Requirements
7. サービス特有の要件
7.1. Connectivity
7.1. 接続性
1. The emulation MUST support the transport of signals between
Attachment Circuits (ACs) of the same type (see Section 5) and,
wherever appropriate, bit-rate.
1. エミュレーションは同じタイプ(セクション5を見る)とどこでも、適切であるところのビット伝送速度のAttachment Circuits(ACs)の間の信号の輸送を支持しなければなりません。
2. The encapsulation layer SHOULD remain unaffected by specific
characteristics of connection between the ACs and PE devices at
the two ends of the PW.
2. カプセル化層のSHOULDはPWの2つの端にACsとPE装置との接続の特定の特性で影響を受けないままで残っています。
7.2. Network Synchronization
7.2. ネットワーク同期
1. The encapsulation layer MUST provide synchronization services
that are sufficient to:
1. カプセル化層は以下に十分な同期サービスを提供しなければなりません。
A. match the ingress and egress end service clocks regardless of
the specific network synchronization scenario, and
そしてA. 特定のネットワーク同期シナリオにかかわらずイングレスと出口エンドサービス時計を合わせてください。
B. keep the jitter and wander of the egress service clock within
the service-specific limits defined by the appropriate
normative references.
B. ジターを保ってください、そして、適切な引用規格で定義されたサービス特有の限界の中を出口サービス時計を歩き回ってください。
2. If the same high-quality synchronization source is available to
all the PE devices in the given domain, the encapsulation layer
SHOULD be able to make use of it (e.g., for better reconstruction
of the native service clock).
2. 与えられたドメインのすべてのPE装置について、同じ高品質な同期ソースがあるなら、カプセル化はSHOULDを層にします。それ(例えば、ネイティブのサービス時計の、より良い再建のための)を利用できてください。
7.3. Robustness
7.3. 丈夫さ
The robustness of the emulated service depends not only upon the edge-to-edge emulation protocol, but also upon proper implementation of the following procedures.
見習われたサービスの丈夫さは縁から縁へのエミュレーションプロトコルによるだけではなく、以下の手順の適切な履行にもよります。
Riegel Informational [Page 16] RFC 4197 PWE3 TDM Requirements October 2005
[16ページ]RFC4197PWE3 TDM要件2005年10月の情報のリーゲル
7.3.1. Packet loss
7.3.1. パケット損失
Edge-to-edge emulation of TDM circuits MAY assume very low probability of packet loss between ingress and egress PE. In particular, no retransmission mechanisms are required.
縁から縁へのTDMサーキットのエミュレーションはイングレスと出口PEの間のパケット損失の非常に低い確率を仮定するかもしれません。 「再-トランスミッション」メカニズムは全く特に、必要ではありません。
In order to minimize the effect of lost packets on the egress service, the encapsulation layer SHOULD:
無くなっているパケットの出口への効果を最小にするために、サービス、カプセル化はSHOULDを層にします:
1. Enable independent interpretation of TDM data in each packet by
the egress PE (see [RFC2736]). This requirement MAY be
disregarded if the egress PE needs to interpret structures that
exceed the path MTU between the ingress and egress PEs.
1. 出口PEのそばで各パケットのTDMデータの独立している解釈を可能にしてください([RFC2736]を見てください)。 出口PEが、イングレスと出口PEsの間で経路MTUを超えている構造を解釈する必要があるなら、この要件は無視されるかもしれません。
2. Allow reliable detection of lost packets (see next section). In
particular, it SHOULD allow estimation of the arrival time of the
next packet and detection of lost packets based on this estimate.
2. 無くなっているパケットの信頼できる検出を許してください(次のセクションを見てください)。 特にそれ、SHOULDは次のパケットの到着時間に関する見積りとこの見積りに基づく無くなっているパケットの検出を許します。
3. Minimize possible effect of lost packets on recovery of the
circuit clock by the egress PE.
3. 出口PEのそばでサーキット時計の回復への無くなっているパケットの可能な効果を最小にしてください。
4. Increase the resilience of the CE TDM interface to packet loss by
allowing the egress PE to substitute appropriate data.
4. 出口PEが適切なデータを代入するのを許容することによって、CE TDMインタフェースの弾力をパケット損失に増加させてください。
7.3.2. Out-of-order delivery
7.3.2. 不適切な配送
The encapsulation layer MUST provide the necessary mechanisms to guarantee ordered delivery of packets carrying the TDM data over the PSN. Packets that have arrived out-of-order:
PSNの上までTDMデータを運んで、カプセル化層は、命令されたパケットの配信を保証するために必要なメカニズムを提供しなければなりません。 故障していた状態で到着したパケット:
1. MUST be detected, and
1. そして検出しなければならない。
2. SHOULD be reordered if not judged to be too late or too early for
playout.
2. SHOULDは再命令されたか、または判断しました。遅過ぎるか、または再生に早くなり過ぎるように。
Out-of-order packets that cannot be reordered MUST be treated as lost.
同じくらい無くなった状態で再命令できない故障しているパケットを扱わなければなりません。
7.4. CE Signaling
7.4. Ceシグナリング
Unstructured TDM circuits would not usually require any special mechanism for carrying CE signaling as this would be carried as part of the emulated service.
通常、不統一なTDMサーキットは、これが見習われたサービスの一部として運ばれるだろうというのに従ってCEシグナリングを運ぶためにどんな特別なメカニズムも必要としないでしょう。
Some CE applications using structured TDM circuits (e.g., telephony) require specific signaling that conveys the changes of state of these applications relative to the TDM data.
構造化されたTDMサーキット(例えば、電話)を使用するいくつかのCEアプリケーションがTDMデータに比例してこれらのアプリケーションの状態の変化を運ぶ特定のシグナリングを必要とします。
Riegel Informational [Page 17] RFC 4197 PWE3 TDM Requirements October 2005
[17ページ]RFC4197PWE3 TDM要件2005年10月の情報のリーゲル
The encapsulation layer SHOULD support signaling of state of CE applications for the relevant circuits providing for:
以下に提供される関連サーキットのCEアプリケーションの状態のカプセル化層のSHOULDサポートシグナリング
1. Ability to support different signaling schemes with minimal
impact on encapsulation of TDM data,
1. TDMデータのカプセル化への最小量の影響で異なったシグナリング計画を支持する能力
2. Multiplexing of application-specific CE signals and data of the
emulated service in the same PW,
2. アプリケーション特有のCE信号のマルチプレクシングと同じPWでの見習われたサービスに関するデータ
3. Synchronization (within the application-specific tolerance
limits) between CE signals and data at the PW egress,
3. PW出口のCE信号とデータの間の同期(アプリケーション特有の寛容限界の中の)
4. Probabilistic recovery against possible, occasional loss of
packets in the PSN, and
4. そしてPSNのパケットの可能で、時々の損失に対する確率的な回復。
5. Deterministic recovery of the CE application state after PW setup
and network outages.
5. PWが供給停止をセットアップして、ネットワークでつないだ後にCEアプリケーション状態の決定論的な回復。
CE signaling that is used for maintenance purposes (loopback commands, performance monitoring data retrieval, etc.) SHOULD use the generic PWE3 maintenance protocol.
維持目的(ループバックコマンド、性能のモニターしているデータの検索など)に使用されるCEシグナリング SHOULDは一般的なPWE3維持プロトコルを使用します。
7.5. PSN Bandwidth Utilization
7.5. PSN帯域幅利用
1. The encapsulation layer SHOULD allow for an effective trade-off
between the following requirements:
1. カプセル化層のSHOULDは以下の要件の間の有効なトレードオフを考慮します:
A. Effective PSN bandwidth utilization. Assuming that the size
of the encapsulation layer header does not depend on the size
of its payload, an increase in the packet payload size
results in increased efficiency.
A.の有効なPSN帯域幅利用。 パケットペイロードサイズの増加は増加する効率をもたらして、カプセル化層のヘッダーのサイズをペイロードのサイズに依存しないと仮定します。
B. Low edge-to-edge latency. Low end-to-end latency is the
common requirement for Voice applications over TDM services.
Packetization latency is one of the components comprising
edge-to-edge latency, and it decreases with the packet
payload size.
B.縁から縁への低い潜在。 低端から端への潜在はTDMサービスの上のVoiceアプリケーションのための一般的な要件です。 Packetization潜在は縁から縁への潜在を包括するコンポーネントの1つです、そして、パケットペイロードサイズに従って、それは減少します。
The compensation buffer used by the CE-bound IWF increases
latency to the emulated circuit. Additional delays introduced by
this buffer SHOULD NOT exceed the packet delay variation observed
in the PSN.
CE行きのIWFによって使用された補償バッファは見習われたサーキットへの潜在を高めます。 このバッファSHOULD NOTによって導入された追加遅れはPSNで観察されたパケット遅れ変化を超えています。
2. The encapsulation layer MAY provide for saving PSN bandwidth by
not sending corrupted TDM data across the PSN.
2. カプセル化層は崩壊したTDMデータを使いにやらないのによる帯域幅をPSNに救うのにPSNを提供するかもしれません。
Riegel Informational [Page 18] RFC 4197 PWE3 TDM Requirements October 2005
[18ページ]RFC4197PWE3 TDM要件2005年10月の情報のリーゲル
3. The encapsulation layer MAY provide the ability to save the PSN
bandwidth for the structure-aware case by not sending channels
that are permanently inactive.
3. カプセル化層は構造意識しているケースのために永久に不活発なチャンネルを送らないことによってPSN帯域幅を貯蓄する能力を提供するかもしれません。
4. The encapsulation layer MAY enable the dynamic suppression of
temporarily unused channels from transmission for the structure-
aware case.
4. カプセル化層は構造の意識しているケースのためのトランスミッションから一時未使用のチャンネルのダイナミックな抑圧を可能にするかもしれません。
If used, dynamic suppression of temporarily unused channels
MUST NOT violate the integrity of the structures delivered over
the PW.
使用されるなら、一時未使用のチャンネルのダイナミックな抑圧はPWの上に渡された構造の保全に違反してはいけません。
5. For NxDS0, the encapsulation layer MUST provide the ability to
keep the edge-to-edge delay independent of the service rate.
5. NxDS0のために、カプセル化層はサービス率の如何にかかわらず縁から縁が遅れであることを保つ能力を提供しなければなりません。
7.6. Packet Delay Variation
7.6. パケット遅れ変化
The encapsulation layer SHOULD provide for the ability to compensate for packet delay variation, while maintaining jitter and wander of the egress end service clock with tolerances specified in the normative references.
カプセル化層のSHOULDはジターを維持している間、パケット遅れ変化を補う能力に備えて、寛容が引用規格で指定されている状態で、出口エンドサービス時計を歩き回ります。
The encapsulation layer MAY provide for run-time adaptation of delay introduced by the jitter buffer if the packet delay variation varies with time. Such an adaptation MAY introduce a low level of errors (within the limits tolerated by the application) but SHOULD NOT introduce additional wander of the egress end service clock.
カプセル化層は時間に従ってパケット遅れ変化が異なるならジターバッファによって導入された遅れのランタイム適合に備えるかもしれません。 そのような適合が(アプリケーションで許容された限界の中の)SHOULD NOTだけが導入する誤りの低レベルを導入するかもしれない、追加、出口エンドサービス時計を歩き回ってください。
7.7. Compatibility with the Existing PSN Infrastructure
7.7. 既存のPSNインフラストラクチャとの互換性
The combination of encapsulation and PSN tunnel layers used for edge- to-edge emulation of TDM circuits SHOULD be compatible with existing PSN infrastructures. In particular, compatibility with the mechanisms of header compression over links where capacity is at a premium SHOULD be provided.
カプセル化の組み合わせとPSNトンネル層は縁へのTDMの縁のエミュレーションにサーキットSHOULDを使用しました。既存のPSNインフラストラクチャと互換性があってください。 事項、容量がaプレミアムSHOULDにあるリンクの上のヘッダー圧縮のメカニズムとの互換性に、提供してください。
7.8. Congestion Control
7.8. 輻輳制御
TDM circuits run at a constant rate, and hence offer constant traffic loads to the PSN. The rate varying mechanism that TCP uses to match the demand to the network congestion state is, therefore, not applicable.
TDMサーキットは、一定のトラヒック負荷をPSNに一定の割合で走って、したがって、提供します。 したがって、TCPがネットワークの混雑状態に要求に匹敵するのに使用するメカニズムを変えるレートは適切ではありません。
The ability to shut down a TDM PW when congestion has been detected MUST be provided.
混雑が検出されたときTDM PWを止める能力を提供しなければなりません。
Riegel Informational [Page 19] RFC 4197 PWE3 TDM Requirements October 2005
[19ページ]RFC4197PWE3 TDM要件2005年10月の情報のリーゲル
Precautions should be taken to avoid situations wherein multiple TDM PWs are simultaneously shut down or re-established, because this leads to PSN instability.
複数のTDM PWsが同時に止められるか、または復職する状況を避けるために注意するべきです、これがPSNの不安定性に通じるので。
Further congestion considerations are discussed in chapter 6.5 of [RFC3985].
さらなる混雑問題は[RFC3985]の第6.5章で論じられます。
7.9. Fault Detection and Handling
7.9. 欠点検出と取り扱い
The encapsulation layer for edge-to-edge emulation of TDM services SHOULD, separately or in conjunction with the lower layers of the PWE3 stack, provide for detection, handling, and reporting of the following defects:
縁から縁へのSHOULDが別々にかPWE3スタックの下層に関連して検出に提供するTDMサービスのエミュレーション、取り扱い、および以下の欠陥の報告のためのカプセル化層:
1. Misconnection, or Stray Packets. The importance of this
requirement stems from customer expectation due to reliable
misconnection detection in SONET/SDH networks.
1. 付け違い、または迷っているパケット。 この要件の重要性は信頼できる付け違い検出による顧客の期待にSonet/SDHネットワークでよります。
2. Packet Loss. Packet loss detection is required to maintain clock
integrity, as discussed in Section 7.3.1 above. In addition,
packet loss detection mechanisms SHOULD provide for localization
of the outage in the end-to-end emulated service.
2. パケット損失。 パケット損失検出が、時計保全を維持するのに上のセクション7.3.1で議論するように必要です。 さらに、パケット損失検出メカニズムSHOULDは終わらせる終わりでの供給停止の見習われたサービスのローカライズに備えます。
3. Malformed packets.
3. 誤った形式のパケット。
7.10. Performance Monitoring
7.10. パフォーマンスモニター
The encapsulation layer for edge-to-edge emulation of TDM services SHOULD provide for collection of performance monitoring (PM) data that is compatible with the parameters defined for 'classic', TDM-based carriers of these services. The applicability of [G.826] is left for further study.
縁から縁へのSHOULDが'クラシック'(これらのサービスのTDMを拠点とするキャリヤー)のために定義されたパラメタと互換性がある性能モニターしている(PM)データの収集に提供するTDMサービスのエミュレーションのためのカプセル化層。 [G.826]の適用性はさらなる研究に発たれます。
8. Security Considerations
8. セキュリティ問題
The security considerations in [RFC3916] are fully applicable to the emulation of TDM services. In addition, TDM services are sensitive to packet delay variation [Section 7.6], and need to be protected from this method of attack.
[RFC3916]のセキュリティ問題はTDMサービスのエミュレーションに完全に適切です。 さらに、TDMサービスは、パケット遅れ変化[セクション7.6]に敏感であり、この攻撃方法から保護される必要があります。
9. References
9. 参照
9.1. Normative References
9.1. 引用規格
[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月。
Riegel Informational [Page 20] RFC 4197 PWE3 TDM Requirements October 2005
[20ページ]RFC4197PWE3 TDM要件2005年10月の情報のリーゲル
9.2. Informative References
9.2. 有益な参照
[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月。
[G.702] ITU-T Recommendation G.702 (11/88) - Digital hierarchy
bit rates
[G.702]ITU-T Recommendation G.702(11/88)--デジタル階層構造ビット伝送速度
[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.706] ITU-T Recommendation G.706 (04/91) - Frame alignment and
cyclic redundancy check (CRC) procedures relating to
basic frame structures defined in Recommendation G.704
[G.706]ITU-T Recommendation G.706(04/91)--Recommendation G.704で定義された基本枠構造に関連するフレーム整列と周期冗長検査(CRC)手順
[G.707] ITU-T Recommendation G.707 (10/00) - Network node
interface for the synchronous digital hierarchy (SDH)
[G.707]ITU-T Recommendation G.707(10/00)--同期デジタル階層構造のためのネットワーク・ノードインタフェース(SDH)
[G.751] ITU-T Recommendation G.751 (11/88) - Digital multiplex
equipments operating at the third order bit rate of 34
368 Kbit/s and the fourth order bit rate of 139 264
Kbit/s and using positive justification
[G.751]ITU-T Recommendation G.751(11/88)--34の3番目のオーダービット伝送速度で139 264のキロビット/sと使用の積極的な正当化の368キロビット/sと四次のビット伝送速度を操作するデジタルマルチプレックス機器
[G.810] ITU-T Recommendation G.810 (08/96) - Definitions and
terminology for synchronization networks
[G.810]ITU-T Recommendation G.810(08/96)--同期ネットワークのための定義と用語
[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)--レートにおける第一のレートより上における国際的で、一定のビット伝送速度デジタル経路への誤り性能パラメタと目的
[Q.700] ITU-T Recommendation Q.700 (03/93) - Introduction to
CCITT Signalling System No. 7
[Q.700]ITU-T推薦Q.700(03/93)--CCITT合図システムNo.7への序論
[Q.931] ITU-T Recommendation Q.931 (05/98) - ISDN user-network
interface layer 3 specification for basic call control
[Q.931]ITU-T Recommendation Q.931(05/98)--基本的な呼び出しコントロールのためのISDNユーザネットワーク・インターフェース層の3仕様
[RFC1958] Carpenter, B., "Architectural Principles of the
Internet", RFC 1958, June 1996.
[RFC1958] 1996年6月の大工、B.、「インターネットの建築プリンシプルズ」RFC1958。
[RFC2736] Handley, M. and C. Perkins, "Guidelines for Writers of
RTP Payload Format Specifications", BCP 36, RFC 2736,
December 1999.
[RFC2736]ハンドレー、M.とC.パーキンス、「RTP有効搭載量書式仕様の作家へのガイドライン」BCP36、1999年12月のRFC2736。
Riegel Informational [Page 21] RFC 4197 PWE3 TDM Requirements October 2005
[21ページ]RFC4197PWE3 TDM要件2005年10月の情報のリーゲル
[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay
Variation Metric for IP Performance Metrics (IPPM)", RFC
3393, November 2002.
[RFC3393]デミチェリスとC.とP.Chimento、「IPパフォーマンス測定基準(IPPM)における、メートル法のIPパケット遅れ変化」、RFC3393、2002年11月。
[T1.105] ANSI T1.105 - 2001 Synchronous Optical Network (SONET) -
Basic Description including Multiplex Structure, Rates,
and Formats, May 2001
[T1.105]ANSI T1.105--2001年の同期式光通信網(Sonet)--2001年5月にMultiplex Structure、Rates、およびFormatsを含む基本的な記述
[T1.107] ANSI T1.107 - 1995. Digital Hierarchy - Format
Specification
[T1.107]ANSI T1.107--1995。 デジタル階層構造--書式仕様
[TR-NWT-170] Digital Cross Connect Systems - Generic Requirements and
Objectives, Bellcore, TR-NWT-170, January 1993
[TR-NWT-170]デジタル十字はシステムを接続します--要件目的、ジェネリックBellcore、TR-NWT-170、1993年1月
10. Contributors Section
10. 貢献者部
The following have contributed to this document:
以下はこのドキュメントに貢献しました:
Sasha Vainshtein Axerra Networks
サシャVainshtein Axerraネットワーク
EMail: sasha@axerra.com
メール: sasha@axerra.com
Yaakov Stein RAD Data Communication
YaakovシタインRAD、データ通信
EMail: yaakov_s@rad.com
メール: yaakov_s@rad.com
Prayson Pate Overture Networks, Inc.
Prayson頭のオーバーチュアはInc.をネットワークでつなぎます。
EMail: prayson.pate@overturenetworks.com
メール: prayson.pate@overturenetworks.com
Ron Cohen Lycium Networks
ロンコーエンLyciumネットワーク
EMail: ronc@lyciumnetworks.com
メール: ronc@lyciumnetworks.com
Tim Frost Zarlink Semiconductor
ティムフロストZarlink Semiconductor
EMail: tim.frost@zarlink.com
メール: tim.frost@zarlink.com
Riegel Informational [Page 22] RFC 4197 PWE3 TDM Requirements October 2005
[22ページ]RFC4197PWE3 TDM要件2005年10月の情報のリーゲル
Author's Address
作者のアドレス
Maximilian Riegel Siemens AG St-Martin-Str 76 Munich 81541 Germany
マクシミリアンリーゲルジーメンス株式会社通りマーチンStr76ミュンヘン81541ドイツ
Phone: +49-89-636-75194 EMail: maximilian.riegel@siemens.com
以下に電話をしてください。 +49-89-636-75194 メールしてください: maximilian.riegel@siemens.com
Riegel Informational [Page 23] RFC 4197 PWE3 TDM Requirements October 2005
[23ページ]RFC4197PWE3 TDM要件2005年10月の情報のリーゲル
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
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 currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Riegel Informational [Page 24]
リーゲルInformationalです。[24ページ]
一覧
スポンサーリンク
