Table of ContentsForeword ........................................................................................................................................ 1Chapter 1 Introduction............................................................................................................. 2Chapter 2 Why Frame Relay? ................................................................................................. 3Chapter 3 The Need for Management .................................................................................... 5Chapter 4 Service-Level Agreements..................................................................................... 7How Service Levels Are Measured ................................................................................................ 7Components of a Service-Level Agreement .................................................................................. 9Chapter 5 Enterprise-Wide Service-Level Management .................................................... 12Network Instrumentation ............................................................................................................... 13Connectivity Assurance ................................................................................................................ 15

Link Management Interface (LMI) Message Processing .....................................................................16Diagnostics .........................................................................................................................................16Loopback Testing................................................................................................................................17User Interface .....................................................................................................................................17

Network Service-Level Assurance ............................................................................................... 18Network Service-Level Verification .....................................................................................................18Network Service-Level Analysis..........................................................................................................19

Application Performance Assurance ............................................................................................ 21Protocol and Application Utilization ....................................................................................................22Host and User Utilization ....................................................................................................................23Time-Based Utilization ........................................................................................................................23Application-Level Decoding Services .................................................................................................24Forecasting Services ..........................................................................................................................24

Device Management Requirements............................................................................................. 24Chapter 6 Sourcebook In Review......................................................................................... 26Chapter 7 SNMP Overview ................................................................................................... 27RFCs Relevant to SNMP .............................................................................................................. 27Chapter 8 RMON Overview.................................................................................................... 28Chapter 9 About FrameSaver SLV..................................................................................... 29Product Overview.......................................................................................................................... 29FrameSaver SLV Features and Benefits ..................................................................................... 29Components.................................................................................................................................. 30

Frame Aware DSUs ............................................................................................................................30OpenLane Management .....................................................................................................................31NetScout Probes .................................................................................................................................32

Applications ................................................................................................................................... 32Network Management................................................................................................................... 33

OpenLane Management Applications .................................................................................................34NetScout Manager Plus ......................................................................................................................35

Chapter 10 About Paradyne .................................................................................................. 36Core Competencies and Products ............................................................................................... 36Technology Innovations................................................................................................................ 36

Frame Relay Management Firsts ........................................................................................................37Hotwire DSL/MVL Firsts......................................................................................................................37

Glossary of Terms....................................................................................................................... 39Calculations and Formulas........................................................................................................ 41FDR and DDR ...............................................................................................................................41VCA, MTBSO and MTTR.............................................................................................................. 41Network Latency ........................................................................................................................... 41

1ForewordOver the last five years frame relay has become the wide-area networking technology of choicefor most data applications and even today is still experiencing tremendous growth. What startedout as a fast packet alternative to X.25 for LAN-to-LAN connectivity has evolved into areliable, ubiquitous public networking service. The frame relay service providers haveestablished high performance standards, capable of supporting nearly any business application.

Today frame relay networks support critical applications including SNA, SAP, voice/fax/videoand a wide range of IP applications. Often these applications and protocols compete with eachother for bandwidth creating network performance issues that are difficult to diagnose. Networkmanagers who rely on public frame relay service are using a new management and diagnostictool, Service-Level Management systems, to ensure optimum network service and applicationperformance, even across public networks.

Service-Level Management of multi-protocol networks is required for businesses that rely on thenetwork to support the company. Even the growth of the Internet continues to fuel frame relaygrowth as frame relay lines are used for Internet access, as well as support of both enterprise IPand legacy applications. Frame relay services are now generally available nearly everywherearound the world. Service providers trying to differentiate their frame services have respondedby offering various types and levels of Service-Level Management. But it remains theresponsibility of the IT manager to monitor, manage and troubleshoot the IT networkinfrastructure. New Service-Level Management tools exist today to satisfy this requirement.

The Frame Relay Service-Level Management Sourcebook focuses on the issues of frame relayservice-level management specifically and as part of an overall enterprise-wide managementmodel. I would recommend this sourcebook to any network manager interested in knowing moreabout frame relay management issues; typical service level agreements and how they arestructured; the SLA parameters and how they are measured; and some insight into how framerelay Service-Level Management affects overall application performance management.

Chris NicollSenior Analyst, Network Management and Carrier InfrastructureCurrent Analysis, Inc.

2Chapter 1 IntroductionThis sourcebook is intended for network managers looking to either deploy new frame relay networks or bettermanage the networks they currently have in place, and for service providers who are offering managed frame relaynetworks. 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 relayequipment vendors and service providers.

We begin by exploring issues associated with frame relay services and the need for effective Service-LevelManagement on frame relay networks. We then examine a more comprehensive Service-Level Management modelthat 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 manyexcellent textbooks on the subject.1 This sourcebook presents an overview of frame relay technology, with a specificfocus on Service-Level Agreements and Management. While the technology of frame relay has been around for quitesome 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 sametime 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.

3Chapter 2 Why Frame Relay?Frame relay is one of the hottest technologies in the telecommunications industry today. Network managers arefinding that frame relay can relieve many of the headaches caused by bandwidth-hungry applications and services onlimited networks, and simultaneously help reduce the overall cost of their WANs.

FIGURE 2Dedicated End-to-End Circuit Configuration

FIGURE 3Virtual Circuit Configuration Using Frame Relay

Essentially, frame relay allows a distributed organization to build a virtual WAN using packet-switching technologyinstead of dedicated end-to-end circuits, as demonstrated in Figures 2 and 3. Rather than implement a mesh of T1s orleased-line circuits between each site, a network manager can use frame relay to build a hub-and-spoke networkbetween the different facilities, with the service providers frame relay cloud at the center. This design provides manybenefits:

Savings in Equipment Acquisition CostsFrame 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 circuitsat each facility. Frame relay allows each site to connect to every other site through a single physical interface,amounting to significantly lower equipment costs.

4 Savings on Local Access ChargesSince only one physical connection is required, only one local loop is needed at each site for all WANconnectivity. This can result in dramatic cost savings for the local access as well.

Savings on WAN Usage ChargesFrame relay can significantly reduce wide-area network costs, since frame relay usage rates typically are notmileage 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 toframe relay. Many customers report savings of 40 percent to 60 percent when compared to the costs ofleased-line services.

Improved FlexibilityThe virtual nature of frame relay offers much greater flexibility when business demands require changes to thenetwork architecture. Adding new sites to the network is a simple matter of connecting those sites to the serviceproviders 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 dedicatednetworks, since it requires only a modification to a single sites connection to the cloud, which probably can behandled with a simple software change at the service providers network.

Improved Levels of Inter-Site ConnectivityWith circuit-based networks, it often has been far too expensive to interconnect each site directly with everyother 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 andcongestion. Frame relays distributed design allows each site to be connected directly to every other site throughthe use of virtual circuits, resulting in better connectivity at a far lower cost than an equivalent meshed design.

Performance on DemandFrame relay has the unique capability of temporarily exceeding the allocated bandwidth between two sites. Thisturbo mode lets you buy just the bandwidth you need for routine operations, allocating more bandwidth whenit is needed for large transfers. Equally important, this temporary allocation happens invisibly, according tobandwidth-usage parameters defined when setting up the service. You define when you want it to happen, andwhen those conditions are met, the network responds accordingly.

Migration to ATMMany users and service providers are looking to migrate their core network infrastructures to ATM, allowing forvoice, video and data traffic to be sent across a single WAN infrastructure. With lower costs and wideravailability than ATM, frame relay is already becoming a common local-access technology for ATM-basednetworks, allowing network managers to take advantage of the benefits of both technologies. With thisphenomena in motion, it is easy to see why many network professionals see frame relay as a logical steppingstone to ATM.

Investment ProtectionThe frame relay migration began in earnest in 1994, and today it is the fastest-growing network servicebarnoneworldwide. The worldwide frame relay services market has grown from approximately $830 million in1995 to $3.9 billion by the end of 1997. Looking ahead, we expect the market to top $10 billion by the year2000. The number of frame relay ports is expected to grow from 123,000 in 1995 to more than 1.5 million in theyear 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.

5Chapter 3 The Need for ManagementAlthough there are many benefits to be reaped by implementing frame relay as a WAN technology, there are issuesthat naturally arise from outsourcing your WAN to a public frame relay service provider. At first glance, these issueswould be no different from using a private leased-line network. But remember that a public frame relay network isstatistically shared by all of its users. In a private leased-line environment, dedicated end-to-end channels are usedto provide wide-area connectivity. In frame relay, Virtual Circuits (VCs) are sharing ports, switches and trunkresources throughout the network for end-to-end connectivity. When network managers move to frame relaynetworking, they place a great deal of responsibility in the hands of the service provider to ensure they are gettingtheir fair share to the public networks resources. This requires a substantial amount of trust, particularly wheremission-critical applications are concerned.

For this reason, getting contractual commitments for guaranteed levels of service is a critical part of anyimplementation 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 ifthey 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 aguarantee that the agreed upon levels of availability and performance will be met and is not a guarantee that aneffective network will be built in the first place. In order for an SLA to be truly effective, other areas must beexamined and agreed upon before the frame relay network is designed. Among these issues are:

Bandwidth RequirementsFrame relay demands a much better understanding of the bandwidth requirements of the specific networkprotocols and applications in use on your network. In addition, you also will need to make bandwidth decisionsaccording to these elements importance to your business objectives and their usage patterns (time of day, day ofweek, quantities of time, etc.).

For example, you may wish to distribute reports electronically, but you may not want to replicate printer queuesacross the entire enterprise network. With all of the options available in the various frame relay offerings, beingable to match your needs precisely to the proper type of service can make the difference between building aneffective network or not.

Connectivity RequirementsJust as you need to ensure that you will have a sufficient level of bandwidth across your wide-area network, youalso must allow for a sufficient level of connectivity at each of your installation sites. You may need to providefor VCs between each of the secondary facilities in order to guarantee e-mail delivery times. Conversely, youmay be able to get by with VCs that only connect your field offices to a central office (or several primaryfacilities, as the case may be). Frame relay allows for extraordinarily high levels of flexibility in design, includinginefficient or inappropriate ones.

In addition to these planning concerns, there are various management issues that must be addressed before thenetwork can be implemented. Since frame relay uses a packet-switched design instead of circuit-switched design, it ismuch more difficult to monitor the entire network from top to bottom. Among these issues are:

Lack of Physical-Layer VisibilitySince frame relay networks are packet based, it is more difficult to conduct non-disruptive, end-to-endconnectivity tests across the frame relay network. Although this is possible with a leased-line topology, framerelays packet-switched design prevents end-to-end physical-layer testing. Without the proper equipment toprovide both logical and physical-layer tests, it is nearly impossible to quickly diagnose problems at a remotelocation.

6 Lack of Layer 3 and Application VisibilityFrame relay networking is often used to consolidate both LAN-based client/server applications with legacy SNAhost-terminal traffic over a single network. However, multiple protocols running over the same network oftenhave different requirements that may compete or even conflict with each other. This frame- or packet-basedtransport 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 MonitoringUnlike leased-line networks, frame relay users share the service providers cloud with that providers othercustomers. How do subscribers know that they are getting their fair share? There are no real tariffedparameters to ensure that the service level you are buying is available, other than an SLA. Working throughperformance-monitoring issues is a fundamental part of establishing service, and it is the main focus of thisdocument.

Basic Trust and SecurityOutsourcing WAN connectivity means that network managers must open their traffic to the service providersnetwork. Both parties need to establish a high level of trust that sensitive information and resources at bothorganizations will not be compromised.

For many organizations, frame relay represents a management challenge. On one hand, the economic benefits fortransporting 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 themigration to frame relay to be a straightforward and systematic procedure. These offerings also ease the burden ofnetwork 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, thuseasing the transition and overall manageability of the network.

7Chapter 4 Service-Level AgreementsOnce the frame relay network has been designed and management issues have been addressed, a Service-LevelAgreement (SLA) needs to be constructed that will provide for guaranteed levels of service. Since the SLA isessentially a binding legal agreementand since these agreements sometime call for significant service rebates shouldthe 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 tocommunicate using common language and assumptions. Although work in this area is not yet complete (it likely willbe finalized sometime in 1999), the Frame Relay Forums efforts are a good starting point for building a workableSLA, 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 andadjust the network, network managers need much greater levels of detail. For example, how exactly is networklatency and throughput going to be measured? Which layer of the network will be monitored? Between which pointson the network? How is latency measuredround trip or one way? What size packets will be used to measurelatency? 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 betterquality of service guarantees, custom reports and improved problem resolution/help desk functions. However, until astandard SLA is agreed upon, and service providers implement the standards, the metrics and how SLAs aremeasured will vary from service provider to service provider. Some network managers are working with theirproviders to define the metrics of their SLA and the specifics of how, when and where these metrics will bemeasured.

How Service Levels Are MeasuredIn order to understand how SLAs are defined, we must first understand the network model more clearly. Theillustration in Figure 4 shows the basic conceptual boundaries on a typical frame relay network and how measurementcan be conducted.

FIGURE 4

8Very simply, there are two points where SLA measurements can be made: at the frame relay switch port or at thecustomers 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 andmanagement of the physical equipment. Several frame relay switch vendors have built data collection capabilitiesdirectly into their products, allowing for just this type of management. SLAs based on measurements made at theframe 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-endmeasurements as the basis for their SLAs. To do this, a device must be located on the customers premises that cancollect the required information and send it back to a central Network Management System (NMS) on a periodicbasis.

Recently, a few DSU vendors have added data collection capabilities to their products just for this purpose. In NorthAmerica, the DSU is a natural place to integrate such functionality, since it historically has been the agreed-upondemarcation point between the service provider and the user. In other parts of the world where NTUs are installedand owned by the local access provider, a standalone probe may be required for the collection and communicationof SLA metrics. This is demonstrated below in Figure 5.

FIGURE 5The Managed Demarc is the point at which the subscribers responsibility ends and the service providersresponsibility begins. However, in Figure 6 below, we show two points of demarcation: one for the local loopprovider (the incumbent LEC or PTT), and one for the frame relay service provider. In reality, these points may be inthe same physical unit (such as a DSU) or may alternately take the form of two distinct systems (such as an NTU anda probe).

9SLAs defined in terms of end-to-end responsibility typically include the local loop as well as the core frame relayswitching system. Most frame relay service providers will take responsibility for end-to-end management as long asyou are using their equipment. Other service providers may not be so inclined.

FIGURE 6

Components of a Service-Level AgreementA service providers SLA essentially is a binding legal agreement that dictates very specific characteristics of theframe relay network and offers customer rebates if the SLA performance parameters are not met. Great care is takenby 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 ThroughputOverall 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 metricsused 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 transportingframe relay traffic across a VC, in a single direction. The FDR is a ratio of successful frame receptions toattempted frame transmissions. The Data Delivery Ratio is similar to the FDR, except that bytes are countedinstead of frames. See FDR and DDR in the Calculations and Formulas section for details on calculating thesemetrics.

Network LatencyNetwork latency, sometimes called Frame Transfer Delay (FTD), is a measure of the time it takes for packets totraverse the network, from end to end or from edge to edge. Since latency is a function of the amount of time ittakes 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-WayIn addition, you should make sure that your SLA specifies that throughput and latency measurements will betaken using round-trip measurements, as opposed to one-way measurements. Although one-way latency can bespecified, calculation is technically challenging given the need to maintain precise time synchronization end toend across the network. In practice, however, one-way latency is usually estimated by measuring the round-triplatency and dividing by two.

10

Service AvailabilityIt is also important to measure the overall up-time and availability of the frame relay service, including any and alloutages that interrupt traffic moving through the network. Three such measurements are Virtual CircuitAvailability (VCA), Mean Time Between Service Outages (MTBSO) and Mean Time to Repair (MTTR). Thesemeasurements should be made on each VC on the network. See VCA, MTBSO and MTTR in the Calculationsand Formulas section for information on how to calculate these values.

ExclusionsBesides looking at overall performance, SLAs may include allowances for any predefined conditions that wouldrequire an adjustment in the performance calculations. There are several valid reasons for service beingunavailable, and these exclusions must be defined in the SLA. For example, a loose cable on a customer-ownedrouter should be excluded in the SLA, although the same problem on a provider-owned piece of equipmentshould 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 ResolutionBesides defining what a problem looks like, it is also crucial to fully define the terms, conditions and proceduresfor resolving problems. For example, network managers may want to specify a shorter resolution time forproblems affecting the full trunk or port than those affecting just one virtual connection, since a full trunk/lineoutage at a primary site could shut down the entire companys network. Meanwhile, a service provider will wantto specify that the network manager will have personnel available to assist the service provider in gainingphysical access to the CPE equipment.

Furthermore, it is important that the equipment used to track the SLA be capable of collecting and displayinginformation to make it clear as to whether or not a particular failure is excluded. This is not the time for fuzzyagreements and vague statements about some type of outage. Where, when, why and how long are questions thatcan be answered with the right type of systems in place.

A Note on AveragesSome SLA covenants revolve around averages. For example, a statement may be included in the SLA that statesthat 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 haveaverage 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-sensitiveapplications. For this reason, broad averages should be avoided, with SLAs focusing instead on minimumrequirements. This approach will best serve the needs of the user and will ensure proper operation of theapplications across all links in the network.

Service-Level ReportingEach of the measurements listed above can be tracked for every VC on a frame relay cloud, with each VC beingtracked for one or more SLA parameters. With a medium-sized network of 200 VCs, this can be anoverwhelming amount of information to sift through.

Therefore, there is a need for consolidated statements of network operation, as well as detailed reports showingspecific failures. At the highest level, the subscriber is interested in getting a thumbs up or a thumbs downshowing whether or not the network performed according to the guaranteed levels. Figure 7 below shows asample report summarizing service-level data over a monthly period.

11

Other SLA OptionsSLAs can be expanded to include all types of issues. For example, some service users add specific languageabout the time it should take to install a new site and get it operational. Likewise, an SLA may include termsdictating the length of time required to make moves and changes to the frame relay network, including bandwidthadjustments or site relocation.

FIGURE 7Most service providers offer a basic SLA or at least a simple verification service. These agreements are usuallybased on monthly averages of data throughput, latency and availability, and they offer some type of guarantee withlimited 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 servicestypically are more expensive than the basic offering, but can be well worth the additional costs if network managersconsider 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.

12

Chapter 5 Enterprise-Wide Service-Level ManagementSo 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 totalEnterprise-Wide Service-Level Management architecture must be in place, providing management for all aspects ofan 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 onapplications being alive and well all of the time. In the end, performance of critical business applications is the onlyimportant measure of the network. If applications are not performing to expectations, the business is exposed. Werefer 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 ofthese 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 relatedto the frame relay service directly. While performance and availability of the frame relay network should be keyconcerns, they are not the only aspects that should be on the minds of network managers. Therefore, networkmanagers must implement measurement services across their entire networks in order to truly measure applicationperformance.

In addition, the network manager should care about how the entire enterprise network is being impacted by theseother elements, since the root cause may very well be related to some other issue. Without the necessary tools toevaluate parameters associated with the network service and the behavior of applications, problems may never befully understood.

Today, various service providers are now offering managed LAN or Router services as well as managed WANservices. As part of these comprehensive out-tasking services a view of the overall application and network flowperformance is also essential. In Figure 8 below, we present a comprehensive model identifying the building blocks ofa well-designed Enterprise-Wide Service-Level Management model.

13

FIGURE 8Service-Level Management Model

The Service-Level Management model serves as a tool that can be used effectively within an organization as well asbetween 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-LevelVerification and Service-Level Analysis.

Network InstrumentationBefore we explore this model in greater depth, it is useful to understand network instrumentation. At a minimum, weneed to deploy data collection and control devices at the edge of the WAN service, and preferably across the LAN aswell.

We refer to these devices as remote monitoring (RMON) agents. For the WAN these typically take the form of aDSU with embedded RMON agent or a RMON WAN probe. Additionally, we may also want to instrument selectedLAN segments at various locations across the enterprise with RMON LAN probes. An example of this is shown inFigure 9 below.

FIGURE 9

14

Lets consider the issue of how DSUs with RMON agents communicate in a frame relay network. Each agent needsto establish communications with other agents as well as with the Network Management System (NMS). This isdemonstrated below in Figure 10.

FIGURE 10While it seems elementary, interconnection of agents across the WAN is in itself not trivial. Two methods ofmanagement connectivity are demonstrated in Figure 11. In the first (router-based) method, the source DSU isinterconnected with the router via a LAN or serial connection. The router combines this information with user dataand 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 betweenDSUs.

FIGURE 11

15

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 inorder to assure connectivity so that routers can communicate over the network service. So, with this technique, therouter needs to be operational to gain connectivity across the network in order for the router to be operationalclearly a problem exists!

The router may not be present when the service is turned up. Optimally, services providers would like to be able toturn 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, adirect 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 noreasy 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 therespective systems. The embedding of several VCs onto a single VC can be performed by the frame-aware DSUsusing straightforward techniques.

FIGURE 12There 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 inhandy when it comes time to run diagnostic tests or to measure latency.

Connectivity AssuranceSeveral elements contribute to the goal of effectively monitoring and managing overall connectivity assurance. Theseinclude:

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.

16

Link Management Interface (LMI) Message ProcessingBefore the network can be managed, effective methods of communicating information about the network must beestablished. 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 relaynetwork. LMI messages sent by the network notify endpoint devices (Frame Aware DSUs, Routers, or FRADs) ofthe active Data-Link Circuit Identifiers (DLCIs) in use on the network2, and also allow for real-time status monitoringof 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, calledLMI Pass-Through, calls for the DSU to send LMI messages to the router or host for processing directly, with theDSUs RMON agent monitoring the LMI messages for alerts and other status messages. The second method calls forthe DSU to act as the network endpoint directly. The LMI is then regenerated for the downstream devices.

FIGURE 13Generally speaking, the LMI Terminate/Regenerate model is more effective for network management purposes. Firstand foremost, by terminating the signal at the DSU, a known entity and configuration can be tested independent ofthe 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 notmind this model either, since additional management agents can be installed on the router specifically, thus providingmultiple levels of network management and reporting.

DiagnosticsRobust diagnostics are a fundamental component of any well-designed network management system. A gooddiagnostic system can collect information at multiple layers of the OSI stack and can report this information to thenetwork management staff on a timely basis. Some examples of the data that should be collected and made availableby the RMON agents for diagnostic purposes are:

2 A virtual circuit is associated with each DLCI.

17

Physical-layer statistics Frame Relay link statistics Frame Relay PVC statistics LMI statistics

Loopback TestingAnother key ingredient of any management system is the ability to execute a loopback test, where test patterns aretransmitted to a destination system and are immediately echoed back to the original sender. When the information isreceived, 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-linklayers of the network. It should be pointed out that in a frame relay network environment Layer 1 testing only worksfor 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 inthat it can be done only by the local exchange carrier, and should be considered only as a last resort for testingphysical connectivity.

However, since frame relay provides a consistent Layer 2 interface across the entire WANregardless of theunderlying mediumit is also possible to conduct non-disruptive loopback tests at that layer. Specifically, DSUssupporting dedicated management circuits can use this technique to transparently test connectivity between deviceswithout impacting normal traffic.

User InterfaceInstallation, configuration, software downloading, out-of-band access services, diagnostics and loopback testingservices are difficult procedures for many personnel to easily grasp. Making these procedures easy is, therefore, anessential 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 14below. In this example, one sites network has gone offline, as indicated by a red icon.

FIGURE 14

18

By clicking on the failed network icon, a graphical representation of the DSU can then be presented to the networkmanager, as shown in Figure 15 below.

FIGURE 15As you can see, the devices per-port status information should be readily visible. In addition, a variety of options forreconfiguring, resetting or testing the device should be allowed.

Network Service-Level AssuranceConnectivity Assurance testing is the most essential component of frame relay management. However, NetworkService-Level Assurance is also an important aspect of successfully implementing a comprehensive Enterprise-WideService-Level Management architecture.

Connectivity Assurance testing really only tells you whether or not the network and its various components arefunctional. It does not tell you how well it is functioning or provide for much in the way of summary data. In order toeffectively analyze how well a network is living up to the standards defined in an SLA, network managers and serviceproviders 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 thatshow 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 providerswith the information required to fine-tune the network for optimal performance. In this regard, they help to ensurethat the SLA is never needed, since the network always performs better than expected.

Network Service-Level VerificationService-Level Management systems (including RMON agents and NMS systems) provide a set of tools forcalculating 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 ThroughputNetwork throughput is measured in terms of Data Delivery Ratio (DDR) or Frame Delivery Ratio (FDR), asdescribed in Chapter 4, Components of a Service-Level Agreement. One technique for measuring DDR orFDR is to have each DSU periodically send management packets containing frame and octet counts to a centralnetwork management system, allowing the network manager to measure the number of octets and frames thatwere sent and received over a known time frame.

19

Network LatencyNetwork latency is measured in terms of the amount of time it takes to send a complete packet from oneendpoint 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 packetshould be transmitted across the VC being tested and not through a specific management circuit. For details onhow to calculate latency, refer to Network Latency in the Calculations and Formulas section.

Testing FrequencyAn 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, asthey will end up consuming significant amounts of valuable bandwidth, and actually may trigger performancedegradation problems during periods of network congestion. Conversely, if samples are only taken every fewminutes, there may not be enough data to identify problem scenarios accurately until after the fact. One or twosamples per minute will probably be sufficient for most users.

Reporting CharacteristicsOnce data has been collected, it needs to be processed and distributed to the appropriate network managementpersonnel. Depending on the size and complexity of the network in question, this could happen as often as once aday, or as infrequently as once a month. The SLM systems also should provide detailed reports that summarizethe overall network performance, while showing where problems occurred, if any. An example from ParadynesSLV 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 RateWithin CIR Above CIR Total Avg Latency Availability

100.00% 99.035% 99.517% 34.5 99.995%

FIGURE 16

Network Service-Level AnalysisAn effective Service-Level Management product also should provide insight into the characteristics of networksoffering marginal and exceptional performance, thus allowing the network manager and service provider to fine-tunethe 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

20

Historical analysis provides insight into how well the network operates, and it should give some indication as towhether or not certain VCs are over- or under-subscribed. Meanwhile, what-if scenarios offer the opportunity to planfor 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 AnalysisIn Figure 17 below, a report is presented that shows network capacity and throughput by day of week. Using thistype of information, a network manager cannot only measure the overall availability of his or her networkresources, 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)

WeeklySunday 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 temporaryover-subscription requests. Does latency go up? Are packets thrown away? Or can a burst be absorbed by thenetwork without issue? The Service Level Management solution you choose for your network should be able todisplay these bursts in a variety of ways, as illustrated in Figure 18 below.

FIGURE 18

21

