Академический Документы
Профессиональный Документы
Культура Документы
Foreword ........................................................................................................................................ 1
Chapter 1 Introduction............................................................................................................. 2
Chapter 2 Why Frame Relay? ................................................................................................. 3
Chapter 3 The Need for Management .................................................................................... 5
Chapter 4 Service-Level Agreements..................................................................................... 7
How Service Levels Are Measured ................................................................................................ 7
Components of a Service-Level Agreement .................................................................................. 9
Chapter 5 Enterprise-Wide Service-Level Management .................................................... 12
Network Instrumentation ............................................................................................................... 13
Connectivity Assurance ................................................................................................................ 15
Link Management Interface (LMI) Message Processing .....................................................................16
Diagnostics .........................................................................................................................................16
Loopback Testing................................................................................................................................17
User Interface .....................................................................................................................................17
Applications ................................................................................................................................... 32
Network Management................................................................................................................... 33
OpenLane Management Applications .................................................................................................34
NetScout Manager Plus ......................................................................................................................35
Glossary of Terms....................................................................................................................... 39
Calculations and Formulas........................................................................................................ 41
FDR and DDR ............................................................................................................................... 41
VCA, MTBSO and MTTR .............................................................................................................. 41
Network Latency ........................................................................................................................... 41
Foreword
Over the last five years frame relay has become the wide-area networking technology of choice
for most data applications and even today is still experiencing tremendous growth. What started
out as a fast packet alternative to X.25 for LAN-to-LAN connectivity has evolved into a
reliable, ubiquitous public networking service. The frame relay service providers have
established high performance standards, capable of supporting nearly any business application.
Today frame relay networks support critical applications including SNA, SAP , voice/fax/video
and a wide range of IP applications. Often these applications and protocols compete with each
other for bandwidth creating network performance issues that are difficult to diagnose. Network
managers who rely on public frame relay service are using a new management and diagnostic
tool, Service-Level Management systems, to ensure optimum network service and application
performance, even across public networks.
Service-Level Management of multi-protocol networks is required for businesses that rely on the
network to support the company. Even the growth of the Internet continues to fuel frame relay
growth as frame relay lines are used for Internet access, as well as support of both enterprise IP
and legacy applications. Frame relay services are now generally available nearly everywhere
around the world. Service providers trying to differentiate their frame services have responded
by offering various types and levels of Service-Level Management. But it remains the
responsibility of the IT manager to monitor, manage and troubleshoot the IT network
infrastructure. New Service-Level Management tools exist today to satisfy this requirement.
The Frame Relay Service-Level Management Sourcebook focuses on the issues of frame relay
service-level management specifically and as part of an overall enterprise-wide management
model. I would recommend this sourcebook to any network manager interested in knowing more
about frame relay management issues; typical service level agreements and how they are
structured; the SLA parameters and how they are measured; and some insight into how frame
relay Service-Level Management affects overall application performance management.
Chris Nicoll
Senior Analyst, Network Management and Carrier Infrastructure
Current Analysis, Inc.
Chapter 1 Introduction
This sourcebook is intended for network managers looking to either deploy new frame relay networks or better
manage the networks they currently have in place, and for service providers who are offering managed frame relay
networks. After reading this sourcebook, you should have a good understanding of frame relays benefits and realworld management challenges, along with the information you need to ask the right questions of frame relay
equipment vendors and service providers.
We begin by exploring issues associated with frame relay services and the need for effective Service-Level
Management on frame relay networks. We then examine a more comprehensive Service-Level Management model
that encompasses the entire enterprise (i.e., not just the WAN, but LAN resources as well).
FIGURE 1
For a more in-depth treatment of frame relay networking technology, we recommend reading one of the many
1
excellent textbooks on the subject. This sourcebook presents an overview of frame relay technology, with a specific
focus on Service-Level Agreements and Management. While the technology of frame relay has been around for quite
some time, the principles behind Service-Level Management are only now becoming widely understood.
With the proper understanding and planning, you can reap substantial benefits from frame relay, while at the same
time increase your overall network management capabilities.
The Guide to Frame Relay Networking, Christine A. Heckart, Flatiron Publishing, Inc., 1994; or The Guide to Frame Relay &
Fast Packet Networking, Nathan J. Muller and Robert P. Davidson, Telecom Library Inc., 1991.
2
FIGURE 2
Dedicated End-to-End Circuit Configuration
FIGURE 3
Virtual Circuit Configuration Using Frame Relay
Essentially, frame relay allows a distributed organization to build a virtual WAN using packet-switching technology
instead of dedicated end-to-end circuits, as demonstrated in Figures 2 and 3. Rather than implement a mesh of T1s or
leased-line circuits between each site, a network manager can use frame relay to build a hub-and-spoke network
between the different facilities, with the service providers frame relay cloud at the center. This design provides many
benefits:
Improved Flexibility
The virtual nature of frame relay offers much greater flexibility when business demands require changes to the
network architecture. Adding new sites to the network is a simple matter of connecting those sites to the service
providers network (as opposed to connecting them to all other sites through additional mesh wiring).
Furthermore, allocating additional bandwidth for specific sites is easier and faster than traditional dedicated
networks, since it requires only a modification to a single sites connection to the cloud, which probably can be
handled with a simple software change at the service providers network.
Performance on Demand
Frame relay has the unique capability of temporarily exceeding the allocated bandwidth between two sites. This
turbo mode lets you buy just the bandwidth you need for routine operations, allocating more bandwidth when
it is needed for large transfers. Equally important, this temporary allocation happens invisibly, according to
bandwidth-usage parameters defined when setting up the service. You define when you want it to happen, and
when those conditions are met, the network responds accordingly.
Migration to ATM
Many users and service providers are looking to migrate their core network infrastructures to ATM, allowing for
voice, video and data traffic to be sent across a single WAN infrastructure. With lower costs and wider
availability than ATM, frame relay is already becoming a common local-access technology for ATM-based
networks, allowing network managers to take advantage of the benefits of both technologies. With this
phenomena in motion, it is easy to see why many network professionals see frame relay as a logical stepping
stone to ATM.
Investment Protection
The frame relay migration began in earnest in 1994, and today it is the fastest-growing network servicebar
noneworldwide. The worldwide frame relay services market has grown from approximately $830 million in
1995 to $3.9 billion by the end of 1997. Looking ahead, we expect the market to top $10 billion by the year
2000. The number of frame relay ports is expected to grow from 123,000 in 1995 to more than 1.5 million in the
year 2000.
Chapter Summary:
Frame relay is fast. Network managers can connect every site directly, add or change sites at will, and
allocate additional bandwidth on an as-needed basis.
Frame relay costs less. Savings of 40 percent to 60 percent over comparable-speed leased-line services are
possible, along with lower costs of equipment and local access.
The frame relay market is healthy and growing, making it a safe choice for current and future
networking needs.
Bandwidth Requirements
Frame relay demands a much better understanding of the bandwidth requirements of the specific network
protocols and applications in use on your network. In addition, you also will need to make bandwidth decisions
according to these elements importance to your business objectives and their usage patterns (time of day, day of
week, quantities of time, etc.).
For example, you may wish to distribute reports electronically, but you may not want to replicate printer queues
across the entire enterprise network. With all of the options available in the various frame relay offerings, being
able to match your needs precisely to the proper type of service can make the difference between building an
effective network or not.
Connectivity Requirements
Just as you need to ensure that you will have a sufficient level of bandwidth across your wide-area network, you
also must allow for a sufficient level of connectivity at each of your installation sites. You may need to provide
for VCs between each of the secondary facilities in order to guarantee e-mail delivery times. Conversely, you
may be able to get by with VCs that only connect your field offices to a central office (or several primary
facilities, as the case may be). Frame relay allows for extraordinarily high levels of flexibility in design, including
inefficient or inappropriate ones.
In addition to these planning concerns, there are various management issues that must be addressed before the
network can be implemented. Since frame relay uses a packet-switched design instead of circuit-switched design, it is
much more difficult to monitor the entire network from top to bottom. Among these issues are:
For many organizations, frame relay represents a management challenge. On one hand, the economic benefits for
transporting both LAN and legacy application traffic are compelling and cannot be ignored. On the other hand,
building and managing an effective and efficient frame relay network can be complex.
However, products and solutions have recently emerged on the market that resolve this paradox, allowing the
migration to frame relay to be a straightforward and systematic procedure. These offerings also ease the burden of
network management, allowing for proactive monitoring and change.
Chapter Summary:
Frame relay migration can be difficult due to issues of trust in outsourcing, determining bandwidth
requirements, lack of physical-layer visibility, and lack of Layer 3 and application visibility.
New frame relay management products can help eliminate the best-guess nature of frame relay, thus
easing the transition and overall manageability of the network.
Data throughput
Network latency
Service availability
As one might expect, a high-level definition is not sufficient as a complete SLA. In order to effectively monitor and
adjust the network, network managers need much greater levels of detail. For example, how exactly is network
latency and throughput going to be measured? Which layer of the network will be monitored? Between which points
on the network? How is latency measuredround trip or one way? What size packets will be used to measure
latency? How often will the network be measured? The list goes on.
Most frame relay service providers today are providing various types of SLAs. Some premium services provide better
quality of service guarantees, custom reports and improved problem resolution/help desk functions. However, until a
standard SLA is agreed upon, and service providers implement the standards, the metrics and how SLAs are
measured will vary from service provider to service provider. Some network managers are working with their
providers to define the metrics of their SLA and the specifics of how, when and where these metrics will be
measured.
FIGURE 4
Very simply, there are two points where SLA measurements can be made: at the frame relay switch port or at the
customers site in customer premises equipment (CPE). Each option has different characteristics.
For service providers, implementing measurement at the switch port is ideal, since it allows for direct monitoring and
management of the physical equipment. Several frame relay switch vendors have built data collection capabilities
directly into their products, allowing for just this type of management. SLAs based on measurements made at the
frame relay switch typically include edge-to-edge measurement, as shown in Figure 4.
Recognizing that the local loop is often the source of problems, many users have insisted on obtaining end-to-end
measurements as the basis for their SLAs. To do this, a device must be located on the customers premises that can
collect the required information and send it back to a central Network Management System (NMS) on a periodic
basis.
Recently, a few DSU vendors have added data collection capabilities to their products just for this purpose. In North
America, the DSU is a natural place to integrate such functionality, since it historically has been the agreed-upon
demarcation point between the service provider and the user. In other parts of the world where NTUs are installed
and owned by the local access provider, a standalone probe may be required for the collection and communication
of SLA metrics. This is demonstrated below in Figure 5.
FIGURE 5
The Managed Demarc is the point at which the subscribers responsibility ends and the service providers
responsibility begins. However, in Figure 6 below, we show two points of demarcation: one for the local loop
provider (the incumbent LEC or PTT), and one for the frame relay service provider. In reality, these points may be in
the same physical unit (such as a DSU) or may alternately take the form of two distinct systems (such as an NTU and
a probe).
SLAs defined in terms of end-to-end responsibility typically include the local loop as well as the core frame relay
switching system. Most frame relay service providers will take responsibility for end-to-end management as long as
you are using their equipment. Other service providers may not be so inclined.
FIGURE 6
Network Latency
Network latency, sometimes called Frame Transfer Delay (FTD), is a measure of the time it takes for packets to
traverse the network, from end to end or from edge to edge. Since latency is a function of the amount of time it
takes for a packet to be completely received, this measurement can be affected by the size of the packets in use.
For this reason, some SLAs will stipulate packet size when specifying latency guarantees.
Service Availability
It is also important to measure the overall up-time and availability of the frame relay service, including any and all
outages that interrupt traffic moving through the network. Three such measurements are Virtual Circuit
Availability (VCA), Mean Time Between Service Outages (MTBSO) and Mean Time to Repair (MTTR). These
measurements should be made on each VC on the network. See VCA, MTBSO and MTTR in the Calculations
and Formulas section for information on how to calculate these values.
Exclusions
Besides looking at overall performance, SLAs may include allowances for any predefined conditions that would
require an adjustment in the performance calculations. There are several valid reasons for service being
unavailable, and these exclusions must be defined in the SLA. For example, a loose cable on a customer-owned
router should be excluded in the SLA, although the same problem on a provider-owned piece of equipment
should be covered.
Other commonly cited exclusions are:
Problem Resolution
Besides defining what a problem looks like, it is also crucial to fully define the terms, conditions and procedures
for resolving problems. For example, network managers may want to specify a shorter resolution time for
problems affecting the full trunk or port than those affecting just one virtual connection, since a full trunk/line
outage at a primary site could shut down the entire companys network. Meanwhile, a service provider will want
to specify that the network manager will have personnel available to assist the service provider in gaining
physical access to the CPE equipment.
Furthermore, it is important that the equipment used to track the SLA be capable of collecting and displaying
information to make it clear as to whether or not a particular failure is excluded. This is not the time for fuzzy
agreements and vague statements about some type of outage. Where, when, why and how long are questions that
can be answered with the right type of systems in place.
A Note on Averages
Some SLA covenants revolve around averages. For example, a statement may be included in the SLA that states
that the average latency across all VCs will be less than or equal to some number, say 60 milliseconds (ms).
While the use of averages may appear to be valid, this approach can mask certain issues.
For example, say that 90 VCs out of 100 are averaging 40-ms latency, and that the remaining 10 VCs have
average latencies of 80 ms. The average latency across all 100 circuits is 44 mswell within the target range.
Yet, this hides the fact that 10 links are performing so poorly that they are likely to affect latency-sensitive
applications. For this reason, broad averages should be avoided, with SLAs focusing instead on minimum
requirements. This approach will best serve the needs of the user and will ensure proper operation of the
applications across all links in the network.
Service-Level Reporting
Each of the measurements listed above can be tracked for every VC on a frame relay cloud, with each VC being
tracked for one or more SLA parameters. With a medium-sized network of 200 VCs, this can be an
overwhelming amount of information to sift through.
Therefore, there is a need for consolidated statements of network operation, as well as detailed reports showing
specific failures. At the highest level, the subscriber is interested in getting a thumbs up or a thumbs down
showing whether or not the network performed according to the guaranteed levels. Figure 7 below shows a
sample report summarizing service-level data over a monthly period.
10
FIGURE 7
Most service providers offer a basic SLA or at least a simple verification service. These agreements are usually
based on monthly averages of data throughput, latency and availability, and they offer some type of guarantee with
limited penalties for non-conformance.
In an effort to try to differentiate themselves, some providers are starting to offer premium SLAs that include Webbased reporting with expanded performance measurements and contractual guarantees. These premium services
typically are more expensive than the basic offering, but can be well worth the additional costs if network managers
consider the proactive management abilities that are gained in return.
Chapter Summary:
Service level agreements are contractual agreements between a service user and a service provider.
SLAs can also include clauses for predefined exceptions, averages, and minimum levels-of-service.
11
Increasingly, business managers are realizing that networks are the hearts of their enterprises, with business relying on
applications being alive and well all of the time. In the end, performance of critical business applications is the only
important measure of the network. If applications are not performing to expectations, the business is exposed. We
refer to this as the Service-Level Management (SLM) challenge.
What events can impact the day-to-day operation of applications? Just about anything. A few common examples of
these events are:
As you can see, many events can cause applications to perform poorly across a WAN, only some of which are related
to the frame relay service directly. While performance and availability of the frame relay network should be key
concerns, they are not the only aspects that should be on the minds of network managers. Therefore, network
managers must implement measurement services across their entire networks in order to truly measure application
performance.
In addition, the network manager should care about how the entire enterprise network is being impacted by these
other elements, since the root cause may very well be related to some other issue. Without the necessary tools to
evaluate parameters associated with the network service and the behavior of applications, problems may never be
fully understood.
Today, various service providers are now offering managed LAN or Router services as well as managed WAN
services. As part of these comprehensive out-tasking services a view of the overall application and network flow
performance is also essential. In Figure 8 below, we present a comprehensive model identifying the building blocks of
a well-designed Enterprise-Wide Service-Level Management model.
12
FIGURE 8
Service-Level Management Model
The Service-Level Management model serves as a tool that can be used effectively within an organization as well as
between a customer and a service provider. The models goal is to provide these personnel with the problemreporting and analysis services needed in order to better manage their overall enterprise network.
Three distinct levels of management are contained within the Service-Level Management Model: connectivity,
network services and application performance. Network services can be broken down further into Service-Level
Verification and Service-Level Analysis.
Network Instrumentation
Before we explore this model in greater depth, it is useful to understand network instrumentation. At a minimum, we
need to deploy data collection and control devices at the edge of the WAN service, and preferably across the LAN as
well.
We refer to these devices as remote monitoring (RMON) agents. For the WAN these typically take the form of a
DSU with embedded RMON agent or a RMON WAN probe. Additionally, we may also want to instrument selected
LAN segments at various locations across the enterprise with RMON LAN probes. An example of this is shown in
Figure 9 below.
FIGURE 9
13
Lets consider the issue of how DSUs with RMON agents communicate in a frame relay network. Each agent needs
to establish communications with other agents as well as with the Network Management System (NMS). This is
demonstrated below in Figure 10.
FIGURE 10
While it seems elementary, interconnection of agents across the WAN is in itself not trivial. Two methods of
management connectivity are demonstrated in Figure 11. In the first (router-based) method, the source DSU is
interconnected with the router via a LAN or serial connection. The router combines this information with user data
and transmits the information across the network on a single Permanent Virtual Circuit (PVC). While straightforward, this implementation suffers one important drawback: The router is in the communication path between
DSUs.
FIGURE 11
14
FIGURE 12
There are two advantages to this method:
The path of RMON management data is guaranteed to be identical to that of the users PVC. This comes in
handy when it comes time to run diagnostic tests or to measure latency.
Connectivity Assurance
Several elements contribute to the goal of effectively monitoring and managing overall connectivity assurance. These
include:
Each area provides critical functionality required to effectively measure overall connectivity and network availability.
15
FIGURE 13
Generally speaking, the LMI Terminate/Regenerate model is more effective for network management purposes. First
and foremost, by terminating the signal at the DSU, a known entity and configuration can be tested independent of
the router or other downstream equipment. Since most network failures are a result of misconfigured user equipment,
there is a major incentive on the part of service providers to implement this model. Network managers should not
mind this model either, since additional management agents can be installed on the router specifically, thus providing
multiple levels of network management and reporting.
Diagnostics
Robust diagnostics are a fundamental component of any well-designed network management system. A good
diagnostic system can collect information at multiple layers of the OSI stack and can report this information to the
network management staff on a timely basis. Some examples of the data that should be collected and made available
by the RMON agents for diagnostic purposes are:
16
Physical-layer statistics
Frame Relay link statistics
Frame Relay PVC statistics
LMI statistics
Loopback Testing
Another key ingredient of any management system is the ability to execute a loopback test, where test patterns are
transmitted to a destination system and are immediately echoed back to the original sender. When the information is
received, the data can be examined to determine if any corruption or sequencing problems have occurred.
Loopback tests are possible at Layer 1 and Layer 2, providing testing capabilities for both the physical and data-link
layers of the network. It should be pointed out that in a frame relay network environment Layer 1 testing only works
for the local loop between the DSU at a customer location and the service providers point-of-presence. Furthermore,
Layer 1 loopback testing is disruptive, preventing any use of the circuit during testing. It is also time consuming in
that it can be done only by the local exchange carrier, and should be considered only as a last resort for testing
physical connectivity.
However, since frame relay provides a consistent Layer 2 interface across the entire WANregardless of the
underlying mediumit is also possible to conduct non-disruptive loopback tests at that layer. Specifically, DSUs
supporting dedicated management circuits can use this technique to transparently test connectivity between devices
without impacting normal traffic.
User Interface
Installation, configuration, software downloading, out-of-band access services, diagnostics and loopback testing
services are difficult procedures for many personnel to easily grasp. Making these procedures easy is, therefore, an
essential part of effective network monitoring and management.
For example, a user should be able to visually ascertain the status of the network at any time, as shown in Figure 14
below. In this example, one sites network has gone offline, as indicated by a red icon.
FIGURE 14
17
By clicking on the failed network icon, a graphical representation of the DSU can then be presented to the network
manager, as shown in Figure 15 below.
FIGURE 15
As you can see, the devices per-port status information should be readily visible. In addition, a variety of options for
reconfiguring, resetting or testing the device should be allowed.
Verification products do what the name says: They store information about the network and provide reports that
show whether or not the service provider is meeting the terms defined in the SLA.
Meanwhile, analysis tools go beyond basic verification services, providing network managers and service providers
with the information required to fine-tune the network for optimal performance. In this regard, they help to ensure
that the SLA is never needed, since the network always performs better than expected.
Network Service-Level Verification
Service-Level Management systems (including RMON agents and NMS systems) provide a set of tools for
calculating whether or not the service provider is meeting the terms of the SLA. Specifically, factors such as latency,
throughput and availability should be measured and reported.
18
Network Throughput
Network throughput is measured in terms of Data Delivery Ratio (DDR) or Frame Delivery Ratio (FDR), as
described in Chapter 4, Components of a Service-Level Agreement. One technique for measuring DDR or
FDR is to have each DSU periodically send management packets containing frame and octet counts to a central
network management system, allowing the network manager to measure the number of octets and frames that
were sent and received over a known time frame.
Network Latency
Network latency is measured in terms of the amount of time it takes to send a complete packet from one
endpoint to another. Typically, this is done using a simple Layer 2 loopback test, as described in Chapter 5,
Loopback Testing.
In order to guarantee that the path of the test packet exactly parallels the service users VC, the test packet
should be transmitted across the VC being tested and not through a specific management circuit. For details on
how to calculate latency, refer to Network Latency in the Calculations and Formulas section.
Testing Frequency
An SLA should contain a definition of the frequency at which throughput and latency measurements are taken,
although this number should be decided carefully. Samples probably should not be taken every few seconds, as
they will end up consuming significant amounts of valuable bandwidth, and actually may trigger performance
degradation problems during periods of network congestion. Conversely, if samples are only taken every few
minutes, there may not be enough data to identify problem scenarios accurately until after the fact. One or two
samples per minute will probably be sufficient for most users.
Reporting Characteristics
Once data has been collected, it needs to be processed and distributed to the appropriate network management
personnel. Depending on the size and complexity of the network in question, this could happen as often as once a
day, or as infrequently as once a month. The SLM systems also should provide detailed reports that summarize
the overall network performance, while showing where problems occurred, if any. An example from Paradynes
SLV Reporter package is shown in Figure 16 below.
SLV Reporter
Report #16m
Delivery
Above CIR
99.035%
Rate
Total
99.517%
Avg Latency
34.5
Availability
99.995%
FIGURE 16
19
Historical analysis provides insight into how well the network operates, and it should give some indication as to
whether or not certain VCs are over- or under-subscribed. Meanwhile, what-if scenarios offer the opportunity to plan
for availability in case of disaster or unplanned usage spikes. Both areas are critical in order to plan ahead effectively,
ensuring that problems dont crop up.
Historical Analysis
In Figure 17 below, a report is presented that shows network capacity and throughput by day of week. Using this
type of information, a network manager cannot only measure the overall availability of his or her network
resources, but can also fine tune the network.
SLV Reporter
Report #4w
Name/Location
Chi/Atl
Port Speed
(Kbps)
384
Chi/Clev
768
512
Weekly
Summary
Sunday
Monday
Tuesday
Wednesday
Thursday
Friday
Saturday
%Util
12%
67%
63%
71%
65%
63%
21%
66%
Mbits
3,981.3
22,229.0
20,901.9
23,556.1
21,565.4
20,901.9
6,967.3
109,154.3
Tuesday
Wednesday
Thursday
Friday
Sunday
Sunday
Chi/Balt
Monday
%Util
8%
59%
61%
67%
62%
66%
15%
63%
Mbits
5,308.4
39,149.6
40,476.7
44,458.0
41,140.2
43,794.4
9,953.3
209,018.9
Monday
Sunday
Monday
Tuesday
Wednesday
Thursday
Friday
%Util
7%
71%
65%
63%
62%
66%
17%
65%
Mbits
3,096.6
31,408.1
28,753.9
27,869.2
27,426.8
29,196.3
7,520.3
144,654.3
Sunday
Monday
Tuesday
Wednesday
Thursday
Friday
Tuesday
FIGURE 17
Burst Analysis
Another important capability here is conducting burst analysis to see how the network responds to temporary
over-subscription requests. Does latency go up? Are packets thrown away? Or can a burst be absorbed by the
network without issue? The Service Level Management solution you choose for your network should be able to
display these bursts in a variety of ways, as illustrated in Figure 18 below.
FIGURE 18
20
What-If Scenarios
From time to time, it may also be desirable to run network tests that stress the network beyond its design,
showing how well it performs (or doesnt perform) under load. For example, what would happen to a branch site
if an additional 64 Kbps of traffic were added to its connection? Would other applications slow down? Would
more bandwidth need to be purchased?
Some RMON probes can generate load patterns that simulate almost any type of data, allowing these kinds of
tests to be conducted easily. Make sure that the SLM you use can track the results of these tests cleanly.
21
For example, Application Performance Assurance can be useful when trying to determine how well the frame relay
network will respond to changes in the types of traffic being carried. If a network manager wanted to know how the
network would respond if SNA traffic were migrated onto the frame relay network, Application Performance
Assurance tools should be able to identify this. These services also can be useful for building predictive models that
show how migrating one specific application (such as a server-based e-mail system) to newer, more-efficient ones
(such as SMTP and POP/IMAP) would affect the network.
While hypothetical, these scenarios illustrate the advantages of having the ability to examine network-, transport-,
protocol- and application-level (Layers 3-7) traffic patterns across the entire enterprise network. Not only is the
network manager interested in how the changes in traffic will affect the frame relay networks utilization levels, but
also how the changes will affect the applications, hosts and users. Gaining access to this level of visibility is what
Application Performance Assurance testing and reporting is all about.
Some of the elements required for effective monitoring and management at these higher layers include:
Each filter provides different types of views into the network activity patterns. They are all required to effectively
manage not just the frame relay network, but the entire enterprise (WAN and LAN).
Protocol and Application Utilization
In order to effectively analyze and plan for major changes to the network, network managers must be able to track
the protocols in use on the network and display their consumption rates. This is the only way to know how much
bandwidth a set of protocols and the related applications are consuming.
For example, protocol utilization and distribution statistics may indicate that Web traffic across the frame relay
network is consuming a significant amount of bandwidth and preventing SNA traffic from getting through on a timely
basis. Another example may be that NetWare Service Advertisement Protocol (SAP) updates are consuming an
inordinate amount of bandwidth, preventing file transfers from completing.
Using this information, a network manager could choose to adjust the frame relay network, allowing for the traffic to
flow smoothly, or he or she could establish filters at the WAN routers that reduce or eliminate these types of traffic.
The point is that protocol- and application-level utilization measurements are required in order for the network
manager to prevent application-layer failures. This is illustrated in Figure 19 below.
FIGURE 19
22
In addition to measuring protocol and application traffic at a broad level, an SLM solution also should allow the
network manager to view these statistics on a per-DSU basis. In addition, the SLM should be able to query each
RMON agent individually for detailed information, allowing the agents to locate specific utilization issues on a perport basis easily.
Host and User Utilization
Not all network congestion problems are related to a specific protocol or application, although it may seem that way
from a cursory look at the network traffic. In reality, the problem may be that a particular user or host is misusing the
network resources, generating more traffic than expected.
Since RMON tools can provide information at all layers, it is possible to track network usage all the way down to the
per-node layer, as shown in Figure 20 below. Using this information, you can see exactly what the source of your
utilization issues are, and either adjust your bandwidth or router filters appropriately.
FIGURE 20
Host-specific monitoring also can expose excessive user activity. For example, if a user is downloading a large file off
the Internetor even from something like an internal database systemit is possible to track the excess utilization
down to the specific PC in question, showing the specific times that the problem occurred. It is then a simple matter
of locating the user and adjusting the behavior appropriately.
Time-Based Utilization
Sometimes excess traffic is a function of business, and in these situations the traffic cannot be filtered out at the
router. One example of this might be an order-entry system that submits new orders to manufacturing and billing
systems in different parts of the company. In this scenario, a network manager would want to make sure that plenty
of bandwidth was available for the transfers to complete successfully.
These business-specific utilization issues typically occur at known times. In the example above, the order-entry
systems may conduct their batch transfers at 11 p.m. every weeknight. In another example, a payroll system may send
data to an outside agency every second Wednesday.
By using the information available at the protocol, application and host levels, a network manager can be sure to
allocate sufficient amounts of bandwidth for the large transfers to complete successfully.
23
24
Reporting
Once RMON data has been collected by the NMS, it needs to be consolidated and reported in a format that is
useful to the network management personnel. In many cases, this data will come from hundreds or even
thousands of endpoints, thus requiring highly scalable NMS systems.
Typically, an RMON vendor also will sell an NMS system that leverages specific aspects of its agent services.
Additionally, many third-party NMS applications with excellent reporting capabilities exist in the marketplace,
such as Concord Systems and Kaspia. Concord, in particular, is noted for its scalability and has been selected by
many service providers for this reason. RMON agents that are designed around industry-standard MIBs and that
support RMON v1 and v2, should work well with these third-party systems.
Chapter Summary:
Enterprise-Wide Service-Level Management consists of connectivity assurance, network service-level
verification, network service-level analysis and application performance assurance.
Measurements need to be taken across the entire enterprise network, and not just as they apply to the
frame relay network in particular, since outside factors can negatively affect a WAN more severely than
issues with the WAN itself.
Service-Level Management involves all layers of the protocol stack, from the physical layer to the
application layer, and includes LAN and WAN resources alike.
25
The need for Service-Level Agreements (SLAs) to guarantee network availability and performance
The need for management at the enterprise level, including protocols, applications and users across the enterprise
network, and how these issues affect frame relay performance
These issues are all important aspects of any enterprise networkand frame relay is no exception. Indeed, due to the
outsourced nature of the technology, effective and proactive management is more important than with any other
WAN technology. However, this does not mean that you should avoid frame relay networks. Instead, you should
view this as an opportunity to dramatically increase management activity while simultaneously reducing costs.
In order to do this, you must consider the importance of an overall SLM solution. Such a system should provide you
with a set of tools, services and reports that offers a deep level of detail about the kinds of traffic in use on your
network. This in turn will help you to:
Get the network in service, keep it in service, and return it to service in the event of failure
Help you to adjust the network, infrastructure or SLA to optimize the overall network performance and
utilization
26
SNMP specifies five primitives (commands and responses) that can be used by the management station or managed
devices. These are:
27
Probes containing agents are placed on network segments and are capable of monitoring a variety of interfaces.
Examples of agents are Ethernet agents, Token Ring agents, frame relay agents and ATM agents.
28
Product Overview
FrameSaver SLV (Service Level Verifier) is the latest addition to Paradynes FrameSaver family of frame relay access
products. FrameSaver SLV combines Paradyne's award-winning frame aware diagnostics and QoS features with
NetScout's market leading probe technology to deliver the industry's most powerful frame relay management offering.
FrameSaver SLV incorporates RMON agent technology licensed from NetScout including: IP top talkers, protocol
distribution, plus data collection and monitoring in a RMON 2 standard format. This extends FrameSaver SLV's
monitoring capability beyond the frame relay network layer (Layer 2) to incorporate Layer 3 which identifies the
protocols and users that are impacting the frame relay network performance.
Each FrameSaver SLV collects and stores physical, frame and networking protocol (Layer 1, 2, and 3) statistics in
RMON 2 buckets for periodic retrieval on a network-wide basis. These statistics can also be accessed in real time
to help troubleshoot and "drill down" on specific network problems. In addition, various thresholds can be set in each
FrameSaver SLV to alarm on specific network conditions. For example, when a Service Level Agreement parameter
such as network latency or throughput at a particular location is, or is about to be, exceeded. Other solutions on the
market monitor network statistics but don't provide the rich set of diagnostic, test, and optimization features found in
the FrameSaver family. An entirely new set of Intelligent Service Level Verification features have been developed that
can accurately analyze instantaneous burst and dropped packets that typically are "masked" by the conventional
averaging techniques found in competing solutions. Continuous latency testing rounds out the SLV performance
improvements.
FrameSaver SLV incorporates a robust set of Service-Level Management features targeted specifically at
Connectivity Assurance, Service Level Verification and Analysis, and Application Performance Assurance. These
features include non-disruptive PVC loopbacks, router independent management connectivity, and a comprehensive
set of performance monitoring graphs to facilitate troubleshooting. Users can rapidly pinpoint the source of trouble
indicated by the monitoring tools and dispatch or even affect the appropriate fix remotely. This emphasis on rapid
Return To Service results in proactive service level analysis/verification and improved network availability.
FrameSaver SLV systems include OpenLane and NetScout management applications and may, if the application
warrants, include standalone NetScout probes. Together these three components (DSUs, NMS applications and
standalone probes) provide you with the ultimate flexibility in meeting your customers current or future
requirements.
Benefits
29
Features
Frame Relay aware management including:
-
Benefits
Allows you to communicate to your remote unit
without having to depend on the Router. Eliminates the
need to purchase special PVCs, cables, LAN adapters
or router ports. Return-to-service connectivity
assurance tools identify the cause of network problems
quickly and minimize downtime.
Components
The FrameSaver SLV family includes three components; Frame Aware DSUs, NetScout probes and OpenLane
management applications. While it is expected that every installation will include numerous access units and an
OpenLane management system, a limited number will also require standalone probes. Following is a brief description
of the FrameSaver SLV components.
Frame Aware DSUs
Two Frame Aware DSUs are available: the FrameSaver SLV 9624 for 56/64K applications and the 9124 for T1/FT1
applications. Each combines Paradynes industry leading DSU technology and patented frame relay management
capabilities with RMON agent-based performance monitoring from NetScout to deliver the industrys best frame
relay access product. They provide network service providers and end-user customers a comprehensive set of tools
designed to monitor and ensure frame relay network service levels.
FrameSaver SLVs intelligent verification features proactively monitor key service parameters and collect the detailed
information required to accurately monitor service levels as well as to identify the cause of missed agreements. They
include extensive RMON-based performance monitoring capabilities that capture Layer 1, 2, and 3 statistics required
30
to monitor network utilization, identify problems, optimize performance and perform long-term planning. Statistics
are stored in RMON 2 User History buckets for periodic collection and are also accessible in real time to help
troubleshoot and drill down on specific network problems. In addition, thresholds can be set to proactively monitor
and alarm on specific conditions such as over or under utilization or excessive network latency. This, combined with
physical and logical PVC-based management and router independent SNMP connectivity rapidly pinpoints the
source of trouble maximizing network availability.
FIGURE 21
FrameSaver SLV 9624
The FrameSaver SLV 9624 is a single-port (native V.35) 56/64K DSU that is optimized for frame relay access. With
support for up to three PVCs, it is ideal for small branch locations.
FIGURE 22
FrameSaver SLV 9124
The FrameSaver SLV 9124 is a frame relay optimized T1/FT1 DSU/CSU that has one data port (native V.35) and a
DSX-1 drop and insert port for voice traffic. The PVC capacity is up to 64 (making this an ideal product for branch
and small-to-medium sized regional/central sites.
OpenLane Management
Like all Paradyne SNMP-managed devices, the OpenLane DCE Manager and Performance Wizard manage
FrameSaver SLV. In addition, NetScout Manager Plus application software will be used as part of the OpenLane
management solution to manage FrameSaver SLV components. Specifically, NetScout Manager Plus is used to
manage the Layer 3 capabilities (Top talkers, Protocol distribution and RMON storage buckets). NetScout Manager
Plus is also used to manage standalone NetScout probes that are provided as part of the FrameSaver solution.
31
NetScout Probes
Selected NetScout WAN and LAN/WAN probes are available for resale through Paradyne to meet specialized
monitoring and diagnostic requirements that cannot be satisfied by FrameSaver access units alone. NetScout probes
continuously monitor up to Layer 7 on network LANs and/or WANs to gather data on traffic protocols, applications
and users. They provide the end-to-end monitoring to simplify troubleshooting and capacity planning. NetScout
probes not only monitor network traffic, but can also be customized to monitor an application regardless of its
topology or protocol.
FIGURE 23
LAN / WAN Probes
Applications
FrameSaver SLV has been specifically designed for frame relay access. In a typical application, FrameSaver SLV
access units are installed at each location. This will provide network service level verification/analysis, protocol
performance monitoring and connectivity assurance for every physical and logical (PVC) circuit in the network. This
will meet the needs of the majority of customers and is ideal for star and mesh network topologies.
FIGURE 24
FrameSaver SLV Application
32
End-to-end enterprise wide Application Performance Assurance requires a higher level of monitoring than that
provided by the FrameSaver SLV access units. To meet this need, a NetScout probe may be installed in conjunction
with the FrameSaver device at one or more locations. The FrameSaver SLV devices provide Layers 1, 2, and 3
monitoring, plus physical and logical PVC monitoring and connectivity assurance (e.g., initiating alarms on loss of a
circuit or PVC), Intelligent Verification and Frame Relay Aware diagnostics. The NetScout probe will provide full
Layer 7 application performance assurance monitoring of either the WAN segment or both the WAN and LAN. In
addition, a probe will provide advanced packet capture and decode capabilities and has greater storage capacity. For
example, a FrameSaver SLV access unit can monitor up to seven protocols and six IP top talkers at one time, while a
standalone probe can monitor an unlimited number making it a viable addition for large specialized situations. This
application is ideally suited for star network topologies that will only require a limited number of probes at regional or
central sites.
FIGURE 25
FrameSaver SLV Plus NetScout Probe Application
Network Management
The FrameSaver SLV access units include the following levels of management:
SNMP Management
Because of their advanced diagnostics and RMON features, FrameSaver SLV devices will typically be
manageable by an SNMP NMS. Adherence to standards such as SNMP and RMON not only allows the
customer to take advantage of Paradyne OpenLane applications, but also to leverage investments they have made
in other standards-based applications, such as, Concord Network Health. The FrameSaver products support
multiple SNMP community strings and multiple authorized managers, allowing the most flexible NMS solution
available today. For example, an NSP can monitor and manage a complete FrameSaver network while
individual ISPs could monitor and manage only their portion of the network.
33
Device Display
Provides a real-time graphical representation of the device. The display presents color-coded icons that identify
the operational and administrative status of all interface ports (e.g., interface is up, down, in test, etc.) This
display also serves as a primary interface for all DCE Manager functionality.
Device Identity
Reports general information such as name, description, model number, serial number, release levels, up time,
contact and location. Some information can also be changed or set from this display.
Status
Device status commands display operational status of the device and its interfaces. Port status displays detailed
alarm, test and operating status for a selected interface.
Diagnostics
A set of intuitive graphical commands used to initiate loopback, test patterns, and monitor the results.
Options
Displays the current configuration of a device or interface. Device and interface options can also be changed or
set from this display.
Help-On-Line
Context-sensitive help for all DCE Manager functions.
The OpenLane Performance Wizard adds real-time and historical performance reports for the FrameSaver product
line. These tools provide data collection and reporting enabling a customer to proactively and reactively monitor,
analyze, and troubleshoot their network. With these tools the user has the ability to verify the quality and the level of
service being provided, as well as monitor bandwidth utilization details. FrameSaver SLV displays include:
34
PVC Performance
DLCI Throughput of local and remote devices in relation to CIR showing data transmission and receive
rates
Frames sent within, and above CIR, frames sent with DE set, FECNs, BECNs, and congested seconds
Compression Efficiency and Throughput
PVC Data Delivery Analysis
Transmit Bit Burst Analysis
Round-trip network latency
Frames transmitted and received, and frames discarded by the network
Frame size distribution
Paradyne offers the NetScout management suite to provide all RMON-based monitoring for the FrameSaver SLV
access units and the NetScout probes. With the NetScout Manager a customer has the ability to retrieve the Data
Link and Network layer (OSI Layers 2 and 3) statistics from a FrameSaver SLV. Additionally, a customer will have
the ability to retrieve the historical performance data stored in the user history buckets and listen for threshold
crossing alarms from the FrameSaver SLV products. The NetScout management suite also provides complete
monitoring for the NetScout probes.
Chapter Summary:
Paradynes FrameSaver SLV Service Level Management solution allows companies to build and manage data
networks based on public network services like frame relay, while maintaining the same operational efficiency
and confidence used in the management of private networks. By deploying the FrameSaver SLV solution you
can now move mission-critical applications to shared public networks, without losing control over the
network. Paradyne is leading the way in frame network service-level management with offerings like
FrameSaver SLV (Service Level Verifier).
Visit our Frame Relay Website www.paradyne.com/framesaver-minisite for all the information you need to
understand how to implement this premium WAN Service-Level Management system.
35
Technology Innovations
Paradynes technology portfolio boasts more than 133 patents50 that have been issued in the past six years.
Gaining recognition with every new product introduction, Paradyne continues to invest in its future with extensive
research and development programs. Time and time again, new product introductions have provided Paradyne
customers with advantages and benefits never dreamed of a few years earlier. In just one generation, Paradyne has
launched numerous industry firsts.
And, in each instance, Paradyne customers won a substantial advantage in manageable growth, flexible configurations
and long systems life. In the modem market, here are just a few industry firsts:
36
Paradynes FrameSaver family is the industrys first frame relay access system that provides IS managers with the
tools to diagnose and fix network performance problems. Winner of the Data Communications Hot New Product
Award for January 1998, FrameSaver allows IS managers to control costs, optimize performance and manage their
frame relay networks with the same confidence and control they had previously with more costly, leased-line
networks. The FrameSaver family includes a series of 56/64 Kbps and T1/FT1 frame relay endpoint access devices
coupled with a sophisticated suite of network management applications that identify, locate and fix frame relay
network problemsin real time.
Paradynes new FrameSaver Service-Level Verifier (SLV) System offers the industrys best performance
management, network diagnostics and optimization. This collaborative offering from Paradyne and NetScout Systems
introduces RMON-based probing capabilities through Layer 3, which includes Internet Protocol (IP) top talkers,
protocol distribution and RMON 2 user history to the already robust diagnostics available in FrameSaver. Paradynes
router-independent FrameSaver SLV allows customers to get the network in service faster, manage the service better
and return to service quicker in the event of an outage.
Hotwire DSL/MVL Firsts
Paradyne is also revolutionizing the data communications industry with its high-speed network access Hotwire
products, consisting of commercial-grade RADSL (Rate Adaptive DSL), HDSL, SDSL and MSDSL solutions, and
the recently announced residential/SOHO branch-office MVL System. Paradynes commercial Hotwire firsts
include:
The industrys first SDSL PC card, offering full-duplex, 384 Kbps symmetric services to support trials of
advanced multimedia services, including videoconferencing, high-speed Internet access and remote LAN access
The industrys first 1.5-2 Mbps Asymmetric Digital Subscriber Line (ADSL) modems in the form of a PC card
Shipment of the industrys first commercial RADSL system based on CAP technology
The industrys first stackable Digital Subscriber Line Access Mux (DSLAM)the Hotwire 8600 multiservices
DSLAM and the Hotwire 8800 multiservices DSLAM which support IP, frame relay and channelized T1/E1
services on a single access platform
The most comprehensive, cost-effective array of DSLAMs and DSL endpoints in the industry
The industrys first commercial deployments of high-speed RADSL-based services
37
Paradynes Hotwire MVL System is the newest member of the Hotwire family of products. Hotwire MVL System
firsts include:
Elimination of the costly dispatch of service technicians due to innovative plug-and-play design
Low heat dissipation, which results in the industrys highest port density2,000 portswithin the Central Office
(CO), delivering the industrys lowest cost
First residential/SOHO solution supporting Multiple Simultaneous Access from one to eight devices operating on
a single copper phone pair concurrently
First solution delivering peer-to-peer print and file-sharing capability between devices and users within a
residential/SOHO environment
First residential/SOHO solution operating within the ISDN/T1.413 spectral requirement
First residential/SOHO solution that allocates bandwidth dynamically to support multiple, independent
applications
First solution based on MVL to support multiple services over one local-access network connection
First to achieve reliable operation at 768 Kbps downstream and upstream over CSA and RRD loopsover 18
Kft.
Unprecedented distancemore than 24 Kft on 24 AWG, 33 percent more than ADSL.
In 1992, Paradyne pioneered GlobeSpan technology, the leading industry source of digital subscriber line (DSL)
technology. On August 20, 1996, GlobeSpan Technologies Inc. announced its launch as a separate technology
licensing business, emerging from the sale of AT&T Paradyne by Lucent Technologies announced on July 31, 1996.
Paradyne also develops technology for wireless services. Enhanced Throughput Cellular (ETC) is an advanced data
protocol for transmission and error-correction in wireless media. ETC2 Quick Connect cellular data protocol offers
faster connection time than any competing technology by enabling one-second connection time for mobile workers
making cellular data calls.
If you would like more information, please feel free to contact us at 1-800-PARADYNE or 727-530-8623, or check
our WebsitePower Pagesat www.paradyne.com.
38
Glossary of Terms
The following glossary of terms relates to how these terms are used in this sourcebook. Please note that these terms
may also have other definitions.
ATM
Asynchronous Transfer Mode. Today, most frame relay networks are based on some
form of ATM switching and transport inside the service providers network to transport
frame relay packets.
CIR
Committed Information Rate. Used when ordering a frame relay Virtual Circuit. Packets
transmitted into the frame relay network above CIR become discard-eligible and may be
discarded by the service provider. Packets transmitted below the CIR should not be
discard-eligible.
CPE
Demarc
The point between the telephone company communications facilities and the terminal
equipment, DSU/CSU protective apparatus or wiring at a subscribers premises.
DLCI
Data-Link Connection Identifier. Used to indicate a frame relay port connection to and
from a frame relay network. DLCIs are associated with Virtual Circuits as a pair of
DLCIs (one at either end) mapped across a frame relay network become a VC.
DSU
Digital Service Unit. Used to terminate a digital WAN service. For frame relay service,
DSUs range in speed from 56 Kbps to T3 (51 Mbps).
FDR/DDR
Frame Delivery Ratio/Data Delivery Ratio. The two most common metrics used to
measure data throughput.
Frame-Aware DSU
A DSU with a specific set diagnostic, monitoring and test features designed for use in
frame relay networks. In an enhanced frame relay SLA service the frame aware DSU is
bundled with the service and becomes a Managed Demarc.
LAN
Latency
One of three basic Service-Level Agreement parameters that refers to the time it takes for
a packet to travel across a frame relay network.
LMI
Local Management Interface. A specification for the use in frame relay networking that
defines a method of exchanging status information between FR network ports and
customer premises devices such as routers, FRADs, or frame aware DSUs.
Local Loop
The physical wires that run from the subscribers service to the Local Exchange Carriers
central office.
NMS
NSP
Network Service Provider. Generic term for a carrier like a Local Exchange Carrier or
Inter-Exchange Carrier, PTT (Postal Telephone and Telegraph), CLEC, etc.
NTU
Network Terminating Unit. A device that is placed at the final interconnect point between
the Public Service Telephone Network and the customer-owned equipment. Generally,
NTUs are used globally by PTTs to terminate various data services including frame relay.
OSI
39
RMON
SLA
SNMP MIB
Simplified Network Management Protocol Management Information Base. A standardsbased grouping of management objects used to communicate network management
information.
Throughput
One of three basic Service-Level Agreement parameters or the actual amount of useful
and non-redundant information that is transmitted or processed.
VC
Virtual Circuit. A switched and private frame relay logical circuit across a frame relay
network made up of a pair of DLCIs.
WAN
40
Network Latency
The outgoing packet is time-stamped so that the round-trip latency can be measured. Since network latency can be
related to length of the frame, some network service providers will insist that measurements be made on a test packet
of a specific size. Therefore, we calculate:
FTDone-way = (t2 t1) / 2
Where:
T1 = The timestamp placed on the outgoing packet
t2 = The time the return packet was detected
We call this the deterministic latency measurement technique. You will note that the one-way FTD is calculated as
the round-trip transit time divided by 2. In a best-case scenario, it may be preferable to actually measure each leg of
latency independently to arrive at an FTDtransmit and an FTDreceive. While theoretically superior, one-way
41
measurement of latency may not be practical. For one-way latency measurements to be performed, exact clock
synchronization needs to be maintained across a network. This can be a technical challenge when you consider the
number of nodes involved and the accuracy required.
It is possible for frame-aware DSUs to transmit and measure latency for packets of varying lengths. For example, test
packets can be sent into the network that cycle between 64 bytes, 256 bytes, 512 bytes and 1,024 bytes. In this way,
reports can be generated showing latency vs. packet size for each measured PVC. This is key, since some applications
generate large packets (for example, FTP), whereas others generate small packets (voice over frame relay).
Another method exists for measuring latency, which we will call the average latency measurement technique.
Consider the calculation of network latency between two endpoints, A and B. Both A and B transmit data over a
PVC. The time at which data leaves A is recorded (Tab). The time at which data is received at B is recorded (Rab).
Likewise, data flowing in the other direction is measured to derive Tba and Rba. Now, an average round-trip latency
can be calculated as follows:
Round-trip latency = (Rab Tab) (Rba Tba)
Note that both (Rab Tab) and (Rba Tba) are relative measures of one-way latency offset by the lack of clock
synchronization at either side of the link. Yet, when the round-trip latency is calculated, clock synchronization offsets
cancel, yielding a round-trip time.
Both techniques are valid, and pros and cons are listed:
The deterministic measurement technique uses packets of known size. Therefore, service providers may favor it
for this reason. Also, test packets of various sizes can be sent, allowing latency vs. packet size to be graphed.
The average measurement technique measures latency of actual customer data, regardless of packet size. The
resulting measure is an average of many different samples. While this technique may have some appeal, it can be
problematic when trying to resolve issues related to missed-latency Service-Level Agreements. Packet length is a
key variable in understanding (and predicting) network latency.
When measuring latency, it is important to understand both average latency and maximum latency. The average
latency technique smoothes out the variation in latency measurement, and, therefore, is not as useful in reporting
both average latency and maximum latency.
Product availability and pricing subject to change without notification. IDCs November 1997 Trends in the
Digital Access Equipment Arena Report: 1996-2002 cites Paradyne as the DSU/CSU market share leader.
Paradyne, Hotwire, FrameSaver, OpenLane, Performance Wizard, MVL and ETC2 are trademarks of
Paradyne Corporation. ETC is a registered trademark of Paradyne Corporation. GlobeSpan is a trademark
of GlobeSpan Technologies Inc. NetScout is a registered trademark of NetScout Systems, Inc. All other
products or services mentioned are the trademarks, service marks, registered trademarks, or registered
service marks of their respective owners.
42