ETSI EN 300 820-2 V1.2.3 (1998-07)

Telecommunications Management Network (TMN); Asynchronous Transfer Mode (ATM) Management information model for the X-type interface between Operation Systems (OSs) of a Virtual Path (VP)/Virtual Channel (VC) cross connected network; Part 2: VP alarm management

DEN/TMN-00032

Telekomunikacijsko upravljavno omrežje (TMN) - Informacijski model upravljanja asinhronega prenosnega načina (ATM) za vmesnik X med obratovalnimi sistemi (OS) omrežja s prevezovanjem navidezne poti (VP)/navideznega kanala (VC) - 2. del: Upravljanje alarma VP

General Information

• Status: Published
• Publication Date: 14-Jul-1998
• Technical Committee: TMN - Telecommunications Management Network
• Current Stage: 12 - Completion
• Due Date: 17-Jul-1998
• Completion Date: 15-Jul-1998
• Ref Project: SIST EN 300 820-2 V1.2.3:2003 - Telecommunications Management Network (TMN); Asynchronous Transfer Mode (ATM) Management information model for the X-type interface between Operation Systems (OSs) of a Virtual Path (VP)/Virtual Channel (VC) cross connected network; Part 2: VP alarm management

Standards Content (Sample)

2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.Telecommunications Management Network (TMN); Asynchronous Transfer Mode (ATM) Management information model for the X-type interface between Operation Systems (OSs) of a Virtual Path (VP)/Virtual Channel (VC) cross connected network; Part 2: VP alarm management33.040.35Telefonska omrežjaTelephone networksICS:Ta slovenski standard je istoveten z:EN 300 820-2 Version 1.2.3SIST EN 300 820-2 V1.2.3:2003en01-november-2003SIST EN 300 820-2 V1.2.3:2003SLOVENSKI
STANDARD



SIST EN 300 820-2 V1.2.3:2003



EN 300 820-2 V1.2.3 (1998-07)European Standard (Telecommunications series)Telecommunications Management Network (TMN);Management information model for the X-typeinterface between Operation Systems (OSs)of a Virtual Path (VP)/Virtual Channel (VC)cross connected network;Part 2: Asynchronous Transfer Mode (ATM)VP alarm managementSIST EN 300 820-2 V1.2.3:2003



ETSIEN 300 820-2 V1.2.3 (1998-07)2ReferenceDEN/TMN-00032 (7lci0iq0.PDF)KeywordsB-ISDN, broadband, ISDN, managementETSIPostal addressF-06921 Sophia Antipolis Cedex - FRANCEOffice address650 Route des Lucioles - Sophia AntipolisValbonne - FRANCETel.: [phone]
Fax: [phone]Siret N° 348 623 562 00017 - NAF 742 CAssociation à but non lucratif enregistrée à laSous-Préfecture de Grasse (06) N° 7803/[e-mail]://www.etsi.frhttp://www.etsi.orgCopyright NotificationNo 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 1998.All rights reserved.SIST EN 300 820-2 V1.2.3:2003



ETSIEN 300 820-2 V1.2.3 (1998-07)3ContentsIntellectual Property Rights.4Foreword.41Scope.52Normative references.53Definitions and abbreviations.63.1Definitions.63.2Abbreviations.84Requirements.85Resources for ATM VP alarm management.95.1The basis for the exchange of management information.95.2The managed resources.106The VP alarm reporting management function sets.106.1VP alarm reporting MS - Overview.106.2Alarm notification MFS.116.3Alarm processing MFS.126.4Alarm event logging MFS.127Management functions.137.1Alarm notification management functions.137.2Alarm processing management function.187.3Alarm event logging management function.188Scenarios.199Management information.209.1Relationships.209.1.1Managed objects.219.1.2Inheritance tree.229.1.3Naming tree.229.2X-interface GDMO description.239.3X-interface ATM VP alarm management ASN.1 module.23Annex A (informative):Security aspects.24History.25SIST EN 300 820-2 V1.2.3:2003



ETSIEN 300 820-2 V1.2.3 (1998-07)4Intellectual Property RightsIPRs essential or potentially essential to the present document may have been declared to ETSI. The informationpertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be foundin ETR 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect ofETSI standards", which is available free of charge from the ETSI Secretariat. Latest updates are available on the ETSIWeb server (http://www.etsi.fr/ipr or http://www.etsi.org/ipr).Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guaranteecan be given as to the existence of other IPRs not referenced in ETR 314 (or the updates on the ETSI Web server) whichare, or may be, or may become, essential to the present document.ForewordThis European Standard (Telecommunications series) has been produced by ETSI Technical CommitteeTelecommunications Management Network (TMN).The present document is part 2 of a multi-part EN covering the management information model for the X-type interfacebetween Operation Systems (OSs) of a Virtual Path (VP)/Virtual Channel (VC) cross connected network, as identifiedbelow:Part 1:"Configuration management aspects";Part 2:"Asynchronous Transfer Mode (ATM) VP alarm management";Part 3:"Performance management aspects".National transposition datesDate of adoption of this EN:3 July 1998Date of latest announcement of this EN (doa):31 October 1999Date of latest publication of new National Standardor endorsement of this EN (dop/e):30 April 1999Date of withdrawal of any conflicting National Standard (dow):30 April 1999SIST EN 300 820-2 V1.2.3:2003



ETSIEN 300 820-2 V1.2.3 (1998-07)51ScopeThe present document addresses the requirements of network and service providers of Asynchronous Transfer Mode(ATM) cross connected networks for managing the fault alarms 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 Public Network Operators (PNOs).The present document describes the X-interface VP alarm management area covering the following aspects:-the Management Services (MS) and Management Functions (MF) needed that provide the necessary alarmmessages for faults detected within ATM Connections which span several administrative domains;-the management information crossing the X-interface. This management information specification uses theGuidelines for the Definition of Managed Objects (GDMO) formalism, described inITU-T Recommendation X.722 [2].The present document has been named as "ATM VP alarm management" because it is expected to be part of acomprehensive fault management standard for ATM VP and Virtual Channels (VCs) in due course. As such it isself-sufficient for the defined scope of reporting faults on, and recovery procedures for, VPs across the X-interface.2Normative referencesReferences may be made to:a)specific versions of publications (identified by date of publication, edition number, version number, etc.), inwhich case, subsequent revisions to the referenced document do not apply; orb)all versions up to and including the identified version (identified by "up to and including" before the versionidentity); orc)all versions subsequent to and including the identified version (identified by "onwards" following the versionidentity); ord)publications without mention of a specific version, in which case 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 samenumber.[1]EN 300 820-1: "Network Aspects (NA); Management information model for the X-type interfacebetween Operation Systems (OSs) of a Virtual Path (VP)/Virtual Channel (VC) cross connectednetwork; Part 1: Configuration management aspects".[2]ITU-T Recommendation X.722: "Information Technology - Open Systems Interconnection -Structure of management information: Guidelines for the definition of managed objects".[3]ITU-T Recommendation G.805: "Generic functional architecture of transport networks".[4]ITU-T Recommendation M.3010: "Principles for a Telecommunications Management Network".[5]ITU-T Recommendation X.721: "Definition of Management Information".[6]ITU-T Recommendation X.733: "Information Technology - Open Systems Interconnection -Systems management: Alarm reporting function".[7]ITU-T Recommendation M.3400: "TMN management functions".[8]ITU-T Recommendation X.734: "Event report management function".[9]ITU-T Recommendation X.208: "Specification of Abstract Syntax Notation One".SIST EN 300 820-2 V1.2.3:2003



