WO2016146853A1 - Procédé et système de gestion de l'utilisation du réseau - Google Patents

Procédé et système de gestion de l'utilisation du réseau Download PDF

Info

Publication number
WO2016146853A1
WO2016146853A1 PCT/EP2016/056169 EP2016056169W WO2016146853A1 WO 2016146853 A1 WO2016146853 A1 WO 2016146853A1 EP 2016056169 W EP2016056169 W EP 2016056169W WO 2016146853 A1 WO2016146853 A1 WO 2016146853A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
traffic
data traffic
network
steering
Prior art date
Application number
PCT/EP2016/056169
Other languages
English (en)
Inventor
Eric Christian Berthold LOOS
Original Assignee
Belgacom International Carrier Services
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Belgacom International Carrier Services filed Critical Belgacom International Carrier Services
Priority to EP16711604.5A priority Critical patent/EP3272070A1/fr
Publication of WO2016146853A1 publication Critical patent/WO2016146853A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0876—Network utilisation, e.g. volume of load or congestion level
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/14—Network analysis or design
    • H04L41/147—Network analysis or design for predicting network behaviour
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5003—Managing SLA; Interaction between SLA and QoS
    • H04L41/5019—Ensuring fulfilment of SLA
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0823—Errors, e.g. transmission errors
    • H04L43/0829—Packet loss
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0852—Delays

