idnits 2.17.1 draft-klee-actn-connectivity-multi-vendor-domains-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 -- The document date (December 2014) is 3419 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 December 2014 6 June 24, 2014 8 ACTN Use-case for On-demand E2E Connectivity Services in Multiple 9 Vendor Domain Transport Networks 11 draft-klee-actn-connectivity-multi-vendor-domains-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 December 24, 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 and the 52 control and management of on-demand end-to-end provisioning of 53 connections that traverse multiple vendor domain transport networks. 55 These abstractions shall help create a virtualized environment 56 supporting operators in viewing and controlling different vendor 57 domains, especially for on-demand network connectivity service for a 58 single operator. 60 Table of Contents 62 1. Introduction..................................................2 63 2. On-demand End-to-end Connectivity in Multi-vendor Domain 64 Transport Networks................................................3 65 3. Requirements...................................................4 66 4. References.....................................................7 67 5. Contributors...................................................7 68 Intellectual Property Statement...................................8 69 Disclaimer of Validity............................................8 71 1. Introduction 73 Network operators build and operate their network using multiple 74 domains in different dimensions. Domains may be defined by a 75 collection of links and nodes (each of a different technology), 76 administrative zones under the concern of a particular business 77 entity, or vendor-specific "islands" where specific control 78 mechanisms have to be applied. Establishing end-to-end connections 79 spanning several of these domains is a perpetual problem for 80 operators, which need to address both interoperability and 81 operational concerns at the control and data planes. 83 The introduction of new services, often requiring connections that 84 traverse multiple domains, needs significant planning, and several 85 manual operations to interface multiple vendor-specific domains in 86 which specific control/management mechanisms of the vendor equipment 87 have to be applied (e.g., EMS/NMS, OSS/BSS, control plane, SDN 88 controller, etc.). Undoubtedly, establishing an on-demand end-to-end 89 connection which requires provisioning based on dynamic resource 90 information is more difficult in the current network context. 92 This document provides a use-case that addresses the need for 93 creating a virtualized environment supporting operators in viewing 94 and controlling different vendor domains, especially for on-demand 95 network connectivity service for a single operator. This will 96 accelerate rapid service deployment of new services, including more 97 dynamic and elastic services, and improve overall network operations 98 and scaling of existing services. 100 This use-case is a part of the overarching work, called Abstraction 101 and Control of Transport Networks (ACTN). Related documents are the 102 ACTN-framework [ACTN-Frame] and the problem statement [ACTN-PS]. 104 2. On-demand End-to-end Connectivity in Multi-vendor Domain Transport 105 Networks 107 This section provides an architecture example to illustrate the 108 context of the current challenges and issues operators face in 109 delivering on-demand end-to-end connectivity services in operators' 110 multi-vendor domain transport networks. 112 | 113 | / End-to-End Connection \ | 114 |/-----------------------------------------------------------\| 115 |\-----------------------------------------------------------/| 116 | \ / | 117 | | 118 | +----------------+ | 119 | | | | 120 | | Converged | | 121 | | Packet-Optical| | 122 | +-------------+ | Core Domain | +-------------+ | 123 | | |--| (Vendor A) |--| | | 124 +----+ | Access | +----------------+ | Access | +----+ 125 | CE1|--| Domain 1 | | | | Domain 3 |--| CE2| 126 +----+ | (Vendor B) |----- -----| (Vendor C) | +----+ 127 +-------------+ +-------------+ 129 Figure 1. Multi-vendor Domains 131 As an illustrative example, consider a multi-domain transport 132 network consisting of three domains: one core converged packet- 133 optical domain (Vendor A) and two access domains (Vendors B and C). 134 Each access domain is managed by its domain control/management 135 mechanism which is often a proprietary vendor-specific scheme. The 136 core domain is also managed by Vendor A's proprietary 137 control/management mechanism (e.g., EMS/NMS, OSS/BSS, Control Plane, 138 SDN Controller, or any combination of these entities, etc.) that may 139 not interoperate with access domain control/management mechanisms or 140 at best partially interoperate if Vendor A is same as Vendor B or 141 Vendor C. 143 Due to these domain boundaries, facilitating on-demand end-to-end 144 connections (e.g., Ethernet Virtual Connections, etc.) that traverse 145 multi-domains is not readily achieved. These domain controls are 146 optimized for its local operation and in most cases not suited for 147 controlling the end-to-end connectivity services. For instance, the 148 discovery of the edge nodes that belong to other domains is hard to 149 achieve partly because of the lack of the common API and its 150 information model and control mechanisms thereof to disseminate the 151 relevant information. 153 Moreover, the path computation for any on-demand end-to-end 154 connection would need abstraction of dynamic network resources and 155 ways to find an optimal path that meets the connection's service 156 requirements. This would require knowledge of both the domain level 157 dynamic network resource information and the inter-domain 158 connectivity information including domain gateway/peering points and 159 the local domain policy. 161 From an on-demand connection provisioning perspective, in order to 162 facilitate a fast and reliable end-to-end signaling, each domain 163 operation and management elements should ideally speak the same 164 control protocols to its neighboring domains. However, this is not 165 possible for the current network context unless a folk-lift green 166 field technology deployment with a single vendor solution would be 167 done. Although each domain applies the same protocol for the data 168 plane, an end-to-end connectivity traversing multiple domains might 169 not be provided due to a management and control mechanism focusing 170 only on its own domain. 172 From a network connectivity management perspective, it would require 173 a mechanism to disseminate any connectivity issues from the local 174 domain to the other domains whenever the local domain cannot resolve 175 a connectivity issues. This is hard to achieve due to the lack of 176 the common API and its agreed-upon information model and control 177 mechanisms thereof to disseminate the relevant information. 179 From an operation's perspective, the current network environments 180 are not conducive to offering on-demand end-to-end connectivity 181 services in multi-vendor domain transport networks. For instance, 182 when the performance monitoring inquiry is requested, operators 183 manually monitor each domain and aggregate the performance results. 184 However, it may not be precise because of the different measurement 185 timing employed by each domain. 187 3. Requirements 189 In the previous section, we discussed the current challenges and 190 issues that prevent operators from offering on-demand end-to-end 191 connectivity services in multi-vendor domain transport networks. 193 This section provides a high-level requirement for enabling on- 194 demand end-to-end connectivity services in multi-vendor domain 195 transport networks in a single operator environment. 197 Figure 2 shows information flow requirements of the aforementioned 198 context. 200 +-------------------------------------------------+ 201 | | 202 | Customer On-demand Network Service | 203 | | 204 +-------------------------------------------------+ 205 /|\ 206 | 207 \|/ 208 +-------------------------------------------------+ 209 | | 210 | Abstracted Global View | 211 | | 212 +-------------------------------------------------+ 213 /|\ 214 | 215 \|/ 216 +-------------------------------------------------+ 217 | | 218 | Single Integrated E2E Network View | 219 | | 220 +-------------------------------------------------+ 221 /|\ /|\ /|\ 222 | | | 223 \|/ \|/ \|/ 224 +-------------+ +-------------+ +-------------+ 225 | | | | | | 226 | Domain A | | Domain B | | Domain C | 227 | Control | | Control | | Control | 228 +-------------+ +-------------+ +-------------+ 230 Figure 2. Information Flow Requirements for Enabling On-demand 231 Network Connectivity Service in Multi-vendor Domain Networks 233 There are a number of key requirements from Figure 2. 235 - A single integrated end-to-end network view is necessary to be 236 able to compute paths and provision the end-to-end paths that 237 traverse multiple vendor domains. 239 - In order to create a single integrated end-to-end network view, 240 discovery of inter-connection data between domains including the 241 domain border nodes/links is necessary. (The entity to collect 242 domain-level data is responsible for collecting inter-connection 243 links/nodes) 245 - The entity to collect domain-level data should recognize 246 interoperability method between each domain. (There might be 247 several interoperability mechanisms according to technology being 248 applied.) 250 - The entity responsible to collect domain-level data and create an 251 integrated end-to-end view should support push/pull model with 252 respect to all its interfaces. 254 - The same entity should coordinate a signaling flow for end-to-end 255 connections to each domain involved. (This entity to domain 256 control is analogous to an NMS to EMS relationship) 258 - The entity responsible to create abstract global view should 259 support push/pull model with respect to all its interfaces. (Note 260 that the two entities (an entity to create an integrated end-to- 261 end view and an entity to create an abstracted global view) can be 262 assumed by the same entity, which is an implementation issue. 264 - There is a need for a common API between each domain control to 265 the entity that is responsible for creating a single integrated 266 end-to-end network view. At the minimum, the following items are 267 required on the API: 269 o Programmability of the API. 271 o The multiple levels/granularities of the abstraction of 272 network resource (which is subject to policy and service 273 need). 275 o The abstraction of network resource should include customer 276 end points and inter-domain gateway nodes/links. 278 o Any physical network constraints (such as SRLG, link 279 distance, etc.) should be reflected in abstraction. 281 o Domain preference and local policy (such as preferred peering 282 point(s), preferred route, etc.) 284 o Domain network capability (e.g., support of push/pull model). 286 - The entity responsible for abstraction of a global view into a 287 customer view should provide a programmable API to allow the 288 flexibility. 290 o Abstraction of a global view into a customer view should be 291 provided to allow customer to dynamically request network on- 292 demand services including connectivity services. 294 o What level of details customer should be allowed to view 295 network is subject to negotiation between the customer and 296 the operator. 298 4. References 300 [ACTN-Frame] D. Ceccarelli, L. Fang, Y. Lee and D. Lopez, "Framework 301 for Abstraction and Control of Transport Networks," draft- 302 ceccarelli-actn-framework, work in progress. 304 [ACTN-PS] Y. Lee, D. King, M. Boucadair, R. Jing, and L. Murillo, 305 "Problem Statement for the Abstraction and Control of 306 Transport Networks," draft-leeking-actn-problem-statement, 307 work in progress. 309 5. Acknowledgement 311 The authors wish to thank Young Lee for the discussions in the 312 document. 314 6. Contributors 316 Authors' Addresses 318 Kwang-koog Lee 320 KT 321 Email: kwangkoog.lee@kt.com 323 Hosong Lee 325 KT 326 Email: hosong.lee@kt.com 328 Intellectual Property Statement 330 The IETF Trust takes no position regarding the validity or scope of 331 any Intellectual Property Rights or other rights that might be 332 claimed to pertain to the implementation or use of the technology 333 described in any IETF Document or the extent to which any license 334 under such rights might or might not be available; nor does it 335 represent that it has made any independent effort to identify any 336 such rights. 338 Copies of Intellectual Property disclosures made to the IETF 339 Secretariat and any assurances of licenses to be made available, or 340 the result of an attempt made to obtain a general license or 341 permission for the use of such proprietary rights by implementers or 342 users of this specification can be obtained from the IETF on-line 343 IPR repository at http://www.ietf.org/ipr 345 The IETF invites any interested party to bring to its attention any 346 copyrights, patents or patent applications, or other proprietary 347 rights that may cover technology that may be required to implement 348 any standard or specification contained in an IETF Document. Please 349 address the information to the IETF at ietf-ipr@ietf.org. 351 Disclaimer of Validity 353 All IETF Documents and the information contained therein are 354 provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION 355 HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 356 THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 357 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 358 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 359 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 360 FOR A PARTICULAR PURPOSE. 362 Acknowledgment 364 Funding for the RFC Editor function is currently provided by the 365 Internet Society.