I-D"SDN Layers and Architecture Terminology"読んでみた(3)

4. SDN Model View

4.  SDN Model View

   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 of Figure 1.

[NOX] や [Beacon] のような SDN コントローラは、CPSI を実装した、コントロールプレーン・アプリケーションとサービスの集合である。[NOX] と [Beacon] はどちらも OpenFlow をつかい、アプリケーションに対してノースバウンドインタフェースを提供する。コントローラに対する SDN ノースバウンドインタフェースは、Figure 1 の Network Service Abstraction Layer に実装される。

   The above model can be used to describe in a concise manner all
   prominent SDN-enabling technologies, as we explain in the following

この後の節で説明するように、上記のモデルは、すべての主要な SDN を実現する技術を、簡潔な方法で記述するために使うことができる。

4.1. ForCES
4.1.  ForCES

   The IETF-standardized Forwarding and Control Element Separation
   (ForCES) framework [RFC3746] consists of one model and two protocols.
   ForCES separates the Forwarding 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 が標準化した Forwarding and Control Element Separation (ForCES) フレームワーク [RFC3746] は、一つのモデルと二つのプロトコルから構成されている。ForCES はオープンインタフェース、つまり ForCES モデル [RFC5812] を使ってモデル化されるフォワーディングプレーンの実体(entity)上で動作する 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 and secondly with a protocol to transport

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 an XML language, based on an XML schema.

ForCES は、グラフ中で接続されたときに Forwarding Element (FE) を構成する、Logical Functional Blocks (LFBs) を使ったフォワーディングプレーンのモデルをつくる。LFB は XML スキーマに基づく XML で記述される。

   LFB definitions include base and custom-defined datatypes; metadata
   definitions; input and output ports; operational parameters or
   components; 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

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 モデルの要素を関し、設定、制御するために使うことができる。そのプロトコルは、単純なコマンド、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

Figure 1 について、ForCES モデル [RFC5812] は、LFB を使うことで、オペレーショナルプレーンとフォワーディングプレーンの両方に対する、DAL に適している。ForCES プロトコル [RFC5810] は (MSPI のために利用することもできるが) CPSI のために設計されており、それに適している。


   The Network Configuration Protocol (NETCONF [RFC6241]), is an IETF-
   standardized network management protocol [RFC6632].  NETCONF provides
   mechanisms to install, manipulate, and delete the configuration of
   network devices.

Network Configuration Protocol (NETCONF [RFC6241]) は、IETF で標準化されたネットワーク管理プロトコル [RFC6632] である。NETCONF はネットワーク機器の設定インストール、操作、削除のための仕組みを提供する。

   NETCONF protocol operations are realized as remote procedure calls
   (RPCs).  The NETCONF protocol uses an Extensible Markup Language
   (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 プロトコルは eXtensible Markup Language (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 NETCONF, 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
   datatype and allows custom defined datatypes as well.

YANG はデータの階層的な構成を木構造でモデル化し、モデル内部で各ノードは、値または子ノードの集合のいずれかを持つ。加えて YANG はデータモデルを、モジュールとサブモジュールの中に、再利用性と拡張性を持たせるように構造化する。YANG モデルは、データに強制される制約を記述することができる。各著素あれた YANG は基本的なデータタイプの集合を持ち、独自定義のデータタイプも同様に利用可能である。

   YANG allows the definition of NETCONF RPCs allowing the protocol to
   have an extensible number of commands.  For RPC definition, 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 plane.  NETCONF
   [RFC6241] is suitable for the MPSI.  NETCONF is a management protocol
   [RFC6241] which was not (originally) designed for fast CP updates,
   and it might not be suitable for addressing the requirements of CPSI.

Figure 1 について、YANG モデル [RFC65020] は、フォワーディングプレーンとオペレーショナルプレーンのための DAL を規定するのに適している。NETCONF [RFC6241] は MPSI に適している。NETCONF はマネジメントプロトコル [RFC6241] であり、高速な CP アップデートのために(元々は)設計されておらず、CPSI の要求を解決するためには適していない。

4.3. OpenFlow
4.3.  OpenFlow

   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 [OFSIGC].  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]。最初は、その目的は研究者に対して実験的なプロトコルをプロダクション・ネットワークの中で実行する方法を提供することだった [OFSIGC]。OpenFlow はたくさんの改訂を受け、同様に今後も追加の改訂が起こりうる。これ以降の記述はバージョン 1.4 [OpenFlow] を反映している。要するに、OpenFlow はプロトコルを定義しており、それを介することで、論理的に集中化されたコントローラは OpenFlow スイッチを制御することができる。OpenFlow 準拠のスイッチそれぞれは、パケット検索を実行するために使われる、ひとつ以上のフローテーブルを保持する。パケット検索と転送に関して、明確なアクションがとられる。グループテーブルと外部コントローラとの 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 Plane 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.

Figure 1 に関して、OpenFlow スイッチ仕様 [OpenFlow] は、フォワーディングプレーンのためだけでなく CPSI のためにも DAL を定義する。OF-CONFIG プロトコル [OF-CONFIG] は YANG モデル [RFC6020] を元にしており、OpenFlow スイッチのフォワーディングプレーンとオペレーショナルプレーンのための DAL を提供し、NETCONF [RFC6241] を MPSI として規定する。OF-CONFIG は OpenFlow DAL と重複するが、トランスポートプロトコルとしての NETCONF [RFC6241] によるものであり、それについては前の節で説明した制限を共有している。

4.4. Interface to the Routing System
4.4.  Interface to the Routing System

   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.

Interface to Routing System (I2RS) は、標準的なインタフェースを、ルーティングシステムに提供する。(インタフェースは)プロトコルベースのコントロールまたはマネジメントインタフェースの集合を介した、リアルタイムまたはイベントドリブンの相互作用のためのものである。基本的に、I2RS の主要な目的のひとつは、RIB をプログラム可能にすることであり、それによって新しい種類のネットワークプロビジョングと操作が可能にする。

   I2RS does 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
   [I-D.ietf-i2rs-problem-statement] 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]
   modelling language.

