I’ve talked about service modeling and lifecycle automation, and about the software that’s needed to make a modeled service effective. It’s time to look at another related issue, which is the issue of just what you’re orchestrating. While it’s popular to talk about “cloud-native” technology for network features, the cloud is an application hosting technology at its core, and networks and network features aren’t the same thing at all, even at the most fundamental level.
I’ve looked at a lot of user applications of cloud computing, containers, and Kubernetes, and one thing that strikes me is that the great majority of them are characterized by one word; unanimity. There is one resource pool, one administration, and one user domain. If you look at the world of network services, you find three distinct domains, the interplay of which frames the reality of any service deployment.
The first of these domains is the service domain. Where is the service to be offered? This question is usually easy to answer but that makes it easy to ignore. The scope of a service target sets the boundaries of the area where resources will necessarily be consumed. That frames the question of the way the other domains interact to set orchestration requirements.
The second domain is the administrative domain. Who controls resources; has the right and ability to manipulate and allocate them? Where a service domain crosses multiple administrative domains, it indicates that the service will require some inter-provider coordination or the use of a generally available resource like the Internet. Administrative domains can fragment resources, and when they do it fragments orchestration. Administrative domains are also fragmented; in a service there’s a single “seller” and potentially multiple “partners”, with the former having service contract/SLA responsibility to the buyer.
The resource domain is the last, bottom, of our three domains. Resource domains are divided by a number of factors in an abstract sense; “network” and “hosting” are examples. In the real world, the meaningful distinction is between control zones, resource collections that can be manipulated through a single API or management application. The big control-zone challenge is that network requirements and hosting requirements are interdependent; you have to connect a hosted element where it’s been placed, so changes in hosting change networking. Similarly, you have to replace a hosted element if the network connection to it is lost and can’t be recovered.
The reason these domains are important is that they impact the way that service lifecycle management can be automated through orchestration. That’s true both for technical reasons (the examples I’ve given above) and for reasons of sales/marketing.
From the very early days of networking, operators separated the “business” side of networking from the technical operations side. In a typical telco, the OSS/BSS systems form the basis for the business side and the NOC/NMS the basis for technical operations. This separation is reflected in the TMF’s vision as well, including the way that the TMF service model or SID divides things into “customer-facing” and “resource-facing” services, and calls the thing that gets sold a “product” rather than a “service”.
I’ve carried the separation through in my own work, separating my ExperiaSphere model into a service and resource domain, but the TMF move is to me the compelling one. The TMF represents the OSS/BSS community, which for operators is the CIO organization. Network operations falls under another unit completely, and so blurring the boundaries between those two domains would mean somehow unifying behavior of groups that have been separated since Bell talked with Watson.
The administrative domain then looms as a perhaps-decisive area to consider. A number of questions emerge from that consideration, some of which relate to how making some changes on how we define the domain could impact the effectiveness of cross-domain orchestration.
Fundamentally, administrative domains are areas where inter-provider federation is required. This federation could consist of network-to-network interfaces (NNIs), the practice followed in the ‘70s with the X.25 and X.75 packet switching standard. It could also include the kind of service-element contributions envisioned by both the IPsphere Forum and the TMF SDF work fifteen years ago. This sort of thing deals with situations where the “administrations” involved are truly independent organizations, so it would also presumably cover any relationships with fully separate subsidiaries, where regulatory mandates require independent operation.
The obvious question would be whether to combine the administrative interconnect and federation requirements with the control-zone separation mandated in the resource layer because of differences in technology or operations responsibility. If you need to exercise management through a different API channel, how much of a difference does it make whether the two APIs are within the same company jurisdiction?
One difference is the need for “cloaking” of infrastructure. Operators are happy to federate service components or entire services with partners, but not to cede those partners visibility into their infrastructure, or direct control over any part of that infrastructure. I’ve seen this point made consistently for decades, and there’s no reason to believe it’s going away.
Another difference is the extent to which the resources represented by a federated or separated API are abstracted. It’s often true that when an operator shares a truly federated service element with another, that element is represented only functionally and not at the implementation level. In short, where service elements cross administrative domain boundaries, the thing that crosses is almost a service-domain element. However, it has a direct resource relationship because it exists because it represents a “foreign” resource set. In my ExperiaSphere work, I reflected this by treating a federated/contributed element as the “boundary” object of the resource domain.
I think that may be the optimum way of dealing with those three domains; services and resources become the two operative domains, with the administrative domain represented by a special class of service object.
What happens with resource domain orchestration is the next question. The reason this is important is that the obvious division within the resource domain is the one between hosting and network. If this division of resources means a division in orchestration, then it would be necessary to define a higher orchestration level to envelope both. If we want to avoid this, we need to somehow limit the need for orchestration in one or both those divisions, and in any other divisions that might arise. There are two ways to do that.
Way number one is to abstract the resource management process by defining specific “services” that are available. We do this today with network connectivity based on presumptive Internet/VPN availability. In a sense, what happens is that the resource division is managed independently of the service domain, with the goal of “exporting” features that can be consumed functionally. This converts our resource divisions into what look like the federated features we used to subduct the administrative domain into the resource domain.
The second way is to incorporate awareness of and control over one resource division in the orchestration capabilities of the other. This approach is easiest to see in connection with hosting’s control over networking. Kubernetes provides for specification of a virtual network technology. If Kubernetes’ networking capabilities were expanded to include enough of the specific function-oriented requirements of networking (address assignment, URL decoding, connection/tunnel creation, etc.) then it would be possible to make connectivity subordinate to hosting. It’s not clear to me at this point whether this approach is practical, though Nephio might explore it as part of their mission.
I remain convinced that some sort of explicit service/resource model is essential, though. The relationship between hosting and network, OTT and on-net, and multiple standards initiatives and industry groups, are all very dynamic, and most of the initiatives are focused on lower-level orchestration and automation. That leaves a lot of variability and complexity that lives above any new tools and capabilities. I think we’ll eventually need to deal with it, and that it would be smart to think matters over now.