[要約] 要約:RFC 4197は、パケットスイッチングネットワーク上での時分割多重(TDM)回線のエッジ間エミュレーションに関する要件を定義しています。目的:このRFCの目的は、TDM回線をパケットスイッチングネットワーク上でエミュレートするための要件を提供し、異なるネットワーク技術間の互換性を確保することです。

Network Working Group                                          M. Riegel
Request for Comments: 4197                                    Siemens AG
Category: Informational                                     October 2005
        

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)The Internet Society(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.

このドキュメントでは、プレシオクロナスデジタル階層のマルチプレックス(TDM)デジタル信号と同期光学ネットワーク/パケットスイッチネットワーク上の同期光ネットワーク/同期デジタル階層のエッジとエッジのエミュレーションの特定の要件を定義します。擬似ワイヤエミュレーションエッジとエッジ(PWE3)の共通アーキテクチャに整合しています。PWE3の一般的な要件に言及し、該当する場合は、TDM回路の詳細から発生する要件を定義することによりそれらを補完します。

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. 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.

このドキュメントでは、プレシオクロナスデジタル階層(PDH)のマルチプレックスされた(TDM)デジタル信号と同期光学ネットワーク(SONET)/同期デジタル階層(SDH)のエッジトゥエッジエッジエミュレーションの特定の要件を定義します。パケットスイッチネットワーク(PSN)。[RFC3985]で定義されているように、擬似ワイヤエミュレーションエッジとエッジ(PWE3)の共通アーキテクチャに整合しています。TDM回路の詳細から発生する要件を定義することにより、[RFC3916]の要件を参照し、[RFC3916]を補完します[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.

このドキュメントでは、「TDM」という用語は、PDHまたはSONET/SDH階層のいずれかに属する同期ビットストリームの一般的な記述子として使用されます。

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.544 MbpsのT1ビットストリームと44.736 MbpsのT3ビットストリームが義務付けられていますが、ヨーロッパでは2.048 MbpsのE1ビットストリームと34.368 MbpsのE3ビットストリームが利用されます。

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.

TDMは、[G.702]で定義されたレートで非構造化ビットストリームを運ぶために使用できますが、フレームと呼ばれるより大きなユニットにビットストリームを運ぶ標準化された方法がありますが、各フレームには同じ数のビットが含まれています。

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.

音声トラフィックのサンプリング周波数に関連するビットレートは常に8000の倍数であるため、T1フレームは193ビットと256ビットのE1フレームで構成されています。フレーム内のビット数はフレームサイズと呼ばれます。

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フレーミングビット、E1フレームごとに8フレーミングビットのシーケンス)。これらのフレーミングビットの生成方法の詳細は、[G.704]、[G.706]、および[G.751]で解明されています。フレームなし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は、各フレームの同じ位置で繰り返される一連の「タイムスロット」のシーケンスで、複数のチャネル(たとえば、それぞれが8000 8ビットサンプルで構成される音声チャネル)を多重化するためによく使用されます。この多重化は「チャネル化されたTDM」と呼ばれ、追加の構造を導入します。

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:フレーム、チャネル化、マルチフェームを含む1つ以上のレベルの構造描写を備えたTDM(例:[G.704]、[G.751]、および[T1.107]で定義されています)。

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ネットワーク上で輸送されるという保証はありません(具体的には、同期ビットと関連するオーバーヘッドが侵入時に剥がされる可能性があり、通常は出口で再生される可能性があります)または輸送されたビットは、元の順序でパケットに配置されます(ただし、この場合、ビット順序は通常出口で回収されます。1つの既知の例外は、TDMデータとデジタルクロスコネクトによって導入されたCASビット間のマルチフレーム同期の損失です。ネイティブサービス処理(NSP)ブロック、[TR-NWT-170]を参照)。

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 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.

ソネットという用語は、[T1.105]で指定されている北米同期光ネットワークを指します。これは、125USごとに繰り返されるNX783バイトペイロードコンテナの概念に基づいています。このペイロードはSTS-1 SPEと呼ばれ、より高い帯域幅の回路(STS-NCなど)に連結するか、下部帯域幅回路(仮想支流)に下位になっている場合があります。より高い帯域幅の連結回路を使用して、IPパケットからATMセル、デジタルビデオ信号まであらゆるものを運ぶことができます。個々のSTS-1 SPEは、個々のDS3またはE3 TDM回路を運ぶために頻繁に使用されます。783バイトのコンテナが低レートのペイロードのために下位区別されると、個々のT1またはE1 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の両方に、パフォーマンス監視、障害分離、およびさまざまなタイプの光学または電気スパンに沿ったその他のメンテナンス機能に使用されるかなりの量の輸送間頭部が含まれています。これには、ペイロードを非同期に運ぶためのポインターベースのメカニズムも含まれます。さらに、ペイロードエリアには、エンドツーエンドのパフォーマンス監視、障害分離、および運ばれるサービスのメンテナンスに関する専用のオーバーヘッドが含まれています。メインのペイロード領域が低レート回路(T1/E1など)に細分されている場合、個々のT1/E1回路のエンドツーエンドモニタリングのために追加のオーバーヘッドが含まれています。

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レート回路のエミュレーションが含まれます。仮想支流(VT)とその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回路を運ぶPWの詳細をカバーしていません。

The need for a specific document to complement [RFC3916] addressing of edge-to-edge emulation of TDM circuits arises from the following:

特定のドキュメントがTDM回路のエッジツーエッジエミュレーションのアドレス指定を補完する必要性は、次のものから生じます。

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),

