Network Function Virtualisation(NFV) 정리

Computer/SDN/NFV 2014. 2. 14. 15:57

그제(12일) SK텔레콤 T open lab에서 주최한 제 16회 개발자 포럼 (SDN/NFV "차세대 Network")에 참여하였다. 작년부터 NFV 관련 세미나에 꾸준히 참석해왔는데 그당시에 비해 발표가 더욱 구체화되고 결과도 많이 나온것 같다. 이번 포럼관련해서 NFV기사가 5개나 봤는데 보도자료를 토대로 썼는지 내용들이 다들 비슷하다[5]. 그리고 발표자료를 보내주신다고 해서 기다리고 있었는데 막상 받아보니 정작 중요한 NFV 관련 자료는 거의 없었다. 따라서 정보공유 차원에서 그동안 모아왔던 자료들과 개인적인 생각들을 글로 정리해 본다.

고작 개인이 무수한 벤더와 텔코들의 방향을 완전히 이해하는것은 불가능한 일이겠지만, 나자신과 그리고 NFV를 시작하시려는 분들에게도 도움이 되길 바라며 한번 부족하나마 끄적여본다. 단, 이 글이 그렇게 친절하게 적힌 글은 아니라서 이제 막 시작하시려는 분들에게는 어려울수도 있겠다. 글을 적기에 앞서, 유사한 이름을 가진 Network Virtualization는 NFV(Network Function Virtualisation)와는 스펠부터 다른(ㅋㅋ), SDN에서 구현 가능한 개념이라고 언급하고 넘어가고 싶다. 글의 순서는 다음과 같다.

1. SDN/NFV 다이어그램에서의 "Open Innovation"이란
2. NFV의 장점
3. NFV에서의 Virtualisation이란
4. NFV의 발전단계
5. NFV의 구조
6. NFV M&O의 구조
7. NFV 설계/구현 사례
8. 이동통신망에서의 NFV(VNF) 고려사항
9. NFV와 SDN의 관계
10. 마치며
11. References

1. SDN/NFV 다이어그램에서의 "Open Innovation"이란

[그림 1, 2] NFV와 SDN의[2], 그리고 NFV와 스마트폰과의 관계[4]

이번 포럼에서 강조되었던 점 중 하나는 SDN/NFV를 통한 '상생, 협력'이었던것 같다. 따라서 이들간의 관계를, NFV White Paper[2]에서 발췌한 [그림 1]을 보며 생각해보자. SDN/NFV의 지향점은 '하드웨어 독립적인 네트워킹'이라고 정의해볼 수 있다. 그런데 왜 저 그림에 'Open Innovation'이라는 부분이 추가가 된 것일까, 이것은 SDN/NFV 기술을 통해 그동안 '벤더'의 장막으로 인해 진입이 사실상 불가했던 3rd party들이 참여할 수 있는 여지가 생겼기 때문이다. SDN/NFV는 각 이해당사자들의 요구를 충족시킬 수 있는 기술일 뿐 아니라, 열린 네트워크 환경, 네트워크 플랫폼(OpenAPI, OpenPlatform..)으로써 새로운 생태계(Echosystem)를 형성한다. 기술적, 현실적 한계로인해 접근할 수 없었던 폐쇄적인 네트워크 시장에 누구든 참여할 수 있는 여지를 마련함으로써, 거대 기업에서 생산해내지 못한 다양하고 innovative한 아이디어들이 등장하게 될 것이다.

SDN/NFV를 이야기할때면 항상 등장하는것이 핸드폰에 대한 비유다. [그림 2]를 보면, 현재 통신망의 변화과정이 피쳐폰에서 스마트폰으로 변천하는 과정과 유사하다는 것을 알 수 있다. 피쳐폰에서는 제조사가 만들어놓은 특수 소프트웨어만이 구동가능했고, 더이상의 확장은 불가능했다. 하지만 스마트폰은 다르다. 스마트폰은 좀 더 소프트웨어적인 운영체제가 돌아간다는것 뿐 아니라, 운영체제 그 자체가 소프트웨어를 위한 '플랫폼'으로 역할을 하여 다양한 소프트웨어가 자유롭게 설치될 수 있는 여지를 만들었다. 운영체제라는 layer위에서, 기기의 특성에 상관없이 공개된 API를 통하여 무수한 앱이 누구나에 의해 생산될 수 있는 것이다. 이와 비슷한 그림을 그리자는것이 SDN/NFV이며, 제공되는 플랫폼을 통해 장비/벤더에 구속되지 않는 다양한 Function들을 누구나(ISV, independent software vendor) 만들 수 있게 된다.

