Network Working Group R. Bush
Request for Comments: 3439 D. Meyer
Updates: 1958 December 2002
Category: Informational
Some Internet Architectural Guidelines and Philosophy
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 (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
Abstract
抽象
This document extends RFC 1958 by outlining some of the philosophical guidelines to which architects and designers of Internet backbone networks should adhere. We describe the Simplicity Principle, which states that complexity is the primary mechanism that impedes efficient scaling, and discuss its implications on the architecture, design and engineering issues found in large scale Internet backbones.
この文書は、インターネットのバックボーンネットワークの建築家やデザイナーが遵守すべきする哲学的なガイドラインのいくつかを概説することによってRFC 1958を拡張します。私たちは、複雑さが効率的なスケーリングを妨げる主要なメカニズムであると述べて単純化原則を、説明し、大規模なインターネットバックボーンで見つかった建築、デザインとエンジニアリングの課題への影響を議論します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Large Systems and The Simplicity Principle . . . . . . . . . 3
2.1. The End-to-End Argument and Simplicity . . . . . . . . . 3
2.2. Non-linearity and Network Complexity . . . . . . . . . . 3
2.2.1. The Amplification Principle. . . . . . . . . . . . . . . 4
2.2.2. The Coupling Principle . . . . . . . . . . . . . . . . . 5
2.3. Complexity lesson from voice. . . . . . . . . . . . . . . 6
2.4. Upgrade cost of complexity. . . . . . . . . . . . . . . . 7
3. Layering Considered Harmful. . . . . . . . . . . . . . . . . 7
3.1. Optimization Considered Harmful . . . . . . . . . . . . . 8
3.2. Feature Richness Considered Harmful . . . . . . . . . . . 9
3.3. Evolution of Transport Efficiency for IP. . . . . . . . . 9
3.4. Convergence Layering. . . . . . . . . . . . . . . . . . . 9
3.4.1. Note on Transport Protocol Layering. . . . . . . . . . . 11
3.5. Second Order Effects . . . . . . . . . . . . . . . . . . 11
3.6. Instantiating the EOSL Model with IP . . . . . . . . . . 12
4. Avoid the Universal Interworking Function. . . . . . . . . . 12
4.1. Avoid Control Plane Interworking . . . . . . . . . . . . . 13
5. Packet versus Circuit Switching: Fundamental Differences . . 13
5.1. Is PS is inherently more efficient than CS? . . . . . . . 13
5.2. Is PS simpler than CS? . . . . . . . . . . . . . . . . . . 14
5.2.1. Software/Firmware Complexity . . . . . . . . . . . . . . 15
5.2.2. Macro Operation Complexity . . . . . . . . . . . . . . . 15
5.2.3. Hardware Complexity. . . . . . . . . . . . . . . . . . . 15
5.2.4. Power. . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.2.5. Density. . . . . . . . . . . . . . . . . . . . . . . . . 16
5.2.6. Fixed versus variable costs. . . . . . . . . . . . . . . 16
5.2.7. QoS. . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.2.8. Flexibility. . . . . . . . . . . . . . . . . . . . . . . 17
5.3. Relative Complexity . . . . . . . . . . . . . . . . . . . 17
5.3.1. HBHI and the OPEX Challenge. . . . . . . . . . . . . . . 18
6. The Myth of Over-Provisioning. . . . . . . . . . . . . . . . 18
7. The Myth of Five Nines . . . . . . . . . . . . . . . . . . . 19
8. Architectural Component Proportionality Law. . . . . . . . . 20
8.1. Service Delivery Paths . . . . . . . . . . . . . . . . . . 21
9. Conclusions. . . . . . . . . . . . . . . . . . . . . . . . . 21
10. Security Considerations . . . . . . . . . . . . . . . . . . 22
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 23
12. References. . . . . . . . . . . . . . . . . . . . . . . . . 23
13. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . 27
14. Full Copyright Statement. . . . . . . . . . . . . . . . . . 28
RFC 1958 [RFC1958] describes the underlying principles of the Internet architecture. This note extends that work by outlining some of the philosophical guidelines to which architects and designers of Internet backbone networks should adhere. While many of the areas outlined in this document may be controversial, the unifying principle described here, controlling complexity as a mechanism to control costs and reliability, should not be. Complexity in carrier networks can derive from many sources. However, as stated in [DOYLE2002], "Complexity in most systems is driven by the need for robustness to uncertainty in their environments and component parts far more than by basic functionality". The major thrust of this document, then, is to raise awareness about the complexity of some of our current architectures, and to examine the effect such complexity will almost certainly have on the IP carrier industry's ability to succeed.
RFC 1958 [RFC1958]は、インターネットアーキテクチャの基本原則を説明しています。このノートでは、インターネットのバックボーンネットワークの建築家やデザイナーが付着先となる哲学的なガイドラインのいくつかを概説することによって、その仕事を拡張します。このドキュメントで概説した領域の多くは論争のかもしれないが、統一原理は、コストと信頼性を制御するメカニズムとして複雑さを制御し、ここで説明し、すべきではありません。キャリアネットワークの複雑さは、多くのソースから派生することができます。ただし、[DOYLE2002]で述べたように、「ほとんどのシステムでの複雑さは、その環境や構成部品の不確実性に対するロバスト性のために必要な基本的な機能によって、よりもはるかに多くによって駆動されます」。この文書の主要な推進力は、その後、私たちの現在のアーキテクチャのいくつかの複雑さについての意識を高めるために、そして、そのような複雑さはほぼ確実に成功するためにIPキャリア業界の能力に与える影響を検討することです。
The rest of this document is organized as follows: The first section describes the Simplicity Principle and its implications for the design of very large systems. The remainder of the document outlines the high-level consequences of the Simplicity Principle and how it should guide large scale network architecture and design approaches.
このドキュメントの残りは以下の通り構成されています。最初のセクションは非常に大規模なシステムの設計のための単純化原則とその意味を説明しています。文書の残りは単純化原則の高レベルの結果の概要を説明し、どのように大規模なネットワークアーキテクチャおよび設計手法を導くべきです。
The Simplicity Principle, which was perhaps first articulated by Mike O'Dell, former Chief Architect at UUNET, states that complexity is the primary mechanism which impedes efficient scaling, and as a result is the primary driver of increases in both capital expenditures (CAPEX) and operational expenditures (OPEX). The implication for carrier IP networks then, is that to be successful we must drive our architectures and designs toward the simplest possible solutions.
おそらく最初のマイクオデル、UUNETの元チーフアーキテクトによって連接されたシンプル原理は、複雑さが効率的なスケーリングを妨げる主要な機構であり、その結果、両方の資本支出の増加（CAPEX）の主要ドライバであると述べていますそして、運用コスト（OPEX）。キャリアIPネットワークのための含意は、その後、我々はできるだけ簡単な解決策に向かって私たちのアーキテクチャと設計を駆動しなければならない成功するためにということです。
The end-to-end argument, which is described in [SALTZER] (as well as in RFC 1958 [RFC1958]), contends that "end-to-end protocol design should not rely on the maintenance of state (i.e., information about the state of the end-to-end communication) inside the network. Such state should be maintained only in the end points, in such a way that the state can only be destroyed when the end point itself breaks." This property has also been related to Clark's "fate-sharing" concept [CLARK]. We can see that the end-to-end principle leads directly to the Simplicity Principle by examining the so-called "hourglass" formulation of the Internet architecture [WILLINGER2002]. In this model, the thin waist of the hourglass is envisioned as the (minimalist) IP layer, and any additional complexity is added above the IP layer. In short, the complexity of the Internet belongs at the edges, and the IP layer of the Internet should remain as simple as possible.
[SALTZER]で説明されたエンド・ツー・エンドの引数、（だけでなく、RFC 1958で[RFC1958]）、エンド・ツー・エンドのプロトコルの設計は、状態の維持に頼るべきではない」と主張する（約すなわち、情報ネットワーク内のエンド・ツー・エンド通信の状態）。このような状態は、エンドポイント自体が壊れるときの状態のみ破壊することができるように、唯一のエンドポイントで維持されるべきです。」このプロパティは、また、クラークの「運命共有」という概念[CLARK]に関係しています。私たちは、エンド・ツー・エンド原理は、インターネットアーキテクチャ[WILLINGER2002]のいわゆる「砂時計」製剤を調べることによって単純化原則に直接つながることがわかります。このモデルでは、砂時計の細いウエスト（ミニマリスト）IP層として想定され、そして任意の追加の複雑さは、IP層の上に追加されます。要するに、インターネットの複雑さが縁で属し、インターネットのIP層は、可能な限りシンプルなままにしてください。
Finally, note that the End-to-End Argument does not imply that the core of the Internet will not contain and maintain state. In fact, a huge amount coarse grained state is maintained in the Internet's core (e.g., routing state). However, the important point here is that this (coarse grained) state is almost orthogonal to the state maintained by the end-points (e.g., hosts). It is this minimization of interaction that contributes to simplicity. As a result, consideration of "core vs. end-point" state interaction is crucial when analyzing protocols such as Network Address Translation (NAT), which reduce the transparency between network and hosts.
最後に、エンドツーエンドの引数は、インターネットのコアが含まれており、状態を維持しないであろうことを意味するものではないことに注意してください。実際には、膨大な量の粗粒度状態は、インターネットのコア（例えば、ルーティング状態）に維持されます。しかしながら、ここで重要な点は、この（粗い粒度）の状態は、エンドポイント（例えば、ホスト）によって維持される状態にほぼ直交していることです。それはシンプルさに貢献する相互作用のこの最小化です。ネットワークとホストとの間の透過性を低下させるようなネットワークアドレス変換（NAT）などのプロトコルを解析するとき結果として、「コアエンドポイント対」状態との相互作用の考慮が重要です。
Complex architectures and designs have been (and continue to be) among the most significant and challenging barriers to building cost-effective large scale IP networks. Consider, for example, the task of building a large scale packet network. Industry experience has shown that building such a network is a different activity (and hence requires a different skill set) than building a small to medium scale network, and as such doesn't have the same properties. In particular, the largest networks exhibit, both in theory and in practice, architecture, design, and engineering non-linearities which are not exhibited at smaller scale. We call this Architecture, Design, and Engineering (ADE) non-linearity. That is, systems such as the Internet could be described as highly self-dissimilar, with extremely different scales and levels of abstraction [CARLSON]. The ADE non-linearity property is based upon two well-known principles from non-linear systems theory [THOMPSON]:
複雑なアーキテクチャやデザインは、費用対効果の高い大規模なIPネットワークを構築するための最も重要かつ挑戦的な障壁の間（およびであり続ける）となっています。例えば、大規模なパケットネットワークを構築する作業を考えてみましょう。業界での経験は、そのようなネットワークを構築する異なる活動であることを示す（従って、異なるスキルセットを必要とする）、中規模ネットワークに小さなを構築するよりも、そのようなものとして同じ特性を有していないいます。特に、最大のネットワークの展示は、理論と実践で、建築、デザイン、およびエンジニアリングの非線形性の両方で小さい規模で展示されていません。私たちは、このアーキテクチャ、設計、およびエンジニアリング（ADE）非直線性を呼び出します。それは、インターネットのようなシステムは、非常に異なるスケールおよび抽象[CARLSON]のレベルと、高い自己異なるように記述することができる、です。 ADE非線形特性は非線形システム理論[THOMPSON]から2つのよく知られた原理に基づいています：
The Amplification Principle states that there are non-linearities which occur at large scale which do not occur at small to medium scale.
増幅の原理は、中規模、小規模で発生していない大規模で発生する非線形性があると述べています。
COROLLARY: In many large networks, even small things can and do cause huge events. In system-theoretic terms, in large systems such as these, even small perturbations on the input to a process can destabilize the system's output.
结果：多くの大規模なネットワークでは、小さなものは、巨大なイベントの原因となりますことができます。システム論的観点から、このような大規模システムでは、プロセスへの入力の小さな摂動は、システムの出力を不安定にすることができます。
An important example of the Amplification Principle is non-linear resonant amplification, which is a powerful process that can transform dynamic systems, such as large networks, in surprising ways with seemingly small fluctuations. These small fluctuations may slowly accumulate, and if they are synchronized with other cycles, may produce major changes. Resonant phenomena are examples of non-linear behavior where small fluctuations may be amplified and have influences far exceeding their initial sizes. The natural world is filled with examples of resonant behavior that can produce system-wide changes, such as the destruction of the Tacoma Narrows bridge (due to the resonant amplification of small gusts of wind). Other examples include the gaps in the asteroid belts and rings of Saturn which are created by non-linear resonant amplification. Some features of human behavior and most pilgrimage systems are influenced by resonant phenomena involving the dynamics of the solar system, such as solar days, the 27.3 day (sidereal) and 29.5 day (synodic) cycles of the moon or the 365.25 day cycle of the sun.
増幅原理の重要な例は、一見小さな変動に驚くべき方法で、このような大規模なネットワークのような動的システムを、変換することができる強力なプロセスであり、非線形共鳴増幅です。これらの小さな変動は緩やかに蓄積すること、およびそれらが他のサイクルと同期している場合は、大きな変化をもたらすことがあります。共振現象は、小さな変動が増幅され、はるかにそれらの初期サイズを超える影響を与えることができる非線形挙動の一例です。自然界は、（風の小さな突風の共振増幅による）タコマブリッジの破壊など、システム全体の変更を生成することができる共振挙動の例で満たされています。他の例は、非線形共振増幅によって作成される土星の小惑星ベルトとリングのギャップを含みます。人間の行動と、ほとんどの巡礼システムの一部の機能は、このような太陽の日、27.3日（恒星）と29.5月の日（synodic）サイクルかの365.25日サイクルとして、ソーラーシステムのダイナミクスを伴う共振現象の影響を受けています太陽。
In the Internet domain, it has been shown that increased inter-connectivity results in more complex and often slower BGP routing convergence [AHUJA]. A related result is that a small amount of inter-connectivity causes the output of a routing mesh to be significantly more complex than its input [GRIFFIN]. An important method for reducing amplification is ensure that local changes have only local effect (this is as opposed to systems in which local changes have global effect). Finally, ATM provides an excellent example of an amplification effect: if you lose one cell, you destroy the entire packet (and it gets worse, as in the absence of mechanisms such as Early Packet Discard [ROMANOV], you will continue to carry the already damaged packet).
インターネット・ドメインでは、より複雑でしばしば遅いBGPルーティング収束[アフジャ]に相互接続結果を増加させることが示されています。関連する結果は、相互接続少量のルーティングメッシュの出力は、その入力【GRIFFIN]よりも著しく複雑させることです。増幅を減少させるための重要な方法は、ローカルの変更は、ローカル効果（これは局所的な変化は、グローバルな効果を有しているシステムに対向するように）を有することを確認しています。最後に、ATMは、増幅効果の優れた例を提供する：1つのセルを失う場合は、パケット全体を破壊（及びそれが悪化する、このような早期パケット廃棄[ロマノフ]などのメカニズムが存在しない場合のように、あなたが運ぶために続けますすでに破損したパケット）。
Another interesting example of amplification comes from the engineering domain, and is described in [CARLSON]. They consider the Boeing 777, which is a "fly-by-wire" aircraft, containing as many as 150,000 subsystems and approximately 1000 CPUs. What they observe is that while the 777 is robust to large-scale atmospheric disturbances, turbulence boundaries, and variations in cargo loads (to name a few), it could be catastrophically disabled my microscopic alterations in a very few large CPUs (as the point out, fortunately this is a very rare occurrence). This example illustrates the issue "that complexity can amplify small perturbations, and the design engineer must ensure such perturbations are extremely rare." [CARLSON]
増幅のもう一つの興味深い例は、エンジニアリングのドメインから来て、そして[CARLSON]に記載されています。彼らは、できるだけ多く15万などのサブシステムと約1000個のCPUを含む、「フライ・バイ・ワイヤ」航空機であるボーイング777を、検討してください。彼らは何を観察すると、777は（数名に）大規模な大気の擾乱、乱流境界、および貨物の負荷の変動に対して頑健である一方で、それは壊滅的ポイントとして非常に少数の大のCPU（の私の顕微鏡的変化を無効にすることができることですアウト、幸いこれは）非常にまれです。この例では、「複雑さが小さな摂動を増幅することができ、かつ設計エンジニアは、このような摂動は非常にまれであることを確認しなければならないこと。」の問題を示しています[CARLSON]
The Coupling Principle states that as things get larger, they often exhibit increased interdependence between components.
カップリング原理は、物事が大きくなるにつれ、彼らは多くの場合、コンポーネント間の相互依存性の増加を示すと述べています。
COROLLARY: The more events that simultaneously occur, the larger the likelihood that two or more will interact. This phenomenon has also been termed "unforeseen feature interaction" [WILLINGER2002].
结果：同時に発生する複数の事象、二つ以上が相互作用することに大きな可能性。この現象はまた、[WILLINGER2002]「不測の機能の相互作用」と呼ばれています。
Much of the non-linearity observed large systems is largely due to coupling. This coupling has both horizontal and vertical components. In the context of networking, horizontal coupling is exhibited between the same protocol layer, while vertical coupling occurs between layers.
大規模なシステムを観察した非直線性の多くは、カップリングによるところが大きいです。この結合は、水平および垂直成分の両方を有します。垂直結合が層の間に生じている間ネットワーキングの文脈では、水平方向のカップリングは、同じプロトコル層との間に発揮されます。
Coupling is exhibited by a wide variety of natural systems, including plasma macro-instabilities (hydro-magnetic, e.g., kink, fire-hose, mirror, ballooning, tearing, trapped-particle effects) [NAVE], as well as various kinds of electrochemical systems (consider the custom fluorescent nucleotide synthesis/nucleic acid labeling problem [WARD]). Coupling of clock physical periodicity has also been observed [JACOBSON], as well as coupling of various types of biological cycles.
カップリングは、プラズママクロ不安定性（ハイドロ磁気、例えば、キンク、火災ホース、ミラー、バルーニング、引き裂き、捕捉された粒子の効果）[NAVE]、ならびに各種含む天然システム、多種多様によって発揮されます電気化学システム（カスタム蛍光ヌクレオチド合成/核酸標識問題[WARD]を考えます）。クロック物理周期の結合はまた、[JACOBSON】観察、ならびに生物学的サイクルの様々なタイプのカップリングされています。
Several canonical examples also exist in well known network systems. Examples include the synchronization of various control loops, such as routing update synchronization and TCP Slow Start synchronization [FLOYD,JACOBSON]. An important result of these observations is that coupling is intimately related to synchronization. Injecting randomness into these systems is one way to reduce coupling.
いくつかの正規の実施例はまた、周知のネットワークシステム内に存在します。例としては、ルーティングアップデートの同期及びTCPスロースタート同期[フロイド、JACOBSON]のような様々な制御ループの同期化を含みます。これらの観察の重要な結果は、カップリングには、同期と密接に関連しているということです。これらのシステムの中にランダム性を注入する結合を低減する一つの方法です。
Interestingly, in analyzing risk factors for the Public Switched Telephone Network (PSTN), Charles Perrow decomposes the complexity problem along two related axes, which he terms "interactions" and "coupling" [PERROW]. Perrow cites interactions and coupling as significant factors in determining the reliability of a complex system (and in particular, the PSTN). In this model, interactions refer to the dependencies between components (linear or non-linear), while coupling refers to the flexibility in a system. Systems with simple, linear interactions have components that affect only other components that are functionally downstream. Complex system components interact with many other components in different and possibly distant parts of the system. Loosely coupled systems are said to have more flexibility in time constraints, sequencing, and environmental assumptions than do tightly coupled systems. In addition, systems with complex interactions and tight coupling are likely to have unforeseen failure states (of course, complex interactions permit more complications to develop and make the system hard to understand and predict); this behavior is also described in [WILLINGER2002]. Tight coupling also means that the system has less flexibility in recovering from failure states.
興味深いことに、公共の危険因子の分析に電話網（PSTN）、チャールズ・ペローは、二つの関連する軸に沿った複雑さの問題、彼用語「相互作用」および「結合」[PERROW]を分解する。 Perrowは、複雑なシステム（特に、PSTN）の信頼性を決定する重要な要因として相互作用および結合を引用します。カップリングは、システムの柔軟性を指すこのモデルでは、相互作用は、成分（線形または非線形）間の依存関係を指します。シンプルで直線的な相互作用を持つシステムは、機能的に下流にあるだけで、他のコンポーネントに影響を与える要素を持っています。複雑なシステム・コンポーネントは、システムの異なる、おそらく遠くの部品の多くの他のコンポーネントと相互作用します。疎結合システムは、密結合のシステムが行うよりも、時間的制約、シーケンシング、および環境の前提条件でより多くの柔軟性を持っていると言われています。また、複雑な相互作用と緊密な結合を持つシステムが予期せぬ故障状態を持っている可能性があります（もちろん、複雑な相互作用を開発し、理解し、予測することは難しいシステムを作るために多くの合併症を許可します）。この現象は、[WILLINGER2002]に記載されています。密結合は、システムが障害状態からの回復にはあまり柔軟性を有することを意味します。
The PSTN's SS7 control network provides an interesting example of what can go wrong with a tightly coupled complex system. Outages such as the well publicized 1991 outage of AT&T's SS7 demonstrates the phenomenon: the outage was caused by software bugs in the switches' crash recovery code. In this case, one switch crashed due to a hardware glitch. When this switch came back up, it (plus a reasonably probable timing event) caused its neighbors to crash When the neighboring switches came back up, they caused their neighbors to crash, and so on [NEUMANN] (the root cause turned out to be a misplaced 'break' statement; this is an excellent example of cross-layer coupling). This phenomenon is similar to the phase-locking of weakly coupled oscillators, in which random variations in sequence times plays an important role in system stability [THOMPSON].
PSTNのSS7制御ネットワークは、密結合、複雑なシステムと間違って行くことができるかの興味深い例を提供します。そのようなAT＆TのSS7のも公表1991停電などの停止は、現象を示しています停止がスイッチクラッシュリカバリコードにソフトウェアのバグによって引き起こされました。この場合、一方のスイッチは、ハードウェアの不具合に墜落しました。このスイッチが戻って来たときに近接スイッチがアップ戻ってきたとき、それ（プラス合理的に可能性の高いタイミングイベントが）その隣人がクラッシュする原因と、彼らは彼らの隣人をクラッシュさせ、かつので、[NEUMANN]上の（根本原因があることが判明しました見当違いの「ブレーク」ステートメントは、これは）クロスレイヤ結合の優れた例です。この現象は、シーケンス時間のランダムな変動は、システムの安定性[THOMPSON]において重要な役割を果たしている、弱く結合された発振器の位相ロックに類似しています。
In the 1970s and 1980s, the voice carriers competed by adding features which drove substantial increases in the complexity of the PSTN, especially in the Class 5 switching infrastructure. This complexity was typically software-based, not hardware driven, and therefore had cost curves worse than Moore's Law. In summary, poor margins on voice products today are due to OPEX and CAPEX costs not dropping as we might expect from simple hardware-bound implementations.
1970年代と1980年代に、音声キャリアは特にクラス5スイッチング・インフラストラクチャに、PSTNの複雑さの実質的な増加を運転した機能を追加することによって、競合します。この複雑さは、通常、ソフトウェアベースではなく、ハードウェアを駆動し、したがって、ムーアの法則よりも悪いコスト曲線を持っていました。要約すると、音声製品の貧しいマージンは本日、OPEXとCAPEXに起因している私たちは、単純なハードウェアバインドの実装から期待するかもしれないと落下しませかかります。
Consider the cost of providing new features in a complex network. The traditional voice network has little intelligence in its edge devices (phone instruments), and a very smart core. The Internet has smart edges, computers with operating systems, applications, etc., and a simple core, which consists of a control plane and packet forwarding engines. Adding an new Internet service is just a matter of distributing an application to the a few consenting desktops who wish to use it. Compare this to adding a service to voice, where one has to upgrade the entire core.
複雑なネットワークの新機能を提供するコストを考えてみましょう。従来の音声ネットワークは、そのエッジデバイス（携帯電話機器）に少し知性、そして非常にスマートなコアを有します。インターネットは、コントロールプレーンとパケット転送エンジンで構成されたスマートエッジなどのオペレーティングシステム、アプリケーション、とコンピュータ、および単純なコアを持っています。新しいインターネットサービスを追加すると、それを使用したいいくつかの同意デスクトップにアプリケーションを配布するだけです。 1はコア全体をアップグレードする必要があり、音声、にサービスを追加するには、この比較。
There are several generic properties of layering, or vertical integration as applied to networking. In general, a layer as defined in our context implements one or more of
ネットワークに適用されるレイヤー、または垂直統合のいくつかの一般的な性質があります。一般的には、私たちのコンテキストで定義されている層は、1つ以上を実装します
Error Control: The layer makes the "channel" more reliable (e.g., reliable transport layer)
エラー制御：層は、「チャンネル」より信頼性の高い（例えば、信頼性の高いトランスポート層）を行います
Flow Control: The layer avoids flooding slower peer (e.g., ATM flow control)
フロー制御：層が遅くピア（例えば、ATMフロー制御）をフラッディング回避
Fragmentation: Dividing large data chunks into smaller pieces, and subsequent reassembly (e.g., TCP MSS fragmentation/reassembly)
フラグメンテーション：小さな断片に大きなデータチャンクの分割、およびその後の再組み立て（例えば、TCP MSSの断片化/再アセンブリ）
Multiplexing: Allow several higher level sessions share single lower level "connection" (e.g., ATM PVC)
多重：いくつかのより高いレベルのセッションは、単一の低レベル「接続」を共有できるように（例えば、ATM PVC）
Connection Setup: Handshaking with peer (e.g., TCP three-way handshake, ATM ILMI)
接続セットアップ：ピアとのハンドシェイク（例えば、TCPスリーウェイハンドシェイク、ATM ILMI）
Addressing/Naming: Locating, managing identifiers associated with entities (e.g., GOSSIP 2 NSAP Structure [RFC1629])
アドレッシング/ネーミング：位置決め、エンティティに関連付けられた識別子を管理する（例えば、GOSSIP 2 NSAP構造[RFC1629]）
Layering of this type does have various conceptual and structuring advantages. However, in the data networking context structured layering implies that the functions of each layer are carried out completely before the protocol data unit is passed to the next layer. This means that the optimization of each layer has to be done separately. Such ordering constraints are in conflict with efficient implementation of data manipulation functions. One could accuse the layered model (e.g., TCP/IP and ISO OSI) of causing this conflict. In fact, the operations of multiplexing and segmentation both hide vital information that lower layers may need to optimize their performance. For example, layer N may duplicate lower level functionality, e.g., error recovery hop-hop versus end-to-end error recovery. In addition, different layers may need the same information (e.g., time stamp): layer N may need layer N-2 information (e.g., lower layer packet sizes), and the like [WAKEMAN]. A related and even more ironic statement comes from Tennenhouse's classic paper, "Layered Multiplexing Considered Harmful" [TENNENHOUSE]: "The ATM approach to broadband networking is presently being pursued within the CCITT (and elsewhere) as the unifying mechanism for the support of service integration, rate adaptation, and jitter control within the lower layers of the network architecture. This position paper is specifically concerned with the jitter arising from the design of the "middle" and "upper" layers that operate within the end systems and relays of multi-service networks (MSNs)."
このタイプの積層は、様々な概念と構造の利点を持っています。しかし、データ・ネットワーキングの文脈構造積層は、各層の機能は、プロトコルデータユニットが次の層に渡される前に完全に行われることを意味します。これは、各レイヤの最適化が別々に行わなければならないことを意味します。このような順序付けの制約は、データ操作機能の効率的な実装と競合しています。一つは、この紛争を引き起こす（例えば、TCP / IPおよびISO OSI）階層モデルを非難することができます。実際には、多重化およびセグメント化の両方の動作は、下位層がその性能を最適化する必要があるかもしれない重要な情報を隠し。例えば、層Nは、より低いレベルの機能、エンドツーエンドのエラー回復対、例えば、エラー回復ホップホップを複製することができます。加えて、異なる層が同じ情報を必要とするかもしれない（例えば、タイムスタンプ）：層のN層を必要とするかもしれないN-2の情報（例えば、下位層パケットサイズ）など[WAKEMAN]。関連して、さらに皮肉文がTennenhouseの古典的な論文から来て、[TENNENHOUSE]「階層化多重化は、有害と考えられ」：「ブロードバンドネットワークへのATMのアプローチは、現在、CCITT内追求（および他の場所）されているサービスのサポートのための統一メカニズムとしてネットワークアーキテクチャの下位層内の統合、レート適応、およびジッタ制御。この位置は用紙が「中」の設計とマルチのエンドシステムとリレー内で動作する「上位」層から生じるジッタと特異的に関係しています-serviceネットワーク（MSNs）。」
As a result of inter-layer dependencies, increased layering can quickly lead to violation of the Simplicity Principle. Industry experience has taught us that increased layering frequently increases complexity and hence leads to increases in OPEX, as is predicted by the Simplicity Principle. A corollary is stated in RFC 1925 [RFC1925], section 2(5):
層間の依存関係の結果、増加したレイヤーは、すぐに単純化原則の違反につながることができます。業界での経験は、頻繁に複雑になり、したがって、単純化原則によって予測された通り、OPEXの増加につながる重ねる増加したことを私たちに教えてくれました。推論は、RFC 1925 [RFC1925]に記載され、部分2（5）：
"It is always possible to agglutinate multiple separate problems into a single complex interdependent solution. In most cases this is a bad idea."
「単一の複雑な相互依存のソリューションに複数の独立した問題を凝集することが常に可能である。ほとんどの場合、これは悪い考えです。」
The first order conclusion then, is that horizontal (as opposed to vertical) separation may be more cost-effective and reliable in the long term.
一次の結論は、次に、（垂直とは対照的に）水平分離は長期的にはよりコスト効果がありかつ信頼性があり得ることです。
A corollary of the layering arguments above is that optimization can also be considered harmful. In particular, optimization introduces complexity, and as well as introducing tighter coupling between components and layers.
上記積層引数の当然の結果は、最適化にも有害と考えることができるということです。具体的には、最適化は複雑さを導入し、ならびに成分と層の間の緊密な結合を導入します。
An important and related effect of optimization is described by the Law of Diminishing Returns, which states that if one factor of production is increased while the others remain constant, the overall returns will relatively decrease after a certain point [SPILLMAN]. The implication here is that trying to squeeze out efficiency past that point only adds complexity, and hence leads to less reliable systems.
最適化の重要と関連する効果は他の人が一定のまま生産の一つの要因が増加した場合、全体的なリターンが比較的一定の点[SPILLMAN]の後に減少することを述べて収穫逓減の法則によって記述されています。ここでの意味は、その点を過ぎて効率を絞り出すしようとするだけで複雑さが増し、ひいては信頼性の低いシステムにつながるということです。
While adding any new feature may be considered a gain (and in fact frequently differentiates vendors of various types of equipment), but there is a danger. The danger is in increased system complexity.
すべての新機能を追加は、利得と考えることもできるが（実際に頻繁に機器の様々なタイプのベンダーを差別）が、危険性があります。危険性が増加し、システムの複雑さです。
The evolution of transport infrastructures for IP offers a good example of how decreasing vertical integration has lead to various efficiencies. In particular,
IPのための輸送インフラの進化は、様々な効率化につながりました垂直統合を減らす方法の良い例を提供しています。特に、
| IP over ATM over SONET --> | IP over SONET over WDM --> | IP over WDM | \|/ Decreasing complexity, CAPEX, OPEX
| SONETオーバーATM上のIP - > | WDMオーバーSONETオーバーIP - > | WDMオーバーIP | \ | /複雑さを減らす、CAPEX、OPEX
The key point here is that layers are removed resulting in CAPEX and OPEX efficiencies.
ここで重要な点は、層がCAPEXとOPEX効率が得られ削除されていることです。
Convergence is related to the layering concepts described above in that convergence is achieved via a "convergence layer". The end state of the convergence argument is the concept of Everything Over Some Layer (EOSL). Conduit, DWDM, fiber, ATM, MPLS, and even IP have all been proposed as convergence layers. It is important to note that since layering typically drives OPEX up, we expect convergence will as well. This observation is again consistent with industry experience.
収束が「収束層」を介して達成される収束して上述した階層化の概念に関連しています。収束引数の終了状態は、いくつかのレイヤ（EOSL）以上のすべての概念です。コンジット、DWDM、繊維、ATM、MPLS、さらにIPは、すべての収束層として提案されています。私たちが、収束が同様に期待、一般的に階層化以来、OPEXを押し上げることに注意することが重要です。この観察は、業界での経験と再び一致しています。
There are many notable examples of convergence layer failure. Perhaps the most germane example is IP over ATM. The immediate and most obvious consequence of ATM layering is the so-called cell tax: First, note that the complete answer on ATM efficiency is that it depends upon packet size distributions. Let's assume that typical Internet type traffic patterns, which tend to have high percentages of packets at 40, 44, and 552 bytes. Recent data [CAIDA] shows that about 95% of WAN bytes and 85% of packets are TCP. Much of this traffic is composed of 40/44 byte packets.
収束層の障害の多くの顕著な例があります。おそらく最も密接な例では、ATM上でIPです。 ATMレイヤリングの即時かつ最も明白な結果は、いわゆるセル税である：まず、ATM効率の完全な答えは、それがパケットのサイズ分布に依存することであることに注意してください。のは、その典型的なインターネットタイプのトラフィックの40でパケットの高い割合を持っている傾向があるパターン、44、および552のバイトを想定してみましょう。最近のデータ[CAIDA] WANバイトの約95％であり、パケットの85％がTCPであることを示しています。このトラフィックの多くは40/44バイトのパケットで構成されています。
Now, consider the case of a a DS3 backbone with PLCP turned on. Then the maximum cell rate is 96,000 cells/sec. If you multiply this value by the number of bits in the payload, you get: 96000 cells/sec * 48 bytes/cell * 8 = 36.864 Mbps. This, however, is unrealistic since it assumes perfect payload packing. There are two other things that contribute to the ATM overhead (cell tax): The wasted padding and the 8 byte SNAP header.
PLCPをオンにして今、DS3バックボーンの場合を考えます。次いで、最大セルレートが96,000細胞/秒です。あなたはペイロードのビット数によって、この値を乗算した場合、あなたが得る：96000セル/秒* 48のバイト/セル* 8 = 36.864 Mbpsの。それは完璧なペイロード梱包を想定しているので、これは、しかし、非現実的です。無駄なパディングと8バイトのSNAPヘッダー：ATMオーバーヘッド（セルタックス）に貢献する他の二つのものがあります。
It is the SNAP header which causes most of the problems (and you can't do anything about this), forcing most small packets to consume two cells, with the second cell to be mostly empty padding (this interacts really poorly with the data quoted above, e.g., that most packets are 40-44 byte TCP Ack packets). This causes a loss of about another 16% from the 36.8 Mbps ideal throughput.
それは（これは引用されたデータと、本当に悪い相互作用し、ほとんど空にパディングされる第2のセルと、二つのセルを消費するために、最も小さなパケットを強制的に、ほとんどの問題の原因となる（そして、あなたがこのことについて何もすることができません）SNAPヘッダであります上記、例えば、ほとんどのパケットが40-44バイトTCP ACKパケットであることを）。これは、36.8 Mbpsの理想的なスループットからさらに約16％の損失が発生します。
So the total throughput ends up being (for a DS3):
だから、全体のスループットは（DS3のため）されて終わります。
DS3 Line Rate: 44.736
PLCP Overhead - 4.032
Per Cell Header: - 3.840
SNAP Header & Padding: - 5.900
=========
30.960 Mbps
Result: With a DS3 line rate of 44.736 Mbps, the total overhead is about 31%.
結果：44.736 MbpsでのDS3回線速度で、総オーバーヘッドは約31％です。
Another way to look at this is that since a large fraction of WAN traffic is comprised of TCP ACKs, one can make a different but related calculation. IP over ATM requires:
これを見てする別の方法は、WANトラフィックの大部分は、TCPのACKで構成されているため、1が異なるが関連する計算を行うことができるということです。 ATMを介したIPが必要です。
IP data (40 bytes in this case)
8 bytes SNAP
8 bytes AAL5 stuff
5 bytes for each cell
+ as much more as it takes to fill out the last cell
On ATM, this becomes two cells - 106 bytes to convey 40 bytes of information. The next most common size seems to be one of several sizes in the 504-556 byte range - 636 bytes to carry IP, TCP, and a 512 byte TCP payload - with messages larger than 1000 bytes running third.
情報の40のバイトを搬送するために106バイト - ATMに、この2つのセルになります。 IP、TCPを運ぶために636バイト、512バイトのTCPペイロード - - 第三を実行している1000バイトを超えるメッセージと次の最も一般的なサイズは、504から556バイトの範囲内のいくつかのサイズの一つのようです。
One would imagine that 87% payload (556 byte message size) is better than 37% payload (TCP Ack size), but it's not the 95-98% that customers are used to, and the predominance of TCP Acks skews the average.
一つは、87％のペイロード（556バイトのメッセージサイズ）が37％のペイロード（TCP ACKサイズ）よりも優れているが、それは顧客がするために使用されている95から98パーセントではない、とTCP ACKの優位性は、平均値をスキューという。想像します
Protocol layering models are frequently cast as "X over Y" models. In these cases, protocol Y carries protocol X's protocol data units (and possibly control data) over Y's data plane, i.e., Y is a "convergence layer". Examples include Frame Relay over ATM, IP over ATM, and IP over MPLS. While X over Y layering has met with only marginal success [TENNENHOUSE,WAKEMAN], there have been a few notable instances where efficiency can be and is gained. In particular, "X over Y efficiencies" can be realized when there is a kind of "isomorphism" between the X and Y (i.e., there is a small convergence layer). In these cases X's data, and possibly control traffic, are "encapsulated" and transported over Y. Examples include Frame Relay over ATM, and Frame Relay, AAL5 ATM and Ethernet over L2TPv3 [L2TPV3]; the simplifying factors here are that there is no requirement that a shared clock be recovered by the communicating end points, and that control-plane interworking is minimized. An alternative is to interwork the X and Y's control and data planes; control-plane interworking is discussed below.
プロトコルの階層化モデルは、しばしば「X Yオーバー」のモデルとしてキャストされています。これらのケースでは、プロトコルYは、プロトコルXのプロトコルデータユニットを搬送する（およびおそらくはデータ制御）Yのデータプレーン上、即ち、Yは「収束層」です。例としては、MPLSを超えるATM、ATM上のIP、およびIP上でフレームリレーが含まれます。 Yレイヤリングの上にXがわずかしか成功[TENNENHOUSE、WAKEMAN]と会ったが、効率をすることができ、得られるいくつかの注目すべき事例がありました。 XとYとの間の「同型」のようなものがある場合、特に、「Y効率オーバーX」は（即ち、小さな収束層が存在する）を実現することができます。これらの場合におけるXのデータ、および場合によってトラフィックを制御する、[L2TPV3「カプセル化」とY.例を介して転送ATM上のフレームリレーを含み、そしてL2TPv3の上リレー、ATM AAL5およびイーサネットフレームれます。ここで簡略化因子が共有クロックが通信エンドポイントにより回収することは要求されず、そのコントロールプレーンのインターワーキングが最小化されるということです。代替的には、XとYの制御およびデータプレーンを連動することです。コントロールプレーンのインターワーキングについては後述します。
IP over ATM provides an excellent example of unanticipated second order effects. In particular, Romanov and Floyd's classic study on TCP good-put [ROMANOV] on ATM showed that large UBR buffers (larger than one TCP window size) are required to achieve reasonable performance, that packet discard mechanisms (such as Early Packet Discard, or EPD) improve the effective usage of the bandwidth and that more elaborate service and drop strategies than FIFO+EPD, such as per VC queuing and accounting, might be required at the bottleneck to ensure both high efficiency and fairness. Though all studies clearly indicate that a buffer size not less than one TCP window size is required, the amount of extra buffer required naturally depends on the packet discard mechanism used and is still an open issue.
ATMを介したIPは、予期しない二次効果の優れた例を提供します。特に、ATMのロマノフと良い置くTCP上のフロイドの古典的研究[ロマノフ]はパケット廃棄など早期パケット廃棄などのメカニズム（、またはことを、（1つのTCPウィンドウサイズより大きい）大UBRバッファが妥当なパフォーマンスを達成するために必要とされていることを示しましたEPD）の帯域幅の有効利用を改善し、それより精巧なサービスと、そのようなVCのキューイングおよび会計ごとに、FIFO + EPDよりも戦略をドロップするには、高い効率性と公平性の両方を確保するために、ボトルネックで必要になることがあります。すべての研究は明らかにバッファサイズ分の1つの以上のTCPウィンドウサイズが必要であることを示しているが、自然に必要な余分なバッファの使用量はパケット廃棄メカニズムに依存し、まだ未解決の問題です。
Examples of this kind of problem with layering abound in practical networking. Consider, for example, the effect of IP transport's implicit assumptions of lower layers. In particular:
レイヤーを持つこの種の問題の例としては、実用的なネットワーキングに富みます。例えば、下位層のIPトランスポートの暗黙の仮定の影響を考えてみましょう。特に：
o Packet loss: TCP assumes that packet losses are indications of congestion, but sometimes losses are from corruption on a wireless link [RFC3115].
Oパケットロス：TCPはパケットロスが輻輳の兆候であると仮定しているが、時には損失が無線リンク[RFC3115]に破損からです。
o Reordered packets: TCP assumes that significantly reordered packets are indications of congestion. This is not always the case [FLOYD2001].
Oパケット順序変更：TCPは大幅に並べ替えパケットが輻輳の兆候であることを前提としています。これは、[FLOYD2001]必ずしもそうではありません。
o Round-trip times: TCP measures round-trip times, and assumes that the lack of an acknowledgment within a period of time based on the measured round-trip time is a packet loss, and therefore an indication of congestion [KARN].
Oのラウンドトリップ時間：TCP対策往復時間、および測定された往復時間に基づいて、一定期間内に確認応答の欠如は、パケット損失、したがって、混雑の表示[カーン]であることを前提としています。
o Congestion control: TCP congestion control implicitly assumes that all the packets in a flow are treated the same by the network, but this is not always the case [HANDLEY].
O輻輳制御：TCP輻輳制御が暗黙的フロー内のすべてのパケットがネットワークによって同じように扱われることを前提とし、これは必ずしもそうではない[HANDLEY]。
While IP is being proposed as a transport for almost everything, the base assumption, that Everything over IP (EOIP) will result in OPEX and CAPEX efficiencies, requires critical examination. In particular, while it is the case that many protocols can be efficiently transported over an IP network (specifically, those protocols that do not need to recover synchronization between the communication end points, such as Frame Relay, Ethernet, and AAL5 ATM), the Simplicity and Layering Principles suggest that EOIP may not represent the most efficient convergence strategy for arbitrary services. Rather, a more CAPEX and OPEX efficient convergence layer might be much lower (again, this behavior is predicted by the Simplicity Principle).
IPはIP上すべて（EOIP）はOPEXとCAPEX効率化につながることを、ほとんどすべてのトランスポートとして基本仮説を提案している間、重要な検査が必要です。それはケースであるが、特に、多くのプロトコルを効率的にIPネットワーク上で移送することができること（具体的には、フレームリレー、イーサネット、およびAAL5 ATMなどの通信エンドポイント間の同期を回復する必要がないそれらのプロトコル）シンプルさと階層化の原則はEOIPは、任意のサービスのための最も効率的なコンバージェンス戦略を表していないことを示唆しています。むしろ、より多くのCAPEXとOPEX効率的な収束層ははるかに低いかもしれません（再び、この動作は単純化原則によって予測されます）。
An example of where EOIP would not be the most OPEX and CAPEX efficient transport would be in those cases where a service or protocol needed SONET-like restoration times (e.g., 50ms). It is not hard to imagine that it would cost more to build and operate an IP network with this kind of restoration and convergence property (if that were even possible) than it would to build the SONET network in the first place.
EOIPが最もOPEXとCAPEX効率的な輸送ではない場合の例はサービスまたはプロトコルが、SONETのような復旧時間（例えば、50ミリ秒）が必要な場合であろう。 （それも可能だった場合）、それが最初の場所でSONETネットワークを構築する場合と比べて、構築し、回復と収束性のこの種のIPネットワークを動作させるために多くを要するだろうと想像することは難しいことではありません。
While there have been many implementations of Universal Interworking unction (UIWF), IWF approaches have been problematic at large scale. his concern is codified in the Principle of Minimum Intervention BRYANT]:
ユニバーサルインターワーキング慰め（UIWF）の多くの実装が存在してきたが、IWFのアプローチは、大規模で問題となっています。彼の関心は、最小介入BRYANT]の原則に成文化されています。
"To minimise the scope of information, and to improve the efficiency of data flow through the Encapsulation Layer, the payload should, where possible, be transported as received without modification."
「受信した情報の範囲を最小限にするため、および封入層を介してデータフローの効率を向上させるために、ペイロードは、可能な場合、変更せずに輸送されなければなりません。」
This corollary is best understood in the context of the integrated solutions space. In this case, the architecture and design frequently achieves the worst of all possible worlds. This is due to the fact that such integrated solutions perform poorly at both ends of the performance/CAPEX/OPEX spectrum: the protocols with the least switching demand may have to bear the cost of the most expensive, while the protocols with the most stringent requirements often must make concessions to those with different requirements. Add to this the various control plane interworking issues and you have a large opportunity for failure. In summary, interworking functions should be restricted to data plane interworking and encapsulations, and these functions should be carried out at the edge of the network.
この当然の結果は、最高の統合ソリューションスペースの文脈で理解されています。この場合は、アーキテクチャと設計は頻繁にすべての可能世界の最悪を実現しています。少なくとも切り替え需要が最も厳しい要件を持つプロトコルながら、最も高価な費用を負担する必要がありますとプロトコル：これは、このような統合されたソリューションは、性能/ CAPEX / OPEXスペクトルの両端にうまく機能しないという事実によるものです多くの場合、異なる要件を持つものに譲歩をしなければなりません。この各種の制御プレーンのインターワーキングの問題に追加すると、失敗の大きなチャンスを持っています。要約すると、インターワーキング機能は、データプレーンのインターワーキング及びカプセル化に限定されるべきであり、これらの機能は、ネットワークのエッジで行われるべきです。
As described above, interworking models have been successful in those cases where there is a kind of "isomorphism" between the layers being interworked. The trade-off here, frequently described as the "Integrated vs. Ships In the Night trade-off" has been examined at various times and at various protocol layers. In general, there are few cases in which such integrated solutions have proven efficient. Multi-protocol BGP [RFC2283] is a subtly different but notable exception. In this case, the control plane is independent of the format of the control data. That is, no control plane data conversion is required, in contrast with control plane interworking models such as the ATM/IP interworking envisioned by some soft-switch manufacturers, and the so-called "PNNI-MPLS SIN" interworking [ATMMPLS].
上述したように、インターワーキングモデルは、インターワーキングされる層との間の「同型」のようなものがあるような場合に成功しています。しばしば「統合対夜のトレードオフに入れる」として説明ここでのトレードオフは、様々な時間に及び様々なプロトコル層で検討されています。一般に、このような統合ソリューションは、効率的に証明している中で、いくつかの例があります。マルチプロトコルBGP [RFC2283]は微妙に異なるが、顕著な例外です。この場合、制御プレーンは、制御データのフォーマットとは無関係です。すなわち、[ATMMPLS】インターワーキングこのようないくつかのソフトスイッチ製造業者によって想定されるATM / IPインターワーキングなどの制御プレーンのインターワーキングモデルと対照的に、制御プレーンデータ変換が必要とされない、である、いわゆる「PNNI-MPLS SIN」。
Conventional wisdom holds that packet switching (PS) is inherently more efficient than circuit switching (CS), primarily because of the efficiencies that can be gained by statistical multiplexing and the fact that routing and forwarding decisions are made independently in a hop-by-hop fashion [[MOLINERO2002]. Further, it is widely assumed that IP is simpler that circuit switching, and hence should be more economical to deploy and manage [MCK2002]. However, if one examines these and related assumptions, a different picture emerges (see for example [ODLYZKO98]). The following sections discuss these assumptions.
従来の知識は、パケット交換（PS）は、主に統計多重およびルーティングおよび転送決定はホップバイホップで独立して行われているという事実によって得ることができる効率の回線交換（CS）、より本質的に、より効率的であると考えていますファッション[[MOLINERO2002]。また、広くIPは、その回線交換簡単であり、したがって[MCK2002]展開および管理がより経済的であることが想定されます。一つは、これらと関連する仮定を調べる場合は、別の画像は、（[ODLYZKO98実施例を参照）現れます。次のセクションでは、これらの仮定を議論します。
It is well known that packet switches make efficient use of scarce bandwidth [BARAN]. This efficiency is based on the statistical multiplexing inherent in packet switching. However, we continue to be puzzled by what is generally believed to be the low utilization of
よくパケットスイッチが乏しい帯域幅[BARAN]を効率的に使用することが知られています。この効率は、パケット交換に固有の統計多重に基づいています。しかし、我々は一般の利用率が低くなると考えられるもので困惑され続け
Internet backbones. The first question we might ask is what is the current average utilization of Internet backbones, and how does that relate to the utilization of long distance voice networks? Odlyzko and Coffman [ODLYZKO,COFFMAN] report that the average utilization of links in the IP networks was in the range between 3% and 20% (corporate intranets run in the 3% range, while commercial Internet backbones run in the 15-20% range). On the other hand, the average utilization of long haul voice lines is about 33%. In addition, for 2002, the average utilization of optical networks (all services) appears to be hovering at about 11%, while the historical average is approximately 15% [ML2002]. The question then becomes why we see such utilization levels, especially in light of the assumption that PS is inherently more efficient than CS. The reasons cited by Odlyzko and Coffman include:
インターネットバックボーン。私達が頼むかもしれない最初の質問は、インターネットバックボーンの現在の平均使用率は何かということです、そしてどのようにそれは長距離音声ネットワークの利用に関連していますか？ Odlyzkoと商用インターネットのバックボーンは15から20パーセントで実行しながら、IPネットワーク内のリンクの平均使用率は、3％の範囲内で実行する企業のイントラネット（3％と20％の間の範囲であったことをコフマン[ODLYZKO、コフマン]レポート範囲）。一方、長距離音声回線の平均使用率は約33％でした。加えて、2002年、光ネットワーク（すべてのサービス）の平均使用率は、過去の平均は約15％[ML2002]であるが、約11％でホバリングしているように見えます。私たちは、このような利用レベルを参照してください、なぜ質問は、特にPSがCSよりも本質的に、より効率的であるという仮定の光の中で、となります。 Odlyzkoとコフマンによって引用さの理由は、次のとおりです。
(i). Internet traffic is extremely asymmetric and bursty, but links are symmetric and of fixed capacity (i.e., don't know the traffic matrix, or required link capacities);
（私）。インターネットトラフィックが非常に非対称とバースト性ですが、リンクが対称と固定容量である（すなわち、トラフィックマトリクス、または必要なリンク容量を知りません）。
(ii). It is difficult to predict traffic growth on a link, so operators tend to add bandwidth aggressively;
（ⅱ）。リンク上のトラフィックの成長を予測することは困難であるため、事業者は積極的に帯域幅を追加する傾向があります。
(iii). Falling prices for coarser bandwidth granularity make it appear more economical to add capacity in large increments.
（ハ）。粗い帯域幅の単位のための価格下落は、それが大きな単位で容量を追加する方が経済的に表示させます。
Other static factors include protocol overhead, other kinds of equipment granularity, restoration capacity, and provisioning lag time all contribute to the need to "over-provision" [MC2001].
他の静的要素は、すべての必要性を「オーバープロビジョニング」[MC2001]に寄与するプロトコルオーバーヘッド、機器粒度の他の種類、回復容量、およびプロビジョニング遅延時間を含みます。
The end-to-end principle can be interpreted as stating that the complexity of the Internet belongs at the edges. However, today's Internet backbone routers are extremely complex. Further, this complexity scales with line rate. Since the relative complexity of circuit and packet switching seems to have resisted direct analysis, we instead examine several artifacts of packet and circuit switching as complexity metrics. Among the metrics we might look at are software complexity, macro operation complexity, hardware complexity, power consumption, and density. Each of these metrics is considered below.
エンド・ツー・エンド原理は、インターネットの複雑さが縁で属することを示すと解釈することができます。しかし、今日のインターネットバックボーンルータは非常に複雑です。さらに、この複雑さは、ライン・レートに比例します。回路およびパケット交換の相対的な複雑さは、直接分析に抵抗しているように見えるので、私たちは、代わりに複雑指標としてパケットおよび回線交換のいくつかの成果物を調べます。メトリックの中で、私たちは、見えるかもしれませんソフトウェアの複雑、マクロ操作の複雑さ、ハードウェアの複雑さ、消費電力、および密度があります。これらの指標のそれぞれについて考察されます。
One measure of software/firmware complexity is the number of instructions required to program the device. The typical software image for an Internet router requires between eight and ten million instructions (including firmware), whereas a typical transport switch requires on average about three million instructions [MCK2002].
ソフトウェア/ファームウェアの複雑さの1つの尺度は、デバイスをプログラムするのに必要な命令の数です。典型的なトランスポート・スイッチ三百万の命令[MCK2002]について平均して必要一方、インターネットルータのための典型的なソフトウェア・イメージは、（ファームウェアを含む）百万8〜10の命令を必要とします。
This difference in software complexity has tended to make Internet routers unreliable, and has notable other second order effects (e.g., it may take a long time to reboot such a router). As another point of comparison, consider that the AT&T (Lucent) 5ESS class 5 switch, which has a huge number of calling features, requires only about twice the number of lines of code as an Internet core router [EICK].
ソフトウェアの複雑さのこの差は、インターネットルータが不安定にする傾向があり、注目すべき他の二次的な効果を持っていた（例えば、そのようなルータを再起動するのに長い時間がかかる場合があります）。比較の別の点として、コール機能の膨大な数を有するAT＆T（ルーセント）5ESSクラス5スイッチは、インターネットコアルータ[EICK]としてコードの行の約二倍の数を必要とすることを考えます。
Finally, since routers are as much or more software than hardware devices, another result of the code complexity is that the cost of routers benefits less from Moore's Law than less software-intensive devices. This causes a bandwidth/device trade-off that favors bandwidth more than less software-intensive devices.
ルータは、ハードウェア・デバイスよりも同じくらいか、それ以上のソフトウェアなので最後に、コードの複雑さの別の結果は、ルーターのコストが少なくムーアの法則から以下のソフトウェア集約型デバイスよりも利益をもたらすということです。これは、より少ないソフトウェア集約型デバイスよりも多くの帯域幅を優先する帯域幅/デバイスのトレードオフが発生します。
An Internet router's line card must perform many complex operations, including processing the packet header, longest prefix match, generating ICMP error messages, processing IP header options, and buffering the packet so that TCP congestion control will be effective (this typically requires a buffer of size proportional to the line rate times the RTT, so a buffer will hold around 250 ms of packet data). This doesn't include route and packet filtering, or any QoS or VPN filtering.
インターネットルータのラインカードは（これは通常のバッファを必要とするパケットヘッダを処理し、最長プレフィックス一致、ICMPエラーメッセージを生成し、IPヘッダオプションの処理、およびTCPの輻輳制御が有効になるようにパケットをバッファリングなど、多くの複雑な操作を実行しなければなりませんラインレート時間RTTに比例する大きさなので、バッファ）は、パケットデータの約250ミリ秒を保持します。これは、ルートおよびパケットフィルタリング、または任意のQoSやVPNのフィルタリングが含まれていません。
On the other hand, a transport switch need only to map ingress time-slots to egress time-slots and interfaces, and therefore can be considerably less complex.
一方、トランスポートスイッチは、出力タイムスロットとのインターフェイスに入力タイムスロットにマッピングする必要があり、したがって、かなりより複雑であることができます。
One measure of hardware complexity is the number of logic gates on a line card [MOLINERO2002]. Consider the case of a high-speed Internet router line card: An OC192 POS router line card contains at least 30 million gates in ASICs, at least one CPU, 300 Mbytes of packet buffers, 2 Mbytes of forwarding table, and 10 Mbytes of other state memory. On the other hand, a comparable transport switch line card has 7.5 million logic gates, no CPU, no packet buffer, no forwarding table, and an on-chip state memory. Rather, the line-card of an electronic transport switch typically contains a SONET framer, a chip to map ingress time-slots to egress time-slots, and an interface to the switch fabric.
ハードウェアの複雑さの1つの尺度は、[MOLINERO2002】ライン・カード上の論理ゲートの数です。 OC192のPOSルータラインカードは、ASICの中に、少なくとも30万のゲート、少なくとも1つのCPU、パケットバッファ300バイト、転送テーブルの2バイト、及び他の10のバイトが含まれています。高速インターネットルータラインカードの場合を考えますステート・メモリ。一方、比較可能なトランスポートスイッチのラインカードは、750万個の論理ゲート、無CPU、無パケットバッファなし転送テーブル、およびオンチップ状態メモリを有します。むしろ、電子輸送スイッチのラインカードは、典型的には、SONETフレーマ、出力タイムスロットに入力タイムスロットをマッピングするチップ、およびスイッチ・ファブリックへのインターフェースを含んでいます。
Since transport switches have traditionally been built from simpler hardware components, they also consume less power [PMC].
トランスポートスイッチは、従来より単純なハードウェア構成要素から構築されているので、彼らはまた、[PMC]少ない電力を消費します。
The highest capacity transport switches have about four times the capacity of an IP router [CISCO,CIENA], and sell for about one-third as much per Gigabit/sec. Optical (OOO) technology pushes this complexity difference further (e.g., tunable lasers, MEMs switches. e.g., [CALIENT]), and DWDM multiplexers provide technology to build extremely high capacity, low power transport switches.
最大容量のトランスポート・スイッチは、IPルータ[CISCO、CIENA]の約4倍の容量を持ち、ギガビット/秒あたり限りおよそ三分の一のために販売しています。光（OOO）技術（例えば、波長可変レーザ、MEMSスイッチ。例えば、[CALIENT]）さらに、この複雑さの差を押し、そしてDWDMマルチプレクサ極めて高容量、低電力トランスポートスイッチを構築する技術を提供します。
A related metric is physical footprint. In general, by virtue of their higher density, transport switches have a smaller "per-gigabit" physical footprint.
関連するメトリックは、物理的な設置面積です。一般的に、それらのより高い密度によって、トランスポートスイッチはより小さい「当たりギガビット」物理的設置面積を有します。
Packet switching would seem to have high variable cost, meaning that it costs more to send the n-th piece of information using packet switching than it might in a circuit switched network. Much of this advantage is due to the relatively static nature of circuit switching, e.g., circuit switching can take advantage of of pre-scheduled arrival of information to eliminate operations to be performed on incoming information. For example, in the circuit switched case, there is no need to buffer incoming information, perform loop detection, resolve next hops, modify fields in the packet header, and the like. Finally, many circuit switched networks combine relatively static configuration with out-of-band control planes (e.g., SS7), which greatly simplifies data-plane switching. The bottom line is that as data rates get large, it becomes more and more complex to switch packets, while circuit switching scales more or less linearly.
パケット交換は、回路内のネットワークを切り替えるかもしれないよりパケット交換を使用して情報のn番目の部分を送信するために、よりコストことを意味し、高い変動費を持っているように思われます。この利点の多くは回線交換の比較的静的な性質に起因する、例えば、回線交換は、入力情報に対して実行される操作を排除する情報の事前到着予定のを利用することができます。回路ケースを切り替えるに、例えば、入ってくる情報をバッファループ検出を実行し、次のホップを解決するため、パケットのヘッダ内のフィールドを変更する必要などがありません。最後に、多くの回路は、ネットワークが大幅データプレーンスイッチングを簡素化するアウトオブバンド制御プレーン（例えば、SS7）、比較的静的な設定を組み合わせる切り替えます。一番下の行は、データレートが大きいにつれ回路は、多かれ少なかれ直線的にスケールを切り替えながら、それは、パケットをスイッチングするために、ますます複雑になることです。
While the components of a complete solution for Internet QoS, including call admission control, efficient packet classification, and scheduling algorithms, have been the subject of extensive research and standardization for more than 10 years, end-to-end signaled QoS for the Internet has not become a reality. Alternatively, QoS has been part of the circuit switched infrastructure almost from its inception. On the other hand, QoS is usually deployed to determine queuing disciplines to be used when there is insufficient bandwidth to support traffic. But unlike voice traffic, packet drop or severe delay may have a much more serious effect on TCP traffic due to its congestion-aware feedback loop (in particular, TCP backoff/slow start).
コールアドミッション制御、効率的なパケット分類、およびスケジューリングアルゴリズムを含む、インターネットのQoSのための完全なソリューションのコンポーネントは、10年以上のための広範な研究と標準化の対象となっているが、インターネットを持っているため、エンド・ツー・エンドのQoSを合図現実のものとなっていません。また、QoSは、回路の一部がその発端からほとんどのインフラを切り替えられました。一方、QoSは、通常のトラフィックをサポートするための十分な帯域幅があるときに使用されるように規律をキューイング決定するために配備されています。しかし、音声トラフィックとは異なり、パケットドロップまたは重度の遅延は、その混雑対応のフィードバック・ループ（特に、TCPのバックオフ/スロースタート）へのTCPトラフィックにはるかに深刻な影響を有することができます。
A somewhat harder to quantify metric is the inherent flexibility of the Internet. While the Internet's flexibility has led to its rapid growth, this flexibility comes with a relatively high cost at the edge: the need for highly trained support personnel. A standard rule of thumb is that in an enterprise setting, a single support person suffices to provide telephone service for a group, while you need ten computer networking experts to serve the networking requirements of the same group [ODLYZKO98A]. This phenomenon is also described in [PERROW].
やや困難メトリック定量化するためには、インターネットの固有の柔軟性です。高度な訓練を受けたサポート担当者のための必要性：インターネットの柔軟性は、その急速な成長につながっているが、この柔軟性はエッジで比較的高いコストが付属しています。親指の標準ルールは同じグループ[ODLYZKO98A]のネットワーキングの要件を提供するために10人のコンピュータネットワークの専門家を必要としながら、企業の設定では、単一の支持者は、グループの電話サービスを提供するのに十分であることです。この現象は、[PERROW]に記載されています。
The relative computational complexity of circuit switching as compared to packet switching has been difficult to describe in formal terms [PARK]. As such, the sections above seek to describe the complexity in terms of observable artifacts. With this in mind, it is clear that the fundamental driver producing the increased complexities outlined above is the hop-by-hop independence (HBHI) inherent in the IP architecture. This is in contrast to the end to end architectures such as ATM or Frame Relay.
パケット交換と比較して回線交換の相対的な計算の複雑さは、正式な用語[PARK]で記述することは困難でした。このように、上記のセクションでは、観察可能なアーティファクトの点で複雑さを説明しよう。これを念頭において、上記の概説増加の複雑さを生成する基本的なドライバは、IPアーキテクチャに固有のホップバイホップの独立（HBHI）があることは明らかです。これは、ATMのようなアーキテクチャを終了またはフレームリレーする端とは対照的です。
[WILLINGER2002] describes this phenomenon in terms of the robustness requirement of the original Internet design, and how this requirement has the driven complexity of the network. In particular, they describe a "complexity/robustness" spiral, in which increases in complexity create further and more serious sensitivities, which then requires additional robustness (hence the spiral).
[WILLINGER2002]オリジナルのインターネット設計の堅牢性要件の面で、この現象を説明し、どのようにこの要件はネットワークの駆動複雑さを持っています。特に、それらは追加の堅牢性を必要とさらにより深刻な感度、（したがってスパイラル）を作成複雑に増大した「複雑性/堅牢性」スパイラルを、記載されています。
The important lesson of this section is that the Simplicity Principle, while applicable to circuit switching as well as packet switching, is crucial in controlling the complexity (and hence OPEX and CAPEX properties) of packet networks. This idea is reinforced by the observation that while packet switching is a younger, less mature discipline than circuit switching, the trend in packet switches is toward more complex line cards, while the complexity of circuit switches appears to be scaling linearly with line rates and aggregate capacity.
このセクションの重要な教訓は、簡単原理は、回線交換に適用可能なだけでなく、パケット切り替えながら、パケットネットワークの（したがっておよびOPEXとCAPEX特性）の複雑さを制御するのに重要であるということです。このアイデアは、パケット交換が回線交換よりも若い、成熟度の低い規律ある一方で、回路のスイッチの複雑さは、ラインレートと骨材と直線的にスケーリングされるように見えるが、パケット・スイッチの傾向は、より複雑なラインカードに向かっているという観察によって補強されています容量。
As a result of HBHI, we need to approach IP networks in a fundamentally different way than we do circuit based networks. In particular, the major OPEX challenge faced by the IP network is that debugging of a large-scale IP network still requires a large degree of expertise and understanding, again due to the hop-by-hop independence inherent in a packet architecture (again, note that this hop-by-hop independence is not present in virtual circuit networks such as ATM or Frame Relay). For example, you may have to visit a large set of your routers only to discover that the problem is external to your own network. Further, the debugging tools used to diagnose problems are also complex and somewhat primitive. Finally, IP has to deal with people having problems with their DNS or their mail or news or some new application, whereas this is usually not the case for TDM/ATM/etc. In the case of IP, this can be eased by improving automation (note that much of what we mention is customer facing). In general, there are many variables external to the network that effect OPEX.
HBHIの結果として、我々は回路ベースのネットワークを行うよりも、根本的に異なる方法で、IPネットワークにアプローチする必要があります。具体的には、IPネットワークが直面する主要なOPEXの課題は、大規模IPネットワークのデバッグはまだ、再び（再びによるパケットのアーキテクチャに固有のホップバイホップ独立に、専門知識や理解の程度が大きい必要とされますこのホップバイホップの独立は、ATMやフレームリレー）などの仮想回線ネットワーク内に存在しないことに注意してください。たとえば、あなたが唯一の問題は、独自のネットワークの外部にあることを発見するためにあなたのルーターの大規模なセットを訪問する必要があります。さらに、問題を診断するために使用するデバッグツールは、複雑な、やや原始的です。これは通常、TDM / ATMの/ etcには当てはまらないのに対し、最後に、IPは、そのDNSまたは、メールやニュースやいくつかの新しいアプリケーションで問題が発生した人々に対処しなければなりません。 IPの場合、これは（私たちが言及するものの多くは、顧客の直面していることに注意してください）自動化を向上させることによって緩和することができます。一般的には、その旨のOPEXネットワークの外部に多くの変数があります。
Finally, it is important to note that the quantitative relationship between CAPEX, OPEX, and a network's inherent complexity is not well understood. In fact, there are no agreed upon and quantitative metrics for describing a network's complexity, so a precise relationship between CAPEX, OPEX, and complexity remains elusive.
最後に、CAPEX、OPEX、およびネットワークの固有の複雑さとの量的関係はよく理解されていないことに注意することが重要です。実際には、ネットワークの複雑さを記述するためのいかなる合意したとの定量的指標が存在しないので、CAPEX、OPEXの間の正確な関係、および複雑さは、とらえどころのないまま。
As noted in [MC2001] and elsewhere, much of the complexity we observe in today's Internet is directed at increasing bandwidth utilization. As a result, the desire of network engineers to keep network utilization below 50% has been termed "over-provisioning". However, this use of the term over-provisioning is a misnomer. Rather, in modern Internet backbones the unused capacity is actually protection capacity. In particular, one might view this as "1:1 protection at the IP layer". Viewed in this way, we see that an IP network provisioned to run at 50% utilization is no more over-provisioned than the typical SONET network. However, the important advantages that accrue to an IP network provisioned in this way include close to speed of light delay and close to zero packet loss [FRALEIGH]. These benefits can been seen as a "side-effect" of 1:1 protection provisioning.
[MC2001]にし、他の場所で述べたように、我々は今日のインターネットで観察する複雑の多くは帯域幅の利用を増やすことに向けられています。その結果、50％以下のネットワーク使用率を維持するためのネットワークエンジニアの願望は「オーバープロビジョニング」と呼ばれています。しかし、オーバープロビジョニング用語のこの使用は誤称です。むしろ、現代のインターネットのバックボーン内の未使用容量は、実際に保護容量です。 「：IP層での1保護1」特に、1は、としてこれを見るかもしれません。このように見ると、私たちは、IPネットワークが50％の利用率で実行するようにプロビジョニングされたことがわかり、それ以上にプロビジョニング上、典型的なSONETネットワーク以外ではありません。しかしながら、このようにプロビジョニングされたIPネットワークに計上重要な利点は、光遅延の速度に近く、ゼロパケット損失[FRALEIGH]に近い含みます。 1つの保護プロビジョニング：これらの利点は、1の「副作用」として見られてすることができます。
There are also other, system-theoretic reasons for providing 1:1-like protection provisioning. Most notable among these reasons is that packet-switched networks with in-band control loops can become unstable and can experience oscillations and synchronization when congested. Complex and non-linear dynamic interaction of traffic means that congestion in one part of the network will spread to other parts of the network. When routing protocol packets are lost due to congestion or route-processor overload, it causes inconsistent routing state, and this may result in traffic loops, black holes, and lost connectivity. Thus, while statistical multiplexing can in theory yield higher network utilization, in practice, to maintain consistent performance and a reasonably stable network, the dynamics of the Internet backbones favor 1:1 provisioning and its side effects to keep the network stable and delay low.
1のような保護のプロビジョニング：1を提供するための他、システム論的な理由もあります。これらの理由の中で最も注目すべきは、帯域内制御ループとパケット交換ネットワークが不安定になることができ、混雑時に振動や同期を体験することができるということです。トラフィックのコンプレックスと非線形動的相互作用は、ネットワークの一部で輻輳がネットワークの他の部分に広がっていくことを意味します。ルーティングプロトコルパケットが輻輳又はルートプロセッサ過負荷のために失われている場合には、一貫性のないルーティング状態を引き起こし、これはトラフィックループをもたらすことができる、ブラックホール、および接続性を失いました。安定したネットワークを維持し、低遅延させるために1プロビジョニングとその副作用：統計的多重化は理論的には高いネットワーク使用率を得ることができるつつ、実際には、安定した性能と合理的に安定したネットワークを維持するために、インターネットのバックボーンのダイナミクスは、1を好みます。
Paul Baran, in his classic paper, "SOME PERSPECTIVES ON NETWORKS-- PAST, PRESENT AND FUTURE", stated that "The tradeoff curves between cost and system reliability suggest that the most reliable systems might be built of relatively unreliable and hence low cost elements, if it is system reliability at the lowest overall system cost that is at issue" [BARAN77].
ポール・バランは、彼の古典的な論文、「NETWORKS--過去、現在、未来にいくつかの展望」で、コストとシステムの信頼性との間のトレードオフ曲線は、最も信頼性の高いシステムでは、比較的信頼性が低いので、低コストの要素で構築されるかもしれないことを示唆している」と述べました、それは問題である最低の全体的なシステム・コスト」[BARAN77]でシステムの信頼性である場合。
Today we refer to this phenomenon as "the myth of five nines". Specifically, so-called five nines reliability in packet network elements is consider a myth for the following reasons: First, since 80% of unscheduled outages are caused by people or process errors [SCOTT], there is only a 20% window in which to optimize. Thus, in order to increase component reliability, we add complexity (optimization frequently leads to complexity), which is the root cause of 80% of the unplanned outages. This effectively narrows the 20% window (i.e., you increase the likelihood of people and process failure). This phenomenon is also characterized as a "complexity/robustness" spiral [WILLINGER2002], in which increases in complexity create further and more serious sensitivities, which then requires additional robustness, and so on (hence the spiral).
今日は「5つのナインの神話」として、この現象を参照してください。パケットネットワーク要素において具体的には、いわゆるファイブナインの信頼性以下の理由神話を検討されている：第一に、予定外の停止の80％が人またはプロセスエラーによって引き起こされているので[SCOTT]の中のわずか20％のウィンドウが存在します最適化します。このように、部品の信頼性を高めるために、我々は、計画外の停止の80％の根本的な原因である、（最適化は頻繁に複雑につながる）の複雑さを追加します。これは効果的に20％のウィンドウを（つまり、あなたが人とプロセス障害の可能性を増加させる）狭めます。この現象はまた作成し、これに付加的な堅牢性を必要とし、より深刻な感度、（従って螺旋）複雑に増大する「複雑さ/ロバスト性」スパイラル[WILLINGER2002]、として特徴付けられます。
The conclusion, then is that while a system like the Internet can reach five-nines-like reliability, it is undesirable (and likely impossible) to try to make any individual component, especially the most complex ones, reach that reliability standard.
結論は、その後、インターネットのようなシステムは5ナインのような信頼性を達することができますが、それは任意の個々のコンポーネント、特に最も複雑なものは、その信頼性の標準に到達作ってみることは望ましくない（そしておそらく不可能）であるということです。
As noted in the previous section, the computational complexity of packet switched networks such as the Internet has proven difficult to describe in formal terms. However, an intuitive, high level definition of architectural complexity might be that the complexity of an architecture is proportional to its number of components, and that the probability of achieving a stable implementation of an architecture is inversely proportional to its number of components. As described above, components include discrete elements such as hardware elements, space and power requirements, as well as software, firmware, and the protocols they implement.
前節で述べたように、パケットの計算の複雑さは、インターネットなどのネットワークは正式な用語で記述することは困難であることが分かっている切り替えます。しかし、アーキテクチャの複雑さを直感的に、高レベルの定義は、アーキテクチャの複雑さ、部品のその数に比例していること、およびアーキテクチャの安定した実装を達成する確率は、コンポーネントのその数に反比例することかもしれません。上述したように、コンポーネントは、ハードウェア要素、空間および電力の要件、ならびにソフトウェア、ファームウェア、及びそれらが実装プロトコルなどの離散要素を含みます。
Stated more abstractly:
もっと抽象的に次のように述べました。
Let
してみましょう
A be a representation of architecture A,
アーキテクチャAの表現で、
|A| be number of distinct components in the service delivery path of architecture A,
| A |アーキテクチャAのサービス配信経路に別個の構成要素の数です、
w be a monotonically increasing function,
wは、単調増加関数であります
P be the probability of a stable implementation of an architecture, and let
Pは、アーキテクチャの安定した実装の確率があること、そしてみましょう
Then
それから
Complexity(A) = O(w(|A|)) P(A) = O(1/w(|A|))
複雑さ（A）= O（W（| A |））P（A）= O（1 / W（| A |））
where
どこ
O(f) = {g:N->R | there exists c > 0 and n such that g(n) < c*f(n)}
O（F）= {G：N-> R | C> 0およびnようにG（N）<C *とのF（N）}は存在します
[That is, O(f) comprises the set of functions g for which there exists a constant c and a number n, such that g(n) is smaller or equal to c*f(n) for all n. That is, O(f) is the set of all functions that do not grow faster than f, disregarding constant factors]
[すなわち、O（f）は、G（n）が小さいかまたは全てのnのC *のF（N）と等しくなるように定数cと数nを、そこに存在するための関数gのセットを含みます。これは、O（f）が一定の要因を無視し、fより速く成長していないすべての関数の集合である、です]
Interestingly, the Highly Optimized Tolerance (HOT) model [HOT] attempts to characterize complexity in general terms (HOT is one recent attempt to develop a general framework for the study of complexity, and is a member of a family of abstractions generally termed "the new science of complexity" or "complex adaptive systems"). Tolerance, in HOT semantics, means that "robustness in complex systems is a constrained and limited quantity that must be carefully managed and protected." One focus of the HOT model is to characterize heavy-tailed distributions such as Complexity(A) in the above example (other examples include forest fires, power outages, and Internet traffic distributions). In particular, Complexity(A) attempts to map the extreme heterogeneity of the parts of the system (Internet), and the effect of their organization into highly structured networks, with hierarchies and multiple scales.
興味深いことに、高度に最適化された許容値（HOT）モデル[HOT]は一般的に複雑さを特徴づけるためにしようとする（HOTは、複雑さの研究のための一般的なフレームワークを開発する一つの最近の試みであり、かつ抽象化のファミリーのメンバーである、一般的に「と呼ばれます複雑さの新しい科学」や 『複雑適応システム』）。公差は、HOT意味論で、「複雑なシステムでの堅牢性を慎重に管理し、保護しなければならない制約があり、限られた量である。」ということを意味しますHOTモデルの一つの焦点は、（他の例としては、森林火災、停電、およびインターネットトラフィック分布を含む）上記の例では、このような複雑さ（A）のようなヘビーテイル分布を特徴付けることです。特に、複雑（A）は、階層および複数のスケールで、高度に構造化ネットワーク内のシステム（インターネット）の部分の極端な不均一性、及びその組織の影響をマッピングすることを試みます。
The Architectural Component Proportionality Law (ACPL) states that the complexity of an architecture is proportional to its number of components.
アーキテクチャコンポーネント比例性法（ACPL）は、アーキテクチャの複雑さ、部品のその数に比例することを述べています。
COROLLARY: Minimize the number of components in a service delivery path, where the service delivery path can be a protocol path, a software path, or a physical path.
结果：サービス配信パスは、プロトコル経路、ソフトウェア・パス、または物理的なパスであることができるサービス配信経路内のコンポーネントの数を最小限に抑えます。
This corollary is an important consequence of the ACPL, as the path between a customer and the desired service is particularly sensitive to the number and complexity of elements in the path. This is due to the fact that the complexity "smoothing" that we find at high levels of aggregation [ZHANG] is missing as you move closer to the edge, as well as having complex interactions with backoffice and CRM systems. Examples of architectures that haven't found a market due to this effect include TINA-based CRM systems, CORBA/TINA based service architectures. The basic lesson here was that the only possibilities for deploying these systems were "Limited scale deployments (such) as in Starvision can avoid coping with major unproven scalability issues", or "Otherwise need massive investments (like the carrier-grade ORB built almost from scratch)" [TINA]. In other words, these systems had complex service delivery paths, and were too complex to be feasibly deployed.
顧客と所望のサービス間のパスは、パス内の要素の数と複雑さに特に敏感であるように、この推論は、ACPLの重要な結果です。これは、私たちが凝集の高いレベルで見つける複雑さ「平滑化」[ZHANG]はあなたが近いエッジに移動するよう欠落しているだけでなく、バックオフィスやCRMシステムとの複雑な相互作用をしているという事実によるものです。これによる効果に市場を発見していないアーキテクチャの例としては、TINAベースのCRMシステム、CORBA / TINAベースのサービス・アーキテクチャが含まれます。ここでの基本的な教訓は、これらのシステムを展開するための唯一の可能性はなかった「（など）リミテッド規模な展開Starvisionのような主要な証明されていない拡張性の問題に対処避けることができる」、または「それ以外のほとんどから構築されたキャリアグレードのORBのような大規模な投資を（必要ということでしたスクラッチ）」[TINA]。言い換えれば、これらのシステムは、複雑なサービス・デリバリー・パスを持っていて、実行可能に展開されるにはあまりにも複雑でした。
This document attempts to codify long-understood Internet architectural principles. In particular, the unifying principle described here is best expressed by the Simplicity Principle, which states complexity must be controlled if one hopes to efficiently scale a complex object. The idea that simplicity itself can lead to some form of optimality has been a common theme throughout history, and has been stated in many other ways and along many dimensions. For example, consider the maxim known as Occam's Razor, which was formulated by the medieval English philosopher and Franciscan monk William of Ockham (ca. 1285-1349), and states "Pluralitas non est ponenda sine neccesitate" or "plurality should not be posited without necessity." (hence Occam's Razor is sometimes called "the principle of unnecessary plurality" and " the principle of simplicity"). A perhaps more contemporary formulation of Occam's Razor states that the simplest explanation for a phenomenon is the one preferred by nature. Other formulations of the same idea can be found in the KISS (Keep It Simple Stupid) principle and the Principle of Least Astonishment (the assertion that the most usable system is the one that least often leaves users astonished). [WILLINGER2002] provides a more theoretical discussion of "robustness through simplicity", and in discussing the PSTN, [KUHN87] states that in most systems, "a trade-off can be made between simplicity of interactions and looseness of coupling".
この文書では、長時間理解インターネットアーキテクチャの原則を体系化しようとします。特に、ここで説明する統一原理は最良のものが効率的に複雑なオブジェクトを拡張したいと考えているならば、複雑に制御しなければならないと述べ単純化原則、で表されます。シンプルそのものは最適のいくつかのフォームにつながることができないという考えは、歴史を通して共通のテーマとなっている、と他の多くの方法で、多くの次元に沿って述べられています。例えば、オッカム（約1285年から1349年）の中世英語の哲学者フランシスコ修道士ウィリアムによって策定されたオッカムの剃刀として知られている格言を考えると、述べて「Pluralitas非EST ponenda正弦neccesitate」または「複数の仮定すべきではありません必要なし。」 （したがって、オッカムの剃刀は時々、「不必要な複数の原則」と「シンプルさの原則」と呼ばれています）。オッカムの剃刀のおそらくより現代的な製剤は、現象のための最も簡単な説明は、本質的に好ま1であると述べています。同じ考えの他の製剤は、KISS（愚かなそれをシンプルに保つ）原理と驚き最小の原則（ほとんど使用可能なシステムは、少なくとも頻繁に驚いユーザーの葉1であることを主張）に記載されています。 【WILLINGER2002「単純を通じて堅牢」のより理論的な議論を提供し、PSTNを議論において、[KUHN87]ほとんどのシステムでは、「トレードオフが相互作用および結合の弛みを簡単に間することができる」と述べています。
When applied to packet switched network architectures, the Simplicity Principle has implications that some may consider heresy, e.g., that highly converged approaches are likely to be less efficient than "less converged" solutions. Otherwise stated, the "optimal" convergence layer may be much lower in the protocol stack that is conventionally believed. In addition, the analysis above leads to several conclusions that are contrary to the conventional wisdom surrounding packet networking. Perhaps most significant is the belief that packet switching is simpler than circuit switching. This belief has lead to conclusions such as "since packet is simpler than circuit, it must cost less to operate". This study finds to the contrary. In particular, by examining the metrics described above, we find that packet switching is more complex than circuit switching. Interestingly, this conclusion is borne out by the fact that normalized OPEX for data networks is typically significantly greater than for voice networks [ML2002].
ネットワークアーキテクチャは、パケットに切り替え適用した場合、単純化原則は非常に収束手法は「あまり収束」ソリューションよりも効率的である可能性が高いこと、例えばいくつかは異端考慮することができる意味を有します。別段の記載が、「最適な」収束層は、従来考えられているプロトコル・スタック内のはるかに低くてもよいです。また、分析は、上記のパケットネットワークを取り巻く社会通念に反している、いくつかの結論につながります。おそらく最も重要なのは、パケット交換が回線交換よりも簡単であるという信念です。この信念は、そのような「パケットが回路よりも簡単であることから、動作するために以下の費用がしなければならない」との結論につながりました。この研究は、逆に見つけました。特に、上記の指標を調べることによって、我々はパケット交換が回線交換よりも複雑であることがわかります。興味深いことに、この結論は、データネットワークのための正規化されたOPEXは、典型的には、音声ネットワーク[ML2002]よりも有意に大きいという事実によって裏付けされています。
Finally, the important conclusion of this work is that for packet networks that are of the scale of today's Internet or larger, we must strive for the simplest possible solutions if we hope to build cost effective infrastructures. This idea is eloquently stated in [DOYLE2002]: "The evolution of protocols can lead to a robustness/complexity/fragility spiral where complexity added for robustness also adds new fragilities, which in turn leads to new and thus spiraling complexities". This is exactly the phenomenon that the Simplicity Principle is designed to avoid.
最後に、この作品の重要な結論は、我々は費用対効果の高いインフラを構築することを願っていた場合、今日のインターネット以上の規模であるパケットネットワークのために、我々はできるだけ簡単な解決のために努力しなければならないということです。 「複雑さも順番に新しいので、スパイラル複雑につながる新しいもろさを、追加堅牢性のために追加堅牢性/複雑さ/脆弱スパイラルにつながる可能なプロトコルの進化」：このアイデアは雄弁[DOYLE2002]に記載されています。これはまさに単純化原則を回避するように設計された現象です。
This document does not directly effect the security of any existing Internet protocol. However, adherence to the Simplicity Principle does have a direct affect on our ability to implement secure systems. In particular, a system's complexity grows, it becomes more difficult to model and analyze, and hence it becomes more difficult to find and understand the security implications inherent in its architecture, design, and implementation.
このドキュメントは、直接、既存のインターネットプロトコルのセキュリティには影響しません。しかし、単純化原則の遵守は、安全なシステムを実現する当社の能力に影響を与えるダイレクトを持っています。具体的には、システムの複雑さが成長し、それがモデル化し分析することがより困難になり、ひいてはそれが見つけるとそのアーキテクチャ、設計、実装に固有のセキュリティへの影響を理解することがより困難になります。
Many of the ideas for comparing the complexity of circuit switched and packet switched networks were inspired by conversations with Nick McKeown. Scott Bradner, David Banister, Steve Bellovin, Steward Bryant, Christophe Diot, Susan Harris, Ananth Nagarajan, Andrew Odlyzko, Pete and Natalie Whiting, and Lixia Zhang made many helpful comments on early drafts of this document.
回路の複雑さを比較するためのアイデアの多くは、交換及びパケットは、ネットワークはニック・マッケオンとの会話に触発されたスイッチ。スコット・ブラッドナー、デビッド・バニスター、スティーブBellovin氏、スチュワードブライアント、クリストフDiot、スーザン・ハリス、Ananth Nagarajan、アンドリュー・オッドリツコ、ピートとナタリーホワイティング、およびLixiaチャンは、このドキュメントの初期の草稿には、多くの有益なコメントをしました。
[AHUJA] "The Impact of Internet Policy and Topology on Delayed Routing Convergence", Labovitz, et. al. Infocom, 2001.
ら、Labovitz、[アフジャ]「遅延ルーティングコンバージェンスのインターネットポリシーおよびトポロジの影響」。アル。インフォコム、2001。
[ATMMPLS] "ATM-MPLS Interworking Migration Complexities Issues and Preliminary Assessment", School of Interdisciplinary Computing and Engineering, University of Missouri-Kansas City, April 2002
[ATMMPLS]「ATMMPLSインターワーキング移行の複雑さの問題と予備的評価」、学際コンピューティングと工学部、ミズーリ州、カンザスシティ、2002年4月の大学
[BARAN] "On Distributed Communications", Paul Baran, Rand Corporation Memorandum RM-3420-PR, http://www.rand.org/publications/RM/RM3420", August, 1964.
[BARAN] "上の分散コミュニケーションズ"、ポール・バラン、ランド研究所覚書RM-3420-PR、http://www.rand.org/publications/RM/RM3420" 、8月、1964。
[BARAN77] "SOME PERSPECTIVES ON NETWORKS--PAST, PRESENT AND FUTURE", Paul Baran, Information Processing 77, North-Holland Publishing Company, 1977,
[BARAN77]「ネットワーク上SOME展望 - 過去、現在、未来」、ポール・バラン、情報処理77、北オランダ出版社、1977年、
[BRYANT] "Protocol Layering in PWE3", Bryant et al, Work in Progress.
[BRYANT「PWE3におけるプロトコルレイヤリング」、ブライアントら、進行中で働いています。
[CAIDA] http://www.caida.org
[DROP] http://www.caida.org
[CALLIENT] http://www.calient.net/home.html
【CALLIENT] http://www.calient.net/home.html
[CARLSON] "Complexity and Robustness", J.M. Carlson and John Doyle, Proc. Natl. Acad. Sci. USA, Vol. 99, Suppl. 1, 2538-2545, February 19, 2002. http://www.pnas.org/cgi/doi/10.1073/pnas.012582499
[CARLSON] "複雑性と堅牢性"、J.M.カールソンとジョン・ドイル、PROC。ナショナル・。 ACAD。 SCI。 USA、巻。 99、補遺。 1、2538年から2545年、2月19日、2002年http://www.pnas.org/cgi/doi/10.1073/pnas.012582499
[CIENA] "CIENA Multiwave CoreDiretor", http://www.ciena.com/downloads/products/ coredirector.pdf
[CIENA] "CIENAマルチウェーブCoreDiretor"、http://www.ciena.com/downloads/products/ coredirector.pdf
[CISCO] http://www.cisco.com
[CISCO] http://www.cisco.com
[CLARK] "The Design Philosophy of the DARPA Internet Protocols", D. Clark, Proc. of the ACM SIGCOMM, 1988.
[CLARK] "DARPAインターネットプロトコルの設計理念"、D.クラーク、PROC。 ACM SIGCOMM、1988年。
[COFFMAN] "Internet Growth: Is there a 'Moores Law' for Data Traffic", K.G. Coffman and A.M. Odlyzko, pp. 47-93, Handbook of Massive Data Stes, J. Elli, P. M. Pardalos, and M. G. C. Resende, Editors. Kluwer, 2002.
[コフマン]：、K.G.「インターネットの成長データトラフィックのための 『ムーア法』あり」コフマンと午前Odlyzko、頁47から93まで、大量のデータスイーツ、J.エリ、P. M. Pardalos、およびM. G. C.レゼンデ、編集者のハンドブック。 Kluwerの2002年。
[DOYLE2002] "Robustness and the Internet: Theoretical Foundations", John C. Doyle, et. al. Work in Progress.
[DOYLE2002]「堅牢性とインターネット：理論的基礎」、ジョン・C・ドイル、ら。アル。進行中の作業。
[EICK] "Visualizing Software Changes", S.G. Eick, et al, National Institute of Statistical Sciences, Technical Report 113, December 2000.
[EICK]「可視化ソフトウェアの変更」、S。G. Eick、ら、統計科学研究所、テクニカルレポート113、2000年12月。
[MOLINERO2002] "TCP Switching: Exposing Circuits to IP", Pablo Molinero-Fernandez and Nick McKeown, IEEE January, 2002.
[MOLINERO2002] "TCPスイッチング：IPへの回路の公開"、パブロMolineroに-フェルナンデスとニック・マッケオン、IEEE 2002年1月。
[FLOYD] "The Synchronization of Periodic Routing Messages", Sally Floyd and Van Jacobson, IEEE ACM Transactions on Networking, 1994.
[FLOYD]「周期的なルーティングメッセージの同期」、サリーフロイドとバン・ジェイコブソン、ネットワーキング、1994年にIEEE ACMトランザクション。
[FLOYD2001] "A Report on Some Recent Developments in TCP Congestion Control, IEEE Communications Magazine, S. Floyd, April 2001.
[FLOYD2001]「TCP輻輳制御におけるいくつかの最近の動向に関する報告書、IEEEコミュニケーションズマガジン、S.フロイド、2001年4月。
[FRALEIGH] "Provisioning IP Backbone Networks to Support Delay-Based Service Level Agreements", Chuck Fraleigh, Fouad Tobagi, and Christophe Diot, 2002.
[FRALEIGH]「遅延ベースのサービスレベル契約をサポートするためにプロビジョニングIPバックボーンネットワーク」、チャックFraleigh、のFouad Tobagi、およびクリストフDiot、2002。
[GRIFFIN] "What is the Sound of One Route Flapping", Timothy G. Griffin, IPAM Workshop on Large-Scale Communication Networks: Topology, Routing, Traffic, and Control, March, 2002.
トポロジ、ルーティング、トラフィック、およびコントロール、2002年3月：[GRIFFIN]、ティモシー・G.グリフィン、大規模通信ネットワーク上のIPAMワークショップ「ワンルートフラッピングの音は何ですか」。
[HANDLEY] "On Inter-layer Assumptions (A view from the Transport Area), slides from a presentation at the IAB workshop on Wireless Internetworking", M. Handley, March 2000.
[HANDLEY]、M.ハンドリー、2000年3月「インター層の仮定（トランスポートエリアからの眺め）には、ワイヤレス・インターネット上のIABワークショップでのプレゼンテーションからスライド」。
[HOT] J.M. Carlson and John Doyle, Phys. Rev. E 60, 1412- 1427, 1999.
[HOT] J.M.カールソンとジョン・ドイル、PHYS。牧師E 60、1412- 1427年、1999年。
[ISO10589] "Intermediate System to Intermediate System Intradomain Routing Exchange Protocol (IS-IS)".
「中間システムイントラドメインルーティング交換プロトコル（IS-IS）への中間システム」[ISO10589]。
[JACOBSON] "Congestion Avoidance and Control", Van Jacobson, Proceedings of ACM Sigcomm 1988, pp. 273-288.
【JACOBSON「輻輳回避と制御」、バン・ジェイコブソン、ACM SIGCOMMの会報1988、頁273から288。
[KARN] "TCP vs Link Layer Retransmission" in P. Karn et al., Advice for Internet Subnetwork Designers, Work in Progress.
[カーン] P.カーンら、インターネットサブネットワークデザイナー、進行中の作業のためのアドバイスで「リンクレイヤの再送対TCP」。
[KUHN87] "Sources of Failure in the Public Switched Telephone Network", D. Richard Kuhn, EEE Computer, Vol. 30, No. 4, April, 1997.
[KUHN87]、D.リチャード・クーン、EEEコンピュータ、巻「公共の場での失敗のソースは、交換電話網」。 30、第4号、1997年4月。
[L2TPV3] Lan, J., et. al., "Layer Two Tunneling Protocol (Version 3) -- L2TPv3", Work in Progress.
【L2TPV3】ラン、J.、ら。 。アル、「レイヤ2トンネリングプロトコル（バージョン3） - L2TPv3の」が進行中で働いています。
[MC2001] "U.S Communications Infrastructure at A Crossroads: Opportunities Amid the Gloom", McKinsey&Company for Goldman-Sachs, August 2001.
[MC2001]「A岐路に立つ米通信インフラ：暗がりのなか機会」ゴールドマン・サックス、2001年8月のため、マッキンゼー・アンド・カンパニー。
[MCK2002] Nick McKeown, personal communication, April, 2002.
[MCK2002]ニック・マッケオン、私信、2002年4月。
[ML2002] "Optical Systems", Merril Lynch Technical Report, April, 2002.
[ML2002] "光学システム"、メリルリンチ技術報告書、2002年4月。
[NAVE] "The influence of mode coupling on the non-linear evolution of tearing modes", M.F.F. Nave, et al, Eur. Phys. J. D 8, 287-297.
[NAVE]「モードを引き裂くの非線形進化上のモード結合の影響」、M.F.F.ネーブ、ら、Eur。 PHYS。 J. D 8、287-297。
[NEUMANN] "Cause of AT&T network failure", Peter G. Neumann, http://catless.ncl.ac.uk/Risks/9.62.html#subj2
[NEUMANN "AT＆Tのネットワーク障害の原因"、ピーターG.ノイマン、http://catless.ncl.ac.uk/Risks/9.62.html#subj2
[ODLYZKO] "Data networks are mostly empty for good reason", A.M. Odlyzko, IT Professional 1 (no. 2), pp. 67-69, Mar/Apr 1999.
[ODLYZKO]、午前「データ・ネットワークは、正当な理由のために、ほとんど空になっています」 Odlyzko、ITプロフェッショナル1（2番）、頁67-69、月/ 1999年4月。
[ODLYZKO98A] "Smart and stupid networks: Why the Internet is like Microsoft". A. M. Odlyzko, ACM Networker, 2(5), December, 1998.
[ODLYZKO98A]「スマートと愚かなネットワーク：インターネットは、Microsoftのようなものですなぜ」。 A. M. Odlyzko、ACM Networkerの、2（5）、1998年12月。
[ODLYZKO98] "The economics of the Internet: Utility, utilization, pricing, and Quality of Service", A.M. Odlyzko, July, 1998. http://www.dtc.umn.edu/~odlyzko/doc/networks.html
[ODLYZKO98]「インターネットの経済学：ユーティリティ、利用率、価格設定、およびサービスの品質」、A.M。 Odlyzko、7月、1998年http://www.dtc.umn.edu/~odlyzko/doc/networks.html
[PARK] "The Internet as a Complex System: Scaling, Complexity and Control", Kihong Park and Walter Willinger, AT&T Research, 2002.
[PARK] "複雑系としてのインターネット：スケーリング、複雑さと制御"、KihongパークとウォルターWillinger、AT＆T研究所、2002年。
[PERROW] "Normal Accidents: Living with High Risk Technologies", Basic Books, C. Perrow, New York, 1984.
[PERROW] "ノーマル事故：ハイリスク・テクノロジーズとともに生きる"、ベーシックブック、C. Perrow、ニューヨーク、1984年。
[PMC] "The Design of a 10 Gigabit Core Router Architecture", PMC-Sierra, http://www.pmc-sierra.com/products/diagrams/CoreRouter_lg.html
[PMC] "10ギガビットコアルータのアーキテクチャの設計"、PMC-Sierraの、http://www.pmc-sierra.com/products/diagrams/CoreRouter_lg.html
[RFC1629] Colella, R., Callon, R., Gardner, E. and Y. Rekhter, "Guidelines for OSI NSAP Allocation in the Internet", RFC 1629, May 1994.
[RFC1629] Colella、R.、Callon、R.、ガードナー、E.およびY. Rekhter、 "インターネットでのOSI NSAP配分のためのガイドライン"、RFC 1629、1994年5月。
[RFC1925] Callon, R., "The Twelve Networking Truths", RFC 1925, 1 April 1996.
[RFC1925] Callon、R.、 "十二・ネットワーキング真実"、RFC 1925、1996年4月1日。
[RFC1958] Carpenter, B., Ed., "Architectural principles of the Internet", RFC 1958, June 1996.
[RFC1958]大工、B.、エド。、 "インターネットの建築の原則"、RFC 1958、1996年6月。
[RFC2283] Bates, T., Chandra, R., Katz, D. and Y. Rekhter, "Multiprotocol Extensions for BGP4", RFC 2283, February 1998.
[RFC2283]ベイツ、T.、チャンドラ、R.、カッツ、D.およびY. Rekhter、 "BGP4のためのマルチプロトコル拡張機能"、RFC 2283、1998年2月。
[RFC3155] Dawkins, S., Montenegro, G., Kojo, M. and N. Vaidya, "End-to-end Performance Implications of Links with Errors", BCP 50, RFC 3155, May 2001.
[RFC3155]ドーキンス、S.、モンテネグロ、G.、古城、M.およびN. Vaidya、 "エラーとリンクのエンドツーエンドのパフォーマンスへの影響"、BCP 50、RFC 3155、2001年5月。
[ROMANOV] "Dynamics of TCP over ATM Networks", A. Romanov, S. Floyd, IEEE JSAC, vol. 13, No 4, pp.633-641, May 1995.
【ロマノフ "ATMネットワーク上のTCPのダイナミクス"、A.ロマノフ、S.フロイド、IEEE JSAC、巻。 13、ノー4、pp.633-641、1995年5月。
[SALTZER] "End-To-End Arguments in System Design", J.H. Saltzer, D.P. Reed, and D.D. Clark, ACM TOCS, Vol 2, Number 4, November 1984, pp 277-288.
、J.H. [SALTZER]「システム設計におけるエンドツーエンドの引数」 Saltzer、D.P.リード、およびD.D.クラーク、ACM TOCS、第2巻、ナンバー4、1984年11月、頁277-288。
[SCOTT] "Making Smart Investments to Reduce Unplanned Downtime", D. Scott, Tactical Guidelines, TG-07-4033, Gartner Group Research Note, March 1999.
[SCOTT]、D.スコット、戦術的なガイドライン、TG-07から4033まで、ガートナーグループの研究ノート、1999年3月「計画外のダウンタイムを削減するために、スマート投資を行います」。
[SPILLMAN] "The Law of Diminishing Returns:, W. J. Spillman and E. Lang, 1924.
[SPILLMAN]は「減少の法律は:, W. J. SpillmanとE.ラング、1924を返します。
[STALLINGS] "Data and Computer Communications (2nd Ed)", William Stallings, Maxwell Macmillan, 1989.
[ストーリングス]「データおよびコンピュータ・コミュニケーションズ（第2版）」、ウィリアム・ストーリングス、マックスウェルマクミラン、1989。
[TENNENHOUSE] "Layered multiplexing considered harmful", D. Tennenhouse, Proceedings of the IFIP Workshop on Protocols for High-Speed Networks, Rudin ed., North Holland Publishers, May 1989.
[TENNENHOUSE]高速ネットワークのためのプロトコルで、D. Tennenhouse、IFIPワークショップの議事録を「階層多重化が有害とみなさ」、ルーディン編、北オランダ出版社、1989年5月。
[THOMPSON] "Nonlinear Dynamics and Chaos". J.M.T. Thompson and H.B. Stewart, John Wiley and Sons, 1994, ISBN 0471909602.
[THOMPSON]「非線形力学とカオス」。 J.M.T.トンプソンとH.B.スチュワート、ジョン・ワイリー・アンド・サンズ、1994、ISBN 0471909602。
[TINA] "What is TINA and is it useful for the TelCos?", Paolo Coppo, Carlo A. Licciardi, CSELT, EURESCOM Participants in P847 (FT, IT, NT, TI)
[TINA] "TINAは何であり、それは通信会社のために有用です？"、P847でパオロ・コッポ、カルロ・A. Licciardi、CSELT、EURESCOM参加者（FT、IT、NT、TI）
[WAKEMAN] "Layering considered harmful", Ian Wakeman, Jon Crowcroft, Zheng Wang, and Dejan Sirovica, IEEE Network, January 1992, p. 7-16.
[WAKEMAN]はイアン・ウェイクマン、ジョンクロウクロフト、鄭王、およびデヤンSirovica、IEEEネットワーク、1992年1月、P、 "階層化は、有害とみなさ"。 7-16。
[WARD] "Custom fluorescent-nucleotide synthesis as an alternative method for nucleic acid labeling", Octavian Henegariu*, Patricia Bray-Ward and David C. Ward, Nature Biotech 18:345-348 (2000).
[WARD]「核酸標識する別の方法として、カスタム蛍光ヌクレオチド合成」、オクタヴィアンHenegariu *、パトリシア・ブレイ区とDavid C.ウォード、ネイチャーバイオテクノロジー18：345-348（2000）。
[WILLINGER2002] "Robustness and the Internet: Design and evolution", Walter Willinger and John Doyle, 2002.
[WILLINGER2002]「堅牢性とインターネット：設計と進化」、ウォルターWillingerとジョン・ドイル、2002。
[ZHANG] "Impact of Aggregation on Scaling Behavior of Internet Backbone Traffic", Sprint ATL Technical Report TR02-ATL-020157 Zhi-Li Zhang, Vinay Ribeiroj, Sue Moon, Christophe Diot, February, 2002.
[ZHANG] "インターネットバックボーントラフィックの挙動をスケーリングに集約の影響"、スプリントATLテクニカルレポートTR02-ATL-020157志李チャン、ビナイRibeiroj、スー・ムーン、クリストフDiot、2002年2月。
Randy Bush EMail: randy@psg.com
ランディブッシュEメール：randy@psg.com
David Meyer EMail: dmm@maoz.com
デビッド・マイヤー電子メール：dmm@maoz.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。