Network Working Group Young Lee Internet Draft Huawei Intended status: Informational Sergio Belotti Alcatel-Lucent Expires: September 2015 Dhruv Dhody Huawei Daniele Ceccarelli Ericsson March 7, 2015 Information Model for Abstraction and Control of Transport Networks draft-leebelotti-actn-info-00.txt Abstract This draft provides an information model for abstraction and control of transport networks. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Lee-Belotti Expires September 7, 2015 [Page 1] Internet-Draft ACTN Info Model March 2015 This Internet-Draft will expire on September 7, 2015. 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 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 2. ACTN Applications..............................................4 2.1.1. Coordination of Multi-destination Service Requirement/Policy..........................................5 2.1.2. Application Service Policy-aware Network Operation...7 2.1.3. Network Function Virtualization Service Enabled Connectivity................................................9 2.1.4. Dynamic Service Control Policy Enforcement for Performance and Fault Management...........................10 2.1.5. E2E VN Survivability and Multi-Layer (Packet-Optical) Coordination for Protection/Restoration....................12 3. ACTN common interfaces information model......................13 4. References....................................................18 4.1. Informative References...................................18 5. Contributors..................................................18 Contributors' Addresses..........................................18 Authors' Addresses...............................................18 1. Introduction This draft provides information model for the ACTN interfaces identified in the ACTN architecture and framework document [ACTN- Frame]. Lee-Belotti Expires September 7, 2015 [Page 2] Internet-Draft ACTN Info Model March 2015 The ACTN architecture identified a three-tier control hierarchy as depicted in Figure 1: - Customer Network Controllers (CNC) - Multi-Domain Service Coordinator (MDSC) - Physical Network Controllers (PNC). VPN customer NW Mobile Customer ISP NW service Customer | | | +-------+ +-------+ +-------+ | CNC-A | | CNC-B | | CNC-C | +-------+ +-------+ +-------+ \___________ | ____________ _/ ---------- | CMI ------------ \ | / +-----------------------+ | MDSC | +-----------------------+ _________/ | \_________ -------- | MPI ------------____ / | \ +-------+ +-------+ +-------+ | PNC | | PNC | | PNC | +-------+ +-------+ +-------+ Figure 1. A Three-tier ACTN control hierarchy The two interfaces with respect to the MDSC, one north of the MDSC and the other south of the MDSC are referred to as CMI (CNC-MDSC Interface) and MPI (MDSC-PNC Interface), respectively. It is intended to model these two interfaces with one common model. Section 2 provides a high-level applicability of ACTN based on a number of use-cases listed in the following: - draft-cheng-actn-ptn-requirements-00 (ACTN Use-cases for Packet Transport Networks in Mobile Backhaul Networks) Lee-Belotti Expires September 7, 2015 [Page 3] Internet-Draft ACTN Info Model March 2015 - draft-dhody-actn-poi-use-case-03 (Packet Optical Integration (POI) Use Cases for Abstraction and Control of Transport Networks (ACTN)) - draft-fang-actn-multidomain-dci-01 (ACTN Use Case for Multi-domain Data Center Interconnect) - draft-klee-actn-connectivity-multi-vendor-domains-03 (ACTN Use- case for On-demand E2E Connectivity Services in Multiple Vendor Domain Transport Networks) - draft-kumaki-actn-multitenant-vno-00 (ACTN : Use case for Multi Tenant VNO) - draft-lopez-actn-vno-multidomains-01 (ACTN Use-case for Virtual Network Operation for Multiple Domains in a Single Operator Network) - draft-shin-actn-mvno-multi-domain-00 (ACTN Use-case for Mobile Virtual Network Operation for Multiple Domains in a Single Operator Network) - draft-xu-actn-perf-dynamic-service-control-02 (Use Cases and Requirements of Dynamic Service Control based on Performance Monitoring in ACTN Architecture) J 2. ACTN Applications This section provides the scope of the ACTN applicability to support the following applications. - Coordination of Multi-destination Service Requirement/Policy (Section 2.2.1) - Application Service Policy-aware Network Operation (section 2.2.2) - Network Function Virtualization Service Enabled Connectivity (2.2.3) - Dynamic Service Control Policy Enforcement for Performance/Fault Management (Section 2.2.4) - E2E VN Survivability and Multi-Layer (Packet-Optical) Coordination for Protection/Restoration (Section 2.2.5) Lee-Belotti Expires September 7, 2015 [Page 4] Internet-Draft ACTN Info Model March 2015 2.1.1. Coordination of Multi-destination Service Requirement/Policy +----------------+ | CNC | | (Global DC | | Operation | | Control) | +--------+-------+ | | Service Requirement/Policy: | | - Endpoint/DC location info | | - Endpoint/DC dynamic | | selection policy | | (for VM migration, DR, LB) | v +---------+--------+ | Multi-domain | Service policy-driven |Service Controller| dynamic DC selection +-----+---+---+----+ | | | | | | +----------------+ | +----------------+ | | | +-----+-----+ +-----+------+ +------+-----+ | PNC for | | PNC for | | PNC for | | Transport | | Transport | | Transport | | Network A | | Network B | | network C | +-----------+ +------------+ +------------+ | | | +---+ ------ ------ ------ +---+ |DC1|--//// \\\\ //// \\\\ //// \\\\---+DC4| +---+ | | | | | | +---+ | TN A +-----+ TN B +----+ TN C | / | | | | | / \\\\ //// / \\\\ //// \\\\ //// +---+ ------ / ------ \ ------ \ |DC2| / \ \+---+ +---+ / \ |DC6| +---+ \ +---+ +---+ |DC3| \|DC4| +---+ +---+ DR: Disaster Recovery LB: Load Balancing Figure 2: Service Policy-driven Data Center Selection Figure 2 shows how VN service policies from the CNC are incorporated by the MDSC to support multi-destination applications. Multi- Lee-Belotti Expires September 7, 2015 [Page 5] Internet-Draft ACTN Info Model March 2015 destination applications refer to applications in which the selection of the destination of a network path for a given source needs to be decided dynamically to support such applications. Data Center selection problems arise for VM mobility, disaster recovery and load balancing cases. VN's service policy plays an important role for virtual network operation. Service policy can be static or dynamic. Dynamic service policy for data center selection may be placed as a result of utilization of data center resources supporting VNs. The MSDC would then incorporate this information to meet the service objective of this application. Lee-Belotti Expires September 7, 2015 [Page 6] Internet-Draft ACTN Info Model March 2015 2.1.2. Application Service Policy-aware Network Operation +----------------+ | CNC | | (Global DC | | Operation | | Control) | +--------+-------+ | | Application Service Policy | | - VNF requirement (e.g. | | security function, etc.) | | - Location profile for each VNF | v +---------+--------+ | Multi-domain | Dynamically select the |Service Controller| network destination to +-----+---+---+----+ meet VNF requirement. | | | | | | +---------------+ | +----------------+ | | | +------+-----+ +-----+------+ +------+-----+ | PNC for | | PNC for | | PNC for | | Transport | | Transport | | Transport | | Network A | | Network B | | network C | | | | | | | +------------+ +------------+ +------------+ | | | {VNF b} | | | {VNF b,c} +---+ ------ ------ ------ +---+ |DC1|--//// \\\\ //// \\\\ //// \\\\-|DC4| +---+ | | | | | |+---+ | TN A +---+ TN B +--+ TN C | / | | | | | / \\\\ //// / \\\\ //// \\\\ //// +---+ ------ / ------ \ ------ \ |DC2| / \ \\+---+ +---+ / \ |DC6| {VNF a} +---+ +---+ +---+ |DC3| |DC4| {VNF a,b,c} +---+ +---+ {VNF a, b} {VNF a, c} Figure 3: Application Service Policy-aware Network Operation Lee-Belotti Expires September 7, 2015 [Page 7] Internet-Draft ACTN Info Model March 2015 This scenario is similar to the previous case in that the VN service policy for the application can be met by a set of multiple destinations that provide the required virtual network functions (VNF). Virtual network functions can be, for example, security functions required by the VN application. The VN service policy by the CNC would indicate the locations of a certain VNF that can be fulfilled. This policy information is critical in finding the optimal network path subject to this constraint. As VNFs can be dynamically moved across different DCs, this policy should be dynamically enforced from the CNC to the MDSC and the PNCs. Lee-Belotti Expires September 7, 2015 [Page 8] Internet-Draft ACTN Info Model March 2015 2.1.3. Network Function Virtualization Service Enabled Connectivity +----------------+ | CNC | | (Global DC | | Operation | | Control) | +--------+-------+ | | Service Policy | | (e.g., firewall, traffic | | optimizer) | | | v +---------+--------+ | Multi-domain | Select network |Service Controller| connectivity subject to +-----+---+---+----+ meeting service policy | | | | | | +---------------+ | +----------------+ | | | +------+-----+ +-----+------+ +------+-----+ | PNC for | | PNC for | | PNC for | | Transport | | Transport | | Transport | | Network A | | Network B | | network C | | | | | | | +------------+ +------------+ +------------+ | | | | | | +---+ ------ ------ ------ +---+ |DC1|--//// \\\\ //// \\\\ //// \\\\-|DC4| +---+ | | | | | |+---+ | TN A +---+ TN B +--+ TN C | / | | | | | / \\\\ //// / \\\\ //// \\\\ //// +---+ ------ / ------ \ ------ \ |DC2| / \ \\+---+ +---+ / \ |DC6| +---+ +---+ +---+ |DC3| |DC4| +---+ +---+ Figure 4: Network Function Virtualization Service Enabled Connectivity Lee-Belotti Expires September 7, 2015 [Page 9] Internet-Draft ACTN Info Model March 2015 Network Function Virtualization Services are usually setup between customers' premises and service provider premises and are provided mostly by cloud providers or content delivery providers. The context may include, but not limited to a security function like firewall, a traffic optimizer, the provisioning of storage or computation capacity where the customer does not care whether the service is implemented in a given data center or another. These services may be hosted virtually by the provider or physically part of the network. This allows the service provider to hide his own resources (both network and data centers) and divert customer requests where most suitable. This is also known as "end points mobility" case and introduces new concepts of traffic and service provisioning and resiliency (e.g., Virtual Machine mobility). 2.1.4. Dynamic Service Control Policy Enforcement for Performance and Fault Management +------------------------------------------------+ | Customer Network Controller | +------------------------------------------------+ 1.Traffic| /|\4.Traffic | /|\ Monitor& | | Monitor | | 8.Traffic Optimize | | Result 5.Service | | modify & Policy | | modify& | | optimize \|/ | optimize Req.\|/ | result +------------------------------------------------+ | Mult-domain Service Controller | +------------------------------------------------+ 2. Path | /|\3.Traffic | | Monitor | | Monitor | |7.Path Request | | Result 6.Path | | modify & | | modify& | | optimize \|/ | optimize Req.\|/ | result +------------------------------------------------+ | Physical Network Controller | +------------------------------------------------+ Figure 5: Dynamic Service Control for Performance and Fault Management Figure 5 shows the flow of dynamic service control policy enforcement for performance and fault management initiated by customer per their VN. The feedback loop and filtering mechanism tailored for VNs performed by the MDSC differentiates this ACTN Lee-Belotti Expires September 7, 2015 [Page 10] Internet-Draft ACTN Info Model March 2015 scope from traditional network management paradigm. VN level dynamic OAM data model is a building block to support this capability. Lee-Belotti Expires September 7, 2015 [Page 11] Internet-Draft ACTN Info Model March 2015 2.1.5. E2E VN Survivability and Multi-Layer (Packet-Optical) Coordination for Protection/Restoration +----------------+ | Customer | | Network | | Controller | +--------*-------+ * | E2E VN Survivability Req. * | - VN Protection/Restoration * v - 1+1, Restoration, etc. +------*-----+ - End Point (EP) info. | | | MDSC | MDSC enforces VN survivability | | requirement, determining the | | optimal combination of Packet/ +------*-----+ Opticalprotection/restoration, * Optical bypass, etc. * * ********************************************** * * * * +----*-----+ +----*----+ +----*-----+ +----*----+ |PNC for | |PNC for | |PNC for | |PNC for | |Access N. | |Packet C.| |Optical C.| |Access N.| +----*-----+ +----*----+ +----*-----+ +---*-----+ * --*--- * * * /// \\\ * * --*--- | Packet | * ----*- /// \\\ | Core +------+------/// \\\ | Access +----\\ /// * | Access | | Network | ---+-- * | Network | +---+ |\\\ /// | * \\\ ///---+EP6| | +---+- | | -----* -+---+ +---+ +-+-+ | | +----/// \\\ | | |EP1| | +--------------+ Optical | | | +---+ +---+ | | Core +------+ +--+EP5| +-+-+ \\\ /// +---+ |EP2| ------ | +---+ | | +--++ ++--+ |EP3| |EP4| +---+ +---+ Figure 6: E2E VN Survivability and Multi-layer Coordination for Protection and Restoration Lee-Belotti Expires September 7, 2015 [Page 12] Internet-Draft ACTN Info Model March 2015 Figure 6 shows the need for E2E protection/restoration control coordination that involves CNC, MDSC and PNCs to meet the VN survivability requirement. VN survivability requirement and its policy need to be translated into multi-domain and multi-layer network protection and restoration scenarios across different controller types. After an E2E path is setup successfully, the MSDC has a unique role to enforce policy-based flexible VN survivability requirement by coordinating all PNC domains. As seen in Figure 6, multi-layer (i.e., packet/optical) coordination is a subset of this E2E protection/restoration control operation. The MDSC has a role to play in determining an optimal protection/restoration level based on the customer's VN survivability requirement. For instance, the MDSC needs to interface the PNC for packet core as well as the PNC for optical core and enforce protection/restoration policy as part of the E2E protection/restoration. Neither the PNC for packet core nor the PNC for optical core is in a position to be aware of the E2E path and its protection/restoration situation. This role of the MSDC is unique for this reason. In some cases, the MDSC will have to determine and enforce optical bypass to find a feasible reroute path upon packet core network failure which cannot be resolved the packet core network itself. To coordinate this operation, the PNCs will need to update its domain level abstract topology upon resource changes due to a network failure or other factors. The MSDC will incorporate all these update to determine if an alternate E2E reroute path is necessary or not based on the changes reported from the PNCs. It will need to update the E2E abstract topology and the affected CN's VN topology in real-time. This refers to dynamic synchronization of topology from Physical topology to abstract topology to VN topology. MDSC will also need to perform the path restoration signaling to the affected PNCs whenever necessary. 3. ACTN common interfaces information model This section provides ACTN common interface information model to support primitives between controllers: CNC-MDSC and MDSC-PNC. The basic primitives are required between the controllers. It is described between a client controller and a server controller. A client-server relationship is recursive between a CNC and a MDSC and between a MDSC and a PNC. In the CMI interface, the client is a CNC Lee-Belotti Expires September 7, 2015 [Page 13] Internet-Draft ACTN Info Model March 2015 while the server is a MDSC. In the MPI interface, the client is a MDSC and the server is a PNC. At a minimum, the following primitives should be supported: - Virtual Network (VN) Instantiate/Modify/Delete - VN Topology Update (Push Model) ::= Where is an identifier that identifies a particular VN. is an indicator if this is for (i) instantiate, (ii) modify; (iii) delete. There may be a case where a query of a VN is necessary before an instantiate request. This is subject to further investigation. ::= ( [])... Where Lee-Belotti Expires September 7, 2015 [Page 14] Internet-Draft ACTN Info Model March 2015 It is assumed that a list of interface identifiers has been known to the server prior to the VN Query message flow. ::= [] The Client Capability comprises the client interface capability (e.g., maximum interface bandwidth, etc.) and other client-specific policy information. ::= | Where pertains to end-client policies which specify the end-client related service/operational policies. Details of this field will be supplied in a later revision. pertains to the policies related to multi-domain network operation assumed by the MDSC. For example, domain selection preference in the context of multi- domain networks is a network-client policy. Details of this field will be supplied in a later revision. describes the End-Point Location's support for certain Virtual Network Functions (VNFs) (e.g., security function, firewall capability, etc.). describes if the End-Point can support load balancing, disaster recovery or VM migration. ::= Lee-Belotti Expires September 7, 2015 [Page 15] Internet-Draft ACTN Info Model March 2015 [] [] Where ::= | describes a particular cost associated with the VN Topology link/path such as reservable bandwidth, maximum link/path capacity, latency, etc. describes if the request is . a single vs. a bulk request, . VN diversity preference (in case of a bulk request, whether VNs should be disjoint or not), . SRLG is required in describing link/path topology, or . Others TDB. indicates a specific objective function for computing a path vector. This only applies when the VN Topology Type is a path vector. ::= Where ::= | | | ::= Lee-Belotti Expires September 7, 2015 [Page 16] Internet-Draft ACTN Info Model March 2015 [] ::= Where ::= | <1+1> | <1:N> ::= [] Where is a delegation policy to the Server to allow or not a local reroute fix upon a failure of the primary LSP. is only applied on the MPI where the MDSC (client) provides a domain preference to each PNC (server). is a policy that allows a server to trigger an updated VN topology upon failure without an explicit request from the client. is another policy that triggers an increment update from the server. is the status indicator whether the VN has been successfully instantiated/modified/deleted in the server network or not in response to . describes the resulting VN topology. Details of are TDB. describes the instantiated VN property. Details are TBD. Lee-Belotti Expires September 7, 2015 [Page 17] Internet-Draft ACTN Info Model March 2015 4. References 4.1. Informative References [ACTN-Frame] D. Ceccarelli, et al., "Framework for Abstraction and Control of Transport Networks", draft-ceccarelli-actn- framework, work in progress. 5. Contributors Contributors' Addresses Authors' Addresses Young Lee Huawei Technologies 5340 Legacy Drive Plano, TX 75023, USA Phone: (469)277-5838 Email: leeyoung@huawei.com Sergio Belotti Alcatel Lucent Via Trento, 30 Vimercate, Italy Email: sergio.belotti@alcatel-lucent.com Dhruv Dhoddy Huawei Technologies dhruv.ietf@gmail.com Daniele Ceccarelli Ericsson Torshamnsgatan,48 Stockholm, Sweden Email: daniele.ceccarelli@ericsson.com Lee-Belotti Expires September 7, 2015 [Page 18]