ETSIEN 300 820-2 V1.2.3 (1998-07)6[10]Network Management Forum NMF025: "The 'Ensembles' Concepts and Format", Issue 1.0,August 1992.[11]ITU-T Recommendation X.711: "Common management information protocol specification forCCITT Applications".3Definitions and abbreviations3.1DefinitionsFor the purposes of the present document, the following definitions apply:(Some definitions depend on the future acceptance of the "cascaded/mixed mode" as described in EN 300 820-1 [1].This dependence is already taken into account in these definitions).access point: It is defined in ITU-T Recommendation G.805 [3].A Public Network Operator (A PNO): The A PNO is the PNO whose subnet is connected to the A user, the userwhere the overall VP-connection starts. The A PNO can be the initiating one, but this is not always the case. If it is theinitiating PNO it is the root of the X-interface tree. If not, it is the most left leaf (as indicated in figure 1).If, in future the "cascaded" mode should be accepted as defined in EN 300 820-1 [1], and if the A PNO also acts asinitiating PNO, then the A PNO is the consumer of the other PNO's parts of the VP connection.cascade organization: It is described in EN 300 820-1 [1]. The impact of this organization on the model is for furtherstudy.connection: A "transport entity" which is capable of transferring information transparently between "connectionpoints". A "connection" defines the association between the "connection points" and the "connection points" delimit the"connection".consumer and provider roles of a PNO: With respect to a particular VP, a PNO acts as a consumer if it has delegatedthe management of a VP subnetwork connection plus the outgoing link connection (both shall be part of the connection)to another PNO (that acts as a provider). If, in future, the "cascaded/mixed" mode should be accepted(EN 300 820-1 [1]), a PNO can have both roles at once, if it is providing part of the VP (acting as a provider), and at thesame time asks another PNO to provide a part of the connection (acting as a consumer).destination PNO: Z PNO (This term was used in older versions of the specification).initiating Network Operator (PNO): The initiating PNO is the PNO requesting a particular ATM connection startingin the A subnetwork and ending in the Z subnetwork; it controls the overall VP connection.Inter PNO Physical Link (IPPL): It represents a physical link that offers bi-directional transmission capabilities andconnects two pnoVpSubnetworks. Each InterPNOPhysicalLink is terminated by two pnoNWAtmAccessPoints which arein charge of emitting failures related to the link or to the access point itself. An IPPL can be realized by any transmissioncapability (SDH, PDH etc.). There is no explicit managed object defined in the X-interface that represents this resource.Information about IPPLs is included in the interPNOTopologicalSubnetworkPair object, EN 300 820-1 [1].link connection: A "transport entity" provided by the "client/server" association. It is formed by a near-end"adaptation" function, a server "trail" and a far-end "adaptation" function between "connection points". It can beconfigured as part of the "trail management process" in the associated server layer.Link: A "topological component" which describes the fixed relationship between a "sub-network" and another"sub-network" or "access group".mixture organization: It is described in EN 300 820-1 [1]. The impact of this organization on the X-interface model isfor further study.network connection: A "transport entity" formed by the series of "connections" between "termination connectionpoints".SIST EN 300 820-2 V1.2.3:2003



ETSIEN 300 820-2 V1.2.3 (1998-07)7originating PNO: An A PNO when it is also the initiating PNO. (This term was used in older versions of thespecification).Public Network Operator (PNO): An operator that manages an administrative ATM domain. The term PNO is used inthe present document to be in alignment with EN 300 820-1 [1].pnoVpSubnetwork: A subnetwork (according to ITU-T Recommendation G.805 [3]) is a topological component usedfor carrying ATM cells. PnoVpSubnetworks are delineated by termination points, modelled by vpCTPs contained inNWATMAccesspoints, and they are used for setting up pnoVpSubnetworkConnections.NOTE:In principle (cf. to I-ETS 300 653) one subnetwork can consist of several subcomponents: subnetworksand connections between subnetworks (generally called link connections). But this capability is notsupported in Xcoop. Usually one pnoVpSubnetwork represents an ATM network belonging to the domainone network operator.protection switching: Automatic switching to pre-assigned spare capacity in network resources, consequent on reactionto receipt of an alarm signal by a network management system. (In the context of the present document, this is internal toa PNO).recovery: Recovery is a procedure performed by a PNO which makes use of spare capacity in the subnetwork orinter-pno physical links belonging to this PNO. It follows after an alarm signal from a fault in the PNO’s networkresources.star organization: It is described in EN 300 820-1 [1]. It is the organizational form that is used in this specification.sub-network connection: A "transport entity" formed by a "connection" across a "sub-network" between "connectionpoints". It can be configured as part of the "trail management process" as defined in ITU-T Recommendation G.805 [3].subnetwork: A "topological component" used to effect routing and management. It describes the potential for"sub-network connections" across the "sub-network". It can be partitioned into interconnected "sub-networks" and"links". Each " sub-network" in turn can be partitioned into smaller "sub-networks " and "links" and so on. A"sub-network" may be contained within one physical node.termination connection point: It is defined in ITU-T Recommendation G.805 [3].trail: It is defined in ITU-T Recommendation G.805 [3].transit PNO: A transit PNO is a PNO using its own subnetwork to perform its required transit part of VP connection. Ithas a provider role and corresponds to a leaf in the X-interface tree, not being the Z side. In the "cascaded/mixedapproach" case (EN 300 820-1 [1]), it can be both a provider (where it acts as a transit) and a consumer (where iteffectively acts as an Initiating PNO).user: An end customer which is associated with the reservation of a VP connection.VP subnetwork connection: A "transport entity" which is capable of transferring information transparently between"connection points" across a subnetwork or from a subnetwork access point to a user.X-interface tree: With respect to a particular VP, an X-interface relationship exists between each provider PNO and itsconsumer PNO. Because each provider has exactly one consumer, the X-interface relations between all PNOs involvedin the management of a particular VP form a tree, the X-interface relation tree. Note, that for a particular VP there canbe several possible X-interface relation trees; the actual tree is formed at VP set-up. The root of the tree is the InitiatingPNO; it uses (and via an X-interface controls) the PNOs (often transit PNOs), to which it is connected in the tree via itsbranches. The most right leaf of the tree is the Z PNO. Figure 1 shows an example of an X-interface tree.X-interface: The management interface between two PNOs. In the "Responsibility Model", which is described inITU-T Recommendation M.3010 [4], two Operations Systems Functions (= Managers ) that are located in differentTMNs (= different PNOs), communicate over an X Reference Point.Z PNO: A Z PNO is a PNO whose subnet is connected to a user, where the overall VP connection ends.SIST EN 300 820-2 V1.2.3:2003



ETSIEN 300 820-2 V1.2.3 (1998-07)8InitiatingPNOAPNOTransitPNOZPNOTransitPNOFigure 1: Example of an X-interface tree with the Initiating PNO not being the A PNO3.2AbbreviationsFor the purposes of the present document, the following abbreviations apply:ATMAsynchronous Transfer ModeGDMOGuidelines for the Definition of Managed ObjectsMFManagement FunctionsMFSManagement Function SetsMSManagement ServiceOSOperation SystemPNOPublic Network OperatorTMNTelecommunications Management NetworkVPVirtual PathVCVirtual Channel4RequirementsF1In case of faults, it should be possible to localize faults on a PNO sub-network and/or IPPLlevel.F2All parties which are affected by a faulty PNO sub-network are to be informed of the failure.F3All alarm information passed across the X-interface should be time-stamped.F4Elimination of redundant multiple alarms relating to a single underlying cause before the alarminformation is transmitted across the X-interface.F5Protection switching and the result of the protection should be notified.F6It should be possible to enable/disable alarm reporting on a given connection or group ofconnections.F7It should be possible to modify the filtering criteria for alarm reporting.SIST EN 300 820-2 V1.2.3:2003



ETSIEN 300 820-2 V1.2.3 (1998-07)95Resources for ATM VP alarm management5.1The basis for the exchange of management informationThe architectural framework characterizing the exchange of management information across the X-interface isrepresented in figure 2.X-interfacePNOSubnetworkQ interfaceNNMSINMSAlarmNotification MSConfiguration MSRemote INMSFigure 2: Architectural framework for the X-interfaceIn figure 2, the terms "NNMS" and "INMS" were derived from an earlier organizational point of view wherebyadministrations operated "National" (NNMS) and corresponding International (INMS) parts of a single overall networkmanagement system. For the present document these terms are retained but "INMS" can be assumed to be generalized tothe management system for an X-interface interconnection between any two operators, whether within nationalboundaries or across them. NNMS can be assumed to be generalized to the internal management system of any operatorwhich also relies on interconnections using X-interfaces.The block named NNMS is responsible for the management of an operator’s sub-network while the block named INMSis responsible for the management of connections between operators which in turn rely on interconnections with theoperator’s subnetworks. The distinction has been made because these two systems act on different Information Modelsand because there is the necessity of exchange of information between them. The logical positioning of the "Q"interface, which basically controls network switches in the NNMS, is also indicated but any matters relating to thisinterface are outside the scope of the present document.The INMS has to support the following operations as far as the Alarm Notification MS is concerned:-reception of notifications coming from a remote INMS. These notifications are described in detail insubclause 7.1;-reception of alarms coming from the NNMS and relevant to the X-interface. These alarms may be associatedwith faulty VP connections used for inter-network connections (they may be Physical Layer alarms or VP Layeralarms or faults affecting the ATM Cross Connect which acts as the inter-network gateway);-elaboration of alarms coming from the NNMS (qualification and adaptation to inter-network alarm format);-sending of alarms to the appropriate PNOs (Initiating PNO in the case of a VPSC fault or all PNOs in the case ofInter-PNO Physical Link (IPPL) fault);-logging alarms and retrieving alarm reports.SIST EN 300 820-2 V1.2.3:2003



ETSIEN 300 820-2 V1.2.3 (1998-07)105.2The managed resourcesA simplified view of the network level resources being managed is provided in figure 3.An X-interface is presumed to exist at the management level between the PNOs shown in figure 3.A PNOTransit PNOZ PNOVPSCVPSPNAAPIPPLPNAAPIPTSPA UserVPSCVPSCU-PNAAPLegendaVPS:VP SubnetworkVPSC:VP Subnetwork ConnectionIPTSP:Inter-PNO Topological Subnetwork PairIPPL:Inter-PNO Physical LinkPNAAP:pnoNWatmAccessPointU-PNAAP:pnoNWAtmAccessPoint for a userIPTSPFigure 3: X-interface managed network resources and connections6The VP alarm reporting management function sets6.1VP alarm reporting MS - OverviewIn defining the VP Alarm Reporting MS for the X-interface and following the Ensembles concept, defined by theNetwork Management Forum NMF025 [10], some Management Function Sets (MFS) have been identified. Each MFShas been decomposed in MF. The following MFSs have been identified to manage the notifications described inclause 7:-Alarm notification MFS;-Alarm event logging MFS;-Alarm processing MFS.The identified VP Alarm Reporting MFSs are organized as depicted in figure 4 and described in more detail insubclauses 6.2, 6.3 and 6.4.SIST EN 300 820-2 V1.2.3:2003



ETSIEN 300 820-2 V1.2.3 (1998-07)11XInterfaceNNMSINMSQInterfaceAlarm EventLog MFSAlarm NotificationMFSAlarm ProcessingMFSConfigurationMSFault MgtData BaseVP Alarm Management MSFigure 4: MFSs relative to the VP alarm management MS6.2Alarm notification MFSThis MFS performs the following tasks:transmission of faulty VP alarm notifications across the X-interface; these notifications contain the followingparameters:SubnetworkId, resource id (vpConnectionId, atmAccessPointId), time of event, probable cause, perceived severity,specific problems (the last three of which are described in more detail below and are derived from the event informationsection of ITU-T Recommendation X.733 [6] and are reproduced here in order to clarify the basis on which the MFSmessages are generated by the system).forwarding of sent alarms to the Alarm Event Logging MFS to be recorded in the SALog:The four types of Alarm Notifications are summarized in figure 5. In the case of an IPPL failure the same notificationsare sent but to all PNOs instead of only the Origin PNO.probableCause: This parameter defines further qualification (after Event Type and information) as to the probablecause of the alarm. Probable cause values for notifications shall be indicated in the behaviour clause of the object classdefinition. The syntax of standard probableCauses shall be the ASN.1 type object identifier. The managed object classdesigner should choose the most specific probableCause applicable.The set of probableCauses will not be further elaborated here and reference should be made toITU-T Recommendation X.733 [6].specificProblems: This parameter identifies the status of the alarm in the VP Alarm MS. In the context of thesespecifications, the specificProblems values have been restricted to:-protection-switched;-under-recovery;-cleared;-unrecoverable.perceivedSeverity: This parameter defines six severity levels, which provide an indication of how it is perceived thatthe capability of the managed object has been affected. Briefly, these are:-cleared: Indicates the clearing of one or more previously reported alarms.SIST EN 300 820-2 V1.2.3:2003



