Internet DRAFT - draft-wang-l3sm-service-automation-architecture
draft-wang-l3sm-service-automation-architecture
Network Working Group A. Wang
Internet-Draft China Telecom
Intended status: Standards Track Y. Cheng
Expires: April 21, 2016 China Unicom
Y. Zhuang
Huawei
D. Zhang
October 19, 2015
Service Automation Management Architecture
draft-wang-l3sm-service-automation-architecture-01
Abstract
This document describes a generic architecture for the service
automation management (SAM) which can be used to deploy service
across networks models specified in IETF. It describes the basic
architecture, the components, and interfaces used for service
automation control and configuration. However, this document does
not propose protocols or extensions to existing protocols but shows
how service requests from customer applications can be realized in
the way more programmable and agile manner and mapped to the
corresponding protocols and network elements.
Status of This Memo
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 April 21, 2016.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
Wang, et al. Expires April 21, 2016 [Page 1]
Internet-Draft Service Automation Architecture October 2015
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Objectives . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3
3. Generic Architecture for service automation management (SAM) 3
3.1. SAM architecture . . . . . . . . . . . . . . . . . . . . 3
3.2. Functions Components . . . . . . . . . . . . . . . . . . 4
3.2.1. APPs . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2.2. Customer Service Orchestrator (CSO) . . . . . . . . . 5
3.2.3. Network Service Orchestrator (NSO) . . . . . . . . . 5
3.2.4. OSS . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2.5. Devices . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Functional Interfaces . . . . . . . . . . . . . . . . . . 6
3.3.1. C1: Service Level interface . . . . . . . . . . . . . 6
3.3.2. C2: Network Wide Interface . . . . . . . . . . . . . 7
3.3.3. C3: Device Level Interface . . . . . . . . . . . . . 7
3.3.4. C4: Network Level OSS facing interface . . . . . . . 7
3.4. Candidate Network Configuration Management Protocols . . 7
3.5. Relation between service model and Network element model 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Normative References . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
The purpose of network system configuration is to allow the
deployment of services requested by customers across networks.
Essentially, these services are built from a combination of network
elements and protocol configuration. However, they are presented to
service customers in a more abstract way.
To facilitate service automation control and configuration more
automatic and much simpler manner, service models are proposed and
specified in IETF to help customers express their service
requirements as well as operators configure their networks per these
requirements. As a starting point, L3 VPN Service Model (L3SM)
Wang, et al. Expires April 21, 2016 [Page 2]
Internet-Draft Service Automation Architecture October 2015
working group is working on such a service model. [I-D.bogdanovic-
netmod-yang-model-classification] discusses YANG model layering which
lays a good foundation for L3SM service model work.
The L3VPN Service Model (L3SM) [I-D.ietf-l3sm-l3vpn-service-model] is
aimed to provide an abstracted view of a Layer 3 IP VPN service
configuration components, which can further break down into the data
into specific Network Element models to configure the participating
network elements to perform the service . It is more focused on the
characteristics of the L3VPN service itself which should be specified
in the service data model, while little description of the service
model usage, i.e., interacting with other control plane component to
configure the network.
This document describes a generic architecture of the service
automation management to use service models such as L3SM across the
network. The generic SAM architecture is to explain the role of the
service model, such as L3 VPN Service Model (L3SM), used in the
network and how it can be further processed and deployed onto network
nodes to realize the customer service.
This document can help service model developers and network operators
better understand the usage of service model and how it can be
deployed in their networks.
1.1. Objectives
The purpose of this service-automation management architecture is to
provide an outline of how service models from customer applications
can be processed and translated into configurations of network
elements and protocols, so as to realize the customer requested
service.
2. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. Generic Architecture for service automation management (SAM)
3.1. SAM architecture
Figure 1 illustrates a generic architecture for the service
automation management. The components and functional interfaces are
further discussed in Sections 3.2 and 3.3, respectively. It is
important to understand that the relationships and interfaces shown
Wang, et al. Expires April 21, 2016 [Page 3]
Internet-Draft Service Automation Architecture October 2015
between components in this figure are focused on the instantiation of
service configuration onto network elements.
+-------+
| |
| APP |
| |
+-------+
|C1
+------------|---------------------------------------+
|+-----------V----+ C4 +-------+ |
||Customer Service|<----------| OSS | |
|| Orchestrator | +-------+ |
|| | |
|+-----------^-- -+ |
| C2| |
| |----V--------------------------------------+|
| | Network Service Orchestrator||
| | +--------+ +--------------+ ||
| | |Config | +-------------+ | ||
| | |Manager | +-------------+ |--+ ||
| | +-- -----+ | Controller |--+ ||
| | +-------------+ ||
| |----^--------------------------------------+|
| | |
| | |
+------------|---------------------------------------+
C3 |
+--|--- -----+
+---|--- ---+ |
+------V--- + |-+
| |--+
| Device |
+-----------+
The translation from service model into a set of network
configurations is done by the Customer Service Orchestrator
(CSO),Conf Manager and Network Service Orchestrator. Further, the
translated configuration/control data is signaled using XML based
encoding and YANG module onto involved network elements.
3.2. Functions Components
This section describes the functional components shown as boxes in
Figure 1. The interactions between those components, the functional
interfaces are described in Section 3.3.
Wang, et al. Expires April 21, 2016 [Page 4]
Internet-Draft Service Automation Architecture October 2015
3.2.1. APPs
Within the service automation management architecture, an APP may
issue high-level service requests to the Customer Service
Orchestrator which indicates the network service from customer. It
may also establish policies for the activities of the components
within the architecture.
The APP will use service model to carry service characteristics
parameters and inject thismodel into the Customer Service
Orchestrator.
3.2.2. Customer Service Orchestrator (CSO)
The Customer Service Orchestrator is a service component and used by
service customers to communicate with the network management
system(e.g.,OSS) to request operations on the network.
The Customer Service Orchestrator will also interact with the network
service Orchestrator or Conf Manager to control, operate, and manage
a network.
Besides, it might also needs to work with OSS or control plane to get
network capability information, network requirement information and
Network Planning information(e.g., route target).
The Customer Service Orchestrator will use service model sent from
APP as input and network planning information from OSS or network
capability information from Control plane and translate them to
orchestrated configuration (e.g., Technology independent network
element configuration or Technology dependent Network element
configuration)of network elements who will be part of the service.
3.2.3. Network Service Orchestrator (NSO)
The network Service Orchestrator is a configuration component and
used to control, operate, and manage a network in more scalable way.
It can interact with the Customer Service Orchestrator to get
orchestrated configuration of network nodes(e.g., Technology
independent Network element configuration). In this way, it allows
the customer service orchestrator to distribute the technology
independent network configurations for service model in a more
general way without equipped with various protocols for different
network device configurations.
For a Network Service Orchestrator, it can comprise several different
type of Controller, e.g., ODL Controller, ONOS Controller, ABNO
Controller, I2RS Controller, SDN Controller), each of which is able
Wang, et al. Expires April 21, 2016 [Page 5]
Internet-Draft Service Automation Architecture October 2015
to install various different protocols described in section 3.4 for
configuration of different network devices.
The Conf Manager also can be part of the network service orchestrator
and used to control, operate, and manage a network as a whole
dedicatedly Using Netconf protocol.
3.2.4. OSS
OSS applies to legacy software based platform used by service
provider to support and manage network operations helping with
plan,build, operate and optimize the networks. OSS systems support
network management functions such as network inventory. OSS systems
will interact with Customer Service Orchestrator and provide Network
inventory information and network planning informationsuch as route
target to Customer Service Orchestrator as input to generate
orchestrated configuration of network elements.
3.2.5. Devices
Devices can be routers, but also servers (like AAA),while not limited
to these examples. The configuration of network devices may be done
by CLI, or by NetConf/RestConf coupled with specific configuration
YANG data models (BGP, VRF, BFD ...) or any other way by the Network
Service Orchestrator in section 3.2.3 or the Customer Service
Orchestrator in section 3.2.2.
3.3. Functional Interfaces
This section describes the main interfaces between functional
components involved in service automation control and configuration
that might be used in an realization of customer services. As noted
in section 2.2, interfaces shown between components in Figure 1 are
illustrative and focused on service automation and configuration
based on service model. It is assumed that existing protocols can
provide all of the capabilities. The discussion of new protocols for
these capabilities is out of scope.
3.3.1. C1: Service Level interface
The north-bound Service Level interfaces to the customer service
orchestrator (CSO) are used by applications. With the service level
interface, customers can request customer network service with
various service requirements needed in the network. The interface
will also need to be able to report the asynchronous completion of
service requests and convey changes in the status of services, but
these status information are not necessary to be carried by service
model.
Wang, et al. Expires April 21, 2016 [Page 6]
Internet-Draft Service Automation Architecture October 2015
3.3.2. C2: Network Wide Interface
The network Level orchestrator is used to provide network
configuration on the network for customer services by operators. In
this case, the network Wide interface from the customer service
orchestrator is introduced.
After the customer service orchestrator maps the service model of the
requested network service into network configuration data, it sends
out the configuration data onto network service orchestrator via the
network wide interface while leaving the detailed protocol-related
configuration of involved network devices, such as routers and AAA,
to the network service orchestrator itself. Note that Network Wide
Interface can be an internal interface between Customer Service
Orchestrator and Network service orchestrator. That is to say,
Customer Service orchestrator is collocated with Network service
orchestrator or Conf Manager.
3.3.3. C3: Device Level Interface
Upon receiving a orchestrated network configuration data from the
Network Service Orchstrator, the network service orchestrator or Conf
Manager further configures the managed network devices by using
corresponding protocols (See section 3.4) via the device level
interfaces.
3.3.4. C4: Network Level OSS facing interface
By using these configuration interfaces, the Customer Service
Orchestrator can interact with OSS and get planning information or
verify whether the network resource can meet service requirements in
the service model by looking up network capability provided by OSS
and determine appropriate network level configuration parameters.
3.4. Candidate Network Configuration Management Protocols
As noted in 3.2, the Customer Service Orchestrator,Network Service
Orchestrator, Conf Manager is to install corresponding protocols to
exchange information with involved network devices. Many protocols
already exist to perform these functions, including the following:
o SNMP [RFC3412]
o The Network Configuration Protocol (NETCONF) [RFC6241]
o RESTCONF [RESTCONF]
o The General Switch Management Protocol (GSMP) [RFC3292]
Wang, et al. Expires April 21, 2016 [Page 7]
Internet-Draft Service Automation Architecture October 2015
o ForCES [RFC5810]
o OpenFlow [ONF]
o PCEP [PCE-Init-LSP]
3.5. Relation between service model and Network element model
Service Models are created to describe the characteristics of a
service, as agreed upon with consumers of that service while Network
Element Model describes the configuration parameters of a network
protocol and features for a participanting network device. In
addition the network element model describe operation state of the
network protocol for corresponding network device. The Network
element Models can be further broken down into Technology independent
YANG model and Technology specific YANG model. Unlike Network
element models, the service models can not be directly implemented
into network element. For more details on difference between service
model and network model, please refer to [I-D.bogdanovic-netmod-yang-
model-classification].
4. Security Considerations
TBD.
5. IANA Considerations
TBD.
6. Normative References
[I-D.bogdanovic-netmod-yang-model-classification]
Bogdanovic, D., Claise, B., and C. Moberg, "YANG Model
Classification", draft-bogdanovic-netmod-yang-model-
classification-04 (work in progress), October 2015.
[I-D.ietf-l3sm-l3vpn-service-model]
Litkowski, S., Shakir, R., Tomotaki, L., and K. D'Souza,
"YANG Data Model for L3VPN service delivery", draft-ietf-
l3sm-l3vpn-service-model-01 (work in progress), August
2015.
[I-D.ietf-netconf-restconf]
Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", draft-ietf-netconf-restconf-08 (work in
progress), October 2015.
Wang, et al. Expires April 21, 2016 [Page 8]
Internet-Draft Service Automation Architecture October 2015
[I-D.ietf-pce-pce-initiated-lsp]
Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP
Extensions for PCE-initiated LSP Setup in a Stateful PCE
Model", draft-ietf-pce-pce-initiated-lsp-04 (work in
progress), April 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
Network Configuration Protocol (NETCONF)", RFC 6020,
October 2010.
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
Bierman, "Network Configuration Protocol (NETCONF)",
RFC 6241', June 2011.
Authors' Addresses
Aijun Wang
China Telecom
No.118,Xizhimenneidajie,Xicheng District
Beijing 100035
China
Email: wangaj@ctbri.com.cn
Ying Cheng
China Unicom
P.R. China
Email: chengying10@chinaunicom.cn
Yan Zhuang
Huawei
101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012
China
Email: zhuangyan.zhuang@huawei.com
Wang, et al. Expires April 21, 2016 [Page 9]
Internet-Draft Service Automation Architecture October 2015
Dacheng Zhang
Email: dacheng.zhang@gmail.com
Wang, et al. Expires April 21, 2016 [Page 10]
