Consolidated Network as service and WAN services

Cloud-computing explosions have also brought about the explosion of the term "service", which makes it hard to distinguish between "services". The network as a service seems to be considered superfluous (if it is not a service, what the service provider is selling?) and it is undefined, but we cannot ignore it because it represents the future of the network.

The network as a service concept originates from cloud computing and specific support for virtual networks in OpenStack, and the quantum interface describes how to create a network connectivity service to support the connection between cloud computing and storage services.

The relationship between the network, the service and the physical network

Here the network is the service is created to support the application of the virtual network. There is a clear distinction between connecting to a fixed location, such as a headquarters, to a traditional network of branches, servers, servers, and servers to storage. If Naas is an application network, an important issue is how it is associated with network infrastructure and network services. The answer to this question is the key to turning Naas from a good idea into a "real" Naas.

If the network is the source of services in the cloud, then the first practical Naas choice is the virtual coverage network. Network software vendor Nicira (acquired by VMware in 2012) developed a fully software-based Nicira NVP virtual network architecture that can be controlled by the Cloud API. A virtual overlay network is a combination of a tunnel (using a suitable tunneling protocol, including GRE) and a virtual switch, which creates a network above the physical network devices (switches and routers).

Given that the network is a service that is deployed and controlled by software, these applications are essentially transparent add-ons to the actual network equipment and services that create connections. Virtual overlay Networks Subdivide the connections that are generated by real services and infrastructure, but do not create connections or change service contract relationships. This is a perfect way for users who want to dynamically apply network control but do not want to change the way their site is connected, how it is built, and what their network service contracts are.

Create a virtual network segment

If the network services themselves need to become more flexible and more application-driven, we need more development work to achieve this. Virtual Overlay network cannot create real service is an important limitation, because many people regard network as service as new flexible network service, but in fact, Naas's virtual overlay form can only subdivide real network/service-provided connection.

A virtual overlay network is not the only way to create a virtual network segment that controls connections. In Ethernet networks, standards such as VLANs and Vxlan can split real infrastructure into virtual networks, and network operators also provide virtual LANs and virtual private Network (VPN) services. The virtual network is not so virtual because it is created by a real device with real features. These features must be invoked by managing the Application Interface (API), which has both advantages and disadvantages.

The most obvious disadvantage of creating Naas for a specified device is the control software/cloud control device. This may require collaboration between the software/cloud as well as the network management system (quantum to provide this customization), which is achievable. It is important to ensure that the network and services of the specified device contain all the key elements of the application network. Applying a virtual network typically requires a DHCP service for address assignment, DNS for address resolution, and a default gateway (router) to connect the application network to the user.

Consolidated Network as service and WAN services

Virtual network coverage and the Naas of a designated device form still need to combine a set of static underlying wide area network (WAN) services, so many people believe that the Naas model does not yet achieve full flexibility. All traffic on the Naas service must be within the capacity of the actual network, including WAN links. Some people believe that the Naas of the virtual network coverage form is not integrated with the device, making it more difficult to manage. The NMS tool simply treats the Naas service as traffic. Full flexibility to achieve Naas means consolidating the Naas concept with WAN services.

If there's one final problem with Naas, it's not easy to order Naas from a service carrier. At the technical level, operators can provide users with a management portal to build, modify, and remove virtual networks at the level of LAN (VLAN, Vxlan) or VPN, but this type of dynamic mechanism will be in line with long-established industry pricing practices (based on traffic, number of site connections, and contract deadlines) Conflict.

Will users accept higher prices for Naas? Or do operators offer attractive prices but do not promise customer service? The market is still open to questions about these issues.

However, the problem is not just these. If virtual networks "develop recklessly" without considering the impact of their traffic on "real" networks, virtual network coverage and Naas will bring quality of service (QoS) issues to all network users. If the internal department had inadvertently ordered something very expensive when it started their own application network, the carrier-based Naas could cause huge costs for the business. All this means that the Naas service must have some kind of policy management system to control misuse, which will ensure the rapid development of Naas, not just a hopeful and more flexible network model.

(Responsible editor: Fumingli)