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