I2RS は、初期では新しいインタフェースを作るつもりはなく、むしろ既存のインタフェースを拡張したり利用したりすることで、ルーティングシステムのための情報モデルを定義している。たとえば、最新の I2RS の検討事項 [I-D.ietf-i2rs-problem-statement] では、以前定義された IETF プロトコル(たとえば ForCES [RFC5810], NETCONF [RFC6241], SNMP [RFC3417])について議論している。情報およびデータモデルの定義に関して、I2RS ワーキンググループは YANG [RFC6020] モデリング言語を使うことを選択している。

   Currently the I2RS working group is developing an Information Model
   [I-D.ietf-i2rs-rib-info-model] in regards to the Network Services
   Abstraction Layer for the I2RS agent.

現在の I2RS ワーキンググループは、I2RS エージェントのための Network Service Abstraction Layer (NSAL) に関する情報モデル [I-D.ietf-i2rs-rib-info-model] を開発している。

   With respect to Figure 1, the I2RS architecture
   [I-D.ietf-i2rs-architecture] 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 the 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 provide access even to other than control

Figure 1 について、I2RS アーキテクチャ [I-D.ietf-i2rs-architecture] は、コントロールおよびアプリケーションプレーンを含み、利用可能な任意の CPSI (それは ForCES [RFC5810]、OpenFlow [OpenFlow] あるいはほかのインタフェースになるかもしれない) と DAL を使う。さらに、I2RS エージェントはコントロールプレーン・サービスである。その上にあるすべてのサービスまたはアプリケーションは、コントロールプレーン、マネジメントプレーン、あるいはアプリケーションプレーンのいずれかに属している。I2RS ドキュメント中では、エージェントへのマネジメントアクセスは、SNMP や NETCONF のようなマネジメントプロトコルによって提供される。I2RS プロトコルもまたサービスインタフェースにマップされ、それはコントロールアプリケーション以外にも接続方法を提供するだろう。

4.5. SNMP
4.5.  SNMP

   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.

Simple Network Management Protocol (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 (OID).  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 は Management Information Bases (MIBs) の定義によって、データの記述に拡張可能な設計を使っている。MIB は機器サブシステムの管理データの構造を記述する。MIB はオブジェクト識別子 (OID) を格納する階層的な名前空間を使う。各 OID は、SNMP を介して読んだり設定したりできる変数を識別する。MIB は Structure of Managmenet Information Version 2 [RFC2578] によって定義されている記法を使っている。

   An early example of SNMP in the context of SDN is discussed in

SDN の文脈における SNMP の初期の例は [Peregrine] で議論されている。

   With respect to Figure 1, SNMP MIBs can be used to describe DAL for
   the Forwarding and Operational Plane.  Similar to YANG, SNMP MIBs are
   able to describe DAL for the Forwarding Plane.  SNMP, similar to
   NETCONF, is suited for the MPSI.

Figure 1 について、SNMP MIB は、フォワーディングプレーンとオペレーショナルプレーンのための DAL を記述するために使うことができる。YANG と同じように、SNMP MIB はフォワーディングプレーンのための DAL を記述できる。SNMP は NETCONF と似ており、MPSI に適している。

4.6. PCEP
4.6.  PCEP

   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 an IETF protocol for
   communication between a Path Computation Client (PCC) and a PCE, or
   between multiple PCEs.

Path Computation Element (PCE) [RFC4655] アーキテクチャは単一のサービスまたはサービスの集合のために、パスを計算する能力を持つエンティティを定義する。PCE はネットワークノード、ネットワーク管理ステーション、あるいは、専用の計算プラットフォーム(リソースを認識し(resource-awre)、様々なパス計算問題とスイッチング技術に対する複数の制約を考慮する能力を持つ)であるかもしれない。PCE Communication Protocol (PCEP) [RFC5440] は、Path Computation Client (PCC) と PCE 間、または、複数の PCE 間でコミュニケーションするための IETF プロトコルである。

   The PCE 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 NMS nodes, and the type of optimization request which may
   significantly impact the optimization response time from the PCE to
   the PCC.

PCE は、サービス、end-to-end コネクションのシグナリング、実際のパケット転送のためのパス計算を分離するネットワーク構想(vision)を表現する。オンライン、オフラインのパス計算の定義は、PCE のネットワークから NMS ノードへの到達可能性(reachability)に依存しており、PCE から PCC への再適化応等時間に重大な影響を与える、最適化要求の一種である。

   The PCEP messaging mechanism facilitates the specification of
   computation endpoints (source and destination node addresses) and
   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 which may act as domain
   control entities (services and applications).  The PCE working group
   is specifying extensions [I-D.ietf-pce-stateful-pce], which allow an
   active PCE to control, using PCEP, MPLS or GMPLS Label Switched Paths
   (LSP), thus making it applicable for the CPSI for MPLS and GMPLS

Figure 1 について、PCE は、コントロールプレーン・アプリケーションのためのサービスを提供する、コントロールプレーン・サービスである。PCEP は、ドメイン制御エンティティ(サービスとアプリケーション)として動作する PCE 間の east-west インタフェースとして使われるだろう。PCE ワーキンググループは、拡張 [I-D.ietf-pce-stateful-pce] を規定している。その拡張は、アクティブな PCE が PCEP、MPLS または GMPLS Label Switched Paths (LSP) を使って制御できるようにし、MPLS と GMPLS スイッチのための CPSI を適用できるようにする。

4.7. BFD
4.7.  BFD

   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.

Bidirectional Forwarding Detection (BFD) [RFC5880] は、IETF で標準化されたネットワークプロトコルで、二つの転送要素間の経路障害を、とても低遅延で検出するために設計されている。転送要素には、物理インタフェース、サブインタフェース、データリンク、転送エンジン自身を含む。BFD は少ないオーバーヘッドで、任意のシステム間パス上の障害検出を提供できる。システム間パスには、直接接続する物理リンク、仮想回路 (virtual circuit)、トンネル、MPLS LSPs、マルチホップでルーティングされる経路、リターンパスが存在する単方向リンク、などがある。それは、転送と制御のエンジンが分離された場合に備えて、システムの転送エンジンの何らかの構成要素によく実装される。

   With respect to Figure 1, a BFD agent can be implemneted 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 use the
   forwarding plane to send/receive BFD packets and update the
   operational plane resources accordingly.  Services and applications
   of control and management plane that monitor or has subscribed to
   changes of resources, learn these changes through their respective
   interface and will take the necessary action.

Figure 1 について、BFD エージェントは、コントロールプレーンサービスまたはアプリケーションとして実装できる。BFD エージェントは BFD パケットの送信/受信を行うために、フォワーディングプレーンに向けて CPSI を使う。しかし、BFD エージェントは、通常、機器上のアプリケーションとして実装され、BFD パケットの送受信を行うためにフォワーディングプレーンを使い、それに応じてオペレーショナルプレーンのリソースを更新する。コントロールプレーンとマネジメントプレーンの、リソースの変更監視や予約を行うサービスとアプリケーションは、これらの変化をそれぞれのインタフェースを介して学習し、必要な行動をとる。

5. Summary
5.  Summary

   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 コミュニティによって公にレビューされ、今後数年の間、ネットワーク研究者、エンジニア、実務家(practitioner) の便利な道具として役立つことを、我々は願っている。

   We conclude this document with a brief summary of the SDN
   architecture layers terminology.  In general, we consider a network
   element as a composition of resources.  Each network element has a
   forwarding plane (FP), responsible for handling packets in the
   datapath, and an operational plane (OP), 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 taking 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 service abstraction layer (NSAL) where other more
   network applications or services may use them.  The taxonomy
   introduced in this document defines distinct SDN planes, abstraction
   layers and interfaces, aiming 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) によって抽象化され、ほかの複数のネットワークアプリケーションやサービスがそれらを使うことができる。本書で紹介している分類法は、個々のSDN プレーン、抽象化レイヤとインタフェースを定義し、SDN の用語を明確にすることと、特定の実装の選択に関係なく、SDN コミュニティ全体で一般的に認められた基準となる定義を確立することを目指している。

6. Contributors

6.  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

   Daniel King for providing text related to PCEP.

   Scott Mansfield for information regarding current ITU work on SDN.

   Yaakov Stein for providing text related to the CAP theorem and SDO-
   related information.

   Russ White for text suggestions on the definitions on control,
   management and application.

7. Acknowledgements

7.  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 draft-specific comments; they helped
   put this document in a better shape.

   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, Yaakov
   Stein, Dimitri Staessens, Eve Varma, Stuart Venters, Russ White and
   Lee Young for their critical comments and discussions at the IETF 88,
   IETF 89 and IETF 90 meetings and the SDNRG mailing list, which we
   took into consideration while revising this document.

   We would also like to thank (in alphabetical order) Spencer Dawkins
   and Eliot Lear for their IRSG reviews which further refined this

   Finally we thank Nobo Akiya for his review on the section on BFD,
   Julien Meuric for his review on the section of PCE, and Adrian Farrel
   and Benoit Claise for their IESG reviews of this document.

   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

8. IANA Considerations

8.  IANA Considerations

   This memo makes no requests to IANA.

9. Security Considerations

9.  Security Considerations

   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 and 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
   [SDNSecOF].  Security considerations regarding specific interfaces,
   such as, for example, ForCES, I2RS, SNMP, or NETCONF are addressed in
   their respective documents as well as [RFC7149].

本書は新しいネットワークアーキテクチャあるいはプロトコルについての提案は行っていない。従って、インターネットのセキュリティに対しては何も影響を及ぼさない。とはいっても、セキュリティはネットワークを利用する上で最優先であり、そのためネットワークアーキテクチャの設計や運用の展開の際には十分な考察が与えられるべきである。SDN におけるセキュリティは文献中で議論されており、たとえば [SDNSecurity], [SDNSecServ], [SDNSecOF] がある。特定のインタフェース(たとえば ForCES, I2RS, SNMP, NETCONF)に関するセキュリティ考察に関しては、[RFC7149] と同様に、それぞれのドキュメントに記載されている。

10. Informative References

10.  Informative References

   [A4D05]    Greenberg, Albert, et al., "A clean slate 4D approach to
              network control and management", ACM SIGCOMM Computer
              Communication Review 35.5 (2005): 41-54 , 2005.

   [ALIEN]    D. Parniewicz, R. Doriguzzi Corin, et al., "Design and
              Implementation of an OpenFlow Hardware Abstraction Layer",
              Proc. ACM SIGCOMM Workshop on Distributed Cloud Computing
              (DCC), Chicago, Illinois, USA, August 2014, pp. 71-76.
              doi> 10.1145/2627566.2627577 , 2014.

   [Beacon]   Erickson, David., "The beacon openflow controller.", In
              Proceedings of the second ACM SIGCOMM workshop on Hot
              topics in software defined networking, pp. 13-18. ACM,
              2013. , 2013.

   [CAPBR]    Eric A. Brewer, "Towards robust distributed systems.",
              Symposium on Principles of Distributed Computing (PODC).
              2000 , 2000.

   [CAPFN]    Panda, Aurojit, Colin Scott, Ali Ghodsi, Teemu Koponen,
              and Scott Shenker., "CAP for Networks.", In Proceedings of
              the second ACM SIGCOMM workshop on Hot topics in software
              defined networking, pp. 91-96. ACM, 2013. , 2013.

   [CAPGL]    Seth Gilbert, and Nancy Ann Lynch., "Brewer's conjecture
              and the feasibility of consistent, available, partition-
              tolerant web services", ACM SIGACT News 33.2 (2002):
              51-59. , 2002.

   [CORBA]    Object Management Group, "Common Object Request Broker
              Architecture specification version 3.3", November 2012,

   [DIOPR]    Denazis, Spyros, Kazuho Miki, John Vicente, and Andrew
              Campbell., "Designing interfaces for open programmable
              routers.", In Active Networks, pp. 13-24. Springer Berlin
              Heidelberg, 1999 , 1999.

   [ESNet]    Yu, James, and Imad Al Ajarmeh., "An empirical study of
              the NETCONF protocol.", In Networking and Services (ICNS),
              2010 Sixth International Conference on, pp. 253-258. IEEE,
              2010. , 2010.

   [FCAPS]    International Telecommunication Union, "X.700: Management
              Framework For Open Systems Interconnection (OSI) For CCITT
              Applications", September 1992,

              Atlas, A., Halpern, J., Hares, S., Ward, D., and T.
              Nadeau, "An Architecture for the Interface to the Routing
              System", draft-ietf-i2rs-architecture-05 (work in
              progress), July 2014.

              Atlas, A., Nadeau, T., and D. Ward, "Interface to the
              Routing System Problem Statement", draft-ietf-i2rs-
              problem-statement-04 (work in progress), June 2014.

              Bahadur, N., Folkes, R., Kini, S., and J. Medved, "Routing
              Information Base Info Model", draft-ietf-i2rs-rib-info-
              model-03 (work in progress), May 2014.

              Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP
              Extensions for Stateful PCE", draft-ietf-pce-stateful-
              pce-09 (work in progress), June 2014.

   [ITUATM]   CCITT, Geneva, Switzerland, "CCITT Recommendation 1.361,
              B-ISDN ATM Layer Specification", 1990.

   [ITUSG11]  Telecommunication Standardization sector of ITU, "ITU,
              Study group 11", 2013, <http://www.itu.int/en/ITU-T/

   [ITUSG13]  Telecommunication Standardization sector of ITU, "ITU,
              Study group 13", 2013, <http://www.itu.int/en/ITU-T/

   [ITUSS7]   Telecommunication Standardization sector of ITU, "ITU,
              Q.700 : Introduction to CCITT Signalling System No. 7",

              ITU-T Study Group 13, "Y.3300, Framework of software-
              defined networking", June 2014, <http://www.itu.int/ITU-

   [KANDOO]   Hassas Yeganeh, Soheil, and Yashar Ganjali., "Kandoo: a
              framework for efficient and scalable offloading of control
              applications.", In Proceedings of the first workshop on
              Hot topics in software defined networks, pp. 19-24. ACM
              SIGCOMM, 2012. , 2012.

   [NFVArch]  European Telecommunication Standards Institute, "Network
              Functions Virtualisation (NFV): Architectural Framework;
              White paper, ETSI GS 9 NFV 002, 2013", December 2013,

   [NOX]      Gude, Natasha, Teemu Koponen, Justin Pettit, Ben Pfaff,
              Martin Casado, Nick McKeown, and Scott Shenker., "NOX:
              towards an operating system for networks.", ACM SIGCOMM
              Computer Communication Review 38, no. 3 (2008): 105-110. ,

   [NV09]     Chowdhury, NM Mosharaf Kabir, and Raouf Boutaba, "Network
              virtualization: state of the art and research challenges",
              Communications Magazine, IEEE 47.7 (2009): 20-26 , 2009.

              Open Networking Foundation, "OpenFlow Management and
              Configuration Protocol 1.1.1", March 2013,

   [OF08]     McKeown, Nick, et al., "OpenFlow: enabling innovation in
              campus networks", ACM SIGCOMM Computer Communication
              Review 38.2 (2008): 69-74 , 2008.

   [OFSIGC]   McKeown, Nick, Tom Anderson, Hari Balakrishnan, Guru
              Parulkar, Larry Peterson, Jennifer Rexford, Scott Shenker,
              and Jonathan Turner., "OpenFlow: enabling innovation in
              campus networks.", ACM SIGCOMM Computer Communication
              Review 38, no. 2 (2008): 69-74. , 1998.

   [ONFArch]  Open Networking Foundation, "SDN Architecture, Issue 1",
              June 2014,

              Open Networking Foundation, "The OpenFlow 1.4
              Specification.", October 2013,

   [P1520]    Biswas, Jit, Aurel A. Lazar, J-F. Huard, Koonseng Lim,
              Semir Mahjoub, L-F. Pau, Masaaki Suzuki, Soren
              Torstensson, Weiguo Wang, and Stephen Weinstein., "The
              IEEE P1520 standards initiative for programmable network
              interfaces.", Communications Magazine, IEEE 36, no. 10
              (1998): 64-70. , 1998.

   [PENet]    Hedstrom, Brian, Akshay Watwe, and Siddharth Sakthidharan,
              "Protocol Efficiencies of NETCONF versus SNMP for
              Configuration Management Functions", PhD dissertation,
              Master's thesis, University of Colorado, 2011 , 2011.

              Campbell, Andrew T., et al, "A survey of programmable
              networks", ACM SIGCOMM Computer Communication Review 29.2
              (1999): 7-23 , September 1992.

              Chiueh, Tzi-cker, Cheng-Chun Tu, Yu-Cheng Wang, Pai-Wei
              Wang, Kai-Wen Li, and Yu-Ming Huang., "Peregrine: An All-
              Layer-2 Container Computer Network.", In Cloud Computing
              (CLOUD), 2012 IEEE 5th International Conference on, pp.
              686-693. IEEE, 2012 , 2012.

   [PiNA]     John Day, "Patterns in network architecture: a return to
              fundamentals.", Prentice Hall (ISBN 0132252422). , 2007.

   [RCP]      Caesar, Matthew, Donald Caldwell, Nick Feamster, Jennifer
              Rexford, Aman Shaikh, and Jacobus 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. USENIX Association, 2005. , 2005.

   [REST]     Fielding, Roy, "Fielding Dissertation: Chapter 5:
              Representational State Transfer (REST).", 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.

   [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.

   [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.

   [RFC2578]  McCloghrie, K., Ed., Perkins, D., Ed., and J.
              Schoenwaelder, Ed., "Structure of Management Information
              Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.

   [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.

   [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

   [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.

   [RFC3417]  Presuhn, R., "Transport Mappings for the Simple Network
              Management Protocol (SNMP)", STD 62, RFC 3417, December

   [RFC3418]  Presuhn, R., "Management Information Base (MIB) for the
              Simple Network Management Protocol (SNMP)", STD 62, RFC
              3418, December 2002.

   [RFC3535]  Schoenwaelder, J., "Overview of the 2002 IAB Network
              Management Workshop", RFC 3535, May 2003.

   [RFC3746]  Yang, L., Dantu, R., Anderson, T., and R. Gopal,
              "Forwarding and Control Element Separation (ForCES)
              Framework", RFC 3746, April 2004.

   [RFC4271]  Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
              Protocol 4 (BGP-4)", RFC 4271, January 2006.

   [RFC4655]  Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
              Element (PCE)-Based Architecture", RFC 4655, August 2006.

   [RFC5440]  Vasseur, JP. and JL. Le Roux, "Path Computation Element
              (PCE) Communication Protocol (PCEP)", RFC 5440, March

   [RFC5531]  Thurlow, R., "RPC: Remote Procedure Call Protocol
              Specification Version 2", RFC 5531, May 2009.

   [RFC5743]  Falk, A., "Definition of an Internet Research Task Force
              (IRTF) Document Stream", RFC 5743, December 2009.

   [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.

   [RFC5812]  Halpern, J. and J. Hadi Salim, "Forwarding and Control
              Element Separation (ForCES) Forwarding Element Model", RFC
              5812, March 2010.

   [RFC5880]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
              (BFD)", RFC 5880, June 2010.

   [RFC6020]  Bjorklund, M., "YANG - A Data Modeling Language for the
              Network Configuration Protocol (NETCONF)", RFC 6020,
              October 2010.

   [RFC6241]  Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
              Bierman, "Network Configuration Protocol (NETCONF)", RFC
              6241, June 2011.

   [RFC6632]  Ersue, M. and B. Claise, "An Overview of the IETF Network
              Management Standards", RFC 6632, June 2012.

   [RFC7047]  Pfaff, B. and B. Davie, "The Open vSwitch Database
              Management Protocol", RFC 7047, December 2013.

   [RFC7149]  Boucadair, M. and C. Jacquenet, "Software-Defined
              Networking: A Perspective from within a Service Provider
              Environment", RFC 7149, March 2014.

   [RFC7276]  Mizrahi, T., Sprecher, N., Bellagamba, E., and Y.
              Weingarten, "An Overview of Operations, Administration,
              and Maintenance (OAM) Tools", RFC 7276, June 2014.

   [RINA]     John Day, Ibrahim Matta, and Karim Mattar., "Networking is
              IPC: a guiding principle to a better internet.", In
              Proceedings of the 2008 ACM CoNEXT Conference, p. 67. ACM,
              2008. , 2008.

              Nascimento, Marcelo R., Christian E. Rothenberg, Marcos R.
              Salvador, Carlos NA Correa, Sidney C. de Lucena, and
              Mauricio F. 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. ACM, 2011. ,

   [SDNACS]   Diego Kreutz, Fernando M. V. Ramos, Paulo Verissimo,
              Christian Esteve Rothenberg, Siamak Azodolmolky, Steve
              Uhlig, "Software-Defined Networking: A Comprehensive
              Survey.", arXiv preprint arXiv:1406.0440 , 2014.

              Feamster, Nick, Jennifer Rexford, and Ellen Zegura., "The
              Road to SDN", ACM Queue11, no. 12 (2013): 20. , 2013.

   [SDNNFV]   Haleplidis, Evangelos, Jamal Hadi Salim, Spyros Denazis,
              and Odysseas Koufopavlou., "Towards a Network Abstraction
              Model for SDN.", Journal of Network and Systems Management
              (2014): 1-19. Special Issue on Management of Software
              Defined Networks, Springer , 2014.

              Kloti, Rowan, Vasileios Kotronis, and Paul Smith.,
              "Openflow: A security analysis.", Proceedings Workshop on
              Secure Network Protocols (NPSec). IEEE (2013). , 2013,

              Sandra Scott-Hayward, Gemma O'Callaghan, and Sakir Sezer.,
              "SDN security: A survey.", In Future Networks and Services
              (SDN4FNS), 2013 IEEE SDN for, pp. 1-7. IEEE, 2013. , 2013.

              Diego Kreutz, Fernando Ramos, and Paulo 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. ACM, 2013. , 2013.

              Bruno Astuto A. Nunes, Marc Mendonca, Xuan-Nam Nguyen,
              Katia Obraczka, and Thierry 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.

   [SLTSDN]   Yosr Jarraya, Taous Madi, and Mourad Debbabi, "A Survey
              and a Layered Taxonomy of Software-Defined Networking", To
              be published in Communications Surveys and Tutorials, IEEE
              Issue: 99 , 2014.

              Lakshman, T. V., T. Nandagopal, R. Ramjee, K. Sabnani, and
              T. Woo., "The softrouter architecture.", In Proc. ACM
              SIGCOMM Workshop on Hot Topics in Networking. 2004. ,

   [Tempest]  Rooney, Sean, Jacobus E. van der Merwe, Simon A. Crosby,
              and Ian M. Leslie., "The Tempest: a framework for safe,
              resource assured, programmable networks.", Communications
              Magazine, IEEE 36, no. 10 (1998): 42-53 , 1998.

Authors' Addresses

Authors' Addresses

   Evangelos Haleplidis (editor)
   University of Patras
   Department of Electrical and Computer Engineering
   Patras  26500

   Email: ehalep@ece.upatras.gr

   Kostas Pentikousis (editor)
   EICT GmbH
   Torgauer Strasse 12-15
   10829 Berlin

   Email: k.pentikousis@eict.de

   Spyros Denazis
   University of Patras
   Department of Electrical and Computer Engineering
   Patras  26500

   Email: sdena@upatras.gr

   Jamal Hadi Salim
   Mojatatu Networks
   Suite 400, 303 Moodie Dr.
   Ottawa, Ontario  K2H 9R4

   Email: hadi@mojatatu.com

   David Meyer

   Email: dmm@1-4-5.net

   Odysseas Koufopavlou
   University of Patras
   Department of Electrical and Computer Engineering
   Patras  26500

   Email: odysseas@ece.upatras.gr