[要約] RFC 7426は、ソフトウェア定義ネットワーキング（SDN）のレイヤとアーキテクチャの用語に関する要約です。このRFCの目的は、SDNの概念と用語を明確に定義し、SDNの実装と展開を支援することです。
Internet Research Task Force (IRTF) E. Haleplidis, Ed.
Request for Comments: 7426 University of Patras
Category: Informational K. Pentikousis, Ed.
ISSN: 2070-1721 EICT
S. Denazis
University of Patras
J. Hadi Salim
Mojatatu Networks
D. Meyer
Brocade
O. Koufopavlou
University of Patras
January 2015
Software-Defined Networking (SDN): Layers and Architecture Terminology
ソフトウェア定義ネットワーク（SDN）：レイヤーとアーキテクチャの用語
Abstract
概要
Software-Defined Networking (SDN) refers to a new approach for network programmability, that is, the capacity to initialize, control, change, and manage network behavior dynamically via open interfaces. SDN emphasizes the role of software in running networks through the introduction of an abstraction for the data forwarding plane and, by doing so, separates it from the control plane. This separation allows faster innovation cycles at both planes as experience has already shown. However, there is increasing confusion as to what exactly SDN is, what the layer structure is in an SDN architecture, and how layers interface with each other. This document, a product of the IRTF Software-Defined Networking Research Group (SDNRG), addresses these questions and provides a concise reference for the SDN research community based on relevant peer-reviewed literature, the RFC series, and relevant documents by other standards organizations.
Software-Defined Networking（SDN）は、ネットワークプログラマビリティの新しいアプローチ、つまり、オープンインターフェイスを介してネットワークの動作を動的に初期化、制御、変更、および管理する機能を指します。 SDNは、データ転送プレーンの抽象化を導入することにより、ネットワークの実行におけるソフトウェアの役割を強調し、そうすることで、コントロールプレーンから分離します。この分離により、経験がすでに示しているように、両方の飛行機でより迅速なイノベーションサイクルが可能になります。ただし、SDNとは正確に何であるか、SDNアーキテクチャーのレイヤー構造とは何か、レイヤー同士がどのようにやり取りするかについては、ますます混乱が生じています。このドキュメントは、IRTF Software-Defined Networking Research Group（SDNRG）の製品であり、これらの質問に対応し、関連するピアレビュー文献、RFCシリーズ、および他の標準化団体による関連ドキュメントに基づいて、SDN研究コミュニティに簡潔なリファレンスを提供します。
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 Software-Defined Networking 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）のSoftware-Defined Networking 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/rfc7426.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7426で入手できます。
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 ....................................................4
2. Terminology .....................................................5
3. SDN Layers and Architecture .....................................7
3.1. Overview ...................................................9
3.2. Network Devices ...........................................12
3.3. Control Plane .............................................13
3.4. Management Plane ..........................................14
3.5. Discussion of Control and Management Planes ...............16
3.5.1. Timescale ..........................................16
3.5.2. Persistence ........................................16
3.5.3. Locality ...........................................16
3.5.4. CAP Theorem Insights ...............................17
3.6. Network Services Abstraction Layer ........................18
3.7. Application Plane .........................................19
4. SDN Model View .................................................19
4.1. ForCES ....................................................19
4.2. NETCONF/YANG ..............................................20
4.3. OpenFlow ..................................................21
4.4. Interface to the Routing System ...........................21
4.5. SNMP ......................................................22
4.6. PCEP ......................................................23
4.7. BFD .......................................................23
5. Summary ........................................................24
6. Security Considerations ........................................24
7. Informative References .........................................25
Acknowledgements ..................................................33
Contributors ......................................................34
Authors' Addresses ................................................34
"Software-Defined Networking (SDN)" is a term of the programmable networks paradigm [PNSurvey99] [OF08]. In short, SDN refers to the ability of software applications to program individual network devices dynamically and therefore control the behavior of the network as a whole [NV09]. Boucadair and Jacquenet [RFC7149] point out that SDN is a set of techniques used to facilitate the design, delivery, and operation of network services in a deterministic, dynamic, and scalable manner.
「ソフトウェア定義ネットワーク（SDN）」は、プログラム可能なネットワークパラダイム[PNSurvey99] [OF08]の用語です。つまり、SDNとは、ソフトウェアアプリケーションが個々のネットワークデバイスを動的にプログラムし、ネットワーク全体の動作を制御する機能を指します[NV09]。 Boucadair and Jacquenet [RFC7149]は、SDNがネットワークサービスの設計、配信、および運用を決定論的、動的、およびスケーラブルな方法で促進するために使用される一連の技術であることを指摘しています。
A key element in SDN is the introduction of an abstraction between the (traditional) forwarding and control planes in order to separate them and provide applications with the means necessary to programmatically control the network. The goal is to leverage this separation, and the associated programmability, in order to reduce complexity and enable faster innovation at both planes [A4D05].
SDNの重要な要素は、（従来の）フォワーディングプレーンとコントロールプレーンの間に抽象化を導入して、それらを分離し、プログラムでネットワークを制御するために必要な手段をアプリケーションに提供することです。目標は、この分離と関連するプログラマビリティを活用して、複雑さを軽減し、両方の面でより迅速なイノベーションを可能にすることです[A4D05]。
The historical evolution of the research and development area of programmable networks is reviewed in detail in [SDNHistory] [SDNSurvey], starting with efforts dating back to the 1980s. As documented in [SDNHistory], many of the ideas, concepts, and concerns are applicable to the latest research and development in SDN (and SDN standardization) and have been under extensive investigation and discussion in the research community for quite some time. For example, Rooney, et al. [Tempest] discuss how to allow third-party access to the network without jeopardizing network integrity or how to accommodate legacy networking solutions in their (then new) programmable environment. Further, the concept of separating the control and forwarding planes, which is prominent in SDN, has been extensively discussed even prior to 1998 [Tempest] [P1520] in SS7 networks [ITUSS7], Ipsilon Flow Switching [RFC1953] [RFC2297], and ATM [ITUATM].
プログラマブルネットワークの研究開発領域の歴史的な進化は、[SDNHistory] [SDNSurvey]で詳細にレビューされており、1980年代にさかのぼる取り組みから始まります。 [SDNHistory]で文書化されているように、アイデア、概念、および懸念の多くは、SDN（およびSDN標準化）の最新の研究開発に適用可能であり、かなり長い間、研究コミュニティで広範な調査と議論の下にありました。例えば、ルーニーら。 [テンペスト]は、ネットワークの整合性を危険にさらすことなくサードパーティによるネットワークへのアクセスを許可する方法、または（新しい）プログラマブル環境でレガシーネットワーキングソリューションに対応する方法について説明します。さらに、SDNで顕著であるコントロールプレーンとフォワーディングプレーンの分離の概念は、SS7ネットワーク[ITUSS7]、イプシロンフロースイッチング[RFC1953] [RFC2297]で1998 [Tempest] [P1520]より前まで広く議論されてきました。 ATM [ITUATM]。
SDN research often focuses on varying aspects of programmability, and we are frequently confronted with conflicting points of view regarding what exactly SDN is. For instance, we find that for various reasons (e.g., work focusing on one domain and therefore not necessarily applicable as-is to other domains), certain well-accepted definitions do not correlate well with each other. For example, both OpenFlow [OpenFlow] and the Network Configuration Protocol (NETCONF) [RFC6241] have been characterized as SDN interfaces, but they refer to control and management, respectively.
SDNの調査は、多くの場合、プログラマビリティのさまざまな側面に焦点を当てており、SDNとは正確には何であるかについて、対立する視点に直面することがよくあります。たとえば、さまざまな理由（たとえば、1つのドメインに焦点を当てているため、必ずしも他のドメインにそのまま適用できるとは限らない）のために、特定の十分に受け入れられている定義が互いに適切に関連付けられていないことがわかりました。たとえば、OpenFlow [OpenFlow]とネットワーク構成プロトコル（NETCONF）[RFC6241]はどちらもSDNインターフェイスとして特徴付けられていますが、それぞれ制御と管理を指します。
This motivates us to consolidate the definitions of SDN in the literature and correlate them with earlier work at the IETF and the research community. Of particular interest is, for example, to determine which layers comprise the SDN architecture and which interfaces and their corresponding attributes are best suited to be used between them. As such, the aim of this document is not to standardize any particular layer or interface but rather to provide a concise reference that reflects current approaches regarding the SDN layer architecture. We expect that this document would be useful to upcoming work in SDNRG as well as future discussions within the SDN community as a whole.
これは、文献におけるSDNの定義を統合し、それらをIETFおよび研究コミュニティでの以前の研究と相関させる動機になります。特に興味深いのは、たとえば、SDNアーキテクチャを構成するレイヤーと、それらの間で使用するのに最適なインターフェイスとそれに対応する属性を決定することです。したがって、このドキュメントの目的は、特定のレイヤーやインターフェイスを標準化することではなく、SDNレイヤーアーキテクチャに関する現在のアプローチを反映した簡潔なリファレンスを提供することです。このドキュメントは、SDNRGでの今後の作業だけでなく、SDNコミュニティ全体での今後の議論にも役立つと期待しています。
This document addresses the work item in the SDNRG charter titled "Survey of SDN approaches and Taxonomies", fostering better understanding of prominent SDN technologies in a technology-impartial and business-agnostic manner but does not constitute a new IETF standard. It is meant as a common base for further discussion. As such, we do not make any value statements nor discuss the applicability of any of the frameworks examined in this document for any particular purpose. Instead, we document their characteristics and attributes and classify them, thus providing a taxonomy. This document does not intend to provide an exhaustive list of SDN research issues; interested readers should consider reviewing [SLTSDN] and [SDNACS]. In particular, Jarraya, et al. [SLTSDN] provide an overview of SDN-related research topics, e.g., control partitioning, which is related to the Consistency, Availability and Partitioning (CAP) theorem discussed in Section 3.5.4.
このドキュメントは、SDNRG憲章の「SDNアプローチと分類法の調査」というタイトルの作業項目を扱い、テクノロジーに公平でビジネスにとらわれない方法で著名なSDNテクノロジーの理解を深めますが、新しいIETF標準を構成するものではありません。これは、さらに議論するための共通の基盤として意図されています。そのため、特定の目的のために、このドキュメントで検討したフレームワークの適用性について、価値を表明したり、論じたりすることはありません。代わりに、それらの特性と属性を文書化して分類し、分類法を提供します。このドキュメントは、SDNの調査問題の完全なリストを提供することを意図していません。関心のある読者は、[SLTSDN]と[SDNACS]を確認することを検討してください。特に、Jarrayaら。 [SLTSDN]は、セクション3.5.4で説明されている一貫性、可用性、パーティショニング（CAP）の定理に関連するSDN関連の研究トピック、たとえば、コントロールパーティショニングの概要を提供します。
This document has been extensively reviewed, discussed, and commented by the vast majority of SDNRG members, a community that certainly exceeds 100 individuals. It is the consensus of SDNRG that this document should be published in the IRTF stream of the RFC series [RFC5743].
この文書は、100人を超えるコミュニティーであるSDNRGメンバーの圧倒的多数によって広範囲にレビュー、議論、コメントされています。この文書がRFCシリーズ[RFC5743]のIRTFストリームで公開されることは、SDNRGの合意です。
The remainder of this document is organized as follows. Section 2 explains the terminology used in this document. Section 3 introduces a high-level overview of current SDN architecture abstractions. Finally, Section 4 discusses how the SDN layer architecture relates to prominent SDN-enabling technologies.
このドキュメントの残りの部分は、次のように構成されています。セクション2では、このドキュメントで使用されている用語について説明します。セクション3では、現在のSDNアーキテクチャの抽象化の概要を紹介します。最後に、セクション4では、SDNレイヤーアーキテクチャが、著名なSDN対応テクノロジーにどのように関連するかについて説明します。
This document uses the following terms:
このドキュメントでは、次の用語を使用します。
o Software-Defined Networking (SDN) - A programmable networks approach that supports the separation of control and forwarding planes via standardized interfaces.
o Software-Defined Networking（SDN）-標準化されたインターフェースを介して制御プレーンと転送プレーンの分離をサポートするプログラム可能なネットワークアプローチ。
o Resource - A physical or virtual component available within a system. Resources can be very simple or fine-grained (e.g., a port or a queue) or complex, comprised of multiple resources (e.g., a network device).
o リソース-システム内で使用可能な物理または仮想コンポーネント。リソースは、非常に単純なものでも細かいもの（ポートやキューなど）でも、複数のリソース（ネットワークデバイスなど）で構成される複雑なものでもかまいません。
o Network Device - A device that performs one or more network operations related to packet manipulation and forwarding. This reference model makes no distinction whether a network device is physical or virtual. A device can also be considered as a container for resources and can be a resource in itself.
o ネットワークデバイス-パケットの操作と転送に関連する1つ以上のネットワーク操作を実行するデバイス。この参照モデルでは、ネットワークデバイスが物理デバイスか仮想デバイスかは区別されません。デバイスは、リソースのコンテナと見なすこともでき、それ自体がリソースになることもあります。
o Interface - A point of interaction between two entities. When the entities are placed at different locations, the interface is usually implemented through a network protocol. If the entities are collocated in the same physical location, the interface can be implemented using a software application programming interface (API), inter-process communication (IPC), or a network protocol.
o インターフェイス-2つのエンティティ間の相互作用のポイント。エンティティが異なる場所に配置されている場合、インターフェイスは通常、ネットワークプロトコルを介して実装されます。エンティティが同じ物理的な場所に配置されている場合、ソフトウェアアプリケーションプログラミングインターフェイス（API）、プロセス間通信（IPC）、またはネットワークプロトコルを使用してインターフェイスを実装できます。
o Application (App) - An application in the context of SDN is a piece of software that utilizes underlying services to perform a function. Application operation can be parameterized, for example, by passing certain arguments at call time, but it is meant to be a standalone piece of software; an App does not offer any interfaces to other applications or services.
o アプリケーション（アプリ）-SDNのコンテキストでのアプリケーションは、基盤となるサービスを利用して機能を実行するソフトウェアです。たとえば、呼び出し時に特定の引数を渡すことで、アプリケーションの操作をパラメーター化できますが、これはスタンドアロンのソフトウェアであることを意図しています。アプリは他のアプリケーションやサービスへのインターフェースを提供しません。
o Service - A piece of software that performs one or more functions and provides one or more APIs to applications or other services of the same or different layers to make use of said functions and returns one or more results. Services can be combined with other services, or called in a certain serialized manner, to create a new service.
o サービス-1つ以上の機能を実行し、同じまたは異なるレイヤーのアプリケーションまたは他のサービスに1つ以上のAPIを提供して、上記の機能を利用して1つ以上の結果を返すソフトウェア。サービスを他のサービスと組み合わせたり、特定のシリアル化された方法で呼び出したりして、新しいサービスを作成できます。
o Forwarding Plane (FP) - The collection of resources across all network devices responsible for forwarding traffic.
o Forwarding Plane（FP）-トラフィックの転送を担当するすべてのネットワークデバイスにわたるリソースのコレクション。
o Operational Plane (OP) - The collection of resources responsible for managing the overall operation of individual network devices.
o 運用面（OP）-個々のネットワークデバイスの全体的な運用を管理するリソースの集合。
o Control Plane (CP) - The collection of functions responsible for controlling one or more network devices. CP instructs network devices with respect to how to process and forward packets. The control plane interacts primarily with the forwarding plane and, to a lesser extent, with the operational plane.
o コントロールプレーン（CP）-1つ以上のネットワークデバイスの制御を担当する機能の集まり。 CPは、パケットの処理方法と転送方法に関してネットワークデバイスに指示します。コントロールプレーンは、主にフォワーディングプレーンと相互作用しますが、それほどではありませんが、オペレーションプレーンと相互作用します。
o Management Plane (MP) - The collection of functions responsible for monitoring, configuring, and maintaining one or more network devices or parts of network devices. The management plane is mostly related to the operational plane (it is related less to the forwarding plane).
o 管理プレーン（MP）-1つ以上のネットワークデバイスまたはネットワークデバイスの一部を監視、構成、および保守する機能の集合。管理プレーンは、主に運用プレーンに関連しています（転送プレーンにはあまり関連していません）。
o Application Plane - The collection of applications and services that program network behavior.
o アプリケーションプレーン-ネットワークの動作をプログラムするアプリケーションとサービスのコレクション。
o Device and resource Abstraction Layer (DAL) - The device's resource abstraction layer based on one or more models. If it is a physical device, it may be referred to as the Hardware Abstraction Layer (HAL). DAL provides a uniform point of reference for the device's forwarding- and operational-plane resources.
o デバイスおよびリソース抽象化レイヤー（DAL）-1つ以上のモデルに基づくデバイスのリソース抽象化レイヤー。物理デバイスの場合、ハードウェアアブストラクションレイヤー（HAL）と呼ばれることがあります。 DALは、デバイスのフォワーディングプレーンリソースとオペレーショナルプレーンリソースの統一参照ポイントを提供します。
o Control Abstraction Layer (CAL) - The control plane's abstraction layer. CAL provides access to the Control-Plane Southbound Interface.
o コントロールアブストラクションレイヤー（CAL）-コントロールプレーンのアブストラクションレイヤー。 CALは、コントロールプレーンサウスバウンドインターフェイスへのアクセスを提供します。
o Management Abstraction Layer (MAL) - The management plane's abstraction layer. MAL provides access to the Management-Plane Southbound Interface.
o 管理抽象化層（MAL）-管理プレーンの抽象化層。 MALは、管理プレーンサウスバウンドインターフェイスへのアクセスを提供します。
o Network Services Abstraction Layer (NSAL) - Provides service abstractions that can be used by applications and services.
o ネットワークサービスアブストラクションレイヤー（NSAL）-アプリケーションとサービスで使用できるサービスアブストラクションを提供します。
Figure 1 summarizes the SDN architecture abstractions in the form of a detailed, high-level schematic. Note that in a particular implementation, planes can be collocated with other planes or can be physically separated, as we discuss below.
図1は、SDNアーキテクチャの抽象化を詳細な高レベルの回路図の形式で要約したものです。以下で説明するように、特定の実装では、プレーンは他のプレーンと同じ場所に配置することも、物理的に分離することもできます。
SDN is based on the concept of separation between a controlled entity and a controller entity. The controller manipulates the controlled entity via an interface. Interfaces, when local, are mostly API invocations through some library or system call. However, such interfaces may be extended via some protocol definition, which may use local inter-process communication (IPC) or a protocol that could also act remotely; the protocol may be defined as an open standard or in a proprietary manner.
SDNは、制御対象エンティティとコントローラーエンティティの間の分離の概念に基づいています。コントローラーは、インターフェイスを介して被制御エンティティを操作します。インターフェイスは、ローカルの場合、ほとんどの場合、いくつかのライブラリまたはシステムコールを介したAPI呼び出しです。ただし、そのようなインターフェースは、ローカルのプロセス間通信（IPC）またはリモートで動作する可能性のあるプロトコルを使用する可能性があるプロトコル定義を介して拡張できます。プロトコルは、オープンスタンダードとして、または独自の方法で定義できます。
Day [PiNA] explores the use of IPC as the mainstay for the definition of recursive network architectures with varying degrees of scope and range of operation. The Recursive InterNetwork Architecture [RINA] outlines a recursive network architecture based on IPC that capitalizes on repeating patterns and structures. This document does not propose a new architecture -- we simply document previous work through a taxonomy. Although recursion is out of the scope of this work, Figure 1 illustrates a hierarchical model in which layers can be stacked on top of each other and employed recursively as needed.
Day [PiNA]は、さまざまな程度のスコープと動作範囲を持つ再帰ネットワークアーキテクチャの定義の主力としてのIPCの使用を探ります。再帰的インターネットワークアーキテクチャ[RINA]は、繰り返しのパターンと構造を利用するIPCに基づく再帰的ネットワークアーキテクチャの概要を示しています。このドキュメントは新しいアーキテクチャを提案していません-分類法による以前の作業を単にドキュメント化しています。再帰はこの作業の範囲外ですが、図1は、階層を互いに積み重ねて、必要に応じて再帰的に使用できる階層モデルを示しています。
o--------------------------------o
| |
| +-------------+ +----------+ |
| | Application | | Service | |
| +-------------+ +----------+ |
| Application Plane |
o---------------Y----------------o
|
*-----------------------------Y---------------------------------*
| Network Services Abstraction Layer (NSAL) |
*------Y------------------------------------------------Y-------*
| |
| Service Interface |
| |
o------Y------------------o o---------------------Y------o
| | Control Plane | | Management Plane | |
| +----Y----+ +-----+ | | +-----+ +----Y----+ |
| | Service | | App | | | | App | | Service | |
| +----Y----+ +--Y--+ | | +--Y--+ +----Y----+ |
| | | | | | | |
| *----Y-----------Y----* | | *---Y---------------Y----* |
| | Control Abstraction | | | | Management Abstraction | |
| | Layer (CAL) | | | | Layer (MAL) | |
| *----------Y----------* | | *----------Y-------------* |
| | | | | |
o------------|------------o o------------|---------------o
| |
| CP | MP
| Southbound | Southbound
| Interface | Interface
| |
*------------Y---------------------------------Y----------------*
| Device and resource Abstraction Layer (DAL) |
*------------Y---------------------------------Y----------------*
| | | |
| o-------Y----------o +-----+ o--------Y----------o |
| | Forwarding Plane | | App | | Operational Plane | |
| o------------------o +-----+ o-------------------o |
| Network Device |
+---------------------------------------------------------------+
Figure 1: SDN Layer Architecture
図1：SDNレイヤーのアーキテクチャ
This document follows a network-device-centric approach: control mostly refers to the device packet-handling capability, while management typically refers to aspects of the overall device operation. We view a network device as a complex resource that contains and is part of multiple resources similar to [DIOPR]. Resources can be simple, single components of a network device, for example, a port or a queue of the device, and can also be aggregated into complex resources, for example, a network card or a complete network device.
このドキュメントはネットワークデバイス中心のアプローチに従います。管理とは通常、デバイスのパケット処理機能を指しますが、管理とは通常、デバイスの動作全体の側面を指します。ネットワークデバイスは、[DIOPR]と同様の複数のリソースを含み、その一部である複雑なリソースと見なします。リソースは、ネットワークデバイスの単純な単一のコンポーネント（デバイスのポートやキューなど）にすることも、ネットワークカードやネットワークデバイス全体などの複雑なリソースに集約することもできます。
The reader should keep in mind that we make no distinction between "physical" and "virtual" resources or "hardware" and "software" realizations in this document, as we do not delve into implementation or performance aspects. In other words, a resource can be implemented fully in hardware, fully in software, or any hybrid combination in between. Further, we do not distinguish whether a resource is implemented as an overlay or as a part/component of some other device. In general, network device software can run on so-called "bare metal" or on a virtualized substrate. Finally, this document does not discuss how resources are allocated, orchestrated, and released. Indeed, orchestration is out of the scope of this document.
このドキュメントでは、「物理」リソースと「仮想」リソース、または「ハードウェア」と「ソフトウェア」の実現を区別していないことに注意してください。実装やパフォーマンスについては詳しく説明していません。言い換えれば、リソースは完全にハードウェア、完全にソフトウェア、またはその間の任意のハイブリッドの組み合わせで実装できます。さらに、リソースがオーバーレイとして実装されているのか、他のデバイスの一部/コンポーネントとして実装されているのかは区別しません。一般に、ネットワークデバイスソフトウェアは、いわゆる「ベアメタル」または仮想化された基板上で実行できます。最後に、このドキュメントでは、リソースがどのように割り当てられ、調整され、解放されるかについては説明していません。実際、オーケストレーションはこのドキュメントの範囲外です。
SDN spans multiple planes as illustrated in Figure 1. Starting from the bottom part of the figure and moving towards the upper part, we identify the following planes:
図1に示すように、SDNは複数のプレーンにまたがっています。図の下部から開始して上部に向かって、次のプレーンを識別します。
o Forwarding Plane - Responsible for handling packets in the data path based on the instructions received from the control plane. Actions of the forwarding plane include, but are not limited to, forwarding, dropping, and changing packets. The forwarding plane is usually the termination point for control-plane services and applications. The forwarding plane can contain forwarding resources such as classifiers. The forwarding plane is also widely referred to as the "data plane" or the "data path".
o フォワーディングプレーン-コントロールプレーンから受信した指示に基づいて、データパス内のパケットを処理します。転送プレーンのアクションには、パケットの転送、ドロップ、および変更が含まれますが、これらに限定されません。フォワーディングプレーンは、通常、コントロールプレーンのサービスとアプリケーションの終点です。転送プレーンには、分類子などの転送リソースを含めることができます。フォワーディングプレーンは、「データプレーン」または「データパス」とも呼ばれます。
o Operational Plane - Responsible for managing the operational state of the network device, e.g., whether the device is active or inactive, the number of ports available, the status of each port, and so on. The operational plane is usually the termination point for management-plane services and applications. The operational plane relates to network device resources such as ports, memory, and so on. We note that some participants of the IRTF SDNRG have a different opinion in regards to the definition of the operational plane. That is, one can argue that the operational plane does not constitute a "plane" per se, but it is, in practice, an amalgamation of functions on the forwarding plane. For others, however, a "plane" allows one to distinguish between different areas of operations; therefore, the operational plane is included as a "plane" in Figure 1. We have adopted this latter view in this document.
o運用面-ネットワークデバイスの運用状態（デバイスがアクティブか非アクティブか、使用可能なポートの数、各ポートのステータスなど）を管理します。運用面は通常、管理面のサービスとアプリケーションの終点です。オペレーショナルプレーンは、ポート、メモリなどのネットワークデバイスリソースに関連しています。 IRTF SDNRGの一部の参加者は、運用面の定義に関して異なる意見を持っていることに注意します。すなわち、運用面はそれ自体「面」を構成しないと主張することができるが、それは実際には、転送面上の機能の融合である。ただし、他の人にとっては、「平面」によって、操作の異なる領域を区別できます。したがって、運用面は図1の「面」として含まれています。このドキュメントでは、この後者のビューを採用しています。
o Control Plane - Responsible for making decisions on how packets should be forwarded by one or more network devices and pushing such decisions down to the network devices for execution. The control plane usually focuses mostly on the forwarding plane and less on the operational plane of the device. The control plane may be interested in operational-plane information, which could include, for instance, the current state of a particular port or its capabilities. The control plane's main job is to fine-tune the forwarding tables that reside in the forwarding plane, based on the network topology or external service requests.
o コントロールプレーン-1つまたは複数のネットワークデバイスがパケットを転送する方法を決定し、その決定をネットワークデバイスにプッシュして実行します。コントロールプレーンは通常、ほとんどが転送プレーンに重点を置いており、デバイスの運用プレーンには重点を置いていません。コントロールプレーンは、たとえば特定のポートの現在の状態またはその機能を含む運用プレーン情報に関心がある場合があります。コントロールプレーンの主な役割は、ネットワークトポロジまたは外部サービス要求に基づいて、転送プレーンにある転送テーブルを微調整することです。
o Management Plane - Responsible for monitoring, configuring, and maintaining network devices, e.g., making decisions regarding the state of a network device. The management plane usually focuses mostly on the operational plane of the device and less on the forwarding plane. The management plane may be used to configure the forwarding plane, but it does so infrequently and through a more wholesale approach than the control plane. For instance, the management plane may set up all or part of the forwarding rules at once, although such action would be expected to be taken sparingly.
o 管理プレーン-ネットワークデバイスの監視、構成、および保守を担当します。たとえば、ネットワークデバイスの状態に関する決定を行います。管理プレーンは通常、デバイスの運用プレーンに重点を置いており、転送プレーンには重点を置いていません。管理プレーンを使用して転送プレーンを構成できますが、その頻度は低く、コントロールプレーンよりもホールセールアプローチを使用します。たとえば、管理プレーンは転送ルールのすべてまたは一部を一度に設定できますが、そのようなアクションは慎重に行われることが期待されます。
o Application Plane - The plane where applications and services that define network behavior reside. Applications that directly (or primarily) support the operation of the forwarding plane (such as routing processes within the control plane) are not considered part of the application plane. Note that applications may be implemented in a modular and distributed fashion and, therefore, can often span multiple planes in Figure 1.
o アプリケーションプレーン-ネットワークの動作を定義するアプリケーションとサービスが存在するプレーン。直接（または主に）転送プレーンの操作（コントロールプレーン内のルーティングプロセスなど）をサポートするアプリケーションは、アプリケーションプレーンの一部とは見なされません。アプリケーションはモジュール化され分散された方法で実装できるため、図1の複数のプレーンにまたがることが多いことに注意してください。
[RFC7276] has defined the data, control, and management planes in terms of Operations, Administration, and Maintenance (OAM). This document attempts to broaden the terms defined in [RFC7276] in order to reflect all aspects of an SDN architecture.
[RFC7276]は、運用、管理、および保守（OAM）の観点から、データ、制御、および管理プレーンを定義しています。このドキュメントは、SDNアーキテクチャのすべての側面を反映するために、[RFC7276]で定義された用語を拡張することを試みます。
All planes mentioned above are connected via interfaces (indicated with "Y" in Figure 1. An interface may take multiple roles depending on whether the connected planes reside on the same (physical or virtual) device. If the respective planes are designed so that they do not have to reside in the same device, then the interface can only take the form of a protocol. If the planes are collocated on the same device, then the interface could be implemented via an open/ proprietary protocol, an open/proprietary software inter-process communication API, or operating system kernel system calls.
上記のすべてのプレーンは、インターフェースを介して接続されます（図1で「Y」で示されています）。接続されたプレーンが同じ（物理または仮想）デバイス上にあるかどうかに応じて、インターフェースは複数の役割を果たす場合があります。それぞれのプレーンが同じデバイスに存在する必要がない場合、インターフェースはプロトコルの形式のみを取ることができます。プレーンが同じデバイスに配置されている場合、インターフェースはオープン/プロプライエタリプロトコル、オープン/プロプライエタリソフトウェアを介して実装できます。プロセス間通信API、またはオペレーティングシステムのカーネルシステムコール。
Applications, i.e., software programs that perform specific computations that consume services without providing access to other applications, can be implemented natively inside a plane or can span multiple planes. For instance, applications or services can span both the control and management planes and thus be able to use both the Control-Plane Southbound Interface (CPSI) and Management-Plane Southbound Interface (MPSI), although this is only implicitly illustrated in Figure 1. An example of such a case would be an application that uses both [OpenFlow] and [OF-CONFIG].
アプリケーション、つまり、他のアプリケーションへのアクセスを提供せずにサービスを消費する特定の計算を実行するソフトウェアプログラムは、プレーン内にネイティブに実装することも、複数のプレーンにまたがることもできます。たとえば、アプリケーションまたはサービスは、コントロールプレーンと管理プレーンの両方にまたがることができるため、コントロールプレーンサウスバウンドインターフェイス（CPSI）と管理プレーンサウスバウンドインターフェイス（MPSI）の両方を使用できますが、これは暗黙的に図1に示されています。このようなケースの例は、[OpenFlow]と[OF-CONFIG]の両方を使用するアプリケーションです。
Services, i.e., software programs that provide APIs to other applications or services, can also be natively implemented in specific planes. Services that span multiple planes belong to the application plane as well.
サービス、つまり他のアプリケーションやサービスにAPIを提供するソフトウェアプログラムも、特定のプレーンにネイティブに実装できます。複数のプレーンにまたがるサービスは、アプリケーションプレーンにも属します。
While not shown explicitly in Figure 1, services, applications, and entire planes can be placed in a recursive manner, thus providing overlay semantics to the model. For example, application-plane services can be provided to other applications or services through NSAL. Additional examples include virtual resources that are realized on top of a physical resources and hierarchical control-plane controllers [KANDOO].
図1には明示されていませんが、サービス、アプリケーション、およびプレーン全体を再帰的に配置できるため、モデルにオーバーレイセマンティクスを提供できます。たとえば、アプリケーションプレーンサービスは、NSALを介して他のアプリケーションまたはサービスに提供できます。追加の例には、物理リソースおよび階層型コントロールプレーンコントローラー[KANDOO]の上に実現される仮想リソースが含まれます。
Note that the focus in this document is, of course, on the north/ south communication between entities in different planes. But this, clearly, does not exclude entity communication within any one plane.
このドキュメントでは、もちろん、異なる平面にあるエンティティ間の北/南通信に焦点を合わせていることに注意してください。しかし、これは明らかに、1つの平面内のエンティティ通信を排除するものではありません。
It must be noted, however, that in Figure 1, we present an abstract view of the various planes, which is devoid of implementation details. Many implementations in the past have opted for placing the management plane on top of the control plane. This can be interpreted as having the control plane acting as a service to the management plane. Further, in many networks, especially in Internet routers and Ethernet switches, the control plane has been usually implemented as tightly coupled with the network device. When taken as a whole, the control plane has been distributed network-wide. On the other hand, the management plane has been traditionally centralized and has been responsible for managing the control plane and the devices. However, with the adoption of SDN principles, this distinction is no longer so clear-cut.
ただし、図1には、実装の詳細がない、さまざまなプレーンの抽象的なビューが示されていることに注意してください。過去の多くの実装では、管理プレーンをコントロールプレーンの上に配置することを選択していました。これは、コントロールプレーンが管理プレーンへのサービスとして機能していると解釈できます。さらに、多くのネットワーク、特にインターネットルーターやイーサネットスイッチでは、コントロールプレーンは通常、ネットワークデバイスと緊密に結合されて実装されています。全体として見ると、コントロールプレーンはネットワーク全体に分散されています。一方、管理プレーンは従来から集中化されており、コントロールプレーンとデバイスの管理を担当しています。ただし、SDN原則の採用により、この区別はそれほど明確ではなくなりました。
Additionally, this document considers four abstraction layers:
さらに、このドキュメントでは4つの抽象化レイヤーについて検討します。
o The Device and resource Abstraction Layer (DAL) abstracts the resources of the device's forwarding and operational planes to the control and management planes. Variations of DAL may abstract both planes or either of the two and may abstract any plane of the device to either the control or management plane.
o デバイスおよびリソースアブストラクションレイヤー（DAL）は、デバイスの転送および運用プレーンのリソースを制御および管理プレーンに抽象化します。 DALのバリエーションは、両方のプレーンまたは2つのプレーンのいずれかを抽象化し、デバイスのプレーンをコントロールプレーンまたは管理プレーンのいずれかに抽象化します。
o The Control Abstraction Layer (CAL) abstracts the Control-Plane Southbound Interface and the DAL from the applications and services of the control plane.
o コントロールアブストラクションレイヤー（CAL）は、コントロールプレーンのアプリケーションとサービスからコントロールプレーンサウスバウンドインターフェイスとDALを抽象化します。
o The Management Abstraction Layer (MAL) abstracts the Management-Plane Southbound Interface and the DAL from the applications and services of the management plane.
o 管理抽象化レイヤー（MAL）は、管理プレーンのアプリケーションとサービスから管理プレーンサウスバウンドインターフェイスとDALを抽象化します。
o The Network Services Abstraction Layer (NSAL) provides service abstractions for use by applications and other services.
o ネットワークサービスアブストラクションレイヤー（NSAL）は、アプリケーションやその他のサービスで使用するためのサービスアブストラクションを提供します。
At the time of this writing, SDN-related activities have begun in other SDOs. For example, at the ITU, work on architectural [ITUSG13] and signaling requirements and protocols [ITUSG11] has commenced, but the respective study groups have yet to publish their documents, with the exception of [ITUY3300]. The views presented in [ITUY3300] as well as in [ONFArch] are well aligned with this document.
この記事の執筆時点では、SDN関連の活動は他のSDOでも始まっています。たとえば、ITUでは、アーキテクチャ[ITUSG13]と信号要件とプロトコル[ITUSG11]の作業が開始されましたが、[ITUY3300]を除いて、それぞれの研究グループはまだドキュメントを公開していません。 [ITUY3300]および[ONFArch]で提示されている見解は、このドキュメントとよく整合しています。
A network device is an entity that receives packets on its ports and performs one or more network functions on them. For example, the network device could forward a received packet, drop it, alter the packet header (or payload), forward the packet, and so on. A network device is an aggregation of multiple resources such as ports, CPU, memory, and queues. Resources are either simple or can be aggregated to form complex resources that can be viewed as one resource. The network device is in itself a complex resource. Examples of network devices include switches and routers. Additional examples include network elements that may operate at a layer above IP (such as firewalls, load balancers, and video transcoders) or below IP (such as Layer 2 switches and optical or microwave network elements).
ネットワークデバイスは、ポートでパケットを受信し、ポートで1つ以上のネットワーク機能を実行するエンティティです。たとえば、ネットワークデバイスは、受信したパケットの転送、ドロップ、パケットヘッダー（またはペイロード）の変更、パケットの転送などを行うことができます。ネットワークデバイスは、ポート、CPU、メモリ、キューなどの複数のリソースの集合体です。リソースは単純であるか、または集約して複雑なリソースを形成し、1つのリソースとして表示することができます。ネットワークデバイス自体は複雑なリソースです。ネットワークデバイスの例には、スイッチやルーターが含まれます。追加の例には、IPの上のレイヤー（ファイアウォール、ロードバランサー、ビデオトランスコーダーなど）またはIPの下のレイヤー（レイヤー2スイッチ、光またはマイクロ波ネットワークエレメントなど）で動作するネットワーク要素が含まれます。
Network devices can be implemented in hardware or software and can be either physical or virtual. As has already been mentioned before, this document makes no such distinction. Each network device has a presence in a forwarding plane and an operational plane.
ネットワークデバイスは、ハードウェアまたはソフトウェアで実装でき、物理デバイスでも仮想デバイスでもかまいません。前述のとおり、このドキュメントではそのような区別はありません。各ネットワークデバイスは、転送プレーンと運用プレーンに存在します。
The forwarding plane, commonly referred to as the "data path", is responsible for handling and forwarding packets. The forwarding plane provides switching, routing, packet transformation, and filtering functions. Resources of the forwarding plane include but are not limited to filters, meters, markers, and classifiers.
一般に「データパス」と呼ばれる転送プレーンは、パケットの処理と転送を担当します。フォワーディングプレーンは、スイッチング、ルーティング、パケット変換、およびフィルタリング機能を提供します。転送プレーンのリソースには、フィルター、メーター、マーカー、および分類子が含まれますが、これらに限定されません。
The operational plane is responsible for the operational state of the network device, for instance, with respect to status of network ports and interfaces. Operational-plane resources include, but are not limited to, memory, CPU, ports, interfaces, and queues.
オペレーショナルプレーンは、ネットワークポートやインターフェースのステータスなど、ネットワークデバイスの動作状態を担当します。運用面のリソースには、メモリ、CPU、ポート、インターフェイス、およびキューが含まれますが、これらに限定されません。
The forwarding and the operational planes are exposed via the Device and resource Abstraction Layer (DAL), which may be expressed by one or more abstraction models. Examples of forwarding-plane abstraction models are Forwarding and Control Element Separation (ForCES) [RFC5812], OpenFlow [OpenFlow], YANG model [RFC6020], and SNMP MIBs [RFC3418]. Examples of the operational-plane abstraction model include the ForCES model [RFC5812], the YANG model [RFC6020], and SNMP MIBs [RFC3418].
転送プレーンと運用プレーンは、1つ以上の抽象化モデルで表現できるデバイスとリソースの抽象化レイヤー（DAL）を介して公開されます。フォワーディングプレーン抽象化モデルの例は、Forwarding and Control Element Separation（ForCES）[RFC5812]、OpenFlow [OpenFlow]、YANGモデル[RFC6020]、およびSNMP MIB [RFC3418]です。運用面抽象モデルの例には、ForCESモデル[RFC5812]、YANGモデル[RFC6020]、SNMP MIB [RFC3418]が含まれます。
Note that applications can also reside in a network device. Examples of such applications include event monitoring and handling (offloading) topology discovery or ARP [RFC0826] in the device itself instead of forwarding such traffic to the control plane.
アプリケーションはネットワークデバイスに常駐することもできます。そのようなアプリケーションの例には、そのようなトラフィックをコントロールプレーンに転送する代わりに、デバイス自体でのイベントの監視と処理（オフロード）トポロジ検出またはARP [RFC0826]が含まれます。
The control plane is usually distributed and is responsible mainly for the configuration of the forwarding plane using a Control-Plane Southbound Interface (CPSI) with DAL as a point of reference. CP is responsible for instructing FP about how to handle network packets.
コントロールプレーンは通常分散されており、DALを参照ポイントとして使用するコントロールプレーンサウスバウンドインターフェイス（CPSI）を使用した転送プレーンの設定を主に担当します。 CPは、ネットワークパケットの処理方法についてFPに指示する責任があります。
Communication between control-plane entities, colloquially referred to as the "east-west" interface, is usually implemented through gateway protocols such as BGP [RFC4271] or other protocols such as the Path Computation Element (PCE) Communication Protocol (PCEP) [RFC5440]. These corresponding protocol messages are usually exchanged in-band and subsequently redirected by the forwarding plane to the control plane for further processing. Examples in this category include [RCP], [SoftRouter], and [RouteFlow].
コントロールプレーンエンティティ間の通信は、通称「イーストウェスト」インターフェイスと呼ばれ、通常、BGP [RFC4271]などのゲートウェイプロトコルまたはパス計算エレメント（PCE）通信プロトコル（PCEP）[RFC5440]などの他のプロトコルを介して実装されます。 ]。これらの対応するプロトコルメッセージは通常、インバンドで交換され、その後、フォワーディングプレーンによってコントロールプレーンにリダイレクトされて、さらに処理されます。このカテゴリの例には、[RCP]、[SoftRouter]、および[RouteFlow]が含まれます。
Control-plane functionalities usually include:
コントロールプレーンの機能には通常、次のものが含まれます。
o Topology discovery and maintenance
o トポロジーの発見と保守
o Packet route selection and instantiation
o パケットルートの選択とインスタンス化
o Path failover mechanisms The CPSI is usually defined with the following characteristics:
oパスフェイルオーバーメカニズムCPSIは通常、次の特性で定義されます。
o time-critical interface that requires low latency and sometimes high bandwidth in order to perform many operations in short order
o 短時間で多くの操作を実行するために低レイテンシと、時には高帯域幅を必要とするタイムクリティカルなインターフェース
o oriented towards wire efficiency and device representation instead of human readability
o 人間の可読性ではなく、ワイヤ効率とデバイス表現を重視
Examples include fast- and high-frequency of flow or table updates, high throughput, and robustness for packet handling and events.
例としては、フローまたはテーブルの高速および高頻度の更新、高スループット、パケット処理およびイベントの堅牢性などがあります。
CPSI can be implemented using a protocol, an API, or even inter-process communication. If the control plane and the network device are not collocated, then this interface is certainly a protocol. Examples of CPSIs are ForCES [RFC5810] and the OpenFlow protocol [OpenFlow].
CPSIは、プロトコル、API、またはプロセス間通信を使用して実装できます。コントロールプレーンとネットワークデバイスが併置されていない場合、このインターフェイスは確かにプロトコルです。 CPSIの例は、ForCES [RFC5810]とOpenFlowプロトコル[OpenFlow]です。
The Control Abstraction Layer (CAL) provides access to control applications and services to various CPSIs. The control plane may support more than one CPSI.
Control Abstraction Layer（CAL）は、さまざまなCPSIへの制御アプリケーションおよびサービスへのアクセスを提供します。コントロールプレーンは複数のCPSIをサポートする場合があります。
Control applications can use CAL to control a network device without providing any service to upper layers. Examples include applications that perform control functions, such as OSPF, IS-IS, and BGP.
制御アプリケーションは、CALを使用して、上位層にサービスを提供せずにネットワークデバイスを制御できます。例には、OSPF、IS-IS、BGPなどの制御機能を実行するアプリケーションが含まれます。
Control-plane service examples include a virtual private LAN service, service tunnels, topology services, etc.
コントロールプレーンサービスの例には、仮想プライベートLANサービス、サービストンネル、トポロジサービスなどがあります。
The management plane is usually centralized and aims to ensure that the network as a whole is running optimally by communicating with the network devices' operational plane using a Management-Plane Southbound Interface (MPSI) with DAL as a point of reference.
管理プレーンは通常は集中型であり、DALを参照ポイントとして使用する管理プレーンサウスバウンドインターフェイス（MPSI）を使用してネットワークデバイスの運用プレーンと通信することにより、ネットワーク全体が最適に実行されるようにします。
Management-plane functionalities are typically initiated, based on an overall network view, and traditionally have been human-centric. However, lately, algorithms are replacing most human intervention. Management-plane functionalities [FCAPS] typically include:
管理プレーンの機能は通常、全体的なネットワークビューに基づいて開始され、従来は人間中心の機能でした。ただし、最近、アルゴリズムはほとんどの人間の介入に取って代わります。管理プレーン機能[FCAPS]には通常、次のものが含まれます。
o Fault and monitoring management
o 障害および監視管理
o Configuration management
o 構成管理
In addition, management-plane functionalities may also include entities such as orchestrators, Virtual Network Function Managers (VNF Managers) and Virtualised Infrastructure Managers, as described in [NFVArch]. Such entities can use management interfaces to
さらに、管理プレーン機能には、[NFVArch]で説明されているように、オーケストレーター、仮想ネットワーク機能マネージャー（VNFマネージャー）、仮想化インフラストラクチャマネージャーなどのエンティティも含まれます。このようなエンティティは、管理インターフェースを使用して
operational-plane resources to request and provision resources for virtual functions as well as instruct the instantiation of virtual forwarding functions on top of physical forwarding functions. The possibility of a common abstraction model for both SDN and Network Function Virtualization (NFV) is explored in [SDNNFV]. Note, however, that these are only examples of applications and services in the management plane and not formal definitions of entities in this document. As has been noted above, orchestration and therefore the definition of any associated entities is out of the scope of this document.
仮想機能のリソースを要求およびプロビジョニングし、物理転送機能に加えて仮想転送機能のインスタンス化を指示する運用プレーンリソース。 SDNとネットワーク機能仮想化（NFV）の両方に共通の抽象化モデルの可能性については、[SDNNFV]で説明しています。ただし、これらは管理プレーンのアプリケーションとサービスの例にすぎず、このドキュメントのエンティティの正式な定義ではないことに注意してください。上で述べたように、オーケストレーション、したがって関連するエンティティの定義は、このドキュメントの範囲外です。
The MPSI, in contrast to the CPSI, is usually not a time-critical interface and does not share the CPSI requirements.
MPSIは、CPSIとは対照的に、通常、タイムクリティカルなインターフェースではなく、CPSI要件を共有しません。
MPSI is typically closer to human interaction than CPSI (cf. [RFC3535]); therefore, MPSI usually has the following characteristics:
MPSIは通常、CPSIよりも人間の相互作用に近い（[RFC3535]を参照）。したがって、MPSIには通常、次の特性があります。
o It is oriented more towards usability, with optimal wire performance being a secondary concern.
o 使いやすさに重点が置かれており、最適なワイヤー性能が二次的な関心事です。
o Messages tend to be less frequent than in the CPSI.
o メッセージは、CPSIよりも頻度が低くなる傾向があります。
As an example of usability versus performance, we refer to the consensus of the 2002 IAB Workshop [RFC3535]: the key requirement for a network management technology is ease of use, not performance. As per [RFC6632], textual configuration files should be able to contain international characters. Human-readable strings should utilize UTF-8, and protocol elements should be in case-insensitive ASCII, which requires more processing capabilities to parse.
ユーザビリティとパフォーマンスの例として、2002 IABワークショップ[RFC3535]のコンセンサスを参照します。ネットワーク管理テクノロジーの重要な要件は、パフォーマンスではなく使いやすさです。 [RFC6632]に従って、テキストの設定ファイルは国際的な文字を含むことができるはずです。人間が読める文字列はUTF-8を利用する必要があり、プロトコル要素は大文字と小文字を区別しないASCIIである必要があります。ASCIIは、解析するためにより多くの処理機能を必要とします。
MPSI can range from a protocol, to an API or even inter-process communication. If the management plane is not embedded in the network device, the MPSI is certainly a protocol. Examples of MPSIs are ForCES [RFC5810], NETCONF [RFC6241], IP Flow Information Export (IPFIX) [RFC7011], Syslog [RFC5424], Open vSwitch Database (OVSDB) [RFC7047], and SNMP [RFC3411].
MPSIは、プロトコルから、API、さらにはプロセス間通信までさまざまです。管理プレーンがネットワークデバイスに組み込まれていない場合、MPSIは確かにプロトコルです。 MPSIの例は、ForCES [RFC5810]、NETCONF [RFC6241]、IPフロー情報エクスポート（IPFIX）[RFC7011]、Syslog [RFC5424]、Open vSwitch Database（OVSDB）[RFC7047]、SNMP [RFC3411]です。
The Management Abstraction Layer (MAL) provides access to management applications and services to various MPSIs. The management plane may support more than one MPSI.
管理抽象化層（MAL）は、さまざまなMPSIへの管理アプリケーションおよびサービスへのアクセスを提供します。管理プレーンは複数のMPSIをサポートする場合があります。
Management applications can use MAL to manage the network device without providing any service to upper layers. Examples of management applications include network monitoring, fault detection, and recovery applications.
管理アプリケーションは、MALを使用して、上位層にサービスを提供せずにネットワークデバイスを管理できます。管理アプリケーションの例には、ネットワーク監視、障害検出、および回復アプリケーションが含まれます。
Management-plane services provide access to other services or applications above the management plane.
管理プレーンサービスは、管理プレーン上の他のサービスまたはアプリケーションへのアクセスを提供します。
The definition of a clear distinction between "control" and "management" in the context of SDN received significant community attention during the preparation of this document. We observed that the role of the management plane has been earlier largely ignored or specified as out-of-scope for the SDN ecosystem. In the remainder of this subsection, we summarize the characteristics that differentiate the two planes in order to have a clear understanding of the mechanics, capabilities, and needs of each respective interface.
SDNのコンテキストにおける「制御」と「管理」の明確な区別の定義は、このドキュメントの作成中にコミュニティから大きな注目を集めました。以前は、管理プレーンの役割はほとんど無視されているか、SDNエコシステムの範囲外として指定されていました。このサブセクションの残りの部分では、それぞれのインターフェースのメカニズム、機能、およびニーズを明確に理解するために、2つのプレーンを区別する特性を要約します。
A point has been raised regarding the reference timescales for the control and management planes regarding how fast the respective plane is required to react to, or how fast it needs to manipulate, the forwarding or operational plane of the device. In general, the control plane needs to send updates "often", which translates roughly to a range of milliseconds; that requires high-bandwidth and low-latency links. In contrast, the management plane reacts generally at longer time frames, i.e., minutes, hours, or even days; thus, wire efficiency is not always a critical concern. A good example of this is the case of changing the configuration state of the device.
デバイスの転送または操作プレーンへの対応に必要な速度、または操作に必要な速度に関する制御プレーンと管理プレーンの参照タイムスケールに関するポイントが引き上げられました。一般的に、コントロールプレーンは更新を「頻繁に」送信する必要があり、これはおおよそミリ秒の範囲に変換されます。高帯域幅で低遅延のリンクが必要です。対照的に、管理プレーンは通常、より長い時間枠、つまり分、時間、または数日で反応します。したがって、ワイヤの効率は必ずしも重要な問題ではありません。この良い例は、デバイスの構成状態を変更する場合です。
Another distinction between the control and management planes relates to state persistence. A state is considered ephemeral if it has a very limited lifespan and is not deemed necessary to be stored on non-volatile memory. A good example is determining routing, which is usually associated with the control plane. On the other hand, a persistent state has an extended lifespan that may range from hours to days and months, is meant to be used beyond the lifetime of the process that created it, and is thus used across device reboots. Persistent state is usually associated with the management plane.
コントロールプレーンと管理プレーンのもう1つの違いは、状態の永続化に関連しています。状態の寿命が非常に限られていて、不揮発性メモリに保存する必要がないと見なされる場合、状態は一時的なものと見なされます。良い例は、通常はコントロールプレーンに関連付けられているルーティングの決定です。一方、永続的な状態は数時間から数日、数か月に及ぶ可能性のある長い寿命を持ち、それを作成したプロセスの寿命を超えて使用されることを意図しているため、デバイスの再起動全体で使用されます。通常、永続的な状態は管理プレーンに関連付けられています。
As mentioned earlier, traditionally, the control plane has been executed locally on the network device and is distributed in nature whilst the management plane is usually executed in a centralized manner, remotely from the device. However, with the advent of SDN centralizing, or "logically centralizing", the controller tends to muddle the distinction of the control and management plane based on locality.
前述のように、伝統的に、コントロールプレーンはネットワークデバイス上でローカルに実行され、実際には分散されていますが、管理プレーンは通常、デバイスからリモートで集中的に実行されます。ただし、SDNの集中化、つまり「論理的な集中化」の出現により、コントローラは、局所性に基づいて制御プレーンと管理プレーンの区別を混乱させる傾向があります。
The CAP theorem views a distributed computing system as composed of multiple computational resources (i.e., CPU, memory, storage) that are connected via a communications network and together perform a task. The theorem, or conjecture by some, identifies three characteristics of distributed systems that are universally desirable:
CAPの定理は、分散コンピューティングシステムを、通信ネットワークを介して接続され、一緒にタスクを実行する複数の計算リソース（つまり、CPU、メモリ、ストレージ）で構成されると見なします。定理、または一部の推測は、普遍的に望ましい分散システムの3つの特性を識別します。
o Consistency, meaning that the system responds identically to a query no matter which node receives the request (or does not respond at all).
o 一貫性。つまり、どのノードが要求を受信しても（またはまったく応答しなくても）、システムはクエリにまったく同じように応答します。
o Availability, i.e., that the system always responds to a request (although the response may not be consistent or correct).
o 可用性。つまり、システムは常に要求に応答します（応答が一貫していないか、正しくない場合があります）。
o Partition tolerance, namely that the system continues to function even when specific nodes or the communications network fail.
o パーティションの許容度。つまり、特定のノードまたは通信ネットワークに障害が発生した場合でも、システムは機能し続けます。
In 2000, Eric Brewer [CAPBR] conjectured that a distributed system can satisfy any two of these guarantees at the same time but not all three. This conjecture was later proven by Gilbert and Lynch [CAPGL] and is now usually referred to as the CAP theorem [CAPFN].
2000年に、Eric Brewer [CAPBR]は、分散システムがこれらの保証のうち2つを同時に満たすことができるが、3つすべてを満たせるわけではないと推測しました。この推測は後にギルバートとリンチ[CAPGL]によって証明され、現在は通常、CAP定理[CAPFN]と呼ばれています。
Forwarding a packet through a network correctly is a computational problem. One of the major abstractions that SDN posits is that all network elements are computational resources that perform the simple computational task of inspecting fields in an incoming packet and deciding how to forward it. Since the task of forwarding a packet from network ingress to network egress is obviously carried out by a large number of forwarding elements, the network of forwarding devices is a distributed computational system. Hence, the CAP theorem applies to forwarding of packets.
ネットワーク経由でパケットを正しく転送することは、計算上の問題です。 SDNが提供する主な抽象概念の1つは、すべてのネットワーク要素が、着信パケットのフィールドを検査して転送方法を決定するという単純な計算タスクを実行する計算リソースであることです。パケットをネットワークの入口からネットワークの出口に転送するタスクは明らかに多数の転送要素によって実行されるため、転送デバイスのネットワークは分散型計算システムです。したがって、CAPの定理はパケットの転送に適用されます。
In the context of the CAP theorem, if one considers partition tolerance of paramount importance, traditional control-plane operations are usually local and fast (available), while management-plane operations are usually centralized (consistent) and may be slow.
CAPの定理のコンテキストでは、パーティションの許容度を最重要視すると、従来のコントロールプレーンの操作は通常ローカルで高速（利用可能）ですが、管理プレーンの操作は通常は集中化（一貫性）されて遅くなる可能性があります。
The CAP theorem also provides insights into SDN architectures. For example, a centralized SDN controller acts as a consistent global database and specific SDN mechanisms ensure that a packet entering the network is handled consistently by all SDN switches. The issue of tolerance to loss of connectivity to the controller is not addressed by the basic SDN model. When an SDN switch cannot reach its controller, the flow will be unavailable until the connection is restored. The use of multiple non-collocated SDN controllers has been proposed (e.g., by configuring the SDN switch with a list of controllers); this may improve partition tolerance but at the cost of loss of absolute consistency. Panda, et al. [CAPFN] provide a first exploration of how the CAP theorem applies to SDN.
CAP定理は、SDNアーキテクチャへの洞察も提供します。たとえば、集中型SDNコントローラーは一貫したグローバルデータベースとして機能し、特定のSDNメカニズムは、ネットワークに入るパケットがすべてのSDNスイッチによって一貫して処理されることを保証します。コントローラーへの接続の喪失に対する許容度の問題は、基本的なSDNモデルでは対処されていません。 SDNスイッチがコントローラーに到達できない場合、接続が復元されるまでフローは利用できません。複数の連結されていないSDNコントローラーの使用が提案されています（例えば、コントローラーのリストでSDNスイッチを構成することにより）。これにより、パーティションの許容度は向上しますが、絶対的な一貫性が失われます。パンダ等[CAPFN]は、CAPの定理がSDNにどのように適用されるかについての最初の調査を提供します。
The Network Services Abstraction Layer (NSAL) provides access from services of the control, management, and application planes to other services and applications. We note that the term "SAL" is overloaded, as it is often used in several contexts ranging from system design to service-oriented architectures; therefore, we explicitly add "Network" to the title of this layer to emphasize that this term relates to Figure 1, and we map it accordingly in Section 4 to prominent SDN approaches.
Network Services Abstraction Layer（NSAL）は、制御、管理、およびアプリケーションプレーンのサービスから他のサービスおよびアプリケーションへのアクセスを提供します。 「SAL」という用語は、システム設計からサービス指向アーキテクチャーまでのさまざまなコンテキストでよく使用されるため、過負荷になっていることに注意してください。したがって、この層のタイトルに「ネットワーク」を明示的に追加して、この用語が図1に関連していることを強調し、セクション4でそれを著名なSDNアプローチにマッピングします。
Service interfaces can take many forms pertaining to their specific requirements. Examples of service interfaces include, but are not limited to, RESTful APIs, open protocols such as NETCONF, inter-process communication, CORBA [CORBA] interfaces, and so on. The two leading approaches for service interfaces are RESTful interfaces and Remote Procedure Call (RPC) interfaces. Both follow a client-server architecture and use XML or JSON to pass messages, but each has some slightly different characteristics.
サービスインターフェイスは、特定の要件に関連する多くの形式をとることができます。サービスインターフェイスの例には、RESTful API、NETCONFなどのオープンプロトコル、プロセス間通信、CORBA [CORBA]インターフェイスなどが含まれますが、これらに限定されません。サービスインターフェイスの2つの主要なアプローチは、RESTfulインターフェイスとリモートプロシージャコール（RPC）インターフェイスです。どちらもクライアント/サーバーアーキテクチャに準拠し、XMLまたはJSONを使用してメッセージを渡しますが、それぞれに若干異なる特性があります。
RESTful interfaces, designed according to the representational state transfer design paradigm [REST], have the following characteristics:
表現状態転送設計パラダイム[REST]に従って設計されたRESTfulインターフェースには、次の特性があります。
o Resource identification - Individual resources are identified using a resource identifier, for example, a URI.
o リソースの識別-個々のリソースは、URIなどのリソース識別子を使用して識別されます。
o Manipulation of resources through representations - Resources are represented in a format like JSON, XML, or HTML.
o 表現によるリソースの操作-リソースは、JSON、XML、HTMLなどの形式で表現されます。
o Self-descriptive messages - Each message has enough information to describe how the message is to be processed.
o 自己記述的メッセージ-各メッセージには、メッセージの処理方法を説明するのに十分な情報があります。
o Hypermedia as the engine of application state - A client needs no prior knowledge of how to interact with a server, as the API is not fixed but dynamically provided by the server.
o アプリケーション状態のエンジンとしてのハイパーメディア-APIは固定されておらず、サーバーによって動的に提供されるため、クライアントはサーバーとの対話方法に関する事前の知識を必要としません。
Remote procedure calls (RPCs) [RFC5531], e.g., XML-RPC and the like, have the following characteristics:
リモートプロシージャコール（RPC）[RFC5531]（XML-RPCなど）には、次の特性があります。
o Individual procedures are identified using an identifier.
o 個々の手順は識別子を使用して識別されます。
o A client needs to know the procedure name and the associated parameters.
o クライアントは、プロシージャ名と関連パラメータを知っている必要があります。
Applications and services that use services from the control and/or management plane form the application plane.
コントロールおよび/または管理プレーンからのサービスを使用するアプリケーションおよびサービスは、アプリケーションプレーンを形成します。
Additionally, services residing in the application plane may provide services to other services and applications that reside in the application plane via the service interface.
さらに、アプリケーションプレーンに常駐するサービスは、サービスインターフェースを介して、アプリケーションプレーンに常駐する他のサービスやアプリケーションにサービスを提供できます。
Examples of applications include network topology discovery, network provisioning, path reservation, etc.
アプリケーションの例には、ネットワークトポロジの検出、ネットワークのプロビジョニング、パスの予約などがあります。
We advocate that the SDN southbound interface should encompass both CPSI and MPSI.
SDNサウスバウンドインターフェイスは、CPSIとMPSIの両方を含む必要があることを推奨します。
SDN controllers such as [NOX] and [Beacon] are a collection of control-plane applications and services that implement a CPSI ([NOX] and [Beacon] both use OpenFlow) and provide a northbound interface for applications. The SDN northbound interface for controllers is implemented in the Network Services Abstraction Layer (NSAL) of Figure 1.
[NOX]や[Beacon]などのSDNコントローラーは、CPSI（[NOX]と[Beacon]はどちらもOpenFlowを使用）を実装し、アプリケーションにノースバウンドインターフェイスを提供するコントロールプレーンアプリケーションとサービスのコレクションです。コントローラーのSDNノースバウンドインターフェイスは、図1のネットワークサービスアブストラクションレイヤー（NSAL）に実装されています。
The above model can be used to describe all prominent SDN-enabling technologies in a concise manner, as we explain in the following subsections.
上記のモデルは、以下のサブセクションで説明するように、すべての著名なSDN対応テクノロジーを簡潔に説明するために使用できます。
The IETF Forwarding and Control Element Separation (ForCES) framework [RFC3746] consists of one model and two protocols. ForCES separates the forwarding plane from the control plane via an open interface, namely the ForCES protocol [RFC5810], which operates on entities of the forwarding plane that have been modeled using the ForCES model [RFC5812].
IETF転送と制御要素分離（ForCES）フレームワーク[RFC3746]は、1つのモデルと2つのプロトコルで構成されています。 ForCESは、オープンインターフェイス、つまりForCESモデル[RFC5812]を使用してモデル化された転送プレーンのエンティティで動作するForCESプロトコル[RFC5810]を介して、転送プレーンをコントロールプレーンから分離します。
The ForCES model [RFC5812] is based on the fact that a network element is composed of numerous logically separate entities that cooperate to provide a given functionality (such as routing or IP switching) and yet appear as a normal integrated network element to external entities.
ForCESモデル[RFC5812]は、ネットワーク要素が、所定の機能（ルーティングやIPスイッチングなど）を提供するために協力し、外部エンティティに対して通常の統合ネットワーク要素として表示される多数の論理的に分離したエンティティで構成されるという事実に基づいています。
ForCES models the forwarding plane using Logical Functional Blocks (LFBs), which, when connected in a graph, compose the Forwarding Element (FE). LFBs are described in XML, based on an XML schema.
ForCESは、論理機能ブロック（LFB）を使用して転送プレーンをモデル化します。LFBは、グラフに接続されると、転送要素（FE）を構成します。 LFBは、XMLスキーマに基づいてXMLで記述されます。
LFB definitions include base and custom-defined datatypes; metadata definitions; input and output ports; operational parameters or components; and capabilities and event definitions.
LFB定義には、基本およびカスタム定義のデータ型が含まれます。メタデータ定義;入力および出力ポート。運用パラメーターまたはコンポーネント;および機能とイベントの定義。
The ForCES model can be used to define LFBs from fine- to coarse-grained as needed, irrespective of whether they are physical or virtual.
ForCESモデルを使用すると、物理的であるか仮想であるかに関係なく、必要に応じてLFBを細粒度から粗粒度まで定義できます。
The ForCES protocol is agnostic to the model and can be used to monitor, configure, and control any ForCES-modeled element. The protocol has very simple commands: Set, Get, and Del(ete). The ForCES protocol has been designed for high throughput and fast updates.
ForCESプロトコルはモデルに依存せず、ForCESモデルの要素を監視、構成、および制御するために使用できます。プロトコルには、Set、Get、およびDel（ete）という非常に単純なコマンドがあります。 ForCESプロトコルは、高スループットと高速更新のために設計されています。
With respect to Figure 1, the ForCES model [RFC5812] is suitable for the DAL, both for the operational and the forwarding plane, using LFBs. The ForCES protocol [RFC5810] has been designed and is suitable for the CPSI, although it could also be utilized for the MPSI.
図1に関して、ForCESモデル[RFC5812]は、LFBを使用する運用プレーンと転送プレーンの両方のDALに適しています。 ForCESプロトコル[RFC5810]が設計され、CPSIに適していますが、MPSIにも使用できます。
The Network Configuration Protocol (NETCONF) [RFC6241] is an IETF network management protocol [RFC6632]. NETCONF provides mechanisms to install, manipulate, and delete the configuration of network devices.
ネットワーク構成プロトコル（NETCONF）[RFC6241]は、IETFネットワーク管理プロトコル[RFC6632]です。 NETCONFは、ネットワークデバイスの設定をインストール、操作、および削除するメカニズムを提供します。
NETCONF protocol operations are realized as remote procedure calls (RPCs). The NETCONF protocol uses XML-based data encoding for the configuration data as well as the protocol messages. Recent studies, such as [ESNet] and [PENet], have shown that NETCONF performs better than SNMP [RFC3411].
NETCONFプロトコル操作は、リモートプロシージャコール（RPC）として実現されます。 NETCONFプロトコルは、構成データとプロトコルメッセージにXMLベースのデータエンコーディングを使用します。 [ESNet]や[PENet]などの最近の調査では、NETCONFはSNMP [RFC3411]よりもパフォーマンスが高いことが示されています。
Additionally, the YANG data modeling language [RFC6020] has been developed for specifying NETCONF data models and protocol operations. YANG is a data modeling language used to model configuration and state data manipulated by the NETCONF protocol, NETCONF remote procedure calls, and NETCONF notifications.
さらに、YANGデータモデリング言語[RFC6020]は、NETCONFデータモデルとプロトコル操作を指定するために開発されました。 YANGは、NETCONFプロトコル、NETCONFリモートプロシージャコール、およびNETCONF通知によって操作される構成および状態データをモデル化するために使用されるデータモデリング言語です。
YANG models the hierarchical organization of data as a tree, in which each node has either a value or a set of child nodes. Additionally, YANG structures data models into modules and submodules, allowing reusability and augmentation. YANG models can describe constraints to be enforced on the data. Additionally, YANG has a set of base datatypes and allows custom-defined datatypes as well.
YANGは、データの階層構造をツリーとしてモデル化します。各ノードには、値または子ノードのセットがあります。さらに、YANGはデータモデルをモジュールとサブモジュールに構造化し、再利用と拡張を可能にします。 YANGモデルは、データに適用される制約を記述できます。さらに、YANGには一連の基本データ型があり、カスタム定義のデータ型も使用できます。
YANG allows the definition of NETCONF RPCs, which allows the protocol to have an extensible number of commands. For RPC definitions, the operations names, input parameters, and output parameters are defined using YANG data definition statements.
YANGはNETCONF RPCの定義を許可します。これにより、プロトコルは拡張可能な数のコマンドを持つことができます。 RPC定義の場合、操作名、入力パラメーター、および出力パラメーターは、YANGデータ定義ステートメントを使用して定義されます。
With respect to Figure 1, the YANG model [RFC6020] is suitable for specifying DAL for the forwarding and operational planes. NETCONF [RFC6241] is suitable for the MPSI. NETCONF is a management protocol [RFC6632], which was not (originally) designed for fast CP updates, and it might not be suitable for addressing the requirements of CPSI.
図1に関して、YANGモデル[RFC6020]は、転送プレーンと運用プレーンのDALを指定するのに適しています。 NETCONF [RFC6241]はMPSIに適しています。 NETCONFは管理プロトコル[RFC6632]であり、（当初は）高速CP更新用に設計されていなかったため、CPSIの要件に対処するのに適していない場合があります。
OpenFlow is a framework originally developed at Stanford University and currently under active standards development [OpenFlow] through the Open Networking Foundation (ONF). Initially, the goal was to provide a way for researchers to run experimental protocols in a production network [OF08]. OpenFlow has undergone many revisions, and additional revisions are likely. The following description reflects version 1.4 [OpenFlow]. In short, OpenFlow defines a protocol through which a logically centralized controller can control an OpenFlow switch. Each OpenFlow-compliant switch maintains one or more flow tables, which are used to perform packet lookups. Distinct actions are to be taken regarding packet lookup and forwarding. A group table and an OpenFlow channel to external controllers are also part of the switch specification.
OpenFlowは、もともとスタンフォード大学で開発されたフレームワークであり、現在Open Networking Foundation（ONF）を通じて活発な標準開発[OpenFlow]が行われています。当初、目標は研究者が生産ネットワークで実験プロトコルを実行する方法を提供することでした[OF08]。 OpenFlowは多くの改訂を受けており、追加の改訂が行われる可能性があります。以下の説明は、バージョン1.4 [OpenFlow]を反映しています。つまり、OpenFlowは、論理的に集中化されたコントローラーがOpenFlowスイッチを制御できるプロトコルを定義します。各OpenFlow準拠のスイッチは、1つ以上のフローテーブルを保持します。これらのテーブルは、パケットルックアップを実行するために使用されます。パケットの検索と転送に関して、明確なアクションを実行する必要があります。グループテーブルと外部コントローラーへのOpenFlowチャネルもスイッチ仕様の一部です。
With respect to Figure 1, the OpenFlow switch specifications [OpenFlow] define a DAL for the forwarding plane as well as for CPSI. The OF-CONFIG protocol [OF-CONFIG], based on the YANG model [RFC6020], provides a DAL for the forwarding and operational planes of an OpenFlow switch and specifies NETCONF [RFC6241] as the MPSI. OF-CONFIG overlaps with the OpenFlow DAL, but with NETCONF [RFC6241] as the transport protocol, it shares the limitations described in the previous section.
図1に関して、OpenFlowスイッチ仕様[OpenFlow]は、CPSIだけでなく転送プレーンのDALを定義します。 YANGモデル[RFC6020]に基づくOF-CONFIGプロトコル[OF-CONFIG]は、OpenFlowスイッチの転送および操作プレーンにDALを提供し、MPCONとしてNETCONF [RFC6241]を指定します。 OF-CONFIGはOpenFlow DALと重複しますが、トランスポートプロトコルとしてNETCONF [RFC6241]を使用すると、前のセクションで説明した制限を共有します。
Interface to the Routing System (I2RS) provides a standard interface to the routing system for real-time or event-driven interaction through a collection of protocol-based control or management interfaces. Essentially, one of the main goals of I2RS, is to make the Routing Information Base (RIB) programmable, thus enabling new kinds of network provisioning and operation.
ルーティングシステムへのインターフェース（I2RS）は、プロトコルベースの制御または管理インターフェースのコレクションを介して、リアルタイムまたはイベント駆動型の対話のためのルーティングシステムへの標準インターフェースを提供します。基本的に、I2RSの主な目標の1つは、ルーティング情報ベース（RIB）をプログラム可能にすることです。これにより、新しい種類のネットワークのプロビジョニングと操作が可能になります。
I2RS did not initially intend to create new interfaces but rather leverage or extend existing ones and define informational models for the routing system. For example, the latest I2RS problem statement
I2RSは当初、新しいインターフェイスを作成することを意図していませんでしたが、既存のインターフェイスを活用または拡張して、ルーティングシステムの情報モデルを定義していました。たとえば、最新のI2RS問題ステートメント
[I2RSProb] discusses previously defined IETF protocols such as ForCES [RFC5810], NETCONF [RFC6241], and SNMP [RFC3417]. Regarding the definition of informational and data models, the I2RS working group has opted to use the YANG [RFC6020] modeling language.
[I2RSProb]は、ForCES [RFC5810]、NETCONF [RFC6241]、SNMP [RFC3417]など、以前に定義されたIETFプロトコルについて説明します。情報モデルとデータモデルの定義に関して、I2RSワーキンググループはYANG [RFC6020]モデリング言語の使用を選択しました。
Currently the I2RS working group is developing an Information Model [I2RSInfo] in regards to the Network Services Abstraction Layer for the I2RS agent.
現在、I2RSワーキンググループは、I2RSエージェントのネットワークサービスアブストラクションレイヤーに関する情報モデル[I2RSInfo]を開発しています。
With respect to Figure 1, the I2RS architecture [I2RSArch] encompasses the control and application planes and uses any CPSI and DAL that is available, whether that may be ForCES [RFC5810], OpenFlow [OpenFlow], or another interface. In addition, the I2RS agent is a control-plane service. All services or applications on top of that belong to either the Control, Management, or Application plane. In the I2RS documents, management access to the agent may be provided by management protocols like SNMP and NETCONF. The I2RS protocol may also be mapped to the service interface as it will even provide access to services and applications other than control-plane services and applications.
図1に関して、I2RSアーキテクチャ[I2RSArch]は、コントロールプレーンとアプリケーションプレーンを包含し、ForCES [RFC5810]、OpenFlow [OpenFlow]、または別のインターフェイスのいずれであっても、利用可能なCPSIおよびDALを使用します。また、I2RSエージェントはコントロールプレーンサービスです。その上にあるすべてのサービスまたはアプリケーションは、コントロール、管理、またはアプリケーションプレーンのいずれかに属しています。 I2RSドキュメントでは、エージェントへの管理アクセスは、SNMPやNETCONFなどの管理プロトコルによって提供される場合があります。 I2RSプロトコルは、コントロールプレーンのサービスとアプリケーション以外のサービスとアプリケーションへのアクセスも提供するため、サービスインターフェイスにマップすることもできます。
The Simple Network Management Protocol (SNMP) is an IETF-standardized management protocol and is currently at its third revision (SNMPv3) [RFC3417] [RFC3412] [RFC3414]. It consists of a set of standards for network management, including an application-layer protocol, a database schema, and a set of data objects. SNMP exposes management data (managed objects) in the form of variables on the managed systems, which describe the system configuration. These variables can then be queried and set by managing applications.
簡易ネットワーク管理プロトコル（SNMP）はIETF標準の管理プロトコルであり、現在3番目のリビジョン（SNMPv3）[RFC3417] [RFC3412] [RFC3414]にあります。これは、アプリケーション層プロトコル、データベーススキーマ、およびデータオブジェクトのセットを含む、ネットワーク管理の標準のセットで構成されています。 SNMPは、管理データ（管理対象オブジェクト）を、システム構成を説明する管理対象システムの変数の形式で公開します。その後、これらの変数は、アプリケーションを管理することによって照会および設定できます。
SNMP uses an extensible design for describing data, defined by Management Information Bases (MIBs). MIBs describe the structure of the management data of a device subsystem. MIBs use a hierarchical namespace containing object identifiers (OIDs). Each OID identifies a variable that can be read or set via SNMP. MIBs use the notation defined by Structure of Management Information Version 2 [RFC2578].
SNMPは、管理情報ベース（MIB）によって定義されたデータを記述するための拡張可能な設計を使用します。 MIBは、デバイスサブシステムの管理データの構造を記述します。 MIBは、オブジェクト識別子（OID）を含む階層的な名前空間を使用します。各OIDは、SNMP経由で読み取りまたは設定できる変数を識別します。 MIBは、管理情報バージョン2 [RFC2578]で定義された表記法を使用します。
An early example of SNMP in the context of SDN is discussed in [Peregrine].
SDNのコンテキストにおけるSNMPの初期の例は、[Peregrine]で説明されています。
With respect to Figure 1, SNMP MIBs can be used to describe DAL for the forwarding and operational planes. Similar to YANG, SNMP MIBs are able to describe DAL for the forwarding plane. SNMP, similar to NETCONF, is suited for the MPSI.
図1に関しては、SNMP MIBを使用して、転送プレーンと運用プレーンのDALを記述できます。 YANGと同様に、SNMP MIBは転送プレーンのDALを記述できます。 NETCONFと同様に、SNMPはMPSIに適しています。
The Path Computation Element (PCE) [RFC4655] architecture defines an entity capable of computing paths for a single service or a set of services. A PCE might be a network node, network management station, or dedicated computational platform that is resource-aware and has the ability to consider multiple constraints for a variety of path computation problems and switching technologies. The PCE Communication Protocol (PCEP) [RFC5440] is used between a Path Computation Client (PCC) and a PCE, or between multiple PCEs.
パス計算要素（PCE）[RFC4655]アーキテクチャは、単一のサービスまたは一連のサービスのパスを計算できるエンティティを定義します。 PCEは、リソースを認識するネットワークノード、ネットワーク管理ステーション、または専用の計算プラットフォームであり、さまざまなパス計算の問題やスイッチングテクノロジーに関する複数の制約を考慮することができます。 PCE通信プロトコル（PCEP）[RFC5440]は、パス計算クライアント（PCC）とPCEの間、または複数のPCEの間で使用されます。
The PCE architecture represents a vision of networks that separates path computation for services, the signaling of end-to-end connections, and actual packet forwarding. The definition of online and offline path computation is dependent on the reachability of the PCE from network and Network Management System (NMS) nodes and the type of optimization request that may significantly impact the optimization response time from the PCE to the PCC.
PCEアーキテクチャは、サービスのパス計算、エンドツーエンド接続のシグナリング、および実際のパケット転送を分離するネットワークのビジョンを表しています。オンラインおよびオフラインのパス計算の定義は、ネットワークおよびネットワーク管理システム（NMS）ノードからのPCEの到達可能性、およびPCEからPCCへの最適化応答時間に大きな影響を与える可能性のある最適化要求のタイプに依存します。
The PCEP messaging mechanism facilitates the specification of computation endpoints (source and destination node addresses), objective functions (requested algorithm and optimization criteria), and the associated constraints such as traffic parameters (e.g., requested bandwidth), the switching capability, and encoding type.
PCEPメッセージングメカニズムは、計算エンドポイント（送信元ノードと宛先ノードのアドレス）、目的関数（要求されたアルゴリズムと最適化基準）、およびトラフィックパラメーター（要求された帯域幅など）、スイッチング機能、エンコーディングタイプなどの関連制約の指定を容易にします。 。
With respect to Figure 1, PCE is a control-plane service that provides services for control-plane applications. PCEP may be used as an east-west interface between PCEs that may act as domain control entities (services and applications). The PCE working group is specifying extensions [PCEActive] that allow an active PCE to control, using PCEP, MPLS or GMPLS Label Switched Paths (LSPs), thus making it applicable for the CPSI for MPLS and GMPLS switches.
図1に関して、PCEは、コントロールプレーンアプリケーションにサービスを提供するコントロールプレーンサービスです。 PCEPは、ドメイン制御エンティティ（サービスおよびアプリケーション）として機能するPCE間のイーストウエストインターフェイスとして使用できます。 PCEワーキンググループは、アクティブPCEがPCEP、MPLS、またはGMPLSラベルスイッチドパス（LSP）を使用して制御できるようにする拡張[PCEActive]を指定しているため、MPLSおよびGMPLSスイッチのCPSIに適用できます。
Bidirectional Forwarding Detection (BFD) [RFC5880] is an IETF-standardized network protocol designed for detecting path failures between two forwarding elements, including physical interfaces, subinterfaces, data link(s), and, to the extent possible, the forwarding engines themselves, with potentially very low latency. BFD can provide low-overhead failure detection on any kind of path between systems, including direct physical links, virtual circuits, tunnels, MPLS LSPs, multihop routed paths, and unidirectional links where there exists a return path as well. It is often implemented in some component of the forwarding engine of a system, in cases where the forwarding and control engines are separated.
双方向転送検出（BFD）[RFC5880]は、物理インターフェイス、サブインターフェイス、データリンク、および可能な限り転送エンジン自体を含む2つの転送要素間のパス障害を検出するために設計されたIETF標準のネットワークプロトコルです。潜在的に非常に低いレイテンシ。 BFDは、直接物理リンク、仮想回線、トンネル、MPLS LSP、マルチホップルーテッドパス、リターンパスが存在する単方向リンクなど、システム間のあらゆる種類のパスでオーバーヘッドの少ない障害検出を提供できます。転送エンジンと制御エンジンが分離されている場合、システムの転送エンジンのコンポーネントに実装されることがよくあります。
With respect to Figure 1, a BFD agent can be implemented as a control-plane service or application that would use the CPSI towards the forwarding plane to send/receive BFD packets. However, a BFD agent is usually implemented as an application on the device and uses the forwarding plane to send/receive BFD packets and update the operational-plane resources accordingly. Services and applications of the control and management planes that monitor or have subscribed to changes of resources can learn about these changes through their respective interfaces and take any actions as necessary.
図1に関して、BFDエージェントは、BFDパケットを送受信するためにCPSIを転送プレーンに向けて使用するコントロールプレーンサービスまたはアプリケーションとして実装できます。ただし、BFDエージェントは通常、デバイス上のアプリケーションとして実装され、フォワーディングプレーンを使用してBFDパケットを送受信し、それに応じて運用プレーンリソースを更新します。リソースの変更を監視またはサブスクライブしているコントロールプレーンと管理プレーンのサービスとアプリケーションは、それぞれのインターフェイスを通じてこれらの変更について学習し、必要に応じてアクションを実行できます。
This document has been developed after a thorough and detailed analysis of related peer-reviewed literature, the RFC series, and documents produced by other relevant standards organizations. It has been reviewed publicly by the wider SDN community, and we hope that it can serve as a handy tool for network researchers, engineers, and practitioners in the years to come.
このドキュメントは、関連する査読済み文献、RFCシリーズ、および他の関連する標準化団体によって作成されたドキュメントを徹底的かつ詳細に分析した後に作成されました。幅広いSDNコミュニティによって公にレビューされており、今後のネットワークの研究者、エンジニア、実務家にとって便利なツールとして役立つことを願っています。
We conclude this document with a brief summary of the terminology of the SDN layer architecture. In general, we consider a network element as a composition of resources. Each network element has a forwarding plane (FP) that is responsible for handling packets in the data path and an operational plane (OP) that is responsible for managing the operational state of the device. Resources in the network element are abstracted by the Device and resource Abstraction Layer (DAL) to be controlled and managed by services or applications that belong to the control or management plane. The control plane (CP) is responsible for making decisions on how packets should be forwarded. The management plane (MP) is responsible for monitoring, configuring, and maintaining network devices. Service interfaces are abstracted by the Network Services Abstraction Layer (NSAL), where other network applications or services may use them. The taxonomy introduced in this document defines distinct SDN planes, abstraction layers, and interfaces; it aims to clarify SDN terminology and establish commonly accepted reference definitions across the SDN community, irrespective of specific implementation choices.
このドキュメントの最後に、SDNレイヤーアーキテクチャの用語の概要を示します。一般に、ネットワーク要素はリソースの構成と見なされます。各ネットワーク要素には、データパス内のパケットの処理を担当する転送プレーン（FP）と、デバイスの運用状態の管理を担当する運用プレーン（OP）があります。ネットワーク要素のリソースは、デバイスおよびリソース抽象化レイヤー（DAL）によって抽象化され、制御または管理プレーンに属するサービスまたはアプリケーションによって制御および管理されます。コントロールプレーン（CP）は、パケットの転送方法を決定します。管理プレーン（MP）は、ネットワークデバイスの監視、構成、および保守を担当します。サービスインターフェイスは、ネットワークサービスアブストラクションレイヤー（NSAL）によって抽象化されます。NSALでは、他のネットワークアプリケーションまたはサービスがそれらを使用できます。このドキュメントで紹介する分類法は、個別のSDNプレーン、抽象化レイヤー、およびインターフェースを定義しています。特定の実装の選択に関係なく、SDN用語を明確にし、SDNコミュニティ全体で一般に受け入れられている参照定義を確立することを目的としています。
This document does not propose a new network architecture or protocol and therefore does not have any impact on the security of the Internet. That said, security is paramount in networking; thus, it should be given full consideration when designing a network architecture or operational deployment. Security in SDN is discussed in the literature, for example, in [SDNSecurity], [SDNSecServ], and
このドキュメントは、新しいネットワークアーキテクチャまたはプロトコルを提案していないため、インターネットのセキュリティに影響を与えません。とは言っても、ネットワーキングではセキュリティが最も重要です。したがって、ネットワークアーキテクチャまたは運用展開を設計するときは、十分に検討する必要があります。 SDNのセキュリティは、文献、たとえば[SDNSecurity]、[SDNSecServ]、および
[SDNSecOF]. Security considerations regarding specific interfaces (such as, for example, ForCES, I2RS, SNMP, or NETCONF) are addressed in their respective documents as well as in [RFC7149].
[SDNSecOF]。特定のインターフェイス（たとえば、ForCES、I2RS、SNMP、NETCONFなど）に関するセキュリティの考慮事項は、それぞれのドキュメントと[RFC7149]で対処されています。
[A4D05] Greenberg, A., Hjalmtysson, G., Maltz, D., Myers, A., Rexford, J., Xie, G., Yan, H., Zhan, J., and H. Zhang, "A Clean Slate 4D Approach to Network Control and Management", ACM SIGCOMM Computer Communication Review, Volume 35, Issue 5, pp. 41-54, 2005.
[A4D05] Greenberg、A.、Hjalmtysson、G.、Maltz、D.、Myers、A.、Rexford、J.、Xie、G.、Yan、H.、Zhan、J。、およびH. Zhang、「Aネットワーク制御と管理へのクリーンスレート4Dアプローチ」、ACM SIGCOMM Computer Communication Review、Volume 35、Issue 5、pp。41-54、2005。
[ALIEN] Parniewicz, D., Corin, R., Ogrodowczyk, L., Fard, M., Matias, J., Gerola, M., Fuentes, V., Toseef, U., Zaalouk, A., Belter, B., Jacob, E., and K. Pentikousis, "Design and Implementation of an OpenFlow Hardware Abstraction Layer", In Proceedings of the ACM SIGCOMM Workshop on Distributed Cloud Computing (DCC), Chicago, Illinois, USA, pp. 71-76, doi 10.1145/2627566.2627577, August 2014.
[エイリアン] Parniewicz、D.、Corin、R.、Ogrodowczyk、L.、Fard、M.、Matias、J.、Gerola、M.、Fuentes、V.、Toseef、U.、Zaalouk、A.、Belter、 B.、Jacob、E。、およびK. Pentikousis、「OpenFlow Hardware Abstraction Layerの設計と実装」、ACM SIGCOMM Workshop on Distributed Cloud Computing（DCC）、シカゴ、イリノイ、米国、pp。71- 76、doi 10.1145 / 2627566.2627577、2014年8月。
[Beacon] Erickson, D., "The Beacon OpenFlow Controller", In Proceedings of the second ACM SIGCOMM workshop on Hot Topics in Software Defined Networking, pp. 13-18, 2013.
[ビーコン]エリクソン、D。、「The Beacon OpenFlow Controller」、ソフトウェア定義ネットワークのホットトピックに関する第2回のACM SIGCOMMワークショップの議事録、2013年13〜18ページ。
[CAPBR] Brewer, E., "Towards Robust Distributed Systems", In Proceedings of the Symposium on Principles of Distributed Computing (PODC), 2000.
[CAPBR]ブリューワーE.、「堅牢な分散システムに向けて」、2000年の分散コンピューティングの原則に関するシンポジウム（PODC）の議事録。
[CAPFN] Panda, A., Scott, C., Ghodsi, A., Koponen, T., and S. Shenker, "CAP for Networks", In Proceedings of the second ACM SIGCOMM workshop on Hot Topics in Software Defined Networking, pp. 91-96, 2013.
[CAPFN] Panda、A.、Scott、C.、Ghodsi、A.、Kopenen、T。、およびS. Shenker、「CAP for Networks」、ソフトウェア定義ネットワークのホットトピックに関する第2 ACM SIGCOMMワークショップのプロシーディングス、 pp。91-96、2013。
[CAPGL] Gilbert, S. and N. Lynch, "Brewer's Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services", ACM SIGACT News, Volume 33, Issue 2, pp. 51-59, 2002.
[CAPGL] Gilbert、S.およびN. Lynch、「Brewerの予想および一貫性があり、利用可能な、パーティショントレラントWebサービスの実現可能性」、ACM SIGACT News、Volume 33、Issue 2、pp。51-59、2002。
[CORBA] Object Management Group, "CORBA Version 3.3", November 2012, <http://www.omg.org/spec/CORBA/3.3/>.
[CORBA]オブジェクト管理グループ、「CORBAバージョン3.3」、2012年11月、<http://www.omg.org/spec/CORBA/3.3/>。
[DIOPR] Denazis, S., Miki, K., Vicente, J., and A. Campbell, "Designing Interfaces for Open Programmable Routers", In "Active Networks", Springer Berlin Heidelberg, pp. 13-24, 1999.
[DIOPR] Denazis、S.、Miki、K.、Vicente、J。、およびA. Campbell、「Designing Interfaces for Open Programmable Routers」、「Inactive Networks」、Springer Berlin Heidelberg、pp。13-24、1999。
[ESNet] Yu, J. and I. Al Ajarmeh, "An Empirical Study of the NETCONF Protocol", Sixth International Conference on Networking and Services, pp. 253-258, 2010.
[ESNet] Yu、J。およびI. Al Ajarmeh、「NETCONFプロトコルの実証的研究」、第6回ネットワークおよびサービスに関する国際会議、pp。253-258、2010年。
[FCAPS] ITU, "Management Framework For Open Systems Interconnection (OSI) For CCITT Applications", ITU Recommendation X.700, September 1992, <http://www.itu.int/rec/T-REC-X.700-199209-I/en>.
[FCAPS] ITU、「CCITTアプリケーションのオープンシステム相互接続（OSI）の管理フレームワーク」、ITU勧告X.700、1992年9月、<http://www.itu.int/rec/T-REC-X.700- 199209-I / en>。
[I2RSArch] Atlas, A., Halpern, J., Hares, S., Ward, D., and T. Nadeau, "An Architecture for the Interface to the Routing System", Work in Progress, draft-ietf-i2rs-architecture-07, December 2014.
[I2RSArch] Atlas、A.、Halpern、J.、Hares、S.、Ward、D。、およびT. Nadeau、「ルーティングシステムへのインターフェイスのアーキテクチャ」、作業中、draft-ietf-i2rs-アーキテクチャ07、2014年12月。
[I2RSInfo] Bahadur, N., Folkes, R., Kini, S., and J. Medved, "Routing Information Base Info Model", Work in Progress, draft-ietf-i2rs-rib-info-model-04, December 2014.
[I2RSInfo] Bahadur、N.、Folkes、R.、Kini、S.、J。Medved、「Routing Information Base Info Model」、Work in Progress、draft-ietf-i2rs-rib-info-model-04、12月2014。
[I2RSProb] Atlas, A., Nadeau, T., and D. Ward, "Interface to the Routing System Problem Statement", Work in Progress, draft-ietf-i2rs-problem-statement-05, January 2015.
[I2RSProb]アトラス、A。、ナドー、T。、およびD.ウォード、「ルーティングシステム問題ステートメントへのインターフェース」、作業中、draft-ietf-i2rs-problem-statement-05、2015年1月。
[ITUATM] ITU, "B-ISDN ATM Layer Specification", ITU Recommendation I.361, 1990, <http://www.itu.int/rec/T-REC-I.361-199902-I/en>.
[ITUATM] ITU、「B-ISDN ATM Layer Specification」、ITU勧告I.361、1990、<http://www.itu.int/rec/T-REC-I.361-199902-I/en>。
[ITUSG11] ITU, "ITU-T Study Group 11: Protocols and test specifications", <http://www.itu.int/en/ITU-T/ studygroups/2013-2016/11/Pages/default.aspx>.
[ITUSG11] ITU、「ITU-T Study Group 11：Protocols and test specification」、<http://www.itu.int/en/ITU-T/ studygroups / 2013-2016 / 11 / Pages / default.aspx> 。
[ITUSG13] ITU, "ITU-T Study Group 13: Future networks including cloud computing, mobile and next-generation networks", <http://www.itu.int/en/ITU-T/studygroups/ 2013-2016/13/Pages/default.aspx>.
[ITUSG13] ITU、「ITU-T Study Group 13：クラウドコンピューティング、モバイル、次世代ネットワークを含む将来のネットワーク」、<http://www.itu.int/en/ITU-T/studygroups/ 2013-2016 / 13 / Pages / default.aspx>。
[ITUSS7] ITU, "Introduction to CCITT Signalling System No. 7", ITU Recommendation Q.700, 1993, <http://www.itu.int/rec/T-REC-Q.700-199303-I/e>.
[ITUSS7] ITU、「Introduction to CCITT Signaling System No. 7」、ITU Recommendation Q.700、1993、<http://www.itu.int/rec/T-REC-Q.700-199303-I/e >。
[ITUY3300] ITU, "Framework of software-defined networking", ITU Recommendation Y.3300, June 2014, <http://www.itu.int/rec/T-REC-Y.3300-201406-I/en>.
[ITUY3300] ITU、「Framework of Software-defined Networking」、ITU Recommendation Y.3300、June 2014、<http://www.itu.int/rec/T-REC-Y.3300-201406-I/en> 。
[KANDOO] Yeganeh, S. and Y. Ganjali, "Kandoo: A Framework for Efficient and Scalable Offloading of Control Applications", In Proceedings of the first ACM SIGCOMM workshop on Hot Topics in Software Defined Networks, pp. 19-24, 2012.
[KANDOO] Yeganeh、S。およびY. Ganjali、「Kandoo：A Framework for Afficient and Scalable Offloading of Control Applications」、Proceedings in the first ACM SIGCOMM Workshop on Hot Topics in Software Defined Networks、pp.19-24、2012 。
[NFVArch] ETSI, "Network Functions Virtualisation (NFV): Architectural Framework", ETSI GS NFV 002, October 2013, <http://www.etsi.org/deliver/etsi_gs/ nfv/001_099/002/01.01.01_60/gs_nfv002v010101p.pdf>.
[NFVArch] ETSI、「Network Functions Virtualization（NFV）：Architectural Framework」、ETSI GS NFV 002、2013年10月、<http://www.etsi.org/deliver/etsi_gs/ nfv / 001_099 / 002 / 01.01.01_60 / gs_nfv002v010101p.pdf>。
[NOX] Gude, N., Koponen, T., Pettit, J., Pfaff, B., Casado, M., McKeown, N., and S. Shenker, "NOX: Towards an Operating System for Networks", ACM SIGCOMM Computer Communication Review, Volume 38, Issue 3, pp. 105-110, July 2008.
[NOX] Gude、N.、Koponen、T.、Pettit、J.、Pfaff、B.、Casado、M.、McKeown、N。、およびS. Shenker、「NOX：To Operating an Operating System for Networks」、ACM SIGCOMM Computer Communication Review、Volume 38、Issue 3、pp.105-110、2008年7月。
[NV09] Chowdhury, N. and R. Boutaba, "Network Virtualization: State of the Art and Research Challenges", Communications Magazine, IEEE, Volume 47, Issue 7, pp. 20-26, 2009.
[NV09] Chowdhury、N。、およびR. Boutaba、「ネットワーク仮想化：最先端の研究および課題」、Communications Magazine、IEEE、Volume 47、Issue 7、pp。20-26、2009。
[OF-CONFIG] Open Networking Foundation, "OpenFlow Management and Configuration Protocol (OF-Config 1.1.1)", March 2013, <https://www.opennetworking.org/images/stories/ downloads/sdn-resources/onf-specifications/ openflow-config/of-config-1-1-1.pdf>.
[OF-CONFIG] Open Networking Foundation、「OpenFlow Management and Configuration Protocol（OF-Config 1.1.1）」、2013年3月、<https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf -specifications / openflow-config / of-config-1-1-1.pdf>。
[OF08] McKeown, N., Anderson, T., Balakrishnan, H., Parulkar, G., Peterson, L., Rexford, J., Shenker, S., and J. Turner, "OpenFlow: Enabling Innovation in Campus Networks", ACM SIGCOMM Computer Communication Review, Volume 38, Issue 2, pp. 69-74, 2008.
[OF08] McKeown、N.、Anderson、T.、Balakrishnan、H.、Parulkar、G.、Peterson、L.、Rexford、J.、Shenker、S。、およびJ. Turner、「OpenFlow：キャンパスにおけるイノベーションの実現ネットワーク」、ACM SIGCOMM Computer Communication Review、Volume 38、Issue 2、pp。69-74、2008。
[ONFArch] Open Networking Foundation, "SDN Architecture, Version 1", June 2014, <https://www.opennetworking.org/images/stories/ downloads/sdn-resources/technical-reports/ TR_SDN_ARCH_1.0_06062014.pdf>.
[ONFArch] Open Networking Foundation、「SDN Architecture、Version 1」、2014年6月、<https://www.opennetworking.org/images/stories/downloads/sdn-resources/technical-reports/TR_SDN_ARCH_1.0_06062014.pdf>。
[OpenFlow] Open Networking Foundation, "The OpenFlow Switch Specification, Version 1.4.0", October 2013, <https://www.opennetworking.org/images/stories/ downloads/sdn-resources/onf-specifications/openflow/ openflow-spec-v1.4.0.pdf>.
[OpenFlow] Open Networking Foundation、「OpenFlowスイッチ仕様、バージョン1.4.0」、2013年10月、<https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow/openflow -spec-v1.4.0.pdf>。
[P1520] Biswas, J., Lazar, A., Huard, J., Lim, K., Mahjoub, S., Pau, L., Suzuki, M., Torstensson, S., Wang, W., and S. Weinstein, "The IEEE P1520 standards initiative for programmable network interfaces", IEEE Communications Magazine, Volume 36, Issue 10, pp. 64-70, 1998.
[P1520]ビスワス、J。、ラザール、A。、ハード、J。、リム、K。、マジュブ、S。、ポー、L。、鈴木、M。、トルステンソン、S。、王、W、およびS Weinstein、「プログラム可能なネットワークインターフェイスのためのIEEE P1520標準イニシアチブ」、IEEE Communications Magazine、Volume 36、Issue 10、pp。64-70、1998。
[PCEActive] Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP Extensions for Stateful PCE", Work in Progress, draft-ietf-pce-stateful-pce-10, October 2014.
[PCEActive] Crabbe、E.、Minei、I.、Medved、J。、およびR. Varga、「ステートフルPCEのPCEP拡張機能」、作業中、draft-ietf-pce-stateful-pce-10、2014年10月。
[PENet] Hedstrom, B., Watwe, A., and S. Sakthidharan, "Protocol Efficiencies of NETCONF versus SNMP for Configuration Management Functions", Master's thesis, University of Colorado, 2011.
[PENet] Hedstrom、B.、Watwe、A。、およびS. Sakthidharan、「構成管理機能のためのNETCONFとSNMPのプロトコル効率」、修士論文、コロラド大学、2011年。
[PNSurvey99] Campbell, A., De Meer, H., Kounavis, M., Miki, K., Vicente, J., and D. Villela, "A Survey of Programmable Networks", ACM SIGCOMM Computer Communication Review, Volume 29, Issue 2, pp. 7-23, September 1992.
[PNSurvey99] Campbell、A.、De Meer、H.、Kounavis、M.、Miki、K.、Vicente、J。、およびD. Villela、「A Survey of Programmable Networks」、ACM SIGCOMM Computer Communication Review、Volume 29 、第2号、7〜23ページ、1992年9月。
[Peregrine] Chiueh, D., Tu, C., Wang, Y., Wang, P., Li, K., and Y. Huang, "Peregrine: An All-Layer-2 Container Computer Network", In Proceedings of the 2012 IEEE 5th International Conference on Cloud Computing, pp. 686-693, 2012.
[Peregrine] Chiueh、D.、Tu、C.、Wang、Y.、Wang、P.、Li、K。、およびY. Huang、「Peregrine：An All-Layer-2 Container Computer Network」、Proceedings of 2012 IEEE 5th International Conference on Cloud Computing、pp。686-693、2012
[PiNA] Day, J., "Patterns in Network Architecture: A Return to Fundamentals", Prentice Hall, ISBN 0132252422, 2008.
[PiNA]デイ、J。、「ネットワークアーキテクチャのパターン：基本への回帰」、プレンティスホール、ISBN 0132252422、2008。
[RCP] Caesar, M., Caldwell, D., Feamster, N., Rexford, J., Shaikh, A., and J. van der Merwe, "Design and Implementation of a Routing Control Platform", In Proceedings of the 2nd conference on Symposium on Networked Systems Design & Implementation Volume 2, pp. 15-28, 2005.
[RCP] Caesar、M.、Caldwell、D.、Feamster、N.、Rexford、J.、Shaikh、A。、およびJ. van der Merwe、「ルーティング制御プラットフォームの設計および実装」、Proceedings of theネットワーク化されたシステムの設計と実装に関するシンポジウム第2会議、第2巻、15〜28ページ、2005年。
[REST] Fielding, Roy, "Chapter 5: Representational State Transfer (REST)", in Disseration "Architectural Styles and the Design of Network-based Software Architectures", 2000.
[REST] Fielding、Roy、「Chapter 5：Representational State Transfer（REST）」、Insertation「Architectural Styles and the Design of Network-based Software Architectures」、2000。
[RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware", STD 37, RFC 826, November 1982, <http://www.rfc-editor.org/info/rfc826>.
[RFC0826] Plummer、D。、「イーサネットアドレス解決プロトコル：またはネットワークプロトコルアドレスをイーサネットハードウェアで送信するための48ビットイーサネットアドレスに変換する」、STD 37、RFC 826、1982年11月、<http：//www.rfc- editor.org/info/rfc826>。
[RFC1953] Newman, P., Edwards, W., Hinden, R., Hoffman, E., Ching Liaw, F., Lyon, T., and G. Minshall, "Ipsilon Flow Management Protocol Specification for IPv4 Version 1.0", RFC 1953, May 1996, <http://www.rfc-editor.org/info/rfc1953>.
[RFC1953] Newman、P.、Edwards、W.、Hinden、R.、Hoffman、E.、Ching Liaw、F.、Lyon、T。、およびG. Minshall、「IPv4バージョン1.0のIpsilonフロー管理プロトコル仕様」 、RFC 1953、1996年5月、<http://www.rfc-editor.org/info/rfc1953>。
[RFC2297] Newman, P., Edwards, W., Hinden, R., Hoffman, E., Liaw, F., Lyon, T., and G. Minshall, "Ipsilon's General Switch Management Protocol Specification Version 2.0", RFC 2297, March 1998, <http://www.rfc-editor.org/info/rfc2297>.
[RFC2297]ニューマン、P。、エドワーズ、W。、ヒンデン、R。、ホフマン、E。、リアウ、F。、リヨン、T。、およびG.ミンシャル、「Ipsilon's General Switch Management Protocol Specification Version 2.0」、RFC 2297、1998年3月、<http://www.rfc-editor.org/info/rfc2297>。
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999, <http://www.rfc-editor.org/info/rfc2578>.
[RFC2578] McCloghrie、K.、Ed。、Perkins、D.、Ed。、and J. Schoenwaelder、Ed。、 "Structure of Management Information Version 2（SMIv2）"、STD 58、RFC 2578、April 1999、<http ：//www.rfc-editor.org/info/rfc2578>。
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002, <http://www.rfc-editor.org/info/rfc3411>.
[RFC3411] Harrington、D.、Presuhn、R。、およびB. Wijnen、「An Simple Describing for Simple Network Management Protocol（SNMP）Management Frameworks」、STD 62、RFC 3411、2002年12月、<http：// www。 rfc-editor.org/info/rfc3411>。
[RFC3412] Case, J., Harrington, D., Presuhn, R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3412, December 2002, <http://www.rfc-editor.org/info/rfc3412>.
[RFC3412] Case、J.、Harrington、D.、Presuhn、R.、and B. Wijnen、 "Message Processing and Dispatching for the Simple Network Management Protocol（SNMP）"、STD 62、RFC 3412、December 2002、<http ：//www.rfc-editor.org/info/rfc3412>。
[RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002, <http://www.rfc-editor.org/info/rfc3414>.
[RFC3414] Blumenthal、U。およびB. Wijnen、「バージョン3のSimple Network Management Protocol（SNMPv3）用のユーザーベースのセキュリティモデル（USM）」、STD 62、RFC 3414、2002年12月、<http：// www .rfc-editor.org / info / rfc3414>。
[RFC3417] Presuhn, R., "Transport Mappings for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3417, December 2002, <http://www.rfc-editor.org/info/rfc3417>.
[RFC3417] Presuhn、R。、「トランスポートマッピングの簡易ネットワーク管理プロトコル（SNMP）」、STD 62、RFC 3417、2002年12月、<http://www.rfc-editor.org/info/rfc3417>。
[RFC3418] Presuhn, R., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002, <http://www.rfc-editor.org/info/rfc3418>.
[RFC3418] Presuhn、R。、「簡易ネットワーク管理プロトコル（SNMP）の管理情報ベース（MIB）」、STD 62、RFC 3418、2002年12月、<http://www.rfc-editor.org/info/ rfc3418>。
[RFC3535] Schoenwaelder, J., "Overview of the 2002 IAB Network Management Workshop", RFC 3535, May 2003, <http://www.rfc-editor.org/info/rfc3535>.
[RFC3535] Schoenwaelder、J。、「Overview of the 2002 IAB Network Management Workshop」、RFC 3535、2003年5月、<http://www.rfc-editor.org/info/rfc3535>。
[RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, "Forwarding and Control Element Separation (ForCES) Framework", RFC 3746, April 2004, <http://www.rfc-editor.org/info/rfc3746>.
[RFC3746] Yang、L.、Dantu、R.、Anderson、T。、およびR. Gopal、「Forwarding and Control Element Separation（ForCES）Framework」、RFC 3746、2004年4月、<http：//www.rfc- editor.org/info/rfc3746>。
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006, <http://www.rfc-editor.org/info/rfc4271>.
[RFC4271] Rekhter、Y.、Li、T。、およびS. Hares、「A Border Gateway Protocol 4（BGP-4）」、RFC 4271、2006年1月、<http://www.rfc-editor.org/ info / rfc4271>。
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006, <http://www.rfc-editor.org/info/rfc4655>.
[RFC4655] Farrel、A.、Vasseur、J。、およびJ. Ash、「A Path Computation Element（PCE）-Based Architecture」、RFC 4655、2006年8月、<http://www.rfc-editor.org/ info / rfc4655>。
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009, <http://www.rfc-editor.org/info/rfc5424>.
[RFC5424] Gerhards、R。、「The Syslog Protocol」、RFC 5424、2009年3月、<http://www.rfc-editor.org/info/rfc5424>。
[RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009, <http://www.rfc-editor.org/info/rfc5440>.
[RFC5440] Vasseur、JP。とJL。 Le Roux、「Path Computation Element（PCE）Communication Protocol（PCEP）」、RFC 5440、2009年3月、<http://www.rfc-editor.org/info/rfc5440>。
[RFC5531] Thurlow, R., "RPC: Remote Procedure Call Protocol Specification Version 2", RFC 5531, May 2009, <http://www.rfc-editor.org/info/rfc5531>.
[RFC5531] Thurlow、R。、「RPC：Remote Procedure Call Protocol Specification Version 2」、RFC 5531、2009年5月、<http://www.rfc-editor.org/info/rfc5531>。
[RFC5743] Falk, A., "Definition of an Internet Research Task Force (IRTF) Document Stream", RFC 5743, December 2009, <http://www.rfc-editor.org/info/rfc5743>.
[RFC5743] Falk、A。、「Definition of an Internet Research Task Force（IRTF）Document Stream」、RFC 5743、2009年12月、<http://www.rfc-editor.org/info/rfc5743>。
[RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and Control Element Separation (ForCES) Protocol Specification", RFC 5810, March 2010, <http://www.rfc-editor.org/info/rfc5810>.
[RFC5810] Doria、A.、Hadi Salim、J.、Haas、R.、Khosravi、H.、Wang、W.、Dong、L.、Gopal、R。、およびJ. Halpern、「転送および制御要素の分離（ForCES）プロトコル仕様」、RFC 5810、2010年3月、<http://www.rfc-editor.org/info/rfc5810>。
[RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control Element Separation (ForCES) Forwarding Element Model", RFC 5812, March 2010, <http://www.rfc-editor.org/info/rfc5812>.
[RFC5812] Halpern、J。およびJ. Hadi Salim、「Forwarding and Control Element Separation（ForCES）Forwarding Element Model」、RFC 5812、2010年3月、<http://www.rfc-editor.org/info/rfc5812> 。
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010, <http://www.rfc-editor.org/info/rfc5880>.
[RFC5880] Katz、D。およびD. Ward、「Bidirectional Forwarding Detection（BFD）」、RFC 5880、2010年6月、<http://www.rfc-editor.org/info/rfc5880>。
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, October 2010, <http://www.rfc-editor.org/info/rfc6020>.
[RFC6020] Bjorklund、M。、「YANG-ネットワーク構成プロトコル（NETCONF）のデータモデリング言語」、RFC 6020、2010年10月、<http://www.rfc-editor.org/info/rfc6020>。
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. Bierman, "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011, <http://www.rfc-editor.org/info/rfc6241>.
[RFC6241] Enns、R.、Bjorklund、M.、Schoenwaelder、J。、およびA. Bierman、「Network Configuration Protocol（NETCONF）」、RFC 6241、2011年6月、<http://www.rfc-editor.org / info / rfc6241>。
[RFC6632] Ersue, M. and B. Claise, "An Overview of the IETF Network Management Standards", RFC 6632, June 2012, <http://www.rfc-editor.org/info/rfc6632>.
[RFC6632] Ersue、M。およびB. Claise、「An Overview of the IETF Network Management Standards」、RFC 6632、June 2012、<http://www.rfc-editor.org/info/rfc6632>。
[RFC7011] Claise, B., Trammell, B., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, September 2013, <http://www.rfc-editor.org/info/rfc7011>.
[RFC7011] Claise、B.、Trammell、B。、およびP. Aitken、「Specification of the IP Flow Information Export（IPFIX）Protocol for the Exchange of Flow Information of Exchange」、STD 77、RFC 7011、2013年9月、<http： //www.rfc-editor.org/info/rfc7011>。
[RFC7047] Pfaff, B. and B. Davie, "The Open vSwitch Database Management Protocol", RFC 7047, December 2013, <http://www.rfc-editor.org/info/rfc7047>.
[RFC7047] Pfaff、B。およびB. Davie、「The Open vSwitch Database Management Protocol」、RFC 7047、2013年12月、<http://www.rfc-editor.org/info/rfc7047>。
[RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined Networking: A Perspective from within a Service Provider Environment", RFC 7149, 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、2014年3月、<http://www.rfc-editor.org/info/rfc7149 >。
[RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. Weingarten, "An Overview of Operations, Administration, and Maintenance (OAM) Tools", RFC 7276, June 2014, <http://www.rfc-editor.org/info/rfc7276>.
[RFC7276]ミズラヒ、T。、スプレッチャー、N。、ベラガンバ、E。、およびY.ウェインガルテン、「運用、管理、および保守（OAM）ツールの概要」、RFC 7276、2014年6月、<http：// www.rfc-editor.org/info/rfc7276>。
[RINA] Day, J., Matta, I., and K. Mattar, "Networking is IPC: A Guiding Principle to a Better Internet", In Proceedings of the 2008 ACM CoNEXT Conference, Article No. 67, 2008.
[RINA] Day、J.、Matta、I。、およびK. Mattar、「ネットワーキングはIPC：より良いインターネットへの指導原則」、2008 ACM CoNEXT会議の議事録、2008年の記事No. 67。
[RouteFlow] Nascimento, M., Rothenberg, C., Salvador, M., Correa, C., de Lucena, S., and M. Magalhaes, "Virtual Routers as a Service: The RouteFlow Approach Leveraging Software-Defined Networks", In Proceedings of the 6th International Conference on Future Internet Technologies, pp. 34-37, 2011.
[RouteFlow] Nascimento、M.、Rothenberg、C.、Salvador、M.、Correa、C.、de Lucena、S。、およびM. Magalhaes、「サービスとしての仮想ルーター：ソフトウェア定義ネットワークを活用したRouteFlowアプローチ」 、第6回国際インターネット会議に関する議事録、pp。34-37、2011年。
[SDNACS] Kreutz, D., Ramos, F., Verissimo, P., Rothenberg, C., Azodolmolky, S., and S. Uhlig, "Software-Defined Networking: A Comprehensive Survey", Networking and Internet Architecture (cs.NI), arXiv:1406.0440, 2014.
[SDNACS] Kreutz、D.、Ramos、F.、Verissimo、P.、Rothenberg、C.、Azodolmolky、S。、およびS. Uhlig、「Software-Defined Networking：A Comprehensive Survey」、Networking and Internet Architecture（cs .NI）、arXiv：1406.0440、2014。
[SDNHistory] Feamster, N., Rexford, J., and E. Zegura, "The Road to SDN: An Intellectual History of Programmable Networks", ACM Queue, Volume 11, Issue 12, 2013.
[SDNHistory] Feamster、N.、Rexford、J。、およびE. Zegura、「SDNへの道：プログラマブルネットワークの知的歴史」、ACM Queue、Volume 11、Issue 12、2013。
[SDNNFV] Haleplidis, E., Hadi Salim, J., Denazis, S., and O. Koufopavlou, "Towards a Network Abstraction Model for SDN", Journal of Network and Systems Management: Special Issue on Management of Software Defined Networks, pp. 1-19, 2014.
[SDNNFV] Haleplidis、E.、Hadi Salim、J.、Denazis、S。、およびO. Koufopavlou、「SDNのネットワーク抽象化モデルに向けて」、Journal of Network and Systems Management：Special Issue on Management of Software Defined Networks、 pp。1-19、2014。
[SDNSecOF] Kloti, R., Kotronis, V., and P. Smith, "OpenFlow: A Security Analysis", 21st IEEE International Conference on Network Protocols (ICNP) pp. 1-6, October 2013.
[SDNSecOF] Kloti、R.、Kotronis、V.、and P. Smith、 "OpenFlow：A Security Analysis"、21st IEEE International Conference on Network Protocols（ICNP）pp。1-6、October 2013。
[SDNSecServ] Scott-Hayward, S., O'Callaghan, G., and S. Sezer, "SDN Security: A Survey", In IEEE SDN for Future Networks and Services (SDN4FNS), pp. 1-7, 2013.
[SDNSecServ] Scott-Hayward、S.、O'Callaghan、G.、and S. Sezer、 "SDN Security：A Survey"、In IEEE SDN for Future Networks and Services（SDN4FNS）、pp。1-7、2013。
[SDNSecurity] Kreutz, D., Ramos, F., and P. Verissimo, "Towards Secure and Dependable Software-Defined Networks", In Proceedings of the second ACM SIGCOMM workshop on Hot Topics in Software Defined Networking, pp. 55-60, 2013.
[SDNSecurity] Kreutz、D.、Ramos、F。、およびP. Verissimo、「安全で信頼性の高いソフトウェア定義ネットワークに向けて」、ソフトウェア定義ネットワークのホットトピックに関する2番目のACM SIGCOMMワークショップの議事録、55〜60ページ、2013。
[SDNSurvey] Nunes, B., Mendonca, M., Nguyen, X., Obraczka, K., and T. Turletti, "A Survey of Software-Defined Networking: Past, Present, and Future of Programmable Networks", IEEE Communications Surveys and Tutorials, DOI:10.1109/SURV.2014.012214.00180, 2014.
[SDNSurvey] Nunes、B.、Mendonca、M.、Nguyen、X.、Obraczka、K。、およびT. Turletti、「ソフトウェア定義ネットワーキングの調査：プログラマブルネットワークの過去、現在、未来」、IEEEコミュニケーションズ調査とチュートリアル、DOI：10.1109 / SURV.2014.012214.00180、2014。
[SLTSDN] Jarraya, Y., Madi, T., and M. Debbabi, "A Survey and a Layered Taxonomy of Software-Defined Networking", IEEE Communications Surveys and Tutorials, Volume 16, Issue 4, pp. 1955-1980, 2014.
[SLTSDN] Jarraya、Y.、Madi、T。、およびM. Debbabi、「ソフトウェア定義ネットワーキングの調査と階層化分類法」、IEEEコミュニケーション調査およびチュートリアル、第16巻、第4号、1955-1980年、 2014。
[SoftRouter] Lakshman, T., Nandagopal, T., Ramjee, R., Sabnani, K., and T. Woo, "The SoftRouter Architecture", In Proceedings of the ACM SIGCOMM Workshop on Hot Topics in Networking, 2004.
[SoftRouter] Lakshman、T.、Nandagopal、T.、Ramjee、R.、Sabnani、K。、およびT. Woo、「The SoftRouter Architecture」、ネットワーキングのホットトピックに関するACM SIGCOMMワークショップのプロシーディングス、2004年。
[Tempest] Rooney, S., van der Merwe, J., Crosby, S., and I. Leslie, "The Tempest: A Framework for Safe, Resource Assured, Programmable Networks", Communications Magazine, IEEE, Volume 36, Issue 10, pp. 42-53, 1998.
[テンペスト]ルーニーS.、ファンデルマーウェJ.、クロスビーS.、およびI.レスリー、「The Tempest：A Framework for Safe、Resource Assured、Programmable Networks」、Communications Magazine、IEEE、Volume 36、Issue 10、pp。42-53、1998。
Acknowledgements
謝辞
The authors would like to acknowledge Salvatore Loreto and Sudhir Modali for their contributions in the initial discussion on the SDNRG mailing list as well as their document-specific comments; they helped put this document in a better shape.
著者は、SDNRGメーリングリストに関する最初のディスカッションでの貢献とドキュメント固有のコメントについて、Salvatore LoretoとSudhir Modaliに感謝します。彼らはこの文書をより良い形にするのを助けました。
Additionally, we would like to thank (in alphabetical order) Shivleela Arlimatti, Roland Bless, Scott Brim, Alan Clark, Luis Miguel Contreras Murillo, Tim Copley, Linda Dunbar, Ken Gray, Deniz Gurkan, Dave Hood, Georgios Karagiannis, Bhumip Khasnabish, Sriganesh Kini, Ramki Krishnan, Dirk Kutscher, Diego Lopez, Scott Mansfield, Pedro Martinez-Julia, David E. Mcdysan, Erik Nordmark, Carlos Pignataro, Robert Raszuk, Bless Roland, Francisco Javier Ros Munoz, Dimitri Staessens, Yaakov Stein, Eve Varma, Stuart Venters, Russ White, and Lee Young for their critical comments and discussions at IETF 88, IETF 89, and IETF 90 and on the SDNRG mailing list, which we took into consideration while revising this document.
さらに、（アルファベット順で）Shivleela Arlimatti、Roland Bless、Scott Brim、Alan Clark、Luis Miguel Contreras Murillo、Tim Copley、Linda Dunbar、Ken Gray、Deniz Gurkan、Dave Hood、Georgios Karagiannis、Bhumip Khasnabish、 Sriganesh Kini、Ramki Krishnan、Dirk Kutscher、Diego Lopez、Scott Mansfield、Pedro Martinez-Julia、David E. Mcdysan、Erik Nordmark、Carlos Pignataro、Robert Raszuk、Bless Roland、Francisco Javier Ros Munoz、Dimitri Staessens、Yaakov Stein、Eve Varma 、スチュワートベンターズ、ラスホワイト、およびリーヤングは、IETF 88、IETF 89、およびIETF 90、ならびにSDNRGメーリングリストでの重要なコメントと議論について、このドキュメントを改訂する際に考慮に入れました。
We would also like to thank (in alphabetical order) Spencer Dawkins and Eliot Lear for their IRSG reviews, which further refined this document.
また、IRSGレビューを提供してくれたSpencer DawkinsとEliot Learに（アルファベット順で）感謝します。
Finally, we thank Nobo Akiya for his review of the section on BFD, Julien Meuric for his review of the section on PCE, and Adrian Farrel and Benoit Claise for their IESG reviews of this document.
最後に、BFDに関するセクションのレビューについてはNobo Akiyaに、PCEに関するセクションのレビューについてはJulien Meuricが、このドキュメントのIESGレビューについてはAdrian FarrelとBenoit Claiseに感謝します。
Kostas Pentikousis is supported by [ALIEN], a research project partially funded by the European Community under the Seventh Framework Program (grant agreement no. 317880). The views expressed here are those of the author only. The European Commission is not liable for any use that may be made of the information in this document.
Kostas Pentikousisは、[ALIEN]によってサポートされています。[ALIEN]は、第7フレームワークプログラム（付与契約番号317880）に基づき、欧州共同体によって部分的に資金提供されています。ここで表明されている見解は、著者のみの見解です。欧州委員会は、この文書に記載されている情報のいかなる使用についても責任を負いません。
Contributors
貢献者
The authors would like to acknowledge (in alphabetical order) the following persons as contributors to this document. They all provided text, pointers, and comments that made this document more complete:
著者は、このドキュメントへの寄稿者として（アルファベット順で）次の人物に感謝したいと思います。彼らはすべて、このドキュメントをより完全なものにするテキスト、ポインタ、コメントを提供しました。
o Daniel King for providing text related to PCEP.
o PCEPに関連するテキストを提供してくださったDaniel King。
o Scott Mansfield for information regarding current ITU work on SDN.
o SDNでの現在のITU作業に関する情報については、Scott Mansfieldを参照してください。
o Yaakov Stein for providing text related to the CAP theorem and SDO-related information.
o CAP定理とSDO関連情報に関連するテキストを提供してくれたYaakov Stein。
o Russ White for text suggestions on the definitions of control, management, and application.
o コントロール、管理、およびアプリケーションの定義に関するテキストの提案については、ラスホワイト。
Authors' Addresses
著者のアドレス
Evangelos Haleplidis (editor) University of Patras Department of Electrical and Computer Engineering Patras 26500 Greece
エヴァンジェロスハレプリディス（編集者）パトラス大学電気コンピュータ工学科パトラス26500ギリシャ
EMail: ehalep@ece.upatras.gr
Kostas Pentikousis (editor) EICT GmbH Torgauer Strasse 12-15 10829 Berlin Germany
Kostas Pentikousis（編集者）EICT GmbH Torgauer Strasse 12-15 10829ベルリンドイツ
EMail: k.pentikousis@eict.de
Spyros Denazis University of Patras Department of Electrical and Computer Engineering Patras 26500 Greece
Spyros Denazisパトラス大学電気およびコンピュータ工学科Patras 26500ギリシャ
EMail: sdena@upatras.gr Jamal Hadi Salim Mojatatu Networks Suite 400, 303 Moodie Dr. Ottawa, Ontario K2H 9R4 Canada
メール：sdena@upatras.gr Jamal Hadi Salim Mojatatu Networks Suite 400、303 Moodie Dr. Ottawa、オンタリオK2H 9R4カナダ
EMail: hadi@mojatatu.com
David Meyer Brocade
デビッドマイヤーブロケード
EMail: dmm@1-4-5.net
Odysseas Koufopavlou University of Patras Department of Electrical and Computer Engineering Patras 26500 Greece
Odysseas Koufopavlouパトラス大学電気電子工学科パトラス26500ギリシャ
EMail: odysseas@ece.upatras.gr