20161110 cmlee opnfv_colorado1.0_분석

1

OPNFV Colorado 1.0 분석

2016. 11. 10㈜파이오링크SDN개발실 이철민([email protected])

© PIOLINK, Inc. Optimizing Your Cloud Data Center.

Contents

About OPNFV

– External view of OPNFV

– Internal view of OPNFV

Colorado Overview

– Architecture

– Key enhancements of OPNFV Colorado

– Deployment Tools

Colorado Release Documentation

– Platform Documentation

– Feature Project Documentation

– Test Project Documentation

Colorado Approved Project

– Requirements Project

2

© PIOLINK, Inc. Optimizing Your Cloud Data Center. 3

About OPNFV


About OPNFV

4

External view of OPNFV : OPNFV?

– Open Platform for NFV(Network Function Virtualization)

– 통신 사업자 주도로 LINUX FOUNDATION이 2014년 9월 30일 SAN FRANCISCO에서 OPNFV Project 설립을 발표

• NFV 생태계 구축 및 확산을 위한 Project

• Linux Foundation Collaborative Project

– 새로운 NFV 제품 및 서비스 도입을 가속화 하기 위한 캐리어급 통합 오픈 소스 플랫폼

• Carrier-Grade

• Integrated

• Open Source Platform


About OPNFV

5

External view of OPNFV : Goals– NFV 기반의 새로운 제품과 서비스 도입을 촉진하기 위해 통합 및 검증 된 Open Source Platform 개발

– OPNFV 기술이 업계의 요구사항을 충족하는지 검증할 Community참여유도

– OPNFV Platform에활용될 수 있는 관련 Open Source Project에기여 및 참여

• Open Source Component들간의 일관성(Consistency), 성능(Performance), 상호 운용성(Interoperability)을보장

– 개방형 표준 및 오픈 소스 소프트웨어(Open Standards and Software)에기반하여 NFV 솔루션을 위한 생태계 조성

– Open Source NFV를 위한 Platform과 Community로써 확산 촉진


About OPNFV

6

External view of OPNFV : Members

– OPNFV Member는주로 전세계 주요 통신사와 통신장비 제조사 들로 구성되어 있는 것이 특징


About OPNFV

7

External view of OPNFV : Releases

– Arno(이탈리아서부의 강), Brahmaputra(티벳남서부에서 인도 북동부로 흐르는 강), Colorado(미국 남서부를흐르는 강) Release(첫글자로 Release 순서 파악 Arno, Brahmaputra, Colorado)

– Upstream 형태의 작업을 수행 하는 데서 River(강)으로 표현

– Next Releases Danube(독일 남서부에서 흑해로 흐르는 강)

Release Version Release Date Install Tools

Colorado 1.0 Mon, 09/26/2016 • Apex• Compass• Fuel• JuJu

Brahmaputra 3.0 Fri, 04/29/2016 • Apex• Compass• Fuel• JuJu

Brahmaputra 2.0 Thu, 04/21/2016 • Apex• Compass• Fuel• JuJu

Brahmaputra 1.0 Tue, 03/01/2016 • Apex• Compass• Fuel• JuJu

Arno SR1 Thu, 10/01/2015 • Foreman• Fuel

Arno 1.0 Thu, 06/04/2015 • Foreman• Fuel


About OPNFV

8

Internal view of OPNFV : Scope(ETSI 표준)

– asdfsdf

– 초기 OPNFV 프로젝트에서는 기존에 존재하는 Open Source Project들을 OPNFV의 Upstream Project로통합하여 NFV Infrastructure(NFVI)와 Virtualized Infrastructure Manager(VIM) 구현을 목표로 함

• Upstream Project는 OPNFV의 각 구성요소가 되는 (OpenStack, OVS, OpenDaylight, KVM, 등등)

– NFVI, VIM의 API(Application Programmable Interface)를제공하여 다른 NFV Elements(e.g. VNF Manager,

VNFs, Orchestrator)와연동이 가능하도록 함

– 이번 Colorado부터 OPNFV Scope에 MANO(Management and Orchestration)가포함

OPNFV

Colorado

Scope


About OPNFV

9

Internal view of OPNFV : Architecture

– OPNFV Project는 Common H/W Requirements, S/W Architecture, MANO 및 Application을포함하여 일관된 가상화 Platform의개발

– 효과적인 개발을 위해 다음과 같은 기본 Building Blocks으로구분

• H/W : Pharos Project와관련된 Infra working group

• S/W Platform : Platform 통합 및 Deployment Projects

• MANO : MANO working group과관계된 Project

• Applications : OPNFV에 대한 요구 사항을 다루며 모든 다른 영역에 영향

Orchestration and Management


About OPNFV

10

Internal view of OPNFV : Architecture - Software– Virtual Infrastructure Management(VIM)

• OpenStack은 Cloud 관리 시스템 및 관련 기술의 완전한 레퍼런스를 제공

– Operating System

• 모든 Target machines은 Linux를사용

• Linux의 Ubuntu, Centos, SUSE linux를지원

– Networking Technologies

• SDN Controllers

– Neutron : OpenStack의 network connectivity as a service를 담당. OpenStack 다른 service(e.g. Nova 등)

의 interface devices(vNICs)를관리

– OpenDaylight : SDN 플랫폼을 구축. 향후 네트워크에 대한 기반을 제공

– ONOS : 고 가용성, 성능, scale-out을위해 설계된 캐리어 급 SDN 네트워크 운영 체제

– Data Plane

• Linux virtual networking 성능 향상을 위한 open source

– FD.io(Fast Data – Input/Output) : Cisco의 Vector Packet Processing(VPP)기술과인텔의 DPDK(Data

Plane Development Kit)기술을 결합한 최신 Packet 처리 Open Source Project

– Open vSwitch : 프로그래밍 방식의 확장을 통해 대규모 네트워크 자동화가 가능하고, 표준 관리 인터페이스 및 프로토콜을 지원하는 virtual switch


About OPNFV

11

Internal view of OPNFV : Related Community– Open Source Project Relevant to OPNFV(Colorado 1.0 기준)

Project Cadence OPNFV Version Release Current Project Version

OpenStack 6 months Mitaka 2016-04-07 Newton

OpenDaylight ~ 6 months Beryllium 2016-05-11 Boron

Open vSwitch 4~6 months 2.5.90 2016-09 2.6.0

ONOS 3 months Goldeneye(1.6.0) 2016-05-30 Hummingbird(1.7.0)

OpenContrail 3.0 2016-03 3.0.1

DPDK 4 months 16.04 2016-07 16.07

Libvirt Monthly 1.3.2 2016-09-14 2.3.0

QEMU/KVM 4–5 months 2.6 2016-05-11 2.7.0

Linux 2-3 months 4.4.6 2016-03-16 4.7


About OPNFV

12

Internal view of OPNFV : Approved Project [1]– OPNFV Development

• OPNFV Project의 Software로포함 가능한 기존 Open Source Project를식별

• OPNFV 기술위원회의 기술 검토를 거쳐 선정

• NFV 플랫폼으로써 제공되어야 할 기능 및 성능과 선정된 Project간 gap 분석

• Project 기능 개선 및 수정과 요구사항 도출

• Open Source Project Group에전달 또는 직접 소스코드 개발

– OPNFV Project Category

• 요구사항(Requirements) Project

– NFV Reference Platform 개발을 위해 필요한 요구사항에 대해 수집 및 문서화를 위한 Project

– 정의된 요구사항은 OPNFV Community나 Upstream Project에서구현

– NFV를 위해 새롭게 필요하거나 기존 기능에 수정이 필요한 Project가포함

• 통합 및 검증(Integration & Testing) Project

– NFV Reference Platform 구축에 사용되는 다양한 Open Source Project (e.g. OpenStack, OpenDaylight)

의 통합 및 검증 수행을 위한 Project

• 협력 개발(Collaborative Development) Project

– NFV Reference Platform 개발을 위해 다른 Open Source Project 그룹 및 표준화 단체 등과 협력 개발을위한 Project

• 문서화(Documentation) Project

– OPNFV 와 관련된 문서화 및 문서 작성 도구 개발을 위한 프로젝트


About OPNFV

13

Internal view of OPNFV : Approved Project [2] (Colorado 1.0 기준)– Feature project : Requirements 20개, Integration & Testing 22개, Collaborative Development 9개, Documentation 1

개, 총 52 Project

– Colorado1.0 기준 변경 Project : Requirements 6개, Integration & Testing 10개, Collaborative Development 6개, 총22 Project


About OPNFV

14

Internal view of OPNFV : Project Lifecycle [1]– OPNFV의 각 Project는독립적이며 다음의 Lifecycle을따른다.

– Lifecycle의속도는 각 Project 마다 다르다.

– Proposal

• 아직 실제 존재하지 않는 Project를필요에 의해 기술위원회에 공식 제안 단계

• OPNFV Project 제안 요건에 따라 작성된 제안서는 기술위원회의 생성 검토(Creation Review) 회의를 통해승인 여부를 결정

– Incubation

• 승인이 결정되면 Resource가투입되어 Project가진행되는 초기 단계

• 기술위원회에서 정의한 Project범주별 지표에 맞는 결과물을 입증, 배포한 이력과 해당 Project Community

가 활동 중이면 기술위원회 검토(Graduation Review)를 거쳐 Mature(성숙)단계로 이전

– Mature

• 성공적으로 결과물을 배포하고 있는 단계

• 프로젝트 통합 검토(Integration Review)를 거쳐 통합(Integration)단계로발전

– Integration

• Project 결과물이 OPNFV 참조 플랫폼을 구성하는 요소로서 인정된 단계


About OPNFV

15

Internal view of OPNFV : Project Lifecycle [2]

– Archived

• Project가예정된 목표를 완수했거나 실패하는 등 다양한 이유로 인해 더 이상 유지될 필요가 없어 종료 또는 폐기되는 단계

• Project가어떤 상태 에서든 기술위원회의 종료 검토(Termination Review)를통해 결정


Colorado Overview


Colorado Overview

17

Architecture

– Colorado는 Security, IPv6, SFC, VPN capabilities, multiple H/W Architectures(e.g. ARM) support에대해서 중요한 개선사항을 포함

– Testing & CI/CD 개발 운영 프로세스 지원

– 기능 별 Component 구성

Orchestration and Management


Colorado Overview

18

Key enhancements of OPNFV Colorado [1]– Core feature enhancements

• Security : OPNFV Colorado에서는 Open Source의 best practices를위해 CII의 Best Practices Badges를획득하여 Security framework를향상

– CII(Core Infrastructure Initiative)는 2016년 5월, LINUX FOUNDATION이 Open Source의성능과 안정성을 검증하기 위해 발족한 Project

– Best Practices Badges (획득)제도를 통해 인증

• SFC(Service Function Chaining) : VNFM 설치를 위한 몇몇 installer에포함됨

– Continues Development

– Multi-node use

• IPv6 : 개선 된 IPv6를 지원. 모든 underlay와 overlay를 지원 및 통합.

• VPN : SDN VPN Project는 Quagga BGP router와의통합을 통해 BGP-base peering 지원을 포함하여, 현재모든 Layer2 및 Layer3 VPN을지원

– BGP Peering : BGP router간의 routing 정보를 교환하기 위한 절차

• ARM(Hardware Architecture) : OPNFV는 이제 완전히 x86 및 ARM을 포함하여 다양한 HW platforms을지원, OPNFV의 automated testing 및 개발 운영 Infrastructure와통합


Colorado Overview

19

Key enhancements of OPNFV Colorado [2]– Enhanced testing capabilities

• Colorado는가능한 test scenario를 24개에서 42개로증가하여 testing capabilities를확장

• Automated test workflow를 통해 더 효율적인 자원의 활용, Yardstick과 VSPERF Project의통합, security,

VPN, IPv6 및 그 밖의 features test cases 추가

– Infrastructure and testing environment advancements

• Pharos specification와 Community Labs에대한 유효성 검사 도구가 포함

– Pharos test lab Project : Community(회원사)에분산된 Test Labs을연합 구축하는 Project

– Community labs : https://wiki.opnfv.org/display/pharos/Community+Labs

• Labs participating in Colorado : https://wiki.opnfv.org/display/INF/Scenario+Infrastructure

– Community process enhancements

• Community는 Colorado에서 Infrastructure, MANO, Testing, Security에 중점

• 5명의 Committer-At-Large members를추가하여 Project 관리 위주 성격을 높임

• Key Upstream Communities : OpenStack, OpenDaylight, ONOS, OpenContrail, FD.io, OVS, Open-O,

Ceph, DPDK, ODP, OpenBaton, KVM, Linux kernel

• OPNFV internship-program은 Pharos 개선, VNF on-boarding, CINDR 성능 test를 포함하여 Colorado에가치 있는 기여를 제공

https://wiki.opnfv.org/display/pharos/Community+Labs

https://wiki.opnfv.org/display/INF/Scenario+Infrastructure


Colorado Overview

20

Deployment Tools– Apex is an OPNFV Installation tool based on RDO Manager that deploys OPNFV using the RDO Project

OpenStack Distribution. RDO manager is a Triple-O based installation tool. Triple-O is an image based life cycle

deployment tool that is a member of the OpenStack Big Tent Governance. Apex uses Centos on all target

platforms and can deploy all SDN controllers

– Compass is an installer project based on open source project Compass, which provides automated deployment

and management of OpenStack and other distributed systems. It can be considered as what the LiveCD to a

single box for a pool of servers – bootstrapping the server pool. Compass is based on Ansible. It can deploy

Ubuntu or Centos as target operating system and ODL and ONOS as SDN controllers

– Fuel is an installer project based on the Fuel OpenStack open source project providing automated deployment

and management of OpenStack and other distributed systems. Fuel is based on puppet and deploys the Ubuntu

Linux operating system; the OpenStack virtual Infra-structure manager, and OpenDaylight or ONOS SDN

controllers

– Joid is an installer utilizes the technology developed in Juju and MAAS. Juju allows you to deploy, configure,

manage, maintain, and scale cloud services quickly and efficiently on public clouds, as well as on physical

servers, OpenStack, and containers. Together with MAAS hardware usage can be optimized



