[要約] RFC 7576は、自律ネットワーキングに関する一般的なギャップ分析を提供しています。その目的は、自律ネットワーキングの現状と将来の方向性を理解し、改善のための指針を提供することです。
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.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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.
この文書は、Internet Research Task Force（IRTF）の製品です。 IRTFは、インターネット関連の研究開発活動の結果を公開しています。これらの結果は、展開に適さない可能性があります。このRFCは、Internet Research Task Force（IRTF）のNetwork Management Research Groupのコンセンサスを表しています。 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.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 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などの内部ゲートウェイルーティングプロトコルは主にこれらの特性を示しますが、ネットワークの他のほとんどの側面ではトップダウン構成が必要であり、多くの場合、人間の管理者とかなりの集中化を伴います。本質的に、オートノミックネットワーキングはすべてのネットワーク構成をルーティングと同じ基盤に配置し、手動またはデータベース主導の構成を最小限に制限します。重要なタスクの多くが残るため、これによって人間の管理者が不要になる可能性は非常に低いことに注意してください。このアイデアは、手作業による計算、2つの異なる構成ファイル間のクロスチェック、または面倒なデータ入力など、面倒でエラーが発生しやすいタスクを排除することです。より高いレベルの運用タスクと複雑なトラブルシューティングは、人間が行う必要があります。
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, 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.
長年にわたり、IPアドレスとそのプレフィックスを完全に手動で静的に管理する以外に方法はありませんでした。サイトがIPv4アドレスの割り当て（通常はクラスC / 24またはクラスB / 16、まれにクラスA / 8）を受け取った後は、サブネット計画の紙と鉛筆の設計の問題でした（該当する場合）。アドレッシング計画自体。サブネットプレフィックスは手動でルーターに構成され、/ 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.
明らかに、この方法は、サイトに数十を超えるホストが存在するようになるとすぐに不器用でエラーが発生しやすくなりましたが、DHCP [RFC2131]が1990年代の後半に実行可能なソリューションになるまで使用する必要がありました。 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].
管理に関しては、DNSマッピングは通常、IPアドレス割り当てと適切に同期する必要があるため、IPアドレス管理とDNS管理の間にはリンクがあります。 DHCPが広く使用されるようになったのとほぼ同時に、IPアドレスの割り当てに合わせてDNSソースファイルを手動で保守することは非常に面倒になりました。 DNSの逆引きにより、クライアントの役割しか果たしていないホストでもDNS名を合成する必要がありました。そのため、DHCPサーバーテーブルをフォワードDNSおよびリバースDNSと同期させる必要がありました。このため、[RFC7010]で番号を付け直す場合について説明したように、IPアドレス管理ツールが登場しました。ただし、これらは[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].
もう1つの機能は、ダイナミック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.
非常に初期の段階から、ルーティングシステムに何らかの障害（つまり、リンクやルーターに問題が発生した）が発生した場合、インターネットルーティングは自己回復することが目標でした。また、ネットワークを介して最適なルートを見つける問題は、数年前によく知られたアルゴリズムが発見された数学グラフ理論の問題として特定されました（ダイクストラおよびベルマン-フォードアルゴリズム）。したがって、大規模なネットワークのルーティングテーブルを手動で構成することは非現実的であることが明らかだったため、最初からルーティングプロトコルは主に自律型になりました。
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 configured with the appropriate DNS server addresses. Additionally, some networks deploy Multicast DNS [RFC6762] locally to provide additional automation of the name space.
元々、ホスト名は静的テーブルで検索され、従来のファイル名から「hosts.txt」と呼ばれることがよくありました。 DNSが1980年代に導入されたとき、すべてのホストはDNSリゾルバーコードを必要とし、適切なDNSサーバーの（名前ではなく）IPアドレスで構成する必要がありました。デフォルトのルーターと同様に、これらはもともと手動で構成されていました。現在、これらはDHCPまたはDHCPv6 [RFC3315]を介して自動的に提供されています。 IPv6エンドシステムの場合、ルーターアドバタイズメントオプションを介してそれらを自動的に提供する方法もあります。ただし、DHCPまたはDHCPv6サーバー、またはIPv6ルーターは、適切な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.
元々、ユーザー認証とアカウンティングは、主に物理的な接続と、直接接続による信頼度に基づいていました。ネットワークオペレーターは、ユーザーとの専用物理リンクのセットアップに基づいて課金されます。自動化されたユーザー認証は、1990年代初頭にポイントツーポイントプロトコル[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.
ピア間のオートノミックプロセスが関係するもう1つの領域は、状態の同期です。この場合、いくつかのデバイスは一貫性のない状態で始まり、ピアツーピアの手順を経て、その後それらの状態が一貫します。多くのオートノミックプロセスまたは自動プロセスには、ある程度の暗黙的な状態同期が含まれています。ネットワーク時間同期[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ネットワークは、非常に多様な要件を持つ多数の顧客にサービスを提供する必要があるという事実を考えると、エンタープライズネットワークよりも頻繁に変更する必要があります。現在の厳格なモデルでは、ネットワーク管理者は、顧客が注文できる限られた数のサービスを設計します。ネットワークサービスの新しい要件は、人間の管理では迅速に対応できない場合があります。リアルタイムのリクエストがある場合、柔軟で迅速にデプロイするには、レスポンスが自律型である必要があります。ただし、インターフェイスの背後で、抽象化されたネットワーク情報とユーザー承認管理を記述することは、近い将来、ネットワーク管理者からの人間の知性に依存する必要があるかもしれません。ネットワークまたはネットワークサービス間のユーザー識別の統合/統合は、オートノミックネットワークアクセスのもう1つの課題です。現在、多くのエンドユーザーは、ネットワークまたはネットワークサービスを切り替えるときに、ユーザーアカウントと認証情報を手動で管理する必要があります。
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）に代表される、より柔軟な新しいネットワーク構成方法を導入しても、管理の問題が複雑になるだけであるという懸念の根拠があります。 [Kim13]など、SDNが構成管理の自動化の必要性と機会の両方を生み出すことは間違いありません。このトピックは、[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.
ドメイン内のノードが相互に検証可能なドメインIDを持つオートノミックネットワークでは、セキュリティプロセスを完全に自動的に実行できます。ノードはお互いを安全に識別し、必要なセキュリティ設定と、必要に応じて共有キーさえ交渉します。トラストアンカー（認証局、登録局）、証明書失効リスト、ポリシーサーバーなどの場所は、サービスディスカバリによって見つけることができます。証明書失効リストのダウンロードなどのトランザクションは、共通のトラストアンカーを介して認証できます。ポリシーの配布も完全に自動化でき、共通のトラストアンカーを介して保護できます。
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.
考えられるもう1つのオートノミック機能は、デバイスの障害や過負荷が発生する前にそれらを予測することです。デバイスは、自身の障害を予測して隣接デバイスに警告したり、デバイスが隣接デバイスの障害を予測したりする可能性があります。どちらの場合も、オートノミックネットワークは、問題を迂回して障害を報告することにより、ユーザーに影響を与えることなく、障害がすでに発生しているかのように応答できます。障害を予測するための基準は、温度、バッテリーステータス、ビットエラー率などです。過負荷を予測するための基準は、負荷率、遅延、ジッター、輻輳損失などの増加です。
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.
ネットワークサービスは、特定の順序で配置されるデバイスとパラメータの数に依存しています。たとえば、停電後、「通常に戻る」操作の調整されたシーケンスが必要です（たとえば、最初にスイッチとルーター、2番目に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.
したがって、ネットワークでの水平方向の情報交換に対する要求が高まっています。特に、自律的な決定には、ピアネットワークデバイス間の3種類の相互作用が必要です。検出（ネイバーとピアを見つける）、同期（ネットワークステータスについて合意する）、およびネゴシエーション（変更が必要な場合）です。したがって、多くの異なるタイプのデバイスの発見、多くのタイプのパラメータの同期、および多くの異なるタイプの目的の交渉をサポートする、再利用可能な発見、同期、および交渉メカニズムが必要です。
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 上記のIDスキームに基づいて、操作を自動的に保護できます。
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.
多くの既存のプロトコルは、可能な限り柔軟であるように定義されています。したがって、これらのプロトコルは、操作を開始するために多数の初期構成を必要とします。特定のケースには関係のない選択肢とオプションがあり、そのいくつかはコーナーケースを対象としています。さらに、数年前から存在していたプロトコルでは、基盤となるハードウェアテクノロジーがその間に進化したため、設計上の考慮事項の一部はもはや関係ありません。この問題の規模を理解するために、160を超えるDHCPオプションがIPv4用に定義されていることを考慮してください。オンラインですぐに利用できるサンプルのルーター構成ファイルでさえ、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.
私たちが持っている知識と経験が多ければ多いほど、私たちができるより良い決定ができます。ネットワークとネットワーク管理についても同じです。ネットワーク内の1つのコンポーネントに、何をすべきかに影響を与える知識が不足していて、別のコンポーネントにその知識がある場合、通常、人間のオペレーターまたは集中管理ツールを使用して知識を伝えます。
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、「デフォルトでインターネットを安全にする」、作業中、draft-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.
[Kim13] 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、「分散プレフィックス割り当てアルゴリズム」、作業中、draft-ietf-homenet-prefix-assignment-07、2015年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] 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>。
[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。、「Dynamic Host Configuration Protocol」、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 UPDATE）」、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、「Remote Authentication Dial In User Service（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]リグニー、C。、「RADIUSアカウンティング」、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.、and M. Carney、 "Dynamic Host Configuration Protocol for 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、「Neighbor Discovery for IP version 6（IPv6）」、RFC 4861、DOI 10.17487 / RFC4861、2007年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 Stateless Address Autoconfiguration」、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.、Shes、N.、Raszuk、R.、Greene、B.、Mauch、J。、およびD. McPherson、「Dissemination of Flow Specification Rules」、RFC 5575、DOI 10.17487 / RFC5575、August 2009、<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、「Network Time Protocol Version 4：Protocol and Algorithms Specification」、RFC 5905、DOI 10.17487 / RFC5905、2010年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。、編、Bjorklund、M。、編、Schoenwaelder、J。、編、およびA. Bierman、編、「Network Configuration Protocol（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、「Multiple Interfaces and Provisioning Domains Problem Statement」、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、「Multicast 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 Site Renumbering Gap Analysis」、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、「Significance of IPv6 Interface Identifiers」、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、「Software-Defined Networking：A Perspective from a Service Provider Environment」、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、「Autonomic Networking：Definitions and Design Goals」、RFC 7575 、DOI 10.17487 / RFC7575、2015年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.
[Xiao02] Xiao、X.、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ネットワーク管理研究グループの参加者によってなされた貴重なコメントを認めたいと思います。 Kevin FallとRene Struikによるレビューは特に役に立ちました。
Authors' Addresses
著者のアドレス
Sheng Jiang Huawei Technologies Co., Ltd Q14, Huawei Campus, No.156 Beiqing Road Hai-Dian District, Beijing, 100095 China
S横江hu Aはテクノロジー株式会社Q14、hu Aはキャンパス、No.156はi青道路H艾-Dイアン地区、北京、100095中国
EMail: jiangsheng@huawei.com
Brian Carpenter Department of Computer Science University of Auckland PB 92019 Auckland 1142 New Zealand
ブライアンカーペンターコンピュータサイエンス学部オークランド大学PB 92019オークランド1142ニュージーランド
EMail: brian.e.carpenter@gmail.com
Michael H. Behringer Cisco Systems Building D, 45 Allee des Ormes Mougins 06250 France
マイケルH.ベーリンガーシスコシステムズビルディングD、45アリーデオルムムジャン06250フランス
EMail: mbehring@cisco.com