ettrends banner

백동명 (Baek D.M.) 네트워크컴퓨팅융합연구실 선임연구원
윤승현 (Yoon S.H.) 네트워크컴퓨팅융합연구실 책임연구원
이범철 (Lee B.C.) 네트워크컴퓨팅융합연구실 실장

Ⅰ. 서론

Network Function Virtualization(NFV)은 2012년 10월 ETSI Industry Specification Group(ISG) 산하의 NFV로부터 출발하여 2015년 1월까지 phase 1을 마치고, 2017년 1월까지 phase 2로 진행되고 있다. 현재 38개 이상의 통신사업자와 270여 개 이상의 IT벤더가 참여하고 있다. Phase1에서는 NFV가 무엇이고, 어떤 이점이 있고, 어떤 기술적 이슈가 있는지, 어떤 use case가 있는지에 초점을 맞추었다. Phase 2에서는 멀티 벤더 제품 간 상호호환 보장, 네트워크 기능관리의 자동화 및 간소화, 새로운 요구사항에 대한 use case 발굴, 가상화 및 클라우드 컴퓨팅 기술과의 접목 및 향상 등에 초점을 두고 있다. 조직도상으로도 NFV기술의 진화와 새로운 요구사항 및 에코시스템을 발굴하는 EVE WG와 기존의 SWA, Management and Orchestration(MANO), INF WG이 하나로 합쳐져 인터페이스 및 기능 구조에 대한 규격을 개발하는 IFA WG 등이 생겼다[1].

NFV의 특징은 네트워크 기능을 SW화하여 제어 및 관리할 수 있게 하는 것이다. 이 점이 미래 통신의 유연성과 서비스 민첩성(agility)을 가져다 줄 것으로 기대한다. 네트워크 기능이란 모바일 네트워크 노드 기능(라우팅, SGSN, GGSN, PDN-GW등)과, VPN, Deep Packet Inspection(DPI), QoS 모니터링 기능, AAA, 정책 서버, Firewalls, spam 방지기능 등이 말한다. 또한, 통신사업자들의 요구사항이 Network Operators Council(NOC)을 통해 강하게 반영된다.

NFV 이점으로는 Capital Expenditure(CAPEX)/OPEX 절감, 새로운 서비스 생성에 대한 시간단축과 투자비용 회수 증대, 유연한 서비스 진화성과 스케일 변경에 따른 관리 자동화가 있다. 현재의 통신사업자들은 비용절감보다는 새로운 서비스 창출에 무게를 더 두고 있다. 산업적 효과는 순수 SW 참여시장을 개방하고, 혁신적 서비스 개발에 대한 기회가 증대할 것으로 예측한다.

기술적 이슈로는 SW화함에 따른 성능저하 문제와 보안문제이다. 성능 면에선 DPDK 같은 데이터 가속화 기술로서, 보안문제는 REL(reliability) WG와 SEC(security) WG에서 이를 해결하고자 한다. 멀티 벤더 간 상호호환성과 인터워킹도 이슈이다. 또한, 오픈소스단체들(OPNFV, OpenStack)과의 문화적 차이 극복도 중요하다. 보수적인 표준화 단체와 진보적인 오픈소스 단체의 문화적 차이도 적지 않다. 과거와는 달리 규격보다 코드가 먼저 나오는 현실이다.

신규 서비스 창출의 가능성은 use case와 Proof of Concepts(PoC)에서 볼 수 있다. 클라우드식 분류법을 택한 NFVLaaS, VNPaaS, VNFaaS와 이동통신영역인 vEvolved Packet Core(EPC)와 vIP Multimedia System(IMS), 기지국 가상화를 들 수 있다. 또한, Set Top Box(STB)등 홈 네트워크 서비스 가상화, 미래에도 여전히 문제가 될 비디오 트래픽을 다루는 CDN 등이 있다. 이 중에서 service chaining 혹은 VNF Forwar-ding Graph(VNFFG)가 가장 Virtual Network Fun-ction(VNF)다운 서비스라고 판단된다. PoC는 7월 현재 38개가 제안되었는데 Final report를 제출하여 완료된 것과, 현재 진행되는 것이 있다. 한국에서는 SKT와 ETRI에서 제안하였다. 이 PoC는 먼 상상의 미래가 아닌, 현실 적용이 가능한 근미래의 통신서비스란 관점에서 의미가 있다.

