I did a blog early this week on the foundation for an agile service-model approach. Some of my operator friends were particularly interested in this topic, more than I thought frankly. Most of it was centered on how this sort of model would be applied during the routine processes of building and selling services. If service agility is the goal, then operators want specific knowledge of how a given strategy would impact the “think-it-to-sell-it” cycle. So let’s set the stage, then dive in.
What I’m suggesting is that we define services in a series of hierarchical modeling steps, with each step based on an intent model that offers a from-the-consumer-side abstraction of the service/feature being defined. For network services and features, we could assume the model had a standard structure, which defined FUNCTIONAL-PROPERTIES for the model, and INTERFACES that allow for connection of models or to users. The FUNCTIONAL-PROPERTIES would always include an SLA to describe performance and availability.
As I noted in the earlier blog, you can build basic connection services with three broad models—the point-to-point (LINE), multipoint (LAN), and multicast (TREE). A bit of deeper thinking would show that there could be two kinds of TREEs, the M-TREE that’s true multicast and the L-TREE that’s a load-balance point. You could divide other connection service models too, if needed.
For more complicated features, I proposed two additional models, the IN-LINE model for a service that sits across a data path (firewall is the classic example) and the ON-LINE model for a service that attaches like it’s an endpoint, as DNS would.
INTERFACEs are the glue for all of this. Depending on the functional model of the service we might have a single class of interface (“ENDPOINT” on a LAN) or we might have multiple classes (“SENDER” and “RECEIVER” on multicast TREEs). Connection services connect endpoints so you’d have one for every endpoint you wanted to connect, and you might also have Network-to-Network Interface (NNI) points to connect subsets of a service that was divided by implementation or administrative boundaries.
Given this setup, we can relate the process of selling or building a service to the specific model elements. My assumption is that we have a service architect who is responsible for doing the basic building, and a service agent (the customers themselves, via a portal, or a customer service rep) who would fill in an order for a purchase.
If we started with an order for, as an example, an IP VPN, we would expect the order to identify the sites to be supported and the SLA needed. This would populate a query into a product catalog that would extract the options that would meet the criteria. In our example, it might suggest an “Internet tunnel” VPN using IPsec or something like it, or a “provisioned” VPN. It might also suggest a VLAN with hosted routing. All of the options that fit the criteria could be shown to the ordering party (user or customer service rep) for examination, or they could be priced out first based on the criteria.
If we assume that the provisioned option was selected, the order process might query the customer on whether additional service—like firewall, DNS, DNCP, encryption, application delivery control, or whatever—might be useful. Let’s assume that a firewall option was selected for all sites.
The next step would be to decompose the order. The “IP VPN” service would logically be made up of a series of access LINEs to LAN-IP-VPN INTERFACEs. Because we have a need for a firewall, we’d create each LINE as an access segment, an IN-LINE firewall component, and a VPN connection segment. Or, in theory, we might find one outlying site that doesn’t have a suitable place to host a cloud firewall, so it would get CPE that had local function hosting.
If the VPN spanned several geographies, we might decompose our LAN-IP-VPN object into a series of NNI-connected objects, one for each area. We’d then build per-area VPNs as above and connect them.
You can see that the other direction might work similarly. Suppose a service architect is looking to build a new service called an INTERNET-EXTENDED-IP-VPN. This service would combine a LAN-IP-VPN with an Internet tunnel to an on-ramp function. The architect might start with the LAN-IP-VPN object, and add to it an ON-LINE object representing an Internet gateway VPN on-ramp. The combined structure would then be re-cataloged for use.
Any given object could decompose in a variety of ways. As I suggested, we might say that a customer who wants an “IP VPN” of ten sites or less within a single metro area would be offered a VLAN and virtual router combination instead. If those conditions were not met, a different option would be selected. Service architects would presumably be able to search the catalog for an object based on interface needs, functional needs, and SLA. They could assemble the results into useful (meaning sellable) services.
The initial objects, the bottom of the hierarchy, would transform network or software behaviors into intent models for further composition into services. NFV VNFs are examples of bottom-level intent models, and so are the physical devices whose functions they replicate. You can create features by composing the behaviors that are needed into a model, then put it into a catalog for use. The FUNCTIONAL-PROPERTIES SLA can include the pricing policies so the service would self-price based on the features it contains, the number of interfaces, the specific performance/availability terms, etc.
I don’t mean to suggest that every service can be built this way, or that I’ve covered every functional, topological, and interface option. I just want to demonstrate that we can do service-building using object principles as long as we make our objects conform to intent modeling so we can hide the details of implementation from other higher layers. Policies can then guide how we map “intent” at a given layer to a realization, and that realization might still be a set of “composite objects” that would again be modeled through intent and decomposed based on policies.
Operators tell me this is the sort of thing they want to be able to do, and that they want to understand how both composition of services and decomposition of orders would take place. Interestingly they also tell me that they don’t get much if any of this sort of discussion from vendors, even those who actually have some or all of the capabilities I’ve presented in my example.
Very early in the NFV game, one of the Founding Fathers of NFV told me that to be meaningful to operators, any NFV solution had to be framed in the context of that think-it-to-sell-it service lifecycle. That lifecycle is where the benefits lie, particularly the benefit of “service agility”. We have solutions in this space that work, but few of them are vertically integrated to the point where they can address evolving SDN/NFV and legacy components and can build current and emerging service models. None, apparently, are well described to the buyers. The fact that there’s so much interest now in intent modeling and its role in service agility is a great sign for the industry—a sign we might finally be listening to those early words of wisdom.