| OPS Area Working Group | Q. Wu |
| Internet-Draft | W. Liu |
| Intended status: Informational | Huawei Technologies |
| Expires: March 13, 2017 | A. Farrel |
| Juniper Networks | |
| September 9, 2016 |
Service Models Explained
draft-wu-opsawg-service-model-explained-03
The IETF has produced a considerable number of data models in the YANG modelling language. The majority of these are used to model devices and they allow access for configuration and to read operational status.
A small number of YANG models are used to model services (for example, the Layer Three Virtual Private Network Service Model produced by the L3SM working group).
This document briefly sets out the scope of and purpose of an IETF service model, and it shows where a service model might fit into a Software Defined Networking architecture or deployment.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 13, 2017.
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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.
In recent years the number of data models written in the YANG modelling language [RFC6020] for configuration and monitoring has blossomed. Many of these are used for device-level configuration (for example, [RFC7223]) or for control of protocols (for example, [RFC7407]).
Within the context of Software Defined Networking (SDN) [RFC7426] YANG data models may be used on Southbound Interfaces (SBIs) between a controller and network devices, and 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 models.
Recently 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. These models may be used in manual and even paper-driven service request processes moving to IT-based mechanisms. Ultimately they could be used in online, software-driven dynamic systems.
This document explains the scope and purpose of service models within 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.
Other work on classifying YANG data models has been done in [I-D.ietf-netmod-yang-model-classification]. That document provides an important reference for this document, and also uses the term "service model". Section 6.1 provides a comparison between these two classifications.
Readers should familiarize themselves with the description and classification of YANG models provided in [I-D.ietf-netmod-yang-model-classification].
The following terms are used in this document:
The distinction between a customer service model and a service delivery model needs to be repeatedly clarified. A customer service model is not a data model 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, a customer service model is not a data model that describes how a network operator realizes and delivers the service described by the model. This issue 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 simply in Figure 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]
The encoding and communication protocol used to exchange a customer service model between customer and network operator are deployment- and implementation-specific. The IETF has standardized the NETCONF protocol [RFC6241] and the RESTCONF protocol [I-D.ietf-netconf-restconf] for interactions "on the wire" between software components with data encoded in XML or JSON. However, co-located software components might use an API, while systems with more direct human interactions might use web pages or even paper forms.
-------------- Customer ----------------------
| | Service Model | |
| Customer | <-----------------> | Network Operator |
| | | |
-------------- ----------------------
Figure 1: The Customer Service Models used on the Interface between Customers and Network Operators
How a network operator processes a customer's service request described with a customer service model will depend on the commercial and operational tools, processes, and policies used by the 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 network 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 southbound to network orchestrators or controllers.
In an SDN system, the control and configuration of network resources and protocols is performed by software systems that determine how best to utilize the network. Figure 2 shows a common architectural view of an SDN system where network elements are programmed by a component called a controller, and where controllers are instructed by an orchestrator that has a wider view of the whole of, or part of, a network.
------------------
| |
| Orchestrator |
| |
.------------------.
. : .
. : .
------------ ------------ ------------
| | | | | |
| Controller | | Controller | | Controller |
| | | | | |
------------ ------------ ------------
: . . :
: . . :
: . . :
--------- --------- --------- ---------
| Network | | Network | | Network | | Network |
| Element | | Element | | Element | | Element |
--------- --------- --------- ---------
Figure 2: A Common SDN Architecture
But a customer' service request is (or should be) network-agnostic. That is, there should be an independence between the behavior and functions that a customer requests and the technology that the network operator has available to deliver the service. This means that the service request must be mapped to the orchestrator's view, and this mapping may include a choice of which networks to use depending on what technologies are available and which service features have been requested.
This mapping can be achieved by splitting the orchestration function between a "Service Orchestrator" and a "Network Orchestrator" as shown in Figure 3. In a system that is fully implemented in software, this could lead to agile service delivery or service automation.
Customer
------------------ Service ----------
| | Model | |
| Service |<-------->| Customer |
| Orchestrator | | |
| | ----------
------------------
. .
. . -----------
. . ......|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 SDN Architecture with a Service Orchestrator
Figure 3 also shows where different data models might be applied within the architecture.
The split between control components that exposes a "service interface" is present in many figures showing extended SDN architectures:
This can all lead to some confusion around the definition of a "service interface" and a "service model". Some previous literature considers the interface that is northbound of the Network Orchestrator to be a "service interface" used by an application (as shown in Figure 3), 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 where the service is described by a service model and the interaction is between customer and operator. Further discussion of this point is provided in Section 5.
In discussing service models, there are several possible causes of confusion:
Other work has classified YANG models, produced parallel architectures, and developed a range of YANG models. This section briefly examines that other work and shows how it fits with the description of service models introduced in this document.
As previously noted, [I-D.ietf-netmod-yang-model-classification] provides a classification of YANG data models. It introduces the term "Network Service YANG Module" to identify the type of model used to "describe the configuration, state data and operations of an abstract representation of a service implemented on one or multiple network elements." These are service delivery models as described in this document, that is, they are the models used on the interface between the Service Orchestrator or OSS/BSS and the Network Orchestrator as shown in Figure 3.
Figure 1 of [I-D.ietf-netmod-yang-model-classification] can be modified to make this more clear and to add an additional example of a Network Service YANG model as shown in Figure 4.
+---------------+
| |
| Customers |
| |
+---------------+
- - - - - - - - - - - - - -
Service YANG Modules
+--------------------------+ +--------------------------+
| | | Operations and Business |
| Service Orchestrator | | Support Systems |
| | | (OSS/BSS) |
+--------------------------+ +--------------------------+
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Network Service YANG Modules
+------------+ +-------------+ +-------------+ +-------------+
| | | | | | | |
| - L2VPN | | - L2VPN | | EVPN | | L3VPN |
| - VPWS | | - VPLS | | | | |
| | | | | | | |
+------------+ +-------------+ +-------------+ +-------------+
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Network Element YANG Modules
+------------+ +------------+ +-------------+ +------------+
| | | | | | | |
| MPLS | | BGP | | IPv4 / IPv6 | | Ethernet |
| | | | | | | |
+------------+ +------------+ +-------------+ +------------+
L2VPN: Layer 2 Virtual Private Network
L3VPN: Layer 3 Virtual Private Network
VPWS: Virtual Private Wire Service
VPLS: Virtual Private LAN Service
Figure 4: YANG Module Layers Showing Service Models
A number of IETF working groups are developing YANG models related to services. These models focus on how the network operator configures the network through protocols and devices to deliver a service.
A sample set of these models is listed here:
All of these models are service delivery models in the context of this document.
Several initiatives within the IETF are developing customer service models. The most advanced presents the Layer Three Virtual Private Network (L3VPN) service as described by a network operator to a customer. This L3VPN service model (L3SM) is documented in [I-D.ietf-l3sm-l3vpn-service-model] where its usage is described as in Figure 5 which is reproduced from that document. As can be seen, the L3SM is a customer service model as described in this document.
L3VPN-SVC |
MODEL |
|
+------------------+ +-----+
| Orchestration | < --- > | OSS |
+------------------+ +-----+
| |
+----------------+ |
| Config manager | |
+----------------+ |
| |
| Netconf/CLI ...
| |
+------------------------------------------------+
Network
Figure 5: The L3SM Service Architecture
A Layer Two VPN service model (L2SM) is defined in [I-D.wen-l2sm-l2vpn-service-model]. 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.
----------------------------
| 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
The MEF has developed an architecture for network management and operation. It is documented as the Lifecycle Serice Orchestration (LSO) Reference Architecture and illustrated in Figure 2 of [MEF-55]. Part of this is depicted in Figure 7.
The MEF terms the functional interfaces between components as Management Interface Reference Points (MIRPs). These are the logical points of interaction between functional management entities and are further defined by Interface Profiles and implemented by APIs. As can be seen from Figure 7, each of these MIRPs has been given a name. In the context of this document:
:
Customer Domain : Service Provider Domain
:
CANATA : --------------
------------------>| Business |
| : | Applications |
v : --------------
------------- : ^
| Customer | : |
| Application | : | LEGATO
| Coordinator | : |
------------- : |
^ : v
| : ---------------
| : | Service |
------------------>| Orchestration |
ALEGRO : | Functionality |
: ---------------
: ^
: | PRESTO
: v
: ----------------
: | Infrastructure |
: | Control and |
: | Management |
: ----------------
: ^
: | ADAGIO
: v
: -------------
: | Element |
: | Control and |
: | Management |
: -------------
Figure 7: Part of The MEF's LSO Reference Architecture
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 the customer site and make a definition to the type of service delivered. Such features do need to be described in the service model.
Two examples are:
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, but which 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 to all network operators' offerings. Policies that describe who at 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 to all network operators' offerings.
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 in Layer Three Virtual Private Network Service Model (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. Thus, when a basic description of the core service is agreed and documented in a service model, it is important that that model should 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 vary 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.
It is an implementation and deployment choice whether all service models are processed by a single Service Orchestrator that can coordinate between the different services, or whether each service model is handled by a specialized Service Orchestrator able to provide tuned behavior for a specific service.
TBD
TBD
This document makes no requests for IANA action
Thanks to Daniel King, Xian Zhang, and Michael Scharf for useful review and comments.
| [I-D.ietf-l3sm-l3vpn-service-model] | Litkowski, S., Shakir, R., Tomotaki, L., Ogaki, K. and K. D'Souza, "YANG Data Model for L3VPN service delivery", Internet-Draft draft-ietf-l3sm-l3vpn-service-model-12, July 2016. |
| [I-D.ietf-netmod-yang-model-classification] | Bogdanovic, D., Claise, B. and C. Moberg, "YANG Module Classification", Internet-Draft draft-ietf-netmod-yang-model-classification-02, June 2016. |
| [RFC3444] | Pras, A. and J. Schoenwaelder, "On the Difference between Information Models and Data Models", RFC 3444, DOI 10.17487/RFC3444, January 2003. |
| [RFC7426] | Haleplidis, E., Pentikousis, K., 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. |