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

ETSI

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

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

资源详情

资源推荐

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

etsi300132-1

etsi en 300 2

etsi en 303 396

ETSI标准和ISO标准的关系

etsi tr 101 053-3

ETSI TS 103 461

etsi en 302 065

ETSI EN 302 217

etsi ts 102 361.1

etsi 5g网络mec部署、应用

ETSI发布标准必须经过ISO批准吗

etsi es201 980

etsi en 301 489-1 v2.2.3(2019-11)是什么

1. ts 102 221 2. ts 102 2253. ts 102 2264. ts 102 671

对讲机的sar测试标准

3GPP为什么叫3GPP

802.11ax前瞻4：802.11ax与HiperLan

最新资源