Network Working Group Kwang-koog Lee Internet Draft Hosong Lee Intended status: Informational KT Expires December 2014 June 24, 2014 ACTN Use-case for On-demand E2E Connectivity Services in Multiple Vendor Domain Transport Networks draft-klee-actn-connectivity-multi-vendor-domains-01.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 24, 2014. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. K. Lee & H. Lee Expires December 24, 2014 [Page 1] Internet-Draft ACTN Multiple Vendor Domains June 2014 Abstract This document provides a use-case that addresses the need for facilitating the application of virtual network abstractions and the control and management of on-demand end-to-end provisioning of connections that traverse multiple vendor domain transport networks. These abstractions shall help create a virtualized environment supporting operators in viewing and controlling different vendor domains, especially for on-demand network connectivity service for a single operator. Table of Contents 1. Introduction..................................................2 2. On-demand End-to-end Connectivity in Multi-vendor Domain Transport Networks................................................3 3. Requirements...................................................4 4. References.....................................................7 5. Contributors...................................................7 Intellectual Property Statement...................................8 Disclaimer of Validity............................................8 1. Introduction Network operators build and operate their network using multiple domains in different dimensions. Domains may be defined by a collection of links and nodes (each of a different technology), administrative zones under the concern of a particular business entity, or vendor-specific "islands" where specific control mechanisms have to be applied. Establishing end-to-end connections spanning several of these domains is a perpetual problem for operators, which need to address both interoperability and operational concerns at the control and data planes. The introduction of new services, often requiring connections that traverse multiple domains, needs significant planning, and several manual operations to interface multiple vendor-specific domains in which specific control/management mechanisms of the vendor equipment have to be applied (e.g., EMS/NMS, OSS/BSS, control plane, SDN controller, etc.). Undoubtedly, establishing an on-demand end-to-end connection which requires provisioning based on dynamic resource information is more difficult in the current network context. This document provides a use-case that addresses the need for creating a virtualized environment supporting operators in viewing and controlling different vendor domains, especially for on-demand K. Lee & H. Lee Expires December 24, 2014 [Page 2] Internet-Draft ACTN Multiple Vendor Domains June 2014 network connectivity service for a single operator. This will accelerate rapid service deployment of new services, including more dynamic and elastic services, and improve overall network operations and scaling of existing services. This use-case is a part of the overarching work, called Abstraction and Control of Transport Networks (ACTN). Related documents are the ACTN-framework [ACTN-Frame] and the problem statement [ACTN-PS]. 2. On-demand End-to-end Connectivity in Multi-vendor Domain Transport Networks This section provides an architecture example to illustrate the context of the current challenges and issues operators face in delivering on-demand end-to-end connectivity services in operators' multi-vendor domain transport networks. | | / End-to-End Connection \ | |/-----------------------------------------------------------\| |\-----------------------------------------------------------/| | \ / | | | | +----------------+ | | | | | | | Converged | | | | Packet-Optical| | | +-------------+ | Core Domain | +-------------+ | | | |--| (Vendor A) |--| | | +----+ | Access | +----------------+ | Access | +----+ | CE1|--| Domain 1 | | | | Domain 3 |--| CE2| +----+ | (Vendor B) |----- -----| (Vendor C) | +----+ +-------------+ +-------------+ Figure 1. Multi-vendor Domains As an illustrative example, consider a multi-domain transport network consisting of three domains: one core converged packet- optical domain (Vendor A) and two access domains (Vendors B and C). Each access domain is managed by its domain control/management mechanism which is often a proprietary vendor-specific scheme. The core domain is also managed by Vendor A's proprietary control/management mechanism (e.g., EMS/NMS, OSS/BSS, Control Plane, SDN Controller, or any combination of these entities, etc.) that may not interoperate with access domain control/management mechanisms or at best partially interoperate if Vendor A is same as Vendor B or Vendor C. K. Lee & H. Lee Expires December 24, 2014 [Page 3] Internet-Draft ACTN Multiple Vendor Domains June 2014 Due to these domain boundaries, facilitating on-demand end-to-end connections (e.g., Ethernet Virtual Connections, etc.) that traverse multi-domains is not readily achieved. These domain controls are optimized for its local operation and in most cases not suited for controlling the end-to-end connectivity services. For instance, the discovery of the edge nodes that belong to other domains is hard to achieve partly because of the lack of the common API and its information model and control mechanisms thereof to disseminate the relevant information. Moreover, the path computation for any on-demand end-to-end connection would need abstraction of dynamic network resources and ways to find an optimal path that meets the connection's service requirements. This would require knowledge of both the domain level dynamic network resource information and the inter-domain connectivity information including domain gateway/peering points and the local domain policy. From an on-demand connection provisioning perspective, in order to facilitate a fast and reliable end-to-end signaling, each domain operation and management elements should ideally speak the same control protocols to its neighboring domains. However, this is not possible for the current network context unless a folk-lift green field technology deployment with a single vendor solution would be done. Although each domain applies the same protocol for the data plane, an end-to-end connectivity traversing multiple domains might not be provided due to a management and control mechanism focusing only on its own domain. From a network connectivity management perspective, it would require a mechanism to disseminate any connectivity issues from the local domain to the other domains whenever the local domain cannot resolve a connectivity issues. This is hard to achieve due to the lack of the common API and its agreed-upon information model and control mechanisms thereof to disseminate the relevant information. From an operation's perspective, the current network environments are not conducive to offering on-demand end-to-end connectivity services in multi-vendor domain transport networks. For instance, when the performance monitoring inquiry is requested, operators manually monitor each domain and aggregate the performance results. However, it may not be precise because of the different measurement timing employed by each domain. 3. Requirements In the previous section, we discussed the current challenges and issues that prevent operators from offering on-demand end-to-end connectivity services in multi-vendor domain transport networks. K. Lee & H. Lee Expires December 24, 2014 [Page 4] Internet-Draft ACTN Multiple Vendor Domains June 2014 This section provides a high-level requirement for enabling on- demand end-to-end connectivity services in multi-vendor domain transport networks in a single operator environment. Figure 2 shows information flow requirements of the aforementioned context. +-------------------------------------------------+ | | | Customer On-demand Network Service | | | +-------------------------------------------------+ /|\ | \|/ +-------------------------------------------------+ | | | Abstracted Global View | | | +-------------------------------------------------+ /|\ | \|/ +-------------------------------------------------+ | | | Single Integrated E2E Network View | | | +-------------------------------------------------+ /|\ /|\ /|\ | | | \|/ \|/ \|/ +-------------+ +-------------+ +-------------+ | | | | | | | Domain A | | Domain B | | Domain C | | Control | | Control | | Control | +-------------+ +-------------+ +-------------+ Figure 2. Information Flow Requirements for Enabling On-demand Network Connectivity Service in Multi-vendor Domain Networks There are a number of key requirements from Figure 2. - A single integrated end-to-end network view is necessary to be able to compute paths and provision the end-to-end paths that traverse multiple vendor domains. - In order to create a single integrated end-to-end network view, discovery of inter-connection data between domains including the K. Lee & H. Lee Expires December 24, 2014 [Page 5] Internet-Draft ACTN Multiple Vendor Domains June 2014 domain border nodes/links is necessary. (The entity to collect domain-level data is responsible for collecting inter-connection links/nodes) - The entity to collect domain-level data should recognize interoperability method between each domain. (There might be several interoperability mechanisms according to technology being applied.) - The entity responsible to collect domain-level data and create an integrated end-to-end view should support push/pull model with respect to all its interfaces. - The same entity should coordinate a signaling flow for end-to-end connections to each domain involved. (This entity to domain control is analogous to an NMS to EMS relationship) - The entity responsible to create abstract global view should support push/pull model with respect to all its interfaces. (Note that the two entities (an entity to create an integrated end-to- end view and an entity to create an abstracted global view) can be assumed by the same entity, which is an implementation issue. - There is a need for a common API between each domain control to the entity that is responsible for creating a single integrated end-to-end network view. At the minimum, the following items are required on the API: o Programmability of the API. o The multiple levels/granularities of the abstraction of network resource (which is subject to policy and service need). o The abstraction of network resource should include customer end points and inter-domain gateway nodes/links. o Any physical network constraints (such as SRLG, link distance, etc.) should be reflected in abstraction. o Domain preference and local policy (such as preferred peering point(s), preferred route, etc.) o Domain network capability (e.g., support of push/pull model). - The entity responsible for abstraction of a global view into a customer view should provide a programmable API to allow the flexibility. K. Lee & H. Lee Expires December 24, 2014 [Page 6] Internet-Draft ACTN Multiple Vendor Domains June 2014 o Abstraction of a global view into a customer view should be provided to allow customer to dynamically request network on- demand services including connectivity services. o What level of details customer should be allowed to view network is subject to negotiation between the customer and the operator. 4. References [ACTN-Frame] D. Ceccarelli, L. Fang, Y. Lee and D. Lopez, "Framework for Abstraction and Control of Transport Networks," draft- ceccarelli-actn-framework, work in progress. [ACTN-PS] Y. Lee, D. King, M. Boucadair, R. Jing, and L. Murillo, "Problem Statement for the Abstraction and Control of Transport Networks," draft-leeking-actn-problem-statement, work in progress. 5. Acknowledgement The authors wish to thank Young Lee for the discussions in the document. 6. Contributors Authors' Addresses Kwang-koog Lee KT Email: kwangkoog.lee@kt.com Hosong Lee KT Email: hosong.lee@kt.com K. Lee & H. Lee Expires December 24, 2014 [Page 7] Internet-Draft ACTN Multiple Vendor Domains June 2014 Intellectual Property Statement The IETF Trust takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in any IETF Document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Copies of Intellectual Property disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement any standard or specification contained in an IETF Document. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity All IETF Documents and the information contained therein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. K. Lee & H. Lee Expires December 24, 2014 [Page 8]