📄 rfc3202.txt
字号:
Steinberger & Nicklass Standards Track [Page 6]
RFC 3202 Frame Relay Service Level Defs MIB January 2002
+---------------------------+
|+-----------+ +-----------+|
|| | |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])
Steinberger & Nicklass Standards Track [Page 7]
RFC 3202 Frame Relay Service Level Defs MIB January 2002
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].
Steinberger & Nicklass Standards Track [Page 8]
RFC 3202 Frame Relay Service Level Defs MIB January 2002
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
Steinberger & Nicklass Standards Track [Page 9]
RFC 3202 Frame Relay Service Level Defs MIB January 2002
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
Steinberger & Nicklass Standards Track [Page 10]
RFC 3202 Frame Relay Service Level Defs MIB January 2002
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.
Steinberger & Nicklass Standards Track [Page 11]
RFC 3202 Frame Relay Service Level Defs MIB January 2002
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
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -