📄 rfc2515.txt
字号:
Network Working Group K. Tesink, Editor
Request for Comments: 2515 Bell Communications Research
Obsoletes: 1695 February 1999
Category: Standards Track
Definitions of Managed Objects
for ATM Management
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 (1999). All Rights Reserved.
Table of Contents
1 Abstract ............................................. 2
2 The SNMP Network Management Framework ................. 2
3 ATM Terminology ....................................... 3
3.1 VCL/VPL and VCC/VPC ................................. 3
3.2 PVC, SVC and Soft PVC ............................... 5
3.3 Traffic Management Parameters ....................... 6
3.3.1 Traffic Policing and Traffic Shaping Parameters
.................................................... 6
3.3.2 Cell Loss Priority ................................ 6
3.3.3 QoS Class ......................................... 6
3.3.4 Service Category .................................. 7
3.4 Max Active and Max Current VPI and VCI Bits ......... 7
4 Overview .............................................. 8
4.1 Background .......................................... 8
4.2 Structure of the MIB ................................ 9
4.3 ATM Interface Configuration Table ................... 9
4.4 ATM Interface DS3 PLCP and TC Layer Tables .......... 9
4.5 ATM Virtual Link and Cross-Connect Tables ........... 9
5 Application of MIB II to ATM .......................... 10
5.1 The System Group .................................... 10
5.2 The Interface Group ................................. 10
5.2.1 Support of the ATM Cell Layer by ifTable .......... 10
6 Support of the AAL3/4 Based Interfaces ................ 12
7 Support of the AAL5 Managed Objects ................... 12
7.1 Managing AAL5 in a Switch ........................... 12
Tesink Standards Track [Page 1]
RFC 2515 ATM Management Objects February 1999
7.2 Managing AAL5 in a Host ............................. 14
7.3 Support of AAL5 by ifTable .......................... 15
7.4 Support of Proprietary Virtual Interface by ifT-
able ............................................... 16
7.5 AAL5 Connection Performance Statistics Table ........ 17
8 ILMI MIBs and the ATM Managed Objects ................. 18
9 Definitions ........................................... 20
10 Acknowledgments ...................................... 83
11 References ........................................... 83
12 Security Considerations .............................. 85
13 Author's Address ..................................... 85
14 Intellectual Property ................................ 86
15 Full Copyright Statement ............................. 87
1. Abstract
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 replaces RFC 1695 [24]. Changes relative to RFC 1695 are
summarized in the MIB module's REVISION clause.
Textual Conventions used in this MIB are defined in [6] and [19].
2. The SNMP Network Management Framework
The SNMP Management Framework presently consists of five major
components:
0 An overall architecture, described in RFC 2271 [1].
0 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 RFC
1902 [5], RFC 1903 [6] and RFC 1904 [7].
0 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].
Tesink Standards Track [Page 2]
RFC 2515 ATM Management Objects February 1999
The third version of the message protocol is called SNMPv3 and
described in RFC 1906 [10], RFC 2272 [11] and RFC 2274 [12].
0 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].
0 A set of fundamental applications described in RFC 2273 [14] and
the view-based access control mechanism described in RFC 2275
[15].
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 (e.g., 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.
3. ATM Terminology
Some basic ATM terminologies are described in this section to
facilitate defining the ATM managed objects.
3.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.
Tesink Standards Track [Page 3]
RFC 2515 ATM Management Objects February 1999
<-----------------------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
<-----------------------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 (or ATM switch) at one end of the VCC/VPC supports its
end of the VCC/VPC plus the VCL or VPL on its external interface, and
each switch through which the VCC/VPC passes supports the pair of
VCLs/VPLs on its external interfaces as well as the cross-connection
of those VCLs/VPLs. 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.
Tesink Standards Track [Page 4]
RFC 2515 ATM Management Objects February 1999
<---------------------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, service category 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.
3.2. PVC, SVC and Soft PVC
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. A Soft PVC is a connection of which
portions are switched, while other portions are permanent (see Figure
3 and [22]).
+--------+ +--------+ +--------+
pvc| ATM |svc svc | ATM |svc svc | ATM |pvc
----| Switch |-----------| Switch |-----------| Switch |----
+--------+ +--------+ +--------+
Figure 3: An example of a Soft PVC
Tesink Standards Track [Page 5]
RFC 2515 ATM Management Objects February 1999
3.3. Traffic Management Parameters
3.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 conceptually activated on an incoming VCL or VPL
as shown in Figure 4. The use of the traffic enforcer at the ingress
of the connection is to make sure that the user traffic does not
exceed the 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 4: 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, conceptually 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.
3.3.2. Cell Loss Priority
To prioritize traffic during resource congestion, ATM cells are
assigned one of the two types of Cell Loss Priority (CLP), CLP=0 and
CLP=1. ATM cells with CLP=0 have a higher priority in regard to cell
loss than ATM cells with CLP=1. Therefore, during resource
congestions, CLP=1 cells are dropped before any CLP=0 cell is
dropped.
3.3.3. QoS Class
RFC1695 specified that one of a number of Quality of Service (QoS)
classes is assigned to a VCC or VPC by associating the object
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -