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
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).
已经定义了少量模块来对服务进行建模（例如，由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.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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）的产品。它代表了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.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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.
在软件定义网络（SDN）[RFC7149][RFC7426]的上下文中，数据模块可用于控制器和网络设备之间的接口，以及网络编排器和控制器之间的接口。还可能存在此类组件的层次结构，其中超级控制器、域控制器和设备控制器都使用模块交换信息和指令。
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.
在[RFC8199]中已经完成了对YANG模块进行分类的其他工作。该文件为本文件提供了重要参考，并使用了术语“服务模块”。在本文件中，第6.1节对相同术语的这两种用法进行了比较。
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.
网络运营商：该术语用于指拥有和运营一个或多个提供互联网连接服务和/或其他服务的网络的公司。
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.
客户：这个术语是指从网络运营商处购买服务（包括连接）的人。在本文档中，客户通常是运行自己的网络或计算平台并希望连接到Internet或站点之间的公司。这样的客户可以操作企业网络或数据中心。有时，该术语也可用于指此类公司中与网络运营商签订合同购买服务的个人。这里所描述的客户是与网络运营商分开的商业运营商，但是一些公司可以与内部客户一起运营，以便例如，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.
服务：网络运营商向客户提供一项或多项服务。本文档上下文中的服务（有时称为网络服务）是客户站点与Internet之间或跨网络运营商网络和Internet的客户站点之间的某种形式的连接。但是，如第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.
读者还可以参考[RFC7297]了解IP连接服务的特征化示例。
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:
数据模型：[RFC3444]中描述了信息模型（IM）和数据模型（DM）的概念。该文档通过将数据模型与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的另一个重要特征是它定义了托管对象之间的关系。
DMs, conversely, are defined at a lower level of abstraction and include many details. They are intended for implementors and include protocol-specific constructs.
相反，DMs是在较低的抽象级别定义的，包含许多细节。它们是为实现者设计的，包括特定于协议的结构。
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:
服务模型：服务模型是一种特定类型的数据模型。它以便携方式描述服务和服务参数，可统一使用，且与设备和操作环境无关。服务模式可分为以下两类：
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，而具有更直接人机交互的系统可能会使用网页甚至纸质表单。当直接的人机交互开始发挥作用时，接口交互可以通过业务实践来实现，这可能会引入一些误差，从而提高自动化、确定性接口的优先级。
-------------- Customer ----------------------
| | Service Model | |
| Customer | <-----------------> | Network Operator |
| | | |
-------------- ----------------------
-------------- 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.
然而，目的是网络运营商将服务请求映射到配置和操作参数中，这些参数控制一个或多个网络以提供请求的服务。这意味着网络运营商（或网络运营商运行的软件）获取客户服务模型中的信息，并确定如何通过启用和配置网络协议和设备来提供服务。他们可以通过构建服务交付模型并将其传递给网络协调器或控制器来实现这一点。标准客户服务模型的使用通过自动化简化了服务交付。
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.
也有人建议，应该有一个单一的基本客户服务模块，并应提供个别服务的详细信息，作为该模块的扩展或补充。许多服务参数（例如客户的身份和邮政地址）很可能是通用的，多次定义它们（在每个客户服务模型中定义一次）是错误的。然而，此时应考虑“模块”和“模型”之间的区别：模块是模型的数据在逻辑上被分解和记录的方式，特别是在多个模型中的重用。
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 |
--------- --------- --------- ---------
------------------
| |
| 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.
实现此映射的一个实现选项是在“服务编排器”和“网络编排器”之间拆分编排功能，如图3所示。
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 |
--------- --------- --------- --------- ---------
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：带有服务编排器的示例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显示了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即服务”（例如，存储即服务（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]还将这些数据模型称为“服务模型”，并将其编码为“网络服务模块”；第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
o SLA与客户服务模型中的服务定义有高度重叠。例如，对特定带宽的请求可能出现在客户服务模型中，而提供服务的协议是对客户服务模型中服务描述的承诺。然而，SLA通常包括一些细粒度的细节，这些细节是关于如何允许服务变化、变化多少以及变化的频率。SLA还与带有惩罚等的商业条款相关联，因此也不是很好的话题
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.
标准化。与商业条款一样，预计一些网络运营商将增强标准客户服务模型，以使用他们自己的工作或根据专门从事此主题的标准机构提供的材料，包括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]提供了模块的分类。它引入术语“网络服务模块”，以确定用于“描述在一个或多个网元上实现的服务的抽象表示的配置、状态数据、操作和通知”的模块类型。这些模块用于构建本文档中描述的服务交付模型；也就是说，它们是服务编排器或OSS/BSS与网络编排器之间接口上使用的模块，如图3所示。
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所示。可以看出，最高级别的模块收集用于提供操作支持和业务支持的模块。这些可能由操作支持系统（OSS）或业务支持系统（BSS）使用，服务编排器可能构成OSS/BSS的一部分，也可能是一个单独的组件。图中的这一最高层分为客户服务模块，用于描述本文档中所讨论的向客户提供的服务，以及其他模块，用于描述进一步的OSS/BSS功能，如计费和SLA。
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Operations Support and Business Support YANG Modules
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Operations Support and Business Support YANG Modules
+-----------------------+ +-----------------------+
| | | |
| Customer Service | | Other |
| YANG Modules | | Operations Support |
| | | and |
| +------+ +------+ | | Business Support |
| | | | | | | YANG Modules |
| | L2SM | | L3SM | | | |
| | | | | | | |
| +------+ +------+ | | |
| | | |
+-----------------------+ +-----------------------+
+-----------------------+ +-----------------------+
| | | |
| Customer Service | | Other |
| YANG Modules | | Operations Support |
| | | and |
| +------+ +------+ | | Business Support |
| | | | | | | YANG Modules |
| | L2SM | | L3SM | | | |
| | | | | | | |
| +------+ +------+ | | |
| | | |
+-----------------------+ +-----------------------+
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Network Service YANG Modules
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Network Service YANG Modules
+------------+ +-------------+ +-------------+ +-------------+
| | | | | | | |
| - L2VPN | | - L2VPN | | EVPN | | L3VPN |
| - VPWS | | - VPLS | | | | |
| | | | | | | |
+------------+ +-------------+ +-------------+ +-------------+
+------------+ +-------------+ +-------------+ +-------------+
| | | | | | | |
| - L2VPN | | - L2VPN | | EVPN | | L3VPN |
| - VPWS | | - VPLS | | | | |
| | | | | | | |
+------------+ +-------------+ +-------------+ +-------------+
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Network Element YANG Modules
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Network Element YANG Modules
+------------+ +------------+ +-------------+ +------------+
| | | | | | | |
| MPLS | | BGP | | IPv4 / IPv6 | | Ethernet |
| | | | | | | |
+------------+ +------------+ +-------------+ +------------+
+------------+ +------------+ +-------------+ +------------+
| | | | | | | |
| 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:第二层虚拟专用网服务模式L2VPN:第二层虚拟专用网L3SM:第三层虚拟专用网服务模式L3VPN:第三层虚拟专用网VPLS:虚拟专用局域网服务VPWS:虚拟专用线服务
Figure 4: YANG Module Abstraction Layers Showing Customer Service Modules
图4：显示客户服务模块的模块抽象层
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工作组正在开发与服务相关的模块。这些模型侧重于网络运营商如何通过协议和设备配置网络以提供服务。其中一些模型被分类为网络服务交付模型（也被称为服务交付模型或网络配置模型，具体取决于它们的定位级别），而另一些模型具有与特定元素配置相关的细节，因此被分类为网络元素模型（也被称为设备模型）。
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
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.
[L2VPN-Service]中定义了第2层VPN服务模型（L2SM）。该模型的用法如图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
----------------------------
| 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在服务模型方面的工作通常较小，并且提供了一个简单、自包含的服务模块。这并没有使两种方法无效：它只是观察到它们是不同的方法。
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:
两个例子如下：
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
与第5节中讨论的商业条款和SLA一样，预计一些网络运营商将增强标准客户服务模型，以使用自己的
work or depending on specific policy models built in the IETF or other standards bodies.
工作或取决于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.Schoenwaeld，“关于信息模型和数据模型之间的差异”，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，“阳模块分类”，RFC 8199，DOI 10.17487/RFC81992017年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.Wen，“BGP/MPLS L3 VPN的YANG数据模型”，正在进行的工作，草稿-dhjain-bess-BGP-L3VPN-YANG-022016年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的YANG数据模型”，正在进行的工作，草案-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服务交付的杨数据模型”，正在进行的工作，草稿-ietf-l2sm-L2VPN-SERVICE-Model-042017年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数据模型”，正在进行的工作，草案-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）：参考体系结构和框架”，服务运营规范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.，Ed.“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.，Ed.，Bjorklund，M.，Ed.，Schoenwaeld，J.，Ed.，和A.Bierman，Ed.，“网络配置协议（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.，“用于接口管理的YANG数据模型”，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.Schoenwaeld，“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]Haleplis，E.，Ed.，Pentikousis，K.，Ed.，Denazis，S.，Hadi Salim，J.，Meyer，D.，和O.Koufopavlou，“软件定义网络（SDN）：层和架构术语”，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]King，D.和A.Farrel，“基于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.，Ed.“YANG 1.1数据建模语言”，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，“L3VPN服务交付的YANG数据模型”，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].
感谢院长Bogdanovic、周天然和Carl Moberg帮助协调[RFC8199]。
Many thanks to Jerry Bonner for spotting a tiny but critical, one-word typo.
非常感谢Jerry Bonner发现了一个微小但关键的一个单词拼写错误。
Authors' Addresses
作者地址
Qin Wu Huawei Technologies
秦武华为技术有限公司
Email: bill.wu@huawei.com
Email: bill.wu@huawei.com
Will Liu Huawei Technologies
刘翔是否会选择华为技术
Email: liushucheng@huawei.com
Email: liushucheng@huawei.com
Adrian Farrel Juniper Networks
Adrian Farrel Juniper Networks
Email: afarrel@juniper.net
Email: afarrel@juniper.net