OPNFV 프로젝트 특징 및 ARNO 배포판 분석

일반적으로 NFV 플랫폼에 대해 통신사업자와 같은 사용자들은 강건(robust)하면서도 유연한 솔루션을 기대하지만, NFV 플랫폼의 구조적 특성상 다양한 이종의 솔루션이 복잡하게 연계되어 구성되어야 하므로 이들 이종 솔루션을 하나의 시스템으로 통합하는 일은 만만치 않다. 따라서 OPNFV 프로젝트는 무엇보다도 커뮤니티 주도로 NFV 플랫폼에 대한 시스템 통합에 초점을 두고 있다.

따라서 OPNFV 프로젝트의 결과물인 NFV 참조 플랫폼은 다양한 방법으로 사용될 수 있다[4]. 첫째, NFV 솔루션을 설치하고 시험검증하며 구축할 때 참조할 수 있는 구성요소(reference building block)로서 활용할 수 있다. 둘째, 자신만의 활용 목적에 맞는 시스템 통합을 위한 참조 시스템 통합(reference system integration)으로서 활용될 수 있다. 셋째, 개별적으로 또는 OPNFV 커뮤니티의 부분으로서 NFV를 추가 개발하기 위한 기반(foundation) 솔루션으로써 활용될 수 있다. 요컨대, OPNFV의 결과물은 그 자체가 하나의 NFV 종합 솔루션을 제공하는 것을 지향하기보다는 다양한 유스케이스(usecases)와 서비스 특성에 맞는 NFV 솔루션을 각자 개발할 수 있는 참조 플랫폼을 지향한다.

OPNFV 프로젝트는 통신장비 수준의 NFV 참조 플랫폼 개발을 위해 공개 소프트웨어 프로젝트를 적극적으로 활용할 계획이다. 이를 좀 더 세분화하여 살펴보면, 기존의 공개 소프트웨어 프로젝트를 활용하는 방안, 새로운 공개 소프트웨어 프로젝트를 출범시키고 이를 활용하는 방안, 그리고 자체 코드 베이스를 유지하는 방안으로 구분할 수 있다.

먼저 OPNFV 프로젝트는 가능한 현존하는 공개 소프트웨어 프로젝트를 최대한 적극 활용하는 것이 주된 개발전략이다. 우선 현존하는 NFV 관련 공개 소프트웨어 프로젝트를 식별한 다음, OPNFV 기술위원회(Technical Steering Committee: TSC)의 기술 검토를 거쳐 선정한다. 선정된 각 프로젝트에 대해서 NFV 플랫폼으로써 제공해야 할 기능 및 성능 요구사항에 대비하여 어떤 격차(gap)를 가졌는지를 분석하고, 프로젝트별로 필요한 기능개선이나 수정과 관련된 요구사항을 도출한다. 이렇게 정리된 요구사항은 각 공개 소프트웨어 프로젝트에 전달되어 반영될 수도 있으며, 또는 OPNFV 프로젝트에서 직접 소스코드를 개발하여 해당 프로젝트에 기여하는 방안도 고려할 수 있다.

만일 NFV 플랫폼의 주요 기능에 대한 공개 소프트웨어 프로젝트가 아직 존재하지 않는 경우에는 OPNFV 차원에서 새로운 공개 소프트웨어 프로젝트를 출범시키고, 이 프로젝트를 통해 관련 기능에 대한 소프트웨어를 구현한 다음, OPNFV 프로젝트에서 활용하는 방안도 함께 고려하고 있다.

그러나 모든 NFV 관련 기능이 기존 공개 소프트웨어 프로젝트의 범주에 포함되거나 또는 별도의 독립적인 공개 소프트웨어 프로젝트로 운용되는 것이 바람직하지 않을 수도 있다. 이러한 경우에는 별도의 공개 소프트웨어 프로젝트와 연계하지 않고, OPNFV 프로젝트에서 자체적으로 관련 기능을 구현하고 이를 자체 코드베이스로 유지 관리하는 방법도 포함될 수 있다.

OPNFV 개발전략을 실현하기 위해 OPNFV 프로젝트는 OPNFV 내에서 진행되는 개별 하부 프로젝트의 범주를 다음과 같이 크게 4가지로 구분하고 있다.

- 요구사항 프로젝트

- 통합 및 검증 프로젝트

- 협력개발 프로젝트

- 문서화 프로젝트

요구사항 프로젝트(Requirements Projects)는 OPNFV에서 추구하는 통신장비 수준의 NFV 참조 플랫폼 개발을 위해 필요한 요구사항을 수집하고 이를 문서화하는 것을 목적으로 활동하는 프로젝트이다. 예를 들어, OpenStack과 같은 대표적인 공개 소프트웨어 프로젝트는 NFV 환경이 아닌 일반적인 클라우드를 관리하기 위해 개발된 것이기 때문에, NFV의 VIM으로 활용되기 위해서는 새롭게 개발되거나 격차를 해소해야 할 기능들이 존재한다. 따라서 이와 같은 기능을 식별하고 정리하는 것이 요구사항 프로젝트의 목적이다.

통합 및 검증 프로젝트(Integration and Testing Projects)는 OPNFV 참조 플랫폼 개발과 관련하여 지속적인 통합(Continuous Integration)과 시험검증 그리고 관련 도구의 개발에 초점을 둔 프로젝트로서, 다수의 공개 소프트웨어 프로젝트 등과 관련될 수 있다. 특히, OPNFV 프로젝트가 다양한 공개 소프트웨어를 통합하여 상호 운용성과 성능을 검증한 참조 플랫폼을 개발하기로 한 만큼, 통합 및 검증 프로젝트에 속하는 개별 프로젝트는 OPNFV의 핵심인 시스템 통합과 관련된 프로젝트가 포함된다.

협력개발 프로젝트(Collaborative Development Projects)는 기존 공개 소프트웨어 프로젝트, 관련 업계의 포럼 및 프로젝트, 또는 표준화 단체 등과의 실질적인 협력개발을 위한 프로젝트이다.

마지막으로 문서화 프로젝트(Documentation Projects)는 OPNFV와 관련된 다양한 문서의 작성 및 관련 도구의 개발에 초점을 둔 프로젝트이다.

OPNFV 프로젝트는 OPNFV에서 추진하는 개별 프로젝트에 대한 개발 생명주기(lifecycle)를 (그림 1)과 같이 제안(proposal), 육성(incubation), 성숙(mature), 통합(integration), 최상위(top-level), 종료(archived)의 6가지 상태로 구분하여 정의하고 있다.

(그림 1)

OPNFV 프로젝트 생명주기[1]

먼저 제안단계는 아직 프로젝트가 실제 존재하지는 않지만, 필요에 의해 프로젝트가 공식적으로 기술위원회에 제안된 단계를 뜻한다. OPNFV의 프로젝트 제안 요건에 따라 작성된 제안서는 최소 2주 간의 공지기간이 경과한 다음, 기술위원회의 생성 검토(creation review) 회의를 통해 승인 여부를 결정한다.

생성이 승인된 프로젝트는 육성단계로서, 자원이 투입되어 프로젝트가 진행 중이지만 아직 초기단계인 경우이다. 육성단계의 프로젝트는 기술위원회에서 정의한 프로젝트 범주별 지표에 맞는 결과물을 입증할 수 있고, 프로젝트의 커뮤니티가 활동 중이며, 배포정책에 따라 결과물을 배포한 이력이 있다면 기술위원회의 검토(graduation review)를 거친 후 성숙단계로 진입할 수 있다. 다음 절에서 소개하는 OPNFV의 하부 프로젝트는 프로젝트 출범초기인 만큼 모두 육성단계에 속한다.

성숙단계는 프로젝트가 안정적으로 수행되며 성공적으로 결과물을 배포하고 있는 단계를 의미한다. 성숙단계에 있는 프로젝트는 통합검토(integration review)를 거쳐 통합단계로 발전하거나 승격검토(elevation review)를 거친 다음 최상위 단계로 전이할 수도 있다.

통합 단계는 프로젝트 결과물이 OPNFV 참조 플랫폼을 구성하는 요소로서 인정된 단계로서, OPNFV 프로젝트의 핵심 결과물을 의미한다.

최상위 단계는 성숙단계뿐만 아니라 통합단계에서도 기술위원회의 승격검토를 거쳐 도달할 수 있다. 어떤 프로젝트가 최상위 단계라는 것은 OPNFV의 핵심속성을 대변하면서 커뮤니티에서 널리 수용되는 프로젝트로서, 프로젝트가 장기적으로 운용되는 단계를 의미한다. 최상위 단계에는 최소 4개 이상의 개별 프로젝트로 구성이 되는데, OPNFV 프로젝트 범주별로 각각 최소 하나의 프로젝트는 최상위 단계에 포함될 예정이다.

마지막으로 종료단계는 프로젝트가 예정된 목표를 완수했거나 실패하는 등 다양한 이유로 인해 개별 프로젝트가 더 이상 유지될 필요가 없어 사실상 종료 또는 폐기되는 단계를 뜻한다. 따라서, 종료단계는 프로젝트가 앞서 소개한 5개의 상태 중 어떤 상태에서든 기술위원회의 종료검토(termination review)를 통해 결정될 수 있다.

본 절에서는 2015년 6월, 현재까지 OPNFV 프로젝트에서 제안이 승인되어 진행 중인 하부 프로젝트에 대해 프로젝트 범주별로 간략하게 소개하기로 한다.

가. 요구사항 프로젝트

1) Doctor: Fault Management

Doctor 프로젝트는 가상 인프라 상에서 운용되는 네트워크 서비스의 고가용성을 보장하기 위해 결함을 관리하고 시스템을 유지하는 프레임워크를 수립하는 프로젝트이다. 현재 초기버전의 요구사항 및 구조설계를 마무리하고 OpenStack Nova와 Ceilometer 프로젝트에 기능 개선 요구사항을 제기하고 있다.

2) Copper: Virtualized Infrastructure Deployment Policies

Copper 프로젝트는 Virtual Network Function(VNF)의 속성에 따라 정책 기반으로 가상 인프라를 구성하여 제공하는 기술에 대한 것이다. 이와 관련된 기존 공개 소프트웨어 프로젝트로는 OpenStack Congress 프로젝트와 OpenDaylight의 Group-based Policy(GBP) 프로젝트가 있다.

3) Promise: Resource Management

Promise 프로젝트는 나중에 사용할 목적으로 자원을 예약하거나 자원 용량(capacity)을 관리하는 기술에 관한 프로젝트이다. OpenStack Blazar 프로젝트가 관련 프로젝트로서 고려되고 있다.

4) Availiability: High Availability

Availability 프로젝트는 통신장비 수준의 고가용성을 제공하기 위해 하드웨어, 가상 인프라 및 서비스 고가용성에 대한 요구사항 개발에 초점을 두고 있다.

5) DPACC: Data Plane Acceleration

DPACC 프로젝트는 VNF 데이터평면 가속화와 관련하여 가속화 기술의 적용여부나 종류와 무관하게 VNF의 이식성(portability)을 보장하기 위한 프레임워크 및 인터페이스 정의에 초점을 두고 있다.

6) VNFFG: OpenStack Based VNF Forwarding Graph

VNFFG 프로젝트는 OpenStack 기반의 솔루션 환경에서 VNF Forwarding Graph을 통해 종단 간 네트워크 서비스를 제공하는 프레임워크에 관한 프로젝트이다.

7) Prediction: Data Collection for Failure Prediction

Prediction 프로젝트는 예기치 못한 NFV 시스템 고장을 미연에 방지하기 위해 데이터를 수집하며, 고장을 예측하고 관리하는 고장 예측 시스템에 관한 것이다.

8) RS: Resource Scheduler

RS 프로젝트는 VNF의 속성상 CPU나 메모리뿐만 아니라 네트워크에 대한 정보도 추가로 수집하여 자원 스케줄링에 활용하기 위한 프로젝트이다.

8) RS: Resource Scheduler

RS 프로젝트는 VNF의 속성상 CPU나 메모리뿐만 아니라 네트워크에 대한 정보도 추가로 수집하여 자원 스케줄링에 활용하기 위한 프로젝트이다.

9) Movie: Model Oriented Virtualization Interface

Movie 프로젝트는 NFV Orchestrator와 VNFM(VNF Manager)를 위한 VIM의 추상화된 상단 인터페이스(north-bound interface)를 제공하기 위한 것으로서, 모델 기반 구조(Model Driven Architecture)의 접근방법을 따른다.

11) Escalator: Smooth Upgrade

Escalator 프로젝트는 서비스 중단없이 NFVI 또는 VIM의 소프트웨어를 원활하게 업그레이드하기 위한 요구사항 도출을 목표로 한다.

나. 통합 및 검증 프로젝트

1) Octopus: Continuous Integration