(그림 1)
NFV관점에서의 SDN/NFV 개념도[2]

특히 NFV 문서에서는 (그림 1)과 같이 Software Defined Networking(SDN)/NFV/VIM/WAN Infrastructure Manager(WIM)이 연결된 전체적인 네트워크를 다룬다. NFV/SDN/Cloud에 대한 관련성을 다루는 많은 문헌이 있으나 오픈소스단체가 아닌 유럽 통신 표준화 단체인 ETSI에서 관장하므로 통신 전반적인 면을 총괄해서 다루는 면에서 큰 의미가 있다. 강세를 보이는 오픈소스는 SDN의 경우 ODL과 ONOS이며, VIM은 OpenStack과 VMware이다. WIM이란 지역적으로 분산된 데이터센터 간의 원거리 통신을 담당하는 전송영역 관리자이다[2].

Ⅱ. NFV 핵심개념

NFV의 핵심개념을 이해하기 위해서는 통신망 시뮬레이터에서 노드와 링크가 연결된 그림을 통해 서비스를 제공하는 것을 상상해보자. 전체 네트워크 서비스는 Network Service(NS)이며, 노드는 VNF이고 링크는 VL이다. 전체 그림의 형식적 정보가 VNF이다. 이때 NS와 VNF가 인스턴스화된 SW이므로, 고정 기능만 수행하는 물리통신 기능과 다르게 생성, 변화, 사멸 등의 Life-cycle Management를 사용하게 된다.

전문적인 설명을 하자면, NFV의 주기능은 NS life-cycle management, VNF lifecycle management, Resource management, 성능 및 장애관리 등이다. NS 개념은 일반적인 end-to-end 서비스가 아닌, 단순히 VNF의 기능들로 연결되어 제공되는 서비스를 말한다. 이 이상의 VOD, CDN 등의 애플리케이션을 다루는 일반 문헌의 service orchestrator 혹은 end to end service orchestrator 개념은 NFV 문서범위를 넘어 선다.

(그림 2)
NFV 참조 기능 구조[2]

NFV 참조 기능 구조는 (그림 2)와 같으며 크게 NFV Infrastructure(NFVI), VNF, MANO로 나눌 수 있다. NFVI는 인프라로서 컴퓨팅, 스토리지, 네트워크 기능을 지원하는 물리적 HW자원과 이를 가상화된 하이퍼바이저 같은 SW자원을 제공한다. VNF는 네트워크 기능의 집합으로서 각 벤더가 카타로그로서 등록하며 EM(기존의 자체 관리시스템)을 포함한다. 본고의 관심사인 MANO는 관리평면으로서 좌측의 NFVI, VNF 블록에 대한 관리기능을 NFV Orchestrator, VNF manager, VIM manger로써 제공한다.

