idnits 2.17.1 draft-lopez-actn-vno-multidomains-00.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 182 has weird spacing: '...ere are domai...' -- The document date (May 25, 2014) is 3595 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 May 25, 2014 8 ACTN Use-case for Virtual Network Operation for Multiple Domains 9 in a Single Operator Network 11 draft-lopez-actn-vno-multidomains-00.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 November 25, 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 (at any dimension: applied technology, 55 administrative zones, or vendor-specific technology islands) as a 56 single virtualized network. Such an approach will facilitate the 57 deployment of NFV (Network Function Virtualization) mechanisms, and 58 accelerate rapid service deployment of new services, including more 59 dynamic and elastic services, and improve overall network operations 60 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...................7 72 3.3. Virtual Network Operations Interface (VNO-I)..............8 73 4. References.....................................................8 74 Author's Addresses................................................9 75 Intellectual Property Statement...................................9 76 Disclaimer of Validity............................................9 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, and several 91 manual operations to interface different administrative zones, 92 vendor equipment and technology. This is problem becomes more 93 relevant as the consolidation of virtualization technologies like 94 Network Functions Virtualization (NFV) calls for a more elastic 95 behavior of the transport network, able to support their 96 requirements on dynamic infrastructure reconfiguration [NFV-UC]. 98 This document provides a use-case that addresses the aforementioned 99 need within a single operator network. 101 This use-case is a part of the overarching work, called Abstraction 102 and Control of Transport Networks (ACTN). The goal of ACTN is to 103 facilitate virtual network operation by: 105 . The creation of a virtualized environment allowing operators to 106 view the abstraction of the underlying multi-admin, multi- 107 vendor, multi-technology networks and 109 . The operation and control/management of these multiple networks 110 as a single virtualized network. 112 This will accelerate rapid service deployment of new services, 113 including more dynamic and elastic services, and improve overall 114 network operations and scaling of existing services. 116 Related documents are the ACTN-framework [ACTN-Frame] and the 117 problem statement [ACTN-PS]. 119 2. Operational Issues in Multi-domain Networks 121 As an illustrative example, let's consider a multi-domain network 122 consisting of four administration zones: three Data Center Network 123 zones, A, B and C; and one core Transport Network (TN) zone to which 124 Data Center Network zones A, B and C are inter-connected. These 125 zones are under a single operator's administration, but there are 126 organizational boundaries amongst them (being under the concern of 127 different business units, for example). 129 Figure 1 shows this example multi-domain network. 131 +----------------------+ 132 | +---+ DC Domain B | 133 | |EP6| | 134 | +---+ | 135 | | | 136 | |-------- | 137 | /// \\\ | 138 +----------------+ | // \\ | 139 | TN Domain | || | | 140 +------------------------+ | ---- -|--|| Data Center B | | 141 | DC Domain A | | //- -\\ | | || | | 142 | --------- | | / \| | | \\ // | 143 | /// \\\ | | / \ | | \\\ /// | 144 | // \\ | || || | --------- | 145 | | | | || Transport || +----------------------+ 146 | | Data Center A |-|-|| Network || +----------------------+ 147 | | | | || || | --------- | 148 | \\ // | | \ / | | /// \\\ | 149 | \\\ /// | | \ /| | | // \\ | 150 | | --------- | | | \\- -// | | || | | 151 | | | | | ---- | | || Data Center C | | 152 | +---+ +---+ | | | -|--|| | | 153 | |EP1| |EP2| | | | | | \\ // | 154 | +---+ +---+ | | +---+ | | \\\ /// | 155 +------------------------+ | |EP3| | | |--------- | | 156 | +---+ | | | | | 157 | | | +---+ +---+ | 158 +----------------+ | |EP4| |EP5| | 159 | +---+ +---+ | 160 | DC Domain C | 161 +----------------------+ 163 Figure 1. Multi-domain Network 165 Although the figure depicts a single operator's network, there can 166 be several partitions into sub-domains in which some connections may 167 have to traverse several sub-domains to connect End Points (EPs). 168 EPs are customer end-points such as enterprise gateway locations, 169 some of which are directly homed on transport networks, while some 170 others are part of data center networks. EPs can also host physical 171 or virtual network functions (PNFs/VNFs) or virtual machines (VMs). 172 Connections between EPs in many cases have to traverse multiple 173 technology and/or administrative domains. For instance, in Figure 1 174 if EP1 were to be connected to EP4, then the data path for this 175 connection would have to traverse DC Domain A, TN Domain and DC 176 Domain C where the destination of this connection resides. Another 177 example of a multi-domain connection would be from EP3 in TN Domain 178 to EP 6 in DC Domain B. 180 There are also intra-domain connections; for instance, a connection 181 from EP4 to EP5 would only constitute an intra-domain connection 182 within DC Domain C. We can assume there are domain control entities 183 of various types (e.g., SDN-controller, NMS/EMS, Control Plane, or a 184 combination of these entities, etc.) responsible for domain-specific 185 network operations such as connection operation and management 186 (including creation/deletion of a connection, path computation and 187 protections, etc.), and other functions related to operations such 188 as configuration, monitor, fault management, etc. As different 189 technologies have emerged in different times, there is a plethora of 190 diverse domain control systems with their respective interfaces and 191 protocols. To maximize capital investments, operators tend to keep 192 the current legacy operation and management technology and to 193 continue to offer network services from the technology deployed in 194 their networks. 196 Due to these domain boundaries, facilitating connections that 197 traverse multi-domains is not readily achieved. Each domain control 198 establishing other domain control in a peer to peer level creates 199 permutation issues for the end-to-end control. Besides, these domain 200 controls are optimized for its local operation and in most cases not 201 suited for controlling the end-to-end connectivity services. For 202 instance, the discovery of the EPs that belong to other domains is 203 hard to achieve partly because of the lack of the common API and its 204 information model and control mechanisms thereof to disseminate the 205 relevant information. 207 Moreover, the path computation for any end-to-end connection would 208 need abstraction of network resources and ways to find an optimal 209 path that meets the connection's service requirements. This would 210 require knowledge of the inter-domain peering relationships and the 211 local domain policy. 213 From a connection provisioning perspective, in order to facilitate a 214 fast and reliable end-to-end signaling, each domain operation and 215 management elements should ideally speak the same control protocols 216 to its neighboring domains. 218 From a network connectivity management perspective, it would require 219 a mechanism to disseminate any connectivity issues from the local 220 domain to the other domains whenever the local domain cannot resolve 221 a connectivity issues. 223 3. Virtual Network Operations for Multi-domain Networks 225 Based on the issues discussed in the previous section in regard to 226 the operations for multi-domain networks, we propose the definition 227 of a virtual network operations (VNO) infrastructure that helps 228 operators to establish end-to-end connections spanning multiple 229 domains and its related operation and management issues. 231 The VNO Coordinator facilitates virtual network operation, the 232 creation of a virtualized environment allowing operators to view the 233 underlying multi-admin, multi-vendor, multi-technology networks and 234 their operation and management as a single, virtualized network. 236 The basic premise of VNO is to create a hierarchy of operations in 237 which to separate virtual network operations from physical network 238 operations. This helps operators build virtual network operations 239 infrastructure on top of physical network operations. Figure 2 shows 240 a hierarchical structure of operations. 242 +----------------------+ 243 | VNO Coordinator | 244 +----------------------+ 245 | 246 | VNO-I 247 .-----------------------------------------. 248 | | | | 249 +----------+ +----------+ +----------+ +----------+ 250 | DCN | | DCN | | DCN | | | 251 | Domain A | | Domain B | | Domain C | | TN Domain| 252 | Control | | Control | | Control | | Control | 253 | | | | | | | | 254 +----------+ +----------+ +----------+ +----------+ 255 | | | | 256 /----\ /----\ /----\ /----\ 257 // \\ // \\ // \\ // \\ 258 | DC A | | DC B | | DC C | | Transport| 259 \\ // \\ // \\ // \\Network/ 260 \----/ \----/ \----/ \----/ 262 Figure 2. Operations Hierarchy 264 Figure 2 shows operations hierarchy based on Figure 1. The two main 265 ideas are: 267 1. Domain control/management entities (e.g., DCN Domain Control A, B, 268 C and TN Domain Control) are kept intact to continue its domain 269 operations with its technology choice and policy, etc. As 270 discussed before domain control/management entities can be a form 271 of various types (e.g., SDN-controller, NMS/EMS, Control Plane, or 272 a combination of these entities, etc.) that is responsible for 273 domain-specific network operations. 275 2. The VNO Coordinator establishes a standard-based API (which is 276 termed as the Virtual Network Operations Interface (VNO-I) in 277 Figure 2) with each of the domain control/management entities. The 278 VNO coordination takes place via the VNO-I's. 280 3.1. Responsibilities of Domain Control/Management Entities 282 . Creation of domain-level abstraction of network topology 284 It is the responsibility of domain control/management entity to 285 create an abstraction of its network topology. The level of 286 abstraction varies from one domain to another, subject to local 287 domain policy. All EPs and gateway nodes to other domains need 288 to be represented at a minimum. The level of internal nodes and 289 links may be abstracted according to its domain policy. 291 . Dissemination of abstraction of network topology to the VNO 292 Coordinator (both Push and Pull models) 294 . VNO interface support (e.g., protocol, messages, etc.) 296 . Domain-level connection control/management that includes 297 creation/deletion of a connection 299 . Domain-level path computation 301 . Domain-level protection and reroute 303 . Other functions related to operations such as monitor, fault 304 management, etc. 306 3.2. Responsibilities of the VNO Coordinator 308 . Creation of a global abstraction of network topology. 310 The VNO Coordinator assembles each domain level abstraction of 311 network topology into a global abstraction of the end-to-end 312 network. 314 . VNO interface support (e.g., protocol, messages, etc.) 316 . End-to-end connection lifecycle management 318 . Invocation of path provisioning request to each domain 320 . Invocation of path protection/reroute to the affected domain(s) 322 . End-to-end network monitoring and fault management 324 . OSS/BSS interface support for service management 326 3.3. Virtual Network Operations Interface (VNO-I) 328 [Editor's Note: the details of the supported functions of the VNO-I 329 as well as the discussions pertaining to the info/data model 330 requirements of the VNO-I will be supplied in the revision] 332 4. References 334 [ACTN-Frame] D. Ceccarelli, L. Fang, Y. Lee and D. Lopez, "Framework 335 for Abstraction and Control of Transport Networks," draft- 336 ceccarelli-actn-framework, work in progress. 338 [ACTN-PS] Y. Lee, D. King, M. Boucadair, and R. Jing, "Problem 339 Statement for the Abstraction and Control of Transport 340 Networks," draft-leeking-actn-problem-statement, work in 341 progress. 343 [NFV-UC] NFV ETSI Industry Specification Group (ISG), "Network 344 Functions Virtualisation (NFV); Use Cases", 345 http://www.etsi.org/deliver/etsi_gs/NFV/001_099/001/01.01. 346 01_60/gs_NFV001v010101p.pdf 348 Author's Addresses 350 Diego Lopez (Editor) 351 diego@tid.es 353 Young Lee 354 leeyoung@huawei.com 356 Intellectual Property Statement 358 The IETF Trust takes no position regarding the validity or scope of 359 any Intellectual Property Rights or other rights that might be 360 claimed to pertain to the implementation or use of the technology 361 described in any IETF Document or the extent to which any license 362 under such rights might or might not be available; nor does it 363 represent that it has made any independent effort to identify any 364 such rights. 366 Copies of Intellectual Property disclosures made to the IETF 367 Secretariat and any assurances of licenses to be made available, or 368 the result of an attempt made to obtain a general license or 369 permission for the use of such proprietary rights by implementers or 370 users of this specification can be obtained from the IETF on-line 371 IPR repository at http://www.ietf.org/ipr 373 The IETF invites any interested party to bring to its attention any 374 copyrights, patents or patent applications, or other proprietary 375 rights that may cover technology that may be required to implement 376 any standard or specification contained in an IETF Document. Please 377 address the information to the IETF at ietf-ipr@ietf.org. 379 Disclaimer of Validity 381 All IETF Documents and the information contained therein are 382 provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION 383 HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 384 THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 385 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 386 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 387 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 388 FOR A PARTICULAR PURPOSE. 390 Acknowledgment 392 Funding for the RFC Editor function is currently provided by the 393 Internet Society.