idnits 2.17.1 draft-klee-actn-connectivity-multi-vendor-domains-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 -- The document date (December 2014) is 3410 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 KT 3 Intended status: Informational 4 Expires December 2014 6 June 4, 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-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 December 4, 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.....................................................6 67 5. Contributors...................................................7 68 Intellectual Property Statement...................................7 69 Disclaimer of Validity............................................7 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.). 90 This document provides a use-case that addresses the need for 91 creating a virtualized environment supporting operators in viewing 92 and controlling different vendor domains, especially for on-demand 93 network connectivity service for a single operator. This will 94 accelerate rapid service deployment of new services, including more 95 dynamic and elastic services, and improve overall network operations 96 and scaling of existing services. 98 This use-case is a part of the overarching work, called Abstraction 99 and Control of Transport Networks (ACTN). Related documents are the 100 ACTN-framework [ACTN-Frame] and the problem statement [ACTN-PS]. 102 2. On-demand End-to-end Connectivity in Multi-vendor Domain Transport 103 Networks 105 This section provides an architecture example to illustrate the 106 context of the current challenges and issues operators face in 107 delivering on-demand end-to-end connectivity services in operators' 108 multi-vendor domain transport networks. 110 | 111 | / End-to-End Connection \ | 112 |/-----------------------------------------------------------\| 113 |\-----------------------------------------------------------/| 114 | \ / | 115 | | 116 | +----------------+ | 117 | | | | 118 | | Converged | | 119 | | Packet-Optical| | 120 | +-------------+ | Core Domain | +-------------+ | 121 | | |--| (Vendor A) |--| | | 122 +----+ | Access | +----------------+ | Access | +----+ 123 | CE1|--| Domain 1 | | | | Domain 3 |--| CE2| 124 +----+ | (Vendor B) |----- -----| (Vendor C) | +----+ 125 +-------------+ +-------------+ 127 Figure 1. Multi-vendor Domains 129 As an illustrative example, consider a multi-domain transport 130 network consisting of three domains: One Core Converged Packet- 131 Optical Domain (Vendor A) and two access domains (Vendors B and C). 132 Each access domain is managed by its domain control/management 133 mechanism which is often a proprietary vendor-specific scheme. The 134 core domain is also managed by Vendor A's proprietary 135 control/management mechanism (e.g., EMS/NMS, OSS/BSS, ASON/GMPLS 136 Control Plane, SDN Controller, or any combination of these entities, 137 etc.) that may not interoperate with access domain 138 control/management mechanisms or at best partially interoperate if 139 Vendor A is same as Vendor B or Vendor C. 141 Due to these domain boundaries, facilitating on-demand end-to-end 142 connections (e.g., Ethernet Virtual Connections, etc.) that traverse 143 multi-domains is not readily achieved. These domain controls are 144 optimized for its local operation and in most cases not suited for 145 controlling the end-to-end connectivity services. For instance, the 146 discovery of the Client Ends (CE) that belong to other domains is 147 hard to achieve partly because of the lack of the common API and its 148 information model and control mechanisms thereof to disseminate the 149 relevant information. 151 Moreover, the path computation for any on-demand end-to-end 152 connection would need abstraction of dynamic network resources and 153 ways to find an optimal path that meets the connection's service 154 requirements. This would require knowledge of both the domain level 155 dynamic network resource information and the inter-domain 156 connectivity information including domain gateway/peering points and 157 the local domain policy. 159 From an on-demand connection provisioning perspective, in order to 160 facilitate a fast and reliable end-to-end signaling, each domain 161 operation and management elements should ideally speak the same 162 control protocols to its neighboring domains. However, this is not 163 possible for the current network context unless a folk-lift green 164 field technology deployment with a single vendor solution would be 165 done. 167 From a network connectivity management perspective, it would require 168 a mechanism to disseminate any connectivity issues from the local 169 domain to the other domains whenever the local domain cannot resolve 170 a connectivity issues. This is hard to achieve due to the lack of 171 the common API and its agreed-upon information model and control 172 mechanisms thereof to disseminate the relevant information. 174 From an operation's perspective, the current network environments 175 are not conducive to offering on-demand end-to-end connectivity 176 services in multi-vendor domain transport networks. 178 3. Requirements 180 In the previous section, we discussed the current challenges and 181 issues that prevent operators from offering on-demand end-to-end 182 connectivity services in multi-vendor domain transport networks. 184 This section provides a high-level requirement for enabling on- 185 demand end-to-end connectivity services in multi-vendor domain 186 transport networks in a single operator environment. 188 Figure 1 shows information flow requirements of the aforementioned 189 context. 191 +-------------------------------------------------+ 192 | | 193 | Customer On-demand Network Service | 194 | | 195 +-------------------------------------------------+ 196 /|\ 197 | 198 \|/ 199 +-------------------------------------------------+ 200 | | 201 | Abstracted Global View | 202 | | 203 +-------------------------------------------------+ 204 /|\ 205 | 206 \|/ 207 +-------------------------------------------------+ 208 | | 209 | Single Integrated E2E Network View | 210 | | 211 +-------------------------------------------------+ 212 /|\ /|\ /|\ 213 | | | 214 \|/ \|/ \|/ 215 +-------------+ +-------------+ +-------------+ 216 | | | | | | 217 | Domain A | | Domain B | | Domain C | 218 | Control | | Control | | Control | 219 +-------------+ +-------------+ +-------------+ 221 Figure 2. Information Flow Requirements for Enabling On-demand 222 Network Connectivity Service in Multi-vendor Domain Networks 224 There are a number of key requirements from Figure 2. 226 - A single integrated end-to-end network view is necessary to be 227 able to compute paths and provision the end-to-end paths that 228 traverse multiple vendor domains. 230 - The entity responsible to collect domain-level data and create an 231 integrated end-to-end view should support push/pull model with 232 respect to all its interfaces. 234 - The same entity should coordinate a signaling flow for an end-to- 235 end connections to each domain involved. (This entity to domain 236 control is analogous to an NMS to EMS relationship) 238 - The entity responsible to create abstract global view should 239 support push/pull model with respect to all its interfaces. (Note 240 that the two entities (an entity to create an integrated end-to- 241 end view and an entity to create an abstracted global view) can be 242 assumed by the same entity, which is an implementation issue. 244 - There is a need for a common API between each domain control to 245 the entity that is responsible for creating a single integrated 246 end-to-end network view. At the minimum, the following items are 247 required on the API: 249 o Programmability of the API. 251 o The multiple levels/granularities of the abstraction of 252 network resource (which is subject to policy and service 253 need). 255 o The abstraction of network resource should include customer 256 end points and inter-domain gateway nodes/links. 258 o Any physical network constraints (such as SRLG, link 259 distance, etc.) should be reflected in abstraction. 261 o Domain preference and local policy (such as preferred peering 262 point(s), preferred route, etc.) 264 o Domain network capability (e.g., support of push/pull model). 266 - The entity responsible for abstraction of a global view into a 267 customer view should provide a programmable API to allow the 268 flexibility. 270 o Abstraction of a global view into a customer view should be 271 provided to allow customer to dynamically request network on- 272 demand services including connectivity services. 274 o What level of details customer should be allowed to view 275 network is subject to negotiation between the customer and 276 the operator. 278 4. References 280 [ACTN-Frame] D. Ceccarelli, L. Fang, Y. Lee and D. Lopez, "Framework 281 for Abstraction and Control of Transport Networks," draft- 282 ceccarelli-actn-framework, work in progress. 284 [ACTN-PS] Y. Lee, D. King, M. Boucadair, R. Jing, and L. Murillo, 285 "Problem Statement for the Abstraction and Control of 286 Transport Networks," draft-leeking-actn-problem-statement, 287 work in progress. 289 5. Contributors 291 Authors' Addresses 293 Kwang-koog Lee 295 KT 296 Email: kwangkoog.lee@kt.com 298 Intellectual Property Statement 300 The IETF Trust takes no position regarding the validity or scope of 301 any Intellectual Property Rights or other rights that might be 302 claimed to pertain to the implementation or use of the technology 303 described in any IETF Document or the extent to which any license 304 under such rights might or might not be available; nor does it 305 represent that it has made any independent effort to identify any 306 such rights. 308 Copies of Intellectual Property disclosures made to the IETF 309 Secretariat and any assurances of licenses to be made available, or 310 the result of an attempt made to obtain a general license or 311 permission for the use of such proprietary rights by implementers or 312 users of this specification can be obtained from the IETF on-line 313 IPR repository at http://www.ietf.org/ipr 315 The IETF invites any interested party to bring to its attention any 316 copyrights, patents or patent applications, or other proprietary 317 rights that may cover technology that may be required to implement 318 any standard or specification contained in an IETF Document. Please 319 address the information to the IETF at ietf-ipr@ietf.org. 321 Disclaimer of Validity 323 All IETF Documents and the information contained therein are 324 provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION 325 HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 326 THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 327 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 328 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 329 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 330 FOR A PARTICULAR PURPOSE. 332 Acknowledgment 334 Funding for the RFC Editor function is currently provided by the 335 Internet Society.