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. 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
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 RFC 1695 . Changes relative to RFC 1695 are summarized in the MIB module's REVISION clause. Textual Conventions used in this MIB are defined in  and . RFC 2271 . 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 , STD 16, RFC 1212  and RFC 1215 . The second version, called SMIv2, is described in RFC 1902 , RFC 1903  and RFC 1904 . 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 . A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901  and RFC 1906 .
The third version of the message protocol is called SNMPv3 and described in RFC 1906 , RFC 2272  and RFC 2274 . 0 Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 . A second set of protocol operations and associated PDU formats is described in RFC 1905 . 0 A set of fundamental applications described in RFC 2273  and the view-based access control mechanism described in RFC 2275 . 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.
<-----------------------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.
<---------------------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. 22]). +--------+ +--------+ +--------+ pvc| ATM |svc svc | ATM |svc svc | ATM |pvc ----| Switch |-----------| Switch |-----------| Switch |---- +--------+ +--------+ +--------+ Figure 3: An example of a Soft PVC
RFC1695 specified that one of a number of Quality of Service (QoS) classes is assigned to a VCC or VPC by associating the object atmTrafficQoSClass with each VCL or VPL. However, new insights in ATM traffic management have caused this object to be deprecated.
(between IF a and IF b, the minimum of the two configured "Max Active VPI Bits" is 6, so both interfaces set their "Max Current VPI Bits" to 6. Since IF c and IF d both are configured with "Max Active VPI Bits" of 8, they set their "Max Current VPI Bits" to 8.) Figure 5 MSB LSB +----------------------------------------------------+ | | | | | +----------------------------------------------------+ ^ ^ ^ ^ | | | | Max bits Max Bits Max Max supported supported Active (config.) current (negotiated) by MIB by h/w Bits Bits Figure 6 16], the DS3 or SONET MIBs for management of physical interfaces, and, as appropriate, MIB modules for applications that make use of ATM, such as SMDS. These MIB modules are outside the scope of this specification. The current specification of this ATM MIB is based on SNMPv2-SMI.
rconnect between two VCLs is represented in the atmVcCrossConnectTable of the ATM-MIB, indexed by the atmVclCrossConnectIdentifier values for the two VCLs. For an SVC or Soft PVC the VPL and VCL tables defined in this memo are used. Hoewever, for an SVC or Soft PVC the cross-connect between two VPLs is represented in the atmSvcVpCrossConnectTable of the ATM2-MIB, indexed by the atmVplCrossConnectIdentifier values for the two VPLs, and the cross-connect between two VCLs is represented in the atmSvcVcCrossConnectTable of the ATM2-MIB, indexed by the atmVclCrossConnectIdentifier values for the two VCLs. Note: The ATM2-MIB module was being defined in a separate memo at the time of this publication. Please consult the RFC directory for an exact reference. 16], ATM is a data link layer protocol. Thus, for ATM switches and ATM networks, sysServices will have the value "2". 17] which states that the interfaces table (ifTable) contains information on the managed resource's interfaces and that each sub-layer below the internetwork layer of a network interface is considered an interface. Thus, the ATM cell layer interface is represented as an entry in the ifTable. This entry is concerned with the ATM cell layer as a whole, and not with individual virtual connections which are managed via the ATM-specific managed objects specified in this memo. The inter-relation of entries in the ifTable is defined by Interfaces Stack Group defined in .
Object Use for the generic ATM layer ====== ============================= ifIndex Each ATM port is represented by an ifEntry. ifDescr Description of the ATM interface. ifType The value that is allocated for ATM is 37. ifSpeed The total bandwidth in bits per second for use by the ATM layer. ifPhysAddress The interface's address at the ATM protocol sublayer; the ATM address which would be used as the value of the Called Party Address Information Element (IE) of a signalling message for a connection which either: - would terminate at this interface, or - for which the Called Party Address IE would need to be replaced by the Called Party SubAddress IE before the message was forwarded to any other interface. For an interface on which signalling is not supported, then the interface does not necessarily have an address, but if it does, then ifPhysAddress is the address which would be used as above in the event that signalling were supported. If the interface has multiple such addresses, then ifPhysAddress is its primary address. If the interface has no addresses, then ifPhysAddress is an octet string of zero length. Address encoding is as per . Note that addresses assigned for purposes other than those listed above (e.g., an address associated with the service provider side of a public network UNI) may be represented through atmInterfaceSubscrAddress. ifAdminStatus See . ifOperStatus Assumes the value down(2) if the ATM cell layer is down. ifLastChange See . ifInOctets The number of received octets over the interface, i.e., the number of received, assigned cells multiplied by 53. ifOutOctets The number of transmitted octets over the interface, i.e., the number of transmitted, assigned cells multiplied by 53.
ifInErrors The number of cells dropped due to uncorrectable HEC errors. ifInUnknownProtos The number of received cells discarded during cell header validation, including cells with unrecognized VPI/VCI values, and cells with invalid cell header patterns. If cells with undefined PTI values are discarded, they are also counted here. ifOutErrors See . ifName Textual name (unique on this system) of the interface or an octet string of zero length. ifLinkUpDownTrapEnable Default is disabled (2). ifConnectorPresent Set to false (2). ifHighSpeed See . ifHCInOctets The 64-bit version of ifInOctets; supported if required by the compliance statements in . ifHCOutOctets The 64-bit version of ifOutOctets; supported if required by the compliance statements in . ifAlias The non-volatile 'alias' name for the interface as specified by a network manager. 18].
AAL5 in a switch is modeled as shown in Figure 7 and 8. AAL5 will be managed in a switch for only those virtual connections that carry AAL5 and are terminated at the AAL5 entity in the switch. Note that, the virtual channels within the ATM UNIs carrying AAL5 will be switched by the ATM switching fabric (termed as ATM Entity in the figure) to the virtual channels on a proprietary internal interface associated with the AAL5 process (termed as AAL5 Entity in the figure). Therefore, performance management of the AAL5 resource in the switch will be modeled using the ifTable through an internal (pseudo-ATM) virtual interface and the AAL5 performance management per virtual connection will be supported using an additional AAL5 connection table in the ATM MIB. The association between the AAL5 virtual link at the proprietary virtual, internal interface and the ATM virtual link at the ATM interface will be derived from the virtual channel cross-connect table and the virtual channel link table in the ATM MIB. Note that for the proprietary virtual interface the traffic transmit and receive conventions in the virtual channel link table are as follows: Transmitting traffic: ATM Entity ---> AAL5 Entity Receiving traffic: ATM Entity <--- AAL5 Entity ___________________________ | | | ============= | | | AAL5 | | | | Entity | | | ============= | | | | | -----Prop. Virtual Interface | | | | ============= | | | ATM | | | | Entity | | | ============= | |_____|__|__|__|__|_______| | | | | | ---------------- ATM UNIs | | | | | | | | | | v v v v v Figure 7: Model of an AAL5 Entity in a Switch
__________________ | | | AAL5 | |________________| | | | Prop. Virtual | | Interface | |________________| Figure 8: AAL5 Entity's Interface Stack in a Switch
21]. Specific interpretations of ifTable for the AAL5 CPCS layer are as follows. Object Use for AAL5 CPCS layer entity ====== ============================== ifIndex Each AAL5 entity is represented by an ifEntry. ifDescr Description of the AAL5 entity. ifType The value that is allocated for AAL5 is 49. ifMtu Set to the largest PDU size for the AAL5 CPCS layer that can be processed by the AAL5 entity. ifSpeed Set to 0. ifPhysAddress An octet string of zero length. ifAdminStatus See . ifOperStatus Assumes the value down(2) if the AAL5 layer is down. ifLastChange See . ifInOctets The number of received AAL5 CPCS PDU octets. ifOutOctets The number of AAL5 CPCS PDU octets transmitted. ifInUcastPkts The number of received AAL5 CPCS PDUs passed to a higher-layer. ifOutUcastPkts The number of AAL5 CPCS PDUs received from a higher-layer for transmission. [Note: The number of AAL5 PDUs actually transmitted is the number received from a higher-layer for transmission minus any which are counted by ifOutErrors and ifOutDiscards.]
ifInErrors Number of errored AAL5 CPCS PDUs received. The types of errors counted include CRC-32 errors, SAR time-out errors, and oversized SDU errors. ifInUnknownProtos Set to 0. ifInDiscards Number of received AAL5 CPCS PDUs discarded. Possible reason may be input buffer overflow. ifOutErrors Number of AAL5 CPCS PDUs that could not be transmitted due to errors. ifOutDiscards Number of AAL5 CPCS PDUs received for transmission that are discarded. Possible reason may be output buffer overflow. ifInMulticastPkts Set to 0. ifInBroadcastPkts Set to 0. ifOutMulticastPkts Set to 0. ifOutBroadcastPkts Set to 0. ifName Textual name (unique on this system) of the AAL5 entity or an octet string of zero length. ifHighSpeed Set to 0. ifConnectorPresent Set to false (2). ifPromiscuousMode Set to false(2). ifLinkUpDownTrapEnable Default is disabled (2). ifAlias The non-volatile 'alias' name for the interface as specified by a network manager.
Object Use for proprietary virtual, internal interface associated with AAL entities ====== =============================================== ifIndex Each proprietary virtual, internal interface associated with AAL entities is represented by an ifEntry. ifDescr Description of the proprietary virtual, internal interface associated with AAL entities. ifType The value that is allocated for proprietary virtual, internal interface is 53. ifSpeed See . Set to 0 if the speed is not known. ifPhysAddress See . An octet string of zero length if no address is used for this interface. ifAdminStatus See . ifOperStatus See . ifLastChange See . ifName Textual name (unique on this system) of the interface or an octet string of zero length. ifHighSpeed See . Set to 0 if the speed is not known. ifConnectorPresent Set to false (2). ifLinkUpDownTrapEnable Default is disabled (2). ifAlias The non-volatile 'alias' name for the interface as specified by a network manager.
23]. The ILMI protocols and MIBs allow two connected ATM Interface Management Entities (IMEs) to exchange bi-directional parameters, mainly to facilitate auto-configuration between ATM peer entities. The support of the ATM management functions by the ILMI MIBs and those contained in this memo are compared in Table 1. In this table, "yes" in the "ILMI MIBs" column indicates that the management functions are supported by the ILMI MIBs. The parenthesized numbers in the "This memo" column correspond to the sets of tables enumerated in Section 6.2. For that subset of management information which the ILMI MIBs and this memo have in common, every effort has been made to retain identical semantics and syntax, even though the MIB objects are identified using different OBJECT IDENTIFIERs. Table 1 - Structuring of ATM Managed Objects ______________________________________________________________ | |This |ILMI| ATM Mgmt.Inf. |ATM Managed Objects |memo |MIBs| ______________|_________________________________|_______|____| Local Interface Information: _____________________________________________________________ ATM interface:| (1) port identifier |ATM MIB| | physical layer| (2) physical transmission types | (1)*|yes | configuration | (3) operational status |MIB II | * | | (4) administrative status | | ** | | (5) last change status | | | _____________________________________________________________ ATM interface:| (1) active VPI/VCI fields |ATM MIB| | cell layer | (2) maximum number of VPCs/VCCs | (1) |yes | configuration | (3) configured VPCs/VCCs | | ** | | (4) ILMI VPI/VCI values | | | | (5) Neighbor system info | | | | (6) Max. number of VPI/VCI bits | |yes | | (7) ATM Subscribed Address | | | _____________________________________________________________ ATM interface:|(1) received/transmitted cells | | | cell layer |(2) cells with HEC error |MIB II |yes | performance |(3) cell header validation errors| | | _____________________________________________________________
_____________________________________________________________ ATM interface:|(1)DS3 PLCP severely errored |ATM MIB| | PLCP & TC | framing seconds | (2)| | layer |(2)DS3 PLCP unavailable seconds | |no | performance |(3)DS3 PLCP alarm state | | | |(4)out of cell delineation events| | | |(5)TC alarm state | | | _____________________________________________________________ VP/VC link: |(1)VPI or VPI/VCI value |ATM MIB| | configuration |(2)VCL or VPL operational status | (3,4)|yes | |(3)VCL/VPL administrative status | |*** | |(4)VCL/VPL last change status | | | |(5)transmit/receive traffic/ | | | | service category parameters | | | |(6)AAL type | | | |(7)transmit/receive AAL5 SDU size| | | |(8)AAL5 encapsulation type | | | |(9)connection topology type | | | |(10)use of call control | | | _____________________________________________________________ VP/VC |(1)cross-connect identifier | | | Cross-connect:|(2)port identifier of one | | | configuration | end | | | |(3)port identifier of the other |ATM MIB| | | end | (5)|no | |(4)VPI or VPI/VCI value | | | | of one end | | | |(5)VPI or VPI/VCI value of | | | | the other end | | | |(6)VC/VP cross-connect | | | | operational status | | | |(7)VC/VP cross-connect | | | | administrative status | | | |(8)VC/VP last change status | | | _____________________________________________________________ VCC AAL5 CPCS |(1)PDUs discarded for CRC errors |ATM MIB| | layer: |(2)PDUs discarded due to | (6) | | performance | reassembly time out | |no | |(3)PDUs discarded due to large | | | | SDUs | | | _____________________________________________________________ AAL5 entity: |(1)received/transmitted PDUs | | | |(2)PDUs discarded due to | | | | protocol errors |MIB II |no | |(3)a set of configuration/state | | | | parameters | | | _____________________________________________________________
*The operational, administrative, and last change status of the ATM interface and the physical transmission type shall be supported by the interface table in MIB II . ILMI does not contain the administrative and last change status of the ATM interface. ** The ILMI MIB contains read-only objects for various parameters at the ATM interface level. ***The ILMI MIBs contain local and end-to-end operational status of the VPC/VCC segment. However, it does not contain the VPC/VCC administrative and last change status and the VCC AAL information.