[要約] RFC 8328は、ポリシー抽象化の簡素化された使用のためのポリシーベースの管理フレームワーク(SUPA)に関するものです。このRFCの目的は、ポリシーの抽象化を容易にし、ネットワーク管理者がポリシーを効果的に管理できるようにすることです。

Independent Submission                                            W. Liu
Request for Comments: 8328                           Huawei Technologies
Category: Informational                                           C. Xie
ISSN: 2070-1721                                            China Telecom
                                                            J. Strassner
                                                          G. Karagiannis
                                                     Huawei Technologies
                                                                M. Klyus
        

J. Bi Tsinghua University Y. Cheng China Unicom D. Zhang Huawei Technologies March 2018

J. Bits ingization University Y. Cheng China u Nico MD。Zhang hu A for Technologies March 2018

Policy-Based Management Framework for the Simplified Use of Policy Abstractions (SUPA)

ポリシー抽象化(SUPA)の簡素化された使用のためのポリシーベースの管理フレームワーク

Abstract

概要

The Simplified Use of Policy Abstractions (SUPA) policy-based management framework defines base YANG data models to encode policy. These models point to device-, technology-, and service-specific YANG data models developed elsewhere. Policy rules within an operator's environment can be used to express high-level, possibly network-wide, policies to a network management function (within a controller, an orchestrator, or a network element). The network management function can then control the configuration and/or monitoring of network elements and services. This document describes the SUPA basic framework, its elements, and interfaces.

ポリシー抽象化の簡略化(SUPA)ポリシーベースの管理フレームワークは、ポリシーをエンコードするための基本的なYANGデータモデルを定義します。これらのモデルは、他の場所で開発されたデバイス、テクノロジー、およびサービス固有のYANGデータモデルをポイントします。オペレーターの環境内のポリシールールを使用して、(コントローラー、オーケストレーター、またはネットワーク要素内の)ネットワーク管理機能に対して高レベルの、場合によってはネットワーク全体のポリシーを表現できます。ネットワーク管理機能は、ネットワーク要素とサービスの構成や監視を制御できます。このドキュメントでは、SUPA基本フレームワーク、その要素、およびインターフェースについて説明します。

Status of This Memo

本文書の状態

This document is not an Internet Standards Track specification; it is published for informational purposes.

このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。

This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.

これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFC Editorは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 7841のセクション2をご覧ください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8328.

このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc8328で入手できます。

Copyright Notice

著作権表示

Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.

Copyright(c)2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定(https://trustee.ietf.org/license-info)の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。

Table of Contents

目次

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Requirements Language . . . . . . . . . . . . . . . . . .   4
     2.2.  Abbreviations and Definitions . . . . . . . . . . . . . .   4
   3.  Framework for Generic Policy-Based Management . . . . . . . .   5
     3.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.2.  Operation . . . . . . . . . . . . . . . . . . . . . . . .  10
     3.3.  The GPIM and the EPRIM  . . . . . . . . . . . . . . . . .  10
     3.4.  Creation of Generic YANG Modules  . . . . . . . . . . . .  10
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
     6.2.  Informative References  . . . . . . . . . . . . . . . . .  12
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  14
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14
        
1. Introduction
1. はじめに

Traffic flows over increasingly complex enterprise and service provider networks are becoming more and more important. Meanwhile, the rapid growth of this variety makes the task of network operations and management applications deploying new services much more difficult. Moreover, network operators want to deploy new services quickly and efficiently. Two possible mechanisms for dealing with this growing difficulty are 1) the use of software abstractions to simplify the design and configuration of monitoring and control operations and 2) the use of programmatic control over the configuration and operation of such networks. Policy-based management can be used to combine these two mechanisms into an extensible framework.

ますます複雑化するエンタープライズおよびサービスプロバイダーネットワーク上のトラフィックフローは、ますます重要になっています。一方、この多様性の急速な成長により、新しいサービスを展開するネットワーク運用および管理アプリケーションのタスクははるかに困難になっています。さらに、ネットワークオペレーターは、新しいサービスを迅速かつ効率的に展開したいと考えています。この増大する困難に対処するための2つの可能なメカニズムは、1)監視および制御操作の設計と構成を簡素化するためのソフトウェア抽象化の使用、および2)そのようなネットワークの構成と操作に対するプログラム制御の使用です。ポリシーベースの管理を使用すると、これら2つのメカニズムを拡張可能なフレームワークに組み合わせることができます。

There is a set of policy rules within an operator's environment that defines how services are designed, delivered, and operated.

オペレーターの環境には、サービスの設計、提供、および運用方法を定義する一連のポリシールールがあります。

The SUPA (Simplified Use of Policy Abstractions) data model represents a high-level, possibly network-wide policy, which can be input to a network management function (within a controller, an orchestrator, or a network element). The network management function can then control the configuration and/or monitoring of network elements and services according to such policies.

SUPA(Simplified Use of Policy Abstractions)データモデルは、高レベルの、場合によってはネットワーク全体のポリシーを表し、ネットワーク管理機能(コントローラー、オーケストレーター、またはネットワーク要素内)に入力できます。ネットワーク管理機能は、このようなポリシーに従って、ネットワーク要素とサービスの構成や監視を制御できます。

SUPA defines a Generic Policy Information Model (GPIM) [SUPA-INFO] for use in network operations and management applications. The GPIM defines concepts and terminology needed by policy management independent of the form and content of the policy rule. The Event-Condition-Action (ECA) Policy Rule Information Model (EPRIM) [SUPA-INFO] extends the GPIM by defining how to build policy rules according to the ECA paradigm.

SUPAは、ネットワーク操作および管理アプリケーションで使用するためのGeneric Policy Information Model(GPIM)[SUPA-INFO]を定義しています。 GPIMは、ポリシールールの形式や内容に関係なく、ポリシー管理に必要な概念と用語を定義します。イベント条件アクション(ECA)ポリシールール情報モデル(EPRIM)[SUPA-INFO]は、ECAパラダイムに従ってポリシールールを構築する方法を定義することにより、GPIMを拡張します。

Both the GPIM and the EPRIM are targeted at controlling the configuration and monitoring of network elements throughout the service development and deployment life cycle. The GPIM and the EPRIM can both be translated into corresponding YANG [RFC6020] [RFC7950] modules that define policy concepts, terminology, and rules in a generic and interoperable manner; additional YANG modules may also be derived from the GPIM and/or EPRIM to manage specific functions.

GPIMとEPRIMはどちらも、サービスの開発と展開のライフサイクル全体を通じて、ネットワーク要素の構成と監視を制御することを目的としています。 GPIMとEPRIMは、どちらも対応するYANG [RFC6020] [RFC7950]モジュールに変換できます。これらのモジュールは、ポリシーの概念、用語、ルールを一般的かつ相互運用可能な方法で定義します。追加のYANGモジュールは、特定の機能を管理するためにGPIMやEPRIMから派生させることもできます。

The key benefit of policy management is that it enables different network elements and services to be instructed to behave the same way, even if they are programmed differently. Management applications will benefit from using policy rules that enable scalable and consistent programmatic control over the configuration and monitoring of network elements and services.

ポリシー管理の主な利点は、プログラムが異なっていても、異なるネットワーク要素とサービスが同じように動作するように指示できることです。管理アプリケーションは、ネットワーク要素とサービスの構成と監視に対するスケーラブルで一貫性のあるプログラムによる制御を可能にするポリシールールを使用することでメリットを得ます。

Some typical and useful instances for authors to understand the applicability of SUPA, such as SNMP blocking upon load of link reaching a threshold and virtual matching migration upon the changing of user location, are described in [SUPA-APP].

[SUPA-APP]では、作成者がSUPAの適用可能性を理解するためのいくつかの典型的で有用なインスタンス(リンクの負荷がしきい値に達したときのSNMPブロッキング、ユーザーの場所の変更時の仮想マッチングの移行など)について説明しています。

2. Terminology
2. 用語
2.1. Requirements Language
2.1. 要件言語

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。

2.2. Abbreviations and Definitions
2.2. 略語と定義

SUPA: The Simplified Use of Policy Abstractions is a policy-based management framework that defines a data model to be used to represent high-level, possibly network-wide policies. This data model can be input to a network management function (within a controller, an orchestrator, or a network element).

SUPA:Simplified Use of Policy Abstractionsは、高レベルの、おそらくネットワーク全体のポリシーを表すために使用されるデータモデルを定義する、ポリシーベースの管理フレームワークです。このデータモデルは、ネットワーク管理機能(コントローラー、オーケストレーター、またはネットワーク要素内)に入力できます。

YANG: An acronym for "Yet Another Next Generation". YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications [RFC6020]

YANG:「Yet Another Next Generation」の頭字語。 YANGは、ネットワーク構成プロトコル(NETCONF)、NETCONFリモートプロシージャコール、およびNETCONF通知によって操作される構成および状態データをモデル化するために使用されるデータモデリング言語です[RFC6020]

ECA: Event-Condition-Action is a shortcut for referring to the structure of active rules in event-driven architecture and active database systems.

ECA:Event-Condition-Actionは、イベント駆動型アーキテクチャーとアクティブデータベースシステムのアクティブルールの構造を参照するためのショートカットです。

EMS: An Element Management System is software used to monitor and control network elements (devices) in telecommunications.

EMS:Element Management Systemは、通信のネットワーク要素(デバイス)を監視および制御するために使用されるソフトウェアです。

NMS: A Network Management System is a set of hardware and/or software tools that allow an IT professional to supervise the individual components of a network within a larger network management framework.

NMS:ネットワーク管理システムは、ITプロフェッショナルが大規模なネットワーク管理フレームワーク内のネットワークの個々のコンポーネントを監視できるようにするハードウェアツールまたはソフトウェアツール、あるいはその両方のセットです。

OSS: An Operations/Operational Support System is a computer system used by telecommunications service providers to manage their networks (e.g., telephone networks).

OSS:運用/運用サポートシステムは、通信サービスプロバイダーがネットワーク(電話網など)を管理するために使用するコンピューターシステムです。

BSS: A Business Support System is used to support various end-to-end telecommunication services.

BSS:ビジネスサポートシステムは、さまざまなエンドツーエンドのテレコミュニケーションサービスをサポートするために使用されます。

GPIM: A Generic Policy Information Model defines concepts and terminology needed by policy management independent of the form and content of the policy rule.

GPIM:Generic Policy Information Modelは、ポリシールールの形式や内容に関係なく、ポリシー管理に必要な概念と用語を定義します。

EPRIM: An ECA Policy Rule Information Model extends the GPIM by defining how to build policy rules according to the ECA paradigm.

EPRIM:ECAポリシールール情報モデルは、ECAパラダイムに従ってポリシールールを構築する方法を定義することにより、GPIMを拡張します。

GPDM: Generic Policy Data Models [SUPA-DATA] are created from the GPIM. These YANG data model policies are used to control the configuration of network elements that model the service(s) to be managed. The relationship between the information model (IM) and data model (DM) can be founded in [RFC3444].

GPDM:Generic Policy Data Models [SUPA-DATA]はGPIMから作成されます。これらのYANGデータモデルポリシーは、管理対象のサービスをモデル化するネットワーク要素の構成を制御するために使用されます。情報モデル(IM)とデータモデル(DM)の関係は、[RFC3444]で見つけることができます。

Declarative Policy: Policies that specify the goals to be achieved but not how to achieve those goals (also called "intent-based" policies). Please note that declarative policies are out of scope for the initial phase of SUPA.

宣言的ポリシー:達成すべき目標を指定するが、それらの目標をどのように達成するかを指定しないポリシー(「意図に基づく」ポリシーとも呼ばれる)。 SUPAの初期フェーズでは、宣言型ポリシーは対象外であることに注意してください。

3. Framework for Generic Policy-Based Management
3. 一般的なポリシーベースの管理のフレームワーク

This section briefly describes the design and operation of the SUPA policy-based management framework.

このセクションでは、SUPAポリシーベースの管理フレームワークの設計と操作について簡単に説明します。

3.1. Overview
3.1. 概観

Figure 1 shows a simplified functional architecture of how SUPA is used to define policies for creating snippets of network element configurations. SUPA uses the GPIM to define a consensual vocabulary that different actors can use to interact with network elements and services. The EPRIM defines a generic structure for imperative policies. The GPIM, and/or the combination of the GPIM and the EPRIM, is converted to generic YANG modules.

図1は、SUPAを使用してネットワーク要素構成のスニペットを作成するためのポリシーを定義する方法の簡略化された機能アーキテクチャを示しています。 SUPAはGPIMを使用して、さまざまなアクターがネットワーク要素やサービスと対話するために使用できる同意語彙を定義します。 EPRIMは、必須ポリシーの一般的な構造を定義します。 GPIM、またはGPIMとEPRIMの組み合わせ、またはそのいずれかが汎用YANGモジュールに変換されます。

In one possible approach (shown with asterisks in Figure 1), SUPA Generic Policy and SUPA ECA Policy YANG modules together with the Resource and Service YANG data models specified in the IETF (which define the specific elements that will be controlled by policies) are used by the Service Interface Logic. This Service Interface Logic creates appropriate input mechanisms for the operator to define policies (e.g., a web form or a script) for creating and managing the network configuration. The operator interacts with the interface, and the policies input by operators are then translated into configuration snippets.

1つの可能なアプローチ(図1にアスタリスクで示されています)では、SUPA汎用ポリシーおよびSUPA ECAポリシーのYANGモジュールと、IETFで指定されたリソースおよびサービスのYANGデータモデル(ポリシーによって制御される特定の要素を定義)が使用されます。サービスインターフェースロジックによって。このサービスインターフェースロジックは、オペレーターがネットワーク構成を作成および管理するためのポリシー(Webフォームやスクリプトなど)を定義するための適切な入力メカニズムを作成します。オペレーターはインターフェースと対話し、オペレーターが入力したポリシーは構成スニペットに変換されます。

Note that the Resource and Service YANG data models may not exist. In this case, the SUPA generic policy YANG modules serve as an extensible basis to develop new YANG data models for the Service Interface Logic. This transfers the work specified by the Resource and Service YANG data models specified in the IETF into the Service Interface Logic.

リソースとサービスのYANGデータモデルが存在しない場合があることに注意してください。この場合、SUPA汎用ポリシーYANGモジュールは、サービスインターフェイスロジック用の新しいYANGデータモデルを開発するための拡張可能な基盤として機能します。これにより、IETFで指定されたResourceおよびService YANGデータモデルで指定された作業がService Interface Logicに転送されます。

                        +---------------------+
    +----------+       \|        SUPA         |
    |   IETF   |---+----+  Information Models |
    +----------+   |   /|    GPIM and EPRIM   |
                   |    +---------+-----------+
       Assignments |              | Defines Policy Concepts
       and Managed |             \|/
         Content   |    +---------+-----------+
                   |   \|    SUPA Generic     |
                   +----+    & ECA Policy     |
                       /|    YANG modules     |
                        +---------+-----------+
                                  *  Possible Approach
    +-----------------------------*-----------------------------+
    |  Management System          *                             |
    |                            \*/                            |
    |            Fills  +---------+---------+  +-------------+  |
    | +--------+ Forms \| Service Interface |/ |Resource and |/ | +----+
    | |Operator|--------+       Logic       +--|Service YANG |----|IETF|
    | +--------+ Runs  /| (locally defined  |\ | data models |\ | +----+
    |           scripts |forms, scripts,...)|  +-------------+  |
    |                   +---------+---------+                   |
    |                            \|/                            |
    |                     +-------+--------+                    |
    |                     |  Local Devices |                    |
    |                     | and Management |                    |
    |                     |     Systems    |                    |
    |                     +----------------+                    |
    +-----------------------------------------------------------+
        

Figure 1: SUPA Framework

ふぃぐれ 1: すぱ Fらめをrk

Figure 1 shows the SUPA Framework at a high level of abstraction. The operator actor can interact with SUPA in other ways not shown in Figure 1. In addition, other actors (e.g., an application developer) that can interact with SUPA are not shown for simplicity.

図1は、SUPAフレームワークを高レベルの抽象化で示しています。オペレーターアクターは、図1に示されていない他の方法でSUPAと対話できます。さらに、SUPAと対話できる他のアクター(たとえば、アプリケーション開発者)は、簡略化のために表示されていません。

The EPRIM defines an ECA policy as an example of imperative policies. An ECA policy rule is activated when its event clause is true; the condition clause is then evaluated and, if true, signals the execution of one or more actions in the action clause. This type of policy explicitly defines the current and desired states of the system being managed. Imperative policy rules require additional management functions, which are explained in Section 3.2.

EPRIMは、必須のポリシーの例としてECAポリシーを定義しています。 ECAポリシールールは、そのイベント句がtrueのときにアクティブになります。次に条件句が評価され、trueの場合、アクション句の1つ以上のアクションの実行を通知します。このタイプのポリシーは、管理対象のシステムの現在の状態と望ましい状態を明示的に定義します。命令型ポリシールールには、セクション3.2で説明する追加の管理機能が必要です。

Figure 2 shows how the SUPA Policy Model is used to create policy data models step-by-step and how the policy rules are used to communicate among various network management functions located on different layers.

図2は、SUPAポリシーモデルを使用してポリシーデータモデルを段階的に作成する方法と、ポリシールールを使用して異なるレイヤーにあるさまざまなネットワーク管理機能間で通信する方法を示しています。

The GPIM is used to construct policies. The GPIM defines generic policy concepts as well as two types of policies: ECA policy rules and declarative policy statements.

GPIMは、ポリシーの構築に使用されます。 GPIMは、一般的なポリシーの概念と、ECAポリシールールと宣言型ポリシーステートメントの2種類のポリシーを定義します。

A set of Generic Policy Data Models (GPDM) are then created from the GPIM. These YANG data model policies are then used to control the configuration of network elements that model the service(s) to be managed.

次に、GPIMから一連の汎用ポリシーデータモデル(GPDM)が作成されます。次に、これらのYANGデータモデルポリシーを使用して、管理対象のサービスをモデル化するネットワーク要素の構成を制御します。

Resource and Service YANG Data Models: Models of the service as well as physical and virtual network topology including the resource attributes (e.g., data rate or latency of links) and operational parameters needed to support service deployment over the network topology.

リソースとサービスのYANGデータモデル:リソースモデル(リンクのデータレートやレイテンシなど)とネットワークトポロジを介したサービスの展開をサポートするために必要な運用パラメーターを含む、サービスと物理および仮想ネットワークトポロジのモデル。

                              |  SUPA Policy Model
                              |
                              |  +----------------------------------+
                              |  | Generic Policy Information Model |
                              |  +----------------------------------+
                              |        D                 D
                              |        D   +-------------v-------------+
 +----------------------+     |        D   |   ECA Policy Rule         |
 | OSS/BSS/Orchestrator <--+  |        D   |   Information Model       |
 +----------^-----------+  |  |        D   +---------------------------+
            C              |  |        D                          D
            C              |  |  +----+D+------------------------+D+---+
            C              +-----+     D  SUPA Policy Data Model  D    |
 +----------v-----------+     |  | ----v-----------------------+  D    |
 |  EMS/NMS/Controller  <--------+ | Generic Policy Data Model |  D    |
 +----------^-----------+     |  | ----------------------------+  D    |
            C              +-----+              D                 D    |
            C              |  |  |    +---------v-----------------v--+ |
 +----------v-----------+  |  |  |    |  ECA Policy Rule Data Model  | |
 |  Network Element     <--+  |  |    +------------------------------+ |
 +----------------------+     |  +-------------------------------------+
                              |
                              |
Legend:
The double-headed arrow with Cs = "communication"
The arrow with Ds = "derived from"
        

Figure 2: SUPA Policy Model Framework

図2:SUPAポリシーモデルフレームワーク

SUPA Policy Model: This model represents one or more policy modules that contain the following entities:

SUPAポリシーモデル:このモデルは、次のエンティティを含む1つ以上のポリシーモジュールを表します。

Generic Policy Information Model: A model for defining policy rules that are independent of data repository, data definition, query, implementation language, and protocol. This model is abstract and is used for design; it MUST be turned into a data model for implementation.

Generic Policy Information Model:データリポジトリ、データ定義、クエリ、実装言語、プロトコルに依存しないポリシールールを定義するためのモデル。このモデルは抽象的であり、設計に使用されます。実装するためのデータモデルに変換する必要があります。

Generic Policy Data Model: A model of policy rules that are dependent on data repository, data definition, query, implementation language, and protocol.

Generic Policy Data Model:データリポジトリ、データ定義、クエリ、実装言語、およびプロトコルに依存するポリシールールのモデル。

ECA Policy Rule Information Model (EPRIM): This model represents a policy rule as a statement that consists of an event clause, a condition clause, and an action clause. This type of policy rule explicitly defines the current and desired states of the system being managed. This model is abstract and is used for design; it MUST be turned into a data model for implementation.

