I-D"SDN Layers and Architecture Terminology"読んでみた(2)
3. SDN Layers and Architecture
3. SDN Layers and Architecture Figure 1 summarizes in the form of a detailed high-level schematic the SDN architecture abstractions. Note that in a particular implementation planes can be collocated with other planes or can be physically separated, as we discuss below.
Figure 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 calls 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 コールである。しかし、そうしたインタフェースは、ローカルのプロセス間通信(inter-process communication, 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. RINA [RINA] outlines a recursive network architecture based on IPC which 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 scope for 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 [RINA] はパターンと構造の繰り返しを利用した IPC に基づく再帰的なネットワークアーキテクチャの概要を説明している。本書は、新しいアーキテクチャの提案を行わない――我々は分類法を通じてこれまでの取り組みを簡単に文書化する。再帰は今回の作業の範囲外だが、Figure 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
3.1 Overview
3.1. Overview This document follows a network device centric approach: Control mostly refers to the device packet handling capability, while management typically refer to the overall device operation aspects.
本書はネットワーク機器中心のアプローチをとる: 制御は主に機器のパケット操作機能を参照するが、管理は通常、機器操作という局面全体を参照する。
We view a network device as a complex resource which 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 throughout this document that we make no distinction between "physical" and "virtual" resources or "hardware" and "software" realizations, 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 on 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 scope for 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:
SDN は、Figure 1 に図示されたような複数のプレーンにわたる。図の下の部分から始めて、上の部分まで移動していくことで、我々は以下のようにプレーンを識別する:
Forwarding Plane - Responsible for handling packets in the
datapath 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".
- Forwarding Plane
- フォワーディングプレーン。データパスの中で、コントロールプレーンから受け取る命令にしたがってパケット操作をすることを受け持つ。フォワーディングプレーンの動作は、パケットの転送・破棄・変更を含むが、これだけに限定されない。フォワーディングプレーンは通常、コントロールプレーンのサービスとアプリケーションの終端点となる。フォワーディングプレーンは分類器 (? classifiers) のようなリソースを含むことができる。フォワーディングプレーンは、"データプレーン" あるいは "データパス" とも呼ばれる。
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 to distinguish between different areas
of operations and therefore the operational plane should be
included as a "plane" in Figure 1. We have adopted this latter
view in this document.
- Operational Plane
- オペレーショナルプレーン。ネットワーク機器の運用上の状態管理(たとえば、どの機器がアクティブ/非アクティブか、有効になっているポート番号は何番か、各ポートの状態は何か、など)を受け持つ。オペレーショナルプレーンは、通常、マネジメントプレーンのサービスまたはアプリケーションの終端点となる。オペレーショナルプレーンは、ネットワーク機器リソース(たとえばポートやメモリなどの)と関連する。ここで注意しておくのは、IRTF SDNRG の一部の参加者は、オペレーショナルプレーンの定義について異なる意見を持っているということである。(異なる見解を持つ人は)オペレーショナルプレーンはそれ自体としては "プレーン" を構成せず、実際にはフォワーディングプレーン上の機能の集合である(と主張する)。しかし、ほかの人にとっては、"プレーン" は操作(operation)の異なる領域間で区別することができ、したがって、オペレーショナルプレーンは Figure 1 に "プレーン" として含まれるべきである。
Control Plane - Responsible for taking 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.
- Control Plane
- コントロールプレーン。ひとつ以上のネットワーク機器によって、パケットがどのように転送されるべきかを決定することを受け持ち、(パケットの転送を)実行するために、その決定をネットワーク機器へ投入する。コントロールプレーンは通常、ほとんどフォワーディングプレーンに焦点を当てる。機器のオペレーショナルプレーンに対してはそれよりも頻度が少ない。コントロールプレーンはオペレーショナルプレーンの情報(たとえば特定のポートまたは機能の現在の状態)に関心がある。コントロールプレーンの主要な仕事は、ネットワークトポロジあるいは外部のサービス要求に基づいて、フォワーディングプレーンに存在するフォワーディングテーブルの調整をすることである。
Management Plane - Responsible for monitoring, configuring and
maintaining network devices, e.g. taking 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.
- Management Plane
- マネジメントプレーン。ネットワーク機器の監視、構成変更、維持管理を受け持つ。たとえばネットワーク機器の状態にについて決定を行う。マネジメントプレーンは通常、主に機器のオペレーショナルプレーンに焦点を当て、フォワーディングプレーンについてはそれほど対象としない。マネジメントプレーンはフォワーディングプレーンを設定するために使われるが、それは、それほど頻繁にではなく、コントロールプレーンに対してよりも大規模なアプローチで行われる。たとえば、マネジメントプレーンは、フォワーディングルールのすべてまたは一部を一度にセットアップするだろう(そうした動作が慎重に行われることが期待されるとしても)。
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.
- Application Plane
- アプリケーションプレーン。ネットワークの振る舞いを定義するアプリケーションとサービスが属するプレーン。直接(または主に)フォワーディングプレーンの操作をサポートするアプリケーション(コントロールプレーン中のルーティングプロセスのような)は、アプリケーションプレーンの一部とは見なされない。アプリケーションはモジュール化され、分散された形で実装することができ、よってアプリケーションはしばしば Figure 1 にあるように複数のプレーンにまたがることができる、という点に注意すること。
[RFC7276] has defined the data, control and management plane 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] は、運用・管理・保守 (Operation, Administration, and Management: OAM) の観点からデータ、コントロール、マネジメントプレーンを定義している。本書は、SDN アーキテクチャのすべての側面を反映させるために、[RFC7276] で定義された用語を拡大することを試みている。
All planes mentioned above are connected via interfaces (as 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 co-located 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.
上記で言及されたすべてのプレーンは、インタフェースを通して接続されている(Figure 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 plane 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].
アプリケーション、すなわち、(ほかのアプリケーションへのアクセスを提供せずにサービスを消費する特定の計算を行う)ソフトウェアプログラムは、プレーンの中に直接実装する、あるいは複数のプレーンにまたがって実装することができる。たとえば、これは暗黙的に Figure 1 に示されているが、アプリケーションまたはサービスは、コントロールプレーンとマネジメントプレーンの両方にまたがることが可能であり、したがって Control Plane Soucebound Interface (CPSI) と Management Plane Soucebound Interface (MSPI) の両方を使うことができる。そうした例の一つは、[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 provide through NSAL services to other applications or services. Additional examples include virtual resources that are realized on top of a physical resources and hierarchical control plane controllers [KANDOO].
Figure 1 では明示的に示されていないが、サービス、アプリケーション、プレーン全体は、モデルに対してオーバーレイ処理(overlay semantics)を提供することで、再帰的な方法で配置することができる。たとえば、アプリケーションプレーン・サービスは、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.
本書の関心は、もちろん、異なるプレーンにあるエンティティ間の north/south 通信にあることに注意すること。しかしこれは、明らかに、任意のひとつのプレーン内部におけるエンティティ同士の通信を除外するものではない。
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.
ただし、注意しなければいけないのは、様々なプレーンの抽象化の観点を提示した Figure 1 の中には、実装に関する詳細が欠けていることである。過去の多くの実装が、コントロールプレーンの上にマネジメントプレーンを配置することを選択した。これは、コントロールプレーンはマネジメントプレーンに対するサービスとして動作する、と解釈することができる。
さらに、多くのネットワーク、特にインターネットルータやイーサネットスイッチでは、コントロールプレーンは通常ネットワーク機器と密結合している。全体としてみると、コントロールプレーンはネットワーク全体 (network-wide) に分散配置されている。一方、マネジメントプレーンは伝統的に集中化され、コントロールプレーンと機器の管理を受け持ってきた。しかし、SDN の原理を適用することで、こうした区別はもはや明確なものではなくなっている。
Additionally, this document considers four abstraction layers:
さらに、本書は4つの抽象化レイヤについて検討する:
The Device and resource Abstraction Layer (DAL) abstracts the
device's forwarding and operational plane resources to the control
and management plane. 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.Device and resource Abstraction Layer (DAL) はコントロールプレーンとマネジメントプレーンに対して、機器のフォワーディングプレーンとオペレーショナルプレーンのリソースを抽象化する。DAL の種類によっては、両方あるいはどちらかのプレーンを抽象化するだろうし、コントロールプレーンまたはマネジメントプレーンのいずれかに対して、機器の任意のプレーンを抽象化するかもしれない。
The Control Abstraction Layer (CAL) abstracts the CP southbound
interface and the DAL from the applications and services of the
control plane.Control Abstraction Layer (CAL) は、コントロールプレーンのアプリケーションとサービスから、CP サウスバウンドインタフェースと DAL を抽出する。
The Management Abstraction Layer (MAL) abstracts the MP southbound
interface and the DAL from the applications and services of the
management plane.Management Abstraction Layer (MAL) は、マネジメントプレーンのアプリケーションとサービスから、MP サウスバウンドインタフェースと DAL を抽出する。
The Network Services Abstraction Layer (NSAL) provides service
abstractions for use by applications and other services.Network Service Abstraction Layer (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 [ONFArch] are well aligned with this document.
これを書いている時点では、ほかの SDO*1 で SDN に関連する活動が始まっている。たとえば、ITU ではアーキテクチャについての活動 [ITUSG13] と、シグナリング要求およびプロトコルについての活動 [ITUSG11] が始まっているが、それぞれのスタディグループは ([ITUY3300] を除いて) まだドキュメントの発行には至っていない。[ITUY3300] および [ONFArch] で提示された観点は、本書と良く連携されている。
3.2. Network Devices
3.2. Network Devices 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) and 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, optical or microwave network elements.
ネットワーク機器は、パケットをポート上で受信し、ひとつ以上のネットワーク機能を実行するエンティティである。たとえば、ネットワーク機器は受信したパケットを転送したり、破棄したり、パケットヘッダ(またはペイロード)を書き換えてから転送したりできる。ネットワーク機器は複数のリソース(たとえばポート、CPU、メモリ、キューなど)を集合させたものである。リソースは、単純なものか、単一のリソースを複合させ、集約したものにできる。ネットワーク機器はそれ自体が複合的なリソースである。ネットワーク機器の例には、スイッチやルータがある。そのほかの例としては、ファイアウォール、ロードバランサ、ビデオトランスコーダ(動画変換)のように、IP レイヤ上で動作するもの、L2 スイッチや光/マイクロ波ネットワーク機器のように IP レイヤの下で動作するものなどが含まれる。
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 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].
フォワーディングプレーンとオペレーショナルプレーンは、ひとつ以上の抽象化モデルとして提示される、機器/リソース抽象化レイヤ (DAL) を介して公開される。フォワーディングプレーンの抽象化モデルの例としては、ForCES [RFC5812]、OpenFlow [OpenFlow]、YANG モデル [RFC6020]、SNMP MIBs [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] の操作(デバイス自身に対するトラフィックをコントロールプレーンに転送する代わりにオフロードする)などがある。
3.3. Control Plane
3.3. Control Plane 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.
コントロールプレーンは通常、分散され、主にフォワーディングプレーンの設定を、Control Plane Soucebound Interface (CPSI) と参照ポイントとしての DAL を使うことで受け持つ。
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 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].
コントロールプレーン・エンティティ間の通信 (口頭では "east-west" インタフェースとして参照される) は、通常、BGP [RFC4271] のようなゲートウェイプロトコル、または PCEP [RFC5440] のようなほかのプロトコルを介して実装される。これらの該当するプロトコルメッセージは、通常は対域内 (in-band) で交換され、その後の処理のために、フォワーディングプレーンによってコントロールプレーンへ転送される。このカテゴリには [RCP], [SoftRouter], [RouteFlow] が含まれる。
Control Plane functionalities usually include: o Topology discovery and maintenance o Packet route selection and instantiation o Path failover mechanisms
コントロールプレーンの機能は通常、以下を含む:
- トポロジディスカバリとメンテナンス
- パケットの経路選択とインスタンス化
- パスのフェイルオーバー機構
The CPSI is usually defined with the following characteristics:
o time-critical interface which requires low latency and sometimes
high bandwidth in order to perform many operations in short order
o oriented towards wire efficiency and device representation instead
of human readabilityCPSI は通常、以下の特徴で定義される:
- 大量の処理を迅速に処理するために、低遅延かつたまに広帯域であることを要求する最優先のインタフェース
- 人に対する可読性よりも帯域効率や機械可読性が指向される。
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 interprocess 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 は、プロトコルまたは同等のプロセス間通信を使って実装できる。もしコントロールプレーンとネットワーク機器が同居していないのであれば、そのときのインタフェースは確実にプロトコルになる。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 CPSIs.
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サービス(VPLS)、サービストンネル、トポロジサービスなどがある。
3.4. Management Plane
3.4. Management Plane 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.
マネジメントプレーンは通常、集中化され、Management Plane Southbound Interface (MPSI) と参照ポイントとしての DAL を使って、ネットワーク機器のオペレーショナルプレーンが相互にコミュニケーションすることによって、ネットワーク全体が確実に動作しているか確認することを目的にしている。
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: o Fault and Monitoring management o Configuration management
マネジメントプレーンの機能は、一般的に、ネットワーク全体に対するビューに基づいて開始され、伝統的に人間中心(human-centric)だった。しかし、最近のアルゴリズムはほとんどの人的介入を置き換えた。マネジメントプレーンの機能 [FCAPS] は一般に以下のものを含む:
- 障害と監視の管理
- 構成管理
In addition, management plane functionalities may also include entities such as orchestrators, Virtual Function Managers (VNF manager) and Virtualised Infrastructure Managers, as described in [NFVArch]. Such entities can use management interfaces to 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 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 scope for this document.
さらに、マネジメントプレーンの機能性は、たとえばオーケストレータや [NFVArch] で説明されているような Virtual Function Manager*2 (VNF manager) などのエンティティを含むことがある。オペレーショナルプレーンのリソースに対して、仮想的な機能のリソースを要求し提供するために、そうしたエンティティは管理インタフェースを使うことができる。同様に、(エンティティは)物理的な転送機能の上にある仮想的な転送機能のインスタンス化を指示することができる。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]) and, therefore, MPSI usually has the following
characteristics:
o It is oriented more towards usability, with optimal wire
performance being a secondary concern
o Messages tend to be less frequent than in the CPSIMPSI は一般的に、CPSI よりも([RFC3535]参照)人との相互作用に近い。したがって、MPSI は通常、以下の特徴を持つ:
- ユーザビリティを指向し、帯域性能の最適化などは二次的な関心事になる。
- メッセージは CPSI ほど高頻度にならない傾向がある。
As an example of usability versus performance, we refer to the consensus of the 2002 IAB Workshop [RFC3535], such as that the key requirement for a network management technology is ease of use and 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 require more processing capabilities to parse.
性能に対するユーザビリティの例として、2002年の IAB Workshop での合意、すなわち、ネットワーク管理技術の鍵となる要求は、性能ではなく使いやすさであるという点を参照する [RFC3535]。[RFC6632] に従って、テキストベースの設定ファイルは国際化文字を含むことができるようになっているべきである。人間が読める文字列は UTF-8 を使用すべきであり、プロトコルの要素は、解析するためにより多くの処理能力が必要な、大文字・小文字の区別をしない ASCII 文字にすべきである。
MPSI can range from a protocol, to an API or even interprocess 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], OVSDB [RFC7047] and SNMP [RFC3411].
MPSI はプロトコルからAPIあるいは同等のプロセス間通信の間に及ぶことができる。もしマネジメントプレーンがネットワーク機器に組み込まれていないのであれば、MPSI は確実にプロトコルとなる。MPSI の例として、ForCES [RFC5810], NETCONF [RFC6241], 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.
Management Abstraction Layer (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.
マネジメントプレーン・サービスは、マネジメントプレーン上のほかのサービスまたはアプリケーションに対して接続方法を提供する。
3.5. Control and Management Plane Discussion
3.5. Control and Management Plane Discussion 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 エコシステムにおいて範囲外として指定されていることを観察した。この節の残りの部分では、構造、機能、各インタフェースのニーズについて明確な理解を得るために、その二つのプレーンの違いを生じさせる特徴をまとめる。
3.5.1. Timescale A point has been raised regarding the reference timescales for the control and management planes. That is, how fast is the respective plane required to react, or 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, and 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.
3.5.1. Timescale
コントロールプレーンとマネジメントプレーンに対する時間的尺度(timescale)の基準に関してポイントが提起されている。すなわち、各プレーンが反応するために要求される速さはどの程度か、あるいは、機器のフォワーディングプレーンやオペレーショナルプレーンを操作するために必要な速さはどの程度か、という点について。一般的に、コントロールプレーンは "たびたび" アップデートを送信する必要がある。アップデートはおおよそミリ秒の範囲で変換され、広帯域・低遅延のリンクを必要とする。対照的にマネジメントプレーンは、一般的により長い時間範囲(time frames)、すなわち数分、数時間、数日の範囲で反応する。そのため、帯域の効率は、常に重大な関心事ではない。こうした事例のよい例は、機器の設定状態を変更することである。
3.5.2. Persistence Another distinction between the control and management planes relates to state persistence. A state is considered ephemeral if it has a very limited lifespan. 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 which may range from hours to days and months and is usually associated with the management plane. Persistent state is also usually associated with data store of the state.
3.5.2. Persistence
コントロールプレーンとマネジメントプレーン間のもうひとつの違いは、状態の持続性(persistence)と関係している。もし状態がごく限定された存続時間を持つのであれば、状態は一時的と見なせる。よい例は、通常コントロールプレーンに関連づけられている、ルーティングを決定することである。一方では、数時間・数日・月単位を超えるような存続時間を持つ持続性のある状態は、通常マネジメントプレーンと関連している。持続的な状態はまた、状態のデータストアとも関連している。
3.5.3. Locality 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 "locally centralizing" the controller tends to muddle the distinction of the control and management plane based on locality.
3.5.3. Locality
先に言及したように、伝統的にコントロールプレーンはネットワーク機器上で局所的に実行され、実際には分散される。一方、マネジメントプレーンは集中的な方法で、機器に対してリモートで実行される。しかし、SDN による集中化の登場で、または "局所的な集中化" により、コントローラは、コントロールプレーンとマネジメントプレーン間の局所性に基づく区別を混在させる傾向がある。
3.5.4. CAP Theorem Insights
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:
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 Availability, i.e. that the system always responds to a request
(although the response may not be consistent or correct)
o Partition tolerance, namely that the system continues to function
even when specific nodes or the communications network fail.3.5.4. CAP Theorem Insights
CAP定理は、分散コンピューティング・システムを、複数の計算機リソース(たとえば CPU、メモリ、ストレージ)から成るものと見なす。それは、通信網を介して接続されており、総合してタスクを実行する。定理(または推論)は、普遍的な価値のある、分散システムの3つの特徴を特定する:
- 一貫性(consistency)、システムは問い合わせに対して、どのノードが要求を受信したかにかかわらず、等しく応答する(または全く応答しない)こと。
- 可用性(availability)、すなわち、システムは常に要求に対して応答すること(応答が一貫していない、あるいは正しくないとしても)。
- 分断耐性(partition tolerance)、つまり、特定のノードまたは通信網が障害を起こしたとしても、システムは機能を継続すること。
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] は、分散システムはこれら3つの特徴のうち、任意の2つを同時に満たすことは可能だが、3つすべてを満たすことはできない、と予想した。この予想は後日 Gilbert と Lynch [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 が仮定する主要な抽象化のひとつは、すべてのネットワーク構成要素が、入ってくるパケットの中のフィールドを検査し、転送する方法を決定する、シンプルな計算タスクを実行する計算機リソースである、ということだ。ネットワークの入り口(ingress)から出口(egress)へパケットを転送するというタスクは、明らかに多数のパケット転送要素によって実行されるので、パケット転送機器のネットワークは分散された計算機システムとなる。よって、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 スイッチがコントローラのリストを持つように設定される); これは分断耐性を向上させるが、確実な一貫性を失うという犠牲を払う。Panda ら [CAPFN] は SDN に対して CAP 定理をどのように適用するかに関する最初の調査を提供している。
3.6. Network Services Abstraction Layer
3.6. Network Services Abstraction Layer 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 という用語がオーバーロードされていることに注意する。それはしばしば、システム設計からサービス指向アーキテクチャの範囲の、いくつかの文脈で使用される。したがって我々は、この語は Figure 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 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] インタフェース等を含むが、これに限定されるわけではない。サービスインタフェースの二つの主要なアプローチは、RESTful インタフェースと RPC インタフェースである。両方ともクライアント・サーバ型のアーキテクチャを採っており、メッセージをやりとりするために、それぞれ特徴が若干異なる XML または JSON を使う。
RESTful interfaces, designed according to the representational state
transfer design paradigm [REST], have the following characteristics:
o Resource identification - individual resources are identified
using a resource identifier, for example a URI.
o Manipulation of resources through representations - Resources are
represented in a format like JSON, XML or HTML.
o Self-descriptive messages - Each message has enough information to
describe how the message is to be processed.
o Hypermedia as the engine of application state - a client needs no
prior knowledge of how to interact with a server, not through a
fixed interface.RESTful インタフェースは、REpresentational State Transfer (REST) 設計パラダイム [REST] に準じて設計されており、以下のような特徴を持つ:
- リソース識別
- 個々のリソースは、(URIのような)リソース識別子によって識別される。
- 表現によるリソースの操作
- リソースは JSON, XML, HTML などの形式で表現される。
- 自己記述可能なメッセージ
- 各メッセージは、メッセージが処理される方法を記述するのに十分な情報を持つ。
- アプリケーション状態のエンジンとしてのハイパーメディア
- クライアントは、サーバと対話する方法の事前知識を必要とせず、固定されたインタフェースを介さない。
Remote procedure calls (RPC), e.g. [RFC5531], XML-RPC and the like,
have the following characteristics:
o Individual procedures are identified using an identifier
o A client needs to know the procedure name and the associated
parametersたとえば [RFC5531]、XML-RPC などのリモートプロシジャコール (RPC)は、以下の特徴を持つ:
- 個々のプロシジャは識別子を使うことで識別される。
- クライアントはプロシジャの名前と関連するパラメタを知る必要がある。
3.7. Application Plane
3.7. Application Plane 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.
アプリケーションの例は、ネットワークトポロジディスカバリ、ネットワークプロビジョニング、パス予約などがある。
