draft-ietf-frnetmib-frmrelay-service-02.txt   draft-ietf-frnetmib-frmrelay-service-03.txt 
Definitions of Managed Objects Definitions of Managed Objects
for Frame Relay Service Level Definitions for Frame Relay Service Level Definitions
September 19, 2000 December 19, 2000
draft-ietf-frnetmib-frmrelay-service-02.txt draft-ietf-frnetmib-frmrelay-service-03.txt
Robert A. Steinberger Robert A. Steinberger
Paradyne Networks Paradyne Networks
rsteinberger@paradyne.com rsteinberger@paradyne.com
Orly Nicklass, Ph.D Orly Nicklass, Ph.D
RAD Data Communications Ltd. RAD Data Communications Ltd.
Orly_n@rad.co.il Orly_n@rad.co.il
Status of this Memo Status of this Memo
skipping to change at page 2, line 25 skipping to change at page 2, line 25
3.6. Theory of Operation ....................................... 9 3.6. Theory of Operation ....................................... 9
3.6.1. Capabilities Discovery .................................. 9 3.6.1. Capabilities Discovery .................................. 9
3.6.2. Determining Reference Points for Row Creation ........... 9 3.6.2. Determining Reference Points for Row Creation ........... 9
3.6.2.1. Graphical Examples of Reference Points ................ 11 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.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.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.2.1.3. End-to-End Using Reference Point Example ............ 14
3.6.3. Creation Process ........................................ 15 3.6.3. Creation Process ........................................ 15
3.6.4. Destruction Process ..................................... 15 3.6.4. Destruction Process ..................................... 15
3.6.4.1. Manual Row Destruction ................................ 15 3.6.4.1. Manual Row Destruction ................................ 15
3.6.4.2. Automatic Row Destruction ............................. 15 3.6.4.2. Automatic Row Destruction ............................. 16
3.6.5. Modification Process .................................... 16 3.6.5. Modification Process .................................... 16
3.6.6. Collection Process ...................................... 16 3.6.6. Collection Process ...................................... 16
3.6.6.1. Remote Polling ........................................ 16 3.6.6.1. Remote Polling ........................................ 16
3.6.6.2. Sampling .............................................. 17 3.6.6.2. Sampling .............................................. 17
3.6.6.3. User History .......................................... 17 3.6.6.3. User History .......................................... 17
3.6.7. Use of MIB in Calculation of Service Level Definitions .. 17 3.6.7. Use of MIB in Calculation of Service Level Definitions .. 18
3.6.8. Delay ................................................... 19 3.6.8. Delay ................................................... 20
3.6.9. Frame Delivery Ratio .................................... 20 3.6.9. Frame Delivery Ratio .................................... 20
3.6.10. Data Delivery Ratio .................................... 20 3.6.10. Data Delivery Ratio .................................... 21
3.6.11. Service Availability ................................... 20 3.6.11. Service Availability ................................... 21
4. Relation to Other MIBs ...................................... 21 4. Relation to Other MIBs ...................................... 22
5. Structure of the MIB ........................................ 22 5. Structure of the MIB ........................................ 23
5.1. frsldPvcCtrlTable ......................................... 22 5.1. frsldPvcCtrlTable ......................................... 23
5.2. frsldSmplCtrlTable ........................................ 23 5.2. frsldSmplCtrlTable ........................................ 24
5.3. frsldPvcDataTable ......................................... 23 5.3. frsldPvcDataTable ......................................... 24
5.4. frsldPvcSampleTable ....................................... 23 5.4. frsldPvcSampleTable ....................................... 24
5.5. frsldCapabilities ......................................... 23 5.5. frsldCapabilities ......................................... 24
6. Object Definitions .......................................... 23 6. Object Definitions .......................................... 24
7. Acknowledgments ............................................. 52 7. Acknowledgments ............................................. 53
8. References .................................................. 53 8. References .................................................. 54
9. Security Considerations ..................................... 55 9. Security Considerations ..................................... 56
10. Authors' Addresses ......................................... 55 10. Authors' Addresses ......................................... 56
11. Copyright Section .......................................... 56 11. Copyright Section .......................................... 57
1. The SNMP Management Framework 1. The SNMP Management Framework
The SNMP Management Framework presently consists of five major The SNMP Management Framework presently consists of five major
components: components:
o An overall architecture, described in RFC 2571 [1]. o An overall architecture, described in RFC 2571 [1].
o Mechanisms for describing and naming objects and events for the o Mechanisms for describing and naming objects and events for the
purpose of management. The first version of this Structure of purpose of management. The first version of this Structure of
skipping to change at page 9, line 48 skipping to change at page 9, line 48
supported reference points. supported reference points.
These objects do not imply that there is no need for an Agent These objects do not imply that there is no need for an Agent
Capabilities macro for devices that do not fully support every object Capabilities macro for devices that do not fully support every object
in this MIB. They are provided specifically to aid in the ensured in this MIB. They are provided specifically to aid in the ensured
network management operations of this MIB with respect to row network management operations of this MIB with respect to row
creation and modification. creation and modification.
3.6.2. Determining Reference Points for Row Creation 3.6.2. Determining Reference Points for Row Creation
The ability to monitor specific reference points varies between The performance of a PVC is monitored by evaluating the uni-
devices. This variance is based on the capabilities of device in directional flow of frames from an ingress point to an egress point.
regards to communication with the remote devices along the PVC as Reference points describe where each of the two measurements are
well as where the device exists in the network. Most endpoint devices made. Monitoring both of the uni-directional flows that make-up the
are capable of monitoring the local source and destination reference PVC frame traffic requires a total of four reference points as shown
points but may not have the capability to monitor any other reference in Figures 3 through 5. A monitoring point that evaluates traffic is
points. Some devices are able to communicate with remote devices in restricted to counting frames that pass the reference points hosted
such a way that information concerning the remote reference points is locally on the monitoring point. Thus, if the monitoring point is
known locally. 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.
To monitor bidirectional information on a PVC a total of four The local monitoring point MAY be implemented in such way that the
reference points is required. Two relate to the local device and two information from the downstream monitoring point is moved to the
relate to the remote device. It does not matter on which device the local monitoring point using implementation-specific mechanisms. In
reference points exist as long as the transmit and receive reference this case all information required to calculate frame loss becomes
points for each device are captured. 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 The following list shows the possible valid reference points for an
FRF.13 SLA from the source reference point to the destination FRF.13 SLA from the source reference point to the destination
reference point in both directions. reference point in both directions.
o Local Information Only o Local Information Only
Local Device: srcLocalRP, desLocalRP Local Device: srcLocalRP, desLocalRP
Remote Device: srcLocalRP, desLocalRP Remote Device: srcLocalRP, desLocalRP
skipping to change at page 12, line 27 skipping to change at page 12, line 27
| Egress | | Ingress | | Egress | | Ingress |
| +-----+ | | +-----+ | | +-----+ | | +-----+ |
|(D)| | | Traffic Flow | | |(C)| |(D)| | | Traffic Flow | | |(C)|
<--<--<- -<--<--<--<--<--<--<--<--<--<--<-- --<--<-- <--<--<- -<--<--<--<--<--<--<--<--<--<--<-- --<--<--
| | | | From Device 2 to 1 | | | | | | | | From Device 2 to 1 | | | |
| +-----+ | | +-----+ | | +-----+ | | +-----+ |
+-------------+ +-------------+ +-------------+ +-------------+
where (A), (B), (C) and (D) are reference points where (A), (B), (C) and (D) are reference points
Figure 3
For devices with only local knowledge, one row is required on each For devices with only local knowledge, one row is required on each
device as follows: device as follows:
(A) frsldPvcCtrlTransmitRP for Device 1 = ingTxLocalRP(2) (A) frsldPvcCtrlTransmitRP for Device 1 = ingTxLocalRP(2)
(B) frsldPvcCtlrReceiveRP for Device 2 = eqoRxLocalRP(5) (B) frsldPvcCtlrReceiveRP for Device 2 = eqoRxLocalRP(5)
(C) frsldPvcCtrlTransmitRP for Device 2 = ingTxLocalRP(2) (C) frsldPvcCtrlTransmitRP for Device 2 = ingTxLocalRP(2)
(D) frsldPvcCtlrReceiveRP for Device 1 = eqoRxLocalRP(5) (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 For devices with both local and remote knowledge, the two rows can
exist in any combination on either device. For this example, the exist in any combination on either device. For this example, the
transmitting devices will be responsible for information regarding transmitting devices will be responsible for information regarding
the flow for which they are the origin. Only one row is required per the flow for which they are the origin. Only one row is required per
device for this example. device for this example.
(A) frsldPvcCtrlTransmitRP for Device 1 = ingTxLocalRP(2) (A) frsldPvcCtrlTransmitRP for Device 1 = ingTxLocalRP(2)
(B) frsldPvcCtlrReceiveRP for Device 1 = eqoRxRemoteRP(11) (B) frsldPvcCtlrReceiveRP for Device 1 = eqoRxRemoteRP(11)
(C) frsldPvcCtrlTransmitRP for Device 2 = ingTxLocalRP(2) (C) frsldPvcCtrlTransmitRP for Device 2 = ingTxLocalRP(2)
(D) frsldPvcCtlrReceiveRP for Device 2 = eqoRxRemoteRP(11) (D) frsldPvcCtlrReceiveRP for Device 2 = eqoRxRemoteRP(11)
3.6.2.1.2. Edge-to-Edge Egress Queue Reference Point Example 3.6.2.1.2. Edge-to-Edge Egress Queue Reference Point Example
Device 1 Device 2 Device 1 Device 2
+-------------+ +-------------+ +-------------+ +-------------+
skipping to change at page 13, line 26 skipping to change at page 13, line 31
| Egress | | Ingress | | Egress | | Ingress |
| +-----+ | | +-----+ | | +-----+ | | +-----+ |
| | |(D)| Traffic Flow | | |(C)| | | |(D)| Traffic Flow | | |(C)|
<--<--<- -<--<--<--<--<--<--<--<--<--<--<-- --<--<-- <--<--<- -<--<--<--<--<--<--<--<--<--<--<-- --<--<--
| | | | From Device 2 to 1 | | | | | | | | From Device 2 to 1 | | | |
| +-----+ | | +-----+ | | +-----+ | | +-----+ |
+-------------+ +-------------+ +-------------+ +-------------+
where (A), (B), (C) and (D) are reference points where (A), (B), (C) and (D) are reference points
Figure 4
For devices with only local knowledge, one row is required on each For devices with only local knowledge, one row is required on each
device as follows: device as follows:
(A) frsldPvcCtrlTransmitRP for Device 1 = ingTxLocalRP(2) (A) frsldPvcCtrlTransmitRP for Device 1 = ingTxLocalRP(2)
(B) frsldPvcCtlrReceiveRP for Device 2 = eqiRxLocalRP(4) (B) frsldPvcCtlrReceiveRP for Device 2 = eqiRxLocalRP(4)
(C) frsldPvcCtrlTransmitRP for Device 2 = ingTxLocalRP(2) (C) frsldPvcCtrlTransmitRP for Device 2 = ingTxLocalRP(2)
(D) frsldPvcCtlrReceiveRP for Device 1 = eqiRxLocalRP(4) (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).
For devices with both local and remote knowledge, the two rows can For devices with both local and remote knowledge, the two rows can
exist in any combination on either device. For this example, the exist in any combination on either device. For this example, the
transmitting devices will be responsible for information regarding transmitting devices will be responsible for information regarding
the flow for which they are the origin. Only one row is required per the flow for which they are the origin. Only one row is required per
device for this example. device for this example.
(A) frsldPvcCtrlTransmitRP for Device 1 = ingTxLocalRP(2) (A) frsldPvcCtrlTransmitRP for Device 1 = ingTxLocalRP(2)
(B) frsldPvcCtlrReceiveRP for Device 1 = eqiRxRemoteRP(10) (B) frsldPvcCtlrReceiveRP for Device 1 = eqiRxRemoteRP(10)
skipping to change at page 14, line 26 skipping to change at page 14, line 37
| Destination | | Source | | Destination | | Source |
| +-----+ | | +-----+ | | +-----+ | | +-----+ |
|(D)| | | Traffic Flow | | |(C)| |(D)| | | Traffic Flow | | |(C)|
<--<--<- -<--<--<--<--<--<--<--<--<--<--<-- --<--<-- <--<--<- -<--<--<--<--<--<--<--<--<--<--<-- --<--<--
| | | | From Device 2 to 1 | | | | | | | | From Device 2 to 1 | | | |
| +-----+ | | +-----+ | | +-----+ | | +-----+ |
+-------------+ +-------------+ +-------------+ +-------------+
where (A), (B), (C) and (D) are reference points where (A), (B), (C) and (D) are reference points
Figure 5
For devices with only local knowledge, one row is required on each For devices with only local knowledge, one row is required on each
device as follows: device as follows:
(A) frsldPvcCtrlTransmitRP for Device 1 = srcLocalRP(1) (A) frsldPvcCtrlTransmitRP for Device 1 = srcLocalRP(1)
(B) frsldPvcCtlrReceiveRP for Device 2 = desLocalRP(1) (B) frsldPvcCtlrReceiveRP for Device 2 = desLocalRP(1)
(C) frsldPvcCtrlTransmitRP for Device 2 = srcLocalRP(1) (C) frsldPvcCtrlTransmitRP for Device 2 = srcLocalRP(1)
(D) frsldPvcCtlrReceiveRP for Device 1 = desLocalRP(1) (D) frsldPvcCtlrReceiveRP for Device 1 = desLocalRP(1)
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 For devices with both local and remote knowledge, the two rows can
exist in any combination on either device. For this example, the exist in any combination on either device. For this example, the
transmitting devices will be responsible for information regarding transmitting devices will be responsible for information regarding
the flow for which they are the origin. Only one row is required per the flow for which they are the origin. Only one row is required per
device for this example. device for this example.
(A) frsldPvcCtrlTransmitRP for Device 1 = srcLocalRP(1) (A) frsldPvcCtrlTransmitRP for Device 1 = srcLocalRP(1)
(B) frsldPvcCtlrReceiveRP for Device 1 = desRemoteRP(7) (B) frsldPvcCtlrReceiveRP for Device 1 = desRemoteRP(7)
skipping to change at page 17, line 45 skipping to change at page 18, line 17
The objects in this MIB can be used to calculate the statistics The objects in this MIB can be used to calculate the statistics
defined in FRF.13 [17]. The description below describes the defined in FRF.13 [17]. The description below describes the
calculations for one direction of the data flow, i.e. data sent from calculations for one direction of the data flow, i.e. data sent from
local transmitter to a remote receiver. A complete set of local transmitter to a remote receiver. A complete set of
bidirectional information would require calculations based on both bidirectional information would require calculations based on both
directions. For the purposes of this description, the reference directions. For the purposes of this description, the reference
points used SHOULD consistently represent data that is sent by one points used SHOULD consistently represent data that is sent by one
device and received by the other. 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: The calculations below use the following terminology:
o DelayAvg o DelayAvg
The average delay on the PVC. This is represented within the The average delay on the PVC. This is represented within the
MIB by frsldPvcSmplDelayAvg. MIB by frsldPvcSmplDelayAvg.
o FrDeliveredC o FrDeliveredC
The number of frames received by the receiving device through The number of frames received by the receiving device through
the receive reference point that were delivered within CIR. the receive reference point that were delivered within CIR.
This is represented within the MIB by one of This is represented within the MIB by one of
frsldPvcDataFrDeliveredC, frsldPvcDataHCFrDeliveredC, frsldPvcDataFrDeliveredC, frsldPvcDataHCFrDeliveredC,
frsldPvcSmplFrDeliveredC, or frsldPvcSmplHCFrDeliveredC. frsldPvcSmplFrDeliveredC, or frsldPvcSmplHCFrDeliveredC.
 End of changes. 16 change blocks. 
35 lines changed or deleted 73 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/