Downloaded 26 times
![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!](https://image.slidesharecdn.com/mknetworkprogrammability-03-150219001929-conversion-gate01/85/SDN-9-320.jpg)
![Declarative Programming
（宣言的プログラミング）とは
[長所]
• 並列処理への親和性
• 不測の事態への対処、頑健性
• 複雑性への対処、スケール性
• 再利用性、保守性
[制約]
• チューリング不完全
• ドメイン・スコープを制限する必要あり
• 細部まで明示的に規定することができない
“What”を合意
モデル
冪等性](https://image.slidesharecdn.com/mknetworkprogrammability-03-150219001929-conversion-gate01/85/SDN-10-320.jpg)
More Related Content
![[D20] 高速Software Switch/Router 開発から得られた高性能ソフトウェアルータ・スイッチ活用の知見 (July Tech Fest...](https://cdn.slidesharecdn.com/ss_thumbnails/jtf20182-180803022253-thumbnail.jpg?width=640&height=640&fit=bounds)
「宣言的プログラミング」と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
- 3. Agenda • Network領域におけるプログラミングパラダイム試論 • 宣言的プログラミング • SDNのひとつの形態 • Open Daylight -‐-‐ BGP-‐LS/PCEPとMD-‐SAL
- 4. Network Programmabilityとは何か • Neutron IE T F • NETCONF/YANG • I2RS • FORCES • + あらゆるネットワークプロトコル！ Network Engineerによる プログラミング、 オーケストレーション Network Device (Virtual, Physical) の プログラミング
- 5. Network領域における Programming Paradigmの傾向 (仮説) • ImperaYveよりもDeclara've (ImperaYve – 命令的、DeclaraYve – 宣言的) • ProcedureよりもModel driven (Procedure – 手続き型、Model driven – モデル駆動型) • WaterfallよりもAgile開発手法
- 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 広く緩い定義から狭く厳密な定義まであるらしい...。 ひとまず、あまり厳密性は気にしないでおく…。
- 7. Declarative Programming （宣言的プログラミング）とは http://karari.tumblr.com/post/61067682037/clojure 「1から10までの全ての整数を足す」 ImperaYveなコード var s = 0;! for(var n=1; n=10; n++)! {! s = s + n; ! }! console.log(s);! //55! DeclaraYveなコード (- (range 1 11)! (reduce +)! (println)! )! //55! Flowchart ! Model !! n = 10 ? • 足す • nを増加させる 1 ... 10 1から10という範囲の 整数の集合 総計
- 8. Declarative Programming （宣言的プログラミング）とは 参照透過性(ReferenYal Transparency)、冪等性(Idempotence)とは何か 参照透過性(ReferenYal Transparency) 文脈に依らず、式の値はその構成要素だけによって決まる。 同じ条件を与えると、必ず同じ値が返る。 （外部変数、とかを使ってはいけない。） 冪等性(Idempotence) ある操作を一度行っても複数回行っても結果が変わらないことを表す概念 （例えば、n++;は冪等でない。冪等性が保証できないと、Ymeout -‐ retry等 の場合に結果が変わってしまう） à ネットワークコンピューティング、並列処理には重要
- 9. Idempotence （冪等性） group{'sysadmin':! !ensure=present! }! # FirstPuppet 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!
- 10. Declarative Programming （宣言的プログラミング）とは [長所] • 並列処理への親和性 • 不測の事態への対処、頑健性 • 複雑性への対処、スケール性 • 再利用性、保守性 [制約] • チューリング不完全 • ドメイン・スコープを制限する必要あり • 細部まで明示的に規定することができない “What”を合意 モデル 冪等性
- 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 (*)不確実性を高める要因 • 地理的・論理的な距離 • スケーリング • 複数、多様なコンポーネント（物理・仮想） • 並列、分散、マルチエージェント型システム
- 17. (Appendix) コンピューティング領域における Programming Paradigm オブジェクト指向 Object Oriented 手続き型 Procedural 宣言的、函数型 DeclaraYve, FuncYonal 対立 ?! • 原理的に相容れないところがある • しかし用途が違えば要求も違うのであまり原理主義にならずに.. ImperaYve DeclaraYve
- 18. (Appendix) Cloud Management領域における Imperativevs 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
- 20. Agenda • Network領域におけるプログラミングパラダイム試論 • 宣言的プログラミング • SDNのひとつの形態 • Open Daylight -‐-‐ BGP-‐LS/PCEPとMD-‐SAL
- 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 - NetworkEngineerのための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/
- 24.
- 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
- 29. Model-Driven SAL • ApplicaYonはNorth Bound Interfaceによりモデルとその情報にアクセスする
- 30. Why Model? • Modelとは、システムの機能、構造、ふるまいの表現(*) (*) Architectural Board ORMSC, “Model Driven Architecture”, July 2001 • Modelのメリット • 宣言的 Howを指示ではなくWhatを合意 • 共通言語 多様で異なる{技術｜プラットフォーム｜組織} 間での共通性 • ポータビリティ、保守性 モデルからモデルへの変換 • 頑健性、スケール • 不確実性への対処
- 31. まとめ • Network領域におけるプログラミングパラダイム試論 • 宣言的プログラミング • SDNのひとつの形態 • Open Daylight -‐-‐ BGP-‐LS/PCEPとMD-‐SAL 複雑・多様・不確実性に対処するために • DeclaraYve Programming 宣言的プログラミング • Model Driven モデル駆動型
- 32.