WO2015097318A1 - Procedimiento y sistema para restaurar degradaciones de la qos en redes de mpls - Google Patents

Procedimiento y sistema para restaurar degradaciones de la qos en redes de mpls Download PDF

Info

Publication number
WO2015097318A1
WO2015097318A1 PCT/ES2013/070929 ES2013070929W WO2015097318A1 WO 2015097318 A1 WO2015097318 A1 WO 2015097318A1 ES 2013070929 W ES2013070929 W ES 2013070929W WO 2015097318 A1 WO2015097318 A1 WO 2015097318A1
Authority
WO
WIPO (PCT)
Prior art keywords
network
mpls
alarm
monitoring
services
Prior art date
Application number
PCT/ES2013/070929
Other languages
English (en)
French (fr)
Inventor
Juan Pedro Fernandez-Palacios Gimenez
Juan RODRIGUEZ MARTINEZ
Original Assignee
Telefonica, S.A
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 Telefonica, S.A filed Critical Telefonica, S.A
Priority to PCT/ES2013/070929 priority Critical patent/WO2015097318A1/es
Priority to US15/108,273 priority patent/US20160308709A1/en
Priority to EP13900511.0A priority patent/EP3089409A4/en
Publication of WO2015097318A1 publication Critical patent/WO2015097318A1/es

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/64—Hybrid switching systems
    • H04L12/6418—Hybrid transport
    • 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/06—Management of faults, events, alarms or notifications
    • H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
    • H04L41/0659—Management of faults, events, alarms or notifications using network fault recovery by isolating or reconfiguring faulty entities
    • 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/06—Management of faults, events, alarms or notifications
    • H04L41/0604—Management of faults, events, alarms or notifications using filtering, e.g. reduction of information by using priority, element types, position or time
    • H04L41/0618—Management of faults, events, alarms or notifications using filtering, e.g. reduction of information by using priority, element types, position or time based on the physical or logical position
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/22—Alternate routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/52—Network services specially adapted for the location of the user terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/54—Store-and-forward switching systems 
    • H04L12/56—Packet switching systems
    • H04L12/5601—Transfer mode dependent, e.g. ATM
    • H04L2012/5625—Operations, administration and maintenance [OAM]
    • H04L2012/5627—Fault tolerance and recovery
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/28—Routing or path finding of packets in data switching networks using route fault recovery
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/50—Routing or path finding of packets in data switching networks using label swapping, e.g. multi-protocol label switch [MPLS]

Definitions

  • the present invention has its application within the telecommunications sector and, especially, it refers to the Quality Assurance in computer networks and, more specifically, it refers to a system and method for preventing, detecting and restoring Quality degradations of the Service (QoS) in End-to-End Multi-Protocol Label Switching (MPLS) networks.
  • QoS Quality degradations of the Service
  • MPLS End-to-End Multi-Protocol Label Switching
  • IP Core networks are normally deployed over Multi-Protocol Label Switching (MPLS) technology, due to the wide range of advantages provided by this encapsulation, in terms of Traffic Engineering (TE), homogeneous provision of any type of service, restoration tools and maintenance of the Quality of Service (QoS).
  • MPLS Multi-Protocol Label Switching
  • TE Traffic Engineering
  • QoS Quality of Service
  • the MPLS has also experienced an extension to other existing segments, such as regional networks.
  • these MPLS domains have normally been kept separate, at least in large operators, mainly due to scalability reasons.
  • E2E Extreme-to-Extreme
  • MPLS Scalable transport over any type of access and layer 1 technologies, in any segment of network (and between any network segment) and for any type of service.
  • all network routers distributed routers, border routers and sub-routers
  • E2E MPLS networks offer flexibility and homogeneity, while providing services on Pseudo-Cables (PW) in (and between) all network segments, simplification of network management and existence of defined mechanisms of Operation, Administration and Maintenance (OAM) of E2E for fault management.
  • PW Pseudo-Cables
  • OAM Operation, Administration and Maintenance
  • the most relevant example of E2E MPLS architectures is the MPLS Seamless.
  • the total failure time (that is, the time during which the service is not available) is made up of three time intervals.
  • the process comprises the following three stages: after a failure occurs, the first stage (i) is to detect what has happened, then (ii) locate where it has occurred and, finally, (iii) restore it.
  • An objective of any fault management system should be to reduce the total failure time as much as possible.
  • OAM protocols have been defined for Ethernet, IP and MPLS networks, and also for the PWE3 (Emulation of Pseudo Cables from Border to Border).
  • PWE3 Evolution of Pseudo Cables from Border to Border
  • tools such as LSP Ping or Bidirectional Remission Detection (BFD) have long been used for fault detection: monitoring messages are exchanged in band between pairs of routers and, when Some do not arrive, a fault is detected. After detection and location, MPLS networks can then execute the corresponding restoration mechanism.
  • QoS Quality of customer services
  • SLA Service Level Agreements
  • the MPLS-TP OAM tools are being defined primarily in the IETF (Internet Engineering Task Force), although in ITU-T there is another parallel definition based on similar mechanisms.
  • the OAM toolkit consists of a comprehensive set of fault management and performance monitoring capabilities, which can be used by operators to detect and locate defects more effectively.
  • the techniques of passive QoS monitoring are divided into two main groups.
  • passive monitoring techniques that make use of network traffic, complex processing algorithms and traffic distribution models to provide knowledge about the status of operators' networks. Examples of such techniques include Remote Monitoring (RMON), Simple Network Monitoring Protocol (SNMP) or NetFIow-enabled devices.
  • Remote Monitoring (RMON) is a standard protocol that allows various network monitors and console systems to obtain and exchange network monitoring data.
  • SNMP is also a standard protocol, oriented to the monitoring and configuration of network nodes.
  • NetFIow is a network protocol developed by Cisco Systems to collect IP traffic information, which has become an industrial standard for traffic monitoring, and has support on various platforms.
  • an alternative for passive monitoring consists of devices that monitor traffic as it passes. These devices can be devices of special purpose (passive probes) such as a tracker, or they may be embedded in devices such as routers, switches or hosts (e.g., support devices for Deep Packet Inspection - DPI).
  • - Active monitoring consists of devices that monitor traffic as it passes
  • the active monitoring approach relies on the ability to inject test packets into the network, or to perform measurements at the application level. As such, it creates extra traffic, traffic that is perfectly known to the monitoring system, so it can be identified. In that sense, it is very similar to OAM-based monitoring, although it is usually performed by probes external to the network nodes.
  • the active approach provides explicit control over the generation of packages for measurement scenarios (control over the nature of traffic generation, sampling techniques, package sizes, etc.) and timing; therefore, it implies testing what is required when required.
  • the mostly accepted classification includes active monitoring tools in two groups: PGM (Probe Gap Models) that base the estimation on the dispersion gap between two consecutive polling packets, and PRM (Probe Rate Models), whose estimates are supported in sending convoys of polling packages at increasing speeds.
  • PGM Probe Gap Models
  • PRM Probe Rate Models
  • monitoring in the physical layer is also very common in operator networks.
  • Such monitoring can be carried out by means of encapsulation procedures (LAN, WAN, G.709), which allow the physical layer to provide alarms such as loss of
  • MPLS restoration In addition to the tools already described above, there is still a Additional functionality that plays an important role once a fault is detected and located: MPLS restoration. Restoration mechanisms need to be activated to restore customer traffic flows, that is, to inject them on an alternative path that does not present any failure. In the MPLS there are several procedures to achieve such behavior, being the
  • the speed at which failures are detected depends on the time interval between monitoring messages: if this interval is short, the failures are detected very quickly, and few customer packages are lost. However, the bandwidth consumed by these messages is greater, preventing operators from using this bandwidth for customer traffic.
  • LSPs Switched Label Paths
  • E2E's MPLS solutions are based on a concept called the MPLS hierarchy, which means that Switched Label Paths (LSPs) can be established at different levels.
  • LSPs Switched Label Paths
  • the routers can act at the same time as 'border' or 'intermediate' nodes, according to the LSP considered, and that the information referring to some of these layers can be hidden from them.
  • this process is executed by an operator that activates the injection of monitoring packages by distributed active probes (or nodes that support OAM) at the different levels of MPLS, until the fault is found, a time-consuming process.
  • DPI are also rarely used for this purpose, since there are alternatives (such as the same monitoring protocols) that are specific to these characteristics; instead, they are used more frequently to gather information regarding clients in the service layer.
  • Passive monitoring protocols on the other hand, also have other limitations.
  • active monitoring tools Normally, active monitoring tools rely on delay measurements to provide their estimates of network QoS.
  • the delay of the packages depends on many factors, for example, the size of the package or the kind of traffic. Therefore, the patterns of injected traffic need to be as similar as possible to the actual patterns of customer traffic that runs through the network. Otherwise, the measurement would not be reliable. Real patterns are very complex and very variable today, so it is very difficult to obtain realistic models.
  • monitoring systems are only aware of network failures once the application layer has notified that the user is experiencing QoS degradation. This reactive behavior may not match the monitoring expectations, since it is not possible to locate the network fault with measurements at the application layer, which results in a very slow restoration of the service.
  • Active monitoring involves the injection of polling packets into the network.
  • OAM monitoring the same limitations are valid as for OAM monitoring: the problem of bandwidth consumption and the lack of automated solutions for fault detection.
  • the tools passive there is no direct internal communication between these polls and the MPLS layer in the network nodes, so the activation of the restoration mechanisms should be done through external systems (which normally require human intervention).
  • active monitoring tools will not be considered in this invention, except those of the application layer.
  • the present invention solves the aforementioned problems and overcomes the limitations of the state of the art explained above, revealing a method and system that make use of the monitoring mechanisms currently available for the detection of QoS degradation, in a coordinated and automated manner. , so that the monitoring load can be reduced. This is done by carrying out a centralized coordination of the monitoring mechanisms, which allows detecting potentially critical situations by means of light tools (that is, consumers of a low bandwidth), and then confirming or invalidating the degradation, leading to make more intense measurements only in those segments where you need to make them.
  • the present invention provides a method and system for the prevention, detection and automatic restoration of QoS degradations, while minimizing the monitoring bandwidth consumed for this purpose: the invention makes first use of low bandwidth consumption tools, and confirms that degradations take place using more powerful tools focused on specific segments, where an increase in bandwidth does not affect the total network behavior. The determination of critical segments also allows for faster restoration, which positively affects the availability of services.
  • the present invention makes use of the most powerful monitoring systems available in the market, coordinating them to increase the speed at which services are recovered after failures, and to reduce the number of monitoring packets injected into the network.
  • the procedures defined for the invention are automated, which once again increases the availability of services, since human intervention is avoided.
  • a method for restoring QoS degradations in MPLS networks comprises the following steps: receiving one or more alarms from the Application Layer, or from an MPLS network node,
  • a second aspect of the present invention relates to a system for determining QoS degradations in MPLS networks, comprising: communication modules of the service layer and the network layer, to receive alarms, respectively, from the Layer of Application and from an MPLS network node,
  • an alarm management and correlation module to correlate all alarms sent by the communication modules of the service layer and the network layer, and that are associated with a segment with failures in the same location
  • one or more calculation modules to determine the services affected by the correlated alarms, received from the alarm management and correlation module, with information on the location of the segment with failures, obtained from means of location of segments in the network of MPLS, and with access to a system database, from which the restoration paths for all affected services are obtained,
  • a signaling planner connected to the MPLS signaling, to enable the restoration of the affected services, using the restoration paths obtained when activated by any of the calculation modules,
  • an active monitoring trigger that is requested by any of the calculation modules, to obtain tests on the restored services, from the service layer to the communication module of the service layer, and from the network layer to the module network layer communication.
  • the active monitoring activator module not only activates tests of restored services, but also, in a preferred embodiment of the invention, activates the most intense tests (active tests) confirming degradations.
  • the active monitoring trigger can be requested by any of the calculation modules to actively obtain tests, for purposes of confirmation of degradation, or on the restored services.
  • the location means of the failed segments is a network node of the MPLS network, from which a system calculation module defined above receives an alarm, and therefore requests the location of this network segment.
  • the location means are provided by the system database, external or internal to the system, from which the location of the network segment used by the Application Layer is requested. by a system calculation module described above.
  • a computer program comprising computer program code means adapted to perform the steps of the described process when said program is executed on a computer, a digital signal processor, a formation of field-programmable gates, an application-specific integrated circuit, a micro-processor, a micro-controller, or any combination of the aforementioned and / or other form of programmable hardware.
  • the present invention provides a QoS Monitoring Administrator, with automation of detection, location and prevention or restoration of QoS in E2E MPLS networks.
  • An intelligent entity which coordinates different monitoring tools in order to proactively preserve QoS in MP2 networks of E2E, in an automated and scalable way, does not exist to date in the state of the art.
  • the intelligence of the QoS Monitoring Administrator system proposed here is able to track the MPLS network and automatically evaluate when, where and by which monitoring technique the QoS of a certain service / path should be monitored. Thus, no There is no need for human intervention in the monitoring process.
  • the scalability of the proposed QoS Monitoring Administrator system which focuses on active monitoring actions in those specific network segments in which the QoS is susceptible to degradation, is one of the most important features with added value, given that The size of the E2E MPLS networks makes it impossible to scale with overloaded or unnecessary monitoring processes.
  • the present invention is capable of reducing the number of total monitoring packets to confirm these QoS degradations, enhancing the scalability of the QoS Monitoring Administrator (QMM) system.
  • QMM QoS Monitoring Administrator
  • the ability of the QMM system to locate specific segments of the MPLS network, which are critical for QoS is an added value, not only in terms of monitoring resources, but also in terms of the time required for restoration and, therefore, in terms of service availability.
  • the present invention allows the maximization of the Quality of Service (QoS) of the end user in E2E-MPLS networks.
  • QoS Quality of Service
  • Figure 1 shows a system for determining QoS degradations and their relationships with other network entities existing in an MPLS network scenario, according to a preferred embodiment of the invention.
  • Figure 2 shows a message flow diagram in the system of Figure 1, to determine QoS degradations, according to a possible embodiment of the invention.
  • Figure 3 shows a message flow diagram in the system of Figure 1, to determine QoS degradations reported by alarms coming from the Application Layer, according to a possible application case of use of the invention.
  • Figure 4 shows a message flow diagram in the system of Figure 1, to determine QoS degradations reported by alarms from the Physical Layer or a Passive Traffic Analyzer, according to another possible application case of use of the invention.
  • Figure 5 shows a message flow diagram in the system of Figure 1, for determining QoS degradations reported by alarms from MPLS OAM tools, according to a possible additional application case of use of the invention.
  • Figure 6 shows a message flow diagram in the system of Figure 1, in a proactive mode of operation, to determine QoS degradations, according to another possible embodiment of the invention.
  • Figure 7 shows a block diagram of the system architecture, to determine QoS degradations in an MPLS network, according to one embodiment. Preferred of the invention.
  • Figure 1 presents a QoS Monitoring Administrator (QMM) as a system (10) to determine QoS degradations in an MPLS network (30), and also shows the specific relationships and interfaces between the system (10) and the modules existing, which are the following:
  • QMM QoS Monitoring Administrator
  • Service Support System (21) it is the module in charge of collecting the monitoring data of the application layer (20), obtained by means of active measurements, and send them to the system (10). It shares the same vision of quality experienced with end customers, and therefore is able to detect degradation or violations of the SLAs subscribed by them.
  • Passive Traffic Analyzer (32) this module or functional entity includes the passive measurements that the monitoring protocols can perform in the MPLS networks (30) of the operators. Therefore, they are located in the network nodes (31), although equivalent measurements carried out by external probes are also allowed.
  • Two possible modes of operation are considered (which can coexist simultaneously): mode of operation on demand, in which the system (10) consults the Passive Traffic Analyzer (32) to (perform, if necessary, e) inform about a passive monitoring process on a specific network node (31); and proactive mode of operation, in which the Passive Traffic Analyzer (32) automatically informs the system (10) about periodic passive measurements on certain network nodes (31).
  • Physical Layer Monitoring (33) a module consisting of the set of alarms that network nodes (31) can announce, referring to physical failures, such as loss of connectivity or poor transmission quality. These alarms are announced to the system (10).
  • MPLS OAM Tools a module consisting of the set of capabilities that allow operators to solve problems with MPLS networks (30). Since the destination MPLS network (30) may be based on the E2E MPLS, these tools are best suited for global monitoring. The light tools can be used proactively to detect situations of potential congestion on certain network areas, while others, executed on demand from the system (10), can be valid to confirm or reject the presence of such network failures, or with detection purposes when node / link failures occur (in case no faster tool is available).
  • MPLS signaling (35) this module allows the system (10) to initiate MPLS-based restoration processes in the network (30), in case certain network segments experience a lack of QoS.
  • System Database (36) this module stores the required information, both from the operator's network (30), for example, its status, configured paths, etc., and from the application layer (20), For example, active services.
  • FIG. 2 shows a flow chart of the communication messages exchanged in the network scenario illustrated above in Figure 1, which involves the QMM system (10) that makes use of prevention, detection and restoration procedures for QoS degradation , as described below.
  • Continuous lines in Figure 2 refer to mandatory procedures, while dashed lines are used for those procedures that are optional in the system (10).
  • This system (10) implements a procedure to determine QoS degradations, which comprises the following main stages:
  • the system (10) can request (d), usually from the network nodes (31), additional tests for location purposes, so the network nodes (31) answer with answers (e) of location.
  • the system (10) directly initiates the traffic restoration procedures (h), by interacting with the MPLS Signaling module (35), and receives the result (i).
  • the system (10) may need to consult the System Database (36) before making any additional decisions; this stage of consulting the Database (36) is optional, before request location tests, the consultation stage (b) and the corresponding response (c), while the consultation stage (f), with its corresponding response (g), before starting the restoration procedures (h), is mandatory.
  • test procedures are activated (j) by the system (10) to ensure the correct global QoS within the new network situation.
  • test procedures can be carried out (k) by the network nodes (31) and / or the application layer (20).
  • the mechanisms to recover the original traffic situation once the fault is repaired can be governed by the well-known "do before breaking" mechanisms available for MPLS networks, and they would be activated by the operator at any convenient time for it.
  • the procedure incorporates the optional possibility of selecting the alarm correlation criterion, so that, when several are received, possibly referred to the same QoS fault , the system (10) is able to compile and manage all of them, correlate them and execute the appropriate corrective actions.
  • the criteria for the management of alarms are the following: - in the case where several alarms reach the QMM system (10) in a short (configurable) period of time, the system (10 ) confers a higher degree of priority to alarms that present (in general) faster error localization mechanisms.
  • Each of the monitoring procedures therefore, has been labeled with A priority weighting.
  • the physical layer (33) and passive monitoring protocols (32) can quickly locate the problem experienced in the network, since both generate alarms at the exact point where the fault occurs.
  • the alarms of the physical layer (33) will have a higher degree of priority (the second globally), however, due to its detection time, the fastest, and due to the very common operational need to quickly overcome any degradation of the physical layer that could occur. Therefore, the monitoring alarms of the passive traffic analyzer (32) will be managed with the third priority level when they reach the QMM system (10).
  • the MPLS OAM monitoring mechanisms (34) normally involve the rapid detection of anomalies, but at the cost of bandwidth, as expressed above.
  • the time to locate the affected segment depends on many variables, so these alarms will be given the minimum level of priority (fourth globally).
  • this system (10) is able to manage them: first attending to those that locate the faults more quickly, the system (10) is capable after determining which nodes / links and LSP / services are affected, and is able to correlate the rest of the alarms, so that they do not need to be considered. It is important to mention that having a longer detection or location time does not prevent the alarms of the slowest modules from appearing in the total network scenario, since each tool can monitor different parameters and is more suitable for different purposes.
  • Figures 3 to 6 extend the basic workflow described above in Figure 2, and include the interactions that take place between the QMM system (10) and the existing modules in various use cases.
  • Two main categories of use cases can be defined: those cases, shown in FIGs. 3 to 5, in which the operation of the QMM system (10) is reactive, that is, it reacts after the degradation of QoS has occurred; and those such as the one shown in Figure 6, in which the QMM system (10) is proactive, that is, reacts by trying to avoid the degradation of QoS before it occurs.
  • Figure 3 shows the specific workflow for a use case in which the alarm is received from the application layer (20), which means that the client is aware of the degradation of QoS, so that the operation System (10) QMM must be reactive, to quickly resolve the alarm situation.
  • the system (10) receives an alarm (a1) from the application layer (20), and consults (b1) the Database (36) to obtain (c1) the network path that is being used by the application layer (20) for the given service, to which the alarm refers. Then, the system (10) internally checks other potential alarms that may have been received from network nodes (31) by the QMM system (10) along that specific path.
  • the system (10) finds any (which normally should be the case), it groups them according to the specific network segment or node that is affected (if it is already identified by the other alarms) and jumps to a stage (f1) of Consult the Database (36) again, looking for information on all the services that could potentially be affected by such events. Subsequent step (g1) is the Answer given by the Database (36). On the contrary, if no other alarm is present, or those present have not yet located the segment, or the segments, affected (s), then the QMM system (10) requests (d1) the OAM mechanisms (34) MPLS on the network nodes (31) that carry out specific operations on demand to locate the fault, according to the type of alarm received from the application layer (20).
  • the MPLS OAM tools (34) could be those that measure the packet delay along the path. Tests carried out by MPLS OAM tools (34) should first be referred to the end-to-end path. In the event that the result (e1) of the operations of the OLS mechanisms (34) of MPLS to locate the fault is adequate, then the system (10) declares that potential problems can be located within the customer's premises. The resolution of such problems is also outside the scope of the invention.
  • step ( ⁇ 1) Once the fault is located by MPAM OAM (34), and this location result (e1) is received by the QMM system (10), then the system (10) continues with steps (f1) and (g1) of inquiry and response, respectively, to / from the Database (36), equivalent to those described above.
  • the system (10) has a clear vision of which services may be affected by the different degradations, so it activates (h1) the MPLS signaling (35) to initiate protection / restoration mechanisms for each of the services affected by the alarm.
  • the results of the restoration procedures are provided in step ( ⁇ 1).
  • the QMM system (10) needs to check the correct operation of all restored services, so it activates (j1) on-demand monitoring mechanisms, either in the application layer (20), if possible, according to the availability of such tools in the different facilities of the clients, or by means of OAM (31) of MPLS, which is always available.
  • the test results are provided in step (k1).
  • the system (10) again consults (11) the Database (36) in search of alternative paths for those services, and repeats (in a loop) the execution of stages from () to (k1) for those alternative paths.
  • FIG 4 shows the specific workflow of another use case in which the operation of the QMM system (10) is reactive for an alarm received from the physical layer monitoring tools (33).
  • the QMM system (10) receives an alarm (a2) from the physical layer monitoring tools (33), and does not need to execute the location operations, that is, avoiding the stages from (b) to (e) in the basic flow of Figure 2, since these tools already provide such information. Therefore, the system (10) goes directly to the collection of other potential alarms referred to the same segment (coming from the network nodes (31) with lower alarm priority), and jumps to step (f2) to consult the Database (36) in search of information about all the services that could be potentially affected by this specific event. The response of the Database (36) is given in step (g2).
  • the QMM system (10) has a clear vision of which services may be affected by degradation, so it activates (h2) the MPLS signaling mechanisms (35) to initiate protection mechanisms for each of those services.
  • the results of the restoration procedures are They provide on stage ( ⁇ 2).
  • the QMM system (10) needs to check the correct operation of all the restored services, so it activates the monitoring mechanisms (j2) on demand, either in the application layer (20), if possible, according to the availability of such tools in different customer facilities, or through MPAM OAM (31), which is always available.
  • the results of the tests are provided in step (k2).
  • the QMM system (10) again consults ( ⁇ 2) the Database (36) in search of alternative paths for those services, and runs in a loop, if required, the stages from (h2) to (k2) for those alternative paths.
  • the QMM system (10) can only be aware of such a situation in step (g2); In these cases, the tasks of the system (10) are restricted to those services that cannot be automatically recovered. The operation for them is equivalent to what has already been described in the case of use of Figure 4.
  • step (a2) the system (10) receives the alarm from the passive traffic analyzer (32), instead of the physical layer monitoring tools (33).
  • the types of alarm that the system (10) needs to search in correspondence with the segment are those that arrive only from the MPAM OAM tools (34), since they are the ones with the lowest priority.
  • FIG. 5 shows a specific workflow from another use case, in which the operation of the QMM system (10) is reactive for an alarm received from the MPLS OAM tools (34).
  • MPLS networks (30) monitoring can be done at different levels of MPLS, and between different pairs of MPLS network nodes (31), even if they are not directly connected. Therefore, the operation of the system (10) depends on how this is done. monitoring
  • MPLS instead of physical layer monitoring tools (33), or passive traffic analyzer (32),
  • the QMM system (10) receives an alarm (a3) from the MPAM OAM tools (34). There is no need to consult the network path in this case, that is, avoiding stages from (b) to (c) in the basic flow of Figure 2, since it has been explicitly defined in the monitoring tool and it is well known. In addition, since there is no additional alarm to correlate, the location procedure is mandatory: the QMM system (10) requests (d3) the MPLS OAM (34) mechanisms in the network nodes (31) to carry out specific operations on demand, segment by segment, to locate the fault, and their responses are sent back in step (e3). After the location, the QMM system (10) advances to step (f3) to consult the Database (36) for information on all the services that could potentially be affected by the localized event.
  • step (g3) The response of the Base of Data (36) is given in step (g3).
  • the QMM system (10) again has a clear vision of which services can be affected by the different degradations, so it activates (h3) signaling mechanisms (35) to initiate the protection mechanisms for each of those services.
  • the results of the restoration procedures are provided in ( ⁇ 3).
  • the QMM system (10) needs to verify the correct operation of all the restored services, so it activates the monitoring mechanisms (j3) on demand, either in the application layer (20), if possible, according to the availability of such tools in different customer facilities, or through MPAM OAM (31), which is always available.
  • the test results are provided in stage (k3).
  • the QMM system (10) again consults (13) the Database (36) in search of alternative paths for those services, and executes, if required, in a loop, the stages from (h3) to (k3) for those alternative paths.
  • the system In networks with their own automatic restoration procedures, the system
  • Figure 6 shows the QMM system (10) capable of reacting to potential degradations proactively, that is, even before they occur.
  • the main event from which the QMM system (10) can protect the network (30) is traffic congestion.
  • Three areas of network operation can be distinguished
  • the QMM system (10) initially uses the passive traffic analyzer (32) for passive monitoring, without therefore consuming network bandwidth to detect "potentially conflicting" situations.
  • the SNMP protocol for example, can monitor network bandwidth until a certain threshold is exceeded. At that time, faster and more accurate monitoring is needed, and is provided by MPLS OAM tools (34) within the network segment that is "potentially conflicting.”
  • This type of monitoring is to detect and locate "critical" situations very quickly: since the network segment to be monitored has been very small, the problem of bandwidth consumption is strictly controlled, and the amount of monitoring packets that can being injected can be high enough to guarantee adequate benefits.
  • the passive monitoring tools of the passive traffic analyzer (32) are continuously measuring network traffic and, in the case of measuring bandwidths that exceed the specified threshold for "potentially conflicting" situations, generate an alarm (a4) to the QMM system (10), as shown in the flow chart of Figure 6.
  • the specific segment is already located by the passive tool, so the QMM system (10) is able to request (d4) directly from the MPLS OAM tools (34) that run tests you continue with high demand for bandwidth over that segment.
  • the passive traffic analyzer (32) that is running can still detect that the network segment has returned to the zone of
  • the MPLS OAM tools (34) announce it (e4) to the QMM system (10), which, in turn, initiates a similar procedure, in which stages between (f4) and (14), to other use cases, for example, in the case of using alarm reception from OAM (34) of MPLS, shown in Figure 5.
  • the QMM system (10) does not need to modify the path for all the services that run through the "critical” segment, but only for those sufficient between them to return to the "potentially conflicting" situation (eventually notified by a new alarm from the OAM tools (34) of MPLS) and ii) the modification of paths must be made without any loss of traffic.
  • the QMM system (10) modifies and verifies one service path at a time, until it receives an alarm from the MPLS OAM tools (34), indicating that the situation has become "potentially conflicting" again.
  • the candidate service for the migration selection criteria is outside the scope of this invention.
  • the passive traffic analyzer (32) can eventually determine the
  • Figure 7 illustrates the architecture of the proposed system (10) QMM, Service Quality Monitoring Administrator, including the different modules and interfaces.
  • the system (10) does not need to be built on a single physical machine; it is possible to distribute the different functionalities by different physical elements, in particular, by the same nodes of the MPLS network, with the only requirement to implement the required functionalities of the interfaces.
  • at least one processor and Ethernet connectivity to all required external modules is required. However, multiple processors are recommended for higher performance.
  • a further description of the different modules and the different interfaces, internal and external, is provided below, according to a possible embodiment of the invention.
  • CM it constitutes the brain and the intelligence of the system (10) and is in charge of coordinating all the operations executed in the different possible use cases, as described above.
  • CM it constitutes the brain and the intelligence of the system (10) and is in charge of coordinating all the operations executed in the different possible use cases, as described above.
  • Alarm Management and Correlation module (106) probe the Passive Traffic Analyzer module (32) of the network nodes (31), using the COMM module of the Network Layer (102) for communication of the network layer, when the Passive Traffic Analyzer (32) is operating in the on demand mode.
  • the passive measurement to be probed is decided by the Calculation Module (100), according to the type of alarm received.
  • the Active Monitoring Activator module (107) initiate active monitoring procedures, either in the external Service Support System, through the Service Layer COMM module (101), or in the OAM modules (34) of MPLS of the network nodes (31), by means of the COMM module of the Network Layer (102).
  • the type of active measurement to be activated is decided by the Calculation Module (100), according to the type of alarm received.
  • Service Layer, Network Layer, Database modules (101, 102, 103, 105) Operator COMM and external interface systems of the Signaling Planner module (104).
  • the common objective of such modules (101, 102, 103, 104, 105) is to hide the specific details of potentially different implementations of the external interfaces from the QMM processing modules, unifying communications to the internal modules.
  • the System Database (36) can be implemented using different technologies and, therefore, the interface (203) DDBB - DBCOMM can present different technical implementations, all supporting the same set of requirements.
  • the DBBB COMM module (103) is then in charge of translating the different format messages, providing messages unified by the interface (212) CM - DBCOMM.
  • Service Layer COMM (101), SLCOMM: maintains interfaces with the Service Support System (21) to receive alarms or request active tests at the service layer. The alarms received are then sent to the Alarm Management and Correlation module (106), while the activation of active tests is does in the Active Monitoring Activator module (107).
  • COMMde the Network Layer (102), NLCOMM maintains interfaces with the network nodes to receive alarms from different external systems: i) Physical Layer Monitoring (33), ii) Passive Traffic Analyzer (32) and / or iii) OAM (34) of MPLS.
  • the alarms received are sent to the Alarm Management and Correlation module (106), a module that also activates passive polling on demand.
  • the activation of active tests is done in the module (107) Active Monitoring Activator.
  • DDBB COMM (103), DBCOMM: maintains interfaces with the System Database (36) to receive information regarding the status of networks / services, or regarding new paths on which to provide restored services. This information is requested by the Calculation Module (100).
  • Calculation can also provide, through this module, the System Database (36) the changes in the status of networks / services that the QMM system (10) has detected.
  • Signaling Planner (104), SS maintains interfaces with functionalities of
  • OCOMM 105) of the Operator, OCOMM: provides an interface for the operator (700) to configure both the priority levels of the different alarms that could be received and the thresholds between the operation zones for the use case in which the System (10) QMM works proactively, values that are stored in the Configuration module (109). Its external interface allows the operator (700) to consult information about the alarms occurred and also the actions carried out, information arrived from the module (1 10) of Record storage.
  • the rest of the internal processing modules of the QMM system (10) are: Alarm Management and Correlation (106), AMC: this module is in charge of processing the different alarms received from the external modules, through the modules (101, 102 ) COMM of the Services Layer and the Network Layer. After receiving an alarm, it determines the priority according to the values provided by the Configuration module (109), and executes the correlation algorithm associated with that priority (basically, checks the existence of alarms with less priority that refer to the same fault). The grouped alarms are then sent to the Calculation Module (100), so that you can initiate the procedures, as indicated in the description of the use cases. The correlation process is governed by a Synchronization Clock (108), thereby ensuring that alarms separated in time are treated differently.
  • AMC Alarm Management and Correlation
  • Alarm Management and Correlation (106) is also in charge of probing the external Passive Traffic Analyzer (32), through the module (102) COMM of the Network Layer, as requested by the Module (100) of
  • AMT Active Monitoring Activator (107), AMT: this module is in charge of incentivizing the active tests available in external systems, in particular, in the Service Support System (21) for tests in the service layer, or using the MPAM OAM tools (34) from the network nodes. Communication with the former is done through the module (101) COMM of the Service Layer, while the module (102) COMM of the Network Layer allows communication with the latter. The execution of external active tests is requested by the Calculation Module (100), and the results are provided back by the Active Monitoring Activator (107).
  • CONF stores the configuration parameters provided by the operator for the priority values to be given to each of the alarms to potentially receive, and for the two thresholds that separate the operation zones in the case of use in which the QMM system (10) works proactively.
  • the first set of parameters is then referred to the Alarm Management and Correlation module (106), while the second is referred to the Calculation Module (100).
  • Both interfaces share the same procedure: To send all alarms received from external monitoring systems to the Alarm Management and Correlation module (106).
  • the format of the messages differs, depending on the specific external module that generates the alarm, since different types of information are available in each procedure; in particular, whenever "fault location" information is available, it should be added to the body of the message.
  • the response message from the Alarm Management and Correlation module (106) is an acknowledgment.
  • the NLCOMM - AMC Interface (207) also allows another procedure: the Alarm Management and Correlation module (106), to request a certain type of external passive measurement at the network nodes.
  • the request message must include: i) the network node, or interface, where the measurement should be made, ii) the type of measurement to be made, p.
  • the input for the last parameter could have the form of "until a certain threshold is exceeded", as required by the use case in which the QMM system (10) operates proactively.
  • the response message from the COMM (102) module of the Network Layer provides the result of the requested measurement.
  • the request message must include: i) the specific service - in the case of service layer monitoring - or the network segment / node / interface - in the case of network layer monitoring - to be tested, ii) the type of measurement to be made, e.g. eg, experienced delay, and iii) for how long, or how many repetitions should be done.
  • the input for the last parameter may have the form "until a certain threshold is exceeded", as required by the use case in which the QMM system (10) operates proactively.
  • the response messages from the modules (101, 102) COMM of the Service Layer and the Network Layer provide the result of the requested measurement.
  • CM - AMC Interface (210): Allows two procedures: to the Alarm Management and Correlation module (106), to send correlated alarm sets to the Calculation Module (100).
  • the format of these messages differs, according to the specific external module that generates the alarm, as indicated also for the Interfaces (206, 207) SLCOMM - AMC and NLCOMM - AMC.
  • the response message from the Calculation Module (100) is an acknowledgment. to the Calculation Module (100), to request a certain type of passive measurement external to the Alarm Management and Correlation module (106).
  • the format of the request and response messages should match a scheme equivalent to the second procedure in the NLCOMM - AMC Interface (207).
  • CM - AMT interface (21 1): Allows a procedure.
  • the Calculation Module (100) request a certain type of active measurement external to the Active Monitoring Activator module (107).
  • the request message includes the same information as for the SLCOMM - AMT (208) or NLCOMM - AMC (209) Interfaces, with an additional field to specify the external element to carry out the measurement, that is, if it needs to be managed by the probes of the application layer or the OAM mechanisms (34) of MPLS.
  • the response message from the Active Monitoring Activator module (107) provides the result of the requested measurement.
  • CM - DBCOMM interface (212): It allows four types of procedures, three of requests from the Calculation Module (100) to the DBCOMM module (103), and an informative one, at the same address: i) Requesting the path that a route is traveling specified service, so that location procedures can be initiated after an alarm is received from the application layer.
  • the request message includes a service identifier, while the response includes the path, for example, in the form of an Explicit Route Object, or ERO.
  • the request message includes the path, for example, in the form of an ERO, while the response provides a list with the service identifiers.
  • a specific module for the calculation of paths is required in the external Database of the System for this purpose.
  • An example of such a module is the Path Calculation Element - PCE - defined by the IETF.
  • the request includes the service identifier, while the response includes the new ERO.
  • the informational message includes different fields, depending on the specific event being recorded, while the response includes only an acknowledgment of receipt.
  • CM - SS Interface (213): Allows a procedure: to the Calculation Module (100), to request a restoration operation from the Signaling Planner (104).
  • the request message must include: i) the service, or services, that needs to be restored (s), and ii) the network path over which these services should be restored. It should be noted, therefore, that services can be grouped into a single request when they share the same new path. The services affected by the same fault, but restored on different paths, generate different requests in this interface.
  • the response from the SS module (104) includes the result of the restoration operation (completed successfully or not, and the reason in the latter case).
  • OCOMM - CONF (214) interface It allows two procedures: to the COMM module (105) of the Operator, to store in the Configuration module (109) the priority values set by the operator (700) for the different external alarms available in the monitoring system The message includes a non-repeated integer value for each type of alarm, and the response is an acknowledgment.
  • the COMM module (105) of the Operator to store in the Configuration module (109) the two threshold values that separate the three operation zones defined in the use case in which the QMM system (10) operates proactively.
  • the message includes two values between 0 and 100, corresponding to the bandwidth usage values that separate such zones.
  • the answer is an acknowledgment of receipt.
  • CONF - CM interface Allows a procedure: to the Configuration Module (109), to store in the Calculation Module (100) the threshold values that define the zones of operation (use case in which the system ( 10) QMM works proactively), values that are configurable by the operator (700).
  • the message includes two values, which separate the "correct" and
  • OCOMM - LS (217) interface allows a procedure: to the Operator COMM module (105), to request from the Registry Storage module (1 10) the information that allows to have a clear knowledge of what events have occurred, and what actions corrective measures have been adopted by the system
  • LS - CM Interface Allows a procedure: to the Calculation Module (100), to store in the module (1 10) of Record Storage all the information required by the operators (700), as indicated in the Interface (217) OCOMM - LS. The answer is an acknowledgment of receipt.
  • SC - AMC interface Allows a procedure: to the Synchronization Clock (108), to provide the timing for the correlation procedures in the Alarm Management and Correlation module (106). This is a continuous clock signal, without any specific message exchanged.
  • External interfaces are interfaces that allow communication with external systems that can present many different kinds of interface implementations. In this way, for the specific internal procedures of the QMM system (10) the details of the external systems implementation technologies are hidden, and they share unified message formats. Thus, a new interface implementation of an external module only requires modifications to the COMM modules and the interfaces of the QMM system (10).
  • SSS Interface - SLCOMM (201) is the origin of the service layer alarms, retransmitted by the SLCOMM - AMC (206) interface, and retransmits the measurement requests of the active service layer that arrive from the SLCOMM interface -
  • NN - NLCOMM interface (202) it is the origin of the network layer alarms relayed by the NLCOMM - AMC interface (207), and retransmits the requests for passive and active network layer measurements, which arrive from the interfaces
  • DDBB - DBCOMM interface (203) retransmits requests and informational messages that arrive from the CM - DBCOMM (212) interface.
  • MPLS Sig - SS (204) interface retransmits requests that arrive from the (213) CM-SS interface.
  • Operator Interface - OCOMM (205) is the origin of the configurable parameters retransmitted through the OCOMM-CONF interface (214), and the operator's requests (700) for record information, retransmitted through the OCOMM-LS interface (217).

Landscapes

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

Abstract

Un sistema (10) que implementa un procedimiento para determinar degradaciones de QoS comprende: - recibir alarmas (a) desde la capa de aplicación (20), o desde los nodos (31) de red de una red de MPLS, incluyendo el Analizador de Tráfico Pasivo (32), la Monitorización de Capa Física (33) y los nodos de OAM (34) de MPLS, - según la alarma, el sistema (10) solicita pruebas (d) para la localización y los nodos (31) de red responden con la localización (e), - una vez que el fallo está localizado, el sistema (10) inicia la restauración (h) del tráfico mediante la Señalización (35) de MPLS y recibe el resultado (i), - el sistema (10) puede necesitar consultar la Base de Datos (36) del Sistema: la etapa de consulta (b) – respuesta (c) antes de solicitar la localización es optativa, mientras que la etapa de consulta (f) – respuesta (g) es obligatoria antes de la restauración (h), - una vez que el tráfico está restaurado, el sistema (10) activa (j) pruebas adicionales por los nodos (31) de red y / o la capa de aplicación (20) por para garantizar la QoS global correcta dentro de la nueva situación de red, - el sistema (10) puede activar un bucle (i) de restauración adicional hasta que se declare un comportamiento global estable no degradado.

Description

DESCRIPCIÓN
PROCEDIMIENTO Y SISTEMA PARA RESTAURAR DEGRADACIONES DE LA
QOS EN REDES DE MPLS
Campo de la invención
La presente invención tiene su aplicación dentro del sector de las telecomunicaciones y, especialmente, se refiere a la Garantía de Calidad en redes de ordenadores y, más específicamente, se refiere a un sistema y procedimiento para impedir, detectar y restaurar las degradaciones de la Calidad del Servicio (QoS) en redes de Conmutación de Etiquetas MultiProtocolo (MPLS) de Extremo-a- Extremo (E2E).
Antecedentes de la invención
Las redes del Núcleo del Protocolo de Internet (IP) se despliegan normalmente sobre la tecnología de Conmutación de Etiquetas MultiProtocolo (MPLS), debido a la amplia gama de ventajas que proporciona esta encapsulación, en términos de Ingeniería de Tráfico (TE), provisión homogénea de cualquier tipo de servicio, herramientas de restauración y mantenimiento de la Calidad del Servicio (QoS). Por esos motivos, en los últimos años pasados, la MPLS también ha experimentado una extensión a otros segmentos existentes, como las redes regionales. Sin embargo, estos dominios de la MPLS normalmente se han mantenido separados, al menos en los grandes operadores, debido, principalmente, a motivos de escalabilidad.
Muy recientemente, se ha hecho un esfuerzo para definir las denominadas redes de MPLS de Extremo-a-Extremo (E2E), lo que significa transporte ajustable a escala de MPLS sobre cualquier tipo de acceso y tecnologías de la capa 1 , en cualquier segmento de red (y entre cualquier segmento de red) y para cualquier tipo de servicio. En otras palabras, todos los encaminadores de red (encaminadores de distribución, encaminadores fronterizos y metro-encaminadores) proporcionan una única capa de transporte basada en MPLS para cualquier servicio establecido entre nodos de Acceso y nodos de Servicio. Las ventajas principales que las redes de MPLS de E2E ofrecen son la flexibilidad y homogeneidad, proporcionando a la vez servicios sobre Seudo-Cables (PW) en (y entre) todos los segmentos de red, la simplificación de la gestión de red y la existencia de mecanismos definidos de Operación, Administración y Mantenimiento (OAM) de E2E para la gestión de fallos.
El ejemplo más relevante de las arquitecturas de MPLS de E2E es la MPLS Sin Fisuras. Sin embargo, una de las cuestiones más importantes que presentan las redes de MPLS de E2E está precisamente referida a la gestión de fallos. El tiempo total de fallo (es decir, el tiempo durante el cual el servicio no está disponible) está compuesto por tres intervalos temporales. El proceso comprende las siguientes tres etapas: después de que ocurre un fallo, la primera etapa (i) es detectar que ha ocurrido, luego (ii) localizar dónde ha ocurrido y, finalmente, (iii) restaurarlo. Un objetivo de cualquier sistema de gestión de fallos debería ser reducir lo máximo posible el tiempo total de fallo.
Para ese fin, los procesos automatizados son un requisito; si cualquiera de las tres etapas anteriores, (i) detección, (ii) localización o (iii) restauración, necesita intervención humana, entonces el tiempo de respuesta aumenta, y el servicio no está disponible durante un tiempo más largo. La MPLS permite varios mecanismos automatizados de restauración, aunque vale la pena mencionar que no son rápidos en todas las ocasiones.
Además, estos no son los únicos retos: los procesos actuales de gestión de fallos (y los mecanismos de restauración) tratan principalmente con fallos de Pérdida de
Conectividad (LoC), pero existen otras averías que también afectan a la QoS, como la congestión de red, por ejemplo. Por tanto, la gestión adecuada de fallos también necesita abordar tales causas de degradación. Las actuales herramientas de monitorización de MPLS y las soluciones de restauración se describen brevemente a continuación:
- Monitorización de OAM de la MPLS
Los protocolos de OAM han sido definidos para redes de Ethernet, IP y MPLS, y también para la PWE3 (Emulación de Seudo Cables de Frontera a Frontera). En particular, para MPLS y PWE3, las herramientas como LSP Ping o la Detección de Remisión Bidireccional (BFD) han sido usadas desde hace largo tiempo para la detección de fallos: los mensajes de monitorización son intercambiados en banda entre pares de encaminadores y, cuando algunos no llegan, se detecta un fallo. Después de la detección y la localización, las redes de MPLS pueden ejecutar luego el correspondiente mecanismo de restauración. Recientemente, tales herramientas tradicionales han sido extendidas en el contexto de MPLS-TP con capacidades realzadas de MPLS de OAM, que permiten a los proveedores de redes monitorizar la disponibilidad de la red y la calidad de los servicios de clientes (QoS), y proporcionar los SLA (Acuerdos de Niveles de Servicios) requeridos. Las herramientas de OAM de MPLS-TP están siendo definidas principalmente en la IETF (Fuerza de Tareas de Ingeniería de Internet), aunque en ITU-T hay otra definición paralela basada en mecanismos similares. El juego de herramientas de OAM consiste en un conjunto exhaustivo de capacidades de monitorización de la gestión de fallos y de las prestaciones, que puede ser usado por los operadores para detectar y localizar defectos más efectivamente.
Monitorización pasiva
Las técnicas de monitorización pasiva de la QoS se dividen en dos grupos principales. Por una parte, existen técnicas de monitorización pasiva que hacen uso del tráfico de red, algoritmos complejos de procesamiento y modelos de distribución del tráfico para brindar conocimientos acerca del estado de las redes de los operadores. Los ejemplos de tales técnicas incluyen la Monitorización Remota (RMON), el Protocolo Sencillo de Monitorización de Red (SNMP) o dispositivos capacitados para NetFIow. La Monitorización Remota (RMON) es un protocolo estándar que permite a diversos monitores de red y sistemas de consola obtener e intercambiar datos de monitorización de red. El SNMP es también un protocolo estándar, orientado a la monitorización y configuración de nodos de red. Finalmente, NetFIow es un protocolo de red desarrollado por Cisco Systems para recoger información de tráfico del IP, que se ha convertido en un estándar industrial para la monitorización del tráfico, y que dispone de soporte en diversas plataformas. Por otra parte, una alternativa para la monitorización pasiva consiste en dispositivos que monitorizan el tráfico según pasa. Estos dispositivos pueden ser dispositivos de propósito especial (sondas pasivas) tales como un rastreador, o pueden estar incrustados en dispositivos tales como encaminadores, conmutadores o anfitriones (p. ej., dispositivos de soporte de la Inspección Profunda de Paquetes - DPI). - Monitorización activa
El enfoque de monitorización activa se apoya en la capacidad de inyectar paquetes de prueba en la red, o de realizar mediciones al nivel de las aplicaciones. Como tal, crea tráfico extra, tráfico que es perfectamente conocido para el sistema de monitorización, por lo que puede ser identificado. En ese sentido, es muy similar a la monitorización basada en OAM, aunque es usualmente realizada por sondas externas a los nodos de red. El enfoque activo proporciona control explícito sobre la generación de paquetes para escenarios de medición (control sobre la naturaleza de la generación del tráfico, técnicas de muestreo, tamaños de paquete, etc.) y la temporización; por tanto, implica probar lo que se requiere cuando se requiere. La clasificación mayoritariamente aceptada comprende herramientas de monitorización activa en dos grupos: PGM (Modelos de Brecha de Sondeo) que basan la estimación en la brecha de dispersión entre dos paquetes sondeadores consecutivos, y PRM (Modelos de Tasa de Sondeo), cuyas estimaciones se apoyan en enviar convoyes de paquetes de sondeo a velocidades crecientes. En la bibliografía pueden identificarse varias iniciativas y desarrollos de tales herramientas. Las herramientas de monitorización activa pueden ser ejecutadas continuamente (habitualmente, para la gestión proactiva de fallos) o bajo demanda (usualmente con propósitos reactivos, después de que alguna alarma ha sido generada por otro mecanismo).
Monitorización de la capa física
Aparte de la monitorización en las capas 2, 3 y demás, la monitorización en la capa física también es muy común en las redes de los operadores. Tal monitorización puede ser llevada a cabo mediante procedimientos de encapsulación (LAN, WAN, G.709), que permiten que la capa física proporcione alarmas como Pérdida de
Señal, Pérdida de Trama, Indicación de Defecto Remoto, etc., al correspondiente sistema de gestión.
Además de las herramientas ya descritas anteriormente, hay todavía una funcionalidad adicional que juega un papel importante una vez que un fallo es detectado y localizado: la restauración de MPLS. Los mecanismos de restauración necesitan ser activados para restaurar los flujos de tráfico de clientes, es decir, para inyectarlos sobre un trayecto alternativo que no presenta ningún fallo. En la MPLS existen varios procedimientos para lograr tal comportamiento, siendo el
Reencaminamiento Rápido (FRR) el más común. Además, por la razón que sea (p. ej., cuando se detecta congestión), los operadores de red pueden querer desplazar la carga de tráfico desde un segmento de red a otro. Tal operación necesita ser ejecutada sin ninguna pérdida del tráfico de clientes, lo que se conoce como el enfoque de "hacer antes de romper". En la MPLS es posible hacer ingeniería de tráfico (TE) usando RSVP-TE, una extensión del Protocolo de Reserva de Recursos (RSVP). Tanto la restauración como los procesos de ingeniería de tráfico pueden estar determinados como reversibles o no reversibles. Esto significa que es posible determinar si el tráfico debe revertirse al trayecto original, o no, una vez que el fallo ha sido reparado.
Además, a fin de hacer ingeniería de tráfico (TE) basada en retardos y pérdidas, hay varias propuestas de la IETF (en una fase previa a la estandarización), que incluyen la posibilidad de monitorizar las condiciones de red antes del establecimiento de cualquier servicio de conectividad, p. ej., usando el estado de red como entrada para la determinación del mejor trayecto. Esta característica es esencialmente distinta a las presentadas anteriormente, que están centradas en la monitorización de los servicios actualmente configurados. Otro ejemplo que merece la pena mencionar es el procedimiento y aparato para el soporte de gestión de redes de la funcionalidad de OAM revelada en el documento EP1 176759, que describe un sistema de gestión de red con una interfaz gráfica de usuario (GUI) que comprende varias características para facilitar el trabajo de los operadores humanos, es decir, para facilitar la configuración y la recolección de resultados de la monitorización basada en OAM. Por lo tanto, aún se requiere la intervención humana. Los únicos procesos automatizados descritos allí son (i) la configuración de funcionalidades de OAM a lo largo de los nodos que forman los trayectos (primario y de resguardo) y (ii) la recolección de los resultados de pruebas de OAM y su presentación al operador mediante la GUI. Es aún el operador humano quien determina cuáles pruebas deben ser llevadas a cabo tras la recepción de una alarma. Además, el procedimiento descrito en el documento EP1 176759 no incluye características de prevención para la degradación de la QoS.
Las soluciones previamente presentadas del estado de la técnica representan distintos enfoques para llevar a cabo la monitorización y la medición de las prestaciones en redes reales. No obstante, funcionando como características aisladas, ni están adaptadas ni resuelven todos los problemas presentados, especialmente en términos de consumo de ancho de banda y de funcionamiento automatizado en redes de MPLS de E2E. Algunas deficiencias de las soluciones existentes se describen a continuación:
Limitaciones de la monitorización actual de OAM
Dado que los mecanismos de detección de OAM están basados en monitorizar paquetes inyectados en banda, entre pares de nodos en la red, la velocidad a la que se detectan los fallos (y, por tanto, la cantidad de tráfico de clientes que se pierde antes de que se restaure el fallo) depende del intervalo temporal entre mensajes de monitorización: si este intervalo es corto, los fallos son detectados muy rápidamente, y se pierden pocos paquetes de clientes. Sin embargo, el ancho de banda consumido por estos mensajes es mayor, impidiendo a los operadores usar este ancho de banda para el tráfico de clientes. Con las actuales arquitecturas de redes, donde los dominios Central y Regional de MPLS están aislados, el número de Trayectos Conmutados de Etiquetas (LSP) que necesitan monitorización es del orden de los miles. De tal modo, el consumo de ancho de banda por la monitorización de paquetes está limitado, y la velocidad de detección puede ser rápida. Sin embargo, en la evolución hacia la MPLS de E2E, con cientos de miles (o incluso millones) de LSP, en potencia, recorriendo todos los dominios de red hasta el acceso, este consumo aumenta mucho, presentando problemas de escalabilidad si se desea la detección rápida. Ha de observarse que los mensajes de monitorización se envían en banda, es decir, por los mismos enlaces físicos según los paquetes de clientes viajan por la red. El problema del consumo del ancho de banda podría ser resuelto por medio de la monitorización fuera de banda, usando distintos enlaces físicos, pero con este enfoque solamente podrían detectarse fallos de nodo (no fallos de enlace en los enlaces de tráfico). Además del problema de consumo de ancho de banda implícito para la detección rápida de fallos, la monitorización de redes de MPLS de E2E requiere actualmente intervenciones manuales, ya que los procedimientos de ubicación pueden ser muy complejos. Las soluciones de MPLS de E2E se basan en un concepto llamado jerarquía de MPLS, lo que significa que los Trayectos Conmutados de Etiquetas (LSP) pueden ser establecidos en distintos niveles. El resultado es que los encaminadores pueden actuar al mismo tiempo como nodos 'fronterizos' o 'intermedios', según el LSP considerado, y que la información referida a algunas de estas capas puede ser ocultada a los mismos. De tal modo, cuando se genera una alarma en el sistema de monitorización, puede no ser trivial localizar en qué nodo intermedio específico ha ocurrido el fallo físico. Actualmente, este proceso es ejecutado por un operador que activa la inyección de paquetes de monitorización por sondas activas distribuidas (o nodos que presten soporte a OAM) en los distintos niveles de MPLS, hasta que se halle el fallo, proceso que consume mucho tiempo. La conclusión, entonces, es que la monitorización de OAM de las redes de MPLS de E2E no está adaptada tampoco en términos de funcionamiento automatizado. Finalmente, la detección de situaciones de congestión de red, usando herramientas de OAM de monitorización de prestaciones, no sería muy efectiva en términos de carga de red, ya que tales herramientas inyectan grandes cantidades de paquetes en la red.
Limitaciones de los protocolos de monitorización pasiva Las sondas pasivas no son usadas normalmente para la monitorización de redes, debido al alto número de puntos críticos existentes, lo que demandaría un alto número de dispositivos externos desplegados por la red. El rastreo de tráfico, o la
DPI, también son raramente usados con este fin, ya que existen alternativas (como los mismos protocolos de monitorización) que son específicos para estas características; en cambio, son usados más frecuentemente para reunir información referida a clientes en la capa de servicios. Los protocolos de monitorización pasiva, por otra parte, también presentan otras limitaciones.
La mayoría de las estimaciones de QoS de los protocolos de monitorización pasiva son afectadas no solamente por la ocupación de colas, sino también por los criterios de tráfico, definidos para los distintos tipos de tráfico (multimedios, http, etc.), en los nodos que recorre el tráfico. Así, pueden aparecer situaciones en las cuales la estimación de QoS podría estar distorsionada, debido a una muestra averiada, cuyo origen no reside en la ocupación de colas, sino en aquellos criterios de los cuales no está al tanto la herramienta de monitorización. Normalmente, los tiempos de detección son muy bajos, por dos motivos: (i) la complejidad de los algoritmos y la fase de pos-procesamiento, y (ii) el proceso de sondeo requerido para recolectar los datos y las trampas y alarmas generadas. Según el tipo de fallo y las capas que estén siendo monitorizadas, el tiempo de ubicación también podría ser alto. Si se hace la monitorización en la capa de la MPLS, y los fallos ocurren en nodos intermedios, las herramientas pasivas no pueden localizar tales fallos por su cuenta, necesitando soporte de cualquiera de las herramientas activas que han sido descritas. Y, finalmente, no hay ninguna comunicación interna directa entre estos protocolos y la capa de la MPLS en los nodos de red, por lo que la activación de los mecanismos de restauración tendría que ser hecha por medio de sistemas externos (que requieren normalmente la intervención humana).
Limitaciones de las herramientas de monitorización activa Normalmente, las herramientas de monitorización activa se basan en mediciones de retardos para proporcionar sus estimaciones sobre la QoS de la red. El retardo de los paquetes depende de muchos factores, por ejemplo, el tamaño del paquete o la clase de tráfico. Por tanto, los patrones del tráfico inyectado necesitan ser tan similares como sea posible a los patrones reales del tráfico de clientes que recorre la red. En otro caso, la medición no sería fiable. Los patrones reales son muy complejos y muy variables hoy en día, por lo que es muy difícil obtener modelos realistas. Para la monitorización en la capa de aplicación de los servicios críticos, los sistemas de monitorización solamente son conscientes de los fallos de red una vez que la capa de aplicación ha notificado que el usuario está experimentando degradaciones de QoS. Este comportamiento reactivo puede no coincidir con las expectativas de monitorización, ya que no es posible localizar el fallo de la red con mediciones en la capa de aplicación, lo que deriva en una restauración muy lenta del servicio. La monitorización activa comporta la inyección de paquetes de sondeo en la red. De tal modo, valen las mismas limitaciones que para la monitorización de OAM: el problema del consumo del ancho de banda y la falta de soluciones automatizadas para la detección de fallos. Y, finalmente, como con las herramientas pasivas, no hay ninguna comunicación interna directa entre estos sondeos y la capa de la MPLS en los nodos de red, por lo que la activación de los mecanismos de restauración debería ser hecha por medio de sistemas externos (que requieren normalmente la intervención humana). Al presentar también las mismas limitaciones que OAM, y requerir normalmente que se desplieguen sondeos externos sobre la red, las herramientas de monitorización activa no serán consideradas en esta invención, excepto las de la capa de aplicación.
Limitaciones de la monitorización de la capa física
Una es la limitación más importante para las herramientas de monitorización de la capa física: no son capaces de detectar averías que no sean las de la capa 1 . Para la Pérdida de Conectividad, por ejemplo, estas herramientas son muy adecuadas: al ser internas a los nodos de red, normalmente, los vendedores de equipos implementan la interfaz entre ellas y la capa de MPLS, por lo que las alarmas en la capa 1 pueden activar directamente los procesos de restauración basados en la
MPLS. Sin embargo, no hay ningún proceso capaz de detectar congestión de red con herramientas de la capa 1 , por ejemplo.
Limitaciones de los mecanismos de restauración
Finalmente, merece la pena mencionar una limitación para los mecanismos de restauración de la MPLS, referida a los fallos en nodos intermedios. Cuando ocurren fallos en estos nodos, en muchas ocasiones la recuperación rápida es posible mediante mecanismos locales como el FRR. Sin embargo, a veces no lo es (p. ej., cuando no hay un enlace de resguardo). En tales ocasiones, pueden usarse nuevos mecanismos, según lo definido en el marco de MPLS-TP, para informar al nodo de ingreso del LSP, el cual ejecuta a su vez el mecanismo de recuperación de extremo-a-extremo (p. ej., primario / de resguardo) con el cual puede haber sido configurado. Sin embargo, en redes basadas en la jerarquía de MPLS, como las de la MPLS de E2E, tal enfoque deriva en un proceso de restauración común para todos los LSP de servicio, que siguen el trayecto de resguardo del LSP de transporte. No hay ninguna manera, hasta donde sabemos, para que los puntos extremos de servicio sepan de tal fallo, aparte de la gestión externa, por el sencillo motivo de que los nodos de transporte no son conscientes de los LSP de servicio. Por tanto, no es posible implementar la restauración rápida y particularizada de extremo a extremo en la capa de servicio.
Para resumir, no hay ninguna herramienta única que permita la restauración rápida escalable (y, por tanto, bajas pérdidas de tráfico y, por tanto, alta disponibilidad de servicios) para todo tipo de degradación de la Calidad del Servicio (QoS) que pueda ocurrir en grandes redes de Conmutación de Etiquetas MultiProtocolo (MPLS). Además, la automatización no existe para los sistemas de monitorización a la fecha, que necesitan intervención humana para detectar, correlacionar y localizar degradaciones de QoS, lo que nuevamente aumenta el tiempo total requerido para la restauración. Las soluciones automatizadas existentes presentan o bien altos tiempos de localización de fallos, o bien una alta carga de monitorización, lo que significa que el ancho de banda consumido y asociado es muy alto, impidiendo a los operadores usar este ancho de banda para ofrecer servicios adicionales de conectividad. Por lo tanto, existe la necesidad en el estado de la técnica de un sistema para impedir, detectar y restaurar degradaciones de QoS, en base a sistemas de monitorización que hagan un uso coordinado de varias de tales herramientas existentes, sin intervención humana y con rápido tiempo de respuesta.
Resumen de la invención
La presente invención resuelve los problemas precitados y supera las limitaciones del estado de la técnica anteriormente explicadas, revelando un procedimiento y sistema que hacen uso de los mecanismos de monitorización actualmente disponibles para la detección de la degradación de la QoS, de una manera coordinada y automatizada, de modo que pueda reducirse la carga de monitorización. Esto se hace llevando a cabo una coordinación centralizada de los mecanismos de monitorización, lo que permite detectar situaciones potencialmente críticas por medio de herramientas ligeras (es decir, consumidoras de un bajo ancho de banda), y confirmando o invalidando luego la degradación, llevando a cabo mediciones más intensas solamente en aquellos segmentos donde se necesita hacerlas. Por lo tanto, la presente invención proporciona un procedimiento y un sistema para la prevención, detección y restauración automática de las degradaciones de la QoS, minimizando a la vez el ancho de banda de monitorización consumido con este fin: la invención hace uso primero de herramientas de bajo consumo de ancho de banda, y confirma que las degradaciones tienen lugar usando herramientas más potentes centradas en segmentos específicos , donde un incremento del ancho de banda no afecta el comportamiento total de la red. La determinación de segmentos críticos también permite una restauración más rápida, lo que afecta positivamente la disponibilidad de los servicios.
Dado que en el estado de la técnica anterior no hay una única herramienta de monitorización que sea adecuada para superar toda clase de degradaciones que puedan ocurrir en la redes actuales, la presente invención hace uso de los más potentes sistemas de monitorización disponibles en el mercado, coordinándolos para aumentar la velocidad a la cual son recuperados los servicios después de los fallos, y para reducir el número de paquetes de monitorización inyectados en la red. Además, los procedimientos definidos para la invención están automatizados, lo que una vez más aumenta la disponibilidad de los servicios, ya que se evita la intervención humana.
Según un primer aspecto de la presente invención, se describe un procedimiento para restaurar degradaciones de QoS en redes de MPLS, y comprende las siguientes etapas: recibir una o más alarmas desde la Capa de Aplicación, o desde un nodo de la red de MPLS,
localizar un segmento con fallos de la red de MPLS asociado a la(s) alarma(s) recibida(s);
correlacionar todas las alarmas asociadas al segmento con fallos en la misma ubicación;
determinar los servicios afectados por las alarmas correlacionadas, para cada servicio afectado, obtener de una base de datos unos trayectos de restauración a partir
restaurar todos los servicios afectados, usando los trayectos de restauración,
(com)probar/testear los servicios restaurados. Un segundo aspecto de la presente invención se refiere a un sistema para determinar degradaciones de QoS en redes de MPLS, que comprende: módulos de comunicación de la capa de servicios y de la capa de red, para recibir alarmas, respectivamente, desde la Capa de Aplicación y desde un nodo de red de MPLS,
un módulo de gestión y correlación de alarmas, para correlacionar todas las alarmas que le envían los módulos de comunicación de la capa de servicios y de la capa de red, y que están asociadas a un segmento con fallos en una misma ubicación,
uno o más módulos de cálculo para determinar los servicios afectados por las alarmas correlacionadas, recibidas desde el módulo de gestión y correlación de alarmas, con información sobre la ubicación del segmento con fallos, obtenida a partir de medios de localización de segmentos en la red de MPLS, y con acceso a una base de datos del sistema, desde la cual se obtienen los trayectos de restauración para todos los servicios afectados,
un planificador de señalización conectado con la señalización de la MPLS, para habilitar la restauración de los servicios afectados, usando los trayectos de restauración obtenidos cuando es activado por cualquiera de los módulos de cálculo,
un activador de monitorización activa que es solicitado por cualquiera de los módulos de cálculo, para obtener pruebas sobre los servicios restaurados, desde la capa de servicios hasta el módulo de comunicación de la capa de servicios, y desde la capa de red hasta el módulo de comunicación de la capa de red.
El módulo activador de monitorización activa no solamente activa pruebas de servicios restaurados, sino que también, en una realización preferida de la invención, activa las pruebas más intensas (pruebas activas) que confirman las degradaciones. De tal modo, el activador de monitorización activa puede ser solicitado por cualquiera de los módulos de cálculo para obtener pruebas activamente, con fines de confirmación de degradación, o sobre los servicios restaurados. Los medios de localización de los segmentos con fallos están un nodo de red de la red de MPLS, desde el cual un módulo de cálculo del sistema definido anteriormente recibe una alarma, y por tanto solicita la ubicación de este segmento de red. En el caso de las alarmas recibidas desde la Capa de Aplicación, los medios de localización son proporcionados por la base de datos del sistema, externa o interna al sistema, desde la cual la ubicación del segmento de red usado por la Capa de Aplicación es solicitada por un módulo de cálculo del sistema descrito anteriormente.
En un aspecto final de la presente invención, se revela un programa de ordenador, que comprende medios de código de programa de ordenador adaptados para realizar las etapas del procedimiento descrito cuando dicho programa es ejecutado en un ordenador, un procesador de señales digitales, una formación de compuertas programables en el terreno, un circuito integrado específico para la aplicación, un micro-procesador, un micro-controlador, o cualquier combinación de los precitados y / u otra forma de hardware programable.
El procedimiento y sistema de acuerdo a los aspectos descritos anteriormente de la invención tienen un buen número de ventajas con respecto al estado de la técnica anterior, centradas y orientadas para aumentar las prestaciones de las redes de MPLS de E2E, proporcionando a la vez servicios sobre los Trayectos Conmutados de Etiquetas (LSP). Estas ventajas de la invención pueden ser resumidas de la siguiente manera:
- La presente invención proporciona un Administrador de Monitorización de QoS, con automatización de la detección, ubicación y prevención o restauración de la QoS en redes de MPLS de E2E. Una entidad inteligente, que coordine distintas herramientas de monitorización a fin de preservar proactivamente la QoS en redes de MPLS de E2E, de manera automatizada y escalable, no existe a la fecha en el estado de la técnica. La inteligencia del sistema Administrador de Monitorización de QoS propuesto aquí es capaz de rastrear la red de MPLS y evaluar automáticamente cuándo, dónde y por medio de cuál técnica de monitorización debería ser monitorizada la QoS de un cierto servicio / trayecto. De tal modo, no hay ninguna necesidad de intervención humana en el proceso de monitorización.
- La escalabilidad del sistema propuesto de Administrador de Monitorización de QoS, que se centra en acciones de monitorización activa en aquellos segmentos específicos de red en los cuales la QoS es susceptible de degradación, constituye una de las características más importantes con valor añadido, dado que el tamaño de las redes de MPLS de E2E hace imposible ajusfar a escala con procesos de monitorización sobrecargados o innecesarios. - Al centrarse en la ubicación de red donde ocurren las degradaciones de QoS, la presente invención es capaz de reducir el número de paquetes totales de monitorización para confirmar estas degradaciones de QoS, realzando la escalabilidad del sistema Administrador de Monitorización de QoS (QMM). Así, puede aumentar el número de servicios simultáneamente provistos, usando el ancho de banda no usado. Además, la capacidad del sistema QMM para localizar segmentos específicos de la red de MPLS, que sean críticos para la QoS, constituye un valor añadido, no solamente en términos de recursos de monitorización, sino también en términos del tiempo requerido para la restauración y, por tanto, en términos de disponibilidad del servicio.
- Por medio de mecanismos preventivos de restauración, que son capaces de detectar e impedir automáticamente degradaciones de QoS en la red, la presente invención permite la maximización de la Calidad de Servicio (QoS) del usuario final en redes de MPLS de E2E- .
- Con respecto al documento EP1 176759, las principales diferencias ventajosas de la invención son los precitados mecanismos de restauración preventiva y la automatización de estos mecanismos, así como los mecanismos automatizados de detección y restauración de la degradación de la QoS.
Estas y otras ventajas serán evidentes a la luz de la descripción detallada de la invención.
Descripción de los dibujos Con el fin de ayudar en la comprensión de las características de la invención, según una realización práctica preferida de la misma, y a fin de complementar esta descripción, se adjuntan las siguientes figuras como una parte integral de la misma, con carácter ilustrativo y no limitador:
La Figura 1 muestra un sistema para determinar degradaciones de QoS y sus relaciones con otras entidades de red existentes en un escenario de red MPLS, según una realización preferida de la invención.
La Figura 2 muestra un diagrama de flujo de mensajes en el sistema de la Figura 1 , para determinar degradaciones de QoS, de acuerdo a una posible realización de la invención.
La Figura 3 muestra un diagrama de flujo de mensajes en el sistema de la Figura 1 , para determinar degradaciones de QoS informadas por alarmas provenientes de la Capa de Aplicación, de acuerdo a un posible caso de aplicación de uso de la invención.
La Figura 4 muestra un diagrama de flujo de mensajes en el sistema de la Figura 1 , para determinar degradaciones de QoS informadas por alarmas provenientes de la Capa Física o de un Analizador de Tráfico Pasivo, de acuerdo a otro posible caso de aplicación de uso de la invención.
La Figura 5 muestra un diagrama de flujo de mensajes en el sistema de la Figura 1 , para determinar degradaciones de QoS informadas por alarmas provenientes de herramientas de OAM de la MPLS, de acuerdo a un posible caso adicional de aplicación de uso de la invención.
La Figura 6 muestra un diagrama de flujo de mensajes en el sistema de la Figura 1 , en una modalidad de funcionamiento proactivo, para determinar degradaciones de QoS, de acuerdo a otra posible realización de la invención.
La Figura 7 muestra un diagrama de bloques de la arquitectura del sistema, para determinar degradaciones de QoS en una red de MPLS, según una realización preferida de la invención.
Realización preferida de la invención Las cuestiones definidas en esta descripción detallada se proporcionan para ayudar en una comprensión exhaustiva de la invención. En consecuencia, los medianamente expertos en la técnica reconocerán que pueden hacerse variaciones, cambios y modificaciones de las realizaciones descritas en la presente memoria sin apartarse del ámbito y el espíritu de la invención. Además, se omite la descripción de funciones y elementos bien conocidos, para mayor claridad y concisión.
Por supuesto, las realizaciones de la invención pueden ser implementadas en una gran variedad de plataformas arquitectónicas, sistemas operativos y servidores, dispositivos, sistemas o aplicaciones. Cualquier diseño arquitectónico específico o implementación presentada en la presente memoria se proporciona solamente con fines de ilustración y comprensión, y no está concebido para limitar aspectos de la invención. Es dentro de este contexto que se presentan ahora diversas realizaciones de la invención, con referencia a las FIGs. 1 a 7.
La Figura 1 presenta un Administrador de Monitorización de QoS (QMM) como un sistema (10) para determinar degradaciones de QoS en una red de MPLS (30), y también muestra las relaciones e interfaces específicas entre el sistema (10) y los módulos existentes, que son los siguientes:
• Capa de Aplicación (20): En el modelo de Internet, es la capa donde residen los servicios (aplicaciones), creando e intercambiando datos de usuario entre distintos anfitriones, por una red de ordenadores.
• Sistema de Soporte de Servicios (21 ): es el módulo encargado de recolectar los datos de monitorización de la capa de aplicación (20), obtenidos por medio de mediciones activas, y de enviarlos al sistema (10). Comparte la misma visión de la calidad experimentada con los clientes finales, y por lo tanto es capaz de detectar degradación o violaciones de los SLA suscritos por ellos.
• Analizador de Tráfico Pasivo (32): este módulo o entidad funcional incluye las mediciones pasivas que los protocolos de monitorización pueden realizar en las redes (30) de MPLS de los operadores. Por tanto, están situados en los nodos (31 ) de red, aunque también se admiten mediciones equivalentes llevadas a cabo por sondas externas. Se consideran dos posibles modalidades de funcionamiento (que pueden coexistir simultáneamente): modalidad de funcionamiento bajo demanda, en la cual el sistema (10) consulta al Analizador de Tráfico Pasivo (32) para (realizar, si es necesario, e) informar acerca de un proceso de monitorización pasiva sobre un nodo (31 ) de red específico; y modalidad de funcionamiento proactivo, en la cual el Analizador de Tráfico Pasivo (32) informa automáticamente al sistema (10) acerca de mediciones pasivas periódicas sobre ciertos nodos (31 ) de red.
• Monitorización de Capa Física (33): un módulo que consiste en el conjunto de alarmas que los nodos (31 ) de red pueden anunciar, referidas a averías físicas, como pérdida de conectividad o mala calidad de transmisión. Estas alarmas son anunciadas al sistema (10).
• Herramientas OAM (34) de MPLS: un módulo que consiste en el conjunto de capacidades que permiten a los operadores resolver problemas de las redes (30) de MPLS. Dado que la red (30) de MPLS de destino puede estar basada en la MPLS de E2E, estas herramientas son las más adecuadas para la monitorización global. Las herramientas ligeras pueden ser usadas proactivamente para detectar situaciones de congestión potencial sobre ciertas áreas de red, mientras que otras, ejecutadas bajo demanda desde el sistema (10), pueden ser válidas para confirmar o rechazar la presencia de tales averías de red, o con fines de detección cuando ocurren fallos de nodo / enlace (en caso de que no estuviera disponible ninguna herramienta más veloz). • Señalización (35) de MPLS: este módulo permite al sistema (10) iniciar procesos de restauración basados en MPLS en la red (30), en caso de que ciertos segmentos de red experimenten una falta de QoS.
• Base de Datos (36) del Sistema: este módulo almacena la información requerida, tanto de la red (30) del operador, por ejemplo, su estado, los trayectos configurados, etc., como de la capa de aplicación (20), por ejemplo, los servicios activos.
La Figura 2 muestra un diagrama de flujo de los mensajes de comunicación intercambiados en el escenario de red ilustrado anteriormente en la Figura 1 , que implica al sistema (10) QMM que hace uso de procedimientos de prevención, detección y restauración de la degradación de QoS, según se describe más adelante. Las líneas continuas en la Figura 2 se refieren a procedimientos obligatorios, mientras que las líneas discontinuas se usan para aquellos procedimientos que son optativos en el sistema (10). Este sistema (10) implementa un procedimiento para determinar degradaciones de QoS, que comprende las siguientes etapas principales:
Recibir alarmas (a) desde la capa de aplicación (20) y / o desde cualquiera de, o todos, los nodos (31 ) de red, incluyendo a los nodos del Analizador de Tráfico Pasivo (32), los nodos de Monitorización de Capa Física (33) y los nodos de OAM (34) de MPLS.
- Según la alarma específica, el sistema (10) puede solicitar (d), normalmente desde los nodos (31 ) de red, pruebas adicionales con fines de ubicación, por lo que los nodos (31 ) de red contestan con respuestas (e) de ubicación.
Una vez que está localizado el fallo, el sistema (10) inicia directamente los procedimientos (h) de restauración de tráfico, mediante la interacción con el módulo de Señalización (35) de MPLS, y recibe el resultado (i).
En cualquier etapa, el sistema (10) puede necesitar consultar la Base de Datos (36) del Sistema antes de tomar cualquier decisión adicional; esta etapa de consultar la Base de Datos (36) es optativa, antes de solicitar pruebas de localización, la etapa (b) de consulta y la correspondiente respuesta (c), mientras que la etapa (f) de consulta, con su correspondiente respuesta (g), antes de iniciar los procedimientos (h) de restauración, es obligatoria.
- Una vez que el tráfico ha sido restaurado, procedimientos adicionales de prueba son activados (j) por el sistema (10) para garantizar la QoS global correcta dentro de la nueva situación de red.
Estos procedimientos de prueba pueden ser llevados a cabo (k) por los nodos (31 ) de red y / o la capa de aplicación (20).
- Mientras el sistema (10) está aún detectando la degradación de QoS, mecanismos adicionales de restauración podrían ser activados por el sistema (10), mediante un bucle (i), hasta que el sistema (10) pueda declarar un comportamiento global estable no degradado.
Los mecanismos para recuperar la situación original del tráfico una vez que el fallo está reparado, que están fuera del ámbito de la invención, pueden ser gobernados por los mecanismos bien conocidos de "hacer antes de romper", disponibles para las redes de MPLS, y serían activados por el operador en cualquier momento conveniente para el mismo.
- Dado que distintas alarmas, desde distintos módulos, podrían llegar al sistema (10), el procedimiento incorpora la posibilidad optativa de seleccionar el criterio de correlación de alarmas, de modo que, cuando varias sean recibidas, posiblemente referidas a la misma avería de QoS, el sistema (10) sea capaz de compilar y gestionar todas ellas, correlacionarlas y ejecutar las adecuadas acciones correctivas.
En una posible realización, los criterios para la gestión de alarmas (otros son posibles) son los siguientes: - en el caso en que varias alarmas llegan al sistema (10) QMM en un breve periodo (configurable) de tiempo, el sistema (10) confiere un mayor grado de prioridad a las alarmas que presentan (en general) mecanismos más veloces de localización de errores. Cada uno de los procedimientos de monitorización, por lo tanto, ha sido etiquetado con una ponderación de prioridad.
La única excepción a la regla mencionada anteriormente es para la monitorización de la capa de aplicación (20): como esta capa comparte la experiencia con los clientes del servicio, las alarmas recibidas desde ella tendrán la más alta prioridad.
La capa física (33) y los protocolos (32) de monitorización pasiva pueden localizar rápidamente el problema experimentado en la red, ya que ambos generan alarmas en el punto exacto donde ocurre la avería. Las alarmas de la capa física (33) tendrán un mayor grado de prioridad (el segundo globalmente), sin embargo, debido a su tiempo de detección, el más veloz, y debido a la muy común necesidad operativa de superar rápidamente cualquier degradación de la capa física que pudiera ocurrir. Por lo tanto, las alarmas de monitorización del analizador de tráfico pasivo (32) serán gestionadas con el tercer nivel de prioridad cuando lleguen al sistema (10) QMM.
Finalmente, los mecanismos de monitorización de OAM (34) de MPLS comportan normalmente la rápida detección de anomalías, pero al coste del ancho de banda, según lo expresado anteriormente. Además, el tiempo para localizar el segmento afectado depende de muchas variables, por lo que a estas alarmas se dará el nivel mínimo de prioridad (cuarto globalmente).
Con este enfoque, en el caso en que lleguen varias alarmas de distintos tipos al sistema (10) QMM, este sistema (10) es capaz de gestionarlas: atendiendo primero a aquellas que localicen las averías más rápidamente, el sistema (10) es capaz luego de determinar cuáles nodos / enlaces y LSP / servicios están afectados, y es capaz de correlacionar el resto de las alarmas, de modo que no necesiten ser consideradas. Es importante mencionar que el tener un tiempo mayor de detección o localización no impide que aparezcan las alarmas de los módulos más lentos en el escenario total de red, dado que cada herramienta puede monitorizar distintos parámetros y es más adecuada para distintos fines.
Para los escenarios ejemplares de red y casos de uso descritos más adelante, y mostrados en las Figuras 3 a 6, el criterio para la gestión de alarmas a considerar es el descrito en detalle anteriormente.
Las Figuras 3 a 6 extienden el flujo básico de trabajo anteriormente descrito en la Figura 2, e incluyen las interacciones que tienen lugar entre el sistema (10) QMM y los módulos existentes en varios casos de uso. Pueden definirse dos categorías principales de casos de uso: aquellos casos, mostrados en las FIGs. 3 a 5, en los cuales el funcionamiento del sistema (10) QMM es reactivo, es decir, reacciona después de que ha ocurrido la degradación de QoS; y aquellos tales como el mostrado en la Figura 6, en los cuales el sistema (10) QMM es proactivo, es decir, reacciona intentando evitar la degradación de QoS antes de que ocurra.
La Figura 3 muestra el flujo de trabajo específico para un caso de uso en el cual la alarma es recibida desde la capa de aplicación (20), lo que significa que el cliente está al tanto de la degradación de QoS, por lo que el funcionamiento del sistema (10) QMM debe ser reactivo, para resolver rápidamente la situación de alarma. El sistema (10) recibe una alarma (a1 ) desde la capa de aplicación (20), y consulta (b1 ) la Base de Datos (36) para obtener (c1 ) el trayecto de red que está siendo usado por la capa de aplicación (20) para el servicio dado, al cual se refiere la alarma. Luego, el sistema (10) comprueba internamente otras alarmas potenciales que puedan haber sido recibidas desde nodos (31 ) de red por el sistema (10) QMM a lo largo de ese trayecto específico.
Si el sistema (10) halla alguna (lo que normalmente debería ser el caso), las agrupa según el segmento o nodo específico de red que esté afectado (si ya está identificado por las otras alarmas) y salta a una etapa (f1 ) de consultar nuevamente la Base de Datos (36), en busca de información sobre todos los servicios que podrían ser potencialmente afectados por tales sucesos. La etapa (g1 ) subsiguiente es la Respuesta dada por la Base de Datos (36). Por el contrario, si no está presente ninguna otra alarma, o las presentes no han localizado aún el segmento, o los segmentos, afectado(s), entonces el sistema (10) QMM solicita (d1 ) a los mecanismos de OAM (34) de MPLS en los nodos (31 ) de red que lleven a cabo operaciones específicas bajo demanda para localizar el fallo, según el tipo de alarma recibida desde la capa de aplicación (20). La definición completa de cuáles operaciones están asociadas a cuáles alarmas está fuera del ámbito de la invención. Para proporcionar solamente un ejemplo, si la alarma se refería a un retardo largo en un servicio de audio-conferencia, entonces las herramientas de OAM (34) de MPLS podrían ser las que midan el retardo de paquetes a lo largo del trayecto. Las pruebas llevadas a cabo por las herramientas de OAM (34) de MPLS deberían remitirse primero al trayecto de extremo a extremo. En el caso en que el resultado (e1 ) de las operaciones de los mecanismos de OAM (34) de MPLS para localizar el fallo sea el adecuado, entonces el sistema (10) declara que pueden localizarse problemas potenciales dentro de las instalaciones del cliente. La resolución de tales problemas también está fuera del ámbito de la invención. Por otra parte, si el resultado de la localización de fallos por parte de OAM (34) de MPLS es insatisfactorio, entonces se hacen pruebas segmento por segmento, para localizar el segmento o nodo específico afectado por la degradación. Las pruebas realizadas por OAM (34) de MPLS son activadas y controladas por el sistema (10) QMM, que es el que tiene la información de los segmentos.
Una vez que el fallo está localizado por OAM (34) de MPLS, y este resultado (e1 ) de localización es recibido por el sistema (10) QMM, entonces el sistema (10) continúa con las etapas (f1 ) y (g1 ) de consulta y respuesta, respectivamente, a / desde la Base de Datos (36), equivalentes a las descritas anteriormente. En esta etapa, el sistema (10) tiene una visión clara de cuáles servicios pueden ser afectados por las distintas degradaciones, por lo que activa (h1 ) la señalización (35) de MPLS para iniciar los mecanismos de protección / restauración para cada uno de los servicios afectados por la alarma. Los resultados de los procedimientos de restauración se proporcionan en la etapa (¡1 ).
El sistema (10) QMM necesita comprobar el funcionamiento correcto de todos los servicios restaurados, por lo que activa (j1 ) mecanismos de monitorización bajo demanda, ya sea en la capade aplicación (20), en lo posible, según la disponibilidad de tales herramientas en las distintas instalaciones de los clientes, o bien mediante OAM (31 ) de MPLS, que siempre está disponible. Los resultados de las pruebas se proporcionan en la etapa (k1 ). En el caso en que algunos de los resultados de las pruebas sean insatisfactorios, el sistema (10) consulta nuevamente (11 ) la Base de Datos (36) en busca de trayectos alternativos para esos servicios, y repite (en un bucle) la ejecución de etapas desde ( ) a (k1 ) para esos trayectos alternativos.
Ha de observarse que muchas redes tienen sus propios procedimientos de restauración automática, por ejemplo, cuando los enlaces están cortados. En esos casos, el sistema (10) es consciente de tal situación en las etapas (c1 ) o (g1 ), dado que la Base de Datos (36) ya proporciona la información en cuanto a que uno o varios servicios específicos han sido automáticamente restaurados a un trayecto de resguardo. Los cometidos del sistema (10) QMM ante tal suceso garantizan que otros servicios, posiblemente no capaces de ser recuperados automáticamente, tampoco sean afectados. El funcionamiento para ellos es equivalente a lo que ya se ha descrito en el caso de uso de la Figura 3.
La Figura 4 muestra el flujo de trabajo específico de otro caso de uso en el cual el funcionamiento del sistema (10) QMM es reactivo para una alarma recibida desde las herramientas de monitorización de la capa física (33). El sistema (10) QMM recibe una alarma (a2) desde las herramientas de monitorización de la capa física (33), y no necesita ejecutar las operaciones de localización, es decir, evitando las etapas desde (b) a (e) en el flujo básico de la Figura 2, dado que estas herramientas ya proporcionan tal información. Por lo tanto, el sistema (10) va directamente a la recolección de otras alarmas potenciales referidas al mismo segmento (provenientes de los nodos (31 ) de red con prioridad inferior de alarma), y salta a la etapa (f2) para consultar la Base de Datos (36) en busca de información sobre todos los servicios que podrían ser potencialmente afectados por este suceso específico. La respuesta de la Base de Datos (36) se da en la etapa (g2).
En esta etapa, el sistema (10) QMM tiene una visión clara de cuáles servicios pueden ser afectados por la degradación, por lo que activa (h2) los mecanismos de señalización (35) de MPLS para iniciar los mecanismos de protección para cada uno de esos servicios. Los resultados de los procedimientos de restauración se proporcionan en la etapa (¡2). Finalmente, el sistema (10) QMM necesita comprobar el funcionamiento correcto de todos los servicios restaurados, por lo que activa los mecanismos (j2) de monitorización bajo demanda, ya sea en la capa de aplicación (20), en lo posible, según la disponibilidad de tales herramientas en las distintas instalaciones de clientes, o bien mediante OAM (31 ) de MPLS, que siempre está disponible. Los resultados de las pruebas se proporcionan en la etapa (k2). En el caso en que algunos de ellos sean insatisfactorios, el sistema (10) QMM consulta nuevamente (¡2) la Base de Datos (36) en busca de trayectos alternativos para esos servicios, y ejecuta en un bucle, si se requiere, las etapas desde (h2) a (k2) para esos trayectos alternativos. En redes con sus propios procedimientos de restauración automática, el sistema (10) QMM solamente puede ser consciente de tal situación en la etapa (g2); para esos casos, los cometidos del sistema (10) están restringidos a aquellos servicios que no puedan ser automáticamente recuperados. La operación para ellos es equivalente a lo que ya ha sido descrito en el caso de uso de la Figura 4.
Hay otro posible caso de uso en el cual una alarma llega al sistema (10) QMM desde el analizador de tráfico pasivo (32). Entonces, el flujo de trabajo específico es equivalente al del caso anterior, ilustrado en la Figura 4. Las únicas diferencias son:
En la etapa (a2), el sistema (10) recibe la alarma desde el analizador de tráfico pasivo (32), en lugar de las herramientas de monitorización de capa física (33).
Los tipos de alarma que el sistema (10) necesita buscar en correspondencia con el segmento son los que llegan solamente desde las herramientas de OAM (34) de MPLS, dado que son las que tienen la prioridad mínima.
La Figura 5 muestra un flujo de trabajo específico de otro caso de uso, en el cual el funcionamiento del sistema (10) QMM es reactivo para una alarma recibida desde las herramientas de OAM (34) de MPLS. En las redes (30) de MPLS, la monitorización puede ser hecha en distintos niveles de MPLS, y entre distintos pares de nodos (31 ) de red de MPLS, incluso si no están directamente conectados. Por lo tanto, el funcionamiento del sistema (10) depende de cómo se hace esta monitorización.
Para las alarmas que llegan desde herramientas ejecutadas entre nodos (31 ) de red, que están directamente conectados, el funcionamiento es similar a los casos de uso mostrados en la Figura 4, donde una alarma es recibida desde la monitorización de la capa física (33), o desde el analizador de tráfico pasivo (32), dado que no se necesita ejecutar ningún procedimiento de localización, pero con las siguientes diferencias: - el sistema (10) recibe la alarma (a3) desde las herramientas de OAM (34) de
MPLS, en lugar de las herramientas de monitorización de capa física (33), o del analizador de tráfico pasivo (32),
- No hay ninguna necesidad de correlacionar otras alarmas, dado que estas son las de menor prioridad.
Para las alarmas que llegan desde herramientas ejecutadas entre nodos (31 ) de red que no están directamente conectados, el funcionamiento es muy similar al caso de uso mostrado en la Figura 3, donde una alarma es recibida desde la capade aplicación (20), dado que se requiere un procedimiento de localización entre los distintos enlaces que ha recorrido la prueba activa. El procedimiento es entonces el mostrado en la Figura 5, y según lo siguiente:
El sistema (10) QMM recibe una alarma (a3) desde las herramientas de OAM (34) de MPLS. No hay ninguna necesidad de consultar el trayecto de red en este caso, es decir, evitando etapas desde (b) a (c) en el flujo básico de la Figura 2, dado que ha sido explícitamente definido en la herramienta de monitorización y es bien conocido. Además, dado que no hay ninguna alarma adicional para correlacionar, el procedimiento de localización es obligatorio: el sistema (10) QMM solicita (d3) los mecanismos de OAM (34) de MPLS en los nodos (31 ) de red para llevar a cabo operaciones específicas bajo demanda, segmento a segmento, para localizar el fallo, y sus Respuestas son enviadas de vuelta en la etapa (e3). Después de la localización, el sistema (10) QMM avanza a la etapa (f3) para consultar la Base de Datos (36) en busca de información sobre todos los servicios que podrían ser potencialmente afectados por el suceso localizado. La respuesta de la Base de Datos (36) se da en la etapa (g3). En esta etapa, el sistema (10) QMM nuevamente tiene una visión clara de cuáles servicios pueden ser afectados por las distintas degradaciones, por lo que activa (h3) mecanismos (35) de señalización para iniciar los mecanismos de protección para cada uno de esos servicios. Los resultados de los procedimientos de restauración son proporcionados en (¡3). Finalmente, el sistema (10) QMM necesita comprobar el correcto funcionamiento de todos los servicios restaurados, por lo que activa los mecanismos (j3) de monitorización bajo demanda, ya sea en la capa de aplicación (20), en lo posible, según la disponibilidad de tales herramientas en las distintas instalaciones de clientes, o bien mediante OAM (31 ) de MPLS, que siempre está disponible. Los resultados de las pruebas son proporcionados en la etapa (k3). En el caso en que algunos de ellos sean insatisfactorios, el sistema (10) QMM consulta nuevamente (13) la Base de Datos (36) en busca de trayectos alternativos para esos servicios, y ejecuta, si se requiere, en un bucle, las etapas desde (h3) a (k3) para esos trayectos alternativos. En redes con sus propios procedimientos de restauración automática, el sistema
(10) QMM solamente puede ser consciente de tal situación en la etapa (g3). Para esos casos, los cometidos del sistema (10) QMM están restringidos a aquellos servicios que no puedan ser automáticamente recuperados. La operación para ellos es equivalente a lo que ya se ha descrito en este caso de uso de la Figura 5.
La Figura 6 muestra el sistema (10) QMM capaz de reaccionar ante degradaciones potenciales de manera proactiva, es decir, incluso antes de que ocurran. En particular, el principal suceso del cual puede proteger el sistema (10) QMM a la red (30) es la congestión de tráfico. Pueden distinguirse tres zonas de operación de la red
En una zona de "operación correcta" no hay ningún peligro de real de pérdida de paquetes debido al crecimiento repentino del tráfico. Por tanto, la monitorización del tráfico no necesita ser muy precisa o veloz. - En la zona "potencialmente conflictiva" aún no hay ningún peligro real de pérdida de paquetes, pero la monitorización del tráfico necesita ser muy precisa para evitar aumentar el tráfico e ingresar a la zona crítica.
En la zona "crítica", en caso de un repentino crecimiento del tráfico, podrían perderse paquetes, por lo que deben ejecutarse acciones para volver (al menos) a la zona "potencialmente conflictiva".
Debe observarse que el comportamiento deseado para los operadores es estar en la zona de "operación correcta", y que los crecimientos inesperados del tráfico solamente afectan a sus redes en el sentido de que ingresan temporalmente en la zona "potencialmente conflictiva". El crecimiento estable del tráfico debido, por ejemplo, a un incremento en el número de clientes o en el número de servicios ofrecidos, debería ser gestionado mediante otros procedimientos, como inversión en nuevos equipos o planificación revisada de la red. También debe observarse que la definición de los umbrales entre zonas depende del operador y está fuera del ámbito de esta invención.
Para evitar la congestión de red, el sistema (10) QMM usa inicialmente el analizador de tráfico pasivo (32) para la monitorización pasiva, sin consumir, por tanto, ancho de banda de red para detectar situaciones "potencialmente conflictivas". El protocolo SNMP, por ejemplo, puede monitorizar el ancho de banda de la red hasta que se sobrepase un cierto umbral. En ese momento, se necesita una monitorización más veloz y más precisa, y se proporciona mediante herramientas de OAM (34) de MPLS dentro del segmento de red que es "potencialmente conflictivo".
Este tipo de monitorización es para detectar y localizar situaciones "críticas" muy rápidamente: dado que el segmento de red a monitorizar ha sido muy reducido, el problema del consumo de ancho de banda está estrictamente controlado, y la cantidad de paquetes de monitorización que pueden ser inyectados puede ser lo bastante alta como para garantizar las prestaciones adecuadas.
Las herramientas de monitorización pasiva del analizador de tráfico pasivo (32) están midiendo continuamente el tráfico de red y, en el caso en que midan anchos de banda que sobrepasen el umbral especificado para situaciones "potencialmente conflictivas", generan una alarma (a4) para el sistema (10) QMM, según se muestra en el diagrama de flujo de la Figura 6. El segmento específico ya está localizado por la herramienta pasiva, por lo que el sistema (10) QMM es capaz de solicitar (d4) directamente a las herramientas de OAM (34) de MPLS que ejecuten pruebas continuas con alta demanda de ancho de banda sobre ese segmento.
Puede ocurrir que nunca se sobrepase el umbral hacia las situaciones "críticas". Entonces, eventualmente, el analizador de tráfico pasivo (32) que está ejecutándose aún puede detectar que el segmento de red ha vuelto a la zona de
"operación correcta", y lo anuncia al sistema (10) QMM, el cual, a su vez, detiene la monitorización activa de las herramientas de OAM (34) de MPLS.
En el caso en que se sobrepase el umbral hacia situaciones "críticas", las herramientas de OAM (34) de MPLS lo anuncian (e4) al sistema (10) QMM, el cual, a su vez, inicia un procedimiento similar, en las etapas entre (f4) y (14), al de otros casos de uso, por ejemplo, en el caso de uso de la recepción de alarmas desde OAM (34) de MPLS, mostrado en la Figura 5. Las únicas diferencias entre ellos son que: i) el sistema (10) QMM no necesita modificar el trayecto para todos los servicios que recorren el segmento "crítico", sino solamente para los suficientes entre ellos como para volver a la situación "potencialmente conflictiva" (eventualmente notificada mediante una nueva alarma proveniente de las herramientas de OAM (34) de MPLS) y ii) la modificación de trayectos debe ser hecha sin ninguna pérdida de tráfico. En otras palabras, el sistema (10) QMM modifica y verifica un trayecto de servicio a la vez, hasta que recibe una alarma desde las herramientas de OAM (34) de MPLS, indicando que la situación ha vuelto a ser "potencialmente conflictiva". El servicio candidato para el criterio de selección de migración está fuera del ámbito de esta invención. Finalmente, el analizador de tráfico pasivo (32), eventualmente, puede determinar la
"operación correcta" y luego es posible migrar nuevamente los servicios a los trayectos originales, nuevamente sin ninguna pérdida de tráfico.
La Figura 7 ilustra la arquitectura del propuesto sistema (10) QMM, Administrador de Monitorización de Calidad de Servicio, incluyendo los distintos módulos e interfaces. El sistema (10) no necesita ser construido sobre una única máquina física; es posible distribuir las distintas funcionalidades por distintos elementos físicos, en particular, por los mismos nodos de la red de MPLS, con el único requisito de implementar las funcionalidades requeridas de las interfaces. Para la implementación y la operación correcta, se requiere al menos un procesador y conectividad por Ethernet hacia todos los módulos externos requeridos. Sin embargo, se recomiendan múltiples procesadores para mayores prestaciones. Una descripción adicional de los distintos módulos y de las distintas interfaces, internas y externas, se proporciona más adelante, según una posible realización de la invención.
- Módulos internos del sistema (10) QMM
Módulo de Cálculo (100), CM: constituye el cerebro y la inteligencia del sistema (10) y está a cargo de coordinar todas las operaciones ejecutadas en los distintos casos de uso posibles, según lo descrito anteriormente. En particular:
• Recibe conjuntos de alarmas correlacionadas desde el módulo de Gestión y Correlación de Alarmas (106). Cada conjunto inicia un procedimiento de cálculo distinto, que puede ser cualquiera de los cinco anteriormente descritos para los casos de uso.
• Puede requerir que el módulo de Gestión y Correlación de Alarmas (106) sondee el módulo Analizador de Tráfico Pasivo (32) de los nodos (31 ) de red, mediante el módulo COMM de la Capa de Red (102) para la comunicación de la capa de red, cuando el Analizador de Tráfico Pasivo (32) está funcionando en la modalidad bajo demanda. La medición pasiva a sondear es decidida por el Módulo de Cálculo (100), según el tipo de alarma recibida.
• Puede requerir que el módulo Activador de Monitorización Activa (107) inicie procedimientos de monitorización activa, ya sea en el Sistema de Soporte de Servicio externo, mediante el módulo COMM de la Capa de Servicio (101 ), o bien en los módulos de OAM (34) de MPLS de los nodos (31 ) de red, mediante el módulo COMM de la Capa de Red (102). El tipo de medición activa a activar es decidido por el Módulo de Cálculo (100), según el tipo de alarma recibida.
• Puede solicitar al módulo externo de Base de Datos (36) del Sistema, mediante el módulo COMM de Bases de Datos (103), información con respecto al estado de la red, o los servicios, según los requisitos de cada uno de los casos de uso. También puede solicitar a la base de datos externa, o DDBB (36), nuevos trayectos sobre los cuales debería proveer servicios restaurados. Finalmente, provee a la DDBB cambios de estado que pueda haber detectado, tal como la indisponibilidad de un enlace.
• Puede solicitar al módulo Planificador de Señalización (104) llevar a cabo operaciones de restauración sobre un grupo de servicios, proporcionando el nuevo trayecto en la solicitud.
• Almacena los valores de umbral configurados por el operador para definir las zonas de operación, según lo expresado en el caso 5 de uso, valores que son recibidos desde el módulo de Configuración (109).
• Provee al módulo de Almacenamiento de Registros (1 10) información asociada a las distintas alarmas recibidas y operaciones llevadas a cabo, de modo que puedan ser consultadas por el operador mediante el módulo COMM (105) del Operador.
Capa de Servicios, Capa de Red, Base de Datos, módulos (101 , 102, 103, 105) COMM del Operador y sistemas externos de interfaz del módulo Planificador (104) de Señalización. El objetivo común de tales módulos (101 , 102, 103, 104, 105) es ocultar a los módulos de procesamiento de QMM los detalles específicos de implementaciones potencialmente distintas de las interfaces externas, unificando las comunicaciones hacia los módulos internos. Por ejemplo, la Base de Datos (36) del Sistema puede ser implementada usando distintas tecnologías y, por tanto, la interfaz (203) DDBB - DBCOMM puede presentar distintas implementaciones técnicas, dando todas soporte al mismo conjunto de requisitos. El moduloDDBB COMM (103) está luego a cargo de traducir los distintos mensajes de formato, proporcionando mensajes unificados por la interfaz (212) CM - DBCOMM.
COMM de la Capa de Servicio (101 ), SLCOMM: mantiene interfaces con el Sistema de Soporte de Servicios (21 ) para recibir alarmas o solicitar pruebas activas en la capa de servicios. Las alarmas recibidas son luego enviadas al módulo (106) de Gestión y Correlación de Alarmas, mientras que la activación de pruebas activas se hace en el módulo Activador de Monitorización Activa (107).
COMMde la Capa de Red (102), NLCOMM: mantiene interfaces con los nodos de red para recibir alarmas desde distintos sistemas externos: i) Monitorización de Capa Física (33), ii) Analizador de Tráfico Pasivo (32) y / o iii) OAM (34) de MPLS.
También puede solicitar pruebas activas de OAM de MPLS o un sondeo pasivo bajo demanda. Las alarmas recibidas son enviadas al módulo (106) de Gestión y Correlación de Alarmas, módulo que también activa el sondeo pasivo bajo demanda. Por otra parte, la activación de pruebas activas se hace en el módulo (107) Activador de Monitorización Activa.
DDBB COMM (103), DBCOMM: mantiene interfaces con la Base de Datos (36) del Sistema para recibir información con respecto al estado de redes / servicios, o con respecto a nuevos trayectos sobre los cuales proveer servicios restaurados. Esta información es solicitada por el Módulo (100) de Cálculo. El Módulo (100) de
Cálculo también puede proveer, mediante este módulo, a la Base de Datos (36) del Sistema los cambios de estado de redes / servicios que el sistema (10) QMM ha detectado. Planificador de Señalización (104), SS: mantiene interfaces con funcionalidades de
Señalización (104) de MPLS, disponibles en la red para permitir procedimientos de restauración, a petición del Módulo (100) de Cálculo. Estas funcionalidades, en la implementación más sencilla, podrían admitir el acceso mediante una red de gestión que use la Interfaz de Línea de Comando, o CLI, de los nodos de la red. Son válidas soluciones alternativas, más sofisticadas, que proporcionen características equivalentes.
COMM (105) del Operador, OCOMM: proporciona una interfaz para que el operador (700) configure tanto los niveles de prioridad de las distintas alarmas que podrían ser recibidas como los umbrales entre las zonas de operación para el caso de uso en el cual el sistema (10) QMM funciona proactivamente, valores que son almacenados en el módulo (109) de Configuración. Su interfaz externa permite al operador (700) consultar información acerca de las alarmas ocurridas y asimismo las acciones realizadas, información llegada desde el módulo (1 10) de Almacenamiento de Registros.
El resto de los módulos internos de procesamiento del sistema (10) QMM son: Gestión y Correlación de Alarmas (106), AMC: este módulo está a cargo de procesar las distintas alarmas recibidas desde los módulos externos, mediante los módulos (101 , 102) COMM de la Capa de Servicios y la Capa de Red. Tras la recepción de una alarma, determina la prioridad según los valores proporcionados por el módulo (109) de Configuración, y ejecuta el algoritmo de correlación asociado a esa prioridad (básicamente, comprueba la existencia de alarmas con menos prioridad que hacen referencia al mismo fallo). Las alarmas agrupadas son luego enviadas al Módulo (100) de Cálculo, de modo que pueda iniciar los procedimientos, según lo indicado en la descripción de los casos de uso. El proceso de correlación está gobernado por un Reloj (108) de Sincronización, con lo que se asegura que las alarmas separadas en el tiempo sean tratadas de forma diferente.
El funcionamiento de este módulo para una alarma específica puede ser retardado en caso de que llegue una alarma con una prioridad más alta, si no es capaz de tratarlas en paralelo. Finalmente, la Gestión y Correlación (106) de Alarmas también está a cargo de sondear el Analizador de Tráfico Pasivo (32) externo, mediante el módulo (102) COMM de la Capa de Red, según lo solicitado por el Módulo (100) de
Cálculo, para la modalidad de funcionamiento bajo demanda de las herramientas de monitorización pasiva.
Activador de Monitorización Activa (107), AMT: este módulo está a cargo de incentivar las pruebas activas disponibles en los sistemas externos, en particular, en el Sistema de Soporte de Servicios (21 ) para pruebas en la capa de servicios, o usando las herramientas de OAM (34) de MPLS de los nodos de la red. La comunicación con los primeros se hace a través del módulo (101 ) COMM de la Capa de Servicios, mientras que el módulo (102) COMM de la Capa de Red permite la comunicación con los segundos. La ejecución de pruebas activas externas es solicitada por el Módulo (100) de Cálculo, y los resultados son proporcionados de vuelta por el Activador de Monitorización Activa (107).
Reloj (108) de Sincronización, SC: proporciona el reloj para la sincronización de los procedimientos de correlación llevados a cabo en el módulo (106) de Gestión y Correlación de Alarmas.
Configuración (109), CONF: almacena los parámetros de configuración proporcionados por el operador para los valores de prioridad a dar a cada una de las alarmas a recibir potencialmente, y para los dos umbrales que separan las zonas de operación en el caso de uso en el cual el sistema (10) QMM funciona proactivamente. El primer conjunto de parámetros se remite luego al módulo (106) de Gestión y Correlación de Alarmas, mientras que el segundo se remite al Módulo (100) de Cálculo.
Almacenamiento (1 10) de Registros, LS: almacena información acerca de alarmas ocurridas y acciones correctivas asociadas ejecutadas, información que es proporcionada por el Módulo (100) de Cálculo, antes de su presentación al operador (700), mediante el módulo (105) COMM del Operador.
Interfaces internas del sistema (10) QMM
Interfaz SLCOMM - AMC (206) e Interfaz NLCOMM - AMC (207):
Ambas interfaces comparten el mismo procedimiento: Para remitir todas las alarmas recibidas desde sistemas de monitorización externa hacia el módulo de Gestión y Correlación de Alarmas (106). El formato de los mensajes difiere, según el módulo externo específico que genera la alarma, dado que en cada procedimiento están disponibles distintos tipos de información; en particular, toda vez que está disponible información de "localización de fallos", debería añadirse al cuerpo del mensaje. El mensaje de respuesta desde el módulo de Gestión y Correlación de Alarmas (106) es un acuse de recibo. Además, la Interfaz NLCOMM - AMC (207) también permite a otro procedimiento: el módulo de Gestión y Correlación de Alarmas (106), solicitar un cierto tipo de medición pasiva externa en los nodos de la red. El mensaje de solicitud debe incluir: i) el nodo, o interfaz, de red donde debería hacerse la medición, ii) el tipo de medición a hacer, p. ej., el ancho de banda consumido, y iii) por cuánto tiempo, o cuántas repeticiones deberían hacerse. La entrada para el último parámetro podría tener la forma de "hasta que se sobrepase un cierto umbral", según lo requerido por el caso de uso en el cual el sistema (10) QMM funciona proactivamente. El mensaje de respuesta desde el módulo COMM (102) de la Capa de Red proporciona el resultado de la medición solicitada.
Interfaz SLCOMM - AMT (208) e Interfaz NLCOMM - AMT (209): Ambas interfaces comparten el mismo procedimiento: El módulo Activador de Monitorización Activa (107), para solicitar un cierto tipo de medición activa externa, ya sea por el Sistema de Soporte de Servicios (21 ) o bien por los mecanismos de OAM (34) de MPLS de los nodos (31 ) de la red. El mensaje de solicitud debe incluir: i) el servicio específico - en el caso de monitorización de capa de servicios - o el segmento / nodo / interfaz de red - en el caso de monitorización de la capa de red - a probar, ii) el tipo de medición a hacer, p. ej., retardo experimentado, y iii) por cuánto tiempo, o cuántas repeticiones deberían hacerse. La entrada para el último parámetro puede tener la forma "hasta que se sobrepase un cierto umbral", según lo requerido por el caso de uso en el cual el sistema (10) QMM funciona proactivamente. Los mensajes de respuesta desde los módulos (101 , 102) COMM de la Capa de Servicios y de la Capa de Red proporcionan el resultado de la medición solicitada.
Interfaz CM - AMC (210): Permite dos procedimientos: al módulo de Gestión y Correlación de Alarmas (106), para enviar conjuntos de alarmas correlacionadas al Módulo (100) de Cálculo. El formato de estos mensajes difiere, según el módulo externo específico que genera la alarma, según lo indicado también para las Interfaces (206, 207) SLCOMM - AMC y NLCOMM - AMC. El mensaje de respuesta desde el Módulo (100) de Cálculo es un acuse de recibo. al Módulo de Cálculo (100), para solicitar un cierto tipo de medición pasiva externa al módulo de Gestión y Correlación de Alarmas (106). El formato de los mensajes de solicitud y respuesta debería coincidir con un esquema equivalente al segundo procedimiento en la Interfaz (207) NLCOMM - AMC. Interfaz CM - AMT (21 1 ): Permite un procedimiento. al Módulo de Cálculo (100), solicitar un cierto tipo de medición activa externa al módulo Activador de Monitorización Activa (107). El mensaje de solicitud incluye la misma información que para las Interfaces SLCOMM - AMT (208) o NLCOMM - AMC (209), con un campo adicional para especificar el elemento externo para llevar a cabo la medición, es decir, si necesita ser gestionada por las sondas de la capa de aplicación o los mecanismos de OAM (34) de MPLS. El mensaje de respuesta desde el módulo Activador de Monitorización Activa (107) proporciona el resultado de la medición solicitada.
Interfaz CM - DBCOMM (212): Permite cuatro tipos de procedimientos, tres de solicitudes desde el Módulo de Cálculo (100) al módulo DBCOMM (103), y uno informativo, en la misma dirección: i) Solicitando el trayecto que está recorriendo un servicio especificado, de modo que los procedimientos de localización puedan iniciarse después de que sea recibida una alarma desde la capa de aplicación. El mensaje de solicitud incluye un identificador de servicio, mientras que la respuesta incluye el trayecto, por ejemplo, en forma de un Objeto de Ruta Explícita, o ERO.
ii) Solicitando los servicios que recorren un trayecto específico, de modo que sean conocidos todos los servicios que necesitan ser restaurados después de que se localiza un fallo. El mensaje de solicitud incluye el trayecto, por ejemplo, en forma de un ERO, mientras que la respuesta proporciona una lista con los identificadores de servicios. iii) Solicitando un nuevo trayecto para un servicio especificado, dado que el trayecto original no está disponible. Ha de observarse que un módulo específico para el cálculo de trayectos es requerido en la Base de Datos externa del Sistema con este fin. Un ejemplo de tal módulo es el Elemento de Cálculo de Trayecto - PCE - definido por la IETF. La solicitud incluye el identificador de servicio, mientras que la respuesta incluye el nuevo ERO. iv) Informando acerca de cambios de servicios / redes, causados por situaciones de fallo, de modo que la DDBB (36) externa se mantenga actualizada. El mensaje informativo incluye distintos campos, según el suceso específico que está siendo registrado, mientras que la respuesta incluye solamente un acuse de recibo.
Interfaz CM - SS (213): Permite un procedimiento: al Módulo de Cálculo (100), para solicitar una operación de restauración al Planificador (104) de Señalización. El mensaje de solicitud debe incluir: i) el servicio, o los servicios, que necesita(n) ser restaurado(s), y ii) el trayecto de red sobre el cual deberían ser restaurados estos servicios. Debe observarse, por lo tanto, que los servicios pueden ser agrupados en una única solicitud cuando comparten el mismo nuevo trayecto. Los servicios afectados por el mismo fallo, pero restaurados sobre distintos trayectos, generan distintas solicitudes en esta interfaz. La respuesta desde el módulo SS (104) incluye el resultado de la operación de restauración (cumplida con éxito o no, y el motivo en este último caso). Interfaz OCOMM - CONF (214): Permite dos procedimientos: al módulo COMM (105) del Operador, para almacenar en el módulo de Configuración (109) los valores de prioridad fijados por el operador (700) para las distintas alarmas externas disponibles en el sistema de monitorización. El mensaje incluye un valor entero no repetido para cada uno de los tipos de alarma, y la respuesta es un acuse de recibo. al módulo COMM (105) del Operador, para almacenar en el módulo de Configuración (109) los dos valores de umbral que separan las tres zonas de operación definidas en el caso de uso en el cual el sistema (10) QMM funciona proactivamente. El mensaje incluye dos valores entre 0 y 100, correspondientes a los valores de uso de ancho de banda que separan tales zonas. La respuesta es un acuse de recibo. Interfaz CONF - AMC (215): Permite un procedimiento: al Módulo de Configuración (109), para almacenar en el módulode Gestión y Correlación de Alarmas (106) los valores de prioridad de los distintos tipos de alarmas que el sistema puede recibir, valores que son configurables por el operador
(700). En otras palabras, esto es una especie de retransmisor del primer procedimiento en la Interfaz OCOMM - CONF (214). La respuesta es un acuse de recibo. Interfaz CONF - CM (216): Permite un procedimiento: al Módulo de Configuración (109), para almacenar en el Módulo de Cálculo (100) los valores de umbral que definen las zonas de operación (caso de uso en el cual el sistema (10) QMM funciona proactivamente), valores que son configurables por el operador (700). El mensaje incluye dos valores, que separan las zonas "correcta" y
"potencialmente conflictiva" a un lado, y a la última de la zona "crítica" en el otro. Nuevamente, es una especie de retransmisor, en este caso del segundo procedimiento en la Interfaz OCOMM - CONF (214). La respuesta es un acuse de recibo.
Interfaz OCOMM - LS (217): permite un procedimiento: al módulo COMM (105) del Operador, para solicitar al módulo de Almacenamiento de Registros (1 10) la información que permita tener un conocimiento claro de qué sucesos han ocurrido, y qué acciones correctivas han sido adoptadas por el sistema
(10) QMM, ante la solicitud del operador (700). La respuesta es una lista de sucesos y acciones asociadas.
Interfaz LS - CM (218): Permite un procedimiento: al Módulo de Cálculo (100), para almacenar en el módulo (1 10) de Almacenamiento de Registros toda la información requerida por los operadores (700), según lo indicado en la Interfaz (217) OCOMM - LS. La respuesta es un acuse de recibo. Interfaz SC - AMC (219): Permite un procedimiento: al Reloj (108) de Sincronización, para proporcionar la temporización para los procedimientos de correlación en el módulo de Gestión y Correlación de Alarmas (106). Esta es una señal continua de reloj, sin ningún mensaje específico intercambiado.
Interfaces externas del sistema (10) QMM
Las interfaces externas son interfaces que permiten la comunicación con sistemas externos que pueden presentar muchas clases distintas de implementaciones de interfaces. De esta manera, para los procedimientos internos específicos del sistema (10) QMM quedan ocultos los detalles de las tecnologías de implementación de sistemas externos, y comparten formatos unificados de mensajes. De esta manera, una nueva implementación de interfaz de un módulo externo solamente requiere modificaciones en los módulos COMM y las interfaces del sistema (10) QMM.
Interfaz SSS - SLCOMM (201 ): es el origen de las alarmas de la capa de servicio, retransmitidas por la interfaz SLCOMM - AMC (206), y retransmite las solicitudes de medición de la capa de servicio activo que llegan desde la interfaz SLCOMM -
AMT (208).
Interfaz NN - NLCOMM (202): es el origen de las alarmas de la capa de red retransmitidas por la interfaz NLCOMM - AMC (207), y retransmite las solicitudes de medición de capas de red pasivas y activas, que llegan desde las interfaces
(207, 209) NLCOMM - AMC y NLCOMM - AMT.
Interfaz DDBB - DBCOMM (203): retransmite las solicitudes y mensajes informativos que llegan desde la interfaz CM - DBCOMM (212).
Interfaz MPLS Sig - SS (204): retransmite las solicitudes que llegan desde la interfaz (213) CM-SS.
Interfaz Operador - OCOMM (205): es el origen de los parámetros configurables retransmitidos a través de la interfaz OCOMM - CONF (214), y de las solicitudes del operador (700) de información de registros, retransmitidas a través la interfaz OCOMM - LS (217).
Obsérvese que en este texto, el término "comprende" y sus derivaciones (tales como "comprendiendo", etc.) no deberían ser entendidos en un sentido excluyente, es decir, estos términos no deberían ser interpretados como excluyentes de la posibilidad de que lo que se describe y define pueda incluir elementos, etapas, etc., adicionales.

