RFC 2954
Definitions of Managed Objects for Frame Relay Service
Network Working Group K. Rehbehn Request for Comments: 2954 Megisto Systems Obsoletes: 1604 D. Fowler Category: Standards Track Syndesis Limited October 2000 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. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved.Abstract
This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in Transmission Control Protocol/Internet Protocol-based (TCP/IP) internets. In particular, it defines objects for managing the frame relay service. This document obsoletes RFC 1604.Table of Contents
1 The SNMP Management Framework ................................ 2 2 Overview ..................................................... 3 2.1 Scope of MIB ............................................... 3 2.2 Transiting Multiple Frame Relay Networks ................... 5 2.3 Access Control ............................................. 5 2.4 Frame Relay Service MIB Terminology ........................ 6 2.5 Relation to Other MIBs ..................................... 8 2.5.1 System Group ............................................. 8 2.5.2 Interfaces Table (ifTable, ifXtable) ..................... 8 2.5.3 Stack Table for DS1/E1 Environment ....................... 12 2.5.4 Stack Table for V.35 Environments ........................ 14 2.5.5 The Frame Relay/ATM PVC Service Interworking MIB ......... 14 2.6 Textual Convention Change .................................. 15 3 Object Definitions ........................................... 15 3.1 The Frame Relay Service Logical Port ....................... 17
3.2 Frame Relay Management VC Signaling ........................ 22 3.3 Frame Relay PVC End-Points ................................. 32 3.4 Frame Relay PVC Connections ................................ 45 3.5 Frame Relay Accounting ..................................... 53 3.6 Frame Relay Network Service Notifications .................. 56 3.7 Conformance Information .................................... 57 4 Acknowledgments .............................................. 67 5 References ................................................... 67 6 Security Considerations ...................................... 69 7 Authors' Addresses ........................................... 70 APPENDIX A Update Information .................................. 71 Intellectual Property Rights ................................... 75 Full Copyright Statement ....................................... 761. 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], STD 58, RFC 2579 [6] and STD 58, 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 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. Overview
These objects are used to manage a frame relay Service. At present, this applies to the following value of the ifType variable in the IF-MIB [26]: frameRelayService (44) This section provides an overview and background of how to use this MIB and other potential MIBs to manage a frame relay service.2.1. Scope of MIB
The Frame Relay Service MIB supports Customer Network Management (CNM) of a frame relay network service. Through the use of this and other related MIBs, a frame relay service customer's NMS can monitor the customer's UNI/NNI logical ports and PVCs. It provides customers with access to configuration data, performance monitoring information, and fault detection for the delivered frame relay service. As an option, an SNMP agent supporting the Frame Relay Service MIB may allow customer-initiated PVC management operations such as creation, deletion, modification, activation, and deactivation of individual PVCs. However, internal aspects of the network (e.g., switching elements, line cards, and network routing tables) are beyond the scope of this MIB. The Frame Relay Service MIB models all interfaces and PVCs delivered by a frame relay service within a single virtual SNMP system for the purpose of comprehensively representing the customer's frame relay service. The customer's interfaces and PVCs may physically exist on one or more devices within the network topology. An SNMP agent
providing support for the Frame Relay Service MIB as well as other appropriate MIBs to model a single virtual frame relay network service is referred to as a Frame Relay Service (FRS) agent. Internal communication mechanisms between the FRS agent and individual devices within the frame relay network delivering the service are implementation specific and beyond the scope of this MIB. The customer's NMS will typically access the SNMP agent implementing the Frame Relay Service MIB over a frame relay permanent virtual connection (PVC). SNMP access over a frame relay PVC is achieved through the use of SNMP over UDP over IP encapsulated in Frame Relay according to STD 55, RFC2427 and ITU X.36 Annex D [23]. Alternate access mechanisms and SNMP agent implementations are possible. This MIB will NOT be implemented on user equipment (e.g., DTE). Such devices are managed using the Frame Relay DTE MIB (RFC2115[18]). However, concentrators may use the Frame Relay Service MIB instead of the Frame Relay DTE MIB. This MIB does not define managed objects for the physical layer. Existing physical layer MIBs (e.g., DS1 MIB) and Interface MIB will be used as needed in FRS Agent implementations. This MIB supports frame relay PVCs. This MIB may be extended at a later time to handle frame relay SVCs. A switch implementation may support this MIB for the purpose of configuration and control of the frame relay service beyond the scope of traditional customer network management applications. A number of objects (e.g. frLportTypeAdmin) support administrative actions that impact the operation of frame relay switch equipment in the network. This is reflected in the differences between the two MIB compliance modules: o the frame relay service compliance module (frnetservCompliance), and o the frame relay switch compliance module (frnetSwitchCompliance). The frame relay service compliance module does not support the administrative control objects used for switch management.
2.2. Transiting Multiple Frame Relay Networks
This MIB is only used to manage a single frame relay service offering from one network service provider. Therefore, if a customer PVC traverses multiple networks, then the customer must poll a different FRS agent within each frame relay network to retrieve the end-to-end view of service. Figure 1 illustrates a customer ("User B") NMS accessing FRS agents in three different frame relay networks (I, J, and K). +-------------------------------------+ | 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 1, Multi-network PVC2.3. Access Control
A frame relay network is shared amongst many frame relay subscribers. Each subscriber will only have access to their information (e.g., information with respect to their interfaces and PVCs). The FRS agent should provide instance level granularity for MIB views.
2.4. 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 DS1 line, an access channel can denote any one of the following: o Unchannelized DS1 - the entire DS1 line is considered an access channel. Each access channel is comprised of 24 DS0 time slots. o Channelized DS1 - an access channel is any one of 24 channels. Each access channel is comprised of a single DS0 time slot. o Fractional DS1 - an access channel is a grouping of NxDS0 time slots (NX56/64 Kbps, where N = 1-23 DS0 Time slots per Fractional DS1 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. 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), and unframed E1 (G.703 without G.704). 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 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 service is provided in contiguous or non-contiguous time slot increments. Time slot (DS0) - An octet within the 192-bit information field in each DS1 frame is defined as a time slot. Time slots are position sensitive within the 192-bit information field. Fractional DS1 service is provided in contiguous or non-contiguous time slot increments. UNI - User to Network Interface N391 - Full status (status of all PVCs) polling counter N392 - Error threshold N393 - Monitored events count T391 - Link integrity verification polling timer T392 - Polling verification timer nT3 - Status enquiry timer nN3 - Maximum status enquiry counter
2.5. Relation to Other MIBs
2.5.1. System Group
Use the System Group of the SNMPv2-MIB [27] to describe the Frame Relay Service (FRS) agent. The FRS agent may be monitoring many frame relay devices in one network. The System Group does not describe frame relay devices monitored by the FRS agent. sysDescr: ASCII string describing the FRS agent. Can be up to 255 characters long. This field is generally used to indicate the network providers identification and type of service offered. sysObjectID: Unique OBJECT IDENTIFIER (OID) for the FRS agent. sysUpTime: Clock in the FRS agent; TimeTicks in 1/100s of a second. Elapsed type since the FRS agent came on line. sysContact: Contact for the FRS agent. ASCII string of up to 255 characters. sysName: Domain name of the FRS agent, for example, acme.com sysLocation: Location of the FRS agent. ASCII string of up to 255 characters. sysServices: Services of the managed device. The value "2", which implies that the frame relay network is providing a subnetwork level service, is recommended.2.5.2. Interfaces Table (ifTable, ifXtable)
This specifies how the Interfaces Group defined in the IF MIB [26] shall be used for the management of frame relay based interfaces, and in conjunction with the Frame Relay Service MIB module. This memo assumes the interpretation of the evolution of the Interfaces group to be in accordance with: "The interfaces table (ifTable) contains information on the managed resource's interfaces. Each sub-layer below the internetwork layer of a network interface is considered an interface." Thus, the ifTable allows the following frame relay-based interfaces to be represented as table entries:
- Frame relay interfaces in equipment (e.g., switches, routers or
networks) supporting frame relay. This level is concerned with
generic frame counts and not with individual virtual connections.
In accordance with the guidelines of ifTable, frame counts per
virtual connection are not covered by ifTable, and are considered
interface specific and covered in the Frame Relay Service MIB module.
In order to interrelate the ifEntries properly, the Interfaces Stack
Group shall be supported.
Some specific interpretations of ifTable for frame relay follow.
Object Use for the generic Frame Relay layer
====== =============================================
ifIndex Each frame relay port is represented by an
ifEntry.
ifDescr Description of the frame relay interface.
ASCII string describing the UNI/NNI logical
port. Can be up to 255 characters long.
ifType The value allocated for Frame Relay Service
is equal to 44.
ifMtu Set to maximum frame size in octets for this
frame relay logical port.
ifSpeed Peak bandwidth in bits per second available
for use. This could be the speed of the
logical port and not the access rate. Actual
user information transfer rate (i.e., access
rate) of the UNI or NNI logical port in bits
per second (this is not the clocking speed).
For example, it is 1,536,000 bits per second
for a DS1-based UNI/NNI logical port and
1,984,000 bits per second for an E1-based
UNI/NNI logical port.
ifPhysAddress The primary address for this logical port
assigned by the frame relay interface
provider. An octet string of zero length if
no address is used for this logical port.
ifAdminStatus The desired administrative status of the
frame relay logical port.
ifOperStatus The current operational status of the Frame
Relay UNI or NNI logical port.
ifLastChange The value of sysUptime at the last
re-initialization of the logical port. The
value of sysUpTime at the time the logical
port entered its current operational state.
If the current state was entered prior to the
last re-initialization of the local network
management subsystem, then this object
contains a zero value.
ifInOctets The number of received octets. This counter
only counts octets from the beginning of the
frame relay header field to the end of user
data.
ifInUcastPkts The number of received unerrored, unicast
frames.
ifInDiscards The number of received frames discarded.
Specifically, frames discarded due to ingress
buffer congestion and traffic policing.
ifInErrors The number of received frames that are
discarded because of an error. Specifically,
frames that are too long or too short, frames
that are not a multiple of 8 bits in length,
frames with an invalid or unrecognized DLCI,
frames with an abort sequence, frames with
improper flag delimitation, and frame that
fail FCS.
ifInUnknownProtos The number of packets discarded because of an
unknown or unsupported protocol. For Frame
Relay Service interfaces, this counter will
always be zero.
ifOutOctets The number of transmitted octets. This
counter only counts octets from the beginning
of the frame relay header field to the end of
user data.
ifOutUcastpkts The number of unerrored, unicast frames sent.
ifOutDiscards The number of frames discarded in the egress
direction. Possible reasons are as follows:
policing, congestion.
ifOutErrors The number of frames discarded in the egress
direction because of an error. Specifically,
frames that are aborted due to a transmitter
underrun.
ifName This variable is not applicable for Frame
Relay Service interfaces, therefore, this
variable contains a zero-length string.
ifInMulticastPkts The number of received unerrored, multicast
frames.
ifInBroadcastPkts This variable is not applicable for Frame
Relay Service interfaces, therefore, this
counter is always zero.
ifOutMulticastPkts The number of sent unerrored, multicast
frames.
ifOutBroadcastPkts This variable is not applicable for Frame
Relay Service interfaces, therefore, this
counter is always zero.
ifHCInOctets Only used for DS3-based (and greater) Frame
Relay logical ports. The number of received
octets. This counter only counts octets
from the beginning of the frame relay header
field to the end of user data.
ifHCOutOctets Only used for DS3-based (and greater) Frame
Relay logical ports. The number of
transmitted octets. This counter only counts
octets from the beginning of the frame relay
header field to the end of user data.
ifLinkUpDownTrapEnable Set to true(1). It is recommended that the
underlying physical layer notifications be
disabled since both are not required.
Notifications are enabled at the frame relay
service layer specifically because PVC
notifications are not to be sent if the frame
relay interface fails. Without a
linkUp/linkDown notification, the management
station would receive no notification of the
failure.
ifHighSpeed Set to the user data rate of the frame relay
logical port in millions of bits per second.
If the user data rate is less than 1 Mbps,
then this value is zero.
ifPromiscuousMode Set to false(2).
ifConnectorPresent Set to false(2).
Frame relay network service interfaces support the Interface Stack
Group. Frame relay network service interfaces do not support any
other groups or objects in the Interfaces group of the IF MIB.
2.5.3. Stack Table for DS1/E1 Environment
This section describes by example how to use ifStackTable to
represent the relationship of frame relay service to ds0 and
ds0Bundles with ds1 interfaces [20].
Example: A frame relay service is being carried on 4 ds0s of a ds1.
+---------------------+
| Frame Relay Service |
+---------------------+
|
+---------------------+
| ds0Bundle |
+---------------------+
| | | |
+---+ +---+ +---+ +---+
|ds0| |ds0| |ds0| |ds0|
+---+ +---+ +---+ +---+
| | | |
+---------------------+
| ds1 |
+---------------------+
The assignment of the index values could for example be:
ifIndex Description
1 FrameRelayService (type 44)
2 ds0Bundle (type 82)
3 ds0 #1 (type 81)
4 ds0 #2 (type 81)
5 ds0 #3 (type 81)
6 ds0 #4 (type 81)
7 ds1 (type 18)
The ifStackTable is then used to show the relationships between the
various interfaces.
ifStackTable Entries
HigherLayer LowerLayer
0 1
1 2
2 3
2 4
2 5
2 6
3 7
4 7
5 7
6 7
7 0
In the case where the frame relay service is using a single ds0, then
the ds0Bundle is not required.
+---------------------+
| Frame Relay Service |
+---------------------+
|
+---+
|ds0|
+---+
|
+---------------------+
| ds1 |
+---------------------+
The assignment of the index values could for example be:
ifIndex Description
1 FrameRelayService (type 44)
2 ds0 (type 81)
3 ds1 (type 18)
The ifStackTable is then used to show the relationships between the
various interfaces.
ifStackTable Entries
HigherLayer LowerLayer
0 1
1 2
2 3
3 0
2.5.4. Stack Table for V.35 Environments
This section describes by example how to use ifStackTable to
represent the relationship of frame relay service with V.35
interfaces.
+---------------------+
| Frame Relay Service |
+---------------------+
|
+---------------------+
| v35 |
+---------------------+
An example of index values in this case could be:
ifIndex Description
1 FrameRelayService (type 44)
2 v35 (type 33)
Note type 33 (RS232-like MIB) is used instead of type 45 (V.35). V35
does not pertain to this environment.
The ifStackTable is then used to show the relationships between the
various interfaces.
ifStackTable Entries
HigherLayer LowerLayer
0 1
1 2
2 0
2.5.5. The Frame Relay/ATM PVC Service Interworking MIB
Connections between two frame relay endpoints are represented with an
entry in the frPVCConnectTable of this MIB. Both endpoints are
represented with rows in the frPVCEndptTable. The
frPVCEndptConnectIdentifier object of each endpoint points to the
frPVCConnectTable cross-connect table row for the connection.
In contrast, a connection that spans frame relay and ATM endpoints is represented with an entry in the frAtmIwfConnectionTable of the FR/ATM PVC Service Interworking MIB defined in [28]. In the case of an inter-worked connection, the frPVCEndptConnectIdentifier object is set to zero. Instead, the frPVCEndptAtmIwfConnIndex object is set to the index of the FR/ATM IWF cross-connect table row. The frame relay PVC cross-connect table (frPVCConnectTable) does not contain an entry for the FR/ATM inter-worked connection.2.6. Textual Convention Change
Version 1 of the Frame Relay Service MIB contains MIB objects defined with the DisplayString textual convention. In version 2 of this MIB, the syntax for these objects has been updated to use the (now preferred) SnmpAdminString textual convention. The new TC provides support for a greater variety of international character sets. The working group realizes that this change is not strictly supported by SMIv2. In our judgment, the alternative of deprecating the old objects and defining new objects would have a more adverse impact on backward compatibility and interoperability, given the particular semantics of these objects.
(page 15 continued on part 2)
