Service Models Explained

In recent years the number of data models written in the YANG modelling langauge for configuration and monitoring has blossomed. Many of these are used for device-level configuration (for example, ) or for control of protocols (for example, ). Within the context of Software Defined Networking (SDN) YANG data models may be used on Southbound Interfaces (SBIs) between a controller and network devices, and between network orchestrators and controllers. 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 dispells some common misconceptions.

The following terms are used in this document: This term is used interchangeably to refer to the company that owns a network that provides Internet connectivity and services, or the individual who performs operations and management on that network. Someone who purchases connectivity and other services from a network operator. In the context of this document, a customer is usually the 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 is the customer of an optical transport network. A network operator delivers one or more services to a customer. A 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. 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 be a more complex connectivity model (such as a multi-site 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. The concepts of information models and data models are described in . That document defines a data model by contrasting it with the definition of an information model, so it may be helpful to quote some text to give context within this document. The main purpose of an information model 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 information model depends on the modeling needs of its designers. In order to make the overall design as clear as possible, an information model should hide all protocol and implementation details. Another important characteristic of an information model is that it defines relationships between managed objects. Data models, conversely, are defined at a lower level of abstraction and include many details. They are intended for implementors and include protocol-specific constructs. A service model is a specific type of data model. It describes a service and all of the parameters of the service in a portable, operator-independent way. It can be used by a human or by software to configure or request a service and may equally be consumed by a human or by a software component. It needs to be repeatedly clarified that a 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 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, service models are used on the interface between customers and network operators. This is simply shown in The language in which a service model is described is a choice for whoever specifies the model. The IETF uses the YANG data modeling language defined in The encoding and communication protocol used to exchange a service model between customer and network operator are deployment- and implementation-specific. The IETF recommends the use of the NETCONF Configuration Protocol with data encoded in XML or JSON for interactions "on the wire" between software components. However, co-located software components might use an API, while systems with more direct huan interactions might use web pages or even paper forms.

-------------- ---------------------- | | Service Model | | | Customer | <-----------------> | Network Operator | | | | | -------------- ---------------------- How a network operator processes a service request described be a 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 service model and determines how to deliver the service by enabling and configuring network protocols and devices.

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. shows 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 | --------- --------- --------- --------- But a service request is (or should be) network-agnostic. That is, there should be an independence between the behavior and unctions 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 . In a system that is fully implemented in software, this could lead to agile service delivery or service automation.

------------------ ---------- | | Service Model | | | Service |<--------------->| Customer | | Orchestrator | | | | | ---------- .------------------. . . . . ------------------ ------------------ | | | | | Network | | Network | | Orchestrator | | Orchestrator | | | | | .------------------ ------------------. . : : . . : : . ------------ ------------ ------------ ------------ | | | | | | | | | Controller | | Controller | | Controller | | Controller | | | | | | | | | ------------ ------------ ------------ ------------ : . . : : : . . : : : . . : : --------- --------- --------- --------- --------- | Network | | Network | | Network | | Network | | Network | | Element | | Element | | Element | | Element | | Element | --------- --------- --------- --------- --------- The split between control components that exposes a "service interface" is present in many figures showing extended SDN architectures: Figure 1 of 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. describes an interface between an "Application Service Coordinator" and an "Application-Based Network Operations Controller".

In discussing service models, there are several possible causes of confusion: The services we are discussing are services provided by network operators to customers. This is a completely different thing to "Foo as a Service" (for example, Infrastructure as a Service (IaaS)) where a service provider offers a service at some location that is reached across a network. The confusion arises not only because of the use of the word "service", but also because network operators may also offer value-added services to their customers. Network operation is completely out of scope in the discussion of service models. That means that the service model does not reveal to the customer anything about how the network operator delivers the service. The model does not expose details of technology or network resources used to provide the service. 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 followed by the tunnel. 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 te service model. The network operator may use further data 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 and might include many of the pieces of information in the service model alongside protocol parameters and device configuratin information. It is important that the Service Orchestrator should be able to map from a service model to these data models, but they are not the same things. Commercial terms are generally not a good subject for standardization. It is possible that some network operators will enhance standard service models to include commercial information, but the way this is done is likely to vary widely between network operators. Service Level Agreements (SLAs) have a high degree of overlap with the definition of sevices present in service models. Requests for specific bandwidth, for example, might be present in a service model, and agreement to deliver a service is a commitment to the description of the service in the 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 so are also not good topics for standardization.

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: 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. Protocols that are run between customer equipment and network operator equipment (for example, Operations, Administration, and Maintenance protocols, or protocols for exchanging routing information) need to be selected and configured as part of the service description.

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) ws 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

This document makes no requests for IANA action

Thanks to Daniel King for review comments.