Claims

REIVINDICACIONES
1. Un procedimiento para restaurar degradaciones de QoS en redes de MPLS, caracterizado por comprender:
-recibir al menos una alarma (1 ) desde la Capa de Aplicación (20) o desde un nodo (31 ) de red de una red de MPLS (30),
-localizar un segmento con fallos de la red de MPLS(30), asociado a dicha al menos una alarma recibida;
-correlacionar todas las alarmas asociadas al segmento con fallos en la misma ubicación,
-determinar los servicios afectados por las alarmas correlacionadas,
-consultar una base de datos (36) para obtener trayectos de restauración para todos los servicios afectados,
-restaurar los servicios afectados usando los trayectos de restauración, -probar los servicios restaurados.
2. El procedimiento según la reivindicación 1 , en el cual, si la alarma (1 ) es recibida desde un nodo (31 ) de red, la localización de un segmento con fallos comprende solicitar la localización al nodo (31 ) de red.
3. El procedimiento según la reivindicación 1 , en el cual, si la alarma (1 ) es recibida desde la Capa de Aplicación (20), la localización de un segmento con fallos comprende solicitar la ubicación de un trayecto de red usado por la Capa de Aplicación (20) a la base de datos (36) y solicitar de herramientas OAM (34) de MPLS la ubicación del segmento con fallos a lo largo del trayecto de red.
4. El procedimiento según cualquier reivindicación precedente, en el cual la correlación de las alarmas comprende asignar una ponderación de prioridad a la alarma (1 ) recibida.
5. El procedimiento según la reivindicación 4, en el cual la ponderación de prioridad es asignada de acuerdo a los siguientes criterios: -si la alarma (1 ) es recibida desde la Capa de Aplicación (20), la alarma (1 ) es asignada a la más alta ponderación de propiedad;
— si la alarma (1 ) es recibida desde herramientas de OAM (34) de MPLS de un nodo (31 ) de red, la alarma (1 ) es asignada a la ponderación de prioridad más baja;
-si la alarma (1 ) es recibida desde las herramientas de monitorización de la Capa Física (33) de un nodo (31 ) de red, a la alarma (1 ) es asignada una mayor ponderación de prioridad que una ponderación de prioridad asignada a la alarma (1 ) en el caso en que es recibida desde el analizador de tráfico pasivo (32) de un nodo (31 ) de red.
6. El procedimiento según cualquier reivindicación precedente, en el cual la etapa de restauración usa la señalización (35) de la MPLS.
7. El procedimiento según cualquier reivindicación precedente, en el cual la prueba de los servicios restaurados es solicitada desde la Capa de Aplicación (20) o desde las herramientas OAM (34) de MPLS.
8. El procedimiento según cualquier reivindicación precedente, que comprende adicionalmente, si hay resultados de las pruebas de los servicios restaurados que fallan, consultar la base de datos (36) para obtener trayectos de restauración alternativos para todos los servicios afectados, y repetir las etapas de restauración y prueba usando los trayectos de restauración alternativos.
9. El procedimiento según cualquier reivindicación precedente, que comprende adicionalmente definir una pluralidad de zonas de operación de red y monitorizar segmentos de red para determinar en qué zona definida de operación de red está funcionando un segmento de red y, según la zona determinada de operación de red, si la monitorización es activa o pasiva.
10. El procedimiento según la reivindicación 9, en el cual la monitorización de segmentos de red es realizada por un analizador de tráfico pasivo (32) o por las herramientas OAM (34) de MPLS.
1 1 . El procedimiento según cualquiera de las reivindicaciones 9 a 10, en el cual, si la zona determinada de operación de red es crítica, indicando potenciales degradaciones de QoS, se recibe una alarma (1 ) desde un nodo (31 ) de red de la red de MPLS (30).
12. El procedimiento según la reivindicación 1 1 , en el cual, si una alarma (1 ) es recibida desde el analizador de tráfico pasivo (32), la monitorización de los segmentos de red es continuada por las herramientas OAM (34) de MPLS.
13. El procedimiento según la reivindicación 1 1 , en el cual, si la alarma (1 ) es recibida desde las herramientas OAM (34) de MPLS, las etapas de restauración y prueba son repetidas usando trayectos de restauración para los servicios que recorren el segmento de red en la zona crítica determinada de operación de red.
14. Un sistema (10) para restaurar degradaciones de QoS, integrado en una red
(30) de MPLS, caracterizado por comprender adicionalmente:
-un módulo de comunicación de la capa de servicios (101 ), para recibir al menos una alarma (1 ) desde la Capa de Aplicación (20), y un módulo de comunicación de la capa de red (102), para recibir al menos una alarma (1 ) desde un nodo (31 ) de red de la red de MPLS (30),
-un módulo (de gestión y correlación de alarmas106), que recibe todas las alarmas asociadas a un segmento con fallos en una misma ubicación desde el módulo de comunicación de la capa de servicios (101 ), y el módulo de comunicación de la capa de red (102), y correlaciona las alarmas recibidas,
-al menos un módulo de cálculo (100), que obtiene la ubicación del segmento con fallos a partir de medios para localizar segmentos de la red de MPLS (30), configurados para determinar los servicios afectados por las alarmas correlacionadas, que el módulo de cálculo (100) recibe desde el módulo de gestión y correlación de alarmas (106), consultando una base de datos (36) de la cual se obtienen unos trayectos de restauración para todos los servicios afectados,
-un planificador (104) de señalización conectado con la señalización (35) de la MPLS para permitir la restauración de los servicios afectados cuando es activado por el módulo de cálculo (100), usando los trayectos de restauración obtenidos,
-un activador (107) de monitorización activa, que es solicitado por el módulo de cálculo (100) para obtener pruebas sobre los servicios restaurados desde la capa de servicios, a través del módulo de comunicación de la capa de servicio (101 ), y desde la capa de red, a través del módulo de comunicación de la capa de red (102).
15. Un programa de ordenador que comprende medios de código de programa de ordenador, adaptados para realizar las etapas del procedimiento según cualquier reivindicación de 1 a 13, cuando dicho programa es ejecutado en un ordenador, un procesador de señales digitales, una formación de compuertas programables en el terreno, un circuito integrado específico de la aplicación, un micro-procesador, un micro-controlador o cualquier otra forma de hardware programable.
PCT/ES2013/070929 2013-12-26 2013-12-26 Procedimiento y sistema para restaurar degradaciones de la qos en redes de mpls WO2015097318A1 (es)

Priority Applications (3)

Application Number Priority Date Filing Date Title
PCT/ES2013/070929 WO2015097318A1 (es) 2013-12-26 2013-12-26 Procedimiento y sistema para restaurar degradaciones de la qos en redes de mpls
US15/108,273 US20160308709A1 (en) 2013-12-26 2013-12-26 Method and system for restoring qos degradations in mpls networks
EP13900511.0A EP3089409A4 (en) 2013-12-26 2013-12-26 Method and system for restoring qos deteriorations in mpls networks

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/ES2013/070929 WO2015097318A1 (es) 2013-12-26 2013-12-26 Procedimiento y sistema para restaurar degradaciones de la qos en redes de mpls

Publications (1)

Publication Number Publication Date
WO2015097318A1 true WO2015097318A1 (es) 2015-07-02

Family

ID=53477606

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/ES2013/070929 WO2015097318A1 (es) 2013-12-26 2013-12-26 Procedimiento y sistema para restaurar degradaciones de la qos en redes de mpls

Country Status (3)

Country Link
US (1) US20160308709A1 (es)
EP (1) EP3089409A4 (es)
WO (1) WO2015097318A1 (es)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111865670A (zh) * 2020-07-03 2020-10-30 宏图智能物流股份有限公司 一种仓库网络快速恢复方法以及仓库网络快速恢复服务器

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10404548B2 (en) 2016-08-29 2019-09-03 Cisco Technology, Inc. Control of network nodes in computer network systems
US11063837B2 (en) * 2018-11-28 2021-07-13 Cisco Technology, Inc. Customized network load-balancing using machine learning
CN111294226B (zh) * 2018-12-10 2023-05-09 华为技术有限公司 通信方法和装置
US11552874B1 (en) * 2019-01-18 2023-01-10 Keysight Technologies, Inc. Methods, systems and computer readable media for proactive network testing
US11627049B2 (en) * 2019-01-31 2023-04-11 Hewlett Packard Enterprise Development Lp Failsafe firmware upgrade for cloud-managed devices
CN112468311B (zh) * 2019-09-09 2023-01-03 中国移动通信有限公司研究院 一种保护倒换的方法、节点设备和存储介质
US11671341B2 (en) * 2019-09-19 2023-06-06 Hughes Network Systems, Llc Network monitoring method and network monitoring apparatus
JP7179810B2 (ja) * 2020-10-27 2022-11-29 株式会社日立製作所 クラスタシステム、クラスタシステムのフェイルオーバー制御方法
CN114138348A (zh) * 2021-11-16 2022-03-04 中国电信集团系统集成有限责任公司 业务恢复优先级评估方法及设备、存储介质和产品
CN116170353B (zh) * 2023-02-01 2023-10-24 广州通则康威智能科技有限公司 一种路由器下挂设备自动测速方法、系统及存储介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1176759A2 (en) 2000-07-24 2002-01-30 Alcatel Canada Inc. Method and apparatus for Network management support of OAM functionality
US20110267980A1 (en) * 2010-01-29 2011-11-03 Calippe Joel R Method and apparatus for hint-based discovery of path supporting infrastructure
US20120054346A1 (en) * 2010-08-26 2012-03-01 Futurewei Technologies, Inc. Method and System for Cross-Stratum Optimization in Application-Transport Networks

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2933021B2 (ja) * 1996-08-20 1999-08-09 日本電気株式会社 通信網障害回復方式
CA2474879C (en) * 2001-07-03 2013-04-09 Imagine Broadband Limited Method and system for monitoring service performance over a virtual private network connection by simulating end user activity
EP1502396A1 (de) * 2002-05-08 2005-02-02 Siemens Aktiengesellschaft Verfahren zur unterstützung von ersatzschaltungen in mpls-netzen
US8179786B2 (en) * 2004-05-19 2012-05-15 Mosaid Technologies Incorporated Dynamic traffic rearrangement and restoration for MPLS networks with differentiated services capabilities
US7965620B2 (en) * 2004-05-25 2011-06-21 Telcordia Licensing Company, Llc Method, computer product and system for correlating events in a network
US7573808B2 (en) * 2004-08-06 2009-08-11 Fujitsu Limited Smart resync of data between a network management system and a network element
US7822837B1 (en) * 2004-12-30 2010-10-26 Packeteer, Inc. Adaptive correlation of service level agreement and network application performance
US7551623B1 (en) * 2005-01-31 2009-06-23 Packeteer, Inc. Modulation of partition parameters achieving delay-based QoS mechanism
JP4758259B2 (ja) * 2006-01-31 2011-08-24 株式会社クラウド・スコープ・テクノロジーズ ネットワーク監視装置及び方法
US7907535B2 (en) * 2007-11-26 2011-03-15 Alcatel-Lucent Usa Inc. Anomaly detection and diagnosis using passive monitoring
US8284044B2 (en) * 2008-12-23 2012-10-09 Telefonaktiebolaget Lm Ericsson (Publ) Poll-based alarm handling system and method
US7961599B2 (en) * 2009-03-03 2011-06-14 Alcatel Lucent Pseudowire tunnel redundancy
CN103370904B (zh) * 2010-09-30 2018-01-12 瑞典爱立信有限公司 用于确定网络意外事件的严重性的方法、网络实体
US8774010B2 (en) * 2010-11-02 2014-07-08 Cisco Technology, Inc. System and method for providing proactive fault monitoring in a network environment
US8964563B2 (en) * 2011-07-08 2015-02-24 Telefonaktiebolaget L M Ericsson (Publ) Controller driven OAM for OpenFlow
EP2795841B1 (en) * 2011-12-21 2021-11-24 Telefonaktiebolaget LM Ericsson (publ) Method and arrangement for fault analysis in a multi-layer network

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1176759A2 (en) 2000-07-24 2002-01-30 Alcatel Canada Inc. Method and apparatus for Network management support of OAM functionality
US20110267980A1 (en) * 2010-01-29 2011-11-03 Calippe Joel R Method and apparatus for hint-based discovery of path supporting infrastructure
US20120054346A1 (en) * 2010-08-26 2012-03-01 Futurewei Technologies, Inc. Method and System for Cross-Stratum Optimization in Application-Transport Networks

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
JUAN FERNANDEZ-PALACIOS ET AL.: "E2E-OAM in convergent Sub-wavelength-MPLS environments.", FUTURE NETWORK&MOBILE SUMMIT (FUTURENETW), July 2012 (2012-07-01), BERLIN, GERMANY, pages 1 - 11, XP032231982 *
MAMADOU SIDIBE ET AL.: "QoS monitoring framework for end-to-end service management in wired and wireless networks.", COMPUTER SYSTEMS AND APPLICATIONS, 2008. AICCSA 2008. IEEE /ACS INTERNATIONAL CONFERENCE, 31 March 2008 (2008-03-31), PISCATAWAY, NJ, USA, pages 964 - 968, XP031245070 *
See also references of EP3089409A4
SIDIBE M ET AL.: "QoS monitoring for end-to-end heterogeneous networks configurations management.Automation, Quality and Testing, Robotics, 2008. AQTR 2008.", IEEE INTERNATIONAL CONFERENCE ON, 22 May 2008 (2008-05-22), PISCATAWAY, NJ, USA, pages 364 - 368, XP031298112 *
XIANGPING WU ET AL.: "Improve the fault management capability of IP networks.", RELIABILITY, MAINTAINABILITY AND SAFETY, 2009. ICRMS 2009. 8TH INTERNATIONAL CONFERENCE, 20 July 2009 (2009-07-20), PISCATAWAY, NJ, USA, pages 1164 - 1168, XP031532926 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111865670A (zh) * 2020-07-03 2020-10-30 宏图智能物流股份有限公司 一种仓库网络快速恢复方法以及仓库网络快速恢复服务器
CN111865670B (zh) * 2020-07-03 2023-06-30 宏图智能物流股份有限公司 一种仓库网络快速恢复方法以及仓库网络快速恢复服务器

