Table of Contents
Introduction
2
The Necessity of Performance Management 2
Metro Ethernet Performance Challenges
3
A Solution to the Challenges of Metro Ethernet Performance
4
Service-Centric Performance Management of Metro Ethernet
6
KPIs 6
Resource Monitoring KPIs 7
End-to-End Measurement KPIs 8
Traffic Analysis KPIs 9
Service Monitoring 9
Aggregation, Abstraction and Analysis 10
Aggregation 10
Abstraction 10
Analysis 11
Service-Customer-Resource Relationships
12
Introduction
Today Metro Ethernet is a billion-dollar market, according to market-research firm IDC, and by their prediction is expected to reach $6.3 billion worldwide by 2008. The advantages of Metro Ethernet lie in its ability to move data at higher speeds for lower costs than alternative technologies, thereby
providing a compelling argument to use Ethernet as a WAN transport service. Enterprise customers are increasingly aware of this benefit, as well as others related to improved
management cost and ease of use. With significant expertise and comfort around Ethernet, Enterprises are seeking to adopt Metro Ethernet as a cost-effective networking
technology. Similarly, Service Providers have anticipated the needs of their customers and are building out new Metro Ethernet networks and services. They not only foresee the promise of new revenue potential and higher flexibility in bandwidth provisioning but operational and capital savings as well.
However to harness the full potential of Metro Ethernet, there are considerable service quality challenges that must be addressed. To do so, it is imperative that Service Providers and their customers integrate a comprehensive Performance Management platform into their overall management delivery chain.
After briefly reviewing the unique performance characteristics of Metro Ethernet, this paper will describe the challenges associated with guaranteeing service quality. It will go on to explain the paramount role of Performance Management in addressing those challenges to ensure reliable service delivery and customer-centric Quality of Service.
The Necessity of Performance Management
Performance Management provides a set of critical Service Assurance functions in the management of core, edge and customer networks. It offers the ability to proactively plan and optimize transport layer capacity, preemptively detect transport and application layer performance problems and rapidly resolve performance issues to ensure reliable and consistent delivery of network services.
Performance Management is more effective than traditional fault management solutions that are inherently reactive by nature. By combining real-time and historical monitoring and analysis of network performance for the purpose of detecting ongoing and impending degradations, performance management is a proactive discipline. Trend analysis predicts a point in time where capacity will be reached and performance compromised. Long-term historical depth of detailed metrics supports traffic engineering and troubleshooting. Across these capabilities, threshold analysis is performed outside the equipment, allowing for the creation of performance-based traps as opposed to traps coming from within the equipment. This opens the opportunity to more sophisticated aspects of preventative performance problem analysis, such as identifying deviations from a baseline, accounting for transient peaks, and detecting hazardous combinations of stressed performance. More advanced Performance Management with a service-centric focus can then abstract those measurements into easily understood information within the context of service and business parameters.
In doing so, Performance Management provides proactive information that can be used to take appropriate action, preemptively and rapidly, before conditions worsen and before impacting customers.
Metro Ethernet Performance Challenges
The simplicity of Metro Ethernet as one of its overarching features creates some strong shortcomings in terms of performance predictability and sustainability. These
disadvantages can be highlighted by comparing Metro Ethernet to the technology it will often replace, ATM and Frame Relay (ATM/FR). Metro Ethernet is not as deterministic and resilient, making it difficult to match the performance and reliability of ATM/FR. Specifically this translates into the following challenges:
1) The reliable provisioning mechanisms of ATM/FR enable it to minimize risk of over-provisioning and hence congestion that leads to performance degradation. In contrast, Metro Ethernet has no such inherent control, causing it to be more prone to performance degradation than ATM/FR.
2) Once the connection and the path of ATM/FR have been established, bandwidth can be guaranteed and performance levels are predictable. Ethernet is conversely dynamic, meaning that paths can change, leading to uneven loading and
bottlenecks. Furthermore, transient queuing delays can occur on high-speed Ethernet interfaces in the core of the network when the network is heavily utilized. Therefore, performance can change indeterminately.
3) Because Ethernet was developed as a LAN technology, link management mechanisms such as Spanning Tree Protocol (STP) might not smoothly scale to greater sized networks. Long spanning tree reconvergence times can threaten performance and interrupt service by blocking traffic.
Transport Topology Strengths Limitations
ATM/Frame Relay Static PVC-based, long-distance
channels providing permanent point-to-point connections.
Highly reliable, guaranteed bandwidth and predictable performance. Inherent congestion avoidance ensures consistently low latency.
Less flexibility and greater complexity of service activation, provisioning and change. Higher cost of operations.
Metro Ethernet at the edge with an MPLS core
Dynamic, connection-less, point to point or any to any packet flow.
High speed, flexible, low cost replacement of Frame Relay and ATM.
Lack of over-provisioning and congestion controls.
Performance is at risk unless carefully managed/engineered.
Table 1: Key Aspects of Metro Ethernet Compared to Frame Relay and ATM
As summarized in Table 1, limitations of Metro Ethernet can pose service level performance risk to the service provider and their customers. Only a sound Performance Management approach can address these issues.
A Solution to the Challenges of Metro
Ethernet Performance
At a time when business-driven Service Level Agreements (SLAs) are more stringent than ever, and considering the dynamic, indeterministic nature of Metro Ethernet, Performance Management is needed from the moment of service activation and continuously thereafter. What must also be considered is that multiple types of Metro Ethernet services can be offered (Ethernet Line Service, Ethernet LAN Service, Ethernet Relay Service) with multiple levels of QoS to a large number of customers. Changes to subscribership, customer usage, end to end connectivity paths and traffic engineering policies are constant. Amid all this complexity and change, marginal and intermittent service levels will surely exist that can be extremely difficult to detect and resolve. Such challenging and dynamic conditions require Performance Management to constantly supervise the performance and quality of Metro Ethernet services.
By continuously monitoring, analyzing and reporting on performance at each ingress/egress point end-to-end and by testing/monitoring performance between network end points, the necessary information can be acquired to understand Metro Ethernet service levels.
Performance Management of Metro Ethernet will: - Provide multiple means of collecting performance
information
- Measure network and platform utilization and error levels - Monitor traffic against provisioned traffic profiles
- Verify QoS policies in relation to each class of service on the interface
- Detect sudden and long term deviations from normality - Measure utilization in relation to interface capacity
- Project future capacity utilization based on long term trends - Detect problematic performance conditions
- Provide organized, high-level analysis and detailed metrics An important aspect of measuring Metro Ethernet utilization is to account for traffic profiles which control the rate at which frames can traverse a customer interface to manage available resources and allow for bandwidth change on-demand. A typical Metro Ethernet traffic profile consists of the parameters shown in Table 2 that would be established on UNIs (User-Network Interfaces), EVCs (Ethernet Virtual Connections) and/or by CoS (Class of Service).
Parameter Description
CIR (Committed Info Rate) The maximum rate at which service frames can be delivered, on
average. CIR settings limit the frame size to emulate speed throttling, e.g.: speeds such as 2Mbps, 10 Mbps, 50 Mbps over a 100 Mbps 802.1 interface. CIR will need to meet end-to-end service level objectives.
Frame rates above the CIR (and frame sizes above the CBS) may be discarded, depending on the EIR parameter.
CBS(Committed Burst Size) CBS is the maximum allowable frame size in accordance with the CIR.
EIR (Excess Information Rate) The maximum rate at which service frames can be delivered above the CIR, on average. These frames will have no service level objective.
Frame rates and sizes above the EIR and EBS are subject to discard.
EBS(Excess Burst Size) EBS is the maximum allowable frame size in accordance with the EIR.
The traffic profiles are a key point of reference against which Metro Ethernet performance and service levels are measured. In Figure 1, a simplistic Ethernet Line (E-Line) architecture is shown for the purpose of illustrating the use of traffic profiles against the physical and virtual components that must be managed. This requires Performance Management that employs a combination of collection, analysis and reporting techniques that tie Metro Ethernet traffic statistics to UNIs, Customer Equipment (CEs), Provider Equipment (PEs) and end-to-end service levels.
Figure 1: Defining a Typical E-Line Service Configuration
UNI CE U-PE U-PE CE EVC1 EVC2 U-PE CE UNI UNI EVC1 EVC2 Data Video
VoIP Traffic Profile A
Traffic Profile B Traffic Profile C
UNI: User-Network Interface CE: Customer Equipment EVC: Ethernet Virtual Connection U-PE: User-Facing Provider Equipment
Service-Centric Performance Management of
Metro Ethernet
A resource-centric approach to managing dynamic technologies such as Metro Ethernet is functionally and operationally insufficient. It lacks an ability to understand relationships between quality (from the perspective of the user) and performance (from the perspective of the technology) to ensure customer satisfaction and SLA protection. A service-centric approach to Performance Management provides that ability, including proactive analysis and preemptive alerting that can map customers to service levels and deliver visibility into relationships between end-to-end performance and network resources.
Service centric implies both a 'top-down' and 'bottom-up' approach to understanding Metro Ethernet performance. Hierarchically, Metro Ethernet offerings are based on services, customers, their EVCs and their Virtual LANs (VLANs), each with physical interfaces, UNIs, service level classes, CEs and PEs. From 'top' to 'bottom', each of these have performance attributes that can be mapped to one another.
In doing so, service-centric Performance Management allows for prioritization of identified performance problems, troubleshooting, end-to-end service level management and proactive capacity planning based on customer, service and resource impact.
The following service-centric Performance Management collection and analysis components are required to reliably offer and manage Metro Ethernet services.
KPIs
Multiple techniques are necessary to gather sufficient
information to manage Metro Ethernet performance. Resource monitoring, end-to-end testing and traffic flow analysis KPIs are all needed in combination to confirm service levels, anticipate capacity limitations, detect problems as they develop and troubleshoot.
Figure 2 shows a generic path of CEs and PEs and the performance information sources for producing vendor-agnostic KPIs.
Figure 2: KPI Data Sources
Resource Monitoring Flow Capture CE U-PE N-PE P N-PE PE-AGG Shadow Router Test System CE Computer Equipment U-PE
Aggregation Edge Core Edge Access
End-to-End Measurements Access
Resource Monitoring KPIs
Basic resource monitoring in principle is a straightforward process, however monitoring the behavior of Metro and core networks, MPLS in particular, is a more complex problem. Resource queries can provide a wide variety of data via industry standard and proprietary protocols. Table 3 demonstrates multiple methods of collection. In the core, routers, WAN switches and Multi-Service Provider Edge (MSPE) device MIBs classically produce rich sources of information on physical and
virtual interfaces, and the physical platform itself. Polling and storing this data is easy enough, as long as there is a solid understanding of standard MIBs as well as the leading vendor MIBs. Beyond that, knowing what is relevant and how to gather, analyze, aggregate and process that data on a large scale is not trivial. It requires a standards-based foundation and an empirical process of refinement to perfect. The result is a set of
Method Complexity Metro
Ethernet Value
SNMP Standard MIBs
SNMP Proprietary MIBs
TL1
CORBA/XML
Table 3: Performance Monitoring Methods
Key Performance Indictors (KPIs) and detailed troubleshooting metrics that deliver real value.
Some equipment vendors offer Element Management Systems (EMS), such as the Alcatel 5620 Service Aware Manager (SAM) and Cisco IP Solution Center (Cisco ISC), which support configuration, provisioning and monitoring of their own devices. Performance data is gathered by these systems, by SNMP and through proprietary methods, but always in a controlled way. The information that can be drawn from them through APIs and log files is generally the same as can be gathered directly. Yet in the case of Metro Ethernet, the EMS information source is more extensive.
Table 4 provides a non-exhaustive list of KPIs that are the most important to managing Metro Ethernet performance and service levels. The analysis behind these KPIs is not particularly complex, involving raw-to-rate and other basic calculations. More advanced KPIs can be obtained when performing aggregation, abstraction and analysis, as described in the next section.
Metro Ethernet services will have QoS policies imposed to make it more reliable and deterministic. The network KPIs listed in Table 4 are derived with respect to each CoS within each VLAN, where available. This includes VLANs (or customer ports) that carry only one CoS level.
KPI Description
Device KPIs
Availability Percentage of time a physical or logical resource is available for use. A variety of protocols (such as SNMP and ICMP) are typically used.
CPU, Memory, Buffer Utilization
Calculated as a percentage of capacity. Excessive levels, either individually or in combination, indicate resource overloading which can result in delays in data transfer and a high rate of packet errors or dropped packets.
CIR Utilization Percentage of customer utilization levels relative to the CIR.
Queue Drop Discarded packets, including those measured as Tail and Random drop. Implies congestion or improper
End-to-End Measurement KPIs
The purpose of Metro Ethernet is to deliver a service end to end, thereby driving the necessity of end-to-end
measurements that can confirm delivery of those services. End-to-end measurements play an important role determining service quality, irrespective of the devices between. Moreover, a lack of in-depth instrumentation of devices in support of QoS performance visibility makes end-to-end measurements essential.
By delivering frames between Layer 2 network end-points (UNIs) and measuring the round trip results, the ability of the network to support the end user can be validated. In order to accomplish this, a mapping between MAC address and IP address is required, by means of Layer 3 end-to-end
instrumentation such as IP SLAs or Juniper RPM, to report on Metro Ethernet end-to-end performance levels. This mapping mechanism is not always necessary for vendors such as Alcatel that provide direct end-to-end Layer 2 OAM MAC Ping instrumentation.
Advantages of end-to-end testing over resource monitoring include:
- Does not require focus on a particular device/type when network-wide problems exist
- Collects performance information regardless of network activity levels
- Controllable on a continuous basis
- Gathers information not available via resource monitoring
The last point is critical to monitoring service levels in a relevant way. Response Time, Jitter and Delay are simply not available otherwise. Equipment vendors such as Cisco and Juniper offer embedded end to end tools, IP SLAs and RPM respectively, to support the creation of test "probes" within their equipment. Test traffic is generated by the "sender" (router, shadow router or switch) to the "target" (responder, router or IP host).
Configured by a dedicated test system, a full mesh of probes can be created for each CoS to fully instrument all possible VPLS paths in moderate sized environments. On a larger scale, a full mesh of all CE to CE destination pairs is not feasible to implement and manage. The load on the performance management system and the devices involved would be far too taxing. In this case, probes must be created selectively. Since PEs support multiple connection points, they can be used to establish a full mesh. Customer equipment can then be used selectively to enhance end-to-end perspectives. As another alternative, probes can be created on-demand, either manually or automatically, to aid in troubleshooting activities. Table 5 describes end-to-end KPIs and methods of testing.
KPI Description Technique
Reachability The percentage of time that an end element responds to transaction requests.
Typically a resource monitoring entity that performs end-to-end testing.
Test entity located as close as possible to the customer pings IP host elements at the opposite side of the EVC.
Reponse Time
The average time it takes for a request to reach a target.
Availability Percentage of time a device or interface is available for use.
Cisco IP SLAs and Juniper RPM probes configured by a monitoring entity. Ideally one probe for each application, CoS and type of protocol that go through the path.
Target can be any IP host.
Delay One way and round-trip delay of layer 2
and 3 transactions.
Target can be any IP host or another router.
Jitter Variation of delay. Target is a synchronized responder.
Frame Loss Percentage of undelivered frames compared to total number of frames submitted.
Alcatel OAM MAC Ping Target is any host element.
Traffic Analysis KPIs
Even with traffic profiles and QoS policies in place, problems associated with Spanning Tree Protocol can still occur. NetFlow and similar flow analysis technologies (and to a lesser extent RMON2) that are commonly used in the IP world bring effective support in troubleshooting Metro Ethernet by detecting and reporting on abnormal traffic behavior. Long STP reconvergence times will create an abnormal reduction in traffic that can be detected by NetFlow. ToS reporting capabilities by NetFlow identify which services are impacted.
Service Modeling
Metro Ethernet is a service-centric technology which requires performance measurements against customer SLAs as defined between customer UNIs. Service Modeling is the foundation to service-centric Performance Management of Metro Ethernet services. It understands relationships between resources, the services they support, the customers subscribing to those services and their respective performance indicators. Without this structure, performance management can not support higher valued management tasks such as service-centric problem identification, customer resource impact analysis, service-oriented capacity planning and business-prioritized troubleshooting. Without the aid of such a model, KPIs and
reports can have no logical order or connectedness. Volumes of information collected across multiple customers and network elements would otherwise be a costly and time-prohibitive process to assemble, aggregate, abstract and organize. The service model is fed by Service, Customer, Inventory and Traffic Profile information from service activation and
provisioning systems. The automatic feed of information to the model during provisioning plays a critical role in terms of immediacy, accuracy and operational efficiency. The same process performed manually on a multi-customer, multi-service scale is simply not feasible, nor accurate. Vendor EMS solutions such as Cisco ISC and Alcatel 5620 SAM, as well as multi-vendor OSS provisioning platforms such as those offered by Cramer, MetaSolv and Syndesis, provide proven Metro Ethernet provisioning solutions that are capable of delivering service-centric topology feeds to Performance Management.
As configuration changes are made and customers are added, the model is dynamically updated so that the correct resources can be monitored relative to all the appropriate service and customer dimensions, as indicated in Figure 3. The model therefore provides a structure for gathering, storing, aggregating, organizing and locating information.
Figure 3: Populating the Metro Ethernet Performance Management Service Model
Provisioning Queries End-to-End Testing Populate Performance Model Structured / Actionable Performance Information Service Configuration & Activation Service Configuration
and Activation Metro Ethernet PerformanceManagement Service Model Services E-Line E-LAN QoS Managed CE, PE Customer Profiles Names Sites CE Names Ports VLAN IDs VLAN CoSs EVCs Bandwidth Profiles Inventory P Names PE Names Sites VLAN IDs DiffServ/TOSs LSPs EVCs Service Profiles Devices to Manage
To reiterate, the goal of the service model is to interrelate Ethernet service attributes, KPIs and detailed performance metrics end to end. However, considering the rapidly growing state of Metro Ethernet business requirements and technology, no rigid performance management service model can possibly achieve that goal. If the model design is flexible and open to change, the performance management solution will be able to adapt and support both vendor agnostic and service-centric objectives through the evolution of Metro Ethernet.
The underlying model design has a direct impact on flexibility and maintainability. Models built upon relational tables of KPIs and service topology attributes are difficult to maintain. Table interlinking is generally linear and hence requires a complex series of iterative changes to take place. Conversely, object-oriented models treat service and resource properties and their KPIs as modular objects that can be linked
hierarchically. Changes to the intra-model relationships can be made centrally. Global changes to the way KPIs are associated, aggregated or analyzed can be made in a single step through inheritance.
Aggregation, Abstraction and Analysis
Metro Ethernet services at any reasonable scale will produce a vast number of KPIs to review. Information overload will quickly become a distinct problem, even with a Metro Ethernet service model to organize those KPIs. Therefore, the service model also plays a role in aggregation and abstraction of KPIs. The result is a reduction (or distillation) of
information by grouping it to Metro Ethernet performance dimensions, customer attributes, traffic profiles and QoS policies. Additionally, more advanced analytics processed on those KPIs enrich the sophisticated proactive and preemptive capabilities of Performance Management to accurately detect performance degradation.
Aggregation
KPI data is reduced from short time intervals to longer time intervals through temporal aggregation. This is a basic but important factor when accommodating large amounts of information over time. For example, KPIs such as end-to-end measurements of Jitter collected every 5 minutes are
aggregated into hourly, daily and weekly increments to support SLA reporting.
Grouping of KPIs to various service model dimensions allows considerable condensing of information into basic status views. Examples include: Availability of resources supporting a particular customer, availability of PE resources in general, interfaces with the most errors in a particular location, number of dropped packets for the different QoS classes on a group of VLANs.
Abstraction
Multiple KPIs are combined into a composite KPI to infer the health of a resource or interface through the use of a single value (aka: level of wellbeing). Beyond a simple reduction of many indicators to one, the use of composite indicators helps identify problems not otherwise noticeable at a granular level. Examples of abstracted KPI calculations include:
- Composite Platform Status: CPU usage, memory usage and buffer usage values that exceed a hazardous level* are counted, weighted and combined. Ideally, CPU usage is considered for all CPUs of the monitored device; memory usage includes process and kernel values; and buffer utilization is relative to the maximum number of buffers allowed.
- Prolonged Interface Hazards: Based on the amount of time a network interface has been in a 'degraded' mode, a condition where the average rate of errors in combination with the average utilization (for inbound and outbound traffic) reaches hazardous levels*.
Analysis Description
Baseline Records hourly, daily, weekly, monthly norms, typically against network utilization KPIs.
Linear, multi-level thresholds Multiple upper and lower limits that detect different levels of performance degradation severity.
Dynamic threshold analysis Automatic adjustment of thresholds in relation to baseline. By tracking a so-called tunnel of normality, detects sudden and significantly high abnormalities or changes.
Pattern distributions, standard deviation and percentile
Improves accuracy by differentiating brief peaks in performance from sustained problematic conditions.
Historical trending Predicts where utilization levels will be in the near and distant future. Calculations based on historical data improve accuracy. Time-to-capacity values are critical to capacity planning.
Analysis
Advanced KPI analysis produces proactive information at two levels. 1) Early warnings (through alerts) of existing and potential performance problems, based on real-time analysis and 2) Long term predictions of capacity utilization levels based on historical analysis. The calculations behind these KPIs are as follows.
Service-Customer-Resource Relationships
With Metro Ethernet topology parameters inserted into the model, as illustrated previously in Figure 3, service to customer to resource relationships are established to achieve logical associations of performance information. The model holds relationships, as shown in Figure 4, between service provider edge devices (U-PEs, N-PEs), physical and virtual UNI to UNI connection components (ports, VLANs, VPLSs, Pseudowires, LSPs), traffic prioritization by QoS (DiffServ, ToS) and CoS (802.1p), customer edge devices (CEs), customer names and locations. Some of this information comes from the Service Configuration and Activation systems as change occurs and some of it is drawn from the environment itself during resource monitoring.
Probe set-up for end-to-end measurements as discussed earlier relies completely on this model to know which QoS classes to test through what interfaces using which equipment.
However, as not all devices support the creation of end-to-end probes, the model should be equipped to query all network devices and discover which of them do support this function.
Once the probes are in place, end-to-end measurements are associated with all the other aspects of the model: services, customers, sites, resources and QoS as represented in Figure 4. A structured service-centric approach to performance
management is fully realized when, based on the service model, network managers, service support personnel and account managers can move seamlessly from one type of information to another. As demonstrated in Figure 4, regardless of the entry point into the model, relevant workflow-based access (not any-to-any access) is possible. For example, starting in the top left corner of Figure 4 and moving clock-wise, customers have E-Line and E-LAN services with end-to-end KPIs that show the health of those services. The services are delivered to customer sites where their devices (switches) reside. The devices have physical and virtual interfaces that connect to specific provider devices (multi-service provider edge devices) and their specific interfaces. Those provider devices are mapped back to the end-to-end service level KPI measurements that traverse the core from edge-to-edge (PE to PE). Each interface is mapped to EVCs, LSPs and VLANs, each with their own Quality of Service utilization and performance levels. Each VLAN with its class of service performance is mapped back to the customers. With this interconnected relevance, an account executive can, for instance, confirm Metro Ethernet utilization levels for his customers by name, location or service, allowing proactive recommendation of upgrade before exceeding capacity and suffering poor performance.
Another important aspect here is the ability to "manage by exception" in relevant ways. Static, multi-level and dynamic threshold analysis, and the performance-based alerts they produce, will also fall within the structure of the model to determine who, how and where a problem lies. A simple process of elimination of performance alerts through services, customers, locations - groups and nested subgroups - can be
Figure 4: Points of Entry to Paths of Interconnection
Points of Entry
End-to-End KPIs Aggregated & Abstracted KPIs Devices Resource KPIs Ports Interfaces EVCs LSPs VLANs QoS Attributes Services Customers Sites Core Metro Edge
supported by the model. The result is an acute ability to understand dependencies and to prioritize action based on service criticality and business impact, as opposed to traditional first-come first-serve event management models. Beyond the operations and account management purposes of the model to deliver relevant actionable information
internally, customer-facing reporting1 brings value as well. Whether through premium performance reporting or
Managed Services offerings, those reports help customers gain insight into class-of-service loading, impending capacity shortages and provide them the rational for justifying service upgrades.
Conclusion
As more and more forms of communication are migrated to Enterprise and consumer networks (voice, video, databases, data storage, imagery, real-time applications) the demand for bandwidth is rapidly accelerating. Metro Ethernet offers the highest speed and lowest price per bit to date, making it a great opportunity to service providers and their customers. However, the dynamic, indeterminate nature of Metro Ethernet
necessitates continuous supervision. Performance Management with a service-centric and customer-centric focus is the only option to sustaining reliability amid constant changes to subscribership, customer usage, end to end connectivity paths and traffic engineering policies. Only Service-centric
Performance Management can relate Quality of Service from the perspective of the customer to performance from the perspective of the technology.
To protect the bottom line customer success and satisfaction -Metro Ethernet requires proactive monitoring and reporting that detects sudden changes in performance, service level
degradations, capacity utilization levels and their evolution, and impending violation of SLA objectives. A Metro Ethernet Performance Management service model that is automatically populated and updated with ongoing changes is the key to the 'top-down' and 'bottom-up' approach to Performance
Tel: +33 (0)1 64 86 79 00 Fax: +33 (0)1 64 86 79 79
North American Headquarters
InfoVista Corporation 12950 Worldgate Drive Suite 250 Herndon,VA 20170 USA Tel: +1 703 435 2435 Fax: +1 703 435 5122 Asia-Pacific Headquarters
InfoVista (Asia-Pacific) Pte Ltd Block 750 C,#03-16/17