* 擬似ワイヤの各方向(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

* 一元配置遅延の最小化に特に重点を置き、

* 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].

「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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ネットワークは、チャネル関連シグナル伝達(CAS)または共通チャネルシグナル(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(チャネル関連のシグナル伝達)CASは、音声信号と同じT1またはE1フレームに運ばれますが、音声帯域では運ばれません。CASシグナル伝達は、タイムスロットのTDMトラフィックよりも遅い速度で転送される可能性があるため、すべてのTDMフレームのすべてのCASビットを更新する必要はありません。したがって、CASシステムは、多数のTDMフレームの後にのみすべてのシグナルビットを循環します。これは、マルチフレームまたはスーパーフレームとして知られる新しい構造を定義します。一般的なマルチフレームは、長さが12、16、または24フレームで、1.5、2、および3ミリ秒に対応しています。

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(共通チャネルシグナル伝達)CCSシグナル伝達は、TDMトランクの関連するTDMタイムスロットを介したテレフォニーアプリケーションの状態に関する非同期メッセージを個別のデジタルチャネルを使用します。このチャネルは、同じTDMトランク(トランク関連CCS)の1つまたは複数の隣接するタイムスロットに物理的に位置するか、完全に別々のネットワーク上で輸送される場合があります。

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で定義されているビットストリームおよび構造化されたビットストリームペイロードタイプの特別なケースを表しています。

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.

クロックリカバリは、配信されたパケットストリームからの送信ビットタイミング情報の抽出です。パケットストリームなど、高度にジッタリングされたソースからこの情報を抽出することは、複雑なタスクかもしれません。

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-----------------------------+
        

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、CE2カスタマーエッジデバイスは、TDM回路をエミュレートすることを終了します。

PE1, PE2 Provider edge devices adapting these end services to PW.

PE1、PE2プロバイダーエッジデバイスこれらの最終サービスをPWに適応させます。

S1, S2 Provider core routers.

S1、S2プロバイダーコアルーター。

Phy Physical interface terminating the TDM circuit.

TDM回路を終了するPHY物理インターフェイス。

Enc PSN-bound interface of the PW, where the encapsulation takes place.

カプセル化が行われるPWのPSNバインドインターフェイス。

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の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.

「A」CE1にTDMアタッチメント回路を送信するためにCE1が使用するクロック。

"B" The clock recovered by PE1 from the incoming TDM attachment circuit. "A" and "B" always have the same frequency.

「B」は、着信TDMアタッチメント回路からPE1によって回収されたクロック。「A」と「B」には常に同じ頻度があります。

"G" The clock used by CE2 for transmission of the TDM attachment circuit towards CE2.

「G」CE2へのTDMアタッチメント回路の伝送のためにCE2が使用するクロック。

"H" The clock recovered by PE2 from the incoming TDM attachment circuit. "G" and "H" always have the same frequency.

「H」は、着信TDMアタッチメント回路からPE2によって回収されたクロック。「G」と「H」には常に同じ頻度があります。

"C", "D" Local oscillators available to PE1 and PE2, respectively.

「C」、「D」は、それぞれPE1とPE2が利用できます。

"E" Clock used by PE2 to transmit the TDM attachment service circuit to CE2 (the recovered clock).

TDMアタッチメントサービス回路をCE2(回復したクロック)に送信するためにPE2が使用する「E」クロック。

"F" Clock recovered by CE2 from the incoming TDM attachment service ("E and "F" have the same frequency).

「F」クロックは、着信TDMアタッチメントサービスからCE2によって回収されました( "eおよび" f "の周波数は同じです)。

"I" If the clock exists, it is the common network reference clock available to PE1 and PE2.

「I」クロックが存在する場合、それはPE1とPE2が利用できる一般的なネットワーク参照クロックです。

"J" Clock used by PE1 to transmit the TDM attachment service circuit to CE1 (the recovered clock).

TDMアタッチメントサービス回路をCE1(回復したクロック)に送信するためにPE1が使用する「J」クロック。

"K" Clock recovered by CE1 from the incoming TDM attachment service ("J" and "K" have the same frequency).

「k」クロックは、着信TDMアタッチメントサービス( "j"と "k"の周波数が同じ)からCE1によって回収されました。

"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」と「E」、およびクロック「H」と「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":

一般的なネットワーク参照クロック「I」はすべてのPEデバイスで使用でき、ローカルオシレーター「C」と「D」は「I」にロックされています。

* 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はループタイミングを使用します)。

                       +-----+                 +-----+
      +-----+    |     |- - -|=================|- - -|     |    +-----+
      | /-- |<---------|............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|
                                    +-+
        

Figure 3: CE Synchronized Scenario

図3:CE同期シナリオ

No timing information has to be transferred in these cases.

これらの場合には、タイミング情報を転送する必要はありません。

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クロック「I」は、この目的のための参照として使用できます。

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":

一般的なネットワーク参照クロック「I」はすべてのPEデバイスで使用でき、ローカルオシレーター「C」と「D」は「I」にロックされています。

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|
                                  +-+
        

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.

この場合、タイミング情報(一般的な参照クロック「I」と着信クロック「A」の差)は、入り込みPEから出口PEに明示的に転送する必要があります。

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が利用できる一般的なネットワーク参照クロック「I」はありません。

o No common reference clock "L" is available to CE1 and CE2.

o CE1およびCE2には一般的な参照クロック「L」は使用できません。

Figure 5 presents the adaptive network scenario.

図5は、適応ネットワークシナリオを示しています。

                     |J                                       |G
                     v                                        |
                    +-----+                 +-----+           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.

この場合、タイミング情報は、rtpによって、侵入PEから出口PEに明示的に転送される場合があります。

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.

可能な限り、このドキュメントで指定された要件は、カプセル化レイヤーの適切な配置によってのみ満たされる必要があります。要件がカプセル化層とペイロード層の両方に適用される(またはペイロードレイヤーのみ)(まれな)ケースが明示的に記録されます。

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]で説明されているE1。

o T1 (DS1) as described in [G.704].

o [G.704]で説明されているT1(DS1)。

o E3 as defined in [G.751].

o [G.751]で定義されているE3。

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 [G.704]で説明されているように、フレーミングによって課される構造の1つを使用したE1/T1。

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 VT-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 VT-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.構造認識輸送のために、必要な情報はカプセル化層によって提供される必要があります。

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.

C. SONET/SDH回路の構造認識輸送は、ペイロードの一部としてパスオーバーヘッド情報を保存する必要があります。輸送オーバーヘッドの関連コンポーネントは、カプセル化層に運ばれる場合があります。

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. ネイティブサービスでサポートされている場合、多重化と非複数形のサポート。これは、単一のSTS-1 SPEまたはVC-4のNX DS0回路(シグナリングの有無にかかわらず)およびNX VT-Xに関連しています。

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.擬似ワイヤによって十分な情報を提供する必要があります。NSP回路を使用して多重化と脱臼の複雑さを減らすことが好ましいソリューションである可能性があります。

3. Intervention or transparent transfer of Maintenance Messages of the Native Services, depending on the particular scenario.

3. 特定のシナリオに応じて、ネイティブサービスのメンテナンスメッセージの介入または透明な転送。

4. Consideration of Per-PSN Packet Overhead (see also Section 7.5 below).

4. PSNあたりのパケット間の考慮事項の考慮事項(以下のセクション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.

問題の構造が望ましいパケット化遅延を超えるか、PEのペア間のパスMTUを超える場合、断片化適応症は構造認識輸送に使用される場合があります。

The following requirement listed in [RFC3916] is not applicable to emulation of TDM services:

[RFC3916]にリストされている以下の要件は、TDMサービスのエミュレーションには適用されません。

o Support of variable length PDUs.

o 可変長PDUのサポート。

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].

構造に依存しない輸送は、TDM回路を[RFC3985]で定義された「ビットストリーム」ペイロードタイプに属するものとして扱います。

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).

