[要約] RFC 7575は、自律型ネットワーキングの定義と設計目標に関するものであり、自律型ネットワーキングの概念とその目的を明確にすることを目指しています。
Internet Research Task Force (IRTF) M. Behringer
Request for Comments: 7575 M. Pritikin
Category: Informational S. Bjarnason
ISSN: 2070-1721 A. Clemm
Cisco Systems
B. Carpenter
Univ. of Auckland
S. Jiang
Huawei Technologies Co., Ltd
L. Ciavaglia
Alcatel Lucent
June 2015
Autonomic Networking: Definitions and Design Goals
自律型ネットワーキング：定義と設計目標
Abstract
概要
Autonomic systems were first described in 2001. The fundamental goal is self-management, including self-configuration, self-optimization, self-healing, and self-protection. This is achieved by an autonomic function having minimal dependencies on human administrators or centralized management systems. It usually implies distribution across network elements.
自律システムは2001年に最初に説明されました。基本的な目標は、自己構成、自己最適化、自己修復、自己保護を含む自己管理です。これは、人間の管理者または集中管理システムへの依存が最小限のオートノミック機能によって実現されます。これは通常、ネットワーク要素間の分散を意味します。
This document defines common language and outlines design goals (and what are not design goals) for autonomic functions. A high-level reference model illustrates how functional elements in an Autonomic Network interact. 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/rfc7575.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7575で入手できます。
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 to Autonomic Networking . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Self-Management . . . . . . . . . . . . . . . . . . . . . 5
3.2. Coexistence with Traditional Management . . . . . . . . . 6
3.3. Secure by Default . . . . . . . . . . . . . . . . . . . . 7
3.4. Decentralization and Distribution . . . . . . . . . . . . 8
3.5. Simplification of Autonomic Node Northbound Interfaces . 8
3.6. Abstraction . . . . . . . . . . . . . . . . . . . . . . . 8
3.7. Autonomic Reporting . . . . . . . . . . . . . . . . . . . 9
3.8. Common Autonomic Networking Infrastructure . . . . . . . 9
3.9. Independence of Function and Layer . . . . . . . . . . . 10
3.10. Full Life-Cycle Support . . . . . . . . . . . . . . . . . 10
4. Not among the Design Goals . . . . . . . . . . . . . . . . . 11
4.1. Eliminate Human Operators . . . . . . . . . . . . . . . . 11
4.2. Eliminate Emergency Fixes . . . . . . . . . . . . . . . . 11
4.3. Eliminate Central Control . . . . . . . . . . . . . . . . 11
5. An Autonomic Reference Model . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. Informative References . . . . . . . . . . . . . . . . . . . 13
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
Autonomic systems were first described in a manifesto by IBM in 2001 [Kephart]. The fundamental concept involves eliminating external systems from a system's control loops and closing of control loops within the autonomic system itself, with the goal of providing the system with self-management capabilities, including self-configuration, self-optimization, self-healing, and self-protection.
自律システムは、2001年にIBMによってマニフェストで最初に記述されました[Kephart]。基本的な概念には、システムの制御ループから外部システムを排除し、自律システム自体の内部で制御ループを閉じることを含み、自己構成、自己最適化、自己修復などの自己管理機能をシステムに提供することを目的としています。自己防衛。
IP networking was initially designed with similar properties in mind. An IP network should be distributed and redundant to withstand outages in any part of the network. Routing protocols such as OSPF and IS-IS exhibit properties of self-management and can thus be considered autonomic in the definition of this document.
IPネットワーキングは当初、同様の特性を念頭に置いて設計されました。 IPネットワークは、ネットワークのどの部分でも機能停止に耐えられるように分散および冗長化する必要があります。 OSPFやIS-ISなどのルーティングプロトコルは、自己管理の特性を示すため、このドキュメントの定義ではオートノミックと見なすことができます。
However, as IP networking evolved, the ever-increasing intelligence of network elements was often not put into protocols to follow this paradigm, but was put into external configuration systems. This configuration made network elements dependent on some process that manages them, either a human or a network management system.
ただし、IPネットワーキングが進化するにつれ、ネットワーク要素のインテリジェンスが増加し続けるため、このパラダイムに従うプロトコルに組み込まれることはなく、外部構成システムに組み込まれるようになりました。この構成により、ネットワーク要素は、人間またはネットワーク管理システムのいずれかを管理するいくつかのプロセスに依存するようになりました。
Autonomic functions can be defined in two ways:
自律機能は、次の2つの方法で定義できます。
o On a node level: Nodes interact with each other to form feedback loops.
o ノードレベル：ノードは相互に作用してフィードバックループを形成します。
o On a system level: Feedback loops include central elements as well.
o システムレベル：フィードバックループには中心的な要素も含まれます。
System-level autonomy is implicitly or explicitly the subject in many IETF working groups, where interactions with controllers or network management systems are discussed.
システムレベルの自律性は、暗黙的または明示的に多くのIETFワーキンググループの主題であり、コントローラーまたはネットワーク管理システムとの相互作用が議論されます。
This work specifically focuses on node-level autonomic functions. It focuses on intelligence of algorithms at the node level, to minimize dependency on human administrators and central management systems.
この作業は、ノードレベルの自律機能に特に焦点を当てています。人間の管理者や中央管理システムへの依存を最小限に抑えるために、ノードレベルでのアルゴリズムのインテリジェンスに焦点を当てています。
Some network deployments benefit from a fully autonomic approach, for example, networks with a large number of relatively simple devices. Most currently deployed networks, however, will require a mixed approach, where some functions are autonomic and others are centrally managed. Central management of networking functions clearly has advantages and will be chosen for many networking functions. This document does not discuss which functions should be centralized or follow an autonomic approach. Instead, it should help make the decision which is the best approach for a given situation.
たとえば、比較的単純なデバイスが多数あるネットワークなど、一部のネットワーク配置は完全に自律的なアプローチの恩恵を受けます。ただし、現在展開されているほとんどのネットワークには、いくつかの機能が自律型であり、他の機能が集中管理される混合アプローチが必要です。ネットワーク機能の集中管理には明らかに利点があり、多くのネットワーク機能に選択されます。このドキュメントでは、集中化する必要のある機能やオートノミックアプローチに従う必要のある機能については説明していません。代わりに、特定の状況に最適なアプローチを決定するのに役立ちます。
Autonomic function cannot always discover all required information; for example, policy-related information requires human input, because policy is by its nature derived and specified by humans. Where input from some central intelligence is required, it is provided in a highly abstract, network-wide form.
オートノミック機能は、常にすべての必要な情報を発見できるわけではありません。たとえば、ポリシーは本質的に人間によって導出および指定されるため、ポリシー関連の情報には人間の入力が必要です。中心的なインテリジェンスからの入力が必要な場合、それは非常に抽象的なネットワーク全体の形式で提供されます。
Autonomic Computing in general and Autonomic Networking in particular have been the subject of academic study for many years. There is much literature, including several useful overview papers (e.g., [Samaan], [Movahedi], and [Dobson]). In the present document, we focus on concepts and definitions that seem sufficiently mature to become the basis for interoperable specifications in the near future. In particular, such specifications will need to coexist with traditional methods of network configuration and management, rather than realizing an exclusively autonomic system with all the properties that it would require.
オートノミックコンピューティング全般、特にオートノミックネットワーキングは、長年にわたって学術研究の主題となっています。いくつかの有用な概要論文（[Samaan]、[Movahedi]、[Dobson]など）を含む多くの文献があります。このドキュメントでは、近い将来に相互運用可能な仕様の基礎になるのに十分成熟しているように見える概念と定義に焦点を当てます。特に、このような仕様は、必要なすべてのプロパティを備えた排他的な自律システムを実現するのではなく、ネットワーク構成と管理の従来の方法と共存する必要があります。
There is an important difference between "automatic" and "autonomic". "Automatic" refers to a predefined process, such as a script. "Autonomic" is used in the context of self-management. It includes feedback loops between elements as well as northbound to central elements. See also the definitions in the next section. Generally, an automatic process works in a given environment but has to be adapted if the environment changes. An autonomic process can adapt to changing environments.
「自動」と「自律」の間には重要な違いがあります。 「自動」とは、スクリプトなどの事前定義されたプロセスを指します。 「自律型」は、自己管理のコンテキストで使用されます。これには、要素間のフィードバックループと、中心の要素へのノースバウンドが含まれます。次のセクションの定義も参照してください。一般に、自動プロセスは特定の環境で機能しますが、環境が変化した場合は適応する必要があります。オートノミックプロセスは、変化する環境に適応できます。
This document provides the definitions and design goals for Autonomic Networking in the IETF and IRTF. It represents the consensus of the IRTF's Network Management Research Group (NMRG).
このドキュメントでは、IETFおよびIRTFにおけるオートノミックネットワーキングの定義と設計目標について説明します。これは、IRTFのネットワーク管理研究グループ（NMRG）のコンセンサスを表しています。
We make the following definitions.
以下のように定義します。
Autonomic: Self-managing (self-configuring, self-protecting, self-healing, self-optimizing); however, allowing high-level guidance by a central entity, through Intent (see below). An autonomic function adapts on its own to a changing environment.
オートノミック：自己管理（自己構成、自己保護、自己修復、自己最適化）;ただし、インテントを介して中央エンティティによる高レベルのガイダンスを許可します（以下を参照）。オートノミック機能は、変化する環境に独自に適応します。
Automatic: A process that occurs without human intervention, with step-by-step execution of rules. However, it relies on humans defining the sequence of rules, so is not Autonomic in the full sense. For example, a start-up script is automatic but not autonomic. An automatic function may need manual adjustments if the environment changes.
自動：ルールを段階的に実行する、人間の介入なしに発生するプロセス。ただし、ルールのシーケンスを定義する人間に依存しているため、完全な意味でのオートノミックではありません。たとえば、起動スクリプトは自動ですが、オートノミックではありません。自動機能では、環境が変化した場合に手動で調整する必要があります。
Intent: An abstract, high-level policy used to operate the network. Its scope is an autonomic domain, such as an enterprise network. It does not contain configuration or information for a specific node (see Section 3.2 on how Intent coexists with alternative management paradigms). It may contain information pertaining to a node with a specific role (for example, an edge switch) or a node running a specific function. Intent is typically defined and provided by a central entity.
意図：ネットワークの運用に使用される抽象的な高レベルのポリシー。その範囲は、エンタープライズネットワークなどの自律ドメインです。特定のノードの構成や情報は含まれていません（Intentが代替管理パラダイムとどのように共存するかについては、セクション3.2を参照してください）。特定の役割を持つノード（エッジスイッチなど）または特定の機能を実行するノードに関する情報が含まれている場合があります。インテントは通常、中央エンティティによって定義および提供されます。
Autonomic Domain: A collection of autonomic nodes that instantiate the same Intent.
オートノミックドメイン：同じインテントをインスタンス化するオートノミックノードのコレクション。
Autonomic Function: A feature or function that requires no configuration and can derive all required information through self-knowledge, discovery, or Intent.
自律機能：構成を必要とせず、自己認識、発見、または意図を通じて必要なすべての情報を引き出すことができる機能または機能。
Autonomic Service Agent: An agent implemented on an autonomic node that implements an autonomic function, either in part (in the case of a distributed function) or whole.
オートノミックサービスエージェント：オートノミック機能を部分的に（分散機能の場合）または全体として実装するオートノミックノードに実装されたエージェント。
Autonomic Node: A node that employs exclusively autonomic functions. It requires (!) no configuration. (Note that configuration can be used to override an autonomic function. See Section 3.2 for more details.) An Autonomic Node may operate on any layer of the networking stack. Examples are routers, switches, personal computers, call managers, etc.
自律ノード：自律機能のみを使用するノード。 （！）設定は必要ありません。 （構成を使用して、オートノミック機能をオーバーライドできることに注意してください。詳細については、セクション3.2を参照してください。）オートノミックノードは、ネットワークスタックの任意のレイヤーで動作できます。例としては、ルーター、スイッチ、パーソナルコンピューター、コールマネージャーなどがあります。
Autonomic Network: A network containing exclusively autonomic nodes. It may contain one or several autonomic domains.
自律型ネットワーク：自律型ノードのみを含むネットワーク。 1つまたは複数の自律ドメインが含まれる場合があります。
This section explains the high-level goals of Autonomic Networking, independent of any specific solutions.
このセクションでは、特定のソリューションに関係なく、オートノミックネットワーキングの高レベルの目標について説明します。
The original design goals of autonomic systems as described in [Kephart] also apply to Autonomic Networks. The overarching goal is self-management, which is comprised of several "self" properties. The most commonly cited are:
[Kephart]で説明されているオートノミックシステムの元の設計目標は、オートノミックネットワークにも適用されます。包括的な目標は、いくつかの「自己」プロパティで構成される自己管理です。最も一般的に引用されるのは：
o Self-configuration: Functions do not require configuration, by either an administrator or a management system. They configure themselves, based on self-knowledge, discovery, and Intent. Discovery is the default way for an autonomic function to receive the information it needs to operate.
o 自己構成：管理者または管理システムによる機能の構成は必要ありません。彼らは自己認識、発見、意図に基づいて自分自身を設定します。ディスカバリーは、オートノミック機能が操作に必要な情報を受け取るためのデフォルトの方法です。
o Self-healing: Autonomic functions adapt on their own to changes in the environment and heal problems automatically.
o 自己修復：自律機能は、環境の変化に独自に適応し、問題を自動的に修復します。
o Self-optimizing: Autonomic functions automatically determine ways to optimize their behavior against a set of well-defined goals.
o 自己最適化：オートノミック機能は、明確に定義された一連の目標に対して動作を最適化する方法を自動的に決定します。
o Self-protection: Autonomic functions automatically secure themselves against potential attacks.
o 自己保護：オートノミック機能により、潜在的な攻撃から自動的に保護されます。
Almost any network can be described as "self-managing", as long as the definition of "self" is large enough. For example, a well-defined Software-Defined Networking (SDN) system, including the controller elements, can be described overall as "autonomic", if the controller provides an interface to the administrator that has the same properties as mentioned above (high level, network-wide, etc.).
「自己」の定義が十分に大きければ、ほとんどすべてのネットワークを「自己管理」と表現できます。たとえば、コントローラーが上記と同じプロパティを持つ管理者にインターフェイスを提供する場合、コントローラー要素を含む明確に定義されたSoftware-Defined Networking（SDN）システムは、全体的に「オートノミック」と表現できます（高レベル、ネットワーク全体など）。
For the work in the IETF and IRTF, we define the "self" properties on the node level. It is the design goal to make functions on network nodes self-managing, in other words, minimally dependent on management systems or controllers, as well as human operators. Self-managing functions on a node might need to exchange information with other nodes in order to achieve this design goal.
IETFおよびIRTFでの作業のために、ノードレベルで「自己」プロパティを定義します。ネットワークノードの機能を自己管理にすること、つまり、管理システムやコントローラ、および人間のオペレータへの依存を最小限に抑えることが設計目標です。ノードの自己管理機能は、この設計目標を達成するために他のノードと情報を交換する必要がある場合があります。
As mentioned in the introduction, closed-loop control is an important aspect of self-managing systems. This implies peer-to-peer dialogues between the parties that make up the closed loop. Such dialogues require two-way "discussion" or "negotiation" between each pair or groups of peers involved in the loop, so they cannot readily use typical top-down command-response protocols. Also, a discovery phase is unavoidable before such closed-loop control can take place. Multiparty protocols are also possible but can be significantly more complex.
冒頭で述べたように、閉ループ制御は自己管理システムの重要な側面です。これは、閉ループを構成する当事者間のピアツーピアの対話を意味します。このような対話では、ループに関与するピアの各ペアまたはグループ間で双方向の「ディスカッション」または「ネゴシエーション」が必要になるため、一般的なトップダウンのコマンド応答プロトコルを簡単に使用できません。また、このような閉ループ制御が行われる前に、発見フェーズは避けられません。マルチパーティプロトコルも可能ですが、かなり複雑になる可能性があります。
For the foreseeable future, autonomic nodes and networks will be the exception; autonomic behavior will initially be defined function by function. Therefore, coexistence with other network management paradigms has to be considered. Examples are management by command line, SNMP, SDN (with related APIs), the Network Configuration Protocol (NETCONF), etc.
近い将来、自律ノードとネットワークは例外になります。自律動作は、最初は機能ごとに定義されます。したがって、他のネットワーク管理パラダイムとの共存を検討する必要があります。例としては、コマンドラインによる管理、SNMP、SDN（関連するAPIを使用）、ネットワーク構成プロトコル（NETCONF）などがあります。
Conflict resolution between a) autonomic default behavior and Intent and b) other methods is therefore required. This is achieved through prioritization. Generally, autonomic mechanisms define a network-wide behavior, whereas the alternative methods are typically on a node-by-node basis. Node-based management concepts take a higher priority over autonomic methods. This is in line with current examples of autonomic functions; for example, with routing, a (statically configured) route has priority over the routing algorithm. In short:
したがって、a）オートノミックのデフォルト動作とインテント、およびb）その他の方法の間の競合解決が必要です。これは優先順位付けによって実現されます。一般に、オートノミックメカニズムはネットワーク全体の動作を定義しますが、代替方法は通常、ノードごとに行われます。ノードベースの管理概念は、オートノミックメソッドよりも優先されます。これは、オートノミック機能の現在の例と一致しています。たとえば、ルーティングでは、（静的に構成された）ルートがルーティングアルゴリズムよりも優先されます。要するに：
o lowest priority: autonomic default behavior
o 最も低い優先順位：自律型のデフォルトの動作
o medium priority: autonomic Intent
o 中優先度：オートノミックインテント
o highest priority: node-specific network management concepts, such as command line, SNMP, SDN, NETCONF, etc. How these concepts are prioritized is outside the scope of this document.
o 最高の優先順位：コマンドライン、SNMP、SDN、NETCONFなどのノード固有のネットワーク管理の概念。これらの概念にどのように優先順位を付けるかは、このドキュメントの範囲外です。
The above prioritization essentially results in the actions of the human administrator always being able to overrule autonomic behavior. This is generally the expectation of network operators today and therefore remains a design principle here. In critical systems, such as atomic power plants, sometimes the opposite philosophy is used: The expectation is that a well-defined algorithm is more reliable than a human operator, especially in rare exception cases. Networking generally does not follow this philosophy yet. However, warnings should be issued if node-specific overrides may conflict with autonomic behavior.
上記の優先順位付けにより、基本的に人間の管理者のアクションは常に自律的な動作を無効にすることができます。これは一般に今日のネットワークオペレーターの期待であり、したがって、ここでも設計原則のままです。原子力発電所などの重要なシステムでは、逆の哲学が使用されることがあります。特にまれな例外的なケースでは、明確に定義されたアルゴリズムは人間のオペレーターよりも信頼性が高いことが期待されます。ネットワーキングは一般に、まだこの哲学に従っていません。ただし、ノード固有のオーバーライドがオートノミック動作と競合する可能性がある場合は、警告を発行する必要があります。
In other fields, autonomic mechanisms disengage automatically if certain conditions occur: The autopilot in a plane switches off if the plane is outside a predefined envelope of flight parameters. The assumption is that the algorithms only work correctly if the input values are in expected ranges. However, some opinions suggest that exactly in exceptional conditions is the worst moment to switch off autonomic behavior, since the pilots have no full understanding of the situation at this point and may be under high levels of stress. For this reason, we suggest here to NOT generally disable autonomic functions if they encounter unexpected conditions, because it is expected that this adds another level of unpredictability in networks, when the situation may already be hard to understand.
他の分野では、特定の条件が発生するとオートノミックメカニズムが自動的に解除されます。飛行機が事前定義された飛行パラメータのエンベロープの外側にあると、飛行機のオートパイロットがオフになります。想定は、入力値が期待される範囲内にある場合にのみアルゴリズムが正しく機能することです。ただし、パイロットは現時点では状況を完全に理解しておらず、ストレスが非常に高いため、例外的な状況では自律動作をオフにする最悪の瞬間であるとする意見もあります。このため、予期しない状況が発生した場合は、オートノミック機能を一般的に無効にしないことをお勧めします。これにより、状況がすでに理解しにくい場合に、ネットワークに予測不可能なレベルがさらに追加されることが予想されます。
All autonomic interactions should be secure by default. This requires that any member of an autonomic domain can assert its membership using a domain identity, for example, a certificate issued by a domain certification authority. This domain identity is used for nodes to learn about their neighboring nodes, to determine the boundaries of the domain, and to cryptographically secure interactions within the domain. Nodes from different domains can also mutually verify their identity and secure interactions as long as they have a mutually respected trust anchor.
すべてのオートノミック相互作用は、デフォルトで安全でなければなりません。これには、オートノミックドメインのすべてのメンバーが、ドメイン証明機関によって発行された証明書などのドメインIDを使用してメンバーシップをアサートできることが必要です。このドメインIDは、ノードが隣接ノードについて学習し、ドメインの境界を決定し、ドメイン内の相互作用を暗号で保護するために使用されます。異なるドメインのノードは、相互に尊重されるトラストアンカーがある限り、相互にIDを確認し、相互作用を保護することもできます。
A strong, cryptographically verifiable domain identity is a fundamental cornerstone in Autonomic Networking. It can be leveraged to secure all communications and thus allows automatic security without traditional configuration, for example, preshared keys. See also the document "Making The Internet Secure By Default" [Behringer] for more information.
強力で暗号的に検証可能なドメインIDは、オートノミックネットワーキングの基本的な基盤です。すべての通信をセキュリティで保護するために利用できるため、事前共有キーなどの従来の構成なしで自動セキュリティを実現できます。詳細については、ドキュメント「インターネットをデフォルトで安全にする」[Behringer]も参照してください。
Autonomic functions must be able to adapt their behavior depending on the domain of the node they are interacting with.
自律機能は、相互作用するノードのドメインに応じて、その動作を適応させることができなければなりません。
The goal of Autonomic Networking is to minimize dependencies on central elements; therefore, decentralization and distribution are fundamental to the concept. If a problem can be solved in a distributed manner, it should not be centralized.
自律型ネットワーキングの目標は、中心的な要素への依存を最小限に抑えることです。したがって、分権化と分配がこの概念の基本です。問題を分散して解決できる場合は、集中化しないでください。
In certain cases, it is today operationally preferable to keep a central repository of information, for example, a user database on an Authentication, Authorization, and Accounting (AAA) server. An Autonomic Network should be able to use such central systems, in order to be deployable. It is possible to distribute such databases as well, and such efforts should be at least considered. Depending on the case, distribution may not be simple replication but may involve more complex interactions and organization.
場合によっては、認証、承認、およびアカウンティング（AAA）サーバー上のユーザーデータベースなど、情報の中央リポジトリを保持することが運用上望ましい場合があります。オートノミックネットワークは、展開可能にするために、このような中央システムを使用できる必要があります。そのようなデータベースを配布することも可能であり、そのような努力は少なくとも考慮されるべきです。場合によっては、配布は単純な複製ではない場合がありますが、より複雑な相互作用と編成が含まれる場合があります。
Even in a decentralized solution, certain information flows with central entities are required. Examples are high-level service definitions, as well as network status requests, audit information, logging, and aggregated reporting.
分散型ソリューションであっても、中央のエンティティとの特定の情報フローが必要です。例としては、高レベルのサービス定義、ネットワークステータスリクエスト、監査情報、ロギング、集約レポートなどがあります。
Therefore, nodes in an Autonomic Network require a northbound interface. However, the design goal is to maintain this interface as simple and high level as possible.
したがって、オートノミックネットワークのノードにはノースバウンドインターフェイスが必要です。ただし、設計目標は、このインターフェイスをできるだけシンプルかつ高レベルに維持することです。
An administrator or autonomic management system interacts with an Autonomic Network on a high level of abstraction. Intent is defined at a level of abstraction that is much higher than that of typical configuration parameters, for example, "optimize my network for energy efficiency". Intent must not be used to convey low-level commands or concepts, since those are on a different abstraction level.
管理者またはオートノミック管理システムは、高度な抽象化でオートノミックネットワークと対話します。インテントは、「エネルギー効率のためにネットワークを最適化する」など、一般的な構成パラメータよりもはるかに高い抽象化レベルで定義されます。低レベルのコマンドまたは概念は異なる抽象化レベルにあるため、それらを伝えるためにインテントを使用しないでください。
For example, the administrator should not be exposed to the version of the IP protocol running in the network.
たとえば、管理者は、ネットワークで実行されているIPプロトコルのバージョンに公開されるべきではありません。
Also on the reporting and feedback side, an Autonomic Network abstracts information and provides high-level messages such as "the link between node x and y is down" (possibly with an identifier for the specific link, in case of multiple links).
また、レポートとフィードバックの側では、オートノミックネットワークが情報を抽象化し、「ノードxとyの間のリンクがダウンしています」などの高レベルのメッセージを提供します（複数のリンクの場合は、特定のリンクの識別子が含まれる可能性があります）。
An Autonomic Network, while minimizing the need for user intervention, still needs to provide users with visibility like in traditional networks. However, in an Autonomic Network, reporting should happen on a network-wide basis. Information about the network should be collected and aggregated by the network itself and presented in a consolidated fashion to the administrator.
オートノミックネットワークは、ユーザーの介入の必要性を最小限に抑えながら、従来のネットワークと同様にユーザーに可視性を提供する必要があります。ただし、オートノミックネットワークでは、レポートはネットワーク全体で発生する必要があります。ネットワークに関する情報は、ネットワーク自体によって収集および集約され、統合された方法で管理者に提示される必要があります。
The layers of abstraction that are provided via Intent need to be supported for reporting functions as well, in order to give users an indication about the effectiveness of their Intent. For example, in order to assess how effective the network performs with regards to the Intent "optimize my network for energy efficiency", the network should provide aggregate information about the number of ports that were able to be shut down, and the corresponding energy savings, while validating current service levels are, on aggregate, still met.
Intentを介して提供される抽象化のレイヤーは、ユーザーがIntentの有効性を示すために、レポート機能でもサポートされる必要があります。たとえば、「エネルギー効率のためにネットワークを最適化する」という目的に関してネットワークがどれほど効果的に機能するかを評価するために、ネットワークは、シャットダウンできたポートの数とそれに対応するエネルギー節約に関する集約情報を提供する必要があります、現在のサービスレベルの検証は、全体としてはまだ満たされています。
Autonomic network events should concern the Autonomic Network as a whole, not individual systems in isolation. For example, the same failure symptom should not be reported from every system that observes it, but only once for the Autonomic Network as a whole. Ultimately, the Autonomic Network should support exception-based management, in which only events that truly require user attention actually cause the user to be notified. This requires capabilities that allow systems within the network to compare information and apply specific algorithms to determine what should be reported.
オートノミックネットワークイベントは、独立した個々のシステムではなく、オートノミックネットワーク全体に関係する必要があります。たとえば、同じ障害の症状は、それを監視するすべてのシステムから報告されるのではなく、オートノミックネットワーク全体で1回だけ報告されます。最終的に、オートノミックネットワークは例外ベースの管理をサポートする必要があります。この場合、ユーザーの注意を本当に必要とするイベントだけが実際にユーザーに通知されます。これには、ネットワーク内のシステムが情報を比較し、特定のアルゴリズムを適用して何を報告すべきかを決定できる機能が必要です。
[RFC7576] points out that there are already a number of autonomic functions available today. However, they are largely independent, and each has its own methods and protocols to communicate, discover, define, and distribute policy, etc.
[RFC7576]は、今日利用可能なオートノミック機能がすでにいくつかあることを指摘しています。ただし、それらは主に独立しており、それぞれがポリシーなどを通信、発見、定義、および配布するための独自のメソッドとプロトコルを持っています。
The goal of the work on Autonomic Networking in the IETF is therefore not just to create autonomic functions but to define a common infrastructure that autonomic functions can use. This Autonomic Networking Infrastructure may contain common control and management functions such as messaging, service discovery, negotiation, Intent distribution, self-monitoring, and diagnostics, etc. A common approach to define and manage Intent is also required.
したがって、IETFでのオートノミックネットワーキングに関する作業の目標は、オートノミック機能を作成するだけでなく、オートノミック機能が使用できる共通インフラストラクチャを定義することです。このオートノミックネットワーキングインフラストラクチャには、メッセージング、サービスディスカバリ、ネゴシエーション、インテントの配布、自己監視、診断などの一般的な制御および管理機能が含まれる場合があります。インテントを定義および管理するための共通のアプローチも必要です。
Refer to the reference model below: All the components around the "Autonomic Service Agents" should be common components, such that the Autonomic Service Agents do not have to replicate common tasks individually.
以下の参照モデルを参照してください。「オートノミックサービスエージェント」の周囲のすべてのコンポーネントは、オートノミックサービスエージェントが共通のタスクを個別に複製する必要がないように、共通のコンポーネントである必要があります。
Autonomic functions may reside on any layer in the networking stack. For example, Layer 2 switching today is already relatively autonomic in many environments, since most switches can be plugged together in many ways and will automatically build a simple Layer 2 topology. Routing functions run on a higher layer and can be autonomic on Layer 3. Even application-layer functionality such as unified communications can be autonomic.
オートノミック機能は、ネットワークスタックの任意のレイヤーに常駐できます。たとえば、ほとんどのスイッチはさまざまな方法で接続でき、簡単なレイヤー2トポロジーを自動的に構築するため、今日のレイヤー2スイッチングはすでに多くの環境で比較的自律型です。ルーティング機能は上位層で実行され、レイヤー3でオートノミックにすることができます。ユニファイドコミュニケーションなどのアプリケーションレイヤー機能でさえオートノミックにすることができます。
"Autonomic" in the context of this framework is a property of a function that is implemented on a node. Autonomic functions can be implemented on any node type, for example, a switch, router, server, or call manager.
このフレームワークのコンテキストでの「オートノミック」は、ノードに実装されている関数のプロパティです。オートノミック機能は、スイッチ、ルーター、サーバー、コールマネージャーなど、任意のノードタイプに実装できます。
An Autonomic Network requires an overall control plane for autonomic nodes to communicate. As in general IP networking, IP is the spanning layer that binds all those elements together; autonomic functions in the context of this framework should therefore operate at the IP layer. This concerns neighbor discovery protocols and other functions in the Autonomic Control Plane.
オートノミックネットワークでは、オートノミックノードが通信するための全体的なコントロールプレーンが必要です。一般的なIPネットワーキングと同様に、IPはこれらすべての要素を結合するスパニングレイヤーです。したがって、このフレームワークのコンテキストにおけるオートノミック機能は、IPレイヤーで動作する必要があります。これは、オートノミックコントロールプレーンのネイバー探索プロトコルとその他の機能に関係します。
An autonomic function does not depend on external input to operate; it needs to understand its current situation and surroundings and operate according to its current state. Therefore, an autonomic function must understand the full life cycle of the device it runs on, from manufacturing and initial testing through deployment, testing, troubleshooting, and decommissioning.
オートノミック機能は、動作する外部入力に依存しません。現在の状況と環境を理解し、現在の状態に従って動作する必要があります。したがって、オートノミック機能は、製造および初期テストからデプロイメント、テスト、トラブルシューティング、および廃止まで、デバイスが稼働するデバイスのライフサイクル全体を理解する必要があります。
The state of the life cycle of an autonomic node is reflected in a state model. The behavior of an autonomic function may be different for different deployment states.
自律ノードのライフサイクルの状態は、状態モデルに反映されます。自律機能の動作は、デプロイメントの状態によって異なる場合があります。
This section identifies various items that are explicitly not design goals in the IETF and IRTF for Autonomic Networks; they are mentioned to avoid misunderstandings of the general intention. They address some commonly expressed concerns from network administrators and architects.
このセクションでは、オートノミックネットワークのIETFおよびIRTFの設計目標ではないさまざまな項目を識別します。それらは一般的な意図の誤解を避けるために言及されています。彼らは、ネットワーク管理者やアーキテクトから一般的に表明された懸念に対処します。
Section 3.1 states that "It is the design goal to make functions [...] minimally dependent on [...] human operators". However, it is not a design goal to completely eliminate them. The problem targeted by Autonomic Networking is the error-prone and hard-to-scale model of individual configuration of network elements, traditionally by manual commands but today mainly by scripting and/or configuration management databases. This does not, however, imply the elimination of skilled human operators, who will still be needed for oversight, policy management, diagnosis, reaction to help-desk tickets, etc. The main impact on administrators should be less tedious detailed work and more high-level work. (They should become more like doctors than hospital orderlies.)
セクション3.1は、「機能を人間のオペレーターに最小限に依存することは設計目標である」と述べています。ただし、それらを完全に排除することは設計目標ではありません。オートノミックネットワーキングの対象となる問題は、ネットワーク要素の個々の構成のエラーが発生しやすく、スケーリングが難しいモデルです。ただし、これは、監視、ポリシー管理、診断、ヘルプデスクチケットへの対応などに必要な熟練した人間のオペレーターの排除を意味するものではありません。レベルの作業。 （彼らは病院の秩序よりも医者のようになるべきです。）
However good the autonomous mechanisms, sometimes there will be fault conditions, etc., that they cannot deal with correctly. At that point, skilled operator interventions will be needed to correct or work around the problem. Hopefully, this can be done by high-level mechanisms (adapting the policy database in some way), but, in some cases, direct intervention at the device level may be unavoidable. This is obviously the case for hardware failures, even if the Autonomic Network has bypassed the fault for the time being. "Truck rolls" will not be eliminated when faulty equipment needs to be replaced. However, this may be less urgent if the autonomic system automatically reconfigures to minimize the operational impact.
どのように自律メカニズムが優れていても、障害状態などがあり、正しく処理できない場合があります。その時点で、問題を修正または回避するには、熟練したオペレーターの介入が必要になります。うまくいけば、これは高レベルのメカニズム（何らかの方法でポリシーデータベースを適応させる）で実行できますが、場合によっては、デバイスレベルでの直接的な介入が避けられないことがあります。オートノミックネットワークが当面は障害を回避したとしても、これは明らかにハードウェア障害の場合です。故障した機器の交換が必要な場合でも、「トラックロール」は削除されません。ただし、オートノミックシステムが操作上の影響を最小限に抑えるために自動的に再構成する場合、これは緊急性が低くなる可能性があります。
While it is a goal to simplify northbound interfaces (Section 3.5), it is not a goal to eliminate central control, but to allow it on a higher abstraction level. Senior management might fear loss of control of an Autonomic Network. In fact, this is no more likely than with a traditional network; the emphasis on automatically applying general policy and security rules might even provide more central control.
ノースバウンドインターフェイスを簡素化することが目標ですが（セクション3.5）、中央制御をなくすことは目標ではなく、より高い抽象化レベルでそれを可能にすることです。上級管理職は、オートノミックネットワークの制御の喪失を恐れるかもしれません。実際、これは従来のネットワークよりも可能性が高いです。一般的なポリシーとセキュリティルールを自動的に適用することに重点を置くと、より集中的な制御が可能になる場合もあります。
An Autonomic Network consists of Autonomic Nodes. Those nodes communicate with each other through an Autonomic Control Plane that provides a robust and secure communications overlay. The Autonomic Control Plane is self-organizing and autonomic itself.
オートノミックネットワークは、オートノミックノードで構成されます。これらのノードは、堅牢で安全な通信オーバーレイを提供するオートノミックコントロールプレーンを介して相互に通信します。オートノミックコントロールプレーンは自己組織化し、オートノミック自体です。
An Autonomic Node contains various elements, such as autonomic service agents that implement autonomic functions. Figure 1 shows a reference model of an autonomic node. The elements and their interaction are:
オートノミックノードには、オートノミック機能を実装するオートノミックサービスエージェントなどのさまざまな要素が含まれています。図1は、自律ノードの参照モデルを示しています。要素とその相互作用は次のとおりです。
o Autonomic Service Agents: They implement the autonomic behavior of a specific service or function.
o オートノミックサービスエージェント：特定のサービスまたは機能のオートノミック動作を実装します。
o Self-knowledge: An autonomic node knows its own properties and capabilities
o 自己認識：自律ノードは自身の特性と機能を知っています
o Network Knowledge (Discovery): An Autonomic Service Agent may require various discovery functions in the network, such as service discovery.
o ネットワークナレッジ（ディスカバリー）：オートノミックサービスエージェントは、サービスディスカバリーなど、ネットワーク内のさまざまなディスカバリー機能を必要とする場合があります。
o Feedback Loops: Control elements outside the node may interact with autonomic nodes through feedback loops.
o フィードバックループ：ノード外の制御要素は、フィードバックループを介して自律ノードと相互作用する場合があります。
o An Autonomic User Agent, providing a front-end to external users (administrators and management applications) through which they can receive reports and monitor the Autonomic Network.
o Autonomic User Agentは、外部ユーザー（管理者および管理アプリケーション）にフロントエンドを提供し、それを介してレポートを受信し、Autonomic Networkを監視できます。
o Autonomic Control Plane: Allows the node to communicate with other autonomic nodes. Autonomic functions such as Intent distribution, feedback loops, discovery mechanisms, etc., use the Autonomic Control Plane. The Autonomic Control Plane can run in-band, over a configured VPN, over a self-managing overlay network as described in [ACP], or over a traditional out-of-band network. Security is a requirement for the Autonomic Control Plane, which can be bootstrapped by a mechanism as described in [BOOTSTRAP].
o オートノミックコントロールプレーン：ノードが他のオートノミックノードと通信できるようにします。インテント分散、フィードバックループ、検出メカニズムなどのオートノミック機能は、オートノミックコントロールプレーンを使用します。オートノミックコントロールプレーンは、帯域内、構成されたVPN経由、[ACP]で説明されている自己管理オーバーレイネットワーク経由、または従来の帯域外ネットワーク経由で実行できます。セキュリティはオートノミックコントロールプレーンの要件であり、[BOOTSTRAP]で説明されているメカニズムでブートストラップできます。
+------------------------------------------------------------+
| +------------+ |
| | Feedback | |
| | Loops | |
| +------------+ |
| ^ |
| Autonomic User Agent |
| V |
| +-----------+ +------------+ +------------+ |
| | Self- | | Autonomic | | Network | |
| | knowledge |<------>| Service |<------>| Knowledge | |
| | | | Agents | | (Discovery)| |
| +-----------+ +------------+ +------------+ |
| ^ ^ |
| | | |
| V V |
|------------------------------------------------------------|
| Autonomic Control Plane |
|------------------------------------------------------------|
| Standard Operating System Functions |
+------------------------------------------------------------+
Figure 1: Reference Model for an Autonomic Node
図1：自律ノードの参照モデル
At the time of finalizing this document, this reference model is being worked out in more detail. See [Reference-Model] for more details.
このドキュメントを完成させる時点で、この参照モデルはより詳細に検討されています。詳細については、[参照モデル]を参照してください。
This document provides definitions and design goals for Autonomic Networking. A full threat analysis will be required as part of the development of solutions, taking account of potential attacks from within the network as well as from outside.
このドキュメントでは、オートノミックネットワーキングの定義と設計目標について説明します。ソリューションの開発の一環として、ネットワーク内外からの潜在的な攻撃を考慮した完全な脅威分析が必要になります。
[ACP] Behringer, M., Bjarnason, S., BL, B., and T. Eckert, "An Autonomic Control Plane", Work in Progress, draft-behringer-anima-autonomic-control-plane-02, March 2015.
[ACP] Behringer、M.、Bjarnason、S.、BL、B。、およびT. Eckert、「An Autonomic Control Plane」、Work in Progress、draft-behringer-anima-autonomic-control-plane-02、2015年3月。
[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月。
[BOOTSTRAP] Pritikin, M., Behringer, M., and S. Bjarnason, "Bootstrapping Key Infrastructures", Work in Progress, draft-pritikin-anima-bootstrapping-keyinfra-01, February 2015.
[ブートストラップ] Pritikin、M.、Behringer、M。、およびS. Bjarnason、「Bootstrapping Key Infrastructures」、Work in Progress、draft-pritikin-anima-bootstrapping-keyinfra-01、2015年2月。
[Dobson] Dobson, S., Denazis, S., Fernandez, A., Gaiti, D., Gelenbe, E., Massacci, F., Nixon, P., Saffre, F., Schmidt, N., and F. Zambonelli, "A survey of autonomic communications", ACM Transactions on Autonomous and Adaptive Systems (TAAS), Volume 1, Issue 2, Pages 223-259, DOI 10.1145/1186778.1186782, December 2006.
[ドブソン]ドブソン、S、デナジス、S、フェルナンデス、A、ガイティ、D、ゲレンベ、E、マサッチ、F、ニクソン、P、サフレ、F、シュミット、N、F Zambonelli、「自律通信の調査」、自律適応システム（TAAS）のACMトランザクション、第1巻、第2号、第223-259頁、DOI 10.1145 / 1186778.1186782、2006年12月。
[GANA] ETSI, "Autonomic network engineering for the self-managing Future Internet (AFI); Generic Autonomic Network Architecture (An Architectural Reference Model for Autonomic Networking, Cognitive Networking and Self-Management)", ETSI GS AFI 002, April 2013, <http://www.etsi.org/deliver/etsi_gs/ AFI/001_099/002/01.01.01_60/gs_afi002v010101p.pdf>.
[GANA] ETSI、「自己管理型フューチャーインターネット（AFI）のためのオートノミックネットワークエンジニアリング、汎用オートノミックネットワークアーキテクチャ（オートノミックネットワーキング、コグニティブネットワーキング、および自己管理のためのアーキテクチャ参照モデル）」、ETSI GS AFI 002、2013年4月、 <http://www.etsi.org/deliver/etsi_gs/ AFI / 001_099 / 002 / 01.01.01_60 / gs_afi002v010101p.pdf>。
[Kephart] Kephart, J. and D. Chess, "The Vision of Autonomic Computing", IEEE Computer, vol. 36, no. 1, pp. 41-50, DOI 10.1109/MC.2003.1160055, January 2003.
[ケファート]ケファートJ.およびD.チェス、「オートノミックコンピューティングのビジョン」、IEEE Computer、vol。 36、いいえ。 1、pp。41-50、DOI 10.1109 / MC.2003.1160055、2003年1月。
[Movahedi] Movahedi, Z., Ayari, M., Langar, R., and G. Pujolle, "A Survey of Autonomic Network Architectures and Evaluation Criteria", IEEE Communications Surveys & Tutorials, Volume 14, Issue 2, Pages 464-490, DOI 10.1109/SURV.2011.042711.00078, 2012.
[Movahedi] Movahedi、Z.、Ayari、M.、Langar、R.、and G. Pujolle、 "A Survey of Autonomic Network Architectures and Evaluation Criteria"、IEEE Communications Surveys＆Tutorials、Volume 14、Issue 2、Pages 464- 490、DOI 10.1109 / SURV.2011.042711.00078、2012。
[Reference-Model] Behringer, M., Ed., Carpenter, B., Eckert, T., Ciavaglia, L., and B. Liu, "A Reference Model for Autonomic Networking", Work in Progress, draft-behringer-anima-reference-model-02, June 2015.
[参照モデル] Behringer、M.、Ed。、Carpenter、B.、Eckert、T.、Ciavaglia、L.、and B. Liu、 "A Reference Model for Autonomic Networking"、Work in Progress、draft-behringer- anima-reference-model-02、2015年6月。
[RFC7576] Jiang, S., Carpenter, B., and M. Behringer, "General Gap Analysis for Autonomic Networking", RFC 7576, DOI 10.17487/RFC7576, June 2015, <http://www.rfc-editor.org/info/rfc7576>.
[RFC7576] Jiang、S.、Carpenter、B。、およびM. Behringer、「Autonomic Networkingの一般的なギャップ分析」、RFC 7576、DOI 10.17487 / RFC7576、2015年6月、<http://www.rfc-editor.org / info / rfc7576>。
[Samaan] Samaan, N. and A. Karmouch, "Towards Autonomic Network Management: an Analysis of Current and Future Research Directions", IEEE Communications Surveys and Tutorials, Volume 11, Issue 3, Page(s) 22-36, DOI 10.1109/SURV.2009.090303, 2009.
[Samaan] Samaan、N。およびA. Karmouch、「オートノミックネットワーク管理に向けて：現在および将来の研究方向の分析」、IEEEコミュニケーション調査およびチュートリアル、第11巻、第3号、22〜36ページ、DOI 10.1109 /SURV.2009.090303、2009。
Acknowledgements
謝辞
Many parts of this work on Autonomic Networking are the result of a large team project at Cisco Systems. In alphabetical order: Ignas Bagdonas, Parag Bhide, Balaji BL, Toerless Eckert, Yves Hertoghs, Bruno Klauser.
オートノミックネットワーキングに関するこの作業の多くの部分は、シスコシステムズでの大規模なチームプロジェクトの結果です。アルファベット順：Ignas Bagdonas、Parag Bhide、Balaji BL、Toerless Eckert、Yves Hertoghs、Bruno Klauser。
We thank the following people for their input to this document: Dimitri Papadimitriou, Rene Struik, Kostas Pentikousis, Dave Oran, and Diego Lopez Garcia.
この文書へのご意見、ご感想をお寄せいただきましたDimitri Papadimitriou、Rene Struik、Kostas Pentikousis、Dave Oran、Diego Lopez Garciaに感謝いたします。
The ETSI working group AFI <http://portal.etsi.org/afi> defines a similar framework for Autonomic Networking in the "General Autonomic Network Architecture" [GANA]. Many concepts explained in this document can be mapped to the GANA framework. The mapping is outside the scope of this document. Special thanks to Ranganai Chaparadza for his comments and help on this document.
ETSIワーキンググループAFI <http://portal.etsi.org/afi>は、「General Autonomic Network Architecture」[GANA]でオートノミックネットワーキングの同様のフレームワークを定義しています。このドキュメントで説明されている多くの概念をGANAフレームワークにマッピングできます。マッピングはこのドキュメントの範囲外です。 Ranganai Chaparadza氏のコメントとこのドキュメントに関する助力に感謝します。
Authors' Addresses
著者のアドレス
Michael H. Behringer Cisco Systems Building D, 45 Allee des Ormes Mougins 06250 France
マイケルH.ベーリンガーシスコシステムズビルディングD、45アリーデオルムムジャン06250フランス
EMail: mbehring@cisco.com
Max Pritikin Cisco Systems 5330 Airport Blvd Boulder, CO 80301 United States
Max Pritikin Cisco Systems 5330 Airport Blvd Boulder、CO 80301 United States
EMail: pritikin@cisco.com
Steinthor Bjarnason Cisco Systems Mail Stop LYS01/5 Philip Pedersens vei 1 LYSAKER, AKERSHUS 1366 Norway
Steinthor Bjarnason Cisco Systems Mail Stop LYS01 / 5 Philip Pedersens vei 1 LYSAKER、AKERSHUS 1366 Norway
EMail: sbjarnas@cisco.com Alexander Clemm Cisco Systems 170 West Tasman Drive San Jose, CA 95134-1706 United States
Eメール：sbjarnas@cisco.com Alexander Clemm Cisco Systems 170 West Tasman Drive San Jose、CA 95134-1706 United States
EMail: alex@cisco.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
Sheng Jiang Huawei Technologies Co., Ltd Q14, Huawei Campus No.156 Beiqing Road Hai-Dian District, Beijing 100095 China
S横江胡Aはテクノロジーズ株式会社Q14、胡Aはキャンパスno.156ですi青道路H艾-Dイアン地区、北京100095中国
EMail: jiangsheng@huawei.com
Laurent Ciavaglia Alcatel Lucent Route de Villejust Nozay 91620 France
Laurent Ciavaglia Alcatel Lucent Route de Villejust Nozay 91620フランス
EMail: laurent.ciavaglia@alcatel-lucent.com