Octopus 프로젝트는 Jenkins를 기반으로 NFV와 관련된 다양한 공개 소프트웨어 프로젝트를 통합하고 검증하며 자동으로 패키지를 빌드하는 일련의 지속적인 통합을 수행하는 프로젝트이다.

2) BGS: Bootstrap/Get-Started

BGS 프로젝트는 공개 소프트웨어 프로젝트를 이용하여 단기간 내에 예제 VNF를 실행해 볼 수 있는 최소한의 기본적인 NFV 인프라 환경을 구성하고 이를 검증하는 프로젝트이다. 사실상 OPNFV 프로젝트의 초기활동은 거의 BGS 프로젝트에 초점이 맞추어져 있으며, 다음 장에서 소개할 ARNO 배포판도 BGS 프로젝트의 결과를 기반으로 하고 있다.

3) IPv6-enabled OPNFV

이 프로젝트는 IPv6가 지원되는 OPNFV 플랫폼을 설치할 수 있는 통합 패키지 제공을 목표로 한다.

4) VSPERF: Characterize vSwitch Performance for Telco NFV Use Cases

VSPERF 프로젝트는 통신사업자의 NFV 구축환경에서 서로 다른 다양한 가상 스위치를 시험하고 검증할 수 있는 프레임워크 개발에 초점을 두고 있다.

5) OSCAR: OPNFV System Configuration and Reporting

OSCAR 프로젝트는 공개 소프트웨어인 Cobbler/ Puppet을 기반으로 OPNFV 플랫폼 및 가상 인프라를 자동으로 설치하고 설정하기 위한 구축 시스템을 개발하는 프로젝트이다.

6) Pharos: Testbed Infrastructure

Pharos 프로젝트는 OPNFV 커뮤니티 회원사가 제공하는 지리적으로 분산된 연합시험 환경(fede-rated test labs)을 구축하고 제공하는 프로젝트이다. 각 시험환경은 OPNFV 하드웨어 참조 규격에 따라 구축되며, 이를 통해 OPNFV 플랫폼을 설치하고 검증할 수 있다.

7) FuncTest: Base System Functionality Testing

FuncTest 프로젝트는 OPNFV 플랫폼의 기능을 시험하고 검증하기 위한 시험방법, 시험도구 및 시험항목을 개발하고 시험을 수행하는 프로젝트이다.

8) Qtip: Platform Performance Benchmarking

Qtip 프로젝트는 OPNFV 플랫폼에 대한 벤치마킹을 수행하고, 시험검증 및 벤치마킹을 위한 도구를 제공하기 위한 프로젝트이다.

9) Parser: Deployment Template Translation

Parser 프로젝트는 NFV에서 사용되는 다양한 템플릿과 관련하여 통신사업자가 사용하는 템플릿 양식을 TOSCA(Topology and Orchestration Specification for Cloud)/CAMP(Cloud Application Management for Platforms)로 변환하고, 이를 다시 OpenStack Heat Template과 같은 일반적인 VIM 템플릿으로 변환하는 것을 목표로 한다.

10) Yardstick: Infrastructure Verification

Escalator 프로젝트는 서비스 중단없이 NFV 인프라가 제공할 수 있는지를 검증하기 위한 프로젝트 이다.

다. 협력개발 프로젝트

1) Software Fastpath Service Quality Metrics

본 프로젝트는 VNF가 사용할 수 있는 Fastpath를 생성한 다음, 이를 통한 트래픽의 성능을 측정하고, 필요시 VNF나 EM(Element Management)에게 통지하는 유틸리티와 라이브러리를 개발하는 프로젝트이다.

2) ONOSFW: ONOS Framework

ONOSFW 프로젝트는 VIM의 SDN(Software-Defined Networking) 컨트롤러로서 ONOS(Open Network Operating System)을 사용할 수 있도록 관련 프레임워크나 라이브러리 등을 개발하는 프로젝트이다.

라. 문서화 프로젝트

OPNFV Documentation 프로젝트는 OPNFV 배포판에 대한 릴리즈 노트, 설치 가이드, 사용자 가이드 등의 각종 문서를 개발하는 프로젝트이다.

이상과 같이 현재 OPNFV 프로젝트는 20개 이상의 프로젝트가 승인되어 활동하고 있으며, 앞으로도 필요에 따라 다양한 프로젝트가 제안되고 추진될 것으로 예상된다. 개별 프로젝트별로 중점적으로 개발하는 목적이나 성격은 조금씩 다를 수 있지만, 이들 개별 프로젝트의 연관관계를 도식화하면 (그림 2)와 같다.

(그림 2)

OPNFV 프로젝트의 관계 흐름[5]

먼저 개발단계에서는 통신장비 수준의 NFV 플랫폼 개발을 위해 Doctor를 포함한 다양한 요구사항 프로젝트가 진행된다. 요구사항 프로젝트에서 도출된 기능개선 요구사항은 OpenStack, OpenDaylight 등과 같은 원천공개 소프트웨어 프로젝트에 전달된다.

지속적인 통합단계에서는 Octopus 프로젝트 등을 통해 선정된 원천공개 소프트웨어 프로젝트의 결과물을 상호 통합하고 검증한 다음, 빌드과정을 거쳐 NFV 플랫폼을 구축할 수 있는 이미지와 패키지로 생성된다.

플랫폼 구축단계에서는 NFV 플랫폼 이미지와 패키지를 설치하고 설정하기 위한 스크립트 등을 OSCAR 프로젝트 등을 통해 생성한다. 이때 NFV 플랫폼은 Pharos 시험검증 환경이나 이와 호환되는 인프라 환경에 구축될 수 있다.

응용 구축단계에서는 Pharos 시험검증 환경에 구축된 NFV 플랫폼을 대상으로 FuncTest, Qtip, VSPERF 등의 시험검증 프로젝트를 통해 플랫폼 시험검증, 하드웨어 시험검증, VNF 시험검증, 성능 시험검증 등을 수행한다.

OPNFV 프로젝트는 공식 배포판 발표에 앞서 배포판 코드명을 알파벳 순서의 강 이름으로 결정하고, 첫 번째 배포판의 코드명은 투표를 통해 이탈리아 중부에 위치한 ARNO 강으로 결정하였다.

OPNFV 프로젝트의 출발점은 실제 VNF를 실행하고 운용할 수 있는 최소한의 NFVI와 VIM으로 이루어진 기본 인프라를 기존 공개 소프트웨어 프로젝트를 활용하여 단기간 내에 구성하고, 이를 OPNFV 검증환경인 Pharos 환경에서 구축하고 검증하는 것이다. 이를 위해 OPNFV 프로젝트가 출범한 지 약 6개월 정도가 경과한 4월 23일을 첫 번째 배포판의 발표예정일로 계획하고 있었으나, 통합검증 지연으로 인해 한 달여 경과한 지난 6월 4일에 ARNO를 공식 발표하였다. ARNO 배포판의 개발목적을 가장 충실히 담고 있는 OPNFV 프로젝트는 바로 BGS 프로젝트이다. 따라서 사실상 ARNO 배포판은 BGS 프로젝트의 결과물이 중심이 된 것으로 볼 수 있다.

OPNFV ARNO 배포판의 구성은 (그림 3)과 같다. (그림 3)의 왼쪽은 ETSI의 NFV 참조구조를 기준으로 ARNO 배포판에 포함된 공개 소프트웨어 프로젝트를 나타내고 있으며, 그림의 오른쪽은 OPNFV 프로젝트의 활동을 기준으로 ARNO 배포판에 포함된 OPNFV 하부 프로젝트를 나타낸다.

(그림 3)

OPNFV ARNO 배포판의 구성[6]

OPNFV 프로젝트에서 수행 중인 개별 프로젝트 중에서는 통합 및 검증 프로젝트 범주의 BGS, FuncTest, Octopus 프로젝트가 포함되었고, ARNO 배포판에 대한 설치 가이드 등을 제공할 문서화 프로젝트가 포함되었다. 단, 통신장비 수준의 NFV 플랫폼 개발을 위해 현재 클라우드 환경에 초점을 맞춘 원천공개 소프트웨어 프로젝트에 대한 격차(gap)를 분석하고 요구사항을 도출하는 OPNFV 요구사항 프로젝트 범주의 프로젝트는 ARNO 배포판에 포함되지는 않았다.

ARNO 배포판에 포함된 원천공개 소프트웨어 프로젝트는 (그림 3)의 왼쪽과 같다. 먼저 ARNO 배포판에서는 인프라를 구성하는 서버의 운영체제로서 CentOS 7.0과 Ubuntu 14.04를 채택하였으며, 가능한 CentOS 7.0을 기본 운영체제로 고려하고 있다.

