Some vendors are starting to leverage a truly open architecture for optimization of unified fabrics with extensible service control applications. One of the great opportunities in software-defined networking is to amplify the efficiency of network and service operations teams by allowing them to leverage a powerful set of logically centralized and abstracted control functions for the infrastructures and services they manage. While this model is simple to articulate it takes great vision and talent to realize in the world of real, deployed solutions that deliver the result. The goal is only partially realized by the use of SDN controllers themselves. Controllers indeed do help simplify by normalizing and abstracting control plane functions for the given domain. In parallel, though, operators are driving to achieve additional optimizations, efficiencies, and innovations by leveraging what I call SDN Service Control applications that work in tandem with the centralized SDN controller code. Examples of focus for these include traffic analytics, service level monitoring and management, and custom traffic steering design for various operating goals (application performance, service availability, cost optimization, etc.). The dynamics for how these goals can be pursued vary a bit between internal data center and adjacent wide area network infrastructures. I focus on data center implementations here . The end game we’re looking at is one where the logically centralized and streamlined controls for the network being managed dynamically serve the needs of the applications and users relying on it for their services. In many data centers this will include a sizable overlay virtual network running in parallel with a high-performance physical underlay network. It will include a blend of control plane and value-adding service control apps to make it all work automatically and with maximum performance, efficiency, security, and stakeholder satisfaction (phew!). A challenge in getting to this end game is achieving these results in a streamlined, integrated manner for both underlay and overlay networks. As implementing SDN in data center environments has gotten started, we’ve largely had operationally separate deployments of underlay and overlay networks. Services such as VXLAN and virtualized router modules are operating in their own logical scopes, and a sometimes heterogeneous fabric of underlying physical network nodes is implementing its own L2 and L3 functions in parallel. Each piece can do its part on its own, but it doesn’t create an especially streamlined operational model. Some amount of overlay and underlay integration has occurred. From the open networking point of view, a number of OpenFlow controllers have started to bring a degree of integration of underlay switches with a range of centralized control plane functions. And in a proprietary context, Cisco’s ACI framework and APIC service control system have brought a range of application policy controls to both overlay and underlay network infrastructures—the only glitch from an optimization point of view is it’s not being implemented on a fully open platform. Neither of these early stage developments has brought a design that unlocks the potential of the open network control environment of SDN with the power of value-add that can be obtained from service control applications running in parallel with the SDN controller that have the ability to optimize both the virtual and the physical network environments according to the operator’s service delivery requirements. Most SDN controllers delivered to date open up control of either a virtual overlay or a physical underlay but not both. And while the APIC is logically elegant within its own technological silo, it’s not opening up the opportunity for streamlining to the same extent—across a heterogeneous SDN infrastructure—as a solution leveraging, say, and Open Daylight-based set of network control plane functions could. A glimpse into a more open framework for streamlining whole data center networking fabrics has started to appear in a set of recently introduced SDN service control applications from Big Switch and Brocade. Each has the attribute of bringing a distinct set of added value to managing a data center’s SDN deployment, while leveraging the abstraction of the SDN controller as a means of streamlining the deployment of the application’s work. In this manner they have the potential of leveraging the versatility and openness of the SDN control plane for implementation of the service controls they are generating in either a virtual or a physical deployment or both. Simplifying analytics, traffic engineering, and application policy controls in this way brings an order of magnitude increase in the level of efficiency that an operations and service management team can achieve toward the services they are managing. ... View more

...and how reflecting on this can help navigate the path ahead in realizing the promise of the new software-defined model A number of parallels exist between the nascent forms of software-defined networking (SDN) we are working with today and the early stages of development in a similar area of technology that began in the mid 1990s and required more than a decade of steady enhancements to become the essential part of many network deployments that MPLS is today. By looking at these parallels we can gain some perspective on the nature of such innovations and, yes, their related upheavals, as well as inspiration for continuing to work hard on the finer points of implementation that will ultimately bring the simplified, more agile design model of SDN into wider use. Let’s look at the parallels in point-counterpoint mode. Today: We often say in moments of exasperation things such as there are too many forms of SDN; it will die before lift-off because the parts just won’t play with each other. Then: In 1997 the comments were that there were too many forms of MPLS (too many ways distributing labels in a network, TDP, LDP, BGP, etc.), and how will we ever build multivendor deployments? In the end, meeting customers’ requirements whittled options down to a few basic alternatives that allowed for some choice, but ensured multi-vendor networks using MPLS could be built. Today: There are too many choices for communicating with elements southbound from controllers; there is no real hope for efficiencies and scaling in control plane abstractions. Then: In the late 90s on MPLS we said things such as there are too many choices for implementing VPNs, quality of service and traffic engineering with MPLS; we will never be able to build real service offerings. But eventually customers’ requirements brought RSVP-TE, MP-BGP, VPLS, and BGP/MPLS IP VPNs into play as means of meeting market requirements with interoperable designs. Today: People ask, how do I monitor this (add your own euphemism) thing and dismissively assert that SDN will forever be a lab experiment unless the real-time and on-going needs of managing such software-driven solutions can be met. Then: In the early days of MPLS we said similar things. MPLS was interesting in the lab, but it would never be adopted widely unless we solved the OA&M problem. And with the firm guidance of customers’ demands the development of mechanisms to manage MPLS networks evolved via RFC 4379, LSP ping, LSP traceroute, and other mechanisms widely employed today. And as we speak, innovation around MPLS is not yet dead despite its widespread adoption. EVPN and Segment Routing are two cases in point for how the evolution continues. By reflecting on these innovations and their refinement over time, we can perhaps weave in a modest amount of patience amidst the stream of developments and implementation models we are digesting with the new designs that are ushering SDN incrementally into our multidomain, multilayer, and multivendor world. In the end it may not matter if OpenFlow, XMPP, and NETCONF coexist in portions of an otherwise abstracted control plane. It may not matter that the service management templates used in different controllers vary greatly in implementation today, as they may evolve to converge on a few basic models as customers’ deployments continue, as happened with MPLS OAM. No doubt we are in the disruptive, chaotic, and sometimes confusing phase of innovation when it comes to SDN (for the WAN, for overlay networks, for underlay physical systems, for VNFs, etc.). But if we focus on the gains available from the architecture that have been shown in their early forms to date (flexibility in platform choice, efficiency and scale in monitoring large network systems, and acceleration of new service deployment, to name a few examples) and work on closing the gaps in the implementations that remain to be resolved for the deployments to be pursued with more confidence, we may benefit in a manner similar to the way we did from the persistence of the innovators who spawned MPLS and labored for its viable deployment in the wide array of use cases we have it deployed in today. ... View more

Disaggregated, modular, mix and match, open, these are the sound bites of the emerging white box and open software ecosystems. Will they define the architectural thinking used throughout our information-driven world moving forward? From the Open Compute Project in data center hardware to open source software such as Open Daylight and OpenStack, the principles of ‘don’t lock me in’ and ‘let me be in charge of components I need for my best-in-class solution’ are making a play for being the dominant drivers for solution designs in nearly every network and IT platform category. Take Cavium’s just-announced XPliant family of terabit-scale Ethernet Data Center switches as a fresh example. Its Open Compute Project design foundation means, with OCP’s Switch Abstraction Interface (SAI) the switches can be used by any open networking software team to build functions that suit their needs without being held back by the underlying hardware’s processing architecture. And, with its Open Network Install Environment (ONIE), solution designers can decide whichever network OS best suits their needs. Mix and match, open, see http://www.cavium.com/newsevents-Cavium-XPliant-Ethernet-Switch-Supports-the-Emerging-Open-Ecosystems.html. In another closely related category, look at Ericsson’s Hyperscale Data Center System (HDS 8000) introduced at Mobile World Congress last week. To support an array of cloud-scale workloads, Ericsson determined it makes sense for the processor and memory elements in its HDS server ‘sleds’ (individual units) to be mixable in a manner customers decide are optimal for their needs. Each combination can be made available to the larger ‘pool’ of resources available and allocated as desired by the cloud management system in use. Each module is attached via an optical infrastructure to simplify storage and compute integration, again based on the workload’s needs. Mix and match, modular, see http://www.ericsson.com/spotlight/cloud. Does this ultra-modular perspective mean the era of integrated product and solution deliveries is dead? Not completely. They will be less prominent in the long run but unlikely to go completely away. For example, HP delivers its Helion OpenStack cloud computing platform as a whole system offering for which it is accountable to its customers. It includes HP and open community components. Juniper delivers its OCX 1100 Open Networking Switch as a platform full of choices about the OS a customer chooses to use in its data center for which Juniper is accountable. It includes Juniper and open community components. The increased role of open and modular thinking in solution deliveries is just an indication that the range of ingredients available to producers is increasing (these options were not possible 10 years ago) and the opportunity to bring them to customers in creative ways have expanded. In that sense, the line defining for whom a solution integrator works—a ‘whole system’ vendor (Cisco, Ericsson, HP); a professional services firm (Accenture, Tata); or an end customer (DT, Equinix, NTT)—is being drawn more flexibly today (and moving to the future) than was possible a decade ago. Each party can decide the amount of responsibility it thinks it should shoulder in delivering the end result. The range of options has increased. Like many deeply rooted transitions, there are parts of this one that are sometimes messy and a bit fragile compared with the ‘certainty’ that integrated platform deliveries of the past have offered. However that fragility will likely subside in coming years as integrators of every type get more familiar with the open building blocks with which they are working, and the use cases they’re supporting put their real and natural pressure on where the boundaries of responsibility should lie for the solutions to be practical. The outcome will be a downshift in the unit cost of underlying hardware, an uptick in the amount of choice that solution integrators decide to use in their designs, and a rise in the value of the software in the solutions at every stage of deployments—from network nodes to server units to higher level applications—that support the services we decide we want to use. That transition will undoubtedly have its jarring and its stellar moments and will take some time to occur. In the meantime as it unfolds, it’s worth paying close attention to the shifts being brought to market in line with that trajectory in offerings such as the Cavium and Ericsson solutions highlighted here. ... View more

Some vendors are starting to leverage a truly open architecture for optimization of unified fabrics with extensible service control applications. One of the great opportunities in software-defined networking is to amplify the efficiency of network and service operations teams by allowing them to leverage a powerful set of logically centralized and abstracted control functions for the infrastructures and services they manage. While this model is simple to articulate it takes great vision and talent to realize in the world of real, deployed solutions that deliver the result. The goal is only partially realized by the use of SDN controllers themselves. Controllers indeed do help simplify by normalizing and abstracting control plane functions for the given domain. In parallel, though, operators are driving to achieve additional optimizations, efficiencies, and innovations by leveraging what I call SDN Service Control applications that work in tandem with the centralized SDN controller code. Examples of focus for these include traffic analytics, service level monitoring and management, and custom traffic steering design for various operating goals (application performance, service availability, cost optimization, etc.). The dynamics for how these goals can be pursued vary a bit between internal data center and adjacent wide area network infrastructures. I focus on data center implementations here . The end game we’re looking at is one where the logically centralized and streamlined controls for the network being managed dynamically serve the needs of the applications and users relying on it for their services. In many data centers this will include a sizable overlay virtual network running in parallel with a high-performance physical underlay network. It will include a blend of control plane and value-adding service control apps to make it all work automatically and with maximum performance, efficiency, security, and stakeholder satisfaction (phew!). A challenge in getting to this end game is achieving these results in a streamlined, integrated manner for both underlay and overlay networks. As implementing SDN in data center environments has gotten started, we’ve largely had operationally separate deployments of underlay and overlay networks. Services such as VXLAN and virtualized router modules are operating in their own logical scopes, and a sometimes heterogeneous fabric of underlying physical network nodes is implementing its own L2 and L3 functions in parallel. Each piece can do its part on its own, but it doesn’t create an especially streamlined operational model. Some amount of overlay and underlay integration has occurred. From the open networking point of view, a number of OpenFlow controllers have started to bring a degree of integration of underlay switches with a range of centralized control plane functions. And in a proprietary context, Cisco’s ACI framework and APIC service control system have brought a range of application policy controls to both overlay and underlay network infrastructures—the only glitch from an optimization point of view is it’s not being implemented on a fully open platform. Neither of these early stage developments has brought a design that unlocks the potential of the open network control environment of SDN with the power of value-add that can be obtained from service control applications running in parallel with the SDN controller that have the ability to optimize both the virtual and the physical network environments according to the operator’s service delivery requirements. Most SDN controllers delivered to date open up control of either a virtual overlay or a physical underlay but not both. And while the APIC is logically elegant within its own technological silo, it’s not opening up the opportunity for streamlining to the same extent—across a heterogeneous SDN infrastructure—as a solution leveraging, say, and Open Daylight-based set of network control plane functions could. A glimpse into a more open framework for streamlining whole data center networking fabrics has started to appear in a set of recently introduced SDN service control applications from Big Switch and Brocade. Each has the attribute of bringing a distinct set of added value to managing a data center’s SDN deployment, while leveraging the abstraction of the SDN controller as a means of streamlining the deployment of the application’s work. In this manner they have the potential of leveraging the versatility and openness of the SDN control plane for implementation of the service controls they are generating in either a virtual or a physical deployment or both. Simplifying analytics, traffic engineering, and application policy controls in this way brings an order of magnitude increase in the level of efficiency that an operations and service management team can achieve toward the services they are managing. ... View more

As the world gets driven more and more by cloud-based services, what do tomorrow’s operations jobs look like? A decade and more ago ops managers were blue chip contractors, assembling custom-tuned components into environments a well-known set of visitors could use for a prescribed set of tasks. In tomorrow’s cloud-based world the picture that’s emerging is one in which a much larger and more diverse set of visitors needs to be accommodated for purposes that vary widely depending on when and why they show up. Their expectation is that the cloud infrastructure makes a wide range of capabilities available when they need it, and that the underlying platform will be dynamically allocated to simply make it possible at that time. In this sense the new operations manager has to be aware of the capabilities of a variety of ‘venues’ (three-tiered applications, web-scale apps, elastic storage pools, etc.) and ready to let them out for exactly what the renter needs, now. The mix is larger. The versatility of functions is greater. And the client mix is constantly expanding. In this way the operations manager of the future is partly an expert realtor who maintains a pool of properties ready to be leveraged for what each client needs, ready to be reallocated to the next one when the first one is done. The realtor gets known for the quality of the properties that are offered. And the clients get referred because the promptness of service and the versatility to support their many distinct needs has been shown. The realtor simply has to ensure the range of properties on offer continues to be value to the clients who may want to visit. ... View more

Markets have been busy recently with announcements of solutions to help service providers benefit from powerful innovations in SDN, NFV and cloud computing systems. Solutions are emerging for fixed and mobile network environments, and for business and consumer applications. Pockets of solutions are emerging to address one part or another of an operator’s end-to-end environment, for example, increasing elasticity in mobile packet cores, simplifying business customer premise (CPE) configurations, and instantiating VNFs dynamically into cloud-based IT services. While progress in pockets is good, designers also have to keep in mind that customer experiences exist on an end-to-end basis, at each point of consumption and across the aggregated performance of each domain involved in the service. Indeed, by embracing the cloud-based paradigm we are pursuing a goal in which services–and the policies that control them–are dynamically managed across the collection of resources that support them. At its highest level, this is a job for service-level orchestration, for platforms that ‘think’ about a service end-to-end. Domain-specific solutions that optimize for local requirements can be integrated into a total service using northbound plug-ins and APIs. In essence a new design challenge for SPs has emerged: to optimize the mosaic of new virtual elements while still achieving a high-quality operation. How efficient (or complicated) this is depends to a degree on how efficiently the ‘gold vein’ of consistent service policies can be deployed into an end-to-end path at scale. How well an SP can do this will affect both quality of experience for the customer as well as total cost of ownership and return on investment for the SP. One approach to mastering this challenge is to build using solutions that employ a consistent framework for managing policies across multiple domains, such as end-user CPE, wide area networks, and cloud computing data centers. The overall goal could be approached by focusing on key building blocks of the end-to-end service environment and managing its policies consistently, thereby getting a start on the overall goal. For example, managing networking resources consistently would be one way of achieving continuity at scale, at least for the network underpinning user applications. This approach requires a policy management system that aligns the network ‘northbound’ consistently with the operator’s requirements and propagates policies for enforcing those requirements in a scalable manner to each virtual element that is deployed in multiple domains. This is an ambitious, some might say, lofty goal. Yet realizing the goal of delivering services for many individual customers on demand and at scale and with consistently orchestrated quality requires just such a far-reaching implementation. Thus, while it is possible to start transitioning infrastructures to virtualized designs one domain at a time, it is also possible to build on an architecture that consistently spans multiple domains on an end-to-end basis. In this way, an operators may simultaneously increase efficiency and increase the quality of customers’ experiences. In doing so, they would measurably accelerate their progress to delivering cloud-based services on demand across an entirely virtualized service delivery infrastructure with consistent end-to-end policy control. ... View more

The most intriguing development in cloud service architectures in the past several months to me (beyond the continuing innovations in the OpenStack cloud management suite) is introduction of the Intercloud vision.  Remarkably elegant, Intercloud has the potential to create an open and highly elastic environment for cloud-based applications and services.  Among the cloud service delivery platforms I have explored, none has the potential for enabling the versatility of offerings and the reach of federation across an open fabric that the Intercloud envisions.  In the way that the Internet is a network of networks, the Intercloud has the potential to become  a cloud of many clouds, at global scale. At its basic level the Intercloud enables businesses to build hybrid cloud solutions in a variety of scenarios.  These range from enterprises and operators using the Intercloud hybrid solution itself to enterprises accessing other providers such as Amazon, Google or Microsoft via gateways to their environments included in the Intercloud solution.  Beyond the hybrid cloud deployments, Intercloud enables cloud providers to extend their own service offerings in efficient, innovative ways.  For example if an operator wants to increase its capacity, reach more locations or add additional services to its catalogue without making the full investment themselves, Intercloud can be used to extend the operator’s offerings on a white label basis for the operator’s own brand, or as a Cisco branded extension to the operator’s catalogue for applications the operator may want to add (such as hosted collaboration).  Early adopter Telstra envisions just these kinds of use cases in expanding its services into Asian and more distant markets, and into incremental application areas. Beyond these uses, the most inspiring aspect of the Intercloud platform to me is its potential for growing into a highly elastic cloud of clouds at remarkable scale. Beyond providing IaaS and SaaS in any geography in which the operator can arrive at favorable commercial terms (via federation and branding agreements) imagine what the Intercloud could enable for developers looking for global reach for applications in the Internet of Everything, or for other applications that have meaningful potential in distant global markets.  The Intercloud has the potential to reduce or eliminate barriers to entry for service innovations and delivery in many markets, enabling participants to complete on a more open, level and scalable playing field than has been present to date in other cloud service delivery environments.  Its inherently federated and API-driven architecture for cloud interconnections reflects the same openness that has made the Internet the global force for innovation that it is, leveraging mechanisms such as BGP and HTTP to accomplish its results.  Is the Intercloud the platform that will finally allow any operator or developer to compete at scale with organizations previously considered to have unconquerable advantages in service and application delivery (OTT and ‘web scale’ providers)? Time will tell.  But for now the chance to start realizing the opportunities has begun to materialize, and proof points of the mechanisms for enabling them have been brought into public domain by the early ecosystem partners in the Intercloud solution who are testing their viability.  Kudos to Cisco and its partners developing the vision and pursuing the potential of cloud-based services at such an eye-popping scale. About the Author Learn more about Paul Parker-Johnson and read his other blog posts by visiting his Community Profile Follow Park Parker-Johnson on Twitter @pj4cloud ... View more

As an industry, our visions of progress in SP offerings are filled with virtualized functions, elastic workloads, orchestration, APIs, scalable infrastructures and almost everything software-defined.  None of this is flawed, and we get strong, regular glimpses of the potential in such heavily virtualized models in an array of domains regularly.  For example, intriguing offerings are presented to us mid-session in streaming video services based on our individual profiles and histories. Auto-scaling in hybrid cloud IT for cost-effective performance improvements is enabled using the provider’s service management API.  And, optimizations in cost and performance of multi-layer network services is proven to deliver measurable benefits by managing each layer as part of a unified, abstract service design applied to each underlying layer. With this progress in hand toward realizing a more agile SP market, we have not yet arrived at a point where complete automation of service composition and deployment across the array of applications operators target has been achieved.  We are on the cusp of realizing complete frameworks and deployment kits to put that goal within reach, but still have important hurdles to overcome in making the vision real. Let’s look at where the improvements in integration remain to be made. If we look at it as a ‘start-to-finish’ checklist of requirements for an elastic, software-driven environment, we can start by noting that strong solutions for automating development and deployment of applications into cloud-based services in real-time have started to dramatically shorten the time to delivery for new application functions.  Introducing new features into Google or Netflix or other ‘web-scale’ application systems is ample demonstration of this method’s value.  Expanding DevOps capabilities to new functional areas (like inserting new functions into programmable networks) is key to expanding the value of services.  Similarly dramatic progress has been made in creating and managing virtual infrastructures for compute, storage and network functions in many XaaS environments, and we see intriguing service offerings and bundles emerging ‘one by one’ as operators overcome their individual service delivery barriers.  But, can we blend these individual ‘buckets’ of virtualized service delivery solutions into more complete end-to-end service creation frameworks? As we make progress in individual domains, a hurdle remaining to be overcome is the integration of toolsets into a suite of offerings that fits multiple SP situations and enables them to generate services in a manner that will fit their adoption profile at the pace that works for them.  To add urgency to this point, one of the critical success factors recently identified by the ETSI Network Functions Virtualization (NFV) working groups in the achievement of their goals is development of a suitably strong management and orchestration (MANO) framework that will enable virtualized network functions to be deployed effectively in conjunction with the other elements of service providers’ multi-faceted infrastructures.  Helping overcome these barriers is a task that can be taken on by suppliers with sufficient range of vision, offerings and resources to enable SPs’ virtualized solution deliveries productively.  Let’s break this down into two overall dimensions where packaging, functionality, and go-to-market leadership can be provided:  having the right functionality, and having the right consumption models for SPs to choose between. On functionality, if a supplier starts by being able to profile the business parameters of an SP’s offering and populate them into the charging, cataloguing, provisioning, and other OSS/BSS systems needed to commercialize the service, this accomplishes a key element in the flow of automation that results.  From there if the supplier can offer a portfolio of functional elements – either virtual or physical – to support a wide range of operator services, and provides them in a manner that integrates with orchestration and management required for operation, a second key step in deployment simplification has been taken. It’s easy to see how this aspect of portfolio breadth is impactful in infrastructure functions like firewalling, switching, policy enforcement, computing platforms, and others.  And it is impactful in application-oriented software offerings like video content libraries, collaboration system modules, and vertical industry applications (smart grid, health care, transportation, etc.).  If the supplier is also in a position to offer templates and policies that can be used by an operator to jump-start implementation in the target virtual infrastructure, we start to have the level of integrated portfolio operators have been hungry for as the virtualized and software-defined infrastructure transformations have been developing. Going beyond this, recognizing that operators are functioning at different paces of development in their own portfolios, it’s equally meaningful if suppliers can deliver their solutions at varying levels of integration to facilitate uptake by SPs. For example, an individual function such as content inspection or SP wireless LAN may be of interest to an operator a la carte, ready for integration into a service delivery framework as the operator prefers.  Or, a different operator may be more interested if those functions are available as part of a pre-integrated, certified solution including orchestration, templates, and the functional components themselves, ready to deploy as a pre-tested module. Or still, another operator who’s interested in lower risk in trialing and deployment may want to obtain these capabilities ‘as a service’ from the supplier to minimize training, deployment and go-to-market overhead in determining if the service is going to ‘take’ in their subscriber base.  Offering such a range of consumption models provides a boost to the SP community in being able to accelerate deployments at a pace each SP deems is best for them. At this early stage of the developing market for virtualized infrastructure solutions, coming to the table with that many areas of requirement addressed – and still being open to work with an open, standards-based ecosystem of suppliers to contribute to working SP solutions – is a crucial part of accelerating progress.  We look at Cisco’s introduction of the Evolved Services Platform (ESP) as a leading example of the top-to-bottom portfolio breadth and flexibility in how elements can be adopted by SPs that will foster development of innovative and virtualized services faster.  At this stage of the market for virtualized service delivery platforms ESP provides a unifying framework for integration of capabilities productively, and still leaves the door open for innovation in all the key components of the value chain.  It should prove very effective in stimulating uptake for powerful, versatile service delivery platforms in a wide range of application categories.  In this sense it helps operators overcome many of the barriers to adoption they have faced when considering how to take advantage of important innovations at different points in the virtualized service delivery platforms landscape.  By overcoming those barriers it becomes an ingredient for achieving real progress and benefits in the broad transformation of SP infrastructures to becoming more fully software-driven infrastructures. Read and download for more information: ACG Research Paper: Business Case for Cisco Evolved Services Platform and NFV ... View more

