Table of Contents

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
Network Service-Level Assurance ............................................................................................... 18
Network Service-Level Verification .....................................................................................................18
Network Service-Level Analysis..........................................................................................................19
Application Performance Assurance ............................................................................................ 21
Protocol and Application Utilization ....................................................................................................22
Host and User Utilization ....................................................................................................................23
Time-Based Utilization ........................................................................................................................23
Application-Level Decoding Services .................................................................................................24
Forecasting Services ..........................................................................................................................24
Device Management Requirements ............................................................................................. 24
Chapter 6 Sourcebook In Review ......................................................................................... 26
Chapter 7 SNMP Overview ................................................................................................... 27
RFCs Relevant to SNMP .............................................................................................................. 27
Chapter 8 RMON Overview.................................................................................................... 28
Chapter 9 About FrameSaver SLV..................................................................................... 29
Product Overview.......................................................................................................................... 29
FrameSaver SLV Features and Benefits ..................................................................................... 29
Components.................................................................................................................................. 30
Frame Aware DSUs ............................................................................................................................30
OpenLane Management .....................................................................................................................31
NetScout Probes .................................................................................................................................32
Applications ................................................................................................................................... 32
Network Management................................................................................................................... 33
OpenLane Management Applications .................................................................................................34
NetScout Manager Plus ......................................................................................................................35
Chapter 10 About Paradyne .................................................................................................. 36
Core Competencies and Products ............................................................................................... 36
Technology Innovations ................................................................................................................ 36
Frame Relay Management Firsts ........................................................................................................37
Hotwire DSL/MVL Firsts......................................................................................................................37
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.

1
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 real-
world 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.

1
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
Chapter 2 Why Frame Relay?
Frame relay is one of the hottest technologies in the telecommunications industry today. Network managers are
finding that frame relay can relieve many of the headaches caused by bandwidth-hungry applications and services on
limited networks, and simultaneously help reduce the overall cost of their WANs.

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:
Savings in Equipment Acquisition Costs
Frame relay allows many virtual network connections to share a single physical network interface. With circuit-
based WANs, individual sites typically require direct connections to every other site, demanding multiple circuits
at each facility. Frame relay allows each site to connect to every other site through a single physical interface,
amounting to significantly lower equipment costs.

3
 Savings on Local Access Charges
Since only one physical connection is required, only one local loop is needed at each site for all WAN
connectivity. This can result in dramatic cost savings for the local access as well.
Savings on WAN Usage Charges
Frame relay can significantly reduce wide-area network costs, since frame relay usage rates typically are not
mileage sensitive. In addition, incremental connectivity is also less expensive than with private leased lines,
meaning more connectivity for the money. By far, this is the number one reason customers are migrating to
frame relay. Many customers report savings of 40 percent to 60 percent when compared to the costs of
leased-line services.
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.
Improved Levels of Inter-Site Connectivity
With circuit-based networks, it often has been far too expensive to interconnect each site directly with every
other site. In order to provide inter-site connectivity in this model, network managers have been forced to piggy-
back traffic between secondary offices through a primary office, resulting in high levels of latency and
congestion. Frame relays distributed design allows each site to be connected directly to every other site through
the use of virtual circuits, resulting in better connectivity at a far lower cost than an equivalent meshed design.
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.

4
Chapter 3 The Need for Management
Although there are many benefits to be reaped by implementing frame relay as a WAN technology, there are issues
that naturally arise from outsourcing your WAN to a public frame relay service provider. At first glance, these issues
would be no different from using a private leased-line network. But remember that a public frame relay network is
statistically shared by all of its users. In a private leased-line environment, dedicated end-to-end channels are used
to provide wide-area connectivity. In frame relay, Virtual Circuits (VCs) are sharing ports, switches and trunk
resources throughout the network for end-to-end connectivity. When network managers move to frame relay
networking, they place a great deal of responsibility in the hands of the service provider to ensure they are getting
their fair share to the public networks resources. This requires a substantial amount of trust, particularly where
mission-critical applications are concerned.
For this reason, getting contractual commitments for guaranteed levels of service is a critical part of any
implementation effort. The good news is that many service providers are starting to offer Service-Level Agreements
(SLAs) that document explicit levels of network performance and response times. But SLAs can be meaningless if
they are not developed with adequate protection for both the network manager and service provider.
Although an SLA will become the most critical component of a frame relay network once it is operational, it is only a
guarantee that the agreed upon levels of availability and performance will be met and is not a guarantee that an
effective network will be built in the first place. In order for an SLA to be truly effective, other areas must be
examined and agreed upon before the frame relay network is designed. Among these issues are:
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:
Lack of Physical-Layer Visibility
Since frame relay networks are packet based, it is more difficult to conduct non-disruptive, end-to-end
connectivity tests across the frame relay network. Although this is possible with a leased-line topology, frame
relays packet-switched design prevents end-to-end physical-layer testing. Without the proper equipment to
provide both logical and physical-layer tests, it is nearly impossible to quickly diagnose problems at a remote
location.

5
 Lack of Layer 3 and Application Visibility
Frame relay networking is often used to consolidate both LAN-based client/server applications with legacy SNA
host-terminal traffic over a single network. However, multiple protocols running over the same network often
have different requirements that may compete or even conflict with each other. This frame- or packet-based
transport adds to the complexity of viewing and dissecting traffic flow at the network or application layers,
resulting in designs that can cause performance problems with mission-critical applications.
Overall Performance Monitoring
Unlike leased-line networks, frame relay users share the service providers cloud with that providers other
customers. How do subscribers know that they are getting their fair share? There are no real tariffed
parameters to ensure that the service level you are buying is available, other than an SLA. Working through
performance-monitoring issues is a fundamental part of establishing service, and it is the main focus of this
document.
Basic Trust and Security
Outsourcing WAN connectivity means that network managers must open their traffic to the service providers
network. Both parties need to establish a high level of trust that sensitive information and resources at both
organizations will not be compromised.
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.

6
Chapter 4 Service-Level Agreements
Once the frame relay network has been designed and management issues have been addressed, a Service-Level
Agreement (SLA) needs to be constructed that will provide for guaranteed levels of service. Since the SLA is
essentially a binding legal agreementand since these agreements sometime call for significant service rebates should
the service provider not performgreat care and attention should be given to the creation of such a document.
First of all, the Frame Relay Forum is developing a standard for SLAs, allowing network managers and vendors to
communicate using common language and assumptions. Although work in this area is not yet complete (it likely will
be finalized sometime in 1999), the Frame Relay Forums efforts are a good starting point for building a workable
SLA, with macro-measurements of quality for the following three criteria:
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.

How Service Levels Are Measured

In order to understand how SLAs are defined, we must first understand the network model more clearly. The
illustration in Figure 4 shows the basic conceptual boundaries on a typical frame relay network and how measurement
can be conducted.

FIGURE 4

7
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).

8
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

Components of a Service-Level Agreement

A service providers SLA essentially is a binding legal agreement that dictates very specific characteristics of the
frame relay network and offers customer rebates if the SLA performance parameters are not met. Great care is taken
by the NSP in developing the SLA to ensure that the service level measurement parameters are accurate,
understandable, measurable, and meaningful. Most SLAs today include many or all of the following parameters:
Frame Throughput and Data Throughput
Overall throughput can be measured in a number of ways. It is absolutely vital that the SLA explicitly state how,
when and where this measurement is to be made with no ambiguity whatsoever. The two most common metrics
used to measure data throughput are the Frame Delivery Ratio (FDR) and the Data Delivery Ratio (DDR).

The Frame Delivery Ratio service-level metric is used to determine the networks effectiveness in transporting
frame relay traffic across a VC, in a single direction. The FDR is a ratio of successful frame receptions to
attempted frame transmissions. The Data Delivery Ratio is similar to the FDR, except that bytes are counted
instead of frames. See FDR and DDR in the Calculations and Formulas section for details on calculating these
metrics.
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.
Round-Trip vs. One-Way
In addition, you should make sure that your SLA specifies that throughput and latency measurements will be
taken using round-trip measurements, as opposed to one-way measurements. Although one-way latency can be
specified, calculation is technically challenging given the need to maintain precise time synchronization end to
end across the network. In practice, however, one-way latency is usually estimated by measuring the round-trip
latency and dividing by two.

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

Excessive latency due to large packet lengths
Frames lost due to invalid frame length
Frames lost due to CPE failure
Frames transmitted in excess of CIR

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
 Other SLA Options
SLAs can be expanded to include all types of issues. For example, some service users add specific language
about the time it should take to install a new site and get it operational. Likewise, an SLA may include terms
dictating the length of time required to make moves and changes to the frame relay network, including bandwidth
adjustments or site relocation.

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 Web-
based 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 define quality of service.
SLAs may be written around edge-to-edge measurements or end-to-end measurements.
QoS can be measured in terms of throughput, latency and availability.
SLAs can also include clauses for predefined exceptions, averages, and minimum levels-of-service.

11
Chapter 5 Enterprise-Wide Service-Level Management
So far, we have discussed the issues associated with frame relay service management from a WAN-centric approach.
However, effective monitoring and management requires a much broader view of the network. To this end, a total
Enterprise-Wide Service-Level Management architecture must be in place, providing management for all aspects of
an enterprises end-to-end network, including the LANs and WANs, as well as application-level monitoring.
Some of the more critical aspects of an Enterprise-Wide Service-Level Management solution should include:
The physical layer through the applications layer
LAN and WAN utilization rates
Real-time and historical-trend reporting
Access speeds from 56 Kbps through T3 and beyond

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:
Applications being added and retired
Unexpected utilization that causes application performance problems
Contention for resources among different applications, such as print queue updates that prevent remote jobs from
executing
Failure of a service provider to live up to its SLA
Local equipment misconfiguration or failure
And, as always, the infamous back-hoe fade (cable cut)

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 problem-
reporting 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 straight-
forward, this implementation suffers one important drawback: The router is in the communication path between
DSUs.

FIGURE 11

14
There are several drawbacks to this approach:
Routers often can be the source of trouble in a network. A Catch-22 situation arises. The DSUs are deployed in
order to assure connectivity so that routers can communicate over the network service. So, with this technique, the
router needs to be operational to gain connectivity across the network in order for the router to be operational
clearly a problem exists!
The router may not be present when the service is turned up. Optimally, services providers would like to be able to
turn up the service and verify that it is operating correctly with or without a router present.
Now, consider the picture at the bottom of Figure 11. With this method of DSU management interconnection, a
direct management path is established between DSUs. Another PVC is provisioned for the exclusive use of the DSUs.
While issues of router independence are overcome, provisioning of dedicated PVCs may be neither cost effective nor
easy to manage.
Yet another connection scheme is depicted in Figure 12. A single point-to-point VC is provisioned between DSUs.
With this technique, both user data and RMON management data are embedded onto a single PVC between the
respective systems. The embedding of several VCs onto a single VC can be performed by the frame-aware DSUs
using straightforward techniques.

FIGURE 12
There are two advantages to this method:
No additional PVCs are required.
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:
Link Management Interface (LMI) message processing
Remote diagnostics
Loopback tests
User interface

Each area provides critical functionality required to effectively measure overall connectivity and network availability.

15
Link Management Interface (LMI) Message Processing
Before the network can be managed, effective methods of communicating information about the network must be
established. In frame relay networks the standard interface used for this is the Link Management Interface (LMI),
which defines a set of standardized messages for the configuration and maintenance of a VC on a frame relay
network. LMI messages sent by the network notify endpoint devices (Frame Aware DSUs, Routers, or FRADs) of
the active Data-Link Circuit Identifiers (DLCIs) in use on the network2, and also allow for real-time status monitoring
of the physical and logical links between devices on the network.
There are two basic options for processing LMI information, as shown in Figure 13 below. The first method, called
LMI Pass-Through, calls for the DSU to send LMI messages to the router or host for processing directly, with the
DSUs RMON agent monitoring the LMI messages for alerts and other status messages. The second method calls for
the DSU to act as the network endpoint directly. The LMI is then regenerated for the downstream devices.

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:

2
A virtual circuit is associated with each DLCI.

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.
Network Service-Level Assurance
Connectivity Assurance testing is the most essential component of frame relay management. However, Network
Service-Level Assurance is also an important aspect of successfully implementing a comprehensive Enterprise-Wide
Service-Level Management architecture.
Connectivity Assurance testing really only tells you whether or not the network and its various components are
functional. It does not tell you how well it is functioning or provide for much in the way of summary data. In order to
effectively analyze how well a network is living up to the standards defined in an SLA, network managers and service
providers alike must take network analysis to the next level.
Tools for Network Service-Level Assurance fall into two categories:
Network Service-Level Verification
Network Service-Level Analysis

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.
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.

18
 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

SLV Summary - Monthly Report

Customer Name/Account #: EXACT Corporation / 061793 Report Date: 07/15/98 3p.m.
Report Period: 06/01/98 12:00a.m. - 06/30/98 11:59p.m.
Summary Period: 8a.m. - 5p.m.

Data Delivery Rate

Within CIR Above CIR Total Avg Latency Availability
100.00% 99.035% 99.517% 34.5 99.995%

FIGURE 16

Network Service-Level Analysis

An effective Service-Level Management product also should provide insight into the characteristics of networks
offering marginal and exceptional performance, thus allowing the network manager and service provider to fine-tune
the network, rather than simply making sure it doesnt fall below the terms defined in the SLA.
There are three components of any Service-Level Management product that should be examined closely in this area:
Historical analysis of real-world data
Burst analysis
What-if scenarios using worst-case test data

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

Network Capacity & Throughput (Tx) Detail - Weekly Report

Customer Name /Acct. #: Exact Corporation /016793 Report Date: 07/15/98 3p.m.
Name/Location: Chicago Report Period: 06/14/98 12:00a.m. - 06/21/98 11:59p.m.
Summary Period: Mon.-Fri. 8a.m. - 5p.m.

Port Speed
Name/Location (Kbps)
Weekly
Sunday Monday Tuesday Wednesday Thursday Friday Saturday Summary

Chi/Atl 384 %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

Sunday Monday Tuesday Wednesday Thursday Friday Sunday

Chi/Balt 768 %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

Sunday Monday Tuesday Wednesday Thursday Friday Monday

Chi/Clev 512 %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
 A Word About Bursts
Several vendors have introduced systems that allow customers to measure burstsa burst being defined as the
number of bytes sent into the network exceeding the configured committed information rate. During periods of
bursting, network switches mark packets discard eligible by setting the DE bit to 1. Whenever congestion in
the network occurs, the network will drop packets with the DE bit set to 1 before all others.

When measuring bursting, it is important that the techniques employed exactly duplicate those that are utilized by
the switch. While this may seem elementary, some SLM vendors have designed systems that do not measure
bursts in the same way as frame relay switches. This can lead to a situation where the service provider discards
data (legally, according to the SLA), yet the subscribers system indicates that bursting conditions do not exist.
Finger-pointing between the service provider and the subscriber is likely to occur.

Know that bursts should be measured in terms of number of bytes transmitted into the network under CIR and
number of bytes transmitted into the network over CIR. Some systems report a measurement called bursty
seconds. While this may be an intellectually appealing measurement due to its apparent simplicity, it is
meaningless because it does not indicate whether or not a packet is available to be marked discard eligible by
the frame relay switch. There is no way to correlate bursty seconds with network performance.
A Word About Throughput
Throughput is a measure of the number of bytes transmitted into the network, divided by the number of bytes
received at the other end of the link. Throughput, then, is a ratio100% indicating no packets were dropped. It
is important that customers look for systems that actually can measure dropped packets over a period of time.

It may also be important to be able to establish the number of dropped packets sent into the network under and
over CIR. After all, the service provider is allowed to drop packets during congested periods if busting is
occurring.

In conclusion, bursting and throughput are related and should not be viewed independently. As shown in Figure
18, bursting, latency, packet size and throughput are all correlated in a convenient four-panel display.
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.

Application Performance Assurance

At the end of the day, the only important measurement is whether or not the business-critical applications are
performing as expected. Is the network able to keep up with the e-mail traffic being passed between sites? Is database
entry reliable? Are the order-entry and billing systems able to completely exchange data? Being able to discern the
answers to these kinds of questions, make up the highest level of an effective Service-Level Management solution:
the Application Performance Assurance testing and reporting services.
Application Performance Assurance tools provide the necessary visibility into Layer 3 through Layer 7views that
are required in order to effectively manage strategic aspects of the network. These tools help determine which
protocols, applications and users are consuming the most WAN resources, among other details.

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:
Utilization by protocol and application
Utilization by host and/or user
Utilization by time of day, week or month
Application-level decoding services
Forecasting services

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 per-
port 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
Application-Level Decoding Services
Another service that should be looked for in any SLM product is the ability to capture network packets and decode
them in detail, allowing a network manager to view the contents of the traffic directly. Using this feature, a network
manager can go beyond simply looking at IPX traffic, and instead look at NetWare Directory Services (NDS) or SAP
updates, and implement changes accordingly.
Furthermore, these decoding tools should allow the management personnel to view application-specific protocols,
such as SMTP, Oracles SQL*Net and others. Since this type of traffic generally is harder to filter out at the router
level, having the ability to examine application-specific traffic patterns allows for changes to be made to the end
systems directly, allowing the enterprise network to run more efficiently.
For example, it may be that some e-mail messages are being routed across the network when they shouldnt be.
Perhaps a user has relocated from one office to another, and all e-mail messages sent to his address are first routed to
his old office, and then forwarded to his new office. This is unnecessary traffic that is using three times the network
bandwidth it should use. By being able to view the SMTP application protocol directly, this situation could be caught
and handled, providing better network utilization as well as faster e-mail delivery to the user.
Forecasting Services
As shown, the use of RMON probes when applied in conjunction with an SLM product allows the network
management personnel to monitor traffic at a variety of levels, further allowing them to adjust the network or traffic
usage accordingly. However, this same capability can be used to plan for major network changes in a proactive
manner.
For example, assume that an organization wanted to roll out a new company-wide set of services, such as a collection
of notes application. In order to prepare the network for the increased utilization, the network managers would need
to understand how the application affected the overall network.
The best way to perform this type of evaluation is to select a trial site with a known number of users and activity
levels, and then baseline the network utilization according to those parameters. This data could then be projected for
every site in the organization with a known number of users and utilization levels.
Device Management Requirements
The breadth of information that different RMON agents collect, store and report varies significantly among the many
offerings on the market. As we have seen, however, there are some fundamental requirements that must be met in
order for effective management to occur. Devices should be able to collect and report on network activity at all seven
layers, and provide the ability to capture and decode application-layer packets.
How these devices collect, store and report this information is another area of concern. Not all devices provide the
same level of functionality or feature depth, which obviously can cause difficulties when trying to analyze traffic
patterns across different product lines. For this reason, you should verify that your equipment meets certain
management and reporting characteristics, including:
RMON Versions and Availability
There are two main RMON standards that you should know. RMON v1 was the first effort at providing a
consistent Remote Network Monitoring service, although it was limited to LAN-specific topologies such as
Ethernet and Token Ring. RMON v2 is topology-independent, making it useful for monitoring frame relay
networks.

Most of the modern infrastructure equipment available today implements support for one or both of these
RMON versions. Many hubs, switches and routers use RMON, as do frame relay DSUs. The major benefit to
using RMON standards-based instrumentation and tools throughout the enterprise network is that they provide
consistent and accurate monitoring, regardless of where the statistics are being collected.
Collection and Storage
If nothing else, the RMON agents and SLM tools should support standardized information collection and storage
services, allowing the agents to be queried by the SLM platform consistently. Fortunately, standards exist for
these services and are widely supported, although not to the same extent by all vendors.

24
 Agent Polling and Sending Services
Information about the network is collected by the RMON agent periodically, according to the specific MIBs in
use. For example, a DSU with RMON capability collects numerous statistics on the status of the frame relay
network as well as protocol information. Once this data is collected, it must be made available to the central
Network Management System (NMS). This can be achieved by either having the NMS poll the agent
periodically, or by having the agent send summary information to the NMS proactively.

In order to minimize the load on the network, it is often better to let the NMS poll the agent during off-peak
times, allowing for historical analysis without loading down the network. However, this only works when the
network is functional, and you may miss data that indicates a failure is about to occur (or was about to occur,
more likely). Regardless of how the NMS collects data from the agent, it always is important that the agent be
able to store at least 24 hours of activity in memory, providing access to details during periods of unavailability.
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.
Application-Level Assurance is critical to successfully managing an enterprise network.
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
Chapter 6 Sourcebook In Review
This Sourcebook has attempted to cover a wide variety of topics as clearly as possible, enabling network personnel to
understand the issues surrounding effective monitoring and management of frame relay networks. We have covered
topics such as:
Frame relay concepts and benefits
The issues that naturally accompany the outsourcing of WAN services
The need for Service-Level Agreements (SLAs) to guarantee network availability and performance
What RMON agents do and why you need them
The issues behind comprehensive Service-Level Management (SLM)
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
Verify that your SLA is being met
Help you to adjust the network, infrastructure or SLA to optimize the overall network performance and
utilization

26
Chapter 7 SNMP Overview

The Simple Network Management Protocol (SNMP) is a protocol for Internet network management services. It is
formally specified in a series of related RFC documents. SNMP is used by most LAN and WAN equipment vendors
as the preferred method of network management communications.
RFCs Relevant to SNMP
RFC 1089 SNMP over Ethernet
RFC 1140 IAB official protocol standards
RFC 1147 Tools for monitoring and debugging TCP/IP Internets and interconnected devices (superseded by
RFC 1470)
RFC 1155 Structure and identification of management information for TCP/IP-based Internets
RFC 1156 Management Information Base (MIB) network management of TCP/IP-based Internets
RFC 1157 An SNMP
RFC 1158 MIB network management of TCP/IP-based Internets: MIB-II
RFC 1161 (H) - SNMP over OSI
RFC 1187 Bulk table retrieval with SNMP
RFC 1212 Concise MIB definitions
RFC 1213 MIB for network management of TCP/IP-based Internets: MIB-II
RFC 1215 (I) - A convention for defining traps for use with SNMP
RFC 1224 Techniques for managing asynchronously generated alerts
RFC 1270 (I) - SNMP communication services
RFC 1303 (I) - A convention for describing SNMP-based agents
RFC 1470 (I) - A network management tool catalog
RFC 1298 SNMP over IPX (obsolete, see RFC 1420)
RFC 1418 SNMP over OSI
RFC 1419 SNMP over AppleTalk
RFC 1420 SNMP over IPX (replaces RFC 1298)

A managed network using SNMP has three main components:

Management station: A computer running management software

Managed devices with agents: Any device that can respond to SNMP command
Management Information Base (MIB): A database of related manageable objects

SNMP specifies five primitives (commands and responses) that can be used by the management station or managed
devices. These are:
Get-request: Used to request the values of one or more MIB variables
Get-next-request: Used to read values sequentially (often used to read through tables)
Set-request: Used to update one or more MIB values
Get-response: Returned to answer a get-request, get-next-request, or a set-request
Trap: Used to support significant events, such as a cold restart or link down

27
Chapter 8 RMON Overview

In 1992, the Remote Network Monitoring Management Information Base was published as RFC 1271, an extension
to MIB-II, and immediately dubbed the RMON MIB. This RFC has since been superseded by RFC 1757 and RFC
1513. The RMON MIBs contain the tools that a network management station needs to configure and control a
monitor, read out data and reports, and receive alarms.
Remote monitoring (RMON) is broken down into two separate sections, called RMON 1 and RMON 2. RMON 1 is
specified in RFC 1757 and RFC 1513, and is capable of providing information on Layer 1 and Layer 2 of the OSI
model. RMON 2 is specified in RFC 2021 and is capable of providing information on Layer 3 through Layer 7 of the
OSI model.
An RMON implementation has three main components:
Management station: Computer running management software
Probes with agents: Devices designed to monitor the network and collect RMON data
RMON MIBs: Specific RMON databases

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
Chapter 9 About FrameSaver SLV
Paradynes FrameSaver SLV family of products are designed specifically to help customers and service providers
with the challenges of frame relay service-level management. The FrameSaver SLV system provides all the tools
necessary to ensure accurate service level verification and monitoring of the frame relay network as well as true
enterprise-wide service-level management addressed in Chapter 5 of this sourcebook.
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.

FrameSaver SLV Features and Benefits

Features
Full featured 56/64K and T1/FT1 DSU/CSUs
optimized for frame relay access
Extensive SNMP Management, standard MIBs such
as MIB II, Frame Relay and RMON, plus Enterprise
MIBs
Benefits
Offers the flexibility of supporting all access
requirements from 56K to fractional and full T1.
Allows management of different devices under a single
Standards Based platform, such as HP OpenView.
Paradynes OpenLane applications add the ability to
take full advantage of the total solution offered.

29
 Features
Frame Relay aware management including:
- Router independent remote SNMP management
- Shared or dedicated PVC connectivity with LMI
spoofing
- Extensive PVC diagnostic, loopback and pattern
tests
Intelligent data delivery, latency and burst analyzer
features
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.
Intelligent performance monitoring enables accurate
information for network service level analysis and
verification.