ETSIEN 300 820-2 V1.2.3 (1998-07)12-indeterminate: Indicates that the severity level cannot be determined.-critical: Indicates that a service affecting condition has occurred and an immediate corrective action is required.-major: Indicates that a service affecting condition has happened and an urgent corrective action is required.-minor: Indicates the existence of a non-service affecting fault condition and that corrective action should betaken in order to prevent a more serious fault.-warning: Indicates the detection of a potential or impending service affecting fault, before any significant effectshave been felt.Again, reference should be made to ITU Recommendation X.733 [6] for full descriptions.6.3Alarm processing MFSFor the Alarm Processing MFS the following tasks are identified:-With regard to the NNMS interface (Not a part of the X-interface specification):-reception of alarms concerning the part of the PNO’s NNMS-based sub-network supporting INMS-basedconnections. It is assumed that these alarms are "qualified" in the sense that the recognition of repeatingalarms and the measurement of persistence has been already performed by the NNMS;-adaptation of the NNMS-based alarm to the required INMS format. This adaptation will allow the sametreatment for NNMS-based and INMS-based alarms;-forwarding the INMS alarms (i.e. the NNMS alarms that have been adapted to INMS format and that shallbe sent to other PNOs) to the VP Alarm Notification MFS.-With regard to the INMS Interface:-reception of alarms from remote INMSs across the X-interface; the alarm indications will contain thefollowing parameters: Subnetwork Id (Sub-network whose PNO has detected the Fault), affected resource id(VPconnectionId, pnoNWAtmAccessPoint, .), time of event, probable cause, perceived severity, andspecific problems. It is supposed that the Sub-network has performed recognition of repeating alarms andmeasurement of persistence before issuing the alarm across the X-interface. The end of the alarm event willbe communicated by using the same alarm indication with the perceived severity field set to "cleared";-forwarding the received alarms to the RA Log to be stored.-Filtering:-discrimination and failure localization: it localizes the failure on the basis of the information received. ThePNO which receives one or more alarm notifications coming from other PNOs will be capable ofdistinguishing the cause of the fault from the inducing causes by analysing the alarm notification parameters.The alarm notification is logged in RAlog (see alarm event logging MFS).6.4Alarm event logging MFSThis task is in charge of managing the interactions with the logs. Logging of alarms may be organized as follows:-RALog: log of received alarms from remote INMSs, recorded sequentially;-QALog: is a log which records the qualified alarms, storing begin, end, counting of alarm repetitions;-SALog: log of sent alarms across the X-interface. This log (and only this type) may also be viewed from a remoteINMS.SIST EN 300 820-2 V1.2.3:2003



ETSIEN 300 820-2 V1.2.3 (1998-07)13Therefore this MFS performs the following tasks:writing alarms that are generated by the Alarm Processing MFS and the Alarm Notification MFS. This function recordsthe next alarm events:-the ones that qualify as alarms (with regard to number of occurrences, persistence, etc.). The set of these alarmsare summarized under the concept "QALog". (QALog is not visible over the X-interface);-alarm notifications that arrive from the X-interface (these are summarized under RALog, which is not visibleover the X-interface);-the alarm notifications that are transmitted over the X-interface. (these are recorded in the SALog, which isvisible over the X-interface).reading information (not a part of the X-interface specification) contained in the logs upon request by the operator. Thisfunction accesses the SALog, RALog and QALog in order to read alarm records. Some access keys may be identifiedfor accessing the information stored in the logs.request alarm report:
...