22

Platform Documentation(+Installation Instruction)– OPNFV Platform의개요 문서, OPNFV설치 지침, 사용자 가이드를 제공

– OPNFV 설치 지침은 다음 4개의 Installation의지침서와 release notes을포함

• Apex

• Compass

• Fuel

• Joid

– Apex, Compass, Fuel, JOID를 통한 설치 사항은 본 문서에서 다루지 않음

Feature Project Documentation– Colorado Release에서변경 사항이 있는 Feature들에대한 Documentation

Test Project Documentation– Testing Project(Bottlenecks, Functest, vSwitchPerf, Yardstick) 수행 결과 Documentation



23

Feature Project Documentation [1]– ARMband project

• AArch64(ARM Architecture 64bit)를 target으로 deployment tool Fuel을사용하여 OPNFV Colorado 1.0 release

• AArch64 infrastructure에 OPNFV를 구축하여 AArch64 infrastructure의개발을 가속화하는 것이 목표

• 현재 x86_64와AArch64 architecture의 mixing이 가능하지 않지만 추후 지원 예정

• AArch64 설치 시 구성요소

– OpenDaylight(Beryllium SR3)

– Open vSwitch for NFV : version 선택

– BGPVPN

• AArch64 미 지원 plugins

– ONOS

– Service Function Chaining

– SDN distributed routing and VPN

– NFV Hypervisors-KVM

– VSPERF

• 제한 사항

– 최대 blades : 1 Fuel master, 3 Controllers, 20 Compute blades

– 최소 blades : 1 Fuel master, 1 Controllers, 1 Compute blades

– Storage : 오직 Cphe storage 설정만 가능

– Max number of networks : 65k

– Fuel master arch : x86_64

– Target node arch : aarch64



24

Feature Project Documentation [2]– Copper release documentation

• Colorado Approved Project – Copper 참조

– Doctor features and capabilities

• Colorado Approved Project – Doctor 참조

– Domino features and capabilities

• Colorado Approved Project – Domino 참조

– FastDataStacks feature and scenario documentation

• NFV 및 가상화된 고성능 애플리케이션이나 비디오 processing을위해 캐리어급의 성능, 확장성을 제공하는 “fast data stack”솔루션

• 어플리케이션의 정책을 실현하고 복잡한 네트워크 토폴로지를 제어하는 기능 제공

• NFV Infrastructure의필수 구성 조건

– The virtual forwarder

– Forwarder diversity

– Policy driven connectivity

• 구현을 위한 Component

– OpenStack – OpenDaylight Controller

– FD.io – Vector Packet Processor

– IPv6 platform support and capability

• IPv6 전용 Infrastructure에 OPNFV Colorado를설치하는 절차 및 IPv6 vRouter 사용 및 설정 가이드

• OPNFV Colorado Release를사용하여 service VM을 IPv6 vRouter로설정하는 가이드



25

Feature Project Documentation [3]– KVM for NFV

• KVMFORNFV Project는 Fuel에서만지원

• 커널, QEMU, Fuel등 version update

• VNF data plane의 Minimal Interrupt latency variation 등을 위한 문서 갱신

– MOON security management for NFV

• OPNFV Infrastructure에 security management framework를제공

• 다음과 같은 S/W modules을포함

– Keystone-moon

– Keystonemiddleware-moon

– Moonclient

– Odl-aaa-moon

– Tests

• Moon 설치 OPNFV Project : Compass4NFV

• Moon Test Project : Functest, Yardstic

• OPNFV에서 최초의 Moon Release 및 version

– Multisite datacenter project

• 복수 지역에 분산 구축된 VIM에 대한 관리 Project인 multisite의요구 사항, 설치, 구성 및 사용에 대한 설명서

• Colorado Approved Project – Multisite 참조

– Network readiness project(NetReady)

• NFV networking use cases를통해 NFVI에 대한 기본적인 요구 사항 확인

• Colorado Approved Project – NetReady 참조



26

Feature Project Documentation [4]– ONOS framework project

• NFVI와 VIM 프레임 워크의 통합 SDN Controller로 ONOS를 선택했을 경우 Use case와 Goldeneye 기능 명세

• Brahmaputra release 기능과 ONOS Goldeneyes의기능을 포함하여 SFC 시나리오를 통합 및 추가

– OVSNFV release documentation

• OVS는 OPNFV 구축에 사용되는 virtual switch

• DPDK 16.07을활성화하여 OVS를 설치하는 시나리오 및 설치 가이드

• Fuel & Apex 설치 지원

– Parser project

• 통신사업자가 네트워크 기능을 환경에 맞게 배포할 때, 사용하는 템플릿 양식을 TOSCA(Topology and

Orchestration Specification for Cloud) / CAMP(Cloud Application Management for Platforms) 형태로 변환해주는 Project

• policy2tosca

– tosca의 Policy2Tosca Module이정책 관련 field를 heat orchestration 템플릿으로 변환

– Policy2Tosca Module은 OPNFV Colorado 설치 후 별도로 설치 가능

• Tosca2heat

– Tosca2heat의기능 개선

• OPNFV Colorado 플랫폼에 통합된 OpenStack tosca-parser 모듈을 이용하여 추가 시험 지원



27

Feature Project Documentation [5]– Pharos

• 지리적, 기술적으로 다양한 OPNFV lab infrastructure를통해 매우 강력하고 안정적인 OPNFV platform 개발을 도움

• Lab의 capabilities를정의하고, 개발의 관리/사용 및 process를책임

• ARM architecture 지원 기능 추가

• Pharos Project 설명서/wiki page 갱신

• Colorado Release에대한 POD & Lab 템플릿 검토 및 업데이트

– Promise

• Promise 설치, 설정 방법과 요구사항 및 User guide 문서.(related MANO)

• Colorado Approved Project – Promise 참조

– SDNVPN

• BGP/MPLS based VPN을생성 및 연결할 수 있도록 OpenStack Neutron BGPVPN API를 확장

• SDN VPN은항상 ODL을통해 지원(ODL 필수)

• ODL version : Beryllium SR3

• SDNVPN은 OpenStack Neutron BGPVPN API 확장을 통해 OpenStack기반으로 BGP/MPLS를생성하고연결하는 기능 추가

– SFC

• OpenDaylight SFC Project를 OPNFV 환경(Fuel or Apex Installers)으로통합

• 후속 Release에서다른 Installers가고려됨.

– Software fast-path Quality Metrics

• VNF가 NFVI를 통해 Low latency, high performance packet processing path를지원 할 수 있는 utilities와libraries 개발



28

Test Project Release Documentation– Bottlenecks documentation

• 테스트 및 검증을 통해 OPNFV Infrastructure의 Bottleneck을확인하는 Project

• 문서 (user guide, installation Procedure, Release Notes, Platform Overview, Configuration Guide) 제공,

OPNFV community labs를위한 Jenkins 채용, framework, test case 확인

– Functest documentation

• OPNFV solution의내부 기능 테스트

• Test case와다른 upstream communities 및 OPNFV project의 test case도포함

• Internal test cases

– Healthcheck, vPing ssh, vPing userdata, Tempest Smoke Serial, Rally Sanity, ODL, Tempest full parallel,

Rally full, vIMS

• 자동화를 위한 Functest framework의 OPNFV project

– Bgpvpn, Copper, Doctor, Domino, Moon, Multisite, ONOSFW, ONOS-sfc, ODL-sfc, Parser, Promise,

Security scan

– vSwitchPerf documentation(VSPERF)

• NFV 환경에서 다양한 Virtual Switch 성능을 시험하고 검증하는 Framework 개발 프로젝트

• Upgrade된 version(OVS2.5, DPDK v16.07 등) 지원 등 기능 Update

– Yardstick documentation

• OPNFV의 Infra 검증을 위한 Project

• OPNFV platform(Compute, Network, Storage) testing, Test cases(HA, KPv6, KVM, Parser, StorPerf, VSperf,

virtual Traffic Classifier)검증


Colorado Project


Colorado Project - Requirements Project

30

Doctor(Fault Management & Maintenance) [1]– Overview

• NFVI의 결함 관리 및 유지 보수를 위한 Framework 수립을 위해 개발된 Project

– Goals

• 가상화 된 인프라(Virtualized Infrastructure) 상에서 운영되는 네트워크 서비스의 HA(High Availability)를보장하고 관리체계 구축을 위한 Framework를제공

– Features

• Immediate Notification

– Ceilometer & Aodh으로활성화된 가상 자원의 상태가 업데이트되면 VNFM에게 즉시 알림

– Ceilometer & Aodh 통합

• 일관성 있는 상태 인지 향상

– Nova API를통해 nova-compute-service down

– Nova API를통해 VM 정보를 가져 옴

• OpenStack Congress를통해 정책 기반의 유연한 장애 상관관계를 확인

– OpenStack Congress 통합(Colorado에서 Congress = Inspector 기능 추가)



31

Doctor(Fault Management & Maintenance) [2]– Architecture

• Monitor : Virtualized Infrastructure를감시. H/W & S/W resource의다양한 측면을 모니터링하는 tool &

service(e.g. Zabbix) 로 event 발생시 Inspector에 notification

• Inspector : Controller의 Resource Map을확인하여 virtual resource의영향도에 따라 상태를 업데이트(Notifier가상태를 참조)

• Controller(s) : 지속적으로 resource 상태를 업데이트하고 Notifier에 virtual resource에대한 모든 failure

events를보낸다(Nova)

• Notifier : Controller로부터 받은 failure events와초기 Consumer에의해 정의 된 Alarm 구성을 참조하여Consumer에게 Notify



32

Doctor(Fault Management & Maintenance) [3]– Doctor Platform and typical sequence (Colorado = brahmaputra)

• OpenStack Compute(Nova) - Controller

• OpenStack Telemetry(Ceilometer) - Notifier

• OpenStack Alarming(Aodh) - Notifier

• Doctor Inspector

• Doctor Monitor



33

Doctor(Fault Management & Maintenance) [4]– Use Case 1 : Faults Management(&recovery)

• 요구조건 : Controller가 NFVI의 오류를 검출 할 수 있도록 구성 되어야 함

– 결함 예측 관련 Project : Prediction Project

• 동작 과정 : NFVI 상태 모니터링 중 특정 Server에서 Fault 발생 시 해당 Server 상에 존재하는 VM(s)을 다른Server로 Migration 수행



34

Doctor(Fault Management & Maintenance) [3]– Use Case 2 : Maintenance

• 요구조건 : Administrator(관리자)에의한 작업은 전체 형상 유지 및 VM(s)의 영향을 최소화 하기 위해Consumer(VNFM or NFVO)를 통해서 수행

• 동작 과정 : 특정 Server에 대한 Upgrade 및 종료 필요 시, 해당 Server 상에 존재하는 VM(s)을 다른 Server

로 Migration 수행



35

Copper(Virtualized Infrastructure Deployment Policies) [1]– Overview

• 가상 자원을 사용자가 원하는 NFV Infrastructure에 Deploy 하도록 Policy를 정의

• 기존의 Open Source를이용하여 Compute, Network, Storage 등의 가상 인프라 관리(Virtual Infrastructure

Management)를위한 Policy을 테스트

• Copper를위한 기존 Open Source

– OpenStack Congress : OpenStack에서제공하는 Policy as a Service

– OpenDaylight Group Based Policy(GBP) : Application 각각에 대한 정책 구성

– Goals

• Copper Project는 NFV 서비스 환경이 NFV 플랫폼을 사용하는 (이해)관계자의 다양한 요구사항을 충족하는지 확인하기 위해 configuration policy을 통해 보장

– Scope

• Brahmaputra

– OPNFV의 installer project중하나 이상에 OpenStack Congress를추가

– Congress service exercise에 test script 및 tool 제공

• Colorado

– Congress는 JOID 및 Apex installer을위해서 OPNFV CI/CD pipeline에서지원

» For JOID, a JuJu Charm for Congress

» For Apex, a Puppet Module for Congress

– Congress use case tests는 Functest 에 통합

– Congress test tools의추가 기능 향상



36

Copper(Virtualized Infrastructure Deployment Policies) [2]– Use Case 1: Affinity

• VM instance 생성시 특정 compute 또는 storage cluster에함께 위치하도록 생성

– Use Case 2: Anti Affinity

• VM instance 생성시 서로 다른(또는 외부의) compute 또는 storage cluster에생성

– Use Case 3: Network Access Control

• VM에 연결된 Network는 공개 하거나 VM owner’s group이소유 하여,

– Troubleshooting을위한 physical or virtual network ports Mirroring

– 서비스 사용자의 개인 정보 보호를 위해 다른 tenants로의 Mirroring을 방지할 수 있어야 함

– Use Case 4: Storage Access Control

• VM에 연결된 Storage resource는 VM owners’ group user가소유

– Use Case 5: Resource Reclamation

• Scaling up(또는 down) 상황 등 VI 자원 확보를 위해 Resource Reclamation

– Use Case 6: Resource Use Limits

• 자원 사용 시간 제한 후 instance 종료(terminated)



37

Promise(Resource Management) [1]– Overview

• Virtualized telecom network에서 Resource Reservation은기본적인 기능

– 자원 예약에 따른 Scheduling 없이 다수의 Consumer가 Resource에대한 설정을 변경(VM 생성 또는 증가) 할 경우 실패 할 가능성이 높아짐

• 가상 자원 예약과 관리(Resource Reservation & Management)를위한 Project

– Resource : Compute, Storage, Network

• OpenStack에서는 Resource Reservation 기능을 지원하지 않음

• OPNFV에서 해당 기능을 수행하기 위한 Project로수립

– Goals

• 가상화 된 인프라(Virtualized Infrastructure) 상에서 운영되는 네트워크 서비스의 HA(High Availability)를보장하고 관리체계 구축을 위한 Framework를제공

• ETSI GS NFV MAN 001(NFV Management and Orchestration)에정의된 다음 두 가지 요구 사항을 제공

– Resource Capacity Management

– Resource Reservation



38

Promise(Resource Management) [2]– Features

• Reservation management

– Create-reservation

» 가용 용량을 확인하고 예약 요구를 충족시키는 충분한 용량이 존재할 경우 생성

– Update-reservation

» Create-reservation과동일한 parameters와 reservation-id를통해 update

– Cancel-reservation

» reservation-id를통해 예약을 취소

– Query-reservation

» Reservation system에서 filter를통해 Query와 일치하는 예약에 대한 정보를 반환

• Allocation management

– Create-instance

» 사용 가능한 Resource pool을이용하여 instance를즉시 생성

– Destroy-instance

» Instance-id를통해 instance destroy

• Capacity management

– Increase/Decrease-capacity

» Increase/Decrease 서비스사용 시 충분한 자원이 적절한 시간에 사용될 수 있는지에 대한 책임은Consumer/Administrator에게있기 때문에 신중하게 사용

– Query-capacity

» 가용 capacity 정보를 조회하기 위해 사용



39

Promise(Resource Management) [3]– Architecture

– ETSI NFV에서 User/Client는 NFVO 또는 VNFM에 대응

– 예약 된 자원은 시작 시간부터 종료 시간으로 사용

– Promise 문서 에서는 NFVO의 예약 요청에 대해서만 고려



40

Promise(Resource Management) [4]– Need to be developed

• Capacity management

– Resource providers(NFVI)에서사용 가능한 자원의 확인 & Monitoring

– New 또는 expired 예약이나 addition/removal 되는 Resource의결과를 제공하기 위해서 사용 가능한Resource capacity 상태를 update

» VIM 자체 기능으로 VIM northbound interface 동작이 아님



41


• Resource Reservation

– 시작 시간 및 종료 시간 설정

– Resource capacity Increase/decrease 예약

– Update resource reservation(e.g. add/remove)

– Reservation time 종료로 인한 Terminate(제거)



42


• VIM northbound interfaces

– Resource 예약 요청의 Receive/Reply

– Resource capacity 관리 요청의 Receive/Reply

– Start time에맞춰 예약된 Resource 할당 요청의 Receive/Reply

– Resource reservation event의 Subscribe/Notify

» Resource Reservation Subscribe의결과(Error or complete)를예약 전에 회신

» 예약 종료 시간까지 남은 시간에 대해 Subscribe/Notify

» 예약 종료 시간에 자원 종료 알림 Subscribe/Notify

– 사용 가능한 Resource capacity 요청의 Receive/Reply

– 변경 가능한 Resource capacity 요청의 Receive/Reply



43

Availability(High Availability for OPNFV)– Overview

• OPNFV Platform에필요한 HA(High Availability) 기능 요구사항분석 및 Solution을제시하는 Project

– Goals

• 아래와 같은 요구사항 문서(Requirement Document) 작성

– Overall Principle for High availability in NFV

– Hardware High Availability

– Virtualization facilities High Availability(Host OS & Hypervisor)

– Virtual Infrastructure High Availability

– VIM High Availability

– VNF High Availability

• OpenStack 에서 제공하는 HA Scheme 과 NFV Scenario 에서 필요한 HA Scheme 차이 분석



44

DPACC(Data Plane Acceleration) [1]– Overview

• 과거에 비해 다양한 유형의 Traffic 발생 및 Data Rate의증가로 Network Infrastructure에서 Data Plane

Device의 High Performance가요구됨

• Bandwidth, Real Time을위한 Data Plane Device의가속화 기능 Project

– Goals

• VNF Data plane acceleration을위한 General Framework 지정

• Data plane acceleration에대한 추상화 API 정의 및 개발

• Acceleration 기술 적용 여부나 종류, 하드웨어에 관계없이 VNF의 Portability와 Resource Management를보장

– Features

• 가장 일반적이고 중요한 기능들에 대한 DPA(Data Plane Acceleration) API를 정의

– Packet Processing

– Encryption

– Transcoding



45

DPACC(Data Plane Acceleration) [2]– Use Cases

“Pass-Through” Model

• VNF에서 Hypervisor/host OS를 bypass하여HW resource에 direct 접근

• 장점 : HW resource에직접 접근하여 높은성능을 내는 Model

• 단점 : VM image는새로운 H/W

Accelerators 또는 변경 시 마다 특정드라이버를 업그레이드를 통해 확인

"Fully-Intermediated" Model

• VNF에서 Synthetic Driver를 통해 HW

resource에접근

• 장점 : VNFs 변경 여부와 상관없이 backend

driver에서 대응 가능

• 단점 : VNFs에 할당하는 H/W의 access

control, resource scheduling mechanisms



46

DPACC(Data Plane Acceleration) [3]– Scope

• Packet processing, encryption, transcoding외의기능은 이후 phases에포함(e.g. Management plane API)

• Use cases, Management plane Interface, Integrated testing and release testing result가추가 예정



47

OpenStack based VNF Forwarding Graph [1]– Overview

• VNFFG(VNF Forwarding Graph)는 End to End 사이의 VNF Service들을 빠르게 자동으로 Deploy할수 있도록 해주는 Framework를수립 하는 Project

• VNFFG는 GS NFV-MANO 001(ETSI NFV 표준 문서)에 정의 된 구성 요소 중 하나

• Network Service를구성하는 VNF의 연결 순서를 의미(An Ordered Sequence of VNFs for composed

Services)

• VNFFG = Service Function Chaining

– Goals

• Tenant의 Traffic에따라 필요한 네트워크 기능(VNF)등을 선택적으로 연결(chaining) 및 실행이 가능하게 함

• OpenStack 기반의 Service Function Chaining 기술 구현 및 검증

– Features

• VNF Instance and VNF Template registration (on-boarding) and management

• Intent based specification of a tenant’s flow and its associated service function requirement/intention

• Information (such as 3rd party’s VNF instance connectivity and flavor details and VNFFG’s service function

ordering information) passing mechanism between the VNFFG Manager and Network Controllers’ drivers.

• OpenStack based and OpenFlow compliant VNFFG setup.

• NSH encapsulation mechanism for chain-ID and metadata in the data plane.

• Service by-pass feature which can dynamically bypass a VNF in the case that the VNF service is not

needed anymore.

– Dependencies

• SFC Architecture : L4-L7 Work Group [ONF-SFC]을 따른다

• SFC Encapsulation(data-plane) : IETF의 SFC Work Group [SFC-ARCH]와 [SFC-SCH]을 따른다



48

OpenStack based VNF Forwarding Graph [2]– Architecture

– Components

• VNFFG Orchestrator/Manager : 관리자/사용자가 Intent 기반의 VNFFG를 정의 할 수 있도록 Interface 제공

• VNF Instance Manager : VNFs의 life cycle 관리. VNF Registration API를 통해 VNFFG Manager로부터 전달

• SDN Controller : 트래픽 제어를 위해 Classifier, SF Forwarder에 Flow Rule을 Deploy 함

• Service Function Forwarder(OF-Switch) : SF-Forwarder가관리하는 Local VNF(e.g. FW, LB, IPS)들의 트래픽 제어

• VNF : Service Function 으로 실제 기능을 수행

• Traffic Classifier : 들어오는 패킷(ingress packet)을검사하여 VNFFG 유형별로 분리



49

OpenStack based VNF Forwarding Graph [3]– Interfaces

• Management Interfaces

– Interface M1은 VNFFG App/Admin와 VNFFG Manager 사이에 위치하며, VNFs와 VNFFGs 생성

– Interface M2은 VNF Manager와 VNFFG Manager 사이에 위치하며, VNF Instance & Templates 등록

• Control Plane Interfaces

– Interface C1은 VNFFG Plugin과다른 벤더의 SDN Controller driver 사이에 위치하며, VNF 인스턴스(Service Function) 연결 및 상세 설정

– Interface C2은 SDN Controller와 (OpenFlow)vSwitch 사이에 위치하며, vSwitch에 경로를 programming

• Data-plane Interfaces

– Data가 VNFFG를 횡단하는 경로에 존재하는 Interface

– Ingress Classifier, Service Function, Proxy Devices등에위치



50

Prediction(Data Collection for Failure Prediction)– Overview

• Failure Prediction(장애예측)System Project

• Failure Prediction System은 Data Collector, Failure Predictor, Failure Management 를 목표로 하며, 각각의모듈로 구성

• 사용자가 사전에 정의한 규칙에 의해 Failure를감지하고 데이터를 수집

• 수집된 데이터를 바탕으로 Machine Learning을통해 Failure감지를위한 새로운 규칙을 정의하여Unexpected Failure를감지

• Failure Prediction을위해 Machine Learning Library 사용(e.g. Weka, Spark ML lib)

– Goals

• NFV 시스템에서 Unexpected Failure를방지하기 위한 Failure Prediction Framework 구축

– Features

• Monasca

– 모니터링 서비스 MONaaS(Monitoring as a Service)를 제공하는 OpenStack프로젝트

• Heat

– OpenStack의 Orchestration 프로젝트

– Heat에서제공하는 cfn-hup라는 Tool을이용하여 VM의 Metadata 모니터링 및 Notification 가능

• VM Introspection(Virtual Machine Introspection)

– VM을 검사하고 수정하기 위한 Mechanism

– LibVIM라는오픈소스를 통해 Xen, KVM기반의 VM 검사 및 수정 가능

– Use Case 1 : Infrastructure Failure Prediction

• Infrastructure Metric 을 기반으로 Infrastructure 에대한 Failure Prediction 을 수행(e.g. Nova, Neutron, MQ)

– Use Case 2

• Infrastructure 와 VM 에 대한 Metric 을 기반으로 VNF 에 대한 Failure Prediction 을 수행



51

RS(Resource Scheduler) [1]– Overview

• VNF는 여러 개의 VM(VNFC)과 VLinks(Virtual Network)로 구성됨

• OpenStack에서 VM이 서로 다른 Host로 선택이 될 수 있어 높은 성능을 보장 하지 않음

– OpenStack에서 VM의 Deploy는 Nova Scheduler(Resource Scheduler)가담당

– Nova Scheduler는 VM을 Deploy할 Host선택시, Filter와 Weight Mechanism으로결정

– 따라서, VM이 서로 다른 Host에생성 될 경우 높은 성능을 보장하지 않음

• OpenStack에서 VLinks(Network 자원) 요구사항 반영이 불가능하여 높은 성능을 보장하지 않음

– OpenStack의 Ceilometer로 Network 정보 모니터링이 불가능

– 따라서, Nova Scheduler는 Network resource 요구 및 제약조건을 확인 할 수 없음

• 즉, Resource Scheduler를통해 VM 및 VLinks 할당 최적화 향상을 위한 Project

– Goals

• 성능 최적화를 위한 Resource Scheduler 기능 강화

• Network 정보 및 Resource 의 분리



52

RS(Resource Scheduler) [2]– Nova Scheduler : VM Deployment Mechanism

• Nova Scheduler가 VM을 Deploy할 Host를결정하는 Mechanism을의미

• Filters : Service 상태부터 resource, server type등을고려하여 Accept or reject

• Weighting : VM 생성 costs가 Host에할당 될 경우 host간 weight를 비교하여 Sort

출처 : http://docs.openstack.org/kilo/config-reference/content/section_compute-scheduler.html



53

RS(Resource Scheduler) [3]– Architecture

– VM deploy시 Nova Scheduler에의해 관리되던 resource관리를 RS(Resource Scheduler)의정책을 통해 관리

NFVI

Cloud Admin

State

DB

Commander

AdvisorWatcher

OpenStack

VNFO

NFVM

RSNova Scheduler

Policy

Tacticcollect

check

decideapply

request

출처 : https://wiki.opnfv.org/download/attachments/2926023/rs_architecture_for_discussion_r1.pptx?version=1&modificationDate=1458849023000&api=v2



54

RS(Resource Scheduler) [4]– Features

• Network Information Monitoring and Collection

– 물리적 Host 사이의 Links의대역폭과 시간 지연

– 물리적 Network Topology

– 물리적 Network안에서 Vlinks의상태를 미리 정의

• Resource Isolation

– 자원 관리의 효율성과 성능 보장을 위해 VM에 할당되는 자원은 같은 Host에서 제공

– 현재 OpenStack에서는이와 같은 Resource Isolation을지원하지 않음



55

RS(Resource Scheduler) [5]– Features

• Resource Allocation Optimization

– VM 생성 시, Neutron, Cinder, Ceilometer로부터 다양한 정보를 수집하여 VM을 Deploy 할 Host 결정



56

Movie [1]– Overview

• OPNFV의 Architecture에서 General Cloud Platform:VIM(e.g. OpenStack)가상위 계층에 NBI(NorthBound

Interface)를제공하도록 하는 Project

– OpenStack에서제공하고 있는 Interface(The IaaS service oriented NBI)는상위 계층에서 많은 작업이필요

• 상위 계층(NFV Orchestrator, VMF Manager)에서 VIM의 가상 자원(Computing, Network, Storage Service)

의 접근, VNF접속, 흐름 식별, 정책 조작을 하기 위한 추상화 Interface(Intent base NBI)

– Goals

• General Cloud Platform(e.g. OpenStack)의 Interface를확장하여 추상화 된 VIM NBI(North-Bound

Interface)제공

• OpenStack에서제공하는 Interface 뿐 아니라 Promise, Copper, VNFFG와 같은 OPNFV 연관 Project의NBI 제공을 위한 요구사항 분석을 진행



57

Movie [2]– Architecture

• NBI 일관성을 위해 MDA(Model Driven Architecture)를사용

• MDA란? 잘 정의된 모델(e.g. Yang Modeling)을이용하여 Interface를자동으로 생성하는 Architecture



58

Multisite(Multi-Site Virtualized Infrastructure) [1]– Overview

• NFV Infrastructure와 NFVI를 관리하는 VIM는 복수의 지역에 분산되어 구축될 수 있음

• 복수의 지역에 분산된 다수의 VIM(OpenStack)에대한 연결 및 관리가 필요

– Goals

• VIM으로 사용되는 OpenStack의하위 프로젝트(Nova, Cinder, Neutron, Glance, Ceilometer, KeyStone 등)

를 개선하여 NFV Cloud 환경을 지원 하는 것을 목표로 함

– Architecture

• Multisite Project는 OpenStack(및하위 프로젝트)뿐 아니라 Copper, Promise, VNFFG, Doctor, HA, Parser,

등등 OPNFV 하위 프로젝트들의 요구 사항도 분석



59

Multisite(Multi-Site Virtualized Infrastructure) [2]– Use Case 1 : Multisite identity service management

• Bug reported to KeyStone (Liberty)

– Use Case 2 : VNF high availability across VIM

• Cross OpenStack L2 networking requirements to L2GW (Newton)

– Use Case 3 : Multisite VNF Geo-Site disaster recovery

• Group VMs consistency snapshot via quiesce/unquiesce API (Newton)

– Use Case 4 : Resources management and synchronization

– Use Case 5 : Centralized monitoring service

• Kingbird

– 분산된 가상 자원, tenant 레벨의 IP/MAC 주소 관리를 위한 global view, ssh key의 동기화, images,

flavors, security groups등을중앙에서 관리하고 view를 제공하는 project

– Colorado Release Notes는 Kingbird에서진행

• Tricircle

– OpenStack 하위 프로젝트. L2/L3 네트워크를 연결하여 volume/VM 이동, 이미지 배포, 글로벌 자원 view

분산 관리



60

Escalator(Smooth Upgrade) [1]– Overview

• 기존 Telco Network에서 Service(Software)는전용 Hardware Platform과결합되어 있는 구조

• NFV Framework는가상화 기술을 통해 VNF(Service Software)가위치한 Platform/Hardware로부터 분리(decouple)되어있는 구조로 Platform/Hardware에대한 Upgrade가용이 함

– Goals

• NFVI와 VIM을 서비스 중단이 없이 업그레이드(Smooth Upgrade)하기위해서 사용자 요구 사항을 도출하기위한 Project

– Scope



61

Escalator(Smooth Upgrade) [2]– Published(ETSI ISG NFV REL003)

1. 서비스 가용성 및 네트워크 서비스의 중단없이 Software Upgrade

2. 네트워크 서비스 및 VNFFG의 update가필요할 수 있으며, 네트워크 서비스 중단이발생해서는 안됨

3. VNF 및 Infrastructure software modules(e.g.

virtualization layer or hypervisor, virtual

switches, Firmware software, etc.)를독립적으로 Upgrade 가능

4. Software는서비스 가용성 및 연속성을 보장

5. Upgrade 된 Software는기존 네트워크트래픽이 정상적으로 처리 되는지 실시간으로확인

6. NFV-MANO Software Upgrade 동작이 기존네트워크 서비스 및 가용성과 연속성에 영향을주어서는 안됨



62

Inspector(Audit)– Overview

• 현재 OPNFV는 Cloud 환경에서 Audit 표준 포맷을 준수하기 어려움

• CADF를 통해 NFV 환경에서 표준 포맷을 따르는 Auditing Framework 구축을 목표로 함

– CADF : Cloud Auditing Data Federation, 감사 이벤트에 대한 명세, OpenStack Identity에서지원

• CADF는 Cloud Provider와 Customer 사이에 활용되는 Event, Log, Report 들에 대한 Data Model을정의

– Goals

• OPNFV의 핵심 Component들의Audit Framework가 충분히 광범위하고 산업 표준을 준수하고 NFV Use

Case에사용 가능한지 분석하고 평가하기 위한 Project

– Features

• 존재하는 CADF Based tools을이용하여 Audit Solution 구축

• OpenStack의Audit에대한 분석 문서 제공

• ODL(OpenDaylight)의 Audit 준수에 대한 요구사항 분석 및 문서 제공

• NFV에 사용되는 CADF가 필요한 Audit Information(감사로그 정보)를 모두 포함 하고 있는지에 대한 평가결과 문서 제공

• OpenStack Component들이 CADF 표준을 준수하기 위한 요구사항 분석 문서 제공

• OpenStack Component들이 Audit Integrity Protection(감사로그 무결성 보장)과 관련된 요구사항 분석 문서제공

– Dependencies

• OpenStack release cycle에 종속

• OpenStack related modules

– pyCADF/keystonemiddleware

– Barbican/Castellan

– Ceilometer

• ODL



63

RCA, Pinpoint(Fault localization) [1]– Overview

• Observed indications(Neutron-Nova, Ceilometer, Monasca, SDN Controller 등)구성들로 부터 Fault의정확한 source를도출하는 Process

• 성능에 대한 병목(Bottleneck)지점도분석

– Goals

• NFVI, VIM을 위한 Fault Localization Framework 제공

• Fault의범위는 Network 관련 Issue를대상으로 함(e.g. No Network Connectivity)

– Features

• Fault Isolation

– Failure(결함) 발생 시 전체 시스템에 영향을 미치지 않도록 결함 발생 구성요소를 분리시키거나격리

• Alarm/Event Correlation

• RCA(Root Cause Analysis)

– 문제 발생 시 정확한 원인 분석



64

RCA, Pinpoint(Fault localization) [2]– Scope

• 가상화 환경에서 Network fault localization



65

RCA, Pinpoint(Fault localization) [3]– Architecture(with other project)

• Doctor : fault notification 및 event 집계

• Yardstick : 구성 검증 테스트 프로젝트. OAM Tools로사용.

• Bottleneck : 시스템 병목 현상과 성능을 배포 전에 알기 위한 테스트 자동화 환경 구성(준비 단계)



66

Genesis(General System Install Services)– Overview

• OPNFV설치에 사용되는 Deployment Tool(Installer)로 Joid, Apex, Fuel, Compass가있음

• 여러 개의 Installer(Joid, Apex, Fuel, Compass)에대한 보편적인 요구사항을 정의한 Project

• Integration & Testing Project의 Bootstrap/Get-Started(BGS) Project 결과를 기반으로 진행

– Bootstrap/Get-Started Project는 VNF example을실행 할 수 있도록 빠르게 NFV 환경을 구성하고 검증하는 Project

• Genesis Project는 Colorado에참여 되지 않음(Brahmaputra 유지)

– Goals

• Genesis project에정의된 요구사항을 OPNFV 설치 Installer에반영하여 Common User Experience 제공을목표로 함

– Deployment Tool

• Joid

• Apex

• Fuel

• Compass



67

ENFV(Edge NFV)– Overview

• NFV 기술은 기존 네트워크 H/W 장비들을 가상화 하여 자원을 효율적으로 관리

• Switch, Router와같은 Edge Network 장비 역시 NFV 기술 범위에 포함

• 따라서 Edge NFV Platform에대해서도 NFVI나 MANO와 상호 연동 하는 경우에 대한 고려가 필요

– Goals

• Edge Network NFV Platform이필요로 하는 Capability와 Behavior 등을 정의

– Features

• WAN links로오는 User Traffic에대한 전용 Tunneling

• WAN links로 Compute platform에접근권한을 가지는 Management Traffic에대한 전용 Tunneling

• 많은 작은 DC(Data Center)를위해 Multi data center 관리를 확장

• Remote Compute Node를위한 모니터링 기능

• Data plane 최적화(e.g. DPACC)



68

Models(Model-Driven)– Overview

• Open Source Project나표준 단체에서는 NFV Service / VNF Management 개발을 위해 Information과 Data

Model을정의 함

• Information / Data Model : NFV System을 구성하는 Functional Block(e.g. VIM, VNFM, NFVO)간 교환하는정보나 메시지를 의미

– Goals

• Open Source Project나표준 단체에서 정의하는 Information / Data Model에대한 통합과 유효성 입증

– Features

• Colorado release planning page : Not Found

• Danube release planning page : https://wiki.opnfv.org/display/SWREL/Danube

https://wiki.opnfv.org/display/SWREL/Danube



69

Domino(Template Distribution Service) [1]– Overview

• NFV의 발전으로 NFV Infrastructure는지리적으로 확산되어 구축

• 사업자는 transport resource 뿐만 아니라 compute 및 storage resource등에대해서도 지리적 분산 구축 환경을 고려한 관리가 필요

• 모든 지역을 하나의 Centralized Resource Orchestrator가통합 관리 하는 것은 NFV 환경에 적합하지 않음

• 지역을 Domain 단위로 나누고 각 Domain에 Resource Orchestrator나 Controller를통해 Resource를효율적으로 관리

– VNF(e.g. VM+VLINKs생성) 구성 시 같은 Domain Resource를결합하여 구성

• 서로 다른 Domain에위치하는 VNF의 결합은 End to End(E2E) Service로정의

• E2E Service는 Model과 Policy를 정의하여 하나의 Service Template에전체 서비스 시나리오를 정의

• E2E Service Template가생성될 경우 해당 Template는 Processed, Partitioned, Translated 과정을 거쳐 각Domain의 Local Resource Orchestrator에게분배(Distributed)

– Goals

• 발전된 NFV 환경에서 E2E Service Template를배포하여 효율적인 Resource관리를위한 Project

– Features

• Colorado release planning page : Not Found

– Colorado release : User guide

• Danube release planning page : https://wiki.opnfv.org/display/SWREL/Danube

https://wiki.opnfv.org/display/SWREL/Danube



70

Domino(Template Distribution Service) [2]– Architecture

• Model과 Policy 생성

• Model을설명하고 Policy을 표현하기 위해 기존도구를 사용

• e.g. Copper, Model, Congress,

yang/yaml models, NEMO, protocol

buffers, etc

• Model 및 Policy 생성 방법은 이 프로젝트목적과 거리가 있으므로 생략

• policy2tosca 모듈에서 일관된 서비스 템플릿 생성을위해 Policy 규칙 및 Service Model을구문 분석

• 등록된 Consumers에맞게 Service Template에서해당하는 부분을 결정하고 Consumers가인식하는형식으로 Template을변환 후 전송

• Domino Module은 OPNFV의 Upstream

Project(e.g. Parser)를 활용하여 Template을번역

• Consumers는하나 이상의 resource orchestration

templates를가지고 있거나(e.g. OpenStack - Heat

Orchestrator and Kubernetes) Template based

orchestration agent가설치 필요



71

NetReady(Network Readiness)– Overview & Goals

• Cloud Platform 인 OpenStack 을 NFV Platform 으로 사용 할 때 Networking Architecture 에서 추가적으로변경이 필요한 사항들에 대한 조사

– Features

• NFV use case의관련 설정을 알아보고 Use Case로부터 요구 사항을 분석

• 요구 사항 분석을 기반으로 OpenStack Networking architecture와의 gap을분석

• Architecture Solution 제안

• 제안된 Solution 평가

– Result

• NFV Networking 사업은 혁신, 빠른 개발, 민첩한 구동 및 배포가 쉽게 이루어 지도록 요구.

• 따라서, model-driven, 확장성 있는 framework로주문형 NFV networking을지원할 것으로 예상

• OpenStack은관리자 권한 없이 네트워크 관리자 작업을 수행할 수 있어야 함



72

Opera(Open-O Integration) [1]– Overview

• OPNFV 범위에 NFV MANO가 포함되도록 확대 되면서 upstream project로추가 생성

• Open-O(Open-Orchestration)는 MANO에 대한 요구 사항으로 개발 진행 된 비 독점적 Project

• OPNFV platform과 MANO의 다양한 components 통합을 위해 interface/data models의요구사항에 중점을둠

• VIM으로 OpenStack, VNFM으로 Juju, NFVO으로 Open-O 사이의 통합을 지원하도록 설계

– Goals

• OPNFV에서 NFVO의 역할 및 NFVO역할을 가지는 Project 및 다른 Project의참조 Project



73

Opera(Open-O Integration) [2]– Scope

• ETSI NFV MANO interface 표준

• (2)-NFVO, (9)-VIM interface 표준



74

Opera(Open-O Integration) [3]– Scope

• Project 통합 범위

• 초기 Open-O Integration은 NFVO, Common TOSCA 및 Common Service 구성에 집중

• Open-O 와 관련된 다른 Components는다음 OPNFV 에서 통합



75

Orchestra(Open Baton Integration) [1]– Overview

• 2015년 10월 ETSI NFV MANO가 OPNFV 프로젝트에 포함(Colorado 1.0 비공개 Project)

• MANO의 역할로 존재하던 Open Baton platform(open source)을 OPNFV에 통합하는 project

– Goals

• OPNFV 설치 도구의 일부로서 OPNFV platform에통합

• Open baton 통합 test의 use case를기반으로 OPNFV 프로젝트 Models 및 FuncTest와통합

• Autoscaling 및 Fault Management와관련된 use cased의확장을 통해 OPNFV project에통합



76

Orchestra(Open Baton Integration) [2]– Architecture

• NS : Network Slicing

• AE : Autoscaling Engine

• FM : Fault Management



77

Orchestra(Open Baton Integration)[3]– Features

• Network functions 및 service 뿐만 아니라 Infrastructure resources를동적으로 관리하는 Carrier grade급NFV Orchestrator

• 동적 관리 기능 gVNFM(generic Virtual Network Function Manager)

• 다른 타입의 VIM을 추가하거나 삭제할 경우 Orchestration login의어떤 수정도 없이 추가 및 삭제가 가능한plugin mechanism

• Publish/subscribe mechanism 기반의 강력한 event 처리 엔진이 등록 된 외부 모듈에 lifecycle event를발송

• VNFs 스케일링 동작을 자동으로 실행 관리 가능한 auto-scaling 엔진

• 모든 수준의 fault에자동 실행 관리되는 fault management system

• Customized VNFMs의 생성을 위한 libraries 구성, CLI 터미널을 통한 빠른 Network Functions 관리

• Platform 관리를 위한 사용자 친화적인 dashboard


References

http://artifacts.opnfv.org/opnfvdocs/colorado/docs/overview/index.html

http://artifacts.opnfv.org/opnfvdocs/colorado/docs/platformoverview/index.html

https://wiki.opnfv.org/display/moon/Moon+Projet+Proposal

http://artifacts.opnfv.org/opnfvdocs/colorado/docs/platformoverview/deploymenttools.html

https://wiki.opnfv.org/display/PROJ/Approved+Projects

http://artifacts.opnfv.org/opnfvdocs/colorado/docs/documentation/index.html






http://artifacts.opnfv.org/opnfvdocs/colorado/docs/documentation/index.html

20161110 cmlee opnfv_colorado1.0_분석

Technology