idnits 2.17.1 draft-klee-actn-connectivity-multi-vendor-domains-02.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 -- The document date (November 10, 2014) is 3426 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Kwang-koog Lee 2 Internet Draft Hosong Lee 3 Intended status: Informational KT 4 Expires April 2014 Ricard Vilata 5 CTTC 6 Victor Lopez 7 Telefonica 9 November 10, 2014 11 ACTN Use-case for On-demand E2E Connectivity Services in Multiple 12 Vendor Domain Transport Networks 14 draft-klee-actn-connectivity-multi-vendor-domains-02.txt 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with 19 the provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six 27 months and may be updated, replaced, or obsoleted by other documents 28 at any time. It is inappropriate to use Internet-Drafts as 29 reference material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on April 10, 2015. 39 Copyright Notice 41 Copyright (c) 2014 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with 49 respect to this document. 51 Abstract 53 This document provides a use-case that addresses the need for 54 facilitating the application of virtual network abstractions and the 55 control and management of on-demand end-to-end provisioning of 56 connections that traverse multiple vendor domain transport networks. 58 These abstractions shall help create a virtualized environment 59 supporting operators in viewing and controlling different vendor 60 domains, especially for on-demand network connectivity service for a 61 single operator. 63 Table of Contents 65 1. Introduction..................................................2 66 2. On-demand End-to-end Connectivity in Multi-vendor Domain 67 Transport Networks................................................3 68 3. Requirements...................................................5 69 4. References.....................................................8 70 5. Contributors...................................................8 71 Intellectual Property Statement...................................9 72 Disclaimer of Validity............................................9 74 1. Introduction 76 Network operators build and operate their network using multiple 77 domains in different dimensions. Domains may be defined by a 78 collection of links and nodes (each of a different technology), 79 administrative zones under the concern of a particular business 80 entity, or vendor-specific "islands" where specific control 81 mechanisms have to be applied. Due to the technology of each vendor, 82 the optical components cannot be interconnected. Therefore each 83 optical domain becomes an isolated island in terms of provisioning. 84 The network operators use vendor-specific NMS implementations along 85 with an operator-tailored umbrella provisioning system, which may 86 include a technology specific Operations Support System (OSS). 87 Thanks to the evolution of vendor specific SDN controllers, the 88 network operators require a network entity, which abstract the 89 details of the optical layer while enabling end-to-end provisioning 90 of services. The establishment of end-to-end connections spanning 91 several of these domains is a perpetual problem for operators, which 92 need to address both interoperability and operational concerns at 93 the control and data planes. 95 The introduction of new services, often requiring connections that 96 traverse multiple domains, needs significant planning, and several 97 manual operations to interface multiple vendor-specific domains in 98 which specific control/management mechanisms of the vendor equipment 99 have to be applied (e.g., EMS/NMS, OSS/BSS, control plane, SDN 100 controller, etc.). Undoubtedly, establishing an on-demand end-to-end 101 connection which requires provisioning based on dynamic resource 102 information is more difficult in the current network context. 104 This document provides a use-case that addresses the need for 105 creating a virtualized environment supporting operators in viewing 106 and controlling different vendor domains, especially for on-demand 107 network connectivity service for a single operator. This will 108 accelerate rapid service deployment of new services, including more 109 dynamic and elastic services, and improve overall network operations 110 and scaling of existing services. 112 This use-case is a part of the overarching work, called Abstraction 113 and Control of Transport Networks (ACTN). Related documents are the 114 ACTN-framework [ACTN-Frame] and the problem statement [ACTN-PS]. 116 2. On-demand End-to-end Connectivity in Multi-vendor Domain Transport 117 Networks 119 This section provides an architecture example to illustrate the 120 context of the current challenges and issues operators face in 121 delivering on-demand end-to-end connectivity services in operators' 122 multi-vendor domain transport networks. 124 | 125 | / End-to-End Connection \ | 126 |/-----------------------------------------------------------\| 127 |\-----------------------------------------------------------/| 128 | \ / | 129 | | 130 | +----------------+ | 131 | | | | 132 | | Converged | | 133 | | Packet-Optical| | 134 | +-------------+ | Core Domain | +-------------+ | 135 | | |--| (Vendor A) |--| | | 136 +----+ | Access | +----------------+ | Access | +----+ 137 | CE1|--| Domain 1 | | | | Domain 3 |--| CE2| 138 +----+ | (Vendor B) |----- -----| (Vendor C) | +----+ 139 +-------------+ +-------------+ 141 Figure 1. Multi-vendor Domains 143 As an illustrative example, consider a multi-domain transport 144 network consisting of three domains: one core converged packet- 145 optical domain (Vendor A) and two access domains (Vendors B and C). 146 Each access domain is managed by its domain control/management 147 mechanism which is often a proprietary vendor-specific scheme. The 148 core domain is also managed by Vendor A's proprietary 149 control/management mechanism (e.g., EMS/NMS, OSS/BSS, Control Plane, 150 SDN Controller, or any combination of these entities, etc.) that may 151 not interoperate with access domain control/management mechanisms or 152 at best partially interoperate if Vendor A is same as Vendor B or 153 Vendor C. 155 Due to these domain boundaries, facilitating on-demand end-to-end 156 connections (e.g., Ethernet Virtual Connections, etc.) that traverse 157 multi-domains is not readily achieved. These domain controls are 158 optimized for its local operation and in most cases not suited for 159 controlling the end-to-end connectivity services. For instance, the 160 discovery of the edge nodes that belong to other domains is hard to 161 achieve partly because of the lack of the common API and its 162 information model and control mechanisms thereof to disseminate the 163 relevant information. 165 Moreover, the path computation for any on-demand end-to-end 166 connection would need abstraction of dynamic network resources and 167 ways to find an optimal path that meets the connection's service 168 requirements. This would require knowledge of both the domain level 169 dynamic network resource information and the inter-domain 170 connectivity information including domain gateway/peering points and 171 the local domain policy. 173 From an on-demand connection provisioning perspective, in order to 174 facilitate a fast and reliable end-to-end signaling, each domain 175 operation and management elements should ideally speak the same 176 control protocols to its neighboring domains. However, this is not 177 possible for the current network context unless a folk-lift green 178 field technology deployment with a single vendor solution would be 179 done. Although each domain applies the same protocol for the data 180 plane, an end-to-end connectivity traversing multiple domains might 181 not be provided due to a management and control mechanism focusing 182 only on its own domain. 184 From a network connectivity management perspective, it would require 185 a mechanism to disseminate any connectivity issues from the local 186 domain to the other domains whenever the local domain cannot resolve 187 a connectivity issues. This is hard to achieve due to the lack of 188 the common API and its agreed-upon information model and control 189 mechanisms thereof to disseminate the relevant information. 191 From an operation's perspective, the current network environments 192 are not conducive to offering on-demand end-to-end connectivity 193 services in multi-vendor domain transport networks. For instance, 194 when the performance monitoring inquiry is requested, operators 195 manually monitor each domain and aggregate the performance results. 196 However, it may not be precise because of the different measurement 197 timing employed by each domain. 199 3. Requirements 201 In the previous section, we discussed the current challenges and 202 issues that prevent operators from offering on-demand end-to-end 203 connectivity services in multi-vendor domain transport networks. 205 This section provides a high-level requirement for enabling on- 206 demand end-to-end connectivity services in multi-vendor domain 207 transport networks in a single operator environment. 209 Figure 2 shows information flow requirements of the aforementioned 210 context. 212 +-------------------------------------------------+ 213 | | 214 | Customer On-demand Network Service | 215 | | 216 +-------------------------------------------------+ 217 /|\ 218 | 219 \|/ 220 +-------------------------------------------------+ 221 | | 222 | Abstracted Global View | 223 | | 224 +-------------------------------------------------+ 225 /|\ 226 | 227 \|/ 228 +-------------------------------------------------+ 229 | | 230 | Single Integrated E2E Network View | 231 | | 232 +-------------------------------------------------+ 233 /|\ /|\ /|\ 234 | | | 235 \|/ \|/ \|/ 236 +-------------+ +-------------+ +-------------+ 237 | | | | | | 238 | Domain A | | Domain B | | Domain C | 239 | Control | | Control | | Control | 240 +-------------+ +-------------+ +-------------+ 242 Figure 2. Information Flow Requirements for Enabling On-demand 243 Network Connectivity Service in Multi-vendor Domain Networks 245 There are a number of key requirements from Figure 2. 247 - A single integrated end-to-end network view is necessary to be 248 able to provision the end-to-end paths that traverse multiple 249 vendor domains. In this approach the scalability and 250 confidentiality problems are solved, but new considerations must 251 be taken into account: 253 o Limited awareness, by the VNC, of the intra-domain resources 254 availability. 256 o Sub-optimal path selection. 258 - The path computations shall be performed in two stages: first on 259 the abstracted end-to-end network view (happening at VNC), and on 260 the second stage it shall be expanded by each PNC. 262 - In order to create a single integrated end-to-end network view, 263 discovery of inter-connection data between domains including the 264 domain border nodes/links is necessary. (The entity to collect 265 domain-level data is responsible for collecting inter-connection 266 links/nodes) 268 - The entity to collect domain-level data should recognize 269 interoperability method between each domain. (There might be 270 several interoperability mechanisms according to technology being 271 applied.) 273 - The entity responsible to collect domain-level data and create an 274 integrated end-to-end view should support push/pull model with 275 respect to all its interfaces. 277 - The same entity should coordinate a signaling flow for end-to-end 278 connections to each domain involved. (This entity to domain 279 control is analogous to an NMS to EMS relationship) 281 - The entity responsible to create abstract global view should 282 support push/pull model with respect to all its interfaces. (Note 283 that the two entities (an entity to create an integrated end-to- 284 end view and an entity to create an abstracted global view) can be 285 assumed by the same entity, which is an implementation issue. 287 - Hierarchical composition of integrated network views should be 288 enabled by a common API between NorthBound Interface of the Single 289 Integrated End-to-End view (handled by VNC) and Domain Control 290 (handled by PNC). 292 - There is a need for a common API between each domain control to 293 the entity that is responsible for creating a single integrated 294 end-to-end network view. At the minimum, the following items are 295 required on the API: 297 o Programmability of the API. 299 o The multiple levels/granularities of the abstraction of 300 network resource (which is subject to policy and service 301 need). 303 o The abstraction of network resource should include customer 304 end points and inter-domain gateway nodes/links. 306 o Any physical network constraints (such as SRLG, link 307 distance, etc.) should be reflected in abstraction. 309 o Domain preference and local policy (such as preferred peering 310 point(s), preferred route, etc.) 312 o Domain network capability (e.g., support of push/pull model). 314 - The entity responsible for abstraction of a global view into a 315 customer view should provide a programmable API to allow the 316 flexibility. Abstraction might be provided by representing each 317 domain as a virtual node (node abstraction) or a set of virtual 318 nodes and links (link abstraction). Node abstraction creates a 319 network topology composed by nodes representing each network 320 domain and the inter-domain links between the border nodes of each 321 domain. 323 o Abstraction of a global view into a customer view should be 324 provided to allow customer to dynamically request network on- 325 demand services including connectivity services. 327 o What level of details customer should be allowed to view 328 network is subject to negotiation between the customer and 329 the operator. 331 4. References 333 [ACTN-Frame] D. Ceccarelli, L. Fang, Y. Lee and D. Lopez, "Framework 334 for Abstraction and Control of Transport Networks," draft- 335 ceccarelli-actn-framework, work in progress. 337 [ACTN-PS] Y. Lee, D. King, M. Boucadair, R. Jing, and L. Murillo, 338 "Problem Statement for the Abstraction and Control of 339 Transport Networks," draft-leeking-actn-problem-statement, 340 work in progress. 342 5. Acknowledgement 344 The authors wish to thank Young Lee for the discussions in the 345 document. 347 6. Contributors 349 Authors' Addresses 351 Kwang-koog Lee 353 KT 354 Email: kwangkoog.lee@kt.com 356 Hosong Lee 358 KT 359 Email: hosong.lee@kt.com 361 Ricard Vilata 362 CTTC 363 Email: ricard.vilalta@cttc.es 365 Victor Lopez 366 Telefonica 367 Email: victor.lopezalvarez@telefonica.com