したがって、カプセル化層は共通のシーケンスサービスを提供する必要があり、必要に応じてタイミング情報(同期サービス)を提供する必要があります(上記のセクション4.3を参照)。

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].

ペイロード層とカプセル化層の組み合わせは、[RFC1958]および[RFC3985]のセクション3に示されているように、インターネットプロトコルの一般的な設計原則に準拠する必要があります。

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ペイロードの何らかの形の適応を使用する場合があります。これらの場合、標準的な適応手法を使用する必要があります。

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. エミュレーションは、同じタイプのアタッチメントサーキット(ACS)間の信号の輸送(セクション5を参照)と、適切な場合はビットレートをサポートする必要があります。

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. カプセル化層は、PWの両端にある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デバイスが同じ高品質の同期ソースを使用できる場合、カプセル化層はそれを利用できるはずです(たとえば、ネイティブサービスクロックのより良い再構築のために)。

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.

エミュレートされたサービスの堅牢性は、エッジツーエッジエミュレーションプロトコルだけでなく、次の手順の適切な実装にも依存します。

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:

失われたパケットの出力サービスに対する影響を最小限に抑えるために、カプセル化層は次のとおりです。

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が、入り口と出口の間の経路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. 失われたパケットの信頼できる検出を許可します(次のセクションを参照)。特に、次のパケットの到着時間の推定と、この推定に基づいて失われたパケットの検出を可能にするはずです。

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. Egress 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. プレイアウトには遅すぎる、または早すぎると判断されない場合は、並べ替える必要があります。

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データに対するこれらのアプリケーションの状態の変更を伝える特定のシグナル伝達が必要です。

