[要約] RFC 3439は、インターネットのアーキテクチャのガイドラインと哲学に関するものであり、要約すると以下のようになります。1. インターネットの設計原則としての柔軟性と拡張性の重要性を強調している。 2. インターネットのアーキテクチャにおけるモジュール性とレイヤー化の原則を提案している。 3. インターネットの進化と成長に対応するための指針となることを目的としている。
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.
Copyright（c）The Internet Society（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.
このドキュメントは、Internet Backboneネットワークのアーキテクトとデザイナーが従うべき哲学的ガイドラインのいくつかを概説することにより、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.
おそらくウーネットの元チーフアーキテクトであるマイクオデルによって最初に明確にされたシンプルさの原則は、複雑さが効率的なスケーリングを妨げる主要なメカニズムであり、その結果、両方の資本支出（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]）に記載されているエンドツーエンドの議論は、「エンドツーエンドのプロトコル設計は状態の維持に依存すべきではないと主張しています（すなわち、ネットワーク内のエンドツーエンド通信の状態。そのような状態は、エンドポイント自体が壊れたときにのみ状態を破壊できるように、エンドポイントでのみ維持されるべきです。」このプロパティは、クラークの「運命共有」コンセプト[クラーク]にも関連しています。エンドツーエンドの原則は、インターネットアーキテクチャのいわゆる「砂時計」の定式化を調べることにより、単純さの原則に直接つながることがわかります[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ネットワークを構築するための最も重要で挑戦的な障壁の1つです（そして引き続き）。たとえば、大規模なパケットネットワークを構築するタスクを検討してください。業界の経験は、このようなネットワークを構築することは、小規模から中規模のネットワークを構築するのとは異なるアクティビティである（したがって、異なるスキルセットを必要とする）ため、同じプロパティを持っていないことが示されています。特に、理論的および実際には、小規模では展示されていないアーキテクチャ、設計、およびエンジニアリングの非線形性の両方で、最大のネットワークが展示されています。このアーキテクチャ、デザイン、エンジニアリング（ADE）の非線形性と呼んでいます。つまり、インターネットなどのシステムは、非常に異なるスケールとレベルの抽象化を伴う非常に自己異なると説明できます[Carlson]。ADE非線形性プロパティは、非線形システム理論[トンプソン]からの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日（シノディック）サイクルなど、太陽系のダイナミクスを含む共鳴現象、または3655日間のサイクルの影響を受けます。太陽。
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ルーティングの収束がより複雑で、しばしば遅くなることが示されています[Ahuja]。関連する結果は、少量の相互接続性により、ルーティングメッシュの出力が入力よりも大幅に複雑になることです[Griffin]。増幅を減らすための重要な方法は、局所的な変化が局所的な効果のみを持つことを保証することです（これは、局所的な変化がグローバルな効果をもたらすシステムとは対照的です）。最後に、ATMは増幅効果の優れた例を提供します。1つのセルを失った場合、パケット全体を破壊します（そして、初期のパケット廃棄[Romanov]などのメカニズムがないため、さらに悪化します。すでに破損したパケット）。
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]
増幅のもう1つの興味深い例は、エンジニアリングドメインに由来し、[Carlson]に記載されています。彼らは、最大150,000のサブシステムと約1000のCPUを含む「フライバイワイヤ」航空機であるボーイング777を考えています。彼らが観察しているのは、777は大規模な大気の乱れ、乱流の境界、貨物負荷の変動（いくつかの名前のために）に堅牢であるが、非常に少数の大きなCPUでの顕微鏡の変化を壊滅的に無効にする可能性があるということです（ポイントとして微視的な変化を妨げる可能性があります。幸いなことに、これは非常にまれな出来事です）。この例は、「複雑さが小さな摂動を増幅することができ、設計エンジニアはそのような摂動が非常にまれであることを保証する必要があるという問題を示しています。[カールソン]
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].
結果：同時に発生するイベントが多いほど、2つ以上が相互作用する可能性が大きくなります。この現象は、「予期せぬ機能相互作用」とも呼ばれています[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.
カップリングは、プラズママクロインスティティリティ（水性磁気、たとえば、キンク、ファイアホース、ミラー、バルーン、涙、閉じ込められた粒子効果）、およびさまざまな種類のさまざまな種類など、さまざまな天然システムによって示されます。電気化学システム（カスタム蛍光ヌクレオチド合成/核酸標識問題[WARD]を考慮してください）。時計の物理的周期性の結合も観察されており[ヤコブソン]、さまざまな種類の生物学的サイクルの結合があります。
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スロースタート同期など、さまざまなコントロールループの同期が含まれます[Floyd、Jacobson]。これらの観察の重要な結果は、結合が同期に密接に関連していることです。これらのシステムにランダム性を注入することは、結合を減らす1つの方法です。
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）の危険因子を分析する際に、チャールズペローは2つの関連軸に沿って複雑さの問題を分解します。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年によく公表された停止などの停止は、現象を示しています。停止は、Switchesのクラッシュ回復コードのソフトウェアバグによって引き起こされました。この場合、ハードウェアのグリッチのために1つのスイッチがクラッシュしました。このスイッチが戻ってきたとき、それ（加えて合理的に可能性のあるタイミングイベント）により、隣接するスイッチが戻ってきたときに隣人がクラッシュし、隣人がクラッシュしました。見当違いの「ブレーク」ステートメント。これは、架橋結合の優れた例です）。この現象は、弱く結合した発振器の位相ロックに似ており、シーケンス時間のランダムな変動がシステムの安定性に重要な役割を果たします[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.
複雑なネットワークで新機能を提供するコストを検討してください。従来の音声ネットワークには、そのエッジデバイス（電話機器）にはほとんどインテリジェンスがあり、非常にスマートなコアがあります。インターネットには、スマートなエッジ、オペレーティングシステムを備えたコンピューター、アプリケーションなど、コントロールプレーンとパケット転送エンジンで構成されるシンプルなコアがあります。新しいインターネットサービスを追加することは、使用を希望するいくつかの同意のデスクトップにアプリケーションを配布することの問題です。これを音声にサービスを追加することと比較してください。音声では、コア全体をアップグレードする必要があります。
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 3方向握手、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]：「ブロードバンドネットワーキングへのATMアプローチは、現在、サービスをサポートするための統一メカニズムとしてCCITT（および他の場所）内で追求されています。ネットワークアーキテクチャの下層層内の統合、レート適応、およびジッター制御。このポジションペーパーは、最終システム内で動作する「中央」および「上部」層の設計とマルチのリレーから生じるジッターに特に関係しています。 - サービスネットワーク（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.
最適化の重要かつ関連する効果は、収益の減少の法則によって説明されています。これは、生産の1つの要因が増加し、他の要因が一定のままである場合、特定のポイント[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
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を搭載したA DS3バックボーンの場合を検討してください。その後、最大セルレートは96,000セル/秒になります。この値にペイロードのビット数を掛けると、96000セル/秒 * 48バイト/セル * 8 = 36.864 Mbpsが得られます。ただし、これは完全なペイロードパッキングを想定しているため、非現実的です。ATMのオーバーヘッド（細胞税）に寄与する他の2つのことがあります。無駄なパディングと8バイトスナップヘッダーです。
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つのセルを消費します。2番目のセルはほとんど空のパディングです（これは引用符を引いたデータと非常に不十分に相互作用します上記、たとえば、ほとんどのパケットは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 Acksで構成されているため、異なるが関連する計算を行うことができることです。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
IPデータ（この場合は40バイト）8バイトスナップ8バイトAAL5スタッフ各セルに5バイトが最後のセルに記入するのにかかるのと同じくらいかかります
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.
ATMでは、これは2つのセルになります-40バイトの情報を伝達するための106バイト。次に最も一般的なサイズは、IP、TCP、および512バイトのTCPペイロードを搭載するための504-556バイト範囲-636バイトのいくつかのサイズの1つであると思われます。
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 over y」モデルとして頻繁にキャストされます。これらの場合、プロトコルYは、YのデータプレーンでプロトコルXのプロトコルデータユニット（およびおそらく制御データ）を運びます。つまり、Yは「収束層」です。例には、ATM上のフレームリレー、ATM上のIP、およびMPLよりもIPが含まれます。X over y層はわずかな成功しか満たされていませんが[Tennenhouse、Wakeman]、効率が得られ、得られる顕著な例がいくつかあります。特に、XとYの間に「異型」のようなものがある場合、「x over y効率」を実現できます（つまり、小さな収束層があります）。これらの場合、Xのデータ、およびおそらく制御トラフィックは「カプセル化」され、Yを介して輸送されます。例には、ATM上のフレームリレー、L2TPV3 [L2TPV3]を超えるフレームリレー、AAL5 ATM、イーサネットが含まれます。ここでの単純化要因は、通信エンドポイントによって共有クロックが回復されるという要件がなく、コントロールプレーンインターワーキングが最小化されることです。別の方法は、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.
IP Over ATMは、予期せぬ2次効果の優れた例を提供します。特に、ATMのTCPグッドプット[ロマノフ]に関するロマノフとフロイドの古典的な研究では、合理的なパフォーマンスを達成するために大きなUBRバッファー（1つのTCPウィンドウサイズ）が必要であることが示されました。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 Transportの下層層の暗黙の仮定の影響を考えてみましょう。特に：
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は往復時間を測定し、測定された往復時間に基づく期間内に認識がないことがパケット損失であり、したがって輻輳の兆候であると仮定します[Karn]。
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のような復元時間（50msなど）を必要とする場合です。そもそも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アプローチは大規模に問題がありました。彼の懸念は、最低介入の原則で成文化されています。
"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]は、微妙に異なるが注目すべき例外です。この場合、制御面は制御データの形式に依存しません。つまり、一部のソフトスイッチメーカーが想定するATM/IPインターワーキングや、いわゆる「pnni-mpls sin」インターワーキング[atmmpls]などのコントロールプレーンインターワーキングモデルとは対照的に、コントロールプレーンのデータ変換は必要ありません。
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 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:
パケットスイッチが希少な帯域幅を効率的に使用することはよく知られています[Baran]。この効率は、パケットスイッチングに固有の統計的多重化に基づいています。しかし、私たちは、一般的にインターネットのバックボーンの利用率が低いと考えられているものに困惑し続けています。私たちが尋ねる最初の質問は、インターネットバックボーンの現在の平均利用は何ですか、そしてそれは長距離音声ネットワークの利用とどのように関係しているのでしょうか？OdlyzkoとCoffman [Odlyzko、Coffman]は、IPネットワークでのリンクの平均利用率は3％から20％の範囲であると報告しています（コーポレートイントラネットは3％の範囲で実行され、商用インターネットバックボーンは15-20％で実行されます。範囲）。一方、長距離の音声ラインの平均利用は約33％です。さらに、2002年には、光ネットワーク（すべてのサービス）の平均利用率は約11％でホバリングしているように見えますが、過去の平均は約15％です[ML2002]。問題は、特にPSがCSよりも本質的に効率的であるという仮定に照らして、そのような利用レベルを見る理由になります。OdlyzkoとCoffmanが引用した理由は次のとおりです。
(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;
（ii）。リンクのトラフィックの成長を予測することは困難であるため、オペレーターは帯域幅を積極的に追加する傾向があります。
(iii). Falling prices for coarser bandwidth granularity make it appear more economical to add capacity in large increments.
（iii）。粗い帯域幅の粒度の価格の下落により、容量を大幅に増やすためにより経済的に見えるようになります。
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つの尺度は、デバイスのプログラムに必要な命令の数です。インターネットルーターの典型的なソフトウェアイメージには、800万から1,000万の指示（ファームウェアを含む）が必要ですが、典型的なトランスポートスイッチには平均で約300万の指示が必要です[MCK2002]。
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].
ソフトウェアの複雑さのこの違いは、インターネットルーターを信頼できないようにする傾向があり、他の顕著な2次効果を持っています（たとえば、そのようなルーターを再起動するのに長い時間がかかる場合があります）。比較の別のポイントとして、膨大な数の呼び出し機能を備えたAT＆T（Lucent）5ESSクラス5スイッチには、インターネットコアルーター[EICK]としてのコードの数の約2倍の数だけが必要であることを考えてください。
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.
最後に、ルーターはハードウェアデバイスと同じくらいまたはそれ以上のソフトウェアであるため、コードの複雑さのもう1つの結果は、ルーターのコストがソフトウェア集約型のデバイスよりもムーアの法則からの利益が少ないことです。これにより、帯域幅/デバイスのトレードオフが発生し、ソフトウェア集約型のデバイスよりも帯域幅を好みます。
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に少なくとも3,000万個のゲート、少なくとも1つのCPU、300 mbytesのパケットバッファー、2 mbytesの転送テーブル、10 mbytesの他の10 mbytesが含まれています。状態記憶。一方、同等の輸送スイッチラインカードには、750万のロジックゲート、CPU、パケットバッファーなし、転送テーブルなし、およびオンチップ状態メモリがあります。むしろ、電子輸送スイッチのラインカードには、通常、ソネットフレーマー、タイムスロットを脱出させるタイムスロットをマッピングするチップ、スイッチファブリックへのインターフェイスが含まれています。
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倍であり、ギガビット/秒あたり約3分の1で販売されています。光学（OOO）テクノロジーにより、この複雑さの違いがさらにプッシュされます（たとえば、調整可能なレーザー、MEMSスイッチ。たとえば、[Calient]、[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).
コール入場制御、効率的なパケット分類、スケジューリングアルゴリズムなど、インターネットQOの完全なソリューションのコンポーネントは、10年以上にわたって広範な研究と標準化の対象となっていますが、インターネットのエンドツーエンドのシグナルQOは 現実にならない。 あるいは、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].
メトリックを定量化するのがやや難しいのは、インターネットの固有の柔軟性です。インターネットの柔軟性は急速な成長につながりましたが、この柔軟性は、非常に訓練されたサポート担当者の必要性であるEdgeで比較的高いコストを備えています。標準的な経験則では、エンタープライズ設定では、単一のサポート担当者がグループに電話サービスを提供するのに十分であり、同じグループ[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やフレームリレーなどの仮想回路ネットワークには存在しないことに注意してください。たとえば、問題が自分のネットワークの外部であることを発見するためにのみ、ルーターの大きなセットにアクセスする必要がある場合があります。さらに、問題の診断に使用されるデバッグツールも複雑であり、やや原始的です。最後に、IPはDNS、メール、ニュース、または新しいアプリケーションに問題がある人に対処する必要がありますが、これは通常TDM/ATM/などの場合はそうではありません。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保護」と見なすかもしれません。このように表示されると、50％の使用率で実行されるようにプロビジョニングされたIPネットワークは、典型的な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].
Paul Baranは、「ネットワークに関するいくつかの視点 - 過去、現在、未来」で、「コストとシステムの信頼性のトレードオフ曲線は、最も信頼性の高いシステムが比較的信頼できないため、低コストの要素で構築される可能性があることを示唆していると述べました。、問題が発生している最低のシステムコストでシステムの信頼性がある場合」[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九の神話」と呼んでいます。具体的には、パケットネットワーク要素のいわゆる5九本の信頼性は、次の理由で神話を考慮してください：最初に、予定外の停止の80％が人またはプロセスエラーによって引き起こされるため[Scott]、最適化する。したがって、コンポーネントの信頼性を高めるために、複雑さ（最適化は頻繁に複雑さにつながる）を追加します。これは、計画外の停止の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つの9つの信頼性に達することができるが、個々のコンポーネント、特に最も複雑なコンポーネントをその信頼性基準に到達させることは望ましくない（そしておそらく不可能な）ことです。
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|))
where
ただし
O(f) = {g:N->R | there exists c > 0 and n such that 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）は、一定のcと数nが存在する関数gのセットを含むため、g（n）はすべてのnのc*f（n）に小さくまたは等しくなります。つまり、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は、複雑さの研究のための一般的なフレームワークを開発するための最近の試みの1つであり、一般的に「The」と呼ばれる抽象化の家族のメンバーです。複雑さの新しい科学」または「複雑な適応システム」）。耐性は、ホットセマンティクスでは、「複雑なシステムの堅牢性は、慎重に管理および保護する必要がある制約された限られた量である」ことを意味します。ホットモデルの焦点の1つは、上記の例の複雑さ（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では、主要な証明されていないスケーラビリティの問題への対処を避けることができるように」「限られた規模の展開（そのような）または「それ以外の場合は大規模な投資が必要です」スクラッチ）」[ティナ]。言い換えれば、これらのシステムには複雑なサービス提供パスがあり、複雑すぎて実行可能に展開できませんでした。
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".
このドキュメントは、長年にわたるインターネットアーキテクチャの原則を成文化しようとします。特に、ここで説明する統一原則は、複雑なオブジェクトを効率的に拡張したい場合は複雑さを制御する必要があると述べる単純さの原則で最もよく表現されます。シンプルさ自体が何らかの形の最適性につながる可能性があるという考えは、歴史を通じて共通のテーマであり、他の多くの方法や多くの側面に沿って述べられています。たとえば、Occam's Razorとして知られる格言を考えてみましょう。これは、中世の英国哲学者とフランシスコ会のモンクウィリアムオブオッカム（CA。1285-1349）によって策定され、「複数の非ESTポネンダのサインネクセテート」または「多複数が仮定されるべきではありません」と述べています。必然的に。」（したがって、オッカムのカミソリは、「不必要な複数の原則」と「シンプルさの原則」と呼ばれることもあります）。おそらくOccam's Razorのより現代的な定式化は、現象の最も単純な説明は本質的に好まれるものであると述べています。同じアイデアの他の定式化は、キス（単純な愚かな）原則と最も驚きの原則（最も使いやすいシステムは、最も頻繁にユーザーを驚かせるものであるという主張）に見られます。[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].
パケットスイッチのネットワークアーキテクチャに適用されると、シンプルさの原則には、一部の人が異端を考える場合があります。それ以外の場合は、「最適な」収束層は、従来と考えられているプロトコルスタックでははるかに低い場合があります。さらに、上記の分析は、パケットネットワーキングを取り巻く従来の知恵に反するいくつかの結論につながります。おそらく最も重要なのは、パケットの切り替えが回路の切り替えよりも簡単であるという信念です。この信念は、「パケットは回路よりも簡単であるため、動作するのに費用がかかる必要がある」などの結論につながりました。この研究はそれとは反対です。特に、上記のメトリックを調べることにより、パケットの切り替えは回路の切り替えよりも複雑であることがわかります。興味深いことに、この結論は、データネットワークの正規化されたオペックスが通常、音声ネットワークよりも著しく大きいという事実によって裏付けられています[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.
回路の切り替えとパケットスイッチされたネットワークの複雑さを比較するためのアイデアの多くは、Nick McKeownとの会話に触発されました。スコット・ブラッドナー、デビッド・バニスター、スティーブ・ベロヴィン、スチュワード・ブライアント、クリストフ・ディオット、スーザン・ハリス、アナント・ナガラジャン、アンドリュー・オドリズコ、ピート、ナタリー・ホワイティング、リキシア・チャンは、この文書の初期草案について多くの有益なコメントをしました。
[AHUJA] "The Impact of Internet Policy and Topology on Delayed Routing Convergence", Labovitz, et. al. Infocom, 2001.
[Ahuja]「遅延ルーティングの収束に対するインターネットポリシーとトポロジの影響」、Labovitz、et。アル。Infocom、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]「ATM-MPLS移行の複雑さの問題と予備評価」、学際的コンピューティングおよびエンジニアリングの学校、ミズーリカンザス大学、2002年4月
[BARAN] "On Distributed Communications", Paul Baran, Rand Corporation Memorandum RM-3420-PR, http://www.rand.org/publications/RM/RM3420", August, 1964.
[バラン]「分散通信について」、ポール・バラン、ランドコーポレーションメモRM-3420-PR、http：//www.rand.org/publications/rm/rm3420 "、1964年8月。
[BARAN77] "SOME PERSPECTIVES ON NETWORKS--PAST, PRESENT AND FUTURE", Paul Baran, Information Processing 77, North-Holland Publishing Company, 1977,
[baran77]「ネットワークに関するいくつかの視点 - パスト、現在、未来」、ポール・バラン、情報処理77、ノースホランド出版社、1977年、
[BRYANT] "Protocol Layering in PWE3", Bryant et al, Work in Progress.
[Bryant]「PWE3でのプロトコル階層式」、Bryant et al、Work in Progress。
[CAIDA] http://www.caida.org
[Caida] http://www.caida.org
[CALLIENT] http://www.calient.net/home.html
[カリエント] 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
[カールソン]「複雑さと堅牢性」、J.M。カールソンとジョン・ドイル、Proc。natl。アカデミー。SCI。米国、vol。99、suppl。1、2538-2545、2002年2月19日。http：//www.pnas.org/cgi/doi/10.1073/pnas.012582499
[CIENA] "CIENA Multiwave CoreDiretor", http://www.ciena.com/downloads/products/ coredirector.pdf
[Ciena] "Ciena MultiWave 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.
[クラーク]「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。コフマンとA.M.Odlyzko、pp。47-93、Handbook of Massive Data Stes、J。Elli、P。M。Pardalos、およびM. G. C. Resende、編集者。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、et al、国立統計科学研究所、テクニカルレポート113、2000年12月。
[MOLINERO2002] "TCP Switching: Exposing Circuits to IP", Pablo Molinero-Fernandez and Nick McKeown, IEEE January, 2002.
[Molinero2002]「TCPスイッチング：サーキットをIPに露出させる」、Pablo Molinero-Fernandez、Nick McKeown、IEEE 2002年1月。
[FLOYD] "The Synchronization of Periodic Routing Messages", Sally Floyd and Van Jacobson, IEEE ACM Transactions on Networking, 1994.
[Floyd]「定期的なルーティングメッセージの同期」、Sally Floyd and Van Jacobson、IEEE ACM Transactions on Networking、1994。
[FLOYD2001] "A Report on Some Recent Developments in TCP Congestion Control, IEEE Communications Magazine, S. Floyd, April 2001.
[FLOYD2001] "TCP混雑制御における最近の開発に関するレポート、IEEE Communications Magazine、S。Floyd、2001年4月。
[FRALEIGH] "Provisioning IP Backbone Networks to Support Delay-Based Service Level Agreements", Chuck Fraleigh, Fouad Tobagi, and Christophe Diot, 2002.
[Fraleigh]「遅延ベースのサービスレベル契約をサポートするIPバックボーンネットワークのプロビジョニング」、Chuck Fraleigh、Fouad Tobagi、およびChristophe 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.
[グリフィン]「1つのルートフラップの音」、ティモシーG.グリフィン、大規模な通信ネットワークに関するIPAMワークショップ：トポロジー、ルーティング、トラフィック、コントロール、2002年3月。
[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]「層間の仮定（輸送エリアからのビュー）について、ワイヤレスインターネットワークに関するIABワークショップでのプレゼンテーションからスライドします」、M。Handley、2000年3月。
[HOT] J.M. Carlson and John Doyle, Phys. Rev. E 60, 1412- 1427, 1999.
[ホット] J.M.カールソンとジョン・ドイル、Phys。Rev. E 60、1412-1427、1999。
[ISO10589] "Intermediate System to Intermediate System Intradomain Routing Exchange Protocol (IS-IS)".
[ISO10589]「中間システムへの中間システム内部ドーマンルーティング交換プロトコル（IS-IS）」。
[JACOBSON] "Congestion Avoidance and Control", Van Jacobson, Proceedings of ACM Sigcomm 1988, pp. 273-288.
[ジェイコブソン]「混雑の回避とコントロール」、ヴァンジェイコブソン、ACM Sigcomm 1988の議事録、pp。273-288。
[KARN] "TCP vs Link Layer Retransmission" in P. Karn et al., Advice for Internet Subnetwork Designers, Work in Progress.
[Karn] P. Karn et al。の「TCP vsリンクレイヤー再送信」、インターネットサブネットワークデザイナーへのアドバイス、進行中の作業。
[KUHN87] "Sources of Failure in the Public Switched Telephone Network", D. Richard Kuhn, EEE Computer, Vol. 30, No. 4, April, 1997.
[Kuhn87]「公共の切り替えた電話網における失敗の原因」、D。リチャード・クーン、EEE Computer、vol。30、No。4、1997年4月。
[L2TPV3] Lan, J., et. al., "Layer Two Tunneling Protocol (Version 3) -- L2TPv3", Work in Progress.
[L2TPV3] Lan、J.、et。al。、「レイヤー2トンネルプロトコル（バージョン3）-L2TPV3」、進行中の作業。
[MC2001] "U.S Communications Infrastructure at A Crossroads: Opportunities Amid the Gloom", McKinsey&Company for Goldman-Sachs, August 2001.
[MC2001]「交差点での米国のコミュニケーションインフラストラクチャ：暗闇の中での機会」、2001年8月、ゴールドマンサックスのマッキンゼー＆カンパニー。
[MCK2002] Nick McKeown, personal communication, April, 2002.
[MCK2002] Nick McKeown、Personal Communication、2002年4月。
[ML2002] "Optical Systems", Merril Lynch Technical Report, April, 2002.
[ML2002]「光学システム」、Merril Lynchテクニカルレポート、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。Nave、et al、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ネットワーク障害の原因」、Peter G. Neumann、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]「データネットワークは、ほとんど正当な理由でほとんど空です」、A.M。Odlyzko、IT Professional 1（no。2）、pp。67-69、1999年3月/4月。
[ODLYZKO98A] "Smart and stupid networks: Why the Internet is like Microsoft". A. M. Odlyzko, ACM Networker, 2(5), December, 1998.
[odlyzko98a]「スマートで愚かなネットワーク：インターネットがマイクロソフトのような理由」。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、1998年7月。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 Park and Walter Willinger、AT＆T Research、2002。
[PERROW] "Normal Accidents: Living with High Risk Technologies", Basic Books, C. Perrow, New York, 1984.
[Perrow]「通常の事故：リスクの高いテクノロジーでの生活」、Basic Books、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.、Gardner、E。、およびY. Rekhter、「インターネットでのOSI NSAP配分のガイドライン」、RFC 1629、1994年5月。
[RFC1925] Callon, R., "The Twelve Networking Truths", RFC 1925, 1 April 1996.
[RFC1925] Callon、R。、「The Twelve Networking Truths」、RFC 1925、1996年4月1日。
[RFC1958] Carpenter, B., Ed., "Architectural principles of the Internet", RFC 1958, June 1996.
[RFC1958] Carpenter、B.、ed。、「インターネットの建築原理」、RFC 1958、1996年6月。
[RFC2283] Bates, T., Chandra, R., Katz, D. and Y. Rekhter, "Multiprotocol Extensions for BGP4", RFC 2283, February 1998.
[RFC2283] Bates、T.、Chandra、R.、Katz、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] Dawkins、S.、Montenegro、G.、Kojo、M。and 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、Vol。13、No 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.
[Saltzer]「システム設計におけるエンドツーエンドの引数」、J.H。Saltzer、D.P。リード、およびD.D.クラーク、ACM TOCS、Vol 2、番号4、1984年11月、pp 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、Gartner Group Research Note、1999年3月。
[SPILLMAN] "The Law of Diminishing Returns:, W. J. Spillman and E. Lang, 1924.
[Spillman] "減少するリターンの法則：、W。J。Spillman and E. Lang、1924。
[STALLINGS] "Data and Computer Communications (2nd Ed)", William Stallings, Maxwell Macmillan, 1989.
[Stallings] "Data and Computer Communications（2nd Ed）"、William Stallings、Maxwell Macmillan、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。テネンハウス、高速ネットワークのプロトコルに関するIFIPワークショップの議事録、Rudin ed。、North Holland Publishers、1989年5月。
[THOMPSON] "Nonlinear Dynamics and Chaos". J.M.T. Thompson and H.B. Stewart, John Wiley and Sons, 1994, ISBN 0471909602.
[トンプソン]「非線形ダイナミクスとカオス」。J.M.T.トンプソンとH.B.Stewart、John Wiley and Sons、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)
[ティナ]「ティナとは何ですか、それは通信事業に役立ちますか？」、Paolo Coppo、Carlo A. Licciardi、CSELT、Eurescom参加者P847（FT、IT、NT、TI）の参加者
[WAKEMAN] "Layering considered harmful", Ian Wakeman, Jon Crowcroft, Zheng Wang, and Dejan Sirovica, IEEE Network, January 1992, p. 7-16.
[ウェイクマン]「レイヤーリングは有害と考えられていた」、イアン・ウェイクマン、ジョン・クロウクロフト、ゼン・ワン、およびデジャン・シロビカ、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]「核酸標識の代替方法としてのカスタム蛍光ヌクレオチド合成」、オクタビアンヘネガリウ*、パトリシアブレイワードおよびデイビッドC.ワード、ネイチャーバイオテクノロジー18：345-348（2000）。
[WILLINGER2002] "Robustness and the Internet: Design and evolution", Walter Willinger and John Doyle, 2002.
[Willinger2002]「堅牢性とインターネット：デザインと進化」、Walter Willinger and John Doyle、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]「インターネットバックボーントラフィックのスケーリング動作に対する集約の影響」、Sprint ATL Technical Report TR02-ATL-020157 Zhi-Li Zhang、Vinay Ribeiroj、Sue Moon、Christophe Diot、2002年2月。
Randy Bush EMail: randy@psg.com
ランディブッシュメール：randy@psg.com
David Meyer EMail: dmm@maoz.com
David Meyerメール：dmm@maoz.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。