nfv vnf architecture

© PIOLINK, Inc. SDN No.1

NFV VNF Architecture

2015. 05. 08

㈜파이오링크

SDN개발실 정병화 ([email protected])


목차

1. Overview of VNF in the NFV Architecture

2. VNF Design Patterns and Properties

3. VNF States and Transitions

4. VNF Fault Management Overview

5. Functional Requirements on Management and Orchestration

6. Functional Requirements on Infrastructure

7. VNF Architecture Design Examples

Annex A (Informative): Relationship to SDN

참고자료

2

© PIOLINK, Inc. SDN No.1 © PIOLINK, Inc. SDN No.1

1. Overview of VNF in the NFV

Architecture

3


NFV VNF Scope

4


▪ VNF는 하나 이상의 VNFC로 구성

▪ VNF Component(VNFC)는 소프트웨어 컴포넌트이고 VNF Provider가 정의

▪ VNF는 EM, VNF Manager, NFVI와 연동

VNF Architecture

5


VNF - 의미와 특성

▪ VNF 이란?

- 하나의 network entity 또는 network entities의 그룹

- network entity는 표준화 기관이 정의함 (e.g. 3GPP or IETF)

- Interfaces 와 behaviour로 구성

• VNF는 외부의 NF와 통신을 위해 잘 정의된 external interface를 공개

• VNF의 내부의 network entities 사이에 internal interface는 외부의 NF에 비공개

- 예제) An 'EPC VNF’ = MME + S-GW + P-GW network entities.

▪ VNFC 이란?

- a network entity = a software component → VNF Component (VNFC)

- A VNF = a set of VNFC

- VNFC Instance 는 NFVI Virtualized Container interface(Vn-Nf)와 1:1 map 됨.

6


VNF - 의미와 특성

▪ A VNF 특성

- 소프트웨어의 내용이 정의되어 있는 단일 abstract entity

• VNF Descriptor(VNFD)에 정의됨.

- VNFC 사이의 인터페이스 정의 및 연결

- VNFCs VM 이동, scale up/down, scale in/out, VNFC 사이의 네트워크 연결

- VNF 인스턴스는 VNF의 runtime 인스턴스화

• VNF Manager가 VNFD에 정의된 VNFC 인스턴스들을 생성.

- VNF 소프트웨어 package

• Single VNF Provider가 소프트웨어를 통합하고 package 할 책임이 있음.

▪ VNFC 특성

- VNF를 구성하는 specific component

- VNFC instances(VNFCIs)는 VNFC의 인스턴스화

- VNFCIs는 그들 사이의 network 연결을 변화 시킬 수 있음

• NFV Management 와 Orchestration이 수행함.

- 여러 VNF의 common한 컴퍼넌트는 별도의 VNF에서 공유해야 함.

7


Interfaces

▪ Interface는 두 entities 사이의 상호작용 지점

▪ Entities는 소프트웨어 또는 하드웨어의 서비스/리소스

- 소프트웨어 인터페이스

• 소프트웨어 entities이 소프트웨어 구현으로부터 어떻게 통신하는지 구분

• 소프트웨어 entities 사이의 통신을 제한

- 하드웨어 인터페이스

• 본 스펙의 범위를 벗어남

▪ VNF 소프트웨어 아키텍처와 관련된 인터페이스

- 5가지 type: SWA1~SWA5

8

SoftWare Architecture (SWA)


Interfaces

9


Interfaces

10


SWA-1 Interfaces

11

▪ 정의

- VNF의 외부(External) 인터페이스

▪ 목적

- 다른 Network Function(NF) 통신을 위한 인터페이스

• VNF 간의 연결

• VNF와 물리 네트워크 기능(PNF) 간의 연결

• VNF와 End point 간의 연결

▪ 특징

- Well defined 인터페이스, 외부에 공개

- VNF Provider는 VNFD에 SWA-1에 대한 정보를 제공

- 실제적으로 SWA-5 에서 사용되어지는 logical 인터페이스

- Network Operator or Service Provider는 network service를 구성시, NF간의 연결을 결정시 이용


SWA-2 Interfaces

▪ 정의

- VNF 내부(Internal) 인터페이스

▪ 목적

- VNFC와 VNFC 간의 통신을 위한 인터페이스

▪ 특징

- VNF Provider가 정의, vendor-specific 특성, 외부에 비공개

- 성능(capacity, latency, etc)의 요구 사항을 명시

- 실제적으로 SWA-5 에서 사용되어지는 logical 인터페이스

- 2개의 VNFC 인스턴스가 동일한 host 안에서 동작할 때, latency를 향상시킬 수 있는 기술

• Serial Bus like technologies

- inter-partition(i.e. the VNFCs) 통신에서 사용할 수 있는 channel-based 통신 메커니즘 (CPU level speed-controlled vs.

NIC schedule-controlled)

