ETSI NFV MAN001: 网络功能虚拟化管理和编排规范

需积分: 9 125 浏览量更新于2024-07-19 收藏 2.15MB PDF 举报

ETSI NFV MAN001是ETSI（欧洲电信标准协会）发布的关于网络功能虚拟化（NFV）管理和编排的重要规格文档。该版本为V1.1.1，发布日期为2014年12月。NFV是电信行业的一个关键概念，它旨在通过将传统的网络功能软件化并部署在通用硬件上，实现网络服务的灵活、高效和成本节约。 MAN001文档的核心关注点在于网络功能的配置管理和编排（orchestration）。配置管理涉及对虚拟网络功能进行设置、调整和监控，以确保其正确运行，并与基础设施和其它网络组件协同工作。这包括了虚拟化环境中的软件配置、性能优化以及故障排查等方面的技术。编排（orchestration）则是指自动化过程，用于动态创建、修改和删除网络服务，它整合了资源分配、服务实例化、生命周期管理和服务链路的建立与终结。编排工具通常会根据业务需求和策略，协调复杂的网络资源，以提供按需的服务部署和扩展。文档中提到的“configuration”一词强调了对NFV环境中各个组件的配置能力，这可能涵盖了网络设备、虚拟机、网络服务以及接口的设置。同时，关键词"orchestration"的出现表明了文档着重于解决如何通过自动化和标准化的方式来优化服务部署流程，提高网络效率。值得注意的是，虽然这份文档代表了参与NFV ETSI Industry Specification Group (ISG)的成员的观点，但并不一定代表整个ETSI的立场。此外，关于版权和使用的声明提醒读者，未经ETSI书面授权，电子或纸质版本的内容不得随意修改，且可通过指定的网址下载最新的官方版本。 ETSI NFV MAN001 V1.1.1文档为网络运营商、技术提供商和开发者提供了一套管理和编排NFV基础设施的标准指南，以推动网络功能虚拟化的实施和演进，从而满足现代通信网络的灵活性和可扩展性需求。

ETSI

ETSI GS NFV

MAN 001 V1.1.1 (2014

12)

4.4 Management and Orchestration aspects of Network

Services

The Network Service Orchestration is responsible for the Network Service lifecycle management including operations

such as:

• On-board Network Service, i.e. register a Network Service in the catalogue and ensure that all the templates

describing the NS are on-boarded.

• Instantiate Network Service, i.e. create a Network Service using the NS on-boarding artefacts.

• Scale Network Service, i.e. grow or reduce the capacity of the Network Service.

• Update Network Service by supporting Network Service configuration changes of various complexity such as

changing inter-VNF connectivity or the constituent VNF instances.

• Create, delete, query, and update of VNFFGs associated to a Network Service.

• Terminate Network Services, i.e. request the termination of constituent VNF instances, request the release of

NFVI resources associated to NSs, and return them to NFVI resource pool if applicable.

The deployment and operational behaviour requirements of each Network Service is captured in a deployment template,

and stored during the Network Service on-boarding process in a catalogue, for future selection for instantiation. The

deployment template fully describes the attributes and requirements necessary to realize such a Network Service.

Network Service Orchestration coordinates the lifecycle of VNFs that jointly realize a Network Service. This includes

(not limited to) managing the associations between different VNFs, and when applicable between VNFs and PNFs, the

topology of the Network Service, and the VNFFGs associated with the Network Service.

During the Network Service lifecycle, the Network Service Orchestration functions may monitor KPIs of a Network

Service if such requirements were captured in the deployment template, and may report this information to support

explicit request for such operations from other functions.

The Network Service Orchestration performs its services by using the VNF Management services and by orchestrating

the NFV Infrastructure that supports the interconnection between VNFs functionality, and its functions are exposed in

an open, well known abstracted manner as services to other functions. In order to fulfil its responsibilities, the Network

Service Orchestration functions consume services exposed by other functions (e.g. Virtualised Infrastructure

Management functions).

The services provided by Network Service Orchestration can be consumed by authenticated and properly authorized

other functions (e.g. Operations Support System (OSS), Business Support System (BSS)).

4.5 Other management and orchestration aspects of NFV

framework

This clause provides a high level description of some additional management and orchestration aspects of NFV, that

apply to management of virtualised resources, VNFs, and NSs.

4.5.1 Fault and performance management

Fault and performance management are functionalities that shall exist in any NFV framework. They support the

assurance aspects of the lifecycle of any Network Service instance or VNF instance, in order to provide Service Level

Agreement (SLA) management. Fault and performance management functionality is typically distributed over different

functional blocks that are dedicated among others to fault and performance measurement, resultscalculation and

aggregation, fault correlation, and fault resolution.

Fault notifications may be the result of several sources of faults: physical infrastructure (compute, storage, and

networking related faults); virtualised infrastructure (e.g. VM-related faults), and application logic (i.e. VNF instance

related faults).

ETSI

ETSI GS NFV

MAN 001 V1.1.1 (2014

12)

Fault correlation and root-cause analysis are processes that determine the reason for faults conditions and the impact of

fault conditions. Once correlated and analysed, the correlated fault information helps determining the necessary

corrective actions, and it helps triggering such actions at one or more fault resolution points, within the NFV

Framework or outside the NFV Framework (e.g. OSS).

Fault correlation can be centralized or distributed among multiple functional blocks, and no assumption is made here

regarding either. Ideally, faults should be analysed and resolved as soon as possible, hence at the functional block that

has sufficient information to perform the root-cause analysis and correlation and to determine the necessary corrective

action.

4.5.2 Policy Management

NFV policy management refers to the management of rules governing the behaviour of NFV-MANO functions

(e.g. management of VNF or NS scaling operations, access control, resource management, fault management, etc.).

Policies are defined with conditions and corresponding actions. For example, a scaling policy may state to execute the

related actions if the required conditions (e.g. VNF low CPU usage) were to manifest during runtime. Different actions

defined on the policy can be mutually exclusive resulting in process of selecting a particular action (or set of actions) to

be executed. Once declared, a policy may be bound to one or more NS instances, VNF instances, and NFVI resources.

NFV-MANO needs to support the execution of policies both automatically and manually, (e.g. by requiring manual

intervention from other operation systems, e.g. OSS/BSS).

4.5.3 Testing aspects of Network Services

As part of the NS instantiation process, as well as at any other times during the NS lifecycle, there may be a need to

perform testing (performance, operational, functional, etc.) for various reasons. For example, performance testing is a

key step of network engineering across all levels, and its main goal is to detect problems before a service goes live.

Additionally, in NFV deployments, testing has a subtle yet critical role - tuning the particular NFVI configuration. Any

sufficiently complex Network Service needs to be tested across multiple aspects, and across different network paths

(subsets or end-to-end); it can be tested as a whole, in parts (segments), or in parallel. The test plan for a Network

Service should be integrated and created as part of the design process of the service. The different ways to integrate a

test plan in a NS design are deliberately not covered by the present document.

The testing of a single VNF is a subset case of testing of an entire Network Service. In particular it is a necessary step

before placing a VNF "in service", e.g. on a new NFVI and in cases where it is determined that the VNF fails to perform

at the expected levels. Healing a VNF is a process that in some cases may require functional testing, before determining

the appropriate healing procedure.

NS testing should not impact the services provided by the NS.

NS testing procedures may be described in appropriate templates, supporting automation via the Network Service

Orchestration functions, or administered manually.

4.6 Relation of NFV management and orchestration with

existing operations and management systems

4.6.1 Overview

NFV-MANO functions play an important role in delivering the business benefits envisioned by the NFV ISG. These

benefits are achieved through interworking with other functional components in the NFV framework, as well as external

entities, such as Operations and Business Support Systems (OSS/BSS).

OSS/BSS include the collection of systems and management applications that service providers use to operate their

business. NFV is disruptive to many OSS/BSS functions, as the success of such a technology enabled business

transformation is predicated on changes in mind-sets, skillsets and toolsets to support corresponding process

re-engineering efforts.

ETSI

ETSI GS NFV

MAN 001 V1.1.1 (

2014

12)

NFV is a paradigm shift in how the networks that underpin today's service provider infrastructures are built and

operated, and how the services they deliver are managed. New degrees of freedom are introduced to the network and its

management as resources now may be added, changed, and removed dynamically. This change opens up a wave of new

business opportunities. However, a new and highly agile operational approach is needed to take full advantage of these

opportunities.

4.6.2 NFV-MANO Interworking with OSS/BSS to deliver NFV business

benefits

NFV-MANO alone cannot deliver all the NFV business benefits; it needs to integrate and interwork with other

management entities for this purpose (e.g. OSS, BSS), using interfaces offered by those entities and offering its own

interfaces to be used by external entities.

In order for service providers to achieve the full benefit of NFV, NFV-MANO solutions should be considered

holistically alongside OSS/BSS integration and management requirements. Simply extending existing OSS/BSS models

to account for virtualisation will not be sufficient, because this approach will not support the new value-added

capabilities and services provided by NFV. Efforts are needed to ensure that NFV-MANO and OSS/BSS evolution is

