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 subsections.
この後の節で説明するように、上記のモデルは、すべての主要な 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 information.
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 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 モデルの要素を関し、設定、制御するために使うことができる。そのプロトコルは、単純なコマンド、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.
Figure 1 について、ForCES モデル [RFC5812] は、LFB を使うことで、オペレーショナルプレーンとフォワーディングプレーンの両方に対する、DAL に適している。ForCES プロトコル [RFC5810] は (MSPI のために利用することもできるが) CPSI のために設計されており、それに適している。
4.2. NETCONF/YANG
4.2. NETCONF/YANG 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 applications.
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 [Peregrine].
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 switches.
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 complete: 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 document. 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 document.
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,
<http://www.omg.org/spec/CORBA/3.3/>.
[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,
<http://www.itu.int/rec/T-REC-X.700-199209-I/en>.
[I-D.ietf-i2rs-architecture]
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.
[I-D.ietf-i2rs-problem-statement]
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.
[I-D.ietf-i2rs-rib-info-model]
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.
[I-D.ietf-pce-stateful-pce]
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/
studygroups/2013-2016/11/Pages/default.aspx>.
[ITUSG13] Telecommunication Standardization sector of ITU, "ITU,
Study group 13", 2013, <http://www.itu.int/en/ITU-T/
studygroups/2013-2016/13/Pages/default.aspx>.
[ITUSS7] Telecommunication Standardization sector of ITU, "ITU,
Q.700 : Introduction to CCITT Signalling System No. 7",
1993.
[ITUY3300]
ITU-T Study Group 13, "Y.3300, Framework of software-
defined networking", June 2014, <http://www.itu.int/ITU-
T/recommendations/rec.aspx?rec=12168>.
[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,
<http://www.etsi.org/deliver/etsi_gs/
NFV/001_099/003/01.01.01_60/gs_NFV003v010101p.pdf>.
[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. ,
2008.
[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.
[OF-CONFIG]
Open Networking Foundation, "OpenFlow Management and
Configuration Protocol 1.1.1", March 2013,
<https://www.opennetworking.org/images/stories/downloads/
sdn-resources/onf-specifications/openflow-config/of-
config-1-1-1.pdf>.
[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,
<https://www.opennetworking.org/images/stories/downloads/
sdn-resources/technical-reports/
TR_SDN_ARCH_1.0_06062014.pdf>.
[OpenFlow]
Open Networking Foundation, "The OpenFlow 1.4
Specification.", October 2013,
<https://www.opennetworking.org/images/stories/downloads/
sdn-resources/onf-specifications/openflow/openflow-spec-
v1.4.0.pdf>.
[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.
[PNSurvey99]
Campbell, Andrew T., et al, "A survey of programmable
networks", ACM SIGCOMM Computer Communication Review 29.2
(1999): 7-23 , September 1992.
[Peregrine]
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
2002.
[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
2002.
[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
2009.
[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.
[RouteFlow]
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. ,
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.
[SDNHistory]
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.
[SDNSecOF]
Kloti, Rowan, Vasileios Kotronis, and Paul Smith.,
"Openflow: A security analysis.", Proceedings Workshop on
Secure Network Protocols (NPSec). IEEE (2013). , 2013,
<http://www.csg.ethz.ch/people/vkotroni/openflow_sec>.
[SDNSecServ]
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.
[SDNSecurity]
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.
[SDNSurvey]
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.
[SoftRouter]
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. ,
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 Greece Email: ehalep@ece.upatras.gr Kostas Pentikousis (editor) EICT GmbH Torgauer Strasse 12-15 10829 Berlin Germany Email: k.pentikousis@eict.de Spyros Denazis University of Patras Department of Electrical and Computer Engineering Patras 26500 Greece Email: sdena@upatras.gr Jamal Hadi Salim Mojatatu Networks Suite 400, 303 Moodie Dr. Ottawa, Ontario K2H 9R4 Canada 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 Email: odysseas@ece.upatras.gr
