Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3202

Definitions of Managed Objects for Frame Relay Service Level Definitions

Pages: 64
Proposed Standard
Updated by:  9141
Part 1 of 3 – Pages 1 to 24
None   None   Next

Top   ToC   RFC3202 - Page 1
Network Working Group                                     R. Steinberger
Request for Comments: 3202                             Paradyne Networks
Category: Standards Track                                    O. Nicklass
                                            RAD Data Communications Ltd.
                                                            January 2002


                     Definitions of Managed Objects
               for Frame Relay Service Level Definitions

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

This memo defines an extension of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the Frame Relay Service Level Definitions.

Table of Contents

1. The SNMP Management Framework ............................... 2 2. Conventions ................................................. 3 3. Overview .................................................... 3 3.1. Frame Relay Service Level Definitions ..................... 4 3.2. Terminology ............................................... 5 3.3. Network Model ............................................. 5 3.4. Reference Points .......................................... 6 3.5. Measurement Methodology ................................... 8 3.6. Theory of Operation ....................................... 9 3.6.1. Capabilities Discovery .................................. 9 3.6.2. Determining Reference Points for Row Creation ........... 10 3.6.2.1. Graphical Examples of Reference Points ................ 11 3.6.2.1.1. Edge-to-Edge Interface Reference Point Example ...... 12 3.6.2.1.2. Edge-to-Edge Egress Queue Reference Point Example ... 13 3.6.2.1.3. End-to-End Using Reference Point Example ............ 14 3.6.3. Creation Process ........................................ 15 3.6.4. Destruction Process ..................................... 15
Top   ToC   RFC3202 - Page 2
   3.6.4.1. Manual Row Destruction ................................   15
   3.6.4.2. Automatic Row Destruction .............................   16
   3.6.5. Modification Process ....................................   16
   3.6.6. Collection Process ......................................   16
   3.6.6.1. Remote Polling ........................................   16
   3.6.6.2. Sampling ..............................................   17
   3.6.6.3. User History ..........................................   17
   3.6.7. Use of MIB Module in Calculation of Service Level
   Definitions ....................................................   17
   3.6.8. Delay ...................................................   20
   3.6.9. Frame Delivery Ratio ....................................   20
   3.6.10. Data Delivery Ratio ....................................   21
   3.6.11. Service Availability ...................................   21
   4. Relation to Other MIB Modules ...............................   22
   5. Structure of the MIB Module .................................   23
   5.1. frsldPvcCtrlTable .........................................   23
   5.2. frsldSmplCtrlTable ........................................   23
   5.3. frsldPvcDataTable .........................................   23
   5.4. frsldPvcSampleTable .......................................   24
   5.5. frsldCapabilities .........................................   24
   6. Persistence of Data .........................................   24
   7. Object Definitions ..........................................   24
   8. Acknowledgments .............................................   61
   9. References ..................................................   61
   10. Security Considerations ....................................   63
   11. Authors' Addresses .........................................   63
   12. Full Copyright Statement ...................................   64

1. The SNMP Management Framework

The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2571 [1]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4]. The second version, called SMIv2, is described in STD 58, RFC 2578 [5], RFC 2579 [6] and RFC 2580 [7]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [8]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [9] and RFC
Top   ToC   RFC3202 - Page 3
      1906 [10].  The third version of the message protocol is called
      SNMPv3 and described in RFC 1906 [10], RFC 2572 [11] and RFC 2574
      [12].

   o  Protocol operations for accessing management information.  The
      first set of protocol operations and associated PDU formats is
      described in STD 15, RFC 1157 [8].  A second set of protocol
      operations and associated PDU formats is described in RFC 1905
      [13].

   o  A set of fundamental applications described in RFC 2573 [14] and
      the view-based access control mechanism described in RFC 2575
      [15].

   A more detailed introduction to the current SNMP Management Framework
   can be found in RFC 2570 [16].

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  Objects in the MIB are
   defined using the mechanisms defined in the SMI.

   This memo specifies a MIB module that is compliant to the SMIv2.  A
   MIB conforming to the SMIv1 can be produced through the appropriate
   translations.  The resulting translated MIB must be semantically
   equivalent, except where objects or events are omitted because no
   translation is possible (use of Counter64).  Some machine readable
   information in SMIv2 will be converted into textual descriptions in
   SMIv1 during the translation process.  However, this loss of machine
   readable information is not considered to change the semantics of the
   MIB.

2. Conventions

The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC 2119 [22].

3. Overview

This MIB module addresses the items required to manage the Frame Relay Forum's Implementation Agreement for Service Level Definitions (FRF.13 [17]). At present, this applies to these values of the ifType variable in the Internet-standard MIB: o frameRelay (32) o frameRelayService (44)
Top   ToC   RFC3202 - Page 4
   This section provides an overview and background of how to use this
   MIB module.

