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
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.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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编辑批准发布的文件不适用于任何级别的互联网标准；见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.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
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
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.
这里有两个目的。首先是指导在复杂领域工作的研究人员的工作。研究人员能够将他们的工作与网络设计师的关注点联系起来的越多，他们的研究就会变得越有用。本文件还可以指导以前未考虑的领域的研究。第二是帮助网络工程师更好地理解复杂性可能“隐藏”在网络中的位置，并更充分地了解复杂性如何与设计和部署交互作用。
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网络复杂性研究小组（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.
网络复杂性维基[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:
“复杂”和“复杂”这两个术语经常互换使用，但它们描述了不同但重叠的特性。RG对这两个术语作了以下陈述，但需要进一步完善，才能将其视为正式定义：
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]用一个例子解释了这一概念：互联网对单一组件故障很强大，但对目标攻击很脆弱。“强健但脆弱”属性还涉及到一个事实，即所有网络设计都必须在不同的设计目标之间进行权衡。最简单的一个是“好的、快的、便宜的：选择任何两个（你不可能拥有所有三个）”，如“十二个网络真理”[RFC1925]所述。在实际的网络设计中，必须在许多方面进行权衡，例如，包括网络平台的规划、设计、实施和管理的网络周期中的范围、时间和成本问题。第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]将这三个复杂性轴定义为“复杂性立方体”，其各自的轴是网络元素、中心系统和人类操作员。任何功能都可以在这三个轴中的任何一个轴上实现，这种选择可能会影响系统的整体复杂性。
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 网络状态：包含网络元素，如路由器、交换机（及其操作系统，包括协议）、线路、中央系统等。这还包括网络设备上协议的数量和算法复杂性。
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传输协议进行错误检测和重传），或者当一层中使用的假设被另一层违反时，会考虑复杂性。这会导致令人惊讶的结果，可能导致复杂的交互，例如振荡，因为不同的层使用不同的计时器进行重传。这些问题导致了这样一种观点，即增加分层常常会增加复杂性[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.
有两种解决系统级问题的基本方法：接口和连续体。在通过接口解决系统级问题时，我们试图将系统的每个部分视为一个“黑匣子”，并对这些黑匣子之间的接口有一个完整的理解。在将系统级问题作为一个连续体来解决时，我们试图将单个变更或元素对整个系统的影响理解为一组权衡。
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.
解决一个特定问题（或一类问题）会增加复杂性，从而增加另一类问题的可能性（或出现）。在这种观点下，发现这些权衡的连续性，然后确定如何度量每一个，成为理解和度量系统级复杂性的关键步骤。
The following sections describe five such continuums; more may be possible.
以下各节描述了五个这样的连续体；可能还有更多。
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
+---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。这通过减少经过这两个路由器的信息量（仅在本例中为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应该选择通过R2的最短路径而不是通过R3的较长路径。这实际上增加了网络的延伸。从R1到R6的最短路径为3跳，在配置聚合之前，始终会选择该路径。假设一半的流量将沿着路径通过R2（3跳）和一半通过R3（4跳）转发，则网络将被（（3+4）/2）-3）或.5“半跳”拉伸。
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.
用于限制网络控制平面内故障域大小的主要方法是信息隐藏；隐藏在网络控制平面中的两种主要信息类型是可达性信息和拓扑信息。聚合可达性信息的示例是将路由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处的路由信息将网络划分为两个故障域：（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公布的聚合路由的度量依赖于聚合中的一个路由时，会发生错误的故障域分离。例如，如果192.0.2.0/24聚合的度量是从组件192.0.2.1/32的度量派生出来的，那么这一组件的故障将导致R1处的转发表发生变化——在这种情况下，控制平面并没有真正划分为两个不同的故障域。插图网络中增加的复杂性将是聚合控制平面信息所需配置的管理，以及确保控制平面真正分离为两个不同故障域的度量的管理。
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配置为运行一个路由协议，而R2、R3、R4、R5和R6配置为运行另一个协议，则R2和R3可以配置为在这两个控制平面之间重新分配可达性信息。这可能会将控制平面拆分为多个故障域（具体取决于重新分发的配置方式），但代价是创建和管理重新分发配置。此外，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.
控制平面复杂性与最佳网络利用率相互作用的另一个广泛领域是QoS。优化通过网络的流量需要两个特定的操作：标记和每跳行为（PHB）。与在网络中的每个转发设备上检查每个数据包不同，数据包通常以某种方式（通常通过服务位的类型）进行标记或分类，以便可以在所有转发设备上一致地处理它们。
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
+----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
假设标记配置在网络边缘；在这种情况下，必须配置四个设备（R4、R5、R6、R7），包括正在进行的配置管理，以标记数据包。将数据包标记移动到
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.
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，则通过网络的数据包将在每个跃点正确处理。涉及的成本将是管理三台设备上的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:
网络控制平面对配置或拓扑变化的反应速度是一个广泛研究的领域。控制平面会聚可分为四个基本部分：
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毫秒内检测到，则链路理论上可以在一秒钟内改变状态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.
网络拓扑的更改也必须在整个网络中传播，以便路径上的每个设备都可以计算新的转发表。在高速网络环境中，路由信息更改的传播可能在数十毫秒内发生，这就增加了每秒传播多个更改的可能性。以这种速率将信息注入控制平面会造成参与控制平面的进程和设备过载的风险，并在网络中产生破坏性的正反馈回路。为了避免这些后果，大多数控制平面协议都会调节任何单个设备传输网络变化信息的速度。该领域最近的一项创新是使用指数退避技术来管理将信息播发到控制平面的速率；第一次更改的传输速度很快，而后续更改的传输速度较慢。这些技术都通过增加配置和管理控制平面传播网络变化信息的速率的复杂性来控制通过控制平面的快速信息流的不稳定影响。
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.
从而允许第一次计算快速运行，同时延迟后续计算。配置和管理这些计时器是网络中的另一个复杂性来源。
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.
为了分析权衡，有必要将其形式化。这种权衡的参数列表很长，而且参数本身可能很复杂。例如，“成本”可以是一个简单的一维度量，但“可扩展性”和“最佳转发状态”更难详细定义。
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 成本：网络的建设和运行成本（即资本支出（capex）和运营支出（opex））是多少？
o Bandwidth/Delay/Jitter: Traffic characteristics between two points (average, max, etc.)
o 带宽/延迟/抖动：两点之间的流量特性（平均值、最大值等）
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.
网络设备和布线的集合具有一定的复杂性。例如，在两个位置之间添加冗余链路会增加网络的复杂性，但会提供更多冗余。此外，网络设备可以或多或少是模块化的，这会影响复杂性与易维护性、可用性和可升级性之间的权衡。
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
算法可以分布式运行；例如，像OSPF这样的路由协议在网络中的所有路由器上运行。但是，它也可以位于中心位置，如网络运营中心（NOC）。物理位置会影响其他几个参数，例如可用性（本地更改可能比通过
remote NOC) and ease of operation, because it might be easier to understand and troubleshoot one central entity rather than many remote ones.
远程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.
在本文档中，我们将区分三种类型的依赖关系：本地依赖关系、网络范围依赖关系和网络外部依赖关系。
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.
路由协议、故障转移协议和许多其他协议在整个网络中都有依赖关系。如果一个节点受到问题的影响，这可能会对整个网络产生连锁反应。这些协议通常设计用于处理意外后果，因此不太可能单独引发问题。但是，偶尔会出现一些复杂问题（例如，不同层上的不同计时器），导致意外行为。
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.
配置可以被视为跨网络设备的分布式状态，其中管理员直接影响网络的运行。修改配置可以从整体上改善网络行为或对其产生负面影响。在最坏的情况下，一次错误配置可能会导致整个网络瘫痪。因此，人工管理员能够很好地管理配置的复杂性是很重要的。
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.
意外行为可能有多种来源：配置可能包含错误，操作系统（算法）可能有错误，硬件可能有故障，包括从断光纤到故障线路卡的任何东西。在严重问题中，多种原因的组合可能导致单一可见的情况。由于网络的复杂性，跟踪错误情况的根本原因可能非常困难。
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.
即使在没有错误条件的情况下，也应该监控网络的状态，以便在网络服务受到影响之前检测到错误条件。例如，在设计良好的网络中，单个链路断开事件可能不会导致服务中断，但需要快速解决该问题以恢复冗余。
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服务器，它对Internet的功能至关重要。实际上，所有互联网用户都隐含地依赖于根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.，“网络复杂性分类”，2009年互联网重新架构研讨会论文集（2009年重新研究），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，B-G.，Ratnasamy，S.和E.Eddie，“网络复杂性：网络系统设计的复杂性度量”，第五届USENIX网络系统设计和实施研讨会论文集（NSDI'08），第393-406页，2008年4月<http://usenix.org/events/nsdi08/ tech/full\u 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，“互联网的‘强健但脆弱’性质”，美国国家科学院刊，第102卷，第41号，DOI 10.1073/PNAS.05014261002，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.，“十二个网络真理”，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，“一些互联网架构指南和哲学”，RFC 3439，DOI 10.17487/RFC3439，2002年12月<http://www.rfc-editor.org/info/rfc3439>.
[wiki] "Network Complexity - The Wiki", <http://networkcomplexity.org/>.
[wiki]“网络复杂性-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.
作者感谢拉娜·瑟卡尔、肯·卡尔伯格和卢卡·卡维廖内在本文件编写过程中所做的贡献。
Authors' Addresses
作者地址
Michael H. Behringer Cisco Systems Building D, 45 Allee des Ormes Mougins 06250 France
Michael H.Behringer思科系统D栋，45 Allee des Ormes Mougins，法国06250
Email: mbehring@cisco.com
Email: mbehring@cisco.com
Alvaro Retana Cisco Systems 7025 Kit Creek Rd. Research Triangle Park, NC 27709
阿尔瓦罗·雷塔纳思科系统公司，地址：北卡罗来纳州三角研究公园基特克里克路7025号，邮编：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
Russ White Ericsson 144美国北卡罗来纳州暖木巷Apex 27539号
Email: russ@riw.us
URI: http://www.ericsson.com
Email: russ@riw.us
URI: http://www.ericsson.com
Geoff Huston Asia Pacific Network Information Centre 6 Cordelia St South Brisbane, QLD 4101 Australia
澳大利亚昆士兰州南布里斯班科迪利亚街6号杰夫休斯顿亚太网络信息中心4101
Email: gih@apnic.net
URI: http://www.apnic.net
Email: gih@apnic.net
URI: http://www.apnic.net