[要約] RFC 8309は、サービスモデルの説明とその目的を提供する。要約すると、このRFCは、異なるサービスモデルの特徴と利点を説明し、ネットワークアーキテクチャの設計に役立つ情報を提供する。
Internet Engineering Task Force (IETF) Q. Wu
Request for Comments: 8309 W. Liu
Category: Informational Huawei Technologies
ISSN: 2070-1721 A. Farrel
Juniper Networks
January 2018
Service Models Explained
サービスモデルの説明
Abstract
概要
The IETF has produced many modules in the YANG modeling language. The majority of these modules are used to construct data models to model devices or monolithic functions.
IETFは、YANGモデリング言語で多くのモジュールを作成しています。これらのモジュールの大部分は、デバイスまたはモノリシック関数をモデル化するためのデータモデルを構築するために使用されます。
A small number of YANG modules have been defined to model services (for example, the Layer 3 Virtual Private Network Service Model (L3SM) produced by the L3SM working group and documented in RFC 8049).
少数のYANGモジュールがサービスをモデル化するために定義されています（たとえば、L3SMワーキンググループによって作成され、RFC 8049に文書化されているレイヤー3仮想プライベートネットワークサービスモデル（L3SM））。
This document describes service models as used within the IETF and also shows where a service model might fit into a software-defined networking architecture. Note that service models do not make any assumption of how a service is actually engineered and delivered for a customer; details of how network protocols and devices are engineered to deliver a service are captured in other modules that are not exposed through the interface between the customer and the provider.
このドキュメントでは、IETF内で使用されるサービスモデルについて説明し、サービスモデルがソフトウェア定義ネットワーキングアーキテクチャに適合する可能性がある場所も示します。サービスモデルは、サービスが実際にどのように設計され、顧客に提供されるかを想定していないことに注意してください。サービスを提供するためにネットワークプロトコルとデバイスがどのように設計されているかの詳細は、顧客とプロバイダーの間のインターフェイスを通じて公開されていない他のモジュールに取り込まれます。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 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/rfc8309.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8309で入手できます。
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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terms and Concepts . . . . . . . . . . . . . . . . . . . . . 4
3. Using Service Models . . . . . . . . . . . . . . . . . . . . 7
3.1. Practical Considerations . . . . . . . . . . . . . . . . 8
4. Service Models in an SDN Context . . . . . . . . . . . . . . 8
5. Possible Causes of Confusion . . . . . . . . . . . . . . . . 11
6. Comparison with Other Work . . . . . . . . . . . . . . . . . 13
6.1. Comparison with Network Service Models . . . . . . . . . 13
6.2. Service Delivery and Network Element Model Work . . . . . 15
6.3. Customer Service Model Work . . . . . . . . . . . . . . . 16
6.4. The MEF Architecture . . . . . . . . . . . . . . . . . . 17
7. Further Concepts . . . . . . . . . . . . . . . . . . . . . . 18
7.1. Technology Agnostic . . . . . . . . . . . . . . . . . . . 18
7.2. Relationship to Policy . . . . . . . . . . . . . . . . . 18
7.3. Operator-Specific Features . . . . . . . . . . . . . . . 19
7.4. Supporting Multiple Services . . . . . . . . . . . . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
9. Manageability Considerations . . . . . . . . . . . . . . . . 20
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
11.1. Normative References . . . . . . . . . . . . . . . . . . 21
11.2. Informative References . . . . . . . . . . . . . . . . . 21
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
In recent years, the number of modules written in the YANG modeling language [RFC6020] for configuration and monitoring has blossomed. Many of these are used for device-level configuration (for example, [RFC7223]) or for control of monolithic functions or protocol instances (for example, [RFC7407]).
近年、構成と監視のためにYANGモデリング言語[RFC6020]で記述されたモジュールの数が増加しています。これらの多くは、デバイスレベルの構成（[RFC7223]など）や、モノリシック関数やプロトコルインスタンス（[RFC7407]など）の制御に使用されます。
[RFC7950] makes a distinction between a "data model", which it defines as describing how data is represented and accessed, and a "YANG module", which defines hierarchies of schema nodes to make a self-contained and compilable block of definitions and inclusions. YANG structures data models into modules for ease of use.
[RFC7950]は、データの表現方法とアクセス方法を記述するものとして定義されている「データモデル」と、スキーマノードの階層を定義して自己完結型のコンパイル可能な定義ブロックを作成する「YANGモジュール」を区別します。インクルージョン。 YANGは、使いやすいようにデータモデルをモジュールに構造化します。
Within the context of Software-Defined Networking (SDN) [RFC7149] [RFC7426], YANG data modules may be used on the interface between a controller and network devices, as well as between network orchestrators and controllers. There may also be a hierarchy of such components with super controllers, domain controllers, and device controllers all exchanging information and instructions using YANG modules.
Software-Defined Networking（SDN）[RFC7149] [RFC7426]のコンテキスト内では、YANGデータモジュールは、コントローラーとネットワークデバイスの間のインターフェース、およびネットワークオーケストレーターとコントローラーの間で使用できます。スーパーコントローラー、ドメインコントローラー、およびデバイスコントローラーがすべてYANGモジュールを使用して情報と命令を交換する、このようなコンポーネントの階層がある場合もあります。
There has been interest in using YANG to define and document data models that describe services in a portable way that is independent of which network operator uses the model, for example, the Layer 3 Virtual Private Network Service Model (L3SM) [RFC8049]. Such models may be used in manual and even paper-driven service request processes with a gradual transition to IT-based mechanisms. Ultimately, they could be used in online, software-driven dynamic systems and may be used as part of an SDN system.
YANGを使用して、どのネットワークオペレーターがモデルを使用するかとは関係なく、ポータブルな方法でサービスを記述するデータモデルを定義および文書化することに関心がありました。たとえば、レイヤー3仮想プライベートネットワークサービスモデル（L3SM）[RFC8049]です。このようなモデルは、ITベースのメカニズムへの段階的な移行を伴う手動の、さらには紙駆動のサービス要求プロセスで使用される場合があります。最終的には、オンラインのソフトウェア駆動の動的システムで使用でき、SDNシステムの一部として使用できます。
This document explains the scope and purpose of service models within the IETF (and is limited to within the scope of the IETF) and describes how a service model can be used by a network operator. Equally, this document clarifies what a service model is not and dispels some common misconceptions.
このドキュメントでは、IETF内のサービスモデルの範囲と目的（およびIETFの範囲内に限定されます）について説明し、ネットワークオペレーターがサービスモデルを使用する方法について説明します。同様に、このドキュメントは、サービスモデルが何でないかを明確にし、いくつかの一般的な誤解を払拭します。
The document also shows where a service model might fit into an SDN architecture, but it is important to note that a service model does not require or preclude the use of SDN. Note that service models do not make any assumption of how a service is actually engineered and delivered to a customer; details of how network protocols and devices are engineered to deliver a service are captured in other modules that are not exposed through the interface between the customer and the provider.
このドキュメントには、サービスモデルがSDNアーキテクチャに適合する可能性がある場所も示されていますが、サービスモデルはSDNの使用を要求または排除しないことに注意することが重要です。サービスモデルは、サービスが実際にどのように設計され、顧客に提供されるかを想定していないことに注意してください。サービスを提供するためにネットワークプロトコルとデバイスがどのように設計されているかの詳細は、顧客とプロバイダーの間のインターフェイスを通じて公開されていない他のモジュールに取り込まれます。
In summary, a service model is a formal representation of the data elements that describe a network service as that service is described to or requested by a customer of a network operator. Details included in the service model include a description of the service as experienced by the customer, but not features of how that service is delivered or realized by the service provider.
要約すると、サービスモデルは、ネットワークサービスを記述するデータ要素の正式な表現であり、そのサービスはネットワークオペレーターの顧客に対して記述または要求されます。サービスモデルに含まれる詳細には、顧客が体験したサービスの説明が含まれますが、サービスプロバイダーがそのサービスを提供または実現する方法の機能は含まれません。
Other work on classifying YANG modules has been done in [RFC8199]. That document provides an important reference for this document and also uses the term "service module". In this document, Section 6.1 provides a comparison between these two uses of the same terminology.
YANGモジュールの分類に関する他の作業は[RFC8199]で行われました。このドキュメントは、このドキュメントの重要なリファレンスであり、「サービスモジュール」という用語も使用しています。このドキュメントでは、6.1節で、同じ用語のこれら2つの使用法を比較しています。
Readers should familiarize themselves with the description and classification of YANG modules provided in [RFC8199].
読者は、[RFC8199]で提供されているYANGモジュールの説明と分類に慣れる必要があります。
The following terms are used in this document:
このドキュメントでは、次の用語が使用されています。
Network Operator: This term is used to refer to the company that owns and operates one or more networks that provide Internet connectivity services and/or other services.
ネットワークオペレーター：この用語は、インターネット接続サービスやその他のサービスを提供する1つ以上のネットワークを所有および運営する会社を指すために使用されます。
Customer: This term refers to someone who purchases a service (including connectivity) from a network operator. In the context of this document, a customer is usually a company that runs their own network or computing platforms and wishes to connect to the Internet or between sites. Such a customer may operate an enterprise network or a data center. Sometimes this term may also be used to refer to the individual in such a company who contracts to buy services from a network operator. A customer as described here is a separate commercial operation from the network operator, but some companies may operate with internal customers so that, for example, an IP/MPLS packet network may be the customer of an optical transport network.
顧客：この用語は、ネットワークオペレーターからサービス（接続を含む）を購入する人を指します。このドキュメントのコンテキストでは、顧客は通常、独自のネットワークまたはコンピューティングプラットフォームを実行し、インターネットまたはサイト間への接続を希望する企業です。このような顧客は、企業ネットワークまたはデータセンターを運営している場合があります。時には、この用語は、ネットワーク事業者からサービスを購入することを契約しているそのような会社の個人を指すために使用されることもあります。ここで説明する顧客は、ネットワークオペレータとは別の商用事業ですが、一部の企業は内部の顧客と事業を行っているため、たとえば、IP / MPLSパケットネットワークが光伝送ネットワークの顧客になる場合があります。
Service: A network operator delivers one or more services to a customer. A service in the context of this document (sometimes called a Network Service) is some form of connectivity between customer sites and the Internet or between customer sites across the network operator's network and across the Internet. However, a distinction should be drawn between the parameters that describe a service as included in a customer service model (see the definition of this term, below) and a Service Level Agreement (SLA), as discussed in Sections 5 and 7.2.
サービス：ネットワークオペレーターは、1つ以上のサービスを顧客に提供します。このドキュメントのコンテキストでのサービス（ネットワークサービスと呼ばれることもあります）は、顧客サイトとインターネットの間、またはネットワークオペレーターのネットワーク全体とインターネット全体の顧客サイト間の何らかの形の接続です。ただし、セクション5および7.2で説明するように、カスタマーサービスモデル（この用語の定義は以下を参照）に含まれるサービスを記述するパラメーターと、サービスレベルアグリーメント（SLA）を区別する必要があります。
A service may be limited to simple connectivity (such as IP-based Internet access), may be a tunnel (such as a virtual circuit), or may involve more complex connectivity (such as in a multisite virtual private network). Services may be further enhanced by additional functions providing security, load balancing, accounting, and so forth. Additionally, services usually include guarantees of quality, throughput, and fault reporting.
サービスは、単純な接続（IPベースのインターネットアクセスなど）に制限されたり、トンネル（仮想回線など）であったり、より複雑な接続（マルチサイト仮想プライベートネットワークなど）を含む場合があります。セキュリティ、ロードバランシング、アカウンティングなどを提供する追加機能により、サービスをさらに強化できます。さらに、サービスには通常、品質、スループット、および障害報告の保証が含まれます。
This document makes a distinction between a service as delivered to a customer (that is, the service as discussed on the interface between a customer and the network operator) and the service as realized within the network (as described in [RFC8199]). This distinction is discussed further in Section 6.
このドキュメントでは、顧客に提供されるサービス（つまり、顧客とネットワークオペレーター間のインターフェースで説明されるサービス）と、ネットワーク内で実現されるサービス（[RFC8199]で説明）を区別しています。この違いについては、セクション6でさらに説明します。
Readers may also refer to [RFC7297] for an example of how an IP connectivity service may be characterized.
読者は、IP接続サービスの特徴の例として[RFC7297]も参照できます。
Data Model: The information model (IM) and data model (DM) concepts are described in [RFC3444]. That document defines a data model by contrasting it with the definition of an IM as follows:
データモデル：情報モデル（IM）およびデータモデル（DM）の概念は、[RFC3444]で説明されています。そのドキュメントは、次のようにIMの定義と対比することによってデータモデルを定義します。
The main purpose of an IM is to model managed objects at a conceptual level, independent of any specific implementations or protocols used to transport the data. The degree of specificity (or detail) of the abstractions defined in the IM depends on the modeling needs of its designers. In order to make the overall design as clear as possible, an IM should hide all protocol and implementation details. Another important characteristic of an IM is that it defines relationships between managed objects.
IMの主な目的は、データの転送に使用される特定の実装やプロトコルに関係なく、管理対象オブジェクトを概念レベルでモデル化することです。 IMで定義された抽象化の特異性（または詳細）の程度は、その設計者のモデリングのニーズに依存します。全体的な設計をできるだけ明確にするために、IMはすべてのプロトコルと実装の詳細を隠す必要があります。 IMのもう1つの重要な特徴は、管理対象オブジェクト間の関係を定義することです。
DMs, conversely, are defined at a lower level of abstraction and include many details. They are intended for implementors and include protocol-specific constructs.
逆に、DMはより低い抽象化レベルで定義され、多くの詳細を含みます。これらは実装者向けであり、プロトコル固有の構成が含まれています。
As mentioned in Section 1, this document also uses the terms "data model" and "YANG module" as defined in [RFC7950].
セクション1で述べたように、このドキュメントでは、[RFC7950]で定義されている「データモデル」および「YANGモジュール」という用語も使用しています。
Service Model: A service model is a specific type of data model. It describes a service and the parameters of the service in a portable way that can be used uniformly and independent of the equipment and operating environment. The service model may be divided into the two following categories:
サービスモデル：サービスモデルは、特定のタイプのデータモデルです。サービスとサービスのパラメータを、機器や動作環境に関係なく均一に使用できるポータブルな方法で記述します。サービスモデルは、次の2つのカテゴリに分類できます。
Customer Service Model: A customer service model is used to describe a service as offered or delivered to a customer by a network operator as shown in Figure 1. It can be used by a human (via a user interface such as a GUI, web form, or Command-Line Interface (CLI)) or by software to configure or request a service and may equally be consumed by a human (such as via an order fulfillment system) or by a software component. Such models are sometimes referred to simply as "service models" [RFC8049]. A customer service model is expressed in a YANG module as a core set of parameters that are common across network operators: additional features that are specific to the offerings of individual network operators would be defined in extensions or augmentations of the module. Except where specific technology details are directly pertinent to the customer (such as encapsulations or mechanisms applied on access links), customer service models are technology agnostic so that the customer does not have influence over or knowledge of how the network operator engineers the service.
カスタマーサービスモデル：カスタマーサービスモデルは、図1に示すように、ネットワークオペレーターが顧客に提供または提供するサービスを表すために使用されます。GUI、Webフォームなどのユーザーインターフェイスを介して、人間が使用できます。 、またはコマンドラインインターフェイス（CLI））、またはサービスを構成または要求するためのソフトウェアによって、人間（注文処理システムなど）またはソフトウェアコンポーネントによって等しく消費される場合があります。そのようなモデルは、単に「サービスモデル」と呼ばれることもあります[RFC8049]。カスタマーサービスモデルは、YANGモジュールで、ネットワークオペレーター全体に共通のパラメーターのコアセットとして表現されます。個々のネットワークオペレーターの提供に固有の追加機能は、モジュールの拡張または拡張で定義されます。特定のテクノロジーの詳細が直接お客様に関係する場合（アクセスリンクに適用されるカプセル化やメカニズムなど）を除き、カスタマーサービスモデルはテクノロジーにとらわれないため、ネットワークオペレーターがサービスを設計する方法に影響を与えたり、知識を持たせたりすることはありません。
An example of where such details are relevant to the customer is when they describe the behavior or interactions on the interface between the equipment at the customer site (often referred to as the Customer Edge or CE equipment) and the equipment at the network operator's site (usually referred to as the Provider Edge or PE equipment).
そのような詳細が顧客に関連する例は、顧客サイトの装置（カスタマーエッジまたはCE装置と呼ばれることが多い）とネットワークオペレーターのサイトの装置（通常、プロバイダーエッジまたはPE機器と呼ばれます）。
Service Delivery Model: A service delivery model is used by a network operator to define and manage how a service is engineered in the network. It can be used by a human operator (such as via a management station) or by a software tool to instruct network components. The YANG modules that encode such models are sometimes referred to as "network service YANG modules" [RFC8199] and are consumed by "external systems" such as an Operations Support System (OSS). A service delivery module is expressed as a core set of parameters that are common across a network type and technology: additional features that are specific to the configuration of individual vendor equipment or proprietary protocols would be defined in extensions or augmentations of the module. Service delivery modules include technology-specific modules.
サービス提供モデル：サービス提供モデルは、ネットワークでサービスがどのように設計されているかを定義および管理するためにネットワークオペレーターによって使用されます。これは、（管理ステーションなどを介して）人間のオペレーターが使用したり、ネットワークコンポーネントを指示するソフトウェアツールを使用したりできます。このようなモデルをエンコードするYANGモジュールは、「ネットワークサービスYANGモジュール」[RFC8199]と呼ばれることがあり、運用サポートシステム（OSS）などの「外部システム」によって使用されます。サービスデリバリモジュールは、ネットワークタイプとテクノロジー全体で共通のコアパラメータセットとして表現されます。個々のベンダーの機器または独自のプロトコルの構成に固有の追加機能は、モジュールの拡張または拡張で定義されます。サービス提供モジュールには、テクノロジー固有のモジュールが含まれます。
The distinction between a customer service model and a service delivery model needs to be clarified. The modules that encode a customer service model are not used to directly configure network devices, protocols, or functions: it is not something that is sent to network devices (i.e., routers or switches) for processing. Equally, the modules that encode a customer service model do not describe how a network operator realizes and delivers the service described by the module. This distinction is discussed further in later sections.
カスタマーサービスモデルとサービス提供モデルの違いを明確にする必要があります。カスタマーサービスモデルをエンコードするモジュールは、ネットワークデバイス、プロトコル、または機能を直接構成するためには使用されません。処理のためにネットワークデバイス（ルーターやスイッチなど）に送信されるものではありません。同様に、顧客サービスモデルをエンコードするモジュールは、ネットワークオペレーターがモジュールによって記述されたサービスを実現および提供する方法を記述していません。この違いについては、後のセクションで詳しく説明します。
As already indicated, customer service models are used on the interface between customers and network operators. This is shown in Figure 1.
すでに示したように、カスタマーサービスモデルは、カスタマーとネットワークオペレータ間のインターフェイスで使用されます。これを図1に示します。
The language in which a customer service model is described is a choice for whoever specifies the model. The IETF uses the YANG data modeling language defined in [RFC6020].
カスタマーサービスモデルが記述される言語は、モデルを指定する人にとっての選択です。 IETFは、[RFC6020]で定義されているYANGデータモデリング言語を使用します。
The encoding and communication protocol used to exchange a customer service model between the customer and network operator is specific to deployment and implementation. The IETF has standardized the NETCONF protocol [RFC6241] and the RESTCONF protocol [RFC8040] for interactions "on the wire" between software components with data encoded in XML or JSON. However, co-located software components might use an internal API, while systems with more direct human interactions might use web pages or even paper forms. Where direct human interaction comes into play, interface interactions may be realized via business practices that may introduce some margin of error, thus raising the priority for automated, deterministic interfaces.
カスタマーとネットワークオペレーター間でカスタマーサービスモデルを交換するために使用されるエンコーディングおよび通信プロトコルは、展開と実装に固有です。 IETFは、NETCONFプロトコル[RFC6241]とRESTCONFプロトコル[RFC8040]を標準化し、データをXMLまたはJSONでエンコードしたソフトウェアコンポーネント間の「オンザワイヤ」のやり取りを実現しました。ただし、同じ場所に配置されたソフトウェアコンポーネントは内部APIを使用し、人間との直接的なやり取りがあるシステムはWebページまたは紙のフォームを使用する場合があります。人間との直接的なやり取りが関係する場合、ビジネスプラクティスを介してインターフェイスのやり取りが実現され、ある程度の誤差が生じる可能性があるため、自動化された確定的なインターフェイスの優先度が高くなります。
-------------- Customer ----------------------
| | Service Model | |
| Customer | <-----------------> | Network Operator |
| | | |
-------------- ----------------------
Figure 1: The Customer Service Models Used on the Interface between Customers and Network Operators
図1：顧客とネットワーク事業者間のインターフェイスで使用される顧客サービスモデル
How a network operator processes a customer's service request when described with a customer service model depends on the commercial and operational tools, processes, and policies used by the network operator. These may vary considerably from one network operator to another.
カスタマーサービスモデルで記述されたときにネットワークオペレーターがカスタマーのサービスリクエストを処理する方法は、ネットワークオペレーターが使用する商用および運用ツール、プロセス、およびポリシーによって異なります。これらは、ネットワークオペレーターによってかなり異なる場合があります。
However, the intent is that the network operator maps the service request into configuration and operational parameters that control one or more networks to deliver the requested services. That means that the network operator (or software run by the network operator) takes the information in the customer service model and determines how to deliver the service by enabling and configuring network protocols and devices. They may achieve this by constructing service delivery models and passing them to network orchestrators or controllers. The use of standard customer service models eases service delivery by means of automation.
ただし、その意図は、ネットワークオペレーターがサービス要求を1つ以上のネットワークを制御する構成パラメーターと操作パラメーターにマップして、要求されたサービスを提供することです。つまり、ネットワークオペレーター（またはネットワークオペレーターが実行するソフトウェア）は顧客サービスモデルの情報を取得し、ネットワークプロトコルとデバイスを有効にして構成することにより、サービスを提供する方法を決定します。彼らは、サービス提供モデルを構築し、それらをネットワークオーケストレーターまたはコントローラーに渡すことにより、これを実現する場合があります。標準の顧客サービスモデルを使用すると、自動化によってサービス提供が容易になります。
The practicality of customer service models has been repeatedly debated. It has been suggested that network operators have radically different business models and widely diverse commercial offerings, which makes a common customer service model impractical. However, L3SM [RFC8049] results from the consensus of multiple individuals working at network operators and offers a common core of service options that can be augmented according to the needs of individual network operators.
顧客サービスモデルの実用性は繰り返し議論されてきました。ネットワークオペレーターは、根本的に異なるビジネスモデルと広く多様な商用サービスを提供しているため、一般的な顧客サービスモデルは非現実的であることが示唆されています。ただし、L3SM [RFC8049]は、ネットワークオペレーターで働く複数の個人の合意の結果であり、個々のネットワークオペレーターのニーズに応じて拡張できるサービスオプションの共通コアを提供します。
It has also been suggested that there should be a single, base customer service module, and that details of individual services should be offered as extensions or augmentations of this. It is quite possible that a number of service parameters (such as the identity and postal address of a customer) will be common, and it would be a mistake to define them multiple times (once in each customer service model). However, the distinction between a 'module' and a 'model' should be considered at this point: modules are how the data for models is logically broken out and documented, especially for reuse in multiple models.
また、単一のベースカスタマーサービスモジュールが必要であり、個々のサービスの詳細は、この拡張または拡張として提供する必要があることも示唆されています。多くのサービスパラメータ（顧客のIDや住所など）が一般的である可能性が高く、それらを複数回（各顧客サービスモデルで1回）定義するのは誤りです。ただし、この時点では「モジュール」と「モデル」の区別を考慮する必要があります。モジュールは、特に複数のモデルで再利用するために、モデルのデータを論理的に分割して文書化する方法です。
In an SDN system, the management of network resources and protocols is performed by software systems that determine how best to utilize the network. Figure 2 shows a sample architectural view of an SDN system where network elements are programmed by a component called an "SDN controller" (or "controller" for short) and where controllers are instructed by an orchestrator that has a wider view of the whole of, or part of, a network. The internal organization of an SDN control plane is specific to deployment.
SDNシステムでは、ネットワークリソースとプロトコルの管理は、ネットワークを最適に利用する方法を決定するソフトウェアシステムによって実行されます。図2は、SDNシステムのアーキテクチャビューの例を示しています。ここでは、ネットワーク要素が「SDNコントローラー」（略して「コントローラー」）と呼ばれるコンポーネントによってプログラムされており、コントローラー全体の全体像がより広いオーケストレーターによって指示されています。 、またはネットワークの一部。 SDNコントロールプレーンの内部構成は、展開に固有です。
------------------
| |
| Orchestrator |
| |
.------------------.
. : .
. : .
------------ ------------ ------------
| | | | | |
| Controller | | Controller | | Controller |
| | | | | |
------------ ------------ ------------
: . . :
: . . :
: . . :
--------- --------- --------- ---------
| Network | | Network | | Network | | Network |
| Element | | Element | | Element | | Element |
--------- --------- --------- ---------
Figure 2: A Sample SDN Architecture
図2：サンプルSDNアーキテクチャ
A customer's service request is (or should be) technology agnostic. That is, a customer is unaware of the technology that the network operator has available to deliver the service, so the customer does not make requests specific to the underlying technology but is limited to making requests specific to the service that is to be delivered. The orchestrator must map the service request to its view, and this mapping may include a choice of which networks and technologies to use depending on which service features have been requested.
顧客のサービスリクエストは、テクノロジーにとらわれない（またはそうである必要があります）。つまり、顧客は、ネットワークオペレータがサービスを提供するために利用できるテクノロジーを認識していないため、基盤となるテクノロジーに固有のリクエストを行うのではなく、配信されるサービスに固有のリクエストを行うことに限定されます。オーケストレーターはサービス要求をそのビューにマップする必要があります。このマッピングには、要求されたサービス機能に応じて、使用するネットワークとテクノロジーの選択が含まれる場合があります。
One implementation option to achieve this mapping is to split the orchestration function between a "Service Orchestrator" and a "Network Orchestrator" as shown in Figure 3.
このマッピングを実現する1つの実装オプションは、図3に示すように、オーケストレーション機能を「Service Orchestrator」と「Network Orchestrator」の間で分割することです。
Customer
------------------ Service ----------
| | Model | |
| Service |<-------->| Customer |
| Orchestrator | (a) | |
| | ----------
------------------
. .
. . (b) -----------
. (b) . ......|Application|
. . : | BSS/OSS |
. . : -----------
. Service Delivery . :
. Model . :
------------------ ------------------
| | | |
| Network | | Network |
| Orchestrator | | Orchestrator |
| | | |
.------------------ ------------------.
. : : .
. : Network Configuration : .
. : Model : .
------------ ------------ ------------ ------------
| | | | | | | |
| Controller | | Controller | | Controller | | Controller |
| | | | | | | |
------------ ------------ ------------ ------------
: . . : :
: . . Device : :
: . . Configuration : :
: . . Model : :
--------- --------- --------- --------- ---------
| Network | | Network | | Network | | Network | | Network |
| Element | | Element | | Element | | Element | | Element |
--------- --------- --------- --------- ---------
Figure 3: An Example SDN Architecture with a Service Orchestrator
図3：Service Orchestratorを使用したSDNアーキテクチャの例
Figure 3 also shows where different data models might be applied within the architecture. The device configuration models are used by a controller to set parameters on an individual network element. The network configuration models are used by a network orchestrator to instruct controllers (which may each be responsible for multiple network elements) how to configure parts of a network.
図3は、アーキテクチャ内のさまざまなデータモデルが適用される場所も示しています。コントローラは、デバイス構成モデルを使用して、個々のネットワーク要素にパラメータを設定します。ネットワーク構成モデルは、ネットワークオーケストレーターがコントローラー（複数のネットワーク要素をそれぞれ担当する可能性がある）にネットワークの一部を構成する方法を指示するために使用されます。
The following examples illustrate the split between control components that expose a "service interface" that is present in many figures that show extended SDN architectures:
次の例は、拡張SDNアーキテクチャを示す多くの図に存在する「サービスインターフェイス」を公開する制御コンポーネント間の分割を示しています。
o Figure 1 of [RFC7426] shows a separation of the "Application Plane", the "Network Services Abstraction Layer (NSAL)", and the "Control Plane". It marks the "Service Interface" as situated between the NSAL and the control plane.
o [RFC7426]の図1は、「アプリケーションプレーン」、「ネットワークサービスアブストラクションレイヤー（NSAL）」、および「コントロールプレーン」の分離を示しています。 NSALとコントロールプレーンの間にある「サービスインターフェイス」にマークを付けます。
o Figure 1 of [RFC7491] shows an interface between an "Application Service Coordinator" and an "Application-Based Network Operations Controller".
o [RFC7491]の図1は、「アプリケーションサービスコーディネーター」と「アプリケーションベースのネットワークオペレーションコントローラー」間のインターフェースを示しています。
o Figure 1 of [RFC8199] shows an interface from an OSS or a Business Support System (BSS) that is expressed in "Network Service YANG Modules".
o [RFC8199]の図1は、「Network Service YANG Modules」で表現されるOSSまたはビジネスサポートシステム（BSS）からのインターフェースを示しています。
This can all lead to some confusion around the definition of a "service interface" and a "service model". Some previous literature considers the interface northbound of the network orchestrator (labeled "(b)" in Figure 3) to be a "service interface" used by an application, but the service described at this interface is network centric and is aware of many features, such as topology, technology, and operator policy. Thus, we make a distinction between this type of service interface and the more abstract service interface (labeled "(a)" in Figure 3) where the service is described by a service model and the interaction is between the customer and network operator. Further discussion of this point is provided in Section 5.
これはすべて、「サービスインターフェース」と「サービスモデル」の定義に関する混乱を招く可能性があります。以前のいくつかの文献では、ネットワークオーケストレーターのノースバウンドインターフェース（図3で「（b）」とラベル付けされている）をアプリケーションが使用する「サービスインターフェース」と見なしていますが、このインターフェースで記述されるサービスはネットワーク中心であり、多くの機能を認識しています、トポロジ、テクノロジー、オペレータポリシーなど。したがって、このタイプのサービスインターフェイスとより抽象的なサービスインターフェイス（図3で「（a）」のラベルが付いている）を区別します。サービスはサービスモデルによって記述され、相互作用は顧客とネットワークオペレーターの間で行われます。この点については、セクション5で詳しく説明します。
In discussing service models, there are several possible causes of confusion:
サービスモデルの説明では、混乱の原因がいくつか考えられます。
o The services we are discussing are connectivity services provided by network operators to customers; the services are achieved by manipulating the network resources of the operator's network. This is a completely different thing to "Foo as a Service" (for example, Storage as a Service (SaaS)) where a service provider offers reachability to a value-added service that is provided at some location in the network using other resources (compute, storage, ...) that are not part of the network itself. The confusion arises not only because of the use of the word "service" in both cases, but also because network operators may offer both types of service to their customers.
o ここで取り上げるサービスは、ネットワークオペレータが顧客に提供する接続サービスです。サービスは、オペレーターのネットワークのネットワークリソースを操作することによって実現されます。これは、「Foo as a Service」（たとえば、Storage as a Service（SaaS））とはまったく異なります。サービスプロバイダーは、他のリソースを使用してネットワーク内のある場所で提供される付加価値サービスに到達可能性を提供します（コンピューティング、ストレージ、...）ネットワーク自体の一部ではありません。混乱は、両方のケースで「サービス」という単語が使用されているためだけでなく、ネットワークオペレータが両方のタイプのサービスを顧客に提供している可能性があるためにも発生します。
o Network operation is normally out of scope in the discussion of services between a network operator and a customer. That means that the customer service model does not reveal to the customer anything about how the network operator delivers the service, nor does the model expose details of technology or network resources used to provide the service (all of these details could, in any case, be considered security vulnerabilities). For example, in the simple case of point-to-point virtual link connectivity provided by a network tunnel (such as an MPLS pseudowire), the network operator does not expose the path through the network that the tunnel follows. Of course, this does not preclude the network operator from taking guidance from the customer (such as to avoid routing traffic through a particular country) or from disclosing specific details (such as might be revealed by a route trace), but these are not standard features of the service as described in the customer service model.
o ネットワーク運用は、通常、ネットワーク事業者と顧客の間のサービスの議論では範囲外です。つまり、顧客サービスモデルは、ネットワークオペレーターがサービスを提供する方法について顧客に何も明らかにせず、サービスの提供に使用されるテクノロジーまたはネットワークリソースの詳細を公開しません（これらの詳細はすべて、いずれの場合でも、セキュリティの脆弱性と見なされます）。たとえば、ネットワークトンネル（MPLS疑似配線など）によって提供されるポイントツーポイント仮想リンク接続の単純なケースでは、ネットワークオペレーターは、トンネルがたどるネットワーク経由のパスを公開しません。もちろん、これはネットワークオペレーターが顧客からのガイダンス（特定の国へのトラフィックのルーティングを回避するなど）や特定の詳細（ルートトレースによって明らかになる可能性があるなど）の開示を排除するものではありませんが、これらは標準ではありませんカスタマーサービスモデルで説明されているサービスの機能。
o The network operator may use further data models (service delivery models) that help to describe how the service is realized in the network. These models might be used on the interface between the service orchestrator and the network orchestrator, as shown in Figure 3, and might include many of the pieces of information from the customer service model alongside protocol parameters and device configuration information. [RFC8199] also terms these data models as "service models" and encodes them as "Network Service YANG Modules"; a comparison is provided in Section 6.1. It is important that the service orchestrator be able to map from a customer service model to these service delivery models, but they are not the same thing.
o ネットワークオペレーターは、ネットワークでサービスがどのように実現されるかを説明するのに役立つ追加のデータモデル（サービス配信モデル）を使用できます。これらのモデルは、図3に示すように、サービスオーケストレーターとネットワークオーケストレーターの間のインターフェースで使用される場合があり、プロトコルパラメーターやデバイス構成情報とともに、カスタマーサービスモデルからの情報の多くを含む場合があります。 [RFC8199]は、これらのデータモデルを「サービスモデル」とも呼び、「ネットワークサービスYANGモジュール」としてエンコードします。比較はセクション6.1で提供されます。サービスオーケストレータが顧客サービスモデルからこれらのサービス提供モデルにマッピングできることが重要ですが、それらは同じものではありません。
o Commercial terms (such as "cost per byte", "cost per minute", and "scoped by quality and type of service", as well as terms related to payment) are generally not a good subject for standardization. It is possible that some network operators will enhance standard customer service models to include commercial information, but the way this is done is likely to vary widely between network operators. Thus, this feature is out of scope for standardized customer service models.
o 商用用語（「バイトあたりのコスト」、「分あたりのコスト」、「サービスの品質と種類によって範囲が定められている」、および支払いに関連する用語など）は、一般的に標準化の対象にはなりません。一部のネットワークオペレーターは、標準の顧客サービスモデルを強化して商業情報を含めることができますが、その方法はネットワークオペレーターによって大きく異なる可能性があります。したがって、この機能は標準化されたカスタマーサービスモデルの範囲外です。
o SLAs have a high degree of overlap with the definition of services present in customer service models. Requests for specific bandwidth, for example, might be present in a customer service model, and agreement to deliver a service is a commitment to the description of the service in the customer service model. However, SLAs typically include a number of fine-grained details about how services are allowed to vary, by how much, and how often. SLAs are also linked to commercial terms with penalties and so forth and thus are also not good topics for standardization. As with commercial terms, it is expected that some network operators will enhance standard customer service models to include SLA parameters either using their own work or depending on material from standards bodies that specialize in this topic, but this feature is out of scope for the IETF's customer service models.
o SLAは、顧客サービスモデルに存在するサービスの定義と高度に重複しています。たとえば、特定の帯域幅の要求は顧客サービスモデルに存在する可能性があり、サービスを提供することへの同意は、顧客サービスモデルでのサービスの説明への取り組みです。ただし、SLAには通常、サービスをどのように、どれだけ、どれだけの頻度で変更できるかについて、多くの細かい詳細が含まれています。 SLAは、ペナルティなどを伴う商用条件にもリンクされているため、標準化に適したトピックでもありません。商業用語と同様に、一部のネットワークオペレーターは、独自の作業を使用するか、このトピックに特化した標準化団体の資料に応じてSLAパラメーターを含めるように標準のカスタマーサービスモデルを拡張することが予想されますが、この機能はIETFの範囲外ですカスタマーサービスモデル。
If a network operator chooses to express an SLA using a data model, that model might be referenced as an extension or an augmentation of the customer service model.
ネットワークオペレーターがデータモデルを使用してSLAを表現することを選択した場合、そのモデルはカスタマーサービスモデルの拡張または拡張として参照される可能性があります。
Other work has classified YANG modules, produced parallel architectures, and developed a range of YANG modules. This section briefly examines that other work and shows how it fits with the description of service models introduced in this document.
その他の作業では、YANGモジュールを分類し、並列アーキテクチャを作成し、さまざまなYANGモジュールを開発しました。このセクションでは、他の作業について簡単に検討し、このドキュメントで紹介されているサービスモデルの説明とどのように適合するかを示します。
As previously noted, [RFC8199] provides a classification of YANG modules. It introduces the term "Network Service YANG Module" to identify the type of module used to "describe the configuration, state data, operations, and notifications of abstract representations of services implemented on one or multiple network elements." These modules are used to construct the service delivery models as described in this document; that is, they are the modules used on the interface between the service orchestrator or OSS/BSS and the network orchestrator, as shown in Figure 3.
前述のように、[RFC8199]はYANGモジュールの分類を提供します。 「ネットワークサービスYANGモジュール」という用語を導入して、「1つまたは複数のネットワーク要素に実装されたサービスの抽象的な表現の構成、状態データ、操作、および通知を記述する」ために使用されるモジュールのタイプを識別します。これらのモジュールは、このドキュメントで説明されているように、サービス提供モデルを構築するために使用されます。つまり、図3に示すように、これらはサービスオーケストレータまたはOSS / BSSとネットワークオーケストレータの間のインターフェースで使用されるモジュールです。
Figure 1 of [RFC8199] can be modified to make this more clear and to include an additional example of a Network Service YANG module, as shown in Figure 4. As can be seen, the highest classification of modules collects those that are used to deliver operations support and business support. These might be consumed by an Operations Support System (OSS) or a Business Support System (BSS), and a service orchestrator may form part of an OSS/BSS or may be a separate component. This highest layer in the figure is divided into the customer service modules that are used to describe services to a customer as discussed in this document, and other modules that describe further OSS/BSS functions such as billing and SLAs.
[RFC8199]の図1を変更して、これをより明確にし、図4に示すように、Network Service YANGモジュールの追加例を含めることができます。ご覧のように、モジュールの最も高い分類は、配信に使用されるモジュールを収集します運用サポートとビジネスサポート。これらは、運用サポートシステム（OSS）またはビジネスサポートシステム（BSS）によって使用される可能性があり、サービスオーケストレータはOSS / BSSの一部を形成する場合もあれば、別個のコンポーネントである場合もあります。図のこの最上位層は、このドキュメントで説明するように顧客へのサービスを説明するために使用される顧客サービスモジュールと、課金やSLAなどのOSS / BSS機能をさらに説明する他のモジュールに分かれています。
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Operations Support and Business Support YANG Modules
+-----------------------+ +-----------------------+
| | | |
| Customer Service | | Other |
| YANG Modules | | Operations Support |
| | | and |
| +------+ +------+ | | Business Support |
| | | | | | | YANG Modules |
| | L2SM | | L3SM | | | |
| | | | | | | |
| +------+ +------+ | | |
| | | |
+-----------------------+ +-----------------------+
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Network Service YANG Modules
+------------+ +-------------+ +-------------+ +-------------+
| | | | | | | |
| - L2VPN | | - L2VPN | | EVPN | | L3VPN |
| - VPWS | | - VPLS | | | | |
| | | | | | | |
+------------+ +-------------+ +-------------+ +-------------+
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Network Element YANG Modules
+------------+ +------------+ +-------------+ +------------+
| | | | | | | |
| MPLS | | BGP | | IPv4 / IPv6 | | Ethernet |
| | | | | | | |
+------------+ +------------+ +-------------+ +------------+
Key: EVPN: Ethernet Virtual Private Network L2SM: Layer 2 Virtual Private Network Service Model L2VPN: Layer 2 Virtual Private Network L3SM: Layer 3 Virtual Private Network Service Model L3VPN: Layer 3 Virtual Private Network VPLS: Virtual Private LAN Service VPWS: Virtual Private Wire Service
キー：EVPN：イーサネット仮想プライベートネットワークL2SM：レイヤー2仮想プライベートネットワークサービスモデルL2VPN：レイヤー2仮想プライベートネットワークL3SM：レイヤー3仮想プライベートネットワークサービスモデルL3VPN：レイヤー3仮想プライベートネットワークVPLS：仮想プライベートLANサービスVPWS：仮想プライベートワイヤーサービス
Figure 4: YANG Module Abstraction Layers Showing Customer Service Modules
図4：カスタマーサービスモジュールを示すYANGモジュールアブストラクションレイヤー
A number of IETF working groups are developing YANG modules related to services. These models focus on how the network operator configures the network through protocols and devices to deliver a service. Some of these models are classified as network service delivery models (also called service delivery models or network configuration models depending on the level at which they are pitched), while others have details that are related to specific element configuration and so are classed as network element models (also called device models).
多くのIETFワーキンググループが、サービスに関連するYANGモジュールを開発しています。これらのモデルは、ネットワークオペレーターがプロトコルとデバイスを介してネットワークを構成し、サービスを提供する方法に焦点を当てています。これらのモデルの一部は、ネットワークサービス提供モデル（提案されたレベルに応じてサービス提供モデルまたはネットワーク構成モデルとも呼ばれます）として分類されますが、特定の要素構成に関連する詳細を持ち、ネットワーク要素として分類されます。モデル（デバイスモデルとも呼ばれます）。
A sample set of these models is listed here:
これらのモデルのサンプルセットを以下に示します。
o [BGP-L3VPN-YANG] defines a YANG module that can be used to configure and manage BGP L3VPNs.
o [BGP-L3VPN-YANG]は、BGP L3VPNの構成と管理に使用できるYANGモジュールを定義します。
o [L2VPN-YANG] documents a data model that is expected to be used by the management tools run by the network operators in order to manage and monitor the network resources that they use to deliver L2VPN services.
o [L2VPN-YANG]は、L2VPNサービスを提供するために使用するネットワークリソースを管理および監視するために、ネットワークオペレーターによって実行される管理ツールによって使用されることが予想されるデータモデルを文書化しています。
o [EVPN-YANG] defines YANG modules for delivering an Ethernet VPN service.
o [EVPN-YANG]は、イーサネットVPNサービスを提供するためのYANGモジュールを定義します。
Several initiatives within the IETF are developing customer service models. The L3SM presents the L3VPN service, as described by a network operator, to a customer. Figure 5, which is reproduced from [RFC8049], shows that the L3SM is a customer service model as described in this document.
IETF内のいくつかのイニシアチブは、顧客サービスモデルを開発しています。 L3SMは、ネットワークオペレーターが説明するL3VPNサービスを顧客に提供します。 [RFC8049]から複製された図5は、L3SMがこのドキュメントで説明されているカスタマーサービスモデルであることを示しています。
L3VPN-SVC |
MODEL |
|
+------------------+ +-----+
| Orchestration | < --- > | OSS |
+------------------+ +-----+
| |
+----------------+ |
| Config manager | |
+----------------+ |
| |
| Netconf/CLI ...
| |
+------------------------------------------------+
Network
Figure 5: The L3SM Service Architecture
図5：L3SMサービスアーキテクチャ
A Layer 2 VPN Service Model (L2SM) is defined in [L2VPN-SERVICE]. That model's usage is described as in Figure 6, which is a reproduction of Figure 5 from that document. As can be seen, the L2SM is a customer service model as described in this document.
レイヤ2 VPNサービスモデル（L2SM）は[L2VPN-SERVICE]で定義されています。そのモデルの使用法は、図6のように記述されています。これは、そのドキュメントからの図5の複製です。見てわかるように、L2SMは、このドキュメントで説明されているカスタマーサービスモデルです。
----------------------------
| Customer Service Requester |
----------------------------
|
L2VPN |
Service |
Model |
|
-----------------------
| Service Orchestration |
-----------------------
|
| Service +-------------+
| Delivery +------>| Application |
| Model | | BSS/OSS |
| V +-------------+
-----------------------
| Network Orchestration |
-----------------------
| |
+----------------+ |
| Config manager | |
+----------------+ | Device
| | Models
| |
--------------------------------------------
Network
Figure 6: The L2SM Service Architecture
図6：L2SMサービスアーキテクチャ
The MEF Forum (MEF) has developed an architecture for network management and operation. It is documented as the Lifecycle Service Orchestration (LSO) Reference Architecture and is illustrated in Figure 2 of [MEF-55].
MEFフォーラム（MEF）は、ネットワークの管理と運用のためのアーキテクチャを開発しました。これはライフサイクルサービスオーケストレーション（LSO）リファレンスアーキテクチャとして文書化されており、[MEF-55]の図2に示されています。
The work of the MEF embraces all aspects of Lifecycle Service Orchestration, including billing, SLAs, order management, and lifecycle management. The IETF's work on service models is typically smaller and offers a simple, self-contained service YANG module. This does not invalidate either approach: it only observes that they are different approaches.
MEFの作業には、請求、SLA、注文管理、ライフサイクル管理など、ライフサイクルサービスオーケストレーションのすべての側面が含まれます。 IETFのサービスモデルに関する作業は一般的に小さく、シンプルな自己完結型のサービスYANGモジュールを提供します。これはどちらのアプローチも無効にしません。異なるアプローチであることのみを観察します。
This section introduces a few further, more advanced concepts.
このセクションでは、さらにいくつかの高度な概念を紹介します。
Service models should generally be technology agnostic. That is to say, the customer should not care how the service is provided so long as the service is delivered.
サービスモデルは通常、テクノロジーにとらわれないものである必要があります。つまり、サービスが提供されている限り、顧客はサービスの提供方法を気にする必要はありません。
However, some technologies reach to the customer site and impact the type of service delivered. Such features do need to be described in the service model.
ただし、一部のテクノロジーは顧客サイトに到達し、提供されるサービスの種類に影響を与えます。このような機能は、サービスモデルで説明する必要があります。
Two examples are as follows:
2つの例を次に示します。
o The data passed between customer equipment and network operator equipment will be encapsulated in a specific way, and that data-plane type forms part of the service.
o カスタマー機器とネットワークオペレーター機器の間で受け渡されるデータは特定の方法でカプセル化され、そのデータプレーンタイプはサービスの一部を形成します。
o Protocols that are run between customer equipment and network operator equipment (for example, Operations, Administration, and Maintenance (OAM) protocols, protocols for discovery, or protocols for exchanging routing information) need to be selected and configured as part of the service description.
o カスタマー機器とネットワークオペレーター機器の間で実行されるプロトコル（たとえば、運用、管理、および保守（OAM）プロトコル、検出用のプロトコル、またはルーティング情報を交換するためのプロトコル）は、サービスの説明の一部として選択および構成する必要があります。
Policy appears as a crucial function in many places during network orchestration. A service orchestrator will, for example, apply the network operator's policies to determine how to provide a service for a particular customer (possibly considering commercial terms). However, the policies within a service model are limited to those over which a customer has direct influence and that are acted on by the network operator.
ポリシーは、ネットワークオーケストレーション中に多くの場所で重要な機能として表示されます。たとえば、サービスオーケストレータは、ネットワークオペレータのポリシーを適用して、特定の顧客にサービスを提供する方法を決定します（おそらく商業的条件を考慮します）。ただし、サービスモデル内のポリシーは、顧客が直接影響を及ぼし、ネットワークオペレーターによって実行されるポリシーに限定されます。
The policies that express desired behavior of services on occurrence of specific events are close to SLA definitions: they should only be included in the base service model where they are common offerings of all network operators. Policies that describe which person working for a customer may request or modify services (that is, authorization) are close to commercial terms: they, too, should only be included in the base service model where they are common offerings of all network operators.
特定のイベントの発生時にサービスの望ましい動作を表現するポリシーは、SLA定義に近いものです。すべてのネットワークオペレーターに共通して提供される基本サービスモデルにのみ含める必要があります。顧客のために働いている人がサービスを要求または変更する可能性があることを説明するポリシー（つまり、承認）は商取引条件に近いものです。これらも、すべてのネットワークオペレーターに共通の提供である基本サービスモデルにのみ含める必要があります。
As with commercial terms and SLAs discussed in Section 5, it is expected that some network operators will enhance standard customer service models to include policy parameters either using their own work or depending on specific policy models built in the IETF or other standards bodies.
セクション5で説明した商取引条件およびSLAと同様に、一部のネットワークオペレーターは、標準のカスタマーサービスモデルを拡張して、独自の作業を使用するか、IETFまたは他の標準化団体で構築された特定のポリシーモデルに応じて、ポリシーパラメーターを含めることが期待されます。
Nevertheless, policy is so important that all service models should be designed to be easily extensible to allow policy components to be added and associated with services as needed.
それでも、ポリシーは非常に重要なので、すべてのサービスモデルは、ポリシーコンポーネントを必要に応じて追加し、サービスに関連付けることができるように簡単に拡張できるように設計する必要があります。
When work on the L3SM was started, there was some doubt as to whether network operators would be able to agree on a common description of the services that they offer to their customers because, in a competitive environment, each markets the services in a different way with different additional features. However, the working group was able to agree on a core set of features that multiple network operators were willing to consider as "common". They also understood that, should an individual network operator want to describe additional features (operator-specific features), they could do so by extending or augmenting the L3SM model.
L3SMの作業が開始されたとき、競争の激しい環境ではサービスの販売方法が異なるため、ネットワーク事業者が顧客に提供するサービスの共通の説明に同意できるかどうかについて、いくつかの疑問がありました。さまざまな追加機能を備えています。しかし、ワーキンググループは、複数のネットワークオペレーターが「共通」と見なすことをいとわない機能のコアセットについて合意することができました。また、個々のネットワークオペレーターが追加の機能（オペレーター固有の機能）を説明したい場合は、L3SMモデルを拡張または拡張することで説明できることも理解していました。
Thus, when a basic description of a core service is agreed upon and documented in a service model, it is important that that model be easily extended or augmented by each network operator so that the standardized model can be used in a common way and only the operator-specific features be varied from one environment to another.
したがって、コアサービスの基本的な説明が合意され、サービスモデルに文書化される場合、標準化されたモデルを共通の方法でのみ使用できるように、そのモデルを各ネットワークオペレーターが簡単に拡張または拡張できることが重要です。オペレーター固有の機能は、環境によって異なります。
Network operators will, in general, offer many different services to their customers. Each would normally be the subject of a separate service model.
ネットワーク事業者は、一般に、顧客にさまざまなサービスを提供します。通常、それぞれが個別のサービスモデルの対象になります。
Whether each service model is handled by a specialized service orchestrator that is able to provide tuned behavior for a specific service, or whether all service models are handled by a single service orchestrator, is an implementation and deployment choice.
各サービスモデルが特定のサービスの調整された動作を提供できる専用のサービスオーケストレーターによって処理されるか、またはすべてのサービスモデルが単一のサービスオーケストレーターによって処理されるかは、実装と展開の選択です。
It is expected that, over time, certain elements of the service models will be seen to repeat in each model. An example of such an element is the postal address of the customer.
時間の経過とともに、サービスモデルの特定の要素が各モデルで繰り返されることが予想されます。このような要素の例は、顧客の住所です。
It is anticipated that, while access to such information from each service model is important, the data will be described in its own module and may form part of the service model either by inclusion or by index.
各サービスモデルからのそのような情報へのアクセスは重要ですが、データは独自のモジュールで記述され、インクルードまたはインデックスによってサービスモデルの一部を形成することが予想されます。
The interface between customer and service provider is a commercial interface, and it needs to be subject to appropriate confidentiality. Additionally, knowledge of what services are provided to a customer or delivered by a network operator may supply information that can be used in a variety of security attacks. The service model itself will expose security-related parameters for the specific service where the related function is available to the customer.
顧客とサービスプロバイダーの間のインターフェイスは商用インターフェイスであり、適切な機密性の対象となる必要があります。さらに、顧客に提供されるサービスやネットワークオペレーターによって提供されるサービスに関する情報は、さまざまなセキュリティ攻撃で使用できる情報を提供する場合があります。サービスモデル自体は、顧客が関連機能を利用できる特定のサービスのセキュリティ関連パラメーターを公開します。
Clearly, the ability to modify information exchanges between customer and network operator may result in bogus requests, unwarranted billing, and false expectations. Furthermore, in an automated system, modifications to service requests or the injection of bogus requests may lead to attacks on the network and delivery of customer traffic to the wrong place.
明らかに、顧客とネットワークオペレーター間の情報交換を変更する機能は、偽の要求、不当な請求、および誤った期待につながる可能性があります。さらに、自動化されたシステムでは、サービス要求への変更または偽の要求の挿入により、ネットワークへの攻撃と、間違った場所への顧客トラフィックの配信が発生する可能性があります。
Therefore, it is important that the protocol interface used to exchange service request information between customer and network operator is subject to authorization, authentication, and encryption. Clearly, the level of abstraction provided by a service model protects the operator from unwarranted visibility into their network, and additional protection is provided by the fact that how the service is delivered is entirely up to the operator.
したがって、顧客とネットワークオペレータの間でサービス要求情報を交換するために使用されるプロトコルインターフェイスは、許可、認証、および暗号化の対象となることが重要です。明らかに、サービスモデルによって提供される抽象化のレベルは、ネットワークへの不当な可視性からオペレーターを保護し、サービスの提供方法は完全にオペレーター次第であるという事実によって、追加の保護が提供されます。
Equally, all external interfaces, such as any of those between the functional components in Figure 3, need to be correctly secured. This document discusses modeling the information, not how it is exchanged.
同様に、図3の機能コンポーネント間のインターフェースなど、すべての外部インターフェースを正しく保護する必要があります。このドキュメントでは、情報の交換方法ではなく、情報のモデリングについて説明します。
This whole document discusses issues related to network management and control.
このドキュメント全体では、ネットワークの管理と制御に関連する問題について説明します。
It is important to observe that automated service provisioning resulting from use of a customer service model may result in rapid and significant changes in traffic load within a network and that that might have an effect on other services carried in a network.
カスタマーサービスモデルの使用による自動サービスプロビジョニングにより、ネットワーク内のトラフィック負荷が急速かつ大幅に変化する可能性があり、ネットワークで伝送される他のサービスに影響を与える可能性があることに注意してください。
It is expected, therefore, that a service-orchestration component has awareness of other service commitments, that the network-orchestration component will not commit network resources to fulfill a service unless doing so is appropriate, and that a feedback loop will be provided to report on degradation of the network that will impact the service.
したがって、サービスオーケストレーションコンポーネントが他のサービスコミットメントを認識していること、適切な場合を除き、ネットワークオーケストレーションコンポーネントがネットワークリソースをコミットしてサービスを実行しないこと、およびフィードバックループを提供してレポートを提供することが期待されます。サービスに影響を与えるネットワークの劣化。
The operational state of a service does not form part of a customer service model. However, it is likely that a network operator may want to report some state information about various components of the service and that could be achieved through extensions to the core service model, just as SLA extensions could be made as described in Section 5.
サービスの運用状態は、カスタマーサービスモデルの一部ではありません。ただし、セクション5で説明されているようにSLA拡張を行うことができるのと同じように、ネットワークオペレーターは、サービスのさまざまなコンポーネントに関するいくつかの状態情報を報告したい場合があり、コアサービスモデルの拡張を通じてそれを実現できます。
This document does not require any IANA actions.
このドキュメントでは、IANAアクションは必要ありません。
[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>。
[RFC8199] Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module Classification", RFC 8199, DOI 10.17487/RFC8199, July 2017, <https://www.rfc-editor.org/info/rfc8199>.
[RFC8199] Bogdanovic、D.、Claise、B。、およびC. Moberg、「YANG Module Classification」、RFC 8199、DOI 10.17487 / RFC8199、2017年7月、<https://www.rfc-editor.org/info/ rfc8199>。
[BGP-L3VPN-YANG] Jain, D., Patel, K., Brissette, P., Li, Z., Zhuang, S., Liu, X., Haas, J., Esale, S., and B. Wen, "Yang Data Model for BGP/MPLS L3 VPNs", Work in Progress, draft-dhjain-bess-bgp-l3vpn-yang-02, August 2016.
[BGP-L3VPN-YANG] Jain、D.、Patel、K.、Brissette、P.、Li、Z.、Zhuang、S.、Liu、X.、Haas、J.、Esale、S.、B。ウェン、「BGP / MPLS L3 VPNのヤンデータモデル」、作業中、draft-dhjain-bess-bgp-l3vpn-yang-02、2016年8月。
[EVPN-YANG] Brissette, P., Sajassi, A., Shah, H., Li, Z., Tiruveedhula, K., Hussain, I., and J. Rabadan, "Yang Data Model for EVPN", Work in Progress, draft-ietf-bess-evpn-yang-03, October 2017.
[EVPN-YANG] Brissette、P.、Sajassi、A.、Shah、H.、Li、Z.、Tiruveedhula、K.、Hussain、I.、J。Rabadan、「EVPNのヤンデータモデル」、作業進捗状況、draft-ietf-bess-evpn-yang-03、2017年10月。
[L2VPN-SERVICE] Wen, B., Fioccola, G., Xie, C., and L. Jalil, "A YANG Data Model for L2VPN Service Delivery", Work in Progress, draft-ietf-l2sm-l2vpn-service-model-04, October 2017.
[L2VPN-SERVICE] Wen、B.、Fioccola、G.、Xie、C。、およびL. Jalil、「L2VPNサービス提供のためのYANGデータモデル」、作業中、draft-ietf-l2sm-l2vpn-service-モデル-04、2017年10月。
[L2VPN-YANG] Shah, H., Brissette, P., Chen, I., Hussain, I., Wen, B., and K. Tiruveedhula, "YANG Data Model for MPLS-based L2VPN", Work in Progress, draft-ietf-bess-l2vpn-yang-07, October 2017.
[L2VPN-YANG] Shah、H.、Brissette、P.、Chen、I.、Hussain、I.、Wen、B。、およびK. Tiruveedhula、「MPLSベースのL2VPNのYANGデータモデル」、Work in Progress、 draft-ietf-bess-l2vpn-yang-07、2017年10月。
[MEF-55] MEF Forum, "Lifecycle Service Orchestration (LSO): Reference Architecture and Framework", Service Operations Specification MEF 55, March 2016.
[MEF-55] MEFフォーラム、「ライフサイクルサービスオーケストレーション（LSO）：リファレンスアーキテクチャとフレームワーク」、Service Operations Specification MEF 55、2016年3月。
[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>。
[RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined Networking: A Perspective from within a Service Provider Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, <https://www.rfc-editor.org/info/rfc7149>.
[RFC7149] Boucadair、M。およびC. Jacquenet、「ソフトウェア定義ネットワーキング：サービスプロバイダー環境内からの展望」、RFC 7149、DOI 10.17487 / RFC7149、2014年3月、<https：//www.rfc-editor。 org / info / rfc7149>。
[RFC7223] Bjorklund, M., "A YANG Data Model for Interface Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, <https://www.rfc-editor.org/info/rfc7223>.
[RFC7223] Bjorklund、M。、「A YANG Data Model for Interface Management」、RFC 7223、DOI 10.17487 / RFC7223、2014年5月、<https://www.rfc-editor.org/info/rfc7223>。
[RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP Connectivity Provisioning Profile (CPP)", RFC 7297, DOI 10.17487/RFC7297, July 2014, <https://www.rfc-editor.org/info/rfc7297>.
[RFC7297] Boucadair、M.、Jacquenet、C。、およびN. Wang、「IP接続プロビジョニングプロファイル（CPP）」、RFC 7297、DOI 10.17487 / RFC7297、2014年7月、<https：//www.rfc-editor。 org / info / rfc7297>。
[RFC7407] Bjorklund, M. and J. Schoenwaelder, "A YANG Data Model for SNMP Configuration", RFC 7407, DOI 10.17487/RFC7407, December 2014, <https://www.rfc-editor.org/info/rfc7407>.
[RFC7407] Bjorklund、M。、およびJ. Schoenwaelder、「SNMP構成用のYANGデータモデル」、RFC 7407、DOI 10.17487 / RFC7407、2014年12月、<https://www.rfc-editor.org/info/rfc7407> 。
[RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software-Defined Networking (SDN): Layers and Architecture Terminology", RFC 7426, DOI 10.17487/RFC7426, January 2015, <https://www.rfc-editor.org/info/rfc7426>.
[RFC7426] Haleplidis、E。、編、Pentikousis、K。、編、Denazis、S.、Hadi Salim、J.、Meyer、D.、O。Koufopavlou、「ソフトウェア定義ネットワーキング（SDN）：レイヤーand Architecture Terminology」、RFC 7426、DOI 10.17487 / RFC7426、2015年1月、<https://www.rfc-editor.org/info/rfc7426>。
[RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for Application-Based Network Operations", RFC 7491, DOI 10.17487/RFC7491, March 2015, <https://www.rfc-editor.org/info/rfc7491>.
[RFC7491]キング、D。、およびA.ファレル、「アプリケーションベースのネットワーク操作のためのPCEベースのアーキテクチャ」、RFC 7491、DOI 10.17487 / RFC7491、2015年3月、<https://www.rfc-editor.org/ info / rfc7491>。
[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>。
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/info/rfc8040>.
[RFC8040] Bierman、A.、Bjorklund、M。、およびK. Watsen、「RESTCONFプロトコル」、RFC 8040、DOI 10.17487 / RFC8040、2017年1月、<https://www.rfc-editor.org/info/rfc8040 >。
[RFC8049] Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data Model for L3VPN Service Delivery", RFC 8049, DOI 10.17487/RFC8049, February 2017, <https://www.rfc-editor.org/info/rfc8049>.
[RFC8049] Litkowski、S.、Tomotaki、L.、K。Ogaki、「YANG Data Model for L3VPN Service Delivery」、RFC 8049、DOI 10.17487 / RFC8049、2017年2月、<https：//www.rfc-editor。 org / info / rfc8049>。
Acknowledgements
謝辞
Thanks to Daniel King, Xian Zhang, Michael Scharf, Med Boucadair, Luis Miguel Contreras Murillo, Joe Salowey, Benoit Claise, Robert Sparks, Tom Petch, David Sinicrope, and Deborah Brungard for their useful review and comments.
Daniel King、Xian Zhang、Michael Scharf、Med Boucadair、Luis Miguel Contreras Murillo、Joe Salowey、Benoit Claise、Robert Sparks、Tom Petch、David Sinicrope、Deborah Brungardの有益なレビューとコメントに感謝します。
Thanks to Dean Bogdanovic, Tianran Zhou, and Carl Moberg for their help coordinating with [RFC8199].
[RFC8199]との調整に協力してくれたDean Bogdanovic、Tianran Zhou、Carl Mobergに感謝します。
Many thanks to Jerry Bonner for spotting a tiny but critical, one-word typo.
Jerry Bonner氏に、小さいながらも重要な1単語のタイプミスを見つけてくれてありがとう。
Authors' Addresses
著者のアドレス
Qin Wu Huawei Technologies
五湖AのQは技術です
Email: bill.wu@huawei.com
Will Liu Huawei Technologies
劉華為技術は
Email: liushucheng@huawei.com
Adrian Farrel Juniper Networks
エイドリアンファレルジュニパーネットワークス
Email: afarrel@juniper.net