Network Working Group Kwang-koog Lee Internet Draft Hosong Lee Intended status: Informational KT Expires January 2018 Ricard Vilalta CTTC Victor Lopez Telefonica July 31, 2017 ACTN use-case for E2E network services in multiple vendor domain transport networks draft-klee-teas-actn-connectivity-multi-domain-03.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 January 31, 2018. 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 K. Lee & H. Lee Expires January 31, 2018 [Page 1] Internet-Draft ACTN Multiple Vendor Domains July 2017 carefully, as they describe your rights and restrictions with respect to this document. 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 end-to-end network services 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 end-to-end network connectivity service for a single operator. Table of Contents 1. Introduction...................................................2 2. End-to-End Network Services in Multi-vendor Domain Transport Networks..........................................................3 2.1. Example A - Leased Line Services..........................5 2.2. Example B - Data Center Interconnect (DCI)................6 3. Requirements...................................................7 4. References....................................................10 5. Acknowledgement...............................................10 6. Contributors..................................................11 1. Introduction Network operators build and operate their network using multiple domains (i.e., core and access networks) 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. Due to the technology of each vendor, the optical components cannot be interconnected. Even, the interconnection of components supporting the same technology is not easy since their control and management system is tightly coupled with their own devices. Therefore each optical domain becomes an isolated island in terms of the control and management of end-to-end services traversing multiple domains. The network operators use vendor-specific NMS implementations along with an operator-tailored umbrella provisioning system, which may include a technology specific Operations Support System (OSS). Thanks to the evolution of vendor specific SDN controllers, the K. Lee & H. Lee Expires January 31, 2018 [Page 2] Internet-Draft ACTN Multiple Vendor Domains July 2017 network operators require a network entity, which abstracts the details of the optical layer while enabling control and management of the end-to-end services traversing multiple domains. The establishment of 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 end-to-end network services for a single operator. Surely, the use-case could be also available for the interconnection of end-to-end services for multiple operators. This will accelerate rapid 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 Requirements [ACTN-Req], ACTN-framework [ACTN-Frame] and the problem statement [ACTN-PS]. 2. End-to-End Network Services 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 end-to-end network services in operators' multi-vendor domain transport networks. K. Lee & H. Lee Expires January 31, 2018 [Page 3] Internet-Draft ACTN Multiple Vendor Domains July 2017 | | / 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. Due to these domain boundaries, facilitating 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 K. Lee & H. Lee Expires January 31, 2018 [Page 4] Internet-Draft ACTN Multiple Vendor Domains July 2017 connectivity information including domain gateway/peering points and the local domain policy. From an end-to-end 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 vendor domains might not be provided due to a management and control mechanism focusing only on its own domain. In addition, the end-to-end connection provisioning via multiple domains might not be treated by a single layer but the control and management of multi-layer should be necessary. In this case, the control plane of an upper layer first interacts with its lower layer in order to check whether the lower layer can provide network resources to meet service-level requirements such as SLA (Service Level Agreement) and user-defined policies. Then, the upper layer could proceed to provision its own layer referring to provisioning results provided from its lower layer. However, vendor-specific management systems have no awareness of adjacent layers of network resources. Even, a single vendor management system covering multi- layer avoids the interaction with control planes of the multi-layer due to the complexity of implementation. 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 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. 2.1. Example A - Leased Line Services Service providers offer to customers a leased line service connecting geographically distant two or more locations. Traditionally, leased lines have been offered using SONET/SDH networks in speed ranging from E1 to STM64 to meet specific business K. Lee & H. Lee Expires January 31, 2018 [Page 5] Internet-Draft ACTN Multiple Vendor Domains July 2017 needs. But, as demand grew on data network, service providers started to offer Ethernet-based leased line services in speed ranging from 10Mbps and 10Gbps. Especially, MPLS-TP defined by IETF is mainly used to achieve the carrier-grade characteristics (high- level availability, guaranteed bandwidth, and OAM capabilities) of SONET/SDH. However, unlike the SONET/SDH networks, there are some limitations to provide an end-to-end connectivity on top of telco infrastructure with multi-vendor domains, because the EMS/NMS system of each vendor does not communicate with each other in order to operate the multi- vendor MPLS-TP networks due to the lack of common API. Each vendor devices can support the same OAM and protection mechanisms, but end- to-end connections are only created through data planes manually configured from operators. Operators should manually give specific MPLS label values to network elements acting as LSRs/LERs considering the collision of used label values. In addition, the exchange of specific OAM and protection switching information should be achieved for appropriate end-to-end OAM and protection switching operations. Even, it is hard to operate such kinds of connections because of network elements non-visible from each vendor's EMS/NMS system. As a result, operators might have difficulties in terms of execution of on-demand OAM functions and manual protection switching commands. To achieve an end-to-end connectivity, each vendor domain creates their own MPLS-TP tunnels by their EMS/NMS systems and then, MEF- based ENNIs are used at the interconnection links. But, this solution still requires manual configurations from operators for S- VLAN handling and various ENNI parameters (connectivity information, and bandwidth profile). 2.2. Example B - Data Center Interconnect (DCI) Enterprise customer data centers are consolidating, growing and becoming more redundant and dynamic. Thereby, service providers provide a new data center interconnect (DCI) service connecting geographically separate data centers to their customers to extend their computing resources or enhance the service availability between data centers or main sites. DCI supports two possible transport scenarios over metro and regional area networks. - DWDM or CWDM: This is a Layer 1 type of DCI service using optical WDM equipment between data centers to meet the highest bandwidth and lowest latency requirements. Depending on distance and capacity requirements between data centers, provider choose a short-reach CWDM or long-reach DWDM technology. Then, customers K. Lee & H. Lee Expires January 31, 2018 [Page 6] Internet-Draft ACTN Multiple Vendor Domains July 2017 are provided a private optical network using an optical wavelength. - L2VPN: This is a Layer 2 type of DCI service using Ethernet-based L2VPN technologies for customers requiring seamless LAN extension. Two kinds of L2VPN technologies are applicable where one is carrier Ethernet transport technology and another is L2VPN solutions based on IP/MPLS or overlay network technologies such as VxLAN, NVGRE or GRE. The Carrier Ethernet technology provides predictable performance in terms of various Ethernet services (i.e., E-Line, E-Tree, E-LAN) defined by MEF (Metro Ethernet Forum). In the meantime, L2VPN based on IP technologies cover less stringent latency and bandwidth requirements. The scenarios are mapped into networking technologies that can meet the underlying requirements. From the provider perspectives, the providers should support a number of different network technologies metro and regional area network between data centers in order for offering appropriate virtual private networks depending on the customer requirements. Unlike the case of Example A in this section, some of IP-based overlay solutions only provide SDN-based interface technologies such as NetConf, RestConf, OpenFlow and SNMP without any EMS/NMS systems. Therefore, it is necessary to implement an integration system for the control and management of the L1 and L2/L3 devices. Resource discovery and control throughout the multiple layers should be achieved in provider networks to offer more rapid service agility and efficiency of the DCI service. 3. Requirements In the previous section, we discussed the current challenges and issues that prevent operators from offering end-to-end connectivity services in multi-vendor domain transport networks. This section provides a high-level requirement for enabling end-to- end connectivity services in multi-vendor domain transport networks. Figure 2 shows information flow requirements of the aforementioned context. K. Lee & H. Lee Expires January 31, 2018 [Page 7] Internet-Draft ACTN Multiple Vendor Domains July 2017 +-------------------------------------------------+ | | | Customer On-demand Network Service | | | +-------------------------------------------------+ /|\ | \|/ +-------------------------------------------------+ | | | Abstracted Global View | | | +-------------------------------------------------+ /|\ | \|/ +-------------------------------------------------+ | | | Single Integrated E2E Network View | | | +-------------------------------------------------+ /|\ /|\ /|\ | | | \|/ \|/ \|/ +-------------+ +-------------+ +-------------+ | | | | | | | Domain A | | Domain B | | Domain C | | Control(NMS)| | Control(NMS)| | Control(Dev)| +-------------+ +-------------+ +-------------+ Figure 2. Information Flow Requirements for Enabling End-to-End 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 provision the end-to-end paths that traverse multiple vendor domains. In this approach the scalability and confidentiality problems are solved, but new considerations must be taken into account: o Limited awareness, by the VNC, of the intra-domain resources availability. o Sub-optimal path selection. K. Lee & H. Lee Expires January 31, 2018 [Page 8] Internet-Draft ACTN Multiple Vendor Domains July 2017 - The path computations shall be performed in two stages: first on the abstracted end-to-end network view (happening at VNC), and on the second stage it shall be expanded by each PNC. - In order to create a single integrated end-to-end network view, discovery of inter-connection data between domains including the 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. - Hierarchical composition of integrated network views should be enabled by a common API between NorthBound Interface of the Single Integrated End-to-End view (handled by VNC) and Domain Control (handled by PNC). - 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. K. Lee & H. Lee Expires January 31, 2018 [Page 9] Internet-Draft ACTN Multiple Vendor Domains July 2017 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. Abstraction might be provided by representing each domain as a virtual node (node abstraction) or a set of virtual nodes and links (link abstraction). Node abstraction creates a network topology composed by nodes representing each network domain and the inter-domain links between the border nodes of each domain. 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. [ACTN-Req] Y. Lee, D. Dhody, S. Belotti, K. Pithewan, D. Ceccarelli, "Requirements for Abstraction and Control of Transport Networks", draft-lee-teas-actn-requirements, work in progress. 5. Acknowledgement The authors wish to thank Young Lee for the discussions in the document. K. Lee & H. Lee Expires January 31, 2018 [Page 10] Internet-Draft ACTN Multiple Vendor Domains July 2017 6. Contributors Authors' Addresses Kwang-koog Lee KT Email: kwangkoog.lee@kt.com Hosong Lee KT Email: hosong.lee@kt.com Ricard Vilalta CTTC Email: ricard.vilalta@cttc.es Victor Lopez Telefonica Email: victor.lopezalvarez@telefonica.com K. Lee & H. Lee Expires January 31, 2018 [Page 11]