Month: April 2017

Picking the best approach to service modeling for lifecycle management is like picking the Final Four; there’s no shortage of strongly held opinions.  This blog is my view, but as you’ll see I’m not going to war to defend my choice.  I’ll lay out the needs, give my views, and let everyone make their own decision.  If you pick something that doesn’t meet the needs I’m describing, then I believe you’ll face negative consequences.  But as a relative once told me a decade or so ago, “Drive your own car, boy!”

I’ve described in prior blogs that there are two distinct layers in a service model—the service layer and the resource layer.  The need to reflect the significant differences in the missions of these layers without creating a brittle structure effectively defines a third layer, the boundary layer where I’ve recommended that the actual process of laying out the abstractions to use should start.  I’m going to start the modeling discussion at the top, though, because that’s where the service really starts.

The service layer describes commercial issues, parameters, elements, and policies at the business level.  These models, in my view, should be structured as intent models, meaning that they create abstract elements or objects whose exposed properties describe what they do, not how.  The beauty of an intent model is that it describes the goal, which means that the mechanisms whereby that goal can be met (which live within the intent model) are invisible and equivalent.

I’ve done a fair amount of intent modeling, in standards groups like IPsphere and the TMF and in my own original ExperiaSphere project (spawned from TMF Service Delivery Framework work, TMF519), the CloudNFV initiative where I served as Chief Architect, and my new ExperiaSphere model that addressed the SDN/NFV standards as they developed.  All of these recommended different approaches, from TMF SID to Java Classes to XML to TOSCA.  My personal preference is TOSCA because I believe it’s the most modern, the most flexible, and the most complete approach.  We live in a cloud world; why not accept that and use a cloud modeling approach?  But what’s important is the stuff that is inside.

An intent model has to describe functionality in abstract.  In network or network/compute terms, that means that it has to define the function the object represents, the connections that it supports, the parameters it needs, and the SLA it asserts.  When intent models are nested as they would be in a service model, they also have to define, but internally, the decomposition policies that determine how objects at the next level are linked to this particular object.  All of this can be done in some responsive way with any of the modeling approaches I’ve mentioned, and probably others as well.

When these models spawn subordinates through those decomposition policies, there has to be a set of relationships defined between the visible attributes of the superior object and those of its subordinates, to ensure that the intrinsic guarantees of the abstract intent model are satisfied.  These can operate in both directions; the superior passes a relationship set based on its own exposed attributes to subordinates, and it takes parameters/SLA exposed by subordinates and derives its own exposed values from them.

It follows from this that any level of the model can be “managed” providing that there are exposed attributes to view and change and that there’s something that can do the viewing and changing.  It also follows that if there’s a “lifecycle” for the service, that lifecycle has to be derived from or driven by the lifecycles of the subordinate elements down to the bottom.  That means that every intent model element or object has to have a “state” and a table that relates how events would be processed based on that state.  Thus, each one has to specify an event interface and a table that contains processes that are to be used for all the state/event intersections.

Events in this approach are signals between superior and subordinate models.  It’s critical that they be exchanged only across this one specific adjacency, or we’d end up with a high-level object that knew about/from something inside what’s supposed to be an opaque abstraction.  When an event happens, it’s the event that would trigger the model element to do something, meaning that it’s the event that activates the lifecycle progression.  That’s why this whole state/event thing is so important to lifecycle management.

A service model “instance”, meaning one representing a specific service contract or agreement, is really a data model.  If you took that model in its complete form and handed it to a process that recognized it, the process could handle any event and play the role of the model overall.  That makes it possible to distribute, replicate, and replace processes as long as they are properly written.  That includes not only the thing that processes the model to handle events, but also the processes referenced in the state/event table.  The model structures all of service lifecycle management.

It’s easy to become totally infatuated with intent modeling, and it is the most critical concept in service lifecycle management, but it’s not the only concept.  Down at the bottom of a tree of hierarchical intent models will necessarily be something that commits resources.  If we presume that we have a low-level intent model that receives an “ACTIVATE” event, that model element has to be able to actually do something.  We could say that the process that’s associated with the ACTIVATE in the “Ordered” state does that, of course, but that kind of passes the buck.  How does it do that?  There are two possibilities.

One is that the process structures an API call to a network or element management system that’s already there, and asks for something like a VLAN.  The presumption is that the management system knows what a VLAN is and can create one on demand.  This is the best approach for legacy services built from legacy infrastructure, because it leverages what’s already in use.

The second option is that we use something model-driven to do the heavy lifting all the way down to infrastructure.  TOSCA is a cloud computing modeling tool by design, so obviously it could be used to manage hosted things directly.  It can also describe how to do the provisioning of non-cloud things, but unless you’re invoking that EMS/NMS process as before, you’d have to develop your own set of processes to do the setup.

Where YANG comes in, in my view, is at this bottom level.  Rather than having a lot of vendor and technology tools you either inherit and integrate or build, you could use YANG to model the tasks of configuring network devices and generating the necessary (NETCONF) commands to the devices.  In short you could reference a YANG/NETCONF model in your intent model.  The combination is already used in legacy networks, and since legacy technology will dominate networking for at least four to five more years, that counts a lot.

I want to close this by making a point I also made in the opening.  I have a personal preference for TOSCA here, based on my own experiences, but it’s not my style to push recommendations that indulge my personal preferences.  If you can do what’s needed with another model, it works for me.  I do want to point out that at some point it would be very helpful to vendors and operators if models of services and service elements were made interchangeable.  That’s not going to happen if we have a dozen different modeling and orchestration approaches.

The next blog in this series will apply these modeling principles to the VNFs and VNF management, which will require a broader look at how this kind of structured service model supports management overall.

 

Service modeling has to start somewhere, and both the “normal” bottom-up approach and the software-centric top-down approach have their plusses and minuses.  Starting at the bottom invites creating an implementation-specific approach that misses a lot of issues and benefits.  Starting at the top ignores the reality that operators have an enormous sunk cost in network infrastructure, and a revenue base that depends on “legacy” services.  So why not the middle, which as we saw in the last blog means that boundary layer?

A boundary-layer-driven approach has the advantage of focusing where the capabilities of infrastructure, notably the installed base of equipment, meets the marketing goals as defined by the service-level modeling.  The trick for service planners, or for vendors or operators trying to define an approach that can reap the essential justifying benefits, is a clear methodology.

The most important step in boundary-layer planning for service lifecycle management and modeling is modeling legacy services based on OSI principles.  Yes, good old OSI.  OSI defines protocol layers, but it also defines management layers, and this latter definition is the most helpful.  Services, says the OSI management model, are coerced from the cooperative behavior of systems of devices.  Those systems, which we call “networks”, are of course made of the devices themselves, the “physical network functions” that form the repository of features that NFV is targeting, for example.

Good boundary-layer planning starts with the network layer.  A service or resource architect would want to first define the network behaviors that are created and exploited by current infrastructure.  Most network services are really two-piece processes.  You have the “network” as an extended set of features that form the communications/connection framework that’s being sold, and you have “access”, which is a set of things that get sites connected to that network framework.  That’s a good way to start boundary planning—you catalog all the network frameworks—Internet, VPN, VLAN, whatever—and you catalog all the access pieces.

You can visualize networks as being a connection framework, to which are added perhaps-optional hosted features.  For example, an IP VPN has “router” features that create connectivity.  It also has DNS and DHCP features to manage URL-versus-IP-address assignment and association, and it might have additional elements like security, tunnels, firewalls, etc.  The goal of our network behavior definition is to catalog the primary network services, like IP VPN, and to then list the function/feature components that are available for it.

From the catalog of services and features, we can build the basic models at the boundary layer.  We have “L3Connect” and “L2Connect” for example, to express an IP network or an Ethernet network.  We could also have an “L1Connect” to represent tunnels.  These lowest-level structures are the building-blocks for the important boundary models.

Let’s go back to IP VPN.  We might say that L3Connect is an IP VPN.  We might further classify IP VPN into “IPSubnet”, which is really an L2Connect plus a default gateway router.  We might say that an L1Connect plus a SDWAN access set is also an IP VPN.  You get the picture, I think.  The goal is to define elements that can be nuclear, or be made up of a combination of other elements.  All of the elements we define in the boundary layer relate to what it looks like as a service and how we do it through a device or device system.

Don’t get caught up in thinking about retail services at this point.  What we want to have is a set of capabilities, and a mechanism to combine those capabilities in ways that we know are reasonable and practical.  We don’t worry about the underlying technology needed to build our L2Connect or whatever, only that the function of a Level 2 connection resource exists and can be created from infrastructure.

The boundary-layer functions we create obviously do have to be sold, and do have to be created somehow, but those responsibilities lie in the resource and service layers, where modeling and lifecycle management defines how those responsibilities are met.  We decompose a boundary model element into resource commitments.  We decompose a retail service into boundary model elements.  That central role of the boundary element is why it’s useful to start your modeling there.

I think it’s pretty self-evident how you can build boundary models for legacy services.  It’s harder to create them when there is no service you can start with, where the goal of the modeling is to expose new capabilities.  Fortunately, we can go back to another structural comment I made in an earlier blog.  All network services can be built as a connection model, combined with in-line elements and hosted elements.  An in-line element is something that information flows through (like a firewall) and a hosted element is something that performs a service that looks something like what a network endpoint might do (a DNS or DHCP server).  A connection model describes the way the ports of the service relate to traffic.  Three connection models are widely recognized; “LINE” or “P2P”, which is point-to-point, “LAN” or “MP” which is multipoint, and “TREE” which is broadcast/multicast.  In theory you could build others.

If we presume that new services would be defined using these three most general models, we could have something that says that a “CloudApplication” is a set of hosted elements that represent the components, and a connection model that represents the network service framework in which the hosted elements are accessible.  Users get to that connection model via another connection model, the LINE or access model, and perhaps some in-line elements that represent things like security.

If new services can be built this way it should be obvious that there are some benefits in using these lower-level model concepts as ways to decompose the basic features like L2Connect.  That’s an MP connection model built at L2, presumably with Ethernet.  If this approach of decomposing to the most primitive features is followed uniformly, then the bottom of the boundary layer is purely a set of function primitives that can be realized by infrastructure in any way that suits the functions.  L3Connect is a connection model of MP realized at the Level 3 or IP level.  You then know that you need to define an MP model, and make the protocol used a parameter of the model.

Even cloud applications, or cloud computing services, can be defined.  We could say that an ApplicationService is a hosted model, connected to either an L2 or L3 Connect service that’s realized as a MP model.  How you host, meaning whether it’s containers or VMs, can be a parameter of the hosting model if it’s necessary to know at the service layer which option is being used.  You could also have a purely “functional” hosting approach that decomposes to VMs or containers or even bare metal.

There is no single way to use the boundary layer, but for any given combination of infrastructure and service goals, there’s probably a best way.  This means it’s worth taking the time to find what’s your own best approach before you get too far along.

In our next piece, we’ll look at the modeling principles for the service, boundary, and resource layers to lay out what’s necessary in each area, and what might be the best way of getting it.

This is my third blog in my series on service management, and like the past two (on the resource layer and service layer) this one will take a practical-example focus to try to open more areas of discussion.  I don’t recommend anyone read this piece without having read the other two blogs.

The service layer of a network model is responsible for framing commercial presentation and integrating OSS/BSS processes.  The resource layer manages actual deployment and FCAPS/network operations.  The goal should be to keep these layers independent so that technology doesn’t impact service definitions and retail considerations impact technical deployment only insofar as they change technical requirements.  The “boundary layer” that makes this happen is the topic today, and this layer is actually a kind of elastic speed-match function that will expand and contract, absorb functions and emit them, depending on just how an operator frames services and deploys them.

In a perfect world (meaning one aimed at presenting us with ease and pleasure!) we’d see a boundary layer exactly one object thick.  A resource layer would emit a set of “Behaviors” or “Resource-Facing Services” (RFSs) that would then be assigned commercial terms by a corresponding service-layer element.  We’d end up with a kind of boundary dumbbell, with one lump in the service layer and one in the resource layer, and a 1:1 bar linking them.

To understand why the boundary layers are probably more complicated, let’s look at an example.  Suppose we have a “Behavior” of “L3VPN”, which offers IP virtual-network capability.  We might have four different models for creating it—IP/MPLS, IP/2547, hosted virtual routers, and SD-WAN.  These technologies might be available in some or all of the service area, and might be able to deliver on any SLA offered for L3VPNs or only a subset.  That sets up our example.

Suppose an order for L3VPN comes in, and asks for an SLA and served locations that fit all the models, or even just two of them.  We could presume that the resource layer would decide on which to use, based on cost metrics.  Suppose that we had no options that did everything.  We’d now select multiple implementations, and to support that we’d have to ensure that each deployed L3VPN had a “gateway” port that let it attach to other implementations.  We’d pick the implementation based on cost as before.  So far, so good.

Now suppose some clever marketing person said that because SD-WAN was hot, they wanted to have a specific SD-WAN offering.  We now have two choices.  First, we could define a specific service of SD-WAN VPN, which would decompose only into SD-WAN implementations.  Second, we could introduce a “TechType” parameter into the L3VPN model, which could then guide the decomposition below.  It’s this situation that opens our boundary discussion.

Defining two services that are identical except in how they can be decomposed is an invitation to management/operations turmoil.  So passing a parameter might be a better solution, right?  But should the decomposition of that parameter-driven implementation choice lie in the service or resource layer?  Whether we do SD-WAN or IP/MPLS VPN is implementation, if we presume the SLA and location requirements can be satisfied either way.  But it was a commercial decision to allow the technical choice?  That might suggest that we needed to make the choice in the service layer.

A boundary layer strategy could accommodate this by exposing some parameters to allow resource-layer decomposition to accommodate technology selection and other factors based on retail service commitments.  You could consider the boundary layer, and implement it, either as part of the resource layer or the service layer, and where services are numerous and complicated you could make it a separate layer that was administered by agreement of the architects in both areas.

You have to be careful with boundary functions, and that’s a good reason to keep them independent of both layers.  Any parameters that don’t describe a basic SLA and yet are exchanged between the service and resource layers could end up complicating both layers at best, and creating brittle or condition-specific models and implementations.  A good example is that if you decide on consideration to withdraw a specific implementation of our L3VPN model, service definitions that included parameter-based decomposition that relied on that implementation would now be broken.  That could be fixed for new customers, but what happens when a service model for an active service instance is changed?

The boundary layer is probably the logical place to establish service and infrastructure policy, to integrate management practices between services and resources, and to create a “team mentality” around transformation and new service models.  Not surprisingly, it’s not a place on which operators (or vendors) have focused.  Most seem to think that having a boundary layer at all is an admission of failure, or perhaps an accommodation to the “antiquated” divided management model that now prevails between OSS/BSS and NMS.  Not true.

High inertia in the service-creation process is arguably a direct result of the view that somehow a service is a resource, that all services derive directly from inherent protocol-centric resource behaviors.  If that view could be battered down we could end up with more agile services even if no infrastructure changes were made, and the explicit focus on a boundary function is IMHO mandatory in doing the battering.

Infrastructure lives in a world of long capital cycles, from five to fifteen years.  Services live in a world where six months can be interminable.  With an explicit notion of a boundary layer, we could set both service and resource planners on the task of creating abstract components from which future services would be built.  Is that a formidable task?  Surely, but surely less formidable than the task of building infrastructure that anticipated service needs even five years out.  Less formidable than defining a service strategy that had to look ahead for a full capital cycle to prep installed resources to support it.

Services at the network level reduce to those pipes and features I talked about in the first blog of this series.  As simplistic as that may be, it is still a step whose value is recognized in software architecture—you define high-level classes from which you then build lower-level, more specific, ones.  We have many possible kinds of pipes, meaning connection tunnels, and clearly many types of features.  We could divide each of these base classes into subclasses—real or virtual for “pipes”, for example, or hosted experiences versus in-line event/control tasks for “features”.  If the boundary layer of the future was equipped with a set of refined abstractions that could easily map up to services or down to implementations, we need only find examples of both to create a transformed model, at any point we desire.

The boundary layer, in fact, might be the best possible place to apply standards.  There are many variations in operator practices for service management and resource management today, and many different vendor and technology choices in play even without considering SDN, NFV, and the cloud.  Standards, to be effective, would have to accommodate these without constraining “transformation” and at the same time stay applicable to the critical “what we have now” dimension.  That’s what the boundary layer could accomplish.

No software development task aimed at abstraction of features and resources would ever be undertaken without some notion of a converging structure of “classes” that were built on and refined to create the critical models and features.  Since both services and infrastructure converge on the boundary layer, and since the goal of that layer is accommodation and evolution in parallel, it’s probably the place we should start when building our models of future services.  Since we have nothing there now, we would be free to pick an approach that works in all directions, too.

In the next blog in this series, I’ll look at how starting service modeling with the boundary point might work, and how it would then extend concepts and practices to unify transformation.

Yesterday I talked about service transformation through lifecycle management, starting with how to expose traditional networking services and features through intent models.  Today, I’m going to talk about the other side of the divide—service modeling.  Later, we’ll talk about the boundary function between the two, and still later will take up other topics like how service architects build services and how portals then activate them.

The resource layer that we’ve already covered is all about deployment and management of actual resources.  The service layer is all about framing commercial offerings from contributed “Behaviors” or “Resource-Facing Services” (RFS) and sustaining commercial SLAs.  Again, there’s nothing to say that a common model and even common decomposition software wouldn’t be able to deal with it all.  I think TOSCA would enable that, in fact.  Whether that single-mechanism approach is useful probably depends on whether any credible implementations exist, which operators will have to decide.

The top of the service layer is the actual commercial offerings, which the TMF calls “Products” because they get sold.  These retail services would be represented by a model whose properties, ports, and parameters (those “three Ps”) are the attributes that the buyer selects and the operator guarantees.  The goal of the whole service modeling process is to decompose this single retail service object (which you will recall is an intent model) into a set of deployments onto real resources.  That, in my view at least, could include functional decomposition, geographic/administrative decomposition, or a combination thereof.

Functional decomposition means taking the retail service properties and dividing them functionally.  A VPN, for example, could be considered to consist of two functional elements—“VPNCore” and “VPNAccess”.  It would be these two functional elements that would then have to be further decomposed to create a set of Behaviors/RFSs that included our “Features” and “Pipes” primitive elements, and that were then deployed.

Geographic/administrative decomposition is essential to reflect the fact that user ports are usually in a specific place, and that infrastructure is often uneven across a service geography.  For example, a “VPNAccess” element might decompose into at least an option for cloud-hosted VNFs where there was infrastructure to support that, but might decompose into “pipes” and physical devices elsewhere.

Probably most services would include a mixture of these decomposition options, which I think means that what we’re really looking for is a set of policies that can control how a given higher-layer element would be decomposed.  The policies might test geography, functionality, or any other factor that the operator (and customer) found useful.  Because the policies are effectively based on retail element parameters, the relevant parameters have to be passed from the retail element, down as far as they’d need to be tested in policies.

Policies that control decomposition have, as their goal, selecting from among the possible deployment options associated with a given retail feature.  These features could be considered analogous to the TMF’s “Customer-Facing Services” or CFSs, but the latter seem to be more likely to be rigorous functional or administrative divisions, almost “wholesale” elements.  What I’m describing is more arbitrary or flexible; all you care about is getting to the point where resources are committed, not to creating specific kinds of division.  My functional and geographic examples are just that; examples and not goals.

If we presume (as I do) that the service domain is the provenance of “service architects” who are more customer- or market-oriented than technically oriented, it follows that the Behaviors/RFSs that are exposed by the resource layer are probably not going to be directly composed into services, or even directly decomposed from them.  Another likely role of the boundary layer is to frame the resource-layer offerings in the desired lowest-level units of service composition.

In our hypothetical technical and marketing meetings, a team from each group would likely coordinate what the boundary layer would expose to the service layer.  From this, service architects would be able to compose services based on pricing, features, and SLA requirements, and if technology/vendor changes were made down in the resource layer, those changes wouldn’t impact the services as long as the paramount rule of making sure that intent models supported common capabilities regardless of how they decompose, was followed.

The service layer is also where I think that federation of service elements from others would be provided.  If we have a service-layer object, we could have that object decompose to a reference to a high-level service object (a wholesale service element) provided by a third party.  The decomposition would activate an order process, which is a model decomposition, in another domain.  This could be a 1:1 mapping, meaning a single object in the “owning” service model decomposes to a like object in the “wholesale” service model, or the wholesale federated option could be one decomposition choice.

The service/resource boundary would set the limit of customer/CSR management visibility, and also the visibility a retail provider had into the service contribution of a wholesale partner.  Remember that every service/resource element is an intent model with those three Ps.  One of them includes the SLA the element is prepared to assert to its superiors, and every element at every level is responsible for securing that SLA either by selecting subordinates that can do it, or by providing incremental management practices.

The management practices are important because if we presume our service/resource boundary, then we would probably find that the network management and network operations processes, people, and tools would be directed to the resource layer, and the service management and OSS/BSS tools and practices at the service layer.  That would again open the possibility of considering the modeling and decomposition might differ on either side of that boundary, though I stress that I believe a single process from top to bottom would preserve management flexibility just as well.

I’ve tended to describe these models as hierarchies—a single thing on top and a bunch of decomposed subordinates fanning out below.  If you looked at the complete inventory of models for a given operator there would be a lot of “things on top”, and the trees below would often be composed of the same set of elements, with some adds and removals for each. That’s a form of the same kind of component reuse that marks modern software development processes.

One value of this complex “forest” of model trees is that we could define one set of service definitions that a customer might be able to order from a portal, and another that would require customer service intervention.  That would maximize self-service without risking instability.  In any case, the SLAs of the intent models would drive the portal’s management state, so the customer wouldn’t be able to directly influence the behavior of shared resources.

It’s also true that some “component reuse” would be more than just reusing the same model to instantiate independent service tenancies.  Some features, like the subscriber management or mobility management elements of IMS/EPC, are themselves multi-tenant.  That means that our modeling has to be able to represent multi-tenant elements as well as create tenant-specific instances.  After all, a federated contribution to a service might well be multi-tenant and as long as it did what the three Ps promised, we’d never know it because the details are hidden in the black box of the intent model.

We can’t say as much about the service layer as you might think, other than to say that it enforces commercial policies.  The real details of the service layer will depend on the boundary layer, the way that the service and resource policies and models combine.  There are a number of options for that, and we’ll look at them in the next blog in this series.

One of the challenges of transforming the way we do networking is the need for abstraction and the difficulty we experience in dealing with purely abstract things.  What I’ll be doing over the next week or ten days (depending on what else comes up that warrants blogging) is looking at the process of building and running the network of the future, as a means of exploring how technologies should be used to get us there.  I’m hoping that the process example will make the complexities of this evolution easier to understand.

We know by now that the best way to do transformation is to automate the service lifecycle from top to bottom, and the best way to do that is to model the services and decompose the models to drive software processes.  There’s probably not much disagreement on this, but there’s a lot of mystery in the area of how that can be done.  The goal here is to work to dispel some of that mystery.

The approach I’m going to advocate here is one that separates the commercial (service-domain) and technical (resource-domain) activity, and that is based on intent modeling and abstraction.  I’m a fan of top-down approaches, but in this case I’m going to start at the bottom because we have a network already, and the first test of any new network methodology is whether it can embrace where we are and so jump from that to where we want to be.

Network “services” at the high level are made up of two things—“pipes” and “features”.  A pipe is something that has two ends/ports and provides for the movement of information through it.  A feature has some indeterminate number of ends/ports, and the outputs are a complex function of the inputs.  Everything from access connections to the Internet can be built using these two things.

When network architects sit down to create a model of the network of the future, they’ll be building it from nuclear pieces that we’d likely recognize, things like “VPN”, “VLAN”, “Application”, and “Connection”.  The temptation might be to start with these elements, but a good software architect would say that you have to go back to the most basic form of things to standardize and optimize what you’re doing.  So “Connections” are “pipes”, and all of the other things we have listed here are “Features”.  Keep this in mind as we develop this.

Our network architects should start their processes by defining the things that infrastructure as it now exists can deliver.  A “network” today is a layer of protocols that has specific properties, meaning that it is a combination of pipes and features that combine to deliver specific capabilities.  I’ve called these capabilities Behaviors in my ExperiaSphere work, and they are roughly analogous (but not exactly so) with the TMF’s notion of Resource-Facing Services (RFS).  All of the technical pieces of current retail or wholesale services are Behaviors/RFSs.

An RFS should be functional, not procedural, meaning that it should describe what happens and not how it’s done.  If we have an RFS called “VPN”, that means in our convention that it’s a Level 3/IP private network feature with an unspecified number of access ports.  It doesn’t mean it’s MPLS or RFC2547 or SD-WAN; all of these are means of implementing the VPN RFS.  The same is true for our “Firewall” feature, our “IMS” feature, and so on.

When our network architects are done with their process, they’d have a list of the “feature primitives” that are used to create services based on current technology.  This is an important fork in the road, because it now defines how we achieve service automation and how we take advantage of the feature agility of virtualization.

The goal of service automation is to define a set of models and processes that will deliver each of our abstract features no matter what they’re built on.  That means that all mechanisms for building a VPN would be structures underneath the general structure “VPN”.  We have to define “VPN” in terms of its properties, its ports, and the parameters (including SLA) that it either accepts or asserts, then we have to insure that every mechanism for implementing the VPN supports exactly that set of things, no more or less.

Ideally, you’d think up your properties, ports, and parameters based on the functionality you’re describing, but in the real world it’s likely that you would do a rough cut based on foresight, then refine it as you subdivide “VPN” into the various ways you could create one.  Our team of network architects would probably take this approach, and at the end of their work they’d have a complete list of the “three Ps” for each feature.  This would become input into the work of network engineers who would take charge of the feature implementations.

A feature, as a high-level abstraction, can be implemented in any way or combination of ways that conforms to the high-level description (our three Ps).  In today’s networks, implementation variations are caused by geographic scope, administrative areas, technology or vendor differences, and so forth.  For a given feature, like our VPN example, the first step would be to list out the various implementation options and the way that a given service would be assigned a set of these options.  Thus, decomposition of an abstract VPN feature starts by examining the way that an implementation (or set of implementations) is selected.  For each, you’d then have network engineers describe the process of deploying the implementations they’re responsible for, and mapping between their parameters and those of the high-level feature.

The implementations referenced here would not need to be modeled or described in any specific way, as long as their model/description was suitable for decoding by something (a DevOps tool, YANG, etc.) and as long as the model could be referenced and activated by the high-level selection process just described.

I mentioned the policy-based selection of implementation alternatives, and this would make up what I’d call a boundary layer, meaning that in theory there is a set of processes that link retail services to network services, and could be considered to be divided among those two things in any reasonable way.  The only caveat is the requirement of isolation; you should never mix commercial and technical policies because that would risk setting up a brittle service definition that might expose implementations up in the service layer where they definitely don’t belong.  See below!

The other pathway from the high-level feature model inventory is to service architects who want to build new features, those that perhaps were not available with standard network devices but would be suitable for the application of virtualized features.  An example might be a publish-and-subscribe tool for event distribution.  The service architect would define the high-level feature (“PandS”) and would also provide the three “Ps” for it.  The result would then again be turned over to a network or server/software engineer for translation into a deployment and lifecycle implementation.

To return to an earlier point, it’s important in this model that the implementation differences that are reflected when decomposing the high-level objects have to be technical policies and not business policies.  What we want here is for the “Behaviors” or RFSs that are exposed by infrastructure are the boundary between the service domain and the resource domain.  Customer portals and customer service reps should not be making implementation decisions, nor should commercial issues be exposed directly to resources.  It’s OK to have parameters passed that guide selection, but these should be technically and commercially neutral.

I’ve noted before that I think a modeling approach like TOSCA is the best way to describe services, even ones that have nothing to do with hosted features.  However, you can see that since the decomposition of our RFSs or Behaviors into actual resource commitments is hidden inside the RFS/Behavior object, there’s no reason why we couldn’t let the decomposition be handled any way that works, meaning that it could take advantage of vendor features, previous technology commitments, etc.

If this approach is followed, we could build models of current services and describe those services in such a way that automated lifecycle processes could operate, reducing opex.  These same processes would also work with implementations of current features that had been translated to virtual-function form, facilitating the evolution to SDN and NFV where the business case can be made.

Some will say that by tapping off opex benefits, this approach could actually limit the SDN and NFV deployments.  Perhaps, but if it’s possible to utilize current technology more efficiently, we need to identify that mechanism and cost/benefit analyze it versus more radical transformations.

In the next blog on this topic, I’ll talk about the service layer of the model, and in the one following it the way that we could expect to see these two layers integrated—those pesky boundary functions.  The other topics will develop from these three main points; stay tuned!

There seem to be a lot of forces driving, suggesting, or inducing major changes in the networking industry.  As indicators, we have mergers at the service provider, equipment vendor, and content provider level, and we have proposed breakups of hardware and software at the equipment level.  Another hardware player broke itself to death, selling pieces to multiple parties.  To this mix, add in the fact that it’s clear that in the US, regulatory policy is going to shift decisively, and you have a recipe for some chaotic times.  Let’s look at what’s happening, and how it might all shake out.  I warn you that this is a long blog that covers a lot of territory, but this is our industry and we have to work through it thoroughly.

The heart of the present situation is the “Internet business model” that evolved from a time when (sadly) Wall Street analysts were framing (accidentally) the structure of the industry of the future.  In the ‘80s, when the Web was driving massive changes in consumer data usage, the Street took it on themselves to value ISPs based on their subscriber count.  One picked $50,000 per customer, for example.  Needless to say, it didn’t take ISPs long to realize that the key to getting a high valuation for your stock was to have a lot of customers.  This led to the “all-you-can-eat” and “bill-and-keep” model of Internet pricing, a sharp change from the traditional settlement model of earlier data services.

That current business model divides the Internet into the “top” and “network” players.  In a pure bill-and-keep world, the former players (including consumers) pay to attach to the Internet via their ISP, but not for what they send or receive.  The ISPs bill, and keep what they get, which from almost the first has meant that priority services are difficult to create, even if regulations permit it.  You can’t expect others to offer your traffic priority when you got paid for the feature and they didn’t.  The wireline world says that you can use unlimited data, and that’s sometimes true in wireless broadband too, but in both cases, you may have your speed throttled at some point if you go over a limit.  That’s the “all-you-can-eat” part.  The marginal cost of bandwidth is near-zero.

In this world, fortune has favored those in the top layer, the OTTs, because they provide the meat of the service.  What separates the Internet from the prior data services is that the Internet is really not a communications service but a content service.  However, it overlays on a communication/connection service, and the underlay (network) part is available to all.  OTT versions of underlay services (VoIP is an example, as is the Internet VPN) have competed with the service providers’ native services, and the ISPs have little ability to recover the cost of the incremental traffic generated either by cannibalizing their current services or carrying new OTT services.  The result has been a steady decline in revenue per bit carried.  That puts pressure on capex, which puts pressure on the network equipment vendors.

If content is the service, then it makes sense for service providers to want to buy content producers.  Comcast and NBC, AT&T and both DirecTV and Time Warner, are examples of buying yourself higher on the value chain.  So, arguably, is Verizon and Yahoo.  On the network equipment side, we’ve seen partnerships like the Cisco/Ericsson relationships and outright mergers like Alcatel-Lucent and Nokia.  That hasn’t solved the problem of capex pressure on buyers, and that means network operators are turning to lower-cost commodity hardware and working hard to avoid vendor lock-ins.

The lock-in piece is especially problematic to bigger vendors, who rely on symbiosis among their product lines to give them control of large deals.  This has been a worry for network operators for a decade, and it’s the driving force behind AT&T’s Domain 2.0 approach to dividing networking into pieces that assign vendors to limited roles.  Companies who try to take a big bite out of network functionality are hit hardest, and smaller players hardest of all.  Brocade had big dreams and big opportunities, but not big enough thoughts and execution.

The commodity hardware issue is an offshoot of a bunch of trends, not the least of which is the Facebook-driven Open Compute Project, but which also includes hosted routing and NFV.  If network equipment vendors are going to lose the hardware part of their revenue stream anyway, it could make sense to unbundle the network operating system software and sell it separately.  Otherwise there’s a rampant open-source market stimulus, and you lose everything.  Some vendors have already taken this approach, at least in part, including Cisco rivals Arista and Juniper.

Cisco is now reportedly looking at a revolutionary step, unbundling its hardware/software elements (Cisco says this is “unsubstantiated” which isn’t exactly the same as false).  I think that this move would represent a logical response to conditions, but I also think that if it’s done it will validate the commoditization of network hardware.  Just because Cisco will reportedly offer a code-named Lindt standalone network software stack to run on white-box gear doesn’t mean that everyone will buy it.  If you admit to commodity hardware, you admit to interchangeable software.  The capital burden of the hardware doesn’t lock buyers to you anymore.  True or not true in Cisco’s case, unbundling software from hardware has started among competitors, and is a sign of an industry facing pressures that can only mount over time.

I’ve outlined the business-model backdrop for all of this because the business model issue is what’s driving things, and that drive will continue.  Because the regulatory changes are very likely to impact the business model of the Internet, the future of networking will depend on how both providers and equipment vendors respond.

The latest round on the regulatory side is the undoing of the extensions in Internet privacy that were put into place by the Obama administration in its last days.  These rules would impose restrictions on how the ISPs themselves can collect and use personal data, and they were opposed by many from the first on the basis that they continued the policy of offering benefits to the “top” of the Internet that were denied to the bottom, or network, providers.  They were not in effect at the point of repeal, so what’s the impact?  It could be a lot.

Service providers are heavily regulated and thus regulation-driven in planning.  Having seen the writing on the wall with respect to personal data, they either stayed out of the ad game or dabbled in it by buying up OTT companies (Verizon and Yahoo come to mind).  If the ISPs have the same right to collect personal data without consent as the OTTs like Google and Facebook, then they could be competitors in the ad-driven or personal-context-driven services spaces.  Even more significantly, the overall regulatory trends both here in the US and internationally seem to be shifting toward a more balanced model (which by the way has been recommended by experts all along).  Such a shift might turn over things like prohibitions on paid prioritization and settlement.  It could change literally everything, and that is the point on which the future turns.

“Could”, because relaxing regulations in general could lead operators to believe they’ve been given a new lease on connection-services life, not a new opportunity to look beyond them.  Whether we’ll continue to see commoditization and consolidation or a new age in networking will depend on whether operators can see a clear path to those new opportunities.  If they don’t see one, they’ll fall back—and fall literally as an industry—on the familiar.

Both network equipment vendors and service providers are victims of decades of inertial, supply-side-driven, behavior.  They fear competition more than they seek opportunity, and that is true on both the seller and buyer sides.  Now we have what might be the killer opportunity, a chance for the turtle to grow muscular hind legs to overcome the inherent race disadvantage.  Will the operators seize that opportunity?  Will vendors encourage them?  We don’t know yet, and whether they do or not determines whether network equipment stays separate from experience-based services.  That determines whether it’s valuable, and whether vendors who provide it can prosper.

The key to vendor success in the future isn’t to divorce hardware and software to take advantage of and promote commoditization at the same time (at best a zero-sum game, and probably worse than that), but to focus on what operators are going to need to have to address their own problems (which vendors and operators know today) and opportunities (which both parties need to think about, in terms of where they are and how they might be exploited).

What are the impacts of being cleared to collect personal data?  First, the collecting has to happen, and if you’re not a party to the relationship directly (you don’t own Facebook or provide an alternative) then you have to be able to detect what’s happening from the outside.  What are the implications of using the interior data of a web relationship with a third party?  Second, you have to be able to monetize what you learn, which means that you either have to support ad-sponsored stuff or you have to offer paid services whose personalization is based somehow on collection of information.

The collecting part of this is really problematic because the interior data is already largely encrypted via https.  Further, it’s not clear that just having Congress void the FCC ruling on collecting private data would give ISPs the right to actually tap the conversation.  They would very likely have to limit themselves to learning things from the visible aspects of the relationships—the IP addresses that they necessarily see, and the DNS requests that they also see and in most cases actually field (your default DNS is usually set by your access provider, though you can override that).  What can be gleaned from the minimal data actually available.  Alone, not much—far less than the OTTs who provide the services being used would have available.  In combination, perhaps a lot.  If you know everything the user has going on, even at a superficial level, you have context.

Ad personalization is all about context.  Personalized services are all about context.  There is surely an event-creating process associated with getting data that new regulations would allow you to get, but the bigger problem is making it valuable.  The irony is that if operators had looked at the IoT opportunity sensibly, they’d have seen that the correlation of contextual information is the real gold mine in IoT too.  They might then have seen that common technology features could support IoT and their new ad opportunity.

New ad opportunities are nice, particularly if you see your current competition being created and funded by that source, but advertising is still at a zero year-over-year growth rate, and online advertising isn’t doing much better.  It’s also true that there is little opportunity for ISPs to snoop into web streams; all it takes is an HTTPS session to stomp that out.  There is an opportunity for operators to digest information they get from Internet addresses and, most of all, from DNS hits.  There’s an opportunity to correlate voice/SMS session data with other things like movement of the user, and to contextualize voice/SMS contacts with subsequent searching and other web activity.  Operators can share in that, but they can’t own the space because the actual providers of the services have the edge, those OTTs who have created social media and web video.

This is where the vendors need to start thinking.  Contextual data from a lot of sources, generated as events and combined using complex event processing, is the only way that the regulatory shift can really benefit the network operators, unless they want to actually compete with OTTs.  If that’s what they want, then they’ve always had the option.  Look at Verizon and Yahoo (again).

The contextual opportunity—both from the service context side and the IoT side—are also probably the last hope of operators and network vendors to pull the industry out of commoditization.  Even if you could improve operational efficiency with service automation, you don’t have anything more than a quick fix to the profit-per-bit problem.  Only new revenue can save you in the long term.  My modeling has consistently said that there is over nine hundred billion dollars per year in new opportunity that could be exploited by network operators.  None of it comes from enhanced versions of connectivity and transport services—it’s all from carrier cloud.  That’s already transforming vendor business, driving more data center switching while routing is under pressure.  If vendors think realistically about what carrier cloud will mean, they can be a player and even a driver in addressing that new revenue.  If not, then either another vendor will step up and win, or operators will go entirely to open-source software and commodity hardware.

Huawei’s sales were up this quarter, and profits were stagnant.  Even the network equipment price leader can’t make a business success out of the current market, and it’s only going to get harder to do that if “the current market” is what you think will save you.  On the other hand, the future is truly bright.