SIST EN 300 820-3 V1.1.1:2000

• Abstract:

  This document addresses the configuration management area, covering the following aspects: - the management services and functions needed to manage ATM connections, which span over several administrative domains. These management services and functions cover the performance management requirements for the X-interface; - the management information crossing the X-interface (using GDMO formalisms as described in ITU-T Recommendatio X.722).

• Status: Published
• Publication Date: 31-Oct-2003
• ICS: 33.040.35 - Telephone networks
• Technical Committee: SPN - Services and Protocols for Networks
• Current Stage: 6060 - National Implementation/Publication (Adopted Project)
• Start Date: 01-Nov-2003
• Due Date: 01-Nov-2003
• Completion Date: 01-Nov-2003
• Ref Project: ETSI EN 300 820-3 V1.1.1 (2000-11) - Telecommunications Management Network (TMN); Asynchronous Transfer Mode (ATM) management information model for the X interface between Operation Systems (OSs) of a Virtual Path (VP)/Virtual Channel (VC) cross connected networks; Part 3: VP Performance management

SIST EN 300 820-3 V1.1.1:2000 is the SIST adoption of ETSI EN 300 820-3, a European Standard for Telecommunications Management Network (TMN) management of Asynchronous Transfer Mode (ATM) Virtual Path (VP) performance across the X-interface between Operation Systems (OSs) of different Providing Network Operators (PNOs). It specifies the management services, messages, and managed objects used to read performance data, report and log performance alarms, and coordinate performance monitoring for cross-domain VP connections. It is aimed at network and service providers that need a standardized way to exchange performance information between their operation systems.

What does SIST EN 300 820-3 V1.1.1:2000 specify?

SIST EN 300 820-3 V1.1.1:2000 specifies the VP Performance management part of a multi-part ATM management information model for the X-interface. The document focuses on performance monitoring information exchanged between OSs of different PNOs when a VP connection spans several administrative ATM domains.

The standard is restricted to VP Performance Management. The foreword notes that VC Performance Management aspects are for further study.

The document is organized as follows:

Part of the document	What it covers
Clause 1	Scope and relationship to the other parts
Clause 2	Normative references
Clause 3	Definitions, symbols and abbreviations
Clause 4	Performance management requirements
Clause 5	Management services and scenarios
Clause 6	Management information model
Annex A	Need for enhancing the QoS table
Annex B	Mapping of messages onto CMIP primitives

Clause 5 describes the message exchanges used for reading performance data, reporting alarms, inspecting logs, and controlling performance monitoring. Clause 6 defines the managed objects, attributes, actions, name bindings, behaviours, and the ASN.1 module that support those exchanges.

What are the key requirements of SIST EN 300 820-3 V1.1.1:2000?

SIST EN 300 820-3 V1.1.1:2000 sets out the performance-management behaviour that PNOs need to expose across the X-interface. In practice, it defines what an initiating PNO can request, what the responding PNO must report, and how the related managed objects behave.

Clause 4: operational goals

Clause 4 requires that performance problems can be localized on a PNO subnetwork and/or IPPL level, and that threshold-crossed and unavailable-time problems can be indicated on those same levels for an agreed QoS class. It also requires that performance-problem information crossing the X-interface be time-stamped. For users, that means the exchanged records are meant to support fault localization, not just generic alarms.

Clause 5.1: read current performance data

Clause 5.1 and 5.1.1 define Read Performance Data. The I-PNO can request current performance data from an A-, T- or Z-PNO for a monitored VP Subnetwork Connection or VP Link Connection, using M-GET on pnoPerformanceData instances. The returned data can include the current performance ratios, scanPeriod, offsetTime, unavailabilityState, pnoGaugeThresholdAttributeList, and additionalGaugeThresholdAttributeList. In practice, this lets the requesting operator see both the measurements and the threshold context that explains how they are being judged.

Clause 5.2: report and log performance alarms

Clause 5.2 defines Performance Alarm Reporting and Logging. Two alarm types are used: Unavailable Time Notification (UTN) when a connection enters or leaves an unavailable period, and Threshold Crossed Notification (TCN) when a performance parameter crosses a threshold. After sending either notification, the responding PNO stores it in its Performance Log so the I-PNO can read it later. This matters because the live alarm and the retained record are both part of the interface.

Clause 5.2.1 and 5.2.2: how alarms are raised

UTN is tied to unavailable periods and to the state changes derived from ATM severely errored seconds, as detected by the OAM flow continuity check. TCN is driven by periodic updates controlled by scanPeriod, and the standard limits repeated notifications so that at most one threshold-crossed notification is generated per parameter during the same observation period. If a value crosses a threshold and returns to normal before the end of the scanPeriod, no alarm is reported. In practice, this reduces noise from short transients.

Clause 5.3: inspect stored alarms

Clause 5.3 defines Performance Alarm Log Inspection. The I-PNO can read the stored performance alarm messages that were previously sent by the A-, T- or Z-PNO, and the standard advises filtering so that only log information for the connection of interest is returned. This is useful for troubleshooting, audits, and post-event review.

Clause 5.4: coordinate monitoring and thresholds

Clause 5.4 defines Performance Measurement Co-ordination. The I-PNO can set or modify additional thresholds, but not the regular thresholds that come from the reserved QoS class. The document also defines start/stop control for performance monitoring on a SubNetworkConnection and on a LinkConnection. Monitoring starts only when it is requested and the connection is unlocked, and the sink has to be activated before the source. For link monitoring, the model uses separate control in the involved subnetwork domains, so operator coordination is explicit.

Clause 6: object model and behaviour

Clause 6 defines the managed object classes that carry the measurements and notifications: pnoPerformanceData, pnoSNCBidirectionalPerformanceMonitor, and pnoLCBidirectionalPerformanceMonitor. The model shows how pnoPerformanceData is created when monitoring starts and deleted when monitoring stops, and how logs record the alarms sent across the interface. For implementers, this section is the blueprint for the MIB structure, object naming, and the CMIP/CMIS interactions.

What terms does SIST EN 300 820-3 V1.1.1:2000 define?

• PNO (Providing Network Operator) - an operator able to provide network resources to customers and exchange management information across the X-interface.
• pnoPerformanceData - the managed object that holds the current performance data, thresholds, timing information, and unavailability state for a monitored connection.
• pnoSNCBidirectionalPerformanceMonitor - the managed object that controls performance measurement on a pnoVpSubnetworkConnection and covers both transmission directions.
• pnoLCBidirectionalPerformanceMonitor - the managed object that controls performance measurement on a VP Link Connection and is tied to one transmission direction for a given end.
• scanPeriod - the time interval between two successive updates of the performance parameters visible on the X-interface.
• unavailabilityState - the attribute that indicates whether the monitored connection is available or unavailable.
• QoS (Quality of Service) - the agreed service quality class whose performance thresholds are used for monitoring and alarm generation.

Who uses SIST EN 300 820-3 V1.1.1:2000?

SIST EN 300 820-3 V1.1.1:2000 is used by network and service providers that manage ATM cross-connected networks with VP connections spanning multiple administrative domains. It is also used by PNOs that need a common way to exchange performance data, alarm reports, and monitoring-control requests across the X-interface.

In practice, the main users are:

• TMN and network-management engineers defining the interface behaviour.
• O&M teams monitoring VP performance and investigating alarms.
• System designers implementing OS-to-OS management functions.
• Quality and service teams that need to compare observed performance with agreed QoS classes.
• Test teams validating CMIP/CMIS message flows, managed objects, and log handling.

Which standards are used with SIST EN 300 820-3 V1.1.1:2000?

The document relies on several referenced standards and companion parts:

• ETSI EN 300 820-1 - the configuration management part of the same ATM X-interface model.
• ETSI EN 300 820-2 - the alarm management part of the same ATM X-interface model.
• ITU-T Recommendation I.356 - defines the ATM layer cell transfer performance parameters monitored in this part.
• ITU-T Recommendation I.357 - provides the definition of ATM connection availability used for unavailable-state handling.
• ITU-T Recommendation I.610 - provides the OAM operation and maintenance principles and the flow continuity check used for detecting unavailability.
• ISO/IEC 10165-2 and ITU-T Recommendation X.721 - provide the management-information structure and managed object definitions used for the object model.
• ITU-T Recommendation X.722 - provides the GDMO guidance used to define managed objects.
• ITU-T Recommendation M.3100 - provides the generic network information model used as a base for the managed objects.
• ETSI ES 200 653 - provides the Generic Object Model from which the information model is derived.
• ITU-T Recommendations X.710 and X.711 - define the CMIS and CMIP service and protocol used for the message mapping.

What does the SIST EN 300 820-3 V1.1.1:2000 document contain?

The document contains message sequence charts for reading performance data, sending UTN and TCN notifications, inspecting PerfLog records, setting additional thresholds, and starting or stopping monitoring. It also contains an information model with an inheritance tree, entity relationship diagram, name bindings, object class definitions, package definitions, attribute definitions, action definitions, and behaviour definitions.

Clause 6 includes the ASN.1 module XATMPMModule, which defines the syntax for the control information, results, thresholds, locations, and state values used by the interface. Annex A explains why the QoS table needs to be enhanced for cross-domain use, and Annex B maps the management functions to CMIP primitives for implementation and testing.

SLOVENSKI STANDARD
01-november-2003
7HOHNRPXQLNDFLMVNRXSUDYOMDYQRRPUHåMH701,QIRUPDFLMVNLPRGHOXSUDYOMDQMD
DVLQKURQHJDSUHQRVQHJDQDþLQD$70]DYPHVQLN;PHGREUDWRYDOQLPLVLVWHPL
26RPUHåMDVSUHYH]RYDQMHPQDYLGH]QHSRWL93QDYLGH]QHJDNDQDOD9&
GHO8SUDYOMDQMH]PRJOMLYRVWLGHORYDQMD93
Telecommunications Management Network (TMN); Asynchronous Transfer Mode (ATM)
management information model for the X interface between Operation Systems (OSs) of
a Virtual Path (VP)/Virtual Channel (VC) cross connected networks; Part 3: VP
Performance management
Ta slovenski standard je istoveten z: EN 300 820-3 Version 1.1.1
ICS:
33.040.35 Telefonska omrežja Telephone networks
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

European Standard (Telecommunications series)
Telecommunications Management Network (TMN);
Asynchronous Transfer Mode (ATM)
management information model for the X-interface
between Operation Systems (OSs)
of a Virtual Path (VP)/Virtual Channel (VC)
cross connected networks;
Part 3: VP Performance management

2 ETSI EN 300 820-3 V1.1.1 (2000-11)
Reference
DEN/TMN-GOM003-3
Keywords
ATM, B-ISDN, broadband, interface,
management, performance, switching, TMN
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE
Tel.: [phone] Fax: [phone]
Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88
Important notice
Individual copies of the present document can be downloaded from:
http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive
within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at http://www.etsi.org/tb/status/
If you find errors in the present document, send your comment to:
[e-mail]
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.
© European Telecommunications Standards Institute 2000.
All rights reserved.
ETSI
3 ETSI EN 300 820-3 V1.1.1 (2000-11)
Contents
Intellectual Property Rights .4
Foreword.4
1 Scope.5
2 References.5
3 Definitions, symbols and abbreviations .6
3.1 Definitions . 6
3.2 Abbreviations. 7
4 Requirements.8
5 Management services.8
5.1 MFS Read Performance Data. 9
5.1.1 MF Read Performance Data (RPD) . 9
5.2 MFS Performance Alarm Reporting and Logging . 10
5.2.1 MF Unavailable Time Notification (UTN). 11
5.2.2 MF Threshold Crossed Notification (TCN). 13
5.3 MFS Performance Alarm Log Inspection. 14
5.3.1 MF Performance Log Inspection (PLI) . 14
5.4 MFS Performance Measurement Co-ordination (PMC) . 15
5.4.1 MF Additional Threshold Setting/Modification. 15
5.4.2 MF Start/Stop of the Performance Monitoring (STPM). 16
5.4.2.1 MF Start/Stop PM on a SubNetworkConnection (STSNCPM). 16
5.4.2.2 MF Start/Stop PM on a LinkConnection (STLCPM). . 17
5.5 Ensemble Scenarios. 18
5.5.1 Introduction . 18
5.5.2 MF Read Performance Data (RPD) . 18
5.5.3 MF Unavailable Time Notification (UTN). 20
5.5.4 MF Threshold Crossed Notification (TCN). 20
5.5.5 MF PerfLog Inspection (PLI) . 21
5.5.6 MF Additional Threshold Setting/Modification . 22
5.5.7 MF Start/Stop PM on a VpSubNetworkConnection . 22
5.5.8 MF Start/Stop PM on a LinkConnection. 23
6 Management Information model .23
6.1 Introduction. 23
6.1.1 Overview of the Managed Object Classes. 23
6.2 Inheritance tree. 25
6.3 Entity Relationship Diagram. 27
6.4 Name Binding. 28
6.5 Restrictions on standardized Object Classes. 29
6.6 Object Classes Definitions. 29
6.7 Package Definitions. 29
6.8 Attribute Definitions. 32
6.9 Action Definitions. 35
6.10 Name Binding Definitions. 35
6.11 Behaviour Definitions. 36
6.12 ASN.1 Module. 37
Annex A (informative): Need for enhancing the QoS table .39
Annex B (informative): Mapping of messages onto CMIP primitives .40
Bibliography.41
History .42
ETSI
4 ETSI EN 300 820-3 V1.1.1 (2000-11)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://www.etsi.org/ipr).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This European Standard (Telecommunications series) has been produced by ETSI Technical Committee
Telecommunications Management Network (TMN).
The present document is part 3 of a multi-part deliverable covering the management information model for the X-type
interface between Operations Systems (OSs) of a Virtual Path (VP)/Virtual Channel (VC) cross connected network, as
identified below:
Part 1: "Configuration management";
Part 2: "Alarm management";
Part 3: "VP Performance management".
(VC Performance Management aspects are for further study).
National transposition dates
Date of adoption of this EN: 24 November 2000
Date of latest announcement of this EN (doa): 28 February 2001
Date of latest publication of new National Standard
or endorsement of this EN (dop/e): 31 August 2001
Date of withdrawal of any conflicting National Standard (dow): 31 August 2001
Note that in contrast to parts 1 and 2, the present document (part 3) is restricted to aspects associated with VP
Performance Management and that an extension to VC Performance Management remains for further study and
development.
ETSI
5 ETSI EN 300 820-3 V1.1.1 (2000-11)
1 Scope
The present document addresses the requirements of network and service providers of Asynchronous Transfer Mode
(ATM) cross connected networks for managing the exchange of performance monitoring information associated with
the Virtual Path (VP) connections, which span several administrative ATM domains. These requirements are satisfied
by the use of a standardized interface (the "X-interface") between Operation Systems (OSs) belonging to different
Providing Network Operators (PNOs).
Readers of The present document should be made aware that the abbreviation 'PNO' is taken to mean Providing
Network Operator. In early versions of other related documents EN 300 820-1 [7], EN 300 820-2 [8], PNO was defined
as Public Network Operator. The change in definition has been provided to reflect the change in market conditions for
provision of interconnected telecommunications services. However, it is considered necessary to retain the abbreviation
'PNO' because it is found in many of the managed object definitions used to specify the X-interface. It would be
disadvantageous to introduce major changes in these managed object definitions, which serve purely technical purposes
for management of interconnections only.
The present document should be used in conjunction with EN 300 820-1 [7] and EN 300 820-2 [8].
The present document describes the X-interface VP performance management area covering the following aspects:
- the Management Services (MS) and Management Functions (MF) needed to provide the necessary management
messages for performance degradations detected within ATM connections and the necessary Management
Functions for co-ordination of performance monitoring;
- the management information crossing the X-interface. This management information specification uses the
Guidelines for the Definition of Managed Objects (GDMO) formalism, described in
ITU-T Recommendation X.722 [11].
2 References
The following documents contain provisions which, through reference in this text, constitute provisions of the present
document.
• References are either specific (identified by date of publication, edition number, version number, etc.) or
non-specific.
• For a specific reference, subsequent revisions do not apply.
• For a non-specific reference, the latest version applies.
• A non-specific reference to an ETS shall also be taken to refer to later versions published as an EN with the same
number.
[1] ITU-T Recommendation I.357: "B-ISDN semi-permanent connection availability".
[2] ITU-T Recommendation I.356: "B-ISDN ATM layer cell transfer performance".
[3] ITU-T Recommendation I.610: "B-ISDN operation and maintenance principles and functions".
[4] ISO/IEC 10165-2: "Information technology - Open Systems Interconnection - Structure of
management information: Definition of management information".
[5] ITU-T Recommendation M.3100: "Generic network information model".
[6] ITU-T Recommendation I.751: "Asynchronous transfer mode management of the network element
view".
[7] ETSI EN 300 820-1: "Telecommunications Management Network (TMN); Asynchronous Transfer
Mode (ATM) Management information model for X interface between Operation Systems (OSs)
of a Virtual Path (VP)/Virtual Channel (VC) cross connected networks; Part 1: Configuration
management".
ETSI
6 ETSI EN 300 820-3 V1.1.1 (2000-11)
[8] ETSI EN 300 820-2: "Telecommunications Management Network (TMN); Asynchronous Transfer
Mode (ATM) management information model for the X interface between Operation Systems
(OSs) of a Virtual Path (VP)/Virtual Channel (VC) cross connected networks; Part 2: Alarm
management".
[9] ETSI ES 200 653: "Telecommunications Management Network (TMN); Network level generic
class library".
[10] ITU-T Recommendation X.721: "Information technology - Open Systems Interconnection -
Structure of management information: Definition of management information"
(ISO/IEC 10165-3).
[11] ITU-T Recommendation X.722: "Information technology - Open Systems Interconnection -
Structure of Management Information: Guidelines for the definition of managed objects"
(ISO/IEC 10165-4).
[12] ITU-T Recommendation X.710 | ISO/IEC 9595: "Data Communication Networks: Open Systems
Interconnection; Management - Common Management Information Service Definition".
[13] ITU-T Recommendation X.711 | ISO/IEC 9596-1: "Common Management Information protocol
specification for CCITT applications".
3 Definitions, symbols and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
PNO (Providing Network Operator): operator able to provide network resources to customers
- Topological Components
None of the topological components can be created or modified, in terms of characteristics, with management functions
across the X-interface, since they represent physical resources:
inter-PNO Physical Link (IPPL): it represents a physical link that offers bidirectional transmission capabilities and
connects two pnoVpSubnetworks. Each Inter-PNO Physical Link is terminated by two pnoNWAtmAccessPoints which
are in charge of emitting notifications in case of failures related to the link or to the access point itself. An IPPL can be
realized by any transmission capability (SDH, PDH etc.). There is no explicit managed object defined that represents
this resource. Information about IPPLs is included in the interPnoTopologicalSubnetworkPair object
interPnoTopologicalSubnetworkPair: it represents the connectivity between the VP Subnetworks of two PNOs, and it
includes one or a bundle of IPPLs that actually provide this connectivity
pnoVpSubnetwork: topological component used to effect routing and management of ATM cells. It describes the
potential for setting up "ATM-VP connections" across the subnetwork. The pnoVpSubnetworks are delineated by ATM
AccessPoints and interconnected by "inter-PNO Physical links".
A pnoVpSubnetwork can be partitioned into interconnected "sub-networks" and "links", but this partitioning is not
shown over X-interface. In the context of The present document, one pnoVpSubnetwork represents an ATM network
belongingtoonePNO
- Transport entities
Transport entities provide transparent information transfer across the network. There is no information change between
input and output other than that resulting from degradation in the transfer process:
sub-network connection: subnetwork connection is capable of transferring information transparently across a
subnetwork. It is delimited by connection termination points at the boundary of the subnetwork and represents the
association between these connection points
ETSI
7 ETSI EN 300 820-3 V1.1.1 (2000-11)
pnoVpSubnetworkConnection: pnoVpSubnetworkConnection represents a bidirectional portion of a VP connection
across a PNO subnetwork. It transports ATM cells from one pnoNWAtmAccessPoint to another. This connection is
seen by the I-PNO through the X-interface as a whole, with no details regarding the way the connection is composed
inside the involved PNOs domains.
If a failure on subnetwork connection occurs this managed object emits a failure notification concerning the subnetwork
connection portion of the VP Connection
Vp Link Connection: VP connection crossing a number of PNO administrative domains can be partitioned into VP
Subnetwork Connections and VP Link Connections. The latter represent the part of the overall connection that run over
an Inter-PNO Physical Link
- Reference points
pnoNWAtmAccessPoint: it represents the access point to the ATM PNO Subnetwork, or in some cases, it represents
an endpoint of a Inter-PNO Physical Link at the cell level. Each IPPL is terminated by two pnoNWAtmAccessPoint
which are in charge of emitting Fault Notifications when detecting failures related to the link or the access point itself
pnoVpCTP: this resource represents an endpoint of a pnoVpSubnetworkConnection (and therefore of a VP Link
Connection as well). Instances of this object class are contained in pnoNWAtmAccessPoints. A pnoVpCTP maps to the
VPidentifier of the virtual path
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
AP Access Point
A-PNO Originating PNO
ASN.1 Abstract Syntax Notation 1
ATM Asynchronous Transfer Mode
CDV Cell Delay Variation
CER Cell Error Ratio
CLR Cell Loss Ratio
CMIP Common Management Information Protocol
CMIS Common Management Information Service
CMISE Common Management Information Service Element
CMR Cell Misinsertion Rate
CTP Connection Termination Point
ER Entity Relationship
GDMO Guidelines for the Definition of Managed Objects
INMS Inter-operator Network Management System
I-PNO Initiating PNO
IPPL Inter-PNO Physical Link
LC Link Connection
MIB Management Information Base
MO Managed Object
MOC Managed Object Class
NE Network Element
NMS Network Management System
OAM Operation And Maintenance
PM Performance Management
PNO Providing Network Operator
QoS Quality of Service
SECBR Severely Errored Cell Block Ratio
SES Severely Errored Seconds of an ATM connection
ATM
SNC SubNetwork Connection
TMN Telecommunications Management Network
T-PNO Transit PNO
VP Virtual Path
VPCTP Virtual Path Connection Termination Point
Z-PNO Terminating PNO
ETSI
8 ETSI EN 300 820-3 V1.1.1 (2000-11)
4 Requirements
1) In case of performance problems, it should be possible to localize performance problems on a PNO
sub-network and/or IPPL level.
2) It should be possible to indicate threshold crossed and unavailable time problems on a PNO sub-network
and/or IPPL level, formerly agreed in a configuration management request for a certain QoS class.
3) All performance problems information passed across the X-interface should be time-stamped.
4) It should be possible to start and stop performance monitoring on request.
5) It should be possible to set and modify additional thresholds.
5 Management services
The following MFSs for Performance management have been identified:
Read Performance Data
- (request to read the value of one or several measured performance parameters, for a particular VP Subnetwork
Connection/VP Link Connection by the I-PNO).
Performance Alarm Reporting and Logging
- (notification and logging of performance alarms).
Performance Alarm Log Inspection
- (log consultation on reported performance alarms).
Performance Management Co-ordination
- (for the I-PNO to request an A, T or Z PNO to Start/Stop the performance monitoring process of the VP SNC or
LC and the setting or modification of PM additional thresholds).
All alarms due to performance degradation have a warning, the severity of which is indicated. The underlying resource
has no state change associated with the PM alarm.
Each MFS is described by a set of messages that are sent between PNOs. PNO internal activities initiated by incoming
messages are described only as necessary for the description of the X-interface message exchanges. The order in which
the different messages are issued is illustrated by the use of Message Sequence Charts.
It should be noted that only the main parameters are indicated in the Sequence Charts. The full list of parameters per
message and the parameter value range can be obtained from the ASN.1 and GDMO description. It should also be noted
that the MFS described here only cover the normal flow of events and the most important error cases, not the invalid or
unexpected behaviours.
An MFS is decomposed into a set of one or several MFs. The 4 MFS in this specification are listed hereafter, together
with the related MFs:
- MFS Read Performance Data;
- MF Read Performance Data (RPD);
- MFS Performance Alarm Reporting and Logging;
- MF Unavailable Time Notification (UTN);
- MF Threshold Crossed Notification (TCN);
- MFS Performance Alarm Log Inspection;
- MF Performance Log Inspection (PLI);
ETSI
9 ETSI EN 300 820-3 V1.1.1 (2000-11)
- MFS Performance Measurement Co-ordination;
- MF PM Additional Thresholds Setting/Modification (TSM);
- MF Start/Stop PM on a Subnetwork Connection (STSNCPM);
- MF Start/Stop PM on a Link Connection (STLCPM).
5.1 MFS Read Performance Data
This MFS enables the I-PNO to read performance data from the A-, T- or Z-PNOs.
Each PNO will, if requested by the I-PNO, collect performance data for the active semi-permanent VP connections
within its domain. How this information is collected is an internal matter for each PNO and hence beyond the scope of
this MFS. This MFS describes how performance data information held within the domain of the A-, T- or Z-PNO can
be read by the I-PNO.
The Read Performance Data MFS contains one Management Function: Read Performance Data (RPD).
5.1.1 MF Read Performance Data (RPD)
This MF enables the I-PNO to get performance data related to its connections from another PNO.
Each PNO that provides monitored VP Subnetwork Connection and VPLink Connection resources has, if requested, to
collect by any internal means, the performance information from its ATM network to provide performance data related
to the following resources: VP Subnetwork Connections and VP Link Connections.
In each PNO MIB this network level performance information is contained in up to three pnoPerformanceData
ObjectClass Instances per monitored connection:
- one for the Vp Subnetwork Connection for both directions of transmission (named by a
pnoSNCBidirectionalPerformanceMonitor object);
- one for the VP Link Connection towards the A-PNO for one transmission direction (named by a
pnoLCBidirectionalPerformanceMonitor object);
- one for the VP Link Connection towards the Z-PNO for one transmission direction (named by a
pnoLCBidirectionalPerformanceMonitor object).
This means that an A- or Z-PNO may only have one instance of Performance Data object for VP Link Connection
monitoring purposes.
Although performance information held by the pnoPerformanceData object is supposed to be "real time " information,
the frequency at which the performance information visible on the X-interface is updated could be relatively low and
depends on the different PNOs. The duration between two successive updates of performance parameters is called the
scanPeriod. The scanPeriod value is read-only across the X- interface and the way this value is set is outside the scope
of the interface definition. The information in the Performance Data will be updated as a result of internal performance
processing activities within a PNO domain.
For a given connection the performance information related to A, T and Z-PNOs Subnetwork and Link Connections can
only be read by the I-PNO. The M-GET CMISE service is used for reading the attributes of the pnoPerformanceData
object instances.
The I-PNO acts as the Manager and the PNO receiving the request acts as the Agent. The parameters that the manager
will receive include the following:
- the values of the performance ratios to be read (e.g. atoZCER, atoZCLR0, etc.);
- scanPeriod, which represents the time interval between two successive updates of performance parameters. It is
read-only;
- offsetTime, which represents the difference between the current time and the time of the last update of the
performance parameters. It is read-only;
ETSI
10 ETSI EN 300 820-3 V1.1.1 (2000-11)
- unavailabilityState, which indicates if the connection is in an unavailable state or not, based on the definition
from ITU-T Recommendation I.357 [1];
- pnoGaugeThresholdAttributeList, which contains the threshold(s) associated with the requested QoS class for
the connection;
- additionalGaugeThresholdAttributeList, which contains the additional thresholds set by the I-PNO.
The reading operation can be performed at any time and it is possible as long as the object instance exists.
Consequently, if the monitored connection is in an inactive state, reading of performance information is possible but
should return the NULL value.
I-PNO A,T,Z-PNO
For all Performance data
to be read
ReadPerformanceData (GET_Req)
Read pnoVpSubnetworkConnection
and VpLinkConnection perf. data
ReadPerformanceData (GET_Rsp)
Figure 1: Read Performance Data
5.2 MFS Performance Alarm Reporting and Logging
A Performance alarm notification is sent to the I-PNO across the X-interface whenever performance degradation
occurs in the A, T or Z PNO domain.
In order for an X-interface performance alarm notification to be sent from the A, T or Z PNO to the I-PNO at least one
of the attributes, that reflects the actual performance data of a VP Subnetwork Connection or VP Link Connection, must
cross the threshold kept in the pnoGaugeThresholdAttributeList attribute or in the
additionalGaugeThresholdAttributeList attribute. Alternatively a notification is sent if the VP Subnetwork Connection
begins or ends an unavailability period.
The MFS Performance Alarm Reporting and Logging contains two different Management Functions.
The first one handles the case when a VP Subnetwork Connection enters or leaves an unavailability period, MF
Unavailable Time Notification (UTN). The perceived severity field in the notification is set to "Warning" to indicate the
beginning of the performance alarm and to "Cleared" to indicate the end.
The other MF Threshold Crossed Notification (TCN) is emitted when at least one of the performance parameters
associated with the resource crosses a threshold requested by the I-PNO (either to indicate a performance degradation or
a performance restoration respectively for the monitored VP connection).
After sending either kind of notification, the agent PNO has to store it in the Performance Log in its MIB, so that it can
be read at any time by the I-PNO to which it was sent. The logging function is part of the two MFs described here while
the Log Reading functionality is covered by the Performance Alarm Log Inspection MFS.
ETSI
11 ETSI EN 300 820-3 V1.1.1 (2000-11)
Reception:
A Performance Alarm is received by the I-PNO across the X-interface if the INMS of the A-, T-, or Z-PNOs sends one.
The subsequent processing of the message by the I-PNO (e.g. displaying) is outside the scope of The present document.
5.2.1 MF Unavailable Time Notification (UTN)
An Unavailable Time Notification is sent to the I-PNO across the X- interface whenever a VP Subnetwork Connection
or VP Link Connection owned by this I-PNO becomes unavailable and when it becomes available again.
Unavailable period Available period
start detected start detected
10 seconds
Time (seconds)
10 SESATM without
any SESATM
Availability Unavailability Availability
Period Period Period
SESATM: Severely Errored Second
Error free second ES:secondwitherrors
Figure 2: A VP connection Entering and Leaving the Unavailability period
As shown in figures 2 and 3, an unavailable time event message indicating that the VP connection is in the unavailable
state is sent out defining when the VP connection was in the available state before and ten consecutive SESATM events
have occurred. The VPC then enters the unavailability period and the ten SESATM are part of the unavailable time. The
SESATM are detected with the OAM flow continuity check (see ITU-T Recommendation I.610 [3]).
The connection is considered to be in the available state again when for 10 consecutive seconds no SES event occur,
ATM
and these ten seconds are part of the available time.
The unavailable time event message is sent to the I-PNO across the X-interface as a QoS Alarm notification.
After sending the message, the agent PNO appends the Performance Alarm record in the standard MO PerfLog in its
MIB. The record will be deleted after a certain time that is not standardized, but rather agreed bilaterally by the PNOs.
ETSI
12 ETSI EN 300 820-3 V1.1.1 (2000-11)
A, T, Z- PNO I-PNO
IF ten consecutive SES AND
ATM
state is available time
FORA,T,Z-PNOs (having
degraded resource involved in
the VPC)
UnavailableTime(M_Event_Report)
(The starting of the Unavailable Time is
10s earlier.)
Unavailable Time Event Logging
Start of unavailable timer
IF ten consecutive non SES
ATM
AND state is Unavailable Time
FOR the detecting PNO (A, T, Z-PNO)
UnavailableTime(M_Event_Report)
(The ending of the Unavailable Time is
10s earlier).
Unavailable Time Event Logging
End of unavailable timer
Figure 3: The notification of the Unavailable Period event
ETSI
13 ETSI EN 300 820-3 V1.1.1 (2000-11)
5.2.2 MF Threshold Crossed Notification (TCN)
The MF Threshold Crossed Notification is initiated when a Performance Threshold is crossed by at least one of the
observed current performance parameters (see figure 4). After each interval of time, set with the scanPeriod attribute,
the performance parameters held in the pnoPerformanceData object have to be updated. Each time that the data related
to performance is updated, the new values should automatically be matched against the threshold values, contained in
the pnoGaugeThresholdAttributeList object and in the additionalGaugeThresholdAttributeList object. If any of the
thresholds are crossed a notification should be sent. There is a maximum of one Threshold Crossed notification per
parameter during the same observation period identified by the scanPeriod attribute.
It should be noted that in the case where a threshold is crossed and back to a normal value within the same scanPeriod,
there is no QoSAlarm notification reported to the I-PNO.
Monitored Performance
parameter
QoS Alarm Notification
QoS Alarm Notification
(Cleared)
(Warning)
threshold
scanPeriod
time
Figure 4: Occurrence of QoS Alarm and QoS Alarm Clearance Notification
The Threshold Crossed event message is sent to the I-PNO across the X-interface as a QoS Alarm notification. For the
monitored VP Subnetwork Connection and VP Link Connection the Performance Data MO instances belonging to that
PNO emit a QoS Alarm notification when a threshold crossing has been detected.
The monitored parameters are those described in ITU-T Recommendation I.356 [2], and the threshold values are
indicated in the QoS table in annex 1.
The notification sent includes the following parameters:
- probable cause, which is set to "Threshold Crossed";
- perceived severity, which is set to "Warning" to indicate that the performance has been degraded and to
"Cleared" to indicate that the performance has been restored for this parameter (other parameters could possibly
be in a 'threshold crossed' status. It is only when all the TCs are cleared that the performance is completely
restored);
- thresholdInfo which includes the parameter that triggered the notification, the value of threshold crossed, and
the actual measured attribute value;
- additionalInformation, that tells if the notification is related to the VP Subnetwork Connection, to the VP Link
Connection towards the A-end or to the VP Link Connection towards the Z-end.
ETSI
14 ETSI EN 300 820-3 V1.1.1 (2000-11)
A, T or Z PNO
I-PNO
ThresholdCrossed (M_Event_Report)
update Perflog
Figure 5: The notification of a Threshold Crossed Event.
After sending this notification, the agent PNO copies it in the Performance Alarm Record and appends it in the standard
MO PerfLog in its MIB. The record will be deleted only after a certain amount of time which is not standardized, but
rather agreed bilaterally by the PNOs.
5.3 MFS Performance Alarm Log Inspection
This MFS enables the I-PNO to read stored performance alarm messages previously sent to it by the A-, T- or Z-PNO.
This is possible due to the previous MFS that includes standard logging of the alarms sent by the PNO acting as agent.
5.3.1 MF Performance Log Inspection (PLI)
In the Performance Alarm Log Inspection MFS, there is only one MF called the Performance Log Inspection MF (PLI).
This allows a PNO acting as a manager (i.e. the I-PNO for a connection) to read the Performance alarm logs of the A-,
T- or Z-PNO for that connection across the X-interface.
In the PLI MF, the I-PNO requests to read the sent alarm log of another PNO (A, Z or T) that receives the request,
checks it and if it is valid returns the response to the I-PNO (either a failure, or the alarm record(s) requested).
The sequence of messages that can be exchanged across the X-interface between the requesting (I) PNO and the
responding (A, T or Z) PNO for the Performance Log Inspection is given in figure 6.
ETSI
15 ETSI EN 300 820-3 V1.1.1 (2000-11)
A, T, Z-PNO
I-PNO
Read PerfLog (GET_Req)
Read PerfLog (GET_Rsp)
Figure 6: The perfLog Inspection
It is advisable that a filtering mechanism is applied when a PLI request is made, so that only the PerfLog information
related to the connection of interest is sent back in the response.
5.4 MFS Performance Measurement Co-ordination (PMC)
This MFS enables the I-PNO to co-ordinate the performance monitoring information of the different VP Subnetwork
and Link Connections in the A-, T- and Z-PNOs domains into the performance information for the end-to-end VP
connection under its responsibility. This MFS contains two types of functionalities: MF Additional Threshold
Setting/Modification and MF Start/Stop.
5.4.1 MF Additional Threshold Setting/Modification.
This MF enables the I-PNO to request the setting or the modification of the values for the additional thresholds of a VP
Subnetwork Connection and/or a VP Link Connection; refer to figure 7. The A-, T- or Z-PNO responds to the request of
the I-PNO either with a threshold set/modification information or with a failure indication. Please note that the regular
thresholds cannot be set or modified with this MF. The regular thresholds are set by default in the reserve request which
specifies the "VpQoSClass". The mapping between the value (0…99) of this integer and the performance parameters is
done by the QoS table (see annex A).
If an alarm condition exists previous to the occurrence of a threshold value change (i.e. an old threshold had been
violated) and the current value of the measurement is within the allowable range of the new threshold value, then a QoS
alarm notification is emitted with the severity field set to "Cleared". If the new threshold value is set within the range of
the old threshold value, so that the new threshold is also violated, a QoS alarm notification is emitted even if an alarm
condition is already outstanding.
I-PNO A, T, Z PNO
ThresholdValueModification (SET_Req)
ThresholdValueModification (SET_Rsp)
Figure 7: Additional Threshold Setting/Modification
ETSI
16 ETSI EN 300 820-3 V1.1.1 (2000-11)
5.4.2 MF Start/Stop of the Performance Monitoring (STPM).
The performance monitoring on a VP Subnetwork Connection will be started whenever requested by the I-PNO for that
connection and it will be stopped either when the connection is deactivated or whenever explicitly requested by the
I-PNO.
If the connection is activated and deactivated during its reservation lifetime, several different situations could arise:
- The monitoring process has been explicitly started by the I-PNO at a moment in which the connection is
deactivated.
- In this case the monitoring should start as soon as the connection is activated.
- The monitoring process has been explicitly started by the I-PNO at a moment in which the connection is active
and after that, the connection is deactivated and activated again, without any explicit "stop monitoring" request
being received.
- In this case the monitoring should be started when requested, stopped when the connection is deactivated and
automatically restarted when the connection is reactivated.
- The connection is deactivated and therefore not being monitored, but the monitoring process is supposed to start
as soon as the connection is reactivated and the I-PNO issues an explicit request to stop the monitoring.
- The monitoring process will not be started when the connection is reactivated.
To perform this behaviour, the attributes sinkPMRequest and sourcePMRequest are used to indicate if performance
monitoring is requested.
5.4.2.1 MF Start/Stop PM on a SubNetworkConnection (STSNCPM)
The performance monitoring will be started when the administrativeState of a pnoVpSubnetworkConnection has the
state UNLOCKED and one of the two attributes sinkPMRequest and/or sourcePMRequest of the
pnoSNCBidirectionalPerformanceMonitor indicates that performance monitoring has been requested.
The values of the attributes sinkPMRequest and sourcePMRequest are set with the pnoSNCControlPM Action
belonging to the pnoSNCBidirectionalPerformanceMonitor object class.
Therefore, the attributes SinkPMRequest and SourcePMRequest will determine the role of the Access Point at the
A-end, and the Access Point on the other end will necessarily take the opposite role. Only those two attributes,
sinkPMRequest and sourcePMRequest, are needed to control the performance monitoring within the subnetwork
connection. The reason is that if OAM cells are to be introduced in the pnoNWAtmAccessPoint at one end of the
Subnetwork Connection, the pnoNWAtmAccessPoint at the other end of the subnetwork connection has to be ready to
collect those OAM cells.
NOTE: Sink/Source order of activation = the Sink has to be activated before the Source.
Figure 8 shows the message interactions needed to start or stop the monitoring process with the pnoSNCControl Action.
ETSI
17 ETSI EN 300 820-3 V1.1.1 (2000-11)
I-PNO A, T, Z-PNO
PnoSNCcontrolPM (ACTION_Req)
PnoSNCcontrolPM (ACTION_Rsp)
PM Start/Stop
PnoSNCcontrolPMInformation (ACTION_Req)
PnoSNCcontrolPMResult (ACTION_Rsp)
Figure 8: PM on a SubNetworkConnection.
5.4.2.2 MF Start/Stop PM on a LinkConnection (STLCPM).
The performance monitoring will be started when the administrativeState of a pnoVpSubnetworkConnection has the
state UNLOCKED and one of the two attributes sinkPMRequest and/or sourcePMRequest of the
pnoLCBidirectionalPerformanceMonitor indicates that performance monitoring has been requested.
The values of the attributes sinkPMRequest and sourcePMRequest are set with the pnoLCControlPM Action belonging
to the pnoLCBidirectionalPerformanceMonitor object class.
The pnoLCControlPM Action will be used to indicate when the monitoring process is requested on a Link Connection.
It can also be specified if the monitoring is to be performed in both directions or only in one, and, in that case, in which
one.
NOTE: Sink/Source order of activation = the Sink has to be activated before the Source.
ETSI
18 ETSI EN 300 820-3 V1.1.1 (2000-11)
Figure 9 shows the message interactions needed to start or stop the monitoring process with the pnoLCControl Action
I-PNO A, T, Z-PNO
PnoLCcontrolPM (ACTION_Req)
PnoLCcontrolPM (ACTION_Rsp)
PM Start/Stop
PnoLCcontrolPMInformation
(ACTION_Req)
PnoLCcontrolPMResult
(ACTION_Rsp)
Figure 9: PM of a link connection
5.5 Ensemble Scenarios
5.5.1 Introduction
This clause defines the Ensemble scenarios. Each of these definitions consists of brief textual descriptions and message
flow diagrams.
The scenarios are used to show how the managed objects in the information model can be used to accomplish the
function listed in clauses 5.1 to 5.4.
In the scenarios that follow, CMIP [13] flows between (and corresponding CMIS [12] primitives within) manager and
agent systems are indicated by arrows with a three character abbreviation for request, indicate, response and confirm
primitives shown at the head and tail of the arrow. For example:
o-- Req -------------------- Ind -->
CMIS request
<-- Cnf -------------------- Rsp --o
CMIS response
NOTE 1: CMIS information in italics denotes parameters described in the sequence charts. No OPTIONAL parts
are included.
NOTE 2: It should be noted that the local distinguished name is used to address the Base Object Instance for all
scenarios described in clause 5.5.
5.5.2 MF Rea
...