Más contenido relacionado La actualidad más candente (20) Similar a 「宣言的プログラミング」とSDNのひとつの形態 (20) 「宣言的プログラミング」とSDNのひとつの形態1. 19
Feb.
2015
河野 美也(Miya
Kohno,
miya.kohno@gmail.com)
「宣言的プログラミング」と
SDNのひとつの形態
ネットワークプログラマビリティ勉強会 #3
http://network-programmability.connpass.com/
2. 自己紹介
• 河野
美也(こうの
みや)
• 元ソフトウェア開発者でした
- Programming
style議論が好きでした
• その後はネットワークエンジニア
- Protocol
- Network
Architecture
• Official
Blog
- hEp://gblogs.cisco.com/jp/author/miyakohno/
• TwiEer
@mkohno
6. Declarative Programming
(宣言的プログラミング)とは
Wikipedia(英語版)によると、
「ImperaYveでないProgramming
Style
(キリッ)
」
その他の定義としては、
• A
program
that
describes
what
computaYon
should
be
performed
and
not
how
to
compute
it
方法(how)
ではなく、何(what)をすべきかを記述
• Any
programming
language
that
lacks
side
effects
(or
more
specifically,
is
referenYally
transparent)
副作用の無いこと(厳密には、参照透過であること)
• A
language
with
a
clear
correspondence
to
mathemaYcal
logic
数理と対応している言語のこと
http://en.wikipedia.org/wiki/Declarative_programming
広く緩い定義から狭く厳密な定義まであるらしい...。
ひとまず、あまり厳密性は気にしないでおく…。
9. Idempotence (冪等性)
group{'sysadmin':!
!ensure=present!
}!
# First Puppet Run!
notice: /Group[sysadmin]/ensure: created!
notice: Finished catalog run in 0.08 seconds!
!
# Second Puppet Run!
notice: Finished catalog run in 0.03 seconds!
Puppetの例
「存在する」という
望む状態を記述する
既に「存在する」ので
二度目は実行されない
同じことをShell
Script(ImperaYve)で書こうとすると、条件分岐が増える
if[`getentgroupsysadmin|awk-F:'{print$1}'`==]!
!then!
! !groupaddsysadmin!
fi!
11. チューリング完全性について
• 「チューリング完全」とは
- アルゴリズムに還元できるものは全て記述できること
- 多くのプログラム言語(C,
Java,
Perl,
PHP,
Python..)は
チューリング完全である
• DeclaraYve(宣言的)方法は、チューリング不完全
- “how”を記述でなく、”what”を合意
-‐-‐
アルゴリズムの万能性、柔軟性は放棄する
- 用途をある程度制限することによりモデルを具現化
e.g.
SQL,
HTML,
JSON,
YANG..
12. Declarative Programming
(宣言的プログラミング)とは
ImperaYve
DeclaraYve
プログラミン
グ言語
手続き型
函数型
Domain
Specific
Language
Network
Control
Openflow
OVS
DB
NETCONF/RESTCONF
Control
Plane
Protocols
OrchestraYon/
AutomaYon
Workflow
Model-‐driven
構成管理
Script
Puppet
CFEngine
OVSDB
13. Transport
Assurance
OrchestraYon
Control
Infrastructure
• Physical
• Virtual
virtual
physical
Service
ApplicaYon
Forwarding
Plane
(Distributed)
Control
Plane
(Centralized)
Control
Plane
Domain
OrchestraYon
Service
OrchestraYon
Service,
ApplicaYon
Network Programmabilityにおける階層性
様々な形態の
Programmability
14. • Model
Driven
SAL(Service
AdaptaYon
Layer)の追加
• 多種のSouthbound
Protocol
(BGP-‐LS,
PCEP..)
• 仮想・物理デバイスへの対応
(例) OpenDaylight Controller Architecture
http://www.opendaylight.org/
DeclaraYve
ImperaYve
15. • NFVO
(NFV
Service
Orchestrator)
• VNFM
(VNF
Manager)
• VIM
(Virtual
Infrastructure
Manager)
–
Openstack,
etc.
(例) ETSI NFV Orchestration Architecture
Imperative
BSS
EMS1
VirtualizaYon
Layer
VNFM
VIM
Virtual
CompuYng
Virtual
Storage
Virtual
Networ
k
NFVO
NFVI
NFV
Management
and
OrchestraYon
(Mano)
CompuYng
Hardware
Storage
Hardware
Network
Hardware
VNF1
VNF2
VNF3
Tail-‐f
NCS
EMS1
EMS1
OSS
SID
Workflow
Script
YANG
Model
VNF,
VNFM
Interface
DefiniYons
YANG
Model
Service
DefiniYons
Declarative
16. Imperative vs Declarative
• チューリング完全性、きめ細かい制御が必要
à
ImperaYve
• 不確実性の高い(*)環境
à
DeclaraYve
(*)不確実性を高める要因
• 地理的・論理的な距離
• スケーリング
• 複数、多様なコンポーネント(物理・仮想)
• 並列、分散、マルチエージェント型システム
18. (Appendix) Cloud Management領域における
Imperative vs Declarative議論
hEp://docs.oasis-‐open.org/tosca/TOSCA/v1.0/
cs01/TOSCA-‐v1.0-‐cs01.pdf
Proceedings
of
the
IEEE
InternaYonal
Conference
on
Cloud
Engineering
(IEEE
IC2E
2014)}
March
2014,
p87-‐96,
DOI
10.1109/IC2E.
2014.56
19. (Appendix – さらに蛇足) 人間と機械の関係
ImperaYveなパラダイム
• プログラムを書く人間が全てを知っている
DeclaraYveなパラダイム
• Network
centric
compuYng
-‐-‐
ネットワークを介して機械が機械をプログラムする
• 人間が予め全てを掌握している訳ではない
-‐-‐
deep
learning,
agent-‐based
system
21. Network Engineerにとってのネットワーク?!
Network
Engineers
Image
source
:
hEp://www.dreamsYme.com/royalty-‐free-‐stock-‐images-‐3d-‐white-‐people-‐system-‐administrator-‐image28585969,
hEp://www.sudarshansowech.com/chnt3.htm
node
link
• 自分のendpoint情報を表明
• あとはよしなにつながる
GW
• IP
addr/subnet
• vlan
• port
外部ネットワーク
内部ネットワーク
Security
Server
Engineers
• ネットワークはノードとリンク
から構成される
• トポロジー重要、帯域重要
• Cost,
Delay,
JiEer..
22. BGP−LSとPCEP - Network EngineerのためのSDN
R5
R6
R7
R3
R4
R1
R2
SDN
Controller
Programming
CollecIon
NB
interface
PCEP
BGP-‐LS,
etc
CongesYon!
TE
path
(Traffic
Engineering
Path)の
パス計算、設定
Topology、帯域、
使用率などの収集
• 自律分散性は維持
• SLAを満たすパスをつくる
• 要求されるQoSに応じて
パスを分ける
23. • TCP
MD5
Signature
OpYon
(rfc2385)は分離され、別プロジェクトになった
-‐
BGP,
PCEPともにover
TCPで動作する
• SDNi(SDN
interface)とは、SDN
Controller間の連携(例えば、複数のコントーラに
跨がるBandwidth
On
Demandなど)を実現するインタフェース
-‐
BGPの実装を必要とする
OpenDaylightにおけるBGP-LS, PCEPの実装
http://www.opendaylight.org/
25. PCEPによるPath(Tunnel)設定
https://wiki.opendaylight.org/view/BGP_LS_PCEP:Programmer_Guide
R5
R6
R7
R3
R4
R1
R2
SDN
Controller
Programming
CollecIon
NB
interface
PCEP
BGP-‐LS,
etc
• draw-‐iex-‐pce-‐stateful-‐pce-‐02
and
draw-‐crabbe-‐iniYated-‐00
• draw-‐iex-‐pce-‐stateful-‐pce-‐07,
draw-‐iex-‐pce-‐pce-‐iniYated-‐lsp-‐00
• draw-‐sivabalan-‐pce-‐segment-‐rouYng-‐02
Create
node,
name,
arguments,
endpoints-‐obj,
ero,
lsp
Update
node,
name,
arguments,
operaYonal,
ero,
lsp
Remove
node,
name
26. (Appendix: Segment Routing)
Controller
DC
Cross
Domain
OrchestraYon
IPv4/IPv6
MPLS
Network
DC
Controller
Segment
RouIng
One
Collector
APIs
MPLS
Segment
RouIng
Control
Plane
転送情報配布
LDPやRSVPによ
りLabelを配布
IGPにより
Segment
IDを配布
Traffic
Engineering
RSVP
TE
signaling
を使用
ヘッダスタックを
使用
ProtecIon
RSVP
TE
FRR
IP
FRR(LFA)も可能
だがトポロジー
制約があった。
Topology-‐
Independent
FRR
• RSVP,LDPは不要
• NWにおけるステート(RSVP
state)の排除
• ApplicaYon,
OrchestraYonとの連携
27. - Request
(RPC)とNoYficaYonの受付け
- Modelデータのためのデータストレージ
Model Driven SAL
http://www.opendaylight.org/
AD-‐SAL
MD-‐SAL
• ネットワークとその属性、ネットワーク機器をモデル化
• Service/ApplicaYon(North
Bound)とProctocol
Plug-‐in(South
Boundのマッピング
28. Model-Driven SAL
28
module
topology-‐tunnel-‐pcep-‐programming
{
yang-‐version
1;
namespace
urn:opendaylight:params:xml:ns:yang:topology:tunnel:pcep:programming;
prefix
ttpp;
import
pcep-‐types
{
prefix
pcep;
revision-‐date
2013-‐10-‐05;
}
import
topology-‐tunnel-‐programming
{
prefix
ttp;
revision-‐date
2013-‐09-‐30;
}
import
topology-‐tunnel-‐p2p
{
prefix
p2p;
revision-‐date
2013-‐08-‐19;
}
import
topology-‐tunnel-‐pcep
{
prefix
ptp;
revision-‐date
2013-‐08-‐20;
}
organization
Cisco
Systems,
Inc.;
contact
Robert
Varga
rovarga@cisco.com;
description
This
module
contains
the
programming
extensions
for
tunnel
topologies.
Copyright
(c)2013
Cisco
Systems,
Inc.
All
rights
reserved.
This
program
and
the
accompanying
materials
are
made
available
under
the
terms
of
the
Eclipse
Public
License
v1.0
which
accompanies
this
distribution,
and
is
available
at
http://www.eclipse.org/legal/epl-‐v10.html;
rpc
pcep-‐create-‐p2p-‐tunnel
{
input
{
uses
ttp:create-‐p2p-‐tunnel-‐input;
uses
p2p:tunnel-‐p2p-‐path-‐cfg-‐attributes;
uses
ptp:tunnel-‐pcep-‐link-‐cfg-‐attributes;
}
output
{
uses
ttp:create-‐p2p-‐tunnel-‐output;
}
}
rpc
pcep-‐destroy-‐tunnel
{
input
{
uses
ttp:destroy-‐tunnel-‐input;
}
output
{
uses
ttp:destroy-‐tunnel-‐output;
}
}
rpc
pcep-‐update-‐tunnel
{
input
{
uses
ttp:base-‐tunnel-‐input;
uses
p2p:tunnel-‐p2p-‐path-‐cfg-‐attributes;
uses
ptp:tunnel-‐pcep-‐link-‐cfg-‐attributes;
}
output
{
uses
ttp:base-‐tunnel-‐output;
}
}!
}!
Yang
Tools
Plugin
Plugin
Model
topology-tunnel-pcep-programming.yang
APIs
30. Why Model?
• Modelとは、システムの機能、構造、ふるまいの表現(*)
(*)
Architectural
Board
ORMSC,
“Model
Driven
Architecture”,
July
2001
• Modelのメリット
• 宣言的
Howを指示ではなくWhatを合意
• 共通言語
多様で異なる{技術|プラットフォーム|組織}
間での共通性
• ポータビリティ、保守性
モデルからモデルへの変換
• 頑健性、スケール
• 不確実性への対処