네트워크 서비스를 기술하는 방식은 (그림 3)과 같이 NS descriptor(NSD)와 VNF descriptor(VNFD)란 정보요소(Information Element)로 표현된다. 모든 것을 포함하는 NSD에는 VNFFGD, VLD, VNFD 등이 다 들어 있다. 이 중에서 노드 역할을 하는 VNFD와 링크 역할을 하는 VLD를 이용해서 서비스를 고객이 설계할 것이다. VNFD에서는 Virtual Deploy Unit(VDU)가 있어서 디플로이 될 인프라의 HW 파라메터(cpu, memory, PCIe, network)와 SW 파라메터(hypervisor, virtual switch)를 가지고 있다. 클라우드는 하부 인프라를 은닉하는 반면에 NV는 고성능과 High Ability(HA)를 위해 하부 인프라의 세세한 정보를 다 알아야 하는 것이 클라우드와 다른 특징이다. 그 외 lifecyle_event, deployment+flavor, auto_scale_policy, manifest_file 등이 있다. NSD, VNFD는 일종의 디플로이 템플레이트로서 인스턴스를 한 개 이상 만들 수 있다. 이때 각 인스턴스마다 동작하면서 런타임적 속성을 가질 수 있는데 이를 Record란 단어를 붙은 NSR, VNFFGR, VLR, VNFR, PNFR 등의 저장소에서 관리한다.

(그림 3)
NFV에서 사용되는 정보요소 관계도[2]

VNF lifecycle 관리절차는 다음과 같다. VNF가 VNFO를 통해 Catalog에 등록되고, VIM에 의해 VM이 생성된다. 그 후 인스턴스 생성하게 되는데 인증을 받고 VIM으로부터 자원할당을 받는다. 그 후 런타임 되면서 자원변화나 QoS변화, 에러발생 등으로 업데이트가 요구된다. 종료단계에선 VNF 인스턴스를 종료하기 위해 자원과 네트워크를 연결해지한다.

NS lifecycle 관리는 VNF lifecycle을 포함하여 조금 더 복잡하다. NS는 (그림 4)와 같은 서비스 체인을 이룬다. 이른바 VNF FG인데 아직은 여러 이슈(VNF 연결 관계성, 실행 순서, 정보 모델, 동작 의존성, 업데이트 발생 시 처리 등)에 대해 논의 중이다. 상단의 추상적 개념인 Virtual Link가 하단의 물리적 링크로 바뀌는 과정에서 Network Forwarding Path(NFP)란 자원으로 변환된다. VIM이 OpenStack이라면 Neutron의 제어를 통해서 NFP를 제공받는 복잡한 과정을 거칠 것이다. VNF FG에 대해선 기존의 OpenStack이 제공하지 않은 것이어서 OpenStack의 API 확장이 요구된다.

(그림 4)
Service Chaining 개념[2]

절차는 다음과 같다. NSD 기술을 통해서 NS를 정의하여 카탈로그에 등록한다. 그 후 인증을 거치고 요구된 자원을 할당받아 NS 인스턴스를 생성한다. 종료 시에는 NS에 사용되는 모든 자원을 해지하고 카탈로그에서 삭제한다.

III. NFV Orchestrator

MANO 내의 기능 블록은 (그림 2)와 같이 NFV Orchestrator(NFVO), VNF Manager(VNFM), VIM, NS catalogue, VNF catalogue, NFV Instances repository, NFVI resources repository 등으로 구성된다. 특히 NFV 최상위 제어기인 NFV Orchestrator는 OSS/BSS, VNFM, VIM 등과 인터페이스한다. 중심기능은 NS lifecycle 관리가 가장 중요하다고 전술하였다. 여기서는 (그림 5)와 같이 NFVO 주변 모듈기능 및 관계성을 기술하여 NFVO의 특징을 알아보자[3]. 이 작업은 IFA WG에서 일어난다. OpenStack과의 공동 협력을 위한 NFVO-VIM의 규격작업이 IFA005에서 일어나는데 완성도가 높다. 복잡한 상황이 있는 VNFM 관련 규격작업인 IFA007과 IFA006은 상대적으로 느린 편이다.

(그림 5)
NVF-MANO 블록과 인터페이스[3]

1. NFVO

VNVO의 중심기능은 NS lifecycle 관리로서 NSD 템플레이트 관리(등록, 수정, 삭제, 활성화, 비활성화, 질의 등)와 NS 인스턴스 관리(생성, 스케일링, 업데이트, 종료 등)이다. 상단에는 OSS/BSS 혹은 GUI와 인터페이스하고, 하단에는 VNFM, VIM을 제어한다. IFA005를 통해서 OpenStack의 API가 확장된다. VIM과 동격으로 WIM도 관장할 수 있다.

2. OSS/BSS 연관성

NFV-MANO 자체가 NFV의 비즈니스 이점을 살리지 못한다. 네트워크 기능 이상의 비즈니스 애플리케이션을 위해서는 OSS/BSS 인터페이스를 통해서 end-to-end 서비스를 해야 한다. 응용 애플리케이션을 구현하기 위해선 반드시 전체망 관점에서 OSS/BSS와 통합하여 설계해야 한다. 이를 위해 개방적인 인터페이스, 상황에 맞는 자동화, 정책 기반의 운영, 개인화된 맞춤형 서비스가 요구된다. 이것은 MANO 문서 이외의 영역이다. 그러나 5G와 IoT와 관련된 신규 서비스 제공을 위해서 꼭 필요하다.

3. VNFM

VNFM의 중심기능은 VNF lifecycle 관리로서 VNF 인스턴스 생성, 확장, 업데이트 및 업그레이드, 종료 등이다. 수많은 기존의 네트워크 기능들을 카탈로그화해야 한다. 그 개수가 얼마 안 되면 특정 VNF와 특정 VNFM 간에 밀접한 연관이 있겠지만 수많은 VNF를 관리하려면 일반적(generic) VNFM이 필요하다. VNF와 VNFM 간의 의존성, 멀티 벤더의 상호호환성 등이 이슈이다. 이 외에 전통적인 관리기능인 FCAPS 기능을 해야 한다. 이것은 Fault(장애), Configuration(설치), Accounting(요금), Performance(성능), Security(보안) 를 의미한다.

4. VIM

VIM은 사실상 NFV영역이 아닌 클라우드 영역이다. VIM의 강력한 후보는 디 팩토 표준인 OpenStack이다. OpenStack은 NFV 산하 단체가 아닌 독립된 오픈소스 단체이기에 서로 협력이 필요하다. VNFO와 인터페이스하기 위해 기존 OpenStack의 API뿐 아니라, NFP 관련 API 확장이 필요하다. Forwarding Graph를 통해 service chaining하기 위한 것은 기존 클라우드에 없기 때문이다. NFVO를 통해서만이 아니라 VNFM을 통해서도 제어받는데 상대적으로 규격작업이 느리다. 기존 클라우드와는 달리 네트워크 서비스는 하드웨어 성능이 우수해야 하고, 고가용성이 보장되어야 한다. 이는 네트워크 기능강화, 자원예약 가능, 모니터링 강화, 베어메탈 프로비저닝에 대한 강화를 의미한다.

그래서 OpenStack에서는 4개의 프로젝트가 진행되고 있다. Snabb NFV를 통해 Neutron기능을 강화를, Climate를 통해 가상 머신과 물리 리소스 예약을 담당하고, Ceilometer를 통해 모니터링 기능을 강화한다. Ironic은 가상머신 방식이 아닌 베어메탈 프로비저닝을 통해 성능을 향상시키고자 한다.

IV. Orchestrator 제품들

제품 조사한 것은 3개이다. Cyans사의 Blue Planet, HP사의 director, Ericson사와 제휴한 Cortx Service Orchestrator란 제품이다. <표 1>에 서로 비교하였다.

<표 1>
Orchestrator 제품 비교

1. Cyans사

Cyans사는 Blue Planet는 통신 사업자와 WAN을 위해 최초의 carrier-grade SDN/NFV 플랫폼을 출시했다. 레거시 네트워크를 포함한 전체 망에 대해서 end-to-end deployment되는 것을 단순화시킨 특징이 있다. 또한, 멀티 벤더, 멀티 도메인의 네트워크 환경에서 Open API를 사용하여 프로그램 가능한 시스템을 제공한다. Blue Planet Applications으로는 orchestration 역할을 하는 Planet Orchestrate, MNS 관련한 Planet Operate, SLA관련한 Planet View, 네트워크 확충을 고려한 플랜 툴인 Planet Design, 성능과 RIO 그리고 자산 관련한 Planet inventory 등이 있다. NFV World Congress에 3가지 시나리오를 출품했다[(그림 6) 참조][4].

(그림 6)
Cyan사의 End-to-End View[[5]

2. HP사

P사의 Director는 NFV ETSI에 가장 충실한 전략을 취하고 있다. 원래부터 IT 선두 벤더였고, 인프라 제품을 공급해왔고, 독창적인 제품보다는 오픈스택 커뮤니티에 기여할 수 있는 전략을 택해왔다[(그림 7) 참조].

(그림 7)
HP사의 Director[[6]

3. Ericsson사

Ericsson은 2015년 6월에 가상 네트워크를 위한 서비스 오케스트레이션 솔루션 업체인 CENX사와의 제휴를 통해 자사의 ‘Cortex Service Orchestrator’를 에릭슨의 글로벌 관리 버시스 전달 플랫폼의 주요 컴포넌트로 활용하게 됐다. 이것은 Metro Ethernet Forum(MEF) 내용을 준용한다고 한다[(그림 8) 참조][7].

(그림 8)
Ericsson사의 Orchestrator 제품[[7]

4. Telefonica사

Openmano는 Telefonica사에서 출시하였는데 NFV의 상단인 orchestrator를 다루고 있다. 벤더 중립적인 입장에서 VNF를 쉽게 개발하고 테스트하는 것을 목적으로 하고 있다. VNF들의 연결을 수동으로 하는 것이 비실용적이라는 것을 느낀 후 2009년 이후로 개발해왔다고 한다. OPNFV는 하단의 OpenStack과 연관된 인프라에 포커싱하고 있으나 Openmano는 NFV의 최상위를 담당한다[(그림 9) 참조].

(그림 9)
Telefornica 사의 Openmano[[8]

V. Openmano 분석

(그림 10)과 같이 Openmano의 주요 모듈은 openmanod, openmano-gui, openvimd 등 3개이다. 또한, Openvim과 openmano에 대한 값을 입력할 수 있는 2개의 command line 클라이언트를 가지고 있다. Openvim에 의해 외부 컴포넌트(compute nodes, Open Flow switch, image storage)를 제어한다. Floodlight라는 OpenFlow controller를 통해서 switch를 간접 제어한다.

(그림 10)
Openmano의 구조[[9]

시스템 요구사항은 다소 강한 편인데 최소 서버 2대가 필요하다. 한대는 controller node용이고 나머지는 compute node용이다. Controller node용에 언급한 3개의 모듈이 모두 들어있다. Compute node는 Centos 7.0 혹은 Ubuntu 14.04 버전을 사용하고, KVM를 가진 64비트 OS, qemu와 libvirt를 만족해야 한다. Test mode가 아니고 full NFV를 셋업한다면 compute node는 SR-IOV 용량의 10GE를 가져야 한다(예, Intel X520 NIC). Openflow switch도 10GE 인터페이스가 요구된다.

설치하는 방식은 Linux, Apache server, Mysql DB, PHP(LAMP)의 전형적인 구조로 이루어졌다. 설치된 SW들을 보면 데이터모델은 YAML, JSON 등이고, DB는 MySQL, 웹서버는 bottle을 사용하고 가상화 관리 툴로서는 libvert를 사용한다. Bottle은 파이썬을 위한 WSGI 마이크로 웹-프레임워크인데 빠르고, 간단하고, 가벼운 특징을 지닌다. Libvert는 플랫폼 가상화를 관리하기 위한 오픈소스 API 데몬 관리 도구이다. Github를 통해서 프로그램을 다운받는다.

1. 소스 구조

전체 폴드 구조는 docs, images, openmano, openmano-gui, opemvim, scripts로 구성되어 있다. 이것은 openmano, openmano-gui, openvim 구성으로서 VNFM이 없는 NFV 기본모델의 약식 구조를 가진다. Openmano는 NS와 VNF의 가장 기본적인 Lifecycle management 정도만 구현했다. Openvim은 OpenStack을 사용하지 않고 LAMP로 구성하였다. 후에는 OpenStack으로 전환할 것으로 로드맵에 있다.

2. openmano-gui 분석

Openmano-gui의 경우, GUI를 구성하는 부분으로서 <표 2>와 같이 웹 디자인의 전형적인 패턴인 Java script, css, PHP, html 등으로 디자인되었다. Ajax 기법을 사용하는 데에 google api를 사용한 Jquery 라이브러리를 사용하였다. 확장자별 파일은 다음과 같다. OpenStack이 python 단일언어로 짜여진 것과는 다름을 알 수 있다.

<표 2>
Openmano 확장자별 파일

Index.html이 연결되어 바로 리다이렉션되어 scenario.php로 나타난다. 여기에서 분할된 화면마다 나타나는 시나리오 혹은 VNF 관련 버튼마다의 이벤트 실행이 scenario.php, vnfs.php, physical.php로 실행된다. 최초 화면의 탭에 나타난 이름은 Scenarios, VNFs, Physical 등이고 combo 박스로서 Datacenter1, Data-center2 등이 있다. <표 3>에 나오는 버튼들의 이름을 나열해보았다. 이는 Lifecycle management하는 수준을 파악할 수 있다.

<표 3>
Openmano Lifecycle 요소들

3. openmano 분석

Openmano는 형태적으로 웹 서버, 애플리케이션 서버, DB 서버의 3단 구조를 본 따서 bottle 웹 서버, NFVO 엔진 모듈, NFVO DB 모듈로 나눌 수 있다. 여기에 따라서 관련 파일을 나열하면 <표 4>와 같다.

<표 4>
Openmano 주요 파일들

NFVO를 구현한 Openmano 서버가 Openmanod.py에 main 함수 형태로 있다. openmanod.cfg란 설정 파일을 로딩하여 웹서버(httpserver.py)를 구동한다. 이 모듈에서 클라이언트 측의 GET, POST 등의 API 요청에 응답하게 된다. 각 API에 대한 NFVO 구현 엔진이 nfvo.py에 있어서 VNF와 시나리오에 대해서 라이프 사이클 관리를 한다. 하부 인프라까지의 API가 필요한 기능에 대해서는 vimconnector.py의 클래스 vimconnector를 통해서 openvim API를 이용하게 된다. API 요청 시 사용되는 스키마에 대한 것을 openmano_ schema.py에서 체크한다. DB는 NFVO DB 엔진은 nfvo_db.py에 있다. NS와 VNF에 관한 api는 <표 5>와 같다.

<표 5>
openmano API

4. openvim 분석

Openvimd.py에 main 함수 형태가 있다. <표 6>과 같이 실행되어 웹 서버로 동작한다.

<표 6>
실행 순서

현재는<표 7>과 같은 openvim API를 이용하여 OpenStack 보다는 Host에 가상머신을 생성하여 사용하는 방식을 택하였다. 후에 OpenStack으로 대체할 것이다. 따라서 VM을 생성하는 OpenStack과 비슷하게 tenants, flavors, images, instance 생성, 사멸에 관한 api가 있다. Network에 대해선 network와 port는 있어도 subnet이 없고, 계층2 네트워크여서 IP 주소 관리가 없다. 컴퓨터 노드 간에는 bridge 통신을 한다. OpenStack처럼 Nova network 혹은 Neutron network를 사용하지 않음은 물론이다. Port 정보를 보면 완성도를 알 수 있는데 name, id, tenant_id, device_id, device_owner, bandwidth(option), binding(option)이 있다. 외부 네트워크와 인터페이스를 위한 external ports도 있는데 내부 port 파라메터와 비슷하다.

<표 7>
openvim API

VI. 결론

Cyan Blue Planet가 가장 상업적 목적에 부합한 Orchestrator로 생각된다. 이에 비해 HP는 NFV 규격과 그 오픈소스 생태계에 기여하려는 의도가 강하다. Openmano는 간단 명료하지만 기본적 기능을 잘 보여준다. 본디 Orchestrator는 통신사 전용 맞춤형 성격이 있어서 주목받지 못하는 실정이었다. 그러나 NFV 이점을 누리기 위해서는 OSS/BSS와 end-to-end Service Orchestrator와 연계해야 된다. 여기에 NFV orches-trator의 중요성이 있다.

약어 정리

CAPEX

Capital Expenditure

DPI

Deep Packet Inspection

EMS

Element Management System

EPC

Evolved Packet Core

HA

High Ability

IMS

IP Multimedia System

ISG

Industry Specification Group

LAMP

Linux, Apache server, Mysql DB, PHP

MANO

Management and Orchestration

MEF

Metro Ethernet Forum

NFP

Network Forwarding Path

NFV

Network Function Virtualization

NFVI

NFV Infrastructure

NFVO

NFV Orchestrator

NOC

Network Operators Council

NS

Network Service

NSD

NS descriptor

PoC

Proof of Concepts

SDN

Software Defined Networking

STB

Set Top Box

VDU

Virtual Deploy Unit

VNF

Virtual Network Function

VNFD

VNF descriptor

VNFFG

VNF Forwarding Graph

VNFM

VNF Manager

WIM

WAN Infrastructure Manager

References

[1] 이종화, “ETSI NFV Phase-2 표준화 동향,”TTA J., 제 157권, 2015, pp. 47-53.
[2] ETSI ISG, “NFV; Management and Orchestration,” GS NFV-MAN 001 v1.1.1, Dec. 2014.
[3] NFV, “IFA WG Work Plan at a Glance,” 발표자료.
[4] http://www.cyaninc.com/products/blue-planet-sdn-platform
[5] Cyan, “Decoding the Management & Orchestration Architecture for NFV,” Feb. 2014.
[6] HP, “Realizing virtualization HP delivers NFV or-chestration,” Solution overview, 2014.
[7] http://www.cenx.com/cortx-service-orchestrator/
[8] https://www.youtube.com/watch?v=5Szc-VGDhi4
[9] https://github.com/nfvlabs/openmano/wiki/Getting-started

(그림 1)

f001

NFV관점에서의 SDN/NFV 개념도<a href="#r002">[2]</a>

(그림 2)

f002

NFV 참조 기능 구조<a href="#r002">[2]</a>

(그림 3)

f003

NFV에서 사용되는 정보요소 관계도<a href="#r002">[2]</a>

(그림 4)

f004

Service Chaining 개념<a href="#r002">[2]</a>

(그림 5)

f005

NVF-MANO 블록과 인터페이스<a href="#r003">[3]</a>

<표 1>

t001

Orchestrator 제품 비교

(그림 6)

f006

Cyan사의 End-to-End View[<a href="#r005">[5]</a>

(그림 7)

f007

HP사의 Director[<a href="#r006">[6]</a>

(그림 8)

f008

Ericsson사의 Orchestrator 제품[<a href="#r007">[7]</a>

(그림 9)

f009

Telefornica 사의 Openmano[<a href="#r008">[8]</a>

(그림 10)

f010

Openmano의 구조[<a href="#r009">[9]</a>

<표 2>

t002

Openmano 확장자별 파일

<표 3>

t003

Openmano Lifecycle 요소들

<표 4>

t004

Openmano 주요 파일들

<표 5>

t005

openmano API

<표 6>

t006

실행 순서

<표 7>

t007

openvim API