Intent-Based Networking

SDNAccording to the prestigious consulting firm Gartner, Intent-Based Networking System – IBNS – technology will be the go-to tool for managing data networks in a few years’ time. It is an evolution of Software-Defined Networking SDN / SD-WAN. 

(more…)

Juan Rodrigo: Development Engineer, is part of Teldat’s R&D Department. Within this department he is part of the General Software Development Department.

Application-Aware Routing related to SD-WAN

Application-Aware RoutingApplication-Aware Routing is a change to the way we think about how data packets should be routed through an IP network and is closely related to SD-WAN, Policy-based routing and the use of SLA’s – Service Level Agreements.

(more…)

Juan Rodrigo: Development Engineer, is part of Teldat’s R&D Department. Within this department he is part of the General Software Development Department.

Network Services based on Models

it modelNetwork service providers are currently up against a serious issue: how to improve agility when setting up new competitive services to meet the demands of the IT world. It’s not just about reducing network equipment expenses (needed to maintain competitiveness) but being able to deploy services at a much quicker pace.

IT is calling for increased bandwidth from service providers and this, in turn, brings on the relentless need for both new equipment and access technologies.  In addition to all this, network service providers have to compete against IT and content providers, giving rise to the definition of new services and how to get production moving as swiftly as posible.

Basically, all services are made up of appropriately configured groups of devices, be they physical or virtual, where installation and configuration is intensively costly. Device configuration processes today are based on encoded scripts written by experts. Process automatization is hindered by the wide variety of devices needed to adapt to new services and the cost involved. New devices inevitably mean new scripts and training.

In view of the fact that current procedures neither contribute to cost reductions (CAPEX/OPEX), or reduce the time involved in exploitation, it’s obvious a new approach is needed: focus on how to be a service rather than how to deploy said service.

Definition of a service must take place through formal language. The language will allow the service to be formally specified, giving rise to a model. The model must be recognized and interpreted by service provider management tools. And it’s patently obvious that current tools, OSS/BSS, are no longer valid: adaptation to a new model is crucial.

What is a Service Model?

As already referenced, the way to define a service is by using a formal language, permitting the service to be shaped, specifying the related and associative elements essential for the service. A service model does not specify an ultimate manufacturer for a specific device, nor the configuration schema.

The advantages to this approach are evident: a service can quickly and formally be specified using a library of elements to help create it.  The key, of course, lies in how to achieve the series of configurations needed to make the equipment work from a generic model.

The mechanism is by no means easy. However, once achieved, the process can be automated.  Essentially, this means the mapping of a service model to other models that formally specify the configurations required to deploy the service.  For each type of device, a corresponding configuration model is generated (always bearing in mind this does not guarantee validity for all manufacturers). Models, resulting from the mapping, can then be used to configure all devices involved in delivering the service.

Formal models defining the services and configuration models are currently sparking great interest in our sector. Initiatives, with this end goal in mind, are now appearing where direct involvement by equipment manufacturers is a must to meet the needs of providers.

Languages such as TOSCA, which fulfills the definition of formal and is used to define services, and YANG, fulfilling the formal definition of configurations, are particularly important.  The former is a language directly applied to the SDX/NFV world, while the latter, although not new, is beginning to appear in the portfolios of some manufacturers. NETCONF often accompanies YANG to transport and manage the configurations.

TOSCA (Topology and Orchestration Specification for Cloud Applications) is a language based on templates used to specify a service and its deployment in a Cloud infrastructure. The two basic elements in TOSCA for services are nodes and relationships.

A node may be a subnet, a network, a server, a service, an NFV, etc., while the relationship describes how the nodes connect to one another.  The definition also includes node lifecycles, policies and operational behavior.

The templates are specified through YAML, although XML was initially used.

TOSCA is currently the subject of much interest in projects such as Juju, Cloudify, IBM Cloud Orchestrator and OpenStack Heat.

YANG (Yet Another Next Generation) is a formal data model language widely used to define configurations and interfaces.

A configuration can be considered as a set of data that must be orchestrated and may depend on other values. YANG interprets configuration data as a hierarchical tree where each tree node either has a value, or is the point of connection to other nodes.  Each node is perfectly defined, together with its interaction with other nodes. An important aspect of YANG is the limiting constraints placed on node values, restricting the appearance of a node, or its value, over the appearance of other nodes, or values, in the hierarchy.

A generic YANG mode includes data for configuration, status, RPC (Remote Procedure Call) and notifications.

YANG is often accompanied by NETCONF (Network Configuration Protocol). This is a configuration transfer and management protocol. YANG models are directly mapped in XML and transmitted by NETCONF. This guarantees atomic transaction, where a result is correct or erroneous, and configuration management.  There are three types of configurations: Candidate, over which changes are made; Running, executing in the device and Startup being the configuration stored in the device and used in startup. A candidate configuration can transform into running and the latter, in turn, into startup, providing the changes to the configuration are considered correct.

Conclusion

Modeling, for both services and configurations, is a concept that network equipment manufacturers (for physical and virtual devices) must take into consideration, not in the long term, but now.  It is one of the main elements network service providers need up and running to survive IT competition.

Juan Rodrigo: Development Engineer, is part of Teldat’s R&D Department. Within this department he is part of the General Software Development Department.

SDN and NFV: New paradigm communication

Router cloud para oficinasDuring the past two years, a lot has been discussed about SDN/NFV technologies which promise major changes in the current communication scenarios. Many have pointed out that the current network status does not allow a quick evolution, new protocols or facilitate the implementation of new services.

We can consider the evolution of existing protocols or creating new ones that meet current needs, but introducing changes onto the network is very risky and no one wants to take these risks. The network has its shortcomings, but it works. This lack of interest in the evolution make some people say that the current Internet is ossified.

The implementation of new network services require operators to create overlays over the current IP network. These overlays (tunnels, VLAN…) are a first step towards the network virtualization.

Another problem operators are facing is that the life cycle of devices is becoming shorter as technology evolves very quickly. Hence operators are hard-pressed both from a technical and economical (CAPEX/OPEX) point of view.

SDN and NFV technologies are presented as a solution to the above problems.

What is SDN?

SDN is the acronym for Software Defined Networking. The idea behind this acronym is to manage data networks by separating the control plane from the data plane. Current networks are based on the use of black boxes (routers) in which the control plane (routing protocols, Access lists, policies,…) and the data plane (switching, routing) cannot be separated. This would require the operator to adapt the functional features of each manufacturer.

The SDN approach consists in centralizing the control plane, so that from this, the network operational logic made up by switches/routers (white boxes or bare-metal) can be established. From the central part (SDN controller) the switching/routing (Flow tables) will be implemented into the devices through protocols such as OpenFlow. The switching/routing operations are made based on the stored rules in the flow tables in the switches/routes.

Advantages of SDN

1.When the SDN software controller is placed in a centralized location. It will have a global vision of the network status and may take global decisions, allowing it to act simultaneously on all the devices’ flow tables. This is an advantage versus current dynamic routing protocols, in which any network status modification takes a finite time to spread and during which the network is in an unstable routing status.

2. Via the OpenFlow interface (southband API) the control and data planes become independent. This allows an easier integration of new devices to the network.

3.SDN allows part of the transport network for working traffic and another part of the transport network  for testing. This permits new features and services innovation. It’s an advantage of network virtualization that allows different types of traffic transportation without affecting each other.

4.Most of the SDN controllers on the market (OpendayLight, FloodLight,…) have an interface (northbound API) with Orchestration Software (OpenStack) from where the network policies are defined.

5. The SDN controller currently in production are written in Java, which reduces the slope of the learning curve.

What is NFV?

NFV is the acronym for Network Function Virtualization. The idea behind this acronym is as follows: As in a data center (DC), from orchestrators such as OpenStack, virtual machines (VM) can run when requested on any physical DC server, from which network features could work on any accessible server via IP. Virtualized Network Features/Functionalities (VNF) run within virtual machines or dockers. The set of servers on which VNFs run, make up the NFVI (NFV Infrastructure) network. These servers may be located at any point of the operator network.

Initially it is not necessary that NFV and SDN go together, even if they complement each other. In fact many of the objectives and advantages of both technologies are shared.

WAN accelerators, firewalls, security, balancers, etc are examples of VNFs i.e all applications that until now were performed through the appliances. Moreover, typical routing features such as IPsec, tunnels, dynamic routing can be added.

Advantages of NFV

There are shared NFV benefits which are obtained with SDN.

1.The necessary time to have a network feature up and running is considerably less, as a specific hardware is not essential. It is a software issue.

2.The VNFs run on off-the shell servers.

3.Reduce network “ossification” by allowing innovation and quick implementation.

4.It becomes independent from the hardware by being able to run on off-the-shell servers.

5.The network operations are simplified as they can be carried from a central point.

Scenarios for the use of SDN/NFV

Cloud

Cloud is the first scenario for the use of these technologies. Through orchestrators such as OpenStack VMs are managed for computing and virtual storage operations. VMs, located on different servers, have access to a level 2 network through solutions such as Open Virtual Switch (OVS). OVS is able to look beyond the limits of a server and ensure access to VMs that run on different servers to the same virtual switch. OVS can be managed through SDN controllers such as OpenDayLight.

As with the computing VMs, VNFs can be instantiated within the DC’s limits.

WAN

The success of the cloud architecture based on orchestrators + controllers + OVS is extended to the WAN. From OpenStack it should be possible to instantiate VNFs within the NFVI servers. These servers can be located in severals parts of the operator network, for example, in the operator point of presence (PoP).

This solution leads to the vCPE concept (Virtual CPE): The network features now located in the client installations are partly shifted to the servers located in the PoP or on the cloud, depending on the latency needs of the involved protocols.

VNFs will not prevent the operators from having a network as at present in the sense of IP connectivity between all the network positions. NFVI infrastructure needs all the servers to be interconnected and accessible from the cloud.

What is Teldat’s position as far as these technologies are concerned?

SDN/NFV are a challenge for router manufacturers, as they introduce radical changes to the current network architecture. Teldat is not indifferent to this change and aims to adapt to the new scenario. The ability to run applications (VNFs) over our router has been a first step, allowing to split transmission services provided by the router from the network services implemented by applications that run within the router.

Juan Rodrigo: Development Engineer, is part of Teldat’s R&D Department. Within this department he is part of the General Software Development Department.