📄 rfc1695.txt
字号:
Network Working Group M. Ahmed
Request for Comments: 1695 K. Tesink
Category: Standards Track Editors
Bell Communications Research
August 1994
Definitions of Managed Objects
for ATM Management Version 8.0
using SMIv2
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.
Table of Contents
1. Introduction ............................................. 2
2. The SNMPv2 Network Management Framework .................. 2
3. Object Definitions ....................................... 2
4. ATM Terminology .......................................... 3
4.1 VCL/VPL and VCC/VPC ..................................... 3
4.2 PVC and SVC ............................................. 5
4.3 Traffic Management Parameters ........................... 5
4.3.1 Traffic Policing and Traffic Shaping Parameters ...... 5
4.3.2 Cell Loss Priority .................................... 6
4.3.3 QoS Class ............................................. 6
5. Overview ................................................. 7
5.1 Background .............................................. 7
5.2 Structure of the MIB .................................... 7
5.3 ATM Interface Configuration Group ....................... 7
5.4 ATM Interface DS3 PLCP and TC Layer Groups .............. 8
5.5 ATM Virtual Link and Cross-Connect Groups ............... 8
6. Application of MIB II to ATM ............................. 8
6.1 The System Group ........................................ 8
6.2 The Interface Group ..................................... 8
6.2.1 Support of the ATM Cell Layer by ifTable .............. 9
7. Support of the AAL3/4 Based Interfaces ................... 10
8. Support of the AAL5 Managed Objects ...................... 10
8.1 Managing AAL5 in a Switch ............................... 11
8.2 Managing AAL5 in a Host ................................. 12
8.3 Support of AAL5 by ifTable .............................. 13
8.4 Support of Proprietary Virtual Interface by ifT-able .. 14
8.5 AAL5 Connection Performance Statistics Group ............ 15
Ahmed & Tesink [Page 1]
RFC 1695 ATM Management Objects August 1994
9. ILMI MIB and the ATM Managed Objects ..................... 15
10. Definitions ............................................. 18
11. Acknowledgments ......................................... 72
12. References .............................................. 72
13. Security Considerations ................................. 73
14. Authors' Addresses ...................................... 73
1. Introduction
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes objects used for managing ATM-based
interfaces, devices, networks and services.
This memo specifies a MIB module in a manner that is both compliant
to the SNMPv2 SMI, and semantically identical to the peer SNMPv1
definitions.
2. The SNMPv2 Network Management Framework
The SNMPv2 Network Management Framework consists of four major
components. They are:
0 RFC 1442 [1] which defines the SMI, the mechanisms used
for describing and naming objects for the purpose of
management.
0 STD 17, RFC 1213 [2] defines MIB-II, the core set of
managed objects for the Internet suite of protocols.
0 RFC 1445 [3] which defines the administrative and other
architectural aspects of the framework.
0 RFC 1448 [4] 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.
3. 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 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
Ahmed & Tesink [Page 2]
RFC 1695 ATM Management Objects August 1994
often use a textual string, termed the descriptor, to also refer to
the object type.
4. ATM Terminology
Some basic ATM terminologies are described in this section to
facilitate defining the ATM managed objects.
4.1. VCL/VPL and VCC/VPC
There are two distinct types of ATM virtual connections: Virtual
Channel Connections (VCCs) and Virtual Path Connection (VPCs). As
shown in Figures 1 and 2, ATM virtual connections consist of
concatenated series of virtual links which forms a path between two
end points, with each concatenation occurring at an ATM switch.
Virtual links of VCCs are called Virtual Channel Links (VCLs).
Virtual links of VPCs are called Virtual Path Links (VPLs). The VCI
and VPI fields in the ATM cell header associate each cell of a VCC
with a particular VCL over a given physical link. The VPI field in
the ATM cell header associates each cell of a VPC with a particular
VPL over a given physical link. Switches route cells between VCLs
(or VPLs) via a cross-connect function according to the cells'
VCI/VPI (or VPI) values.
<-----------------------VCC-------------------------->
------------ -----------
|ATM | |ATM |
|X-Connect | |X-Connect |
VCL1 |Point | VCL2 |Point | VCL3
O---------|----X-----|-------|-----|----X-----|-------O
| | | |
------------ ------------
ATM Switch ATM Switch
Figure 1: Virtual Channel Links and
Virtual Channel Connection
Ahmed & Tesink [Page 3]
RFC 1695 ATM Management Objects August 1994
<-----------------------VPC-------------------------->
------------ -----------
|ATM | |ATM |
|X-Connect | |X-Connect |
VPL1 |Point | VPL2 |Point | VPL3
O---------|----X-----|-------|-----|----X-----|-------O
| | | |
------------ ------------
ATM Switch ATM Switch
Figure 2: Virtual Path Links and
Virtual Path Connection
A single ATM end-system or switch does not support the whole end-to-
end span of a VCC (or VPC). Rather, multiple ATM end- systems and/or
switches each support one piece of the VCC (or VPC). That is, each
ATM end-system at one end of the VCC/VPC supports its end of the
VCC/VPC plus the VCLs or VPLs on its external interfaces, and each
switch through which the VCC/VPC passes, supports the multiple
VCLs/VPLs on that switch's external interfaces and the cross-
connection of those VCLs/VPLs through that switch. Thus, the end-
to-end management of a VCC or VPC is achieved only by appropriate
management of its individual pieces in combination.
Note that for management purposes, an ATM network may be viewed as a
large distributed switch by hiding all the network's internal
connectivity as being internal to the distributed switch (as shown in
Figure 2a). This model may for example be used for Customer Network
Management (CNM) purposes.
Ahmed & Tesink [Page 4]
RFC 1695 ATM Management Objects August 1994
<---------------------VCC--------------------------->
--------------------------------------
| |
| ---------- ---------- |
| | ATM | | ATM | |
VCL1 | | Switch | | Switch | | VCL3
O-------|-|--------|------/-------|--------|-|------O
| | | | | |
| ---------- ---------- |
| |
| ATM Network |
--------------------------------------
Figure 2a: ATM Network modeled as a large distributed
switch
A VCC has a set of traffic characteristics (i.e., bandwidth
parameters, QoS Class parameters, etc.). VCLs inherit their traffic
characteristics from the VCC of which they are a part. VCCs are bi-
directional by definition. However, the traffic parameters in the
two directions of a connection can be symmetric or asymmetric, i.e.,
the two directions can have the same or different traffic flows. A
uni-directional traffic flow across a VCC is achieved by assigning a
zero bandwidth in one direction. Note that in addition to the
bandwidth required by the user traffic flow, bandwidth is also
required for OAM cell flows, even for the zero-bandwidth direction of
a uni-directional connection. These same principles apply to VPCs.
4.2. PVC and SVC
A Permanent Virtual Connection (PVC) is a provisioned VCC or VPC. A
Switched Virtual Connection (SVC) is a switched VCC or VPC that is
set up in real-time via call set-up signaling procedures. A PVC (or
an SVC) can be a point-to-point, point-to-multipoint, or multipoint-
to-multipoint VCC or VPC.
4.3. Traffic Management Parameters
4.3.1. Traffic Policing and Traffic Shaping Parameters
In order to allocate resources fairly among different users, some
networks police traffic at resource access points. The traffic
enforcement or policing taken at a UNI is called Usage Parameter
Control (UPC) and is activated on an incoming VCL or VPL as shown in
Figure 3. The use of the traffic enforcer at the ingress of the
connection is to make sure that the user traffic does not exceed the
Ahmed & Tesink [Page 5]
RFC 1695 ATM Management Objects August 1994
negotiated traffic parameters such as the peak cell rate associated
with a specific traffic descriptor type.
---------- ----------
UNI | ATM | NNI | ATM | UNI
| | switch | | | switch | |
O<---|---->X(UPC) |<----|------>| (UPC)X<-----|--->O
| VCL | | | VCL | | VCL |
---------- ----------
Figure 3: An Example of a UPC
In addition, traffic shaping may be performed on an outgoing VPL or
VCL at a given ATM interface. The function of the ATM traffic shaper
either at the source or an egress point of the connection is to
smooth the outgoing cell traffic inter-arrival time. If policing or
shaping is not performed then the policing or shaping algorithm is
not activated. ATM Forum has specified seven traffic descriptor
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -