Standards documents are definitely not entertaining reads, even important ones. The ETSI ISG published its “Report on SDN Usage in NFV Architectural Framework” prior to the last ISG meeting, and I’ve been reading through it. There are a lot of interesting and useful things in it, and some things that I think are problematic, but it’s hard to dig them out.
Since the topic of SDN/NFV symbiosis is critical, I want to try to restructure the view to make it easier to absorb, and comment on some of the recommendations. “Recommendations” is important, because this document was really aimed at supporting and evolving the NFV-to-SDN relationship, not coming to all the necessary conclusions.
We all know that the recognized vision of SDN is the conversion of abstract application-level connection requirements to commitments of network resources to fulfill them. You might, in high-level SDN-speak, say “Give me these nine points on a LAN or subnet” and expect the necessary OpenFlow commands would be generated (by an SDN controller) to bring that about.
One of the challenges that this simple vision of SDN brings to the SDN/NFV symbiosis discussion is that this capability can be mapped into NFV in a variety of ways, which I think are best viewed as being “dimensions” of a relationship:
- The “who’s the user?” dimension. Is NFV a user of SDN service, is the target user a customer or another application, or are both possible?
- The “who deploys?” dimension. Is NFV using SDN facilities already in place, or is NFV expected to deploy/manage SDN elements?
- The “who federates?” dimension. Are multiple SDN domains connected within SDN and so provide multi-domain services, or is NFV responsible for federation across SDN domains?
I’m going to try to organize these dimensions into something coherent that can still be related to the ETSI material. If you want to follow that relating process yourself, please refer to sections 4.3 and 4.4 of the ETSI document.
SDN could broadly be seen as an NFV resource, an NFV service, or both. If SDN is a resource then it’s represented in some way by a Virtual Infrastructure Manager, and that relationship could involve “deep” or “shallow” placement of the SDN controller. In deep placement, SDN is simply an in-place connection capability like that created by switches or routers, which is why the ISG says that this is where SDN acts like a physical network function. In deep placement, NFV wouldn’t “see” SDN directly at all. The VIM would presumably ask a lower-level management system for connectivity and that system would interact with SDN to create it. In shallow placement, the SDN controller is part of the VIM itself, meaning that SDN control is a VIM service extended downward to compatible devices.
If SDN is a service of NFV, then the implication is that NFV is offering not just connectivity that happens to be available using SDN, but offering SDN itself. To me, that means that NFV is offering an SDN controller and SDN vSwitches as VNFs and that the “SDN service” would look something like a service chain, where the controller VNF has to be connected to the vSwitch VNFs in some way. NFV would also have to offer management, including horizontal scaling if that were a capability to be included.
The more difficult case is the “all of the above” case. In theory, NFV could deploy SDN-as-a-service and then utilize the connection features the new “SDN service” offers to build other services. This is the concept I called “Infrastructure Services” in both CloudNFV and ExperiaSphere. The challenge here is that SDN is first deployed and then composed as though it had been there all along, which implies that the deployment of an infrastructure service could create a service catalog entry, a VIM, or something else. How this gets done dynamically in such a way that other services could reference it isn’t covered in the ETSI specs.
Customer targeting and deployment responsibility are obviously related fairly closely. They may also be related to the functional scope of the SDN controller being used. For example, where the controller is designed to use multiple southbound protocols to allow an abstract service to be built using a mixture of SDN and legacy devices, that higher-level role argues not only for a “shallow” definition of placement of the controller but also for a broader-scope VIM. In other words, as the SDN controller gets more functional it can absorb the functions of several VIMs, or the need for a VIM to separate service requests by domain. In the extreme case you could argue that a supercontroller might be able to fulfill any connection request through a single VIM.
This leads us to the federation dimension. If a service is to be extended across operator boundaries or other domain boundaries, there are two basic possibilities. One is that the service model decomposes into elements that are linked to a series of VIMs, some of which are out of domain and referenced logically. In this case, federation is done by NFV’s MANO-or-MANO-like elements. The other possibility is that SDN makes the whole connection across all boundaries look like a single-domain service, in which case it’s SDN’s responsibility to manage the federation.
The determining factor here is likely to be the extent to which federated elements are purely connection elements, meaning whether a cross-domain service requires only connections in other domains or hosting of VNFs in other domains. If the latter is the case, then it probably doesn’t do much good to be able to offer SDN connectivity services that span domains. It would be smarter to let NFV manage federation.
These issues aren’t totally clear in the document, but they’re not easy to be clear on and I think they’re covered respectably. There are some important areas where I think the document fell short.
The most significant of these is in the area of intent modeling. The document recognizes that some of the bodies in the SDN space (ONF and ODL) have recognized intent-modeled northbound interfaces. It also comments that it’s recommending that intent-modeled interfaces be further studied for NFV. Gosh, people, we’re way beyond the “further study” point here. The SDN alignment document clearly shows that intent modeling is the way everyone is going, which means that before NFV does anything else in terms of connection service definition, or perhaps does anything else in service modeling at all, it needs to adopt an intent-model framework for all its abstraction/virtualization interfaces.
Every day, the ISG is working on stuff that is at risk to being a barrier to intent model adoption, or at least at risk to creating unnecessary work in harmonizing pre-intent-model recommendations with intent modeling. This document, to me, shouts out a warning to the ISG to stop diddling on intent modeling and bring that forward immediately as the basis for the interfaces between MANO and the VIM, between NFV and SDN, between OSS/BSS and MANO, and for service modeling in general.
Second, the recommendation of the document is that there be an interface defined between the SDN controller and MANO. This implies that NFV somehow has to deal with the controller differently from other applications, and I do not believe that’s necessary. In fact, I think it’s risky. First, we don’t have such an interface now, and how much work and time will be expended creating one is unknown. We’re running out of time to make a business case for both SDN and NFV. Second, it forces us to address a truly knotty problem, one I’ve described before, which is the difference between service address space and control/management address space.
Security and stability for NFV and SDN alike depend on being able to separate control and management traffic from the user/service data plane. If that’s not done then the foundation interfaces of SDN and NFV are subject to attack/hacking. Improper address space management also risks contamination of tenant separation strategies. This raises questions with respect to SDN’s mission in NFV, or in how NFV handles it.
The existence of a MANO interface to an SDN controller mandates connectivity with MANO, but how can that be harmonized with the fact that the controller is not a real part of NFV? If we deploy a controller for multi-tenant use (whether NFV deploys it or not) we have to ask whether the MANO connection provides for separation of the tenants, or whether it would be possible that the activities of one service relating to SDN control might impact others.
If we deploy SDN using NFV, and we have to make the connections to the vSwitches or instantiate copies of the controller, we’re in particularly deep water. In most case, probably, we’re overlaying SDN forwarding on top of some established (likely L2, Ethernet) connectivity. Is that connectivity then shared? Remember, a new SDN controller is an application of VNFs, but it also may support multi-tenancy.
I think most of the questions on SDN/NFV coexistence could be addressed in the context of intent modeling. I think intent modeling would also go a long way to defining an open framework for NFV, which we clearly don’t have now, and it would even help to build a business case. The SDN/NFV paper is right to call out the need to look at intent modeling, but it should have been in there from the start. If we kick off processes to address intent modeling and address spaces now, it’s better than nothing, but it’s going to take time and operators want something to happen with NFV this year.