coordinated so as to jointly support the following:

• Open and consistent interfaces, to facilitate automation, self-service operations at service and product level

that can respond with the speed and agility required by changing business needs.

• Adaptive automation, where service usage drives on-demand resource requirements, triggering feedback from

the system that the management functions analyse and make changes to, enabling the infrastructure to provide

the resources and services needed at that point in time.

• Orchestration, where policies (and other mechanisms) can guide the decisions required to change all or part of

the system to perform a given function.

• Personalized services that are easily configured, by the operator and/or end-user at the service and/or network

resource layers, to fit individual customer preferences and requirements.

• Technology-driven innovation, where rapid development, continuous integration, deployment, and

experimentation, meet business and service operations agility and enable the migration to next generation

operations.

4.6.3 Key Challenges and Considerations

Management of end-to-end services by OSS/BSS requires convergence on a common approach to presenting

management services and management information from both legacy network systems and NFV based systems, so that

accurate end-to-end management views can be derived.

Standards are essential to achieve this convergence process. However, experience has taught the industry that this is

already a major issue for converged fixed and mobile network management including applications and services. It will

be even more acute when managing end-to-end services across a mixture of NFV functions, infrastructure, and legacy

interconnected network systems, in a highly dynamic NFV environment.

Some design patterns are used for converged fixed and mobile network operations. These patterns are shared between

interfaces, and are exposed by diverse network management systems. This enables a common way to integrate an

end-to-end view across multiple resources:

• To describe the semantics and relationships of information exchanged across management interfaces, a

federated information model that provides common and consensually defined terms, concepts, and objects is

required.

• To lower integration complexity, a set of common interface operations are required for covering request and

response patterns, as well as the behaviour and sequencing of those requests and responses for each of fault,

configuration, accounting, performance, inventory, and security management.

• To improve consistency in representing information in end-to-end applications, common data types and

common vocabularies are required. For example: specification of fault codes and location codes used across

multiple resources.

ETSI

ETSI GS NFV

MAN 001 V1.1.1 (2014

12)

This pattern based approach, developed from prior converged network management studies, can help to inform and

guide future NFV standards, open source and proof of concept project development and their integration approaches.

More importantly, it may help the industry in managing converged networks (fixed and mobile) with a similar

methodology and complementary functional realizations.

Another key challenge is automation. Operators need to speed up the ability to dynamically incorporate change. The

agile management of network functions, applications, and services provides new opportunities for revenue while

reducing costs. Automation may be supported by an aligned approach between the OSS/BSS and the NFV-MANO

functionality based on, for example:

• Open and standardized interfaces.

• Common information models.

• Mappings to different data models.

• Ability to incorporate real-time data analytics.

The key challenge in this area is to provide a flexible and dynamic policy-based management approach.

Furthermore, the need for real-time processing (in conjunction with offline processing) is an additional key challenge

that plays an increasingly important role. It is desirable to support real-time processing by automation.

The support of the processing of a huge amount of data, including data analytics, based on several data sources

(e.g. structured, semi-structured, and unstructured data from the infrastructure as well as other sources), also in real

time, is a further key challenge in the OSS/BSS and NFV context.

To address the need for dynamic operation of NFV management and orchestration, the management architecture shall

support run-time integration of management functions and processes. This is different from today's static integration, as

it implies that interfaces shall be adaptive to support business agility.

In other words, the interfaces in NFV-MANO may not need to mandate a specific list of end points based on the

information being exchanged; in contrast, they may instead allow for different entities to consume the information

based on service necessity. A loosely-coupled set of interfaces will allow services and applications, as well as

associated business and operational processes, to be data-driven and controlled by policies. This adaptive approach

further enables a steady evolution of existing legacy systems to integrate with NFV.

4.7 Administrative Domains

In a typical scenario for NFV there will not be a single organization controlling and maintaining a whole NFV system.

The organizations may either be departments of the same root organization e.g. a network department and an IT

datacentre department or they may be different companies providing different functional blocks of the NFV

Architectural Framework. The basic use cases for these scenarios are described in ETSI GS NFV 001 [i.1].

Administrative Domains can be mapped to different organizations and therefore can exist within a single service

provider or distributed among several service providers. Administrative Domains can be collapsed, resulting in different

deployment options.

For the purpose of the present document, the following administrative types of domains are identified:

• Infrastructure Domain.

• Tenant Domain.

NOTE: The present document only focuses on two types of Administrative Domains; additional domain types

may be identified later to support different deployment scenarios.

An Infrastructure Domain may be defined by different criteria (e.g. by organization, by type of resource such as

networking, compute and storage as in traditional datacentre environments, by geographical location, etc.), and multiple

Infrastructure Domains may co-exist. An Infrastructure Domain may provide infrastructure to a single or multiple

Tenant Domains. The Infrastructure Domain is application agnostic and thus has no insight of what is executed within a

VNF.

ETSI

ETSI GS NFV

MAN 001 V1.1.1 (2014

12)

A Tenant Domain may be defined by different criteria (e.g. organization, by type of Network Service, etc.), and

multiple Tenant Domains may co-exist. A Tenant Domain may use infrastructure in a single or multiple Infrastructure

Domains.

While the VNFs and Network Services reside in the Tenant Domain, in order to materialize they need the NFVI

resources from the Infrastructure Domains. Therefore the Tenant Domain consumes resources from one or more

Infrastructure Domains using the Infrastructure Domain orchestration functionality to orchestrate and operate virtual

infrastructure resources required by VNFs and Network Services built using those VNFs. Typical management tasks

within the Tenant Domain are VNF FCAPS. Typical management and orchestration tasks requiring the involvement of

both the Tenant Domain and the Infrastructure Domain are on-boarding of VNFs, instantiation of VNFs and scaling of

VNFs. The Tenant Domain is application aware, in the sense that functional blocks in this Administrative Domain

understand and support the logical functionality of the VNFs.

Other typical relationships between a Tenant Domain and an Infrastructure Domain include (non-exhaustive):

• A Tenant Domain may use VNFs belonging to that Tenant Domain and/or to other Tenant Domains, in order

to realize the Tenant Domain's Network Services.

• A Tenant Domain and an Infrastructure Domain could be mapped against the same or different organizations

(in a particular in the case when the Infrastructure Domain is offering infrastructure to a Tenant Domain).

• While typically an Infrastructure Domain provides infrastructure services to a Tenant Domain, it may also

provide infrastructure services to one or more other Infrastructure Domains.

The identification of different Administrative Domains leads to the requirement to use different management and

orchestration functionality in those domains. The cross-relationships between the different Administrative Domains

leads to the identification of the requirement that NFV-MANO functionality is not monolithic, but rather needs to be

layered: management and orchestration functionality in an Administrative Domain may provide services that are

consumed by management and orchestration functionality in a different Administrative Domain.

However, the specific mapping of Administrative Domains to NFV-MANO functions in different layers is deliberately

left out of scope for the present document, since many different mappings can be supported, depending on the specifics

of the deployment environment.

5 Management and Orchestration architectural

framework

5.1 Overview

This clause expands on the NFV Architectural Framework (ETSI GS NFV 002 [i.2]) by providing a functional

architecture with more granular distribution and a more detailed description of the NFV Management and Orchestration

(NFV-MANO) functionality, as well as a description of the reference points between NFV-MANO functional blocks

and other functional blocks in the E2E NFV reference architecture. The NFV-MANO architectural framework focuses

on the aspects brought into the operator's networks by NFV, hence mainly on the new functional blocks and reference

points between those functional blocks. Other functional blocks and reference that may be necessary for a better

understanding of the NFV-MANO architectural framework may be included and briefly described, but the detailed

description for those are in-scope for other NFV documents, which the present document references.

5.2 Principles of NFV-MANO

The NFV-MANO architectural framework relies on a set of principles that support the combination of the concepts of

distinct Administrative Domains and layered management and orchestration functionality in each of those domains:

• The architecture needs to include the possibility of multiple NFV-MANO functional blocks in the Tenant

Domain leveraging resources in the same Infrastructure Domain, and there shall a general architectural

principle of horizontal equality between those NFV-MANO functional blocks.

剩余183页未读，继续阅读

qq_41781383

粉丝: 0
资源: 1

ETSI NFV MAN001: 网络功能虚拟化管理和编排规范

NFV -Architectural Framework

gs_NFV-INF001v010101p

ETSI NFV架构框架详解：虚拟网络功能的基础设计

ETSI MEC 001

跟踪者：跟踪者：ETSI MANO NFV Orchestrator VNF经理。 请参阅https：wiki.openstack.orgwikiTacker。 在opendev.org上维护的代码镜像

ETSI关于F5G的定义和应用场景 ETSI_GR_F5G001(Generation Definition).pdf

ETSI102361

ETSI 131111

ETSI 131102

【通信技术】 F5G ETSI标准 gr_F5G001v010101p.pdf

最新资源

跟踪者：跟踪者：ETSI MANO NFV Orchestrator VNF经理。请参阅https：wiki.openstack.orgwikiTacker。在opendev.org上维护的代码镜像