2. NFV의 장점

NFV는 H/W 장비를 소프트웨어로 에뮬레이션 하는 'Network Function(NF) 구현'에 머무르지 않는다. 클라우드의 발전으로 이룩한 다양한 가상화 기술을 통하여 더욱 배치가 용이하고(deployable) 유연하고(elastic/flexable) 쉽게 확장 가능하고(expandable/scalable), 민첩한(agile) Function Virtualisation(FV)가 가능해졌다. 특정 벤더의 고가의 장비 대신, 단순하고 고성능인 저가의 대용량 COTS/Commodity 서버(Cloud, Server Farm)를 배치할 때 가장 먼저 기대할 수 있는 효과로는 CAPEX/OPEX/TCO의 절감이 있다. 그리고 더욱 환경친화적이다, 옛날 표현을 끌어와보자면 '저탄소 녹색성장'이라고나 할까. 또한 기존에는 사용자들의 Peak usage를 언제든지 충족하기 위해 고성능의 장비를 배치하여 상당한 유휴자원이 문제가 되었지만, FV에서는 사용자들의 수요에 맞게 용량을 조절하는 인스턴스 배치/설정의 자동화가 가능해진다(Resource Utilization). 또한 장비에 문제가 발생하거나, 혹은 새로운 서비스를 도입하고자 할 때 H/W기반의 환경에서는 오류처리에 수분~수시간이 걸릴 수 있지만, 가상화된 환경에서는 원격에서도 효율적인 Orchestration을 통해 신속하게 문제를 처리하고 Deploy/Instantiate 할 수 있다. 어느 문서를 보던간에 장점은 서두에 등장하니 굳이 이것 이상 열거할 필요는 없을 것 같다.

3. NFV에서의 Virtualisation이란

우선 NFV 표준에서의[10] Virtualisation이란, 네트워크 기능(Network Function)과 NFV인프라의 일부가 소프트웨어로 구현이 되어, NFV 아키텍쳐와 상호 연동될 수 있도록 하는것을 의미한다. "Virtualisation means that a network function and part of the infrastructure are implemented in software, and hence, the NFV software architecture is an important aspect of the NFV architectural framework" 이 정의를 바탕으로, '가상화'에 대한 고려가 없어도 구현될 수 있는, 독립적인 '소프트웨어로서의 네트워크 기능'들은 그냥 NF(Network Function)이라고 불러야 할것이라 생각한다.

NF에 비해, NFV환경에서의 NF는 VNF(Virtualised Network Function)로 정의할 수 있으며 설명과 그 예는 다음과 같다. 뒤에도 다시 언급되는데, 그전에 좀 더 확실하고 짚고 넘어가본다. "Virtualised Network Function, as the software implementation of a network function which is capable of running over the NFVI[10]", "A VNF is a virtualisation of a network function in a legacy non-virtualised network. Examples of NFs are 3GPP™ Evolved Packet Core (EPC) [i.2] network elements, e.g. Mobility Management Entity (MME), Serving Gateway (SGW), Packet Data Network Gateway (PGW); elements in a home network, e.g. Residential Gateway (RGW); and conventional network functions, e.g. Dynamic Host Configuration Protocol (DHCP) servers, firewalls, etc. GS NFV 001 provides a list of use cases and examples of target network functions (NFs) for virtualisation."