3.1. Frame Relay Service Level Definitions

The frame relay service level definitions address specific characteristics of a frame relay service that can be used to facilitate the following tasks: o Evaluation of frame relay service providers, offerings or products. o Measurement of Quality of Service. o Enforcement of Service Level Agreements. o Planning or describing a frame relay network. The following parameters are defined in FRF.13 [17] as a sufficient set of values to accomplish the tasks previously stated. o Delay - The amount of time elapsed, in microseconds, from the time a frame exits the source to the time it reaches the destination. NOTE: FRF.13 [17] defines this value in terms of milliseconds. o Frame Delivery Ratio - The ratio of the number of frames delivered to the destination versus the number of frames sent by the source. This ratio can be further divided by inspecting either only the frames within the CIR or only the frames in excess of the CIR. o Data Delivery Ratio - The ratio of the amount of data delivered to the destination versus the amount of data sent by the source. This ratio can be further divided by inspecting either only the data within the CIR or only the data in excess of the CIR. o Service Availability - The amount of time the frame relay service was not available. There are three types of availability statistics defined in FRF.13 [17]: Mean Time to Repair, Virtual Connection Availability, and Mean Time Between Service Outages. The later two require information about the scheduled outage time. It is assumed that scheduled outage time information will be maintained by the network management software, so it is not included in the MIB module. Consult FRF.13 [17] for more details.
Top   ToC   RFC3202 - Page 5

3.2. Terminology

o CIR - The Committed Information Rate (CIR) is the subscriber data rate (expressed in bits/second) that the network commits to deliver under normal network conditions [18]. o DLCI - Data Link Connection Identifier [18]. o Logical Port - This term is used to model the Frame Relay "interface" on a device [18]. o NNI - Network to Network Interface [18]. o Permanent Virtual Connection (PVC) - A virtual connection that has its end-points and bearer capabilities defined at subscription time [18]. o Reference Point (RP) - The point of reference within the network model at which the calculations or data collection takes place. o UNI - User to Network Interface [18].

3.3. Network Model

The basic model, as illustrated in figure 1 below, contains two frame relay DTE endpoints connected to a network cloud via a frame relay UNI interface. The network cloud can contain zero or more internal frame relay NNI connections that interconnect multiple networks. The calculations and data collection can be performed at any reference point within the network. +-------------+ +-------------+ | Frame Relay | | Frame Relay | | DTE Device | | DTE Device | +------+------+ +------+------+ | | UNI UNI Connection Connection | | +------+------+ NNI +-------------+ NNI +------+------+ | Network A +------------+ Network B +------------+ Network C | +-------------+ Connection +-------------+ Connection +-------------+ Figure 1 Frame Relay Network Reference Model
Top   ToC   RFC3202 - Page 6

3.4. Reference Points

The collection and calculations of the service level definitions apply to two reference points within the network. These two points are the locations where the frames are referenced in the collection of the service level specific information. The reference points used in the MIB module are shown in figure 2 below. For completeness, the module also allows for proprietary reference points which MAY exist anywhere in the network that is not a previously defined reference point. The meaning of the proprietary reference points is insignificant unless defined by the device manufacturer.
Top   ToC   RFC3202 - Page 7
      +---------------------------+
      |+-----------+ +-----------+|
      ||           | |Measurement||
      ||Frame Relay---Engine     --(Source RP)----+
      ||DTE        | |(If Exists)||               |
      |+-----------+ +-----------+|               |
      +---------------------------+               |
        Frame Relay Source                        |
       +------------------------------------------+
       |             Frame Relay Network
       |            +----------------------------------+
       |            | +------------------------------+ |
       |            | | +---------+ +---------+      | |
       |            | | |         | | Traffic |      | |
       +--(Ingress RP)--- L1 / L2 --- Policing|      | |
                    | | | Control | | Engine  |      | |
                    | | +---------+ +----|----+      | |
                    | |                  |           | |
                    | |         (Traffic Policing RP)| |
                    | +------------------|-----------+ |
                    |    Ingress Node    |             |
                    |                    |             |
                    |        +-----------|-----------+ |
                    |        |  Intermediate Nodes   | |
                    |        +-----------|-----------+ |
                    |                    |             |
                    |      Egress Node   |             |
                    |     +--------------|-----------+ |
                    |     | (Egress Queue Input RP)  | |
                    |     |              |           | |
                    |     |      +-------+------+    | |
                    |     |      | Egress Queue |    | |
                    |     |      +-------+------+    | |
                    |     |              |           | |
                    |     | (Egress Queue Output RP) | |
                    |     +--------------|-----------+ |
                    +--------------------|-------------+
         Frame Relay Destination         |
      +---------------------------+      +-----------+
      |+-----------+ +-----------+|                  |
      ||           | |Measurement||                  |
      ||Frame Relay---Engine     --(Destination RP)--+
      ||DTE        | |(If Exists)||
      |+-----------+ +-----------+|
      +---------------------------+

                                Figure 2
                     Reference Points (FRF.13 [17])
Top   ToC   RFC3202 - Page 8
   The MIB variables frsldPvcCtrlTransmitRP and frsldPvcCtrlReceiveRP
   allow the user to view and configure the reference points at which
   the calculations occur.  These variables are specific to the device
   on which they are located.  Frame relay devices act as both frame
   sources and frame destinations.  The definitions in this MIB module
   apply to the interaction of a pair of devices on the network path.
   The same device can potentially use different reference points for
   calculation and collection of the statistics based on whether the
   referenced frame is sent or received by the device.  When the device
   is acting as a frame source, the value of frsldPvcCtrlTransmitRP
   reflects the reference point used for all source calculations
   pertaining to the specified PVC.  When the device is acting as a
   frame destination, the value of frsldPvcCtrlReceiveRP reflects the
   reference point used for all destination calculations pertaining to
   the specified PVC.

   For example, FRF.13 [17] defines an Edge-to-Edge Egress Queue
   measurement domain as a domain in which measurement is performed
   between an Ingress Reference Point and an Egress Queue Input
   Reference Point.  For this domain between a source device and a
   destination device, the value of frsldPvcCtrlTransmitRP for the
   source device would be set to ingTxLocalRP(2) and the value of
   frsldPvcCtrlReceiveRP for the destination device would be set to
   eqiRxLocalRP(4).  While it is usually the case that the reference
   points would be equivalent on the remote device when monitoring
   frames going in the opposite direction, there is no requirement for
   them to be so.

   It can be seen from the above example that a total of four reference
   points are required in order to collect information for both
   directions of traffic flow.  The reference points represent the
   transmit and receive directions at both ends of a PVC.  If a device
   has knowledge of the information from the remote device, it is
   possible to collect the statistics from a single device.  This is not
   always the case.  In most instances, two devices will need to be
   monitored to capture a complete description of the service level on a
   PVC.  The reference points a single device is capable of monitoring
   are contained in the frsldRPCaps object.

3.5. Measurement Methodology

This document neither recommends nor suggests a method of implementation. This is left to the device manufacturer and should be independent of the data that is actually collected. Periodic collection of this data can be performed through either polling of the data table, use of the sample tables or use of the user history group of RFC 2021 [19].
Top   ToC   RFC3202 - Page 9

3.6. Theory of Operation

The following sections describe how to use this MIB module. They include row handling, data collection and data calculation. The recommendations here in are suggestions as to implementation and do not infer that they are the only method that can be used to perform such operations.

3.6.1. Capabilities Discovery

Three objects are provided specifically to aid the network manager in discovering the capabilities of the device with respect to this MIB module. o frsldPvcCtrlWriteCaps This object reports the write capabilities of the PVC Control Table. Use this object to determine which objects can be modified. This need only be referenced if row creation or modification is to be performed. o frsldSmplCtrlWriteCaps This object reports the write capabilities of the Sample Control Table. Use this object to determine which objects can be modified. The group need only be referenced if the sample tables will be used to collect historical information. o frsldRPCaps This object reports the reference points at which the device is capable of collecting information. This object needs to be referenced if row creation is to be performed in the PVC Control Table. Devices can only create rows containing supported reference points. These objects do not imply that there is no need for an Agent Capabilities macro for devices that do not fully support every object in this MIB module. They are provided specifically to aid in the ensured network management operations of this MIB module with respect to row creation and modification. An additional four objects are provided to report and control memory the utilization of this MIB module. These objects are frsldMaxPvcCtrls, frsldNumPvcCtrls, frsldMaxSmplCtrls are frsldNumSmplCtrls. Together, they allow a manager to control the
Top   ToC   RFC3202 - Page 10
   amount of memory allocated for specific utilization by this MIB
   module.  This is done by setting the maximum allowed allocation of
   controls.

3.6.2. Determining Reference Points for Row Creation

