Management of Hybrid Packet and Circuit Switched Networks Work ongoing in ITU-T SG-4 27 March 2000...

Management of Hybrid Packet and Management of Hybrid Packet and Circuit Switched NetworksCircuit Switched Networks

Work ongoing in ITU-T SG-4 Work ongoing in ITU-T SG-4

27 March 200027 March 2000IETF TMN BOFIETF TMN BOF

Mark KlererMark KlererWorking Group Chair, ITU-T SG 4 WP 5Working Group Chair, ITU-T SG 4 WP 5

Tel: +1 973 292 5710Tel: +1 973 292 5710Fax: +1 973 292 4161Fax: +1 973 292 4161

Email: [email protected]: [email protected]

2IETF TMN BOF, Adelaide, Aus. - 27 March 2000 2M. Klerer -

Topics

• Problem Statement

• What is TMN

• The Q.25 Framework

• One Common Simplified Methodology

• Multiparadigm Support In TMN

• Common Semantics and Processes in TMN

• Event Services in TMN

• Work within SG-4 on TMN

• Proposal for Joint Work


Problem Statement• New telecom networks are emerging and existing networks are evolving to use

packet switched technologies as networks backbone and/or service infrastructure. These networks build on the heritage of the traditional PSTN and the traditional Internet. In order to be able to support the services the users are demanding it must be possible to manage these new networks in a manner that allows:

— Easy configuration of network elements, networks and services

— The ability to support different types of Service Level Agreements

— The ability for service providers to measure and bill service usage

— Monitor the network to assure performance guarantees are met

— Provision for network robustness in the event of faults and the isolation of faults

— The ability for multiple service providers to cooperate in end-to-end service and network management

— The ability for service providers to deploy multi-vendor solutions

— The ability for new vendors to work into a known deployed operations infrastructure


What is TMN• A functional architecture for:

— Identification of levels of abstraction of management activity

— Separation of technology, networking, service and business concerns

— Identification of management tasks that need to be performed

— Identification of information and activities that need to exist between functional entities

• A set of common information models and processes

— Information models for network elements, networks and services

— Models and procedures for common management tasks, e.g. alarm reporting, performance monitoring, call detail recording, . . .

• A set of protocols for communicating between NEs and Oss, and OSs and OSs

— Large selection of lower layer protocols

— Original upper layers use OSI protocols (CMIP and FTAM)

— Upper layer architecture evolving to address CORBA, EDI, SNMP, ...


TMN Relationship to Telecommunications Networks

.

SwitchingSystem

SwitchingSystem

SwitchingSystem

TransmissionSystems

OSTraffic Mgmt

TransmissionSystems

OSSurvelliance

OSProvisioning

Data Communications Network

WS WS WS

WS

TMN

Telecommunications Network

TMN Interfaces

WorkStation


ServiceManagement

ElementManagement

NetworkManagement

NetworkElements

TMN Layered Architecture (M.3010)

Business Management

• Enterprise view• Goal setting, finance, budgeting• Product & human resource planning

• Contacts with customers & svc providers• Service orders, complaints, & billing• Quality of service

• Network support of all services • End-to-end network view of all NEs & links

• View of NE subset, individually or collectively as a subnetwork• Mediation

• Network resource functionality

OSF

OSF

OSF

OSF

NEF

•

•

•

•

q

q

q

q


Elements of a TMN Interface

• Architectural definition of communicating TMN entities: roles and relationships

• Operation, Administration, Maintenance, and Provisioning (OAM&P) requirements to be supported by communications

• Application information models for support of OAM&P requirements

• Resource information models defining abstractions of telecommunications network resources to be managed

• Protocols to transport the application and resource information between TMN entities

ManagingSystem

ManagedSystem

TMNInterface


TMN Physical Architecture (M.3010)

Data Communications Network(DCN)

Data Communications Network(DCN)

OperationsSystem

(OS)

MediationDevice(MD)

Q Adaptor(QA)

NetworkElement

(NE)

NetworkElement

(NE)

WSQ / X / F

Q

Q / F

Q

QQ

TMN

X

FG

Q Adaptor(QA)

Q

WS - Workstation


Integrated Management of Telecom and IP-based Networks• In June 1998, SG 13 modified its work plan to emphasize IP and SG 16

requested SG 4 support of its work on the management of multimedia terminals, systems, and protocols.

• In response, SG 4 agreed to define the Integrated Management of IP-based and Telecom Networks.

• In September, ITU-T’s Telecommunication Standardization Advisory Group (TSAG)

— Assigned SG 13 as the lead SG for IP Aspects

— Requested each SG to determine how to support IP-based networks

— Established procedures for collaboration between the ITU-T and the IETF

• In October, SG 15 modified its TMN work plan to support interworking with IP-optimized transport equipment.

• In December 1998, ITU-T IP Workshop supported TMN as basis for Integrated Management of IP and Telecom Networks

• In March 1999, SG 4 modified its work plan to support IP, including the creation of a unified management framework to support its role as lead ITU-T SG for TMN

• January 2000 SG-4 agrees to work jointly with ETSI TC-TMN, TIPHON and T1M1 on management of hybrid packet/circuit switched based networks

10IETF TMN BOF, Adelaide, Aus. - 27 March 2000 1

0M. Klerer -

Q 25/4 Proposal on Integrated Management of Hybrid Circuit Switched and Packet/IP Networks• Objectives

Enable flow-through of management information in support of business processes, both within OSs within a single administration and between administrations. Flow-through of information between administrations may be subject to firewalling and may, therefore, not be available for all functions; (i.e. the business processes determine what may flow through and what will require interactions between staff or be blocked).

Enable one-touch end-to-end service management in a Hybrid Circuit/Packet (HCP) environment, by supporting an integrated view of packet and circuit switched network resources, applications and services.

Enable end-to-end network management in an HCP environment, including transparent fault isolation across packet and circuit switching technologies and performance parameter allocation for impairments that occur due to the multiple technologies.

Allow identical functionality of network elements, networks and services to be managed by the same processes regardless of whether the functionality is used with circuit or packet technology.


1M. Klerer -

Framework Document Outline

• Descriptions of

— Networking Environment

— Services Environment

— Application Services

— TMN Considerations– TMN Management Architectures for HCPN– IP Based Management Architectures

— Information Models and Specification Methodology

— Protocol Architectures and Interworking


2M. Klerer -

TMN Methodology for Requirements and Modelling

• Objective: Common working methods for all groups working on specifications of TMN based on Requirement, Analysis and Design methodology (M.3020)

— Requirements to be understandable to OAM experts and provide sufficient detail to drive modelling

— Model details to be traceable to requirement details

— Information to be defined independent of deployment technology

• Approved Methodology will use:– For Requirements and Analysis: UML notations including Use Case, Class Structure, Sequence,

Collaboration, Activity, and Implementation Diagrams; State Charts– For Design: Use tools appropriate for that paradigm. E.g. IDL for CORBA; GDMO for

CMIP, SMI for SNMP, ...


3M. Klerer -

It’s a Multi-paradigm World

• New technologies are evolving continuously and particular technologies may be more appropriate in particular environments. It is therfore proposed to accommodate multiple model paradigms within TMN. Two types of paradigms are defined:

— General purpose paradigms– Models and protocols that supply the full set of management

functionality required in a distributed environment (.e.g. scalability, data search capabilities, event services)

– Currently: CMIP and CORBA2.3 with additional services

— Special purpose paradigms:– Models and protocols designed to satisfy some specific management

application. Special purpose paradigms will exist because for their particular application they may offer a performance advantage or economic benefit.

– Currently: EDI, SNMP


4M. Klerer -

Requirements for General Purpose Paradigms.• Scalability (106 - 107 objects)

• Compatibility with existing models

• Support multiple managers

• Support for query capabilities

• Support for data modification capabilities

• Support operations for set valued attributes

• Support multiple object access

• Selective access of attributes

• Support operations on multiple objects

• Support of autonomous notifications

• Well defined notifications

• Support for modeling of the containment relationship

• Support of unique names

• Support of creation and deletion semantics


5M. Klerer -

CMIS Capabilities (Q.811, Q.812)

• Data manipulation functions

— Get

— Set: Replace, Set to Default, Add to list, Delete from list

• Object Life Cycle

— Create

— Delete

• Object Methods

— Action

• Notification Service

— Event Report

• Support Capabilities

— Simultaneous operation on multiple objects

— Conditional operation based on filtering

— Retrieval based on filtering

— Cross object synchronization


6M. Klerer -

Preserving Semantics and Processes in a Multi-paradigm World

• Common semantics (at the individual parameter level) for all common parameters (e.g. be able to perform a one-to-one mapping of state information between two objects/entities).

• Allow the management application for the same management function to operate identically in both the circuit-switched and packet-switched environment.


7M. Klerer -

Telecommunications Management Services

• Alarm Surveillance - Q.821

• Performance Management - Q.822

• Traffic Management - Q.823

• ISDN Service Profile Management - Q.824

• Call Detail Recording - Q.825

• Routing Management - Q.826


8M. Klerer -

The Q.821 Alarm Surveillance Model

LO G

ALARMREC ORD

Agent

EventForw arding

Discrim inator

Notification

Alarm Reports, to aM anager (e.g ., O S)

ALAR MRECO RD

M anagedObject

(e.g ., TTP)


9M. Klerer -

Alarm Reporting Services

• Initiate Alarm Reporting• Configure Alarm Filters• Suspend/Resume Alarm Reporting• Terminate Alarm Reporting• Create (Alarm) Logs• Configure Log Filters• Log Alarm Reports• Suspend/Resume Logging of Events• Retrieve Alarm Records• Configuration of Summary Alarms• Alarm Severity Assignment• Inhibiting/Allowing of Audible/Visual Indicators• Resting of Audible/Visual Indicators


0M. Klerer -

Event Report Management Function (X.734)

The Event Reporting Function provides services and management support objects to provide the following capabilities:

1. Allow specification the destination(s) and backup destination(s) to which event reports are to be sent.

2. Allow the specification of filtering criteria that determine which notifications to transmit as event reports.

3. Allow the initiation and termination of event reporting to a particular destination.

4. Allow temporary suspension and resumption of event reporting services.

5. Allow for scheduling of event reporting activity.

6. Allow retrieval of event reporting characteristics.

7. Allow the specification of whether or not events are to be sent in confirmed mode.


1M. Klerer -

Event Reporting Model

PotentialEvent

Reports

EventReports

EventPreprocessing

EventReport

Controls

EventReporting

Discriminator

Discrim inator Construct

M anagedObjects

N otifications


2M. Klerer -

Event Forwarding Discriminator Behaviour

The optional mode attribute in the EFD determines whether the event report will be sent in the confirmed or unconfirmed mode.

The Event Forwarding Discriminator (EFD) contains a destination, and optionally, a backup destination list and active destination attribute. When the EFD forwards event reports it forwards these event reports to the destination indicated in the destination sttribute or to the destination indciated in the active destination attribute when this attribute is present. The backup destination list is a prioritized list of backup destinations that are used if the primary or higher priority destination becomes unreachable.

The scheduling characteristics of the EFD are determinjed by the Scheduling Package that has been instantiated. At most one scheduling package may be instantiated. If a scheduling package is instatntiated the availability status package must also be instantiated.


3M. Klerer -

Event Forwarding Discriminator Behaviour

Event forwarding to a particular destination is initiated by creating an EFD and terminated by deleting an EFD.

Suspension and resumption of event reporting is accomplished by manipulating the administrative state attribute of the EFD. When the administrative state is Locked, event reporting is suspended; changing to the Unlocked state resumes event reporting.

To allow monitoring of the history of event reporting of a particular system, the EFD emits notifications when it is created, modified and deleted. The first event processed by an EFD is its own creation notification; the last its own deletion notification.

Whether or not the EFD is currently on- or off-duty is indicated by its availability status. In the absence of scheduling capability the EFD is always on duty and this attribute is not present.

The types of events that will be forwarded are determined by the logical expression contained in the discriminator construct.


4M. Klerer -

The Log Control Function (X.735)

objects to provide the following capabilities:The Log Control Function provides services and management support

1. Allow the specification of filtering criteria that determine whatinformation is to be logged.

2. Allow the initiation and termination of logging to a particular log.

3. Allow temporary suspension and resumption of logging activity

4. Allow for scheduling of logging activity.

5. Allow retrieval of logging characteristics.


5M. Klerer -

Log Control Model

EventRecords

Event Log

Applications

Event RecordRequests

Event LogControls

EventReports

Event ReportCollector

EventData

EventData

D iscrim ina tor C onstruct

EventPreprocessingM anaged

Objects

N otifications


6M. Klerer -

Log Behaviour

The Log is a support object that provides the capability of recording local and incoming events. For each event or event report to be logged, a log record is created and stored in the log.

The log, as defined in ISO, is a logical entity. A log may, therefore, be of infinite size and may be implemented on multiple and heterogeneous devices.Logs that are of finite size will eventually become full. Two kinds of behavior may be experienced when the log-full condition occurs: the log may wrap, i.e. earliest received records are deleted, or the log may halt, i.e. the most recent events are discarded.

To allert managers that a log-full condition is approaching, a Capacity Alarm Threshold notification is available and may be used to generate alarms. This threshold is set-valued. The threshold and associated notification is mandatory for a log that displays "halt" behavior.

The log records within a particular log contain record ids. These ids are assigned ascending in numerical sequence and can be used for retrieving all records since the last read.


7M. Klerer -

Log Behaviour; Contd.

The kind of information that will be logged is determined by the logical expression contained in the discriminator construct.

Logging to a particular log is initiated by creating a log and terminated by deleting the log. Alternatively, logging can also be terminated when the stop time arrives.

Suspension and resumption of logging is accomplished by manipulating the administrative state attribute of the log. When the administrative state is Locked, logging is suspended; changing to the Unlocked state resumes logging. Log records can be retrieved eben when the log is in the Locked state.

Whether or not the log is currently on- or off-duty is indicated by its availability status.

To allow monitoring of the history of the log of a particular system, the log emits notifications when it is created, modified, deleted or when its optional capacity threshold is exceeded.


8M. Klerer -

The Event Log Record

ATTRIBUTES

R

R/W

R

R NOTIFICATIONS

OPERATIONS

CONDITIONAL PACKAGES

event Log Record MANAGED OBJECT CLASS

Record IdLogging timeManaged object classManaged object instanceEvent type

RR

No ne

None

Event Time PackageNotification Identifier PackageCorrelated Notifications PackageAdditional Text PackageAdditional Information Package


9M. Klerer -

Log Record and Event Log Record Behavior

A log record cannot be created by a direct management operation. Instead log records are created as a side effect of an event report or a local event.

Event log records cannot be modified by management action, but it can be deleted. Until deleted event log records constitute an unmodified record of what has occurred.

Log records contain record ids that are unique within the log and are assigned in numericaly ascending order.

All log records are time stamped when logged.

Event log records contain optional event time, notificationidentifier, correlated notifications, additional text and additional information attributes. These attributes are present in the event record whenever they are contained as parameters in the incoming event report or when available in the local system for local events.


0M. Klerer -

Event Reporting and Logging Model

EventRecords

Event Log

A pplications

Event RecordRequests

Event LogControls

EventReports

Event ReportCollector

EventReports

EventPreprocessing

EventReport

Controls

EventData

EventData

Discriminator Construct

EventReporting

Discriminator

D iscriminator Construct

PotentialEvent

Reports

M anaged Object

LogPreprocessing


1M. Klerer -

Alarm Reporting Function (X.733)

Five alarm types have been defined:

- Communications alarm - Quality of service alarm - Processing alarm - Equipment alarm - Environmental alarm

The Alarm Reporting Function provides the user with the ability to transmit and clear alarms. Alarms are events that indicate a change in the networking or systems environment that is of concern to management. The alarms allow for the indication of the severity of the situation and provide parameters that facilitate event correlation.


2M. Klerer -

Alarm Reporting Service - Event Specific Information

• Probable Cause• Specific Problems• Perceived Severity• Backed-up Status• Back-up Object• Trend Indication• Threshold Information• Notification Identifier• Correlated Notifications• State Change Definition• Monitored Attributes• Proposed Repair Actions• Additional Text• Additional Information


3M. Klerer -

• Approach• Identify events that are of interest in determining performance characteristics

• Define a time interval over which these events are to be observed

• Record the number of occurrences of these events in a current data object

• Threshold these event, if required, to generate an alarm• At the end of the time interval, if required, move data into a history data object

Q.822 Performance Monitoring


4M. Klerer -

Q.822 Performance Monitoring Hierarchy

Top(X.721)

Scanner(X.738)

TresholdData

(Q.822)

HistoryData

(Q.822)

CurrentData

(Q.822)

TechnologySpecific

Current Data

TechnologySpecific

History DataTechnology

SpecificHistory Data


5M. Klerer -

Model of the Performance Data Collection

Managed Object being observed

Current Data or its subclasses

scannerId

granularityPeriod

susp ectF lag

various PM attributes

no t all attributes shown

not all attributes shown

.

.

.

.

.

.


scannerId

granularityPeriod

suspectFlag


not all attributes show n

.

.

.


scannerId

granularityPeriod

suspectF lag



.

.

.


6M. Klerer -

Thresholding Applied to a Single Managed Object

Event Forw ardind Discrim inator

discrim inatorConsdtruct

destinationAddressbeginTim e

endTim e

adm inistrativeState


.

.

M-Event Report ofThreshold Crossing

Current Data or its suclasses

scannerId

granularityPeriod

suspectFlag

thresholdDataInstance

various PM Attributes


.

.

.Q uality of ServiceNotification

Threshold Data

thresholdDataId

thresholdAttributeList


.

.

.

Managed Object Being ObservedLog

logId

Discrim inatorConstruct

..not all attributes shown

A larm R ecord

recordId

eventT ime


A larm R ecord

recordId

eventT ime


Alarm Record

recordId

eventTim e

..not all attributes show n


7M. Klerer -

Thresholding Applied to a Group of Managed Objects

Current Data or its suclassescurrentDataI d

granularityPeriodsuspectFlag

thresholdDataInstancevariousPm nAttributes

not all attr ibutes shown

.

.

.

Managed Object Being O bserved


Managed Object Being Observed

Current Data or its suclassescurrentDataI d

granularityPeriodsuspectFlag

thresholdDataInstancevariousPm nAttributes


.

.

.


Managed O bject Being Observed


scannerIdl

suspectFlagthresholdDataInstancevarious PM Attributes


.

.

.


Threshold DatathresholdDataIdthresholdAttributeList

Event Forw arding Discrim inator

discrim inatorConstructdestinationAddressbeginTim eendTim eadm inistrativeState


.

.

.

M-Event Report ofThreshold Crossing

Quality Of ServiceNotification

granularityPeriod


8M. Klerer -

Performance Monitoring History Data

currentDataId

suspectFlag

.

.

.

Managed Object Being Observed


scannerId

granularityPeriod

suspectFlag

discrim inatorConstruct



.

.



.

.

History Data or itssuclasses

historyDataId

various PM Attributes.


.

.

History Data or itssuclasses

historyDataId

various PM Attributes.


.

.

H istory Data or itssuclasses

historyDataId



9M. Klerer -

Option 4

cNE cNE cNE iwNE

Pkt Layer EMS

pNEpNEpNE

Ckt Layer EMS

Payload EMS

SMS

NMS

Management of HCSP Networks Possible Realizations


0M. Klerer -

Possible IP Management Areas

• Management of IP network resources

—Routers, bridges, hubs, LANs, and hosts, such as servers and workstations

—Supports management of IP-based TMN DCNs

• FCAPS for IP networks including

—H.323-based management

—Topology management

—Policy management

—SLA management

—IP usage management

• FCAPS for mixed networks including

—End-to-end connection management

—Integrated accounting management

—Interlayer management (ala G.805 layers)


1M. Klerer -

ITU-T SG 4 Question Responsibilities

Q.2/4 – M.1400 extensions (C)

Q.6/4 – None

Q.8/9/4 (aka MQ/4) – M.23IP perf. objectives, allocations and limits (P)

Q.10/4 & 11/4 – IP test procedures and test equipment (F,P)

Q.12/4 – None

Q.13/4 – M.3013, Investigate extensions to architecture (All)

Q.14/4 – “SMI responsibility” (some relationship to Q.19/4)

Q.15/4 – M.3100 (F,C,P), M.3200 (All), M.3400 (All), M.3108- and M.3208-series leased circuits (All)

Q.17/4 – M.3320 (All), M.332x-series (specific parts of FCAPS), SLA Requirements (P)

Q.18/4 – Generic CL Network Models (FCAP), Adapt to G.cls

Q.19/4 – Q.81x-series, IP related management protocol


2M. Klerer -

Q.20/4 – Q.825 [CDR](A), Q.823 (tfc. mgt), Q.821 (alarm), Q.822 (perf), Q.824 (?), Policy managemnt

Q.21/4 – IP access network (NAS and RAS)

Q.23/4 – IP NML

Q.24/4 – Mobile-IP, Intelligent Networks

Q.25/4 – Framework and Tracking Work Plan of SG-4 Projects and other SG IP related Management Projects

ITU-T SG 4 Question Responsibilities


3M. Klerer -

Proposal for a Common Group for Joint Expert Meetings on HCSP Management

• To allow work on management of HCSP networks to proceed most rapidly and assure that common semantics can be preserved it is proposed that the network, service and business management level work be done jointly. This work needs to be cognizant of the capabilities provided by the network elements.

• The network element work will in all likelihood be done within the network element groups but should use common semantics and be driven by overall management capabilities required at the network, service and business layer.

• Initial stake-holder groups identified: ITU-T, ETSI, TIPHON, T1M1 and IETF


4M. Klerer -

Host Date

TIPHON March 14, 2000

ETSI TC-TMN May 23-24, 2000

T1M1 August 9-11, 2000

ITU-T Q25/4 15-19 January 2001

Scheduled Meetings


5M. Klerer -

Next Scheduled Meeting

23 - 24 May Meeting:

Contributions expected by 10 May 2000

Venue: ETSI Building in Sophia Antipolis, France

(Nearest Airport: Nice)

Mailing List For Joint Meetings:

[email protected]

To subscribe sent e-mail to:

[email protected] with body of text

subscribe jointnm


6M. Klerer -

Want More Information ?

• Selected TMN Standards and Comprehensive Presentation on SG-4 Work is available via FTP at

—[email protected]/itu_to_ietf/SG4


7M. Klerer -


Option 1

cNE cNE cNE iwNE

IP EMS

pNEpNEpNE

Inf. EMS

NMS

SMS


8M. Klerer -

Option 2

cNE cNE cNE iwNE

IP EMS

pNEpNEpNE

Inf. EMS

NMS

SMS

SemanticMediator



9M. Klerer -

Option 3

cNE cNE cNE iwNE

IP EMS

pNEpNEpNE

Inf. EMS

Inf. NMS

SMS

IP NMS

Integrated NMS


Management of Hybrid Packet and Circuit Switched Networks Work ongoing in ITU-T SG-4 27 March 2000...

Documents

Transcript of Management of Hybrid Packet and Circuit Switched Networks Work ongoing in ITU-T SG-4 27 March 2000...