• Shared Memory Access

- 두 VNFC가 함께 shared memory 접근할 수 있는 메커니즘

12


SWA-3 Interfaces

▪ 정의

- VNF와 NFV MANO의 연결 인터페이스(특히, VNF Manager)

▪ 목적

- VNF의 life cycle management를 위해서 사용

▪ 특징

- 상호연결(Interconnection) attribute: IP/L2 연결을 사용.

- ve-Vnfm-vnf 인터페이스

13


SWA-4 Interface

▪ 정의

- EM이 VNF와 통신하기 위해 사용.

▪ 목적

- FAB, FCAPS network management model과 framework에 따라 VNF를 관리.

14

FCAPS 는 ISO Telecommunications

Management Network model과 network

management를 위한 framework.

[참조: http://en.wikipedia.org/wiki/FCAPS]

VNF

http://en.wikipedia.org/wiki/FCAPS


SWA-5 Interface

▪ 정의

- VNF와 VNFI 사이의 인터페이스

▪ 목적

- SWA-5는 VNF에게 VNFI resource를 할당

• VNF의 Type: VNF Forwarding Graph, VNF Sets

• VNFI의 Type: resources for networking, compute, storage, hardware accelerators

▪ 특성

- NFVI와 VNF 사이에 있는 모든 sub-interface의 단일 abstraction.

- Vn-Nf 인터페이스

- SWA-5 sub-interface

• Generic compute functionality

• Specialized interface

• Storage

• Network I/O

15


SWA-5 Interface ▪ SWA-5 sub-interface

- Generic compute functionality

• 목적: 인터페이스에 generic compute 기능을 제공

• 연결 속성 : CPU-dependent attributes.

- Specialized interface

• 목적 : Video, Voice Gateway card 부터 특화된 memory, 라우팅 애플리케이션까지 다양한 기능을 제공

• 연결 속성 : 표준과 연관된 인터페이스와 구현 기술에 밀접하게 연관됨.

- Storage

• 목적 : storage 동작을 지원할 수 있는 storage 인터페이스를 제공

• 연결 속성 : NFVI 의 물리 storage는 local 또는 remote에서 제공 할 수 있음

- Network I/O

• 목적 : VNFC/VNF에게 network connectivity 서비스를 제공 (Layer 2/3 서비스)

• 연결 속성 : NIC-level attributes, network 를 나누고 redundancy(LAG).

16


2. VNF Design Patterns and

Properties

17


2.1 VNF Design Patterns – VNF Internal Structure

18

▪ VNF는 하나 또는 다수의 VNFC로 구성됨

- VNFC는 가상 컨테이너(VM)에 올라간 소프트웨어 컴포넌트.

- 다수의 VNFC는 상호간에 연결됨.

▪ 하나의 VNF가 다수의 VNFC로 구성되지만, 외부에는 하나의 시스템으로

드러남.


2.1 VNF Design Patterns – VNF Instantiation

19

▪ VNF의 구성요소인 VNFC들은 각각 parallelizable 또는 non-parallelizable하게

실행

- Parallelizable: 하나의 VNF에 여러 개의 VNFC가 인스턴스화를 수행

- Non-parallelizable: 하나의 VNF에 한 개의 VNFC가 인스턴스화를 수행


2.1 VNF Design Patterns – VNFC States

20

▪ 각각의 VNFC는 state 정보를 다룰 수 있음.

- VNFC는 state 정보를 가질수 있고, 가지고 있지 않을 수 있음.

▪ state 정보를 가진 경우

- VNFC 내부 또는 외부에 저장 할 수 있음


2.1 VNF Design Patterns – VNF Load Balance Models

21

▪ 4가지 type의 Load balancing

1) VNF-internal Load Balancing

2) VNF-external Load Balancing

3) End-to-End Load Balancing

4) Infrastructure Network Load Balancing



22

(1) VNF-internal Load Balancer

-1 VNF 인스턴스는 Peer NF를 1 logical NF로 인식

-내부의 LB는 여러 VNFCs로 packets/flows/sessions 을 분산 시킴

-(e.g.) VNF Provider가 확장 가능한 하나의 NF을 구현시

-Single VNF Provider solution

-VNFM이 LB를 생성



23

(2) VNF-external Load Balancer

-N VNF 인스턴스는 Peer NF를 1 logical NF로 인식

-외부의 LB는 별도의 VNF이고, 여러 VNFs로 packets/flows/sessions을 분산 시킴

-(e.g.) 웹서버 앞 단의 ADC (Application Delivery Controller) type의 LB 또는 DSR

(Direct Server Return)

-VNFs가 서로 다른 VNF Providers 일 경우

-NFVO가 VNF 인스턴스를 생성하고, LB VNF를 연결



24

(3) End-to-End Load Balancing

-N VNF는 Peer NF를 N logical NFs 으로 인식

-(e.g.) 3GPP에서 eNBs (Peer NF)와 MME, S-GW 사이의 S1-flex 인터페이스

-(e.g.) 웹서버들 사이에 있는 Client-side의 DNS기반 load balancing.

-VNFs는 서로 다른 VNF Providers

-NFVO가 VNFs 인스턴스를 생성 하지만, LB는 Peer NF가 제공



25

(4) Infrastructure Network Load Balancer

-N VNF 인스턴스는 Peer NF를 1 logical NF로 인식

-LB는 NFV Infrastructure 가 제공하는 hypervisor vSwitch, OS vSwitch, physical box

안에 존재함

-(e.g.) 여러 Firewall 인스턴스들에게 load balancing을 제공하는 NFV Infrastructure

-NFVO가 VNF 인스턴스를 생성하고 NFVI의 load balancer 설정 및 VNF와 연결.


2.1 VNF Design Patterns – VNF Scaling Models

26

▪ 세 가지 종류의 VNF Scaling

1) Auto scaling

2) On-demand scaling

3) Scaling based on a management request



27

(1) Auto scaling

-VNF Manager가 VNFC 의 Rule을 기준으로 scaling 여부 결정

•VNF’s VM의 리소스 사용양을 모니터링 (VNF, EM, VIM로부터 정보 수신)

-Scale out/in 와 scale up/down을 제공



28

(2) On-demand scaling (from VNF or EM)

-VNF 또는 EM이 VNFC 인스턴스의 상태를 모니터링 할 수 있는 경우

•VNF가 scaling 실행 여부를 결정하고, VNF manager에게 scaling 요청

-Scale out/in 과 scale down/up 제공



29

(3) Scaling based on a management request

-관리자가 Manual하게 scaling 설정

-또는, OSS/BSS가 VNFD의 Rule에 따라 scaling 결정하고 OFVO에게 요청

-Scale out/in 과 scale down/up 제공


2.1 VNF Design Patterns – VNF Component Re-Use

30

▪ 여러 가지 모델이 연구되었지만, ETSI NFV와 관련하여 한가지만 허용

2개의 VNF가 동일한 기능의 B1, B2 를 포함

ETSI NFV가 동의하지 않음

2개의 VNF가 VNFC B 를 공유

Valid한 모델이 아님

공통의 기능을 가진 VNFC B가

별도의 VNF에 존재


2.2 VNF Update and Upgrade

31

▪ VNF Update

-새로운 기능 또는 인터페이스를 도입하는 것이 아님.

-VNFFG에 연결된 다른 VNF에 영향을 주지 않고 실행

▪ VNF Upgrade

-새로운 기능 또는 인터페이스를 도입하는 것임.

-네트워크 서비스 레벨에서 실행

▪ VNF Updating 과 VNF Upgrading 방법

- vendor specific.

▪ 요구사항 for VNF Provider

-VNF updating/upgrading 실행에 대한 automatic procedure 제공

-Procedure는 NFV MANO에 대한 requesting을 포함하여 VNF updating/upgrading

진행을 제어

-Procedure는 NFV MANO로부터 얻어진 가상 리소스를 해제하는 것을 포함하여 VNF

updating/upgrading에 대한 roll-back 기능을 지원


2.3 VNF’s Properties – Hardware Independence

32

▪ 정의

-하드웨어 독립성과 관련하여 NF를 분류

▪ 모든 VNF는 다음 중 하나에 속함.

-COTS-Ready

•NF는 physical infrastructure에서 완전히 독립적임

-Partly COTS-Ready

•VNFCs 중 몇몇은 physical infrastructure로부터 독립적이지만, 몇몇은 특정 하드웨어에

의존적임

•(e.g.) MRF – 몇몇 VNFC는 특정 DSP card가 필요함.

-Hardware dependent

•NF는 특정 하드웨어에 종속적임

•(e.g.) DPI 구현은 특정 데이터 가속 card를 요구함. UDP firewall, gateway device 등

▪ COTS (Commercial off-the-shelf)


2.3 VNF’s Properties – Virtualization and container Awareness

33

▪ 정의

- 다양한 container와 가상 기술과 관련된 NF의 소프트웨어 특성

• NF는 여러 가지 이유로 가상화 환경에서 실행 될 수 없음

• VNF 형태로 가상화 환경에서 실행되는 NF

- OS container 위에서 설계, Hypervisor 가상화에서 설계

▪ 모든 NF는 다음 분류 중 하나에 속하거나, 조합 됨.

-Hypervisor agnostic

• virtual machine/hypervisor 환경에 의존성 없음.

• virtual machine/hypervisor 환경에서 동작 & native 하드웨어에서 동작

- Hypervisor dependent

• VNF 구현은 가상 머신/hypervisor 환경에 의존성이 있음.

- Operating System Containers

• NF 소프트웨어는 OS container 기술과 함께 사용되기 위해 설계됨

- Higher layer container technology

• NF 소프트웨어는 JVM과 같은 higher layer container 기술 상에서 실행 할 수 있음.

- Not virtualized and no container technology

• NF는 가상 머신/hypervisor 환경/container 기술 상에서 실행 불가.

• PNF로서 NFV 범위가 아님

- Partly virtualized

• NF 중 몇몇 컴포넌트는 가상화 될 수 있고, 몇몇은 가상화를 인지하고, 몇몇은 가상화가 불가.


2.3 VNF’s Properties – Elasticity

34

▪ 정의

- scaling(up/down, in/out)의 type과 elastic operation을 정의 및 수행하는 특성

▪ 모든 VNF는 다음 분류 중 하나에 속함.

- No elasticity

• VNF의 자원들은 고정 (변경할 수 없음)

- Elasticity by scaling up/down only

• NFV 프레임워크는 가상 자원(size, performance, bandwidth)을 조정할 수 있음.

- Elasticity by scaling out/in only

• VNF는 VNFC 인스턴스를 추가/삭제 할 수 있음.

- Elasticity in either dimension

• VNF는 scaling up/down, out/in 둘 다 제공함


2.4 VNF’s Properties – VNF Policy Management

35

▪ 정의

- 자동화된 동작 task(e.g. scale in/out, threshold기반의 migration)를 위해 필요한

dynamic한 rule 기반의 provisioning과 관리를 제공하는 특성

▪ 모든 VNF는 다음 중 하나에 속함.

- Fully policy based VNF

• NFV MANO는 VNF를 위한 provisioning과 관리 정책을 전체 기능을 제공

- Not policy based VNF

• NFV MANO는 VNF를 위한 provisioning과 관리 정책을 제공하지 않음

• VNF가 정책관리를 제공함.


2.4 VNF’s Properties – Migration operations

36

▪ 정의

- VNF의 리소스에 대한 이동을 수행하는 특성

▪ 모든 VNF는 다음 중 하나 또는 조합의 특성을 가짐.

- No live migration supported

• VNF가 실행되는 동안 이동하는 것을 지원하지 않음

- Live migration supported

• hypervisor 기술을 사용하여 다른 NFVI 리소스로 VNF를 이동 하는 것을 지원

- Migration partially supported

• VNFC 중 몇몇은 지원하고 몇몇은 지원하지 않음

- Other migration mechanisms

• VNF의 이중화를 활용 (standby VNFC를 shutdown 하고 다른 NFVI에서 restart)


2.4 VNF’s Properties

37

▪ VNFC States

-Stateful operation

-Stateless operation

▪ Reliability

-VNF에 대한 Reliability architectural pattern, dependencies, requirement

-VNF Fault Management와 연관성 있음

-참고: ETSI GS NFV-REL 001: “Network Functions Virtualisation(NFV): Resiliency Requirements”

▪ Location Awareness

- VNF 또는 몇몇 컴포넌트는 토폴로지 안에 있는 위치에 대한 의존성이 있음

▪ Application Management

- VNF를 위한 애플리케이션 관리

• No management

• standardized management interface: EM or OSS/BSS 사용

• proprietary management interface: EM or VNF Provider 사용을 위한 비표준 인터페이스

• multiple service provider’s management interfaces

▪ Diversity and Evolution of VNF Properties

- 하나의 VNF를 형성하는 다수의 VNFC는 각각 다른 특성을 가질 수 있음

- (e.g.) stateful/non-paralleizable 특성의 VNFC, statefulness/parallelizable 특성의 VNFC


2.5 Attributes describing VNF’s Requirements

38

▪ VNF Topological Characteristics

- VNF의 배치설정(deployment configuration)과 동작(operate behaviour)은 VNFD 템플릿에 정의

• 배치동작(deployment behaviour): 배치될 VNF의 상태와 설정

• 동작(operate behaviour): 운영, 관리되기 위한 적절한 기능

- VNFD는 VNF가 생성될 때 사용됨

- VNFD의 주요 구성 정보

• VNF identification data

- VNF vendor/provider 정보, VNF type/설명 정보, Version

• VNF specific data

- VNF 설정, VNVC의 inter-dependencies 연결 요구사항

- VNF lifecycle workflow scripts, VNF를 구성하는 VNFCs 정보(type, version)

• VNFC data

- VNFC의 type, 식별 정보, VNFC 설정 정보

- Virtualisation container files/images 정보

• Virtualised resource requirements

- Compute, storage, network 관련 resources 정보


2.5 Attributes describing VNF’s Requirements

39

▪ Deployment Behaviour

- Virtualisation containers

- NFVI Resources

- Components and Relationship

- Location

- Other constraints

▪ Operational Behaviour

- Management Operations


3. VNF States and Transitions

40


VNF 인스턴스 상태

41

상태 설명

Null VNF 인스턴스가 없지만 생성하려는 상태

Instantiated Not Configured VNF 인스턴스가 존재하지만 서비스를 위한 설정이

없는 상태

Instantiated Configured - Inactive VNF 인스턴스가 서비스를 위해 설정된 상태

Instantiated Configured - Active VNF 인스턴스가 서비스에 참여한 상태

Terminated VNF 인스턴스를 삭제한 상태


VNF 상태 전이

42

Transitions

action

Reverse

transition action 설명

Instantiate Terminate Instantiate - VNF 인스턴스를 생성 (NFVI 리소스 할당)

Terminate - VNF 인스턴스를 삭제 (NFVI 리소스 해제)

Configure N/A

Configure - 원하는 서비스에 참여할 수 있도록 VNF 인스턴스의

parameters를 설정 또는 설정변경

(e.g. VoLTE 서비스에 참여할 수 있도록 vDRA를 설정)

Start Stop Start - Instantiated Configured-Inactive 상태의 VNF를 실행

Stop - Instantiated Configured-Active 상태의 VNF를 중지

Scale out Scale in Scale out - VNF 인스턴스에 new VNFC 인스턴스를 추가

Scale in - VNF 인스턴스에서 VNFC 인스턴스를 제거

Scale-up Scale-down Scale-up - VNFC 인스턴스의 compute, network, storage 자원을 확장

Scale-down - VNFC 인스턴스의 compute, network, storage 자원을 축소

Update Update Rollback Update - 버그수정 및 개선사항을 적용

Update Rollback - 버그수정 및 개선사항을 적용한 것을 되돌림

Upgrade Upgrade Rollback Upgrade - VNF 이미지 버전을 올림

Upgrade Rollback - VNF 이미지를 이전 버전으로 되돌림

Reset N/A Reset - VNF의 설정을 삭제함


The VNF 상태와 상태전이

43


VNF Instantiation 개요

44

master Ve-Vnfm인터페이스를 통해

VNF manager와 통신

● 동일한 vlan & broadcast domain

● VNFC는 IP address를 가지고 상호간에 통신함

VNFC가 서로 연결되었을때

VNF가 Instantiation 이됨


The VNF Descriptor’s Role in VNF Instantiation

45

▪ VNFD

- VNF Provider가 제공함

- VNF의 가상 리소스 요구사항을 설명

- NFV MANO가 VNF의 lifecycle 동작을 수행하기 위해 VNFD를 사용함

- NFVI resource

•connectivity, bandwidth, latency, etc.

- Location rule

•e.g. 몇몇 VNFC 인스턴스는 동일한 rack에 위치


Instantiation

46

▪ VNF Instantiation

① VNF Manager는 VNFD에 정의되어 있는 VNFC set를 생성

VNFC set가 VNF의 최소 인스턴스 (called “boot VNF 인스턴스”) 경우

추가적인 VNFCs 생성을 위해 VNF Manager에게 권한을 요청하고 VNFCs 생성

② EM을 등록

③ VNF Manager에게 완료됨을 알림

► VNF 인스턴스 상태: Instantiated NOT Configured state

▪ VNFC Instantiation

① VNF Manager는 VNFD의 정보에 기초해서 VM, network, storage 리소스를 요청

이전에 할당해 놓은게 있으면 그 리소스를 사용

② 완료되면, VM을 start함

③ VNF Manager는 기본 인스턴스 설정을 하고 추가적인 동작을 시작함 (From VNFD)

내부의 load balancer의 설정을 포함

④ VNF 또는 EM에게 설정할 준비가 됐음을 알림.


Termination

47

▪ VNFC Instance Termination

① VNF Manager는 VNFC 인스턴스에게 “shut down”을 요청

내부의 load balance 설정 조정, VNFC의 상태를 저장

② 정상적으로 shut down 되면, VNFM에게 알림

☞ VNF가 VNFC를 위한 termination 기능을 가지고 있는 경우

VNF가 VNFM에게 권한을 요청하고 VNC 인스턴스를 종료시킴

► VNFC의 가상 리소스는 삭제됨

▪ VNF Instance Termination

- VNF Manager는 아래 두 가지 방법 중 하나를 실행

A. VNFD에 정의 되어 있는 VNFC 인스턴스들을 종료시킴

B. VNF가 내부적으로 “shut down” 기능을 가지고 있는 경우, VNF에게 종료 요청함.

VNF는 graceful한 shut down 기능 수행을 완료 후, VNFM에게 알림.

VNFM은 VNF의 리소스를 해제하기 위해서, VIM에 관련 동작을 수행하도록 요청함.

- 만약 정상적인 종료가 실패하면, VNF Manager는 모든 VNFC를 강제 종료함.


VNF Instance Scaling

48

▪ General Aspects

- VNF는 work load의 종류에 따라서, VNF 인스턴스의 구성요소인 VNFC의 scaling 함

- scaling의 분류

• Scaling out/in : VNFC를 추가/삭제

• Scaling up/down : VNFC의 리소스를 확장/축소

▪ Scaling Triggers

- Auto-scaling

• VNF Manager가 VNF의 구성요소인 VNFC를 모니터링, 조건 만족 시 trigger함

• Infrastructure-level event (VIM), VNF-level event (VNF 인스턴스, EM)

- On-demand scaling

• VNF 인스턴스, EM이 VNF의 구성요소인 VNFC를 모니터링, VNFM에게 scaling 요청.

- Scaling based on a management request

• NFVO 또는 관리자가 직접 VNFM에게 scaling 요청.


VNF Instance Scaling

49

▪ VNF Scale-out

① VNFM은 VNFC 인스턴스를 생성

② VNFM은 VNF 인스턴스 또는 EM에게 post-scale-out notification을 전달

③ VNF 는 scale-out 후에 internal operation을 수행

▪ VNF Scale-in

① VNFM은 VNFC 인스턴스를 종료

② VNFM은 VNF 인스턴스 또는 EM에게 post-scale-in notification을 전달

③ VNF 는 scale-in 후에 internal operation을 수행

▪ VNF Scale-up

① VNFM은 scale-up을 위한 VNFC 인스턴스의 리소스 update를 VIM에게 요청

② VNFM은 VNF 인스턴스 또는 EM에게 post-scale-up notification 전달

③ VNF는 internal operation을 수행

▪ VNF Scale-down

① VNFM은 scale-down을 위한 VNFC 인스턴스의 리소스 update를 VIM에게 요청

② VNFM은 VNF 인스턴스 또는 EM에게 post-scale-down notification 전달

③ VNF는 internal operation을 수행


Start and Stop VNF

50

▪ Start VNF

① VNF의 상태 : Instantiated Configure-Inactive state

② VNFM 또는 EM은 VNF 인스턴스에게 active로 이동하도록 요청

③ VNF 인스턴스는 start 되었음을 VNFM에게 알림.

④ VNF의 상태 : Instantiated Configure-active state

▪ Stop VNF

① VNF의 상태 : Instantiated Configure-active state

② VNFM 또는 EM은 VNF 인스턴스에게 “shut down” 수행하도록 요청

③ VNF 인스턴스는 stop 되었음을 VNFM에게 알림.

④ VNF의 상태 : Instantiated Configure-inactive state

▪ VNF Instance Configuration

① VNF의 상태: Instantiated (Not) Configured (Inactive, Active) state

② VNF 인스턴스는 VNFM 또는 EM이 설정을 함.

설정을 수행하는 entity를 configurator 라고 함.

③ VNF 인스턴스의 설정이 완료된 후, configurator에게 알림.

④ VNF의 상태: Instantiated Configured (Inactive, Active) state


4. VNF Fault Management

Overview

51


Introduction

52

▪ NFV framework의 특성 중 하나는 hardware failure를 완화시키는 것.

- NFVI failure를 masking

- 가상화 기반의 HA 메커니즘

▪ VNF는 NFVI failure로부터 독립적임.

▪ Fault management 의 여러 가지 processes

- Fault detection, fault localisation, fault reporting

- 이러한 process들은 다른 entity에 위치할 수 있음

▪ VNF는 entities 에서 발생한 fault에 대해서 알 필요성이 있음.

- VNF의 lifecycle 에 의존성

▪ VNF는 lifecycle을 관리하는 entity에게 fault에 대해서 알려야 함.

▪ VNF fault management는 다음을 포함함.

- VNF 가상 리소스의 fault

- VNF 안에서의 fault


Virtualised resource faults

53

▪ VNF에 영향을 주는 NFVI의 fault

- VNF의 기능에 영향을 주는 가상 리소스의 fault (e.g. 전체 NFVI down)

- VNF의 이중화 방식의 fault (e.g. backup 가상화 리소스의 사용불가)

- Vn-Nf/SWA-5 인터페이스의 fault (e.g. 가상 layer/hypervisor의 fault)

- 가상 container 연결의 fault


VNF faults

54

▪ VNF 애플리케이션 내부의 fault와 관련됨.

- 소프트웨어 버그

- VNFC 간의 통신 실패

- 보안 faults (e.g. VNF 보안의 허점, Denial of Service)

- VNF 설정 실패 (e.g. 잘못된 parameter 설정)


5. Functional Requirements on

Management and Orchestration

55


High Level Requirements to Management and Orchestration

56

▪ General Management and Orchestration Requirements related to VNF

▪ Management and Orchestration Requirements Related to VNF Lifecycle

▪ Management and Orchestration Requirements Related to Scaling

▪ Management and Orchestration Requirements Related to Maintenance

Tasks


Requirements for VNFD and VNF-FGD template

57

▪ General Requirements Related to VNF

▪ General Requirements Related to VNF Forwarding Graphs

▪ Requirements Related to VNF Creation and Termination

▪ Requirements Related to Scaling


6. Functional Requirements on

Infrastructure

58


Functional Requirements on Infrastructure

59

▪ Generic Domain Requirements

▪ Hypervisor Requirements

▪ Compute Resource Requirements

▪ Network Resource Requirements


7. VNF Architecture Design

Examples

60


개요

61

▪ 네트워크 기능 중 몇몇은 높은 성능을 요구함

- 실시간 서비스 지원, high data processing, 극단적인 I/O

- 다른 entity의 네트워크 기능 또는 storage와 함께 높은 성능의 통신

▪ 대응방안: VNF Architecture 에서 지원

- 기존 기술에 DPDK, SRIOV와 소프트웨어 디자인을 접목

- 전체 성능을 높이기 위해서 몇몇 기능은 하드웨어로 이동하는 방안


Faster VNFC

62

▪ VNF의 성능 향상 방법

- VNF 또는 VNFC 인스턴스의 scaling up/out

- VM의 애플리케이션 에서부터 NVFI의 layer까지 전체 stack을 개선

▪ Figure 23

- data processing acceleration library, cpu와 호환할 수 있는 driver

• A. VM의 network stack에서 DPDK 사용

• B. vswitch에서 DPDK 사용


VNFC to VNFC Communication

63

▪ Scenario #1

- Hardware switch

▪ Scenario #2

- Virtual switch (vSwitch)

▪ Scenario #3

- DPDK를 사용하는 vSwitch

▪ Scenario #4

- SR-IOV를 사용하는 eSwitch

▪ Scenario #5

- SR-IOV를 사용하는 eSwitch

- DPDK를 사용하는 VNFC

▪ Scenario #6

- VNFC 사이를 Serial Bus 연결

• extreme workload

• 매우 작은 latency


VNFC Memory to VNFC Memory

64

▪ 몇몇 NF은 매우 작은 data path latency 요구

▪ e.g.) 실시간 video 회의

- DPI가 datapath 있지만, video transcoding은

사용자의 서비스 향상을 위해서 매우 빠른 성능을

요구

▪ shared memory scheme

- inter-VNFC 통신을 위해 사용

- 두 VNFC는 동일한 물리 host 에 위치


Faster Network Access

65

▪ 몇몇 NF은 high Gb Ethernet traffic 처리를

요구

- e.g.) data plane function

▪ network speed/bandwidth는 VM의

performance와 밀접한 연관

- ETH(Ethernet)은 현재 40Gbps 지원

- IB (Infiniband)는 현재 56 Gbps 지원

• IB는 구현과 관리가 더욱 simple함

• $/Gbps 낮은 비용

▪ VM이 SR-IOV를 사용하기 위해서 NIC에서

기능을 제공해야 함.


Fast Storage Access

66

▪ 대용량의 데이터를 다루는 몇몇 NF은 인스턴스가 storage에 빠르게 접근하는

것을 요구

- e.g.) CDN과 content

▪ iSCSI (internet small computer system interface) 기술

- 컴퓨팅 환경에서 데이터 스토리지 시설을 이어주는 IP 기반의 스토리지 네트워킹

표준

- 단점: CPU 를 사용하기 때문에 CPU의 cycle, latency, 전력에 영향

▪ RDMA (Remote Direct Memory Access) 기술

- OS와 CPU를 bypass하는 기술

- iSER (iSCSI extension for RDMA) 는 hypervisor traffic을 가속화하기 위해 사용

- 장점

• 믿을 수 없을 정도의 낮은 latency

• 한결같은 latency

• OS를 skip함으로, CPU cycle이 크게 감소

- iSER의 장점

• TCP/IP based iSCSI보다 6배 성능


Fast Storage Access

67

▪ Fast and low latency storage access

- RDMA : Remote direct memory access.

- RoCE : RDMA over Converged Ethernet.

- iSER : iSCSI extensions for RDMA.


Driver version, Software Updates

68

▪ Requirements to Management and Orchestration

- VNFD는 VNFC가 요구하는 driver version을 VNF가 알 수 있는 parameter를

제공해야 함.

- Management and Orchestration은 VIM에게 driver version update를 지시할 수

있어야 함.

▪ Requirement to VIM

- VIM은 사용되고 있는 driver의 version을 설명할 수 있어야 함.

- VIM은 driver version을 update 할 수 있어야 함.


Annex A (informative):

Relationship to SDN

69


SDN Architecture Overview

70

▪ SDN controller 와 SDN network elements

