Internet Research Task Force (IRTF) S. Jiang
Request for Comments: 7576 Huawei Technologies Co., Ltd
Category: Informational B. Carpenter
ISSN: 2070-1721 Univ. of Auckland
M. Behringer
Cisco Systems
June 2015
Internet Research Task Force (IRTF) S. Jiang
Request for Comments: 7576 Huawei Technologies Co., Ltd
Category: Informational B. Carpenter
ISSN: 2070-1721 Univ. of Auckland
M. Behringer
Cisco Systems
June 2015
General Gap Analysis for Autonomic Networking
自治网络的通用间隙分析
Abstract
摘要
This document provides a problem statement and general gap analysis for an IP-based Autonomic Network that is mainly based on distributed network devices. The document provides background by reviewing the current status of autonomic aspects of IP networks and the extent to which current network management depends on centralization and human administrators. Finally, the document outlines the general features that are missing from current network abilities and are needed in the ideal Autonomic Network concept.
本文档为主要基于分布式网络设备的基于IP的自治网络提供问题陈述和一般差距分析。本文档通过回顾IP网络自治方面的当前状态以及当前网络管理在多大程度上依赖于集中化和人工管理员来提供背景信息。最后，本文档概述了当前网络功能中缺少的、理想的自主网络概念中需要的一般功能。
This document is a product of the IRTF's Network Management Research Group.
本文件是IRTF网络管理研究小组的产品。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the consensus of the Network Management Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网研究工作组（IRTF）的产品。IRTF发布互联网相关研究和开发活动的结果。这些结果可能不适合部署。本RFC代表了互联网研究任务组（IRTF）网络管理研究小组的共识。IRSG批准发布的文件不适用于任何级别的互联网标准；见RFC 5741第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/rfc7576.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7576.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Automatic and Autonomic Aspects of Current IP Networks . . . 3
3.1. IP Address Management and DNS . . . . . . . . . . . . . . 3
3.2. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Configuration of Default Router in a Host . . . . . . . . 5
3.4. Hostname Lookup . . . . . . . . . . . . . . . . . . . . . 5
3.5. User Authentication and Accounting . . . . . . . . . . . 6
3.6. Security . . . . . . . . . . . . . . . . . . . . . . . . 6
3.7. State Synchronization . . . . . . . . . . . . . . . . . . 7
4. Current Non-autonomic Behaviors . . . . . . . . . . . . . . . 7
4.1. Building a New Network . . . . . . . . . . . . . . . . . 7
4.2. Network Maintenance and Management . . . . . . . . . . . 8
4.3. Security Setup . . . . . . . . . . . . . . . . . . . . . 9
4.4. Troubleshooting and Recovery . . . . . . . . . . . . . . 9
5. Features Needed by Autonomic Networks . . . . . . . . . . . . 10
5.1. More Coordination among Devices or Network Partitions . . 11
5.2. Reusable Common Components . . . . . . . . . . . . . . . 11
5.3. Secure Control Plane . . . . . . . . . . . . . . . . . . 12
5.4. Less Configuration . . . . . . . . . . . . . . . . . . . 12
5.5. Forecasting and Dry Runs . . . . . . . . . . . . . . . . 13
5.6. Benefit from Knowledge . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. Informative References . . . . . . . . . . . . . . . . . . . 14
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Automatic and Autonomic Aspects of Current IP Networks . . . 3
3.1. IP Address Management and DNS . . . . . . . . . . . . . . 3
3.2. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Configuration of Default Router in a Host . . . . . . . . 5
3.4. Hostname Lookup . . . . . . . . . . . . . . . . . . . . . 5
3.5. User Authentication and Accounting . . . . . . . . . . . 6
3.6. Security . . . . . . . . . . . . . . . . . . . . . . . . 6
3.7. State Synchronization . . . . . . . . . . . . . . . . . . 7
4. Current Non-autonomic Behaviors . . . . . . . . . . . . . . . 7
4.1. Building a New Network . . . . . . . . . . . . . . . . . 7
4.2. Network Maintenance and Management . . . . . . . . . . . 8
4.3. Security Setup . . . . . . . . . . . . . . . . . . . . . 9
4.4. Troubleshooting and Recovery . . . . . . . . . . . . . . 9
5. Features Needed by Autonomic Networks . . . . . . . . . . . . 10
5.1. More Coordination among Devices or Network Partitions . . 11
5.2. Reusable Common Components . . . . . . . . . . . . . . . 11
5.3. Secure Control Plane . . . . . . . . . . . . . . . . . . 12
5.4. Less Configuration . . . . . . . . . . . . . . . . . . . 12
5.5. Forecasting and Dry Runs . . . . . . . . . . . . . . . . 13
5.6. Benefit from Knowledge . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. Informative References . . . . . . . . . . . . . . . . . . . 14
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
The general goals and relevant definitions for Autonomic Networking are discussed in [RFC7575]. In summary, the fundamental goal of an Autonomic Network is self-management, including self-configuration, self-optimization, self-healing, and self-protection. Whereas interior gateway routing protocols such as OSPF and IS-IS largely exhibit these properties, most other aspects of networking require top-down configuration, often involving human administrators and a considerable degree of centralization. In essence, Autonomic Networking is putting all network configurations onto the same footing as routing, limiting manual or database-driven configuration to an essential minimum. It should be noted that this is highly unlikely to eliminate the need for human administrators, because many of their essential tasks will remain. The idea is to eliminate tedious and error-prone tasks, for example, manual calculations, cross-checking between two different configuration files, or tedious data entry. Higher-level operational tasks, and complex troubleshooting, will remain to be done by humans.
[RFC7575]中讨论了自主网络的一般目标和相关定义。总之，自主网络的基本目标是自我管理，包括自我配置、自我优化、自我修复和自我保护。尽管内部网关路由协议（如OSPF和IS-IS）在很大程度上展示了这些特性，但网络的大多数其他方面都需要自顶向下的配置，通常需要人工管理员和相当程度的集中。本质上，自主网络是将所有网络配置置于与路由相同的基础上，将手动或数据库驱动的配置限制在最低限度。应该注意的是，这不太可能消除对人工管理员的需求，因为他们的许多基本任务仍将保留。其思想是消除繁琐且容易出错的任务，例如，手动计算、两个不同配置文件之间的交叉检查或繁琐的数据输入。更高级别的操作任务和复杂的故障排除仍将由人工完成。
This document represents the consensus of the IRTF's Network Management Research Group (NMRG). It first provides background by identifying examples of partial autonomic behavior in the Internet and by describing important areas of non-autonomic behavior. Based on these observations, it then describes missing general mechanisms that would allow autonomic behaviors to be added throughout the Internet.
本文件代表了IRTF网络管理研究小组（NMRG）的共识。它首先通过识别互联网上部分自主行为的例子和描述非自主行为的重要领域来提供背景。基于这些观察结果，本文接着描述了允许在整个互联网上添加自主行为的缺失的一般机制。
The terminology defined in [RFC7575] is used in this document.
本文件使用[RFC7575]中定义的术语。
This section discusses the history and current status of automatic or autonomic operations in various aspects of network configuration, in order to establish a baseline for the gap analysis. In particular, routing protocols already contain elements of autonomic processes, such as information exchange and state synchronization.
本节讨论网络配置各个方面的自动或自主操作的历史和现状，以便为差距分析建立基线。特别是，路由协议已经包含自治进程的元素，如信息交换和状态同步。
For many years, there was no alternative to completely manual and static management of IP addresses and their prefixes. Once a site had received an IPv4 address assignment (usually a Class C /24 or Class B /16, and rarely a Class A /8), it was a matter of paper-and-pencil design of the subnet plan (if relevant) and the addressing plan itself. Subnet prefixes were manually configured into routers,
多年来，除了对IP地址及其前缀进行完全手动和静态管理外，别无选择。一旦站点收到IPv4地址分配（通常为C/24类或B/16类，很少为a/8类），就需要纸笔设计子网计划（如果相关）和寻址计划本身。子网前缀已手动配置到路由器中，
and /32 addresses were assigned administratively to individual host computers and configured manually by system administrators. Records were typically kept in a plain text file or a simple spreadsheet.
和/32地址以管理方式分配给各个主机，并由系统管理员手动配置。记录通常保存在纯文本文件或简单的电子表格中。
Clearly, this method was clumsy and error-prone as soon as a site had more than a few tens of hosts, but it had to be used until DHCP [RFC2131] became a viable solution during the second half of the 1990s. DHCP made it possible to avoid manual configuration of individual hosts (except, in many deployments, for a small number of servers configured with static addresses). Even so, prefixes had to be manually assigned to subnets and their routers, and DHCP servers had to be configured accordingly.
显然，当一个站点有几十台以上的主机时，这种方法就很笨拙，而且容易出错，但在20世纪90年代后半期DHCP[RFC2131]成为可行的解决方案之前，这种方法必须一直使用。DHCP使得避免手动配置单个主机成为可能（在许多部署中，少数配置了静态地址的服务器除外）。即使如此，前缀必须手动分配给子网及其路由器，DHCP服务器也必须相应地配置。
In terms of management, there is a linkage between IP address management and DNS management, because DNS mappings typically need to be appropriately synchronized with IP address assignments. At roughly the same time as DHCP came into widespread use, it became very laborious to manually maintain DNS source files in step with IP address assignments. Because of reverse DNS lookup, it also became necessary to synthesize DNS names even for hosts that only played the role of clients. Therefore, it became necessary to synchronize DHCP server tables with forward and reverse DNS. For this reason, IP address management tools emerged, as discussed for the case of renumbering in [RFC7010]. These are, however, centralized solutions that do not exhibit autonomic properties as defined in [RFC7575].
在管理方面，IP地址管理和DNS管理之间存在联系，因为DNS映射通常需要与IP地址分配适当同步。大约在DHCP广泛使用的同时，手动维护DNS源文件与IP地址分配同步变得非常困难。由于反向DNS查找，甚至对于仅扮演客户端角色的主机，也有必要合成DNS名称。因此，有必要将DHCP服务器表与正向和反向DNS同步。因此，IP地址管理工具应运而生，正如[RFC7010]中关于重新编号的案例所讨论的那样。但是，这些都是集中式解决方案，不具有[RFC7575]中定义的自主属性。
A related issue is prefix delegation, especially in IPv6 when more than one prefix may be delegated to the same physical subnet. DHCPv6 Prefix Delegation [RFC3633] is a useful solution, but it requires specific configuration so cannot be considered autonomic. How this topic is to be handled in home networks is still in discussion [Pfister]. Still further away is autonomic assignment and delegation of routable IPv4 subnet prefixes.
一个相关的问题是前缀委派，特别是在IPv6中，当多个前缀可能委派给同一物理子网时。DHCPv6前缀委派[RFC3633]是一个有用的解决方案，但它需要特定的配置，因此不能被认为是自主的。如何在家庭网络中处理这个问题仍在讨论中[Pfister]。更进一步的是自主分配和委派可路由IPv4子网前缀。
An IPv6 network needs several aspects of host address assignments to be configured. The network might use stateless address autoconfiguration [RFC4862] or DHCPv6 [RFC3315] in stateless or stateful modes, and there are various alternative forms of Interface Identifier [RFC7136].
IPv6网络需要配置主机地址分配的几个方面。网络可能在无状态或有状态模式下使用无状态地址自动配置[RFC4862]或DHCPv6[RFC3315]，接口标识符[RFC7136]有多种替代形式。
Another feature is the possibility of Dynamic DNS Update [RFC2136]. With appropriate security, this is an automatic approach, where no human intervention is required to create the DNS records for a host after it acquires a new address. However, there are coexistence issues with a traditional DNS setup, as described in [RFC7010].
另一个特性是动态DNS更新[RFC2136]的可能性。在适当的安全性下，这是一种自动方法，在主机获取新地址后，无需人为干预即可为其创建DNS记录。但是，如[RFC7010]所述，传统DNS设置存在共存问题。
Since a very early stage, it has been a goal that Internet routing should be self-healing when there is a failure of some kind in the routing system (i.e., a link or a router goes wrong). Also, the problem of finding optimal routes through a network was identified many years ago as a problem in mathematical graph theory, for which well known algorithms were discovered (the Dijkstra and Bellman-Ford algorithms). Thus, routing protocols became largely autonomic from the start, as it was clear that manual configuration of routing tables for a large network was impractical.
从很早的阶段开始，当路由系统出现某种故障（即链路或路由器出现故障）时，互联网路由应该是自愈的目标。此外，通过网络寻找最佳路线的问题多年前被确定为数学图论中的一个问题，为此，人们发现了著名的算法（Dijkstra和Bellman-Ford算法）。因此，路由协议从一开始就在很大程度上是自主的，因为很明显，为大型网络手动配置路由表是不切实际的。
IGP routers do need some initial configuration data to start up the autonomic routing protocol. Also, BGP-4 routers need detailed static configuration of routing policy data.
IGP路由器确实需要一些初始配置数据来启动自主路由协议。此外，BGP-4路由器需要路由策略数据的详细静态配置。
Originally, the configuration of a default router in a host was a manual operation. Since the deployment of DHCP, this has been automatic as far as most IPv4 hosts are concerned, but the DHCP server must be appropriately configured. In simple environments such as a home network, the DHCP server resides in the same box as the default router, so this configuration is also automatic. In more complex environments, where an independent DHCP server or a local DHCP relay is used, DHCP configuration is more complex and not automatic.
最初，主机中默认路由器的配置是手动操作。自部署DHCP以来，就大多数IPv4主机而言，这是自动的，但必须正确配置DHCP服务器。在家庭网络等简单环境中，DHCP服务器与默认路由器位于同一个框中，因此此配置也是自动的。在更复杂的环境中，如果使用独立的DHCP服务器或本地DHCP中继，DHCP配置会更复杂，而且不会自动进行。
In IPv6 networks, the default router is provided by Router Advertisement messages [RFC4861] from the router itself, and all IPv6 hosts make use of it. The router may also provide more complex Route Information Options. The process is essentially autonomic as far as all IPv6 hosts are concerned, and DHCPv6 is not involved. However, there are still open issues when more than one prefix is in use on a subnet, and more than one first-hop router may be available as a result (see, for example, [RFC6418]).
在IPv6网络中，默认路由器由来自路由器本身的路由器广告消息[RFC4861]提供，所有IPv6主机都使用它。路由器还可以提供更复杂的路由信息选项。就所有IPv6主机而言，该过程基本上是自主的，不涉及DHCPv6。然而，当一个子网上使用了多个前缀时，仍然存在一些未解决的问题，因此可能会有多个第一跳路由器可用（例如，请参见[RFC6418]）。
Originally, hostnames were looked up in a static table, often referred to as "hosts.txt" from its traditional file name. When the DNS was deployed during the 1980s, all hosts needed DNS resolver code and needed to be configured with the IP addresses (not the names) of suitable DNS servers. Like the default router, these were originally manually configured. Today, they are provided automatically via DHCP or DHCPv6 [RFC3315]. For IPv6 end systems, there is also a way for them to be provided automatically via a Router Advertisement option. However, the DHCP or DHCPv6 server, or the IPv6 router, needs to be
最初，主机名是在静态表中查找的，通常从其传统文件名中称为“hosts.txt”。在20世纪80年代部署DNS时，所有主机都需要DNS解析程序代码，并且需要使用合适DNS服务器的IP地址（而不是名称）进行配置。与默认路由器一样，这些路由器最初是手动配置的。如今，它们是通过DHCP或DHCPv6[RFC3315]自动提供的。对于IPv6终端系统，还可以通过路由器广告选项自动提供它们。但是，DHCP或DHCPv6服务器或IPv6路由器需要
configured with the appropriate DNS server addresses. Additionally, some networks deploy Multicast DNS [RFC6762] locally to provide additional automation of the name space.
配置了相应的DNS服务器地址。此外，一些网络在本地部署多播DNS[RFC6762]，以提供名称空间的额外自动化。
Originally, user authentication and accounting was mainly based on physical connectivity and the degree of trust that follows from direct connectivity. Network operators charged based on the setup of dedicated physical links with users. Automated user authentication was introduced by the Point-to-Point Protocol [RFC1661], [RFC1994] and RADIUS protocol [RFC2865] [RFC2866] in the early 1990s. As long as a user completes online authentication through the RADIUS protocol, the accounting for that user starts on the corresponding Authentication, Authorization, and Accounting (AAA) server automatically. This mechanism enables business models with charging based on the amount of traffic or time. However, user authentication information continues to be manually managed by network administrators. It also becomes complex in the case of mobile users who roam between operators, since prior relationships between the operators are needed.
最初，用户身份验证和计费主要基于物理连接和直接连接产生的信任度。网络运营商根据与用户建立的专用物理链路收费。20世纪90年代初，点对点协议[RFC1661]、[RFC1994]和RADIUS协议[RFC2865][RFC2866]引入了自动用户身份验证。只要用户通过RADIUS协议完成在线身份验证，该用户的记帐就会自动在相应的身份验证、授权和记帐（AAA）服务器上启动。此机制支持基于流量或时间收费的业务模型。但是，用户身份验证信息仍然由网络管理员手动管理。移动用户在运营商之间漫游的情况也变得复杂，因为运营商之间需要事先建立关系。
Security has many aspects that need configuration and are therefore candidates to become autonomic. On the other hand, it is essential that a network's central policy be applied strictly for all security configurations. As a result, security has largely been based on centrally imposed configurations.
安全性有许多方面需要配置，因此成为自治的候选者。另一方面，网络的中心策略必须严格适用于所有安全配置。因此，安全性在很大程度上是基于集中实施的配置。
Many aspects of security depend on policy, for example, password rules, privacy rules, firewall rulesets, intrusion detection and prevention settings, VPN configurations, and the choice of cryptographic algorithms. Policies are, by definition, human made and will therefore also persist in an autonomic environment. However, policies are becoming more high-level, abstracting addressing, for example, and focusing on the user or application. The methods to manage, distribute, and apply policy and to monitor compliance and violations could be autonomic.
安全性的许多方面取决于策略，例如，密码规则、隐私规则、防火墙规则集、入侵检测和预防设置、VPN配置以及加密算法的选择。根据定义，政策是人为的，因此也将在自主环境中持续存在。然而，策略正变得越来越高级，例如，将寻址抽象化，并将重点放在用户或应用程序上。管理、分发和应用策略以及监控法规遵从性和违规行为的方法可以是自主的。
Today, many security mechanisms show some autonomic properties. For example user authentication via IEEE 802.1x allows automatic mapping of users after authentication into logical contexts (typically VLANs). While today configuration is still very important, the overall mechanism displays signs of self-adaption to changing situations.
今天，许多安全机制显示出一些自主属性。例如，通过IEEE 802.1x的用户认证允许在认证后自动将用户映射到逻辑上下文（通常是VLAN）。虽然今天的配置仍然非常重要，但总体机制显示出适应不断变化的情况的迹象。
BGP Flowspec [RFC5575] allows a partially autonomic threat-defense mechanism, where threats are identified, the flow information is automatically distributed, and counter-actions can be applied. Today, typically a human operator is still in the loop to check correctness, but over time such mechanisms can become more autonomic.
BGP Flowspec[RFC5575]允许一种部分自主的威胁防御机制，在这种机制中，可以识别威胁，自动分发流信息，并可以应用反措施。今天，通常一个人工操作员仍在循环中检查正确性，但随着时间的推移，这种机制会变得更加自主。
Negotiation capabilities, present in many security protocols, also display simple autonomic behaviors. In this case, a security policy about algorithm strength can be configured into servers but will propagate automatically to clients.
协商功能存在于许多安全协议中，也显示出简单的自主行为。在这种情况下，关于算法强度的安全策略可以配置到服务器中，但会自动传播到客户端。
Another area where autonomic processes between peers are involved is state synchronization. In this case, several devices start out with inconsistent state and go through a peer-to-peer procedure after which their states are consistent. Many autonomic or automatic processes include some degree of implicit state synchronization. Network time synchronization [RFC5905] is a well-established explicit example, guaranteeing that a participating node's clock state is synchronized with reliable time servers within a defined margin of error, without any overall point of control of the synchronization process.
对等点之间的自主进程涉及的另一个领域是状态同步。在这种情况下，一些设备以不一致的状态开始，并经过对等过程，之后它们的状态是一致的。许多自主或自动进程包括某种程度的隐式状态同步。网络时间同步[RFC5905]是一个公认的明确示例，它保证参与节点的时钟状态在规定的误差范围内与可靠的时间服务器同步，而不需要对同步过程进行任何整体控制。
In current networks, many operations are still heavily dependent on human intelligence and decision, or on centralized top-down network management systems. These operations are the targets of Autonomic Networking technologies. The ultimate goal of Autonomic Networking is to replace human and automated operations by autonomic functions, so that the networks can run independently without depending on a human or Network Management System (NMS) for routine details, while maintaining central control where required. Of course, there would still be the absolute minimum of human input required, particularly during the network-building stage, emergencies, and difficult troubleshooting.
在当前的网络中，许多操作仍然严重依赖于人类的智能和决策，或者依赖于集中式自上而下的网络管理系统。这些操作是自主网络技术的目标。自主网络的最终目标是用自主功能取代人工和自动化操作，从而使网络能够独立运行，而无需依赖人工或网络管理系统（NMS）获取日常细节，同时在需要时保持中央控制。当然，仍然需要绝对最少的人力投入，特别是在网络建设阶段、紧急情况和疑难故障排除期间。
This section analyzes the existing human and central dependencies in typical networks and suggests cases where they could, in principle, be replaced by autonomic behaviors.
本节分析了典型网络中现有的人和中心依赖关系，并提出了原则上可以由自主行为取代的情况。
Building a network requires the operator to analyze the requirements of the new network, design a deployment architecture and topology, decide device locations and capacities, set up hardware, design network services, choose and enable required protocols, configure
构建网络需要运营商分析新网络的需求，设计部署架构和拓扑，决定设备位置和容量，设置硬件，设计网络服务，选择并启用所需协议，配置
each device and each protocol, set up central user authentication and accounting policies and databases, design and deploy security mechanisms, etc.
每个设备和每个协议，设置中央用户身份验证和记帐策略和数据库，设计和部署安全机制等。
Overall, these jobs are quite complex work that cannot become fully autonomic in the foreseeable future. However, part of these jobs may be able to become autonomic, such as detailed device and protocol configurations and database population. The initial network management policies/behaviors may also be transplanted from other networks and automatically localized.
总的来说，这些工作相当复杂，在可预见的未来无法完全自主。但是，这些作业的一部分可能会变得自主，例如详细的设备和协议配置以及数据库填充。初始网络管理策略/行为也可以从其他网络移植并自动本地化。
Network maintenance and management are very different for ISP networks and enterprise networks. ISP networks have to change much more frequently than enterprise networks, given the fact that ISP networks have to serve a large number of customers who have very diversified requirements. The current rigid model is that network administrators design a limited number of services for customers to order. New requirements of network services may not be able to be met quickly by human management. Given a real-time request, the response must be autonomic, in order to be flexible and quickly deployed. However, behind the interface, describing abstracted network information and user authorization management may have to depend on human intelligence from network administrators in the foreseeable future. User identification integration/consolidation among networks or network services is another challenge for Autonomic Network access. Currently, many end users have to manually manage their user accounts and authentication information when they switch among networks or network services.
对于ISP网络和企业网络，网络维护和管理是非常不同的。考虑到ISP网络必须服务于大量需求非常多样化的客户，ISP网络的变化必须比企业网络频繁得多。目前僵化的模式是网络管理员为客户设计数量有限的服务。人工管理可能无法快速满足网络服务的新需求。给定一个实时请求，响应必须是自主的，以便灵活快速地部署。然而，在界面后面，描述抽象的网络信息和用户授权管理在可预见的将来可能必须依赖于网络管理员的人工智能。网络或网络服务之间的用户身份集成/整合是自主网络访问的另一个挑战。目前，许多最终用户在网络或网络服务之间切换时必须手动管理其用户帐户和身份验证信息。
Classical network maintenance and management mainly handle the configuration of network devices. Tools have been developed to enable remote management and make such management easier. However, the decision about each configuration detail depends either on human intelligence or rigid templates. Therefore, these are the sources of all network configuration errors -- the human was wrong, the template was wrong, or both were wrong. This is also a barrier to increasing the utility of network resources, because the human managers cannot respond quickly enough to network events, such as traffic bursts, that were not foreseen in the template. For example, currently, a light load is often assumed in network design because there is no mechanism to properly handle a sudden traffic flood. It is therefore common to avoid performance collapses caused by traffic overload by configuring idle resources, with an overprovisioning ratio of at least 2 being normal [Xiao02].
经典的网络维护和管理主要处理网络设备的配置。已经开发了一些工具来实现远程管理，并使这种管理更加容易。但是，关于每个配置细节的决定取决于人类智能或严格的模板。因此，这些都是所有网络配置错误的来源——人错了，模板错了，或者两者都错了。这也是提高网络资源利用率的一个障碍，因为人力资源经理无法对模板中未预见的网络事件（如流量突发）做出足够快的响应。例如，目前，在网络设计中经常假设轻负载，因为没有适当的机制来处理突然的流量泛滥。因此，通过配置空闲资源来避免因流量过载而导致的性能崩溃是很常见的，正常情况下，过度配置比率至少为2[Xiao02]。
There are grounds for concern that the introduction of new, more flexible, methods of network configuration, typified by Software-Defined Networking (SDN), will only make the management problem more complex unless the details are managed automatically or autonomically. There is no doubt that SDN creates both the necessity and the opportunity for automation of configuration management, e.g., [Kim13]. This topic is discussed from a service provider viewpoint in [RFC7149].
有理由担心，以软件定义网络（SDN）为代表的新的、更灵活的网络配置方法的引入只会使管理问题更加复杂，除非细节是自动或自主管理的。毫无疑问，SDN为配置管理的自动化创造了必要性和机会，例如[Kim13]。[RFC7149]中从服务提供商的角度讨论了此主题。
Autonomic decision processes for configuration would enable dynamic management of network resources (by managing resource-relevant configuration). Self-adapting network configuration would adjust the network into the best possible situation; this would prevent configuration errors from having lasting impact.
配置的自主决策过程将支持网络资源的动态管理（通过管理与资源相关的配置）。自适应网络配置可将网络调整到最佳状态；这将防止配置错误产生持久影响。
Setting up security for a network generally requires very detailed human intervention or relies entirely on default configurations that may be too strict or too risky for the particular situation of the network. While some aspects of security are intrinsically top-down in nature (e.g., broadcasting a specific security policy to all hosts), others could be self-managed within the network.
为网络设置安全性通常需要非常详细的人工干预，或者完全依赖默认配置，这些配置对于网络的特定情况来说可能过于严格或过于危险。虽然安全性的某些方面本质上是自上而下的（例如，向所有主机广播特定的安全策略），但其他方面可以在网络内自我管理。
In an Autonomic Network, where nodes within a domain have a mutually verifiable domain identity, security processes could run entirely automatically. Nodes could identify each other securely, negotiating required security settings and even shared keys if needed. The locations of the trust anchors (certificate authority, registration authority), certificate revocation lists, policy server, etc., can be found by service discovery. Transactions such as a download of a certificate revocation list can be authenticated via a common trust anchor. Policy distribution can also be entirely automated and secured via a common trust anchor.
在自治网络中，域内的节点具有可相互验证的域标识，安全过程可以完全自动运行。节点可以安全地相互识别，协商所需的安全设置，甚至在需要时共享密钥。可以通过服务发现找到信任锚（证书颁发机构、注册机构）、证书吊销列表、策略服务器等的位置。诸如下载证书吊销列表之类的事务可以通过公共信任锚进行身份验证。策略分发也可以通过公共信任锚完全自动化和安全。
These concepts lead to a network where the intrinsic security is automatic and applied by default, i.e., a "self-protecting" network. For further discussion, see [Behringer].
这些概念导致了一个内在安全性自动且默认应用的网络，即“自我保护”网络。有关进一步讨论，请参见[Behringer]。
Current networks suffer difficulties in locating the cause of network failures. Although network devices may issue many warnings while running, most of them are not sufficiently precise to be identified as errors. Some of them are early warnings that would not develop into real errors. Others are, in effect, random noise. During a major failure, many different devices will issue multiple warnings within a short time, causing overload for the NMS and the operators.
目前的网络很难找到网络故障的原因。尽管网络设备在运行时可能会发出许多警告，但大多数警告不够精确，无法识别为错误。其中一些是早期警告，不会发展成真正的错误。其他的实际上是随机噪音。在重大故障期间，许多不同的设备将在短时间内发出多个警告，导致NMS和操作员过载。
However, for many scenarios, human experience is still vital to identify real issues and locate them. This situation may be improved by automatically associating warnings from multiple network devices together. Also, introducing automated learning techniques (comparing current warnings with historical relationships between warnings and actual faults) could increase the possibility and success rate of Autonomic Network diagnoses and troubleshooting.
然而，在许多情况下，人类经验对于确定真正的问题和定位问题仍然至关重要。通过将来自多个网络设备的警告自动关联在一起，可以改善这种情况。此外，引入自动学习技术（将当前警告与警告和实际故障之间的历史关系进行比较）可以提高自主网络诊断和故障排除的可能性和成功率。
Depending on the network errors, some of them (particularly hardware failures) may always require human intervention. However, Autonomic Network management behavior may help to reduce the impact of errors, for example, by switching traffic flows around. Today, this is usually manual (except for classical routing updates). Fixing software failures and configuration errors currently depends on humans and may even involve rolling back software versions and rebooting hardware. Such problems could be autonomically corrected if there were diagnostics and recovery functions defined in advance for them. This would fulfill the concept of self-healing.
根据网络错误的不同，其中一些错误（特别是硬件故障）可能总是需要人工干预。但是，自主网络管理行为可能有助于减少错误的影响，例如，通过切换流量。今天，这通常是手动的（除了经典的路由更新）。修复软件故障和配置错误目前取决于人工，甚至可能涉及回滚软件版本和重新启动硬件。如果事先为这些问题定义了诊断和恢复功能，则可以自动纠正这些问题。这将实现自我疗愈的概念。
Another possible autonomic function is predicting device failures or overloads before they occur. A device could predict its own failure and warn its neighbors, or a device could predict its neighbor's failure. In either case, an Autonomic Network could respond as if the failure had already occurred by routing around the problem and reporting the failure, with no disturbance to users. The criteria for predicting failure could be temperature, battery status, bit error rates, etc. The criteria for predicting overload could be increasing load factor, latency, jitter, congestion loss, etc.
另一种可能的自主功能是在设备故障或过载发生之前预测它们。设备可以预测其自身的故障并警告其邻居，或者设备可以预测其邻居的故障。在这两种情况下，自主网络都可以通过围绕问题进行路由并报告故障来做出响应，就像故障已经发生一样，而不会对用户造成干扰。预测故障的标准可能是温度、电池状态、误码率等。预测过载的标准可能是增加负载系数、延迟、抖动、拥塞损失等。
There are innumerable properties of network devices and end systems that today need to be configured either manually, by scripting, or by using a management protocol such as the Network Configuration Protocol (NETCONF) [RFC6241]. In an Autonomic Network, all of these would need to either have satisfactory default values or be configured automatically. Some examples are parameters for tunnels of various kinds, flows (in an SDN context), quality of service, service function chaining, energy management, system identification, and NTP configuration, but the list is endless.
目前，网络设备和终端系统有无数属性需要手动、通过脚本或使用管理协议（如网络配置协议（NETCONF）[RFC6241]）进行配置。在自主网络中，所有这些都需要具有令人满意的默认值或自动配置。一些示例是各种隧道的参数、流量（在SDN上下文中）、服务质量、服务功能链接、能源管理、系统标识和NTP配置，但列表是无止境的。
The task of Autonomic Networking is to incrementally build up individual autonomic processes that could progressively be combined to respond to every type of network event. Building on the preceding background information, and on the reference model in [RFC7575], this section outlines the gaps and missing features in general terms and, in some cases, mentions general design principles that should apply.
自主网络的任务是逐步建立独立的自主进程，这些进程可以逐步组合起来，以响应各种类型的网络事件。基于上述背景信息和[RFC7575]中的参考模型，本节概述了一般术语中的差距和缺失特征，并在某些情况下提及了应适用的一般设计原则。
Network services are dependent on a number of devices and parameters to be in place in a certain order. For example, after a power failure, a coordinated sequence of "return to normal" operations is desirable (e.g., switches and routers first, DNS servers second, etc.). Today, the correct sequence of events is either known only by a human administrator or automated in a central script. In a truly Autonomic Network, elements should understand their dependencies and be able to resolve them locally.
网络服务依赖于许多设备和参数，这些设备和参数以一定的顺序就位。例如，在电源故障后，需要协调的“恢复正常”操作序列（例如，首先是交换机和路由器，其次是DNS服务器，等等）。如今，事件的正确顺序要么只有管理员知道，要么由中央脚本自动确定。在一个真正自主的网络中，元素应该理解它们的依赖关系，并且能够在本地解决它们。
In order to make right or good decisions autonomically, the network devices need to know more information than just reachability (routing) information from the relevant or neighbor devices. Devices must be able to derive, for themselves, the dependencies between such information and configurations.
为了自主地做出正确或良好的决策，网络设备需要知道更多的信息，而不仅仅是来自相关或相邻设备的可达性（路由）信息。设备必须能够自行导出此类信息和配置之间的依赖关系。
There are therefore increased requirements for horizontal information exchange in the networks. Particularly, three types of interaction among peer network devices are needed for autonomic decisions: discovery (to find neighbors and peers), synchronization (to agree on network status), and negotiation (when things need to be changed). Thus, there is a need for reusable discovery, synchronization, and negotiation mechanisms that would support the discovery of many different types of device, the synchronization of many types of parameter, and the negotiation of many different types of objective.
因此，对网络中横向信息交换的要求越来越高。特别是，自主决策需要对等网络设备之间的三种交互：发现（查找邻居和对等方）、同步（商定网络状态）和协商（当需要更改时）。因此，需要可重用的发现、同步和协商机制来支持许多不同类型设备的发现、许多类型参数的同步以及许多不同类型目标的协商。
Elements of autonomic functions already exist today, within many different protocols. However, all such functions have their own discovery, transport, messaging, and security mechanisms as well as non-autonomic management interfaces. Each protocol has its own version of the above-mentioned functions to serve specific and narrow purposes. It is often difficult to extend an existing protocol to serve different purposes. Therefore, in order to provide the reusable discovery, synchronization, and negotiation mechanisms mentioned above, it is desirable to develop a set of reusable common protocol components for Autonomic Networking. These components should be:
自主功能的元素今天已经存在于许多不同的协议中。但是，所有这些功能都有自己的发现、传输、消息传递和安全机制以及非自主管理接口。每个协议都有其自身版本的上述功能，以满足特定和狭义的目的。通常很难扩展现有协议以满足不同的目的。因此，为了提供上述可重用的发现、同步和协商机制，需要为自主网络开发一组可重用的通用协议组件。这些组成部分应为：
o Able to identify other devices, users, and processes securely.
o 能够安全地识别其他设备、用户和进程。
o Able to automatically secure operations, based on the above identity scheme.
o 能够基于上述身份方案自动保护操作。
o Able to manage any type of information and information flows.
o 能够管理任何类型的信息和信息流。
o Able to discover peer devices and services for various Autonomic Service Agents (or autonomic functions).
o 能够为各种自主服务代理（或自主功能）发现对等设备和服务。
o Able to support closed-loop operations when needed to provide self-managing functions involving more than one device.
o 当需要提供涉及多个设备的自我管理功能时，能够支持闭环操作。
o Separable from the specific Autonomic Service Agents (or autonomic functions).
o 可与特定的自主服务代理（或自主功能）分离。
o Reusable by other autonomic functions.
o 可由其他自主功能重用。
The common components will, in effect, act as a control plane for autonomic operations. This control plane might be implemented in-band as functions of the target network, in an overlay network, or even out-of-band in a separate network. Autonomic operations will be capable of changing how the network operates and allocating resources without human intervention or knowledge, so it is essential that they are secure. Therefore, the control plane must be designed to be secure against forged autonomic operations and man-in-the middle attacks and as secure as reasonably possible against denial-of-service attacks. It must be decided whether the control plane needs to be resistant to unwanted monitoring, i.e., whether encryption is required.
公共组件实际上将充当自主操作的控制平面。该控制平面可以作为目标网络的功能在带内实现，在覆盖网络中实现，或者甚至在单独网络的带外实现。自主操作将能够在无需人工干预或知识的情况下改变网络运行和分配资源的方式，因此它们的安全性至关重要。因此，控制平面的设计必须能够防止伪造的自主操作和中间人攻击，并尽可能防止拒绝服务攻击。必须确定控制平面是否需要抵抗不必要的监控，即是否需要加密。
Many existing protocols have been defined to be as flexible as possible. Consequently, these protocols need numerous initial configurations to start operations. There are choices and options that are irrelevant in any particular case, some of which target corner cases. Furthermore, in protocols that have existed for years, some design considerations are no longer relevant, since the underlying hardware technologies have evolved meanwhile. To appreciate the scale of this problem, consider that more than 160 DHCP options have been defined for IPv4. Even sample router configuration files readily available online contain more than 200 lines of commands. There is therefore considerable scope for simplifying the operational tools for configuration of common protocols, even if the underlying protocols themselves cannot be simplified.
许多现有的协议被定义为尽可能灵活。因此，这些协议需要许多初始配置来启动操作。有一些选择和选项在任何特定情况下都是无关的，其中一些是针对角落情况的。此外，在已经存在多年的协议中，一些设计考虑不再相关，因为底层硬件技术也在不断发展。为了理解这个问题的规模，考虑为IPv4定义了超过160个DHCP选项。甚至在线可用的示例路由器配置文件也包含200多行命令。因此，即使基础协议本身无法简化，简化通用协议配置的操作工具仍有相当大的空间。
From another perspective, the deep reason why human decisions are often needed mainly results from the lack of information. When a device can collect enough information horizontally from other devices, it should be able to decide many parameters by itself, instead of receiving them from top-down configuration.
从另一个角度来看，人们常常需要做出决策的深层次原因主要是缺乏信息。当一个设备能够水平地从其他设备收集足够的信息时，它应该能够自行决定许多参数，而不是从自上而下的配置接收这些参数。
It is desired that top-down management is reduced in Autonomic Networking. Ideally, only the abstract Intent is needed from the human administrators. Neither users nor administrators should need to create and maintain detailed policies and profiles; if they are needed, they should be built autonomically. The local parameters should be decided by distributed Autonomic Nodes themselves, either from historic knowledge, analytics of current conditions, closed logical decision loops, or a combination of all.
希望在自主网络中减少自上而下的管理。理想情况下，只需要人工管理员提供抽象的意图。用户和管理员都不需要创建和维护详细的策略和配置文件；如果需要，则应自行建造。本地参数应由分布式自主节点自己决定，可以是历史知识、当前条件分析、闭合逻辑决策循环，也可以是所有参数的组合。
In a conventional network, there is no mechanism for trying something out safely, which means that configuration changes have to be designed in the abstract and their probable effects have to be estimated theoretically. In principle, an alternative to this would be to test the changes on a complete and realistic network simulator. However, this is a practical impossibility for a large network that is constantly changing, even if an accurate simulation could be performed. There is therefore a risk that applying changes to a running network will cause a failure of some kind. An autonomic network could fill this gap by supporting a closed loop "dry run" mode in which each configuration change could be tested out dynamically in the control plane without actually affecting the data plane. If the results are satisfactory, the change could be made live on the running network. If there is a consistency problem such as overcommitment of resources or incompatibility with another configuration setting, the change could be rolled back dynamically with no impact on traffic or users.
在传统的网络中，没有安全尝试的机制，这意味着必须抽象地设计配置更改，并且必须从理论上估计其可能的影响。原则上，一种替代方法是在一个完整且真实的网络模拟器上测试这些变化。然而，对于一个不断变化的大型网络来说，这实际上是不可能的，即使可以进行精确的模拟。因此，对正在运行的网络应用更改可能会导致某种类型的故障。自主网络可以通过支持闭环“干运行”模式来填补这一空白，在这种模式下，可以在控制平面中动态测试每个配置更改，而不会实际影响数据平面。如果结果令人满意，可以在正在运行的网络上实时进行更改。如果存在一致性问题，如资源过度使用或与其他配置设置不兼容，则可以动态回滚更改，而不会对流量或用户造成影响。
The more knowledge and experience we have, the better decisions we can make. It is the same for networks and network management. When one component in the network lacks knowledge that affects what it should do, and another component has that knowledge, we usually rely on a human operator or a centralized management tool to convey the knowledge.
我们拥有的知识和经验越多，我们就能做出更好的决定。网络和网络管理也是如此。当网络中的一个组件缺少影响其应做的事情的知识，而另一个组件拥有该知识时，我们通常依靠人工操作员或集中管理工具来传递知识。
Up to now, the only available network knowledge is usually the current network status inside a given device or relevant current status from other devices.
到目前为止，唯一可用的网络知识通常是给定设备内的当前网络状态或来自其他设备的相关当前状态。
However, historic knowledge is very helpful to make correct decisions, in particular, to reduce network oscillation or to manage network resources over time. Transplantable knowledge from other networks can be helpful to initially set up a new network or new
然而，历史知识对于做出正确的决策非常有帮助，特别是减少网络振荡或管理网络资源。来自其他网络的可移植知识有助于最初建立一个新的网络或网络
network devices. Knowledge of relationships between network events and network configuration may help a network to decide the best parameters according to real performance feedback.
网络设备。了解网络事件和网络配置之间的关系有助于网络根据实际性能反馈确定最佳参数。
In addition to such historic knowledge, powerful data analytics of current network conditions may also be a valuable source of knowledge that can be exploited directly by Autonomic Nodes.
除了这些历史知识外，对当前网络状况的强大数据分析也可能是自主节点可以直接利用的宝贵知识来源。
This document is focused on what is missing to allow autonomic network configuration, including security settings, of course. Therefore, it does not itself create any new security issues. It is worth underlining that autonomic technology must be designed with strong security properties from the start, since a network with vulnerable autonomic functions would be at great risk.
本文档重点介绍了允许自主网络配置所缺少的内容，当然包括安全设置。因此，它本身不会产生任何新的安全问题。值得强调的是，自主技术从一开始就必须具有强大的安全特性，因为具有易受攻击的自主功能的网络将面临巨大的风险。
[Behringer] Behringer, M., Pritikin, M., and S. Bjarnason, "Making The Internet Secure By Default", Work in Progress, draft-behringer-default-secure-00, January 2014.
[Behringer]Behringer，M.，Pritikin，M.，和S.Bjarnason，“默认情况下确保互联网安全”，正在进行的工作，草稿-Behringer-Default-Secure-00，2014年1月。
[Kim13] Kim, H. and N. Feamster, "Improving Network Management with Software Defined Networking", IEEE Communications Magazine, pages 114-119, February 2013.
[Kim 13]Kim，H.和N.Feamster，“通过软件定义的网络改进网络管理”，《IEEE通信杂志》，第114-119页，2013年2月。
[Pfister] Pfister, P., Paterson, B., and J. Arkko, "Distributed Prefix Assignment Algorithm", Work in Progress, draft-ietf-homenet-prefix-assignment-07, June 2015.
[Pfister]Pfister，P.，Paterson，B.，和J.Arkko，“分布式前缀分配算法”，正在进行的工作，草稿-ietf-homenet-Prefix-Assignment-072015年6月。
[RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, DOI 10.17487/RFC1661, July 1994, <http://www.rfc-editor.org/info/rfc1661>.
[RFC1661]辛普森，W.，编辑，“点对点协议（PPP）”，STD 51，RFC 1661，DOI 10.17487/RFC16611994年7月<http://www.rfc-editor.org/info/rfc1661>.
[RFC1994] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, DOI 10.17487/RFC1994, August 1996, <http://www.rfc-editor.org/info/rfc1994>.
[RFC1994]辛普森，W，“PPP挑战握手认证协议（CHAP）”，RFC 1994，DOI 10.17487/RFC1994，1996年8月<http://www.rfc-editor.org/info/rfc1994>.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, DOI 10.17487/RFC2131, March 1997, <http://www.rfc-editor.org/info/rfc2131>.
[RFC2131]Droms，R.，“动态主机配置协议”，RFC 2131，DOI 10.17487/RFC2131，1997年3月<http://www.rfc-editor.org/info/rfc2131>.
[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, DOI 10.17487/RFC2136, April 1997, <http://www.rfc-editor.org/info/rfc2136>.
[RFC2136]Vixie，P.，Ed.，Thomson，S.，Rekhter，Y.，和J.Bound，“域名系统中的动态更新（DNS更新）”，RFC 2136，DOI 10.17487/RFC2136，1997年4月<http://www.rfc-editor.org/info/rfc2136>.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, DOI 10.17487/RFC2865, June 2000, <http://www.rfc-editor.org/info/rfc2865>.
[RFC2865]Rigney，C.，Willens，S.，Rubens，A.，和W.Simpson，“远程认证拨入用户服务（RADIUS）”，RFC 2865，DOI 10.17487/RFC2865，2000年6月<http://www.rfc-editor.org/info/rfc2865>.
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, DOI 10.17487/RFC2866, June 2000, <http://www.rfc-editor.org/info/rfc2866>.
[RFC2866]Rigney，C.，“半径会计”，RFC 2866，DOI 10.17487/RFC2866，2000年6月<http://www.rfc-editor.org/info/rfc2866>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC3315]Droms，R.，Ed.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC 3315，DOI 10.17487/RFC3315，2003年7月<http://www.rfc-editor.org/info/rfc3315>.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, DOI 10.17487/RFC3633, December 2003, <http://www.rfc-editor.org/info/rfc3633>.
[RFC3633]Troan，O.和R.Droms，“动态主机配置协议（DHCP）版本6的IPv6前缀选项”，RFC 3633，DOI 10.17487/RFC3633，2003年12月<http://www.rfc-editor.org/info/rfc3633>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, <http://www.rfc-editor.org/info/rfc4861>.
[RFC4861]Narten，T.，Nordmark，E.，Simpson，W.，和H.Soliman，“IP版本6（IPv6）的邻居发现”，RFC 4861，DOI 10.17487/RFC48612007年9月<http://www.rfc-editor.org/info/rfc4861>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, <http://www.rfc-editor.org/info/rfc4862>.
[RFC4862]Thomson，S.，Narten，T.和T.Jinmei，“IPv6无状态地址自动配置”，RFC 4862，DOI 10.17487/RFC4862，2007年9月<http://www.rfc-editor.org/info/rfc4862>.
[RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., and D. McPherson, "Dissemination of Flow Specification Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, <http://www.rfc-editor.org/info/rfc5575>.
[RFC5575]Marques，P.，Sheth，N.，Raszuk，R.，Greene，B.，Mauch，J.，和D.McPherson，“流量规范规则的传播”，RFC 5575，DOI 10.17487/RFC5575，2009年8月<http://www.rfc-editor.org/info/rfc5575>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, <http://www.rfc-editor.org/info/rfc5905>.
[RFC5905]Mills，D.，Martin，J.，Ed.，Burbank，J.，和W.Kasch，“网络时间协议版本4：协议和算法规范”，RFC 5905，DOI 10.17487/RFC59052010年6月<http://www.rfc-editor.org/info/rfc5905>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <http://www.rfc-editor.org/info/rfc6241>.
[RFC6241]Enns，R.，Ed.，Bjorklund，M.，Ed.，Schoenwaeld，J.，Ed.，和A.Bierman，Ed.，“网络配置协议（NETCONF）”，RFC 6241，DOI 10.17487/RFC6241，2011年6月<http://www.rfc-editor.org/info/rfc6241>.
[RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and Provisioning Domains Problem Statement", RFC 6418, DOI 10.17487/RFC6418, November 2011, <http://www.rfc-editor.org/info/rfc6418>.
[RFC6418]Blanchet，M.和P.Seite，“多接口和供应域问题声明”，RFC 6418，DOI 10.17487/RFC6418，2011年11月<http://www.rfc-editor.org/info/rfc6418>.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013, <http://www.rfc-editor.org/info/rfc6762>.
[RFC6762]Cheshire，S.和M.Krochmal，“多播DNS”，RFC 6762，DOI 10.17487/RFC6762，2013年2月<http://www.rfc-editor.org/info/rfc6762>.
[RFC7010] Liu, B., Jiang, S., Carpenter, B., Venaas, S., and W. George, "IPv6 Site Renumbering Gap Analysis", RFC 7010, DOI 10.17487/RFC7010, September 2013, <http://www.rfc-editor.org/info/rfc7010>.
[RFC7010]Liu，B.，Jiang，S.，Carpenter，B.，Venaas，S.，和W.George，“IPv6站点重新编号差距分析”，RFC 7010，DOI 10.17487/RFC7010，2013年9月<http://www.rfc-editor.org/info/rfc7010>.
[RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, February 2014, <http://www.rfc-editor.org/info/rfc7136>.
[RFC7136]Carpenter，B.和S.Jiang，“IPv6接口标识符的重要性”，RFC 7136，DOI 10.17487/RFC7136，2014年2月<http://www.rfc-editor.org/info/rfc7136>.
[RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined Networking: A Perspective from within a Service Provider Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, <http://www.rfc-editor.org/info/rfc7149>.
[RFC7149]Boucadair，M.和C.Jacquenet，“软件定义的网络：服务提供商环境中的视角”，RFC 7149，DOI 10.17487/RFC7149，2014年3月<http://www.rfc-editor.org/info/rfc7149>.
[RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic Networking: Definitions and Design Goals", RFC 7575, DOI 10.17487/RFC7575, June 2015, <http://www.rfc-editor.org/info/rfc7575>.
[RFC7575]Behringer，M.，Pritikin，M.，Bjarnason，S.，Clemm，A.，Carpenter，B.，Jiang，S.，和L.Ciavaglia，“自主网络：定义和设计目标”，RFC 7575，DOI 10.17487/RFC7575752015年6月<http://www.rfc-editor.org/info/rfc7575>.
[Xiao02] Xiao, X., Telkamp, T., Fineberg, V., Chen, C., and L. Ni, "A Practical Approach for Providing QoS in the Internet Backbone", IEEE Communications Magazine, pages 56-62, December 2002.
[Xiaoo2]Xiao，Telkamp，T.，Fineberg，V.，Chen，C.，和L.Ni，“在互联网主干网中提供QoS的实用方法”，IEEE通信杂志，第56-62页，2002年12月。
Acknowledgements
致谢
The authors would like to acknowledge the valuable comments made by participants in the IRTF Network Management Research Group. Reviews by Kevin Fall and Rene Struik were especially helpful.
作者希望感谢IRTF网络管理研究小组参与者提出的宝贵意见。凯文·法尔和雷内·斯特鲁克的评论特别有用。
Authors' Addresses
作者地址
Sheng Jiang Huawei Technologies Co., Ltd Q14, Huawei Campus, No.156 Beiqing Road Hai-Dian District, Beijing, 100095 China
中国北京海淀区北青路156号华为校园盛江华为技术有限公司Q14，邮编：100095
EMail: jiangsheng@huawei.com
EMail: jiangsheng@huawei.com
Brian Carpenter Department of Computer Science University of Auckland PB 92019 Auckland 1142 New Zealand
Brian Carpenter奥克兰大学计算机系，奥克兰92019，新西兰1142
EMail: brian.e.carpenter@gmail.com
EMail: brian.e.carpenter@gmail.com
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