Network Working Group A. Wang Internet-Draft China Telecom Intended status: Standards Track Y. Cheng Expires: April 20, 2016 China Unicom October 18, 2015 Service Automation Management Architecture draft-wang-l3sm-service-automation-architecture-00 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 20, 2016. Copyright Notice Copyright (c) 2015 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 Wang & Cheng Expires April 20, 2016 [Page 1] Internet-Draft Service Automation Architecture October 2015 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 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) 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. Wang & Cheng Expires April 20, 2016 [Page 2] Internet-Draft Service Automation Architecture October 2015 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 between components in this figure are focused on the instantiation of service configuration onto network elements. Wang & Cheng Expires April 20, 2016 [Page 3] Internet-Draft Service Automation Architecture October 2015 +-------+ | | | 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 & Cheng Expires April 20, 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 & Cheng Expires April 20, 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 & Cheng Expires April 20, 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 & Cheng Expires April 20, 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 model Service Models are created to describe the characteristics of a service, as agreed upon with consumers of that service while Network Models describe the configuration, state data and operations of a network protocol/general device. 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. [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. Wang & Cheng Expires April 20, 2016 [Page 8] Internet-Draft Service Automation Architecture October 2015 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [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 Wang & Cheng Expires April 20, 2016 [Page 9]