The performance of a PVC is monitored by evaluating the uni- directional flow of frames from an ingress point to an egress point. Reference points describe where each of the two measurements are made. Monitoring both of the uni-directional flows that make-up the PVC frame traffic requires a total of four reference points as shown in Figures 3 through 5. A monitoring point that evaluates traffic is restricted to counting frames that pass the reference points hosted locally on the monitoring point. Thus, if the monitoring point is near the ingress point of the flow, it will count the frames entering into the frame relay network. The complete picture of frame loss for the uni-directional flow requires information from the downstream reference point located at another (remote) monitoring point. The local monitoring point MAY be implemented in such way that the information from the downstream monitoring point is moved to the local monitoring point using implementation-specific mechanisms. In this case all information required to calculate frame loss becomes available from the local measurement point. The local measurement point agent is capable of reporting all the objects in the FrsldPvcDataEntry row - the counts for offered frames entering the network and delivered frames exiting the network. Alternatively, the local monitoring point MAY be restricted to counts of frames observed on the local device only. In this case, the objects of the FrsldPvcDataEntry row reporting what happened on the remote device are not available. The following list shows the possible valid reference points for an FRF.13 SLA from the source reference point to the destination reference point in both directions. o Local Information Only Local Device: srcLocalRP, desLocalRP Remote Device: srcLocalRP, desLocalRP o Remote Information Only Local Device: srcRemoteRP, desRemoteRP Remote Device: srcRemoteRP, desRemoteRP
Top   ToC   RFC3202 - Page 11
   o  Mixed Two Device Model 1 (Local Device Always Transmitter)

         Local Device:  srcLocalRP, desRemoteRP
         Remote Device: srcLocalRP, desRemoteRP

   o  Mixed Two Device Model 2 (Local Device Always Receiver)

         Local Device:  srcRemoteRP, desLocalRP
         Remote Device: srcRemoteRP, desLocalRP

   o  Mixed One Device Model 1 (Directional Rows)

         First Row:  srcRemoteRP, desLocalRP (Receiver Row)
         Second Row: srcLocalRP, desRemoteRP (Sender Row)

   o  Mixed One Device Model 2 (Device Based Rows)

         First Row:  srcLocalRP, desLocalRP (Local Row)
         Second Row: srcRemoteRP, desRemoteRP (Remote Row)

   Each of the above combinations is valid and provides the same
   information.

   The following steps are recommended to find which reference points
   need to be configured:

   1) Locate both of the devices at either end of the PVC to be
      monitored.

   2) Determine the capabilities by referencing the frsldRPCaps object
      of each device.

   3) Locate the best combination of the two devices such that the
      necessary reference points are all represented.

   4) If any one of the necessary reference points does not exist in the
      combination of the two devices, it is not possible to monitor the
      FRF.13 defined SLA between the two reference point on the PVC.

3.6.2.1. Graphical Examples of Reference Points
FRF.13 [17] defines three specific combinations of reference points: Edge-to-Edge Interface, Edge-to-Edge Egress Queue and End-to-End. Examples of valid reference points that may be used for each of these are discussed in the sections below.
Top   ToC   RFC3202 - Page 12
   It is often the case that a device knows as a minimum either only
   local information or both local and remote information.  Because
   these are two common examples, each will be illustrated below.

3.6.2.1.1. Edge-to-Edge Interface Reference Point Example
Device 1 Device 2 +-------------+ +-------------+ | Ingress | | Egress | | +-----+ | | +-----+ | |(A)| | | Traffic Flow | | |(B)| -->-->-- -->-->-->-->-->-->-->-->-->-->-->- -->-->--> | | | | From Device 1 to 2 | | | | | +-----+ | | +-----+ | | | | | | Egress | | Ingress | | +-----+ | | +-----+ | |(D)| | | Traffic Flow | | |(C)| <--<--<- -<--<--<--<--<--<--<--<--<--<--<-- --<--<-- | | | | From Device 2 to 1 | | | | | +-----+ | | +-----+ | +-------------+ +-------------+ where (A), (B), (C) and (D) are reference points Figure 3 For devices with only local knowledge, one row is required on each device as follows: (A) frsldPvcCtrlTransmitRP for Device 1 = ingTxLocalRP(2) (B) frsldPvcCtlrReceiveRP for Device 2 = eqoRxLocalRP(5) (C) frsldPvcCtrlTransmitRP for Device 2 = ingTxLocalRP(2) (D) frsldPvcCtlrReceiveRP for Device 1 = eqoRxLocalRP(5) In which a single row is created on Device 1 containing reference points (A) and (D), and a single row is created on Device 2 containing reference points (C) and (B). For devices with both local and remote knowledge, the two rows can exist in any combination on either device. For this example, the transmitting devices will be responsible for information regarding the flow for which they are the origin. Only one row is required per device for this example.
Top   ToC   RFC3202 - Page 13
   (A) frsldPvcCtrlTransmitRP for Device 1 = ingTxLocalRP(2)

   (B) frsldPvcCtlrReceiveRP for Device 1 = eqoRxRemoteRP(11)

   (C) frsldPvcCtrlTransmitRP for Device 2 = ingTxLocalRP(2)

   (D) frsldPvcCtlrReceiveRP for Device 2 = eqoRxRemoteRP(11)