A Word About BurstsSeveral vendors have introduced systems that allow customers to measure burstsa burst being defined as thenumber of bytes sent into the network exceeding the configured committed information rate. During periods ofbursting, network switches mark packets discard eligible by setting the DE bit to 1. Whenever congestion inthe 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 bythe switch. While this may seem elementary, some SLM vendors have designed systems that do not measurebursts in the same way as frame relay switches. This can lead to a situation where the service provider discardsdata (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 andnumber of bytes transmitted into the network over CIR. Some systems report a measurement called burstyseconds. While this may be an intellectually appealing measurement due to its apparent simplicity, it ismeaningless because it does not indicate whether or not a packet is available to be marked discard eligible bythe frame relay switch. There is no way to correlate bursty seconds with network performance.

A Word About ThroughputThroughput is a measure of the number of bytes transmitted into the network, divided by the number of bytesreceived at the other end of the link. Throughput, then, is a ratio100% indicating no packets were dropped. Itis 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 andover CIR. After all, the service provider is allowed to drop packets during congested periods if busting isoccurring.

In conclusion, bursting and throughput are related and should not be viewed independently. As shown in Figure18, bursting, latency, packet size and throughput are all correlated in a convenient four-panel display.

What-If ScenariosFrom 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 siteif an additional 64 Kbps of traffic were added to its connection? Would other applications slow down? Wouldmore bandwidth need to be purchased?

Some RMON probes can generate load patterns that simulate almost any type of data, allowing these kinds oftests to be conducted easily. Make sure that the SLM you use can track the results of these tests cleanly.

Application Performance AssuranceAt the end of the day, the only important measurement is whether or not the business-critical applications areperforming as expected. Is the network able to keep up with the e-mail traffic being passed between sites? Is databaseentry reliable? Are the order-entry and billing systems able to completely exchange data? Being able to discern theanswers 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 thatare required in order to effectively manage strategic aspects of the network. These tools help determine whichprotocols, applications and users are consuming the most WAN resources, among other details.

22

For example, Application Performance Assurance can be useful when trying to determine how well the frame relaynetwork will respond to changes in the types of traffic being carried. If a network manager wanted to know how thenetwork would respond if SNA traffic were migrated onto the frame relay network, Application PerformanceAssurance tools should be able to identify this. These services also can be useful for building predictive models thatshow 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 thenetwork manager interested in how the changes in traffic will affect the frame relay networks utilization levels, butalso how the changes will affect the applications, hosts and users. Gaining access to this level of visibility is whatApplication 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 effectivelymanage not just the frame relay network, but the entire enterprise (WAN and LAN).Protocol and Application UtilizationIn order to effectively analyze and plan for major changes to the network, network managers must be able to trackthe protocols in use on the network and display their consumption rates. This is the only way to know how muchbandwidth 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 relaynetwork is consuming a significant amount of bandwidth and preventing SNA traffic from getting through on a timelybasis. Another example may be that NetWare Service Advertisement Protocol (SAP) updates are consuming aninordinate 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 toflow 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 networkmanager to prevent application-layer failures. This is illustrated in Figure 19 below.

FIGURE 19

23

In addition to measuring protocol and application traffic at a broad level, an SLM solution also should allow thenetwork manager to view these statistics on a per-DSU basis. In addition, the SLM should be able to query eachRMON agent individually for detailed information, allowing the agents to locate specific utilization issues on a per-port basis easily.

Host and User UtilizationNot all network congestion problems are related to a specific protocol or application, although it may seem that wayfrom a cursory look at the network traffic. In reality, the problem may be that a particular user or host is misusing thenetwork 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 theper-node layer, as shown in Figure 20 below. Using this information, you can see exactly what the source of yourutilization issues are, and either adjust your bandwidth or router filters appropriately.

FIGURE 20Host-specific monitoring also can expose excessive user activity. For example, if a user is downloading a large file offthe Internetor even from something like an internal database systemit is possible to track the excess utilizationdown to the specific PC in question, showing the specific times that the problem occurred. It is then a simple matterof locating the user and adjusting the behavior appropriately.Time-Based UtilizationSometimes excess traffic is a function of business, and in these situations the traffic cannot be filtered out at therouter. One example of this might be an order-entry system that submits new orders to manufacturing and billingsystems in different parts of the company. In this scenario, a network manager would want to make sure that plentyof 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-entrysystems may conduct their batch transfers at 11 p.m. every weeknight. In another example, a payroll system may senddata 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 toallocate sufficient amounts of bandwidth for the large transfers to complete successfully.

24

Application-Level Decoding ServicesAnother service that should be looked for in any SLM product is the ability to capture network packets and decodethem in detail, allowing a network manager to view the contents of the traffic directly. Using this feature, a networkmanager can go beyond simply looking at IPX traffic, and instead look at NetWare Directory Services (NDS) or SAPupdates, 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 routerlevel, having the ability to examine application-specific traffic patterns allows for changes to be made to the endsystems 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 tohis old office, and then forwarded to his new office. This is unnecessary traffic that is using three times the networkbandwidth it should use. By being able to view the SMTP application protocol directly, this situation could be caughtand handled, providing better network utilization as well as faster e-mail delivery to the user.

Forecasting ServicesAs shown, the use of RMON probes when applied in conjunction with an SLM product allows the networkmanagement personnel to monitor traffic at a variety of levels, further allowing them to adjust the network or trafficusage accordingly. However, this same capability can be used to plan for major network changes in a proactivemanner.

For example, assume that an organization wanted to roll out a new company-wide set of services, such as a collectionof notes application. In order to prepare the network for the increased utilization, the network managers would needto 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 activitylevels, and then baseline the network utilization according to those parameters. This data could then be projected forevery site in the organization with a known number of users and utilization levels.

Device Management RequirementsThe breadth of information that different RMON agents collect, store and report varies significantly among the manyofferings on the market. As we have seen, however, there are some fundamental requirements that must be met inorder for effective management to occur. Devices should be able to collect and report on network activity at all sevenlayers, 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 thesame level of functionality or feature depth, which obviously can cause difficulties when trying to analyze trafficpatterns across different product lines. For this reason, you should verify that your equipment meets certainmanagement and reporting characteristics, including:

RMON Versions and AvailabilityThere are two main RMON standards that you should know. RMON v1 was the first effort at providing aconsistent Remote Network Monitoring service, although it was limited to LAN-specific topologies such asEthernet and Token Ring. RMON v2 is topology-independent, making it useful for monitoring frame relaynetworks.

Most of the modern infrastructure equipment available today implements support for one or both of theseRMON versions. Many hubs, switches and routers use RMON, as do frame relay DSUs. The major benefit tousing RMON standards-based instrumentation and tools throughout the enterprise network is that they provideconsistent and accurate monitoring, regardless of where the statistics are being collected.

Collection and StorageIf nothing else, the RMON agents and SLM tools should support standardized information collection and storageservices, allowing the agents to be queried by the SLM platform consistently. Fortunately, standards exist forthese services and are widely supported, although not to the same extent by all vendors.

25

Agent Polling and Sending ServicesInformation about the network is collected by the RMON agent periodically, according to the specific MIBs inuse. For example, a DSU with RMON capability collects numerous statistics on the status of the frame relaynetwork as well as protocol information. Once this data is collected, it must be made available to the centralNetwork Management System (NMS). This can be achieved by either having the NMS poll the agentperiodically, 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-peaktimes, allowing for historical analysis without loading down the network. However, this only works when thenetwork 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 beable to store at least 24 hours of activity in memory, providing access to details during periods of unavailability.

ReportingOnce RMON data has been collected by the NMS, it needs to be consolidated and reported in a format that isuseful to the network management personnel. In many cases, this data will come from hundreds or eventhousands 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 bymany service providers for this reason. RMON agents that are designed around industry-standard MIBs and thatsupport 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 theframe relay network in particular, since outside factors can negatively affect a WAN more severely thanissues with the WAN itself.

Service-Level Management involves all layers of the protocol stack, from the physical layer to theapplication layer, and includes LAN and WAN resources alike.

26

Chapter 6 Sourcebook In ReviewThis Sourcebook has attempted to cover a wide variety of topics as clearly as possible, enabling network personnel tounderstand the issues surrounding effective monitoring and management of frame relay networks. We have coveredtopics 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 theoutsourced nature of the technology, effective and proactive management is more important than with any otherWAN technology. However, this does not mean that you should avoid frame relay networks. Instead, you shouldview 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 youwith a set of tools, services and reports that offers a deep level of detail about the kinds of traffic in use on yournetwork. 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 andutilization

27

Chapter 7 SNMP Overview

The Simple Network Management Protocol (SNMP) is a protocol for Internet network management services. It isformally specified in a series of related RFC documents. SNMP is used by most LAN and WAN equipment vendorsas the preferred method of network management communications.

RFCs Relevant to SNMPRFC 1089 SNMP over EthernetRFC 1140 IAB official protocol standardsRFC 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 InternetsRFC 1156 Management Information Base (MIB) network management of TCP/IP-based InternetsRFC 1157 An SNMPRFC 1158 MIB network management of TCP/IP-based Internets: MIB-IIRFC 1161 (H) - SNMP over OSIRFC 1187 Bulk table retrieval with SNMPRFC 1212 Concise MIB definitionsRFC 1213 MIB for network management of TCP/IP-based Internets: MIB-IIRFC 1215 (I) - A convention for defining traps for use with SNMPRFC 1224 Techniques for managing asynchronously generated alertsRFC 1270 (I) - SNMP communication servicesRFC 1303 (I) - A convention for describing SNMP-based agentsRFC 1470 (I) - A network management tool catalogRFC 1298 SNMP over IPX (obsolete, see RFC 1420)RFC 1418 SNMP over OSIRFC 1419 SNMP over AppleTalkRFC 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 manageddevices. 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

28

Chapter 8 RMON Overview

In 1992, the Remote Network Monitoring Management Information Base was published as RFC 1271, an extensionto MIB-II, and immediately dubbed the RMON MIB. This RFC has since been superseded by RFC 1757 and RFC1513. The RMON MIBs contain the tools that a network management station needs to configure and control amonitor, 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 isspecified in RFC 1757 and RFC 1513, and is capable of providing information on Layer 1 and Layer 2 of the OSImodel. RMON 2 is specified in RFC 2021 and is capable of providing information on Layer 3 through Layer 7 of theOSI 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.

29

Chapter 9 About FrameSaver SLVParadynes FrameSaver SLV family of products are designed specifically to help customers and service providerswith the challenges of frame relay service-level management. The FrameSaver SLV system provides all the toolsnecessary to ensure accurate service level verification and monitoring of the frame relay network as well as trueenterprise-wide service-level management addressed in Chapter 5 of this sourcebook.

Product OverviewFrameSaver SLV (Service Level Verifier) is the latest addition to Paradynes FrameSaver family of frame relay accessproducts. FrameSaver SLV combines Paradyne's award-winning frame aware diagnostics and QoS features withNetScout'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, protocoldistribution, plus data collection and monitoring in a RMON 2 standard format. This extends FrameSaver SLV'smonitoring capability beyond the frame relay network layer (Layer 2) to incorporate Layer 3 which identifies theprotocols 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 inRMON 2 buckets for periodic retrieval on a network-wide basis. These statistics can also be accessed in real timeto help troubleshoot and "drill down" on specific network problems. In addition, various thresholds can be set in eachFrameSaver SLV to alarm on specific network conditions. For example, when a Service Level Agreement parametersuch as network latency or throughput at a particular location is, or is about to be, exceeded. Other solutions on themarket monitor network statistics but don't provide the rich set of diagnostic, test, and optimization features found inthe FrameSaver family. An entirely new set of Intelligent Service Level Verification features have been developed thatcan accurately analyze instantaneous burst and dropped packets that typically are "masked" by the conventionalaveraging techniques found in competing solutions. Continuous latency testing rounds out the SLV performanceimprovements.

FrameSaver SLV incorporates a robust set of Service-Level Management features targeted specifically atConnectivity Assurance, Service Level Verification and Analysis, and Application Performance Assurance. Thesefeatures include non-disruptive PVC loopbacks, router independent management connectivity, and a comprehensiveset of performance monitoring graphs to facilitate troubleshooting. Users can rapidly pinpoint the source of troubleindicated by the monitoring tools and dispatch or even affect the appropriate fix remotely. This emphasis on rapidReturn 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 applicationwarrants, include standalone NetScout probes. Together these three components (DSUs, NMS applications andstandalone probes) provide you with the ultimate flexibility in meeting your customers current or futurerequirements.

FrameSaver SLV Features and BenefitsFeatures Benefits

Full featured 56/64K and T1/FT1 DSU/CSUsoptimized for frame relay access

Offers the flexibility of supporting all accessrequirements from 56K to fractional and full T1.

Extensive SNMP Management, standard MIBs suchas MIB II, Frame Relay and RMON, plus EnterpriseMIBs

Allows management of different devices under a singleStandards Based platform, such as HP OpenView.Paradynes OpenLane applications add the ability totake full advantage of the total solution offered.

30

Features BenefitsFrame Relay aware management including:

- Router independent remote SNMP management

- Shared or dedicated PVC connectivity with LMIspoofing

- Extensive PVC diagnostic, loopback and patterntests

Allows you to communicate to your remote unitwithout having to depend on the Router. Eliminates theneed to purchase special PVCs, cables, LAN adaptersor router ports. Return-to-service connectivityassurance tools identify the cause of network problemsquickly and minimize downtime.

Intelligent data delivery, latency and burst analyzerfeatures

Intelligent performance monitoring enables accurateinformation for network service level analysis andverification.

Single V.35 data port with standard connector No adapter cable or unique cable required to connect toyour DTE equipment.

RMON 2-based Layer 1 to 3 performance monitoringand data collection. Physical, logical and RMONstatistics stored for 24 hours in 15-minute intervals anddaily totals for 5 days.

Provides information required to manage theperformance of their network. RMON-based datacollection and service level reporting provide efficientand economical monitoring of vital frame serviceparameters.

Telnet and ASCII User Interface with passwordprotection

Provides a separate direct connection to the unitthrough an ASCII terminal, modem or over the SNMPlink. This allows the user to configure and test the unitindependent of their NMS system.

Easy installation with automatic configuration Auto configuration and router independent managementreduce installation time, complexity and expense.

DSX-1 port on 9124 for consolidating PBX voicetraffic

DSX-1 drop and insert port allows consolidating ofPBX voice traffic reducing network access costs.

Dual flash storage areas and in-band FTP softwaredownload

Modular architecture and software downloadabilityprotects investments and reduces life-cycle costs.

2-year, return to factory warranty Peace-of-mind and evidence of product quality.

ComponentsThe FrameSaver SLV family includes three components; Frame Aware DSUs, NetScout probes and OpenLanemanagement applications. While it is expected that every installation will include numerous access units and anOpenLane management system, a limited number will also require standalone probes. Following is a brief descriptionof the FrameSaver SLV components.

Frame Aware DSUsTwo Frame Aware DSUs are available: the FrameSaver SLV 9624 for 56/64K applications and the 9124 for T1/FT1applications. Each combines Paradynes industry leading DSU technology and patented frame relay managementcapabilities with RMON agent-based performance monitoring from NetScout to deliver the industrys best framerelay access product. They provide network service providers and end-user customers a comprehensive set of toolsdesigned to monitor and ensure frame relay network service levels.

FrameSaver SLVs intelligent verification features proactively monitor key service parameters and collect the detailedinformation required to accurately monitor service levels as well as to identify the cause of missed agreements. Theyinclude extensive RMON-based performance monitoring capabilities that capture Layer 1, 2, and 3 statistics required

31

to monitor network utilization, identify problems, optimize performance and perform long-term planning. Statisticsare stored in RMON 2 User History buckets for periodic collection and are also accessible in real time to helptroubleshoot and drill down on specific network problems. In addition, thresholds can be set to proactively monitorand alarm on specific conditions such as over or under utilization or excessive network latency. This, combined withphysical and logical PVC-based management and router independent SNMP connectivity rapidly pinpoints thesource of trouble maximizing network availability.

FIGURE 21FrameSaver SLV 9624

The FrameSaver SLV 9624 is a single-port (native V.35) 56/64K DSU that is optimized for frame relay access. Withsupport for up to three PVCs, it is ideal for small branch locations.

FIGURE 22FrameSaver SLV 9124

The FrameSaver SLV 9124 is a frame relay optimized T1/FT1 DSU/CSU that has one data port (native V.35) and aDSX-1 drop and insert port for voice traffic. The PVC capacity is up to 64 (making this an ideal product for branchand small-to-medium sized regional/central sites.

OpenLane ManagementLike all Paradyne SNMP-managed devices, the OpenLane DCE Manager and Performance Wizard manageFrameSaver SLV. In addition, NetScout Manager Plus application software will be used as part of the OpenLanemanagement solution to manage FrameSaver SLV components. Specifically, NetScout Manager Plus is used tomanage the Layer 3 capabilities (Top talkers, Protocol distribution and RMON storage buckets). NetScout ManagerPlus is also used to manage standalone NetScout probes that are provided as part of the FrameSaver solution.

32

NetScout ProbesSelected NetScout WAN and LAN/WAN probes are available for resale through Paradyne to meet specializedmonitoring and diagnostic requirements that cannot be satisfied by FrameSaver access units alone. NetScout probescontinuously monitor up to Layer 7 on network LANs and/or WANs to gather data on traffic protocols, applicationsand users. They provide the end-to-end monitoring to simplify troubleshooting and capacity planning. NetScoutprobes not only monitor network traffic, but can also be customized to monitor an application regardless of itstopology or protocol.

FIGURE 23LAN / WAN Probes

ApplicationsFrameSaver SLV has been specifically designed for frame relay access. In a typical application, FrameSaver SLVaccess units are installed at each location. This will provide network service level verification/analysis, protocolperformance monitoring and connectivity assurance for every physical and logical (PVC) circuit in the network. Thiswill meet the needs of the majority of customers and is ideal for star and mesh network topologies.

FIGURE 24FrameSaver SLV Application

33

End-to-end enterprise wide Application Performance Assurance requires a higher level of monitoring than thatprovided by the FrameSaver SLV access units. To meet this need, a NetScout probe may be installed in conjunctionwith the FrameSaver device at one or more locations. The FrameSaver SLV devices provide Layers 1, 2, and 3monitoring, plus physical and logical PVC monitoring and connectivity assurance (e.g., initiating alarms on loss of acircuit or PVC), Intelligent Verification and Frame Relay Aware diagnostics. The NetScout probe will provide fullLayer 7 application performance assurance monitoring of either the WAN segment or both the WAN and LAN. Inaddition, a probe will provide advanced packet capture and decode capabilities and has greater storage capacity. Forexample, a FrameSaver SLV access unit can monitor up to seven protocols and six IP top talkers at one time, while astandalone probe can monitor an unlimited number making it a viable addition for large specialized situations. Thisapplication is ideally suited for star network topologies that will only require a limited number of probes at regional orcentral sites.

FIGURE 25FrameSaver SLV Plus NetScout Probe Application

Network ManagementThe 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 (oremulation). The terminal can be locally connected or remotely connected (via external modem) to the COMPort. Three levels of access security with password protection are available.

TELNET Access to the ASCII Terminal InterfaceThe 9x24 products support TELNET connections to the menu-driven ATI via the IP management link.

SNMP ManagementBecause of their advanced diagnostics and RMON features, FrameSaver SLV devices will typically bemanageable by an SNMP NMS. Adherence to standards such as SNMP and RMON not only allows thecustomer to take advantage of Paradyne OpenLane applications, but also to leverage investments they have madein other standards-based applications, such as, Concord Network Health. The FrameSaver products supportmultiple SNMP community strings and multiple authorized managers, allowing the most flexible NMS solutionavailable today. For example, an NSP can monitor and manage a complete FrameSaver network whileindividual ISPs could monitor and manage only their portion of the network.

34

OpenLane Management ApplicationsThe FrameSaver SLV products offer robust network management as a key differentiator to competitive systems. TheFrameSaver products are managed by Paradynes pre-eminent network management solution, which includes theDCE 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 isPerformance Wizard, an advanced performance management application providing real-time and historical datacollection and graphing capabilities.

Some of the advanced functionality provided by the DCE Manager application includes:

Device DisplayProvides a real-time graphical representation of the device. The display presents color-coded icons that identifythe operational and administrative status of all interface ports (e.g., interface is up, down, in test, etc.) Thisdisplay also serves as a primary interface for all DCE Manager functionality.

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

StatusDevice status commands display operational status of the device and its interfaces. Port status displays detailedalarm, test and operating status for a selected interface.

DiagnosticsA set of intuitive graphical commands used to initiate loopback, test patterns, and monitor the results.

OptionsDisplays the current configuration of a device or interface. Device and interface options can also be changed orset from this display.

Enhanced Trap ProcessingEnhances the base platforms ability to process, correlate, and display traps. This feature also ensures that thenetwork map icons accurately reflect the alarm status of the managed devices.

Help-On-LineContext-sensitive help for all DCE Manager functions.

The OpenLane Performance Wizard adds real-time and historical performance reports for the FrameSaver productline. 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 ofservice 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, a