VIM으로는 OpenStack Juno 배포판이 선정되었으며, 서버 가상화를 위한 하이퍼바이저는 KVM(Kernel-based Virtual Machine) 을, 가상 스토리지 서비스는 Ceph 프로젝트를, SDN 제어는 Open Daylight Helium SR2를, 가상 스위치는 OVS(Open vSwitch) 2.3.0을 선택하였다. 따라서 이상의 공개 소프트웨어 프로젝트를 이용하여 ARNO 배포판의 NFVI와 VIM을 구성한다.

OPNFV 프로젝트에서는 NFV 플랫폼이 최소한의 성능을 보장하도록 베어메탈(baremetal) 서버에 구축하도록 권장하고 있다. 따라서 하나의 NFV 플랫폼을 구축하고 검증하며 운용하기 위해 (그림 4)와 같이 최소한 6대의 독립된 서버로 구성된 환경을 권장한다.

(그림 4)

OPNFV 하드웨어 구성[4]

먼저 제어 노드는 NFV 플랫폼에서 OpenStack과 OpenDaylight와 같은 VIM이 설치되는 서버로서, 고가용 클러스터 구성을 위해 최소 3대의 서버로 구성하도록 권장한다. VNF가 운용될 컴퓨트 노드는 서로 다른 물리 서버에 존재하는 VNF 간의 통신 등을 보장하고 검증할 수 있도록 최소 2대의 서버로 구성하도록 한다. 마지막으로 NFV 플랫폼을 설치하고 시험검증을 수행하기 위한 노드로서 Jumphost 서버 1대를 별도로 구성하며, 사용자는 외부망을 통해 Jumphost 서버에 접근할 수 있다.

Jumphost의 시스템 설치용 가상머신은 자체 DHCP (Dynamic Host Configuration Protocol) 서버를 갖고 서브넷에 대한 DHCP 서비스를 제공하므로, 별도의 DHCP 서버를 구성할 필요는 없다. 다만, 서버의 상태와 무관하게 IPMI(Intelligent Platform Management Interface) 또는 PXE(Preboot Execution Environment) 부팅이 가능하도록 모든 서버에 LOM(Lights-Out Management)포트를 구성해야 한다.

OPNFV 프로젝트에서는 약 6개월을 주기로 새로운 배포판을 발표할 계획이다. 따라서 ARNO에 이은 두 번째 배포판은 오는 12월에 발표될 예정으로, 코드명은 티베트에서 발원하여 인도와 방글라데시를 흐르는 강인 Brahmaputra로 결정되었다.

ARNO 배포판은 짧은기간 내에 간단한 VNF를 실제 실행할 수 있는 가장 기본적인 NFVI와 VIM을 구성하는 것을 목표로 했기 때문에 다양한 기능의 원천공개 소프트웨어 프로젝트가 포함되지는 않았다. 그러나, Brahmaputra 이후에 발표될 배포판에서는 (그림 5)와 같이 다양한 공개 소프트웨어 프로젝트가 추가로 통합될 예정이다. 예를 들어, SDN 제어의 경우, 종전의 OpenDaylight 이외에도 Open Contrail이나 ONOS 프로젝트가 포함될 수 있다. 다만, 이것이 OPNFV의 NFV 참조 플랫폼에 반드시 3가지의 SDN 컨트롤러가 동시에 설치 운용되는 것을 의미하는 것은 아니다. 사용자의 환경이나 유스케이스에 따라 어느 하나의 SDN 컨트롤러만 선택하여 NFV 플랫폼을 구성할 수도 있고, 둘 이상의 컨트롤러를 동시에 사용하여 NFV 플랫폼을 구성할 수도 있다.

(그림 5)

ARNO 후속 배포판의 구성[6]

또한 VIM도 추후 CloudStack이나 Docker 등의 프로젝트가 포함될 수 있으며, 하이퍼바이저도 Xen과 같은 다른 공개 소프트웨어 프로젝트가 얼마든지 선정될 수 있다.

추가로 ARNO 후속 배포판에서는 DPDK(Data Plane Deve-lopment Kit)나 ODP(Open Data Plane) 와 같은 데이터 평면 가속 기술도 NFV 플랫폼의 구성요소로서 포함될 것으로 기대된다.