SIST EN 300 820-3 V1.1.1:2000

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.: +33492 94 4200 Fax: +33493 65 4716
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:
editor@etsi.fr
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
...