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

1
OPNFV Colorado 1.0 분석
2016. 11. 10
㈜파이오링크
SDN개발실 이철민(cm.lee@piolink.com)

© 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에 가
치 있는 기여를 제공

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

Colorado Release Documentation

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
– 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
– 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
– 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
– 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
– 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 Platform and typical sequence (Colorado = brahmaputra)
• OpenStack Compute(Nova) - Controller
• OpenStack Telemetry(Ceilometer) - Notifier
• OpenStack Alarming(Aodh) - Notifier
• Doctor Inspector
• Doctor Monitor

33
– Use Case 1 : Faults Management(&recovery)
• 요구조건 : Controller가 NFVI의 오류를 검출 할 수 있도록 구성 되어야 함
– 결함 예측 관련 Project : Prediction Project
• 동작 과정 : NFVI 상태 모니터링 중 특정 Server에서 Fault 발생 시 해당 Server 상에 존재하는 VM(s)을 다른
Server로 Migration 수행

34
– 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
– 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
– Architecture
– ETSI NFV에서 User/Client는 NFVO 또는 VNFM에 대응
– 예약 된 자원은 시작 시간부터 종료 시간으로 사용
– Promise 문서 에서는 NFVO의 예약 요청에 대해서만 고려

40
– 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
– 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
– 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
– 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
– 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
– 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
– Architecture
– VM deploy시 Nova Scheduler에 의해 관리되던 resource관리를 RS(Resource Scheduler)의 정책을 통해 관리
NFVI
Cloud Admin
State
DB
Commander
AdvisorWatcher
OpenStack
VNFO
NFVM
RSNova
Scheduler
Policy
Tactic
collect
check
decideapply
request
출처 : https://wiki.opnfv.org/download/attachments/2926023/rs_architecture_for_discussion_r1.pptx?version=1&modificationDate=1458849023000&api=v2

54
– Features
• Network Information Monitoring and Collection
– 물리적 Host 사이의 Links의 대역폭과 시간 지연
– 물리적 Network Topology
– 물리적 Network안에서 Vlinks의 상태를 미리 정의
• Resource Isolation
– 자원 관리의 효율성과 성능 보장을 위해 VM에 할당되는 자원은 같은 Host에서 제공
– 현재 OpenStack에서는 이와 같은 Resource Isolation을 지원하지 않음

55
– 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
– Scope
• 가상화 환경에서 Network fault localization

65
– 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

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

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
– Scope
• ETSI NFV MANO interface 표준
• (2)-NFVO, (9)-VIM interface 표준

74
– 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

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

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

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

Ähnlich wie 20161110 cmlee opnfv_colorado1.0_분석 (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (6)

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