In the past two to three years we have analyzed and experimented with new designs and service innovations that can be created using SDN and related virtualization models. Early evidence of the types of benefits that can be achieved has emerged in the data center and cloud computing domains as virtual networks and SDN architectures of various types have created new offerings in XaaS and other application areas. However as we dig deeper into the implications of SDN throughout the SP landscape, we are starting to wrestle more deeply with the fact that SP services are delivered across a range of domains and a broad menu of services, and that SDN solutions – while following certain fundamentals in every case – are destined for use in unique end-to-end combinations.  SDN is sure to be deployed in metro, edge, and core network areas, in addition to the data center environment.  Yet solutions will need to integrate well end-to-end to deliver on the model’s benefits. Thinking about this end-to-end service environment has caused me to conclude that, to be maximally effective, SDN solutions will need to support 5 key points of openness for the benefit of their developers and customers.  These include 4 points of direction on an architectural compass and a 5 th dimension of internal modular design.  Let’s look at this in the context of a specific SP use case, and take general lessons from there. Let’s look outside the data center (where SDN deployments are today more fully understood) and consider an operator’s metropolitan area network in relation to its full suite of services.  For many operators (often called converged SPs) this metro will include support for fixed residential, fixed business, and mobile network services, and a connection to the operator’s IP edge/core domains. For SDN to deliver meaningful benefits in this metro (such as simplification, agility, and scale) it will work best if it is open and modular on the 5 dimensions I mentioned – the 4 ‘compass points’ of northbound, southbound, eastbound and westbound, and the 5 th internal area.  In the northbound direction the SDN control tier has to support open interfaces to orchestration and service management systems to simplify deployment and accelerate time to revenue.  This could be done with well defined object models and an open northbound interface such as a suite of RESTful APIs.  This would make communication with, say, the OpenStack platform (or other service management systems) simple, robust and perhaps most important, extensible. Looking southbound toward the mixture of network elements that will be supporting the SP services in the metro (such as optical multiplexers, Ethernet switches, access multiplexers, and others) interpreting the higher layer service requirements consistently, and translating them into the protocol best suited for managing each class of device is the key to flexibility in managing the underlying infrastructure.  Southbound communication could be done using OpenFlow, NetConf, PCEP or other open, extensible protocols.  But the key to sustainable benefits is integration of the protocols with an abstraction layer in the SDN controller that allows higher layer services to be deployed efficiently across a diverse set of elements. Simultaneously, controllers have eastbound and westbound integration requirements to support flexibility in choice of network elements and end-to-end integration of services.  In the metro the SDN platform needs to provide support for business VPN, residential broadband, and mobile network services.  And it needs to manage functions like bandwidth allocation, CoS settings, and failover behaviors consistently for the service and with each element type.  In ‘westbound’ connections functions need to align with CPE, access, and mobile network interfaces.  And in the ‘eastbound’ direction (IP edge/backbone network sites) similar integrations are required.  Since SDN is supplying consolidated network control for the metro, employing a modular, extensible, and standards-based suite of protocol implementations is as critical to success as achieving the right logical abstractions in the northbound and southbound directions.  This can include BGP, MPLS, Ethernet, optical and other protocol modules, depending on the case.  It is analagous to the requirement in individual element classes (such as switches, routers, and multiplexers) to support an appropriate mix of interfaces and protocols for the services they are supporting.   In an SDN control tier, however, the range of supported elements and control plane protocols is likely to be greater than those supported in a typical current-day network element.  This is so customers can achieve the simplification, agility, innovation and scale they are seeking. Thus the special requirement in the SDN case is for a suitably broad range of east- and west-bound modules that can be maintained and extended moving forward as functionalities change. The final dimension is openness internal to the SDN controller platform itself.  Aside from supporting ease of extension by its own developers, an open internal system design helps partners and customers add value to the platform with their own innovations.  Whether this is done using an approach like Java OSGi (as is done in the Open Daylight SDN system) or by other methods, the point is, extending functionality within the controller is as valid an enhancement path as adding applications that interact with the controller using its northbound APIs. Both methods accelerate innovation and deployment of operator services on as many dimensions as possible. From this metro SDN case it’s easy to see how these 5 points of openness in adjacent network domains will contribute to SPs being able to assemble the most flexible, efficient and scalable SDN platform that they can.  If the SDN tier that’s deployed across all of the domains can communicate consistently with northbound orchestration to manage services cohesively, it will make introducing new services that much easier and faster to achieve.  And if the controllers at the same time are open and modular for managing a broad mixture of network elements in each domain, then they are achieving the efficiency, flexibility and scale so crucial to their operating needs.  If any of the controllers they deploy is implemented with significant limitations on any of the 5 target dimensions, then the range of opportunities available to them will be constrained to some degree.  This is not to say that early stage or domain-specific solutions may not achieve some success as suppliers and customers test out the technologies and gain experience with the model.  Instead it’s to say that the long-term benefits of the abstracted and extensible model of SDN for SPs are most likely to be maximized if the design approach embodied in the 5 points of open controller system architecture are used. A proof point for this perspective can be found in the initial Open Daylight SDN controller release (called ‘Hydrogen’).  However that is just one reference point that is likely to coexist in the market with multiple other offerings.  Thus in the big picture, the greater the number of solutions embracing the 5 open points model, the broader the overall benefit stream is likely to be. ... View more