TEAS Working Group Y. Lee (Editor) Internet Draft Huawei Intended Status: Standard Track D. Ceccarelli Ericsson Dhruv Doddy Huawei Takuya Miyasaka KDDI Peter Park KT Bin Young Yoon ETRI Expires: January 5, 2017 July 5, 2016 A Yang Data Model for ACTN VN Operation draft-lee-teas-actn-vn-yang-00.txt Abstract This document provides a YANG data model for the Abstraction and Control of Traffic Engineered (TE) networks (ACTN) Virtual Network (VN) operation. 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 This Internet-Draft will expire on January 5, 2017. Lee, et al. Expires October 2016 [Page 1] Internet-Draft ACTN VN YANG Model July 2016 Copyright Notice Copyright (c) 2016 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 1.1. Terminology...............................................3 1.2. ACTN CMI context..........................................3 2. ACTN VN YANG Model (Tree Structure)............................7 3. ACTN-VN YANG Model.............................................8 4. Security Considerations.......................................16 5. IANA Considerations...........................................16 6. Acknowledgments...............................................16 7. References....................................................17 7.1. Normative References.....................................17 7.2. Informative References...................................17 8. Contributors..................................................17 Authors' Addresses...............................................18 1. Introduction This document provides a YANG data model for the Abstraction and Control of Traffic Engineered (TE) networks (ACTN) Virtual Network (VN) operation that is going to be implemented for the Customer Network Controller (CNC)- Multi-Domain Service Coordinator (MSDC) interface (CMI). The YANG model discussed in this document is used to operate customer-driven VNs during the VN instantiation and its life-cycle operations stages. Lee, et al. Expires October 2016 [Page 2] Internet-Draft ACTN VN YANG Model July 2016 This document is based on the requirements identified in [ACTN-REQ] and on the architecture framework defined in [ACTN-FWK]. As defined in [ACTN-FW], a Virtual Network (VN) is a customer view of the TE networks and may comprise a set of end-to-end tunnels connecting customer's end points. Therefore, it is important to associate a VN with its members (which are a number of end-to-end tunnels) that are going to be created in the provider network. Each end-to-end tunnel defined under a VN is referred to as a VN member. The YANG model discussed in this document basically provides the characteristics of VNs such as VN level parameters (e.g., VN ID, VN member, VN objective function, VN service preference, etc.), customer's end point characteristics (e.g., Customer Interface Capability, Access Points Interface characteristics, etc.), and other relevant VN information that needs to be known to the MDSC to facilitate ACTN VN operation. 1.1. Terminology - Abstract Topology: Every lower controller in the provider network, when is representing its network topology to a higher layer, it may want to hide details of the actual network topology. In such case, an abstract topology may be used for this purpose. Abstract topology enhances scalability for the MDSC to operate multi-domain networks. The abstraction of topology can be applied on both MPI and CMI, from PNC to MDSC and from MDSC to CNC respectively. - Access link: A link between a customer node and a provider node. - Access Point (AP): An access point is defined on an access link. It is used to keep confidentiality between the customer and the provider. It is an identifier shared between the customer and the provider, used to map the end points of the border node in the provider NW. The AP can be used by the customer when requesting connectivity service to the provider. A number of parameters, e.g. available bandwidth, need to be associated to the AP to qualify it. - VN Access Point (VNAP): A VNAP is defined within an AP as part of a given VN and is used to identify the portion of the AP, (and hence of the access link) dedicated to a given VN. 1.2. ACTN CMI context The model presented in this document has the following ACTN context. Lee, et al. Expires October 2016 [Page 3] Internet-Draft ACTN VN YANG Model July 2016 +-------+ | CNC | +-------+ | | <--- CMI (CNC-MDSC Interface) | +-----------------------+ | MDSC | +-----------------------+ Figure 1. ACTN CMI Lee, et al. Expires October 2016 [Page 4] Internet-Draft ACTN VN YANG Model July 2016 The CNC is the actor of the VN creation/modification/deletion (aka VN CRUD (- Create, read, update and delete) model). A VN comprises a set of the VN members. Each VN member is an end-to-end tunnel from a customer point of view that connects customer endpoints (i.e., source CE and destination CE). The following figure describes a VN that comprises three VN members forming a full mesh for the VN as an illustration. VN Member 1 |<-------------------------------------->| | | | ------------- | | ( ) | | - - | +---+ X ( Provider ) Z +---+ |CE1|---+----( )---+---|CE2| +---+ AP1 ( Network ) AP2 +---+ .- - - _ -. |\ ( ) /| \ ------------- / \ | / ---- + AP3 ---- VN Member 2 \ | / VN Member 3 \ Y | / \ +---+ / `----> |CE3|<----` +---+ Figure 2. Full Mesh Example for a VN In Figure 2, a VN has three members, namely, VN Member 1, VN member 2, and VN member 3. VN Member 1 is an end-to-end tunnel identified by CE1-AP1 (source) and CE2-AP2 (destination). Similarly, VN Member 2 by CE1-AP1 and CE3-AP3 and VN Member 3 by CE3-AP3 and CE2-AP2. This particular VN shown in Figure 2 is a full mesh connectivity across these three customer end-points. It is also possible for the customer to create a VN which can be a hub and spoke or any other form of connectivity depending on its connectivity requirement. Each end-to-end tunnel may be Lee, et al. Expires October 2016 [Page 5] Internet-Draft ACTN VN YANG Model July 2016 unidirectional or bidirectional which is also depending on its connectivity requirements. The following figure shows some examples of a VN that can represented in a different connectivity form depending on the customer's connectivity requirements. +---+ +---+ +---+ +---+ +---+ +---+ |CE1|---------|CE2| |CE4|---------|CE5| |CE8|---------|CE9| +---+ +--- +---+ +---+ +---+ +---+ \ / | \ | \ | \ / | \ | \ | \ / | \ | \ | \ / | \ | \ | \ / | \ | \ | \ / | \ | \ | +---+ +---+ +---+ +---+ +---+ |CE3| |CE6| |CE7| |CE6|---------|CE7| +---+ +---+ +---+ +---+ +---+ (a) Full Mesh (b) Hub and Spoke (c) partial Mesh Figure 2. Different Connectivity Forms of a VN It is important to note that a VN can associate a multiple number of end-to-end tunnels (i.e., VN members) with one unique identifier. From a customer standpoint, this simplifies its VN operation significantly. The MDSC interacts with the CNC for the VN operation. Once the customer VN is requested by the CNC to the MDSC, the MDSC shall be responsible for translating and mapping the VN request into specific network centric-models (e.g., TE-tunnels [TE-Tunnel], TE-topology [TE-TOPO], etc.) to coordinate the multi-domain network operations with PNCs. The mapping and translation of a VN into network-centric models is out of the scope of this document. Lee, et al. Expires October 2016 [Page 6] Internet-Draft ACTN VN YANG Model July 2016 The set of assumptions that applies to this document is the following: - CNC is responsible for providing necessary Customer End-Points information to the MDSC via the CMI. - The access links (between Customer Edge (CE) Devices and the Provider Edge (PE) Devices) are assumed to have been provisioned prior to the VN instantiation request. - Access point identifiers have been configured and therefore are known in both the CNC and the MDSC. 2. ACTN VN YANG Model (Tree Structure) module: ietf-actn-vn +--rw actn | +--rw ap | | +--rw access-point-list* [access-point-id] | | +--rw access-point-id uint32 | | +--rw access-point-name? string | | +--rw max-bandwidth? decimal64 | | +--rw avl-bandwidth? decimal64 | +--rw vn | +--rw vn-list* [vn-id] | +--rw vn-id uint32 | +--rw vn-name? string | +--rw vn-member-list* [vn-member-id] | | +--rw vn-member-id uint32 | | +--rw src? leafref | | +--rw src-vn-ap-id? uint32 | | +--rw dest? leafref | | +--rw dest-vn-ap-id? uint32 | +--rw delay? uint32 | +--rw delay-variation? uint32 | +--rw packet-loss? decimal64 | +--rw bandwidth? decimal64 | +--rw protection? identityref | +--rw local-reroute? boolean | +--rw push-allowed? boolean | +--rw incremental-update? boolean | +--rw admin-status? identityref +--ro actn-state +--ro ap | +--ro access-point-list* [access-point-id] | +--ro access-point-id uint32 | +--ro access-point-name? string | +--ro max-bandwidth? decimal64 Lee, et al. Expires October 2016 [Page 7] Internet-Draft ACTN VN YANG Model July 2016 | +--ro avl-bandwidth? decimal64 +--ro vn +--ro vn-list* [vn-id] +--ro vn-id uint32 +--ro vn-name? string +--ro vn-member-list* [vn-member-id] | +--ro vn-member-id uint32 | +--ro src? leafref | +--ro src-vn-ap-id? uint32 | +--ro dest? leafref | +--ro dest-vn-ap-id? uint32 | +--ro delay? uint32 | +--ro delay-variation? uint32 | +--ro packet-loss? decimal64 | +--ro oper-status? identityref +--ro delay? uint32 +--ro delay-variation? uint32 +--ro packet-loss? decimal64 +--ro bandwidth? decimal64 +--ro protection? identityref +--ro local-reroute? boolean +--ro push-allowed? boolean +--ro incremental-update? boolean +--ro admin-status? identityref +--ro oper-status? Identityref 3. ACTN-VN YANG Code The YANG code is as follows: file ietf-actn-vn@2016-7-5.yang module ietf-actn-vn { namespace "urn:ietf:params:xml:ns:yang:ietf-actn-vn"; prefix "vn"; /* Import TE generic types */ import ietf-te-types { prefix "te-types"; } Lee, et al. Expires October 2016 [Page 8] Internet-Draft ACTN VN YANG Model July 2016 organization "IETF Traffic Engineering Architecture and Signaling (TEAS) Working Group"; contact "Editor: Young Lee "; description "This module contains a YANG module for the ACTN VN. It describes a VN operation module that takes place in the context of the CNC-MDSC Interface (CMI) of the ACTN architecture where the CNC is the actor of a VN creation /modification /deletion."; revision 2016-07-05 { description "initial version."; reference "TBD"; } /* * Groupings */ grouping access-point{ description "AP related information"; leaf access-point-id { type uint32; description "unique identifier for the referred access point"; } leaf access-point-name { type string; description "ap name"; } leaf max-bandwidth { type decimal64 { Lee, et al. Expires October 2016 [Page 9] Internet-Draft ACTN VN YANG Model July 2016 fraction-digits 2; range "0..max"; } description "max bandwidth of the AP"; } leaf avl-bandwidth { type decimal64 { fraction-digits 2; range "0..max"; } description "available bandwidth of the AP"; } /*add details and any other properties of AP, not associated by a VN CE port, PE port etc. This link may not be in the TE topology model(?) thus reference to that model would be incorrect */ }//access-point grouping vn-member { description "vn-member is described by this container"; leaf vn-member-id { type uint32; description "vn-member identifier"; } leaf src { type leafref { path "/actn/ap/access-point-list/access-point-id"; } description "reference to source AP"; } leaf src-vn-ap-id{ type uint32; description Lee, et al. Expires October 2016 [Page 10] Internet-Draft ACTN VN YANG Model July 2016 "vn-ap-id"; } leaf dest { type leafref { path "/actn/ap/access-point-list/access-point-id"; } description "reference to destination AP"; } leaf dest-vn-ap-id{ type uint32; description "vn-ap-id"; } /* can we add reference to itef-te model(?) here */ }//vn-member grouping connectivity-metric { description "service aware metrics"; leaf delay { type uint32 { range "0..max"; } description "Path Delay or latency in micro seconds."; } leaf delay-variation { type uint32 { range "0..max"; } description "Path Delay variation in micro seconds."; } leaf packet-loss { type decimal64 { fraction-digits 6; range "0 .. max"; Lee, et al. Expires October 2016 [Page 11] Internet-Draft ACTN VN YANG Model July 2016 } description "Path Packet Loss in percentage"; } /*should we add other metrics like bandwidth utilization?*/ }//connectivity-metric grouping policy { description "policy related to vn-member-id"; leaf local-reroute { type boolean; description "Policy to state if reroute can be done locally"; } leaf push-allowed { type boolean; description "Policy to state if changes can be pushed to the customer"; } leaf incremental-update { type boolean; description "Policy to allow only the changes to be reported"; } }//policy grouping objective-function { description "objective-function"; uses connectivity-metric; leaf bandwidth { type decimal64 { fraction-digits 2; Lee, et al. Expires October 2016 [Page 12] Internet-Draft ACTN VN YANG Model July 2016 range "0..max"; } description "bandwidth requested/required for vn-member-id"; } leaf protection { type identityref { base te-types:lsp-prot-type; } description "protection type."; } uses policy; }//objective-function /* * Configuration data nodes */ container actn { description "actn is described by this container"; container ap { description "AP configurations"; list access-point-list { key "access-point-id"; description "access-point identifier"; uses access-point{ description "access-point information"; } } } container vn { description "VN configurations"; Lee, et al. Expires October 2016 [Page 13] Internet-Draft ACTN VN YANG Model July 2016 list vn-list { key "vn-id"; description "a virtual network is identified by a vn-id"; leaf vn-id { type uint32; description "a unique vn identifier"; } leaf vn-name { type string; description "vn name"; } list vn-member-list{ key "vn-member-id"; description "List of VN-members in a VN"; uses vn-member; } uses objective-function; leaf admin-status { type identityref { base te-types:state-type; } default te-types:state-up; description "VN administrative state."; } }//vn-list }//vn }//actn /* * Operational data nodes */ container actn-state{ config false; description "actn is described by this container"; Lee, et al. Expires October 2016 [Page 14] Internet-Draft ACTN VN YANG Model July 2016 container ap { description "AP state"; list access-point-list { key "access-point-id"; description "access-point identifier"; uses access-point{ description "access-point information"; } } } container vn { description "VN state"; list vn-list { key "vn-id"; description "a virtual network is identified by a vn-id"; leaf vn-id { type uint32; description "a unique vn identifier"; } leaf vn-name { type string; description "vn name"; } list vn-member-list{ key "vn-member-id"; description "List of VN-members in a VN"; uses vn-member; uses connectivity-metric; leaf oper-status { type identityref { base te-types:state-type; } description Lee, et al. Expires October 2016 [Page 15] Internet-Draft ACTN VN YANG Model July 2016 "VN-member operational state."; } } uses objective-function; leaf admin-status { type identityref { base te-types:state-type; } description "VN administrative state."; } leaf oper-status { type identityref { base te-types:state-type; } description "VN operational state."; } }//vn-list }//vn }//actn-state } 4. Security Considerations TDB 5. IANA Considerations TDB 6. Acknowledgments This document was prepared using 2-Word-v2.0.template.dot. Lee, et al. Expires October 2016 [Page 16] Internet-Draft ACTN VN YANG Model July 2016 7. References 7.1. Normative References [ACTN-REQ] Lee, et al., "Requirements for Abstraction and Control of TE Networks", work in progress: draft-ietf-teas-actn- requirements. [ACTN-FWK] D. Ceccarelli, Y. Lee [Editors], "Framework for Abstraction and Control of Traffic Engineered Networks", work in progress: draft-ceccarelli-teas-actn-framework. [TE-TOPO] X. Liu, et al., "YANG Data Model for TE Topologies", work in progress: draft-ietf-teas-yang-te-topo. [TE-tunnel] T. Saad, et al., "A YANG Data Model for Traffic Engineering Tunnels and Interfaces", work in progress: draft-ietf-teas-yang-te. 7.2. Informative References 8. Contributors Contributor's Addresses Haomian Zheng Huawei Technologies Email: zhenghaomian@huawei.com Xian Zhang Huawei Technologies Email: zhang.xian@huawei.com Sergio Belotti Nokia Email: sergio.belotti@nokia.com Lee, et al. Expires October 2016 [Page 17] Internet-Draft ACTN VN YANG Model July 2016 Authors' Addresses Young Lee (ed.) Huawei Technologies Email: leeyoung@huawei.com Daniele Ceccarelli Ericsson Torshamnsgatan,48 Stockholm, Sweden Email: daniele.ceccarelli@ericsson.com Dhruv Dhoddy Huawei Technologies, Email: dhruv.ietf@gmail.com Takuya Miyasaka KDDI Email: ta-miyasaka@kddi.com Peter Park KT Email: peter.park@kt.com Bin Yeong Yoon ETRI Email: byyun@etri.re.kr Lee, et al. Expires October 2016 [Page 18]