ECAポリシールール情報モデル(EPRIM):このモデルは、ポリシールールを、イベント句、条件句、およびアクション句で構成されるステートメントとして表します。このタイプのポリシールールは、管理対象のシステムの現在の状態と望ましい状態を明示的に定義します。このモデルは抽象的であり、設計に使用されます。実装するためのデータモデルに変換する必要があります。

ECA Policy Rule Data Model: A model of policy rules, derived from EPRIM, where each policy rule consists of an event clause, a condition clause, and an action clause.

ECAポリシールールデータモデル:EPRIMから派生したポリシールールのモデル。各ポリシールールは、イベント句、条件句、およびアクション句で構成されます。

EMS/NMS/Controller: This represents one or more entities that are able to control the operation and management of a network infrastructure (e.g., a network topology that consists of network elements).

EMS / NMS /コントローラー:これは、ネットワークインフラストラクチャ(ネットワーク要素で構成されるネットワークトポロジなど)の操作と管理を制御できる1つ以上のエンティティを表します。

Network Element (NE): An element that can interact with the local or remote EMS/NMS/Controller in order to exchange information, such as configuration information, policy-enforcement capabilities, and network status.

ネットワーク要素(NE):構成情報、ポリシー施行機能、ネットワークステータスなどの情報を交換するために、ローカルまたはリモートのEMS / NMS /コントローラーと対話できる要素。

Relationships among Policy, Service, and Resource models are illustrated in Figure 3.