Definitions

  • the invention relates to a method for managing network utilisation and to a system for managing network utilisation.
  • a typical data communication network comprises many components and resources. These may comprise transmission lines, receivers, transmitters, antennas, routers, switches, gateways, satellite links, satellites, submarine cables and the like. Via links between components data traffic is sent from one component to another.
  • the data may transfer from one subnetwork owned or operated by an entity such as a carrier via a border router via for instance a satellite link or a submarine or terrestrial cable to a border router of another subnetwork owned and operated by an entity such as a carrier or enterprise. Both subnetworks may be owned by the same entity, forming an internal network. Within such subnetwork there may be nodes and links to transfer the data from a source to a border router or from one border router to another border router or form a border router to a destination. Data is often also transferred from one network to another network via links such as satellite links or submarine and terrestrial cables.
  • the resources and components may require substantial expense to establish and operate, these resources are often used by many users. By sharing, those costs may be reduced. Because the networking resources are shared, use by one user may affect the ability of another user to use those same resources. This may be particularly noticeable during time periods of high network resource utilization. A high utilization of network resources may introduce queuing delays within a network, as data should wait to be transmitted or received until resources become available; if resources are not available in due time, some of the data will be discarded. In some environments, ensuring adequate network capacity to provide a high performance networking environment for all users may be achieved by building in some degree of overcapacity.
  • the network access centre aggregates statistics for subscribers and depending on the aggregated statistics configures a firewall to reduce the network capabilities available to a subscriber, by limiting or blocking data traffic sent by a subscriber.
  • the network access centre may determine whether a subscriber is exceeding the usage limit specified by a user's network data access plan. If certain criteria are met, the subscriber's network traffic is filtered to allow only data complying with certain capabilities (for instance only certain high importance type of data, while blocking more "frivolous" type of data) without limiting the upload or download speed. If a further criteria is met, the upload and download speed may be restricted in addition.
  • the present invention aims to increase the efficiency of network utilisation.
  • Method for managing network utilisation comprises:
  • the system according to the invention utilisation comprises:
  • remote service elements for a number of networks having a number of traffic profile matching rules for data traffic groups and a number of traffic profile delivery rules for data transport for data traffic group,
  • remote service elements being arranged for
  • the remote service element having a data traffic forecaster for providing a data traffic forecast for data transfer for each data traffic group based on collected previous data traffic information for said each data traffic group,
  • the invention relates to a system that works with existing infrastructure to provide traffic management and flexible traffic routing over all the available transmission paths.
  • the most relevant element of this solution is a Traffic Optimization Gateway (TOG), a distributed platform that manages the different network elements in addition to processing specific network data within the TOG to achieve the traffic management and flexible traffic routing.
  • the objective of the TOG platform is to give a single point of management for a distributed service to provide a set of new functionalities: • Optimizes distribution of traffic flows between various paths such as fibre or submarine cables and satellite
  • the TOG platform is a VAS (Value added service) that will run on top of existing products and technologies integrated to provide an optimized Wide Area Network IP data service.
  • This service will be deployed in a distributed environment, controlling the IP traffic with elements deployed on either or both sides of the Wide Area Network links which are to be managed by the TOG.
  • a centralized TOG service node may be paired with a wide number of remote service nodes.
  • Fig. 1 illustrates a basic view of the TOG Service method and platform.
  • a number of subnetworks, in figure 1 denoted with “customer network” are each provided with a remote TOG 1.
  • a central TOG 2 is provided.
  • the central TOG comprises a controller server/service element 3; furthermore the TOG system comprises a manager server/managing element 4 for managing the overall platform.
  • Traffic from the remote TOGs 1 is sent across the network in accordance with configurated rulesets.
  • the service element 3 does identification and steering of data flows and collect measurements on paths through which data flows.
  • the managing element 4 comprises a number of functions such as:
  • GUI graphical User interface
  • the objective of the TOG is to provide a set of functionalities and features.
  • the functionality covered by the TOG is Traffic Identification, Traffic classification and marking, optionally Stopping/Throttling of low priority traffic and Traffic Steering.
  • Satellite backup activation there is an option to add the Satellite backup activation.
  • the information below presents a high level architecture design of the TOG platform. It provides a helicopter view of the TOG platform and how it will be integrated into the network.
  • FIG. 1 illustrates the general set-up.
  • the system comprises central service elements 3, remote service elements 1 and management elements 4.
  • the TOG service will preferably run over a distributed platform an example of which is shown in figure 3 providing a quick view of the TOG solution.
  • a central TOG 2 On a central site a central TOG 2 is provided, on various remote sides remote TOGs having remote service elements 1 are provided.
  • a forwarding device la To a service element 1, 3 a forwarding device la, respectively 3a, such as a router or switch is associated.
  • the TOG platform preferably comprises:
  • a single Management Element (ME) 4 see figure 1, for managing the overall platform on a central TOG
  • SE Service Elements
  • the different SEs will be similar but not identical due to the nature of the functionality that they will include. It can be distinguished between two different kinds of SEs:
  • SEs of the Central TOG The SE will be installed in one or more central locations.
  • SEs of the Remote TOGs SEs will be installed in (or near) several key customer premises. This SE will interface the customer IP network.
  • Figure 5 shows some functionalities of the Remote TOGs (left side) and the Central TOGs (right side). The main functionalities of each component are included.
  • the remote TOG 1 For the outbound data traffic, thus data traffic going from a costumer subnetwork via a remote TOG 1 to a central TOG 2, the remote TOG 1 comprises means 41 for identification of data (to which data traffic group data belongs), steering of data, i.e. how to best steer data belonging to a certain data traffic group from the remote TOG 1 over possible links to the central TOG 2) and policy routing and QoS (which conditions determine which data belongs to which data traffic group, and to conditions routing of data traffic groups to the central TOG should meet).
  • identification of data to which data traffic group data belongs
  • steering of data i.e. how to best steer data belonging to a certain data traffic group from the remote TOG 1 over possible links to the central TOG 2
  • policy routing and QoS which conditions determine which data belongs to which data traffic group, and to conditions routing of data traffic groups to the central TOG should meet.
  • the lower arrows show the primary traffic path mainly followed by the IP traffic in both directions.
  • the upper paths are used by the TOG to provide both, additional bandwidth and a backup alternative to the traditional ones to be used in case of a network outage.
  • the central TOG comprises means for steering the data traffic onwards to the intended final destination.
  • the remote TOG comprises means 41
  • the central TOG comprises means 42 for identification of data, steering and policy routing and QoS.
  • the remote TOG comprises means to steer the inbound traffic onwards towards the intended destination within the customers subnetwork.
  • service elements often remote service elements 1 , but the same functionality could also be performed by central service element 2, gather performance data on logical paths created over both on-demand (i.e. satellite) and permanent paths.
  • the logical paths may be constructed using any means that allow the path to be formed between the service element and a traffic delivery endpoint independent of other network flows in a way that bypasses routing decision making by intermediate network elements.
  • the data are broken into smaller pieces called packets as they move along the tunnel for transport. As the packets move through the tunnel, they are encrypted and another process called encapsulation occurs.
  • the private network data and the protocol information that goes with it are encapsulated in public network transmission units for sending. The units look like public data, allowing them to be transmitted across the Internet. Encapsulation allows the packets to arrive at their proper destination. At the final destination, de-capsulation and decryption occur.
  • PPTP 'Point-to-Point Tunnelling Protocol
  • Authorized users can access a private network called a virtual private network, which is provided by an Internet service provider. This is a private network in the "virtual" sense because it is actually being created in a tunnelled environment.
  • L2TP Layer Two Tunnelling Protocol
  • Tunnelling is a way for communication to be conducted over a private network but tunnelled through a public network. This is particularly useful in a corporate setting and also offers security features such as encryption options.
  • Multiprotocol Label Switching is a type of data-carrying service for high- performance telecommunications networks that directs data from one network node to the next based on short path labels rather than long network addresses, avoiding complex lookups in a routing table.
  • the labels identify virtual links (i.e. paths) between distant nodes rather than endpoints.
  • MPLS can encapsulate packets of various network protocols, hence its name "multiprotocol”.
  • the endpoint of a logical path connected to a Service Element may be another Service Element or any other network device capable of removing the logical path container and forwarding the carried network flows to the correct ultimate destination.
  • Performance data will be gathered from the logical paths using available standards based or proprietary measurements techniques yielding at least information regarding packet loss, jitter and latency, for instance a network performance measurement such as RFC3432, RFC 3393, RFC 2330, RFC 2681 Alternatively or in addition, in the measurement approach, an SE sends one or multiple test packets with a predetermined payload at set intervals to another element suitable configured to process the test packets and to send them back to the originator of the test. By comparing the set of sent test packets with the received packets, the service element is able to determine whether packets went missing, what latency each packet experienced through the network and whether there is a variation in the latencies experience by each packet (jitter).
  • the performance measurements are preferably compared to a configurable threshold value. If the performance does not meet the threshold the path will be declared unavailable.
  • the test may also be used in addition to the telemetry for periodically gauging the accuracy of telemetry measurements.
  • Figure 6 illustrates a part of the system and method of the invention.
  • a user of customer 1 provides the ME 2 of the central TOG with traffic profiles TP c i for various data traffic groups or informs the ME of its choice of suggested traffic profiles or any combination thereof. This can be done via the internet.
  • the Management element of the central TOG then provides this traffic profile information to the service elements 2 and 1 of both the central TOG and of the customer 1.
  • the service elements comprise a receiver for receiving the traffic profile information.
  • Different sets of traffic profiles TP cl - and TP c i may be set by a customer for incoming and outgoing data traffic.
  • Figure 7 illustrates an example of data comprised in the traffic profiles. They comprise three parts, of which the third part is optional, but highly preferred.
  • the first part comprises matching rules. These matching rules allow determining to which data traffic group an IP flow is to be assigned. There can be a multitude of data traffic groups. The object is to group IP flows into data traffic groups. A number of matching rules are shown in part 71 of figure 7.
  • the matching rules may comprise one or more of the following:
  • a set of traffic profile delivery rules 72 are provided for a data traffic group. This specifies the requirement/wishes for delivery of each data traffic group.
  • the traffic profile delivery rules may comprise one or more of the following:
  • Figure 7 shows the traffic profile for profile 1 , there may be in the set of traffic profiles rules for traffic profile 2, 3 etc.
  • the delivery rules may also specify whether a best approximation is to be chosen or whether the delivery rules are strict. There may be a mix of the two. For instance: a data traffic group could be: specially encrypted IP flows.
  • the traffic profile matching rules 71 could, as an example, specify that for any IP flow it is checked whether the IP flow is encrypted, and if so, by which encryption method. There would then be one or more data traffic groups within a set of profiles "encrypted". There could be a data traffic group with the profile: encrypted by this program, or by that program, within these two sets of profiles there could be specific profiles, specifying requirements on speed and possible loss.
  • the traffic profile delivery rules may specify that for one group of encrypted IP flows the required paths must be paths A, B and C, and no other paths. The delivery rules for the path would then be restrictive, only specified paths, or paths of a specific type, can be used. For any such encrypted IP flow data traffic group there can also be set the maximum latency, maximum packet loss and/or maximum jitter. For these requirements a best approximation approach may be used.
  • the data for traffic profile comprises, when being sent to the ME, a third component, namely traffic profile historical data 73 collected previously.
  • IP flow may not match any of the traffic profiles, then it is the default data traffic group, and is treated by a default procedure. This constitutes non-matched flow. Often this may mean that what can not be classified in any specified data traffic group is "the rest" and such IP flow is sent if there is any bandwidth left by whatever path, no matter how much packet loss or jitter etc, in short, the last in the line,
  • a situation is schematically shown in which a set of rules is provided.
  • the provided information may also be, or be related to an amendment, change or up-date of an already existing traffic profile TPQ. Examples are (not to be considered restrictive):
  • the maximum loss, latency or jitter may have been set to severe or not severe enough and in an update this is corrected.
  • a change in the source or destination protocol address range Someone within may have been promoted and henceforth his or her data is up-graded in importance. The same holds for a department that has gained importance. A destination of data may also have gained in importance (e.g. a small customer that has become an important player) or the opposite (e.g. a customer has gone bankrupt).
  • the update in assignment of data sent or received to a more or less "important" data traffic group reflects said change.
  • the other assignment rules or traffic rules may remain unchanged.
  • the central service element is provided with the information of traffic profiles 1, 2, 3 etc of the various customers.
  • the service element of customer 1 is only provided with the traffic profiles set by customer 1 as provided to the management element ME and provided to the SE of customer 1.
  • the traffic profile information is passed via the central ME.
  • each data profile in detail, i.e. a customized data profile
  • the customer chooses one or more of such standard traffic profiles, plus no, one or more personalised traffic profiles and provides the ME with its choices, upon which the ME provides the information to the remote and central SE.
  • information on the settings of one or more standard traffic profiles may already be present. So for instance, if the SE comprises information on a number of proposed standard traffic profiles for standard data traffic groups, the information sent by the ME to the SE may be as simple as: "standard traffic profiles SI, S3 and S7 and, in addition, the following additional traffic profiles characterized by the following rules 71 and 72".
  • the SE then has the information on matching rules, delivery rules and possibly also history for the traffic profiles.
  • Figure 8 further illustrates an aspect of the invention.
  • the ME has provided the SE with the traffic profiles.
  • Part A illustrates an IP flow entering the forwarding device la, 2a of service element 1, 2.
  • the initial packets of the IP flow usually the header, are compared to the matching rules 71. This allows establishing to which data traffic group the incoming IP flow is to be assigned.
  • a signal is sent to the application in the SE signalling to which rules the IP flow matches and thus to which data traffic group it is assigned.
  • This information is collected.
  • the steering planner is provided with the information, and steers the IP flow to a specific logical port thereby steering it via the path chosen by the steering planner. Non-matched flows are sent to the default logical port.
  • the subsequent packets are sent to the chosen logical port. Further data is collected and sent to the data collector.
  • FIG. 9 illustrates the process in more detail.
  • the traffic data (to which data traffic group the IP flow is associated, when, how much) collected is provided to the data collector. These data is stored and an input for the traffic profile forecaster provider.
  • the traffic profile forecaster provider provides a data traffic forecast (91) as input for the steering planner (92). Furthermore, through telemetry or the process illustrated in figures 10 and 11 measurements on the present parameters of paths, for instance capacity and parameters such as latency, jitter and/or packet loss is collected and supplied to the collector.
  • the steering planner is provided with a forecast for instance from the traffic forecast provider, and a comparison is made, either within or separate from the steering planner, as schematically illustrated in figure 12, between forecast of data traffic and actual situation.
  • the steering planner makes a steering plan, to match the traffic paths for data traffic groups to the measured parameters and the steering plan determines the steering actions allowing the forwarding device la, 3a to steer the IP flow to the right path.
  • the forecast is made on basis of collected traffic data. Additional information such as for instance which days are holidays or the switch of day light savings time to normal time may be used in the forecast in addition to using previously collected traffic data.
  • a possible method for collecting path parameters via direct action on available paths is schematically illustrated in figures 10 and 11.
  • Each Service Element independently uses performance measurements to determine the available paths to reach destinations to provide such information to the steering planner to create a steering plan. Based on this information the steering planner creates a steering plan, which for economic reasons will initially try to meet the demands, i.e. make a steering plan wherein for each or for most data traffic groups the used paths meet or match as best as possible the traffic profile delivery rules 72 by using permanent paths, avoiding using expensive satellite capacity.
  • the Service Element will notify the Management Element of the additional satellite bandwidth that is required to accommodate all the traffic in the steering plan, with defined maximum.
  • the steering plan is based on a forecast of the demand for bandwidth between the time of calculation of the steering plan and a configurable time-period.
  • Each Service Element collects information regarding the traffic flows passing the Service Element.
  • a service element may consider other sources of flow information already existing in the network of the customer, which are shared with the Service Element using standard protocols such as Netflow (Cisco Proprietary) or IP Flow Information Export (IPFIX, documented in RFC 3917). This information is then processed and summarized in 'Traffic Profiles', either defined by the end-user via an interface on the Management Element, or created internally by the Service Element to keep track of data flows exceeding a certain size threshold.
  • each Service Element constructs a historic usage pattern that is in turn used to create a prediction regarding anticipated traffic demand in the coming time-period for data traffic groups. This is performed in a traffic profile forecaster provider (91) as schematically illustrated in figure 9. The actual traffic levels are also measured and compared to the predictions; if there is a significant mismatch, a new steering plan will be created for a shorter time-period.
  • FIG 12 illustrates this method.
  • the traffic forecast provider generates a prediction for each traffic profile each T time period. In figure 12 this is schematically shown by the solid curve.
  • the traffic forecaster provider checks the netflow information to compare the current traffic used by each traffic profile to the predicted value. If the current traffic differs more than a standard deviation from the predicted value, in figure 12 schematically illustrated by point 123, the traffic forecast provider notifies the steering planner, indicating that actual traffic deviates from the prediction and preferably how much.
  • the steering planner then makes a new steering plan order to create a new steering plan.
  • the steering planner creates a new steering plan or if it concerns more than one profile new set of steering plans that will be applied by the traffic steering for a new time period, for instance for the next 24 hours.
  • the steering planner may make a new, short term, steering plan for a shorter time period, for instance one hour and replaces the one that was created in the ling term, 24 hour steering plan by the new shorter term steering plan, reverting back to the long term steering after said one hour.
  • TCP/IP Transmission Control Protocol/Internet Protocol
  • This protocol has built-in mechanisms to ensure that a point to point TCP connection between communicating hosts uses as much bandwidth as possible. Therefore if there is a constraint in the total capacity, the TCP protocol will reduce the amount of bandwidth used in a session, but it will constantly try to revert to the highest possible throughput.
  • the traffic prediction created by the Service Element takes into account how much bandwidth each traffic profile requires under normal circumstances.
  • the traffic prediction allows a Service Element to estimate how much bandwidth a traffic profile will use when it is no longer constrained due to an event in the network.
  • Relying on a traffic prediction also allows the Service Element to request the ME to provide a correctly sized on-demand satellite capacity leading to a greater stability of the on-demand path.
  • the steering plan thus created represents a solution for the traffic distribution over the available permanent paths and the amount of satellite bandwidth that ideally should be activated on-demand.
  • An On-Demand Resource requestor (ODRR) in the SE uses the traffic predictions alone or in combination with actual data on properties of available paths to ensure that on-demand capacity, i.e. bandwidth via a satellite link, is requested only when absolutely required.
  • the ODRR sends a request for satellite bandwidth to the Management element. If a permanent path fails so that the remaining paths cannot meet the bandwidth requirements the ODRR also sends such a request.
  • the management element comprises an On-demand resource manager which receives this request and similar request of other remote SEs and, if possible, allocates bandwidth on the satellite paths and informs the SE of such allocation of satellite bandwidth.
  • the information on the allocated satellite bandwidth is provided to the steering planner of the SE, which uses this information to make a new steering plan using the allocated satellite bandwidth for some or all IP flows.
  • the steering planner of the SE uses this information to make a new steering plan using the allocated satellite bandwidth for some or all IP flows.
  • there is a demand of 150Mbit from left to right whereas the permanent paths have 200Mbit of capacity each. Even if either Path A or Path B fails, the other path will have sufficient capacity to meet the demand.
  • the ODRM will only activate the on-demand capacity if both paths would fail or the demand would increase beyond 200Mbit.
  • the Central TOG comprises:
  • a Management Element 4 A dedicated server, e.g. a Linux server, running the distributed platform and service components for management.
  • Service Elements One dedicated Server, e.g. a Linux server, per SE running the distributed platform and service components for IP traffic processing.
  • This server will also run dedicated software to take control over the switching elements and apply dynamic control over the IP traffic.
  • Routers or devices supporting forwarding control on flows of packet data where the matching criteria to determine the action taken on the flow by an external application using an application interface can be for instance based on information present in the headers and the data of OSI model layers 2 through 7, will process the IP traffic of the central TOG.
  • Figure 14 illustrates the central TOG comprising Service Element and Router/Switch component with application interface and figure 15 illustrates the management element in the central TOG.
  • the service element of the central TOG comprises a means 42A for identification and classification of data traffic, a means 42B for steering and a means 42C for QoS filtering and shaping.
  • the management element comprises a GUI (graphical user interface). This GUI receives the Traffic profiles TPQ of the various customers and pushes this information to the remote SE of the customer.
  • the Management Element collects the requirements for on-demand capacity derived from the traffic predictions and the steering plan by the Service Elements.
  • the remote SEs comprise an ODRR which send its request R to the ODRM in the management element.
  • the Management Element will assign fully, partially or not at all the on demand satellite capacity requested by a Service Element and allocate an allocation A to the customer. This assignment can be realised in the network resources by way of Application Programming Interfaces (API) exposed by 3rd party network management systems.
  • API Application Programming Interfaces
  • the solution may incorporate additional connectivity to effectively transmit configuration commands from the network management systems to the network elements.
  • the Steering Plan preferably shares the capacity based on forecasted traffic demand and in-line with defined business rules regarding the allocation of the bandwidth from a common pool, providing the Service Elements on-demand capacity which is guaranteed.
  • the Management Element relays the information about the assigned capacity A to the Service Elements so they can use this information to fine tune their steering plans.
  • Each Remote TOG comprises:
  • a generic processing component e.g. a Linux server, running the distributed platform and all the service components for IP traffic processing and a forwarding component.
  • a reason to multiply these components is to provide High Availability or scalability to the service.
  • These servers may or will also run software provided to take control over the switching elements and apply dynamic control over the IP traffic.
  • FIG 16 illustrates the remote TOG comprising Service Element and Router/forwarding component.
  • the remote TOG comprises a means 41 A for identification and classification of data traffic, a means 4 IB for steering and a means 41 C for QoS filtering and shaping.
  • the Network Diagram shown in figure 17 illustrates a global view of the overall network environment. This shows the different elements that there are preferably present to provide the TOG service.
  • each Remote TOG there will be at least one Remote TOG in each customer subnetwork.
  • This TOG will be able to process the inbound and outbound traffic of the customer.
  • a defined subset of this traffic will pass through the Central TOG.
  • the paths than can be used for this purpose can be for instance any of the submarine cables accessible by the customer and the recently established Satellite paths. There might be more than one satellite path. Supposing an initial path pre-established, the Central TOG could decide to modify it to carry a higher traffic throughput for this customer.
  • Several cable and satellite paths connect the customer premises with the network containing the central TOG's.
  • the bypass is to the internet.
  • the internet is not the only wide area network the TOG could be applicable to, might be the EU network of an African operator too.
  • the method of the invention comprises preferably a number of steps: - establishing data traffic groups, wherein for each traffic group a number of quality parameters for data transport are set for a network, assigning outgoing or incoming data traffic from or to a network to a data traffic group, sending and/or receiving assigned data traffic to and/or from a network via a forwarding device
  • the steering plan is established by comparing and paring the capacity and quality characteristics of the possible paths to the quality parameters for a data traffic group optionally activate on demand capacity through application program interfaces exposed by third party resource or network management systems.
  • the shared internetwork links forming various potential data traffic paths between the networks
  • Management Element which distributes it to the relevant Service Elements, the customer can set e.g. acceptable delay, jitter, packet loss, but also business rules like e.g. desirability based on cost due to usage based billing methods.
  • the outgoing and/or ingoing traffic is assigned to a data traffic group; this can be done on for instance content (e-mail, for instance) or origin within the network (e.g. source address) or destination or based on a combination of source, destination, protocol and ports, where wildcards are supported to mean 'any value' for a certain parameter.
  • a central element is provided with actual information on the conditions and qualities of the possible paths between the remote TOGs and the central TOG, for instance available satellite connections and submarine cables. Conditions can be available bandwidth, delay, jitter, loss etc.
  • the central element also is provided with present and past data traffic information. In various ways information on conditions of various possible paths may be obtained, for instance using Netflow, IPFIX or other standard protocols used for "flow accounting", the data on the conditions of various possible paths is read using known industry protocols such as SNMP (Simple Network Management protocol) for requesting interface statistics.
  • SNMP Simple Network Management protocol
  • a prediction of the data in the data traffic groups going to and from the various subnetworks is made.
  • This prediction and the quality parameters set for the data graphic groups (which may not be the same for each subnetwork) are compared to the conditions for the various available paths.
  • Based on these comparisons and the priority for the data traffic groups a data steering plan is made and the various data steering groups are steered to and/or from the remote TOGs and central TOG in accordance with the steering plan.
  • the steering plan can be dynamically adjusted, sending the second data traffic group (or part of the second data traffic group) also via a submarine cable and/or extra bandwidth may be, based on the prediction, set aside in the satellite link.
  • the data traffic belonging to a data traffic group can be distinguished by one or more parameters, for instance one or more of the following:
  • Source address Destination address; Destination port; ToS value; Source port; Traffic protocol
  • Attracted data traffic can be classified in a data traffic group on basis of match between parameters for a data traffic group and parameters of the data (precise or to a best approximation). Thus the data is identified as belonging to a data traffic group.
  • the traffic passing through the TOG routers is identified.
  • Data traffic groups are matched to a traffic profile to group them by quality and business parameters and/or priority compared to other data traffic groups.
  • the TOG supports a number, for instance up to 20, different traffic profiles per customer. For these Traffic Profiles, the user can define one or more of a number of parameters.
  • the TOG will apply this configuration for all the flows that are matched as part of this traffic profile.
  • a number of parameters for the traffic profile are:
  • Max Packet Loss The user can define what the maximum value of packet loss that can be tolerated for this traffic profile is.
  • - Max Latency The user can define what the maximum value of Latency or delay that can be tolerated for a traffic profile is.
  • Max Jitter The user can define what the maximum value of Jitter or delay that can be tolerated for this traffic profile is.
  • the user also defines the priority of traffic profiles by the number on the list.
  • the traffic that cannot be classified is preferably treated as the default treatment. For instance in default treatment all the flows are balanced with the same percentage over all the available paths (including the satellite paths).
  • the user can select, for instance by using a flag, whether, when a requirement cannot be met, the traffic is to be dropped or a path that comes closest to the set maximum value for packet loss, latency or jitter is to be selected.
  • the result of the Classification is preferably a List of suitable paths that could be applied to each traffic Profile. These lists discard those paths that cannot be used for a given traffic profile.
  • the Steering functionality, or steering planner will determine the Steering Plan, specifying which path will be used for each traffic profile for each customer.
  • the classification allows the customer to specify what is the nature of some relevant traffic and how the TOG should handle it. The customer will configure this traffic classification creating a list of specific Traffic Profiles.
  • the system preferably comprises a steering planner.
  • the Steering planner is in charge of creating the Steering Plan and determining when this steering plan should be modified.
  • the TOG will apply a Flexible Traffic Routing to manage the data traffic of the customer.
  • the Steering planner considers 3 items to create the Steering Plans:
  • the classification provides a list of possible paths; the steering planner is provided with up-to-data on the paths and the predicted data for data traffic groups and combines the various information for an optimal steering plan.
  • the Steering Plan contains all the information required by the TOG Router and the Flow Manager How to route and mark the traffic.
  • the Steering planner is responsible for creating new Steering plans when the characteristics of the traffic changes to accommodate the routing to the new traffic arriving the TOG.
  • the steering planner receives various information and makes a steering plan using the received information.
  • the steering planner receives information from monitoring providers,
  • the Monitoring Providers continuously check the current values of traffic and the status of the paths. This means that they compare for instance:
  • IP/SLAs values with the previous ones (to detect a change in a path).
  • the Steering planner In case of a significant change in path conditions, they notify the Steering planner so that the Steering plan can be changed by the steering planner.
  • the Steering planner also is provided information by a traffic profile forecaster.
  • the steering plan is based on prediction for data traffic group flows.
  • the Traffic Profile Forecast Provider When the Traffic Profile Forecast Provider detects that the current Traffic Bandwidth of any of the Traffic Profiles (i.e. data traffic group) differs more than the Standard Deviation from the predicted value, it notifies the Steering planner (and preferably also how much the deviation is) so that the steering planner may create a new Steering Plan for the changed situation.
  • the steering planner may also be notified of any change in the requirement set for data traffic groups, for instance a change in a maximum allowed jitter etc.
  • the Steering Plan contains the information required by the TOG Router and the Flow Manager How to route and mark the traffic for the data traffic groups.
  • the Steering planner is responsible for creating new Steering plans when the characteristics of the traffic changes to accommodate the routing to the new traffic arriving the TOG. If the Steering planner has a new Steering Plan, it provides this info to the Policy Manager to reconfigure the TOG router or routers according to this new Steering Plan so that the data traffic groups are transferred over the links in accordance with the altered steering plan. Whenever necessary or useful, the TOG will preferably attract the data traffic entering or exiting the customer network through defined paths.
  • the methods preferably used in the invention to attract traffic to a remote TOG and/or a central TOG are different and separately usable for the upstream traffic (traffic from the customer to Internet) and for the downstream traffic (traffic from Internet to customer).
  • a configuration should preferably be made that attracts the traffic to the Remote TOG in place of the PE routers that would receive it in a standard BGP routing environment.
  • a basic rule of routing is that more specific prefix announcements always take precedent. E.g. a packet to 10.10.10.1 always will follow a route to 10.10.10.0/24 over 10.10.0.0/16 independently of the metric, administrative distance or other parameters of the routes (the only exception is that a route won't be used if the associated next-hop is unreachable).
  • the Remote TOG will split the prefixes configured in the customer profiles to the minimal amount of more specific prefixes that allow them to be successfully distributed by the steering planner over the available paths and will announce them.
  • the Remote TOG will announce the prefixes to all its iBGP peers with a local preference better than the one used in the customer network.
  • the Local Preference parameter works only inside the boundaries of an AS according to the BGP specification, so the preference it indicates cannot be relayed to other networks on the "Internet” or other wide area networks composed of several companies with their own AS.
  • Traffic flowing from Internet to the customer can flow through the network comprising the Central TOG, but also through any other provider of the customer that will propagate the BGP routing announcements of the customer.
  • the path of the incoming traffic flows depends on events and traffic management decisions of third party networks outside of the control of the network attempting to influence the incoming traffic flows.
  • the invention preferably uses the disaggregation method explained previously, but with differences:
  • the customer does not announce any one of the more specific prefixes by itself o
  • the customer inserts in the routing database of the associated RIR all of the more preferred prefixes that can be steered (not necessarily steered in the present moment, but that can be in the future)
  • the Remote TOG will generate and announce to the Central TOG using eBGP these more specific prefixes defined in the policies of the customer.
  • the PE's of the network hosting the central TOG will announce these prefixes to Internet.
  • the BGP announcements will have the AS of the customer as origin and the AS of the network hosting the central TOG as transit. In some deployment scenarios, where the central TOG platform is integrated with the customer network, there will not be a transit AS.
  • the TOG makes a reasonable approximation of paths available to networks which are the source of traffic as defined in the data traffic profile by collecting multiple views of the interconnections between networks from the most interconnected global networks, for instance, the top 10 internet service providers worldwide.
  • the TOG engages in a trial and error stage applying the steering techniques on customer BGP announcements with the sole purpose of validating the approximated model by verifying the intended shift of incoming traffic flows towards the intended path. If during the trial and error stage, the intended effect is not observed, the steering plan is improved.
  • the incoming traffic flows will be directed towards the paths determined in the steering plan created by the TOG and thus under control of the TOG.
  • the Traffic Steering summarizes all the activities that the TOG performs on the traffic to achieve routing it over the most desirable path depending on its classification. Depending on the Traffic classification - that is, the configuration for each traffic profile - the TOG will determine which path of the available is the best available one to handle each configured traffic profile.
  • the Result of the Traffic Steering functionality is to create a Steering Plan and to apply it.
  • the Steering Plan contains several steering rules that determine how the traffic is distributed among the different paths.
  • the TOG will create a Steering Plan, containing all the routing rules to apply to all the Traffic Profiles for a specific period of time. This is basically:
  • the Steering planner is in charge of creating the Steering Plan and determining when this steering plan must be modified.
  • the TOG will apply a Flexible Traffic Routing to manage the data traffic flows of the Customer.
  • the Steering planner considers 3 items to create the Steering Plans:
  • the Steering Plan contains the information required by the TOG Router and the Flow Manager to route and mark the traffic.
  • the Steering planner If the Steering planner has a new Steering Plan, it provides this info to the Policy Manager to reconfigure the TOG router according to this new Steering Plan to steer the data traffic flows from a customer according to the new steering plan.
  • the Steering planner preferably creates a new and sometimes totally different steering plan each T period. This means approximately a new router reconfiguration each T period of time.
  • the Traffic Steering functionality will produce a Steering Plan that will be applied during a configurable period of time T. It contains the steering rules that the TOG must follow to correctly steer the traffic during this period of Time T. If the new Steering Plan is equal than the current one, no actions are taken.
  • tunnels are preferably created between the Central TOG and the Remote TOG and vice versa.
  • An important requirement for the tunnels is that they must follow the exact path for what they were designed. I.e. the tunnel created through carrier A should always transit through carrier A. If there is a connectivity problem with (or inside) carrier A, the tunnel preferably goes down, not be rerouted through other carriers. If the customer has more than one connection with one carrier, for each connection preferably a separate tunnel is created.
  • Method and system for managing network utilisation uses data traffic groups. Incoming and outgoing data flows are assigned based on traffic profile matching rules to a data traffic group. For a data traffic group a number of quality parameters, such as maximum loss and jitter are set. A data traffic forecast is made based on collected previous data traffic information. For possible paths, such as tunnels, for data traffic groups parameters such as available bandwidth and quality parameters are monitored. A traffic data steering plan is made, using the gathered information and the data traffic forecast, and the data traffic for each data traffic group is steered on basis of the data steering plan. In preferred embodiments additional bandwidth via a satellite is requested.
  • the customer may want to be sure that if there is a problem with the inbound or outbound data flows that bypass the SE, the system of the invention takes measures to ensure safe and sound delivery of such data flow. The system then monitors the paths, but not the actual data flows through the paths.
  • Figure 20 illustrates such an embodiment.
  • Some data flows bypass the service element SE. Such flows can be sent via an unmanaged path or via a monitored path.
  • the SE does not control what is sent via the unmanaged path or what is sent via the monitored path.
  • the system does monitor the availability and/or other parameters such as loss, latency and jitter. This can be done, as illustrated, by the SE sending itself test packages via a route including the monitored path or monitoring the path via telemetry.
  • the SE sends a BGP (Border Gateway Protocol) announce to the relevant forwarding devices (routers), thereby attracting the traffic that would be sent through the failed path to the SE.
  • BGP Border Gateway Protocol
  • the SE may have permanent access to a satellite link and/or send a request R for satellite bandwidth to the ME.
  • the SE can then send the data which would otherwise not arrive at its destination to its destination via an alternative path for instance, as will often be the case and illustrated in figure 20, via a satellite connection. In the right hand part of figure 20 this is illustrated by the dotted arrows showing the data traffic being sent over a satellite connection to the intended destination.
  • At least some of the outgoing data flows of a network bypass the steering plan, sent via monitored paths wherein when the monitoring indicates that a path is blocked or its parameters fall below a threshold, the data flows is attracted to a service element (1) and steered via the service element (1).
  • This embodiment on the one hand provides costumers the freedom to bypass the SE for some data flows, thereby reducing costs, but on the other hand the safety and convenience that the present invention provides in case a monitored path falls.
  • the customer takes the risk of failure of the path.
  • the customer could arrange for certain data flows from certain forwarding devices to be attracted to the SE, but, in normal circumstances other flows not to be attracted to the SE.
  • the customer may have these data flows attracted to the SE. This can be applied both for outbound as well as for inbound data flows.
  • the SE preferably keeps on monitoring the failed path.
  • Figure 21 illustrates a sharing of satellite bandwidth.
  • the shared bandwidth pool is 300 Mbit/s.
  • Operator 1 and 3 when there is no failure in the path or paths they used, do not need satellite bandwidth.
  • the steering planner in the remote SE will notice that the capacity of the permanent paths is or soon will be inadequate and send via the ODRR an on-demand request for satellite bandwidth to the ODRM in the management element.
  • Operator 1 & 3 may pay an insurance fee for the maximal bandwidth.
  • the central element allocates the bandwidth over the operators taking into account assigned priority and weight.
  • bandwidth via a satellite is pooled by more than one network and the central management element (ME) distributes the available bandwidth over the network cooperating in the pool.
  • ME central management element
  • the central element has gathered data on the agreements between the member of the pool and assigns, when a request for on-demand resources is sent by a service element to the central element bandwidth on the satellite link in accordance, or in best accordance, with the agreement.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Environmental & Geological Engineering (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

L'invention concerne un procédé et un système de gestion de l'utilisation du réseau qui utilisent des groupes de trafic de données. Des flux de données entrants et sortants sont attribués sur la base de règles de mise en correspondance d'un profil de trafic par rapport à un groupe de trafic de données. Concernant un groupe de trafic de données, un certain nombre de paramètres de qualité, tels qu'une perte et une gigue maximales, sont réglés. Une prévision d'un trafic de données est effectuée sur la base d'informations collectées de trafic de données précédentes. Pour les chemins possibles, tels que des tunnels, des paramètres de groupes de trafic de données tels que la largeur de bande disponible et des paramètres de qualité sont surveillés. Un plan de direction de données du trafic est réalisé, en utilisant les informations collectées et les prévisions du trafic de données, et le trafic de données pour chaque groupe de trafic de données est dirigé sur la base du plan de direction de données. Dans des modes de réalisation préférés, une largeur de bande supplémentaire par l'intermédiaire d'un satellite est demandée.
PCT/EP2016/056169 2015-03-19 2016-03-21 Procédé et système de gestion de l'utilisation du réseau WO2016146853A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP16711604.5A EP3272070A1 (fr) 2015-03-19 2016-03-21 Procédé et système de gestion de l'utilisation du réseau

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP15159956 2015-03-19
EP15159956.0 2015-03-19

Publications (1)

Publication Number Publication Date
WO2016146853A1 true WO2016146853A1 (fr) 2016-09-22

Family

ID=55589852

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2016/056169 WO2016146853A1 (fr) 2015-03-19 2016-03-21 Procédé et système de gestion de l'utilisation du réseau

Country Status (2)

Country Link
EP (1) EP3272070A1 (fr)
WO (1) WO2016146853A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108075928A (zh) * 2017-12-15 2018-05-25 中盈优创资讯科技有限公司 网络流量通用仿真模型及方法

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100214920A1 (en) * 2009-02-20 2010-08-26 At&T Corp. Systems and Methods for Capacity Planning Using Classified Traffic
US8811172B1 (en) * 2014-04-10 2014-08-19 tw telecom holdings inc. Network path selection using bandwidth prediction

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100214920A1 (en) * 2009-02-20 2010-08-26 At&T Corp. Systems and Methods for Capacity Planning Using Classified Traffic
US8811172B1 (en) * 2014-04-10 2014-08-19 tw telecom holdings inc. Network path selection using bandwidth prediction

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108075928A (zh) * 2017-12-15 2018-05-25 中盈优创资讯科技有限公司 网络流量通用仿真模型及方法
CN108075928B (zh) * 2017-12-15 2020-12-08 中盈优创资讯科技有限公司 网络流量通用仿真模型及方法

Also Published As

Publication number Publication date
EP3272070A1 (fr) 2018-01-24

Similar Documents

Publication Publication Date Title
US11646964B2 (en) System, apparatus and method for providing a virtual network edge and overlay with virtual control plane
US20230224246A1 (en) System, apparatus and method for providing a virtual network edge and overlay with virtual control plane
US10523593B2 (en) System, apparatus and method for providing a virtual network edge and overlay
US10122829B2 (en) System and method for providing a control plane for quality of service
US9929964B2 (en) System, apparatus and method for providing aggregation of connections with a secure and trusted virtual network overlay
US7046665B1 (en) Provisional IP-aware virtual paths over networks
US8867349B2 (en) Regulation of network traffic in virtual private networks
US9264350B2 (en) System, apparatus and method for providing improved performance of aggregated/bonded network connections with multiprotocol label switching
US9264307B2 (en) System, apparatus and method for providing improved performance of aggregated/bonded network connections between remote sites
US20040223499A1 (en) Communications networks with converged services
US10333832B2 (en) System, apparatus and method for providing improved performance of aggregated/bonded network connections with multiprotocol label switching
AU2014295861B2 (en) System, apparatus and method for providing improved performance of aggregated/bonded network connections between remote sites
CA2990045C (fr) Systeme, appareil, et procede pour la fourniture d'un reseau virtuel edge ou overlay
CA3029862A1 (fr) Systeme et procede de fourniture de plan de controle pour la qualite de service
WO2016146853A1 (fr) Procédé et système de gestion de l'utilisation du réseau
Cisco Introduction to MPLS VPN Technology
EP4407932A1 (fr) Procédé et système de transmission de données par paquets en mer
CA2863901C (fr) Systeme, appareil et methode destines a fournir un rendement ameliore de connexions reseau regroupees ou liees au moyen de commutation d'etiquette multiprotocole
Iftikhar et al. Multi-Protocol Label Switching To Support Quality of Service Needs

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16711604

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

REEP Request for entry into the european phase

Ref document number: 2016711604

Country of ref document: EP