idnits 2.17.1 draft-lopez-actn-vno-multidomains-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 183 has weird spacing: '...ere are domai...' -- The document date (October 27, 2014) is 3462 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Diego Lopez (Ed.) 2 Telefonica 3 Internet Draft 4 Intended status: Informational 6 October 27, 2014 8 ACTN Use-case for Virtual Network Operation for Multiple Domains 9 in a Single Operator Network 11 draft-lopez-actn-vno-multidomains-01.txt 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with 16 the provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as 26 reference material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 27, 2014. 36 Copyright Notice 38 Copyright (c) 2014 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with 46 respect to this document. 48 Abstract 50 This document provides a use-case that addresses the need for 51 facilitating the application of virtual network abstractions to 52 network operation. These abstractions shall create a virtualized 53 environment supporting operators in viewing and controlling 54 different domains as a single virtualized network. Each domain can 55 be created due to the applied technology, administrative zones, or 56 vendor-specific technology islands).Such an approach will facilitate 57 the deployment of NFV (Network Function Virtualization) mechanisms, 58 and accelerate rapid service deployment of new services, including 59 more dynamic and elastic services, and improve overall network 60 operations and scaling of existing services. 62 This use-case considers the application of these abstractions within 63 the network of a single operator. 65 Table of Contents 67 1. Introduction..................................................2 68 2. Operational Issues in Multi-domain Networks....................3 69 3. Virtual Network Operations for Multi-domain Networks...........6 70 3.1. Responsibilities of Domain Control/Management Entities....7 71 3.2. Responsibilities of the VNO Coordinator...................8 72 3.3. Virtual Network Operations Interface (VNO-I)..............9 73 4. References.....................................................9 74 Author's Addresses...............................................10 75 Intellectual Property Statement..................................10 76 Disclaimer of Validity...........................................10 78 1. Introduction 80 Network operators build and operate their network using multiple 81 domains in different dimensions. Domains may be defined by a 82 collection of links and nodes (each of a different technology), 83 administrative zones under the concern of a particular business 84 entity, or vendor-specific "islands" where specific control 85 mechanisms have to be applied. Establishing end-to-end connections 86 spanning several of these domains is a perpetual problem for 87 operators, which need to address both interoperability and 88 operational concerns at the control and data planes. The 89 introduction of new services often requiring connections that 90 traverse multiple domains needs significant planning, the creation 91 of umbrella Network Management Systems (NMSs) or even several manual 92 operations to interface different administrative zones, vendor 93 equipment and technology. This problem becomes more relevant as the 94 consolidation of virtualization technologies like Network Functions 95 Virtualization (NFV) calls for a more elastic behavior of the 96 transport network, able to support their requirements on dynamic 97 infrastructure reconfiguration [NFV-UC]. 99 This document provides a use-case that addresses the aforementioned 100 need within a single operator network. 102 This use-case is a part of the overarching work, called Abstraction 103 and Control of Transport Networks (ACTN). The goal of ACTN is to 104 facilitate virtual network operation by: 106 . The creation of a virtualized environment allowing operators to 107 view and work with the abstraction of the underlying multi- 108 admin, multi-vendor, multi-technology networks and 110 . The operation and control/management of these multiple networks 111 as a single virtualized network. 113 This will accelerate rapid service deployment of new services, 114 including more dynamic and elastic services, and improve overall 115 network operations and scaling of existing services. 117 Related documents are the ACTN-framework [ACTN-Frame] and the 118 problem statement [ACTN-PS]. 120 2. Operational Issues in Multi-domain Networks 122 As an illustrative example, let's consider a multi-domain network 123 consisting of four administration zones: three Data Center Network 124 zones, A, B and C; and one core Transport Network (TN) zone to which 125 Data Center Network zones A, B and C are inter-connected. These 126 zones are under a single operator's administration, but there are 127 organizational boundaries amongst them (being under the concern of 128 different business units or technical departments, for example). 130 Figure 1 shows this multi-domain network example. 132 +----------------------+ 133 | +---+ DC Domain B | 134 | |EP6| | 135 | +---+ | 136 | | | 137 | |-------- | 138 | /// \\\ | 139 +----------------+ | // \\ | 140 | TN Domain | || | | 141 +------------------------+ | ---- -|--|| Data Center B | | 142 | DC Domain A | | //- -\\ | | || | | 143 | --------- | | / \| | | \\ // | 144 | /// \\\ | | / \ | | \\\ /// | 145 | // \\ | || || | --------- | 146 | | | | || Transport || +----------------------+ 147 | | Data Center A |-|-|| Network || +----------------------+ 148 | | | | || || | --------- | 149 | \\ // | | \ / | | /// \\\ | 150 | \\\ /// | | \ /| | | // \\ | 151 | | --------- | | | \\- -// | | || | | 152 | | | | | ---- | | || Data Center C | | 153 | +---+ +---+ | | | -|--|| | | 154 | |EP1| |EP2| | | | | | \\ // | 155 | +---+ +---+ | | +---+ | | \\\ /// | 156 +------------------------+ | |EP3| | | |--------- | | 157 | +---+ | | | | | 158 | | | +---+ +---+ | 159 +----------------+ | |EP4| |EP5| | 160 | +---+ +---+ | 161 | DC Domain C | 162 +----------------------+ 164 Figure 1. Multi-domain Network 166 Although the figure depicts a single operator's network, there can 167 be several partitions into sub-domains in which some connections may 168 have to traverse several sub-domains to connect End Points (EPs). 169 EPs are customer end-points such as enterprise gateway locations, 170 some of which are directly homed on transport networks, while some 171 others are part of data center networks. EPs can also host physical 172 or virtual network functions (PNFs/VNFs) or virtual machines (VMs). 173 Connections between EPs in many cases have to traverse multiple 174 technology and/or administrative domains. For instance, in Figure 1 175 if EP1 were to be connected to EP4, then the data path for this 176 connection would have to traverse DC Domain A, TN Domain and DC 177 Domain C where the destination of this connection resides. Another 178 example of a multi-domain connection would be from EP3 in TN Domain 179 to EP 6 in DC Domain B. 181 There are also intra-domain connections; for instance, a connection 182 from EP4 to EP5 would only constitute an intra-domain connection 183 within DC Domain C. We can assume there are domain control entities 184 of various types (e.g., SDN-controller, NMS/EMS, Control Plane, or a 185 combination of these entities, etc.) responsible for domain-specific 186 network operations such as connection operation and management 187 (including creation/deletion of a connection, path computation and 188 protections, etc.), and other functions related to operations such 189 as configuration, monitor, fault management, etc. As different 190 technologies have emerged in different points of time, there is a 191 plethora of diverse domain control systems with their respective 192 interfaces and protocols. To maximize capital investments, operators 193 tend to keep the current legacy operation and management technology 194 and to continue to offer network services from the technology 195 deployed in their networks. 197 Due to these domain boundaries, facilitating connections that 198 traverse multi-domains is not readily achieved. Each domain control 199 establishing other domain control in a peer to peer level creates 200 permutation issues for the end-to-end control. Besides, these domain 201 controls are optimized for its local operation and in most cases not 202 suited for controlling the end-to-end connectivity services. For 203 instance, the discovery of the EPs that belong to other domains is 204 hard to achieve partly because of the lack of the common API and its 205 information model and control mechanisms thereof to disseminate the 206 relevant information. Some scenarios would require a path 207 computation service for each domain to carry out end-to-end path 208 computation, but considering current status of the network. 210 Moreover, the path computation for any end-to-end connection would 211 need abstraction of network resources and ways to find an optimal 212 path that meets the connection's service requirements. This would 213 require knowledge of the inter-domain peering relationships and the 214 local domain policy. 216 From a connection provisioning perspective, in order to facilitate a 217 fast and reliable end-to-end signaling, each domain operation and 218 management elements should ideally work with the same control 219 protocols that its neighboring domains. At least each domain should 220 support a stitching mode, so the end-to-end connection can be 221 created in a per domain basis. 223 From a network connectivity management perspective, it would require 224 a mechanism to disseminate any connectivity issues from the local 225 domain to the other domains whenever the local domain cannot resolve 226 a connectivity issue. This connectivity issue can happen during the 227 provisioning time or during the network operation, when there is a 228 failure on a connection that cannot be restored or protected. 230 3. Virtual Network Operations for Multi-domain Networks 232 Based on the issues discussed in the previous section in regard to 233 the operations for multi-domain networks, we propose the definition 234 of a virtual network operations (VNO) infrastructure that helps 235 operators to establish end-to-end connections spanning multiple 236 domains and its related operation and management issues. 238 The VNO Coordinator facilitates virtual network operation, the 239 creation of a virtualized environment allowing operators to view the 240 underlying multi-admin, multi-vendor, multi-technology networks and 241 their operation and management as a single, virtualized network. 243 The basic premise of VNO is to create a hierarchy of operations in 244 which to separate virtual network operations from physical network 245 operations. This helps operators build virtual network operations 246 infrastructure on top of physical network operations. Figure 2 shows 247 a hierarchical structure of operations. 249 +----------------------+ 250 | VNO Coordinator | 251 +----------------------+ 252 | 253 | VNO-I 254 .-----------------------------------------. 255 | | | | 256 +----------+ +----------+ +----------+ +----------+ 257 | DCN | | DCN | | DCN | | | 258 | Domain A | | Domain B | | Domain C | | TN Domain| 259 | Control | | Control | | Control | | Control | 260 | | | | | | | | 261 +----------+ +----------+ +----------+ +----------+ 262 | | | | 263 /----\ /----\ /----\ /----\ 264 // \\ // \\ // \\ // \\ 265 | DC A | | DC B | | DC C | | Transport| 266 \\ // \\ // \\ // \\Network/ 267 \----/ \----/ \----/ \----/ 269 Figure 2. Operations Hierarchy 271 Figure 2 shows operations hierarchy based on Figure 1. The two main 272 ideas are: 274 1. Domain control/management entities (e.g., DCN Domain Control A, B, 275 C and TN Domain Control) are kept intact to continue its domain 276 operations with its technology choice and policy, etc. As 277 discussed before domain control/management entities can be a form 278 of various types (e.g., SDN-controller, NMS/EMS, Control Plane, or 279 a combination of these entities, etc.) that is responsible for 280 domain-specific network operations. 282 2. The VNO Coordinator establishes a standard-based API (which is 283 termed as the Virtual Network Operations Interface (VNO-I) in 284 Figure 2) with each of the domain control/management entities. The 285 VNO coordination takes place via the VNO-I's. 287 3.1. Responsibilities of Domain Control/Management Entities 289 . Creation of domain-level abstraction of network topology 291 It is the responsibility of domain control/management entity to 292 create an abstraction of its network topology. The level of 293 abstraction varies from one domain to another, subject to local 294 domain policy. All EPs and gateway nodes to other domains need 295 to be represented at a minimum. The level of internal nodes and 296 links may be abstracted according to its domain policy. 298 . Dissemination of abstraction of network topology to the VNO 299 Coordinator (both Push and Pull models) 301 . VNO interface support (e.g., protocol, messages, etc.) 303 . Domain-level connection control/management that includes 304 creation/deletion of a connection 306 . Domain-level path computation and optimization 308 . Domain-level protection and reroute 310 . Domain-lever policy enforcement 312 . Other functions related to operations such as monitor, fault 313 management, accounting, etc. 315 3.2. Responsibilities of the VNO Coordinator 317 . Creation of a global abstraction of network topology. 319 The VNO Coordinator assembles each domain level abstraction of 320 network topology into a global abstraction of the end-to-end 321 network. 323 . VNO interface support (e.g., protocol, messages, etc.) 325 . End-to-end connection lifecycle management 327 . Invocation of path provisioning request to each domain 328 (including optimization requests) 330 . Invocation of path protection/reroute to the affected domain(s) 332 . End-to-end network monitoring and fault management. This could 333 imply potential KPIs and alarm correlation capabilities. 335 . End-to-end accounting and generation of detailed records for 336 resource usage 338 . End-to-end policy enforcement 340 . OSS/BSS interface support for service management 342 3.3. Virtual Network Operations Interface (VNO-I) 344 VNO-I should support the transfer of information detailed above to 345 perform the identified functionality. It should be based on open 346 standard-based API. 348 [Editor's Note: the details of the supported functions of the VNO-I 349 as well as the discussions pertaining to the info/data model 350 requirements of the VNO-I will be supplied in the revision] 352 4. References 354 [ACTN-Frame] D. Ceccarelli, L. Fang, Y. Lee and D. Lopez, "Framework 355 for Abstraction and Control of Transport Networks," draft- 356 ceccarelli-actn-framework, work in progress. 358 [ACTN-PS] Y. Lee, D. King, M. Boucadair, and R. Jing, "Problem 359 Statement for the Abstraction and Control of Transport 360 Networks," draft-leeking-actn-problem-statement, work in 361 progress. 363 [NFV-UC] NFV ETSI Industry Specification Group (ISG), "Network 364 Functions Virtualisation (NFV); Use Cases", 365 http://www.etsi.org/deliver/etsi_gs/NFV/001_099/001/01.01. 366 01_60/gs_NFV001v010101p.pdf 368 Author's Addresses 370 Diego Lopez (Editor) 371 Telefonica 372 Email: diego@tid.es 374 Young Lee 375 Huawei 376 Email: leeyoung@huawei.com 378 LUIS MIGUEL CONTRERAS MURILLO 379 Telefonica 380 Email: luismiguel.contrerasmurillo@telefonica.com 382 Victor Lopez Alvarez 383 Telefonica 384 Email: victor.lopezalvarez@telefonica.com