- SDN controller가 분산 배치의 기능인 경우

• VNF로 구현시 확장성에 유용함 – scaling up/down, out/in

- SDN network element도 VNF로 구현

• hybrid mode 뿐 아니라 SDN과 non-SDN 모델


SDN in NFV Architecture

71


SDN in NFV Architecture

1. 물리 스위치, 하이퍼바이저 가상 스위치, 임베디드 스위치

2. VNFCIs 사이의 연결 서비스 제공

3. SDN controller

4. VNF (e.g.) virtual router, virtual firewall, etc.

5. SDN 애플리케이션, 서비스 chaining 애플리케이션

6. Nf-Vi 인터페이스

7. Ve-Vnfm 인터페이스

8. Vn-Nf 는 VNFCIs 사이의 연결 서비스를 접근

할 수 있게 하는 것.

▪ SDN을 위한 NFV 요구사항

- SDN controller가 가상화 될 때, Ve-Vnfm 지원

- SDN 컴포넌트 VNF vendor는 VNFD를 제공

72

1.

2.

5.

3. 4.

7.

6. 8.


L2 Transparent Network Service Chaining with Traffic Steering

73

▪ 문제 1 – Physical server deployment

- Fixed Service Chain

• 모든 traffic이 연결된 device를 통과해야 함.

- Service 추가 또는 삭제

• 신규 서비스를 도입 시, 물리적인 연결과 서비스 설정하는데 많은 시간이 걸리고, 실수할

확률이 있음.

- 복잡한 scale-out 구조

• 두 set의 Load balance 필요, 셋업하는데 많은 비용.


L2 Transparent Network Service Chaining with Traffic Steering

74

▪ 문제 2 – Virtual Server Deployments

-가상 환경에서의 VM 운영

• 여러 서버들은 하나의 물리 서버에서 인스턴스화 할 수 있음.

• 다양한 권한을 가진 서버들은 동일한 서버에서 인스턴스화 할 수 있음.

• 서버들은 물리서버를 이동할 수 있음.

- Security를 가상 환경에 배치 하기 위한 방안

• 다양한 type의 VM은 각각의 물리 서버에 위치해야 함.

• (e.g.) L2 security를 Web VM과 DB VM 사이에서 요구하는 경우.

- 문제

• 다양한 type의 서버들을 위한 type 별 전용 물리서버

• Overlay 기술을 지원하는 네트워크 서비스 devices.

• IPSec 함께 overlay


Solution Description & Relationship to SDN/OF

▪ Virtual 환경에서의 network service 도입

- simple, fast, 낮은 error 발생

- VM의 서버 위치와 이동이 자유로움.

- Virtual network 기술의 의존성이 없음.

▪ 앞의 문제를 해결하기 위한 2가지 기술

- Network service 가 VM에 배치되는 NFV 기술

- Network function chain환경에서 traffic steering을 제공할 수 있는 SDN/OF 기술

75


Role of SDN/OF in Service Chaining Traffic Steering

76

▪ Service Chaining

- Orchestration tool(e.g. openstack)을 통한 Configuration step:

• Uploading network service images into orchestration tool.

• Creation of network service chain.

• Adding network services to the chain. (Firewall, DDoS, IPS, DPI, WAF)

• Creating bypass rules.

- Rule 1: Web traffic, bypass “DDoS”, “DPI”

- Rule 2: All traffic, bypass “WAF”

• Attaching the network service chain to a virtual network.



77

▪ Service Chaining

- Packet flow:

• Step 1: App VM1은 App VM2에 HTTP 연결을 시도. OF table에 없는 첫 packet은 SDN controller로 upcall됨.

• Step 2: SDN controller의 traffic steering application은 Rule 1의 해당하는 packet임을 인지하고, A, B, C, D, E를 지나가도록

virtual switch에 rule을 설정

• Step 3: flow rule이 설정된 후, App VM2이 모든 HTTP traffic은 rule에 따라 network service 노드들을 지나감.



78

▪ Scale-out

- SDN controller와 OF switch는 flow rule을 통해 Load balance의 동작을 할 수 있음.

- IPS, WAF는 3개의 IPS, 2개의 WAF로 scale-out 함.

- SDN controller는 IPS, WAF를 선택 할 때, 가장 적은 load를 가진 것을 선택함.

• Red line과 Blue line은 다른 IPS를 경유함.


참고자료

▪ ETSI GS NFV-SWA 001 : Network Functions Virtualisation (NFV); Virtual

Network Function Architecture

▪ VNF 관리 인터페이스 (ETRI)

79


감사합니다.

㈜파이오링크

서울시 금천구 가산디지털2로 98

(가산동 550-1) IT캐슬 1동 401호

TEL: 02-2025-6900

FAX: 02-2025-6901

www.PIOLINK.com

80

nfv vnf architecture

Technology