この文書はRFC3439の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
ironoxideは何ですか
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. 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. この文書はインターネットバックボーンネットワークの建築家と設計者が信 奉するある哲学的ガイドラインを説明することでＲＦＣ１９５８を拡張しま す。我々は単純原則を記述し、そしてこれは複雑さが効率的なスケーラビリ ティを妨げる主要要因であると述べて、そして大規模インターネットバック ボーンで見いだされた体系と設計と工学的問題の意味を論じます。 Table of Contents 目次 1. Introduction 1. はじめに 2. Large Systems and The Simplicity Principle 2. 大きいシステムと単純化原則 2.1. The End-to-End Argument and Simplicity 2.1. エンドエンド議論と単純化 2.2. Non-linearity and Network Complexity 2.2. 非線形性とネットワーク複雑さ 2.2.1. The Amplification Principle 2.2.1. 増幅原則 2.2.2. The Coupling Principle 2.2.2. カプリング原則 2.3. Complexity lesson from voice 2.3. 音声からの教訓 2.4. Upgrade cost of complexity 2.4. 複雑さの更新コスト 3. Layering Considered Harmful 3. 層の有害性 3.1. Optimization Considered Harmful 3.1. 最適化の有害 3.2. Feature Richness Considered Harmful 3.2. 豊富な機能の有害 3.3. Evolution of Transport Efficiency for IP 3.3. ＩＰの転送効率の進展 3.4. Convergence Layering 3.4. 収束層 3.4.1. Note on Transport Protocol Layering 3.4.1. トランスポートプロトコルレイヤのメモ 3.5. Second Order Effects 3.5. 副作用 3.6. Instantiating the EOSL Model with IP 3.6. ＩＰでＥＯＳＬモデルの実体化 4. Avoid the Universal Interworking Function 4. 普遍的インターワーク機能を避る 4.1. Avoid Control Plane Interworking 4.1. 制御面インターワーク機能を避る 5. Packet versus Circuit Switching: Fundamental Differences 5. パケット対回線交換：基本的な相違 5.1. Is PS is inherently more efficient than CS? 5.1. ＰＳは本質的にＣＳより効率的か？ 5.2. Is PS simpler than CS? 5.2. ＰＳはＣＳより単純ですか？ 5.2.1. Software/Firmware Complexity 5.2.1. ソフトウェア／ファームウェアの複雑さ 5.2.2. Macro Operation Complexity 5.2.2. マクロ処理複雑さ 5.2.3. Hardware Complexity 5.2.3. ハードウェア複雑さ 5.2.4. Power 5.2.4. 電力 5.2.5. Density 5.2.5. 密度 5.2.6. Fixed versus variable costs 5.2.6. 固定費と変動費 5.2.7. QoS 5.2.7. ＱｏＳ 5.2.8. Flexibility 5.2.8. 柔軟性 5.3. Relative Complexity 5.3. 相対的な複雑さ 5.3.1. HBHI and the OPEX Challenge 5.3.1. ＨＢＨＩと運用経費の挑戦 6. The Myth of Over-Provisioning 6. 過度供給の神話 7. The Myth of Five Nines 7. ファイブナインの神話 8. Architectural Component Proportionality Law 8. 構築要素比例法則 8.1. Service Delivery Paths 8.1. サービス配達パス 9. Conclusions 9. 結論 10. Security Considerations 10. セキュリティの考察 11. Acknowledgments 11. 謝辞 12. References 12. 参考文献 13. Authors' Addresses 13. 著者のアドレス 14. Full Copyright Statement 14. 著作権表示全文 1. Introduction 1. はじめに 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. ＲＦＣ１９５８[RFC1958]はインターネット体系の基礎原則を記述します。こ の文書はこの文書はインターネットバックボーンネットワークの建築家と設 計者が信奉するある哲学的ガイドラインを説明することでその仕事を拡張し ます。この文書で説明されたエリアの多くが議論の的であるかもしれないが、 ここで記述された統一の原則、制御コストと信頼性のメカニズムとして複雑 の制御は、はそうでないべきです。キャリアネットワークの複雑は多くの情 報源から生じます。しかしながら、[DOYLE2002]で述べられるように、「たい ていのシステムでの複雑さは、不安定な環境での強靭性の必要性や、基本機 能でない構成部分から生じます」。この文書の主要な推進力は、我々の現在 の体系のある複雑さについての認識を上げて、このような複雑さが成功する ＩＰキャリア産業の能力にほとんど確かに持つであろう効果を調べる事です。 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. この文書の残りが次のように編成されます：最初の章は非常に大きいシステ ムの設計の単純化原則とその意味を記述します。文書の残りが単純化の原則 の上位レベルの帰結と、それが大規模ネットワーク体系と設計方針を指導す るかを説明します。 2. Large Systems and The Simplicity Principle 2. 大きいシステムと単純化原則 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. ＵＵＮＥＴの前の最高建築家マイク・オーデルが明言した単純化原則は、複 雑さが効率的スケーラビリティを妨げる主要原因で、設備投資（ＣＡＰＥＸ） と運用経費（ＯＰＥＸ）を増加させる結果になると述べます。キャリアＩＰ ネットワークへのほのめかしは、成功するためには、最も単純な可能な解決 策に向かって体系と設計を動かさなければならないということです。 2.1. The End-to-End Argument and Simplicity 2.1. エンドエンド議論と単純化 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]で（同様にＲＦＣ１９５８[RFC1958]で）で記述されるエンドエン ド議論は、「エンドエンドプロトコル設計はネットワーク内の状態（すなわ ち、エンドエンド通信の状態の情報）の維持に依存すべきではない。このよ うな状態は末端でだけ維持し、終端点自身が壊れるときにだけ破壊される方 法で維持されるべき」と主張します。この特性は同じくクラークの「運命共 有」概念[CLARK]と関係があります。我々はインターネット体系 [WILLINGER2002]のいわゆる「砂時計」の明確な説明を調べることによってエ ンドエンド原則が直接単純化原則を導くのを見ることができます。このモデ ルで、砂時計の細いウエストは（ミニマリスト）ＩＰ層であると想定されま す、そして追加の複雑さはＩＰ層の上に加えられます。要するに、インター ネットの複雑さはエッジに属し、そしてインターネットのＩＰ層は可能な限 り単純なままでいるべきです。 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. 最終的に、エンドエンド議論がインターネットのコアが状態を持たず維持し ないということを意味しないことに注意してください。実際、膨大な量が粗 い粒度の状態（例えば、ルーティング状態）がインターネットのコアで維持 されています。しかしながら、重要な点はこの（荒い粒度の）状態はほとん ど末端（例えば、ホスト）で維持された状態と無関係なことです。単純化に 貢献するのはこの相互作用の最小化です。結果として、ネットワークアドレ ス翻訳（ＮＡＴ）のようなプロトコル分析する時、「コア対エンド」状態対 話の考慮は決定的で、これはネットワークとホストの間の透過性を減らしま す。 2.2. Non-linearity and Network Complexity 2.2. 非線形性とネットワーク複雑さ 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]: 複雑な体系と設計はコスト効果の高い大規模ＩＰネットワークを構築する重 大挑戦的な障壁でした（であり続けています）。例えば、建築する仕事が大 規模なパケットネットワークであると思ってください。産業的経験から、小 から中サイズのネットワークの構築と、大規模ネットワークの構築は、特性 が異なるので、全く異なる活動で（それ故異なる技能が要求される）あるこ とが明らかになっています。特に、最大ネットワークは、理論と実際の両方 で、体系と設計と工学的に、小さいスケールとは非線形を示します。我々は これを体系・設計・工学（ＡＤＥ）非線形性と呼びます。すなわち、インター ネットのようなシステムは、非常に異なるスケールの概念レベルで、高い自 己相似性がないといえます[CARLSON]。ＡＤＥ非線形性特性は、非線形システ ム理論の２つの既知の原則によります[THOMPSON]： 2.2.1. The Amplification Principle 2.2.1. 増幅原則 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. 増幅原則の重要な例は非線形の共鳴倍増です、これは表面上小さい変動が驚 くべき方法で、大きいネットワークのような、動的システムを変えることが できる強力なプロセスです。これらの小さい変動はゆっくりと貯まるかもし れず、そしてもしそれらが他のサイクルと同期するなら、主要な変動を作り 出すかもしれません。共鳴現象は小さい変動が拡大され、それらの最初の大 きさを超えて遠くに影響を持つもしれない非線形行動の例です。自然界はシ ステムサイズの変動を引き起こす共鳴行動の例で満ちています、例えば（小 さい突風の共鳴拡大による）タコマ峡橋の破壊です。他の例は小惑星帯と土 星の輪の隙間で、非線形の共鳴拡大を含みます。ある人間の行動やたいてい の巡礼システムの特性は太陽系力学、例えば、太陽日、月の２７.３日（公転 周期）と２９.５日（朔望周期）、太陽の３６５.２５日間の周期、の共鳴現 象の影響を受けています。 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). インターネットドメインで、接続性の増加が、より複雑で、そしてしばしば より遅いＢＧＰルーティング収束をもたらすことが明らかにされました [AHUJA]。関連した結果は小量の接続性により、ルーティングメッシュの出力 が入力より複雑になるということです[GRIFFIN]。増幅を減らす主要な方法は ローカルな変更がローカル効果だけを持つように保障することです（これは ローカルな変更が世界的な効果を持つシステムと対照した場合です）。最終 的に、ＡＴＭは増幅効果の優秀な例を供給します：もし１つのセルを失うな ら、全部のパケットが破壊されます（そしてこれは、早期パケット廃棄 [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] もう１つの増幅の面白い例は、工学分野もあり[CARLSON]で記述されます。彼 らはボーイング７７７を考察し、これは「ワイヤで飛ぶ」航空機で、およそ １５０、０００のサブシステムとおよそ１０００のＣＰＵを含みます。彼ら が述べるには、７７７が（少数の例を挙げると）大規模な大気変動や乱流限 界や貨物変動に対して強靭であるが、少数の大ＣＰＵの微小な変動が壊滅的 になり得るということです（幸いこれが非常にまれな事象です）。この例は 「複雑さは小さい不安原因を拡大でき、そして工学設計者はこのような不安 原因が非常にまれであることを保証しなくてはなりません」[CARLSON]という 事を示します。 2.2.2. The Coupling Principle 2.2.2. カプリング原則 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. いくつかの標準的な例がネットワークシステムでも存在します。例えば、ルー ティング更新同期やＴＣＰスロースタート同期のような、種々な制御ループ の同期です[FLOYD,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. 興味深い事に、公衆交換電話網（ＰＳＴＮ）のリスク要因分析において、 Charles Perrowは２つの関連した軸に沿って複雑さ問題を分解し、「相互作 用」と「カプリング」と呼びました[PERROW]。Perrowは複雑なシステム（そ して特にＰＳＴＮで）の信頼性を決定する際に相互作用とカプリングを重要 な要因として参照します。このモデルで、相互作用が要素間の（線形や非線 形の）依存性で、カプリングがシステムの柔軟性です。単純な線形相互作用 を持つシステムは機能上下流にある他の要素にだけ影響を与える要素からな ります。複雑なシステム要素が、システムの別のそして多分遠い部分の多く の他の要素と相互作用します。雑なカプリングシステムは緊密なカプリング システムより、時間制約と順序付けと環境上の仮定でより柔軟と言われます。 加えて、複雑な相互作用と緊密なカプリングを持つシステムは、思いがけな い失敗状態になる可能性が高いです（もちろん、複雑な相互作用は開発の混 乱を起こし理解と予想の難しいシステムを作ります）；この行動は [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]. ＰＳＴＮのＳＳ７制御ネットワークは緊密カプリング複雑システムがどう悪 くなるかの面白い例を供給します。よく知られているＡＴ＆ＴのＳＳ７の停 電のような停電は現象を証明します：停電は交換機の障害回復コードのソフ トウェアバグで起こりました。この場合、１つの交換機がハードウェア故障 のために停止しました。この交換機が回復した時、それ（とありそうなタイ ミングイベント）はその隣接交換機を停止しました。隣接交換機が回復する と、それはその隣接交換機を止め、それが続きました[NEUMANN]（最初の原因 は「ｂｒｅａｋ」文の場所が謝っていたことです；これはレイヤ間カプリン グのよい例です）。この現象は弱くつながれた発振器のフェーズロックに類 似していて、ここで時間列のランダムな相違がシステム安定性における重要 な役割を演じます[THOMPSON]。 2.3. Complexity lesson from voice 2.3. 音声からの教訓 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. １９７０年代と１９８０年代に、音声キャリアはＰＳＴＮの複雑さを増加さ せる機能を加えることで、特にクラス５を交換機インフラで競争しました。 この複雑さは典型的にソフトウェアベースで、ハードウェア駆動でなくて、 従ってムーアの法則より悪いコストカーブを持っていました。要約すると今 日の音声製品の乏しい限界は低下しない運用経費と設備投資コストによるも ので、我々が単純なハードウェア実装でコスト低下を期待しています。 2.4. Upgrade cost of complexity 2.4. 複雑さの更新コスト 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. 複雑なネットワークで新しい機能を供給するコストを考慮してください。伝 統的な音声ネットワークは知性の少ないエッジ装置（電話機）と非常に頭が 良いコアです。インターネットは頭が良いエッジと、オペレーティング・シ ステムを持っているコンピュータと、アプリケーションなどと単純なコア、 コアは制御とパケット転送エンジンから成り立ちます。新しいインターネッ トサービスを加えることは、使うことを望む少数のデスクトップにアプリケー ションを配る問題です。これを全部のコアを更新しなければならない音声サー ビスと比較してください。 3. Layering Considered Harmful 3. 層の有害性 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 ネットワーキングに適用する層あるいは垂直統合のいくつかの一般的な特性 があります。一般に、我々の状況で定義された層が以下の１つ以上を実行し ます。 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) フロー制御： 遅い通信相手を輻輳させるのを避ける（例えば、 ＡＴＭフロー制御） Fragmentation: Dividing large data chunks into smaller pieces, and subsequent reassembly (e.g., TCP MSS fragmentation/reassembly) 分割： 大きいデータパケットをより小さいパケットへの 分割と、続く再構築（例えば、ＴＣＰ ＭＳＳ 分割／組立） Multiplexing: Allow several higher level sessions share single lower level "connection" (e.g., ATM PVC) 多重送信： 複数の上位層セッションがひとつの下位「接続」 の共有を許す（例えば、ＡＴＭ ＰＶＣ） Connection Setup: Handshaking with peer (e.g., TCP three-way handshake, ATM ILMI) 接続設定： 通信相手との握手（例えば、ＴＣＰ三手順握手、 ＡＴＭ ＩＬＭＩ） Addressing/Naming: Locating, managing identifiers associated with entities (e.g., GOSSIP 2 NSAP Structure [RFC1629]) アドレス／命名： エンティティーと結び付けられた識別子の場所と 管理（例えば、ＧＯＳＳＩＰ２ ＮＳＡＰ 構造[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)." この種類のレイヤは様々な概念と組立て利点を持ちます。しかしながら、デー タネットワーキング環境で構造化レイヤは各レイヤの機能は、プロトコルデー タユニットが次のレイヤにパス届く前に完全に遂行されることを意味します。 これはそれぞれのレイヤの最適化が別にされなければならないことを意味し ます。このような順序制約はデータ扱い機能の効率的な実装と矛盾していま す。レイヤモデル（例えば、ＴＣＰ／ＩＰとＩＳＯ ＯＳＩ）は矛盾すると非 難した人がいます。実際、多重送信と分割処理は共によりレイヤの性能の最 適化が必要かもしれないという肝要な情報を隠します。例えば、レイヤＮが より低いレベルの機能と重複するかもしれません、例えば、ホップ毎のエラー 回復とエンドエンドエラー回復です。加えて、異なるレイヤが同じ情報を必 要とするかもしれません（例えば、タイムスタンプ）：レイヤＮがレイヤ Ｎ−２情報（例えば、より低いレイヤのパケットサイズ）や同種のものを必 要とするかもしれません[WAKEMAN]。関連した、そして更に皮肉な文が Tennenhouseの古い文献「層状の多重送信は有害と思われる」[TENNENHOUSE] にあります：「広帯域ネットワークへのＡＴＭの方法は、ネットワーク体系 の低レイヤのサービス統合と速度調整とジッタ制御のサポートのための統一 の機構として、まもなくＣＣＩＴＴ（やその他）で遂行されます。この文献 は特にエンドシステムやマルチサービスネットワーク（ＭＳＮ）のリレーで 扱う「中」から「上位」レイヤでのジッタを懸念します。」 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): レイヤ間の依存性の結果として、レイヤの増加は単純化原則違反を導きます。 産業上の経験は我々にレイヤの増加は複雑さを増やし、そのため、単純化原 則が予言するように、運用経費を増やします。結果はＲＦＣ１９２５ [RFC1925]の２（５）章で述べられます： "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. 最初の結論は、（垂直と対照した場合の）水平分散は、長期的に費用効果と 信頼性が高いです。 3.1. Optimization Considered Harmful 3.1. 最適化の有害 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]。ここの意味はあるポイント を超えて効率を出そうとすると複雑さを増やすだけで、それ故により低い信 頼性のシステムを導くということです。 3.2. Feature Richness Considered Harmful 3.2. 豊富な機能の有害 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. 新しい機能の追加が利点と思われる（そして実際しばしば種々のタイプの装 置のベンダーを区別します）が、脅威があります。脅威はシステムの複雑さ の増加です。 3.3. Evolution of Transport Efficiency for IP 3.3. ＩＰの転送効率の進展 The evolution of transport infrastructures for IP offers a good example of how decreasing vertical integration has lead to various efficiencies. In particular, ＩＰの転送基盤の進展は、縦の統合が様々な効果を持つかの、良い例を提供 します。特に、 | 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. ここの鍵となる点は、設備投資と運用経費の効果をもたらして、層が取り 去られるということです。 3.4. Convergence Layering 3.4. 収束層 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. 収束は「収束層」によって収束が成し遂げられるという点で、上記の層の概 念と関係があります。収束議論の終わり状態は、ある層の上にすべてがある （ＥＯＳＬ）との概念です。導管、ＤＷＤＭ、ファイバー、ＡＴＭ、ＭＰＬ ＳとＩＰでさえ、すべて収束層として提案されました。層が典型的に運用経 費の増加を導くので、収束も同じと思うことを指摘するのは重要です。この 観察は産業的経験と整合しています。 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. 収束層失敗の多くの顕著な例があります。多分最も適切な例はＡＴＭ上のＩ Ｐです。ＡＴＭレイヤの即刻で最も明白な結果はいわゆるセル税です：最初 に、ＡＴＭ効率上の完全な答えは、パケットサイズの分散に依存することに 注意してください。４０と４４と５５２バイトのパケットが高い比率を持つ 傾向がある典型的なインターネットタイプのトラヒックパターンを仮定しま しょう。最近のデータ[CAIDA]は９５％のＷＡＮバイトと８５％のパケットが ＴＣＰであることを示します。このトラフィックの多くが４０/４４のバイト のパケットで構成されています。 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. ＰＬＣＰがオンになっているＤＳ３バックボーンを考えます。最大のセル率 は９６，０００のセル／秒です。この値とペイロードのビット数を掛ければ いかが得られます：９６０００セル／秒 × ４８バイト／セル × ８ ＝ ３６．８６４Ｍｂｐｓ。しかしこれは、完ぺきなペイロード搭載を想定する ので、非現実的です。ＡＴＭオーバーヘッド（セル税）に関連する２つのこ とがあります：無駄なパディングと８バイトＳＮＡＰヘッダ。 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. 問題の大部分を起こすのはＳＮＡＰヘッダです（そしてあなたはこれについ て何もできません）、たいていの小さいパケットが２つのセルを消費します、 ２番目のセルはほとんど空のパディングです（これは上記、つまりほとんど のパケットが４０−４４バイトのＴＣＰ ＡＣＫパケットなので、下手な相互 作用です）。これは理想的な３６．８Ｍｂｐｓのスループットから１６％の 損失を発生させます。 So the total throughput ends up being (for a 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%. 結果：４４．７３６ＭｂｐｓのＤＳ３回線で、全体のオーバヘッドはおよそ ３１％です。 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: これを見るもう１つの方法は、ＷＡＮトラフィックの大部分がＴＣＰ ＡＣＫ で構成されるので、異なる関連計算ができます。ＡＴＭ上のＩＰの要求： 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. ＡＴＭ上で、これは４０バイトの情報を運ぶために２つのセル−１０６バイ ト−になります。次の最も一般的サイズは、５０４〜５５６バイト範囲、Ｉ ＰとＴＣＰと５１２バイトＴＣＰペイロードを運ぶ〜６３６バイトで、 １０００バイト以上のメッセージが第三と思われます。 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. ８７％のペイロード（５５６バイトメッセージサイズ）が３７％ペイロード （ＴＣＰ Ａｃｋサイズ）よりよいと思いますが、しかし顧客が使えるのは ９５−９８％と想像するでしょう、そしてＴＣＰ Ａｃｋが多いと平均をゆが めます。 3.4.1. Note on Transport Protocol Layering 3.4.1. トランスポートプロトコルレイヤのメモ 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.
あなた自身の真珠を育てることができプロトコルレイヤモデルはしばしば「Ｙ上のＸ」モデルの役します。これら の場合、プロトコルＹは、Ｙのデータプレーン上でプロトコルＸのプロトコ ルデータユニット（と多分制御データ）を運びます、すなわち、Ｙは「収束 層」です。例えばＡＴＭ上のフレームリレーや、ＡＴＭ上のＩＰや、ＭＰＬ Ｓ上のＩＰです。Ｙ上のＸレイヤはほとんど成功していない[TENNENHOUSE, WAKEMAN]が、効率の利益が得られる少数の顕著な例があります。特に、「Ｙ 上のＸ効率」は、ＸとＹの間に一種の「同型写像」がある時（すなわち、小 さい収束層がある時）に理解できます。Ｘのデータと制御トラフィックがＹ 上で「カプセルかされて」送られます。例えばＡＴＭ上のフレームリレーと、 Ｌ２ＴＰｖ３[L2TPV3]上のフレームリレーとＡＡＬ５ ＡＴＭとイーサネット です；ここの単純化要因は共有クロックが通信末端で回復する必要がなく制 御面の相互変換が最小であることです。他はＸとＹの制御とデータ面の相互 変換です；制御面変換は以下で論じられます。 3.5. Second Order Effects 3.5. 副作用 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. ＡＴＭ上のＩＰは予想できない副作用の優秀な例を供給します。特に、ロマ ノフとフロイドのＴＣＰ成功転送[ROMANOV]のＡＴＭ上での古典的研究は妥当 な性能を成し遂げるのに（１つのＴＣＰウインドウサイズより）大きいＵＢ Ｒバッファを要求し、（パケット早期廃棄やＰＥＤのような）パケット廃棄 メカニズムがバンド幅の効率的な使用を改善し、そしてＶＣ毎のキューや課 金のようなＦＩＦＯ＋ＥＰＤより精巧なサービスと廃棄戦略が、高い効率と 公さの正両方を保証するためにボトルネックで必要かもしれません。すべて の研究が明らかにバッファサイズがＴＣＰウインドウサイズより小さくない ことを要求するが、当然必要とされるバッファ量は使用するパケット廃棄メ カニズムに依存し、まだ未解決問題です。 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: この種類のレイヤ問題の例が実用的なネットワーキングでたくさんあります。 例えば、より低層のＩＰトランスポートの暗黙の仮定の効果を考えてくださ い。特に： o Packet loss: TCP assumes that packet losses are indications of congestion, but sometimes losses are from corruption on a wireless link [RFC3115]. o パケット損失：ＴＣＰはパケット損失が輻輳表示であると想定します、し かし時々損失は無線リンクの誤りのためです[RFC3115]。 o Reordered packets: TCP assumes that significantly reordered packets are indications of congestion. This is not always the case [FLOYD2001]. o 順序誤りパケット：ＴＣＰが過度のパケットの順序誤りは輻輳表示である と想定します。これは常に正しいのではありません[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 往復遅延時間：ＴＣＰは往復遅延時間を評価し、往復遅延時間評価に基づ いて一定期間内に確認応答がなければパケット損失と考え、それ故に輻輳 表示と想定します[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 混雑制御：ＴＣＰ混雑制御は暗黙にネットワークがフローのパケットをす べて同じに扱うと想定します、しかしこれは常に正しいのではありません [HANDLEY]。 3.6. Instantiating the EOSL Model with IP 3.6. ＩＰでＥＯＳＬモデルの実体化 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). 全てをＩＰ上で行う（ＥＯＩＰ）のが運用経費と設備投資の効率をもたら すだろうという基本的仮定で、ＩＰがほとんどすべての転送土台とするのが 提案されているが、重要な審査を要求します。特に多くのプロトコルがＩＰ ネットワークで効率的に送れるのに対し（特に、フレームリレーやイーサネッ トやＡＡＬ５ ＡＴＭのような、通信末端間で同期再生が必要ないプロトコル で）、単純化とレイヤ原則はＥＯＩＰが任意のサービスで最も効率的な収束 戦略を表さないかもしれないことを示唆します。どちらかと言うと、多く運 用経費と設備投資が効率的な収束層はもっと下位かもしれません（この行動 は単純化原則で予言されます）。 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. ＥＯＩＰが運用経費と設備投資で最も効率的でない例は、サービスやプロト コルがＳＯＮＥＴのような回復時間（例えば５０ｍｓ）を求める場合です。 このような回復時間と収束性質をもつＩＰネットワークの構築と運用は（可 能だとしても）、第１層にＳＯＮＥＴを作るより高価と想像できます。 4. Avoid the Universal Interworking Function 4. 普遍的インターワーク機能を避る 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]: 普遍的インターワーク機能（ＵＩＷＦ）の多数の実装があったが、ＩＷＦの 方法は大規模では問題が多いです。これの懸念は最小調停の原則[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." 「情報範囲を最小にし、カプセル化レイヤを通したデータフローの効率を改 善するために、ペイロードを、可能な場合は、修正無しで送るべきです。」 4.1. Avoid Control Plane Interworking 4.1. 制御面インターワーク機能を避る 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. この結果は統合解決空間という環境で最も良く理解できます。この場合、体 系と設計はすべての可能な世界の中で最も悪いものを成し遂げます。これは このような統合解決策が両端間の性能／設備投資／運用経費を不完全に利用 するからです：最も厳しい要求条件を持つプロトコルは他の面で要求条件の 譲歩をしなければならないのに対し、最小スイッチを要求するプロトコルは 最も高価なコストを負わなければならないかもしれません。これに種々な制 御面インターワーク問題を加えてください、そうすれば失敗が多いのがわか ります。要約すると、インターワーク機能はデータ面インターワークとカプ セル化に限定されるべきで、そしてこれらの機能はネットワークエッジで遂 行されるべきです。 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]. 上記のように、インターワークモデルは、インターワークされている層の間 に一種の「同型写像」がある場合に成功を収めていました。しばしば「統合 対夜の船のトレードオフ」と描写されたトレードオフは、様々な時に、様々 なプロトコルレイヤで調べられました。一般に、このような統合化された解 決策が効率的と分かった事例はほとんどありません。マルチプロトコルＢＧ Ｐ[RFC2283]はやや異なりますが、顕著な例外です。この場合、制御面は制御 データフォーマットとは独立しています。すなわち、あるソフトスイッチ製 造業者が想像し、「ＰＮＮＩ−ＭＰＬＳ ＳＩＮ」と呼んだ、ＡＴＭ／ＩＰイ ンターワークのような制御面インターワークモデルはと対照的に、制御面デー タ変換は必要ありません。 5. Packet versus Circuit Switching: Fundamental Differences 5. パケット対回線交換：基本的な相違 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. 従来の知識では、パケット交換（ＰＳ）が回線交換（ＣＳ）より、主に統計 多重送信とルーティングと転送決定がホップ毎に独立しているという事実か ら、本質的に効率的と考えていました[MOLINERO2002]。さらに、ＩＰが回線 交換より単純なので、配置と管理がより経済的になるべきであると広く想定 されます[MCK2002]。しかしながら、もしこれらと関連した仮定を調べるなら、 異なる絵が出現します（[ODLYZKO98]の例を参照）。次の章はこれらの仮定 を論じます。 5.1. Is PS is inherently more efficient than CS? 5.1. ＰＳは本質的にＣＳより効率的か？ 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]はＩＰネットワークのリンクの平均使用率が３％から２０ ％の間にあると報告します（企業のイントラネットが３％の範囲で動作し、 商用インターネットバックボーンが１５-２０％の範囲で動作する）。他方、 長距離音声回線の平均使用率はおよそ３３％です。加えて、光ネットワーク の（すべてのサービスの）平均使用率は、歴史的平均が１５％なのに対して、 ２００２年におよそ１１％のあたりと思われます[ML2002]。ここからの質問 は、特にＰＳは本質的にＣＳより効率的だという仮説を考えた場合に、なぜ このような利用率なのかです。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); (i). インターネットトラフィックは非常に不均一でバースト的なのに 対し、リンクは均一で固定容量です（すなわち、トラフィックマ トリックス、必要なリンク容量を知らない）； (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]。 5.2. Is PS simpler than CS? 5.2. ＰＳはＣＳより単純ですか？ 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. エンドエンド原則はインターネットの複雑さがエッジに属すると述べている と解釈できます。しかしながら、今日のインターネットバックボーンルータ は非常に複雑です。さらに、この複雑さは回線速度に比例します。回路交換 とパケット交換の相対的な複雑さは直接分析に影響しないと思われるので、 我々は代わりに複雑さの指標としてパケット交換と回線交換のいくつかの人 工物を調べます。指標になるかもしれないものは、ソフトウェア複雑さ、マ クロオペレーション複雑さ、ハードウェア複雑さ、電力消費量と密度があり ます。これらの指標のそれぞれが下で考察されます。 5.2.1. Software/Firmware Complexity 5.2.1. ソフトウェア／ファームウェアの複雑さ 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]. ソフトウェア／ファームウェアの複雑さの１つの指標は装置をプログラムす るのに必要な命令数です。インターネットルータの典型的なソフトウェアイ メージは（ファームウェアを含めて）８百万から１千万の間の命令を必要と するのに対して、典型的なトランスポートスイッチが平均しておよそ３百万 の命令を必要とします[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]. このソフトウェア複雑さの相違はインターネットルータを信頼できなくする 傾向があり、そして顕著な他の副作用を生みます（例えば、このようなルー タを再起動するのに長時間を要するかもしれない）。他の比較として、膨大 な呼機能をもつＡＴ＆Ｔ（ルーセント）５ＥＳＳクラス５交換機は、インター ネットコアルータのコード行の２倍だけが必要と考えられます[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. 最終的に、ルータがハードウェア装置というよりソフトウェアであるので、 コードの複雑さの結果はムーアの法則よりソフトウェア集中装置より少し有 利ということです。これは帯域幅がソフトウェア集中的装置に不利にはたら く帯域幅／装置トレードオフを起こします。 5.2.2. Macro Operation Complexity 5.2.2. マクロ処理複雑さ 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. インターネットルータのラインカードはパケットヘッダ処理や、最長プレフィッ クス一致処理や、ＩＣＭＰエラーメッセージ生成や、ＩＰヘッダオプション 処理や、ＴＣＰ混雑制御が効率的になるようなパケットバッファリング（こ れは一般に回線速度ＲＴＴに比例した大きさのバッファがをもち、バッファ がおよそ２５０ミリセカンドパケットデータのを持つであしょう）など、多 くの複雑な処理を行わなければなりません。これは経路とパケットフィルタ リングや、ＱｏＳやＶＰＮフィルタリングを含みません。 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. 他方、トランスポートスイッチは入口タイムスロットと出口タイムスロット とインターフェースを対応付けるだけで、それ故にかなり複雑でありません。 5.2.3. Hardware Complexity 5.2.3. ハードウェア複雑さ 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. ハードウェア複雑さの１つの尺度はラインカード上の論理ゲート数です [MOLINERO2002]。高速インターネットルータのラインカードの場合を考えま す：ＯＣ１９２ ＰＯＳルータのラインカードはＡＳＩＣに少なくとも３千万 のゲートと、少なくとも１つのＣＰＵと、３００メガバイトのパケットバッ ファと、２メガバイトの転送表と、１０メガバイトの他のメモリを持ちます。 他方、類似のトランスポートスイッチラインカードは７５０万の論理ゲート があり、ＣＰＵとパケットバッファと転送表はなく、チップ搭載の状態メモ リを持っています。どちらかと言うと、電子トランスポートスイッチのライ ンカードは典型的にＳＯＮＥＴフレーム処理と入口タイムスロットと出口タ イムスロットとインターフェースを対応付けるチップを含んでいます。 5.2.4. Power 5.2.4. 電力 Since transport switches have traditionally been built from simpler hardware components, they also consume less power [PMC]. トランスポートスイッチが伝統的により単純なハードウェア要素から作られ ているので、より少ない電力消費です[PMC]。 5.2.5. Density 5.2.5. 密度 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. 大容量トランスポートスイッチは大体ＩＰルータの４倍の容量を持ち [CISCO,CIENA]、そしてギガビット／秒での対比で３分の１の値段です。光学 式（ＯＯＯ）技術がさらにこの複雑さの差を広げ（例えば、レーザ調整、Ｍ ＥＭスイッチ、例えば、[CALIENT]）、そしてＤＷＤＭ多重化は非常に大容量 で低電力トランスポートスイッチを作る技術を用意します。 A related metric is physical footprint. In general, by virtue of their higher density, transport switches have a smaller "per-gigabit" physical footprint. 関連した尺度は物理的な大きさです。一般に、高密度のために、トランスポー トスイッチがより小さい「ギガビットあたりの」物理的な大きさを持ちます。 5.2.6. Fixed versus variable costs 5.2.6. 固定費と変動費 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. パケット交換は情報をｎ個に分割して運ぶので回線交換より高い変動費を持 つように思われるでしょう。この利点の多くは回線交換の比較的静的な性質 のためです、例えば、回線交換で前もって予定した通り情報が来るので、入 力情報の処理が必要ありません。例えば、回線交換の場合、入力情報のバッ ファやループ検出や次の転送先の解決やパケットヘッダのフィールド変更な どは不要です。最終的に、多くの回線交換ネットワークは関連する静的な設 定を帯域外の制御面（例えばＳＳ７）に統合し、データ面スイッチを単純化 します。最終損益は回線交換で直線的なのに対して、パケット交換ではデー タ率が大きくなるにつれてより複雑になるということです。 5.2.7. QoS 5.2.7. ＱｏＳ 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). インターネットＱｏＳの完全な解決策の、呼管理や効率的パケット分類やス ケジュールアルゴリズムなどの要素、の大規模な研究と標準化が１０年以上 行われて来たが、インターネットのエンドエンド信号ＱｏＳは実現していま せん。代わりに、ＱｏＳは発信側の回線交換インフラの一部でした。他方、 ＱｏＳは十分な帯域がないときに、キューの統制の決定のために通常配置さ れます。けれども音声トラフィックと異なり、パケット廃棄やひどい遅延は、 輻輳制御フィードバックのため、ＴＣＰトラヒックへ多大な影響があるかも しれません（特に、ＴＣＰバックオフ／スロースタートで）。 5.2.8. Flexibility 5.2.8. 柔軟性 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]。この現象はでも記述されます[PERROW]。 5.3. Relative Complexity 5.3. 相対的な複雑さ 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]。それで、上の章は観察可能な人工物 に関して複雑さを記述しようと努めます。これを念頭におくと、上記の複雑 さの増加を発生する基本的な要因はＩＰ体系固有の「ホップ毎の」独立（Ｈ ＢＨＩ）であることは明確です。これはＡＴＭやフレームリレーのようなエ ンドエンド体系と対照的です。 [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. この章の重要結論は単純化原則が、パケット交換にも、回線交換にも適用で きるが、パケットネットワークで複雑さ（それ故に運用経費と設備投資の特 性）を制御することがより重大だということです。この考えはパケット交換 が回線交換よりく未成熟な学問であるが、パケット交換がより複雑なライン カードに向かう傾向があり、回線交換の複雑さは回線容量に比例してると思 われるという観察結果で補強されます。 5.3.1. HBHI and the OPEX Challenge 5.3.1. ＨＢＨＩと運用経費の挑戦 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. ＨＢＨＩの結果として、我々が回線交換ネットワークと基本的に異なる方法 でＩＰネットワークを扱う必要があります。特に、ＩＰネットワークの直面 した主な運用経費挑戦は、またしてもパケット体系のホップ毎の独立な振る 舞いにより、大規模なＩＰネットワークのデバッグは高度な専門知識と理解 を必要とします（再び、この「ホップ毎の」独立がＡＴＭや回線交換のよう な仮想回線ネットワークで存在していないことに注意してください）。例え ば、問題がネットワーク外側であることを発見するためだけに、保守者が多 数のルータを訪問しなければならないかもしれません。さらに、問題診断の デバッグツールも複雑で幾分未開発です。最終的に、ＩＰはＤＮＳやメール やニュースや何か新しいアプリケーションで問題を抱えた人々を扱わなけれ ばならないのに対して、これは通常ＴＳＭ／ＡＴＭ／などで問題でありませ ん。ＩＰの場合、これは自動化を改善することで簡単になります（我々が顧 客について述べることはほとんどこれです）。一般に、運用経費に効果があ るネットワーク外の多くの変数があります。 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. 最終的に、設備投資と運用経費の間の量的な関係や、ネットワーク固有の複 雑さが、よく理解されないことを指摘します。実際、ネットワークのの複雑 さを記述する単位に関する合意はなく、これが設備投資や運用経費と複雑さ の間の正確な関係を捉え難くします。 6. The Myth of Over-Provisioning 6. 過度供給の神話 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]や他で述べたように、我々が今日のインターネットで観察する複雑 さの多くが、帯域使用の増加に向けられます。結果として、ネットワークエ ンジニアがネットワーク使用率を５０％以下に維持する願望は「過度供給」 と呼ばれました。しかしながら、この過度供給という用語は誤った名称です。 どちらかと言うと、近代的インターネットバックボーンで使われていない容 量は実際は保障容量です。特に、これを「ＩＰ層での１：１保障」と見るか もしれません。このように見れば、５０％使用率で供給されたＩＰネットワー クが、一般的ＳＯＮＥＴネットワークより過剰供給ではありません。しかし ながら、このようにして供給されたＩＰネットワークで生じる重要な利点は 遅延を光速に近づける事と、パケット損失をゼロに近づけることを含みます [FRALEIGH]。これらの利益は１：１の保障供給の「副作用」と見れます。 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. １：１のような保障供給を行う他のシステム理論的な理由があります。ほと んどの有名な理由は帯域内制御ループを持つパケット交換ネットワークが輻 輳時に不安定になり変動と同期がおこるということです。トラフィックの複 雑で非線形な動的相互作用はネットワークの一部分での輻輳はネットワーク 他の部分に広まることを意味します。ルーティングプロトコルパケットが輻 輳やルートプロセッサの過負荷で失われる時、これは整合しないルーティン グ常態を起こし、そしてこれはトラフィックループやブラックホールや接続 性損失をもたらすかもしれません。それで統計多重送信は理論上高い利用率 を生じるはずなのに、実際は、性能と適度に安定したネットワークの整合を 維持し、インターネットバックボーンの力学は１：１供給を奨励し、ネット ワークの安定と低遅延の副作用をもたらします。 7. The Myth of Five Nines 7. ファイブナインの神話 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). 今日我々はこの現象を「ファイブナイン神話」と述べます。特に、パケット ネットワーク要素でのファイブナイン信頼性がが次の理由に関して神話と考 えます：最初に、予定外停電の８０％が人やプロセスエラー[SCOTT]で起こる ので、最適化できるのは２０％だけです。それで、構成要素の信頼性を増や すために、我々は複雑さを発生させ（最適化がしばしば複雑さを導く）、そ してこれは予定外停電の８０％の根本原因です。これは２０％の余地をさら に狭めなす（すなわち、人やプロセスの誤りの可能性を増やします）。この 現象は「複雑／強靭」スパイラル[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. 結論は、インターネットのようなシステムがファイブナインの信頼性に達す ることができるが、個別の要素、特に最も複雑なものは、信頼性標準に達す ることが望ましくない（そして多分不可能である）ということです。 8. Architectural Component Proportionality Law 8. 構築要素比例法則 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| be number of distinct components in the service delivery path of architecture A, 体系Ａのサービス配達パス上の異なる要素の数 w be a monotonically increasing function, 機能増加の単調性 P be the probability of a stable implementation of an architecture, and let 体系の安定実装の可能性 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)は関数gの集合で、関数gは全ての数nに対し、g(n)が c*f(n)以下となる定数cがある関数です。すなわち、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]は一般的用語で複雑さを描写しよう と試みます（ＨＯＴは複雑さの研究の一般的なフレームワークを発展させる １つの最近の試みで、一般に「複雑さの新科学」あるいは「複雑適応システ ム」と呼ばれる抽象概念の一種です）。ＨＯＴ意味論での、我慢は「複雑な システムでの安定は慎重に管理と保護されなければならない量が不自然で制 限されている」ことを意味します。ＨＯＴモデルの１つの焦点は、上記の例 のComplexity(A) の様な（他の例は火事と停電とインターネットトラフィッ ク分配を含む）のような、重く終わる分散の特徴づけです。特に、 Complexity(A)がシステム（インターネット）の部分の極度の不均一への対応 付けと、階層化と多段スケールの高組織化ネットワークへの組織の効果を試 みます。 8.1. Service Delivery Paths 8.1. サービス配達パス The Architectural Component Proportionality Law (ACPL) states that the complexity of an architecture is proportional to its number of components. 構築要素比例法則（ＡＣＰＬ）は体系の複雑さが要素数に比例していると述 べます。 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. この結果は、顧客と望ましいサービスの間のパスが特にパスの要素数と複雑 さに敏感なので、ＡＣＰＬの重要な結果です。これは我々が上位レベル集約 で見出す複雑さの「平滑化」[ZHANG]が、エッジでの処理ではなく、後方業務 やＣＲＭシステムと複雑な相互作用を持つ、という事実のためです。この効 果のために市場がなかった体系の例は、TINAベースCRMシステムや、ＣＯＲＢ Ａ／ＴＩＮＡベースサービス体系です。ここの基本的な教訓は、これらのシ ステムを実装する可能性があるのは、「Starvisionのような限定的配置で、 主な証明されていないスケール問題の対処を避けることができる」か、 「（ほとんどゼロから作られたキャリアグレードのＯＲＢのような）大規模 投資を必要とする」ものだという事です[TINA]。言い換えれば、これらのシ ステムは複雑なサービス配達パスを持ち、展開するには複雑すぎました。 9. Conclusions 9. 結論 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". この文書は長く理解されてきたインターネット体系の原則を成文化しようと 試みます。特に、ここで記述された統一原則は単純化原則で最もよく表現さ れ、そしてもし効率的に複雑なオブジェクトのスケールを望むなら、複雑さ を制御しなければならないと述べます。単純さ自身が最適形式を導くという 考えは、歴史を通じて一般的テーマであり、多くの方法と方面で述べられま した。例えば、中世の英国の哲学者とオッカムのフランシスコ修道士ウィリ アム（１２８５−１３４９ころ)によって定式化されたオッカムの剃刀として 知られている格言は、「存在は不必要に増加してはならない」あるいは「複 数性が必要無しで仮定されるべきではない」と述べます。（それ故オッカム の剃刀は時々「多数不必要原則」と「単純原則」と呼ばれます）。オッカム の剃刀の多分より現代な公式は、現象の最も単純な説明が自然な優先である、 と述べます。同じ考えの他の明確な説明がＫＩＳＳ（愚かで単純なままでい ろ）原則と、最少驚き原則（最も有用なシステムはしばしば最もユーザを驚 かさないという主張）、で見いだされます。[WILLINGER2002]は「単純さを 通しての強靭性」のより理論的な議論を供給し、そしてＰＳＴＮの議論 [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]で述べられます：「プロトコル進展は強靭性／複雑さ／もろ さのスパイラルを導きます、強靭さが複雑さを加え、新しいもろさを加えま す、これは新しい連鎖的な複雑さを導きます」。これは単純化原則が避けた いと考えている現象です。 10. Security Considerations 10. セキュリティの考察 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. この文書は既存のインターネット・プロトコルのセキュリティに直接影響を もたらしません。しかしながら、単純化原則への固守が安全なシステムを実 行する我々の能力に直接影響を持っています。特に、システムの複雑さは成 長します、それは設計や分析をいっそう難しくします、そしてそれ故にその 体系と設計と実行に固有のセキュリティの意味を見いだして理解することは より難しくなります。 11. Acknowledgments 11. 謝辞 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との会話から出ました。Scott BradnerとDavid BanisterとSteve BellovinとSteward BryantとChristophe DiotとSusan HarrisとAnanth NagarajanとAndrew OdlyzkoとPete and Natalie WhitingとLixia Zhangはこ の文書の初期ドラフトで多くの助けになるコメントをしました。 12. References 12. 参考文献 [AHUJA] "The Impact of Internet Policy and Topology on Delayed Routing Convergence", Labovitz, et. al. 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 [BARAN] "On Distributed Communications", Paul Baran, Rand Corporation Memorandum RM-3420-PR, http://www.rand.org/publications/RM/RM3420", August, 1964. [BARAN77] "SOME PERSPECTIVES ON NETWORKS--PAST, PRESENT AND FUTURE", Paul Baran, Information Processing 77, North-Holland Publishing Company, 1977, [BRYANT] "Protocol Layering in PWE3", Bryant et al, Work in Progress. [CAIDA] http://www.caida.org [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 [CIENA] "CIENA Multiwave CoreDiretor", http://www.ciena.com/downloads/products/ coredirector.pdf [CISCO] http://www.cisco.com [CLARK] "The Design Philosophy of the DARPA Internet Protocols", D. Clark, Proc. of the 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. [DOYLE2002] "Robustness and the Internet: Theoretical Foundations", John C. Doyle, et. al. Work in Progress. [EICK] "Visualizing Software Changes", S.G. Eick, et al, National Institute of Statistical Sciences, Technical Report 113, December 2000. [MOLINERO2002] "TCP Switching: Exposing Circuits to IP", Pablo Molinero-Fernandez and Nick McKeown, IEEE January, 2002. [FLOYD] "The Synchronization of Periodic Routing Messages", 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. [FRALEIGH] "Provisioning IP Backbone Networks to Support Delay- Based Service Level Agreements", Chuck Fraleigh, Fouad Tobagi, and 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. [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. [HOT] J.M. Carlson and John Doyle, Phys. Rev. E 60, 1412- 1427, 1999. [ISO10589] "Intermediate System to Intermediate System Intradomain Routing Exchange Protocol (IS-IS)". [JACOBSON] "Congestion Avoidance and Control", Van Jacobson, Proceedings of 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. [KUHN87] "Sources of Failure in the Public Switched Telephone Network", D. Richard Kuhn, EEE Computer, Vol. 30, No. 4, April, 1997. [L2TPV3] Lan, J., et. al., "Layer Two Tunneling Protocol (Version 3) -- L2TPv3", Work in Progress. [MC2001] "U.S Communications Infrastructure at A Crossroads: Opportunities Amid the Gloom", McKinsey&Company for Goldman-Sachs, August 2001. [MCK2002] Nick McKeown, personal communication, April, 2002. [ML2002] "Optical Systems", Merril Lynch Technical Report, April, 2002. [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. [NEUMANN] "Cause of AT&T network failure", 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. [ODLYZKO98A] "Smart and stupid networks: Why the Internet is like Microsoft". A. M. Odlyzko, ACM Networker, 2(5), December, 1998. [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 [PARK] "The Internet as a Complex System: Scaling, Complexity and Control", Kihong Park and Walter Willinger, AT&T Research, 2002. [PERROW] "Normal Accidents: Living with High Risk Technologies", Basic Books, C. Perrow, New York, 1984. [PMC] "The Design of a 10 Gigabit Core Router Architecture", 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. [RFC1925] Callon, R., "The Twelve Networking Truths", RFC 1925, 1 April 1996. [RFC1958] Carpenter, B., Ed., "Architectural principles of the Internet", RFC 1958, June 1996. [RFC2283] Bates, T., Chandra, R., Katz, D. and Y. Rekhter, "Multiprotocol Extensions for BGP4", RFC 2283, February 1998. [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. [ROMANOV] "Dynamics of TCP over ATM Networks", A. Romanov, S. Floyd, IEEE JSAC, vol. 13, No 4, pp.633-641, May 1995. [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. [SCOTT] "Making Smart Investments to Reduce Unplanned Downtime", D. Scott, Tactical Guidelines, TG-07-4033, Gartner Group Research Note, March 1999. [SPILLMAN] "The Law of Diminishing Returns:, W. J. Spillman and E. Lang, 1924. [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. [THOMPSON] "Nonlinear Dynamics and Chaos". J.M.T. Thompson and 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) [WAKEMAN] "Layering considered harmful", Ian Wakeman, Jon Crowcroft, Zheng Wang, and Dejan Sirovica, IEEE Network, January 1992, 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). [WILLINGER2002] "Robustness and the Internet: Design and evolution", 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. 13. Authors' Addresses 13. 著者のアドレス Randy Bush EMail: rand David Meyer EMail: dm 14. Full Copyright Statement 14. 著作権表示全文 Copyright (C) The Internet Society (2002). All Rights Reserved. 著作権（Ｃ）インターネット学会（２００２）。すべての権利は保留される。 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.
0 件のコメント:
コメントを投稿