Also Published As

Publication number Publication date
EP3089409A4 (en) 2017-11-01
US20160308709A1 (en) 2016-10-20
EP3089409A1 (en) 2016-11-02

Similar Documents

Publication Publication Date Title
WO2015097318A1 (es) Procedimiento y sistema para restaurar degradaciones de la qos en redes de mpls
US10230605B1 (en) Scalable distributed end-to-end performance delay measurement for segment routing policies
US9521055B2 (en) Network connectivity management
US7773611B2 (en) Method and apparatus for packet loss detection
US8111627B2 (en) Discovering configured tunnels between nodes on a path in a data communications network
US8631115B2 (en) Connectivity outage detection: network/IP SLA probes reporting business impact information
ES2359097T3 (es) Localización de fallos en arquitecturas basadas en múltiples árboles de expansión.
US11677653B2 (en) System, method and nodes for performance measurement in segment routing network
US7969908B2 (en) Connectivity outage detection based on a multicast management MPLS-VPN group
US20060215577A1 (en) System and methods for identifying network path performance
US8612576B1 (en) Wide area network monitoring
US20130148494A1 (en) Dynamic Bandwidth Adjustment in Packet Transport Network
US9813300B2 (en) Media flow tracing in third party devices
Liang et al. On diagnosis of forwarding plane via static forwarding rules in software defined networks
EP4142239A1 (en) Network performance monitoring and fault management based on wide area network link health assessments
KR20140088206A (ko) 네트워크 측정 트리거들을 사용하는 서비스 보장
CN108924044A (zh) 链路维持方法、pe设备及可读存储介质
US20170195132A1 (en) Data Monitoring/Aggregation For Evaluating Connections Between Networks
US10389615B2 (en) Enhanced packet flow monitoring in a network
Troia et al. Resilience of Delay-sensitive Services with Transport-layer Monitoring in SD-WAN
US8351324B2 (en) Analyzing service impacts on virtual private networks
US20110116384A1 (en) Network connectivity management
EP3735767B1 (en) Method and system for assigning resource failure severity in communication networks
US11765059B2 (en) Leveraging operation, administration and maintenance protocols (OAM) to add ethernet level intelligence to software-defined wide area network (SD-WAN) functionality
JP5469104B2 (ja) 情報処理装置、ネットワーク試験方法、及びプログラム

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: 13900511

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 15108273

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

REEP Request for entry into the european phase

Ref document number: 2013900511

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2013900511

Country of ref document: EP