[要約] RFC 7893は、仮想回線の過負荷に関する考慮事項を提供する。その目的は、仮想回線の過負荷によるパフォーマンスの低下を最小限に抑えるためのガイドラインを提供することである。
Internet Engineering Task Force (IETF) Y(J) Stein
Request for Comments: 7893 RAD Data Communications
Category: Informational D. Black
ISSN: 2070-1721 EMC Corporation
B. Briscoe
BT
June 2016
Pseudowire Congestion Considerations
疑似配線の輻輳に関する考慮事項
Abstract
概要
Pseudowires (PWs) have become a common mechanism for tunneling traffic and may be found in unmanaged scenarios competing for network resources both with other PWs and with non-PW traffic, such as TCP/IP flows. Thus, it is worthwhile specifying under what conditions such competition is acceptable, i.e., the PW traffic does not significantly harm other traffic or contribute more than it should to congestion. We conclude that PWs transporting responsive traffic behave as desired without the need for additional mechanisms. For inelastic PWs (such as Time Division Multiplexing (TDM) PWs), we derive a bound under which such PWs consume no more network capacity than a TCP flow. For TDM PWs, we find that the level of congestion at which the PW can no longer deliver acceptable TDM service is never significantly greater, and is typically much lower, than this bound. Therefore, as long as the PW is shut down when it can no longer deliver acceptable TDM service, it will never do significantly more harm than even a single TCP flow. If the TDM service does not automatically shut down, a mechanism to block persistently unacceptable TDM pseudowires is required.
疑似配線（PW）は、トラフィックをトンネリングするための一般的なメカニズムになり、他のPWと、TCP / IPフローなどの非PWトラフィックの両方とネットワークリソースを競合する非管理対象シナリオで見られる場合があります。したがって、そのような競争が許容される条件の下で指定することは価値があります。つまり、PWトラフィックは他のトラフィックに大きな悪影響を与えたり、輻輳に必要以上に寄与したりしません。レスポンシブトラフィックを転送するPWは、追加のメカニズムを必要とせずに、期待どおりに動作すると結論付けます。非弾性PW（時分割多重（TDM）PWなど）の場合、そのようなPWがTCPフローよりも多くのネットワーク容量を消費しない範囲を導出します。 TDM PWの場合、PWが許容可能なTDMサービスを提供できなくなる輻輳レベルは、この限界よりも大幅に高くなることはなく、通常ははるかに低くなります。したがって、受け入れ可能なTDMサービスを提供できなくなったときにPWがシャットダウンされる限り、単一のTCPフローよりもはるかに大きな害を及ぼすことは決してありません。 TDMサービスが自動的にシャットダウンしない場合は、永続的に受け入れられないTDM疑似配線をブロックするメカニズムが必要です。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7893.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7893で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. PWs Comprising Elastic Flows . . . . . . . . . . . . . . . . 6
4. PWs Comprising Inelastic Flows . . . . . . . . . . . . . . . 7
5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . . . . 19
7. Informative References . . . . . . . . . . . . . . . . . . . 19
Appendix A. Loss Probabilities for TDM PWs . . . . . . . . . . . 22
Appendix B. Effect of Packet Loss on Voice Quality for
Structure-Aware TDM PWs . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
A pseudowire (PW) (see [RFC3985]) is a construct for tunneling a native service, such as Ethernet or TDM, over a Packet Switched Network (PSN), such as IPv4, IPv6, or MPLS. The PW packet encapsulates a unit of native service information by prepending the headers required for transport in the particular PSN (which must include a demultiplexer field to distinguish the different PWs) and preferably the 4-byte Pseudowire Emulation Edge-to-Edge (PWE3) control word.
疑似配線（PW）（[RFC3985]を参照）は、IPv4、IPv6、MPLSなどのパケット交換ネットワーク（PSN）を介して、イーサネットやTDMなどのネイティブサービスをトンネリングするための構成体です。 PWパケットは、特定のPSN（さまざまなPWを区別するためにデマルチプレクサフィールドを含める必要があります）と、できれば4バイトの疑似配線エミュレーションエッジツーエッジ（PWE3）での転送に必要なヘッダーを付加することにより、ネイティブサービス情報のユニットをカプセル化します。コントロールワード。
PWs have no bandwidth reservation or control mechanisms, meaning that when multiple PWs are transported in parallel, and/or in parallel with other flows, there is no defined means for allocating resources for any particular PW, or for preventing the negative impact of a particular PW on neighboring flows. The case where the service provider network provisions a PW with sufficient capacity is well understood and will not be discussed further here. Concerns arise when PWs share network capacity with elastic or congestion-responsive traffic, whether that capacity sharing was planned by a service provider or results from PW deployment by an end user.
PWには帯域幅予約または制御メカニズムがありません。つまり、複数のPWが並行して、または他のフローと並行して転送される場合、特定のPWにリソースを割り当てたり、特定のPWの悪影響を防ぐための定義された手段はありません。隣接するフローのPW。サービスプロバイダーネットワークが十分な容量のPWをプロビジョニングするケースはよく理解されているため、ここではこれ以上説明しません。 PWがネットワークキャパシティをエラスティックトラフィックまたは輻輳対応トラフィックと共有する場合、その容量の共有がサービスプロバイダーによって計画されたものか、エンドユーザーによるPW展開の結果であるかに関係なく、懸念が生じます。
PWs are most often placed in MPLS tunnels, but we herein restrict ourselves to PWs in IPv4 or IPv6 PSNs; MPLS PSNs are beyond the scope of this document. There are several mechanisms that enable transporting PWs over an IP infrastructure, including:
PWはほとんどの場合MPLSトンネルに配置されますが、ここではIPv4またはIPv6 PSNのPWに限定します。 MPLS PSNはこのドキュメントの範囲外です。 IPインフラストラクチャを介したPWの転送を可能にするメカニズムには、次のものがあります。
o UDP/IP encapsulations as defined for TDM PWs [RFC4553] [RFC5086] [RFC5087],
o TDM PWに定義されたUDP / IPカプセル化[RFC4553] [RFC5086] [RFC5087]、
o PWs based on Layer 2 Tunneling Protocol (L2TPv3) [RFC3931],
o レイヤ2トンネリングプロトコル（L2TPv3）に基づくPW [RFC3931]、
o MPLS PWs directly over IP according to RFC 4023 [RFC4023], and
o RFC 4023 [RFC4023]に従ってIPを介して直接MPLS PW、および
o MPLS PWs over Generic Routing Encapsulation (GRE) over IP according to RFC 4023 [RFC4023].
o RFC 4023 [RFC4023]に準拠したMPLS PWs over Generic Routing Encapsulation（GRE）over IP。
Whenever PWs are transported over IP, they may compete for network resources with neighboring congestion-responsive flows (e.g., TCP flows). In this document, we study the effect of PWs on such neighboring flows, and discover that the negative impact of PW traffic is generally no worse than that of congestion-responsive flows [RFC2914] [RFC5033].
PWがIPを介して転送されるときはいつでも、ネットワークリソースを求めて、隣接する輻輳対応フロー（TCPフローなど）と競合する可能性があります。このドキュメントでは、PWがこのような隣接するフローに及ぼす影響を調査し、PWトラフィックの悪影響が、通常、輻輳対応フロー[RFC2914] [RFC5033]の悪影響よりも悪いことはないことを発見しました。
At first glance, one may consider a PW transported over IP to be considered as a single flow, on par with a single TCP flow. Were we to accept this tenet, we would require a PW to back off under congestion to consume no more bandwidth than a single TCP flow under such conditions (see [RFC5348]). However, since PWs may carry traffic from many users, it makes more sense to consider each PW to be equivalent to multiple TCP flows.
一見すると、IP経由で転送されたPWは、単一のTCPフローと同等の単一のフローと見なされる場合があります。この原則を受け入れるとしたら、そのような状況で単一のTCPフローよりも多くの帯域幅を消費しないように、輻輳下でPWがバックオフする必要があります（[RFC5348]を参照）。ただし、PWは多くのユーザーからのトラフィックを運ぶ可能性があるため、各PWを複数のTCPフローと同等であると見なす方が理にかなっています。
The following two sections consider PWs of two types:
次の2つのセクションでは、2つのタイプのPWについて検討します。
Elastic Flows: Section 3 concludes that the response to congestion of a PW carrying elastic (e.g., TCP) flows is no different from the aggregated behaviors of the individual elastic flows, had they not been encapsulated within a PW.
エラスティックフロー：セクション3では、PW内にカプセル化されていなければ、エラスティック（TCPなど）フローを運ぶPWの輻輳に対する応答は、個々のエラスティックフローの集約された動作と同じであると結論付けています。
Inelastic Flows: Section 4 considers the case of inelastic constant bit rate (CBR) TDM PWs [RFC4553] [RFC5086] [RFC5087] competing with TCP flows. Such PWs require a preset amount of bandwidth, that may be lower or higher than that consumed by an otherwise unconstrained TCP flow under the same network conditions. In any case, such a PW is unable to respond to congestion in a TCP-like manner; although admittedly the total bandwidth it consumes remains constant and does not increase to consume additional bandwidth as TCP rates back off. For TDM services, we will show that TDM service quality degradation generally occurs before the TDM PW becomes TCP-unfriendly. For TDM services that do not automatically shut down when they persistently fail to comply with acceptable TDM service criteria, a transport circuit breaker [CIRCUIT-BREAKER] may be employed as a last resort to shut down a TDM pseudowire that can no longer deliver acceptable service.
非弾性フロー：セクション4では、非弾性固定ビットレート（CBR）TDM PW [RFC4553] [RFC5086] [RFC5087]がTCPフローと競合する場合について検討します。このようなPWには事前設定された量の帯域幅が必要です。これは、同じネットワーク条件下で他の制約のないTCPフローによって消費される帯域幅よりも低いか高い場合があります。いずれの場合でも、そのようなPWはTCPのような方法で輻輳に応答することができません。確かに、消費する総帯域幅は一定のままで、TCPレートが低下しても追加の帯域幅を消費するように増加することはありません。 TDMサービスの場合、TDM PWがTCPに対応しなくなる前に、TDMサービスの品質低下が一般的に発生することを示します。許容可能なTDMサービス基準に準拠できない場合に自動的にシャットダウンしないTDMサービスの場合、許容可能なサービスを提供できなくなったTDM疑似配線をシャットダウンする最後の手段として、トランスポート回路ブレーカー[CIRCUIT-BREAKER]を使用できます。 。
Thus, in both cases, pseudowires will not inflict significant harm on neighboring TCP flows, as in one case they respond adequately to congestion, and in the other they would be shut down due to being unable to deliver acceptable service before harming neighboring flows.
したがって、どちらの場合も、疑似配線は輻輳に適切に対応する場合と、隣接フローに害を与える前に許容できるサービスを提供できないためにシャットダウンされる場合のように、隣接TCPフローに重大な害を及ぼすことはありません。
Note: This document contains a large number of graphs that are necessary for its understanding, but could not be rendered in ASCII. It is strongly suggested that the PDF version be consulted.
注：このドキュメントには、理解に必要な多数のグラフが含まれていますが、ASCIIではレンダリングできませんでした。 PDFバージョンを参照することを強くお勧めします。
The following acronyms are used in this document:
このドキュメントでは、次の頭字語が使用されています。
AIS Alarm Indication Signal (see [G775])
AISアラーム表示信号（[G775]を参照）
BER Bit Error Rate [G826]
BERビット誤り率[G826]
BW Bandwidth
BW帯域幅
CBR Constant Bit Rate
CBR固定ビットレート
ES Errored Second [G826]
ESエラー秒数[G826]
ESR Errored Second Rate [G826]
ESRエラー秒数率[G826]
GRE Generic Routing Encapsulation [RFC2784]
GRE汎用ルーティングカプセル化[RFC2784]
L2TPv3 Layer 2 Tunneling Protocol Version 3 [RFC3931]
L2TPv3レイヤー2トンネリングプロトコルバージョン3 [RFC3931]
MOS Mean Opinion Score [P800]
MOS平均オピニオンスコア[P800]
MPLS Multiprotocol Label Switching [RFC3031]
MPLSマルチプロトコルラベルスイッチング[RFC3031]
NSP Native Service Processing [RFC3985]
NSPネイティブサービス処理[RFC3985]
PLR Packet Loss Ratio
PLRパケット損失率
PSN Packet Switched Network [RFC3985]
PSNパケット交換ネットワーク[RFC3985]
PW Pseudowire [RFC3985]
PW疑似配線[RFC3985]
SAToP Structure-Agnostic TDM over Packet [RFC4553]
SAToP構造にとらわれないTDM over Packet [RFC4553]
SES Severely Errored Seconds [G826]
SES重大エラー秒数[G826]
SESR Severely Errored Seconds Ratio [G826]
SESR重大エラー秒数比[G826]
TCP Transmission Control Protocol
TCP伝送制御プロトコル
TDM Time Division Multiplexing [G703]
TDM時分割多重化[G703]
UDP User Datagram Protocol
UDPユーザーデータグラムプロトコル
In this section, we consider Ethernet PWs that primarily carry congestion-responsive traffic. We expand on the remark in Section 8 (Congestion Control) of [RFC4553], and show that the desired congestion avoidance behavior is automatically obtained and additional mechanisms are not needed.
このセクションでは、主に輻輳対応トラフィックを伝送するイーサネットPWについて検討します。 [RFC4553]のセクション8（輻輳制御）の発言を拡張し、望ましい輻輳回避動作が自動的に取得され、追加のメカニズムが不要であることを示します。
Let us assume that an Ethernet PW aggregating several TCP flows is flowing alongside several TCP/IP flows. Each Ethernet PW packet carries a single Ethernet frame that carries a single IP packet that carries a single TCP segment. Thus, if congestion is signaled by an intermediate router dropping a packet, a single end-user TCP/IP packet is dropped, whether or not that packet is encapsulated in the PW.
複数のTCPフローを集約するイーサネットPWが複数のTCP / IPフローと一緒に流れていると仮定します。各イーサネットPWパケットは、単一のTCPセグメントを伝送する単一のIPパケットを伝送する単一のイーサネットフレームを伝送します。したがって、中間ルーターがパケットをドロップすることで輻輳が通知された場合、そのパケットがPWにカプセル化されているかどうかに関係なく、単一のエンドユーザーTCP / IPパケットがドロップされます。
The result is that the individual TCP flows inside the PW experience the same drop probability as the non-PW TCP flows. Thus, the behavior of a TCP sender (retransmitting the packet and appropriately reducing its sending rate) is the same for flows directly over IP and for flows inside the PW. In other words, individual TCP flows are neither rewarded nor penalized for being carried over the PW. An elastic PW does not behave as a single TCP flow, as it will consume the aggregated bandwidth of its component flows; yet if its component TCP flows backs off by some percentage, the bandwidth of the PW as a whole will be reduced by the very same percentage, purely due to the combined effect of its component flows.
その結果、PW内の個々のTCPフローは、非PW TCPフローと同じドロップ確率を経験します。したがって、TCP送信側の動作（パケットを再送信し、その送信速度を適切に下げる）は、IPを介した直接フローとPW内のフローで同じです。言い換えると、個々のTCPフローは、PWを介して伝送されるため、報酬もペナルティも受けません。エラスティックPWは、コンポーネントフローの集約された帯域幅を消費するため、単一のTCPフローとして動作しません。ただし、そのコンポーネントのTCPフローが一定の割合でバックオフした場合、PWの帯域幅は全体として非常に同じ割合で減少します。これは、純粋にそのコンポーネントフローの複合効果によるものです。
This is, of course, precisely the desired behavior. Were individual TCP flows rewarded for being carried over a PW, this would create an incentive to create PWs for no operational reason. Were individual flows penalized, there would be a deterrence that could impede pseudowire deployment.
もちろん、これはまさに望ましい動作です。個々のTCPフローがPWを介して伝送されることで報酬が得られた場合、これは運用上の理由なしにPWを作成するインセンティブになります。個々のフローにペナルティが課せられた場合、疑似配線の展開を妨げる可能性のある抑止が存在します。
There have been proposals to add additional TCP-friendly mechanisms to PWs, for example by carrying PWs over DCCP. In light of the above arguments, it is clear that this would force the PW down to the bandwidth of a single flow, rather than N flows, and penalize the constituent TCP flows. In addition, the individual TCP flows would still back off due to their endpoints being oblivious to the fact that they are carried over a PW. This would further degrade the flow's throughput as compared to a non-PW-encapsulated flow, in contradiction to desirable behavior.
たとえば、DCCPを介してPWを伝送することにより、TCPに適したメカニズムをPWに追加するという提案がありました。上記の議論に照らして、これがPWをNフローではなく単一フローの帯域幅に強制し、構成TCPフローにペナルティを課すことは明らかです。また、個々のTCPフローは、エンドポイントがPWを介して伝送されるという事実を認識していないため、バックオフします。これは、PWカプセル化されていないフローと比較して、望ましい動作とは対照的に、フローのスループットをさらに低下させます。
We have limited our treatment to the case of TCP traffic carried by Ethernet PWs (which are by far the most commonly deployed packet-carrying pseudowires), but it is not overly difficult to show that our result is equally valid for other PW types, such as ATM or frame-relay pseudowires.
イーサネットPW（これは、最も一般的に展開されているパケットを運ぶ疑似配線です）によって運ばれるTCPトラフィックの場合に扱いを制限しましたが、結果が他のPWタイプに対しても同様に有効であることを示すのはそれほど難しくありません。 ATMまたはフレームリレー疑似配線として。
Inelastic PWs, such as TDM PWs [RFC4553] [RFC5086] [RFC5087], are potentially more problematic than the elastic PWs of the previous section. As mentioned in Section 8 (Congestion Control) of [RFC4553], being constant bit rate (CBR), TDM PWs can't incrementally respond to congestion in a TCP-like fashion. On the other hand, being CBR, TDM PWs do not make things worse by attempting to capture additional bandwidth when neighboring TCP flows back off.
TDM PW [RFC4553] [RFC5086] [RFC5087]などの非弾性PWは、前のセクションの弾性PWよりも潜在的に問題があります。 [RFC4553]のセクション8（輻輳制御）で述べたように、固定ビットレート（CBR）であるため、TDM PWはTCPのような方法で輻輳に段階的に応答することができません。一方、CBRであるTDM PWは、隣接するTCPフローがオフに戻ったときに追加の帯域幅をキャプチャしようとしても、事態を悪化させることはありません。
Since a TDM PW consumes a constant amount of bandwidth, if the bandwidth occupied by a TDM PW endangers the network as a whole, it might seem that the only recourse is to shut it down, denying service to all customers of the TDM native service. Nonetheless, under certain conditions it may be possible to reduce the bandwidth consumption of an emulated TDM service. A prevalent case is that of a TDM native service that carries voice channels that may not all be active. The ATM Adaptation Layer 2 (AAL2) mode of [RFC5087] (perhaps along with connection admission control) can enable bandwidth adaptation, at the expense of more sophisticated native service processing (NSP).
TDM PWは一定量の帯域幅を消費するため、TDM PWが占有する帯域幅がネットワーク全体を危険にさらしている場合は、TDM PWをシャットダウンして、TDMネイティブサービスのすべての顧客に対するサービスを拒否することが唯一の解決策であると思われる場合があります。それにもかかわらず、特定の条件下では、エミュレートされたTDMサービスの帯域幅消費を削減できる可能性があります。流行しているケースは、すべてがアクティブではない可能性がある音声チャネルを伝送するTDMネイティブサービスのケースです。 [RFC5087]のATMアダプテーションレイヤー2（AAL2）モード（およびおそらく接続受付制御）は、より高度なネイティブサービス処理（NSP）を犠牲にして、帯域幅アダプテーションを有効にすることができます。
In the following, we will focus on structure-agnostic TDM PWs [RFC4553] although similar analysis can be readily applied to structure-aware PWs (see Appendix B). We will show that, for many cases of interest, a TDM PW, even when treated as a single flow, will behave in a reasonable manner without any additional mechanisms. We also show that, at the level of congestion when a TDM PW can no longer deliver acceptable TDM service, a single unconstrained TCP flow would typically still consume more capacity than a whole TDM PW. Therefore, to ensure that a TDM PW does not inflict significantly more harm than a TCP flow, it suffices to shut down a TDM PW that is persistently unable to deliver acceptable TDM service. This shutting down could be accomplished by employing a managed transport circuit breaker, by which we mean an automatic mechanism for terminating an unresponsive flow during persistently high levels of congestion [CIRCUIT-BREAKER]. Note that a transport circuit breaker is intended as a protection mechanism of last resort, just as an electrical circuit breaker is only triggered when absolutely necessary.
以下では、構造にとらわれないTDM PW [RFC4553]に焦点を当てますが、同様の分析は構造認識PWにも容易に適用できます（付録Bを参照）。 TDM PWは、多くの場合、単一のフローとして扱われた場合でも、追加のメカニズムなしで妥当な方法で動作することを示します。また、TDM PWが許容可能なTDMサービスを提供できなくなったときの輻輳のレベルでは、単一の制約のないTCPフローは、通常、TDM PW全体よりも多くの容量を消費します。したがって、TDM PWがTCPフローよりもはるかに大きな害を与えないようにするには、許容できるTDMサービスを継続的に提供できないTDM PWをシャットダウンするだけで十分です。このシャットダウンは、マネージドトランスポートサーキットブレーカーを使用することで実現できます。これは、輻輳が継続的に高レベルの状態で、無応答フローを終了する自動メカニズムを意味します[CIRCUIT-BREAKER]。トランスポート回路ブレーカーは、電気回路ブレーカーが絶対に必要な場合にのみトリガーされるのと同様に、最後の手段の保護メカニズムとして意図されていることに注意してください。
For the avoidance of doubt, the above does not say that a TDM PW should be shut down when it becomes TCP-unfriendly. It merely says that the act of shutting down a TDM PW that can no longer deliver acceptable TDM service ensures that the PW does not contribute to congestion significantly more than a TCP flow would. Also, note that being unable to deliver acceptable TDM service for a short amount of time is insufficient justification for shutting down a TDM PW. While TCP flows react within a round-trip time, service commissioning and decommissioning are generally time-consuming processes that should only be undertaken when it becomes clear that the congestion is not transient.
誤解を避けるために、上記では、TDM PWがTCPに対応しなくなったときにシャットダウンする必要があるとは述べていません。受け入れ可能なTDMサービスを提供できなくなったTDM PWをシャットダウンすることにより、PWがTCPフローよりも大幅に輻輳に寄与しないことが保証されるだけです。また、許容できるTDMサービスを短期間提供できないことは、TDM PWをシャットダウンする理由として不十分であることにも注意してください。 TCPフローは往復時間内に反応しますが、サービスのコミッショニングとデコミッショニングは一般に時間のかかるプロセスであり、輻輳が一時的でないことが明らかになったときにのみ実行されます。
In order to quantitatively compare TDM PWs to TCP flows, we will compare the effect of TDM PW traffic with that of TCP traffic having the same packet size and delay. This is potentially an overly pessimistic comparison, as TDM PW packets are frequently configured to be short in order to minimize latency, while TCP packets are free to be much larger.
TDM PWとTCPフローを定量的に比較するために、TDM PWトラフィックの効果を、同じパケットサイズと遅延を持つTCPトラフィックの効果と比較します。 TDM PWパケットは待機時間を最小限に抑えるために短く設定されることが多いため、これは過度に悲観的な比較になる可能性がありますが、TCPパケットは自由に大きくできます。
There are two network parameters relevant to our discussion, namely the one-way delay (D) and the packet loss ratio (PLR). The one-way delay of a native TDM service consists of the physical time-of-flight plus 125 microseconds for each TDM switch traversed, and is thus very small as compared to typical PSN network-crossing latencies. Since TDM services are designed with this low latency in mind, emulated TDM services are usually required to have similar low end-to-end delay. In our comparisons, we will only consider one-way delays of a few milliseconds.
私たちの議論に関連する2つのネットワークパラメーター、つまり一方向の遅延（D）とパケット損失率（PLR）があります。ネイティブTDMサービスの一方向の遅延は、物理的な飛行時間と、通過する各TDMスイッチの125マイクロ秒で構成されているため、通常のPSNネットワーク通過遅延と比較すると非常に小さいです。 TDMサービスはこの低レイテンシを考慮して設計されているため、エミュレートされたTDMサービスには通常、同様の低エンドツーエンドの遅延が必要です。比較では、数ミリ秒の一方向の遅延のみを考慮します。
Regarding packet loss, the relevant RFCs specify actions to be carried out upon detecting a lost packet. Structure-agnostic transport has no alternative to outputting an "all-ones" Alarm Indication Signal (AIS) pattern towards the TDM circuit, which, when long enough in duration, is recognized by the receiving TDM device as a fault indication (see Appendix A). TDM standards (such as [G826]) place stringent limits on the number of such faults tolerated. Calculations presented in Appendix A show that only loss probabilities in the realm of fractions of a percent are relevant for structure-agnostic transport. Structure-aware transport regenerates frame alignment signals, thus avoiding AIS indications resulting from infrequent packet loss. Furthermore, for TDM circuits carrying voice channels, the use of packet loss concealment algorithms is possible (such algorithms have been previously described for TDM PWs). However, even structure-aware transport ceases to provide a useful service at about 2 percent loss probability. Hence, in our comparisons we will only consider PLRs of 1 or 2 percent.
パケット損失に関して、関連するRFCは、パケットの損失を検出したときに実行するアクションを指定しています。構造にとらわれないトランスポートには、TDM回路に向けて「すべて1」のアラーム表示信号（AIS）パターンを出力する代替手段がありません。これは、持続時間が十分長い場合、受信TDMデバイスによって障害表示として認識されます（付録Aを参照）。 ）。 TDM標準（[G826]など）は、許容されるそのような障害の数に厳しい制限を課します。付録Aに示されている計算では、パーセントに相当する領域の損失確率のみが構造にとらわれない輸送に関連していることが示されています。構造認識トランスポートはフレームアライメント信号を再生成するため、まれなパケット損失によるAIS表示を回避できます。さらに、音声チャネルを伝送するTDM回路の場合、パケット損失隠蔽アルゴリズムの使用が可能です（そのようなアルゴリズムはTDM PWについて以前に説明されています）。ただし、構造を意識したトランスポートでさえ、約2％の損失確率で有用なサービスを提供できなくなります。したがって、比較では1％または2％のPLRのみを考慮します。
TCP Friendly Rate Control (TFRC) [RFC5348] provides a simplified formula for TCP throughput as a function of round-trip delay and packet loss ratio.
TCP Friendly Rate Control（TFRC）[RFC5348]は、ラウンドトリップ遅延とパケット損失率の関数として、TCPスループットの簡略化された式を提供します。
S
X = ------------------------------------------------
R ( sqrt(2p/3) + 12 sqrt(3p/8) p (1+32p^2) )
where:
ただし：
X is the average sending rate in bytes per second,
Xは、1秒あたりのバイト数で表した平均送信レートです。
S is the segment (packet payload) size in bytes,
Sはバイト単位のセグメント（パケットペイロード）サイズです。
R is the round-trip time in seconds,
Rは、秒単位の往復時間です。
p is the packet loss probability (i.e., PLR/100).
pはパケット損失確率です（つまり、PLR / 100）。
We can now compare the bandwidth consumed by TDM pseudowires with that of a TCP flow for a given packet loss ratio and one-way end-to-end delay (taken to be half the round-trip delay R). The results are depicted in the accompanying figures (available only in the PDF version of this document). In Figures 1 and 2, we see the conventional rate vs. packet loss plot for low-rate TDM (both T1 and E1) traffic, as well as TCP traffic with the same payload size (64 or 256 bytes respectively). Since the TDM rates are constant (T1 and E1 having payload throughputs of 1.544 Mbps and 2.048 Mbps respectively), and Structure-Agnostic TDM over packet (SAToP) can only faithfully emulate a TDM service up to a PLR of about half a percent, the T1 and E1 pseudowires occupy line segments on the graph. On the other hand, the TCP rate equation produces rate curves dependent on both one-way delay and packet loss.
これで、TDM疑似配線によって消費される帯域幅を、特定のパケット損失率と一方向のエンドツーエンド遅延（往復遅延Rの半分と見なされます）のTCPフローの帯域幅と比較できます。結果は添付の図に示されています（このドキュメントのPDFバージョンでのみ利用可能です）。図1と図2では、低速のTDM（T1とE1の両方）トラフィックと、ペイロードサイズが同じ（それぞれ64バイトまたは256バイト）のTCPトラフィックの従来のレート対パケット損失のプロットを示しています。 TDMレートは一定であり（T1およびE1のペイロードスループットはそれぞれ1.544 Mbpsおよび2.048 Mbpsです）、構造にとらわれないTDM over packet（SAToP）は、最大約半分のPLRまでのTDMサービスのみを忠実にエミュレートできます。 T1およびE1疑似配線は、グラフ上の線分を占めます。一方、TCPレート方程式は、一方向の遅延とパケット損失の両方に依存するレート曲線を生成します。
For large packet sizes, short one-way delays, and low packet loss ratios, the TDM pseudowires typically consume much less bandwidth than TCP would under identical conditions. For small packets, long one-way delays, and high packet loss ratios, TDM PWs potentially consume more bandwidth, but only marginally. Furthermore, our "apples to apples" comparison forced the TCP traffic to use packets of sizes smaller than would be typical.
パケットサイズが大きく、一方向の遅延が短く、パケット損失率が低い場合、TDM疑似配線は、通常、同一条件下でのTCPよりもはるかに少ない帯域幅を消費します。小さなパケット、長い一方向の遅延、および高いパケット損失率の場合、TDM PWは潜在的により多くの帯域幅を消費しますが、ごくわずかです。さらに、「リンゴ同士」の比較により、TCPトラフィックは通常よりも小さいサイズのパケットを使用する必要がありました。
Similarly, in Figures 3 and 4 we repeat the exercise for higher rate E3 and T3 (rates 34.368 and 44.736 Mbps respectively) pseudowires, allowing delays and PLRs suitable for these signals. We see that the TDM pseudowires consume much less bandwidth than TCP, for all reasonable parameter combinations.
同様に、図3と4では、より高いレートのE3とT3（それぞれレート34.368と44.736 Mbps）の疑似配線の演習を繰り返し、これらの信号に適した遅延とPLRを可能にします。 TDM疑似配線は、すべての妥当なパラメータの組み合わせに対して、TCPよりもはるかに少ない帯域幅を消費することがわかります。
--------------------------------------------------------------------
I I
I I
I I
I I
I E1/T1 PWs vs. TCP for segment size 64B I
I I
I I
I I
I I
I (only in PDF version) I
I I
I I
I I
I I
I I
--------------------------------------------------------------------
Figure 1: E1/T1 PWs vs. TCP for Segment Size 64B
図1：E1 / T1 PW対セグメントSyzi 64BのTSP
--------------------------------------------------------------------
I I
I I
I I
I I
I E1/T1 PWs vs. TCP for segment size 256B I
I I
I I
I I
I I
I (only in PDF version) I
I I
I I
I I
I I
I I
--------------------------------------------------------------------
Figure 2: E1/T1 PWs vs. TCP for Segment Size 256B
図2：セグメントサイズ256BのE1 / T1 PWとTCP
--------------------------------------------------------------------
I I
I I
I I
I I
I E3/T3 PWs vs. TCP for segment size 536B I
I I
I I
I I
I I
I (only in PDF version) I
I I
I I
I I
I I
I I
--------------------------------------------------------------------
Figure 3: E3/T3 PWs vs. TCP for Segment Size 536B
図3：セグメントサイズ536BのE3 / T3 PWとTCP
--------------------------------------------------------------------
I I
I I
I I
I I
I E3/T3 PWs vs. TCP for segment size 1024B I
I I
I I
I I
I I
I (only in PDF version) I
I I
I I
I I
I I
I I
--------------------------------------------------------------------
Figure 4: E3/T3 PWs vs. TCP for Segment Size 1024B
図4：セグメントサイズ1024BのE3 / T3 PWとTCP
We can use the TCP rate equation to determine the precise conditions under which a TDM PW consumes no more bandwidth than a TCP flow between the same endpoints under identical conditions. Replacing the round-trip delay with twice the one-way delay D, setting the bandwidth to that of the TDM service BW, and the segment size to be the TDM fragment (taking into account the PWE3 control word), we obtain the following condition for a TDM PW:
TCPレートの式を使用して、TDM PWが同一の条件下で同じエンドポイント間のTCPフローよりも多くの帯域幅を消費しない正確な条件を決定できます。往復遅延を一方向の遅延Dの2倍に置き換え、帯域幅をTDMサービスBWの帯域幅に設定し、セグメントサイズをTDMフラグメントにする（PWE3制御ワードを考慮に入れる）と、次の条件が得られます。 TDM PWの場合：
4 S
D < -----------
BW f(p)
where:
ただし：
D is the one-way delay,
Dは一方向の遅延です。
S is the TDM segment size (packet excluding overhead) in bytes,
Sは、バイト単位のTDMセグメントサイズ（オーバーヘッドを除くパケット）です。
BW is the TDM service bandwidth in bits per second,
BWは、ビット/秒単位のTDMサービス帯域幅です。
f(p) = sqrt(2p/3) + 12 sqrt(3p/8) p (1+32p^2).
f（p）= sqrt（2p / 3）+ 12 sqrt（3p / 8）p（1 + 32p ^ 2）。
One may view this condition as defining a "friendly" operating envelope for a TDM PW, as a TDM PW that occupies no more bandwidth than a TCP flow causes no more congestion than that TCP flow. Under this condition, it is acceptable to place the TDM PW alongside congestion-responsive traffic such as TCP. On the other hand, were the TDM PW to consume significantly more bandwidth than a TCP flow, it could contribute disproportionately to congestion, and its mixture with congestion-responsive traffic might be inappropriate. Note that we are sidestepping any debate over the validity of the TCP-friendliness concept and merely saying that there can be no question that a TDM PW is acceptable if it causes no more congestion than a single TCP flow.
TCPフローよりも帯域幅を占有しないTDM PWは、そのTCPフローよりも輻輳を引き起こさないため、この条件をTDM PWの「フレンドリーな」動作エンベロープの定義と見なすことができます。この状況では、TCPなどの輻輳対応トラフィックの横にTDM PWを配置することは許容されます。一方、TDM PWは、TCPフローよりも大幅に多くの帯域幅を消費し、輻輳に過度に寄与する可能性があり、輻輳応答トラフィックとの混合は不適切な場合があります。 TCPとの親和性の概念の有効性については議論を避けており、TDM PWが単一のTCPフロー以上の輻輳を引き起こさない場合は、TDM PWが受け入れ可能であることは間違いありません。
We derived this condition assuming steady-state conditions, and thus two caveats are in order. First, the condition does not specify how to treat a TDM PW that initially satisfies the condition, but is then faced with a deteriorating network environment. In such cases, one additionally needs to analyze the reaction times of the responsive flows to congestion events. Second, the derivation assumed that the TDM PW was competing with long-lived TCP flows, because under this assumption it was straightforward to obtain a quantitative comparison with something widely considered to offer a safe response to congestion. Short-lived TCP flows may find themselves disadvantaged as compared to a long-lived TDM PW satisfying the above condition.
定常状態を想定してこの条件を導き出したので、2つの注意点があります。第1に、この条件は、最初は条件を満たすが、ネットワーク環境の悪化に直面するTDM PWの処理方法を指定していません。そのような場合、さらに、輻輳イベントに対する応答フローの反応時間を分析する必要があります。 2つ目は、TDM PWが長命のTCPフローと競合しているとの推定でした。これは、この仮定の下では、輻輳に対する安全な応答を提供すると広く考えられているものとの定量的な比較を簡単に行うことができるためです。上記の条件を満たす長命のTDM PWと比較して、短命のTCPフローは不利になる場合があります。
We see in Figures 5 and 6 that TDM pseudowires carrying T1 or E1 native services satisfy the condition for all parameters of interest for large packet sizes (e.g., S=512 bytes of TDM data). For the SAToP default of 256 bytes, as long as the one-way delay is less than 10 milliseconds, the loss probability can exceed 0.3 or 0.6 percent. For packets containing 128 or 64 bytes, the constraints are more troublesome, but there are still parameter ranges where the TDM PW consumes less than a TCP flow under similar conditions. Similarly, Figures 7 and 8 demonstrate that E3 and T3 native services with the SAToP default of 1024 bytes of TDM per packet satisfy the condition for a broad spectrum of delays and PLRs.
図5および6を見ると、T1またはE1ネイティブサービスを伝送するTDM疑似配線は、大きなパケットサイズ（たとえば、S = 512バイトのTDMデータ）の対象となるすべてのパラメーターの条件を満たすことがわかります。 SAToPのデフォルトの256バイトの場合、一方向の遅延が10ミリ秒未満である限り、損失確率は0.3または0.6％を超える可能性があります。 128バイトまたは64バイトを含むパケットの場合、制約はより厄介ですが、TDM PWが同様の条件下でTCPフローよりも消費しないパラメーター範囲があります。同様に、図7および8は、SAToPのデフォルトがパケットあたり1024バイトのTDMであるE3およびT3ネイティブサービスが、幅広い遅延とPLRの条件を満たすことを示しています。
--------------------------------------------------------------------
I I
I I
I I
I I
I T1 compatibility regions I
I I
I I
I I
I I
I (only in PDF version) I
I I
I I
I I
I I
I I
--------------------------------------------------------------------
Figure 5: TCP Compatibility Areas for T1 SAToP
図5：T1 SAToPのTCP互換性エリア
--------------------------------------------------------------------
I I
I I
I I
I I
I E1 compatibility regions I
I I
I I
I I
I I
I (only in PDF version) I
I I
I I
I I
I I
I I
--------------------------------------------------------------------
Figure 6: TCP Compatibility Areas for E1 SAToP
図6：E1 SAToPのTCP互換性エリア
--------------------------------------------------------------------
I I
I I
I I
I I
I E3 compatibility regions I
I I
I I
I I
I I
I (only in PDF version) I
I I
I I
I I
I I
I I
--------------------------------------------------------------------
Figure 7: TCP Compatibility Areas for E3 SAToP
図7：E3 SAToPのTCP互換性エリア
--------------------------------------------------------------------
I I
I I
I I
I I
I T3 compatibility regions I
I I
I I
I I
I I
I (only in PDF version) I
I I
I I
I I
I I
I I
--------------------------------------------------------------------
Figure 8: TCP Compatibility Areas for T3 SAToP
図8：T3 SAToPのTCP互換性エリア
The figures presented in the previous section demonstrate that TDM service quality degradation generally occurs before the TDM PW would consume more bandwidth than a comparable TCP flow. Thus, while TDM PWs are unable to respond to congestion in a TCP-like fashion, TDM PWs that are able to deliver acceptable TDM service do not contribute to congestion significantly more than a TCP flow.
前のセクションで示した図は、TDM PWが同等のTCPフローよりも多くの帯域幅を消費する前に、TDMサービス品質の低下が一般的に発生することを示しています。したがって、TDM PWはTCPのような方法で輻輳に応答することはできませんが、許容可能なTDMサービスを提供できるTDM PWは、TCPフローよりも輻輳に大きく寄与することはありません。
Combined with our earlier determination that Ethernet PWs automatically respond in a TCP-like fashion (see Section 3), our final conclusion is that PW-specific congestion-avoidance mechanisms are generally not required. This is true even for TDM PWs, assuming that the TDM management plane initiates service shutdown when service parameters are persistently below levels required by the relevant TDM standards. If the TDM service does not automatically shut down, a mechanism to block persistently unacceptable TDM pseudowires is required, or a transport circuit breaker [CIRCUIT-BREAKER] may be triggered as a last resort.
イーサネットPWが自動的にTCPのような方法で応答するという以前の決定（セクション3を参照）と組み合わせると、最終的な結論は、PW固有の輻輳回避メカニズムは通常必要ないということです。これは、TDM PWの場合にも当てはまります。サービスパラメータが関連するTDM標準で必要なレベルを下回っているときにTDM管理プレーンがサービスのシャットダウンを開始すると想定しています。 TDMサービスが自動的にシャットダウンしない場合は、永続的に受け入れられないTDM疑似配線をブロックするメカニズムが必要です。または、トランスポート回路ブレーカー[CIRCUIT-BREAKER]が最後の手段としてトリガーされる場合があります。
This document does not introduce any new congestion-specific mechanisms and thus does not introduce any new security considerations above those present for PWs in general.
このドキュメントでは、輻輳固有の新しいメカニズムは紹介されていないため、一般的なPWに存在するセキュリティ上の考慮事項よりも新しいセキュリティの考慮事項は紹介されていません。
[CIRCUIT-BREAKER] Fairhurst, G., "Network Transport Circuit Breakers", Work in Progress, draft-ietf-tsvwg-circuit-breaker-15, April 2016.
[CIRCUIT-BREAKER]フェアハースト、G。、「Network Transport Circuit Breakers」、Work in Progress、draft-ietf-tsvwg-circuit-breaker-15、2016年4月。
[G703] ITU-T, "Physical/electrical characteristics of hierarchical digital interfaces", ITU Recommendation G.703, April 2016.
[G703] ITU-T、「階層型デジタルインターフェイスの物理的/電気的特性」、ITU勧告G.703、2016年4月。
[G775] ITU-T, "Loss of Signal (LOS), Alarm Indication Signal (AIS) and Remote Defect Indication (RDI) defect detection and clearance criteria for PDH signals", ITU Recommendation G.775, October 1998.
[G775] ITU-T、「信号消失（LOS）、アラーム表示信号（AIS）、およびリモート欠陥表示（RDI）の欠陥検出とPDH信号のクリアランス基準」、ITU勧告G.775、1998年10月。
[G826] ITU-T, "Error Performance Parameters and Objectives for International Constant Bit Rate Digital Paths at or above Primary Rate", ITU Recommendation G.826, December 2002.
[G826] ITU-T、「エラーパフォーマンスパラメータおよびプライマリレート以上の国際固定ビットレートデジタルパスの目標」、ITU勧告G.826、2002年12月。
[P50App1] ITU-T, "Telephone Transmission Quality, Telephone Installations, Local Line Networks: Appendix 1", ITU-T Recommendation P.50, February 1998.
[P50App1] ITU-T、「電話の伝送品質、電話設備、ローカル回線ネットワーク：付録1」、ITU-T勧告P.50、1998年2月。
[P800] ITU-T, "Methods for subjective determination of transmission quality", ITU Recommendation P.800, June 1998.
[P800] ITU-T、「伝送品質の主観的な決定方法」、ITU勧告P.800、1998年6月。
[P862] ITU-T, "Perceptual evaluation of speech quality (PESQ): An objective method for end-to-end speech quality assessment of narrow-band telephone networks and speech codecs", ITU Recommendation P.826, February 2001.
[P862] ITU-T、「音声品質の知覚評価（PESQ）：狭帯域電話ネットワークと音声コーデックのエンドツーエンドの音声品質評価の客観的方法」、ITU勧告P.826、2001年2月。
[PACKET-LOSS] Stein, J(Y). and I. Druker, "The Effect of Packet Loss on Voice Quality for TDM over Pseudowires", Work in Progress, draft-stein-pwe3-tdm-packetloss-01, December 2003.
[パケットロス]スタイン、J（Y）。 I. Druker、「疑似配線を介したTDMの音声品質に対するパケット損失の影響」、進行中の作業、draft-stein-pwe3-tdm-packetloss-01、2003年12月。
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, DOI 10.17487/RFC2784, March 2000, <http://www.rfc-editor.org/info/rfc2784>.
[RFC2784] Farinacci、D.、Li、T.、Hanks、S.、Meyer、D。、およびP. Traina、「Generic Routing Encapsulation（GRE）」、RFC 2784、DOI 10.17487 / RFC2784、2000年3月、<http ：//www.rfc-editor.org/info/rfc2784>。
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, DOI 10.17487/RFC2914, September 2000, <http://www.rfc-editor.org/info/rfc2914>.
[RFC2914] Floyd、S。、「Congestion Control Principles」、BCP 41、RFC 2914、DOI 10.17487 / RFC2914、2000年9月、<http://www.rfc-editor.org/info/rfc2914>。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, <http://www.rfc-editor.org/info/rfc3031>.
[RFC3031] Rosen、E.、Viswanathan、A。、およびR. Callon、「Multiprotocol Label Switching Architecture」、RFC 3031、DOI 10.17487 / RFC3031、2001年1月、<http://www.rfc-editor.org/info / rfc3031>。
[RFC3931] Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed., "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, DOI 10.17487/RFC3931, March 2005, <http://www.rfc-editor.org/info/rfc3931>.
[RFC3931] Lau、J.、Ed。、Townsley、M.、Ed。、I。Goyret、Ed。、「Layer Two Tunneling Protocol-Version 3（L2TPv3）」、RFC 3931、DOI 10.17487 / RFC3931、2005年3月、<http://www.rfc-editor.org/info/rfc3931>。
[RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, DOI 10.17487/RFC3985, March 2005, <http://www.rfc-editor.org/info/rfc3985>.
[RFC3985]ブライアント、S。、エド。およびP. Pate、編、「疑似ワイヤーエミュレーションエッジツーエッジ（PWE3）アーキテクチャ」、RFC 3985、DOI 10.17487 / RFC3985、2005年3月、<http://www.rfc-editor.org/info/rfc3985 >。
[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed., "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005, <http://www.rfc-editor.org/info/rfc4023>.
[RFC4023] Worster、T.、Rekhter、Y。、およびE. Rosen、編、「IPまたはGeneric Routing Encapsulation（GRE）でのMPLSのカプセル化」、RFC 4023、DOI 10.17487 / RFC4023、2005年3月、<http：/ /www.rfc-editor.org/info/rfc4023>。
[RFC4553] Vainshtein, A., Ed. and YJ. Stein, Ed., "Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP)", RFC 4553, DOI 10.17487/RFC4553, June 2006, <http://www.rfc-editor.org/info/rfc4553>.
[RFC4553] Vainshtein、A.、Ed。とYJ。スタイン編、「構造にとらわれない時分割多重（TDM）over Packet（SAToP）」、RFC 4553、DOI 10.17487 / RFC4553、2006年6月、<http://www.rfc-editor.org/info/rfc4553> 。
[RFC5033] Floyd, S. and M. Allman, "Specifying New Congestion Control Algorithms", BCP 133, RFC 5033, DOI 10.17487/RFC5033, August 2007, <http://www.rfc-editor.org/info/rfc5033>.
[RFC5033]フロイド、S。およびM.オールマン、「Specifying New Congestion Control Algorithms」、BCP 133、RFC 5033、DOI 10.17487 / RFC5033、2007年8月、<http://www.rfc-editor.org/info/rfc5033 >。
[RFC5086] Vainshtein, A., Ed., Sasson, I., Metz, E., Frost, T., and P. Pate, "Structure-Aware Time Division Multiplexed (TDM) Circuit Emulation Service over Packet Switched Network (CESoPSN)", RFC 5086, DOI 10.17487/RFC5086, December 2007, <http://www.rfc-editor.org/info/rfc5086>.
[RFC5086] Vainshtein、A.、Ed。、Sasson、I.、Metz、E.、Frost、T.、and P. Pate、 "Structure-Aware Time Division Multiplexed（TDM）Circuit Emulation Service over Packet Switched Network（CESoPSN ） "、RFC 5086、DOI 10.17487 / RFC5086、2007年12月、<http://www.rfc-editor.org/info/rfc5086>。
[RFC5087] Stein, Y(J)., Shashoua, R., Insler, R., and M. Anavi, "Time Division Multiplexing over IP (TDMoIP)", RFC 5087, DOI 10.17487/RFC5087, December 2007, <http://www.rfc-editor.org/info/rfc5087>.
[RFC5087]スタイン、Y（J）、シャショーア、R。、インスラー、R。、およびM.アナビ、「IPを介した時分割多重化（TDMoIP）」、RFC 5087、DOI 10.17487 / RFC5087、2007年12月、<http ：//www.rfc-editor.org/info/rfc5087>。
[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 5348, DOI 10.17487/RFC5348, September 2008, <http://www.rfc-editor.org/info/rfc5348>.
[RFC5348] Floyd、S.、Handley、M.、Padhye、J。、およびJ. Widmer、「TCP Friendly Rate Control（TFRC）：Protocol Specification」、RFC 5348、DOI 10.17487 / RFC5348、2008年9月、<http： //www.rfc-editor.org/info/rfc5348>。
ITU-T Recommendation G.826 [G826] specifies limits on the Errored Second Ratio (ESR) and the Severely Errored Second Ratio (SESR). For our purposes, we will simplify the definitions and understand an Errored Second (ES) to be a second of time during which a TDM bit error occurred or a defect indication was detected. A Severely Errored Second (SES) is an ES second during which the Bit Error Rate (BER) exceeded one in one thousand (10^-3). Note that if the error condition AIS was detected according to the criteria of ITU-T Recommendation G.775 [G775], an SES was considered to have occurred. The respective ratios are the fraction of ES or SES to the total number of seconds in the measurement interval.
ITU-T勧告G.826 [G826]は、エラー秒数比（ESR）と重大エラー秒数比（SESR）の制限を指定しています。ここでは、定義を簡略化し、エラーが発生した秒（ES）を、TDMビットエラーが発生したか、欠陥の兆候が検出された時間の1秒と理解します。重大エラー秒数（SES）は、ビットエラー率（BER）が1000分の1（10 ^ -3）を超えたES秒です。 ITU-T勧告G.775 [G775]の基準に従ってエラー状態AISが検出された場合、SESが発生したと見なされたことに注意してください。それぞれの比率は、測定間隔の合計秒数に対するESまたはSESの割合です。
All TDM signals run at 8000 frames per second (higher rate TDM signals have longer frames). So, assuming an integer number of TDM frames per TDM PW packet, the number of packets per second is given by packets per second = 8000 / (frames per packet). Prevalent cases are 1, 2, 4, and 8 frames per packet, translating to 8000, 4000, 2000, and 1000 packets per second, respectively.
すべてのTDM信号は毎秒8000フレームで実行されます（TDM信号のレートが高いほど、フレームが長くなります）。したがって、TDM PWパケットあたりのTDMフレームの整数を想定すると、1秒あたりのパケット数は、1秒あたりのパケット数= 8000 /（1パケットあたりのフレーム数）で与えられます。一般的なケースは、パケットあたり1、2、4、8フレームで、それぞれ8000、4000、2000、1000パケット/秒に変換されます。
For both E1 and T1 TDM circuits, G.826 allows an ESR of 4% (0.04), and an SESR of 0.2% (0.002). For E3 and T3, the ESR must be no more than 7.5% (0.075), while the SESR is unchanged. Focusing on E1 circuits, the ESR of 4% translates (assuming the worst case of isolated exactly periodic packet loss) to a packet loss event no more than every 25 seconds. However, once a packet is lost, another packet lost in the same second doesn't change the ESR, although it may contribute to the ES becoming an SES. Thus for 1, 2, 4, and 8 frames per packet, the maximum allowed packet loss probability is 0.0005%, 0.001%, 0.002%, and 0.004% respectively.
E1およびT1 TDM回線の両方で、G.826は4％（0.04）のESR、および0.2％（0.002）のSESRを許可します。 ESRは変更されませんが、E3およびT3の場合、ESRは7.5％（0.075）以下でなければなりません。 E1回路に焦点を合わせると、ESRが4％になると（最悪の場合、正確に定期的にパケットが分離されるという最悪のケースを想定して）、25秒以内のパケット損失イベントに変換されます。ただし、パケットが失われると、同じ秒に失われた別のパケットはESRを変更しませんが、ESがSESになる原因になる可能性があります。したがって、パケットあたり1、2、4、および8フレームの場合、最大許容パケット損失確率は、それぞれ0.0005％、0.001％、0.002％、および0.004％です。
These extremely low allowed packet loss probabilities are only for the worst case scenario. With tail-drop buffers, when packet loss is above 0.001%, it is likely that loss bursts will occur. If the lost packets are sufficiently close together (we ignore the precise details here), then the permitted packet loss ratio increases by the appropriate factor, without G.826 being cognizant of any change. Hence, the worst-case analysis is expected to be extremely pessimistic for real networks. Next, we will consider the opposite extreme and assume that all packet loss events are in periodic loss bursts. In order to minimize the ESR, we will assume that the burst lasts no more than one second, and so we can afford to lose in each burst no more than the number of packets transmitted in one second. As long as such one-second bursts do not exceed four percent of the time, we still maintain the allowable ESR. Hence, the maximum permissible packet loss ratio is 4%. Of course, this estimate is extremely optimistic, and furthermore does not take into consideration the SESR criteria.
これらの非常に低い許容パケット損失確率は、最悪の場合のシナリオのみです。テールドロップバッファを使用すると、パケット損失が0.001％を超えると、損失バーストが発生する可能性があります。失われたパケットが互いに十分に接近している場合（ここでは正確な詳細は無視します）、G.826が変更を認識せずに、許可されるパケット損失率が適切な係数で増加します。したがって、最悪のケースの分析は、実際のネットワークにとって非常に悲観的であると予想されます。次に、反対の極端を検討し、すべてのパケット損失イベントが定期的な損失バーストであると仮定します。 ESRを最小化するために、バーストが1秒以下であると仮定します。そのため、各バーストで1秒で送信されるパケット数以下の損失を許容できます。このような1秒のバーストが時間の4％を超えない限り、許容されるESRは維持されます。したがって、最大許容パケット損失率は4％です。もちろん、この見積もりは非常に楽観的であり、さらにSESR基準は考慮されていません。
As previously explained, an SES is declared whenever AIS is detected. There is a major difference between structure-aware and structure-agnostic transport in this regards. When a packet is lost, SAToP outputs an "all-ones" pattern to the TDM circuit, which is interpreted as AIS according to G.775 [G775]. For E1 circuits, G.775 specifies that AIS is detected when four consecutive TDM frames have no more than 2 alternations. This means that if a PW packet or consecutive packets containing at least four frames are lost, and four or more frames of "all-ones" output to the TDM circuit, an SES will be declared. Thus burst packet loss, or packets containing a large number of TDM frames, lead SAToP to cause high SESR, which is 20 times more restricted than ESR. On the other hand, since structure-aware transport regenerates the correct frame alignment pattern, even when the corresponding packet has been lost, packet loss will not cause declaration of SES. This is the main reason that SAToP is much more vulnerable to packet loss than the structure-aware methods.
前述のように、AISが検出されると必ずSESが宣言されます。この点で、構造認識トランスポートと構造非依存トランスポートの間には大きな違いがあります。パケットが失われると、SAToPはTDM回線に「すべて1」のパターンを出力します。これは、G.775 [G775]に従ってAISとして解釈されます。 E1回線の場合、G.775は、4つの連続したTDMフレームに2つ以上の代替がない場合にAISが検出されることを指定しています。これは、PWパケットまたは少なくとも4つのフレームを含む連続したパケットが失われ、TDM回路に出力される「すべて1」のフレームが4つ以上ある場合、SESが宣言されることを意味します。したがって、バーストパケット損失、または多数のTDMフレームを含むパケットにより、SAToPは、ESRよりも20倍制限された高いSESRを引き起こします。一方、構造認識トランスポートは正しいフレームアライメントパターンを再生成するため、対応するパケットが失われた場合でも、パケットの損失によってSESが宣言されることはありません。これが、構造認識方式よりもSAToPの方がパケット損失に対してはるかに脆弱である主な理由です。
For realistic networks, the maximum allowed packet loss for SAToP will be intermediate between the extremely pessimistic estimates and the extremely optimistic ones. In order to numerically gauge the situation, we have modeled the network as a four-state Markov model, (corresponding to a successfully received packet, a packet received within a loss burst, a packet lost within a burst, and a packet lost when not within a burst). This model is an extension of the widely used Gilbert model. We set the transition probabilities in order to roughly correspond to anecdotal evidence, namely low background isolated packet loss, and infrequent bursts wherein most packets are lost. Such simulation shows that up to 0.5% average packet loss may occur and the recovered TDM still conforms to the G.826 ESR and SESR criteria.
現実的なネットワークでは、SAToPの最大許容パケット損失は、非常に悲観的な見積もりと非常に楽観的な見積もりの中間になります。状況を数値的に測定するために、ネットワークを4つの状態のマルコフモデルとしてモデル化しました（正常に受信されたパケット、損失バースト内で受信されたパケット、バースト内で損失されたパケット、そうでない場合に損失されたパケットに対応）バースト内）。このモデルは、広く使用されているギルバートモデルを拡張したものです。遷移の確率は、事例の証拠、つまりバックグラウンドでの孤立したパケット損失が少ないことと、ほとんどのパケットが失われるまれなバーストにほぼ対応するように設定します。このようなシミュレーションは、最大0.5％の平均パケット損失が発生する可能性があり、回復されたTDMがG.826 ESRおよびSESR基準に依然として適合していることを示しています。
Appendix B. Effect of Packet Loss on Voice Quality for Structure-Aware TDM PWs
付録B.構造認識TDM PWの音声品質に対するパケット損失の影響
Packet loss in voice traffic causes audio artifacts such as choppy, annoying, or even unintelligible speech. The precise effect of packet loss on voice quality has been the subject of detailed study in the Voice over IP (VoIP) community, but VoIP results are not directly applicable to TDM PWs. This is because VoIP packets typically contain over 10 milliseconds of the speech signal, while multichannel TDM packets may contain only a single sample, or perhaps a very small number of samples.
音声トラフィックのパケット損失により、音声が途切れる、煩わしい、または音声が聞き取りにくくなるなどのアーティファクトが発生します。音声品質に対するパケット損失の正確な影響は、Voice over IP（VoIP）コミュニティでの詳細な調査の対象でしたが、VoIPの結果はTDM PWに直接適用できません。これは、VoIPパケットには通常10ミリ秒を超える音声信号が含まれているのに対し、マルチチャネルTDMパケットには単一のサンプルのみ、または非常に少数のサンプルが含まれている場合があるためです。
The effect of packet loss on TDM PWs has been previously reported [PACKET-LOSS]. In that study, it was assumed that each packet carried a single sample of each TDM timeslot (although the extension to multiple samples is relatively straightforward and does not drastically change the results). Four sample replacement algorithms were compared, differing in the value used to replace the lost sample:
TDM PWに対するパケット損失の影響は、以前に報告されています[パケット損失]。その研究では、各パケットが各TDMタイムスロットの単一のサンプルを運ぶと想定されていました（ただし、複数のサンプルへの拡張は比較的簡単で、結果を大幅に変更することはありません）。失われたサンプルを置き換えるために使用される値が異なる、4つのサンプル置換アルゴリズムが比較されました。
1. Replacing every lost sample by a preselected constant (e.g., zero or "AIS" insertion).
1. 失われたすべてのサンプルを事前に選択された定数（ゼロまたは「AIS」挿入など）で置き換えます。
2. Replacing a lost sample by the previous sample.
2. 失われたサンプルを前のサンプルに置き換える。
3. Replacing a lost sample by linear interpolation between the previous and following samples.
3. 失われたサンプルを、前のサンプルと次のサンプルの間の線形補間で置き換える。
4. Replacing the lost sample by STatistically Enhanced INterpolation (STEIN).
4. 失われたサンプルを統計的に強化された補間（STEIN）で置き換える。
Only the first method is applicable to SAToP transport, as structure awareness is required in order to identify the individual voice channels. For structure-aware transport, the loss of a packet is typically identified by the receipt of the following packet, and thus the following sample is usually available. The last algorithm posits the Linear-Predictive Coding (LPC) speech generation model and derives lost samples based on available samples both before and after each lost sample.
個々の音声チャネルを識別するために構造認識が必要であるため、SAToPトランスポートに適用できるのは最初の方法のみです。構造認識トランスポートの場合、パケットの損失は通常、次のパケットの受信によって識別されるため、通常は次のサンプルを使用できます。最後のアルゴリズムは、線形予測コーディング（LPC）音声生成モデルを仮定し、失われた各サンプルの前後の両方で、利用可能なサンプルに基づいて失われたサンプルを導き出します。
The four algorithms were compared in a controlled experiment in which speech data was selected from English and American English subsets of the ITU-T P.50 Appendix 1 corpus [P50App1] and consisted of 16 speakers, eight male and eight female. Each speaker spoke either three or four sentences, for a total of between seven and 15 seconds. The selected files were filtered to telephony quality using modified IRS filtering and down-sampled to 8 kHz. Packet loss of 0, 0.25, 0.5, 0.75, 1, 2, 3, 4, and 5 percent were simulated using a uniform random number generator (bursty packet loss was also simulated but is not reported here). For each file, the four methods of lost sample replacement were applied and the Mean Opinion Score (MOS) was estimated using PESQ [P862]. Figure 9 depicts the PESQ-derived MOS for each of the four replacement methods for packet drop probabilities up to 5%.
4つのアルゴリズムは、音声データがITU-T P.50付録1コーパス[P50App1]の英語とアメリカ英語のサブセットから選択され、16人のスピーカー、8人の男性と8人の女性からなる制御実験で比較されました。各スピーカーは3つまたは4つの文章を話し、合計7〜15秒でした。選択されたファイルは、変更されたIRSフィルタリングを使用してテレフォニー品質にフィルタリングされ、8 kHzにダウンサンプリングされました。 0、0.25、0.5、0.75、1、2、3、4、および5％のパケット損失は、一様乱数ジェネレーターを使用してシミュレートされました（バースト性パケット損失もシミュレートされましたが、ここでは報告されません）。各ファイルに対して、4つの失われたサンプルの置換方法が適用され、PESQ [P862]を使用して平均オピニオンスコア（MOS）が推定されました。図9は、最大5％のパケットドロップ確率の4つの置換方法のそれぞれについて、PESQから派生したMOSを示しています。
--------------------------------------------------------------------
I I
I I
I I
I I
I I
I I
I PESQ-MOS as a function of packet drop probability I
I I
I I
I I
I I
I (only in PDF version) I
I I
I I
I I
I I
I I
I I
I I
--------------------------------------------------------------------
Figure 9: PESQ-Derived MOS as a Function of Packet-Drop Probability
図9：パケットドロップ確率の関数としてのPESQ派生MOS
For all cases, the MOS resulting from the use of zero insertion is less than that obtained by replacing with the previous sample, which in turn is less than that of linear interpolation, which is slightly less than that obtained by statistical interpolation.
すべての場合において、ゼロ挿入の使用から得られるMOSは、前のサンプルで置き換えることによって得られるMOSより小さいため、線形補間のMOSは統計的補間によって得られるMOSよりもわずかに低くなります。
Unlike the artifacts that speech compression methods may produce when subject to buffer loss, packet loss here effectively produces additive white impulse noise. The subjective impression is that of static noise on AM radio stations or crackling on old phonograph records. For a given PESQ-derived MOS, this type of degradation is more acceptable to listeners than choppiness or tones common in VoIP.
バッファ損失の影響を受けたときに音声圧縮方法が生成する可能性のあるアーティファクトとは異なり、ここでのパケット損失は付加的なホワイトインパルスノイズを効果的に生成します。主観的な印象は、AMラジオ局の静的ノイズまたは古い蓄音機のレコードのパチパチという印象です。特定のPESQから派生したMOSの場合、このタイプの低下は、VoIPで一般的な途切れやトーンよりもリスナーに受け入れられます。
If MOS>4 (full toll quality) is required, then the following packet drop probabilities are allowable:
MOS> 4（フル料金品質）が必要な場合、次のパケットドロップ確率が許容されます。
zero insertion - 0.05%
ゼロ挿入-0.05％
previous sample - 0.25%
前のサンプル-0.25％
linear interpolation - 0.75%
線形補間-0.75％
STEIN - 2%
ストーン-2％
If MOS>3.75 (barely perceptible quality degradation) is acceptable, then the following packet drop probabilities are allowable:
MOS> 3.75（かろうじて知覚可能な品質低下）が許容できる場合、次のパケットドロップ確率が許容されます。
zero insertion - 0.1%
ゼロ挿入-0.1％
previous sample - 0.75%
前のサンプル-0.75％
linear interpolation - 3%
線形補間-3％
STEIN - 6.5%
ストーン-6.5％
If MOS>3.5 (cell phone quality) is tolerable, then the following packet drop probabilities are allowable:
MOS> 3.5（携帯電話の品質）が許容できる場合、次のパケットドロップ確率が許容されます。
zero insertion - 0.4%
ゼロ挿入-0.4％
previous sample - 2%
前のサンプル-2％
linear interpolation - 8%
線形補間-8％
STEIN - 14%
ストーン-14％
Authors' Addresses
著者のアドレス
Yaakov (Jonathan) Stein RAD Data Communications 24 Raoul Wallenberg St., Bldg C Tel Aviv 69719 Israel
Yaakov（Jonathan）Stein RAD Data Communications 24 Raoul Wallenberg St.、Bldg C Tel Aviv 69719 Israel
Phone: +972 (0)3 645-5389
Email: yaakov_s@rad.com
David L. Black EMC Corporation 176 South St. Hopkinton, MA 69719 United States
David L. Black EMC Corporation 176 South St. Hopkinton、MA 69719アメリカ
Phone: +1 (508) 293-7953
Email: david.black@emc.com
Bob Briscoe BT
ボブ・ブリスコBT
Email: ietf@bobbriscoe.net
URI: http://bobbriscoe.net/