ポリシー、サービス、およびリソースモデル間の関係を図3に示します。

         +---------------+                   +----------------+
         |    Policy     |         (1)       |    Service     |
         |               |*******************|                |
         |   ( SUPA )    |*******************| ( L3SM, ... )  |
         +---------------+                   +----------------+
                **                                  /*\
                  **                                *
                    **                            *
                 (2)  **                        *   (3)
                        **                    *
                          **                *
                            **            *
                        +-------------------+
                        |    Resource       |
                        |                   |
                        | (Inventory, ... ) |
                        +-------------------+
        

Figure 3: Relationship among Policy, Service, and Resource Models

図3:ポリシー、サービス、リソースモデル間の関係

In Figure 3:

図3:

(1) The policy manages and can adjust service behavior as necessary (1:1..n). In addition, data from resources and services are used to select and/or modify policies during runtime.

(1)ポリシーはサービスの動作を管理し、必要に応じて調整できます(1:1..n)。さらに、リソースとサービスからのデータは、実行時にポリシーを選択または変更するために使用されます。

(2) The policy manages and can adjust resource behavior as necessary (1:1..n).

(2)ポリシーはリソースの動作を管理し、必要に応じて調整できます(1:1..n)。

(3) Resource hosts service; changing resources may change service behavior as necessary.

(3)リソースホストサービス。リソースを変更すると、必要に応じてサービスの動作が変更される場合があります。

Policies are used to control the management of resources and services, while data from resources and services are used to select and/or modify policies during runtime. More importantly, policies can be used to manage how resources are allocated and assigned to services. This enables a single policy to manage one or multiple services and resources as well as their dependencies. The use of (1:1..n) in point (1) and (2) above show that one policy rule is able to manage and can adjust one or multiple services/resources. Lines (1) and (2) (connecting policy to resource and policy to service) are the same, and line (3) (connecting resource to service) is different as it's navigable only from resource to service.

ポリシーは、リソースとサービスの管理を制御するために使用され、リソースとサービスからのデータは、実行時にポリシーを選択または変更するために使用されます。さらに重要なのは、ポリシーを使用して、リソースがサービスに割り当てられ、割り当てられる方法を管理できることです。これにより、1つのポリシーで1つまたは複数のサービスとリソース、およびそれらの依存関係を管理できます。上記のポイント(1)と(2)で(1:1..n)を使用すると、1つのポリシールールで1つまたは複数のサービス/リソースを管理および調整できることがわかります。行(1)と(2)(ポリシーをリソースに、ポリシーをサービスに接続)は同じです。行(3)(リソースをサービスに接続)は、リソースからサービスにのみナビゲートできるため、異なります。

3.2. Operation
3.2. 操作

SUPA can be used to define various types of policies, including policies that affect services and/or the configuration of individual network elements or groups of network elements. SUPA can be used by a centralized and/or distributed set of entities for creating, managing, interacting with, and retiring policy rules.

SUPAを使用して、サービスに影響を与えるポリシーや個々のネットワーク要素またはネットワーク要素のグループの構成を含むさまざまなタイプのポリシーを定義できます。 SUPAは、ポリシールールを作成、管理、操作、および廃止するために、集中および/または分散されたエンティティセットで使用できます。

The SUPA scope is limited to policy information and data models. SUPA does not define network resource data models or network service data models; both are out of scope. Instead, SUPA makes use of network resource data models defined by other working groups or Standards Development Organizations (SDOs).

SUPAスコープは、ポリシー情報とデータモデルに限定されます。 SUPAはネットワークリソースデータモデルまたはネットワークサービスデータモデルを定義しません。どちらも範囲外です。代わりに、SUPAは他のワーキンググループまたは標準開発組織(SDO)によって定義されたネットワークリソースデータモデルを利用します。

Declarative policies are out of scope for the initial phase of SUPA.

宣言的ポリシーは、SUPAの初期段階では対象外です。

3.3. The GPIM and the EPRIM
3.3. GPIMとEPRIM

The GPIM provides a shared vocabulary for representing concepts that are common to different types of policies, but which are independent of language, protocol, repository, and level of abstraction. Hence, the GPIM defines concepts and vocabulary needed by policy management systems independent of the form and content of the policy. The EPRIM is a more specific model that refines the GPIM to specify policy rules in an ECA form.

GPIMは、異なるタイプのポリシーに共通であるが、言語、プロトコル、リポジトリ、および抽象化のレベルに依存しない概念を表すための共有ボキャブラリを提供します。したがって、GPIMは、ポリシーの形式や内容に関係なく、ポリシー管理システムが必要とする概念と語彙を定義します。 EPRIMは、GPIMを改良してECAフォームでポリシールールを指定する、より具体的なモデルです。

This enables different policies at different levels of abstraction to form a continuum, where more abstract policies can be translated into more concrete policies and vice versa. For example, the information model can be extended by generalizing concepts from an existing data model into the GPIM; the GPIM extensions can then be used by other data models.

これにより、さまざまな抽象化レベルのさまざまなポリシーが連続体を形成でき、より抽象的なポリシーをより具体的なポリシーに変換したり、その逆を行うことができます。たとえば、情報モデルは、既存のデータモデルの概念をGPIMに一般化することで拡張できます。 GPIM拡張は他のデータモデルで使用できます。

3.4. Creation of Generic YANG Modules
3.4. ジェネリックYANGモジュールの作成

An information model is abstract. As such, it cannot be directly instantiated (i.e., objects cannot be created directly from it). Therefore, both the GPIM and the combination of the GPIM and the EPRIM are translated into generic YANG modules.

情報モデルは抽象的です。そのため、直接インスタンス化することはできません(つまり、オブジェクトを直接インスタンス化することはできません)。したがって、GPIMと、GPIMとEPRIMの組み合わせの両方が、汎用のYANGモジュールに変換されます。

SUPA will provide guidelines for translating the GPIM (or the combination of the GPIM and the EPRIM) into concrete YANG data models that define how to manage and communicate policies between systems. Multiple imperative policy YANG data models may be instantiated from the GPIM (or the combination of the GPIM and the EPRIM). In particular, SUPA will specify a set of YANG data models that will consist of a base policy model for representing policy management concepts independent of the type or structure of a policy; it will also specify an extension for defining policy rules according to the ECA paradigm. (Note: This means that policies can be defined using the GPIM directly, or using the combination of the GPIM and the EPRIM. If you use only the GPIM, you get a technology- and vendor-independent information model that you are free to map to the data model of your choice; note that the structure of a policy is NOT defined. If you use the GPIM and the EPRIM, you get a technology-and vendor-independent information model that defines policies as an ECA policy rule (i.e., imperative).)

SUPAは、GPIM(またはGPIMとEPRIMの組み合わせ)を、システム間のポリシーの管理および通信方法を定義する具体的なYANGデータモデルに変換するためのガイドラインを提供します。複数の必須ポリシーYANGデータモデルは、GPIM(またはGPIMとEPRIMの組み合わせ)からインスタンス化できます。特に、SUPAは一連のYANGデータモデルを指定します。これは、ポリシーのタイプや構造に関係なく、ポリシー管理の概念を表すための基本ポリシーモデルで構成されます。また、ECAパラダイムに従ってポリシールールを定義するための拡張機能も指定します。 (注:これは、GPIMを直接使用して、またはGPIMとEPRIMの組み合わせを使用してポリシーを定義できることを意味します。GPIMのみを使用する場合、自由にマップできるテクノロジおよびベンダーに依存しない情報モデルを取得します選択したデータモデルに追加します。ポリシーの構造は定義されていないことに注意してください。GPIMとEPRIMを使用すると、ECAポリシールールとしてポリシーを定義する、テクノロジーおよびベンダーに依存しない情報モデル(つまり、必須)。

The process of developing the GPIM, the EPRIM, and the derived/ translated YANG data models is realized following the sequence shown below. After completing this process and, if the implementation of the YANG data models requires it, the GPIM and EPRIM and the derived/ translated YANG data models are updated and synchronized.

GPIM、EPRIM、および派生/変換されたYANGデータモデルの開発プロセスは、以下に示すシーケンスに従って実現されます。このプロセスを完了した後、YANGデータモデルの実装で必要な場合は、GPIMとEPRIM、および派生/変換されたYANGデータモデルが更新され、同期されます。

      (1)=>(2)=>(3)=>(4)=>(3')=>(2')=>(1')
        
      Where:
      (1)=GPIM
      (2)=EPRIM
      (3)=YANG data models
      (4)=Implementation
      (3')=update of YANG data models
      (2')=update of EPRIM
      (1')=update of GPIM
        

The YANG module derived from the GPIM contains concepts and terminology for the common operation and administration of policy-based systems as well as an extensible structure for policy rules of different paradigms. The YANG module derived from the EPRIM extends the generic nature of the GPIM by representing policies using an ECA structure.

GPIMから派生したYANGモジュールには、ポリシーベースのシステムの一般的な操作と管理の概念と用語、およびさまざまなパラダイムのポリシールールの拡張可能な構造が含まれています。 EPRIMから派生したYANGモジュールは、ECA構造を使用してポリシーを表すことにより、GPIMの一般的な性質を拡張します。

The above sequence allows for the addition of new model elements, as well as the editing of existing ones, in the GPIM and EPRIM. In practice, the implementation sequence may be much simpler. Specifically, it is unlikely that the GPIM will need to be changed. In addition, changes to the EPRIM will likely be focused on fine-tuning the behavior offered by a specific set of model elements.

上記のシーケンスにより、GPIMおよびEPRIMで新しいモデル要素を追加したり、既存のモデル要素を編集したりできます。実際には、実装シーケンスははるかに簡単です。具体的には、GPIMの変更が必要になることはほとんどありません。さらに、EPRIMへの変更は、特定のモデル要素のセットによって提供される動作の微調整に重点が置かれる可能性があります。

4. Security Considerations
4. セキュリティに関する考慮事項

This informational document presents the framework and workflow of SUPA as well as an explanation on the relationship of policy, service and resources. This document does not introduce any new security issues, and the framework has no security impact on the Internet. The same considerations are relevant as those for the base NETCONF protocol (see Section 9 in [RFC6241]).

この情報ドキュメントでは、SUPAのフレームワークとワークフロー、およびポリシー、サービス、リソースの関係について説明しています。このドキュメントでは新しいセキュリティの問題は紹介されておらず、フレームワークはインターネットにセキュリティの影響を与えません。基本的なNETCONFプロトコルと同じ考慮事項が関連しています([RFC6241]のセクション9を参照)。

5. IANA Considerations
5. IANAに関する考慮事項

This document has no IANA actions.

このドキュメントにはIANAアクションはありません。

6. References
6. 参考文献
6.1. Normative References
6.1. 引用文献

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。

6.2. Informative References
6.2. 参考引用

[RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between Information Models and Data Models", RFC 3444, DOI 10.17487/RFC3444, January 2003, <https://www.rfc-editor.org/info/rfc3444>.

[RFC3444] Pras、A。およびJ. Schoenwaelder、「情報モデルとデータモデルの違いについて」、RFC 3444、DOI 10.17487 / RFC3444、2003年1月、<https://www.rfc-editor.org/info/ rfc3444>。

[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, <https://www.rfc-editor.org/info/rfc6020>.

[RFC6020] Bjorklund、M。、編、「YANG-ネットワーク構成プロトコル(NETCONF)のデータモデリング言語」、RFC 6020、DOI 10.17487 / RFC6020、2010年10月、<https://www.rfc-editor。 org / info / rfc6020>。

[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>.

[RFC6241] Enns、R。、編、Bjorklund、M。、編、Schoenwaelder、J。、編、およびA. Bierman、編、「Network Configuration Protocol(NETCONF)」、RFC 6241、DOI 10.17487 / RFC6241、2011年6月、<https://www.rfc-editor.org/info/rfc6241>。

[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>.

[RFC7950] Bjorklund、M。、編、「The YANG 1.1 Data Modeling Language」、RFC 7950、DOI 10.17487 / RFC7950、2016年8月、<https://www.rfc-editor.org/info/rfc7950>。

[SUPA-APP] Cheng, Y., Liu, D., Fu, B., Zhang, D., and N. Vadrevu, "Applicability of SUPA", Work in Progress, draft-cheng-supa-applicability-01, March 2017.

[SUPA-APP] Cheng、Y.、Liu、D.、Fu、B.、Zhang、D.、N。Vadrevu、「SUPAの適用性」、進行中の作業、draft-cheng-supa-applicability-01、 2017年3月。

[SUPA-DATA] Halpern, J., Strassner, J., and S. Van der Meer, "Generic Policy Data Model for Simplified Use of Policy Abstractions (SUPA)", Work in Progress, draft-ietf-supa-generic-policy-data-model-04, June 2017.

[SUPA-DATA] Halpern、J.、Strassner、J。、およびS. Van der Meer、「ポリシー抽象化の簡略化された使用のための一般的なポリシーデータモデル(SUPA)」、進行中の作業、draft-ietf-supa-generic- policy-data-model-04、2017年6月。

[SUPA-FRAME] Zhou, C., Contreras, L., Sun, Q., and P. Yegani, "The Framework of Simplified Use of Policy Abstractions (SUPA)", Work in Progress, draft-zhou-supa-framework-02, May 2015.

[SUPA-FRAME] Zhou、C.、Contreras、L.、Sun、Q。、およびP. Yegani、「ポリシー抽象化の単純化された使用のフレームワーク(SUPA)」、進行中の作業、ドラフト-zhou-supa-framework 2015年5月2日。

[SUPA-INFO] Strassner, J., Halpern, J., and S. Meer, "Generic Policy Information Model for Simplified Use of Policy Abstractions (SUPA)", Work in Progress, draft-ietf-supa-generic-policy-info-model-03, May 2017.

[SUPA-INFO] Strassner、J.、Halpern、J。、およびS. Meer、「ポリシー抽象化(SUPA)の簡易使用のための一般的なポリシー情報モデル」、進行中の作業、draft-ietf-supa-generic-policy- info-model-03、2017年5月。

[SUPA-STATE] Karagiannis, G., Strassner, J., Sun, Q., Contreras, L., Yegani, P., and J. Bi, "Problem Statement for Simplified Use of Policy Abstractions (SUPA)", Work in Progress, draft-karagiannis-supa-problem-statement-07, June 2015.

[SUPA-STATE] Karagiannis、G.、Strassner、J.、Sun、Q.、Contreras、L.、Yegani、P。、およびJ. Bi、「ポリシー抽象化(SUPA)の簡略化された使用に関する問題ステートメント」、作業進行中、draft-karagiannis-supa-problem-statement-07、2015年6月。

[SUPA-VALUE] Klyus, M., Strassner, J., Liu, W., Karagiannis, G., and J. Bi, "SUPA Value Proposition", Work in Progress, draft-klyus-supa-value-proposition-00, March 2016.

[SUPA-VALUE] Klyus、M.、Strassner、J.、Liu、W.、Karagiannis、G。、およびJ. Bi、「SUPA Value Proposition」、進行中の作業、draft-klyus-supa-value-proposition- 2016年3月00日。

Acknowledgements

謝辞

This document has benefited from reviews, suggestions, comments, and proposed text provided by the following members, listed in alphabetical order: Andy Bierman, Marc Blanchet, Mohamed Boucadair, Scott O. Bradner, Scott Cadzow, Zhen Cao, Vikram Choudhary, Benoit Claise, Spencer Dawkins, Mehmet Ersue, Ian Farrer, Fernando Gont, Joel Halpern, Jonathan Hansford, Jing Huang, Xing Li, Marco Liebsch, Diego R. Lopez, Johannes Merkle, Marie-Jose Montpetit, Kostas Pentikousis, Simon Perreault, Hosnieh Rafiee, Raghav Rao, Jose Saldana, Jon Saperia, Tom Taylor, Jean Francois Tremblay, Tina Tsou, Eric Voit, Gunter Wang, Yangyang Wang, Bert Wijnen, and Tianran Zhou.

このドキュメントは、次のメンバーから提供されたレビュー、提案、コメント、および提案されたテキストから恩恵を受けています。アルファベット順に記載されています。 、スペンサー・ドーキンス、メフメット・エルスエ、イアン・ファラー、フェルナンド・ゴント、ジョエル・ハルパーン、ジョナサン・ハンスフォード、ジン・ファン、シン・リー、マルコ・リープシュ、ディエゴ・R・ロペス、ヨハネス・メルクル、マリー・ホセ・モンプティ、コスタス・ペンティコウシス、シモン・ラロー、ホスニーRaghav Rao、Jose Saldana、Jon Saperia、Tom Taylor、Jean Francois Tremblay、Tina Tsou、Eric Voit、Gunter Wang、Yangyang Wang、Bert Wijnen、およびTianran Zhou。

Part of the initial draft of this document was picked up from previous documents: [SUPA-VALUE], [SUPA-STATE], and [SUPA-FRAME]. We appreciatively acknowledge the authors, contributors, and acknowledged parties of those documents.

このドキュメントの最初のドラフトの一部は、以前のドキュメント[SUPA-VALUE]、[SUPA-STATE]、および[SUPA-FRAME]から抜粋されています。私たちはそれらの文書の著者、貢献者、そして承認された関係者に感謝します。

Contributors

貢献者

The following people contributed to the creation of this document, listed in alphabetical order:

以下の人々がこのドキュメントの作成に貢献しました。アルファベット順にリストされています。

Luis M. Contreras, Telefonica I+D Dan Romascanu, Avaya Juergen Schoenwaelder, Jacobs University, Germany Qiong Sun, China Telecom Parviz Yegani, Huawei Technologies Cathy Zhou, Huawei Technologies

Luis M. Contreras、Telefonica I + D Dan Romascanu、Avaya Juergen Schoenwaelder、Jacobs University、ドイツQiong Sun、中国Telecom Parviz Yegani、Huawei Technologies Cathy Zhou、Huawei Technologies

Authors' Addresses

著者のアドレス

Will (Shucheng) Liu Huawei Technologies Bantian, Longgang District Shenzhen 518129 China

will(Shu成)l IU hu Aはテクノロジー禁止の日であり、長いだけの地区は非常に現実的です518129中国

   Email: liushucheng@huawei.com
        

Chongfeng Xie China Telecom China Telecom Information Technology Innovation Park Beijing 102209 China

C Red Maple X IE China Telecom China Telecom Information Technology Innovation Park Beijing 102209 China

Email: xiechf.bri@chinatelecom.cn John Strassner Huawei Technologies 2330 Central Expressway Santa Clara, CA 95138 United States of America

メール:xiechf.bri@chinatelecom.cn John Strassner Huawei Technologies 2330 Central Expressway Santa Clara、CA 95138 United States of America

   Email: john.sc.strassner@huawei.com
        

Georgios Karagiannis Huawei Technologies Hansaallee 205 Dusseldorf 40549 Germany

Georgios Karagiannis Huawei Technologies Hansaallee 205デュッセルドルフ40549ドイツ

   Email: Georgios.Karagiannis@huawei.com
        

Maxim Klyus

マキシムクライウス

   Email: xmaruto@gmail.com
        

Jun Bi Tsinghua University Network Research Center, Tsinghua University Beijing 100084 China

Jun Bi清華大学ネットワーク研究センター、清華大学北京100084中国

   Email: junbi@tsinghua.edu.cn
        

Ying Cheng China Unicom No.21 Financial Street, XiCheng District Beijing 100033 China

ying Cheng China u伱com no.21 Financial Street、ξCheng District Beijing 100033 China

   Email: chengying10@chinaunicom.cn
        

Dacheng Zhang Huawei Technologies Beijing China

DAは技術中国北京として張胡Aになります

   Email: dacheng.zhang@huawei.com