3.6.2.1.2. Edge-to-Edge Egress Queue Reference Point Example
Device 1 Device 2 +-------------+ +-------------+ | Ingress | | Egress | | +-----+ | | +-----+ | |(A)| | | Traffic Flow |(B)| | | -->-->-- -->-->-->-->-->-->-->-->-->-->-->- -->-->--> | | | | From Device 1 to 2 | | | | | +-----+ | | +-----+ | | | | | | Egress | | Ingress | | +-----+ | | +-----+ | | | |(D)| Traffic Flow | | |(C)| <--<--<- -<--<--<--<--<--<--<--<--<--<--<-- --<--<-- | | | | From Device 2 to 1 | | | | | +-----+ | | +-----+ | +-------------+ +-------------+ where (A), (B), (C) and (D) are reference points Figure 4 For devices with only local knowledge, one row is required on each device as follows: (A) frsldPvcCtrlTransmitRP for Device 1 = ingTxLocalRP(2) (B) frsldPvcCtlrReceiveRP for Device 2 = eqiRxLocalRP(4) (C) frsldPvcCtrlTransmitRP for Device 2 = ingTxLocalRP(2) (D) frsldPvcCtlrReceiveRP for Device 1 = eqiRxLocalRP(4) In which a single row is created on Device 1 containing reference points (A) and (D), and a single row is created on Device 2 containing reference points (C) and (B).
Top   ToC   RFC3202 - Page 14
   For devices with both local and remote knowledge, the two rows can
   exist in any combination on either device.  For this example, the
   transmitting devices will be responsible for information regarding
   the flow for which they are the origin.  Only one row is required per
   device for this example.

   (A) frsldPvcCtrlTransmitRP for Device 1 = ingTxLocalRP(2)

   (B) frsldPvcCtlrReceiveRP for Device 1 = eqiRxRemoteRP(10)

   (C) frsldPvcCtrlTransmitRP for Device 2 = ingTxLocalRP(2)

   (D) frsldPvcCtlrReceiveRP for Device 2 = eqiRxRemoteRP(10)

3.6.2.1.3. End-to-End Using Reference Point Example
Device 1 Device 2 +-------------+ +-------------+ | Source | | Destination | | +-----+ | | +-----+ | |(A)| | | Traffic Flow | | |(B)| -->-->-- -->-->-->-->-->-->-->-->-->-->-->- -->-->--> | | | | From Device 1 to 2 | | | | | +-----+ | | +-----+ | | | | | | Destination | | Source | | +-----+ | | +-----+ | |(D)| | | Traffic Flow | | |(C)| <--<--<- -<--<--<--<--<--<--<--<--<--<--<-- --<--<-- | | | | From Device 2 to 1 | | | | | +-----+ | | +-----+ | +-------------+ +-------------+ where (A), (B), (C) and (D) are reference points Figure 5 For devices with only local knowledge, one row is required on each device as follows: (A) frsldPvcCtrlTransmitRP for Device 1 = srcLocalRP(1) (B) frsldPvcCtlrReceiveRP for Device 2 = desLocalRP(1) (C) frsldPvcCtrlTransmitRP for Device 2 = srcLocalRP(1) (D) frsldPvcCtlrReceiveRP for Device 1 = desLocalRP(1)
Top   ToC   RFC3202 - Page 15
   In which a single row is created on Device 1 containing reference
   points (A) and (D), and a single row is created on Device 2
   containing reference points (C) and (B).

   For devices with both local and remote knowledge, the two rows can
   exist in any combination on either device.  For this example, the
   transmitting devices will be responsible for information regarding
   the flow for which they are the origin.  Only one row is required per
   device for this example.

   (A) frsldPvcCtrlTransmitRP for Device 1 = srcLocalRP(1)

   (B) frsldPvcCtlrReceiveRP for Device 1 = desRemoteRP(7)

   (C) frsldPvcCtrlTransmitRP for Device 2 = srcLocalRP(1)

   (D) frsldPvcCtlrReceiveRP for Device 2 = desRemoteRP(7)

3.6.3. Creation Process

In some cases, devices will automatically populate the rows of PVC Control Table and potentially the Sample Control Table. However, in many cases, it may be necessary for a network manager to manually create rows. Manual creation of rows requires the following steps: 1) Ensure the PVC exists between the two devices. 2) Determine the necessary reference points for row creation. 3) Create the row(s) in each device as needed. 4) Create the row(s) in the sample control tables if desired.

3.6.4. Destruction Process

3.6.4.1. Manual Row Destruction
Manual row destruction is straight forward. Any row can be destroyed and the resources allocated to it are freed by setting the value of its status object (either frsldPvcCtrlStatus or frsldSmplCtrlStatus) to destroy(6). It should be noted that when frsldPvcCtrlStatus is set to destroy(6) all associated sample control, sample and data table rows will also be destroyed. Similarly, when frsldSmplCtrlStatus is set to destroy(6) all sample rows will also be
Top   ToC   RFC3202 - Page 16
   destroyed.  The frsldPvcCtrlPurge objects do not apply to manual row
   destruction.  If the row is set to destroy(6) manually, the rows are
   destroyed as part of the set.

3.6.4.2. Automatic Row Destruction
Rows is the tables may be destroyed automatically based on the existence of the DLCI on which they rely. This behavior is controlled by the frsldPvcCtrlPurge and frsldPvcCtrlDeleteOnPurge objects. When a DLCI no longer exists in the device, the data in the tables has no relation to anything known on the network. However, there may be some need to keep the historic information active for a short period after the destruction or removal of a DLCI. If the basis for the row no longer exists, the row will be destroyed at the end of the purge interval that is controlled by frsldPvcCtrlPurge. The effects of automatic row destruction are the same as manual row destruction.

3.6.5. Modification Process

All read-create items in this MIB module can be modified at any time if they are fully supported. Write access is not required. To simplify the use of the MIB frsldPvcCtrlWriteCaps and frsldSmplCtrlWriteCaps state which of the read-create variables can actually be written on a particular device.

3.6.6. Collection Process

3.6.6.1. Remote Polling
This MIB module supports data collection through remote polling of the free running counters in the PVC Data Table. Remote polling is a common method used to capture real-time statistics. A remote management station polls the device to collect the desired information. It is recommended all statistics for a single PVC be collected in a single PDU. The following objects are designed around the concept of real-time polling: o frsldPvcDataMissedPolls o frsldPvcDataFrDeliveredC o frsldPvcDataFrDeliveredE o frsldPvcDataFrOfferedC o frsldPvcDataFrOfferedE o frsldPvcDataDataDeliveredC o frsldPvcDataDataDeliveredE
Top   ToC   RFC3202 - Page 17
   o  frsldPvcDataDataOfferedC
   o  frsldPvcDataDataOfferedE
   o  frsldPvcDataHCFrDeliveredC
   o  frsldPvcDataHCFrDeliveredE
   o  frsldPvcDataHCFrOfferedC
   o  frsldPvcDataHCFrOfferedE
   o  frsldPvcDataHCDataDeliveredC
   o  frsldPvcDataHCDataDeliveredE
   o  frsldPvcDataHCDataOfferedC
   o  frsldPvcDataHCDataOfferedE
   o  frsldPvcDataUnavailableTime
   o  frsldPvcDataUnavailables

3.6.6.2. Sampling
The sample tables provide the ability to historically sample data without requiring the additional overhead of polling. At key periods, a network management station can collect the samples needed. This method allows the manager to perform the collection of data at times that will least affect the active network traffic. The sample data can be collected using a series of SNMP getNext or getBulk operations. The value of frsldPvcSmplIdx increments with each new collection bucket. This allows the managers to skip information that has already been collected. However, care should be taken in that the value can roll over after a long period of time. The start and end times of a collection period allow the manager to know what the actual period of collection was. It is possible for there to be discontinuities in the sample table, so both start and end should be referenced.
3.6.6.3. User History
User history, as defined in RFC 2021 [19], is an alternative mechanism that can be used to get the same benefits as the sample table by using the objects provided for real-time polling. Some devices MAY have the ability to use user history and opt not to support the sample tables. If this is the case, the information from the data table can be used to define a group of user history objects.

3.6.7. Use of MIB Module in Calculation of Service Level Definitions

The objects in this MIB module can be used to calculate the statistics defined in FRF.13 [17]. The description below describes the calculations for one direction of the data flow, i.e., data sent from local transmitter to a remote receiver. A complete set of bidirectional information would require calculations based on both
Top   ToC   RFC3202 - Page 18
   directions.  For the purposes of this description, the reference
   points used SHOULD consistently represent data that is sent by one
   device and received by the other.

   A complete evaluation requires the combination of two uni-directional
   flows.  It is possible for a management station to combine all of the
   calculated information into one conceptual row.  Doing this requires
   that each of the metrics are collected for both flow directions and
   grouped by direction  If the information is split between two
   devices, the management station must know which two devices to
   communicate with for the collection of all information.  The grouping
   of information SHOULD be from ingress to egress in each flow
   direction.

   The calculations below use the following terminology:

   o  DelayAvg

         The average delay on the PVC.  This is represented within the
         MIB module by frsldPvcSmplDelayAvg.

   o  FrDeliveredC

         The number of frames received by the receiving device through
         the receive reference point that were delivered within CIR.
         This is represented within the MIB module by one of
         frsldPvcDataFrDeliveredC, frsldPvcDataHCFrDeliveredC,
         frsldPvcSmplFrDeliveredC, or frsldPvcSmplHCFrDeliveredC.

   o  FrDeliveredE

         The number of frames received by the receiving device through
         the receive reference point that were delivered in excess of
         CIR.  This is represented within the MIB module by one of
         frsldPvcDataFrDeliveredE, frsldPvcDataHCFrDeliveredE,
         frsldPvcSmplFrDeliveredE, or frsldPvcSmplHCFrDeliveredE.

   o  FrOfferedC

         The number of frames offered by the transmitting device through
         the transmit reference point that were sent within CIR.  This
         is represented within the MIB module by one of
         frsldPvcDataFrOfferedC, frsldPvcDataHCFrOfferedC,
         frsldPvcSmplFrOfferedC, or frsldPvcSmplHCFrOfferedC.
Top   ToC   RFC3202 - Page 19
   o  FrOfferedE

         The number of frames offered by the transmitting device through
         the transmit reference point that were sent in excess of CIR.
         This is represented within the MIB module by one of
         frsldPvcDataFrOfferedE, frsldPvcDataHCFrOfferedE,
         frsldPvcSmplFrOfferedE, or frsldPvcSmplHCFrOfferedE.

   o  DataDeliveredC

         The number of octets received by the receiving device through
         the receive reference point that were delivered within CIR.
         This is represented within the MIB module by one of
         frsldPvcDataDataDeliveredC, frsldPvcDataHCDataDeliveredC,
         frsldPvcSmplDataDeliveredC, or frsldPvcSmplHCDataDeliveredC.

   o  DataDeliveredE

         The number of octets received by the receiving device through
         the receive reference point that were delivered in excess of
         CIR.  This is represented within the MIB module by one of
         frsldPvcDataDataDeliveredE, frsldPvcDataHCDataDeliveredE,
         frsldPvcSmplDataDeliveredE, or frsldPvcSmplHCDataDeliveredE.

   o  DataOfferedC

         The number of octets offered by the transmitting device through
         the transmit reference point that were sent within CIR.  This
         is represented within the MIB module by one of
         frsldPvcDataDataOfferedC, frsldPvcDataHCDataOfferedC,
         frsldPvcSmplDataOfferedC, or frsldPvcSmplHCDataOfferedC.

   o  DataOfferedE

         The number of octets offered by the transmitting device through
         the transmit reference point that were sent in excess of CIR.
         This is represented within the MIB module by one of
         frsldPvcDataDataOfferedE, frsldPvcDataHCDataOfferedE,
         frsldPvcSmplDataOfferedE, or frsldPvcSmplHCDataOfferedE.

   o  UnavailableTime

         The amount of time the PVC was not available during the
         interval of interest.  This is represented within the MIB
         module by either frsldPvcDataUnavailableTime or
         frsldPvcSmplUnavailableTime.
Top   ToC   RFC3202 - Page 20
   o  Unavailables

         The number of times the PVC was declared to be unavailable
         during the interval of interest.  This is represented within
         the MIB module by either frsldPvcDataUnavailables or
         frsldPvcSmplUnavailables.

3.6.8. Delay

The frame transfer delay is defined as the amount of time elapsed, in microseconds, from the time a frame exits the source to the time it reaches the destination. The average delay can be found using the MIB variable described in DelayAvg above. The delay may be calculated as either round trip or one way, and this information is held in the frsldPvcCtrlDelayType MIB variable. If the delay be calculated as round trip, the value of DelayAvg represents the average of the total delays of the round trips. In this case, the manager SHOULD divide the value returned by the agent by two to obtain the frame transfer delay. In the case that frsldPvcCtrlDelayType is oneWay, the value of DelayAvg represents the average of the frame transfer delays and SHOULD be used as is.

3.6.9. Frame Delivery Ratio

The frame delivery ratio is defined as the total number of frames delivered to the destination divided by the frames offered by the source. The destination values can be obtained using FrDeliveredC and FrDeliveredE. The source values can be obtained using FrOfferedC and FrOfferedE. FrDeliveredC + FrDeliveredE Frame Delivery Ratio = --------------------------- FrOfferedC + FrOfferedE FrDeliveredC Committed Frame Delivery Ratio = ------------ FrOfferedC FrDeliveredE Excess Frame Delivery Ratio = ------------ FrOfferedE
Top   ToC   RFC3202 - Page 21

3.6.10. Data Delivery Ratio

The data delivery ratio is defined as the total amount of data delivered to the destination divided by the data offered by the source. The destination values can be obtained using DataDeliveredC and DataDeliveredE. The source values can be obtained using DataOfferedC and DataOfferedE. DataDeliveredC + DataDeliveredE Data Delivery Ratio = ------------------------------- DataOfferedC + DataOfferedE DataDeliveredC Committed Data Delivery Ratio = -------------- DataOfferedC DataDeliveredE Excess Data Delivery Ratio = -------------- DataOfferedE

3.6.11. Service Availability

