[要約] RFC 7980は、ネットワークの複雑さを定義するためのフレームワークであり、ネットワークの設計と管理のためのガイドラインを提供します。目的は、ネットワークの複雑さを理解し、効果的なネットワークの設計と運用を支援することです。
Independent Submission M. Behringer
Request for Comments: 7980 A. Retana
Category: Informational Cisco Systems
ISSN: 2070-1721 R. White
Ericsson
G. Huston
APNIC
October 2016
A Framework for Defining Network Complexity
ネットワークの複雑さを定義するためのフレームワーク
Abstract
概要
Complexity is a widely used parameter in network design, yet there is no generally accepted definition of the term. Complexity metrics exist in a wide range of research papers, but most of these address only a particular aspect of a network, for example, the complexity of a graph or software. While it may be impossible to define a metric for overall network complexity, there is a desire to better understand the complexity of a network as a whole, as deployed today to provide Internet services. This document provides a framework to guide research on the topic of network complexity as well as some practical examples for trade-offs in networking.
複雑さはネットワーク設計で広く使用されているパラメータですが、一般的に受け入れられている用語の定義はありません。複雑さの測定基準はさまざまな研究論文に存在しますが、これらのほとんどは、グラフやソフトウェアの複雑さなど、ネットワークの特定の側面のみを扱います。ネットワーク全体の複雑さのメトリックを定義することは不可能かもしれませんが、インターネットサービスを提供するために現在展開されているように、ネットワーク全体の複雑さをよりよく理解したいという要望があります。このドキュメントは、ネットワークの複雑さのトピックに関する研究を導くためのフレームワークと、ネットワーキングにおけるトレードオフのいくつかの実際的な例を提供します。
This document summarizes the work of the IRTF's Network Complexity Research Group (NCRG) at the time of its closure. It does not present final results, but a snapshot of an ongoing activity, as a basis for future work.
この文書は、IRTFの閉会時のネットワーク複雑性研究グループ（NCRG）の作業をまとめたものです。これは最終結果ではなく、将来の作業の基礎となる進行中のアクティビティのスナップショットです。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFCエディターは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7980.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7980で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. General Considerations . . . . . . . . . . . . . . . . . . . 5
2.1. The Behavior of a Complex Network . . . . . . . . . . . . 5
2.2. Complex versus Complicated . . . . . . . . . . . . . . . 5
2.3. Robust Yet Fragile . . . . . . . . . . . . . . . . . . . 6
2.4. The Complexity Cube . . . . . . . . . . . . . . . . . . . 6
2.5. Related Concepts . . . . . . . . . . . . . . . . . . . . 6
2.6. Technical Debt . . . . . . . . . . . . . . . . . . . . . 7
2.7. Layering Considerations . . . . . . . . . . . . . . . . . 8
3. Trade-Offs . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Control-Plane State versus Optimal Forwarding Paths
(Stretch) . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Configuration State versus Failure Domain Separation . . 10
3.3. Policy Centralization versus Optimal Policy Application . 12
3.4. Configuration State versus Per-Hop Forwarding
Optimization . . . . . . . . . . . . . . . . . . . . . . 13
3.5. Reactivity versus Stability . . . . . . . . . . . . . . . 13
4. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 15
5. Elements of Complexity . . . . . . . . . . . . . . . . . . . 16
5.1. The Physical Network (Hardware) . . . . . . . . . . . . . 16
5.2. Algorithms . . . . . . . . . . . . . . . . . . . . . . . 17
5.3. State in the Network . . . . . . . . . . . . . . . . . . 17
5.4. Churn . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.5. Knowledge . . . . . . . . . . . . . . . . . . . . . . . . 17
6. Location of Complexity . . . . . . . . . . . . . . . . . . . 17
6.1. Topological Location . . . . . . . . . . . . . . . . . . 17
6.2. Logical Location . . . . . . . . . . . . . . . . . . . . 18
6.3. Layering Considerations . . . . . . . . . . . . . . . . . 18
7. Dependencies . . . . . . . . . . . . . . . . . . . . . . . . 18
7.1. Local Dependencies . . . . . . . . . . . . . . . . . . . 19
7.2. Network-Wide Dependencies . . . . . . . . . . . . . . . . 19
7.3. Network-External Dependencies . . . . . . . . . . . . . . 19
8. Management Interactions . . . . . . . . . . . . . . . . . . . 20
8.1. Configuration Complexity . . . . . . . . . . . . . . . . 20
8.2. Troubleshooting Complexity . . . . . . . . . . . . . . . 20
8.3. Monitoring Complexity . . . . . . . . . . . . . . . . . . 20
8.4. Complexity of System Integration . . . . . . . . . . . . 21
9. External Interactions . . . . . . . . . . . . . . . . . . . . 21
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 22
11. Security Considerations . . . . . . . . . . . . . . . . . . . 22
12. Informative References . . . . . . . . . . . . . . . . . . . 22
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
Network design can be described as the art of finding the simplest solution to solve a given problem. Complexity is thus assumed in the design process; engineers do not ask if there should be complexity, but rather, how much complexity is required to solve the problem. The question of how much complexity assumes there is some way to characterize the amount of complexity present in a system. The reality is, however, this is an area of research and experience rather than a solved problem within the network engineering space. Today's design decisions are made based on a rough estimation of the network's complexity rather than a solid understanding.
ネットワーク設計は、与えられた問題を解決するための最も簡単なソリューションを見つける技術として説明できます。したがって、設計プロセスでは複雑さが想定されます。エンジニアは複雑さが必要かどうかを尋ねるのではなく、問題を解決するためにどれだけ複雑が必要かを尋ねます。システムに存在する複雑さの量を特徴付ける方法がいくつかあると仮定して、どれほど複雑さが想定されるかという問題があります。しかし、現実は、ネットワークエンジニアリングスペース内の解決された問題というよりは、研究と経験の領域です。今日の設計の決定は、ネットワークの複雑さの大まかな見積もりに基づいて行われ、しっかりとした理解ではありません。
The document begins with general considerations, including some foundational definitions and concepts. It then provides some examples for trade-offs that network engineers regularly make when designing a network. This section serves to demonstrate that there is no single answer to complexity; rather, it is a managed trade-off between many parameters. After this, this document provides a set of parameters engineers should consider when attempting to either measure complexity or build a framework around it. This list makes no claim to be complete, but it serves as a guide of known existing areas of investigation as well as a pointer to areas that still need to be investigated.
このドキュメントは、いくつかの基本的な定義と概念を含む一般的な考慮事項から始まります。次に、ネットワーク設計者がネットワークを設計するときに定期的に行うトレードオフの例をいくつか示します。このセクションは、複雑さに対する単一の答えがないことを示すのに役立ちます。むしろ、多くのパラメータ間の管理されたトレードオフです。この後、このドキュメントでは、エンジニアが複雑さを測定するか、またはその周りにフレームワークを構築するときに検討する必要がある一連のパラメーターを提供します。このリストは完全であることを主張するものではありませんが、既知の既存の調査領域のガイドとして、また調査が必要な領域へのポインタとして役立ちます。
Two purposes are served here. The first is to guide researchers working in the area of complexity in their work. The more researchers are able to connect their work to the concerns of network designers, the more useful their research will become. This document may also guide research into areas not considered before. The second is to help network engineers to build a better understanding of where complexity might be "hiding" in their networks and to be more fully aware of how complexity interacts with design and deployment.
ここには2つの目的があります。 1つ目は、複雑な作業を行う研究者を指導することです。研究者が自分の研究をネットワーク設計者の懸念に結びつけることができるほど、彼らの研究はより有用になります。このドキュメントは、これまで考慮されていなかった領域の研究をガイドする場合もあります。 2つ目は、ネットワークエンジニアが複雑さがネットワークのどこに「隠れている」かをよりよく理解し、複雑さが設計と展開とどのように相互作用するかをより完全に理解できるようにすることです。
The goal of the IRTF Network Complexity Research Group (NCRG) [ncrg] was to define a framework for network complexity research while recognizing that it may be impossible to define metrics for overall network complexity. This document summarizes the work of this group at the time of its closure in 2014. It does not present final results, but rather a snapshot of an ongoing activity, as a basis for future work.
IRTF Network Complexity Research Group（NCRG）[ncrg]の目標は、ネットワーク全体の複雑さのメトリックを定義することが不可能である可能性があることを認識しながら、ネットワーク複雑度研究のフレームワークを定義することでした。このドキュメントは、2014年の閉鎖時のこのグループの作業をまとめたものです。最終的な結果ではなく、将来の作業の基礎として進行中の活動のスナップショットを示しています。
Many references to existing research in the area of network complexity are listed on the Network Complexity Wiki [wiki]. This wiki also contains background information on previous meetings on the subject, previous research, etc.
ネットワークの複雑性の分野における既存の研究への多くの参照は、Network Complexity Wiki [wiki]にリストされています。このwikiには、このテーマに関する以前の会議、以前の研究などに関する背景情報も含まれています。
While there is no generally accepted definition of network complexity, there is some understanding of the behavior of a complex network. It has some or all of the following properties:
一般的に受け入れられているネットワークの複雑さの定義はありませんが、複雑なネットワークの動作についてはある程度の理解があります。次のプロパティの一部またはすべてがあります。
o Self-Organization: A network runs some protocols and processes without external control; for example, a routing process, failover mechanisms, etc. The interaction of those mechanisms can lead to a complex behavior.
o 自己組織化：ネットワークは、外部制御なしでいくつかのプロトコルとプロセスを実行します。たとえば、ルーティングプロセス、フェイルオーバーメカニズムなど。これらのメカニズムの相互作用により、複雑な動作が発生する可能性があります。
o Unpredictability: In a complex network, the effect of a local change on the behavior of the global network may be unpredictable.
o 予測不可能性：複雑なネットワークでは、ローカルネットワークの変更がグローバルネットワークの動作に与える影響は予測できない場合があります。
o Emergence: The behavior of the system as a whole is not reflected in the behavior of any individual component of the system.
o 出現：システム全体の動作は、システムの個々のコンポーネントの動作には反映されません。
o Non-linearity: An input into the network produces a non-linear result.
o 非線形性：ネットワークへの入力により、非線形の結果が生成されます。
o Fragility: A small local input can break the entire system.
o 脆弱性：ローカル入力が小さいと、システム全体が壊れる可能性があります。
The two terms "complex" and "complicated" are often used interchangeably, yet they describe different but overlapping properties. The RG made the following statements about the two terms, but they would need further refinement to be considered formal definitions:
「複雑な」と「複雑な」という2つの用語はしばしば同じ意味で使用されますが、異なるが重複する特性を表します。 RGは2つの用語について次のように述べていますが、正式な定義と見なされるにはさらに改良が必要です。
o A "complicated" system is a deterministic system that can be understood by an appropriate level of analysis. It is often an externally applied attribute rather than an intrinsic property of a system and is typically associated with systems that require deep or significant levels of analysis.
o 「複雑な」システムは、適切なレベルの分析で理解できる決定論的なシステムです。多くの場合、これはシステムの固有のプロパティではなく、外部から適用される属性であり、通常、深いレベルまたは重要なレベルの分析を必要とするシステムに関連付けられています。
o A "complex" system, by comparison, is an intrinsic property of a system and is typically associated with emergent behaviors such that the behavior of the system is not fully described by the sum of the behavior of each of the components of the system. Complex systems are often associated with systems whose components exhibit high levels of interaction and feedback.
o 対照的に、「複雑な」システムはシステムの本質的な特性であり、通常、システムの動作がシステムの各コンポーネントの動作の合計によって完全に記述されないような緊急動作に関連付けられます。複雑なシステムは、多くの場合、コンポーネントが高いレベルの相互作用とフィードバックを示すシステムに関連付けられています。
Networks typically follow the "robust yet fragile" paradigm: they are designed to be robust against a set of failures, yet they are very vulnerable to other failures. Doyle [Doyle] explains the concept with an example: the Internet is robust against single-component failure but fragile to targeted attacks. The "robust yet fragile" property also touches on the fact that all network designs are necessarily making trade-offs between different design goals. The simplest one is "Good, Fast, Cheap: Pick any two (you can't have all three)", as articulated in "The Twelve Networking Truths" [RFC1925]. In real network design, trade-offs between many aspects have to be made, including, for example, issues of scope, time, and cost in the network cycle of planning, design, implementation, and management of a network platform. Section 3 gives some examples of trade-offs, and parameters are discussed in Section 4.
ネットワークは通常、「堅牢でありながら壊れやすい」パラダイムに従います。ネットワークは一連の障害に対して堅牢になるように設計されていますが、他の障害に対して非常に脆弱です。 Doyle [Doyle]は、概念を例を挙げて説明します。インターネットは単一コンポーネントの障害に対して堅牢ですが、標的型攻撃に対して脆弱です。 「堅牢でありながら壊れやすい」特性は、すべてのネットワーク設計が異なる設計目標間で必然的にトレードオフを行っているという事実にも触れています。 「The Twelve Networking Truths」[RFC1925]で説明されているように、最も単純なものは「Good、Fast、Cheap：2つ選択してください（3つすべてを選択することはできません）」です。実際のネットワーク設計では、たとえば、ネットワークプラットフォームの計画、設計、実装、および管理のネットワークサイクルにおけるスコープ、時間、およびコストの問題など、多くの側面の間でトレードオフを行う必要があります。セクション3ではトレードオフの例をいくつか示し、パラメータについてはセクション4で説明します。
Complex tasks on a network can be done in different components of the network. For example, routing can be controlled by central algorithms and the result distributed (e.g., OpenFlow model); the routing algorithm can also run completely distributed (e.g., routing protocols such as OSPF or IS-IS), or a human operator could calculate routing tables and statically configure routing. Behringer [Behringer] defines these three axes of complexity as a "complexity cube" with the respective axes being network elements, central systems, and human operators. Any function can be implemented in any of these three axes, and this choice likely has an impact on the overall complexity of the system.
ネットワーク上の複雑なタスクは、ネットワークのさまざまなコンポーネントで実行できます。たとえば、ルーティングは中央のアルゴリズムと結果の分散（OpenFlowモデルなど）によって制御できます。ルーティングアルゴリズムは完全に分散して実行することもできます（たとえば、OSPFやIS-ISなどのルーティングプロトコル）、または人間のオペレーターがルーティングテーブルを計算して静的にルーティングを構成することもできます。 Behringer [Behringer]は、これらの3つの複雑な軸を「複雑さの立方体」として定義します。それぞれの軸は、ネットワーク要素、中央システム、および人間のオペレーターです。これらの3つの軸のいずれにも任意の機能を実装できます。この選択は、システム全体の複雑さに影響を与える可能性があります。
When discussing network complexity, a large number of influencing factors have to be taken into account to arrive at a full picture, for example:
ネットワークの複雑さについて説明する場合、全体像を把握するには、多数の影響要因を考慮する必要があります。次に例を示します。
o State in the Network: Contains the network elements, such as routers, switches (with their OS, including protocols), lines, central systems, etc. This also includes the number and algorithmic complexity of the protocols on network devices.
o ネットワーク内の状態：ルーター、スイッチ（OSとプロトコルを含む）、回線、中央システムなどのネットワーク要素が含まれます。これには、ネットワークデバイス上のプロトコルの数とアルゴリズムの複雑さも含まれます。
o Human Operators: Complexity manifests itself often by a network that is not completely understood by human operators. Human error is a primary source for catastrophic failures and therefore must be taken into account.
o 人間のオペレーター：複雑さは、人間のオペレーターによって完全には理解されていないネットワークによってしばしば現れます。人為的エラーは壊滅的な障害の主な原因であり、したがって考慮に入れる必要があります。
o Classes/Templates: Rather than counting the number of lines in a configuration or the number of hardware elements, more important is the number of classes from which those can be derived. In other words, it is probably less complex to have 1000 interfaces that are identically configured than 5 that are configured completely different.
o クラス/テンプレート：構成の行数やハードウェア要素の数をカウントするのではなく、それらを導出できるクラスの数がより重要です。言い換えれば、まったく同じように構成された1000個のインターフェースを、完全に異なる構成の5個のインターフェースよりも複雑にする必要はおそらくないでしょう。
o Dependencies and Interactions: The number of dependencies between elements, as well as the interactions between them, has influence on the complexity of the network.
o 依存関係と相互作用：要素間の依存関係の数、および要素間の相互作用は、ネットワークの複雑さに影響を与えます。
o Total Cost of Ownership (TCO): TCO could be a good metric for network complexity if the TCO calculation takes into account all influencing factors, for example, training time for staff to be able to maintain a network.
o 総所有コスト（TCO）：TCOの計算に影響を与えるすべての要因（スタッフがネットワークを維持できるようにするためのトレーニング時間など）を考慮に入れる場合、TCOはネットワークの複雑さの良い指標になる可能性があります。
o Benchmark Unit Cost (BUC): BUC is a related metric that indicates the cost of operating a certain component. If calculated well, it reflects at least parts of the complexity of this component. Therefore, the way TCO or BUC is calculated can help to derive a complexity metric.
o ベンチマークユニットコスト（BUC）：BUCは、特定のコンポーネントの運用コストを示す関連メトリックです。うまく計算すると、このコンポーネントの複雑さの少なくとも一部が反映されます。したがって、TCOまたはBUCの計算方法は、複雑さの指標を導き出すのに役立ちます。
o Churn / Rate of Change: The change rate in a network itself can contribute to complexity, especially if a number of components of the overall network interact.
o チャーン/変化率：ネットワーク自体の変化率は、特にネットワーク全体の多数のコンポーネントが相互作用する場合に、複雑さに影響を与える可能性があります。
Networks differ in terms of their intended purpose (such as is found in differences between enterprise and public carriage network platforms) and differences in their intended roles (such as is found in the differences between so-called "access" networks and "core" transit networks). The differences in terms of role and purpose can often lead to differences in the tolerance for, and even the metrics of, complexity within such different network scenarios. This is not necessarily a space where a single methodology for measuring complexity, and defining a single threshold value of acceptability of complexity, is appropriate.
ネットワークは、意図された目的（企業と公共輸送ネットワークプラットフォームの違いなど）と意図された役割の違い（いわゆる「アクセス」ネットワークと「コア」トランジットの違いなど）の点で異なります。ネットワーク）。役割と目的の違いは、多くの場合、そのような異なるネットワークシナリオ内の複雑さの許容度の違い、さらには複雑さの測定基準の違いにつながる可能性があります。これは必ずしも、複雑さを測定し、複雑さの許容範囲の単一のしきい値を定義するための単一の方法論が適切である空間ではありません。
Many changes in a network are made with a dependency on the existing network. Often, a suboptimal decision is made because the optimal decision is hard or impossible to realize at the time. Over time, the number of suboptimal changes in themselves cause significant complexity, which would not have been there had the optimal solution been implemented.
ネットワークの多くの変更は、既存のネットワークに依存して行われます。多くの場合、最適な決定は現時点では実現が困難または不可能であるため、次善の決定が行われます。時間の経過とともに、最適化されていない変更の数自体が非常に複雑になり、最適なソリューションが実装されていなかった場合は、複雑になります。
The term "technical debt" refers to the accumulated complexity of suboptimal changes over time. As with financial debt, the idea is that also technical debt must be repaid one day by cleaning up the network or software.
「技術的負債」という用語は、時間の経過とともに次善の変化が蓄積する複雑さを指します。金融債務と同様に、技術的な債務も、ネットワークまたはソフトウェアをクリーンアップすることにより、いつか返済しなければならないという考えです。
In considering the larger space of applications, transport services, network services, and media services, it is feasible to engineer responses for certain types of desired applications responses in many different ways and involving different layers of the so-called network protocol stack. For example, Quality of Service (QoS) could be engineered at any of these layers or even in a number of combinations of different layers.
アプリケーション、トランスポートサービス、ネットワークサービス、およびメディアサービスのより大きなスペースを考慮すると、いわゆるネットワークプロトコルスタックのさまざまなレイヤーを使用して、さまざまな方法で特定のタイプの目的のアプリケーション応答の応答を設計することができます。たとえば、サービスの品質（QoS）は、これらのレイヤーのいずれかで、または異なるレイヤーのいくつかの組み合わせで設計することもできます。
Considerations of complexity arise when mutually incompatible measures are used in combination (such as error detection and retransmission at the media layer in conjunction with the use of TCP transport protocol) or when assumptions used in one layer are violated by another layer. This results in surprising outcomes that may result in complex interactions, for example, oscillation, because different layers use different timers for retransmission. These issues have led to the perspective that increased layering frequently increases complexity [RFC3439].
複雑さの考慮事項は、相互に互換性のない測定を組み合わせて使用する場合（TCPトランスポートプロトコルの使用に関連するメディアレイヤーでのエラー検出と再送信など）、または1つのレイヤーで使用される前提が別のレイヤーに違反している場合に発生します。これにより、異なる層が再送信に異なるタイマーを使用するため、複雑な相互作用、たとえば発振を引き起こす可能性のある驚くべき結果がもたらされます。これらの問題は、階層化の増加がしばしば複雑さを増すという見方につながりました[RFC3439]。
While this research work is focused on network complexity, the interactions of the network with the end-to-end transport protocols, application layer protocols, and media properties are relevant considerations here.
この研究作業はネットワークの複雑さに焦点を当てていますが、ネットワークとエンドツーエンドのトランスポートプロトコル、アプリケーション層プロトコル、およびメディアプロパティとの相互作用は、ここで関連する考慮事項です。
Network complexity is a system-level, rather than component-level, problem; overall system complexity may be more than the sum of the complexity of the individual pieces.
ネットワークの複雑さは、コンポーネントレベルではなく、システムレベルの問題です。システム全体の複雑さは、個々の要素の複雑さの合計よりも大きい場合があります。
There are two basic ways in which system-level problems might be addressed: interfaces and continuums. In addressing a system-level problem through interfaces, we seek to treat each piece of the system as a "black box" and develop a complete understanding of the interfaces between these black boxes. In addressing a system-level problem as a continuum, we seek to understand the impact of a single change or element to the entire system as a set of trade-offs.
システムレベルの問題に対処するには、インターフェイスと継続の2つの基本的な方法があります。インターフェイスを介してシステムレベルの問題に対処する際、システムの各部分を「ブラックボックス」として扱い、これらのブラックボックス間のインターフェイスを完全に理解するよう努めます。システムレベルの問題を連続体として扱う場合、システム全体に対する単一の変更または要素の影響を一連のトレードオフとして理解することを目指します。
While network complexity can profitably be approached from either of these perspectives, in this document we have chosen to approach the system-level impact of network complexity from the perspective of continuums of trade-offs. In theory, modifying the network to resolve one particular problem (or class of problems) will add complexity that results in the increased likelihood (or appearance) of another class of problems. Discovering these continuums of trade-offs, and then determining how to measure each one, become the key steps in understanding and measuring system-level complexity in this view.
ネットワークの複雑さは、これらの観点のどちらからでも有利にアプローチできますが、このドキュメントでは、トレードオフの連続性の観点から、ネットワークの複雑さのシステムレベルの影響にアプローチすることを選択しました。理論的には、1つの特定の問題（または問題のクラス）を解決するためにネットワークを変更すると、複雑さが増し、別のクラスの問題の可能性（または外観）が増加します。これらのトレードオフの連続性を発見し、それぞれを測定する方法を決定することは、このビューでシステムレベルの複雑さを理解および測定するための重要なステップになります。
The following sections describe five such continuums; more may be possible.
次のセクションでは、このような5つの連続性について説明します。もっと可能かもしれません。
o Control-Plane State versus Optimal Forwarding Paths (or its opposite measure, stretch)
o コントロールプレーンの状態と最適な転送パス（またはその逆の測定、ストレッチ）
o Configuration State versus Failure Domain Separation
o 構成状態と障害ドメインの分離
o Policy Centralization versus Optimal Policy Application
o ポリシーの集中化と最適なポリシーの適用
o Configuration State versus Per-Hop Forwarding Optimization
o 構成状態とホップごとの転送の最適化
o Reactivity versus Stability
o 反応性対安定性
Control-plane state is the aggregate amount of information carried by the control plane through the network in order to produce the forwarding table at each device. Each additional piece of information added to the control plane -- such as more-specific reachability information, policy information, additional control planes for virtualization and tunneling, or more precise topology information -- adds to the complexity of the control plane. This added complexity, in turn, adds to the burden of monitoring, understanding, troubleshooting, and managing the network.
コントロールプレーンの状態は、各デバイスで転送テーブルを作成するために、ネットワークを介してコントロールプレーンによって伝送される情報の総量です。より具体的な到達可能性情報、ポリシー情報、仮想化とトンネリングのための追加のコントロールプレーン、またはより正確なトポロジー情報など、コントロールプレーンに追加される各情報は、コントロールプレーンの複雑さを増します。このように複雑さが増すと、ネットワークの監視、理解、トラブルシューティング、および管理の負担が増えます。
Removing control-plane state, however, is not always a net positive gain for the network as a system; removing control-plane state almost always results in decreased optimality in the forwarding and handling of packets traveling through the network. This decreased optimality can be termed "stretch", which is defined as the difference between the absolute shortest (or best) path traffic could take through the network and the path the traffic actually takes. Stretch is expressed as the difference between the optimal and actual path. The figure below provides an example of this trade-off.
ただし、コントロールプレーンの状態を削除しても、システムとしてのネットワークの正の利益が常に得られるとは限りません。コントロールプレーンの状態を削除すると、ほとんどの場合、ネットワークを通過するパケットの転送と処理の最適性が低下します。この最適性の低下は「ストレッチ」と呼ばれ、ネットワークを通過する可能性のある絶対最短（または最良）のパスと、トラフィックが実際に通過するパスとの差として定義されます。ストレッチは、最適パスと実際のパスの差として表されます。次の図は、このトレードオフの例を示しています。
+---R1---+
| |
(aggregate: 192.0.2/24) R2 R3 (aggregate: 192.0.2/24)
| |
R4-------R5
|
(announce: 192.0.2.1/32) R6
Assume each link is of equal cost in this figure and that R6 is advertising 192.0.2.1/32.
この図では、各リンクのコストが同じで、R6が192.0.2.1/32をアドバタイズしていると想定しています。
For R1, the shortest path to 192.0.2.1/32, advertised by R6, is along the path [R1,R2,R4,R6].
R1の場合、R6によってアドバタイズされる192.0.2.1/32への最短パスは、パス[R1、R2、R4、R6]に沿っています。
Assume, however, the network administrator decides to aggregate reachability information at R2 and R3, advertising 192.0.2.0/24 towards R1 from both of these points. This reduces the overall complexity of the control plane by reducing the amount of information carried past these two routers (at R1 only in this case).
ただし、ネットワーク管理者がR2とR3で到達可能性情報を集約し、これらの両方のポイントからR1に向けて192.0.2.0/24をアドバタイズすると決定したとします。これにより、これら2つのルーターを介して（この場合はR1でのみ）伝送される情報量が減るため、コントロールプレーンの全体的な複雑さが軽減されます。
Aggregating reachability information at R2 and R3, however, may have the impact of making both routes towards 192.0.2.1/32 appear as equal cost paths to R1; there is no particular reason R1 should choose the shortest path through R2 over the longer path through R3. This, in effect, increases the stretch of the network. The shortest path from R1 to R6 is 3 hops, a path that will always be chosen before aggregation is configured. Assuming half of the traffic will be forwarded along the path through R2 (3 hops), and half through R3 (4 hops), the network is stretched by ((3+4)/2) - 3), or .5, a "half a hop".
ただし、R2とR3で到達可能性情報を集約すると、192.0.2.1 / 32への両方のルートがR1への等コストパスとして表示されるという影響がある場合があります。 R1がR3を通る長いパスよりもR2を通る最短のパスを選択する特別な理由はありません。これにより、事実上、ネットワークの範囲が拡大します。 R1からR6への最短パスは3ホップです。これは、集約が構成される前に常に選択されるパスです。トラフィックの半分がR2（3ホップ）を介してパスに沿って転送され、半分がR3（4ホップ）を介して転送されると仮定すると、ネットワークは（（3 + 4）/ 2）-3）、または.5、a 「ハーフホップ」。
Traffic engineering through various tunneling mechanisms is, at a broad level, adding control-plane state to provide more optimal forwarding (or network utilization). Optimizing network utilization may require detuning stretch (intentionally increasing stretch) to increase overall network utilization and efficiency; this is simply an alternate instance of control-plane state (and hence, complexity) weighed against optimal forwarding through the network.
さまざまなトンネリングメカニズムによるトラフィックエンジニアリングは、広いレベルで、コントロールプレーンの状態を追加して、より最適な転送（またはネットワーク利用）を提供します。ネットワーク使用率を最適化するには、全体的なネットワーク使用率と効率を向上させるために、デチューニングストレッチ（意図的にストレッチを増やす）が必要になる場合があります。これは、ネットワークを介した最適な転送と比較して、単にコントロールプレーンの状態（したがって複雑さ）の代替インスタンスです。
A failure domain, within the context of a network control plane, can be defined as the set of devices impacted by a change in the network topology or configuration. A network with larger failure domains is more prone to cascading failures, so smaller failure domains are normally preferred over larger ones.
障害ドメインは、ネットワークコントロールプレーンのコンテキスト内で、ネットワークトポロジまたは構成の変更によって影響を受けるデバイスのセットとして定義できます。大きな障害ドメインを持つネットワークは、カスケード障害になりやすいため、通常、大きな障害ドメインよりも小さな障害ドメインが優先されます。
The primary means used to limit the size of a failure domain within a network's control plane is information hiding; the two primary types of information hidden in a network control plane are reachability information and topology information. An example of aggregating reachability information is summarizing the routes 192.0.2.1/32, 192.0.2.2/32, and 192.0.2.3/32 into the single route 192.0.2.0/24, along with the aggregation of the metric information associated with each of the component routes. Note that aggregation is a "natural" part of IP networks, starting with the aggregation of individual hosts into a subnet at the network edge. An example of topology aggregation is the summarization of routes at a link-state flooding domain boundary, or the lack of topology information in a distance-vector protocol.
ネットワークのコントロールプレーン内の障害ドメインのサイズを制限するために使用される主な手段は、情報の隠蔽です。ネットワークコントロールプレーンに隠されている2つの主要なタイプの情報は、到達可能性情報とトポロジ情報です。到達可能性情報の集約の例として、ルート192.0.2.1/32、192.0.2.2/32、および192.0.2.3/32を単一のルート192.0.2.0/24に集約し、それぞれに関連付けられているメトリック情報を集約しています。コンポーネントのルート。集約はIPネットワークの「自然な」部分であり、個々のホストをネットワークエッジのサブネットに集約することから始まることに注意してください。トポロジ集約の例は、リンクステートフラッディングドメイン境界でのルートの要約、または距離ベクトルプロトコルのトポロジ情報の欠落です。
While limiting the size of failure domains appears to be an absolute good in terms of network complexity, there is a definite trade-off in configuration complexity. The more failure domain edges created in a network, the more complex configuration will become. This is particularly true if redistribution of routing information between multiple control-plane processes is used to create failure domain boundaries; moving between different types of control planes causes a loss of the consistent metrics most control planes rely on to build loop-free paths. Redistribution, in particular, opens the door to very destructive positive feedback loops within the control plane. Examples of control-plane complexity caused by the creation of failure domain boundaries include route filters, routing aggregation configuration, and metric modifications to engineer traffic across failure domain boundaries.
障害ドメインのサイズを制限することは、ネットワークの複雑さの点では絶対的に良いように見えますが、構成の複雑さには明確なトレードオフがあります。ネットワークで作成される障害ドメインエッジが多いほど、構成はより複雑になります。これは、複数のコントロールプレーンプロセス間でルーティング情報を再配布して、障害ドメインの境界を作成する場合に特に当てはまります。異なるタイプのコントロールプレーン間を移動すると、ほとんどのコントロールプレーンがループのないパスの構築に依存している一貫したメトリックが失われます。特に再配布は、コントロールプレーン内の非常に破壊的な正のフィードバックループへの扉を開きます。障害ドメインの境界の作成によって引き起こされるコントロールプレーンの複雑さの例には、ルートフィルター、ルーティング集約構成、および障害ドメインの境界を越えてトラフィックを処理するためのメトリックの変更が含まれます。
Returning to the network described in the previous section, aggregating routing information at R2 and R3 will divide the network into two failure domains: (R1, R2, R3) and (R2, R3, R4, R5). A failure at R5 should have no impact on the forwarding information at R1.
前のセクションで説明したネットワークに戻り、R2とR3でルーティング情報を集約すると、ネットワークが2つの障害ドメイン（R1、R2、R3）と（R2、R3、R4、R5）に分割されます。 R5で障害が発生しても、R1の転送情報に影響はありません。
A false failure domain separation occurs, however, when the metric of the aggregate route advertised by R2 and R3 is dependent on one of the routes within the aggregate. For instance, if the metric of the 192.0.2.0/24 aggregate is derived from the metric of the component 192.0.2.1/32, then a failure of this one component will cause changes in the forwarding table at R1 -- in this case, the control plane has not truly been separated into two distinct failure domains. The added complexity in the illustration network would be the management of the configuration required to aggregate the control-plane information, and the management of the metrics to ensure the control plane is truly separated into two distinct failure domains.
ただし、R2およびR3によってアドバタイズされた集約ルートのメトリックが集約内のルートの1つに依存している場合、誤った障害ドメイン分離が発生します。たとえば、192.0.2.0 / 24アグリゲートのメトリックがコンポーネント192.0.2.1/32のメトリックから派生している場合、この1つのコンポーネントで障害が発生すると、R1の転送テーブルが変更されます。この場合、コントロールプレーンは、実際には2つの異なる障害ドメインに分離されていません。図のネットワークでさらに複雑になるのは、コントロールプレーン情報を集約するために必要な構成の管理と、コントロールプレーンが2つの異なる障害ドメインに確実に分離されるようにするためのメトリックの管理です。
Replacing aggregation with redistribution adds the complexity of managing the feedback of routing information redistributed between the failure domains. For instance, if R1, R2, and R3 were configured to run one routing protocol while R2, R3, R4, R5, and R6 were configured to run another protocol, R2 and R3 could be configured to redistribute reachability information between these two control planes. This can split the control plane into multiple failure domains (depending on how, specifically, redistribution is configured) but at the cost of creating and managing the redistribution configuration. Further, R3 must be configured to block routing information redistributed at R2 towards R1 from being redistributed (again) towards R4 and R5.
集約を再配布に置き換えると、障害ドメイン間で再配布されるルーティング情報のフィードバックの管理が複雑になります。たとえば、R1、R2、およびR3が1つのルーティングプロトコルを実行するように構成され、R2、R3、R4、R5、およびR6が別のプロトコルを実行するように構成されている場合、R2およびR3はこれら2つのコントロールプレーン間で到達可能性情報を再配布するように構成できます。 。これにより、コントロールプレーンを複数の障害ドメインに分割できます（具体的には、再配布の構成方法によって異なります）。ただし、再配布構成の作成と管理は犠牲になります。さらに、R3は、R2からR1に向けて再配布されたルーティング情報が、R4およびR5に向けて（再度）再配布されないように構成する必要があります。
Another broad area where control-plane complexity interacts with optimal network utilization is QoS. Two specific actions are required to optimize the flow of traffic through a network: marking and Per Hop Behaviors (PHBs). Rather than examining each packet at each forwarding device in a network, packets are often marked, or classified, in some way (typically through Type of Service bits) so they can be handled consistently at all forwarding devices.
コントロールプレーンの複雑さが最適なネットワーク使用率と相互作用するもう1つの広い領域はQoSです。ネットワークを介したトラフィックのフローを最適化するには、マーキングとホップごとの動作（PHB）の2つの特定のアクションが必要です。ネットワーク内の各転送デバイスで各パケットを検査するのではなく、何らかの方法で（通常はType of Serviceビットを介して）パケットをマークまたは分類し、すべての転送デバイスで一貫して処理できるようにします。
Packet-marking policies must be configured on specific forwarding devices throughout the network. Distributing marking closer to the edge of the network necessarily means configuring and managing more devices, but it produces optimal forwarding at a larger number of network devices. Moving marking towards the network core means packets are marked for proper handling across a smaller number of devices. In the same way, each device through which a packet passes with the correct PHBs configured represents an increase in the consistency in packet handling through the network as well as an increase in the number of devices that must be configured and managed for the correct PHBs. The network below is used for an illustration of this concept.
パケットマーキングポリシーは、ネットワーク全体の特定の転送デバイスで構成する必要があります。マーキングをネットワークのエッジに近づけて配信すると、必然的に、より多くのデバイスを構成および管理することになりますが、より多くのネットワークデバイスで最適な転送が行われます。マーキングをネットワークコアに向けて移動するということは、少数のデバイスでパケットを適切に処理できるようにマークを付けることを意味します。同様に、正しいPHBが構成された状態でパケットが通過する各デバイスは、ネットワークを介したパケット処理の一貫性の向上と、正しいPHBのために構成および管理する必要のあるデバイスの数の増加を表しています。以下のネットワークは、この概念の説明に使用されます。
+----R1----+
| |
+--R2--+ +--R3--+
| | | |
R4 R5 R6 R7
In this network, marking and PHB configuration may be configured on any device, R1 through R7.
このネットワークでは、マーキングとPHB構成は、R1からR7までの任意のデバイスで構成できます。
Assume marking is configured at the network edge; in this case, four devices (R4, R5, R6, R7) must be configured, including ongoing configuration management, to mark packets. Moving packet marking to R2 and R3 will halve the number of devices on which packet-marking configuration must be managed, but at the cost of inconsistent packet handling at the inbound interfaces of R2 and R3 themselves.
マーキングがネットワークエッジで設定されていると想定します。この場合、4つのデバイス（R4、R5、R6、R7）を構成し、継続的な構成管理を含めて、パケットにマークを付ける必要があります。パケットマーキングをR2およびR3に移動すると、パケットマーキング構成を管理する必要があるデバイスの数が半分になりますが、R2およびR3自体の受信インターフェイスでのパケット処理の一貫性が失われます。
Thus, reducing the number of devices that must have managed configurations for packet marking will reduce optimal packet flow through the network. Assuming packet marking is actually configured along the edge of this network, configuring PHBs on different devices has this same trade-off of managed configuration versus optimal traffic flow. If the correct PHBs are configured on R1, R2, and R3, then packets passing through the network will be handled correctly at each hop. The cost involved will be the management of PHB configuration on three devices. Configuring a single device for the correct PHBs (R1, for instance), will decrease the amount of configuration management required at the cost of less than optimal packet handling along the entire path.
したがって、パケットマーキングの管理構成が必要なデバイスの数を減らすと、ネットワークを介した最適なパケットフローが減少します。パケットマーキングがこのネットワークのエッジに沿って実際に構成されていると仮定すると、さまざまなデバイスでPHBを構成すると、管理された構成と最適なトラフィックフローのトレードオフが同じになります。 R1、R2、およびR3で正しいPHBが構成されている場合、ネットワークを通過するパケットは各ホップで正しく処理されます。関係するコストは、3つのデバイスでのPHB構成の管理です。正しいPHB（R1など）用に単一のデバイスを構成すると、パス全体で最適なパケット処理が行われずに、必要な構成管理の量が減少します。
The number of PHBs configured along a forwarding path exhibits the same complexity versus optimality trade-off described in the section above. The more classes (or queues) traffic is divided into, the more fine-grained traffic will be managed as it passes through the network. At the same time, each class of service must be managed, both in terms of configuration and in its interaction with other classes of service configured in the network.
転送パスに沿って構成されたPHBの数は、上記のセクションで説明したのと同じ複雑さと最適性のトレードオフを示します。トラフィックが分割されるクラス（またはキュー）が多いほど、トラフィックがネットワークを通過するときに管理されるトラフィックがきめ細かくなります。同時に、各サービスクラスは、構成の面でも、ネットワークで構成された他のサービスクラスとの相互作用の面でも管理する必要があります。
The speed at which the network's control plane can react to a change in configuration or topology is an area of widespread study. Control-plane convergence can be broken down into four essential parts:
ネットワークのコントロールプレーンが構成またはトポロジの変更に反応できる速度は、広く研究されている分野です。コントロールプレーンの収束は、次の4つの重要な部分に分類できます。
o Detecting the change
o 変化の検出
o Propagating information about the change
o 変更に関する情報の伝達
o Determining the best path(s) through the network after the change
o 変更後のネットワークを介した最適なパスの決定
o Changing the forwarding path at each network element along the modified paths
o 変更されたパスに沿って各ネットワーク要素の転送パスを変更する
Each of these areas can be addressed in an effort to improve network convergence speeds; some of these improvements come at the cost of increased complexity.
これらの各領域は、ネットワークの収束速度を向上させるために取り組むことができます。これらの改善の一部は、複雑さが増すという犠牲を払っています。
Changes in network topology can be detected much more quickly through faster echo (or hello) mechanisms, lower-layer physical detection, and other methods. Each of these mechanisms, however, can only be used at the cost of evaluating and managing false positives and high rates of topology change.
より高速なエコー（またはHello）メカニズム、下位層の物理検出、およびその他の方法により、ネットワークトポロジの変更をはるかに迅速に検出できます。ただし、これらの各メカニズムを使用できるのは、誤検知とトポロジ変更の頻度が高いことを評価および管理するという犠牲を払った場合のみです。
If the state of a link change can be detected in 10 ms, for instance, the link could theoretically change state 50 times in a second -- it would be impossible to tune a network control plane to react to topology changes at this rate. Injecting topology change information into the control plane at this rate can destabilize the control plane, and hence the network itself. To counter this, most techniques that quickly detect link-down events include some form of dampening mechanism; configuring and managing these dampening mechanisms increases complexity.
たとえば、リンクの変化の状態を10ミリ秒で検出できる場合、理論的にはリンクが1秒間に50回状態を変化させる可能性があります。この速度でトポロジの変化に対応するようにネットワークコントロールプレーンを調整することは不可能です。この速度でトポロジ変更情報をコントロールプレーンに注入すると、コントロールプレーンが不安定になり、ネットワーク自体が不安定になる可能性があります。これに対抗するために、リンクダウンイベントをすばやく検出するほとんどの手法には、何らかの形の減衰メカニズムが含まれています。これらのダンプニングメカニズムを構成および管理すると、複雑さが増します。
Changes in network topology must also be propagated throughout the network so each device along the path can compute new forwarding tables. In high-speed network environments, propagation of routing information changes can take place in tens of milliseconds, opening the possibility of multiple changes being propagated per second. Injecting information at this rate into the control plane creates the risk of overloading the processes and devices participating in the control plane as well as creating destructive positive feedback loops in the network. To avoid these consequences, most control-plane protocols regulate the speed at which information about network changes can be transmitted by any individual device. A recent innovation in this area is using exponential backoff techniques to manage the rate at which information is advertised into the control plane; the first change is transmitted quickly, while subsequent changes are transmitted more slowly. These techniques all control the destabilizing effects of rapid information flows through the control plane through the added complexity of configuring and managing the rate at which the control plane can propagate information about network changes.
パスに沿った各デバイスが新しい転送テーブルを計算できるように、ネットワークトポロジの変更もネットワーク全体に伝播する必要があります。高速ネットワーク環境では、ルーティング情報の変更が数十ミリ秒で反映されるため、1秒間に複数の変更が反映される可能性があります。この速度で情報をコントロールプレーンに注入すると、コントロールプレーンに参加しているプロセスとデバイスに過負荷がかかり、ネットワークに破壊的な正のフィードバックループが発生するリスクが生じます。これらの結果を回避するために、ほとんどのコントロールプレーンプロトコルは、ネットワークの変更に関する情報を個々のデバイスが送信できる速度を調整します。この領域における最近の革新は、指数バックオフ技術を使用して、情報がコントロールプレーンにアドバタイズされるレートを管理することです。最初の変更はすぐに送信され、その後の変更はよりゆっくりと送信されます。これらの手法はすべて、コントロールプレーンがネットワークの変更に関する情報を伝達する速度を構成および管理するという複雑さを追加することにより、コントロールプレーンを介した高速情報フローの不安定化効果を制御します。
All control planes require some form of algorithmic calculation to find the best path through the network to any given destination. These algorithms are often lightweight but they still require some amount of memory and computational power to execute. Rapid changes in the network can overwhelm the devices on which these algorithms run, particularly if changes are presented more quickly than the algorithm can run. Once a device running these algorithms becomes processor or memory bound, it could experience a computational failure altogether, causing a more general network outage. To prevent computational overloading, control-plane protocols are designed with timers limiting how often they can compute the best path through a network; often these timers are exponential in nature and thus allow the first computation to run quickly while delaying subsequent computations. Configuring and managing these timers is another source of complexity within the network.
すべてのコントロールプレーンは、特定の宛先へのネットワークを介した最適なパスを見つけるために、何らかの形のアルゴリズム計算を必要とします。これらのアルゴリズムは多くの場合軽量ですが、実行するにはある程度のメモリと計算能力が必要です。ネットワークの急激な変化は、特にアルゴリズムが実行できるよりも速い速度で変更が提示される場合、これらのアルゴリズムが実行されるデバイスを圧倒する可能性があります。これらのアルゴリズムを実行しているデバイスがプロセッサまたはメモリにバインドされると、全体として計算エラーが発生し、より一般的なネットワーク障害が発生する可能性があります。計算の過負荷を防ぐために、コントロールプレーンプロトコルはタイマーを使用して設計されており、ネットワークを介して最適なパスを計算できる頻度を制限します。多くの場合、これらのタイマーは本質的に指数関数的であるため、後続の計算を遅らせながら最初の計算を迅速に実行できます。これらのタイマーの構成と管理は、ネットワーク内の複雑さのもう1つの原因です。
Another option to improve the speed at which the control plane reacts to changes in the network is to precompute alternate paths at each device and possibly preinstall forwarding information into local forwarding tables. Additional state is often needed to precompute alternate paths, and additional algorithms and techniques are often configured and deployed. This additional state, and these additional algorithms, add some amount of complexity to the configuration and management of the network.
コントロールプレーンがネットワークの変化に反応する速度を向上させる別のオプションは、各デバイスで代替パスを事前計算し、場合によっては転送情報をローカル転送テーブルに事前インストールすることです。多くの場合、代替パスを事前計算するために追加の状態が必要です。追加のアルゴリズムと手法が構成されて展開されることがよくあります。この追加の状態とこれらの追加のアルゴリズムにより、ネットワークの構成と管理がある程度複雑になります。
In some situations (for some topologies), a tunnel is required to pass traffic around a network failure or topology change. These tunnels, while not manually configured, represent additional complexity at the forwarding and control planes.
一部の状況（一部のトポロジー）では、ネットワーク障害またはトポロジー変更の周囲のトラフィックを通過させるためにトンネルが必要です。これらのトンネルは、手動で構成されていませんが、転送プレーンとコントロールプレーンの複雑さが増しています。
In Section 3, we describe a set of trade-offs in network design to illustrate the practical choices network operators have to make. The amount of parameters to consider in such trade-off scenarios is very large, and thus a complete listing may not be possible. Also, the dependencies between the various metrics themselves is very complex and requires further study. This document attempts to define a methodology and an overall high-level structure.
セクション3では、ネットワーク設計における一連のトレードオフについて説明し、ネットワークオペレーターが行う必要のある実際的な選択を示します。このようなトレードオフのシナリオで検討するパラメーターの量は非常に多いため、完全なリストを作成できない場合があります。また、さまざまなメトリック間の依存関係自体も非常に複雑であり、さらに調査する必要があります。このドキュメントでは、方法論と全体的な高レベルの構造を定義しようとしています。
To analyze trade-offs it is necessary to formalize them. The list of parameters for such trade-offs is long, and the parameters can be complex in themselves. For example, "cost" can be a simple unidimensional metric, but "extensibility" and "optimal forwarding state" are harder to define in detail.
トレードオフを分析するには、それらを形式化する必要があります。このようなトレードオフのパラメーターのリストは長く、パラメーター自体が複雑になる可能性があります。たとえば、「コスト」は単純な1次元のメトリックにすることができますが、「拡張性」と「最適な転送状態」を詳細に定義することは困難です。
A list of parameters to trade off contains metrics such as:
トレードオフするパラメーターのリストには、次のようなメトリックが含まれています。
o State: How much state needs to be held in the control plane, forwarding plane, configuration, etc.?
o 状態：コントロールプレーン、転送プレーン、構成などで保持する必要のある状態の量。
o Cost: How much does the network cost to build and run (i.e., capital expenditure (capex) and operating expenses (opex))?
o コスト：ネットワークを構築して実行するためのコスト（つまり、設備投資（設備投資）と運用コスト（運用））はどれくらいですか？
o Bandwidth/Delay/Jitter: Traffic characteristics between two points (average, max, etc.)
o 帯域幅/遅延/ジッター：2点間のトラフィック特性（平均、最大など）
o Configuration Complexity: How hard is it to configure and maintain the configuration?
o 構成の複雑さ：構成を構成および維持するのはどれほど難しいですか？
o Susceptibility to Denial of Service: How easy is it to attack the service?
o サービス拒否の脆弱性：サービスへの攻撃はどれほど簡単ですか？
o Security (Confidentiality/Integrity): How easy is it to sniff/modify/insert the data flow?
o セキュリティ（機密性/整合性）：データフローの傍受/変更/挿入はどれほど簡単ですか？
o Scalability: To what size can I grow the network/service?
o スケーラビリティ：ネットワーク/サービスをどのくらいのサイズまで拡張できますか？
o Stability: How stable is the network under the influence of local change?
o 安定性：地域の変化の影響下でネットワークはどの程度安定していますか？
o Reactivity: How fast does the network converge or adapt to new situations?
o 反応性：ネットワークはどのくらい速く収束し、新しい状況に適応しますか？
o Extensibility: Can I use the network for other services in the future?
o 拡張性：今後、他のサービスにネットワークを使用できますか？
o Ease of Troubleshooting: Are failure domains separated? How hard is it to find and correct problems?
o トラブルシューティングの容易さ：障害ドメインは分離されていますか？問題を見つけて修正するのはどれほど難しいですか？
o Optimal Per-Hop Forwarding Behavior
o 最適なホップごとの転送動作
o Predictability: If I change a parameter, what will happen?
o 予測可能性：パラメーターを変更するとどうなりますか？
o Clean Failure: When a problem arises, does the root cause lead to deterministic failure?
o クリーンエラー：問題が発生した場合、根本原因は確定的なエラーにつながりますか？
Complexity can be found in various elements in a networked system. For example, the configuration of a network element reflects some of the complexity contained in this system, or an algorithm used by a protocol may be more or less complex. When classifying complexity, "WHAT is complex?" is the first question to ask. This section offers a method to answer this question.
複雑さは、ネットワーク化されたシステムのさまざまな要素に見られます。たとえば、ネットワーク要素の構成は、このシステムに含まれる複雑さの一部を反映しています。または、プロトコルによって使用されるアルゴリズムは、多少複雑になる場合があります。複雑さを分類するとき、「複雑なものは何か」最初に尋ねる質問です。このセクションでは、この質問に答える方法を提供します。
The set of network devices and wiring contains a certain complexity. For example, adding a redundant link between two locations increases the complexity of the network but provides more redundancy. Also, network devices can be more or less modular, which has impact on complexity trading off against ease of maintenance, availability, and upgradability.
ネットワークデバイスと配線のセットには、特定の複雑さが含まれています。たとえば、2つの場所の間に冗長リンクを追加すると、ネットワークの複雑さが増しますが、冗長性が向上します。また、ネットワークデバイスは多かれ少なかれモジュール化される可能性があり、保守の容易さ、可用性、およびアップグレード性とトレードオフの複雑さに影響を与えます。
The behavior of the physical network is not only defined by the hardware but also by algorithms that run on network elements and in central locations. Every algorithm has a certain intrinsic complexity, which is the subject of research on software complexity.
物理ネットワークの動作は、ハードウェアだけでなく、ネットワーク要素や中央の場所で実行されるアルゴリズムによっても定義されます。すべてのアルゴリズムには固有の複雑さがあり、これはソフトウェアの複雑さに関する研究の主題です。
The way a network element treats traffic is defined largely by the state in the network, in form of configuration, routing state, security measures, etc. Section 3.1 shows an example where more control-plane state allows for a more precise forwarding.
ネットワーク要素がトラフィックを処理する方法は、構成、ルーティング状態、セキュリティ対策などの形で、ネットワークの状態によって主に定義されます。セクション3.1は、より多くのコントロールプレーン状態がより正確な転送を可能にする例を示しています。
The rate of change itself is a parameter in complexity and needs to be weighed against other parameters. Section 3.5 explains a trade-off between the speed of communicating changes through the network and the stability of the network.
変化率自体は複雑さのパラメータであり、他のパラメータと比較検討する必要があります。セクション3.5では、ネットワークを介した変更の伝達速度とネットワークの安定性との間のトレードオフについて説明します。
Certain complexity parameters have a strong link to the human aspect of networking. For example, the more options and parameters a network protocol has, the harder it is to configure and troubleshoot. Therefore, there is a trade-off between the knowledge to be maintained by operational staff and desired functionality. The required knowledge of network operators is therefore an important part in complexity considerations.
特定の複雑性パラメータは、ネットワーキングの人間的側面と強いつながりがあります。たとえば、ネットワークプロトコルのオプションとパラメーターが多いほど、構成とトラブルシューティングが難しくなります。したがって、運用スタッフが維持する知識と必要な機能の間にはトレードオフがあります。したがって、ネットワークオペレーターに必要な知識は、複雑さを考慮する上で重要な部分です。
The previous section discussed in which form complexity may be perceived. This section focuses on where this complexity is located in a network. For example, an algorithm can run centrally, distributed, or even in the head of a network administrator. In classifying the complexity of a network, the location of a component may have an impact on overall complexity. This section offers a methodology to find WHERE the complex component is located.
前のセクションでは、フォームの複雑さがどのように認識されるかについて説明しました。このセクションでは、この複雑さがネットワークのどこにあるかに焦点を当てます。たとえば、アルゴリズムは、集中的に、分散して、またはネットワーク管理者の頭の中で実行することができます。ネットワークの複雑さを分類する場合、コンポーネントの場所が全体的な複雑さに影響を与える可能性があります。このセクションでは、複雑なコンポーネントが配置されている場所を見つける方法を提供します。
An algorithm can run distributed; for example, a routing protocol like OSPF runs on all routers in a network. But, it can also be in a central location such as the Network Operations Center (NOC). The physical location has an impact on several other parameters, such as availability (local changes might be faster than going through a remote NOC) and ease of operation, because it might be easier to understand and troubleshoot one central entity rather than many remote ones.
アルゴリズムは分散して実行できます。たとえば、OSPFのようなルーティングプロトコルは、ネットワーク内のすべてのルーターで実行されます。ただし、ネットワークオペレーションセンター（NOC）などの中央の場所に配置することもできます。物理的な場所は、可用性（リモートNOCを経由するよりもローカルでの変更の方が速い場合があります）や操作のしやすさなど、他のいくつかのパラメーターに影響を与えます。
The example in Section 3.3 shows how the location of state (in this case configuration) impacts the precision of the policy enforcement and the corresponding state required. Enforcement closer to the edge requires more network-wide state but is more precise.
セクション3.3の例は、状態の場所（この場合は構成）がポリシーの適用の精度と対応する必要な状態にどのように影響するかを示しています。エッジに近い方の施行には、ネットワーク全体の状態が必要ですが、より正確です。
Independent of its physical location, the logical location also may make a difference to complexity. A controller function, for example, can reside in a NOC and also on a network element. Generally, organizing a network in separate logical entities is considered positive because it eases the understanding of the network, thereby making troubleshooting and configuration easier. For example, a BGP route reflector is a separate logical entity from a BGP speaker, but it may reside on the same physical node.
物理的な場所とは関係なく、論理的な場所も複雑さに影響を与える可能性があります。たとえば、コントローラー機能はNOC内に存在することも、ネットワーク要素上に存在することもできます。一般に、ネットワークを個別の論理エンティティに編成すると、ネットワークの理解が容易になり、トラブルシューティングと設定が容易になるため、ポジティブと見なされます。たとえば、BGPルートリフレクタはBGPスピーカーとは別の論理エンティティですが、同じ物理ノードに存在する場合があります。
Also, the layer of the TCP/IP stack in which a function is implemented can have an impact on the complexity of the overall network. Some functions are implemented in several layers in slightly different ways; this may lead to unexpected results.
また、機能が実装されるTCP / IPスタックの層は、ネットワーク全体の複雑さに影響を与える可能性があります。一部の機能は、わずかに異なる方法で複数のレイヤーに実装されています。これにより、予期しない結果が生じる可能性があります。
As an example, a link failure is detected on various layers: L1, L2, the IGP, BGP, and potentially more. Since those have dependencies on each other, different link failure detection times can cause undesired effects. Dependencies are discussed in more detail in the next section.
例として、リンク障害はさまざまなレイヤー（L1、L2、IGP、BGPなど）で検出されます。これらは相互に依存しているため、リンク障害の検出時間が異なると、望ましくない影響が生じる可能性があります。依存関係については、次のセクションで詳しく説明します。
Dependencies are generally regarded as related to overall complexity. A system with less dependencies is generally considered less complex. This section proposes a way to analyze dependencies in a network.
依存関係は一般に、全体的な複雑さに関連していると見なされます。依存関係の少ないシステムは、一般的にそれほど複雑ではないと見なされます。このセクションでは、ネットワークの依存関係を分析する方法を提案します。
For example, [Chun] states: "We conjecture that the complexity particular to networked systems arises from the need to ensure state is kept in sync with its distributed dependencies."
たとえば、[Chun]氏は、次のように述べています。
In this document, we distinguish three types of dependencies: local dependencies, network-wide dependencies, and network-external dependencies.
このドキュメントでは、ローカルの依存関係、ネットワーク全体の依存関係、ネットワーク外部の依存関係の3種類の依存関係を区別します。
Local dependencies are relative to a single node in the network. For example, an interface on a node may have an IP address; this address may be used in other parts of the configuration. If the interface address changes, the dependent configuration parts have to change as well.
ローカルの依存関係は、ネットワーク内の単一のノードに関連しています。たとえば、ノードのインターフェイスにIPアドレスが設定されている場合があります。このアドレスは、構成の他の部分で使用できます。インターフェイスアドレスが変更されると、依存する構成部分も変更する必要があります。
Similar dependencies exist for QoS policies, access-control lists, names and numbers of configuration parts, etc.
QoSポリシー、アクセス制御リスト、構成部分の名前と数などにも同様の依存関係が存在します。
Routing protocols, failover protocols, and many others have dependencies across the network. If one node is affected by a problem, this may have a ripple effect through the network. These protocols are typically designed to deal with unexpected consequences and thus are unlikely to cause an issue on their own. But, occasionally a number of complexity issues come together (for example, different timers on different layers), resulting in unexpected behavior.
ルーティングプロトコル、フェイルオーバープロトコル、およびその他の多くは、ネットワーク全体で依存関係があります。 1つのノードが問題の影響を受ける場合は、ネットワーク全体に波及効果がある可能性があります。これらのプロトコルは通常、予期しない結果に対処するように設計されているため、それ自体で問題を引き起こすことはほとんどありません。ただし、複雑な問題（たとえば、異なるレイヤーの異なるタイマー）が同時に発生し、予期しない動作が発生する場合があります。
Some dependencies are on elements outside the actual network, for example, on an external NTP clock source or an Authentication, Authorization, and Accounting (AAA) server. Again, a trade-off is made: in the example of AAA used for login authentication, we reduce the configuration (state) on each node (in particular, user-specific configuration), but we add an external dependency on a AAA server. In networks with many administrators, a AAA server is clearly the only manageable way to track all administrators. But, it comes at the cost of this external dependency with the consequence that admin access may be lost for all devices at the same time when the AAA server is unavailable.
一部の依存関係は、外部のNTPクロックソースや認証、承認、アカウンティング（AAA）サーバーなど、実際のネットワーク外の要素に依存しています。繰り返しになりますが、トレードオフが行われます。ログイン認証に使用されるAAAの例では、各ノードの構成（状態）（特にユーザー固有の構成）を減らしていますが、AAAサーバーに外部依存関係を追加しています。多くの管理者がいるネットワークでは、AAAサーバーが、すべての管理者を追跡する唯一の管理可能な方法であることは明らかです。ただし、この外部依存性を犠牲にして、AAAサーバーが使用できないときに、すべてのデバイスの管理者アクセスが同時に失われる可能性があります。
Even with the external dependency on a AAA server, the advantage of centralizing the user information (and logging) still has significant value over distributing user information across all devices. To solve the problem of the central dependency not being available, other solutions have been developed -- for example, a secondary authentication mode with a single root-level password in case the AAA server is not available.
AAAサーバーに外部から依存している場合でも、ユーザー情報を集中化（およびロギング）する利点は、すべてのデバイスにユーザー情報を配布することよりも大きな価値があります。中央の依存関係が利用できないという問題を解決するために、他のソリューションが開発されました。たとえば、AAAサーバーが利用できない場合に単一のルートレベルのパスワードを使用するセカンダリ認証モードです。
A static network generally is relatively stable; conversely, changes introduce a degree of uncertainty and therefore need to be examined in detail. Also, the troubleshooting of a network exposes intuitively the complexity of the network. This section proposes a methodology to classify management interactions with regard to their relationship to network complexity.
静的ネットワークは一般に比較的安定しています。逆に、変更はある程度の不確実性をもたらすため、詳細に検討する必要があります。また、ネットワークのトラブルシューティングは、ネットワークの複雑さを直感的に明らかにします。このセクションでは、ネットワークの複雑さとの関係に関して管理の相互作用を分類する方法を提案します。
Configuration can be seen as distributed state across network devices where the administrator has direct influence on the operation of the network. Modifying the configuration can improve the network behavior overall or negatively affect it. In the worst case, a single misconfiguration could potentially bring down the entire network. Therefore, it is important that a human administrator can manage the complexity of the configuration well.
構成は、管理者がネットワークの運用に直接影響を与える、ネットワークデバイス全体の分散状態と見なすことができます。構成を変更すると、ネットワークの動作が全体的に向上するか、ネットワークに悪影響が及ぶ可能性があります。最悪の場合、1つの設定ミスでネットワーク全体がダウンする可能性があります。したがって、人間の管理者が構成の複雑さを適切に管理できることが重要です。
The configuration reflects most of the local and global dependencies in the network, as explained in Section 7. Tracking those dependencies in the configuration helps in understanding the overall network complexity.
セクション7で説明されているように、構成はネットワークのローカルおよびグローバルの依存関係のほとんどを反映しています。構成でこれらの依存関係を追跡すると、ネットワーク全体の複雑さを理解するのに役立ちます。
Unexpected behavior can have a number of sources: the configuration may contain errors, the operating system (algorithms) may have bugs, and the hardware may be faulty, which includes anything from broken fibers to faulty line cards. In serious problems, a combination of causes could result in a single visible condition. Tracking the root causes of an error condition may be extremely difficult, pointing to the complex nature of a network.
予期しない動作にはさまざまな原因が考えられます。構成にエラーが含まれている可能性があり、オペレーティングシステム（アルゴリズム）にバグがある可能性があり、ハードウェアが故障している可能性があります。深刻な問題では、原因の組み合わせにより、1つの目に見える状態が発生する可能性があります。エラー状態の根本的な原因を追跡することは、ネットワークの複雑な性質を指摘して非常に困難な場合があります。
Being able to find the source of a problem requires, therefore, a solid understanding of the complexity of a network. The configuration complexity discussed in the previous section represents only a part of the overall problem space.
したがって、問題の原因を見つけるには、ネットワークの複雑さをしっかりと理解する必要があります。前のセクションで説明した構成の複雑さは、問題空間全体の一部にすぎません。
Even in the absence of error conditions, the state of the network should be monitored to detect error conditions ideally before network services are affected. For example, a single link-down event may not cause a service disruption in a well-designed network, but the problem needs to be resolved quickly to restore redundancy.
エラー状態がない場合でも、理想的にはネットワークサービスに影響が及ぶ前に、ネットワークの状態を監視してエラー状態を検出する必要があります。たとえば、1つのリンクダウンイベントが適切に設計されたネットワークでサービスの中断を引き起こすことはありませんが、問題を迅速に解決して冗長性を復元する必要があります。
Monitoring a network has itself a certain complexity. Issues are in scale; variations of devices to be monitored; variations of methods used to collect information; the inevitable loss of information as reporting is aggregated centrally; and the knowledge required to understand the network, the dependencies, and the interactions with users and other external inputs.
ネットワークの監視は、それ自体がある程度複雑です。問題は大規模です。監視するデバイスのバリエーション。情報収集に使用される方法のバリエーション。報告が一元的に集約されるため、情報の必然的な損失。また、ネットワーク、依存関係、ユーザーと他の外部入力との相互作用を理解するために必要な知識。
A network doesn't just consist of network devices but includes a vast array of backend and support systems. It also interfaces a large variety of user devices, and a number of human interfaces, both to the user/customer as well as to administrators of the network. A system integration job is required in order to make sure the overall network provides the overall service expected.
ネットワークは、ネットワークデバイスだけで構成されているのではなく、膨大な数のバックエンドとサポートシステムが含まれています。また、ネットワークの管理者だけでなく、ユーザー/顧客の両方に対して、多種多様なユーザーデバイスと多くのヒューマンインターフェイスをインターフェイスします。ネットワーク全体が期待される全体的なサービスを提供するようにするために、システム統合ジョブが必要です。
All those interactions and systems have to be modeled to understand the interdependencies and complexities in the network. This is a large area of future research.
これらの相互作用とシステムはすべて、ネットワークの相互依存性と複雑さを理解するためにモデル化する必要があります。これは将来の研究の大きな領域です。
A network is not a self-contained entity, but it exists to provide connectivity and services to users and other networks, both of which are outside the direct control of a network administrator. The user experience of a network also illustrates a form of interaction with its own complexity.
ネットワークは自己完結型のエンティティではありませんが、ユーザーや他のネットワークに接続性とサービスを提供するために存在します。これらは両方ともネットワーク管理者の直接の制御の範囲外です。また、ネットワークのユーザーエクスペリエンスは、独自の複雑さを持つ相互作用の形式を示しています。
External interactions fall into the following categories:
外部相互作用は次のカテゴリに分類されます。
o User Interactions: Users need a way to request a service, to have their problems resolved, and potentially to get billed for their usage. There are a number of human interfaces that need to be considered, which depend to some extent on the network, for example, for troubleshooting or monitoring usage.
o ユーザーインタラクション：ユーザーは、サービスをリクエストし、問題を解決し、場合によっては使用料を請求する方法を必要としています。たとえば、トラブルシューティングや使用状況の監視など、ある程度ネットワークに依存するヒューマンインターフェイスを考慮する必要があります。
o Interactions with End Systems: The network also interacts with the devices that connect to it. Typically, a device receives an IP address from the network and information on how to resolve domain names, plus potentially other services. While those interactions are relatively simple, the vast amount of end-device types makes this a complicated space to track.
o エンドシステムとの相互作用：ネットワークは、それに接続するデバイスとも相互作用します。通常、デバイスはネットワークからIPアドレスと、ドメイン名の解決方法に関する情報、およびその他のサービスを受け取ります。これらの相互作用は比較的単純ですが、エンドデバイスの種類が膨大であるため、追跡が複雑になります。
o Internetwork Interactions: Most networks connect to other networks. Also, in this case, there are many interactions between networks, both technical (for example, running a routing protocol) as well as non-technical (for example, tracing problems across network boundaries).
o インターネットワークの相互作用：ほとんどのネットワークは他のネットワークに接続します。また、この場合、技術的（たとえば、ルーティングプロトコルの実行）と非技術的（たとえば、ネットワーク境界を越えた問題の追跡）の両方で、ネットワーク間に多くの相互作用があります。
For a fully operational network providing services to users, the external interactions and dependencies also form an integral part of the overall complexity of the network service. A specific example are the root DNS servers, which are critical to the function of the Internet. Practically all Internet users have an implicit dependency on the root DNS servers, which explains why those are frequent targets for attacks. Understanding the overall complexity of a network includes understanding all those external dependencies. Of course, in the case of the root DNS servers, there is little a network operator can influence.
ユーザーにサービスを提供する完全に機能するネットワークの場合、外部の相互作用と依存関係も、ネットワークサービスの全体的な複雑さの不可欠な部分を形成します。具体的な例は、インターネットの機能に不可欠なルートDNSサーバーです。実際には、すべてのインターネットユーザーがルートDNSサーバーに暗黙的に依存しているため、これらのサーバーが攻撃の対象になることがよくあります。ネットワークの全体的な複雑さを理解することには、それらすべての外部依存関係を理解することが含まれます。もちろん、ルートDNSサーバーの場合、ネットワークオペレーターが影響を与えることはほとんどありません。
In the foreseeable future, it is unlikely to define a single, objective metric that includes all the relevant aspects of complexity. In the absence of such a global metric, a comparative approach could be easier.
近い将来、複雑さの関連するすべての側面を含む単一の客観的なメトリックを定義することはほとんどありません。そのようなグローバルな測定基準がない場合、比較アプローチの方が簡単かもしれません。
For example, it is possible to compare the complexity of a centralized system where algorithms run centrally and the results are distributed to the network nodes with a distributed algorithm. The type of algorithm may be similar, but the location is different, and a different dependency graph would result. The supporting hardware may be the same and thus could be ignored for this exercise. Also, layering is likely to be the same. The management interactions, though, would significantly differ in both cases.
たとえば、アルゴリズムが一元的に実行され、結果が分散アルゴリズムを使用してネットワークノードに分散される集中システムの複雑さを比較することが可能です。アルゴリズムのタイプは似ているかもしれませんが、場所が異なり、異なる依存関係グラフが生成されます。サポートするハードウェアは同じであるため、この演習では無視できます。また、レイヤリングも同じである可能性があります。ただし、管理のやり取りはどちらの場合も大きく異なります。
The classification in this document also makes it easier to survey existing research with regards to which area of complexity is covered. This could help in identifying open areas for research.
このドキュメントの分類により、どの複雑な領域がカバーされているかに関して、既存の調査を簡単に調査できます。これは、研究のオープンエリアを特定するのに役立ちます。
This document does not discuss any specific security considerations.
このドキュメントでは、特定のセキュリティに関する考慮事項については説明していません。
[Behringer] Behringer, M., "Classifying Network Complexity", Proceedings of the 2009 Workshop on Re-architecting the Internet (Re-Arch '09), ACM, DOI 10.1145/1658978.1658983, December 2009.
[Behringer] Behringer、M。、「Classifying Network Complexity」、Proceedings of the 2009 Workshop on Re-architecting the Internet（Re-Arch '09）、ACM、DOI 10.1145 / 1658978.1658983、2009年12月。
[Chun] Chun, B-G., Ratnasamy, S., and E. Eddie, "NetComplex: A Complexity Metric for Networked System Designs", Proceedings of the 5th USENIX Symposium on Networked Systems Design and Implementation (NSDI '08), pp. 393-406, April 2008, <http://usenix.org/events/nsdi08/ tech/full_papers/chun/chun.pdf>.
[Chun] Chun、BG。、Ratnasamy、S。、およびE. Eddie、「NetComplex：A Complexity Metric for Networked System Designs」、Proceedings of the 5th USENIX Symposium on Networked Systems Design and Implementation（NSDI '08）、pp。 393-406、2008年4月、<http://usenix.org/events/nsdi08/ tech / full_papers / chun / chun.pdf>。
[Doyle] Doyle, J., Anderson, D., Li, L., Low, S., Roughnan, M., Shalunov, S., Tanaka, R., and W. Willinger, "The 'robust yet fragile' nature of the Internet", Proceedings of the National Academy of Sciences of the United States of America (PNAS), Volume 102, Number 41, DOI 10.1073/pnas.0501426102, October 2005.
[Doyle] Doyle、J.、Anderson、D.、Li、L.、Low、S.、Roughnan、M.、Shalunov、S.、Tanaka、R。、およびW. Willinger、「「丈夫で壊れやすい」 「インターネットの性質」、全米科学アカデミー（PNAS）の議事録、102巻、41号、DOI 10.1073 / pnas.0501426102、2005年10月。
[ncrg] IRTF, "IRTF Network Complexity Research Group (NCRG) [CONCLUDED]", <https://irtf.org/concluded/ncrg>.
[ncrg] IRTF、「IRTFネットワーク複雑性研究グループ（NCRG）[終了]」、<https://irtf.org/concluded/ncrg>。
[RFC1925] Callon, R., "The Twelve Networking Truths", RFC 1925, DOI 10.17487/RFC1925, April 1996, <http://www.rfc-editor.org/info/rfc1925>.
[RFC1925] Callon、R。、「The Twelve Networking Truths」、RFC 1925、DOI 10.17487 / RFC1925、1996年4月、<http://www.rfc-editor.org/info/rfc1925>。
[RFC3439] Bush, R. and D. Meyer, "Some Internet Architectural Guidelines and Philosophy", RFC 3439, DOI 10.17487/RFC3439, December 2002, <http://www.rfc-editor.org/info/rfc3439>.
[RFC3439] Bush、R。およびD. Meyer、「Some Internet Architectural Guidelines and Philosophy」、RFC 3439、DOI 10.17487 / RFC3439、2002年12月、<http://www.rfc-editor.org/info/rfc3439>。
[wiki] "Network Complexity - The Wiki", <http://networkcomplexity.org/>.
[wiki] "Network Complexity-The Wiki"、<http://networkcomplexity.org/>。
Acknowledgements
謝辞
The motivations and framework of this overview of studies into network complexity are the result of many meetings and discussions with too many people to provide a full list here. However, key contributions have been made by John Doyle, Dave Meyer, Jon Crowcroft, Mark Handley, Fred Baker, Paul Vixie, Lars Eggert, Bob Briscoe, Keith Jones, Bruno Klauser, Stephen Youell, Joel Obstfeld, and Philip Eardley.
このネットワークの複雑さに関する研究の概要の動機とフレームワークは、ここで完全なリストを提供するにはあまりにも多くの人々との多くの会議や議論の結果です。ただし、主な貢献は、ジョンドイル、デイブマイヤー、ジョンクロウクロフト、マークハンドラリー、フレッドベイカー、ポールヴィクシー、ラースエガート、ボブブリスコー、キースジョーンズ、ブルーノクラウザー、スティーブンユーエル、ジョエルオブストフェルド、フィリップエードリーによって行われました。
The authors would like to acknowledge the contributions of Rana Sircar, Ken Carlberg, and Luca Caviglione in the preparation of this document.
著者は、このドキュメントの作成におけるRana Sircar、Ken Carlberg、およびLuca Caviglioneの貢献に感謝します。
Authors' Addresses
著者のアドレス
Michael H. Behringer Cisco Systems Building D, 45 Allee des Ormes Mougins 06250 France
マイケルH.ベーリンガーシスコシステムズビルディングD、45アリーデオルムムジャン06250フランス
Email: mbehring@cisco.com
Alvaro Retana Cisco Systems 7025 Kit Creek Rd. Research Triangle Park, NC 27709
Alvaro Retana Cisco Systems 7025 Kit Creek Rd。 Research Triangle Park、NC 27709
United States of America Email: aretana@cisco.com
アメリカ合衆国メール：aretana@cisco.com
Russ White Ericsson 144 Warm Wood Lane Apex, NC 27539 United States of America
ラスホワイトエリクソン144 Warm Wood Lane Apex、NC 27539アメリカ合衆国
Email: russ@riw.us
URI: http://www.ericsson.com
Geoff Huston Asia Pacific Network Information Centre 6 Cordelia St South Brisbane, QLD 4101 Australia
Geoff Huston Asia Pacific Network Information Center 6 Cordelia St South Brisbane、QLD 4101 Australia
Email: gih@apnic.net
URI: http://www.apnic.net