The encapsulation layer SHOULD support signaling of state of CE applications for the relevant circuits providing for:

カプセル化層は、次のことを提供する関連する回路のCEアプリケーションの状態のシグナル伝達をサポートする必要があります。

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. 同じPWでのエミュレートサービスのアプリケーション固有のCE信号とデータの多重化、

3. Synchronization (within the application-specific tolerance limits) between CE signals and data at the PW egress,

3. CEシグナルとPWエグレスのデータとの間の同期(アプリケーション固有の許容限界内)、

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シグナル(ループバックコマンド、パフォーマンス監視データ取得など)は、汎用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. カプセル化層は、次の要件間の効果的なトレードオフを可能にする必要があります。

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サービスを介した音声アプリケーションの一般的な要件です。パケット化のレイテンシは、エッジからエッジのレイテンシを構成するコンポーネントの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で使用される補償バッファーは、エミュレートされた回路のレイテンシを増加させます。このバッファーによって導入された追加の遅延は、PSNで観察されたパケット遅延変動を超えてはなりません。

2. The encapsulation layer MAY provide for saving PSN bandwidth by not sending corrupted TDM data across the PSN.

2. カプセル化層は、PSN全体で破損したTDMデータを送信しないことにより、PSN帯域幅を保存することを提供する場合があります。

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.

カプセル化レイヤーは、パケット遅延の変動を補う能力を提供する必要がありますが、ジッターと出口エンドサービスクロックのさまようことを、規範的な参照で指定された許容範囲を維持します。

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.

カプセル化層は、パケット遅延の変動が時間とともに変化する場合、ジッターバッファーによって導入された遅延のランタイム適応を提供する場合があります。このような適応は、低レベルのエラーを導入する可能性があります(アプリケーションによって容認される制限内)が、出口末端のサービスクロックの追加のさまようことを導入すべきではありません。

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.

TDM回路のエッジ間エミュレーションに使用されるカプセル化とPSNトンネル層の組み合わせは、既存のPSNインフラストラクチャと互換性があるはずです。特に、容量がプレミアムにあるリンク上のヘッダー圧縮のメカニズムとの互換性を提供する必要があります。

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をシャットダウンする機能を提供する必要があります。

Precautions should be taken to avoid situations wherein multiple TDM PWs are simultaneously shut down or re-established, because this leads to PSN instability.

PSNの不安定性につながるため、複数のTDM PWが同時にシャットダウンまたは再確立される状況を避けるために注意を払う必要があります。

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:

TDMサービスのエッジツーエッジエミュレーション用のカプセル化層は、PWE3スタックの下層と組み合わせて、次の欠陥の検出、取り扱い、および報告を提供する必要があります。

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で説明するように、クロックの完全性を維持するには、パケット損失の検出が必要です。さらに、パケット損失検出メカニズムは、エンドツーエンドのエミュレートサービスの停止のローカリゼーションを提供する必要があります。

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.

TDMサービスのエッジツーエッジエミュレーション用のカプセル化レイヤーは、これらのサービスのTDMベースのキャリア、「クラシック」に定義されたパラメーターと互換性のあるパフォーマンス監視(PM)データの収集を提供する必要があります。[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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。

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.、McPherson、D。、およびP. Pate、「擬似ワイヤーエミュレーションエッジとエッジ(PWE3)の要件」、RFC 3916、2004年9月。

[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.

[RFC3985] Bryant、S。およびP. Pate、「Pseudo Wire Emulation Edge-to-Edge(PWE3)アーキテクチャ」、RFC 3985、2005年3月。

[G.702] ITU-T Recommendation G.702 (11/88) - Digital hierarchy bit rates

[G.702] ITU -T推奨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推奨G.704(10/98) - 1544、6312、2048、8448および44 736 Kbit/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の推奨G.706(04/91) - 推奨で定義された基本的なフレーム構造に関連するフレームアライメントおよび環状冗長チェック(CRC)手順G.704

[G.707] ITU-T Recommendation G.707 (10/00) - Network node interface for the synchronous digital hierarchy (SDH)

[G.707] ITU -T推奨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の推奨G.751(11/88) - 34 368 KBIT/sの3次ビットレートで動作するデジタルマルチプレックス機器と139 264 KBIT/sの4次ビットレートで動作し、正の正当化を使用して

[G.810] ITU-T Recommendation G.810 (08/96) - Definitions and terminology for synchronization networks

[G.810] ITU -T推奨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推奨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の推奨事項Q.931(05/98)-ISDNユーザーネットワークインターフェイスレイヤー3基本コールコントロールの仕様

[RFC1958] Carpenter, B., "Architectural Principles of the Internet", RFC 1958, June 1996.

[RFC1958]カーペンター、B。、「インターネットの建築原理」、RFC 1958、1996年6月。

[RFC2736] Handley, M. and C. Perkins, "Guidelines for Writers of RTP Payload Format Specifications", BCP 36, RFC 2736, December 1999.

[RFC2736] Handley、M。およびC. Perkins、「RTPペイロード形式の仕様の作家のためのガイドライン」、BCP 36、RFC 2736、1999年12月。

[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)", RFC 3393, November 2002.

[RFC3393] Demichelis、C。およびP. Chimento、「IPパフォーマンスメトリック(IPPM)のIPパケット遅延変動メトリック」、RFC 3393、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月

[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] Digital Cross Connect Systems-ジェネリック要件と目標、Bellcore、TR-NWT-170、1993年1月

10. Contributors Section
10. 貢献者セクション

The following have contributed to this document:

以下はこのドキュメントに貢献しています。

Sasha Vainshtein Axerra Networks

サーシャヴァインシュテインアクセラネットワーク

   EMail: sasha@axerra.com
        

Yaakov Stein RAD Data Communication

Yaakov Stein Radデータ通信

   EMail: yaakov_s@rad.com
        

Prayson Pate Overture Networks, Inc.

Prayson Pate Overtuer Networks、Inc。

   EMail: prayson.pate@overturenetworks.com
        

Ron Cohen Lycium Networks

Ron Cohen Lycium Networks

   EMail: ronc@lyciumnetworks.com
        

Tim Frost Zarlink Semiconductor

Tim Frost Zarlink半導体

   EMail: tim.frost@zarlink.com
        

Author's Address

著者の連絡先

Maximilian Riegel Siemens AG St-Martin-Str 76 Munich 81541 Germany

Maximilian Riegel Siemens Ag St-Martin-Str76 Munich 81541ドイツ

   Phone: +49-89-636-75194
   EMail: maximilian.riegel@siemens.com
        

Full Copyright Statement

完全な著作権声明

Copyright (C) The Internet Society (2005).

Copyright(c)The Internet Society(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.

この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織(もしあれば)が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。

Intellectual Property

知的財産

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。

Acknowledgement

謝辞

Funding for the RFC Editor function is currently provided by the Internet Society.

RFCエディター機能の資金は現在、インターネット協会によって提供されています。