Some forms of service availability measurement defined in FRF.13 [17] require knowledge of the amount of time the network is allowed to be unavailable during the period of measurement. This is called the excluded outage time and will be represented in the measurements below as ExcludedTime. It is assumed that the management software will maintain this information in that it often relates to specific times and dates that many devices are not capable of maintaining. Further, it may change based on a moving maintenance window that the device cannot track well. Mean Time to Repair (FRMTTR) = 0 if Unavailables is 0. UnavailableTime Otherwise, FRMTTR = --------------- Unavailables Virtual Connection Availability (FRVCA) = 0 if IntervalTime equals ExcludedTime. IntervalTime - ExcludedTime - UnavailableTime Otherwise, FRVCA = --------------------------------------------- *100 IntervalTime - ExcludedTime Mean Time Between Service Outages (FRMTBSO) = 0 if Unavailables is 0.
Top   ToC   RFC3202 - Page 22
   Otherwise, FRMTBSO = IntervalTime - ExcludedTime - UnavailableTime
                        ---------------------------------------------
                                       Unavailables

4. Relation to Other MIB Modules

There is no explicit relation to any other frame relay MIB module nor are any required to implement this MIB module. However, there is a need for knowledge of ifIndexes and some understanding of DLCIs. The ifIndex information can be found in the IF-MIB [21] which is required. The DLCI information can be found in either the Frame Relay DTE MIB (RFC 2115) [20] or the Frame Relay Network Services MIB (RFC 2954) [18]; however, neither is required. Upon setting of frsldPvcCtrlStatus in the frsldPvcCtrlTable to active(1) the system can be in one of the following three states: (1) The respective DLCI is known and is active. This corresponds to a state in which frPVCEndptRowStatus is active(1) and frPVCEndptRcvdSigStatus is either active(2) or none(4) for the Frame Relay Network Services MIB (RFC 2954) [18]. For the Frame Relay DTE MIB, the same state is shown by frCircuitRowStatus of active(1) and frCircuitState of active(2). (2) The respective DLCI has not been created. This corresponds to a state in which the row with either frPVCEndptDLCIIndex or frCircuitDlci equal to the respective DLCI does not exist in either the frPVCEndptTable or the frCircuitTable respectively. (3) The respective DLCI has just been removed. This corresponds to a state in which either frPVCEndptRowStatus is no longer active(1) or frPVCEndptRcvdSigStatus is no longer active(2) or none(4) for the Frame Relay Network Services MIB (RFC 2954) [18]. For the Frame Relay DTE MIB, the same state is shown when either frCircuitRowStatus is no longer active(1) or frCircuitState is no longer active(2). For the first case, the row in the frsldPvcDataTable will be filled. If frsldSmplCtrlStatus in the frsldSmplCtrlTable for the respective DLCI is also `active' the frsldPvcSampleTable will be filled as well. For the second case, the respective rows will not be added to any of the data or sample tables and frsldPvcCtrlStatus SHOULD report notReady(3).
Top   ToC   RFC3202 - Page 23
   For the third case, frsldPvcCtrlDeleteOnPurge should direct the
   behavior of the system.  If all tables are purged, this case will be
   equivalent to the second case above.  Otherwise, frsldPvcCtrlStatus
   SHOULD remain active(1).

5. Structure of the MIB Module

The FRSLD-MIB consists of the following components: o frsldPvcCtrlTable o frsldSmplCtrlTable o frsldPvcDataTable o frsldPvcSampleTable o frsldCapabilities Refer to the compliance statement defined within for a definition of what objects MUST be implemented.

5.1. frsldPvcCtrlTable

The frsldPvcCtrlTable is the central control table for operations of the Frame Relay Service Level Definitions MIB. It provides variables to control the parameters required to calculate the objects in the other tables. A row in this table MUST exist in order for a row to exist in any other table in this MIB module.

5.2. frsldSmplCtrlTable

This is an optional table to allow control of sampling of the data in the data table.

5.3. frsldPvcDataTable

This table contains the calculated data. It relies on configuration from the control table.
Top   ToC   RFC3202 - Page 24

5.4. frsldPvcSampleTable

This table contains samples of the delivery and availability information from the data table as well as delay information calculated over the sample period. It relies on configuration from both the control table and the sample control table.

5.5. frsldCapabilities

This is a group of objects that define write capabilities of the read-create objects in the tables above.

6. Persistence of Data

The data in frsldPvcCtrlTable and frsldSmplCtrlTable SHOULD persist through power cycles. Note, however, that the symantics of readiness for the rows still applies. This means that it is possible for a row to be reprovisioned as notReady(3) if the underlying DLCI does not persist. The data collected in the other tables SHOULD NOT persist through power cycles in that the reference TimeStamp is no longer valid.


(page 24 continued on part 2)

Next Section