Service modeling has been a recurring topic for my blogs, in part because of its critical importance in what I’ve called “service lifecycle automation” and the industry now calls “zero-touch automation”. Another reason it’s recurring is that I keep getting requests from people to cover another angle of the topic. The most recent one relates to the notion of a “service topology”. What the heck is that, many are wondering. Good question.
A “service” is a cooperative relationship between functional elements to accomplish a systemic goal that the service itself defines. The “functional elements” could be legacy devices like switches, routers, optical add-drop multiplexers, and so forth. In the modern software-defined age, it could also be a bunch of virtual functions, and obviously it could be a combination of the two.
A service model, then, could be seen as a description of how the functions cooperate, a description of their relationship. In a “network” of devices, a service model might be a nodal topology map, perhaps overlaid with information on how each node is induced to behave cooperatively. This is our traditional way of thinking about services, for obvious reasons. It assumes that the service is a product of the network, which is an entity with specific structure and capabilities. In our software-defined era, things get more complicated, and at several levels.
Yes, you could visualize a future service as a collection of virtual devices that mapped 1:1 to the same traditional boxes in the same physical topology. That could be called the “cloud-hosted node” model. NFV proposes a different approach, where virtual functions that are derived from physical functions (devices) are instantiated per-customer, per service. Thus, a service isn’t always coerced from communal nodes; it can be created ad hoc from service-specific hosted elements.
The second level is the stuff that we’re hosting on. In software-defined services of any sort, we have a pool of resources that are committed as needed, rather than dedicated and specialized boxes. Since the pool of resources is shared, we can’t let the individual services just grab at it and do what they want. We need some notion of virtualization of resources, where everything thinks it has dedicated service elements of some sort, but all actually pull stuff from the pool. The pool is a “black box” with no structural properties visible.
Down inside the resource-pool black box, we still have physical topologies, because we have servers, switches, data centers, trunks, and other stuff that create the “resource fabric” that makes up the pool. However, we now have a series of virtual topologies, representing the relationships of the software elements that make up the services.
While you might be tempted to think of a virtual topology as the same kind of trunk-and-node structure we’re familiar with from switch/router networks, just translated to “virtual switch/router” and “virtual trunks”, that’s not logical. Why would someone want to define, at the service virtual level, a specific virtual-node structure? A VPN might really be a collection of cooperating routers, but to the user it would look like one giant virtual router. That’s what the virtual-service topology would also look like.
A virtual-service, or let’s face it, any service, topology is really a functional topology. It describes the functions that are needed, not how those functions are delivered. When we have to pass through the boundary between services and the resources, we need to map to the real world, but we don’t want to pull real-world mapping specifics into the virtual service layer. Thus, the functional view of a VPN would be “access-plus-VPN”.
This lets us shine some light on issues that are raised periodically on service modeling. Most would agree that there are two contenders today in the model space—TOSCA from OASIS and YANG. In terms of genesis, TOSCA is a data modeling language that was developed to describe how to configure a physical nodal topology of devices. TOSCA is a declarative language to describe (as the acronym “Topology and Orchestration Specification for Cloud Applications” suggests) the deployment of components in the cloud. If you take the root missions as the current definitions for each language, then they both belong to the process of decomposing functions into resource cooperation. The more “functional” or software-defined you are, the more TOSCA makes sense. If you see nothing but physical devices or hosted equivalents thereof, you can use YANG.
What about the service layer? There, you’ll recall, I suggested that we really had a function topology—“access” and “VPN” in the example. You could say that “VPN-Service” as a model element decomposes into “VPN-Access” and “VPN-Core”. You could say that “VPN-Access” has two interfaces—customer-side and network-side, the latter of which connects to one of a variable number of “customer-side” interfaces on “VPN-Core”. We could visualize this as some kind of pseudo-molecule, a fat atom being the core and a bunch of little atoms stuck to the surface and representing the access elements.
It’s perfectly possible to describe the service structure as a series of intent model objects in a hierarchy, and use something like XML to do that. The initial CloudNFV project did that, in fact. However, it’s also possible to describe that structure in both TOSCA and YANG too. I favor TOSCA because it is designed for the deployment of hosted elements, not for the configuration of semi-fixed elements (but again, you can probably use either).
But let’s leave modeling religious arguments and return to our hierarchy (however we model it). A high-level element like “VPN-Access” or “VPN-Core” could be decomposed in a number of ways depending on the specific nature of the service, things like where the users are located and what the infrastructure in that area looks like. Thus, we could expect to see some possible decomposition of each of our high-level elements based on broad things like administrative domain/geography. When we know that a specific user access point in a specific location needs “VPN-Access” we would expect to see the model decompose not into other models, but into some configuration or deployment language that can actually commit/coerce resources.
The virtualization layer of our structure creates a kind of boundary point between services and resources, and it’s convenient to assume that we have “service architects” that build above this point and “resource architects” that handle what happens below. If we build services from collected resource behaviors, it makes sense to presume that resource architects create a set of behaviors that are then collected into model elements at the boundary point, and are visible and composable pieces of the service. There may be a model hierarchy above the boundary point, as illustrated here, and there might also be a hierarchy used to organize the resource behaviors according to the kind of infrastructure involved.
In this example, we could say that “VPN-Access” is such a boundary behavior element. Every administrative domain that provides access to users would be expected to provide such an element, and to decompose it as needed to create the necessary connection for the full set of users it offers such a service to. As this decomposition and commitment progresses, the functional/hierarchical model of the service creates a physical topology that connects information flows. VPN-Access trunk goes into VPN-Core port. This connecting has to be an attribute of the deployment (or redeployment) of the service.
What this says is that there is a service topology at two levels, one at the functional/descriptive level, and one at the resource/connection level. The first creates the second, and mediates the ongoing lifecycle management processes.
The boundary between these two layers is what’s really important, and yet we’ve had almost no industry focus on that point. Operators need to be able to build services from some specific toolkit, even in a virtual world. Operators need to be able to divide the “operations” tasks between the service side (OSS/BSS) and the network side (NMS, NOC). Anyway, in any virtual world, it’s where concept meets reality that’s critical, and that is at this boundary point.
What might live here? Let’s take a specific example: “Firewall”. I could sell a firewall feature as an adjunct to VPN-Access, but depending on how it was implemented in a given location, the abstract notion of Firewall might decompose to a VNF, a physical device, or some sort of network service. Above, it’s all the same, but where the function meets the resource, the deployment rules would vary according to what’s available.
We could probably gain a lot by forgetting the modeling-language issues for the moment, and focusing on what happens at the virtual service/resource boundary. Each language could then present its credentials relative to that point, and we could see how it frames what we do now, and what we expect from the network of the future.