「宣言的プログラミング」とSDNのひとつの形態

19 Feb. 2015 河野美也（Miya Kohno, [email protected]）

「宣言的プログラミング」と��

SDNのひとつの形態

ネットワークプログラマビリティ勉強会 #3 http://network-programmability.connpass.com/

自己紹介

•  河野美也（こうのみや）

•  元ソフトウェア開発者でした - Programming style議論が好きでした

•  その後はネットワークエンジニア - Protocol - Network Architecture

•  Official Blog - hEp://gblogs.cisco.com/jp/author/miyakohno/

•  TwiEer @mkohno

Agenda

•  Network領域におけるプログラミングパラダイム試論 • 宣言的プログラミング

•  SDNのひとつの形態 •  Open Daylight -‐-‐ BGP-‐LS/PCEPとMD-‐SAL

Network Programmabilityとは何か

•  Neutron

I E T F •  NETCONF/YANG •  I2RS •  FORCES •  + あらゆるネットワークプロトコル！

Network Engineerによるプログラミング、オーケストレーション

Network Device (Virtual, Physical) のプログラミング

Network領域における��Programming Paradigmの傾向 (仮説)

•  ImperaYveよりもDeclara've 　(ImperaYve – 命令的、DeclaraYve – 宣言的) •  ProcedureよりもModel driven 　(Procedure – 手続き型、Model driven – モデル駆動型)

•  WaterfallよりもAgile開発手法

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

広く緩い定義から狭く厳密な定義まであるらしい...。ひとまず、あまり厳密性は気にしないでおく…。

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という範囲の整数の集合

総計

Declarative Programming��（宣言的プログラミング）とは参照透過性(ReferenYal Transparency)、冪等性(Idempotence)とは何か

参照透過性(ReferenYal Transparency) 文脈に依らず、式の値はその構成要素だけによって決まる。同じ条件を与えると、必ず同じ値が返る。（外部変数、とかを使ってはいけない。）

冪等性(Idempotence) ある操作を一度行っても複数回行っても結果が変わらないことを表す概念（例えば、n++;は冪等でない。冪等性が保証できないと、Ymeout -‐> retry等の場合に結果が変わってしまう）

à ネットワークコンピューティング、並列処理には重要

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!


[長所] •  並列処理への親和性 •  不測の事態への対処、頑健性 •  複雑性への対処、スケール性 •  再利用性、保守性

[制約] •  チューリング不完全 •  ドメイン・スコープを制限する必要あり •  細部まで明示的に規定することができない

“What”を合意モデル冪等性

チューリング完全性について

•  「チューリング完全」とは -  アルゴリズムに還元できるものは全て記述できること -  多くのプログラム言語（C, Java, Perl, PHP, Python..)は　　チューリング完全である

•  DeclaraYve（宣言的）方法は、チューリング不完全 -  “how”を記述でなく、”what”を合意　　-‐-‐ アルゴリズムの万能性、柔軟性は放棄する -  用途をある程度制限することによりモデルを具現化　　e.g. SQL, HTML, JSON, YANG..


ImperaYve DeclaraYve

プログラミング言語

手続き型函数型 Domain Specific Language

Network Control

Openflow OVS DB NETCONF/RESTCONF Control Plane Protocols

OrchestraYon/AutomaYon

Workflow Model-‐driven

構成管理 Script

Puppet CFEngine

OVSDB

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

•  Model Driven SAL(Service AdaptaYon Layer)の追加 •  多種のSouthbound Protocol (BGP-‐LS, PCEP..) •  仮想・物理デバイスへの対応

(例) OpenDaylight Controller Architecture http://www.opendaylight.org/

DeclaraYve

ImperaYve

•  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

Imperative vs Declarative

•  チューリング完全性、きめ細かい制御が必要　à ImperaYve

•  不確実性の高い(*)環境　　　à DeclaraYve (*)不確実性を高める要因 •  地理的・論理的な距離 •  スケーリング •  複数、多様なコンポーネント（物理・仮想） •  並列、分散、マルチエージェント型システム

(Appendix) コンピューティング領域におけるProgramming Paradigm

オブジェクト指向 Object Oriented

手続き型 Procedural

宣言的、函数型 DeclaraYve, FuncYonal

対立 ?!

•  原理的に相容れないところがある •  しかし用途が違えば要求も違うのであまり原理主義にならずに..

ImperaYve

DeclaraYve

(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

(Appendix – さらに蛇足) 人間と機械の関係

ImperaYveなパラダイム •  プログラムを書く人間が全てを知っている

DeclaraYveなパラダイム •  Network centric compuYng -‐-‐ ネットワークを介して機械が機械をプログラムする

•  人間が予め全てを掌握している訳ではない -‐-‐ deep learning, agent-‐based system

Agenda



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

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に応じてパスを分ける

•  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/

BGP-LSによるトポロジーの学習 https://wiki.opendaylight.org/images/e/e3/Os2014-md-sal-tutorial.pdf

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>

(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との連携

-  Request (RPC)とNoYficaYonの受付け -  Modelデータのためのデータストレージ

Model Driven SAL http://www.opendaylight.org/

AD-‐SAL MD-‐SAL

•  ネットワークとその属性、ネットワーク機器をモデル化 •  Service/ApplicaYon(North Bound)とProctocol Plug-‐in(South Boundのマッピング

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 <[email protected]>"; 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

Model-Driven SAL •  ApplicaYonはNorth Bound Interfaceによりモデルとその情報にアクセスする

Why Model?

•  Modelとは、システムの機能、構造、ふるまいの表現(*) (*) Architectural Board ORMSC, “Model Driven Architecture”, July 2001

•  Modelのメリット •  宣言的　　Howを指示ではなくWhatを合意 •  共通言語　多様で異なる{技術｜プラットフォーム｜組織} 間での共通性

•  ポータビリティ、保守性　　モデルからモデルへの変換 •  頑健性、スケール •  不確実性への対処

まとめ



複雑・多様・不確実性に対処するために

•  DeclaraYve Programming 宣言的プログラミング

•  Model Driven モデル駆動型

Thank you !

Technology

「宣言的プログラミング」とSDNのひとつの形態