Network-as-a-Service:

Transcription

1 WHITE PAPER Network-as-a-Service: SDN-enabled L1 Virtual Networking Introduction Cable operators have expanded their enterprise service offerings to include multipoint managed networks for enterprises requiring interconnect networks, which may be metro, regional, or national in scope. In some cases, these enterprises not only want more visibility into their network infrastructure and service performance, but also want the ability to provision and control their services and bandwidth in real time. Due to the complexity of sharing services among several enterprises (and even residential services) on a single underlying network infrastructure, allowing enterprise customers this degree of control has been difficult to accomplish due to security, reliability, and management issues.

2 Software defined networking (SDN), which provides a global network view and the ability to manage services across multiple network layers and vendors, provides operators for the first time the ability to establish multiple Layer 1 (L1) virtual networks, one for each enterprise or service domain, and offer virtual Network-as-a-Service (NaaS) configurations as part of their commercial service offering. This will allow enterprise customers to directly control, manage, monitor, and provision their services as if their network were fully independent and not part of a larger shared network, but will prevent each enterprise from seeing or interfering with other virtual L1 virtual private networks (VPNs) on the network. This provides a high degree of flexibility and security while conserving network resources and lowering overall network costs. This paper provides an overview of an SDN-controlled hierarchical network architecture capable of supporting L1 virtual network services and explore how such a network can support a broad range of services and applications. This architecture includes an SDN controller, L1 VPN application and customer management interface running above the SDN controller, an Open Transport Switch (OTS) that mediates between the SDN controller and the transport layer, and an optical transport layer allowing bandwidth and services to be provisioned in real time via the SDN controller. Today s Layer 1 Enterprise Services To understand how NaaS, which provides enterprise-controlled dynamic service management and creation, can be implemented as a new enterprise service, it is first necessary to understand how traditional enterprise services are delivered and the underlying switching and transport architectures used to deliver these services. These provide the foundation upon which a NaaS enterprise architecture can be built. 1. Leased Layer 1 Transport Services In traditional cable commercial services, an enterprise requiring bandwidth between two or more points (whether on a metro, regional, or national level), frequently leases point-to-point (P-P) optical transport capacity between its sites to build an interconnected enterprise network with a cable operator providing the intermediate P-P transport between enterprise sites. The actual interconnects provided may consist of leased circuits (e.g., Gigabit Ethernet, or GbE, depending on the application) or wavelength services with the required client protocol interfaces (i.e. an entire optical wavelength is leased, usually 10G or 100G). In these cases, if the enterprise requires multipoint to multipoint (MP-MP) connectivity, this is achieved with enterprise-owned switches/ routers located on its premises, and the cable operator simply provides P-P optical transport to stitch the enterprise network together. Page 2

3 Figure 1, below, shows two Layer 1 enterprise networks connected by a cable operator network. The first network (shown at the top of the figure) consists of leased GbE circuits connecting multiple sites in a ring configuration. MP-MP connectivity is provided by enterprise-owned switching platforms at each enterprise site. The ring architecture provides resiliency in case of a fiber cut or other failure. The second network (shown at the bottom of the figure) consists of a P-P 10G wavelength service between two enterprise sites. In this example, the cable operator provides optical interconnections between the enterprise sites and transports these internally on the operator network using 10G transport waves. For leased circuit enterprise services, the leased circuit capacity is usually smaller than the actual underlying capacity of the optical transport wave. For example, an enterprise may need a Gbe circuit between two points, but the actual circuit will likely be carried on a 10G or 100G transport wave in the cable operator s network. For optimum wavelength utilization, this requires digital multiplexing capability in the optical transport platform to combine multiple services onto a single wavelength for transport. This is best accomplished using Ooptical transport networks (OTN), the ITU-T standard for multi-service, multi-rate multiplexing and transport. OTN flexibly allows multiple services with different bit rates and protocols to be multiplexed onto a single transport wave and thus greatly increases wavelength utilization. In the case of optical transport platforms that also integrate OTN switching at every node, additional efficiencies can be achieved since OTN enables sub-lambda grooming (the ability to digitally add/drop services to/from a wave at any node in the network or to re-multiplex services) and inter-lambda switching (the ability to switch services between wavelengths at any node in Enterprise Managed Operator Managed Enterprise Managed Leased P-P Circuits (GbE) Hub A Optical Transport Network Hub B Leased P-P Circuits MP-MP Enterprise Network Hub C Hub D Leased P-P 10G Wavelength Wavelengths (10G) Demarcation Demarcation Figure 1: Leased P-P Circuits and Wavelength Services Page 3

4 OTN ROADM OTN OTN OTN ROADM ROADM ROADM Optical Switching Only (Lambdas) End-to-end optical express No service grooming Subject to wavelength blocking OTN ROADM OTN OTN OTN ROADM ROADM ROADM Digital Switching Only (ODUn) Nodal sub-lambda grooming Nodal inter-lambda switching Nodal OEO and digital switching OTN ROADM OTN OTN OTN ROADM ROADM ROADM Multi-Layer Switching (L0 and L1) OEO for digital OTN grooming Express fully utilized lambdas Maximum flexibility/efficient Figure 2: Optical, Digital and Multi-Layer Switching the network). The former greatly increases wavelength utilization and flexibility; the latter virtually eliminates wavelength blocking and thus minimizes stranded bandwidth. For wavelength enterprise services, no multiplexing is required since the entire capacity of the wave is utilized to transport the leased enterprise service. In this case, the wave may be efficiently switched entirely in the dense wave division multiplexing (DWDM) optical domain using a reconfigurable optical add/drop multiplexer (ROADM). However, OTN digital switching can also be used in conjunction with optical layer switching for enhanced flexibility, as is shown in Figure 2, above. Some next-generation optical networks support a multi-layer switching architecture in which the network nodes integrate both digital OTN switching at L1 and reconfigurable optical switching at Layer 0 (L0, the DWDM layer). This architecture combines the benefits of an OTN switching architecture (digital multiplexing, grooming, and switching of services at every node) and an optical switching architecture (ROADM switching for adding, dropping, or expressing entire wavelengths at every node). This hybrid switching architecture supports flexible multiplexing and switching at both the circuit and wavelength levels. The multi-layer switching architecture provides the highest degree of flexibility as the network evolves and service demands change, and as discussed later, provides a strong foundation for supporting NaaS services due to its flexibility. Page 4

5 Integrated Digital/Optical Node Local Client Add/Drop OTN Digital Switching Digital Bandwidth Management Multi-service add/drop multiplexing optimizes circuit and wavelength efficiency Sub-lambda nodal grooming efficiently packs waves Inter-lambda nodal switching reduces wavelength blocking West Fiber East Fiber Optical Bandwidth Management Add/drop whole wavelengths for local OTN processing Optically express whole wavelengths for pass-through Ideal for wavelength services ROADM Optical Switching Figure 3: Multi-Layer Switching Architecture Figure 3, above, shows a high level view of an integrated multi-layer switching architecture. At each add-drop location and at junction nodes, this architecture provides intra- and interwavelength grooming of sub-wavelength services using digital OTN switching, multiplexing these services onto the fewest possible line-side wavelengths and maximizing their bandwidth utilization. The integrated OTN switch also handles all add/drop and bandwidth management for client services. This architecture also incorporates integrated optical layer switching using a ROADM, which is responsible for expressing waves through the node if these waves have no local traffic, and for routing waves with local traffic into the OTN switch for add/drop multiplexing or grooming. OTN is ideal for digitally switching and multiplexing individual sub-lambda circuits, while a ROADM is ideal for optically switching wavelength services or waves that have been fully packed using OTN multiplexing. For both leased circuits and wavelength services, the cable operator provides switching (L0 optical and/or L1 OTN) to transparently route the enterprise services end-to-end. These types of L1 services are sometimes preferred by enterprise customers for their security since the enterprise traffic is not mixed with other services, but is transported on an independent circuit or wave. Additionally, these services typically provide a high level of quality of service (QoS) with low latency and minimal jitter because they have no intermediate L2/L3 switching/routing or statistical multiplexing. Typical services provided here include Fibre Channel and Carrier Ethernet Private Line (EPL, a point-to-point Carrier Ethernet service, circuit or wavelength-based). 2. Leased Service Operational Considerations One of the challenges both cable operators and enterprises face is addressing changing service requirements as an enterprise s connectivity requirements evolve. Enterprises often have changing bandwidth requirements and a need to turn up new services or connect new Page 5

6 sites. Unfortunately, the service model described above is largely implemented with static configurations and is manually configured, and making changes is usually a complex, timeconsuming process for both the cable operator and the enterprise. A service change or addition typically involves the following steps: The enterprise calls its cable operator and requests a new circuit or wavelength, or other service change The operator assesses the network end-to-end for the bandwidth and hardware inventory needed to support the new circuit or changes A quote is generated for installation and service fees, and an agreement is signed between the operator and the enterprise The necessary hardware for the circuit is ordered (sometimes with significant vendor lead times for delivery) and installed The circuit is provisioned, tested, and turned up, then turned over to the enterprise Any subsequent changes require a repeat of the process The above process can easily take six to twelve weeks, and this requires the enterprise to predict new service requirements well in advance of when they are actually needed. Given the number of manual touchpoints for both the enterprise and operator, the process is also resource-intensive and expensive. What is needed is an intelligent network that flexibly allows the enterprise to rapidly turn up its own circuits through a self-service portal, automating much of the process and changing static configurations into dynamic services. This approach will clearly reduce costs for both the operator and the enterprise while accelerating service changes and new service turn-up. Network-as-a-Service 1. L1 Optical Transport VPN NaaS has the promise of fulfilling the needs identified above by essentially giving each enterprise on the operator s network its own virtual network, distinct and independent of other enterprises services and of the operator s own production network. Operators and enterprises are used to thinking of circuits as services, but NaaS takes the concept of service one step further by giving the enterprise its own L1 virtual network, where the enterprise has complete end-to-end visibility of its services and the ability to monitor service level agreements (SLAs), turn up new services, change bandwidth between sites, re-route services between sites, and rapidly adapt to changing service requirements or network conditions. In essence, the service the enterprise now receives from the operator is a network, not just circuits. In an L1 virtual optical transport network, each enterprise only sees its components of the network, its services, and the resources that have been allocated to it by the cable operator. However, the cable operator still has a global view of the network and the ability to manage and monitor all elements. In this manner, each enterprise can only see and impact its own services, and the overall integrity of each virtual network is maintained, as is the integrity of the overall cable operator network. Page 6

7 Each L1 VPN is maintained in software so that the integrity of VPN partitioning, security, and resources is maintained. This is accomplished by virtualizing network bandwidth and resources so that these may be assigned individually among the VPNs on the operator s network. This virtualization of physical transport network resources allows resources to be pooled and then allocated, released, and re-allocated on-demand via software, which improves resource utilization while providing enhanced network flexibility. Figure 4, below, shows a high level view of the operator s L1 optical transport network on the left. In this example, the operator s network consists of six nodes interconnected in a mesh pattern. On the right, two virtual networks are shown that are derived from and operate over the operator s network. Each of these virtual networks is managed by a different enterprise, and each enterprise only has visibility into and control over its own VPN. 2. NaaS Multi-layer Architecture In implementing an effective NaaS architecture, it is useful to establish objectives at the outset. The architecture should at a minimum: Support virtualization of transport network resources and a simple abstraction to higher layer applications for provisioning bandwidth services to allow creation and control of multiple independent virtual networks Enable full programmability of the optical transport layer at the circuit and wavelength level and provide the ability to dynamically switch and groom transport bandwidth services on demand Allow simplification, orchestration, and automation of the provisioning operations within a multi-vendor, multi-layer, and multi-domain environment Virtual Network 1 Enterprise A Cable Operator s L1 Optical Transport Network Virtual Network 2 Enterprise B Figure 4: L1 Optical Transport Network with Enterprise Virtual Networks Page 7

8 Enable greater overall network resource utilization across multiple network layers Provide simplified enterprise access and provisioning of its L1 VPN via an enterprise VPN portal Accelerate the delivery of new services and rapidly deliver bandwidth on-demand to support multiple applications, wherever and whenever needed SDN is ideally suited for meeting these objectives. While multiple layers in the network must participate in and contribute to achieving these objectives, SDN provides an umbrella architectural framework for implementing these objectives and building a multi-vendor, softwaredriven network optimized across all layers and domains. SDN was initially targeted at packet and data center applications at Layers 2 and 3, not wide area networking (WAN) applications, where Layer 1 optical transport networks are inherently circuit-based, usually employing SONET/SDH or OTN. These technologies were not anticipated or supported in earlier standards efforts for SDN, which have been largely driven by the Open Networking Foundation (ONF) and its OpenFlow-based SDN. Recognizing this, ONF began standardization efforts for Transport SDN to extend the OpenFlow model to include the transport layer, thus allowing global optimization across Layers 0-3. The ONF SDN architectural model is shown below in Figure 5. The model consists of three layers. The application layer consists of end-user business applications that utilize the underlying SDN and network resources. The control layer provides the logically centralized SDN functionality that monitors and controls the underlying network data plane through an OpenFlow interface. The infrastructure layer consists of the network elements (NEs) and other devices that provide L0-L3 routing and switching through the network. Application Layer Control Layer Network Services Business Applications API API API Network Services Infrastructure Layer Figure 5: Open Networking Foundation SDN Architecture Page 8

9 This model is characterized by three core attributes: Centralized intelligence: An SDN controller provides a global view and control of all elements and layers of the network. Networks not built upon SDN are largely controlled and managed layer by layer or element by element, so multi-layer and multi-vendor global optimization, if it exists at all, must be manually accomplished. Programmability: SDN assumes a software-driven network where all layers are programmable and where network configuration is automated. Abstraction: In this model, the business applications are abstracted from the underlying network technologies and complexities, as is the SDN control layer. This allows new business applications to be rapidly developed at the application layer, rather than at the network layer, which is typical of networks today. Having defined a framework for an SDN-enabled network, we will now explore how this framework can be used to implement a NaaS architecture. The L1 VPN NaaS architecture described below consists of four key components (starting from the lowest layer and working upwards): An L1 optical transport network which delivers enterprise circuits and wavelength services An Open Transport Switch which serves as a software-based mediator between the optical transport network and the SDN controller A standards-based SDN controller that provides multi-layer, multi-vendor coordination of network resources and a global view of the network A software-driven enterprise portal that allows enterprises to access their L1 VPN and manage and monitor services Figure 6, below, shows the hierarchical NaaS architecture based upon the four components listed above. As can be seen, this architecture fits within the ONF SDN model with the OTS and optical network comprising the infrastructure layer. Network Applications / NFV SDN Controller IT/Cloud Orchestration OTS plugins Request/Response https/rest/json Notifications Pub/Sub Websockets/JSON/STOMP OTS API Functions Security Basic, Oauth https/rest/json Adaptation Function Inventory, Provisioning, Monitoring Inventory SubNetwork, NE, Port Provisioning SNC NE Communication Layer (ssh,xml) Notifications Virtualization, Overlay Future Port Monitoring State, Fault, Config Enterprise A Secure communications Enterprise B GMPLS/SSON Virtual Network 1 Optical Transport Network with Converged L0/L1 Enterprise A Figure 6: NaaS Hierarchical Architecture Page 9

10 An overview of the L1 optical transport network and its capabilities was previously provided above. This optical network provides the foundation for the overall NaaS service by enabling circuits and/or wavelengths to be turned up, reconfigured, re-routed, or turned down. The three key requirements for this network are 1) the ability to switch circuits and waves end-to-end in the network using OTN digital switching and/or optical layer ROADM switching, 2) the ability to automate this switching process to eliminate manual operations and truck rolls, and 3) the ability to interface to a higher network management layer to provide a northbound network view as well as a provisioning capability in the transport layer. Most optical network systems provide a northbound interface to a higher level element management system (EMS). This interface may support a number of protocols and capabilities and is capable of not only pulling network information from the NEs and network, but of provisioning these elements as well. While this interface provides a powerful means of managing the network, it is often specific to a vendor and the NE type, and it is generally not a suitable management interface for the SDN controller, which requires a higher degree of element abstraction and which uses industry-standard SDN southbound interfaces that are not typically found in optical network management interfaces, at least not today. To bridge the gap between the SDN controller and the managed network, a software-based, virtualized open transport switch, is deployed on a standard server, where it provides a high level of abstraction and virtualization of the transport network for the SDN controller. This allows the SDN controller to communicate with and provision the optical transport network without the intermediate use of the element management system for that network or without detailed provisioning knowledge of the underlying optical network elements. In most cases, operators will operate the optical network in a hybrid control mode that allows SDN control of the enterprise virtual networks by enterprise customers, and traditional EMS control by the operator of its production network. The OTS provides standard northbound SDN controller interfaces, including OpenFlow for data plane provisioning, Representational State Transfer (REST), and JavaScript Object Notation (JSON ), an open standard format that uses human-readable text to transmit data objects consisting of attribute value pairs). REST/JSON are used for configuration, management, and administrative functions. Beneath the SDN controller interface, OTS provides a set of Application Programming Interfaces (APIs) that provide essential functions for integrating the optical transport layer management with the SDN controller. The API functions provided here include the following: Optical layer status notification Port monitoring (including state, fault, and current configuration) End-to-end circuit provisioning Inventory discovery and management (including NEs, ports, and circuits) Topology discovery and management OTS status, configuration and management Secure communication interfaces to both the SDN controller and transport network Page 10

11 Network as a Service (NaaS) Billing Agent Topology Module Policy Agent Controller L1 PCE Provisioning Manager OAM Handler SDN Control Layer OTS Lo/L1 Optical Transport Network Open Transport Switch (OTS) Bandwidth Virtualization Digital/Optical Switching DWDM Intelligent Transport Abstraction Figure 7: NaaS Architecture with SDN Controller Functions The SDN controller in this architecture provides multi-layer optimization and network orchestration for the NaaS applications running above it at the applications layer, but provides other key services for the NaaS application as well. Figure 7, above, shows the overall NaaS architecture, but with additional details around the SDN controller modules, including topology management, provisioning management, and path computation element (PCE) In addition to its lower layer network management functions, the controller must be capable of providing virtualization for the enterprise VPNs, which requires a policy agent with operator-defined attributes for each enterprise VPN along with information for each VPN s current configuration and resources. This ensures integrity across the network, including for each individual VPN. Since this is an enterprise-controlled application, a billing agent/interface is also essential to capture changes in service configurations to ensure proper billing. The last component of the architecture is the NaaS application layer and enterprise portal. This component defines the overall NaaS application capabilities and service attributes by integrating the SDN and network infrastructure layers, along with back office software systems (such as billing and policy management) and an enterprise portal providing a user interface to each enterprise having a self-managed NaaS VPN on the network. At the application layer, services are completely defined in software, with the SDN control layer providing abstraction and mediation with the underlying network actually delivering the service. 3. NaaS Operational Flow With an enterprise-managed NaaS service, the operational flow to make service modifications is greatly streamlined, which provides operational savings for both the cable operator and the Page 11

12 enterprise. Moreover, because there are fewer steps in the process and most processes are now automated, service changes can be accomplished much more rapidly, which allows an enterprise to respond more quickly and effectively to changing network conditions or service requirements. A service change or addition now will typically involve the following steps: The enterprise remotely logs into the cable operator customer portal and requests a new circuit or wavelength, or a different service change The NaaS API along with the other NaaS architecture components assesses the network endto-end in real time for the bandwidth and hardware inventory needed to support the service change The portal API provides a real-time quote to the enterprise to implement the change. If the quote is acceptable, the enterprise accepts it, and the circuit changes are provisioned, and then turned over to the enterprise Of course, the above process assumes the necessary underlying hardware is in place to implement the requested changes. If it is not, it is also possible for the NaaS API to be programmed to submit the necessary work orders for getting hardware ordered and installed, and to make any necessary billing adjustments. It is also possible for both the operator and the enterprise to agree upon a policy and procedure to ensure a pool of hardware is available prior to known demand to allow rapid response. 4. SDN Architecture and Application Extensions It should be noted that the architecture described here, without any changes other than to the application layer and SDN extensions into the L2/L3 layers, is capable of supporting a much broader range of applications and services simultaneously on the SDN control layer and existing network infrastructure. For example, this architecture may be integrated into the operator s L2/ L3 switching/routing layers, providing true L0-L3 multi-layer control and optimization. This would support extended applications such as bandwidth on demand, bandwidth allocation by time of day, bandwidth-driven router bypass or port turn-up/turn-down, integrated Carrier Ethernet service management across all network layers, L0-L3 enterprise VPNs supporting the full range of Carrier Ethernet services, and many others. Conclusion SDN is still an emerging technology with ongoing standards development, but there are nevertheless many live network deployments of SDN today delivering real services and generating real revenue or delivering real network efficiencies and cost savings. SDN promises to revolutionize the way networks are operated and managed, as well as to revolutionize the way new services are developed and delivered. On the infrastructure side, SDN offers the promise of accelerating network operational cycles while increasing network resource utilization, and doing so dynamically and automatically. On the service side, SDN offers the promise of much more rapid service definition and activation, including the creation of entirely new services and revenue streams. SDN provides a software defined, programmable, and automated network and service architecture that promises to eliminate the silos that exist today between vendors and network layers, allowing unprecedented optimization and service acceleration. NaaS is just one example of an SDN service. NaaS allows the creation of enterprise L1 VPNs, which in turn opens up the possibility for enterprise-managed VPNs and VPN services. NaaS Page 12

13 allows an enterprise to directly modify and control in real time all components of its VPN, including bandwidth, service levels, connection points, and other parameters. The benefits to the cable operator and enterprise include simplified service changes, process automation, accelerated service changes, greater network efficiency, and the ability to respond in real time to dynamic service or network conditions. Abbreviations API Application Programming Interface BW Bandwidth E-LAN Ethernet LAN, A Carrier Multipoint to Multipoint service E-Line Ethernet Line, A Carrier Ethernet point-to-point service EMS Element Management System EPL Ethernet Private Line EP-LAN Ethernet Private LAN EVC Ethernet Virtual Circuit EVPL Ethernet Virtual Private Line EVP-LAN Ethernet Virtual Private LAN GbE Gigabit Ethernet JSON JavaScript Object Notation L0 Layer 0 (the DWDM Layer) L1 Layer 1 LAN Local Area Network MEF Metro Ethernet Forum MP-MP Multipoint to Multipoint NaaS Network as a Service NE Network Element ONF Open Networking Foundation OTN Optical Transport Network, ITU-T standard for transport and multiplexing OTS Optical Transport System PCE Path Computation Element P-P Point-to-Point P-OTS Packet Optical Transport System QoS Quality of Service REST Representational State Transfer ROADM Reconfigurable Optical Add/Drop Multiplexer SDN Software Defined Networking SLA Service Level Agreement SDH Synchronous Digital Hierarchy SONET Synchronous Optical Network VLAN Virtual LAN VPN Virtual Private Network WAN Wide Area Networking Page 13

14 Bibliography & References Liou, Chris. Optimizing Multi-Layer Networks with Transport SDN. SCTE Cable-Tec Expo Technical Proceedings. October Hart, Gaylord, and Anuj Malik. The Evolution of Next-Gen Optical Networks: Terabit Super-Channels and Flexible Grid ROADM Architectures. SCTE Cable-Tec Expo Technical Proceedings. September ITU-T Recommendation G.709. Interfaces for the Optical Transport Network (OTN). Walker, Timothy. Optical Transport Network (OTN) Tutorial. OTNtutorial.pdf Open Networking Foundation. OpenFlow-enabled Transport SDN. May 27, images/stories/downloads/sdn-resources/solution-briefs/sb-of-enabled-transport-sdn.pdf Metro Ethernet Forum. Carrier Ethernet Services, MEF Reference Presentation. November Assets/Presentations/Carrier-Ethernet-Services-Overview-Reference-Presentation-R pptx This paper was originally published and presented at the 2015 SCTE Cable-Tec Expo in New Orleans, LA, October 13-16, Page 14

15 Infinera Corporation 140 Caspian Court Sunnyvale, CA USA Telephone: Fax: Have a question about Infinera s products or services? Please contact us via the addresses below. Americas: Asia & Pacific Rim: Europe, Middle East, and Africa: General sales-am@infinera.com sales-apac@infinera.com sales-emea@infinera.com info@infinera.com Specifications subject to change without notice. Document Number: WP-NAAS Copyright 2016 Infinera Corporation. All rights reserved. Infinera and logos that contain Infinera are trademarks or registered trademarks of Infinera Corporation in the United States and other Countries.