This site requires cookies to work properly. Note that if you continue navigating our website, you indicate your consent to our use of cookies. To change your preferences or more information, go to Teldat Cookies Policy.


Scenario & Data Model

Scenario & Data Model

Q: What is the "Data Model"?

A: In some sense, the data model is like a database which contains information from the SDWAN network. It is  necessary to unify the network definition because one of the key aspects of SDWAN is the centralization of the entire network control plane in software. In the SDWAN Teldat approach, the control plane is implemented in the "Controller", and from the "data model", it builds / modifies the configurations of all the devices in the network in real time.

Note: In the "traditional" networking the configuration is done device by device (CLI), there is no a "data model" as such, and one could say that the data model is distributed in the configuration files of each device and all together make up the network. Although it is also possible to generate and maintain a SDWAN network in this way, throughout this document is assumed that it is not done in this way, instead it is done using the Controller.

Q: How many access networks and what kind of them can be set up and used in a SDWAN network?

A: Two types of networks can be configured: MPLS and Internet, without limit on the number of access networks / suppliers of each type. It is necessary to differentiate between these two types of network since MPLS networks do not have connectivity between them, and to generate the connectivity configuration of remote points with concentrators must be ensured that they belong to the same MPLS network.

Q: How can be identified applications to apply them policies and SLA?

A: Using an ordered list of sentences at level 3 (addresses), 4 (protocols and ports) or 7 (Host Name http). These sentences can be inclusive or exclusive, for example, to identify all the traffic except traffic to, or all TCP traffic except addressed to port X.

Q: How many applications can be identified to assign policies and SLA?

A: There is not limit on the number of applications, nor the number of policies. It is possible to associate a policy to an application, but to facilitate the management it is possible to group applications to apply a common policy, moreover, there is not limit either in the number of applications per group.

Q: How is the SLA level established?

A: Probes are generated from the remote points through all networks access, and delay, delay variation (jitter) and loss rate are measured.

Q: Are the probes active or passive? can be parameterized?

A: Probes are active, so they consume some traffic and CPU, but in practice it is negligible and thus it is possible to get SLA information before any application starts. Probes parameterization is included in the data model, so  the bandwidth consumed can be configured precisely.

Q: Is it possible to define SLA levels to applications? How?

A: Yes. As mentioned before, it is possible to associate SLA thresholds with applications or groups of applications, i.e. the maximum acceptable level for delay, jitter and loss rate for such application(s).

Q: How many SLA profiles are supported?

A: There is no limit in the number of SLA profiles that can be defined.

Q: What happens when a defined SLA level in an application cannot be achieved?

A: Application (or group of applications) is (are) moved to another access network where the SLA level is better. (for each application and remote branch type, the preferred access networks available in that branch are configured). The preferred and backup access networks are defined in an application(s) by application(s) basis.

Q: How many users and IP networks are supported?

A: There is no limit in the number of users and IP networks supported.

Q: How is quality of service (QoS) supported?

A: For any application (or group of applications), it is possible to define the level of network access: 

  • Priority: Real time, High, Normal and Low
  • Bitrate limit: maximum bitrate that can use one or a group of application categories.
  • Weight: percentage of throughput that is guaranteed to one or a group of application categories, in case of overload. 
  • DSCP or ToS marking: mark the traffic with DSCP or ToS
  • Queue lenght for each application category.

To ease the burden of configuration and maintenance, this is configured using templates of remote offices sharing the same QoS configuration. 

Q: Is direct access to internet (breakout) supported from remote offices?

A: Yes, it is supported. To do so, simply identify the type of traffic to be sent directly to the internet in each remote site. For example, everything other than their own services. To ease the burden of configuration and maintenance, this is configured using templates of remote offices sharing the same breakout configuration.

Q: Are “native” MPLS services supported, e.g. telephony over IP network?

A: Yes, in the same way that breakout internet traffic is supported, it is also possible to select services/applications and send them directly through the MPLS network (without tunnels, i.e. in the "underlay")

Q: Does Teldat SD-WAN Controller support the configuration of access devices to MPLS networks?

A: Yes, from CNM Controller is possible to configure all the necessary parameters to connect a device directly to the MPLS network. In CNM is possible to configure paramenters of the MPLS like: routing protocol, peer address, Local AS, Remote AS...

Q: Need the customer two devices, one for access and other for the SD-WAN capabilities, in Teldat SD-WAN scenario?

A: No, the customer has both possibilities. If the customer already has deployed an access device from the carrier, Teldat can deploy the SD-WAN device as a second level device, but if the customer doesn’t have it, Teldat devices can be also deployed as an access device with SD-WAN Controller.  

Q: How is achieved connectivity between SDWAN and not yet migrated SDWAN points?

A: Via the VPNs hub ("Datacenter Edge") is possible to connect remote points migrated and non-migrated since this element keeps connectivity with migrated sites through the SDWAN tunnels ("overlay") and also connectivity with the rest of the network directly ("underlay").

Q: Are several Datacenters supported?

A: Yes, several Datacenters are supported without limitation in the number of Datacenters or Datacenter Edges. Neither the number of Branch Edges that connect with a Datacenter is limited.

Q: Traffic balancing over different access/networks simultaneously is supported?

A: It is possible to select for each application or group of applications the access/network to use preferentially whenever SLA compliance is achieved, so it is possible to balance different applications for different access/networks. 

Contact us