📄 rfc1604.txt
字号:
Network Working Group T. Brown, Editor
Request for Comments: 1604 Bell Communications Research
Obsoletes: 1596 March 1994
Category: Standards Track
Definitions of Managed Objects
for Frame Relay Service
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.
Abstract
This memo defines an extension to 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.
Table of Contents
1. The SNMPv2 Network Management Framework ............... 2
2. Object Definitions .................................... 2
3. Overview .............................................. 2
3.1 Scope of MIB ......................................... 3
3.2 Frame Relay Service MIB Terminology .................. 5
3.3 Apply MIB II to a Frame Relay Service ................ 7
4. Object Definitions .................................... 12
4.1 The Frame Relay Service Logical Port Group ........... 12
4.2 The Frame Relay Management VC Signaling Group ........ 15
4.3 The PVC End-Point Group .............................. 22
4.4 Frame Relay PVC Connection Group ..................... 30
4.5 Frame Relay Accounting Groups ........................ 37
5. Frame Relay Network Service TRAPS ..................... 40
6. Conformance Information ............................... 43
7. Acknowledgments ....................................... 45
8. References ............................................ 45
9. Security Considerations ............................... 46
10. Author's Address ..................................... 46
Frame Relay Service MIB Working Group [Page 1]
RFC 1604 Frame Relay Service MIB March 1994
1. The SNMPv2 Network Management Framework
The SNMPv2 Network Management Framework consists of four major
components. They are:
o RFC 1442 which defines the SMI, the mechanisms used for
describing and naming objects for the purpose of
management.
o STD 17, RFC 1213 defines MIB-II, the core set of managed
objects for the Internet suite of protocols.
o RFC 1445 which defines the administrative and other
architectural aspects of the framework.
o RFC 1448 which defines the protocol used for network
access to managed objects.
The Framework permits new objects to be defined for the purpose of
experimentation and evaluation.
2. Object Definitions
Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. Objects in the MIB are
defined using the subset of Abstract Syntax Notation One (ASN.1)
defined in the SMI. In particular, each object object type is named
by an OBJECT IDENTIFIER, an administratively assigned name. The
object type together with an object instance serves to uniquely
identify a specific instantiation of the object. For human
convenience, we often use a textual string, termed the descriptor, to
refer to the object type.
3. Overview
These objects are used when the particular media being used to manage
is Frame Relay Service. At present, this applies to these values of
the ifType variable in the Internet-standard MIB:
frameRelayService (44)
This section provides an overview and background of how to use this
MIB and other potential MIBs when managing a Frame Relay Service.
Figure 1 shows the MIB stack that could be followed for managing a
Frame Relay Service. This is only an example and not meant to be
inclusive.
Frame Relay Service MIB Working Group [Page 2]
RFC 1604 Frame Relay Service MIB March 1994
____________________________________________________
| | | | |
| | | SIP | RFC1490 |
| | X.25 MIB | Relay | (no applic.|
| | for IW/Encap.| MIB | MIB) |
| | | | |
| MIB II |-----------------------------------|
| | |
| ifTable | Frame Relay Service MIB |
| ifXTable | |
| ifStackTable |___________________________________|
| | | |
| | Physical Layer MIBs | ATM MIB |
| | e.g., DS1/E1 MIB, |---------|
| | RS232-like MIB | Phy. |
| | | Layer |
| | | MIB |
|--------------|-------------------------|---------|
Figure 1. Frame Relay MIB Architecture
3.1. Scope of MIB
The Frame Relay Service MIB will only manage the Frame Relay portion
of the network. This MIB is based upon the Customer Network
Management concepts presented in the document "Service Management
Architecture for Virtual Connection Services" [6].
This MIB will NOT be implemented on User Equipment (e.g., DTE), and
the Frame Relay DTE MIB (RFC 1315) should be used to manage those
devices [8].
Frame Relay Service MIB is intended to be used for Customer Network
Management (CNM) of a Frame Relay Network Service. It provides
information that allows end-customers to obtain performance
monitoring, fault detection, and configuration information about
their Frame Relay Service. It is an implementation decision as to
whether this MIB is used to create/delete/modify PVCs and to turn
PVCs on or off.
By using this and other related MIBs, a customer's NMS can monitor
their PVCs and UNI/NNI logical ports. Internal aspects of the
network (e.g., switching elements, line cards, and network routing
tables) are outside the scope of this MIB. The Customer's NMS will
typically access the SNMP proxy-agent within the Frame Relay network
using SNMP over UDP over IP with IP encapsulated in Frame Relay
according to RFC1490/ANSI T1.617 Annex F [7,9]. The customer, thus,
Frame Relay Service MIB Working Group [Page 3]
RFC 1604 Frame Relay Service MIB March 1994
has a PVC to the SNMP proxy-agent. Alternate access mechanisms and
SNMP agent implementations are possible. The service capabilities
include retrieving information and receiving TRAPs. It is beyond the
scope of this MIB to define managed objects to monitor the physical
layer. Existing physical layer MIBs (e.g., DS1 MIB) and MIB II will
be used as possible. The Frame Relay Service SNMP MIB for CNM will
not contain any managed objects to monitor the physical layer. This
MIB primarily addresses Frame Relay PVCs. This MIB may be extended
at a later time to handle Frame Relay SVCs.
This MIB is only used to manage a single Frame Relay Service offering
from one network. This MIB will typically be implemented on a
service provider's SNMP proxy-agent. The SNMP proxy-agent proxies for
all Frame Relay equipment within one service provider's Frame Relay
network. (Other SNMP agent implementations are not precluded.)
Therefore, this MIB models a PVC segment through one Frame Relay
Network. See Figure 2. If the customer's PVCs traverse multiple
networks, then the customer needs to poll multiple network proxy-
agents within each Frame Relay Network to retrieve their end-to-end
view of their service. See Figure 2 and the Service Management
Architecture [6].
Frame Relay Service MIB Working Group [Page 4]
RFC 1604 Frame Relay Service MIB March 1994
+-------------------------------------+
| Customer Network Management Station |
| (SNMP based) |
+-------------------------------------+
^ ^ ^
| | |
| | |
UNI | NNI | NNI | UNI
| ^ | ^ | ^
| +-----------+ | +-----------+ | +-----------+ |
| | | | | | | | | |
Originating | | FR | | | FR | | | FR | |Terminating
+--------+ | | Network I | | | Network J | | | Network K | | +--------+
| | | | | | | | | | | | | |
| |---| |---| |---| |---| User B |
| | | | | | | | | | | | | |
| //////////////////////////////////////////////////////////// |
| | | | | | | | | | | | | |
+--------+ | +-----------+ | +-----------+ | +-----------+ | +--------+
| | | |
| | | |
| PVC Segment 1 | PVC Segment 2 | PVC Segment 3 |
|<------------->|<------------->|<------------->|
| |
| Multi-network PVC |
|<--------------------------------------------->|
| NNI = Network-to Network Interface |
UNI = User-to-Network Interface
Figure 2. Multi-network PVC
Also, since the Frame Relay network is a shared network amongst many
Frame Relay subscribers, each subscriber will only have access to
their information (e.g., information with respect to their interfaces
and PVCs). Therefore, in order to provide this capability, the Frame
Relay PVC CNM proxy agent should be able to support instance level
granularity for MIB views. See the Service Management Architecture.
3.2. Frame Relay Service MIB Terminology
Access Channel - An access channel generically refers to the DS1/E1
or DS3/E3-based UNI access channel or NNI access channel across which
frame relay data transits. An access channel is the access pathway
for a single stream of user data.
Within a given T1 line, an access channel can denote any one of the
following:
Frame Relay Service MIB Working Group [Page 5]
RFC 1604 Frame Relay Service MIB March 1994
o Unchannelized T1 - the entire T1 line is considered an access
channel. Each access channel is comprised of 24 T1 time
slots.
o Channelized T1 - an access channel is any one of 24 channels.
Each access channel is comprised of a single T1 time slot.
o Fractional T1 - an access channel is a grouping of N T1 time
slots (NX56/64 Kbps, where N = 1-23 T1 Time slots per FT1
Access Channel) that may be assigned in consecutive or
non-consecutive order.
Within a given E1 line, a channel can denote any one of the
following:
o Unchannelized E1 - the entire E1 line is considered a single
access channel. Each access channel is comprised of 31 E1
time slots.
o Channelized E1 - an access channel is any one of 31 channels.
Each access channel is comprised of a single E1 time slot.
o Fractional E1 - an access channel is a grouping of N E1 time
slots (NX64 Kbps, where N = 1-30 E1 time slots per FE1 access
channel) that may be assigned in consecutive or
non-consecutive order.
in 3 Within a given unformatted line, the entire unformatted line
is considered an access channel. Examples include RS-232, V.35,
V.36 and X.21 (non- switched).
Access Rate - The data rate of the access channel, expressed in
bits/second. The speed of the user access channel determines how
rapidly the end user can inject data into the network.
Bc - The Committed Burst Size (Bc) is the maximum amount of
subscriber data (expressed in bits) that the network agrees to
transfer, under normal conditions, during a time interval Tc.
Be - The Excess Burst Size (Be) is the maximum amount of
subscriber data (expressed in bits) in excess of Bc that the
network will attempt to deliver during the time interval Tc. This
data (Be) is delivered in general with a lower probability than
Bc.
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. CIR is averaged over the
Frame Relay Service MIB Working Group [Page 6]
RFC 1604 Frame Relay Service MIB March 1994
time interval Tc (CIR = Bc/Tc).
DLCI - Data Link Connection Identifier
Logical Port - This term is used to model the Frame Relay
"interface" on a device.
NNI - Network to Network Interface
Permanent Virtual Connection (PVC) - A virtual connection that has
its end-points and bearer capabilities defined at subscription
time.
Time slot (E1) - An octet within the 256-bit information field in
each E1 frame is defined as a time slot. Time slots are position
sensitive within the 256-bit information field. Fractional E1
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -