Teas Working Group Young Lee Internet Draft Huawei Intended status: Informational Sergio Belotti Nokia Expires: August 5, 2018 Dhruv Dhody Huawei Daniele Ceccarelli Ericsson Bin Yeong Yoon ETRI February 5, 2018 Information Model for Abstraction and Control of TE Networks (ACTN) draft-ietf-teas-actn-info-model-07.txt Abstract This draft provides an information model for Abstraction and Control of Traffic Engineered Networks (ACTN). 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 Lee & Belotti, et al. Expires August 5, 2018 [Page 1] Internet-Draft ACTN Info Model February 2018 The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 5, 2018. Copyright Notice Copyright (c) 2018 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...................................................3 1.1. Terminology...............................................4 2. ACTN Common Interfaces Information Model.......................4 3. Virtual Network primitives.....................................5 3.1. VN Instantiate............................................6 3.2. VN Modify.................................................7 3.3. VN Delete.................................................7 3.4. VN Update.................................................7 3.5. VN Compute................................................7 4. Traffic Engineering (TE) primitives............................8 4.1. TE Instantiate............................................9 4.2. TE Modify.................................................9 4.3. TE Delete.................................................9 4.4. TE Topology Update (for TE resources).....................9 4.5. Path Compute.............................................10 5. VN Objects....................................................10 5.1. VN Identifier............................................10 5.2. VN Service Characteristics...............................10 5.3. VN End-Point.............................................13 5.4. VN Objective Function....................................14 5.5. VN Action Status.........................................14 5.6. VN Topology..............................................15 Lee & Belotti, et al. Expire August 5, 2018 [Page 2] Internet-Draft ACTN Info Model February 2018 5.7. VN Member................................................15 5.7.1. VN Computed Path....................................16 5.7.2. VN Service Preference...............................16 6. TE Objects....................................................17 6.1. TE Tunnel Characteristic.................................17 7. Mapping of VN Primitives with VN Objects......................19 8. Mapping of TE Primitives with TE Objects......................20 9. Security Considerations.......................................21 10. IANA Considerations..........................................22 11. References...................................................22 11.1. Normative References....................................22 11.2. Informative References..................................22 12. Contributors.................................................23 Contributors' Addresses..........................................23 Authors' Addresses...............................................23 1. Introduction This draft provides an information model for Abstraction and Control of Traffic Engineered Networks (ACTN). The information model described in this document covers the requirements identified in the ACTN requirements document [ACTN-REQ] and the interfaces identified in the ACTN architecture and framework document [ACTN-Frame]. The ACTN reference architecture [ACTN-Frame] identifies a three-tier control hierarchy comprising the following as depicted in Figure 1: - Customer Network Controllers (CNCs) - Multi-Domain Service Coordinator (MDSC) - Provisioning Network Controllers (PNCs). Lee & Belotti, et al. Expire August 5, 2018 [Page 3] Internet-Draft ACTN Info Model February 2018 +-------+ +-------+ +-------+ | 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. This document models these two interfaces and derivative interfaces there of (e.g., MDSC to MSDC in a hierarchy of MDSCs) as a single common interface. 1.1. Terminology The terms "Virtual Network (VN)" and "Virtual Network Service (VNS)" are defined in [ACTN-Frame] and the terms "abstraction" and "abstract topology" are defined in [RFC7926]. 2. ACTN Common Interfaces Information Model This section provides ACTN common interface information model to describe in terms of primitives, objects, their properties (represented as attributes), their relationships, and the resources for the service applications needed in the ACTN context. The standard interface is described between a client controller and a server controller. A client-server relationship is recursive between a CNC and an MDSC and between an MDSC and a PNC. In the CMI, Lee & Belotti, et al. Expire August 5, 2018 [Page 4] Internet-Draft ACTN Info Model February 2018 the client is a CNC while the server is an MDSC. In the MPI, the client is an MDSC and the server is a PNC. There may also be MDSC- MDSC interface(s) that need to be supported. This may arise in a hierarchy of MDSCs in which workloads may need to be partitioned to multiple MDSCs. Basic primitives (messages) are required between the CNC-MDSC and MDSC-PNC controllers. These primitives can then be used to support different ACTN network control functions like network topology request/query, VN service request, path computation and connection control, VN service policy negotiation, enforcement, routing options, etc. There are two different types of primitives depending on the type of interface: - Virtual Network primitives at CMI - Traffic Engineering primitives at MPI As well described in [ACTN-Frame], at the CMI level, there is no need for detailed TE information since the basic functionality is to translate customer service information into virtual network service operation. At the MPI level, MDSC has the main scope for multi-domain coordination and creation of a single e2e abstracted network view which is strictly related to TE information. As for topology, this document employs two types of topology: - The first type is referred to as virtual network topology which is associated with a VN. Virtual network topology is a customized topology for view and control by the customer. See Section 3.1 for details. - The second type is referred to as TE topology which is associated with provider network operation on which we can apply policy to obtain the required level of abstraction to represent the underlying physical network topology. 3. Virtual Network primitives This section provides a list of main VN primitives related to virtual network which are necessary to satisfy ACTN requirements specified in [ACTN-REQ] Lee & Belotti, et al. Expire August 5, 2018 [Page 5] Internet-Draft ACTN Info Model February 2018 At a minimum, the following VN Action primitives should be supported: - VN Instantiate - VN Modify - VN Delete - VN Update - VN Path Compute - VN Query VN Action is an object describing the main VN primitives. VN Action can assume one of the mentioned above primitives values. ::= | | | | | All these actions will solely happen at CMI level between Customer Network Controller (CNC) and Multi Domain Service Coordinator (MDSC). 3.1. VN Instantiate VN Instantiate refers to an action from customers/applications to request the creation of VNs. Depending on the agreement between client and provider, VN instantiate can imply different VN operations. There are two types of VN instantiation: VN type 1: VN is viewed as a set of edge-to-edge links (VN members). VN type 2: VN is viewed as a VN-topology comprising virtual nodes and virtual links. Lee & Belotti, et al. Expire August 5, 2018 [Page 6] Internet-Draft ACTN Info Model February 2018 Please see [ACTN-Frame] for full details regarding the types of VN. 3.2. VN Modify VN Modify refers to an action issued from customers/applications to modify an existing VN (i.e., an instantiated VN). 3.3. VN Delete VN Delete refers to an action issued from customers/applications to delete an existing VN. 3.4. VN Update VN Update refers to any update to the VN that needs to be updated to the customers. VN Update fulfills a push model at CMI level, to make customers aware of any specific changes in the topology details related to the instantiated VN. VN Update, depending of the type of VN instantiated, can be an update of VN members (edge-to-edge links) in case of VN type 1, or an update of virtual topology in case of VN type 2. The connection-related information (e.g., LSPs) update association with VNs will be part of the "translation" function that happens in MDSC to map/translate VN request into TE semantics. This information will be provided in case customer optionally wants to have more detailed TE information associated with the instantiated VN. 3.5. VN Compute VN Compute consists of Request and Reply. Request refers to an action from customers/applications to request a VN computation. VN Compute Reply refers to the reply in response to VN Compute Request. VN Compute Request/Reply is to be differentiated from a VN Instantiate. The purpose of VN Compute is a priori exploration to compute network resources availability and getting a possible VN view in which path details can be specified matching Lee & Belotti, et al. Expire August 5, 2018 [Page 7] Internet-Draft ACTN Info Model February 2018 customer/applications constraints. This a priori exploration may not guarantee the availability of the computed network resources at the time of instantiation. 3.6. VN Query VN Query refers to inquiry pertaining to the VN that has been already instantiated. VN Query fulfills a pull model and permit to get topology view. VN Query Reply refers to the reply in response to VN Query. 4. Traffic Engineering (TE) primitives This section provides a list of main TE primitives necessary to satisfy ACTN requirements specified in [ACTN-REQ] related to typical TE operations supported at MPI level. At a minimum, the following TE action primitives should be supported: - TE Instantiate/Modify/Delete - TE Topology Update (See Section 4.4. for the description) - Path Compute TE Action is an object describing the main TE primitives. TE Action can assume one of the mentioned above primitives values. ::= | | | | | All these actions will solely happen at MPI level between Multi Domain Service Coordinator (MDSC) and Provisioning Network Controller (PNC). Lee & Belotti, et al. Expire August 5, 2018 [Page 8] Internet-Draft ACTN Info Model February 2018 4.1. TE Instantiate TE Instantiate refers to an action issued from MDSC to PNC to instantiate new TE tunnels. 4.2. TE Modify TE Modify refers to an action issued from MDSC to PNC to modify existing TE tunnels. 4.3. TE Delete TE Delete refers to an action issued from MDSC to PNC to delete existing TE tunnels. 4.4. TE Topology Update (for TE resources) TE Topology Update is a primitive specifically related to MPI to provide TE resource update between any domain controller towards MDSC regarding the entire content of any "domain controller" actual TE topology or an abstracted filtered view of TE topology depending on negotiated policy. See [TE-TOPO] for detailed YANG implementation of TE topology update. ::= ::= [] ::= [] ::= [] ::= ::= [] Lee & Belotti, et al. Expire August 5, 2018 [Page 9] Internet-Draft ACTN Info Model February 2018 ::= [] Where Abstraction provides information on level of abstraction (as determined a priori). TE-topology-identifier is an identifier that identifies a specific te-topology, e.g., te-types:te-topology-id [TE-TOPO]. Node-list is detailed information related to a specific node belonging to a te-topology, e.g., te-node-attributes [TE-TOPO]. Link-list is information related to the specific link related belonging to a te-topology, e.g., te-link-attributes [TE-TOPO]. TE Termination Point-list is detailed information associated with the termination points of te-link related to a specific node, e.g., interface-switching-capability [TE-TOPO]. 4.5. Path Compute Path Compute consists of Request and Reply. Request refers to an action from MDSC to PNC to request a path computation. Path Compute Reply refers to the reply in response to Path Compute Request. The context of Path Compute is described in [Path-Compute]. 5. VN Objects This section provides a list of objects associated to VN action primitives. 5.1. VN Identifier VN Identifier is a unique identifier of the VN. 5.2. VN Service Characteristics VN Service Characteristics describes the customer/application requirements against the VNs to be instantiated. Lee & Belotti, et al. Expire August 5, 2018 [Page 10] Internet-Draft ACTN Info Model February 2018 ::= (...) Where ::= |||| The Connectivity Type identifies the type of required VN Service. In addition to the classical type of services (e.g. P2P/P2MP etc.), ACTN defines the "multi-destination" service that is a new P2P service where the end points are not fixed. They can be chosen among a list of pre-configured end points or dynamically provided by the CNC. ::= [] The VN Traffic Matrix represents the traffic matrix parameters for the required the service connectivity. Bandwidth is a mandatory parameter and a number of optional constrains can be specified in the VN Constrains (e.g. diversity, cost). They can include objective functions and TE metrics bounds as specified in [RFC5541]. Further details on the VN constraints are specified below: ::= [] [] [] ( | ) Where: Layer Protocol identifies the layer topology at which the VN service is requested. It could be for example MPLS, ODU, and OCh. Diversity allows asking for diversity constraints for a VN Instantiate/Modify or a VN Path Compute. For example, a new VN or a path is requested in total diversity from an existing one (e.g. diversity exclusion). Lee & Belotti, et al. Expire August 5, 2018 [Page 11] Internet-Draft ACTN Info Model February 2018 ::= ( (...)) | ( (...)) Shared Risk is used to get the SRLG associated with the different tunnels composing a VN. Based on the realization of VN required, group of physical resources can be impacted by the same risk. VN member (i.e., edge-to-edge link) can be impacted by this shared risk. Metric can include all the Metrics (cost, delay, delay variation, latency), bandwidth utilization parameters defined and referenced by [RFC3630] and [RFC7471]. As for VN Objective Function See Section 5.4. VN Survivability describes all attributes related to the VN recovery level and its survivability policy enforced by the customers/applications. ::= [] [] Where: VN Recovery Level is a value representing the requested level of resiliency required against the VN. The following values are defined: . Unprotected VN . VN with per tunnel recovery: The recovery level is defined against the tunnels composing the VN and it is specified in the VN Tunnel Recovery Level. ::= <0:1>|<1+1>|<1:1>|<1:N>|| The VN Tunnel Recovery Level indicates the type of protection or restoration mechanism applied to the VN. It augments the recovery types defined in [RFC4427]. ::= [] Lee & Belotti, et al. Expire August 5, 2018 [Page 12] Internet-Draft ACTN Info Model February 2018 [] [] [] Where: Local Reroute Allowed is a delegation policy to the Server to allow or not a local reroute fix upon a failure of the primary LSP. Domain Preference is only applied on the MPI where the MDSC (client) provides a domain preference to each PNC (server), e.g., when an inter-domain link fails, then PNC can choose the alternative peering with this info. Push Allowed is a policy that allows a server to trigger an updated VN topology upon failure without an explicit request from the client. Push action can be set as default unless otherwise specified. Incremental Update is another policy that triggers an incremental update from the server since the last period of update. Incremental update can be set as default unless otherwise specified. 5.3. VN End-Point VN End-Point Object describes the VN's customer end-point characteristics. ::= ( [] [])... Where: Access point identifier represents a unique identifier of the client end-point. They are used by the customer to ask for the setup of a virtual network creation. A VN End-Point is defined Lee & Belotti, et al. Expire August 5, 2018 [Page 13] Internet-Draft ACTN Info Model February 2018 against each AP in the network and is shared between customer and provider. Both the customer and the provider will map it against his own physical resources. Access Link Capability identifies the capabilities of the access link related to the given access point. (e.g., max-bandwidth, bandwidth availability, etc.) Source Indicator indicates if an end-point is source or not. 5.4. VN Objective Function The VN Objective Function applies to each VN member (i.e., each E2E tunnel) of a VN. The VN Objective Function can reuse objective functions defined in [RFC5541] section 4. For a single path computation, the following objective functions are defined: o MCP is the Minimum Cost Path with respect to a specific metric (e.g. shortest path). o MLP is the Minimum Load Path, that means find a path composted by te-link least loaded. o MBP is the Maximum residual Bandwidth Path. For a concurrent path computation, the following objective functions are defined: o MBC is to Minimize aggregate Bandwidth Consumption. o MLL is to Minimize the Load of the most loaded Link. o MCC is to Minimize the Cumulative Cost of a set of paths. 5.5. VN Action Status VN Action Status is the status indicator whether the VN has been successfully instantiated, modified, or deleted in the server network or not in response to a particular VN action. Lee & Belotti, et al. Expire August 5, 2018 [Page 14] Internet-Draft ACTN Info Model February 2018 Note that this action status object can be implicitly indicated and thus not included in any of the VN primitives discussed in Section 3. 5.6. VN Topology When a VN is seen by the customer as a topology, it is referred to as VN topology. This is associated with VN Type 2, which is comprised of virtual nodes virtual and links. ::= ::= [] :: = [] 5.7. VN Member VN Member describes details of a VN Member which is a list of a set of VN Members represented as VN_Member_List. ::= [] Where ::= [] Ingress VN End-Point is the VN End-Point information for the ingress portion of the AP. See Section 5.3 for VN End-Point details. Egress VN End-Point is the VN End-Point information for the egress portion of the AP. See Section 5.3 for VN End-Point details. VN Associated LSP describes the instantiated LSPs in the Provider's network for the VN Type 1. It describes the instantiated LSPs over the VN topology for VN Type 2. Lee & Belotti, et al. Expire August 5, 2018 [Page 15] Internet-Draft ACTN Info Model February 2018 5.7.1. VN Computed Path The VN Computed Path is the list of paths obtained after the VN path computation request from higher controller. Note that the computed path is to be distinguished from the LSP. When the computed path is signaled in the network (and thus the resource is reserved for that path), it becomes an LSP. ::= (...) 5.7.2. VN Service Preference This section provides VN Service preference. VN Service is defined in Section 2. ::= [] [] [] Where Location Service Preference describes the End-Point Location's (e.g. Data Centers) support for certain Virtual Network Functions (VNFs) (e.g., security function, firewall capability, etc.) and is used to find the path that satisfies the VNF constraint. Client-specific Preference describes any preference related to Virtual Network Service (VNS) that application/client can enforce via CNC towards lower level controllers. For example, permission the correct selection from the network of the destination related to the indicated VNF It is e.g. the case of VM migration among data center and CNC can enforce specific policy that can permit MDSC/PNC to calculate the correct path for the connectivity supporting the data center interconnection required by application. End-Point Dynamic Selection Preference describes if the End-Point (e.g. Data Center) can support load balancing, disaster recovery or VM migration and so can be part of the selection by MDSC following service Preference enforcement by CNC. Lee & Belotti, et al. Expire August 5, 2018 [Page 16] Internet-Draft ACTN Info Model February 2018 6. TE Objects 6.1. TE Tunnel Characteristics Tunnel Characteristics describes the parameters needed to configure TE tunnel. ::= [] [] [] [] [] Where ::= ||| The Tunnel Type identifies the type of required tunnel. In this draft, only P2P model is provided. Tunnel Id is the TE tunnel identifier. Tunnel Layer represents the layer technology of the LSPs supporting the tunnel. ::= ::= ||||prot | Tunnel Constraints are the base tunnel configuration constraints parameters. Where ::= [] [] Lee & Belotti, et al. Expire August 5, 2018 [Page 17] Internet-Draft ACTN Info Model February 2018 [] [] [] [] [] Topology Id references the topology used to compute the tunnel path. Bandwidth is the bandwidth used as parameter in path computation ::= | | Disjointness provides the type of resources from which the tunnel has to be disjointed SRLG is a group of physical resources impacted by the same risk from which an E2E tunnel is required to be disjointed. ::= where Setup Priority indicates the level of priority to taking resources from another tunnel [RFC3209] Holding Priority indicates the level of priority to hold resources avoiding preemption from another tunnel [RFC3209] Affinities represent structure to validate link belonging to path of the tunnel [RFC3209] ::= | Metric can include all the Metrics (cost, delay, delay variation, latency), bandwidth utilization parameters defined and referenced by [RFC3630] and [RFC7471]. ::= ::= | | | | | Lee & Belotti, et al. Expire August 5, 2018 [Page 18] Internet-Draft ACTN Info Model February 2018 See chapter 5.4 for objective function type description. 7. Mapping of VN Primitives with VN Objects This section describes the mapping of VN Primitives with VN Objects based on Section 5. ::= [] [] ::= [] [] ::= :: = [] [] ::= Lee & Belotti, et al. Expire August 5, 2018 [Page 19] Internet-Draft ACTN Info Model February 2018 [] ::= ::= ::= [] 8. Mapping of TE Primitives with TE Objects This section describes the mapping of TE Primitives with TE Objects based on Section 6. ::= ::= ::= :: = ::= Lee & Belotti, et al. Expire August 5, 2018 [Page 20] Internet-Draft ACTN Info Model February 2018 ::= 9. Security Considerations The ACTN information model described in this document defines key interfaces for managed traffic engineered networks. Securing the request and control of resources, confidentially of the information, and availability of function are critical security considerations when deploying and operating ACTN platforms. Several distributed ACTN functional components are required, and implementations should consider encrypting data that flows between components, especially when they are implemented at remote nodes, regardless these data flows are on external or internal network interfaces. From a security and reliability perspective, ACTN may encounter many risks such as malicious attack and rogue elements attempting to connect to various ACTN components. Furthermore, some ACTN components represent a single point of failure and threat vector, and must also manage policy conflicts, and eavesdropping of communication between different ACTN components. The conclusion is that all data models and protocols used to realize the ACTN info model should have rich security features, and customer, application and network data should be stored in encrypted data stores. Additional security risks may still exist. Therefore, discussion and applicability of specific security functions and protocols will be better described in documents that are use case and environment specific. Lee & Belotti, et al. Expire August 5, 2018 [Page 21] Internet-Draft ACTN Info Model February 2018 10. IANA Considerations This document has no actions for IANA. 11. References 11.1. Normative References [ACTN-REQ] Y. Lee, et al., "Requirements for Abstraction and Control of Transport Networks", draft-ietf-teas-actn-requirements, work in progress. [ACTN-Frame] D. Ceccarelli and Y. Lee, "Framework for Abstraction and Control of Transport Networks, draft-ietf-teas-actn- framework, work in progress. 11.2. Informative References [TE-TOPO] Liu, X. et al., "YANG Data Model for TE Topologies", draft-ietf-teas-yang-te-topo, work in progress. [RFC3209] D. Awduche, et al, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC3630] D. Katz, K. Kompella, D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003. [RFC4427] E. Mannie, D. Papadimitriou (Editors), "Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4427, March 2006. [RFC5541] JL. Le Roux, JP. Vasseur and Y. Lee, "Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)", RFC 5541, June 2009. [RFC7471] S. Giacalone, et al, "OSPF Traffic Engineering (TE) Metric Extensions", RFC 7471, March 2015. Lee & Belotti, et al. Expire August 5, 2018 [Page 22] Internet-Draft ACTN Info Model February 2018 [RFC7926] A. Farrel, et al., "Problem Statement and Architecture for Information Exchange between Interconnected Traffic- Engineered Networks", RFC 7926, July 2016. [Path-Compute] I. Busi, S. Belotti, et al., "Yang model for requesting Path Computation", draft-ietf-teas-yang-path- computation", work in progress. 12. Contributors Contributors' Addresses Haomian Zheng Huawei Technologies Email: zhenghaomian@huawei.com Xian Zhang Huawei Technologies Email: zhang.xian@huawei.com Authors' Addresses Young Lee (Editor) Huawei Technologies 5340 Legacy Drive Plano, TX 75023, USA Phone: (469)277-5838 Email: leeyoung@huawei.com Sergio Belotti (Editor) Alcatel Lucent Via Trento, 30 Vimercate, Italy Email: sergio.belotti@alcatel-lucent.com Dhruv Dhody Huawei Technologies, Divyashree Technopark, Whitefield Bangalore, India Email: dhruv.ietf@gmail.com Lee & Belotti, et al. Expire August 5, 2018 [Page 23] Internet-Draft ACTN Info Model February 2018 Daniele Ceccarelli Ericsson Torshamnsgatan,48 Stockholm, Sweden Email: daniele.ceccarelli@ericsson.com Bin Yeong Yoon ETRI Email: byyun@etri.re.kr Lee & Belotti, et al. Expire August 5, 2018 [Page 24]