Single V.35 data port with standard connector
RMON 2-based Layer 1 to 3 performance monitoring
and data collection. Physical, logical and RMON
statistics stored for 24 hours in 15-minute intervals and
daily totals for 5 days.
Telnet and ASCII User Interface with password
protection
Easy installation with automatic configuration
DSX-1 port on 9124 for consolidating PBX voice
traffic
Dual flash storage areas and in-band FTP software
download
2-year, return to factory warranty
No adapter cable or unique cable required to connect to
your DTE equipment.
Provides information required to manage the
performance of their network. RMON-based data
collection and service level reporting provide efficient
and economical monitoring of vital frame service
parameters.
Provides a separate direct connection to the unit
through an ASCII terminal, modem or over the SNMP
link. This allows the user to configure and test the unit
independent of their NMS system.
Auto configuration and router independent management
reduce installation time, complexity and expense.
DSX-1 drop and insert port allows consolidating of
PBX voice traffic reducing network access costs.
Modular architecture and software downloadability
protects investments and reduces life-cycle costs.
Peace-of-mind and evidence of product quality.

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:

ASCII Terminal Interface (ATI)

This interface provides a menu-driven native interface that is accessible through a VT100 terminal (or
emulation). The terminal can be locally connected or remotely connected (via external modem) to the COM
Port. Three levels of access security with password protection are available.
TELNET Access to the ASCII Terminal Interface
The 9x24 products support TELNET connections to the menu-driven ATI via the IP management link.
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
OpenLane Management Applications
The FrameSaver SLV products offer robust network management as a key differentiator to competitive systems. The
FrameSaver products are managed by Paradynes pre-eminent network management solution, which includes the
DCE Manager, a powerful Element Management System (EMS) that runs in conjunction with HP OpenView,
satisfying a wide range of network monitoring and management requirements. Complementing the DCE Manager is
Performance Wizard, an advanced performance management application providing real-time and historical data
collection and graphing capabilities.
Some of the advanced functionality provided by the DCE Manager application includes:
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.
Enhanced Trap Processing
Enhances the base platforms ability to process, correlate, and display traps. This feature also ensures that the
network map icons accurately reflect the alarm status of the managed devices.
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:

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

34
 Physical Link Performance
Total Line Utilization showing percentage of physical link
Total Line Throughput showing data transmission rates
Heaviest Users utilizing pie charts to detail percentage of utilization for each DLCI, and bar charts to show
heaviest users over time
Diagnostic Displays
Error Free and Errored Seconds, Unavailable Seconds, Signaling & Frame Errors, Unknown Protocol
Frames
LMI Statistics: Reliability Errors, Protocol Errors, Channel Inactives
Congestion Displays
Data Transmitted Over CIR
FECNs, BECNs, Discarded Frames, and Discard Eligibles

NetScout Manager Plus

NetScout Manager, the console software at the heart of the NetScout management family, monitors, analyzes, and
reports on data gathered from FrameSaver SLV access units and NetScout Probes with more than forty integrated
baselining and trending tools and comprehensive, refined reporting capabilities.
NetScout Manager provides:
Alarms and real-time monitoring for daily operations and troubleshooting.
Reports for security audits and policy administration.
Reports for capacity planning.
A consolidated, end-to-end, application-layer view of distributed enterprise networks.
Agent-grouping capabilities that greatly simplify managing large networks from a central console.

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
Chapter 10 About Paradyne
Paradyne Corporation is a recognized pioneer in network access. Founded in 1969, Paradyne was purchased in 1989
by AT&T. Subsequent to its sale on August 1, 1996, by AT&T Corp. and Lucent Technologies, Inc. to Texas Pacific
Group, Paradyne is an independently owned company. Last year, Paradyne was named by The Red Herring magazine
as one of the hottest companies to watch in the 1990s., and this year they named us one of the top fifty private
companies.
But the new Paradyne is not about history. Its about making history. As one of the largest independent
manufacturers of network access products in a dynamic market, we are an industry leadertouting numerous
industry firsts. We develop industry-defining digital access products and technologies that facilitate high-speed access
to networks worldwide for communications, computing and information. We market our award-winning analog
products, digital access products and an extensive array of frame relay solutions and access multiplexers to
commercial end users, Internet service providers (ISPs), frame relay service providers (FRSPs) and network service
providers (NSPs).

Core Competencies and Products

The companys broad competencies are in transmission technologies and applications, with particular strength in
digital signal processing, channel coding and communication applications, combined with a thorough understanding
of wide-area network design and local-loop characteristics.
Paradyne is the U.S. market-share leader in DSU/CSUs. Based on IDCs November 1997 Trends in the Digital
Access Equipment Arena Report: 1996-2002, Paradyne has outsold and outperformed the competition for several
years running. Industry media, analysts and influencers clearly recognize Paradynes product quality and reliability as
the superior choice. In addition to leading the market with high-end products, Paradyne has now added a new
affordable line of DSU/CSU products, delivering Paradynes proven performance, reliability, ease of use and
installation, convenience and quality.
Working with the DSU/CSUs and FrameSaver products is Paradynes exclusive OpenLane network management
suite. Performance Wizard management software, which collaborates to provide user-friendly graphical displays of
the health of the network, enables customers to monitor network performance and make real-time adjustments.
Paradynes DCE Manager application provides a real-time view of network and device status. These applications
support a powerful WAN performance suite from the customers HP OpenView console.
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:
The first 4,800-bps dial modem
The first family of LSI digital modems
The first modem with remote diagnostics
The first 14.4 Kbps modem
The first 9,600 bps/208-B Auto Recognition modem
The worlds first 28.8 Kbps modem
The worlds first 33.6 Kbps modem
The first PCMCIA data/fax modem for notebook computers

36
Frame Relay Management Firsts
The first product to incorporate FRF.9 compression
The first frame relay aware DSU/CSU
The first product to incorporate loopbacks that are non-disruptive to customer applications and verify frame
relay PVC physical and logical integrity
Patented PVC multiplexing technique to support multiple customer data streams and in-band, router-independent
SNMP management in a frame relay access device
The first frame relay total management solution to offer performance management and include the tools to fix
network problems
The first frame relay access device to offer integral ISDN dial restoral
The first frame relay SLV system to offer unprecedented management, network diagnostics and optimization,
outperforming current frame relay solutions from Visual Networks, Adtran, Kentrox and others with rapid
Return to Service and Remote Monitoring (RMON) features

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 Customer Premises [or Provided] Equipment. Communications equipment that resides at
the customers location.
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 Local area network.
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 Network Management System. A system responsible for managing a portion(s) of a
network and the entity that implements functions at the Network Management Layer.
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 Open Systems Interconnection. Model (Layers 1 7) established by the International
Standards Organization (ISO). The idea of OSI is to provide a network design framework
to allow equipment from different vendors to communicate. There are seven layers (or
steps), each building on the one below it. They run from Layer 1 (Physical) to Layer 7
(Applications).

39
RMON Remote Monitoring. A standards-based format used to collect and store network
statistics on various types of LANs and WANs. See the RMON appendix.
SLA Service-Level Agreement. An agreement between a service provider and a user that
defines a set of parameters that quality of service (QoS) is be measured.
SNMP MIB Simplified Network Management Protocol Management Information Base. A standards-
based 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 Wide area network, like a public frame relay.

40
Calculations and Formulas
FDR and DDR
Attempted frame transmissions are referred to as FramesOffered, while successfully delivered frames are referred to
as FramesDelivered. We also can make the distinction between frames delivered inside the predefined bandwidth and
those that were delivered during bursts.
Three metrics are given below:
FDR = (FramesDeliveredc + FramesDeliverede) / (FramesOfferedc + FrameOfferede)
FDRc = FramesDeliveredc / FramesOfferedc
FDRe = FrameDeliverede / FramesOfferede
Where:
FramesDeliveredc = Successfully delivered frames within CIR
FramesDeliverede = Successfully delivered frames in excess of CIR
FramesOfferedc = Offered frames within CIR
FramesOfferede = Offered frames in excess of CIR
The calculations for determining DDR are similar to those used with FDR, with DDR, DDRc and DDRe used instead
of FDR, FDRc and FDRe.

VCA, MTBSO and MTTR

VCA = (IntervalTime ExcludedOutageTime OutageTime) / (IntervalTime ExcludedOutageTime) * 100
MTBSO = (IntervalTime ExcludedOutageTime OutageTime) / OutageCount
MTTR = OutageTime / OutageCount
Where:
IntervalTime = Time in minutes of period that availability is measured
OutageTime = Aggregate time of all outages on a VC
ExcludedOutageTime = Aggregate time of all excluded outages that occur during the measurement period
OutageCount = Count of the number of outages on a VC during the IntervalTime

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