실제로 NF 자체의 구현은 비교적 단순한 편이다. 이미 '나와있는' 스펙들을 잘 구현해 내면 어떻게든 돌아가게 되어있으니... 결국 문제는 'NFV 인프라'이다. 인프라(Framework, 혹은 playground)를 구축하는데에는 상당한 '기반'이 필요하다. 서로 다른 NF들을 하나의 규격화된 Box(모 교수님은 이 개념을 상당히 좋아하셨더라지..)로써 다루도록 표준이나 API를 정의해 주어야 하고, 서로간을 잇는 가교역할을 수행하도록 시스템을 설계하고, 가상환경에서 효율적으로 자원을 관리/운영할 수 있도록 기술적인 기반을 마련해야 한다. 이러한 인프라에 대한 고민은 [17]에서도 엿볼 수 있다. 그리고 추가로, NFV '프레임워크'에 대한 정의는 NFV 문서[10]에 너무 잘 설명되어있어서 그대로 가져와본다.

The NFV framework enables dynamic construction and management of VNF instances and the relationships between them regarding data, control, management, dependencies and other attributes. To this end, there are at least three architectural views of VNFs that are centred around different perspectives and contexts of a VNF. These perspectives include:

a virtualisation deployment/on-boarding perspective where the context can be a VM,
a vendor-developed software package perspective where the context can be several inter-connected VMs and a deployment template that describes their attributes,
an operator perspective where the context can be the operation and management of a VNF received in the form of a vendor software package.

4. NFV의 발전단계

[그림 3] NFV의 발전단계[3]

가상화 환경에서 NFV가 어떤 모습으로 나타날 수 있는지 [그림 3]에서의 다섯단계들을 보며 알아본다. 이번 포럼에서 등장한 SKT의 유스케이스는, 물론 일반인들을 대상으로 서술한것이기 때문에 그랬겠지만, 'Auto-optimization'에 해당한다고 볼 수 있겠다[5].

Virtualized is a primary NFV evolutionary stage in which network functions run on hypervisors and general purpose hardware, but may require dedicated physical resources, selected hypervisors and customized configuration solutions.
Cloud is the stage in which virtualization is based on standard interfaces and where virtualized network functions (vNFs) are interoperable with – and portable between – hardware platforms, hypervisors, and cloud resource control systems of different vendors.
Automated Lifecycle Management is the stage in which service providers use tools – similar to the ones deployed in the IT world but adapted to carrier requirements – to manage the vNF lifecycle from onboarding to phase out.
Auto-optimization is the stage in which vNFs are able to dynamically and automatically adapt to changes in service demand (e.g., by scaling up and down) and in which vNF placement and con!guration can be automatically modified to optimize resource use or improve customer experience, for example through reduced latency.
A service provider could – and often will – be in different deployment stages simultaneously. The provider may, for example, deploy several virtualized network functions that adhere to industry-standard interfaces and that can be managed through automated lifecycle tools, while other functions may only be available in a virtualized form. Once a service provider reaches the Fully Automated Cloud stage for all virtualizable network functions, all potential bene!ts of NFV can be realized.

5. NFV의 구조

[그림 4, 5, 6] NFV Architectural Framework[10][3][24]

NFV는 크게 위 [그림 5]과 같이 네 부분으로 이루어진다, 그리고 [그림 5]의 왼쪽 부분은 좀 더 상세하게 [그림 4]와 같이 표현이 가능하다. [그림 5]의 각 부분은 서로 다른 벤더들에 의해 구현될 수 있으며, NFVI을 다루는 NFV Infrastructure WG의 입장에 따르면, NFVI 자체만해도 Hypervisor, Compute, Infratstructure Network Domain으로 분리되어 고려되기도 한다. 아무튼 위 네 부분에 대한 설명은 [2]에서의 내용을 그대로 아래에 인용해본다. Descriptor에 대해서는 아직 명확한 정의가 없는데, 이것은 ETSI NFV MANO WG의 WI(Work Item)으로 규정중이며, 올해 3월에 Draft가 나올 듯 하다.[10] 그림을 보다 갑자기 생각났는데, 위에서 스마트폰이라는 비유가 등장한 김에 NFV 인프라를 안드로이드 운영체제에 비유해보자. 그러면 NFVI는 I/O등의 논리적 자원(물론 그 아래에 물리적인 Hardware Resources가 있다), NFV M&O는 커널, NFV Interface들은 라이브러리, 그리고 VNF는 라이브러리를 사용하는 '앱'으로 표현해볼 수 있을 것 같다.

The NFVI (Network Functions Virtualisation Infrastructure), which provides the virtual resources required to support the execution of the Virtualised Network Functions. It includes Commercial-Off-The-Shelf (COTS) hardware, accelerator components where necessary, and a software layer which virtualises and abstracts the underlying hardware.
The VNF (Virtualised Network Function) is the software implementation of a network function which is capable of running over the NFVI. It can be accompanied by an Element Management System (EMS), as long as it is applicable to the particular function, which understands and manages an individual VNF and its peculiarities. The VNF is the entity corresponding to today’s network nodes, which are now expected to be delivered as pure software free from hardware dependency.
The NFV M&O (Management and Orchestration), which covers the orchestration and lifecycle management of physical and/or software resources that support the infrastructure virtualisation, and the lifecycle management of VNFs. NFV Management and Orchestration focuses on the virtualisation-specific management tasks necessary in the NFV framework. The NFV M&O also interacts with the (NFV external) OSS/BSS landscape, which allows NFV to be integrated into an already existing network-wide management landscape.
The entire NFV system is driven by a set of metadata describing Service, VNFs and Infrastructure requirements, so that the NFV Management & Orchestration systems can act accordingly. These descriptions along with the Services, VNFs and Infrastructure can be provided by different industry players. Service, VNF and Infrastructure Description, This data-set provides information regarding the VNF deployment template, VNF Forwarding Graph, service-related information, and NFV infrastructure information models.

6. NFV M&O의 구조

[그림 7] NFV Management and Orchestration Architecture[10]

그리고 NFV의 M&O의 세가지 개체는 다음과 같이 정의가 가능하다. [10,11]

NFV Orchestrator
- in charge of the orchestration and management of NFV infrastructure and software resources, and realizing network services on NFVI.
- on-boarding of new Network Service (NS), VNF-FG and VNF Packages
- NS lifecycle management (including instantiation, scale-out/in, performance measurements, event correlation, termination)
- global resource management, validation and authorization of NFVI resource requests
- policy management for NS instances
NFV Manager
- responsible for VNF lifecycle management (e.g. instantiation, update, query, scaling, termination).
- Multiple VNF Managers may be deployed; a VNF Manager may be deployed for each VNF, or a VNF Manager may serve multiple VNFs.
- overall coordination and adaptation role for configuration and event reporting between NFVI and the E/NMS
Virtualised Infrastructure Manager (VIM):
- comprises the functionalities that are used to control and manage the interaction of a VNF with computing, storage and network resources under its authority, as well as their virtualisation.
- controlling and managing the NFVI compute, storage and network resources, within one operator’s infrastructure sub-domain
- collection and forwarding of performance measurements and events

특히 VIM의 기능은 다음과 같이 세분화 된다. [11] 티스토리에서 지원을 안해주는 바람에 분리해서 기록한다.

Resource management, in charge of the:
- Inventory of software (e.g. hypervisors), computing, storage and network resources dedicated to NFV infrastructure.
- Allocation of virtualisation enablers, e.g. VMs onto hypervisors, compute resources, storage, and relevant network connectivity.
- Management of infrastructure resource and allocation, e.g. increase resources to VMs, improve energy efficiency, and resource reclamation.
Operations, for:
- Visibility into and management of the NFV infrastructure.
- Root cause analysis of performance issues from the NFV infrastructure perspective.
- Collection of infrastructure fault information.
- Collection of information for capacity planning, monitoring, and optimization.

여기서 애매한 게 하나 있다. 위 세 분류에서 VM의 Lifecycle 관리가 Orchestrator에서 이루어지는지, Manager에서인지 의견이 나뉘는데, 표준문서를 비롯한 다수의 의견은 scaling등의 Lifecycle 관리 업무는 NFV Manager가 담당해야 한다고 하는 것 같다. 약간 다른 용어를 사용하는 [그림 8]과 그 아래의 설명[3]을 보면 그래도 방향이 보인다. Descriptor를 받아서 structure/template를 파악하고 전체 그림을 그리는 것은 NFV Orchestrator(LMF)이다. 그리고 그에 의거해 VM을 생성하도록 NFV Manager(CRC)에 요청을 보낸다. 이 그림에서 NFV VIM은 어디에? 그림으로 보나 설명으로 보나, 당연히 LMF내에 존재한다.

[그림 8] NFV Manager(LMF)의 작동 [3]

vNF lifecycle management function (LMF) uses a descriptor that is generally provided by the vNF vendor. This descriptor defines the structure of the vNF (as it may consist of various sub-functions where each needs to run as an independent VM) and deployment and operational aspects, such as computation, storage and networking requirements. These descriptors are mapped to requests to the cloud resource control to create VMs and to identify software images to be downloaded and initiated on those VMs. Once the VMs are up and running, the LMF configures parameters of the vNF components based on instructions in the descriptor. Lifecycle management also plays a role in elasticity – scaling the vNF up and down–adding, removing or resizing VMs as needed. Triggered by either an operator decision, a vNF event (e.g., a traf!c overload alert), or an infrastructure event (e.g., VM load crossing a defined threshold), the LMF executes the required actions.

7. NFV 설계/구현 사례

[그림 9, 10, 11] Cloud EPC 구축을 위한 Intel-Tieto 의 설계[7][8][9]

OpenFlow가 인기 끌고 대세가 될 수 있었던 이유에는, 'programmable networking'이 중요하다는것은 누구나 인식해왔지만 감히 누가 나서서 표준화 하지 못했던 그것을, 그들이 잘 정의(well-defined)하고 공개했기 떄문이라 생각한다. 이와 같은 논리로 상당한 벤더/기업들이 자신들의 NFV 솔루션을 보다 먼저 구현/공개하고 자신들의 강점을 강조하고 있다. 특히 지금 SDN이라고 불리는 개념이 OpenFlow 구현물을 위주로 돌아간다는것을 생각해보면, 성공적인 NFV 솔루션이 한번 나오고 도입되기 시작되면 주류를 제외한 다른 제품들이 묻히게 될 가능성도 있다. 가뜩이나 NFV의 등장으로 market share의 감소가 예상되는 와중에 한번 밀리면 계속 밀리는 구조가 되는것이고, 이때문에 각 벤더들이 총력을 다하는것으로 보인다.

그와중에 DPDK를 필두로 가상화에 대한 원천 S/W, H/W 기술을 보유한 인텔의 기술이 가상화 인프라(NFVI) '제반사항(Hardware Resources)'의 인텔화를 주도하고 있다. MWC 2012에 등장한 [그림 9, 10. 11]의 Intel-Tieto의 Cloud EPC 설계는 NFV가, 특히 SDN과 함께 어떤식으로 구현될 수 있는지 보여준다. 여기서 언급된 DPDK(Data Plane Development Kit)에 대해 간단히 소개하자면, 인텔 아키텍쳐를 사용하는 하드웨어에서 고성능 data plane 패킷 프로세싱을 지원하는 최적화된 소프트웨어 라이브러리/드라이버를 가리키며 이를 사용하면 스위칭등에 비약적인 성능향상을 기대할 수 있다고 한다. DPDK의 개략적인 설명과 EPC에의 활용사례는 [14]에서 찾아볼 수 있다.

[그림 12] The New OSS(Operations Support System) Ecosystem[21]

[그림 9, 10]의 구조를 [그림 5, 8]에 맞춰 M&O를 중심으로 다시 설명해보면, 전체적인 구성을 더 잘 이해할 수 있을 것 같다. NFV 기본구조위에 이동통신망 특성상 OSS가 추가된 [그림 8]을 보는데에 Alcatel-Lucent에서의 [그림 12]과 함께 보면 괜찮을 것 같다. 아무튼, 위 구조에서는 NFVI(하드웨어 가상화)와 VNF Manager(VM 관리)은 OpenStack으로 관리되고, 그리고 Cloud Controller/Orchestrator으로만(자세한 정보는 공개되지 않은것 같다) 그림에 표현된것이 M&O의 역할을 한다 할 수 있겠다. 이것들을 하나하나 결합하면 결국 [그림 12]과같이 거대한 NVF 솔루션이 등장할것이다.

이미 2013년에 다양한 PoC가 수행되었다. NEC-Telefonica vEPC이외에도 British Telecom의 BRAS(Broadband Remote Access Server), Verizon의 Virtual EPC/IMS, Telefonica의 vCPE/DPI 등의 PoC가 성공적으로 수행되었다.[20] 그리고 2014년은 이들을 실제 적용해 보는 년도가 될것이라 한다. 그런데 아무리 좋은 제안이라고 해도 사업자들이 바로 적용하는데에는 여러가지 barrier가 존재한다. 아래장에서 어떤 특성들이 NFV도입에 영향을 끼치는지 알아본다.

8. 이동통신망에서의 NFV(VNF) 고려사항

[그림 13, 14, 15] 경제적 효과&적용 용이성[4], 서비스 유연성&가격적 측면[3], 그리고 성능면으로 구분한[13] NFV(VNF) 고려사항

관계자들의 말에 따르면, 비록 국내 모든 사업자들이 NFV를 도입한다고는 하지만[23], NFV로의 실제적인 전환에는 상당한 시간이 걸릴것으로 생각된다. 요즘 경제가 어려운데다가 상용화 단계(Carrier-grade)에 미치기에는 아직 기술이 성숙하지 않았기 때문이라고 한다. 이때 [30]에서의 내용이 현실적으로 들린다. 그래도 도입을 고려하는 단계에 있는 만큼, 어떤 관점이 고려되는지 정리해 볼 필요가 있다.

9. NFV와 SDN의 관계

물론 NFV가 이동통신망에 한정되는 개념은 아니지만, 이동통신사업자들이 주축이 되어 표준화를 주도하고 있고, 이동통신망에 적용되었을 경우 그 영향이 다른 분야에 비해 파격적이기에 대부분의 NFV는 이쪽에 치중되어 설명된다. 하지만 Carrier가 가진 또다른 시장인 셋탑박스(STB) 시장에서도 NFV의 가능성이 더욱 가시화되고 있다. 이번 HP 세션에서도 셋탑박스에 대해 언급이 되긴 했었는데(물론 이를 비롯한 다양한 유스케이스가 정의되어 있다[12]), STB에서의 VNF의 예를 들자면 CDN, DPI에서부터 사용자정보관리, 과금개체, 이미지 프로세싱이나 압축, 그리고 이미지에서의 정보 검/추출등의 모듈들을 생각해볼 수 있을것이다.

[그림 16] SDN과 NFV의 연관관계[16]

특히 그러한 서비스(모듈)들은 개별적으로 호출되는것이 아닌, SDN에서의 Service Chaining을 통해 일련의 처리과정을 거침으로써 새로운 서비스로써 승화된다. 지금 계속 서비스라는 단어로 두가지의 개념을 설명하고 있어 혼동될 수 있다. 참고로 NFV 문서[10]에서의 서비스는 다음과 같이 정의되어 있다. "A network service can be viewed architecturally as a forwarding graph of Network Functions (NFs) interconnected by supporting network infrastructure." 그리고 NFV 문서들을 보면 Service니 Template니 하는데, 좀 쉬운 설명은 [25] 에서 찾아볼 수 있다.

돌아와서, 이동통신망을 예로 들어보면, S-GW <-> P-GW로 이어지는 플로우가 있어야지 NFV가 의미가 있지, 서로가 연결되지 않으면 단지 '구현'일 뿐 '서비스'라고 칭할 수는 없다. 이러한 상황에서 SDN을 통한 Service Chaining(NF Forwarding)이 NFV와 SDN을 뗄 수 없게 만든다고 생각하며, 더 나아가 NFV에서의 성능과 확장성 문제 또한 SDN으로 해결할 수 있다고 생각한다. Alcatel-Lucent에서는 다음과 같이 이들의 관계를 나타냈다. "Alcatel-Lucent regards SDN as the yin to NFV’s yang. To achieve the full benefits of NFV, a carrier-grade, scalable and responsive networking solution is critical, first and foremost within datacenters, but also in the telecommunications network at large.[3]"

[그림 17, 18] VNF Forwarding Graph(VNF FG)[12] aka. Service Chain[13].

10. 마치며

글의 틀이 어느정도 잡혔기 때문에 우선 이정도로 정리하고 글을 발행한다.(단 글 수정은 계속 할 예정이다) 아직 전체자료의 1/2도 커버하지 못할정도로 요새는 NFV 자료의 홍수라 할 수 있겠다. 하지만 대개가 추상적인 내용이라 정리가 안됐었는데 이정도로 정리해놓으면 그래도 어느정도 틀이 잡혀진것이라 생각한다. 다음 글에서는 Ecosystem을 이끌어 나가려고 노력하는 Alcatel-Lucent의 CloudBand와, 블로그에 글을 열심히 작성하사는, Tom Nolle의 CIMI Corp.에서 설계한 CloudNFV를 분석해보는 글을 작성해 볼 생각이다. 이와 더불어 업계/관련자들의 입장을 바탕으로 NFV 도입에 부정적인 시각에 대한 글을 작성해 볼 예정이다. 또한 SDN에 대해서도, SDN의 근본과 Floodlight/OpenDayLight에 대해 글을 써볼까 '생각중'이다. 요즘같이 바쁠때 글쓰는데에 너무 시간이 오래걸리는거 같아 부담이 되긴 한다.... 아래는 [16]에서 언급된 NFV에 대한 질문을 첨부해 본다.

Q1. What do we mean by orchestration? Service orchestration? Resource cloud orchestration? Controller orchestration?
Q2. What happens to legacy OSS? What is the migration path to SDN/NFV management approaches?
Q3. What are the largest barriers to operationalizing SDN and NFV?
Q4. Can SDN and NFV be introduced into legacy networks or should they support new services in a greenfield way?
Q5. How much of the network can a single vendor realistically orchestrate? What are the specific standards needed here?
Q6. How far should NFV management and orchestration follow the IT cloud management paradigm?
Q7. What are the benefits of SDN/NFV network automation and orchestration?

"Building an NFV solution is not an exercise in isolation like designing a discrete network box or simply porting software from a network box to a Virtual Machine. It requires re-thinking the way system functions should be realized in a virtualized environment. It also demands deep and rich collaboration with key partners to move quickly. This was critical in accelerating our development and allowing us to achieve unprecedented performance and scale. We are committed to the principle that if you want to play in the NFV ecosystem you need to be a good NFV citizen. You have to have collaboration and openness in your company DNA so that the real impact of NFV can be realized by our carrier customers," said Nishi Kant, CEO at Connectem. [29]

11. References

Bold해놓은 문서는 직접 확인해 보시는걸 권장합니다. 특히, 처음 NFV를 접하는데에는 [27, 28]이 가장 좋은 자료인 듯 합니다.

[1] 2012.08.28 - 디지털데일리 - 통신3사, SDN에 주목…“트래픽 관리, 신규서비스 창출에 적용”

[2] ETSI - Network Functions Virtualisation – Update White Paper

[3] Alcatel-Lucent - NETWORK FUNCTIONS VIRTUALIZATION – CHALLENGES AND SOLUTIONS STRATEGIC WHITE PAPER

[4] KT 유무선네트워크연구소 옥기상 팀장님의 슬라이드

[5] SKT, 차세대 NFV 기술 도입…데이터 폭증 대비

[6] Youtube - [NEC Report from MWC2013] Carrier SDN Solutions - virtualized EPC

[7] Transforming Networks with NFV & SDN - Rose Schooler , Vice President, Intel Architecture Group

[8] Carrier Cloud Telecoms - Exploring the Challenges of Deploying Virtualisation and SDN in Telecoms Networks

[9] Developing a Wireless Communications Cloud with Intel Architecture

[10] ETSI NFV Management and Orchestration - An Overview
[11] ETSI GS NFV 002 V1.1.1 (2013-10) - Network Functions Virtualisation(NFV); Architectural Framework